- May 31, 2013
-
-
Dan Williams authored
-
Dan Williams authored
-
Dan Williams authored
-
Dan Williams authored
-
Dan Williams authored
Icera devices include bands that the modem doesn't support in the %IPBM=? list, so the plugin sets the band to its current enabled/disabled value to test whether that band is supported. Apparently enabling a band that's already enabled isn't a NOP, and we don't want to make any changes since we're just checking whether the band is supported. So instead of enabling already- enabled bands, just assume those bands are supported and only check the disabled bands. This is a backport of 23204111
-
Dan Williams authored
If the modem was locked, it'll delay responding until the SIM is ready, which can take a long time.
-
Dan Williams authored
Attempting PPP on interface 1 never returns CONNECT, simply hangs and times out at the dial.
-
Dan Williams authored
Modems can probably put whatever they want between the quotes for the operator name, including commas. Handle that. https://bugzilla.gnome.org/show_bug.cgi?id=701329
-
Dan Williams authored
Otherwise it could match an IPv6 context with the same APN name, which isn't what we want since MM 0.6 doesn't support IPv6.
-
Dan Williams authored
-
Just treat 'NA' as MM_MOBILE_EQUIPMENT_ERROR_NOT_ALLOWED error. https://bugzilla.gnome.org/show_bug.cgi?id=697368
-
Dan Williams authored
Nozomi devices are old Option NV CardBus devices with the ttys (nozX) hanging directly off the PCI device. We need to read the vendor and product IDs off them too. It appears that udev screws up the ID_MODEL_ID field (at least on F17, its set to the device path and not the PCI ID) so just skip looking at the TTY itself and read the PCI parent, where we're 100% sure to find the PCI IDs we want. Backport of 2bbe2f83
-
Dan Williams authored
For some reason a number of ZTE CDMA devices want the whole QCDM frame in one USB transaction, or at least don't like it being broken up and sent byte-by-byte with a send delay. They simply don't respond. Since testing indicates that every other QCDM capable device I've got also handles a zero send delay on both 3.8.8 and 2.6.32, lets just set it to zero for everything, which should speed things up a bit too. https://bugzilla.gnome.org/show_bug.cgi?id=698869
-
Dan Williams authored
user_data is a MMCallbackInfo, not MMGenericCdma.
-
- May 29, 2013
-
-
Dan Williams authored
Most modems don't require a dial number these days, plus the user really shouldn't care about the number anyway; if it's required, ModemManager will construct the right one for you. So don't require a number at all.
-
- Apr 18, 2013
-
-
Dan Williams authored
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.
-
- Apr 17, 2013
-
-
Dan Williams authored
The helper functions got the return code of qcdm_result_* wrong and thus failed all requests for pilot sets.
-
- Apr 09, 2013
-
-
Dan Williams authored
Could cause memory corruption, though it was usually only noticed when MM was quitting.
-
- Apr 08, 2013
-
-
Dan Williams authored
-
- Apr 04, 2013
-
-
-
Aleksander Morgado authored
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
- Mar 26, 2013
-
-
-
Thomas Bechtold authored
-
- Mar 13, 2013
-
-
- Mar 12, 2013
-
-
Dan Williams authored
-
-
- Mar 04, 2013
-
-
- Feb 27, 2013
-
-
Aleksander Morgado authored
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
-
- Feb 20, 2013
-
-
Dan Williams authored
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 27408b4c 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.
-
- Feb 19, 2013
-
-
- Feb 15, 2013
-
-
Dan Williams authored
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}%~'
-
Dan Williams authored
This reverts commit 625e1c48. 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.
-
- Feb 12, 2013
-
-
Dan Williams authored
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.
-
Dan Williams authored
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}%~'
-
- Feb 08, 2013
-
-
Dan Williams authored
Typo caused candidate or remaining sets to be treated as the active pilot set.
-
- Feb 07, 2013
-
-
Dan Williams authored
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 8253d6f9
-
Dan Williams authored
Returns various ERI information like Indicator ID/Index, Icon ID/Index, Icon Mode, and banner.
-
Dan Williams authored
-
Dan Williams authored
-