Booting and resetting too fast for Cisco switches

I don't know that you can call that an issue with the ASG APs... I've had networks in the past that had problems until I disabled Spanning Tree or set to Port Fast mode, ports on Cisco switches.  This happened with a variety of workstations and devices.

Thanks for the report. We've seen similar issues internally as well (also with Cisco switches) and we'll adjust the AP reset timeout to a larger value soon.

On NetGear switches even with PoE an VLAN's on it i didn't see this behavior ...

Robert

It has to do with how *slow* some Cisco switches are, without special configuration, at recognizing whether a port is a spanning tree port or not.  IIRC, newer builds of IOS for the newer Cisco switches default to having all ethernet ports set as "portfast" ports, which fixes the problem "out of the box."  Older builds default to a slower spanning tree protocol.  In my experience, most newer switches that support spanning tree default to a "Fast" spanning tree detection algorithm to skirt the issue.

Yes, but I would also say that the AP is resetting way too quickly.

While this config did help, not every client that has Cisco switches that tries to plug in an AP will know this. Adding an extra 15 - 30 seconds before it resets itself shouldn't hurt.

i´ve got similar problem cisco 3750 with poe. first everything seems to bee very fine but after a few test now i can see that the ap lost the network connection after a few seconds (round about 20 to 60):
logfile:
2010:07:28-18:47:09 192.168.113.98 : Interface type not supported.
2010:07:28-18:47:09 192.168.113.93 : Interface type not supported.
2010:07:28-18:47:09 192.168.113.93 kernel: [42949414.350000] RT305x_ESW: Link Status Changed
2010:07:28-18:47:09 192.168.113.93 kernel: [42949414.350000] RT305x_ESW: Link Status Changed
2010:07:28-18:47:25 asgv7 awed[4045]: recv msg: id 'A400017A7A0ACE1', type: '3', digest: '7c8f5f562113b03a7a0ef25ffe6b09bbb56676a7', length: '32'
2010:07:28-18:47:29 asgv7 awed[4045]: send msg: type '3', digest: '5e3b5ec3c9731cff1b33c7a99dc5921b812106e5', length: '16'
2010:07:28-18:47:27 192.168.113.93 : ASG->DEV [type 3, padlen 16]
2010:07:28-18:47:27 192.168.113.98 kernel: [42949431.420000] RT305x_ESW: Link Status Changed
2010:07:28-18:47:27 192.168.113.98 kernel: [42949431.420000] RT305x_ESW: Link Status Changed
2010:07:28-18:47:30 asgv7 awed[4045]: recv msg: id 'A400013E587C64A', type: '3', digest: '2fe27f3ddd5031a92d817ec25dad90500313f609', length: '32'
2010:07:28-18:47:30 asgv7 awed[4045]: send msg: type '3', digest: '92eecfc1b42f2de13545787966877600d10ca953', length: '16'
2010:07:28-18:47:28 192.168.113.98 : ASG->DEV [type 3, padlen 16]
2010:07:28-18:47:32 192.168.113.98 kernel: [42949436.580000] RT305x_ESW: Link Status Changed
2010:07:28-18:47:32 192.168.113.98 kernel: [42949436.590000] RT305x_ESW: Link Status Changed
2010:07:28-18:47:42 192.168.113.93 : DEV->ASG [type 3, id A400017A7A0ACE1, padlen 32]: { "associated_clients": [ ] }
2010:07:28-18:47:45 asgv7 awed[4045]: recv msg: id 'A400017A7A0ACE1', type: '3', digest: '7c8f5f562113b03a7a0ef25ffe6b09bbb56676a7', length: '32'
2010:07:28-18:47:45 asgv7 awed[4045]: send msg: type '3', digest: '5e3b5ec3c9731cff1b33c7a99dc5921b812106e5', length: '16'
2010:07:28-18:47:43 192.168.113.93 : ASG->DEV [type 3, padlen 16]
2010:07:28-18:47:43 192.168.113.98 : DEV->ASG [type 3, id A400013E587C64A, padlen 32]: { "associated_clients": [ ] }
2010:07:28-18:47:46 asgv7 awed[4045]: recv msg: id 'A400013E587C64A', type: '3', digest: '2fe27f3ddd5031a92d817ec25dad90500313f609', length: '32'
2010:07:28-18:47:46 asgv7 awed[4045]: send msg: type '3', digest: '92eecfc1b42f2de13545787966877600d10ca953', length: '16'
2010:07:28-18:47:44 192.168.113.98 : ASG->DEV [type 3, padlen 16] 
 

no eventlog entries on the switch.

Hi,

i´ve got similar problem cisco 3750 with poe. first everything seems to bee very fine but after a few test now i can see that the ap lost the network connection after a few seconds (round about 20 to 60)

What's the actual problem you've got? Is the Wifi AP not working during that time? Or are your concerns just based on the log messages? Please elaborate.

Thank you,
Helmut

i can see the AP30 rebooting and it is not available.
i can say that i haven´t got the time to try out wether it ist better to activate the portfast or disable. 
i still have other differrent problems but this thread discribes one of them.
both APs rebooting without any reason and i´m loosing contact.
during the reboot i can see the client roaming to the other AP but the "running" ping is interrupted then the nearest AP is back online and only if i reboot the client i get a connection. (when i hit the moment when the AP and the wireless network is online).
in the moment i try to find out in which situation this happens and to recreate this behavior. And whether this happens if i connect the AP on a Cisco 2960 whithout poe.

i can see the AP30 rebooting and it is not available.
i can say that i haven´t got the time to try out wether it ist better to activate the portfast or disable. 
i still have other differrent problems but this thread discribes one of them.
both APs rebooting without any reason and i´m loosing contact.
during the reboot i can see the client roaming to the other AP but the "running" ping is interrupted then the nearest AP is back online and only if i reboot the client i get a connection. (when i hit the moment when the AP and the wireless network is online).
in the moment i try to find out in which situation this happens and to recreate this behavior. And whether this happens if i connect the AP on a Cisco 2960 whithout poe.

Just for clarification: this thread is about the AP rebooting _before_ it was able to connect to the ASG and thus _before_ it activates the wireless networks.

As far as I understand (according to your description) your AP is rebooting sometimes while it is already operational and used by a client. If that's the case your issue seems to be different. To track that issue further down, could you please enable debugging on the APs (see [1] for a description), reproduce the problem and open a new thread afterwards with the /var/log/wireless.log attached? That might give us a clue.

Thank you very much,
Helmut

[1] http://www.astaro.org/astaro-beta-versions/astaro-wireless-security-beta/33027-wlan-crash-after-few-clients-connected.html#post151296

okay sorry, i´ve missed the "before"