(re)add previously readonly ubiquiti airmax #3141
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
3. topic: docs
|
At the OpenWrt developer meetup, we've talked about this patch and while it doesn't matter for this backport, the patch should be replaced by a more selective patch based on DT-properties, as this approach might break future devices if upstream deprecates the unlock-all Kconfig symbol. |
|
A quick test seems promising (see updated initial post). I'm not too keen to brick (and attempt to restore the device). What tests do we want to do before readding them? I'll take the device home and can to those then. |
herbetom
force-pushed
the
fix-readonly-ubiquiti-airmax
branch
from
ebea824 to
f18f517
Compare
|
@herbetom Please try with this patch and add the property to the node of the nor flash: |
herbetom
force-pushed
the
fix-readonly-ubiquiti-airmax
branch
from
f18f517 to
cb6a2ee
Compare
|
Okay, My patch was not the best. Please apply the patches from my staging tree and see if this fixes the WP. Also remember to revert the kernel configuration update which enabled this behavior target-wide. |
herbetom
force-pushed
the
fix-readonly-ubiquiti-airmax
branch
2 times, most recently
from
12afa0d to
2dbb134
Compare
|
I've tried it and the device didn't came back up. Don't know what's gone wrong. A Power Cycle didn't change anything. |
|
Tried on a TL-WR842N v3 with and without the DT property. So the patch itself seems fine. |
herbetom
force-pushed
the
fix-readonly-ubiquiti-airmax
branch
2 times, most recently
from
08717ce to
c39b4ca
Compare
|
The current state seems to work regarding resolvig the read only problem. Hoewer, in my tests with an Ubiquiti NanoBeam AC Gen1 (XC) i've had the problem that the device became unresponsive after some upgrades (Ethernet up, but no response). The "solution" was to power it down for an extended period of time. (A few days, haven't attempted to narrow it down. Just unpluging it for a few seconds didn't seem to help.) I'm not eaxtly sure what triggers it, but larger upgrades (upgrading from OpenWrt v2023.1.x) seems like something that should be tested a bit more. |
herbetom
force-pushed
the
fix-readonly-ubiquiti-airmax
branch
from
c39b4ca to
1d81c97
Compare
|
I've rebased this onto #3184 |
|
@herbetom needs an update or rebase, doesn't it? |
|
@herbetom if it is still relevant und you want to go on with this, can you please rebase and test your code again? |
herbetom
force-pushed
the
fix-readonly-ubiquiti-airmax
branch
from
1d81c97 to
ec0e2d9
Compare
|
@herbetom i just noticed you rebased your code back then but didn't remove the DRAFT - maybe you want to think about this again? |
|
I just verified this PR on a NanoStation XW on Sunday. Both commits together also work :) (as intended) In order to test whether the device would still be broken without this change (very likely). |
|
@rotanid Sorry for never responding! 🙈 My motivation to do anything related to ubiquiti is quite low atm. I think i've asked in #gluon at the point of rebasing something on how to procceed. But there wasn't any feedback and then i never got back to it ... @Djfe I agree, at this point we should probably drop the attempt of the arguably better targeted unlocking. With it beeing unlocked on OpenWrt now for quite some time i wouldn't be too confident that other devices won't also rely on this and it would cause further disruption turning that back. |
|
What are you agreeing with? ^^ Since Ubiquiti has a working tftp recovery we are less likely to run into a bricking typo like this one, that is hard/impossible to recover from: In the end this is up to the committer (possibly blocktrron) whether we want to merge this into the next release or not. PS: |
|
|
About your post in february: |
|
I tested an image without the kconfig and it effectively resets the device into config mode: Logread after sysupgrading to an image without the kconfig or the fix from this PRThe device reboots into config mode and resets all settings (or rather can't restore them during sysupgrade, I guess). I used sysupgrade without the argument -n There is one good thing though: Conclusion: TL;DR |
herbetom
force-pushed
the
fix-readonly-ubiquiti-airmax
branch
from
ec0e2d9 to
49089c2
Compare
herbetom
changed the title
|
okay good to know building openwrt 24.10 fails. on ath79-generic. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
closes #2939
I've installed a firmware build from the branch on a
Ubiquiti NanoBeam AC Gen1 (XC).I'm able to store the
/etc/dropbear/authorized_keysfile accross reboots.I haven't validated that the device was actually affected and haven't checked anything else.
dmesg