Date: Wed, 29 Jan 1997 14:46:19 -0800 (PST) From: Archie Cobbs <archie@whistle.com> To: avalon@coombs.anu.edu.au (Darren Reed) Cc: archie@whistle.com, terry@lambert.org, ari.suutari@ps.carel.fi, brian@awfulhak.demon.co.uk, hackers@freebsd.org, cmott@srv.net Subject: Re: ipdivert & masqd Message-ID: <199701292246.OAA24842@bubba.whistle.com> In-Reply-To: <199701292130.NAA19395@gatekeeper> from Darren Reed at "Jan 30, 97 08:29:09 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> > The theory was that this loop avoidance was working too well, and > > seemed to be applying to packets other than the one that it was > > supposed to. What I'm trying to prove to myself is that this can't > > be happening. > > Does ip_divert_flag get set/reset inside or outside the loop in > ip_input() which dequeues packets ? (src isn't handy) Ah.. well, it doesn't get reset until ip_input() returns. Perhaps this is the problem... certainly if calling ip_input() with one packet can trigger the ipfw processing of other packets, that would be bad. [ checking source .. ] >From my reading it doesn't seem like this can happen. Packet fragments are queued up and then merged when the last packet arrives, but sending ip_input() a whole separate packet shouldn't trigger this. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701292246.OAA24842>