Re: Add new conntion with DBus API
On 6 May 2010 07:39, Nguyen Canh Toan toan...@viettel.com.vn wrote:
Hi all,
Currently, I have a purpose of programmatically add remove connection
configuration through DBus interface
org.freedesktop.NetworkManagerSettings.Connection.
I found an API Delete() on
org.freedesktop.NetworkManagerSettings.Connection but I can’t find what
function stuff to create new connection.
Did anyone experience with this issue? Could you please to share it to me?
Hi Nguyen,
you'll need to create it via gconf. A connection is represented as a dict of
dicts in DBus or a dir of dirs in gconf. As gconf lacks a create this tree
atomically command, you'll need to set the values one by one. NMSettings
will send a NewConnection signal when it decides that the profile is
created/ready.
Pablo
Thanks,
Toan Nguyen
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
--
Pablo Martí
http://minimoesfuerzo.org
python -c print
'706d617267616d40676d61696c2e636f6d'.decode('hex')
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Add new conntion with DBus API
On 5 May 2010 10:53, Jirka Klimes jkli...@redhat.com wrote:
On Thursday 06 of May 2010 07:39:07 Nguyen Canh Toan wrote:
Hi all,
Currently, I have a purpose of programmatically add remove connection
configuration through DBus interface
org.freedesktop.NetworkManagerSettings.Connection.
I found an API Delete() on
org.freedesktop.NetworkManagerSettings.Connection but I can't find what
function stuff to create new connection.
Did anyone experience with this issue? Could you please to share it to
me?
Thanks,
Toan Nguyen
You search for AddConnection() method of
org.freedesktop.NetworkManagerSettings interface.
For a simple python example see:
http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/python/add-
system-connection.pyhttp://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/python/add-%0Asystem-connection.py
More complex example can be found here:
http://markmail.org/message/2xfwvjqjovu4fk2j
For specification of settings parameters
see:
http://projects.gnome.org/NetworkManager/developers/settings-spec-08.html
Wow, I didn't know about this one, thought that gconf was the only was to
edit the connection. When was this added?
--
Pablo Martí
http://minimoesfuerzo.org
python -c print '706d617267616d40676d61696c2e636f6d'.decode('hex')
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Add new conntion with DBus API
2010/5/5 Jirka Klimes jkli...@redhat.com
On Wednesday 05 of May 2010 11:28:11 Pablo Martí Gamboa wrote:
On 5 May 2010 10:53, Jirka Klimes jkli...@redhat.com wrote:
On Thursday 06 of May 2010 07:39:07 Nguyen Canh Toan wrote:
Hi all,
Currently, I have a purpose of programmatically add remove
connection
configuration through DBus interface
org.freedesktop.NetworkManagerSettings.Connection.
I found an API Delete() on
org.freedesktop.NetworkManagerSettings.Connection but I can't find
what
function stuff to create new connection.
Did anyone experience with this issue? Could you please to share it
to
me?
Thanks,
Toan Nguyen
You search for AddConnection() method of
org.freedesktop.NetworkManagerSettings interface.
For a simple python example see:
http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/p
ython/add-
system-connection.py
http://cgit.freedesktop.org/NetworkManager/NetworkM
anager/tree/examples/python/add-%0Asystem-connection.py
More complex example can be found here:
http://markmail.org/message/2xfwvjqjovu4fk2j
For specification of settings parameters
see:
http://projects.gnome.org/NetworkManager/developers/settings-spec-08.html
Wow, I didn't know about this one, thought that gconf was the only was to
edit the connection. When was this added?
It's been there for some time now.
The commit is 0d69dfe39ef61b42b2024c7fbd8bbad9e9c6d164 from 23.7.2009.
Thanks for the info!
--
Pablo Martí
http://minimoesfuerzo.org
python -c print '706d617267616d40676d61696c2e636f6d'.decode('hex')
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Confusing about DBus API specification
2010/4/29 Nguyen Canh Toan toan...@viettel.com.vn
Hi all,
After reading DBus API
http://projects.gnome.org/NetworkManager/developers/spec-07.html#org.freedesktop.NetworkManager
I try to list all connection setting by below interface specification
* *
*org.freedesktop.NetworkManagerSettings*
The NetworkManagerSettings interface is provided by the service which
provides connections to NetworkManager.
Methods:
ListConnections ( ) → ao
List the connections stored by this Settings object.
Returns
connections - ao
List of connections.
Signals:
NewConnection ( o: connection )
Emitted when a new connection has been configured.
Parameters
connection - o
Object path of the new connection.
Interface has no properties.
*Without success. *DBus service say:
Traceback (most recent call last):
File ./python_dbus_client, line 21, in module
connections = manager.ListConnections()
File /var/lib/python-support/python2.6/dbus/proxies.py, line 140, in
__call__
**keywords)
File /var/lib/python-support/python2.6/dbus/connection.py, line 622, in
call_blocking
message, timeout)
*dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod:
Method ListConnections with signature on interface
org.freedesktop.NetworkManager doesn't exist*
That's because ListConnections is a method of the
org.freedesktop.NetworkManagerSettings
interface ;)
Try executing your method as:
connections = manager.ListConnections(dbus_interface=
org.freedesktop.NetworkManagerSettings)
Best regards,
--
Pablo Martí // http://minimoesfuerzo.org
python -c print '706d617267616d40676d61696c2e636f6d'.decode('hex')
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: USSD interface for ModemManager
2010/3/10 Pablo Martí Gamboa pma...@warp.es
2010/3/10 Dan Williams d...@redhat.com
On Tue, 2010-03-09 at 17:34 -0800, Dan Williams wrote:
On Tue, 2010-03-09 at 13:45 +0100, Pablo Martí Gamboa wrote:
Hi Dan, Marcel and others,
we would like to extend the ModemManager API so that it can handle
USSD commands. The USSD API of oFono [0] looks quite nice IMHO and I'd
like to propose a similar API:
I'd actually change two things; this API (and by extension the ofono
one) doesn't allow clients to respond to a USSD request that is pending
when they start up. Say your app sends the request, then crashes or
something. When it's crashed, the network sends the response. Now your
app can't get the response when it starts back up and handle it, it
would have to cancel the USSD session and send the request again.
I tossed this into the MM introspection/ directory with my proposed
changes; keeping the changes or dropping them doesn't make a huge
difference to me, I just thought it was a slightly more robust way of
doing the API. Updated spec HTML attached for your review.
Looks good to me, thanks!
Hmm, seems I made up my mind too fast. There is one wart in the proposed API
Initiate/Reply doesn't return anything, it will set the
Network{Request,Notification} property which in turn will fire the
MmPropertiesChanged signal. I think that's a slightly cumbersome way of
getting the reply. IMHO both methods (Initiate and Reply) should return a
string. Our UI code has enough callbacks me thinks, having to listen for the
MmPropertiesChanged signal to get the response of an USSD command seems
wrong to me. MmPropertiesChanged is nice, but has a completely different use
case (a low level internal interaction might result on an important property
change -say Enabled- and the UI is notified)
Thoughts ?
Pablo
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
USSD interface for ModemManager
Hi Dan, Marcel and others,
we would like to extend the ModemManager API so that it can handle USSD
commands. The USSD API of oFono [0] looks quite nice IMHO and I'd like to
propose a similar API:
USSD Interface
===
Service org.freedesktop.ModemManager
Interface org.freedesktop.ModemManager.Modem.Gsm.Ussd
Methods string Initiate(string command)
Sends a USSD command string to the network
initiating a session. When the request is handled
by the appropriate node of the network, the
method returns the response or an appropriate
error. The network may be awaiting further response
from the ME after returning from this method and no
new command can be initiated until this one is
cancelled or ended.
void Respond(string reply)
Send a response to the network either when
it is awaiting further input after Initiate()
was called or after a network-initiated request.
void Cancel()
Cancel an ongoing USSD session, mobile- or
network-initiated.
Signals
NotificationReceived(string message)
Signal is emitted on a network-initiated USSD
request for which no response is needed.
RequestReceived(string message)
Signal is emitted on a network-initiated USSD
request for which a response must be sent using
the Respond method unless it is cancelled or
the request is not supported.
Properties string State [readonly]
Reflects the state of current USSD session. The
values have the following meanings:
idle No active USSD session.
active A session is active between the
network and the ME, the ME is
waiting for a reply from the
network.
user-response The network is waiting for the
user's response, client must
call Respond().
It is basically a copy of their API (they nailed it down) except for
GetProperties and PropertiesChanged signal which are ConnMan-specific. I
haven't had a use-case yet for the Respond command (my USSD petitions are
simple), but it needs to be there indeed for future uses. Thoughts?
[0]
http://git.kernel.org/?p=network/ofono/ofono.git;a=blob_plain;f=doc/supplementaryservices-api.txt;hb=HEAD
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager location APIs
2010/3/6 Dan Williams d...@redhat.com
Hi Pablo and others,
I pushed up a proposal for a location information API to MM git. If you
have a bit of time would you mind taking a look at it? Any suggestions
would be most welcome. The bits about security do make things a bit
more complicated, but I decided to add them since at least many phone
manufacturers take pains to ensure that users can limit which
applications have access to location-based APIs.
The API is nice, and the security stuff certainly needs to be there. Looks
good to me.
I've got some thoughts about the .Gsm.Hso and .Gsm.Sms interfaces, I'll
create a small report tomorrow. We are also working on USSD here, and I'd
like to draft an API together. I'll send an email tomorrow.
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [ANN] NetworkManager 0.8 released
On 2 March 2010 09:03, Dan Williams d...@redhat.com wrote:
Hello everyone,
After somewhat more than a year in development, I'm happy to announce
the release of NetworkManager 0.8 and it's associated components,
network-manager-applet, the four VPN daemons, and ModemManager 0.3.
We spent the past year reworking NetworkManager to better support mobile
broadband connections, Bluetooth, IPv6, and 802.1x authenticated
connections to name a few of the big features. Along with literally
hundreds of bug fixes.
Hi Dan,
congrats on this new release, I'm sure NM users will love it. I can confirm
that with this new release the ModemManager integration is working
flawlessly, so I'm quite happy too :) Isn't it a bit late for releasing
software ? ;)
All the best,
Pablo
And there's more kick-ass stuff coming for 0.8.1. Bluetooth DUN and
DHCPv6 support have already been merged, and we're right in the middle
of adding mobile broadband signal strength (finally!) and live operator
information. See the NetworkManager/ReleaseProcess wiki page on
live.gnome.org for more information about what's coming soon.
In the mean time, you can grab NetworkManager 0.8 and the other
components here:
http://ftp.gnome.org/pub/GNOME/sources/NetworkManager/0.8/
http://ftp.gnome.org/pub/GNOME/sources/ModemManager/0.3/
http://ftp.gnome.org/pub/GNOME/sources/NetworkManager-openconnect/0.8/
http://ftp.gnome.org/pub/GNOME/sources/NetworkManager-openvpn/0.8/
http://ftp.gnome.org/pub/GNOME/sources/NetworkManager-pptp/0.8/
http://ftp.gnome.org/pub/GNOME/sources/NetworkManager-vpnc/0.8/
http://ftp.gnome.org/pub/GNOME/sources/network-manager-applet/0.8/
As always, for more information, check out:
http://www.gnome.org/projects/NetworkManager/
http://live.gnome.org/NetworkManager
Cheers,
Dan
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem with Simple.Connect
2009/12/2 Dan Williams d...@redhat.com
On Wed, 2009-12-02 at 12:36 +0100, Pablo Martí Gamboa wrote:
Any progress on this front? :)
Yes. I'm finishing up the modem states changes (an internal
implementation detail of MM) at which point I'll be applying a previous
patch for DTR toggling as part of a 'disconnect' cleanup. For modems
that have multiple ports (and aren't special like mbm or hso) we can
disconnect more easily here, as we can deactivate the PDP context on the
other TTY and thus ensure the connection is really down before we try to
break into the PPP stream. The other complication is that NM for
example does try to give PPP time to gracefully exit, and we should
actually fix NM to only call disconnect when it knows that PPP has
terminated.
I'm *VERY* happy to report that this problem is gone in 0.8. This is the log
of five successful connection attempts in a row :))
http://pastebin.com/m3a9eb6a9
Thanks a lot for making it happen
Pablo
Dan
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] mbm plugin: send enap=0 on disable
2009/11/20 Dan Williams d...@redhat.com
On that note Pablo, would you mind if I added an Enabled (type bool)
property to the org.freedesktop.ModemManager.Modem interface to indicate
the current enablement state?
Not at all, it is required indeed!
The reason I want to do this is because in the multi-modem-user case
where NM should not be disabling the device, we still need a mechanism
to allow users to do that to save power or whatever if their laptop does
not support rfkill of the device. For NetworkManager, I'd put a Enable
Mobile Broadband checkbox into the right-click menu of nm-applet, just
like the Enable Wireless checkbox is there. This checkbox would reflect
the state of each modem's Enabled property. If the user unchecked the
box, the applet would direct NetworkManager to disable all 3G devices
using Enable(false), while simply choosing Disconnect in the menu would
direct NM to call Disconnect() as we've previously discussed.
Dan
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] mbm plugin: send enap=0 on disable
2009/11/20 Torgny Johansson torgny.johans...@gmail.com
Hi!
This patch makes the mbm plugin send at*enap=0 when disable is called.
Currently enap=0 is only sent when disconnect is called which I don't see
happening. That causes enap to stay
connected even if the user selects disconnect from nm-applet.
I'm not sure if this is the intended behaviour or if the bug is that
disconnect isn't being called though...
Hi Torgny,
NM 0.8 sends Enable(false) instead of Disconnect(), assuming that it
should disconnect the device too, although as you well know, that is not
always the case. This is a deviation from the original ModemManager spec,
Dan Williams acknowledged this problem and it should be fixed soon.
Regards,
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem with Simple.Connect
2009/10/26 Dan Williams d...@redhat.com
On Mon, 2009-10-26 at 13:36 +0100, Pablo Martí Gamboa wrote:
Also I'm having reliability problems with PPP devices and
Simple.Connect, first attempt will work (most of the time) but the
second will never.
That may be because the data session is not properly torn down by either
Disconnect or Enable(false). Not sure though, I have seen this at
various times too and haven't been able to pin it down. Usually some
combination of init strings end up fixing this.
It seems other users are having pppd_timeout() problems too:
https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/393094
https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/407519
https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/432205
Is it possible they are related?
Pablo
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem with Simple.Connect
2009/10/26 Dan Williams d...@redhat.com
On Mon, 2009-10-26 at 13:36 +0100, Pablo Martí Gamboa wrote:
2009/10/26 Pablo Martí Gamboa pma...@warp.es
2009/10/9 Dan Williams d...@redhat.com
On Thu, 2009-10-08 at 10:33 +0200, Pablo Martí Gamboa
wrote:
I forgot to mention that when I press Disconnect
from nm-applet,
that just issues an Enable(false) to the device
rather than
Disconnect(); Enable(false);, I asked yesterday in
#nm and nobody
seemed to recall why that decision had been made,
they just remembered
that it was more reliable for a particular device.
In my case it is
the other way around! will nm0.8 ship like this?
Right now NM doesn't call disconnect at all, AFAIK.
It just calls
Enable(false). We assume that also cleans up the
connection and
disables the modem, since disabling the modem implies
the connection is
torn down. Is that not working?
For projects like NM this behaviour is acceptable, between
every connection attempt you don't do any operations with the
3G device. However for projects like Wader, this is an
unfortunate change. Now when we issue a DeactivateConnection,
we get an Enable(false) sent to our device, deactivating the
radio and leaving the device unusable for some operations. Why
don't we stick to the original vocabulary? Enable(true);
Connect(settings); Disconnect(); Enable(false);
Right now the harm is already done, and we are going to have
to ship with a workaround for this behaviour (unless somehow
the patch makes it into the distros before 0.8, which for
Ubuntu is already too late).
Please please, go back to the old behaviour.
Yes, this should be fixed in NetworkManager.
I finally gave up and disabled NM compatibility, the reason is that NM
does not respect current ModemManager vocabulary and adding so many
workarounds is polluting my code:
* When a device is announce via DeviceAdded, NM sends right away
two Enable(0) (should be boolean). workaround #1
This is sub-optimal behavior in NetworkManager, and it should be fixed
in NetworkManager before NM 0.8. NM should not be sending this when the
device is recognized. The problem code is in
nm-modem.c::device_state_changed(), and should be changed to take the
old_state into account.
* When a Simple.Connect call is issued, NM sends right away two
Enable(0) (I assume that to make sure we are not connected) thus
breaking my internal state, workaround #2
This is most likely the same problem as above; and the fix should be the
same as the problem above.
* When I press Disconnect from nm-applet, it won't send a
Disconnect, it sends Enable(0) twice again. workaround #3
This is a second problem, and should be fixed in NetworkManager.
* When a Simple.Connect call is issued, NM does not bother to
Enable(true) the device, it assumes that the internal simple state
machine will do it for us. Not working around it :S
Fair enough; if we relied on that behavior explicitly, it should have
been included in the specification documentation originally.
Also I'm having reliability problems with PPP devices and
Simple.Connect, first attempt will work (most of the time) but the
second will never.
That may be because the data session is not properly torn down by either
Disconnect or Enable(false). Not sure though, I have seen this at
various times too and haven't been able to pin it down. Usually some
combination of init strings end up fixing this.
Thanks for acknowledging this issues Dan. Looking forward to the fixes :)
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem with Simple.Connect
2009/10/9 Dan Williams d...@redhat.com
On Thu, 2009-10-08 at 10:33 +0200, Pablo Martí Gamboa wrote:
I forgot to mention that when I press Disconnect from nm-applet,
that just issues an Enable(false) to the device rather than
Disconnect(); Enable(false);, I asked yesterday in #nm and nobody
seemed to recall why that decision had been made, they just remembered
that it was more reliable for a particular device. In my case it is
the other way around! will nm0.8 ship like this?
Right now NM doesn't call disconnect at all, AFAIK. It just calls
Enable(false). We assume that also cleans up the connection and
disables the modem, since disabling the modem implies the connection is
torn down. Is that not working?
For projects like NM this behaviour is acceptable, between every connection
attempt you don't do any operations with the 3G device. However for projects
like Wader, this is an unfortunate change. Now when we issue a
DeactivateConnection, we get an Enable(false) sent to our device,
deactivating the radio and leaving the device unusable for some operations.
Why don't we stick to the original vocabulary? Enable(true);
Connect(settings); Disconnect(); Enable(false);
Right now the harm is already done, and we are going to have to ship with a
workaround for this behaviour (unless somehow the patch makes it into the
distros before 0.8, which for Ubuntu is already too late).
Please please, go back to the old behaviour.
Pablo+
This was an unfortunate change and should be reverted as soon as possible
BTW, how do you handle breaking into the ongoing PPP session on a 1-port
modem and hanging up the connection? +++ATH? Or AT D1, setting the
serial port's DTR to off and then ATH?
Dan
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem with Simple.Connect
2009/10/26 Pablo Martí Gamboa pma...@warp.es
2009/10/9 Dan Williams d...@redhat.com
On Thu, 2009-10-08 at 10:33 +0200, Pablo Martí Gamboa wrote:
I forgot to mention that when I press Disconnect from nm-applet,
that just issues an Enable(false) to the device rather than
Disconnect(); Enable(false);, I asked yesterday in #nm and nobody
seemed to recall why that decision had been made, they just remembered
that it was more reliable for a particular device. In my case it is
the other way around! will nm0.8 ship like this?
Right now NM doesn't call disconnect at all, AFAIK. It just calls
Enable(false). We assume that also cleans up the connection and
disables the modem, since disabling the modem implies the connection is
torn down. Is that not working?
For projects like NM this behaviour is acceptable, between every connection
attempt you don't do any operations with the 3G device. However for projects
like Wader, this is an unfortunate change. Now when we issue a
DeactivateConnection, we get an Enable(false) sent to our device,
deactivating the radio and leaving the device unusable for some operations.
Why don't we stick to the original vocabulary? Enable(true);
Connect(settings); Disconnect(); Enable(false);
Right now the harm is already done, and we are going to have to ship with a
workaround for this behaviour (unless somehow the patch makes it into the
distros before 0.8, which for Ubuntu is already too late).
Please please, go back to the old behaviour.
Pablo+
This was an unfortunate change and should be reverted as soon as possible
Didn't want to repeat myself here, sorry
BTW, how do you handle breaking into the ongoing PPP session on a 1-port
modem and hanging up the connection? +++ATH? Or AT D1, setting the
serial port's DTR to off and then ATH?
Dan
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem with Simple.Connect
2009/10/26 Pablo Martí Gamboa pma...@warp.es
2009/10/9 Dan Williams d...@redhat.com
On Thu, 2009-10-08 at 10:33 +0200, Pablo Martí Gamboa wrote:
I forgot to mention that when I press Disconnect from nm-applet,
that just issues an Enable(false) to the device rather than
Disconnect(); Enable(false);, I asked yesterday in #nm and nobody
seemed to recall why that decision had been made, they just remembered
that it was more reliable for a particular device. In my case it is
the other way around! will nm0.8 ship like this?
Right now NM doesn't call disconnect at all, AFAIK. It just calls
Enable(false). We assume that also cleans up the connection and
disables the modem, since disabling the modem implies the connection is
torn down. Is that not working?
For projects like NM this behaviour is acceptable, between every connection
attempt you don't do any operations with the 3G device. However for projects
like Wader, this is an unfortunate change. Now when we issue a
DeactivateConnection, we get an Enable(false) sent to our device,
deactivating the radio and leaving the device unusable for some operations.
Why don't we stick to the original vocabulary? Enable(true);
Connect(settings); Disconnect(); Enable(false);
Right now the harm is already done, and we are going to have to ship with a
workaround for this behaviour (unless somehow the patch makes it into the
distros before 0.8, which for Ubuntu is already too late).
Please please, go back to the old behaviour.
I finally gave up and disabled NM compatibility, the reason is that NM does
not respect current ModemManager vocabulary and adding so many workarounds
is polluting my code:
* When a device is announce via DeviceAdded, NM sends right away two
Enable(0) (should be boolean). workaround #1
* When a Simple.Connect call is issued, NM sends right away two
Enable(0) (I assume that to make sure we are not connected) thus breaking
my internal state, workaround #2
* When I press Disconnect from nm-applet, it won't send a
Disconnect, it sends Enable(0) twice again. workaround #3
* When a Simple.Connect call is issued, NM does not bother to
Enable(true) the device, it assumes that the internal simple state machine
will do it for us. Not working around it :S
Also I'm having reliability problems with PPP devices and Simple.Connect,
first attempt will work (most of the time) but the second will never.
Bear in mind that I am not dissing anyone's work here, this is just a
summary of some of the problems that an alternate ModemManager implementor
faces if she strives for total compatibility. Hopefully in the future I'll
be able to re-enable the compatibility...
Best regards,
Pablo
BTW, how do you handle breaking into the ongoing PPP session on a 1-port
modem and hanging up the connection? +++ATH? Or AT D1, setting the
serial port's DTR to off and then ATH?
Dan
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Please, document byte order in org.freedesktop.NetworkManager.IP4Config
2009/10/22 Andrey Batyiev baty...@gmail.com
Hello everyone
Am I right, that every IP address in
org.freedesktop.NetworkManager.IP4Config
is in network byte order? Could you explicitly document this behaviour,
please?
implementation in Python:
import sockket
def convert_ip_to_int(ip):
Converts ``ip`` to its integer representation
:param ip: The IP to convert
:type ip: str
:rtype: int
i = struct.unpack('i', socket.inet_pton(socket.AF_INET, ip))[0]
if i 0:
i += 0x + 1
return i
Thanks,
Andrey
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Please, document byte order in org.freedesktop.NetworkManager.IP4Config
2009/10/22 Pablo Martí Gamboa pma...@warp.es
2009/10/22 Andrey Batyiev baty...@gmail.com
Hello everyone
Am I right, that every IP address in
org.freedesktop.NetworkManager.IP4Config
is in network byte order? Could you explicitly document this behaviour,
please?
implementation in Python:
import sockket
def convert_ip_to_int(ip):
Converts ``ip`` to its integer representation
:param ip: The IP to convert
:type ip: str
:rtype: int
i = struct.unpack('i', socket.inet_pton(socket.AF_INET, ip))[0]
if i 0:
i += 0x + 1
return i
Oops, too quick... it should be import socket :P
Thanks,
Andrey
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem with Simple.Connect
2009/10/13 Dan Williams d...@redhat.com
On Fri, 2009-10-09 at 10:00 +0200, Pablo Martí Gamboa wrote:
The puzzling thing is that the very first time it will connect no
problem, it is the second and third attempts that fail. Nothing in the
wader log indicates that there's been a problem (the log trace of a
successful and unsuccessful attempts are exactly similar). So perhaps
there is a problem with that ppp timeout?
Is not like Simple.Connect is complicated right, it is basically the
old connect beefed up. And the old connect reliability was way better
(i.e. several connection attempts in a row no problem)
Is there anything else I can do to help you figure out this one?
I'd hazard a guess that we're not disconnecting or hanging up the
previous connection correctly somewhere. Disable implies disconnect of
course, so any Enable(False) handler should also be ensuring clean
disconnection.
Can you run NM with:
NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon
and lets see what comes out? That will provide the PPP spew which could
help us get closer.
Attached you can find success1.log and error2.log, the first attempt succeed
and the second failed.
I've tried with:
* plain '+++ATH\r'
* lower raise DTR
* lower raise DTR + 'ATH\r'
And the outcome was the same
Regards,
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
success1.log.gz
Description: GNU Zip compressed data
error2.log.gz
Description: GNU Zip compressed data
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem with Simple.Connect
2009/10/14 Pablo Martí Gamboa pma...@warp.es
2009/10/13 Dan Williams d...@redhat.com
On Fri, 2009-10-09 at 10:00 +0200, Pablo Martí Gamboa wrote:
The puzzling thing is that the very first time it will connect no
problem, it is the second and third attempts that fail. Nothing in the
wader log indicates that there's been a problem (the log trace of a
successful and unsuccessful attempts are exactly similar). So perhaps
there is a problem with that ppp timeout?
Is not like Simple.Connect is complicated right, it is basically the
old connect beefed up. And the old connect reliability was way better
(i.e. several connection attempts in a row no problem)
Is there anything else I can do to help you figure out this one?
I'd hazard a guess that we're not disconnecting or hanging up the
previous connection correctly somewhere. Disable implies disconnect of
course, so any Enable(False) handler should also be ensuring clean
disconnection.
Can you run NM with:
NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon
and lets see what comes out? That will provide the PPP spew which could
help us get closer.
Attached you can find success1.log and error2.log, the first attempt
succeed and the second failed.
I've tried with:
* plain '+++ATH\r'
* lower raise DTR
* lower raise DTR + 'ATH\r'
Turns out that ModemManager actually uses a fourth one:
* Set baudrate temporally to 0 and restore speed in some milliseconds
I tried this attempt with the same results (see attached files)
And the outcome was the same
Regards,
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
success2.log.gz
Description: GNU Zip compressed data
error3.log.gz
Description: GNU Zip compressed data
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem with Simple.Connect
2009/10/9 Dan Williams d...@redhat.com
On Thu, 2009-10-08 at 09:02 +0200, Pablo Martí Gamboa wrote:
2009/10/7 Dan Williams d...@redhat.com
On Tue, 2009-10-06 at 12:43 +0200, Pablo Martí Gamboa wrote:
Hi all,
I'm getting a unreliable behavior with Simple.Connect, the
first call
will succeed, but further calls won't.
Going through the logs with Tambet, we have noticed that
there is
something weird going on with IPv6 code:
I think that's mostly unrelated; NM will not finish the
connection until
both IP4 and IP6 have completed, but of course in your case
you don't
have IP6 configured since this is a mobile broadband
connection, so that
stage is just a null-op. The real problem seems to be:
Oct 6 10:27:04 lenovo NetworkManager: WARN
pppd_timed_out(): Looks
like pppd didn't initialize our dbus module
which indicates that PPP did not successfully complete, or
that the NM
pppd plugin could not push the IP4 config information back to
NetworkManager. Can you run NM like so:
NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon
see successful.log and error.log (first and second attempts
respectively)
and then reproduce the issue? That should show a lot more log
output
(including pppd's stdout debugging info) that will allow us to
figure
out what's going on here.
Also, did this just start happening, or has this been around
for a bit?
Or did you just install something new?
I forgot to mention that this with NetworkManager + Wader rather than
NM + MM. I'm testing the integration of both packages before
(hopefully) the release of Ubuntu 9.10 final. I hadn't tested
Simple.Connect in a while.
That logfile indicates that PPP isn't able to establish a session within
the timeout. NM times PPP out after 20 seconds, which is a pretty long
time to give PPP. I've actually never seen PPP take more than about 5
or 10 seconds to connect, even in marginal situations on any of my 25 or
so devices.
The puzzling thing is that the very first time it will connect no problem,
it is the second and third attempts that fail. Nothing in the wader log
indicates that there's been a problem (the log trace of a successful and
unsuccessful attempts are exactly similar). So perhaps there is a problem
with that ppp timeout?
Is not like Simple.Connect is complicated right, it is basically the old
connect beefed up. And the old connect reliability was way better (i.e.
several connection attempts in a row no problem)
Is there anything else I can do to help you figure out this one?
Regards,
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem with Simple.Connect
2009/10/9 Dan Williams d...@redhat.com
On Thu, 2009-10-08 at 10:33 +0200, Pablo Martí Gamboa wrote:
2009/10/8 Pablo Martí Gamboa pma...@warp.es
2009/10/7 Dan Williams d...@redhat.com
On Tue, 2009-10-06 at 12:43 +0200, Pablo Martí Gamboa
wrote:
Hi all,
I'm getting a unreliable behavior with
Simple.Connect, the first call
will succeed, but further calls won't.
Going through the logs with Tambet, we have noticed
that there is
something weird going on with IPv6 code:
I think that's mostly unrelated; NM will not finish
the connection until
both IP4 and IP6 have completed, but of course in your
case you don't
have IP6 configured since this is a mobile broadband
connection, so that
stage is just a null-op. The real problem seems to
be:
Oct 6 10:27:04 lenovo NetworkManager: WARN
pppd_timed_out(): Looks
like pppd didn't initialize our dbus module
which indicates that PPP did not successfully
complete, or that the NM
pppd plugin could not push the IP4 config information
back to
NetworkManager. Can you run NM like so:
NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon
see successful.log and error.log (first and second attempts
respectively)
and then reproduce the issue? That should show a lot
more log output
(including pppd's stdout debugging info) that will
allow us to figure
out what's going on here.
Also, did this just start happening, or has this been
around for a bit?
Or did you just install something new?
I forgot to mention that this with NetworkManager + Wader
rather than NM + MM. I'm testing the integration of both
packages before (hopefully) the release of Ubuntu 9.10 final.
I hadn't tested Simple.Connect in a while.
I forgot to mention that when I press Disconnect from nm-applet,
that just issues an Enable(false) to the device rather than
Disconnect(); Enable(false);, I asked yesterday in #nm and nobody
seemed to recall why that decision had been made, they just remembered
that it was more reliable for a particular device. In my case it is
the other way around! will nm0.8 ship like this?
Right now NM doesn't call disconnect at all, AFAIK. It just calls
Enable(false). We assume that also cleans up the connection and
disables the modem, since disabling the modem implies the connection is
torn down. Is that not working?
That has caused some unreliability problems with HSO devices for us. I've
added a small guard that before disabling a device will disconnect it if its
connected and will carry on disabling it. This has improved the reliability
and can connect with hso devices several times in a row.
BTW, how do you handle breaking into the ongoing PPP session on a 1-port
modem and hanging up the connection? +++ATH? Or AT D1, setting the
serial port's DTR to off and then ATH?
We were using the DTR approach (without ATH), and that was working nicely
for us (NM 0.7.1), then when we switched to NM 0.8 and faced all this
Simple.Connect problems I tried switching to +++ATH, but it hasn't improved
anything...
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem with Simple.Connect
2009/10/7 Dan Williams d...@redhat.com
On Tue, 2009-10-06 at 12:43 +0200, Pablo Martí Gamboa wrote:
Hi all,
I'm getting a unreliable behavior with Simple.Connect, the first call
will succeed, but further calls won't.
Going through the logs with Tambet, we have noticed that there is
something weird going on with IPv6 code:
I think that's mostly unrelated; NM will not finish the connection until
both IP4 and IP6 have completed, but of course in your case you don't
have IP6 configured since this is a mobile broadband connection, so that
stage is just a null-op. The real problem seems to be:
Oct 6 10:27:04 lenovo NetworkManager: WARN pppd_timed_out(): Looks
like pppd didn't initialize our dbus module
which indicates that PPP did not successfully complete, or that the NM
pppd plugin could not push the IP4 config information back to
NetworkManager. Can you run NM like so:
NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon
see successful.log and error.log (first and second attempts respectively)
and then reproduce the issue? That should show a lot more log output
(including pppd's stdout debugging info) that will allow us to figure
out what's going on here.
Also, did this just start happening, or has this been around for a bit?
Or did you just install something new?
I forgot to mention that this with NetworkManager + Wader rather than NM +
MM. I'm testing the integration of both packages before (hopefully) the
release of Ubuntu 9.10 final. I hadn't tested Simple.Connect in a while.
Thanks a lot for your time and help!!
Pablo
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
NetworkManager: info Activation (ttyUSB0) starting connection 'Vodafone'
NetworkManager: info (ttyUSB0): device state change: 3 - 4 (reason 0)
NetworkManager: info Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) scheduled...
NetworkManager: info Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) started...
NetworkManager: info (ttyUSB0): device state change: 4 - 6 (reason 0)
NetworkManager: info Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) complete.
NetworkManager: info Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) scheduled...
NetworkManager: info Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) started...
NetworkManager: info (ttyUSB0): device state change: 6 - 4 (reason 0)
NetworkManager: info Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) complete.
NetworkManager: info Activation (ttyUSB0) Stage 2 of 5 (Device Configure) scheduled...
NetworkManager: info Activation (ttyUSB0) Stage 2 of 5 (Device Configure) starting...
NetworkManager: info (ttyUSB0): device state change: 4 - 5 (reason 0)
NetworkManager: info Activation (ttyUSB0) Stage 2 of 5 (Device Configure) successful.
NetworkManager: info Activation (ttyUSB0) Stage 3 of 5 (IP Configure Start) scheduled.
NetworkManager: info Activation (ttyUSB0) Stage 2 of 5 (Device Configure) complete.
NetworkManager: info Activation (ttyUSB0) Stage 3 of 5 (IP Configure Start) started...
NetworkManager: info (ttyUSB0): device state change: 5 - 7 (reason 0)
NetworkManager: info Starting pppd connection
NetworkManager: debug [1254985070.460266] nm_ppp_manager_start(): Command line: /usr/sbin/pppd nodetach lock nodefaultroute debug user vodafone ttyUSB0 noipdefault noauth usepeerdns lcp-echo-failure 0 lcp-echo-interval 0 ipparam /org/freedesktop/NetworkManager/PPP/2 plugin /usr/lib/pppd/2.4.4/nm-pppd-plugin.so
Plugin /usr/lib/pppd/2.4.4/nm-pppd-plugin.so loaded.
** Message: nm-ppp-plugin: (plugin_init): initializing
NetworkManager: debug [1254985070.468209] nm_ppp_manager_start(): ppp started with pid 3471
NetworkManager: info Activation (ttyUSB0) Stage 4 of 5 (IP6 Configure Get) scheduled...
NetworkManager: info Activation (ttyUSB0) Stage 3 of 5 (IP Configure Start) complete.
NetworkManager: info Activation (ttyUSB0) Stage 4 of 5 (IP6 Configure Get) started...
NetworkManager: info Activation (ttyUSB0) Stage 4 of 5 (IP6 Configure Get) complete.
** Message: nm-ppp-plugin: (nm_phasechange): status 3 / phase 'serial connection'
NetworkManager: WARN pppd_timed_out(): Looks like pppd didn't initialize our dbus module
NetworkManager: info (ttyUSB0): device state change: 7 - 9 (reason 14)
NetworkManager: info Marking connection 'Vodafone' invalid.
NetworkManager: Tried to set deprecated property gsm/puk
NetworkManager: info Activation (ttyUSB0) failed.
NetworkManager: info (ttyUSB0): device state change: 9 - 3 (reason 0)
NetworkManager: info (ttyUSB0): deactivating device (reason: 0).
NetworkManager: flush_routes: assertion `iface_idx = 0' failed
NetworkManager: flush_addresses: assertion `iface_idx = 0' failed
NetworkManager: info Policy set 'Auto eth0' (eth0) as default for routing and DNS.
NetworkManager: debug [1254985093.001338] ensure_killed(): waiting for ppp pid 3471 to exit
NetworkManager: info Activation (ttyUSB0
Re: Problem with Simple.Connect
2009/10/8 Pablo Martí Gamboa pma...@warp.es
2009/10/7 Dan Williams d...@redhat.com
On Tue, 2009-10-06 at 12:43 +0200, Pablo Martí Gamboa wrote:
Hi all,
I'm getting a unreliable behavior with Simple.Connect, the first call
will succeed, but further calls won't.
Going through the logs with Tambet, we have noticed that there is
something weird going on with IPv6 code:
I think that's mostly unrelated; NM will not finish the connection until
both IP4 and IP6 have completed, but of course in your case you don't
have IP6 configured since this is a mobile broadband connection, so that
stage is just a null-op. The real problem seems to be:
Oct 6 10:27:04 lenovo NetworkManager: WARN pppd_timed_out(): Looks
like pppd didn't initialize our dbus module
which indicates that PPP did not successfully complete, or that the NM
pppd plugin could not push the IP4 config information back to
NetworkManager. Can you run NM like so:
NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon
see successful.log and error.log (first and second attempts respectively)
and then reproduce the issue? That should show a lot more log output
(including pppd's stdout debugging info) that will allow us to figure
out what's going on here.
Also, did this just start happening, or has this been around for a bit?
Or did you just install something new?
I forgot to mention that this with NetworkManager + Wader rather than NM +
MM. I'm testing the integration of both packages before (hopefully) the
release of Ubuntu 9.10 final. I hadn't tested Simple.Connect in a while.
I forgot to mention that when I press Disconnect from nm-applet, that just
issues an Enable(false) to the device rather than Disconnect();
Enable(false);, I asked yesterday in #nm and nobody seemed to recall why
that decision had been made, they just remembered that it was more reliable
for a particular device. In my case it is the other way around! will nm0.8
ship like this?
Thanks a lot for your time and help!!
Pablo
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [Patch] Export NM version over dbus
2009/9/14 Tambet Ingo tam...@gmail.com
Hey,
Attached patch exports the NetworkManager version over DBus.
Currently, it's probably mostly needed to determine whether the NM
daemon is 0.7 or 0.8, so if this new property isn't implemented, it's
0.8.
Is this going to be added ? It would be *really* interesting for projects,
like Wader, that strive to be compatible with NM 0.6 - 0.8. Right now we are
using hacks to identify the version around. i.e. getDevices vs GetDevices
(0.6 / 0.7+) and GetDevices return value (0.7. returns HAL udi, 0.8+ returns
NM-created object path)
Regards,
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Small typo
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
From 8ac84955c27217364f6111e8d6aef346f21cdf8b Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Pablo=20Mart=C3=AD?= pma...@warp.es
Date: Tue, 2 Jun 2009 14:32:17 +0200
Subject: [PATCH] Fix typo
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Pablo Martí pma...@warp.es
---
libnm-util/nm-setting.c |2 +-
system-settings/plugins/keyfile/io/reader.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libnm-util/nm-setting.c b/libnm-util/nm-setting.c
index 49f88e1..f9e9f19 100644
--- a/libnm-util/nm-setting.c
+++ b/libnm-util/nm-setting.c
@@ -176,7 +176,7 @@ one_property_cb (gpointer key, gpointer val, gpointer user_data)
param_spec = g_object_class_find_property (info-class, prop_name);
if (!param_spec || !(param_spec-flags NM_SETTING_PARAM_SERIALIZE)) {
/* Oh, we're so nice and only warn, maybe it should be a fatal error? */
- nm_warning (Ignorning invalid property '%s', prop_name);
+ nm_warning (Ignoring invalid property '%s', prop_name);
return;
}
diff --git a/system-settings/plugins/keyfile/io/reader.c b/system-settings/plugins/keyfile/io/reader.c
index e7f360d..13c4b12 100644
--- a/system-settings/plugins/keyfile/io/reader.c
+++ b/system-settings/plugins/keyfile/io/reader.c
@@ -643,7 +643,7 @@ connection_from_file (const char *filename)
bad_permissions = statbuf.st_mode 0077;
if (bad_owner || bad_permissions) {
- g_warning (Ignorning insecure configuration file '%s', filename);
+ g_warning (Ignoring insecure configuration file '%s', filename);
return NULL;
}
--
1.6.0.4
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Bug in src/nm-gsm-device.c
2009/5/21 Dan Williams d...@redhat.com
On Wed, 2009-05-20 at 10:23 +0200, Pablo Martí Gamboa wrote:
Hi all,
I've just been bitten by a small bug in src/nm-gsm-device.c +443:
const char *responses[] = { +CREG: 0,0, +CREG: 0,1, +CREG: 0,2,
+CREG: 0,3, +CREG: 0,5, NULL };
If an external implementation has send '+CREG=1' those terminators
won't work. I think that you should just check the last part of the
+CREG response.
What would the response terminator look like in that case? Not quite
sure I follow.
Something along the lines of what is done in ModemManager:
if (g_str_has_prefix (response-str, +CREG: )) {
int unsolicited, stat;
sscanf (response-str + 7, %d,%d, unsolicited, stat);
switch(stat) {
case 5: break;
case 4: break;
}
}
Regards,
Pablo
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Bug in src/nm-gsm-device.c
2009/5/21 Dan Williams d...@redhat.com
On Thu, 2009-05-21 at 09:15 +0200, Pablo Martí Gamboa wrote:
2009/5/21 Dan Williams d...@redhat.com
On Wed, 2009-05-20 at 10:23 +0200, Pablo Martí Gamboa wrote:
Hi all,
I've just been bitten by a small bug in src/nm-gsm-device.c
+443:
const char *responses[] = { +CREG: 0,0, +CREG: 0,1,
+CREG: 0,2,
+CREG: 0,3, +CREG: 0,5, NULL };
If an external implementation has send '+CREG=1' those
terminators
won't work. I think that you should just check the last part
of the
+CREG response.
What would the response terminator look like in that case?
Not quite
sure I follow.
Something along the lines of what is done in ModemManager:
if (g_str_has_prefix (response-str, +CREG: )) {
int unsolicited, stat;
sscanf (response-str + 7, %d,%d, unsolicited, stat);
switch(stat) {
case 5: break;
case 4: break;
}
}
Right, but I meant what is the exact response that's screwing up NM here
on 0.7 branch? In 0.7 we do need to match the full response, otherwise
we might match some other unsolicited response the modem sends, instead
of CREG.
It does not recognizes responses like +CREG: 1,1. For now my workaround has
been to disable +CREG notifications right before connecting via NM DBus[0],
otherwise it won't work.
AFAICT this wasn't present in the NM shipped with Fedora 10, OpenSUSE 11.1
or Ubuntu 8.10.
[0]
http://public.warp.es/wader/browser/node/core/trunk/wader/common/dialers/nm_pppd.py#L84
Dan
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Bug in src/nm-gsm-device.c
Hi all,
I've just been bitten by a small bug in src/nm-gsm-device.c +443:
const char *responses[] = { +CREG: 0,0, +CREG: 0,1, +CREG: 0,2,
+CREG: 0,3, +CREG: 0,5, NULL };
If an external implementation has send '+CREG=1' those terminators won't
work. I think that you should just check the last part of the +CREG
response.
Tambet said that this file is no longer present in trunk, although I'm
following fdo's git and its indeed there, wtf?
Best regards,
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Moving ppp-manager into ModemManager
2009/5/8 Marcel Holtmann mar...@holtmann.org
Hi guys,
what do you guys think about moving the ppp-manager part from
NetworkManager into ModemManager?
What is the actual reason why ModemManager doesn't handle the PPP part
of a data connection?
Because NetworkManager also happens to support pppoe and friends
Regards
Marcel
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Diskless clients and NetworkManager
On Thursday 30 April 2009, Pablo Martí Gamboa wrote:
2009/4/30 Dan Williams d...@redhat.com
On Thu, 2009-04-30 at 14:06 +0100, Marc Herbert wrote:
David Sundqvist a écrit :
If I set it to be managed by NM, will NM try to manage it in any
way?
Can I set it to be seen, but still unmanaged? Or maybe I could
get NM
to always output a connected status instead of a no-connection
which
triggers firefox offline mode, etc. (should the connection be
lost,
well, then NM won't be able to detect it anyway due to being
frozen
on the first page touch).
There seems to be something fundamentally wrong in this
no-connection/
/offline thing. Since NM can be configured to manage _not all_
interfaces (including none at all) then why are some applications
wrongly assuming NM is always managing the entire network
configuration? This seems to be where the bug lies and should be
fixed.
Its mostly a distro problem; if NM is not managing your default
internet
connection, then you should probably turn NM off when setting up the
machine.
Unfortunately, in today's Linux Desktop this will yield some main
application unusable, they all rely on the NetworkManager interface for
connectivity status. For projects that provide connectivity (ConnMan,
Wader, VMC, K-MobileTools, gnome-ppp, etc.) is a frustrating situation.
Even thou NetworkManager is the de-facto standard tool for managing
connectivity, NetworkManager won't always be the solution for everyone.
Say
you have a token ring connection, NetworkManager doesn't have plans to
support it. Say you provide dial up capabilities, like VMC, Wader, etc.
It
ain't gonna be nice, users have connectivity but applications are not
aware. There are workarounds for applications like Firefox, but it is
not
something that a noob user will understand or do. For other apps like
pidgin, there's no workaround AFAIK. Perhaps Moblin has patched
Firefox,
pidgin, etc. to listen for ConnMan's signals, but this is only possible
on
the OEM/distro level - i.e. I'm not gonna ship a patched
firefox/pidgin/foo
that listens for Wader's signals in my ppa/buildservice, it ain't gonna
scale.
It is gonna be a though process, but we need to engage all the
interested
parties on a discussion about how to make applications aware of
connectivity changes and come up with a DBus interface that several
applications can provide.
I have already expressed this concerns to Dan Williams, and I think
that
@asac thinks something similar.
What do you guys think?
The only way you can make intelligent decisions about the network
state
on the machine is to make those decisions with *all* the necessary
information, and that means letting NetworkManager control all your
network connections.
There are situations in which NM is not appropriate at this time, and
those are mostly situations where the primary network connection
cannot
be controlled by NM for some reason. Thankfully, there are not too
many
of those. Network-mounted-/usr is one of those cases, as are cases
where the root device is network-mounted, or where the interface
cannot
be touched after exiting the initrd. For now, I'd suggest using the
static config scripts.
A bullet-point on my feature list is to handle this case specifically
for wired non-802.1x connections, because all other types require too
much state to just be taken over post-initrd.
Dan
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Diskless clients and NetworkManager
2009/4/30 Marc Herbert marc.herb...@gmail.com
David Sundqvist a écrit :
If I set it to be managed by NM, will NM try to manage it in any way?
Can I set it to be seen, but still unmanaged? Or maybe I could get NM
to always output a connected status instead of a no-connection which
triggers firefox offline mode, etc. (should the connection be lost,
well, then NM won't be able to detect it anyway due to being frozen on
the first page touch).
There seems to be something fundamentally wrong in this no-connection/
/offline thing. Since NM can be configured to manage _not all_
interfaces (including none at all) then why are some applications
wrongly assuming NM is always managing the entire network
configuration? This seems to be where the bug lies and should be
fixed.
Is there other buggy applications that people should be afraid of
besides firefox?
Firefox, pidgin, gajim, epiphany-browser, synapse, etc. quite a few of them
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Diskless clients and NetworkManager
2009/4/30 Dan Williams d...@redhat.com
On Thu, 2009-04-30 at 14:06 +0100, Marc Herbert wrote:
David Sundqvist a écrit :
If I set it to be managed by NM, will NM try to manage it in any way?
Can I set it to be seen, but still unmanaged? Or maybe I could get NM
to always output a connected status instead of a no-connection which
triggers firefox offline mode, etc. (should the connection be lost,
well, then NM won't be able to detect it anyway due to being frozen on
the first page touch).
There seems to be something fundamentally wrong in this no-connection/
/offline thing. Since NM can be configured to manage _not all_
interfaces (including none at all) then why are some applications
wrongly assuming NM is always managing the entire network
configuration? This seems to be where the bug lies and should be
fixed.
Its mostly a distro problem; if NM is not managing your default internet
connection, then you should probably turn NM off when setting up the
machine.
Unfortunately, in today's Linux Desktop this will yield some main
application unusable, they all rely on the NetworkManager interface for
connectivity status. For projects that provide connectivity (ConnMan, Wader,
VMC, K-MobileTools, gnome-ppp, etc.) is a frustrating situation.
Even thou NetworkManager is the de-facto standard tool for managing
connectivity, NetworkManager won't always be the solution for everyone. Say
you have a token ring connection, NetworkManager doesn't have plans to
support it. Say you provide dial up capabilities, like VMC, Wader, etc. It
ain't gonna be nice, users have connectivity but applications are not aware.
There are workarounds for applications like Firefox, but it is not something
that a noob user will understand or do. For other apps like pidgin, there's
no workaround AFAIK. Perhaps Moblin has patched Firefox, pidgin, etc. to
listen for ConnMan's signals, but this is only possible on the OEM/distro
level - i.e. I'm not gonna ship a patched firefox/pidgin/foo that listens
for Wader's signals in my ppa/buildservice, it ain't gonna scale.
It is gonna be a though process, but we need to engage all the interested
parties on a discussion about how to make applications aware of connectivity
changes and come up with a DBus interface that several applications can
provide.
I have already expressed this concerns to Dan Williams, and I think that
@asac thinks something similar.
What do you guys think?
The only way you can make intelligent decisions about the network state
on the machine is to make those decisions with *all* the necessary
information, and that means letting NetworkManager control all your
network connections.
There are situations in which NM is not appropriate at this time, and
those are mostly situations where the primary network connection cannot
be controlled by NM for some reason. Thankfully, there are not too many
of those. Network-mounted-/usr is one of those cases, as are cases
where the root device is network-mounted, or where the interface cannot
be touched after exiting the initrd. For now, I'd suggest using the
static config scripts.
A bullet-point on my feature list is to handle this case specifically
for wired non-802.1x connections, because all other types require too
much state to just be taken over post-initrd.
Dan
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: APN list: adding mcc mnc
2009/4/14 Martijn Cox (LiveContacts) m@livecontacts.com
Hello all,
I’ve sent the following email to Wellark, the maintainer of the Mobile
Broadband Provider Info project, a few weeks ago, outlining a way to include
mobile country codes and mobile network codes in the MBPI project. In the
meantime, we’ve already implemented this scheme in our company, and have
successfully used it to extract the APN’s for two providers in one country.
Would you be interested in using this scheme?
Hi Martijn,
as the lead developer of the Wader project I would be quite interested in
this new addition, its the only reason that refrained us from using mbcm.
Regards,
Pablo
As Wellark has been very busy, he has asked me to forward this message to
both the NetworkManager and the Wader Development mailing list, as he
suspects there is additional interest these development groups in adding
country code and network codes to the MBPI project. Note that I currently
have no idea what the NetworkManager and Wader development groups are, as
this is not within the scope of my current job-assignment.
Regards, Martijn.
*From:* Martijn Cox
*Sent:* woensdag 1 april 2009 13:00
*To:* 'an...@kaijanmaki.net'
*Subject:* apn list, adding mcc mnc
Hi Wellark,
I’m a developer for (amongst others), the blackberry platform. I’ve come
across your project, and wish to contribute by adding the mobile country
code and mobile network code to the xml file, based on the Wikipedia list @
http://en.wikipedia.org/wiki/Mobile_Network_Code. Do you regard such an
endeavor as ok?
I would like to add them, according to the following DTD,
which is based on your supplied DTD, with additions in yellow:
!ELEMENT serviceproviders (country*)
!ATTLIST serviceproviders format CDATA #REQUIRED
!ELEMENT country (provider* ,mcc+)
!ATTLIST country code CDATA #REQUIRED
!ELEMENT provider ( mnc+,
name+,
(gsm|cdma),
username?,
password?,
dns*,
gateway?)
!ELEMENT name (#PCDATA)
!ATTLIST name xml:lang CDATA #IMPLIED
!ELEMENT gsm (apn)
!ELEMENT apn (#PCDATA)
!ELEMENT cdma EMPTY
!ELEMENT username (#PCDATA)
!ELEMENT password (#PCDATA)
!ELEMENT dns (#PCDATA)
!ELEMENT gateway (#PCDATA)
!ELEMENT mcc (#PCDATA)
!ELEMENT mnc (#PCDATA)
Do you think that would be ok? The reason for these additions is that it’s
easier to search this way when you have access to a provider id (mobile
network code), and mobile country code (i.s.o. the country identifier you
use, which is currently not available for me).
Regards,
Martijn Cox
Livecontacts B.V.
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM using Option card
On Feb 8, 2008 5:08 PM, [EMAIL PROTECTED] wrote:
On Fri, Feb 08, 2008 at 09:54:28AM -0500, Dan Williams wrote:
We've been talking to the VMC developers, who have added a D-Bus
interface to VMC. You're right, it's pointless to have many projects
duplicate the same quirks and workarounds for cards, and using some
existing tool is the way to go. Since VMC is adding the D-Bus
interface, Tambet and I thought that using VMC like we currently use
wpa_supplicant would be a good option.
Did you ever look at VMC? IMHO it is much too heavyweight to be a backend
for a system daemon like NM. And it supported almost no hardware the last
time i looked (a few weeks ago).
Hi :)
I'm a VMC developer so I have to say something here :)
This are the contents of the device plugins dir:
huawei_e172.py huawei_e220.py huawei_e270.py
huawei_e272.py huawei_e620.py huawei_e660a.py
huawei_e660.py huawei_e870.py novatel_ovation.py
novatel_u630.py novatel_u740.py novatel_xu870.py
option_colt.py option_etna.py option_globesurfericon.py
option_gtfusion.py option_gtfusionquadlite.py
option_gtm378.py option_gtmax36.py
option_nozomi.py sierrawireless_875.py
zte_mf620.py
Some of the plugins are fully tested by us (50%) and the rest
contributed by users, but work (some better than others) to some
extent. The number (22) aint that great when you compare it with, say,
gammu/gnokki's support of mobiles. But this 22 devices are pretty much
whats available right now in most EMEA shops.
Current VMC core is too heavyweight yes, we're working on that. Once
the refactoring is done, vmc-core will be a lean package that will
just depend on python, python-twisted-core and python-dbus. Stay tuned
:)
Regards,
--
Pablo Martí Gamboa
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
