LINUX.ORG.RU
решено Форум — Admin  

Как задетектить отвал Wi-Fi адаптера?

 , , , ,


0

2
  • Ubuntu 20.04
  • TP-Link TL-WN722N v.1

Раздаю инет через усб wi-fi адаптер(указан выше), используя hostapd, и примерно раз в сутки-двое, в зависимости от интенсивности использования он отваливается.

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

Проблема решается вручную использованием команды usbreset, но мне бы хотелось как-то автоматизировать этот процесс. И поэтому такой вопрос: Как задетектить отвал Wi-Fi адаптера, чтобы затем запустить скрипт перезагрузки?

Сам hostapd молчит(а нажатие ctrl+c вешает его до того момента, пока не перезагрузишь адаптер), dmesg тоже молчит



Последнее исправление: LinuxAttendant (всего исправлений: 1)

Ответ на: комментарий от LinuxAttendant

Можно тупо ресетить по расписанию. Предположительно в моменты минимальной активности клиентов. Но не факт, что угадаешь.

next-anonymous
()
Последнее исправление: next-anonymous (всего исправлений: 1)

Что вы придумываете все? Что может быть проще скрипта в кроне, который любым доступным спобом определяет что сети отвалилась и «решается ... использованием команды usbreset»?! Проблема яйца выеденого не стоит 🤦‍♂️

erfea ★★★★★
()
Ответ на: комментарий от erfea

На всякий случай еще раз. Отваливающийся Wi-Fi адаптер это хост, он раздает Wi-Fi клиентам. Я же хочу на компьютере, к которому подключен этот Wi-Fi адаптер(который раздает интернет, полученный через другой интерфейс) задетектить отвал.

LinuxAttendant
() автор топика
Ответ на: комментарий от LinuxAttendant

Можно из /sys/class/net/wlan0/statistics. И посмотреть какие параметры там меняются или наоборот не меняются, когда он в рабочем состоянии или когда завис. Например, число tx packets или tx errors. В hostapd тоже довольно подробное логирование есть, которое выключено по умолчанию.

Но это опять-таки смотря что реализовали в драйвере и что означает «завис». Т.е. он перестает wifi сеть вещать в этот момент и клиенты её больше не видят?

zent ★
()
Ответ на: комментарий от LinuxAttendant

Я перечислил на вскидку 3 варианта. Ясновидящие в отпуске, как конкретно выражается «отвал Wi-Fi адаптера» мне откуда знать? Может в выдоде lsusb он пропадает, может ifconfig отобразит что сеть лежит, в крайнем случае в неработающей сети ну вот нихренашеньки не отпингуется.

erfea ★★★★★
()

Апдейт.

Проверял все параметры (читаемые cat) из /sys/class/net/wlan0/* и они постоянны как до так и после отвала. За исключением txpackets и подобных - их значения перестают расти после отвала (логично).

А hostadp -dd, реагирует только спустя довольно продолжительное время после отвала и выводит это

wlan0: ap_handle_timer: 00:11:22:33:44:55 flags=0x8023 timeout_next=0
wlan0: Station 00:11:22:33:44:55 has been inactive too long: 315 sec, max allowed: 300
  Polling STA
nl80211: Client probe request addr=00:11:22:33:44:55 cookie=1328
ap_handle_timer: register ap_handle_timer timeout for 00:11:22:33:44:55 (3 seconds - AP_DISASSOC_DELAY)
wlan0: ap_handle_timer: 00:11:22:33:44:55 flags=0x8063 timeout_next=1
wlan0: Station 00:11:22:33:44:55 has been inactive too long: 318 sec, max allowed: 300
wlan0: Timeout, sending disassociation info to STA 00:11:22:33:44:55
nl80211: send_mlme - da= 00:11:22:33:44:55 noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0xa0 (WLAN_FC_STYPE_DISASSOC) nlmode=3
nl80211: send_mlme -> send_frame
nl80211: send_frame - Use bss->freq=2462
nl80211: send_frame -> send_frame_cmd
nl80211: CMD_FRAME freq=2462 wait=0 no_cck=0 no_ack=0 offchanok=0
CMD_FRAME - hexdump(len=26): a0 00 00 00 ba 04 e4 f2 bb f1 84 16 f9 13 1e e2 84 16 f9 13 1e e2 00 00 04 00
nl80211: Frame TX command accepted; cookie 0x531
nl80211: Drop oldest pending send action cookie 0x0
wlan0: AP-STA-DISCONNECTED 00:11:22:33:44:55
wlan0: STA 00:11:22:33:44:55 IEEE 802.11: disassociated due to inactivity
ap_handle_timer: register ap_handle_timer timeout for 00:11:22:33:44:55 (1 seconds - AP_DEAUTH_DELAY)
wlan0: STA 00:11:22:33:44:55 MLME: MLME-DISASSOCIATE.indication(00:11:22:33:44:55, 4)
wlan0: STA 00:11:22:33:44:55 MLME: MLME-DELETEKEYS.request(00:11:22:33:44:55)
wpa_driver_nl80211_set_key: ifindex=9 (wlan0) alg=0 addr=0x55ee844c7090 key_idx=0 set_tx=1 seq_len=0 key_len=0
   addr=00:11:22:33:44:55
wlan0: ap_handle_timer: 00:11:22:33:44:55 flags=0x8041 timeout_next=2
wlan0: Timeout, sending deauthentication info to STA 00:11:22:33:44:55
nl80211: send_mlme - da= 00:11:22:33:44:55 noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0xc0 (WLAN_FC_STYPE_DEAUTH) nlmode=3
nl80211: send_mlme -> send_frame
nl80211: send_frame - Use bss->freq=2462
nl80211: send_frame -> send_frame_cmd
nl80211: CMD_FRAME freq=2462 wait=0 no_cck=0 no_ack=0 offchanok=0
CMD_FRAME - hexdump(len=26): c0 00 00 00 ba 04 e4 f2 bb f1 84 16 f9 13 1e e2 84 16 f9 13 1e e2 00 00 02 00
nl80211: Frame TX command accepted; cookie 0x532
nl80211: Drop oldest pending send action cookie 0x0
wlan0: STA 00:11:22:33:44:55 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
wlan0: STA 00:11:22:33:44:55 MLME: MLME-DEAUTHENTICATE.indication(00:11:22:33:44:55, 2)
wlan0: STA 00:11:22:33:44:55 MLME: MLME-DELETEKEYS.request(00:11:22:33:44:55)
wpa_driver_nl80211_set_key: ifindex=9 (wlan0) alg=0 addr=0x55ee844c7090 key_idx=0 set_tx=1 seq_len=0 key_len=0
   addr=00:11:22:33:44:55
nl80211: sta_remove -> DEL_STATION wlan0 00:11:22:33:44:55 --> 0 (Success)
nl80211: Set beacon (beacon_set=1)
nl80211: Beacon head - hexdump(len=57): 80 00 00 00 ff ff ff ff ff ff 84 16 f9 13 1e e2 84 16 f9 13 1e e2 00 00 00 00 00 00 00 00 00 00 64 00 11 04 00 06 52 54 4b 20 39 39 01 08 82 84 8b 96 0c 12 18 24 03 01 0b
nl80211: Beacon tail - hexdump(len=45): 2a 01 04 32 04 30 48 60 6c 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 3b 02 51 00 7f 08 04 00 00 02 00 00 00 40
nl80211: ifindex=9
nl80211: beacon_int=100
nl80211: beacon_rate=0
nl80211: rate_type=0
nl80211: dtim_period=2
nl80211: ssid=SSID
  * beacon_int=100
  * dtim_period=2
nl80211: hidden SSID not in use
nl80211: privacy=1
nl80211: auth_algs=0x1
nl80211: wpa_version=0x2
nl80211: key_mgmt_suites=0x2
nl80211: pairwise_ciphers=0x10
nl80211: group_cipher=0x10
nl80211: beacon_ies - hexdump(len=10): 7f 08 04 00 00 02 00 00 00 40
nl80211: proberesp_ies - hexdump(len=10): 7f 08 04 00 00 02 00 00 00 40
nl80211: assocresp_ies - hexdump(len=10): 7f 08 04 00 00 02 00 00 00 40
nl80211: multicast to unicast disabled on interface wlan0
ap_free_sta: cancel ap_handle_timer for 00:11:22:33:44:55
nl80211: Event message available
nl80211: Drv Event 20 (NL80211_CMD_DEL_STATION) received for wlan0
nl80211: Delete station 00:11:22:33:44:55

Буду, скорее всего, по крону проверять разницу пакетов и, если есть клиенты, делать ресет.

LinuxAttendant
() автор топика
Ответ на: комментарий от smilessss

выкинуть его

Пожалуй соглашусь в вами. Не считая что это TP (какой смысл с этим УГ прыгать, не понимаю), так это TP ещё и весьма не первой свежести, оно может уже просто «неработает по возрасту», мы же не знаем условий его эксплуатации все эти годы :)

anc ★★★★★
()

У меня такой же свисток. Работал прекрасно на ядрах до 5.15 включительно, при обновлении ядра до 5.18 стал регулярно отваливаться. Как по расписанию. Проблема в ядре - возврат на 5.15 решает. Пока жду, что пофиксят в 5.19, в багзилле была описана какая-то проблема с r8188

Может у тебя что-то схожее? не пробовал с другими ядрами?

Chord ★★★
()
Последнее исправление: Chord (всего исправлений: 1)
Admin