Re: Network Manager reason codes
- From: mike cloaked <mike cloaked gmail com>
- To: networkmanager-list gnome org
- Subject: Re: Network Manager reason codes
- Date: Fri, 11 Feb 2011 19:06:18 +0000
On Fri, Feb 11, 2011 at 4:30 PM, Sven Nielsen <post svennielsen de> wrote:
>> >
>> > That is of course fine - but there are use cases where the two APs are
>> > both in one's own home - and both have the same ssid.... and that
>> > presents a problem - at least for me.
>> >
> I cannot see the problem either. I think you are talking about the common scenario of having several APs
> physically distributed on a location which are providing the same WLAN (i.e. all have identical SSID and
> security settings) to clients. Purpose is to ensure good connectivity around the whole facility.
>
> This situation is already handled automatically by Network Manager. Simply define a network configuration,
> and do NOT set a bssid. This way, NM can (and will) always and automatically connect to the AP with the
> strongest signal. It will also automatically switch to another AP if you move out of the range of one AP and
> into the range of another AP. It does this transparently, usually even without any noticeable connection
> pause.
>
> DO NOT set the BSSID (MAC) if you want to roam several APs that provide the same WLAN.
>
> To optimize WLAN quality, configure APs with distinct channels (e.g. 1 and 6) to avoid interferences between
> both signals.
I don't know if you have actually tried this in a real life situation
or not? However if you do have two access points, and they have the
same ssid, and the same wpa2 encryption with the same password, but
are on different channels (let's say one is upstairs and the other is
downstairs) - then go near access point 1 (let's say it is upstairs) -
and connect - it works really well and indeed you can see which it has
connected to by running "iwconfig" as root. This will show the mac
address of the access point that the wireless is connected to and it
will confirm it has connected to the access point in the same room.
The signal remains beautifully at about 100% for as long as you like -
and all is sweet.
Now you turn the laptop off and go to work.
In the evening you come back home, and being tired you bring the
laptop downstairs and sit on the sofa while you watch the news and
turn on the laptop which is now near the downstairs access point.
You find the signal is really weak and the speed of connection is low
- so you become root and type "iwconfig" - you are amazed that it is
still connecting to the the upstairs access point as you can still see
the same mac address listed. The access point is only 10 feet from
you and if the laptop would only connect to this one you would get a
solid and unwavering 100% signal - but NM refuses to co-operate and
make that connection.
OK so you are now frustrated - so you go into the NM connections list
and remove the connection that you already have. You do "service
NetworkManager restart" and then when the icon reappears on the gnome
desktop, you click it, and connect to the same ssid name - now it
connects immediately to the near one with 100% signal and you use it
all evening with no problem.
You shutdown for the night. Next morning you are upstairs and turn on
the laptop - and it now wants to stick with the one downstairs - which
is now very weak because you are upstairs! This is my experience with
more than one laptop - with different wireless cards but all running
Fedora 14.
So next time I am in the situation where it refuses to connect to the
strong signal I disconnect the wireless and edit the connection in NM
- and add in the MAC address of the near access point into the bssid
field and save the change. Now I can connect to the specific access
point that I want to.
The point is that I should not need to go through this rigmarole to
connect to a very much stronger access point which is transmitting the
same ssid, password and encryption type as another access point with
the same connection details which is much further away and has a
substantially and consistently weaker signal.
--
mike c
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]