Это добьется цели:
PPATH=$(while [[ "$PWD" != / && ! -f project.rc ]]; do cd ..; done; echo "$PWD")
Переменная PPATH
будет затем содержать путь проекта, из которого Вы называете команду. Можно затем найти всю информацию, в которой Вы нуждаетесь в Вашем $PPATH/project.rc
. (Переменная будет расположена в /
если нет такого файла в родительских каталогах.)
Этот вид проблемы лучше разделен на независимые части. В этом случае, хитрость ifupdown
полностью и делая все шаги вручную - который является:
выполненный wpa_supplicant
с соответствующим файлом конфигурации
после того как соединение устанавливается, выполняя клиента DHCP,
Проверять как ifupdown
выполнения wpa_supplicant
- это должно передать его своего рода конфигурация в файле, который Вы могли прервать - проверяют вывод ps fax | grep wpa_supplicant
когда ifupdown
работает - параметр -c
опция является названием (вероятно, на лету сгенерированный) конфигурационный файл.
Если Вы решили переключиться от ifupdown
по некоторым причинам Вы могли бы интересоваться wicd
, который состоит из демона, которым управляет различный UIs (ncurses, GTK, QT).
Между прочим, некоторые клиенты DHCP могут настроить беспроводное соединение путем порождения wpa_supplicant
самостоятельно (я видел dhcpcd
выполнение этого) - который может быть довольно интригующим (и вмешивающийся), когда каждый пытается отладить проблемы соединения.
Это - порядок вещей, которые я попробовал бы при отладке облупленного беспроводного устройства.
Попытайтесь разгрузить драйверы ядра, связанные с беспроводным устройством. Что-то к эффекту следующего:
$ 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
Исследуйте любые сообщения, связанные с беспроводным устройством, сообщаемым через 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
wpa_supplicant
тонкая настройка. Гм, для меня кажется странным, что перезагрузка модуля ядра может решить вопрос. Это происходило, по вашему опыту?
– Boris Burkov
22.09.2013, 02:53
Было рука встряхните
+ FAIL
тоже долго. Ни одно решение из форумов ( gentoo
| Arch
), ни stackexchange
у меня не сработало.
Я использую «голый» void
linux, использую только необходимые программы dhcpcd
, wpa_supplicant
.
То, что, наконец, сработало, заняло у меня много времени, но другого шанса не было, потому что:
чип WLAN
(чтобы исключить неисправное оборудование) не был в жестко закодированном поддерживаемом белом списке аппаратного обеспечения
в загрузчике Lenovo. Да, действительно здорово, совместимы, но их просто нет в списке, и поэтому они не работают, вау, просто вау. Жестко закодированный белый список
! 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, правильный сетевой интерфейс работают | и работает, и что сетевой интерфейс, например 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 e.g. "wlan0" to the correct interface as shown by ip link command, exempli gratia "wlp2s".
Похоже, что NetworkManager имеет некоторый эффект, и это исправление! У меня еще не было времени выяснить, что это такое.
wpa_supplicant.conf
?psk
параметр должен содержать фактический пароль, не его хеш (как он, sometimeas происходит). Также иногда это могло бы помочь выключению (или на) IPv6 (отзовитесь эхом 0 или 1 к/proc/sys/net/ipv6/conf/all/disable_ipv6
) - Я видел, что проблемы соединения с IPv6 включили, хотя я больше не вспоминаю, было ли это с этой ошибкой. – peterph 23.09.2013, 23:41psk
пароль и его хеш (в случае чистого пароля, я использовал""
вокруг этого). Спасибо за ipv6 предложение я попробую его – Boris Burkov 24.09.2013, 16:47