Enables support for Dynack feature. When a remote station is far away, we need to compensate for the distance by allowing more time for an ACK to arrive back before issueing a retransmission. Currently, it needs to be set fixed to indicate the maximum distance the remote station will ever be. While this mostly works for static antennae, it introduces 2 issues: - If the actual distance is less, speed is reduced due to a lot of wates wait-time - If the distance becomes greater, retries start to occur and comms can get lost. Allowing to set it dynamically using dynack ensures the best possible tradeoff between speed vs distance. This feature is currently only supported in ath9k. it is also disabled by default. Enabling it can be done in 2 ways: - issue cmd: iw phy0 set distance auto - sending the NL80211_ATTR_WIPHY_DYN_ACK flag to mac80211 driver using netlink Disabling it can be done by providing a valid fixed value. To give an idea of a practical example: In my usecase, we have mesh wifi device installed on ships/platforms. Currently, the coverage class is set at 12000m fixed. When a vessel moved closer (ex. 1500m), the measured link capacity was a lot lower compared to setting the coverage class fixed to 1500m Dynack completely solved this, nearly providing double the bandwidth at closer range compared to the fixed setting of 12000m being used. Also when a vessel sailed to a distance greater than the fixed setting, communication was lost as the ACK's never arrived within the max allowed timeframe. Actual distance: 6010m iperf 60s run avg Fixed 12150m: 31 Mbit/s Dynack: 58 Mbit/s Fixed 6300m: 51 Mbit/s Dynack: 59 Mbit/s Fixed 3000m: 13 Mbit/s (lots of retries) Dynack: 58 Mbit/s Actual distance: 1504m iperf 60s run avg Fixed 12150m: 31 Mbit/s Dynack: 86 Mbit/s Fixed 6300m: 55 Mbit/s Dynack: 87 Mbit/s Fixed 3000m: 67 Mbit/s Dynack: 87 Mbit/s Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
we only wanted to drop rtl8xxxue support Signed-off-by: John Crispin <john@phrozen.org>
After a very enlightening but unfortunately far too short exchange with Jes we mutually agreed to drop the patches. They are unfortunately not ready yet. Acked-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: John Crispin <john@phrozen.org>
Commit 61d57a2f88b90ba951012e66c7c6fae9234c97b4 adds ath10k LED support, but doesn't add an option to actually enable it. After enabling this option, a LED named ath10k-phy0 appears in sysfs, and a trigger can be assigned to it. Since 60deb3cdef4a the default set trigger is the tpt one. Enable it by default, as most devices using ath10k chips shouldn't be severely space-constrained. There are likely many devices that can benefit from having it enabled, like my testing device. Before: text data bss dec hex filename 245311 8899 16 254226 3e112 ath10k_core.ko After: text data bss dec hex filename 245979 8899 16 254894 3e3ae ath10k_core.ko Tested on a D-Link DAP-2695-A1 (ar71xx). Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Some ath10k firmware versions allow to access the chip internal a temperature sensor and allow to reduce the amount of the time when the card is allowed to send. The latter is required on devices which tend to overheat. An userspace service has to read /sys/class/ieee80211/phy*/device/hwmon/hwmon*/temp1_input regularly and then decide how much the device has to be throttled. This can be done by writing to /sys/class/ieee80211/phy*/device/cooling_device/cur_state. By default it is not throttled (0) but it can be throttled up to 100(%). Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
Import a revert-commit from Stanislaw Gruszka which significantly improves WiFi performance on rt2x00 based hardware. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: John Crispin <john@phrozen.org>
Refactor mesh initialization into a separate function, do some cleaning on the way to make the code more readable. Changes: * Move iw mesh setup to new mac80211_setup_mesh() * fallback on 'ssid' parameter in case 'mesh_id' isn't set * move setting of freq variable to shared code as it is needed for both, the wpa_supplicant and the iw based setup. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The commit 574e4377fad5 ("mac80211: properly setup mesh interface") uses
the variable $wpa to decide whether encrypted meshpoint is requested by the
user or not. But the variable $wpa will only be set correctly after the
function wireless_vif_parse_encryption is called.
Fixes: 574e4377fad5 ("mac80211: properly setup mesh interface")
Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
Setup wpa_supplicant for encrypted mesh or when using DFS channels and adjust interface setup to pass fixed frequency for mesh mode. Signed-off-by: Daniel Golle <daniel@makrotopia.org>