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.
