On Wed, 2013-04-03 at 19:37 +0200, Gerald Richter - ECOS wrote: > Hi, > > we have a similar case here (Also firmware version 2_*). We are investigating > at the moment. As soon as I have more information, we will try to create an > updated patch.
If there's any chance you can run the ENTERCND thing, then AT!CUSTOM to see if your MUXMODE has been modified, that would be great. I'm really poking around in the dark here, but it would be very, very nice to have a way of detecting this automatically rather than doing something like; strstr (info, "8790") && strstr (fwver, "2_") Dan > Gerald > > > > -----Ursprüngliche Nachricht----- > > Von: Aleksander Morgado [mailto:[email protected]] > > Gesendet: Mittwoch, 3. April 2013 19:00 > > An: Dan Williams > > Cc: Gerald Richter; Marius Kotsbak; Harald Jung; networkmanager- > > [email protected] > > Betreff: Re: AW: Problems with Sierra MC 8790 with older firmware revision > > > > On 03/04/2013 03:33 PM, Dan Williams wrote: > > > On Fri, 2013-03-01 at 15:08 +0100, Gerald Richter - ECOS wrote: > > >> The following patch solves the problem for us. It works with all > > >> revisions we have available for testing > > > > > > Pushed to git master and 0.6, thanks! > > > > > > Dan > > > > > >> Gerald > > >> > > >> --- mm-plugin-sierra.c~ 2012-08-29 17:02:18.000000000 +0200 > > >> +++ mm-plugin-sierra.c 2013-03-01 13:22:09.000000000 +0100 > > >> @@ -78,6 +78,9 @@ > > >> if (strstr (response, "C885")) > > >> g_object_set_data (G_OBJECT (task), > > >> TAG_SIERRA_APP_PPP_OK, GUINT_TO_POINTER (TRUE)); > > >> > > >> + if (strstr (response, "MC8790")) > > >> + g_object_set_data (G_OBJECT (task), > > >> + TAG_SIERRA_APP_PPP_OK, GUINT_TO_POINTER (TRUE)); > > >> + > > >> /* For debugging: let users figure out if their device supports > > >> it or not > > */ > > >> if (getenv ("MM_SIERRA_APP1_PPP_OK")) { > > >> mm_dbg ("Sierra: APP1 PPP OK '%s'", response); > > >> > > > > > > Ah, the fun... :) > > > > So I've got a MC8790 here which does *not* like the APP1 port for PPP. > > It has the following revision: > > 'K2_0_7_35AP C:/WS/FW/K2_0_7_35AP/MSM6290/SRC 2010/03/04 17:37:08' > > > > This is what we get from the probing: > > > > log_port(): (/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.7) > > tty/ttyUSB3 at (primary) > > log_port(): (/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.7) > > tty/ttyUSB4 data (primary) > > log_port(): (/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.7) > > tty/ttyUSB1 qcdm > > > > And it just stalls when we try to launch the ATD call in ttyUSB4: > > > > [1365007565.579948] [mm-broadband-bearer.c:200] > > common_get_at_data_port(): Connection through a plain serial AT port > > (ttyUSB4) > > [1365007565.579997] [mm-serial-port.c:958] mm_serial_port_open(): > > (ttyUSB4) device open count is 2 (open) > > [1365007565.580036] [mm-serial-port.c:1003] mm_serial_port_close(): > > (ttyUSB3) device open count is 1 (close) [1365007565.580080] [mm-at-serial- > > port.c:408] debug_log(): (ttyUSB4): > > --> 'ATD*99***2#<CR>' > > ... > > And that's it, won't reply. > > > > Running the ATD call in the primary ttyUSB3 port (without the patch > > above) kind of works; in that case ttyUSB4 is marked as secondary, but again > > ttyUSB4 doesn't know how to properly work not even as secondary and > > either reports error or times out most messages... > > > > Some additional info for Dan, surely not very useful :) > > > > AT!NVPORTSET? > > ERROR > > AT!MXPORTMAP? > > ERROR > > AT!NVMUXMODE? > > ERROR > > AT!NVMUXMODE=? > > ERROR > > AT!MAPUART=? > > ERROR > > AT!MAPUART? > > ERROR > > AT!NVPORTMAP? > > ERROR > > > > -- > > Aleksander > _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
