Re^2: Getting packets over 1500 Bytes pcap.

UDP which does not support "packet segmentation and re-assembly"

UDP layers on top of IP, which does fragment packets that are larger than the MTU. Reassembly happens at the final destination, so while you may not see all IP fragments of a large UDP packet while they are in transit, you should be able to see the full UDP packet at both source and destination.

the network sill silently drop packets larger than the MTU

That makes it sound like any UDP packets larger than the MTU will silently be dropped, which isn't the case. UDP packets may be dropped silently, however there isn't a general rule tying this to the MTU. If the IP "don't fragment" bit is set and the packet is larger than the MTU, it may be discarded, but it should generate an ICMP "Fragmentation Required" message.

Comment on Re^2: Getting packets over 1500 Bytes pcap.

Replies are listed 'Best First'.
Re^3: Getting packets over 1500 Bytes pcap. by NetWallah (Canon) on May 26, 2014 at 05:02 UTC
I guess we are both right - depending on which IP option is implemented: From http://en.wikipedia.org/wiki/IP_fragmentation In a case where a router receives a protocol data unit (PDU) larger than the next hop's MTU, it has two options if the transport is IPv4: drop the PDU and send an Internet Control Message Protocol (ICMP) message which indicates the condition Packet too Big, or fragment the IP packet and send it over the link with a smaller MTU. What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? -Larry Wall, 1992	[reply]
Re^4: Getting packets over 1500 Bytes pcap. by no_slogan (Deacon) on May 26, 2014 at 13:41 UTC
Firewalls don't care about internet standards. I get an immediate response to a 1400 byte ping: `06:26:15.154205 IP 10.0.0.13 > perlmonks.pair.com: ICMP echo request, +id 46849, seq 0, length 1408 06:26:15.232493 IP perlmonks.pair.com > 10.0.0.13: ICMP echo reply, id + 46849, seq 0, length 1408` [download] And no response to a fragmented 1500 byte ping: `06:26:32.986529 IP 10.0.0.13 > perlmonks.pair.com: ICMP echo request, +id 47105, seq 0, length 1480 06:26:32.986540 IP 10.0.0.13 > perlmonks.pair.com: icmp` [download] BTW, I get a "time exceeded" message if I set the TTL to 16, but nothing if I set it to 17. It looks like Pair.com's border firewall is eating ICMPs. `06:34:53.777278 IP 10.0.0.13 > perlmonks.pair.com: ICMP echo request, +id 59649, seq 0, length 1480 06:34:53.777287 IP 10.0.0.13 > perlmonks.pair.com: icmp 06:34:53.862597 IP continental.car1.pittsburgh3.level3.net > 10.0.0.13 +: ICMP time exceeded in-transit, length 36` [download] (And yes, I know ping doesn't use UDP.)	[reply] [d/l] [select]
Re^3: Getting packets over 1500 Bytes pcap. by no_slogan (Deacon) on May 26, 2014 at 04:31 UTC
That makes it sound like any UDP packets larger than the MTU will silently be dropped, which isn't the case. A lot of firewalls don't pass fragments nowdays, so it mostly is the case. >ping -c3 -s1400 perlmonks.org PING perlmonks.org (209.197.123.153): 1400 data bytes 1408 bytes from 209.197.123.153: icmp_seq=0 ttl=49 time=85.135 ms 1408 bytes from 209.197.123.153: icmp_seq=1 ttl=49 time=82.106 ms 1408 bytes from 209.197.123.153: icmp_seq=2 ttl=49 time=83.449 ms --- perlmonks.org ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 82.106/83.563/85.135/1.239 ms >ping -c3 -s1500 perlmonks.org PING perlmonks.org (209.197.123.153): 1500 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 --- perlmonks.org ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss [download]	[reply] [d/l]