Thanks and will post the log if I encounter it as I flashed the previous version of the build and it works fine for now. I see that you are super busy with lots and lots of commits since y'day and will start the build once the commits have settled... somewhat. 
Can somebody with the OEM version of an MX4200v2 send me the output of the following commands?
strings /dev/mtd20 | grep 'mfg_data_version\|modelNumber\|hw_version\|hw_revision\|cert_region\|manufacturer\|modelDescription\|devinfo_version\|sw_version'
strings /dev/mtd20 | cut -d "=" -f 1
I'm investigating full debranding of the ISP variants.
It looks like they are back on sale over at woot. They haven't managed to clear everything out yet.
https://computers.woot.com/offers/linksys-ln1301-wifi-6-router?utm_medium=share&utm_source=web
You can get the first one for $15 and additional units for $20.
3 Likes
I built your latest changes and flashed it now and all good. Reboot works fine.
Yes, ordered the 4th one today. Get a 5th one or not is the question on my mind now but I absolutely, positively do NOT need more than 3. Must resist! Must resist! lol
Can we rebuild using this method?
#!/bin/sh
CDBU=$(date +"%F_%H%M%S")
BAK="../abu/$CDBU"
mkdir -p "../abu" # Ensure backup directory exists
cp .config "$BAK"
rm -rf bin build_dir tmp
git pull
./scripts/feeds update -a
./scripts/feeds install -a
./scripts/diffconfig.sh > configdiff
cp configdiff .config
make defconfig
make oldconfig
make -j$(nproc)
The difference between this configdiff and qosmio's nss seed (config.nss.seed) are huge. There are tons of things that are different and not sure what you will get if you took the configdiff and compiled and flashed it?
Are you doing make clean all the time when rebuilding?
No, I'm not.
Got it, thanks for clarifying! Are there any specific steps to speed up the rebuild process?
Only the first build takes time. About 1h or so. Subsequent git pull + build takes about 20 minutes or so for me.
Hi, I am currently using MX4300 qosmio version firmware with NSS support, I noticed one weird issue: The ipv6 broadcast packets got dropped by radio 2. Specifically, devices on the 5G wifi radio did not get ipv6 connectivity, since the router cannot find the device MAC address of a given ipv6 with NDP. This issue can be a workaround by setting option multicast_to_unicast_all '1' in /etc/config/wireless. May I know if anybody has a similar issue?
Here is a full version of the config that was not working:
config wifi-device 'radio0'
option type 'mac80211'
option path 'platform/soc@0/c000000.wifi'
option band '5g'
option channel 'auto'
option htmode 'HE80'
option cell_density '0'
option country 'US'
option txpower '24'
option disabled '1'
config wifi-device 'radio1'
option type 'mac80211'
option path 'platform/soc@0/c000000.wifi+1'
option band '2g'
option channel 'auto'
option htmode 'HE40'
option cell_density '0'
option txpower '30'
option noscan '1'
option country 'US'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'NAME'
option encryption 'psk2'
option key 'SECRET'
config wifi-device 'radio2'
option type 'mac80211'
option path 'platform/soc@0/c000000.wifi+2'
option band '5g'
option channel '161'
option htmode 'HE80'
option txpower '24'
option country 'US'
option cell_density '0'
config wifi-iface 'default_radio2'
option device 'radio2'
option network 'lan'
option mode 'ap'
option ssid 'NAME'
option encryption 'sae-mixed'
option key 'SECRET'
option ocv '0'
config wifi-iface 'wifinet3'
option device 'radio0'
option mode 'ap'
option ssid 'NAME'
option encryption 'sae-mixed'
option key 'SECRET'
option ocv '0'
option network 'lan'
Here is /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 ula_prefix 'fd01:6a38:a437::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
config device
option name 'lan1'
option macaddr '80:69:1a:21:aa:36'
config device
option name 'lan2'
option macaddr '80:69:1a:21:aa:36'
config device
option name 'lan3'
option macaddr '80:69:1a:21:aa:36'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config device
option name 'wan'
option macaddr '80:69:1a:21:aa:36'
config interface 'wan'
option device 'wan'
option proto 'dhcp'
config interface 'wan6'
option device 'wan'
option proto '6rd'
option peeraddr '205.171.2.64'
option ip6prefix '2602::'
option ip6prefixlen 24
option ttl 255
option mtu 1472
option ip6assign 64
Do you want to use Linksys software? In OpenWrt it won't change anything, only different MAC addresses are used.
Primarily, it's for dual-boot configurations with OpenWRT on one partition and Linksys on another. Even when you run Linksys' firmware on an ISP-branded device, it still offers you to upgrade to your ISP's version if it's newer.
I want to investigate that a bit more and I reckon it's all down to the values in devinfo. It'd be interesting to see if it's possible to go from one ISP to another by manipulating those and sniff firmware upgrade URLs and so on. Those could contain newer versions of the wireless firmware for example which in turn could be used by OpenWRT.
I'm having a different issue: I use it as a dumb AP. All devices are isolated(can't ping each other) and the solution is to check "multicast to unicast" option. It actually affects both FOSS and NSS firmware.
Exactly the same issue as Clients in same WLAN can't reach each other - #47 by BlueSky
2 Likes
@qosmio Wow, I hit the max throughput on my link (500/500 Mbps) with the latest NSS changes and am amazed that I could get this on a desktop wired to a wireless node, which is about 50 feet away from the main router and multiple walls in between, is insane!
Thank you and the team for making it happen!
2 Likes
Hi, can you share your build? I'm not that good building and I'm using Arix but stuck on .50 kernel
I made a build for the first time yesterday.
Used the following:
Build environment (I used Ubuntu)
https://openwrt.org/docs/guide-developer/toolchain/install-buildsystem
Instead of make on the last line use
make V=s -j$(nproc)
Was done in approx 20 mins, but it was on a 8 core processor
3 Likes
Anyone experiencing high latency on local network? I'm using the latest NSS firmware, and the router is operating as a dumb AP.
Outbound traffic is very good:
% ping www.google.com -c 10
PING www.google.com (142.250.65.228): 56 data bytes
64 bytes from 142.250.65.228: icmp_seq=0 ttl=58 time=9.345 ms
64 bytes from 142.250.65.228: icmp_seq=1 ttl=58 time=8.249 ms
64 bytes from 142.250.65.228: icmp_seq=2 ttl=58 time=10.681 ms
64 bytes from 142.250.65.228: icmp_seq=3 ttl=58 time=13.021 ms
64 bytes from 142.250.65.228: icmp_seq=4 ttl=58 time=13.324 ms
64 bytes from 142.250.65.228: icmp_seq=5 ttl=58 time=10.394 ms
64 bytes from 142.250.65.228: icmp_seq=6 ttl=58 time=12.533 ms
64 bytes from 142.250.65.228: icmp_seq=7 ttl=58 time=11.540 ms
64 bytes from 142.250.65.228: icmp_seq=8 ttl=58 time=13.077 ms
64 bytes from 142.250.65.228: icmp_seq=9 ttl=58 time=13.469 ms
--- www.google.com ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 8.249/11.563/13.469/1.736 ms
Local network is terrible:
% ping 192.168.1.123 -c 10
PING 192.168.1.123 (192.168.1.123): 56 data bytes
64 bytes from 192.168.1.123: icmp_seq=0 ttl=64 time=68.854 ms
64 bytes from 192.168.1.123: icmp_seq=1 ttl=64 time=85.281 ms
64 bytes from 192.168.1.123: icmp_seq=2 ttl=64 time=104.160 ms
64 bytes from 192.168.1.123: icmp_seq=3 ttl=64 time=22.008 ms
64 bytes from 192.168.1.123: icmp_seq=4 ttl=64 time=40.631 ms
64 bytes from 192.168.1.123: icmp_seq=5 ttl=64 time=59.927 ms
64 bytes from 192.168.1.123: icmp_seq=6 ttl=64 time=78.980 ms
64 bytes from 192.168.1.123: icmp_seq=7 ttl=64 time=97.574 ms
64 bytes from 192.168.1.123: icmp_seq=8 ttl=64 time=117.749 ms
64 bytes from 192.168.1.123: icmp_seq=9 ttl=64 time=33.609 ms
--- 192.168.1.123 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 22.008/70.877/117.749/30.177 ms
There's no interference issue
Also I have to enable Multi To Unicast otherwise all devices are isolated. Is that a chip/driver issue, or just something that can be simply fixed in the settings?
EDIT: Seems like this router doesn't like MacBook Pro (USI 339S00912). When testing my PC with Intel AX200, the latency is very stable (~2ms)
I'm on the latest and don't experience high latency.
But, I had trouble sysupgrading the latest changes from yesterday. I kept getting command failed thru' luci and did a sysupgrade -v ".img" from SSH but still wasn't clean. I had to reset and restore the configs and all good now. So, something looks wrong with the sysupgrade from y'day. I am NOT planning to flash it on my other 2 MX4300s and will wait for @qosmio to see whether he sees any issues.
root@MX4300-UPSTAIRS:~# ping 192.168.100.23 -c 10 --- LAN
PING 192.168.100.23 (192.168.100.23): 56 data bytes
64 bytes from 192.168.100.23: seq=0 ttl=128 time=2.205 ms
64 bytes from 192.168.100.23: seq=1 ttl=128 time=2.164 ms
64 bytes from 192.168.100.23: seq=2 ttl=128 time=2.942 ms
64 bytes from 192.168.100.23: seq=3 ttl=128 time=2.644 ms
64 bytes from 192.168.100.23: seq=4 ttl=128 time=2.255 ms
64 bytes from 192.168.100.23: seq=5 ttl=128 time=2.334 ms
64 bytes from 192.168.100.23: seq=6 ttl=128 time=2.263 ms
64 bytes from 192.168.100.23: seq=7 ttl=128 time=2.188 ms
64 bytes from 192.168.100.23: seq=8 ttl=128 time=2.347 ms
64 bytes from 192.168.100.23: seq=9 ttl=128 time=2.348 ms
--- 192.168.100.23 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 2.164/2.369/2.942 ms
root@MX4300-UPSTAIRS:~# ping www.google.com -c 10
PING www.google.com (142.250.115.105): 56 data bytes
64 bytes from 142.250.115.105: seq=0 ttl=58 time=6.848 ms
64 bytes from 142.250.115.105: seq=1 ttl=58 time=5.605 ms
64 bytes from 142.250.115.105: seq=2 ttl=58 time=6.615 ms
64 bytes from 142.250.115.105: seq=3 ttl=58 time=7.313 ms
64 bytes from 142.250.115.105: seq=4 ttl=58 time=7.168 ms
64 bytes from 142.250.115.105: seq=5 ttl=58 time=5.746 ms
64 bytes from 142.250.115.105: seq=6 ttl=58 time=7.937 ms
64 bytes from 142.250.115.105: seq=7 ttl=58 time=7.008 ms
64 bytes from 142.250.115.105: seq=8 ttl=58 time=5.615 ms
64 bytes from 142.250.115.105: seq=9 ttl=58 time=7.023 ms
--- www.google.com ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 5.605/6.687/7.937 ms