Modify

Opened 9 years ago

Closed 9 years ago

#4522 closed defect (fixed)

mtu_fix should be enabled by default

Reported by: anonymous Owned by: developers
Priority: high Milestone:
Component: base system Version:
Keywords: Cc:

Description

The firewall mtu_fix should be enabled by default. Otherwise, TCP connections do not work properly on smaller MTUs (i.e., all PPP/otherwise tunneled sessions) when ICMP is blocked anywhere in the path (be it at the firewall or ISP level, or more likely at the remote site).

The news page describes mtu_fix as a "workaround for broken Path MTU detection in some buggy ISPs" - so all DSL ISPs are buggy???

Attachments (0)

Change History (6)

comment:1 Changed 9 years ago by oliver@…

As a counterexample, I have a DSL connection (PPPoA) with just the defaults, and it works fine.

comment:2 Changed 9 years ago by oliver@…

It is worth noting that my PPPoA connection has a MTU of 1500 (the default), which is probably helping.

From my memories of dialup connections and playing with MTU settings, the most common cause of PMTU discovery issues was when the ISP end of the PPP connection was on a RFC1918 private IP - which meant that ICMP fragmentation-needed messages never made it back out to the internet at large. Whether or not that happens is very ISP specific. For example the ISP end of my PPPoA connection is a public routable IP address, so it's never going to be an issue here.

If you have a remote site that is blocking inbound ICMP fragmentation-needed messages, that site is fairly broken anyway. Any fragmentation for any reason along the path is going to make PMTU discovery break. The connection at your end is only a small part of that path.

So in summary - no, please don't make mtu_fix the default, I don't want to pay a performance cost for the sake of of some broken ISPs and servers that I don't use anyway.

comment:3 Changed 9 years ago by anonymous

I guess I should have written "PPPoE/otherwise tunneled sessions over Ethernet". Maybe it'd be better if the firewall could detect such situations and enable the mtu_fix as required?

Unfortunately, a lot of the sites that block all ICMP are banks, because they have to comply with silly regulations drawn up by people who have no knowledge of networking...

comment:4 Changed 9 years ago by oliver@…

In the spirit of eating my own dogfood, I'm now running with a MTU of 1478. Nothing's broken.. yet.

The problem with enabling mtu_fix is that it's global and it's really aimed at the case where PMTUD *never* works because your ISP is eating the necessary ICMP messages. That's quite site specific; I'm not sure how you'd detect it automatically.

If you're having problems with only some specific sites, it seems like it would be better to add TCPMSS firewall rules just for those sites?

comment:5 Changed 9 years ago by oliver@…

Having run at MTU=1478 (with a working ISP!) for a day now, I retract my previous comments. I'm up to 6 exceptions for remote hosts that have broken PMTUD (e.g. they block all ICMP) and climbing. It seems common enough that enabling MSS clamping by default seems reasonable - you're going to be bitten by it regardless of what your ISP is doing.

I am also suspicious about what the real performance cost is. As far as I can see, TCPMSS clamping won't do anything that wouldn't happen anyway with a large MSS that gets reduced when ICMP fragmentation needed messages turn up. Asking about that on openwrt-devel, since bug tracking systems suck for discussion :)

comment:6 Changed 9 years ago by cyrus

  • Resolution set to fixed
  • Status changed from new to closed

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.