Qualcommax NSS Build

Community Builds, Projects & Packages
6507

@bahtsiz_bedevi fixed. If not i need script 6 output

6508

I'll test it right away

6509

to anyone who has 301w:
vanilla openwrt snapshot has the 10g port fix merged, but the 301w dts change is dropped, which means:

  1. if your 301w already have a .mbn file write to the ethphyfw1/2 (/dev/mtd11 && mtd12), i.e. you were using the aq_load_fw workaround, you need to KEEP that aq_load_fw in your bootcmd, removing it will give you a broken 10g-1/2;
  2. if you are still using the vendor/original FW, it should work with the latest SNAPSHOT without using that workaround;
  3. in thoery if we write the original .cld file back to ethphyfw1/2 and drop the workaround, the latest SNAPSHOT should work too, but I havn't tested that yet.
1 Like
6510

Why do 301w owners flash nbg images anyway?

6511

i replied to that on your commit ... openwrt qnap301w instructions that include loading the /dev/mtd1[0-1] with a firmware - https://openwrt.org/toh/qnap/301w?s[]=open&s[]=howto&s[]=file

1 Like
6513

@rmandrad they said use either this or that

image
image1502×710 66.8 KB

why would anyone use the github files, is something broken with stock?

1 Like
6514

AFAIK, that was introduced along with the aq_load_fw workaround...
at that time, the 10g port on 301w was broken while it was reported that it works on NBG board.
so people tried all sorts of combinations: change/flash aqr fw, load via uboot bootcmd, and settled with anything that "works"...

btw, I just tried: write the original AQR-G4_v5.4.C-AQR_CIG_WF-1945_0x{0,8}_ID44778_VER1630.cld file back to ethphyfw1/2 and drop the bootcmd workaround, it works with your latest commit 6029d0e

 -----------------------------------------------------
 OpenWrt SNAPSHOT, r35726-6029d0efc8
 -----------------------------------------------------
root@301W:~# 
root@301W:~# 
root@301W:~# 
root@301W:~# fw_printenv |grep cmd
bootcmd=bootipq
root@301W:~# 
root@301W:~# 
root@301W:~# dmesg |grep -i aqr
[    3.208755] Aquantia AQR113C 90000.mdio-1:00: loading firmware version 'v5.4.C CIG WF-1945_0x0 060120 02:47:48' from 'NVMEM'
[   17.127736] Aquantia AQR113C 90000.mdio-1:08: loading firmware version 'v5.4.C CIG WF-1945_0x8 060120 02:47:48' from 'NVMEM'
[   30.335985] qca-ppe 3a000000.ppe 10g-1 (uninitialized): PHY [90000.mdio-1:08] driver [Aquantia AQR113C] (irq=POLL)
[   30.354400] qca-ppe 3a000000.ppe 10g-2 (uninitialized): PHY [90000.mdio-1:00] driver [Aquantia AQR113C] (irq=POLL)
root@301W:~# dmesg |grep -i 10g
[   30.335985] qca-ppe 3a000000.ppe 10g-1 (uninitialized): PHY [90000.mdio-1:08] driver [Aquantia AQR113C] (irq=POLL)
[   30.354400] qca-ppe 3a000000.ppe 10g-2 (uninitialized): PHY [90000.mdio-1:00] driver [Aquantia AQR113C] (irq=POLL)
[   47.486596] qca-ppe 3a000000.ppe 10g-1: qca-ppe-nss: port 5 armed for NSS fw attach
[   47.494118] qca-ppe 3a000000.ppe 10g-2: qca-ppe-nss: port 6 armed for NSS fw attach
[   47.574132] qca-ppe 3a000000.ppe 10g-1: qca-ppe-nss: NSS data plane override on port 5
[   47.580695] qca-ppe 3a000000.ppe 10g-2: qca-ppe-nss: NSS data plane override on port 6
[   51.752424] qca-ppe 3a000000.ppe 10g-2: configuring for inband/usxgmii link mode
[   52.246462] qca-ppe 3a000000.ppe 10g-2: qca-ppe-nss: port 6 on NSS fw data plane (vsi 6)
[   52.246904] br-lan: port 5(10g-2) entered blocking state
[   52.253647] br-lan: port 5(10g-2) entered disabled state
[   52.259104] qca-ppe 3a000000.ppe 10g-2: entered allmulticast mode
[   52.264878] qca-ppe 3a000000.ppe 10g-2: entered promiscuous mode
[   52.277047] qca-ppe 3a000000.ppe 10g-1: configuring for inband/usxgmii link mode
[   52.776389] qca-ppe 3a000000.ppe 10g-1: qca-ppe-nss: port 5 on NSS fw data plane (vsi 7)
[   55.917208] qca-ppe 3a000000.ppe 10g-1: Link is Up - 1Gbps/Full - flow control off
root@301W:~#
1 Like
6515

yes the same here

6516

so, to summarize:

  • .mbn is a .cld with certain header, and can be converted back and forth.
  • the bootcmd workaround works both with .mbn and .cld, just write the file to the mtd, and it will load;
  • if you are not using the bootcmd to load fw, openwrt+301w can only work with .cld, while nbg7815 and mx8500 works with .mbn;
6517

And all it took was some AI model to change the .config :). (The rest was new driver specific)

6518

And the AI couldn't have done it without one @JuliusBairaktaris instructing it to do that and paying for its subscription

6519

Hi @JuliusBairaktaris @bahtsiz_bedevi

I think the mesh/DHCP issue may be related to the TX checksum offload problem that @qosmio mentioned in the following issue. It wasn’t identified as the root cause of the GitHub STA/client issue at the time, but one of the workarounds he suggested before arriving at the final fix appears to be the likely cause of the mesh/DHCP issue that @bahtsiz_bedevi reported.

1 Like
6520

@JuliusBairaktaris 's AI says the same thing https://github.com/JuliusBairaktaris/openwrt-nss-edma/issues/16#issuecomment-5215411671

What the two captures say

All 269 OFFERs the router sent reach the peer, on phy1-mesh0 and on its br-lan, and they are byte-identical to your router-side copy — a full 358-byte diff over both files is empty. So nothing in the mesh loses or mangles anything: not the mesh path, not the proxy path, not the firmware's encap, not the air, not the peer's bridge.

Every one of them carries udp checksum = 0x850c. That is not a checksum. It is the IPv4 pseudo-header sum for 192.168.1.1 → 192.168.1.101, proto 17, length 324:

c0a8 + 0101 + c0a8 + 0165 + 0011 + 0144  ->  0x850c

which is exactly the value Linux leaves in the field when it hands a packet down as CHECKSUM_PARTIAL and expects the hardware to finish it. Nothing finished it. The frame went out over the air with the placeholder still in place.

Everything else in the same two captures verifies correctly — all 40 ICMP echoes both ways, all 18 of the peer's own DISCOVERs. Only the router's OFFERs are broken, and all of them are.

Why the peer says nothing

busybox udhcpc checks the UDP checksum itself, in networking/udhcp/dhcpc.c:

check = packet.udp.check;
packet.udp.check = 0;
if (check && check != inet_cksum(&packet, bytes)) {
log1s("packet with bad UDP checksum, ignoring");
return -2;
}

log1s() compiles to nothing unless busybox is built with UDHCP_DEBUG. So the peer receives all 269 offers, discards every one in userspace, and prints not a single line about it. That is why six rounds of instrumentation on both ends found zero drops anywhere: there was no drop. The frame was delivered, and rejected.

@JuliusBairaktaris I will run step 2 and 3 tonight

1 Like
6521

Yes, and I will just have to buy either a mesh capable antenna or second router. Then all this would be minutes.

But currently mesh is no prio. So I let AI drive everything about it

6522

All hail the God of AI, a.k.a. the God of Math: Lord of tensors, Keeper of gradients, and Master of the sacred loss function. :slight_smile:
`

"According to Nvidia, at the lowest level, AI has already transformed standard cell development, one of the most time-consuming steps when transitioning to a new fabrication process. Porting a standard cell library of roughly 2,500–3,000 cells previously required a team of eight engineers working for about 10 months. Nvidia has replaced this work with a reinforcement learning system called NB-Cell, which can now complete the same task overnight on a single GPU."

6523

@xlighting2017 provides a good background ... @qosmio repo always worked with the NBG firmware i honestly stopped looking at all to qnap on openwrt as everything always worked like a clock ... I believe from what robi mentioned he did some changes very busy on other non qnap stuff but no one noticed or were asked to try with the right firmware instead of NBG... @sppmaster asked and no one had a glue including Robi ... anyhow glad all is sorted and also glad AI showed up in the meantime as our skills are extended to fix the issues and help /challenge the human devs capacity.

1 Like
6524

NAILED IT!!!

Flashed Qosmio NSS:

root@router-sinan:~# ethtool -k phy0-mesh0 | grep tx-checksum-ip-generic
        tx-checksum-ip-generic: off

Then flashed Julius EDMA:

root@router-sinan:~# ethtool -k phy0-mesh0 | grep tx-checksum-ip-generic
        tx-checksum-ip-generic: on

Restarted the mesh peer while tx-checksum-ip-generic: on, it became unreachable.

Executed ethtool -K phy0-mesh0 tx off
The mesh immediately has become reachable again :slight_smile:

Good job!

3 Likes
6525

I am troubleshooting an issue with my build of JuliusBairaktaris' NSS implementation and I could do with some help in the form of running a repro on other hosts and with other routers, running the same firmware of course.

I'll put the test first and then the details of what my issue is.

From a host on your network:

cat << 'EOF' > repro.py
import socket, ssl, sys

iface = sys.argv[1] if len(sys.argv) > 1 else "eth0"
host = "login.microsoftonline.com"
ip = socket.getaddrinfo(host, 443, socket.AF_INET, socket.SOCK_STREAM)[0][4][0]
print(f"resolved {host} -> {ip}")

ctx = ssl.create_default_context()
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BINDTODEVICE, iface.encode())
sock.settimeout(10)
sock.connect((ip, 443))
ssock = ctx.wrap_socket(sock, server_hostname=host)
ssock.send(b'GET / HTTP/1.1\r\nHost: login.microsoftonline.com\r\nConnection: close\r\n\r\n')
ssock.settimeout(8)
print(ssock.recv(4096))
EOF

python3 repro.py <interface>

Where interface is your network device e.g. eth0, wlan0, wlo1, etc. as shown with ip link

When I run that on any host in my network with an Ethernet adapter, I get a timeout, whereas the same host would succeed with a wireless adapter. Moreover, if I disable NSS with nss.general.enabled='0', the wired adapters also succeed.

The hang isn't during the TCP/TLS setup itself. The handshake completes fully every time. It's specifically the response after that which never arrives: the client sends its request, and nothing comes back until the socket times out.

I captured this on the wire to narrow it down further. With a wired client, the TLS handshake data all arrives correctly and the client's kernel ACKs it. But that ACK, while visible in a capture on the router's own br-lan, never shows up on wan. The far end (Microsoft's server, in this repro) never receives it, retransmits the unacknowledged data a few times, and eventually resets the connection. So whatever's happening seems to be specifically about a packet that's accepted on the LAN side not making it out to WAN, not about data failing to reach the client.

One could jump to the conclusion that NSS is at the centre of the issue, but it could well be that NSS uncovers an issue with the EDMA stack. I never had this issue with Qosmio's NSS or with vanilla OpenWrt but it's like comparing apples with oranges.

Behind this, as you can imagine, it's not just me doing some random tests. I use an OAuth 2.0 Proxy on my network to be able to send emails easily with git send-email and use other email clients that don't support OAuth 2.0 natively.

The proxy itself hangs during authentication when NSS is enabled which led me to investigate what was going on and the repro is just a by-product that helps with the testing.

Interestingly, I was able to use this proxy with a build from last week (which unfortunately I no longer have), but I haven't been able to pinpoint any recent commit that would be related to this issue.

6526

So thats why it was so hard to find. Qosmio doesnt set it in code but in a hotplug script

@vochong the issue linked was this code difference https://github.com/qosmio/openwrt-ipq/issues/21#issuecomment-2830132066

I would have inheritated it anyways

1 Like
6527

Please build from the latest commit so that I know exactly what you are running.

If you are able to produce an MRE it would make the hunt way easier. Your MRE should start with an unconfigured builder image.

And open an issue on github with it