Hosszú levelezésünk alatt egyszer sem említettem, mert kiment a fejemből. Engem pár hónapja az akkori (hála Istennek már csak emlék) MSI alaplapom Dragon Center vagy mi a tököm nevű szoftvere szívatott meg. Mert hogy volt benne egy olyan LAN vezérlés beállítás, ami lekorlátozta a hálókártya sebességét. Egy mozdulattal kikapcsoltam, attól kezdve jó volt.

Nem lehet, hogy Nálad is valami ilyesmi van, ha nem is pont az alaplap szoftvere, hanem valamilyen másik szoftver/program okozza ezt?

Aquila non captat muscas.

Nem tudom, nem használok semmi ilyet. Majd kicsit lenyugszom és higgadt fejjel átnézek mindent...

nagyon leegyszerűsítve: egyrészt a mobilnet egy osztott közeget használ, tehát eleve nem kapsz fix sávszélességet, hanem a többi felhasználóval osztozol. másrészt amíg a többi szolgáltatónak van egyenként 70-80 MHz használható sávszélessége, addig a diginek 5 (öt) MHz. szóval örülj neki, hogy egyáltalán tudsz rajta torrentezni, mert nagyon nem erre való. egyébként se, de ennyi sávval főleg nem.
egyébként digi mobil topik.

istálló? gazemberség? hupákolás?

Most van.

Revolut meghívó pü-ben

Nem tudom, nem-e az MTU volt elállítva, de CMD alól nyomhatnál egy gyors tesztet: ping prohardver.hu -f -l 1472
Általában mindenhol 1500-ra teszik az eszközöket, de PPPOE esetén látok valami extra 6+2-őt (PPPOE header+protokol), akinél az ONT nincs bridge módban, ott 1492 vagy 1500 van beállítva MTU-nak? (jönnek majd kötni ide is valamikor de én egyből kérném bridge módba)

Nekem bridgben van elejétől kezdve. Holnap reggel megpróbálom a pinget.

A 8 bájt a PPPoE overhead. Telekomnál is Diginél is ennyi, a valódi MTU-d így 1492 bájt.

A Windows-os PING uye minden overhead nélkül adja meg a méretet, tehát ha a -f -l 1472-t használod, akkor az 1500 bájtos IP csomagot jelent (20 bájt IP és 8 bájt ICMP overhead nincs benne az 1472-ben).

PPPoE mellett az MTU-d 1492 bájt, tehát a windows-os ping alkalmazásnál -f -l 1464 -et kell megadni.

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

Ezt az eredményt kaptam:

Pinging prohardver.hu [92.61.114.179] with 1472 bytes of data:
Reply from 192.168.0.1: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 92.61.114.179:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),

Ezt az ONT-be csatlakozva közvetlenül, vagy routeren keresztül kellene futtatnom?

Pinging prohardver.hu [92.61.114.179] with 1492 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 92.61.114.179:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Ez most mit is jelent pontosan?

Azt, hogy nem tudja elküldeni a csomagot mert túl nagy a mérete és fregmentálni kellene de be lett állítva a DF és így eldobja.
Próbáld dchard megoldását
PPPoE mellett az MTU-d 1492 bájt, tehát a windows-os ping alkalmazásnál -f -l 1464 -et kell megadni.

Hello darkness, my old friend...

Azóta sincs.
Kéne tenni valamit, de mit?

[ Szerkesztve ]

Revolut meghívó pü-ben

Ügyfélszolgálat?

Hibabejelentés?

Szia, nem haragszom rád egyáltalán, sőt én kérem elnézésedet hogy sokkoltalak. Remélem, nem szenvedtél maradandó sérüléseket.

Komolyra fordítva a szót, aki az IT-szektorban dolgozik az igyekszik általában az eredeti, angol kifejezéseket használni. Mert nem csak magyarokkal áll ott szóba az ember, mint a prohardveren vagy a DIGI magyarországi ügyfélszolgáltalán.

Hogy rosszul csinálod

Használd a "-f -l 1464" kapcsolót. Illetve ha van saját routered, akkor ellenőrizd, hogy a router PPPoE beállításai között az MTU 1492 bájtra legyen állítva.

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

Nagy nehezen megtaláltam (régen néztem), az advanced fülre kellett ütnöm, különben rejtve van.
A TP-Link routerben ez van: 1480
1480 as default, do not change unless necessary

Ha érted, akkor már elavult.

Köszi, megpróbálom. Véletlenül nem a 1464-et írtam be.

Igen, kicsit szét voltam esve már tegnap, miután kiderült, hogy két hétig a "levegőt boxoltam"...

Ezt az eredményt kaptam:
Pinging prohardver.hu [92.61.114.179] with 1464 bytes of data:
Reply from 92.61.114.179: bytes=1464 time=8ms TTL=58
Reply from 92.61.114.179: bytes=1464 time=7ms TTL=58
Reply from 92.61.114.179: bytes=1464 time=7ms TTL=58
Reply from 92.61.114.179: bytes=1464 time=7ms TTL=58

A routerben az MTU és az MRU 1492 értéken van.

[ Szerkesztve ]

ez így rendben van

Köszi

Tipikus megkeseredett kötekedős kolléga vagy aki bentragadt egy pozícióba 5 éve és nem tud kitörni, ezért a prohardveren kötekszik.

Sok lesz az offolás. Térjünk vissza a topikhoz.

(jaj, bocsánat, tehát a tárgyhoz / témához, nem topikhoz)

Érdekes, én inkább simán igénytelenségnek tartottam az angol kifejezéseidet. Vannak itt igazi szakemberek is, tőlük biztosan nem olvasol ilyeneket. Egyszerűen nincs arra szükségük, hogy ilyenekkel próbáljanak hozzáértőnek tűnni.

Ahogy érzed. Szép napot Viktor.

Aha.

Gondoltam tudod, hogy miért akartam 1472-re pingeltetni veled, de bocsi, hogy nem fogalmaz akkor világosabban. De remélem azóta hasít a net ott!

Ami engem érdekelt: "For PPPoE subscribers, the PPP MRU or PPP MTU size can be greater than 1492 bytes if the PPP-Max-Payload tag is received in the PPPoE Active Discovery Request (PADR) packets."
Ezért kérdeztem első körben mi van az ONT menüjében, akinek router mód üzemel, a matek még megy természetesen, de köszönöm azért, itthon nem is számítottam többre az 1492-nél. Pfsense rendszer (a routeremen) elsőre bugos volt LAN oldalról, de átállítottam még ott is az MSS értékkel együtt, már csak digis net kellene tesztelni (az MSS=maximum segment size a legnagyobb TCP csomag méret, 1492-40, bár pfsense ezt magától levonja, 1452-el nem túl stabilak a tesztjeim).

Hát ez már nem az én szintem...

1452 nálam az MSS clamping, és minden jó.

Switch Tax

lehet én nem értek valamit, de miért -40? ha mtu routerben 1492 akkor abból -28 a IP/ICMP header miatt, ezért pingelünk 1464-el. ha neked 1452-vel okés csak, akkor valószinüleg 1480-ra van állítva az mtu a routerben.

[ Szerkesztve ]

Azért mert itt le kell vonni az IP headert ami 20 bájt, illetve a TCP headert is ami még 20 bájt.

Rendes nevén TCP MSS clamping.

szerk.: Az ICMP header csak 8 bájt.

Azaz:

ICMP: 1492 -20 -8 = 1464
TCP: 1492 -20 -20 = 1452

[ Szerkesztve ]

Switch Tax

köszi, így már világos

Annyinak kell lenni, csak elsőre nem olvas pfsense alatt a beadott érték alá: If a value is entered in this field, then MSS clamping for TCP connections to the value entered above minus 40 (TCP/IP header size) will be in effect.
Szóval így duplán lett levonva elsőre, mivel én is minuszoltam.

Azt a kérdést kellett volna feltenned, hogy a Digi optikán támogatja-e a baby jumbo frame-et, és akkor rögtön megkaptad volna a megfelelő választ: nem. Egyébként a Telekom sem.

A jól működő MSS clamp-hez a WAN MTU-t (ebben az esetben a PPPoE kapcsolatét) kell helyesen beállítani, utána jól fog működni. Ha nálad 1492 bájtos MTU mellett szarul működik, akkor reszelgetni kéne még picit a pfsense-et, vagy más probléma van.

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

Az elnevezésben nem voltam biztos, de igen láttam, hogy pl. UK ISP által volt/van baby jumbo.
MSS opció külön is adja, oda írtam be levont érték, de rájöttem azt ő levonja magától (elsőre 1412-re került így de kibogoz már).

Nem teljesen ország specifikus egyébként, hogy van-e vagy nincs. Tudok neked mutatni nem egy olyan ONT vendort (nem csak kínait), ahol még a legfrissebb 2020 júliusi firmware-ben sincs még baby jumbo támogatás sem a GPON interfészen... Mi sem tudtuk bevezetni többek között emiatt.

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

Üdv,
Érdeklődnék, hogy mennyire macera mostanában a digi-nél való bekötés kérése egyáltalán?
Még először több mint 2 hónapja töltöttem ki a netes dolgot, viszont mivel az ott látott max netet kértem (500as) kaptam egy emailt, hogy 15 napon belül megnézik az nálam egyáltalán működik-e. Na most ez volt 2 hónapja, vártam vele kb. 3-4 hétig majd újra csináltam a netes balhét amivel vártam 2 héttel ezelőttig amikor is felhívtam őket és végül is kaptam egy ugyan olyan emailt amit eddig, de ezt most telefonos ügyintézőtől.
Igazából nem tudom, hogy érdemes-e most bemennem esetleg ügyfélszolgálatra ami itt van alig 500méterre.
Értem én, hogy most van más szolgáltatónál gond és új előfizetőkre sor vár vagy valami de kb. 2 hónap+ után még ott tartok, hogy majd szólnak 15napon belül, hogy talán tudnak jönni

[ Szerkesztve ]

Azt kell lásd, hogy nálatok fttb hálózat van (ez a max. 500 Mbps-ból derül ki), amit éppen mostanában építenek át ftth-ra (jelenleg max. 1000 Mbps).
Ezért nagyon nem kapkodnak az új fttb ügyfelekért, mert pont az átépítés miatt kevés a bekötő emberük, ráadásul annak majd néhány hónap/fél/egy év múlva vissza kell mennie ugyanoda és át kell kábeleznie a friss bekötést. Ez jellemzően az új ügyfeleknek sem jó, hiszen kábelezés szempontjából nem mindegy, hogy egy-egy ethernet-telefon-koax jön be (fttb), vagy egy darab optikai kábel (ftth).

érdemes bemenni, a diginél valami furcsa okból kifolyólag a személyes ügyfélszolgálat hatékonyabb, mint a telefonos meg a levelezős.

istálló? gazemberség? hupákolás?

Csanádpalota–Kövegy, helyközi optikai hálózat - Invitel
Úgy gondolnám, hogy az Invitel nem épít már hálózatot csak a DIGI.

Ezt én értem de akkor inkább állítanák át úgy, hogy most nincs fél évig itt digi új előfizető számára mint sem, hogy 2hónap után ott tartok, hogy nem jelentkeznek. Megpróbálom az irodát, hátha az segít vagy megmondják, hogy most ne akarjak digit.