Hello Miika, Miika Komu escribió:
This command functioned perfectly, so I think I've got HIP properly installed. Thanks.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:hiplOr are you actually trying to download the binaries? It's a bit unclear to me.
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.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.
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 packetdebug(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: 0x0000debug(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 givendebug(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 0debug(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 daemonSo, 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 UNASSOCIATEDThis 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. Ihave installed the SSH server and the video server on oops, that willact as a responder, and access to it from crash, which is theinitiator. I perfectly see the base exchange and the data transmisionciphrated 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 downHi, 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 casewhere 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 automatethe 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, SamuIs this possible? What am I doing wrong? Any help will be appreciated. Regards, Nerea
-- Nerea Toledo Gandarias Departament of Electronics and Telecommunications University of The Basque Country ETSI Bilbao Tel: +34 94 601 7396 UPV / EHU Fax: +34 94 601 4259 Alda Urquijo s/n 48013 - Bilbao (Spain)