and antenna diversity:
Check the hardware capabilities---transmit power control (TPC),
antenna diversity---before setting up the sysctls that control
those capabilities. Previously, the TPC and ant. diversity sysctls
were not setup because ath_sysctlattach was called before sc_hastpc
and sc_hasdiversity were initialized, so users could not view/control
antenna diversity or TPC settings, even on hardware with those
capabilities.
Obey the user's transmit-antenna selection even when sending IBSS
beacons on hardware with VEOL capability; for all other hardware/modes,
only switch transmit antennas after every four beacons if the user
has not selected a transmit antenna---i.e., they chose antenna 1
or 2 instead of 0 ("auto").
the NIC decryptes & decapsulates WEP frames before passing them to
the host. "Remember" the state of IEEE80211_F_DROPUNENC in
sc_ic_flags, though, and try our best to honor it as we setup the
hardware state.
This is the second patch of this kind. The previous patch was
badly broken because wi_mend_flags was basing its decision to clear
IEEE80211_F_DROPUNENC based on the operating state we were
transitioning FROM instead of the state we were transitioning TO.
This fixes a bug that Simon Burge reported, where dhclient wi0
would not get a lease unless and until you ran 'ifconfig wi0'
concurrently (which would frob the IEEE80211_F_DROPUNENC bit in
the right way). This patch was tested by Simon with his Toshiba
Lucent-clone.
back out my change to ieee80211_crypto_encap that made it free its
mbuf argument on error. I had thought it was a bug. It was not.
It's the drivers that are broken. Make an(4), atw(4), ipw(4),
iwi(4), ral(4), rtw(4), ural(4), and wi(4) free the mbuf when
ieee80211_crypto_encap returns NULL. Also, return ath(4) to the
way it was---i.e., free the mbuf.
Thanks to Sam Leffler to pointing out my mistake.
+ Synchronize ath_calibrate() with ATH_LOCK()/ATH_UNLOCK(). Thanks
to Steve Woodford for suggesting this fix. This patch stops
ath(4) from generating messages "hardware error; resetting" while
Steve's D-Link DWL-AG650 card is operating (kern/28385). The
MiniPCI wireless adapter on one of my Soekris boards also operates
more reliably following this patch.
+ Use ATH_LOCK_IMPL() and family to synchronize access to the
transmit queue, also.
rate, with short preamble turned *off*. Fixes IBSS operation,
where multicast frames were sent at the highest possible rate with
short preamble turned *on*, so the likelihood of reception was
relatively low, and there was no chance for stations w/o short
preamble capability to receive the frames.
XXX This is a quick fix that I will revisit very soon. Multicast
data frames are eligible to be sent with short preamble in
IEEE80211_M_STA, IEEE80211_M_HOSTAP modes. An AP knows who all of
its peers are at all times, so it can make an intelligent decision.
Ditto the AP client.
XXX The rate adaptation should be involved in choosing short/long
preamble. Also, we can make a reasonable choice of a higher
multicast data rate based on statistics gathered by the rate
adaptation module.
Damien Bergamini, ported and submitted by FUKAUMI Naoki per PR kern/30449
I've modified the USB "ural" driver for recent changes to the NetBSD
ieee80211 framework, possibly not completely, but with an ASUS wireless
adapter I'm getting some signs of life.
Didn't care about pci/cardbus for now, hopefully someone with hardware
will do it.
receive direction, while software handles WEP in the transmit
direction. When net80211 calls rtw's rtw_key_set with a WEP key,
I point the key's wk_cipher at our "fake" cipher, rtw_cipher_wep,
which is alike to ieee80211_cipher_wep except it provides a different
crypto-decapsulation routine, rtw_wep_decap. rtw_wep_decap copies
the key passed to it by net80211, clears the key's SWCRYPT flag,
and then calls wep_decap. Now wep_decap will decapsulate, but it
will *not* re-decrypt.
XXX I need to check whether the hardware supports 40-bit WEP,
XXX 104-bit WEP, or both, and act accordingly.
the RX direction, but not in the TX direction. The
net80211 crypto framework doesn't seem to cope very well
with the assymetry (I'm probably missing something), so
I will use software WEP for now.
net80211: In ieee80211_compute_duration, figure out whether to add
the WEP header to the packet overhead by checking the
WEP bit in the Frame Control field of the 802.11 header,
instead of checking the IEEE80211_F_PRIVACY flag.
Also, if the WEP bit is present, assume that the frame
described by (wh, len) has already already been WEP
encapsulated, and adjust the payload length accordingly.
XXX that's a grotty hack that I will have to revisit,
later.
net80211. It was especially important to zero the IEEE80211_F_DROPUNENC
(discard unencrypted packets) flag in operating modes where the
firmware decrypts for us. Otherwise, the 802.11 layer discarded
all received frames. See wi_mend_flags. From FreeBSD, with
improvements by me.
For better compliance with the "net80211 way":
set sc_cnfauthmode from ic->ic_bss->ni_authmode. Enter
the RUN state through ieee80211_create_ibss instead of
ieee80211_new_state(IEEE80211_S_RUN). To sync BSSID in ad hoc
mode, use ieee80211_sta_join() instead of
ieee80211_new_state(IEEE80211_S_RUN). From FreeBSD.
Configure the firmware to obey IEEE80211_F_DROPUNENC.
As we change to state RUN in STA mode, generate a link-status
message on the routing socket with a call to ieee80211_notify_node_join()
instead of calling rt_ifmsg directly.
Run normal net80211 processing (ieee80211_newstate) on the ->RUN
transition.
The __UNCONST macro is now used only where necessary and the RW macros
are gone. Most of the changes here are consumers of the
sysctl_createv(9) interface that now takes a pair of const pointers
which used not to be.
pcmcia devices, the drive may still be doing its power-on reset.
XXX From the specs the delay could be up to 31s here, but we don't want to
wait for 31s if we have a channel with no drives and pull-up resitors on
the bus.
Based on patch submitted in kern/25659 by Steven M. Bellovin, part of fix for
kern/25659.
it appears to break output on the Soekris net4501, which is a rather
popular platform.
This should fix PR kern/29612 -- if not, I will probably revert it again.
dyoung