Hi Aleksander,
The attached patch solved the problem. Thanks!
Cheers,
Tom
On 13/10/11 22:12, Aleksander Morgado wrote:
Hi,
So the real problem here is that the Cinterion modem sends a NUL byte
before the CONNECT response:
[mm-at-serial-port.c:298] debug_log(): (ttyS1): -- 'ATD*99***1#CR'
Patch is not compile tested as I lack some
dependencies to build NM on this box.
Signed-off-by: Thomas Jarosch thomas.jaro...@intra2net.com
---
src/nm-device-ethernet.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/src/nm-device-ethernet.c
Hi all,
The ObjectManager interface was recently added as a standard interface
in DBus:
http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-objectmanager
For the 0.6 API, we could be using this interface instead of the
proposed GetDevices() method, the Modems property and
Using the new object manager interfaces sounds great, would simplify the
code the connection manager and greatly reduce the number messages
associated with adding or removing a modem from the system. I agree that we
should use this in the 0.6 API.
-Jason
On Fri, Oct 14, 2011 at 8:59 AM,
On Thu, 2011-10-13 at 13:10 -0400, Dan Winship wrote:
the warnings were annoying me :)
It doesn't fix everything. These warnings:
nm-ip4-config.h:65: Warning: NMClient: Return value is not superclass
for constructor; symbol='nm_ip4_config_new'
constructed='NMClient.IP4Config'
On Fri, 2011-10-14 at 13:17 +0200, Thomas Jarosch wrote:
Patch is not compile tested as I lack some
dependencies to build NM on this box.
Signed-off-by: Thomas Jarosch thomas.jaro...@intra2net.com
---
src/nm-device-ethernet.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
On Thu, 2011-10-13 at 22:12 +0200, Aleksander Morgado wrote:
Hi,
So the real problem here is that the Cinterion modem sends a NUL byte
before the CONNECT response:
[mm-at-serial-port.c:298] debug_log(): (ttyS1): -- 'ATD*99***1#CR'
modem-manager[2621]: debug [1317807408.548825]
So the real problem here is that the Cinterion modem sends a NUL byte
before the CONNECT response:
[mm-at-serial-port.c:298] debug_log(): (ttyS1): -- 'ATD*99***1#CR'
modem-manager[2621]: debug [1317807408.548825]
[mm-at-serial-port.c:298] debug_log(): (ttyS1): -- '\0'
Hi Dan,
On 10/14/2011 05:14 PM, Dan Williams wrote:
--- a/src/nm-device-ethernet.c
+++ b/src/nm-device-ethernet.c
@@ -343,6 +343,7 @@ _update_s390_subchannels (NMDeviceEthernet *self)
while ((item = g_dir_read_name (dir))) {
char buf[50];
char *cdev_path;
+
On Fri, 2011-10-14 at 17:26 +0200, Thomas Jarosch wrote:
Hi Dan,
On 10/14/2011 05:14 PM, Dan Williams wrote:
--- a/src/nm-device-ethernet.c
+++ b/src/nm-device-ethernet.c
@@ -343,6 +343,7 @@ _update_s390_subchannels (NMDeviceEthernet *self)
while ((item = g_dir_read_name (dir))) {
Sounds good to me.
Eric
On Fri, Oct 14, 2011 at 11:16 AM, Dan Williams d...@redhat.com wrote:
On Fri, 2011-10-14 at 09:53 -0400, Jason Glasgow wrote:
Using the new object manager interfaces sounds great, would simplify
the code the connection manager and greatly reduce the number messages
On Thu, 2011-10-13 at 05:25 +0200, Anders Feder wrote:
My pleasure - if only getting rid of bugs was this easy in all
software...
Speaking of bugs, I have another open issue in Bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=659228
I've been told that autoconnect is not supported for
Den 14. okt. 2011 18:39, skrev Dan Williams:
On Thu, 2011-10-13 at 05:25 +0200, Anders Feder wrote:
My pleasure - if only getting rid of bugs was this easy in all
software...
Speaking of bugs, I have another open issue in Bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=659228
I've been
What is the current behaviour? On my system, the 3G connection does not
autoconnect even though autoconnect=true.
Anders Feder
On 14-10-2011 18:39, Dan Williams wrote:
On Thu, 2011-10-13 at 05:25 +0200, Anders Feder wrote:
My pleasure - if only getting rid of bugs was this easy in all
On Fri, 2011-10-14 at 19:18 +0200, Anders Feder wrote:
What is the current behaviour? On my system, the 3G connection does not
autoconnect even though autoconnect=true.
Correct, because modems are not auto-enabled. enabled == powered up.
The modem must be enabled before it will auto-connect
I see. Should I clear this change of behavior with someone if I would
like to implement it?
Also, where would the entry point be? Since the modem may or may not
need an unlock, perhaps there needs to be two:
When modem is discovered {
If (autoconnect == true) {
If (Unlock
16 matches
Mail list logo
