Enhancement request: UI buttons to disconnect / reconnect red interface

Networking
22

Let me make sure I’ve covered all the bases… The Comcast modem has been replaced (twice).

The IPFire hardware has been replaced. The original was a Dell Pentium 4 HT with the built-in gigabit Ethernet adapter and a D-Link PCI Ethernet adapter, DGE-530T. Both adapters were used as the red interface at one time.

The current IPFire hardware is an Intel Core i5 system with a pair of PCI Express network adapters:

GREEN (TP-link TG-3478): "pci: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411
PCI Express Gigabit Ethernet Controller (rev 15)" 
GREEN : (54:af:97:14:21:97)

RED (built in)   : "pci: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411
PCI Express Gigabit Ethernet Controller (rev 0c)"
RED   : (14:dd:a9:2a:8a:04)

I have replaced both the red and the green Ethernet cables. I have NOT replaced the Netgear 16 port Ethernet switch(es) or any of the Ethernet cables connected to them but multiple desktop system see the dropouts.

If the cable modem is not in bridge mode, the current IPFire hardware has no measurable dropouts. If the cable modem is in bridge mode, the current (and the previous) IPFire hardware saw dropouts.

In addition with the cable modem in bridge mode and while my desktop is experiencing dropouts, a laptop connected to the cable modem via one of the other three Ethernet ports (with a static IP of 10.0.0.101) and running the same test software doesn’t see any dropouts.

To run the same test tools on a different system connected directly to the cable modem in bridge mode requires that the system run Windows. Attaching a Windows 10 system with a public IP to the internet has, IMO, a high probability of getting infected in very short order.

I’m willing to do this if you all believe it is necessary but I’ll have to build one up from scratch and will wipe the hard drive as soon as I have run whatever experiments you guys want.

I’m more willing to run a live linux system from DVD on the IPFire hardware because that’s just booting from the DVD instead of the hard disk.

As an additional point of reference, I’m a gamer. I can run World of Warcraft or Lord of the Rings Online without losing my connection while the dropouts are occurring. That’s what prompted my comment “I wonder if its just ICMP packets that are getting dropped on the floor?”.

23

One last observation on the conjecture that I have a bad Ethernet cable. I believe if this was the cause of the dropouts, I would see them both in bridge mode and out of bridge mode. The cables don’t care what the IP address is. Similarly if the IPFire hardware was at fault, I believe bridge mode and non-bridge mode would act similarly.

What I do believe is that there is a hardware problem outside of my residence because a traceroute in bridge mode to 75.75.75.75 (Comcast DNS server) is different when in bridge mode and out of bridge mode.

Problem is that Comcast technicians don’t want to pursue this. They would rather state that they are not able to support or troubleshoot with the hardware I have connected to their cable modem.

24

One other thought…

Did you try looking at the cable modem web screens? I am curious if there were any errors in the cable modem log file? Or any low signals?

1 Like
25

I don’t see any “errors” in the log files. I would expect that the Comcast technicians would have examined the logs (and any other indicators) when I contacted them about my problems.

26

:thinking: What is the role of the RPi?

1 Like
27

This is a very plausible hypothesis, however I propose an alternative one for your consideration: bad modem. Not the hardware, as it has been changed two times. No, firmware implementation of the bridging protocol. I think comcast is trying to do a complex setting, whereby you do have a bridge, but also you can connect other appliances if they have a fixed IP or another DHCP server assigns an address to them. This means that the modem will still route traffic to them. This is not how a bridge should work and introduces a layer of complexity, which can sneak in bugs.

If you google “comcast bridge mode malfunctioning” or something like that, you will find an impressive number of reports from other users, and not a clear pattern of resolution. This smells like something above your personal situation and of a difficult to track nature. A bug (or bugs) in the firmware handling of the bridge mode, also been reported in the past, can do that.

I wish you all the best in fixing this annoying problem.

4 Likes
28

:thinking: Or perhaps the answer could be simpler

If I have understood correctly-
Everything works fine if only one device is connected to the modem in bridge mode.

This is according to the instructions on the ISP website

Note: Any ethernet port can be used but only one device can be connected to the gateway while in Bridge Mode.

5 Likes
29

Ah! there you go, this is more reasonable. Good finding @tphz

3 Likes
30

The RPi was connected after a local technician asked for an ethernet cable to plug into the cable modem.

At the time, the complaint was that I was paying for 900Mbits/sec download and only getting 175Mbits/sec. I connected the RPi to the ethernet cable to run a speedtest but the RPi 4 ethernet adapter isn’t capable of saturating the connection. I’ll remove it so I’m playing “by the rules”.

1 Like
31

Well I’m more confused than ever now… I completed the following experiments:

  1. Cable modem in bridge mode, Raspberry Pi 4 connected to modem port 1, nothing else connected. Ran mtr for 30 minutes at a 10 second interval, no dropouts.
  2. Cable modem in bridge mode, IPFire hardware with Linuxmint 20.3 connected to modem port 1, nothing else connected. Ran mtr for 20 minutes at a 10 second interval, no dropouts.
  3. Cable modem in bridge mode, IPFire hardware and software connected to modem port 1, nothing else connected. Ran mtr for 20 minutes at a 10 second interval, 80+% dropouts.
  4. Cable modem not in bridge mode, IPFire hardware and software connected to modem port 1, nothing else connected. Ran mtr for 30 minutes at a 10 second interval, no dropouts.

That says to me that the IPFire software is causing the problem.

With regards to using multiple cable modem ethernet ports when the cable modem is in bridge mode. I have my “land line phone” through Comcast / Xfinity so I believe the modem firmware has to establish its own connection to the internet to use VoIP. Since it has to establish this connection and it has to appear on 10.0.0.1 for its web interface, its not a stretch to allow the other three ethernet ports to support static IPs in the 10.0.0.0/24 range.

With IPFire connected in bridge mode and the RPi 4 connected with a static IP I can run mtr on both simultaneously and I get 80+% dropouts on the public IP and no dropouts on the RPi 4.

So until someone has a bright idea (or even a dim idea :slightly_smiling_face:) I’m going to surrender and run the cable modem with bridge mode disabled and just double NAT.

32

When IPFire is connected in bridge mode it has a public IP. According to the firewall logs, I see 100,000+ dropped packets. Could all this extraneous traffic be causing my dropout problems?

33

Excellent troubleshooting. When you did the setup installing IPFire for the red interface, what connection type did you chose, Static or DHCP. Or something else? Maybe the problem is over there?

Also, while you do your test in bridge mode, can you run on a console to IPFire:

tail -f /var/log/messages

and report some of the logs here? Maybe it can give us some insight on whats going on.

Edit: can it be again the Reverse Path Filter? You should try this. On the IPFire console issue these two commands:

sysctl net.ipv4.conf.default.rp_filter=2
sysctl net.ipv4.conf.all.rp_filter=2

and then repeat your test in bridge mode.

1 Like
34

also the RPi and linuxmint should have had a public IP. Your test is showing that it is something happening in IPFire, the fact that you have so many dropped packets made me consider that these are packets dropped due to the Reverse Path Filter set in strict mode.

1 Like
35

@cfusco Thanks for the excellent suggestions. I went off to gather logs before you edited your message to include the additional reverse path filter stuff so here’s the log output while running mtr on the IPFire console. I’ve included the output of ifconfig as well.

messages.zip (5.7 KB)

I applied those commands and it appears to have made things worse. I’m still getting the dropouts but the mtr output is very strange.

What are the default values so I can set them back?

36

set it to 1

37

I went into the IPFire web interface, Firewall Options and turned off all the Firewall logging options. This required a reboot and it appears that those sysctl settings reverted to the default of 1 (leave off the = and it reports the current values).

mtr is now behaving normally and the dropout rate is down from 80+% to around 30%. Not as good as none but I think we are on the right track.

I wonder why the public IP Xfinity provides has such a large netmask:
inet 71.196.143.121 netmask 255.255.254.0 broadcast 255.255.255.255

Isn’t that about 512 machines worth of traffic I have to see?

38

A reboot reset to 1 by default.

Why is IPFire dropping all those packets on UDP port 2190? Do you have Intrusion Prevention installed? Those packets will still be dropped even if not logged. Something is filtering your inbound traffic and causing your slowdown in IPFire. What is it?

1 Like
39

probably that traffic is legitimate and IPFire filtering causes the flood. I see SYN packets dropped as well.

I hope someone that understand these things will help you out. I am not qualified to say anything useful here.

40

I do not (knowing) have Intrusion Prevention installed. I have no idea what’s going on with 2190 and I have no clue what other filtering is taking place.

Thanks for your help so far. Hopefully we can get to the bottom of this.

41

A quick search showed:

Port Description: Tivo Beacon port for Tivo DVRs to perform auto-discovery of other DVRs and compatible desktop clients

edit:

3 Likes