Re: Network Manager reason codes
On Thu, 2011-02-10 at 21:10 +, mike cloaked 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. Ok it is time to admit ignorance. I don't understand the scenario described above. What are the implications of having 2 APs in your house (meaning I assume that they have thew same wireless passed) but different bssids (presumably different Mac addresses for the AP cards). How would you specify using NM one AP over the other. Wouldn't only one connection entry show up on the NM access point list? -- === Murder is always a mistake -- one should never do anything one cannot talk about after dinner. -- Oscar Wilde, The Picture of Dorian Gray === Aaron Konstam telephone: (210) 656-0355 e-mail: akons...@sbcglobal.net ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager reason codes
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. Sven ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager reason codes
On Fri, Feb 11, 2011 at 4:30 PM, Sven Nielsen p...@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 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager reason codes
On Fri, Feb 11, 2011 at 7:06 PM, mike cloaked mike.cloa...@gmail.com wrote: On Fri, Feb 11, 2011 at 4:30 PM, Sven Nielsen p...@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. By the way the whole point of having two access points set up with the same ssid and encryption is that you just connect to a single ssid wherever you are in that location - but NM simply does not seem to behave that way. If you set different ssid on the two access points, then the behaviour I described above still happens if there is any small amount if signal from the access point still seen by the wireless radio - only if there is no signal at all from the previously connected access point will the system then forget the previous connection and try to connect to the near one. I have indeed heard the reasons for why the logic for making the initial connection is the way it is currently but in the scenario I described it would appear to me to be significantly away from the optimum behaviour - If my description is not well phrased I will try to describe it a different way? -- mike c ___
Re: Network Manager reason codes
On Fri, 11 Feb 2011 19:06:18 + mike cloaked mike.cloa...@gmail.com wrote: 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) Yes, in fact I have been using this on a regular basis in an environment consisting of as much as 20 APs serving a corporate facility. I am sorry that there seems to be some issues with the software/hardware you are using. You can try if fine-tuning the sens parameter of iwconfig helps. Check the signal level you get with iwconfig, then adapt the sens value, and try if roaming happens faster if you then change position in your home. Those 20 APs were actually built and configured by me, and one of the requirements for that installation was uninterrupted WLAN Voip calling while the clients roam between the APs. So, in theory, roaming is a very well working concept. Still, it depends on the hardware and software/drivers working well together. For debugging, you can also try if disabling network-manager and configuring the connection manually in /etc/networks gives better roaming behaviour. If roaming does not work for you, it is a misconfiguration or a bug, and defining several networks with different BSSIDs for the sams SSID is nothing but crude workaround which should not be necessary. Regards, Sven ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Issues in commit 52f2295: libnm-util: fix possible crash in nm_setting_update_secrets()
Hi, I've noticed issues connecting to my test PPTP VPN (using SwissVPN test account); secrets can't be retrieved which causes the VPN connection to immediately fail on start. That was using a package built on the latest commits in branch NM_0_8, in Ubuntu Natty. If I revert the commit 52f2295a4925acc892e2fd67540671d4a8047f55 [1], things seem to work properly again. I sadly haven't had time to further look into the issue yet; so this is just a heads up that something might be broken ;) [1] http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=NM_0_8id=52f2295a4925acc892e2fd67540671d4a8047f55 Regards, Mathieu Trudel-Lapierre mathieu...@gmail.com Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager reason codes
On Fri, Feb 11, 2011 at 7:59 PM, Sven Nielsen p...@svennielsen.de wrote: I am sorry that there seems to be some issues with the software/hardware you are using. You can try if fine-tuning the sens parameter of iwconfig helps. Check the signal level you get with iwconfig, then adapt the sens value, and try if roaming happens faster if you then change position in your home. There are two separate issues here - one is the initial connection going to the less appropriate AP - and the other is roaming once you are connected. Both seem to be problematic for my case. Maybe I am missing something but presumably iwconfig is a temporary work around each time I boot the laptop - and it would seem that since NM would attempt a connection before I got a chance to set up a terminal and enter commands from the CLI then NM would already have done the wrong thing for me. I presume you would need to enter something like iwconfig wlan0 sens 10 and then restart NM to see if that helped - but it would mean doing this workaround each time I boot the machine? I will certainly run a test over the weekend to see if this makes a difference - and if it does it would help. However in this case unless I set the sens alteration command as part of a script in rc.local or similar then I would need to do the tweak after each login which is far from ideal - it would be nice if this could be a much more automated process. Indeed for a less experienced user this would seem an undesirable thing to have to do. I am used to hacking to get the system to work as I like it to. Those 20 APs were actually built and configured by me, and one of the requirements for that installation was uninterrupted WLAN Voip calling while the clients roam between the APs. So, in theory, roaming is a very well working concept. Still, it depends on the hardware and software/drivers working well together. Possibly once connected altering the value of the sens command may then help the roaming aspect if what you suggest will help my use case. For debugging, you can also try if disabling network-manager and configuring the connection manually in /etc/networks gives better roaming behaviour. You mean set up wpa_supplicant manually? I used to do this but I thought that we had moved forward to a more modern era where doing this manually was a thing of the past! If roaming does not work for you, it is a misconfiguration or a bug, and defining several networks with different BSSIDs for the sams SSID is nothing but crude workaround which should not be necessary. I totally agree but I would like to know where any misconfiguration has happened - all I do is boot the machine and NetworkManager shows the available connections - and I connect - where do I then have to look for misconfigured files? Or is this a set of standard configurations that are set in the package in Fedora that may be different from configs in your operating system? Are you also using Fedora or a different linux distribution? It would be so nice to get this resolved! Regards, Mike -- mike c ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager reason codes
On Fri, 11 Feb 2011 20:17:27 + mike cloaked mike.cloa...@gmail.com wrote: I totally agree but I would like to know where any misconfiguration has happened - all I do is boot the machine and NetworkManager shows the available connections - and I connect - where do I then have to look for misconfigured files? Or is this a set of standard Misconfiguration in the way that NM's internal default values are not well chosen. different from configs in your operating system? Are you also using Fedora or a different linux distribution? Ubuntu 10.10 Maybe I am missing something but presumably iwconfig is a temporary work around each time I boot the laptop - and it would seem that since NM would attempt a connection before I got a chance to set up a terminal and enter commands from the CLI then NM would already have done the wrong thing for me. iwconfig can change parameters after a connection is up. iwconfig is not in itself for workarounds. It is a tool for setting parameters of the wlan card. NM also acts on these parameters, and might set them subotpimal. So, to analyse if your problem is hardware/driver/NM related, fiddling with iwconfig can give hints. I presume you would need to enter something like iwconfig wlan0 sens 10 and then restart NM to see if that helped - but it would mean doing this workaround each time I boot the machine? Yo do not need to restart NM. iwconfig value changes take effect immediately while an interface is up. No, according to man iwconfig it would mean setting it to some negative value: Go to the location in the middle between your access points. You find this by issuing iwlist wlan_if scan repeatedly. Monitor the Signal level: If both APs show roughly the same level, say e.g. -55 dBm, you have found the middle. Now, set sens to some value a little lower, e.g. iwconfig wlan_if sens -60 Your card should then switch APs as soon as you cross this middle signal level. You can automate this setting by adding, as root, a script in /etc/network/if-up.d/ Name it e.g. set_sens and, in the script: #!/bin/bash if [ $IFACE = wlan_if ]; then iwconfig wlan_if sens -60 # use this to check if script works: # iwconfig wlan_if txpower 3 fi (Replace wlan_if with wour interface name). Make the script executable for all. In theory, NM should then honour this script and set the sens value each time it brings up your wlan interface. The script should be triggered when disabling and enabling again wireless through NM tray icon. Check if the script works by changing a value you can monitor, e.g in the script set txpower to 3 instead of the sens value. After completely disabling wireless an enabling it again, iwconfig should show Tx-Power=3 dBm Possibly once connected altering the value of the sens command may then help the roaming aspect if what you suggest will help my use case. Yes, changing it after being connected should help. And the above script should automate the process. I hope the NM on Fedora honours the if-??.d scripts, too. You mean set up wpa_supplicant manually? I used to do this but I thought that we had moved forward to a more modern era where doing this manually was a thing of the past! No, if wireless-tools and wpasupplicant are installed you can put a simple config in /etc/network/interfaces: iface wlan0 inet dhcp wpa-ssid YOUR_SSID wpa-passphrase your_passphrase ... This would be for wpa2, for WEP you would use wireless-essid etc. See /usr/share/doc/wpasupplicant/ and man wireless for more info. Regards, Sven ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager reason codes
On Fri, 11 Feb 2011 20:17:27 + mike cloaked mike.cloa...@gmail.com wrote: it would be nice if this could be a much more automated process. Indeed for a less experienced user this would seem an undesirable thing to have to do. Totally agree. NM should expose alot more of these sophisticated network functions though some kind of advanced GUI interface. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager reason codes
On Fri, Feb 11, 2011 at 9:24 PM, Sven Nielsen p...@svennielsen.de wrote: On Fri, 11 Feb 2011 20:17:27 + mike cloaked mike.cloa...@gmail.com wrote: I totally agree but I would like to know where any misconfiguration has happened - all I do is boot the machine and NetworkManager shows the available connections - and I connect - where do I then have to look for misconfigured files? Or is this a set of standard Misconfiguration in the way that NM's internal default values are not well chosen. different from configs in your operating system? Are you also using Fedora or a different linux distribution? Ubuntu 10.10 Maybe I am missing something but presumably iwconfig is a temporary work around each time I boot the laptop - and it would seem that since NM would attempt a connection before I got a chance to set up a terminal and enter commands from the CLI then NM would already have done the wrong thing for me. iwconfig can change parameters after a connection is up. Wow - that is really valuable and comprehensive advice - thank you so much. I will run tests over the weekend and report back Sunday evening. Mike -- mike c ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: Network Manager reason codes
different from configs in your operating system? Are you also using Fedora or a different linux distribution? This is off-topic. But I must say this. It is not Linux distribution. It is the GNU Distribution. They are the distributions of the GNU Operating system. From: networkmanager-list-boun...@gnome.org [networkmanager-list-boun...@gnome.org] On Behalf Of Sven Nielsen [p...@svennielsen.de] Sent: Saturday, February 12, 2011 2:54 AM To: networkmanager-list@gnome.org Subject: Re: Network Manager reason codes On Fri, 11 Feb 2011 20:17:27 + mike cloaked mike.cloa...@gmail.com wrote: I totally agree but I would like to know where any misconfiguration has happened - all I do is boot the machine and NetworkManager shows the available connections - and I connect - where do I then have to look for misconfigured files? Or is this a set of standard Misconfiguration in the way that NM's internal default values are not well chosen. different from configs in your operating system? Are you also using Fedora or a different linux distribution? Ubuntu 10.10 Maybe I am missing something but presumably iwconfig is a temporary work around each time I boot the laptop - and it would seem that since NM would attempt a connection before I got a chance to set up a terminal and enter commands from the CLI then NM would already have done the wrong thing for me. iwconfig can change parameters after a connection is up. iwconfig is not in itself for workarounds. It is a tool for setting parameters of the wlan card. NM also acts on these parameters, and might set them subotpimal. So, to analyse if your problem is hardware/driver/NM related, fiddling with iwconfig can give hints. I presume you would need to enter something like iwconfig wlan0 sens 10 and then restart NM to see if that helped - but it would mean doing this workaround each time I boot the machine? Yo do not need to restart NM. iwconfig value changes take effect immediately while an interface is up. No, according to man iwconfig it would mean setting it to some negative value: Go to the location in the middle between your access points. You find this by issuing iwlist wlan_if scan repeatedly. Monitor the Signal level: If both APs show roughly the same level, say e.g. -55 dBm, you have found the middle. Now, set sens to some value a little lower, e.g. iwconfig wlan_if sens -60 Your card should then switch APs as soon as you cross this middle signal level. You can automate this setting by adding, as root, a script in /etc/network/if-up.d/ Name it e.g. set_sens and, in the script: #!/bin/bash if [ $IFACE = wlan_if ]; then iwconfig wlan_if sens -60 # use this to check if script works: # iwconfig wlan_if txpower 3 fi (Replace wlan_if with wour interface name). Make the script executable for all. In theory, NM should then honour this script and set the sens value each time it brings up your wlan interface. The script should be triggered when disabling and enabling again wireless through NM tray icon. Check if the script works by changing a value you can monitor, e.g in the script set txpower to 3 instead of the sens value. After completely disabling wireless an enabling it again, iwconfig should show Tx-Power=3 dBm Possibly once connected altering the value of the sens command may then help the roaming aspect if what you suggest will help my use case. Yes, changing it after being connected should help. And the above script should automate the process. I hope the NM on Fedora honours the if-??.d scripts, too. You mean set up wpa_supplicant manually? I used to do this but I thought that we had moved forward to a more modern era where doing this manually was a thing of the past! No, if wireless-tools and wpasupplicant are installed you can put a simple config in /etc/network/interfaces: iface wlan0 inet dhcp wpa-ssid YOUR_SSID wpa-passphrase your_passphrase ... This would be for wpa2, for WEP you would use wireless-essid etc. See /usr/share/doc/wpasupplicant/ and man wireless for more info. Regards, Sven ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ::DISCLAIMER:: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail
