Ethernet unreachable if cable unplugged and plugged again

freezr

freezr

Hi guys,

I am sorry for the stupid title.

I have an headless mini pc that I connect with SSH, the cable I use (and that I should replace) is loosing so it may happen the day after I have to replug it correctly, and here is where happens the issue: when I replug the cable I can't ssh anymore, the only solution, is to plug a keyboard and blindly type service netif restart and crossing the fingers.

Is there a way to prevent this behavior? Should I check on the bios setting first?

Thanks... 🙏
 
freezr said:
Is there a way to prevent this behavior?
Click to expand...
Shouldn't happen to begin with. What's the make and model of the network interface? What driver is attached? Is it DHCP or statically configured?

I plug and unplug ethernet all the time. It might take a second for the interface to become active again, but have never needed to restart anything.
 
Hi SirDice

This is the model:
Code: 
pciconf -lv | grep -A1 -B3 eth
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet

The network is static:
Code: 
ifconfig_re0="inet 10.0.10.1 netmask 255.255.255.0"

Code: 
ifconfig re0
re0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
    options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
    ether e0:51:d8:17:8d:cd
    inet 10.0.10.1 netmask 0xffffff00 broadcast 10.0.10.255
    media: Ethernet autoselect (1000baseT <full-duplex,master>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

Some logs from the previous session:
Code: 
Dec  1 20:15:45 gpc kernel: re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0x3000-0x30ff mem 0x80404000-0x80404fff,0x80400000-0x80403fff at device 0.0 on pci2
Dec  1 20:15:45 gpc kernel: re0: Using 1 MSI-X message
Dec  1 20:15:45 gpc kernel: re0: ASPM disabled
Dec  1 20:15:45 gpc kernel: re0: Chip rev. 0x54000000
Dec  1 20:15:45 gpc kernel: re0: MAC rev. 0x00100000
Dec  1 20:15:45 gpc kernel: miibus0: <MII bus> on re0
Dec  1 20:15:45 gpc kernel: re0: Using defaults for TSO: 65518/35/2048
Dec  1 20:15:45 gpc kernel: re0: Ethernet address: e0:51:d8:17:8d:cd
Dec  1 20:15:45 gpc kernel: re0: netmap queues/slots: TX 1/256, RX 1/256
Dec  1 20:15:45 gpc kernel: re0: link state changed to UP
Dec  1 20:15:45 gpc kernel: re0: link state changed to DOWN
Dec  1 20:15:45 gpc kernel: re0: link state changed to UP
Dec  1 20:42:11 gpc kernel: re0: link state changed to DOWN
Dec  2 13:07:27 gpc kernel: re0: link state changed to UP
Dec  2 13:09:51 gpc kernel: re0: link state changed to DOWN
Dec  2 13:10:35 gpc kernel: re0: link state changed to UP
Dec  2 13:12:11 gpc kernel: re0: link state changed to DOWN
Dec  2 13:12:14 gpc kernel: re0: link state changed to UP
Dec  2 13:14:22 gpc kernel: re0: link state changed to DOWN
Dec  2 13:14:36 gpc kernel: re0: link state changed to UP
Dec  2 13:15:12 gpc kernel: re0: link state changed to DOWN
Dec  2 13:15:15 gpc kernel: re0: link state changed to UP
Dec  2 13:16:10 gpc kernel: re0: link state changed to DOWN
Dec  2 13:16:17 gpc kernel: re0: link state changed to UP
Dec  2 13:19:09 gpc kernel: re0: link state changed to DOWN
Dec  2 13:19:13 gpc kernel: re0: link state changed to UP
Dec  2 14:02:13 gpc kernel: re0: link state changed to DOWN
Dec  2 14:02:17 gpc kernel: re0: link state changed to UP
Dec  2 16:31:33 gpc kernel: re0: link state changed to DOWN
Dec  2 16:31:37 gpc kernel: re0: link state changed to UP
Dec  2 16:55:47 gpc kernel: re0: link state changed to DOWN
Dec  2 16:55:51 gpc kernel: re0: link state changed to UP
Dec  2 19:30:06 gpc kernel: re0: link state changed to DOWN
Dec  2 19:30:10 gpc kernel: re0: link state changed to UP
Dec  2 20:35:34 gpc kernel: re0: link state changed to DOWN
Dec  3 12:38:32 gpc kernel: re0: link state changed to UP
Dec  3 12:45:52 gpc kernel: re0: link state changed to DOWN
Dec  3 12:45:54 gpc kernel: re0: link state changed to UP
Dec  3 12:47:20 gpc kernel: re0: link state changed to DOWN
Dec  3 12:47:28 gpc kernel: re0: link state changed to UP
Dec  3 12:52:59 gpc kernel: re0: link state changed to DOWN
Dec  3 12:53:04 gpc kernel: re0: link state changed to UP
Dec  3 12:59:30 gpc kernel: re0: link state changed to DOWN
Dec  3 12:59:34 gpc kernel: re0: link state changed to UP

Maybe the ethernet goes in some kind of hibernation? 🤷‍♂️
 
It seems to flap a lot (UP, DOWN, UP, DOWN, UP, DOWN), that's never good and probably due to the bad cable. It's possible the card ends up in some weird state because of it. Definitely replace that cable.
 
Ethernet has 4 wire pairs (8 wires in total), each pair carries a differential signal. Those pairs are twisted in the cable (hence the name; twisted pair; the TP in UTP). The signals come in on the PHY of a network interface where the differential (analog) signal get translated back into digital ones and zeros and handled by the other part of the network chip. When you have a bad cable, bad connection, or a combination, you can get missing signals, spikes, interference, noise, etc. It's possible the PHY part of the chip can't make sense of it any more. Turning it off and on again (what netif restart basically does) might return it back to a working state. Or not, and may need an actual power off (switching the entire computer off). Or it may even get destroyed entirely, although that's rare, there's lots of safety builtin. I haven't fried a network card in ages and I do a lot of tinkering.
 
I forgot to mention this is a cross-cable it provides a direct connection between the two computers it doesn't pass through a router/switch.
 
I installed it.

Code: 
Message from realtek-re-kmod-1101.00.1500068:

--
Add the following lines to your /boot/loader.conf
to override the built-in FreeBSD re(4) driver.

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

By default, the size of allocated mbufs is enough
to receive the largest Ethernet frame supported
by the card.  If your memory is highly fragmented,
trying to allocate contiguous pages (more than
4096 bytes) may result in driver hangs.
For this reason the value is tunable at boot time,
e.g. if you don't need Jumbo frames you can lower
the memory requirements and avoid this issue with:

hw.re.max_rx_mbuf_sz="2048"

To enable Wake on LAN (WoL) support you might need
to set the following tunables:

hw.re.s5wol="1"
hw.re.s0_magic_packet="1"

If you experience network hangs with IPv6 enabled,
you might need to disable the checksum offloading
by adding the following parameters to the related
ifconfig line in your /etc/rc.conf file:

-rxcsum -txcsum -rxcsum6 -txcsum6

I wonder if I should enable WoL as well... 🤔
 
You must log in or register to reply here.
Back
Top