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.
APNs can only contain alphanumeric characters, '.', and '-'. To be
helpful we strip spaces off before setting the APN internally so that
previously (and incorrectly) valid APNs don't cause the whole
connection to fail validation and thus disappear. The only case seen
in the wild was a Pelephone IL APN which erroneously had a trailing
space in the mobile broadband provider database. Bad characters
cause the connection to fail with vague error messages about being
unable to activate the PDP context during PPP negotiation.
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).
'enable' command queries and sets NetworkingEnabled property. It should be used
by users. Previous 'sleep' command that actually did enable/disable,
really calls Sleep() now and is not meant for common usage.
Keep compat with old format if the SSID includes unprintable
characters. But having to type an int list for an SSID is just silly
and it's about damn time we fix that.
The IO library was in io/ because I was too lazy to find autotools'
SUBDIRS rules at the time and that you could use '.' for the current
directory. Fix that and use its own error defines instead of
the system settings service. Clean up a for more things for good
measure too (like KEYFILE_DIR, etc).
This should help people debug issues with keyfile not recognizing
files since it'll actually print out something when it fails to
parse stuff. Also logs changes, new connections, and deletions.
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.
