Hi, Mattias Blomqvist <[email protected]> writes:
> Hi, > > On Thu, Mar 26, 2009 at 5:40 PM, Arnaud Ebalard <[email protected]> wrote: >> Hi, >> >> Mattias Blomqvist <[email protected]> writes: >> >>> I have only one interface defined and it is defined as a tunnel >>> interface. So no preference values. >>> The output from mip6d is (I know the time on the MN isn't set so the >>> timestamps have the wrong date and time): >>> Fri Jan 11 04:18:37 mn_move: in foreign net >>> ... >>> Fri Jan 11 04:18:37 mh_send: sending MH type 5 >>> from xxxx:xxxx:0:1300:0:0:0:1 >>> to xxxx:xxxx:0:0:0:0:0:1 >>> Fri Jan 11 04:18:37 mh_send: local CoA xxxx:xxxx:0:1300:0:0:0:1 >>> Fri Jan 11 04:18:37 bul_update_timer: Updating timer >>> == BUL_ENTRY == >>> Home address xxxx:xxxx:0:1300:0:0:0:1 >>> Care-of address xxxx:xxxx:0:1300:0:0:0:1 >>> CN address xxxx:xxxx:0:0:0:0:0:1 >>> lifetime = 262140, delay = 1000 >>> flags: IP6_MH_BU_HOME IP6_MH_BU_ACK >>> ... >>> etc. >>> xxxx:xxxx is the same for every address above. >>> This BU will obviously not work. The real problem is that it continues >>> to use the same address for CoA and HoA even after a RA resulting in >>> autoconf of a correct CoA has been received. The only way to correct >>> this problem is to restart mip6d after the tunnel interface have >>> received a RA so it has a useable CoA. >> >> There is something I don't understand in your setup which prevents me to >> see why or how umip would do what you have above: the CoA UMIP uses is >> always (otherwise it is a bug) configured (manually or statically) on >> the interface. So in your case, this means that your tunnel interface >> has the xxxx:xxxx:0:1300:0:0:0:1 address set initially, doesn't it? > > Correct. 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. >> Can you please provide the whole (anonymized) output of ip addr show for >> your system. > > Before RA received: > > Mobile-test:~# ip -6 addr show > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 24: tunnel: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qlen 500 > inet6 xxxx:xxxx:0:1300::1/56 scope global > valid_lft forever preferred_lft forever > inet6 fe80::13/64 scope link > valid_lft forever preferred_lft forever > > After RA received: > > Mobile-test:~# ip -6 addr show > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 24: tunnel: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qlen 500 > inet6 yyyy:yyyy::13/64 scope global dynamic > valid_lft 2591997sec preferred_lft 604797sec > inet6 xxxx:xxxx:0:1300::1/56 scope global > valid_lft forever preferred_lft forever > inet6 fe80::13/64 scope link > valid_lft forever preferred_lft forever > > > The output is exactly the same regardless if mip6d is running or not. > >> Now, with regard to the Tunnel keyword, as explained in the man page, it >> expects that the tunnel interface be configured externally, either in an >> automatic fashion of by hand. This is compatible with ppp, 6to4 and >> Teredo (at least). Your interface seems to work differently. Can you >> provide some details. > > It is configured externally. But only link-local address and HoA are > set. The CoA cannot be set since it will change when the tunnel's > other end moves (which is the whole point in using MIPv6). The thing is you don't have to set the HoA on your tunnel iface. In fact, it will not work if it is set (as explained before). You let the HoA be configured by UMIP on the ip6tnl iface and the CoA be automatically configured by your external mechanism on the tunnel iface. You should have the following: at the beginning: Mobile-test:~# ip -6 addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 24: tunnel: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qlen 500 inet6 fe80::13/64 scope link valid_lft forever preferred_lft forever and after RA is received: Mobile-test:~# ip -6 addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 24: tunnel: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qlen 500 inet6 yyyy:yyyy::13/64 scope global dynamic valid_lft 2591997sec preferred_lft 604797sec inet6 fe80::13/64 scope link valid_lft forever preferred_lft forever >> I may be wrong and I would have to check in the code but: >> >> - because autoconfig is deactivated by UMIP, no RS should be sent by the >> kernel on the tunnel. Does a userland process does that? > > Yes. Just as the manpage says, the interface has to be managed by > something else. > >> - when an interface is a Tunnel one, UMIP does not send RS. > > The user process sends an RS to receive an RA which is sent to the > tunnel interface. This RA is important because it is the only way to > get an autoconfigured address that is usable as CoA. > >> - 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. >> - Tunnel information as understood by umip is read again and updated >> when the link status changes, i.e. on up and down or when an address >> is removed/added. If this is done on the tunnel as you explain, it >> should work. Can you verify the tunnel has a new address after >> receiving a RA, as you report? > > It doesn't seem to read it when an address is added if it is done by > the kernel upon receiving an RA. > Yes, the tunnel has a new address after an RA is received regardless > if mip6d is running or not. See ip command output above. Because the netlink notification will be provided by the kernel, UMIP will have the information. I think it just does not care about the newly configured CoA because the HoA on the tunnel iface is interfering. >> It would help if you could be more specific on how your tunnel interface >> work (config, routes, ...) > > It uses the standard linux tuntap driver in tunnel mode. The tunnel > device is opened, a link-local address is set in accordance with RFC > 4291 and a static ipv6 address is also set (the HOA, > xxxx:xxxx:0:1300::1/56) and then the interface is brought up. > Addresses are set by normal "ip -6 addr add" commands. No additional > routes other than thoose resulting from the ip command or received RA > is set. Received RA is sent by radvd (running on another host at other > end of the tunnel) with the simplest possible config: > > interface tunnel > { > AdvSendAdvert on; > prefix yyyy:yyyy::/64 > { > }; > }; Just remove the "ip addr add" for the HoA on your Tunnel iface and everything should work as expected (just a bet ;-) ) Cheers, a+ _______________________________________________ Support mailing list [email protected] http://ml.nautilus6.org/mailman/listinfo/support
