| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
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
|
|
Tested by: <than@redhat.com>
https://bugs.freedesktop.org/show_bug.cgi?id=94777
|
|
Initialized "cgmi_retries" variable from CustomInitContext with the
same value as the other retries, moreover the context is now allocated
with g_slice_new0.
Before this changes, when cgmi_retries assumed big values during the
probing of no AT-capable ports, the command AT+CGMI (mm-plugin-dell.c:custom_init_step)
was sent a semi-infinite number of times, blocking the plugin's initialization.
|
|
GCC 6 doesn't like this. Unused since f2024b7.
|
|
We try to combine in common envvars the compiler and linker flags shared by the
different components, and where possible, also re-using the implicit AM_CFLAGS
and AM_LDFLAGS variables that automake provides, and which apply to all objects
being built in the same Makefile.am.
The plugins build rules are also updated so that whenever a plugin has some
testable 'helpers', these are compiled into a noinst library and then the new
library included by both the plugin and the tester program. This avoids multiple
recompilations of the same sources for different objects.
|
|
We try to combine in common envvars the compiler and linker flags shared by the
different components, and where possible, also re-using the implicit AM_CFLAGS
and AM_LDFLAGS variables that automake provides, and which apply to all objects
being built in the same Makefile.am.
The internal libmodem-helpers.la library is also renamed to libhelpers.la
|
|
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
|
|
Based on a previous patch from Dan Williams <dcbw@redhat.com>
|
|
|
|
This patch adds current modes setting in Telit plugin
|
|
|
|
Which actually segfaults, as MMBroadbandModem doesn't implement the
disable_unsolicited_events() method in the voice interface.
|
|
These messages list the emergency numbers reported by the network, we don't use
them yet.
E.g.:
^ECCLIST: 112,911\r\n
|
|
Probe the Thuraya XT modem by USB vendor ID; there are no RS232 versions
to my knowledge.
One of my computers exhibiting the probing issue (VID/PID of the PCI
host controller instead of the USB device) fixed itself after a reboot.
Signed-off-by: Thomas Sailer <t.sailer@alumni.ethz.ch>
|
|
Signed-off-by: Thomas Sailer <t.sailer@alumni.ethz.ch>
|
|
|
|
This patch adds current mode loading in Telit plugin
|
|
This patch add supported modes loading in Telit plugin.
|
|
|
|
|
|
|
|
We now need it for GTask support.
|
|
|
|
Since GLib 2.42, the sockets that are added to socket listeners may no longer
be closed automatically when the listener is finalized. In order to avoid that,
we will keep our own socket reference and close/unref it ourselves.
This issue was preventing adding new test cases with the same port names.
$ ./test-service-generic --verbose
GTest: random seed: R02S889153ee0f2e59c570f4edff9caa4176
GTest: run: /MM/Service/Generic/enable-disable
Activating service name='org.freedesktop.ModemManager1'
Successfully activated service 'org.freedesktop.ModemManager1'
(MSG: DEBUG: client connection closed)
(MSG: MESSAGE: Found modem at '/org/freedesktop/ModemManager1/Modem/0')
** Message: Found modem at '/org/freedesktop/ModemManager1/Modem/0'
(MSG: DEBUG: client connection closed)
GTest: result: OK
GTest: run: /MM/Service/Generic/cme-error-detected
Activating service name='org.freedesktop.ModemManager1'
Successfully activated service 'org.freedesktop.ModemManager1'
(MSG: FATAL-ERROR: Cannot bind socket: Error binding to address: Address already in use)
** (/home/aleksander/Development/foss/ModemManager/plugins/.libs/lt-test-service-generic:32043): ERROR **: Cannot bind socket: Error binding to address: Address already in use
|
|
We were wrongly using a main loop in the port context thread to manage the
global main context. That was silently making the DBus property notifications
kind of work, as they were being updated via another thread, so here we could
just sleep() and recheck the property values.
Given that having that unrelated thread updating the dbus properties of our
MMManager object is not a good thing, we'll instead totally ignore that and
fully re-create the MMManager in each iteration with the sync() method, which
has its own internal thread.
|
|
Instead of creating a new main context to be used in the thread, we were using
the global context. So, fix that, and create a totally new pair of main context
and main loop to be used within the thread.
|
|
We were trying to load the generic modes supported reported by either *CNTI=2 or
AT+WS46=?, so that then we could filter out the MBM-specific modes unsupported.
But, this may not be ideal, as both these two commands may fail:
[mm-broadband-modem.c:1612] modem_load_supported_modes(): loading supported modes...
[mm-port-serial.c:1237] mm_port_serial_open(): (ttyACM1) device open count is 3 (open)
[mm-port-serial.c:1294] _close_internal(): (ttyACM1) device open count is 2 (close)
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): --> 'AT*CNTI=2<CR>'
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): <-- '<CR><LF>ERROR<CR><LF>'
[mm-serial-parsers.c:364] mm_serial_parser_v1_parse(): Got failure code 100: Unknown error
[mm-broadband-modem.c:1546] supported_modes_cnti_ready(): Generic query of supported 3GPP networks with *CNTI failed: 'Unknown error'
[mm-port-serial.c:1237] mm_port_serial_open(): (ttyACM1) device open count is 3 (open)
[mm-port-serial.c:1294] _close_internal(): (ttyACM1) device open count is 2 (close)
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): --> 'AT+WS46=?<CR>'
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): <-- '<CR><LF>ERROR<CR><LF>'
[mm-serial-parsers.c:364] mm_serial_parser_v1_parse(): Got failure code 100: Unknown error
[mm-broadband-modem.c:1494] supported_modes_ws46_test_ready(): Generic query of supported 3GPP networks with WS46=? failed: 'Unknown error'
[mm-iface-modem.c:3974] load_supported_modes_ready(): couldn't load Supported Modes: 'Couldn't retrieve supported modes'
Instead, we'll ask the modem for the list of modes supported, and return that
directly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Found by Jean-Christian de Rivaz
|
|
|
|
This command is sent by Huawei ME909s-120 with firmware 23.613.61.00.00
|
