Google Meet Stopped Working After Core Update 152->153

Getting Started with IPFire Updates Trouble
101

Hi,

well, to the best of my understanding, this is the way things are designed here: Since IPFire cannot know what MTU to set instead of the crappy 576 bytes propagated by the ISP modem, that has to be properly reconfigured manually.

Some connections work fine with an MTU of 1500 bytes. Some others, such as PPPoE dial-up ones, probably won’t. I don’t really think this is a task we can shed from our users’ shoulders.

Thanks, and best regards,
Peter Müller

3 Likes
102

Hi @pmueller, fair point, but we don’t know this for certain yet.

For instance from @prussbw:

The odd thing about this is, after capturing a DHCP exchange between IPFire and my ISP, I don’t see the MTU option (26) being requested or sent at all. It’s obviously dhcpcd that’s passing the setting to the rest of the system, but I can’t see why it’s doing that. It appears to have been doing this since at least Core 152 if not earlier, it’s just that some other change in the packet flow appears to have made the route MTU setting affect Green<->Red packets starting in Core 153.

Does the team have a recommended way to grab DHCP traffic running between IPFire and ISP DHCP Server?

If all of our ISPs end up being at fault, then two questions remain:

  1. Why Post-152 - What exactly changed? Knowing the root cause is always comforting.
  2. May we have a simple method in the IPFire Web Admin to override the default in a configuration setting. This workaround gets clobbered after some updates and a simple way to easily setup and persist this change would be helpful to those of us that are impacted.
103

This is pretty simple!
(from above)

2 Likes
104

I’m inclined to believe that this is incorrect behavior on the part of dhcpcd: If the DHCP server doesn’t specify an MTU (as is happening in my case), I would expect that the route MTU should be left unspecified, thereby letting the interface use its default. Instead, dhcpcd appears to be overruling the interface and setting MTU to the lowest possible setting, which seems over-conservative to me (given the application problems we’ve seen). The only current way to keep it from not specifying an MTU on the route appears to be to disable option interface_mtu completely, which of course has problems of its own from the POV of a widely deployed, general-purpose firewall like IPFire.

I’m considering raising this as a question on the dhcpcd Issues board. Perhaps they have a way around this that we haven’t found yet. However, I don’t want to give the impression that I’m speaking for the IPFire development team, at least without discussing it first. Any suggestions?

2 Likes
105

I use tcpdump, but tshark is also available.

At some point the mechanism changed that dhcpcd uses to enforce the MTU. Instead of changing the MTU of the interface, they add it to the route. This is much better.

And before, we caught 576 as an invalid value (because it is unreasonably small) which we cannot do now because dhcpcd sets the MTU internally.

dhcpcd does not temper with the MTU at all unless it is told to. The modem sends those 576 bytes. That is why it needs to manually be overwritten now.

This makes dhcpcd ignore what the modem is sending, but generally we don’t want this. There are setups where people have a slightly smaller than usual MTU (1492, 1464) in their local networks; and some people are brave and run jumbo frames.

1 Like
106

Hi,

closing this thread for the sake of completeness and transparency, since the issue has been fixed in Core Update 165, although it requires manual interaction (i.e. configuring the appropriate MTU in IPFire).

Thanks, and best regards,
Peter Müller

3 Likes