Új hozzászólás Aktív témák
-
vargalex
félisten
Viszont az NMHH eszközt most a routere elé kötötte, ami ugyan úgy 50%-os sebességet mér...
Illetve írta a kolléga, hogy bridge módba állítás után rövid ideig megvolt a sebesség.
#2909 kutga: a kérdés inkább az, hogy ha most router módban használnád, akkor meg lenne-e a sebesség. Persze lehet, hogy a Telekom esetében ez mindig az ügyfélszolgálat felhívásával jár...
-
vargalex
félisten
A szolgáltató nem rázhat le azzal, hogy a garantált sebesség megvan. A szolgáltatónak kell bizonyítani, hogy a kínált sebesség elérhető az előfizetőnél legalább bizonyos időszakokban és soha nem esik a garantált sebesség alá. Az viszont egyáltalán nem elfogadható, ha soha nem érhető el.
Jól értem, hogy router módban a direktbe rá kötött PC-n sincs meg soha a sebesség?
Az NMHH-s mérőbox mért már valamit? -
vargalex
félisten
Érdekes, hogy valameddig megvolt a gigabit. Azóta sincs meg soha a sebesség? Újraindítás (HGW, router) után sem?
Az hülyeség, hogy a HGW bridge módban nem szolgáltat adatot részükre. Ugyan úgy kell, hogy lássák a jelszinteket, egyebeket. Az lehet, hogy a rá csatlakoztatott eszköz linksebességét nem látják. Persze, mivel megvan az 500 Mbps, így biztosan legalább gigabit.
Az szerintem egy másik bénaság, hogy bridge módban ezeket állítani lehet egyáltalán... -
-
vargalex
félisten
Ha azt akarod, hogy a te eszközöd (is) tűzfalazzon, akkor LAN-WAN. Ekkor tényleg minden úgy fog működni, mint eddig.
Ha azt akarod, hogy a te eszközöd ne tűzfalazzon, akkor LAN-LAN. Ekkor viszont (és az előbb rosszult írtam), a mérőeszköz egy IP kérés esetén DMZ-be teszi az aktuális IP-t (azaz kívülről minden hozzá érkezik). ebben az esetben ez nem garantálható, hogy a routered lesz.
Szóval, ha biztonságra mész, vagy van olyan szolgáltatás, ami miatt a saját routeredben port továbbítás van beállítva, akkor LAN-WAN kösd össze.Egyébként milyen routered van? Milyen firmware-val? (Csak a sebesség problémád miatt kérdezem.)
-
vargalex
félisten
Az NMHH eszköz ebben az esetben a 192.168.199.1-es tartományból fog IP-t osztani. Mindent forward-ol arra az eszközre, ami először IP-t kér tőle. Azaz a te esetedben minden külső próbálkozás (elérés) a saját routeredre lesz irányítva. Így továbbra is mindent el tudsz érni kívülről, mint eddig is. Arra kell figyelni, hogy ha DDNS-t használsz. akkor a frissítő eszköz (jellemzően a saját routered) ne a WAN címét, hanem a valós publikus IP-t írja a DDNS-hez.
-
vargalex
félisten
Docsis hálózat esetén gyakran előfordul, hogy másik MAC című eszköz csak akkor kap IP címet, ha a modemet (HGW-t) újraindítja a felhasználó.
Esetedben, ha ezt nem végezted el, akkor valószínűleg a mérőeszköz nem kapott semmilyen IP címet. Persze az üzemmód váltáshoz újra is kell indítani a mérőeszközt. Működés alatt nem próbálja újradetektálni a WAN kapcsolat típusát.Ha a mérőeszköz nem kap IP címet, a saját webes felületét akor is eléred a http://192.168.199.1 URL-en, ahol megnézheted a logokat, illetve a detektált kapcsolat típusát, stb.
-
#2889
vargalex
félisten
Alteran-IT
#2888
vargalex
félisten
válasz
Alteran-IT
#2888
üzenetére
Na igen, azokkal a torrentezőkkel, akik nem limitálnak és NAS-on, vagy szerveren tolják, nem tudsz mit kezdeni. Mondjuk, ha limitálják a sávszélességet, akkor sem feltétlenül elég az uplink, csak több felhasználó tömi ki.
-
#2879
vargalex
félisten
enginev3.0
#2878
vargalex
félisten
válasz
enginev3.0
#2878
üzenetére
Miért szégyen? Az NMHH mérő szervere a BIX-ben van. A Telekomnak van a BIX felé valamekkora sávszélessége, legyen X Mbps. Van Y előfizetője. Az Y előfizetőnél Z a maximális feltöltési sebesség. Elég könnyen belátható, hogy X egész biztosan kisebb, mint a Z-k összege. Ezért osztott a közeg. Sőt, szinte biztos vagyok benne, hogy az X kisebb, mint a garantált sebességek összege. Ezt pedig megoldják forgalom priorizálással. Ennek semmi köze az átviteli közeghez...
A szolgáltatót tudomásom szerint akkor vonhatja felelősségre a hatóság (büntetheti meg), ha nincs is olyan időpillanat, amikor a maximális sávszélesség elérhető lenne.
-
#2877
vargalex
félisten
enginev3.0
#2876
vargalex
félisten
válasz
enginev3.0
#2876
üzenetére
Hát, a 700 Mbps-es feltöltéssel nem hiszem, hogy kezdene bármit is a szolgáltató. Hiszen osztott közegről beszélünk, ezért is van a garantált sebesség.
Én mondjuk ilyen sebességnek veszettül örülnék, nálam 500 Mbps / 22 Mbps a maximális sebesség One-nál (volt Vodafone, illetve előte UPC). -
#2875
vargalex
félisten
enginev3.0
#2874
vargalex
félisten
válasz
enginev3.0
#2874
üzenetére
És milyen értékeket mér? Nem csak ütemezett mérések lehetségesek, hanem az eszköz webes felületén tudsz azonnali mérést is indítani.
-
vargalex
félisten
válasz
draco31
#2866
üzenetére
Az előfordulhat, de alapesetben nem kellene jelezned, hiszen tényleg visszajut a futártól hozzájuk az infó.
#2867 enginev3.0: Működni működik a saját router mögött is, de nem teljesen szabályos, hiszen mérés alatt akkor nem tud az eszköz a többi LAN porton zajló forgalomról, így torzulhat a mérés. Az viszont szabályos, ha a saját routered után kötöd és az összes vezetékes eszközödet átrakod az NMHH eszközre. Számodra teljesen változatlan lesz minden, hiszen ilyenkor a mérőeszköz switch módba vált, azaz minden eszközödnek a saját routered fog továbbra is IP címet osztani és csak 1 NAT-olás lesz.
A visszaküldésről nem tudok semmit, nekem nincs ilyen eszközöm. A szerződésben nincs meghatározva minimum időtartam?
-
#2865
vargalex
félisten
enginev3.0
#2864
vargalex
félisten
válasz
enginev3.0
#2864
üzenetére
Miután a futár visszavitte az aláírt papírokat (legalábbis emlékeim szerint van ilyen), azaz értesülnek róla, hogy megtörténi a kézbesítés, néhány napon belül rögzítik a rendszerbe az eszközt, ami így be tud jelentkezni és feladatokat is fog kapni.
-
#2852
vargalex
félisten
Alteran-IT
#2850
vargalex
félisten
válasz
Alteran-IT
#2850
üzenetére
Wifi monitorozás: detektálja és folyamatosan figyeli az előtte (pl. éppen a HGW által), de azonos hálózatba tartozó wifi forgalmat azért, hogy egy esetleges mérést meg tudjon szakítani. Ugye pl. HGW esetén hiába kötöd be az eszközt szabályosan - azaz minden vezetékes eszközöd azon megy keresztül - a wifi nem fog rajta keresztülmenni. Viszont így a párhuzamos wifi forgalom torzíthatná a méréseket.
Dupla NAT: ha az előírásoknak megfelelően kötöd be, akkor nincs dupla NAT, ugyanis az eszköz érzékeli, hogy ő egy privát IP címet kap, így átkapcsol bridge (switch) módba. Önmaga ebben az esetben nem fog címfordítást végezni.Valóban anno a Samknows is TP-Link TL-WDR3600-okat osztott, ahogy az NMHH is az akkori csúcs otthoni netekhez (a projekt indulásakor még 120 Mbps letöltési sebességű volt a legmagasabb előfizetés), viszont a későbbi gigabites netekhez - ahogy írtam is - olyan eszköz beszerzése volt szükséges, amely képes NAT-olni és önmaga megmérni is a gigabites sebességet. Ez az igény már 2018-ban megjelent, akkor pedig erre valójában csak az
mvebu(Marvell Armada) architechtúrájú eszközök voltak képesek. Ezekből pedig csak a Linksys WRT1900AC, majd kicsivel később a WRT3200ACM volt adott. Mire a fejlesztés elkezdődött, a WRT3200ACM már a piacon volt, így az volt a nyilvánvaló választás.
Az, hogy a TP-Link-nek (és egyéb gyártóknak) voltak routerei, amelyek hardware NAT-al képesek (voltak) "átvinni" gigabites sebességet, semmit nem jelent. Több okból is:- maga az eszköz csak HW NAT-al képes a gigabites átvitelre, önmaga egyáltalán nem képes azt kimérni (márpedig ugye jelen esetben a mérés magán az eszközön fut)
- több típus nem támogatott az OpenWrt által (így ezek ki is estek, mert OpenWrt alapú az NMHH firmware is, ahogy a Samknows is)
- OpenWrt által nem volt támogatott (és nagyjából a Mediatek-et kivéve most sem) a HW NAT, így egy esetleges router üzemmódban a felhasználó által elérhető sebesség is "sérült" volnaAz egyedi gyártás pedig draco31 kolléga által vázolt esetek miatt nem biztos, hogy megérné...
-
#2849
vargalex
félisten
Alteran-IT
#2848
vargalex
félisten
válasz
Alteran-IT
#2848
üzenetére
Nem nagyon tudnak áttérni Raspberry Pi szerű eszközre, mert:
- olyan eszköz kell, amin nagyon egyszerű módon (értsd: pl. kicseréled a memóriakártyát) nem tudod lecserélni az NMHH firmware-t
- mindenképpen itthon beszerezhető legyen
- mivel hivatalosan a vezetékes eszközök rajta kell átmenjenek, ezért minimum 1 WAN és 4 LAN port kell, hogy a felhasználónak ne legyen kényelmetlen (pl. aki csak szolgáltatói HGW-t használ)
- a wifi monitorozás miatt kell, hogy legyen legalább 2 sávos wifi
- elég erős SoC kell legyen benne, hogy képes legyen átengedni is és megmérni is a gigabites sebességet PPPoE üzemmódban is
- az első ponttal összefüggésben: lehetőleg dobozba szerelt, szétszedéshez legalább csavarozást igényeljenBiztos van még más is.
-
#2847
vargalex
félisten
Alteran-IT
#2844
vargalex
félisten
válasz
Alteran-IT
#2844
üzenetére
Egész pontosan Linksys WRT3200ACM.
-
vargalex
félisten
Szerintem csak annyit tudnak mondani, hogy az eszköz forgalmi limit túllépés miatt megszakította a mérést.
Most nézem, hogy forgalmi limit túllépés esetén mégis kiderül a logból az általuk beállított érték. Ugyanis ilyenkor az eszköz ír egy ilyen logot:Limit túllépés. Limit: xxx bytes/sec, Traffic: yyy bytes/secMajd a következő log:
Measure script killed.Az
xxxaz általuk beállított értékből számított megengedett forgalom másodpercenként, azyyypedig az eszköz által érzékelt "párhuzamos" forgalom.Remélem azért nem hivatkoztál rám a levélben...
-
vargalex
félisten
Az a kérdés, hogy a központ milyen limitet küld le az eszköznek. A baj az, hogy ezt nem írja ki a logba az eszköz. Ugye, ha pl. beállítanak 200 MB limitet (10 percre vonatkozóan), azt az eszköz visszaosztja másodpercre. Azaz azt mondja, hogy ha a nem általa generált forgalom (és az a baj, hogy itt a lokális wifi forgalom is beleértendő) meghaladja a 2,66 Mbps-t bármikor is a mérés alatt, akkor megszakítja azt. Persze ezt a 200 MB-ot csak példaként írtam, nem tudom, hogy mekkora értékkel dolgoznak valójában.
-
vargalex
félisten
Nem úgy értettem, hogy más IP címet kap az eszköz. Hanem, ha pl. jelenleg 192.168.1.100 a címe és mondjuk 48 óra a lease time, akkor ha a hálózati kapcsolat (fizikai) nem szakad meg, akkor őt 24 órán keresztül senki nem fogja értesíteni arról, hogy te közben a 192.168.1.50-et rendelted a MAC címéhez. Így működik a DHCP protokoll. Először a lease time felénél fog újra a szerverhez fordulni egy DHCP renew-al.
A weboldalon indított mérés természetesen nem tudja figyelni a párhuzamos forgalmat, így nem is szakítja meg azt soha.
-
vargalex
félisten
És a .100-as IP-n (vagy ugye a portálon megjelenő iframe-ban) megjelenik a lokális webes felület? Ha igen, akkor ezt az IP címet kapta.
A 192.168.199.1-es IP-n csak akkor érhető el az eszköz, ha nincs WAN kapcsolata, vagy a WAN portra publikus IP címet kap, illetve ha PPPoE a mögötte felépülő kapcsolat. -
vargalex
félisten
Mi az, hogy DHCP-n nem kap IP címet és mégis küldi a 9-es státuszt (azaz forgalmi korlát túllépése)? Ez elvileg azt jelenti, hogy a központban beállított mértékű forgalmat túllépte az eszköz a mérés alatt. Szóval, ha ilyen státuszú méréseket látsz, akkor élnie kell az eszköznek és kapcsolata is kell, hogy legyen.
Hogy van bekötve nálad az eszköz? Ha saját router után, akkor ott nem látod, hogy milyen IP-t kapott? A profil oldaladon a Mérőbox oldala gombra kattintva nem jelenik meg a lokális felület (saját LAN-odból próbálva)? -
vargalex
félisten
Ez így nagyon érdekes. Ugyanis a hiba szerint szerver oldalon nem tudta beszúrni a mérési eredményt, mert latency-nek (delay) NULL-t akarna beírni, viszont NOT NULL constraint van a táblán. Azonban az is látszik, hogy a mérést megszakította az eszköz limit túllépés miatt, ezért 9-es státuszt ("forgalmi korlát túllépése (a mérés közben az adatforgalom meghaladta a feladat végrehajtása esetén elfogadható mértéket, ami jelentősen torzíthatja a mérési eredményt") küldött és ilyenkor 0-ás mérési eredményeket küld be. Úgyhogy ez szerver oldalon nincs jól kezelve...
-
vargalex
félisten
Sajnos a wifi scan teleszemeteli a logot, így ott nem igazán látható, csak éppen a "hibás mérés" időpontjában.
Ugye 0 elméletileg akkor lehet a mérési eredmény (de még egyszer mondom, hogy nem kellene, hogy lásd a grafikonon), amikor hibára fut a mérés, vagy nem ad vissza semmilyen eredményt az eszköz, esetleg nem is kerül kiosztásra a megadott időablakban a mérés.
Mondjuk nálad az 5-ös státusz az ugye egyébként hibás mérést jelent, mert nem a szolgáltatódhoz tartozó IP címről érkezett az eredmény. A böngészőben a Fejlesztői eszközökben (F12) a Network (Hálózat) fülön a
series_speedhívás eredményeként kell, hogy lásd aJSON-ben ezeket a 0-ás eredményeket is. Vagy egyszerűen a Highchart jeleníti meg hibásan. -
vargalex
félisten
válasz
DaM_HuN
#2794
üzenetére
De, figyeli a box az átmenő és wifi forgalmat (ha úgy van bekötve), csak azért ennél jóval nagyobb sávszélesség használat esetén szakítja meg (vagy nem indítja el) a mérést (ha úgy konfigurálják egyáltalán a méréseket, mert természetesen akár úgy is beállíthatják, hogy ezt ne vegye figyelembe).
A weboldal sajnos olyan szempontból tényleg "béna", hogy szerintem kliens oldalra lehozza az összes mérési eredményt és úgy jeleníti meg a grafikont.
Az azonnali mérést le lehet scriptelni, hiszen ez egy weboldal, a hívásokat ki tudod nézni a böngésző forgalmából.
A firmware cserével viszont óvatosan (tudom, csak vicceltél), mert az NMHH esetén szerintem soha nem kerül a tulajdonodba a box, nem úgy, mint a SamKnows-nál.
-
vargalex
félisten
válasz
DaM_HuN
#2792
üzenetére
Miért akarsz a boxon mérni? Azonnali mérést tudsz indítani a box webes felületén, így az pl. curl hívásokkal le is scriptelhető. De ugye ennek lehet az az eredménye, hogy éppen fut egy sebességmérés, vagy nem elérhető a szerver, stb. Ráadásul ott ugye a háttérben elindítja a sebesség mérést és vár annak a kimenetére. Tehát ezt neked is meg kell tenned.
Az azonnali mérések hatósági kérésre nem kerülnek be sem az eszköz logjába, sem a szelessav.net-re (hiszen ez nem egy előre tervezett mérés, nem is veszi figyelembe, hogy közben forgalmaz-e a felhasználó, stb.)Az ütemezett mérések azért nem pontosan ugyan akkor indulnak, mert ugyan van egy időablak, de figyelembe veszi, hogy az utolsó 10 percben te mennyit forgalmaztál, van-e szabad szerver kapacitás, stb. Illetve elképzelhető az is, hogy az így elindított mérést megszakítja a box, mivel te elkezdtél közben forgalmazni. Ezért lehet időben eltérés közöttük.
De egyébként mi a célod? Csak az, hogy ellenőrizd, hogy van-e neted?
Asztali és mobil app pedig azért nincs, mert nem kérte a hatóság, illetve inkább azt kérte, hogy a weboldal legyen asztali és mobil böngészőben is használható. (Tehát senkinek nem tört bele semmibe a bicskája.)
-
vargalex
félisten
válasz
DaM_HuN
#2790
üzenetére
Az eszközön authentikáció nélküli webes felületen látod a méréseket. A letöltött html-t egy scripttel nem nagy mutatvány feldolgozni... Akár csak az utolsó mérést kiszedni belőle. Egyékbént a /tmp-ben vannak a nyers adatok, de ahhoz nem férsz hozzá, így marad a html parse-olás.
-
vargalex
félisten
válasz
dethroner
#2788
üzenetére
Akkor a 10.x.x.x IP cím az valami szolgáltatói DNS szerver lesz, ami a log fülön látszódhat.
Akkor jól értem, hogy a hardveres és a szoftveres mérés IP címei ugyan abból a tartományból vannak (109.61.x.x), csak a végük különbözik? A géped nem épít fel véletlenül egy másik PPPoE session-t és igazából ő is kap egy publikus IP-t? -
vargalex
félisten
válasz
dethroner
#2786
üzenetére
A 10.x.x.x az egy privát IP tartomány. Azaz a szolgáltatód NAT-ol, ha nincs a mérőbox előtt másik eszközöd.
A publikus IP-t (ami a szolgáltató valamelyik eszköze lesz) az azonnali mérés eredményénél láthatod, valószínűleg ezt a mérést fogod látni a webes felületen is. Ha ez eltér a software-os méréstől, akkor a szolgáltató más kijáraton megy a software mérők és más a hardware mérők felé. -
-
vargalex
félisten
válasz
dethroner
#2769
üzenetére
Az NMHH-s webes méréseket bejelentkezve készítetted? Mert, ha nem, akkor mindenképpen írd meg nekik, hogy a szoftveres mérős is azonos értékeket produkál.
Hidd el, a többi szolgáltató mérője sem "rontja" más hálózatból érkező mérések eredményét. Csak egyszerűen egy szolgáltató saját hálózata valahol véget ér, valamilyen eszköz végződteti, ami valamilyen port sebességgel (vagy inkább több porton) csatlakozik a többi hálózat felé. Ez márpedig be tud dugulni, ha nem jól van méretezve.
-
vargalex
félisten
válasz
dethroner
#2767
üzenetére
Ahogy írtam, ha az NMHH szoftveres mérése is kevesebbet mutat, akkor a szolgáltatód nem tud akkora sebességet az NMHH hálózata felé/felől, mint az ígért sebesség. A mérőbox a gépen mért mérésekbe nem szól bele, hacsak nem párhuzamosan kötött és megy közben mérés.
A szerelő is megerősített abban, hogy csak a saját hálózaton garantálják a sebességet (ezért ott is mérnek). -
-
vargalex
félisten
válasz
dethroner
#2757
üzenetére
Az a baj, hogy a szolgáltató általában a saját hálózatán szokta csak garantálni a sebességet. Nyilván ez valamilyen szinten érthető is (lenne), hiszen csak arra van ráhatása. Viszont, ha az uplinkje mondjuk 1 Gbps (vagy akár 10 Gbps), akkor az hálózaton kifelé biztosan be tud dugulni.
-
vargalex
félisten
válasz
dethroner
#2753
üzenetére
Simán elképzelhető, hogy nem megfelelő paraméterezésű nálad ez az új mérőscript. Ugye ebben a verzióban megpróbálnak viszonylag kevés szálon mérni (20, 25, vagy 30), ehhez viszont egy előmérést használnak. Ez lehet, hogy valamiért nem jó nálad, mert esetleg a szolgáltatód lassan engedi fel a teljes sebességre a vonalat. A korábbi script több, mint 100 szálon mért, ha jól emlékszem.
Az mit jelent, hogy az NMHH oldalán csináltál egy mérést? A webes felületen, vagy az eszközön?
-
vargalex
félisten
válasz
DaM_HuN
#2746
üzenetére
Szia!
Gondolom kivették a táblázatból a 0 értékeket, mert nem mutatott jól. A frontend fejlesztést nem követem...
#2747 dethroner: Ahogy nézem, az a rendes körülmények közötti érték valami olyan, ami a sorbarendezett mérések közül a 90% körüli értéket veszi.
Azaz neked sorbarendezi a 24 mérésedet és a 21. és 22. helyen álló mért értékek átlagát veszi. Legalábbis első ránézésre ezt csinálja és nem azt, hogy 90%-ban mi az érték...
-
vargalex
félisten
Sz mindegy, hogy publikus-e az információ, de kliens oldalon is látszik, hogy a szerver várakoztatja a mérést (indulásnál), ha úgy ítéli meg, hogy erőforrás korlátba ütközhet.
Persze, mivel az ISP kiderítheti a merő szerverek IP címeit, így bőven gyorsíthat, vagy lassíthatja is a merésen (pl. forgalom priorizálással). Utóbbi állna érdekében, hiszen számára a lényeg az, hogy a hálózata képes az adott sebességre. Arra nem kötelezi semmi, hogy ezt a teljes szolgáltatási időben, minden irányban tudnia is kell… -
#2734
vargalex
félisten
aprokaroka87
#2733
vargalex
félisten
válasz
aprokaroka87
#2733
üzenetére
Ha a hardware-os mérésre gondolsz, akkor nem igazán. Az eszköz csak a központi szerverrel kommunikál. Kulcsos titkosítás, radius cert auth, minden van. Vagy mi pontosan az elképzelésed?
-
vargalex
félisten
válasz
dethroner
#2725
üzenetére
Az SSH az egy szerver szolgáltatás. Default-ban a 22-es porton hallgat, ott fogadja a kapcsolatokat az SSH kliensektől. Persze átkonfigurálható, átrakható más portra. Ha eddig azt sem tudtad, hogy mi ez, akkor nyilván nem fog zavarni.
Viszont azt mindenképpen jelenti, hogy a szolgáltatód kifelé sem enged minden forgalmat, azaz erősen szűr. Nyilván a 80 (HTTP) és a 443 (HTTPS) engedve van, hiszen a többségnek arra van szükséges. De te el akarhatsz érni bármilyen más porton futó külső szolgáltatást, akkor pedig már nem jó, ha a szolgáltatód azt nem engedi. -
vargalex
félisten
-
vargalex
félisten
válasz
DaM_HuN
#2705
üzenetére
Szia!
Ezeken az Asus routereken elérhető az SSH, így én összehasonlítaném az
nvram showparancs kimenetét a két állapotban.
Azt látom, hogy elvileg az első kettő BroadCom SoC-al, a harmadik viszont MT7621-el szerelt. Így csak a firmware-ban található "valami" lehet ludas.Egyébként nem azt írtam, hogy "megakad a mérés", hiszen az végig megy. Nincs egyébként valami QOS bekapcsolva, ami automatikusan detektálná a sávszélességet és esetleg éppen ez kavar be? (Mondjuk ennek az
nvram show-ból ki kellene derülnie.)A mérőboxon UPnP kliens sincs, így UPnP kérést sem küld a routernek.
-
vargalex
félisten
válasz
DaM_HuN
#2703
üzenetére
Az egészen biztos, hogy a mérőeszköz semmilyen beállítást nem eszközöl (és nem is tud) az előtte lévő eszközön. Így az, hogy kihúzod a mérőeszközt és továbbra sem jó a sebesség, a saját router, vagy a szolgáltató hibája. Esetleg arra tudok gondolni, hogy a túl sok szálon történő mérés (a gigabites kapcsolatokon 100 fölötti szálszámmal mérnek általában a Telekomos optikán jellemző magas késleltetés miatt, de ez a mérőscriptben látszik is) megakasztja az előtte lévő eszközt. Persze, ennek is illene egy restart esetén rendeződni, de nem ismerem az Asus firmware-okat (a reset az NVRAM-ot törli, oda csak a router ír).
-
vargalex
félisten
-
vargalex
félisten
Nézd meg a speedtest.net oldalon is, hogy mit mérsz ilyenkor, mert az legalább ugyan úgy a bix-re mér. Illetve mi a mérő script? Az NMHH bix hálózata felé lehet valami gond, legalábbis a 133-as latency-ből ezt gondolom...
-
-
vargalex
félisten
Szia!
Olyan, mintha a link sebesség esne vissza 100 Mbps-re. Esetleg megpróbálhatsz egy kábel cserét. A link változásnak elvileg látszania kell a log-ban (bár, az lehet, hogy csak a dmesg-ben látszik, ami ugye a felületről nem látható), de ugye oda nagyon gyakran ír az eszköz, így a 16 KB hamar kipörög...
-
vargalex
félisten
Központban ütemezik a méréseket, jelenleg akkor ezek szerint óránként mér. Elvileg van egy utolsó 10 percben mért sávszélesség, ami fölött nem mér, de a mérés elvégzésére van egy előre beállított intervalluma (ez lehet akár 1 órás is). Ráadásul ezt a korlátot lehet, hogy elég magasra állították, mivel a felhasználó által generált forgalmat is beleszámolja a mérésbe...
-
vargalex
félisten
Igen, ha a Linksys-t a szolgáltatói HGW-re kötöd, ami publikus IP-t ad, akkor dupla NAT lesz. Ha a saját router mögé, ami privát IP-t ad, akkor a Linksys átkapcsol switch üzemmódba.
A hibaüzenethez: az első bejelentkezés akkor tud megtörténni, ha az NMHH regisztrálja az eszközt, azaz rögzíti a rendszerbe a futár által visszaigazolt kiszállítást.
-
vargalex
félisten
válasz
dethroner
#2665
üzenetére
Eredetileg úgy volt belőve, hogy az azonnali mérőscript egyezett az ütemezett scripttel. De aztán jött a gigabit a Telekom hálózatán és azt csak nagyon nagy kapcsolatszám esetén lehet kihajtani. Érdekes, mert Diginél nem volt ilyen probléma (és ha jól tudom Vodafone-nál sincs). Az ilyen nagy szálszámú mérést a kis eszközökre (TP-Link TL-WR841ND) nem célszerű kiküldeni, mert memória (erőforrás) limitbe ütközhetnek. Viszont a rendszer arra nincs felkészítve, hogy különböző csoportokba szervezett eszközöknek más-más azonnali mérőscriptet adjon, abból csak 1 db globális létezik (amikor indult az egész rendszer, még éppen bevezetés alatt volt az UPC FiberPower 120, az volt a csúcs).
Viszont az ütemezett scripteknél van ilyenre lehetőségük. -
vargalex
félisten
válasz
dethroner
#2663
üzenetére
Szerintem a manuális méréskor érkező scriptet nem frissítették az automatikus méréskor érkezőre, kevesebb szálon mérhet.
Hasonlítsd össze az azonnali mérés után megjelenő Lefuttatott mérőscriptet a Sebességmérő script fülön láthatóval. Ha jól sejtem, utóbbinál a DOWNLOAD és UPLOAD esetén az URL mögött nagyobb számok fognak állni, míg a manuális mérésnél 10 a DOWNLOAD és 4 az UPLOAD esetén (azaz 10, illetve 4 szálon folyik a mérés).
-
-
vargalex
félisten
válasz
DaM_HuN
#2646
üzenetére
Szia!
A 12-es hibakód azt jelenti, hogy eszköz oldalon valami nem stimmelt a mérés során. Nevezetesen azt, hogy a mérő script kimenete nem 3 érték volt (okozhatja tűzfal blokkolás, stb.). Jó lenne hozzá látni az eszköz logját is hozzá. Valami ilyet kell keresni benne: "Not a valid traffic result:".
A 7-es esetén elvileg az eszköz nem végzett, vagy meg sem kapta a mérési feladatot (pl. saját forgalom miatt) az engedélyezett intervallumban.
-
vargalex
félisten
válasz
golya87
#2642
üzenetére
1. Dupla NAT lesz, de a mérőeszköz minden beérkező új forgalmat a hozzá elsőként csatlakozó eszközre (a routered) irányít. Akkor lehet problémád, ha a routered DDNS címet is frissít és nem a valódi külső IP-t jelenti.
2. Fog működni, de így a hivatalos bekötés szerint a saját vezetékes eszközeidet a mérődobozra kell kötnöd.
3. Igen, monitorozza a saját wifi hálózatod forgalmi mennyiségét. -
#2641
vargalex
félisten
Hegyirabló
#2640
vargalex
félisten
válasz
Hegyirabló
#2640
üzenetére
Már rég nem az eszközről beszélünk! Az egyáltalán nem zavar, hogy azt állítod, hogy a szolgáltatói eszközödnek egyetlen gigabites portja van?
Mellesleg olyat még nem hallottál, hogy egy routert egy bizonyos eszközzel használva meghal a hálózat? Sajnos ilyen létezik, pedig a router minden más típusú eszközzel megfelelően működik és az eszköz is minden más típusú routerrel. Akkor ebben az esetben melyik okozza a problémát?
Nem mellesleg arra még mindig nem tudtál válaszolni, hogy miért ment 9 hónapig hibátlanul? Logot sem akarsz semmiképpen adni. Azt sem akarod megnézni, hogy ilyenkor az NMHH-s eszközt sem éred el, vagy csak a szolgáltatói eszközt, vagy csak intenet elérésed nincs. Így nagyon nehéz segíteni, azaz valóban egy megoldás van: visszaadod.
-
#2639
vargalex
félisten
Hegyirabló
#2638
vargalex
félisten
válasz
Hegyirabló
#2638
üzenetére
Ne haragudj, de meg kell védenem a kollégát. Az általad írt Sagemcom 5760 típusú HGW-n 1 db 2,5 Gbps-es és 4 db 1 Gbps-es port található (pl. itt és itt is megtalálhatod). Az, hogy nálad 100 Mbps-en áll össze a kapcsolat, helyi hibára utal. Milyen eszközök azok, amik 100 Mbps linkkel kapcsolódnak? Ha gigabitesek, akkor cseréltesd a Telekommal a HGW-t, mert hibásan működik (vagy rájönnek a hibára nálad).
-
#2634
vargalex
félisten
Hegyirabló
#2632
vargalex
félisten
válasz
Hegyirabló
#2632
üzenetére
Nem kell hozzá érteni, ott van a mérő box lokális webes felületén a Rendszer napló fül. Illetve a szolgáltatói eszközök webes felületén is szokott napló lenni.
Egyébként egyetlen eszközöd van LAN-on, ami szakad? Mert akkor lehet, hogy nem is a neted szakadozik, hanem az eszközöd nem jön ki az NMHH box-al. Az nem változott véletlenül éppen a probléma megjelenésekor? -
#2630
vargalex
félisten
Hegyirabló
#2629
vargalex
félisten
válasz
Hegyirabló
#2629
üzenetére
A 20 perces log pont elég lett volna, hogy kiderüljön valami...
Egyébként az NMHH-nál legfeljebb a mérő scriptet módosították a kérdéses időszakban (paraméterezést). Ebben egészen biztos vagyok, egész egyszerűen azért, mert nem kaptak új firmware-t a mérőeszközökre...
A mérő script pedig nem okozhatja a szakadást, ugyanis óránként mérnek, nálad pedig 20 perc alatt kétszer is megszakadt.
Egyébként vezetéken kapcsolódsz?A portálon a mérőbox lokális felülete most nálam sem látszik. Az viszont azért van, mert https-en éred el a portált, az eszköz oldalát viszont http-n töltené be az iframe-ba. Ez valami új biztonsági korlátozás a böngészőben, vagy a portál headerjében hagyták ki valamit. Semmi köze a mérőboxhoz.
-
#2628
vargalex
félisten
Hegyirabló
#2627
vargalex
félisten
válasz
Hegyirabló
#2627
üzenetére
Annyi magyarázatot tudok adni, hogy a szolgáltató eszköze és az NMHH box valamiért nem jön ki egymással
. Nyilván a szolgáltató oldalon változott valami, mert az NMHH-s box a kérdéses időszakban nem frissült. Viszont a log, illetve annak ellenőrzése, hogy ilyenkor mit érszb még el, az sokat segítene. Az 5-10 másodperces korlát csak utóbbira vonatkozik, a logot kicsit később is nézheted. Ezek nélkül lehetetlen bármit is mondani.
Viszont én is visszakérdezhetek: te azt tudod valamivel magyarázni, hogy azt első 9 hónapban hibátlanul működött? Ha valami az NMHH-s boxxal nem stimmel, akkor a kezdetektől kellett volna produkálnia az első boxnak is, ahogy a második is teszi.Egyébként legrosszabb esetben, ha esetleg legalább 1-el kevesebb vezetékes eszközöd van, mint amennyi LAN portja a szolgáltatói eszköznek, akkor használd párhuzamosan kötve. Ugyan torzulhatnak a mérési eredmények (sokat nem fog, mert az NMHH-s eszköz több 100 szálon is mérhet), de legalább lesznek.
Jut eszembe. A szakadások mérés alatt jelentkeznek, vagy mérési időn kívül is? Ha előbbi, akkor az is lehet, hogy a szolgáltatói eszköz nem bírja (vagy nem tolerálja) a több 100 szálat...
-
#2626
vargalex
félisten
Hegyirabló
#2625
vargalex
félisten
válasz
Hegyirabló
#2625
üzenetére
Ebben nem lennék olyan biztos. Hiszen, ahogy írtam (és ugye te írtad, hogy mikor kezdett szakadozni), 9 hónapig hibátlanul ment. Azaz, ha a mérődobozon nem változott semmi, akkor valami más kellett, hogy változzon. Ezt támasztja az is alá, hogy a második mérődoboz ugyan úgy viselkedett, mint az első. Azaz, valószínűleg az első 9 hónapban az is hibátlanul ment volna... Logban nem látszik semmi egyébként? Amikor megszakad a net, akkor a szolgáltatói eszközt sem tudod elérni?
-
#2624
vargalex
félisten
Hegyirabló
#2623
vargalex
félisten
válasz
Hegyirabló
#2623
üzenetére
Most hogy is van nálad? Az eszköz bridge üzemmódban van, vagy NAT-ol?
Érdekes ez a szakadozás, ráadásul 2 eszköz esetén is. Azt nem mondanám, hogy a mérődobozokkal nem stimmel valami, ugyanis egyrészt többen is használják, másrészt visszanézve a hozzászólásaidat, az első példány nagyjából 9 hónapig hibátlanul üzemelt nálad... Mi változott nagyjából akkor a hálózatodban? -
vargalex
félisten
A külső cég által végzett biztonsági audit egyik vizsgálata ez volt, hogy a weboldalon keresztül kompromittálható-e az eszköz. Nem... Ugyanis nem értékel ki semmilyen beérkező get/post paramétert a szerver oldal, egyszerűen egy paraméter értékét vizsgálja.
NAT-olni akkor kezd, ha DHCP esetén a WAN oldalra publikus IP-t kap, vagy ha PPPoE kapcsolatot detektál (a LAN oldalon PPPoE kapcsolatot kezdeményeznek és még nincs élő WAN kapcsolat).
-
vargalex
félisten
Most jut eszembe, hogy esetleg te az eszköz webes felületén található Portscan eredmények oldalra gondolsz. Ott az NMHH bármilyen port tesztelésére utasíthatná az eszközt, de ez azt vizsgálja, hogy kifelé nem blokkolja-e a szolgáltatód egy távoli szerver valamilyen porton történő elérését! Azaz ott a 22-es TCP port a cél IP (ami egy szintén a BIX-ben lévő NMHH-s szerver) 22-es TCP portját jelenti.
-
vargalex
félisten
Egyébként kíváncsi vagyok, hogy miből látod, hogy a 22-es port nyitva van:
[gavarga@gavarga-5500 ~]$ sudo nmap 10.10.2.143Starting Nmap 7.91 ( https://nmap.org ) at 2021-02-26 07:47 CETNmap scan report for 10.10.2.143Host is up (0.091s latency).Not shown: 998 closed portsPORT STATE SERVICE53/tcp open domain80/tcp open httpNmap done: 1 IP address (1 host up) scanned in 1.05 seconds[gavarga@gavarga-5500 ~]$ sudo nmap -sS 10.10.2.143Starting Nmap 7.91 ( https://nmap.org ) at 2021-02-26 07:47 CETNmap scan report for 10.10.2.143Host is up (0.098s latency).Not shown: 998 closed portsPORT STATE SERVICE53/tcp open domain80/tcp open httpNmap done: 1 IP address (1 host up) scanned in 18.04 seconds[gavarga@gavarga-5500 ~]$ sudo nmap -sT 10.10.2.143Starting Nmap 7.91 ( https://nmap.org ) at 2021-02-26 07:48 CETNmap scan report for 10.10.2.143Host is up (0.074s latency).Not shown: 998 closed portsPORT STATE SERVICE53/tcp open domain80/tcp open httpNmap done: 1 IP address (1 host up) scanned in 1.00 seconds[gavarga@gavarga-5500 ~]$ sudo nmap -p 22 10.10.2.143Starting Nmap 7.91 ( https://nmap.org ) at 2021-02-26 07:48 CETNmap scan report for 10.10.2.143Host is up (0.024s latency).PORT STATE SERVICE22/tcp closed sshNmap done: 1 IP address (1 host up) scanned in 0.34 seconds
Pedig nálam bridge módban van az eszköz... -
vargalex
félisten
Nem hallgat semmi a 22-es porton (nincs is SSH szerver az eszközön), de switch üzemmódban nincs is tűzfal, így igazából minden nyitva van, de csak a web szerver hallgatózik.
Nem csak hivatalosan nem elérhető az eszköz, hanem valóban. Biztonsági vizsgálat is történt. Tudom, mert van közöm a fejlesztéshez...
De ugye te az NMHH boxról és nem a Samknows-ról írsz? -
vargalex
félisten
A "mérőeszköz", azaz a Linksys router nem konfigurálható, azaz igazából nem tudja kiváltani a saját routeredet. A wifi-t is csak monitorozásra használja, így AP sem lehet belőle.
Az átmenő és a wifi (ha előtte van az AP) forgalmat csak méri az eszköz, mindössze azért, hogy eldönthesse, hogy éppen végezhet-e mérést. -
-
vargalex
félisten
Szerintem olvassátok át még egyszer azt a hivatalos/javasolt bekötési módot.
-
#2593
vargalex
félisten
Hegyirabló
#2590
vargalex
félisten
válasz
Hegyirabló
#2590
üzenetére
Fél perc eltéréssel az aktuális osztott közegen bárki indíthat egy letöltést. Nem tudom, mi ebben a meglepő. Több másik felhasználóval együtt osztozol 2,5 Gbps-en.
Új hozzászólás Aktív témák
- Zotac Gaming RTX 5070 // Felbontott, új // SZÁMLA // GARANCIA //
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
- ASUS Vivobook 15 - 15.6"FHD IPS - i5-1335U - 8GB - 512GB - Win11 - 1+ év garancia - MAGYAR
- BESZÁMÍTÁS! Gigabyte B760 i5 12600KF 16GB DDR4 512GB SSD RTX 3080 10GB Asus A31 PLUS TG ARGB 750W
- Dell Latitude 5410 - 14", Core i5 10210U, 8-16GB RAM, SSD, jó akku, számla, 6 hó gar
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest