[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Routing bug ?
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Re: Routing bug ?
- From: Claudio Jeker <cjeker_(_at_)_diehard_(_dot_)_n-r-g_(_dot_)_com>
- Date: Sat, 8 May 2004 14:04:47 +0159
- Mail-followup-to: Claudio Jeker <cjeker_(_at_)_diehard_(_dot_)_n-r-g_(_dot_)_com>, misc_(_at_)_openbsd_(_dot_)_org
On Fri, May 07, 2004 at 11:23:19PM -0400, Mike Tancsa wrote:
> At 06:15 PM 07/05/2004, Theo de Raadt wrote:
> >> Now FreeBSD 4.* acts equaly exeption is the PRCLONING which is a FreeBSD
> >> extension while in FreeBSD 5.2 and upwards the cached route in the pcb
> >> where removed and so every outgoing packet does a new route lookup and
> >> therefor sees the readded route.
> >Read this as "performance hit".
> Thanks for the feedback. For us, the behavior breaks raccoon in an
> environment where links come and go. i.e. l2tp/pptp links that come and go
> due to a very lossy path. (we need to use l2tp/pptp initially to make the
> connection for a number of reasons).
> Is OpenBSD able to handle such a setup ? e.g. lossy link that connects via
> mpd initially via an netgraph interface. The Key exchange daemon does its
> think via the ng interface on port 500. The link goes down due to a number
> of reasons beyond our control. the Key exchange daemon tries to go out the
> default route/discard interface or is just blocked via appropriate
> ACL. Regardless, it tries to go out a different interface. The link comes
> back up. the key exchange daemon is still sending out the default
> interface... problems ensue.
> One of the FreeBSD folks had the following to say on their design decisions
As said in the mail from Andre. Don't bind(2)/connect(2) to a udp port but
instead use sendto(2)/recvfrom(2) all the time. Or just close(2) and
reopen -- socket(2) -- the connection from time to time.
If raccoon is broken you should probably fix it there. There is now way
the kernel will change his behaviour.