from:"Jean Parpaillon"

SMS receiving question

2011-11-04 Thread Jean Parpaillon

Hi all,
I am using ModemManager to receive SMS with a Huawei E1752 USB modem.
I am plugged on signal SmsReceived but I receive nothing. I used ofono
stack to do the same things and it worked, but I can not run both ofono
and ModemManager at the same time.

Do you know if my issue comes from this particular modem or is  a known
ModemManager issue ? 

Best regards,
-- 
Jean Parpaillon
Pulse2 project leader

Mandriva SA - http://mandriva.com
Rennes - FR
Phone: +33 6 30 10 92 86
email: jparpail...@mandriva.com
jabber: jean.parpail...@gmail.com
skype: jean.parpaillon


signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: SMS receiving question

2011-11-04 Thread Jean Parpaillon

Hi,

Le vendredi 04 novembre 2011 à 11:14 -0500, Dan Williams a écrit :
 On Fri, 2011-11-04 at 09:20 -0400, Nathan Williams wrote:
  Do you have logs from ModemManager? If you run with --log-level=DEBUG,
  you should see the +CMTI notification when the SMS arrives, and we can
  see what MM does from that point forward.
 
 Via IRC yesterday, 

You may be confusing, I am not on the chan. But I should, and I will :)

 he said that he's got a Huawei E1550 ( I think I have
 one too) and that it responded with CMS ERROR: 303 to the AT
 +CNMI=2,1,2,1,0 request that MM sends.  Which is odd, because those
 appear to be legal values:
 
 AT+CNMI=?
 +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
 
 so obviously something isn't quite working with this device and the SIM
 card, and because we can't set the  message storage the CMTI
 notification isn't happening.
 
 Dan
 
  - Nathan
  
  On Fri, Nov 4, 2011 at 6:12 AM, Jean Parpaillon
  jparpail...@mandriva.com wrote:
   Hi all,
   I am using ModemManager to receive SMS with a Huawei E1752 USB modem.
   I am plugged on signal SmsReceived but I receive nothing. I used ofono
   stack to do the same things and it worked, but I can not run both ofono
   and ModemManager at the same time.
  
   Do you know if my issue comes from this particular modem or is  a known
   ModemManager issue ?
  
   Best regards,
   --
   Jean Parpaillon
   Pulse2 project leader
  
   Mandriva SA - http://mandriva.com
   Rennes - FR
   Phone: +33 6 30 10 92 86
   email: jparpail...@mandriva.com
   jabber: jean.parpail...@gmail.com
   skype: jean.parpaillon
  
   ___
   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
 
 
 


-- 
Jean Parpaillon
Pulse2 project leader

Mandriva SA - http://mandriva.com
Rennes - FR
Phone: +33 6 30 10 92 86
email: jparpail...@mandriva.com
jabber: jean.parpail...@gmail.com
skype: jean.parpaillon


signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH 1/2] Add CanWakeUp property to NMDevice

2011-10-13 Thread Jean Parpaillon

Hi,
Thank you for your feedback. Answers inside.

Le mercredi 12 octobre 2011 à 23:44 -0500, Dan Williams a écrit :
 On Wed, 2011-10-12 at 13:22 +0200, Jean Parpaillon wrote:
  From: Jean Parpaillon jean.parpail...@free.fr
 
 So what's the overall architecture here?  This is the implementation,
 clearly, but what goes into the device's virtual functions like
 can_wake_up() and prepare_wake_up()?
 

I must admit that I sent this hoping to (re?)start a discussion on the
subject.
My understanding is the following:
- for ethernet (or ethernet-like) devices, there is a common interface
for wakeup capable devices. It mainly consist in enable/disable wakeup
and, for some devices, setting a 'secret'
- this interface have been (partly) generalized with the ACPI syfs
interface. Each (capable) device has a wakeup file in his sysfs
structure in where you can write enable/disable and this is suppose to
deal with power during S3 ACPI state and maybe more (rfkill ?, network
not disconnecting when calling kernel halt() ?) ?

My developments were stopped when I found that my laptop BIOS does not
support powering up mini PCIe device when in S3 state, as it was
supposed to be the case (thanks lenovo ;) )

So, in a first time, I needed to have this property to ensure
NetworkManager is not disconnecting the device when sleeping.
prepare_wakeup(), in my thoughts, must prepare the device for waking up
(!), which means, for instance, setting the secret for waking up. But
this is based on the device I use, which is ericsson F5521gw.
Nevertheless, I think that this architecture is pretty generic, as it is
also used by ethtool.

Of course, CanWakeUp should be consistent with ACPI wakeup property in
sysfs and prepare_wakeup() should just call a generic interface in the
kernel... which exists only in the (old ?) ethtool interface.


Does it make sense for you ? For what you can see, I have still a lot of
questions but I am really interested in discussing this subject to
provide a NM standardized way of dealing with wow.

 Also would be good to pull Matthew Garrett in here; we've had
 discussions about WOL/WOWLAN before.
 

Sure.

 Dan
 

Best regards,
Jean 

  ---
   introspection/nm-device.xml |5 
   libnm-glib/nm-device.c  |   48 
  +++
   libnm-glib/nm-device.h  |2 +
   src/nm-device-interface.c   |7 ++
   src/nm-device-interface.h   |2 +
   src/nm-device.c |   23 
   src/nm-device.h |4 +++
   7 files changed, 91 insertions(+), 0 deletions(-)
  
  diff --git a/introspection/nm-device.xml b/introspection/nm-device.xml
  index 5fdda96..2e29bb4 100644
  --- a/introspection/nm-device.xml
  +++ b/introspection/nm-device.xml
  @@ -97,6 +97,11 @@
   The general type of the network device; ie Ethernet, WiFi, etc.
 /tp:docstring
   /property
  +property name=CanWakeUp type=b access=readwrite 
  +  tp:docstring
  +If TRUE, the device can wake up the host when sleeping.
  +  /tp:docstring
  +/property
   
   method name=Disconnect
 annotation name=org.freedesktop.DBus.GLib.CSymbol 
  value=impl_device_disconnect/
  diff --git a/libnm-glib/nm-device.c b/libnm-glib/nm-device.c
  index f06c1e4..9b832d3 100644
  --- a/libnm-glib/nm-device.c
  +++ b/libnm-glib/nm-device.c
  @@ -55,6 +55,7 @@ typedef struct {
  NMDeviceCapabilities capabilities;
  gboolean managed;
  gboolean firmware_missing;
  +   gboolean can_wake_up;
  NMIP4Config *ip4_config;
  gboolean got_ip4_config;
  NMDHCP4Config *dhcp4_config;
  @@ -81,6 +82,7 @@ enum {
  PROP_CAPABILITIES,
  PROP_MANAGED,
  PROP_FIRMWARE_MISSING,
  +   PROP_CAN_WAKE_UP,
  PROP_IP4_CONFIG,
  PROP_DHCP4_CONFIG,
  PROP_IP6_CONFIG,
  @@ -304,6 +306,7 @@ register_for_property_changed (NMDevice *device)
  { NM_DEVICE_CAPABILITIES, _nm_object_demarshal_generic, 
  priv-capabilities },
  { NM_DEVICE_MANAGED,  _nm_object_demarshal_generic, 
  priv-managed },
  { NM_DEVICE_FIRMWARE_MISSING, _nm_object_demarshal_generic, 
  priv-firmware_missing },
  +   { NM_DEVICE_CAN_WAKE_UP,  _nm_object_demarshal_generic, 
  priv-can_wake_up },
  { NM_DEVICE_IP4_CONFIG,   demarshal_ip4_config, 
  priv-ip4_config },
  { NM_DEVICE_DHCP4_CONFIG, demarshal_dhcp4_config,   
  priv-dhcp4_config },
  { NM_DEVICE_IP6_CONFIG,   demarshal_ip6_config, 
  priv-ip6_config },
  @@ -452,6 +455,9 @@ get_property (GObject *object,
  case PROP_FIRMWARE_MISSING:
  g_value_set_boolean (value, nm_device_get_firmware_missing 
  (device));
  break;
  +   case PROP_CAN_WAKE_UP:
  +   g_value_set_boolean (value, nm_device_get_can_wake_up (device));
  +   break;
  case PROP_IP4_CONFIG:
  g_value_set_object (value, nm_device_get_ip4_config (device

[PATCH 2/2] Add nm_device_prepare_wake_up function to MNDevice, called when going to sleep and device is marked as 'CanWakeUp'

2011-10-12 Thread Jean Parpaillon

From: Jean Parpaillon jean.parpail...@free.fr

---
 src/nm-device.c |   20 ++--
 src/nm-device.h |1 +
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/src/nm-device.c b/src/nm-device.c
index 31a73c1..fdd5627 100644
--- a/src/nm-device.c
+++ b/src/nm-device.c
@@ -167,6 +167,8 @@ static gboolean can_assume_connections (NMDeviceInterface 
*device);
 
 static void nm_device_activate_schedule_stage5_ip_config_commit (NMDevice 
*self, int family);
 
+static void nm_device_prepare_wake_up (NMDevice *dev);
+
 static void nm_device_take_down (NMDevice *dev, gboolean wait, 
NMDeviceStateReason reason);
 
 static gboolean nm_device_bring_up (NMDevice *self, gboolean block, gboolean 
*no_firmware);
@@ -3296,6 +3298,17 @@ nm_device_bring_up (NMDevice *self, gboolean block, 
gboolean *no_firmware)
 }
 
 static void
+nm_device_prepare_wake_up (NMDevice *self)
+{
+   g_return_if_fail (NM_IS_DEVICE (self));
+   
+   nm_log_info (LOGD_DEVICE, (%s): preparing for waking up...);
+
+   if (NM_DEVICE_GET_CLASS (self)-prepare_wake_up)
+   NM_DEVICE_GET_CLASS (self)-prepare_wake_up (self);
+}
+
+static void
 nm_device_take_down (NMDevice *self, gboolean block, NMDeviceStateReason 
reason)
 {
g_return_if_fail (NM_IS_DEVICE (self));
@@ -3899,8 +3912,11 @@ nm_device_state_changed (NMDevice *device,
switch (state) {
case NM_DEVICE_STATE_UNMANAGED:
nm_device_set_firmware_missing (device, FALSE);
-   if (old_state  NM_DEVICE_STATE_UNMANAGED)
-   nm_device_take_down (device, TRUE, reason);
+   if (old_state  NM_DEVICE_STATE_UNMANAGED) {
+   if (priv-can_wake_up)
+   nm_device_prepare_wake_up (device);
+   else
+   nm_device_take_down (device, TRUE, reason);
break;
case NM_DEVICE_STATE_UNAVAILABLE:
if (old_state == NM_DEVICE_STATE_UNMANAGED || 
priv-firmware_missing) {
diff --git a/src/nm-device.h b/src/nm-device.h
index b7273de..fb450bf 100644
--- a/src/nm-device.h
+++ b/src/nm-device.h
@@ -70,6 +70,7 @@ typedef struct {
gboolean(*is_up) (NMDevice *self);
gboolean(*bring_up)  (NMDevice *self);
void(*take_down) (NMDevice *self);
+   void(*prepare_wake_up) (NMDevice *self);
 
void(* update_hw_address) (NMDevice *self);
void(* update_permanent_hw_address) (NMDevice *self);
-- 
1.7.6.3

___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NM dbus API bug ?

2011-10-06 Thread Jean Parpaillon

Thank you very much for your answer.

It actually solved my issue.


Jean

Le mercredi 05 octobre 2011 à 13:53 -0500, Dan Williams a écrit :
 On Tue, 2011-10-04 at 17:07 +0200, Jean Parpaillon wrote:
  Hi again :)
 
 Your original crash is a dbus-glib bug, which likely was a regression in
 dbus-glib 0.94 and is fixed by:
 
 http://cgit.freedesktop.org/dbus/dbus-glib/commit/?id=3e0828f57c3925ea9b63d22ab82d991a0fea0536
 
 ie it's been fixed in dbus-glib 0.96 and later.
 
  I'm quite confused on using NetworkManager DBUS API on master branch.
  1/ When getting the object with the path returned by
  NetworkManager.GetDevices() method, NM crashes (path is of the
  form: /org/freedesktop/NetworkManager/Devices/0)
 
 That is the correct form of paths.  Device names can change at runtime
 so they are not part of the object path as exposed over D-Bus.
 
  2/ If I get the Device object with path
  like /org/freedesktop/NetworkManager/Devices/eth0, I can get the object
  but Introspectable interface gives me no interface at all on this
  object. Strange...
 
 Right, because that's not actually an object that NetworkManager exports
 over D-Bus, which is why you won't get any introspection information.
 It could be a bug in the Python dbus bindings that you get an object
 here at all, but the Python bits us lazy bindings so they'll only look
 up the introspection information when you need it, which can be later
 than when you create the Interface object.
 
 In the end, the bug is in dbus-glib 0.94 and fixed in 0.96.
 
 Dan
 
  It is WIP ? It is supposed to work right now ?
  I can try to fix it, if someone gives me some hints :)
  
  Regards,
  Jean
  
  Le mardi 04 octobre 2011 à 14:15 +0200, Jean Parpaillon a écrit :
   Hi all,
   I'm using NetworkManager from master branch.
   
   Running the following python code crash NetworkManager:
   
   ###
   import dbus
   import sys
   
   NM_DBUS_SERVICE = org.freedesktop.NetworkManager
   NM_MANAGER_PATH = /org/freedesktop/NetworkManager
   NM_MANAGER_IFACE = org.freedesktop.NetworkManager
   NM_DEVICE_IFACE = org.freedesktop.NetworkManager.Device
   
   bus = dbus.SystemBus()
   
   manager_proxy = bus.get_object(NM_DBUS_SERVICE, NM_MANAGER_PATH)
   manager_iface = dbus.Interface(manager_proxy,
   dbus_interface=NM_MANAGER_IFACE)
   
   for device_path in manager_iface.GetDevices():
   print Device: %s % device_path
   
   device_proxy = bus.get_object(NM_DBUS_SERVICE, device_path)
   
   ###
   
   In a few words, it crashes when I try to get dbus proxy object with a
   path I get from GetDevices() method.
   The crashes produces the following backtrace:
   Oct  4 14:01:17 tiflis NetworkManager[26393]: warn caught signal 11.
   Generating backtrace...
   Oct  4 14:01:17 tiflis NetworkManager[26393]: *** START
   **
   Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
   0: /usr/sbin/NetworkManager (nm_logging_backtrace+0x3b) [0x45e3fb]
   Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
   1: /usr/sbin/NetworkManager (0x40+0x4470c1) [0x4470c1]
   Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
   2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fbdf74d9000+0x7fbdf74e8020)
   [0x7fbdf74e8020]
   Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
   3: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000
   +0x7fbdf79469b0) [0x7fbdf79469b0]
   Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
   4: /lib/libglib-2.0.so.0 (g_hash_table_foreach+0x43) [0x7fbdf6017bd3]
   Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
   5: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000
   +0x7fbdf794808c) [0x7fbdf794808c]
   Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
   6: /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x7fbdf76f5000+0x7fbdf7713371)
   [0x7fbdf7713371]
   Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
   7: /lib/x86_64-linux-gnu/libdbus-1.so.3 (dbus_connection_dispatch+0x380)
   [0x7fbdf7705270]
   Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
   8: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000
   +0x7fbdf7945675) [0x7fbdf7945675]
   Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
   9: /lib/libglib-2.0.so.0 (g_main_context_dispatch+0x1f3)
   [0x7fbdf60284a3]
   Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
   10: /lib/libglib-2.0.so.0 (0x7fbdf5fe3000+0x7fbdf6028c80)
   [0x7fbdf6028c80]
   Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
   11: /lib/libglib-2.0.so.0 (g_main_loop_run+0x182) [0x7fbdf60292f2]
   Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
   12: /usr/sbin/NetworkManager (main+0x1155) [0x4220f5]
   Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
   13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xfd)
   [0x7fbdf57f7ead]
   Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
   14: /usr/sbin/NetworkManager (0x40+0x42224d) [0x42224d]
   Oct  4 14:01:17 tiflis NetworkManager[26393]: *** END

NM dbus API bug ?

2011-10-04 Thread Jean Parpaillon

Hi all,
I'm using NetworkManager from master branch.

Running the following python code crash NetworkManager:

###
import dbus
import sys

NM_DBUS_SERVICE = org.freedesktop.NetworkManager
NM_MANAGER_PATH = /org/freedesktop/NetworkManager
NM_MANAGER_IFACE = org.freedesktop.NetworkManager
NM_DEVICE_IFACE = org.freedesktop.NetworkManager.Device

bus = dbus.SystemBus()

manager_proxy = bus.get_object(NM_DBUS_SERVICE, NM_MANAGER_PATH)
manager_iface = dbus.Interface(manager_proxy,
dbus_interface=NM_MANAGER_IFACE)

for device_path in manager_iface.GetDevices():
print Device: %s % device_path

device_proxy = bus.get_object(NM_DBUS_SERVICE, device_path)

###

In a few words, it crashes when I try to get dbus proxy object with a
path I get from GetDevices() method.
The crashes produces the following backtrace:
Oct  4 14:01:17 tiflis NetworkManager[26393]: warn caught signal 11.
Generating backtrace...
Oct  4 14:01:17 tiflis NetworkManager[26393]: *** START
**
Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
0: /usr/sbin/NetworkManager (nm_logging_backtrace+0x3b) [0x45e3fb]
Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
1: /usr/sbin/NetworkManager (0x40+0x4470c1) [0x4470c1]
Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fbdf74d9000+0x7fbdf74e8020)
[0x7fbdf74e8020]
Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
3: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000
+0x7fbdf79469b0) [0x7fbdf79469b0]
Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
4: /lib/libglib-2.0.so.0 (g_hash_table_foreach+0x43) [0x7fbdf6017bd3]
Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
5: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000
+0x7fbdf794808c) [0x7fbdf794808c]
Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
6: /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x7fbdf76f5000+0x7fbdf7713371)
[0x7fbdf7713371]
Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
7: /lib/x86_64-linux-gnu/libdbus-1.so.3 (dbus_connection_dispatch+0x380)
[0x7fbdf7705270]
Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
8: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000
+0x7fbdf7945675) [0x7fbdf7945675]
Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
9: /lib/libglib-2.0.so.0 (g_main_context_dispatch+0x1f3)
[0x7fbdf60284a3]
Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
10: /lib/libglib-2.0.so.0 (0x7fbdf5fe3000+0x7fbdf6028c80)
[0x7fbdf6028c80]
Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
11: /lib/libglib-2.0.so.0 (g_main_loop_run+0x182) [0x7fbdf60292f2]
Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
12: /usr/sbin/NetworkManager (main+0x1155) [0x4220f5]
Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xfd)
[0x7fbdf57f7ead]
Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
14: /usr/sbin/NetworkManager (0x40+0x42224d) [0x42224d]
Oct  4 14:01:17 tiflis NetworkManager[26393]: *** END
**


Any clue ?

-- 
Jean Parpaillon
RD Engineer
http://mandriva.com
+33 6 30 10 92 86
xmpp: jean.parpail...@gmail.com


signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NM dbus API bug ?

2011-10-04 Thread Jean Parpaillon

Hi again :)

I'm quite confused on using NetworkManager DBUS API on master branch.
1/ When getting the object with the path returned by
NetworkManager.GetDevices() method, NM crashes (path is of the
form: /org/freedesktop/NetworkManager/Devices/0)
2/ If I get the Device object with path
like /org/freedesktop/NetworkManager/Devices/eth0, I can get the object
but Introspectable interface gives me no interface at all on this
object. Strange...

It is WIP ? It is supposed to work right now ?
I can try to fix it, if someone gives me some hints :)

Regards,
Jean

Le mardi 04 octobre 2011 à 14:15 +0200, Jean Parpaillon a écrit :
 Hi all,
 I'm using NetworkManager from master branch.
 
 Running the following python code crash NetworkManager:
 
 ###
 import dbus
 import sys
 
 NM_DBUS_SERVICE = org.freedesktop.NetworkManager
 NM_MANAGER_PATH = /org/freedesktop/NetworkManager
 NM_MANAGER_IFACE = org.freedesktop.NetworkManager
 NM_DEVICE_IFACE = org.freedesktop.NetworkManager.Device
 
 bus = dbus.SystemBus()
 
 manager_proxy = bus.get_object(NM_DBUS_SERVICE, NM_MANAGER_PATH)
 manager_iface = dbus.Interface(manager_proxy,
 dbus_interface=NM_MANAGER_IFACE)
 
 for device_path in manager_iface.GetDevices():
 print Device: %s % device_path
 
 device_proxy = bus.get_object(NM_DBUS_SERVICE, device_path)
 
 ###
 
 In a few words, it crashes when I try to get dbus proxy object with a
 path I get from GetDevices() method.
 The crashes produces the following backtrace:
 Oct  4 14:01:17 tiflis NetworkManager[26393]: warn caught signal 11.
 Generating backtrace...
 Oct  4 14:01:17 tiflis NetworkManager[26393]: *** START
 **
 Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
 0: /usr/sbin/NetworkManager (nm_logging_backtrace+0x3b) [0x45e3fb]
 Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
 1: /usr/sbin/NetworkManager (0x40+0x4470c1) [0x4470c1]
 Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fbdf74d9000+0x7fbdf74e8020)
 [0x7fbdf74e8020]
 Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
 3: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000
 +0x7fbdf79469b0) [0x7fbdf79469b0]
 Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
 4: /lib/libglib-2.0.so.0 (g_hash_table_foreach+0x43) [0x7fbdf6017bd3]
 Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
 5: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000
 +0x7fbdf794808c) [0x7fbdf794808c]
 Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
 6: /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x7fbdf76f5000+0x7fbdf7713371)
 [0x7fbdf7713371]
 Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
 7: /lib/x86_64-linux-gnu/libdbus-1.so.3 (dbus_connection_dispatch+0x380)
 [0x7fbdf7705270]
 Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
 8: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000
 +0x7fbdf7945675) [0x7fbdf7945675]
 Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
 9: /lib/libglib-2.0.so.0 (g_main_context_dispatch+0x1f3)
 [0x7fbdf60284a3]
 Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
 10: /lib/libglib-2.0.so.0 (0x7fbdf5fe3000+0x7fbdf6028c80)
 [0x7fbdf6028c80]
 Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
 11: /lib/libglib-2.0.so.0 (g_main_loop_run+0x182) [0x7fbdf60292f2]
 Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
 12: /usr/sbin/NetworkManager (main+0x1155) [0x4220f5]
 Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xfd)
 [0x7fbdf57f7ead]
 Oct  4 14:01:17 tiflis NetworkManager[26393]: Frame
 14: /usr/sbin/NetworkManager (0x40+0x42224d) [0x42224d]
 Oct  4 14:01:17 tiflis NetworkManager[26393]: *** END
 **
 
 
 Any clue ?
 
 ___
 networkmanager-list mailing list
 networkmanager-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/networkmanager-list



-- 
Jean Parpaillon
RD Engineer
http://mandriva.com
+33 6 30 10 92 86
xmpp: jean.parpail...@gmail.com


signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Shutdown/hibernate/sleep events

2011-09-12 Thread Jean Parpaillon

Hi,

Le jeudi 08 septembre 2011 à 12:49 -0500, Dan Williams a écrit :
 On Thu, 2011-09-01 at 17:31 +0800, Daniel Yek wrote:
  On Thu, 2011-09-01 at 10:15 +0200, Jean Parpaillon wrote:
   I'm currently developing a solution leveraging wake on wireless feature
   on some new 3g modems. For this to work, SIM card must not be disabled
   when computer go to sleep. 
   Can someone point me the code which is responsible for handling SIM
   deactivation and sleep events ? It is in ModemManager ? NetworkManager ?
   linux driver itself ?
  
  I won't start with ModemManager, NetworkManager, or the driver.
  
  I will start with ACPI code and trace from there.
  
  ACPI does Power Management and 
  implements the policy of sleeping states.
  
  Not sure if the policy is extended up to ModemManager.
  
  I don't know any more than this (without doing the work,)
  so just take this as one other suggestion that you can look into.
 
 At the moment, here's what' happens with NM/MM.  When NM gets the signal
 to go to sleep, it disconnect active connections.  ModemManager
 currently knows nothing about sleep/wake, it depends on the driver or
 kernel stack to indicate to MM that the modem has been powered down
 (usually indicated by a USB bus disconnect of the modem device and
 associated serial ports).
 

Ok, thank you very much for your explanation.
It seems that USB power on sleep mode can be controlled through sysfs,
(when drivers handle this): see http://lwn.net/Articles/265034/

In my case, an Ericsson modem, the driver seems ok.

 When you say SIM card disabled what specifically do you mean?  Do you
 mean the modem should be left in powered-up mode and potentially
 registered with the network?  

Yes, exactly. The module may be registered to the network to be able to
receive a special message and wakeup.

 Normally the SIM card doesn't have much to
 do with this at all, it's that the modem isn't powered down (CFUN=0) and
 is allowed to stay registered.
 
 But as Daniel wrote, you first have to ensure that the kernel's USB
 stack allows the modem to remain powered and doesn't turn off the USB
 controller during suspend.
 
 So at this point it's more about the kernel drivers and USB stack than
 it is about userspace.  Once you've verified that the kernel provides
 the behavior you expect, then we can investigate what mechanisms the
 modem provides to userspace clients for this; ie does it keep the serial
 ports open across suspend/resume and thus on resume when the MM process
 is unfrozen, there's data to be read on the serial port?  

Yes, serial port must remain opened.

 Or is the
 serial port closed and we need to re-open it and read data?  That sort
 of thing.

If I understand well, I should provide a mechanism to tell
NetworkManager not shutting down certain interfaces when sleeping.
Furthermore, we could be able to provide a pre-sleep dispatch script in
order to prepare the modem to wake up the computer.

The specific AT commands to prepare the modem for waking up must be in a
separate script/hook/plugin as some of them are under NDA,
unfortunately. But I think that a proper architecture to handle wake on
wireless in a generic way could be useful, for the case of other devices
of this type.

Best regards,
Jean
 
 Dan
 
 
 


-- 
Jean Parpaillon
RD Engineer
http://mandriva.com
+33 6 30 10 92 86
xmpp: jean.parpail...@gmail.com


signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

SMS receiving question

Re: SMS receiving question

Re: [PATCH 1/2] Add CanWakeUp property to NMDevice

[PATCH 2/2] Add nm_device_prepare_wake_up function to MNDevice, called when going to sleep and device is marked as 'CanWakeUp'

Re: NM dbus API bug ?

NM dbus API bug ?

Re: NM dbus API bug ?

Re: Shutdown/hibernate/sleep events

8 matches

Site Navigation

Mail list logo

Footer information