Which AP is chosen when several are found for the same SSID?

2008-10-02 Thread Jose Aliste
Hi all,

I want to ask the question in the subject:
Which AP is chosen when several are found for the same SSID?
I ask this because I see three AP from mi wireless network at my office. Two
of them are 802.11G AP are the other one is only 802.11B the signal for
the slow one is better(it is nearer) and NM always connects to it. However,
I would like to NM to connect to one of the others because even with less
signal the connection is better( 33mb/s against the 11mb/s of  a b
connection!).

So, how can I tell NM to use the AP I need ?

Greetings

José
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: NetworkManager-list Digest, Vol 49, Issue 2

2008-10-02 Thread Howard Chu

Message: 5
Date: Wed, 1 Oct 2008 23:58:22 +0200
From: Alexander Sack[EMAIL PROTECTED]
Subject: [PATCH] hostname support for ifupdown plugin + allow
read-only   hostname system provider + move nm_inotify_helper to 
plugin
independent place (system-settings/src/)
To: networkmanager-list@gnome.org
Message-ID:[EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii

Implement system hostname support for debian/ubuntu

Fix only system-setting plugins with 
NM_SYSTEM_CONFIG_INTERFACE_CAP_MODIFY_HOSTNAME
are considered a valid hostname provider

Make nm-inotify-helper from ifcfg-fedora plugin usable
for other plugins too


Is any of that really necessary? Any tool that rewrites /etc/hostname is also 
going to already call sethostname(); shouldn't you only need to call 
gethostname() to get NM in sync? Why go thru the hassle of opening and reading 
a file and calling sethostname() to tell the kernel what it already knows?


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Consistent usage of ip_iface vers iface

2008-10-02 Thread Per Hallsmark

Hi,

If I read the sources right, it seems the iface/ip_iface usage is a bit 
inconsistent.
Probably it all started out with iface and later ip_face was added for 
those parts
that needed specifying an network interface because the original 
interface wasn't.

So, now I stumble into more areas where this change needs to be done.
Attached is a patch for this.

One(?) thing left (you can search for TODO in the patch) is to change in 
NetworkManagerPolicy.c, function update_default_route(), where the

logic depends on iface != ip_iface to mean ppp...
In my case, I would just like to have the normal path in that function even
though that the iface/ip_iface differs.
Wouldn't it be enough for ppp to set 0 for gateway and we could simplify
this function?

Best regards,
Per
Index: src/dhcp-manager/nm-dhcp-dhclient.c
===
--- src/dhcp-manager/nm-dhcp-dhclient.c	(revision 4136)
+++ src/dhcp-manager/nm-dhcp-dhclient.c	(working copy)
@@ -45,23 +45,23 @@
 
 
 static char *
-get_pidfile_for_iface (const char * iface)
+get_pidfile_for_iface (const char * ip_iface)
 {
 	return g_strdup_printf (%s/%s-%s.%s,
 	NM_DHCP_MANAGER_RUN_DIR,
 	NM_DHCP_MANAGER_PID_FILENAME,
-	iface,
+	ip_iface,
 	NM_DHCP_MANAGER_PID_FILE_EXT);
 }
 
 
 static char *
-get_leasefile_for_iface (const char * iface)
+get_leasefile_for_iface (const char * ip_iface)
 {
 	return g_strdup_printf (%s/%s-%s.%s,
 	NM_DHCP_MANAGER_RUN_DIR,
 	NM_DHCP_MANAGER_LEASE_FILENAME,
-	iface,
+	ip_iface,
 	NM_DHCP_MANAGER_LEASE_FILE_EXT);
 }
 
@@ -84,7 +84,7 @@
 	gboolean success = FALSE;
 
 	g_return_val_if_fail (device != NULL, FALSE);
-	g_return_val_if_fail (device-iface != NULL, FALSE);
+	g_return_val_if_fail (device-ip_iface != NULL, FALSE);
 	
 	new_contents = g_string_new (_(# Created by NetworkManager\n));
 
@@ -157,15 +157,15 @@
 #elif defined(TARGET_DEBIAN)
 	orig = g_strdup (SYSCONFDIR /dhcp3/dhclient.conf);
 #else
-	orig = g_strdup_printf (SYSCONFDIR /dhclient-%s.conf, device-iface);
+	orig = g_strdup_printf (SYSCONFDIR /dhclient-%s.conf, device-ip_iface);
 #endif
 
 	if (!orig) {
-		nm_warning (%s: not enough memory for dhclient options., device-iface);
+		nm_warning (%s: not enough memory for dhclient options., device-ip_iface);
 		return FALSE;
 	}
 
-	tmp = g_strdup_printf (nm-dhclient-%s.conf, device-iface);
+	tmp = g_strdup_printf (nm-dhclient-%s.conf, device-ip_iface);
 	device-conf_file = g_build_filename (/var, run, tmp, NULL);
 	g_free (tmp);
 
@@ -174,7 +174,7 @@
 
 	if (!g_file_get_contents (orig, contents, NULL, error)) {
 		nm_warning (%s: error reading dhclient configuration %s: %s,
-		device-iface, orig, error-message);
+		device-ip_iface, orig, error-message);
 		g_error_free (error);
 		goto out;
 	}
@@ -185,7 +185,7 @@
 		success = TRUE;
 	else {
 		nm_warning (%s: error creating dhclient configuration: %s,
-		device-iface, error-message);
+		device-ip_iface, error-message);
 		g_error_free (error);
 	}
 
@@ -218,15 +218,15 @@
 		goto out;
 	}
 
-	device-pid_file = get_pidfile_for_iface (device-iface);
+	device-pid_file = get_pidfile_for_iface (device-ip_iface);
 	if (!device-pid_file) {
-		nm_warning (%s: not enough memory for dhclient options., device-iface);
+		nm_warning (%s: not enough memory for dhclient options., device-ip_iface);
 		goto out;
 	}
 
-	device-lease_file = get_leasefile_for_iface (device-iface);
+	device-lease_file = get_leasefile_for_iface (device-ip_iface);
 	if (!device-lease_file) {
-		nm_warning (%s: not enough memory for dhclient options., device-iface);
+		nm_warning (%s: not enough memory for dhclient options., device-ip_iface);
 		goto out;
 	}
 
@@ -238,7 +238,7 @@
 		unsigned long int tmp = strtoul (pid_contents, NULL, 10);
 
 		if (!((tmp == ULONG_MAX)  (errno == ERANGE)))
-			nm_dhcp_client_stop (device-iface, (pid_t) tmp);
+			nm_dhcp_client_stop (device-ip_iface, (pid_t) tmp);
 		remove (device-pid_file);
 	}
 
@@ -259,7 +259,7 @@
 	g_ptr_array_add (dhclient_argv, (gpointer) -cf);	/* Set interface config file */
 	g_ptr_array_add (dhclient_argv, (gpointer) device-conf_file);
 
-	g_ptr_array_add (dhclient_argv, (gpointer) device-iface);
+	g_ptr_array_add (dhclient_argv, (gpointer) device-ip_iface);
 	g_ptr_array_add (dhclient_argv, NULL);
 
 	if (!g_spawn_async (NULL, (char **) dhclient_argv-pdata, NULL, G_SPAWN_DO_NOT_REAP_CHILD,
Index: src/dhcp-manager/nm-dhcp-manager.c
===
--- src/dhcp-manager/nm-dhcp-manager.c	(revision 4136)
+++ src/dhcp-manager/nm-dhcp-manager.c	(working copy)
@@ -172,7 +172,7 @@
 	nm_dhcp_device_watch_cleanup (device);
 
 	if (device-pid)
-		nm_dhcp_client_stop 

Re: knetworkmanager stopped working

2008-10-02 Thread Helmut Schaa
Am Donnerstag, 2. Oktober 2008 schrieb Anton Moiseev:
 I have posted this problem to opensuse mailing list, and then to the
 kde-linux mailing list, but there were no response, and this list
 seems to be the most relevant.

KNetworkManager list:
https://mail.kde.org/mailman/listinfo/kde-networkmanager

 I have Opensuse 11 with kde4 and knetworkmanager 0.7r826733 from
 opensuse repo and knetworkmanager stopped working for me.

I'm pretty sure you've updated NM and did not update KNM or vice versa.
What does the NM log (/var/log/NetworkManager) tells you?

Helmut
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Problems with Networkmanager 0.7

2008-10-02 Thread Ronald Wiplinger (Lists)
Dan Williams wrote:


Dan,

is here the right place to talk about Networkmanager 0.7?

If so, I am happy that the latest version I received manages to connect
to the Internet via Wireless AND Ethernet AND I can open applications.
However, it does not allow me to connect via E220, the main reason I
switched to a pre-release at all.

From your lines I guess that Alexander is working on the
Networkmanager, but I have not seen a message here on the list. I don't
want to disturb him, but I can offer to test for him, since I really use
Ethernet, wireless and E220, depending where I am working with my EeePC
(Ubuntu SD card)

bye

Ronald

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: knetworkmanager stopped working

2008-10-02 Thread Helmut Schaa
Hi,

Am Donnerstag, 2. Oktober 2008 schrieb Anton Moiseev:
 Oct  2 18:39:41 benderamp-hp NetworkManager: WARN
 wait_for_connection_expired(): Connection (2)
 /org/freedesktop/NetworkManagerSettings/Connection/1 failed to
 activate (timeout): (0) Connection was not provided by any settings
 service

Looks like a configuration mismatch between KNM and NM to me. You could
try to recreate your connections.

Helmut
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: NetworkManager-list Digest, Vol 49, Issue 2

2008-10-02 Thread Alexander Sack
On Wed, Oct 01, 2008 at 04:14:33PM -0700, Howard Chu wrote:
 Message: 5
 Date: Wed, 1 Oct 2008 23:58:22 +0200
 From: Alexander Sack[EMAIL PROTECTED]
 Subject: [PATCH] hostname support for ifupdown plugin + allow
  read-only   hostname system provider + move nm_inotify_helper to 
 plugin
  independent place (system-settings/src/)
 To: networkmanager-list@gnome.org
 Message-ID:[EMAIL PROTECTED]
 Content-Type: text/plain; charset=us-ascii

 Implement system hostname support for debian/ubuntu

 Fix only system-setting plugins with 
 NM_SYSTEM_CONFIG_INTERFACE_CAP_MODIFY_HOSTNAME
 are considered a valid hostname provider

 Make nm-inotify-helper from ifcfg-fedora plugin usable
 for other plugins too

 Is any of that really necessary? Any tool that rewrites /etc/hostname is 
 also going to already call sethostname(); shouldn't you only need to call 
 gethostname() to get NM in sync? Why go thru the hassle of opening and 
 reading a file and calling sethostname() to tell the kernel what it 
 already knows?

Hmm ...

there is nothing on debian that enforces that sethostname and
/etc/hostname stay in sync.

Also tools that dont rewrite /etc/hostname include NM itself and
things like vi /etc/hostname or echo newhostname  /etc/hostname.

So the next step is probably to add write support for /etc/hostname to
the ifupdown plugin.

 - Alexander

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Problems with Networkmanager 0.7

2008-10-02 Thread Dan Williams
On Thu, 2008-10-02 at 23:02 +0800, Ronald Wiplinger (Lists) wrote:
 Dan Williams wrote:
 
 
 Dan,
 
 is here the right place to talk about Networkmanager 0.7?
 
 If so, I am happy that the latest version I received manages to
 connect to the Internet via Wireless AND Ethernet AND I can open
 applications. However, it does not allow me to connect via E220, the
 main reason I switched to a pre-release at all.

What's the issue with the E220 again?

 From your lines I guess that Alexander is working on the
 Networkmanager, but I have not seen a message here on the list. I
 don't want to disturb him, but I can offer to test for him, since I
 really use Ethernet, wireless and E220, depending where I am working
 with my EeePC (Ubuntu SD card)

Alexander Sack, the Ubuntu NetworkManager package maintainer.

Dan


 bye
 
 Ronald
 

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Which AP is chosen when several are found for the same SSID?

2008-10-02 Thread Dan Williams
On Wed, 2008-10-01 at 19:14 -0400, Jose Aliste wrote:
 Hi all, 
 
 I want to ask the question in the subject: 
 Which AP is chosen when several are found for the same SSID?  
 I ask this because I see three AP from mi wireless network at my
 office. Two of them are 802.11G AP are the other one is only
 802.11B the signal for the slow one is better(it is nearer) and NM
 always connects to it. However, I would like to NM to connect to one
 of the others because even with less signal the connection is
 better( 33mb/s against the 11mb/s of  a b connection!).

At this moment, this is left up to the driver and the supplicant.  The
supplicant will apparently choose the AP with the best signal strength
(since the scan results for the same SSID are sorted by signal
strength), but the driver can also choose to roam from AP to AP based on
other criteria.

 So, how can I tell NM to use the AP I need ?

You can try to set the BSSID in the connection editor to lock it onto
one of the APs, but the driver has the discretion to ignore that and
roam to an AP it thinks is better.  We don't yet have the facility to
lock to 802.11g at _any_ level of the stack, not just NetworkManager.
You could try setting the data rate, but that doesn't always do what you
want since you can only set it to one value, and the card would be
unable to rate-scale based on signal quality of the locked AP.

In short, can't really be done, but this is only partly NM's fault.
There's a lot more work in the stack from drivers, to WEXT, to
wpa_supplicant to make sure this works the way you want it.

Dan


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: NetworkManager-list Digest, Vol 49, Issue 2

2008-10-02 Thread Dan Williams
On Wed, 2008-10-01 at 16:14 -0700, Howard Chu wrote:
  Message: 5
  Date: Wed, 1 Oct 2008 23:58:22 +0200
  From: Alexander Sack[EMAIL PROTECTED]
  Subject: [PATCH] hostname support for ifupdown plugin + allow
  read-only   hostname system provider + move nm_inotify_helper to 
  plugin
  independent place (system-settings/src/)
  To: networkmanager-list@gnome.org
  Message-ID:[EMAIL PROTECTED]
  Content-Type: text/plain; charset=us-ascii
 
  Implement system hostname support for debian/ubuntu
 
  Fix only system-setting plugins with 
  NM_SYSTEM_CONFIG_INTERFACE_CAP_MODIFY_HOSTNAME
  are considered a valid hostname provider
 
  Make nm-inotify-helper from ifcfg-fedora plugin usable
  for other plugins too
 
 Is any of that really necessary? Any tool that rewrites /etc/hostname is also 
 going to already call sethostname(); shouldn't you only need to call 
 gethostname() to get NM in sync? Why go thru the hassle of opening and 
 reading 
 a file and calling sethostname() to tell the kernel what it already knows?

It's a matter of persistent storage... when you reboot you'd probably
like to have the hostname come back as what you set it before, and that
means you have to store the persistent hostname somewhere on the
filesystem...

But it's just good programming to ensure that when that file changes,
updates are recognized, because whatever wrote that file out doesn't
_have_ to call sethostname(2).

Dan

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list