[hipl-users] Re: Fwd: Re: Fwd: hip update flood
- From: Till Janos <janos.till@xxxxxxxxx>
- To: hipl-users@xxxxxxxxxxxxx
- Date: Sun, 6 Dec 2009 20:29:33 +0100
Hi Miika!
If I run simple the hipd daemon on both side host A and host B it works
correctly, the address_change_time_counter doesn't reach 0 to trigger the
updates.
The flooding begins when I start pinging host B from A. The HIP association
establishes during the course of the Base Exchange mechanism (A is the
Initiator, B the Responder), and from that point the updates are coming
frequently.
1. Could you try it?
I 've checked mobility with handover.
My host A receives the UDP packets from host B using DITG traffic
generator.
A short time after 4 sec I initiate handover manually, I receive my new
address correctly.
Even I delete the previous address and route entry right after invoking
handover, it seems that the triggering of the update mechanism takes too
long sometimes, and causes an extra handover latency (see an axample
below).
2. Is this built in handover delaying mechanism necessary? How could I
reduce the latency?
Here is my tshark log:
...
*4.103628 2001:738:2001:20a0:216:76ff:fe06:c0b1 ->
2001:738:2001:2084:230:5ff:fe61:1eb5 ESP ESP (SPI=0xd128d584) (B -> A)*
4.103628 2001:12:4e97:be5b:8711:1ab9:68fd:ce95 ->
2001:16:c51e:bd25:5363:b:4de1:2cda UDP Source port: 39181 Destination port:
bctp
7.465298 fe80::213:20ff:fe20:7c4a -> ff02::1 ICMPv6 Router advertisement
8.403834 :: -> ff02::1:ff61:1eb5 ICMPv6 Neighbor solicitation
10.023130 fe80::213:20ff:fe20:7c4a -> ff02::1 ICMPv6 Router advertisement
11.555857 0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover - Transaction ID
0xbe58ab70
12.570006 fe80::213:20ff:fe20:7c4a -> ff02::1 ICMPv6 Router advertisement
13.549919 0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover - Transaction ID
0xbe58ab70
15.393276 fe80::213:20ff:fe20:7c4a -> ff02::1 ICMPv6 Router advertisement
15.550055 0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover - Transaction ID
0xbe58ab70
17.764293 fe80::213:20ff:fe20:7c4a -> ff02::1 ICMPv6 Router advertisement
20.038019 fe80::213:20ff:fe20:7c4a -> ff02::1 ICMPv6 Router advertisement
20.072095 2001:738:2001:2087:230:5ff:fe61:1eb5 ->
2001:738:2001:20a0:216:76ff:fe06:c0b1 HIP HIP UPDATE (HIP Update
Packet)* (A -> B Locator )
*
20.209789 fe80::213:20ff:fe20:7c4a -> ff02::1:ff61:1eb5 ICMPv6 Neighbor
solicitation
20.209834 2001:738:2001:2087:230:5ff:fe61:1eb5 -> fe80::213:20ff:fe20:7c4a
ICMPv6 Neighbor advertisement
20.212753 2001:738:2001:20a0:216:76ff:fe06:c0b1 ->
2001:738:2001:2087:230:5ff:fe61:1eb5 HIP HIP UPDATE (HIP Update Packet) *
(B -> A echo_request )*
20.326227 2001:738:2001:2087:230:5ff:fe61:1eb5 ->
2001:738:2001:20a0:216:76ff:fe06:c0b1 HIP HIP UPDATE (HIP Update Packet) *
(A -> B echo_response )*
*20.326784 2001:738:2001:2087:230:5ff:fe61:1eb5 ->
2001:738:2001:20a0:216:76ff:fe06:c0b1 ESP ESP (SPI=0x633d1fd3) (new address
A -> B)*
20.501106 2001:738:2001:20a0:216:76ff:fe06:c0b1 ->
2001:738:2001:2087:230:5ff:fe61:1eb5 ESP ESP (SPI=0xd128d584)
20.501106 2001:12:4e97:be5b:8711:1ab9:68fd:ce95 ->
2001:16:c51e:bd25:5363:b:4de1:2cda UDP Source port: 39181 Destination port:
bctp
...
handover switching script:
echo "HO: ap2 -> ap1 "
iwconfig wlan0 essid asus-fmip-ap1 &
echo "previous address and route deleting"
ip -6 addr del dev wlan0 2001:738:2001:2084:230:5ff:fe61:1eb5/64 &
ip -6 route del default via fe80::213:20ff:fe20:7c4d dev wlan0 &
Thanks for your help,
Janos
2009/12/4 Miika Komu <miika.komu@xxxxxxx>
>
>
> Hi,
>
> I tried but I can't repeat your problem. Your logs say first:
>
> debug(maintenance.c:753@periodic_maintenance): Delay mobility triggering
> (count 5)
> debug(maintenance.c:753@periodic_maintenance): Delay mobility triggering
> (count 4)
> debug(maintenance.c:753@periodic_maintenance): Delay mobility triggering
> (count 3)
> debug(maintenance.c:753@periodic_maintenance): Delay mobility triggering
> (count 2)
> debug(maintenance.c:753@periodic_maintenance): Delay mobility triggering
> (count 1)
> debug(maintenance.c:753@periodic_maintenance): Delay mobility triggering
> (count 0)
>
> and this not displayed later at all:
>
> debug(maintenance.c:748@periodic_maintenance): Triggering UPDATE
>
> I believe this is probably the source of the problem.
>
> The new algo for "delayed handovers" is quit short and simple. It's in
> hipd/maintenance.c:
>
> 744 if (hip_wait_addr_changes_to_stabilize &&
> 745 address_change_time_counter != -1) {
> 746 if (address_change_time_counter == 0) {
> 747 address_change_time_counter = -1;
> 748 HIP_DEBUG("Triggering UPDATE\n");
> 749 err = hip_send_update_locator();
> 750 if (err)
> 751 HIP_ERROR("Error sending UPDATE\n");
> 752 } else {
> 753 HIP_DEBUG("Delay mobility triggering (count
> %d)\n 753 n", address_change_time_counter - 1);
> 754 address_change_time_counter--;
> 755 }
> 756 }
>
> Value -1 is the initial for address_change_time_counter and it means that
> there no need trigger handover. Value zero means that a handover needs to be
> triggered immediately. A positive value N means that the handover should be
> triggered in N seconds.
>
> Can you find a flaw in that algorithm? You can also use gdb to test this as
> follows:
>
> # gdb hipd
> watch address_change_time_counter
> run
>
> (then type "continue" to continue after hitting a breakpoint)
>
> I am sorry the bounce this problem back to you but I really tried to repeat
> the problem but couldn't.
>
>
Other related posts:
