HE 6in4 tunnel, TCP kapcsolat megszakad

[sipsza]

Sziasztok!

Láttam, hogy itt már többen is próbálták a Hurricane Electric 6in4 tunneljét.
Én eddig tudok a tunnelen keresztül pingelni tetszőleges IPv6 címet, de az összetettebb TCP kapcsolatok (pl. tls) hamar megszakadnak.

Csatolok egy packet capture-t, ami a PPPoE interfészen készült egy https kapcsolatról.

Sagemcom F@st 5655v2 AC ONT-t használok PPPoePassthrough módban, fw: SG3G10000494. Az IPv6 dualstack az ügyfélszolgálat szerint nem aktiválható.
A 6in4 tunnelt és a tcp kapcsolatot már próbáltam indítani a következő eszközök összes lehetséges kombinációjáról: mikrotik router, openwrt router, linux pc, windows pc. Mindegyiken a legfrissebb szoftver van, ipv4/ipv6 tűzfal/nat/fastpath kikapcsolva.

A PPPoE kapcsolatom MTU-ja 1480, a 6in4 tunnel MTU-ját végigpróbáltam 1280-tól 1460-ig. A tcp MSS-t is próbáltam kicsire venni.
A tunnelen az 1460 byte-os ICMPv6 echo csomagok egészben átjutnak.

Találkoztatok már hasonló hibával?

Köszi,
Szabolcs

[sipsza]

Egy kis frissítés, hátha jól jön még valakinek.

Szereztem egy VPS-t natív IPv6-tal, hogy lássam, hogy a szerver melyik csomagokat kapja meg.
 - a 3-way handshake megtörténik sérülésmentesen, ha otthonról indítom a TCP kapcsolatot; de a fordított esetben nem kapom meg a VPS-töl az ACK-ot
 - a VPS minden csomagot megkap a klienstől
 - a PSH, RST, FIN csomagok megérkeznek a klienshez
 - az üres ACK-ok nem érkeznek meg a klienshez

Ezután megnéztem, hogy mi történik a router ONT felőli ethernet interfészén. (Nem tudom, hogy  ez korábban miért nem jutott eszembe.)
Az üres ACK-okat tartalmazó csomagok is megérkeznek, de a PPPoE headerben a csomagméret eltér a valóstól (pl.: 106 helyett 2123, 94 helyett 1915), ezért a router PPPoE drivere eldobja.

Kíváncsiságból csináltam egy pár GB-os IPv4 packet capturet, amiben volt web, torrent, tcp, udp, de a PPPoE header sehol sem volt sérült.

Megpróbáltam a Hurricane Electric helyett a VPS felé kiépíteni tunneleket:
 - 6in4 tunnel esetén az eddigi hibát tapasztalom
 - 4in4 = IPIP: minden ok
 - GRE-n belül nekem az IPv4 és az IPv6 is ok, mással ellentétben

Találtam valakit, akinek ugyanilyen problémája volt, de másik szolgáltatónál:
Problem with 6to4 inside PPPoE

[sipsza]

Frissítés 2.

Cseréltek nálam ONT-t (egy másik hiba miatt). A típusa és a fw nem változott, és sajnos a hiba sem.

Észrevettem, hogy a következő hibaüzenet jelenik meg a logok között az ONT-n, amikor megérkezik egy ACK a szervertől:
[ERROR pktrunner] add_fwd_commands,502: Unable to determine if the flow is routed/bridged (502)

Valaki meg tudná mondani, hogy milyen csatornán érdemes az ilyen jellegű hibákat bejelenteni?

[Halacs]

Szia!

Én is ezzel küdtök. Sikerült jutnod valamire? A csomag méreteket nem néztem még, de nálam a következő van.

Adott két lakás, mindkettőben Telekom. Az egyik ("A" lakás) Telekom optikával, a másik ("B" lakás) Telekom de koaxon. Mindkét helyen Mikrotik router van.

A "B" lakásban a HE 6in4 tunnel remekül megy, míg a másik lakásban ping6 rendben, de TCP kapcsolat (curl -vv6 http://google.com) már nem megy rendesen. A konfigurációban nem találtam különbséget a két lakás közt, sőt mi több úgy emlékszek mielőtt Telekomra váltottam volna *****-vel működött is frankón minden.

Természetesen IPv4 esetén semmi probléma nincs.

Ha megnézem a router HE tunnel interészét akkor azt látom, hogy kimennek a csomagok, még a kapcsolat is felépül de mikor a HTTP payload kimegy már nem jön többet ACK ezért indul a retransmisson majd kapcsolat bontás (FIN,ACK majd RST).

Szerkesztve ekkor: 2020. június 25. Szerkesztő: Halacs

[sipsza]

@Halacs

Szia!

Úgy néz ki, hogy a Broadcom pktrunner nevű kernelmoduljában van a hiba. (A Sagemcom ONT-ben Broadcom SoC van.) A Broadcom a hibát már rég javította, de hozzánk valahogy még nem ért el.

Írtam több emailt is a Telekomnak, bennük a hiba részleteivel és a feltételezett okkal. Egyikre sem kaptam választ.
Felhívtam az ügyfélszolgálatot. Ott azt mondták, hogy ha kapnak új firmware-t a Sagemcomtól, akkor azt egyből megkapjuk mi is, de jelezni nem fogják a hibát a Sagemcom felé.
Írtam a Sagemcomnak, hogy tudnak-e a hibáról, és, hogy a SG3G10000494-e a legújabb firmware. Megkérdezték, hogy ki a szolgáltatóm, majd ők sem válaszoltak többet.

Ez volt február elején, azóta semmi fejlemény.

[sipsza]

Sziasztok!

Egy ideje már kint van az SG3G10000604 firmware a Sagemcom ONT-re, de még semmilyen közleményt nem láttam a javított hibákról.
Valaki le tudná nekem ellenőrizni, hogy megoldódott-e a probléma?

Az én ONT-met időközben visszacserélték a Huawei-re (fw.: V3R017C10S150), amivel gond nélkül tudok 6in4 tunnelt használni, de valószínűleg újból egy Sagemcomot kapok, ha egy  nagyobb csomagra váltok.

[Halacs]

6 órája, sipsza írta:

Sziasztok!

Egy ideje már kint van az SG3G10000604 firmware a Sagemcom ONT-re, de még semmilyen közleményt nem láttam a javított hibákról.
Valaki le tudná nekem ellenőrizni, hogy megoldódott-e a probléma?

Az én ONT-met időközben visszacserélték a Huawei-re (fw.: V3R017C10S150), amivel gond nélkül tudok 6in4 tunnelt használni, de valószínűleg újból egy Sagemcomot kapok, ha egy  nagyobb csomagra váltok.

Szia!

Nekem szerencsém van mert voltak olyan jó fejek annó és nekem külön bekapcsolták hogy nálam működjön a dual stack, de rövid ideig most  vissza kapcsoltam a HE tunnel interfészt a routeremben.

Eredmény:

- tunnel interfész azt mondja magáról hogy "enabled" meg hogy "running"

- ugyanakkor a ping nem megy: ping 2a00:1450:4016:801::200e interface=HE-IPv6-broker --> no route to host

Megeshet, hogy valamit én szúrok el, most nincs agyam utána gondolni, de ez alapján nem megy és ha jól emlékszem nekem is Sagemcom ONT-m van ebben a lakásban.

Azt még gyorsan megnéztem, hogy a HE oldalán a client IP az stimmel azzal amim van - script frissíti időnként úgy fest azóta is

Szerkesztve ekkor: 2020. augusztus 30. Szerkesztő: Halacs

[sipsza]

@Halacs

Köszönöm a választ!

Ping, UDP nekem ment anno, csak a TCP-vel voltak gondok. A hiba szerintem nálad is másból ered, vagy nincs aktív cím az interfészen, vagy nincs felvéve arra fele mutató route.

Példa konfig a HE oldaláról:
/interface 6to4 add comment="HE IPv6 Tunnel Broker" disabled=no local-address=*.*.*.* mtu=1280 name=sit1 remote-address=216.66.87.14
/ipv6 route add comment="" disabled=no distance=1 dst-address=2000::/3 gateway=2001:470:*:*::1 scope=30 target-scope=10
/ipv6 address add address=2001:470:*:*::2/64 advertise=no disabled=no eui-64=no interface=sit1

 

 

[e.tamas]

@sipsza

Szia!

Ugyanezzel a problémával küzdök én is. Eltöltöttem pár órát, mire rájöttem, hogy nem MTU/MSS probléma van, hanem a PPPoE headerben rossz payload length értékek jönnek a válasz ACK-kban és magában a válasz üzenetben is, amiket így a router (vagy a Sagemcom ONT) eldob, attól függően, hogy ki terminálja a PPPoE-t.

Van (még) egy ***** kábeles netem is, amin ez eddig tökéletesen működött, ott ugye nincs PPPoE. Viszont az ***** felmondta a szolgáltatást, úgyhogy most próbálnám átrakni a HE 6in4 tunnelemet a T-s kapcsolatra. (Mert a T egyelőre nekem nem adott még natív IPv6-ot. Talán 2 éve kérdeztem őket erről, azt mondták fokozatosan vezetik be, majd sorra kerülök. Erre szerintem még várhatok egy darabig :-) )

Először azt gondoltam, hogy az ONT-s NAT környékén lehet valami gond, bár furcsa volt, hogy a ping és UDP megy, csak TCP-vel van baj. Megkértem a PPPoE passthrough beállítást az ügyfélszolgálattól, és mostmár a routerem végződteti a PPPoE-t. Ekkor találtam meg a valódi problémát, amikor az ONT felé menő porton sniffeltem a forgalmat.

Nem igazán tudom mit tudok tenni. SagemCom 5655v2 a home gw, és SG3G10000604 firmware van már rajta, és így sem működik. Márpedig meg szeretném oldani, mielőtt megszűnik az Invi netem :-)

Őszintén nem is értem, hogy hogyan tud belegányolni a PPPoE headerbe a hgw ilyen módon, ha a PPPoE-t az én routerem végződteti. Szóval az is lehet, hogy nem a hgw-vel van probléma, hanem a BRAS oldalon? De az meg hogy a pékbe rontja el a payload length-et az IP 6in4-be foglalt IPv6-on belüli TCP valamilyen attribútuma alapján, hogy csak a válasz ACK és a tényleges válasz csomagok sérülnek így? Vagy lehet, hogy csak a csomag hosszától függően romlik el?

Bár ahogy írtad, nálad az ONT csere megoldotta a hibát, szóval akkor mégis ONT hiba lehet?

Mindenesetre guglizva az invalid PPPoE payload length kulcsszavakra, azért én is találtam pár bejegyzést, ahol ugyanezt a hibát írják le, ezen a fórum bejegyzésen kívül is, szóval a probléma nem egyedi :-(.

Érdemes bejelentenem a problémát az MT ügyfélszolgálaton? Gyanítom a first line-on túl kellene jutnom valahogy, hogy érdemben tudjak beszélni erről valakivel :-)) pcap file-t tudok prezentálni nekik, amiben egyértelmű a hiba oka.

[Halacs]

38 perce, e.tamas írta:

@sipsza

Szia!

Ugyanezzel a problémával küzdök én is. Eltöltöttem pár órát, mire rájöttem, hogy nem MTU/MSS probléma van, hanem a PPPoE headerben rossz payload length értékek jönnek a válasz ACK-kban és magában a válasz üzenetben is, amiket így a router (vagy a Sagemcom ONT) eldob, attól függően, hogy ki terminálja a PPPoE-t.

Van (még) egy ***** kábeles netem is, amin ez eddig tökéletesen működött, ott ugye nincs PPPoE. Viszont az ***** felmondta a szolgáltatást, úgyhogy most próbálnám átrakni a HE 6in4 tunnelemet a T-s kapcsolatra. (Mert a T egyelőre nekem nem adott még natív IPv6-ot. Talán 2 éve kérdeztem őket erről, azt mondták fokozatosan vezetik be, majd sorra kerülök. Erre szerintem még várhatok egy darabig :-) )

Először azt gondoltam, hogy az ONT-s NAT környékén lehet valami gond, bár furcsa volt, hogy a ping és UDP megy, csak TCP-vel van baj. Megkértem a PPPoE passthrough beállítást az ügyfélszolgálattól, és mostmár a routerem végződteti a PPPoE-t. Ekkor találtam meg a valódi problémát, amikor az ONT felé menő porton sniffeltem a forgalmat.

Nem igazán tudom mit tudok tenni. SagemCom 5655v2 a home gw, és SG3G10000604 firmware van már rajta, és így sem működik. Márpedig meg szeretném oldani, mielőtt megszűnik az Invi netem :-)

Őszintén nem is értem, hogy hogyan tud belegányolni a PPPoE headerbe a hgw ilyen módon, ha a PPPoE-t az én routerem végződteti. Szóval az is lehet, hogy nem a hgw-vel van probléma, hanem a BRAS oldalon? De az meg hogy a pékbe rontja el a payload length-et az IP 6in4-be foglalt IPv6-on belüli TCP valamilyen attribútuma alapján, hogy csak a válasz ACK és a tényleges válasz csomagok sérülnek így? Vagy lehet, hogy csak a csomag hosszától függően romlik el?

Bár ahogy írtad, nálad az ONT csere megoldotta a hibát, szóval akkor mégis ONT hiba lehet?

Mindenesetre guglizva az invalid PPPoE payload length kulcsszavakra, azért én is találtam pár bejegyzést, ahol ugyanezt a hibát írják le, ezen a fórum bejegyzésen kívül is, szóval a probléma nem egyedi :-(.

Érdemes bejelentenem a problémát az MT ügyfélszolgálaton? Gyanítom a first line-on túl kellene jutnom valahogy, hogy érdemben tudjak beszélni erről valakivel :-)) pcap file-t tudok prezentálni nekik, amiben egyértelmű a hiba oka.

Szerintem mindenképp érdemes jelezni a hibát és szerintem érdemes azt is elmondani, hogy a dolog nem egyedi és itt ezen a fórumon van róla több infó. Ez szerintem segít átlendíteni az első szintű supporton és egyúttal segít annak is kitalálni mi a fene van aki azátn ténylegesen meg tudja esetleg oldani hiszen így nem veszik el és nem torzul a szakmai infó. Sanszos egyébként, hogy elsőre pikk-pakk le fogják zárni a hibát, de ha nem oldják meg vagy nem adnak érdemi választ akkor a My Telekom (vagy mi a hóhér a neve) oldalra belépve a hibajegyeknél megtalálod és kommenttel újra lehet nyitni aminek biztos örülni fognak de ha szakmailag korrekt meg illedelmes a dolog akkor ez így fer

[OverLord]

Hátha valakinek segít.

Van megoldás a problémára. A Telekom újabb, gigabites, vagy kétgigás kapcsolatát használó optikai végpontjain kell eszközcserét kérni, lásd:

HE.NET IPv6 tunnel IPv4 Hálózaton - cikk alja.

Azt nem tudom, hogy alacsonyabb sebességnél adnak-e ki ilyen eszközt, nekem ugyanez volt a problémám és ez megoldotta.