Re: Using a mobile phone via Bluetooth
On Tue, 2009-07-07 at 17:43 +0100, Brian Morrison wrote: > Dan Williams wrote: > > > Sounds like more on the Bluetooth side, of course. Does your phone do > > anything when NM tries to bring the connection up? Mine usually asks me > > whether I want to allow the computer to connect, or it'll show an icon > > saying a computer is connected. > > Bluetooth will insist on being paired and authorised as well or it will > ask for permission to allow the connection and use it. Right, you can't always just open the persistent rfcomm port and expect it to work, due to these sorts of issues. > > In any case, this is exactly why this > > method is a hack, and why we want the real solution... > > I don't see there is any way to bypass these parts of the Bluetooth > protocol stack, but perhaps you know differently. Well, the problem is that there's no intelligence built into that hack method of doing Bluetooth. In the bits we've added to 0.8 for Bluetooth, we ask Bluez to set up the rfcomm port, and we can get reliable errors when we can't talk to the phone or when something else goes wrong. With the persistent stuff, the errors just get completely lost, because to NetworkManager, the hacked rfcomm thing just looks like a directly connected serial port and thus all errors on the bluetooth side just end up looking like a generic failure to talk to the modem. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: supplicant interface scan state tracking
On Tue, 2009-07-07 at 22:41 +0100, Daniel Drake wrote: > On Tue, 2009-07-07 at 12:15 -0400, Dan Williams wrote: > > It could be a signal ordering issue. The code in > > nm-supplicant-interface.c is: > > > > if (priv->scanning) > > return TRUE; > > if (priv->con_state == NM_SUPPLICANT_INTERFACE_CON_STATE_SCANNING) > > return TRUE; > > > > So only if both of these are FALSE will > > nm_supplicant_interface_get_scanning() return FALSE. Each of these > > variables is independently set, priv->scanning is based off the > > supplicant's 'scanning' property, and priv->con_state is based off the > > 'state' property. > > The problem is that sometimes when this happens, con_state is never > updated. It remains as SCANNING even after eth0 has been disconnected. > Would it be OK to reset this to 0 inside disconnect_cb? No; because disconnect just terminates the current association, it doesn't actually have any effect on the supplicant interface's state. Just because we're disconnected doesn't mean we can't request scans or whatever. Is NM perhaps ignoring some other signal from the supplicant after disconnect? Or is the supplicant not sending state updates after a disconnect? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: supplicant interface scan state tracking
On Wed, 2009-07-08 at 01:28 +0200, Witold Sowa wrote: > Witold Sowa pisze: > > Daniel Drake pisze: > >> On Tue, 2009-07-07 at 12:15 -0400, Dan Williams wrote: > >> > >>> It could be a signal ordering issue. The code in > >>> nm-supplicant-interface.c is: > >>> > >>> if (priv->scanning) > >>> return TRUE; > >>> if (priv->con_state == NM_SUPPLICANT_INTERFACE_CON_STATE_SCANNING) > >>> return TRUE; > >>> > >>> So only if both of these are FALSE will > >>> nm_supplicant_interface_get_scanning() return FALSE. Each of these > >>> variables is independently set, priv->scanning is based off the > >>> supplicant's 'scanning' property, and priv->con_state is based off the > >>> 'state' property. > >>> > >> > >> The problem is that sometimes when this happens, con_state is never > >> updated. It remains as SCANNING even after eth0 has been disconnected. > >> Would it be OK to reset this to 0 inside disconnect_cb? > >> > >> Daniel > >> > > Mayby that's because in supplicant's wpa_supplicant_clear_status function > > (wpa_supplicant.c) state is changed to disconnected, but notification is > > not sent? > > > > Witek > > > No, that's not a problem. Sorry for the false alarm. BTW: why we have > separate scanning property? Isn't status == scanning enough? No, because when the card is already in CONNECTED state, the supplicant purposefully doesn't flip back to SCANNING when a scan request comes in (like when NM requests a periodic scan). It also won't flip to SCANNING when unsolicited results come in and the supplicant can't find the associated AP, which makes the supplicant perform an additional specific-SSID scan for the associated AP. I don't really think that's a huge problem; the "state" is an overall state and doesn't actually reflect periodic scans while associated, because you're still associated. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: supplicant interface scan state tracking
Witold Sowa pisze: > Daniel Drake pisze: >> On Tue, 2009-07-07 at 12:15 -0400, Dan Williams wrote: >> >>> It could be a signal ordering issue. The code in >>> nm-supplicant-interface.c is: >>> >>> if (priv->scanning) >>> return TRUE; >>> if (priv->con_state == NM_SUPPLICANT_INTERFACE_CON_STATE_SCANNING) >>> return TRUE; >>> >>> So only if both of these are FALSE will >>> nm_supplicant_interface_get_scanning() return FALSE. Each of these >>> variables is independently set, priv->scanning is based off the >>> supplicant's 'scanning' property, and priv->con_state is based off the >>> 'state' property. >>> >> >> The problem is that sometimes when this happens, con_state is never >> updated. It remains as SCANNING even after eth0 has been disconnected. >> Would it be OK to reset this to 0 inside disconnect_cb? >> >> Daniel >> > Mayby that's because in supplicant's wpa_supplicant_clear_status function > (wpa_supplicant.c) state is changed to disconnected, but notification is not > sent? > > Witek > No, that's not a problem. Sorry for the false alarm. BTW: why we have separate scanning property? Isn't status == scanning enough? >> ___ >> 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: supplicant interface scan state tracking
Daniel Drake pisze: > On Tue, 2009-07-07 at 12:15 -0400, Dan Williams wrote: > >> It could be a signal ordering issue. The code in >> nm-supplicant-interface.c is: >> >> if (priv->scanning) >> return TRUE; >> if (priv->con_state == NM_SUPPLICANT_INTERFACE_CON_STATE_SCANNING) >> return TRUE; >> >> So only if both of these are FALSE will >> nm_supplicant_interface_get_scanning() return FALSE. Each of these >> variables is independently set, priv->scanning is based off the >> supplicant's 'scanning' property, and priv->con_state is based off the >> 'state' property. >> > > The problem is that sometimes when this happens, con_state is never > updated. It remains as SCANNING even after eth0 has been disconnected. > Would it be OK to reset this to 0 inside disconnect_cb? > > Daniel > Mayby that's because in supplicant's wpa_supplicant_clear_status function (wpa_supplicant.c) state is changed to disconnected, but notification is not sent? Witek > > ___ > 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: supplicant interface scan state tracking
On Tue, 2009-07-07 at 12:15 -0400, Dan Williams wrote: > It could be a signal ordering issue. The code in > nm-supplicant-interface.c is: > > if (priv->scanning) > return TRUE; > if (priv->con_state == NM_SUPPLICANT_INTERFACE_CON_STATE_SCANNING) > return TRUE; > > So only if both of these are FALSE will > nm_supplicant_interface_get_scanning() return FALSE. Each of these > variables is independently set, priv->scanning is based off the > supplicant's 'scanning' property, and priv->con_state is based off the > 'state' property. The problem is that sometimes when this happens, con_state is never updated. It remains as SCANNING even after eth0 has been disconnected. Would it be OK to reset this to 0 inside disconnect_cb? Daniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Using a mobile phone via Bluetooth
Dan Williams wrote: > Sounds like more on the Bluetooth side, of course. Does your phone do > anything when NM tries to bring the connection up? Mine usually asks me > whether I want to allow the computer to connect, or it'll show an icon > saying a computer is connected. Bluetooth will insist on being paired and authorised as well or it will ask for permission to allow the connection and use it. > In any case, this is exactly why this > method is a hack, and why we want the real solution... I don't see there is any way to bypass these parts of the Bluetooth protocol stack, but perhaps you know differently. -- Brian ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Using a mobile phone via Bluetooth
On Wed, 2009-07-08 at 01:31 +0900, David Smith wrote: > On Wed, Jul 8, 2009 at 1:19 AM, Dan Williams wrote: > > On Wed, 2009-07-08 at 01:13 +0900, david.daniel.sm...@gmail.com wrote: > >> On Tue, Jul 7, 2009 at 3:18 AM, Dan Williams wrote: > >> > On Mon, 2009-07-06 at 12:54 -0400, Ryan Novosielski wrote: > >> >> -BEGIN PGP SIGNED MESSAGE- > >> >> Hash: SHA1 > >> >> > >> >> Brian Morrison wrote: > >> >> > Saw this on the Planet Fedora RSS feed today: > >> >> > > >> >> > http://fetzig.org/2009/07/04/tethering-in-fedora-using-your-mobile-phone-with-networkmanager-to-surf-the-web/ > >> >> > > >> >> > Does this look the sort of thing where a more sane approach could be > >> >> > added to NM or udev to cope with a wider range of phones without > >> >> > needing to create user rules? > >> >> > >> >> I notice this solution mentions GSM. Is there any reason this should not > >> >> work for a CDMA phone? > >> > > >> > As long as the phone responds to AT+GCAP with "IS-707" the probe will > >> > tag the phone as a CDMA device and you should be able to use it with a > >> > CDMA connection like any normal data card or USB-attached CDMA phone. > >> > NM shouldn't be confused by the mis-tagged HAL entry in the linked > >> > dialup-bluetooth.py because it prefers the probed capabilities over > >> > static ones in HAL. > >> > > >> > >> I have an emobile (Japanese provider) CDMA device that responds with > >> +GCAP: +CGSM,+DS,+ES but not IS-707 and so only gets resolved as GSM by > >> NM, but in reality it's a CDMA-only device and works fine when just dialed > >> with pppd. What should I do in this situation? Also an earlier model from > >> the same provider that was also CDMA failed to respond at all to the > >> AT+GCAP (and subsequent) commands from nm-modem-probe. Is the device not > >> following the spec or is NM too strict? > > > > Emobile appears to be a GSM carrier, they appear to provide HSPA-based > > 3G services. You may be confusing "CDMA" with W-CDMA. W-CDMA (Wideband > > CDMA) is the GSM-based 3G standard but shares a technological basis with > > the CDMA2000 standards that we actually think of as CDMA. > > > > Indeed, sorry for the confusion. > > > What does your ppp dialup script contain? That would help narrow the > > issue down. > > I've attached the pppd config file and the chatscript. It all seems like very > default settings (just dial the right number and use em/em for l/p). I > suppose it's the format of the number it's dialing that's interesting? Yup. That tells the phone what stored APN to use, in this case APN #1. Whatever that is; you can use AT+CGDCONT=? to get them I think. Dan > > > > Dan > > > > > > > ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Using a mobile phone via Bluetooth
emobile.pppd Description: Binary data signature.asc Description: OpenPGP digital signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Fixed compilation error on openSUSE distibution
On Tue, 2009-07-07 at 04:48 +0200, Witold Sowa wrote: > Removed reference operator which caused incompatible pointer type > compilation error on openSUSE. Good catch, applied. Thanks! Dan > --- > src/named-manager/nm-named-manager.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/named-manager/nm-named-manager.c > b/src/named-manager/nm-named-manager.c > index a360958..cab06ab 100644 > --- a/src/named-manager/nm-named-manager.c > +++ b/src/named-manager/nm-named-manager.c > @@ -149,7 +149,7 @@ run_netconfig (GError **error, gint *stdin_fd) > g_free (tmp); > > if (!g_spawn_async_with_pipes (NULL, argv, NULL, 0, > netconfig_child_setup, > - NULL, &pid, &stdin_fd, NULL, > NULL, error)) > + NULL, &pid, stdin_fd, NULL, NULL, > error)) > return -1; > > return pid; > -- > 1.6.0.2 > ___ > 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: supplicant interface scan state tracking
On Tue, 2009-07-07 at 12:15 -0400, Dan Williams wrote:
> On Mon, 2009-07-06 at 22:16 +0100, Daniel Drake wrote:
> > Hi Dan,
> >
> > I'm finding it quite easy to reproduce a bug related to
> > nm_supplicant_interface_get_scanning()
> > but I'm not sure how to fix it.
> >
> > The logic implemented in my OLPC mesh device so-far is that if the
> > companion device is scanning, it postpones stage2 until the scanning has
> > finished.
> >
> > It does this by monitoring a new "scanning" property on NMDeviceWifi
> > which is implemented based on nm_supplicant_interface_get_scanning().
> > http://dev.laptop.org/git/users/dsd/NetworkManager/commit/?h=olpc&id=111baac88318f4db467360fd9703f37ac0449023
> >
> > Also, if a connection on eth0 is active when you activate a msh0
> > connection, msh0 moves eth0 into NM_DEVICE_STATE_DISCONNECTED and
> > disables autoconnect (via the mechanism in the patch I emailed earlier).
> >
> > Anyway, I can now easily reproduce the following sequence of events
> > causing nm_supplicant_interface_get_scanning() to be less than truthful
> > and cause a deadlock:
> >
> > to start with, an eth0 connection is activating:
> >
> > Activation (eth0) Stage 2 of 5 (Device Configure) complete.
> > Config: set interface ap_scan to 1
> >
> > at this point, inside NMDeviceOlpcMeshPrivate, "scanning" is TRUE and
> > con_state = SCANNING (I know this through some debug messages)
> >
> > (eth0): supplicant connection state: disconnected -> scanning
> >
> > but I interrupt it here by starting a mesh connection
> >
> > Activation (msh0) starting connection 'olpc-mesh-1'
> > (msh0): device state change: 3 -> 4 (reason 0)
> > Activation (msh0) Stage 1 of 5 (Device Prepare) scheduled...
> > Activation (msh0) Stage 1 of 5 (Device Prepare) started...
> >
> > msh0 now disconnects eth0
> >
> > (eth0): device state change: 5 -> 3 (reason 2)
> > (eth0): deactivating device (reason: 2).
> > Activation (msh0) Stage 1 of 5 (Device Prepare) complete.
> >
> > At this point, another dbus signal comes in from wpa_supplicant so
> > "scanning" moves to FALSE. This wakes up msh0 device which calls
> > nm_supplicant_interface_get_scanning() to figure out the new state, but
> > this returns TRUE because con_state is still SCANNING, so msh0 does not
> > continue the connection process and everything stops.
>
> It could be a signal ordering issue. The code in
> nm-supplicant-interface.c is:
>
> if (priv->scanning)
> return TRUE;
> if (priv->con_state == NM_SUPPLICANT_INTERFACE_CON_STATE_SCANNING)
> return TRUE;
>
> So only if both of these are FALSE will
> nm_supplicant_interface_get_scanning() return FALSE. Each of these
> variables is independently set, priv->scanning is based off the
> supplicant's 'scanning' property, and priv->con_state is based off the
> 'state' property.
>
> So what you're probably getting into here is that the 'scanning'
> property is being set to FALSE in the supplicant (and D-Bus listeners
> are notified too) before the State property is being updated.
>
> The way to fix that is to make NMSupplicantInterface's scanning property
> consistent with nm_supplicant_interface_get_scanning() by only flipping
> it to FALSE when both the supplicant's State and Scanning properties
> indicate scanning is not happening.
>
> So you'd add a private member to the NMSupplicantInterfacePrivate struct
> for 'gboolean supplicant_scanning' and replace all usage of
> priv->scanning with priv->supplicant_scanning.
Well, not all usage... get_property() and set_property() should use
priv->scanning. What we're trying to do here is split priv->scanning
into two parts: priv->scanning would be the object property that
represents the combination of the supplicant's scanning and state
properties, while priv->supplicant_scanning would be a direct mirror of
the supplicants scanning property for internal NMSupplicantInterface use
only.
Dan
> Then you'd create a new function called wpas_iface_check_scanning() that
> would basically do this:
>
> static void
> wpas_iface_check_scanning (NMSupplicantInterface *self)
> {
> NMSupplicantInterfacePrivate *priv =
> NM_SUPPLICANT_INTERFACE_GET_PRIVATE (self);
> gboolean new_scanning = FALSE;
>
> if ( priv->supplicant_scanning
> || priv->con_state == NM_SUPPLICANT_INTERFACE_CON_STATE_SCANNING)
> new_scanning = TRUE;
>
> if (new_scanning != priv->scanning) {
> priv->scanning = new_scanning;
> g_object_notify (G_OBJECT (self), "scanning");
> }
> }
>
> and you'd call that function from wherever priv->supplicant_scanning and
> priv->con_state got changed (iface_scanning_cb,
> wpas_iface_handle_scanning, wpas_iface_handle_state_change,
> iface_state_cb).
>
> That should do the trick.
>
> Dan
>
> > What confuses me a little here is that the supplicant is still alive
> > and
> > running, even though there aren't any active con
Re: Using a mobile phone via Bluetooth
On Wed, 2009-07-08 at 01:13 +0900, david.daniel.sm...@gmail.com wrote: > On Tue, Jul 7, 2009 at 3:18 AM, Dan Williams wrote: > > On Mon, 2009-07-06 at 12:54 -0400, Ryan Novosielski wrote: > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> Brian Morrison wrote: > >> > Saw this on the Planet Fedora RSS feed today: > >> > > >> > http://fetzig.org/2009/07/04/tethering-in-fedora-using-your-mobile-phone-with-networkmanager-to-surf-the-web/ > >> > > >> > Does this look the sort of thing where a more sane approach could be > >> > added to NM or udev to cope with a wider range of phones without > >> > needing to create user rules? > >> > >> I notice this solution mentions GSM. Is there any reason this should not > >> work for a CDMA phone? > > > > As long as the phone responds to AT+GCAP with "IS-707" the probe will > > tag the phone as a CDMA device and you should be able to use it with a > > CDMA connection like any normal data card or USB-attached CDMA phone. > > NM shouldn't be confused by the mis-tagged HAL entry in the linked > > dialup-bluetooth.py because it prefers the probed capabilities over > > static ones in HAL. > > > > I have an emobile (Japanese provider) CDMA device that responds with +GCAP: > +CGSM,+DS,+ES but not IS-707 and so only gets resolved as GSM by NM, but in > reality it's a CDMA-only device and works fine when just dialed with pppd. > What should I do in this situation? Also an earlier model from the same > provider that was also CDMA failed to respond at all to the AT+GCAP (and > subsequent) commands from nm-modem-probe. Is the device not following the > spec or is NM too strict? Emobile appears to be a GSM carrier, they appear to provide HSPA-based 3G services. You may be confusing "CDMA" with W-CDMA. W-CDMA (Wideband CDMA) is the GSM-based 3G standard but shares a technological basis with the CDMA2000 standards that we actually think of as CDMA. What does your ppp dialup script contain? That would help narrow the issue down. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: supplicant interface scan state tracking
On Mon, 2009-07-06 at 22:16 +0100, Daniel Drake wrote:
> Hi Dan,
>
> I'm finding it quite easy to reproduce a bug related to
> nm_supplicant_interface_get_scanning()
> but I'm not sure how to fix it.
>
> The logic implemented in my OLPC mesh device so-far is that if the
> companion device is scanning, it postpones stage2 until the scanning has
> finished.
>
> It does this by monitoring a new "scanning" property on NMDeviceWifi
> which is implemented based on nm_supplicant_interface_get_scanning().
> http://dev.laptop.org/git/users/dsd/NetworkManager/commit/?h=olpc&id=111baac88318f4db467360fd9703f37ac0449023
>
> Also, if a connection on eth0 is active when you activate a msh0
> connection, msh0 moves eth0 into NM_DEVICE_STATE_DISCONNECTED and
> disables autoconnect (via the mechanism in the patch I emailed earlier).
>
> Anyway, I can now easily reproduce the following sequence of events
> causing nm_supplicant_interface_get_scanning() to be less than truthful
> and cause a deadlock:
>
> to start with, an eth0 connection is activating:
>
> Activation (eth0) Stage 2 of 5 (Device Configure) complete.
> Config: set interface ap_scan to 1
>
> at this point, inside NMDeviceOlpcMeshPrivate, "scanning" is TRUE and
> con_state = SCANNING (I know this through some debug messages)
>
> (eth0): supplicant connection state: disconnected -> scanning
>
> but I interrupt it here by starting a mesh connection
>
> Activation (msh0) starting connection 'olpc-mesh-1'
> (msh0): device state change: 3 -> 4 (reason 0)
> Activation (msh0) Stage 1 of 5 (Device Prepare) scheduled...
> Activation (msh0) Stage 1 of 5 (Device Prepare) started...
>
> msh0 now disconnects eth0
>
> (eth0): device state change: 5 -> 3 (reason 2)
> (eth0): deactivating device (reason: 2).
> Activation (msh0) Stage 1 of 5 (Device Prepare) complete.
>
> At this point, another dbus signal comes in from wpa_supplicant so
> "scanning" moves to FALSE. This wakes up msh0 device which calls
> nm_supplicant_interface_get_scanning() to figure out the new state, but
> this returns TRUE because con_state is still SCANNING, so msh0 does not
> continue the connection process and everything stops.
It could be a signal ordering issue. The code in
nm-supplicant-interface.c is:
if (priv->scanning)
return TRUE;
if (priv->con_state == NM_SUPPLICANT_INTERFACE_CON_STATE_SCANNING)
return TRUE;
So only if both of these are FALSE will
nm_supplicant_interface_get_scanning() return FALSE. Each of these
variables is independently set, priv->scanning is based off the
supplicant's 'scanning' property, and priv->con_state is based off the
'state' property.
So what you're probably getting into here is that the 'scanning'
property is being set to FALSE in the supplicant (and D-Bus listeners
are notified too) before the State property is being updated.
The way to fix that is to make NMSupplicantInterface's scanning property
consistent with nm_supplicant_interface_get_scanning() by only flipping
it to FALSE when both the supplicant's State and Scanning properties
indicate scanning is not happening.
So you'd add a private member to the NMSupplicantInterfacePrivate struct
for 'gboolean supplicant_scanning' and replace all usage of
priv->scanning with priv->supplicant_scanning.
Then you'd create a new function called wpas_iface_check_scanning() that
would basically do this:
static void
wpas_iface_check_scanning (NMSupplicantInterface *self)
{
NMSupplicantInterfacePrivate *priv =
NM_SUPPLICANT_INTERFACE_GET_PRIVATE (self);
gboolean new_scanning = FALSE;
if ( priv->supplicant_scanning
|| priv->con_state == NM_SUPPLICANT_INTERFACE_CON_STATE_SCANNING)
new_scanning = TRUE;
if (new_scanning != priv->scanning) {
priv->scanning = new_scanning;
g_object_notify (G_OBJECT (self), "scanning");
}
}
and you'd call that function from wherever priv->supplicant_scanning and
priv->con_state got changed (iface_scanning_cb,
wpas_iface_handle_scanning, wpas_iface_handle_state_change,
iface_state_cb).
That should do the trick.
Dan
> What confuses me a little here is that the supplicant is still alive
> and
> running, even though there aren't any active connections. It did also
> manage to raise a dbus signal indicating the termination of the scan
> *after* NM sent the disconnection request, but it did not manage to
> communicate any change in con_state. Also I cannot connect to it with
> wpa_cli to see if is still in SCANNING state.
>
> Thoughts?
>
> Thanks,
> Daniel
>
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Using a mobile phone via Bluetooth
On Tue, Jul 7, 2009 at 3:18 AM, Dan Williams wrote: On Mon, 2009-07-06 at 12:54 -0400, Ryan Novosielski wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Morrison wrote: > Saw this on the Planet Fedora RSS feed today: > > http://fetzig.org/2009/07/04/tethering-in-fedora-using-your-mobile-phone-with-networkmanager-to-surf-the-web/ > > Does this look the sort of thing where a more sane approach could be > added to NM or udev to cope with a wider range of phones without > needing to create user rules? I notice this solution mentions GSM. Is there any reason this should not work for a CDMA phone? As long as the phone responds to AT+GCAP with "IS-707" the probe will tag the phone as a CDMA device and you should be able to use it with a CDMA connection like any normal data card or USB-attached CDMA phone. NM shouldn't be confused by the mis-tagged HAL entry in the linked dialup-bluetooth.py because it prefers the probed capabilities over static ones in HAL. I have an emobile (Japanese provider) CDMA device that responds with +GCAP: +CGSM,+DS,+ES but not IS-707 and so only gets resolved as GSM by NM, but in reality it's a CDMA-only device and works fine when just dialed with pppd. What should I do in this situation? Also an earlier model from the same provider that was also CDMA failed to respond at all to the AT+GCAP (and subsequent) commands from nm-modem-probe. Is the device not following the spec or is NM too strict? signature.asc Description: OpenPGP digital signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: adsl connection always connected
On Mon, 2009-07-06 at 19:24 -0300, Domingo Becker wrote: > 2009/7/6 Dan Williams : > > > > Not at the moment, but in an update NM will try harder to keep these > > sorts of connections up. > > > > I found that it disconnects when I log out of the session. > Think of a server where nobody logs in to the gnome session. > And it should check when the ISP disconnects it automatically. > My ISP does this disconnection several times a day. > The update should take this in count. NetworkManager provides two types of connections: user and system. User connections are private to the user (think VPN that uses your user password, etc) and aren't available unless the user is logged in. System connections are available to all users and can be used before any users logs in, or across fast-user-switching, etc. System connections are provided by the 'nm-system-settings' daemon, and are stored in various ways based on what plugins you've told the system settings service to load. For example, Fedora users use the 'ifcfg-rh' plugin which will read & write configuration from the standard Fedora ifcfg network files in /etc/sysconfig/network-scripts. There's also a 'keyfile' plugin that will read/write network configuration from .ini-style files that live in /etc/NetworkManager/system-connections. That's probably your best option at the moment. Look in /etc/NetworkManager/nm-system-settings.conf and see what plugins you've got defined already, and if you don't have any, put this line into that file in the [main] section: plugins=keyfile then 'killall -TERM nm-system-settings', and run nm-connection-editor. Create the connection of your choice, then look for the "Available to all users" checkbox in the lower-left corner of the editor dialog for the connection. If you check that box, and hit "Apply", the connection will be saved as a system connection and it will be available to all users, and also before any user logs in. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Using a mobile phone via Bluetooth
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan Williams wrote: > On Mon, 2009-07-06 at 23:52 -0400, Ryan Novosielski wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Dan Williams wrote: >>> On Mon, 2009-07-06 at 12:54 -0400, Ryan Novosielski wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Morrison wrote: > Saw this on the Planet Fedora RSS feed today: > > http://fetzig.org/2009/07/04/tethering-in-fedora-using-your-mobile-phone-with-networkmanager-to-surf-the-web/ > > Does this look the sort of thing where a more sane approach could be > added to NM or udev to cope with a wider range of phones without > needing to create user rules? I notice this solution mentions GSM. Is there any reason this should not work for a CDMA phone? >>> As long as the phone responds to AT+GCAP with "IS-707" the probe will >>> tag the phone as a CDMA device and you should be able to use it with a >>> CDMA connection like any normal data card or USB-attached CDMA phone. >>> NM shouldn't be confused by the mis-tagged HAL entry in the linked >>> dialup-bluetooth.py because it prefers the probed capabilities over >>> static ones in HAL. >> So I actually got this working where an rfcomm1 shows up in the NM >> Plasma Applet (I assume that I'm probably supposed to stop setting up >> rfcomm0 manually with /etc/bluetooth/rfcomm.conf). However, nothing I do >> seems to make it want to actually connect. At first the rfcomm1 shows up >> and claims to be looking for an IP address. Then it fails. It's not >> clear that it ever attempts to dialup via PPP, even though I have a >> connection configured. Is there some way to troubleshoot this? > > Sounds like more on the Bluetooth side, of course. Does your phone do > anything when NM tries to bring the connection up? Mine usually asks me > whether I want to allow the computer to connect, or it'll show an icon > saying a computer is connected. In any case, this is exactly why this > method is a hack, and why we want the real solution... My phone is already paired because I use it all the time from kppp, but would love to do it this way instead. I believe there is some activity on the phone but will have to take a look at it again. I'm assuming there's some way to run NM in a mode where I can see exactly what it thinks it's doing? If something fails, it would be good to see what so I can tweak if possible. - -- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer II |$&| |__| | | |__/ | \| _| |novos...@umdnj.edu - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/CST - NJMS Medical Science Bldg - C630 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpTcaEACgkQmb+gadEcsb6XjACbBHvQm8tCzE9Tn5lewIGpjiY3 v78Anj05wTaRnJalDWhMzhCi1OisOwll =DNX0 -END PGP SIGNATURE- begin:vcard fn:Ryan Novosielski n:Novosielski;Ryan org:UMDNJ;IST/AST adr;dom:MSB C630;;185 South Orange Avenue;Newark;NJ;07103 email;internet:novos...@umdnj.edu title:Systems Programmer II tel;work:(973) 972-0922 tel;fax:(973) 972-7412 tel;pager:(866) 20-UMDNJ x-mozilla-html:FALSE version:2.1 end:vcard ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Using a mobile phone via Bluetooth
On Mon, 2009-07-06 at 23:52 -0400, Ryan Novosielski wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Dan Williams wrote: > > On Mon, 2009-07-06 at 12:54 -0400, Ryan Novosielski wrote: > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> Brian Morrison wrote: > >>> Saw this on the Planet Fedora RSS feed today: > >>> > >>> http://fetzig.org/2009/07/04/tethering-in-fedora-using-your-mobile-phone-with-networkmanager-to-surf-the-web/ > >>> > >>> Does this look the sort of thing where a more sane approach could be > >>> added to NM or udev to cope with a wider range of phones without > >>> needing to create user rules? > >> I notice this solution mentions GSM. Is there any reason this should not > >> work for a CDMA phone? > > > > As long as the phone responds to AT+GCAP with "IS-707" the probe will > > tag the phone as a CDMA device and you should be able to use it with a > > CDMA connection like any normal data card or USB-attached CDMA phone. > > NM shouldn't be confused by the mis-tagged HAL entry in the linked > > dialup-bluetooth.py because it prefers the probed capabilities over > > static ones in HAL. > > So I actually got this working where an rfcomm1 shows up in the NM > Plasma Applet (I assume that I'm probably supposed to stop setting up > rfcomm0 manually with /etc/bluetooth/rfcomm.conf). However, nothing I do > seems to make it want to actually connect. At first the rfcomm1 shows up > and claims to be looking for an IP address. Then it fails. It's not > clear that it ever attempts to dialup via PPP, even though I have a > connection configured. Is there some way to troubleshoot this? Sounds like more on the Bluetooth side, of course. Does your phone do anything when NM tries to bring the connection up? Mine usually asks me whether I want to allow the computer to connect, or it'll show an icon saying a computer is connected. In any case, this is exactly why this method is a hack, and why we want the real solution... Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Creating adhoc wireless Network
On Tue, 2009-07-07 at 03:54 -0400, ne...@aflb.com wrote:
> > On Mon, 2009-07-06 at 11:18 -0400, ne...@aflb.com wrote:
> >> Hi Dan,
> >>
> >> I'm playing with the script you provide me but I have a problem :
> >>
> >> File "Create_Wireless.py", line 135, in
> >> if props['DeviceType'] == 2: # wifi
> >> KeyError: 'DeviceType'
> >>
> >> if I execute step by steps :
> >>
> >> >>> print nm_iface.GetDevices()
> >> dbus.Array([dbus.ObjectPath('/org/freedesktop/Hal/devices/net_00_24_81_56_2e_52'),
> >> dbus.ObjectPath('/org/freedesktop/Hal/devices/net_00_22_fa_46_76_9a')],
> >> signature=dbus.Signature('o'))
> >> >>> dev_proxy =
> >> sys_bus.get_object('org.freedesktop.NetworkManager','/org/freedesktop/Hal/devices/net_00_22_fa_46_76_9a')
> >> >>> print dev_proxy
> >> :1.7
> >> /org/freedesktop/Hal/devices/net_00_22_fa_46_76_9a at 0xb7a5a80c>
> >> >>> dev_props_iface = dbus.Interface(dev_proxy,
> >> 'org.freedesktop.DBus.Properties')
> >> >>> print dev_props_iface
> >> >> 0xb7a5811c> :1.7 /org/freedesktop/Hal/devices/net_00_22_fa_46_76_9a at
> >> 0xb7a5a80c> implementing 'org.freedesktop.DBus.Properties' at
> >> 0xb7a5a9ac>
> >> >>> print
> >> dev_props_iface.GetAll('org.freedesktop.NetworkManager.Device')
> >> dbus.Dictionary({}, signature=dbus.Signature('sv'))
> >>
> >> It seems empty ! What's wrong ?
> >
> > What version of dbus-glib do you have? What does 'nm-tool' print out
> > when you run it?
> >
> > Dan
> >
>
> Version provided by SLED11
>
> dbus-1-glib-0.76-34.3
Ok, that's not quite new enough, anything < 0.77 has a bug with GetAll
that causes properties to not be found. The commit in question is:
d1b80d803a0268bd4b3dd5b9a9522230461f2947
Author: Dan Williams 2008-06-05 17:57:53
Committer: Colin Walters 2008-06-05 17:57:53
Follows: dbus-glib_0.76
Precedes: dbus-glib_0.78
Bug 16114 [patch] wincaps-to-uscore property names for GetAll()
* dbus/dbus-gobject.c: We need to uscore property names
so that we actually find the right properties.
but, the good news is that you could do:
dbus_props_iface.Get('org.freedesktop.NetworkManager.Device', '')
and get the properties you care about individually instead of all of
them at once. Somewhat less efficient, but it'll work.
Dan
> dbus-1-1.2.10-3.9.1
> dbus-1-python-0.83.0-22.10
>
> nm-tool print the two interfaces with parameters :
>
> NetworkManager Tool
>
> State: connected
>
> - Device: eth0
>
> Type: Wired
> Driver:tg3
> State: connected
> Default: yes
> HW Address:00:24:81:56:2E:52
>
> Capabilities:
> Supported: yes
> Carrier Detect: yes
> Speed: 100 Mb/s
>
> Wired Settings
>
> IPv4 Settings:
> Address: 10.82.109.86
> Prefix: 24 (255.255.255.0)
> Gateway: 10.82.109.254
>
> DNS: 10.82.161.3
> DNS: 10.68.161.3
>
>
> - Device: eth1
>
> Type: 802.11 WiFi
> Driver:iwlagn
> State: connected
> Default: no
> HW Address:00:22:FA:46:76:9A
>
> Capabilities:
> Supported: yes
>
> Wireless Settings
> WEP Encryption: yes
> WPA Encryption: yes
> WPA2 Encryption: yes
>
> Wireless Access Points(* = Current AP)
> TESTIPSL:Infra, 00:03:2F:1D:61:BF, Freq 2437 MHz, Rate 54
> Mb/s, Strength 79 WEP
> *iSync: Ad-Hoc, D6:08:0C:12:06:49, Freq 2412 MHz, Rate 0
> Mb/s, Strength 0
>
> IPv4 Settings:
> Address: 10.42.44.1
> Prefix: 24 (255.255.255.0)
> Gateway: 0.0.0.0
>
>
> >> Thanks
> >>
> >>
> >> > On Wed, 2009-07-01 at 12:28 -0400, Dan Williams wrote:
> >> >> On Wed, 2009-07-01 at 11:26 -0400, ne...@aflb.com wrote:
> >> >> > Thanks for this quick answer.
> >> >> >
> >> >> > That's what I though. Adding a new connection isnot easy to do...
> >> >> >
> >> >> > when you say "programmatically ask the system settings service to
> >> >> create it"
> >> >> >
> >> >> > What do you mean ? Doing the same stuff as nm-applet but hardcoded
> >> ?
> >> >>
> >> >> Same way nm-connection-editor asks the system settings service to
> >> create
> >> >> a new connection when the user hits "Apply": you call the
> >> >> AddConnection() method on the
> >> >> org.freedesktop.NetworkManagerSettings.System interface with the
> >> >> connection details you want to set.
> >> >>
> >> >> Unfortunately we didn't define that method to return the object path
> >> of
> >> >> the newly created connection in 0.7 (will probably be fixed in 0.8),
> >> so
> >> >> you have to wait for the NewConnection signal that the
> >> >> system-settings-service emits, look for the UUID of the connection
> >> you
> >> >> just created to get the object path, and then tell NM to activate
> >> that
> >> >> connection.
> >> >>
> >
Re: ZTE modem problems and workrounds
--On Tuesday, July 07, 2009 00:03:49 +0100 Rick Jones
wrote:
I find that about one time in 4 or 5 it doesn't detect any port as a
modem, but unplug/re-plug and it usually gets it. I think this is probably
because the probe responses get masked by the stream of UMs coming out
(+ZUSIMR:2), these need to be killed off by sending +CPMS?. This has to be
done anyway to get the thing to dial reliably - I rely on an external
script to do it at the moment, but it's not ideal. Would it be feasible for
nm-modem-probe to do this?
There is another problem with the serial port termios modes, AFAICT, NM
doesn't set them up, but neither does the Option driver. They can have an
arbitrary state which results in unpredictable behaviour, and even kernel
panics.
OK, I retract that, having looked at the source code!
It's strange, but when trying to get concrete symptoms from the previous
erratic behaviour, I was certain that running "stty raw" on each port
improved the way it worked. Must have been an illusion.
However, I've looked at nm-modem-probe, and tried a patch which seems to
work quite well - diff is attached.
It sends an initialisation to the modem before trying the various tests,
this is "AT E0 +CPMS". Turning off echo reduces the clutter in the
responses, and +CPMS is ZTE-specific to stop it emitting continuous UMs,
which just get in the way of everything. +CPMS is actually invalid, but has
the right effect, and should be benign on any other modem.
I also removed the \n from the modem commands, again it reduces response
clutter (the modem takes \r as command terminator). However, maybe \r\n is
needed for other modems? I don't know.
With this patch I now get 100% modem detection, and connection on the first
or second try. That is a HUGE improvement!
Rick
--- nm-modem-probe-orig.c 2009-07-06 15:36:36.0 +0100
+++ nm-modem-probe.c 2009-07-07 12:24:15.0 +0100
@@ -329,6 +329,15 @@
timeout_ms -= 500;
}
+ /* PATCH - turn off echo and send +CPMS to stop ZTE +ZUSIMR messages */
+ if (modem_send_command (fd, "AT E0 +CPMS\r"))
+ {
+ const char *null_responses[] = { NULL };
+ /* we expect ERROR response! */
+ modem_wait_reply (fd, 2, null_responses, terminators, &term_idx, &reply);
+ }
+ /* END PATCH */
+
/* Standard response timeout case */
timeout_ms += 3000;
@@ -339,7 +348,7 @@
g_get_current_time (&start);
idx = term_idx = 0;
- send_success = modem_send_command (fd, "AT+GCAP\r\n");
+ send_success = modem_send_command (fd, "AT+GCAP\r");
if (send_success)
idx = modem_wait_reply (fd, 2, gcap_responses, terminators, &term_idx, &reply);
else
@@ -391,7 +400,7 @@
reply = NULL;
verbose ("GCAP failed, trying ATI...");
- if (modem_send_command (fd, "ATI\r\n")) {
+ if (modem_send_command (fd, "ATI\r")) {
idx = modem_wait_reply (fd, 3, ati_responses, terminators, &term_idx, &reply);
if (0 == term_idx && 0 == idx) {
verbose ("ATI response: %s", reply);
@@ -410,7 +419,7 @@
if ((idx != -2) && !(ret & MODEM_CAP_GSM) && !(ret & MODEM_CAP_IS707_A)) {
const char *cgmm_responses[] = { CGMM_TAG, NULL };
- if (modem_send_command (fd, "AT+CGMM\r\n")) {
+ if (modem_send_command (fd, "AT+CGMM\r")) {
idx = modem_wait_reply (fd, 5, cgmm_responses, terminators, &term_idx, &reply);
if (0 == term_idx && 0 == idx) {
verbose ("CGMM response: %s", reply);
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ZTE modem problems and workrounds
On Mon, Jul 6, 2009 at 6:57 PM, Dan Williams wrote: > On Thu, 2009-07-02 at 22:56 +0200, Przemek Kulczycki wrote: >> Hi Dan. >> I have a similar problem with my ZTE MF626 bought in Poland. >> I'm attaching outputs of lshal, lsusb -vv and dmesg. >> If you need any more outputs from me, feel free to ask. >> I'm using Ubuntu 9.04 64-bit. >> Linux macbook 2.6.28-13-generic #44-Ubuntu SMP Tue Jun 2 07:55:09 UTC >> 2009 x86_64 GNU/Linux >> network-manager 0.7.1~rc4.1.cf199a964-0ubuntu2 >> Cheers, > > Which port of your MF626 actually works with PPP? AFAIK it's ttyUSB1. This is the port that I'm using in Wammu to receive SMS from the modem. > Also, are you running VirtualBox or something? HAL seems screwed up in > your lshal, because it's listed two separate devices as "ttyUSB2", which > is something I've only seen caused by VirtualBox trying to virtualize > sysfs and screwing up device links there horribly. No, I don't have VirtualBox, nor any other VM software installed. My modem has a built-in microSD card reader, maybe this is the reason. -- ## Przemysław Kulczycki >><< Azrael Nightwalker ## # jabber: azrael[na]jabster.pl | tlen: azrael29a # ### www: http://reksio.ftj.agh.edu.pl/~azrael/ ### ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM CLI
John Mahoney a écrit : > I like python, but I only see it becoming a limitation once the system > reaches an embedded device. Python does not like to run on systems with 64 > megs or less. If the final goal is to have a cli with the ability to run > without even an x server then I see the embedded space a large target user > space of this feature and writing it in c would be highly beneficial. Well, I guess both incarnations could exist? The one in a high-level programming language serving as a proving ground for the one in C (premature optimization..., etc., etc.) > I am willing to help on this, but it is still unclear to me what people > refer to as a cli. I suspect most people just want something that looks like the good old ifup/ifdown, /etc/init.d/network[ing] interface together with the flexibility and ease of its text configuration files. Cheers, Marc ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Creating adhoc wireless Network
> On Mon, 2009-07-06 at 11:18 -0400, ne...@aflb.com wrote:
>> Hi Dan,
>>
>> I'm playing with the script you provide me but I have a problem :
>>
>> File "Create_Wireless.py", line 135, in
>> if props['DeviceType'] == 2: # wifi
>> KeyError: 'DeviceType'
>>
>> if I execute step by steps :
>>
>> >>> print nm_iface.GetDevices()
>> dbus.Array([dbus.ObjectPath('/org/freedesktop/Hal/devices/net_00_24_81_56_2e_52'),
>> dbus.ObjectPath('/org/freedesktop/Hal/devices/net_00_22_fa_46_76_9a')],
>> signature=dbus.Signature('o'))
>> >>> dev_proxy =
>> sys_bus.get_object('org.freedesktop.NetworkManager','/org/freedesktop/Hal/devices/net_00_22_fa_46_76_9a')
>> >>> print dev_proxy
>> :1.7
>> /org/freedesktop/Hal/devices/net_00_22_fa_46_76_9a at 0xb7a5a80c>
>> >>> dev_props_iface = dbus.Interface(dev_proxy,
>> 'org.freedesktop.DBus.Properties')
>> >>> print dev_props_iface
>> > 0xb7a5811c> :1.7 /org/freedesktop/Hal/devices/net_00_22_fa_46_76_9a at
>> 0xb7a5a80c> implementing 'org.freedesktop.DBus.Properties' at
>> 0xb7a5a9ac>
>> >>> print
>> dev_props_iface.GetAll('org.freedesktop.NetworkManager.Device')
>> dbus.Dictionary({}, signature=dbus.Signature('sv'))
>>
>> It seems empty ! What's wrong ?
>
> What version of dbus-glib do you have? What does 'nm-tool' print out
> when you run it?
>
> Dan
>
Version provided by SLED11
dbus-1-glib-0.76-34.3
dbus-1-1.2.10-3.9.1
dbus-1-python-0.83.0-22.10
nm-tool print the two interfaces with parameters :
NetworkManager Tool
State: connected
- Device: eth0
Type: Wired
Driver:tg3
State: connected
Default: yes
HW Address:00:24:81:56:2E:52
Capabilities:
Supported: yes
Carrier Detect: yes
Speed: 100 Mb/s
Wired Settings
IPv4 Settings:
Address: 10.82.109.86
Prefix: 24 (255.255.255.0)
Gateway: 10.82.109.254
DNS: 10.82.161.3
DNS: 10.68.161.3
- Device: eth1
Type: 802.11 WiFi
Driver:iwlagn
State: connected
Default: no
HW Address:00:22:FA:46:76:9A
Capabilities:
Supported: yes
Wireless Settings
WEP Encryption: yes
WPA Encryption: yes
WPA2 Encryption: yes
Wireless Access Points(* = Current AP)
TESTIPSL:Infra, 00:03:2F:1D:61:BF, Freq 2437 MHz, Rate 54
Mb/s, Strength 79 WEP
*iSync: Ad-Hoc, D6:08:0C:12:06:49, Freq 2412 MHz, Rate 0
Mb/s, Strength 0
IPv4 Settings:
Address: 10.42.44.1
Prefix: 24 (255.255.255.0)
Gateway: 0.0.0.0
>> Thanks
>>
>>
>> > On Wed, 2009-07-01 at 12:28 -0400, Dan Williams wrote:
>> >> On Wed, 2009-07-01 at 11:26 -0400, ne...@aflb.com wrote:
>> >> > Thanks for this quick answer.
>> >> >
>> >> > That's what I though. Adding a new connection isnot easy to do...
>> >> >
>> >> > when you say "programmatically ask the system settings service to
>> >> create it"
>> >> >
>> >> > What do you mean ? Doing the same stuff as nm-applet but hardcoded
>> ?
>> >>
>> >> Same way nm-connection-editor asks the system settings service to
>> create
>> >> a new connection when the user hits "Apply": you call the
>> >> AddConnection() method on the
>> >> org.freedesktop.NetworkManagerSettings.System interface with the
>> >> connection details you want to set.
>> >>
>> >> Unfortunately we didn't define that method to return the object path
>> of
>> >> the newly created connection in 0.7 (will probably be fixed in 0.8),
>> so
>> >> you have to wait for the NewConnection signal that the
>> >> system-settings-service emits, look for the UUID of the connection
>> you
>> >> just created to get the object path, and then tell NM to activate
>> that
>> >> connection.
>> >>
>> >> It's pretty straightforward actually, once you know what needs to be
>> >> done. If PolicyKit throws up a dialog, use
>> polkit-gnome-authorization
>> >> to allow the user to always have the
>> >> org.freedesktop.network-manager-settings.system.modify permission and
>> >> the user won't ever get asked.
>> >
>> > Check out the attached script. It will create a WEP-enabled adhoc
>> > connection if that connection (identified by UUID) doesn't already
>> > exist, and then direct NetworkManager to activate that connection.
>> The
>> > script is somewhat longer than it needs to be, simply because I made
>> it
>> > more readable, added comments so you can figure out what's going on,
>> and
>> > put some reasonable error checking in.
>> >
>> > Dan
>> >
>> >
>> > #!/bin/env python
>> > # -*- Mode: Python; tab-width: 4; indent-tabs-mode: nil;
>> c-basic-offset: 4
>> > -*-
>> > #
>> > # Copyright (C) 2009 Red Hat, Inc.
>> > #
>> > # This program is free software; you can redistribute it and/or modify
>> > # it under the terms of the GNU General Public License as publishe
