No link on second NIC after reboot



  • I have a weird issue on my pfsense box. After every reboot, I can't get any link on my second NIC (pcie card). This results in having no WAN IP address. The only way to solve this is to have reassign the interfaces (I get to that in a moment). The hardware configuration is as follows:

    • Lenovo Think Centre Desktop PC
    • re0 Mainboard NIC (according to pciconf): RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
    • re1 Second NIC: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
    • Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
    • 8 GB memory
    • 512 GB SSD drive, ZFS installation

    My test setup looks like this:

    Internet
    -> Company router
    -> private company network with extra DHCP server
    -> pfsense test box
    -> my laptop
    

    After installation I set WAN to re1 and LAN to re0. That way I always have access to the pfsense box if the re1 goes down. Initially I had set up a OpenVPN service but I started over with a fresh install to exclude any issues with that.

    What I've tried so far:

    • Fresh install with BIOS instead of UEFI boot
    • Swapping second NIC into another PCIe port
    • executing /etc/rc.linkup interface=re1 action=stop && /etc/rc.linkup interface=re1 action=start after reboot. This resulted in route: writing to routing socket: Network is unreachable route: route has not been found
    • removing rm -rf /tmp/* in /etc/rc.reboot (I've put it back in :-) )
    • running /etc/rc.reload_interfaces (also results in route: writing to routing socket: Network is unreachable message)

    The ONLY way to solve this after a reboot is to either disable / enable the WAN interface in the webgui or to reassign the interfaces via option 1 in console (although I expect that this will also work in webgui). After this it is working reliably and the WAN is pulling a new address from the company DHCP.

    This is very inconvenient because I want to run the firewall unattended. Is there any solution or workaround? Maybe I can (re-)assign the interfaces via script but I didn't find any resources to that. Also I wanted to ask here if I am missing something before I submit an issue.
    Thanks in advance!

    EDIT: The test box was installed using UFS before. I had the same issue after rebooting, but NOT after reroot. Maybe this helps figuring out what is going on :D


  • LAYER 8

    try with the official driver:

    https://forum.netgate.com/post/934753
    https://forum.netgate.com/post/935026

    pkg add https://pkg.FreeBSD.org/FreeBSD:11:amd64/latest/All/realtek-re-kmod-v196.04_2.txz
    

    Edit /boot/loader.conf.local using "Diagnostics" > "Edit File":

    if_re_load="YES"
    if_re_name="/boot/modules/if_re.ko"
    


  • Thanks for the quick reply! Unfortunately this didn't work. However, I wanted to test if the update was successful with dmesg. I could not find the driver version but I found something else (192.168.192.0/24 is the company subnet):

    arpresolve: can't allocate llinfo for 192.168.192.1 on re1
    (repeat above line ~90 times)
    arpresolve: can't allocate llinfo for 192.168.192.1 on re1
    re1: link state changed to UP
    arpresolve: can't allocate llinfo for 192.168.192.1 on re1
    pflog0: promiscuous mode disabled
    Waiting (max 60 seconds) for system process `vnlru' to stop... done
    Waiting (max 60 seconds) for system process `bufdaemon' to stop... done
    Waiting (max 60 seconds) for system process `syncer' to stop...
    Syncing disks, vnodes remaining... 0 0 done
    All buffers synced.
    Uptime: 2h44m47s
    

    It seems that this was right before I restarted the firewall, assuming that "Uptime: 2h44m47s" is the last message before reboot.


  • LAYER 8

    if it was only at restart
    those messages indicate that he was trying to arp something on a network that is no longer available
    maybe because the network / interface disappear



  • @kiokoman
    anyway, the messages disappeared after the Realtek-Update. The network is always available, at least for the other devices in the network.


Log in to reply