Hello again, I have tested 0.4-13 and it seems to work fine. No more segfaults atleast. Is there any other differences between 0.4-12 and 0.4-13 than the small fix in the tunnel patch?
Since I've been able to do some more testing now that my setup works I have some additional questions and observations. 1) When mip6d is started in tunnel mode it immediately tries to do a BU. Since the tunnel I'm using is quite slow, the delay between the BU being sent and the BA from the HA being received is larger than the timeout before the next BU is sent. This will result in the MN receiving a BA that it thinks has the wrong seq no. Like this: mn_process_ha_ba: Got BA with incorrect sequence number 59164, the one sent in BU was 59165 This will repeat a few times until the timeout between BU's have increased a little bit and a BA arrives that matches the last sent BU. My question is. Is there a way to configure mip6d to start with a larger timeout between BU's ? 2) If mip6d is running when the tunnel interface comes up or is started before the tunnel has received a CoA by stateless autoconfig it will use the same address for HoA and CoA. Since it is configured to use a tunnel interface (with tunnel set to enabled) it is always in a foreign net. Should it really use the same address for HoA and CoA when it is in a foreign net? The problem is that even if a RA is received within seconds after the tunnel interface is brought up, mip6d seems to ignore it and continues to use the same address for HoA and CoA. Any ideas? BR, Mattias On Thu, Mar 26, 2009 at 12:37 PM, Arnaud Ebalard <[email protected]> wrote: > Hi, > > Mattias Blomqvist <[email protected]> writes: > >> Hi >> >> I may revisit the kernel problem later. Right now I'm satisfied with >> having it running on 2.6.29. > > ack. > >> Regarding the segfault I think I found the source. >> Forget what I said about ulimit. > > ;-) done. > >> It always seem to segfault on the first run regardless of what ulimit >> is. Why it doesn't segfault after the first run is unknown to me but >> my guess is that something is left behind that prevents further >> segfaults. >> Anyhow, since the umip package from natisbad.org default seems to >> build with debug symbols it was pretty easy to find with the core file >> and some gdb... > > thanks for having taken the time. > >> What happens is the following: >> The segfault is in a memcpy in libnetlink and it is a result of the >> gateway variable pointing to non-accessible memory in the call to >> addattr_l() in route_mod() in rtnl.c >> This in turn is called from apply_update_tunnel_route() in movement.c >> where the actual error seems to be. This functions is only present in >> movement.c after applying the tunnel_support patch so the error is in >> the patch. >> Line 436 in tunnel_support.patch is: >> gateway = RTA_DATA(rta_tb[RTA_DST]); >> Shouldn't this be: >> gateway = RTA_DATA(rta_tb[RTA_GATEWAY]); >> ??? > > Yep, looks like a stupid typo. Considering the test done before that > line, rta_tb[RTA_SRC] is guaranteed to be NULL at that point and the > call to RTA_DATA(rta_tb[RTA_DST] that is done basically returns a small > offset (RTA_LENGTH(0) in fact, i.e. 4): > > if present (for 6to4 mainly). We just skip other routes. */ > if (r->rtm_dst_len != 0 || > r->rtm_src_len != 0 || > r->rtm_table != RT_TABLE_MAIN || > r->rtm_scope != RT_SCOPE_UNIVERSE || > r->rtm_type != RTN_UNICAST || > rta_tb[RTA_DST] != NULL || > rta_tb[RTA_SRC] != NULL) > return 0; > > if (rta_tb[RTA_GATEWAY]) { > gateway = RTA_DATA(rta_tb[RTA_GATEWAY]); > } > > I have updated the patch, the associated mercurial repo and I have also > released a new version of the package (0.4-13). Can you try and do an > "apt-get update && apt-get install umip" to check it is ok on your side? > > Thanks for the feedback. > > Cheers, > > a+ > _______________________________________________ Support mailing list [email protected] http://ml.nautilus6.org/mailman/listinfo/support
