Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised

Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised

Post by Mark Hoble » Mon, 23 May 2011 22:27:44




> It seems to me it's more likely that you're doing something wrong --
> people would immediately notice if these parts of the Linux kernel
> broke! Is it the right route? Are there others?  What does route -ne
> say?

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.0.1        0.0.0.0         UG        0 0          0 eth0
10.0.0.0        0.0.0.0         255.255.255.0   U         0 0          0 eth0

That is interesting. Shouldn't the MSS be 1392 in the top line?

Quote:> I also can't help wondering if you have caused all these problems
> somehow. If the ISP breaks things like this, it's commercial suicide --
> unless they somehow manage to keep Windows unaffected ...

Yeah. They don't support Linux at all.

--
Mark Hobley
Linux User: #370818  http://markhobley.yi.org/

 
 
 

Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised

Post by Tauno Voipi » Tue, 24 May 2011 01:59:15





>>> However, examining the binary version of the above file for strings, I can
>>> see that fragments of the usenet data are being retransmitted.

>> Most likely the isp, or an isp in between your system and e-s is giving
>> nntp traffic a low priority, causing packets to timeout.

> Why should that affect /all/ his large segments, and /only/ the large
> segments? It seems very unlikely to me.

> /Jorgen

For me, this smells that someone under way has firewalled
the ICMP messages needed for MSS discovery.

--

Tauno Voipio

 
 
 

Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised

Post by Mark Hoble » Tue, 24 May 2011 02:09:34



> For me, this smells that someone under way has firewalled the ICMP
> messages needed for MSS discovery.

Yeah. I think they have. That is why I have to set this value manually.

Mark.

--
Mark Hobley
Linux User: #370818  http://markhobley.yi.org/

 
 
 

Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised

Post by Jorgen Grah » Tue, 24 May 2011 04:19:42




>> It seems to me it's more likely that you're doing something wrong --
>> people would immediately notice if these parts of the Linux kernel
>> broke! Is it the right route? Are there others?  What does route -ne
>> say?

> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
> 0.0.0.0         10.0.0.1        0.0.0.0         UG        0 0          0 eth0
> 10.0.0.0        0.0.0.0         255.255.255.0   U         0 0          0 eth0

> That is interesting. Shouldn't the MSS be 1392 in the top line?

I don't know about 1392, but if you have forced it, that column should
say so.  0 means "use the interface's MTU", and the interface is pure
Ethernet.

/Jorgen

--

\X/     snipabacken.se>   O  o   .

 
 
 

Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised

Post by Andy Furnis » Tue, 24 May 2011 04:40:50




>> I see the same, but don't know what the behavior should be. If you set
>> mtu on say eth0 then advertised tcp mss will be affected (which in a way
>> is setting mtu plus mru for tcp) - maybe the route setting really just
>> does mtu alone, which in a way is what you asked for

> That would not be very good at all, because it breaks PMTUD. I would
> obviously want the MTU to match the route.

It doesn't break PMTUD as such - if someone sends you a larger packet
with DF set than your ISP can send, then your ISP should send a frag
needed. The trouble is it may never reach the sender so it's best to
avoid the situation arising (for tcp) by advertising a smaller mss.

Quote:

>> If you want to fix up your wan use iptables mss clamping on the gateway
>> if you can.

> I had a quick look through the router configuration settings and I could not
> see such an option, so I guess that this facility is not provided.

Ahh, I see now you don't have shell access. It may be clamping anyway as
noted elsewhere. Some routers will clamp to the mtu on the wan/ppp
connection by default, or maybe your ISP is doing some clamping.

I would see if the test upload works after you set mtu on the machines
nic rather than the route.

Quote:

>> Using ping to try and work out isp behavior can be misleading - you may
>> just be seeing the settings of the server/network you are pinging and
>> the pings may get fragged/re-assembled without you knowing.

> With PMTUD enabled, the Don't Fragment flag is set though, isn't it? So this
> would mean that we have a single datagram end to end.

A quick test on my box shows that df is only set for ping when < mtu.

If the ping is larger it gets fragged and reply is also fragged.

Assuming iputils ping you can force no frag with ping -M do .....

If you have set mtu low with route/on nic  this will just refuse to send
 > than that, so to test you need to set higher mtu, and of course be
aware that what you see may just depend on the settings/net of the
target rather than your ISP.

 
 
 

Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised

Post by Andy Furnis » Tue, 24 May 2011 04:56:44



> I would see if the test upload works after you set mtu on the machines
> nic rather than the route.

Or as I have just tested and found to work for me -
use the advmss parameter with the ip route command.
 
 
 

Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised

Post by Mark Hoble » Tue, 24 May 2011 07:12:31



> I don't know about 1392, but if you have forced it, that column should
> say so.  0 means "use the interface's MTU", and the interface is pure
> Ethernet.

Right. The ip command is not making the change then. I just tried to fix
this with route:

route del 0.0.0.0
SIOCDELRT: No such process
route add 0.0.0.0 gw 10.0.0.1 netmask 0.0.0.0 mss 1392

route -ne

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.0.1        255.255.255.255 UGH    1392 0          0 eth0
0.0.0.0         10.0.0.1        0.0.0.0         UG        0 0          0 eth0
10.0.0.0        0.0.0.0         255.255.255.0   U         0 0          0 eth0

Hmmm. Not quite what I had in mind. How do I force the revised value into
the right place in the table?

Mark.

--
Mark Hobley
Linux User: #370818  http://markhobley.yi.org/

 
 
 

Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised

Post by Mark Hoble » Tue, 24 May 2011 07:57:44



> Or as I have just tested and found to work for me - use the advmss
> parameter with the ip route command.

Ahhh, right. I just checked the man page and that might be what caused the
problem. On the old version, if advmss was not specified, it used the same
value as mss. On the upgrade, it takes the value from the interface
information in the routing table, which in my case is not the right value,
because I use larger packets on the LAN, than I do for externally bound
traffic.

Mark.

--
Mark Hobley
Linux User: #370818  http://markhobley.yi.org/

 
 
 

Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised

Post by Mark Hoble » Tue, 24 May 2011 08:12:55



> I would see if the test upload works after you set mtu on the machines
> nic rather than the route.

I did that test a while ago. I think it works, if I set it against the nic.
I didn't want to do that though, because it reduces the size of all the LAN
traffic packets.

Quote:> A quick test on my box shows that df is only set for ping when < mtu.
> If the ping is larger it gets fragged and reply is also fragged.

Right. I will look at that yahoo test again.

Cheers,

Mark.

--
Mark Hobley
Linux User: #370818  http://markhobley.yi.org/

 
 
 

Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised

Post by Martijn Lievaar » Tue, 24 May 2011 15:13:55



> I also can't help wondering if you have caused all these problems
> somehow.  If the ISP breaks things like this, it's commercial suicide --
> unless they somehow manage to keep Windows unaffected ...

The non server versions of Windows use a smaller MTU (I recall 1300, but
that may be wrong) to avoid pmtu blackholes, so yes, this is not
impossible.

M4