| Age | Commit message (Collapse) | Author |
|---|
|
ifq dequeue semantics. This basically means we need to check for
available space before dequeuing a packet. As soon as we dequeue
a packet we commit to it. On the PCIe backend this check can not
be done easily since the flowring depends on the packet contents and
we cannot take a peek. When there is no flowring we cache the mbuf
and send it out as soon as the flowring opened up. Then the ifq can
be restarted and traffic can flow. Typically we usually run out of
packet ids, which can be checked without consulting the packet. The
flowring probably never becomes full as the bwfm(4) firmware takes
the packets off the ring without actually sending them out.
Discussed with dlg@
|
|
macppc. Receiving packets stopped, ifconfig down/up made it work
again.
In the tick timeout handler refill the receive ring if it is empty.
The logic is taken from hme(4). Also protect the register access
and ifp counters with splnet().
In gem_rx_watchdog() is a workaround for a hardware bug. It resets
the hardware when there is no progress. If the fifo pointers
advanced a bit, it got stuck anyway. So restart the receive watchdog
timeout in that case.
OK mpi@
|
|
function so it can be shared with the SDIO attachment driver.
|
|
into one header specific to the SDIO attachment driver. Also
add more register and protocol definitions to it.
|
|
in the SDIO bus glue.
|
|
version of the SOCRAM one.
|
|
|
|
|
|
a state transitioning race condition. Event packets, like completing
authentication and the following association completion, are usually
received shortly after another. The code that handles those events is
scheduled using a task, so it can easily happen that the state change
caused by the authentication packet was not done before the following
association event arrived. By moving the event packet handling into the
same context as the state task we serialize the processing and remove
the race condition. Fixes connecting to the 5GHz WiFi AP used at a2k18.
ok stsp@
|
|
CID 1464695; pointed out to me by mikeb@
|
|
transitions, which means those state transition won't be shown in dmesg
in interface debug mode. Make drivers print these transitions themselves.
ok patrick@
|
|
There was code which set them up but didn't include 11b channels which
are part of 11g. And there was a hack which effectively stripped important
flag bits away and wouldn't work for modes with overlapping channels (b/g).
As a result, some flags were missing from 11g channels the driver reported
to net80211, which skipped over those channels when building the media list.
This gets us one step closer to supporting the AR5424.
ok mpi@
|
|
handle, into a debug printf. Also do not print a pointer to kernel buffers
so that we don't leak kernel addresses.
Spotted by and ok stsp@
|
|
with nicer integer equivalents.
Spotted by and ok stsp@
|
|
|
|
apply the channel to the node, like iwm(4) does, when supplying the
scan response to the net80211 stack. Our stack uses this information
for node selection so it's elementary for it to be correct.
Tested by jcs@
|
|
ok dlg
|
|
point including WPA2 support. We now have a different event mask per
mode, so that events that are only useful for STA mode don't interfere
with HOSTAP mode. Power savings is disabled when we act as AP. The
connection events generate 802.11 frames for handling auth/assoc and
deauth/deassoc so that our stack takes note of the connecting nodes.
|
|
settings.
|
|
on TOS values. In AP mode create multiple flowrings per connected node.
|
|
we typically have about four flowrings per priority. As access point
we apparently need one, or four considering the priorities, flowrings
per client. For now let's start with a single TX flowring. To setup
a flowring we need to send a create request and can only start sending
packets as soon as we are told that the ring is created. With this we
can now do actual network traffic.
|
|
happens when we successfully associate and the AP tries to initiate the
WPA2 handshake but we haven't received the asynchronous ASSOC event yet.
Dropping the packet will make the AP retry, and at that point we should
have successfully associated. While there, don't feed the event packets
to our network stack. It's been helpful for debugging but now it's time
to let go.
|
|
reached the RUN state, this probably means that we have roamed to
a different AP. In that case throw us back into SCAN mode and let
the stack look for a new AP to connect to. In the future it might
be worthwhile to use the ROAM event information to read the new AP
information to adjust our stack, but that is further down the road.
|
|
we have to move to the "trying to" ASSOC state. When association has
finished we will receive an ASSOC event, so that we can move into the
RUN state. After that point we will receive ethernet packets and the
WPA2 handshake can occur. The SET_SSID event will now only be used to
bring us back into SCAN when it notes an error, as it often completes
after we have already done the WPA2 handshake and can not be used to
switch between the different states.
|
|
on big endian archs the 1 is shifted to the high byte, which then
gets lost when it's assigned to the uint8_t. at worst we lose the
value, at best the compiler has a teary and fixes it.
this is the fix for a compiler teary.
ok claudio@
|
|
push the mbuf allocation down into the USB attachment code and now pass
an mbuf to the bwfm(4) receive function.
|
|
ok deraadt@ krw@
|
|
ok millert@ krw@
|
|
for-loops. Oops.
|
|
Intel machines.
|
|
Intel machines.
|
|
we chose instead of any AP the firmware chooses based on the SSID.
|
|
variable.
|
|
fix up the code for the Cortex-R4 which works the same.
|
|
|
|
|
|
the PCIe-based BCM43602's firmware in the PCI attachment driver.
|
|
|
|
|
|
made empty. Found by new ctfconv(1) feature and validated by clang.
ok mpi@
|
|
iic(4) controllers.
ok jcs@
|
|
measured RSSI values. The same is already done for USB devices.
RSSI values shown in ifconfig make sense now.
ok kevlo@
|
|
values occur. Add macros to access RSSI info in ds_status4 as well.
ok kevlo@
|
|
ok kettenis
|
|
ok jsg@, stsp@
|
|
a user perspective, it's rather horrible from a security perspective.
Especially since there has not only been the KRACK attack, but also
exploited wireless firmware. Thus this commit changes the way that
bwfm(4) is integrated into our network stack. Instead of making it
an Ethernet controller with some WiFi capability, deeply integrate
it into the net80211 stack. This way we can do the WPA handshake in
software and we don't have to reimplement or copy too much code from
the net80211 stack. Some code taken from NetBSD where Jared McNeill
committed bwfm(4) with net80211 integration as well.
Discussed with and "looks good" stsp@
|
|
|
|
be properly enabled by the correct ioctls.
|
|
which can handle those ioctls quite well for us.
|
|
send us any answers to our request.
|
