From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 16:11:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80CAD1065676 for ; Wed, 2 Apr 2008 16:11:18 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 54EA08FC29 for ; Wed, 2 Apr 2008 16:11:18 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 9BF51E47D7 for ; Wed, 2 Apr 2008 12:11:17 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 02 Apr 2008 12:11:17 -0400 X-Sasl-enc: UAJuE1+nbC+LknF3FAiuYekzOjK9nG60bg4uX5i2k8DC 1207152676 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id C47C214121 for ; Wed, 2 Apr 2008 12:11:16 -0400 (EDT) Message-ID: <47F3B023.60108@incunabulum.net> Date: Wed, 02 Apr 2008 17:11:15 +0100 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.9 (X11/20080207) MIME-Version: 1.0 To: FreeBSD-Net mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: fxp(4) multicast transmission bug. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2008 16:11:18 -0000 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 mtu 1500 driver flags look like this when injection is NOT OK: fxp0: flags=8843 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