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>
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.
Adding dynamic port identification for Telit modems that support AT#PORTCFG
command. Port configurations for HE910/UE910/UL865 taken from document
"HE910/UE910/UL865 Families Ports Arrangements User Guide"
