Red disconnects every ~30 secs

Networking
1

Having an issue where the RED I/F is dropping every ~30 secs… It reconnects on its own, but can take a few secs. So not usable.
This is a new ISP (Nortex) using fiber to a GigaSpire Blast u6x GS4227 in (I’m assuming) bridge mode, so that I get the public IP. WiFi is disabled.
The RED NIC is showing as “pci: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)” and works fine with my Motorola MB8600 cable modem on Suddenlink.
Has anybody seen this or similar issues ?
Thanks

Kernel log

Time Section
20:10:07 kernel: ll header: 00000000: ff ff ff ff ff ff d4 6d 50 37 32 c1 08 00
20:10:07 kernel: IPv4: martian source 255.255.255.255 from 23.252.240.1, on dev red0
20:10:07 kernel: ll header: 00000000: ff ff ff ff ff ff d4 6d 50 37 32 c1 08 00
20:10:07 kernel: IPv4: martian source 255.255.255.255 from 23.252.240.1, on dev red0
20:10:07 kernel: ll header: 00000000: ff ff ff ff ff ff d4 6d 50 37 32 c1 08 00
20:10:07 kernel: IPv4: martian source 255.255.255.255 from 23.252.240.1, on dev red0
20:10:05 kernel: r8169 0000:30:00.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
20:10:02 kernel: r8169 0000:30:00.0 red0: Link is Down
20:10:02 kernel: RTL8211DN Gigabit Ethernet r8169-0-3000:00: attached PHY driver (mii_bus:phy_add r=r8169-0-3000:00, irq=MAC)
20:10:01 kernel: r8169 0000:30:00.0 red0: Link is Down
20:09:06 kernel: ll header: 00000000: ff ff ff ff ff ff d4 6d 50 37 32 c1 08 00
20:09:06 kernel: IPv4: martian source 255.255.255.255 from 23.252.240.1, on dev red0
20:09:06 kernel: ll header: 00000000: ff ff ff ff ff ff d4 6d 50 37 32 c1 08 00
20:09:06 kernel: IPv4: martian source 255.255.255.255 from 23.252.240.1, on dev red0
20:09:06 kernel: ll header: 00000000: ff ff ff ff ff ff d4 6d 50 37 32 c1 08 00
20:09:06 kernel: IPv4: martian source 255.255.255.255 from 23.252.240.1, on dev red0
20:09:04 kernel: r8169 0000:30:00.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
20:09:02 kernel: r8169 0000:30:00.0 red0: Link is Down
20:09:02 kernel: RTL8211DN Gigabit Ethernet r8169-0-3000:00: attached PHY driver (mii_bus:phy_add r=r8169-0-3000:00, irq=MAC)
20:09:01 kernel: r8169 0000:30:00.0 red0: Link is Down

RED log

Time Section
20:10:07 dhcpcd[21767] : red0: probing address 23.252.247.32/24
20:10:07 dhcpcd[21767] : red0: ignoring offer of 23.252.247.32 from 65.162.73.30
20:10:07 dhcpcd[21767] : red0: offered 23.252.247.32 from 65.162.73.30
20:10:06 dhcpcd[21767] : red0: soliciting a DHCP lease
20:10:05 dhcpcd[21767] : red0: soliciting an IPv6 router
20:10:05 dhcpcd[21767] : ipv6_addaddr1: Permission denied
20:10:05 dhcpcd[21767] : red0: adding address fe80::9ade:d0ff:fe06:b822
20:10:05 dhcpcd[21767] : red0: IAID d0:06:b8:22
20:10:05 dhcpcd[21767] : red0: carrier acquired
20:10:03 dhcpcd[21767] : red0: waiting for carrier
20:10:02 dhcpcd[21767] : DUID 00:04:22:bb:2e:45:59:07:11:df:bb:da:d7:25:d5:03:2c:27
20:10:02 dhcpcd[21764] : dhcpcd-9.4.1 starting
20:10:01 dhcpcd[20630] : red0: deleting default route via 23.252.247.1
20:10:01 dhcpcd[20630] : red0: deleting route to 23.252.247.0/24
20:10:01 dhcpcd[20630] : red0: releasing lease of 23.252.247.32
20:10:01 dhcpcd[21520] : waiting for pid 20629 to exit
20:10:01 dhcpcd[20630] : red0: removing interface
20:10:01 dhcpcd[20630] : received SIGALRM, releasing
20:10:01 dhcpcd[21520] : sending signal ALRM to pid 20629
20:09:12 dhcpcd[20630] : red0: adding default route via 23.252.247.1
20:09:12 dhcpcd[20630] : red0: adding route to 23.252.247.0/24
20:09:12 dhcpcd[20630] : red0: leased 23.252.247.32 for 498556 seconds
20:09:06 dhcpcd[20630] : red0: probing address 23.252.247.32/24
20:09:06 dhcpcd[20630] : red0: ignoring offer of 23.252.247.32 from 65.162.73.30
20:09:06 dhcpcd[20630] : red0: offered 23.252.247.32 from 65.162.73.30
20:09:06 dhcpcd[20630] : red0: soliciting a DHCP lease
20:09:05 dhcpcd[20630] : red0: soliciting an IPv6 router
20:09:04 dhcpcd[20630] : ipv6_addaddr1: Permission denied
20:09:04 dhcpcd[20630] : red0: adding address fe80::9ade:d0ff:fe06:b822
20:09:04 dhcpcd[20630] : red0: IAID d0:06:b8:22
20:09:04 dhcpcd[20630] : red0: carrier acquired
20:09:02 dhcpcd[20630] : red0: waiting for carrier
20:09:02 dhcpcd[20630] : DUID 00:04:22:bb:2e:45:59:07:11:df:bb:da:d7:25:d5:03:2c:27
20:09:02 dhcpcd[20627] : dhcpcd-9.4.1 starting
20:09:01 dhcpcd[20383] : waiting for pid 19295 to exit
2

@cmspencer , welcome to the IPFire community.

Your kernel log shows many ‘martians’. These usually are produced by bad network connections.
If you get a public IP of 23.252.247.32 in 23.253.247.0/24 a broadcast from 23.252.240.1 should not occur.
Have you connected your fibre modem the same way as the cable modem? Just to be sure. :wink:
Can you establish a stable connection, if you connect a PC directly?

3

Hi.

If you have many “martians”, maybe you connect accidentally switch with router bypassing IPFire.

This is my gram of sand.

Chers.

4

Thanks Bernhard.
I have the fibre modem connected in the same way, however it’s not a modem as such, but a router with WiFi (Disabled). The ISP has put it into bridge mode (I assume) and tied port 1 of the 4 port switch to the MAC address of the RED I/F.
I did get them to change it and try a different NIC, but still the same issue.
I did test by changing the MAC address on my laptop (Win 11), so that it matches the registered one, and connecting directly to the GigaSpire Port 1, with this I do not see the issue occurring on my laptop.

5

Sounds like failure to auto negotiate port speed. Rare, but it happens when firmware/settings between two network devices are not agreeable. I suggest logging into the mode/router and locking down the port speed on the port used. Also take a look at frame size if available (on the modem) to make sure it is not set at a size the firewall NIC cannot handle.

1 Like
6

@cmspencer: Because there isn’t much traffic besides connection establishment and termination, you can log the traffic on red interface with tcpdump -i red0 -w wan.cap (stop with Ctrl-C ). This logfile wan.cap can be viewed and analysed with Wireshark ( for example ).

7

One of the things noticed during troubleshooting is that the ISP’s router is sending an ARP request and appears for some reason to be coinciding with the RED IF to dropping.

8

It looks like it may be a hardware/BIOS related issue as I built a new IPFire on another box (HP Elite) and I’m not getting the same problem. Could it be Processor Vulnerability Mitigations code ?
I still have to swap over the NIC from my current box to the new one to confirm it’s not NIC related and resolve the issue. The new box is a newer and a higher spec, so I was going to have to do it at some point !
Old: fireinfo.ipfire.org - Profile 36f27c6e905e30d5b109c15df90688b14002cb73
New: fireinfo.ipfire.org - Profile 90a6e5582f28c83ed3e197205a8c1f05aca16825