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

Subject: Re: cipe-1.5.4, kernel 2.4.19, kernel messages
From: Roberto Nibali <ratz,AT,tac,DOT,ch>
Date: Tue, 13 Aug 2002 12:31:54 +0200
In-reply-to: <3D58140C.20507.34B6A3@localhost>

Cheers mate,

> GW: kernel 2.2.20
> ppp2: 203.52.103.254
> cipcb0: 10.2.0.254
> 
> tux: kernel 2.4.19 
> ppp0: 203.52.103.193
> cicb0: 10.2.1.254
> 
> Does cipe need to be updated slightly to work OK with kernel 2.4.19?

I don't think so, your problem is with fragmentation and iptables.

> Thanks in advance for any advice you can give me :)

I hope I can. First off, provided you have some spare time and will to do, 
could 
you try following (but :

o do a s/REJECT/DROP/g for the out_filt chain in the filter table
o test it with the -j DROP target instead of the -j REJECT for the fun of it 
in
   all chains of the filter table
o disable the clamp_mss target in iptables for the ppp+ devices
o set the route mtu to 1000 bytes (ip route change ${NETWORK}/${MASK} dev \
   ${DEVICE} mtu 1000)
o check your defragmentation, if any defragmented packets are seen with 
tcpdump
o test with the 2.4.20-pre2 kernel :)

> Aug 11 13:54:04 tux kernel: ip_finish_output: bad unowned skb = cf018d40: 
>POST_ROUTING
> Aug 11 13:54:04 tux kernel: skb: pf=2 (unowned) dev=ppp0 len=124
> Aug 11 13:54:04 tux kernel: PROTO=17 203.52.103.193:32780 
>203.52.103.254:1148 L=124 S=0x00 I=15355 
> F=0x0000 T=127
> Aug 11 13:54:06 tux kernel: ip_finish_output: bad unowned skb = cf018ec0: 
>POST_ROUTING
> Aug 11 13:54:06 tux kernel: skb: pf=2 (unowned) dev=ppp0 len=124
> Aug 11 13:54:06 tux kernel: PROTO=17 203.52.103.193:32780 
>203.52.103.254:1148 L=124 S=0x00 I=15356 
> F=0x0000 T=127

I reckon you're having REJECT targets for the cipcb+ interfaces and the 
routing 
seems to be a bit unfortunate. This message is a debug message from the core 
netfilter framework and is generated if you hit a rule with a REJECT target 
and 
need to send back some packets from localhost (such as TCP RSTs or ICMP 
blabla) 
and the routing would like to send those through the tunnel back to the 
originating machine. It might occur that the cipcb+ related routing 
information 
in the fast routing cache doesn't return a path to POST_ROUTING info or some 
voodoo like that. Only real networking gurus could tell you that for sure, 
not 
me. But maybe we're lucky and my suggestions help.

> ipt_REJECT              2752   5  (autoclean)

As promised :)

> 13:56:09 root@tux:/var/log# ifconfig

ifconfig is broken with regards to adv. routing and link selection 
information. 
Please install the iproute2 tools and provide following information:

ip -s -s link show
ip rule show
ip route show
ip -s -s route show cache [this one is very important]

>   214 10516 TCPMSS     tcp  --  *      *       0.0.0.0/0            
>0.0.0.0/0          tcp 
> flags:0x06/0x02 TCPMSS clamp to PMTU 
>     0     0 REJECT     tcp  --  eth0   *       0.0.0.0/0            
>0.0.0.0/0          tcp dpt:110 
> reject-with icmp-port-unreachable 
>     0     0 REJECT     tcp  --  eth0   *       0.0.0.0/0            
>0.0.0.0/0          tcp dpt:143 
> reject-with icmp-port-unreachable 
>     0     0 REJECT     tcp  --  eth0   *       0.0.0.0/0            
>0.0.0.0/0          tcp dpt:220 
> reject-with icmp-port-unreachable 
> 24773 2184K ACCEPT     all  --  eth0   *       0.0.0.0/0            
>0.0.0.0/0          
> 29080 2614K ACCEPT     all  --  *      *       0.0.0.0/0            
>0.0.0.0/0          state 
> RELATED,ESTABLISHED 
>     0     0 log_drop   all  --  *      *       0.0.0.0/0            
>0.0.0.0/0          

I'm a bit confused as to why your bloody return packet hits from the REDIRECT 
target hits the NF_IP_FORWARD ... let's see the rest of the rules

> Chain out_filt (2 references)
>  pkts bytes target     prot opt in     out     source               
>destination         
>     0     0 REJECT     all  --  *      *       0.0.0.0/0            
>199.95.206.210     reject-with 
> icmp-port-unreachable 

Ohhh, this one could be it. Maybe it's enough to simply delete that rule for 
the 
sake of testing or set it to DROP. Could you try that, please?

> Table: nat
> ----------
> Chain PREROUTING (policy ACCEPT 283 packets, 29128 bytes)
>  pkts bytes target     prot opt in     out     source               
>destination         
>     1    48 REDIRECT   tcp  --  eth0   *       0.0.0.0/0            
>0.0.0.0/0          tcp dpt:25 
> redir ports 25 
>     0     0 ACCEPT     all  --  *      *       0.0.0.0/0            
>127.0.0.1          
>     0     0 ACCEPT     all  --  *      *       0.0.0.0/0            
>172.31.1.1         
>     0     0 ACCEPT     all  --  *      *       0.0.0.0/0            
>172.31.2.1         
>   243 13136 ACCEPT     all  --  *      *       0.0.0.0/0            
>10.0.0.254         
>     1    48 REDIRECT   tcp  --  eth0   *       0.0.0.0/0            
>0.0.0.0/0          tcp dpt:80 
> redir ports 2 
> 
> Chain POSTROUTING (policy ACCEPT 287 packets, 17323 bytes)
>  pkts bytes target     prot opt in     out     source               
>destination         
>    23  1926 ACCEPT     all  --  *      cip+    0.0.0.0/0            
>0.0.0.0/0          
>   316 28413 MASQUERADE  all  --  *      *       10.0.0.0/24          
>0.0.0.0/0          
> 
> Chain OUTPUT (policy ACCEPT 475 packets, 33946 bytes)
>  pkts bytes target     prot opt in     out     source               
>destination         

Pretty interesting setup you have here :)

Best regards,
Roberto Nibali, ratz

-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc





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