Re: Query regarding a NetworkManager error-code.
On Friday 25 of November 2011 21:25:18 Ajay Garg wrote: Thanks Jirka, I understood, that there needed a set of key-value pairs, to be added under the heading-setting '802-1x'. It is working now - I am able to connect to the WPA2-Enterprise network. Thanks a ton !! You're welcome. It's great that you got it working. You can find description of NM settings at [3]. A connection consists of settings, which in turn have some properties, see NetworkManagerConfiguration at [1]. The D-Bus API used to communicate with NM can be found at [2]. [1] http://live.gnome.org/NetworkManager - wiki page about NetworkManager [2] http://projects.gnome.org/NetworkManager/developers/api/09/spec.html - D- Bus API specifications [3] http://projects.gnome.org/NetworkManager/developers/api/09/ref- settings.html - specification of connection settings Jirka Ajay Garg wrote: You are a champ, Jirka. I am, in fact, trying to activate a connection - a WPA2-Enterprise type. The key-management is, in fact, wireless_security['key_mgmt'] = 'wpa-eap' I have also set wireless_security['proto'] = rsn wireless_security['pairwise'] = ['ccmp', 'tkip'] wireless_security['group'] = ['ccmp', 'tkip'] and also wireless_security['ssid']='Auto MTNL 'wireless_security['eap']='TTLS' wireless_security.['scan_ssid']=1 wireless_security['identity']=John Doe wireless_security['password']=hello wireless_security['phase2']=auth=PAP wireless_security['ca_cert']=/usr/local/etc/raddb/certs/ca.pem wireless_security['anonymous_identity']=anonymous but I see, the following (potentially non-fatal, but warnings nevertheless) logs: Nov 25 00:57:17 ajay NetworkManager[1451]: WARN one_property_cb(): Ignoring invalid property 'password' Nov 25 00:57:17 ajay NetworkManager[1451]: WARN one_property_cb(): Ignoring invalid property 'ca_cert' Nov 25 00:57:17 ajay NetworkManager[1451]: WARN one_property_cb(): Ignoring invalid property 'anonymous_identity' Nov 25 00:57:17 ajay NetworkManager[1451]: WARN one_property_cb(): Ignoring invalid property 'scan_ssid' Nov 25 00:57:17 ajay NetworkManager[1451]: WARN one_property_cb(): Ignoring invalid property 'ssid' Nov 25 00:57:17 ajay NetworkManager[1451]: WARN one_property_cb(): Ignoring invalid property 'identity' Nov 25 00:57:17 ajay NetworkManager[1451]: WARN one_property_cb(): Ignoring invalid property 'phase2' Nov 25 00:57:17 ajay NetworkManager[1451]: WARN one_property_cb(): Ignoring invalid property 'eap' Strangely, the above settings are seen as 'Config added:' when I do the connection via nm-applet, and not through python-dbus-apis. Obviously, I am able to connect through nm-applet, but not through python-dbus-apis. So, I am, in fact, missing the '802-1x' setting. Could you please let-me-know/point-to-the-relevant-docs the possible value(s) that wireless_security['802-1x'] may take? My 3-day long struggle may finally come to an end... Thanks for returning my confidence.. Regards, Ajay Jirka Klimes wrote: Your connection is not valid. You probaly have a connection which requires '802-1x' setting, but it is missing. The setting is required for ieee8021x or wpa-eap key management. List your connection with: nmcli con list id Auto MTNL You can create a valid connection using nm-connection-editor. Jirka ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Querying network state via D-Bus; unexpected result values
On Monday 28 of November 2011 02:14:07 Adam Tauno Williams wrote: I'm attempting to interrogate the state of the network condition via Network Manager's D-Bus service. I can reliably get a value, but the value seems incorrect. According to http://projects.gnome.org/NetworkManager/developers/spec-07.html#type-NM_D EVICE_STATE I expect to see a value of 8 [NM_DEVICE_STATE_ACTIVATED] if the device is online. But what I see from call is generally a 20 if the interface [Device 0, eth0] is unplugged and a value of 100 if the interface is online. The link you use is for NM 0.7, but according to device states value you apparently use NM 0.9 that changed state codes. So, 100 = NM_DEVICE_STATE_ACTIVATED now. The API spec for NM 0.9 is here: http://projects.gnome.org/NetworkManager/developers/api/09/spec.html#type- NM_DEVICE_STATE API spec for NM 0.8: http://projects.gnome.org/NetworkManager/developers/api/08/spec-08.html#type- NM_DEVICE_STATE Jirka #!/bin/env python import dbus bus = dbus.SystemBus() proxy = bus.get_object(org.freedesktop.NetworkManager, /org/freedesktop/NetworkManager) manager = dbus.Interface(proxy, org.freedesktop.NetworkManager) # Get device-specific state devices = manager.GetDevices() for d in devices: dev_proxy = bus.get_object(org.freedesktop.NetworkManager, d) prop_iface = dbus.Interface(dev_proxy, org.freedesktop.DBus.Properties) # Get the device's current state and interface name state = prop_iface.Get(org.freedesktop.NetworkManager.Device, State) name = prop_iface.Get(org.freedesktop.NetworkManager.Device, Interface) # and print them out print state if state == 8: # activated print Device %s is activated % name else: print Device %s is not activated % name ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Querying network state via D-Bus; unexpected result values [SOLVED]
On Mon, 2011-11-28 at 15:44 +0100, Jirka Klimes wrote: On Monday 28 of November 2011 02:14:07 Adam Tauno Williams wrote: I'm attempting to interrogate the state of the network condition via Network Manager's D-Bus service. I can reliably get a value, but the value seems incorrect. According to http://projects.gnome.org/NetworkManager/developers/spec-07.html#type-NM_D EVICE_STATE I expect to see a value of 8 [NM_DEVICE_STATE_ACTIVATED] if the device is online. But what I see from call is generally a 20 if the interface [Device 0, eth0] is unplugged and a value of 100 if the interface is online. The link you use is for NM 0.7, but according to device states value you apparently use NM 0.9 that changed state codes. So, 100 = NM_DEVICE_STATE_ACTIVATED now. The API spec for NM 0.9 is here: http://projects.gnome.org/NetworkManager/developers/api/09/spec.html#type- NM_DEVICE_STATE Ah, my bad. I tried changing the version(s) in the URL, but what I tried didn't work. #!/bin/env python import dbus bus = dbus.SystemBus() proxy = bus.get_object(org.freedesktop.NetworkManager, /org/freedesktop/NetworkManager) manager = dbus.Interface(proxy, org.freedesktop.NetworkManager) # Get device-specific state devices = manager.GetDevices() for d in devices: dev_proxy = bus.get_object(org.freedesktop.NetworkManager, d) prop_iface = dbus.Interface(dev_proxy, org.freedesktop.DBus.Properties) # Get the device's current state and interface name state = prop_iface.Get(org.freedesktop.NetworkManager.Device, State) name = prop_iface.Get(org.freedesktop.NetworkManager.Device, Interface) # and print them out print state if state == 8: # activated print Device %s is activated % name else: print Device %s is not activated % name ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
3GPP interface name in MM 0.6
Hey, According to the DBus specs [1], no element within a DBus interface can start with a digit... so org.freedesktop.ModemManager1.Modem.3gpp is a bad name. :-/ I will temporarily fallback to use: org.freedesktop.ModemManager1.Modem.Modem3gpp (along with org.freedesktop.ModemManager1.Modem.ModemCdma), but suggestions on how to rename that interface (so that no element starts with a digit) are very welcome. Cheers, [1] http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names -- Aleksander ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] core: add internet connectivity check
Hi Thomas, However if your long term goal is WISPr support, then you have to look at the whole page anyway. There is no guarantee that the WISPr XML is at the beginning. Some providers actually just attach it to the end. personally i don't care about WISPr. I just want to know if i have a working internet connection. Doing this without also handling WISPr seems rather pointless. I prefer my system to automatically log me into a hotspot if I have access credentials for it. why do you think that's pointless? eg i have a embedded device with an usb-gadget (detected as ethernet device). when i connect my pc with the device over usb, the device has no internet connection. but when i configure my pc to forward some traffic from the device, the device has internet connection. for this usecase it's very nice to check the connectivity. the device can do different task if a connection is available. I would solve that entirely different, but fair enough. would be interessting for me to know your solution for this. but that's not the point for NM. What about a solution with both - header check and content check. we add another field to the configuration file. Then we have 3 fields: - connectivity-uri - connectivit-response-header - connectivity-response-content if no uri is given, the check is disabled. if only a response-header is given, only the header will be checked if only a response-content is given, only the content will be checked (first with a simple string match. later we can implement something to handle WISPr) if both response-header and response-content are given, we check both. personally I do not care on how this gets solved or if this gets solved at all for NetworkManager. It is not my construction site. I personally would go straight for handling WISPr support and then the rest falls out of it for free. That is my experience since I spent way too much time traveling and looking a hotspots from different providers. And we have run into all the wrong directions already. Only deeply integrated support for WISPr can make this work. Options and variable string parsing is not going to help in the end. These are my 2 cents here. Take it or leave it. Regards Marcel ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[ModemManager] [PATCH] serial: report port-not-open in queueing commands via callback instead of just returning.
This is a followup to my previous change here; the port-not-open
situation is better treated as a manageable error condition rather
than a programming error.
- Nathan
From cec1bb628cd736fd0ac251e77e87f970cd78a4fb Mon Sep 17 00:00:00 2001
From: Nathan Williams n...@chromium.org
Date: Wed, 23 Nov 2011 16:16:20 -0500
Subject: [PATCH] serial: report port-not-open in queueing commands via callback instead of just returning.
This permits routines like mm-generic-gsm.c:simple_get_status() to
work again, as their callbacks get the error they are expecting. To
make this work, adapt get_csq_done() to handle a NULL response when
error is set, and make sure that multiple errors don't step on each
other in the mm_callback_info_chain() sequence created by
simple_get_status().
Change-Id: Ie3a72b1ce71b7f117e8b1f3da7a406c4d2da9e02
---
src/mm-generic-gsm.c | 14 +++---
src/mm-serial-port.c | 10 +-
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/src/mm-generic-gsm.c b/src/mm-generic-gsm.c
index d7a232e..d8ba4be 100644
--- a/src/mm-generic-gsm.c
+++ b/src/mm-generic-gsm.c
@@ -4187,7 +4187,7 @@ get_csq_done (MMAtSerialPort *port,
gpointer user_data)
{
MMCallbackInfo *info = (MMCallbackInfo *) user_data;
-char *reply = response-str;
+char *reply;
gboolean parsed = FALSE;
/* If the modem has already been removed, return without
@@ -4200,6 +4200,7 @@ get_csq_done (MMAtSerialPort *port,
goto done;
}
+reply = response-str;
if (!strncmp (reply, +CSQ: , 6)) {
/* Got valid reply */
int quality;
@@ -5596,6 +5597,9 @@ simple_status_got_signal_quality (MMModem *modem,
if (!error) {
properties = (GHashTable *) mm_callback_info_get_data (info, SS_HASH_TAG);
g_hash_table_insert (properties, signal_quality, simple_uint_value (result));
+} else {
+g_clear_error (info-error);
+info-error = g_error_copy (error);
}
mm_callback_info_chain_complete_one (info);
}
@@ -5612,6 +5616,9 @@ simple_status_got_band (MMModem *modem,
if (!error) {
properties = (GHashTable *) mm_callback_info_get_data (info, SS_HASH_TAG);
g_hash_table_insert (properties, band, simple_uint_value (result));
+} else {
+g_clear_error (info-error);
+info-error = g_error_copy (error);
}
mm_callback_info_chain_complete_one (info);
}
@@ -5631,9 +5638,10 @@ simple_status_got_reg_info (MMModemGsmNetwork *modem,
if (!modem || mm_callback_info_check_modem_removed (info))
return;
-if (error)
+if (error) {
+g_clear_error (info-error);
info-error = g_error_copy (error);
-else {
+} else {
properties = (GHashTable *) mm_callback_info_get_data (info, SS_HASH_TAG);
g_hash_table_insert (properties, registration_status, simple_uint_value (status));
diff --git a/src/mm-serial-port.c b/src/mm-serial-port.c
index 2d07214..ad5cd91 100644
--- a/src/mm-serial-port.c
+++ b/src/mm-serial-port.c
@@ -969,9 +969,17 @@ internal_queue_command (MMSerialPort *self,
MMQueueData *info;
g_return_if_fail (MM_IS_SERIAL_PORT (self));
-g_return_if_fail (priv-open_count 0);
g_return_if_fail (command != NULL);
+if (!(priv-open_count 0)) {
+GError *error = g_error_new_literal (MM_SERIAL_ERROR,
+ MM_SERIAL_ERROR_SEND_FAILED,
+ Sending command failed: device is not enabled);
+callback (self, NULL, error, user_data);
+g_error_free (error);
+return;
+}
+
info = g_slice_new0 (MMQueueData);
if (take_command)
info-command = command;
--
1.7.3.1
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] core: add internet connectivity check
Quoting Marcel Holtmann mar...@holtmann.org: I personally would go straight for handling WISPr support and then the rest falls out of it for free. I must confess, that I didn't know about WISPr before you mentioned it earlier in this thread. The Wikipedia article[1] suggests, that it has almost nothing to do with the problem Thomas is trying to solve, but maybe I'm completely out of tune. If I understand correctly, WISPr is a WiFi- and mobile network related roaming standard, that has to be supported by the network provider. OTOH, Thomas is trying to automate a check, whether a device has an internet connection (via LAN, WiFi, modem, whatever) or not, independent of the provider or its support of a certain protocol. While WISPr might be an interesting addition to NM, I fail to see the connection to Thomas problem and solution. But maybe this is due to my limited understanding of WISPr, or the brevity of Wikipedia on the subject. [1] http://en.wikipedia.org/wiki/WISPr ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
