Forum

I was just going through the Symbol training, and they have implemented "Symbol Extensions" - just like Cisco does - and one of them is where the APs have some additional info in the Beacons and the clients (Symbol clients of course) have some special sauce in the drivers so that a client can move from AP to AP without having to even do a 4-Way Handshake. Normally, the 4-Way is required because each AP's BSSID is different, but apparently the special sauce in the client lets it ignore this fact in some way.

If you ever run across a scenario of Symbol clients and Symbol switches (3.0 code or higher) where the clients are roaming but they don't seem to be roaming...well, this is it. ;-)

Devinator

Funnily enough, some of these symbol-specific parameters in beacons has caused havoc with their own (albeit older) terminals.

I noticed in release 2.0 of the WS5K code that there were some more symbol specific parameters in the beacons. From my own research I think it causes the beacons to exceed some kind of internal buffer on some wearable terminals. This seems to lock them up completely where they would normally roam happily. One workaround I discovered was to cut the available rates on the AP policy down to shorten the number of bytes the beacon, but this type of thing doesn't fill me with great confidence going forward.

The 3.0 code has some nice additional features but I for one will be giving it a while to mature, especially considering the side effects it might have with older equipment. Progress is great but sometimes it's at the expense of compatibility. It would be nice to be able to disable these features as you can with aironet extensions. Is this possible in the new code?

I don't think you can disable these extensions - at least not from what I've seen in the GUI or CLI. I LOVE the new 3.0 code. Best code I've seen in a long time from any vendor.

Devin