[hipl-users] Re: Test fails due to use the HIT as a *real* address
- From: Miika Komu <miika@xxxxxx>
- To: hipl-users@xxxxxxxxxxxxx
- Date: Fri, 9 Feb 2007 21:38:27 +0200 (EET)
On Fri, 9 Feb 2007, Jesús Rojo Martínez wrote:
Hi again! :)
Hmm, what kernel did you install? Did you say that you used a binary
kernel or did you patch it yourself?
I've been trying with my own patched&compiled kernels: 2.6.16.x and now
2.6.19.2, I (think I) have tried the precompiled one you give ( 2.6.17.14).
I'll try it again (end of this mail).
2.6.17.14 is the most stable and tested. Please use that. Oleg had some
problems 2.6.19.x series kernel patch. I marked this to the patches just
two days ago.
So, yes, now a 2.6.19.2, there is no SAD (obviusly, the connection failed
with the name and used plain TCP when the addresses were specified). I think
all the modules are loaded, right?
Yes, I think that changing to 2.6.17.14 and if you compile your own
kernel, make sure that...
a) you apply all three patches or
b) use the source package which is already patched
Hopefully the patching process will end soon as we have contributed some
patches already to the kernel. Some work still remains to be done, though.
Do you see any output of hipd e.g. in /var/log/syslog? Some "hip_error"
lines?
Mmm, some, but doesn't look extrange. Just this ones:'
Feb 9 16:06:28 node1 hipd[6929]: error(nlink.c:1073@parse_rtattr) Deficit
len 28, rta_len=0
[...]
Feb 9 16:06:35 node1 hipd[6929]: error(
hadb.c:310@hip_hadb_add_peer_info_complete)
Ignoring new mapping, old one exists
(These ones above are repeated several times)
Feb 9 16:11:04 node1 hipd[6929]:
error(netdev.c:394@hip_netdev_handle_acquire)
if_index NOT determined
Feb 9 16:11:04 node1 hipd[6929]: error(hipd.c:534@main) Netlink receiving
failed
Do they say you something?
Usually this occurs when your machine cannot route packets to the peer
using the plain IP addresses. Anyway, try the kernel switch first.
You have set two IPs per node. Try having a single IP per node by
commenting extra IPs with # in the beginning of the line.
That was my first try (well, with just one HIT and two IPs... I'll try
only one IP, results are down together with the precompiled version of
kernel&HIPL). Since it didn't work I tried it again with two. Does it matter
which HIT I am using?
No. There is tool called test/pingtest.sh which allows you to iterate and
ping through all of the src/dst combinations.
tcpdump -n -i any esp or proto 253 or port 50500
Please just show the tcpdump output as it is without any patching.
Nothing. It doesn't capture anything :S I have OpenDHT disable, if I use
an enable hipl version I see something (probably is not because the dht,
cuase what I see is independently of it, and I try it again and now it
doesn't show anything :S). So, when executing client-gai:
16:37:40.178069 IP6 3ffe::1 > 3ffe::2: ip-proto-253 40
16:37:40.193023 IP6 3ffe::2 > 3ffe::1: ip-proto-253 576
16:37:40.246468 IP6 3ffe::1 > 3ffe::2: ip-proto-253 824
16:37:42.130213 IP6 3ffe::1 > 3ffe::2: ip-proto-253 40
16:37:42.139876 IP6 3ffe::2 > 3ffe::1: ip-proto-253 760
16:37:42.199715 IP6 3ffe::1 > 3ffe::2: ip-proto-253 640
16:37:42.467241 IP6 3ffe::2 > 3ffe::1: ip-proto-253 128
This looks like a base exchange to me, but there is something wrong with
IPsec set-up in 2.6.19 patch.
And this is quite extrange: First that fails to connect to the OpenDHT,
even if the network works well; second that it needs to connect to the DHT
when the mapping are already in the config file.
And tcpdump captures some packets, BUT previous to the execution of the
client-gai (but after the execution of the server in the peer):
node1:~# tcpdump -n -i any esp or proto 253 or port 50500
tcpdump: WARNING: Promiscuous mode not supported on the "any" device
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
16:56:59.093473 IP 10.0.1.2 > 10.0.1.1: ip-proto-253 40
16:57:05.205681 IP 10.0.1.2 > 10.0.1.1: ip-proto-253 40
Any ideas?
Let's try with only one HIT and only one IP address...
Are you running hipd also on the other host in this case?
Well, after changing the conf and restart the daemon, I have realized that
it complains about a missing module in your prebuilt version (I guess is
builtin the kernel), but just in case:
node1:/etc/hip# /etc/init.d/hipd start
Starting hipd.
FATAL: Module xfrm4_mode_beet not found.
FATAL: Module xfrm6_mode_beet not found.
debug(hipconf.c:367@hip_conf_handle_map): action=1 optc=2
debug(debug.c:566@hip_print_hit): id:
2001:007c:d397:1b35:2ae9:cea3:5fcc:1afb
debug(debug.c:566@hip_print_hit): id:
3ffe:0000:0000:0000:0000:0000:0000:0002
info(hipconf.c:955@hip_do_hipconf): hipconf command successfull
And again, the same exctly error as above (with several HITs and IPs), but
no packets captured at all with tcpdump.
And also again, if I try to connect directly specifying the address
instead of the name, it connects throught plain TCP (no packets captured in
tcpdump and client-gai connects perfeclty).
Sorry if there are too much information now in this mail, but I hope it
can be useful.
Any new idea?
Please change the kernel version. Thx,
--
Miika Komu http://www.iki.fi/miika/
Other related posts:
