sipsza

Tag
  • Tartalmak

    5
  • Csatlakozás időpontja

  • Utolsó látogatás

sipsza a fórumon

  • Rang
    Tudóspalánta
  1. 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?
  2. 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.
  3. 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.
  4. 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
  5. 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