Add a list of files and directories you want to survive an upgrade to /etc/sysupgrade.conf (this is in addition to config files that are kept by default when you check "keep configuration" box).
Would this kernel be included in Arix NSS build??
Thank you!
I just installed the NSS build from the arix00 repo on my router and 4 APs. It has better speeds but still topping out at around 450 Mbps on wi-fi. It's very possibly my config or I am missing some setting. But my config is basic, just a bunch of static leases and around 55 devices.
The stock firmware felt super snappy (lower latency) and higher wi-fi speeds. The only I was getting periodic loss of connectivity on port forwards, as if there was a crash loop.
Even the /tmp/dhcp.leases file can be retained during a sysypgrade if it's listed in /etc/sysupgrade.conf?
Pfft, I feel totally dumb now. I swapped my router last night @3:00 am with an AP by loading settings from the config files from the first router to the AP, I forgot to remove the static lease for the AP and now had different MAC addresses between the LAN and WAN interfaces, the "new" router set its mac address for the LAN interface to that of the AP due to the static lease.
Fixed now and getting 900+ Mbps wi-fi on the arix00 NSS image.
1 Like
I think /etc/sysupgrade.conf simply tells openwrt which files to put into the backup archive, so in principle /tmp/dhcp.leases can be retained this way but I have not checked... Scratch the question mark, I just checked and /tmp/dhcp.leases is in the archive, so yes you can do it.
On the other hand, I would think that /tmp/dhcp.leases is not supposed to survive a reboot, so it is not clear to me that it makes sense to back it up. But maybe there are configurations where that's useful.
1 Like
It is needed for the nodes to display the mesh names on the wireless and status pages or else you will end up with a '?' for the host.
Btw, thanks for testing that /tmp/dhcp.leases survives the firmware upgrade.
I would think that as long dhcp.leases survives the reboot, it will also survive an upgrade.
Alternatively, can you have a startup script that writes the needed values into /tmp/dhcp.leases? Yet another approach could be pulling/pushing dhcp.leases file between between nodes by running (appropriately modified) scp command on the reboot of each node (or main router).
It's meant to be transient. I would advise against backing up /tmp/dhcp.leases. If you want static addresses, define them properly in /etc/config/dhcp and let the clients request it themselves. dnsmasq will sort the rest.
Just use the hotplug script I wrote here. Modify it to your setup.
It will automatically push the lease file to the child nodes whenever a client requests an IP.
@qosmio and I went over that in detail here and am using his hotplug script.
The problem is that the nodes + master's MESH interface's host name doesn't propagate as they are NOT in the lease file. That's why you will see '?' under hosts in the associated stations for ONLY the mesh nodes. I went over this in detail with @qosmio and don't have the energy to rehash them again.
@qosmio - the problem with the hotplug script is that unless a new host requests an IP, the script will not kick in and that's why I was thinking of retaining the dhcp.leases file. When a NODE reboots, the dhcp.lease file doesn't get pushed using your hotplug script unless a client joins the network. In my case, all my devices have a STATIC IP addresses in the /etc/config/dhcp file. So, there won't be any new clients requesting an IP.
You can also just schedule a cron job that manually executes the hotplug script every X minutes.
Clients will still request an IP when connecting to the network (i.e. kicked off due to a node rebooting, manually kicked, or when its lease expires). Static IPs defined in /etc/config/dhcp simply reserves that IP for a particular MAC.
If your setup is small and your devices don't cycle MAC addresses, then you could back up lease file and include it in your build. But not in /tmp directly. It would need to be a custom script that moves it over after boot.
1 Like
Currently, I have it setup as a cron job only, which runs every 4 hours and once during the reboot.
I get your point about /tmp/dhcp.leases and was just curious... that's all. I am not planning to put it in /etc/sysupgrade.conf as the cron job takes care of it now.
1 Like
Are there any recommended update procedures for NSS? I compiled qosmio's latest build, but it won't connect to my mesh unless I plug in to the lan port, manually define an IP, and connect into the router to restart my network interface. Should I use sysupgrade in luci? Or should I boot back into the OEM firmware and overwrite the openwrt partition with a new build?
@qosmio, was wondering if you are planning for a fix for this issue on nss build without suggested workarounds.my scenario is few dumb OpenwrtAPs (and few vlans) with wired backhaul to a switch trunked to a router.
All:
on a separate issue, i have a mDNS reflector container running on mikrotik router, passing traffic from my streamingVLAN(roku) to homeVLAN(where phone devices connect to). i see bridge loop issues related to reflector which was not present in the past prior to introduction of mx4300 AP's (source MAC address of the packet that caused the loop detection is router bridge mac). any insights would be appreciated (already enabled STP/RSTP in all switch/devices/bridges) when we introduce multiple AP's (multiple paths?)
@qosmio The latest kernel 6.6.52 works pretty good, which I compiled Sunday morning, as the previous kernel was fine but had hiccups on my stock screener app. 6.6.52 seems to have fixed it for now as I have been looking at the streaming platform for the past couple of hours and no such issues so far. Thank you so much for keeping up to date.
Btw, this morning I saw quite a few commits from yesterday. So, I pulled the latest, compiled, and installed it. The images seems to work fine but I was unable to Reboot the router. Even reboot command from SSH seems to have NO effect whatsoever. So, I reverted to yesterday's build and works fine. Just curious why I am unable to reboot the router or the reboot process is broken with your latest commits?
Just wanted to chime in that reboot works fine for me. I am testing his repo as well, and cli as well as luci reboot are working fine for me with his latest commits as of yesterday evening.
Maybe you have something adding in your .config that's causing an issue? Maybe forgot to do a defconfig with the new commits (not that it should break reboot)? Perhaps you could try a clean build using his seed file with the latest commits. Then start adding your modifications one by one to see where it goes off the rails.
1 Like
Nah... It's automated and goes through all the steps in order. Something is wrong. I flash back the previous version from yesterday and it works. Let's wait for what the boss @qosmio has to say. 
Are there any pending commits for you? Mine is the latest and that's what I used to build it.
Nope, I am current with his 4300 branch.
EDIT: I take that back, I am current with him as of last night and as of the time I posted to you. Looks like he's just within the past hour sync'd again and has a new base. I have not tried that.... I don't think you have either since you reported your issue a few hours ago. Give it a whirl?
EDIT2: And again he's just based as of 1 minute ago.
I'm going to give him an hour or two and see if it stabilizes, don't want to catch him in the middle.
Not sure, my build doesn't exhibit that problem on a mix of Dynalink (x1), MX5300 (x2) and MX4300 (x5).
Somewhere in the shutdown process a service is either hanging or failing to shutdown properly. If the reboot command doesn't kick your session out you can try opening another session and tail logs before issuing a reboot.
logread -l40 -f
1 Like