| Age | Commit message (Collapse) | Author |
|---|
|
If processing a key-value pair as a bearer property fails, we need to
know if it failed due to the key being unknown or due to some other
reason (e.g. failure parsing value of a known key).
We'll only try with the Simple.Connect properties if the key is
reported as unknown in the bearer properties.
This will help us better identify errors if e.g. an invalid value is
given to a known key. E.g. "yes" was invalid for allow-roaming here:
daemon.notice netifd: wan (30476): simple connect=apn=internet,ip-type=ipv4,allow-roaming=yes
daemon.notice netifd: wan (30476): Error parsing connect string: 'Invalid properties string, unexpected key 'allow-roaming''
|
|
E.g. so that the settings passed on Simple.Connect() or
Bearer.Connect() are parsed correctly from the user string:
daemon.notice netifd: wan (30476): simple connect=apn=internet,ip-type=ipv4,allow-roaming=yes
daemon.notice netifd: wan (30476): Error parsing connect string:
'Invalid properties string, unexpected key 'allow-roaming''
This also goes inline with e.g. the --create-bearer help in the man
page that suggests using yes/no for the allow-roaming setting.
|
|
The error returned in support_check_finish() should be treated as
optional, as in all the other optional feature interfaces.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/172
|
|
|
|
The new mm_location_gps_nmea_get_traces() is a much more generic way
to retrieve the full list of traces and suits the libmm-glib API much
better.
|
|
|
|
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/120
|
|
When a flash operation is started, it is always scheduled in an idle.
If this operation is cancelled, we should right away un-schedule it,
otherwise we may end up calling flash_do() with the GTask in the
private info already gone.
See https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/178#note_330017
|
|
If the Simple.Connect() operation fails before the bearer connection
process starts (e.g. during the previous SIM-PIN checks or explicit
registration attempt), the ongoing connect cancellable is not being
properly cleared, and this would prevent additional new connection
attempts unless an explicit Simple.Disconnect() is called.
$ sudo mmcli -m 1 --simple-connect="operator-id=21403,apn=internet"
error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.MobileEquipment.NetworkTimeout: Network timeout'
$ sudo mmcli -m 1 --simple-connect="operator-id=21403,apn=internet"
error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.InProgress: Connection request forbidden: operation already in progress'
$ sudo mmcli -m 1 --simple-connect="operator-id=21403,apn=internet"
error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.InProgress: Connection request forbidden: operation already in progress'
Fix this, by making sure the ongoing connect cancellable is always
cleared when completing the DBus method invocation that created it.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/169
|
|
Defining the new error codes in the headers is not enough, we also
need to add support in the error helpers in order to create proper
GErrors with the expected error codes.
|
|
|
|
We don't want the connection status checks to interfere with the
disconnection logic, e.g. if they're both using the same TTY for both
things.
E.g. the CGACT? from the conncheck gets in the way of the
disconnection logic:
<debug> [1576037519.710684] Flashing data port (ttyUSB1)...
<debug> [1576037519.710740] (ttyUSB1): port attributes not fully set
<debug> [1576037520.287636] (ttyUSB1) device open count is 3 (open)
<debug> [1576037520.287804] (ttyUSB1): --> 'AT+CGACT?<CR>'
<debug> [1576037520.711067] (ttyUSB1) device open count is 2 (close)
<debug> [1576037520.711127] (ttyUSB1): running init sequence...
<debug> [1576037520.711231] PDP disconnection already sent
<debug> [1576037520.711263] Disconnected bearer '/org/freedesktop/ModemManager1/Bearer/0'
Instead, fully skip all conncheck and stat updates as long as the
modem is not connected. The actual conncheck and stat update timeouts
will be removed once completely disconnected, as it was before.
|
|
This is required in the TOBY-L2 and TOBY-L4 modules in order to report
a proper disconnection, even if there is none in reality. The default
LTE bearer is always reported connected while registered in LTE.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/166
|
|
When the MT detects an attempt to disconnect the last PDN or when the
network returns a response message with cause value #49, the "Last PDN
disconnection not allowed" error is returned.
The numeric error code was changed from 151 to 171 in 3GPP Rel-11, and
therefore there are devices out there that would conform to Rel-10 or
below and that would report +CME ERROR code 151 instead of 171. Given
that 151 isn't defined to a different meaning in the specs, let's
define it in the same way as 171.
|
|
So that bindings know how to free the list of structs.
This commit ends up triggering an API break in the bindings generated
via GObject introspection, because the methods to access the items of
a MMModem3gppNetwork are no longer treated as Modem3gpp class methods.
E.g. instead of:
ModemManager.Modem3gpp.network_get_operator_code(network)
We should now do:
network.get_operator_code()
There is no API break in libmm-glib.
|
|
This is currently not working completely ok because python doesn't
know how to free the GList of MMModem3gppNetwork elements.
/org/freedesktop/ModemManager1/Modem/1: starting network scan...
21403: Orange - Orange (unknown, forbidden)
21401: vodafone ES - vodafone ES (unknown, forbidden)
21403: Orange - Orange (unknown, forbidden)
21403: Orange - Orange (unknown, forbidden)
21401: vodafone ES - vodafone ES (unknown, forbidden)
21404: Yoigo - Yoigo (unknown, forbidden)
21401: vodafone ES - vodafone ES (unknown, forbidden)
21404: Yoigo - Yoigo (unknown, forbidden)
21407: Movistar - Movistar (unknown, available)
21407: Movistar - Movistar (unknown, available)
21407: Movistar - Movistar (unknown, current)
free(): invalid pointer
Aborted
|
|
This reverts commit 3eb623e73b546a444c1fc717f4ed105b3b2d5eae.
This change is plain wrong. The correct order was already fixed in
commit 42dab8e8.
|
|
Solving build issues with truly strict linkers, as in:
http://lists.busybox.net/pipermail/buildroot/2019-December/268817.html
|
|
Also, make sure we enable/disable the voice related unsolicited events
in both primary and secondary ports, because it may happen that the
primary port is connected with PPP and we're using the secondary port
for control.
|
|
When using mm_base_modem_at_command_full(), the corresponding
mm_base_modem_at_command_full_finish() should be used.
|
|
If the modem is connected using the primary port, we can just rely on
the secondary port.
# mmcli --call 0 --start
error: couldn't start the call: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Connected: Cannot run sequence: port is connected'
|
|
|
|
Allow the generic command API while in FAILED state, in case the modem
integrator has some special commands to recover the device.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/163
|
|
If for any reason getting current settings fails and we require static
IP addressing (when using raw-ip), then that must be a hard error,
otherwise we'll end up with the modem reported as connected but
without any IP settings to use:
<info> error: couldn't get current settings: QMI protocol error (15): 'OutOfCall'
<info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (registered -> connected)
<info> Simple connect state (8/8): All done
<warn> Reloading stats failed: Couldn't get packet statistics: QMI protocol error (15): 'OutOfCall'
# mmcli -b 0
Bearer '/org/freedesktop/ModemManager1/Bearer/0'
-------------------------
Status | connected: 'yes'
| suspended: 'no'
| interface: 'wwan1'
| IP timeout: '20'
-------------------------
Properties | apn: 'm2minternet'
| roaming: 'allowed'
| IP type: 'none'
| user: 'none'
| password: 'none'
| number: 'none'
| Rm protocol: 'unknown'
-------------------------
IPv4 configuration | method: 'unknown'
-------------------------
IPv6 configuration | method: 'unknown'
-------------------------
Stats | Duration: '0'
| Bytes received: 'N/A'
| Bytes transmitted: 'N/A'
# mmcli -m 0
/org/freedesktop/ModemManager1/Modem/0 (device id '48f6c35f3d0376aa261a91c0cf7e6340d5a91601')
...
Status | lock: 'sim-pin2'
| unlock retries: 'sim-pin (3), sim-pin2 (3), sim-puk (10), sim-puk2 (10)'
| state: 'connected'
| power state: 'on'
| access tech: 'lte'
| signal quality: '96' (recent)
|
|
When we try to disconnect a bearer and the bearer is already
disconnected (e.g. after a cancelled connection attempt), avoid reporting
that as an error:
<warn> [1575287560.433398] Error disconnecting bearer '/org/freedesktop/ModemManager1/Bearer/0': 'Couldn't disconnect QMI bearer: this bearer is not connected'. Will assume disconnected anyway.
|
|
If a WDS indication is received telling us that the modem is no longer
connected, abort the ongoing connection attempt right away with an
error and cleanup all allocated clients (implicitly disconnecting them
if required)..
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/155
|
|
Refactor the logic and setup a common complete_connect() method that
helps us complete the GTask associated to the connection attempt.
|
|
If the bearer is using a QMI port that is not the primary one, we need
to explicitly open it during the connection attempt. Keep track of
that, and make sure we close it during normal disconnection or if the
connection attempt fails.
|
|
|
|
|
|
Including IOTA-based update, e.g. for Sprint.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
E.g. we shouldn't print emergency numbers field if there is none available:
$ mmcli -i 0
-------------------------------
General | dbus path: /org/freedesktop/ModemManager1/SIM/0
-------------------------------
Properties | imsi: 901700000026890
| iccid: 8988211000000268907
| operator id: 90170
| operator name: 901 70
| emergency numbers:
|
|
|
|
|
|
|
|
|
|
If we blindly try to use QMI over MBIM on devices that don't support
it, the logic works ok but it's very slow, given that the QMI device
open operation has several internal retries, and all those end up
timing out.
Avoid that lost time by checking the list of services supported by the
MBIM modem, and if the QMI over MBIM service is not listed, we'll
avoid trying to open the QMI device right away.
|
|
* single-plugin builds only on schedules
* with/without qmi/mbim builds on master and merge requests
* default build always, including on branches and when git pushing
|
|
|
|
|
|
|
|
|
|
|
|
|
