Can you help me with the Intel i225-v network adapter?

How do you tell that? Aquantio is the other adapter, not the Intel I225, or did I misunderstand you?
There is a „aq“-driver for that device in OpenBSD. Could you use that one?

As for the Intel device: how about the FreeBSD driver from the Intel dowliad section? Any chance to get it working?
 
I have a media server with I225-V NICs, and which boots from USB, so I copied FreeBSD 14.0 RELEASE ISO onto a USB stick, booted it into a rescue shell, and gathered the diagnostic information we need to see. This I225-V NIC is working:
Code: 
# ifconfig igc0
        igc0: flags=1008802<BROADCAST,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        options=4e427bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
        ether 00:e2:69:58:bb:5d
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

# pciconf -lv | grep -B 4 ethernet    # first NIC only
igc0@pci0:1:0:0:        class=0x020000 rev=0x03 hdr=0x00 vendor=0x8086 device=0x15f3 subvendor=0x8086 subdevice=0x0000
    vendor     = 'Intel Corporation'
    device     = 'Ethernet Controller I225-V'
    class      = network
    subclass   = ethernet

# ifconfig igc0 inet 192.168.1.249 netmask 255.255.255.0 up

# ifconfig igc0
igc0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        options=4e427bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
        ether 00:e2:69:58:bb:5d
        inet 192.168.1.249 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

# ping -c5 192.168.1.254    # my local network (default) router
PING 192.168.1.254 (192.168.1.254): 56 data bytes
64 bytes from 192.168.1.254: icmp_seq=0 ttl=64 time=1.441 ms
64 bytes from 192.168.1.254: icmp_seq=1 ttl=64 time=0.577 ms
64 bytes from 192.168.1.254: icmp_seq=2 ttl=64 time=0.561 ms
64 bytes from 192.168.1.254: icmp_seq=3 ttl=64 time=0.559 ms
64 bytes from 192.168.1.254: icmp_seq=4 ttl=64 time=0.573 ms

--- 192.168.1.254 ping statistics ---
 
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.559/0.742/1.441/0.349 ms

# ssh -Y 192.168.1.22    # my FreeBSD daily driver -- ssh will fail but will test the network connection
The authenticity of host '192.168.1.22 (192.168.1.22)' can't be established.
ED25519 key fingerprint is SHA256:+Xl2f6J5ruCrNm6gafcmxMkGtMjpil0oI4RSyk4BhaQ.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Could not create directory '/root/.ssh' (Read-only file system).
Failed to add the host to the list of known hosts (/root/.ssh/known_hosts).
root@192.168.1.22: Permission denied (publickey).

# netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
127.0.0.1          link#5             UH          lo0
192.168.1.0/24     link#1             U          igc0
192.168.1.249      link#5             UHS         lo0

Internet6:
Destination                       Gateway                       Flags     Netif
Expire
::/96                             link#5                        URS         lo0
::1                               link#5                        UHS         lo0
::ffff:0.0.0.0/96                 link#5                        URS         lo0
fe80::%lo0/10                     link#5                        URS         lo0
fe80::%lo0/64                     link#5                        U           lo0
fe80::1%lo0                       link#5                        UHS         lo0
ff02::/16                         link#5                        URS         lo0
Try these things, and give us the details of any differences that you see.
 
Now that I can connect to my FreeBSD-Installation in my home network using a USB-Ethernet-device via ssh having the shell on my MacBook, it's much easier to copy&paste things.
Here we go:

ifconfig igc0 -->
igc0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=4e427bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,
TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
ether 08:bf:b8:19:13:33
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

Trying to force it as suggested did not help.

pciconf -lv | grep -B 4 ethernet -->
igc0@pci0:12:0:0: class=0x020000 rev=0x03 hdr=0x00 vendor=0x8086 device=0x15f3 subvendor=0x1043 subdevice=0x87d2
vendor = 'Intel Corporation'
device = 'Ethernet Controller I225-V'
class = network
subclass = ethernet

pinging my router (remember, this is via the USB-device, not via idc):
PING 192.168.178.1 (192.168.178.1): 56 data bytes
64 bytes from 192.168.178.1: icmp_seq=0 ttl=64 time=2.739 ms
64 bytes from 192.168.178.1: icmp_seq=1 ttl=64 time=2.699 ms
64 bytes from 192.168.178.1: icmp_seq=2 ttl=64 time=0.810 ms
64 bytes from 192.168.178.1: icmp_seq=3 ttl=64 time=1.194 ms
64 bytes from 192.168.178.1: icmp_seq=4 ttl=64 time=0.709 ms

ssh -Y 192.168.178.60 (this is another PC on my home network)
ssh: connect to host 192.168.178.60 port 22: Connection refused

netstat -rn
Routing tables

Internet:
Destination Gateway Flags Netif Expire
default 192.168.178.1 UGS ue0
127.0.0.1 link#1 UH lo0
192.168.178.0/24 link#2 U ue0
192.168.178.114 link#1 UHS lo0

Internet6:
Destination Gateway Flags Netif Expire
::/96 link#1 URS lo0
::1 link#1 UHS lo0
::ffff:0.0.0.0/96 link#1 URS lo0
fe80::%lo0/10 link#1 URS lo0
fe80::%lo0/64 link#1 U lo0
fe80::1%lo0 link#1 UHS lo0
ff02::/16 link#1 URS lo0
 
mettmusik said:
subvendor=0x1043 subdevice=0x87d2
Click to expand...
So it is *not* a standard Intel variant and god knows what "optimizations" asus did to the firmware...
The specs contain something about "ASUS LANGuard". Whatever it does, if you are lucky this can be turned off in the BIOS.
 
it looks like it does get a link in the end

media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
 
The good news is that the link was up -- and that's an improvement on your original problem statement.

The only thing you did not do was to bring up the interface and test behaviour. I know that's a challenge. But, since you now know what to expect, and what "correct" behaviour is, you could test the NIC the same way I did, above. i.e. boot from USB ISO, select "shell" instead of "install" bring the interface up manually (with an appropriate IP address and netmask), make sure the output from ifconfig igc0 looks right, and see if you can ping something.

If that test fails, then you have verified that your NIC won't work with FreeBSD, the probable cause is "subvendor=0x1043 subdevice=0x87d2", and you need to investigate the firmware issues identified by sko.
 
there is this thread with somebody with the same nic
forums.freebsd.org

Solved - Network adapter issues.

Hello, Gang: First, due to going through medical hell since January 2021, I have not been active on this forum for some time now. And secondly, due to the foregoing, I have forgotten several matters having to do with FreeBSD, which I had installed on my office desktop. Then, a couple of months...
forums.freebsd.org forums.freebsd.org
but there is no final resolution on it
but the thread starter seems to be still active so you can ping him
 
gpw928 said:
boot from USB ISO, select "shell" instead of "install" bring the interface up manually (with an appropriate IP address and netmask), make sure the output from ifconfig igc0 looks right, and see if you can ping something.
Click to expand...
You could bring up the interface with dhclient igc0 for testing DHCP from installer LiveCD.
 
maybe you also want to run a tcpdump in parallel to that on the interface to see if it's actually sending (or receiving) anything: tcpdump -ntttvi igc0
 
The igc driver works fine (14.0-RELEASE at least) with this motherboard however, using anything later than BIOS 1602 causes allocation errors with multiple device. I don't think that issue is the cause here but I can't say for sure.
Are you connecting this to a 2.5Gbit switch or 1G? Tried using another cable and/or switch? The Marvell controller currently lacks a driver so that wont work for now at least.
During init dmesg looks like this:
Code: 
diizzy@miyuki:~ % dmesg |grep igc0
igc0: <Intel(R) Ethernet Controller I225-V> mem 0xebe00000-0xebefffff,0xebf00000-0xebf03fff at device 0.0 on pci9
igc0: Using 1024 TX descriptors and 1024 RX descriptors
igc0: Using 4 RX queues 4 TX queues
igc0: Using MSI-X interrupts with 5 vectors
igc0: Ethernet address: REDACTED
igc0: netmap queues/slots: TX 4/1024, RX 4/1024
igc0: link state changed to UP
igc0: link state changed to DOWN
igc0: link state changed to UP

diizzy@miyuki:~ % ifconfig igc0
igc0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        options=4e427bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
        ether REDACTED
        inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

I don't have any 2.5G capable hardware so I can't test connectivity at such speeds.
 
Last edited:
root@schreibtisch:/home/chris # dhclient igc0
DHCPDISCOVER on igc0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on igc0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on igc0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on igc0 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on igc0 to 255.255.255.255 port 67 interval 20
DHCPDISCOVER on igc0 to 255.255.255.255 port 67 interval 9
No DHCPOFFERS received.
No working leases in persistent database - sleeping.


sko You are blaming ASUS for not using standards. But on Linux the I225-v interface works perfectly fine with the open source kernel drivers.
 
I use a 1G connection.
Why should I use other cable etc,, when the same hardware on works fine booting Linux or Windows.
 
mettmusik said:
Halleluja, got internet with the usb network adapter. Had to recompile the kernel, but it works.

bakul
igc00pci0:12:0:0: class= 0x02000 rev=0x03 hdr=0x00 vendor=0x1d6a device=0x94c0 subvendor=0x1043 subdevice=0x87f5

sorry not having it posted in the first place.

Can you further assist me in bringing the igc-device up or at least understand why it will not work?
Click to expand...
I notice the Times in your posts. They are seconds apart. Recopile the kernel. I did that in Linux in the 90s. Never again.
 
mettmusik said:
sko You are blaming ASUS for not using standards. But on Linux the I225-v interface works perfectly fine with the open source kernel drivers.
Click to expand...
It's entirely possible that ASUS provided assistance to the Linux community to tweak the igc driver for Linux to work on their motherboard.

It's not a huge surprise that dhclient(8) does not work. It is, after all, the default mechanism used by FreeBSD install. And you have already attested to failure there.

One other thing you can do to improve confidence in the cabling and switch is just bring up the interface without an IP address ifconfig igc0 up and watch tcpdump -n -i igc0. That should show you packets flying across the LAN (with the correct IP addresses for the subnet).

diizzy tells us above that he has the igc(4) driver working on your motherboard. So you have some encouraging news there. Have you checked your BIOS revision?

My advice above was to test the most basic TCP/IP functions with minimal need for external infrastructure support (like DHCP server). I suggested that because you FIRST need to understand if the IP stack can be made to work at the network level.
 
tcpdump -n -I igc0 -->
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on igc0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel
 
Please confirm that the interface was brought up with ifconfig igc0 up and had an ethernet cable plugged in to the LAN before you ran tcpdump.
 
That suggests that the NIC is completely non-functional.

Are you able to boot Linux from a live ISO and repeat the test (without making any changes to the network or cabling)?

You indicated above that you have a custom kernel, so I would also boot FreeBSD from a live ISO and repeat the test.

You also still need to tell us about the firmware revision.
 
Would a Linux installation on another partition on the same computer be sufficient or does it have to be a live medium?
 
I'm assuming that Linux will come up using igc0 as it's principal NIC, so functional testing should not be difficult. The reason to test Linux is to simply confirm that igc0 can be made to work with exactly the same network configuration as you use for FreeBSD.

The inference we draw from the failure of tcpdump is that your NIC simply does not work at all with FreeBSD, but we need to confirm this, without any changes applied to the network, and with a known good FreeBSD kernel. Hence the suggestion to test with a FreeBSD live ISO kernel from the release media:
Code: 
ifconfig igc0 up
tcpdump -n -i igc0
^C
ifconfig igc0 down
ifconfig igc0 inet 192.168.178.<spare-ip> netmask 255.255.255.0 up
ping 192.168.178.1
These two tests should be definitive, provided you change nothing related to the network.
 
You must log in or register to reply here.
Back
Top