From owner-freebsd-net@FreeBSD.ORG Thu Apr 3 01:11:28 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 0FFA11065670 for ; Thu, 3 Apr 2008 01:11:28 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.244]) by mx1.freebsd.org (Postfix) with ESMTP id AFE738FC18 for ; Thu, 3 Apr 2008 01:11:27 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by hs-out-0708.google.com with SMTP id m63so2472151hsc.11 for ; Wed, 02 Apr 2008 18:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=dMhGxRn+0smTf0/s+0UUaS6wNSZkr8TjHTZQd9E4KsI=; b=kDofoyEQwHKZ6GwBVQrwSqFrKLZEDqiyGqri/MCbWpnDyblkmVB7HMMLh4j0JlBgRBau/k5A+Aw6ZBkSR1DTPU5iioIaw6hvg9p4UQ+AgU2GPzJkiNoNtAda0Y0IhjST712w66vOLMF98AsSF+Cth9SgVCXyIYTgpo+oM6xk5Y0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=F8J3tvdDgLM50kngsKYrjk37RpfkLC3Yve8dqAtM+lWQF04nfJaMvELdiGBSWFflXkIG/pD9/B8bv99K4jUs02pSx6kwFt6DfLc2iCXtUo4UmdY2gYatPPuJyzx0Q0tqqO2U09l02sZqYYSOdSy91Rh9NK+caVQSLMI8xM7nmHQ= Received: by 10.100.241.17 with SMTP id o17mr24273787anh.30.1207185086554; Wed, 02 Apr 2008 18:11:26 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id a42sm4604324rne.15.2008.04.02.18.11.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Apr 2008 18:11:25 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m331BKj6023077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2008 10:11:20 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m331BIXN023076; Thu, 3 Apr 2008 10:11:18 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 3 Apr 2008 10:11:18 +0900 From: Pyun YongHyeon To: Bruce M Simpson Message-ID: <20080403011118.GC22730@cdnetworks.co.kr> References: <47F3B023.60108@incunabulum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47F3B023.60108@incunabulum.net> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD-Net mailing list Subject: Re: fxp(4) multicast transmission bug. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2008 01:11:28 -0000 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 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? > 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