-
Fototrend
Haladó szintű hálózati témák topikja
Új hozzászólás Aktív témák
-
#6858
crok
nagyúr
szőr Artúr
#6857
crok
nagyúr
válasz
szőr Artúr
#6857
üzenetére
IGMP felderítő csomag lesz, General Query: kérdezi a hostoktól a LAN-ban hogy érdekel-e valakit multicast csatlakozás és ha igen akkor melyik cím.
-
#6866
crok
nagyúr
bwin.party
#6864
crok
nagyúr
válasz
bwin.party
#6864
üzenetére
Ha mikró akkor antennairány újrakalibrálása?
(Ha kicsit elmászott és van az útban most köd
vagy egyéb ami szórja a jelet akkor gond lehet.)Melegedés keresése, antennaerősítők általában
ha melegednek kikapcsolnak (önvédelem).A csatlakozók áthuzogatása, kontaktspray
.
Ha van gép ami futhat 0-24 akkor pingplotter
vagy mtr, attól függ milyen oprendszered van.
(Legalább azt látnád hogy kiesésnél hol dropol). -
crok
nagyúr
Egy mórickaábrát tudnál csinálni itt? (Bal oldalon add hozzá a Cisco eszközöket.)
Egyébként NAS-ra be tudsz SSH-zni? Egy tcpdump/wireshark megmondaná ha a SYN-ek megérkeznek a NAS-ra, egyéb esetben a routeren kellene nézelődni (ahogy előttem is írták.. egyébként milyen router?).
-
crok
nagyúr
válasz
rgeorge
#6977
üzenetére
Milyen IP-ket ír? 169.254.x.y? Vagy mi pontosan mi? A program
megmondja a MAC címeket is, itt nézd már meg hogy melyik
gyártóhoz tartozik, nem-e esetleg VMWare vagy más virtualizációs
szoftvergyártóhoz regelt MAC.. esetleg futhat a gépeken virt. gép?Meg csináld úgy akkor a scan-t hogy a gépen kikapcsolod a wifit.
Azért írhat IP-t mert ha olyan wifi ssid-t lát ami nincs levédve vagy
van hozzá jelszava akkor felismeri a kereteit annak a forgalomnak
ami ezekbe az ssid-kba tartozik. -
crok
nagyúr
válasz
rgeorge
#6980
üzenetére
Nem indítottad el ezt a programot két/több gépen is egyszerre?
A MAC címek bytejai egyesével emelkednek a screenshot-on:
192.168.3.112: 45:46:47:48:49:4a
192.168.3.111: 43:44:45:46:47:48
Nem lehet hogy így scannel az a program és most a két vagy
több futó alkalmazás az egymás által generált kereteket látja?
[Szerk.] Az nmap elérhető Windows-ra is.[ Szerkesztve ]
-
crok
nagyúr
Nem teljesen ertem a kerdest de kb. minden toldo "atviszi" ha minden er helyesen van bekotve. Mas kerdes, hogy ha az igy keletkezett teljes hossz meghaladja a 100m-t akkor mar nem lesz jo.. vagy ha az illesztesek rosszak, nagyok a kontaktellenallasok.. mar ha rezkabelezesrol beszelunk, mert optikara mas vonatkozik.
-
crok
nagyúr
Előtte mennyi volt?
11MBps az gyakorlatban pont a max ami átmegy 100Mbps-en (88Mbps+fejlécek..). Lehet megérné megnézni mire állt be az interface a két oldalon. Ha más is változott akkor volna még kérdésem (mert a "másolás" ezer másik okból is lehet kevesebb mint amire számítasz, lehet hogy csak véletlen hogy csak ennyivel jön a cumó, de lehet hogy a pl. a szerver 100Mbps-en lóg te meg hiába állsz át ugye 1Gbps-re.. de ez csak egy dolog, más kérdés a RTD ("ping) és ezáltal a BDP, mennyi a küldő oldali puffer, mennyi a fogadó oldali puffer, mekkora a TCP window ha TCP az átvitel, van e SACK, van-e csomagdobás.. CRC-zik-e a toldás miatt a link.. sok dolgot tudok még mondani ami miatt hasalhat a kihasználható sávszél). -
crok
nagyúr
válasz
bambano
#6992
üzenetére
Ez igaz lehetne, az ami linuxon "incomplete" az a Cisco routeren is "incomplete". Nem inicializálatlan, nem fals.. csak olyan, mint az az IP-cím ami valótlan (martian - marsi) és igazából az incomplete alatt az érték 00:00:00:00:00:00 - csak ezt neked nem írja ki, nehogy "összezavarjon", hogy valós MAC van az IP-re, ehelyett kapsz egy "incomplete" string-et.
De ha van valami ami képes volt IP csomagot kreálni és küldött is valamit akkor abban a keretben lesz MAC cím, lesz IP - így akár bekerülhetne az ARP táblába.. de itt egyébként nem erről van szó, mert a programban jönnek elő a fantomok, fantom MAC-ekkel.. kérdés hogy a program hogy teszteli hogy van-e a subnetben valaki adott IP-n.. esetleg crafted frame-et csinál amiben crafted MAC-el megy ki gratious ARP hogy válaszra kényszerítse az azt az IP-t használó végfelhasználói berendezést? És ha két ilyen programot indítasz el.. akkor láthatja egymás frame-jeit a két app? Akkor meg is vagyunk.
-
#7024
crok
nagyúr
E.Kaufmann
#7023
crok
nagyúr
válasz
E.Kaufmann
#7023
üzenetére
Szvsz. a router a webstick-hez írta most át a default route-ot, azért van ez a viselkedés.
-
#7026
crok
nagyúr
E.Kaufmann
#7025
crok
nagyúr
válasz
E.Kaufmann
#7025
üzenetére
Igen, így keletkezik az aszimmetrikus routing.. az ADSL FIX IP-t csak egyféleképp érheted el, mert arról csak egyféleképpen - az ADSL-eden keresztül - tud a külvilág. Ám a válasz ha a websticken megy ki mert a router szempontjából a def-route azon keresztül mutat ki - ami most valószínűleg meg is van terhelve - lesz válasz meg lassú is lesz.
-
#7029
crok
nagyúr
E.Kaufmann
#7028
crok
nagyúr
válasz
E.Kaufmann
#7028
üzenetére
Miért lenne a forráscím más? A forráscím jó, a route, ahol kimegy.. az nem jó.. (ha lenne uRPF a szolgáltatónál akkor totál eldobná még azt is.. de ezek szerint nincs).
-
#7031
crok
nagyúr
E.Kaufmann
#7030
crok
nagyúr
válasz
E.Kaufmann
#7030
üzenetére
Csak akkor ha a maszkolásban a forráscímek közt szerepel az ADSL fix IP mint forráscím - de mivel forrás csak a LAN-od lesz és egyetlen WAN-od sem lesz benne mint forrás cím így nem lesz NAT-olva, tehát azzal a source-al megy ki ami ugyan korrekt, csak rossz interface-en.
-
crok
nagyúr
válasz
bambano
#7033
üzenetére
Nem, mert azt írja hogy az ADSL fix IP-re csatlakozik valami VPN-el. A NAT nem is játszik. A forráscím pedig a leírás szerint csak az ADSL fix IP lehet, mert arra jött be - itt természetesen csak feltételezem hogy a router a VPN-t termináló eszköz és ténylegesen az ADSL fix IP-t használja a session felépítésére és fenntartására mert az is egy processz és ha változna a kimenő interface és azáltal a forrás cím akkor az már más SPI lenne, más session és természetesen leszakadna (pontosabban nem menne az eredeti session) de itt erről nincs szó, csak arról hogy ha a timeout-ot megemeli akkor jön a pingre válasz - szvsz mert a webstick-en megy a válasz de az ADSL-en jön a kérés.. tökmindegy hogy most az VPN. Alapvetően igaz, hogy a legtöbb router a kimenő interface IP-jét használja mint source ha pl. NAT-ol (természetesen) de a VPN innentől kezdve más más káposzta, ott valahogy session-t kell csinálni, új SSTP session kell csinálni.. ott nincs lehetőség hogy megváltozik a source IP csak úgy pacsira, azt nem engedheti meg a processz csak tervezetten (failover situation) - de, mint írtam a ping megy ha a timeout nagyobb. Egy tracepath esetleg segíthet ping helyett de én inkább annak a routernek a routing tábláját nézném meg, de alaposan.
"mindig azzal a source-szal megy ki, ami az adott interfészé, mert annak a csomagnak a vpn a forrása, ezért azt az ip címet kapja, amelyiken kimegy" - nem. Ez igaz ha a routeren átmenő forgalomról beszélsz, de itt ha az SSTP-t a router terminálja akkor az már nem átmenő hanem feldolgozott forgalom. (Lentebb leírom miért lesz más a source).
"ettől független, hogy a vpnbe, mint adatkapcsolatba, egy belső hálózati ip csomag van belecsomagolva" - ha a VPN-ben megy akkor az a forrás ami a session-ben be van állítva. Ha más az exit interface akkor más, az SSTP session attól még SSTP session, TCP, van neki forrása, célja, ami nem változik meg attól hogy más interface-en megy ki a csomag. Ennek megakadályozására jó az ISP oldalon az uRPF (mert ez így spoof-olt csomagforgalom amúgy).
Egyébként meg Wireshark a megfelelő helyen megmondja ki merre van arccal ( :
Meg egy ábra jól jönne ha nagyon bele akarunk menni, ajánlom a draw.io-t ha nem használtátok még esetleg, bal oldalon More shapes és Cisco majd szép routereket/switcheket/bármit be lehet tenni. Gyors és ingyé' van (és nem mellesleg 100% használhatóbb mint az M$ Visio valaha lesz IMHO). -
#7036
crok
nagyúr
E.Kaufmann
#7034
crok
nagyúr
válasz
E.Kaufmann
#7034
üzenetére
"direktbe az ADSL fix IP címére csatlakozott egy eszköz VPN-en és próbáltam ping-gelni, nem működött, amint megemeltem a várakozási időt, már át-át csúsztak a válaszcsomagok 1000 ms feletti válaszidővel."
Vagyis te az ADSL fix IP-t használod a routeren az SSTP terminálására? A router terminálja az SSTP kapcsolatod? Vagy a LAN-ban van valami amire portforward van beállítva? Mert eddig a leírásod alapján az ADSL fix IP-t használod az SSTP terminálására és a router az SSTP vége.
Egyáltalán nem mindegy hogy melyik forrás címet használod és hacsak a routerben levő processz nem tudja mindkettőt használni, de ahhoz két SSTP kapcsolat is fel kell hogy felépítve legyen. Ilyen failover a világban nincs hogy két IP és egy SSTP..
De ahogy írtam, ha az SSTP-t a LAN-ban levő eszköz terminálja akkor már máshogy működik a dolog.
-
#7038
crok
nagyúr
E.Kaufmann
#7037
crok
nagyúr
válasz
E.Kaufmann
#7037
üzenetére
De, tapasztaltam, leírtam hogy miért és nem, nem volt tiszta a helyzet mert azt nem mondtad, hogy az SSTP szerver nem a router hanem egy eszköz mögötte.
-
crok
nagyúr
Ja igen, mégvalami: mivel az ADSL alatt az SSTP már élő kapcsolat volt és nyilván már volt rá NAT bejegyzés így nem keletkezik új attól függetlenül mert más lesz az exit interface a forwarding szerint (hiszen egy TCP kapcsolatról beszélünk a router szempontjából, az egyik lába a LAN-ba mutat a másik meg "kifelé", már van élő NAT bejegyzés erre a session-re). Ez így van Cisco-ban, Juniperben, iptables-ben Linux alatt mindenben. Így aztán tulképp nem változik semmi csak a webstick bedugásakor lesz egy új, működő kapcsolat és a def-route megváltozik - de minden marad a régiben. Mivel a webstick szolgáltatója nem használ uRPF-et így a tulajdonképp spoof-olt csomag nem dobódik el, ellenben mivel a (valszeg) a webstick sávszélje kisebb mint az ADSL így ott keletkezik majd egy nagyobbacska késleletés - amit érzékelsz is.
-
#7041
crok
nagyúr
E.Kaufmann
#7040
crok
nagyúr
válasz
E.Kaufmann
#7040
üzenetére
Nem az okosság hanem az order of operation számít:
logikusan hamarabb van a NAT mint a routing/forwarding.Képzelt el hogy kondícionális a NAT-olásod, nem csak egy
sima masq - mondjuk a source-ot is cserélni akarod meg a
destination-t is, mert olyan a setup.. akkor nyilván mivel
a destination-t is átírtad és a routing tábládban sem csak
egyetlen def-route lehet így a NAT hamarabb *kell* legyen
mint a routing/forwarding decision. Ennyi.Ha törlöd a NAT bejegyzést vagy lemegy a pppoe akkor
már a másikat fogja használni - mert csak azt tudja és
mert mivel már nem valid a pppoe interface így már nem
is használható az az interface - okafogyottá válik a NAT
bejegyzés és felszabadul, aztán jön a LAN-ból a csomag
majd NAT-olódik és route-olódik is ki a webstick-en.Ha most pl. a webstick be van dugva és kihúzod majd
vissza is dugod az ADSL-t akkor megint minden fain lesz. -
crok
nagyúr
válasz
VeryByte
#7046
üzenetére
Gyors súgó:
https://mega.nz/#F!cx5CxJqL!YmrmiTkCKH0ZxjbdenPZlA!xkgxgTBA
Books > misc > networking-forum
gbic.pdf
mediadistances.pdf
physical_terminations.pdf
Valamint:
http://lostintransit.se/2010/08/05/quick-facts-about-fibre-standards/ -
crok
nagyúr
Amennyire én tudom..
- A privacy extension miatt is lehet ez - Az android használja pl. by default.
https://tools.ietf.org/html/rfc4941
http://blog.ipspace.net/2016/01/ipv6-address-allocation-is-operating.html
- Meg eleve szívsz az Androiddal mert ha lenne benne DHCPv6 akkor egy csomó future feature nem menne
http://www.techrepublic.com/article/androids-lack-of-dhcpv6-support-poses-security-and-ipv6-deployment-issues/
Pár arc DNSet-et használ arra hogy ne legyen újra IPv6 cím generálás (fixre állítja a DNS-t így nem lesz RDNSS használat és nem kapsz RD-s csomagokat és nem kell új IPv6 cím.. csak annyi hogy IPv4 DNS lesz).
- Amúgy mindig azt látod majd amit utoljára generált. -
crok
nagyúr
mklink /d "meghajtó:\valahol\könyvtár-ahol-látni-szertnéd-a-cuccot" "\\[amit-fel-akarsz-mountolni]\[blabla]"
A könyvtár-ahol-látni-szertnéd-a-cuccot ne létezzen,
azt létrehozza a parancs (egy link lesz).Szerk.: @togvau - nincs mit, remélem menni fog amit akarsz.
[ Szerkesztve ]
-
crok
nagyúr
válasz
rgeorge
#7093
üzenetére
Wireshark, pcap-et tedd fel ide szűrve csak a teszt-re. Megnézem neked.
Lehet a kártyára csinál offload-ot (TCP chimney) a Win, mert úgy tudja hogy arra lehet.netsh interface tcp show chimneystat
Ez egy általános kimenet lesz de ott lesz az Idx.
Nézd már ezt meg hogy be van-e kapcsolva..
netsh interface tcp show chimneystat Idx-az-előző-parancsból
netsh interface ipv4 show offload Idx-az-előző-parancsból -
crok
nagyúr
válasz
rgeorge
#7095
üzenetére
IPv6 : ha nem használod tiltsd le a kártyán.
ctrl+r
ncpa.cpl
kártyát kiválaszt, jobb klikk, properties > configure > advanced
TCP checksum Offload (IPv4) > Disabled
TCP checksum Offload (IPv6) > Disabled
UDP checksum Offload (IPv4)-> Disabled
UDP checksum Offload (IPv6)-> DisabledEz is ajánlott ilyenkor általában:
netsh interface tcp set global autotuning=disabled
netsh interface tcp set global chimney=disabled
netsh interface tcp set global rss=disabledMeg amit még ajánlok így első körben az a:
http://www.speedguide.net/articles/windows-7-vista-2008-tweaks-2574 -
crok
nagyúr
válasz
rgeorge
#7099
üzenetére
A beállítások alapján a filter szolgáltatásként ül be.
Derítsd ki hogy mi a neve:
sc query
- vagy -
sc query | clip
Ez a teljes kimenetet vágólapra teszi, onnan már csak
egy mozdulattal paste-eles notepad++-ba vagy valahova..Megállítani így lehet pl:
sc stop "a filter service-nek a neve"
Letiltani meg így:
sc config "a filter service-nek a neve" start= disabled
(Az = és a disabled közé *kell* a space!)
- vagy -
wmic service where name='a filter service-nek a neve' call ChangeStartmode DisabledMeg van egy csodatool ilyesmire:
https://blogs.technet.microsoft.com/jhoward/2010/01/25/announcing-nvspbind/
https://gallery.technet.microsoft.com/Hyper-V-Network-VSP-Bind-cf937850
https://social.technet.microsoft.com/wiki/contents/articles/191.hyper-v-tools-nvspbind.aspx -
crok
nagyúr
válasz
gabber01
#7107
üzenetére
Tényleg totál nem networking az egész kérdés..
De mennyi RAM-od van és 32 vagy 64 bites az OS?
Mennyi a swaphasználat? Nem csak swapol az a
gép mint az állat csak nem látod a fától az erdőt?
Szerk.: Én [ide] tenném talán ezt a kérdést."Viszont azt vettem észre, hogy ha abszolút nem is
forgalmaz a torrent, akkor is egyből az egekbe szökik
a latency, klienstől függetlenül..."
Akkor ilyenkor mit látsz a statokban? Mit csinál az OS?
Ha a torrenttől függetlenül is felmegy a latency.. akkor
esetleg nem swap lesz ez? Vagy valami más? Meg
akkor ha mindenképpen a tcpip csinálja.. akkor egy
jó wireshark a probléma alatt megmondja kivel beszél
az az OS miközben rommá van terhelve.[ Szerkesztve ]
-
crok
nagyúr
-
crok
nagyúr
válasz
gabber01
#7112
üzenetére
@SWAP: ugye azt tudod hogy a Windows nem Linux.. és az hogy 16G RAM-od van még nem azt jelenti hogy nem swapolhat a rendszered eszeveszett módon..? De ez már *tényleg* nem ez a topik.. ja, és a net tele van ezzel meg azzal, hogy sz@r driverek miatt rengetegszer a downgrade a megoldás.. csak mondom..
-
crok
nagyúr
válasz
qwertly
#7115
üzenetére
D-link router - belépés - Advanced - Port forwarding - adsz neki nevet, megadod a belső IP-jét, a WAN IP-n elérhető portot amin majd elérhető lesz a szerver
Ezek után ami a WAN IP-den bejön erre a portra az tovább lesz dobva arra az IP-re amit megadtál belső IP-ként.D-Link router szimulátorok - ha előre meg akarod nézni milyen a UI (admin/admin):
http://support.dlink.com/emulators/dir890l/100/Login.html
http://support.dlink.com/emulators/dir880l/101/Login.html
http://support.dlink.com/emulators/dir866l/100/login_pic.html
http://www.support.dlink.com/emulators/dir825/113NA/Login.html
http://support.dlink.com/emulators/dir818lw/104/Login.html
http://support.dlink.com/emulators/dir817lw/103/Login.html
http://support.dlink.com/emulators/dir815/100/login.htm
http://www.support.dlink.com/emulators/dir685/login.html
http://support.dlink.com/emulators/dir665/100NA/login.htm
http://www.support.dlink.com/emulators/dir660/login.htm
http://support.dlink.com/Emulators/dir657/100/index.html
http://www.support.dlink.com/emulators/dir655/
http://support.dlink.com/emulators/dir635/109/Login.html
http://support.dlink.com/emulators/dir628/
http://support.dlink.com/emulators/dir625/109/login.html
http://www.support.dlink.com/emulators/dir615_revE/510/login.htm
http://support.dlink.com/Emulators/dir605L/111/index.html
http://www.support.dlink.com/emulators/dir600/101NA/login.htmlEgy SOHO router szimulátor lista:
https://www.snbforums.com/threads/router-ui-emulators.30552/ -
crok
nagyúr
@korcsi:
A port forwarding (is) egy NAT megoldás, konkrétan static port address translation csak nem bentről ki (masq, de az amúgyis dynamic) hanem kintről be (forwarding).NAT-olást csinálhatsz kintről befelé vagy bentről kifelé is - az irány ismeretében állítasz be szabályokat, de attól még NAT. NAT-olni nem csak 1:1-ben lehet egy IP-ről a másikra.
Amit te leírtál az is NAT-olás, csak ezt klasszikusan masquerade-nek hívják: dynamic port address translation (many to one) ami elrejti a belső hálózaton levő gépek IP címeit a külső elől, ez egy tipikus Dyn PAT. De ami neki kell az is PAT, csak az irány az ami más.
https://en.wikipedia.org/wiki/Port_forwarding
https://en.wikipedia.org/wiki/Network_address_translation -
#7143
crok
nagyúr
Phantomhive
#7142
crok
nagyúr
válasz
Phantomhive
#7142
üzenetére
Magnat megoldása megoldás, de bambanovel értek egyet, még lehet szerintem is te lennél az első akit kitennének az angolok ha kiderül a trükközés a biztonsággal.. Ez egy lyuk ütése épp a pajzsra : D De lelked rajta.. a te munkahelyed, lehet nincs is már kedved ott dolgozni : D
-
crok
nagyúr
válasz
Elemental
#7147
üzenetére
Belenézni az ügyfeleid forgálmába akkora *NEM* hogy leírni se tudom.. hacsak el nem mondod nekik hogy mit fogsz *pontosan* csinálni és bele is egyeznek (de még akkor is brutálisan aggályos, főleg hogy a kártyás fizetés is átmegy rajtad).
Olyat tudsz esetleg hogy korlátozod a forgalámát IP-címeknek a Bandwidth control menüben.
Valamint a system tools > statistics alatt tudsz olyat beállítani, hogy nézze hogy melyik IP cím mennyi forgalmat bonyolít, itt érdemes megnézni csomag darabszám és teljes adatátvitel szerint nézni 5sec-es frissítéssel mikor "belassulás tapasztalható".
-
crok
nagyúr
válasz
bambano
#7150
üzenetére
@bambano: Problémát természetesen megérteni de jogilag aggályos tanácsot adni nem..
"van-e lehetőség valahogyan megnézni, hogy melyik ip milyen forgalmat bonyolít, hátha ki tudom deríteni, hogy nem-e letölt valaki ilyenkor?" - jelentése számomra kb. forgalom tükrözése, Wireshark-ban elemzése..
Mellesleg úgy néz ki mégiscsak sikerült hasznosat írnom..
@Elemental: A TP-Link a statisztikát a LAN-ra csinálja - amit ott látsz az a LAN-ból/IP-ről a WAN felé továbbított csomagok száma, adat mennyisége, et cetera.. Ezek a SOHO eszközök valamiért olyat nem hajlandók mutatni, hogy mennyi RX és mennyi TX van.. ez leginkább a fejlesztőkön múlt de ez van. De ha a total byte-ot nézed az már remek kiindulópont hogy ki forgalmaz sokat.. amúgy se a letöltés szokott a szívás lenni hanem a nagy feltöltés ami miatt még a többiek DNS kérései is eldobódnak.. és akkor bambano megjegyzéséhez hozzáfűzve.. A kamerarendszer.. remélem ráadásul nagyfelbontású és wifis is egyben mert ha valami akkor a folyamatos és nagy sebességű/nagy csomagméretű konstans forgalom wifin *mindent* megöl.. olyan mértékben képes a backoff időket megnövelni, hogy már a default gw (még ha a kontroller/AP/router közvetlen közelében is van..) akkor is képes 800..900ms-es RTT-re felmenni. Meg úgy egyébként is ha ez ráadásul valamilyen ADSL-en megy amin a feltöltés többszörösen kevesebb mint a letöltés.. akkor ha valaki távolról nézi a kamerák képeit (ami ugye feltöltés) simán kinyírja a többiek kéréseit.
@Gubek-Einste: így van.. ez kevés lesz ide. Használtan már Cisco-t is lehet venni ami ezt simán kivinné a világból. De az esetleges ADSL akkor is erős szűk keresztmetszet.
-
#7156
crok
nagyúr
Gubek-Einste
#7155
crok
nagyúr
válasz
Gubek-Einste
#7155
üzenetére
Ez teljesen igaz - ám ő max. a neten és a saját eszközén tud majd reszelni, a belső hálózat ahogy olvasom nem az ő hanem a mögötte levők hatásköre.
-
crok
nagyúr
válasz
bambano
#7158
üzenetére
"Ezek a SOHO eszközök valamiért olyat nem hajlandók mutatni,": ezt valaki magyarázza már el nekem, a grafikáján az első négy oszlopban van két byte és két packet oszlop. az nem irányonként elkülönült statisztika?
Nem, az nem irányonként elkülönült stat, a D-Linkben/TP-linkben legalábbis ilyen nincs.. total (Tx+Rx) és transmit (Tx) van (ami a LAN IP felől a WAN felé megy):
Persze nem rocket science kivonni a totalból a tx-et hogy megkapd az rx-et..
nem is értem miért nincs normálisan megcsinálva..[ Szerkesztve ]
-
crok
nagyúr
válasz
bambano
#7161
üzenetére
A total a statgyűjtés bekapcsolása óta forgalmazott, a current meg a frissítési intervallum alatt forgalmazott adat egyébként. De tipikusan olyan stat oldal ez is, mint amikor más csinálja a hardver programozását és más a webUI-t.. és a webprogramozó igazából nem hálózatos, csak mondták neki hogy kellenének statisztikák.. jó kis plusz feature.. és neki ez tűnt logikusnak.. más kérdés hogy ezzel egy hálózatos nem megy sokra.. persze információ csak egy nyamvadt iptables kimenet reszelésével sokkal hasznosabb infokat is ki lehet nyerni. Csak nem kérdezett utána attól akiért azt az oldalt csinálta : D
-
-
crok
nagyúr
válasz
Krystal_s
#7171
üzenetére
Van lehetőséged azon a gépen linux-ot futtatni? Live vagy installált az most mindegy.. Ott egy powertop-ot indítanék és megnézném mennyit eszik a WLAN meg az az Ethernet kártya. (nem tudom window-on milyen lehetőség van erre..). Meg ugye vagy csak az egyiket vagy csak a másikat használod?
Új hozzászólás Aktív témák
- Gamer PC v6 , R5 5500 , RX 5700 XT , 32GB DDR4 , 512GB NVME , 1TB HDD
- Gamer PC v5 , i7 10700 , RX 6700 XT 12GB , 32GB DDR4 , 512GB NVME , 1TB HDD , 240 víz
- Corsair Vengeance RGB PRO SL 16GB POSTA AZ ÁRBAN!
- Eladó Lenovo Legion Slim 5 16IRH8 gamer laptop
- Samsung S22 256GB garanciális újszerű állapotban eladó!!
- BONTATLAN Új Ipad 2022 10th Minden szín 1 év hivatalos Apple Garancia AZONNAL ÁTVEHETŐ DEÁK TÉRNÉL.
- HTC Vive Link Box 2PU6100
- AKCIÓ ÚJ Bontatlan Macbook Pro 14 M3 Pro MAX 14 30GPU 36GB 1TB Magyar billentyűzet Azonnal átvehető.
- Apple Mac Mini A1347 eladó. 2026.01-ig aqua garanciával!
- Western Digital Scorpio Blue (750GB, 8MB 5400rpm SATA2) noti HDD eladó
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest