Date: Wed, 02 Apr 2008 17:11:15 +0100 From: Bruce M Simpson <bms@incunabulum.net> To: FreeBSD-Net mailing list <freebsd-net@freebsd.org> Subject: fxp(4) multicast transmission bug. Message-ID: <47F3B023.60108@incunabulum.net>
next in thread | raw e-mail | index | archive | help
Hi,
I am doing some protocol testing, and I just saw something very odd on
6.3-RELEASE.
If I try to inject multicast traffic via bpf with fxp, bpf will report
that it went out OK, however it never makes it out onto the wire. I have
ruled out firewalls, switches and other layer 2 behaviour.
sysctls look like this:
dev.fxp.0.int_delay: 1000
dev.fxp.0.bundle_max: 6
dev.fxp.0.rnr: 0
dev.fxp.0.noflow: 1
driver flags look like this when injection is OK:
fxp0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu
1500
driver flags look like this when injection is NOT OK:
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
... however, if for any reason the group I'm sending to has been joined
by another process or kernel entity, sending is OK.
My understanding of multicast hash filters was that they worked in only
one direction -- receive, not send.
However, I see from reading the driver that the fxp chip has certain
restrictions on how the hash filter is programmed -- the command to do
so must come before any other descriptors are queued.
That's all well and good, but sending should "just work". Further
reading of the driver suggests that it does nothing special about
multicast transmission, so that would seem to point the finger at the
driver firmware or the ASIC itself.
If fxp is behaving differently to 99% of hardware out there, surely this
needs to be marked in capabilities -- I shouldn't strictly need to
program the hash filter to send the traffic, only receive. Whilst it's
something an application is *likely* to do, it doesn't have to do so by
spec, therefore this behaviour is a bug.
Or is there something I'm missing completely here?
Comments? feedback? suggestions?
cheers
BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47F3B023.60108>