1. 23 Sep, 2019 1 commit
  2. 13 Sep, 2019 1 commit
  3. 28 Aug, 2019 2 commits
  4. 23 Aug, 2019 1 commit
  5. 07 Aug, 2019 3 commits
  6. 06 Aug, 2019 1 commit
  7. 05 Aug, 2019 1 commit
  8. 03 Aug, 2019 2 commits
  9. 01 Aug, 2019 4 commits
  10. 23 Jul, 2019 1 commit
  11. 22 Jul, 2019 1 commit
  12. 18 Jul, 2019 1 commit
    • Thomas Haller's avatar
      device: fix reapplying changes to connection ID and UUID · 9c72ca5e
      Thomas Haller authored
      4 properties are not really relevant for an already activated connection
      or it makes not sense to change them. These are connection.id, connection.uuid,
      connection.autoconnect and connection.stable-id.
      For convenience, we allow to reapply these. This way, one can take
      a different setting (e.g. with a different connection.id or
      connection.uuid) and reapply them, but such changes are silently
      However this was done wrongly. Instead of reverting the change to the new
      applied connection, we would change the input connection.
      This is bad, for example with
        nmcli connection up uuid cb922f18-e99a-49c6-b200-1678b5070a82
        nmcli connection modify cb922f18-e99a-49c6-b200-1678b5070a82 con-name "bogus"
        nmcli device reapply eth0
      the last re-apply would reset the settings-connection's connection ID to
      what was before, while accepting the new name on the applied-connection
      (while it should have been rejected).
      Fixes: bf3b3d44 ('device: avoid changing immutable properties during reapply')
      (cherry picked from commit adb51c2a)
      (cherry picked from commit 09f37d5b)
  13. 09 Jul, 2019 1 commit
  14. 04 Jul, 2019 1 commit
  15. 03 Jul, 2019 1 commit
  16. 27 Jun, 2019 1 commit
  17. 26 Jun, 2019 1 commit
  18. 20 Jun, 2019 7 commits
  19. 14 Jun, 2019 2 commits
    • Beniamino Galvani's avatar
      cli: don't wait for connection change on update failure · 2666aa0b
      Beniamino Galvani authored
      When saving a connection, we wait the connection-changed signal before
      proceeding to ensure that the remote connection is up to date.
      However, no signal is emitted if the update fails and so we shouldn't
      wait for it.
      Fixes: a370faeb ('cli: wait for changed signal after updating a connection'):
      (cherry picked from commit 2d347e7e)
      (cherry picked from commit 3423629f)
    • Alfonso Sánchez-Beato's avatar
      core/pppd-plugin: wait to recover port settings before notifying death · 61b4f31d
      Alfonso Sánchez-Beato authored
      pppd restores the previous settings for the serial port it uses right
      before exiting. It is especially important to do so because otherwise
      ModemManager is not able to recover the port as it can receive a hangup
      event from the port due to CLOCAL not being restored.  However, there is
      currently a race condition that produces this issue. This is because
      when PHASE_DEAD is notified, pppd still has not restored the port
      settings - it does that a bit later, in the die() function.
      This patch delays notifying PHASE_DEAD until when the exitnotify() hook
      is called by pppd: when this happens the port settings have already been
      There were previously efforts to fix this in commit fe090c34, so
      PHASE_DEAD was used instead of PHASE_DISCONNECT to notify MM that the
      port was disconnected, but that still early to ensure that the port
      settings are restored.
      The MM traces seen when the bug is triggered are:
      ModemManager[2158]: <warn>  (ttyACM1): could not re-acquire serial port lock: (5) Input/output error
      ModemManager[2158]: <warn>  Couldn't load Operator Code: 'Cannot run sequence: 'Could not open serial device ttyACM1: it has been forced close'
      (cherry picked from commit a251712a)
      (cherry picked from commit 3caa0657)
  20. 11 Jun, 2019 5 commits
  21. 29 May, 2019 2 commits