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

Community Builds, Projects & Packages
1745

@GloooM is @KONG (or anyone else with an ea8500) the current 21.02 and master .dts are the same. Seems like the master settings work. What settings work for you on 21.02 (seems like they need to be different?)

21.02:


--- b/arch/arm/boot/dts/qcom-ipq8064-ea8500.dts
+++ a/arch/arm/boot/dts/qcom-ipq8064-ea8500.dts
@@ -107,15 +107,15 @@	
 };

 &gmac1 {
-	qcom,phy_mdio_addr = <4>;
-	qcom,poll_required = <1>;
-	qcom,rgmii_delay = <0>;
+	qcom,phy-mdio-addr = <0>;
+	qcom,poll-required = <0>;
+	qcom,rgmii-delay = <1>;
	qcom,emulation = <0>;
 };

 /* LAN */
 &gmac2 {
-	qcom,phy_mdio_addr = <0>;	/* none */
+	qcom,phy-mdio-addr = <4>;
	qcom,poll_required = <0>;	/* no polling */
	qcom,rgmii_delay = <0>;
	qcom,emulation = <0>;

master:


--- b/arch/arm/boot/dts/qcom-ipq8064-ea8500.dts
+++ a/arch/arm/boot/dts/qcom-ipq8064-ea8500.dts
@@ -113,15 +113,15 @@	
 };

 &gmac1 {
-	qcom,phy_mdio_addr = <4>;
-	qcom,poll_required = <1>;
-	qcom,rgmii_delay = <0>;
+	qcom,phy-mdio-addr = <0>;
+	qcom,poll-required = <0>;
+	qcom,rgmii-delay = <1>;
	qcom,emulation = <0>;
 };

 /* LAN */
 &gmac2 {
-	qcom,phy_mdio_addr = <0>;	/* none */
+	qcom,phy-mdio-addr = <4>;
	qcom,poll_required = <0>;	/* no polling */
	qcom,rgmii_delay = <0>;
	qcom,emulation = <0>;
1746

Hi @ACwifidude , I cannot test all builds because my ea8500 is my ISP router everyday, I only tested v5.10 build.

On my ea8500 (Hong Kong version) and NSS build, the follow config is must:

 &gmac1 {
	qcom,phy-mdio-addr = <0>;
...
 /* LAN */
 &gmac2 {
	qcom,phy-mdio-addr = <4>;
...

So the above 21.02 and master should be ok for me, but not tested.

BTW, I have noticed in OpenWrt official build, 21.02.1, the ea8500 driver is:

 &gmac1 {
	qcom,phy-mdio-addr = <4>;
...
 /* LAN */
 &gmac2 {
	qcom,phy-mdio-addr = <0>;
...

using this configs, Official build also work on my set. I do not know why.

1747

I noticed I get these on when using the 2.4Ghz interface/radio...
"wlan1: NSS TX failed with error: NSS_TX_FAILURE_TOO_SHORT"

I don't get them on the 5Ghz interface tho', I think I asked about this before but I don't think I ever got an answer.

1748

Yep on 5.10, it is different.

1749

I'm still testing stability with promisc mode disabled, I'm already there for 8 days, everything stable, very fast, Wi-Fi at maximum speed and no disconnections. Disable the options of both wifis to test:

Enable key reinstallation (KRACK) countermeasures

Y

Disassociate On Low Acknowledgment

The question that makes me curious is because almost no one fails or generates instability in the promisc mode, I imagine that some equipment in my wired network causes some type of incompatibility in the router.

how about the tests with firewall4?

1750

My router finally rebooted with br-lan in promisc mode and fw4.
However it rebooted when i fiddled with the firewall so I might have caused it myself.

I'm curious why promisc mode makes the router run like a normal build where hairpin forwards work.
I know for a fact that net.bridge.bridge-nf-call-iptables=1 causes promisc mode to be needed but there gotta be a firewall rule that fixes hairpin forwards.

Perhaps someone can figure out a solution using this as guide:

1 Like
1751

Really alarming discovery that I've just found out with current master build from 20220206 firewall4
If I uncheck a firewall traffic rule and hit save&apply the rule will still remain active and port will be left open.
Can anyone try the same and confirm it.
This is the current content of the /etc/config/firewall

config rule
	option name 'ssh-wan'
	list proto 'tcp'
	option src 'wan'
	option dest_port '22'
	option target 'ACCEPT'
	option enabled '0'

I'm still able to connect from the outside world.

1752

I noticed that too, I don't think think firewall4 reloads properly from LuCi, you have to do it from shell with fw4 reload

1 Like
1753

Thanks.
Your suggestion workarounds the issue for now.

1754

I tried to make a build for EA8500 and every time failed, it said my uImage is too big.
In diffconfig, I've tried to delete almost all addons but do no work, still "too big".

Then I looked up for target/linux/ipq806x/image/generic.mk and found

define Device/linksys_ea8500
	$(call Device/LegacyImage)
	DEVICE_VENDOR := Linksys
	DEVICE_MODEL := EA8500
	SOC := qcom-ipq8064
	PAGESIZE := 2048
	BLOCKSIZE := 128k
	KERNEL_SIZE := 3072k

Then I changed the KERNEL_SIZE to 3200k and build success

Will this brick my router? Or should I just proceed?
I don't think the partition table allows me to change, but how could I shrink the kernel size then?

1755

I think it's fixed in master tho' but this build isn't updated yet.

1 Like
1756

It's working for me so it certainly looks like it's fixed in master now. There were a couple of extra fixes earlier this week, so for now, anything from the 9th onwards should be good for a basic fw4 setup, although obviously there are a lot of other packages that need to be updated still...

Speaking of which, I can see the SQM script nss.qos uses iptables to MARK packets but I can't see anything that actually makes use of them, unless nssfq_codel uses them internally?

1757

I have no such script... wonder where you got it from?
Can you run opkg whatprovides nss.qos

1758

Yep. With the current master build I did a opkg upgrade firewall4 and now it's working.

1759

It's part of a fork of the sqm-scripts package that I think kong created, followed the instructions here pulls the code from the fork in to the build

The basics are as per the example given in the nss-ifb readme (package/qca/nss-ifb/README.md in the source tree)

1760

You can get that script from this GitHub repo[1]. See my post from some weeks ago for some config instructions.

[1]: Apparently the sqm-scripts development for NSS-based SQM takes place in the ipq806x_nss branch of the ricsc/sqm-scripts GitHub repository and not the tohojo/sqm-scripts GitHub repository which OpenWrt's official sqm-scripts package is built from.

1761

Mmh, wonder if they actually work as intended.
On top of this thread there's a far simpler example.

1762

I guess it depends on the intent...

It certainly works as well as the simple script, but the extra bits don't work, so those iptables rules really aren't doing anything

1 Like
1763

now after 9 days the 5ghz wifi network has dropped, it has been left without internet access. I have only restarted the wifi 5ghz and everything ok again.

1764

For what it's worth to those perhaps having glitches with the current build that's posted - Firewall4 has been updated since this build has been posted. May be worth rebuilding / updating to see if it resolves any issues you may be having.

1 Like