The old ieee80211 code only remains as a support library for the ipw2100
and ipw2200 drivers. So, move the code and rename it appropriately to
reflects it's true purpose and status.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
These bits are shared already between ipw2x00 and hostap, and could
probably be shared both more cleanly and with other drivers. This
commit simply relocates the code to lib80211 and adjusts the drivers
appropriately.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The generic packet receive code takes care of setting
netdev->last_rx when necessary, for the sake of the
bonding ARP monitor.
Signed-off-by: David S. Miller <davem@davemloft.net>
It is unnecessary and of questionable value. Also remove
is_empty_ssid, as it is also unnecessary.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This converts pretty much everything to print_mac. There were
a few things that had conflicts which I have just dropped for
now, no harm done.
I've built an allyesconfig with this and looked at the files
that weren't built very carefully, but it's a huge patch.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
trying to clean up the signal/noise code. the previous code in mac80211 had
confusing names for the related variables, did not have much definition of
what units of signal and noise were provided and used implicit mechanisms from
the wireless extensions.
this patch introduces hardware capability flags to let the hardware specify
clearly if it can provide signal and noise level values and which units it can
provide. this also anticipates possible new units like RCPI in the future.
for signal:
IEEE80211_HW_SIGNAL_UNSPEC - unspecified, unknown, hw specific
IEEE80211_HW_SIGNAL_DB - dB difference to unspecified reference point
IEEE80211_HW_SIGNAL_DBM - dBm, difference to 1mW
for noise we currently only have dBm:
IEEE80211_HW_NOISE_DBM - dBm, difference to 1mW
if IEEE80211_HW_SIGNAL_UNSPEC or IEEE80211_HW_SIGNAL_DB is used the driver has
to provide the maximum value (max_signal) it reports in order for applications
to make sense of the signal values.
i tried my best to find out for each driver what it can provide and update it
but i'm not sure (?) for some of them and used the more conservative guess in
doubt. this can be fixed easily after this patch has been merged by changing
the hardware flags of the driver.
DRIVER SIGNAL MAX NOISE QUAL
-----------------------------------------------------------------
adm8211 unspec(?) 100 n/a missing
at76_usb unspec(?) (?) unused missing
ath5k dBm dBm percent rssi
b43legacy dBm dBm percent jssi(?)
b43 dBm dBm percent jssi(?)
iwl-3945 dBm dBm percent snr+more
iwl-4965 dBm dBm percent snr+more
p54 unspec 127 n/a missing
rt2x00 dBm n/a percent rssi+tx/rx frame success
rt2400 dBm n/a
rt2500pci dBm n/a
rt2500usb dBm n/a
rt61pci dBm n/a
rt73usb dBm n/a
rtl8180 unspec(?) 65 n/a (?)
rtl8187 unspec(?) 65 (?) noise(?)
zd1211 dB(?) 100 n/a percent
drivers/net/wireless/ath5k/base.c: Changes-licensed-under: 3-Clause-BSD
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If print_mac() is used inside of a pr_debug() the compiler
can't see that the call is redundant so still performs it
even of pr_debug() ends up being a nop.
So don't use print_mac() in such cases in hot code paths,
use MAC_FMT et al. instead.
As noted by Joe Perches, pr_debug() could be modified to
handle this better, but that is a change to an interface
used by the entire kernel and thus needs to be validated
carefully. This here is thus the less risky fix for
2.6.25
Signed-off-by: David S. Miller <davem@davemloft.net>
It's only a debugging printk, so it went unnoticed; still, the
fix is trivial, so...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Make it match the on-the-wire endianness, eliminate byteswapping.
The only driver that used this sucker (ipw2200) updated.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reported by Chris Evans <scarybeasts@gmail.com>:
> The summary is that an evil 80211 frame can crash out a victim's
> machine. It only applies to drivers using the 80211 wireless code, and
> only then to certain drivers (and even then depends on a card's
> firmware not dropping a dubious packet). I must confess I'm not
> keeping track of Linux wireless support, and the different protocol
> stacks etc.
>
> Details are as follows:
>
> ieee80211_rx() does not explicitly check that "skb->len >= hdrlen".
> There are other skb->len checks, but not enough to prevent a subtle
> off-by-two error if the frame has the IEEE80211_STYPE_QOS_DATA flag
> set.
>
> This leads to integer underflow and crash here:
>
> if (frag != 0)
> flen -= hdrlen;
>
> (flen is subsequently used as a memcpy length parameter).
How about this?
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
After 13 years of use, it looks like my email address is finally going
to disappear. While this is likely to drop the amount of incoming spam
greatly ;-), it may also affect more appropriate messages, so let's
update my email address in various places. In addition, Host AP mailing
list is subscribers-only and linux-wireless can also be used for
discussing issues related to this driver which is now shown in
MAINTAINERS.
Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
To clearly state the intent of copying to linear sk_buffs, _offset being a
overly long variant but interesting for the sake of saving some bytes.
Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
To clearly state the intent of copying from linear sk_buffs, _offset being a
overly long variant but interesting for the sake of saving some bytes.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Now to convert the last one, skb->data, that will allow many simplifications
and removal of some of the offset helpers.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
So that it is also an offset from skb->head, reduces its size from 8 to 4 bytes
on 64bit architectures, allowing us to combine the 4 bytes hole left by the
layer headers conversion, reducing struct sk_buff size to 256 bytes, i.e. 4
64byte cachelines, and since the sk_buff slab cache is SLAB_HWCACHE_ALIGN...
:-)
Many calculations that previously required that skb->{transport,network,
mac}_header be first converted to a pointer now can be done directly, being
meaningful as offsets or pointers.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Renaming skb->h to skb->transport_header, skb->nh to skb->network_header and
skb->mac to skb->mac_header, to match the names of the associated helpers
(skb[_[re]set]_{transport,network,mac}_header).
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This time of the type:
skb->nh.iph = (struct iphdr *)skb->data;
That is completely equivalent to:
skb->nh.raw = skb->data;
Wonder why people love casts... :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For the common, open coded 'skb->nh.raw = skb->data' operation, so that we can
later turn skb->nh.raw into a offset, reducing the size of struct sk_buff in
64bit land while possibly keeping it as a pointer on 32bit.
This one touches just the most simple case, next will handle the slightly more
"complex" cases.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For the common, open coded 'skb->mac.raw = skb->data' operation, so that we can
later turn skb->mac.raw into a offset, reducing the size of struct sk_buff in
64bit land while possibly keeping it as a pointer on 32bit.
This one touches just the most simple case, next will handle the slightly more
"complex" cases.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
One less thing for drivers writers to worry about.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
And use kmemdup and kzalloc where applicable
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In the SoftMAC version of the IEEE 802.11 stack, not all duplicate messages are
detected. For the most part, there is no difficulty; however for TKIP and CCMP
encryption, the duplicates result in a "replay detected" log message where the
received and previous values of the TSC are identical. This change adds a new
variable to the ieee80211_device structure that holds the 'seq_ctl' value for
the previous frame. When a new frame repeats the value, the frame is dropped and
the appropriate counter is incremented.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds a host_strip_iv_icv flag to ieee80211 which indicates that
ieee80211_rx should strip the IV/ICV/other security features from the payload.
This saves on some memmove() calls in the driver and seems like something that
belongs in the stack as it can be used by bcm43xx, ipw2200, and zd1211rw
I will submit the ipw2200 patch separately as it needs testing.
This patch also adds some sensible variable reuse (idx vs keyidx) in
ieee80211_rx
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The "ieee80211: Workaround malformed 802.11 frames from AP" patch (see
http://kernel.org/git/?p=linux/kernel/git/linville/wireless-2.6.git;a=commit;h=f09fc44d8c25f22c4d985bb93857338ed02feac6 )
fixes the problem with some buggy APs but also converts debug message into
an error one. This floods the log with errors when you are near such AP (you
get a message for every beacon). This patch reverts the error message back
to the debug one.
Signed-off-by: Jiri Benc <jbenc@suse.cz>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Stop processing further but return success when we receive a malformed
packet from the AP. We need this patch to workaround some AP bugs. For
example, the beacon frames from the Orinoco AP1000 contains an IE (value
= 128) with length equals to 8 but the actual frame length is only 7.
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ieee80211_rx_any is new to 2.6.18-rc1, even though it appears this function
was never completed:
http://lists.sipsolutions.net/pipermail/softmac-dev/2006-February/000103.html
This patch changes ieee80211_rx_any to always claim the skb, which avoids
further driver complexity and the possibility of leaking management frames.
It also exports the function so that people can actually use it.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This adds a flag to the ieee80211_network structure which indicates whether
the stored erp_value is valid (a check against 0 is not enough, since an ERP
of 0 is valid and very meaningful).
I also added the ERP IE bit-definitions to ieee80211.h.
This is needed by some upcoming softmac patches.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
WARNING: /lib/modules/2.6.17-mm2/kernel/net/ieee80211/ieee80211.ko
needs unknown symbol wireless_spy_update
Someone removed the `#ifdef CONFIG_WIRELESS_EXT' from around the callsite
in net/ieee80211/ieee80211_rx.c and didn't update Kconfig appropriately.
The offending patchset seems to be 35c14b855f
which is tittled
[PATCH] ieee80211: remove unnecessary CONFIG_WIRELESS_EXT checking
After a quick look it seems that wireless_spy_update() lives in
net/core/wirless.c, and that file is only compiled if
CONFIG_WIRELESS_EXT is set. Perhaps this is Kconig work, but
in the mean time here is a reversal of the recent change.
Signed-Off-By: Horms <horms@verge.net.au>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
this patch fixes coverity id #913. ieee80211_monitor_rx() passes the skb
to netif_rx() and we should not reference it any longer.
Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Version 2 of the patch. Added checks for version 0
and proper from/to DS bits. Even in promisc
mode we won't receive packets from another BSSes.
bcm43xx_rx() contains code to filter out packets from
foreign BSSes and decide whether to call ieee80211_rx
or ieee80211_rx_mgt. This is not bcm specific.
Patch adapts that code and adds it to 80211
as ieee80211_rx_any() function.
Signed-off-by: Denis Vlasenko <vda@ilport.com.ua>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes a problem in the ieee80211 probe response and beacon
reception code that would use the packet statistics for a network even
if they were received on a channel other than that which the network
exists on.
This causes a problem in overlapping channels where, for example, a
strong AP on channel 2 could have its beacons received on channels 1 and
3, but at much lower signal levels. If scanning was done sequentially,
this means the beacon received on channel 3 would update the AP's signal
level as being much lower than it really is, which subsequently could
cause that AP to be passed over and an alternate AP selected.
Signed-off-by: James Ketrenos <jketreno@linux.intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix QoS is not active even the network and the card is QOS enabled.
The problem is we pass the wrong ieee80211_network address to
ipw_handle_beacon/ipw_handle_probe_response, thus the
ieee80211_network->qos_data.active will not be set, causing the driver
not sending QoS frames at all.
Signed-off-by: Hong Liu <hong.liu@intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On my system, I get unhandled management functions corresponding
to IEEE80211_STYPE_REASSOC_REQ and IEEE80211_STYPE_ASSOC_REQ. The
attached patch adds the logic to pass these requests off to a user
stack. The patches to implement these requests in softmac have already
been sent to Johannes Berg.
Signed-Off-By: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch contains the following changes:
- add a CONFIG_WIRELESS_EXT select'ed by NET_RADIO for conditional
code
- remove the now no longer required #ifdef CONFIG_NET_RADIO from some
#include's
Based on a patch by Jean Tourrilhes <jt@hpl.hp.com>.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch, generated against 2.6.16-rc1-git4, corrects two typographical
errors in ieee80211_rx.c and adds the facility name to a bare printk.
Signed-Off-By: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
