Some wireless devices don't support Ad-Hoc mode. Expose this fact in
the wireless capabilities so that clients can disable the hot-spot
option if neither CAP_ADHOC nor CAP_AP is available.
https://bugzilla.gnome.org/show_bug.cgi?id=692869
A new value for NM80211Mode is introduced (NM_802_11_MODE_AP) and the
new mode is passed to wpa_supplicant analogous to adhoc-mode.
The places which need to know the interface mode have been extended to
handle the new mode.
If the configuration does not contain a fixed frequency, a channel is
selected the same way as with adhoc-mode before.
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.
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.
Make the meaning of done actually reflect what's happening,
and make sure that when we get an error in the error handler,
that the processing loop breaks out and returns that error.
This wasn't happening for Ad-Hoc connections, which apparently
return various errors for things, leading to blocking in
recv() in the kernel waiting for more data that would never
come, because we'd already gotten an error.
Would affect non-nl80211 drivers since all nl80211 drivers have the
phyX link in sysfs and thus this code wouldn't get run for them.
Found by Dmitri <mitya@mageia.org>
Clarify how we're supposed to break out of the nl_recvmsgs() loop
and also break out if we get an error from nl_recvmsgs(). What's
supposed to happen is that one of the callbacks we've registered
figures out that we're done and sets the 'done' flag, which then
breaks out of the recvmsgs() loop. Using 'err' there previously
was pretty unclear.
This reverts commit 84403ab84a.
It appears we want to loop until one of the callback says we're
done, while this patch would exit too early (possibly before we'd
received a reply) since nl_recvmsgs() returns 0 on success. What
we really want do do here is wait for one of the callbacks we've
registered to tell us that they've successfully handled the message
and gotten a reply.
