Ugrás a tartalomhoz

  • Szeretne hasonló avatart használni? A profilképként felhasználható avatarokat az alábbi linkről tudja letölteni.

    image.jpegimage.jpegimage.jpegimage.jpegimage.jpegimage.jpeg

angyalz

Tag
 Profil megtekintése  Aktivitás megtekintése

  • Tartalmak

    46

  • Csatlakozás időpontja

  • Utolsó látogatás

 Tartalomtípus 

Blogkommentek, amit angyalz posztolt

  2. anonymus

    Posztolva: · Szerkesztve ekkor: Szerkesztő: angyalz

    2 perce, FGy írta:

    Erről beszéltem épp. Azzal nem enged be távolról. A rouer mögött a helyi lanon van egy két dolog, azokra be tudok lépni, ott van portforward. De a routerbe szeretnék távolról, az meg nem megy, pedig ugyanazzal a pw-vel próbáltam. Esetleg kell vmi. portforwardot engedni a wan felől a 443-ra? Nem is emlékszem, hogy lett volna olyan menüpont, hogy "remote management port" vagy hasonló..

    Próbáld meg a gyári jelszóval. Korábban külön kellett megadni LAN és WAN oldalról. A távoli konfigot meg a haladó fülön lehet engedélyezni egy pipával.

    Ja, és adott esetben http://ipcímvagyddnscím:8080 szokott megoldást jelenteni.

  3. anonymus

    Posztolva:

    Na a valaki nem én vagyok, nálam minden változatlan. :S

    Közben az előbb leírt hibát konkretizálom: 
    Csak LAN-on áll fenn, wifin a fix IP-vel is újracsatlakozik. LAN-on a két fix IP-s eszköz közül az egyiket sehol sem látom a modem oldalain (LAN felderítés, DHCP), a másik látszólag csatlakozik fix IP-vel, de forgalom nincs rajta. Továbbá: áramtalaítás után a hiba nagy valószínűséggel nem jelentkezik, a menüből, vagy saját maga által kezdeményezett újraindítással viszont igen. Áramtalanítást követően azonban hajlamos többször is újraindulni, mintha a boot közben valami hibába futna.

  14. anonymus

    Posztolva:

    5 perce, kdevid írta:

    48 oraja jokvagyunk... :D 
    furamodon a dhttps://kozosseg.telekom.hu/?app=core&module=system&controller=loginupla nat se nagyon kavarodik be.... megy minden ami a cisconal problemas volt... (voip, viber, skype, ssh)

    Nekem nem. Ma reggel pont egy szatyor hibával és többszörös újraindítással kezdtünk. Első tünetnek a 2,4GHz/5GHz/LAN nem látták egymást, majd az újraindítást követően a belső háló helyreállt, de kifelé nem ment látszólag semmi. Ekkor a móka kedvéért egy szatyor ping (index.hu, 8.8.8.8, 8.8.4.4, telekom.hu), amik közül egyedül a telekom nem ment le, a többi hibátlan. Ennek ellenére kifelé sem a http, sem a vnc nem működött. Mást nem próbáltam. Harmadik újraindítás és némi várakozás (kb 10 perc) után lassacskán felállt minden.

  15. anonymus

    Posztolva:

    10 órája, kdevid írta:

    Most belottem az R7000et routolni, a hgwn kikapcsoltam tokig a tuzfalat, dmzbe raktam az r7000et es a hgwn hagytam az stb -t. Most nem akad a net, ha toltok... es igy nem tudom hasznalni a musorujsagot taviranyitonak, pedig tudom pingelni a masik halobolt az stb -t

    Ez mondjuk egy érdekes megközelítés, mert azt már korábban is tapasztaltam, hogy ha a tűzfal beállításain bármilyen módon módosítok, akkor sorra fogynak a működő szolgáltatások a hálózaton. 

  16. anonymus

    Posztolva:

    Ekkor: 2017. 08. 27. at 15:41, root írta:

    Láthatnánk valami konkrétumot is? Mondjuk, hogy állnak a csatornáid, milyen klienst használsz, milyen OS-t stb. Csak azért kérdezem, mert én az egyik serveremen futtatok egy torrentflux nevű php klienst, néha húzok olyan 80-90MB/sec-kel, és nálam nincs semmi gond.

    A jelenség  nálam is él, ahogyan korábban többször is jeleztem. Korábban ígértem, hogy megnézem ilyenkor a pinget, azok normálisan mennek lehalt hálózat mellett is. Nálunk OS és böngésző tekintetében a lehető legvegyesebb: Debian, Windows, macOS, iOS, Android. Megjegyzem, hogy bizonyos esetekben még konkrét le- vagy feltöltésnek sem kell mennie (csak átmenetileg valami nagyobb adatforgalomnak akár belső hálón), hogy a jelenség előidézhető legyen. Konkrét szabályszerűséget viszont még nem sikerült felfedeznem, így azt sem állíthatom, hogy bármikor biztosan elő tudom idézni a jelenséget.

    A fentiek miatt, illetve hogy a jelenséget korábban sem a Technicolor, sem Cisco eszközön nem tapasztaltuk, így egyértelműnek gondolom, hogy a Sagem bugja. Érdekesnek vagy új infónak talán az tűnik, hogy a belső forgalom (pl a belső hálón futó backup szerverre történő mentés) is le tudja rohasztani.

  19. anonymus

    Posztolva: · Szerkesztve ekkor: Szerkesztő: angyalz

    2 perce, anonymus írta:

    Pingeld meg 192.168.0.1 -et és a 8.8.8.8 külön külön parancssorban egyszerre. -t kapcsolóval megy megszakításig, ebből látni fogod amit kell.

    Következőnél megejtem, posztolni fogom az eredményt! 

     

    Addig kiegészítés: nem bizonyító erejű, szintén inkább csak érzet, de erősen úgy tűnik, hogy a különféle kapcsolatmódok közül a LAN hal meg utoljára. A wifi-k sokkal sűrűbben és könnyebben dobják be a kulcsot.

  20. anonymus

    Posztolva:

    4 perce, root írta:

    Tudnál nekem erről adni valamit? Gondolom az eszközök SMB-n csattannak össze. Felteszema  workgroup ugyanaz, VLAN nincs. Nálam ilyen hiba amit Te most mondtál, hogy 24 nem látja SMB-n az 5 ön vagy LAN-on levő eszközöket nem jelentkezett.

    Na ez nehéz kérdés. *****i vegyes a paletta. A hálózaton belül van Win, printsrv AirPrint-tel (bonjour), SMB-vel, Linux, macOS, iOS. Ahol a legkönnyebb tetten érni (indikátor), ha leakad a nyomtatás a printsrv-re, vagy az eltérő wifi frekvenciára csatlakozó almás eszközök (iOS / macOS) nem látják egymást, esetleg a bonjour (LAN-ról) csak néhol felfedezhetők. Pl AirPrint 2,4GHz-en nincs meg, 5GHz-re átállva működik (AirPrint nyomtató LAN-on). Békeidőben pedig mindenki lát mindenkit. (AirPrint eszköz is kettő van, az egyik fixen LAN-on, a másiknál variálható, hogy wifi vagy LAN. Teszteltem mindkettőt, igazából egyik sem biztos megoldás)

  21. anonymus

    Posztolva:

    2 perce, anonymus írta:

    1-1.7 Gb -os file próbáltam kisebbel nem láttam értelmét mert mire elindítom a logolást mentést stb addig 3x lejött volna. Úgy volt összerakva a sztori hogy a most fennálló maximális sávszelem kb felét se tudta kihasználni a letöltés. De az egészben az a érdekes hogy az elmúlt napokban elég szépen ment a fel/le és akkor nem bukott ki. 

     

    Üzleti efi viszont tehet ilyet, üzleti mivoltod megmarad viszont a lakossági sla szabályzat árak stb vonatkoznak rád a továbbiakban. (Most futó hűséggel nem tudom mi történik ilyenkor (Ha érdekel tudok árakat küldeni erre vonatkozóan))

    Ha 250 főnél kevesebb embert foglalkoztatsz nettő árbevétel legfeljebb 50 millió eurónak megfelelő forint.  Vagy mérlegfőösszeg legfeljebb 43 millió euró forintnak felel meg. Nem minősül KKV-nak az a vállalkozás, amelyben az állam vagy az önkormányzat közvetlen vagy közvetett tulajdoni részesedés - tőke vagy szavazati joga alapján - külön-külön vagy együttesen meghaladja a 25%-ot. 

     

    Köszönöm, de ezt a kört megfutottuk. Sajnos a meglévő hűségidőnél akadt el a dolog; anno nem kellő körültekintéssel sikerült szerződést kötni... :-/ Egyébként valóban lenne rá lehetőség, de most egy darabig csak a drága csomagokból válogathatunk (ok, céges költségvetés, relatív a drága, de...)

    Kapcsolatvesztés: őszintén szólva nézegetem már egy ideje, próbálok összefüggéseket keresni, de eddig nem sikerült találnom semmi kézzelfoghatót vagy bizonyító erejűt. Egyelőre csak megérzés szintű dolog, de úgy tűnik, hogy nem kell szénné terhelni a kapcsolatot ahhoz, hogy a leakadást előidézzem, inkább csak folyamatosabb, hosszabb terhelés kell neki. Néha úgy tűnik, mintha netrádió szintű dolog  is elég lenne neki. Ilyenkor pl az sem szakad meg, de a http/https meg igen.

  22. anonymus

    Posztolva:

    15 perce, root írta:

    Ez a dolog a V1-es modemeken nem jelentkezett. Hidd el nekem. 2 linux server is üzemel a lakásban. a portfw táblám hosszabb mint a CV-d:))), van ideirányított A, AAAA, MX rekord, szóval ha lett volna vaalmi az kiugrott volna ennyi idő alatt a V1 -en

    Kedves Root! 

    Mindent elhiszek, bizonyára ez is user error, mint a többi jelzett hiba, de gyanítom, hogy a hiba általam történt első jelzésénél még V2 nem is létezett. Vagy nem tudom mióta létezik. Bizonyára hallucinálom a hibákat, de nálunk 2 db ilyen kihelyezett hulladék (bocs, hibátlan eszköz) produkálja nap mint nap. Gondolom az fel sem merül, hogy eltérő környezetekben eltérő hibák jelentkezhetnek. 
    Feltételezem az sem jelentkezett még, hogy a 2,4GHz-re, 5GHz-re, és LAN-ra csatlakozó eszközök a kapcsolódás szerint nem látják egymást. (LAN a LAN-t igen, 2,4GHz a 2,4GHz-et igen, de pl a 2,4GHz-en kapcsolódó eszköz az 5GHz-en kapcsolódó eszközt, vagy a LAN-on kapcsolódó eszközt nem). Na ez pl van, hogy hetekig nem jön elő, máskor napokig kísért.

  23. anonymus

    Posztolva:

    A készletkezelő web alapú, http és https kapcsolatokkal operál; pénztárgép is 80-as portot használ. Tipikusan egyébként ez döglik meg elsőnek. SSH, VNC, stb megmarad. Egyébként nevetségesen kevés adatot küldenek, a hiba előidézéséhez meg nem kell nagyon nagy forgalmat generálni, pláne nem kell túl hosszú időre. A sávszélesség egyébként az átlagos terhelés alapján bőven elegendő lenne. (Üzleti előfizetéssel viszont elég keményen fog a ceruza T. szolgáltatónál) 

  24. anonymus

    Posztolva:

    Admin Urak!

     

    Ez az a hiba, amit jeleztem már ezer éve azzal kiegészítve, hogy bizonyos portokon megmarad a kommunikáció nagyobb terhelés mellett is, másokon meg megszakad, csak őszintén szólva belefáradtam a hibák jelzésébe, hiszen a végfelhasználói oldalon nem történik változás hónapok óta. Igen, szintén V1-et használunk. Céges környezetben, jövedéki termékek készletkezelő rendszerét üzemeltetve rajta. Nem móka és kacagás készletmozgatás közben kapcsolatot veszteni nap mint nap. Igen, üzleti előfizetés. Igen, NAV-hoz és NDN-hez bedrótozott rendszerrel. Számomra azért (Admin urak munkáját maximálisan tisztelve) hajmeresztő a T. szolgáltató belerottyintása.

×
×
  • Új...