<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: CIPE 1.5.2 Linux - Strange behaviour :-(((
From: RoMaN SoFt / LLFB <roman,AT,madrid,DOT,com>
Date: Mon, 24 Sep 2001 14:29:16 +0200

 Hello.

 I posted some time ago about problems establishing a CIPE link
between a 2.4.4 Linux and a 2.2.19 Linux, both with 1.5.2 version of
Cipe. Well, those problems were NOT solved, but I temporarily leave it
'cause I was too much busy. Now I re-take cipe stuff and I want to
solve it.

 I'm going to sumarize because all scheme is difficult (and hard) to
explain.

 The main problem is that CIPE link works on only one way but not in
the other way. I mean, if the hosts running CIPE are named A and B, I
can send encapsulated (over cipcb0) packets from A to B, but NOT from
B to A. I've looked routes, firewall rules, etc and all seems to be
ok: path from B to A should be perfectly ok. Indeed it seems A and B
are "speaking" CIPE protocol ok. But if I examine logs when trying to
send to a IP attached to the CIPE dev  I can see Cipe is sending
packets to the wrong IP !!!!!! This "strange" IP results to be
1.0.0.0. I don't know where the hell is this IP coming from, because I
haven't not entered in any config file (/etc/cipe/options or similar).
I'm totally lost! This is confusing.

 Here you have some logs.

1) I start CIPE on both A and B hosts.

* /var/log/messages on A:

 Sep 24 13:51:20 goliat ciped-cb[701]: CIPE daemon vers 1.5.2 (c) Olaf
Titz 1996-2000
Sep 24 13:51:20 goliat kernel: cipcb0: alloc
Sep 24 13:51:20 goliat kernel: cipcb: read_lock(&tasklist_lock) at
../cipe/device.c:216
Sep 24 13:51:20 goliat kernel: cipcb: read_unlock(&tasklist_lock) at
../cipe/device.c:220
Sep 24 13:51:20 goliat kernel: cipcb0: setpar
Sep 24 13:51:20 goliat kernel: cipcb0: setpar 0.0.0.0:0 1000 60000
0200 0
Sep 24 13:51:20 goliat kernel: cipcb0: setkey
Sep 24 13:51:20 goliat kernel: cipcb0: setkey 1
Sep 24 13:51:20 goliat kernel: cipcb0: attach
Sep 24 13:51:20 goliat kernel: cipcb0: opened
Sep 24 13:51:20 goliat kernel: cipcb0: cipe_sendmsg
Sep 24 13:51:20 goliat kernel: cipcb0: real sendmsg len 21
text=0000...
Sep 24 13:51:20 goliat kernel: cipcb0: cipe_recvmsg
Sep 24 13:51:20 goliat ciped-cb[701]: peer configuration info:
proto=3, crypto=b, version=1.5, correct key parser
Sep 24 13:51:20 goliat kernel: SKB ():
Sep 24 13:51:20 goliat kernel:  0000:  0000 0000 0000 0000  0000 0000
40e7 9dcc  ............@ç.Ì
Sep 24 13:51:20 goliat kernel:  0010:  381e af3b c6fc 0b00  0000 0000
d4db 85ce  8.¯;Æü......ÔÛ.Î
Sep 24 13:51:20 goliat kernel:  0020:  c0db 85ce b2db 85ce  e066 0dcc
0000 0000  ÀÛ.βÛ.Îàf.Ì....
Sep 24 13:51:20 goliat kernel:  0030:  0000 0000 0000 0000  0000 0000
0000 0000  ................
Sep 24 13:51:20 goliat kernel:  0040:  0000 0000 0000 0000  0000 0000
0000 0000  ................
Sep 24 13:51:20 goliat kernel:  0050:  0000 0000 0000 0000  0000 0000
1d00 0000  ................
Sep 24 13:51:20 goliat kernel:  0060:  0000 0000 8422 ffff  0001 0002
0000 0000  ....."ÿÿ........
Sep 24 13:51:21 goliat kernel:  0070:  0100 0000 0800 0000  0001 0000
a0db 85ce  ............?Û.Î
Sep 24 13:51:21 goliat kernel:  0080:  d4db 85ce f1db 85ce  00dc 85ce
842a 1bc0  ÔÛ.ÎñÛ.Î.Ü.Î.*.À
Sep 24 13:51:21 goliat kernel:  0090:  0000 0000 0040 0000  0000 0000
0000 0000  .....@..........
Sep 24 13:51:21 goliat kernel: received: packet len=29 dev=<none>
Sep 24 13:51:21 goliat kernel:  0000:  d1a2 d1a2 001d 0000  0000 0000
0000 0000  ѢѢ............
Sep 24 13:51:21 goliat kernel:  0010:  7600 0000 4349 5045  0362 0105
01         v...CIPE.b...   
Sep 24 13:51:21 goliat kernel: cipcb: sa=62.22.78.68 da=192.168.5.200
us=53666 ud=53666 ul=29
Sep 24 13:51:21 goliat kernel: got unencrypted packet (iv=0) len=21
Sep 24 13:51:21 goliat kernel: cipcb0: returning 13 flags 0010
Sep 24 13:51:21 goliat kernel: cipcb0: cipe_recvmsg

* /var/log/messages on B:

Sep 24 14:32:22 sniff ciped-cb[18644]: CIPE daemon vers 1.5.2 (c) Olaf
Titz 1996-2000
Sep 24 14:32:22 sniff kernel: cipcb0: alloc
Sep 24 14:32:22 sniff kernel: cipcb0: setpar
Sep 24 14:32:22 sniff kernel: cipcb0: setpar 0.0.0.0:0 1000 60000 0200
0
Sep 24 14:32:22 sniff kernel: cipcb0: setkey
Sep 24 14:32:22 sniff kernel: cipcb0: setkey 1
Sep 24 14:32:22 sniff kernel: cipcb0: attach
Sep 24 14:32:22 sniff kernel: cipcb0: opened
Sep 24 14:32:22 sniff kernel: cipcb0: cipe_sendmsg
Sep 24 14:32:22 sniff kernel: cipcb0: real sendmsg len 21 text=0000...
Sep 24 14:32:22 sniff kernel: cipcb0: cipe_recvmsg
Sep 24 14:32:32 sniff kernel: SKB (eth2):
Sep 24 14:32:32 sniff kernel:  0000:  0000 0000 0000 0000  0000 0000
c0d1 43c7  ............ÀÑCÇ
Sep 24 14:32:32 sniff kernel:  0010:  e027 af3b 70f6 0e00  200a 22c0
947d 88c7  à'¯;pö.. ."À.}.Ç
Sep 24 14:32:32 sniff kernel:  0020:  807d 88c7 727d 88c7  80a4 eec0
0000 0000  .}.Çr}.Ç.¤îÀ....
Sep 24 14:32:32 sniff kernel:  0030:  0000 0000 0000 0000  0000 0000
0000 0000  ................
Sep 24 14:32:32 sniff kernel:  0040:  0000 0000 0000 0000  0000 0000
0000 0000  ................
Sep 24 14:32:32 sniff kernel:  0050:  0000 0000 0000 0000  0000 0000
1d00 0000  ................
Sep 24 14:32:32 sniff kernel:  0060:  436f 178c 0000 0000  0000 0000
0000 0000  Co..............
Sep 24 14:32:32 sniff kernel:  0070:  0100 0000 0800 0000  6000 0000
607d 88c7  ........`...`}.Ç
Sep 24 14:32:32 sniff kernel:  0080:  947d 88c7 b17d 88c7  c07d 88c7
3047 16c0  .}.DZ}.ÇÀ}.Ç0G.À
Sep 24 14:32:32 sniff kernel:  0090:  0000 0000 0000 0000  0000 0000
0000 0000  ................
Sep 24 14:32:32 sniff kernel:  00a0:  0000 0000 0000 0000
........        
Sep 24 14:32:32 sniff kernel: received: packet len=29 dev=eth2
Sep 24 14:32:32 sniff kernel:  0000:  d1a2 d1a2 001d 0000  0000 0000
0000 0000  ѢѢ............
Sep 24 14:32:32 sniff kernel:  0010:  7500 0000 4349 5045  0362 0105
01         u...CIPE.b...   
Sep 24 14:32:32 sniff kernel: cipcb: sa=213.97.108.159 da=192.168.2.1
us=53666 ud=53666 ul=29
Sep 24 14:32:32 sniff kernel: got unencrypted packet (iv=0) len=21
Sep 24 14:32:32 sniff kernel: cipcb0: returning 13 flags bffff85c
Sep 24 14:32:32 sniff kernel: cipcb0: cipe_sendmsg
Sep 24 14:32:32 sniff kernel: cipcb0: real sendmsg len 21 text=0000...
Sep 24 14:32:32 sniff ciped-cb[18644]: peer configuration info:
proto=3, crypto=b, version=1.5, correct key parser
Sep 24 14:32:32 sniff kernel: cipcb0: cipe_recvmsg

 CIPE software on both peers seems to be working and talking to each
other, isnt' it????

2) Here you can see some routing info on B:

B:~ # ip rule     
0:      from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default 
B:~ # ip route list
192.168.6.254 dev cipcb0  proto kernel  scope link  src 192.168.7.254 
192.168.5.0/24 via 192.168.1.2 dev eth1  metric 10 
192.168.2.0/24 via 192.168.2.20 dev eth2 
192.168.2.0/24 dev eth2  proto kernel  scope link  src 192.168.2.1 
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.4 
192.168.0.0/24 via 192.168.1.2 dev eth1  metric 10 
127.0.0.0/8 dev lo  scope link 
default via 192.168.2.20 dev eth2 

As you can see B's CIPE device is 192.168.7.254. And the remote party
should be 192.168.6.254. So, if I ping to 192.168.6.254, packets are
routed through CIPE dev (cipcb0). This is ok. Routing seems to be
perfect.

3) My CIPE options on B:

B:~ # cat /etc/cipe/options 
# Fichero configuracion CIPE _sniff_

# Without a "device" line, the device is picked dynamically

# the peer's IP address
ptpaddr         192.168.6.254
# our CIPE device's IP address
ipaddr          192.168.7.254
# my UDP address. Note: if you set port 0 here, the system will pick
# one and tell it to you via the ip-up script. Same holds for IP
0.0.0.0.
me              192.168.2.1:53666
# ...and the UDP address we connect to. Of course no wildcards here.
peer            213.97.108.xxx:53666
# The static key. Keep this file secret!
# The key is 128 bits in hexadecimal notation.
key             [removed from obvious reasons]
B:~ #

4) And now the final probe. You'll see CIPE sending packets to the
WRONG IP !!! Why??? This is a mistery.

B:~ # ping -c 1 192.168.6.254 
PING 192.168.6.254 (192.168.6.254): 56 data bytes
--- 192.168.6.254 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
B:~ #

 I'm sending one ping packet; no response is received cause CIPE isn't
working ok. But let's have a look to the generated packets:

B:/etc/cipe # tcpdump -ni cipcb0
User level filter, protocol ALL, datagram packet socket
tcpdump: listening on cipcb0
14:36:59.448024 192.168.7.254 > 192.168.6.254: icmp: echo request

 This is ok. The ping packet is routed through CIPE device. But:

B:/etc/cipe # tcpdump -ni eth2 port 53666
User level filter, protocol ALL, datagram packet socket
tcpdump: listening on eth2
14:37:54.574601 213.97.108.xxx.53666 > 1.0.0.0.53666: udp 104

 CIPE is sending packet to 1.0.0.0 address instead of 213.97.108.xxx
!!!!! WHY!???

 Any way of debugging this??? I'm completely lost :-((

 Regards, and thanks in advance. I need your help.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
    ** RoMaN SoFt / LLFB **  
       roman,AT,madrid,DOT,com
   http://pagina.de/romansoft
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~





<< | Thread Index | >> ]    [ << | Date Index | >> ]