[hipl-users] Re: [HIP UPDATE] - select() error: Interrupted system call

  • From: Miika Komu <miika.komu@xxxxxxx>
  • To: hipl-users@xxxxxxxxxxxxx
  • Date: Wed, 10 Feb 2010 13:59:18 +0200

On 02/10/2010 01:32 PM, Philippe Foubert wrote:

Hi,

also, do you have "shotgun off" (or commented) in your hipd_config?

Miika, Hi,

I set the same configuration than you.
Node A = 3ffe::1/64
Node B = 3ffe::6/64
Since they are in the same network, no route to add.
(Fyi I'm running the two machines on 2.6.31.17-generic Ubuntu kernel)

I start HIPD on both machine, and on node B I give the mapping HITnodeA
and its Ipv6 Address.
Then I try the connection with a "conntest" command, and it works
perfectly.

Then I remove the Ipv6 address 3ffe::6 of the node B and I add few
seconds after 3ffe::7/64.
I see the HIPD reacting, taking into account that there is only 3ffe::7
left.
-> ftp://ftp.eurecom.fr/incoming/20100210.hipdlog
/
debug(hipd/heartbeat.c:28@hip_handle_update_heartbeat_trigger): Hearbeat
counter with ha expired, trigger UPDATE
debug(hipd/update_legacy.c:36@hip_build_locators_old): there are 2 type
1 locator item
debug(hipd/update_legacy.c:41@hip_build_locators_old): Add address::
3ffe:0000:0000:0000:0000:0000:0000:0007
debug(hipd/update_legacy.c:41@hip_build_locators_old): Add address::
192.168.12.165
debug(hipd/update_legacy.c:55@hip_build_locators_old): locator count 2
debug(lib/core/debug.c:680@hip_print_locator_addresses): LOCATOR:
*3ffe:0000:0000:0000:0000:0000:0000:0007*
debug(lib/core/debug.c:680@hip_print_locator_addresses): LOCATOR:
192.168.12.165
debug(hipd/update.c:70@hip_create_update_msg): Creating the UPDATE packet
/
Nevertheless, it looks like the HIPD is taking into account only the old
IPv6Address.
Once I did the IPv6addresses change, and I run "hipconf get ha all"
-> ftp://ftp.eurecom.fr/incoming/20100210.hipconf.get.ha.all
There is still the old local IPv6Addrress -> /Local IP:
3ffe:0000:0000:0000:0000:0000:0000:0006
/Whereas it should be 3ffe::7 from now on, since the 3ffe::6 does not
exist anymore...
Plus you can notice at the end, that it's written :* 11 packets sent, 0
packets received, 11 packet lost ...
*
In addition, just after the Ipv6Addresses change we can see :
-> the Correspondent Node (Node A = 3ffe::2) which is keeping sending
Neighbour Solicitation to see where is 3ffe::6
(/11:53:59.874440 IP6 3ffe::2 > ff02::1:ff00:6: ICMP6, neighbor
solicitation, who has 3ffe::6, length 32)/
-> The Node B is still sending ESP packets with its old Ipv6 address
(3ffe::6) whereas this IPv6 address does not exist anymore !
/(11:54:10.872463 IP6 *3ffe::6* > 3ffe::2: ESP(spi=0xcd123c1c,seq=0xa),
length 84)/
ftp://ftp.eurecom.fr/incoming/20100210.tcpdump.NS

Really weird...
Philippe


Miika Komu wrote:
On 09/02/10 18:32, Philippe Foubert wrote:

Hi,

* Does ping6 -I <NEW_LOCAL_IPv6_ADDR> <PEER_IPv6_ADDR> work?
-> No. However there is no error message in the Ping command, but I see
nothing coming out from my ethernet interface in the wireshark.
> ..
By any chance do you think it could come from a "route" problem ? I
doubt about this because packets like I1/2 R1/2 are well received,
but...
The two machines are directly connected with an Ethernet Cable. And on
the two machines I just add *"ip -6 route add ::/0 ethX"*
All normal IPv6 traffic is passing perfectly. I guess everything is ok
there no ?

you probably have a routing problem. You may have to add routes
manually. Earlier, I have played only with 3ffe::x/64 prefixes which
did not require adding of manual route. IPv4 addresses definely
require manual route unless you're using DHCP.

The ip utility is very convenient for testing many things including
routes:

ip route <peer-ip>







Other related posts: