Hello all, we observe the following problem at the MIPL 2.0.2 Home Agent (HA) and Mobile Node (MN):
I think, MIPL 2.0.2 was designed for a Break-Before-Make (BBM) handover process. That means the old link is lost, then movement detection and new address configuration takes place and finally an Binding Update with the new Care-of Address (CoA) is sent to the HA. Last year, Gabor has written a patch to enable also a Make-Before-Break (MBB) handover process. In this case, a new radio link is set up, then new address configuration takes place, then the preference of the radio interface is switched which results in a Binding Update for the new CoA and finally the old radio link is released. If we use the MBB handover process sometimes both, the HA and the MN PCs crashes or freezes. In our testbed we use two different radio access technologies: one with a short (1 ms) and one with a long (100-150 ms) RTT. We have choosen a ping6 as a test application. The ping is transmitted every 200 ms with 1000 bytes payload via the MIPv6 tunnel using the -I ip6tnl1 option. If the MN switches from the radio access network with the long RTT radio link to the radio access network with the short RTT, then we can observe (using Ethereal) nearly each time on a router between the MN and the HA, that the Binding Update and Binding Acknowledgement message exchange is finished before the last Echo Request with the old CoA from the long RTT radio link is received at the router and then routed to the HA. In every such case, the HA freezes. Sometimes, a similar problem must result in a system crash or system freeze of the MN. Are the HA and the MN unable to handle packets with the old CoA, after a Binding Update with the new CoA has been processed? I'm using MIPL-2.0.2 with kernel 2.6.16 on a Fedore Core 5 system. We have already tried to disable SMP and all pre-emptiveness from the kernel. But the result was the same. We also made a two line patch to the file /net/core/neighbour.c, which was published here due to a problem with tunnel interfaces in the MN. I appreciate any response! Thanks! Dirk _______________________________________________ mipl mailing list [email protected] http://www.mobile-ipv6.org/cgi-bin/mailman/listinfo/mipl
