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

Subject: Re: cipe-1.5.4, kernel 2.4.19, kernel messages
From: "Steve Ripps" <stever,AT,sttc,DOT,net,DOT,au>
Date: Wed, 14 Aug 2002 11:53:15 +0200
In-reply-to: <3D5A1EB4.8090208@tac.ch>

19:20:40 root@tux:/usr/src/linux# grep CONFIG_NETFILTER_DEBUG .config
CONFIG_NETFILTER_DEBUG=y

Hmm.  So I just turn this off, recompile and forget about it?  Cool :)
I was thinking that is was something serious that would perhaps
cause a kernel panik or something...  I wonder why I even turned it on
anyway?  Silly me.

> 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?
Yep.

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

19:36:03 root@gw:~# tcpdump --version
tcpdump version 3.7.1
libpcap version 0.4
Usage: tcpdump [-adeflnNOpqRStuvxX] [ -c count ] [ -C file_size ]
                [ -F file ] [ -i interface ] [ -r file ] [ -s snaplen ]
                [ -T type ] [ -w file ] [ -E algo:secret ] [ expression ]
19:36:08 root@gw:~# tcpdump -i cipcb0
tcpdump: unknown physical layer type 0x300

Bugger.  Try other end of tunnel:
19:37:25 root@gw:~# ping -c2 10.2.1.254
PING 10.2.1.254 (10.2.1.254) from 10.2.0.254 : 56(84) bytes of data.
64 bytes from 10.2.1.254: icmp_seq=1 ttl=64 time=300 ms
64 bytes from 10.2.1.254: icmp_seq=2 ttl=64 time=220 ms

--- 10.2.1.254 ping statistics ---
2 packets transmitted, 2 received, 0% loss, time 1010ms
rtt min/avg/max/mdev = 220.118/260.296/300.475/40.181 ms
19:38:04 root@gw:~#
19:37:30 root@tux:~# tcpdump -i cipcb0
tcpdump: listening on cipcb0
19:38:01.239787 10.2.0.254 > 10.2.1.254: icmp: echo request
19:38:01.249763 10.2.1.254 > 10.2.0.254: icmp: echo reply
19:38:02.199715 10.2.0.254 > 10.2.1.254: icmp: echo request
19:38:02.209629 10.2.1.254 > 10.2.0.254: icmp: echo reply

19:39:20 root@tux:~# tcpdump -i ppp0 not port ssh
tcpdump: listening on ppp0
19:39:28.909533 203.52.103.254.1292 > 203.52.103.193.32775: udp 104
19:39:28.911273 203.52.103.193.32775 > 203.52.103.254.1292: udp 104
19:39:29.909506 203.52.103.254.1292 > 203.52.103.193.32775: udp 104
19:39:29.910858 203.52.103.193.32775 > 203.52.103.254.1292: udp 104

19:40:02 root@tux:~# tcpdump --version
tcpdump version 3.7.1
libpcap version 0.7

Thanks Roberto.  

Steve.

On 14 Aug 2002 at 11:11, Roberto Nibali wrote:

> 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 | >> ]