From owner-freebsd-net@FreeBSD.ORG Wed Jul 30 16:14:31 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 D6FA81065671 for ; Wed, 30 Jul 2008 16:14:31 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 96A828FC18 for ; Wed, 30 Jul 2008 16:14:31 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m6UGEQPd099060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 09:14:26 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <48909361.2070406@freebsd.org> Date: Wed, 30 Jul 2008 09:14:25 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Chris Buechler References: <20080729114237.45525xviqzjqf9nh@www.publicmx.com> <488F8060.70600@freebsd.org> <488FE0B3.4070400@chrisbuechler.com> In-Reply-To: <488FE0B3.4070400@chrisbuechler.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Rhyolite-Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org Subject: Re: ath using hostap sets MTU to 2290 / channel '0' no longer works 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, 30 Jul 2008 16:14:31 -0000 Chris Buechler wrote: > Sam Leffler wrote: >> John T. Yocum wrote: >>> Hello, >>> >>> I have a system running pfSense, which is built on top of FreeBSD >>> 7.0-RELEASE-p3. In the system I have an Atheros wireless card, which >>> when I enable hostap, changes it's MTU to 2290. If an explanation is >>> listed on a man page, I apologize, I did try searching. >>> >>> Any ideas why this might happen? It doesn't appear to be a pfSense >>> issue, as it appears their code actually tries to set the MTU to 1500. >>> >>> Only reason I ask here, is I noticed in my searching on Google, I >>> noticed others that aren't running pfSense have their MTU set to 2290. >> MTU on an 802.11 network is 2290. If you don't want the default then >> change it. If you cannot then please provide the exact steps you >> take that do not work. > > Thanks for the reply, Sam! > I have an ath card I'm working with that sets its MTU to 1500 in > hostap, so there seems to be inconsistent behavior here. This card, > specifically: > http://www.netgate.com/product_info.php?products_id=130 No ath card sets an mtu; this is done in s/w in the host. > > We added a forced MTU of 1500 to wireless cards in pfSense (as a stop > gap testing measure since they're frequently bridged to Ethernet and > the bridge won't work unless the wireless card is 1500), but it still > appears to revert to 2290 for people. I cannot help w/ an issue unless I can reproduce it. The above does not help me. As I said previously when a card is attached to the system (e.g. on boot or card insert) the default mtu setup is 2290. If it changes at a later then some program is doing it. This is on RELENG_7 and later. > > I haven't had time to fully quantify this, and I can't replicate it > with the hardware I have at hand as it uses 1500 without specifying > any MTU. If I can come up with better info and steps to replicate, > I'll post back. > > While I have your attention, we have found one change in behavior > between 6.x and 7.0. I'm not sure if it's a regression or intentional, > any insight would be appreciated. "ifconfig ath0 channel '0'" used to > work in 6.x with hostap mode. Now users are finding their AP does not > show up unless they manually specify a channel. Running that command > shows: > > # ifconfig ath0 channel '0' > ifconfig: unknown/undefined channel number 0 flags 0x0 > > At boot time when the above is set, I get (dmesg|grep ath0): > Jul 27 18:24:44 pfSense kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, > AR5212, RF5111, RF5112, RF2413, RF5413) > Jul 27 18:24:44 pfSense kernel: ath0: mem > 0x88010000-0x8801ffff irq 10 at device 0.0 on cardbus1 > Jul 27 18:24:44 pfSense kernel: ath0: [ITHREAD] > Jul 27 18:24:44 pfSense kernel: ath0: using obsoleted if_watchdog > interface > Jul 27 18:24:44 pfSense kernel: ath0: Ethernet address: 00:0b:6b:20:3a:4d > Jul 27 18:24:44 pfSense kernel: ath0: mac 5.9 phy 4.3 radio 3.6 > Jul 27 18:24:47 pfSense kernel: ath0: ath_chan_set: unable to reset > channel 6 (2437 Mhz, flags 0x490 hal flags 0x150) > Jul 27 18:24:47 pfSense kernel: ath0: unable to reset hardware; hal > status 0 > > The above was also seen by a pfSense user with a different ath card, > miniPCI I believe. Numerous people have reported that "auto" channel > (what our GUI translates to channel 0 in ifconfig) no longer works > with ath cards on 7.0-based versions when they were working fine > previously on 6.2 and 6.3-based versions. Use ifconfig ath0 channel - (or any) to clear any locked channel. This is in fact a change; never noticed before. I can either change the man page or try to hack ifconfig but I'd prefer to just deprecate the use of "0". > > The ifconfig man page mentions using channel - or any should do the > same as 0. Both of those do not produce any error messages (they > return no output), but the AP still isn't visible. I haven't confirmed > this part, but I believe running ifconfig ath0 down / ifconfig ath0 up > after running either channel - or channel 'any' will make it work. Not > sure on behavior at boot time. When you clear the locked down channel the device should scan. You can observe this by monitoring state w/ ifconfig or enable debug msgs with wlandebug scan+state. > > I tested an old wi(4) card with channel '0' and it still works the > same as in 6.x. 6.x and 7.x are very different systems and wi is not a good indicator of changes in the system. > > I was waiting to post until I had time to gather more definitive > information but since someone else brought it up, thought I'd add to > it. If I can help gather any additional information please let me know. I'll fix the man page at least right now; thanks. Sam