NetworkManager fails to activate my GSM connection

[Jochen Wiedmann]

Hi,

after upgrading to Fedora 11, I can no longer use my GSM stick. See
below for an excerpt from my /var/log/messages. Obviously, the model
is detected and (unlike the behaviour from Fedora 10) not mounted as
an USB drive, but immediately activated. So far, so good. However, the
activation failed.

In Fedora 10, I used to run the command

  usb_modeswitch -v 0af0 -p 6971 -P 6971 -m 0x05 -M
55534243785634120100860100

to have it activated. See

http://mail.gnome.org/archives/networkmanager-list/2009-May/msg00046.html
http://grumpyapache.blogspot.com/2009_05_01_archive.html

for details.

Any ideas, what might be wrong?

Thanks,

Jochen


Jun 11 02:03:42 mcjwi kernel: usb 5-1: USB disconnect, address 3
Jun 11 02:03:51 mcjwi kernel: usb 5-1: new full speed USB device using
uhci_hcd and address 4
Jun 11 02:03:51 mcjwi kernel: usb 5-1: New USB device found,
idVendor=0af0, idProduct=6971
Jun 11 02:03:51 mcjwi kernel: usb 5-1: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
Jun 11 02:03:51 mcjwi kernel: usb 5-1: Product: Globetrotter HSDPA Modem
Jun 11 02:03:51 mcjwi kernel: usb 5-1: Manufacturer: Option N.V.
Jun 11 02:03:51 mcjwi kernel: usb 5-1: SerialNumber: Serial Number
Jun 11 02:03:51 mcjwi kernel: usb 5-1: configuration #1 chosen from 1 choice
Jun 11 02:03:51 mcjwi kernel: usb-storage: probe of 5-1:1.0 failed with error -5
Jun 11 02:03:51 mcjwi kernel: hso 5-1:1.0: Not our interface
Jun 11 02:03:51 mcjwi kernel: usb 5-1: USB disconnect, address 4
Jun 11 02:03:52 mcjwi kernel: usb 5-1: new full speed USB device using
uhci_hcd and address 5
Jun 11 02:03:53 mcjwi kernel: usb 5-1: New USB device found,
idVendor=0af0, idProduct=6971
Jun 11 02:03:53 mcjwi kernel: usb 5-1: New USB device strings: Mfr=1,
Product=2, SerialNumber=4
Jun 11 02:03:53 mcjwi kernel: usb 5-1: Product: Globetrotter HSDPA Modem
Jun 11 02:03:53 mcjwi kernel: usb 5-1: Manufacturer: Option N.V.
Jun 11 02:03:53 mcjwi kernel: usb 5-1: SerialNumber: Serial Number
Jun 11 02:03:53 mcjwi kernel: usb 5-1: configuration #1 chosen from 1 choice
Jun 11 02:03:53 mcjwi kernel: usb-storage: probe of 5-1:1.0 failed with error -5
Jun 11 02:03:53 mcjwi kernel: hso0 (hso): not using net_device_ops yet
Jun 11 02:03:53 mcjwi kernel: hso0: Disabled Privacy Extensions
Jun 11 02:03:53 mcjwi kernel: usb-storage: probe of 5-1:1.1 failed with error -5
Jun 11 02:03:53 mcjwi NetworkManager:   (ttyHS0): found serial
port (udev:GSM  hal:GSM)
Jun 11 02:03:53 mcjwi NetworkManager:   (ttyHS0): new Modem
device (driver: 'hso')
Jun 11 02:03:53 mcjwi NetworkManager:   (ttyHS0): exported as
/org/freedesktop/Hal/devices/usb_device_af0_6971_Serial_Number_if0_serial_unknown_0
Jun 11 02:03:57 mcjwi NetworkManager:   (ttyHS0): device state
change: 1 -> 2
Jun 11 02:03:58 mcjwi NetworkManager:   (ttyHS0): deactivating
device (reason: 2).
Jun 11 02:03:58 mcjwi NetworkManager:
nm_system_device_flush_ip4_routes_with_iface: assertion `iface_idx >=
0' failed
Jun 11 02:03:58 mcjwi NetworkManager:
nm_system_device_flush_ip4_addresses_with_iface: assertion `iface_idx
>= 0' failed
Jun 11 02:03:58 mcjwi NetworkManager:   (ttyHS0): device state
change: 2 -> 3


-- 
Don't trust a government that doesn't trust you.
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Huawei E156G anyone?

[Gianluca Sforna]

I just put my hands on this cheap USB dongle and it appears I can't
connect with it; I'm on Fedora 11,
NetworkManager-0.7.1-4.git20090414.fc11.x86_64

Now since it's possible the SIM is not yet active (grabbed it just few
hours ago) I'd like to know if anyone here has the same dongle model
and can confirm it works.

TIA

Gianluca

-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Password not exported network-manager-vpnc

[Fletcher Liverance]

Hello,

I'm using network-manager 7.1 from Debian Sid with network-manager-vpnc. I've 
noticed that export does not export the user and group password.

>From line ~1259 of properties/nm-vpnc.c:

fprintf(f, 
"[main]\n"
...
"SaveUserPassword=%s\n"
...
"enc_GroupPwd=\n"
"UserPassword=\n"
"enc_UserPassword=\n"
...

It looks like it's storing whether the user password is saved or not, then 
doesn't actually save it. Is there a reason for this or is it just not 
implemented?

Thanks!

Fletcher




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

Basic questions re setting up pptp

[Eric Beversluis]

Do you have instructions anywhere for how to set up pptp using Network
Manager on OpenSuse 11.0. I looked at the Network Manager web page but
didn't see any detailed info there.The only thing was this, which isn't
much help:
"Simply install the NetworkManager VPN plugin your site uses, and
pre-load the user's machines with the VPN's settings. The first time
they connect, the user will be asked for their passwords."

According to Yast, Point-to-point tunneling protocol (PPTP) client is
installed.

I've tried the following without success (not sure what's supposed to go
in each spot):
-Rt click "Network Manager" icon and select "Edit Connections"
-Select VPN from tab
-click "Add"
-Enter connection name
-Don't know what to do with "Connect automatically" and "System
Setting"?
-Does "Connect automatically" mean it will connect each time I start my
computer or what?
-What doe clicking "System Setting" do?
-"Method": Is this the method used in the LAN I'm connecting to?
Assuming that, I leave it at DHCP.
--Addresses: I add the public address for the Watchguard Firebox that
manages the LAN at the target location and the Netmask and Gateway for
the DSL modem.  Is this right?
-I leave DNS Servers and Search Domains blank.
-The former because with DHCP that shouldn't be necessary, I think.
-The latter because I don't know (and don't see any documentation) what
it's for.
-I then click "OK" and nothing happens--the connection does not appear
in the "Network Connections" dialog where I was trying to add the
connection.



Thanks.

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

Re: interactions between OLPC wifi and mesh interfaces

[Daniel Drake]

On Wed, 2009-06-10 at 17:37 +0100, Peter Robinson wrote:
> In the basic testing I've done on 8.2.1 I'm  not sure it disconnects
> from the mesh when connecting to a standard network. I had problems
> when connecting to my AP until I worked out I had to put the mesh on
> the same channel as my AP. Once I did that I could connect to the AP
> fine but the mesh channel still throbbed in the Neighbourhood to show
> it was on that connection.

You're right, there are some reliability bugs in the old code there --
it doesn't always work. And sometimes you end up with a confusing state
on the network view like you are seeing. I hope to lose these bugs in
the new NM/sugar code, hence me asking for implementation advice.

Daniel


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

Re: interactions between OLPC wifi and mesh interfaces

[Peter Robinson]

Hi,

> I'm a little stuck with one issue reimplementing the OLPC mesh device
> support.
>
> 1. When the user is connected to a standard network through eth0, and
> then they request a connection to a mesh network on msh0, eth0 should
> disconnect and go quiet before the mesh connection starts to happen.
>
> 2. When the user is on a mesh through msh0 and requests connection to a
> real network through eth0, the mesh should disconnect itself.
>
> How was this implemented in the NM-0.6 solution? It seemed to work
> there.
>
>
> For (1) I added code into stage1_prepare in the mesh device. It checks
> to see if the companion is activated, if so it calls
> nm_device_state_changed() to make it NM_DEVICE_STATE_DISCONNECTED.
>
> This almost works. I connect to an IBSS, and then the mesh. The above
> code disconnects from the IBSS and starts the mesh connection process.
> However NM is still treating the devices as separate, so very quickly it
> tries to look for a connection to apply to eth0 again. It finds the same
> one (which Sugar's settings implementation is advertising as a network
> that should be autoconnected to) and then we end up with a mess where
> we're trying to connect to a mesh and an IBSS simultaneously.
>
> Switching eth0 to NM_DEVICE_STATE_UNAVAILABLE didn't help, it just got
> back on its feet in the same way.
>
> Thoughts?

In the basic testing I've done on 8.2.1 I'm  not sure it disconnects
from the mesh when connecting to a standard network. I had problems
when connecting to my AP until I worked out I had to put the mesh on
the same channel as my AP. Once I did that I could connect to the AP
fine but the mesh channel still throbbed in the Neighbourhood to show
it was on that connection.

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

interactions between OLPC wifi and mesh interfaces

[Daniel Drake]

Hi,

I'm a little stuck with one issue reimplementing the OLPC mesh device
support.

1. When the user is connected to a standard network through eth0, and
then they request a connection to a mesh network on msh0, eth0 should
disconnect and go quiet before the mesh connection starts to happen.

2. When the user is on a mesh through msh0 and requests connection to a
real network through eth0, the mesh should disconnect itself.

How was this implemented in the NM-0.6 solution? It seemed to work
there.


For (1) I added code into stage1_prepare in the mesh device. It checks
to see if the companion is activated, if so it calls
nm_device_state_changed() to make it NM_DEVICE_STATE_DISCONNECTED.

This almost works. I connect to an IBSS, and then the mesh. The above
code disconnects from the IBSS and starts the mesh connection process.
However NM is still treating the devices as separate, so very quickly it
tries to look for a connection to apply to eth0 again. It finds the same
one (which Sugar's settings implementation is advertising as a network
that should be autoconnected to) and then we end up with a mess where
we're trying to connect to a mesh and an IBSS simultaneously.

Switching eth0 to NM_DEVICE_STATE_UNAVAILABLE didn't help, it just got
back on its feet in the same way.

Thoughts?


No problems (yet) with (2). I connected a signal to the companion device
state-changed within the mesh device. If the companion is moving into an
active state, and the mesh device is active, I use
nm_device_state_changed() to disconnect the mesh device. This works, at
least while sugar is not offering an autoconnect mesh network setting.

I've attached my patch which may help to explain the above situation.

Thanks,
Daniel

diff --git a/src/nm-device-olpc-mesh.c b/src/nm-device-olpc-mesh.c
index 41056d6..3c7aea8 100644
--- a/src/nm-device-olpc-mesh.c
+++ b/src/nm-device-olpc-mesh.c
@@ -694,7 +694,16 @@ real_act_stage1_prepare (NMDevice *dev, 
NMDeviceStateReason *reason)
 {
NMDeviceOlpcMeshPrivate *priv = NM_DEVICE_OLPC_MESH_GET_PRIVATE (dev);
 
-   /* wait with continueing configuration untill the companion device is 
done
+   /* disconnect companion device, if it is connected */
+   if (nm_device_get_act_request (NM_DEVICE (priv->companion))) {
+   nm_warning("disconnecting companion device");
+   nm_device_state_changed (NM_DEVICE (priv->companion),
+NM_DEVICE_STATE_UNAVAILABLE,
+
NM_VPN_CONNECTION_STATE_REASON_USER_DISCONNECTED);
+   nm_warning("companion disconnected");
+   }
+
+   /* wait with continuing configuration untill the companion device is 
done
 * scanning */
if (nm_device_wifi_is_scanning (NM_DEVICE_WIFI (priv->companion))) {
priv->stage1_waiting = TRUE;
@@ -888,6 +897,25 @@ companion_notify_cb (NMDeviceWifi *companion, GParamSpec 
*pspec, gpointer user_d
}
 }
 
+/* disconnect from mesh if someone starts using the companion */
+static void
+companion_state_changed_cb (NMDeviceWifi *companion, NMDeviceState state, 
NMDeviceState old_state, NMDeviceStateReason reason, gpointer user_data)
+{
+   NMDeviceOlpcMesh *self = NM_DEVICE_OLPC_MESH (user_data);
+   NMDeviceState self_state = nm_device_get_state (NM_DEVICE (self));
+
+   if (self_state < NM_DEVICE_STATE_PREPARE
+   || self_state > NM_DEVICE_STATE_ACTIVATED
+   || state < NM_DEVICE_STATE_PREPARE
+   || state > NM_DEVICE_STATE_ACTIVATED)
+   return;
+
+   nm_debug ("disconnecting mesh due to companion connectivity");
+   nm_device_state_changed (NM_DEVICE (self),
+NM_DEVICE_STATE_DISCONNECTED,
+
NM_VPN_CONNECTION_STATE_REASON_USER_DISCONNECTED);
+}
+
 static gboolean
 companion_scan_allowed_cb (NMDeviceWifi *companion, gpointer user_data)
 {
@@ -930,10 +958,13 @@ is_companion (NMDeviceOlpcMesh *self, NMDevice *other)
 
nm_debug ("Found companion device: %s", nm_device_get_iface (other));
 
-   g_signal_connect (G_OBJECT(other), "notify::scanning",
-   G_CALLBACK(companion_notify_cb), self);
-   g_signal_connect (G_OBJECT(other), "scanning-allowed",
-   G_CALLBACK(companion_scan_allowed_cb), self);
+   /* FIXME: where to disconnect? */
+   g_signal_connect (G_OBJECT (other), "state-changed",
+   G_CALLBACK (companion_state_changed_cb), self);
+   g_signal_connect (G_OBJECT (other), "notify::scanning",
+   G_CALLBACK (companion_notify_cb), self);
+   g_signal_connect (G_OBJECT (other), "scanning-allowed",
+   G_CALLBACK (companion_scan_allowed_cb), self);
 
return TRUE;
 }
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networ

Sugar + OLPC mesh network selection logic

[Daniel Drake]

Hi,

I'm looking to implement network selection logic in sugar-0.84 using the
NetworkManager D-Bus API to implement something similar to what was
present in NetworkManager-0.6 for OLPC's mesh device. (the logic is now
being moved out of NetworkManager into sugar)

My work in progress is:
NM-0.7 with OLPC mesh support
http://dev.laptop.org/git/users/dsd/NetworkManager/log/?h=olpc
http://dev.laptop.org/~sjoerd/NM0.7/olpc-mesh.fdi
sugar-0.84.5 patch to add mesh support (connects to link local mesh when
selected on neighborhood view)
http://dev.laptop.org/~dsd/20090610/sugar-0.84-olpc-mesh.patch


I'm looking for some feedback on my plan, particularly for the
interacting-with-NM side of things.

This is how sugar works at the moment (I think):
- Only infrastructure networks are supported.
- On a new install, it doesn't attempt any connections.
- When the user clicks on a network to connect, sugar makes an
NMSettingsConnection object and and uses ActivateConnection() to
activate it.
- If the connection succeeds, sugar saves the details internally.

- When starting up again later, sugar loads all its saved networks,
creating NMSettingsConnection objects with the autoconnect flag set.
- It doesn't call ActivateConnection() on anything, but presumably NM
notices the new connections (with the autoconnect preference) and picks
one to try.


And now the logic I want to implement, which is similar to that in
previous OLPC OS releases:
- First, attempt to connect to any known access points that are in range
using saved credentials. Always prefer known APs to mesh.
- As a fallback if those APs fail, or if no APs are available or if
we've never connected to any (e.g. on first boot), try the mesh.

"try the mesh" means trying each of these configurations in turn,
stopping on the first one that succeeds:
1. Connect to school server on channel 1 (i.e. dhcp with XS anycast
address)
2. Connect to mesh portal on channel 1 (i.e. dhcp with MPP anycast
address)
3. Connect to school server on channel 6
4. Connect to mesh portal on channel 6
5. Connect to school server on channel 11
6. Connect to mesh portal on channel 11
7. Connect to link-local simple mesh on channel 1 (cannot fail)

[the mesh device settings class has properties 'channel' and
'dhcp-anycast-address' therefore the way to try each configuration is by
creating and activating a new NMSettingsConnection object for each one]

My uncertainty is how to implement the above logic.

Is it possible to assign a priority or preference to a
NMSettingsConnection object? If so, I could just create high-priority
objects for all APs, and decreasing priority objects for the mesh
configurations, all with the autoconnect flag. The priorities would
cause Networkmanager to try them in order suggested above.

Alternatively, we could always set autoconnect=False for all networks,
and have some kind of management layer inside sugar which iterates
through all the networks, monitoring the device states, calling
ActivateConnection and moving onto the next one if it failed to connect.
But immediately it gets tricky.. for infrastructure networks, we have to
consider which APs are available, and what happens if they appear
later?, etc.

Or, other options?

Thanks,
Daniel


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

Duplicate MB entries in tray drop-down

[Rick Jones]

Ever since using 0.7.1, I always get double entries for my 3G modem in the 
tray drop-down. This doesn't seem to stop anything working, and clicking 
either instance will connect. It's just a little irritating!


The device is a ZTE MF627. Is there any configuration tweak I can make to 
stop it happening?


The upgrade to 0.7.1 was included in upgrading the OS to Ubuntu 9.04 (from 
8.10), could there be an OS config change that's doing this?


Thanks
Rick Jones ___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Roaming network selection with MB

[Rick Jones]

I ran into a problem recently trying to use my mobile broadband modem in 
France, roaming from the UK.


I discovered that my carrier only has roaming agreements with 2 of the 3 
French networks, but this doesn't stop the modem locking onto the wireless 
signal of the unsupported one (it's not barred in the SIM). This requires 
manual selection of the network before attempting to make a connection. 
Their Windows connection gadget supports this - is this a feature that will 
be available in Modem Manager?


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

Re: Network Manager crashes when rf kill switch is Activated.

[sanjeev sharma]

Hi all,

Find My Comments inline as follows.

On Tue, Jun 9, 2009 at 9:19 PM, Dan Williams wrote:
> On Tue, 2009-06-09 at 18:43 +0530, sanjeev sharma wrote:
>> Hi All,
>>
>> I have been observing a crash of Network Manager when experimenting
>> with the rf kill
>> switch. I was trying to flip the
>> switch before the previous switch state change had been fully processed by
>> software.
>>
>> These are the log messages i have been seeing
>>
>>  daemon.warn NetworkManager:   nm_device_wifi_set_ssid(): error
>> setting SSID to '(null)' for device eth0: Input/output error
>>
>>  daemon.warn NetworkManager:   wireless_get_range(): (eth0):
>> couldn't get driver range information (5).
>>
>> daemon.warn NetworkManager:   nm_supplicant_interface_add_cb():
>> Unexpected supplicant error getting interface: wpa_supplicant couldn't
>> grab this interface.
>>
>>  daemon.warn NetworkManager:   nm_signal_handler(): Caught
>> signal 11.   Generating backtrace...
>
> Can you gdb NM and get a backtrace where it crashes?  Obviously we're
> not handling this case correctly, but it's a bit unclear exactly where
> the error is unless there's a better backtrace.
>
This happens very rarely So gdb NM wouldn't be useful
enough in this case.

> The bits in question are in
> src/supplicant-manager/nm-supplicant-interface.c.  We may need to add a
> signal to the supplicant interface object for something like "invalid",
> so that we know to tear down the supplicant interface object in NM when
> it cannot be added to the supplicant.
>
Does Current NetworkManager source code lead to segfault if supplicant
will fail to add interface.
Which section of networkManager code will handle this
invalid Signal.
> But it actually looks like we should just fix the bug itself, since the
> rest of the code looks like it will handle re-configuring the interface
> when the device un-kills itself.  Need the backtrace for that though.
>
How to proceed further in case if gdb NM not possible.

sanjeev
> Dan
>
>>  daemon.crit NetworkManager: *** START
>> **
>>  daemon.crit NetworkManager: Frame 0: [0xbeb20c4c]
>> May 29 12:08:07 (none) daemon.crit NetworkManager: ***
>> END **
>>
>>
>> would anybody through some pointer on it which causes segfault and how
>> to prevent it.
>>
>> Sanjeev
>
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

MB connection timeout problem

[Rick Jones]

I'm experiencing an odd problem trying to make a mobile-broadband 
connection.

Sometimes it fails, and there is a message in the log saying:

Jun  9 16:28:41 mineee NetworkManager:   pppd_timed_out(): Looks like 
pppd didn't initialize our dbus module


This appears to be a 15-sec timeout, which I think is too short.

The more detailed situation is this - when I have a 3G signal the 
connection works OK. When there is only a 2G signal I get this connection 
problem. I know the modem will connect to 2G, because it works on Windows 
with the carrier's proprietary connection gadget, but it takes noticeably 
longer to make the connection. This is why I suspect it's just a timeout 
issue.


Is there a way to tweak this timeout? I'm not even sure if it's in NM or 
pppd.


I've attached log extracts for both the successful & unsuccessful cases.
NM is 0.7.1, as included with Ununtu 9.04. I see there is an alternative 
0.7.1 on launchpad, but I don't know what differences there are, if any. I 
haven't tried it.


(this is of course a pain to test, as I have to take the laptop off 
somewhere to lose the 3G signal in order to force the 2G case :-/ )


Thanks, Rick 

NM-logs
Description: Binary data
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Network Manager crashes when rf kill switch is Activated.

[代尔欣]

Hi Dan,
May nothing to do with the mentioned crash problem. Just want to discuss
about the codes. Any chance below scenario can happen for WIFI device?
src/nm-device.c
When device deactivate below function will be called:

gboolean nm_device_deactivate_quickly (NMDevice *self)
{
...
/* Tear down an existing activation request */
clear_act_request (self); <-- This function will clear
priv->act_request = NULL
return TRUE;
}

Then NM_DEVICE_STATE_FAILED state change occured for some reason.
src/nm-device-wifi.c
static void device_state_changed (...)
{
...
case NM_DEVICE_STATE_FAILED:
activation_failure_handler (device);
break;
...
}

static void activation_failure_handler (NMDevice *dev)
{
...
req = nm_device_get_act_request (dev);
g_assert (req);  <-- This assert will fail and NetworkManager quit?
...
}

Thanks!!

2009/6/9 Dan Williams 

> On Tue, 2009-06-09 at 18:43 +0530, sanjeev sharma wrote:
> > Hi All,
> >
> > I have been observing a crash of Network Manager when experimenting
> > with the rf kill
> > switch. I was trying to flip the
> > switch before the previous switch state change had been fully processed
> by
> > software.
> >
> > These are the log messages i have been seeing
> >
> >  daemon.warn NetworkManager:   nm_device_wifi_set_ssid(): error
> > setting SSID to '(null)' for device eth0: Input/output error
> >
> >  daemon.warn NetworkManager:   wireless_get_range(): (eth0):
> > couldn't get driver range information (5).
> >
> > daemon.warn NetworkManager:   nm_supplicant_interface_add_cb():
> > Unexpected supplicant error getting interface: wpa_supplicant couldn't
> > grab this interface.
> >
> >  daemon.warn NetworkManager:   nm_signal_handler(): Caught
> > signal 11.   Generating backtrace...
>
> Can you gdb NM and get a backtrace where it crashes?  Obviously we're
> not handling this case correctly, but it's a bit unclear exactly where
> the error is unless there's a better backtrace.
>
> The bits in question are in
> src/supplicant-manager/nm-supplicant-interface.c.  We may need to add a
> signal to the supplicant interface object for something like "invalid",
> so that we know to tear down the supplicant interface object in NM when
> it cannot be added to the supplicant.
>
> But it actually looks like we should just fix the bug itself, since the
> rest of the code looks like it will handle re-configuring the interface
> when the device un-kills itself.  Need the backtrace for that though.
>
> Dan
>
> >  daemon.crit NetworkManager: *** START
> > **
> >  daemon.crit NetworkManager: Frame 0: [0xbeb20c4c]
> > May 29 12:08:07 (none) daemon.crit NetworkManager: ***
> > END **
> >
> >
> > would anybody through some pointer on it which causes segfault and how
> > to prevent it.
> >
> > Sanjeev
>
> ___
> 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