Age | Commit message (Collapse) | Author | Files | Lines |
|
[85/146] Compiling C object src/qmicli/qmicli.p/qmicli-dpm.c.o
../src/qmicli/qmicli-dpm.c:58:5: warning: missing initializer for field ‘arg_description’ of ‘GOptionEntry’ {aka ‘struct _GOptionEntry’} [-Wmissing-field-initializers]
58 | },
| ^
|
|
This is useful for debugging SMS routing.
|
|
If both 'Extended List' and 'Bandwidth List' are missing, we would be
setting the GError twice. Just skip using the GError altogether, as
we're not even printing the error message when these optional TLVs are
missing.
Fixes https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/issues/56
|
|
'wwan' is the Linux subsystem/driver exposing raw PCIe/MHI channels
to userspace via character devices. This channels can serve as transport
for various protocols, including QMUX, MBIM, etc...
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Updated to rename from the original 'mhi_uci' to the final 'wwan'
subsystem/driver name by Aleksander Morgado <aleksander@aleksander.es>.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
|
|
The open port action allows 3 optional TLVs, which we create from a
single string passed by the user.
Each of this TLVs is an array of items, and so the user can pass
multiple groups of keys in order to add multiple items on the same
array. E.g. this should build a request with 2 items in the hw data
port list:
$ sudo qmicli -d qrtr://0 -p \
--dpm-open-port="hw-data-ep-type=embedded,hw-data-ep-iface-number=1,hw-data-rx-id=1,hw-data-tx-id=2,
hw-data-ep-type=embedded,hw-data-ep-iface-number=2,hw-data-rx-id=3,hw-data-tx-id=4"
Each array has a given set of keys to create its elements; if not all
keys for a given array element are given, the operation will fail.
E.g. in this case the second item lacks the 'hw-data-tx-id' field:
$ sudo qmicli -d qrtr://0 -p \
--dpm-open-port="hw-data-ep-type=embedded,hw-data-ep-iface-number=1,hw-data-rx-id=1,hw-data-tx-id=2,
hw-data-ep-type=embedded,hw-data-ep-iface-number=2,hw-data-rx-id=3"
error: unfinished hw data port item
|
|
The Data Port Mapper service provides a way to map hardware endpoint
ids to the ep-type/ep-iface-number fields we would normally use in
"WDA Get/Set Data Format" or "WDS Bind Mux Data Port".
This mapping seems to be required in setups using the IPA driver,
e.g. as seen in the mmdata_port_cfg() method of the modem-data-manager
tool provided by the CodeAurora project under the Linux Foundation:
https://source.codeaurora.org/quic/dataservices/modem-data-manager
|
|
==44890== 64 bytes in 4 blocks are definitely lost in loss record 4,011 of 5,965
==44890== at 0x4840B65: calloc (vg_replace_malloc.c:760)
==44890== by 0x508AA61: g_malloc0 (in /usr/lib/libglib-2.0.so.0.6800.1)
==44890== by 0x4A3B21A: device_add_link_ready (qmi-device.c:1857)
==44890== by 0x4EB73D3: ??? (in /usr/lib/libgio-2.0.so.0.6800.1)
==44890== by 0x4EB7408: ??? (in /usr/lib/libgio-2.0.so.0.6800.1)
==44890== by 0x5081F2F: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.6800.1)
==44890== by 0x50D5B58: ??? (in /usr/lib/libglib-2.0.so.0.6800.1)
==44890== by 0x5081592: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.6800.1)
==44890== by 0x15A503: main (main.c:213)
|
|
Aggregation is optional and can be disabled.
$ qmicli -p -d /dev/cdc-wdm0 --wda-get-data-for mat=ep-type=hsusb,ep-iface-number=4
[/dev/cdc-wdm0] Successfully got data format
QoS flow header: no
Link layer protocol: 'raw-ip'
Uplink data aggregation protocol: 'qmapv5'
Downlink data aggregation protocol: 'qmapv5'
NDP signature: '0'
Downlink data aggregation max datagrams: '32'
Downlink data aggregation max size: '31744'
$ qmicli -v -p -d /dev/cdc-wdm0 --wda-set-data-format=link-layer-protocol=raw-ip,ul-protocol=disabled,dl-protocol=disabled,ep-type=hsusb,ep-iface-number=4
[/dev/cdc-wdm0] Successfully set data format
QoS flow header: no
Link layer protocol: 'raw-ip'
Uplink data aggregation protocol: 'disabled'
Downlink data aggregation protocol: 'disabled'
NDP signature: '0'
Downlink data aggregation max datagrams: '0'
Downlink data aggregation max size: '0'
Signed-off-by: Bjørn Mork <bjorn@mork.no>
|
|
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>
|
|
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
|
|
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
|
|
|
|
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')
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
The if_links.h header exists since back 2012, but the new
ifla_rmnet_flags struct was added only in March 2018 (Linux v4.17).
Setup a configure time check to see if the struct exists in the header
or not, and build rmnet support if so.
Fixes https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/issues/55
|
|
|
|
When using qmi_wwan as backend, there is no guarantee that the link
interface has the new 'qmap/mux_id' property, so there may be no way
to know which mux-id is associated to a given link, and therefore
there wouldn't any way to delete that link, as the 'del_mux' operation
requires the mux-id of the link to delete.
As a fallback, we implement a custom del_all_links() method in this
class, that will just iterate over all possible mux-ids, deleting them
one by one, and ignoring the operation result. The method will succeed
if there are no links listed once the operation has finished.
|
|
This new method allows the user of the library to delete, at once, all
the links found for the given network interface. By default, this
method will iterate over all found links calling
qmi_device_delete_link() for each, with QMI_DEVICE_MUX_ID_UNBOUND as
mux id.
|
|
The new qmi_device_list_links() method allows us to list all links
created from the parent interface.
|
|
This generic method allows us to list all links that have been created
from a base parent interface. The implementation is common for both
rmnet and qmiwwan backends, based on the "upper" links in sysfs.
|
|
|
|
When using the qmi_wwan driver without the new qmap/mux_id sysfs
attribute in the link interface, it is not possible to delete the
interface because the mux id is unknown.
Update the delete_link() method to allow providing a valid mux_id, or
UNBOUND if we want the library to try to find the correct one when
needed.
|
|
We need a way to know whether we can do link management before
attempting to add a new link, because the whole connection logic will
depend on whether we can create those new links or not (e.g. we would
need to bind mux data port and enable QMAP aggregation before creating
the new link)
|
|
formats
E.g. we may want to know in advance if QMAP pass through is supported
or not, before attempting to use it.
|
|
|