specific privilege names to a broad range of privileges. These may
require some future tweaking.
Sponsored by: nCircle Network Security, Inc.
Obtained from: TrustedBSD Project
Discussed on: arch@
Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri,
Alex Lyashkov <umka at sevcity dot net>,
Skip Ford <skip dot ford at verizon dot net>,
Antoine Brodin <antoine dot brodin at laposte dot net>
(1) bpf peer attaches to interface netif0
(2) Packet is received by netif0
(3) ifp->if_bpf pointer is checked and handed off to bpf
(4) bpf peer detaches from netif0 resulting in ifp->if_bpf being
initialized to NULL.
(5) ifp->if_bpf is dereferenced by bpf machinery
(6) Kaboom
This race condition likely explains the various different kernel panics
reported around sending SIGINT to tcpdump or dhclient processes. But really
this race can result in kernel panics anywhere you have frequent bpf attach
and detach operations with high packet per second load.
Summary of changes:
- Remove the bpf interface's "driverp" member
- When we attach bpf interfaces, we now set the ifp->if_bpf member to the
bpf interface structure. Once this is done, ifp->if_bpf should never be
NULL. [1]
- Introduce bpf_peers_present function, an inline operation which will do
a lockless read bpf peer list associated with the interface. It should
be noted that the bpf code will pickup the bpf_interface lock before adding
or removing bpf peers. This should serialize the access to the bpf descriptor
list, removing the race.
- Expose the bpf_if structure in bpf.h so that the bpf_peers_present function
can use it. This also removes the struct bpf_if; hack that was there.
- Adjust all consumers of the raw if_bpf structure to use bpf_peers_present
Now what happens is:
(1) Packet is received by netif0
(2) Check to see if bpf descriptor list is empty
(3) Pickup the bpf interface lock
(4) Hand packet off to process
From the attach/detach side:
(1) Pickup the bpf interface lock
(2) Add/remove from bpf descriptor list
Now that we are storing the bpf interface structure with the ifnet, there is
is no need to walk the bpf interface list to locate the correct bpf interface.
We now simply look up the interface, and initialize the pointer. This has a
nice side effect of changing a bpf interface attach operation from O(N) (where
N is the number of bpf interfaces), to O(1).
[1] From now on, we can no longer check ifp->if_bpf to tell us whether or
not we have any bpf peers that might be interested in receiving packets.
In collaboration with: sam@
MFC after: 1 month
rather than in ifindex_table[]; all (except one) accesses are
through ifp anyway. IF_LLADDR() works faster, and all (except
one) ifaddr_byindex() users were converted to use ifp->if_addr.
- Stop storing a (pointer to) Ethernet address in "struct arpcom",
and drop the IFP2ENADDR() macro; all users have been converted
to use IF_LLADDR() instead.
- WEP TX fix:
The original code called software crypto, ieee80211_crypto_encap(),
which never worked since IEEE80211_KEY_SWCRYPT was never flagged due to
ieee80211_crypto_newkey() assumes that wi always supports hardware based
crypto regardless of operational mode(by virtue of IEEE80211_C_WEP).
This fix works around that issue by adding wi_key_alloc() to force
the use of s/w crypto. Also if anyone ever decides to cleanup ioctl
handling where key changes wouldn't cause a call to wi_init() every time,
we'll need wi_key_alloc() to DTRT.
In addition to that, this fix also adds code to wi_write_wep() to force
existing keys to be switched between h/w and s/w crypto such that an
operation mode change(sta <-> hostap) will flag IEEE80211_KEY_SWCRYPT
properly.
- WEP RX fix:
Clear IEEE80211_F_DROPUNENC even in hostap mode. Quote from Sam:
"This is really gross but I don't see an easy way around it.
By doing it we lose the ability to independently drop unencode
frames (and support mixed wep/!wep use). We should really be
setting the EXCLUDE_UNENCRYPTED flag written in wi_write_wep
based on IEEE80211_F_DROPUNENC but with our clearing it we can't
depend on it being set properly."
Reported by: Holm Tiffe <holm at freibergnet dot de>
Submitted by: sam
MFC after: 3 days
could get an interrupt after we free the ifp, and the interrupt
handler depended on the ifp being still alive, this could, in theory,
cause a crash. Eliminate this possibility by moving the if_free to
after the bus_teardown_intr() call.
for the spl-era locking, but now that we can have multiple, concurrent
interrupts for multiple wi devices, having a global check to make sure
at most one of them was in wi_cmd no longer makes sense.
MFC After: 2 decifortnight
o add ic_curchan and use it uniformly for specifying the current
channel instead of overloading ic->ic_bss->ni_chan (or in some
drivers ic_ibss_chan)
o add ieee80211_scanparams structure to encapsulate scanning-related
state captured for rx frames
o move rx beacon+probe response frame handling into separate routines
o change beacon+probe response handling to treat the scan table
more like a scan cache--look for an existing entry before adding
a new one; this combined with ic_curchan use corrects handling of
stations that were previously found at a different channel
o move adhoc neighbor discovery by beacon+probe response frames to
a new ieee80211_add_neighbor routine
Reviewed by: avatar
Tested by: avatar, Michal Mertl
MFC after: 2 weeks
IFF_DRV_RUNNING, as well as the move from ifnet.if_flags to
ifnet.if_drv_flags. Device drivers are now responsible for
synchronizing access to these flags, as they are in if_drv_flags. This
helps prevent races between the network stack and device driver in
maintaining the interface flags field.
Many __FreeBSD__ and __FreeBSD_version checks maintained and continued;
some less so.
Reviewed by: pjd, bz
MFC after: 7 days
o separate configured beacon interval from listen interval; this
avoids potential use of one value for the other (e.g. setting
powersavesleep to 0 clobbers the beacon interval used in hostap
or ibss mode)
o bounds check the beacon interval received in probe response and
beacon frames and drop frames with bogus settings; not clear
if we should instead clamp the value as any alteration would
result in mismatched sta+ap configuration and probably be more
confusing (don't want to log to the console but perhaps ok with
rate limiting)
o while here up max beacon interval to reflect WiFi standard
Noticed by: Martin <nakal@nurfuerspam.de>
MFC after: 1 week
0. This means that we 'succeed' the attach, even after we've freed
the internal data bits. This leads to a panic when you eject the card
with this problem.
Set error = ENXIO in the mac read zeros case.
over iteration of their multicast address lists when synchronizing the
hardware address filter with the network stack-maintained list.
Problem reported by: Ed Maste (emaste at phaedrus dot sandvine dot ca>
MFC after: 1 week
struct ifnet or the layer 2 common structure it was embedded in have
been replaced with a struct ifnet pointer to be filled by a call to the
new function, if_alloc(). The layer 2 common structure is also allocated
via if_alloc() based on the interface type. It is hung off the new
struct ifnet member, if_l2com.
This change removes the size of these structures from the kernel ABI and
will allow us to better manage them as interfaces come and go.
Other changes of note:
- Struct arpcom is no longer referenced in normal interface code.
Instead the Ethernet address is accessed via the IFP2ENADDR() macro.
To enforce this ac_enaddr has been renamed to _ac_enaddr.
- The second argument to ether_ifattach is now always the mac address
from driver private storage rather than sometimes being ac_enaddr.
Reviewed by: sobomax, sam
machine; instead use the intended entry points. There's still
too much incestuous knowledge about the internals of the
802.11 layer but this at least fixes adhoc mode.
o don't encapsulate on tx; the chip expect a raw frame w/o the crypto header
o clear the WEP bit in the 802.11 header on rx so the 802.11 layer doesn't
try to strip the crypto header
o clobber the "drop unencoded frames" state bit when privacy is enabled so
rx'd frames we pass up to the 802.11 layer are not discarded as unencrypted
This stuff will need to be redone if anyone decides to add WPA support.
your (network) modules as well as any userland that might make sense of
sizeof(struct ifnet).
This does not change the queueing yet. These changes will follow in a
seperate commit. Same with the driver changes, which need case by case
evaluation.
__FreeBSD_version bump will follow.
Tested-by: (i386)LINT
clip/destroy the dB value contained in the wi(4)'s receive frames,
it doesn't match with the flag set in the radiotap header
(unperturbed dB versus dBm).
a new bpf_mtap2 routine that does the right thing for an mbuf
and a variable-length chunk of data that should be prepended.
o while we're sweeping the drivers, use u_int32_t uniformly when
when prepending the address family (several places were assuming
sizeof(int) was 4)
o return M_ASSERTVALID to BPF_MTAP* now that all stack-allocated
mbufs have been eliminated; this may better be moved to the bpf
routines
Reviewed by: arch@ and several others
versions of the firmware. It responds more slowly to commands, and we
bogusly failed them. We assume that all versions of the intersil
firmware before 1.0 are 10 times slower and will give it 10x the time
to finish.
# for 5.2 we should always just assume 5s.
o Back out workaround for not resetting lucent cards more than once. With
these fixes, it appaers they are no longer necessary.
o Set wi_gone when the card goes awol: typically when we get 0xffff back from
the card. Also, don't interact with a card that's gone, so we fail in
seconds rather than minutes. Also reduce amount of time we wait to .5s
in wi_cmd.
o clear wi_gone on ifconfig down to give some cards a chance after they wedge
(this appears to unwedge one of my prism cards with old firmware). ifconfig
up will fail quickly enough if the card really is out to lunch.
o Add delay in wi_init of 100ms.
o wi_stop(ifp, 0->1) changes so that we clear sc_enabled so that we
exit out of the interrupt routine by just acking the interrupt
Submitted by: iedowse
Approved by: re@ (scottl)
# after the freeze I'll fix some of the minor style issues that reviewers
# of this patch have told me about.
operating mode to HostAP, the card will lock up indefinitely (but
the wi(4) driver can recover if you eject the card). The problem is
that the card needs to be "reset" in a way before you even change the
media to hostap. In practice this isn't as noticeable because you
probably do some operation beforehand which prevents the lock-up
before you enable hostap mode.
e.g.:
"ifconfig wi0 up media autoselect mediaopt hostap" will lock up
(if you just inserted the card).
"ifconfig wi0 up ssid foo media autoselect mediaopt hostap" won't lock up.
