Re: [PATCH] keyfile: include '\0' when copying string to array
2011/9/30 Dan Williams d...@redhat.com: On Fri, 2011-09-23 at 18:15 +0800, Gary Ching-Pang Lin wrote: This commit fixes the corrupted string in the copied array by including '\0' in the orignal string. This function gets used for SSIDs too though, and they can't have a trailing NULL. So we need to add the NULL for certificates, but not add it for SSIDs. Can you be more specific about where the corruption was happening and what the input data was that caused it? I think my description is misleading since it's not a real corruption. In reader.c:cert_parser(): if ( (array-len strlen (SCHEME_PATH)) g_str_has_prefix ((const char *) array-data, SCHEME_PATH) (array-data[array-len - 1] == '\0')) The if statement checks whether '\0' is in the end of array. However, this will never happen since get_uchar_array() never includes '\0'. In any case, there was one case which needed fixing, where obviously using new-style plain strings, keyfile wouldn't hit the first case where the string was already prefixed with the file:// scheme (since that code checked for NULL termination). I've pushed a rework of the code to fix that and make it more apparent what's going on. Can you check latest git master to see if that change fixes your issue? OK, I will apply the fix and test again! Thanks! Gary Lin ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Re: Wired + Wireless cohexistence issues, using libnl3
On Thu, 2011-09-29 at 18:09 -0500, Dan Williams wrote: On Wed, 2011-09-28 at 12:09 -0400, Mathieu Trudel-Lapierre wrote: So I actually found the cause for the missing routes in the libnl cache: in nm_netlink_foreach_route(), when rtnl_route_alloc_cache() is called, it is done with the NL_AUTO_PROVIDE flag. I don't know why this was added; but replacing it with 0 (no flags), fixes the issue with no apparent drawbacks. A patch is attached. Thomas, any idea what might be going on here? The cache is freed even though it is provided. The provide/require feature does not do reference counting so the pointer is stored for use even though it has been freed. Not sure if NM ever looks up the provided cache via _require() or if libnl uses it internally (I don't think libnl ever requires a route cache internally) but if either happens, it would cause memory corruption. ___ 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 @@ /arg /method +method name=ScanDevices + tp:docstring +Start a new scan for connected modem devices. + /tp:docstring + annotation name=org.freedesktop.DBus.GLib.Async value=/ + annotation name=org.freedesktop.DBus.GLib.CSymbol value=impl_manager_scan_devices/ +/method + +method name=SetLogging + annotation name=org.freedesktop.DBus.GLib.CSymbol value=impl_manager_set_logging/ + tp:docstring +Set logging verbosity. + /tp:docstring + arg name=level type=s direction=in +tp:docstring + One of [ERR, WARN, INFO, DEBUG]. +/tp:docstring + /arg +/method + signal name=ModemAdded tp:docstring 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
[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 @@ !-- PROPERTIES -- +property name=Sim type=o access=read + tp:docstring + The path of the SIM object available in this device, if any. + /tp:docstring +/property + property name=ModemCapabilities type=u access=read tp:type=MM_MODEM_CAPABILITIES tp:docstring 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
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 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 @@
/arg
/method
-method name=GetInfo
- tp:docstring
-Retrieve modem information, like the manufacturer, hardware version,
-firmware version, etc.
- /tp:docstring
- annotation name=org.freedesktop.DBus.GLib.Async value=/
- annotation name=org.freedesktop.DBus.GLib.CSymbol
value=impl_modem_get_info/
- arg name=info type=a{sv} direction=out
-tp:docstring
- Dictionary containing various information about the modem, including
- zero or more of the following items:
-
- manufacturer : (string)
- model: (string)
- version/revision : (string)
-/tp:docstring
- /arg
-/method
-
method name=Reset
tp:docstring
Clear non-persistent configuration and state, and return the device to
@@ -179,6 +160,24 @@
/tp:docstring
/property
+property name=Manufacturer type=s access=read
+ tp:docstring
+ The equipment manufacturer, as reported by the modem.
+ /tp:docstring
+/property
+
+property name=Model type=s access=read
+ tp:docstring
+ The equipment model, as reported by the modem.
+ /tp:docstring
+/property
+
+property name=Revision type=s access=read
+ tp:docstring
+ The revision identification of the software, as reported by the modem.
+ /tp:docstring
+/property
+
property name=DeviceIdentifier type=s access=read
tp:docstring
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
[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 @@ /tp:docstring /property -property name=SignalQuality type=u access=read +property name=SignalQuality type=ub access=read tp:docstring 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. /tp:docstring /property -- 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 @@ /tp:docstring annotation name=org.freedesktop.DBus.GLib.Async value=/ annotation name=org.freedesktop.DBus.GLib.CSymbol value=impl_modem_set_allowed_mode/ - arg name=mode type=u tp:type=MM_MODEM_MODE + arg name=allowed type=u tp:type=MM_MODEM_MODE tp:docstring Bitmask of all the modes allowed in the modem. /tp:docstring /arg + arg name=preferred type=u tp:type=MM_MODEM_MODE +tp:docstring + Specific mode preferred among the ones allowed, if any. +/tp:docstring + /arg /method method name=SetAllowedBands @@ -296,6 +301,13 @@ /tp:docstring /property +property name=PreferredMode type=u access=read tp:type=MM_MODEM_MODE + tp:docstring +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:docstring +/property + property name=SupportedModes type=u access=read tp:type=MM_MODEM_MODE tp:docstring Access technology selection modes supported by the device. For POTS @@ -492,38 +504,28 @@ tp:enum name=MM_MODEM_MODE type=u tp:docstring -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. /tp:docstring - tp:enumvalue suffix=ANY value=0x - tp:docstring - Any mode can be used (only this value allowed for POTS modems) - /tp:docstring - /tp:enumvalue - tp:enumvalue suffix=2G_PREFERRED value=0x0001 - tp:docstringPrefer 2G (GPRS or EDGE)/tp:docstring - /tp:enumvalue - tp:enumvalue suffix=3G_PREFERRED value=0x0002 - tp:docstringPrefer 3G (UMTS or HSxPA)/tp:docstring + tp:enumvalue suffix=NONE value=0x00 + tp:docstringNone/tp:docstring /tp:enumvalue - tp:enumvalue suffix=4G_PREFERRED value=0x0004 - tp:docstringPrefer 4G (LTE)/tp:docstring + tp:enumvalue suffix=1G value=0x01 +tp:docstringCSD, GSM/tp:docstring /tp:enumvalue - tp:enumvalue suffix=2G_ONLY value=0x0100 - tp:docstringUse only 2G (GPRS or EDGE)/tp:docstring + tp:enumvalue suffix=2G value=0x02 +tp:docstringGPRS, EDGE/tp:docstring /tp:enumvalue - tp:enumvalue suffix=3G_ONLY value=0x0200 - tp:docstringUse only 3G (UMTS or HSxPA)/tp:docstring + tp:enumvalue suffix=3G value=0x04 +tp:docstringUMTS, HSxPA/tp:docstring /tp:enumvalue - tp:enumvalue suffix=4G_ONLY value=0x0400 - tp:docstringUse only 4G (LTE)/tp:docstring + tp:enumvalue suffix=4G value=0x08 +tp:docstringLTE/tp:docstring /tp:enumvalue - !-- FIXME: what about 3G/4G only? or 2G/3G only? Should this be a - bitfield? If so, do we need to indicate what combinations the - modem supports? --- + tp:enumvalue suffix=ANY value=0x + tp:docstring + Any mode can be used (only this value allowed for POTS modems) + /tp:docstring /tp:enum tp:flags name=MM_MODEM_BAND value-prefix=MM_MODEM_BAND type=u -- 1.7.4.1 ___ networkmanager-list mailing list networkmanager-list@gnome.org
[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 @@ /tp:docstring annotation name=org.freedesktop.DBus.GLib.Async value=/ annotation name=org.freedesktop.DBus.GLib.CSymbol value=impl_modem_set_allowed_mode/ - arg name=mode type=u tp:type=MM_MODEM_ALLOWED_MODE + arg name=mode type=u tp:type=MM_MODEM_MODE tp:docstring Bitmask of all the modes allowed in the modem. /tp:docstring @@ -288,7 +288,7 @@ /tp:docstring /property -property name=AllowedModes type=u access=read tp:type=MM_MODEM_ALLOWED_MODE +property name=AllowedModes type=u access=read tp:type=MM_MODEM_MODE tp:docstring 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 @@ /tp:docstring /property -property name=SupportedModes type=u access=read tp:type=MM_MODEM_ALLOWED_MODE +property name=SupportedModes type=u access=read tp:type=MM_MODEM_MODE tp:docstring Access technology selection modes supported by the device. For POTS devices, only the any mode will be returned. @@ -490,7 +490,7 @@ /tp:enumvalue /tp:enum -tp:enum name=MM_MODEM_ALLOWED_MODE type=u +tp:enum name=MM_MODEM_MODE type=u tp:docstring 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 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 @@ /arg /method +method name=SetAllowedModes + tp:docstring +Set the access technologies (eg 2G/3G/4G preference) the device is +currently allowed to use when connecting to a network. + /tp:docstring + annotation name=org.freedesktop.DBus.GLib.Async value=/ + annotation name=org.freedesktop.DBus.GLib.CSymbol value=impl_modem_set_allowed_mode/ + arg name=mode type=u tp:type=MM_MODEM_ALLOWED_MODE +tp:docstring + Bitmask of all the modes allowed in the modem. +/tp:docstring + /arg +/method + !-- SIGNALS -- signal name=StateChanged @@ -260,11 +274,11 @@ /tp:docstring /property -property name=AllowedMode type=u access=readwrite tp:type=MM_MODEM_ALLOWED_MODE +property name=AllowedModes type=u access=read tp:type=MM_MODEM_ALLOWED_MODE tp:docstring -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. /tp:docstring /property -- 1.7.4.1 ___ 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 @@ /arg /method +method name=SetAllowedBands + tp:docstring +Set the radio frequency and technology bands the device is currently +allowed to use when connecting to a network. + /tp:docstring + annotation name=org.freedesktop.DBus.GLib.Async value=/ + annotation name=org.freedesktop.DBus.GLib.CSymbol value=impl_modem_set_allowed_band/ + arg name=mode type=u tp:type=MM_MODEM_BAND +tp:docstring + Bitmask of all the bands allowed in the modem. +/tp:docstring + /arg +/method + !-- SIGNALS -- signal name=StateChanged @@ -289,11 +303,11 @@ /tp:docstring /property -property name=AllowedBands type=t access=readwrite tp:type=MM_MODEM_BAND +property name=AllowedBands type=t access=read tp:type=MM_MODEM_BAND tp:docstring -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. /tp:docstring /property -- 1.7.4.1 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
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
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.
- */
- poll_states[ks-rtype] = dev_state;
-
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: 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]: info (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 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]:info (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
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]:info (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 info (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 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]:info (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 info (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: [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: [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
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 2G4G 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 @@ /tp:docstring annotation name=org.freedesktop.DBus.GLib.Async value=/ annotation name=org.freedesktop.DBus.GLib.CSymbol value=impl_modem_set_allowed_mode/ - arg name=mode type=u tp:type=MM_MODEM_MODE + arg name=allowed type=u tp:type=MM_MODEM_MODE tp:docstring Bitmask of all the modes allowed in the modem. /tp:docstring /arg + arg name=preferred type=u tp:type=MM_MODEM_MODE +tp:docstring + Specific mode preferred among the ones allowed, if any. +/tp:docstring + /arg /method method name=SetAllowedBands @@ -296,6 +301,13 @@ /tp:docstring /property +property name=PreferredMode type=u access=read tp:type=MM_MODEM_MODE + tp:docstring +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:docstring +/property + property name=SupportedModes type=u access=read tp:type=MM_MODEM_MODE tp:docstring Access technology selection modes supported by the device. For POTS @@ -492,38 +504,28 @@ tp:enum name=MM_MODEM_MODE type=u tp:docstring -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. /tp:docstring - tp:enumvalue suffix=ANY value=0x - tp:docstring - Any mode can be used (only this value allowed for POTS modems) - /tp:docstring - /tp:enumvalue - tp:enumvalue suffix=2G_PREFERRED value=0x0001 - tp:docstringPrefer 2G (GPRS or EDGE)/tp:docstring - /tp:enumvalue - tp:enumvalue suffix=3G_PREFERRED value=0x0002 - tp:docstringPrefer 3G (UMTS or HSxPA)/tp:docstring + tp:enumvalue suffix=NONE value=0x00 + tp:docstringNone/tp:docstring /tp:enumvalue - tp:enumvalue suffix=4G_PREFERRED value=0x0004 - tp:docstringPrefer 4G (LTE)/tp:docstring + tp:enumvalue suffix=1G value=0x01 +tp:docstringCSD, GSM/tp:docstring /tp:enumvalue - tp:enumvalue suffix=2G_ONLY value=0x0100 - tp:docstringUse only 2G (GPRS or EDGE)/tp:docstring + tp:enumvalue suffix=2G value=0x02 +tp:docstringGPRS, EDGE/tp:docstring /tp:enumvalue - tp:enumvalue suffix=3G_ONLY value=0x0200 - tp:docstringUse only 3G (UMTS or HSxPA)/tp:docstring + tp:enumvalue suffix=3G
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
[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,
-Not enough memory to load config file);
+
