[support] Destination unreachable from HA on BU???

[Arnaud Ebalard]

Hi,

Mattias Blomqvist <mattias.blomqvist at gmail.com> writes:

> On Fri, Mar 27, 2009 at 9:40 AM, Arnaud Ebalard <arno at natisbad.org> wrote:
>> Hi,
>>
>> Well, *in that case*, what UMIP does is quite logical. You should never
>> have the HoA configured automatically or statically on the system. UMIP
>> will handle the HoA which will be assigned to the ip6tnl* interface.
>
> Aha! Ok. It works a little bit better now.
>
>>>> - If a RA is received, it is not processed by UMIP, i explicitly
>>>>  prevented that in the code for tunnel ifaces, so even if an
>>>>  unsollicited RA is received, then, UMIP is not the one that will set
>>>>  the address on the tunnel interface. Does a userland process does
>>>>  that?
>>>
>>> No. The kernel process the RA like it would for any other interface
>>> and sets the address according to how it should be done for stateless
>>> autoconfig.
>>
>> I checked the code and remembered I decided not to touch the existing
>> /proc configuration for a Tunnel interface when I wrote the code. In
>> process_new_inet6_iface(), I added those lines for that purpose.
>>
>>                        if (!iface->is_tunnel)
>>                                iface_proc_entries_init(iface);
>>
>> This explains why the kernel does it job on this specific iface.
>
> Not entirely true regarding the /proc configuration. The /proc
> configuration default (/proc/sys/net/ipv6/conf/default/*) is still set
> last in md_init() by a call to iface_default_proc_entries_init(). This
> means that when the tunnel interface is created it will inherit the
> defaults already set by mip6d.

That's correct. This may be an issue in your case if the interface
appears after UMIP has done that setting of default/*. Anyway, I don't
think I should modify current behavior. It can be handled in the tunnel
interface configuration by setting correct values for associated /proc
entries.

> This is mainly a problem for accepting
> default router routes in RA's (the default for autconf is set to 1).
> This is however not really a problem. I will handle it in the
> user-space process handling the tunnel interface.
>
> One additional problem seems to be that the tunnel interface must
> exist when mip6d is started. Is there any way around this?

I wrote a patch which is in the repo that handles dynamic interfaces,
i.e. support an interface plugged after the daemon has been started. I
don't know why it does not work in your case. I did not notice problems
when starting teredo interfaces after UMIP on my MN. Can you be more
specific on what happens? are some packets sent or is it just that
nothing happens? Is an address configured? is a RS sent?

Can you verify this is not related to the fact UMIP sets /default/*
value in /proc *before* the interface is brought up (as you pointed),
which may prevents some things to happen (like autoconf or RA
handling). Basically, can you retry by setting again /proc/ values for
the tunnel interface.

Cheers,

a+