XPost: comp.os.linux.networking   
   From: grahn+nntp@snipabacken.se   
      
   On Sun, 2011-05-22, Mark Hobley wrote:   
   > On Sat, 21 May 2011 22:28:56 +0000, Jorgen Grahn wrote:   
   >   
   >> 1460 looks perfectly normal to me; it's the mss for a normal Ethernet.   
   >   
   > Yeah, but I am not connected via ethernet (well, I am, but only as far as   
   > the external gateway), the router uses a wireless broadband and it cannot   
   > route ethernet frames, because they are too large.   
   >   
   >> n.e-s.o cannot know that your ISP is weird.   
   > I don't know what that means. I tell the routing table that my maximum   
   > transmission unit is 1412. Shouldn't the value provided in the mss field   
   > be less than the routable mtu?   
   >   
   > ip route change default via 10.0.0.1 mtu lock 1412   
      
   Ah, sorry! I assumed you were talking about the /server's/ advertised   
   mss. Please ignore everything I wrote above.   
      
   That points to another bizarre fact: the SYNs from n.e-s.org   
   advertise a low mss (1380).  But when I connect to it, it tells me:   
      
     win 5792, options [mss 1460,sackOK,TS val ... ecr ...,nop,wscale 7]   
      
   This makes me think your ISP (or some equipment of yours) does   
   something tricky to the packets you're seeing. Like "MSS clamping".   
      
   [lots more]   
      
   ...   
   > I will mention my router, just in case it matters. It is an Edimax 3g-6200n   
   > and I am using the latest firmware (version 2.24g). The firmware is Linux   
   > based and open source, but it does not provide shell access. On the back of   
   > the router is a Three Mobile Broadband dongle made by Huawei, which makes   
   > the connection to the outside world.   
      
   And then you have GTP tunneling between the routers (SGSN, GGSN) in   
   the 3G network. These frequently pull stupid stunts, too.   
      
   I don't know ... you also seem to say that IP fragmentation doesn't work   
   for you.  That's so abnormal that perhaps you should debug that first.   
   It would be easier though if you had tcpdump access to a machine on   
   the other side -- since something inbetween is obviously messing with   
   your packets.   
      
   /Jorgen   
      
   --   
     // Jorgen Grahn    O  o   .   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)