Re: [MM] Problem Huawei E303

Hoola Jose María :)

I have downloaded and installed the last ModemManager version from the
Git repository. I also have installed the NetworkManager packages by
Aleksander to integrate MM with gnome3 in fedora18:

Everything seems to work fine with some modems like Sierra 307U and
310U. I can use mmcli to unlock the SIM and enable the modem, the
integration with nm-applet also works perfectly.

Good to know!

But with the Huawei e303 I have problems. The mmcli commands work, but
there seem to be a problem in the integration with pppd.
As far as i know the pppd daemon gets the ttyUSB port to connect to
from the D-Bus interface 'org.freedesktop.ModemManager1.Modem and
property 'PrimaryPort'.

No; in the new interface the port to use as data port in pppd is
gathered from the "Bearer" interface; see:

You can gather that info, once connected, with "mmcli -b 0" assuming you
only have one bearer.

This PrimaryPort is defined in the MM sourcecode in the file
src/mm-iface-modem.c, and it seems that in this case it is given the
wrong port???

From the logs I can see the following lines with identify the data and
at port:
Feb 19 12:59:35 jmgonzalezcFedora ModemManager[7373]: <debug>
[1361278775.691035] [mm-base-modem.c:834] log_port():
(/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3) tty/ttyUSB2 at
Feb 19 12:59:35 jmgonzalezcFedora ModemManager[7373]: <debug>
[1361278775.691286] [mm-base-modem.c:834] log_port():
(/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3) tty/ttyUSB0 data

It is supposed that the pppd connection should be done through the
data port. I can see that the ATD call command is sent over the DATA
port, but the pppd daemon tries to establish the connection through the
AT port because that is the port returned by D-Bus in the PrimaryPort

The Primary port in the Modem interface was *exclusively* given so that
we could match modems with bluetooth devices in NetworkManager, IIRC.

I fixed quite some things since I created those packages, so let me
re-create whole new ones with the latest stuff. As said, the port to be
used as data port by pppd is the one given in the Bearer interface.

In order to try to fix this particular problem I created this simple
--- a/src/mm-iface-modem.c
+++ b/src/mm-iface-modem.c
@@ -3704,12 +3704,14 @@ interface_initialization_step
(InitializationContext *ctx)

 #if defined WITH_QMI
             primary = MM_PORT (mm_base_modem_peek_port_qmi
(MM_BASE_MODEM (ctx->self)));
-            if (!primary)
-                primary = MM_PORT (mm_base_modem_peek_port_primary
(MM_BASE_MODEM (ctx->self)));
+            if (!primary){
+                primary = MM_PORT (mm_base_modem_peek_best_data_port
(MM_BASE_MODEM (ctx->self)));
+           }
-            primary = MM_PORT (mm_base_modem_peek_port_primary
(MM_BASE_MODEM (ctx->self)));
+            primary = MM_PORT (mm_base_modem_peek_best_data_port
(MM_BASE_MODEM (ctx->self)));

Which seems to solve the problem with no undesired effects...., but I
suppose that this can break the MM for another modem.

I also have been forced to remove the NDIS connection from the Huawei
--- a/plugins/huawei/mm-plugin-huawei.c
+++ b/plugins/huawei/mm-plugin-huawei.c
@@ -492,7 +492,7 @@ grab_port (MMPlugin *self,
 mm_plugin_create (void)
-    static const gchar *subsystems[] = { "tty", "net", "usb", NULL };
+    static const gchar *subsystems[] = { "tty", "usb", NULL };
     static const guint16 vendor_ids[] = { 0x12d1, 0 };
     static const MMAsyncMethod custom_init = {

Beacuse sometimes (I don't no why only sometimes and not always) it
tries to establish the connection by NDIS, but this never works. This
modem is NDIS capable and it works in Windows, but it can only connect
in Linux with AT commands and pppd.

We actually fixed this in git master like... this morning. The generic
ATD-based connection logic will no longer expose a net port as being the
data port. When did you checkout the ModemManager repo? Can you retry
your tests with latest MM git master?

With these two patches the huawei e303 it is working properly.
Does anyone have the same problems?
Any idea about how to fix in a better way this connectivity problem?

Best regards,
José María.

BTW, if you want some real-time debugging, just invite me to lunch, I
live quite close to the Indra offices in Madrid, and I think I even have
some friends working there :)



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]