Re: NM 0.9.1 failing to get SSIDs with WPA supplicant 0.7.3
On 09/09/2011 04:42 PM, Lamarque Vieira Souza wrote: Em Friday 09 September 2011, iain escreveu: > Hi, > > I'm running NetworkManager 0.9.1 from git and wpa_supplicant 0.7.3 on a > custom distro (based from poky). When I run nmcli dev wifi, the access > points appear but everything seems to be screwed up. Hi, have you patched wpa_supplicant-0.7.3 to work with NM-0.9? If not then this is your problem: https://bugzilla.gnome.org/show_bug.cgi?id=644634 . The patch is also there. Yes, that patch has been applied. thanks, iain ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Most recent NM before udev?
What is the most recent version/branch of NM that doesn't require udev? TIA, David Röthlisberger. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 0.9.1 failing to get SSIDs with WPA supplicant 0.7.3
Em Friday 09 September 2011, iain escreveu: > Hi, > > I'm running NetworkManager 0.9.1 from git and wpa_supplicant 0.7.3 on a > custom distro (based from poky). When I run nmcli dev wifi, the access > points appear but everything seems to be screwed up. Hi, have you patched wpa_supplicant-0.7.3 to work with NM-0.9? If not then this is your problem: https://bugzilla.gnome.org/show_bug.cgi?id=644634 . The patch is also there. > SSID BSSID MODE > FREQ RATE SIGNAL SECURITY ACTIVE > 8C0300010002:FE:F4:50:A9:50 Infrastructure 2 > MHz63 MB/s75 WPA2 no > 8C0600010000:FE:F4:50:A9:50 Infrastructure 2 > MHz 1 MB/s 75 -- no > 8C0600010000:FE:F4:59:01:A0 Infrastructure 2 > MHz 0 MB/s 20 -- no > 8C0300010002:FE:F4:50:A9:50 Infrastructure 2 > MHz 0 MB/s 72 -- no > > The driver appears to be working, iwlist gives all the details I expect > and comparing the output below with the NM output shows what is wrong. > > iwlist tiwlan0 scanning > tiwlan0 Scan completed : >Cell 01 - Address: 12:FE:F4:50:A9:50 > ESSID:"BTFON" > Protocol:IEEE 802.11 BG > Mode:Managed > Frequency:2.462 MHz > Signal level=-56 dBm > Encryption key:off > Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s >9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s >48 Mb/s; 54 Mb/s; 6.5 Mb/s; 13 Mb/s; 19.5 > Mb/s >26 Mb/s; 39 Mb/s; 52 Mb/s; 58.5 Mb/s; 65 > Mb/s > Extra:Bcn int = 100 ms > IE: Unknown: 00054254464F4E > IE: Unknown: 010882848B960C121824 > IE: Unknown: 03010B > IE: Unknown: 2A0100 > IE: Unknown: 32043048606C > IE: Unknown: > 2D1AAC011B0 > 0 > IE: Unknown: > 3D160B08000 > 0 > IE: Unknown: 4A0E14000A002C01C800140005001900 > IE: Unknown: 7F0101 > IE: Unknown: > DD180050F2020101890003A427A442435E00623 > 22F00 > IE: Unknown: > DD1E00904C33AC011B0 > 0 > IE: Unknown: > DD1A00904C340B08000 > 0 > IE: Unknown: DD0900037F0101FF7F >Cell 02 - Address: 02:FE:F4:50:A9:50 > ESSID:"BTOpenzone" > Protocol:IEEE 802.11 BG > Mode:Managed > Frequency:2.462 MHz > Signal level=-56 dBm > Encryption key:off > Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s >9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s >48 Mb/s; 54 Mb/s; 6.5 Mb/s; 13 Mb/s; 19.5 > Mb/s >26 Mb/s; 39 Mb/s; 52 Mb/s; 58.5 Mb/s; 65 > Mb/s > Extra:Bcn int = 100 ms > IE: Unknown: 000A42544F70656E7A6F6E65 > IE: Unknown: 010882848B960C121824 > IE: Unknown: 03010B > IE: Unknown: 2A0100 > IE: Unknown: 32043048606C > IE: Unknown: > 2D1AAC011B0 > 0 > IE: Unknown: > 3D160B08000 > 0 > IE: Unknown: 4A0E14000A002C01C800140005001900 > IE: Unknown: 7F0101 > IE: Unknown: > DD180050F2020101890003A427A442435E00623 > 22F00 > IE: Unknown: > DD1E00904C33AC011B0 > 0 > IE: Unknown: > DD1A00904C340B08000 > 0 > IE: Unknown: DD0900037F0101FF7F >Cell 03 - Address: 00:FE:F4:59:01:A0 > ESSID:"BTHub3-JJCH" > Protocol:IEEE 802.11 BG > Mode:Managed > Frequency:2.437 MHz > Signal level=-88 dBm > Encryption key:on > Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s >9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s >48 Mb/s; 54 Mb/s; 6.5 Mb/s; 13 Mb/s; 19.5 > Mb/s >26 Mb/s; 39 Mb/s; 52 Mb/s; 58.5 Mb/s; 65 > Mb/s >
NM 0.9.1 failing to get SSIDs with WPA supplicant 0.7.3
Hi, I'm running NetworkManager 0.9.1 from git and wpa_supplicant 0.7.3 on a custom distro (based from poky). When I run nmcli dev wifi, the access points appear but everything seems to be screwed up. SSID BSSID MODE FREQ RATE SIGNAL SECURITY ACTIVE 8C0300010002:FE:F4:50:A9:50 Infrastructure 2 MHz63 MB/s75 WPA2 no 8C0600010000:FE:F4:50:A9:50 Infrastructure 2 MHz 1 MB/s 75 -- no 8C0600010000:FE:F4:59:01:A0 Infrastructure 2 MHz 0 MB/s 20 -- no 8C0300010002:FE:F4:50:A9:50 Infrastructure 2 MHz 0 MB/s 72 -- no The driver appears to be working, iwlist gives all the details I expect and comparing the output below with the NM output shows what is wrong. iwlist tiwlan0 scanning tiwlan0 Scan completed : Cell 01 - Address: 12:FE:F4:50:A9:50 ESSID:"BTFON" Protocol:IEEE 802.11 BG Mode:Managed Frequency:2.462 MHz Signal level=-56 dBm Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s; 6.5 Mb/s; 13 Mb/s; 19.5 Mb/s 26 Mb/s; 39 Mb/s; 52 Mb/s; 58.5 Mb/s; 65 Mb/s Extra:Bcn int = 100 ms IE: Unknown: 00054254464F4E IE: Unknown: 010882848B960C121824 IE: Unknown: 03010B IE: Unknown: 2A0100 IE: Unknown: 32043048606C IE: Unknown: 2D1AAC011B0 0 IE: Unknown: 3D160B08000 0 IE: Unknown: 4A0E14000A002C01C800140005001900 IE: Unknown: 7F0101 IE: Unknown: DD180050F2020101890003A427A442435E00623 22F00 IE: Unknown: DD1E00904C33AC011B0 0 IE: Unknown: DD1A00904C340B08000 0 IE: Unknown: DD0900037F0101FF7F Cell 02 - Address: 02:FE:F4:50:A9:50 ESSID:"BTOpenzone" Protocol:IEEE 802.11 BG Mode:Managed Frequency:2.462 MHz Signal level=-56 dBm Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s; 6.5 Mb/s; 13 Mb/s; 19.5 Mb/s 26 Mb/s; 39 Mb/s; 52 Mb/s; 58.5 Mb/s; 65 Mb/s Extra:Bcn int = 100 ms IE: Unknown: 000A42544F70656E7A6F6E65 IE: Unknown: 010882848B960C121824 IE: Unknown: 03010B IE: Unknown: 2A0100 IE: Unknown: 32043048606C IE: Unknown: 2D1AAC011B0 0 IE: Unknown: 3D160B08000 0 IE: Unknown: 4A0E14000A002C01C800140005001900 IE: Unknown: 7F0101 IE: Unknown: DD180050F2020101890003A427A442435E00623 22F00 IE: Unknown: DD1E00904C33AC011B0 0 IE: Unknown: DD1A00904C340B08000 0 IE: Unknown: DD0900037F0101FF7F Cell 03 - Address: 00:FE:F4:59:01:A0 ESSID:"BTHub3-JJCH" Protocol:IEEE 802.11 BG Mode:Managed Frequency:2.437 MHz Signal level=-88 dBm Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s; 6.5 Mb/s; 13 Mb/s; 19.5 Mb/s 26 Mb/s; 39 Mb/s; 52 Mb/s; 58.5 Mb/s; 65 Mb/s Extra:Bcn int = 100 ms IE: Unknown: 000B4254487562332D4A4A4348 IE: Unknown: 010882848B960C121824 IE: Unknown: 030106 IE: Unknown: 05040203 IE: Unknown: 2A0100 IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : CCMP TKIP Authentication Suites (1) : PSK IE: WPA Version
[RFC] use instead of
Use of conflicts with the use of . While users of can switch to it is not posible in the other direction. The header uses because it is part of the API, therefore it conflicts with NM. Does NM rely on using for some reason or can we switch over to using ? --- include/wireless-helper.h |2 +- src/nm-device.c|2 +- src/nm-system.c|2 +- src/ppp-manager/nm-ppp-manager.c |2 +- src/settings/plugins/ifcfg-rh/reader.c |2 +- src/wimax/iwmxsdk.c|2 +- src/wimax/nm-device-wimax.c|2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/include/wireless-helper.h b/include/wireless-helper.h index d150ef7..2e4509a 100644 --- a/include/wireless-helper.h +++ b/include/wireless-helper.h @@ -27,6 +27,6 @@ #include #include #include -#include +#include #include diff --git a/src/nm-device.c b/src/nm-device.c index 3522ea4..a453c39 100644 --- a/src/nm-device.c +++ b/src/nm-device.c @@ -25,7 +25,7 @@ #include #include #include -#include +#include #include #include #include diff --git a/src/nm-system.c b/src/nm-system.c index 0b29468..473fcec 100644 --- a/src/nm-system.c +++ b/src/nm-system.c @@ -40,7 +40,7 @@ #include #include #include -#include +#include #include "nm-system.h" #include "nm-device.h" diff --git a/src/ppp-manager/nm-ppp-manager.c b/src/ppp-manager/nm-ppp-manager.c index e863aab..9d8b79e 100644 --- a/src/ppp-manager/nm-ppp-manager.c +++ b/src/ppp-manager/nm-ppp-manager.c @@ -32,7 +32,7 @@ #include #include #include -#include +#include #include #include diff --git a/src/settings/plugins/ifcfg-rh/reader.c b/src/settings/plugins/ifcfg-rh/reader.c index cdf5889..a2a 100644 --- a/src/settings/plugins/ifcfg-rh/reader.c +++ b/src/settings/plugins/ifcfg-rh/reader.c @@ -28,7 +28,7 @@ #include #include #include -#include +#include #include #include #include diff --git a/src/wimax/iwmxsdk.c b/src/wimax/iwmxsdk.c index dd78d5a..f9dc714 100644 --- a/src/wimax/iwmxsdk.c +++ b/src/wimax/iwmxsdk.c @@ -27,7 +27,7 @@ #include #include #include -#include +#include #include diff --git a/src/wimax/nm-device-wimax.c b/src/wimax/nm-device-wimax.c index d41491a..ec23520 100644 --- a/src/wimax/nm-device-wimax.c +++ b/src/wimax/nm-device-wimax.c @@ -23,7 +23,7 @@ #include #include #include -#include +#include #include #include -- 1.7.6 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 7/7] core: Fix leaks if address parsing fails while setting mac
Both 'old' and 'new' are leaked if nl_addr_build() fails to parse
the mac address.
---
src/nm-system.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/nm-system.c b/src/nm-system.c
index 7fa4b6a..0b29468 100644
--- a/src/nm-system.c
+++ b/src/nm-system.c
@@ -755,6 +755,8 @@ nm_system_iface_set_mac (int ifindex, const struct
ether_addr *mac)
addr = nl_addr_build (AF_LLC, (void *) mac, ETH_ALEN);
if (!addr) {
nm_log_err (LOGD_HW, "(%s): failed to allocate memory
for MAC address change", iface);
+ rtnl_link_put (old);
+ rtnl_link_put (new);
return FALSE;
}
rtnl_link_set_addr (new, addr);
--
1.7.6
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 6/7] core: fix leaked address structure after parsing mac address
---
src/nm-system.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/nm-system.c b/src/nm-system.c
index ac428ee..7fa4b6a 100644
--- a/src/nm-system.c
+++ b/src/nm-system.c
@@ -758,6 +758,7 @@ nm_system_iface_set_mac (int ifindex, const struct
ether_addr *mac)
return FALSE;
}
rtnl_link_set_addr (new, addr);
+ nl_addr_put (addr);
nlh = nm_netlink_get_default_handle ();
if (nlh) {
err = rtnl_link_change (nlh, old, new, 0);
--
1.7.6
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 5/7] ip6: Perform sanity check before processing prefix messages
Verifies that the provided message consists of at least the prefix header.
---
src/ip6-manager/nm-ip6-manager.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/ip6-manager/nm-ip6-manager.c b/src/ip6-manager/nm-ip6-manager.c
index 721d43b..c734139 100644
--- a/src/ip6-manager/nm-ip6-manager.c
+++ b/src/ip6-manager/nm-ip6-manager.c
@@ -624,6 +624,11 @@ process_prefix (NMIP6Manager *manager, struct nl_msg *msg)
nm_log_dbg (LOGD_IP6, "processing netlink new prefix message");
+ if (!nlmsg_valid_hdr (nlmsg_hdr (msg), sizeof(*pmsg))) {
+ nm_log_dbg (LOGD_IP6, "ignoring invalid prefix message");
+ return NULL;
+ }
+
pmsg = (struct prefixmsg *) NLMSG_DATA (nlmsg_hdr (msg));
device = nm_ip6_manager_get_device (manager, pmsg->prefix_ifindex);
--
1.7.6
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 4/7] ip6: Perform sanity checks before processing nduseropt messages
Verifies that the provided message consists of the nduseropt header
followed by an array of options as specified in the header.
---
src/ip6-manager/nm-ip6-manager.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/ip6-manager/nm-ip6-manager.c b/src/ip6-manager/nm-ip6-manager.c
index a8e88be..721d43b 100644
--- a/src/ip6-manager/nm-ip6-manager.c
+++ b/src/ip6-manager/nm-ip6-manager.c
@@ -911,6 +911,13 @@ process_nduseropt (NMIP6Manager *manager, struct nl_msg
*msg)
ndmsg = (struct nduseroptmsg *) NLMSG_DATA (nlmsg_hdr (msg));
+ if (!nlmsg_valid_hdr (nlmsg_hdr (msg), sizeof (*ndmsg)) ||
+ nlmsg_datalen (nlmsg_hdr (msg)) <
+ (ndmsg->nduseropt_opts_len + sizeof (*ndmsg))) {
+ nm_log_dbg (LOGD_IP6, "ignoring invalid nduseropt message");
+ return NULL;
+ }
+
if (ndmsg->nduseropt_family != AF_INET6 ||
ndmsg->nduseropt_icmp_type != ND_ROUTER_ADVERT ||
ndmsg->nduseropt_icmp_code != 0) {
--
1.7.6
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 3/7] ip6: Perform sanity check before processing NEWLINK messages
Verifies that provided message consists of at least the link message
header. nlmsg_parse() does this so it needs to be called prior to
accessing the message contents.
---
src/ip6-manager/nm-ip6-manager.c | 25 +
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/src/ip6-manager/nm-ip6-manager.c b/src/ip6-manager/nm-ip6-manager.c
index f0dc7c3..a8e88be 100644
--- a/src/ip6-manager/nm-ip6-manager.c
+++ b/src/ip6-manager/nm-ip6-manager.c
@@ -970,6 +970,19 @@ process_newlink (NMIP6Manager *manager, struct nl_msg *msg)
struct nlattr *pi[IFLA_INET6_MAX + 1];
int err;
+ /* FIXME: we have to do this manually for now since libnl doesn't yet
+* support the IFLA_PROTINFO attribute of NEWLINK messages. When it
does,
+* we can get rid of this function and just grab IFLA_PROTINFO from
+* nm_ip6_device_sync_from_netlink(), then get the IFLA_INET6_FLAGS out
of
+* the PROTINFO.
+*/
+ err = nlmsg_parse (hdr, sizeof (*ifi), tb, IFLA_MAX, link_policy);
+ if (err < 0) {
+ nm_log_dbg (LOGD_IP6, "ignoring invalid newlink netlink message
"
+ "while parsing PROTINFO attribute");
+ return NULL;
+ }
+
ifi = nlmsg_data (hdr);
if (ifi->ifi_family != AF_INET6) {
nm_log_dbg (LOGD_IP6, "ignoring netlink message family %d",
ifi->ifi_family);
@@ -983,18 +996,6 @@ process_newlink (NMIP6Manager *manager, struct nl_msg *msg)
return NULL;
}
- /* FIXME: we have to do this manually for now since libnl doesn't yet
-* support the IFLA_PROTINFO attribute of NEWLINK messages. When it
does,
-* we can get rid of this function and just grab IFLA_PROTINFO from
-* nm_ip6_device_sync_from_netlink(), then get the IFLA_INET6_FLAGS out
of
-* the PROTINFO.
-*/
-
- err = nlmsg_parse (hdr, sizeof (*ifi), tb, IFLA_MAX, link_policy);
- if (err < 0) {
- nm_log_dbg (LOGD_IP6, "(%s): error parsing PROTINFO attribute",
device->iface);
- return NULL;
- }
if (!tb[IFLA_PROTINFO]) {
nm_log_dbg (LOGD_IP6, "(%s): message had no PROTINFO
attribute", device->iface);
return NULL;
--
1.7.6
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 2/7] ip6: fix leak in process_addr()
rtnladdr is leaked if nm_ip6_manager_get_device() returns NULL.
---
src/ip6-manager/nm-ip6-manager.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/ip6-manager/nm-ip6-manager.c b/src/ip6-manager/nm-ip6-manager.c
index d882b00..f0dc7c3 100644
--- a/src/ip6-manager/nm-ip6-manager.c
+++ b/src/ip6-manager/nm-ip6-manager.c
@@ -551,6 +551,7 @@ process_addr (NMIP6Manager *manager, struct nl_msg *msg)
device = nm_ip6_manager_get_device (manager, rtnl_addr_get_ifindex
(rtnladdr));
if (!device) {
nm_log_dbg (LOGD_IP6, "ignoring message for unknown device");
+ rtnl_addr_put (rtnladdr);
return NULL;
}
--
1.7.6
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 1/7] ip6: fix leak in process_route()
rtnlroute is leaked if nm_ip6_manager_get_device returns NULL
---
src/ip6-manager/nm-ip6-manager.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/ip6-manager/nm-ip6-manager.c b/src/ip6-manager/nm-ip6-manager.c
index fb9e77b..d882b00 100644
--- a/src/ip6-manager/nm-ip6-manager.c
+++ b/src/ip6-manager/nm-ip6-manager.c
@@ -591,6 +591,7 @@ process_route (NMIP6Manager *manager, struct nl_msg *msg)
device = nm_ip6_manager_get_device (manager, rtnl_route_get_oif
(rtnlroute));
if (!device) {
nm_log_dbg (LOGD_IP6, "ignoring message for unknown device");
+ rtnl_route_put (rtnlroute);
return NULL;
}
--
1.7.6
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 0/7] Various libnl related fixes
Pretty straight forward libnl related fixes Thomas Graf (7): ip6: fix leak in process_route() ip6: fix leak in process_addr() ip6: Perform sanity check before processing NEWLINK messages ip6: Perform sanity checks before processing nduseropt messages ip6: Perform sanity check before processing prefix messages core: fix leaked address structure after parsing mac address core: Fix leaks if address parsing fails while setting mac src/ip6-manager/nm-ip6-manager.c | 39 ++--- src/nm-system.c |3 ++ 2 files changed, 30 insertions(+), 12 deletions(-) -- 1.7.6 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Accept VPN IPv4 configs without a tundevice
Hi Dan, > So does the plugin still pass back the rest of the IPv4 config to NM? Yes, but mostly to make NM happy with the VPN connection. We actually need NM to handle DNS information only, as we don't want to compete with it for resolv.conf. > Basically, if the plugin will ensure that IP addressing and routes get > set up as NM would expect them to, then we can have the plugin to pass a > flag to NM saying that's the case, and then NM wouldn't do much (except > DNS fixups, search domain stuff, etc) but would still advertise the > attributes of the VPN connection such that clients could still determine > the VPN's IPv4 config. I think this would be the best solution. Our daemon installs the route in a dedicated routing table to avoid any conflicts (for example if we get a second default route over the VPN). This way it doesn't conflict with NM routes, but just overrides them. It would be nice if I could tell NM if the VPN plugin handles the setup itself during config signaling, e.g.: - got VPN specific IP 10.0.0.7 on eth0, installed myself - got a route to 10.0.0.0/16 using 10.0.0.7, installed myself - got DNS server 10.0.1.2, please handle it for me Does that sound reasonable? Another solution would be to let NM install the IP and route. But it is rather tricky (and plugin specific) to set them up correctly in the VPN context, I won't burden that to NM. Regards Martin ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Set the default IPv6 mode to auto and IPv4 optional
* Mathieu Trudel-Lapierre > I applied this separately from the IPv4 optional bit in Ubuntu > (network-manager 0.9.0-0ubuntu2), but it appears to be breaking > modem connections. Now, I'm not quite certain why that is, but I'm > trying to debug it and hoping it's not a side-effect of other Ubuntu > patches. I'm afraid I don't have the necessary hardware to help figure out why it breaks. :-( -- Tore Anderson ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
