[2054] in linux-net channel archive
No subject found in mail header
daemon@ATHENA.MIT.EDU (John Paul Morrison)
Tue Mar 12 18:17:03 1996
Date: Mon, 11 Mar 96 01:34 PST
From: jmorriso@bogomips.com (John Paul Morrison)
To: submit-linux-dev-net@ratatosk.yggdrasil.com
Newsgroups: linux.dev.net
Path: jmorriso
From: jmorriso@bogomips.com (John Paul Morrison)
Subject: Re: (new_)tunnel in 1.3.71
Organization: BogoMIPS Research Labs
Message-ID: <1996Mar11.093414.2353@bogomips.com>
References: <4hhnl1$79e@nz12.rz.uni-karlsruhe.de> <m0tuFZ7-0009erC@iifeak.swan.ac.uk>
Date: Mon, 11 Mar 1996 09:34:14 GMT
In article <m0tuFZ7-0009erC@iifeak.swan.ac.uk>,
Alan Cox <iialan@iifeak.swan.ac.uk> wrote:
>> Why was (old-) tunnel.c removed?
>>
>> New_tunnel.c has some severe problems, using it locks the machine
>> completely after some frames.
>
>Ok.. Well if someone had bothered to moan _BEFORE_ I removed the old one
>I might have known people were having trouble with it. Since I got exactly
>zero complaints I assumed it had approximately zero bugs.
I tried (new_)tunnel.c in 1.3.72, and the good news is it doesnt lock
the machine The bad news is that it doesnt send any TCP datagrams
either :-)
It's a weird problem, because pings get transmitted, and I see the
replies. But if I try making a TCP connection through a tunnel, it
*looks* like things are transmitted, but no packets leave the machine
(or very few).
I have ppp0 and tunl0 set to the same IP address, with a default route
through ppp0, and some routes through tunl0 (44.x.y.z gw a.b.c.d dev
tunl0)
tcpdump shows IPIP encapsulated pings leaving through ppp0, and then
the un-encapsulated replies coming back in. So this part works.
but tcpdump shows an encapsulated TCP SYN leaving ppp0, when I try to
telnet. No replies. netstat -i shows the count for tunl0 incremented
by 1, but not for ppp0. tcpdump running on another machine doesn't see
the SYN. The weird thing is it only sends one SYN, and doesnt retry.
Another werid thing is that very rarely, encapsulated TCP datagrams
*do* get transmitted, but I can't correlate it with anything - some
small percentage make it out.
I remember some weird problems with the old tunnel.c - maybe something
got left out when new_tunnel.c was written. (strange that the tunnel
driver, which is really very simple, has so many problems)
There are some minor problems with tunnel.c:
- it copies the TTL from the original datagram. It should put a new
one in.
- it clobbers the DF bit. It should copy it so path MTU works.
>
>Alan
>
--
---------------------------------------------------------------------------
BogoMIPS Research Labs -- bogosity research & simulation -- VE7JPM --
jmorriso@bogomips.com ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org
---------------------------------------------------------------------------
