If the caller passed "/" to indicate that NM should choose the default
active connection as the parent of the VPN, make sure we pass that
active connection's object path to the VPN for its specific object
path instead of leaving it "/".
This commit fixes a regression introduced by commit
6272052f9d.
dhclient prefixes options with "new_", however we remove that prefix
before putting options into NMDHCP4Config.
Even with the previous fix some cases were still undistinguishable. For example,SSID like '11;12;' is both valid an intlist and a string.
So this commit:
- escapes ';' character with '\' when writing, and removes '\' while reading
This clearly differentiates between intlist x strings.
- changes regex pattern to allow spaces before ';' in intlist format
Intlists have to end with a ';' since that's how they are written
out, and that's the only way we can actually distinguish between
intlist SSIDs and string SSIDs, really.
No functional change, but clarify what's supposed to happen when
a disconnect occurs during activation or when the device is activated.
If the connection is an 802.1x or LEAP connection who's password is
NOT_SAVED, then we should request a new password immediately since
the existing one is probably no longer valid (ie, a OTP or token).
Otherwise, start a timer to give the supplicant some time to reconnect.
When connection was changed with the editor from WPA to WEP, KEY_MGMT was
not cleared. This resulted in infinite loop of ifcfg plugin under some
circumstances ("Available to all users" unchecked, I think).
The re-read connection was regarded as WPA and thus it differed from the
stored one.
This patch makes NM set the "accept_ra" sysctl to 1 rather than 2. This
causes the kernel to process RAs even if it configured to forward IPv6
traffic on the interface in question.
IPv6 forwarding would likely be enabled on a host running virtualised
operating systems with virtualised network adapters, for example. This
should not prevent NM from successfully activating IPv6 on a
NM-controlled interface configured with IPv6 mode Auto.
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.
