1. 08 May, 2010 2 commits
  2. 06 May, 2010 1 commit
  3. 05 May, 2010 9 commits
  4. 04 May, 2010 8 commits
  5. 03 May, 2010 11 commits
  6. 02 May, 2010 6 commits
    • Dan Williams's avatar
      libnm-util: add 'may-fail' for IPv4 and IPv6 · 806b74db
      Dan Williams authored
      When this property is TRUE, IP configuration can continue as long
      as at least on IP configuration type succeeds.  This allows
      connections to networks where the user does not necessarily know
      whether the network supports IPv4 or IPv6 and does not require
      that both complete succesfully.
      Since most of the time the user doesn't really care what type
      of connectivity they have, as long as they have *some* connectivity,
      this allows better "Just Works" behavior as long as the system
      settings plugins and connection editors/applets use the right
      Suggested defaults for may-fail are:
      IPv4: no (ie, require IPv4 connectivity)
      IPv6: yes (ie, do not require IPv6 connectivity)
      Users who require a specific type of connectivity are probably
      knowlegable enough to check the box as needed for their network.
    • Dan Williams's avatar
      libnm-util: more IPv6 address gateway fixes · 71c7ecba
      Dan Williams authored
    • Dan Williams's avatar
      ip6: avoid autoconf routes where dest == gateway · 5ca72c78
      Dan Williams authored
      These return errors when we try to add them via netlink (both internal
      code and using /sbin/ip) so we'll ignore them for now.
    • Dan Williams's avatar
      trivial: remove some debugging leftovers · 32b255e1
      Dan Williams authored
    • Dan Williams's avatar
      dhcp: ensure getting DHCP IP config fails if the client died early · 28d2c559
      Dan Williams authored
      If the client never delivered any options to NM, make sure we don't
      return a valid IP config object to callers when they request one.
    • Dan Williams's avatar
      dhcp: handle client early exit correctly · c34cc017
      Dan Williams authored
      When the client	exits it may take a short amount of time for the
      dhclient hook script to	deliver	the options to NetworkManager; so
      we need	to keep	the client object around a bit (so we know what
      NMDHCPClient the options getting delivered are for).  If we don't,
      the DHCPManager will dispose of	the DHCPClient object and then
      when the options come in, it can't match up the	PID from the
      options with the PID of	an existing NMDHCPClient.  So put the
      clients	on a removal timer that	keeps them around for a	bit before
      we let the manager dispose of them.
      Since we're keeping the	PID around too instead of zeroing it when
      the client exits (for the reason above), track whether the client
      is really dead yet so we don't indiscriminately	kill a random
      process	that happens to re-use the PID.
  7. 01 May, 2010 3 commits