Új hozzászólás Aktív témák
-
válasz janos666 #18438 üzenetére
Talán érthetőbben megfogalmazva:
Az itthoni gépemen akarok indítani egy webserver-t, ami egy egyszerű, akár komolyabb mobiltelefonos böngészőből is elérhető és kellően sűrű mintavételezéssel/frissítéssel dolgozik (~15-30fps kéne a lag miatt).
Bár lehetne ez egy videó stream is, olyan felbontással és formátumban, amire egy telefon is rá tud kattanni, a lényeg, hogy a PC monitor aktuális képét közvetítse minimális késéssel, és helyi hálózaton belül is közvetlenül elérhető legyen egy IP címről (a wifi routerhez csatlakozó PC és mobil közé ne ékelődjön be az internet).
És alkalmankénti kis lag nem gond, annyira értelmes a software, hogy felismeri, mikor félremér (besaccolja hogy mi lehetséges egy nézhető monitoron, és eldobja azt, ami nem tűnik annak).
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
-
btz
addikt
válasz janos666 #31049 üzenetére
Nekem univerzális repeater relayd módban van megoldva (nem wds) a hálózat, annyit vesz le a sebességből, amenyit a kapcsolódáshoz használ, de ez úgylátom, hogy dinamikusan változik. Mellette a wifire kapcsolódó stick is ugyan úgy n szabvány szerint 300mbps linksebességgel felcsatlakozik arra a routerre ami 270-250 mbps sebességgel felcsatlakozik a router 1.-re, adatforgalomkor a duplájával dolgozik mindig, ez igaz, de ez nem mindíg egyenlő a teljessávszél felével, tehát nincs előre lezárva 300mbpsből 150mbps, ha mondjuk nincs adatforgalom.
Gyárival biztos van sok olyan amin nem megy a repeater mód, de CFW alatt a legtöbbel megoldható legalább egy repeater mód. (Nem a wdsről beszélek, hanem a repeater módról, amikor a 2. Router ügyfélként kapcsolódik az 1. Routerre, és az nem tudja hogy repeatelve van).
Az erősebb AP-ra kapcsolódás dolgot én kliensoldali beállításokkal oldottam meg. Ha a jelszint X érték alá csökken, akkor automatikusan vált az erősebb APra, az állapotot X időnként scanneli. Egy házon belül nekem mindig reális időn bellül mindig arra az APra váltott, amelyikhez fizikálisan is közelebb vagyok.[ Szerkesztve ]
ⓑⓣⓩ
-
Soma01
veterán
válasz janos666 #31472 üzenetére
Szerintem az mindegy, hogy TCP vagy UDP, mert mind a kettő IP csomagokba van berakva. Tehát szerintem nem az a baj. Azt kellene megnézni, hogy egy darab kamerával is ilyen-e. A sávszélesség igényt tisztázni kellene, mert én olvastam a neten több, 3-4 megabájt per másodpercről is és nem 6 megabitről. Szerintem a csomagveszteség nem lehet nagy baj ha tud 100 Mbps felett is menni a hálózat. Milyen kamerák ezek? HD? Felbontás?
-
Soma01
veterán
válasz janos666 #31486 üzenetére
Elég stabil az adatfolyam wifin? Lehet ott bezavar valami. Gondolom csatornát már próbáltál váltani. Meg hát gondolom, az 5 GHz nem olyan telített, bár városban már vannak ott is elég sokan.
Mikrotik-hez mennyire értesz? Tudsz segítséget kérni, hogy valaki nézze át a beállításokat? Kisebb csomagmérettel nem jobb az átvitel (MTU vagy hogy hívják)?
Ahol vetted a Mikrotik-et ott lehet telefonon is tudnak segíteni.[ Szerkesztve ]
-
Soma01
veterán
válasz janos666 #31488 üzenetére
Valahol a wifivel lehet a baj szerintem is. De nagyon furcsa ez nekem... Mindkét telephelyen ez a jelenség?
Ha stabil a kapcsolat, akkor passzolom.
Lehet a switch is rossz amúgy. Írtad, hogy 2,4-es AP is van a kameráknál. Ha azokra csatlakozol, akkor mi van, hogy megy? -
Soma01
veterán
válasz janos666 #31495 üzenetére
Akkor tiszta, világos már minden. Az STX-ekkel van a gond. Illetve ott vész el valahogy a jel. De úgy látom már haladsz vele. Gondoltam én, hogy ott a Mikrotiken belül lesz a gond és biztosan lehet állítani rajta... Szerintem maradjon a 40Mhz széles csatorna, ott lesz tartalék és senkit sem zavarsz vele.
A NAT-olással miért javulna bármi is?
Esetleg azt lehetne megnézni az STX-eken, hogy milyen módban vannak. AP, Kliens... Úgy kellene, hogy 1-1 pár össze legyen lőve és ne is foglalkozzon mással. A másik pár AP gondolom eléggé eltérő csatornán van, ugye?
-
válasz janos666 #31560 üzenetére
Hát nem.
TCP-vel véletlenszerűen, de túl sűrűn teljesen bontódik a kapcsolat (néha végigbírja az 1 órát, ahol az ffmpeg újraindul, hogy új file-t kezdjen, máskor egymás után többször is leáll 1-3 percenként) úgy, mint ami jól végezte dolgát (debug loglevel mellett sincs semmi hibaüzenet, csak kiírja zöld betűkkel az ffmpeg, hogy nincs tovább mit kiírni, ezért leáll).
Gyanítom, hogy ugyan az a véletlenszerű esemény következik be, mikor TCP-vel teljesen bontódik, mint amikor UDP-vel zagyvasággá válik a rögzített anyag.
Kipróbáltam a HTTP-tunneling módot is (az UDP_Multicast módtól amúgy sem várnék sikert, de egyik kamera sem támogatja, több opció pedig már nincs az RTSP szabványban), ami elsőre biztató, de ezt 9-ből csak 5 kamera támogatja (a szenzor és az encoder chip elvileg ugyan az mind a 9-ben, de a firmware más, a frissebbik 4 nem válaszol a HTTP kérésre).
Lehet, hogy az lesz a vége, hogy mindkét helyen le kell tennem valami olyasmit, mint pl. egy Raspberry Pi, amin egy Samba share-be dolgozik az ffmpeg.
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz janos666 #31592 üzenetére
Ezt ideteszem, hátha másnak is lesz még hasonló problémája...
A protokoll 802.11 vagy NV2 helyett Nstreme, de [dynamic size] helyett [best fit] framer és 3200 helyett 1524 framer limit (ezt az értéket empirikus alapon kellett iterálással belőnöm, de tudtam, hogy 1500<=X<=1536, amit keresek, mert 1500 az ethernet MTU és alapértékekkel nekifutva, mikor egy pillanatra rá tudtam pislantani a sűrű szakadozás közepette, akkor épp 1536-ra lőtte be magát a dynamic). Így nincs torlódás a wireless hídon.
Plusz mindezek fejében az RTSP-től az alapértelmezett UDP helyett TCP kapcsolatot kell kérni az adatcsomagokhoz is, és akkor nincs effektív packet loss se (csak szép nagy extra forgalom az ACK-k miatt, de ez úgyis egy erre dedikált és bőségesen tág vonal, szóval elférnek...).Az Nstreme a Mikrotik sajátja, de más hasonló gyártóknál is lehet hasonló egyedi megoldás, aminél van ilyen lehetőség, illetve talán 802.11-hez is beállítható valamiképp az effektív frame size, mert végül is ez a kulcs (és itt azért érdekes az nstreme, mert itt ez engedte ezt manuálisan szabályozni, hogy megolajozhassam a hidat és kisimuljon a forgalom).
Nem volt egyszerű történet.
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Topikgazda
-
Smktrooper
senior tag
-
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.htmlReboot
-
-
válasz janos666 #41775 üzenetére
Hopsz, a második kérdést végül is megválaszoltam magamnak, a GRO tehet róla, de a fura az, hogy ha akkor tiltom csak le a GRO-t, ha már fut az iperf, akkor linux szerver oldalon mindkét CPU mag ~100%-on dolgozik (kis Pentium G4400) és ~8Gbps-t mérek, míg ha úgy indítom az iperf-et, hogy már tiltva van a GRO, akkor az egyik mag gyakorlatilag idle, és a felére esik a mért sebesség. Ez valami nem várt, vagy ismert jelenség? Van rá valami áthidaló megoldás?
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
MasterMark
titán
válasz janos666 #66270 üzenetére
Stateful firewall tud olyat hogy te tudj hozzájuk szólni a másik lan-ba, ők tudnak is válaszolni neked, viszont ők ne mehessenek ki róla.
Egy normális router kell hozzá.
szerk.: Ha szerver a routered, milyen OS van rajta hozzá? Vagy natívban linuxon csinálod kézzel? Egy OPNsense jobb lenne, vagy valami kifejezetten routernek való OS. (VyOS pl.)
szerk.2: A wifit meg kitaláltad ahhoz csak annyi kell hogy külön SSID-n legyenek, külön hálón.
[ Szerkesztve ]
Switch Tax
-
csaszi75
senior tag
válasz janos666 #66270 üzenetére
Létezik olyan klíma, amit tudsz csak lokálisban kezelni a lokális hálózatodról?
Amúgy erre csakis egy elszeparált külön hálózatot tudok elképzelni.
Vagyis külön router.. és arra mennek a régi eszközeid.. S ebbe a routerbe pedig beteszel egy sima WinPC-t, aminek dupla LAN-ja van.. egyik kifelé a net felé, a másik befelé a speckó zárt routered felé.. -
MasterMark
titán
válasz janos666 #66272 üzenetére
De hol a tűzfal? Nincs tűzfalad a net fele? Vagy simán csak iptables? Vagy mi csinálja a natolást? Az is iptables?
Nem kell két kábel, mert 1 kábelen az összes VLAN mehet. (Trunk port ciscos nevezéktannal.)
csaszi75: Felesleges erre teljesen külön háló, és csak magadat szivatod ezzel.
[ Szerkesztve ]
Switch Tax
-
MasterMark
titán
válasz janos666 #66275 üzenetére
A Gentoo-s x86 PC NAT-ol, iptables-el tűzfalaz
És ez ilyen önostorozó fakír setup, vagy miért jó így? iptables-el is el tudod tűzfalazni, de azzal azért nem olyan egyszerű.
Egy VM-ben mehetne rá valami rendes tűzfal OS aminek odaadod a hálókártyát passthrough-ban.
szerk.: A net elérés nekem úgy van megoldva az IoT vlan-on, hogy kézzel amit engedek az kimehet netre külön úton, amit nem az nem. Alapból semmi nem mehet ki ami a hálóra kerül. Van pár dolog ami csak úgy működik ha a kínai gateway-jel kommunikál.
[ Szerkesztve ]
Switch Tax
-
MasterMark
titán
válasz janos666 #66277 üzenetére
Tök jó, de a routernek akkor is kéne egy rendes OS, különben szívás lesz mindenhogy.
VPN-re: wireguard.
Weboldalhoz reverse proxy: nginx, CDN: cloudflareszerk.:
Az akkori megfizethető SoHo router dobozok rohadtul nem bírták a QoS-t / traffic shaping-et lekezelni az internetcsomag sebességén pl. sok torrent futtatása mellett.
Ezt most mi csinálja nálad? Ha van elég gyors neted akkor ezek kb. feleslegesek legtöbbször.[ Szerkesztve ]
Switch Tax
-
MasterMark
titán
válasz janos666 #66279 üzenetére
Wireguardnak jó a kliense windowson is meg androidon is. Szerintem emiatt nem érdemes mást csinálni, sokkal bonyolultabb a setupja egy IKEv2-nek, és nem is működik olyan jól.
szerk.: Nem a hardvert kérdezem, hanem milyen szoftver csinálja ezeket az a kérdés. Csak azért kérdés amúgy, mert kézzel az iptablesbe állítgatni az nagyon advanced dolog. Erre szoktak lenni szoftverek amit bekonfigolsz, ő meg megcsinálja az iptables konfigot hozzá.
Traffic shapinget meg QoS-t gondolom nem tud alapból a Gentoo, bár nem ismerem, de rákeresve ez egy full generic disztró.[ Szerkesztve ]
Switch Tax
-
MasterMark
titán
válasz janos666 #66283 üzenetére
- 1 kábel kell, erre válaszoltam amúgy.
- Stateful tűzfal kell a saját és a másik hálózat között, hogy te tudj hozzá beszélni, de ő ne érje el a túloldalt. Ezt is leírtam amúgy.
A netet meg hagyhatod neki nyitva vagy zárva ahogy tetszik, vagy ami az eszköznek kell.
[ Szerkesztve ]
Switch Tax
-
snyper990
őstag
válasz janos666 #66322 üzenetére
Pont azért lenne szerencsésebb inkább optikai kábel, ha elektromos vezeték mellett fut. Az UTP-ben fém erek vannak, amikben az elektromos vezetéken folyó áram által létrehozott változó mágneses tér feszültséget indukálhat
(Magyarországon pedig a hálózati feszültség 230V már egy jó ideje)[ Szerkesztve ]
-
snyper990
őstag
válasz janos666 #66330 üzenetére
Sokmindentől függ, mekkora feszültség indukálódhat az UTP/STP erein. Lehet, hogy zavar, bár valószínűleg nem (elég alacsony frekvencia a kábelen futó jelekhez képest). Viszont az biztos, hogy olyan feszültség jelenhet meg a kábelen, amire egyrészt az eszközök sincsenek felkészítve, másrészt az sem, aki egyszer véletlenül valahogy hozzáér az erekhez vagy a kábel végén lévő érintkezőkhöz.
STP-hez tudtommal olyan eszközök kellenek, amik fel vannak készítve árnyékolt RJ45 csatlakozó fogadására (földelt aljzatokkal). Ha nincs földelve az árnyékolás, kb. olyan, mintha nem is lenne (illetve talán még rosszabb, mert elektromos kapacitása van a földhöz képest; jobb esetben nem zavar be, de ha nagyobb feszültség kerül rá, kiszámíthatatlan, hogy az hol fog utat találni magának a föld felé). Ha csak az egyik végét földeled, készítettél egy antennát, ami szintén nem optimális. Ha mindkét végét földeled, azt sem mindegy, hogyan teszed.
STP-nek vagy érdemes rendesen utánaolvasni, vagy inkább hagyni. Otthoni felhasználásra kb. teljesen felesleges. -
snyper990
őstag
válasz janos666 #66332 üzenetére
A SOHO hálózati eszközök jelentős részén műanyag az egész foglalat. Szolgáltatói HGW-k aljzatain jellemzően szintén. Laptopokon is többnyire.
Nem írtam sehol, hogy kivitelezhetetlen. Csak arra próbáltam rávilágítani, hogy utána kell olvasni, hogyan kell jól használni, és a hálózat tervezésénél figyelembe kell venni.
De mivel otthoni környezetben nem sok haszna van, szerintem jobb/egyszerűbb inkább kerülni.