This commit improves the handling of rfkill.
- The original two passes check gathers the states of platform
and non-platform switches in two separate loops. Now we gather
the both states in one loop and determine the final states later.
- A new rule is used to determine the states of switches.
if (platform_state == UNBLOCKED)
choose non_platform_state;
else
choose platform_state;
The state is UNBLOCKED if and only if both the platform and
non-platform switches are unblocked, so the ambiguous state in
bgo#655773 will not happen.
Original code always preferred the platform switch state over
the device switch state, so if the platform switch was UNBLOCKED
but the device was BLOCKED, NM would treat the device as
UNBLOCKED and try to activate it, and obviously fail.
NM already includes <linux/if.h> in some places, f.e. nm-netlink-monitor and
we can't mix usage of the two. Stick to using <linux/if.h> as it provides
additional flag definitions such as operational link state and link mode.
Signed-off-by: Thomas Graf <tgraf@redhat.com>
SSIDs don't want NULL termination, but some of the certificate code
checked for it. New-style plain strings would never be NULL
terminated (by accident) so fix that and make the code simpler too.
Found by Gary Ching-Pang Lin <chingpang@gmail.com>
Active VPN connections exported their own active path instead of active path of
base connection in 'SpecificObject' property. It's a regression caused by commit
bc6fc7b910 that split VPN connections to
NMVPNConnectionBase and NMVPNConnection.
Previously, specific object used to be obtained from NMActRequest of parent
connection. The NMActRequest object served also for getting secrets. Commits
0e6a5365d4 and 832e64f8bc
removed NMActRequest from VPN connection because it's not necessary any more.
This commit fixes the issue by passing specific object path explicitly.
OLPC Mesh code now doesn't have to be updated every time we change
the manager's creation arguments. We could make all these arguments
GObject properties of the manager too, but that's more code and
we'd eventually like to figure out a better solution for letting
non-NMManager code listen for device addition/removal.
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.
