Date: Thu, 3 Apr 2008 10:11:18 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Bruce M Simpson <bms@incunabulum.net> Cc: FreeBSD-Net mailing list <freebsd-net@freebsd.org> Subject: Re: fxp(4) multicast transmission bug. Message-ID: <20080403011118.GC22730@cdnetworks.co.kr> In-Reply-To: <47F3B023.60108@incunabulum.net> References: <47F3B023.60108@incunabulum.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080403011118.GC22730>