Fórum Ubuntu CZ/SK
Ubuntu pro osobní počítače => Internet a sítě => Téma založeno: xtal 30 Března 2010, 10:39:47
-
Podaří se mi připojit k wi-fi síti zprostředkované routerem (nm-tool vypíše State: connected), ping na adresu nameserveru (z cat /etc/resolv.conf) funguje, ale ping na jakoukoli jinou adresu ne. Router je podle všeho v pořádku, protože se skrze něj kolegové dokážou připojit.
V prohlížečích to vypadá tak, že pro jakoukoli adresu dojde k timeoutu.
Zkusil jsem návody na https://help.ubuntu.com/community/WifiDocs/WirelessTroubleShootingGuide (https://help.ubuntu.com/community/WifiDocs/WirelessTroubleShootingGuide), ale nezdá se mi, že by tam pro mě měli řešení.
Nenapadá někoho nějaký lepší postup, jak zjistit, v čem je problém?
-
A name server běží kde? Na tom routeru? Nebo dál?
-
Jak to zjistím, kde běží nameserver?
Jinak jsem teď zjistil, že na jiné wi-fi se připojím, takže chyba bude nejspíš někde na půli cesty mezi počítačem a routerem.
-
Vůbec to nechápu, ale internet začal bez jakéhokoli mého pozorovatelného zásahu fungovat. Každopádně pořád nevím, co dělat, když se mi to stane znovu.
Výpisy:
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 00:16:d3:85:ea:8e brd ff:ff:ff:ff:ff:ff
3: wmaster0: <UP,LOWER_UP> mtu 0 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ieee802.11 00:1c:bf:9b:b8:96 brd 00:00:00:00:00:00
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:1c:bf:9b:b8:96 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.5/16 brd 172.16.255.255 scope global wlan0
inet6 fe80::21c:bfff:fe9b:b896/64 scope link
valid_lft forever preferred_lft forever
5: pan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
link/ether d6:c8:59:80:50:18 brd ff:ff:ff:ff:ff:ff
ip r
169.254.0.0/16 dev wlan0 scope link metric 1000
172.16.0.0/16 dev wlan0 proto kernel scope link src 172.16.0.5 metric 2
default via 172.16.0.138 dev wlan0 proto static cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 172.16.0.138dhcpcd-test jsem nenašel, je v nějakém balíčku v repozitářích?
-
Takže třeba:
ping forum.ubuntu.czpadne na timeout?
A co vrátí:
dig -t A forum.ubuntu.cz
Co dává ping 217.31.205.114A co tracepath 217.31.205.114
PS: připojené to viditelně je, teď jde o ten nameserver, je možné, že vrací kraviny ... to už tu bylo :D
-
Jak jsem psal, problém se sám od sebe opravil, takže výpisy těch příkazů by teď byly asi zbytečné (jelikož internet funguje).
Ale když jsem předtím zkoušel ping na jakoukoli adresu (třeba ping forum.ubuntu.cz), vypršel na timeout. dig jsem nezkoušel.
Nevím, zdali se to dá řešit teď, když vše bez zjevného důvodu opět funguje, ale rozhodně se mi s řešením nechce čekat, až to znovu přestane fungovat. Na podobné problémy, které mizí a objeví se, rozhodně nejsem na linuxu zvyklý. Většinou mělo vše jasnou příčinu. :-\
-
Tak to je opravdu divoké.
Viděl bych ale problém v nadřazených DNS serverech té krabičky (kupříkladu vracely ipv6 adresy jako první), což (dle zkušeností) v ubuntu bohužel způsobí nedostupnost www stránek.
Chtělo by to v době nefunkčnosti ping přímo na nějakou veřejnou IP adresu - tím by se vyloučilo (nebo potvrdilo) DNS.
-
Ping na veřejné IP jsem taky zkoušel (je to v testech doporučovaných na https://help.ubuntu.com/community/WifiDocs/WirelessTroubleShootingGuide (https://help.ubuntu.com/community/WifiDocs/WirelessTroubleShootingGuide)) a dopadlo to stejně - timeoutem.
-
Tak pak končím a byl to trpaslík s buldozerem na kabelu.
Už mu ho MP asi (naštěstí) zabavila ...
-
To ale není fér všechno svádět na trpaslíky! :)
-
A nejhorší ze všeho jsou trpaslíci. Ty potvory vám vlezou všude. A strašně rychle se množí!
Tak doufejme, že tenhle umřel :D
-
Takže můj problém se mi vrátil. Už od soboty se nemůžu připojit (teď funguju z notebooku na Windows, kterému připojení přes stejný router kupodivu funguje). Jaké bych měl zaslat výpisy, aby se dalo zjistit něco více?
-
$ ping -c 4 forum.ubuntu.cz
PING forum.ubuntu.cz (217.31.205.114) 56(84) bytes of data.
--- forum.ubuntu.cz ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3016ms
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 00:16:d3:85:ea:8e brd ff:ff:ff:ff:ff:ff
3: wmaster0: <UP,LOWER_UP> mtu 0 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ieee802.11 00:1c:bf:9b:b8:96 brd 00:00:00:00:00:00
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:1c:bf:9b:b8:96 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.3/16 brd 172.16.255.255 scope global wlan0
inet6 fe80::21c:bfff:fe9b:b896/64 scope link
valid_lft forever preferred_lft forever
5: pan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
link/ether 3e:76:13:6b:9b:9f brd ff:ff:ff:ff:ff:ff$ ip r
169.254.0.0/16 dev wlan0 scope link metric 1000
172.16.0.0/16 dev wlan0 proto kernel scope link src 172.16.0.3 metric 2
default via 172.16.0.138 dev wlan0 proto static $ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 172.16.0.138
$ dig -t A forum.ubuntu.cz
; <<>> DiG 9.6.1-P2 <<>> -t A forum.ubuntu.cz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2988
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;forum.ubuntu.cz. IN A
;; ANSWER SECTION:
forum.ubuntu.cz. 15854 IN A 217.31.205.114
;; AUTHORITY SECTION:
ubuntu.cz. 4826 IN NS kitsune.ubuntu.cz.
ubuntu.cz. 4826 IN NS tanuki.ubuntu.cz.
;; ADDITIONAL SECTION:
tanuki.ubuntu.cz. 56051 IN A 217.31.205.114
tanuki.ubuntu.cz. 56051 IN AAAA 2001:1488:d91f:cd70::cd72
;; Query time: 521 msec
;; SERVER: 172.16.0.138#53(172.16.0.138)
;; WHEN: Mon Apr 5 15:19:49 2010
;; MSG SIZE rcvd: 136
$ ping -c 4 217.31.205.114
PING 217.31.205.114 (217.31.205.114) 56(84) bytes of data.
--- 217.31.205.114 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3023ms
$ tracepath 217.31.205.114
1: xtalbook.local (172.16.0.3) 0.239ms pmtu 1500
1: 172.16.0.138 (172.16.0.138) 8.092ms asymm 2
1: 172.16.0.138 (172.16.0.138) 5.727ms asymm 2
2: no reply
-
Je ta wifina šifrovaná? Restart nepomůže?
Obligátní rada: zkus wicd...
-
Restart nic nezmění. Wi-fi by šifrovaná být neměla - jak to zjistím? wicd nemám nainstalováno a bez internetu to bude chvilku trvat.
-
wicd nenainstaluju, protože je v konfliktu s network-manager.
-
wicd nenainstaluju, protože je v konfliktu s network-manager.
Má odpověď zahrnuje jen tuhle otázku bez přemýšlení nad přechozími řešeními.
Když nainstaluješ WICD, nahradí NM. Takže se toho neboj. Oba dva v systému nemohou být. Prali by se :)
-
wicd nenainstaluju, protože je v konfliktu s network-manager.
Má odpověď zahrnuje jen tuhle otázku bez přemýšlení nad přechozími řešeními.
Když nainstaluješ WICD, nahradí NM. Takže se toho neboj. Oba dva v systému nemohou být. Prali by se :)
Přesně tak, nejdřív nainstalovat wicd a natwork-manager by se měl odinstalovat sám, i když teď při poslední instalaci v 10.04 jsem to musel dělat ručně :)
-
Výborně, tak jsem network-manager ručně odebral a nainstaloval wicd. Jak mi teď wicd může pomoci v řešení mého problému?
-
Výborně, tak jsem network-manager ručně odebral a nainstaloval wicd. Jak mi teď wicd může pomoci v řešení mého problému?
To připojení přes wicd nefunguje?
-
Bez připojení k internetu jsem musel wicd instalovat rovnou z deb balíku, takže jsem network-manager dával pryč sudo apt-get remove network-manager.
Co se týče připojení přes wicd-client, nepozoruju žádné změny.
-
Hm, tak tohle je zajimave...
A rikas ze se pres windows na tu wi-fi pripojis?
-
Jo, přes Windows připojení funguje.
-
Blbej trpaslík.
No vidím to na nějakou botu na routeru, protože až na něj se dostane, dokonce obdrží i správné IP k DNS dotazu, zkuste prosím restartovat ten router, zda to pomůže - pokud ano, zkusil bych update firmware na routeru. Taky by to mohla být jeho (routeru) poškozená paměť - neudrží kompletní NAT tabulku ...
-
PMV: Právě proto jsem se ptal ohledně těch Windows, pokud jsem pochopil správně tak při nabootování do Win a připojení vše funguje tak jak má, takže bych to asi neházel na router (ale jistý si tím nejsem)...
xtal: Zkus si stáhnout live cd (http://proc.linux.cz/chci-vyzkouset.html) nějaké jiné distribuce než ubuntu, a tam se zkusit připojit.
-
PMV: Restart routeru jsem zkoušel, ale nepomohl.
LuciusMare: Dříve než jsem stihl nabootovat Fedoru Live, internet opět bez jakéhokoli mého zásahu začal fungovat (po 2 dnech nefunkčnosti). Jinak funkční připojení přes Windows probíhalo přes jiné počítače, sám dual-boot nemám.
Každopádně opět nevím, jak to řešit, nastane-li výpadek znova... :-\
-
Easy až ti to zas slítne zkus na tom tvym kompu nastartovat třeba XPčka a hned budeš vědět :). To je asi nejprimitivnější řešení, určitě tu někdo vymyslí něco lepšího. Jinak mě napadlo, co takhle zkusit jinou sítovku něco nového třebas nějaký Linksys :).
-
Jo jsou i neofiko livka Windows.
-
LuciusMare: Vzpomeňme na problémy Vist s různými WiFi AP s 2.4 kernelem.
Opravdu bych ještě zkusil upgrade FW na tom routeru - nic se tím nezkazí a případně vyloučí se router úplně. Je mi divné, že se dostane na router (pinguje ho, přistupuje na něj) ale nedostane se za něj (a to ani pingem s malým paketem). Chyba šifrování je tedy vyloučená, rovněž chyba vynucené fragmentace (sice by nejel web, ale jel by ping i s relativně velkým paketem).
Ještě bych zkusil nabootovat z LiveCD buntu a připojit se z něj, zda bude či nebude problém.
-
Ahoj,
tak tenhle problém tu už chvíly řeším, zatím bez většího úspěchu. AP je Edimax chová se podobně co se ping, web stránek a pod. týká. Mám odzkoušeno na NB HP500 Ubuntu 10.4 tam chodí v pohodě, na Lenovo sl510 Ubuntu 9.10 64bit vidím AP a dál ne /do sítě/ na N900 s Maemem jsem na tom stejně jako s Lenovem. Po první takovéto reakci na připojení jsem ho zkusil schodil na default a žádná změna, tak jsem ho vyměnil za stejný kus a jediné co se stalo je, že si to HP s Lenovem prohodili. :)
Jinak všechny zařízení se mi v pohodě připojí na vedlejší AP.
Zkoušel jsem místo AP připojit na kabel natvrdo NB /Lenovo/ a ten se v pohodě dál do sítě dostal. Zatím si myslím, že by to mohla být chyba "asi" ovladače verzus AP, ale to jen hádám.
-
Zkuste na to LiveCD verze 9.04.
-
Ahoj,
měl jsem podobný problém a celé to řešilo výměnou routeru za modemem, který přiřazoval DNS.
Mě to dokonce sem tam prohodilo notebooky, jednou se připojil jeden podruhé druhý. :D
-
Mohu potvrdit, jedna z možností je výměna routru, v mém případě to byl ADSL modem ASUS TI4601. Absence novějšího firmwaru od výrobce znamená, že je na vyhození, pokud nenastavím hodnoty ručně.