-
Szeretne hasonló avatart használni? A profilképként felhasználható avatarokat az alábbi linkről tudja letölteni.
-
Tartalmak
51 -
Csatlakozás időpontja
-
Utolsó látogatás
Tartalomtípus
Profil
Fórumok
Blogok
Galéria
Articles
Bejegyzések, amit sipsza posztolt
-
-
27 perce, Gele írta:
Ez hogy deríthető ki? Elismerem kihúzták nálam a gyufát, és kaptak tőlem rendesen. Lehet direkt kaptam ebben a formában a büntit
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,,? -
4 perce, Gele írta:
Bevallom fogalmam nincs hogy van-e. Évek óta az a válasz az ea-től hogy nálam a hiba, és változtassak szolgáltatók akkor lehet megjavul a kapcsolat, gondolom más lesz az útvonal a szerverükhöz. A fifával minden meccs akad, késik, más játék tökéletesen fut online. Igaz azok dedikál szerveren futnak ez meg p2p. De basszus nem már, a 21 században vagyunk ilyen kapcsolatok mellet még van ekkora késés? Persze ahol gond van ki kellene javítani a hibákat.
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. -
dvr camera
itt: Hálózat
22 órája, keraxxx1 írta:Helyben működik már a webes felület . Viszont távolról semmi megnyitottam a portokat a leírás alapján
https://ibb.co/JxKcQ45
https://ibb.co/8XSPPCJ
https://ibb.co/0ZVmqnyPró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
-
8 órája, uzman írta:
Szerintem az afraid.org nem szereti, hogy a kérés és a válasz is ugyanarról az IP címről jön/megy.
Az Ubuntura húzz fel egy helyi dns szervert, ami csak a helyi hálózatot szolgálja ki és minden gondod megoldódik. Forwardernek megadod a hgw címét.
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 semAkkor 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. -
Telekom IPv6
itt: Internet
4 órája, Goodman írta:Aha, rajottem. Most kellett kernem egy prefixet a routeren, es megkaptam DHCPv6-on. De ez igy nagyon erdekes, hogy az ONT-n sehol nem latszik semmi, kvazi nincs is IPv6 cime lathatoan az eszkoznek, de megis.
Szoval ugy nez ki van nativ v6om.
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 delegationA 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. -
4 órája, Invi írta:
Update MSS 1452-vel egy hete jó, ha bármi mást állítunk be lefagy 1 napon belül a modem.
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.
-
8 órája, Invi írta:
Leteszteltük szerver oldalról is. Szóval a kérés kimegy tőlünk a szerver vissza is küldi az infókat, de ha nagyobb csomagokat küld, mint MTU 1500 akkor nem darabolja fel befelé a telekom a modem csak szépen benyeli, a routerünkig már el sem jut. Valami routing probléma lehet ezek szerint ISP oldalon.
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.
-
11 órája, uzman írta:
Szia
Én nem nslookup-pal próbálnám, hanem a https://www.whatismyip.com/oldalon kellene megnézni, hogy a Sagem által kapott IP cím az oldalon látható címmel megegyezik-e.
Ha igen, akkor a https://portchecker.co/ oldalon beírva az általad nyitott port számát, a Check gombra kattintva ellenőrzi, hogy valóban nyitva van-e. Ha azt írja, hogy igen, akkor az eszközeid beállításában lesz a hiba. Ha nem, akkor a Sagem nem nyitotta ki a portot.
Ezzel kapcsolatban sajnos elég sok bejegyzést találtam, hogy többeknél nem megfelelően működik ez a funkció (ezt megerősíteni nem tudom, mert nem ilyen eszközt használok), de ha biztosra akarsz menni, akkor vásárolj egy megfelelő routert és azzal biztosan menni fog a port átirányítás.
@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. -
6 perce, Bppeti írta:
Köszönöm a részletes választ! Az Openwrt firmware-ben a default MTU értékek 1492 a WAN-ra és 1500 a LAN-ra. Mindkettőt felülírtam fixen 1492-re. Így javult a helyzet. A speedtest most 900/800 Mbitet mér a leggyorsabb szerver felé. Még mindig kb 50/150 Mbittel lassabb, mint a Sagemcomról, de ezzel már ki tudok egyezni. MSS-re utalást egyelőre nem találtam, de ennek jobban utána fogok nézni.
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.
-
Telekom IPv6
itt: Internet
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.
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.
-
Telekom IPv6
itt: Internet
@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.
-
Telekom IPv6
itt: Internet
50 perce, btz írta:Szerinted boldog boldogtalan hozzáfér a LAN-odhoz ha IPv6 - ot használsz? IPv6 tűzfalról hallottál már? Ugyanolyan szinten szabályozható hálózatot lehet készíteni IPv6-al, mintha IPv4 lenne. Még portot is lehet nyitni annak az eszköznek, amelyiknek kell, a többit le lehet zárni. Szerinted attól hogy a külvilág felé egyedi címe van az eszköznek ami a LAN-on van, nem lehet központilag tiltani, hogy a portjaihoz kívülről hozzáférjenek? Csúnya hekkerkedés lenne, ha ez így működne.
Maradjunk annyiban, hogy IPv6 - al minden LAN eszköznek lehet egyedi címet adni, a LAN-on lévő eszközök kívülről való elérése ugyanolyan szinten szabályozható, mintha egy NAT mögötti hálózat lenne
+ A NAT magában nem add 100%-os védelmet. A routerem szerint minden eszközömnek van egyedi IPv4 címe, ezért ha nincs más tűzfal szabály megadva és érkezik egy csomag a PPPoE interfészen a 192.168.1.x címekre, akkor vígan továbbítja azokat. Egy rendes ISP persze nem engedi, hogy ilyen történjen, de pl. egy kollégiumi hálózaton megeshet.
Aki magának ír IPv6 tűzfal szabályokat, figyeljen, hogy:
- ne blokkolja a bejövő DHCPv6-ot, különben a router nem tudja megújítani a prefixet
- a hálózat helyes működéséhez engedélyezni kell bizonyos ICMPv6 csomagokat -
Telekom IPv6
itt: Internet
Tudtommal az IPv6 csak a BRAS oldalon van tiltva/engedélyezve, az ONT-ben nem állítanak semmit. Az ONT menüjében nem fog megjelenni IPv6 beállítási lehetőség, de az ezzel kapcsolatos szolgáltatások futnak. Így SLAAC-kel kellene kapnod címet, ha az ONT létesíti a PPPoE kapcsolatot. Ha a Router Advertisementben nincs prefix (vagy egyáltalán nem küld az ONT), hívd fel őket újra.
Ha a routered tárcsáz be:
@ipv6.telekom.hu szerintem már nem él, használd ugyanazt a kapcsolatot, mint IPv4-re. Mikrotiken a PPPoE profilban engedélyezni kell az IPv6-ot, hogy IPV6CP-n kérjen címet (pl.: fe80::b). Ha nem kapsz címet, de packet snifferrel látod, hogy a routered küld IPV6CP kérést, hívd fel őket újra.
Ha eddig megy, DHCPv6-tal a PPPoE interfészen tudsz kérni prefixet. Csak prefixet kérj (címet ne), különben nem kapsz választ. -
Telekom IPv6
itt: Internet
7 perce, vrnagy írta:Koszi. Melyik prefixbol kaptal? Nekem most 2001:4c4e:10c1:1e00:: a prefix, es az elozo korben is a 4c4e-bol kaptam.
2001:4c4e:: . Visszanéztem a logokat, és amióta (január) megy az IPv6, azóta ebből kapok.
-
Telekom IPv6
itt: Internet
3 órája, vrnagy írta:Sziasztok!
Más is tapasztal problémát az amazonos szolgáltatások v6-os elérésével?
Nálam több oldal nem megy v6-on, pl nginx.org, samsung-webform.sprinklr.com
Modem restart után az új prefix sem segít. Más oldalak, pl a google ipv6 betölt gond nélkül. Ipv6-test.com-on max pontot kapok.
Az általad felsorolt oldalakat elérem IPv6-on, de én is észrevettem, hogy július óta az IPv6-os internet elérés nem olyan stabil, mint előtte.
Van egy RIPE Atlas Probe-om, ami pingelget szerte az interneten, és aszerint 5% felett van az IPv6 csomagvesztés. (Érdemes megemlíteni, hogy csak az számít csomagvesztésnek, ha a többi probe nagy része eléri a végpontot, de az enyém nem.)
-
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 -
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.
-
Telekom IPv6
itt: Internet
@blaszlo
Szerintem azért nem kapsz IPv6 címet, amiért eddig sem kaptál: a központ nem ad a Sagemcomnak prefixet, így nincs miből továbbosztania.
Aki részére a központban engedélyezve volt, az a régi firmware-rel is kapott.
A tiltást eddig azzal indokolták, hogy a régi fw nem kezelte rendesen az IPv6-ot, bár ebből én semmit nem tapasztaltam (más igen?).
Lehet, hogy megvárják, hogy az ONT-k nagy része megkapja a frissítést, és utána engedélyezik mindenkinek egyszerre. Az is lehet, hogy újból kell kérni előfizetésenként.Firmware changelog elérhető amúgy valahol?
-
Szia!
Kis infó a Wake on Lanról:
A géped kikapcsolt állapotban lényegében csak azt figyeli, hogy hallja-e a saját MAC címét egymás után ismételve. Neki nem kell, hogy ez a minta be legyen ágyazva egy jól formázott ethernet, IP, UDP csomagba. A beágyazás azért kell, hogy a köztes eszközök (switch, router) továbbítsák neki a mintát.
Ha a felébresztendő és a felébresztő gép egy LAN-on van, akkor elég egy ethernet csomagba rakni a mintát. A cél MAC cím lehet a felébresztendő gép MAC címe, de lehet az ff:ff:ff:ff:ff:ff broadcast MAC cím is. Ha a gép már elég régóta alszik, akkor a switchek elfelejtették, hogy melyik porton van, ezért így, is úgy is broadcastolni fogják a csomagot.
Ha a két gép nincs egy LAN-on, akkor minimum egy IP csomagba kell rakni a mintát. Általában UDP/IP csomagba szokták rakni, hogy kényelmesebben lehessen rá tűzfal szabályokat írni. (TCP erre a célra nem jó, mert sikeres kézfogás nélkül nem küldi el a mintát.)Nézzük mi történik, amikor a Sagemcom az alvó gépnek (legyen 192.168.1.2/24) akar küldeni egy UDP/IP csomagot. Ez a csomag egy ethernet csomagban fog utazni, ehhez tudni kell az cél gép MAC címét. Ha a gép már elég régóta alszik, a Sagemcom ARP (Address Resolution Protocol) táblájában már nem lesz benne a szükséges IP - MAC pár. Ekkor a Sagemcom küldeni fog egy ARP kérést, de ezt az alvó gép nem fogja megválaszolni.
Lehetséges megoldások. Nem tudom, hogy a Sagemcommal bármelyik is elérhető lenne.
- statikus bejegyzés a Sagemcom ARP táblájába: 192.168.1.2 - [az alvó gép MAC címe]
- a 192.168.1.2 helyett a 192.168.1.255-re küldeni a csomagot, így az broadcastolva lesz a LAN-on. Ez biztonsági okokból valószínűleg nem fog menni, hacsak nem veszed fel a 192.168.1.255 - ff:ff:ff:ff:ff:ff ARP bejegyzést.
Nem tudom, hogy a TP-Linkkel miért működött eddig. Ott nem vettél fel statikus ARP rekordot?
Általában a 9-es portot szokták használni a WoL-ra, mert ha broadcastolva lesz a csomag, szeretnénk, hogy a többi gép ne foglalkozzon vele, és a 9-es hivatalos a ne foglalkozz vele port.
-
1 órája, Zölcsi írta:
Sorry, but what is STB?
Set Top Box (in hungarian: TV vevőegység, beltéri egység).
-
Telekom IPv6
itt: Internet
"És a fenti weblapon is világosan le van írva:"
Az IPv6-os hálózatok - Mit kínál a Magyar Telekom? oldalon az is le van írva, hogy a 2001:4c48::/32 prefix alól kapunk majd prefixet. Eközben én a 2001:4c4e:: alól kapok. Nem mintha ennek bármi gyakorlati jelentősége lenne, de így én a többi ottani információt is fenntartásokkal kezeltem. Érdemes lenne kiírni, hogy a Sagemcom még nem támogatott, és nem azért nincs a listán, mert a T akkor még nem is osztogatott ilyen ONT-ket, amikor az oldal utoljára frissítve volt.Csütörtök reggel fél év hibátlan működés után újból megmakacsolta magát a PPPoE szerver. Ma kicserélték a Sagemcomot a régi Huawei-re (nem én kértem a cserét).
Ez egy másik problémámat is megoldotta: HE 6in4 tunnel, TCP kapcsolat megszakad
Azt lehet tudni, hogy az új Sagemcom firmware javítja-e majd ezt a hibát?
Előfizetés átírása két hónap után sem teljes
itt: Számla, módosítás, ügyintézés
Posztolva ekkor: · Szerkesztve ekkor: Szerkesztő: 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:
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:
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ő.