<< | 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 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 
that basically the connection works, you simply don't like the kernlog 

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

         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))){
                                        " bad unowned skb = %p: ",skb);
                                 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:


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

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

Yep, right.

> 22:10:53 root@tux:~# ip route show
> dev ppp0  proto kernel  scope link  src
> dev cipcb0  proto kernel  scope link  src
> dev eth0  proto kernel  scope link  src
> dev lo  scope link
> default via dev ppp0
> 22:11:28 root@tux:~#

So do I assume correctly that you actually have the cipcb0 interface on top 
the ppp0 interface but you're only routing the cipe-related network through 
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 
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.

> from via 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 

> Ping statistics for
>     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 
cipcb0 interface while pinging?

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

Best regards,
Roberto Nibali, ratz

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

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