This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

AP30 WiFi channel auto select not working properly

Dear all,

last week I had performance problems using WiFi so I ran a WiFi network scan using my Android phone and "WiFi Manager". The scan's result was that both wireless LANs were using the same most "crowded" channel.

I thought that must be because I never power cycle and the AP30 would not check for channel population once it was fired up - which I found awkward - but today I had the problem that my Android phone would not connect to the AP30 sitting on my desk, so I power cycled the AP30 with the live opened and I could not believe what I saw:

[FONT="Courier New"]2013:11:11-14:02:01 mail-1 awed[9497]: [AP30 A4000*********] disconnected. Close socket and kill process.
2013:11:11-14:02:56 mail-1 awed[8757]: [MASTER] new connection from 192.168.0.13:53728
2013:11:11-14:02:57 mail-1 awed[14343]: [AP30 A4000*********] AP30 from 192.168.0.13:53728 identified as A4000*********
2013:11:11-14:02:59 mail-1 awed[14343]: [AP30 A4000*********] (Re-)loaded identity and/or configuration
2013:01:01-00:00:42 192.168.0.13-1 kernel: [ 42.150000] cfg80211: Regulatory domain changed to country: DE
2013:01:01-00:00:42 192.168.0.13-1 kernel: [ 42.150000] cfg80211: (2400000 KHz - 2483000 KHz @ 40000 KHz), (N/A, 2000 mBm)
2013:01:01-00:00:42 192.168.0.13-1 kernel: [ 42.150000] cfg80211: (5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
2013:01:01-00:00:42 192.168.0.13-1 kernel: [ 42.150000] cfg80211: (5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
2013:01:01-00:00:42 192.168.0.13-1 kernel: [ 42.150000] cfg80211: (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2700 mBm)
2013:11:11-14:03:00 192.168.0.13-1 sysinit: Channel 2 busy time 22/227ms, 9%
2013:11:11-14:03:00 192.168.0.13-1 sysinit: Channel 3 busy time 3/227ms, 1%
2013:11:11-14:03:01 192.168.0.13-1 sysinit: Channel 4 busy time 19/227ms, 8%
2013:11:11-14:03:01 192.168.0.13-1 sysinit: Channel 5 busy time 56/227ms, 24%
2013:11:11-14:03:01 192.168.0.13-1 sysinit: Channel 6 busy time 119/228ms, 52%
2013:11:11-14:03:02 192.168.0.13-1 sysinit: Channel 7 busy time 21/227ms, 9%
2013:11:11-14:03:02 192.168.0.13-1 sysinit: Channel 8 busy time 10/227ms, 4%
2013:11:11-14:03:02 192.168.0.13-1 sysinit: Channel 9 busy time 16/227ms, 7%
2013:11:11-14:03:03 192.168.0.13-1 sysinit: Channel 10 busy time 34/227ms, 14%
2013:11:11-14:03:03 192.168.0.13-1 sysinit: Channel 11 busy time 51/227ms, 22%
2013:11:11-14:03:04 192.168.0.13-1 sysinit: Select channel 1[/FONT]

A4000********* is the AP30 in question 

Yes, there is no scanning result for channel 1, and btw. this channel is more crowded than channel 2, 8 or 9, but the AP30 still chooses this one.
I also tested this with a different AP30 at a different location - same issue: no channel 1 scanning result, but still choosing this channel 1.

While I was testing it got more confusing: just now my WiFi was gone and I could see in the logs that all 3 AP30 chose a new channel - 2 of them channel 1 (again without scanning results up front) and one of them channel 11 - which is one of the most crowded ones...?!?

Any explanation on this strange behavior? Isn't the system supposed to choose the least crowded channel and change channels when a less crowded channel has been detected?

Configuration on all three AP30 is "Channel 2.4 GHz:Auto", all three are running two wireless networks. UTMs are running firmware 9.106-17.

Thanks for your thoughts in advance!


This thread was automatically locked due to age.
  • That looks like a bug to me.  Please have your reseller submit a ticket to Support.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I also saw this output also on an AP10 (UTM 9.106-17). Seems really like a bug...
  • I wanted to open a ticket and they (Sophos) instantly closed it because it is supposed to be a know error (Mantis ID 26673 & 26791, not in the known error list from end of October), but to be honest, since I cannot take a look at these Mantis descriptions and they did not talk to me at all, I want them to at least send me their Mantis descriptions before I will look the other way - because telling me it may or may not be included in future updates is not the way to treat customers who pay lots of money for licenses.

    In my opinion not only the channel that will be chosen is incorrect, I have the problem that my Android phone will not be handed over to the nearest AP - after turing on WiFi it connects to the AP30 sitting on my desk (full bars) but after a while in standby mode it will be connected to a different AP and has only a single bar - and will not switch back even if the phone stays on for a while. Only turning WiFi off and on again lets the device connect to the nearest AP.
  • Our reseller just replied that not scanning Channel 1 is only a display bug. According to the reseller the channel is scanned, but it is not displayed in the log.
    Not sure if this is really the case...
  • Even if it is a display bug, the system chooses a crowded channel and would not hand over connections automatically, this is what worries me most.

    We really have problems with WiFi at the moment, people start to complain and asking if we have problems with our ISP or lack of bandwidth...
  • AFAIK the current 'auto select' method only selects a channel at AP bootup and sticks to that. It won't change automatically afterwards, only maybe after reboot of AP.

    That's something our Wi-Fi team has been working on and will be improved in a future release so APs will scan the air for congestion and switch channels during runtime.
  • Just got a call from Sophos support and they confirmed that the missing channel 1 scan is a display error and that the channel selection of the least "crowded" one will be fixed in UTM 9.2 - that was a really good talk and it cleared up all things the reply e-mail mixed up before :-)
  • Channel-autoselect during AP operation will not be in v9.2, sorry. That, together with PPPoE for RED has been postponed.
  • Hi Mario, I think people are talking about a couple of different issues here.

    One is that the auto-selection does not choose a less-crowded channel correctly (at start-up). Is that being addressed in 9.2?

    Thanks,
    Barry
  • Hi Mario, I think people are talking about a couple of different issues here.

    One is that the auto-selection does not choose a less-crowded channel correctly (at start-up). Is that being addressed in 9.2?

    Thanks,
    Barry


    Hi Barry. I've found nothing in the bugtracker regarding an auto-select bug. Only the new feature to scan and change channels during operation which has been postponed. So: no bug, no fix in v9.2.

    EDIT: Found it (#26673: WiFi: Results for Channel 1 while channel scannings on AP boot-ups are mostly always missing in the logfile). But this bug ID has no target version, so not sure if, but probably not fixed in v9.2.