Hi,
Quick question if anyone already had this issue since I'm at my wits end.
Since yesterday, no windows client is able to access my Wifi/LAN anymore. Every other device (tasmota esp modules, Steam Deck, Linux Desktop) does have full access. Even a TP-Link repeater works just fine. If I connect the windows clients using the Repeater WiFi connection, it works just fine.
I tried:
Activating/Deactivating Multi to Unicast
using different versions of openwrt (asvio, asvio nss build, normal build)
factory resetting the config
different encryption / password settings for the WiFi ssids
using LAN, the issue happens aswell
using different Windows clients (one XMG Neo, one Lenovo T15, one Asrock Deskmini) with different network cards (well, intel AX200 and AX201, seem close)
deactivating IPv6 under Network -> Interfaces -> Devices -> phy0-ap0 and phy1-ap0, br-lan did not help
My results:
If only radio0 (5ghz) is active, my windows clients sometimes get a connection by LAN and WiFi
The moment I turn on radio1 (2.4ghz), none of my windows clients get any connection (neither LAN nor WiFi)
It seems to be related to DHCP, but not entirely sure. I hope I didn't leave out any information that is needed, if I did, I'd be happy to provide it.
The system log adds the following entries on any connection attempt:
Wed May 15 16:01:15 2024 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) <my_mac_address>
Wed May 15 16:01:15 2024 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.178.217 <my_mac_address>
Wed May 15 16:01:15 2024 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) <my_mac_address>
Wed May 15 16:01:15 2024 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.178.217 <my_mac_address>
Wed May 15 16:01:15 2024 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.178.217 <my_mac_address>
Wed May 15 16:01:15 2024 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.178.217 <my_mac_address> Tankanickel
Wed May 15 16:01:15 2024 daemon.info dnsmasq-dhcp[1]: DHCPDECLINE(br-lan) 192.168.178.217 <my_mac_address>
Addition:
I also checked, if some IPs were distributed twice or something like that. That was not the case.
No issue on my side, I have a pair of windows clients connected without issues (apart from the needs of the settling of multi to unicast on all adapters, but that's true regardless of the STA os).
Can it be related to a recent patching of the OS (wifi driverr??) on your devices?
One device is in an MDM, so no updates there. The windows 10 client has some Win updates in the queue, but they are not installed yet. My main win machine is cut off from updates.
Fun part: if I set the static ip of the adapter to be the previously ACKed and declined one, I'm able to access everything. It's rather strange to see the IP getting ACKed and the declined right afterwards
Edit: Got the source of the problem. I added a repeater some time ago for a few devices on a different floor and that one seems to be duplicating packages, hence the issues. After removing it for a moment to test it out, the windows clients worked perfectly fine.
I've made a build. But it didn't work. I realized that the fan patches are for 6.1 only and are not applied during build. I moved the two kernel patches to 6.6 dir but no luck on this easy try. I'll integrate them manually now.
EDIT: To make it easier for others to comment on this topic here the patchfile for 6.6 regarding fan:
I've updated today to the latest snapshot and wifi is dead after flash. Last working builds I did were from 09.05. Don't have an exact number because I've deleted them already (as the build was succesfull xD).
[18/05/2024 13:47:06] ath11k c000000.wifi: ipq8074 hw2.0
[18/05/2024 13:47:06] ath11k c000000.wifi: FW memory mode: 0
[18/05/2024 13:47:06] remoteproc remoteproc0: powering up cd00000.q6v5_wcss
[18/05/2024 13:47:06] remoteproc remoteproc0: Booting fw image IPQ8074/q6_fw.mdt, size 668
[18/05/2024 13:47:07] remoteproc remoteproc0: remote processor cd00000.q6v5_wcss is now up
[18/05/2024 13:47:07] ath11k c000000.wifi: qmi ignore invalid mem req type 3
[18/05/2024 13:47:07] ath11k c000000.wifi: chip_id 0x0 chip_family 0x0 board_id 0xff soc_id 0xffffffff
[18/05/2024 13:47:07] ath11k c000000.wifi: fw_version 0x290604a5 fw_build_timestamp 2023-10-12 02:06 fw_build_id WLAN.HK.2.9.0.1-01977-QCAHKSWPL_SILICONZ-1
[18/05/2024 13:47:17] ath11k c000000.wifi: failed to fetch board data for bus=ahb,qmi-chip-id=0,qmi-board-id=255,variant=Zyxel-NBG7815 from ath11k/IPQ8074/hw2.0/board-2.bin
[18/05/2024 13:47:17] ath11k c000000.wifi: failed to fetch board data for bus=ahb,qmi-chip-id=0,qmi-board-id=255 from ath11k/IPQ8074/hw2.0/board-2.bin
[18/05/2024 13:47:17] ath11k c000000.wifi: failed to fetch board data for bus=ahb,qmi-chip-id=0,qmi-board-id=255 from ath11k/IPQ8074/hw2.0/board-2.bin
[18/05/2024 13:47:17] ath11k c000000.wifi: failed to fetch board.bin from IPQ8074/hw2.0
[18/05/2024 13:47:17] ath11k c000000.wifi: qmi failed to fetch board file: -12
[18/05/2024 13:47:17] ath11k c000000.wifi: failed to load board data file: -12
[18/05/2024 13:48:09] ath11k c000000.wifi: Coldboot Calibration timed out
The directory is empty and nothing is extracted at all.
Anyone the same and/or a hint which commit causing this?
Hi,
I'm trying add memory from dev/mmcblk0p11 for install extra packages (docker).
I'm using your built:
openwrt-.zyxel-nbg7815-with-led-fan-patch.-qualcommax-ipq807x-zyxel_nbg7815-squashfs-sysupgrade.bin
But still have error in log: Sat May 18 12:26:51 2024 user.info kernel: [ 16.972208] block: attempting to load /etc/config/fstab Sat May 18 12:26:51 2024 user.err kernel: [ 16.973033] block: unable to load configuration (fstab: Entry not found) Sat May 18 12:26:51 2024 user.err kernel: [ 16.976253] block: no usable configuration
I go through extroot configuration with extroot
but have different free space for / as /overlay and no additional memory added from dev/mmcblk0p11'
What else to do?
According to extroot configuration:
Note that OpenWrt is known to ignore the fstab configuration on devices without overlay partition in /proc/mtd . You can work around the issue by using / for the mount point on ROMs without overlay partition at all.
How exactly can I mount extra memory without an ovearlay partition?
Hmm. The board-2.bin file was the first I've checked in download directory. Sometimes things fail to download. But I think compile would have failed if the dl would not have been there. Maybe extraction error?
It seems that the recent APK commits somehow are breaking ipq-wifi as BDF-s dont get included with them, however as soon as I revert back to the last commit before them (The Tegra U-Boot one) and then it works again.
So its a matter of bisecting what exactly is breaking it
Hello, I do not know if this is the correct forum to ask this, since it is not an issue with the custom OpenWRT firmware, but the stock one based on openwrt. I've been experiencing issues with 160MHz on the stock firmware. When I set a 5G channel above 100 the router takes about 10 minutes to switch to this channel, and when it successfully switches, it will only stay on the channel for about 5 minutes before reverting back to channel 48.
I do have root access so the logs corresponding to this are these, at least I think:
root@NBG7815:~# [ 806.081798] ieee80211_dfs_deliver_event: dfs RADAR_DETECT event delivered on chan freq 5605.
[ 806.081846] ieee80211_dfs_deliver_event: dfs NOL_START event delivered on chan freq 5500.
[ 806.089335] ieee80211_dfs_deliver_event: dfs NOL_START event delivered on chan freq 5520.
[ 806.097391] ieee80211_dfs_deliver_event: dfs NOL_START event delivered on chan freq 5540.
[ 806.105552] ieee80211_dfs_deliver_event: dfs NOL_START event delivered on chan freq 5560.
[ 806.113703] ieee80211_dfs_deliver_event: dfs NOL_START event delivered on chan freq 5580.
[ 806.121873] ieee80211_dfs_deliver_event: dfs NOL_START event delivered on chan freq 5600.
[ 806.130028] ieee80211_dfs_deliver_event: dfs NOL_START event delivered on chan freq 5620.
[ 806.138191] ieee80211_dfs_deliver_event: dfs NOL_START event delivered on chan freq 5640.
[ 806.148720] wlan: [0:I:ANY] wlan_scan_update_channel_list: 1090: num_chan: 11
[ 806.154646] wlan: [0:I:ANY] ieee80211_dfs_action: 4116: Changing to HE160 non-DFS channel 48 (5240 MHz)
[ 806.164079] wlan: [5354:I:ANY] ol_acfg_handle_wifi_ioctl: 417: ol_acfg_handle_wifi_ioctl: req->cmd=75 not valid for radio interface, it's for VAP
Error received: -22
Could not send NL command
I think the dfs, which is enabled even when setting a static channel in the admin interface, is causing issues. Would anyone know a way to fix this?
The oem firmware is based on an modifyed outdated version of OpenWrt. Which isn't even close to OpenWrt. The default firmware is crap in many regards. That's why ppl. here are not using it. Beside that this is the wrong location asking for support oem firmware. Please use Zyxel's official support forum and pressure them to fix your issue.
Choosing 160MHz does only allow a small set of fixed channels. If I remember correct it were three only. 53, 108 and ?. The last one I don't remember. This might be wrong I cannot check what oem firmware is doing. So choosing "auto" would be the way to go or looking into settings what channels are free to choose. Maybe the log is giving you a clue.
I've made dualboot basically working. There are two things left on this basic work. I didn't use two functions from common.sh. Namely default_do_upgrade and get_image_dd for getting and writing the mtd partitions. They scared me off (especially the 1st one).
Because I've found out that I cannot write the kernel/rootfs first and then the bootconfig (what would be more save in my view). After calling the upgrade function for kernel/rootfs the system is rebooted no matter what. And do_upgrade sounds like one of those functions. I don't know whats called after. I have to less understanding about the scripts.
Is there interest in creating a PR about?
Personally I want it but I do not insist on creating a PR for it.
ATM I have no clue if this would get after it into the corresponding LuCI application. Because its very different to that what's done on other devices.
I've tested it extensivley. It's working reliable.
I'm interested as said in a previous post, it would give this device a more complete functionality and it would ease some pain in case of a botched build.
Having said that I'm a little more than an end user so I 'm unable to assist in anything more than some test and even then only on a semi finished product as the nbg7815 is my main (and only) router/AP...
What happens, when you flash a "broken" fw which crashes e.g. broken driver, is the some uboot magic, that will boot to the previous flashed build?
How do you switch in case the newly flashed build does not fully boot?
How do you revert to oem firmware.
I don't see a huge benefit, unless it can switch to previously working fw without a user needing serial access. E.g. linksys fw uses a boot counter the fw has to reset, after a few fails, boot will be switched.
Well the zloader is locked down and crap. There is no failsafe in practice. I've tested it by deleting kernel + rootfs with changing the bootorder. The system is just booting over and over again. There is nothing within nvmem which is written during boot. No partition or mtd device like dual_flag is written during bootloader/zloader phase. There is nothing.
If I could I would compile uboot new by cutting out the zloader reference. But that's beyond my skills.
It is true the benefit is small. But for testing it is quite convinient given that you usually don't fk up a system in such a way to not comming up again.
Hi all, I'm curious what your power consumption is.
I measured around 13W with radio 1 and 2 enabled, around 4 clients connected and nothing plugged into the USB or Ethernet ports. Disabling radio 2 and enabling radio 0 saves me around 0.5W but is considerable slower (700-800 vs 400-500 Mbit/s).
Someone in the thread reported about 8W so I'm wondering if something is wrong with my device.
I'm on OpenWrt version 23.05.3 with the latest updates installed.
I replaced wpad-basic-mbedtls with wpad-mbedtls and installed nano, iperf3 and luci-proto-batman-adv (+ dependencies) for my mesh.
My Xiaomi AX3600 needs ~7W with the same packages and clients while also providing ~800 Mbit/s. So the 13W are rather annoying and I'm hoping that I've just missed something to get to the 8W mentioned before.
I get that more features need more power, but currently I'm not even using most of them.
Will revert to a earlier date.