count handling of station entries in hostap mode:
Input path:
o driver is now expected to find the node associated with the
sender of a received frame; use ic_bss if none is located
o driver passes the (referenced) node into ieee80211_input for
use within the wlan module and is responsible for cleaning up
on return
o the antenna state is no longer passed up with each frame; this
is now considered driver-private state and drivers are responsible
for keeping it in the driver-private part of a node
Output path:
Revamp output path for management frames to eliminate redundant
locking that causes problems and to correct reference counting
bogosity that occurs when stations are timed out due to inactivity
(in AP mode). On output the refcnt'd node is stashed in the pkthdr's
recvif field (yech) and retrieved by the driver. This eliminates
an unref/ref scenario and related node table unlock/lock due to the
driver looking up the node. This is particularly important when
stations are timed out as this causes a lock order reversal that
can result in a deadlock. As a byproduct we also reduce the overhead
for sending management frames (minimal). Additional fallout from
this is a change to ieee80211_encap to return a refcn't node for
tieing to the outbound frame. Node refcnts are not reclaimed until
after a frame is completely processed (e.g. in the tx interrupt
handler). This is especially important for timed out stations as
this deref will be the final one causing the node entry to be
reclaimed.
Additional semi-related changes:
o replace m_copym use with m_copypacket (optimization)
o add assert to verify ic_bss is never free'd during normal operation
o add comments explaining calling conventions by drivers for frames
going in each direction
o remove extraneous code that "cannot be executed" (e.g. because
pointers may never be null)
newer lucent/hermes firmware than indicated (investigating). I'm committing
this now since it shouldn't hurt anything.
o Vaguely related, add bogus frame length check from netbsd.
Obtained from: netbsd
Add two new arguments to bus_dma_tag_create(): lockfunc and lockfuncarg.
Lockfunc allows a driver to provide a function for managing its locking
semantics while using busdma. At the moment, this is used for the
asynchronous busdma_swi and callback mechanism. Two lockfunc implementations
are provided: busdma_lock_mutex() performs standard mutex operations on the
mutex that is specified from lockfuncarg. dftl_lock() is a panic
implementation and is defaulted to when NULL, NULL are passed to
bus_dma_tag_create(). The only time that NULL, NULL should ever be used is
when the driver ensures that bus_dmamap_load() will not be deferred.
Drivers that do not provide their own locking can pass
busdma_lock_mutex,&Giant args in order to preserve the former behaviour.
sparc64 and powerpc do not provide real busdma_swi functions, so this is
largely a noop on those platforms. The busdma_swi on is64 is not properly
locked yet, so warnings will be emitted on this platform when busdma
callback deferrals happen.
If anyone gets panics or warnings from dflt_lock() being called, please
let me know right away.
Reviewed by: tmm, gibbs
o add back rx monitor support
o make WI_RID_SCAN_RES DTRT
o fix a bug handling zero-length RID requests (used by dstumbler to set
a zero-length SSID)
o make RID_SCAN_REQ DTRT
o add back WI_RID_OWN_SSID
o fix wi_scan_ap to take a channel mask and txrate (for prism cards)
These changes fix dstumbler -o (monitor mode). A minor change to dstumbler
is needed to get normal AP scanning mode to work right; this is preferred to
modifying the driver.
PR: kern/53187
Reviewed by: Bruce M Simpson <bms@spc.org>
than once. This appears to work around the hanging issues, at the
expense of warnings about bad RID allocations. I'm not sure this is a
permanant workaround, but does appear to help in the tests that I've
done here.
that one cannot generally hold a lock and call bus_teardown_intr.
This is race free with wi_intr because bus_teardown_intr won't allow
wi_intr to be called after it returns.
# jeff hsu points out that there might be a race between this unlock
# and wi_start. While that may be true also, it won't impact this commit.
Submitted by: jhb
firmware 1.50.12, but 2.20.1 and 3.10.4 work. The 1.50.12 card gets
past doing dhclient, but hangs on transmit a little after the ip
address is set. The 1.50.12 card has always been 'cranky' and Bill
Paul's tearing it apart at FreeBSD '99 hasn't helped.
sc_reset and sc_enable are subtlely different things. sc_reset means
exactly "WI_CMD_INI has happened." sc_enabled means "WI_CMD_ENABLE
has been sent to the card without a WI_CMD_DISABLE following." This
is a little different than what they mean on NetBSD (where both of
these concepts are comingled). NetBSD will try to only enable symbol
cards once, while FreeBSD only sends the WI_CMD_INI once.
Also, only try once to reset the card on a symbol.
This makes the lucent cards no worse than before, but apparently not
much better either. I got fewer hangs in my testing than I have in
the past, but I don't know if it is statistically significant or not.
Change 27224 by imp@imp_hammer on 2003/03/22 00:16:22
Put what I think are the correct TX RATE translation tables
in place for LUCENT firmware. This is based on the 4.x driver.
Maybe it should be table driven?
ifconfig wi0 media DS/11Mbps still fails, but it fails before
we even get to the txrate stuff, so other things are wrong.
Change 27225 by imp@imp_hammer on 2003/03/22 00:45:11
Default ic_fixed_rate to -1. This is the same thing as autoselect.
There really should be a #define for this...
one tx buffer for these cards. The old driver only used one. We use
1 for symbol, and 3 for prism cards.
o Don't do the maximum loops thing in the ISR. In fact, revert to the
old interrupt handler. Lucent cards don't seem to work too well if
you don't disable/enable interrupts from the card in the ISR.
Between these two changes, Lucent cards suck less. They work in
autoselect mode only. And seem to get 1Mbps or 2Mbps only. Setting a
specific media speed doesn't work, and I've had a few issues even with
these patches. They turn a former brick into a nearly useful card.
These patches work on the prism 2 and 2.5 PC Card cards that I have.
I've not tested this on PCI cards. I suspect, but couldn't find
proof, that they were the reason that the ISR was changed so radically
from its FreeBSD roots in NetBSD. We might need to have a variant ISR
if so.
code both seem to call wi_start (directly or via the if_start pointer)
without checking to see if OACTIVE is 0. In addition, I think that
with the use of 3 transmit buffers this routine can be called with
OACTIVE set, but I might be mistaken about that (and it doesn't
matter).
Reviewed by: sam
Noticed by: imp, alfred, ambrisko
attach routine, calling WIUNLOCK in the error case of one of the ifs
for that routine is now bogus. This should have been removed when the
WILOCK() was removed, but wasn't.
Submitted by: "Harti Brandt" <brandt@fokus.fraunhofer.de>
at which tx errors are printed (default to 0); hw.wi.debug control the debug
msgs and is only present when WI_DEBUG is defined at compile time (the default
for the moment)
Requested by: imp
o don't strip the Ethernet header from inbound packets; pass packets
up the stack intact (required significant changes to some drivers)
o reference common definitions in net/ethernet.h (e.g. ETHER_ALIGN)
o track ether_ifattach/ether_ifdetach API changes
o track bpf changes (use BPF_TAP and BPF_MTAP)
o track vlan changes (ifnet capabilities, revised processing scheme, etc.)
o use if_input to pass packets "up"
o call ether_ioctl for default handling of ioctls
Reviewed by: many
Approved by: re
and the AT24C08 small serial flash parts. We still report these as
the same part (since we group things already), but now we recognize
the small serial versions as well.
problems with the firmware and will result in a) poor performance and
b) the inability to associate certain types of cards (most notibly
cisco).
Idea obtained from OpenBSD, but I implemented it by clearing the
IFF_PROMISC flag rather than the refusing to honor it downstream.
