I'm working on a usb device driver I've derived from existing drivers in
sys/dev/usb (4.10-RELEASE).
I can successfully load and unload the module, but the usb subsystem does
not appear to see the driver. However if I compile my driver in the
kernel, the usb sub system uses the driver correctly.
Luigi,
I see that bridge callbacks are still living in if_ed.c
from FreeBSD 2.x times. See if_ed.c:2816. I think this is
not correct.
Bridge code is called from ether_input(), which is
indirectly called from if_ed.c:2836.
Any objections about attached patch?
[ccing hackers@ and net@ to get
On Mon, Sep 06, 2004 at 12:52:49AM +0400, Gleb Smirnoff wrote:
Luigi,
I see that bridge callbacks are still living in if_ed.c
from FreeBSD 2.x times. See if_ed.c:2816. I think this is
not correct.
Bridge code is called from ether_input(), which is
indirectly called from if_ed.c:2836.
Well, wait a second... are we talking about a lot of packets being
discarded by the filter in 'normal' operation, or are we talking about
an attack? Because if we are takling about an attack the LAST ethernet
device anyone would ever want to use would be ED. i.e. they would be
On Sun, Sep 05, 2004 at 02:20:36PM -0700, Luigi Rizzo wrote:
L I see that bridge callbacks are still living in if_ed.c
L from FreeBSD 2.x times. See if_ed.c:2816. I think this is
L not correct.
L
L Bridge code is called from ether_input(), which is
L indirectly called from if_ed.c:2836.
L
Gleb Smirnoff wrote:
On Sun, Sep 05, 2004 at 02:20:36PM -0700, Luigi Rizzo wrote:
L I see that bridge callbacks are still living in if_ed.c
L from FreeBSD 2.x times. See if_ed.c:2816. I think this is
L not correct.
L
L Bridge code is called from ether_input(), which is
L indirectly
On Sun, Sep 05, 2004 at 02:20:36PM -0700, Luigi Rizzo wrote:
L there are performance reasons to do this way -- grabbing
L the entire packet is expensive because it is done via programmed
L I/O, so the current code only grabs the header, does the
L filtering, and grabs the rest of the packet only
Sam Leffler wrote:
No. What will move to pfil_hooks is the firewalling within the bridge
code and the layer2 ethernet firewalling. The bridging code as such
will stay where it is.
Well, that's what _you_ want to do :). What I started on last year was a
complete purge of
On Mon, Sep 06, 2004 at 03:01:00AM +0400, Gleb Smirnoff wrote:
...
L I'd rather not apply the patch unless you can show that
L the current code leads to incorrect behaviour.
I suspect that packets dropped by bridge_in() called from if_ed will
not be captured by bpf(4). This is incorrect.
if
9 matches
Mail list logo
