So that dhclient will, in turn, pass it to the action script
(the action script tries to send a DBus signal to NetworkManager
over the system bus).
Dhclient "execve"s the action script with a hand-constructed environment
that only includes specific variables, plus whatever is passed to
dhclient with "-e".
As far as I know, dhcpcd has no option equivalent to dhclient's "-e".
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.
