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 / Zdržování při instalaci balíků z cznic
- - Od ryucz Dne 2014-05-09 08:51
Zdravím, pokud instaluji balíky přímo z repositáře CZNIC tak opkg 2 min a 7 sec stojí a nic nedělá a pak teprve balík nainstaluje. čas je vždy stejný, liší se max o vteřinu.

Pokud instaluji přímo z repositáře openwrt tak se zpoždění neprojeví. Ví někdo čím by to mohlo být?
Nadřazený - - Od Ondřej Caletka (>>>) Dne 2014-05-09 17:33
Vypadá to, že váš Turris má pocit, že má k dispozici IPv6 připojení, ale to ve skutečnosti nefunguje. Po dvou minutách se vyzkouší cesta přes IPv4, která projde. Repozitáře OpenWRT IPv6 adresu nemají, takže se tam problém neprojevuje.

Chcete-li, pošlete výstup příkazů ip a a ip -6 rou. Třeba z toho zjistíme, odkud se vám ta nefunkční IPv6 bere.
Nadřazený - Od ryucz Dne 2014-05-09 17:59
Děkuji, to bylo přesně ono.
Nadřazený - - Od sakulisko Dne 2014-07-08 22:41
Zdravím, právě řeším to samé. Stahování balíčků trvá okolo 2 minut, ping6 nebezi.cz funguje. Snažil jsem se s tím i trochu hrát, ale nic mě nenapadá.

Výpisy příkazů jsou zde 
root@turris:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP group default qlen 1000
    link/ether d8:58:d7:00:01:38 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP group default qlen 1000
    link/ether d8:58:d7:00:01:39 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether d8:58:d7:00:01:3a brd ff:ff:ff:ff:ff:ff
    inet 10.18.2.8/26 brd 10.18.2.63 scope global eth2
       valid_lft forever preferred_lft forever
    inet6 2001:67c:2190:5080:0:ffff:a12:208/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::da58:d7ff:fe00:13a/64 scope link 
       valid_lft forever preferred_lft forever
5: ip6tnl0: <NOARP> mtu 1452 qdisc noop state DOWN group default 
    link/tunnel6 :: brd ::
6: sit0: <NOARP> mtu 1480 qdisc noop state DOWN group default 
    link/sit 0.0.0.0 brd 0.0.0.0
7: gre0: <NOARP> mtu 1476 qdisc noop state DOWN group default 
    link/gre 0.0.0.0 brd 0.0.0.0
8: gretap0: <BROADCAST,MULTICAST> mtu 1476 qdisc noop state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
9: teql0: <NOARP> mtu 1500 qdisc noop state DOWN group default qlen 100
    link/void 
13: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none 
23: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether d8:58:d7:00:01:38 brd ff:ff:ff:ff:ff:ff
    inet 10.23.0.2/24 brd 10.23.0.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 2001:67c:2190:5081::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::da58:d7ff:fe00:138/64 scope link 
       valid_lft forever preferred_lft forever
24: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP group default qlen 1000
    link/ether 60:02:b4:7d:86:46 brd ff:ff:ff:ff:ff:ff


root@turris:~# ip -6 rou
2001:67c:2190:5080::/64 dev eth2  proto kernel  metric 256 
2001:67c:2190:5081::/64 dev br-lan  proto kernel  metric 256 
unreachable 2001:67c:2190:5081::/64 dev lo  proto static  metric 2147483647  error -101
fe80::/64 dev br-lan  proto kernel  metric 256 
fe80::/64 dev eth2  proto kernel  metric 256
Nadřazený - - Od Ondřej Caletka (>>>) Dne 2014-07-09 08:41
To vypadá dobře. Když dáte ping6 api.turris.cz, funguje to? Pokud ne, zkuste traceroute. Možná to je nějaká úplně jiná závada.
Nadřazený - - Od sakulisko Dne 2014-07-09 13:49
Ping funguje. První chvilku trval, ale to předpokládám způsobuje DNSSEC. Pro jistotu rovnou přikládám traceroute. 
turris ~ # traceroute6 api.turris.cz
traceroute to api.turris.cz (2001:1488:ac15:ff80::101) from 2001:67c:2190:5080:10:18:2:8, 30 hops max, 16 byte packets
 1  vlan1518-router.winel.czf-de.spoje.net (2001:67c:2190:5080::1)  7.668 ms  5.681 ms  5.431 ms
 2  triangulum.czf-br.spoje.net (2001:67c:2190:ffff::b09)  5.358 ms  6.468 ms  5.747 ms
 3  vlan10-router.veskrini.czf-br.spoje.net (2001:67c:2190:1040::1)  5.469 ms  5.882 ms  4.3 ms
 4  eth0-router.prometheus.spoje.net (2001:67c:2190:ffff::100d)  5.779 ms  5.237 ms  7.5 ms
 5  vlan11-router.natwor.spoje.net (2001:67c:2190:ffff::1009)  8.071 ms  6.637 ms  5.739 ms
 6  vlan770-router.argo.spoje.net (2001:67c:2190:ffff::1001)  5.818 ms  6.05 ms  3.902 ms
 7  vl4001-pop2.nfx.cz (2a01:490:0:1::b:1)  6.727 ms  8.455 ms  6.254 ms
 8  * nix4-s-ipv6.nic.cz (2001:7f8:14::e:2)  12.91 ms *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
Nadřazený - - Od Ondřej Caletka (>>>) Dne 2014-07-09 20:30
Ode mě vypadá traceroute velmi podobně, takže bych s IPv6 konektivitou jako takovou zřejmě problém není. Ještě mě napadá, že by to mohl být problém s MTU, ale nevím, jak něco takového snadno vyzkoušet.
Nadřazený - Od hybner Dne 2014-07-10 13:31
Na problem s MTU u IPv6 zkuste tento test: http://ipv6-test.com/pmtud/
Nadřazený - - Od sakulisko Dne 2014-07-17 12:17
Pomůže toto? 
turris ~ # ping6 -M do -s 1462 api.turris.cz
PING api.turris.cz(api.turris.cz) 1462 data bytes
From 2001:67c:2190:5080:10:18:2:8 icmp_seq=1 Packet too big: mtu=1500
From 2001:67c:2190:5080:10:18:2:8 icmp_seq=1 Packet too big: mtu=1500
From 2001:67c:2190:5080:10:18:2:8 icmp_seq=1 Packet too big: mtu=1500
From 2001:67c:2190:5080:10:18:2:8 icmp_seq=1 Packet too big: mtu=1500
From 2001:67c:2190:5080:10:18:2:8 icmp_seq=1 Packet too big: mtu=1500
From 2001:67c:2190:5080:10:18:2:8 icmp_seq=1 Packet too big: mtu=1500
From 2001:67c:2190:5080:10:18:2:8 icmp_seq=1 Packet too big: mtu=1500
From 2001:67c:2190:5080:10:18:2:8 icmp_seq=1 Packet too big: mtu=1500

turris ~ # ping6 -M do -s 1452 api.turris.cz
PING api.turris.cz(api.turris.cz) 1452 data bytes
1460 bytes from api.turris.cz: icmp_seq=1 ttl=55 time=9.65 ms
1460 bytes from api.turris.cz: icmp_seq=2 ttl=55 time=8.18 ms
1460 bytes from api.turris.cz: icmp_seq=3 ttl=55 time=8.31 ms
^C
--- api.turris.cz ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 8.183/8.716/9.656/0.670 ms
Nadřazený - - Od Ondřej Caletka (>>>) Dne 2014-07-17 12:35
To vypadá, že ani s MTU problém nemáte. 1452 je maximální velikost payloadu pro ping na MTU 1500 (8 bytů ICMPv6 a 40 bytů IPv6 hlavička). Jen mě trochu zaráží ta adresa 2001:67c:2190:5080:10:18:2:8. Podle mě by to měla být vaše WAN adresa, tedy 2001:67c:2190:5080:0:ffff:a12:208. Je možné, že jde o chybu v busyboxu a ve skutečnosti měla být adresa zapsána takto: 2001:67c:2190:5080:0:ffff:10.18.2.8, což je jen jiný zápis téže adresy.
Nadřazený - - Od commar (>>) Dne 2014-07-17 13:36
Co je parametr -M, zkouším to po vás, ať máte data pro porovnání a na ping6 -M do -s 1462 api.turris.cz
dostanu chybu:
root@turris:~# ping6 -M do -s 1462 api.turris.cz
ping6: invalid option -- M
Nadřazený - - Od David K. Dne 2014-07-17 13:57
-M hint
Select Path MTU Discovery strategy. hint may be either do (prohibit fragmentation, even local one), want (do PMTU discovery, fragment locally when packet size is large), or dont (do not set DF flag)
Nadřazený - Od commar (>>) Dne 2014-07-17 14:11
No tak hned je mi to jasnější... :grin:
To jsem si našel také, viz: http://www.manpager.com/linux/man8/ping6.8.html

ale proč můj Turris vyhazuje chybu a jiným ne?
Nadřazený - - Od jakub.rybar Dne 2014-08-07 13:10 Upraveno 2014-08-07 13:13
Neupgraduje se zase server? V prohlížeči https://api.turris.cz/openwrt-repo/turris/packages/ můžu normálně procházet, Turris ale čeká na odpověď při puštěném opkg update a nedařilo se mu dlouho stáhnout soubor "Packages.gz". Nakonec se zadařilo, instalace balíčku ale čeká na response.

viz root@turris:~$ opkg install php5-cgi
Installing php5-cgi (5.4.23-1) to root...
Downloading https://api.turris.cz/openwrt-repo/turris/packages//php5-cgi_5.4.23-1_mpc85xx.ipk.
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1093k  100 1093k    0     0   8773      0  0:02:07  0:02:07 --:--:--  313k
Installing php5 (5.4.23-1) to root...
Downloading https://api.turris.cz/openwrt-repo/turris/packages//php5_5.4.23-1_mpc85xx.ipk.
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  4081  100  4081    0     0     32      0  0:02:07  0:02:07 --:--:--   970
Nadřazený - - Od jakub.rybar Dne 2014-08-07 13:12
Tak to jede a trvá přesně 2 minuty 7 sekund, tj. 127 sekund než se opkg aktualizuje, resp. než se začne balík stahovat. Proč je tam ta delay? Může to mít co do činění s mojí konektivitou?
Nadřazený - Od Jan Čermák (>>) Dne 2014-08-07 13:15
Nevím, jestli bylo zrovna šťastné zařadit to do tohoto tématu, ten titulek mě osobně tedy dost zmátl... Nicméně, řešení Vašeho problému bych viděl stejné jako tady: https://www.turris.cz/forum/topic_show.pl?pid=1262

Váš příspěvek obratem přesunu do odkazovaného tématu.
Nadřazený - - Od jakub.rybar Dne 2014-08-07 14:27
ping6 OK, traceroute6 končí na nix4-s-ipv6.nic.cz .
Nadřazený - - Od Ondřej Caletka (>>>) Dne 2014-08-07 14:35
To je asi v pořádku. Ještě může být problém s MTU. Zkus na Turrisu tyhle dva příkazy:
curl https://api.turris.cz/openwrt-repo/turris/medkit/ > /dev/null
curl https://api.turris.cz/openwrt-repo/turris/packages/ > /dev/null

Pokud se první stáhne hned a druhý trvá, je možné, že má IPv6 přípojka někde úzké hrdlo a někdo (doufám, že ne firewall u CZ.NIC) blokuje ICMPv6 zprávy o zahození příliš velkého paketu.
Nadřazený - - Od jakub.rybar Dne 2014-08-07 14:39
Oba příkazy čekají shodně 127 sec. Viděl bych to na problém v routování, ale nevím, jak to ověřit.
Nadřazený - - Od Ondřej Caletka (>>>) Dne 2014-08-07 14:58
Aha, takový test zřejmě nebude fungovat, protože velké pakety se přenášejí už během SSL handshake. Zkusil bych dočasně snížit MTU na WAN rozhraní, jestli to nepomůže:
# ip link set dev eth2 mtu 1300
Nadřazený - Od jakub.rybar Dne 2014-08-07 15:03
Bohužel. :( Pokud je to obecný problém u lidí s nativní i tunelovanou IPv6 konektivitou, pak to většina asi neřeší nebo jim těch 127 sec. nevadí. :) Zkusím se k tomu vrátit ještě později.
Nadřazený - - Od jakub.rybar Dne 2014-08-08 20:30 Upraveno 2014-08-12 21:04
Tak je to hodně zvláštní. traceroute6 dohěhne z PC až do CZ.NICu, z Turrisu ale nikoliv - a delaye u instalovaných balíčků zůstávají. Když člověk resetuje Turrise do továrního nastavení a pak jej znova oživuje, z práce na 15 minut jsou najednou 2 hodiny, a to je hodně otravné. Nemohl by mi někdo, kdo vidí do logů pro api.turris.cz říct, s čím má můj Turris (IPv6 adresa: 2001:67C:2190:1503:0:0:0:1/64) problém?

C:\Users\jakub.rybar>tracert api.turris.cz

Výpis trasy k api.turris.cz [2001:1488:ac15:ff80::101]
s nejvýše 30 směrováními:

  1    < 1 ms     1 ms    < 1 ms  2001:67c:2190:yyyy::1]
  2    < 1 ms    < 1 ms    < 1 ms  vlan635-router.pisces.czf-br-spoje.net [2001:67c:2190:1500::1]
  3    < 1 ms    < 1 ms    < 1 ms  dilna-bar.czf-br.spoje.net [2001:67c:2190:1020::1]
  4     1 ms    < 1 ms     1 ms  eth0-router.prometheus.spoje.net [2001:67c:2190:ffff::100d]
  5     1 ms     1 ms     2 ms  vlan11-router.natwor.spoje.net [2001:67c:2190:ffff::1009]
  6     1 ms     1 ms     1 ms  vlan770-router.argo.spoje.net [2001:67c:2190:ffff::1001]
  7     2 ms     2 ms     2 ms  vl4001-pop2.nfx.cz [2a01:490:0:1::b:1]
  8     *        *        2 ms  nix4-s-ipv6.nic.cz [2001:7f8:14::e:2]
  9     2 ms     2 ms     2 ms  2001:1488:d91f:c000::251
10     2 ms     2 ms     2 ms  api.turris.cz [2001:1488:ac15:ff80::101]

Trasování bylo dokončeno.

C:\Users\jakub.rybar>
Nadřazený - - Od sakulisko Dne 2014-08-08 20:39 Hlasů 1
Zdravím, taky jsem to zatím nevyřešil. Velmi mě, ale zaujala cesta od vás k cz.nic. Z velké části se shoduje s tou mou. ISP je spoje.net nevím, jestli to může mít spojitost.
Nadřazený - Od jakub.rybar Dne 2014-08-08 22:38
Jojo, jsem čerstvě přestěhovaný na Břevnov s konektivitou do/od spoje.net. :)
Nadřazený - - Od milanroubal (>) Dne 2014-08-10 18:42
no rozdil je jasny, zatimco turris pouziva UDP traceroute6, windows pouzivaji ICMPv6 tracert. Z linuxoveho boxu se da spustit traceroute6 s parametrem -I, ktery se pak dostane az tam, kam je treba. Mozna by stalo za to spustit z nejakeho linuxoveho boxu
traceroute6 -I --mtu api.turris.cz
muj vystup
# traceroute6 -I --mtu api.turris.cz
traceroute to api.turris.cz (2001:1488:ac15:ff80::101), 30 hops max, 65000 byte packets
1  2a01:198:yyyy::1 (2a01:198:yyyy::1)  0.779 ms F=1500  0.820 ms  0.327 ms
2  gw-2253.dus-01.de.sixxs.net (2a01:198:200:xxxx::1)  8.496 ms F=1280  8.839 ms  8.704 ms
3  * * *
4  * * *
5  as6939.dus.ipv6.ecix.net (2001:7f8:8::1b1b:0:1)  19.934 ms  24.091 ms  24.848 ms
6  10ge1-1.core1.prg1.he.net (2001:470:0:213::2)  21.442 ms  21.095 ms  21.742 ms
7  * nix4-s-ipv6.nic.cz (2001:7f8:14::e:2)  20.970 ms *
8  2001:1488:d91f:c000::251 (2001:1488:d91f:c000::251)  20.490 ms  22.259 ms  21.350 ms
9  api.turris.cz (2001:1488:ac15:ff80::101)  21.340 ms  21.554 ms  20.200 ms

kde je videt, ze MTU v moji vnitrni siti je 1500 a pro cestu ven se zmensuje na 1280.
Nadřazený - - Od jakub.rybar Dne 2014-08-12 21:04
Dobre, ICMPv6 dobehne. Cekal jsem, ze se opravdu chytne nekdo z Turris tymu, protoze mi toto prijde jako zavazny bug. Pokud neodstranime pricinu, proc je tam ta delay? Jake je jeji opodstatneni? Mas IPv6 konektivitu, OK, wget... Nic do 5 vterin? Zkus IPv4, OK, vyreseno. :smile:

traceroute to api.turris.cz (2001:1488:ac15:ff80::101), 30 hops max, 65000 byte packets
1  2001:67c:2190:yyyy::1  0.415 ms F=1500  0.377 ms  0.403 ms
2  vlan635-router.pisces.czf-br-spoje.net (2001:67c:2190:1500::1)  1.594 ms  1.433 ms  1.544 ms
3  dilna-bar.czf-br.spoje.net (2001:67c:2190:1020::1)  1.830 ms  1.608 ms  1.897 ms
4  eth0-router.prometheus.spoje.net (2001:67c:2190:ffff::100d)  2.012 ms  1.985 ms  2.055 ms
5  vlan11-router.natwor.spoje.net (2001:67c:2190:ffff::1009)  2.354 ms  2.151 ms  1.978 ms
6  vlan770-router.argo.spoje.net (2001:67c:2190:ffff::1001)  3.125 ms  2.767 ms  3.287 ms
7  vl4001-pop2.nfx.cz (2a01:490:0:1::b:1)  3.714 ms  3.877 ms  3.746 ms
8  * 2001:7f8:14::e:2 (2001:7f8:14::e:2)  4.391 ms *
9  2001:1488:d91f:c000::251 (2001:1488:d91f:c000::251)  4.755 ms  4.076 ms  3.941 ms
10  api.turris.cz (2001:1488:ac15:ff80::101)  3.790 ms  4.149 ms  3.789 ms
Nadřazený - - Od Ondřej Caletka (>>>) Dne 2014-08-13 09:49
To bohužel není tak jednoduché. Bylo by potřeba patchovat curl, aby dostal podporu happy eyeballs. Spíš bych se snažil najít a odstranit příčinu problému, než vytvářet složitá obcházení.

Zkuste zaznamenat inkriminovaný provoz, třeba se nějak pohneme. Nejsem si totiž stále jist, jestli je problém v tom, že se spojení po IPv6 vůbec nenaváže, nebo v tom, že spojení se otevře, ale data netečou.
Doporučuji tento postup:


root@turris:~# tcpdump -npi eth2 -s0 -w /tmp/dump.pcap  host api.turris.cz &
root@turris:~# curl http://api.turris.cz/updater-repo/ > /dev/null
root@turris:~# curl https://api.turris.cz/updater-repo/ > /dev/null
root@turris:~# kill %1


Nechte prosím oba curly doběhnout a následně pak prosím nějakým způsobem vystavte soubor /tmp/dump.pcap, ať se můžeme podívat, kde přesně dojde ke zdržení.
Nadřazený - Od sakulisko Dne 2014-08-13 13:26
Tak bych tipnul, že se spojení vůbec nenaváže. Dump je zde: http://77.87.243.151/dump.pcap
Nadřazený - - Od jakub.rybar Dne 2014-08-13 13:30
Posílám v kvapu dump: http://uloz.to/xuCKWS6z/dump-pcap
Nadřazený - - Od Ondřej Caletka (>>>) Dne 2014-08-13 14:26
Díky oběma. Je to skutečně tak, že spojení se ani nenaváže − na odchozí paket SYN už nepřijde odpověď SYN+ACK. Takže asi není na vině MTU, ale nějaký firewall, za předpokladu, že jiný provoz funguje normálně.

Zkuste prosím, následující CURLy, stačí mi jen informace, jestli se zdržení projevuje, nebo ne:
curl http://cz-prg-as25192.anchors.atlas.ripe.net/2000 >/dev/null
curl http://cz-prg-as2852.anchors.atlas.ripe.net/2000 >/dev/null
curl http://nl-ams-as3333.anchors.atlas.ripe.net/2000 >/dev/null

Pak to asi bude chtít použít tcptraceroute (u mě je to traceroute -6 -T), protože je možné, že je někým filtrován pouze TCP provoz, nikoli ICMP nebo UDP.
Nadřazený - - Od jakub.rybar Dne 2014-08-13 14:41
Curly na atlas.ripe.net běží stejně jako na api.turris.cz, tj. s prodlevou.

traceroute -6 -T api.turris.cz mi nejel, tak jsem na Turrisu nainstaloval balík "tcptraceroute". Po instalaci se mi nedaří spustit TCP traceroute po IPv6, příkaz tcptraceroute 2001:1488:ac15:ff80::101 skončí chybou Bad destination address: x. Příkaz tcptraceroute -6 2001:1488:ac15:ff80::101 končí chybou Unknown command line argument: -6. :cry:
Nadřazený - - Od Ondřej Caletka (>>>) Dne 2014-08-13 15:16
Aha, na Turrisu asi žádný použitelný tcptraceroute pro IPv6 není. Já to zkouším ze svého PC s balíčkem traceroute-nanog. Jestli můžete, zkuste to taky tak.
Nadřazený - - Od sakulisko Dne 2014-08-13 16:28
To se obávám nepomůže, protože problém mám jen z routeru. Z počítače za routerem už curl -6 https://api.turris.cz funguje korektně.
Nadřazený - - Od Ondřej Caletka (>>>) Dne 2014-08-13 16:40
Aha, to by potom naznačovalo, že váš ISP nějakým způsobem blokuje TCP spojení ze spojovací sítě vašeho routeru s jeho routerem. Asi bude nejlepší, když se ho na to zeptáte.

Teoreticky by mohlo jít nějak donutit Turris, aby pro odchozí komunikaci takovou adresu nepreferoval. Zkuste příkaz:

# ip -6 addr change <spojovací prefix> dev eth2 preferred_lft 0

Ale nevím, zda je možné takovou změnu provést trvale.
Nadřazený - Od sakulisko Dne 2014-08-14 09:22
Psal jsem na technickou podporu, kde došli k podobnému závěru. Zatím čekám na řešení.
Nadřazený - Od sakulisko Dne 2014-08-15 10:42 Hlasů 1
Tak vyřešeno. Chybka byla ve firewallu u ISP, konkrétně ve skriptu, který firewall generuje.

Vyjádření od technika spoje.net (Zkopírováno z jabber konverzace)
          "nektere ty propojovaci ipv6 adresy meli spatne prirazenou qos tridu na brane. Vzniklo to nejakym preklepem ve skriptu ktery to nastavuje"

Děkuji všem zúčastněným, kteří pomáhali problém vyřešit.
Nadřazený - Od jakub.rybar Dne 2014-08-18 17:41
Potvrzuji, že v síti spoje.net byl rozebíraný problém vyřešen. Pevně věřím, že byl předmětný skript zabezpečen proti blbuvzdornosti. :twisted:
Nadřazený - Od milanroubal (>) Dne 2014-08-13 13:10
No nic podozreleho, proc by to melo cekat na timeout, videt neni. Asi je potreba se tomu podivat trochu pod kapotu, ja pouzivam toto:
c:\Program Files (x86)\PuTTY>plink.exe -ssh -pw HESLO_TURRIS root@192.168.1.1 "tcpdump -ni eth2 -s 0 -w - not port 22" | "C:\Program Files\Wireshark\Wireshark.exe" -k -i -
To spusti Wireshark a dumpuje to veskery odchozi provoz z routeru, pak spustit na routeru ten pomaly prikaz a podivat se, co to dela/nedela.
Nadřazený - - Od milanroubal (>) Dne 2014-08-07 22:19
jak dostanu traceroute6 na turrise? Prikaz opkg install traceroute6 nainstaluje pouze tracert6 a tam
root@turris:~# tracert6 api.turris.cz
api.turris.cz port 33434: Bad value for ai_flags

IPv6 jinak normalne chodi,
root@turris:~# ping6 api.turris.cz
PING api.turris.cz (2001:1488:ac15:ff80::101): 56 data bytes
64 bytes from 2001:1488:ac15:ff80::101: seq=0 ttl=58 time=26.229 ms
64 bytes from 2001:1488:ac15:ff80::101: seq=1 ttl=58 time=18.332 ms
Nadřazený - - Od jakub.rybar Dne 2014-08-08 07:19
opkg install iputils-traceroute6
Nadřazený - - Od milanroubal (>) Dne 2014-08-08 10:03
diky, funguje. Jinak ja tam zadnou prodlevu nemam, zadne 2 minuty mi to neceka.
Nadřazený - - Od jakub.rybar Dne 2014-08-08 20:21
A můžeš prosím postnout výpis traceroute6 od tebe?
Nadřazený - Od milanroubal (>) Dne 2014-08-08 20:36
traceroute to api.turris.cz (2001:1488:ac15:ff80::101) from 2a01:198:200:xxxx::2, 30 hops max, 16 byte packets
1  gw-xxxx.dus-01.de.sixxs.net (2a01:198:200:xxxx::1)  8.853 ms  8.046 ms  8.598 ms
2  * * *
3  * * *
4  as6939.dus.ipv6.ecix.net (2001:7f8:8::1b1b:0:1)  22.4 ms  17.128 ms  16.758 ms
5  10ge1-1.core1.prg1.he.net (2001:470:0:213::2)  28.019 ms  25.269 ms  19.222 ms
6  * * nix4-s-ipv6.nic.cz (2001:7f8:14::e:2)  19.06 ms
7  * * *
8  * * *
9  * * *
10  * * *
11  * * *
12  * *

root@turris:~# time curl https://api.turris.cz/openwrt-repo/turris/medkit/ > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1009  100  1009    0     0   7848      0 --:--:-- --:--:-- --:--:--  8007
real    0m 0.13s
user    0m 0.02s
sys     0m 0.00s
Nadřazený - Od commar (>>) Dne 2014-08-08 21:21
Posílám i ode mě, ať máte pro porovnání, O2, VDSL...

root@turris:~# traceroute6 api.turris.cz
traceroute to api.turris.cz (2001:1488:ac15:ff80::101) from 2a00:1028:8d1b:a908: e84f:559b:c1d8:7957, 30 hops max, 16 byte packets
1  dynamic-2a00-1028-0017-1e14-0000-0000-0000-0001.ipv6.broadband.iol.cz (2a00:1028:17:1e14::1)  16.601 ms  16.761 ms  16.69 ms
2  dynamic-2a00-1028-0017-1a01-0000-0000-0000-00a1.ipv6.broadband.iol.cz (2a00:1028:17:1a01::a1)  18.423 ms  17.125 ms  17.201 ms
3  dynamic-2a00-1028-0017-00a6-0000-0000-0000-0001.ipv6.broadband.iol.cz (2a00:1028:17:a6::1)  20.469 ms  18.386 ms  18.935 ms
4  nix4-s-ipv6.nic.cz (2001:7f8:14::e:2)  18.199 ms  18.343 ms *
5  * * *
6  * * *
7  * * *
8  * * *
9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * *

root@turris:~# time curl https://api.turris.cz/openwrt-repo/turris/medkit/ > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1009  100  1009    0     0   8003      0 --:--:-- --:--:-- --:--:--  9518
real    0m 0.13s
user    0m 0.02s
sys     0m 0.00s
- Od jakub.rybar Dne 2014-08-08 22:47
Tak jsem zjistil zase jednu drobnost z Forisu: Standardně vypínám forwarding DNS, když pustím test, tak DNS skončí s chybou. Když fwd naopak zapnu, tak je celý test OK. Nicméně jsem při vypnutém fwd nezaznamenal zásadní problémy s nedostupností služeb, tj. nenabyl jsem dojmu, že by DNS pro IPv4 a IPv6 záznamy nefungovalo.

Z výsledků trasování na PC s Win 7 je zřejmé, že server 2001:1488:d91f:c000::251, který nemá PTR záznam, Turrisu už po IPv6ce neodpoví, zatímco mému PC bez problému a pohotově (2 sec.). Ale stále nevím, kam se tady u sebe mám případně vydat hledat problém... :roll:
Nahoru Téma Majitelé routerů / Technická podpora / Zdržování při instalaci balíků z cznic

Powered by mwForum 2.29.3 © 1999-2013 Markus Wichitill