home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.protocols.tcp-ip      TCP and IP network protocols.      14,669 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 14,022 of 14,669   
   Moe Trin to Barry Margolin   
   Re: icmp echo to a host with smaller mtu   
   12 Jun 13 19:23:54   
   
   From: ibuprofin@painkiller.example.tld.invalid   
      
   On Wed, 12 Jun 2013, in the Usenet newsgroup comp.protocols.tcp-ip, in article   
   , Barry Margolin   
   wrote:   
      
   >Jorgen Grahn  wrote:   
      
   >> My take on this is: you cannot really change the MTU on an interface   
   >> -- you can only tell the interface the actual MTU on the link.   
      
   [fermi ~]$ uname -o   
   GNU/Linux   
   [fermi ~]$ whatis ip ifconfig   
   ip           (7)  - Linux IPv4 protocol implementation   
   ip           (8)  - show / manipulate routing, devices, policy routing   
       and tunnels   
   ifconfig     (8)  - configure a network interface   
   [fermi ~]$   
      
   It's going to depend on the O/S - or more correctly, the network   
   stack, but go for it.  Most IPv4 stacks allow MTU to be set as easily   
   as network mask or IP address.  If you only want to transmit packets up   
   to size $FOO - that's your business as long as it's within the range of   
   the minimum/maximum RECEIVING size of the other end of the link.   Note   
   that I'm only referring to IPv4 here.   On 'fermi', as root I used   
   'ifconfig mtu 1280 eth0' to set the MTU on the Ethernet interface to   
   1280 - look at the tcpdump below.   
      
   >I'd expect B to receive the packet successfully, but it might not be   
   >able to reply because the reply doesn't fit in the MTU.   
      
   Try it.  BTW, know what a "-s 8000" does in ping?  Pay attention to   
   the 'length' variables reported in the tcpdump below:   
      
   [jade ~]$ ping -c 2 -s 8000 fermi   
   PING fermi.phx.az.us (192.168.1.11) 8000(8028) bytes of data.   
   8008 bytes from fermi.phx.az.us (192.168.1.11): icmp_seq=1 ttl=64   
    time=1.76 ms   
   8008 bytes from fermi.phx.az.us (192.168.1.11): icmp_seq=2 ttl=64   
    time=1.72 ms   
      
   --- fermi.phx.az.us ping statistics ---   
   2 packets transmitted, 2 received, 0% packet loss, time 1003ms   
   rtt min/avg/max/mdev = 1.719/1.735/1.762/0.038 ms   
   [jade ~]$ /sbin/ifconfig eth0 | grep MTU   
             UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1   
   [jade ~]$   
      
   [fermi ~]# ifconfig eth0 | grep MTU   
             UP BROADCAST RUNNING MULTICAST  MTU:1280  Metric:1   
   [fermi ~]# tcpdump   
   tcpdump: verbose output suppressed, use -v or -vv for full protocol   
    decode listening on eth0, link-type EN10MB (Ethernet), capture size   
    96 bytes   
   12:08:12.516627 IP jade.phx.az.us > fermi.phx.az.us: ICMP echo request,   
    id 2018, seq 1, length 1480   
   12:08:12.516720 IP jade.phx.az.us > fermi.phx.az.us: icmp   
   12:08:12.516851 IP jade.phx.az.us > fermi.phx.az.us: icmp   
   12:08:12.516966 IP jade.phx.az.us > fermi.phx.az.us: icmp   
   12:08:12.517089 IP jade.phx.az.us > fermi.phx.az.us: icmp   
   12:08:12.517142 IP jade.phx.az.us > fermi.phx.az.us: icmp   
   12:08:12.517194 IP fermi.phx.az.us > jade.phx.az.us: ICMP echo reply,   
    id 2018, seq 1, length 1256   
   12:08:12.517197 IP fermi.phx.az.us > jade.phx.az.us: icmp   
   12:08:12.517199 IP fermi.phx.az.us > jade.phx.az.us: icmp   
   12:08:12.517201 IP fermi.phx.az.us > jade.phx.az.us: icmp   
   12:08:12.517203 IP fermi.phx.az.us > jade.phx.az.us: icmp   
   12:08:12.517204 IP fermi.phx.az.us > jade.phx.az.us: icmp   
   12:08:12.517206 IP fermi.phx.az.us > jade.phx.az.us: icmp   
   12:08:13.517767 IP jade.phx.az.us > fermi.phx.az.us: ICMP echo request,   
    id 2018, seq 2, length 1480   
   12:08:13.517890 IP jade.phx.az.us > fermi.phx.az.us: icmp   
   12:08:13.518015 IP jade.phx.az.us > fermi.phx.az.us: icmp   
   12:08:13.518138 IP jade.phx.az.us > fermi.phx.az.us: icmp   
   12:08:13.518261 IP jade.phx.az.us > fermi.phx.az.us: icmp   
   12:08:13.518315 IP jade.phx.az.us > fermi.phx.az.us: icmp   
   12:08:13.518343 IP fermi.phx.az.us > jade.phx.az.us: ICMP echo reply,   
    id 2018, seq 2, length 1256   
   12:08:13.518345 IP fermi.phx.az.us > jade.phx.az.us: icmp   
   12:08:13.518347 IP fermi.phx.az.us > jade.phx.az.us: icmp   
   12:08:13.518349 IP fermi.phx.az.us > jade.phx.az.us: icmp   
   12:08:13.518350 IP fermi.phx.az.us > jade.phx.az.us: icmp   
   12:08:13.518352 IP fermi.phx.az.us > jade.phx.az.us: icmp   
   12:08:13.518353 IP fermi.phx.az.us > jade.phx.az.us: icmp   
   ^C   
   28 packets captured   
   28 packets received by filter   
   0 packets dropped by kernel   
   [fermi ~]#   
      
   And this works equally well in the opposite direction with the same   
   set-up.  In the early 1990s, the standard test we ran after connecting   
   a new box was to ping the snot out of a victim down the hall   
      
      ping -c25 -s8000 victim   
      
   and we expected at least 24 replies out of 25.  This was being done   
   on Sun SparcStations and various Macs using classic thick-net, but   
   some hosts were using 10BaseT.    The only problem we ran into was   
   some crappy network stack running on PCs which would crash on what it   
   deemed "oversized" pings (different from the classic "Ping of Death").   
   For them, the test was 'ping -c150 -s1475 victim' and 144 out of 150.   
      
           Old guy   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca