[hipl-users] Re: IPv6 address in LOCATOR parameter and mobility
- From: Leo Martinez <boldfox@xxxxxxxxx>
- To: hipl-users@xxxxxxxxxxxxx
- Date: Mon, 22 Jun 2009 11:59:19 +0200
Hello again everyone,
I've been running through the scenario of the last message and found out
some interesting things about it:
- Whenever testing the Handover scenario of the manual (chapter 12) I always
receive a SEGMENTATION FAULT error on the daemon of the crash host
immediately after I have deleted the IPv6 address (crash). Reading the
daemons log, its right after receiving the order to delete the SA of the old
IPv6 address... I tested as well creating the new IPv6 address before
deleting the old one as in a make-before-break attempt to see if no error
appeared, both had the same outcome.
*debug(update.c:2460@hip_send_update): Mobility with single SA pair,
readdress with no rekeying*
*debug(update.c:2461@hip_send_update): Reusing old SA*
*debug(update.c:2484@hip_send_update): make_new_sa=0*
*debug(update.c:2510@hip_send_update): not creating a new SA*
*debug(update.c:2526@hip_send_update): Reusing old SPI*
*debug(update.c:2579@hip_send_update): Netlink event was del, removing SAs
for the address for this entry*
*debug(xfrmapi.c:410@hip_xfrm_state_delete): IPV6 SA deletion*
*debug(xfrmapi.c:415@hip_xfrm_state_delete): sport 0, dport 0*
*debug(xfrmapi.c:431@hip_xfrm_state_delete): deleting xfrm state with spi
0xb8de9c1b*
*debug(xfrmapi.c:432@hip_xfrm_state_delete): SA peer addr:
0x3ffe0000000000000000000000000004*
*debug(xfrmapi.c:410@hip_xfrm_state_delete): IPV6 SA deletion*
*debug(xfrmapi.c:415@hip_xfrm_state_delete): sport 0, dport 0*
*debug(xfrmapi.c:431@hip_xfrm_state_delete): deleting xfrm state with spi
0x6730a71*
*debug(xfrmapi.c:432@hip_xfrm_state_delete): SA peer addr:
0x3ffe0000000000000000000000000002*
*debug(update.c:2078@hip_update_src_address_list): *
*info(hadb.c:769@hip_hadb_get_peer_addr): entry def addr:
3ffe:0000:0000:0000:0000:0000:0000:0002*
*debug(hadb.c:1912@hip_hadb_get_spi_in_list): SPI=0xb8de9c1b*
*debug(update.c:2220@hip_update_src_address_list): I is now 0*
*Segmentation fault*
- Also, I tested having an IPv4 address assigned as well on the same
interface and processed the same instructions. Curiously I found that the
daemon selects the IPv4 address as the prefered locator and uses it to
continue the previous SA. However, there is a problem since it creates a
bogus IPv6 address and is never able to send the UPDATE messages. Heres a
display of the SA before and after this case. Notice the SRC Addr after the
mobility has been made.
# hipconf get ha all
Sending user message 22 to HIPD on socket 3
Sent 40 bytes
Waiting to receive daemon info.
216 bytes received from HIP daemon
HA is ESTABLISHED
Local HIT: 2001:0010:28bf:1eef:6b9f:7003:ab62:d3d3
Peer HIT: 2001:0013:12af:9aa5:0e68:d8df:e9e4:abb2
Local LSI: 1.0.0.1
Peer LSI: 1.0.0.2
Local IP: 2001:0660:3203:1000:0280:06ff:febe:9116
Local NAT traversal UDP port: 0
Peer IP: 2001:0660:3203:1000:0215:e9ff:fe7c:39f4
Peer NAT traversal UDP port: 0
Peer hostname: hal
root@bob:/home/bob# hipconf get ha all
Sending user message 22 to HIPD on socket 3
Sent 40 bytes
Waiting to receive daemon info.
216 bytes received from HIP daemon
HA is ESTABLISHED
Local HIT: 2001:0010:28bf:1eef:6b9f:7003:ab62:d3d3
Peer HIT: 2001:0013:12af:9aa5:0e68:d8df:e9e4:abb2
Local LSI: 1.0.0.1
Peer LSI: 1.0.0.2
* Local IP: c544:0000:7eff:fffe:0000:0000:0000:0000*
Local NAT traversal UDP port: 0
Peer IP: 2001:0660:3203:1000:0215:e9ff:fe7c:39f4
Peer NAT traversal UDP port: 0
Peer hostname: hal
At the moment I have not been able to perform the handover tests described
in chapter 12. Any of you guys have some suggestions regarding these
observations?
Thanks a lot.
Best regards,
Leo
Other related posts:
