Bad TCP performance with Wireless over long distance

Hi. For some months now I have been having serious performance problems. The most important thing is that the problem is only with the TCP connection, the UDP traffic works perfectly well.

My connection to the Internet is via Wifi. Formerly the closest AP of my ISP was only 100 meters away, but a few months ago I connect to another AP that is approximately 500 meters away, approximately 1000 meters if we take into account the round trip distance.

First I thought it was the adapter type that used a TP-Link TL-WN722N V1, so I bought a PCIe TP-Link card with AR9287 Rev. 2 chipset with two Yagi antennas, but the TCP performance is still really bad and erratic, constantly showing errors such as "TCP Connection Reset" and other times not even that.

I have tried to disable ANI, enable TPC, PAPRD, use QCA Fast Path, Flow Offload, try several configurations in the firewall, but nothing, the result is always the same.

So, now I have to connect to the Internet via VPN but the connection speed is much slower.

Please I need help.

Thanks in advance, David.

Are you comfortable with using wireshark or would be willing to try it out? As a packet sniffer, it can be a lot more insightful than just tcpdump to see, for example, if your ACK packets are delayed. if you've got a spare wireless adapter, that would be the second step, taking the interface and hardware you're using for connectivity out of the sniffer's path and just looking at what's going over the air.

VPN connections are always slower.

SSH in to the router and run the following...

cat /etc/config/network

cat /etc/config/wireless

Note: Make sure to obscure the "option key" value(s) in the wireless config results before posting.

cat /etc/config/sqm

cat /etc/config/firewall

cat /etc/config/network

config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'

config interface 'lan'
option proto 'static'
option ipaddr '192.168.0.1'
option netmask '255.255.255.0'
option _orig_ifname 'eth0'
option mtu '1500'
option ipv6 '0'
option delegate '0'
option dns '127.0.0.1'
option type 'bridge'
option ifname 'eth0 tun2'

config interface 'wwan'
option proto 'dhcp'
option delegate '0'
option ipv6 '0'
option peerdns '0'
option dns '127.0.0.1'
option mtu '1500'
option force_link '1'
option ifname 'wlan0'

config interface 'vpn0'
option _orig_ifname 'tun2'
option _orig_bridge 'false'
option proto 'none'
option ifname 'tun2'
option delegate '0'
option force_link '1'

cat /etc/config/wireless

config wifi-device 'radio0'
option type 'mac80211'
option channel '1'
option path 'pci0000:00/0000:00:06.0/0000:02:00.0'
option hwmode '11g'
option htmode 'HT20'
option country 'US'
option country_ie '0'
option doth '0'
option noscan '1'
option short_preamble '1'
option ldpc '1'
option short_gi_20 '1'
option short_gi_40 '1'
option tx_stbc '1'
option rx_stbc '1'
option max_amsdu '1'
option dsss_cck_40 '1'
list ht_capab 'LDPC'
list ht_capab 'SHORT-GI-20'
list ht_capab 'SHORT-GI-40'
list ht_capab 'TX-STBC'
list ht_capab 'RX-STBC1'
list ht_capab 'MAX-AMSDU-7935'
list ht_capab 'DSSS_CCK-40'
option legacy_rates '0'

config wifi-iface 'default_radio0'
option device 'radio0'
option ssid 'MyISPAP'
option bssid 'xx:xx:xx:xx:xx:xx'
option encryption 'none'
option country_ie '0'
option doth '0'
option noscan '1'
option short_preamble '1'
option disassoc_low_ack '0'
option powersave '0'
option uapsd '0'
option ieee80211v '1'
option wmm '1'
option mode 'sta'
option network 'wwan'

cat /etc/config/sqm

config queue
option debug_logging '0'
option qdisc_advanced '1'
option squash_ingress '1'
option squash_dscp '1'
option verbosity '5'
option egress_ecn 'ECN'
option ingress_ecn 'ECN'
option qdisc 'cake'
option script 'layer_cake.qos'
option qdisc_really_really_advanced '1'
option iqdisc_opts 'bandwidth 3Mbit nat diffserv4 rtt 100ms ingress mpu 64'
option eqdisc_opts 'bandwidth 3Mbit nat diffserv4 rtt 100ms mpu 64'
option enabled '1'
option interface 'wlan0'
option linklayer 'none'
option download '3048'
option upload '3048'

/etc/config/firewall

config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '67-68'
option target 'ACCEPT'
option family 'ipv4'

config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'

config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'

config rule
option target 'ACCEPT'
option name 'ICMP VPN'
option proto 'icmp'
option src 'vpn'

config rule
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'

config rule
option src 'wan'
option dest 'lan'
option proto 'ah'
option target 'ACCEPT'

config rule
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'

config defaults
option tcp_ecn '1'
option tcp_window_scaling '1'
option tcp_syncookies '0'
option disable_ipv6 '1'
option output 'ACCEPT'
option input 'ACCEPT'
option forward 'REJECT'

config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option family 'ipv4'
option forward 'ACCEPT'
option network 'lan'

config zone
option name 'wan'
option family 'ipv4'
option output 'ACCEPT'
option network 'wwan'
option input 'REJECT'
option forward 'REJECT'
option masq '1'

config include
option path '/etc/firewall.user'
option family 'ipv4'

config forwarding
option dest 'wan'
option src 'lan'
option family 'ipv4'

config zone 'vpn'
option name 'vpn'
option network 'vpn0'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'

config forwarding 'vpn_forwarding_lan_in'
option src 'vpn'
option dest 'lan'
option family 'ipv4'

config forwarding 'vpn_forwarding_lan_out'
option src 'lan'
option dest 'vpn'
option family 'ipv4'

config forwarding 'vpn_forwarding_wan'
option src 'vpn'
option dest 'wan'
option family 'ipv4'

config forwarding
option dest 'lan'
option src 'wan'

config forwarding
option dest 'vpn'
option src 'wan'

This is a traffic capture for about 5 - 8 minutes. Without VPN.

https://drive.google.com/open?id=1720FkiDushQ1MmNoiuM9FH0scjy0Szib

Any possibility that you assigned the same static IP to two different devices on the same network?

What is the timeout for TCP connections?

What is your ISP rated download/upload speed?

I see you have 3048 set for both in SQM, which seems pretty low.

I currently have distance optimization set to 1350 on my 2.4 Ghz connection, as well as Fragmentation Threshold and RTS/CTS Threshold set to 2346, and encryption set to WPA2-PSK/AES.

I've had no issues with that wireless config.

The speed offered by my ISP is 5Mbits of download and 3Mbits for the upload speed, if it is quite low, but even before it was much lower speed and worked very well Internet connection. In my internal network I have 8 devices and before we could surf all without problems, we even saw online series, we made video calls, everything worked correctly for the speed offered by my ISP.

You mean the netfilter timeout, do not ?, I left them as they come in OpenWrt, but I have also played with these values ​​and everything remains the same. I do not understand what may be happening. Maybe a broken firewall in my ISP? A badly configured router? I doubt it, because a lot of people connect to where I connect and do not have this problem.

Likewise, establishing distance does not produce any improvement.

I have reached the point of enabling Dynamic Ack Timeout, but it does not produce any improvement either. And eye, because the problem is not in the NAT, since even from the PC itself that I use as a router I have the same problem. I have also tried to leave the Slottime in 9 but nothing, the same. I have tried with Minstrel Blues and the same thing happens, I have tried changing channels and the same. I really do not know what else I can try, and I come with these problems since September 2017, and now I have dared to share them because I have not found a way to solve them within my limited knowledge.

Thank you.

With a 500-m link, you're over 1.5 ms one-way. Between that and (1.5µs, less than the 300-2000 µs typical frame time) With directional antennas, any of the "listen first" algorithms for collision avoidance aren't going to be helpful. Your radio needs to "shoot blind". Shorter packets may help -- better to have 1/2 the data get through and the other half tromped on at the receiver, than lose the entire packet. At a frag threshold of 2346, it will never fragment 802.11. Given that the interface probably has an MTU of 1500, you might try something in the 800-1000 range and see if that helps.

I'll try again later to see if I can download that cap file. I wasn't terribly successful the first time.

Here is a sample of "iw dev wlan0 station dump":

Station xx: xx: xx: xx: xx: xx (on wlan0)
inactive time: 0 ms
rx bytes: 37137078
rx packets: 66581
tx bytes: 10724820
tx packets: 51928
tx retries: 60321
tx failed: 869
beacon loss: 9
beacon rx: 7503
rx drop misc: 6778
signal: -76 [-79, -79] dBm
signal avg: -76 [-79, -79] dBm
beacon signal avg: 180 dBm
tx bitrate: 6.5 MBit / s MCS 0
rx bitrate: 5.5 MBit / s
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM / WME: yes
MFP: no
TDLS peer: no
DTIM period: 1
beacon interval: 100
short preamble: yes
short slot time: yes
connected time: 1428 seconds

Or, use RTS/CTS set the RTS/CTS threshold to various things: 100, 400, 800 for example, see if those help at all. Just a thought.

cat /sys/kernel/debug/ieee80211/phy0/netdev:wlan0/stations/10:7b:ef:78:df:ec/rc_stats

           best   ____________rate__________    ________statistics________    _____last____    ______sum-of________

mode guard # rate [name idx airtime max_tp] [avg(tp) avg(prob) sd(prob)] [retry|suc|att] [#success | #attempts]
CCK LP 1 1.0M 120 10548 0.0 0.0 43.9 37.5 0 0 0 304 2271
CCK LP 1 2.0M 121 5476 0.0 0.0 18.7 39.0 0 0 0 1 3
CCK LP 1 5.5M 122 2411 2.4 0.0 57.2 34.2 2 0 0 659 1289
CCK LP 1 11.0M 123 1535 4.8 0.0 19.8 35.9 3 0 0 715 1976
CCK SP 1 2.0M 125 5380 0.0 0.0 0.0 0.0 0 0 0 0 1
CCK SP 1 5.5M 126 2315 2.4 0.0 55.2 25.3 2 0 0 770 1564
CCK SP 1 11.0M 127 1439 4.8 0.0 28.4 32.9 3 0 0 417 1301
HT20 LGI 1 ABCDP MCS0 0 1477 4.8 0.0 29.8 4.6 3 1 4 49500 186028
HT20 LGI 1 MCS1 1 738 9.7 0.0 5.6 21.8 2 0 0 292 1457
HT20 LGI 1 MCS2 2 492 14.6 0.0 4.8 19.0 2 0 0 313 2165
HT20 LGI 1 MCS3 3 369 17.0 0.0 0.3 4.4 2 0 0 5 224
HT20 LGI 1 MCS4 4 246 24.4 0.0 0.0 0.0 0 0 0 0 58
HT20 LGI 1 MCS5 5 185 29.2 0.0 0.0 0.0 0 0 0 0 59
HT20 LGI 1 MCS6 6 164 31.7 0.0 0.0 0.0 0 0 0 0 62
HT20 LGI 1 MCS7 7 148 34.1 0.0 0.0 0.0 0 0 0 0 63
HT20 LGI 2 MCS8 10 738 9.7 0.0 15.3 18.5 2 0 0 57 712
HT20 LGI 2 MCS9 11 369 17.0 0.0 0.0 0.0 0 0 0 0 59
HT20 LGI 2 MCS10 12 246 24.4 0.0 0.0 0.0 0 0 0 0 62
HT20 LGI 2 MCS11 13 185 29.2 0.0 0.0 0.0 0 0 0 0 62
HT20 LGI 2 MCS12 14 123 36.6 0.0 0.0 0.0 0 0 0 0 60
HT20 LGI 2 MCS13 15 92 43.9 0.0 0.0 0.0 0 0 0 0 59
HT20 LGI 2 MCS14 16 82 46.3 0.0 0.0 0.0 0 0 0 0 61
HT20 LGI 2 MCS15 17 74 48.8 0.0 0.0 0.0 0 0 0 0 60
HT20 SGI 1 MCS0 30 1329 4.8 0.0 22.3 39.4 3 0 0 842 3568
HT20 SGI 1 MCS1 31 665 9.7 0.0 9.1 22.3 2 0 0 892 3869
HT20 SGI 1 MCS2 32 443 14.6 0.0 0.1 0.0 5 0 0 130 776
HT20 SGI 1 MCS3 33 332 19.5 0.0 1.4 11.4 4 0 0 2 196
HT20 SGI 1 MCS4 34 222 26.8 0.0 0.0 0.0 0 0 0 0 60
HT20 SGI 1 MCS5 35 166 31.7 0.0 0.0 0.0 0 0 0 0 58
HT20 SGI 1 MCS6 36 148 34.1 0.0 0.0 0.0 0 0 0 0 56
HT20 SGI 1 MCS7 37 133 36.6 0.0 0.0 0.0 0 0 0 0 63
HT20 SGI 2 MCS8 40 665 9.7 0.0 7.4 24.4 4 0 0 18 397
HT20 SGI 2 MCS9 41 332 19.5 0.0 0.0 0.0 0 0 0 0 58
HT20 SGI 2 MCS10 42 222 26.8 0.0 0.0 0.0 0 0 0 0 63
HT20 SGI 2 MCS11 43 166 31.7 0.0 0.0 0.0 0 0 0 0 61
HT20 SGI 2 MCS12 44 111 39.0 0.0 0.0 0.0 0 0 0 0 57
HT20 SGI 2 MCS13 45 83 46.3 0.0 0.0 0.0 0 0 0 0 58
HT20 SGI 2 MCS14 46 74 48.8 0.0 0.0 0.0 0 0 0 0 61
HT20 SGI 2 MCS15 47 67 51.2 0.0 0.0 0.0 0 0 0 0 62

Total packet count:: ideal 57395 lookaround 1974
Average # of aggregated frames per A-MPDU: 1.0

whoops:

c * 1.5ms = 449 KILOMETERS not 449 meters

EDIT: But, that doesn't negate the main issue which is that your radio using a directional antenna to hit an AP 500 meters or more away is unlikely to hear any of the other clients, and so RTS/CTS was designed specifically for this scenario where you can't listen for the other clients and should be enabled with a very low threshold, like maybe the 100 bytes I mention.

That, to me, strongly suggests over-the-air issues.

(And yes, that should have been µs, not ms. I blame the beer at dinner for the derp.)

1 Like

Right now I am testing with the RTS / CTS threshold, I will test for a few minutes.

1 Like

Sounds good -- don't trust anything else I say tonight, another :beer: is tempting.

Great I am 90% sure that a low RTS/CTS threshold will at least help if not fix this. If you can reset your statistics some way then you can look at those tx and tx retry after your changes to RTS/CTS and get some idea how well that helped reduce the retry.

@jeff don't be hard on yourself, I outsource all those calculations to gnu units whether I've had beer or not :wink:

Here is a sample with the CTS / RTS threshold in 100 bytes.

Station xx: xx: xx: xx: xx: xx (on wlan0)
inactive time: 140 ms
rx bytes: 338269
rx packets: 997
tx bytes: 114711
tx packets: 606
tx retries: 746
tx failed: 7
beacon loss: 18
beacon rx: 149
rx drop misc: 101
signal: -75 [-78, -79] dBm
signal avg: -76 [-79, -80] dBm
beacon signal avg: 180 dBm
tx bitrate: 6.5 MBit / s MCS 0
rx bitrate: 6.5 MBit / s MCS 0
expected throughput: 2.197Mbps
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM / WME: yes
MFP: no
TDLS peer: no
DTIM period: 1
beacon interval: 100
short preamble: yes
short slot time: yes
connected time: 28 seconds

I think that retransmissions are still happening too often. Maybe disable ANI would help?

That's still really high. This suggests interference that isn't from other users of the same channel. Either noise like from a cordless phone or microwave or the like, or adjacent channel noise due to a close AP on an overlapping channel.

What does a wifi scan show for AP channel usage and signal strength in your area?