fxp(4) multicast transmission bug.

[Pyun YongHyeon]

On Wed, Apr 02, 2008 at 05:11:15PM +0100, Bruce M Simpson wrote:
 > 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?
 > 

Because I'm not familiar with fxp(4) so I'm not sure but I guess
this is a bug in fxp(4). I think fxp(4) should also reprogram
multicast filtering in its fxp_init() as well as ioctl handler.
Otherwise you may have to join process in a group in order to send
multicast packets.

How about adding fxp_mc_setup() in fxp_init? I guess you may also
have to modify fxp_mc_setup() to set a flag that indicates "waiting
for a completion of multicast setup command". Or you may be able to
remove fxp_mc_setup() out of interrupt handler of fxp(4) and make
fxp_mc_setup() as a full-featured multicast filtering function, e.g.
not relying on an interrupt to catch the completion of multicast
setup command.

 > cheers
 > BMS

-- 
Regards,
Pyun YongHyeon