[hipl-users] Re: testing handover

  • From: Nerea Toledo Gandarias <nerea.toledo@xxxxxx>
  • To: hipl-users@xxxxxxxxxxxxx
  • Date: Tue, 15 Jun 2010 16:52:50 +0200

Hi Miika,

thank you for your help.
I finally see the HIP BEX! I also tried the HO using a single interface and between two different interfaces, and UPDATE messages where sent and received with no problem.
So, I guess the problem was not having the 4757 version...

Thanks again! :-)

Miika Komu escribió:
On 14/06/10 15:47, Nerea Toledo Gandarias wrote:

Hi,

seems like this was messed up in some recent commit. I could repeat the problem in receiving IPv6 packets and I fixed it in revision 4757.

Hi again,

sorry for my insistence but I don't know what is happening. I can't
establish a HIP SA.
I've got IPv6 connectivity. As you can see, I can ping6 between them:

ping6 -i 3ffe::10 3ffe::1
PING 3ffe::1(3ffe::1) 56 data bytes
64 bytes from 3ffe::1: icmp_seq=1 ttl=64 time=7.81 ms
64 bytes from 3ffe::1: icmp_seq=2 ttl=64 time=0.250 ms
64 bytes from 3ffe::1: icmp_seq=3 ttl=64 time=0.172 ms
--- 3ffe::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 6004ms
rtt min/avg/max/mdev = 0.172/2.744/7.810/3.582 ms

and I haven't got any HIP firewall crashed on the background (nor in the
Initiator neither in the Responder)
iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

But, the Initiator sends the I1 packet and receives no response from the
Responder:
(INITIATOR):
# hipconf get ha all
Sending user message 22 to HIPD on socket 3
Sent 40 bytes
Waiting to receive daemon info.
248 bytes received from HIP daemon
HA is I1-SENT
Shotgun mode is off.
Local HIT: 2001:0016:bd4c:b878:b1b4:b27e:1ae0:d9d6
Peer HIT: 2001:0016:31cf:66ba:416d:95e4:ba33:90ae
Local LSI: 1.0.0.1
Peer LSI: 1.0.0.2
Local IP: 3ffe:0000:0000:0000:0000:0000:0000:0010
Local NAT traversal UDP port: 10500
Peer IP: 3ffe:0000:0000:0000:0000:0000:0000:0001
Peer NAT traversal UDP port: 10500
Peer hostname:

(RESPONDER):
# hipconf get ha all
Sending user message 22 to HIPD on socket 3
Sent 40 bytes
Waiting to receive daemon info.
40 bytes received from HIP daemon

I'm using lucid lynx (10.04), just in case it is a problem related to
the distro...

Thanks,
Nerea

Miika Komu escribió:
On 14/06/10 09:44, Miika Komu wrote:

Hi,

please also test that you have connectivity between the IPv6 addresses:

ping6 -i <source ipv6 address> <destination ipv6 address>

On 11/06/10 19:08, Nerea Toledo Gandarias wrote:

Hi Nerea,

just I wild guess but do you have a HIP firewall crashed on the
background? sudo iptables -L -n

If you see HIP firewall rules there, you can just run the following to
start and stop hipfw gracefully (thus wiping iptables rules):

hipfw -k
<press ctrl+c>

Hello Miika,

Miika Komu escribió:
On 06/10/2010 07:51 PM, Nerea Toledo Gandarias wrote:

Hi,

Hi Miika,

I'm trying to download the 1.0.6-4712 release using the Bazaar but it gets stuck. Could you please tell me a way to get this release or the
latest stable release to work with the HO?

the code is now hosted in launchpad. Get rid of the old code and try:

bzr co lp:hipl

Or are you actually trying to download the binaries? It's a bit
unclear to me.
This command functioned perfectly, so I think I've got HIP properly
installed. Thanks.


On the other hand, I'm not able to establish the HIP association with
the 1.0.6 release, as the Responder does not answer to the I1
packet...
I've been looking at the hipconf file and I see some options that I'm
not sure they should be working or commented, i.e. add map HIT IP
(commented) or hit-to-ip on (not commented). So, I would really
appreciate if you could facilitate me the hipconf file options, not
only
for establishing the association but also for carrying out the HO
that
worked for you ;-)

You can always erase the /etc/hip/hipd_config file and restart hipd to
get the default configuration file. Make sure that "shotgun" mode is
turned off.
What I do to obtain the default configuration is killall hipd and I see
that the hipconf file has only hit-to-ip map, nsupdate and nat
plain-upd
on.

The most simple set up is to do this from the command line:

1. hipconf add map <PEER_HIT> <PEER_IP>
2. ping6 <PEER_HIT>
By doing this, I get the following output in the INITIATOR:

Sending HIP_I1 packet
debug(hipd/output.c:1150@hip_send_raw_from_one_src): hip_send_raw():
local_addr:
debug(hipd/output.c:1151@hip_send_raw_from_one_src): hip_send_raw():
peer_addr:
debug(hipd/output.c:1152@hip_send_raw_from_one_src): Source port=0,
destination
debug(hipd/output.c:1153@hip_send_raw_from_one_src): dump:
debug(lib/core/builder.c:1189@hip_dump_msg): --------------- MSG START
---------
debug(lib/core/builder.c:1193@hip_dump_msg): Msg type : HIP_I1 (1)
debug(lib/core/builder.c:1194@hip_dump_msg): Msg length: 40
debug(lib/core/builder.c:1195@hip_dump_msg): Msg err: 2212
debug(lib/core/builder.c:1196@hip_dump_msg): Msg controls: 0x0000
debug(lib/core/builder.c:1215@hip_dump_msg): ---------------- MSG END
----------
debug(hipd/output.c:1185@hip_send_raw_from_one_src): Using IPv6 raw
socket
debug(hipd/output.c:1191@hip_send_raw_from_one_src): local address
given
debug(hipd/output.c:1209@hip_send_raw_from_one_src): src6:
3ffe:0000:0000:0000:0
debug(hipd/output.c:1220@hip_send_raw_from_one_src): dst6:
3ffe:0000:0000:0000:0
debug(lib/tool/checksum.c:273@hip_checksum_packet): Checksumming 40
bytes of dat
debug(hipd/output.c:1297@hip_send_raw_from_one_src): sent=40/40 ipv4=0
debug(hipd/output.c:1298@hip_send_raw_from_one_src): Packet sent ok

Put the RESPONDER I've got this:

Receiving a message on raw HIP from IPv6/HIP socket (file
descriptor: 9).
debug(lib/core/message.c:542@hip_read_control_msg_all):
hip_read_control_msg_all() invoked.
debug(lib/core/builder.c:1849@hip_verify_network_header): Received a
connection to HIT: 2001:001d:c174:1bf0:0cbb:a455:7376:9a0c
debug(lib/core/builder.c:1853@hip_verify_network_header): dst port is 0
debug(lib/tool/checksum.c:273@hip_checksum_packet): Checksumming 40
bytes of data.
debug(lib/core/message.c:640@hip_read_control_msg_all): src:
3ffe:0000:0000:0000:0000:0000:0000:0010
debug(lib/core/message.c:643@hip_read_control_msg_all): dst:
3ffe:0000:0000:0000:0000:0000:0000:0001

But it doesn't respond with the R1 packet. Thus, the INITIATOR keeps on
retransmitting I1 messages to the RESPONDER with no success.
When typing hipconf get ha all in the RESPONDER I get the following:
Sending user message 22 to HIPD on socket 3
Sent 40 bytes
Waiting to receive daemon info.
40 bytes received from HIP daemon

So, the HIP association is not established, as can be seen when typing
hipconf get ha all in the INITIATOR:
Sending user message 22 to HIPD on socket 3
Sent 40 bytes
Waiting to receive daemon info.
248 bytes received from HIP daemon
HA is UNASSOCIATED


This is driving me mad, because I see that the I1 packet arrives to the
Responder (as it gets the source address) but it does not answe with
the
R1 packet!

I'd really appreciate your help.
Thanks a lot.


Thanks a lot!
Nerea

Miika Komu escribió:
On 06/08/2010 08:17 PM, Nerea Toledo Gandarias wrote:

Hi,

I tried this with two interfaces and it is working for me. However, one of the interfaces is wireless and I'm running NetworkManager. So
perhaps I didn't repeat the problem with your exact configuration.

There has been many changes in the code, including removal of a
lot of
unmaintained research extensions and loads of code clean ups. Also,
the new binaries are built for latest ubuntu/fedora versions and
support for old ones are discontinued.

The most important changes in the mobility code are related to
triggering of the handovers, but this happened a while ago. By
default, hipd triggers a handover when ICMPv6 replies inside the
tunnel fail for some while. However, all handovers, including the
ones
occurring from handovers, are delayed for some seconds in order to
wait for e.g. slow wireless interfaces to stabilize during WLAN
authentication.

I am running binary version 1.0.6-4712 (note that the last digit of
the version number is derived directly from the version control
revision). I'd suggest to try it out. Baris is back in the
project and
he might be able to help if the problem persists.

Hi all,

I have taken up again this issue, and I was wondering whether this
bug
has been fixed in the latest versions.
I have been testing the handover in version 1.0.5 and it seems
that it
is still unsolved.

Thanks in advance,
Nerea



Varjonen Samu escribió:
Nerea Toledo Gandarias wrote:
Hello,

I have installed the latest version of HIPL (1.0.4-5) running on ubuntu 8.10 on two vmware virtual machines. Both virtual machines have two ethernet interfaces configured, but eth0 is the only one
that it is up. That is, oops has eth0 3ffe::2/64 and crash has
eth0
3ffe::1/64 configured.
I am testing handover with SSH connection and a video
streaming. I
have installed the SSH server and the video server on oops, that
will
act as a responder, and access to it from crash, which is the
initiator. I perfectly see the base exchange and the data
transmision
ciphrated using ESP.
I have tested soft handover in two different ways:
1.- Introducing the following lines:
oops: sudo ifconfig eth1 up
oops: sudo ifconfig eth1 inet6 add 3ffe::3/64
oops: sudo ifconfig eth0 down

Hi,

This is a known "problem". I changed it some time ago, but it
messed
up someones test environment so it was changed back.

This is what happens in the code:

Eth1 is upped and its address is added everything is fine and then eth0 is downed and its address is removed as a response to netlink
RTM_DELADDR. Now the code counts the addresses on the eth0
interface
and notices that there is none and tries to 0-addr REAP.

Notice the problem ;)

Logically thinking what should happen:

When an address is removed from the interface it should be checked
that if it is the last address on the interface then look for
other
interfaces if there is something we can use.

It is a simple fix, but as I said it was taken out because a test
case
where there was an interface with Internet connectivity and one
that
was only used for nfs. In that case the behavior was not what the
tester wanted it to be and the fix was reverted.

We have one guy who is working on a rewrite of the code on the
experiences we have had with the mobility parts of the code. This
problem is on the list also :)

2.- Using the script handover.sh (/hipl--main--2.6/test/demo/)
In both cases, the connection drops, and you are no longer
connected
with the SSH server neither the video server. With the video
streaming it happens the same, the video gets 'frozen'. The
routes
are well defined.
I find I little bit strange having a script (handover.sh) to
automate
the handover process and have no results using it.

The script uses one interface and its just for testing
purposes. Not
sure of its usefulness to others than me :D

Hope this helped you...


BR,
Samu


Is this possible? What am I doing wrong?

Any help will be appreciated.

Regards,
Nerea





























Other related posts: