Date: Thu, 30 Jan 1997 12:58:10 +1100 (EDT) From: Darren Reed <avalon@coombs.anu.edu.au> To: archie@whistle.com (Archie Cobbs) Cc: avalon@coombs.anu.edu.au, 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: <199701300200.SAA10010@freefall.freebsd.org> In-Reply-To: <199701292246.OAA24842@bubba.whistle.com> from "Archie Cobbs" at Jan 29, 97 02:46:19 pm
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Archie Cobbs, sie said: > > > > > 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. Not what I meant...the ethernet drivers queue up packets using IF_ENQUEUE() (right ?) and ip_input() picks them off using IF_DEQUEUE()...or is there an external loop calling ip_input() now that does the IF_DEQUEUE() ? Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701300200.SAA10010>