Moku prisijungti prie vieno Wi-Fi tinklo, bet nesugebu prisijungti prie kito
Mano veiksmų suvestinė:
# iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wlan0 IEEE 802.11bg ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=27 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:00:00:bb:00:62
inet addr:192.168.1.5 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::201:2eff:febb:2862/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:425 errors:0 dropped:0 overruns:0 frame:0
TX packets:213 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:39914 (38.9 KiB) TX bytes:29834 (29.1 KiB)
Interrupt:26 Base address:0xa000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:24 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2352 (2.2 KiB) TX bytes:2352 (2.2 KiB)
wlan0 Link encap:Ethernet HWaddr 00:00:00:bb:00:1d
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
# nano interfaces
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-conf /etc/network/wpa.conf
# nano wpa.conf
ctrl_interface=DIR=/var/run/wpa_supplicant
ap_scan=1
network={
ssid="Ghost"
psk=f58dcc5b816f-SLAPTAZODIS-f768335518f796cdf5
scan_ssid=1
#key_mgmt=WPA-PSK WPA-EAP IEEE8021X NONE
#pairwise=CCMP TKIP
#group=CCMP TKIP
}
# ifup wlan0
Internet Systems Consortium DHCP Client 4.1.1-P1
Copyright 2004-2010 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/wlan0/00:00:00:bb:00:1d
Sending on LPF/wlan0/00:00:00:bb:00:1d
Sending on Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
DHCPOFFER from 192.168.43.1
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPACK from 192.168.43.1
bound to 192.168.43.131 -- renewal in 1674 seconds.
# ping google.com
PING google.com (173.194.34.68) 56(84) bytes of data.
64 bytes from lhr14s19-in-f4.1e100.net (173.194.34.68): icmp_req=1 ttl=47 time=79.4 ms
64 bytes from lhr14s19-in-f4.1e100.net (173.194.34.68): icmp_req=2 ttl=47 time=87.9 ms
64 bytes from lhr14s19-in-f4.1e100.net (173.194.34.68): icmp_req=3 ttl=47 time=77.4 ms
64 bytes from lhr14s19-in-f4.1e100.net (173.194.34.68): icmp_req=4 ttl=47 time=75.8 ms
64 bytes from lhr14s19-in-f4.1e100.net (173.194.34.68): icmp_req=5 ttl=47 time=75.0 ms
64 bytes from lhr14s19-in-f4.1e100.net (173.194.34.68): icmp_req=6 ttl=47 time=73.8 ms
64 bytes from lhr14s19-in-f4.1e100.net (173.194.34.68): icmp_req=7 ttl=47 time=71.3 ms
64 bytes from lhr14s19-in-f4.1e100.net (173.194.34.68): icmp_req=8 ttl=47 time=80.3 ms
64 bytes from lhr14s19-in-f4.1e100.net (173.194.34.68): icmp_req=9 ttl=47 time=78.8 ms
^C
--- google.com ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8010ms
rtt min/avg/max/mdev = 71.341/77.795/87.936/4.495 ms
Kas mane erzina:
# ifdown wlan0
Internet Systems Consortium DHCP Client 4.1.1-P1
Copyright 2004-2010 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/wlan0/00:00:00:bb:00:1d
Sending on LPF/wlan0/00:00:00:bb:00:1d
Sending on Socket/fallback
DHCPRELEASE on wlan0 to 192.168.43.1 port 67
192.168.43.1 šis IP buvo priskirtas pirmą kartą prisijungus.
Vėliau, pakoregavus /etc/network/wpa.conf:
# ifup wlan0
Internet Systems Consortium DHCP Client 4.1.1-P1
Copyright 2004-2010 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/wlan0/00:00:00:bb:00:1d
Sending on LPF/wlan0/00:00:00:bb:00:1d
Sending on Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 13
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 18
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
Keista kad tai padejo.
Pagal dhcp logus matosi, kad jis bando siusti broadcasts messages i physical subnet tam, kad atrasti DHCP servers. Bet nieks neatsako ir jis uzmiega.
Gal del to kaltas ir pats routeris, o gal ir sf problema (blogi driveriai?). Gal loguose daugiau informacijos raso... Patarciau paziureti modinfo linux network modulio ir load ji su tinkamais parametrais pvz debug.
pamenu turejau ir as panasiu problemu, tai jas issprendziau pakeites viena ar kelis dhcpd hook skriptus (darasiau -x prie interpreter, kad matyciau debug informacija).
Kaip vėliau parodė eksperimentai, kalčiausias čia mano USB imtuvas arba jam valdyti naudojamas modulis (driver'is)?..
iwlist wlan0 scan deja randa tik tinklus, transliuojančius 6 kanalu. (Tinklas, prie kurio nepavyko tąkart prisijungti, groja kitu kanalu).
Jungiantis wpa_supplicant nerodo klaidų, todėl naiviai tikėjausi, kad susijungimas įvyksta, bet dėl kažkokių priežasčių negaunu IP..
Yra ir kitų bėdų su šiuo imtuvu..
# lsusb
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 004: ID 0846:4260 NetGear, Inc. WG111v3 54 Mbps Wireless [realtek RTL8187B]
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
# iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wlan0 IEEE 802.11bg ESSID:"Wi-Fi-Tinklas"
Mode:Managed Frequency:2.437 GHz Access Point: 00:00:00:D0:00:5C
Bit Rate=18 Mb/s Tx-Power=27 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=70/70 Signal level=-31 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Teoriškai tai yra 54 Mbps imtuvas, tačiau kaip matai viršuje, nusistato ant 18 Mbps. Pabandžius per interfaces failą forsuoti 54 - nusminga.. Reziumuojant, imtuvas vos ne vos išbezda vieną realų megabaitą (1MB/s). Trūks plyš, bet man tokio greičio nepakanka.
Toliau savo problemą sprendžiau labai paprastai - užsisakiau kitą imtuvą: TP Link TL-WN823N 300Mbps Mini Wireless N USB Adapter
Gal teko girdėti apie pastarąjį gerų/blogų atsiliepimų?
TL-WN823N, Kaip suprantu ten yra naudojamas Realtek cipas, tai Linux naudos rtl8192*(usb) moduli. Speju veiks, bet ne ka geriau, greiciausiai net ir blogiau.
Reiktų šiaip paieškot su atheros čipais veikiančiais ath9k_htc draiveriais. Juos ant Linux'ų oficialiai gamintojas bent palaiko ir patys čipai turi supportą wpa supplicant'ui ir WEXT draiveriui, tai panašių problemų neturėtų kilti.
@enternald rašė:
Reiktų šiaip paieškot su atheros čipais veikiančiais ath9k_htc draiveriais. Juos ant Linux'ų oficialiai gamintojas bent palaiko ir patys čipai turi supportą wpa supplicant'ui ir WEXT draiveriui, tai panašių problemų neturėtų kilti.
Mano problema labiau susijusi ne su palaikymo komandos nebuvimu (support), bet su paties imtuvo technologiniu nusidevėjimu - jis fiziškai negali perduoti man reikalingo srauto (per senas). Visa kita buvo tik mano kreivarankiškumas
# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0bda:8178 Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter
Veikia gerai, tik reikėjo pasirašyti mažą scenarijų, jei router'is sukvailioja.
#!/bin/bash
# Perkrauna Wi-Fi po rysio trukdziu..
## Kintamieji
_if='wlan0' # Interneto sasajos pavadinimas
_mod='rtl8192cu' # Interneto sasaja valdantis modulis
_ERR='kur_saugoti_klaidas'
## Naudojamos programos
## Gali tekti pasikoreguoti, priklausomai nuo Linux atsakos
_ifdown='/sbin/ifdown'
_ifup='/sbin/ifup'
_modprobe='/sbin/modprobe'
_ip='/sbin/ip'
_ping='/bin/ping'
_grep='/bin/grep'
_sleep='/bin/sleep'
_date='/bin/date'
_cut='/usr/bin/cut'
## Perjungiam Wi-Fi tinklo sasaja ir jos moduli
function i_restart()
{
$_ifdown "$1" &> /dev/null
$_sleep 1 && $_modprobe -r "$2"
$_modprobe "$2"
$_sleep 1 && $_ifup "$1" &> /dev/null
}
## Tikrinam, ar tinklas apskritai buvo prijungas
## Jei gaunam IP - susijungimas buvo
## Jei ne - tinklo sasaja net nebuvo ijungta
_dgate="$($_ip route show | $_grep default | $_cut -d' ' -f3)"
case "$_dgate" in
'') # Tiesiog paleidziam
i_restart $_if $_mod
;;
*) # Jei ijungta - tikrinam
$_ping -c1 -W1 -q $_dgate &> /dev/null
if [ "$?" -ne 0 ]; then
$_date >> "$_ERR"
i_restart $_if $_mod
else
exit 0 # Jei ijungta ir veikia - baigiam
fi
;;
esac
Istorija su gera pabaiga.
Tik va klausimas kodėl deklaravai _ip='/sbin/ip' ir panašius. Folderiai gali keistis sutinku, bet jie kaip taisyklė visados yra PATH'e Šiek tiek švelniai paranojiškas kodas sakyčiau.
Galbūt Tačiau scenarijus turi veikti per cron'ą. Nežinau kodėl, tačiau pilnai nenurodžius kelių iki įrankių man jis nesuveikdavo. Galbūt nesuveikdavo viena kažkuri dalis, tačiau reziumė - scenarijus neatlikdavo savo paskirties.
Atrodo gal ir gremėzdiškai, tačiau veikia.
Del PATH'u tai enternald yra teisus, Crontab rasant reikia priprasti nustatyti PATH, nes kartais jis buna laaabai uzsispyres
O siaip svarbu viskas gerai, man patinka C style shell skriptai ^^
Abu buvot teisūs, nežinau kodėl iškart nešovė į galvą apsirašyti PATH..
Žodžiu galutinis variantas atrodo jau paprasčiau
#!/bin/bash
# Perkrauna Wi-Fi po rysio trukdziu..
## Del 'cron' funkciniu ypatybiu apsirasom 'PATH'
PATH="/bin:/sbin:/usr/bin:$PATH:"
## Kiti svarbiausieji kintamieji
_if='wlan0' # Interneto sasajos pavadinimas
_mod='rtl8192cu' # Interneto sasaja valdantis modulis
_ERR='/kur/saugoti/klaidas'
## Perjungiam Wi-Fi tinklo sasaja ir jos moduli
function i_restart()
{
ifdown "$1" &> /dev/null
sleep 1 && modprobe -r "$2"
modprobe "$2"
sleep 1 && ifup "$1" &> /dev/null
}
## Tikrinam, ar tinklas apskritai buvo prijungas
## Jei gaunam IP - susijungimas buvo
## Jei ne - tinklo sasaja net nebuvo ijungta
_dgate="$(ip route show | grep default | cut -d' ' -f3)"
case "$_dgate" in
# Susijungimo nebuta - aktyvuojam sasaja
'')
i_restart $_if $_mod
;;
# Sasaja buvo aktyvi - tikrinam rysi
*)
ping -c1 -W1 -q $_dgate &> /dev/null
if [ "$?" -ne 0 ]; then
date >> "$_ERR"
i_restart $_if $_mod
# Jei aktyvi ir veikia - baigiam
else
exit 0
fi
;;
esac
Sveiki,
Moku prisijungti prie vieno Wi-Fi tinklo, bet nesugebu prisijungti prie kito
Mano veiksmų suvestinė:
Kas mane erzina:
192.168.43.1 šis IP buvo priskirtas pirmą kartą prisijungus.
Vėliau, pakoregavus /etc/network/wpa.conf:
No DHCPOFFERS received. Kodėl?
Išsprendė mano problemą, nors nesu tikras (šis failas lyg ir turėtų būti generuojamas automatiškai, jo išnulinimas nelabai turėtų turėti įtakos).
Bet kuriuo atveju, problema nebeaktuali.
Keista kad tai padejo.
Pagal dhcp logus matosi, kad jis bando siusti broadcasts messages i physical subnet tam, kad atrasti DHCP servers. Bet nieks neatsako ir jis uzmiega.
Gal del to kaltas ir pats routeris, o gal ir sf problema (blogi driveriai?). Gal loguose daugiau informacijos raso... Patarciau paziureti modinfo linux network modulio ir load ji su tinkamais parametrais pvz debug.
pamenu turejau ir as panasiu problemu, tai jas issprendziau pakeites viena ar kelis dhcpd hook skriptus (darasiau -x prie interpreter, kad matyciau debug informacija).
Kaip vėliau parodė eksperimentai, kalčiausias čia mano USB imtuvas arba jam valdyti naudojamas modulis (driver'is)?..
iwlist wlan0 scan deja randa tik tinklus, transliuojančius 6 kanalu. (Tinklas, prie kurio nepavyko tąkart prisijungti, groja kitu kanalu).
Jungiantis wpa_supplicant nerodo klaidų, todėl naiviai tikėjausi, kad susijungimas įvyksta, bet dėl kažkokių priežasčių negaunu IP..
Yra ir kitų bėdų su šiuo imtuvu..
Teoriškai tai yra 54 Mbps imtuvas, tačiau kaip matai viršuje, nusistato ant 18 Mbps. Pabandžius per interfaces failą forsuoti 54 - nusminga.. Reziumuojant, imtuvas vos ne vos išbezda vieną realų megabaitą (1MB/s). Trūks plyš, bet man tokio greičio nepakanka.
Toliau savo problemą sprendžiau labai paprastai - užsisakiau kitą imtuvą:
TP Link TL-WN823N 300Mbps Mini Wireless N USB Adapter
Gal teko girdėti apie pastarąjį gerų/blogų atsiliepimų?
Pritariu, sprendimas geras
TL-WN823N, Kaip suprantu ten yra naudojamas Realtek cipas, tai Linux naudos rtl8192*(usb) moduli. Speju veiks, bet ne ka geriau, greiciausiai net ir blogiau.
Reiktų šiaip paieškot su atheros čipais veikiančiais ath9k_htc draiveriais. Juos ant Linux'ų oficialiai gamintojas bent palaiko ir patys čipai turi supportą wpa supplicant'ui ir WEXT draiveriui, tai panašių problemų neturėtų kilti.
Na aš pasitikiu udev, tikiu, kad pagavo reikiamą “čipą”: jei pažvelgsi į lsusb - realtek RTL8187B.
Vienaip ar kitaip - šaukštai po pietų, laukiu nesulaukiu, kada atkeliaus naujas imtuvas
Mano problema labiau susijusi ne su palaikymo komandos nebuvimu (support), bet su paties imtuvo technologiniu nusidevėjimu - jis fiziškai negali perduoti man reikalingo srauto (per senas). Visa kita buvo tik mano kreivarankiškumas
Jei kam įdomu - istorijos tęsinys
Taigi, naudojamas modulis: RTL8192CU.
Veikia gerai, tik reikėjo pasirašyti mažą scenarijų, jei router'is sukvailioja.
Istorija su gera pabaiga.
Tik va klausimas kodėl deklaravai _ip='/sbin/ip' ir panašius. Folderiai gali keistis sutinku, bet jie kaip taisyklė visados yra PATH'e Šiek tiek švelniai paranojiškas kodas sakyčiau.
Galbūt Tačiau scenarijus turi veikti per cron'ą. Nežinau kodėl, tačiau pilnai nenurodžius kelių iki įrankių man jis nesuveikdavo. Galbūt nesuveikdavo viena kažkuri dalis, tačiau reziumė - scenarijus neatlikdavo savo paskirties.
Atrodo gal ir gremėzdiškai, tačiau veikia.
Del PATH'u tai enternald yra teisus, Crontab rasant reikia priprasti nustatyti PATH, nes kartais jis buna laaabai uzsispyres
O siaip svarbu viskas gerai, man patinka C style shell skriptai ^^
Abu buvot teisūs, nežinau kodėl iškart nešovė į galvą apsirašyti PATH..
Žodžiu galutinis variantas atrodo jau paprasčiau
Tiesa, PATH gali nustatyti ir i ctrontab, kaip pvz: crontab -e (is paprasto user)
Arba leisti komanda taip:
Kartais buna problemu jeigu nori notify naudoti (dbus)
tokiu atveju patariu susikurti toki skripta:
Dabar matysi kada suveikia cronjob!
Dėkui už naudingus patarimus
Tema perkelta iš https://legacy.ubuntu.lt/forum/viewtopic.php?f=1&t=8853