lp:modemmanager/0.5
- Get this branch:
- bzr branch lp:modemmanager/0.5
Branch merges
Related source package recipes
Branch information
Import details
This branch is an import of the HEAD branch of the Git repository at git://anongit.freedesktop.org/ModemManager/ModemManager,branch=MM_05.
Last successful import was .
Recent revisions
- 1004. By Dan Williams <email address hidden>
-
sierra: fix CSQ handling on APP1 port
The APP1 port doesn't always prefix its replies with <CR><LF> which
runs afoul of the built-in echo removal. Since Sierra modems are on
the whole well-behaved WRT echo removal, just disable it on the
secondary ports. Only changes behavior for PPP-based devices since
they are the only ones that use the APP1 ports. - 1003. By Dan Williams <email address hidden>
-
core: speed up QCDM probing a bit
The point of sending two "version info" commands was to ensure that
the terminating 0x7E of the first one was processed as a QCDM frame
boundary and that any random data in the buffer (like AT commands
from probing) got cleared out. The second command would always
get processed as a valid QCDM command if the device supported QCDM,
since there was no garbage before it.Instead of that dance, just prepend the version info message with
an extra 0x7E to ensure a clean QCDM frame which the device hopefully
responds to immediately. Second, actually process that response
instead of throwing it away. Should save about 3 seconds when
probing QCDM ports. - 1002. By Dan Williams <email address hidden>
-
sierra: use DHCP for the USB 305 (AT&T Lightning)
For some reason, my AT&T Lightning just doesn't work with static
IP (AT%IPDPADDR) any more. No traffic passes even though everything
is set up the way it was before. No idea what happened. Using
latest firmware 2.0.0.11.But what's interesting is on Windows the generic Sierra Watcher
app uses DHCP. But on Linux, when using AT%IPDPACT, DHCP doesn't
work. That's odd. But it turns out the modem supports the
"standard" Sierra proprietary AT!SCACT commands, and that
*does* make DHCP work. Crazy no? So since the Windows app
uses DHCP, it's likely that the non-DHCP case (AT%IPDPACT/AT%IPDPADDR)
either isn't well tested or isn't well supported. With that
in mind, let's just use DHCP for this device in Linux too. - 1001. By Dan Williams <email address hidden>
-
icera: allow implementors to supply custom call control commands
Some devices should use custom call control commands instead of
AT%IPDPACT. - 1000. By Dan Williams <email address hidden>
-
icera: handle additional IPv4 configuration options
Newer devices like the ZTE/Vodafone K3805-z have an enhanced
%IPDPADDR command that includes a netmask and gateway, and
these are necessary to configure the device since it uses /24
instead of a /32. Since the device is nice enough to tell
us that, we should probably use that information.Unfortunately the MM API doens't expose the netmask and gateway
yet, so we'll have to add a GetIP4ConfigEx() method or something
like that, but this commit sets us up to do that. - 999. By Dan Williams <email address hidden>
-
zte: handle Icera-based devics that use DHCP
Since we can't autodetect that the devices use DHCP, we'll need to
tag them with udev rules for the time being. - 998. By Dan Williams <email address hidden>
-
gsm: if the generic CNMI request fails, try a Qualcomm-compatible one
Many devices based on Qualcomm chipsets don't support a <ds> value
of '1', despite saying they do in the AT+CNMI=? response. But they
do accept '2'. Since we're not doing much with delivery status
reports yet, if we get a CME 303 (not supported) error when setting
the message indication parameters via CNMI, fall back to the
Qualcomm-compatible CNMI parameters.If we don't do this, we don't get SMS indications on these devices,
because the original CNMI failed.Tested on Huawei E1550, Huawei E160G, ZTE MF622, and Novatel XU870.
Branch metadata
- Branch format:
- Branch format 7
- Repository format:
- Bazaar repository format 2a (needs bzr 1.16 or later)
