From: rick.jones2@hp.com   
      
   Moe Trin  wrote:   
   > On Wed, 12 Jun 2013, in the Usenet newsgroup comp.protocols.tcp-ip, in   
   article   
   > , Rick Jones wrote:   
      
   > >As it happens, ethtool -S eth0 on the destination shows   
   > >"rx_long_length_errors: 2" and that incremented to 4 when I ran the   
   > >ping test again.   
      
   > You said they're back-to-back, so the only thing I can think of is this   
   > is a artifact of the receiving system not being aware that jumbos were   
   > in use.   I don't know.   
      
   Indeed - it is an example of two stations in the broadcast domain who   
   were using different frame/MTU sizes :)   
      
   > >Now, perhaps in your situation when you shrank the MTU to < 1500   
   > >bytes, the ethernet controller and NIC were still willing to take-in a   
   > >frame larger and IP accept it.   
      
   > That's part of what I meant in my reply to Jorgen (via Barry) by O/S   
   > dependent.  A quick scan through RFC1122 doesn't find it, but I   
   > recall a bit where the a minimum "maximum" packet is 576 bytes, but   
   > I think most Ethernet stacks are built to expect 1500 or so.  For   
   > that matter, the MTU on the loopback is 16436 on my Linux boxes.   
      
   The "minimum 'maximum'" IP datagram size relates to IP fragment   
   reassembly.  A conforming IP(v4) implementation must be able to   
   reassemble IP datagrams of at least 576 bytes.  That is distinct from   
   the minimum MTU for an IPv4 network, which if I recall correctly is 68   
   bytes.   
      
   > >I could see, and have some vague recollections about, systems   
   > >whereon if one dropped the MTU/frame size below 1500 bytes, it   
   > >would not accept packets above the new MTU and still below 1500.   
      
   > Might this be related to PMTU black-holes?  There's certainly plenty   
   > of evidence for that with PPPo? where the user is also running a   
   > firewall blocking those ICMP Type 3 Code 4 mal-ware packets rather   
   > than relying on RFC3514.   
      
   It could be I suppose.  PMTU Discovery depends on receipt of the "too   
   large" IP datagram at a router in the first place, so if there were a   
   hop along the way where the sending side of that hop had an   
   MTU/framesize/whatnot larger than the receiving side of that hop, the   
   traffic could/would get bitbucketed and not generate any ICMP   
   Destination Unreachable, Datagram Too Big messages.   
      
   It has always been my understanding though that PTMU black holes were,   
   99 times out of 10, triggered by overly aggressive ICMP filtering.   
   rick jones   
   --   
   firebug n, the idiot who tosses a lit cigarette out his car window   
   these opinions are mine, all mine; HP might not want them anyway... :)   
   feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)