- Jul 26, 2016
-
-
Aleksander Morgado authored
-
Aleksander Morgado authored
-
- Jul 25, 2016
-
-
Aleksander Morgado authored
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.
-
Aleksander Morgado authored
-
- Jul 21, 2016
-
-
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.
-
- Jul 20, 2016
-
-
Dan Williams authored
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.
-
Aleksander Morgado authored
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>
-
- Jul 15, 2016
-
-
Aleksander Morgado authored
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.
-
- Jul 14, 2016
-
-
Aleksander Morgado authored
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.
-
- Jul 11, 2016
-
-
Dan Williams authored
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.
-
- Jul 07, 2016
-
-
Aleksander Morgado authored
-
Aleksander Morgado authored
-
Aleksander Morgado authored
-
- Jun 15, 2016
-
-
Dan Williams authored
-
- Jun 01, 2016
-
-
Dan Williams authored
-
Dan Williams authored
-
- May 31, 2016
-
-
Aleksander Morgado authored
-
- May 28, 2016
-
-
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.
-
- May 27, 2016
-
-
Dan Williams authored
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.
-
Dan Williams authored
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
-
Dan Williams authored
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
- May 24, 2016
-
-
Dan Williams authored
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).
-
- May 10, 2016
-
-
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
-
- May 04, 2016
-
-
- May 03, 2016
-
-
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
-
Dan Williams authored
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.
-
- Apr 19, 2016
-
-
Aleksander Morgado authored
The "0" case wasn't being handled properly: $ sudo mmcli -m 0 --create-bearer="apn=,allow-roaming=0" Error parsing properties string: 'Cannot get boolean from string '0''
-
- Apr 18, 2016
-
-
Aleksander Morgado authored
-
Aleksander Morgado authored
-
- Apr 15, 2016
-
-
Dan Williams authored
Hook up to the WDS Packet Service Status indication, listen for disconnection events, and disconnect the bearer when we get one.
-
- Apr 13, 2016
-
-
Aleksander Morgado authored
Tested by: <than@redhat.com> https://bugs.freedesktop.org/show_bug.cgi?id=94777
-
Aleksander Morgado authored
-
- Apr 08, 2016
-
-
Aleksander Morgado authored
When we were completing tasks in idle, the logic was like this: * Schedule task completion in idle * self->priv->task = NULL * (idle) Task completion callback called This meant that the self->priv->task was always set to NULL before the completion callback was called, which is what we wanted as a new task may be scheduled in the callback itself. Now, without completing in idle, we were wrongly doing: * Task completion callback called * self->priv->task = NULL This commit fixes the logic by making sure self->priv->task = NULL before any task completion.
-
- Apr 06, 2016
-
-
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.
-
- Apr 03, 2016
-
-
Aleksander Morgado authored
If systemd is found, enable suspend resume support.
-