Re: [PATCH] core: add internet connectivity check
Hi Marcel, On Thu, 2011-11-17 at 10:07 +0900, Marcel Holtmann wrote: > within ConnMan we decided to go for a vendor-header with a specific > value within the HTTP response. That way we are keeping the HTTP > response code and don't have to define a magic one. I don't understand this. Has connman a database with vendor-headers and should every vendor set a specific http header in the response? Cheers, Tom ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] core: add internet connectivity check
Hi David, > Chromium OS hits a URL that is expected to give a 204 response; if we get > anything else, we assume we're being portalled. > > This seems to be working well. HTTPS would be the next step if we start > to see portals returning 204s. within ConnMan we decided to go for a vendor-header with a specific value within the HTTP response. That way we are keeping the HTTP response code and don't have to define a magic one. In addition if you look at the big picture with actually integrating WISPr, you do wanna make the initial request without HTTPS since you need to figure out the login details first. Also with 6to4 and all the other IPv6 setup magic, we separate IPv4 checks from IPv6 checks. Regards Marcel ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] core: add internet connectivity check - V3
Hi,
On Wed, 2011-11-16 at 00:19 -0600, Dan Williams wrote:
> Pretty much what I was thinking about, but I wonder what we should do
> for the expected response. I'm not sure a regex is the right way to go
> at the moment because regex libraries differ in syntax and that might
> tie us into a specific one. But regex is powerful :) I think maybe for
> the moment we should just specify that it's a string match. Then later
> when more intelligently handling hotspot perhaps we'll do regexes.
i use g_str_has_prefix() now to compare the response with the expected
response.
Try it with:
NetworkManager --no-daemon --log-domains=CORE --log-level=DEBUG
--connectivity-uri=http://toabctl.de/conntest.txt
--connectivity-response=HelloNM
Cheers,
Tom
>From b04fe037a5ab994d62943402874a2adba24012ef Mon Sep 17 00:00:00 2001
From: Thomas Bechtold
Date: Fri, 21 Oct 2011 21:21:30 +0200
Subject: [PATCH] core: add internet connectivity check
* use libsoup to compare a http response from a given
uri with a given response (use g_str_has_prefix () to compare)
* do periodically check the connectivity. Check interval is configurable
* check connectivity when device state change
from/to NM_DEVICE_STATE_ACTIVATED
---
configure.ac |4 +
src/Makefile.am |6 +-
src/main.c| 14 ++-
src/nm-config.c | 66 +-
src/nm-config.h |6 +
src/nm-connectivity.c | 349 +
src/nm-connectivity.h | 69 ++
src/nm-manager.c | 84 ++--
src/nm-manager.h |5 +-
9 files changed, 583 insertions(+), 20 deletions(-)
create mode 100644 src/nm-connectivity.c
create mode 100644 src/nm-connectivity.h
diff --git a/configure.ac b/configure.ac
index 8d57f71..a68ec63 100644
--- a/configure.ac
+++ b/configure.ac
@@ -283,6 +283,10 @@ PKG_CHECK_MODULES(GIO, gio-2.0)
AC_SUBST(GIO_CFLAGS)
AC_SUBST(GIO_LIBS)
+PKG_CHECK_MODULES(LIBSOUP, [libsoup-2.4 >= 2.26])
+AC_SUBST(LIBSOUP_CFLAGS)
+AC_SUBST(LIBSOUP_LIBS)
+
GOBJECT_INTROSPECTION_CHECK([0.9.6])
# Qt4
diff --git a/src/Makefile.am b/src/Makefile.am
index c46e5e8..d11fbd4 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -187,7 +187,9 @@ NetworkManager_SOURCES = \
nm-dhcp6-config.h \
nm-rfkill.h \
nm-session-monitor.c \
- nm-session-monitor.h
+ nm-session-monitor.h \
+ nm-connectivity.c \
+ nm-connectivity.h
nm-access-point-glue.h: $(top_srcdir)/introspection/nm-access-point.xml
$(AM_V_GEN) dbus-binding-tool --prefix=nm_access_point --mode=glib-server --output=$@ $<
@@ -250,6 +252,7 @@ NetworkManager_CPPFLAGS = \
$(LIBNL_CFLAGS) \
$(GMODULE_CFLAGS) \
$(POLKIT_CFLAGS) \
+ $(LIBSOUP_CFLAGS) \
-DG_DISABLE_DEPRECATED \
-DBINDIR=\"$(bindir)\" \
-DSBINDIR=\"$(sbindir)\" \
@@ -290,6 +293,7 @@ NetworkManager_LDADD = \
$(LIBNL_LIBS) \
$(GMODULE_LIBS) \
$(POLKIT_LIBS) \
+ $(LIBSOUP_LIBS) \
$(LIBM) \
$(LIBDL)
diff --git a/src/main.c b/src/main.c
index 26fa28f..4b92e2d 100644
--- a/src/main.c
+++ b/src/main.c
@@ -420,6 +420,9 @@ main (int argc, char *argv[])
char *pidfile = NULL, *state_file = NULL;
char *config_path = NULL, *plugins = NULL;
char *log_level = NULL, *log_domains = NULL;
+ char *connectivity_uri = NULL;
+ gint connectivity_interval = -1;
+ char *connectivity_response = NULL;
gboolean wifi_enabled = TRUE, net_enabled = TRUE, wwan_enabled = TRUE, wimax_enabled = TRUE;
gboolean success, show_version = FALSE;
NMPolicy *policy = NULL;
@@ -449,6 +452,9 @@ main (int argc, char *argv[])
" WIFI_SCAN,IP4,IP6,AUTOIP4,DNS,VPN,SHARING,SUPPLICANT,\n"
" AGENTS,SETTINGS,SUSPEND,CORE,DEVICE,OLPC,WIMAX]",
"HW,RFKILL,WIFI" },
+ { "connectivity-uri", 0, 0, G_OPTION_ARG_STRING, &connectivity_uri, "A http(s) address to check internet connectivity" },
+ { "connectivity-interval", 0, 0, G_OPTION_ARG_INT, &connectivity_interval, "the interval in seconds how often a connectivity check will be done" },
+ { "connectivity-response", 0, 0, G_OPTION_ARG_STRING, &connectivity_response, "the expected start of the response" },
{NULL}
};
@@ -503,7 +509,8 @@ main (int argc, char *argv[])
exit (1);
/* Read the config file and CLI overrides */
- config = nm_config_new (config_path, plugins, log_level, log_domains, &error);
+ config = nm_config_new (config_path, plugins, log_level, log_domains,
+ connectivity_uri, connectivity_interval, connectivity_response, &error);
if (config == NULL) {
fprintf (stderr, "Failed to read configuration: (%d) %s\n",
error ? error->code : -1,
@@ -637,6 +644,9 @@ main (int argc, char *argv[])
wifi_enabled,
wwan_enabled,
wimax_enabled,
+ nm_config_get_connectivity_uri (config),
+ nm_config_get_connectivity_interval (config),
+ nm_c
Re: device removal signals does not work for me
On Wed, 2011-11-16 at 12:39 +0100, Thomas Bechtold wrote: > On 15/11/11 19:50, Dan Williams wrote: > > dbus-monitor > > "type='signal',sender='org.freedesktop.NetworkManager',interface='org.freedesktop.NetworkManager'" > > see output (with kernel debug messages in between). So 'DeviceRemoved' > signals are sent. Then the problem is in NMClient? If the signals are getting sent from NM, then yes it would indicate a problem in libnm-glib/NMClient. But to check, if you've got sources, can you run 'libnm-glib-test' from the libnm-glib directory in NM sources, and then remove the device, and tell us what it prints out when you remove the device? For example, doing 'rmmod e1000e' for me prints out: Device removed Interface: eth0 Udi: /sys/devices/pci:00/:00:19.0/net/eth0 Dan > Cheers, > > Tom > > output > usb 1-2: USB disconnect, address 10 > MOSCHIP usb-ethernet driver 1-2:1.0: eth0: unregister 'MOSCHIP > usb-ethernet driver' usb-at91-2, MOSCHIP 7830/7730 usb-NET adapter > signal sender=:1.104 -> dest=(null destination) serial=109 > path=/org/freedesktop/NetworkManager; > interface=org.freedesktop.NetworkManager; member=StateChanged > uint32 4 > signal sender=:1.104 -> dest=(null destination) serial=110 > path=/org/freedesktop/NetworkManager; > interface=org.freedesktop.NetworkManager; member=StateChange > uint32 4 > signal sender=:1.104 -> dest=(null destination) serial=116 > path=/org/freedesktop/NetworkManager; > interface=org.freedesktop.NetworkManager; member=DeviceRemoved > object path "/org/freedesktop/NetworkManager/Devices/0" > signal sender=:1.104 -> dest=(null destination) serial=117 > path=/org/freedesktop/NetworkManager; > interface=org.freedesktop.NetworkManager; member=PropertiesChanged > array [ >dict entry( > string "State" > variant uint32 4 >) >dict entry( > string "ActiveConnections" > variant array [ > ] >) > ] > usb 1-2: new full speed USB device using at91_ohci and address 14 > usb 1-2: New USB device found, idVendor=9710, idProduct=7830 > usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > usb 1-2: Product: USB-MAC Controller > usb 1-2: Manufacturer: Moschip Semiconductor > usb 1-2: SerialNumber: 3b000e66 > usb 1-2: applying rev.C fixup > usb 1-2: applying rev.C fixup > MOSCHIP usb-ethernet driver 1-2:1.0: eth0: register 'MOSCHIP > usb-ethernet driver' at usb-at91-2, MOSCHIP 7830/7730 usb-NET adapter, > 00:13:3b:00:0e:66 > signal sender=:1.104 -> dest=(null destination) serial=122 > path=/org/freedesktop/NetworkManager; > interface=org.freedesktop.NetworkManager; member=DeviceAdded > object path "/org/freedesktop/NetworkManager/Devices/4" > signal sender=:1.104 -> dest=(null destination) serial=125 > path=/org/freedesktop/NetworkManager; > interface=org.freedesktop.NetworkManager; member=PropertiesChanged > array [ >dict entry( > string "ActiveConnections" > variant array [ > ] >) > ] > signal sender=:1.104 -> dest=(null destination) serial=126 > path=/org/freedesktop/NetworkManager; > interface=org.freedesktop.NetworkManager; member=StateChanged > uint32 2 > signal sender=:1.104 -> dest=(null destination) serial=127 > path=/org/freedesktop/NetworkManager; > interface=org.freedesktop.NetworkManager; member=StateChange > uint32 2 > signal sender=:1.104 -> dest=(null destination) serial=130 > path=/org/freedesktop/NetworkManager; > interface=org.freedesktop.NetworkManager; member=PropertiesChanged > array [ >dict entry( > string "State" > variant uint32 2 >) >dict entry( > string "ActiveConnections" > variant array [ > object path > "/org/freedesktop/NetworkManager/ActiveConnection/1" > ] >) > ] ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager recycling connections
On Tuesday 15 of November 2011 20:56:41 Bill C Riemers wrote: > I found the problem. I was wrong about needing to toggle the flag after > every boot. > > Here is the problem, network manager is using the IPV6INIT=no flag, as the > flag IPV6 - IGNORE on a device. But it looks like to me that flag only > controls the use of DHCPv6. Since DHCPv6 is not required when using > Router Advertisements, with "IPV6INIT=no" my wifi comes up successfully > with an IPv6 configuration. If I use IPV6INIT=yes, then it also comes up > successfully, but it waits around for a DHCPv6 that does not exist. After > about 15-20 minutes that times out so it recycles the working connection. > IPV6INIT (together with other flags flags) is used to read/write IPv6 methods via ifcfg-rh plugin. Logic is: IPV6INIT=no NM_SETTING_IP6_CONFIG_METHOD_IGNORE else IPV6_AUTOCONF=yes -> NM_SETTING_IP6_CONFIG_METHOD_AUTO DHCPV6C=yes -> NM_SETTING_IP6_CONFIG_METHOD_DHCP IPV6_AUTOCONF=no and no IPv6 address set -> NM_SETTING_IP6_CONFIG_METHOD_LINK_LOCAL else NM_SETTING_IP6_CONFIG_METHOD_MANUAL > So in essence the problem is the IPV6INIT flag is the wrong flag to be > using for enabling and disabling IPv6 for a device. > > The following seems to map what the "IPV6" Methods drop downs really do: > > Ignore -> Configure with Router Advertisements > Automatic -> Configure with Router Advertisements and then reconfigure with > DHCPv6. If DHCPv6 fails recycle the connection after a long timeout. > > I haven't tried any of the other options. > > Here is what is expected: > > Ignore -> Configure with private address, or disable IPv6 for the device > Automatic -> Configure with Router Advertisements or DHCPv6. (Whichever > succeeds first.) > What is a done when configurong addresses is: NM_SETTING_IP6_CONFIG_METHOD_AUTO or NM_SETTING_IP6_CONFIG_METHOD_LINK_LOCAL SLAAC is started, which could in turn start DHCPv6 if it is required by RA NM_SETTING_IP6_CONFIG_METHOD_DHCP DHCPv6 is started, RA is disabled NM_SETTING_IP6_CONFIG_METHOD_IGNORE Accept RA is disabled or set as it was when NM started NM_SETTING_IP6_CONFIG_METHOD_MANUAL Accept RA is disabled, manual addresses are set details in src/nm-device.c:real_act_stage3_ip6_config_start() > > Bill > Jirka ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
OpenVPN connection through GSM device
Hi, i'm able to start an OpenVPN connection using Network Manager. It work fine if i start it through ethernet connection (previously activate)...but it work bad if i start VPN through GSM/GPRS device connection (previously activate). I'm able to start, but after a bit time (about some minutes) it go down. Below the fragment of Network Manager (DEBUG mode) logs: Nov 16 15:35:13 myWorkstation NetworkManager[2033]: Starting VPN service 'openvpn'... Nov 16 15:35:13 myWorkstation NetworkManager[2033]: VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 2125 Nov 16 15:35:13 myWorkstation kernel: tun: Universal TUN/TAP device driver, 1.6 Nov 16 15:35:13 myWorkstation kernel: tun: (C) 1999-2004 Max Krasnyansky < m...@qualcomm.com> Nov 16 15:35:13 myWorkstation NetworkManager[2033]: VPN service 'openvpn' appeared; activating connections Nov 16 15:35:13 myWorkstation NetworkManager[2033]: [1321457713.828958] [nm-vpn-connection.c:902] get_secrets(): (355653c0-34d3-4777-ad25-f9a498b7ef8e/VPN) requesting VPN secrets pass #1 Nov 16 15:35:13 myWorkstation NetworkManager[2033]: [1321457713.831977] [nm-agent-manager.c:1100] nm_agent_manager_get_secrets(): Secrets requested for connection /org/freedesktop/NetworkManager/Set) Nov 16 15:35:13 myWorkstation NetworkManager[2033]: [1321457713.832486] [nm-settings-connection.c:850] nm_settings_connection_get_secrets(): (355653c0-34d3-4777-ad25-f9a498b7ef8e/vpn:2) secrets requ' Nov 16 15:35:13 myWorkstation NetworkManager[2033]: [1321457713.841727] [nm-agent-manager.c:1015] get_start(): (0xf81f8/vpn) system settings secrets sufficient Nov 16 15:35:13 myWorkstation NetworkManager[2033]: [1321457713.842228] [nm-settings-connection.c:706] agent_secrets_done_cb(): (355653c0-34d3-4777-ad25-f9a498b7ef8e/vpn:2) existing secrets returned Nov 16 15:35:13 myWorkstation NetworkManager[2033]: [1321457713.842587] [nm-settings-connection.c:712] agent_secrets_done_cb(): (355653c0-34d3-4777-ad25-f9a498b7ef8e/vpn:2) secrets request completed Nov 16 15:35:13 myWorkstation NetworkManager[2033]: [1321457713.847864] [nm-settings-connection.c:751] agent_secrets_done_cb(): (355653c0-34d3-4777-ad25-f9a498b7ef8e/vpn:2) new agent secrets processd Nov 16 15:35:13 myWorkstation NetworkManager[2033]: [1321457713.848273] [nm-vpn-connection.c:870] get_secrets_cb(): (355653c0-34d3-4777-ad25-f9a498b7ef8e/VPN) asking service if additional secrets ard Nov 16 15:35:13 myWorkstation NetworkManager[2033]: VPN plugin state changed: 1 Nov 16 15:35:14 myWorkstation NetworkManager[2033]: [1321457714.22935] [nm-vpn-connection.c:840] plugin_need_secrets_cb(): (355653c0-34d3-4777-ad25-f9a498b7ef8e/VPN) service indicated no additional d Nov 16 15:35:14 myWorkstation NetworkManager[2033]: VPN plugin state changed: 3 Nov 16 15:35:14 myWorkstation NetworkManager[2033]: VPN connection 'VPN' (Connect) reply received. Nov 16 15:35:14 myWorkstation nm-openvpn[2127]: OpenVPN 2.1.3 arm-unknown-linux-gnueabi [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] built on Oct 22 2010 Nov 16 15:35:14 myWorkstation nm-openvpn[2127]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Nov 16 15:35:14 myWorkstation nm-openvpn[2127]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Nov 16 15:35:14 myWorkstation nm-openvpn[2127]: WARNING: file '/etc/openvpn/certs/x-key.pem' is group or others accessible Nov 16 15:35:14 myWorkstation nm-openvpn[2127]: /usr/bin/openssl-vulnkey -q -b 2048 -m Nov 16 15:35:16 myWorkstation nm-openvpn[2127]: LZO compression initialized Nov 16 15:35:16 myWorkstation nm-openvpn[2127]: UDPv4 link local: [undef] Nov 16 15:35:16 myWorkstation nm-openvpn[2127]: UDPv4 link remote: [AF_INET]xx.xx.xxx.xxx:1194 Nov 16 15:35:44 myWorkstation nm-openvpn[2127]: [serverVpnPrdItaly] Peer Connection Initiated with [AF_INET]91.213.153.15:1194 Nov 16 15:35:49 myWorkstation NetworkManager[2033]: [1321457749.191751] [nm-netlink-monitor.c:117] link_msg_handler(): netlink link message: iface idx 7 flags 0x1090 Nov 16 15:35:49 myWorkstation nm-openvpn[2127]: TUN/TAP device tun0 opened Nov 16 15:35:49 myWorkstation nm-openvpn[2127]: /usr/libexec/nm-openvpn-service-openvpn-helper tun0 1500 1542 10.9.0.101 10.9.0.1 init Nov 16 15:35:49 myWorkstation NetworkManager[2033]: VPN connection 'VPN' (IP Config Get) reply received. Nov 16 15:35:49 myWorkstation NetworkManager[2033]: VPN Gateway: xx.xx.xxx.xxx Nov 16 15:35:49 myWorkstation NetworkManager[2033]: Internal Gateway: 10.9.0.1 Nov 16 15:35:49 myWorkstation NetworkManager[2033]: Tunnel Device: tun0 Nov 16 15:35:49 myWorkstation NetworkManager[2033]: Internal IP4 Address: 10.9.0.101 Nov 16 15:35:49 myWorkstation NetworkManager[2033]: Internal IP4 Prefix: 32 Nov 16 15:35:49 myWorkstation NetworkManager[2033]: Internal IP4 Point-to-Point Address: 10.9.0.1 Nov 16 15:35:49 myWorkstation NetworkManager[2033]: Ma
Re: [PATCH] core: add internet connectivity check
Chromium OS hits a URL that is expected to give a 204 response; if we get anything else, we assume we're being portalled. This seems to be working well. HTTPS would be the next step if we start to see portals returning 204s. https://gerrit.chromium.org/gerrit/gitweb?p=chromiumos/platform/flimflam.git;a=blob;f=src/portal.c;h=4c5fc99499ed7e217534ca400422e9383439f70c;hb=HEAD ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Show Hidden network from connection file
Thankyou for your reply. Do you know if there is any way to autoconnect to an ad-hoc wifi network even if it was never used before? I'm trying to set up a connection file to requiere the less user intervention. ps: sorry for my english... 2011/11/14 Jirka Klimes > On Tuesday 01 of November 2011 01:29:26 marcos m. wrote: > > Hello! I'm trying to write a connection file that is going to be > > distributed on many computers. > > It configures a wireless ad hoc connection, everything works fine except > > that the connection doesn't appears on the nm-applet in gnome, it is > only > > accessible from 'hidden networks'. > > I would like it to be available from the beginning so i changed the > > timestamp from 0 to 1 but it didn't showed up. > > What else or what files can I edit to make the connection looks like it > has > > been already used? > > Thanks, Marcos. > > Timestamp doesn't affect connection visibility, it only shows if/when the > connection was used last. > > You don't see it in nm-applet, because the items nm-applet shows are > visible > SSIDs. As your network is hidden, it won't be shown until you connect. > > You should see the configured connection profile in nm-connection-editor, > though. "Last Used" column represent timestamp. > > Jirka > ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] core: add internet connectivity check
On 11/16/2011 01:19 AM, Dan Williams wrote: >> ./NetworkManager --no-daemon --log-level=DEBUG --log-domains=CORE >> --connectivity-uri=http://toabctl.de >> --connectivity-response="toabctl.de" > > Pretty much what I was thinking about, but I wonder what we should do > for the expected response. I'm not sure a regex is the right way to go > at the moment because regex libraries differ in syntax and that might > tie us into a specific one. But regex is powerful :) I think maybe for > the moment we should just specify that it's a string match. Then later > when more intelligently handling hotspot perhaps we'll do regexes. My theory on this was to always request a plain-text file, and then if you get back anything HTML, you automatically know it's wrong. -- Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] core: add internet connectivity check
On 16/11/11 07:19, Dan Williams wrote: to test the connectivity check, do eg: ./NetworkManager --no-daemon --log-level=DEBUG --log-domains=CORE --connectivity-uri=http://toabctl.de --connectivity-response="toabctl.de" Pretty much what I was thinking about, but I wonder what we should do for the expected response. I'm not sure a regex is the right way to go at the moment because regex libraries differ in syntax and that might tie us into a specific one. But regex is powerful :) I think maybe for the moment we should just specify that it's a string match. you mean just (g_strcmp0 (defined_string, response_string) == 0) ? That's it? Cheers, Tom ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: device removal signals does not work for me
On 15/11/11 19:50, Dan Williams wrote: dbus-monitor "type='signal',sender='org.freedesktop.NetworkManager',interface='org.freedesktop.NetworkManager'" see output (with kernel debug messages in between). So 'DeviceRemoved' signals are sent. Then the problem is in NMClient? Cheers, Tom output usb 1-2: USB disconnect, address 10 MOSCHIP usb-ethernet driver 1-2:1.0: eth0: unregister 'MOSCHIP usb-ethernet driver' usb-at91-2, MOSCHIP 7830/7730 usb-NET adapter signal sender=:1.104 -> dest=(null destination) serial=109 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=StateChanged uint32 4 signal sender=:1.104 -> dest=(null destination) serial=110 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=StateChange uint32 4 signal sender=:1.104 -> dest=(null destination) serial=116 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=DeviceRemoved object path "/org/freedesktop/NetworkManager/Devices/0" signal sender=:1.104 -> dest=(null destination) serial=117 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=PropertiesChanged array [ dict entry( string "State" variant uint32 4 ) dict entry( string "ActiveConnections" variant array [ ] ) ] usb 1-2: new full speed USB device using at91_ohci and address 14 usb 1-2: New USB device found, idVendor=9710, idProduct=7830 usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-2: Product: USB-MAC Controller usb 1-2: Manufacturer: Moschip Semiconductor usb 1-2: SerialNumber: 3b000e66 usb 1-2: applying rev.C fixup usb 1-2: applying rev.C fixup MOSCHIP usb-ethernet driver 1-2:1.0: eth0: register 'MOSCHIP usb-ethernet driver' at usb-at91-2, MOSCHIP 7830/7730 usb-NET adapter, 00:13:3b:00:0e:66 signal sender=:1.104 -> dest=(null destination) serial=122 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=DeviceAdded object path "/org/freedesktop/NetworkManager/Devices/4" signal sender=:1.104 -> dest=(null destination) serial=125 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=PropertiesChanged array [ dict entry( string "ActiveConnections" variant array [ ] ) ] signal sender=:1.104 -> dest=(null destination) serial=126 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=StateChanged uint32 2 signal sender=:1.104 -> dest=(null destination) serial=127 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=StateChange uint32 2 signal sender=:1.104 -> dest=(null destination) serial=130 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=PropertiesChanged array [ dict entry( string "State" variant uint32 2 ) dict entry( string "ActiveConnections" variant array [ object path "/org/freedesktop/NetworkManager/ActiveConnection/1" ] ) ] ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Automatic setup of UMTS connection
Hi, I am trying to get a UMTS device automatically started on boot. I have created a system-connection, set the PIN, set it to 'Connect automatically'. However, the connection is only started, when I manually activate using nm-applet or from the commandline using nmcli, not automatically on boot. Is this a problem with the device, or the intended NM/MM behaviour for UMTS/CDMA devices? Details follow below. A possible issue is marked with '<*** Problem?' in the output. Thanks, Markus The ModemManager output is: [main.c:167] main(): ModemManager (version 0.5) starting... [mm-manager.c:120] load_plugin(): Loaded plugin Nokia [mm-manager.c:120] load_plugin(): Loaded plugin Novatel [mm-manager.c:120] load_plugin(): Loaded plugin SimTech [mm-manager.c:120] load_plugin(): Loaded plugin Sierra [mm-manager.c:120] load_plugin(): Loaded plugin Option High-Speed [mm-manager.c:120] load_plugin(): Loaded plugin Huawei [mm-manager.c:120] load_plugin(): Loaded plugin Wavecom [mm-manager.c:120] load_plugin(): Loaded plugin MotoC [mm-manager.c:120] load_plugin(): Loaded plugin Gobi [mm-manager.c:120] load_plugin(): Loaded plugin Ericsson MBM [mm-manager.c:120] load_plugin(): Loaded plugin Generic [mm-manager.c:120] load_plugin(): Loaded plugin ZTE [mm-manager.c:120] load_plugin(): Loaded plugin Option [mm-manager.c:120] load_plugin(): Loaded plugin Linktop [mm-manager.c:120] load_plugin(): Loaded plugin AnyData [mm-manager.c:120] load_plugin(): Loaded plugin X22X [mm-manager.c:120] load_plugin(): Loaded plugin Longcheer [mm-manager.c:120] load_plugin(): Loaded plugin Samsung [mm-manager.c:793] device_added(): (tty/ttyS0): could not get port's parent device [mm-manager.c:793] device_added(): (tty/ttyS1): could not get port's parent device [mm-manager.c:793] device_added(): (tty/ttyS2): could not get port's parent device [mm-manager.c:793] device_added(): (tty/ttyS3): could not get port's parent device [mm-manager.c:793] device_added(): (net/can0): could not get port's parent device [mm-manager.c:793] device_added(): (net/can1): could not get port's parent device [mm-serial-port.c:741] mm_serial_port_open(): (ttyUSB0) opening serial port... [mm-serial-port.c:810] mm_serial_port_open(): (ttyUSB0) device open count is 1 (open) [mm-plugin-base.c:850] try_open(): (ttyUSB0): probe requested by plugin 'Sierra' [mm-serial-port.c:741] mm_serial_port_open(): (ttyUSB1) opening serial port... [mm-serial-port.c:810] mm_serial_port_open(): (ttyUSB1) device open count is 1 (open) [mm-plugin-base.c:850] try_open(): (ttyUSB1): probe requested by plugin 'Sierra' [mm-serial-port.c:741] mm_serial_port_open(): (ttyUSB2) opening serial port... [mm-serial-port.c:810] mm_serial_port_open(): (ttyUSB2) device open count is 1 (open) [mm-plugin-base.c:850] try_open(): (ttyUSB2): probe requested by plugin 'Sierra' [mm-serial-port.c:741] mm_serial_port_open(): (ttyUSB3) opening serial port... [mm-serial-port.c:810] mm_serial_port_open(): (ttyUSB3) device open count is 1 (open) [mm-plugin-base.c:850] try_open(): (ttyUSB3): probe requested by plugin 'Sierra' [mm-serial-port.c:741] mm_serial_port_open(): (ttyUSB4) opening serial port... [mm-serial-port.c:810] mm_serial_port_open(): (ttyUSB4) device open count is 1 (open) [mm-plugin-base.c:850] try_open(): (ttyUSB4): probe requested by plugin 'Sierra' [mm-serial-port.c:741] mm_serial_port_open(): (ttyUSB5) opening serial port... [mm-serial-port.c:810] mm_serial_port_open(): (ttyUSB5) device open count is 1 (open) [mm-plugin-base.c:850] try_open(): (ttyUSB5): probe requested by plugin 'Sierra' [mm-serial-port.c:741] mm_serial_port_open(): (ttyUSB6) opening serial port... [mm-serial-port.c:810] mm_serial_port_open(): (ttyUSB6) device open count is 1 (open) [mm-plugin-base.c:850] try_open(): (ttyUSB6): probe requested by plugin 'Sierra' [mm-at-serial-port.c:298] debug_log(): (ttyUSB0): --> 'AT+GCAP' [mm-at-serial-port.c:298] debug_log(): (ttyUSB1): --> 'AT+GCAP' [mm-at-serial-port.c:298] debug_log(): (ttyUSB2): --> 'AT+GCAP' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): --> 'AT+GCAP' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): <-- 'AT+GCAP' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): <-- 'ERROR' [mm-serial-parsers.c:412] mm_serial_parser_v1_parse(): Got failure code 100: Unknown error [mm-at-serial-port.c:298] debug_log(): (ttyUSB4): --> 'AT+GCAP' [mm-at-serial-port.c:298] debug_log(): (ttyUSB5): --> 'AT+GCAP' [mm-at-serial-port.c:298] debug_log(): (ttyUSB6): --> 'AT+GCAP' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): --> 'AT+GCAP' [mm-at-serial-port.c:298] debug_log(): (ttyUSB4): <-- 'OK' [mm-at-serial-port.c:298] debug_log(): (ttyUSB5): <-- 'OK' [mm-at-serial-port.c:298] debug_log(): (ttyUSB6): <-- 'OK' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): <-- 'AT+GCAP' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): <-- 'ERROR' [mm-serial-par
Re: [PATCH 6/6] VLAN: create NMDeviceVLAN and activate it
On 11/16/2011 02:10 PM, Dan Williams wrote:
On Fri, 2011-10-21 at 09:52 +0800, Weiping Pan wrote:
When NetworkManager receives the message that a VLAN device is created in
kernel,
it should create corresponding NMDeviceVLAN object, and then activate it.
Instead of creating a new VLAN setting and passing it into
nm_device_vlan_new(), can't we just pass the interface name in?
Ok.
The second issue is that this code would automatically detect VLAN
interfaces created outside NM; that's not extremely useful because the
tool that created the interface probably wants to set it up too, and if
it doesn't, then it should probably just be telling NM to set it up
instead of creating the VLAN interface and then telling NM to configure
it. So we need to figure out what to do here so we don't step on
anyones toes and we interoperate in a way people expect.
At the moment my thought is to make NM ignore any VLAN interfaces it
doesn't create - the simplest choice and the clearest from an
interoperability standpoint.
If we recognize externally created VLAN interfaces, chances are that
we'll overwrite whatever the thing that created it did. I'm not sure
there's a point to creating a VLAN and then telling NM to configure it,
so why not just have NM create the VLAN and configure it. Taking over
existing configured devices is pretty tricky in most cases, and we only
support it for wired interfaces right now (and not for wired interfaces
that use 802.1x) because when taking over management of an interface we
need to take over *all* of it, including DHCP leases,
802.1x/wpa_supplicnat, PPP control, etc. And we don't do all of that
yet...
Dan
I thought NetworkManager should control all interfaces of a host,
no matter how they are created, then we can monitor states and traffics
of all interfaces.
Ok, let me ignore external created vlan interfaces at present,
we can handle them in the future.
thanks
Weiping Pan
Before activating a VLAN device, we should make sure that the underlying
physical ethernet device is up.
For example, before activating eth0.100, we should make sure that eth0 is up.
NetworkManager calls g_udev_client_query_by_subsystem() to get the device
list, and then activates each devices on that device list.
And luckily I found that the physical ethernet device is prior to VLAN device
on that device list, so there is nothing to do to make sure the activating
sequence between a VLAN device and its underlying physical ethernet device.
Signed-off-by: Weiping Pan
---
src/nm-system.c | 31 ++
src/nm-system.h |1 +
src/nm-udev-manager.c | 105 -
3 files changed, 136 insertions(+), 1 deletions(-)
diff --git a/src/nm-system.c b/src/nm-system.c
index 8696000..62d0961 100644
--- a/src/nm-system.c
+++ b/src/nm-system.c
@@ -1436,3 +1436,34 @@ free_cache:
nl_cache_free(cache);
return FALSE;
}
+
+/**
+ * nm_system_get_link_type:
+ * @name: name of link
+ *
+ * Lookup virtual link type. The returned string is allocated and needs
+ * to be freed after usage.
+ *
+ * Returns: Name of virtual link type or NULL if not a virtual link.
+ **/
+char *
+nm_system_get_link_type(const char *name)
+{
+ struct rtnl_link *result;
+ struct nl_sock *nlh;
+ char *type;
+
+ nlh = nm_netlink_get_default_handle ();
+ if (!nlh)
+ return NULL;
+
+ if (rtnl_link_get_kernel (nlh, 0, name,&result)< 0)
+ return NULL;
+
+ if ((type = rtnl_link_get_type (result)))
+ type = g_strdup(type);
+
+ rtnl_link_put (result);
+
+ return type;
+}
diff --git a/src/nm-system.h b/src/nm-system.h
index 93f942c..2f0e65c 100644
--- a/src/nm-system.h
+++ b/src/nm-system.h
@@ -92,4 +92,5 @@ gboolean nm_system_iface_set_mac
(int ifindex, const struct eth
gboolean nm_system_add_vlan_device(NMSettingVLAN *setting);
gboolean nm_system_del_vlan_device(NMSettingVLAN *setting);
+char * nm_system_get_link_type (const char *name);
#endif
diff --git a/src/nm-udev-manager.c b/src/nm-udev-manager.c
index e8c6b82..3634423 100644
--- a/src/nm-udev-manager.c
+++ b/src/nm-udev-manager.c
@@ -42,6 +42,12 @@
#include "nm-device-wimax.h"
#endif
+#include "nm-system.h"
+#include "nm-device-vlan.h"
+#include "nm-setting-vlan.h"
+#include "nm-netlink-monitor.h"
+#include
+
typedef struct {
GUdevClient *client;
@@ -388,6 +394,90 @@ is_wimax (const char *driver)
return g_strcmp0 (driver, "i2400m_usb") == 0;
}
+static gboolean
+is_vlan (const char *name)
+{
+ gboolean ret = FALSE;
+ struct rtnl_link *search_link = NULL;
+ struct nl_sock *nlh = NULL;
+ struct nl_cache *cache = NULL;
+
+ nlh = nm_netlink_get_default_handle();
+ if (!nlh)
+ return FALSE;
+
+ if (rtnl_link_alloc_cache(nlh,&cache)< 0)
+ return FAL
Re: [PATCH 4/6] VLAN: add NMDeviceVLAN
On 11/16/2011 01:54 PM, Dan Williams wrote:
On Fri, 2011-10-21 at 09:52 +0800, Weiping Pan wrote:
NMDeviceVLAN represents a VLAN device in NetworkManager.
When a VLAN device is created in kernel, NetworkManager will receive the event
and create a corresponding NMDeviceVLAN.
Like the setting, let's use NMDeviceVlan here for consistency.
Ok.
Signed-off-by: Weiping Pan
---
include/NetworkManager.h |1 +
src/Makefile.am |2 +
src/nm-device-vlan.c | 330 ++
src/nm-device-vlan.h | 59
4 files changed, 392 insertions(+), 0 deletions(-)
create mode 100644 src/nm-device-vlan.c
create mode 100644 src/nm-device-vlan.h
diff --git a/include/NetworkManager.h b/include/NetworkManager.h
index 3522dd2..87d7d7f 100644
--- a/include/NetworkManager.h
+++ b/include/NetworkManager.h
@@ -114,6 +114,7 @@ typedef enum {
NM_DEVICE_TYPE_OLPC_MESH = 6,
NM_DEVICE_TYPE_WIMAX = 7,
NM_DEVICE_TYPE_MODEM = 8,
+ NM_DEVICE_TYPE_VLAN = 9,
} NMDeviceType;
/**
diff --git a/src/Makefile.am b/src/Makefile.am
index cbcfdc6..e086024 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -126,6 +126,8 @@ NetworkManager_SOURCES = \
nm-device-bt.h \
nm-device-modem.h \
nm-device-modem.c \
+ nm-device-vlan.h \
+ nm-device-vlan.c \
nm-wifi-ap.c \
nm-wifi-ap.h \
nm-wifi-ap-utils.c \
diff --git a/src/nm-device-vlan.c b/src/nm-device-vlan.c
new file mode 100644
index 000..23abdbc
--- /dev/null
+++ b/src/nm-device-vlan.c
@@ -0,0 +1,330 @@
+/* -*- Mode: C; tab-width: 4; indent-tabs-mode: t; c-basic-offset: 4 -*- */
+/* NetworkManager -- Network link manager
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Copyright (C) 2011 Red Hat, Inc.
+ */
+
+#include
+#include
+
+#include "nm-system.h"
+#include "nm-device-vlan.h"
+#include "nm-device-interface.h"
+#include "nm-device-private.h"
+#include "nm-properties-changed-signal.h"
+#include "nm-marshal.h"
+#include "nm-logging.h"
+
+static void device_interface_init (NMDeviceInterface *iface_class);
+
+G_DEFINE_TYPE_EXTENDED (NMDeviceVLAN, nm_device_vlan, NM_TYPE_DEVICE, 0,
+G_IMPLEMENT_INTERFACE (NM_TYPE_DEVICE_INTERFACE,
device_interface_init))
+
+#define NM_DEVICE_VLAN_GET_PRIVATE(o) (G_TYPE_INSTANCE_GET_PRIVATE ((o),
NM_TYPE_DEVICE_VLAN, NMDeviceVLANPrivate))
+
+typedef struct {
+ char *interface_name;
+ guint32 vlan_id;
+ guint32 vlan_flags;
+ char *vlan_priority_ingress_map;
+ char *vlan_priority_egress_map;
+} NMDeviceVLANPrivate;
+
+enum {
+ PROP_0,
+ PROP_INTERFACE_NAME,
+ PROP_VLAN_ID,
+ PROP_VLAN_FLAGS,
+ PROP_VLAN_PRIORITY_INGRESS_MAP,
+ PROP_VLAN_PRIORITY_EGRESS_MAP,
+ LAST_PROP
+};
So for properties on the device (which get exported over D-Bus) it's
really only useful to have properties that clients are going to be
interested in; are all these properties interesting ones, or are they
mainly implementation details? Clients can get most of these properties
from the NMSettingVlan itself since they aren't going to change while
the interface is activated. Especially INTERFACE_NAME; that's already
handled by the parent class' 'interface' property. Basically, if a
property isn't going to change while the interface is activated/up, it
probably shouldn't be a property of the device, but clients can get it
via the connection data itself. We can always add device properties
later if we find clients want them for some reason, but we can't really
take them away.
When a vlan device is up, the client can only change
+ PROP_VLAN_FLAGS,
+ PROP_VLAN_PRIORITY_INGRESS_MAP,
+ PROP_VLAN_PRIORITY_EGRESS_MAP,
I test them with command vconfig.
I thought the client could change the name of vlan device,
either through "ip link set p2p4 name pwp", or rtnl_link_set_name(),
but both methods can work when the device is down.
So, I can remove PROP_INTERFACE_NAME and PROP_VLAN_ID here.
+static guint32
+real_get_generic_capabilities (NMDevice *device)
+{
+ return NM_DEVICE_CAP_NM_SUPPORTED;
+}
+
+static NMConnection *
+real_get_best_auto_connection (NMDe
Re: [PATCH 3/6] VLAN: create/delete kernel vlan device
On 11/16/2011 01:43 PM, Dan Williams wrote:
On Fri, 2011-10-21 at 09:52 +0800, Weiping Pan wrote:
We make use of libnl (>=3.2.1) to create/delete kernel vlan device,
and it can set vlan id, vlan flags and ingress/egress priority mapping.
Signed-off-by: Weiping Pan
---
src/nm-system.c | 234 +++
src/nm-system.h |3 +
2 files changed, 237 insertions(+), 0 deletions(-)
diff --git a/src/nm-system.c b/src/nm-system.c
index 62ab8b9..8696000 100644
--- a/src/nm-system.c
+++ b/src/nm-system.c
@@ -56,6 +56,7 @@
#include
#include
#include
+#include
static void nm_system_device_set_priority (int ifindex,
NMIP4Config *config,
@@ -1202,3 +1203,236 @@ nm_system_device_set_priority (int ifindex,
rtnl_route_put (found);
}
}
+
+static void priority_parser(GHashTable *table, char *str, const char *delim,
char *subdelim)
+{
+ char *str1, *str2, *token, *key = NULL, *value = NULL;
+ char *saveptr1, *saveptr2;
+ int j;
+
+ if (!table)
+ return;
+
+ for (j = 1, str1 = str; ; j++, str1 = NULL) {
+ int i;
+ token = strtok_r(str1, delim,&saveptr1);
+ if (token == NULL)
+ break;
+
+ i = 0;
+ for (str2 = token; ; str2 = NULL) {
+ if (i == 0) {
+ key = strtok_r(str2, subdelim,&saveptr2);
+ if (key == NULL)
+ break;
+ i++;
+ } else if (i == 1) {
+ value = strtok_r(str2, subdelim,&saveptr2);
+ if (value == NULL)
+ break;
+ i = 0;
+ g_hash_table_insert(table, key, value);
+ }
+ }
+ }
+
+}
+
+static void ingress_priority_iterator(gpointer key, gpointer value ,gpointer
user_data)
+{
+ struct rtnl_link *new_link = (struct rtnl_link *)user_data;
+ int from;
+ uint32_t to;
+
+ errno = 0;
+ from = strtol((char *)key, NULL, 10);
+ if (errno == ERANGE)
+ return;
+
+ errno = 0;
+ to = strtol((char *)value, NULL, 10);
+ if (errno == ERANGE)
+ return;
+ if ((from< 0) || (from> 7))
+ return;
+ rtnl_link_vlan_set_ingress_map(new_link, from, to);
+}
+
+static void egress_priority_iterator(gpointer key, gpointer value ,gpointer
user_data)
+{
+ struct rtnl_link *new_link = (struct rtnl_link *)user_data;
+ uint32_t from;
+ int to;
+
+ errno = 0;
+ from = strtol((char *)key, NULL, 10);
+ if (errno == ERANGE)
+ return;
+
+ errno = 0;
+ to = strtol((char *)value, NULL, 10);
+ if (errno == ERANGE)
+ return;
+ if ((to< 0) || (to> 7))
+ return;
+ rtnl_link_vlan_set_egress_map(new_link, from, to);
+}
+
+/**
+ * nm_system_add_vlan_device:
+ * @setting: NMSettingVLAN
+ *
+ * Add a VLAN device specified in setting.
+ *
+ * Returns: %TRUE on success, or %FALSE
+ */
+gboolean
+nm_system_add_vlan_device(NMSettingVLAN *setting)
+{
+ int ret = 0;
+ int if_index = 0;
+ struct rtnl_link *orig_link = NULL, *new_link = NULL;
+ struct nl_sock *nlh = NULL;
+ struct nl_cache *cache = NULL;
+
+ const char *interface_name = NULL;
+ const char *vlan_slave = NULL;
+ guint32 vlan_id = 0;
+ guint32 vlan_flags = 0;
+
+ const char *delim = ",";
+ char *subdelim = ":";
+ GHashTable *table;
+
+ vlan_slave = nm_setting_vlan_get_vlan_slave(setting);
+ if (!vlan_slave)
+ return FALSE;
+
+ vlan_id = nm_setting_vlan_get_vlan_id(setting);
+ if (vlan_id == 0)
+ return FALSE;
+
+ nlh = nm_netlink_get_default_handle();
+ if (!nlh)
+ return FALSE;
+
+ ret = rtnl_link_alloc_cache(nlh,&cache);
+ if (ret< 0)
+ return FALSE;
+
+ if (!cache)
+ return FALSE;
+
+ orig_link = rtnl_link_get_by_name(cache, vlan_slave);
+ if (!orig_link)
+ goto free_cache;
+
+ if_index = rtnl_link_get_ifindex(orig_link);
+ if (if_index<= 0)
+ goto free_orig_link;
We've got:
/* Generic utility functions */
int nm_netlink_iface_to_index (const char *iface);
char *nm_netlink_index_to_iface (int idx);
struct rtnl_link *nm_netlink_index_to_rtnl_link (int idx);
struct nl_sock * nm_netlink_get_default_handle (void);
in nm-netlink-monitor.c that we can use here to grab links and do
name<->index lookups. The one thing that's missing would be
nm_netlink_iface_to_rtnl_link() which we should
Re: [PATCH 2/6] VLAN: add ifcfg-vlan parser
On 11/16/2011 01:35 PM, Dan Williams wrote:
On Fri, 2011-10-21 at 09:52 +0800, Weiping Pan wrote:
The example of ifcfg-vlan is as followed:
VLAN=yes
TYPE=vlan
DEVICE=vlan43
PHYSDEV=eth9
Ideally here we also accept a MAC address or NM connection UUID as
PHYSDEV so you don't have to manually keep all the interface names in
sync.
Yes. I will put it in TODO list.
REORDER_HDR=0
VLAN_FLAGS=GVRP,LOOSE_BINDING
VLAN_INGRESS_PRIORITY_MAP=0:1,2:5
VLAN_EGRESS_PRIORITY_MAP=12:3,14:7
Are these new variables? ifup (F16) seems to think the only ones that
exist are VLAN (yes/no), REORDER_HDR, and GVRP.
But vconfig supports ingress/egress priority mapping,
so I think NetworkManager should support them, too.
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.43.149
NETMASK=255.255.255.0
And we try to make it compitable with the format used by initscripts,
and there is no need to change anything in ifcfg-eth9.
Pay attention the format of DEVICE here is 'vlan+id', and id is 0-4095.
Signed-off-by: Weiping Pan
---
libnm-util/Makefile.am |2 +
libnm-util/libnm-util.ver | 11 +
libnm-util/nm-connection.c | 25 ++-
libnm-util/nm-connection.h |2 +
libnm-util/nm-setting-vlan.c | 351
libnm-util/nm-setting-vlan.h | 93 +
src/settings/plugins/ifcfg-rh/common.h |1 +
src/settings/plugins/ifcfg-rh/reader.c | 143 -
.../network-scripts/ifcfg-test-vlan-interface | 11 +-
9 files changed, 622 insertions(+), 17 deletions(-)
create mode 100644 libnm-util/nm-setting-vlan.c
create mode 100644 libnm-util/nm-setting-vlan.h
diff --git a/libnm-util/Makefile.am b/libnm-util/Makefile.am
index 1529b4a..a6cf684 100644
--- a/libnm-util/Makefile.am
+++ b/libnm-util/Makefile.am
@@ -17,6 +17,7 @@ libnm_util_include_HEADERS = \
nm-setting-bluetooth.h \
nm-setting-connection.h \
nm-setting-ip4-config.h \
+ nm-setting-vlan.h \
nm-setting-ip6-config.h \
nm-setting-ppp.h\
nm-setting-pppoe.h \
@@ -46,6 +47,7 @@ libnm_util_la_csources = \
nm-setting-bluetooth.c \
nm-setting-connection.c \
nm-setting-ip4-config.c \
+ nm-setting-vlan.c \
nm-setting-ip6-config.c \
nm-setting-ppp.c\
nm-setting-pppoe.c \
diff --git a/libnm-util/libnm-util.ver b/libnm-util/libnm-util.ver
index 53c2482..9f3033e 100644
--- a/libnm-util/libnm-util.ver
+++ b/libnm-util/libnm-util.ver
@@ -30,6 +30,7 @@ global:
nm_connection_get_setting_wired;
nm_connection_get_setting_wireless;
nm_connection_get_setting_wireless_security;
+ nm_connection_get_setting_vlan;
nm_connection_get_type;
nm_connection_get_uuid;
nm_connection_is_type;
@@ -449,6 +450,16 @@ global:
nm_utils_wifi_find_next_channel;
nm_utils_wifi_freq_to_channel;
nm_utils_wifi_is_channel_valid;
+ nm_setting_vlan_error_get_type;
+ nm_setting_vlan_error_quark;
+ nm_setting_vlan_get_type;
+ nm_setting_vlan_new;
+ nm_setting_vlan_get_interface_name;
+ nm_setting_vlan_get_vlan_slave;
+ nm_setting_vlan_get_vlan_id;
+ nm_setting_vlan_get_vlan_flags;
+ nm_setting_vlan_get_vlan_priority_ingress_map;
+ nm_setting_vlan_get_vlan_priority_egress_map;
We probably want to kill the second 'vlan' here since these functions
are already part of the vlan setting, we can just name them:
nm_setting_vlan_get_slave;
nm_setting_vlan_get_id;
nm_setting_vlan_get_flags;
nm_setting_vlan_get_priority_ingress_map;
nm_setting_vlan_get_priority_egress_map;
Ok. I will remove the duplicate "vlan".
local:
*;
};
diff --git a/libnm-util/nm-connection.c b/libnm-util/nm-connection.c
index e3bbeae..2137352 100644
--- a/libnm-util/nm-connection.c
+++ b/libnm-util/nm-connection.c
@@ -44,6 +44,7 @@
#include "nm-setting-wireless-security.h"
#include "nm-setting-vpn.h"
#include "nm-setting-olpc-mesh.h"
+#include "nm-setting-vlan.h"
#include "nm-setting-serial.h"
#include "nm-setting-gsm.h"
@@ -135,7 +136,7 @@ static guint signals[LAST_SIGNAL] = { 0 };
static GHashTable *registered_settings = NULL;
-#define DEFAULT_MAP_SIZE 16
+#define DEFAULT_MAP_SIZE 17
static struct SettingInfo {
const char *name;
@@ -242,6 +243,11 @@ register_default_settings (void)
NM_SETTING_WIMAX_ERROR,
1, TRUE);
+ register_one_setting (NM_SETTING_VLAN_SETTING_NAME,
+ NM_TYPE_SETTING_VLAN,
+ NM_SETTING_VLAN_ERROR,
+ 1, TRUE);
+
Re: [PATCH 0/3] clean up config file handling
On Tuesday 15 of November 2011 18:23:19 Dan Williams wrote: > On Tue, 2011-11-15 at 13:38 +0100, Jirka Klimes wrote: > > On Friday 30 of September 2011 01:05:20 Dan Williams wrote: > > > On Thu, 2011-09-29 at 20:59 +0400, Yury G. Kudryashov wrote: > > > > Dan Williams wrote: > > > > > On Tue, 2011-09-27 at 10:27 -0500, Dan Williams wrote: > > > > >> Split config file reading and handling out of main.c so that it's > > > > >> easier to extend later on. > > > > > > > > > > And I accidentally pushed them. So if anyone has comments, let me > > > > > know and I'll push fixes. > > > > > > > > I saw that with the previous way of handling config file the plugins > > > > used /etc/NetworkManager/NetworkManager.conf even if NetworkManager > > > > is started with '-c' option. Is it still true? If yes, what about > > > > passing a 'config file handle' to plugins? > > > > > > You're right, that's still true. What should probably happen here is > > > that NMSettings should pass the config file path to the plugins when > > > they get created. Either we modify the factory function > > > (nm_system_config_factory) for each plugin, or we make the config file > > > a GObject property on the plugins that gets set by NMSettings right > > > after creating the plugin. I vote #1. Patches anyone? > > > > Solution #1 implemented, please review the patch. > > Looks good to me. > > Dan Pushed as 7b7e426b653a3a342d7b0522957283d0999a9070 Jirka ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
