NBG6617 / ipq40xx - Powersaveing and other problems


#1

Hey all,
I am currently using an NBG6617 with the latest nightly and ran into some problems:

  1. Without echo 200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq long running IPv6 connections at some point receive corrupted packages (e.g. sftp drops the connection for invalid macs). No indication of problems is visible in the logs
  2. Wifi range is really poor (hardly any connectivity at 10 meters distance.
  3. Pings on the network, even between two devices both connected to the switch, are only getting through in batches. Hard to explain but the timestamps on the pings are without any indication of problems, however the packets seem to be transferred all at the same time. E.g. one second the output of ping is

root@ZIM:~# ping libreelec.lan
PING libreelec.lan (192.168.1.177) 56(84) bytes of data.
64 bytes from LibreELEC.lan (192.168.1.177): icmp_seq=1 ttl=64 time=0.637 ms
64 bytes from LibreELEC.lan (192.168.1.177): icmp_seq=2 ttl=64 time=0.862 ms

where it stays for 1-3 seconds, but then immediately goes to

root@ZIM:~# ping libreelec.lan
PING libreelec.lan (192.168.1.177) 56(84) bytes of data.
64 bytes from LibreELEC.lan (192.168.1.177): icmp_seq=1 ttl=64 time=0.637 ms
64 bytes from LibreELEC.lan (192.168.1.177): icmp_seq=2 ttl=64 time=0.862 ms
64 bytes from LibreELEC.lan (192.168.1.177): icmp_seq=3 ttl=64 time=0.715 ms
64 bytes from LibreELEC.lan (192.168.1.177): icmp_seq=4 ttl=64 time=0.711 ms
64 bytes from LibreELEC.lan (192.168.1.177): icmp_seq=5 ttl=64 time=0.576 ms
64 bytes from LibreELEC.lan (192.168.1.177): icmp_seq=6 ttl=64 time=0.675 ms

My guess is that there is something funny going on with some queues in the switch. It really is a problem with the router, when I switch it to my old TL-WDR4900 all problems are gone.

Did anyone experience similar problems on the NBG6617 or other ipq40xx devices or has ideas what to try to fix (2) and (3)?


#2

@chunkeey can probably shed some light on this one.

It was recently switched to the upstream ath10k board file - could it be possible this hasn't been merged correctly, or has different HWIDs?

@Incom can you post a boot log (from serial) here?
If you are able to build, checkout commit 575d0240f9593145aeda60385110e3e1e1673888 and test again.


#3

Hi, bootlog is as follows:

Normal boot: https://pastebin.com/FikqR6Zj
Procd debug level 4: https://pastebin.com/uUP3SFSL

Hope that helps.


#4

Okay, a little bit awkward but (3) seems to be an issue because of the bad wifi. The ssh connection to the locally connected workstations goes via wifi, that's why the ping updated infrequently :man_facepalming:

So the question remaining is why the wifi is that bad, even though I'm sitting 3m away from the router.


#5

I've just compared the boardfiles from the vendor squashfs with the ones included in the board-2.bin from kalles repo. They are identical. Also, the hardware-id seems to match the one in the devicetree.


#6

Incom have you tried setting the wireless to a different channel? Might be worth taking a look at your wireless settings and changing a few defaults. It could be that the channel you are on is over-crowded.
Try different channels and check the signal strength in the interface.

As @blocktrron has checked the board file I think we can rule that out.


#7

Yes, 2.4GHz is pretty crowded around here, but 5GHz is clear and both perform much worse than the previous TP-Link router. Antenna orientation makes little difference, channel width is set to 20MHz.


#8

I am also considering to buy the ZyXEL nbg6617.

My question is, what is that status of support? I know that there are snapshot builds available, but looking at the github repository, I don't see the support being merged to any of the main development branches. What are the chances of the support being merged into the 18.06 branch relatively soon?

Thank you.


#9

Support for the ZyXEL nbg6617 has been merged into the master branch, from which the upcoming 19.01 will branch off, it just came too late for 18.06 (and no, chances for new features/ devices being merged into subsequent 18.06.x releases are between zero and very, very low - that's what master and 19.01 are for).

In terms of its support status in master, it should be on par with the other supported ipq40xx devices - fortunately the hardware offers enough flash and RAM for a long term future, making this certainly one of the more interesting devices among its peers. There is no reason not to use master snapshots for now, until 19.01.0 comes around (or beyond that, if you're comfortable with sticking to master and updating more regularly).


#10

I see. Thank you for the explanation.

I thought it hasn't been merged, because in the original commit, I saw that the firmware file package/firmware/ipq-wifi/board-zyxel_nbg6617.bin has been added, and I don't see the same file at the master brach here. But now I understand that it has been removed later on. ("drop custom board-2.bins")

Where can I find some information about the release schedule? (Ie. ETA for 19.01.0 ?)

Thank you for your help again.


#11

The temporarily required custom package could be dropped, once the official boardfile support package contains the necessary board2.bin data (which it does now, in master).

http://lists.infradead.org/pipermail/openwrt-devel/2018-November/014526.html

But there's no need to be afraid of using master snapshots either.


#12

Thank you for all the input. I have ordered the router.


#13

Does master use ath10k-ct? Master switched to -ct for the R7800 in the last few months and I think it was universal for all ath10k devices. Unfortunately that driver and firmware has unexplained poor wifi performance with certain devices (notably Samsung smartphones) which you may be suffering. Master still has the non -ct drivers and firmware available to try.