The WMC protocol was only present on older Panasonic/Verizon devices
from the 2006 - 2011 timeframe. The last device to support WMC was
the UML290 which also supported QMI (which is much more functional).
ModemManager also never used WMC support and it was never significantly
reverse engineered.
So remove WMC code from git; it'll still be in the history if anyone
cares in the future.
By default the build used -Wno-unused-but-set-variable but that's
clearly not what we want. Fix those problems.
When using clang, the compiler doesn't error on unknown compile
options, so let's add -Werror to the checking too.
CC='clang'
configure:3408: checking for gcc
configure:3435: result: clang
...
configure:17644: checking whether gcc understands -Wno-unused-but-set-variable
configure:17657: clang -c -Wall -std=gnu89 -g -O2 -Wmissing-declarations -Wmissing-prototypes -Wdeclaration-after-statement -Wstrict-prototypes -Wno-unused-parameter -Wno-sign-compare -Wno-deprecated-declarations -Wno-unused-but-set-variable conftest.c >&5
warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
1 warning generated.
configure:17657: $? = 0
configure:17666: result: yes
Reported-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
nozomi and qcaux only drive modems and thus should be included
in this filter rule. Allows nozomi/qcaux devices to work
automatically with strict filter mode.
In mm_iface_modem_3gpp_register_in_network() when deciding whether to
force automatic registration or not, check whether the modem is already
registered in a network. Just checking whether we have a valid operator
code is not sufficient, as some modems (ublox Toby R2xx) don't always
return an operator name/code even when registered.
When the Ericsson F5321 with firmware R3C11/R4D04 is told to make
an IPv6-only connection, it reports that it has IPv4 configuration
but then returns no actual addresses. Check both the flags and
actual data before trying to use them.
ModemManager[25850]: <debug> [1506958721.914717] IPv4 configuration available: 'address, gateway, dns, mtu'
ModemManager[25850]: <debug> [1506958721.914731] IP addresses (0)
ModemManager[25850]: <debug> [1506958721.914741] DNS addresses (0)
ModemManager[25850]: <debug> [1506958721.914748] MTU: '0'
ModemManager[25850]: <debug> [1506958721.914758] IPv6 configuration available: 'address, dns, mtu'
ModemManager[25850]: <debug> [1506958721.914767] IP addresses (1)
ModemManager[25850]: <debug> [1506958721.914852] IP [0]: 'fe80::39:f622:7d01/64'
ModemManager[25850]: <debug> [1506958721.914866] DNS addresses (2)
ModemManager[25850]: <debug> [1506958721.914883] DNS [0]: 'fd00:976a::9'
ModemManager[25850]: <debug> [1506958721.914896] MTU: '1500'
ModemManager[25850]: <debug> [1506958721.914947] (wwp0s20u1i6): port now connected
Allocate the results instead of passing them back on the stack, which removes
the "can't complete in idle" restriction. Also always open the QCDM port
since we can't assume it will be open already at this point.
Instead of mixing the QCDM Novatel Snapshot code directly into the
access technology checking code, split it out with its own async
result. At the same time, make sure to open the QCDM port when
it's needed, instead of assuming its already open. Since it won't
always be.
Looks like a C&P error from the AT#PSNT codepath; all the docs
I can find indicate that AT+SERVICE returns only an integer and
no commas:
<debug> (ttyUSB2): --> 'AT+SERVICE?<CR>'
<debug> (ttyUSB2): <-- '<CR><LF>+SERVICE: 3<CR><LF><CR><LF>OK<CR><LF>'
<debug> Couldn't refresh access technologies: 'Failed to parse +SERVICE response: '+SERVICE: 3''
Two issues here:
1) PCH_SLEEP wasn't considered a "wcdma_open" state, but it should be
since the modem is still registered and can be attached in this state
2) If the system mode is WCDMA (eg, not GSM and not GSM/WCDMA) then
MM shouldn't assume GPRS if WCDMA isn't "open", since GPRS isn't
enabled in WCDMA-only mode
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=100000
The enum was wrong. There isn't actually an L1M_INIT state; the
enum should start with L1M_IDLE. There should also be a
L1M_PCH_SLEEP state between DEACTIVATE and DEEP_SLEEP.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=100000
<debug> (ttyUSB2): --> 'AT^SYSCFG?<CR>'
<debug> (ttyUSB2): <-- '<CR><LF>^SYSCFG:14,2,400380,1,2<CR><LF><CR><LF>OK<CR><LF>'
<warn> couldn't load current allowed/preferred modes: 'No SYSCFG combination found matching the current one (14,2)'
14,2 means "WCDMA-only; acquire WCDMA then GSM" which is somewhat
non-sensical. The supported modes parsing doesn't generate this
combination because it doesn't really make sense, so current mode
matching failed. Just fix up the non-sensical acquisition order
to 0 (automatic).
Implement the detailed signal info interface for some Huawei 3GPP modems
including those based on HiSilicon chipsets like the E3276. Known not to
work on many Qualcomm-based Huawei modems like E392, E397, and E367 as
they don't support the ^HCSQ command, but they do support QMI and so
have access to the extended signal interface via QMI.
When a CDMA-only modem is registered with the EVDO network, its not possible to
read signal strength in the following cases:
1) while a data connection is active on single-AT-port modems, because the AT
port is used for PPP and not available for AT+CSQ, AT+CIND or vendor-specific
signal strength commands
2) when the modem reports only CDMA 1x signal strength with AT+CSQ
Now that we have a reasonable interpretation of RSSI from the QCDM
EVDO Pilot Sets V2 log messgae, use that when other means of getting
signal strength aren't available.
MM never passes MBIM_CONTEXT_IP_TYPE_DEFAULT which would require paying
attention to the ip_type in the reply to figure out what type the modem
activated. Instead, MM always specifies the ip_type it wants to activate,
and some modems (K5160) return a different type in the response. The modem
is required to activate the type MM asks for or return an error, so if
the activation was successful we can safely assume the modem activated
the ip_type we want, and we can ignore the ip_type in the response.
Otherwise we may leave a bearer connected when ModemManager doesn't
think it's connected. Prevents a CME ERROR 277 loop on connect when
the bearer hasn't been torn down correctly.
Wait for either an E2NAP unsolicited disconnect status or (for older
devices) an ENAP poll response before completing the disconnect.
Otherwise the client may start connecting again (such as
NetworkManager autoconnect retry) and the unsolicited E2NAP may
abort it, or the modem may return CME ERROR 277 ("not disconnected
yet") for the next connection attempt.
https://bugs.freedesktop.org/attachment.cgi?id=123525
There are a few key parts to this patch:
1) move the poll id into the Dial3gppContext structure as it is
conceptually part of the connection context data. This simplifies
context cleanup by keeping the poll id cleanup in one place.
2) move unsolicited connection status (E2NAP) handling into the
normal connection codepath, instead of completing the connection
context from the report_connection_status() E2NAP handler. This
simplifies connect code by not requiring checks for a NULL context
everywhere, and allows us to pass the Dial3gppContext structure
around instead of the Bearer object, since the Dial3gppContext
will never be comleted/freed outside the normal connection flow
codepaths like GLib idles and AT command requests.
3) use the connect context cancellable for all AT command requests
in the connect path. This lets us use the error return from
mm_base_modem_at_command_full_finish() to handle cancellation and
also not bother listening to the 'cancelled' signal of the
cancellable, since we can just check for cancellation the next time
the ENAP poll function runs.
https://bugs.freedesktop.org/show_bug.cgi?id=95304
If the modem thinks a PDP context is already active it'll return
583 errors from IPDPCFG and IPDPACT until the context is
deactivated. Deactivation was previously done after authentication,
but needs to be done before any part of the connect process to
ensure the PDP context is inactive.
The previous approach worked only if the context was being
deactivated already (which can take a bit of time) because it would
be deactivated after a few seconds and the connect could continue.
This approach works for more cases (like a MM crash and restart
while the modem is connected).
v4: modems/providers may not return DNS servers and not all modems
support DHCP, so lack of DNS servers should not indicate a bearer
IP method of "DHCP". IP config daemon/scripts already have to handle
missing DNS anyway.
v6: IPv6 requires SLAAC or DHCPv6 as part of the specification, so for
now we assume modems will support it. Provide all the info the modem
sent, but if there is any missing information use an IP method of
"DHCP" to indicate that info should be obtained via SLAAC/DHCPv6. Only
use an IP method of "STATIC" when all basic properties are given by
the modem.
make distcheck runs a build in dist directory subtirs and then runs intltool -m
which in turn complains about translations in a built file:
The following files contain translations and are currently not in use. Please
consider adding these to the POTFILES.in file, located in the po/ directory.
sub/data/org.freedesktop.ModemManager.policy.in
The issue is reported to intltool upstream already:
https://bugs.launchpad.net/intltool/+bug/1117944
For non-QMI/non-MBIM Huawei devices that use HiSense chipsets,
the recommended way to create the connection is to use NDISDUP
and either DHCP on the net interface, or the ^DHCP command.
There are some reports of devices that connect successfully, but
don't respond to DHCP requests on the interface. Try to get
IP addressing info from the device via ^DHCP and fall back to
telling clients to use actual DHCP if that fails.
https://bugzilla.redhat.com/show_bug.cgi?id=1254886
A Huawei E173 (with FW 11.126.15.00.445) seems to stop responding on the
primary port (ttyUSB2) when the CGACT is resent on the data port (ttyUSB0).
The CGACT-on-data-port was originally added as a fallback attempt to get
single-port modems to disconnect when all other methods failed.
For single-port modems, the primary port is also the data port so this
patch will have no effect.
For multi-port modems, this patch will retry the CGACT on the primary
port which has a higher chance of success because we already know
the primary port is talking to us, while the data port may still
be stuck in PPP mode.
CDMA-capable modems (like a Sierra EM7355) will fail to even enable,
because the internal CDMA code tries to initialize using AT commands and
that fails because many MBIM modems don't have an AT port. We should
figure out how to support minimal MBIM + CDMA using MBIM instead of
AT-anything.
[mm-broadband-modem.c:9000] enabling_step(): Modem has CDMA capabilities, enabling the Modem CDMA interface...
[mm-iface-modem-cdma.c:946] mm_iface_modem_cdma_run_registration_checks(): Running registration checks (CDMA1x: 'yes', EV-DO: 'yes')
[mm-broadband-modem.c:7397] setup_registration_checks_context_complete_and_free(): Will skip all QCDM-based registration checks
[mm-broadband-modem.c:7418] setup_registration_checks_context_complete_and_free(): Will skip generic detailed registration check, we don't have Sprint commands
[mm-iface-modem-cdma.c:768] registration_check_step(): Starting QCDM-based registration checks
[mm-iface-modem-cdma.c:780] registration_check_step(): Skipping all QCDM-based checks and falling back to AT-based checks
[mm-iface-modem-cdma.c:823] registration_check_step(): Starting AT-based registration checks
[mm-iface-modem-cdma.c:641] get_service_status_ready(): Could not get service status: No AT port available to run command
[mm-iface-modem.c:1392] __iface_modem_update_state_internal(): Modem /org/freedesktop/ModemManager1/Modem/0: state changed (enabling -> disabled)
When passing known_lock=UNKNOWN to mm_iface_modem_update_lock_info()
we actually do want to ask the modem itself for locks instead of
checking the cache. For example, when an unknown error is returned
after performing PIN/PUK operations, the cache value may well be
NONE if that was the prior lock state, and that bypasses the modem
which might now be locked. Thus the state gets messed up.
Reproducer is to send 'ChangePin' with the wrong "old" PIN 3 times,
then send a wrong PUK. No error was returned from mmcli and
the modem's lock state was shown as 'none'.
This message gets printed for all netdevs and ttys, including most
machines normal ethernet/Wi-Fi interfaces. It seems a bit less critical
than 'warning' level would indicate.
ModemManager[32097]: <warn> Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:19.0': not supported by any plugin
ModemManager[32097]: <warn> Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0': not supported by any plugin
MM probing appears to make 'visor' module die; and anyway
most of the devices driven by 'visor' are not phones, and
of the 3 that are phones they are so old (2002 - 2005 era)
that nobody is likely using them for dialup anymore.
http://www.spinics.net/lists/linux-usb/msg120483.html
b28230411 moved up the self->priv->forced_close = TRUE, which
caused mm_port_serial_close() to just return without actually
closing the port and cleaning up.
Also, cancel the reopen separately from closing the port since
the two operations are actually independent of each other.
Some newer modems (Huawei E1750, Sierra 73xx) provide what looks like
legitimate static IPv4 configuration through the WDSGetCurrentSettings
call, but when configured the interface does not pass traffic. Running
DHCP on the same interface provides a slightly different IPv4
configuration but does allow traffic to pass.
Since QMI was switched to static originally for consistency with IPv6
and for speed of IP configuration (since DHCP takes a bit of time), but
not for any known problems with modems, let's switch back to DHCP until
we have time to figure out what's actually going on.
We have a report of a modem that switches access technologies frequently,
in this case almost every 10 seconds. While that's unusual, it's not
unexpected depending on the RF environment. We shouldn't spam syslog
with that info; if we need it we can get it with mmcli.
Notable changes include reporting all available IP configruation
information in the bearer IP details, even if the method is DHCP,
in which case the client should apply the given configuration and
then proceed with DHCP/PPP/SLAAC/etc addressing mechanisms.
QMI, MBIM, and some other plugins have been switched to the "STATIC"
configuration method from DHCP when the firmware supplies all the
necessary details.
Even if the IPv6 bearer method is DHCP, the client should use SLAAC
(eg, IPv6 Router Solicitations, Router Adverisements, and possibly
DHCPv6) to determine the correct prefix and DNS information. In
some cases, even with the DHCP method, and IPv6 "address" will be
given which should be assigned to the data port before beginning
an IP addressing as the mobile network may expect this address
to be used.
Devices with Icera chipsets (USB305) don't support the Qualcomm
proprietary $QCPDPP command, and we must use the Icera command
instead. Otherwise authenticated bearer creation will fail.
Split out the %IPDPADDR parsing into a helper and add testcases for it,
and add support for IPv6 handling. If the returned IPv6 is link-local,
the address should be assigned to the interface and SLAAC performed to
retrieve the actual IPv6 prefix and RDNSS/DNSSD information.
Subclasses may need to know which IP families were used for the setup
so they can return the correct IP configuration. We can't just use
the MMBearer default_ip_family becuase that isn't the family that
was actually used during the connection.
MMBroadbandModemSierraIcera is not a subclass of
MMBroadbandModemSierra, so we cannot cast it to that type when
passing it to bearer creation. Luckily the bearer doesn't
care, so just downgrade the type to MMBroadbandModem.
We can use these to return better error messages if an operator
does not support the default subscription APN functionality,
and the user does not give us an APN.
If the APN was empty (implying that the modem/network should choose
the default APN) this caused an assertion in libqmi. Just don't
set an APN if we aren't given one.
ensure_internal_ports() didn't deep-copy the ports array, which
meant that anything calling mm_modem_port_info_array_free() was
freeing the internal memory owned by MMModem if it retrieved
the array with mm_modem_get_ports().
https://bugzilla.gnome.org/show_bug.cgi?id=724900
At some point rfcomm serial ports stopped having parents in sysfs,
so checks to get the physical device fail because the rfcomm port
is /sys/devices/virtual/rfcommX and has no parents. So we have
to fall back on checking the interface name.
On at least the EC168C, various unsolicited responses like RSSILVL,
HRSSILVL, and MODE can include an extra Carriage Return:
^MODE: 2<CR><CR><LF><CR><CR><LF>
^RSSILVL:60<CR><CR><LF><CR><CR><LF>
If the bearer doesn't have one of IPv4 or IPv6 configuration, then the
qmi_message_wds_get_current_settings_output_get_ip*_address() functions
will return FALSE with a filled error, which was not cleared.
This fixes a glib warning message about overwriting an already-filled
GError.
Instead of using the NO_NETWORK error, which is only ever read
internally by ModemManager and not very useful when reading quality,
just report signal quality as zero. Before MM 1.0, the signal quality
could be explicitly requested by clients, so the NO_NETWORK error was of
some use, but now that the quality is updated automatically by MM and is
a property instead of a D-Bus method call, the error is pointless.
See commit c79d266e62.
If the rules to tag specific USB interface numbers only apply on the PID, we'll
end up seeing that if the port has a parent with another PID, and that other
PID also has a rule, port will get tagged multiple times.
Dan Williams