Do you have enabled "Multi To Unicast" in all WiFi interfaces?
This was all via wired, hence my question about LAN/WAN interface MACs.. I didn't even have WiFi on (which possibly made all this more difficult, but I have too many devices in my "lab" to keep WiFi on unless I'm actively using the device for something).
even more weird... not sure what to check besides the syslogs
This is exactly how the MAC addresses for interfaces are set in OEM firmware. The configuration has been transferred 1:1.
I think as long as DSA is not here it shouldn't be a problem.
You can set different MAC addresses for the interfaces and see if it makes any difference.
1 Like
Thanks @lytr, that's good to know. Clearly you can see I didn't spend any time with the factory firmware 
Next time I see this happen I'll get a capture of the system logs, or maybe even wire up the serial connection and see what's going on there... it took > 5 mins for me to be able to get an SSH connection to the router after power on last time, and after a lot of fiddling with the client (but none with the router, since I couldn't access either SSH or LuCI), eventually the SSH connection was established fine. The whole time OpenWRT looked to be running since I could see the blue light doing the heartbeat blink.
I just bricked my Linksys HomeWRK when upgrading to yesterday's SNAPSHOT (r28779-6605e45676) and I'm looking for advice on de-bricking.
When I turn the device on the LED doesn't do the normal blinking during boot, it is just a solid blue LED as soon as it is turned it on.
I have tried turning it on for 10 seconds, shutting it off, and repeating 3 times.
I have tried failsafe mode:
https://openwrt.org/docs/guide-user/troubleshooting/failsafe_and_factory_reset#failsafe_mode
You probably experienced this issue: https://github.com/openwrt/openwrt/issues/17897
If you have previously added booting from USB to u-boot env, you can start the initramfs image this way. If not, you need to connect the serial.
2 Likes
The issue @lytr pointed to has just been fixed with this commit, but you'll need to wait for the images to rebuild get the fix in your next image.
2 Likes
Same fault after upgrading yesterday but with an ipq807x/DL-WRX36.
I foggily remember to have USB boot configured, it was just as FA32 formatted flash drive with an initramfs on it, right?
It depends on how you have it set up. Whether you use fatload or bootusb.
Thank you. Unfortunately I did not set up USB Recovery and so I will need to connect via serial.
While I'm waiting for the new build to complete, I would like to set up USB Recovery on my other HomeWRK AP.
Are the two commands below what I should run?
fw_setenv bootusb 'usb start && usbboot 44000000 0 && bootm 44000000'
fw_setenv bootcmd 'run bootusb; bootipq'
Many thanks to all for getting this running on the MX4200v1.
I've noticed high memory usage leading to the device restarting on the stable build. Disable Luci/http server, added zram package and it still reboots after around 24-30 hours.
Zerotier installed for site to site networking, 2 vlans are in use, and using standard wireless packages.
Anyone else had similar issues? I can't pinpoint where the memory is actually being used.
Got it to boot initramfs with fatload. I have scanned through the available documentation, all instruct me to just flash a new firmware.
Is there a way to retain the current config and package selection or do I have to overwrite it?
I cloned the device page for the MX4200 into a new MX4300 page. It's pretty rough so if you would like to help clean it up, please do so here:
4 Likes
[UPDATE2: Make that sort-of working. Sometimes the DHCP responses to the wireless client just appear to be missing, and other times DHCP completes fine and then everything works A-OK. There were definitely some hostapd errors in the log before ("Failed to set beacon parameters"), so I went back to disabling 802.11r and Cell Density, but am seeing flaky results without either of those options set as well]
[UPDATE: Got everything working, so I suspect either some residual state that needed a reboot to clear, or an older 24.10-SNAPSHOT build with some issues still running since I did have to reboot back to the alternate root after screwing up the config initially...Config is basically the same as here.]
I've finally got my MX4300 (running the 24.10 backport of the FOSS code, no NSS) connected to my real home network (vs my lab network), and am having trouble getting VLANs + Wifi to play well together in a dumb AP configuration:
Here's my config: /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 '80:69:1a:xx:yy:z'
config device
option name 'lan2'
option macaddr '80:69:1a:xx:yy:zz'
config device
option name 'lan3'
option macaddr '80:69:1a:xx:yy:zz'
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'
config interface 'lan'
option proto 'static'
option device 'br-lan'
option ipaddr '192.168.1.xxx'
option netmask '255.255.255.0'
config interface 'lan6'
option proto 'dhcpv6'
option device 'br-lan'
option reqaddress 'try'
option reqprefix 'auto'
option norelease '1'
config device
option type 'bridge'
option name 'br-iot'
list ports 'wan.3'
option ipv6 '0'
config device
option type 'bridge'
option name 'br-guest'
list ports 'wan.5'
option ipv6 '0'
config interface 'iot'
option proto 'none'
option device 'br-iot'
config interface 'guest'
option proto 'none'
option device 'br-guest'
and /etc/config/wireless:
config wifi-device 'radio0'
option type 'mac80211'
option path 'platform/soc@0/c000000.wifi'
option band '5g'
option channel '36'
option htmode 'HE80'
option country 'US'
option cell_density '0'
config wifi-iface 'default_radio0'
option device 'radio0'
option mode 'ap'
option ssid 'OpenWrt'
option encryption 'psk2'
option key 'notmypassword'
option ieee80211r '1'
option ft_over_ds '0'
option ft_psk_generate_local '1'
option ieee80211w '1'
option ieee80211w_max_timeout '20000'
option ocv '0'
option network 'lan lan6'
config wifi-device 'radio1'
option type 'mac80211'
option path 'platform/soc@0/c000000.wifi+1'
option band '2g'
option channel '6'
option htmode 'HE20'
option country 'US'
option cell_density '0'
config wifi-iface 'default_radio1'
option device 'radio1'
option mode 'ap'
option ssid 'OpenWrt'
option encryption 'psk2'
option key 'notmypassword'
option network 'lan lan6'
config wifi-device 'radio2'
option type 'mac80211'
option path 'platform/soc@0/c000000.wifi+2'
option band '5g'
option channel '100'
option htmode 'HE80'
option country 'US'
option cell_density '0'
config wifi-iface 'default_radio2'
option device 'radio2'
option mode 'ap'
option ssid 'OpenWrt'
option encryption 'psk2'
option key 'notmypassword'
option ieee80211r '1'
option ft_over_ds '0'
option ft_psk_generate_local '1'
option network 'lan lan6'
This same config works great on my ipq806x systems (though w/out a switch so just eth0 and eth1 in the bridges vs lanX & wan), and it works fine if I connect to the LAN ports via a wired connection... but getting the bridge to connect to the Wifi does not -- clients that connect to the Wifi being provided send DHCP requests but I don't see any response coming back.
I see a lot of these types of questions upthread in ~ August of last year, but they mostly seem to be focused on the NSS build. This is all FOSS.
Anyone confirm/deny that this type of setup works for them, and if so, suggest what change I should make to make it so? Router is connected to a trunk port on my core switch via the wan interface, with VLANs 1 (main lan), 3 (IoT) and 5 (Guest network) available and tagged.
Thanks!
post output of /etc/config/dhcp
It's a dumb AP, so firewall, dnsmasq and odhcpd are all disabled per /etc/rc.local:
# these services do not run on dumb APs
for i in firewall dnsmasq odhcpd; do
if /etc/init.d/"$i" enabled; then
/etc/init.d/"$i" disable
/etc/init.d/"$i" stop
fi
done
exit 0
But in br-lan I can only see VLAN-1... should not be the others too? because they need to travel upto core swtich to get DHCP...
The other VLANs have their own bridges, e.g. br-iot / br-guest, that are then bridged with the appropriate SSIDs, and bound to the other VLANs (3 = iot, 5 = guest). Not fully represented here because I'm trying to get it working on VLAN 1 before debugging the others, but the pattern is the same, except the IoT and Guest VLANs don't get bridged into the switch ports.
I gave up on MX4200v1 because it eventually runs out of memory and dies. In fact, in my case most of the time it does not even reboot but just stops functioning (or does it extremely slow). I see SSIDs but can't connect, I can ping it sometimes but it's very slow etc.
I have one more MX4200v1 that seems to be running fine as a dumb AP (though with wds to upstream router) but possibly it only works because it never has more than 2 clients.
I also have MX4300 and I noticed that memory usage is similar (not surprising since they are almost identical) but thanks to the insane amount of memory MX4300 has, it is running just fine. MX4300 is the main router at the location where it's at and it has a reasonable number of wireless clients. Similarly, I have MX5300 which may be similar enough to make a comparison. This one has twice as much memory as MX4200v1 and this seems to be enough for it to work fine (but compared to MX4300 it has light duties - it has a number of clients connected but it is just a wired dumb AP).
P.S. Try adding physical swap (i.e. on USB stick, not z-ram). It seemed to help with one of my MX4200v1's for a while (I had it running as a main router for a couple of weeks but than after minor configuration changes it started crashing again).