[PATCH] core: improve keyfile error handling
* better error messages
* fix memory leak in parse_state_file ()
* create intermediate parent directories as needed for state file
---
src/main.c | 30 +-
src/nm-config.c | 13 ++---
2 files changed, 23 insertions(+), 20 deletions(-)
diff --git a/src/main.c b/src/main.c
index 59d7cd1..682cfcd 100644
--- a/src/main.c
+++ b/src/main.c
@@ -327,8 +327,8 @@ parse_state_file (const char *filename,
state_file = g_key_file_new ();
if (!state_file) {
- g_set_error (error, 0, 0,
-"Not enough memory to load state file.");
+ g_set_error (error, NM_CONFIG_ERROR, NM_CONFIG_ERROR_NO_MEMORY,
+"Not enough memory to load state file %s.",
filename);
return FALSE;
}
@@ -348,11 +348,12 @@ parse_state_file (const char *filename,
/* try to create the directory if it doesn't exist */
dirname = g_path_get_dirname (filename);
errno = 0;
- if (mkdir (dirname, 0755) != 0) {
+ if (g_mkdir_with_parents (dirname, 0755) != 0) {
if (errno != EEXIST) {
g_set_error (error, G_FILE_ERROR,
G_FILE_ERROR_ACCES,
-"Error creating state
directory %s: %d", dirname, errno);
+"Error creating state
directory %s: %s", dirname, strerror(errno));
g_free (dirname);
+ g_clear_error (&tmp_error);
return FALSE;
}
}
@@ -368,13 +369,15 @@ parse_state_file (const char *filename,
if (data)
ret = g_file_set_contents (filename, data, len,
error);
g_free (data);
+ g_clear_error (&tmp_error);
return ret;
} else {
- g_set_error_literal (error, tmp_error->domain,
tmp_error->code, tmp_error->message);
- g_clear_error (&tmp_error);
+ /* the error is not "No such file or directory" -
propagate the error */
+ g_propagate_error (error, tmp_error);
}
+ g_clear_error (&tmp_error);
/* Otherwise, file probably corrupt or inaccessible */
return FALSE;
}
@@ -384,34 +387,27 @@ parse_state_file (const char *filename,
*/
net = g_key_file_get_boolean (state_file, "main", "NetworkingEnabled",
&tmp_error);
if (tmp_error)
- g_set_error_literal (error, tmp_error->domain, tmp_error->code,
tmp_error->message);
+ g_clear_error (&tmp_error);
else
*net_enabled = net;
- g_clear_error (&tmp_error);
wifi = g_key_file_get_boolean (state_file, "main", "WirelessEnabled",
&tmp_error);
if (tmp_error) {
- g_clear_error (error);
- g_set_error_literal (error, tmp_error->domain, tmp_error->code,
tmp_error->message);
+ g_clear_error (&tmp_error);
} else
*wifi_enabled = wifi;
- g_clear_error (&tmp_error);
wwan = g_key_file_get_boolean (state_file, "main", "WWANEnabled",
&tmp_error);
if (tmp_error) {
- g_clear_error (error);
- g_set_error_literal (error, tmp_error->domain, tmp_error->code,
tmp_error->message);
+ g_clear_error (&tmp_error);
} else
*wwan_enabled = wwan;
- g_clear_error (&tmp_error);
wimax = g_key_file_get_boolean (state_file, "main", "WimaxEnabled",
&tmp_error);
if (tmp_error) {
- g_clear_error (error);
- g_set_error_literal (error, tmp_error->domain, tmp_error->code,
tmp_error->message);
+ g_clear_error (&tmp_error);
} else
*wimax_enabled = wimax;
- g_clear_error (&tmp_error);
g_key_file_free (state_file);
diff --git a/src/nm-config.c b/src/nm-config.c
index f52f06f..7e582f4 100644
--- a/src/nm-config.c
+++ b/src/nm-config.c
@@ -130,14 +130,14 @@ fill_from_file (NMConfig *config,
gboolean success = FALSE;
if (g_file_test (path, G_FILE_TEST_EXISTS) == FALSE) {
- g_set_error (error, G_KEY_FILE_ERROR,
G_KEY_FILE_ERROR_NOT_FOUND, "file not found");
+ g_set_error (error, G_KEY_FILE_ERROR,
G_KEY_FILE_ERROR_NOT_FOUND, "file %s not found", path);
return FALSE;
}
kf = g_key_file_new ();
if (!kf) {
g_set_error (error, NM_CONFIG_ERROR, NM_CONFIG_ERROR_NO_MEMORY,
-"N
Re: Changes to the proposed ModemManager DBus API
On Fri, 2011-09-30 at 15:01 +0200, Aleksander Morgado wrote: > Here is a set of changes to the proposed MM DBus API. Some of them were > already > discussed some time ago in the following thread: > https://mail.gnome.org/archives/networkmanager-list/2011-May/msg00162.html > > [PATCH 1/8] api: include ScanDevices() and SetLogging() in the new manager API > [PATCH 2/8] api: remove GetInfo() from the Modem API and use read-only > properties instead. > [PATCH 3/8] api: let the Modem expose a 'Sim' property to link to a specific > SIM object > [PATCH 4/8] api: let SignalQuality say if the given value was recently taken > [PATCH 5/8] api: new SetAllowedModes() to be able to modify the allowed mode > in the modem > [PATCH 6/8] api: new SetAllowedBands() to be able to modify the allowed bands > in the modem > [PATCH 7/8] api: rename MM_MODEM_ALLOWED_MODE to MM_MODEM_MODE 1 - 7 look fine to commit immediately. > [PATCH 8/8] api: Let MM_MODEM_MODE be a bitfield, and new PreferredMode > property Lets continue discussion on this one for now. Thanks! Dan > Comments and suggestions welcome, > > -- > Aleksander > ___ > 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: [PATCH 8/8] api: Let MM_MODEM_MODE be a bitfield, and new PreferredMode property
On Fri, 2011-09-30 at 15:01 +0200, Aleksander Morgado wrote: > Supported and Allowed modes are modified to be bitmasks of MM_MODEM_MODE > values, > and preference of a specific mode is now given in the new PreferredMode > property and as an extra argument to the SetAllowedModes() call. > > * Supported Modes: bitmask specifying which modes are supported by the > specific > hardware. For example, a modem may only support 1G/2G/3G connections (not 4G). > > * Allowed Modes: bitmask specifying which modes, of the ones Supported by the > modem, are allowed to use. For example, a modem may support 1G/2G/3G > connections > but only 1G and 2G connections are allowed by the user as 3G involves more > expensive data rates. > > [Allowed] ⊆ [Supported] > > * Preferred Mode: specific mode which is preferred among the ones defined in > the Allowed modes bitmask. For example, a modem may allow 1G/2G/3G connections > but the user would like that if possible 2G be used, as 3G consumes too much > battery. If 2G is not possible, 3G can be used. > > [Preferred] ∈ [Allowed] I don't have a huge objection to this, but I'm not sure I see the benefit of having the Preferred/Allowed split versus the complexity. Basically, if Allowed were an enum where we enumerated the preference there are 4 items to choose from (4G, 3G, 2G, empty) and 3 slots in the preference order (since empty doesn't get a slot, just a single enum). Thats a total of 25 combinations, but some like 2G>4G don't really make sense, so we have somewhere under 25. 32-bits gives us a lot of range there if it's an enum not a bitfield. The downside is that it has no relationship with the MM_MODEM_MODE flags. My worry is just that it's added complexity (3 properties to check instead of 2) that may be just a bit more work for clients. Dan > --- > new/org.freedesktop.ModemManager1.Modem.xml | 56 > ++- > 1 files changed, 29 insertions(+), 27 deletions(-) > > diff --git a/new/org.freedesktop.ModemManager1.Modem.xml > b/new/org.freedesktop.ModemManager1.Modem.xml > index 55a52aa..8da5680 100644 > --- a/new/org.freedesktop.ModemManager1.Modem.xml > +++ b/new/org.freedesktop.ModemManager1.Modem.xml > @@ -111,11 +111,16 @@ > > > value="impl_modem_set_allowed_mode"/> > - > + > >Bitmask of all the modes allowed in the modem. > > > + > + > + Specific mode preferred among the ones allowed, if any. > + > + > > > > @@ -296,6 +301,13 @@ > > > > + tp:type="MM_MODEM_MODE"> > + > +The preferred access technology (eg 2G/3G/4G), among the ones > defined in > +the allowed modes. Only one or none values must be given. > + > + > + > tp:type="MM_MODEM_MODE"> > > Access technology selection modes supported by the device. For POTS > @@ -492,38 +504,28 @@ > > > > -Describes the device's current access mode preference; ie the > specific > -technology preferences the device is allowed to use when connecting > to > -a network. Also used as a bitfield to indicate which allowed modes > -the modem supports when setting the mode preference. > +Bitfield to indicate which access modes are supported, allowed or > +preferred in a given device. > > - > - > - Any mode can be used (only this value allowed for POTS modems) > - > - > - > - Prefer 2G (GPRS or EDGE) > - > - > - Prefer 3G (UMTS or HSxPA) > + > + None > > - > - Prefer 4G (LTE) > + > +CSD, GSM > > - > - Use only 2G (GPRS or EDGE) > + > +GPRS, EDGE > > - > - Use only 3G (UMTS or HSxPA) > + > +UMTS, HSxPA > > - > - Use only 4G (LTE) > + > +LTE > > - > + > + > + Any mode can be used (only this value allowed for POTS modems) > + > > > ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 8/8] api: Let MM_MODEM_MODE be a bitfield, and new PreferredMode property
Hey Thomas, > > Supported and Allowed modes are modified to be bitmasks of MM_MODEM_MODE > > values, > > and preference of a specific mode is now given in the new PreferredMode > > property and as an extra argument to the SetAllowedModes() call. > > > > * Supported Modes: bitmask specifying which modes are supported by the > > specific > > hardware. For example, a modem may only support 1G/2G/3G connections (not > > 4G). > > > > * Allowed Modes: bitmask specifying which modes, of the ones Supported by > > the > > modem, are allowed to use. For example, a modem may support 1G/2G/3G > > connections > > but only 1G and 2G connections are allowed by the user as 3G involves more > > expensive data rates. > > > > [Allowed] ⊆ [Supported] > > > > * Preferred Mode: specific mode which is preferred among the ones defined > > in > > the Allowed modes bitmask. For example, a modem may allow 1G/2G/3G > > connections > > but the user would like that if possible 2G be used, as 3G consumes too much > > battery. If 2G is not possible, 3G can be used. > > Is it also possible to define the order? eg 1G/2G/3G are available and i > want to use 1) 2G, 2) 1G and 3) 3G? This wasn't possible before, and also not possible in this proposal, as there is only one Preferred Mode given here. If we would like to allow giving the order of priority to select the modes, as you suggest, we would need to give a list of mode values instead of just one single value. The key point here is what existing modems currently support. It would be great to allow in the API to specify a given order of modes, but then the modems should support that, and AFAIK no modem supports specifying such order. Some modems may allow to force using only 1G or 2G (e.g the Wavecom I've got, you can force it to setup a slow CS data connection), without any notion of having one 'preferred' mode; some other modems allow specifying "2G preferred" or "3G preferred", as we have in the 0.5 API. This proposal doesn't possibly cover all currently existing cases, but at least I tried to do so. Of course, if any given combination is not supported by the modem, the plugins can always return a GError in the SetAllowedModes() call. For example, modems without any notion of 'preferred' modes could allow only NONE to be set as Preferred mode. -- Aleksander ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 8/8] api: Let MM_MODEM_MODE be a bitfield, and new PreferredMode property
Hi Aleksander, the changes looking great. one question about the preferred mode (see below). On Fri, 2011-09-30 at 15:01 +0200, Aleksander Morgado wrote: > Supported and Allowed modes are modified to be bitmasks of MM_MODEM_MODE > values, > and preference of a specific mode is now given in the new PreferredMode > property and as an extra argument to the SetAllowedModes() call. > > * Supported Modes: bitmask specifying which modes are supported by the > specific > hardware. For example, a modem may only support 1G/2G/3G connections (not 4G). > > * Allowed Modes: bitmask specifying which modes, of the ones Supported by the > modem, are allowed to use. For example, a modem may support 1G/2G/3G > connections > but only 1G and 2G connections are allowed by the user as 3G involves more > expensive data rates. > > [Allowed] ⊆ [Supported] > > * Preferred Mode: specific mode which is preferred among the ones defined in > the Allowed modes bitmask. For example, a modem may allow 1G/2G/3G connections > but the user would like that if possible 2G be used, as 3G consumes too much > battery. If 2G is not possible, 3G can be used. Is it also possible to define the order? eg 1G/2G/3G are available and i want to use 1) 2G, 2) 1G and 3) 3G? Cheers, Tom ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 0.9 problem
30.09.2011 21:25, Dan Williams пишет: On Fri, 2011-09-30 at 21:10 +0300, Алекс Скоропад wrote: 30.09.2011 20:23, Dan Williams пишет: On Fri, 2011-09-30 at 20:03 +0300, Алекс Скоропад wrote: 30.09.2011 08:02, Dan Williams пишет: On Sun, 2011-09-25 at 19:11 +0300, Алекс Скоропад wrote: Here they are: Daemon.log - http://goo.gl/gf0q3 wpa_supplicant.log - http://goo.gl/VCEqA In this case, can you add the following to /etc/NetworkManager/NetworkManager.conf ? [logging] level=DEBUG domains=CORE,HW,DEVICE,WIFI,WIFI_SCAN Then restart NM, and try again? It appears that your AP is not broadcasting its SSID; but after the first time you connect NM should be able to cache the BSSID and automatically connect the next time. We need to see if NM is actually receiving the scan result from the supplicant first. Next, look at /var/lib/NetworkManager/seen-bssids and see if you find the BSSID 00:0e:f4:e0:fb:28 in it. Dan I added this section to NetworkManager.conf, but with this section network interface failed to configure: daemon.log - http://goo.gl/nk4t3 wpa_supplicant.log - http://goo.gl/1u4mu This could be one problem: Sep 30 19:29:49 Scaramush NetworkManager[1494]: (ra0): driver does not support SSID scans (scan_capa 0x00). This indicates that the driver you have is does not correctly support specific SSID scans, which are used to more quickly and easily connect to hidden SSID networks. This is a bug in the driver, as most upstream drivers included in the Linux kernel have advertised support for this feature since 2008 or 2009. Also, do you have any entry for 00:0e:f4:e0:fb:28 in /var/lib/NetworkManager/seen-bssids ? Dan Well, the problem was solved with driver from ralink, but this strings (ra0): driver does not support SSID scans (scan_capa 0x00). are still in logs Good to hear, but without the SSID scan capability it'll be somewhat slower to connect to hidden SSID networks. I've added more debug logging to NM to address this problem going forward, so if it happens again we have a better chance of determining why NM wasn't autoconnecting even though it seems to have been able to match the AP up with the stored SSID. Dan Thanks for help ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 0.9 problem
On Fri, 2011-09-30 at 21:10 +0300, Алекс Скоропад wrote: > 30.09.2011 20:23, Dan Williams пишет: > > On Fri, 2011-09-30 at 20:03 +0300, Алекс Скоропад wrote: > >> 30.09.2011 08:02, Dan Williams пишет: > >>> On Sun, 2011-09-25 at 19:11 +0300, Алекс Скоропад wrote: > Here they are: > Daemon.log - http://goo.gl/gf0q3 > wpa_supplicant.log - http://goo.gl/VCEqA > >>> In this case, can you add the following > >>> to /etc/NetworkManager/NetworkManager.conf ? > >>> > >>> [logging] > >>> level=DEBUG > >>> domains=CORE,HW,DEVICE,WIFI,WIFI_SCAN > >>> > >>> Then restart NM, and try again? It appears that your AP is not > >>> broadcasting its SSID; but after the first time you connect NM should be > >>> able to cache the BSSID and automatically connect the next time. We > >>> need to see if NM is actually receiving the scan result from the > >>> supplicant first. > >>> > >>> Next, look at /var/lib/NetworkManager/seen-bssids and see if you find > >>> the BSSID 00:0e:f4:e0:fb:28 in it. > >>> > >>> Dan > >>> > >> I added this section to NetworkManager.conf, but with this section > >> network interface failed to configure: > >> daemon.log - http://goo.gl/nk4t3 > >> wpa_supplicant.log - http://goo.gl/1u4mu > > This could be one problem: > > > > Sep 30 19:29:49 Scaramush NetworkManager[1494]: (ra0): driver > > does not support SSID scans (scan_capa 0x00). > > > > This indicates that the driver you have is does not correctly support > > specific SSID scans, which are used to more quickly and easily connect > > to hidden SSID networks. This is a bug in the driver, as most upstream > > drivers included in the Linux kernel have advertised support for this > > feature since 2008 or 2009. > > > > Also, do you have any entry for 00:0e:f4:e0:fb:28 > > in /var/lib/NetworkManager/seen-bssids ? > > > > Dan > > > Well, the problem was solved with driver from ralink, but this strings > > (ra0): driver does not support SSID scans (scan_capa 0x00). > > are still in logs Good to hear, but without the SSID scan capability it'll be somewhat slower to connect to hidden SSID networks. I've added more debug logging to NM to address this problem going forward, so if it happens again we have a better chance of determining why NM wasn't autoconnecting even though it seems to have been able to match the AP up with the stored SSID. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 0.9 problem
30.09.2011 20:23, Dan Williams пишет: On Fri, 2011-09-30 at 20:03 +0300, Алекс Скоропад wrote: 30.09.2011 08:02, Dan Williams пишет: On Sun, 2011-09-25 at 19:11 +0300, Алекс Скоропад wrote: Here they are: Daemon.log - http://goo.gl/gf0q3 wpa_supplicant.log - http://goo.gl/VCEqA In this case, can you add the following to /etc/NetworkManager/NetworkManager.conf ? [logging] level=DEBUG domains=CORE,HW,DEVICE,WIFI,WIFI_SCAN Then restart NM, and try again? It appears that your AP is not broadcasting its SSID; but after the first time you connect NM should be able to cache the BSSID and automatically connect the next time. We need to see if NM is actually receiving the scan result from the supplicant first. Next, look at /var/lib/NetworkManager/seen-bssids and see if you find the BSSID 00:0e:f4:e0:fb:28 in it. Dan I added this section to NetworkManager.conf, but with this section network interface failed to configure: daemon.log - http://goo.gl/nk4t3 wpa_supplicant.log - http://goo.gl/1u4mu This could be one problem: Sep 30 19:29:49 Scaramush NetworkManager[1494]: (ra0): driver does not support SSID scans (scan_capa 0x00). This indicates that the driver you have is does not correctly support specific SSID scans, which are used to more quickly and easily connect to hidden SSID networks. This is a bug in the driver, as most upstream drivers included in the Linux kernel have advertised support for this feature since 2008 or 2009. Also, do you have any entry for 00:0e:f4:e0:fb:28 in /var/lib/NetworkManager/seen-bssids ? Dan Well, the problem was solved with driver from ralink, but this strings (ra0): driver does not support SSID scans (scan_capa 0x00). are still in logs ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 0.9 problem
30.09.2011 20:23, Dan Williams пишет: On Fri, 2011-09-30 at 20:03 +0300, Алекс Скоропад wrote: 30.09.2011 08:02, Dan Williams пишет: On Sun, 2011-09-25 at 19:11 +0300, Алекс Скоропад wrote: Here they are: Daemon.log - http://goo.gl/gf0q3 wpa_supplicant.log - http://goo.gl/VCEqA In this case, can you add the following to /etc/NetworkManager/NetworkManager.conf ? [logging] level=DEBUG domains=CORE,HW,DEVICE,WIFI,WIFI_SCAN Then restart NM, and try again? It appears that your AP is not broadcasting its SSID; but after the first time you connect NM should be able to cache the BSSID and automatically connect the next time. We need to see if NM is actually receiving the scan result from the supplicant first. Next, look at /var/lib/NetworkManager/seen-bssids and see if you find the BSSID 00:0e:f4:e0:fb:28 in it. Dan I added this section to NetworkManager.conf, but with this section network interface failed to configure: daemon.log - http://goo.gl/nk4t3 wpa_supplicant.log - http://goo.gl/1u4mu This could be one problem: Sep 30 19:29:49 Scaramush NetworkManager[1494]: (ra0): driver does not support SSID scans (scan_capa 0x00). This indicates that the driver you have is does not correctly support specific SSID scans, which are used to more quickly and easily connect to hidden SSID networks. This is a bug in the driver, as most upstream drivers included in the Linux kernel have advertised support for this feature since 2008 or 2009. Also, do you have any entry for 00:0e:f4:e0:fb:28 in /var/lib/NetworkManager/seen-bssids ? Dan Yes, there is an entry in seen-bssids for 00:0E:F4:E0:FB:28. I use driver from ftp://ftp.dlink.ru/pub/Wireless/DWA-525/Drivers/Linux/ because it's the only one driver that work for me ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 0.9 problem
On Fri, 2011-09-30 at 20:03 +0300, Алекс Скоропад wrote: > 30.09.2011 08:02, Dan Williams пишет: > > On Sun, 2011-09-25 at 19:11 +0300, Алекс Скоропад wrote: > >> Here they are: > >> Daemon.log - http://goo.gl/gf0q3 > >> wpa_supplicant.log - http://goo.gl/VCEqA > > In this case, can you add the following > > to /etc/NetworkManager/NetworkManager.conf ? > > > > [logging] > > level=DEBUG > > domains=CORE,HW,DEVICE,WIFI,WIFI_SCAN > > > > Then restart NM, and try again? It appears that your AP is not > > broadcasting its SSID; but after the first time you connect NM should be > > able to cache the BSSID and automatically connect the next time. We > > need to see if NM is actually receiving the scan result from the > > supplicant first. > > > > Next, look at /var/lib/NetworkManager/seen-bssids and see if you find > > the BSSID 00:0e:f4:e0:fb:28 in it. > > > > Dan > > > I added this section to NetworkManager.conf, but with this section > network interface failed to configure: > daemon.log - http://goo.gl/nk4t3 > wpa_supplicant.log - http://goo.gl/1u4mu This could be one problem: Sep 30 19:29:49 Scaramush NetworkManager[1494]: (ra0): driver does not support SSID scans (scan_capa 0x00). This indicates that the driver you have is does not correctly support specific SSID scans, which are used to more quickly and easily connect to hidden SSID networks. This is a bug in the driver, as most upstream drivers included in the Linux kernel have advertised support for this feature since 2008 or 2009. Also, do you have any entry for 00:0e:f4:e0:fb:28 in /var/lib/NetworkManager/seen-bssids ? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 0.9 problem
30.09.2011 08:02, Dan Williams пишет: On Sun, 2011-09-25 at 19:11 +0300, Алекс Скоропад wrote: Here they are: Daemon.log - http://goo.gl/gf0q3 wpa_supplicant.log - http://goo.gl/VCEqA In this case, can you add the following to /etc/NetworkManager/NetworkManager.conf ? [logging] level=DEBUG domains=CORE,HW,DEVICE,WIFI,WIFI_SCAN Then restart NM, and try again? It appears that your AP is not broadcasting its SSID; but after the first time you connect NM should be able to cache the BSSID and automatically connect the next time. We need to see if NM is actually receiving the scan result from the supplicant first. Next, look at /var/lib/NetworkManager/seen-bssids and see if you find the BSSID 00:0e:f4:e0:fb:28 in it. Dan I added this section to NetworkManager.conf, but with this section network interface failed to configure: daemon.log - http://goo.gl/nk4t3 wpa_supplicant.log - http://goo.gl/1u4mu ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 0.9 problem
30.09.2011 08:02, Dan Williams пишет: On Sun, 2011-09-25 at 19:11 +0300, Алекс Скоропад wrote: Here they are: Daemon.log - http://goo.gl/gf0q3 wpa_supplicant.log - http://goo.gl/VCEqA In this case, can you add the following to /etc/NetworkManager/NetworkManager.conf ? [logging] level=DEBUG domains=CORE,HW,DEVICE,WIFI,WIFI_SCAN Then restart NM, and try again? It appears that your AP is not broadcasting its SSID; but after the first time you connect NM should be able to cache the BSSID and automatically connect the next time. We need to see if NM is actually receiving the scan result from the supplicant first. Next, look at /var/lib/NetworkManager/seen-bssids and see if you find the BSSID 00:0e:f4:e0:fb:28 in it. Dan I added this section to NetworkManager.conf, but with this section network interface failed to configure: daemon.log - http://goo.gl/nk4t3 wpa_supplicant.log - http://goo.gl/1u4mu ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] core: improving handling of rfkill
On Tue, 2011-09-20 at 16:36 +0800, Gary Ching-Pang Lin wrote:
> This commit improves the handling of rfkill.
>
> - The original two passes check gathers the states of platform
> and non-platform switches in two separate loops. Now we gather
> the both states in one loop and determine the final states later.
>
> - A new rule is used to determine the states of switches.
>
> if (platform_state == UNBLOCKED)
> choose non_platform_state;
> else
> choose platform_state;
>
> The state is UNBLOCKED if and only if both the platform and
> non-platform switches are unblocked, so the ambiguous state in
> bgo#655773 will not happen.
> See: https://bugzilla.gnome.org/show_bug.cgi?id=655773
Pushed, thanks.
Dan
> ---
> src/nm-udev-manager.c | 73
> -
> 1 files changed, 24 insertions(+), 49 deletions(-)
>
> diff --git a/src/nm-udev-manager.c b/src/nm-udev-manager.c
> index 72501c2..73c1f44 100644
> --- a/src/nm-udev-manager.c
> +++ b/src/nm-udev-manager.c
> @@ -189,84 +189,59 @@ sysfs_state_to_nm_state (gint sysfs_state)
> return RFKILL_UNBLOCKED;
> }
>
> +static RfKillState
> +aggregate_states (RfKillState platform, RfKillState non_platform)
> +{
> + if (platform == RFKILL_UNBLOCKED)
> + return non_platform;
> + else
> + return platform;
> +}
> +
> static void
> recheck_killswitches (NMUdevManager *self)
> {
> NMUdevManagerPrivate *priv = NM_UDEV_MANAGER_GET_PRIVATE (self);
> GSList *iter;
> RfKillState poll_states[RFKILL_TYPE_MAX];
> + RfKillState platform_states[RFKILL_TYPE_MAX];
> gboolean platform_checked[RFKILL_TYPE_MAX];
> int i;
>
> /* Default state is unblocked */
> for (i = 0; i < RFKILL_TYPE_MAX; i++) {
> poll_states[i] = RFKILL_UNBLOCKED;
> + platform_states[i] = RFKILL_UNBLOCKED;
> platform_checked[i] = FALSE;
> }
>
> - /* Perform two passes here; the first pass is for non-platform switches,
> - * which typically if hardkilled cannot be changed except by a physical
> - * hardware switch. The second pass checks platform killswitches, which
> - * take precedence over device killswitches, because typically platform
> - * killswitches control device killswitches. That is, a hardblocked
> device
> - * switch can often be unblocked by a platform switch. Thus if we have
> - * a hardblocked device switch and a softblocked platform switch, the
> - * combined state should be softblocked since the platform switch can be
> - * unblocked to change the device switch.
> - */
> -
> - /* Device switches first */
> + /* Gather the states of platform and non-platform switches */
> for (iter = priv->killswitches; iter; iter = g_slist_next (iter)) {
> Killswitch *ks = iter->data;
> GUdevDevice *device;
> RfKillState dev_state;
> int sysfs_state;
>
> - if (ks->platform == FALSE) {
> - device = g_udev_client_query_by_subsystem_and_name
> (priv->client, "rfkill", ks->name);
> - if (device) {
> - sysfs_state = g_udev_device_get_property_as_int
> (device, "RFKILL_STATE");
> - dev_state = sysfs_state_to_nm_state
> (sysfs_state);
> + device = g_udev_client_query_by_subsystem_and_name
> (priv->client, "rfkill", ks->name);
> + if (device) {
> + sysfs_state = g_udev_device_get_property_as_int
> (device, "RFKILL_STATE");
> + dev_state = sysfs_state_to_nm_state (sysfs_state);
> + if (ks->platform == FALSE) {
> if (dev_state > poll_states[ks->rtype])
> poll_states[ks->rtype] = dev_state;
> - g_object_unref (device);
> - }
> - }
> - }
> -
> - /* Platform switches next; their state overwrites device state */
> - for (iter = priv->killswitches; iter; iter = g_slist_next (iter)) {
> - Killswitch *ks = iter->data;
> - GUdevDevice *device;
> - RfKillState dev_state;
> - int sysfs_state;
> -
> - if (ks->platform == TRUE) {
> - device = g_udev_client_query_by_subsystem_and_name
> (priv->client, "rfkill", ks->name);
> - if (device) {
> - sysfs_state = g_udev_device_get_property_as_int
> (device, "RFKILL_STATE");
> - dev_state = sysfs_state_to_nm_state
> (sysfs_state);
> -
> - if (platform_checked[ks->rtype] == FALSE) {
> - /* Overwrite device state with platform
> state for first
> - * platform switch found.
> -
Re: Problem with auto connect to WLAN
Am Freitag, 30. September 2011, 07:40:39 schrieben Sie: > On Wed, 2011-09-21 at 10:55 +0200, Christian Ehrlicher wrote: > > Hello, > > > > I've a system config to automatically connect to a wlan. This works fine > > for the first start of the network manager. Once the wlan isn't > > available (the wlan router is out of range/the wlan router is not > > active) the network manager won't connect anymore to this wlan. Neither > > automatically nor via dbus call. Deactivating and activating the > > connection via dbus works fine as it should be. > > > > Any ideas? > > NetworkManager version 0.8.x (openSUSE 11.3 default) > > So when the WLAN isn't available, NM will retry connecting a few times > (as long as it's still in the scan list) and then will eventually fail > and mark the network as "disabled", and wait for you to manually > reconnect. We added a feature in 0.9 to clear that tag after a few > minutes. It would be a bit hard to backport to 0.8.x but could be done > if somebody had time. > Ok - then I've some more questions :) 1. Do I get an information about the disabling and can I reenable it somehow? 2. If 1. is not the case - how can I add a new connection via dbus? I currently use a system connection from a config file but would not mind providing the config over dbus if I would know how. 3. Where's the patch you mentioned so I can take a look on it? Thx, Christian ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 6/8] api: new SetAllowedBands() to be able to modify the allowed bands in the modem
Changing the allowed bands in a modem may fail, for example if trying to set a frequency band which is not in the bands mask reported as Supported by the modem. Therefore, we need an explicit SetAllowedBands() method with proper error reporting instead of making the property writable. --- new/org.freedesktop.ModemManager1.Modem.xml | 22 ++ 1 files changed, 18 insertions(+), 4 deletions(-) diff --git a/new/org.freedesktop.ModemManager1.Modem.xml b/new/org.freedesktop.ModemManager1.Modem.xml index 32666c2..3130140 100644 --- a/new/org.freedesktop.ModemManager1.Modem.xml +++ b/new/org.freedesktop.ModemManager1.Modem.xml @@ -118,6 +118,20 @@ + + +Set the radio frequency and technology bands the device is currently +allowed to use when connecting to a network. + + + + + + Bitmask of all the bands allowed in the modem. + + + + @@ -289,11 +303,11 @@ - + -The allowed radio frequency and technology bands the device is currently -allowed to use when connecting to a network. For POTS devices, only -the "any" value is supported. +The radio frequency and technology bands the device is currently allowed +to use when connecting to a network. For POTS devices, only the "any" +value is supported. -- 1.7.4.1 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 5/8] api: new SetAllowedModes() to be able to modify the allowed mode in the modem
Changing the allowed mode of a modem may fail, for example if trying to set a mode which is not in the modes reported as Supported by the modem. Therefore, we need an explicit SetAllowedModes() method with proper error reporting instead of making the property writable. --- new/org.freedesktop.ModemManager1.Modem.xml | 22 ++ 1 files changed, 18 insertions(+), 4 deletions(-) diff --git a/new/org.freedesktop.ModemManager1.Modem.xml b/new/org.freedesktop.ModemManager1.Modem.xml index 450a7a7..32666c2 100644 --- a/new/org.freedesktop.ModemManager1.Modem.xml +++ b/new/org.freedesktop.ModemManager1.Modem.xml @@ -104,6 +104,20 @@ + + +Set the access technologies (eg 2G/3G/4G preference) the device is +currently allowed to use when connecting to a network. + + + + + + Bitmask of all the modes allowed in the modem. + + + + @@ -260,11 +274,11 @@ - + -The allowed access technologies (eg 2G/3G/4G preference) the device is -currently allowed to use when connecting to a network. For POTS -devices, only the "any" mode is supported. +The access technologies (eg 2G/3G/4G preference) the device is currently +allowed to use when connecting to a network. For POTS devices, only the +"any" mode is supported. -- 1.7.4.1 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 7/8] api: rename MM_MODEM_ALLOWED_MODE to MM_MODEM_MODE
Makes more sense to have the enum named just as 'mode', as it applies to both Supported and Allowed. --- new/org.freedesktop.ModemManager1.Modem.xml |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/new/org.freedesktop.ModemManager1.Modem.xml b/new/org.freedesktop.ModemManager1.Modem.xml index 3130140..55a52aa 100644 --- a/new/org.freedesktop.ModemManager1.Modem.xml +++ b/new/org.freedesktop.ModemManager1.Modem.xml @@ -111,7 +111,7 @@ - + Bitmask of all the modes allowed in the modem. @@ -288,7 +288,7 @@ - + The access technologies (eg 2G/3G/4G preference) the device is currently allowed to use when connecting to a network. For POTS devices, only the @@ -296,7 +296,7 @@ - + Access technology selection modes supported by the device. For POTS devices, only the "any" mode will be returned. @@ -490,7 +490,7 @@ - + Describes the device's current access mode preference; ie the specific technology preferences the device is allowed to use when connecting to -- 1.7.4.1 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 8/8] api: Let MM_MODEM_MODE be a bitfield, and new PreferredMode property
Supported and Allowed modes are modified to be bitmasks of MM_MODEM_MODE values, and preference of a specific mode is now given in the new PreferredMode property and as an extra argument to the SetAllowedModes() call. * Supported Modes: bitmask specifying which modes are supported by the specific hardware. For example, a modem may only support 1G/2G/3G connections (not 4G). * Allowed Modes: bitmask specifying which modes, of the ones Supported by the modem, are allowed to use. For example, a modem may support 1G/2G/3G connections but only 1G and 2G connections are allowed by the user as 3G involves more expensive data rates. [Allowed] ⊆ [Supported] * Preferred Mode: specific mode which is preferred among the ones defined in the Allowed modes bitmask. For example, a modem may allow 1G/2G/3G connections but the user would like that if possible 2G be used, as 3G consumes too much battery. If 2G is not possible, 3G can be used. [Preferred] ∈ [Allowed] --- new/org.freedesktop.ModemManager1.Modem.xml | 56 ++- 1 files changed, 29 insertions(+), 27 deletions(-) diff --git a/new/org.freedesktop.ModemManager1.Modem.xml b/new/org.freedesktop.ModemManager1.Modem.xml index 55a52aa..8da5680 100644 --- a/new/org.freedesktop.ModemManager1.Modem.xml +++ b/new/org.freedesktop.ModemManager1.Modem.xml @@ -111,11 +111,16 @@ - + Bitmask of all the modes allowed in the modem. + + + Specific mode preferred among the ones allowed, if any. + + @@ -296,6 +301,13 @@ + + +The preferred access technology (eg 2G/3G/4G), among the ones defined in +the allowed modes. Only one or none values must be given. + + + Access technology selection modes supported by the device. For POTS @@ -492,38 +504,28 @@ -Describes the device's current access mode preference; ie the specific -technology preferences the device is allowed to use when connecting to -a network. Also used as a bitfield to indicate which allowed modes -the modem supports when setting the mode preference. +Bitfield to indicate which access modes are supported, allowed or +preferred in a given device. - - - Any mode can be used (only this value allowed for POTS modems) - - - - Prefer 2G (GPRS or EDGE) - - - Prefer 3G (UMTS or HSxPA) + + None - - Prefer 4G (LTE) + +CSD, GSM - - Use only 2G (GPRS or EDGE) + +GPRS, EDGE - - Use only 3G (UMTS or HSxPA) + +UMTS, HSxPA - - Use only 4G (LTE) + +LTE - + + + Any mode can be used (only this value allowed for POTS modems) + -- 1.7.4.1 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 4/8] api: let SignalQuality say if the given value was recently taken
Modems which only expose a single port will not be able to update the signal quality value while in connected mode. The signal quality value reported in this case, while the modem is connected, will be the last signal quality value read before the connection. The additional boolean value proposed here in the SignalQuality property will just say if the given signal quality was recently taken (if TRUE) or cached some time ago (if FALSE). The time to assume the value was recently taken or not could depend on different things, for example: * If the modem always has an AT port, even if connected, we could directly query the current signal quality and report the value as being fresh. * If the modem has a single port, we could report the value as not being fresh as soon as the modem gets in connected state. * For modems which report the signal quality updates in unsolicited messages, we could report the value as being fresh if the update was received in the last minute or so. --- new/org.freedesktop.ModemManager1.Modem.xml |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/new/org.freedesktop.ModemManager1.Modem.xml b/new/org.freedesktop.ModemManager1.Modem.xml index f2a8d00..450a7a7 100644 --- a/new/org.freedesktop.ModemManager1.Modem.xml +++ b/new/org.freedesktop.ModemManager1.Modem.xml @@ -251,11 +251,12 @@ - + Signal quality in percent (0 - 100) of the dominant access technology the device is using to communicate with the network. Always 0 for POTS -devices. +devices. The additional boolean value indicates if the quality value +given was recently taken. -- 1.7.4.1 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 2/8] api: remove GetInfo() from the Modem API and use read-only properties instead.
New 'Manufacturer', 'Model' and 'Revision properties are added, all being read-only strings. --- new/org.freedesktop.ModemManager1.Modem.xml | 37 +-- 1 files changed, 18 insertions(+), 19 deletions(-) diff --git a/new/org.freedesktop.ModemManager1.Modem.xml b/new/org.freedesktop.ModemManager1.Modem.xml index 15eb1b9..cc970c6 100644 --- a/new/org.freedesktop.ModemManager1.Modem.xml +++ b/new/org.freedesktop.ModemManager1.Modem.xml @@ -82,25 +82,6 @@ - - -Retrieve modem information, like the manufacturer, hardware version, -firmware version, etc. - - - - - - Dictionary containing various information about the modem, including - zero or more of the following items: - - manufacturer : (string) - model: (string) - version/revision : (string) - - - - Clear non-persistent configuration and state, and return the device to @@ -179,6 +160,24 @@ + + + The equipment manufacturer, as reported by the modem. + + + + + + The equipment model, as reported by the modem. + + + + + + The revision identification of the software, as reported by the modem. + + + A best-effort device identifier based on various device information like -- 1.7.4.1 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Changes to the proposed ModemManager DBus API
Here is a set of changes to the proposed MM DBus API. Some of them were already discussed some time ago in the following thread: https://mail.gnome.org/archives/networkmanager-list/2011-May/msg00162.html [PATCH 1/8] api: include ScanDevices() and SetLogging() in the new manager API [PATCH 2/8] api: remove GetInfo() from the Modem API and use read-only properties instead. [PATCH 3/8] api: let the Modem expose a 'Sim' property to link to a specific SIM object [PATCH 4/8] api: let SignalQuality say if the given value was recently taken [PATCH 5/8] api: new SetAllowedModes() to be able to modify the allowed mode in the modem [PATCH 6/8] api: new SetAllowedBands() to be able to modify the allowed bands in the modem [PATCH 7/8] api: rename MM_MODEM_ALLOWED_MODE to MM_MODEM_MODE [PATCH 8/8] api: Let MM_MODEM_MODE be a bitfield, and new PreferredMode property Comments and suggestions welcome, -- Aleksander ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 3/8] api: let the Modem expose a 'Sim' property to link to a specific SIM object
SIM objects will be listed as independent objects in the DBus API, and the 'Sim' property in a given modem object will specify which SIM object is in use. --- new/org.freedesktop.ModemManager1.Modem.xml |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/new/org.freedesktop.ModemManager1.Modem.xml b/new/org.freedesktop.ModemManager1.Modem.xml index cc970c6..f2a8d00 100644 --- a/new/org.freedesktop.ModemManager1.Modem.xml +++ b/new/org.freedesktop.ModemManager1.Modem.xml @@ -123,6 +123,12 @@ + + + The path of the SIM object available in this device, if any. + + + The generic family of access technologies the modem supports. Not all -- 1.7.4.1 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 1/8] api: include ScanDevices() and SetLogging() in the new manager API
These methods were available in the old API, and are needed in the new one. --- new/org.freedesktop.ModemManager1.xml | 20 1 files changed, 20 insertions(+), 0 deletions(-) diff --git a/new/org.freedesktop.ModemManager1.xml b/new/org.freedesktop.ModemManager1.xml index 6ec05da..92d232d 100644 --- a/new/org.freedesktop.ModemManager1.xml +++ b/new/org.freedesktop.ModemManager1.xml @@ -17,6 +17,26 @@ + + +Start a new scan for connected modem devices. + + + + + + + + +Set logging verbosity. + + + + One of [ERR, WARN, INFO, DEBUG]. + + + + A modem was added to the system. -- 1.7.4.1 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
