Hello, on 17.05.2016 14:05, Laurent CARON wrote:
When sending a ping 6 to a destination not accepting fragmented packets, I experience loss with "big" (but < 1500) packets. % ping6 -s 1234 2001:7f8:54::250 Ex: 14:03:07.959532 2001:7f8:54::145 > 2001:7f8:54::250: frag (0xbfb11fea:1232@0+) icmp6: echo request 14:03:07.959536 2001:7f8:54::145 > 2001:7f8:54::250: frag (0xbfb11fea:10@1232) 14:03:07.960179 2001:7f8:54::250 > 2001:7f8:54::145: icmp6: echo reply
Sorry, just been to lunch and probably my brain is off ... but where exactly is the loss here? You are getting a reply, right? Maybe the receiver did receive all the fragments, figured the path MTU is large enough and sent you back a non-fragmented echo reply?
And what do you mean by saying "destination not accepting fragmented packets"? Do all the fragments reach the destination (and the destination then has to figure out what to do with them)? Or does some middlebox (I'm thinking switches / routers) touch the traffic, discarding e.g. non-initial fragments?
Can you do tcpdump or tshark etc. on the source as well as on the destination box to see what exactly gets through and whether your problem is sender/destination-related or rather middlebox-related?
Oh, and what exactly caused the fragmentation in the first place? Your local MTU seems larger than the required 1242 bytes, so path MTU discovery must have kicked in somewhere on the way. Shouldn't you have gotten ICMPv6 packet too big (type 2) messages on ..::145 ? Those should be visible in tcpdump .. but you are not showing any.
I tried "ping6 2001:7f8:54::250" myself right now. Seems that my ICMP echo request goes through unfragmented, whereas I'm getting two fragments (first: 1232 bytes) back. So on the path from ...::145 to me, fragmentation seems to happen, but not in the other direction. IMHO, this means that ..::145 must have successfully performed PMTUD.
Cheers, Christoph -- open...@aixplosive.net
