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

To: cipe-l,AT,inka,DOT,de
Subject: routing, cipe using wrong interface (long)
From: Markus Röder <markus.roeder,AT,makeit4u,DOT,de>
Date: Fri, 23 Jan 2004 12:37:19 +0100

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 )



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