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

Subject: Re: client doesn't recover after server restart
From: Keith Smith <keith,AT,ksmith,DOT,com>
Date: Thu, 14 Feb 2002 04:53:09 +0100
In-reply-to: <20020212102355.70522.qmail@web21309.mail.yahoo.com>

fn ln wrote:
>  Thanks Keith ! 
>  Got your patch, I'll give it a shot ...
>  If I understand things correctly, this is a flaw in
> the program :) Now the question is whether it flaw is
> on the protocol design or on the protocol
> implementation level.

I wouldn't neccesarily call it a flaw.  The program is pretty complete 
and works well.  I would call the program a tad optomistic :) :).  I 
just happen to KNOW that the base connection is going to sh*t, because 
I've seen it too darn many times, particularly on slow links.

> fixed to avoid this bug, would it inevitably break

I wouldn't call it a bug either.  It's just the design.  IMHO tunneling 
really isn't implemented peer to peer, which is the model here.  It's 
really client->host.  Somebody has to be in control, and know when to 
give up, break it off, or whatever.  The other guy should just be listening.

I discussed earlier the "feature" that even if the tunnel isn't talking 
the INTERFACE stay's up.  This is counter to all of the PPP style 
implementations, where when communication is lost the PPP interface goes 
down.  The latter gives me a bit easier control over routing and the 
like, ie when the interface is down, route the vpn traffic elsewhere, 
instead of running a ping loop or something.

More than that if the VPN connection is severed your network traffic 
"hangs" over the tunnel and you get to wait interminable time while 
things "time out" on the TCP stack, locking programs in core.  At least 
with linux things will eventually time out.

If the interface is down the program gets a hard error (No route to 
host) and generally just gives up pretty easily, since the packet 
doesn't get queued, it gets rejected.

I personally don't think this is a "Good Thing", on the otherhand the 
author may have his reasons for implementing it that way.  Since I was 
never brave enough to write this myself, we have to either work with his 
code, or hack it to fit our own needs.  That's what's so great about 
open source, If I don't like something Olaf has done I am free to "fix" 
it as I see fit within the guidlines of the GPL.  He can adopt it, roll 
it in or ignore it as he sees fit.

Maybe Olaf will weigh in on some of these issues, he probably has 
reasons for some of the implementation.  One could argue that cipcb0 is 
like an ethernet interface... If it's unplugged it's still up, and that 
has the advantage of <blah>.  Again, I see it more like a PPP interface 
(ie point to point) since there is no "broadcasting" going on on the 
link, and multiple machines are not sharing it.  Bully for me :).
(perhaps I should avoid the coloquialisms with this int'l crowd).


Keith Smith                 keith,AT,ksmith,DOT,com
655 W Fremont Dr
Tempe AZ 85282              it's hot

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