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.
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.
More info:
https://bugzilla.redhat.com/show_bug.cgi?id=585394http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1172
dbus-glib was not properly enforcing the 'access' permissions on
object properties exported using its API. There were 2 specific bugs:
1) dbus-glib did not enforce the introspection read/write property
permissions, so if the GObject property definition allowed write
access (which is sometimes desirable), D-Bus clients could modify
that value even if the introspection said it was read-only
2) dbus-glib was not filtering out GObject properties that were
not listed in the introspection XML. Thus, if the GObject defined
more properties than were listed in the introspection XML (which is
also often useful, and NM uses this quite a bit) those properties
would also be exposed to D-Bus clients.
To fix this completely, you need to:
1) get dbus-glib master when the patch is commited, OR grab the
patch from https://bugzilla.redhat.com/show_bug.cgi?id=585394 and
build a new dbus-glib
2) rebuild NetworkManager against the new dbus-glib
If a new device wasn't supported, it gets destroyed by the
NMDevice constructor() method. But in the constructor paths
the DHCP manager isn't created yet, and so we attempt to unref
a non-existent DHCP manager. Usually just a harmless warning,
but apparently a crash sometimes.
DHCPv6 doesn't really use broadcast; instead clients use reserved
multicast addresses to talk to the server. ff02::1:2 (link scope)
and ff05::1:3 (site scope) are used. This means the routing table
has to have a route that can handle outgoing traffic to these
addresses, which is ff00::/8. The kernel sometimes adds one for us,
so we need to (a) make sure we don't tear that route down, and
(b) that if it's not there before we start DHCPv6, that we add it.
Otherwise dhclient complains about not being able to send outgoing
traffic from it's send_packet6() function with "no route to host".
It will then use an expired lease, which causes NM to assign that
leases IP address to the interface, whcih causes the kernel to
assign the required ff00::/8 route, and then dhclient performs a
renew (since the expired lease has expired of course) and then
everything works out in the end. But the latency sucks.
So make DHCPv6 faster by ensuring that dhclient has the routes
it needs before we start the DHCP session.
The autoactivation code wasn't excluding subchannel-locked connections
when matching for devices that don't have subchannels. This only
produced a warning message though as the connection activation would
be failed by the check_connection_compatible hook.
If your hostname is 'foo.bar.baz' and your DNS server doesn't
actually reply to queries for 'foo.bar.baz' you can't just 'ping foo'
currently. While that may be somewhat of a misconfigured setup,
since we're already adding the domain part of the hostname to
/etc/resolv.conf we might as well add the short hostname to /etc/hosts
too so that ping works.
If the client was disabled with --with-dhclient=no or
--with-dhcpcd=no, then it's corresponding _PATH will be an empty
string. In that case we want to ignore that client completely
since it was disabled at build time.
