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
