wpa_supplicant seems to crash from time to time on a NetBSD 4.0 MIPS
platform. The root cause turned out to be a MIPS alignment issue.
In my wpa_supplicant crash case, in function
wpa_driver_bsd_event_receive (from driver_bsd.c), the buf[2048] address
is started from i.e. 0x7fffd546, which is not 4 bytes aligned. Later
when it is casted to (struct if_msghdr *), and rtm->rtm_flags is used.
rtm->rtm_flags is "int" type, but its address is not 4 bytes aligned.
This is because the start address of rtm is not 4 bytes aligned.
Unfortunately in NetBSD MIPS kernel (unlike Linux MIPS kernel emulates
unaligned access in its exception handler), the default behavior is to
generate a memory fault to the application that accesses unaligned
memory address. Thus comes the early mentioned wpa_supplicant crash. An
interesting note is when I'm using the wpa_supplicant version 0.4.9, I
never saw this problem. Maybe the stack layout is different. But I
didn't look into details.
I used below patch to resolve this problem. Now it runs correctly for at
least several hours. But you might have a better fix (maybe we can use
malloc/free so that it is at least cache line aligned?). I'm also not
sure if other drivers should have the same problem.
This adds partial callbacks and events to allow P2P management to be
implemented in a driver/firmware. This is not yet complete and is
very much subject to change in the future.
If the underlying driver supports off-channel TX, it will now be used by
the nl80211 driver wrapper, setting WPA_DRIVER_FLAGS_OFFCHANNEL_TX
accordingly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
With the new kernel functionality coming to Linux to allow off-channel
TX, we can take advantage of that in the P2P code that currently uses
remain-on-channel. If a driver advertises support for it, it will be
asked to handle off-channel TX by itself.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The nl80211 driver can report low ACK condition (in fact it reports
complete loss right now only). Use that, along with a config option, to
disconnect stations when the data connection is not working properly,
e.g., due to the STA having went outside the range of the AP. This is
disabled by default and can be enabled with disassoc_low_ack=1 in
hostapd or wpa_supplicant configuration file.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If a station received unprotected Deauthentication or Disassociation
frame with reason code 6 or 7 from the current AP, there may be a
mismatch in association state between the AP and STA. Verify whether
this is the case by using SA Query procedure. If not response is
received from the AP, deauthenticate.
This implementation is only for user space SME with
driver_nl80211.c.
Previously, pairwise and group cipher suites were configured only
when kernel SME (nl80211 connect API) was used. However, mac80211
needs this information even in the user space SME case for one
thing: to disable HT when TKIP/WEP is used. Add
NL80211_ATTR_CIPHER_SUITES_PAIRWISE to fix this special case with
user space SME. This allows mac80211 to disable HT properly when
the AP is configured with configuration that is not allowed.
This add preliminary code for setting the per-STA RX GTK for
RSN IBSS when nl80211 drivers. For some reason, this does not
seem to fully work, but at least driver_nl80211.c is now aware of
what kind of key is being set and the whatever is missing from
making this key configuration go through should be specific to
nl80211/cfg80211.
When controlling multiple virtual interfaces on the same physical
radio, share the scan results events with sibling interfaces. This
decreases the time it takes to connect many virtual interfaces.
This is currently only supported on Linux with cfg80211-based
drivers when using nl80211 or wext driver interface.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Some drivers are not providing exactly reliable error codes (e.g.,
with WEXT), but others may actually indicate reliable information.
Allow driver wrappers to indicate if that is the case and use
optimizations if so. For now, this improves nl80211 with
NL80211_CMD_CONNECT for a case where connection request fails.
driver_param=use_p2p_group_interface=1 can now be used to test
nl80211-drivers with separate P2P group interface. In other words,
the main interface (e.g., wlan0) is reserved for P2P management
operations and non-P2P connections and a new group interface (e.g.,
p2p-wlan0-0) is created for the P2P group.
This implementation is very minimal, i.e., it only support address
allocation for a single P2P group interface (if the driver does not
handle this internally). In addition, not all functionality has yet
been tested, so for now, this is disabled by default and needs that
special driver_param to enable.
WPA_DRIVER_FLAGS_P2P_MGMT_AND_NON_P2P flag can now be used to
indicate that the initial interface (e.g., wlan0) is used for
P2P management operations and potentially non-P2P connections.
This is otherwise identical to
WPA_DRIVER_FLAGS_P2P_DEDICATED_INTERFACE, but the possibility of
non-P2P connections makes some operations differ.
driver.h defines these functions to return 0 on success, not
number of bytes transmitted. Most callers are checking "< 0" for
error condition, but not all. Address this by following the driver
API specification on 0 meaning success.
The driver wrapper may now indicate the preferred channel (e.g., based
on scan results) on both 2.4 GHz and 5 GHz bands (and an overall best
frequency). When setting up a GO, this preference information is used
to select the operating channel if configuration does not include
hardcoded channel. Similarly, this information can be used during
GO Negotiation to indicate preference for a specific channel based
on current channel conditions.
p2p_group_add command can now use special values (freq=2 and freq=5)
to indicate that the GO is to be started on the specified band.
These are not used by any driver wrapper, i.e., only the four
data queues (BK, BE, VI, VO) are configurable. Better remove these
so that there is no confusion about being able to configure
something additional.
Pass data frames from unknown STAs to hostapd in order to reply with
a Deauthentication or Disassociation frame. This fixes compliance
with IEEE Std 802.11-2007, 11.3.
Furthermore, this does not cause a lot of overhead (at least with
mac80211 drivers) since mac80211 does not pass all data frames (but
at least from unauthenticated and unassociated STAs) to cooked monitor
interfaces.
Tested with rt2800pci on a MIPS board.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
drivers.mak is shared between hostapd and wpa_supplicant and
compiling them together may create "wrong" flags.
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Add a new driver event, EVENT_INTERFACE_UNAVAILABLE, for indicating
that the driver is not able to continue operating the virtual
interface in its current mode anymore, e.g., due to operating
channel for GO interface forced to a DFS channel by another virtual
interface.
When this happens for a P2P group interface, the P2P group will
be terminated and P2P-GROUP-REMOVED event shows the reason for
this as follows:
P2P-GROUP-REMOVED wlan0 GO reason=UNAVAILABLE
If CONFIG_DRIVER_WEXT=y is not used in .config, but driver_wext.c
gets pull in to help another driver wrapper, rfkill code needs to
included to fix the build.
Listen to regulatory event messages from kernel and convert them to
internal driver event notifications indicated that the channel list
may have changed.
The driver wrapper can now indicate whether the driver supports
concurrent operations on multiple channels (e.g., infra STA connection
on 5 GHz channel 36 and P2P group on 2.4 GHz channel 1). If not,
P2P_CONNECT commands will be rejected if they would require
multi-channel concurrency.
The new failure codes for P2P_CONNECT:
FAIL-CHANNEL-UNAVAILABLE:
The requested/needed channel is not currently available (i.e., user has
an option of disconnecting another interface to make the channel
available).
FAIL-CHANNEL-UNSUPPORTED:
The request channel is not available for P2P.
The new nl80211 API means we don't need to use monitor interfaces. This
means that the P2P implementation now requires a kernel that has support
for generic management frame (not just Action frame) transmission.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is backward compatible since older kernels will ignore the extra
attribute and only allow registration for Action frames.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
libnl has a bug, when binding more than two sockets and releasing one,
it will release the wrong address and then try to reuse it, which fails.
Therefore, we need to reimplement the socket address assignment logic
locally for libnl 1.1.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
wpa_supplicant showed signal levels incorrectly with some drivers:
Jun 6 16:29:36 rupert wpa_supplicant[18945]: Current BSS: 00:0d:97:11:40:d6
level=190
Jun 6 16:29:36 rupert wpa_supplicant[18945]: Selected BSS: 00:0d:97:11:50:09
level=192
Judging from output from other tools (iwlist) and the min_diff block
at the end of wpa_supplicant_need_to_roam, it seems these values
should actually be negative. Specifically, if one treats that number
as a signed char instead of unsigned, everything matches up.
To be honest, I've little to no understanding of wireless, but looking
at the source code for wireless-tools (iw_print_stats in iwlib.c), it
seems that the fields of the iw_quality struct need to be decoded
differently depending on various flags. I guess
src/drivers/driver_wext.c should have similar logic in
wext_get_scan_qual.
I wrote a patch that attempts to replicate some of that logic,
although it may be more complicated than is necessary; I think some of
the complexity is for backwards-compatibility, which might not be
necessary depending on wpa_supplicant's dependencies? In any case, it
is attached. Again, I don't know how any of this works, so it's likely
the patch is a bit off. But I think at least the logic to determine
min_diff in wpa_supplicant_need_to_roam would be more accurate if
level were determined correctly.
