Zyxel NWA1123-AC pull request tested?

Hello there,

i have seen that there is a pull request for the Zyxel NWA1123-AC, URL: https://github.com/openwrt/openwrt/pull/4037

Has someone been able to test it yet? I began compiling but underestimated how long it would take (my linux box is an old intel dual core) and it is still compiling. Aren't there precompiled binaries?

I bulit it and have been running as my main dedicated AP for some weeks now -- about 6 SSIDs bound to 4 VLANs. I've given it a review -- the changes are a bit outside my core competence, but I researched them carefully -- but not being an OpenWRT committer my review won't release it for merge.

It'd be good if someone with repo write access would review it for release, it's a solid AP and the changes to support it are straightforward and uncontroversial.

Hi,

currently we use a NWA1123-AC with 1 untagged VLAN and two tagged VLANs which seems to work nicely so far.

We installed the *factory-AAOX.bin an own build based on https://github.com/openwrt/openwrt/pull/4037

As we wanted to try to use a more recent openwrt version this procedure is used to build the firmware files on Fedora 36:

* rm -rf openwrt/
* git clone https://github.com/openwrt/openwrt
* cd openwrt/
* git remote add github_s4 https://github.com/s-2/openwrt.git
* git fetch github_s4
* git checkout remotes/github_s4/nwa112x_master
* time make -j13 V=sc | tee run.log (slo tried -j1 )
* find . -name "*zyxel*.bin" -exec ls -l {} \;

Just to get a version where we know that another build works.

tar tvjf ./bin/targets/ath79/generic/openwrt-ath79-generic-zyxel_nwa1123-ac-squashfs-factory-AAOX.bin gives:

drwxr-xr-x user/user   0 2022-06-17 08:56 ./
-rw-r--r-- user/user 3368 2022-06-17 08:56 ./vmlinux_mi124_f1e.lzma.uImage
-rw-r--r-- user/user 8388608 2022-06-17 08:56 ./mi124_f1e-jffs2

bzip2: (stdin): trailing garbage after EOF ignored

./vmlinux_mi124_f1e.lzma.uImage is bz is far too small (all other .bin files as well) compared to the above mentioned change request and indeed the boot hangs with a de or uncompressing kernel message (from mind).

For the make menuconfig "only" the Target Profile was changed to NWA1123-AC (tried NI as well, same behaviour)

Is that perhaps not sufficient? So what do I oversee?

Any other suggestion(s)?

Thanks in advance.

Cheers,

...

This file only contains a loader image, since the current kernel is too big for the device's internal partition layout. The actual OpenWrt kernel + rootfs are contained in the jffs2 image file.

The device has been merged into OpenWrt master recently, it will be available with the official release version 23.xx. In the meantime, you could try downloading the snapshot from the OpenWrt website (however this does not contain the LuCI web interface).

Thanks. Then I at least do not have to do my own builds ;-).
Two APs are have the snapshots installed but appear not that stable (were quite stable with the first commit (at least a feeling I have)). I may have to keep an eye on them and regularly install actual builds.

There have been security issues with the wireless kernel drivers recently which were fixed a few weeks ago, maybe this is still a regression resulting from those changes, that might be fixed with newer releases soon. Since the commit in July 2021, there had also been the FragAttack fixes that caused a slight regression in throughput, as mentioned by another user on that PR, although those were not reported to affect stability, just throughput.

Thanks for this info.

A Windows 10 PC connects to these builds:
OpenWrt SNAPSHOT r22514-c8934099bf / LuCI Master git-23.093.56957-2145121
OpenWrt SNAPSHOT r23300-86bc525d00 / LuCI Master git-23.118.79121-6fb185f

looses connection from time to time though but reconnects in most of the cases.

Both hopefully use the same configuration. The SSIDs use VLANs.

Android phones (8.0, 12.0, 13.0) connect to the older version and loose the connection as well.

For the newer snapshot it needs quite a few tries to connect but typically the connection is lost after a few seconds.

If it connects. In most of the cases it just says connecting on the phone with no debug output on the AP.

A typical debug output is:

connect worked (Android 12):

Fri Jun  9 10:03:48 2023 daemon.notice hostapd: phy1-ap1: AP-STA-DISCONNECTED e8:78:29:c2:41:3a
Fri Jun  9 10:03:50 2023 daemon.info hostapd: phy1-ap1: STA e8:78:29:c2:41:3a IEEE 802.11: authenticated
Fri Jun  9 10:03:50 2023 daemon.info hostapd: phy1-ap1: STA e8:78:29:c2:41:3a IEEE 802.11: associated (aid 1)
Fri Jun  9 10:03:50 2023 daemon.notice hostapd: phy1-ap1: AP-STA-CONNECTED e8:78:29:c2:41:3a auth_alg=open
Fri Jun  9 10:03:50 2023 daemon.info hostapd: phy1-ap1: STA e8:78:29:c2:41:3a WPA: pairwise key handshake completed (RSN)
Fri Jun  9 10:03:50 2023 daemon.notice hostapd: phy1-ap1: EAPOL-4WAY-HS-COMPLETED e8:78:29:c2:41:3a

disconnected after a few seconds and then as debug output

Fri Jun  9 10:08:59 2023 daemon.notice hostapd: phy1-ap1: AP-STA-DISCONNECTED e8:78:29:c2:41:3a
Fri Jun  9 10:08:59 2023 daemon.info hostapd: phy1-ap1: STA e8:78:29:c2:41:3a IEEE 802.11: disassociated due to inactivity
Fri Jun  9 10:09:00 2023 daemon.info hostapd: phy1-ap1: STA e8:78:29:c2:41:3a IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)


Remark: I have the feeling that the debug output may just be that of log level 2 although it is set to 1:

logger_syslog=127
logger_syslog_level=1
logger_stdout=127
logger_stdout_level=1