Skip to content
Snippets Groups Projects
  1. May 31, 2013
  2. May 29, 2013
    • Dan Williams's avatar
      core: if no dial number is given, use standard ones · 71be40e0
      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.
      71be40e0
  3. Apr 18, 2013
    • Dan Williams's avatar
      core: rework logging code to remove log message truncation (bgo #698312) · 99978b9a
      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.
      99978b9a
  4. Apr 17, 2013
  5. Apr 09, 2013
  6. Apr 08, 2013
  7. Apr 04, 2013
    • Aleksander Morgado's avatar
    • Aleksander Morgado's avatar
    • Aleksander Morgado's avatar
      mbm: remove connection attempt check poll explicitly when connected · 16520193
      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
      16520193
  8. Mar 26, 2013
  9. Mar 13, 2013
  10. Mar 12, 2013
  11. Mar 04, 2013
  12. Feb 27, 2013
    • Aleksander Morgado's avatar
      udev: update all udev rules to always match both VID/PID together · e322ccf6
      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
      e322ccf6
  13. Feb 20, 2013
    • Dan Williams's avatar
      gsm,cdma: don't reset connected state if disconnecting fails · e04ddef7
      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.
      e04ddef7
  14. Feb 19, 2013
  15. Feb 15, 2013
    • Dan Williams's avatar
      serial-port: don't steal data from PPP when connected · 27408b4c
      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}%~'
      27408b4c
    • Dan Williams's avatar
      Revert "serial-port: don't steal data from PPP when connected" · cffdb733
      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.
      cffdb733
  16. Feb 12, 2013
    • Dan Williams's avatar
      core: use g_unix_signal_add() for more reliable Unix signal handling · 034279f2
      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.
      034279f2
    • Dan Williams's avatar
      serial-port: don't steal data from PPP when connected · a277e835
      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}%~'
      a277e835
  17. Feb 08, 2013
  18. Feb 07, 2013
Loading