У меня по-прежнему несколько раз в день срабатывают предупреждения conntrack full на прошивке 4.3.20.11298. Сегодня постараюсь сделать pcap.

@UI-jeff @UI-Glenn Я только что поймал свой тестовый телефон, iPhone Xr, который последние 6 часов спамит точку доступа для хотспота (в статусе pending guest). Я начал отслеживать небольшой набор точек доступа в Influx:  
 
Этот спад в конце синей линии — это когда я отключил телефон. У него было включено авто-подключение (Auto-Join), но не авто-вход (Auto-Login).  
Перехват пакетов показывает попытки соединения с api-sjc.smoot.apple.com.  
Имейте в виду, что /proc/sys/net/netfilter/nf_conntrack_max установлен всего на 7792, так что несложно представить, как одна-две настырные клиенты могут перегрузить или устроить DOS-атаку на точку доступа.  
В списке клиентов такие проблемные устройства легко определить по статусу: Pending и высокому уровню активности — я регулярно вижу постоянные 500 Кбит/с и больше, что много для SYN-запросов.

ssh admin@FlexHD-Deck-01 'tcpdump -c 5000 -i ra0' > .\Desktop\dump-202006181232.pcapng  
tcpdump: подробный вывод отключен, используйте -v или -vv для полного декодирования протокола  
прослушивание на ra0, тип канала EN10MB (Ethernet), размер захвата 262144 байта  
захвачено 5000 пакетов  
7290 пакетов прошло через фильтр  
1062 пакета отброшено ядром  
257 пакетов отброшено интерфейсом  

В очереди гость 10.7.5.189 с 2000 до 4000 соединений.

@UI-jeff, я не вижу, где можно прикрепить приватный файл, могу ли я отправить тебе файл захвата в личку? Это не вызвало событие полного заполнения таблицы nf_conntrack, но суть та же. Думаю, это просто приложения или ОС думают, что у них уже есть интернет-соединение, хотя на самом деле нет. В любом случае я тоже считаю, что решение — адекватный или настраиваемый лимит соединений для гостей. Полагаю, что уменьшение таймаутов в контроллере влияет только на соединения, проходящие через роутер, а не через точки доступа, но я пока не проверял уменьшение таймаутов как способ решения проблемы.

@Idea Я раньше такого не видел. Можно ли сделать захват пакетов на гостевом интерфейсе AP, чтобы понять, что именно делает это устройство?

Бьюсь об заклад, я знаю, кто был "главным нарушителем":  
DeckFlex-BZ.v4.3.13# ./check_conntrack.sh 10.7.6.197  
Jun 17 15:41:01 3325/3871  
Jun 17 15:41:06 3465/4019  
Jun 17 15:41:12 3460/4018  
Jun 17 15:41:17 3430/3893  
Jun 17 15:41:22 3266/3698  
Jun 17 15:41:28 3120/3512  
Jun 17 15:41:33 2929/3270  
Jun 17 15:41:39 2766/3003  
Jun 17 15:41:44 2639/2816  
Jun 17 15:41:49 2515/2710  
Jun 17 15:41:54 2361/2590  
Jun 17 15:42:00 2202/2433  
Jun 17 15:42:05 2059/2281  
Jun 17 15:42:10 1776/2011  
Jun 17 15:42:15 1489/1740  
Jun 17 15:42:21 1302/1486  
Jun 17 15:42:26 1102/1265  
Jun 17 15:42:31 1042/1193  
Jun 17 15:42:36 915/1065  
Jun 17 15:42:41 777/927  
Jun 17 15:42:46 622/788  
Jun 17 15:42:51 442/596  
Jun 17 15:42:56 295/443  
Jun 17 15:43:01 115/257  
Jun 17 15:43:07 0/123  
Jun 17 15:43:12 6/131  
Jun 17 15:43:17 8/138  
Jun 17 15:43:22 7/153  
Jun 17 15:43:27 10/183  

Обратите внимание, что между 15:42 и 15:43 Мария ввела код ваучера и перешла из статуса Unauthorized в Authorized. С тех пор поведение её устройства абсолютно нормальное:  
Jun 17 15:43:27 10/183  
Jun 17 15:43:32 22/237  
Jun 17 15:43:37 27/273  
Jun 17 15:43:42 26/279  
Jun 17 15:43:47 26/304  
Jun 17 15:43:52 26/304  
Jun 17 15:43:57 25/261  
Jun 17 15:44:02 13/201  
Jun 17 15:44:07 8/212  
Jun 17 15:44:12 6/208  
Jun 17 15:44:17 6/252  
Jun 17 15:44:22 6/320  
Jun 17 15:44:27 8/341  
Jun 17 15:44:32 11/309  
Jun 17 15:44:37 16/283  
Jun 17 15:44:43 18/378  
Jun 17 15:44:48 18/387  
Jun 17 15:44:53 18/372  
Jun 17 15:44:58 15/372  
Jun 17 15:45:03 13/375  
Jun 17 15:45:08 8/347  
Jun 17 15:45:13 3/234  
Jun 17 15:45:18 4/202  
Jun 17 15:45:23 4/226  
Jun 17 15:45:28 1/207  
Jun 17 15:45:33 2/189  
Jun 17 15:45:38 2/202  
Jun 17 15:45:43 2/200  
Jun 17 15:45:48 1/188  
Jun 17 15:45:53 1/215  
Jun 17 15:45:58 1/219  
Jun 17 15:46:03 0/221  
Jun 17 15:46:09 0/211  
Jun 17 15:46:14 0/237  
Jun 17 15:46:19 0/231  
Jun 17 15:46:24 0/179  
Jun 17 15:46:29 5/175  
Jun 17 15:46:34 5/169  
Jun 17 15:46:39 5/170  
Jun 17 15:46:44 5/153  
Jun 17 15:46:49 6/160  
Jun 17 15:46:54 6/143  
Jun 17 15:46:59 2/139  
Jun 17 15:47:04 2/134  
Jun 17 15:47:09 3/139  
Jun 17 15:47:14 3/136  
Jun 17 15:47:19 3/145  
Jun 17 15:47:24 3/160  
Jun 17 15:47:29 3/160  
Jun 17 15:47:34 3/160  
Jun 17 15:47:39 2/153  
Jun 17 15:47:44 5/157  
Jun 17 15:47:49 6/139  

Ещё раз, скрипт просто считает количество подключений, отфильтрованных grep, от общего числа подключений:  
DeckFlex-BZ.v4.3.13# cat check_conntrack.sh  
while true  
do  
 echo $(date | cut -d " " -f 2,3,4) $(cat /proc/net/nf_conntrack | grep $1 -c)"/"$(cat /proc/net/nf_conntrack | grep . -c)  
 sleep 5  
done

@UI-Glenn Да, именно так. Извиняюсь за повторение. Но дело не в каком-то одном конкретном клиенте, а в разных клиентах в разные дни. Речь о гостях точки доступа перед тем, как они авторизуются (Unauthorized/Pending). Я предполагаю, что эти устройства не вредоносные, а просто что-то в взаимодействии точки доступа и клиента приводит к открытию ими «ОГРОМНОГО» количества TCP-соединений. В итоге один простой неактивный гость, который даже не пользуется интернетом, может случайно вызвать отказ в обслуживании (DoS) на точке доступа, потому что когда она перестаёт отслеживать соединения, начинает сбрасывать новые подключения. Разве нормально, что в стандартном режиме работы невредоносные гости могут случайно устроить DoS на точку доступа? Я предлагаю, чтобы Ubiquiti изучила, что именно происходит, и исправила эту проблему. Если это действительно проблема со стороны клиента, то первое и самое простое решение — установить лимит подключений на одного клиента Hotspot (или хотя бы на один IP-адрес). В Mikrotik это элементарно: IP > Firewall > Filter > Connection Limit. Было бы логично, чтобы в Hotspot была настройка Max Connections per Client, возможно с адекватным значением по умолчанию, например 200.