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