1. 26 Feb, 2012 2 commits
  2. 24 Feb, 2012 3 commits
  3. 23 Feb, 2012 2 commits
  4. 22 Feb, 2012 2 commits
  5. 20 Feb, 2012 2 commits
    • Dan Williams's avatar
      wifi: ensure APs remain in scan list when supplicant updates them · 92412357
      Dan Williams authored
      The port to the new supplicant D-Bus API for NM 0.9 had one unfinished
      piece, which was to remove old APs from the scan list when the
      supplicant returned no scan results or there was a scan error.  In
      this case, the removal code would not be called.  This wasn't much
      of a problem until 836f7d17 which
      began removing APs from the scan list correctly in this case.
      This uncovered a bug in NM's wpa_supplicant management code, which
      was that NM only updates its internal AP object 'last seen' timestamp
      when the AP is reported by the supplicant as a completely new BSS
      (in merge_scanned_ap()).  But the new supplicant D-Bus interface
      only reports the BSS as "new" when the supplicant doesn't know about
      the BSS, either because it is a new BSS or because it's been removed
      from the supplicant's scan list at some point in the past.
      Thus for BSSes that are consistently kept in the supplicant's scan
      list, because the wifi driver is actually doing its job and reporting
      them consistently in scan results, NM would not be updating the
      'last seen' value for the corresponding NM AP objects.  Due to
      836f7d17 this would cause APs that
      should be kept to be removed from the NM scan list.
      To fix this, have the NMAccessPoint object track which supplicant
      dbus object it came from, and have NMSupplicantInterface listen for
      PropertyChanged signals for those APs the supplicant knows about.
      When something changes (like signal strength as the result of updated
      scan results) update the AP's 'last seen' timestamp since it clearly
      still exists in the scan list.  This way we update the timestamp both
      when the supplicant finds a new AP and when it updates the properties
      of existing APs.
    • Jiří Klimeš's avatar
      netlink: fix build on libnl1/2 · 261d760a
      Jiří Klimeš authored
  6. 17 Feb, 2012 4 commits
  7. 16 Feb, 2012 18 commits
  8. 15 Feb, 2012 1 commit
    • Dan Winship's avatar
      Use glib-mkenums to generate enum types · 839eab55
      Dan Winship authored
      Rather than generating enum classes by hand (and complaining in each
      file that "this should really be standard"), use glib-mkenums.
      Unfortunately, we need a very new version of glib-mkenums in order to
      deal with NM's naming conventions and to fix a few other bugs, so just
      import that into the source tree temporarily.
      Also, to simplify the use of glib-mkenums, import Makefile.glib from
      To avoid having to run glib-mkenums for every subdirectory of src/,
      add a new "generated" directory, and put the generated enums files
      Finally, use Makefile.glib for marshallers too, and generate separate
      ones for libnm-glib and NetworkManager.
  9. 13 Feb, 2012 5 commits
  10. 10 Feb, 2012 1 commit