Some drivers (ipw2x00) support capabilities reporting via nl80211 but
absolutely nothing else. NM was only checking for capabilities
when deciding whether or not to use nl80211 to communicate with the
driver for associated AP, signal strength, and channel info, and that
clearly fails with half-implementations of nl80211 in the kernel.
Instead, match the logic that wpa_supplicant uses to determine whether
to stick with nl80211 or fall back to WEXT. For these drivers
NM will now fall back to WEXT and should return to the behavior we
had with 0.9.2 for these devices.
mac80211 drivers don't like being asked to scan when they are already
scanning, and it's pretty impossible to not race with internal
supplicant scanning. NM requests a scan immediately after the
supplicant interface gets created, and that scan request usually
succeeds. But since the supplicant's scan request method returns
when the kernel *starts* the scan, not when the scan is finished,
a second scan that NM would immediately request in
request_wireless_scan() would often fail as the card was already
scanning.
The second scan was requested immediately becuase the SCAN_INTERVAL_MIN
was zero, which was set to zero to intentionally request two scans
to work around drivers that would fail the first scan because they
are stupid.
Well, let's just penalize stupid drivers by *possibly* making the
initial connection take a few more seconds due to the change of
SCAN_INTERVAL_MIN. But what we're really doing here is not asking
for the second scan right after the first one is requested, since
that will almost always fail for most drivers, but request the
second one after the supplicant says the scan is done.
Second, if for some reason the supplicant reports that the scan failed,
don't make the next scan take longer; just queue it up without backing
off so we can retry the scan sooner.
NMDeviceWifi and a few other things expect the interface will
move from STARTING to READY and then on to other states. But the
state was getting set to the actual supplicant interface state
immediately when the first properties were read (which include
the State property) and thus the READY state got bypassed. But
we also want to read stuff like the capabilities before letting
the interface be used.
So first, ensure the supplicant interface object actually uses the
READY state like its callers expect, and second, don't set the
READY state until we actually know what we need to know about it.
Allows better encapsulation of the functionality of the NMSettings
object that we want to expose to the device class. They don't need
the whole object so to keep things simple and contained we'll just
give them a smaller interface to use.
Now that we've encountered this twice with distros disabling WEXT
but apparently not realizing it kills staging and out-of-kernel
drivers like wl.o, make it a log message so we don't have to go
hunting for build-time logfiles.
When copying device names into ioctl structs, we know that the device
names are of valid length, so we were using strcpy(). But you can't
prove that they're short enough just looking at the local code, so
some code analysis tools warn about a potential buffer overflow.. So
use g_strlcpy() instead.
A vlan DEVICE name must be either $(OTHERDEVICE).$(VLAN_ID) or
vlan$(VLAN_ID). Enforce that. In particular, don't:
(a) crash if the name has no "." and doesn't start with "vlan",
(b) loop forever if the $(VLAN_ID) part is non-numeric, or
(c) silently ignore non-numberic characters after the $(VLAN_ID).
The kernel wants there to be a default route over every RA-ed IPv6
interface, and it gets confused and annoyed if we remove that default
route and replace it with our own (causing it to effectively drop all
further RAs on the floor, which is particularly bad if some of the
information in the earlier RA had an expiration time).
So, rather than replacing the kernel's default route(s), just add an
additional one of our own, with a lower (ie, higher priority) metric.
https://bugzilla.redhat.com/show_bug.cgi?id=785772
Reset all known bond options to their default values, not just the
ones that NMSettingBond allows overriding. Also, remove any bond
slaves that were already attached to the bond before we managed it.
Only update bond parameters that need to be updated. In particular,
setting either arp_interval or miimon to 0 has the side effect of also
setting the other one to 0, so don't do that if it's already 0.
Fix the handling of arp_ip_target; the sysfs arp_ip_target node does
not work the same way as the ifcfg BONDING_OPTS line (which is what
the code was assuming before).
libnl3 wants a destination address when setting a route, so just hand
it '::' with a address len of 0 so we don't get -NLE_MISSING_ATTR
when trying to set the IPv6 default route.
We need to set the interface's firewall zone before we kick off
any sort of IP configuration, so that rules for stuff like
DHCP are already handled by the time that these services are started.
With the switch to IPv4 being allowed to fail by default we need
to clean up this old code a bit. PPP failure during IP config
should trigger a timeout, and the core code will handle whether
to fail the device completely or not. But if we got a valid IPv4
config and PPP failed later, the device gets failed. Previously
the device would just sit in IP_CONFIG state because now IPv4
defaults may-fail to TRUE, and when PPP failed the
nm_device_ip_config_should_fail() check would obviously not pass.
This should fix the warning "failed to allocate link cache" when a
new device is added. It doesn't affect WiFi operation, and the
code would fall back to non-nl80211 mechanisms of detecting whether
a device was wifi or not, so it corrects this check and quiets the
error message.
The kernel is broken for Ad-Hoc WPA, and creates the connections
as open connections instead. Yeah, eventually we can use
wpa_supplicant with RSN support, but for now we just have to
disable Ad-Hoc WPA because it's a problem to say we're creating
a protected network but then have the kernel not do that for
us. Will be re-enabled once all the necessary bits have been
fixed.
Note that Ad-Hoc WPA has been broken since at least 2.6.32 with
mac80211-based drivers, which is what most users will be using.
It is currently not possible to create a connection where the
connection-type-specific NMSetting has all default values. This hasn't
been a problem in the past because each type had at least one property
that either had no default value or had a default value that didn't
pass verify(). But NMSettingInfiniband didn't have that property, so
it's impossible to create an InfiniBand connection unless you change
the value of at least InfiniBand-specific setting.
Work around this for now by making the default value of
NMSettingInfiniband:transport-mode be NULL, so it needs to be
overridden.
Like IPv4, if the connection contains no IPv6 setting, perform
IPv6 addressing. Since may-fail defaults to TRUE for IPv6, failure
should have no consequence.
This will allow DNSSEC data to be visible in browsers, which would otherwise
not be the case by default because of dnsmasq acting as a middle-man for
resolution.
Otherwise, we have a regression from the libc resolver behavior.
When using the either DHCP or STATIC IpMethods the modem manager
or device itself negotiates the PPP session so we need to pass
the authentication preferences through to MM.
Notes:
1/ Using a bitfield now that happens to match the Ericsson
in the lower orders so that it's far more tidy.
2/ Devices that wish to utilise this should observe the
following:
If the bitfield doesn't exist in the dict, then MM uses the
modem default, if it does, MM tries to fulfill the request. If the
modem can only accept one value (Qualcomm-type devices accept only
None, PAP or CHAP with AT$QCPDPP) then MM picks the appropriate one
from the dict if only one of PAP or CHAP was given, otherwise we
default to PAP.
(dcbw: make enum a bitfield instead of the bit position)
(comments by dcbw)
This allows out-of-the-box connectivity on IPv6-only networks.
Once caveat is that connections where the user currently
expects no IPv4 connectivity to terminate the connection and
retry will no longer do so until IPv6 also times out, and if
that network where IPv4 is expected to fail also has an IPv6
router sending advertisements, the connection will succeed
instead of failing. That can be resolved by setting the
right bit in the connection's config file; and it's expected
that the number of users who expect IPv4 failure on a
network with usable IPv6 connectivity is quite small
compared to the benefit of OOB IPv6 connectivity.
