routing, cipe using wrong interface (long)

Hi List

I have a very weird problem getting cipe to work.
I know this is quite a lot of info to read, but i hope somebody takes the 
time and can give me the final hint to resolve this strange behaviour
I have the following Setup:

	eth0:		93.0.0.2/8			#internal Net
	eth1:		218.8.157.154/29		# official Ip's
	ippp0:		10.0.0.10 ptp 10.0.0.11		# ISDN Dial-Up
	dvb0_0:	172.21.16.12/16			# Dummy-Interface for DSL via Sat

Here's the routing table while ippp0 is not connected:

	Kernel IP routing table
	Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
	10.0.0.11       0.0.0.0         255.255.255.255 UH    0      0        0 ippp0
	218.8.157.152   0.0.0.0         255.255.255.248 U     0      0        0 eth1
	172.21.0.0      0.0.0.0         255.255.0.0     U     0      0        0 dvb0_0
	93.0.0.0        0.0.0.0         255.0.0.0       U     0      0        0 eth0
	0.0.0.0         10.0.0.11       0.0.0.0         UG    0      0        0 ippp0

When the Dial-Up connection is triggered I start a pptp connection to the 
Astra-Server generating a new device ppp0
which uses the dvb0_0 interface to increase downstream bandwidth. Routing 
Table looks like this:

	Kernel IP routing table
	Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
	218.8.158.2     0.0.0.0         255.255.255.255 UH    0      0        0 
ippp0		# Don't use Sat for DNS
	195.27.93.5     0.0.0.0         255.255.255.255 UH    0      0        0 
ippp0		# Secondary DNS
	195.27.93.15    0.0.0.0         255.255.255.255 UH    0      0        0 
ippp0		# ippp0 Link-Partner
	212.56.240.62   0.0.0.0         255.255.255.255 UH    0      0        0 
ippp0		# Astra-Server
	212.56.240.60   0.0.0.0         255.255.255.255 UH    0      0        0 
ppp0		# Astra-Server
	218.8.157.152   0.0.0.0         255.255.255.248 U     0      0        0 eth1
	172.21.0.0      0.0.0.0         255.255.0.0     U     0      0        0 dvb0_0
	93.0.0.0        0.0.0.0         255.0.0.0       U     0      0        0 eth0
	0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 
ppp0		#  Default using Sattelite downstream

So far the Network Setup which is a little complicated but is working.

Now I start cipe with the following options:

	# cat /etc/cipe/options
	device          cipcb0
	me              218.8.157.154:9001
	peer            0.0.0.0:9001
	ipaddr          172.31.0.5
	ptpaddr         172.31.0.6
	dynip           no
	maxerr          -1
	key             somekey

which gives me

	# netstat -lupn
	...
	udp        0      0 
0.0.0.0:9001            0.0.0.0:*               ESTABLISHED 4012/ciped-cb
	...

and the following in the logs:
	Jan 23 12:21:34 tdslproxy ciped-cb[18492]: CIPE daemon vers 1.5.4 (c) Olaf 
Titz 1996-2000
	Jan 23 12:21:34 tdslproxy kernel: cipcb0: setpar
	Jan 23 12:21:34 tdslproxy kernel: cipcb0: setpar 0.0.0.0:0 1000 60000 0600 0
	Jan 23 12:21:34 tdslproxy kernel: cipcb0: setkey
	Jan 23 12:21:34 tdslproxy kernel: cipcb0: attach
	Jan 23 12:21:34 tdslproxy kernel: cipcb0: opened
	Jan 23 12:21:34 tdslproxy ciped-cb[18492]: peer configuration info: 
proto=3, crypto=b, version=1.5, correct key parser
	Jan 23 12:21:34 tdslproxy ciped-cb[18492]: peer configuration info: 
proto=3, crypto=b, version=1.5, correct key parser

Shouldn't cipe bind it's socket to just 218.8.157.154:9001?

To be sure that the cipe-traffic uses the right interface i have

	# ip rule show show
	0:      from all lookup local
	32765:  from all fwmark        1 lookup cipe
	32766:  from all lookup main
	32767:  from all lookup default

	# ip route show table cipe
	default via 218.8.157.153 dev eth1

	iptables -t mangle -A OUTPUT -p udp --dport 9001 -j MARK --set-mark 1

After starting the client side i get the following in /var/log/messages:
	Jan 23 11:40:21 tdslproxy kernel: cipcb0: new peer 218.8.158.194:9001
	Jan 23 11:40:21 tdslproxy kernel: cipcb0: cipe_sendmsg
	Jan 23 11:40:21 tdslproxy kernel: cipcb0: cipe_recvmsg
	Jan 23 11:40:21 tdslproxy kernel: cipcb0: cipe_sendmsg
	Jan 23 11:40:21 tdslproxy kernel: cipcb0: setkey
	Jan 23 11:40:21 tdslproxy kernel: cipcb0: cipe_recvmsg
	Jan 23 11:40:22 tdslproxy kernel: cipcb0: setkey
	Jan 23 11:40:22 tdslproxy kernel: cipcb0: cipe_sendmsg
	Jan 23 11:40:22 tdslproxy kernel: cipcb0: cipe_recvmsg
	Jan 23 11:40:22 tdslproxy kernel: cipcb0: cipe_sendmsg
	Jan 23 11:40:22 tdslproxy kernel: cipcb0: setkey
	Jan 23 11:40:22 tdslproxy kernel: cipcb0: cipe_recvmsg
	Jan 23 11:40:22 tdslproxy kernel: cipcb0: cipe_recvmsg
	Jan 23 11:40:22 tdslproxy kernel: cipcb0: setkey
	Jan 23 11:40:22 tdslproxy kernel: cipcb0: cipe_recvmsg
	Jan 23 11:40:40 tdslproxy kernel: UDP: bad checksum. From 172.31.0.6:137 
to 172.31.0.5:137 ulen 58
	Jan 23 11:40:42 tdslproxy last message repeated 2 times

so I think the client is connected and they exchange messages just fine.
tcpdump shows the traffic on interface eth1 (both directions).


Now comes the weird thing:
If i do a 'ping 172.31.0.5' on the connected client i can see arriving cipe 
packets on eth1, but there's no reply to those packets on eth1
Upon further investigation i found that the replies take the Systems 
default route which triggers the dial-up Link and in the Logs i get:
	Jan 23 12:24:06 tdslproxy kernel: cipcb0: cipe_sendmsg
	Jan 23 12:24:06 tdslproxy kernel: cipcb0: setkey
	Jan 23 12:24:06 tdslproxy kernel: cipcb0: cipe_recvmsg
	Jan 23 12:24:11 tdslproxy kernel: cipcb0: changing my address: 172.24.130.146
	
So here comes the big question:
- How do i tell cipe to use the correct interface for it's traffic
- How do i tell cipe to bind it's listening socket to the correct interface 
( not 0.0.0.0:9001 )


--
Message sent by the [email protected] mailing list.
Unsubscribe: mail [email protected], "unsubscribe cipe-l" in body
Other commands available with "help" in body to the same address.
CIPE info and list archive: <URL:http://sites.inka.de/~bigred/devel/cipe.html>