Roaming between Linksys WAP54G APs works!

I've just been fiddling with roaming between Linksys WAP54G (V2, FW
2.08) APs with a separate router, and it seems to work pretty well.

Even with WPA-PSK/TKIP security turned on, getting close to the
"other" AP causes the laptop to sync up to that one and continue
passing bits. I've tried it when playing an MP3 off a file server on
the LAN, and it does glitch briefly while switching APs, but it's not
horrible for Email and Web use.

I've got both APs on the same channel, with the same SSID and
identical keys.

I've got a Dell Latitude D600 laptop with an Intel 2200BG Mini-PCI
card (9.0.2.25 drivers) running XP-Pro SP2 with all the latest
patches.

The wisdom here has been that this doesn't work, is there something in
some of the latest drivers/patches/firmware that made this work, or am
I missing something?

When I removed the antennas it took quite a while to sync up to the
"near" AP, but with all antennas in place it seems to sync up without
requiring that the "far" AP get out of range...

On Sat, 20 Aug 2005 20:46:46 -0400, William P. N. Smith <> wrote:

>The wisdom here has been that this doesn't work, is there something in
>some of the latest drivers/patches/firmware that made this work, or am
>I missing something?

Nice try. It really depends on the two coverage areas and wireless
client implementation.

If there's a gap where there's no signal between the two access
points, almost any client will properly start hunting for the a better
connection.

If there's some overlap between the two coverage areas, then the
client will start to hunt for a better connection as soon as the
signal from the original access points disappears.

Where it screws up is there's substantial overlapping coverage between
two access points. For example, putting both access points in the
same room will cause the client to select one of them and hang onto it
forever.

The client also plays a bit part in the puzzle. Some implementations
will hang onto a weak connection long past the point where it should
have given up and started hunting for a better access point. The idea
is that for moving clients (i.e. mobiles, PDA's and VoIP phones) one
would want to extend the dropout time so that the connection doesn't
timeout and disconnect. Such long disconnect delays are also helpful
in dealing with intermittent interference, where one would want to
recover the original connection after the interference disappears.

On the other foot, there are clients that will disconnect and switch
at the slightest provocation or signal loss. Intel keeps optimizing
(juggling) this timeout in various versions of their Proset Centrino
drivers. It makes roaming easy, but is hell on maintaining a
connection while moving.

There's no optimum answer. Methinks client software vendors should
give the customer the option of tinkering with the disconnect timeout,
but everyone seems to be waiting for 802.11r which will allegedly fix
the fast roaming problem, mostly for VoIP applications.

>When I removed the antennas it took quite a while to sync up to the
>"near" AP, but with all antennas in place it seems to sync up without
>requiring that the "far" AP get out of range...

Removing the antennas created the "gap" I described in my first
scenario above.


--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
AE6KS 831-336-2558

Jeff Liebermann <(E-Mail Removed)> wrote:
>Where it screws up is there's substantial overlapping coverage between
>two access points. For example, putting both access points in the
>same room will cause the client to select one of them and hang onto it
>forever.

Both of these are APs that I can see and use independently throughout
my house. The client will switch while it still has a usable signal
to the "far" AP.

>Intel keeps optimizing
>(juggling) this timeout in various versions of their Proset Centrino
>drivers. It makes roaming easy, but is hell on maintaining a
>connection while moving.

This is probably what's happening to me, though in my case it's a
feature! 8*)

> I've got both APs on the same channel, with the same SSID and
> identical keys.

They should really be on non overlapping channels such as 1, 6 or 11.

> The wisdom here has been that this doesn't work, is there something in
> some of the latest drivers/patches/firmware that made this work, or am
> I missing something?

It should work, just sometimes not as well as hoped. Jeff sums it up
just fine.

David.