mirror of
https://git.hardenedbsd.org/hardenedbsd/HardenedBSD.git
synced 2024-11-24 09:13:37 +01:00
791be271f1
This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon. |
||
---|---|---|
.. | ||
amd64 | ||
arm | ||
arm64 | ||
boot | ||
bsm | ||
cam | ||
cddl | ||
compat | ||
conf | ||
contrib | ||
crypto | ||
ddb | ||
dev | ||
fs | ||
gdb | ||
geom | ||
gnu | ||
i386 | ||
isa | ||
kern | ||
kgssapi | ||
libkern | ||
mips | ||
modules | ||
net | ||
net80211 | ||
netgraph | ||
netinet | ||
netinet6 | ||
netipsec | ||
netnatm | ||
netpfil | ||
netsmb | ||
nfs | ||
nfsclient | ||
nfsserver | ||
nlm | ||
ofed | ||
opencrypto | ||
pc98 | ||
powerpc | ||
riscv | ||
rpc | ||
security | ||
sparc64 | ||
sys | ||
teken | ||
tests | ||
tools | ||
ufs | ||
vm | ||
x86 | ||
xdr | ||
xen | ||
Makefile |