Age | Commit message (Collapse) | Author |
|
|
|
|
|
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.
|
|
Most Sierra PPP-based devices are supposed to allow PPP on the
APP1 port, which has a dumb AT parser, leaving the main port
(with the intelligent AT parser) free for status and signal strength.
But out of all the devices I've tested it with (8775, 8781, AC881,
and C885), only the C885 actually works. The rest (including three
different firmware versions for the 8775) either crash or disconnect
shortly after PPP starts.
To help figure out which devices actually support this, when
running MM in debug mode, users can set the MM_SIERRA_APP1_PPP_OK
environment variable and assume the APP1 port allows PPP. This
is only for debugging purposes.
|
|
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.
|
|
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.
|
|
Some devices should use custom call control commands instead of
AT%IPDPACT.
|
|
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.
|
|
Since we can't autodetect that the devices use DHCP, we'll need to
tag them with udev rules for the time being.
|
|
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.
|
|
Text was getting concatenated when reconstructing the full message,
but the data wasn't. That meant that non-text multipart messages,
like the binary APN/MMS settings messages that operators often send,
were broken.
|
|
Not all properties are strings, so when copying the GValue we
have to use the source GValue's type, not STRING.
|
|
|
|
Moto EZX devices prefix the response with +CIMI:, plus some Option
devices suffix it with ",XXXXX" where X is a firmware version or
something.
|
|
More fallout from b22b2d99db57e4cec8e6c3074dd20acd6845cb62
which changed the return type of the qcdm_result_get_*() functions.
|
|
In case the connect gets interrupted by a disconnect or something.
|
|
If a connect operation is attempted immediately after a disconnect,
it sometimes fails with CME error 583 - "a profile (CID) is currently
active". Apparently, even though the preceding operation (%IPDPACT)
to deactivate the PDP context returned an OK response, the context
is not really completely available until a fraction of a second
later. This causes the %IPDPCFG operation that is part of the
subsequent connect attempt to fail with error 583. This change
retries the %IPDPCFG after a one second delay.
BUG=chrome-os-partner:4936
TEST=This can be tested from the UI, but I found it easier to produce
the timing needed to trigger the bug by running mm-disconnect and
mm-connect from a shell.
Start out with the modem in the connected state. In the shell, run
sudo /usr/local/lib/flimflam/test/mm-disconnect; sudo /usr/local/lib/flimflam/test/mm-connect --number='*99#' --apn=wap.cingular
modem-manager should emit the log line "Invalid error code: 583".
Prior to this change, the connect operation would fail. Now it should
succeed.
Change-Id: I6ae0e6a9f5405b54b0b465fe91d9542529f365c2
Reviewed-on: http://gerrit.chromium.org/gerrit/5781
Tested-by: Eric Shienbrood <ers@chromium.org>
Reviewed-by: Nathan J. Williams <njw@chromium.org>
|
|
|
|
It was already exported via D-Bus, but the change signals weren't
getting sent out. I believe this was a holdover from when we weren't
sure whether to export the internal state or not. But we should.
|
|
The APP1 port (which has a limited AT parser) doesn't prefix
its replies with <CR><LF> like nice modems do, and that means
it runs afoul of the echo removal bits of the AT serial port
code. We need to parse the whole string even though it's not
prefixed properly to find the APP1 string in the response.
|
|
Some devices (Sierra GSM ones) return stuff we need but don't
bother to prefix it with <CR><LF>, so we need to optionally turn
off the echo removal at probe time.
|
|
They were getting detected as GSM, because of course the port
type for CDMA modem AT ports is MM_PORT_TYPE_AT, which passed
the check for GSM. Oops.
|
|
When switching branches from git master to MM_06 and 05, the
marshallers generated by git master in src/ get #included
rather than the ones from marshallers/. So make sure we clean
them when doing 'make clean'.
|
|
(bgo #665877) (lp:816400)
|
|
|
|
|
|
|
|
Gsm.Card is really for the SIM, not for anything to do with bands
or the device or whatever. Which was a mistake long cleaned up
in MM 0.7+, but not in earlier versions. Plus, the SupportedBands
and SupportedModes properties were never implemented in any in-tree
drivers.
In the 0.5/0.6 API, SupportedBands belongs on the Network interface
along with the Get/Set methods for bands. The old property on the
Card interface is deprecated, but not removed, to preserve backwards
compatibility.
The SupportedModes property is also deprecated, but not replaced by
a corresponding property on the Network interface, because it returned
a confusing mix of values (conflating access technology and allowed
mode preference), plus it also was never used by in-tree drivers. If
we really do need a property that advertises the supported allowed
modes of the device (ie 2G_PREFERRED, 2G_ONLY, 3G_ONLY, etc) then
we can add one on the Network interface later.
|
|
|
|
|
|
The Huawei plugin requires to probe first the USB interface 0; all the other
probing tasks in the remaining ports will get deferred until the interface 0
gets probed. But, some modems (e.g. Huawei ET8282), don't expose the USB
interface 0 as an AT port, so we get an infinite loop as no port ends up being
probed.
In order to fix this, we will limit to a predefined maximum the number of times
a given probing task is deferred, 4 in this case. So, if a given probing task is
deferred for more than 4x3s=12s, probing will get forced.
|
|
|
|
Who knows how many (if any) spaces modems return.
|
|
Use CFUN=4 to disable radios, keeping access to the SIM
|
|
Also, just g_assert() if regex couldn't be compiled.
|
|
|
|
|
|
|
|
|
|
It turns out we really do have to wait for the modem to return the
">" prompt before sending the message data, otherwise a number of
modems will complain about the data and fail the message. Fix that
by sending the first bit of the CMGS, waiting for the ">", and then
sending the rest.
This also switches all modems over to PDU mode by default if they
support it, since it's more compatible and most recent modems don't
even bother to support text mode anyway.
|
|
Off-by-one, fix it.
|
|
|
|
|
|
If there's no modem-specific power-down command, the port would be
closed prematurely, perhaps leaving unsolicited messages enabled.
Make sure that doesn't happen by ensuring that cleanup commands
complete.
|
|
These ports require QMI commands to start, and MM < 0.7 doesn't
support QMI, so we can't use these yet. They get recognized as
ether ports, but since we can't drive them as ether ports yet,
wierd things happen.
|
|
Tell clients that the reason we're disconnecting isn't some random
hiccup, but that roaming isn't allowed and we're now roaming, and
thus the modem is getting disconnected.
|
|
|
|
|
|
|
|
They seem to give the raw value of the SNR, but we already do signal quality
reporting using ^RSSI, so not useful.
|