Just a heads up to anyone installing this snapshot (squashfs-factory.bin), this snapshot doesn't seem to have opkg installed. It doesn't serve on the web URL either. I had to ssh and flip the boot partition to stock, reinstall arix00's release.
Something that tells me this is not a one-time thing is that arix00's snapshot is 7mb more than the one from this snapshot.
Edit: Hmm, if the current release using OPKG, why did the ssh welcome message tell me that apk is being used now?
Hate to ask, but could you post some screenshots of your config? I have 4 of these myself and I am trying to get them flashed and setup in a mesh. Specifically I am looking to setup radio0 as the backhaul like you did, I have found another post detailing this process somewhat; but I am still trying to wrap my head around it.
Has anyone seen DHCP issues using the MX-{4200,4300} running on 24.10-SNAPSHOT when bridging WLAN and VLAN interfaces? I'm seeing an issue that sporadically causes wireless clients that connect to the MX4300 dumb AP to not receive DHCP responses and therefore fail over to a 169.254.x.x zeroconf style address.
Of course, it happens more often when I don't have debugging / packet capture enabled, but in almost all cases the DHCP response can be seen on the AP's WAN interface (which I'm bridging into br-lan since this is an AP), but just never makes it to the bridge or possibly doesn't make it to the wireless client itself.
This sounds very much like https://github.com/openwrt/openwrt/issues/11650 and https://github.com/openwrt/openwrt/issues/13756, but I haven't had a chance to dig into the bridge state before/after such events.... just discovered those tickets late last night after being frustrated with the flaky DHCP requests all of a sudden becoming less flaky as soon as I started running tcpdump on all interfaces in the chain up to the WLAN.
My /etc/config/network:
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option packet_steering '1'
config device
option name 'lan1'
option macaddr 'my:ma:ca:dd:rr:3e'
config device
option name 'lan2'
option macaddr 'my:ma:ca:dd:rr:3e'
config device
option name 'lan3'
option macaddr 'my:ma:ca:dd:rr:3e'
config device
option type '8021q'
option ifname 'wan'
option vid '1'
option name 'wan.1'
config device
option type '8021q'
option ifname 'wan'
option vid '3'
option name 'wan.3'
option ipv6 '0'
config device
option type '8021q'
option ifname 'wan'
option vid '5'
option name 'wan.5'
option ipv6 '0'
config device
option type 'bridge'
option name 'br-lan'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'wan.1'
option igmp_snooping '1'
config interface 'lan'
option proto 'static'
option device 'br-lan'
option ipaddr '192.168.1.253'
option netmask '255.255.255.0'
option gateway '192.168.1.1'
list dns '192.168.1.2'
list dns '192.168.1.6'
list ip6class 'lan6'
option delegate '0'
config device
option type 'bridge'
option name 'br-iot'
list ports 'wan.3'
option ipv6 '0'
option igmp_snooping '1'
config device
option type 'bridge'
option name 'br-guest'
list ports 'wan.5'
option ipv6 '0'
option igmp_snooping '1'
config interface 'iot'
option proto 'none'
option device 'br-iot'
config interface 'guest'
option proto 'none'
option device 'br-guest'
config interface 'lan6'
option proto 'dhcpv6'
option device '@lan'
option reqaddress 'try'
option reqprefix 'auto'
option norelease '1'
option ip6assign '64'
list ip6class 'lan6'
config device
option name 'wan'
option macaddr 'my:ma:ca:dd:rr:3e'
(yes, there is nothing bridged into the IoT network, because I started testing the primary WLAN bridge and the guest bridge and was seeing DHCP requests timing out)
NOTE: firewall, dnsmasq and odhcpd all disabled since this is a dump AP after all.
It is really as simple as selecting 802.11s in dropdown menu when setting up radio0. I was really surprised. I spent the most of my time educating myself to understand how "mesh" is just a buzzword.
Here's something with screenshots: https://www.tekovic.com/blog/openwrt-80211s-mesh-networking/
Thank you for letting me know. Is there a squashfs-factory.bin file that also has opkg? I am trying to install kmod-batman-adv and apk doesn't seem to have one. If I install the sysupgrade.bin, it will overwrite the OEM firmware (MX4200 uses dual partition, with round-robin), and I don't want to do that. I would like to install an image with opkg via the factory fw.
I don't know what packages squashfs-factory.bin have since those are generally only used for the first install. But since you have a snapshot installed, you can use sysupgrade -s to install on the same partition.
Thanks a lot! Ended up using the snapshot in the custom firmware builder with batman-adv specified in the installed packages field and then used sysupgrade -s [filename] to install onto the same partition. And Luci works!
Have not been following for a while, still running build I built in October, from NSS branch (mac80211 6.11). Thinking about upgrading - which branch is considered most stable?
Older builds had issue with connection sometimes frozen (mostly on Mac) - I had better luck with NSS build vs FOSS. Has this been solved on SNAPSHOT?
Any advantages of using NSS builds from stability prospective? Have VLAN configs been fixed on NSS branch? Which NSS branch to use for MX4300?
This will run dumb AP with wired backhaul, fast roaming and VLANs.
@Ka6uka -
ive had 3 MX4300 AP with wired backhaul, and a 4th AP with WDS backhaul, runninng for months. for my space, with about 5 fixed-location stremaing devices and many devices that roam with less-demanding bandwidth requirements, i've found the most reliable consifuration to be on the FOSS drivers. i htink the things that interfere with client function are more typically lags when moving around, which depend on band-switching and roaming.
the NSS builds typically have a little faster raw transfer speed, but i have yet to overcome the issue of undesired client isolation, where wirelss clients can only see the current AP and upstream router devices.
i've tried DAWN to help with roaming but havent found a big advantage, and that would depend on overcoming the isolaiton issue with NSS builds.
i've tried new NSS builds (on qosmios'basic) every week or so but my limiation is the client isolation, and the many tricks in this long thread have not been continuously successful for me.
I'm doing 802.11s mesh (so wireless backhaul) and it's been pretty stable for me, with good handoff between APs. No DAWN.
I assume your mobility domain values match between APs? What's your "reassociation deadline" value? Are any of these devices using WPA3-SAE? I have read that WPA3-SAE might need "disassociate on low acknowledgement" and "generate PMK locally" disabled, though I haven't and several of my roaming devices use WPA3.
Are your 5GHz and 2.4GHz SSIDs different? I know it's common practice to have them on the same SSID, but my experience is that it causes more issues than it solves since most roaming devices like phones and laptops can handle different SSID connections just fine. If you set your beacon interval to be higher with the 2.4GHz network, though, that should also help the roaming devices choose the 5GHz network over the 2.4GHz network assuming a decent signal.
Last thing: what your disconnect and stay values? I think I changed mine to -90 and that made a big difference.
Since I had issues with the release on my MX4200V1, crashing out of memory, I've sysupgraded to the NSS build by Agustin Lorenzo. It hasn't rebooted yet for over a day, which is actually more than what the release would stay up for with 5 SSIDs. I have software offload enabled along with NSS as I saw it improved routing speeds. Memory is usually stable at 75% (contrary to the 90% it reached with release).
I have 3 AP, with somewhat overlapping coverage. While couple of times I had issues which could be related to roaming, most frequent (still rare) issue is when my MacBook's network will freeze (still showing as connected). Changing to another WiFi solves it.
Overall, I've been pretty happy with this build, no need to reboot (though for variety reasons my uptime is usually less than 2 months) - the only reasons I' considering upgrade are potential drivers update and the fact that I can't update/install packages anymore. Both are non-issues for me really.
Just tried snapshot. Not sure if these are known issues, but ..
build system would throw errors trying to generate custom image using default list of packages.
Prebuild sysupgrade image works, but it did not include Luci. Luckily Luci installed easily and everything was fine initially, but...
Still getting connection freezes, which seem even more frequent / annoying than I remember them having. In particular, before they would mostly occur on resume from sleep (and very infrequently during activity) - not the case anymore. Not related to roaming - my Mac is connected to the single SSID / single radio.
Yup, had to do this too to overwrite the alternate stock firmware. Good news is that you only have to do this once and sysupgrade should work from now on after both partitions are on OpenWrt.
The failsafe mode boot also works as an alternative to 30/30/30.
Commits for MX4200 and MX4300 show installation on both partitions, and doing this clearly reduces problems with upgrades and possibly other things.
While I understand the motivation to keep one partition oem to allow a dual-boot system, I wonder how many of us are frequently switching back and forth in practice. Re-installing oem is pretty easy in any case, so it's no big loss to get rid of it.