NM doesn't handle two networks with same AP MAC Address?
I've got a D-Link A/B/G Access point that happens to use the same MAC address for the A device _and_ the B/G device. I have different network names for the two networks, foo-a for the A network and foo for the b/g network. Unfortunately this confuses NM. iwlist ath0 scan gives me: ath0 Scan completed : Cell 01 - Address: 00:0F:3D:EE:5C:DC ESSID:foo-a Mode:Master Frequency:5.32 GHz (Channel 64) Quality=31/94 Signal level=-64 dBm Noise level=-95 dBm Encryption key:on ... Extra:bcn_int=100 Cell 02 - Address: 00:0F:3D:EE:5C:DC ESSID:foo Mode:Master Frequency:2.412 GHz (Channel 1) Quality=35/94 Signal level=-60 dBm Noise level=-95 dBm Encryption key:on ... I'm connected to the foo-a network: iwconfig ath0 ath0 IEEE 802.11a ESSID:foo-a Mode:Managed Frequency:5.32 GHz Access Point: 00:0F:3D:EE:5C:DC Bit Rate:48 Mb/s Tx-Power:50 dBm Sensitivity=0/3 But when I mouse over the NMInfo Icon it (incorrectly) says: Wireless network connection to 'foo' (20%) And if I left-click, foo is listed twice. It feels like NM keeps track of APs solely by MAC Address instead of a tuple of MAC Address and Frequency (which would clearly solve this problem). Suggestions? Comments? Internally it seems to be doing the right thing at some level. nmtest shows the following: NM Status: 'connected' Active device: '/org/freedesktop/NetworkManager/Devices/ath0' Active device name: 'ath0' Devices: /org/freedesktop/NetworkManager/Devices/eth0 Device type: wired /org/freedesktop/NetworkManager/Devices/ath0 Device type: wireless Strength: 17% Active Network: '/org/freedesktop/NetworkManager/Devices/ath0/Networks/foo-a' Networks: /org/freedesktop/NetworkManager/Devices/ath0/Networks/foo (foo) Strength: 36% /org/freedesktop/NetworkManager/Devices/ath0/Networks/foo-a (foo) Strength: 36% /org/freedesktop/NetworkManager/Devices/ath0/Networks/unclemarcel (unclemarcel) Strength: 6% /org/freedesktop/NetworkManager/Devices/ath0/Networks/WholeHealth (WholeHealth) Strength: 12% /org/freedesktop/NetworkManager/Devices/ath0/Networks/Home wireless (Home wireless) Strength: 7% What I don't understand is why it's showing foo (foo) and foo-a (foo). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] make Wired option a radio
if i have 2 network adapters why wouldn't i be able to use both of them
at the same time? windows boxes allow it.
Robert Love wrote:
We're back!
I've mentioned before (see email subj the wired checkbox.) that the
Wired menu items don't make sense as check boxes. You cannot unselect
it, it is a mutually exclusive option with the wireless radio buttons,
and so on. The behavior is identical to a radio button.
Attached patch makes the Wired menu items radio buttons, part of the
same group as the wireless networks.
May I apply?
Robert Love
Index: gnome/applet/applet.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/applet.c,v
retrieving revision 1.18
diff -u -u -r1.18 applet.c
--- gnome/applet/applet.c 27 Jun 2005 14:00:58 - 1.18
+++ gnome/applet/applet.c 30 Jun 2005 14:48:33 -
@@ -1283,9 +1284,11 @@
{
NMWiredMenuItem *item = wired_menu_item_new ();
GtkCheckMenuItem *gtk_item =
wired_menu_item_get_check_item (item);
-wired_menu_item_update (item, device, n_devices);
+
+ wired_menu_item_update (item, device, n_devices);
if (network_device_get_active (device))
gtk_check_menu_item_set_active (gtk_item, TRUE);
+ gtk_check_menu_item_set_draw_as_radio (gtk_item, TRUE);
g_object_set_data (G_OBJECT (gtk_item), device, g_strdup (network_device_get_nm_path (device)));
g_object_set_data (G_OBJECT (gtk_item), nm-item-data,
item);
@@ -1300,6 +1303,7 @@
{
NMWirelessMenuItem *item = wireless_menu_item_new ();
GtkMenuItem *gtk_item = wireless_menu_item_get_item
(item);
+
wireless_menu_item_update (item, device, n_devices);
g_object_set_data (G_OBJECT (gtk_item), device, g_strdup (network_device_get_nm_path (device)));
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
--
Jason Mellein, 1st Lt, USAF
MIT Leaders for Manufacturing Fellow – Class of 2007
MBA Candidate, Sloan School of Management
MS Candidate, Engineering Systems
e: [EMAIL PROTECTED]
m: 617.803.6955
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: suspend/resume wired
On Thu, 2005-06-30 at 16:50 +0100, Bastien Nocera wrote: I'm sorry, I wasn't commenting on the patch, just wondering whether those cases were covered by it. Oh, the current sleep/wake behavior should handle those fine. I don't think my patch should change the behavior there. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: suspend/resume wired
Yes, our patches are the same. I agree that these patches may not be the best solution. When NM wakes it jumps to the code that 'searches for connections'. The first thing that should happen is that all available devices should be brought up before the search begins. NM is not bring up wired devices, only wireless. If the wired device is not up, NM cannot detect a wired link so it assumes that no wire is plugged in. I expect that Dan Williams may have the answer here. I believe NM is releasing DHCP leases on sleep so there is no issue of leases expiring while NM is asleep. Bill Moss Clemson Robert Love wrote: On Thu, 2005-06-30 at 09:03 -0400, Bill Moss wrote: After an acpi suspend/resume, both e1000 and ipw2200 drivers are loaded but the wired interface is not up. The patch fixes this by bringing up all devices when NM wakes. Ha! I spent the CVS outage tracking this down and came up with a nearly identical patch (see attached). I'm not 100% sure it is right, because wireless comes up fine without manually pushing it up. So that makes me think wired should, too. Or maybe wireless isn't obeying the down and this patch is right and another fix is needed elsewhere. Not sure. I do know that it solves my problem and fixes the bug. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] make Wired option a radio
On Thu, 2005-06-30 at 10:56 -0400, Jason Mellein wrote: if i have 2 network adapters why wouldn't i be able to use both of them at the same time? windows boxes allow it. I don't think the current UI allows this (and if it does, the UI is then broken in other ways). The radio buttons just make the UI look the way it acts. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: suspend/resume wired
On Thu, 2005-06-30 at 12:05 -0400, Bill Moss wrote: Yes, our patches are the same. I agree that these patches may not be the best solution. When NM wakes it jumps to the code that 'searches for connections'. The first thing that should happen is that all available devices should be brought up before the search begins. NM is not bring up wired devices, only wireless. If the wired device is not up, NM cannot detect a wired link so it assumes that no wire is plugged in. I expect that Dan Williams may have the answer here. Ahah! Why are wireless devices coming up but not wired? That is the crux of my uncertainty. I believe NM is releasing DHCP leases on sleep so there is no issue of leases expiring while NM is asleep. Agreed. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: suspend/resume wired
Quoting Robert Love [EMAIL PROTECTED]: On Thu, 2005-06-30 at 12:05 -0400, Bill Moss wrote: Yes, our patches are the same. I agree that these patches may not be the best solution. When NM wakes it jumps to the code that 'searches for connections'. The first thing that should happen is that all available devices should be brought up before the search begins. NM is not bring up wired devices, only wireless. If the wired device is not up, NM cannot detect a wired link so it assumes that no wire is plugged in. I expect that Dan Williams may have the answer here. Ahah! Why are wireless devices coming up but not wired? That is the crux of my uncertainty. In my case the wireless comes up because of the wireless hotplug support, but wired interfaces aren't part of that configuration. At least I've notices that my ath0 device kick off a dhclient on resume on my FC3 machine. I believe NM is releasing DHCP leases on sleep so there is no issue of leases expiring while NM is asleep. Agreed. Robert Love -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
suspend/resume wired
The patch below fixes the problem that I had with suspend to ram. When
it starts, NM normally brings up both wired and wireless interfaces and
they remain up. After a suspend/resume, the wired inteface is not
brought up by the system or by NM but the driver is loaded. This causes
NM to default to a wireless connection even if a wire is plugged in.
Setup: IBM T42, network drivers: e1000, ipw2200, FC4 updated.
Acpi suspend/resume script
#!/bin/sh
/usr/bin/dbus-send --system --dest=org.freedesktop.NetworkManager
--type=method_call /org/freedesktop/NetworkManager
org.freedesktop.NetworkManager.sleep
/sbin/hwclock --systohc
echo -n mem /sys/power/state
/sbin/hwclock --hctosys
/usr/bin/dbus-send --system --dest=org.freedesktop.NetworkManager
--type=method_call /org/freedesktop/NetworkManager
org.freedesktop.NetworkManager.wake
After an acpi suspend/resume, both e1000 and ipw2200 drivers are loaded
but the wired interface is not up. The patch fixes this by bringing up
all devices when NM wakes.
I am not sure if this is the best solution, but it works.
patch fot HEAD 1.409
___
--- nm-dbus-nm.c_orig2005-06-29 21:23:37.0 -0400
+++ nm-dbus-nm.c2005-06-29 21:42:36.0 -0400
@@ -433,6 +433,16 @@
{
app_data-asleep = FALSE;
+/* Physically up all devices */
+nm_lock_mutex (app_data-dev_list_mutex, __FUNCTION__);
+for (elt = app_data-dev_list; elt; elt = g_slist_next
(elt))
+{
+NMDevice*dev = (NMDevice *)(elt-data);
+
+nm_device_bring_up (dev);
+}
+nm_unlock_mutex (app_data-dev_list_mutex, __FUNCTION__);
+
nm_schedule_state_change_signal_broadcast (app_data);
nm_policy_schedule_device_change_check (data-data);
}
--
Bill Moss
Professor, Mathematical Sciences
Clemson University
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[patch] connection information dialog, updated.
Here is a slightly more stetic version of the connection information
dialog, rediffed against current CVS.
Any consensus on this? It is pretty simple and definitely needed, in my
opinion. May I commit?
Robert Love
? gnome/applet/wireless-applet.gladep
Index: gnome/applet/applet.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/applet.c,v
retrieving revision 1.17
diff -u -u -r1.17 applet.c
--- gnome/applet/applet.c 23 Jun 2005 20:34:57 - 1.17
+++ gnome/applet/applet.c 26 Jun 2005 04:09:09 -
@@ -33,6 +33,7 @@
#include string.h
#include stdlib.h
+#include unistd.h
#include sys/types.h
#include sys/wait.h
#include ctype.h
@@ -41,6 +42,12 @@
#include math.h
#include dirent.h
#include time.h
+#include sys/ioctl.h
+#include sys/socket.h
+#include netinet/in.h
+#include arpa/inet.h
+#include sys/un.h
+#include net/if.h
#include gtk/gtk.h
#include glib/gi18n.h
@@ -159,8 +166,181 @@
return obj;
}
+static GtkWidget * get_label (GtkWidget *info_dialog, GladeXML *xml, const char *name)
+{
+ GtkWidget *label;
+
+ if (xml != NULL)
+ {
+ label = glade_xml_get_widget (xml, name);
+ g_object_set_data (G_OBJECT (info_dialog), name, label);
+ }
+ else
+ label = g_object_get_data (G_OBJECT (info_dialog), name);
+
+ return label;
+}
+
+static void nmwa_show_socket_err (GtkWidget *info_dialog, const char *err)
+{
+ GtkWidget *error_dialog;
+ char *msg;
+
+ msg = g_strdup_printf (span weight=\bold\ size=\larger\%s/span\n\n%s,
+ _(Error displaying connection information: ), err);
+ error_dialog = gtk_message_dialog_new_with_markup (GTK_WINDOW (info_dialog),
+ 0, GTK_MESSAGE_ERROR,
+ GTK_BUTTONS_OK, msg);
+ gtk_dialog_run (GTK_DIALOG (error_dialog));
+ gtk_widget_destroy (error_dialog);
+ g_free (msg);
+}
+
+static gboolean nmwa_update_info (NMWirelessApplet *applet)
+{
+ GtkWidget *info_dialog;
+ char *addr = NULL, *mask = NULL, *broadcast = NULL;
+ char *dest = NULL, *mac = NULL, *iface_and_type = NULL;
+ GtkWidget *label;
+ struct ifreq ifr;
+ int fd, flags;
+ gboolean ret_val = TRUE;
+ const char *iface;
+ NetworkDevice *dev;
+ gboolean ret = TRUE;
+
+ info_dialog = glade_xml_get_widget (applet-info_dialog_xml, info_dialog);
+ if (!info_dialog)
+ {
+ char *err = g_strdup (_(Could not find some required resources (the glade file)!));
+ nmwa_show_socket_err (info_dialog, err);
+ g_free (err);
+ return FALSE;
+ }
+
+ dev = nmwa_get_first_active_device (applet-gui_device_list);
+ iface = network_device_get_iface (dev);
+ if (!dev || !iface)
+ {
+ char *err = g_strdup (_(No active connections!));
+ nmwa_show_socket_err (info_dialog, err);
+ g_free (err);
+ return FALSE;
+ }
+
+ fd = socket (AF_INET, SOCK_DGRAM, 0);
+ if (fd 0)
+ {
+ char *err = g_strdup (_(Could not open socket!));
+ nmwa_show_socket_err (info_dialog, err);
+ g_free (err);
+ return FALSE;
+ }
+
+ ifr.ifr_addr.sa_family = AF_INET;
+
+ g_strlcpy (ifr.ifr_name, iface, sizeof (ifr.ifr_name));
+ if (ioctl (fd, SIOCGIFADDR, ifr) == 0)
+ addr = g_strdup (inet_ntoa (((struct sockaddr_in *) ifr.ifr_addr)-sin_addr));
+
+ g_strlcpy (ifr.ifr_name, iface, sizeof (ifr.ifr_name));
+ if (ioctl (fd, SIOCGIFFLAGS, ifr) 0)
+ {
+ char *err = g_strdup (_(SIOCGIFFLAGS failed on socket!));
+ nmwa_show_socket_err (info_dialog, err);
+ g_free (err);
+ ret = FALSE;
+ goto out;
+ }
+ flags = ifr.ifr_flags;
+
+ g_strlcpy (ifr.ifr_name, iface, sizeof (ifr.ifr_name));
+ if (flags IFF_BROADCAST ioctl (fd, SIOCGIFBRDADDR, ifr) == 0)
+ broadcast = g_strdup (inet_ntoa (((struct sockaddr_in *) ifr.ifr_broadaddr)-sin_addr));
+
+ g_strlcpy (ifr.ifr_name, iface, sizeof (ifr.ifr_name));
+ if (ioctl (fd, SIOCGIFNETMASK, ifr) == 0)
+ mask = g_strdup (inet_ntoa (((struct sockaddr_in *) ifr.ifr_addr)-sin_addr));
+
+ g_strlcpy (ifr.ifr_name, iface, sizeof (ifr.ifr_name));
+ if (flags IFF_POINTOPOINT ioctl (fd, SIOCGIFDSTADDR, ifr) == 0)
+ dest = g_strdup (inet_ntoa (((struct sockaddr_in *) ifr.ifr_dstaddr)-sin_addr));
+
+ g_strlcpy (ifr.ifr_name, iface, sizeof (ifr.ifr_name));
+ if (ioctl (fd, SIOCGIFHWADDR, ifr) == 0)
+ mac = g_strdup_printf (%2.2X:%2.2X:%2.2X:%2.2X:%2.2X:%2.2X,
+ (unsigned char) ifr.ifr_hwaddr.sa_data[0],
+ (unsigned char) ifr.ifr_hwaddr.sa_data[1],
+ (unsigned char) ifr.ifr_hwaddr.sa_data[2],
+ (unsigned char) ifr.ifr_hwaddr.sa_data[3],
+ (unsigned char) ifr.ifr_hwaddr.sa_data[4],
+ (unsigned char) ifr.ifr_hwaddr.sa_data[5]);
+
+ label = get_label (info_dialog, applet-info_dialog_xml, label-interface);
+ gtk_label_set_text (GTK_LABEL (label), iface);
+ if (network_device_is_wired (dev))
+ iface_and_type = g_strdup_printf (_(Wired Ethernet (%s)), iface);
+ else
+ iface_and_type = g_strdup_printf (_(Wireless Ethernet (%s)), iface);
+ gtk_label_set_text (GTK_LABEL (label), iface_and_type);
+
+ label = get_label (info_dialog, applet-info_dialog_xml, label-ip-address);
+
Re: [patch] connection information dialog, updated.
On Thu, 2005-06-30 at 14:31 -0400, Dan Williams wrote: On Thu, 2005-06-30 at 12:36 -0400, Robert Love wrote: char *err = g_strdup (_(SIOCGIFFLAGS failed on socket!)); Figure out a better error message for this that doesn't reference sockets or IFFLAGS, and then feel free to commit :) Such demands! I dove to the depths of my creativity and found a better error message. Applied. Also applied the wake-from-sleep interface patch. Thanks, Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Get a link-local IP when wired and DHCP fails
Heya,
Here's a (small) patch I wrote after a discussion with Dan.
The use-cases are:
- Plug my laptop and desktop together, via a crossed-cable or some cheap
hub, they both get a nice little IP address, and they can talk.
- Create an ad-hoc non-encrypted network on my desktop, join in on my
laptop, can't get a DHCP address (not running that kind of server on my
desktop, too lazy), gets a nice little IP address, and they can talk.
The only case left is when we have an ad-hoc encrypted network, as it's
not really possible to know whether the DHCP request failure is due to
no-DHCP server, or wrong WEP key.
I remember Apple's solution to a similar problem (detecting whether a
WEP key is accepted) being pretty ugly and Airport AP specific, but I
don't quite remember the details.
Any comments?
---
Bastien Nocera [EMAIL PROTECTED]
Index: NetworkManagerDevice.c
===
RCS file: /cvs/gnome/NetworkManager/src/NetworkManagerDevice.c,v
retrieving revision 1.145
diff -u -p -r1.145 NetworkManagerDevice.c
--- NetworkManagerDevice.c 30 Jun 2005 14:28:52 - 1.145
+++ NetworkManagerDevice.c 30 Jun 2005 18:55:42 -
@@ -2751,9 +2751,20 @@ static gboolean nm_device_activate_stage
if (ap nm_ap_get_user_created (ap))
ip4_config = nm_device_new_ip4_autoip_config (dev);
- else if (nm_device_get_use_dhcp (dev))
+ else if (nm_device_get_use_dhcp (dev)) {
ip4_config = nm_dhcp_manager_get_ip4_config (data-dhcp_manager, req);
- else
+
+ /* Couldn't get a DHCP address, so we'll try link-local
+ * for wired, and wireless non-encrypted networks, as if
+ * we have encryption on wireless, it could be a wrong
+ * WEP key causing the failure
+ */
+ if (ip4_config == NULL nm_device_is_wired (dev)) {
+ ip4_config = nm_device_new_ip4_autoip_config (dev);
+ } else if (ip4_config == NULL nm_device_is_wireless (dev) == FALSE nm_ap_get_encrypted (ap) == FALSE) {
+ ip4_config = nm_device_new_ip4_autoip_config (dev);
+ }
+ } else
ip4_config = nm_system_device_new_ip4_system_config (dev);
if (nm_device_activation_should_cancel (dev))
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM-applet remark
Hi, If we have only wired devices, it does not make sense to have in the nm-applet menu Stop all wireless devices or Wireless network discovery. Thanks, Paul ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Get a link-local IP when wired and DHCP fails
On Thu, 2005-06-30 at 16:19 -0400, Dan Williams wrote:
On Thu, 2005-06-30 at 20:14 +0100, Bastien Nocera wrote:
+ } else if (ip4_config == NULL nm_device_is_wireless
(dev) == FALSE nm_ap_get_encrypted (ap) == FALSE) {
You probably want this to be
nm_device_is_wireless (dev) == TRUE
right?
Damn, three lines and I manage to screw it up (that's a yes).
---
Bastien Nocera [EMAIL PROTECTED]
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] make Wired option a radio
On Thu, 30 Jun 2005 12:08:43 -0400, Robert Love wrote: On Thu, 2005-06-30 at 10:56 -0400, Jason Mellein wrote: if i have 2 network adapters why wouldn't i be able to use both of them at the same time? windows boxes allow it. I don't think the current UI allows this (and if it does, the UI is then broken in other ways). The radio buttons just make the UI look the way it acts. Robert Love I think of a better idea: Why not just initialize all wired interfaces that have link and only switch the corresponding default gateway when switching the default wired interface ? This way we will have valid IP's on all wired interfaces which IMO is better. The valid IP's can be obtained via dhcp, static, or zeroconf. And we can cache the default gw for each wired network. Then, if we manually change the default wired network, we just modify the default gateway, because all the IP's are already in place. This will improve convergence too, because the time to switch is shorter. Thanks, Paul ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: unable to get ip with dhcp
Found the following error in syslog: dhcdbd: Unrequested down ?:2 I'm unsing dhcdbd version 1.4 on gentoo. Joris On Thu, 2005-06-30 at 09:13 -0400, Derek Atkins wrote: :: J.Vuffray :: [EMAIL PROTECTED] writes: Acces point: Linksys wrt54gs, using wep 128b key, broadcast disabled. Interface: Intel 2200BG with driverloader from linuxant. Any reason you don't use the ipw2200 driver? -derek -- :: J.Vuffray :: [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Get a link-local IP when wired and DHCP fails
On Thu, 2005-06-30 at 20:14 +0100, Bastien Nocera wrote:
Any comments?
When I don't have a DHCP server, I get failure on Stage 3 (start of DHCP
transaction) and never make it to Stage 4. So, this isn't working for
me. Debugging ...
And, attached patch fixes the typo that Dan pointed out and adds an
nm_info for verbosity.
Robert Love
Index: src/NetworkManagerDevice.c
===
RCS file: /cvs/gnome/NetworkManager/src/NetworkManagerDevice.c,v
retrieving revision 1.145
diff -u -u -r1.145 NetworkManagerDevice.c
--- src/NetworkManagerDevice.c 30 Jun 2005 14:28:52 - 1.145
+++ src/NetworkManagerDevice.c 30 Jun 2005 21:02:38 -
@@ -2752,7 +2752,23 @@
if (ap nm_ap_get_user_created (ap))
ip4_config = nm_device_new_ip4_autoip_config (dev);
else if (nm_device_get_use_dhcp (dev))
+ {
+ /*
+ * Could not get a DHCP address, so we'll try link-local for
+ * for wired, and wireless non-encrypted networks, because
+ * if we have encryption on wireless, it could be a wrong
+ * WEP key causing the failure.
+ */
ip4_config = nm_dhcp_manager_get_ip4_config (data-dhcp_manager, req);
+ if (ip4_config == NULL)
+ {
+ if (nm_device_is_wired (dev) || (nm_device_is_wireless (dev) == TRUE nm_ap_get_encrypted (ap) == FALSE))
+ {
+nm_info (No DHCP reply received. Automatically obtaining IP.);
+ip4_config = nm_device_new_ip4_autoip_config (dev);
+ }
+ }
+ }
else
ip4_config = nm_system_device_new_ip4_system_config (dev);
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: gentoo patch
I will try the patch when I get home and see if I can get it working... Did you also make an ebuild? Magnus -Original Message- From: Jos Dehaes [EMAIL PROTECTED] To: networkmanager-list@gnome.org Date: Mon, 27 Jun 2005 17:08:04 +0200 Subject: gentoo patch Hi, I patched the gentoo backend to compile at least (based on the Suse version). But NetworkManager still won't work. Wired (8139too), nor wireless (prism54). Also, I get no GUI feedback at all, how should I start NetworkManager (I used /etc/init.d/NetworkManager start)? I can send logs if anyone is interested in helping out. cheers, Jos Please CC: me when replying ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: gentoo patch
On Tue, 2005-06-28 at 18:16 +0200, Magnus Ottosson wrote: I will try the patch when I get home and see if I can get it working... Did you also make an ebuild? Magnus -Original Message- From: Jos Dehaes [EMAIL PROTECTED] To: networkmanager-list@gnome.org Date: Mon, 27 Jun 2005 17:08:04 +0200 Subject: gentoo patch Hi, I patched the gentoo backend to compile at least (based on the Suse version). But NetworkManager still won't work. Wired (8139too), nor wireless (prism54). Also, I get no GUI feedback at all, how should I start NetworkManager (I used /etc/init.d/NetworkManager start)? I can send logs if anyone is interested in helping out. You most likely need dhclient with redhat patches (patches not in portage) and dhcdbd. Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Get a link-local IP when wired and DHCP fails
On Thu, 2005-06-30 at 20:14 +0100, Bastien Nocera wrote:
+ } else if (ip4_config == NULL nm_device_is_wireless
(dev) == FALSE nm_ap_get_encrypted (ap) == FALSE) {
You probably want this to be
nm_device_is_wireless (dev) == TRUE
right?
Dan
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: suspend/resume wired
On Thu, 2005-06-30 at 10:47 -0400, Robert Love wrote: On Thu, 2005-06-30 at 09:03 -0400, Bill Moss wrote: After an acpi suspend/resume, both e1000 and ipw2200 drivers are loaded but the wired interface is not up. The patch fixes this by bringing up all devices when NM wakes. Ha! I spent the CVS outage tracking this down and came up with a nearly identical patch (see attached). I'm not 100% sure it is right, because wireless comes up fine without manually pushing it up. So that makes me think wired should, too. Or 2 Stupid questions: - Did you try this with the DHCP lease having expired? - Did you try this with a different wireless network? (ie. changing between 2 known and trusted networks, in different locations) maybe wireless isn't obeying the down and this patch is right and another fix is needed elsewhere. Cheers --- Bastien Nocera [EMAIL PROTECTED] Then Robert Shaw got his willy out and peed on me. -- Nick Nolte ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
