Keresés

Új hozzászólás Aktív témák

  • janos666

    nagyúr

    LOGOUT blog

    Most nyúlok először Mikrotik kütyühöz, két SXT Lite 5 személyében, amik még 3.2-es RouterOS-el érkeztek.

    Első pillantásra lenyűgözött a WebFig, de a lehetőségek tárháza egyben nehezebbé is teszi a kezdők életét. Főleg, hogy szerintem még olyasmiket is látok a menükben, amikhez nincs meg a RouterOS licens-em (L3), így csak még kevésbé "látom a fáktól az erdőt".

    Bár már a dobozban talált papírka megkér rá, hogy kezdjem egy RouterOS frissítéssel, ezt egyelőre inkább kihagytam, mert ez egyszerűbbnek tűnik online módban automatikusan, mint offline manuálisan.
    Online-á válni viszont már nehezebb, mert ha a DHCP-s router-em egyik LAN portjára csatlakoztatom egy ilyen SXT egyetlen ethernet portját, akkor sem a WebFig nem válaszol az alapértelmezett IP-jén (és ahogy a router-em nézem, DHCP-ről sem kér/kap más IP-t, de az ő alapértelmezett IP-je is szabad, szóval valamelyiknek működnie kéne), sem a WinBox nem éri el MAC-cím alapján sem (az ugyan erre a router-re kötött, egy LAN-on lévő PC-ről futtatva). Továbbá a router-em WiFi AP-jéhez sem tudok vele kliensként csatlakozni, mikor közvetlenül a PC-vel kötöm össze és úgy elérem a WebFig-et (ez utóbbi valószínűleg user error, amiért még nem ismerem a RouterOS-t).

    Szóval kicsit megtorpantam vele és elgondolkodtam, hogy esetleg megpróbáljak-e inkább OpenWRT-t ütyködni rá az ismert konfigurációs felület miatt. De viszonylag komplikált ezekre a telepítése és nem tudom, hogy vesztek-e vele valami hasznos proprietary cuccot (példának túl-limitálja-e a rádió adóerősségét és a választható csatornákat). És igazából tetszene a RouterOS, ha sikerülne konfigurálnom.

    Semmi másra nem használnám ezeket az SXT-ket, csak a LAN térbeli kiterjesztésére: egy WiFi AP egy router-be és egy WiFi Client egy switch-be.

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz bambano #937 üzenetére

    Bocs, csak átverődtem, mikor a System/Routerboar fülön láttam ezt:
    Model SXT 5nD r2
    Current Firmware 3.22

    De v5.26 a RouterOS verzió és V7-ig bezáróan upgrade-elhető ezzel a license-el.

    Mondjuk ez is egy főverziónyival alacsonyabb, mint az aktuálisan letölthető, de ezért szerintem nem éri meg visszaküldeni és drágább helyről másikat venni (két darabról van szó).
    Vagy már a V5 is több éves? A letöltési oldal alapján ez már az aktuálisan használt MIPS architektúra lehet, ha V5-el indul.

    (#938) poli27

    Aha... Akkor ezért volt ez ennyire "olcsó"...?
    Tehát L3-al nem fog menni, amit terveztem: (A) ponton lévő router LAN portjából egy kábel egy SXT-be, (B) ponton egy SXT-ből egy kábel egy switch-be, és így (egy IP tartományban, NAT/forward/firewall nélkül) elérni oda-vissza az (A) és (B) pont közt a hálózatra kötött eszközöket?

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz bambano #941 üzenetére

    Point-to-point módnál nem hiszem, hogy sokat számít, ha elavul az OS. A biztonsági és kompatibilitási gondok szerintem olyasmiknél jöhetnének ki, amiket ilyenkor ki lehet, vagy akár kell is kapcsolni (tűzfal, DHCP szerver, stb, igazából még a konfigurácós felületekről is kizárhatom saját magam is, mikor már üzemelnek).

    OpenWRT-vel csináltam már működő WDS-t (úgy, hogy még magát a WDS Client eszközt is el lehetett érni mindkét oldalon IP alapján), de itt egyébként sem volt tervben.

    A PoE adaptereikkel viszont nem vagyok megelégedve. Nem elég, hogy nem standard feszültségű és passzív, de szarul is passzol a foglalatokba a normál oldali dugó.
    Nem hálózati gond, hogy nem látom a router-emen át, a laptop-omba is nagyon nehéz úgy beigazgatni a csatlakozófejet, hogy működjön. Fogni kell kézzel, vagy ölbe venni úgy, hogy a lábam feszítse kicsit a csatit és ez is csak az egyikkel sikerül, a másiké gyakorlatilag halott, így kicsit nehéz kipróbálni őket együtt.

    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."

  • janos666

    nagyúr

    LOGOUT blog

    Nem akar a szívemhez nőni a kütyü. :N
    WinBox-al feltöltöttem az .npk file-t, nyomtam egy reboot-ot, aztán vártam türelemmel, de ~15 perc után még mindig csak ugyan úgy villogott a User LED, ahogy rögtön a reboot parancs után kezdte.
    Elvettem az áramot, visszaadtam, de ugyan ezt csinálta, az IP-je nem válaszolt.
    Csináltam egy gombnyomvatartós reset-et és elindult V6-al.
    Szerencsére nem egy fémrúd tetejéről kellett levenni, hogy Reset-eljem, akkor mérges lennék, hogy minek kellett nekem V6. :))

    Érdemes ráforrasztani egy kábelt a Reset PIN-ekre, azért néznek ki így? ;]

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz bacus #949 üzenetére

    Később meglett a hiba: az OS frissítés után javasol bootloader frissítést. Na, én "ügyesen" downgrade-eltem a bootloader-t, mert rögtön azután rányomtam, hogy Firmware Upgrade, hogy felmásoltam az OS csomagot, de még nem volt reboot.
    Erre igazából már akkor rájöttem, hogy a bootloader-t nem az npk csomagból fogja kihalászni és felírni, hanem a már telepített OS-ben lévőt használja, mikkor láttam, hogy 3.2x-ről 3.0x-re downgrade-elt, de akkor úgysem tudtam mást csinálni, mint Reboot-olni és félni, hogy talán fimrware recovery-vel kezdhetem első közös napot.
    Ez is fura kicsit, hogy a hardware-en frissebb volt a bootloader, mint amit az előtelepített OS hordozott, és hogy az 5.3-as OS bootloader-ével nem boot-olt zavartalanul a 6.3-as OS, de ez már így sikerült.
    A lényeg, hogy mikor Reset után magához tért, és ténylegesen is upgrade-eltem a bootloader-t a V6.3-as OS-ből, azóta zavartalanul boot-ol.
    A második SXT-nél pedig már teljesen zökkenőmentesen zajlott az egész. :K

    Láttam, hogy tud ilyet, bepötyögtem a MAC-et, de azon sem reagált.

    Töredelmesen bevallom bűneimet. :((( Igazad van. :B
    Valóban szerettem volna túl lenni az ügyön maximum 1-2 órán belül egy nekifutásból. Ha nem is next-next-finish módon, de egy szál szimpla point-to-point ügyet nem szerettem volna túlbonyolítani sem időben, sem szellemi munkában. Lustaság...
    Gyorsan be akartam állítani este, másnap feldobni őket egy karóra, aztán elfelejteni, hogy léteznek.

    Azóta nézegettem a menüt és a WiKi-t is, illetve tesztelgettem már szobán belül a bridge/station PTP üzemet. (Ráharaptam a PoE konverterek problémás fejére egy krimpelőfogóval és azóta mindkettő működik. :DDD)
    Bár erre a feladatra szerintem még mindig kár lenne mélyre ásnom magam a Mikrotik doksik világában, de azért még így is láttam pár érdekes dolgot.

    Tényleg kár lett volna eldobni a gyári OS-t a kényelem (gyorsabb első konfigurálás) kedvéért, mert úgy látom, hogy --legalább is szobán belül-- NV2-vel sokkal magasabb sávszélt ér el a WiFi, mint standard 802.11-el, illetve ami nagyon praktikusnak tűnik ebben, hogy így 20MHz-el is megvan a ~100Mbps, ami épp passzol a 100-as ethernet portjához és a majdan alatta ülő 100-as switch-hez (ha 802.3af-et használna, az még szebb lenne, mert jutna neki szabad PoE port, de végül is mindegy).

    ---

    Nem, nem nem.
    Nem vagyok frissítés ellenes, csak nem szeretek rögtön nekiugrani, mikor frissen bontok ki valamit a dobozból, amit még nem ismerek, mert ha ilyenkor félrecsúszik valami, az macerás, illetve ha használatbavételi teszteléskor kiderülne, hogy selejtet kaptam (vagy szimplán csak mégsem jó arra, amire használni szeretném) és vissza kéne küldeni, akkor problémás lehet az ilyesmi, hogy "belenyúltam".

    Teljesen másra vonatkozott a letiltás dolog.
    Te nem tiltanád le a DHCP szervert egy ilyen PTP bridge/station módban az SXT-ken, ahol egy harmadik eszköz oszt majd IP-ket mindkét oldalra?

    Ezt nem gyártói firmware butításra értettem.

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz bambano #955 üzenetére

    Ez biztos igaz akkor, ha még egyiket sem, vagy már mindkettőt ismered, de kivétel lehet, ha csak a komplikáltabbal, de azzal már van tapasztalatod. Már egy éjszakányi tapasztalat után is teljesen másképp állnék hozzá egy új Mikrotik-os feladathoz. Ugyan ezt replikálni pedig már tényleg gyerekjáték lenne.

    Mondjuk még mindig vélek látni látszólagos ellentmondásokat. Ez példuál úgy néz ki, mint ha Bridge módban kikapcsolhatnám a Bridge-elést...

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz E.Kaufmann #970 üzenetére

    230 helyett húzhatsz egy új, kis egyenfeszültségű kábelt is a meglévő UTP kábelek csatornájában, illetve bármelyik meglévő 8 eres UTP kábelből befoghatsz tetszőleges célra 4 eret, ha van olyan köztük, amin bőven elég a 10/100-as átvitel (és beleteheted ilyen passzív konverterekkel az egyenáramot + akár földet), vagy húzhatsz egy ötödik UTP-t, ha az jobban tetszik, és mondjuk van belőle fölösleg + jól jöhet még tartalék adatkábel későbbre.

    ---

    Sikeresnek tekinthetem ezt a telepítést, vagy alkalom adtán próbáljam még finomítani a tájolást és/vagy szoftveres beállítást? WinBox screenshot.
    A távolság ~1km, a txpower-t tervezem majd még minimalizálni, mondjuk egy olyan esős/ködös időben tesztelve, mint ma hajnalban várható. Az üzemszerű sávszélesség igény ~32Mb/s (TPC) lesz (lényegében egy irányba, mint a fenti mérésnél).

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz poli27 #972 üzenetére

    Pusztán kényelmi okból, mert így szabadon állítgathatom az ap oldalt, a station mindig rátalál. A doksi szerint nincs semmi hátránya, mert nem "hybrid mód", hanem ebben a sorrendben próbál csatlakozni, de ha már megállapodott, akkor mindegy hol állt.

    Miért szemeteljek, ha elég a 20MHz? :U
    Jön majd az itthoni SXT mellé még egy (170˙-ot bezárva), amin talán kell is a 40MHz, plusz a telken belül van omni antennás 5GHz AP is, a csatornák száma pedig véges, főleg ha betartom az előírásokat (a házon belüli kütyükkel minimális jelszinten nem zavartatnám magam, de azok nem ilyen rugalmasak, ezzel a megafonnal pedig nem akarok olyan tartományban kiabálni a vakvilágba).

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    Tanácstalan vagyok hol lehet a gond, ezért már itt is értetlenkedek kicsit.
    Van három helyszín, amikből az első kettő egyforma, majd a harmadik:
    2x 100Mbps switch-en 4 IP kamera, 1 WiFi AP, 1 SXT-L5
    1x 1000Mbps switch-en 1 IP kamera, 2 SXT-L5, majd egy másik 1000Mbps switch
    A harmadik helyen egy (a második switch-en ülő) rögzítené mind a 9 kamera képét (egyszerű ffmpeg rtsp stream dump mp4 file-ba), de csak a helyben lévőt sikerül neki gond nélkül, a többi videó erősen sérült, illetve ha leállítom a rögzítést és élőben próbálom nézni egy másik PC-ről, akkor is problémás, mert minél több kamera magasabb felbontású/bitrátájú képét nyitom meg egyszerre, úgy előbb csak akadozik/hibázik, majd jön a véletlenszerű disconnect... Ha csak a kis felbontású/bitrátájú stream-eket nyitom meg, azokkal nincs gond.

    Tehát elsőre akár sávszélesség problémának is tűnhet, de egy kamera maximum 8 megabit/sec. Átlagban ettől igazából kevesebb (4-6 attól függően, hogy melyik mit lát, mert éjjel szürkeárnyalatos, stb...), de a biztonság kedvéért mindenféle overhead és egyebek után kerekítsük 10-re.
    A szintetikus sebességmérés az SXT-k közt ilyeneket mutat: 1 2
    Illetve csináltam olyat is, hogy ellátogattam az egyik távoli helyszínre, csatlakoztam a switch-ez egy laptop-al és SMB-vel mozgattam videó file-okat oda-vissza arról a gépről, aminek a kamerákat kéne rögzíteni, csak hogy végképp kizárjam az olyan bagatel hibákat, mint a mértékegységátváltás, és "tömörítéses csalás" a sebességmérésekben, stb, és ez az empirikus teszt is azt mutatta, hogy a szükséges sebesség többszöröse is megvan: néhány percbe telt csak átmásolgatni egy durván négyszer akkora videófile-t, mint amit a szervergépig kábelezett kamera rögzít egy óra alatt.

    Szóval, amire laikusként gyanakszom:
    - valamiféle ütemezés jellegű probléma, amitől "bedugul a vonal", pl. szanaszét tördelt csomagok, vagy épp időtúllépést eredményező extra késleltetés, ami esetleg a Wireless Bridge mód sajátossága
    - mivel a kamerák UTP protokollt használnak, az SXT-k közt pedig van packet loss UTP-vel tesztelve, így vesznek el csomagok, szó szerint a levegőben, amik hiányában látványosan sérül a tömörített videókép, illetve akár kapcsolatbontáshoz is vezet, mikor már >X sorban következő képkockát (vagy >X másodpercet, stb) sem lehet dekódolni, mint értelmes videó stream.

    De ami még fura, hogy kint a távoli helyszínen egy laptop-al csatlakozva a helyi kis 65Mbps (1:1 20MHz 2GHz) WiFi AP-hez gond nélkül tudom nézni élőben a kamerák képét, tehát ha mást nem, a 820.11 módnál nem szabadna problémát jelenteni magának a WiFi-nek (és ezt a módot is próbáltam már az SXT-k közt is, bár a Bridge mód miatt nyilván a proprietary kiterjesztésekkel fűszerezett verzióját...).

    Már minden lehetséges beállítást áttúrtam számtalanszor minden érintett eszközön, amit lehet konfigurálni és nézegettem a LED-eket azon, amit nem, de ad magáról valami életjelet. Az SXT-ken is kipróbáltam már sokféle beállítást 802.11, nstreme dynamic framesize, NV2 különböző TDMA időkkel, stb. Mint a fenti képen is látszik, próbaképp már átállítottam 20-ról 40MHz-re, ellenőriztem, hogy átmegy a swith-eken a Duplex 100Mbps. Végiglépkedtem több RouterOS verzión (bugfix-től RC branch-ig -- messzebbre nem léptem vissza így távolról, hátha a jelentősen régebbi verzióval nem működnének a most beállított dolgok és elveszne a túloldal...).

    Olvastam a Mikrotik WiKi-n, hogy nstreme-el lehetőség van különböző arányú Forward Error Coding-ra, de Winbox-ban sehol sem találom ezt és a WiKi-t is hiába turkálom utána, csak a feature listán látom, a beállítások részletezésénél sehol sem kerül elő, mint ha végül sohasem vált volna elérhetővé a felhazsnálók számára, vagy valamiért már letiltották azóta. Vagy csak WinBox-tól mélyebben kell keresni? (De akkor tényleg kéne hozzá a doksi, hogy mit írjak a parancssorba...) Még ezt gondoltam kipróbálni, mert sávszélesség az látszólag van bőven, de a packet loss-tól félek, hogy talán ez a gond.

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz janos666 #1154 üzenetére

    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."

  • janos666

    nagyúr

    LOGOUT blog

    Van arról tapasztalata valakinek, hogy egy CAPsMAN (v2) alatt, de egyrészt szimultán dual-band, és azon belül is eltérő csatornákra állított CAP-ek közti roaming mennyire sima/észrevétlen (épületben vándorló, roaming szempontból "makacs/buta" eszközt feltételezve), főleg ott, ahol kénytelen (vagy legalább is ildomos lenne) 5GHz-ről 2GHz-re váltania a kliensnek (mert nincs teljes hibátlan 5G lefedettség minden szoba minden sarkában mindenféle kliens-antennatípussal és pozícióval, de a 2G még a szomszéd kertjében is pöpec lenne)?

    Össz-vissz 2-3 db hAP ac²-ről lenne szó, amik vegyes márkájú/típusú "buta" AP-ket váltanának, de igazából csak az a gyakorlati gond, hogy pl. kapaszkodik az utolsó szalmaszálba ~0 sebességgel egy laptop 5G-n ott, ahol még teljesen vállalható a 2G sebesség (persze megfojtva az AP-hez közeli 5G-s klienseket is), de nem akarok egy tucat AP-t szétszórni, mert nem üzleti, hanem magáncélú telepítés, amit szórványosan használunk (szinte mindig idle, de ha fel-alá rohangálnak a házban a vendégek a sok okoskütyüvel, akkor "baj van" és nyafogás...).

    Ajánlották az Ubiquti Unifi-t, aminél a Fast Roaming papíron nagyon mesésen hangzik, de igazából azt sakkoztam ki, hogy:

    1: nem csak drágább (ha beleveszem az árba azt is, hogy a hasonló árazású AP-iken csak 1 ethernet port van, míg a Mikrotik-eken legalább 2, szóval potenciálisan új kábel és/vagy switch is kell, ami megdobhatja az árat/munkaigényt az Ubi-nál [vagy a sokkal drágább Ubi AP kell 2+ porttal], illetve a hasonló árú Ubi még wave1, noha egyelőre úgysincs itt MU-MIMO kliens, de ártani nem árt, ha tudja a Mikrotik AP hasonló áron).

    2: némi nézelődés után a fórumokon elejtett információkból azt sakkoztam össze, hogy gyakorlatilag a Mikrotik is tudja mind a kétféle roaming segédletet, amiknek az Ubiquti saját fantázianeveket adott (Zero-Handoff és Fast Roaming), csak itt nincs külön kiemelve, mint extra funkció, illetve nem annyira automata (de az nem gond, nyomkodtam már Winbox-ot), de ha CAPsMAN alatt minden AP egy csatornán van, az ugyan úgy működik, mint az Ubi féle Zero-Handoff (egybemaszkolódik minden AP, így a kliens nem is tudja, hogy roaming-oltatva lett), illetve ugyan úgy megvan a Fast Roaming féle "autentikáció-gyorsítás" is, mert a CAPsMAN kezel mindent, ami időigényes lehet újracsatlakozáskor (olyanokra gondolva, hogy pl. még élő videótelefon se szakadjon meg emeletek közt battyogva). De egyikről sem találtam egyértelmű pontos dokumentációt Mikrotik esetén, csak mások leírásait pakolom össze (többen állítják, hogy működik az egy csatornás mód, illetve logikusnak tűnik, hogy akkor a több csatornáson is az autentikáció rész).

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Ablakos #5001 üzenetére

    Igen, kb. ez a helyzet ("ragaszkodás"), csak annyi lenne fejlesztés a jelenlegi állapotról (ASUS és TP-Link otthonra szánt router termékei futnak AP módban), hogy Mikrotik-nél (és Ubi-nál):

    1: ki lehet rúgatni a klienseket jelerősség alapján, hogy kénytelen legyen újracsatlakozni, és akkor már általában nem a régit próbálja újra, hanem a legerősebbet választja

    2: elvileg a CAPsMAN (és Unifi) további segítséget ad(hat) a simább/gyorsabb újracsatlakozáshoz más frekvencián (gyorsabb autentikáció), vagy akár elvileg még teljesen észrevétlen is maradhat az AP váltás a kliens számára, ha azonos frekvencián maradhat (a kliens nem is tud róla, hogy több AP-vel van dolga, ő csak egyet lát, és az AP oldal dönti el, hogy épp melyik rádió beszél/hallgat adot kliens esetén).

    A közös frekis dolog többek szerint működik Mikrotik-nál (itt Ph-n is írta nekem valaki egy másik fórumtémában és a Mikrotik fórumon is olvastam ilyen beszámolót), csak abban nem vagyok biztos, hogy az eltérő frekik esetén is gyors-e a váltás, mint amit az Ubiquti ígér Fast Roaming néven. Ez akkor lenne nekem érdekes, mikor 2G és 5G közt kéne váltatni a klienst, mert az nyilván nem lehet közös frekvencián belül.

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    Ez a hAP ac² sokkal kisebb, mint gondoltam:[kép] és ugyan alap konfigurácival is bekapcsol egy RBGPOE-t a "1 / Internet / PoE-in" portra kötve (a mellé kapott 24V/0.8A tápot használtam a PoE injektorhoz), viszont picit kelemetlen meglepetés volt, hogy ezen a porton alapértelmezésben tűzfal fut, így MAC alapján sem találja meg a Winbox. Nem nagy probléma, de egy alapvetően AccessPoint-ról nem hittem, hogy alapesetben Router-ként fog viselkedni, főleg hogy csak ezen a porton fogad PoE-t, szóval kicsit meglepeheti azt, aki rögtön PoE-vel szeretné használni (vagy távolról reset-elni ilyenkor).

    Jah, és így hogy beépített antennás, még talán elfért volna a mellé adott papírkán, ami 10 fotón át magyarázza a talp felpattintását, hogy merre érdemes forgatni a dobozt, mert godolom nem teljesen mindegy.

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz E.Kaufmann #5026 üzenetére

    Persze, csak annyi, hogy rögtön PoE-vel raktam össze elsőre, aztán vakargattam a fejem, hogy "na hol vagy?", de végül is jogos, hogy rá van írva "Internet", és a mellékelt papíron is rajta van, hogy alapértelmezésben aktív a tűzfal ezen a porton, csak AccessPoint és nem Router néven fut, így nem triviális.

    De igen, már átkonfigoltam, egyszerűen bridge-re lehet dobni az összes ethernet portot és wlan-t.

    Viszont picit bugos (szépséghibás / hiányos) még a szoftver.

    Hungary + manual_tx módban a tx_power-t default-on hagyva, 2G-n N-only, 5G-t N/AC módra rakva a Current Tx Power fülön 2G-n minden létező módra 0dBm-et ír, 5G-n ez a teljes táblázat totál üres (a módok listája is hiányzik, nullákat se látok), szóval fogalmam sincs most milyen erősítéssel üzemel.

    A másik bug, hogy (?) az 5G rédión teljesen hiányzik a HT MCS fül, bár igazából megvagyok nélküle, 2G-n is csak a Basic módokat pipálgattam le, minden MCS módot bennhagytam egyelőre (és talán vissza kell majd tennem pár basic-et ott is, majd kiderül).

    Az alapján, amit notin jelszintre mérek, most kicsit hangosabban kiabál 2 és 5G-n is, mint az ASUS N66U a Merlin firmware-el (közel tettem mellé tesztelni), ami a legális fölé engedi lőni a txpower-t, szóval nem gyenge -> persze később több okból is visszaveszem majd, most csak próbálgatom.
    Viszont egy másik emeleten gyengébb, szóval az antenna marad jobban síkban a hAP-on, ami nekem jó is (sokat fog a födém, úgyis külön AP kell a külön emeletekre normális sebességhez 5G-n).

    (#5027) Kiratheonly

    Még konfigolgatom és AC-s kliensem csak 1x1-es van, N-ből van 2x2-es.
    Pontosan mit szeretnél, hogy mérjek? WiFi sebességet iperf-el LAN-on pár különböző jelszinten az épületben, vagy NAT sebességet? (A NAT-ot és tűzfalat már teljesen kigyilkoltam, de később kiróbálhatom, ha backup-oltam, mikor kész a konfig.)

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Kiratheonly #5027 üzenetére

    WiFi sebesség, összevetésül az N66U-val, amit terv szerint levált. Mindkettő a lehetséges max txpower-el ment. Mindig volt egy tégfal (fehér oszlopok), egyszer pedig egy vasalt födém (emelet, szürke oszlopok) is köztük (AP és kliens).

    Egy AC-s mobiltelefonnal 180Mbit/s-t mértem (az AP-vel szomszédos szobában, rálátás nélkül de nyitott ajtóval).
    Ez mind iperf3 TCP mérés egy x86 szerverre (amire közvetlenül volt kötve az AP egy 4 portos Intel i350-es kártyára). Az AP 60-70 körülnek írkálta a CCQ-t a mobillal (Galaxy A3 2017), 70-80 köztinek a notival (Dell 5547, Intel 3160 adapter, friss driver).

    Érdekes akkor a NAT, megnézzem később?

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Kiratheonly #5030 üzenetére

    Közvetlen rálátással sem tartja valamiért stabilan a noti a 433.3Mbps módot, és ilyenkor jön ki ~300Mbps UDP

    Mint látszik, az összes többi kütyü a 2G-s rádión lógott már, ami egy külön mise: korábban sétálgattam a házban, hogy szakadás nélkül átugrik-e a noti a másik AP-ra, de előbb csak belassult úgy 5 másodpercre, aminek hatására minden más 5G-s eszköz katapultált és átmenekült 2G-re. :)) Lényegében valami ilyesmi ment eddig is, ha mozgott a noti (vagy néhány más gép) a házban, akkor akár az AP-től pár méterre lévő TV-n is megszakadt a DLNA-s lejátszás...

    Majd még nézegetem ezt az AP-t, de az a nagyobb baj, hogy pont a CAPsMAN rendszer érdekelt volna, mégis meggondoltam magam az utolsó pillanatban és éjjel 2-3 darab helyett módosítottam a rendelést 1 szálra, de így nyilván nem tudom a CAPsMAN alatti AP-k közti roaming-ot tesztelni. :W
    De szerintem nem olyan rossz ez az áráért, szóval szerintem veszek majd még lenne legalább egyet tesztelni a CAP módot.

    Inkább úgy tűnik, hogy kiforratlan még a szoftver, hiányoznak fülek vagy sorok Winbox-ban, stb...

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Kiratheonly #5032 üzenetére

    Az érdekes. Nem tudtam, hogy jelentősen lassíthat a CAPsMAN.
    Gondolom gigabites vonal volt az AP-k közt...?

    Ma is játszottam vele kicsit és úgy tűnik a notik jobban szeretik, ha vízszintesen fekszik a kütyü (ahelyett, hogy a függőleges fallal párhuzamosan lóg egy kampóról), így kicsit magasabb jelszinteket jelez vissza egy fallal messzebbről.

    Valamint frissítettem a legújabb RC-re (még a mozgatás előtt), és ebben már kicsit kevesebb dolog hiányzik a Winbox-on belül, de még nem 100%. Ez tudom, hogy ennyi mintából még lehet bármitől (időjárás, véletlen szórás, stb), de utána picit jobb sebességeket mértem (+ 10-20 Mbps, tehát még mindig nem hozza az elvi maxot közvetlen rálátással pár méterről se, de azért közeledik).

    Még azon gondolkozom, hogy letekerem a CPU órajelet a minimum felajánlottra, mert még úgy is bőven soknak tűnik ez a CPU szimpla AP módhoz, hátha akkor kicsit hűvösebb lesz belül, ami jobb jel/zaj viszonyt hoz (nem mint ha forró lenne, de azért érezni, hogy melegszik).

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz bacus #5050 üzenetére

    Szerintem a szövegkontextusban és az említett eszközök lehetőségeit tekintve viszonylag egyértelmű volt minden, ha nem is teljesen tudományosan/szakmailag korrekt szemantikával. De én pl. mutattam screenshot-okat is, az már elég egyértelmű.

    De ezzel a hAP AC 2-vel biztos nincs valami rendben.
    Mármint vagy hibás példány, vagy sokkal inkább szar még/már a szoftver (a legutolsó bugfix-re még nem próbáltam downgrade-et, csak stable és RC lett kipróbálva).

    Kikapcsoltam a házban minden 5G-s kütyüt és ellenőriztem, hogy az emelet közepére rakott AP ~0% frekvenciahasználatot mér a kiszemelt csatornákon (legalább 2 téglafal minden irányból, aztán a szomszéd házak falai... vidéki kis falu, ilyenkor nappal sok ház üres, vagy öregek lakják...), aztán mértem egyedül csak a telefonommal közvetlen rálátásban pár méterről, és így is ingadozik a kapcsolat minősége, illetve hiányos a Windox-ban a statisztika (nem jelenik meg a jelszint mérés minden használt MCS-re, stb). 1 stream-el sem tudja tartani a .11N-ből örökölt MCS7 modulációt sem (nem még a 9-est), állandóan lefelé kapcsolgat, és nagyon alacsony CCQ-t jelez vissza, ami talán hibás is lehet, de közben fut a szintetikusan generált TCP adatforgalom, és arra is jelentősen alacsonyabb sávszél mérés jön ki, mint az elvi maximum, szóval tényleg leváltogat alacsonyabb MCS-re és/vagy ismételget adatcsomagokat.

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz janos666 #5053 üzenetére

    Ó, a bugfix a legrosszabb (6.40.8), AC-only módban nem csatlakozik hozzá semmi, A/N/AC módban pedig leragad <100Mbit/s rátákra minden (az 1-stream AC és 2-stream N kliens is) és >100% (!!!) CCQ-kat jelez vissza. :DDD (Mint ha nem is támogatná még a chipsetet a driver, csak valami korlátozott tesztüzemben.) Bár nem gyalultam le a beállításaokat downgrade után.

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Zwodkassy #5055 üzenetére

    Igen, tegnap megtaláltam én is. Nem az első eset, hogy csak akkor találom meg az ilyesmit, ha már félig-meddig reprodukáltam a problémát itthon, és az alapján keresgélek. Látatlanban valahogy nem jut eszembe úgy utánanézni a kiszemelt kütyünek, hogy "hap ac2 slow wifi". :D

    Gondolkozom is, hogy mit csináljak vele, mert nálam is elfogadhatóan működik a legújabb RC-vel, de igazából az az AP is tűrhetően üzemelt, amit erre cseréltem, és pont az lett volna a cél, hogy hosszú távon egy jobb és stabilabb WiFi-t építsek ki itthon (pár darab ilyen AP-vel CAPsMAN alatt), ne az hogy babrálgathassak vaktában és működjön épp elég jól (na meg így nincs kedvem venni még 1-2 darabot ebből, így maradna a vegyes-felvágott ASUS, TPLink, stb...).

    Lehet, hogy visszapofátlankodom a boltnak és levásárlom Ubiquti AC-Lite AP-re, csak van már pár Mikrotik kütyüm, így nagyjából ismerem, míg az Ubi-ba bele kéne tanulnom, de nem szimpi a "szuperfullautomata" hozzáállásuk (úgy sincs mindenkinek tökéletes alapbeállítás és hibátlan auto-konfig).

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Kiratheonly #5051 üzenetére

    Látom már mi lehet a gond. Ma átraktam az egy szál AP-n a wireless interfészeket CAP módba úgy, hogy ugyan ezen a kütyün fut a CAPsMAN is, és most látványosan magas a CPU használat, ha iperf-el forgalmat generálok. Majd kiderült mennyit bír sebességben, ha nem egyedül lesz (közben készlethiányok voltak, de a héten elvileg jön egy).

    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."

  • janos666

    nagyúr

    LOGOUT blog

    Első CAPsMAN tapasztalatom:

    Ha IP cím alapján csatlakozik a távoli CAP a MAN-hez (beírom kézzel az IP-t és üresen hagyom a discovery interfész mezőt), akkor ~75Mbps a max sebesség (iperf3 TCP) a CAP-re csatlakozó kliensen (és nem CPU terhelés miatt, szimplán valami hülyeség).
    Ha automatikusan találja meg MAC cím alapján a CAP a MAN-t (beállítom a megfelelő interfészt a discovery-hez), akkor nincs gond (jön akár ~200Mbps 80Mhz 1x1 módban).
    Mindeközben a helyi CAP-et (ami a MAN-el azonos eszközön fut) az auto discovery a kijelölt interfész IP-jével adja a listához (nem MAC címmel, mint a távoli CAP-et), nem is a 127.0.0.1 címet adja neki (hanem pl. amit épp DHCP-n kapott a discovery-hez kiválasztott interfész, mondjuk 192.168.1.233). Viszont szerencsére itt ez nem látszik befolyásolni a sebességet (akár 127.0.0.1, akár a DHCP-s cím szerepel ott, nem lassul), szóval működik ugyan az az egy sablon beállítás mindenhol (csak nem mindegy az pontosan melyik).

    Ha egy eszközön van a CAP és MAN, akkor lehet úgy bridge-elni, hogy automatikusan bedobáltatom az összes létező interfészt egy bridge-re (Bridge / Ports / all), tehát bekerül a bridge portokhoz a helyi (látszólag disabled állapotú) wlan és a MAN által létrehozott cap interfész is,
    ugyanakkor a távolról irányított CAP-en már ki kell szedni a bridge-ből az ottani wlan interfészeket, hiába szerepelnek ott (is) "disabled"-ként a listán (ilyenkor állandóan ledobálja a MAN a CAP-et és beírja a log-ba, hogy loop van a bridge-en).
    (Ez nekem bug-nak tűnik, mert nem sok logikát látok benne ---inaktívként látni a listán a wlan-t---, és mindenképp kényelmetlen, ha esetleg szeretne váltogatni az ember szóló és CAP mód közt, mert ha piszkálom a bridge portokat, változhat a bridge MAC is, szóval kidob a Winbox, aztán ha DHCP-ről akarok IP-t a bridge-nek, még azt is át kell állítanom az új MAC-hez...)

    Valamiért, ha felállt mindkét AP mindkét rádiója a CAPsMAN alatt, akkor az androidos telefonom az eddigitől lassabban csatlakozik, aztán fárasztóan sokára kap IP-t (a DHCP szerver nem a Mikrotik kütyükön fut, hanem egy x86 háziszerveren), majd egy darabig azt mondja nincs net, végül megjön minden. Ez össz-vissz akár több, mint egy perc, az eddig néhány másodperc helyett (cakk-pakk).

    A seamless roaming nem látszik realizálódni. Olyannyira, hogy a fent vázolt lassabb kapcsolódás miatt talán még lassabb is, mint mikor össze-vissza mindenféle kütyü volt külön csatornákon (most azonos csatornákon vannak az AP rádiók). De ezt majd még tesztelgetem (most talán van egy holtpont a tesztelt sétaútvonalon, nem a tervezett végleges helyén van még a második AP).

    Eddig úgy tűnik, hogy ha frissen áll fel az AP hálózat és először csatlakozik a telefon halál lassan, utána ha átsétálok AP1 alól AP2 alá, akkor teljesen meghal a hálózat a telefonon egész hosszú időre, de ha ezután visszasétálok AP2 alól AP1 alá, akkor nem csak 10-20 másodperc kiesés nincs, de látszólag egyáltalán nem szakad meg a kapcsolat.
    Bár még ki kéne most próbálnom ugyan ezt CAPsMAN nélkül (pont ettől vártam azt, hogy nem kéne minden AP-nek külön-külön babrálnia a roaming-hoz, mert "ismeri" a klienst a MAN...). Lehet, hogy egy ilyen körbejárás után a telefon lesz okosabb, vagy külön-külön egy-egy rádió "emlékszik" rá (és tenné ezt CAPsMAN nélkül is). :F

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz bacus #5124 üzenetére

    Nemrég írták itt lentebb, hogy lassította nekik a WiFi sebességet a CAPsMAN. Ezért is írtam le, hogy miként sikerült véletlenül reprodukálnom a lassulást. Reméltem talán segít másnak a tipp, aki véletlenül belefutott, mert szerintem nem nehéz.

    Első tippre azt hittem, hogy ha nem jelölök ki discovery interfészt, az azt jelenti, hogy minden interfészen keres, nem azt hogy egyiken se. Továbbá alap megközelítésem, hogy első körben minden mezőt üresen hagyok, amit nem muszáj kézzel kitölteni, aztán majd később finomítom ha, és amit kell, vagy épp akarok.

    Másképp elmondva ez a rossz példa (így lelassul a wireless a távoli CAP-en):

    set caps-man-addresses=192.168.1.12 enabled=yes interfaces=wlan_2g,wlan_5g

    Ilyenkor IP címmel kerül be a CAPsMAN listájába a távoli CAP.
    De megtévesztő lehet, hogy mikor azonos eszközön van a CAP és a CAPsMAN, akkor ez is jól működik (ezért ha valaki így próbálja ki először, akkor azt hiheti működni fog a többi CAP-el is ugyan ez, főleg hogy menni megy is, csak lassul, de csak a távoli... szóval nem triviális észrevenni sem, hogy mégsem jó).
    Illetve a helyi CAP mindig IP címmel fog szerepelni a CAPsMAN listán, bárhogy van ez beállítva neki (ezért is gondoltam, jobb ha mindet IP-vel veszem fel, akkor csak IP címek lesznek a listán, nem vegyesen IP és MAC címek, ami kozmetikailag szebb, emberileg átláthatóbb lett volna --- persze nem fontos).

    De így a jó (ilyenkor nincs lassulás wireless sebességben):

    set discovery-interfaces=bridge1 enabled=yes interfaces=wlan_2g,wlan_5g

    Ilyenkor MAC címmel kerül be a CAPsMAN listába a távoli CAP
    (Persze ez lehet ether1, nem csak bridge1, nálam bridge-elve van minden eth*)

    ----------------------------------------------------------------------------------------

    A másik javaslat: persze, hogyne, mindjárt legyalulok mindent netinstall-al, aztán kézzel egyesével visszaállítok mindent, akár többször is egymás után, míg tesztelgetek. :K ;] :U :P
    Ha lehet, akkor mindig a lehető legrugalmasabb beállítást keresem, hogy minél több változtatást éljen túl, minél többféleképp ki lehessen próbálni X dolog paraméterezését úgy, hogy nem kell Z,K,L,M beállításokat kézzel hozzáigazítani egy X kapcsolgatáshoz.

    Szóval ez az, ami működik önálló AP-ken, és akkor is, ha ugyan azon a gépen fut a CAPsMAN és a CAP (megint kanyar vissza a gondolathoz, hogy ha legelőször egy gépen teszteled a CAPsMAN-t, akkor azt hiszed jó lesz a többire is, mert egy gépen belül működött, de a többi, távoli CAP-en már nem fog):

    add bridge=bridge1 interface=all

    Ez azért (lenne) kényelmes, mert ha letiltod a CAP módot, azonnal sima AP-ként kezd üzemelni az eszköz, minden további konfigurálgatás nélkül (mielőtt kötekedés..: az meg azért jó, ha minimális erőbefektetéssel és emberi hibalehetőséggel szeretnéd tesztelgetni, jobb-e neked a CAP mód, mint több szóló AP, vagy sem).

    Azért is zavaró, mert a távoli CAP-eken is így néz ki bridge a fenti beállítással:

    Tehát mindkét wlan interfész, amit most a CAPsMAN kezel, disabled port-ként szerepel. Ennek ellenére mégis loop-ot okoz ez a beállítás.

    Persze ha törlöm az all-t és berakom az ether*-eket a bridge-be a wlan*-ok nélkül, akkor minden OK, csak akkor kézzel hozzá kell adnom a wlan*-okat, ha kiveszem őket CAP módból (de ami miatt még kényelmetlenebb ez, hogy ilyenkor másik MAC-et választ magának a bridge1 interfész, ami miatt leszakad a Winbox és másik IP-t kap az eszköz DHCP-ről, szóval egy rakat beállítást kell kézzel módosítani).

    ----------------------------------------------------------------------------------------

    Szerk.: Úgy tűnik mégis ugyan úgy ki kell venni a wlan* interfészeket a bridge-ből a CAPsMAN eszközön is. Kipróbáltam, és megszűnt a lassú kapcsolódási és DHCP címlekérési probléma a WiFi klienseken. Akkor ott is ugyan úgy gondot okoz, csak kevésbé látványosat és nem kapok a log-ban hibaüzit.

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz ssarosi #5129 üzenetére

    "nem szívesen kezdeném 0-ról, de ha ez okozza, és nem megy másképp, megteszem"

    Nem tudom mennyire megbízható, de én úgy szoktam néha "letisztítani" a beállításokat, hogy a terminálban kiadom az export parancsot, ami csak az alapbeállítástól eltérő dolgokat listázza, aztán egyrészt átnézem mi tűnik (szemre) feleslegesnek (*), aztán összevetem a többi hasonló eszköz exportált listájával (winmerge) és összehangolom őket (kivéve persze azt, ami szándékosan egyedi egy-egy kütyün).

    (*) Ide esik bármi, amit régen próbaképp babrálgattam, vagy esetleg verziófrissítések közben ragadt ott úgy, hogy most el van mentve egyedi értékre a régi alapbeállítás, pedig gyakorlatilag irreleváns/inaktív (tehát kár "cipelni"), vagy jobb is lenne az új alapérték.

    Azért nem bízom ebben 100%-ig, mert a backup file-ok, amiket a ROS generál, ilyenkor is jelentősen eltérő méretűek lehetnek, ha két egyforma eszközön szinte 99% ugyan az a config van az export szerint (pl. egyedül csak az identity és frekvencia beállítások térnek el két AP közt és 23 vs. 34 kb a backup).

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz feketegergo #5161 üzenetére

    Nem fontos fix IP az AP-nek, csak ha neked úgy kényelmesebb/tetszetősebb.

    Én sima AP-hez törlöm a konfigot, kikapcsolok minden csomagot a DHCP, System, Wireless kivételével (a DHCP is opcionális, beírhatsz neki fix IP-t kézzel is --- ezután eleve kevesebb a menüpont is, így általában állítani is kevesebbet kellhet a kevesebb lehetőségből).
    Egy bridge-be dobok minden portot (az "all"-t adtam hozzá portként).
    DHCP-szerver KI, -kliens BE a bridge-en
    Wireless: ahogy neked tetszik ap bridge módban.
    Ha van valami fix IP, akkor arra törlés.
    Ha még nem üres, kipucolom az összes tűzfalszabályt (itt felteszem van előtte egy vagy akár több eszköz, amin aktív valamilyen tűzfal, így itt akár már többszörösen is redundáns lenne, de persze ezt te tudod).

    A wireless bridge kiegészítés könnyen kikapcsolható, ha nem igényled.

    Ha most nem tévedek emlékezetből, akkor a QuickSet menüből a PtP Bridge AP a leghasonlóbb egy ilyen "minimalista AP" módhoz, a Home AP inkább egy Home Router. Az AP-ként árult kütyüjük lényegében egy Router az alapbeállításokon (egy tűzfallal lezárt WAN port fogad, a LAN portokon pedig DHCP szerver fut, szóval kvázi SOHO Router na...), gondolom azért, mert fordított esetben a kevéssé intelligens vásárló nyafog a support-nak, hogy "feltörték netről a wifim és letiltott a netszolgáltatóm miattatok".

    Ja, ezek a kis műanyag dobozok elég langyosak tudnak lenni, főleg nyári melegben, zárt térben, légmozgás (és légkondi) nélkül meglepően meleg lehet a tapintásuk.

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz feketegergo #5186 üzenetére

    A reset csak a konfiguráció módosításokat törli (az alapértékhez képest, így visszakapod az alapot), a netinstall újraírja az OS-t (szóval akkor is működik, ha megsérült valami rendszerfile, illetve ha annyira sem képes a rendszer, hogy törölje a beállításokat a reset gomb nyomkodásakor).

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz feel2006 #5200 üzenetére

    Az a baj az ilyen védelmekkel, hogy néha annyiba kerül, mint a valószínáségek alapján adódó potenciális kár, mert minden évben azért nem csak be a villám hozzád. Mondjuk ha többmillűs szoba, akkor OK, de pl. egy 100k-s TV-t védeni egy 50k-s APC-vel, azért na...
    Nekem a fél millás TV előtt sincs most semmi (lusta vagyok elvezetni az APC-től az új helyére, régen el volt a 200k-shoz is, ha már úgyis kellett a PC-hez a szünetmentességért).

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz bambano #5275 üzenetére

    "azon a ponton, ahol a csomag érkezik, nullához közelítő hatékonyságot lehet elérni."

    Ahogy nézegettem az RC changelog-ot, nemsoká a ROS is engedi majd az ingress QoS-t. Bár persze fogalmam sincs milyen formában oldják meg és hogy fog működni a gyakorlatban.

    Én évek óta használom a router-ként is üzemelő Linux PC-n ezt a script-et (némi módosítással, pl. felvettem még egy alacsonyabb HTB prioritást és port számok alapján besoroltam oda olyasmiket, mint pl. a torrent forgalom): https://wiki.gentoo.org/wiki/Traffic_shaping
    Annyi benne a "trükk", hogy átirányítja a forgalmat egy virtuális eszközre, amitől tükörképként jelenik meg a ki/be irány, így rá lehet húzni kimenő forgalom szabályzási sémát a bejövő forgalomra.

    Nem tudom miért nem kéne tudni működnie, hisz a feladó oldal lényegében a te tetszőlegesen megszabott limitedet "érzi" ahelyett, amit a szolgáltatód szabott meg az élőfizetésedhez (nyilván míg a te limited kisebb, mint a szolgáltatás valós elérhető sebessége).

    A tapasztalatom az, hogy nyilván nem "tökéletes", de messze jobb, mint a "nulla közeli hatékonyság". Nyugodtan lehet pl. futtatni ésszerű számú torrent letöltést anélkül, hogy bármi korlátozás lenne a torrent kliensben és jelentősen megnőne a késés, vagy használhatatlanra zuhanna a magasabbra priorizált forgalom sebessége. Általában legalább a max sebesség harmadát, de inkább a felét megkapja a magasabbra priorizált forgalom még akkor is, ha viszonylag drasztikus dolgok mennek az alacsonyabb prioritású portokon (olyan, ami shaping nélkül úgy le tudná lohasztani a netet, hogy a kliens gépeken sorról sorra tölt be minden kép a weboldalakon, mint ha betárcsázós modemről jönne a net).

    Volt már egyszer, hogy kernel frissítés után eltűnt az IFB (régen két ilyen eszköz volt az alapértelmezés, ha be van forgatva a modul, most nulla, külön paraméterrel kell kérni egyet is), így véletlenül kipróbáltam, hogy milyen mikor elveszem a shaping-et. Hamar elkezdtem turkálni a dolgokat és meglett a hiba.

    Na persze a dual-WAN load-balance az megint más, sohasem próbáltam, nem is szeretném. De sokszor olvastam már tőled a traffic shaping / QoS kérdésben a fenti is idézett kijelentést (és most láttam, hogy a Mikrotik sem ért vele egyet, mert jön a feature).

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz bambano #5282 üzenetére

    "De ez látszatmegoldás, nem igazi."

    Ha nincs "igazi", de látszólag működik a "látszat", akkor miért ne használjuk és miiért mondjuk azt, hogy nincs semmi megoldás?
    Én annyit látok, hogy mikor használom, akkor semmi fennakadást nem lehet tapasztalni racionális körülmények mellett, míg ha kilövöm, akkor nagyon könnyű lerohasztani a sebességet (szándékosság nélkül) és egekbe lőni a késést (úgy, hogy még a webböngészés sebességén is érződik, a videotelefonálás is megsínyli, online játék esélytelen...).

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    Viszonylag normális az, ha egy emeletes ház ablakán kinéző ASUS N66U-t (az eredeti dual-band omni-directional antennáival) kicseréltem egy SXT Lite2 r3-ra (használtan vettem, ROS 6.43.4-re frissítettem és reset-eltem), ami egyenesen a "célra" néz (nevezzük úgy "sufni" ablakára), akkor roszabb lett a helyzet (eddig szimplán lassú és néha szakadt, most alig csatlakozik fel a kliens és mikor mégis, akkor lassabb)?
    Az N66U hírhedten hangos (régi firmware-el nem felel meg az FCC-nek), de az SXT-nek papíron 10 dBi az antenna nyeresége. (A teszthez manual-txpower módba tettem, vagyis elvileg 27db max, amit ír.)

    Nem azt tartom lehetetlennek, hogy nem működik jól az SXT sem ebben a szituációban, csak hogy relatívan rosszabb ez, mint az omnnis cucc. :U

    Azért ez volt a lépés, mert az SXT-t fel lehet tenni magasabbra kültéren (míg a beltéri ASUS-t nem), így már remélem elég lesz. De így elbizonytalanodtam, hogy elég lesz-e kicsit jobb elhelyezéssel az SXT, ha most így muzsikál.

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz ekkold #5904 üzenetére

    Működik a pont-pont kapcsolat Bridge módba rakott Level3 Mikrotik (most abban van ez az SXT) és 1 darab tetszőleges (nem csak Mikrotik) kliens közt is.
    Ezt most frissen is kipróbáltam újra az aktuális ROS verzióval (mikor teszteltem, hogy jól konfigoltam és nem szemetet adtak-e el): itthon az asztalon letettem mellé egy telefont, és pörgettem rajta a szintetikus adatforgalmat iperf3-al. Gond nélkül ketyegett, nem szakadozott és jól volt a sebesség is.

    Nyilván ezer dologtól függ minden ilyen, de annyit csináltam, hogy felemeltem az ablaküvegnek támasztott N66U-t, aminek az egekbe néztek az omni antennái, és odatettem a helyére az SXT-t, beforgatva, hogy lehetőség szerint legjobban a kliensgépre nézzen (pontosabban annak az épületnek az ablakára, ahol az van).
    Egyetlen mobiltelefont kéne csak a hálózaton tartania. Az N66-nak nagyjából sikerült (saccra úgy óránként szakadt csak le), csak kicsit kellett volna jobb, de helyette egyértelműen rosszabb lett (már tiltólistázta is az Android az AP-t, előtte pedig percenként leszakadt).
    Én most ezen lepődtem meg picit, hogy relatívan rosszabb ide ez az STX.

    Még azt tudod megtenni low-buget kreatív-barkácsolgatással, hogy viszek a "sufni" ablakba egy leselejtezett Atheros rádiós TP-Link router-t, és megpróbálok WDS-t összedobni OpenWRT és Mikrotik ROS közt (vagy ha az nagyon nem, akkor NAT-olni vele, de azt nem szeretem). Szokott a WDS sikerülni? (Úgy tudom a fontosabb, hogy a chipset kompatibilis legyen.)

    (#5906) gabyka - De akkor sokkal több eszköz kell: egy AP a főépületbe (pl. egy második SXT, vagy marad a helyén az N66U), a sufnis kliens SXT, és még egy AP a sufniba, amire végül a telefon csatlakozhat.
    Ezt akartam megúszni, különben 2db Lite5-öt vettem volna 1db Lite2 helyett (+ az N66U vagy valami régi TP-Link szemét ment volna át a sufniba AP-nek).

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz bambano #5908 üzenetére

    Nem is akartam, míg nem jött a válasz, hogy ez a baj.
    Ha akarja törölheti topikgazda/moderátor.

    Viszont a WDS már nem működik Atheros-os Mikrotik és Atheros-os OpenWRT közt (ezt ROS L4-es AP-vel is kipróbáltam). Szóval majd kereshetek oda valami használt L4-es Mikrotik AP-t. (Elkezdtem beállítani az OWRT-n WALN->WLAN NAT-ot, de 10-20 perc után felhúztam magam rajta, hogy valamiért nem sikerült.)

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz pappkarcsi #5921 üzenetére

    A seamless-roaming cikket szerintem felejtsd el. Legutóbb pont emiatt vettem itthonra Mikrotik hAP AC2-ket (más célra ismertem és szerettem már a márkát), de nálam nem látszik segíteni semmit a roaming-on a CAPsMAN, és így azóta is furdal, hogy az Ubiquiti cuccai jobbak lettek-e volna erre a vágyra (roaming).

    Szerintem csak egy port forward kell az NVR-ra, és azon keresztül éred el a kamerák real-time stream-jét is WAN-on, miután beléptél az NVR-ra a saját manager szoftverükkel (ha van ilyen funkciója az NVR-nak, nem ismerem a Hikvision-t), vagy amit már rögzített az NVR (ezt a "múltat" szinte minden NVR-on eléred).

    Én személy szerint kihagynám az NVR-t, ha van a hálózaton valami amúgy is 24/7 online PC, vagy összeraknék erre valami kis gépet (Intel J szériás integrált deszkákból, vagy akár egy Raspberry, stb) ffmpeg-el rögzíteni az RTSP stream-et, és akkor lehet minden kamera a LAN-on vagy akár a WAN-ra is forward-olt.

    Pl. egy egyszerű linux bash script kivált egy NVR-t.:
    while :; do sleep 1 && ffmpeg -rtsp_transport udp -i rtsp://192.168.1.201/user=admin_password=yyy_channel=1_stream=0 -vcodec copy -an -t 3600 /mnt/data/surveillance/XXX/1/`date +%Y.%m.%d_%H.%M`.ts 2>/dev/null; done
    Plusz egy cronjob ami törli a régi file-okat ebből a mappából. (Az URL persze márka/típus függő.)

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz e90lci #5930 üzenetére

    Mi? :Y Roaming 1 CAP-el? Roaming? Raom A-ról A-ra és vissza A-ra? :C ;]

    (#5929) bacus - Lehet, hogy csak ezekkel a még mindig viszonylag új IPQ-4018 chipsetekkel van szoftveres (ROS) gond, vagy az épp tesztelt kliensek a reménytelen ügyek és kivételek (többnyire Qualcomm chipset-es kütyüket néztem, bár mind AC wave-1 vagy N, nem wave-2, de próbáltam Intel AC kártyás notival is sétálgatni).

    Maga a CAPsMAN működik és nyilván roaming-ol is a kliens, csak épp nem látom, hogy bármivel simább vagy gyorsabb lenne a roaming, ha CAPsMAN alatt vannak az AP-k, mint ha teljesen önállóan vannak a levegőben.
    Így is, úgy is vált előbb-utóbb a kliens, de sohasem teljesen észrevétlen (vagy csak véletlenszerűen néha elég gyors, hogy annak nevezzem, de nem kiszámíthatóan) és nem láttam, hogy függne a jellemző/átlagos roaming újracsatlakozási idő a CAPsMAN-től (szerintem ránézésre mindig a klienstől függ, akár CAPsMAN, akár nem).

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz #42556672 #5935 üzenetére

    Az egyértelműség kedvéért leírnád kérlek (és aki még hozzászólt), hogy pontosan mit tapasztalsz: CAPsMAN és önállóan konfigurált AP-k közti szituációkban roaming ügyben?

    Többszöri tesztelés után is egyértelműen azt látod, hogy CAPsMAN-el szignifikánsan gyorsabb az újracsatlakozás, vagy akár szó szerint teljesen észrevétlen (meg sem szakadnak az aktív kapcsolatok)?

    Azonos vagy eltérő csatornákon vannak az AP-k?
    Minden AP és a kliens is dual-band (engedélyezve van a 2G és 5G rádió mindenen, AP-ken és klienseken is)?
    Ha igen, akkor ugyan az az SSID? Csak 2G-n és 5G-n belül külön-külön, vagy az összes rádión?

    Többféle kliens eszközzel is teszteltél (pl. random okostelefon), vagy csak valami kézileg finomhangolt beállításokkal üzemelő PC-vel mászkáltál szép óvatosan?

    Lehet, hogy valahol valami apróság hiányzik nálam, de...

    /caps-man channel
    add band=2ghz-onlyn extension-channel=eC frequency=2472 name=13-9
    add band=2ghz-onlyn extension-channel=Ce frequency=2452 name=9-13
    add band=5ghz-n/ac extension-channel=Ceee frequency=5180 name="36-42 (5170-5250)"
    add band=5ghz-n/ac extension-channel=Ceee frequency=5500 name="100-106 (5490-5570)"

    /caps-man datapath
    add bridge=bridge1 client-to-client-forwarding=yes name=datapath1

    /caps-man security
    add authentication-types=wpa2-psk encryption=aes-ccm name=security1 passphrase=XXXXXXXXXXXXX

    /caps-man configuration
    add channel=13-9 country="hungary" datapath=datapath1 distance=indoors hw-retries=15 name=2g security=security1 ssid=YYY
    add channel="100-106 (5490-5570)" country=hungary datapath=datapath1 distance=indoors hw-retries=15 name=5g security=security1 ssid=YYY

    /caps-man interface
    add channel=9-13 configuration=2g disabled=no l2mtu=1600 mac-address=XXXXXXXXXXX master-interface=none name=2g-F17a_AP_0b-1 radio-mac=XXXXXXXXXXX radio-name=XXXXXXXXXXX
    add channel=13-9 configuration=2g disabled=no l2mtu=1600 mac-address=XXXXXXXXXXX master-interface=none name=2g-F17a_AP_1c-1 radio-mac=XXXXXXXXXXX radio-name=XXXXXXXXXXX
    add channel="36-42 (5170-5250)" configuration=5g disabled=no l2mtu=1600 mac-address=XXXXXXXXXXX master-interface=none name=5g-F17a_AP_0b-1 radio-mac=XXXXXXXXXXX radio-name=XXXXXXXXXXX
    add channel="100-106 (5490-5570)" configuration=5g disabled=no l2mtu=1600 mac-address=XXXXXXXXXXX master-interface=none name=5g-F17a_AP_1c-1 radio-mac=XXXXXXXXXXX radio-name=XXXXXXXXXXX

    Az SSID mindig ugyan az. Próbáltam tartományonként azonos csatornákkal (mint látszik is, alapértelmezésben először minden AP ugyan azt a csatit kapta, később szedtem szét kézzel, mikor láttam hogy annak nem volt haszna).

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz #42556672 #5937 üzenetére

    Kösz a részletes választ. :R
    De egy kulcspont még mindig hiányzik: mit tapasztalsz, ha nem CAPsMAN alatt futnak az AP-k és sétálgatsz? Van különbség? Olyankor rendszeresen megszakad a videóhívás AP váltáskor?

    Arra célzok, hogy biztos a CAPsMAN érdeme-e vagy szimplán "okosan" vándorolnak maguktól is a gépeid. Nekem is van olyan, ami igen, de van ami nem. Van ami MAN-al is ügyetlen és van ami anélkül is ügyes...
    Ezért nem vagyok meggyőzve, hogy úgy igazából bármit is segít a MAN.

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz #42556672 #5939 üzenetére

    Ezt nyilván megértem.

    Az előbbi 10-20 percben fel-alá szaladgáltam a házban legalább tízszer két telefonnal a kezeimben: megpróbáltam videóra venni egy "connection aborted" üzit (és ahogy eltűnik néhány másodpercre, majd újra megjelenik a WiFi logó az Android teló felső sávjában), de azon kívül hogy hülyén néztem ki, nem jártam sikerrel, sohasem szakadt meg a TCP kapcsolat (csak lelassult ~0 körüli sebességre pár másodpercre, de nem zárult le).

    Lehet, hogy mikor legutóbb játszottam hasonlót (csak akkor nem próbáltam videózni), épp előttem sorban az ezerből-egynéhány eseteket, vagy pont valami ritka rossz együttállás volt a szoftver verziókkal, vagy az "éterrel".

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz ekkold #5948 üzenetére

    A Factory-only tippre szerintem ezeket jelenetheti:
    - Mostantól ez a verzió kerül a frissenn gyártott hardware-ekre a gyárban
    - A szoftveresek ki akarták adni, de megbukott valami utolsó belső teszten
    - Valamilyen speciális, házon belüli tesztelési célra készítették (kis változtatással a legutóbbi "release" kódhoz, nem a legfrisebb béta/RC kódból)

    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."

  • janos666

    nagyúr

    LOGOUT blog

    Pontosan mit jelent az a gyakorlatban, mikor annyi jelenik meg a log-ban, hogy "radar detected on xxx0000"? Akkor is ezt naplózza, ha nem valódi radar-on működik a DFS, hanem szimplán a spektrális eloszlás tűnik ott túlzsúfoltnak, ahol épp van? Vagy "divat" lett direkt piszkálni mások magáncélú legális (DFS=on) vonalait hamis radar mintákkal (pl. valami szolgáltató)?

    Évek óta üzemelt feltűnő/zavaró szakadások nélkül két SXT (két AP egy karón ~160° szöggel egymástól, 1-2 km távra), de mostanság látványos lett, hogy szakadozik, így elkezdtem nézni a naplókat és főleg az átlagosan csak kicsit magasabb, de jobban ingadozó sávszélt bonyolító AP ugrál néha reménytelenül fel-alá, mindenhol csak radar, radar, radar.

    Miközben elkezdtem felvezetni egy excel táblába a radar frekiket, végül egyrészt arra jutottam, hogy az 5500-5700:20 tartományban (ez a scanlist mindkettőn) gyakorlatilag az összes standard 20MHz csatornán lát radart a cucc akár egy napon belül, de ami picit "gyanússá" látszik nekem tenni a dolgot, hogy úgy tűnik, mint ha sokkal sűrűbben találna radar-t, ha kézzel pakolászom a kezdő frekvenciát (hogy "térképezzek" ott is ahova véletlenszerűen még nem dobta be, majd le), akkor "felbolydul a méhkas" és agyvesztve ugrál 1-2 percenként a csatornák közt, míg végre lenyugszik valahova, akár olyan helyre ahol az excel táblámba pár órával korábban írtam be egy radar-t és ott marad mondjuk egy napot. Ha másnap megint hozzányúlok kézzel, akkor megint megőrül és hirtelen már megint van radar ott is, ahol az előtt állt, hogy pl. frissítettem a ROS-t és emiatt indult újra megint a manuálisan választott frekivel.

    Ez persze lehet véletlen, de inkább tűnik valami rosszindulatú bökdösésnek, vagy esetleg bug-nak.

    Pl. itt van most ez:

    13:54:02 system,info,account user admin logged out from 192.168.1.111 via winbox
    14:01:17 wireless,info wlan1: radar detected on 5500000
    14:01:17 wireless,info @wlan1: disconnected, disabling
    14:01:47 wireless,info wlan1: radar detected on 5580000
    14:02:55 wireless,info @wlan1: connected, signal strength -60, wants bridge
    14:10:31 wireless,info wlan1: radar detected on 5540000
    14:10:31 wireless,info @wlan1: disconnected, disabling
    14:11:36 wireless,info @wlan1: connected, signal strength -65, wants bridge
    17:42:37 system,info,account user admin logged in from 192.168.1.111 via winbox
    17:48:05 wireless,info @wlan1: disconnected, disabling
    17:48:05 system,info device changed by admin
    17:58:13 wireless,info @wlan1: connected, signal strength -61, wants bridge
    18:53:21 wireless,info wlan1: radar detected on 5600000
    18:53:21 wireless,info @wlan1: disconnected, disabling
    18:53:24 wireless,info wlan1: radar detected on 5640000
    18:53:35 wireless,info wlan1: radar detected on 5620000
    18:54:42 wireless,info @wlan1: connected, signal strength -60, wants bridge
    18:59:11 wireless,info wlan1: radar detected on 5540000
    18:59:11 wireless,info @wlan1: disconnected, disabling
    18:59:41 wireless,info wlan1: radar detected on 5660000
    19:00:08 wireless,info wlan1: radar detected on 5560000
    19:01:15 wireless,info @wlan1: connected, signal strength -63, wants bridge
    19:04:31 wireless,info wlan1: radar detected on 5580000
    19:04:31 wireless,info @wlan1: disconnected, disabling
    19:05:01 wireless,info wlan1: radar detected on 5500000
    19:05:11 wireless,info wlan1: radar detected on 5520000
    19:05:21 wireless,info wlan1: radar detected on 5680000
    19:23:49 wireless,info wlan1: radar detected on 5600000
    19:23:52 wireless,info wlan1: radar detected on 5640000
    19:24:12 wireless,info wlan1: radar detected on 5620000
    19:29:39 wireless,info wlan1: radar detected on 5540000
    19:30:06 wireless,info wlan1: radar detected on 5660000
    19:30:26 wireless,info wlan1: radar detected on 5560000

    Közben a másik AP viszonylag nyugisan volt el 5680-on, úgyhogy most nem is "egymást üldözték" (már erre is gondoltam, hogy mikor túl közel vannak a frekik, akkor zavarják egymást az egy karón lévő AP-k, de ez szerintem már akkor is sok).

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz #42556672 #5983 üzenetére

    Lehet, hogy félreértem, de ez alapján állítottam be a scanlist-et 5500:5700:20-ra:

    (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
    # note: max would be +3dB with TPC @ 5250-5725
    (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
    (5470 - 5725 @ 160), (27), DFS, wmmrule=ETSI
    # "Short Range Devices (SRD)"
    # ref: 2006/771/EK, (EU) 2017/1483, MSZ EN 300 440, MSZ EN 302 064
    (5725 - 5875 @ 80), (25 mW)

    Ebben nem látok DFS nélkül kültérre és távolra engedélyezett tartományt.
    De próbaképp szétnéztem 5260-5320 közt is, és ott is találnak radart.

    Az NMHH link szerint csak 5600 és 5650 közt kéne radarnak felbukkannia.
    Gondolom lehet az NMHH-n kívül másnak is hasonló radar-ja. Vagy nálunk más DFS frekin kvázi-legális kilőni a DFS-t (gyakorlatilag véletlen sem jön matricázott autó kopogtatni)?

    A beltéri, földszinti AP 5170-5250 (van a földszinten egy AC kliens, ami nem működik megfelelően DFS csatornákon), az első emeleti beltéri 5250-5330, a padlás üres, a tetőn pedig a két kültéri AP.

    Az emeleti beltéri AP sohasem lát radart, igaz két fal választja el a külvilágtól (középcső lépcsőházból). Nem tudom mikor kezdődött a kültériekkel a radar móka, nem figyeltem (miután kezdetben kijátszogattam magam a konfigurálgatással, utána hosszú időre elfelejtettem, hogy vannak, csak rájuk dobtam néha a friss ROS-t).

    Azon próbálom erősen törni a fejem, hogy vajon DFS=off (régi firmware-ben még volt ilyen) vagy akár SC módban felejthettem-e esetleg őket véletlenül régen, és azért működtek-e ennyi szakadozás nélkül (míg mondjuk frissítéssel eltűnt a DFS=off, vagy egyszer láttam, hogy "ez meg miért van SC-ben?" és kivettem...).

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz ssarosi #5995 üzenetére

    Igaz nem Mikrotik, de van olyan switch-em, amin 8 portból van mindenféle: 0, 10, 100, 1000 Mbps link (ha próbaképp mindre dugok 1000-res túloldalt). Mikor megvettem (használtan) még mind jó volt, és sorban rosszabbodott, míg kicseréltem egy újra (mikor elfogadhatatlan lett, amit még tudott). Az új nem problémázik, szóval nem hiszem hogy a túloldal gyilkolta meg a régit.

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz janos666 #5903 üzenetére

    Ennek folyományképp kint maradt az egyik ablakban az SXT 2nD r3, a másik épület ablakéba pedig tettem egy RB951Ui-2HnD dobozt, de most is instabil a kapcsolat és nagyon aszimmetrikusak a dBm szintek: Tx/Rx: -88/-55.
    Hibás lehet az SXT jelerősítője?

    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."

  • janos666

    nagyúr

    LOGOUT blog

    Jellemző meghibásodás az, ha egy SXT Lite5 áramtalanítás után egyre gyakrabban úgy jön vissza, hogy:
    1: csak 100M-Half sebességet hirdet (alapértelmezett ethernet beállításai voltak, tehát hirdetett mindent, amit ismert, és 100M-Full módban üzemelt, mikor még jól működött)
    2: A Winbox nagyon lassan rátalál a MAC címére (sőt, még a PtP WiFi link távoli oldalára is) 0.0.0.0 IP-vel, de MAC-el sem tud rá bejelentkezni
    3: ha elég kitartóan áramtalanítgatom, néha feláll és hibátlanul működik.

    Mikor legutóbb be tudtam lépni rá feltettem rá a legújabb ROS-t és nyomtam egy bootloader upgrade-et (mivel nem volt közben reboot, így ugyan arra a verzióra, de gondoltam újra felül frissen) és szoftveresen kértem reboot-ot, de akkor sem jött vissza. Közben átfutottam a beállításait és minden jónak tűnt, a log-ban sem volt semmi fura, míg futott.

    Először a spontán áramszünetek után kellett párszor kézzel áramtalanítamon, de idővel csak rosszabb lett, már kezdek felette keresztet vetni (sokszor áramtalanítottam most sorban sikertelenül).

    Próbáltam három különböző feszültségű táppal, kétféle PoE injektorral (miki kábel és egy noname "téglával"), még egy cross-kábelt is betettem a PoE injektor és switch közé próbaképp. Kötöttem közvetlenül switch helyett PC-s NIC-be. Semmi nem érdekli, 100M-Half, azon van forgalom, de belépni nem lehet rá és minden arra utal, hogy WiFi link van ugyan, de az sem használható (a távoli gépek sem érhetők el).

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Botka_db #6172 üzenetére

    A netinstall-t ismerem, de az a baj, hogy karóval együtt jön csak le a magasból.
    Most még próbálgatom, hátha visszajönne addig, hogy átállítsam a boot módod ether-re. Azzal kvázi mindig netinstall módba boot-ol legközelebb, ugye...?
    Tudom, hogy az se lesz elég, ha a bootloader nyavalyog, de azt most írtam felül frissen. Igaz a ROS-t is, de az még lehet hogy valami konfigurációs hiba miatt akad ki boot után.

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz ekkold #6176 üzenetére

    bambano kedvéért ezt most úgy fogom minősíteni, hogy: "Brilliant!" :D
    Megérte tanácskozásra bocsátani, mert eddig is tudtam, hogy a wireless (bridge) link működni látszik, de nem jutott eszembe autóba ülni, és megpróbálni elérni az ottani ethernet-en át az itteni SXT-t. :R

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz janos666 #6170 üzenetére

    Végül mégis életre kelt helyben (sokadjára).
    LOG-ban semmi, conf. export-ban semmi látható hiba (diff nézetben csak a triviális dolgok mint pl. SSDI térnek egy rokonáétól, ami zavartalanul dolgozik és ugyan ebbe a switch-be köt).

    Szóval ha most átrakom nand->ethernet helyett ethernet->nand opcióra a boot sorrendet, akkor a soron következő reboot után rákap a helyi hálós PC-s netinstall-ra?
    Ezzel csak annyi a baj, hogy talán ismét 10-20 áramtalanítás kell majd neki. :Y

    Érdemes lehetne bepipálni, hogy Force Backup Booter? :U

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Mr Dini #16314 üzenetére

    Azt hittem, hogy a RouterBoard firmware-ben csak a bootloader van, ami boot után érdektelen. Ha ez igaz (van hatása boot után is), akkor lehet, hogy átgondolom azt, hogy mikor OpenWRT-t tettem a hAP AP AC^2-re (köszönöm Mikrotik, hogy sohasem lesz Wave 2 driver 128MB-os verziókra, OPenWRT-vel ez valamiért nem gond...), akkor ahelyett, hogy downgrade-eltem volna az utolsó v6.x ROS-ra (v7-el nem boot-ol az OpenWRT) bepipáltam, hogy mindig a backup bootloader-t használja, ami ezeken v3.x

    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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz ratkaics #20505 üzenetére

    Milyen WiFi kell bele, AC, AX, 2-3 antennás...?
    Az 5 x Gb csati megvan pl. a hAP AC^3-on. Ez AC és 2x2, a WAN port PoE In, ami bridge-elhető LAN-ra (PoE out nincs). Vagy van AX^3 (AX 2x2).
    Ha csillió antenna kell, akkor RB4011iGS+5HacQ2HnD-IN, de ez "csak" AC, overkill AX-sokantenna úgy látom még nincs nekik.

    [ 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."

  • janos666

    nagyúr

    LOGOUT blog

    válasz ratkaics #20507 üzenetére

    Akkor szerintem használtan keresnék valami régi típust, amin már Gb-es LAN van, de "agyforraló" erősítős N-es WiFi.

    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."

  • janos666

    nagyúr

    LOGOUT blog

    Ez biztos nem érhető el minden SoC-al, de a bootloader-ben lehet állítani egyrészt energiagazdálkodási módot (pl. performance és powersave), illetve frekvenciát (fel is, le is, de nem tudom, hogy vannak-e ezek olyan okosak, hogy a frekivel együtt a feszültség is lemegy egy görbe szerint, hogy tényleg sokat számítson).
    "Buta WiFi AP"-nek alig kell CPU, de RAM újabban már sok. Router-nek, ami szoftveresen NAT-ol, gyors net mellé (főleg ilyen >=2.5Gbps) kell a CPU is, de nem tudom mostanában mikor működik a hardware-gyorsított NAT és mikor nem (a.k.a. "fast path" mikinél).

    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."

Új hozzászólás Aktív témák