Intel J3455 Extremely Slow Throughput

Installing and Using OpenWrt Network and Wireless Configuration
1

Experiencing extremely limited throughput (under 10Mbit) on my newly installed OpenWrt device. Latency is also a major issue, averaging ~150ms while pinging 1.1.1.1. Unsure if this is a hardware acceleration problem, and if there is a system setting I missed (Software/Hardware flow offloading doesnt help).

System Specs: Intel Celeron J3455 4C 1.5 Ghz w/ Intel I-340 NIC

1.1.1.1 Ping Results (Expected ~7ms with minimal jitter):
43 packets transmitted, 43 received, 0% packet loss, time 42033ms
rtt min/avg/max/mdev = 7.498/154.054/751.085/178.214 ms

Firewall Config:

config defaults
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config zone
	option name 'LAN'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'lan'

config zone
	option name 'WAN'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	list network 'WAN'

config forwarding
	option src 'LAN'
	option dest 'WAN'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'WAN'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'WAN'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'WAN'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'WAN'
	option proto 'udp'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'WAN'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'WAN'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'WAN'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'WAN'
	option dest 'LAN'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'WAN'
	option dest 'LAN'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config zone
	option name 'LAN2'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'LAN2'

config zone
	option name 'LAN3'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'LAN3'

config forwarding
	option src 'LAN2'
	option dest 'WAN'

config forwarding
	option src 'LAN3'
	option dest 'WAN'

config zone
	option name 'WIFI1'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	list network 'WIFI1'

config forwarding
	option src 'WIFI1'
	option dest 'WAN'

config rule
	option name 'WIFI1 DHCP and DNS'
	option src 'WIFI1'
	option dest_port '53 67 68'
	option target 'ACCEPT'

config rule
	option name 'LAN2 DHCP and DNS'
	option src 'LAN2'
	option dest_port '53 67 68'
	option target 'ACCEPT'

config rule
	option name 'LAN3 DHCP and DNS'
	option src 'LAN3'
	option dest_port '53 67 68'
	option target 'ACCEPT'

config forwarding
	option src 'LAN2'
	option dest 'LAN3'

config forwarding
	option src 'LAN3'
	option dest 'LAN2'

config rule
	option name 'Temp Speed Test'
	option src 'LAN3'
	option dest 'LAN2'
	option target 'ACCEPT'
	list proto 'icmp'

config rule
	option name 'Temp Speed Test'
	list proto 'icmp'
	option src 'LAN2'
	option dest 'LAN3'
	option target 'ACCEPT'

ubus call system board

{
	"kernel": "5.15.137",
	"hostname": "OpenWrt",
	"system": "Intel(R) Celeron(R) CPU J3455 @ 1.50GHz",
	"model": "ASRock J3455B-ITX",
	"board_name": "asrock-j3455b-itx",
	"rootfs_type": "ext4",
	"release": {
		"distribution": "OpenWrt",
		"version": "23.05.2",
		"revision": "r23630-842932a63d",
		"target": "x86/64",
		"description": "OpenWrt 23.05.2 r23630-842932a63d"
	}
}

cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fdfd:d9af:0657::/48'

config interface 'lan'
	option device 'eth4'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'LAN2'
	option proto 'static'
	option device 'eth2'
	option ipaddr '10.0.20.1'
	option netmask '255.255.255.0'

config interface 'LAN3'
	option proto 'static'
	option device 'eth3'
	option ipaddr '10.0.30.1'
	option netmask '255.255.255.0'

config interface 'WIFI1'
	option proto 'static'
	option device 'eth1'
	option ipaddr '10.0.10.1'
	option netmask '255.255.255.0'

config interface 'WAN'
	option proto 'dhcp'
	option device 'eth0'
	option vendorid 'Edited'
	option peerdns '0'
	list dns '1.1.1.1'
	list dns '8.8.8.8'
	option hostname '*'
	option clientid 'Intel NIC(90:E2:BA:xx:xx:xx) Edited to 28:80:88:xx:xx:xx' ```

cat /etc/config/wireless (Router without AP)
cat: can't open '/etc/config/wireless': No such file or directory

cat /etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option cachesize '1000'
	option readethers '1'
root@OpenWrt:~# cat /etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option cachesize '1000'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option localservice '1'
	option ednspacket_max '1232'
	list server '1.1.1.1'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option dhcpv6 'server'
	option ra 'server'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

config dhcp 'LAN2'
	option interface 'LAN2'
	option start '100'
	option limit '150'
	option leasetime '12h'

config dhcp 'LAN3'
	option interface 'LAN3'
	option start '100'
	option limit '150'
	option leasetime '12h'

config dhcp 'WIFI1'
	option interface 'WIFI1'
	option start '100'
	option limit '150'
	option leasetime '12h'

config dhcp 'WAN'
	option interface 'WAN'
	option ignore '1'

Edited to include commands

2

Why accept a ping from outside your lan instead of the default of reject?

Not a diagnosis, just trying to put my head around it.

:spiral_notepad:

They will probably ask for more, so help them out a little more:

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
1 Like
3

I changed the ping firewall rule while debugging.

While this is not the topic of this post, I was having trouble pinging the router interface of other zones and edited firewall rules to include 'Temp Speed Test'.

Edited original post to include commands

1 Like
4

We all learn in mysterious ways.
Thanks.
Before they ask I'd put it all back to before you started debugging and let them sort the whole mess.

Take that with a pinch of salt.

1 Like
5

Are the devices directly connected via ethernet?

Try starting from a fresh configuration (default state) and test the throughput between the lan and wan/internet.

6

Yes all of the devices are connected directly via ethernet

7

On second thought, I don't recall changing the 'Allow-Ping' firewall rule. I think it is apart of the default settings.

2 Likes
8

@psherman is waiting for you to also tell him you followed his advice on (default state).

1 Like
9

Will do, thanks. Resetting it now.

Any chance it could be the sources list? Intel is always great about publishing blobs /s
cat /etc/opkg/distfeeds.conf

src/gz openwrt_core https://downloads.openwrt.org/releases/23.05.2/targets/x86/64/packages
src/gz openwrt_base https://downloads.openwrt.org/releases/23.05.2/packages/x86_64/base
src/gz openwrt_luci https://downloads.openwrt.org/releases/23.05.2/packages/x86_64/luci
src/gz openwrt_packages https://downloads.openwrt.org/releases/23.05.2/packages/x86_64/packages
src/gz openwrt_routing https://downloads.openwrt.org/releases/23.05.2/packages/x86_64/routing
src/gz openwrt_telephony https://downloads.openwrt.org/releases/23.05.2/packages/x86_64/telephony
10

Intel CPU/GbE NICs like I340 are pretty standard.
I have a Jetway NF9G-2930 which is Celeron N2930 (slower than your 3455) and 4xi210, still can do 1 Gig throughput, so I don't really think the driver blobs are issue.

So one question, when you are seeing high latency and/or slow throughput, what's the CPU usage? Not sure if some packages eating up CPU resources and causing this.

And, if you manage to have another computer, maybe you can create a fake IP on it's NIC and connect to WAN side of your OpenWrt (so that all tests are internal), then run iperf3 between them. In old days I always do this to test actual throughput of router.

1 Like
11

You see that thread about Chinese malware/back doors? Jetway was one of the companies, specifically, called out..

If you do not want to watch that video DDG Chinese-routers-Wal-mart-backdoor.

12

That's an orthogonal question, regardless of the aspect of this being true or not, that's no answer to the <<10 MBit/s routing throughput reported here. This hardware should be easily fast enough to do 1 GBit/s routing at wirespeed, while still being half asleep (sqm/cake would bring it close to the limit, but I guess it should still make it, at least almost).

"Under 10 MBit/s" rings an alarm bell of eventually the handshake failing to negotiate 1 GBit/s link speed (ethtool will know) and/ or point at an issue with the ethernet (patch-) cables involved, so those are worth testing (replacing). dmesg and htop (enable the display of the core frequencies and temperatures as well) are always worth looking at.

Even if things were going really wrong (including hypothetical harsh exfiltration attempts), you would still expect throughput values in the hundreds of MBit/s from this hardware, so there must be something more fundamental involved.

13

Just a bit of off topic but, I thought, important information.

So sorry I distracted you.

Crap, that is not you 'you'.

Please do not go Herman Melville on me about a post not directed to you.

14

I think you've recognized wrong brand, Jetway is a PC/server motherboard manufacturer based in Taiwan. And the one discussing in video is "Jetstream" which is consumer router brand, actually both WAVLINK/Jetstream with day-0 loophole are well-known for quite some time.

1 Like
15

Time to sleep.
Thanks.

16

Btw., things that would be 'likely' causes include:

  • broken cable
  • broken ports on either side (debris under- or bent pins)
  • EEE being enabled on one end and somehow causing issues
  • overheating (e.g. cooler not sitting correctly, although even then I would expect a bit more than that)
  • some really big software side issue, bringing the CPU down to its knees (things like an IRQ storm, resource conflicts, etc.)
  • interoperability issues between the PHYs involved
  • fundamental chipset/ firmware defects (in the realm of "tx unit hang", or powersave kicking the chipset into a weird state)

The later two wouldn't be that high on my list of suspects though.

Things to check:

  • ethtool
  • dmesg
  • logread
  • htop (under load, with frequencies and temperatures enabled)
  • iperf3 from- and to-, as well as through this board
  • run a random linux live USB stick with kernel v6.1 (e.g. Debian bookworm), test network transfers
    • iperf3 again (no need to set up routing for a first approximation and comparison against the values on OpenWrt)
  • run a random linux live USB stick with a more current kernel (e.g. Fedora), test network transfers
    • iperf3 again (no need to set up routing for a first approximation and comparison against the values on OpenWrt)
  • run a different OS, e.g. OPNsense, for a comparison (this one doesn't work too well from a USB stick, but if you're a bit patient for it to boot up and stay away from the webinterface during the tests, it should still do, somewhat)
    • iperf3 again (no need to set up routing for a first approximation and comparison against the values on OpenWrt)
    • check throughputs

There are further things to approach from there, but the knowledge and relative comparisons from the tests above should help point out further where things might go south

17

Try to install pfsense and check if there is all ok, if not then the problem is deeper.

1 Like
18

I looked into the device driver more...

The Intel I-340 NIC supports the igb kernel module which has been available since 2008. OpenWRT includes igb in its kernel.

19

Turns out the issue was my ISP. Network jitter is now stable and throughput is solid.

This is despite testing the performance of the openwrt router and the netgear router and discerning a significant difference.

Shoutout to Cisco qos /s

20

Usually, when I want to really test the throughput, I will put my own device on WAN side to be a fake ISP, to eliminate external potential issues.

1 Like