ath using hostap sets MTU to 2290 / channel '0' no longer works
sam at freebsd.org
Wed Jul 30 16:14:31 UTC 2008
Chris Buechler wrote:
> Sam Leffler wrote:
>> John T. Yocum wrote:
>>> 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,
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
> 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
> # 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: <Atheros 5212> 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
> 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
> 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
> 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.
More information about the freebsd-net