Проверяя журнал, рекомендуется отключить управление питанием для Wi-Fi, как описано в драйвере wl / b43 здесь затем отредактируйте: /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf

wifi.powersave = 2

[РЕДАКТИРОВАТЬ] это означает, что в моем случае после дальнейшего тестирования изменение этого параметра ухудшило ситуацию, поскольку Wi-Fi отскакивает все больше и больше из-за повторного сканирования Wi-Fi ... Так что, если у вас есть проблема, не использовать это. (Однако у вас может не быть проблемы, если вы используете драйвер wl . В моем случае я использую b43 .)

У меня была такая же проблема. У меня есть беспроводная карта Broadcom 4313, которая обрывает соединение, когда в основном загружала большие файлы в течение длительного периода времени.

Пока это решило мою проблему:

https://help.ubuntu.com/community/WifiDocs/Driver/bcm43xx

Если вам нужно краткое руководство, я рекомендую исправить это, сначала удалив все драйверы используя имя команды sudo modprobe -r drivernamegoeshere, затем добавляя их обратно по одному, чтобы посмотреть, работает ли то, что работает.

Чтобы получить список водителей. lsmod | grep cfg80211, затем удалите каждый и добавьте один из них обратно (начиная с b43) с помощью sudo modprobe b43. Пока это у меня получается.

Я был в подобной ситуации в течение двух недель, и вчера (11 мая) я нашел решение, которое работает до сих пор (двойная загрузка Ubuntu 20.04 / Windows, беспроводная карта Broadcom 4325).

Удивительно, но моя проблема возникла не из-за беспроводного драйвера или управления питанием (в предыдущие дни пробовал много вещей, никаких улучшений), а связана с истечением срока действия записи ARP моего компьютера на моем локальном маршрутизаторе (ARP означает для Протокола разрешения адресов выполняется преобразование между IP-адресами и MAC-адресами).

Вкратце (подробности расследования в конце этого ответа):

• Записи ARP моего маршрутизатора имеют тайм-аут 20 минут,
• Для моего компьютера он уменьшался до истечения срока действия (что заставило меня терять соединение каждые 20 минут),
• И то же самое для других устройств, но для них оно автоматически обновлялось до истечения срока действия. Я сделал сетевые захваты, чтобы узнать, что эти устройства делают по-другому, и обнаружил, что их тайм-аут обновляется, когда они отправляют запрос ARP.

=> Появилось решение, мне пришлось сказать своему компьютеру сделать то же самое! (отправить ARP-запрос)

Реализация решения

Для отправки ARP-запроса я использовал arping, который можно установить из его пакета:

sudo apt install arping

При запуске пишет, что он должен работать как root или с возможностью cap_net_raw. Поскольку я не хотел запускать его как root, я добавил возможность:

sudo setcap "cap_net_raw+ep" /usr/sbin/arping

Я использовал следующую команду для отправки одного ARP-запроса на мой маршрутизатор (замените IP-адрес на тот, который подходит вам):

arping -c 1 192.168.1.1

Затем Я хотел, чтобы эта команда запускалась каждые 15 минут, чтобы регулярно обновлять запись ARP. Это делается путем редактирования файла /etc/crontab :

sudo vi /etc/crontab

и добавления этой строки в конец файла :

*/15 * * * * <username> arping -c 1 192.168.1.1

Это сделает запрос ARP отправленным каждые 15 минут.

Подробный процесс расследования

Вот более подробная информация о том, как я обнаружил проблему:

• Разработал виджет, сообщающий мне с отметками времени, когда соединение потеряно и когда оно восстановлено.
• Запуск захвата tcpdump до тех пор, пока не произойдет отключение/повторное подключение (назначение виджета).
• В перехвате обнаружены ARP-сообщения примерно во время выдачи.
• Просмотрел таблицу ARP моего маршрутизатора pfSense и увидел, что запись тайм-аута для моего ПК всегда уменьшается до истечения срока действия; для других подключенных устройств он также уменьшился, но в какой-то момент он сбрасывался до значения по умолчанию (1200 с в моем случае) до истечения срока действия.
• Подождал до истечения срока действия, чтобы подтвердить, что на моем компьютере наблюдается симптом отключения (да).
• На маршрутизаторе были сделаны снимки tcpdump, чтобы увидеть, как другие устройства успешно сбрасывали свой тайм-аут: отправляя запросы ARP до истечения срока его действия.
• Установил arping, как описано выше, и отправил тестовый ARP-запрос на маршрутизатор: он сбросил мой тайм-аут истечения до 1200 с, победа! \o/

Наконец, я не знаю, почему я никогда не сталкивался с этой проблемой при использовании Windows. При проверке таблицы ARP я вижу, что срок действия записи также истек, но затем сразу же сбрасывается до 20 минут, и я не вижу отключения сети.

Вы также можете задаться вопросом, как проверить таблицу ARP. Если вы используете маршрутизатор pfSense, его можно найти в подменю «Диагностика > Таблица ARP» (для перевода на английский язык, мои меню на французском языке). С другим устройством вам придется проверить его документацию.

Но, в конце концов, если вы не можете проверить таблицу ARP, вы все равно можете попытаться вставить строку в /etc/crontab и запустить ее на пару часов/дней. Если ваша проблема больше не появляется, значит проблема была в ней :-)

Надеюсь, это поможет!

У меня была такая же проблема. После небольшого поиска в Google я нашел несколько ответов после проверки dmesg. Итак, после запуска:

# dmesg -w

Я обнаружил это сообщение об ошибке:

wlan0: deauthenticated from c8:e7:xx:xx:xx:xx (Reason: 6=CLASS2_FRAME_FROM_NONAUTH_STA)

Я нашел значение ошибки в Linux WiFi: деаутентифицированные коды причины:

Попытка кадра класса 2, полученного от клиента STA, не прошедшего проверку подлинности для передачи данных до их аутентификации.

После выявления ошибки мне нужно понять, почему мой старый MacBook White срабатывал от точки доступа (подключение было в сети, но никаких входящих/исходящих пакетов).

Ну, ошибка показывает мне достаточно, чтобы понять проблему. Ошибка связана с ошибкой аутентификации с точкой доступа, после этого я понимаю, что моя точка доступа «пинает» мое соединение и отказывается от пакетов с интерфейса Wi-Fi.

Итак, попробуем кое-что.
Может быть, если я остановлю автоматическое изменение канала/частоты, проблема исчезнет...После изменения конфигурации моей точки доступа на статический канал (36) и частоту на (80 МГц) интерфейс Wi-Fi перестал падать, и проблема была решена (пока все хорошо), так что больше не было нестабильности с подключением Wi-Fi с использованием Broadcom (BCM4321). ).

Что я понял об ошибке?

Я предполагаю, что прошивка имеет некоторую проблему кода с аутентификацией после автоматического согласования канала и частоты, прошивка отправляет запрос на аутентификацию до того, как соединение действительно завершает «рукопожатие» с АП.

Я надеюсь, что этот «обходной путь» поможет вам решить проблему.