From owner-freebsd-net@FreeBSD.ORG Sun Oct 16 19:32:59 2011 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 BEF03106564A; Sun, 16 Oct 2011 19:32:59 +0000 (UTC) (envelope-from steven@pyro.eu.org) Received: from falkenstein-1.sn.de.cluster.ok24.net (maidenhead-1.wnm.uk.cluster.ok24.net [IPv6:2002:4e2f:2f89:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 49B6F8FC15; Sun, 16 Oct 2011 19:32:59 +0000 (UTC) Received: from maidenhead-1.wnm.uk.cluster.ok24.net ([10.1.0.1] helo=falkenstein-1.sn.de.cluster.ok24.net) by falkenstein-1.sn.de.cluster.ok24.net with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RFWS9-0008OA-Tg; Sun, 16 Oct 2011 20:32:57 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=pyro.eu.org; s=10.2011; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=OtJLp/gwCJHn9zQfKX4so5rXyxfWikFadztgazS608Y=; b=jjQfC/ZP0nXj60l3xEo28i6fUZ2tXxBGAH3Ytil4SeIdhAtM33TGG/2ak9QUT/nu7rSKBozklRk3AAbO4XvF1l06d0ru4eBESS1zWRX0SuSPJZRnhVj/A8f8ybU56CPIG8Zm7pMIjkemXCl6IUVZBiGX4LMA5qJTsTcc/kFM7gI=; Received: from 188-220-33-66.zone11.bethere.co.uk ([188.220.33.66] helo=guisborough-1.rcc.uk.cluster.ok24.net) by falkenstein-1.sn.de.cluster.ok24.net with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RFWS0-0008O7-Bm; Sun, 16 Oct 2011 20:32:48 +0100 X-Spam-Status: No, score=-4.4 required=2.0 tests=ALL_TRUSTED, AWL, BAYES_00, DKIM_POLICY_SIGNALL Received: from [192.168.0.110] (helo=[192.168.0.9]) by guisborough-1.rcc.uk.cluster.ok24.net with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RFWRv-0001Ua-2b; Sun, 16 Oct 2011 20:32:47 +0100 Message-ID: <4E9B315A.6030607@pyro.eu.org> Date: Sun, 16 Oct 2011 20:32:42 +0100 From: Steven Chamberlain User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20111006 Icedove/3.0.11 MIME-Version: 1.0 To: Adrian Chadd References: <201110152200.p9FM0QUO044812@freefall.freebsd.org> <4E9A5FB6.7040904@pyro.eu.org> <4E9B062A.9050408@pyro.eu.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode 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: Sun, 16 Oct 2011 19:32:59 -0000 On 16/10/11 17:46, Adrian Chadd wrote: > I don't think it's the mbuf. It looks like the mbuf allocation is fine. > The linux code in compat-wireless... Hi Adrian! Thanks for your suggestions. Happily I've got it working, and it wasn't nearly that complicated. I'm only using i386 architecture. I looked further into the magic 88-byte threshold after which the bug occurs. It turns out that figure included the 24-byte tx_desc, and up to 64 bytes of beacon frame (header+data). rum_write_multi doesn't seem happy with writing >64 bytes at a time to the MAC register. If I break it up into separate calls (e.g. bytes 0-63, then bytes 64-65, written at the appropriate offset) I see the proper beacon frames being transmitted now. It's working for any length of ESSID from 0-32 bytes so padding, alignment or guard bytes don't appear to be necessary for the beacon frame. (For tx_data, though, there is code to handle that). I'll neaten this up, produce a patch and test some more. Thanks, Regards, -- Steven Chamberlain steven@pyro.eu.org