Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 40 replies
  • Subscribers 1 subscriber
  • Views 22159 views
  • Users 0 members are here
Options
Suggested
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's disconnecting all wireless clients

RedTechie
I've been having issues with my Astaro AP30's disconnecting all the wireless clients on the network. It seemed to start happening around v8.203 and I have never had this issue before (been using the AP30's since they were released). 

I currently have 3 SSID's (all using WPA2 Personal). Two are Bridge to LAN (Client isolation off). The third is a guest network that is isolated on a separate VLAN. When this issue happens it cripples all three.

So I did some searching on the forums and found some problems that were kind of similar but with no solutions yet. I opened a ticket with Astaro and they told me they couldn't help because I was a home license (even though I bought roughly $500 worth of hardware from them).

I have tried using the up2date package that upgrades the Astaro to v8.300 but since I have done that it has gotten way worse.

It looks as if the clients are getting disconnected because of some WPA issues? All the clients can see the wireless network but can't connect. For example if I try and reconnect on my iPhone it keeps asking for the password and it never accepts it. Also due to this wireless clients can't get a DHCP IP. There also seems to be no exact time this happens, but I have been seeing it happen roughly once or twice every 12 or so hours.

I have pinged both AP30's during the issue with no timeouts and all pings are under 1ms.

I have turned on awed debugging via the following method:
/var/mdw/scripts/awed stop
awed.plx --debug


See the log attached for a small portion of the log (it's 65MB as it happened last in the middle of the night). The beginning of this log file is when the problem started. It continues on until 10am in the morning (when I fixed it).

The only thing that seems to fix it (temporarily) is either a reboot (power cycle) of the AP's or a stop/start of awed.

This whole issue is annoying as I spent good money for these AP30's thinking they were reliable and right now they are worthless.

Has anyone else been experiencing these issues? Are there any fixes currently for this or is there an ETA for a fix?

Any help or information would be much appreciated! Thanks!


This thread was automatically locked due to age.
wireless_log_debug_on.zip
Parents
  • 0
    After upgrading, one of my customers had to power cycle his AP nine times before it finally straightened itself out.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    After upgrading, one of my customers had to power cycle his AP nine times before it finally straightened itself out.

    Cheers - Bob


    I have power cycled the AP30's probably around 5 or 6 times over this last week and have cycled awed at least 30 times (taking into account my cron cmd also)


    Speaking of which, I just cycled awed a few minutes ago and the wireless already died. Sometimes it lasts for hours other times it goes down a few minutes after cycling awed. :Sigh:

    I'll try cycling the AP30's power a few more times. Thanks
  • 0 in reply to RedTechie
    Hi RedTechie,
    your fault description sounds a like a problem a number of us had during the v8.2b. That was fixed though. When the fix was applied as part of the beta, the recommendation from memory was to leave the APs powered off for about a minute after the ASG was upgraded. Then to reconnect them.

    How many AP30s do you have?

    Sorry, I have runout of ideas to test.

    Ian

    XG115W - v20.0.2 MR-2 - Home

    XG on VM 8 - v21 GA

    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to rfcat_vk
    Hi RedTechie,
    your fault description sounds a like a problem a number of us had during the v8.2b. That was fixed though. When the fix was applied as part of the beta, the recommendation from memory was to leave the APs powered off for about a minute after the ASG was upgraded. Then to reconnect them.

    How many AP30s do you have?

    Sorry, I have runout of ideas to test.

    Ian


    Ok, I gave your suggestion a shot. 

    Procedure: 
    1. I turned off my cron schedule
    2. Unplugged the power from both AP's POE inserters
    3. Re-cycled awed
    4. After 5 minutes plugged the power back in to both AP's (one at a time, while monitoring the wireless live log).

    Interesting thing I noticed, while watching the live log. The first AP30 I plugged in gave a bunch of kernel/sysint type log entries, when the second AP30 I plugged in didn't. The second AP30 just showed that ASG found a new connection for the second AP's IP.

    Here is the log from the first AP30 start up, which didn't happen on the second AP30 startup:
    2012:01:01-18:47:24 floor1 sysinit: rm: can't remove '/var/run/hostapd-*.maclist': No such file or directory
    2012:01:01-18:47:25 floor1 sysinit: 192.168.1.1 = 192.168.1.1
    2012:01:01-18:47:25 floor1 kernel: [ 16.820000] device eth0 entered promiscuous mode
    2012:01:01-18:47:25 floor1 kernel: [ 16.820000] br-lan: port 1(eth0) entering forwarding state
    2012:01:01-18:47:25 floor1 kernel: [ 16.820000] br-lan: port 1(eth0) entering forwarding state
    2012:01:01-18:47:25 floor1 sysinit: Interface type not supported.
    2012:01:01-18:47:26 floor1 kernel: [ 17.450000] cfg80211: Calling CRDA for country: US
    2012:01:01-18:47:26 floor1 sysinit: Usage: iw [options] phy  set antenna  | all |  
    2012:01:01-18:47:26 floor1 sysinit: Set a bitmap of allowed antennas to use for TX and RX.
    2012:01:01-18:47:26 floor1 sysinit: The driver may reject antenna configurations it cannot support.
    2012:01:01-18:47:26 floor1 sysinit: Options:
    2012:01:01-18:47:26 floor1 sysinit: --debug enable netlink debugging
    2012:01:01-18:47:26 floor1 kernel: [ 17.990000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 0 - CWmin: 3, CWmax: 4, Aifs: 2, TXop: 102.
    2012:01:01-18:47:26 floor1 kernel: [ 17.990000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 1 - CWmin: 4, CWmax: 5, Aifs: 2, TXop: 188.
    2012:01:01-18:47:26 floor1 kernel: [ 17.990000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 2 - CWmin: 5, CWmax: 10, Aifs: 3, TXop: 0.
    2012:01:01-18:47:26 floor1 kernel: [ 17.990000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 3 - CWmin: 5, CWmax: 10, Aifs: 7, TXop: 0.
    2012:01:01-18:47:26 floor1 kernel: [ 18.090000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 0 - CWmin: 3, CWmax: 4, Aifs: 2, TXop: 102.
    2012:01:01-18:47:26 floor1 kernel: [ 18.090000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 1 - CWmin: 4, CWmax: 5, Aifs: 2, TXop: 188.
    2012:01:01-18:47:26 floor1 kernel: [ 18.090000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 2 - CWmin: 5, CWmax: 10, Aifs: 3, TXop: 0.
    2012:01:01-18:47:26 floor1 kernel: [ 18.090000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 3 - CWmin: 5, CWmax: 10, Aifs: 7, TXop: 0.
    2012:01:01-18:47:26 floor1 kernel: [ 18.100000] device wlan0 entered promiscuous mode
    2012:01:01-18:47:27 floor1 kernel: [ 19.150000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 0 - CWmin: 2, CWmax: 3, Aifs: 1, TXop: 47.
    2012:01:01-18:47:27 floor1 kernel: [ 19.150000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 1 - CWmin: 3, CWmax: 4, Aifs: 1, TXop: 94.
    2012:01:01-18:47:27 floor1 kernel: [ 19.150000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 2 - CWmin: 4, CWmax: 6, Aifs: 3, TXop: 0.
    2012:01:01-18:47:27 floor1 kernel: [ 19.150000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 3 - CWmin: 4, CWmax: 10, Aifs: 7, TXop: 0.
    2012:01:01-18:47:28 floor1 kernel: [ 19.370000] device red0.100 entered promiscuous mode
    2012:01:01-18:47:28 floor1 kernel: [ 19.370000] device red0 entered promiscuous mode
    2012:01:01-18:47:28 floor1 kernel: [ 19.460000] cfg80211: Regulatory domain changed to country: US
    2012:01:01-18:47:28 floor1 kernel: [ 19.460000] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
    2012:01:01-18:47:28 floor1 kernel: [ 19.460000] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
    2012:01:01-18:47:28 floor1 kernel: [ 19.460000] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
    2012:01:01-18:47:28 floor1 kernel: [ 19.460000] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    2012:01:01-18:47:28 floor1 kernel: [ 19.460000] cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    2012:01:01-18:47:28 floor1 kernel: [ 19.460000] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    2012:01:01-18:47:28 floor1 kernel: [ 19.460000] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
    2012:01:01-18:47:28 floor1 kernel: [ 19.960000] br-red100: port 2(red0.100) entering learning state
    2012:01:01-18:47:28 floor1 kernel: [ 19.960000] br-red100: port 2(red0.100) entering learning state
    2012:01:01-18:47:28 floor1 kernel: [ 19.960000] br-red100: port 1(wlan0) entering learning state
    2012:01:01-18:47:28 floor1 kernel: [ 19.960000] br-red100: port 1(wlan0) entering learning state
    2012:01:01-18:47:30 floor1 kernel: [ 21.380000] device wlan0 left promiscuous mode
    2012:01:01-18:47:30 floor1 kernel: [ 21.380000] br-red100: port 1(wlan0) entering learning state
    2012:01:01-18:47:30 floor1 kernel: [ 21.510000] device wlan0 entered promiscuous mode
    2012:01:01-18:47:30 floor1 kernel: [ 21.510000] br-red100: port 1(wlan0) entering learning state
    2012:01:01-18:47:30 floor1 kernel: [ 21.510000] br-red100: port 1(wlan0) entering learning state
    2012:01:01-18:47:30 floor1 kernel: [ 21.750000] device wlan1 entered promiscuous mode
    2012:01:01-18:47:30 floor1 kernel: [ 21.750000] br-lan: port 2(wlan1) entering forwarding state
    2012:01:01-18:47:30 floor1 kernel: [ 21.750000] br-lan: port 2(wlan1) entering forwarding state
    2012:01:01-18:47:30 floor1 kernel: [ 21.990000] device wlan2 entered promiscuous mode
    2012:01:01-18:47:30 floor1 kernel: [ 21.990000] br-lan: port 3(wlan2) entering forwarding state
    2012:01:01-18:47:30 floor1 kernel: [ 21.990000] br-lan: port 3(wlan2) entering forwarding state 


    Not sure if this type of behavior is normal or not. Regardless I will monitor the status of the wireless and see if the problem persists.


    Another idea I had is to turn off the 5Ghz band on both AP's. But I will try that after this test.

    To answer your question, I have two AP30's.

    Thanks for your help!
  • 0 in reply to RedTechie
    Hi,
    as far I know the AP10/30s only do 2.4ghz, you need a AP50 to get the dual band function.

    One further thing to try, is only have one AP connected at a time for a day or two to see what happens.

    Ian M

    XG115W - v20.0.2 MR-2 - Home

    XG on VM 8 - v21 GA

    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to rfcat_vk
    Well both those ideas didn't help with the problem :sigh:

    Changing the AP30 settings to 2.4Ghz (even though they only have a 2.4Ghz radio) did not change anything. 

    Also turning one or the other off did not change anything either.... It actually made it worse. Maybe the amount of traffic on the AP plays a part in this?


    I have crafted a temporary workaround that works "better" than a 6 hour restart of awed.

    With the help of a script I found at this website: Simple Linux and UNIX system monitoring with ping command and scripts

    I modified it a bit to check two always on/in the house devices. If either one fails it will restart awed. I told it to run every two minutes with a cron job. Works beautifully. 

    So instead of my wireless going down for hours until I fix it or the 6 hour timer is up. It now goes down for a few minutes every few hours whenever the wireless times out.

    I'm really looking forward to that fix Astaro (Sophos).... [;)]
  • 0 in reply to RedTechie

    I have crafted a temporary workaround that works "better" than a 6 hour restart of awed.

    With the help of a script I found at this website: Simple Linux and UNIX system monitoring with ping command and scripts

    I modified it a bit to check two always on/in the house devices. If either one fails it will restart awed. I told it to run every two minutes with a cron job. Works beautifully. 

    So instead of my wireless going down for hours until I fix it or the 6 hour timer is up. It now goes down for a few minutes every few hours whenever the wireless times out.


    Are your scripts pinging the APs or a wireless client to see if the problem appears?
    So, are the APs still "pingable" when they enter this state?

    Thanks,
    Helmut
  • 0 in reply to hschaa
    Are your scripts pinging the APs or a wireless client to see if the problem appears?
    So, are the APs still "pingable" when they enter this state?


    RedTechie, do you have any update to my question?

    Thanks,
    Helmut
  • 0 in reply to hschaa
    Well it seems (so far at least) that my issues have been solved with 8.301! [:D] I have disabled my script and all my wireless devices have been chugging along with no disconnects for a day or so. I will keep an eye on it.

    RedTechie, do you have any update to my question?

    Thanks,
    Helmut


    I'm sorry Helmut! For some reason the this board never sent me email notifications from all the replies! I do have it set to send notifications instantly... strange...

    To answer your question the script would ping a number of different wireless clients (in my case 2) that were always in the house. If either one went down it would restart the awed daemon. It worked pretty good as I have been running it up until 8.301 came out without noticing the problem. (I did verify the problem was still present via the wireless log files)

    The APs were pingable during the issue. It just was the clients that were dropping off (it looked like some sort of encryption mis-match in the logs)

    Anyway I'll post back after a week or so and see if anything has changed. Crossing my fingers I think my issue has been fixed with 8.301!
  • 0 in reply to RedTechie

    The APs were pingable during the issue. It just was the clients that were dropping off (it looked like some sort of encryption mis-match in the logs)


    Could you please elaborate on your assumption regrading the encryption mismatch?
    Thanks.
Reply
  • 0 in reply to RedTechie

    The APs were pingable during the issue. It just was the clients that were dropping off (it looked like some sort of encryption mis-match in the logs)


    Could you please elaborate on your assumption regrading the encryption mismatch?
    Thanks.
Children
  • 0 in reply to hschaa
    I'm having a similar issue - at random times I have dropped connections to all my AP30s (3 currently) at the same time and in a matter of seconds they are all up and running again. It could run anywhere from two minutes to two hours before the next drop, then the same thing. Lights on the points at the time of the outage are as follows - At first drop – Activity Light goes out / Power light stays on / Wireless Activity light stays on
    Then after a few seconds – Activity light comes on stays solid / Power light flashes / Wireless Activity light stays on
    Then – Activity light flashes / Power light goes solid / Wireless flashes

    This all started to happen after the upgrade to 8.300 to 8.301
    I have attached the log file from around one of the times it went down today.
  • 0 in reply to hschaa
    Could you please elaborate on your assumption regrading the encryption mismatch?
    Thanks.


    (See my first post for an example of the logs during an outage)

    Basically, All wireless clients disconnect from the problematic AP (sometimes it's both AP's, sometimes one or the other). During this time the wireless activity light is just solid with very occasional blinks. If you try to reconnect to the AP's that are affected by this issue during the outage it asks you for the wireless password. I enter in the password and it just keeps asking me (at least that's what I noticed on iOS devices).

    And my theory regarding the encryption issue is purely based on the fact that I'm getting a bunch of encryption based messages right before the outage.
  • 0 in reply to RedTechie
    (See my first post for an example of the logs during an outage)

    Basically, All wireless clients disconnect from the problematic AP (sometimes it's both AP's, sometimes one or the other). During this time the wireless activity light is just solid with very occasional blinks. If you try to reconnect to the AP's that are affected by this issue during the outage it asks you for the wireless password. I enter in the password and it just keeps asking me (at least that's what I noticed on iOS devices).


    Thanks for the info. The log indeed shows WPA handshake failures but this is no indication for a crypto bug. It seems more likely that the AP is dropping (or somehow losing) the EAPOL frames and thus never gets an answer back from the clients. As a result the client is asking for the passphrase again and again since it cannot establish a secured connection.

    Could you please observe if the kindle fire somehow increases chances to trigger the problem. If it does I'd buy one for internal testing ASAP.

    Second, I could prepare a special firmware containing much more debug output in the suspicious places. That might help to find the root cause triggering this issue. If you like to try that please drop me a note to helmut.schaa@sophos.com.

    Thanks for your patience,
    Helmut
  • 0 in reply to hschaa
    Thanks for the info. The log indeed shows WPA handshake failures but this is no indication for a crypto bug. It seems more likely that the AP is dropping (or somehow losing) the EAPOL frames and thus never gets an answer back from the clients. As a result the client is asking for the passphrase again and again since it cannot establish a secured connection.

    Could you please observe if the kindle fire somehow increases chances to trigger the problem. If it does I'd buy one for internal testing ASAP.

    Second, I could prepare a special firmware containing much more debug output in the suspicious places. That might help to find the root cause triggering this issue. If you like to try that please drop me a note to helmut.schaa@sophos.com.

    Thanks for your patience,
    Helmut


    Thanks Helmut for this detailed analysis! Regarding the mention of crypto errors in the log. I wasnt sure if EAPOL msgs were part of encryption or not, so i said encryption mismatch. But what you mentioned is accurate of my problem. 

    Well, needless to say it wasn't just the kindle fire like i thought. I told the kindle fire to forget all the astaro APs and to connect to a AT&T hotspot only; but the problem still happened when the kindle wasn't connected.

    I would be more than happy to help debug this issue with a more verbose firmware! The problem dosn't take to long to surface without the awed restart script running and with all the mobile devices we have. I'll send you an email now.
Unfiltered HTML