Intel i225/i226 2.5G NIC Information/Issue Tracking Thread

[meyergru]

You probably missed that the paper is from 2018 and it applies to I210 with a FreeBSD 11.1 kernel, not to your I225 on FreeBSD 13.2. If certain parameters are absent now, it may be a strong indication of that the paper or better insight in general has led to advances in the areas discussed and structural changes made those parameters dispensable now.

The internet is full of outdated material that simply does not apply any more.

[deltaexray]

Hey y'all,

stumbled across this thread almost the same day I ordered my Firewall Barebone on Amazon. If you wanna take a look, just search for HUNSN RJ35 Core I3-N305 Firewall Barebone.

The Intel Chips are all the following:
Intel
S2363L10
SRKTU

All four of them, so I'll just throw it in here.

Cheers
Alex'

[Seimus]

I was able to open my box for cleaning/maintenance as well small upgrade I am currently testing a N100 on OPNsense. I did adjust my comment with proper OPcodes, here are as well pictures.

Regards,
S.

[aramova]

Hey all,

I've got one of these Intel N305-6Ls with 6 I226-v ports.

When I connect it to my Asus AX11000, Raspberry Pi 4, or to my Mac via USB Ethernet I can iperf3 full bore 900+mbit/s bi-directional just fine for hours, no issue. Burn in on 3 interfaces for 24 hours resulted in ~0.7% packet loss on one interface, other two under 0.3% at ~920/900mbit bidirectionally.

When connected to the Verizon ONT everything works fine for ~5 minutes, after which the WAN connection stops responding. All traffic ends, ICMP pings RTO.

ifconfig down/up bring the interface back online, as will reseating the cable. After 5 or so minutes, it will stop again.

After trying a number of tuneables, settings tweaks, different cables even though they all work fine with the Asus, the result is the same. The WAN will only stay online for ~5-15 minutes tops, after which it dies, awaiting for you to bounce it or reseat the cable.

 No errors are reported anywhere.

The exact same cable has zero issues when connected to the Asus AX11000.

The interface on the OPNSense doesn't flap, it just stops responding.

Checking the interface status with ifconfig shows it is still connected, has an IP, is up, but no traffic responds.

pfctl -d to turn off the firewall doesn't change anything. I've eliminated firewall or IDS as a potential I believe.

I have plugged the OPNSense into the Asus as a client treating the AX11000 as a gateway and it worked fine for days, left it running on my office without a problem.

It seems like some sort of incompatibility between the ONT and i226 as everything else checks out, I just can't pinpoint it.

Has anyone else overcome this, or worked around it?

Code Select Expand

opnsense-version
OPNsense 25.1.6_2 (amd64)
FreeBSD OPNsense.localdomain 14.2-RELEASE-p3 FreeBSD 14.2-RELEASE-p3 stable/25.1-n269769-0381600e81a4 SMP amd64


Code Select Expand

kldstat
Id Refs Address                Size Name
 1   60 0xffffffff80200000  1f689d8 kernel
 2    3 0xffffffff82169000    8f960 pf.ko
 3    1 0xffffffff821f9000     3c10 pflog.ko
 4    1 0xffffffff821fd000   5da630 zfs.ko
 5    1 0xffffffff827d8000    1e280 opensolaris.ko
 6    1 0xffffffff827f7000    11a18 pfsync.ko
 7    1 0xffffffff82809000     fb90 carp.ko
 8    1 0xffffffff8281a000     4be0 if_enc.ko
 9    1 0xffffffff8281f000     aa30 if_gre.ko
10    1 0xffffffff8282a000    16608 if_lagg.ko
11    2 0xffffffff82841000     3558 if_infiniband.ko
12    1 0xffffffff833ab000     ea40 if_bridge.ko
13    2 0xffffffff833ba000     8918 bridgestp.ko
14    1 0xffffffff83de5000     6020 ig4.ko
15    1 0xffffffff83dec000     4250 ichsmb.ko
16    1 0xffffffff83df1000     2178 smbus.ko
17    1 0xffffffff83df4000     3390 acpi_wmi.ko
18    1 0xffffffff83df8000     3360 uhid.ko
19    1 0xffffffff83dfc000     4364 ums.ko
20    1 0xffffffff83e01000     20f0 coretemp.ko

Code Select Expand

sysctl -a | grep rx_process_limit
hw.vtnet.rx_process_limit: 1024

Code Select Expand

pciconf -llcvVBa igc0
drv selector class    rev  hdr  vendor device subven subdev
igc0@pci0:1:0:0: 020000   04   00   8086   125c   8086   0000
    vendor     = 'Intel Corporation'
    device     = 'Ethernet Controller I226-V'
    class      = network
    subclass   = ethernet
    cap 01[40] = powerspec 3  supports D0 D3  current D0
    cap 05[50] = MSI supports 1 message, 64 bit, vector masks
    cap 11[70] = MSI-X supports 5 messages, enabled
                 Table in map 0x1c[0x0], PBA in map 0x1c[0x2000]
    cap 10[a0] = PCI-Express 2 endpoint max data 256(512) FLR RO NS
                 max read 512
                 link x1(x1) speed 5.0(5.0) ASPM disabled(L1)
    ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected
    ecap 0003[140] = Serial 1 a8b8e0ffff048d8a
    ecap 0018[1c0] = LTR 1
    ecap 001f[1f0] = Precision Time Measurement 1
    ecap 001e[1e0] = L1 PM Substates 1


Code Select Expand

[00:001:00:00]: Intel(R) Ethernet Controller I226-V
        Vendor                 : 8086
        Device                 : 125C
        Subvendor              : 8086
        Subdevice              : 0000
        Revision               : 4
        LAN MAC                : A8B8E0048D8A
        Alt MAC                : 000000000000
        SAN MAC                : 000000000000
        ETrackId               : 800003AD
        SerialNumber           : A8B8E0FFFF048D8A
        NVM Version            : 2.37(2.25)
        PBA                    : G23456-000
        VPD status             : Not set
        VPD size               : 0
        NVM update             : No config file entry
          checksum             : Valid
        OROM update            : No config file entry
          CIVD                 : 0.0.0
          EFI                  : 0.1.5, checksum None

[EricPerl]

You might want to check you're not "leaking" RFC1918 IPs on the WAN side.
Apparently, some ISPs don't like that at all and stop all traffic.

There was a thread like this a few days back (static? IP from a printer in a range not covered by any LANs, probably leftover on a PC).

You might be able to track it down from a packet capture.
Some folks apparently use an out rule on WAN to prevent it altogether.

[aramova]

You might want to check you're not "leaking" RFC1918 IPs on the WAN side.
Apparently, some ISPs don't like that at all and stop all traffic.

Over the weekend I picked up a cheap TP-Link 2.5gbit unmanaged 5 port switch and placed it inline between the ONT and OPNSense device, the connection has been solid since with no drop outs.

The cable going to the switch is the same that was being used -- only difference is introduction of a switch.

Makes me believe the IP leaking to WAN side isn't the root cause. I've seen a significant number of posts and discussions around Intel, manufacturer, and networking forums discussing the i226 and different ONT issues. Kept most of the notes here if they're useful to anybody. The latest NVM I could find being 2.25 for the i226 didn't help me, others said it did help them.

For me placing a 5 port dumb switch who's only purpose is to act as a Layer 2 intermediary having only the ONT and OPNSense connected solved the problem.

Hopefully some day in the future intel or Verizon FiOS will patch this and I can remove it, it's just another device in the mix to power, and fail.

[EricPerl]

I agree with your conclusion.

Someone has done their research in these articles!
I'm still on 2.17 on a brand new mini-PC. The upgrade process looks a bit daunting (I'm glad I kept the original SSD with Windows in case I need to go down that path).
I have a Nokia ONT as well (exact model number unclear) but I'm not on Verizon.

No obvious issues for now but I've switched to this new box a week ago (I've been running i226-V before, but under proxmox).