Hi @javykhan

Disable the service of mesh11sd and reboot.

Regards, Agustin

It's still not working.

Disabled mesh11sd in startup section and reboot, lost LAN access as well since Wifi was not working already. Did reset and back to meshnode with mesh11sd enabled. Any other way to disable and get proper boot?

Thats my issue also.
Im having lan access only for 10 seconds.
And then 192.168.1.1 is not reachable anymore
No luci no putty no scp

Hi @javykhan

You need to set an IP manually on your interface to be able to connect again.

Range: 192.168.1.0/24 (in clean installation)

Regards, Agustin

@AgustinLorenzo your builds are too unstable and too cluttered. Can you simplify the build please. We just want NSS. Not wiregurd, openVPN, Proxies etc.

LAN interface becomes pingable for few seconds and then goes off. So no access anyway.
By the way why we dont get NSS Wifi image without mesh11sd at first place?

Had to sysupgrade in failsafe mode to 23.05. There was no connectivity and failsafe was only option. This release is not okay at all. @AgustinLorenzo please help to fix the issue.

get into failsafe mode, scp some other release file from your local machine to /tmp/ and then sysupgrade -n

Fixed it by using MiWifiRepairTool and then again to openwrt...
What do you mean failsafe mode? It's good to know for the future

@javykhan, @eR2022 and @AgustinLorenzo

I think it's a problem for the AX6 only, because I just installed the latest build on my AX3600 and it's working (besides ofc that DHCP bug which is solved with uci set dhcp.lan.ignore=0)

The only thing I see on my log is the AP-STA-POLL-OK spam bug which is already known.

To enter failsafe mode on a Redmi AX6 router running OpenWrt, follow these steps:

  1. Ensure you have a wired connection to the router, as failsafe mode will disable wireless connectivity.
  2. Reboot the router and watch for the LED to start flashing rapidly; this indicates the router is ready to enter failsafe mode.
  3. During this LED flashing window, press and holdthe reset button for a few seconds until the LED starts flashing at a different rate, signaling that the router has entered failsafe mode.

https://openwrt.org/docs/guide-user/troubleshooting/failsafe_and_factory_reset

1 Like

I Wish I knew it few hours ago :rofl:
Thank you

1 Like

U can try this firmware.

https://openwrt.admincomps.ru/nss-wifi/

Thanks for the PR!

I made a comment about moving the empty sos/queue onto separate cores. It's shown to have instability with moving those requests between CPUs. This is similar to when moving any of the ce{1..11} IRQs for wireless.

I incorporated it into the latest overhaul-scripts branch for qca-nss-drv made a comment about moving the empty sos/queue onto separate cores. I incorporated your changes to detecting occurrence as part of an overall rework of nss-qca-drv management scripts.

Latest Commits - qca-nss-drv: Rework smp_affinity + Add nss_stats

2024-04-06 - ac967d3 - Merge branch 'NSS-12.4-K6.x' of https://github.com/qosmio/nss-packages into NSS-12.4-K6.x
2024-04-06 - 28a6d74 - Better handling of nss_queue + etc affinity (#22)
2024-04-06 - 41f1217 - qca-nss-drv: Rework smp_affinity + Add nss_stats

Changed:

1. `set_affinity` function moved outside of `enable_rps`.
2. Logic of `set_affinity` updated to use physical CPUs instead of the bitmask.
3. UCI options retrieval logic modified to handle missing options.
4. Updated path from '/lib/debug/qca-nss-drv' to '/usr/bin/nss_stats' for better accessibility.

Added:

1. Two new functions:
   a. `bitmask_to_cpus` - Converts CPU bitmask to a list of CPU numbers.
   b. `cpus_to_bitmask` - Converts CPU list to a bitmask.
2. UCI option `enable_log` introduced to control logging output to `logger`.

Removed:

1. Unused UCI options `nss_firmware *`.
1 Like
install: cannot create regular file '/home/andrew/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-qualcommax_ipq807x/qca-nss-drv-12.2-2024-01-04-89cc01b/.pkgdir/kmod-qca-nss-drv/usr/bin/nss_stats': No such file or directory

not sure why my system is like this

Try with latest commit:

looks like that worked, thanks!

1 Like

Is anyone else facing the problem you can't detect other devices on the same network?

Only Multicast to Unicast is fixing this problem..

@qosmio

great work, thanks!

just one thing to mention, i had a short convo with @rmandrad regarding:

# NSS Core 0 : 4 nss queues to each core

labeling these "nss core #", is this correct? sounds like nss core 1 is used only for crypto.... and doesn't get a queue? so that means core 0 gets 2 sets of queues? all beyond my pay grade lol.

are all nss_queue_* nss core 0?

edit : thats why i closed my first PR and in the 2nd one i change the terminology to "nss_queue set 1" etc.