Skip site navigation (1)Skip section navigation (2)
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>