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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
