[hipl-users] Re: Some errors when doing pingtest with hipl-1.0.1

On Fri, 5 Jan 2007, Tomi Hautakoski wrote:

Hi Tomi,
I ran pingtest.sh from 3ffe::6 to 3ffe::7 on a local WLAN and noticed some errors in the logs. Kernel version is 2.6.15.7 and logs are here: 

http://www.ee.oulu.fi/~thautako/hipl-log-05-01-07.txt
http://www.ee.oulu.fi/~thautako/pingtest-log-05-01-07.txt
1) Is this something to be worried about(e.g. line 2316), it happens multiple times during the test: 

debug(input.c:2483@hip_receive_r2): Received R2 in state ESTABLISHED
error(input.c:2499@hip_receive_r2): Dropping
debug(input.c:663@hip_receive_control_packet): Done with control packet, err is -14.
Dropping R2 in ESTABLISHED state is standardized behaviour. See table 6 in the base draft.
If you look at tcpdump, it will probably tell you that multiple R2 packets were actually sent? Maybe few packets were dropped by the WLAN? Or maybe the implementation specific HIP_RETRANSMIT_INTERVAL (in hipd/hipd.h) is too short?
2) On line 3202, I thought that puzzles would be created so that they can be always solved if the needed cpu-power is present? 

debug(crypto.c:596@impl_dsa_verify): DSA verify: 1
info(cookie.c:179@hip_solve_puzzle): puzzle0x0101000c0a2a48498f7c6db09b8f1918
debug(cookie.c:193@hip_solve_puzzle): (u->pz.I: 0x18198f9bb06d7c8f
debug(cookie.c:211@hip_solve_puzzle): K=10, maxtries (with k+2)=4096
error(cookie.c:253@hip_solve_puzzle): Could not solve the puzzle, no solution found 
error(input.c:1237@hip_handle_r1): Solving of puzzle failed
error(input.c:1361@hip_receive_r1): Handling of R1 failed
I have noticed this too sometimes but I haven't done anything to it because retransmissions deal with it. The implementation tries does not scan the whole solution space because it is exponentially larger when K increases. Can you repeat the problem by e.g. doubling the maxtries in hipd/cookie.c:hip_solve_puzzle(): 

                maxtries = 1ULL << (u->pz.K + 3); /* fix */
3) When shutting down, this happens also multiple times. Removing routes fail or something? At least on line 9015:
debug(debug.c:566@hip_print_hit): daddr: 3ffe:0000:0000:0000:0000:0000:0000:0006 
debug(beet.c:355@hip_xfrm_state_delete): IPV6 SA deletion
debug(beet.c:360@hip_xfrm_state_delete): sport 0, dport 0
error(nlink.c:160@netlink_talk): Cannot talk to rtnetlink Bad file descriptor
My guess is that it is trying to remove security associations on closed NETLINK socket. I need to fix my virtual machines before I can do IPv6 again, I could not repeat this problem on IPv4. In any case, this should not be a very serious problem.
4) At least around line 3238 and onwards, the nasty "I1 was already sent, ignoring" error. Actually this has been a really nasty bug for me when using hipl because I haven't been able to stop it from happening randomly and usually hipd doesnt recover from the sending I1 loop. Adding some sleep()'s between 'hipconf add map' and sending packets to remote HIT helped a bit but it still happens quite often even when not using the last HIT of 'hipconf get hi default'. Any news on bug #175? In this test, looks like hipd actually was able to continue but after 200+ iterations... 

Just got off from a two week holiday. I can have a look at this beast.

--
Miika Komu                                       http://www.iki.fi/miika/

Other related posts: