Running NDISDUP=1,0 on an already disconnected bearer/context will
report ERROR, so we can really ignore the result of the command,
because we're anyway going to get the correct bearer/context status
later on with the NDISSTATQRY checks.
When a network-initiated event is received telling us that a
bearer/context is disconnected, we should handle and process it right
away, without thinking on whether there is going to be a
user-requested disconnect afterwards or not.
This effectively reverts the changes introduced in commit
21a5aaf4fe, which looks like was done to
handle synchronization issues with upper layers (e.g. with
NetworkManager or Shill).
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/205
We can safely cast the data in a GArray to gpointer first, and then
to the pointer type we require.
huawei/mm-broadband-modem-huawei.c: In function 'set_current_bands':
huawei/mm-broadband-modem-huawei.c:916:50: error: cast increases required alignment of target type [-Werror=cast-align]
bands_string = mm_common_build_bands_string ((MMModemBand *)bands_array->data,
^
E.g. do nothing if the response is empty:
<debug> (ttyUSB1): -->'AT^GETPORTMODE<CR>'
<debug> (ttyUSB1): <--'<CR><LF>^GETPORTMODE: TYPE: WCDMA: Huawei Technologies Co.,Ltd.,<CR><LF><CR><LF>OK<CR><LF>'
So far, we're really only interested in the "modem" and "pcui" ports.
root@9d52738:/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4# find . -name interface|sort
./1-1.4:2.0/interface
./1-1.4:2.1/interface
./1-1.4:2.2/interface
./1-1.4:2.3/interface
./1-1.4:2.4/interface
./1-1.4:2.5/interface
./1-1.4:2.6/interface
root@9d52738:/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4# find . -name interface|sort|xargs cat
CDC Ethernet Control Model (ECM)
CDC Ethernet Data
Huawei Mobile Connect - Modem
Huawei Mobile Connect - Application
Huawei Mobile Connect - Pcui
Huawei Mobile Connect - Ctrl
Huawei Mobile Connect - Serial B
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/170
It has the same exact format as MMBaseModemAtCommand, but its contents
are assumed heap allocated.
The only real purpose of this type is to allow defining static
constant MMBaseModemAtCommand variables without warnings when using
-Wdiscarded-qualifiers.
huawei/mm-broadband-bearer-huawei.c: In function ‘connect_3gpp_context_step’:
huawei/mm-broadband-bearer-huawei.c:378:18: error: this statement may fall through [-Werror=implicit-fallthrough=]
378 | ctx->step++;
| ~~~~~~~~~^~
huawei/mm-broadband-bearer-huawei.c:382:5: note: here
382 | case CONNECT_3GPP_CONTEXT_STEP_NDISDUP: {
| ^~~~
huawei/mm-broadband-bearer-huawei.c: In function ‘disconnect_3gpp_context_step’:
huawei/mm-broadband-bearer-huawei.c:708:18: error: this statement may fall through [-Werror=implicit-fallthrough=]
708 | ctx->step++;
| ~~~~~~~~~^~
huawei/mm-broadband-bearer-huawei.c:711:5: note: here
711 | case DISCONNECT_3GPP_CONTEXT_STEP_NDISDUP:
| ^~~~
huawei/mm-broadband-modem-huawei.c: In function ‘huawei_hcsq_changed’:
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_UNKNOWN’ not handled in switch [-Werror=switch-enum]
1816 | switch (act) {
| ^~~~~~
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_POTS’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_GSM_COMPACT’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_GPRS’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_EDGE’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_HSDPA’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_HSUPA’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_HSPA’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_HSPA_PLUS’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_1XRTT’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_EVDO0’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_EVDOA’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_EVDOB’ not handled in switch [-Werror=switch-enum]
huawei/mm-broadband-modem-huawei.c:1816:5: error: enumeration value ‘MM_MODEM_ACCESS_TECHNOLOGY_ANY’ not handled in switch [-Werror=switch-enum]
Useful when clamping a unsigned integer with low threshold set to 0,
which would give us compiler warnings with -Wtype-limits when using
CLAMP(), e.g.:
via/mm-broadband-modem-via.c: In function ‘handle_evdo_quality_change’:
/usr/include/glib-2.0/glib/gmacros.h:811:63: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
811 | #define CLAMP(x, low, high) (((x) > (high)) ? (high) : (((x) < (low)) ? (low) : (x)))
| ^
via/mm-broadband-modem-via.c:284:19: note: in expansion of macro ‘CLAMP’
284 | quality = CLAMP (quality, 0, 100);
| ^~~~~
huawei/mm-modem-helpers-huawei.c: In function ‘parse_mode_combination_string’:
huawei/mm-modem-helpers-huawei.c:991:20: error: this statement may fall through [-Werror=implicit-fallthrough=]
991 | *preferred = MM_MODEM_MODE_NONE;
| ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
huawei/mm-modem-helpers-huawei.c:993:5: note: here
993 | default:
| ^~~~~~~
huawei/mm-modem-helpers-huawei.c: In function ‘mm_huawei_parse_prefmode_response’:
huawei/mm-modem-helpers-huawei.c:550:18: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘const unsigned int’} [-Werror=sign-compare]
550 | if (mode == combination->prefmode)
| ^~
USB sticks only support voice if ^CVOICE returns 0. And to enable audio
streaming on the "Application" port (whatever is returned by AT^DDSETEX=?)
we need to send AT^DDSETEX=<port> after starting the call. After that
the serial port will send and accept signed 16-bit 8000hz PCM audio, or
whatever format is returned by ^CVOICE?.
This patch is a rework of the original implementation by:
Dan Williams <dcbw@redhat.com>
Calls created from property bundles are always outgoing, while calls
created as input events from URCs during runtime are always incoming.
This change makes it mandatory to provide at least direction of the
call when the object is created, leaving the number as an optional
property that may or may not be known in advance (e.g. it would be
optional only for incoming calls).
Instead of handling the URCs in the modem object and using the
MMIfaceModem as a bridge to report the status read from the URC to a
call obtained from the MMCallList... just handle the URCs in the call
object itself.
In order to detect state changes while we're in-call, we have to
monitor the standard connection errors we're used to, but have them
processed as URCs instead of as responses to ATD requests.
The most detailed call state transition flow for a new outgoing call
would be:
UNKNOWN -> DIALING -> RINGING -> ACTIVE
But, if the modem doesn't support reporting intermediate states
(e.g. DIALING or RINGING) then a successful start() should imply
getting into ACTIVE state right away.
For now, only the Huawei plugin implements the detailed transition
support, so make them configurable via call object properties.
We keep the pflags input in mm_base_modem_grab_port() so that plugins
can use other methods to gather port type hints (e.g. querying with AT
commands as in Huawei/Telit or looking at sysfs properties as in HSO).
For standard udev tag port type hints, it will be the base modem
looking them up.
Note that there is no longer any need to ignore non-flagged ports for
those modems that require primary/secondary flags. They will be
implicitly ignored when mm_base_modem_organize_ports() decides which
ports to use, as the flagged ones are preferred over the non-flagged
ones.
We define 3 common udev tag ids to be used by all plugins:
* ID_MM_PORT_TYPE_AT_PRIMARY: the primary modem port. It will be used
for AT control and also as PPP if there is no other port flagged
explicitly to do PPP.
* ID_MM_PORT_TYPE_AT_SECONDARY: the secondary modem port. It will be
used when/if the primary port gets connected to do PPP.
* ID_MM_PORT_TYPE_PPP: the port to be used to do PPP only. This tag
makes sense only when the primary port shouldn't be used for PPP,
i.e. when there is a port dedicated to do PPP and one port
dedicated for control.
When a new USB device is hotplugged, e.g. a USB<->RS232 converter that
exposes a single ttyUSB0, these udev events happen:
add /devices/pci0000:00/0000:00:14.0/usb2/2-1 (usb/usb-device)
add /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 (usb/usb-interface)
add /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0 (usb-serial)
add /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0/tty/ttyUSB0 (tty)
bind /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0 (usb-serial)
bind /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 (usb/usb-interface)
bind /devices/pci0000:00/0000:00:14.0/usb2/2-1 (usb/usb-device)
Our udev rules in MM only added tags in the 'add' events, and it looks
like the only ones 'persistent' after this sequence are those of the
last event happening on the specific path.
This meant that all TTY subsystem rules (e.g. ID_MM_CANDIDATE) would
be stored for later check (e.g. if ModemManager is started after these
rules have been applied), which was ok. "udevadm info -p ..." would
show these tags correctly always.
But this also meant that the 'bind' udev event happening for the USB
device didn't get any of our device-specific tags, and so we would be
missing them (e.g. ID_MM_DEVICE_MANUAL_SCAN_ONLY) if MM is started
after the last event has happened. "udevadm info -p ..." would
not show these tags.
Modify all our rules to also run at the 'bind' events.
See, for context:
https://github.com/systemd/systemd/issues/8221
Keeps build with GCC 8 happy.
mm-base-call.c:758:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
mm-base-call.c:822:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
mm-base-sms.c:908:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
mm-sms-list.c:331:25: warning: variable 'ctx' set but not used [-Wunused-but-set-variable]
mm-iface-modem-messaging.c:1210:21: warning: variable 'storage_ctx' set but not used [-Wunused-but-set-variable]
huawei/mm-plugin-huawei.c:183:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
ublox/mm-plugin-ublox.c:161:24: warning: variable 'response' set but not used [-Wunused-but-set-variable]
ublox/mm-plugin-ublox.c:159:24: warning: variable 'ctx' set but not used [-Wunused-but-set-variable]
icera/mm-modem-helpers-icera.c:218:25: warning: variable 'first_free' set but not used [-Wunused-but-set-variable]
novatel/mm-common-novatel.c:50:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
On Huawei ME936, the hex numbers in the response to AT^DHCP contain the 0x prefix, e.g.
AT^DHCP?
^DHCP: 0xda7d0e0a,0xff000000,0xdb7d0e0a,0xdb7d0e0a,0x01261aac,0x00000000,100000000,50000000
This patch updates mm_huawei_parse_dhcp_response() to handle the
optional 0x prefix.
Aleksander Morgado
Louis-Alexis Eyraud
Murithi Borona
Ben Chan
Lubomir Rintel