[support] UMIP: Disappearing packets ???

[Mattias Blomqvist]

Hi

On Wed, May 13, 2009 at 5:24 PM, Arnaud Ebalard <arno at natisbad.org> wrote:
> Hello,
>
> Mattias Blomqvist <mattias.blomqvist at gmail.com> writes:
>
>> Hello (again)
>>
>> I have a setup with one MN and one HA and a couple of other nodes. The
>> MN registers perfectly with the HA and I can ping the MN's HoA from
>> other nodes.
>> I tried to run telnet to the MN and is able to log in and get a prompt
>> and everything seems to work just fine. Doing an "ls /" works fine.
>> The problem begins if I try to do "ls -l /". This (obviously) results
>> in more data which in turn results in two TCP packets being sent for
>> the output data.
>> With tcpdump I can see that both arrives at the ip6tnl1 interface that
>> mip6d has created. At this point they have the HoA as src and the
>> telnet clients address as dst. I have a second tcpdump running on the
>> interface that they are sent from the MN on. In this tcpdump I can see
>> that the TCP packets have been encapsulated in an outer IPv6 header
>> and this header has the CoA as src and the HA as dst. So long,
>> everything seems fine. The problem is that the first of the two larger
>> packets with the ls output is missing!
>> Did it get lost in the kernel? Or where?
>>
>> If I run telnet directly to the CoA, everything works fine. I get the
>> same issue with ssh (to the HoA) but it is easier to follow the
>> packets and their contents with telnet.
>>
>> Tcpdump output below is first from the one running on the ip6tnl1
>> interface that mip6d creates and the second output is from the
>> interface that the MN uses for communication with the HA. Both outputs
>> starts after "ls -l /" has been typed over telnet but before enter has
>> been hit so they both start with a CRLF sequence being sent and
>> echoed.
>> The ack at 00:17:19.109144 on ip6tnl1 results in a tcp resend of the
>> lost packet since it expects next byte 3. This resend is also lost.
>> This is 100% repeatable and it behaves exactly the same every time.
>>
>> config file for mip6d is included last.
>>
>> I know the output is lengthy, just cut away the data parts if you want
>> it more compressed.
>>
>> Any help is greatly apreciated.
>
> Before even looking at the pcap dump, I much say this really really
> looks like a pmtud issue. So, before looking in other directions, can
> you check the following, Mattias:
>
>  - which version of the kernel you are using?
>  - verify there is no router/box in the middle that would prevent ICMPv6
>   packet too big to flow (some netfilter config, ...)
>  - tell us if you have routers that perform some kind of encapsulation on
>   the path, or routers with a lower MTU on one side.

After some digging, yes this seems to be a pmtu problem. Thanks for
pointing in the right direction.

The XXXXXX interface in the dump is a TUN/TAP interface in tunnel mode
with a mtu set to 1280. I guess I need to set the mtu to something
bigger to allow packets of the size of 1280.

Thanks for the help.

BR,
Mattias Blomqvist