Dotaz: IPv6 - nejede Gmail

[Tonda]

Zdravím!

Nevím si už rady, tak se zkusím zeptat... Snažím se rozchodit IPv6 a uvízl jsem v situaci, kdy se to zdánlivě tváří, že to je funkční - webové stránky, které mají konektivitu přes IPv6, se načítají touto cestou a i test na http://ipv6-test.com/ říká, že je vše OK.

Jenže když se chci přihlásit na Gmail, tak po vyplnění jména a hesla to zůstane zaseklé a nepokračuje v načítání nebo to maximálně zobrazí průběh načítání a cca v půlce se to kousne. Dál se to nikdy nedostane. Takže na Google Mail se nikdy přes "šestku" nedostanu.

Koukal jsem se na to Wiresharkem a hádám, že tomu kousnutí odpovídá moment, kde moje strana posílá "TLS Encrypted Alert - 21" a hned za tím moje strana ukončuje spojení (FIN paket). Jako odpověď ke mě přijde RST od protějšku. Před tím normálně lítají pakety tam a zpátky - nic z toho nevyčtu.

Mám z dřívějších dob na jiném pc nainstalovaný tunel na IPv6 pře Gogo6. Když to nahodím, tak ten Gmail jede v pohodě.

Router je pc s Fedorou, připojení na Internet je přes O2, modem je zapojen jako bridge, ip6tables jsou prakticky prázdné (mám tam jen 2 řádky - pro provoz na loopbacku). Na ppp0 se nastavuje šestková adresa přes RA, na domácím síťovém rozhraní je radvd, který posílá prefix získaný od poskytovatele přes DHCP. MTU na ppp0 se nastavuje samo na 1492. V konfiguráku pro radvd jsem to zkoušel snížit na 1400, ale nepomohlo to...

Pracovní pc je Fedora, ip6tables úplně prázdné.

Budu vděčný za jakýkoliv námět co zkusit, protože už fakt nevím, co s tím.

---

---

Odpovědi

[Petr Šobáň]

Co znamená ip6tables prázdné? (ACCEPT, DROP, REJECT?)

Pro správnou funkci IPv6 nesmíš blokovat icmp pakety.

Jinak jaký máš modem, v comtrendu VR-3026e nejde aby byl modem v bridge a fungovalo IPv6. (Chyba v FW a zatím to neopravily a asi neopraví)

Jinak ostatní věci fungují - všechny ostatní servery.

[Tonda]

Na routeru je pouze:
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -d ::1 -j DROP
Jiného nic neblokuji.

Modem mám ZyXEL VMG1312-B30B. Firmware je aktualizovaný (zaslaný z podpory ZyXEL ČR), původní firmware (a podle O2 stále nejnovější) dělal s bridgem problémy.
Ad "ostatní věci" - normálně prohlížím stránky (ve Firefoxu mám plugin, který ukazuje, jestli je stránka načítána po IPv6) a zdánlivě není problém.
Zatím vím, že mi nejde Google mail - ten se nenačte vůbec, a ještě Google mapy. Tam se při načítaní mapy jednotlivé čtverce často nenačtou všechny, ale v nějakým okamžiku se to kousne.

Takhle podobně mi to blblo, když jsem nastavoval starou IPv4 - než jsem přišel na to, že musím na routeru (v iptables) u odchozích SYN paketů nastavovat MSS na nějakou nižší hodnotu - podle MTU v PPPoE. Na IPv6 už nevím, co "poštelovat". Zkusil jsem v radvd.conf snižit MTU (AdvLinkMTU 1400). Ale to nepomohlo. Všiml jsem si ve Wiresharku, že snižení toho MTU se projevilo ve snížení hodnoty parametru MSS - ten se nastavil na 1340 bytů. Což se mi zdá dostatečně malé a nepokoušel jsem se to dál snižovat. Nevím, co s tím...

[Petr Šobáň]

A základní politika je ?

Forward paketů je povolen?

A blbne to z jiného PC a nebo z toho co dělá router a nebo z obou?

Význam těch pravidel na routeru nechápu, protože pokud máš politiku na ACCEPT tak jsou zbytečná a pokud máš politiku na DROP tak z routeru nemůže nic přes IPv6 odejít.

[Tonda]

Základní politika je ACCEPT.
Forward je povolen - z domácí sítě udělám úspěšný "ping6 www.google.com" a načítám www stránky (na IPv6). Na síťovém rozhraní je vidět provoz IPv6.
Test z jiného PC udělám večer a zítra napíšu, co to dělalo.
Význam těch pravidel by měl být ten, že by nepovolila connect z LAN, pokud by měl paket IP adresu loopbacku a MAC adresu routeru. Za normálního provozu se to nestává, ale při troše snahy to lze vyrobit. (si myslím) Dalo by se o tom polemizovat, jestli to je paranoidní nebo (technicky) zbytečné (navíc, nepotřebné), ale myslím, že na problém, který řeším, to nemá vliv.

[Petr Šobáň]

Tak potom nevím kde je problém - v MTU asi ne protože i tunel má menší MTU, ale klidně můžeš skusit menší MTU.

Skus skouknout routovací tabulku zda tam není nějaká zrada?

Pak mě napadá nějaká zrada v tom ppp0, ale jaká netuším.

[Tonda]

Děkuji. Večer to vyzkouším, zítra dám vědět.

[pavlix]

Občas je potřeba hlídat MTU z obou stran. :)

[Vantomas]

Takže přes IPv4 to funguje a přes IPv6 to nejde? IPv6 konektivita není nativní a je skrz nějaký tunel? Ten tunel má menší MTU než 1500? Problémům se zasekáváním webových stránek spolu při menším MTU značí na problém s tím, že něco po cestě zahazuje pakety, které něco odmítá fragmentovat. Řeší se to přes takové to nastavení TCP MSS, ale většinou se to nastavuje na druhé straně VPN odkud pakety přichází, což by mohl být problém, protože tam asi nebude přístup.

[Tonda]

IPv4 je OK. MSS nastavuji v iptables.
IPv6 je nativně přes O2 - zde řeším ten problém (nejde mi přihlásit se na Gmail).
Na routeru směrem na O2 mám na ppp0 rozhraní MTU 1492. Jak jsem psal dříve, zkusil jsem snižit MTU na 1400, což se projevilo tak, že si TCP spojení nastavil MSS na 1340 (to by snad mohlo stačit?). Ale blblo to pořád dál.

Pro porovnání jsem zkusil IPv6 přes tunel (MTU 1280) a tam mi to jelo v pořádku.

[j]

Telecum? No trebas je ten port na kterej se pripojujes strasne nebezpecnej, tak ho radsi blokujou, to oni radi ... nebo ti blokujou DNS, to taky radi ...

Jinak me napada, vzhledem k chovani ktery popisujes ... nahod si noscript, a zkus ten mail, mapy bez js fungovat nebudou. Alternativne vyzkousej jinej browser. Tohle totiz vypada jako nejakej problem az na urovni js, kdyz ti 6ka jak pises funguje. Pripadne muzes checknout nmap -6 ...

Mno a pokud si rad dojdes zarvat na nadrazi, tak muzes poslat nejakou tu stiznost ze to nefunguje.

Jop, jeste me napada ... to radsi nechtej vedet ... teda v CR si provideri radi delaj ruzny naschvaly, takze tvoje cesky pakety klidne muzou behat pres londyn ... a zpet do CR ... mno a jelikoz google ma po svete ruzny rekneme cache, tak se kvuli tomu proste pripojujes na nejakou ne zrovna idealni a tudiz ... to proste funguje tak jak popisujes. Muzes zkusit trace, ale je treba si uvedomit, ze googli DNS ti pokazdy vrati neco jinyho. Takze je lepsi to otestovat na necem domacim.

[Tonda]

DNS resolver mám vlastní na routeru. Mám zapnuté DNSSEC.

[pavlix]

A testoval jsi, že tam není problém? Tzn. že resolving funguje, jak má?

[pavlix]

Teď koukám teprve, že je to ten stejný problém, co už je zřejmě vyřešený.

[pavlix]

Klasika. Problém pouze přes O2 a ti ho v životě nedokážou řešit. Škoda že na něj narážíš až u těch javaskriptů. Když používáš tunel, jede všechen traffic gmailu po IPv6?

[Tonda]

Udělal jsem test na jiném počítači, kde jsou Win7. Zde všechno fungovalo tak, jak má. Vyzkoušel jsem přihlášení do Gmailu, jak z Firefoxu, tak i z Internet Exploreru, všechno bez problémů.

Takže mě zlobí jen jiné 2 PC (oba Linux) - jeden z Fedorou 23 a druhý s Ubuntu 14.04 LTS. Oba plně aktualizované.
Řadu webů načítám bez problému, např. www.abclinuxu.cz, www.root.cz, www.wikipedia.org.
Ale nenačte se mail.google.com a www.youtube.com blbne - ten se někdy načte, někdy ne.

Zkoušel jsem oveřit velikost paketu, který projde:
ping6 -c 3 -M do -s 1444 www.google.com
PING www.google.com(prg02s12-in-x11.1e100.net) 1444 data bytes
1452 bytes from prg02s12-in-x11.1e100.net: icmp_seq=1 ttl=57 time=55.9 ms
1452 bytes from prg02s12-in-x11.1e100.net: icmp_seq=2 ttl=57 time=59.8 ms
1452 bytes from prg02s12-in-x11.1e100.net: icmp_seq=3 ttl=57 time=48.9 ms

--- www.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 48.936/54.908/59.828/4.516 ms

U většího si už stěžuje, že je větší, než dovoluje MTU(=1492).
Řekl bych, že v MTU problém nebude.

[Petr Šobáň]

Co firewally na těch linuxech pro IPv6?

Pak když používáš svůj DNS co skusit na těch PC kde to blbne nastavit DNS na nic.dns?

2001:1488:800:400::130 2001:678:1::206

Protože mě fakt nenapadá kde jinde by mohl být problém.

[Petr Šobáň]

Pak mě už napadá pouze jedna věc odpojit všechno nechat pouze ty windows a spojit se s mailem na google a wiresharkem si uložit komunikaci, a pak to skusit z linuxu a porovnat rozdíly.

A zjistit co neprošlo.

[Tonda]

Firewally mají všechno ACCEPT, resp. žádná pravidla.
Wiresharkem jsem to studoval, ale nic z toho nepoznám - na začátku DNS dotazy, pak šifrovaná komunikace... Nakonec reset spojení.

No nic, děkuji za nápady, budu se s tím dál nějak prát.

[Jendа]

Projevila se ta změna MTU i na klientech?

Můžeš to zkusit něčím víc lowlevel, třeba openssl s_client?

[Tonda]

Ano, MTU jsem zkusil změnit v nastavení radvd na routeru - vyzkoušel jsem AdvLinkMTU dát na 1400 a posléze i 1280. Změna se u klienta objevila - ve Wiresharku u SYN paketů byla odpovídající hodnota (=MTU-60). Ale Gmail se i s takto sníženou hodnotou odmítal načíst.

Jenom připomenu, že když jsem vypnul nativní IPv6 přes O2 providera a nahodil tunel přes Gogo6 (ten měl MTU 1280), tak všechno chodilo. Připadám si jak blázen.

"openssl s_client" mi nic neříká. Vyhledám a nastuduji. Ale asi bych se k tomu dostal až přes víkend.

[Tonda]

...mám na mysli: MSS=MTU-60

[Petr Šobáň]

Skus přímo na síťovce nastavit MTU třeba na 1000 co to udělá, pak by od klienta neměl odejít větší paket.

Já IPv6 mám a youtube bez problémů.

[Tonda]

IPv6 má kde kdo a bez problémů. Jen se tento druh problému špatně diagnostikuje.

"přímo na síťovce" je kde? Je klient se síťovkou, pak router se síťovkou a pak ppp rozhraní. Obě síťovky mají MTU 1500 - což odpovídá ethernetu a je podle mě správně. ppp rozhraní má MTU 1492, což odpovídá protokolu PPPoE a mělo by tak správně být (podle mě, ale mohu se mýlit). A mám pocit, že se to tak nastaví samo při nahození ppp spojení.

[Jendа]

IPv6 nemůže fungovat, když je MTU pod 1280, takže 1000 nenastavíš, ne?

[Tonda]

Tak tak. Měl jsem v hlavě, že to má nějaké rozpětí, ale nebyl jsem si jist, jak ta čísla jsou.

[Vantomas]

Ve Windows funguje, v Linuxu nefunguje, to je zajímavé zjištění.

Ta Fedora kam je připojen modem má i Xka aby se vyzkoušel ten Google přímo z toho stroje? Nebo se to zkouší až z dalšího počítače v síti za touto Fedorou? Dle popisu vidím, že tam jsou Fedory dvě, tak jen odkud to přesně nejde.

Jestli něco zkoušet pingem, tak to chce zkusit více IP adres než jen ten google.com, protože přihlašování do Google služeb funguje několika redirectama napříč různýma serverama, které se starají o přihlášení uživatele a problém může být zakopaný na jednom z těchto serverů. Může třeba blokovat pakety o menší velikosti nebo tak něco. To by i vysvětlovalo proč zlobí všechny Google služby, protože závisí na těchto SSO serverech.

Zatím kdykoliv jsem se vždycky setkal s problémem, že nějaké weby šly a jiné záhadně ukázaly jen bílou stránku byl v tom, že jsem v cestě měl nějakou VPN, kde nebylo nastaveno MSS pro fragmentaci paketů směrem do tunelu a tak došlo k zahození toho paketu.

Pokud to na problém s MTU nevypadá, tak jsem se s tímto problémem takto nikdy nesetkal a tak jsem zkusil pogooglovat ohledně ipv6 a bílé stránce a našel jsem tři roky starý bugreport u Mozilly, že je problém při přístupu na Google přes IPv6, někdo tam doporučil ve Firefoxu zakázat IPv6 a používat jen IPv4, načež zadavatel řekl "IT WORKS!" a tím to skončilo. Zkoušelo se to v tom Linuxu i v jiném prohlížeči než ve Firefoxu?

[Tonda]

Win7 funguje. Fedora 23 a Ubuntu 14.04 LTS nefunguje, a včera jsem vyhrabal jednu starou flešku s Kali Linux 1.1.0 (cca 2 roky staré) kde je prohlížeč IceWeasel (odnož Firefoxu) a tam to po IPv6 jede - Gmail se normálně načte.

Router je Fedora 23 Server, bez grafiky.

Ping posílám zpravidla na www.seznam.cz a www.google.com . Vrací se bez problémů. Včera jsem znovu zkoušel posílat ping pakety s nastavenou velikostí odpovídající MTU na ppp rozhraní (1492). Díval jsem se ve Wiresharku - jde velký paket tam a velký paket se vrátí.
Pokud by po cestě bylo úzké hrdlo, tak bych čekal, že se to vyřeší pomocí ICMP zpráv.
Nicméně, i tak jsem zkoušel snížit MTU, které posílá z routeru do domácí sítě radvd na 1280 (což je asi technické minimum pro IPv6) a i tak to blblo.

Přísně vzato - on ten Gmail na bílé stránce skončí v cca 50% případů, někdy to projde až k tomu bežícímu proužku, který zobrazuje načítání stránky a zatuhne nekompromisně až tam.

[j]

A overil sis, ze ty widle komunikujou nativne a ne pres tunel? Klidne na nich muze bezet tunel.

[Andrej]

Jako výstřel do tmy naslepo bych doporučoval zkusit na tom serveru/routeru následující:

ip6tables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

To zajistí, že ať je MTU v LAN jakákoliv, SYN směrem ven nebude navrhovat celou LAN MTU (což bývá na WiFi třeba 2700 B, na ethernetu většinou 1500 B, nejsou-li tam jumbo pakety, atp.), ale tweakne to na správnou menší hodnotu, aby se žádná ze stran nesnažila poslat paket, který prostě neprojde.

Tohle by mohl být problém s MTU, který jsem už párkrát viděl a který se projevuje naprosto přesně tím, co je napsáno v dotazu — všechno zdánlivě prochází až do té chvíle, než se z jakéhokoliv důvodu (obrázek, kryptografický protokol) začnou generovat pakety o velikosti těsně pasující do MTU nebo (v případě PPPoE) překračující MTU. Protože se IPv6 prostě nefragmentuje (skoro, většinou, až na pár hodně zvláštních překvapení), je jasné, že na tohle doplatí mnohem snáze než IPv4.

A mimochodem, výše uvedený příkaz s iptables místo ip6tables se může hodit také pro IPv4 — zlepší totiž throughput i latenci právě v situacích, ve kterých by se jinak fragmentovalo na velké počáteční kusy paketů a malé zbytky.

[Tonda]

Zkoušel jsem.

To co popisujete, jsem zažil když jsem nastavoval modem, aby chodil jako bridge. Internet se choval velice podivně (dost podobně jako ten můj současný problém - proto se pořád snažím něco dělat s tím MTU) - www stránky se někdy načetly, někdy ne. Ale co si vzpomínám, tak těch nefungujících stránek bylo mnohem víc, stačilo aby někde byly obrázky nebo nějaký objemnější obsah. Tam mě to trklo brzy a "mss clamping" to vyřešil.

Proto taky jedna z prvních věcí byla, že jsem to zkusil naroubovat i do těch ip6tables. Ale nepomohlo to. V tcpdump jsem si ještě ověřoval, jestli se na tom routru v hlavičce SYN paketů ta hodnota MSS opravdu předělává...

[Michal Kubeček]

Protože se IPv6 prostě nefragmentuje (skoro, většinou, až na pár hodně zvláštních překvapení)

Tak tohle jsem si kdysi taky myslel…

[Andrej]

A byla to pravda.

[Michal Kubeček]

Ne, byl jsem z toho omylu velmi rychle vyveden.

[lertimir]

No fragmentují se na odchozí stanici. Samozřejmě, protože UDP paket větší než MTU musí rozdělit IP. Ale Andrej asi myslel to, že po cestě se IPv6 nefragmentuje.

[pavlix]

Tak jestli to dobře chápu, tak andrej pouze nešikovně použil závorku (napsal do ní něco, co zásadně mění smysl sdělení).

[Tonda]

Takže jsem večer zase zkoušel možné i nemožné a toto jsem zjistil:

- zkusil jsem promazat cache ve Firefoxu - nepomohlo
- zkusil jsem zakázat všechna rozšíření ve Firefoxu - nepomohlo
- zkusil jsem se přihlásit na email Seznamu - bez problémů (samozřejmě po IPv6)
- znovu jsem zkoušel poslat ping pakety na www.google.com s nastavenou velikostí na 1464 (IPv4) a 1444 (IPv6) - bez problémů
- během záseku načítání Gmailu jsem si všiml, že se někdy zobrazí dole taková ta nabídka na přepnutí stránek do holého HTML rozhraní - po kliknutí se Gmail normálně načetl (samozřejmě pouze v tom HTML)
- zkusil jsem nabootovat ze staré flešky, kde jsem měl Kali Linux 1.1.0 (cca 2 roky starý), kde je prohlížeč IceWeasel a ten Gmail načetl normálně. Ale možná nenačítal to samé, jako ten Firefox na aktuální Fedoře, protože IceWeasel chtěl jméno a heslo v jednom formuláři. Ten aktuální Firefox po zadání jména jakoby přeskočí na další stránku, kde je formulář pouze pro heslo.
- na závěr jsem si znovu nahodil tunel na Gogo6 a znovu vyzkoušel, že ten Gmail, který jsem dříve nenačetl, tady normálně otevírám. K vzteku...

[Tonda]

Při pročítání komunikace směrem na Seznam email jsem zjistil, že na začátku přijde z login.szn.cz jeden paket velký 1516 bytů (MTU pro PPPoE je 1492). To nechápu, jakto že to vůbec projde?!

[Vantomas]

Protože se ten paket fragmentuje a přes tunel a následně 1500B Ethernet pošle na víc částí, ale po složení paketu se do systému dostane jako 1516B.

Co zkusit na tý Fedoře a Ubuntu nainstalovat ještě jiný prohlížeč a vyzkoušet to v tom, aby se eliminoval ten bug ve Firefoxu u kterého doporučovali vypnout IPv6? Nejlépe něco co není od Mozilly a něco co nepoužívá Gecko.

[Tonda]

To složení fragmentů dohromady proběhne ještě předtím, než to čte Wireshark?

Na tom Ubuntu bych to mohl zkusit. To by mohlo ledacos napovědět. Tak co je na výběr - asi Chrome nebo Opera, že?

[Vantomas]

Místo Chrome lze nainstalovat Chromium, to je většinou bez Google blobů, kdekomu se ty Google věci příčí.

Co se skládání fragmentů týče, přiznám, že jsem toto nikdy nezjišťoval a nemotal se kolem toho, nebylo proč. Něco se dá domyslet kolem toho, že MTU je záležitost druhé vrstvy, takže to skládá přímo síťovka v nějaké mezipaměti nebo jádro někde na vstupu do subsystému.

[Michal Kubeček]

To složení fragmentů dohromady proběhne ještě předtím, než to čte Wireshark?

Rozhodně ne. Pokud to tedy někdo neposkládá ještě předtím, než to vůbec přijde na ten stroj (což by se ale u IPv6 stát nemělo).

[lertimir]

Ale TCP pakety větší než MTU by chodit neměly.

[Michal Kubeček]

To by sice chodit neměly, ale vzhledem k tomu, že to není o moc větší a že kolega nepíše, co všechno je započteno do těch 1516 B, moc dalekosáhlé závěry bych z toho nevyvozoval.

[Tonda]

Výpočet vypadal takto:
Délka paketu ve Wiresharku (sloupec nadepsaný "length") byla 1530.
Od ní jsem odečetl "ethernet header" - 14 bytů.
Vzniklo 1516 bytů - IP hlavička + data.
Pokud je MTU mého PPP rozhraní 1492, tak čekám, že nic většího neprojde ven a ani ke mě. Ale nehádám se, mohu se samozřejmě mýlit.

[pavlix]

Wireshark neumí reportovat velikost IP paketu, aby člověk nemusel hádat? Mně osobně celý problém stále zavání MTU, ať už z jedné nebo z druhé strany. V případě, že něco běhá, tak spíše z té druhé.

[alkoholik]

Jeste se podivej, jestli ti tam pri vytuhnuti nevisi nejake TCP spojeni ve stavu SYN_SENT.

[Tonda]

Nemyslím si, že by tento stav nastal - ve Wiresharku je vidět SYN paket na začátku, pak odpověď a další komunikace do ukončení spojení (FIN a RST). Bohužel je všechno šifrované (https) a nelze v té komunikaci vyčíst, proč se to kousne.
Nicméně, píšu si to na seznam a večer se zkusím i na toto podívat.

[j]

Chmm ... tohle by opet ukazovalo na problem s js, a tudiz browser.

[pavlix]

A zkusil jsi Chrome/Chromium?

[Luboš Doležel (Doli)]

Spustit Wireshark na úrovni vaší vnitřní sítě a porovnat s tím (opět Wireshark), co jde opravdu do ppp0 a na také interface, kde je ten bridgovaný modem.

[Tonda]

- hledal jsem, jestli se při zatuhnutí Gmailu neobjeví neukončená spojení (SYN_SENT) a netstat vypsal jen pár kusů ESTABLISHED a TIME_WAIT. Takže toto je myslím v pořáku.

- nainstaloval jsem Chromium na počítač, kde mám Ubuntu - a to fungovalo normálně. Gmail se načetl kompletní.

Je tam nějaký problém a Chromium se s ním vypořádá, ale Firefox ne. Protože to blbne jenom mě, tak předpokládám, že Firefox je ok a asi tam budu mít něco špatně nastavené na routeru. (jenžto když ten IPv6 provoz ženu přes tunel, tak to všechno chodí jak má)

[pavlix]

To mě zajímalo. Takže rozdíl mezi Firefoxem a Chromiem. A rozdíl mezi O2 a tunelem. Takže jenom kombo Firefox/O2 dává ten symptom. No nicméně na jednom stroji se teď bude líp porovnávat traffic Firefox versus Chrom, nedej bože nějaký strace -e network na případné rozdíly v práci se sítí.

[Tonda]

Práce s "strace" je už mimo mé znalosti. Ale je to tak, jak jste to popsal.
V tuto chvíli končím (z mé strany) diskusi. Přes víkend se s tím budu intenzivně prát a v pondělí dám vědět, jestli jsem se někam pohnul. Zdravím!

[pavlix]

Kdyžtak mě můžeš odlovit v pondělí na IRC.

[Lol Phirae]

Jen pro připomenutí - měl jsem problémy s https provozem na IPv6. Gmail se nenačetl vůbec, Google Maps často jen částečně, někdy zlobil i YouTube. Ale nebyl to jev obecný, https na IPv4 jelo bez problémů a třeba mail na Seznamu po IPv6 jel také v pohodě.

ŘEŠENÍ:

na routeru docházelo k jevu, kdy se za určitých podmínek některé příchozí pakety slučují do jednoho většího (za účelem zvýšení datové průchodnosti a odlehčení vlastní CPU). Tato vlastnost je na routeru nežádoucí a měla by se asi vypínat.
Pomohlo použít v nastavení síťového rozhraní (u Fedory v adresáři /etc/sysconfig/network-scripts) toto:

ETHTOOL_OPTS="-K $DEVICE gro off"

Více teorie zde:

https://lwn.net/Articles/358910/
https://en.wikipedia.org/wiki/Large_receive_offload
https://www.myricom.com/software/myri10ge/349-when-i-view-traffic-with-tcpdump-why-do-i-see-packets-larger-than-the-mtu.html
http://packetbomb.com/how-can-the-packet-size-be-greater-than-the-mtu/

[pavlix]

Takhle se HTTP(S) odkazy v HTML nepíšou.

[Tonda]

Máte pravdu, to se mi zrovna nepovedlo...

[pavlix]

Jinak k tomu bych si nechal ještě líbit pár detailů. Ne ohledně řešení, ale spíše v čem konkrétně je ten problém a proč je offloading vůbec nastavený tak, aby to nefungovalo. To zní jako bug.

[Lol Phirae]

proč je offloading vůbec nastavený tak, aby to nefungovalo

Páč woe přece ten offloading je hrozně kchůůl, psali to v marketingovym letáku, a ještě k tomu ušetříš asi 0.0000000000023% výkonu CPU a to se hrozně vyplatí!!!

[pavlix]

Vidím volbu „označit jako řešení“, ale kde je volba „označit jako vola“?

[Tonda]

Pokud bude v mých silách, tak poskytnu info. Spíš se ale zeptejte.

"v čem konkrétně je ten problém" - jak se to projevovalo jsem již psal.
Konfiguraci sítě jsem také popisoval. Jen dodám, že ten offloading byl na mém Fedora serveru zapnut implicitně. (nebyla to moje snaha o nějaké "vylepšení")
A jediné nastavení, které jsem k tomu našel je, že se to zapne nebo vypne. Na ne-routeru to asi může na síťové vrstvě přinášet nárust výkonu ale u routeru to zlobí. A podle mě vcelku logicky - router by měl pouze přehazovat pakety mezi rozhraníma a neměl by je nijak upravovat.

[pavlix]

u routeru to zlobí

To je přesně to, co mě zajímá. Popis toho, co se stane jinak, jaké to má důsledky, a proč to neprojde.

router by měl pouze přehazovat pakety mezi rozhraníma a neměl by je nijak upravovat.

Třeba na OpenBSD se běžně používá TCP proxying pokud vím. Sice je to technologicky trochu něco jiného, ale taky je to zásah do paketů.

[petr_p]

Třeba protože tam byla chyba v implementaci.