We'll try to cope with getting devices being reported in either 'usb' or
'usbmisc', trying to avoid the need of checking kernel version during runtime.
All grabbed 'net' ports are added to the new list of data ports. It is a task
for the specific plugin to decide how each of the data ports should be
connected. In the case of not having 'net' ports, the list of data ports will
only contain a single AT port.
All grabbed 'qmi' ports are added to the new list of QMI ports. The first port
in the list is to be considered the 'primary' one, and will be the one used
for all services. The remaining QMI ports, if any, will only be used to for WDS,
to manage the associated 'net' ports.
The 'detailed service status' TLV is either pretty new and not always available,
or given only under some specific circumstances. So, try to gather CDMA1x and
EV-DO registration status with the default info we usually do get.
The logic is the following:
* If registered and the access technologies contain CDMA1x, then CDMA1x is
registered, otherwise it's not.
* If registered and the access technologies contain any of the EV-DO revisions,
then EV-DO is registered, otherwise it's not.
An example output in a CDMA network:
[/dev/cdc-wdm0] Successfully got serving system:
Registration state: 'registered'
CS: 'attached'
PS: 'attached'
Selected network: '3gpp2'
Radio interfaces: '2'
[0]: 'cdma-1xevdo'
[1]: 'cdma-1x'
Roaming status: 'off'
Data service capabilities: '2'
[0]: 'cdma'
[1]: 'evdo-rev-a'
Current PLMN:
MCC: '311'
MNC: '480'
Description: 'Verizon Wireless'
CDMA System ID:
SID: '26'
ESN: '1'
CDMA Base station info:
Base station ID: '3633'
Latitude: '44.913333'º
Longitude: '-93.279722'º
Roaming indicators: '2'
[0]: '(null)' (cdma-1x)
[1]: '(null)' (none)
Default roaming status: '(null)'
3GPP2 time zone:
Leap seconds: '16' seconds
Local time offset: '-300' minutes
Daylight saving time: 'no'
CDMA P_Rev: '6'
Seems that sometimes we get 'selected network' as UNKNOWN, but we still have
proper registration information. Try to handle those cases.
[/dev/cdc-wdm0] Successfully got serving system:
Registration state: 'registered'
CS: 'detached'
PS: 'attached'
Selected network: 'unknown'
Radio interfaces: '1'
[0]: 'lte'
Roaming status: 'off'
Data service capabilities: '1'
[0]: 'lte'
Current PLMN:
MCC: '311'
MNC: '480'
Description: 'Verizon Wireless'
Roaming indicators: '1'
[0]: 'off' (lte)
The QMI protocol is updated frequently with new commands replacing and
improving some already existing ones, which get marked as deprecated.
Instead of initially try to cover the logic with both the old and the new
commands, we'll default to use only the old deprecated ones, which should be
supported also in the modems with newer services.
The supported already implemented for the new QMI commands is hidden behind a
`--with-newest-qmi-commands' configure switch.
Once the implementation is fully developed and tested using the deprecated
commands we can then focus in including the support for the new ones.
Implementations of the CDMA interface can either:
* Implement run_registration_checks()
or,
* Implement the sub-steps of the generic registration checks sequence
In the generic broadband modem implementation we'll just implement the specific
command to request auto/manual network registration, and we leave all the other
logic (waiting for the new registration status and all that) in the interface,
as it is really common for every possible implementation.
Sync with libqmi:
commit 54e5400f6977ae2036b54c2661c1e5c101e03fe4
Author: Aleksander Morgado <aleksander@lanedo.com>
Date: Mon Aug 6 19:57:06 2012 +0200
nas: fix `QmiNasRadioTechnologyPreference' enum names
'Analog' and 'Digital' are purely 3GPP2 terms, so avoid those and provide a mix
of 3GPP and 3GPP2 names.
Instead of always trying to use the newest commands and falling back to the
deprecated one when found that it is not supported, use the service version
given by the client to determine which is the best command to use.
Still, sometimes we need to handle ourselves the fallback to the deprecated
command, when we don't exactly know in which service version the new behaviour
was added (e.g. the 'Mode Preference' TLV in 'Get/Set System Selection
Preference' was last updated in NAS 1.16, but we don't exactly know when it
was added).
Sync with libqmi:
commit cc97645578d937417bb2d72d22714776a98c549e
Author: Aleksander Morgado <aleksander@lanedo.com>
Date: Thu Aug 2 12:15:05 2012 +0200
nas: don't mistake 'change duration' with 'preference duration'
They actually have POWER_CYCLE and PERMANENT values swapped.
Kudos to the one who decided that.
The logic here involves knowing if we have support for 'Signal Info'
indications. All the 'Signal Info' stuff was included in NAS 1.8, so we're
just using a single flag to indicate support for that.
If we do have 'Signal Info', enabling the signal quality indications involves
two steps: configuring thresholds with "Config Signal Info" and then enabling
them with "Register Indications".
If we don't have 'Signal Info' we fallback to the good old "Set Event Report"
for enabling/disabling the indications.
