| Age | Commit message (Collapse) | Author |
|---|
|
The generic disconnection logic now already handles getting the port fully
closed and a wait time before reopening it, so no need for a custom
disconnection logic any more.
|
|
|
|
e.g:
AT+ZPINPUK=? |
| ZPINPUK: 3,10
| OK
|
|
Instead of deciding in advance which data port to use, we let the dialling
operation gather it. For the generic dialling logic, ATD-based, always an
'AT' port will be used as data port, even if we grabbed a 'net' port. Those
plugins that can work with 'net' ports will grab the specific 'net' port
themselves.
|
|
Instead of returning 3 variables in connect_finish(), return a single reference
counted struct. This simplifies how the result is built and passed within a
GSimpleAsyncResult to each _finish() method.
This also simplifies the dialling step in the 3GPP connection sequence, as we
can use the same new type.
|
|
Instead of a custom modem_init() step in the 'Modem' interface, just add a
sequence of port initialization commands in each port.
While enabling for the first time a non-hotplugged modem, we will issue the
port initialization commands only after having run the enabling_modem_init()
step (i.e. after ATZ usually).
|
|
We previously had the modem initialization command merged with some other port
setup commands in the 'modem_init' step of the 'Modem' interface. Instead of
doing this, we now split the logic into two separate steps:
A first 'enabling_modem_init' modem initialization step is to be run just after
the ports have been opened, but only during the first enabling operation, and
only if the modem was not hotplugged. A hotplugged modem is assumed to be
properly initialized already, so no need to ATZ-it. Also, we will now wait 500ms
by default after the modem initialization command has been sent, to let it
settle down.
The second 'modem_init' step will be run during the 'Modem' interface
initialization, and it currently only holds specific setup of the primary and
secondary serial ports. We'll be modifying this logic a bit in the next commits,
so no big deal to have that step name unchanged.
|
|
When setting allowed modes, a ",2" crept into the MODODR command when
porting the plugin from 0.6. That shouldn't be there.
When getting allowed modes, 2 is UMTS preferred and 4 is GSM preferred,
which the previous code combined into only UMTS preferred.
|
|
|
|
HSUPA/HSPA capable devices (ex F5521gw) can report '3' here, which
we'll decide to interpret as HSPA. It might actually be HSDPA + HSUPA,
but whatever...
|
|
Treat NONE the same as ANY and handle specific preferred modes too.
|
|
Some devices (like the ADU960S) support QMI, so if the modem has a
QMI port, use it.
|
|
Specialize what the superclass gave us, if we can.
|
|
roaming
We use the Icon ID here because a value of 1 *always* means not roaming,
while the other values don't appear to be consistent. For example,
an ERI value of "0" is supposed to mean roaming according to the
standards, but the Novatel devices appear to use 0 to mean home.
Since we're not sure, don't depend on the ERI value itself, just
depend on the Icon ID, where we know for sure that 1 means "home".
|
|
|
|
$NWQMISTATUS sometimes returns 'ERROR'. This patch modifies the Novatel
LTE plugin to retry $NWQMISTATUS (up to 5 times) to determine if the
disconnect operation succeeds. It also changes the plugin to assume that
the disconnect operation succeeds if $NWQMISTATUS fails to report the
current connection status.
|
|
Soft resetting a Novatel LTE modem can a significant amount of time
(3-4 seconds). If the modem is newly plugged in, skip the unnecessary
soft reset when enabling the modem.
|
|
We don't want to retry DHCP? on every possible GError reported; specially if the
error is about the port being forced to get closed when the modem gets
unplugged or the like. So just retry on very specific errors reported.
The main cause for retry is really when the modem replies the following:
--> AT^DHCP?
<-- ERROR
Which in our case gets translated to a 'unknown' mobile equipment error. We'll
also consider any kind of mobile equipment error, as the modems may reply a
CME ERROR instead.
|
|
|
|
|
|
We will now use a step-based state machine to handle the connection and
disconnection sequences. All the previous behaviour is kept, except for these
new things:
* Instead of just subclassing the 'dialling' step in the 3GPP connection
sequence, completely subclass the whole 3GPP connection sequence. We do this
because we don't need to preconfigure PDP contexts with AT+CGDCONT before
issuing ^NDISDUP.
* Don't allow IP types other than IPv4. These modems work only with IPv4
bearers.
* Remove cancellation signal handler; not needed as we can check the status of
the cancellation in every 1s timeout.
* Removed the event source id handling for timeouts; timeouts are never
cancelled here.
|
|
Don't assume that all modems exporting a 'net' port will support ^NDISDUP.
|
|
Modems with ECM (e.g. usb0) ports should use AT^NDISDUP in the control port to
request the connection and afterwards just fire up the DHCP client in the net
port.
This patch is originally developed by:
Franko Fang <fangxiaozhi@huawei.com>
And afterwareds reviewed and updated by:
Aleksander Morgado <aleksander@gnu.org>
|
|
Use AT!STATUS to grab current access technology.
|
|
We'll use it for access technology reporting too.
|
|
We have !STATUS for that, which is much more detailed. Use it.
|
|
Sierra CDMA devices don't always have QCDM ports, or if they do,
they aren't always usable. Try Sierra-proprietary commands for
loading the modem's MDN and fall back to QCDM if that fails.
|
|
mm_get_int_from_str() does not allow anything in the string after the
number, eg "-91 asdfasdf" returns an error. So we have to chop off
anything after the number we're interested in.
|
|
|
|
|
|
|
|
We no longer power down the modem during initialization, so remove that
implementation.
|
|
When both load_power_state() and modem_power_down() are not implemented, the
logic will launch the power-up command during (only the first) enabling of the
modem.
In this kind of modems, CFUN is directly related to allowed/preferred modes, so
during the initial power-up we'll just assume we want ANY mode.
|
|
No need to initially power-up the modem.
|
|
No need to initially power-up the modem.
|
|
No need to initially power-up the modem.
|
|
This logic is now implemented by the parent broadband modem object.
Also, implement a custom initial power state loading, so that CDMA-only modems
get marked as 'offline', in order to launch !pcstate=1 to power them up during
the first enabling. The custom initial power state loading will run the parent's
implementation in non-CDMA-only modems.
|
|
This logic is now implemented by the parent broadband modem object.
|
|
|
|
|
|
Specially the first time that CFUN=1,0 is issued after the initial power up, we
really need to wait more than 3s for the AT command reply. Otherwise, the modem
won't like it and it will reset itself :-/
|
|
Not only +PACSP0, but also +PACSP1.
|
|
There was a missing step++ when falling down to the next step in the switch(),
which was preventing a proper connection.
|
|
|
|
|
|
Plain non-Icera ZTE modems will use ATD calls and PPP to establish the
connection, so ignore 'net' ports that may be found in the way (e.g. when the
modem is a QMI modem and we're not using QMI support).
|
|
Disabled in normal compilation, can be enabled to debug issues.
|
|
Unfortunately, Sierra secondary APP ports reply to +GCAP with
only "OK", and not their APP port number or model number. So instead
of using +GCAP, we have to use ATI to get secondary port information.
This allows us to detect which port is the APP1 port that we can
potentially use for PPP, leaving the primary port available for
control and status.
Also, some modems have up to 3 or 4 APP secondary ports, which we
need to ensure aren't used as primary. The previous check for +GCAP
handled that, but let's make it more explicit.
AT+GCAP reply:
OK
ATI reply:
Sierra Wireless, Inc.
C885
APP1
OK
See also: 3f3987e09ee762e48c1d53cb42a1288ce9f332cb (MM_06)
|
|
If the primary port is gone (e.g. when going to sleep) and we are just in the
middle of a connection attempt, we won't be able to receive any unsolicited
message regarding the status of the attempt. So, if we detect that the port is
forced to get closed, we'll just treat it as a connection failure.
http://code.google.com/p/chromium-os/issues/detail?id=35391
|
|
|
