When a default wired connection is saved, it gets deleted first since it
has to be re-created using a settings plugin. But with the settings
rework in 0.9, default wired refcounting changed and the default
wired connection wasn't kept alive in default_wired_try_update()
over the removal/readd. This caused a use-after-free.
We are using the default cb set anyways. This allows running NM with
the NLCB=debug environment variable set to get some debug messages
out of libnl related to netlink communication.
NLCB=debug won't print received netlink messages as the MSG_IN
handler is in use by NM to verify message origins. It's probably
best to introduce new handlers in libnl for debugging purpose
so both use of MSG_IN and enable debugging is possible.
Flags are not getting set when a route is added (e.g. NLM_F_REPLACE).
Apparently this was fixed in Ubuntu, but I didn't see a patch here, so
here it is.
Verifies that provided message consists of at least the link message
header. nlmsg_parse() does this so it needs to be called prior to
accessing the message contents.
* When a connection name (ID) was changed via nm-connection-editor, a new file
path was created, but the old one was not removed. That resulted in two files
and in turn in duplicated connections.
* When two connections with the same name (ID) were present, e.g. files ABC and
ABC-70656842-98ac-4221-aa8b-0d4174770, and nm-connection-editor was used to
edit ABC-70656842-98ac-4221-aa8b-0d4174770, the operation failed.
A race condition meant that sometimes, if the wimax device finished
scanning while stage1 (Prepare) was scheduled but hadn't executed yet:
NetworkManager[8700]: <info> (wmx0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
NetworkManager[8700]: <info> Activation (wmx0) Stage 1 of 5 (Device Prepare) scheduled...
NetworkManager[8700]: <info> (wmx0): wimax state change scanning -> ready (reason 0)
the code would schedule stage2 which meant that stage1 was completely
skipped. But that's where the active-nsp property was set, which
meant clients would not be notified of the new active NSP. This
caused nm-applet to show a zero-signal-strength icon for WiMAX
because libnm-glib didn't know there was an active NSP, even though
NM was connected.
! after the option is deprecated at least as far back as iptables
1.4.12 on 2.6.32. ! should be before the option instead.
Reported-by: Ralf Jung <ralfjung-e@gmx.de>
inet_ntop() either returns 'address%interface' or just 'address'. In the first
case, we replace '%' with '@' since dnsmasq supports '%' only since version
2.58. In the second case, we append '@interface' to make it work.
(small fixes by dcbw)
When new services are installed and the daemon reloads bus policy
(like when installing new VPN plugins with rpm or dpkg) it appears
the rules don't get loaded into NetworkManager's policy space.
Thus any D-Bus message NM sends to the newly installed VPN plugin
gets denied until a restart of NM or the machine. Work around
this dbus bug by letting NM talk to all known VPN services in the
NM policy file which will always exist when NM is around.
Once we've sent a method call over DBus requesting that the modem be
disabled, we should assume that the modem is disabled unless we hear
otherwise. Otherwise, code that checks the modem state immediately
after it gets disabled might think that it's enabled when it almost
certainly is not.
Normally, a device disabled via nm_device_interface_set_enabled() will
shift into the UNAVAILABLE state. Modems, however, don't do that.
Rather, they pretend that they are in the DISCONNECTED state, presumably
to make it easier to re-enable them. To avoid accidentally re-enabling
and autoconnecting a disabled modem, we need to explicitly make
nm_device_interface_get_enabled() == true a prerequisite for
autoconnecting.
What we want to do here is keep separate caches of system and
agent secrets. For system secrets, we cache them because NM
periodically clears secrets using nm_connection_clear_secrets() to
ensure they don't stay around in memory, and that transient secrets
get requested again when they are needed. For agent secrets, we
only want them during activation, but a connection read from disk
will not include agent secrets becuase by definition they aren't
stored in system settings along with the connection. Thus we need
to keep the agent/transient secrets somewhere for the duration of
the activation to ensure they don't get deleted.
This removes the copy-back hack in update_auth_cb() which copied
agent/transient secrets back into the connection over top of the
transient secrets that had been copied back in
nm_settings_connection_replace_settings(). No reason to copy
them twice if we keep an agent/transient secrets hash and do
the right thing with it.
The core problem was that the Update would trigger a write to
disk to save the connection's new settings, which called
nm_settings_connection_replace_settings(). Which saved existing
transient (agent/unsaved) secrets, replaced settings with the
new ones from Update(), then copied back the old transient
secrets. This was to ensure that changes triggered from getting
agent secrets during activation (which might write the connection
out to disk if new system secrets were provided, which triggered
an inotify read-back of the connection, which blew away the
transient secrets just returned from the agent) didn't blow away
transient secrets. Unfortunately that fix was too general.
As a quick hack for now, copy the new secrets and re-apply them
after nm_connection_replace_settings() has run. We'll do the
actual fix later, but it's more involved and needs more testing
so we don't want to apply it this close to release.
Changing NM_CONTROLED from "no" to "yes" worked just the first time.
Fix that by storing unmanaged spec when interface becomes unmanaged
and adjust condition identifying "no-change" updates to the ifcfg
file.
Chain up to parent's commit_changes() even if in-memory and on-disk data are the
same; they are the same when another process changes the on-disk file. Just make
sure not to write out the data needlessly when same.
This fixes a regression caused by 9cba854fa0.
It exhibits e.g. by not auto-activating connection when ONBOOT is changed from
"no" to "yes". Connection "updated" signal was not emitted and listeners like
NMPolicy was not prodded.
