| Age | Commit message (Collapse) | Author |
|---|
|
Just the same kind of match we use for cdc-wdm devices.
|
|
The rules were matched only against devices with an exact 'tty' subsystem, and
that means that we were not properly adding additional tags on e.g. wwan or
cdc-wdm devices.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
They're actually a subcase of SUBSYSTEM!="usb", which we apply just before.
|
|
|
|
messages
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.
|
|
All "2a03 dog hunter AG" devices seem to be Arduinos.
https://bugzilla.redhat.com/show_bug.cgi?id=1261040
|
|
A short delay is necessary with some SIMs when
they have just been unlocked. Using 1 second as secure margin.
|
|
Inverted steps UPDATE_LOCK_INFO_CONTEXT_STEP_RETRIES and
UPDATE_LOCK_INFO_CONTEXT_STEP_AFTER_UNLOCK.
Soon after the unlock, the SIM can be busy and
loading unlock retries might fail.
When implemented, let run "after unlock" logic before any other step in
update lock info, when SIM is not locked this change does not have any
effect since "after unlock" is not executed.
|
|
|
|
|
|
|
|
PyGIWarning: ModemManager was imported without specifying a version first. Use gi.require_version('ModemManager', '1.0') before import to ensure that the right version gets loaded.
|
|
|
|
We now don't break the strict aliasing rules.
Also, having a compiler flag that disables a warning among the flags that are
meant to add extra sanity checking is not correct either:
--enable-extra-warnings=no would generate a bad aliasin warning while
the --enable-extra-warnings=yes would not.
|
|
We shouldn't be accessiing u_int8_t * as u_int16_t *. Let's construct
the 16-bit value by or-ing the 8-bit halves directly; avoiding the
endianness conversion too.
|
|
Apparently I was looking at this in 2012:
https://blogs.gnome.org/dcbw/2012/11/14/got-evdo-help-me-out/
So why not at least get the structures into libqcdm and figure
out a rough correlation between pilot energy and EC/IO.
|
|
The mm_iface_modem_is_*_only() checks were validating that all the other
capabilities except for the ones being queried were unset, but the check wasn't
explicitly checking that the actual capabilities being queried were set.
This was making the check fail when capabilities == MM_MODEM_CAPABILITY_NONE.
Reported-by: Matthew Stanger <stangerm2@gmail.com>
|
|
Deciding the IP method to use based on the underlying QMI port LLP should not be
done when the bearer object is created, because the QMI port in use may not
actually be open or have been opened at that time. During the connection attempt
we do make sure the QMI port is open, so we should check the LLP to use just
after that step.
|
|
When the logic decided that we had to update the kernel data format to match the
one configured in the WWAN network interface, we were not flagging the port LLP
with the correct value, what resulted in NetworkManager trying to use dhclient
on the raw-ip interface:
dhclient[3257]: Unsupported device type 65534 for "wwan1"
dhclient[3257]:
dhclient[3257]: If you think you have received this message due to a bug rather
dhclient[3257]: than a configuration issue please read the section on submitting
dhclient[3257]: bugs on either our web page at www.isc.org or in the README file
dhclient[3257]: before submitting a bug. These pages explain the proper
dhclient[3257]: process and the information we find helpful for debugging..
dhclient[3257]:
dhclient[3257]: exiting.
Fix the internal LLP flag, so that Static IP addressing is requested for all raw-ip
based interfaces.
|
|
modem response
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.
|
|
|
|
|
|
fails
|
|
|
|
|
|
FAILURE state
|
|
|
|
This patch makes declarations bind to definitions within the same module
to prevent the potential ambiguity if referenced directly.
AddressSanitizer think they violated one definition rule, although
those symbols are accessed by address through their modules and do
not depend on the order of the libararies loaded.
|
|
#95304)
https://bugs.freedesktop.org/show_bug.cgi?id=95302
https://bugs.freedesktop.org/show_bug.cgi?id=95304
|
|
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).
|
|
Otherwise the dangling pointer to the context that's being deallocated causes a
crash on spontaneous E2NAP receipt:
ModemManager[1567]: <info> [1462468083.031326] [mm-iface-modem.c:1431] __iface_modem_update_state_internal(): Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> registered)
ModemManager[1567]: <debug> [1462468083.053745] [mm-port-serial-at.c:459] debug_log(): (ttyACM0): <-- '<CR><LF>*E2NAP: 0,36<CR><LF>'
ModemManager[1567]: <debug> [1462468083.053857] [mbm/mm-broadband-modem-mbm.c:824] e2nap_received(): disconnected
(ModemManager:1567): GLib-GIO-CRITICAL **: g_simple_async_result_set_error: assertion 'G_IS_SIMPLE_ASYNC_RESULT (simple)' failed
Program received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x7ffff7086798 "GLib-GIO", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffcda0) at gmessages.c:1046
1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth));
Missing separate debuginfos, use: debuginfo-install libmbim-1.12.4-2.el7.centos.x86_64 libqmi-1.14.2-1.el7.centos.x86_64
(gdb) bt
#0 0x00007ffff6a508c3 in g_logv (log_domain=0x7ffff7086798 "GLib-GIO", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffcda0) at gmessages.c:1046
#1 0x00007ffff6a50a3f in g_log (log_domain=log_domain@entry=0x7ffff7086798 "GLib-GIO", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff6abe73d "%s: assertion '%s' failed") at gmessages.c:1079
#2 0x00007ffff6a50a79 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7ffff7086798 "GLib-GIO", pretty_function=pretty_function@entry=0x7ffff7092ce0 <__FUNCTION__.13394> "g_simple_async_result_set_error", expression=expression@entry=0x7ffff7092a40 "G_IS_SIMPLE_ASYNC_RESULT (simple)") at gmessages.c:1088
#3 0x00007ffff6ff9d3d in g_simple_async_result_set_error (simple=0x7fffe8006e40, domain=297, code=0, format=0x7ffff175b53f "Call setup failed") at gsimpleasyncresult.c:719
#4 0x00007ffff17569ea in report_connection_status (bearer=0x7fffe4008a40 [MMBroadbandBearerMbm], status=MM_BEARER_CONNECTION_STATUS_DISCONNECTED) at mbm/mm-broadband-bearer-mbm.c:174
#5 0x000055555559c9f1 in mm_base_bearer_report_connection_status (self=0x7fffe4008a40 [MMBroadbandBearerMbm], status=MM_BEARER_CONNECTION_STATUS_DISCONNECTED) at mm-base-bearer.c:1118
#6 0x00007ffff17548ed in bearer_list_report_status_foreach (bearer=0x7fffe4008a40 [MMBroadbandBearerMbm], ctx=0x7fffffffd060) at mbm/mm-broadband-modem-mbm.c:805
#7 0x00007ffff6a45f18 in g_list_foreach (list=<optimized out>, func=0x7ffff17548c9 <bearer_list_report_status_foreach>, user_data=0x7fffffffd060) at glist.c:994
#8 0x00005555555a224b in mm_bearer_list_foreach (self=0x5555558e0680 [MMBearerList], func=0x7ffff17548c9 <bearer_list_report_status_foreach>, user_data=0x7fffffffd060) at mm-bearer-list.c:146
#9 0x00007ffff1754a3d in e2nap_received (port=0x5555558e24c0 [MMPortSerialAt], info=0x555555935730, self=0x555555900330 [MMBroadbandModemMbm]) at mbm/mm-broadband-modem-mbm.c:850
#10 0x000055555563d9fd in parse_unsolicited (port=0x5555558e24c0 [MMPortSerialAt], response=0x7fffe80054f0) at mm-port-serial-at.c:280
#11 0x0000555555639915 in parse_response_buffer (self=0x5555558e24c0 [MMPortSerialAt]) at mm-port-serial.c:889
#12 0x0000555555639f0b in common_input_available (self=0x5555558e24c0 [MMPortSerialAt], condition=G_IO_IN) at mm-port-serial.c:1019
#13 0x0000555555639fc7 in iochannel_input_available (iochannel=0x555555926df0, condition=G_IO_IN, data=0x5555558e24c0) at mm-port-serial.c:1042
#14 0x00007ffff6a4979a in g_main_context_dispatch (context=0x5555558a4a00) at gmain.c:3109
#15 0x00007ffff6a4979a in g_main_context_dispatch (context=context@entry=0x5555558a4a00) at gmain.c:3708
#16 0x00007ffff6a49ae8 in g_main_context_iterate (context=0x5555558a4a00, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3779
#17 0x00007ffff6a49dba in g_main_loop_run (loop=0x5555558acf10) at gmain.c:3973
#18 0x000055555558d068 in main (argc=2, argv=0x7fffffffdc38) at main.c:181
(gdb)
https://bugzilla.redhat.com/show_bug.cgi?id=1333293
https://bugs.freedesktop.org/show_bug.cgi?id=95303
|
|
|
|
This patch adds section for building Telit common code and modifies
Dell section for using Telit library
|
|
udev rules for Dell-branded 413c/81ba Telit modem are used for dynamic
port configuration in Telit plugin custom init
|
|
Dell-branded AT based Telit modems should use Telit plugin functions
|
|
This patch moves init and port grabbing functions to a separate file
to allow functions call from Dell plugin
|
