sipsza

Miért kell külön cím is? A /56-os prefixből tudsz osztani magadnak mindenhova. Szerintem koaxon is egy /56-os prefixből kapsz mindent.

@Halacs "ONT csere nem segítene, ezt külön egyeztette a fejlesztőkkel (látta ezt a threadet). Ha nem lenne tiltva területileg az IPv6 akkor menne a nálam lévő ONT-vel is." Az én (megalapozatlan) feltételezésem az volt, hogy ha nincs aktiválva a központban az IPv6, akkor egy új sorozatszámú ONT felregisztrálása aktiválja. Ha a központban minden jó, akkor az ONT nem akadály. "Ezt követően jött az SMS, hogy ők nem találtak a saját hálózatukban hibát, ellenőrizzem a saját eszközeimet." Nem értem ezt a hibajegy lezárási kényszert. Miért nem lehet nyitva hagyni, amíg ténylegesen meg nem oldódik a probléma? Az őszi ETA nagyon kényelmes nekik, mert addigra a lezárt hibajegyedet már meg sem tudod nézni. Nem mintha lenne mire hivatkoznod, mert minden lényeges információt mellékcsatornákon kaptál tőlük. Így majd kezdhetsz mindent elölről. Olyan érzésem van, hogy a Telekomnak az internet csak a webből (IPv4, TCP/UDP, DNS/HTTP(S)) áll. Ha ezeken kívül működik más is, érezd magad megtisztelve.

Nekem 3 hónapig mondogatták, hogy náluk minden rendben. Kértem, hogy nézze meg egy szerelő is, ha már nekem nem hisznek. Ő végül kicserélte az ONT-t (egy teljesen ugyanolyanra), és onnantól ment minden. Azóta többen is megkerestek, akiknél szintén csak az ONT csere volt a megoldás.

@Halacs Igen, az ipv6cp filter mutatná a választ is. Nem tudom, hogy egy sima újraindítás után letölti-e újra az ONT a konfigot. Biztos, ami biztos alapon csinálj egy factory resetet.

@Halacs Az fe80-as címet nem a Mikrotik generálja, hanem a szolgáltatótól kellene kapnod IPV6CP-n (Point-to-Point Protocol IPv6 Control Protocol) keresztül. Futtasd a Tools > Packet Sniffert a PPPoE interface-hez tartozó ethernet interface-en miközben újracsatlakozol. Azt fogod látni, hogy a routered küld egy IPV6CP konfigurációs kérést, de nem kap rá választ. Ha az ONT reset nem segített, kérj ONT cserét.

Szia! Meddig jutottál el? Az első lépések nagy vonalakban: a PPPoE kapcsolathoz tartozó PPP profilban engedélyezni kell az IPv6-ot (use-ipv6 = yes) ezután már a PPPoE interface kapni fog egy v6 címet is, IPv6 > Addresses alatt tudod ellenőrizni, valószínűleg neked is fe80::b lesz DHCPv6-on keresztül kell kérned egy prefixet. Csak prefixet, címet nem, mert különben nem kapsz választ. ebből a prefixből kell címeket osztanod az eszközeidnek Ha a PPPoE interface nem kap címet (nem kapsz választ az IPV6CP kérésre), akkor a T-nél lesz valami. Jelezd nekik, hogy szeretnél IPv6-ot használni. Miután beállították csinálj egy 30+ másodperces ONT resetet. Ha ezután sem lesz jó, kérj egy ONT cserét. Az ONT elvileg nem befolyásol semmit, de az én esetemben a PPPoE szerverük addig nem akarta letölteni az új beállításokat, amíg egy másik ONT-t fel nem regisztráltak.

@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.

Szia! Nem hiszem, hogy találsz ilyen beállítást. Biztos vagy benne, hogy csak a HGW gyorsítótáraz, és pl. az oprendszered nem? Lehet, hogy a HGW nem is a gyorsítótárat használja, hiába nincs interneted. Nálam az ONT akkor is válaszol a DNS lekérdezésekre (nem a cache-ből), ha nincs aktív PPPoE kapcsolat. Az általad említett heurisztika mennyire fix? Lehetne esetleg?: Pingelni a DNS lekérdezés helyett. Egyből egy távoli DNS szervernek küldeni a lekérdezést. Alacsony TTL-lel rendelkező rekordot lekérni, remélve, hogy a HGW tiszteletben tartja azt. Például raw.githubusercontent.com -nál 30 másodperc a TTL, de sok másik CDN esetén is <1 perc. Olyan domaint lekérdezni, ami biztosan nincs a cache-ben. Pl. [minden alkalommal más random string].com, vagy ha az NXDOMAIN válasz nem jó, [minden alkalommal más random string].tumblr.com

@Tim András Nálam optikán a bekötés óta (2016) működik a PPPoE passthrough, IPTV és VoIP mellett, nincs szükség dupla NAT-ra. Api1977 problémáját szerintem VLAN-okkal lehet elegánsan megoldani: nem terheli a router processzorát, mint az IGMP Proxy, mert még a 10+ éves SOHO routerekben is van VLAN képes hardwares switch nem rakok egy olyan eszközt (az STB) a tűzfallal védett belső hálózatomba, ami felett semmi kontrollom nincs kevésbé érzékeny arra, ha a szolgáltató módosít valami beállítást. Semmi sem garantálja, hogy a T holnaptól nem fogja az öt legnézettebb csatorna adását broadcaston küldeni. A fentiek fényében szomorú, hogy a legtöbb SOHO routeren nem, vagy csak korlátozottan lehet hozzáférni a switch/VLAN beállításokhoz a gyári firmwarrel.

@McBelaba Nálam Androidon van egy PPP interface a szolgáltató felől, és a wlan hotspot. Mindkettő ugyanabból a /64 prefixből használ egy-egy címet, és a hotspotra csatlakozott eszközöknek is ezt a prefixet hirdeti ki.

DHCPv6-on szerintem nem fogsz címet kapni, legfeljebb prefixet. Ha cím kell, akkor használj SLAAC-et, mint a Windows és a Debian. Nekem PPPoE-n keresztül, Mikrotik routerrel stabilan megy az IPv6 (IPTV és Telefon mellett). Szívesen segítek, de sok apró beállítás kellhet, ezért jobb lenne, ha valósidőben tudnánk beszélni egymással.

Leellenőriztem az UDP portokat is. Befele blokkolt: 520 - RIP 646 - MPLS LDP Kifele blokkolt: 520 - RIP 646 - MPLS LDP 711 - MPLS Cisco TDP? 1985 - Cisco Hot Standby Router Protocol 3222 - Gateway Load Balancing Protocol 4791 - IP Routable RocE A felsorolt protokollok egy részét a routerem nem is ismeri, de mindegy is, mert még azelőtt nézem csomagokat, hogy a tűzfal vagy egy protokoll daemon elkapná őket.

Köszönöm a választ! Végigmentem a TCP portokon 1-65535 4 különböző helyről: DigitalOcean VPS, U_P_C, egyetemi (HBONE) és céges hálózat. A következő portok egyik helyről sem elérhetőek. Befele: 639 - MSDP 646 - MPLS LDP 711 - MPLS Cisco TDP 7547 - TR-069 CWMP 8085 - DSLForum CPE Management 30005 - TR-069 (nekem másra kell, de gondolom a TR-069 az oka) 51005 58000 Kifele: 25 - SMTP (ezt megértem) 646 - MPLS LDP 711 - MPLS Cisco TDP Érdemes abban reménykednem, hogy kérésre feloldják a befele irányú blokkolást?

Sziasztok! Más sem kapja meg a 30005/TCP-re érkező csomagokat? TCP 30004 és 30006 jó, de a 30005 nem. A mindenkori blokkolt kimenő/bejövő portok listája elérhető valahol? Sagemcom F@st 5655v2 AC ONT-t használok PPPoePassthrough módban, fw: SG3G10000494. Biztosan nem a routerem tűzfal/nat beállításaival van gond, mert még azok előtt, közvetlenül az ethernet interface-en nézem a csomagokat.

Azt azért érdemes lenne megemlíteni, hogy a szolgáltatók nem puszta kiszúrásból nem engedik, hogy saját ONT-t használj. A GPON nem DSL, itt nincs egy dedikált vonalad a központig, hanem van egy gerincvonal, amire több tucat előfizető csatlakozik. A leagázásokat prizmákkal és tükrökkel oldjak meg, nincs semmi aktív védelem. A központi eszköz (OLT) mondja meg az ONT-nek, hogy mikor küldhetnek jelet, hogy egymást ne zavarják. Ha valaki egy inkompatibilis ONT-t próbálna használni, lehet, hogy az egész utcában szolgáltatáskiesést idézne elő. Megjegyzem, nem tudom, hogy mekkora különbség van ONT és ONT között. Tekintve, hogy a Telekom is 2 féle ONT-t használ. Én annak örülnék, ha a Telekom is moduláris CPE-t (pl.: Bell Home Hub 3000) adna. Így akinek nem kellene a körítés (a velük járó bugokkal együtt), annak lenne egy biztosan kompatibilis SFP ONT-je.

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?

Ha a HGW és a STB más alhálón van, akkor elsősorban IGMP Proxyra lesz szükség. Az IGMP Snooping csak a többi eszközt védi a kéretlen multicasttól. @Sanyi85 Ha nem feltétlenül akarod a STB-ot a LAN oldalra rakni, csak nem akarsz egy külön vezetéket húzni a HGW-ből, akkor érdemesebb a router egyik sárga portját átkapcsolni a WAN oldalra, és abba dugni a STB-ot. Nem ismerem a te routeredet, de a VLAN (nem WLAN) vagy a switch beállításokat keresd.

Pontosan mi is akarna lenni ez a bridge mode? Nálam semmin nem változtat, PPPoE Passthrough ide vagy oda. Nekem ezek a beállítások váltak be saját router használatához: - PPPoePassthrough: bekapcsolva - Log-In: üresen hagyva - Password: üresen hagyva - Connection Trigger: manual Nem kellet hívnom az ügyfélszolgálatot, és az újraindítást is túléli.

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

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