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

Subject: RE: cipe-1.5.4, kernel 2.4.19, kernel messages
From: Michael Da Cova <mdacova,AT,equiinet,DOT,com>
Date: Tue, 13 Aug 2002 15:23:21 +0200

HI Guys

Iv been testing CIPE Windows NDIS driver and service, version 2.0-pre14. and
have found it works very nicely on windows 2000/XP a small issue has come up
in that I cant find any information on how to use the pre and post scripts,
what I would like to do is provide a way to feed in a static route onto the
client for the network that the device is trying contact, also sometimes
when you deactivate the application from control panel the shared secret
disappears

Michael

Michael Da Cova
Technical Support Manager
Equiinet Ltd,
Edison House, Edison Road,
Swindon, SN3 5JX, United Kingdom
Tel +44 1793 603729  Fax +44 1793 603701
Email : mdacova,AT,equiinet,DOT,com

Privileged/Confidential Information may be contained in this message.  If
you are not the addressee indicated in this message 
(or responsible for delivery of the message to such person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply email.
Please advise immediately if you or your employer
do not consent to Internet email for messages of this kind. Opinions,
conclusions and other information in this message that do not
relate to the official business of my firm shall be understood as neither
given nor endorsed by it.

-----Original Message-----
From: Steve Ripps [mailto:stever,AT,sttc,DOT,net,DOT,au 
Sent: 13 August 2002 13:30
To: cipe-l,AT,inka,DOT,de
Subject: Re: cipe-1.5.4, kernel 2.4.19, kernel messages

Hi Roberto.
I've tried a few of your suggestions.  See below.  I'll try the others a bit
later when 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 :)

On 13 Aug 2002 at 12:16, Roberto Nibali wrote:

> 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

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

> 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
22:05:46 root@tux:~# ip -s -s link show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    RX: bytes  packets  errors  dropped overrun mcast
    596999     3027     0       0       0       0
    RX errors: length  crc     frame   fifo    missed
               0        0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    596999     3027     0       0       0       0
    TX errors: aborted fifo    window  heartbeat
               0        0       0       0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:50:bf:13:bb:99 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    2267906806 1569287  0       0       0       0
    RX errors: length  crc     frame   fifo    missed
               0        0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    49188161   611400   58      0       58      0
    TX errors: aborted fifo    window  heartbeat
               0        0       0       0
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:60:67:49:61:6d brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    0          0        0       0       0       0
    RX errors: length  crc     frame   fifo    missed
               0        0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    0          0        0       0       0       0
    TX errors: aborted fifo    window  heartbeat
               0        0       0       0
4: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1490 qdisc pfifo_fast qlen 3
    link/ppp
    RX: bytes  packets  errors  dropped overrun mcast
    6673860    26848    1       0       0       0
    RX errors: length  crc     frame   fifo    missed
               0        0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    2146319    27111    0       0       0       0
    TX errors: aborted fifo    window  heartbeat
               0        0       0       0
5: cipcb0: <POINTOPOINT,NOARP,UP> mtu 1442 qdisc pfifo_fast qlen 100
    link/ipip 00:00:5e:b2:00:99 peer 00:00:00:00:00:00
    RX: bytes  packets  errors  dropped overrun mcast
    2632       25       0       0       0       0
    RX errors: length  crc     frame   fifo    missed
               0        0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    4212       35       0       0       0       0
    TX errors: aborted fifo    window  heartbeat
               0        0       0       0
22:09:27 root@tux:~#

> ip rule show
22:09:27 root@tux:~#  ip rule show
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup 253
22:10:53 root@tux:~#

> ip route show
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:~#

> ip -s -s route show cache [this one is very important]
22:11:28 root@tux:~# ip -s -s route show cache
local 127.0.0.1 dev lo  src 127.0.0.1
    cache <local>  users 1 used 20 age 30sec mtu 16436
local 127.0.0.1 from 127.0.0.1 dev lo
    cache <local>  users 5 used 45 age 30sec mtu 16436
local 10.0.0.254 from 10.0.0.198 dev lo  src 10.0.0.254
    cache <local,src-direct>  users 1 used 1670 iif eth0 10.0.0.198 from
10.0.0.254 tos 0x10 dev eth0
    cache  users 3 used 1 age 1643sec mtu 1500
local 203.52.103.193 from 203.52.78.145 dev lo  src 203.52.103.193
    cache <local>  users 1 used 19 age 309sec iif ppp0 10.0.0.198 from
10.0.0.254 dev eth0
    cache  users 1 used 57 age 30sec mtu 1500 rtt 10ms rttvar 10ms cwnd 2
local 203.52.103.193 from 12.253.51.28 dev lo  src 203.52.103.193
    cache <local>  users 1 used 9 age 427sec iif ppp0 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
local 203.52.103.193 from 203.52.103.254 dev lo  src 203.52.103.193
    cache <local,src-direct>  users 1 used 5 age 404sec iif ppp0
203.52.78.145 via 203.52.103.254 dev ppp0  src 203.52.103.193
    cache  users 1 used 4 age 313sec mtu 1490
22:12:27 root@tux:~#

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

Chain out_filt (2 references)
 pkts bytes target     prot opt in     out     source
destination         

Nope.  That did't fix it.

(Win XP 10.0.0.198)
C:\Documents and Settings\steve.WORKGROUP>ping -n 2 10.2.0.254

Pinging 10.2.0.254 with 32 bytes of data:

Reply from 10.2.0.254: bytes=32 time=191ms TTL=254
Reply from 10.2.0.254: bytes=32 time=189ms TTL=254

Ping statistics for 10.2.0.254:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss), Approximate round
trip times in milli-seconds:
    Minimum = 189ms, Maximum = 191ms, Average = 190ms

C:\Documents and Settings\steve.WORKGROUP>

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

--
Message sent by the cipe-l,AT,inka,DOT,de mailing list.
Unsubscribe: mail majordomo,AT,inka,DOT,de, "unsubscribe cipe-l" in body Other
commands available with "help" in body to the same address. CIPE info and
list archive: <URL:http://sites.inka.de/~bigred/devel/cipe.html>





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