aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2013-04-18core: rework logging code to remove log message truncation (bgo #698312)MM_06Dan Williams
Use a static GString which will resize itself if the log message is bigger than the current string size, but will also ensure we don't do a ton of memory reallocation on every log message. Previously all log messages were trucated at 512 bytes due to the log buffer char array being 512 bytes long.
2013-04-17qcdm: fix CDMA1x Pilot Sets pilot handlingDan Williams
The helper functions got the return code of qcdm_result_* wrong and thus failed all requests for pilot sets.
2013-04-09core: fix mixup of signal handler disconnect vs. GSource removalDan Williams
Could cause memory corruption, though it was usually only noticed when MM was quitting.
2013-04-08blacklist: ignore a few more Arduinos (rh #861620)Dan Williams
2013-04-04blacklist: ignore Arduino devicesAleksander Morgado
https://bugs.launchpad.net/bugs/910736 https://bugs.launchpad.net/bugs/1153632
2013-04-04mbm: ignore *ESTKSMS unsolicited messagesAleksander Morgado
https://bugzilla.gnome.org/show_bug.cgi?id=697280
2013-04-04mbm: remove connection attempt check poll explicitly when connectedAleksander Morgado
Completing a MMCallbackInfo is done asynchronously (in an idle), which means that we may get the poll timeout called in between... [mm-at-serial-port.c:334] debug_log(): (ttyACM0): --> 'AT*ENAP?<CR>' [mm-at-serial-port.c:334] debug_log(): (ttyACM0): <-- '<CR><LF>*ENAP:2,""<CR><LF>' [mm-at-serial-port.c:334] debug_log(): (ttyACM0): <-- '<CR><LF>OK<CR><LF>' [mm-at-serial-port.c:334] debug_log(): (ttyACM0): --> 'AT*ENAP?<CR>' [mm-at-serial-port.c:334] debug_log(): (ttyACM0): <-- '<CR><LF>*ENAP:2,""<CR><LF>' [mm-at-serial-port.c:334] debug_log(): (ttyACM0): <-- '<CR><LF>OK<CR><LF>' [mm-at-serial-port.c:334] debug_log(): (ttyACM0): <-- '<CR><LF>*E2NAP: 1<CR><LF>' [mm-modem-mbm.c:703] mbm_e2nap_received(): connected [mm-port.c:181] mm_port_set_connected(): (wwan0): port now connected [mm-modem.c:764] mm_modem_set_state(): Modem /org/freedesktop/ModemManager/Modems/0: state changed (connecting -> connected) [mm-at-serial-port.c:334] debug_log(): (ttyACM0): <-- '<CR><LF>*ERINFO: 1,0,3<CR><LF>' [mm-generic-gsm.c:6215] simple_state_machine(): (wwan0): simple connect state 6 [mm-at-serial-port.c:334] debug_log(): (ttyACM0): --> 'AT*ENAP?<CR>' [mm-at-serial-port.c:334] debug_log(): (ttyACM0): <-- '<CR><LF>*ENAP:1,""<CR><LF>' [mm-at-serial-port.c:334] debug_log(): (ttyACM0): <-- '<CR><LF>OK<CR><LF>' modem-manager[12699]: mm_callback_info_schedule: assertion `info->called == FALSE' failed
2013-03-26core: show simple connect state as string for debuggingThomas Bechtold
2013-03-26sms-utils: use correct printf modifier for gsizeThomas Bechtold
2013-03-13blacklist: ignore West Mountain radio devicesAleksander Morgado
https://bugs.launchpad.net/bugs/1154654
2013-03-12build: distribute autogen.shDan Williams
2013-03-12zte: add port type hints for the ZTE MF195Aleksander Morgado
https://bugzilla.gnome.org/show_bug.cgi?id=691480
2013-03-04sierra: add MC8790 to APP1 PPP whitelistGerald Richter
2013-02-27udev: update all udev rules to always match both VID/PID togetherAleksander Morgado
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. Easier to see with an example: The ZTE MF637 (VID 0x19D2, PID 0x0121) had the following rules: ATTRS{idProduct}=="0121", ENV{.MM_USBIFNUM}=="04", ENV{ID_MM_ZTE_PORT_TYPE_MODEM}="1" ATTRS{idProduct}=="0121", ENV{.MM_USBIFNUM}=="01", ENV{ID_MM_ZTE_PORT_TYPE_AUX}="1" In our ZTE rules we also have some for the device with PID 0x0002, like: ATTRS{idProduct}=="0002", ENV{.MM_USBIFNUM}=="02", ENV{ID_MM_ZTE_PORT_TYPE_MODEM}="1" ATTRS{idProduct}=="0002", ENV{.MM_USBIFNUM}=="04", ENV{ID_MM_ZTE_PORT_TYPE_AUX}="1" And it seems that we can grab multiple PIDs from a single port, i.e. from the parent objects in the hierarchy: udevadm info -a -n /dev/ttyUSB4 | grep idProduct ATTRS{idProduct}=="0121" ATTRS{idProduct}=="0020" ATTRS{idProduct}=="0002" Where that 0x0002 idProduct is not from the modem, but from the EHCI Host Controller (with idVendor 0x1d6b in my case). So... we end up seeing that both set of rules will apply to the ports, and we misleadingly get: (ttyUSB3) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 ZTE: AT port 'tty/ttyUSB2' flagged as primary (ttyUSB2) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 ZTE: AT port 'tty/ttyUSB1' flagged as secondary (ttyUSB1) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 ZTE: AT port 'tty/ttyUSB4' flagged as primary b_port(): (ttyUSB4) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB2 at (primary) (/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB1 at (secondary) (/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB2 data (primary) (/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB0 qcdm Which is wrong, as ttyUSB4 should have been our primary port, not ttyUSB2. With this patch on, the rules apply only to the VID/PID pair, and we end up getting what we really wanted: (ttyUSB3) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (ttyUSB2) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 ZTE: AT port 'tty/ttyUSB1' flagged as secondary (ttyUSB1) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 ZTE: AT port 'tty/ttyUSB4' flagged as primary b_port(): (ttyUSB4) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB4 at (primary) (/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB1 at (secondary) (/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB4 data (primary) (/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB0 qcdm https://bugzilla.gnome.org/show_bug.cgi?id=694759
2013-02-20gsm,cdma: don't reset connected state if disconnecting failsDan Williams
If disconnecting fails, we can't be sure we're not still connected, which is why previously MM reset the CONNECTED state. However, this behavior in conjunction with 27408b4c1e13e3016a01e5b273e66d99f487d3ad caused ModemManager not to recognize that Bluetooth rfcomm ports have disappeared. Oddly udev doesn't tell us that they have gone away, probably because ModemManager still has the port's file descriptor open and virtual devices like rfcomm ports sometimes stick around until all their users have disappeared. Because of 27408b4c MM wasn't listening to the serial port and the port hangup that would normally cause MM to release the port was ignored. But in the end, resetting CONNECTED state when disconnecting doesn't do anything useful because it doesn't allow commands to be sent to the modem which might (helpfully) interrupt the command stream and get the device responsive. Also, whatever terminated the data connection and called Disconnect() should already have terminated anything that would allow data to be transferred, like the PPP session or cleared the IP addresses from the net interface, or terminated the Bluetooth link.
2013-02-19build: fix passing arguments to configure from autogen.sh (bgo #694157)Evan Nemerson
2013-02-15serial-port: don't steal data from PPP when connectedDan Williams
There was a race where if PPP was slow to start, MM could read the first bits of PPP from the port, which MM shouldn't really do. So if the port is connected, remove our GIOChannel watch and let pppd handle all the data. When the port is disconnected, re-attach our watch and start reading from the port again. This may make it harder to detect spurious disconnects if for example pppd drops the connection and the thing controlling PPP (eg, NetworkManager or something else) doesn't tell us about that event by disconnecting the bearer. This is arguably programmer error though. See the logs in https://bugzilla.gnome.org/show_bug.cgi?id=624956#c10 for an example of this: DEBUG: <1280300196.929489> (ttyACM0): <-- '<CR><LF>CONNECT<CR><LF>' DEBUG: <1280300196.929761> (ttyACM0): port now connected DEBUG: <1280300196.929853> Modem /org/freedesktop/ModemManager/Modems/0: state changed (connecting -> connected) DEBUG: <1280300196.929954> (ttyACM0): simple connect state 6 DEBUG: <1280300196.933432> (ttyACM0): <-- '~\-1}#\-64!}!} } }2}#}$\-64#}!}$}%\-36}"}&} }*} } g}%~'
2013-02-15Revert "serial-port: don't steal data from PPP when connected"Dan Williams
This reverts commit 625e1c4884215bb9989dad6c9868c06ba76a4d94. By simply returning when data is available, no data gets cleared from the file descriptor and data_available() keeps getting rescheduled, leading to a busy-loop. This is the wrong approach, we should be removing the GIOChannel watch instead.
2013-02-12core: use g_unix_signal_add() for more reliable Unix signal handlingDan Williams
There were a few problems with MM's existing signal handling, first of which was that calling g_main_loop_quit() from a signal handler only works 50% of the time due to severe restrictions on what you can do from the handler. This caused INT or TERM to sometimes be ignored by MM. Instead, use the glib signal functions which ensure that the handler is run in the right context, where we can do anything we want.
2013-02-12serial-port: don't steal data from PPP when connectedDan Williams
There was a race where if PPP was slow to start, MM could read the first bits of PPP from the port, which MM shouldn't really do. So if the port is connected, don't read any data and let pppd do its thing. See the logs in https://bugzilla.gnome.org/show_bug.cgi?id=624956#c10 for an example of this: DEBUG: <1280300196.929489> (ttyACM0): <-- '<CR><LF>CONNECT<CR><LF>' DEBUG: <1280300196.929761> (ttyACM0): port now connected DEBUG: <1280300196.929853> Modem /org/freedesktop/ModemManager/Modems/0: state changed (connecting -> connected) DEBUG: <1280300196.929954> (ttyACM0): simple connect state 6 DEBUG: <1280300196.933432> (ttyACM0): <-- '~\-1}#\-64!}!} } }2}#}$\-64#}!}$}%\-36}"}&} }*} } g}%~'
2013-02-08qcdm: fix handling of active pilot setDan Williams
Typo caused candidate or remaining sets to be treated as the active pilot set.
2013-02-07novatel: use ERI subsystem information to better determine roamingDan Williams
We use the Icon ID here because a value of 1 *always* means not roaming, while the other values don't appear to be consistent. For example, an ERI value of "0" is supposed to mean roaming according to the standards, but the Novatel devices appear to use 0 to mean home. Since we're not sure, don't depend on the ERI value itself, just depend on the Icon ID, where we know for sure that 1 means "home". Backport of 8253d6f9de7b086a22a564180986b46fda35556b
2013-02-07qcdm: add Novatel ERI subsystem supportDan Williams
Returns various ERI information like Indicator ID/Index, Icon ID/Index, Icon Mode, and banner.
2013-02-07qcdm: rename Novatel subsystem definesDan Williams
2013-02-07qcdm: various LTE-related NV mode pref and sysmode updatesDan Williams
2013-02-07mbm: disconnect if the modem indicates the connection failed (bgo #690868)Dan Williams
2013-02-07mbm: handle HSPA access technology in ERINFO responseDan Williams
HSUPA/HSPA capable devices (ex F5521gw) can report '3' here, which we'll decide to interpret as HSPA. It might actually mean HSDPA + HSUPA, but whatever...
2013-01-09blacklist: ignore all devices from VID 0x0617Aleksander Morgado
No modems from the Swiss Federal Institute of Technology. https://bugzilla.gnome.org/show_bug.cgi?id=691384
2012-12-23ModemManager: Blacklist Dangerous Prototypes Bus Pirate v4Anton Blanchard
The Bus Pirate v4 presents itself as a CDC ACM device which ModemManager attempts to configure. This results in a range of confusing issues because it injects a bunch of AT commands over whatever is going on at the time. Firmware updates were failing at random points and avrdude failed to work at all. Blacklisting it fixed my issues.
2012-12-17sierra: always mark APPx ports as secondaryDan Williams
Some devices have more than one APP port with limited AT parsing. The sierra plugin handled the first one fine, but depending on probing order and other delays, the additional APP2 or APP3 ports could get selected as the primary port, which just doesn't work. So ensure that APP ports are always marked secondary no matter which one they are.
2012-12-13sierra: restore longer CFUN=1 timeout for older devicesDan Williams
Turns out older devices (like the C885/AT&T Mercury) crash often when we don't wait for them to settle from CFUN=1. 5 seconds is too short, but the crashes go away when we wait for 10 seconds. Newer modems like the USB306 don't have this problem, so we just check to see if the modem is a DirectIP device (using sierra_net) and only use the shorter timeout for those newer devices. This is a separate problem from some older modems returning ERROR to valid commands that are sent too soon after CFUN=1, which was observed on really old devices like the PCMCIA 860. (backport of commit 5427f0d356c115814562cbe0483157a62de616cb)
2012-12-13gsm: simplify some codeDan Williams
We never expect g_regex_new() to fail, because if it does, that means the regex isn't valid, and that's a programmer error, not a runtime one.
2012-12-03serial: clear serial info struct before calling ioctl()Aleksander Morgado
We need the kernel driver to give a proper value for the 'closing_wait' variable, but don't assume it will. This should solve the following kind of issues reported by valgrind: ==8985== Conditional jump or move depends on uninitialised value(s) ==8985== at 0x4409A6: mm_serial_port_close (mm-serial-port.c:932) ==8985== by 0x41A420: disable_all_done (mm-generic-cdma.c:753) ==8985== by 0x4125A4: mm_manager_shutdown (mm-manager.c:1130) ==8985== by 0x40DE35: main (main.c:203)
2012-11-30cdma: skip shadowing error variableAleksander Morgado
Makes it easier to understand the code.
2012-11-30cdma: avoid double free of GErrorAleksander Morgado
The GError passed to simple_reg_callback() is coming from (MMCallbackInfo *)info->error, and therefore shouldn't be freed. https://bugzilla.gnome.org/show_bug.cgi?id=689289 For reference, reported by valgrind as: ==8985== Invalid free() / delete / delete[] / realloc() ==8985== at 0x4C2A739: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==8985== by 0x40ED4B: mm_callback_info_unref (mm-callback-info.c:244) ==8985== by 0x56FB0E7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2) ==8985== by 0x56FB6E9: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2) ==8985== by 0x56FDADF: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2) ==8985== by 0x56FDDC7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2) ==8985== by 0x56FE1C1: g_main_loop_run (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2) ==8985== by 0x40DE22: main (main.c:199) ==8985== Address 0xa600770 is 0 bytes inside a block of size 16 free'd ==8985== at 0x4C2A739: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==8985== by 0x40EDD3: callback_info_done (mm-callback-info.c:89) ==8985== by 0x56FB0E7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2) ==8985== by 0x56FB6E9: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2) ==8985== by 0x56FDADF: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2) ==8985== by 0x56FDDC7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2) ==8985== by 0x56FE1C1: g_main_loop_run (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2) ==8985== by 0x40DE22: main (main.c:199)
2012-11-29sierra: USB 306 modems support PPP on the APPx portsDan Williams
2012-11-28huawei: implement Huawei-specific CDMA signal quality checksheiher
Many Huawei CDMA modems implement vendor commands for 1x and EVDO signal quality, so use them since they are more accurate than the generic signal checking. (dcbw: reorganize a bit; add fallbacks on error; consolidate signal quality parsing with unsolicited handlers)
2012-11-28plugin-base: handle Huawei Data07 capabilities probingAleksander Morgado
2012-11-26gsm: always try +CSQ if +CIND fails; fix bugsDan Williams
Two issues: 1) if there was a generic error with the +CIND response, the code set the callback error, scheduled the callback, but then continued with +CIND and possibly +CSQ. That could overwrite the original error (a memory leak) and trigger warning about an already-scheduled callback. Instead, just ignore the error and request +CSQ as a fallback. 2) If +CIND parsing failed, the parse error was set on the callback, but +CSQ was also requested. Thus if +CSQ was successful, the +CIND error would still be returned. Instead, just ignore the +CIND parsing error (but log it) and request +CSQ as a fallback.
2012-11-14qcdm: trivial cleanup of log item numbersDan Williams
2012-11-14qcdm: add some EVDO log item numbersDan Williams
2012-11-14qcdm: clarify log item command length memberDan Williams
2012-11-14uml290mode: fix log messageDan Williams
2012-11-14uml290mode: offline and reset modem after making changesDan Williams
2012-11-14qcdm: add qcdm_cmd_control_new() to set operating modeDan Williams
2012-11-14serial: fix warning when driver doesn't support closing_wait (bgo #630670)Dan Williams
It appears that GIOChannel might also do some flushing, so make sure our warning captures that delay if there is one. Also be paranoid and make sure nothing reset our closing_wait value.
2012-11-13blacklist: skip probing Atmel samba bootloaderAleksander Morgado
https://bugzilla.gnome.org/show_bug.cgi?id=688213
2012-11-12huawei: better detection of data port on some modemsAleksander Morgado
Some devices (e173) appear to lie about NDIS support; GETPORTMODE reports NDIS is enabled, but that port is actually the MDM port and responds to AT commands. So, if we get a port reported as NDIS and none reported as MDM, use the one reported as NDIS for PPP. https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1057186
2012-10-30sierra: allow more time for PDP context activationDan Williams
3 seconds isn't always enough to set up the context with the network.
2012-10-30sierra: fix CFUN power up delay handlingDan Williams
1) all Sierra devices appear to require short delay after powering up, otherwise subsequent commands may return errors. Older devices need longer so ensure new devices are penalized just for being new. 2) When the modem is already in full functionality status and no power up command was sent, there's no need to delay, which was happening regardless of what state the modem was already in. Detect whether the power up was actually executed (response and error will be NULL) and only delay if it was executed.