On Tue, 27 Feb 2007, Jesús Rojo Martínez wrote: Finally answering to this earlier email.
Hi again, I cannot understand anything... :S I tried again the ping6 (without specifying the source HIT) and first it said: connect: Resource temporarily unavailable Then again (just 1s after)... and it worked!!! O_O Do you have any explanation for this? On 2/27/07, Jesús Rojo Martínez <jrojomartinez@xxxxxxxxx> wrote:Hi again!, Yes, this seems to be successful. Good :) But, why didn't it work with IPv4 if I had the default route for it? What other problems was there? (It would be good to know the bugs to include them in my report). * Tests with hipl-patch-208: > > BUT it doesn't work with a direct ping6 to the HIT :S Shouldn't it > work? > > There is no packet in tcpdump, and no log in syslog... > > Is it so that the first ping is dropped? And if you try it again, it > will > succeed? No, I waited enough. I did it again now with the patch-208. 10 packets lost, and after that, another try with another 10 packets lost. Logs in test-ping6/ping6.
There are already bugs filed for problems with the sleep patch and ipsec routing and they are marked as high priority bugs.
With IPv4 still does not work at all, and syslog has some strange errors like: if_index NOT determined Netlink receiving failed Logs in test-ping6/pingtest/ipv4. (I've tried it specifying the peer IP as both, the IPv4 and the IPv6, and the resulst... none of them worked... and a syslog of 10Mb :S ).
I cannot repeat your IPv4 problem on my machine. The original email did not include any attachments. I did not understand whether this one occurred with or without hipd_config. I assume the latter?
> * With hipd_config (and IPv6 addresses, although it fails with IPv4 as > > well): > > > > AGAIN it get frozen "waiting for daemon info". > > Logs in tar file test4. > > To stand out, the log: > > > > debug(user.c:323@hip_handle_user_msg) No response sent > > Ok, for the last time, please try this just once again because I am not > able to reproduce it. There was a bind() call missing from resolver. > Interestingly, it seemes to produce different results on different > machines. No :(( It still doesn't work. It gets frozen with both, IPv4 and v6. Logs in test-hipd_config/{ipv4,ipv6}. In both there is an strange error that says: "hip_sendto() failed".
Well, if you need the hipd_config, maybe you could debug it a little bit by yourself because I am not able to repeat it. Basically what happens upon configuration reading is that hipd sends multiple udp messages to itself and reads them. This was designed like this because we could reuse hipconf functionality for reading the configuration.
The function call chain is as follows:
sending:
hipd.c:main()
init.c:hipd_init()
init.c:hip_load_configuration()
getendpointinfo.c:hip_conf_handle_load()
hipconf.c:hip_do_hipconf()
hipconf.c:hip_send_daemon_info_wrapper()
message.c:hip_send_daemon_info_wrapper()
receiving:
hipd.c:main()
message.c:hip_read_user_control_msg()
user.c:hip_handle_user_msg()
After doing this N times (where N is the number of commands in your
config), hipd should remain looping in hipd.c:main() select loop.
hipl--main--2.6--patch-209 is the latest version of hipl. -- Miika Komu http://www.iki.fi/miika/
