Rename all remaining CyaSSL API references to WolfSSL.
Newer WolfSSL have significant DTLS fixes and security
improvements. Continuing to support old CyaSSL releases
would impact the perfomance of encrypted WTP sessions.
Resetting the headers is not enoug, we have to make sure
the transport header points the right position and the
skb->protocol is initialized to the payload protocol.
Swtich sockets to connected when talking to a specific AC. Use
unconnected UDP sockets only during DISCOVERY.
In JOIN, we need send our local address. The old, routing table
based local address discovery is broken for many reasons (VRF,
policy routing, ...). With a connected socket, we can the same
information with a simple getsockname.
During DISCOVERY we are talking to all potential AC's at once.
So using an unconnected socket makes still sense.
Hard coding basic rates is wrong. Each Wifi types does expect
some default basic rates. However those rates are not set in
stone and the AC is permited to set then to whatever it deems
ok. This might prevent client from connecting, but it still is
the AC decission to do so.
This is first step towards a more flexible basic rate handling.
Injecting 802.11 frames underneath the device logic bypasses
the queue logik and leads to delay. Pass 802.3 frames through
the normal device TX chain.
This has the added benefit that AF_PACKET sockets (e.g. tcpdump)
see the send frames.
Reimplmenting what is already there doesn't make sense. Switch
to the existing and UDP tunnel support code and handle the data
channel as a connected UDP socket
* add a kernel bash hash list to track station to
radio and wlan id binding
* enforce binding on recv
* configure binding through netlink interface from
WTP process
Switch to a connected UDP kernel socket. Comparing the
local and remote IPs is no longer required and handling
different IP versions and UDP types is automatic.
The WTP logic needs to reopen the socket on demand now.
RFC 5416 does require IEEE 802.11 WTP Radio Information for
Discovery and Join Response Messages in Chapter 5. However
Chapter 6.25 indicates that this IE should only be included
in the request messages.
