«Wpa supplicant: не найдена сетевая конфигурация для текущего AP» – адаптер Wi-Fi, основанный на carl9170, скрежет на Debian 7

У меня есть машина Debian 7 с ядром Linux3.2 и адаптер Wi-Fi USB с чипсетом Atheros (D-Link DWA-16 Xtreme N Dual Band), который теоретически должен работать .

Действительно, мне удалось установить Wi-Fi-связь с NetworkManager, и он работал более или менее нормально в течение 30 минут, но затем отключился и не смог восстановить соединение.

Мне не удалось восстановить соединение с NetworkManager, он успешно связывает и проверяет подлинность, запускает 4-стороннее рукопожатие, но затем деаутентифицирует по причине 15 (4-стороннее время установления связи) .

Затем я попытался сделать то же самое с помощью старого старого ifupdown , создав запись в /etc/network/interfaces :

 allow-hotplug wlan1 iface wlan1 inet static wpa-ssid MyNet wpa-psk <My key hash generated by `wpa_passphrase MyNet key`> address 192.168.1.2 netmask 255.255.255.0 broadcast 192.168.1.255 gateway 192.168.1.1 dns-nameservers abcd 

Когда я sudo ifup wlan1 , он ведет себя разумно, пока:

 wpa_supplicant[8258]: wlan1: Associated with <router's MAC> wpa_supplicant[3402]: wlan1: No network configuration found for the current AP 

(из /var/log/syslog ). Wireshark видит пакеты ARP, идущие от моего адаптера wifi к маршрутизатору, но маршрутизатор не отвечает.

Есть ли у вас какие-либо идеи о том, что это значит и как их устранять?

РЕШЕНИЕ: Благодаря предложению peterph я попытался создать wpa_supplicant.conf и запустить wpa_supplicant как отдельную программу как на переднем плане, так и на заднем плане, а затем использовать wpa-conf wpa_supplicant.conf в /etc/network/interfaces .

 sudo wpa_supplicant -iwlan1 -c/etc/wpa_supplicant/wpa_supplicant.conf -d sudo wpa_supplicant -iwlan1 -c/etc/wpa_supplicant/wpa_supplicant.conf -B 

У меня была первая часть проблем (со спонтанным отключением после «status: related») исчезают, когда я убил запущенный экземпляр NetworkManager . Кажется, это вмешалось.

Вторая часть проблемы заключалась в том, что 4-стороннее рукопожатие потерпело неудачу. Он прошел нормально, когда я отключил фильтрацию MAC-адресов в точке доступа. MAC моего интерфейса wifi был в списке доступных MAC-адресов, но по какой-то причине он по-прежнему не смог подключиться к фильтрации MAC-адресов на маршрутизаторе.

ОБНОВЛЕНИЕ 2: Проблемы вернулись. 4-стороннее рукопожатие снова не срабатывает. Перезагрузка драйвера не поможет.

Эта проблема лучше разделена на независимые части. В этом случае обход полностью ifupdown и выполнение всех шагов вручную – это:

  1. запустите wpa_supplicant с соответствующим конфигурационным файлом

  2. после установления соединения, запуска dhcp-клиента,

Чтобы проверить, как ifupdown запускает wpa_supplicant – он должен передать ему какую-то конфигурацию в файле, которую вы можете перехватить – проверьте вывод ps fax | grep wpa_supplicant ps fax | grep wpa_supplicant при ifupdown – параметр параметра -c – это имя файла конфигурации (возможно, «на лету»).

Если вы решили переключиться с ifupdown по какой-то причине, вас может заинтересовать wicd , который состоит из демона, управляемого различными пользовательскими интерфейсами (ncurses, GTK, Qt).

Кстати, некоторые клиенты DHCP могут настроить беспроводное соединение, wpa_supplicant самостоятельно (я видел, что dhcpcd делает это), что может быть довольно интригующим (и мешающим), когда вы пытаетесь отладить проблемы с подключением.

Это порядок вещей, которые я попытаюсь при отладке сломанного беспроводного устройства.

  1. Перезагрузка устраняет проблему?
  2. Попробуйте выгрузить драйверы ядра, связанные с беспроводным устройством. Что-то в виду следующего:

     $ lsmod | grep iw iwlagn 209751 0 iwlcore 195714 1 iwlagn mac80211 229095 2 iwlagn,iwlcore cfg80211 134981 3 iwlagn,iwlcore,mac80211 $ sudo rmmod iwlagn $ sudo rmmod iwlcore $ modprobe iwlagn 
  3. Изучите любые сообщения, связанные с сообщением о беспроводном устройстве через dmesg . Например:

     $ dmesg ... ... [207981.191849] mac80211: Unknown parameter `ieee80211_disable_40mhz_24ghz:Disable' [207988.895378] mac80211: `Disable' invalid for parameter `ieee80211_disable_40mhz_24ghz' [208280.841725] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree:d [208280.841727] iwlagn: Copyright(c) 2003-2010 Intel Corporation [208280.841826] iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [208280.841857] iwlagn 0000:03:00.0: setting latency timer to 64 [208280.842798] iwlagn 0000:03:00.0: Detected Intel(R) Centrino(R) Wireless-N 1000 BGN, REV=0x6C [208280.863413] iwlagn 0000:03:00.0: Tunable channels: 13 802.11bg, 0 802.11a channels [208280.863582] iwlagn 0000:03:00.0: irq 48 for MSI/MSI-X [208280.898025] iwlagn 0000:03:00.0: loaded firmware version 128.50.3.1 build 13488 [208280.898725] phy1: Selected rate control algorithm 'iwl-agn-rs' [208281.154937] ADDRCONF(NETDEV_UP): wlan0: link is not ready [208282.101156] wlan0: authenticate with 30:46:9a:47:4c:d4 (try 1) [208282.104128] wlan0: authenticated [208282.104164] wlan0: associate with 30:46:9a:47:4c:d4 (try 1) [208282.106911] wlan0: RX AssocResp from 30:46:9a:47:4c:d4 (capab=0x411 status=0 aid=3) [208282.106914] wlan0: associated [208282.111520] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [208292.608637] wlan0: no IPv6 routers present 

Если бы hand shake долго не FAIL + проблемы с FAIL . Ни одно решение из ( gentoo | Arch ) форумов или stackexchange работало для меня.

Я нахожусь на пустой кости void linux, используя только основные программы dhcpcd , wpa_supplicant .

Что, наконец, сработало, заняло много времени, но другого шанса не было, потому что:

  • разъем женского кабеля LAN также сломан без какой-либо запасной части, доступной у любого дистрибьютора электроники от DigiKey | Farnell | Reichelt | Conrad | Mouser | Amazon, так как он представляет собой вариант с половинной высотой без знака детали | номер | подсказка.
  • пайка отдельных нитей на материнскую плату, какие сумасшедшие усилия, не делайте это дома, хаха, при работе, требует тонких (очень тонких) гибких проводов, чтобы не коротко или не сломаться!
  • замена WLAN chip (чтобы исключить поврежденное оборудование) не была в жестком кодированном поддерживаемом hardware whitelist в загрузчике Lenovo. Да, действительно здорово, совместимо, но просто не указано и, таким образом, не работает, ничего себе, просто ничего себе. Hard coded white list ! Lenovo! Здравый смысл?

Таким образом, после кучи проб и ошибок, отладки времени возникло другое исправление (возможность), которое я хотел бы поделиться с сообществом.

Решение, которое работает для меня каждый раз после перезагрузки: 1

 sudo wpa_cli # fail sudo xbps-install -Syv NetworkManager sudo ln -s /etc/sv/NetworkManager /var/service/ 

2 (может запускаться автоматически после загрузки).

 sudo sv up NetworkManager sudo wpa_cli # works half way (scan possible but association fails) sudo sv down NetworkManager sudo wpa_cli # fail sudo sv restart dhcpd sudo wpa_cli # works 

Убедитесь, что dhcpcd, wpa_supplicant, правильный сетевой интерфейс up | и работает и что сетевой интерфейс, например wlan0 или wlp2s, используется в /etc/wpa_supplicant/wpa_supplication.conf, id est:

  sudo vi /etc/sv/wpa_supplicant/run # Change all occurrences of the default interface name like eg "wlan0" to the correct interface as shown by ip link command, exempli gratia "wlp2s". 

Похоже, что NetworkManager имеет некоторый эффект, который является исправлением! Я еще не успел исследовать, что это такое.