| 565 | | |
| 566 | | * {{{hostapd-conf}}} was written for and takes advantage of the bash shell, make sure you aren't running it with another shell program (ie Ubuntu's default "dash" shell) |
| 567 | | * ensure both hostapd and wpa_supplicant are not both trying to manage the interface (ie you have it configured for both AP and Client mode) |
| 568 | | * ensure your client can see the AP (ie {{{iw dev wlan0}}} scan for a Linux client, or use a wireless scanner such as 'Wifi Analyzer' on an Android device) |
| 569 | | * For client mode ensure the kernel shows that you are associated with the AP. You should see {{{wlan0: associated}}} in the kernel messages |
| 570 | | * check your encryption settings |
| 571 | | * if you can ping between the AP and the client directly but not get through them: |
| 572 | | * check your routing configuration (ie via {{{route -n}}} on Linux) and make sure you have a proper gateway |
| 573 | | * if trying to bridge wireless to ethernet networks ensure 'both' the AP and the Client have 4addr header parsing enabled |
| 574 | | * if DNS resolution is not occurring first make sure you can ping the nameserver by IP |
| | 562 | * {{{hostapd-conf}}} was written for and takes advantage of the bash shell, make sure you aren't running it with another shell program (ie Ubuntu's default "dash" shell) |
| | 563 | * ensure both hostapd and wpa_supplicant are not both trying to manage the interface (ie you have it configured for both AP and Client mode) |
| | 564 | * ensure your client can see the AP (ie {{{iw dev wlan0}}} scan for a Linux client, or use a wireless scanner such as 'Wifi Analyzer' on an Android device) |
| | 565 | * For client mode ensure the kernel shows that you are associated with the AP. You should see {{{wlan0: associated}}} in the kernel messages |
| | 566 | * check your encryption settings |
| | 567 | * if you can ping between the AP and the client directly but not get through them: |
| | 568 | * check your routing configuration (ie via {{{route -n}}} on Linux) and make sure you have a proper gateway |
| | 569 | * if trying to bridge wireless to ethernet networks ensure 'both' the AP and the Client have 4addr header parsing enabled |
| | 570 | * if DNS resolution is not occurring first make sure you can ping the nameserver by IP |
| | 804 | |
| | 805 | [=#tcp_cong] |
| | 806 | === TCP Congestion Control === |
| | 807 | Starting in Linux 2.6.7 (and back-ported to 2.4.27), Linux includes alternative congestion control algorithms beside the traditional 'reno' algorithm. 2.6.13 added support for plug-able congestion control algorithms set using sysctl variable net.ipv4.tcp_congestion_control which is set to bic/cubic or reno by default depending on kernel versions. |
| | 808 | |
| | 809 | The Internet has predominantly used loss-based congestion control (largely Reno or CUBIC) since the 1980s, relying on packet loss as the signal to slow down. While this worked well for many years, loss-based congestion control is unfortunately out-dated in today's networks. On today's Internet, loss-based congestion control causes the infamous bufferbloat problem, often causing seconds of needless queuing delay, since it fills the bloated buffers in many last-mile links. On today's high-speed long-haul links using commodity switches with shallow buffers, loss-based congestion control has abysmal throughput because it over-reacts to losses caused by transient traffic bursts. |
| | 810 | |
| | 811 | TCP congestion control algorithms can be configured in the Kenrel under 'Networking support (NET) -> Networking options -> TCP/IP networking (INET) -> TCP: advanced congestion control (TCP_CONG_ADVANCED). The default is typically CONFIG_TCP_CONG_CUBIC which builds in CUBIC (default) and Reno. A more modern algorithm called BBR [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/net/ipv4/Kconfig?id=0f8782ea14974ce992618b55f0c041ef43ed0b78 was introduced more recently]. |
| | 812 | |
| | 813 | You can select between multiple TCP congestion control algorithms via userspace sysctl: |
| | 814 | {{{#!bash |
| | 815 | cat /proc/sys/net/ipv4/tcp_available_congestion_control # see available algos |
| | 816 | sysctl net.ipv4.tcp_congestion_control=reno # select Reno |
| | 817 | }}} |
| | 818 | |
| | 819 | References: |
| | 820 | - https://fasterdata.es.net/host-tuning/linux/expert/ |
| | 821 | - https://linuxgazette.net/135/pfeiffer.html |
| | 822 | - https://www.cs.helsinki.fi/research/iwtcp/papers/linuxtcp.pdf |
| | 823 | |
| | 824 | |
| | 825 | [=#tsq] |
| | 826 | === TCP Small Queues (TSQ) === |
| | 827 | TCP Small Queues (TSQ) performs local flow control, limiting the amount of data in the queues on the sending host. Like TSO autosizing, TSQ has its own balancing act, keeping the queues small to reduce latency and head-of-line blocking (HoLB), while keeping the queues just large enough to ensure the queues on the sending host. |
| | 828 | |
| | 829 | The kernel TSQ logic allows up to 1ms of bytes to be queued into qdisc and driver queues. However, Wifi aggregation (multiple streams) needs a bigger budget to allow bigger rates to be discovered by various TCP Congestion Control algos. |
| | 830 | |
| | 831 | A [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3a9b76fd0db9f0d426533f96a68a62a58753a51e patch] has made it into the 4.15 kernel that allows wifi drivers to adjust this value as needed but drivers need to be updated to add this functionality. |
| | 832 | |
| | 833 | Gateworks has a [https://github.com/Gateworks/linux-newport/commit/64f1fcb3f7a7715dc6fa1e8b30f02f01032fb2dd patch] in the Newport kernel that allows userspace to change the default 1ms buffering time manually with sysctl. Increasing the buffering to something between 1ms and 9ms shows significant throughput increases for MIMO cards. For example: |
| | 834 | {{{#!bash |
| | 835 | sysctl net.ipv4.tcp_tsq_limit_output_interval=5 # use 5ms of buffering in TSQ logic |
| | 836 | }}} |
| | 837 | |
| | 838 | References: |
| | 839 | - [https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670041 Ubuntu bug with discussion] |
| | 840 | - [https://github.com/Gateworks/linux-newport/commit/64f1fcb3f7a7715dc6fa1e8b30f02f01032fb2dd Patch allowing userspace configuration of TSQ buffer time via sysctl] |
| | 841 | - [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3a9b76fd0db9f0d426533f96a68a62a58753a51e patch Linux 4.15 patch to allow wifi drivers to adjust the TSQ buffer size] |
| | 842 | - [https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=111b49902465116a8353d29afe02eff0f56ea0a3 patch in LEDE adjusting TSQ logic] |
| | 843 | |
| | 844 | |
| | 845 | [=#mac80211] |
