fxp(4) multicast transmission bug.

[Bruce M Simpson]

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