| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Can't schedule the info completion until we're sure all the
requests have completed. They won't necessarily be completed
in the same order they were issued since some of the data the
requests pull from could be cached and thus we don't have to
wait in the queue to hit up the modem.
|
|
|
|
|
|
Using the USB product ID to direct certain modems to the generic
driver is wrong since even new modems like the E1550 are 0x1001
after the modeswitch. Instead, lets assume that most current modes
use the Huawei-specific AT command set.
|
|
As with allowed modes, make things clearer and simpler by giving
access technology it's own values.
|
|
Instead of trying to stuff everything into the mode bitfield it
turns out it's just easier, clearer, and simpler to use different
values for each of the following:
1) the device's supported access technologies and allowed modes
2) the device's current access technology
3) the device's allowed mode preference
Since none of the AccessTechnology or AllowedMode stuff has hit a
release yet, let's make sure we're doing it the right way early on.
|
|
|
|
Since the values they carry are bitfields, using the highest value
as the maximum isn't the right thing to do.
|
|
Only one mode is going to be stored here so it shouldn't be plural.
|
|
It's just easier this way. It makes little sense to allow
selecting mode combinations for anything other than
(HSDPA | HSUPA). Most radios don't allow fine-grained control
of the different technologies within each 2G or 3G class anyway
thus combinations like (GPRS | UMTS) are pointless since the
device wouldn't be able to use GPRS but not use EDGE.
|
|
AccessTechnology takes over half of what NetworkMode was supposed to
do, but we'll keep NetworkMode around for a while for compatibility
anyway. Create async updaters that subclasses can use to update
the access tech when they get unsolicited messages.
|
|
|
|
|
|
This adds split properties and functions for the allowed modes and the
current access technology used by the device when connected to the
mobile network.
|
|
|
|
MM hadn't implemented it yet, but Wader already implemented an earlier
version that didn't use a bitfield but an enum. Unfortunately the
network mode stuff doesn't allow for distinguishing between the device's
mode preference and the current access technology. So deprecate the
current network mode stuff in the API in preparation for improved API.
|
|
|
|
|
|
|
|
For registration updates and signal strength.
|
|
First, generically handle registration polling if the device does
not support unsolicited registration. Second, using the new
creg/cgreg parsing functions from mm-modem-helpers.c, handle
CREG=2 unsolicited registration replies to capture the GSM LAC/CI
for the location information API.
Because of these changes we can simplify the registration polling
during connection as well by using the common registration parsing
code and the cached registration state.
|
|
407abc65c6ccd802ce8456e5a63e68fab1c7d0a1
Got the logic wrong in that commit. Fix it. Network registration
should always be run since it handles polling for registration
state if needed before continuing.
|
|
Since D-Bus signals cannot by nature be restricted to authenticated
clients (unless using private D-Bus connections) we can handle the
security a bit differently here. Since the Enable() call can be
authenticated, we'll trust the client to say whether higher
security should be used by disallowing location update signals. This
does mean the client will have to poll for location updates, but at
least then clients requesting location information can be
authenticated.
|
|
|
|
NOT FINAL; need to discuss with Pablo and others and actually implement
it before declaring it final.
|
|
|
|
|
|
This is handled by the generic class before the modem is even exported
over D-Bus.
|
|
This is handled by the generic class before the modem is even exported
over D-Bus.
|
|
This is handled by the generic class before the modem is even exported
over D-Bus.
|
|
Since the modem states patch the delay for power-on wasn't honored
for Option devices. Fix that using the new power-on-done handler
and also fix the bug where if the modem was removed, the plugin
would crash because it wasn't handling the timeout removal.
Also remove the explicit PIN check since that's now handled by the
generic GSM code before the modem is even exported over DBus.
|
|
Since the modem states patch the delay for power-on wasn't honored
for Sierra devices. Fix that using the new power-on-done handler
and also fix the bug where if the modem was removed, the plugin
would crash because it wasn't handling the timeout removal.
Also remove the explicit PIN check since that's now handled by the
generic GSM code before the modem is even exported over DBus.
|
|
This lets subclasses handle errors when they know the device supports
the power-up command. Also will let us simplify a number of plugins.
|
|
|
|
First, short-circuit the Enable process if the device requires a PIN
or PUK since for many devices the enable is going to fail anyway
until the PIN is sent.
Second, send the PIN first during the simple state machine for the
same reason; we need the device unlocked before we want to try
to enable it. This also reworks the simple state machine to be a
bit clearer and make each state step correspond to the action it's
actually doing instead of being off-by-one visually (but not logically).
|
|
Don't return until we know what the updated lock status is. Fixes an
issue where callers that send the PIN before the modem is enabled
(remember, some modems can't be enabled until the PIN is entered, so
sometimes we have to send the PIN before it's enabled) would get
the reply too early and get failures from other operations.
|
|
|
|
If E2NAP:0 is received during a connection attempt the connection
attempt has failed or will fail. So stop polling for connection
success for another 50 seconds and abort the connection attempt
immediately. Also moves the E2NAP request call a bit earlier to
ensure that no E2NAP unsolicited messages are lost.
|
|
|
|
It's useful to let distros and admins set policy differently for device
information (for support, inventory, etc) than for actually controlling
the device like PIN/PUK unlocks.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
