- Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Egy korszak vége
- Keringető szivattyú vezérlése: még okosabb fűtés
- Asszociációs játék. :)
- Szólánc.
- Fűzzük össze a szavakat :)
- Digitális Állampolgárság Program
- Megoldások IBS/IBD-re
- CTEK akkumulátor töltő és másolatai
- PLEX: multimédia az egész lakásban
-
LOGOUT.hu
Haladó szintű hálózati témák topikja
Új hozzászólás Aktív témák
-
#9996
sziszi-fuszi
senior tag
bigrock
#9993
sziszi-fuszi
senior tag
válasz
bigrock
#9993
üzenetére
Az "A" és 'B" épület közé optikai gerinc (ez fejleszthető a későbbiekben a legegyszerűbben, ha sávszélt lehet, vagy kell növelni), illetve ennél a megoldásnál megmarad annak a lehetősége, hogy "A" épületben is switch-elni lehessen, ha arra szükség volna. Majd B épületben is switch-eln. Ez arra az esetre is jó lehet ha mindkét épületben lennének gépek, amit a hálózatra kell kötni és ezeknek a gépeknek akár egymást is látniuk kell. Ehhez csupán megfelelő switcheket kell beépíteni, amelyek rendelkeznek SFP vagy SFP+ portokkal.
Mi alá kell írás?
-
#9994
st3v3np3t3r
nagyúr
bigrock
#9993
-
bigrock
addikt
Üdv mindenkinek!
Van két épület egymással szemben, 10 méter a távolság a kettő között.
"A" épületben van bejövő internet, "B" épületben pedig kb. 20 db. irodai kliens PC-t kellene ellátni ezzel a nettel. Mi a leginkább javasolt megoldás?
1. "A" épületébe nagy switch, innen "B" épület összes gépét egyenként kábelen ellátni (a leghosszabb távolság sincs 80 méternél több)
2. "A" épületet és "B" épületet Cat6 gerinc kábellel összekötni és "B" épületben switchelni?
3. Ugyanez, csak optikai kábellel?
A két épület között védőcső van, földben.
Köszi a válaszokat! -
zolee001
őstag
válasz
Doky586
#9991
üzenetére
A megfelelö alkalmazással igen,mivel valahol egy dns bejegyzés történik ami pont ezért van
Egyébként meg kit érdekel?
Ha a public dns servered (ami ha ddns név akkor vicc) saját gépeden hostolod akkor akkor az a igy járás kategória
WHOIS Server: whois.srsplus.com
Registrar URL: http://www.srsplus.com
Updated Date: 2020-02-07T16:50:29Z
Creation Date: 2001-06-28T16:04:59Z
Registry Expiry Date: 2022-06-28T16:04:59Z
Registrar: TLDS L.L.C. d/b/a SRSPlus
Registrar IANA ID: 320
Registrar Abuse Contact Email: abuse@web.com
Registrar Abuse Contact Phone: +1.8003337680
Domain Status: clientTransferProhibited https://icann.org/epp#clientTr
rohibited
Name Server: NF1.NO-IP.COM
Name Server: NF2.NO-IP.COM
Name Server: NF3.NO-IP.COM
Name Server: NF4.NO-IP.COM
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.or>>> Last update of whois database: 2020-11-02T01:41:29Z <<<
For more information on Whois status codes, please visit https://icann.or
NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry i
currently set to expire. This date does not necessarily reflect the expir
date of the domain name registrant's agreement with the sponsoring
registrar. Users may consult the sponsoring registrar's Whois database t
view the registrar's reported date of expiration for this registration.TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-volume and
automated except as reasonably necessary to register domain names or
modify existing registrations; the Data in VeriSign Global Registry
Services' ("VeriSign") Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information
about or related to a domain name registration record. VeriSign does not
guarantee its accuracy. By submitting a Whois query, you agree to abide
by the following terms of use: You agree that you may use this Data only
for lawful purposes and that under no circumstances will you use this Dat
to: (1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail, telephon
or facsimile; or (2) enable high volume, automated, electronic processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly
prohibited without the prior written consent of VeriSign. You agree not t
use electronic processes that are automated and high-volume to access or
query the Whois database except as reasonably necessary to register
domain names or modify existing registrations. VeriSign reserves the righ
to restrict your access to the Whois database in its sole discretion to e
operational stability. VeriSign may restrict or terminate your access to
Whois database for failure to abide by these terms of use. VeriSign
reserves the right to modify these terms at any time.The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.Connecting to whois.srsplus.com...
WHOIS Server: whois.srsplus.com
Registrar URL: http://srsplus.com
Updated Date: 2020-02-07T16:50:29Z
Creation Date: 2001-06-28T16:04:59Z
Registrar Registration Expiration Date: 2022-06-28T16:04:59Z
Registrar: TLDS LLC. d/b/a SRSPlus
Registrar IANA ID: 320
Reseller:
Domain Status: clientTransferProhibited http://icann.org/epp#clientTransf
bited
Registry Registrant ID:
Registrant Name: Dan Durrer
Registrant Organization: No-IP.com
Registrant Street: 425 Maestro Dr. Second Floor
Registrant City: Reno
Registrant State/Province: NV
Registrant Postal Code: 89511
Registrant Country: US
Registrant Phone: +1.7758531883
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: domains@no-ip.com
Registry Admin ID:
Admin Name: Dan Durrer
Admin Organization: No-IP.com
Admin Street: 425 Maestro Dr. Second Floor
Admin City: Reno
Admin State/Province: NV
Admin Postal Code: 89511
Admin Country: US
Admin Phone: +1.7758531883
Admin Phone Ext:
Admin Fax:
Admin Fax Ext:
Admin Email: domains@no-ip.com
Registry Tech ID:
Tech Name: Dan Durrer
Tech Organization: No-IP.com
Tech Street: 425 Maestro Dr. Second Floor
Tech City: Reno
Tech State/Province: NV
Tech Postal Code: 89511
Tech Country: US
Tech Phone: +1.7758531883
Tech Phone Ext:
Tech Fax:
Tech Fax Ext:
Tech Email: domains@no-ip.com
Name Server: nf2.no-ip.com
Name Server: nf1.no-ip.com
Name Server: nf4.no-ip.com
Name Server: nf3.no-ip.com
DNSSEC: Unsigned
Registrar Abuse Contact Email: abuse@web.com
Registrar Abuse Contact Phone: +1.8773812449
URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.intern>>> Last update of WHOIS database: 2020-11-02T01:41:43Z <<<
For more information on Whois status codes, please visit https://www.ican
esources/pages/epp-status-codes-2014-06-16-en.The data in SRSPlus's WHOIS database is provided to you by
SRSPlus for information purposes only, that is, to assist you in
obtaining information about or related to a domain name registration
record. SRSPlus makes this information available "as is," and
does not guarantee its accuracy. By submitting a WHOIS query, you
agree that you will use this data only for lawful purposes and that,
under no circumstances will you use this data to: (1) allow, enable,
or otherwise support the transmission of mass unsolicited, commercial
advertising or solicitations via direct mail, electronic mail, or by
telephone; or (2) enable high volume, automated, electronic processes
that apply to SRSPlus (or its systems). The compilation,
repackaging, dissemination or other use of this data is expressly
prohibited without the prior written consent of SRSPlus.
SRSPlus reserves the right to modify these terms at any time.
By submitting this query, you agree to abide by these terms.Domain Name: ddns.net
Registry Domain ID: 73816572_DOMAIN_NET-VRSN
Registrar WHOIS Server: whois.srsplus.com
Registrar URL: http://srsplus.com
Updated Date: 2020-02-07T16:50:29Z
Creation Date: 2001-06-28T16:04:59Z
Registrar Registration Expiration Date: 2022-06-28T16:04:59Z
Registrar: TLDS LLC. d/b/a SRSPlus
Registrar IANA ID: 320
Reseller:
Domain Status: clientTransferProhibited http://icann.org/epp#clientTransf
bited
Registry Registrant ID:
Registrant Name: Dan Durrer
Registrant Organization: No-IP.com
Registrant Street: 425 Maestro Dr. Second Floor
Registrant City: Reno
Registrant State/Province: NV
Registrant Postal Code: 89511
Registrant Country: US
Registrant Phone: +1.7758531883
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: domains@no-ip.com
Registry Admin ID:
Admin Name: Dan Durrer
Admin Organization: No-IP.com
Admin Street: 425 Maestro Dr. Second Floor
Admin City: Reno
Admin State/Province: NV
Admin Postal Code: 89511
Admin Country: US
Admin Phone: +1.7758531883
Admin Phone Ext:
Admin Fax:
Admin Fax Ext:
Admin Email: domains@no-ip.com
Registry Tech ID:
Tech Name: Dan Durrer
Tech Organization: No-IP.com
Tech Street: 425 Maestro Dr. Second Floor
Tech City: Reno
Tech State/Province: NV
Tech Postal Code: 89511
Tech Country: US
Tech Phone: +1.7758531883
Tech Phone Ext:
Tech Fax:
Tech Fax Ext:
Tech Email: domains@no-ip.com
Name Server: nf2.no-ip.com
Name Server: nf1.no-ip.com
Name Server: nf4.no-ip.com
Name Server: nf3.no-ip.com
DNSSEC: Unsigned
Registrar Abuse Contact Email: abuse@web.com
Registrar Abuse Contact Phone: +1.8773812449
URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.intern>>> Last update of WHOIS database: 2020-11-02T01:41:43Z <<<
For more information on Whois status codes, please visit https://www.ican
esources/pages/epp-status-codes-2014-06-16-en.The data in SRSPlus's WHOIS database is provided to you by
SRSPlus for information purposes only, that is, to assist you in
obtaining information about or related to a domain name registration
record. SRSPlus makes this information available "as is," and
does not guarantee its accuracy. By submitting a WHOIS query, you
agree that you will use this data only for lawful purposes and that,
under no circumstances will you use this data to: (1) allow, enable,
or otherwise support the transmission of mass unsolicited, commercial
advertising or solicitations via direct mail, electronic mail, or by
telephone; or (2) enable high volume, automated, electronic processes
that apply to SRSPlus (or its systems). The compilation,
repackaging, dissemination or other use of this data is expressly
prohibited without the prior written consent of SRSPlus.
SRSPlus reserves the right to modify these terms at any time.
By submitting this query, you agree to abide by these terms. -
Ha ismert a publikus IP címem abból ki lehet deríteni hogy milyen free DDNS nevet regisztráltam hozzá? (mármint mások kideríthetik-e)
Aping -a ipcimparancs nyilván nem mutatja meg. -
Az aktív mód csak LAN-on belül működik.
Interneten (nat-olt háló és nat-olt háló közt) csak passzív módú FTP (és FTPS) működhet, ahhoz pedig nemcsak egy port hanem a megadott porttartományt is forwardolni kell server oldalon. Kliens oldalon semmit se kell állítani.[ Szerkesztve ]
-
milan26
senior tag
-
milan26
senior tag
Sziasztok!
Tud valaki segíteni? FTP szervert próbálok beüzemelni, de végül hibába ütközöm.
Portot nyitottam neki amit kiengedtem a routeren, majd engedélyeztem a windows tűzfalban az FTP protokollt, a port így működik is. Felhasználót is megcsináltam, be is enged, de a szerver nem válaszol a kliensnek, így bontódik a kapcsolat.
-
#9973
beteg
őstag
MasterMark
#9972
beteg
őstag
válasz
MasterMark
#9972
üzenetére
Igen, mivel sem egy figyelmeztetés, risaztás nem jött, látni sincs lehetőségem sehol, hogy kik vannak kitiltva, a weboldal sem közli, a telefonmra pedig elsőre elküldtek az internet szolgáltatóhoz, én most azonnal ott hagynám őket.
De akinek segítek, akié az olal, nem is értette, hogy mi bajom van, azt mondta, hogy emiatt ne menjünk el.
Ő egy világklasszis sportolónk, én csak segítek neki ezzel, hogy csinálgatom az oldalát. Jó türelmes.
Csak futni kell!
-
beteg
őstag
Le volt tíltva a az adott gép külső ip címe a tárhely szolgáltatónál.
Mondjuk az gyanús lehetett volna nekem, hogy arról a gépről megpingelve a doman nevet visszajött az ip címe, csak nem válaszolt. Nálam, ahol bejött az oldal pedig válaszolt.Na mindegy. Legalább kicsit összeszedtem még egy kis hálózatos ismeretet
Tőletek elnézést!Csak futni kell!
-
#9970
MasterMark
titán
mtz81
#9969
-
mtz81
tag
Dns teszt win-nel:
nslookup xy.com - default DNS-sel
nslookup xy.com 8.8.8.8 - google DNS-sel (bármelyik dns ip-jét használhatod)Így tudod tesztelni, hogy melyik DNS nem oldja fel rendesen a nevet.
Az xy.com-ra visszakapott ip-t, ha tudod pingelni mindenhonnan, akkor valami DNS hiba van
[ Szerkesztve ]
-
#9968
beteg
őstag
MasterMark
#9966
beteg
őstag
válasz
MasterMark
#9966
üzenetére
Köszi mindenkinek a segítséget!Még nincs meg a megoldás, de beszéltem most megint a tárhelyszolgáltatóval és úgy néz ki, hogy az lehet az ok, hogy náluk van blokkolva az adott ip cím. Most utána néznek.
Szóval lehet, hogy nem is hálózatos hiba. Akkor bocsánat!
Csak futni kell!
-
inf3rno
nagyúr
Nem teljesen világos, de van olyan, hogy full ugyanazzal az eszközzel nézed, és mondjuk wifivel nem jön be, de mobilnettel igen? Mert akkor a böngésző típusát kapásból kizárhatjuk, és az IP tartomány tiltása marad esetleg, ami a webszolgáltatónál hiba lehet. Ha valami kisebb internetszolgáltató, akkor ott lehetnek érdekességek, állítólag van olyan, hogy a fél világon keresztülmennek a csomagjaid ahhoz, hogy egy magyar oldalt elérj, mert olcsóbb vagy egyszerűbb így nekik, mint egy másik magyar internetszolgáltatónak átadni a csomagot közvetlenül.
Buliban hasznos! =]
-
beteg
őstag
válasz
inf3rno
#9964
üzenetére
Muszáj kiderítenem, megírom majd, hogy mi volt.
még adalék: olyan eszközről sem jön be az adott wifin, amiről máshol bejön.
modem reset sem segített
nem magával a weboldallal van gond, hanem valamilyen tartománnyal, mert más oldal, ami ugyan ott van, sem jön be.
flushdns és barátai sem
Most beszélek még egyszer mind a két szolgáltatóval.Azért köszi!
Csak futni kell!
-
inf3rno
nagyúr
Hát én sajnos még nem értek a hálózatozáshoz, úgyhogy nincs más ötletem. Olvastam már hasonlót régebben mástól is, és ugyanígy webes szolgáltató oldala nem volt elérhető, de azt nem tudom, hogy ugyanez a szolgáltató volt e vagy másik. Mindenesetre elég fura, hogy ilyen előfordul, érdekelne engem is, hogy miért, mert nem túl logikus. Ha internet szolgáltató okozza, akkor esetleg valahol elakadnak a csomagok, de akkor más oldalak is elérhetetlenek lennének (ez mondjuk nem tűnik fel, ha nem látogatod őket és csak néhány oldalról van szó). Ha a webszolgáltató okozza, akkor pl olyanra tudok gondolni, hogy bizonyos IP tartományokat blokkolnak, vagy bizonyos böngészőket, vagy ilyesmi.
[ Szerkesztve ]
Buliban hasznos! =]
-
beteg
őstag
Sziasztok!
Van itt tapasztaltabb hálózatos szakértő?
Segítséget szeretnék kérni, hogyan tudnám kideríteni, hogy kinél van a hiba.
Az a problémám, hogy a profitárhely nevű webtárhely szolgáltatóm webes adminisztrációs felületét és a náluk tárolt weboldalaimat rendszeresen nem tudom elérni a digis netemről, timed out üzenetet adnak.
Ugyan ezeket az oldalakat közben mobil netről el lehet érni. Pontosabban jellemzően el lehet érni telekomos mobil netről. Közben ismerősöm, akinek upc-s nete van, eléri őket, bejönnek a weboldalak. De rendszeresen van olyan, hogy neki nem mennek, nekem pedig mennek. Most például egyikünknek sem.
Próbáltuk vpn-el. Az általában segít, de nem mindig. Próbáltuk inkognitó ablakban és másik böngészőből is, az egyáltalán nem segít.
Beszéltem a tárhely szolgáltatóval, szerintük a net szolgáltató a hibás. Beszéltünk a net szolgáltatókkal, szerintük a tárhelyesek a hibásak.
Nálam a digis modem újraindítása segíteni szokott, olyankor egy ideig megy rendesen. A upc-s modem restartja nem segít.
Nem nyitom megy extrém sokszor a weboldalakat, sok oldalt ezerszer többször töltök le egy nap. Más oldalnál még nem jelentkezett ez a hiba.
Mire gyanakodjak, mi után kutassak, mi lehet a bizonyíték?
Köszi!!!
Csak futni kell!
-
#9958
R̲e̲m̲
senior tag
MasterMark
#9957
R̲e̲m̲
senior tag
válasz
MasterMark
#9957
üzenetére
remélhetőleg nem lesz gondja...
HP microserver g8, hp kártya, hp transceiverek, hp switch...
az kéne már csak, hogy összevesszen saját magával...
köszönöm a választ![ Szerkesztve ]
-
Sajnos nem.
Több olyan ügyem is volt, amelyben a rendőrségnek a szolgáltató által kiadott IP-cím teljesen fals volt. Egy ember ezért majdnem nagyon hosszú időre mehetett volna börtönbe, ha nincs nagyon biztos alibije.
Sosem derült ki, hogy mi állt a háttérben.
MaCS
Fán nem lehet motorozni, motoron viszont lehet fázni!
-
SP4C3
veterán
Nekem gyanús, hogy valaki szórakozik veled.
Legközelebb udvariasan kérd, hogy igazolják magukat..[ Szerkesztve ]
-JNA- Yugoslav National Army // ⍟T-34-85⍟ // MSI H81M-P33 / Intel Xeon E3-1220 v3 @ 3.5GHz / 16GB DDR3 @ 1600MHz / Gigabyte RX470 4GB. sp4c3.speedtestcustom.com
-
Y72
aktív tag
Üdv,
Lehet nem teljesen ide tartozik ez, de hátha tud valaki segíteni:
Rendőrség jött hajnali 3-kor és érdeklődtek hogy minden rendben van-e mert Washington-ból kaptak egy értesítést, hogy az adott IP cím alapján öngyilkosság/gyilkossági kísérlet valószínűsíthető. Már 3x jöttek ki és végül mutattak egy IP címet de az nem az enyém volt.
Mit lehet tenni ill. hogy lehet visszanézni hogy tényleg itt van-e a probléma? (mármint nem a gyilkossági ).
Lehet ez vírus?
Biztos jól azonosították be az IP-t? -
bambano
titán
válasz
inf3rno
#9946
üzenetére
de melyik gép, milyen portokat, hogy nyit, és ha bejönnek rajta, mit tudnak csinálni?
mert ez így eléggé szakmaiatlan.
ha nincs a conntrack táblában bejegyzés, akkor nem jönnek be sehova, leperegnek a tűzfalról, mint biliről a zománc.
ha be van forwardolva egy port, akkor azon be lehet jönni, és lehet a célszervert túlterhelni. de arra lehet rate limitet csinálni, és akkor megint zománc.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
inf3rno
nagyúr
válasz
Ripper17
#9944
üzenetére
Az a baj, hogy én sem. Információbiztonságot tanulok, ott mondta az előadó, de részletekbe nem megy bele ennyire. Tűzfalakkal kapcsolatban mondta, hogy van olyan túlterheléses támadás, hogy küszködik a gép, és portokat nyit emiatt, és azon jönnek be. Sajnos bővebbet én sem tudok, most nincs időm utánanézni.
Buliban hasznos! =]
-
bambano
titán
válasz
Ripper17
#9943
üzenetére
na mégegyszer: a rendes nevén pat-nak nevezett funkció nem l4 funkció, mivel nem történik meg layer 4-es kernel funkciók meghívása és l4-es adatstruktúrák létrehozása. nem l4-ben dolgozik, attól függetlenül, hogy a csomagban l4-hez tartozó adatstruktúrákat babrál.
az egy másik tészta, hogyha raktál a tűzfalba established, related állapotra szabályt, akkor a válasz csomagokat beengedi a tűzfal, de nem nyit meg semmiféle portot, nem a router/tűzfal portjairól van szó, hanem a conntrack táblába bejegyzett portokra érvényesíti a pat inverzét.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Ripper17
tag
válasz
inf3rno
#9936
üzenetére
Én nagyvállalati routeren/tüzfalon még nem láttam arra beállítást, hogy a NAT-nál ha szükséges (lásd elözö kommentem) milyen port tartományból dolgozzon. De még csak erre vonatkozó dokumentációt sem. Pl. TCPnél a 49152-65535 között a router kifele pont úgy "választhat", mint ahogy a gépeden futó kliens szoftverek fejlesztöi megtehetik.
Alapból egy ilyen eszköz (amennyiben a device hardening megtörtént, azaz a nem használt menedzsment és vezérlö protokollok tiltása megtörtént) kívülröl amúgy is "zárt", nem pontosan értem mire gondolt aki ezt a tanácsot adta. -
Ripper17
tag
válasz
bambano
#9937
üzenetére
A lakossági routerek szintjére nem látok le, de egy "alaposan" topic ezen túlmutat.
Minden más, általam ismert esetben (SOHO és enterprise gyártók) az overloaded NAT (port address translation, a nevében is benne hogy L3+L4) müködése:
- 1 külso cím: a router lehetöség szerint a source porttal azonos portot használ. Ha erre nincs lehetöség: vegigscanneli a port tartomanyt es a legelsot allokalja hozza. A valaszuzenet miatt ezt praktikusan meg is kell nyissa kifele.
- több külsö cim eseten ugyanez tortenik, de ha az IP pool 1. cimen nincs szabad port megcsinalja a folyamatot a 2.cimre, stb.Ezt a jelenseget barmikor megnezheted, ha egy nagyobb szervezet globalis irany feloli tuzfal/router NAT tablajat megnezed.
Az egyszeru lakossagi routereknel nagy valoszinuseggel csekely azon esetek szama, ahol a local source port es a global source port nem azonos egy IPnel. De attol meg ez a tipusu NAT L3+L4 szintu forditast csinal. RFC 2663 4.1.2
-
#9942
st3v3np3t3r
nagyúr
MaCS_70
#9941
-
#9941
MaCS_70
félisten
st3v3np3t3r
#9926
válasz
st3v3np3t3r
#9926
üzenetére
A kábelfajtákról nem sok fogalmam van, de egy hasznos apró tanácsot talán adhatok:
Nagyon nem mindegy, hogy hogyan tekerik fel a kábeleket! Sok helyen az illetékes polgár egyszerűen fogja a drótot, és a kezébe mellészedve gyűjti össze. Ezzel viszont minden egyes menet egy csavarodást is tartalmaz, leszedni pedig nem ugyanezen mozdulatok inverzével fogják, hanem csak kihúzzák. Ez pedig az UTP leírásán túl csavart kábelt eredményez. Ez pedig magát a kábelt és a dugókat is extrém módon terheli.
Kézbe is lehet ugyan csavarodásmentesen összeszedni, de a korrekt megoldás a minél nagyobb átmérőjű dobra feltekerés.
MaCS
Fán nem lehet motorozni, motoron viszont lehet fázni!
-
#9940
st3v3np3t3r
nagyúr
inf3rno
#9939
válasz
inf3rno
#9939
üzenetére
Igen, lenne,ha beleférne a dobozba.
A PVC köpenyes kàbel nem rossz ötlet amúgy.
bambano: a hely kötött sajnos, plusz helyet meg nem tudok varázsolni a kábeleknek.
A hely adott, abban kell megoldanom a tárolást.
Honor Magic 6 Pro 5G 512GB//HP Victus 16+Rog Ally RC71L//Korábbi hsz-eim #97246720 név alatt...
-
#9938
bambano
titán
st3v3np3t3r
#9930
bambano
titán
válasz
st3v3np3t3r
#9930
üzenetére
"kis helyen el kell férnie,pl.egy gurulós szerszámos ládaban.": értem, de ha háromhavonta elszakad egy kábel, és te ezt már meguntad, akkor egyértelmű, hogy valamelyik igényedet változtatni kell.
én lehet, hogy vennék pár dobra tekerhető kerti locsolócsövet, belehúznék egy ethernetet és azzal kötném be a kijelzőt. meccs után meg feltekerném. az eleje meg a vége legyen száraz, a többit a cső elbírja.abban teljesen biztos vagyok, hogy nem gyártanak olyan kábelt, ami hosszabb távon is kibírja, hogy rendszeresen kis hajlítási sugárral feltekerik.
de mindenki a saját szerencséjének a kovácsa.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
válasz
Ripper17
#9932
üzenetére
NEM NYIT random portokat.
ip csomag adatstruktúrát machinál.a port nyitás nálam azt jelenti, hogy létrejönnek a socket/file descriptor és egyéb adatstruktúrák a kernelben, majd két socket között másolgatja az adatot a kernel. na ilyet nem csinál. nem is bírná egy pár mega rammal meg gagyi armos procival felszerelt házi router ezt. ilyen megoldással a hardveres nat se tudna működni.
a conntrack táblába beleírja, hogy mit mire fordított, és ha jön egy csomag, annak alapján átírja a megfelelő ip címet és tcp/udp/icmp/stb adatot, majd kiküldi. l3-ban natol, nem l4-ben
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
inf3rno
nagyúr
válasz
Ripper17
#9932
üzenetére
Ja erről már hallottam. Azt mondták, hogy ezt a random külső port nyitást kell először kikapcsolni, mert hatalmas biztonsági rés.
Köszi, nem tudtam, hogy erről van valami tábla, csak sejtettem, hogy lehet ilyen. Majd jobban utánajárok, hogy pontosan hogyan van megoldva.
Buliban hasznos! =]
-
#9935
inf3rno
nagyúr
st3v3np3t3r
#9930
inf3rno
nagyúr
válasz
st3v3np3t3r
#9930
üzenetére
Vannak kültéri kábelek, amik egy fokkal jobban bírják, esetleg azt meg lehet próbálni. Valszeg egy idő után azok is elfáradnak, és nem lesz igazán jó megoldás, be kell tervezni ezt is a költségekbe, aztán úgy összehasonlítani a wifivel.
Buliban hasznos! =]
-
Ripper17
tag
válasz
st3v3np3t3r
#9926
üzenetére
Az Igus (igus.hu) forgalmaz sokféle kábelt "heavy duty" ipari célokra. Egy emailt megér nekik a sztori.
-
Ripper17
tag
válasz
bambano
#9920
üzenetére
Igazabol a NAT is lehet tobbfele.
Ha a Layer4 is kell, mert portforditas/NAT overload van (azaz nem lehet 1:1 hozzarendeles a kulso es a belso IPk kozt) akkor a funkciot vegzo eszkoz bizony random portokat nyit a kulso lábán es ezekre terheli ra a belso forgalmat.
Tehat igazabol a TCP/UDP es az IP fejlec is modosul.Az eredeti kerdezonek: a NAT-olo eszkoz stateful, azaz a NATolasokat nyilvantartja egy NAT adatbazisban. Ennek a kezelese ami sok eroforras.
-
Ripper17
tag
válasz
inf3rno
#9921
üzenetére
A QoS azért egy nagyon komplikált témakör tud lenni.
A teljes hálózaton kell átfüzni, azaz elöbb 2. rétegben (802.11/Ethernet), aztán ha routing is van belül akkor IP-sen. és akkor még nem nyúltál le az egyes vasak buffer/queuing/scheduling mechanizmusaihoz. Tehat igazabol a QoS:
1. Besorolod a forgalmat (classification) egy szabalyrendszser szerint
2. Meghatarozod az egyes forgalmi csoportok QoS paramétereit (802.1p, DSCP/TOS, ha van wifid is akkor a wifi service class)
3. A halozati eszkozokon meghatarozod a forgalmi csoportok kezelesenek, utemezesenek, stb. modjaitértelmesebb cuccok (wifi vezerlok vagy jobb tuzfalak) tudnak alkalmazasszintu forgalom felismerest is, es igy be tudsz allitani pl. kategoriankent (pl. p2p, browsing, VoIP) prioritasokat, limiteket.
-
#9930
st3v3np3t3r
nagyúr
bambano
#9929
válasz
bambano
#9929
üzenetére
miért nem húzod védőcsőbe a kábelt? egy kábelt fel lehet tekerni védőcsővel is.
Mert mobilnak kell lennie, nem fixre telepítettnek és kis helyen el kell férnie,pl.egy gurulós szerszámos ládaban.Szerencsére olyan tipikus nézők nincsenek,akik a támadásjelzőt dobálják.
Jövőhéten felkeresem a kábelfutárt.
A vezetéknélküli rendszer állítólag kb.2-3millióba kerülne.Csak a jeladó 500-750ezer Ft,+kellene hozzá 5db jelfogó is.
Honor Magic 6 Pro 5G 512GB//HP Victus 16+Rog Ally RC71L//Korábbi hsz-eim #97246720 név alatt...
-
#9929
bambano
titán
st3v3np3t3r
#9923
bambano
titán
válasz
st3v3np3t3r
#9923
üzenetére
- ilyenkor érdemes sftp kábelt venni, mert abban az árnyékolások védenek a mechanikai hatástól is. hogy mennyire szeretik a rendszeres felcsavarást, az kétséges.
- miért nem húzod védőcsőbe a kábelt? egy kábelt fel lehet tekerni védőcsővel is.
- hívd fel ezeket: [link] telefonon.lehet, érdemes lenne megnézni, hogy a nyomok alapján ott szakadt-e el a kábel, ahol megmarta a klór. mert ha nem, akkor nem a vegyszer a problémád, hanem a tekergetés.
szerk: a vezetéknélkülire átszerelést megfontolnám, mivel ami nem drót, az zavarható. abból pedig kínos jelenetek lehetnek, ha idióta néző azzal élvezkedik, hogy babrálja a kijelzőket.
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
#9928
st3v3np3t3r
nagyúr
inf3rno
#9927
válasz
inf3rno
#9927
üzenetére
A lényeg az, hogy van 4 támadásjelző mobil ledes kijelző, amiket utp kábellel kell összekötni sorba(egyik továbbítja a másiknak a jelet)ugye ezeket ki kell tenni, meccsek végén be kell szedni, feltekerve. Az "irodai" utp kábelek ezt nem bírják,3-6havonta elszállnak. Ma is elszállt 1,tegnap 5meccs volt, azt kibírta,ma az első meccsen egyszer csak kakukk, megnéztem teszterrel, a 8érből 5 megszakadt. A klóros levegőt meg vizet azért kell bírnia, mert a medencéhez közel van és ráfröcsög a víz.
Szó esett róla, hogy vezetéknélkülire átszereltetjük, de túl költséges lenne és a vezetőség elvetette az ötletet,meg egyértelmű választ se kaptunk arra, hogy a vizilabda szabályzat mennyi késleltetést enged meg a kijelzett időben.
Az RJ45-ös csatlakozók tavaj lettek cserélve mindenhol(majdnem 25db,darabja 13ezer,speciális korróziógátló és ip védett kupakosak).Nem kaptam infót arról, hogy milyen adatprotokolt használnak a ledpanelek kommunikációjához, így még kísérleti jelleggel sem próbáltunk ki vezetéknélküli megoldást.
Honor Magic 6 Pro 5G 512GB//HP Victus 16+Rog Ally RC71L//Korábbi hsz-eim #97246720 név alatt...
-
#9927
inf3rno
nagyúr
st3v3np3t3r
#9926
inf3rno
nagyúr
válasz
st3v3np3t3r
#9926
üzenetére
A klórt úgy nézem, hogy bírja a PVC [link]. Ahogy nézem a pH sem jelent akadályt neki, erősebb lúgokat is kibír. [link]. Szóval elméletben bármelyik kültéri PVC-s kábel jó lehet. A strapabíróságot meg franc tudja. Szerintem egyik kábelt se arra tervezték, hogy szaggassák. Ha ez nagyon fontos szempont, akkor szerintem húzd be plusz egy gégecsőbe. Ez egyébként is jó ötlet lehet, mert ha kicsit is sérül, akkor beszivárog a víz, és tönkremegy. (Nem csináltam még ilyet, ez inkább educated guess.)
Buliban hasznos! =]
-
#9926
st3v3np3t3r
nagyúr
inf3rno
#9925
válasz
inf3rno
#9925
üzenetére
Uszodai víz és levegő lényegében. A víz max.1.0ppm aktív Cl és Ph 7.0-7.6ig bírja a szigetelés és flexibilis legyen.
Vizilabda támadásjelzők összekötéséhez kellene.
Ezért is írtam,hogy extrém igénybevételt kellene,hogy bírjon.Honor Magic 6 Pro 5G 512GB//HP Victus 16+Rog Ally RC71L//Korábbi hsz-eim #97246720 név alatt...
-
#9925
inf3rno
nagyúr
st3v3np3t3r
#9923
inf3rno
nagyúr
-
#9923
st3v3np3t3r
nagyúr
Üdv. Olyan utp patch kábel kellene ami bírja az extrém igénybe vételt,alkalmazható kültéren,vegyszer és vízálló. Létezik ilyen?
Honor Magic 6 Pro 5G 512GB//HP Victus 16+Rog Ally RC71L//Korábbi hsz-eim #97246720 név alatt...
-
bambano
titán
válasz
inf3rno
#9921
üzenetére
a qos azt csinálja, amit mondasz neki.
a forgalommenedzsment alaptörvénye: ott tudsz forgalmat menedzselni, ahol torlódás van. ahol nincs torlódás, ott nem lehet.
ezért van az a probléma, hogy a bejövő forgalmadat legkésőbb a szolgáltató eszközén kellene menedzselni, mert ha már hozzád beért, nincs mit kezdeni vele. a szolgáltató meg jó eséllyel nem fog hozzányúlni.a bejövő forgalmat értelmesen menedzselni nem lehet, bizonyos szinten befolyásolni lehet a kimenő nyugtacsomagok akadályozásával.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
inf3rno
nagyúr
válasz
bambano
#9920
üzenetére
Köszi!
Megnézem a conntrack táblát.
A QoS amennyire tudom prioritást ad a csomagoknak. Gondolom ha valamelyik csomag túl sokáig vár, azt eldobja, és pl egy alacsony prioritású alkalmazás nem fog működni. Én ezt kötném össze azzal, hogy melyik alkalmazás milyen fontos a cég életében, és a kevésbé fontosakat lassítanám be, vagy ha odáig jut, akkor dobatnám el. Ami most bevett eljárás, hogyha ilyen van, akkor szimplán letiltják a kevésbé fontos alkalmazásokat, és egyáltalán nem lehet használni. Szerintem viszont jobb lehet ezzel a QoS-el, mert úgy ahogy működhetnek, ha van rá lehetőség, előre meg elég nehéz kiszámolni, hogy mi az, ami még belefér a sávszélbe, és mi az, ami már nem.
Buliban hasznos! =]
-
bambano
titán
válasz
inf3rno
#9919
üzenetére
a natolásban nem az a megterhelő, hogy átírsz hat bájtot egy csomagban. az a megterhelő, hogy ha nagyobb a forgalom, akkor egy elég nagy táblázatból kell kikeresni, hogy mi legyen az a hat bájt, amit beleírsz a csomagba. hogy az ap milyen értelmezésben kerül ide, azt nem tudom.
nem nyit random portot. csak a csomagot buherálja. ha mélyebben érdekel a dolog, a conntrack táblára keress rá a gugliban.
a qos-sel egy alapvető probléma van: forgalmat szabályozni a kiindulásnál lehet. a bejövő oldalon nem, mert amit szabályozni tudnál, az már bejött. a forgalomba bele lehet piszkálni a fogadó oldalon is, de az nem mindig hatékony.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
inf3rno
nagyúr
NAT-al kapcsolatban van olyan kérdésem, amit sokadszorra sem értek. Elvileg a NAT azt csinálja, hogy belső IP-t fordít külsőre. Gondolom a TCP vagy milyen csomagokban írja át az IP-t. Na most egy otthoni hálón van egy globális IP címem, amit az ISP-től kapok. Az nem világos, hogy miért mondják azt, hogy egy AP-nél nem elég csak a DHCP-t kikapcsolni, hanem a NAT-ot is ki kell terhelés szempontjából. És nem igazán értem, hogy miért, mert nem tűnik annyira megterhelőnek a belső IP-ket átírni egy konstans IP címre, amit a szolgáltatótól kapok. Még csak választani sem kell, hogy melyik helyi IP-nek melyik külsőt adja.
A másik, ami nem világos, hogy a válasz hogyan érkezik meg a megfelelő helyre. Olyasmit olvastam, hogy a válasznak nyit egy ideiglenes random portot, ami csak az adott helyről fogad csomagot, és azon várja pl egy HTTP kérésnél. Gondolom a random portot meg hozzárendeli egy helyi IP címhez meg ott az alkalmazásnak is van egy szintén random port nyitva a válasznak. De nem vagyok biztos benne, hogy ez helytálló.
Egy harmadik ettől különálló dolog, hogyha vannak kritikus és inkább opcionális alkalmazások. Pl ügyviteli rendszer vs Bözsi böngészi a receptek.hu-t, kicsit sarkítva, akkor a QoS jó megoldás e annak a biztosítására, hogy a kritikusnak meglegyen a sávszél mindenkor? Vagy ha mondjuk backup szolgáltatóra állunk kevesebb sávszéllel, mert elszállt pl a Voda modemje, akkor jobb mindent letiltani, ami nem kritikus, és nem a QoS-re bízni, hogy elossza, ami a rendelkezésre áll?
Esetleg ezekre tudtok valamilyen választ adni?
Buliban hasznos! =]
-
felho001
tag
válasz
Gubek-Einste
#9911
üzenetére
És van egy wifi explorer pro ami ezt látja nem tudom ez segít e:
Felhő
-
felho001
tag
válasz
Gubek-Einste
#9911
üzenetére
Szia nálam van használva az eszköz otthoni környezet synology rt2600 router. amiket linkeltél hogy ezek közül kellene valamelyikkel mérni ezek közül megy valamelyik mac os en?
a kliensek tablet telefon pc mac de ezek közül mind 5ghz-re van csatlakozva. ami a 2.4-re azok inkább csak okos kapcsoló robotporszívó mosogató mosógép hangszóró zeppelin, kamera dlink. Normál lakás 10es válaszfalak vannak de ugyan ott mérek kábelen wifi 5ghz és 2.4-en is. ezek az értékek. ez a kábel: [link] ez az 5ghz iphone:
ez pedig a 2.4
Felhő
-
#9911
Gubek-Einste
titán
mtz81
#9910
Valószínűleg sok az idegen hálózat ami zavarja saját wifi-det.
Milyen környezetben (falak száma/anyaga, távolságok, szomszédok) van használva az eszközök?
Ezek közül kellene az egyikkel csinálni egy mérést a helyi viszonyokról és képernyőmentés berakni a 2,4/5 GHz-s csatorna képről.
Milyen router van használva?
Milyen kliens eszköz/adapter van használva?Egy dolog állandó: a változás - Internet powered by Vodafone Net L with CBN CH7465VF & Asus RT-AC65P
-
mtz81
tag
Olyan problémába ütköztem, hogy van egy router 2,4es és 5g wifivel.
Sebességmérésnél (speedtest.net) kábelen és 5g-s wifin is a sávszélesség rendben van, és jitter értéke is 1-5ms körül alakul. Viszont 2,4-es wifin a jitter 140ms körüli és a sávszélesség sem megy 10Mb/s fölé. Több eszközzel is teszteltük.
Mi okozhat ekkora késést?
[ Szerkesztve ]
-
mtz81
tag
Ugyan ezzel a problémával küzdöttünk a határátkelőkön (Tompa, Röszke). Aztán rátaláltunk az Antenna Hungáriára. Gyakorlatilag a semmi közepén is tudnak elfogatható netet szolgáltatni. Csak drága.
Később kiderült, hogy szolgáltatásaik elérhetőek a UPC-n (mostmár Vodafone) keresztül is, mint a UPC társszolgáltatója. Sokkal elfogadhatóbb áron.
Egy próbát megér. -
bambano
titán
biztos vannak olyan cégek, pl. a telekom összes alvállalkozója.
mindkét megoldásnál kb. az a lehetőséged, hogy:
1. mikró, és megoldod, hogy legyen rálátás. ez rácsszerkezetű tornyot jelent, párban.
2. kideríted, hogy kié az infrastruktúra, és bérelsz tőle kábelnyi helyet. az oszlopsor lehet a telekomé vagy az önkormányzaté. ha eléggé eldugott helyen van, ahol már nem számít a szépség, akkor előfordulhat, hogy második oszlopsor felállításához is hozzájárulhat az önkormányzat. ha ez nem megy, akkor ásni kell, abban az esetben a nyomvonalon az összes tulajdonossal meg kell egyezni.a nagyfeszültségű nyomvonal keresztezése lehet zűrös is, vagy lehet szerencsés is, mivel a nagyfeszültségen az mvmnet-nek valószínűleg van optikája.
3. beszélsz a wifis szolgáltatóval, hogy adjon dedikált linket. 950 métert át lehet lőni 60 gigás eszközzel 1 Gbps-sel, de 5 gigán ac-s wifivel biztosan, és az is tudhat akár 800 megabitet is.
ezek a tiszta lehetőségek.
nem tiszta lehetőségek:
1. fogod az optikát és felgurítod az oszlopsorra. ez pontosan addig olcsó, amíg meg nem találja az oszlop tulajdonosa, mert utána nagyon csúnyán vegzálni fog vazelin nélkül, ha érted, mire célzok.
2. lehet kis zsarolást is csinálni, kideríted, hogy a két helyszín a szupergyors internet projektben kihez tartozik, és felhívod, hogy hol a net, és kinek nem fogsz írni a történetről, ha lesz.megoldás lehet a földbe ásott kábel, csak az milliós tétel/kilométer, és nem feltétlenül a legkisebb 7 jegyű szám.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
tjsz
senior tag
Sziasztok!
Nem vagyok benne 100%-ig biztos, hogy jó helyen teszem fel a kérdéseim, de hátha....
Szóval: adva van 2 helyszín és mind2 helyen a net lassúsággal küzdenek, szeretnének valami gyorsabb megoldást.
1. helyszínen a községen kívül, az utolsó háztól kb. 1.2km-re van egy intézet az erdőben, ide jelenleg oszlopokon kivezetve kimegy egy adsl-es vonal, amelyen 1.25Mbit/s letöltési és 256Kbit/s feltöltési sebességet tud garantálni a szolgáltató (ungarische telecom) és az utóbbi időben ezzel a sebességel is megy (korábban egy picit gyorsabb volt). A községben már ott van az üvegszálas net, de ide nem hajlandó kivinni a telekom, mondván, nekik ez nem éri meg, sokba kerül, nem terveztek arra fejleszést stb. Az intézet egy erdős területen van, fizikai rálátás hiánya miatt a mikrohullámú átvitel nem igazán jöhet szóba, a mobilnet sebesség is siralmas. Meglátásotok szerint van-e arra bármilyen lehetőség, hogy az üvegszálas hálózat valamilyen módon eljusson az utolsó ház előtti oszloptól ezen intézetig? Egyáltalán: semmilyen módon nem kötelezhető a telekom, hogy vigye ki az üvegszálat? Hiszen nekik már ott vannak az oszlopaik (amelyen az adsl-es vonal van), tehát üvegszálas kábelt kellene csak felrakni és kész. Vagy rosszul gondolom?
2. helyszínen szintén a községen kívül van egy céges telephely (egy kis völgyben), jelenleg egy wifi-s netszolgáltatón keresztül van nekik net elérésük, de nem túl stabil. A telephelyre vezető út melletti utolsó oszlopon szintén ott van az üvegszálas hálózat (szintén telekom), ezen utolsó oszlop és a telephely között 950m a távolság. Sajnos az utolsó oszlop és a telephely között van egy nagy feszültségű távvezeték is, tehát mikrohullámú átvitel nem jöhet szóba. Milyen engedélyek szükségesek ahhoz, hogy a földbe leásva elvigyék ezt az üvegszálat a telephelyig? Milyen költségekkel lehet számolni? Vannak olyan cégek, akik ilyenek lebonyolítását-megvalósítását vállalják?
[ Szerkesztve ]
-
#9903
szabifotos
senior tag
mtz81
#9902
szabifotos
senior tag
Nem az olcsóbb fajta és elég sokan használják. Nem olvastam még hasonló tapasztalatot.
Az a baj, hogy teljesen random csinálja. Nekem inkább úgy tűnik, hogy lassan történik meg a dns fordítás ilyenkor, mert nem jön válasz, és ha ez sokáig fenn áll, akkor too long response eldobja. Pedig átírkáltam már dns szervert is meg stb.
Mindegy, köszi aki segített eddig. Hónapok óta nem jöttem rá, de szenvedés így a netezés...
Akinek még van ötlete, vagy egy szabad fél órája Székesfehérváron, szívesen látom egy kávéra, ha megcsiholja a netem.
-
#9902
mtz81
tag
szabifotos
#9901
mtz81
tag
válasz
szabifotos
#9901
üzenetére
Ezt a huawei eszközt nem ismerem, de arra gondolnék, hogy amikor nincs forgalom az internet irányába x ideig az eszköz bontja a kapcsolatot. Amikor érkezik egy kérés belülről, akkor újra kapcsolódik a netre, de amíg a kapcsolat fel nem épül az első pár kérelem timeout-ol.
-
#9901
szabifotos
senior tag
bambano
#9868
szabifotos
senior tag
válasz
bambano
#9868
üzenetére
De nem hinném, hogy böngészőspecifikus probléma, mivel wifin is csinálja és telefonon is pörögnek sokszor az appok, máskor meg rendesen működik.
Vagy nem jól gondolkodom?Annyit megpróbáltam, hogy a sim-kártyát a telefonomba tettem és ott jónak tűnt, úgyhogy valami a helyi hálón/esközökön csesződik el és nem jövök rá, hogy mi lehet.
"Connecting...; Resolving host..."
Néha eldobja "not responding" üzenettel, aztán F5 és megy.
Néha arra hivatkozik, hogy nem található XY.hu IP címe, aztán ráfríssítek 5-ször és megy.
Mit tehetnék? [ Szerkesztve ]
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Kávé kezdőknek - amatőr koffeinisták anonim klubja
- Villanyszerelés
- Milyen NAS-t vegyek?
- Spórolós topik
- A fociról könnyedén, egy baráti társaságban
- Xiaomi Mi Box androidos médialejátszó 4K és HDR támogatással
- DIGI kábel TV
- Xiaomi Smart Band 7 - hetedik
- BestBuy topik
- Nyomtató topik
- További aktív témák...
- Új, makulátlan Asus TUF Gaming A15 FA507 (FA507NUR-LP005), Mecha szürke, 3 év garancia
- Lenovo Yoga Pro 7i Profi Ultrabook -30% 14,5 Brutális i7-13700H 14Mag 16/1TB Intel Iris Xe 2,5K 90Hz
- Lenovo LOQ 15irh8
- Bontatlan Lenovo Yoga Pro 7 Profi Ultrabook -30% Ryzen 7 7840HS 8Mag 32/1TB 2,5K RadeonT 780M 4GB
- Különleges ITX PC (5800X3D 64GB 1TB RTX4060 LP) - Portal Companion Cube
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest