try the real time graph/connections tab to get the list of ip and ports. that should give you an idea which service/machine is causing.
Edit - luci would probably crash, try getting the data from
cat /proc/net/nf_conntrack
1 Like
@ACwifidude Hi, thanks for your new code.
I have built the new kernel5.10-nss-qsdk10.0 branch for my ea8500, but the new driver+patch still not work on my ea8500 Lan port. I have to change it back, the following is my modified files, then the Lan port worked.
-
in file
990-00-Add-required-entries-in-dts-files-for-5.10-NSS-support.patch, removed ea8500 and eax500 related parts. -
in file
qcom-ipq8064-ea8500.dts:
&partitions {
partition@5f80000 {
label = "syscfg";
reg = <0x5f80000 0x2080000>;
};
};
&mdio0 {
phy4: ethernet-phy@4 {
reg = <4>;
};
};
&gmac1 {
qcom,phy-mdio-addr = <0>;
qcom,poll-required = <0>;
qcom,rgmii-delay = <1>;
};
/* LAN */
&gmac2 {
qcom,phy-mdio-addr = <4>;
qcom,poll-required = <0>;
qcom,rgmii-delay = <0>;
};
- in file
qcom-ipq8064-eax500.dtsi:
&mdio0 {
status = "okay";
pinctrl-0 = <&mdio0_pins>;
pinctrl-names = "default";
phy0: ethernet-phy@0 {
reg = <0>;
qca,ar8327-initvals = <
0x00004 0x7600000 /* PAD0_MODE */
0x00008 0x1000000 /* PAD5_MODE */
0x0000c 0x80 /* PAD6_MODE */
0x00010 0x2613a0 /* PWS_REG */
0x000e4 0x6a545 /* MAC_POWER_SEL */
0x000e0 0xc74164de /* SGMII_CTRL */
0x0007c 0x4e /* PORT0_STATUS */
0x00094 0x4e /* PORT6_STATUS */
>;
};
phy4: ethernet-phy@4 {
reg = <4>;
};
};
&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_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,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;
};
};
&adm_dma {
status = "okay";
};
(above 2 files, not all parts, the rest parts are same as new code.)
1 Like
I've identified the intruder.
Now I need a firewall rule to limit all those endless connections.
1 Like
Updates:
- added 22.03 build
- changed .dts patch for the ea8500 as per @RadioOperator above post. 22.03 and master builds should work now for the ea8500.
- will look in to @quarky UDP patches for next build which could potentially solve UDP issues.
7 Likes
Hi all, I'm currently rocking the latest 21.02 build with ath10k non-ct and it's working good so far. I was wondering if upgrading to master or even this new 22.03 build would give me more features/performance in my case? Thank you!
As far as version numbers currently (+19 custom commits) here is a rough difference (when they branch off they have their own commits that don’t match up with trunk).
21.02 is r16514+19
22.03 is r19165+19
Master is r19174+19
So upgrading ~2500+ commits gets you kernel 5.10, firewall 4, and a couple other more recent versions of software packages. This may be a good thing, maybe a bad thing. Stability vs cutting edge vs performance is tough. I personally run master and find the performance to be great. I haven’t compared recent 21.02 vs recent master. You can flash back and forth and compare - feel free to try and post some test results about your findings.
2 Likes
Yes it is an ipq8065 device. The build already supports it - I can build images for 22.03 and master this weekend.
1 Like
Hi,
is it possible to keep the settings from your 5.4 nss master (I run it since a year without upgrade) to your 22.03 ?
thank you
1 Like
I never got gigabyte speeds with Kong, switch to the factory, and released I could not reach outside security cameras without using the tx power. Went with this build and love it so far no issues and gig speeds on ethernet. Thanks
1 Like
Hi @ACwifidude, the new patch in branch 2203 for my ea8500 is all OK, just start running, I'll report you if something happened, thanks.
1 Like
Whats interesting is that it liked the “-“ over the “_” in the .dts files. The .dts files are not consistent across the different ipq806x routers in OpenWrt. For fun, I tested
qcom,phy-mdio-addr = <0>;
vs
qcom,phy_mdio_addr = <0>;
For the r7800, I deleted the lines I added at the end of the ipq8065.dtsi file with the “-“ nomenclature and relied on the “_” nomenclature in the .dts file. It definitely did not work (router crashed within seconds of attempting to boot, had to tftp flash my router). The ea8500 looks like it is the same. I don’t know the subtlety of the difference and why some ipq806x devices use one nomenclature vs the other. But with using the same nomenclature across the board, glad everything is working now!
2 Likes
Hi guys,on latest 22.03 stable version I can't download any packages. I think the opkg URL is incorrect. How to solve it?
any chance for xr500 build ?
1 Like
Maybe this is why official openwrt(non-nss) also works ok on ea8500 with "phy_mdio_addr".
Updates:
- included xr500 and RT4230 on today’s 22.03 and master builds
- rebased both builds to the latest commits
4 Likes
I have updated my R7800 to the new master build but now i miss stubby and my DNS over TLS configuration isn`t working anymore. Could anyone help me how to get a compatible stubby package?
Now it is listed again. Thanks!
Wanted to try your build on my XR500 @ACwifidude so I just installed the latest sysupgrade. I was using the mainline ct driver on my stock snapshot but on yours I'm seeing this error in the logs:
[ 127.683000] ath10k_pci 0001:01:00.0: refusing to associate station: too many connected already (32)
I have a bunch of small IoT devices (~35 clients) - how would I go about increasing this parameter on your build?