AP Reboot: errno 2
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-30-2014 01:38 PM
We have a few APs that reboot with a 'heartbeat' lost message, although sometimes it's 'application reboot' in the web interface (of the ZD).
There's nothing obvious in the AP supportinfo file other than it lists reboot_reason: user reboot instead of the above reasons.
This is what the syslog output shows at the reboot time:
Jan 30 15:15:59 wireless4 stamgr: stamgr_AP_xml_house_keeping():complete updating ap cfg to emfd
Jan 30 15:16:00 wireless4 syslog: Request():IPC connection close. errno 2
Jan 30 15:16:00 wireless4 syslog: Request():Deplete everything in the pipe... TODO
Jan 30 15:16:00 wireless4 syslog: main():handleRequest() failed or done...^M
Jan 30 15:16:10 wireless4 stamgr: stamgr_init_AP():AP c0:8a:de:26:10:60 radio(6) default channelset_enable=1 channelset=1057 Line:1421
Jan 30 15:16:10 wireless4 stamgr: stamgr_init_AP():AP c0:8a:de:26:10:60 radio(5) default channelset_enable=0 channelset=0 Line:1421
Jan 30 15:16:19 wireless4 stamgr: stamgr_AP_xml_house_keeping():complete updating ap cfg to emfd
Any insight as to what these syslog messages mean? Specifically what causes errno 2?
I had a support call open a few months back but couldn't replicate it reliably and it disappears most of the time when we move one of the rebooting APs to a new drop. It's almost like some APs are more picky about locations (power dips maybe?), because another AP moved to the same drop will be fine.
I should add that I've tried fw force-update on the rebooting APs with no luck.
There's nothing obvious in the AP supportinfo file other than it lists reboot_reason: user reboot instead of the above reasons.
This is what the syslog output shows at the reboot time:
Jan 30 15:15:59 wireless4 stamgr: stamgr_AP_xml_house_keeping():complete updating ap cfg to emfd
Jan 30 15:16:00 wireless4 syslog: Request():IPC connection close. errno 2
Jan 30 15:16:00 wireless4 syslog: Request():Deplete everything in the pipe... TODO
Jan 30 15:16:00 wireless4 syslog: main():handleRequest() failed or done...^M
Jan 30 15:16:10 wireless4 stamgr: stamgr_init_AP():AP c0:8a:de:26:10:60 radio(6) default channelset_enable=1 channelset=1057 Line:1421
Jan 30 15:16:10 wireless4 stamgr: stamgr_init_AP():AP c0:8a:de:26:10:60 radio(5) default channelset_enable=0 channelset=0 Line:1421
Jan 30 15:16:19 wireless4 stamgr: stamgr_AP_xml_house_keeping():complete updating ap cfg to emfd
Any insight as to what these syslog messages mean? Specifically what causes errno 2?
I had a support call open a few months back but couldn't replicate it reliably and it disappears most of the time when we move one of the rebooting APs to a new drop. It's almost like some APs are more picky about locations (power dips maybe?), because another AP moved to the same drop will be fine.
I should add that I've tried fw force-update on the rebooting APs with no luck.
2 REPLIES 2
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-30-2014 06:34 AM
I get this from time to time and it's usually preceeded by the network switches disabling the ports that a few of the APs are on- in essence rebooting them.
I'd love to have a resolution to this.
The switches are cutting off the APs because STP is detecting traffic storms from the APs. After the ports recover and are reactivated things seem ok.
I'd love to have a resolution to this.
The switches are cutting off the APs because STP is detecting traffic storms from the APs. After the ports recover and are reactivated things seem ok.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-30-2014 03:09 PM
I can't tell from that snip what is occurring, but I can advise that if you have 64mb RAM APs in use (7363/7962/7762) that you should segregate your ZD/APs from client traffic VLANs, with what we'd call the management VLAN.
Client VLANs often contain lots of broadcast/multicast traffic, and APs have to
inspect all packets to determine client traffic from the other bcast/mcast. We have
seen IPv6 floods having an impact and causing APs to lose heartbeats with ZD
too. Filter IPv6 at your VLAN router/switches if not used.
Avoid the use of TKIP/Auto settings in PSK WLANs, and use WPA2/AES combo
only. Otherwise, if you continue to encounter application reboots, open a ticket
with Tech Support for deeper investigation.
Client VLANs often contain lots of broadcast/multicast traffic, and APs have to
inspect all packets to determine client traffic from the other bcast/mcast. We have
seen IPv6 floods having an impact and causing APs to lose heartbeats with ZD
too. Filter IPv6 at your VLAN router/switches if not used.
Avoid the use of TKIP/Auto settings in PSK WLANs, and use WPA2/AES combo
only. Otherwise, if you continue to encounter application reboots, open a ticket
with Tech Support for deeper investigation.

