sipsza

Sziasztok! Ide írok, mert sorra fogynak el a kapcsolatfelvételi lehetőségek. Az e-mailre nem válaszolnak, a chatet már az appból sem érem el, a telefonos üsz. által felvett hibajegyet megoldás és értesítés nélkül lezárják, a Telekom üzletben nem tudnak ilyen típusú hibát felvenni. A történet vázlatosan: Július közepe: Telekom üzletben 1 mobil és 3 vezetékes szolgáltatás átíratása a nevemre (korábban is egy néven volt, Magenta1-gyel). Ügyintéző megemlíti, hogy kell 1 nap, mire minden rendszerben frissülnek az adatok. 3 nap múlva így néz ki a Telekom fiókom: A mobil még az előző előfizető nevén, így a Magenta1 sem aktív. Nekem létrehoztak egy MT azonosítót, de csak a net és a vezetékes telefon van a nevemen, az IPTV nem. Ezt jelzem a Telekomnak, ők azt mondják, hogy őnáluk már minden ok (a Magenta1 is), nálam is megjavul majd. A következő 2 hétben már sokadszorra hívom őket. Most is azt mondják, hogy minden rendben, csak várjak. Most mégis kapok egy SMS-t, hogy a Magenta1 aktív lett. A Telekom fiókban megjelenik a Magenta1 box (a mobil nincs benne), nem került a nevemre újabb szolgáltatás. Pár nap múlva megkapom a számlákat (mobil és vezetékes külön). A mobil számla az én nevemre jött ugyan, de a Telekom fiók még mindig a korábbi előfizetőt mutatja. A Magenta1 kedvezményt csak az átírás előttre és az aktivációról értesítő SMS utánra kapom meg időarányosan (vezetékesre és mobilra ugyanúgy). Megreklamálom a számlákat (itt párhuzamosan kezdetét veszi egy 1,5 hónapos oda-vissza) és rákérdezek, hogy miért jöttek külön a számlák. A válasz az, hogy a tört hónapot így számlázzák, de következő hónapban már majd egyben kapom. Augusztusban is gyakran felkeresem a Telekom ügyfélszolgálatot. Az általános hozzáállás az, hogy nem is értik, hogy nekem miért fontos, hogy a Telekom fiókban a helyes adatok jelenjenek meg. Ennek ellenére pár alkalommal belépnek a Telekom fiókomba, és elismerik, hogy nincs minden a helyén, de szerintük ez csak UI hiba. Az ilyenkor felvett hibákat csendben megoldás nélkül lezárják. Megjön a következő havi számla (számlák). (A korábbi korrekciót még nem sikerült teljesen beépíteni.) Felhívom az ügyfélszolgálatot, hogy miért nem egyben kapom a számlákat. Ő megpróbálja összevonni, nem tudja, vesz fel hibajegyet (amibe beleírja, hogy a Telekom fiók még mindig *****ségeket mutat). A hibát lezárják, a telekom.hu-n semmi nem változik, újabb számlát még nem kaptam. Megpróbálkozom az ugyfelszolgalat@telekom.hu -val, mindent screenshotokkal dokumentálva. Kapok egy automata email-t ami részletezi a többi kapcsolatfelvételi lehetőséget, de egy szóval nem említi, hogy a levelem automatikusan a kukában landol. A biztonság kedvéért válaszolok, hogy az e-mail nekem nagyon is megfelel. Ugyanazt az automata választ kapom csak. Megpróbálom a chatet. (Valamiért csak az appból érem el.) Előrelépés! Az IPTV-t most már az én MT-m alatt látom. A mobil előfizetést még mindig a Magenta1 boxon kívül mutatja a telekom.hu és az app is. Időközben megszűnt a telekom.hu-nak a "Beállítások>Kapcsolt előfizetések" menüpontja, ahol eddig az előző előfizető nevét mutatta a mobilhoz. Felkeresném a chatet, de már egy hete nem találom az appban, a telekom.hu-n meg még mindig nem. Amit szeretnék elérni: Egyben kapjam a vezetékes és a mobil számlákat. Ez ugye elvileg már sínen van, de még nem volt alkalmam meggyőződni róla. A mobil előfizetés kerüljön be a Magenta1 boxba, a telekom.hu-n és az appban egyaránt. Valaki nézzen utána, hogy mi ment félre az átíráskor és biztosítson, hogy azokban a rendszerekben is javításra kerültek a helytelenül replikálódott adatok amikre én nem látok rá a telekom.hu-n vagy a számlákon keresztül. Edit: Az igaz, hogy átíráskor törlődnek a @t-online.hu-s postafiókok? Lehetséges megtudni, hogy mik voltak a címek és azokkal új (üres) fiókokat létrehozni? Csatoltam képeket a telekom.hu-ról. A sárga én vagyok, a piros az előző előfizető.

Hogy van-e a közelben szerverük? Nézz körbe egy olyan fórumon, ahol ismerik a játékot, vagy írj megint a supportnak. Itt pl. panaszkodnak egy másik EA játékra, mert messze van a szerver: Where are European servers,,?

Budapesttől ez a szerver 7500 km-re van légvonalban, ezt a fény vákuumban 25 ms alatt teszi meg, oda-vissza már 50 ms, üvegszálban oda-vissza 75 ms. Ez egy elméleti minimum, ami alá akkor sem tudnál menni, ha közvetlen vonalad lenne a szerverhez. Az EA viszont könnyen tudná orvosolni a problémát, ha telepítene pár szervert egy európai szerverparkba. Én nem vagyok meggyőződve, hogy nincs nekik, csak gyanús, hogy egy amerikai IP-t pingeltetnek veled.

A Fifa is ezt a dragonage.gos.ea.com (159.153.64.173) szervert használja? Ez a szerver az USA-ban van, tehát a 115 ms ping nem meglepő. Nincs az EA-nak európai szervere? A "Loss" mező nem azt jelenti, hogy a router elnyeli az átmenő forgalom egy részét, hanem, hogy nem válaszol a neki célzott pingre. Ez nem szerencsés (főleg, ha a többi ICMP csomagot is eldobálja), de nem feltétlenül befolyásolja a játékélményt.

Mobilnet esetén nem csak egy /128 címed van. A szolgáltató felől van egy PPP interface-ed, ezen kihirdet egy /64 prefixet és ebbe a /64 tartományba küldött csomagokat feléd routolja. (Ez persze nem jelenti azt, hogy mindent meg is kapsz, mert lehet a Telekomnak tűzfala) Ezt a prefixet te tovább tudod hirdetni, mint ahogy az Android is teszi, ha mobil hotspotot csinálsz. Bővebben: Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link (RFC 7278)

Próbáld meg úgy, hogy üresen hagyod a WAN Host IP Range mezőket. Ha nem engedi, add meg ezt: 0.0.0.0 - 255.255.255.255

Az afraid.org a kérést egy rekurzív DNS szervertől kapja, nem közvetlenül Dávidtól. @Csordás Dávid Az érintett domain neveket ideiglenesen hozzáadhatod a hosts fájlodhoz a kliensen. - ha a "publikusIP valami.hu" bejegyzés segít, a DNS feloldással van gond - ha az előző nem, de a "helyiIP valami.hu" segít, a hairpin NAT nem megy - lehet, hogy egyik sem Akkor lehetne könnyen segíteni, ha csinálnál egy packet capture-t a szerveren és a kliensen egyidejűleg. Abból látszana, ha csomagvesztés történik, és az is, ha egy szerver lassan válaszol meg egy kérést. Mielőtt ilyet megosztanál, tudd, hogy az könnyen tartalmazhat jelszavakat és egyéb személyes adatot.

Az első hop (fe80::e2ac:f1ff:fe21:1f43) egy Cisco MAC címből generált link-local cím, tehát nem a Sagemcom. A Telekomtól három csatornán kaphatsz IPv6 címet/prefixet: - IPV6CP-n a PPPoE kapcsolat kezdetekor: fe80::d - a PPPoE interfészen folyamatosan érkezik Router Advertisement, ami tartalmaz SLAAC-re használható prefixet (2001:4c4e:6:495::/64). - DHCPv6 prefix delegation A Mikrotik RouterOS jelenlegi limitációja, hogy a Router Advertisementből nyert címeket/prefixeket/route-okat nem tudod megnézni sehol. Egyetlen beállítási lehetőség, hogy letiltod a RA fogadását. Ezt teheted globálisan (IPv6>Settings>Accept Router Advertisements: no), vagy interfészenként (tűzfallal eldobod a bejövő ICMPv6 Type 134 csomagokat). A telekomos IPv6-hoz nem szükséges, hogy fogadd az RA-t, szóval, ha más miatt nincs rá szükséged, nyugodtan letilthatod.

A T még dolgozik rajta, vagy már elengedte a ügyet? Majd megnézem, hogy nálam számít-e, hogy mennyi ideje megy az ONT / PPPoE kapcsolat.

Ezt leteszteltem én is. Ha az IPv4 Don't fragment flag nem volt aktív, 1493<= méretű csomagok feldarabolódtak és megérkeztek hozzám (helyes működés). Ha a DF flag aktív volt, 1493<= csomagok elvesztek (eddig helyes működés), de a router, ami eldobta őket nem küldött ICMP Fragmentation Needed üzenetet a szervernek (helytelen működés). Így a Path MTU Discovery nem volt sikeres a szerver felől. IPv6, 1493<= csomagok esetén a szerver kapott ICMPv6 Packet Too Big üzenetet (helyes működés). TCP esetén az MSS clamping megoldja a problémát (legalábbis a tüneteit), és kliens oldalon megvalósítható, pl.: iptables tudja. Szinten TCP esetén, de a szerver oldalon a Packetization Layer Path MTU Discovery segíthet, de nem olyan gyors, mint az ICMP alapú. Linuxon net.ipv4.tcp_mtu_probing . UDP és a ráépülő QUIC esetén nem tudom, mivel lehetne orvosolni a tüneteket.

@TMZ írta, hogy kívülről elér mindent, tehát nincs CGNAT mögött. Neki NAT loopbackre (=hairpin NAT, =NAT reflection) lenne szüksége. Ezt sok router nem támogatja, mert plusz terhelést jelent a router processzorának és a CPU - switch busznak. Úgy tudom, hogy jelenleg a Sagemcom sem. Saját routerrel (ONT PPPoE passthrough módban) ez is és a ping probléma is megoldható. Mondjuk, jó lenne, ha az ügyfélszolgálat felismerné a problémát, és egyből tudná/merné azt mondani, hogy: az ONT nem tudhat mindent; ez pont olyan, amit nem tud; használj saját routert.

Ha átírod a LAN MTU-t, akkor írd át minden eszközön (számítógép, okos TV, mobil, ...). Ha nem akarsz magadnak a jövőben fejfájást okozni, hagyd 1500-on. A WAN MTU maradjon 1492. OpenWrt-n az /etc/config/firewall-ban szerintem azt fogod látni, hogy az mtu_fix (=tcp mss clamping) már be van kapcsolva a wan zónára, ezért is jobbak az értékek, mint a gyári szoftverrel. Mikori OpenWrt van fent? Ha augusztus előtti build, akkor frissíts, mert abban a TCP MSS clamping csak a letöltés irányban működött (bővebben).

Szia! Szerintem ez részben MTU (maximum transmission unit) probléma lesz. Az MTU két szomszédos router közötti link jellemzője, ami azt mondja meg, hogy maximum mekkora lehet egy ott közlekedő csomag. A két végpontnak (a te géped, és pl. a téged kiszolgáló webszerver) akkora csomagokat kell (ajánlott) küldenie, hogy azok az egyik közbenső MTU-nál se legyenek nagyobbak. A közbenső MTU-k minimuma a Path MTU (PMTU), amit a két végpont időközönként meg szokott mérni (PMTUD: Path MTU Discovery). Közted és a google/speedtest közötti legalacsonyabb MTU-val rendelkező link valószínűleg a PPPoE kapcsolat lesz, aminek egyik végen a te routered van, a másikon a T routere a központban (nem a Sagemcom). Tehát a te számítógéped által indított PMTUD-re kell, hogy a te routered válaszoljon, és az, hogy se a számítógépeden, se a routereden lévő tűzfal ne szűrje ki az ehhez szükséges üzeneteket (ICMP). A PMTUD mellett még létezik a TCP MSS clamping. Ez bár a PMTUD-t nem pótolja, elég a routereden beállítani, és nem kell a bolygók együttállása, hogy működjön. Ha meg kell adnod valami értéket: MTU=1492 byte, MSS=1452 byte.

@btz Igen. PPPoE passthrough nélkül is próbáltam egyszer, de úgy még a pingre sem jött válasz, bár arról szerintem a NAT tehetett. L2TP/IPsec passthrough kapcsolót kerestem, de vagy nem találtam vagy nem segített. @Goodman Ha ránézel az ONT felőli ethernet interfészen a csomagokra, látni fogod, hogy a feléd érkező TCP ACK-okat tartalmazó csomagokban hibás a PPPoE - Payload length érték, ezért a PPPoE kliensed eldobja őket.

@btz "Ha nagyon nagyon kell IPv6 akkor használhatsz tunnel szolgáltatót is hozzá." Ez nem teljesen igaz. A Sagemcom ONT-ben van egy bug (fw: SG3G10000494, SG3G10000604), amitől nem tudod a leggyakoribb tunnel típust használni. Lásd: HE 6in4 tunnel, TCP kapcsolat megszakad @Goodman Ez a "gondot okoz az IPv6 a Sagemcomnál" elég nagy kamunak tűnik. A konkrét tüneteket sosem mondják, és az a pár kiválasztott sem panaszkodik, aki elérte, hogy nála bekapcsolják. A "területen sok gondot okozott" kifogást sem értem, úgy is előfizetésenként kapcsolják be. Júliusban azt mondták (itt is, és az ügyfélszolgálaton is), hogy a következő firmware (SG3G10000604 ??) majd megold mindent. Most, hogy már kint van egy újabb fw, maradnak a régi kifogások.