MTU setting ignored by Java socket on loopback

Question

I've got a mtu problem. I did the following:

root@sa-headend:/home/sa# ifconfig lo mtu 1500
root@sa-headend:/home/sa# ifconfig lo
lo        Link encap:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:1500  Metrik:1
          RX packets:143 errors:0 dropped:0 overruns:0 frame:0
          TX packets:143 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:58028 (58.0 KB)  TX bytes:58028 (58.0 KB)

root@sa-headend:/home/sa# ip route flush cache

How is it possible that I get packets like this one: (Using Wireshark to capture)

15  0.028587    127.0.0.1   127.0.0.1   TCP 10005 > 49152 [ACK]
    Seq=4717 Ack=53 Win=14600 Len=1608

The TCP packets are generated by a Java socket - if thats of any relevance.

Please don't ask why I want to change the MTU on lo - I just have to do this.

score 4 · Accepted Answer · answered May 19 '11 at 22:47

Sorry to be the guy that mistakenly assumes all Unix-like OSes are alike, but is there any chance your kernel thinks your loopback interface supports TCP Segmentation Offload (TSO)?

In Mac OS X (think "BSD"), if you do a packet capture on the same machine that's sending the packets, you can see impossibly large TCP frames being sent down to the card, because the stack knows that the card will do TSO to chop it up into 1500-byte chunks. On Mac OS X you can disable it with sudo sysctl -w net.inet.tcp.tso=0.

On Linux, for an Ethernet interface, it looks like you can do sudo ethtool -K eth0 tso off. I don't know if that would work on the loopback interface (instead of ethX) though.

MTU setting ignored by Java socket on loopback

1 Answers1