- Aug 29, 2012
-
-
Dan Williams authored
-
Dan Williams authored
-
Dan Williams authored
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.
-
Dan Williams authored
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.
-
Dan Williams authored
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.
-
Dan Williams authored
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.
-
Dan Williams authored
Some devices should use custom call control commands instead of AT%IPDPACT.
-
- Aug 28, 2012
-
-
Dan Williams authored
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.
-
Dan Williams authored
Since we can't autodetect that the devices use DHCP, we'll need to tag them with udev rules for the time being.
-
- Aug 27, 2012
-
-
Dan Williams authored
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.
-
Dan Williams authored
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.
-
Dan Williams authored
Not all properties are strings, so when copying the GValue we have to use the source GValue's type, not STRING.
-
Dan Williams authored
-
Dan Williams authored
Moto EZX devices prefix the response with +CIMI:, plus some Option devices suffix it with ",XXXXX" where X is a firmware version or something.
-
- Aug 24, 2012
-
-
Dan Williams authored
More fallout from b22b2d99 which changed the return type of the qcdm_result_get_*() functions.
-
Dan Williams authored
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>
-
Dan Williams authored
-
Dan Williams authored
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.
-
Dan Williams authored
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.
-
Dan Williams authored
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.
-
Dan Williams authored
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.
-
- Aug 16, 2012
-
-
Dan Williams authored
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'.
-
- Aug 09, 2012
-
-
Marius B. Kotsbak authored
(bgo #665877) (lp:816400)
-
- Aug 08, 2012
-
-
Dan Williams authored
-
- Aug 03, 2012
-
-
Dan Williams authored
-
Dan Williams authored
-
Dan Williams authored
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.
-
Dan Williams authored
-
Dan Williams authored
-
- Jul 30, 2012
-
-
Aleksander Morgado authored
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.
-
- Jul 28, 2012
-
-
Dan Williams authored
-
- Jul 23, 2012
-
-
Dan Williams authored
Who knows how many (if any) spaces modems return.
-
Alexander Orlov authored
Use CFUN=4 to disable radios, keeping access to the SIM
-
- Jul 21, 2012
-
-
Aleksander Morgado authored
Also, just g_assert() if regex couldn't be compiled.
-
- Jul 20, 2012
-
-
Dan Williams authored
-
- Jul 19, 2012
-
-
Dan Williams authored
-
Dan Williams authored
-
Dan Williams authored
-
- Jul 18, 2012
-
-
Dan Williams authored
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.
-