Patrick McHardy writes:
> One reason to leave it where it is is that sfq can drop packets others
> than the one currently handled if the queue becomes full. You don't want
> packets beeing dropped because of another one you're going to drop in
> POSTROUTING anyway. Other qdiscs limit bandwid
One reason to leave it where it is is that sfq can drop packets others
than the one currently handled if the queue becomes full. You don't want
packets beeing dropped because of another one you're going to drop in
POSTROUTING anyway. Other qdiscs limit bandwidth, they couldn't make any
calculati
Harald Welte writes:
> On Fri, Apr 26, 2002 at 09:52:46AM -0700, Don Cohen wrote:
> > Harald Welte writes:
> So you want to have a big case statement _after_ enqueuing of the packet
> happens [ i.e. in the network TX softirq], calling NF_HOOK for the
> respective protocol family?
Actually,
On Fri, Apr 26, 2002 at 09:52:46AM -0700, Don Cohen wrote:
> Harald Welte writes:
>
> > the counter argument is that the queue is part of the lower-layer drivers
> > and not part of the IPv4 stack. netfilter hooks are always restricted
> > to one protocol stack - there's separate hooks for i
Harald Welte writes:
> the counter argument is that the queue is part of the lower-layer drivers
> and not part of the IPv4 stack. netfilter hooks are always restricted
> to one protocol stack - there's separate hooks for ipv4, ipv6, ipx, ...
This seems more a psychological than technical a
On Thu, Apr 25, 2002 at 10:41:52AM -0700, Don Cohen wrote:
>
> My impression (please correct me if I'm wrong) is that pre is supposed
> to catch packets coming into the box and post is supposed to catch
> those going out.
>
> I believe postrouting currently happens before a packet is queued for
