Ipq806x NSS build (Netgear R7800 / TP-Link C2600 / Linksys EA8500)

I managed to compile and succesfully boot my C2600. It's a dumb AP but the nss cores were fully loaded and the router is working well. This is the gmac part of the dts file that I used.

&gmac1 {
	status = "okay";
	compatible = "qcom,nss-gmac";
	reg = <0x37200000 0x200000>;
	interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>;
	phy-mode = "rgmii";
	qcom,id = <1>;
	qcom,pcs-chanid = <0>;
	qcom,phy-mdio-addr = <4>;
	qcom,poll-required = <0>;
	qcom,rgmii-delay = <1>;
	qcom,phy_mii_type = <0>;
	qcom,emulation = <0>;
	qcom,forced-speed = <1000>;
	qcom,forced-duplex = <1>;
	qcom,socver = <0>;
	qcom,irq = <255>;
	mdiobus = <&mdio0>;

	pinctrl-0 = <&rgmii2_pins>;
	pinctrl-names = "default";

	fixed-link {
		speed = <1000>;
		full-duplex;
	};
};

&gmac2 {
	status = "okay";
	compatible = "qcom,nss-gmac";
	reg = <0x37400000 0x200000>;
	interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>;
	phy-mode = "sgmii";
	qcom,id = <2>;
	qcom,pcs-chanid = <1>;
	qcom,phy-mdio-addr = <0>; /* none */
	qcom,poll-required = <0>; /* no polling */
	qcom,rgmii-delay = <0>;
	qcom,phy_mii_type = <1>;
	qcom,emulation = <0>;
	qcom,forced-speed = <1000>;
	qcom,forced-duplex = <1>;
	qcom,socver = <0>;
	qcom,irq = <258>;
	mdiobus = <&mdio0>;

	fixed-link {
		speed = <1000>;
		full-duplex;
	};
};

1 Like

The ea8500 has qcom,phy_mdio_addr set to 4 too.

I’ll add that to my next build. Appreciate it!

DFS seems okay where I am - haven't seen it drop out yet.

I have verified that

uci add_list umdns.@umdns[0].network='wan'; uci commit

Have set HT to 10 and VHT to 100.

Will keep you updated! Appreciate the help :+1:

1 Like

I followed your instructions for building myself. I am trying to use the SQM startup script and I am getting the error below:

root@OpenWrt:~# tc qdisc add dev nssifb root handle 1: nsstbl rate 100Mbit burst 1Mb
Cannot find device "nssifb"

I’d grab that entire set of code and run it in the startup script (/etc/rc.local)

Takes a reboot but should work. Let me know if it doesn’t take or there is an error. :sunglasses:

Don’t have any 160mhz devices - it looks like others are having issues and it might be a driver issue.

I tried that as well, the same error shoes up in the system log:

Tue Dec 29 05:25:06 2020 daemon.notice procd: /etc/rc.d/S95done: Cannot find device "nssifb"

It seems like upstream shaping is working, but downstream is not.

edit: If I modprobe nss-ifb first, I don't get the error message. Downstream shaping still doesn't work, though.

So follow up - unfortunately every now and then it will have no internet. On my MBP it behaves slightly differently compared to my iPhone. It disconnects completely from the network - I'll check the available network and it still shows as available - I'll click it and it connects again! For comparison, my iPhone shows it's still connected to the network but won't actually have an internet connection.

Can't imagine it's anything to do with DFS since the 5GHz SSID is still live and can be reconnected to.

Very odd!

What country did you set, 160Mhz is not available for all countries. And the error is no crash, but info, that init can't be done with your settings

1 Like

The country set is LV (Latvia). On NBG6817 stock firmware and OpenWrt 19.07.5 release, 160Mhz is working fine on 36 or 100 channels with the same country.

modprobe nss-ifb
ip link set up nssifb

With these downstream shaping is working fine for me.

1 Like

Would of been helpful for me to put that in the recommended config. My mistake :man_facepalming: I’ll edit my above post.

1 Like

I have that as well, and it made the error message go away, but still seems not to be shaping on the ingress side.

With NSS you should be able to do full line speed and see a good drop in bufferbloat. How does it look like with vs without?

If it is not kicking in there might be a bug or a missing package.

I am getting full ingress speed (only 100M), low CPU usage (almost nothing), but an F for buffer bloat on the DSL Reports test. With a non-NSS build and SQM I was getting full line speed and an A on DSL Reports, but high CPU usage. Egress shaping seems to be working, as I am getting an A for buffer bloat there.

That bufferbloat sucks - I’d turn the ingress speed down a little (90mbps) and see if it helps. I’ve never seen NSS fq codel tested at that speed (100mbps) so I don’t know how it does. I’m use to testing it at several multiples above that.

@quarky - anything particular about NSS fq codel usage at 100mbps or recommendations for tweaking custom settings for better bufferbloat at that speed?

Example:


modprobe nss-ifb

ip link set up nssifb

# Shape ingress traffic to 100 Mbit with chained NSSFQ_CODEL
tc qdisc add dev nssifb root handle 1: nsstbl rate 100Mbit burst 1Mb
tc qdisc add dev nssifb parent 1: handle 10: nssfq_codel limit 10240 flows 1024 quantum 1514 target 5ms interval 100ms set_default

# Shape egress traffic to 100 Mbit with chained NSSFQ_CODEL
tc qdisc add dev eth0 root handle 1: nsstbl rate 100Mbit burst 1Mb
tc qdisc add dev eth0 parent 1: handle 10: nssfq_codel limit 10240 flows 1024 quantum 1514 target 5ms interval 100ms set_default

Other considerations:

  1. My 2.4ghz SSID is different from my 5ghz SSID - my roaming devices only know the 5ghz network. 2.4ghz is full of interference and I find it unbearably slow (Great for IoT devices!). I found separating SSID by frequency reduced the number of jumps and improved roaming (allowed me to optimize my physical location of my APs for the physics of the 5ghz radios).

  2. There are more aggressive dawn options that might help. I turned them on to encourage aggressive roaming:


        option eval_probe_req '1'
        option eval_auth_req '1'
        option eval_assoc_req '1'

  1. try 20mhz at 2.4ghz. Few devices can connect successfully at 40mhz in this spectrum.

  2. try manually setting your transmit power to your environment. Often times you might need to turn the power up or down to encourage good roaming depending on your environment - 20 is a common setting (Apple devices will start roaming at -70 dbm RSSI)

  3. I’d turn on “force ccmp” so that your encryption is - option encryption 'psk2+ccmp' - (this is AES only, AES is much better than TKIP))

1 Like

And it seems to have magically fixed itself. It seems like it takes some time after booting to start shaping. I can actually pull 110 down and 11 up in a speed test with no traffic shaping. Once it magically started working, 109 and 10.5 got me up to a B buffer bloat wise.
:man_shrugging:t2:

1 Like

Any hope it could see mainlining someday?

No problem shaping 100Mbps. Note tho that the rate configured may not be actual shaped thruput. Try to experiment with figures above and below for best result. Also, do ensure you have sufficient allowance for upstream for reply packets, especially if the upstream bandwidth is low. E.g. if your upstream bandwidth is 10Mbps, cap it with NSS Qdisc as well, or your buffer float will also be affected.

1 Like