<< | 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: Wed, 14 Aug 2002 11:21:08 +0200
In-reply-to: <3D598878.28343.34C5DB@localhost>

Hi,

> Hi Roberto.
> I've tried a few of your suggestions.  See below.  I'll try the others a 
>bit later when

Yeah, I see, that's what I get for trying to sound intelligent ...

> I have more time.  Even if I can avoid it by changing iptables rules, surly 
>it has to
> be considered a bug?  (It certainly bugs me :)

Ok, I've not told you yet but it is not really a bug per se. It's a debug 
message produced by the netfilter core code. From your output logs I can 
derive 
that basically the connection works, you simply don't like the kernlog 
message.

The message you see comes from the ../net/core/netfilter.c:

   nf_debug_ip_finish_output2():
         if (skb->sk) {
                  [ ... code if skb->sk ----> owned ... ]
         } else {
                 if (skb->nf_debug != ((1 << NF_IP_PRE_ROUTING)
                                       | (1 << NF_IP_FORWARD)
                                       | (1 << NF_IP_POST_ROUTING))) {
                         /* Fragments, entunnelled packets, TCP RSTs
                            generated by ipt_REJECT will have no
                            owners, but still may be local */
                         if (skb->nf_debug != ((1 << NF_IP_LOCAL_OUT)
                                               | (1 << NF_IP_POST_ROUTING))){
                                 printk("ip_finish_output:"
                                        " bad unowned skb = %p: ",skb);
                                 debug_print_hooks_ip(skb->nf_debug);
                                 nf_dump_skb(PF_INET, skb);
                         }
                 }
         }

Now that's why I've given you those ideas about dropping the REJECT in the 
out_filt chain. As you can easily verify in ../net/ipv4/ip_output.c:

#ifdef CONFIG_NETFILTER_DEBUG
         nf_debug_ip_finish_output2(skb);
#endif /*CONFIG_NETFILTER_DEBUG*/

It's a debug message you get if you enabled CONFIG_NETFILTER_DEBUG. Nothing 
to 
really worry about. (Besides the fact that the function name is really 
braindead)

> It happens with small ping packets and when opening a TCP connection with 
>netcat
> so I don't think there are any fragments.

Yep, right.

> 22:10:53 root@tux:~# ip route show
> 203.52.103.254 dev ppp0  proto kernel  scope link  src 203.52.103.193
> 10.2.0.254 dev cipcb0  proto kernel  scope link  src 10.2.1.254
> 10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.254
> 127.0.0.0/8 dev lo  scope link
> default via 203.52.103.254 dev ppp0
> 22:11:28 root@tux:~#

So do I assume correctly that you actually have the cipcb0 interface on top 
of 
the ppp0 interface but you're only routing the cipe-related network through 
the 
tunnel? Because if something weird happens with the tunnel and cipe wants to 
send back an acknowledgement to the originating IP address which is not in 
the 
scope of the cipcb0-network, the packet will take the default route over ppp0 
and thus this could result in an unowned skb.

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

Ah, I should have told you to do an 'ip route flush cache' prior to this.

> 203.52.78.145 from 203.52.103.193 via 203.52.103.254 dev ppp0
>     cache  users 1 used 9 age 313sec mtu 1490 rtt 160ms rttvar 80ms cwnd 2

This theoretically could be your ping, congestion window to 2 and rtt of 
about 
160ms.

> Ping statistics for 10.2.0.254:
>     Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),

Well, it seems to work. What kind of packets do you see when you tcpdump on 
the 
cipcb0 interface while pinging?

> Aug 13 22:05:15 tux ipop3d[8097]: connect from 10.0.0.198
> Aug 13 22:05:41 tux kernel: ip_finish_output: bad unowned skb = cefeec80: 
>POST_ROUTING
> Aug 13 22:05:41 tux kernel: skb: pf=2 (unowned) dev=ppp0 len=108
> Aug 13 22:05:41 tux kernel: PROTO=17 203.52.103.193:32780 
>203.52.103.254:1261 L=108 S=0x00 I=12090 
> F=0x0000 T=127
> Aug 13 22:05:42 tux kernel: ip_finish_output: bad unowned skb = cefeec80: 
>POST_ROUTING
> Aug 13 22:05:42 tux kernel: skb: pf=2 (unowned) dev=ppp0 len=108
> Aug 13 22:05:42 tux kernel: PROTO=17 203.52.103.193:32780 
>203.52.103.254:1261 L=108 S=0x00 I=12091 
> F=0x0000 T=127
> Aug 13 22:06:55 tux ipop3d[8108]: connect from 10.0.0.198

Best regards,
Roberto Nibali, ratz

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





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