Previously, NM reset permanent MAC to an interface while disconnecting. That
basically ignored MAC addresses set before NM started managing the interface.
Now, the initial MAC address is remembered and set back to the interface when
disconnecting.
Should be returning NULL here since the actual hostname is returned in the
for() loop if the plugin supports hostnames. But if the plugin for some
reason returns an empty string (which they aren't supposed to do) then
hostname would be left assigned to an already-freed value, which was then
returned to higher layers.
==12331== Invalid free() / delete / delete[]
==12331== at 0x4024B3A: free (vg_replace_malloc.c:366)
==12331== by 0x448BFC5: g_free (gmem.c:191)
==12331== by 0x43E0E05: value_free_string (gvaluetypes.c:268)
==12331== by 0x43DC587: g_value_unset (gvalue.c:276)
==12331== by 0x80B297F: notify (nm-sysconfig-settings.c:229)
==12331== by 0x43C64E7: g_cclosure_marshal_VOID__PARAM (gmarshal.c:531)
==12331== by 0x43B78B8: g_type_class_meta_marshal (gclosure.c:878)
==12331== by 0x43B9251: g_closure_invoke (gclosure.c:767)
==12331== by 0x43CD239: signal_emit_unlocked_R (gsignal.c:3178)
==12331== by 0x43CEDB3: g_signal_emit_valist (gsignal.c:2981)
==12331== by 0x43CF255: g_signal_emit (gsignal.c:3038)
==12331== by 0x43BD630: g_object_dispatch_properties_changed (gobject.c:801)
==12331== Address 0x479f208 is 0 bytes inside a block of size 1 free'd
==12331== at 0x4024B3A: free (vg_replace_malloc.c:366)
==12331== by 0x448BFC5: g_free (gmem.c:191)
==12331== by 0x80B1A08: nm_sysconfig_settings_get_hostname (nm-sysconfig-settings.c:280)
==12331== by 0x80B27C7: get_property (nm-sysconfig-settings.c:1415)
==12331== by 0x43BC707: g_object_get_property (gobject.c:935)
==12331== by 0x80B288D: notify (nm-sysconfig-settings.c:225)
==12331== by 0x43C64E7: g_cclosure_marshal_VOID__PARAM (gmarshal.c:531)
==12331== by 0x43B78B8: g_type_class_meta_marshal (gclosure.c:878)
==12331== by 0x43B9251: g_closure_invoke (gclosure.c:767)
==12331== by 0x43CD239: signal_emit_unlocked_R (gsignal.c:3178)
==12331== by 0x43CEDB3: g_signal_emit_valist (gsignal.c:2981)
==12331== by 0x43CF255: g_signal_emit (gsignal.c:3038)
We don't want to require a full 802.1x reauth when using OTP tokens
and roaming between APs in the same ESS, since that takes a long time
(user has to find the token and type in the code).
It's still got a bunch of issues that need debugging, like when VPN
nameservers exist but no domain and thus not doing split DNS, sometimes
hosts outside the VPN don't resolve correctly, which was previously
masked by having the non-VPN nameservers in /etc/resolv.conf where
glibc would erroneously use them instead of asking BIND. To be fixed
in a subsequent patch.
The dnsmasq plugin seems to work great though.
Caching DNS with dnsmasq works well enough to merge for now. THere
are still some issues with the BIND plugin because BIND is god-awful
unecessarily complex so we'll disable that in a further commit.
If all nameservers are listed in resolv.conf, glibc apparently
tries them all (even if 'options rotate' isn't specified??). Leading
to queries for internet hosts being directed to VPN-specific DNS
servers in split-DNS situations. I've verified this with wireshark;
I see queries going out over the tunnel to VPN nameservers for
non-internal addresses, while BIND itself never logs anything about
queries to VPN nameservers for that same address. Thus the only
thing left is to blame glibc...
Despite most guides saying that without restricting to port 53 queries
won't get through a firewall, I cannot make it work with this option.
DNS queries through a WRT54G just time out even when the WRT54G isn't
caching anything itself (ie, explicit upstream nameservers are the
forwarders in the bind config).
This was supposed to hook up to the bits Adam Langley did last year
for his local-dns-cache DBus service, but I misunderstood the
architecture. It was a separate service, not Chromium itself. But
it's unclear what happened to his local-dns-cache since the project
doesn't seem to have any commits in a year and I'm unsure if it's
actually being used. So remove this stuff for now.
Use a pseudo-hash to quickly check whether the DNS config has really
changed or not. This is certainly better than the 500 line patch I
did then scrapped in favor of this approach... yay. This helps ensure
that we don't kill then respawn caching DNS servers more often than
we have to.
If the VPN client didn't provide a domain we still want to use the
VPN nameservers first, we just can't do split DNS. Also use
--strict-order to ensure VPN nameservers are always chosen first.
Previously the "Enable Wireless" state was somewhat tied to rfkill state,
in that when NM started up, rfkill state would take precedence over what
was listed in the state file, and if you rmmodded your wifi driver and
then modprobed it again after disabling wifi from the menu, wifi would
magically become re-enabled becuase rfkill state changed.
Fix that by creating a third wifi/wwan enable state that tracks the
actual user preference instead of just the rfkill state so that when
the user disables wifi it stays disabled, regardless of what happens
with rfkill.
This means you don't need pm-utils anymore, and that gnome-power-manager
doesn't need to poke NM explicitly for suspend/resume operations.
The old explicit sleep/wake request is still around for pm-utils or
gpm to use, but NM will listen for UPower events and act on them
regardless of what pm-utils or gpm do.
priv->access_list is allocated during object initialization and
only destroyed when the object is destroyed, so it will always
be valid over the lifetime of the object. Thus no need to check
if it exists or not.
The GSList returned by nm_session_manager_get_sessions() must be
freed by the caller. s/connection/self to make it clear what
object is actually being handled here too.
Get rid of the InitInfo struct since it's so small and just store
that information in the main object's private data; less complicated.
Also fix an edge-case where the init-done signal would not get
emitted if CK wasn't tracking any sessions at the time.
While it may not reduce the LOC it saves a few memory allocations
and is somewhat less error prone since callers don't need to free
the returned lists.
Moves the system settings permissions checking into the core service's
permissions checking, which at the same time enables 3-way permission
reporting (yes, no, auth) instead of the old yes/no that we had for
system settings permissions before. This allows UI to show a lock
icon or such when the user could authenticate to gain the permission.
It also moves the wifi-create permissions' namespace to the main
namespace (not .settings) since they really should be checked before
starting a shared wifi connection, rather than having anything to do
with the settings service.
Since these were properties they are harder to validate the caller as
dbus-glib doesn't have any hooks before the property is set. So we
install a low-level dbus filter function to catch property Set
requests before they get to dbus-glib and handle the property access
there.
When NM quits, we don't want to unmanage a device that has
an active connection and can take that connection over again when
NM starts back up. This makes '/etc/init.d/NetworkManager restart'
work seamlessly. All other devices get unmanaged so their
connection (and any dependent VPN connections or wpa_supplicant
processes) get terminated. This bug caused active VPN connections
over wifi to be left running even when they didn't have IP
connectivity.
There were two bugs:
1) the NMDevice class implemented connection_match_config() for
all device subclasses, but only Ethernet devices can assume
connections at startup. Thus the quit-time check passed for
active wifi devices too, and they weren't properly cleaned up
2) The logic for figuring out which devices to clean up after when
quitting was somewhat flawed; we want to default to unmanaging
devices and then skip that step for ones that meet specific
criteria. Instead the code defaulted to leaving all devices active
at shutdown.
