[PATCH 2/2] cdma: add registration status notification
The current UI requires the user to mouse-over and reveal a tool
tip (or click an indicator) to discover the registration state
(aka polling). If the user inadvertently re-registers on a
roaming network, the operation is silent until the user decides
to check the applet for network status, possibly incurring
expensive roaming tariffs in the mean time.
So to prevent silent registration changes, alert the user with a
notification when the CDMA registration status changes to home or
to roaming.
Signed-off-by: Andrew Bird
---
src/applet-device-cdma.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/src/applet-device-cdma.c b/src/applet-device-cdma.c
index 7b0bf85..fe4cbaf 100644
--- a/src/applet-device-cdma.c
+++ b/src/applet-device-cdma.c
@@ -638,6 +638,26 @@ cdma_device_info_free (gpointer data)
}
static void
+notify_user_of_cdma_reg_change (CdmaDeviceInfo *info)
+{
+ guint32 mb_state = cdma_state_to_mb_state (info);
+
+ if (mb_state == MB_STATE_HOME) {
+ applet_do_notify_with_pref (info->applet,
+ _("CDMA network."),
+ _("You are now registered on the
home network."),
+ "nm-signal-100",
+
PREF_DISABLE_CONNECTED_NOTIFICATIONS);
+ } else if (mb_state == MB_STATE_ROAMING) {
+ applet_do_notify_with_pref (info->applet,
+ _("CDMA network."),
+ _("You are now registered on a
roaming network."),
+ "nm-signal-100",
+
PREF_DISABLE_CONNECTED_NOTIFICATIONS);
+ }
+}
+
+static void
reg_state_reply (DBusGProxy *proxy, DBusGProxyCall *call, gpointer user_data)
{
CdmaDeviceInfo *info = user_data;
@@ -648,6 +668,9 @@ reg_state_reply (DBusGProxy *proxy, DBusGProxyCall *call,
gpointer user_data)
G_TYPE_UINT, &cdma1x_state,
G_TYPE_UINT, &evdo_state,
G_TYPE_INVALID)) {
+ if ((info->cdma1x_state != cdma1x_state) || (info->evdo_state
!= evdo_state)) {
+ notify_user_of_cdma_reg_change (info);
+ }
info->cdma1x_state = cdma1x_state;
info->evdo_state = evdo_state;
applet_schedule_update_icon (info->applet);
@@ -837,6 +860,9 @@ reg_state_changed_cb (DBusGProxy *proxy,
{
CdmaDeviceInfo *info = user_data;
+ if ((info->cdma1x_state != cdma1x_state) || (info->evdo_state !=
evdo_state)) {
+ notify_user_of_cdma_reg_change (info);
+ }
info->cdma1x_state = cdma1x_state;
info->evdo_state = evdo_state;
info->skip_reg_poll = TRUE;
--
1.7.4.4
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 1/2] gsm: remove Ubuntu specific icon references
Signed-off-by: Andrew Bird
---
src/applet-device-gsm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/applet-device-gsm.c b/src/applet-device-gsm.c
index 206bb0b..e8865f0 100644
--- a/src/applet-device-gsm.c
+++ b/src/applet-device-gsm.c
@@ -1092,13 +1092,13 @@ notify_user_of_gsm_reg_change (GsmDeviceInfo *info)
applet_do_notify_with_pref (info->applet,
_("GSM network."),
_("You are now registered on the
home network."),
- "notification-gsm-high",
+ "nm-signal-100",
PREF_DISABLE_CONNECTED_NOTIFICATIONS);
} else if (mb_state == MB_STATE_ROAMING) {
applet_do_notify_with_pref (info->applet,
_("GSM network."),
_("You are now registered on a
roaming network."),
- "notification-gsm-high",
+ "nm-signal-100",
PREF_DISABLE_CONNECTED_NOTIFICATIONS);
}
}
--
1.7.4.4
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Slow mobile broadband detection
2011/6/15 Dan Williams : > Then grab full lsusb output like so: > > lsusb -v -d 08ff:2810 Hello, here is my output. If you'd like I'm at your disposal to apply the patch locally and test it. Thanks! $ sudo lsusb -v -d 19d2:0037 Bus 002 Device 004: ID 19d2:0037 ONDA Communication S.p.A. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x19d2 ONDA Communication S.p.A. idProduct 0x0037 bcdDevice0.00 iManufacturer 3 ONDA,Incorporated iProduct2 ONDA WCDMA Technologies MSM iSerial 4 P673M2ODCD01 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 108 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 1 ONDA Configuration bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber3 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 b
Re: Slow mobile broadband detection
On Wed, 2011-06-15 at 12:41 -0500, Dan Williams wrote: > Ok, so this probably indicates that we need to add your device to the > "sendsetup" quirk. If you run "lsusb" and find your device you'll get > something like: > > Bus 004 Device 002: ID 08ff:2810 AuthenTec, Inc. AES2810 > > Then grab full lsusb output like so: > > lsusb -v -d 08ff:2810 > > then we can go about doing that. Hi, here is my "slow" ZTE , let me know what bits do you add to kernel for I test it before enter in mail line, please. lsmod | grep optio option 16429 0 usb_wwan 10768 1 option usbserial 33200 2 option,usb_wwan lsusb -d 19d2:0001 -v Bus 002 Device 028: ID 19d2:0001 ONDA Communication S.p.A. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x19d2 ONDA Communication S.p.A. idProduct 0x0001 bcdDevice0.00 iManufacturer 1 Qualcomm, Incorporated iProduct2 ZTE CDMA Technologies MSM iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 85 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 3 Data Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 128 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 3 Data Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 3 Data Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval
Re: [PATCH] Add GSM registration status notification (V3)
On Wed, 2011-06-15 at 19:35 +0100, Andrew Bird (Sphere Systems) wrote:
> Hi Dan,
> Yep can do but I have no CDMA network here and know little about it, so
> I'll need someone to look over the registration states to check. Is that
> reasonable?
Yeah; basically the same as GSM for the applet side implementation.
Dan
> Thanks,
>
>
> Andrew
>
> On Wednesday 15 June 2011, Dan Williams wrote:
> > On Fri, 2011-06-10 at 16:13 +0100, Andrew Bird wrote:
> > > The current UI requires the user to mouse-over and reveal a tool
> > > tip (or click an indicator) to discover the registration state
> > > (aka polling). If the user inadvertently re-registers on a
> > > roaming network, the operation is silent until the user decides
> > > to check the applet for network status, possibly incurring
> > > expensive roaming tariffs in the mean time.
> > >
> > > So to prevent silent registration changes, alert the user with a
> > > notification when the GSM registration status changes to home or
> > > to roaming.
> >
> > Pushed to master and 0.8.x. Any takers for the CDMA equivalent?
> >
> > Dan
> >
> > > ---
> > >
> > > v1 -> v2: Fix incorrect mapping of reg_state to mb_state.
> > > v2 -> v3: Ensure we preserve the meaning of info->reg_state.
> > >
> > > Use the gsm_state_to_mb_state mapping function.
> > > Also handle the reply of GetRegistrationInfo().
> > >
> > > Signed-off-by: Andrew Bird
> > > ---
> > >
> > > src/applet-device-gsm.c | 34 +++---
> > > 1 files changed, 31 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/src/applet-device-gsm.c b/src/applet-device-gsm.c
> > > index 5d0d584..76fd81e 100644
> > > --- a/src/applet-device-gsm.c
> > > +++ b/src/applet-device-gsm.c
> > > @@ -1083,6 +1083,25 @@ parse_op_name (GsmDeviceInfo *info, const char
> > > *orig, const char *op_code)
> > >
> > > return find_provider_for_mcc_mnc (info->providers, orig);
> > >
> > > }
> > >
> > > +static void
> > > +notify_user_of_gsm_reg_change(GsmDeviceInfo *info)
> > > +{
> > > + guint32 mb_state = gsm_state_to_mb_state (info);
> > > +
> > > + if (mb_state == MB_STATE_HOME)
> > > + applet_do_notify_with_pref (info->applet,
> > > + _("GSM network."),
> > > + _("You are now registered on the
> home
> > > network."), +
> > > "notification-gsm-high",
> > > +
> PREF_DISABLE_CONNECTED_NOTIFICATIONS);
> > > + else if (mb_state == MB_STATE_ROAMING)
> > > + applet_do_notify_with_pref (info->applet,
> > > + _("GSM network."),
> > > + _("You are now registered on a
> roaming
> > > network."), +
> > > "notification-gsm-high",
> > > +
> PREF_DISABLE_CONNECTED_NOTIFICATIONS);
> > > +}
> > > +
> > >
> > > #define REG_INFO_TYPE (dbus_g_type_get_struct ("GValueArray",
> > > G_TYPE_UINT, G_TYPE_STRING, G_TYPE_STRING, G_TYPE_INVALID)) #define
> > > DBUS_TYPE_G_MAP_OF_VARIANT (dbus_g_type_get_map ("GHashTable",
> > > G_TYPE_STRING, G_TYPE_VALUE))
> > >
> > > @@ -1101,7 +1120,7 @@ reg_info_reply (DBusGProxy *proxy, DBusGProxyCall
> > > *call, gpointer user_data)
> > >
> > > if (array->n_values == 3) {
> > >
> > > value = g_value_array_get_nth (array, 0);
> > > if (G_VALUE_HOLDS_UINT (value))
> > >
> > > - new_state = g_value_get_uint (value);
> > > + new_state = g_value_get_uint (value) + 1;
> > >
> > > value = g_value_array_get_nth (array, 1);
> > > if (G_VALUE_HOLDS_STRING (value)) {
> > >
> > > @@ -1120,7 +1139,11 @@ reg_info_reply (DBusGProxy *proxy, DBusGProxyCall
> > > *call, gpointer user_data)
> > >
> > > g_value_array_free (array);
> > >
> > > }
> > >
> > > - info->reg_state = new_state + 1;
> > > + if (info->reg_state != new_state) {
> > > + info->reg_state = new_state;
> > > + notify_user_of_gsm_reg_change (info);
> > > + }
> > > +
> > >
> > > info->op_code = new_op_code;
> > > info->op_name = new_op_name;
> > >
> > > @@ -1281,8 +1304,13 @@ reg_info_changed_cb (DBusGProxy *proxy,
> > >
> > > gpointer user_data)
> > >
> > > {
> > >
> > > GsmDeviceInfo *info = user_data;
> > >
> > > + guint32 new_state = reg_state + 1;
> > > +
> > > + if (info->reg_state != new_state) {
> > > + info->reg_state = new_state;
> > > + notify_user_of_gsm_reg_change (info);
> > > + }
> > >
> > > - info->reg_state = reg_state + 1;
> > >
> > > g_free (info->op_code);
> > > info->op_code = strlen (op_code) ? g_strdup (op_code) : NULL;
> > > g_free (info->op_name);
>
___
[PATCH] Increase connect timeout for Icera
I'm still investigating why it sometimes takes so long to connect. This doesn't seem to happen with a Gobi 2000 modem. Eric From c5a5b9b626ddcb638a46a037bfddc93b9b1a Mon Sep 17 00:00:00 2001 From: Eric Shienbrood Date: Wed, 15 Jun 2011 13:55:20 -0400 Subject: [PATCH] Increase connect timeout from 30 to 60 seconds in Icera plugin. Connect times of longer than 30 seconds have been seen on the Samsung Y3300 when connecting to the AT&T network. --- plugins/mm-modem-icera.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/plugins/mm-modem-icera.c b/plugins/mm-modem-icera.c index 8933142..37e40f9 100644 --- a/plugins/mm-modem-icera.c +++ b/plugins/mm-modem-icera.c @@ -541,7 +541,7 @@ icera_connected (MMAtSerialPort *port, g_source_remove (priv->connect_pending_id); priv->connect_pending_data = info; -priv->connect_pending_id = g_timeout_add_seconds (30, icera_connect_timed_out, self); +priv->connect_pending_id = g_timeout_add_seconds (60, icera_connect_timed_out, self); } } -- 1.7.3.1 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Add GSM registration status notification (V3)
Hi Dan,
Yep can do but I have no CDMA network here and know little about it, so
I'll need someone to look over the registration states to check. Is that
reasonable?
Thanks,
Andrew
On Wednesday 15 June 2011, Dan Williams wrote:
> On Fri, 2011-06-10 at 16:13 +0100, Andrew Bird wrote:
> > The current UI requires the user to mouse-over and reveal a tool
> > tip (or click an indicator) to discover the registration state
> > (aka polling). If the user inadvertently re-registers on a
> > roaming network, the operation is silent until the user decides
> > to check the applet for network status, possibly incurring
> > expensive roaming tariffs in the mean time.
> >
> > So to prevent silent registration changes, alert the user with a
> > notification when the GSM registration status changes to home or
> > to roaming.
>
> Pushed to master and 0.8.x. Any takers for the CDMA equivalent?
>
> Dan
>
> > ---
> >
> > v1 -> v2: Fix incorrect mapping of reg_state to mb_state.
> > v2 -> v3: Ensure we preserve the meaning of info->reg_state.
> >
> > Use the gsm_state_to_mb_state mapping function.
> > Also handle the reply of GetRegistrationInfo().
> >
> > Signed-off-by: Andrew Bird
> > ---
> >
> > src/applet-device-gsm.c | 34 +++---
> > 1 files changed, 31 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/applet-device-gsm.c b/src/applet-device-gsm.c
> > index 5d0d584..76fd81e 100644
> > --- a/src/applet-device-gsm.c
> > +++ b/src/applet-device-gsm.c
> > @@ -1083,6 +1083,25 @@ parse_op_name (GsmDeviceInfo *info, const char
> > *orig, const char *op_code)
> >
> > return find_provider_for_mcc_mnc (info->providers, orig);
> >
> > }
> >
> > +static void
> > +notify_user_of_gsm_reg_change(GsmDeviceInfo *info)
> > +{
> > + guint32 mb_state = gsm_state_to_mb_state (info);
> > +
> > + if (mb_state == MB_STATE_HOME)
> > + applet_do_notify_with_pref (info->applet,
> > + _("GSM network."),
> > + _("You are now registered on the
home
> > network."), +
> > "notification-gsm-high",
> > +
PREF_DISABLE_CONNECTED_NOTIFICATIONS);
> > + else if (mb_state == MB_STATE_ROAMING)
> > + applet_do_notify_with_pref (info->applet,
> > + _("GSM network."),
> > + _("You are now registered on a
roaming
> > network."), +
> > "notification-gsm-high",
> > +
PREF_DISABLE_CONNECTED_NOTIFICATIONS);
> > +}
> > +
> >
> > #define REG_INFO_TYPE (dbus_g_type_get_struct ("GValueArray",
> > G_TYPE_UINT, G_TYPE_STRING, G_TYPE_STRING, G_TYPE_INVALID)) #define
> > DBUS_TYPE_G_MAP_OF_VARIANT (dbus_g_type_get_map ("GHashTable",
> > G_TYPE_STRING, G_TYPE_VALUE))
> >
> > @@ -1101,7 +1120,7 @@ reg_info_reply (DBusGProxy *proxy, DBusGProxyCall
> > *call, gpointer user_data)
> >
> > if (array->n_values == 3) {
> >
> > value = g_value_array_get_nth (array, 0);
> > if (G_VALUE_HOLDS_UINT (value))
> >
> > - new_state = g_value_get_uint (value);
> > + new_state = g_value_get_uint (value) + 1;
> >
> > value = g_value_array_get_nth (array, 1);
> > if (G_VALUE_HOLDS_STRING (value)) {
> >
> > @@ -1120,7 +1139,11 @@ reg_info_reply (DBusGProxy *proxy, DBusGProxyCall
> > *call, gpointer user_data)
> >
> > g_value_array_free (array);
> >
> > }
> >
> > - info->reg_state = new_state + 1;
> > + if (info->reg_state != new_state) {
> > + info->reg_state = new_state;
> > + notify_user_of_gsm_reg_change (info);
> > + }
> > +
> >
> > info->op_code = new_op_code;
> > info->op_name = new_op_name;
> >
> > @@ -1281,8 +1304,13 @@ reg_info_changed_cb (DBusGProxy *proxy,
> >
> > gpointer user_data)
> >
> > {
> >
> > GsmDeviceInfo *info = user_data;
> >
> > + guint32 new_state = reg_state + 1;
> > +
> > + if (info->reg_state != new_state) {
> > + info->reg_state = new_state;
> > + notify_user_of_gsm_reg_change (info);
> > + }
> >
> > - info->reg_state = reg_state + 1;
> >
> > g_free (info->op_code);
> > info->op_code = strlen (op_code) ? g_strdup (op_code) : NULL;
> > g_free (info->op_name);
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: UMTS usb stick MC998D (U998D): disconnect after 30-45 seconds
PS. maybe I've misinterpreted and you just wanted to say that nm/mm could be improved by handling the no carrier error better, so that subsequently I could use nm to reconnect without having to unplug and replug the modem (i.e. even if the real problem isn't solved, at least it would be less hassle to reconnect). Yes I would appreciate that; tell me if you've got patches for me to try. (I can also code in C, but I don't have much time.) PPS. another thing: so far it seems that the modem disconnects exactly when nm sends 'AT+CSQ', at least that's the point in time where the LED goes back to blinking and data transmission stops. Maybe it would never disconnect if nm didn't send that command (well I realize that probably this command is just asking for the status, but what do I know). Christian. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: UMTS usb stick MC998D (U998D): disconnect after 30-45 seconds
> Looks like the modem does signal NO CARRIER at 20:57:11 around when you
> say the connection crashed. One thing we could do is better handle the
That sounds like you think the modem was right in ending the
connection / thinking there is no signal. But this is weird for
several reasons:
- this always happens at around the same point in time after initial connect
- initial connect always works and data exchange works fast and well
till it blows up
- when it survives the magic point in time 20-35 seconds after initial
connect, the connection is stable, also, I can disconnect from nm and
reconnect and it will never blow up then.
- those 'crashes' ('blow ups', disconnects) happen independently of
how strong the signal is
- in my limited testing under Windows, the modem never crashed (I can
do more testing once I've reinstalled Windows somewhere)
So what I'm saying is that I've got no idea why the modem says "no
carrier", but it cannot be that there is no signal.
I suspect that either there's a bug in the modem that's only triggered
in some circumstances, or the "no carrier" answer is somewhat generic
and might mean something like "with the parameters that you requested
me to abide to, I cannot proceed", hence it might be an issue with the
configuration that nm sends to the modem.
Christian.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Add GSM registration status notification (V3)
On Fri, 2011-06-10 at 16:13 +0100, Andrew Bird wrote:
> The current UI requires the user to mouse-over and reveal a tool
> tip (or click an indicator) to discover the registration state
> (aka polling). If the user inadvertently re-registers on a
> roaming network, the operation is silent until the user decides
> to check the applet for network status, possibly incurring
> expensive roaming tariffs in the mean time.
>
> So to prevent silent registration changes, alert the user with a
> notification when the GSM registration status changes to home or
> to roaming.
Pushed to master and 0.8.x. Any takers for the CDMA equivalent?
Dan
> ---
> v1 -> v2: Fix incorrect mapping of reg_state to mb_state.
> v2 -> v3: Ensure we preserve the meaning of info->reg_state.
> Use the gsm_state_to_mb_state mapping function.
> Also handle the reply of GetRegistrationInfo().
>
> Signed-off-by: Andrew Bird
> ---
> src/applet-device-gsm.c | 34 +++---
> 1 files changed, 31 insertions(+), 3 deletions(-)
>
> diff --git a/src/applet-device-gsm.c b/src/applet-device-gsm.c
> index 5d0d584..76fd81e 100644
> --- a/src/applet-device-gsm.c
> +++ b/src/applet-device-gsm.c
> @@ -1083,6 +1083,25 @@ parse_op_name (GsmDeviceInfo *info, const char *orig,
> const char *op_code)
> return find_provider_for_mcc_mnc (info->providers, orig);
> }
>
> +static void
> +notify_user_of_gsm_reg_change(GsmDeviceInfo *info)
> +{
> + guint32 mb_state = gsm_state_to_mb_state (info);
> +
> + if (mb_state == MB_STATE_HOME)
> + applet_do_notify_with_pref (info->applet,
> + _("GSM network."),
> + _("You are now registered on the
> home network."),
> + "notification-gsm-high",
> +
> PREF_DISABLE_CONNECTED_NOTIFICATIONS);
> + else if (mb_state == MB_STATE_ROAMING)
> + applet_do_notify_with_pref (info->applet,
> + _("GSM network."),
> + _("You are now registered on a
> roaming network."),
> + "notification-gsm-high",
> +
> PREF_DISABLE_CONNECTED_NOTIFICATIONS);
> +}
> +
> #define REG_INFO_TYPE (dbus_g_type_get_struct ("GValueArray", G_TYPE_UINT,
> G_TYPE_STRING, G_TYPE_STRING, G_TYPE_INVALID))
> #define DBUS_TYPE_G_MAP_OF_VARIANT (dbus_g_type_get_map ("GHashTable",
> G_TYPE_STRING, G_TYPE_VALUE))
>
> @@ -1101,7 +1120,7 @@ reg_info_reply (DBusGProxy *proxy, DBusGProxyCall
> *call, gpointer user_data)
> if (array->n_values == 3) {
> value = g_value_array_get_nth (array, 0);
> if (G_VALUE_HOLDS_UINT (value))
> - new_state = g_value_get_uint (value);
> + new_state = g_value_get_uint (value) + 1;
>
> value = g_value_array_get_nth (array, 1);
> if (G_VALUE_HOLDS_STRING (value)) {
> @@ -1120,7 +1139,11 @@ reg_info_reply (DBusGProxy *proxy, DBusGProxyCall
> *call, gpointer user_data)
> g_value_array_free (array);
> }
>
> - info->reg_state = new_state + 1;
> + if (info->reg_state != new_state) {
> + info->reg_state = new_state;
> + notify_user_of_gsm_reg_change (info);
> + }
> +
> info->op_code = new_op_code;
> info->op_name = new_op_name;
>
> @@ -1281,8 +1304,13 @@ reg_info_changed_cb (DBusGProxy *proxy,
> gpointer user_data)
> {
> GsmDeviceInfo *info = user_data;
> + guint32 new_state = reg_state + 1;
> +
> + if (info->reg_state != new_state) {
> + info->reg_state = new_state;
> + notify_user_of_gsm_reg_change (info);
> + }
>
> - info->reg_state = reg_state + 1;
> g_free (info->op_code);
> info->op_code = strlen (op_code) ? g_strdup (op_code) : NULL;
> g_free (info->op_name);
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [RFC PATCH] ModemManager: fix USSD reception, network notifications, and network requests
On Thu, 2011-06-09 at 16:33 -0500, Dan Williams wrote:
> RFC patch; I'm tired and don't want to look at this anymore so somebody
> else double-check the cases for me. Because the code was sending the
> USSD request with a "notify me via unsolicited result code" tag, the
> response could come from any port, and in was coming from other ports on
> various devices. But the code expected the response on the main port,
> thus it got lost.
>
> So turn the USSD response processing into an unsolicited command handler
> instead, which allows us to process the response no matter where it
> comes from. This patch also enables network-initiated USSD
> notifications and requests since that's easy to add once the first thing
> here is done.
>
> I'm somewhat wary about having to cache the MMCallbackInfo from
> user-originated requests, since tracking the lifetime of those is easy
> to screw up. So any double-checking of that would be much appreciated.
I've pushed this.
Dan
> ---
> diff --git a/src/mm-generic-gsm.c b/src/mm-generic-gsm.c
> index bc718d1..d814c57 100644
> --- a/src/mm-generic-gsm.c
> +++ b/src/mm-generic-gsm.c
> @@ -120,7 +120,11 @@ typedef struct {
> gboolean loc_enabled;
> gboolean loc_signal;
>
> +gboolean ussd_enabled;
> +MMCallbackInfo *pending_ussd_info;
> MMModemGsmUssdState ussd_state;
> +char *ussd_network_request;
> +char *ussd_network_notification;
>
> /* SMS */
> GHashTable *sms_present;
> @@ -174,6 +178,10 @@ static void cmti_received (MMAtSerialPort *port,
> GMatchInfo *info,
> gpointer user_data);
>
> +static void cusd_received (MMAtSerialPort *port,
> + GMatchInfo *info,
> + gpointer user_data);
> +
> #define GS_HASH_TAG "get-sms"
> static GValue *simple_string_value (const char *str);
> static GValue *simple_uint_value (guint32 i);
> @@ -844,6 +852,10 @@ mm_generic_gsm_grab_port (MMGenericGsm *self,
> mm_at_serial_port_add_unsolicited_msg_handler (MM_AT_SERIAL_PORT
> (port), regex, cmti_received, self, NULL);
> g_regex_unref (regex);
>
> +regex = g_regex_new ("\\r\\n\\+CUSD:\\s*(.*)\\r\\n", G_REGEX_RAW |
> G_REGEX_OPTIMIZE, 0, NULL);
> +mm_at_serial_port_add_unsolicited_msg_handler (MM_AT_SERIAL_PORT
> (port), regex, cusd_received, self, NULL);
> +g_regex_unref (regex);
> +
> if (ptype == MM_PORT_TYPE_PRIMARY) {
> priv->primary = MM_AT_SERIAL_PORT (port);
> if (!priv->data) {
> @@ -1412,6 +1424,21 @@ cind_cb (MMAtSerialPort *port,
> }
> }
>
> +static void
> +cusd_enable_cb (MMAtSerialPort *port,
> +GString *response,
> +GError *error,
> +gpointer user_data)
> +{
> +if (error) {
> +mm_warn ("(%s): failed to enable USSD notifications.",
> + mm_port_get_device (MM_PORT (port)));
> +return;
> +}
> +
> +MM_GENERIC_GSM_GET_PRIVATE (user_data)->ussd_enabled = TRUE;
> +}
> +
> void
> mm_generic_gsm_enable_complete (MMGenericGsm *self,
> GError *error,
> @@ -1462,6 +1489,9 @@ mm_generic_gsm_enable_complete (MMGenericGsm *self,
> mm_at_serial_port_queue_command (priv->primary, cmd, 3, NULL, NULL);
> g_free (cmd);
>
> +/* Enable USSD notifications */
> +mm_at_serial_port_queue_command (priv->primary, "+CUSD=1", 3,
> cusd_enable_cb, self);
> +
> mm_at_serial_port_queue_command (priv->primary, "+CIND=?", 3, cind_cb,
> self);
>
> /* Try one more time to get the SIM ID */
> @@ -1689,6 +1719,11 @@ disable_flash_done (MMSerialPort *port,
> mm_at_serial_port_queue_command (MM_AT_SERIAL_PORT (port), "+CREG=0", 3,
> NULL, NULL);
> mm_at_serial_port_queue_command (MM_AT_SERIAL_PORT (port), "+CGREG=0",
> 3, NULL, NULL);
>
> +if (priv->ussd_enabled) {
> +mm_at_serial_port_queue_command (MM_AT_SERIAL_PORT (port),
> "+CUSD=0", 3, NULL, NULL);
> +priv->ussd_enabled = FALSE;
> +}
> +
> if (priv->cmer_enabled) {
> mm_at_serial_port_queue_command (MM_AT_SERIAL_PORT (port),
> "+CMER=0", 3, NULL, NULL);
>
> @@ -1732,6 +1767,8 @@ disable (MMModem *modem,
>
> mm_generic_gsm_pending_registration_stop (MM_GENERIC_GSM (modem));
>
> +mm_generic_gsm_ussd_cleanup (MM_GENERIC_GSM (modem));
> +
> if (priv->poll_id) {
> g_source_remove (priv->poll_id);
> priv->poll_id = 0;
> @@ -4676,93 +4713,171 @@ ussd_update_state (MMGenericGsm *self,
> MMModemGsmUssdState new_state)
> }
> }
>
> +void
> +mm_generic_gsm_ussd_cleanup (MMGenericGsm *self)
> +{
> +MMGenericGsmPrivate *priv = MM_GENERIC_GSM_GET_PRIVATE (self);
> +
> +if (priv->pending_ussd_info) {
> +/* And schedule the callback */
> +g_clear_error (&priv->pending_ussd_info->error);
> +priv->pending_ussd_info->error = g_error_new_literal
Re: Add a "primary" attribute to provider in the mobile broadband provider info database
On Tue, 2011-06-07 at 13:58 -0700, Jason Glasgow wrote: > Any chance of pushing this? -Jason Done. > > On Fri, May 27, 2011 at 8:07 AM, Dan Williams wrote: > > On Thu, 2011-05-26 at 15:24 -0400, Jason Glasgow wrote: > > I've noticed that some providers (e.g. > AldiTalk/MedionMobile, blau.de, > > E-Plus, simyo Internet, NetCologne in Germany, or 3 in > Sweden) all > > share the same set of PLMNs in the mobile broadband provider > info > > (MBPI) database. This means that looking up a provider in > the database > > based on the PLMN yields more than one provider. After > talking to > > some providers, it appears that in certain instances one can > read the > > SPN file from the SIM card and use this to disambiguate > between the > > different provider entries in the database. > > > > > > Other carriers though have indicated that sometimes the SPN > file on > > the SIM is empty (or non existent), and in that case one > should select > > the 'primary' or default provider. > > > > > > I propose that we add an attribute to the provider entity to > indicate > > that it is the 'primary' provider for a given set of PLMNs. > > > > > > Attached is a patch that defines the attribute and applies > it to a few > > providers. > > > > > > Thoughts? > > > I think it's a fine idea. Anyone have objections? > > Dan > > > > > -Jason > > ___ > > 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: UMTS usb stick MC998D (U998D): disconnect after 30-45 seconds
On Sun, 2011-06-12 at 15:03 -0400, Christian Jaeger wrote: > A couple corrections/addons: > > The crash time window is between 20-~35 seconds from the point of the > connection being up, not 30-45 like I said. > > Upgrading the firmware of the stick (using the firmware upgrade > utility running on Windows) hasn't changed anything. > > This is in Canada, stick provided by Bell, used with the Bell network. > > Here are the debug logs from a run that crashed: > http://christianjaeger.ch/scratch/bell_novatel/crashrun1/ > > Also, there's some discussion going on now in the thread I originally > initiated a year ago on debian-user (already mentioned above, see: > http://forum.nginx.org/read.php?31,107067,202298 ). Looks like the modem does signal NO CARRIER at 20:57:11 around when you say the connection crashed. One thing we could do is better handle the NO CARRIER by disconnecting at exactly that point instead of treating the NO CARRIER error as a response to the AT+CSQ that gets sent. That might have some effect. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [ModemManager] Alternating AT and QCDM during port probing?
On Tue, 2011-06-14 at 21:38 -0500, Dan Williams wrote: > On Wed, 2011-06-15 at 00:35 +0200, Aleksander Morgado wrote: > > Hi Dan & list, > > > > Would it be a good idea to alternate QCDM port probing along with the AT > > port probing?, something like: > > * Try AT command(s) > > * If timeouts, try QCDM > > * If timeouts, try again AT command(s) > > * If timeouts, trya gain QCDM > > * If timeouts, try again AT command(s) > > * If timeouts, failed probing. > > > > In this way, QCDM ports would be detected after just 1 timeout ideally, > > and not after the 3 timeouts of the AT ports. Or even worse, as in the > > ZTE plugin for example, which needs 6 AT command timeouts before > > starting QCDM probing (3 ATE0+CPMS? and 3 AT+GCAP?). > > > > Or is there a good reason to leave QCDM probing always for after AT > > probing? > > I think it was after just because it was added later and I didn't want > to destabilize things too badly. But this approach could work better, > yes. I don't believe there's a case where AT commands simply time out > without a response. One complication I just thought of was that some QCDM ports only respond after the second probe attempt, because the AT commands look like garbage to them, and the first QCDM command terminates the garbage with the HDLC frame marker (0x7E) so the second QCDM command is the only one actually readable by the port. We can work around that though by possibly sending 0x7E 0x7E when opening the port to clear out any previous garbage, perhaps? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Slow mobile broadband detection
On Wed, 2011-06-15 at 08:10 +0200, dave guandalino wrote: > > Except that patch only works for the 'option' driver, which is where > > most 3G modem USB IDs should be added. If your device's IDs aren't > > there, you can't take advantage of the fix. What are your device's IDs? > > Well. How can I determine them and check if they are present or not? > > Btw, the 'option' driver gets loaded. > $ lsmod | grep option > option 25285 2 > usb_wwan 20407 1 option > usbserial 42908 7 option,usb_wwan Ok, so this probably indicates that we need to add your device to the "sendsetup" quirk. If you run "lsusb" and find your device you'll get something like: Bus 004 Device 002: ID 08ff:2810 AuthenTec, Inc. AES2810 Then grab full lsusb output like so: lsusb -v -d 08ff:2810 then we can go about doing that. Dan > $ modinfo option > filename: > /lib/modules/2.6.38-8-generic/kernel/drivers/usb/serial/option.ko > license:GPL > version:v0.7.2 > description:USB Driver for GSM modems > author: Matthias Urlichs > srcversion: 0D74972353E56E42A1951FF > alias: usb:v1EE8p000Bd*dc*dsc*dp*ic*isc*ip* > ...a lot of other alias lines... > > > > > Dan > > > >> > >> > > >> > Perazim > >> > > >> > On Thu, 2011-05-12 at 21:29 +0100, pera...@portugalmail.pt wrote: > >> >> > >> >> Dan, > >> >> > >> >> Attached are the messages log and the modem-manager log for the Alcatel > >> >> X220. > >> >> > >> >> Let me know if you need any other info or to test anything. > >> > > >> > These logs indicate a kernel bug, with a 30 second hang when closing a > >> > serial port. I submitted a patch to the kernel to fix this issue which > >> > was accepted for the 2.6.37 kernel: > >> > > >> > commit 02303f73373aa1da19dbec510ec5a4e2576f9610 > >> > Author: Dan Williams > >> > Date: Fri Nov 19 16:04:00 2010 -0600 > >> > > >> >usb-wwan: implement TIOCGSERIAL and TIOCSSERIAL to avoid blocking > >> > close(2) > >> > > >> >Some devices (ex ZTE 2726) simply don't respond at all when data is > >> > sent > >> >to some of their USB interfaces. The data gets stuck in the TTYs > >> > queue > >> >and sits there until close(2), which them blocks because closing_wait > >> >defaults to 30 seconds (even though the fd is O_NONBLOCK). This is > >> >rarely desired. Implement the standard mechanism to adjust > >> > closing_wait > >> >and let applications handle it how they want to. > >> > > >> >Signed-off-by: Dan Williams > >> > > >> > and the ModemManager snapshot you have should have the support necessary > >> > here. What kernel version are you running? > >> > > >> > Dan > >> > > >> > ___ > >> > 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 > > > > > > ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Cannot connect because "association took too long"
On Wed, 2011-06-15 at 16:10 +0200, Jirka Klimes wrote: > On Wednesday 27 of April 2011 22:36:32 Michal Sojka wrote: > > > > Hi and thanks for the reply. Here is the log. > > > > -Michal > > > > 1303936311.434616: EAP: EAP-Request Identity data - hexdump_ascii(len=44): > > 00 6e 65 74 77 6f 72 6b 69 64 3d 65 64 75 72 6f _networkid=eduro 61 6d > > 2c 6e 61 73 69 64 3d 61 73 62 2d 77 69 73 am,nasid=asb-wis 6d 35 2c 70 > > 6f 72 74 69 64 3d 32 39 m5,portid=29 1303936311.434650: EAP: > > using real identity - hexdump_ascii(len=19): 73 6f 6a 6b 61 6d 31 40 66 65 > > 6c 2e 63 76 75 74 sojk...@fel.cvut 2e 63 7a > > .cz > > 1303936311.434696: TX EAPOL - hexdump(len=28): 01 00 00 18 02 01 00 18 01 > > 73 6f 6a 6b 61 6d 31 40 66 65 6c 2e 63 76 75 74 2e 63 7a > Hmm, the delay of 30 seconds, here > > 1303936341.259024: RX EAPOL - hexdump(len=53): 02 00 00 31 01 02 00 31 01 > > 00 6e 65 74 77 6f 72 6b 69 64 3d 65 64 75 72 6f 61 6d 2c 6e 61 73 69 64 3d > > 61 73 62 2d 77 69 73 6d 35 2c 70 6f 72 74 69 64 3d 32 39 > > 1303936341.259142: EAP: EAP-Request Identity data - hexdump_ascii(len=44): > > 00 6e 65 74 77 6f 72 6b 69 64 3d 65 64 75 72 6f _networkid=eduro 61 6d > > 2c 6e 61 73 69 64 3d 61 73 62 2d 77 69 73 am,nasid=asb-wis 6d 35 2c 70 > > 6f 72 74 69 64 3d 32 39 m5,portid=29 1303936341.259178: EAP: > > using real identity - hexdump_ascii(len=19): 73 6f 6a 6b 61 6d 31 40 66 65 > > 6c 2e 63 76 75 74 sojk...@fel.cvut 2e 63 7a > > .cz > > 1303936341.259225: TX EAPOL - hexdump(len=28): 01 00 00 18 02 02 00 18 01 > > Could you capture the packet exchange by wireshark, so we can see if there is > really the delay or it is just processing issue in wpa_supplicant? Eduroam can sometimes be finicky; I think often the RADIUS servers are at different locations? Except that here after the 30 second delay things move very quickly which indicates that 30 second delay is quite unusual. Just to confirm, was the machine stationary during this log? Was the signal strength good? That would allow us to rule out packet retries at the driver level; and given that the exchange *after* the 30 second delay works very smoothly I would not expect the network to be heavily loaded either. Also if anyone could follow this up with Eduroam administrators and ask if they delay initial EAP authentication as a DoS prevention measure or anything like that? Or is the equipment just badly configured? Other than that, like Jirka suggests, we may have to break out wireshark and packet captures to figure out where the delay actually exists. Either the first EAP frame from the AP got lost, or the AP is just waiting for the RADIUS server to respond. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Issue with Indian Datacard
When I tried with your method after continue its not showing gdb promt again. One more thing.. and nm-applet is not crashing... but still my problem is not yet solved...still I am not able to connect?? If its configuration problem. Then I really like to know what should be done? so that it will work for it. Even on fedora 12 it was working very properly. I have been using same hardward for almost 6 months..just thinking why it was working on F12 ??? and why not working on F15 ?? With Regards, Manish S Runwal Runwalsoft.com From: Jirka Klimes To: networkmanager-list@gnome.org; Manish S Runwal Cc: Dan Williams Sent: Wednesday, 15 June 2011 6:52 PM Subject: Re: Issue with Indian Datacard On Tuesday 14 of June 2011 15:43:18 Manish S Runwal wrote: > Any update on this ? > Please, could you repeat the steps Dan wrote, but after 1) add an additional step: 1a) at the (gdb) prompt, type "continue" It is needed, so that nm-applet is run again (it is stopped when gdb attaches) Jirka > > From: Dan Williams > To: Manish S Runwal > Cc: "networkmanager-list@gnome.org" > Sent: Saturday, 4 June 2011 12:32 AM > Subject: Re: Issue with Indian Datacard > > On Thu, 2011-06-02 at 20:54 -0700, Manish S Runwal wrote: > > Hello Dan, > > Thank you for taking issue on table. > > > > > > I am not so advance in that. if you give me set of commands to execute > > then It will do the steps for you. > > I have tried to use abrt but..it downloading heavily debug+debuginfo > > so thats costing bandwidth. > > any other option ? > > If you install 'gdb' on your machine, you can do the following: > > 1) gdb attach `pidof nm-applet` > 2) then try to trigger the fault in nm-applet > 3) when you do, gdb will stop nm-applet and leave that terminal at the > "(gdb)" prompt > 4) at the (gdb) prompt, type "backtrace" > 5) copy and paste that output into an email reply > > Thanks, > Dan___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Trouble with privileges on dev version of NM
> For some reason it does not scan wireless > networks Please edit /etc/networks/interfaces, comment everything except the loopback network interface and do a #/etc/init.d/network-manager restart. This may solve the problem. > it requires root password to change connection settings. That connection was created using NetworkManagerSystemSettings and it is not a user setting. > Hello! > I'm testing the new NM DBus API, and for this I have installed git version > of > NM (19019a8e0be66fc4121a3885392f904025b86231). It seems to work > and compile, > but there is one issue. For some reason it does not scan wireless networks > (although it used to in 0.8), and also it requires root password to change > connection settings. I'm confused why it would behave this way. Is there any > documentation on how to set up the privileges for NM and nm-applet? Thank you, > Alex. > ___ > 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: NM: Connection order for devices
Quoting "Jirka Klimes" : With mac-address you restricted Connection 2 for the MAC. However, Connection 1 is not restricted and that's why it can be activated on any compatible device. If you want only to use Connection 1 on Device 1, restrict it with MAC the same way as Connection 2. You can also disable auto connecting for a connection, if you want. I think what's missing in NM for Tom (and me) is: 1. a restriction for "device type"(?), e.g. "usbN" or "ethM" (not sure about the correct terminology) 2. a restriction like "not MAC" Especially (1.) would be very useful to me. Would that be hard to implement? ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Cannot connect because "association took too long"
On Wednesday 27 of April 2011 22:36:32 Michal Sojka wrote: > > Hi and thanks for the reply. Here is the log. > > -Michal > > 1303936311.434616: EAP: EAP-Request Identity data - hexdump_ascii(len=44): > 00 6e 65 74 77 6f 72 6b 69 64 3d 65 64 75 72 6f _networkid=eduro 61 6d > 2c 6e 61 73 69 64 3d 61 73 62 2d 77 69 73 am,nasid=asb-wis 6d 35 2c 70 > 6f 72 74 69 64 3d 32 39 m5,portid=29 1303936311.434650: EAP: > using real identity - hexdump_ascii(len=19): 73 6f 6a 6b 61 6d 31 40 66 65 > 6c 2e 63 76 75 74 sojk...@fel.cvut 2e 63 7a > .cz > 1303936311.434696: TX EAPOL - hexdump(len=28): 01 00 00 18 02 01 00 18 01 > 73 6f 6a 6b 61 6d 31 40 66 65 6c 2e 63 76 75 74 2e 63 7a Hmm, the delay of 30 seconds, here > 1303936341.259024: RX EAPOL - hexdump(len=53): 02 00 00 31 01 02 00 31 01 > 00 6e 65 74 77 6f 72 6b 69 64 3d 65 64 75 72 6f 61 6d 2c 6e 61 73 69 64 3d > 61 73 62 2d 77 69 73 6d 35 2c 70 6f 72 74 69 64 3d 32 39 > 1303936341.259142: EAP: EAP-Request Identity data - hexdump_ascii(len=44): > 00 6e 65 74 77 6f 72 6b 69 64 3d 65 64 75 72 6f _networkid=eduro 61 6d > 2c 6e 61 73 69 64 3d 61 73 62 2d 77 69 73 am,nasid=asb-wis 6d 35 2c 70 > 6f 72 74 69 64 3d 32 39 m5,portid=29 1303936341.259178: EAP: > using real identity - hexdump_ascii(len=19): 73 6f 6a 6b 61 6d 31 40 66 65 > 6c 2e 63 76 75 74 sojk...@fel.cvut 2e 63 7a > .cz > 1303936341.259225: TX EAPOL - hexdump(len=28): 01 00 00 18 02 02 00 18 01 Could you capture the packet exchange by wireshark, so we can see if there is really the delay or it is just processing issue in wpa_supplicant? Jirka ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM: Connection order for devices
On Tuesday 14 of June 2011 15:57:29 Thomas Bechtold wrote: > Hi, > > i have 2 connections in /etc/NetworkManager/system-connections > > ### Connection 1 ### > [connection] > id=Ethernet > uuid=be2ae05f-b04d-dcf6-efa3-1e63e0f0e111 > type=802-3-ethernet > [ipv4] > method=auto > > > ### Connection 2 ### > [connection] > id=UsbHost > uuid=66d1285e-9905-4991-99c8-25fa3b3aa08a > type=802-3-ethernet > [ipv4] > method=link-local > [802-3-ethernet] > duplex=full > mac-address=00:50:c2:cd:a5:c7 > [ipv6] > method=ignore > > > I have 2 devices: > Device1 is an ethernet adapter and Device2 is a UsbHostDevice (with mac > 00:50:c2:cd:a5:c7). > > > > When i start NM, seems that NM try to use Conection 1 with Device 2 but > i told NM to use Connection 2 for device 2 (because of the mac-address > entry). Why does this happen? > > cheers, > > tom > With mac-address you restricted Connection 2 for the MAC. However, Connection 1 is not restricted and that's why it can be activated on any compatible device. If you want only to use Connection 1 on Device 1, restrict it with MAC the same way as Connection 2. You can also disable auto connecting for a connection, if you want. Jirka ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Issue with Indian Datacard
On Tuesday 14 of June 2011 15:43:18 Manish S Runwal wrote: > Any update on this ? > Please, could you repeat the steps Dan wrote, but after 1) add an additional step: 1a) at the (gdb) prompt, type "continue" It is needed, so that nm-applet is run again (it is stopped when gdb attaches) Jirka > > From: Dan Williams > To: Manish S Runwal > Cc: "networkmanager-list@gnome.org" > Sent: Saturday, 4 June 2011 12:32 AM > Subject: Re: Issue with Indian Datacard > > On Thu, 2011-06-02 at 20:54 -0700, Manish S Runwal wrote: > > Hello Dan, > > Thank you for taking issue on table. > > > > > > I am not so advance in that. if you give me set of commands to execute > > then It will do the steps for you. > > I have tried to use abrt but..it downloading heavily debug+debuginfo > > so thats costing bandwidth. > > any other option ? > > If you install 'gdb' on your machine, you can do the following: > > 1) gdb attach `pidof nm-applet` > 2) then try to trigger the fault in nm-applet > 3) when you do, gdb will stop nm-applet and leave that terminal at the > "(gdb)" prompt > 4) at the (gdb) prompt, type "backtrace" > 5) copy and paste that output into an email reply > > Thanks, > Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Trouble with privileges on dev version of NM
Hello! I'm testing the new NM DBus API, and for this I have installed git version of NM (19019a8e0be66fc4121a3885392f904025b86231). It seems to work and compile, but there is one issue. For some reason it does not scan wireless networks (although it used to in 0.8), and also it requires root password to change connection settings. I'm confused why it would behave this way. Is there any documentation on how to set up the privileges for NM and nm-applet? Thank you, Alex. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
