Не работает wifi atheros на ноутбуке с Debian
Добрый день! Помогите решить проблему с неработающим wifi!
Ноутбук dell 3584-7386. Недавно установил Debian 10 + openbox. Сразу же поставил firmware-atheros. Через wicd подключился к wifi, нормально работало весь вечер. На следующее же утро не могу подключиться.
Сначала подумал что имя интерфейса изменилось, в wicd ведь его надо руками указать. Однако ifconfig -a выдает только проводное соединение, через которое я сейчас и подключен.
sudo rfkill list и sudo rfkill —output-all не выдают ничего sudo rfkill unblock all не помогает
через lspci адаптер виден:
fn+PrintScreen, на котором комбинация включения wifi, тоже не помогает)
Пару недель назад ставил Ubuntu Server 18.04 + openbox + wicd/network-manager и происходила такая же ерунда. Т.е. от версии ядра, видимо, не зависит проблема.
Также пробовал десктопные ubuntu, kubuntu — там такого косяка не наблюдал, но по некоторым причинам, я не хочу использовать тяжелые de, да и убунту вообще.
P.S. На линукс перешел чуть более полугода назад, многих вещей не понимаю, обьясняйте подробнее, пожалуйста, хочу все знать)
нормально работало весь вечер. На следующее же утро не могу подключиться.
Что было с ноутбуком (или wifi-адаптером) в промежутке «от вечера» до «следующего утра»?
dmesg смотрел? там-то что-то должно быть…
Ноутбук на ночь всегда выключаю.
lspci -knn|grep Network -A3
Про dmesg впервые слышу, к сожалению.
sudo dmesg —level=warn,err,crit,alert,emerg
На форуме нельзя сообщения заспойлерить -_-
Пойду гуглить ошибки…
модуль для устройства (драйвер) загружается – это «+». Но сетевой интерфейс не создаётся, т.к. в dmesg
ссылается на недоступность firmware для адаптера… нужно посмотреть «что там происходит»
- просто файл называется иначе
- лежит не в «своей» директории
- его действительно нет // не, а вдруг?
- …
хотя возникает вопрос как же оно работало накануне.
dmesg первый источник для поиска корня многих проблем
На форуме нельзя сообщения заспойлерить
но у тебя же получилось. Пользуйся кнопкой «Предпросмотр» до публикации – сильно помогает 🙂
ссылается на недоступность firmware для адаптера
Пускай в /var/cache/apt/archives найдёт пакет и поковыряется в его содержимом на предмет «недостающих» файлов.
может ошибаюсь, но сейчас по-умолчанию в дебианах установленные пакеты в кеше не хранятся. но, направление поддерживаю – нужно посмотреть, что там внутри. с самими firmware понятно – они необходимы. а вот почему сначала они есть, а при новой загрузке их нет… ответ вполне может быть найден в deb-пакете
Возможно, фирмварь с винды загрузилась перед установкой дебиана, а при полном выключении память адаптера сбросилась.
сначала они есть, а при новой загрузке их нет
Установочные скрипты в deb-пакете могут не соответствовать параметрам системы.
про винду я как-то пропустил… и потом автор явно указывал, что устанавливал firmware для atheros
Установочные скрипты в deb-пакете могут не соответствовать параметрам системы.
Политика «непричастности» к пакетам с «сомнительной» лицензией означает, что Debian-сообщество положило на эти пакеты болт.
глянул содержимое пакета. какая «неожиданность»: там нет файлов с именами, которые ищет его система. ну так-то они есть, но называются иначе и лежат в другой директории(ях). теперь «такое» уже «не баг, а фича»© ?!
но называются иначе и лежат в другой
уже убедился… нечто хорошее словом «политика» не назовут 🙁 [жизненный опыт]
вообще-то это не у меня, а у ТС проблема…
но я всё-таки посмотрел пакет (не останавливаться же :). Там нет postinstall вообще. И install (барабанная дробь) … содержит только предупреждение …
из «простого»: можно удалить пакет firmware-atheros, установить заново и попытаться выяснить какие из 4-х файлов необходимы (или в какой последовательности) // это при условии, что после повторной установки оно заработает
Точнее надо говорить:
Извините, прямо сейчас нет времени решать проблемку, работаю на удаленке. Пока уходил на обед, выключил ноут, а когда включил… wifi работает как ни в чем не бывало… Если кому-то интересно, вот вывод dmesg (здесь только для ath10k, это, как я понимаю и есть виновник торжества)
судя по логам при загрузке может некий глюк происходить:
- иногда «стопорится» загрузка firmware
- иногда всё само решается
как вариант в следующий раз, когда не заработает, можно попробовать перезагрузить драйвер для адаптера. может и сработает.
может более сведущие и/или опытные предложат что-то более адекватное
Перезагрузка драйвера помогает!
Хоть я и не спец, инфа может помочь кому-то кто не шарит/не имеет на это времени/не хочет ковыряться, поэтому расскажу что делал:
Смотрим, загружен ли вообще модуль: lsmod | grep ath10k
Отрубаем его: sudo modprobe ath10k_pci -r
Можем снова посмотреть что это сработало: lsmod | grep ath10k Теперь команда не должна ничего вывести в консоль
Включаем модуль: sudo modprobe ath10k_pci
Wifi работает. До перезагрузки во всяком случае.
Хотелось бы разобраться с этим до конца, но боюсь, моих знаний не хватит, не понимаю что дальше делать)) Есть у нас модуль ядра, он заглючивает. Как в нем порыться? Или там все сложно и не стоит туда лезть?
да я знаю ) есть ли другие механизмы решения? не знаю.
Есть у нас модуль ядра, он заглючивает. Как в нем порыться? Или там все сложно и не стоит туда лезть?
сложно или нет зависит от твоего уровня знаний и умений. можешь посмотреть код драйвера… а дальше куда «кривая вывезет»…
моих знаний не хватит, не понимаю что дальше делать
у этой ситуации две стороны
- как пользователь оформи в своей системе перезагрузку драйвера скриптом (это самое простое решение). дальше простор для творчества: можешь выполнять скрипт в терминале «ручками», можешь сделать ярлык на запуск скрипта с рабочего стола… или сделать юнит для системд для автоматического выполнения перезагрузки драйвера при необходимости
// я бы реализовал самое простое и удобное для меня решение
- как причастный к debian пользователь ты можешь отправить баг-репорт о проблеме (или даже разработчикам ядра – я вот не знаю, кого эта проблема больше касается)
отправить баг-репорт о проблеме (или даже разработчикам ядра
Так очевидный жест от Товальдса можно схлопотать.
а потом ноем «годами баги не правятся… даже в багтрекер никто не пишет…»
Ядро нельзя подстроить под всех, иначе его «разорвёт».
тогда пусть собирает команды в скрипт, пишет юнит. всё это как патч оправляет Линусу (мелочиться мы не будем) или как любят в debian собирает пакет ath10k-pci-cureit-wifi.deb (правда его точно отклонят и не из-за названия)
драйвер же в ядре и даже через раз работает без тычка. может и не в нём дело?
или как любят в debian собирает пакет ath10k-pci-cureit-wifi.deb
И чо! Отклонят! Это «аргумент» на любом толксе. Не пургу гнать, а бац и выложил ссылочку на пакетик.
ишет юнит. всё это как патч оправляет Линусу
юниты же в ведении лёни потного… но такое и он не примет. лучше отписаться в wiki debian – самое адекватное, имхо, решение.
Поставил OpenSUSE Leap 15.1, тоже на дебиане, аналагичная проблема. Отключение и включение модуля помагает тоже. Лучшее решение, что я нашел в интернетах
Источник
Qualcomm Atheros QCA9377 не переводится в режим монитора.
kali linux 2020.4 wifi модуль Qualcomm Atheros QCA9377 немогу перевести в режим мониторинга.подскажите что делать?
А он в принципе поддерживает режим монитора?
Как минимум нужно было указать чипсет, какие команды вводите и какие сообщения получаете. Также смотрите здесь « Как задать вопрос о проблеме с Wi-Fi адаптером ».
@mial Привет.Спасибо что откликнулся.При сканировании wifi сетей не видит их,пробовал wifite-айрогедон ,в режим монитора переходит а точки доступа не видит.
└─$ lspci
00:00.0 Host bridge: Intel Corporation 8th Gen Core 4-core Processor Host Bridge/DRAM Registers [Coffee Lake H] (rev 07)
00:01.0 PCI bridge: Intel Corporation 6th-9th Gen Core Processor PCIe Controller (x16) (rev 07)
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 630 (Mobile)
00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 07)
00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model
00:12.0 Signal processing controller: Intel Corporation Cannon Lake PCH Thermal Controller (rev 10)
00:14.0 USB controller: Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller (rev 10)
00:14.2 RAM memory: Intel Corporation Cannon Lake PCH Shared SRAM (rev 10)
00:15.0 Serial bus controller [0c80]: Intel Corporation Cannon Lake PCH Serial IO I2C Controller #0 (rev 10)
00:15.1 Serial bus controller [0c80]: Intel Corporation Cannon Lake PCH Serial IO I2C Controller #1 (rev 10)
00:16.0 Communication controller: Intel Corporation Cannon Lake PCH HECI Controller (rev 10)
00:17.0 SATA controller: Intel Corporation Cannon Lake Mobile PCH SATA AHCI Controller (rev 10)
00:1d.0 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #9 (rev f0)
00:1d.4 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #13 (rev f0)
00:1d.5 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #14 (rev f0)
00:1e.0 Communication controller: Intel Corporation Cannon Lake PCH Serial IO UART Host Controller (rev 10)
00:1f.0 ISA bridge: Intel Corporation HM470 Chipset LPC/eSPI Controller (rev 10)
00:1f.3 Audio device: Intel Corporation Cannon Lake PCH cAVS (rev 10)
00:1f.4 SMBus: Intel Corporation Cannon Lake PCH SMBus Controller (rev 10)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Lake PCH SPI Controller (rev 10)
01:00.0 VGA compatible controller: NVIDIA Corporation GP107M [GeForce GTX 1050 3 GB Max-Q] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GP107GL High Definition Audio Controller (rev a1)
06:00.0 Non-Volatile memory controller: Sandisk Corp Device 5008 (rev 01)
07:00.0 Network controller: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter (rev 31)
08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 10)
phy#0
Unnamed/non-netdev interface
wdev 0x2
addr 80
type P2P-device
txpower 0.00 dBm
Interface wlan0
ifindex 3
wdev 0x1
addr 80
ssid
type managed
channel 3 (2422 MHz), width: 40 MHz, center1: 2432 MHz
txpower 20.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 0 0 0 0 0 0 0
PHY Interface Driver Chipset
phy0 wlan0 ath10k_pci Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter (rev 31)
Точно такую же проблему обсуждают в этих ветках:
То есть режим монитора работает, но ничего не захватывает.
Один из пользователей написал причину и решение. Он заметил, что Atheros QCA9377 в airodump отлично работает на версиях Kali выпущенных в 2018 поскольку Atheros QCA9377 в этих версиях использует firmware-5 (прошивку пятой версии).
Но проблема появляется при использовании firmware-6 на версиях Kali выпущенных в 2020 и 2019. Пользователь использовал firmware-5 из 2018 и всё стало работать как надо.
Этот пользователь извлёк пятую версию прошивки и загрузил её на GitHub.
Сейчас если проверить содержимое папки с прошивкой для Atheros QCA9377:
Можно увидеть, что там и пятая и шестая версии:
-rw-r—r— 1 root root 304308 сен 23 11:11 board-2.bin
-rw-r—r— 1 root root 8124 сен 23 11:11 board.bin
-rw-r—r— 1 root root 605908 сен 23 11:11 firmware-5.bin
-rw-r—r— 1 root root 751436 сен 23 11:11 firmware-6.bin
Поэтому можно попробовать удалить шестую версию. А если это не поможет, то загрузить версию с GitHub.
Обязательно начинаем с создания резервной копии (на случай если что-то пойдёт не так):
Удаляем шестую версию:
Чтобы изменения вступили в силу, перезагружаемся:
Проверьте с airodump или с другой программой.
Если это не помогло, то скачиваем версию с гитхаба:
Удаляем прошивку (предполагается, что вы уже сделали резервную копию как показано выше):
Копируем скаченную пятую версию в то место, где она должна быть в системе:
Чтобы изменения вступили в силу, перезагрузитесь:
Теперь захват данных должен работать в airodump и других программах.
Напишите, помогло ли вам это. И что именно сработало — удаление шестой версии или скачивание версии с Гитхаба.
Источник
