Hi Miika,
It's been longer than I thought, but that´s what I've gotten:
The /proc/sys/net/ipv* variables are pretty undocumented and I didn't
find anything useful. However, I've been browsing the mipl source
code, and I'd bet that mipl daemon handles the routing table directly
through netlink library (see movement.c). Besides, I don't see any
other way to change the routing table so nicely just in a second (see
route-log.txt in my last message).
But in the other hand, I've found a workaround through radvd
configuration. The idea is to lower the validity time of routes
advertised, and at the same time to increase the rate of
advertisements avoiding the current routes to expire. Here is the
file radvd.conf:
interface eth1
{
AdvSendAdvert on;
AdvIntervalOpt on;
MaxRtrAdvInterval 3;
MinRtrAdvInterval 1;
prefix 2001:720:410:500::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvPreferredLifetime 8;
AdvValidLifetime 10;
};
};
I've tested that in two sceneries:
- Slow switching: I disconnect the MN for a few seconds (10 - 15 s.)
before connect it to the new link. This gives time to MN routes to
expire and hipl roams pretty good. Only one doubt: packets 116-118
seems an unnecessary update. Why?
-Quick switching: the movement from one link to another is almost
instantaneous. Here the first update packets are sent through the
wrong router but the retransmition fix the problem... except for the
last jump (packets 221 and 234). When MN visit the CN link, the route
to communicate with each other is the local link route (not the
default). This route takes a little bit longer to expire but is
enough to ruin the retransmition too. And since only one
retransmition is sent the movement fails. Then, in packet 271, I
manually deleted the ip address which triggered a new update and
comunication resumes. So, I think that more retransmitions would
solve the problem ¿wouldn't it?
Thanks for your time. Greetings.
Miika Komu escribió:
On Mon, 27 Aug 2007, Fco. Javier Melero wrote:
Hi,
so you have "sticky" default routes even without HIP? So when you
move your host between different networks, the old routes don't get
deleted automatically? Did I understand correctly?
Have you tried tuning the /proc/sys/net/ipv6/* variables?
If e.g. doing /proc/sys/net/ipv6/route/flush or something similar
helps during IPv6 handovers, we can surely add it to hipd code.
Could you experiment with the proc variable because I don't
currently have multiple radvd running here.
It seems like mobile ipv6 is also tuning the proc files:
http://gnist.org/~lars/doc/Mobile-IPv6-HOWTO/Mobile-IPv6-HOWTO.html#MIPv6
Thanks.
Hi Miika,
I'm sorry for taking so long. I've been a couple weeks off, but now
I'm back again (damn it!).
You are completely right. The old routes are what makes it fail in
all sceneries. I've sent you a file where you can see ip address
and routing tables, hipd log and traffic capture. And just to
compare I've done the same for mipl. As you could see mipl make
addresses and routes management automatically and so there´s no
need for manual deletion. Do you think that sort of management
would be possible for hipl?
Greetings
Miika Komu escribió:
On Tue, 7 Aug 2007, Fco. Javier Melero wrote:
Hi,
sorry for the late response.
Hi Miika,
There are no IPv4 addresses involved at all. Right now I´m trying
with IPv6 only networks. Interfamily handovers would be a really
interesting feature but I´m not on it at the moment.
Samu Varjonen or Yaqub Kamran is going to implement interfamily
handovers. Some of the code is ready already.
Here there are two files attached: hipd debug log and a traffic
capture on the MN side. They had been taken while moving from
network A to B. The first HIP_UPDATE was triggered automatically
as soon as the new ip was available. It had the correct IPs but
was sended through the old router, so it fails. A few seconds
later I deleted the old ip and that triggered a new successful
HIP_UPDATE.
This seems to a routing failure and hipd does not manage routing.
Does the route to the old router stick in your system after you
move to the new network? Please check this with "ip route -6" or
"route -6".
--
=========================================================
Fco. Javier Melero de la Torre
Universidad Carlos III de Madrid
Servicio de Informática y Comunicaciones
Area de Seguridad y Comunicaciones
(https://asyc.uc3m.es)
e-mail: javier@xxxxxxxxxx
phone: (+34) 916.249.980, (+34) 918.561.341
fax: (+34) 916.249.430
=========================================================
--
=========================================================
Fco. Javier Melero de la Torre
Universidad Carlos III de Madrid
Servicio de Informática y Comunicaciones
Area de Seguridad y Comunicaciones
(https://asyc.uc3m.es)
e-mail: javier@xxxxxxxxxx
phone: (+34) 916.249.980, (+34) 918.561.341
fax: (+34) 916.249.430
=========================================================
