ath using hostap sets MTU to 2290 / channel '0' no longer works

[Sam Leffler]

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: <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 
> 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