FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F11.3.0 2019-04-08T17:55:04Z 2019-04-08T17:55:04Z Kyle Evans kevans@FreeBSD.org 2019-04-08T17:55:04Z urn:sha1:b258f2e109133e06a4fadd179b7a612ae2da403d 2019-03-28T09:50:25Z Andriy Voskoboinyk avos@FreeBSD.org 2019-03-28T09:50:25Z urn:sha1:878318d26bdecded9654efbf90104bbab93ebd63 Fix ieee80211_radiotap(9) usage in wireless drivers: - Alignment issues: * Add missing __packed attributes + padding across all drivers; in most places there was an assumption that padding will be always minimally suitable; in few places - e.g., in urtw(4) / rtwn(4) - padding was just missing. * Add __aligned(8) attribute for all Rx radiotap headers since they can contain 64-bit TSF timestamp; it cannot appear in Tx radiotap headers, so just drop the attribute here. Refresh ieee80211_radiotap(9) man page accordingly. - Since net80211 automatically updates channel frequency / flags in ieee80211_radiotap_chan_change() drop duplicate setup for these fields in drivers. 2018-03-11T22:49:46Z Eitan Adler eadler@FreeBSD.org 2018-03-11T22:49:46Z urn:sha1:ddff8bf06c6d2f78baf2cb3ac05bc8e3449f379c Some users are reporting that it is causing issues for their hardware. In the interest of not breaking stable, revert while we investigate. 2018-03-07T10:54:10Z Eitan Adler eadler@FreeBSD.org 2018-03-07T10:54:10Z urn:sha1:909fc04f4888e37d7e0faf2993b24e1709e87ea1 These commits have KPI/KBI considerations (or are a result of those that do). I did not properly take into account these concerns when merging to a kbi-stable branch. Requested by: jhb Pointyhat to: eadler 2018-03-05T08:05:30Z Eitan Adler eadler@FreeBSD.org 2018-03-05T08:05:30Z urn:sha1:3e4dbff26bfc9a4d2bb7f73aa900c0915c9de7d8 [iwm] include opt_iwm.h and opt_wlan.h consistently in all files. 2018-03-05T08:01:08Z Eitan Adler eadler@FreeBSD.org 2018-03-05T08:01:08Z urn:sha1:c1799ea2c7b2b38aeb6a11de2814d1410ebaeb39 [iwm] free node reference if rxparams addition fails. 2018-03-05T08:00:17Z Eitan Adler eadler@FreeBSD.org 2018-03-05T08:00:17Z urn:sha1:8f7d04c0548e41a60d72938782783b32b166ba9c [iwm] Set full-offload scan flag. Fixes fw panic when already associated. * Starting a scan from wpa_supplicant or via ifconfig while associated, should no longer cause firmware panics or abort early. Tested: * AC7260, STA mode 2018-03-05T07:58:48Z Eitan Adler eadler@FreeBSD.org 2018-03-05T07:58:48Z urn:sha1:90d88e3c631164fd404f1f6f3427ec3474e9c394 net80211: convert all ieee80211_input_mimo*() consumers to ieee80211_add_rx_params() + drop last (ieee80211_rx_stats) parameter Note: there is an additional check for ieee80211_get_rx_params() return value (which does not exist in the original diff). 2018-03-05T07:54:57Z Eitan Adler eadler@FreeBSD.org 2018-03-05T07:54:57Z urn:sha1:6eb8d9ef1bf27243090ae4d5748e2be756e4873d [net80211] extend the ieee80211_rx_stats struct to include more information. There are a variety of more interesting RX statistics that we should keep track of but we don't. This is a starting point for adding more information. Specifically: * now the RX rate information and some of the packet status is passed up; * The 32 bit or 64 bit TSF is passed up; * the PHY mode is passed up; * the "I'm decap'ed AMSDU!" state is passed up; * number of RX chains is bumped to 4. This is all mostly a placeholder for getting the data into the RX status before we pass it up to net80211 - unfortunately we don't yet enforce that drivers provide it, nor do we pass the provided info back up the stack so anyone can use the data. We're going to need to use some of this data moving forward. Notably, now that some hardware can do AMSDU decap for us (the intel iwm driver can do it when we flip it on; the ath10k port I'm doing does it for us) then we need to pass it up through the stack so the duplicate RX sequence numbers and crypto/IV details don't cause the packet to be dropped and/or counted against a replay counter. It's also the beginning of being able to do more interesting node accounting in net80211. Specifically, once drivers start populating per-packet rate information, AMPDU information, timestamps, etc, we can start providing histograms of rate-versus-RSSI, account for receive time spent per node and other such interesting things. (Note: I'm also hoping to include ranging and RTT information for future chipset support; and it's likely going to include it in this kind of fashion.) 2018-03-05T07:08:58Z Eitan Adler eadler@FreeBSD.org 2018-03-05T07:08:58Z urn:sha1:78e7254260a7b4cc50fdab04caee237c40858c53 [iwm] GC unused code from if_iwm_scan.c, copyied from iwn or iwlwifi/dvm. Obtained from: dragonflybsd.git 10881df269b93c26e5ee6af629c36db5672e6e52