I think that he also did not use OpenWrt but something else. The Luci looks the same but actual os is not OpenWrt.
Hi. I am also in a similar situation but with a different (Italian) ISP: Aruba by OpenFiber. I am using the snapshot firmware. Multi-gig seems to work fine when connected between a QHora 10G port and the 2.5G port of the router the ISP provided (Fritzbox 5530 Fiber) but it gives me 1G bandwidth when connected directly to the ZTE ONT.
I tried changing the cable and updating the 10G ports firmware to no avail. I guess it is a negotiation issue and I am also looking for a way to debug this. The port does negotiate 2.5G on the stock firmware correctly.
You could try to enable advertisement of all speeds using ethtool:
ethtool -s eth4 advertise 18000000E102C
ethtool -s eth5 advertise 18000000E102C
I've already tried that. It worked on 10g-2 (connected to the Fritzbox) but not on 10g-1 (connected to the ZTE ONT). Here you can see the relevant dmesg after issuing the advertisement by means of ethtool for both devices:
[ 1760.470444] nss-dp 3a001000.dp1 lan4: PHY Link is down
[ 1760.471010] br-lan: port 4(lan4) entered disabled state
[ 1763.670281] nss-dp 3a007000.dp6-syn 10g-2: PHY Link is down
[ 1763.670814] br-lan: port 5(10g-2) entered disabled state
[ 1769.910518] nss-dp 3a007000.dp6-syn 10g-2: PHY Link up speed: 1000
[ 1769.910617] br-lan: port 5(10g-2) entered blocking state
[ 1769.915608] br-lan: port 5(10g-2) entered forwarding state
[ 1784.390501] nss-dp 3a001000.dp1 lan4: PHY Link up speed: 1000
[ 1784.390592] br-lan: port 4(lan4) entered blocking state
[ 1784.395242] br-lan: port 4(lan4) entered forwarding state
[ 1874.230461] nss-dp 3a001800.dp5 10g-1: PHY Link is down
[ 1921.990724] nss-dp 3a001800.dp5 10g-1: PHY Link up speed: 1000
[ 1921.990821] IPv6: ADDRCONF(NETDEV_CHANGE): 10g-1: link becomes ready
[ 1921.995913] IPv6: ADDRCONF(NETDEV_CHANGE): vlan-835: link becomes ready
[ 1922.811262] pppoe-wan: renamed from ppp0
[ 2103.750635] nss-dp 3a007000.dp6-syn 10g-2: PHY Link is down
[ 2103.751170] br-lan: port 5(10g-2) entered disabled state
[ 2106.870901] nss-dp 3a007000.dp6-syn 10g-2: PHY Link up speed: 1000
[ 2106.871002] br-lan: port 5(10g-2) entered blocking state
[ 2106.875988] br-lan: port 5(10g-2) entered forwarding state
[ 2175.550959] nss-dp 3a001800.dp5 10g-1: PHY Link is down
[ 2179.815552] nss-dp 3a007000.dp6-syn 10g-2: PHY Link is down
[ 2179.815888] br-lan: port 5(10g-2) entered disabled state
[ 2185.031618] nss-dp 3a001800.dp5 10g-1: PHY Link up speed: 1000
[ 2185.031688] nss-dp 3a007000.dp6-syn 10g-2: PHY Link up speed: 2500
[ 2185.031701] IPv6: ADDRCONF(NETDEV_CHANGE): 10g-1: link becomes ready
[ 2185.042962] br-lan: port 5(10g-2) entered blocking state
[ 2185.049034] br-lan: port 5(10g-2) entered forwarding state
[ 2185.054715] IPv6: ADDRCONF(NETDEV_CHANGE): vlan-835: link becomes ready
[ 2185.981466] pppoe-wan: renamed from ppp0
EDIT: I also tried disabling GRO and LRO to no avail.
2.5G appears to be massively broken atm. No resolution afaik
Actually, I opened a bug on GitHub and a dev has come up with a patch [1] which solves the problem.
I built a custom image with a netifd patch, flashed it on my router and now it negotiate the correct speed on boot, no need to fiddle with ethtool anymore. 
[1] https://github.com/openwrt/openwrt/issues/12321#issuecomment-1496429799
2 Likes
Does it perform as expected now? You get the full 2.5G?
Also very interested if throughput has improved ?
Yes, I get "full" 2.5Gbps Internet now
BUT
Here is iperf3 between my MacStudio and the Qhora...
[ ID] Interval Transfer Bitrate Retr Cwnd RTT
[ 5] 0.00-1.00 sec 264 MBytes 2.21 Gbits/sec 0 6.02 MBytes 12ms
[ 5] 1.00-2.00 sec 267 MBytes 2.24 Gbits/sec 0 6.02 MBytes 11ms
[ 5] 2.00-3.00 sec 266 MBytes 2.23 Gbits/sec 0 6.06 MBytes 12ms
[ 5] 3.00-4.00 sec 265 MBytes 2.23 Gbits/sec 0 6.06 MBytes 11ms
[ 5] 4.00-5.00 sec 264 MBytes 2.21 Gbits/sec 0 6.06 MBytes 10ms
[ 5] 5.00-6.00 sec 265 MBytes 2.22 Gbits/sec 0 6.06 MBytes 11ms
[ 5] 6.00-7.00 sec 265 MBytes 2.22 Gbits/sec 0 6.06 MBytes 11ms
[ 5] 7.00-8.00 sec 267 MBytes 2.24 Gbits/sec 0 6.06 MBytes 11ms
[ 5] 8.00-9.00 sec 265 MBytes 2.22 Gbits/sec 0 6.06 MBytes 11ms
[ 5] 9.00-10.00 sec 265 MBytes 2.22 Gbits/sec 0 6.06 MBytes 12ms
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 2.59 GBytes 2.22 Gbits/sec 0 sender
[ 5] 0.00-10.01 sec 2.59 GBytes 2.22 Gbits/sec receiver... and from the QHora to the MacStudio:
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 230 MBytes 1.92 Gbits/sec 0 274 KBytes
[ 5] 1.00-2.00 sec 229 MBytes 1.92 Gbits/sec 0 274 KBytes
[ 5] 2.00-3.00 sec 228 MBytes 1.91 Gbits/sec 0 274 KBytes
[ 5] 3.00-4.00 sec 228 MBytes 1.91 Gbits/sec 0 274 KBytes
[ 5] 4.00-5.00 sec 230 MBytes 1.92 Gbits/sec 0 274 KBytes
[ 5] 5.00-6.00 sec 228 MBytes 1.91 Gbits/sec 0 274 KBytes
[ 5] 6.00-7.00 sec 228 MBytes 1.91 Gbits/sec 0 274 KBytes
[ 5] 7.00-8.00 sec 228 MBytes 1.91 Gbits/sec 0 274 KBytes
[ 5] 8.00-9.00 sec 226 MBytes 1.90 Gbits/sec 0 274 KBytes
[ 5] 9.00-10.01 sec 232 MBytes 1.95 Gbits/sec 0 274 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 2.23 GBytes 1.92 Gbits/sec 0 sender
[ 5] 0.00-10.04 sec 2.23 GBytes 1.91 Gbits/sec receiverIt's far from 10Gbps...
I get 2.5G between the router and the ONT so I can achieve higher Internet throughput (2.3Gbps download, 530 Mbps upload which is the same result as the stock firmware) but only with packet steering enabled.
Here is the gist of it as far as I understood: OpenWRT still misses hardware accelerated network offloading but the QHora has a quite good CPU so it can (almost) achieve 2.5G networking when packet steering is enabled.
Well, there's a fork which added hw offloading driver back, it can be buggy but it's also worth to have a try:
3 Likes
WOW!!! I am just trying the bitthieft fork and IT'S FRIGGIN' AMAZING!!! 
I've just added the patch/fix for the speed negotiation, disabled packet steering and I got a 1.8 Gbps DL / 519 Mbps UP speed-test on a random server (with speedtestpp). The CPU stays around 70-90% load during the DL phase. I am also going to test 10Gbps networking but for now I am quite happy with it.
Is there something I need to enable? Also, is there something I should be aware while using the bitthief fork?
worth asking the same question on nss community build - IPQ807X NSS Build
fyi - there are a few things you can enable both on the nss-drv and nss-ecm if your use case applies
2 Likes
hrm... im trying to sysupgrade from a middle of march 2023 build to todays snapshot and it wont work 
i tried both via the web interface as well as via cli:
sysupgrade -c /tmp/image
sysupgrade starts, disconnects the network, reboots the device but it boots up with the old firmware installed.
any ideas?
try to stop wpad before you do the sysupgrade
1 Like
Thanks, this is probably the fix. I was not aware that this also affected the 301w. I have an AX3600 as well that requires stopping wpad before sysupgrade.
It ended up working okay without stopping wpad because I tried it like 5 times, and on the 5th try, it went through...only because I read this post after my upgrade.
Can you post here or on the NSS thread the config you used to build it for the QNAP 301W?
Max speed you can reach on PPPoE using the ONT provided by your ISP?
Sorry, I don't have either the device or the .config anymore: I send the QHora back to Amazon and built a custom x86 router with a refurbished SFF PC and a quad 2.5G Ethernet card. The cost and power consumption is basically the same and with the PC I can do a lot more (I am currently using that as a Docker server too).
I can help you setting up the build though. If you're interested just send me a PM.
I could reach ~2.3Gbps / ~475Mbps with bitthief branch which is about the same speed I achieved with my MacStudio connected straight to the ONT.
1 Like
@robimarko I can also confirm that the patch here: https://github.com/openwrt/openwrt/issues/12321#issuecomment-1496429799 fixes the 2.5G networking. Full speed ahead (granted CPU still limited me to ~800mbit/s with NAT)
Wait, so its damn netifd-s fault?
Though, I am not getting how since it looks completely optional
1 Like
It would appear so. Perhaps we can get that patch merged in?
Next step would be getting NSS working so NAT isn't capped to <1g.