1. 12 Nov, 2009 3 commits
  2. 11 Nov, 2009 12 commits
  3. 10 Nov, 2009 5 commits
  4. 07 Nov, 2009 1 commit
    • Dan Williams's avatar
      wifi: fix some immediate wifi connection failures when enabling wifi · d53574d7
      Dan Williams authored
      Impact of this bug is likely limited to Ad-Hoc connections that don't
      require a scan before activation since by the time the scan has finished,
      the NMSupplicantInterface will be set up.  However, this shows a bug where
      Ad-Hoc connections can be immediately activated even if they don't have
      the latest timestamp, because a scan hasn't completed yet and thus we don't
      know if there are any usable APs around.  Could be fixed by only letting
      auto-activations happen after the first successful scan anyway.  But whatever...
      Log messages look like this:
      NetworkManager: <info>  Activation (wlan0/wireless): connection 'Wireless connection 1' requires no security.  No secrets needed.
      NetworkManager: <info>  Config: added 'ssid' value 'foobar'
      NetworkManager: <info>  Config: added 'mode' value '1'
      NetworkManager: <info>  Config: added 'frequency' value '2412'
      NetworkManager: <info>  Config: added 'key_mgmt' value 'NONE'
      (NetworkManager:28239): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed
      (NetworkManager:28239): GLib-GObject-CRITICAL **: g_type_instance_get_private: assertion `instance != NULL && instance->g_class != NULL' failed
      NetworkManager: dbus_g_proxy_begin_call: assertion `DBUS_IS_G_PROXY (proxy)' failed
      NetworkManager: <WARN>  real_act_stage2_config(): Activation (wlan0/wireless): couldn't send wireless configuration to the supplicant.
      NetworkManager: <info>  (wlan0): device state change: 5 -> 9 (reason 9)
      NetworkManager: <info>  Activation (wlan0) failed for access point (foobar)
      NetworkManager: <info>  Marking connection 'Wireless connection 1' invalid.
      This happened because the nm_device_wifi_set_enabled() only checked for
      the existence of the NMSupplicantInterface, but not whether the supplicant
      interface was ready to be used.  The supplicant interface would be in the
      middle of the getInterface or addInterface call and wouldn't have
      initialized priv->iface_proxy yet, which is where that error message was
      coming from.
      So don't change device state from the wifi_enabled handler, just init
      the supplicant interface (it should have been torn down already by
      device_state_changed() when the device goes to UNAVAILABLE or UNMANAGED)
      and wait for the supplicant interface state change to READY to change
      the NMDeviceWifi state to DISCONNECTED in supplicant_iface_state_cb_handler().
  5. 06 Nov, 2009 2 commits
  6. 04 Nov, 2009 3 commits
  7. 03 Nov, 2009 1 commit
  8. 02 Nov, 2009 1 commit
  9. 30 Oct, 2009 2 commits
  10. 28 Oct, 2009 1 commit
  11. 23 Oct, 2009 2 commits
  12. 21 Oct, 2009 1 commit
    • Dan Williams's avatar
      system-settings: fix PK Authority object lifetimes · f8643cc0
      Dan Williams authored
      It's a singleton, but PolicyKit didn't increment the reference count
      when returning from polkit_authority_get() like we expected (which has
      since been fixed upstream).  So for now, just don't unref the authority
      at all.
      Since we don't do that, there's a chance that some PolicyKit calls could
      be outstanding when either the NMSysconfigSettings object or one of the
      NMSysconfigConnection objects are around, so we make sure we cancel any
      PolicyKit calls when the object gets disposed.  This is tricky, because
      canceling them from the dispose may mean that the callback gets called
      after the object is actually destroyed, so we have to be careful not to
      access any private object data from the callbacks in that situation.
  13. 20 Oct, 2009 6 commits
    • Dan Williams's avatar
      core: clear invalid tag on failed connections when sleeping · 4b2c810b
      Dan Williams authored
      So they'll get tried again on wakeup/resume.
    • Dan Williams's avatar
      dns: honor resolv.conf symlinks (lp:324233) · 5761e328
      Dan Williams authored
      Based on a patch from Alexander Sack, but hugely
      modified by me to make use of allocated realpath results
      instead of stack-based arrays, and to fix an omission in
      the original patch that would still have used the
      non-realpath-resolved path to /etc/resolv.conf when doing
      the atomic rename of the tempfile to resolv.conf.
    • Dan Williams's avatar
      libnm-glib: tighter warning print checks · c9d2d977
      Dan Williams authored
      Should be checking for dbus-glib errors of the right type,
      instead of any error code (dbus-glib or not) that happens to be
    • Dan Williams's avatar
      libnm-glib: warning cleanups · 3d194df9
      Dan Williams authored
    • Dan Williams's avatar
      libnm-glib: fix warning tearing down connections · 9e356dab
      Dan Williams authored
      GLib-CRITICAL **: g_hash_table_iter_next: assertion `ri->version == ri->hash_table->version' failed
    • Dan Williams's avatar
      ipv6: fix incorrect address config signal emission · 4b73cf24
      Dan Williams authored
      device->want_signal was never set to TRUE when addrconf was started,
      causing random netlink events (say for link-local address addition
      or removal) to trigger the config-changed signal from
      nm_ip6_device_sync_from_netlink() at the wrong time.  This would
      cause IPv6 address configuration to look like it succeeded, when
      in fact the config timeout was still in-force.  Thus device
      activation would proceed if IPv4 was enabled, but a few seconds later
      the device would be deactivated due to the still active IPv6
      So fix that and clarify when the events from the IPv6 manager happen,
      and what the want_signal variable is really for.