[support] UMIP: Disappearing packets ???

[Mattias Blomqvist]

Hi again.

Just an update that can be good for everyone to know.

Regardless of the type of interface, the MTU of the interface declared
as the home link must be set to a minimum 1320. That is because in the
ip6tnl interface set up by mip6d, the MTU can not be set below 1280
(hardcoded in linux kernel 2.6.29).
This also means that any router along the path to the HA must accept
1320 as MTU as the linux kernel will never set the MTU of the ip6tnl
device below 1280 even if a packet too big is sent back to it as a
result of a 1320 byte long packet.

BR,
Mattias Blomqvist

On Thu, May 14, 2009 at 9:12 AM, Mattias Blomqvist
<mattias.blomqvist at gmail.com> wrote:
> 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
>