Having trouble successfully flashing builds from the qualcommax-6.x-nss-wifi branch of @qosmio's fork on my two MX4200Cs. Haven't made any changes to build configuration other than enabling my target model (I selected MX4200v1 as it appears to be equivalent). After flashing the sysupgrade image through LuCI the router immediately reboots, and seems to hang - the top LED rapidly flashes green and a reboot after waiting quite a while makes it go to solid blue, but the router is completely unresponsive and doesn't respond to pings in either state. Don't have a serial adapter at the moment so unfortunately I can't provide much info on what is going on.
I was earlier able to flash them with @AgustinLorenzo's pre-built images however was unable to get mesh functionality working, for some reason I can't get the radios to turn on when configured for 802.11s - tried using radio0 and radio2 but it has the same behavior on either. Everything else I tested seemed to be fully functioning otherwise.
It's hard to say what could be failing without console access output. Have you confirmed you can switch back to previous version? Turn the power on and off 4 times, waiting around 3 seconds each in the "off" position.
Yeah I am able to revert back without issue fortunately.
Edit: I evidently glossed over the critical step of flashing a factory image to the alternate kernel partition before going through with any sysupgrades... Mesh setup is now fully working on @qosmio's fork. Thanks for the super helpful example config
Glad to hear! BTW, just pushed an update to the mesh example configs. Should now be fully working in sae-mixed (WPA2/WPA3) mode with fast transition (802.11r).
[52021.039797] Ignoring NSS change in VHT Operating Mode Notification from with invalid nss 2
[52234.124184] Ignoring NSS change in VHT Operating Mode Notification from with invalid nss 2
When I tried to connect to the network, I got the following logs:
root@OpenWrt:~# logread -f
Sun Oct 27 08:00:28 2024 daemon.info hostapd: phy0-ap1: STA MAC_ADRESS IEEE 802.11: authenticated
Sun Oct 27 08:00:28 2024 daemon.info hostapd: phy0-ap1: STA MAC_ADRESS IEEE 802.11: associated (aid 1)
Sun Oct 27 08:00:28 2024 daemon.notice hostapd: phy0-ap1: AP-STA-CONNECTED MAC_ADRESS auth_alg=open
Sun Oct 27 08:00:28 2024 daemon.info hostapd: phy0-ap1: STA MAC_ADRESS RADIUS: starting accounting session 349CBDF13C33EED0
Sun Oct 27 08:00:28 2024 daemon.info hostapd: phy0-ap1: STA MAC_ADRESS WPA: pairwise key handshake completed (RSN)
Sun Oct 27 08:00:28 2024 daemon.notice hostapd: phy0-ap1: EAPOL-4WAY-HS-COMPLETED MAC_ADRESS
Sun Oct 27 08:00:29 2024 daemon.notice hostapd: phy0-ap1: BSS-TM-QUERY MAC_ADRESS reason=5(null)
Sun Oct 27 08:00:29 2024 daemon.notice hostapd: phy0-ap1: BSS-TM-RESP MAC_ADRESS status_code=6 bss_termination_delay=0
Sun Oct 27 08:00:46 2024 daemon.notice hostapd: phy0-ap1: AP-STA-DISCONNECTED MAC_ADRESS
Do you know what the problem might be? I have disabled the dnsmasq, firewall and odhcpd services on my dummy AP. And it looks like the dEADkIRK have a similar problem.
Notice: In the LUCI UI it is not possible to add the device config (br-dmz), but yes the network config (DMZ) , but I already tried both options but it does not work.
hye,i got an issues for new build nss repo by @qosmio .build clean compile for arcadyan aw1000..after flash no issues,but after i set networrk interface for quectel cellular..modem keep rebooting or kernel panic..hope develpor or other experienced can help me
I have been running 23.05 on my Xiaomi AX3600 so far, but decided to give these NSS builds a try since I use Wireguard and wanted also to setup Adguard. The problem I am facing with the NSS builds is that WiFi clients do not get an IP address. I have already started from scratch, by performing a fatory reset. Any idea what could be wrong here? Is there anyone with Xiaomi AX3600 running @AgustinLorenzo's builds?
The first two are unrelated to the panic. It occurred around 14h and 27mafter boot, while the panic occurred 8 hours after that warning.
Your error looks to be around here.
Which indicates likely a mix of overloaded # connections + kernel memory exhaustion. Are you running custom sysctl settings?
sort /etc/sysctl.d/* /etc/sysctl.conf
I should add those VLAN configs were mostly taken from @glassdoor and @Ka6uka's own configs here and here. I wasn't able to verify personally as my setup isn't isolated. I briefly tested with a guest vlan and it worked work me. Are you managing the VLANs on the router itself (dhcp) or a managed switch?
Can you try reverting to a previous version of the quectel.sh script?
On your router replace /lib/netifd/proto/quectel.sh with this file and try to connect again:
want to add that on mx4300 vlan config works in my dumbAP setup nss build. (setup vlan device, bridge device,create network interface on bridge, assign interface to SSID)
here's the output ... & thank you @qosmio for having a look
# /etc/sysctl.conf can be used to customize sysctl settings
# /etc/sysctl.conf can be used to customize sysctl settings
# /etc/sysctl.conf can be used to customize sysctl settings
# /etc/sysctl.conf can be used to customize sysctl settings
# Defaults are configured in /etc/sysctl.d/* and can be customized in this file
# Do not edit, changes to this file will be lost on upgrades
# Do not edit, changes to this file will be lost on upgrades
# Do not edit, changes to this file will be lost on upgrades
# Do not edit, changes to this file will be lost on upgrades
# disable bridge firewalling by default
# nf_conntrack_tcp_no_window_check is 0 by default, set it to 1
fs.protected_hardlinks=1
fs.protected_symlinks=1
fs.suid_dumpable=2
kernel.core_pattern=/tmp/%e.%t.%p.%s.core
kernel.panic=3
net.bridge.bridge-nf-call-arptables=0
net.bridge.bridge-nf-call-arptables=0
net.bridge.bridge-nf-call-ip6tables=0
net.bridge.bridge-nf-call-ip6tables=0
net.bridge.bridge-nf-call-iptables=0
net.bridge.bridge-nf-call-iptables=0
net.core.bpf_jit_enable=1
net.core.bpf_jit_kallsyms=1
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.default.arp_ignore=1
net.ipv4.icmp_echo_ignore_broadcasts=1
net.ipv4.icmp_ignore_bogus_error_responses=1
net.ipv4.igmp_max_memberships=100
net.ipv4.ip_forward=1
net.ipv4.tcp_congestion_control=bbr
net.ipv4.tcp_dsack=1
net.ipv4.tcp_fin_timeout=30
net.ipv4.tcp_keepalive_time=120
net.ipv4.tcp_sack=1
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_timestamps=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.default.forwarding=1
net.netfilter.nf_conntrack_acct=1
net.netfilter.nf_conntrack_checksum=0
net.netfilter.nf_conntrack_max=32768
net.netfilter.nf_conntrack_tcp_no_window_check=1
net.netfilter.nf_conntrack_tcp_timeout_established=7440
net.netfilter.nf_conntrack_udp_timeout=60
net.netfilter.nf_conntrack_udp_timeout_stream=180
root@dragonfly-qnap:~# cat /etc/sys
sysctl.conf sysctl.d/ sysfs.conf sysfs.d/ syslog.conf sysupgrade.conf
root@dragonfly-qnap:~# cat /etc/sysctl.
sysctl.conf sysctl.d/
root@dragonfly-qnap:~# cat /etc/sysctl.
sysctl.conf sysctl.d/
root@dragonfly-qnap:~# cat /etc/sysctl.conf .
.ash_history .config/ .ssh/ .wget-hsts
root@dragonfly-qnap:~# cat /etc/sysctl.conf
# Defaults are configured in /etc/sysctl.d/* and can be customized in this file
root@dragonfly-qnap:~# cat /etc/sysctl.
sysctl.conf sysctl.d/
root@dragonfly-qnap:~# cat /etc/sysctl.d/
10-default.conf 11-br-netfilter.conf 11-nf-conntrack.conf 12-tcp-bbr.conf qca-nss-ecm.conf
root@dragonfly-qnap:~# cat /etc/sysctl.d/12-tcp-bbr.conf
# Do not edit, changes to this file will be lost on upgrades
# /etc/sysctl.conf can be used to customize sysctl settings
net.ipv4.tcp_congestion_control=bbr
root@dragonfly-qnap:~# cat /etc/sysctl.d/qca-nss-ecm.conf
# nf_conntrack_tcp_no_window_check is 0 by default, set it to 1
net.netfilter.nf_conntrack_tcp_no_window_check=1
net.netfilter.nf_conntrack_max=32768
net.bridge.bridge-nf-call-arptables=0
net.bridge.bridge-nf-call-iptables=0
net.bridge.bridge-nf-call-ip6tables=0
There was a check added in kernel 6.9 that started enforcing IEEE Std 802.11-2020 - 9.4.1.53 Operating Mode field. Basically means that a station's NSS (number of spatial streams) should not exceed the maximum capability of the access point (AP) or what was negotiated initially. If a station signals a higher NSS , i.e. negotiating at 1x1 then requesting 2x2 for example, then it must be ignored or adjusted downwards.
I don't fully know why this is enforced esp if the AP in this case support 2x2 NSS. Assuming due to resource allocation and airtfime fairness. This issue is mostly related to Realtek and Mediatek chipsets.
I've filtered it out since the interfaces the offload disable script looks at are only physical and bridge interfaces. What you have showing looks ok.
Looks OK to me. The only thing I would suggest trying is changing the congestion control to cubic and testing again. I haven't really had much luck with BBR. Using NSS SQM + cubic has been pretty solid for me though.
