Forum Turris
Fórum Turris Nápověda

Milí majitelé routerů Turris,

toto fórum bylo 9. 12. 2016 zmrazeno a nahrazeno naším novým Turris fórem. Ještě chvíli bude dostupné k prohlížení, ale již zde není možné přispívat. Více informací naleznete v oznámení o uzavření fóra.

Dear Turris routers users,

this forum has been frozen on Dec 9th, 2016 and replaced by our new Turris forum. It will be read-only accessible for some time after. For more information, read the announcement about closing the forum.

Nahoru Téma Majitelé routerů / Technická podpora / Pomalé připojení přes router Turris
- - Od ardee Dne 2014-03-23 12:54
Rád bych poproil o radu.
Zapojil jsem Turris, nastavil, nakonfiguroval WIFI.
Bohužel se téměř nedá dívat na jakákoliv videa (youtube apod.) Je to velmi pomalé a nebo se nastaví minimální kvalita videa.
Mám připojení od UPC 10Mbit/1Mbit (Download/Upload). Testoval jsem s jedním připojeným klientem na DHCP přes Wifi.
Při měření rychlosti na adsl.cz, dsl.cz, rychlost.cz jsou výsledky velmi rozporuplné a kolísavé. Někdy naměří download jen 250Kbit/s.
Pokud zapojím svůj starší TP-Llink s DD-WRT vše naprosto bez problémů.

Nějaké tipy co dělat?

Díky
Nadřazený - Od Jan Čermák (>>) Dne 2014-03-23 18:02
Nejprve bych se pokusil identifikovat zdroj problému. Dělá to i při připojení kabelem do routeru? Pokud ne, projevuje se stejné chování i u jiných klientů? Z mojí zkušenosti můžu říct, že se mi občas stávalo, že si spolu některé Wi-Fi zařízení nechtěly povídat. Z toho důvodu šel z domu například nějaký levný Zyxel, který namísto teoretických 150 Mbit/s fungoval s Intel kartou v notebooku spíš na 150 kbit/s.
Nadřazený - - Od Bedřich Košata Dne 2014-03-26 12:49
Podařilo se Vám vyzkoušet propustnost i přes kabel? Byla tam nějaká změna?
Nadřazený - - Od ardee Dne 2014-03-26 17:15
Ano vyzkousel jsem i kabelove pripojeni. I na kabelu se projevoval stejny problem (jak LAN1 tak i ostatni porty). Lze tedy vyloucit problem s nekompatibilitou WiFi.

Na druhy den jsem Turris vyresetoval - probehlo nekolik updatu a je po problemu.
Bohuzel tedy nejsem schopen presne urcit pricinu. Prozatim je vse v poradku.

Pokud se problem objevi znovu upozornim na nej a pokusim se hledat duvod.
Nadřazený - - Od Bedřich Košata Dne 2014-03-28 09:13
Díky za informaci. Nejsem si vědom, že bychom v aktualizaci opravovali něco, co by mohlo toto vysvětlovat, tak uvidíme, jak se to bude chovat do budoucna. Pokud by se situace opakovala, dejte nám určitě vědět.
Nadřazený - Od ardee Dne 2014-03-28 09:54
Včera se objevil problém znovu.
Zkusil jsem PING na router a docházelo k vypadkům přes WIFI.
Nastavil jsem wifi na 802.11b a pomohlo to....
Je tedy pravděpodobné, že jeden z klientů byl nekompatibilní s 802.11g+n.
Nadřazený - - Od lukasberan Dne 2014-04-09 17:20
Vyzkoušej připojení kabelem. Připojení přes WiFi není moc relevantní informace, protože v závislosti na mnoha dalších okolnostech se může chovat různě. A 40 MHz může být hlavně v alespoň trochu zarušeném okolí spíš problematické. Pokud to z nějakého důvodu není nezbytně nutné, vždy doporučuji nastavovat šířku pásma na 20 MHz už z důvodu ohleduplnosti, ale také kvůli zmíněným problémům.
Nadřazený - - Od ardee Dne 2014-04-23 19:32
Zdravím,

Po dlouhem trápení jsem udělal několik testů. Zkusil jsem dokonce i namontovat další Atheros do volného portu. Nicméně ani hraní s kanály, frekvencemi nepomoho.
Nezbylo než si sehnat síťovku do USB portu a testovat...

Pokud udělám ping na www.google.com, jsou ztráty na spojení (viz níže). Zapojím-li kabel přímo do modemu UPC, vše bez problémů. Pokuď dělám ping na router , vše bez problémů.
Testoval jsem tak , že jsem měl zapojen pouze svůj notebook a žádné jiné zařízení nebylo připojeno. Pro jistotu jsem otestoval i po resetu routeru a výsledek stejný

64 bytes from 173.194.39.115: icmp_seq=2512 ttl=56 time=18.705 ms
Request timeout for icmp_seq 2513
64 bytes from 173.194.39.115: icmp_seq=2514 ttl=56 time=21.190 ms
64 bytes from 173.194.39.115: icmp_seq=2515 ttl=56 time=20.749 ms
64 bytes from 173.194.39.115: icmp_seq=2516 ttl=56 time=19.218 ms
Request timeout for icmp_seq 2517
Request timeout for icmp_seq 2518
64 bytes from 173.194.39.115: icmp_seq=2519 ttl=56 time=21.538 ms
64 bytes from 173.194.39.115: icmp_seq=2520 ttl=56 time=20.359 ms
Request timeout for icmp_seq 2521
64 bytes from 173.194.39.115: icmp_seq=2522 ttl=56 time=18.740 ms
64 bytes from 173.194.39.115: icmp_seq=2523 ttl=56 time=18.758 ms
64 bytes from 173.194.39.115: icmp_seq=2524 ttl=56 time=18.875 ms
64 bytes from 173.194.39.115: icmp_seq=2525 ttl=56 time=19.589 ms
64 bytes from 173.194.39.115: icmp_seq=2526 ttl=56 time=19.177 ms
64 bytes from 173.194.39.115: icmp_seq=2527 ttl=56 time=21.164 ms

--- www.google.com ping statistics ---
2677 packets transmitted, 2382 packets received, 11.0% packet loss
round-trip min/avg/max/stddev = 18.054/20.872/880.676/17.716 ms

Zaujal mě také traceroute v porovnáním s IP adresami na WAN rozhraní. Ve výpisu nevidím gateway UPC jaká je nastavena na WAN rozhraní DHCP clientem?

traceroute to www.google.com (173.194.39.113), 64 hops max, 52 byte packets
1  192.168.13.1 (192.168.13.1)  0.427 ms  0.190 ms  0.147 ms
2  * * *
3  static-84-242-127-1.net.upcbroadband.cz (84.242.127.1)  10.060 ms  10.891 ms  16.698 ms
4  cz-prg01a-ra4-vla2109.net.upc.cz (84.116.221.37)  10.935 ms  35.853 ms  59.389 ms
5  213.46.180.14 (213.46.180.14)  18.399 ms
    213.46.180.18 (213.46.180.18)  20.418 ms
    cz-prg02a-ra2-xe-2-1-0.aorta.net (213.46.172.218)  21.610 ms
6  213.46.172.210 (213.46.172.210)  21.797 ms  13.232 ms  11.885 ms
7  64.233.175.212 (64.233.175.212)  18.699 ms  40.861 ms  20.772 ms
8  72.14.234.255 (72.14.234.255)  38.233 ms  28.195 ms  28.200 ms
9  bud02s02-in-f17.1e100.net (173.194.39.113)  27.724 ms  19.564 ms  29.476 ms

WAN:
Gateway: 89.103.121.1
DNS 1: 213.46.172.37
DNS 2: 213.46.172.36
Connected: 0h 47m 24s

Díky za jakoukoliv pomoc....
Nadřazený - - Od Michal Vaner (>>) Dne 2014-04-24 09:43
Dobrý den

Asi nemám řešení, ale pár pozorování bych měl.

Jednak, to, že se nezobrazuje ta gateway, to může být prostě jen proto, že není ochotná odpovídat na pingy. Mě to na domácím UPC připojení dělá také. Je to sice porušení standardu ze strany té gateway, ale prakticky to ničemu nevadí.

Ty ztráty jsou podezřelé. Nějakou dobu jsem něco takového vídával na jednom prototypu, ale to časem vymizelo a nepodařilo se zjistit, čím to bylo způsobené. Zkusím s ostatními probrat jednu teorii, jak moc je mimo.

Každopádně, ztrátovost asi nebude příčina pomalého připojení. Ztrátovost asi až do 30% by neměla být výrazně poznat, s tím by si TCP mělo bez větších problémů poradit. Leda by někdy nastávala ta ztrátovost výrazně vyšší. Je to tak pomalé vždy, nebo jen někdy?
Nadřazený - Od ardee Dne 2014-04-24 13:01
Napadla me jeste jedna moznost testu. Vyrobim si klice a pripojim se na router pres ssh a zkusim ping primo z routeru jak na google.com tak na 8.8.8.8 (vynechani DNS)

Obavam se, ze ztratovost 11% je pouze pokud nejsou zapojena jina zarizeni , jakmile bude vice pripojenych zarizeni na LAN rozhrani a vice pozadavku ven, zvysi se podle me i ztratovost a zacne se to projevovat lagovanim pri otevirani stranek... (nemam overeno empiricky)
Je to pomale nahodile, nicmene napriklad pri zapnuti skype a komunikaci se internet proste nekdy neda pouzivat... Z 10Mbit linky namerim v urcitych okamzicich jen 200Kbit a to uz neukousne jen skype...navic na grafech neni videt datovy tok v takove vysi.
Nadřazený - Od ardee Dne 2014-04-24 20:35
Udelal jsem par dalsich testu a zde je zaver:

- ping s routeru na www.google.com --> 0% ztrata
- pong ze zarizeni na LAN na www.google.com --- ztrata 4.6%

Domnival jsem se , ze je problem na kabelazi nebo sitove karte tak jsem jeste udelal ping ze zarizeni v LAN na router:

- ping na router z LAN --> 0% ztrata
(bez ohledu na jaky interface LAN je zapojen)

Je videt zlepseni oproti vcerejsku , ale nejsem schopen prokazat zda to ma na svedomi update nebo ne.

Jinymy sloby "Something is wrong inside the black box"....
Nejaka rada jake tesy jeste provest?
Nadřazený - Od Michael Macek Dne 2014-04-25 10:44
TCP je _velice_ citlive na ztratovost, i velmi mala zpusobi vyrazne snizeni propustosti TCP v porovnani s kapacitou pripojky.
- Od JF Dne 2014-04-07 17:25
Pripojenie mám tiež cez UPC 240Mbps/20Mbps a behá to naprosto v poriadku. WiFi pásmo som nastavil na 40MHz a lieta to v pohode. Na mojom noťase pripojenie rýchlosťou 150Mbps, u manželky až 300Mbps, cez LAN 1Gbps.
- - Od Yarda_cz Dne 2014-05-16 19:51 Upraveno 2014-05-16 20:39
Zdravím, dnes jsem router zapojil, nastavil základní nastavení. Wifi mám na 2,4GHz na N-ku, připojení od UPC 60/6 Mbit. Se "starým" routerem mi to běhalo přesně 60/6, nyní s Turrisem 1/6 :eek:. Nevíte, kde je zakopaný pes? Přes kabel to jede stejně pomalu.

Tak oprava, po resetu kabelového modemu po kabelu vše jede ok, problém s wifi stále trvá.
Nadřazený - - Od NONES (>>>) Dne 2014-05-16 20:14
Hmm, to je zvláštní. Já jedu po kabelu 40/4. Čím to měříte?
Nadřazený - Od Yarda_cz Dne 2014-05-16 20:39
speedtest na server UPC
- - Od Yarda_cz Dne 2014-05-16 21:49
Tak jsem polaboroval s kanály. Výsledek je, že na kanálech 1-4 jedu obstojně až 50Mbit, na zbytku od 0,2 do 1Mbit. Je možný takovýto rozdíl?? :eek:
Nadřazený - - Od Michal Vaner (>>) Dne 2014-05-20 10:27
Není možné, že ty ostatní kanály něco ruší?
Nadřazený - Od Yarda_cz Dne 2014-05-20 21:39
Nemám představu co. S předchozím D-Linkem DIR 600 jsem neměl problém na žádném kanálu.
- - Od petr-miler.moje Dne 2014-05-18 01:18
Ve čtvrtek jsem zapojil Turris.Nastavení jsem nijak nemodifikoval, pouze jsem si nastavil DHCP na rozsah 10.0.0.0/24
Připojení mám od O2, modem Zyxel Prestige 660H-T3.

Od té doby mám problém hrát onlinovku C&C. Seká se a stále mě odpojuje od serveru.
Dělá to Chrome, FF i IE.

Zkusil jsem si odchytat, co se děje.
V okamžiku požadavku na obsah se objeví plno takových záznamů.
2295  12.213721000  10.0.0.215  23.63.85.109  TLSv1.2  699  [TCP Retransmission] Application Data
2303  12.244561000  23.42.27.27  10.0.0.215  HTTP  341  [TCP Retransmission] HTTP/1.1 304 Not Modified
2304  12.244736000  10.0.0.215  23.42.27.27  TCP  66  [TCP Dup ACK 2296#1] 51640 > http [ACK] Seq=560 Ack=2145 Win=66304 Len=0 SLE=1858 SRE=2145

Tak jsem zkusil i normální web - zive.cz
755  18.517555000  5.198.129.128  10.0.0.215  HTTP  1506  [TCP Retransmission] Continuation or non-HTTP traffic
756  18.517666000  10.0.0.215  5.198.129.128  TCP  66  [TCP Dup ACK 754#1] 52063 > http [ACK] Seq=1 Ack=10250 Win=62720 Len=0 SLE=2905 SRE=4357
757  18.520172000  5.198.129.128  10.0.0.215  HTTP  1506  [TCP Retransmission] Continuation or non-HTTP traffic
758  18.520271000  10.0.0.215  5.198.129.128  TCP  66  [TCP Dup ACK 754#2] 52063 > http [ACK] Seq=1 Ack=10250 Win=62720 Len=0 SLE=4357 SRE=5809

A taky www.nic.cz
982  24.704231000  217.31.204.120  10.0.0.215  HTTP  693  [TCP Retransmission] HTTP/1.1 200 OK  (PNG)
983  24.704370000  10.0.0.215  217.31.204.120  TCP  66  [TCP Dup ACK 980#1] 52133 > http [ACK] Seq=1676 Ack=10868 Win=65280 Len=0 SLE=10229 SRE=10868
997  26.813955000  10.0.0.215  217.31.204.120  HTTP  498  [TCP Retransmission] GET /ipv6widget/img-cznic/status-new-ajax-loader.gif HTTP/1.1

Takovou ztrátovost paketů jsem neměl. Pokud to v brzké době nevyřeším, tak je to nepoužitelné.
Dokáže mi někdo poradit jak snížit tu ztrátovost ?
Nadřazený - - Od petr-miler.moje Dne 2014-05-18 20:56
Tak jsem odpojil Turris a linku zapojil jako standardní xDSL - router.
Pokles výše uvedených ztracených paketů je razantní. Nedělal jsem statistiku, ale odhaduji, že teď je toho tak 5-10% původního množství.

Minule jsem zapoměl napsat, že to jedu přes kabel a ne přes wifi.
Nadřazený - - Od lzita (>) Dne 2014-05-18 23:53
Rozumím tomu správně, že jste nejprve ADSL router měl nejdříve jako ATM Bridge a Turris sám "vytáčel" ADSL připojení  a v této konfiguraci to nefungovalo dobře, takže jste ADSL router zapojil klasicky a Turrise dal až za NAT a to fungovalo dobře ?
Nadřazený - - Od petr-miler.moje Dne 2014-05-19 08:03
xDSL router jsem zapojil klasicky, ale Turris jsem již nezapojil.
Nadřazený - - Od lzita (>) Dne 2014-05-19 08:59
Já jsem se pral s nepřenášením statistik a pomohlo právě přepnutí ADSL routeru z Bridge módu do "normálního" s tím , že jsem v ADSL routeru nastavil pro IP Turrisu DMZ zónu. Není to z hlediska budoucnosti ideální, a proto bych to chtěl dále řešit. Protože nemám jiný ADSL modem nejsem schopen analyzovat zda je chyba v méme ADSL modemu nebo v Turrisu. Pomohlo by mi kdybyste udělal to samé a řekl zda zpoždění je způsobeno výhradně Turrisem, nebo tím "bridge" módem.
Nadřazený - - Od petr-miler.moje Dne 2014-05-19 09:24 Upraveno 2014-05-19 20:53
Tak jsem to zapojil. Na Turris jsem nasměřoval celý příchozí provoz.
Ztrátovost paketů na mém kompu je OK.
Takto by Turris jako sonda mohl být zapojen, ale takové zapojení asi nebylo smyslem, ne ?
Nadřazený - - Od lzita (>) Dne 2014-05-19 22:24
Děkuji mnohokrát za ochotu. Ještě se zeptám (jestli to není tajné) na Vašeho poskytovatele a typ ADSL routeru.
Já mám poskytovatele O2 a router je Draytek Vigor 2600VG.
Nadřazený - - Od petr-miler.moje Dne 2014-05-20 00:20
Psal jsem to už na začátku :smile:
Připojení mám od O2, modem Zyxel Prestige 660H-T3, down 4,35M - up 320M
O ochotu nejde, spíš co s tím ?
Nadřazený - Od lzita (>) Dne 2014-05-20 09:10 Upraveno 2014-05-20 09:22
Jsem domluvený s panem Vanerem, že mi v pátek zapůjčí nějaký jejich modem jiného typu a budem na tom pracovat. Ještě mne napadá, otestovat jiný obyčejný NeADSL router který zapojit jako Turrise a tak určit kde je chyba.
Vzhledem k cíli projektu jsem přesvědčený, že se to vyřeší.
Do té doby holt asi bude cz.nic muset akceptovat toto schema zapojení.
Nahoru Téma Majitelé routerů / Technická podpora / Pomalé připojení přes router Turris

Powered by mwForum 2.29.3 © 1999-2013 Markus Wichitill