Ath picking random channels

shadow

just me, no one else seeing this?

shadow

still happening, and it's kind of maddening. is there a log i should be looking at of the config file parsing? simply reloading the config with no changes fixes the issue.

stephenw10

That's a bit odd. What wifi hardware are you running? Could it be a firmware problem? What snapshot are you running?
My own ath adapter sticks stubbornly to channel 8. I'm running 13/05/2011 snapshot.

[2.0-RC2][root@pfsense.fire.box]/root(4): sysctl dev.ath.0.%desc
dev.ath.0.%desc: Atheros 2413

Steve

shadow

@stephenw10:

That's a bit odd. What wifi hardware are you running? Could it be a firmware problem? What snapshot are you running?
My own ath adapter sticks stubbornly to channel 8. I'm running 13/05/2011 snapshot.
[2.0-RC2][root@pfsense.fire.box]/root(4): sysctl dev.ath.0.%desc
dev.ath.0.%desc: Atheros 2413
Steve

dev.ath.0.%desc: Atheros 5212

this is 2.0-RC2 updated last week, however, it occurred with an april snapshot of some date before that as well.
the kernel is no longer custom as the axe patch has again been integrated.

stephenw10

Hmmm, OK.
Well I wonder what is causing it to change channel then? I certainly seems that an 'auto' setting somewhere is a likely culprit. What does it think it's set to at the CLI:

[2.0-RC2][root@pfsense.fire.box]/root(3): ifconfig ath0_wlan0
ath0_wlan0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
        ether 00:11:f5:ee:41:8b
        inet6 fe80::211:f5ff:feee:418b%ath0_wlan0 prefixlen 64 scopeid 0x11
        inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255
        nd6 options=3 <performnud,accept_rtadv>media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap>status: running
        ssid Area51net channel 6 (2437 MHz 11g) bssid 00:11:f5:ee:41:8b
        regdomain ETSI country GB ecm authmode WPA1+WPA2/802.11i
        privacy MIXED deftxkey 3 AES-CCM 2:128-bit AES-CCM 3:128-bit
        txpower 30 scanvalid 60 protmode OFF burst -apbridge dtimperiod 1 -dfs</hostap></performnud,accept_rtadv></up,broadcast,running,simplex,multicast>

Steve

shadow

@stephenw10:

Hmmm, OK.
Well I wonder what is causing it to change channel then? I certainly seems that an 'auto' setting somewhere is a likely culprit. What does it think it's set to at the CLI:

[2.0-RC2][root@pfsense.fire.box]/root(3): ifconfig ath0_wlan0
ath0_wlan0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
        ether 00:11:f5:ee:41:8b
        inet6 fe80::211:f5ff:feee:418b%ath0_wlan0 prefixlen 64 scopeid 0x11
        inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255
        nd6 options=3 <performnud,accept_rtadv>media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap>status: running
        ssid Area51net channel 6 (2437 MHz 11g) bssid 00:11:f5:ee:41:8b
        regdomain ETSI country GB ecm authmode WPA1+WPA2/802.11i
        privacy MIXED deftxkey 3 AES-CCM 2:128-bit AES-CCM 3:128-bit
        txpower 30 scanvalid 60 protmode OFF burst -apbridge dtimperiod 1 -dfs</hostap></performnud,accept_rtadv></up,broadcast,running,simplex,multicast>

Steve

on this boot it thought:
ssid "Bad Nook" channel 13 (2472 MHz 11g) bssid 00:0f:cb:af:eb:cf

i assume something is defaulting to auto, but that's not what the GUI shows, and it doesn't explain why just reloading the existing config with no changes fixes it.

stephenw10

Ah so if you backup and then restore your config.xml then it will stay on the correct channel?

What snapshot are you running? It sounds like maybe a file permission problem.
Could be worth reinstalling if you haven't tried that already and you haven't made any complex alterations.

Steve

shadow

thing is, it happened with the last snapshot i had, too, several months earlier, so i can't imagine upgrading to a newer snapshot will fix it. but it's not immediately obvious how to get the snapshot date from the cli, and at the moment i can't access the gui.

i could wipe and reinstall. but that's when this started; the previous (before the wipe) worked fine.

stephenw10

Hmm, OK I agree it's unlikely to help then. :-
For future reference:


[2.0-RC2][root@pfsense.fire.box]/root(1): uname -a
FreeBSD pfsense.fire.box 8.1-RELEASE-p3 FreeBSD 8.1-RELEASE-p3 #0: Fri May 13 23:16:51 EDT 2011     sullrich@FreeBSD_8.0_pfSense_2.0-snaps.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_wrap.8.i386  i386

Steve

shadow

mine was from may 16, by the uname method, which i ha considered but wasn't certain of the veracity of.

shadow

@stephenw10:

Ah so if you backup and then restore your config.xml then it will stay on the correct channel?

oh, i missed this. i don't even need to restore. i can just go to the gui, make no change, "apply" and reloading the config that's already there will fix it.

stephenw10

Yet at boot time, when it presumably reads and applies that same config, it's coming up on a random channel.
Are there any errors in the logs like it's failing to set the channel? Perhaps the wifi hardware is still initialising at that point and can't be set. :-\

Steve

shadow

well, i'd expect it to not have its SSID right either, in that case. but everything is right including the WEP key. just, and only, not the channel.

the log shows that ath0 is the first interface loaded on the system, before either ethernet is. it is probed 29 seconds before the log shows:
Jun 12 22:49:35 rtr check_reload_status: Reloading filter

stephenw10

This is now pure speculation….
The ath driver supports many hardware configurations. Some are better supported than others. The ath driver provides an interface to setup the hardware that offers all the options available however because of hardware support some options may not be fully functional. For example there is an option to alter the regulatory domain of the radio but (as of 2006!) the code was not there for the 5212.

Perhaps, since changing the channel is an actual hardware change, it is not able to set the channel correctly but does configure the ssid and security. You'd hope it would through up an error. You'd also expect other people to be having a problem. :-\

Steve

shadow

thing is, this ath hardware worked fine with every previous snapshot until i reinstalled in may. so unless upstream broke it, that seems unlikely.

cmb

@shadow:

thing is, this ath hardware worked fine with every previous snapshot until i reinstalled in may. so unless upstream broke it, that seems unlikely.

Nothing upstream has changed in ath since a year ago (RELENG_8_1 hasn't changed), and nothing in our wireless code has changed in months. But intermittent issues are the norm for some people with wireless for unknown reasons.

shadow

i don't suspect the wireless hardware; i suspect the config being written to it is wrong. i guess i need to modify the scripts to log what config is actually set to confirm that.