Age | Commit message (Collapse) | Author |
|
The wds profile dumps returned by "Get Default Settings" (0x002C)
or "Get Profile Settings" (0x002B) may return TLVs with 0 length.
This has been observed in practice from a Quectel RG502Q-EA with
0x002c and TLVs 0x1b, 0x1c and 0x4a.
Print an empty value string instead of bailing out with an assert
Signed-off-by: Bjørn Mork <bjorn@mork.no>
|
|
We have a custom modified gtk-doc.make file in our sources, which
disables the gtkdoc-rebase on local install step, so we don't want
autoreconf to copy a different one when we're bootstrapping.
|
|
The template files in the `build-aux/templates` directory used in
enums sources and headers generation use the `{$name}-template.[ch]`
pattern. However, the examples in the official guide[0] and usually
GNOME and Freedesktop packages use the `{$name}.[ch].template`
pattern.
Due to this, the name of the template files and build commands have
been changed.
[0] https://developer.gnome.org/gobject/stable/glib-mkenums.html
|
|
This will be used by transfer-route message MT handling in ModemManager
|
|
|
|
On a QmiDevice re-open, if we're opening with the version info check
flag, we would be re-querying the device for the list of supported
services. That is fine, but we must make sure the array of supported
services from the last open operation is cleared before storing the
new one.
|
|
Just assuming the TLV id and format is the same.
E.g.:
$ sudo qmicli -p -d /dev/cdc-wdm0 \
--wds-create-profile="3gpp,apn=something2,apn-type-mask=emergency|ims"
New profile created:
Profile type: '3gpp'
Profile index: '6'
$ sudo qmicli -p -d /dev/cdc-wdm0 --wds-get-profile-list=3gpp
Profile list retrieved:
...
[6] 3gpp -
APN: 'something2'
APN type: 'ims, emergency'
PDP type: 'ipv4-or-ipv6'
PDP context number: '6'
Username: ''
Password: ''
Auth: 'none'
No roaming: 'no'
APN disabled: 'no'
|
|
The kernel may be new enough to have rmnet support, but it could be
that libc doesn't have ARPHRD_RAWIP defined yet; if so, just define it
ourselves.
Fixes http://autobuild.buildroot.org/results/c8853b7161bd85d46c1282c6c097e7ef4042ae68
|
|
|
|
Fixes https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/issues/57
|
|
Instead of trying to print the NULL string, which ends up as '(null)'
|
|
|
|
|
|
Read the APN Type mask when getting profile settings
and display it in qmicli.
This can be used later to filter APN in the list of APNs
(MBIM as a similar 'ContextType')
|
|
QMI_NAS_PLMN_ACCESS_TECHNOLOGY_IDENTIFIER_NGRAN added since 1.29.2.
|
|
These are to be used in ModemManager.
|
|
|
|
If mux-id is not given, AUTO is assumed.
|
|
|
|
QmiDeviceAddLinkFlags bitmasks
By default flags will be NONE if none specified.
Flags are specified as usual, using nicknames separated by '|', e.g.:
$ sudo qmicli -d /dev/cdc-wdm0 --link-add="mux-id=auto,iface=wwan0,prefix=qmapmux,flags=ingress-map-cksumv4|egress-map-cksumv4"
|
|
The rmnet backend allows some configuration when creating link
interfaces. This configuration specifies how the link being created
works, and is strictly dependent on the setup. E.g. when using rmnet
over IPA we may need to always specify that checksum offload is
supported, while when using rmnet over qmi_wwan, no checksum offload
is currently supported.
None of the flags are applicable to the qmi_wwan-only backend, and so
this new method will return an UNSUPPORTED error if any flag is given
to this backend.
The generic add_link() method is now equivalent to running
add_link_with_flags() with QMI_DEVICE_ADD_LINK_FLAG_NONE.
|
|
Co-authored-by: Aleksander Morgado <aleksander@aleksander.es>
|
|
Define two UIM messages needed to get personalization status and remove
modem locks.
|
|
This access technology bit is presumably supported by 5G modems.
|
|
|
|
|
|
It's going to be used in ModemManager.
|
|
The TLVs that included a guint8 reject cause are updated to have them
reported with the new QmiNasRejectCause enum type.
The old methods that referred to the field as guint8 are flagged as
deprecated and compat replacements are provided to avoid API/ABI
breaks in the next libqmi release.
|
|
|
|
|
|
0x0067 goes after 0x0065
|
|
|
|
Required for memset() and memcpy().
|
|
This fixes the build when using GLib < 2.54.
|
|
|
|
|
|
The g_ptr_array_steal_index_fast() method was introduced in 2.58,
fallback to use g_ptr_array_remove_index_fast() instead.
|
|
|
|
|
|
|
|
|
|
The original logic assumed that after the sysfs add_mux/del_mux write
operation, the link interface would require some time to show up in
sysfs, and so we would attempt to always run one by one these
operations, so that e.g. we could keep track of what mux_id was
requested and what link name was generated.
But this doesn't seem to be true; add_mux/del_mux seem to guarantee
that as soon as the write operation finishes successfully, the new
link is already available (for add_mux) or the given link was already
removed (for del_mux).
So just simplify the logic, and run the whole add/del logic in a sync
way without forcing an artificial 250ms timeout to complete each
operation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|