from 1500 to 1496 bytes. The MTU should remain at 1500, extending the
frame size as per IEEE 802.3. Adding IFCAP_VLAN_MTU to the
if_capabilities field in the smsc driver solves the problem. The
datasheet for the LAN9512 chip, section 3.2.3 states that the chip
supports the extended frame.
Submitted by: rpp@ci.com.au
MFC after: 1 week
PR: 205050
- Restore R92C_TXDW4_HWSEQ_EN bit - it is used by non-8188EU chips.
- Fix DRVRATE bit usage.
Tested with:
- RTL8188EU, STA mode.
- RTL8188CUS, STA mode.
Reviewed by: kevlo
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D4352
IPv4/IPv6 checksum offloading and VLAN tag insertion/stripping.
Since uether doesn't provide a way to announce driver specific offload
capabilities to upper stack, checksum offloading support needs more work
and will be done in the future.
Special thanks to Hayes Wang from RealTek who gave input.
- Add error handling for urtwn_(r88e_)read_rom() and
urtwn_efuse_*() functions.
- Remove code duplication between urtwn_efuse_read() and
urtwn_r88e_read_rom().
- Merge r88e_rom and (r92c_)rom structures
(only one of them can be used at the same time).
- Other minor fixes / improvements.
Tested with RTL8188EU, STA mode
(URTWN_DEBUG + USB_DEBUG, hw.usb.urtwn.debug=3, no visual differences).
Reviewed by: kevlo
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D4253
- Split urtwn_tx_start() into urtwn_tx_data() and urtwn_tx_start()
(the last will be used for beacon updates / raw xmit path).
- Remove unneeded code from _urtwn_getbuf().
- Use CCK11 for data frames in 11b mode.
- Send EAPOL frames at 1 Mbps.
- Reduce code duplication in urtwn_tx_data().
- Fix sequence numbering.
- Add IEEE80211_RADIOTAP_F_WEP flag for encrypted frames.
- Check URTWN_RUNNING flag under lock.
Tested with RTL8188EU, STA mode.
Reviewed by: kevlo
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D4017
- Filter out unneeded frames in STA mode.
- Implement ic_promisc() call.
Tested with RTL8188EU, STA and MONITOR modes.
Reviewed by: kevlo
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D3999
32-bits aligned. Merge the two bounce buffers into a single one. Some
rough tests showed that the DWC OTG throughput on RPI2 increased by
10% after this patch.
MFC after: 1 week
The mbuf length fields must be set before m_adj() is called else
m_adj() will not always adjust the mbuf and an unaligned read
exception can trigger inside the network stack. This can happen on
platforms where unaligned reads are not supported. Adjust a length
check to include the 2-byte ethernet alignment while at it.
MFC after: 3 days
- Drop TSF initialization; device can discover it without our help.
- Do not touch R92C_BCN_CTRL_EN_BCN bit in STA mode.
- Add 'static' keyword for function definition.
Tested with RTL8188EU, STA mode.
Reviewed by: kevlo
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D3801
Since r288350, ic_wme_task() is called via ieee80211_runtask(),
so, any additional deferring from the driver side is not needed.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D4072
status registers for every interrupt. Check a common host channel
status interrupt register first, then conditionally read the
individual host channel status registers.
Submitted by: Sebastian Huber <sebastian.huber@embedded-brains.de>
MFC after: 1 week
- Move all files related to the LinuxKPI into sys/compat/linuxkpi and
its subfolders.
- Update sys/conf/files and some Makefiles to use new file locations.
- Added description of COMPAT_LINUXKPI to sys/conf/NOTES which in turn
adds the LinuxKPI to all LINT builds.
- The LinuxKPI can be added to the kernel by setting the
COMPAT_LINUXKPI option. The OFED kernel option no longer builds the
LinuxKPI into the kernel. This was done to keep the build rules for
the LinuxKPI in sys/conf/files simple.
- Extend the LinuxKPI module to include support for USB by moving the
Linux USB compat from usb.ko to linuxkpi.ko.
- Bump the FreeBSD_version.
- A universe kernel build has been done.
Reviewed by: np @ (cxgb and cxgbe related changes only)
Sponsored by: Mellanox Technologies
registers (they are used for different purposes).
- Wrap R92C_MSR modifications into urtwn_set_mode().
Reviewed by: kevlo
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D3838
This doesn't free the mbuf upon error; the driver ic_raw_xmit method is still
doing that.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3774
* Create ieee80211_free_mbuf() which frees a list of mbufs.
* Use it in the fragment transmit path and ath / uath transmit paths.
* Call it in xmit_pkt() if the transmission fails; otherwise fragments
may be leaked.
This should be a big no-op.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3769
Now run(4) fetches parameters from ic->ic_wme.wme_params array, which is never initialized
(and can be safely removed). This patch replaces &ic->ic_wme.wme_params with
&ic->ic_wme.wme_chanParams.cap_wmeParams (contains parameters for local station;
used by other drivers with WME support).
Tested:
* me: STA: run0: MAC/BBP RT5390 (rev 0x0502), RF RT5370 (MIMO 1T1R), address 38:83:45:11:78:ae
Now device will use retry limit, which is set via 'ifconfig <interface>
maxretry <number>'.
Tested:
* Tested on WUSB54GC, STA mode.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3689
The MAC can be fetched from the key struct.
I added the ndis updates to make it compile.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3657
This diff includes:
* Transmitter Addresses, Keys and TKIP MIC addition to the Security Key Table.
* Proper SEC Control Registers initialization and maintenance.
* Additional flags and values in TX descriptor, which are required for encryption support.
* Error checking in RX path.
Tested:
* Tested on WUSB54GC, STA (WEP, TKIP, CCMP), HOSTAP (CCMP) and IBSS (CCMP, WPA-None) modes.
* rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528, STA mode (CCMP+TKIP)
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3640
Note: I manually had to merge this; I merged in the "put beacon_offsets
into vap" commit before this.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3628
Don't override the NIC MAC address with an overridden MAC address for
a VAP.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3625
Tested:
* rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528, STA mode
Note: haven't tested AP mode yet; will do once the rest of the
AP mode / power save commits are in.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3624
Move the mbuf free responsibility to the caller of the hardware xmit
function, not the hardware xmit function itself.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3621
* Remove unused sc_txtap_len/sc_rxtap_len fields.
* Remove unused ackrate variable.
* Remove unneded warning in rum_update_mcast().
* Use nitems().
* Replace some hardcoded values for RT2573_MAC_CSR1 register.
* Remove second argument for RUM_LOCK_ASSERT() - it is always the same.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3605
The fullmac firmware doesn't seem to populate a useful rssi indicator
in the RX descriptor, so if one plotted said values, they'd basically
look like garbage.
The reference driver implements a "get current rssi" firmware command
which I guess is really meant for station operation only (as hostap
operation would need rssi per station, not a single firmware read.)
So:
* populate sc_currssi during each calibration run;
* use this in the RX path instead of trying to reconstruct the RSSI
value and passing it around as a pointer;
* do up a quick hack to map the rssi hardware value to some useful
signal level;
* the survey results provide an RSSI value between 0..100, so just
do another quick hack to map it into some usefulish signal level;
* supply a faked noise floor - I haven't yet found how to pull it
out of the firmware.
The scan results and the station RSSI information is now more useful
for indicating signal strength / distance.
This logic is mostly crimed from the reference driver and the linux
r92su driver.
I verified that it (a) worked on the rsu hardware I have, and (b)
did traffic testing whilst watching what ath(4) sent as a hostap.
It successfully sent MCS8..15 rates (which requires 2-stream reception)
as well as MCS0..7 (which is 1-stream.)
Tested:
* RTL8712, 1T1R NIC, MCS rates 0..7.
* RTL8712, 1T2R NIC, MCS rates 0..15
TODO:
* Find a 2T2R NIC!
* include opt_wlan.h like a good little wlan driver;
* add a function to free the mbufq /and/ the node references on it, or we will leak
said node references;
* free the mbufq upon NIC shutdown otherwise we may end up with a full list that
we never begin transmit work on, and thus never drain it;
* .. which frees it upon NIC detach too;
* ensure urtwn_start() gets called after the completion of frame TX even if the
pending queue is empty, otherwise transmit will stall. It's highly unlikely that
the usb tx queue would be empty whilst the incoming send queue is full, but hey,
who knows.
This passes some iperf testing with and without the NIC being actively removed during
said active iperf test.
Tested:
* urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R ; STA mode
in the join message so the firmware would pick it up.
* Strip out the direct hardware fiddling for 40MHz mode - the firmware
we're using doesn't require it (the rtl8712su firmware does; it
is less 'fullmac' than what we're using.)
* Fix the mbuf handling during errors - rsu_tx shouldn't free mbufs;
it's up to the caller to do so. This brings it in line with
what other drivers do or should be doing.
Tested:
* RTL8712, HT40 channel, STA mode (during this commit)
Refer to the usb_quirk(4) manual page for more details on how to use
this new feature.
Submitted by: Maxime Soule <btik-fbsd@scoubidou.com>
PR: 203249
MFC after: 2 weeks
* Add a new method to control NIC poweron / network-sleep / power off;
* Add in A-MPDU TX negotiation support, but comment it out because it
does break TX traffic;
* blank out the tx buffer before sending a firmware message, just in case;
* go into network-sleep once associated;
TODO:
* figure out why ampdu negotiation isn't working and breaking TX traffic,
then enable it.
to do it directly.
Ensure that we re-queue starting transmit upon TX completion.
This solves two issues:
* It stops tx stalls - before this, if the transmit path filled the
mbuf queue then it'd never start another transmit.
* It enforces ordering - this is very required for 802.11n which
requires frames to be transmitted in the order they're queued.
Since everything remotely involved in USB has an unlock/thing/relock
pattern with that mutex, the only way to guarantee TX ordering is
to 100% defer it into a separate thread.
This now survives an iperf test and gets a reliable 30mbit/sec.
Correctly (I hope!) remove net80211 references before doing so.
Just doing a dumb mbufq drain isn't enough.
If enough traffic occurs and the mbuf queue fills up then transmit
stalls (which I'm not fixing in this commit!) but then the mbuf queue
stays full until the driver is removed. There's also the net80211
node refcounting leak.
This just ensures that during rsu_stop and detach the mbuf queue
is purged (and references!) so the queue-full situation can be
recovered from.
setup pieces and so (at least) transmit doesn't work.
It'll just fall back to being a straight HT20 device and negotiate
HT20 only.
Tested by: Idwer Vollering <vidwer@gmail.com>
requirements.
Don't start the opmode and join path until a pending survey is finished.
This seems to reliably fix things.
Ideally I'd just finish off the net80211 pluggable scan stuff and implement
the methods here so if_rsu can just drive the scan machinery.
However, that's a .. later thing.
Whilst here, remove the getbuf debugging; it's okay to run out of transmit
buffers under load; it however isn't okay to not be able to send commands.
I'll fix that later.
* Add a tunable to enable 11n if it's available, so to not anger people
who upgrade.
kenv hw.usb.rsu.enable_11n=1 before inserting the device.
* Add initial 11n htconfig bits;
* Enable 40MHz mode if it's available;
* Add 11n channels;
* Set 11n bits in the firmware.
It works for RX; I haven't tested TX aggregation just yet.
However the firmware doesn't do RX re-ordering, so I have to tie it into
the net80211 A-MPDU RX reorder path before I flip this on by default.
I've verified that I'm indeed actually seeing MCS 0->7 rates being received.
I haven't dug into whether it's actually transmitting 11n rates; I'll dig into
that later.
* the tx descriptor TID is priority, not TID.
* the tx descriptor queue id mapping is separate from the
TID/priority; rather than just "BE".
TODO:
* go and re-re-re-verify the queue mappings; the linux and openbsd
mappings aren't exactly the same. I need to verify all of this
before I try to flip on 11n RX.
* Do 1T1R for now, until we read the config out of ROM and use it.
* Disable turbo mode, I dunno what this is, but the linux drivers
have this disabled.
* Set the firmware endpoints to what we read from USB.
Tested:
* RTL8712 cut 3, STA mode
data queues.
This is similar to the openbsd and rtlwifi/r92su drivers.
Note: this driver still assumes it's a 4-endpoint device; I'll enforce
that in a follow-up commit.
There is an issue with interrupts at the moment, but it works with
polling mode set (hw.usb.xhci.use_polling=1).
Reviewed by: hselasky
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3665
This allows for arbitrary channel info to be placed in the input call rather
than the totally gross hack of overriding ic_curchan.
Without this I'm sure ic_curchan setting was racing with the scan code
setting the channel itself..
The firmware in this NIC sends management frames. So far I'm not sure which
ones it handles and which ones it doesn't handle - but this is what openbsd
does.
The association messages are handled by the firmware; the key negotiation
for 802.1x and WPA are done as raw frames, not management frames.
This successfully allows it to associate to my home networks whereas it didn't
work beforehand.
Tested:
* RTL8712, cut 3, STA mode
TODO:
* The firmware does send a join response with a status code; that should be
logged in a more obvious way to assist with debugging. Ie, the firmware
is the thing that is saying "couldn't join, sorry!", not net80211.
* yes, when a "sta disconnect" message comes through we should, like,
disconnect things. We're not currently generating beacon miss messages,
and net80211 isn't disconnecting things via software beacon miss receive.
Tested:
* RTL8712, cut 3, STA mode
* use an ath/iwn style debug bitmap - it's still global rather than per-device,
but it's better than debug levels
* disable bgscan - it just makes things unstable/unpredictable for now.
Tested:
* if_rsu - RTL8712 cut 3, STA mode
connectivity interact with the net80211 stack.
Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.
Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:
- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
driver about any changes: number of wlan(4) interfaces, number of them
in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
driver experiences errors and can not attribute them to any specific
interface, driver updates ic_oerrors or ic_ierrors counters.
Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
now provided by net.wlan.devices sysctl.
Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann,
Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in
testing.
Reviewed by: adrian
Sponsored by: Netflix
Sponsored by: Nginx, Inc.
intervals less than 250us was not handled properly. Add support for
high-bandwidth ISOCHRONOUS packets. USB webcams, USB audio and USB DVB
devices are expected to work better. High-bandwidth INTERRUPT
endpoints is not yet supported.
MFC after: 2 weeks
the kernel is tapping an USB transfer. This leads to a NULL pointer
access. The solution is to only trace while the USB bus lock is
locked.
MFC after: 2 weeks
like RPI-B and RPI-2.
Description of problem:
USB transfers can process data in their callbacks sometimes causing
unacceptable latency for other USB transfers. Separate BULK completion
callbacks from CONTROL, INTERRUPT and ISOCHRONOUS callbacks, and give
BULK completion callbacks lesser execution priority than the
others. This way USB audio won't be interfered by heavy USB ethernet
usage for example.
Further serve USB transfer completion in a round robin fashion,
instead of only serving the most CPU hungry. This has been done by
adding a third flag to USB transfer queue structure which keeps track
of looping callbacks. The "command" callback function then decides
what to do when looping.
MFC after: 2 weeks
* 286410
* 286413
* 286416
The initial commit broke a variety of debug and features that aren't
in the GENERIC kernels but are enabled in other platforms.
with the net80211 stack.
Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.
Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:
- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
driver about any changes: number of wlan(4) interfaces, number of them
in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
driver experiences errors and can not attribute them to any specific
interface, driver updates ic_oerrors or ic_ierrors counters.
Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
now provided by net.wlan.devices sysctl.
Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to Olivier Cochard, gjb@, mmoll@,
op@ and lev@, who also participated in testing. Details here:
https://wiki.freebsd.org/projects/ifnet/net80211
Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not
tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances
of problems are low. The wtap wasn't compilable even before this change.
But the ndis driver is complex, and it is likely to be broken with this
commit. Help with testing and debugging it is appreciated.
Differential Revision: D2655, D2740
Sponsored by: Nginx, Inc.
Sponsored by: Netflix
The ftdi chip itself has a "get bitmode" command that doesn't actually
return the current bitmode, just a snapshot of the gpio lines. The chip
apparently has no way to provide the current bitmode.
This implements the functionality at the driver level. The driver starts
out assuming the chip is in UART mode (which it will be, coming out of
reset) and keeps track of every successful set-bitmode operation so that
it can always return the current mode with UFTDIIOC_GET_BITMODE.
