Any chance you could grab modem-manager debug logs that show the problem?

http://live.gnome.org/NetworkManager/Debugging

under the "Debugging NetworkManager 0.8.x 3G connections" section.

It is already attached to the launchpad bug linked above. Please take a look there and tell me if it is incomplete.

I can confirm the existence of this issue. BTW, the direct liink to the requested debug log is: https://launchpadlibrarian.net/70903271/modemmanager_ericsson_bug.txt

Maybe the patch in https://bugs.launchpad.net/modemmanager/+bug/769497/comments/12 should be tested again.

Created attachment 192643 [details] [review]
Patch that seems to solve the problem

The attached patch seems to solve the problem for me.

Which file did you patched?

I would like to test it too, because i have the same issues.

It is in the attachment (file plugins/mm-modem-mbm.c):

diff --git a/plugins/mm-modem-mbm.c b/plugins/mm-modem-mbm.c
index 9303453..5ea340e 100644
--- a/plugins/mm-modem-mbm.c
+++ b/plugins/mm-modem-mbm.c
@@ -506,8 +506,6 @@ do_disconnect (MMGenericGsm *gsm,
     primary = mm_generic_gsm_get_at_port (gsm, MM_PORT_TYPE_PRIMARY);
     g_assert (primary);
     mm_at_serial_port_queue_command (primary, "*ENAP=0", 3, NULL, NULL);
-
-    MM_GENERIC_GSM_CLASS (mm_modem_mbm_parent_class)->do_disconnect (gsm, cid, callback, user_data);
 }

Please report back how your tests goes.

Mhm i cant find the /mm-modem-mbm.c on my system...

Well, it is source code, so you need to download modemmanager source code, patch it, build it, and then copy mm-modem-mbm.so to where it is on your system. Please see http://projects.gnome.org/NetworkManager/developers/

Now i have the sourcecode files here.

But only the raw src, without buildfiles :/ it is an opensuse 11.4 system..


I will have a look later...

See if you can get the source rpm and patch:

http://linuxmafia.com/pub/linux/suse-linux-internals/chapter34.html

Hmm, my 5521 doesn't have this behavior, but it also has an older firmware version than you do.  However, my part doesn't have the 3G frequencies for my provider, so would you mind forcing the modem to 2G and seeing if you still have the problem?

Dan: but does it have the same USB ID? There are different versions of this modem with different brandings. I have the Lenovo one.

Which behavior do you see? Does it use USB ethernet or PPP?

The USB IDs shouldn't matter; the firmware is largely the same and the hardware is almost exactly the same (F5521gw).  Just the USB IDs really differ.  It just happens that my firmware is older than yours, which could be the issue, or the 2G/3G thing.

Also, connections with MM will always use the USB Ethernet (usb_ncm) device instead of PPP unless for some reason the usb_ncm module is not available; if it's not available then it should really be added.

Dan: I was just unsure if you had the ENV{ID_MM_ERICSSON_MBM}="1" for your USB ID in the 77-mm-ericsson-mbm.rules for udev. It is required to see the problem, since it happens when mixing the Ericsson way (for using USB Ethernet connection) instead of the standard GSM way of connecting/disconnecting.

But yes, the firmware version could also make a difference. I haven't tried to upgrade mine. It is not even sure it is possible since I do not use the the modem in a Lenovo laptop so that the Windows driver refuses to install.

But what do you think about the patch? Will the modem be properly disconnected? Also see e-mail thread on the list with subject "No 3G after disconnecting".

So I magically happen to have *two* 5521gw devices, one with the older firmware, and one with R2A07.  And guess what?  I can reproduce this problem on the R2A07 device.

R2A07 appears to have a quirk that it resets serial port attributes like echo when a disconnect happens, *before* the CGACT=0,1 is sent.  You'll notice this in your logs at:

https://launchpadlibrarian.net/70805107/modemmanager_ericsson_bug.txt

at time 1304195480.635440.  Since modem was originally set up with ATE0 to disable command echo, and since the modem is now echoing commands back, this confuses ModemManager.  But it's not just the echo; other port attributes like &C are reset, and the modem ignores all commands on that port until it sends the "*EMRDY: 1" as well.  I can't figure out what's doing this, and I suspect the firmware difference is the key.  I've asked contacts at Ericsson about this issue.

So for the moment, the R2A07 firmware is misbehaving, but we can attempt to work around it by waiting for the EMRDY=1 and re-disabling echo on the port after disconnect.

Well, I also noticed the echo that was enabled again and thought that was the cause, but it did not help to stop it at disconnection (isn't there a patch for that on the LP bugreport?), so I concluded it is not confused of it.

The problem seems though solved by the patch attached here.

(In reply to comment #18)
> Well, I also noticed the echo that was enabled again and thought that was the
> cause, but it did not help to stop it at disconnection (isn't there a patch for
> that on the LP bugreport?)

Japp, see:

https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/769497/comments/12

(In reply to comment #18)
> The problem seems though solved by the patch attached here.

But how does the patch work for that other firmware? If they behave too different, we probably can make quirk for this specific firmware version (at least if it does not behave according to GSM standard).

But I supposed the Lenovo Windows driver were able to handle both, but maybe it uses PPP.

The patch from comment 19 would work fine with other firmware, but its still not the right fix.

What the issue actually turns out to be is that the F5521gw R2A07 firmware changed how it handles "flashing" the serial port.  "Flashing" is a technique from a long time back to drop the speed of the serial port for 0 baud for a short period of time, after which the firmware is supposed to return to command-mode if it was in data mode (ie, PPP).  MM does this in the generic case when disconnecting to ensure that if the modem only has one AT port, and that port is used for data/PPP, that it can return to command mode and terminate the connection cleanly.

Obviously the Ericsson devices don't need this, since they will always have at least one free AT command port that we can use to send the CGACT command to cleanly terminate the connection.  But since that code was in the generic path, it was executed for the Ericsson cards too.

The 5521 appears to change handling of "flashing" by resetting serial port attributes, perhaps because it assumes that the port was closed and re-opened, and you don't know what process reopened it.

So the real solution is to stop flashing serial ports for devices that don't need it (Ericsson, Option, some Icera-based devices, Sierra, etc).  The flash used to be harmless on previous Ericsson devices, but the R2A07 firmware on the 5521gw now breaks it.

So is the real solution easy to implement or should we add my fix as a quickfix in the mean time as this bug annoys me and a lot of other users right now?

Fixed by these commits; a very low-risk backport for all of them.

master:
d3c2228f7b55465f4433bedb36d47744b8d791f1
26debc1a9745ebc54d35569ba416a368f084a3f4
b9c2180886dc759403c837564cf39a4d030fea52

05:
714a68a8b3202aa28dfdc0b43175272e0ece622a
e218080f72e962ecccc7460e67d54475279e9789
506ebcc40bf625bb19298e0066eb4b33e0c08d59

Ericsson engineers confirmed in email that R2A07 includes a change that ties serial port DTR to port properties/state like echo and others.  When the DTR goes down the port properties/state are reset to power-on defaults.