- Vége: a kínai platformok nem adják vissza a pénzt visszaküldött áru nélkül
- Facebook és Messenger
- Direct One (műholdas és online TV)
- One otthoni szolgáltatások (TV, internet, telefon)
- Hálózati / IP kamera
- Musk szerint bajban van a Tesla humanoid robotja
- Hatalmas hiány lesz a Nintendo Switch 2-ből, rengetegen vinnék
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Linux kezdőknek
- Netflix
Új hozzászólás Aktív témák
-
zenwalk
senior tag
sziasztok
Asztali PC-ről szeretnék filmet lejátszani a TV-n, viszont a TV nem látja a megosztott filmeket. Tv-s topikban ajánlották, hogy fix ip címet osszak ki az eszközöknek. Ezt hogyan tudnám megcsinálni? Van egy T-s modem/router (cisco epc3925) ami lan-lan csatlakozik egy asus n12 d1-hez és erre csatlakozik az iptv box és a tv. A pc amiről le szeretném játszani a t-s routerhez direkt, valamint egy laptop az asushoz wifin keresztül csatlakozik. Melyiken kéne beállítani a fix ip cím kiosztást és milyen név alatt találom ezt? -
#31799
Smktrooper
senior tag
jerry311
#31798
Smktrooper
senior tag
válasz
jerry311
#31798
üzenetére
A fő gerinc az üvegkábel, fénysebesség, azon a cukor nem segít, maximum megtöri és kristályszerkezetének köszönhetően szétszórja
, a fahéj is max azért mert nem veszed észre amíg letölt ha tüsszentesz tőle....Az elérési idő keresztmetszete mindig a NAT chippeken fog múlni, az meg jelenleg 0-2ms közötti tartományban dolgozik. -
#31798
jerry311
nagyúr
Smktrooper
#31797
jerry311
nagyúr
válasz
Smktrooper
#31797
üzenetére
Értem. Ha megszórod fahéjas cukorral a két routert és a vezetékeket, azzal még nyerhetsz egy kis plusz sebességet. A fahéj gyorsítja az elektronok áramlását a fémes kötésben lévő atomok közti távolság enyhe növelésével, illetve a távozó illóolajoktól könnyebben siklanak át a még így is szűk helyeken. A cukor pedig magas energiatartalma miatt fontos, így a világ másik feléről érkező csomagok feltölthetik magukat és gyorsabban célba érnek a belső hálózaton.
-
#31797
Smktrooper
senior tag
jerry311
#31796
Smktrooper
senior tag
válasz
jerry311
#31796
üzenetére
Le van árnyékolva a kettő egymáshoz képest, a biztonság kedvéért. Amikor egymás mellett voltak 500ms elérési idő volt illetve 0,5Mbps re lecsökkent a sávszélesség...Most az emlitett értékek stabilan jó pár hónapja.
Illetve:
A fix reserved IP itt jön képbe...Javitja a kondíciót az elérésben.+Elérési idő definíció:
A kiolvasást indító jel és a kiolvasott információ megjelenése közötti idő. Tehát a teljes spektrum! 4ms esetében 2ms oda 2ms vissza.
-
#31796
jerry311
nagyúr
Smktrooper
#31795
jerry311
nagyúr
válasz
Smktrooper
#31795
üzenetére
DHCP az 4 csomag, kettő oda, kettő vissza, ez eddig 8 msec plusz még pár msec, amit a szerver és kliens dolgozik vele. A 4 msec-es kettes WiFiden sem szabadna tovább tartani mint 20 msec és akkor már beleszámoltam azt is, hogy közben mások is használják.
A 11 és a 13 egymásba lóg, tehát ha az egyiken forgalmaz valami, az zavarja a másikat. Persze még mindig lehet ez a kettő a legjobb választás, ha a többi csatornán sok a szomszéd.
-
#31795
Smktrooper
senior tag
jerry311
#31794
-
#31794
jerry311
nagyúr
Smktrooper
#31792
jerry311
nagyúr
válasz
Smktrooper
#31792
üzenetére
Elvégeznék legalább egy CCNA routing & switching és egy Wireless tanfolyamot vagy legalább elolvasnám a könyveket, mielőtt megpróbálok másokat meggyőzni rosszabbnál rosszabb beállítások helyességéről.
Ha egy router két oldalán ugyanazt a subnetet használod, az routertől függően még akár működhet is (úgy ahogy), de semmiképpen sem javasolt és főleg nem tökéletes.
Address reservation és statikus beállítások közül az utóbbi teljesen felesleges. Egy jól beállított, jól működő hálózatnál a DHCP megvan kb. 15-20 ms alatt. Ha fontos az állandó IP cím arra bőven elég a DHCP, legalább is otthoni környezetben.
Egy SSID elég, csak legyenek külön, nem átfedő csatornán, hogy ne zavarják egymás adását. Így a legtöbb esetben a klienseken nem lesz érezhető a váltás. -
#31793
Smktrooper
senior tag
Gubek-Einste
#31788
Smktrooper
senior tag
válasz
Gubek-Einste
#31788
üzenetére
Azért azt megjegyzem, hogy ez nem egy dupla natos rendszer...1NAT 1Switch ként kell értelmezni.
-
#31791
jerry311
nagyúr
Smktrooper
#31789
jerry311
nagyúr
válasz
Smktrooper
#31789
üzenetére
Ez nagyon messze van a tökéletes otthoni beállítástól.
-
#31790
Smktrooper
senior tag
Gubek-Einste
#31788
Smktrooper
senior tag
válasz
Gubek-Einste
#31788
üzenetére
A lényeg, hogy a WAN portja választja el a belső hálózattól a netet. Network figyelő nem látja az 192.168.1.1 es modemet már, 192.168.1.2 ig látja kliens felől.
Digi van amugy.
-
#31789
Smktrooper
senior tag
Smktrooper
senior tag
Tehát javitva:
-
#31788
Gubek-Einste
Topikgazda
Smktrooper
#31787
válasz
Smktrooper
#31787
üzenetére
Milyen szolgáltatói eszköz van nálad és milyen módban fut (router/modem/bridged)?
-
#31787
Smktrooper
senior tag
Smktrooper
#31785
Smktrooper
senior tag
válasz
Smktrooper
#31785
üzenetére
Egyébként az egy elírás volt.!Hogy DHCP START 192.168.1.2 mert az 192.168.1.3...Ebben igazad van.
-
#31786
Gubek-Einste
Topikgazda
Smktrooper
#31785
válasz
Smktrooper
#31785
üzenetére
Azért nem túl egészséges ha azonos a WAN és LAN oldali tartomány, nem mindenki hozzáért és a router-ek sem engedik az ilyen beállítások használatát.
Ha egyszer már a router-ben MAC alapján van osztva az IP akkor miért legyen a kliens eszközben is fix IP beállítás? Bizonyos eszközökben nem is lehet alternatív beállítást használni, van a fix és van az automatikus, kész ennyi.Két vagy több router-es hálózatban EZT vagy EZT a beállítás ajánljuk, bevált, kipróbált, biztos.
Milyen szolgáltatói eszköz van nálad és milyen módban fut (router/modem/bridged)?
-
#31785
Smktrooper
senior tag
Gubek-Einste
#31784
Smktrooper
senior tag
válasz
Gubek-Einste
#31784
üzenetére
WRT320N+TL-WR741ND
Én értetlenül állok azelőtt, hogy ezen mi nem egyértelmű, hogy ez a tökéletes otthoni szintű beállítás. Nativ, gyors, mi kell még?
Vállalati szinten én is másban gondolkoznék az is tény.
-
#31784
Gubek-Einste
Topikgazda
Smktrooper
#31783
válasz
Smktrooper
#31783
üzenetére
A router beállításnál nem engedi elmenteni ha azonos a WAN és LAN oldali alhálózat.
A router honnan fogja tudni, hogy melyik oldalon van a keresett kliens eszköz ha azonos mind a két oldal?
Milyen router-t használsz egyébként? -
#31783
Smktrooper
senior tag
Gubek-Einste
#31782
Smktrooper
senior tag
válasz
Gubek-Einste
#31782
üzenetére
"Egyébként a legnagyobb hiba a leírásoddal, hogy a WAN és LAN alhálózata nem lehet azonos."
Ezt ki mondja? És miért? Nálam tökéletesen működik. Soha nem volt semmi ütközésem a hálózaton, pedig helyenként 20-25-en lógunk rajta.
-
#31782
Gubek-Einste
Topikgazda
Smktrooper
#31780
válasz
Smktrooper
#31780
üzenetére
A te leírásod a HGW mögötti dupla NAT-os hálózatra vonatkozik.
Pl.:
"A legtöbb modemnek az admin IP címe 192.168.100.1"
"router-en MAC cím alapján fix-ált IP cím van osztva akkor mi szükség van a kliens eszközben manuálisan fix IP-t osztani? Ezzel csak össze lesz kuszálva a hálózat és ha esetleg a kliens eszköz másik hálózatra kerül akkor át kell állítani az IP beállításokat"Ezekre irtam is a képen a megjegyzés fül alatt...Tényleg nem egyértelmű?
Én értem (bár értelmét annyira nem) de mások számára nem biztos, hogy ennyire egyértelmű lenne.Gyakorlati példa:
Eszközök:
Cisco EPC3212 kábel modem, "admin" IP cím 192.168.100.1
Asus N18U router. admin IP cím 192.168.1.1
Asus N12 D1 router, admin IP cím 192.168.1.1Az N18U természetesen megkapja WAN portjába a modemből a kábelt, admin IP címet nem állítjuk át mert jó a gyári érték is. DHCP tartomány 192.168.1.100 és 192.168.1.150 közötti lesz.
MAC alapján fognak IP-t kapni azok a kliens eszközök amelyekre port forward lesz beállítva és/vagy megosztott erőforrást biztosít.
A modemen 192.168.100.1 IP címen tudjuk ellenőrizni a jelszint értékeket, hogy minden rendben van-e.
Az N12 D1-ben van dedikált AP mód de ezt most nem használjuk.
Az N12 D1 admin IP címe 192.168.1.2 lesz, hogy ne ütközzön az N18U-éval, DHCP-t kikapcsoljuk mivel az N18U osztja mindenkinek az IP beállításokat. LAN-LAN kábelezés lesz az N18U és az N12 D1 között.
Így az N18U-ra és az N12 D1-re csatlakozó eszközök egyetlen alhálózat alatt lesznek, mindenki elér mindenkit, a megosztott erőforrásokat mindenki tudja használni.Plusz:
A Cisco EPC3925 egy HGW így router-ként is tud működni (T-nél csak router-ként, UPC-nál router és brideged mód is van) így kétféle eléri címe is van. Ha router-ként működik akkor 192.168.1.1 az admin IP címe, ha bridged módban van akkor pedig 192.168.100.1.
Mivel az Asus N18U jobb router képességekkel rendelkezik és nem akarunk dupla NAT-ot használni így a HGW bridged módban lesz.Egyébként a legnagyobb hiba a leírásoddal, hogy a WAN és LAN alhálózata nem lehet azonos.
-
#31781
Smktrooper
senior tag
Gubek-Einste
#31779
Smktrooper
senior tag
válasz
Gubek-Einste
#31779
üzenetére
Nekem ilyen a net elérésem ha 2 router van a modem után fix ip vel wifin, a rendszer felállásról meg nem is beszélek, hogy mivel nativ a cim ezért nem kell elinditania auto configot, tehát gyorsabban tölt be a rendszer, mintha DHCP-n hagyom.
És amint leírtam az adress reservationre azért van szükség, hogy az egyéb eszközök amikor kérik az IP cimet ne kérjék véletlenül se be azt a cimet amit "tegnap" használtál a munkaállomáson...
-
#31780
Smktrooper
senior tag
Gubek-Einste
#31779
Smktrooper
senior tag
válasz
Gubek-Einste
#31779
üzenetére
Légyszi gondolt át ezt mégegyszer.
Ezek a tökéletes otthoni beállitások.Pl.:
"A legtöbb modemnek az admin IP címe 192.168.100.1"
"router-en MAC cím alapján fix-ált IP cím van osztva akkor mi szükség van a kliens eszközben manuálisan fix IP-t osztani? Ezzel csak össze lesz kuszálva a hálózat és ha esetleg a kliens eszköz másik hálózatra kerül akkor át kell állítani az IP beállításokat"Ezekre irtam is a képen a megjegyzés fül alatt...Tényleg nem egyértelmű?
-
#31779
Gubek-Einste
Topikgazda
Smktrooper
#31778
válasz
Smktrooper
#31778
üzenetére
Néhány észrevétel:
A legtöbb modemnek az admin IP címe 192.168.100.1 hogy ne ütközzön a router-ek által használt 192.168.0.1 vagy 192.168.1.1 IP címekkel.
Ha még is 192.168.0.1 vagy 192.168.1.1 az admin IP cím akkor router módban lévő HGW-vel van dolgunk, ilyen kor vagy meg kell próbálni bridged/modem módba tenni a szolgáltatói eszközt (ha lehetséges) vagy az össze router-t AP módban használni, a dupla NAT kerülendő amennyire csak lehetséges.
Ha egyszer az elsődleges router-en MAC cím alapján fix-ált IP cím van osztva akkor mi szükség van a kliens eszközben manuálisan fix IP-t osztani? Ezzel csak össze lesz kuszálva a hálózat és ha esetleg a kliens eszköz másik hálózatra kerül akkor át kell állítani az IP beállításokat. Az a legjobb ha a kliens eszköz automatikus konfiguráción van és a router-ben van intézve a kiosztás.
A fix-en osztott IP címek ne essenek bele a DHCP tartományba, főleg ne a router admin IP címe. -
süttyő
tag
Sziasztok!
Aztszeretném megkérdezni hogy lehetséges-e 2 router összekötése? Az egyiken menne a wifi az emeleten a másikon a földszinten lenne rákötve 2 db asztali pc. Megoldható lenne? A Lent lévő router wan portjában lévő kbelt dugjam a fent lévő valamelyik lan portjába? Ha ez lehetséges, Milyen beállitásokatkell elvégeznem ehez a routerban? -
#31776
Smktrooper
senior tag
Smktrooper
#31775
Smktrooper
senior tag
válasz
Smktrooper
#31775
üzenetére
#Microsoft Virtual WiFi Miniport Adapter# rejtett eszköz
Megjelenítése
http://www.sevenforums.com/tutorials/77614-device-manager-hidden-devices.html
-
#31775
Smktrooper
senior tag
janos666
#31774
Smktrooper
senior tag
válasz
janos666
#31774
üzenetére
Mintha olyan rémképem lenne, hogy a #Microsoft Virtual WiFi Miniport Adapter#
tud ekkora laggot okozni és elég ha csak az egyik gépen van fenn, már problémát tud okozni a hálózaton.I=====================>
Illetve a gépekben ahol rögzitesz mekkora a CPU cashe hány utas?
http://prohardver.hu/tudastar/a_parhuzamositas_formai.html -
#31774
janos666
nagyúr
Smktrooper
#31773
válasz
Smktrooper
#31773
üzenetére
Azt nem tudom miért nem jutott eddig eszembe komolyabb súllyal figyelembe venni, hogy a kamerákhoz mellékelt Windows-os kínai szotyi (aka "CMS2") látszólag probléma nélkül tud rögzíteni az itthoni Windows-os asztali PC-men WiFi-n át is, ami nem olyan meglepő, hisz eddig is tudtam vele nézni élőben a nagy felbontású stream-eket szimultán 2x2 kiosztásban is. Szóval szerintem szűkíthetünk egyet a körön, hogy csak RTSP esetén van probléma. Bár eddig ezt át sem gondoltam, hogy ez a szoftver talán nem RTSP-n hozza be a stream-eket, hanem valami "natív proprietary" (vagy egyszerűen csak nem feltüntetett nyílt szabványos) módon. Bár végül is lehet, hogy RTSP az, csak valami speciális klienst tákoltak hozzá, ami kikerüli a bug-ot (vagy direkt lehetetlenítették el a szabványos RTSP klienseket?).
Nemrég kipróbáltam az RTSP-t VLC-vel is, ami nem ffmpeg-et használ ehhez, hanem egy másik RTSP megoldást. Ugyan az a szituáció (1 kamera OK, kettőtől több sok, 4 már SOKK), csak sokkal csúnyábban száll el (elkezdi "végtelen sebességgel", azaz a HDD írási sebességével teleírni a TS file-t, ami utána nem nyitható meg player-el).
Mondjuk ettől még továbbra is fura, hogy miként tudnak "interferálni" RTSP használatakor (azt a fenti tény tisztázza, hogy a nyers sávszélesség az rendelkezésre áll), mert nem egyszerűen csak szar az RTSP implementációjuk, hanem akkor van baj, ha egyszerre több kamera is RTSP-t használ ugyan azon a 100Mbps vonalon át.
Teljesen úgy néz ki, mint ha pl. egymásnak is elküldenék az RTSP stream-eket valamiféle peer-to-peer jelleggel, de ezt hihetetlen nehéz elképzelni, hogy miért és miként.
-
#31772
janos666
nagyúr
Smktrooper
#31768
válasz
Smktrooper
#31768
üzenetére
Irreleváns, mert nincs NAT, csak LAN, a WiFi is Bridge móban van, de a tesztelésre kint hagyott laptop az közvetlenül abba a PoE-s unmanaged switch-be ment, amibe a kamerák is.
-
#31771
Intruder2k5
MODERÁTOR
Smktrooper
#31770
válasz
Smktrooper
#31770
üzenetére
Nem tudok gyári fw-vel mérni, mert 8 éve nem használok gyári fw-t, de azt tudom, hogy Tomato alatt nincsenek ilyen problémák, stabilan működik a router akár hónapokon keresztül is. Persze megfelelő nethez, megfelelő routert kell választani, nyilván az 500-as vagy 1000-es DIGI-hez nem ez a párosítás lesz a nyerő.
-
#31770
Smktrooper
senior tag
Intruder2k5
#31769
Smktrooper
senior tag
válasz
Intruder2k5
#31769
üzenetére
Mérj sebességet a gyári firmwarrel def settingz alatt és a moddoltal is. Márcsak a lokál netszolgáltatóval mit művel? Én jópárszor találkoztam olyannal, hogy a moddolt firmware alatt 80-90% on üzemelt csak a cpuja és elfogyott a ramja pikk pakk pl. és emiatt a net is csak 80-90%os sávon ment.
Elnéztem a routert
-
#31769
Intruder2k5
MODERÁTOR
Smktrooper
#31768
válasz
Smktrooper
#31768
üzenetére
Az ASUS RT-N66U-nak nem 1GB, hanem 256MB RAM-ja van, ami persze nem kevés, SOHO routerben eddig a legtöbb 512MB, de bőven vannak még 32/64MB-os darabok is.
Egyébként nekem is "moddolt" firmware van rajta, de egy darab packet loss-t sem okozott eddig.
-
#31768
Smktrooper
senior tag
janos666
#31767
-
Ez egyre rejtélyesebb. Most végigpróbáltam mind a 4 kamerán egyesével, hogy egyszerre csak egyet, de azt párhuzamosan négyszer nyitom meg UDP-n, négy külön ffmpeg folyamattal. Így jól működik (elvétve jelez néhány packet loss-t, de használható mind a négy videófile, egyiken sem észlelhető számottevő képhiba).
Ugyan az az egy kamera (bármelyik) négyszer sima UDP-vel (nem multicast, olyat szerintem nem is tud, de nem is kértem) az OK.
Ha ráindítok így egy második kamerát egyszer, már kezdődnek a bajok (ugyan úgy, mint ha csak egyszer-egyszer nyitnék meg egy-egy kamerából kettőt: még nem vad, de már kezdődik a packet loss üzenet áradat).
Négy kamera külön-külön egyszerre UDP-vel pedig katasztrófa.
TPC-vel hiába butítom a képminőséget, 10-20 percenként reboot...Ez talán mégiscsak valami OS vagy szoftver bug lesz. Google-el találok 2010-től 2015-ig erre vonatkozó hibajelentéseket. Általában mindig le van zárva valamilyen patch-el, vagy javaslattal, hogy mit írjon az ember a parancssorba a buffer növelésére. Már az udp.c-ben is feltoltam a sokat emlegetett buffer méretét, de van felső korlátja és az nem elég, vagyis gondolom inkább más a baj.
-
#31766
Intruder2k5
MODERÁTOR
HRC95
#31764
-
#31765
smallmer
őstag
Smktrooper
#31756
smallmer
őstag
válasz
Smktrooper
#31756
üzenetére
ilyen esetben a wifi ugyanúgy működik ?
illetve bővebben ki tudnád fejteni, hogy mit hogyan kell?
köszönöm -
HRC95
tag
Van a "fő" számítógép abba megy egy Huawei Echolife Hg8245 (t home adta) és erre van rákötve egy TP-LINK TL-WR841N ami szórja a wifit a lakásban, na én most a tp linknek a 2. slotba dugtam egy 20m-es net kábelt és bevittem tesóm gépéhez majd bedugtam a számítógépbe és nem történik semmi
-
HRC95
tag
Olyan kérdésem lenne, hogy hogy tudom megcsinálni azt, hogy a másik gépen is kábeles legyen a net. Van egy gép a nappaliban arra rá van kötve egy Tp-link router és abból jön ki a 2. sloton egy utp kábel ami bemegy a szobába (20m) és csatlakozik a géphez. Össze is van dugva de semmi reakció, mit csináljak vele, vagy ez igy nem is működhet? A wifi állandóan rossz tesómnak ezért szeretném így megcsinálni neki.
-
#31761
janos666
nagyúr
Smktrooper
#31758
válasz
Smktrooper
#31758
üzenetére
Ennél a példánál TCP-t használ az ffmpeg és próbaképp vissza van véve az fps 30-ról 15-re, a bitráta pedig 2048-ra (az normális, ha nem bitre pontosan 2048 van a parancssorban, az egy átlagérték, amit az ffmpeg számol, és a 2048 csak egy "target" érték a hardware encoder-nek, amitől normális, ha picit eltér...). Nem úgy néz ki, mint ha a meg lenne halva a hálózat pusztán attól, hogy aktív egy-egy kapcsolat a kamerák felé. Itt most távoli asztalon nézem a laptop-ot és ott másolok át egy videófile-t (nem tömöríthető adat) WiFi-n az itthoni NAS-ról az ottani Windows asztalra: [link] - szerintem elég szépen szalad és nem szakad meg a rögzítés sem (utóbbi akkor történik, ha reboot-ol a kamera 10-20 percen belül).
-
#31760
mezis
félisten
Smktrooper
#31758
mezis
félisten
válasz
Smktrooper
#31758
üzenetére
Előfordult már ilyen eset is, meg volt már ilyen vírus is.
-
#31759
janos666
nagyúr
Smktrooper
#31758
válasz
Smktrooper
#31758
üzenetére
Feltettem már ezt a kérdést, de elakadt a "hogyan" résznél.
Tegyük fel, hogy hibás az egyik (vagy akár az összes) kamera kábele, vagy valami inkompatibilitási okból Half-duplex 10Mbps-re vált(anak azok) a switch port(ok).
Az alapján, hogy egyszerre bármelyik tetszőleges kamera működik egyedül UDP-vel, a laptop és(/vagy) SXT felé pedig megvan a duplex 100Mpbs (ez ellenőrzötten, tesztelten), akkor ebből elvileg még nem lehetne gond. (Amúgy még nem néztem soha passzív PoE adapterrel és managed switch-el, vagy közvetlenül NIC porton, hogy normál esetben milyen módban üzemel egy-egy kamera portja, a PoE-s unmanaged switch-ek pedig nem jelzik ezt.)
Sok switch-en van pl. >=4db 100Mbps és 1db 1000Mbps "uplink" port, vagy akár 32-64db 100-as és egy-két >=10Gbe SFP+, stb. De pl. UDP esetén nincsenek ACK-k, így ott még az sem szabadna, hogy bezavarjon, ha az "uplink" port (itt az SXT vagy a laptop) visszavált Half-Duplex 100Mbps módba (amikor feltételezett Half-Duplex 10Mbps porttal kommunikál), hisz úgyis kvázi egyirányú a forgalom. -
#31757
janos666
nagyúr
Gubek-Einste
#31749
válasz
Gubek-Einste
#31749
üzenetére
Nem (szerverről frissül a saját lábán, és mikor tegnap ránéztem, akkor letöltött egy novemberi build-et a szeptemberi helyett, de visszafelé nem látok utat, illetve igazából változhatott a SoC is, nem szedtem őket szét, csak a szenzort és encoder chip-et figyeltem a specifikációknál), de még akkor is erősen félmegoldásnak tűnik, illetve továbbra is kérdés, hogy 4 független ffmpeg folyamat esetén (így gondolom nem a programon belül van a hiba, de próbáltam úgy is, hogy egy ffmpeg folyamat kezeljen 4 stream-et, de úgy is csak annyival "jobb", hogy nehezebb átlátni a debug üzeneteket és nem tudom loop-al újraindítani a leszakadozó szálakat) miként folytja el egymás elől a sávszélességet, ha sokszor ennyinek is bele kéne férnie a keretbe?
Az OS-re is nehéz gyanakodni, miután próbáltam Linux-al és Windows-al is, illetve ffmpeg helyett gstreamer-el is, utóbbi az még érzékenyebb és követhetetlenebb. Vagy van esetleg mindkét OS-ben valami szűk limit UDP forgalomra? -
#31756
Smktrooper
senior tag
smallmer
#31755
-
smallmer
őstag
Sziasztok,
ismét kérném a segítségeteket. Két routert használok itthon, egy 1043nd a főrouter, míg egy 841nd kábellel hozzákötve az Acces Point. Olyan gondom van, hogy ha mondjuk egy nas-t beledugok a 841-be akkor sehogy nem tudom elérni. Van szoftvere is a nas-nak ami felderítené a hálózaton, de az sem találja. Esetleg nem tudtok valami megoldást rá, hogy működjön a nas az AP-ról is?
köszönöm -
#31754
Gubek-Einste
Topikgazda
XuChi
#31751
-
-
#31751
XuChi
addikt
Gubek-Einste
#31714
XuChi
addikt
válasz
Gubek-Einste
#31714
üzenetére
Szobában a TV mögött egy szekrényben.
Most lecseréltem egy RP-N53-ra a RP-N14-et. Ez tudja az 5ghz-et.
Ezt is ugyan oda raktam ahol a régi volt. Beállítottam, hogy Acceess Point módban menjen. 5Ghz-n megy, de továbbra is max 35-40mbps-t érel el az eszközökön
-
#31749
Gubek-Einste
Topikgazda
janos666
#31747
-
Még mindig szenvedek az IP kamerákkal.
Lennie kell valami triviális dolognak, ami felett elsiklom.A WiFi link optimalizálása és UDP-ről TCP-re váltás csak félmegoldás volt.
Az egyik távoli helyszín már használható, a másikon viszont időnként reboot-olnak a kamerák (ilyenkor több másodperc is kimarad, és gondolom hosszú távon "nem egészséges" nekik óránként többször reset-elődni...). Hardware-esen mind a 9 hasonló, de a kényesebbik 4-en más a firmware, mint a többi 5-ön, mert két külön rendelésből jöttek. Kizárásos alapon talán ez lehet az ok a némileg eltérő viselkedésre.
(Illetve az automata bitráta miatt is változékony, de most felhúztam mindet a maximális 8Mbps-re a teszteléshez, hogy ez ne verjen át.)Most otthagytam egy Windows-os laptop-ot az egyik helyszínen, leállítottam a távoli rögzítést (ami Gentoo Linux alól menne) és helyben próbálkozom UDP-vel és TCP-vel is, de ugyan az a helyzet, mint WiFi-n át. Nagyjából ez történik UDP-vel:
- egy kameráról vígan írja ki az ffmpeg file-ba RTSP-ről a H264 stream-et
- kettőnél nagyon ritkán, de már előfordul packet loss (bár használható marad a file)
- háromnál sűrűn dobja az ffmpeg a packet loss üzeneteket és szemetel a kép
- négynél már vadul pörögnek a packet loss üzenetek és használhatatlanok a file-ok
Ugyan ez TCP-nél arra változik, hogy egynél több kamera mellett egy kevéssé egyértelmű üzenet jelenik meg néha (de sokkal ritkábban, mint UDP-nél, és a videókban nagyon nehéz kiszúrni, hogy épp ilyenkor veszik-e el 1-2 képkocka, mert nem esik szét úgy a kép, mint mikor UDP csomagok vesznek el), viszont minél több kamera fut egyszerre, annál sűrűbben, durván 2-30 perces időközönként reboot-olnak a kamerák (ennek nyoma van a kamerán tárolt naplófájlban is, illetve ha loop-olva van az ffmpeg, hogy azonnal újrainduljon, amint tud, akkor látni is, ahogy tükrözött sötét képpel indul el a videó, majd átvált tükörképre és beszintezi a fényerőt...)A reboot-ra a tipp-jeim, hogy vagy próbál bufferelni, míg megtelik a RAM és emiatt jön egy pánik, vagy egy watchdog szerűség vélt/valós hálózati hiba esetén reset-el. A másik 5 kamerán, amik nem reboot-olnak, ott gondolom vagy több és elég erre a szabad RAM, vagy nem komplett reboot történik, hanem eldobja a buffer tartalmát, mikor megszorul, vagy esetleg nem is alakul ki ugyan az a szituáció, amiért a másik 4 reboot-ol (mert talán a másik 4-nek sem szabadna, hanem ez egy firmware bug az adott verzióban...). Passz.
Na de ezzel most mi lehet a gond.
Ha egyszerre egy (bármelyik) kamera OK, akkor a switch és a kamera közt nem szűk a keresztmetszet.
A laptop és az SXT közt is megvan a 100Mbps a swith-en át, mert stabil ~10MB/s-el tudok róla SMB-n file-okat hazaküldeni.Sőt, itthon mind a 9 kamera átmegy egy 1000Mbps switch-en, az is amelyik itthon van, az mégsem érzékeny a távoliakra (soha semmilyen formában, az mindig hibátlanul rögzül, bármit is csinál a többi 4+4).
Amikor még a WiFi-re gyanakodtam, ott a RouterOS-ben használtam a Packet Sniffer-t és azt láttam, hogy többnyire 1500 byte-os csomagok mennek a kamera felől a szerverhez és TCP esetén fele ennyi 52 byte-os csomag megy vissza. Utóbbi UDP esetén nincs (így ez nagy valószínűséggel mind TCP ACK csomag és UDP-nél nem is, vagy csak nagyon ritkán nyugtáz vissza az RTSP).
Egy-egy kamera <10Mbps forgalmat generál.
Miért lehet akkor, hogy 4 kamera "megfojtja egymást" a 100Mbps hálón és mi erre a megoldás?
Létezhet olyan, hogy ha egy switch-en több 10Mbps-en működő portból irányul forgalom egy 100Mbps portra, akkor utóbbi is gyakorlatilag összesen 10Mbps-re korlátozódik? Ezt valamilyen switch hibakén fognám fel, de már próbáltam switch-et cserélni (az egyik egy noname kínai, amit még a kamerák forgalmazójától vettem [és miért árulnának pont olyat, ami épp idióta mód inkompatibilis a kameráikkal...?], a másik egy hazai kiskerből találomra felkapott TP-Link 10/100 PoE switch.
-
-
#31743
zenwalk
senior tag
Smktrooper
#31741
zenwalk
senior tag
válasz
Smktrooper
#31741
üzenetére
Honnan kéne látnom, hogy melyik osztja szét jobban?
-
#31739
zenwalk
senior tag
Smktrooper
#31738
zenwalk
senior tag
válasz
Smktrooper
#31738
üzenetére
DHCP útvonalak használata:
Letiltás
Microsoft
RFC3442
RFC3442 & Microsoft -
#31737
zenwalk
senior tag
Smktrooper
#31736
zenwalk
senior tag
válasz
Smktrooper
#31736
üzenetére
-
#31735
zenwalk
senior tag
Smktrooper
#31734
zenwalk
senior tag
válasz
Smktrooper
#31734
üzenetére
Igazából nem tudom változtatni az IP címét, mert AP módban van és így automatikusan beállítja. 3 mód közül tudok válassztani:
Vezeték nélküli router mód (alapértelmezett)
Jelerősítő üzemmód
Hozzáférési pont (AP – Access point) üzemmód -
#31734
Smktrooper
senior tag
zenwalk
#31732
Smktrooper
senior tag
válasz
zenwalk
#31732
üzenetére
Ha a modem az első akkor az asuson csak a DHCP-t kell kikapcsolni, és az ASUSON, ahogy volt csak a LAN1 be kell bedugni a LANkábelt, nem a WAN ba, illetve a LAN cimet tedd egyel a modem IP cime mögé egy értékkel. 192.168.1.1-> 192.168.1.2. ÉS akkor SWITCHKÉNT ÜZEMEL, és a Modem osztja a címet a hálózatnak. WIFI meg alap beállítás szerint áthidalja a LAN-t a WIFIvel.
-
#31732
zenwalk
senior tag
Smktrooper
#31730
zenwalk
senior tag
válasz
Smktrooper
#31730
üzenetére
Az asus routerben van AP mód, így amiket irtál automatikusan beállítja, de azért mindent resetelek.
-
#31731
Des1gnR
őstag
Smktrooper
#31728
Des1gnR
őstag
válasz
Smktrooper
#31728
üzenetére
A PC3-nál csak tűzfal gond volt, szóval legalább lokálisan megy a ping
(Már kezdtem agylobot kapni)A rajzodat át kell rágnom
-
#31730
Smktrooper
senior tag
zenwalk
#31729
Smktrooper
senior tag
válasz
zenwalk
#31729
üzenetére
Kezd előről...Routerek reset, modem reset. "hideginditás" midnet kezdj előröl( csak az egyik routerba engedélyezd a DHCP-t mert kilövik egymást, vagy a tartományt jól válaszd el két távoli cimre ...
192.168.1.1 a modem és a router IP cime 192.168.1.2, majd az ASUS 192.168.1.50 ről induljon)
de persze ettől eltérő lehet a te hálózatodnál. -
zenwalk
senior tag
Sziasztok
Sikerült beüzemelni az Asus N12 D1 routert, amihez a TV és az IPTV box csatlakozik. A T-s router/modemből egy utp kábellel csatlakozik lan-lan, az asus AP módra van állítva. A kábeles eléréssel nincs gond, bár a speedtest 80 megát jelez, miközben 120 megás netünk van. Az asztali PC-n ami közvetlenül csatlakozik a T-s routerhez 110 megát jelez, ami folyamatosan csökken és a teszt végére csak 90 mega marad. Az normális, hogy az asus után csak 80 mega az elérés? A másik problémám pedig, hogy a wifire telefonnal nem tudok csatlakozni. Látja a hálózatot 1-2 másodpercenként változik a wifi erőssége maxról minimumra. A laptoppal tudok csatlakozni és nem is dobál le. Mi lehet a gond? -
#31725
Des1gnR
őstag
Smktrooper
#31724
Des1gnR
őstag
válasz
Smktrooper
#31724
üzenetére
[link]
A PC2Na, de most érdekesség van...a PC2 mellé bedugtunk egy PC3-at és kiiktattuk az internetet.
A PC3 meg tudja pingelni a PC2-t, de a PC2 nem tudja a PC3-at.Szerk: Kipróbáltuk dinamikus ip kiosztással is, de úgy se, pedig a connected devices-nél ott van mindkettő a routerbe...de ugyan az.
Mifolyikgyöngyösön?????
-
Des1gnR
őstag
válasz
VeryByte
#31721
üzenetére
Én ennyit kaptam utasításként, hogy minimum a ping menjen, de hétfőn kipróbáljuk, hogy megy-e aminek mennie kell.
Van ebből az RV215W-ből nekem egy másik is...most a kettőt megpróbáltam összekötni. 10-ből 3x sikerült is kapcsolódnia, de itt még vannak homályos részek, hogy ilyenkor hogy is kellene működnie.
Pl ha rádugok mindkét oldalon 1-1 eszközt fix ip-vel, akkor azoknak látnia kellene egymást ugye?
Smktrooper: Ezt nem teljesen értem, kicsit kifejtenéd? Azt se bánom, ha képet is mellékelsz
Szerk: Egyébként nem igazán vagyok megelégedve ezekkel a cisco routerekkel...pl amikor létrejön a kapcsolat is csak annyi történik, hogy a IPSec Connection Status oldalon beírodik a Start Time, de van, hogy 2-3x is rá kell frissítenem mire a Connect szöveg Disconnectre vált...jelenleg pl nem is váltott, de a Start Time legalább ott van.
Ilyenkor a másik routerrel is connectálnom kell? -
VeryByte
őstag
válasz
Des1gnR
#31719
üzenetére
Na ezért kérdeztem, hogy fontos neked a ping vagy más szolgáltatás kell a visszairányban?
Az, hogy a ping hol döglik le eléggé kérdéses, de én a router-re szavaznék. Én egy RV320-at nyúzok, annak is vannak érdekes húzásai és eléggé nem dokumentáltak.
Pl:
VPN kliens - VPN szerver (nem az RV320) - RV320 - Sonicwall - site-to-site VPN partner
Na ez konkrétan 30 másodpercenként eldobál.
Ha az RV320-at kicserélem egy faék TP-Link-re, akkor simán megy órákig.
De kell az RV, mert a TP-Link csak 16 routing szabályt tud kezelni, nekem meg kell kb 20. -
-
hatnor
tag
Sziasztok!
Valahogy meg lehet azt oldani, hogy egy tp link tl-wr541g routerre kötöm a modemet és egy tp link tl-1043nd routerrel rácsatlakozom wifin és van is rajta net?
Illetve a tp link tl-1043nd routernek, hogy lehetne növelni a hatótávolságát?
Ha csak repeaterrel érdemes, milyet ajánlanátok?üdv:hatnor
-
#31714
Gubek-Einste
Topikgazda
XuChi
#31709
2.4Ghz-en a 120Mbit Upc Netből, a Repeater közvetlen közelében 15-45mbps lett. Ez miért van ???
Hol van elhelyezve az eszköz a szobában (padló közelében/szekrény mögött/stb)?
inSSIDer3/Wifi Analyzer mit mutat a router és a repeater mellett?
Biztosan 2,4 GHz-n volt a teszt a router-nél (a kliens eszközök dual band képességük miatt)?Repeater módban jobb lenne a helyzet (kétlem de mi van ha mégis) ??
Repeater módban biztosan nem lesz jobb mivel alapból link sebesség felezés van ilyenkor.Ha ennek a helyére (RP-N14) beiktatnék egy Asus RT-N18U router-t Access Point módban, meglenne a 120Mbps ???
A külső antenna és jobb MIMO képesség miatt lehet számítani javulásra de előbb jó lenne látni, hogy inSSIDer3/Wifi Analyzer mit mutat a repeater mellett.Illetve, ha Access Point módban van az eszköz, beállítható valahol, hogy a készülékek mindig az erősebb jelre csatlakozzanak ?
Kliens eszköze válogatja, hogy van-e erre lehetőség. -
XuChi
addikt
Kipróbáltam otthon egy Asus RP-N14 Repeater-t.
Access Point módban volt, lan-on kapta a netet a másik szobában lévő Asus RT-N66U-ról.
2.4Ghz-en a 120Mbit Upc Netből, a Repeater közvetlen közelében 15-45mbps lett. Ez miért van ???
Repeater módban jobb lenne a helyzet (kétlem de mi van ha mégis) ??
A fogadó eszközök közvetlenűl az N66U Router-ra kapcsolódva simán hozzák a 100-110mbps-t a másik szobában!!, tehát nem a készülékeim a szűk keresztmetszetek (Ipad Air 2, Iphone 6, Iphone 5, Asus TP300LA intel 6250 wifi)
Ha ennek a helyére (RP-N14) beiktatnék egy Asus RT-N18U router-t Access Point módban, meglenne a 120Mbps ???
Illetve, ha Access Point módban van az eszköz, beállítható valahol, hogy a készülékek mindig az erősebb jelre csatlakozzanak ?
-
VeryByte
őstag
válasz
Des1gnR
#31707
üzenetére
Hm, direkt kipróbáltam egy hasonló felállást (annyi, hogy nem egy cisco a VPN szerver, hanem egy ws2012R2rras) és simán ment kifelé a ping.
Beraksz nekem két képet?
Az egyik a Cisco VPN beállítás oldala a másik pedig a külső gép VPN hálózati beállítások oldala amikor kapcsolódva van. -
VeryByte
őstag
válasz
Des1gnR
#31703
üzenetére
Mondjuk az ott nem is nagyon fog mást kapni.
Egyébként miért szeretnél kifelé ping-elni?
Ugye alapfeltevés, hogy kintről jödssz be egy belső hálóba, tehát ez így teljesen jó.@Smktrooper
Ha IP címmel próbálkozik, akkor mi szerepük lenne a DNS beállításoknak?
Mindegy, ne ragozzuk. -
Des1gnR
őstag
válasz
VeryByte
#31700
üzenetére
Ezekkel már próbálkoztam korábban és utána kikapcsolt tűzfallal is, de sajnos nem segített. Jelenleg is ki vannak kapcsolva a tűzfalak mindkét gépen.
Ha a PC2-vel akarom pingelni a PC1-et, akkor ezt kapom:
Reply From < IP address >: Destination Host UnreachablePC1 csatlakozás utáni adatai:
, a fahéj is max azért mert nem veszed észre amíg letölt ha tüsszentesz tőle....Az elérési idő keresztmetszete mindig a NAT chippeken fog múlni, az meg jelenleg 0-2ms közötti tartományban dolgozik.
illetve bővebben ki tudnád fejteni, hogy mit hogyan kell?
)
lanon és wifin is van internet. IPTV boxot is csatlakoztatnék hozzá, 
Új hozzászólás Aktív témák
MaCS_70- Autós topik
- One mobilszolgáltatások
- Kerékpárosok, bringások ide!
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Mibe tegyem a megtakarításaimat?
- Luck Dragon: Asszociációs játék. :)
- AMD Navi Radeon™ RX 9xxx sorozat
- Graphics: Hello Moto! - Kipróbáltam a Motorola Moto G55 5G-t. (videó is)
- Google Pixel 9a - a lapos munka
- Vége: a kínai platformok nem adják vissza a pénzt visszaküldött áru nélkül
- További aktív témák...
- Újszerű Asus Rog Ally Z1 Extreme 512Gb SSD+Ajándék tok!
- JBL PartyBox 200 használt bluetooth hangfal! Erőteljes hangzás!
- AKCIÓ ÚJ Bontatlan Macbook Pro 16 M4 Pro 14CPU/20GPU 24GB/512GB SSD Magyar billent Azonnal átvehető.
- Lenovo ThinkPad P15 Tervező Vágó Laptop -50% 15,6" i7-10850H 64/512 QUADRO T1000 4GB
- Lenovo ThinkPad P15 Tervező Vágó Laptop -50% 15,6" i7-10850H 32/512 QUADRO T1000 4GB
- ÁRCSÖKKENTÉS Jura Impressa C5 fehér kávégép eladó
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 16/32/64GB RAM RX 7700XT 12GB GAMER PC termékbeszámítással
- Dell Optiplex MT/SFF/Mini 3040, 3050, 3060, 3070, 5070, 7060/ Hp ProDesk /SZÁMLA- GARANCIA
- Nvidia Quadro M2000/ M4000/ P2000/ P2200/ P4000/ P5000/ RTX 4000/ RTX A2000 / RTX A4000
- iPhone 15 Pro 128GB, Szép állapot, Független, 100%, Garanciával!
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest