-
Notifications
You must be signed in to change notification settings - Fork 325
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix readonly ubiquiti airmax #3141
base: main
Are you sure you want to change the base?
Fix readonly ubiquiti airmax #3141
Conversation
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. |
ebea824
to
f18f517
Compare
@herbetom Please try with this patch and add the property to the node of the nor flash:
|
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. |
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. |
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. |
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? |
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? |
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_keys
file accross reboots.I haven't validated that the device was actually affected and haven't checked anything else.
dmesg