Lehet, hogy az a módszer, ahogy az ismerősöd beállította jó lenne, csak pl egy "delay"-t be kell iktatni, ami idő alatt biztosan feléled a szolgáltatói eszköz (nálam kábelmodem 3 perc alatt mindig feléled), mielőtt levágja a mobilnetet.
Nekem erre volt valamikor egy szkriptem, de az egy kicsit túl lett bonyolítva, viszont ez érdekes lehet neked:
[link]
A fő interneted hogy kapcsolódik a routerre? Sima DHCP kliens vagy PPPoE? A Webstick LTE módban van vagy PPP?

A TV távirányítóval van kikapcsolva, vagy az áramot lelövitek a hosszabbíton és akkor jön elő a gond?

Le az elipszilonos jével, éljen a "j" !!!

Van egy-két Wireshark-al "kimentett" forgalom a problémás időszakról, ha érdekes lehet, akkor szívesen felteszem valahova tanulmányozás céljából.
Maga a BACnet protokol több szinten is definiált.
De nekem "simán" jó lenne az is, ha IP tartomány alapján tudnám korlátozni a bejövő csomagok rátáját.
Esetleg, amíg megérkezik a készülék, addig is tudnátok egy hasonló, vagy ilyen korlátozásra példát mutatni nekem?
Van Mikrotik routerem, de szinte mindent leírások alapján állítottam be rajta. Szóval jól jönne egy kis segítség!

Olyan nincs, hogy valami nem sörnyitó ....

A router szünetmentes tápról megy, a TV nyilván nem. Ez nem lehet az ok.

Most úgy működik, hogy ha megszűnik a vezetékes net akkor azonnal átkapcsol mobilra. Észre sem lehet venni. De ha bekapcsolódik a modem akkor a mobilról azonnal leválik de amíg a modem fel nem épül addig a router sem ad internetet. Ez kb. 3 perc valóban. Ezt még el lehet viselni, de az már nem OK amikor a központba is áramszünet van és akármeddig nincs internet de a modem él (csak folyamatosan újra indítja magát) de ilyenkor nem kapcsol át mobil netre. Ekkor kell kihúzni a kábelt. (vagy kéne egy kábel ki-be dugó bot?!)

A fő interneted hogy kapcsolódik a routerre? Sima DHCP kliens vagy PPPoE? A Webstick LTE módban van vagy PPP?

Lőttem képet a Winboxból. Ezt találtam. (nem ismerem ki magam jól ebben) Hátha ebből kiderül.

A TV távirányítóval van kikapcsolva, vagy az áramot lelövitek a hosszabbíton és akkor jön elő a gond?

Sima távirányítós kikapcsolásnál jelentkezik.

Létezik esetleg olyan Mikrotik router, amitm tudja azt amit nekem kell és C sínre rögzíthető?

Olyan nincs, hogy valami nem sörnyitó ....

szerintem egyetlen Mikrotik eszköz sincs, ami sínre rögzíthető, de azért pörgesd végig a katalógust

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Gondolom nem online a szunetmentesed, hanem line interactive, igy a zavarok nem elhanyagolhato reszet atengedi. Probald ki, hogy kihuzod a szunetmentes bemenetet es ugy mi tortenik.

[ Szerkesztve ]

A kisebb mikrotik routereknek vannak meretrajzai, thingiverse-n parhoz van 3d nyomtathato sinre pattinthato haz es-vagy rogzitoelem: [link]

[ Szerkesztve ]

Tégy egy próbát! Tedd át Create Enabled-re, ekkor static inteface-ek lesznek amiknél beállíthatsz statikus nevet az interface-nek plusz a többi beállítást. (Kis számú AP-nél nem lesz kényelmetlen) Ekkor ha az interface nem él akkor is ott van a listában, és nem lesznek gondok azokkal a szabályokkal ahol az interface-re hivatkozol. Én kis hálózatoknál így használom.

Minden másra ott a gyorskötöző

Kössünk egyezséget, megegyezős egyezséget... https://www.paypal.me/engiman/30

Olyan nincs, hogy valami nem sörnyitó ....

Ok!

Olyan nincs, hogy valami nem sörnyitó ....

Most kipróbáltam kihúzott táp mellett, sajnos a helyzet nem változott! Rejtély!

Nem gond, akkor mar tudjuk, hogy ez egy radiofrekvencias interferencia lesz.

Ez ellen arnyekolassal erdemes megprobalkozni, de nem lesz egyszeru menet.

[ Szerkesztve ]

Kérnék egy kis segítséget az alábbi problémával kapcsolatban. Van egy konténerem(nginx) amit szeretnék kívülről a router DDNS címével elérni.
Ha jól sejtem akkor kelleni fog egy port forward illetve egy/több tűzfal szabály.
Ez lenne az általam használt port forward:
4 X ;;; nginx http
chain=dstnat action=dst-nat to-addresses=192.168.1.50 to-ports=80
protocol=tcp dst-address-list=Erd DDNS address dst-port=80 log=yes
log-prefix="nginx_http"
Illetve a tűzfal szabály.
Filter Rules
7 X chain=input action=accept protocol=tcp dst-address-list=Erd DDNS address
dst-port=80 log=no log-prefix=""

Illetve van még két ilyen szabály a lista végén:
17 chain=input action=drop in-interface=pppoe-digi log=no
log-prefix="input_drop"
18 chain=forward action=drop in-interface=pppoe-digi log=no
log-prefix="forward_drop"

Ha csak a port forwardot és az input szabályt állítom be akkor nem érhető el a konténer viszont ha az utolsó forward drop szabályt kikapcsolom akkor igen.
Gondolom még szükség lenne valami szabályra a forward chainben, hogy működjön csak nem tudom mire.
Tudnátok segíteni? Illetve ha valamelyik már meglévő szabály nem jó/nem megfelelő akkor kérlek jelezzétek.
Köszönöm

Hello darkness, my old friend...

Hali!

A filter-ben WAN port felől csinálj egy forward szabályt, ami engedélyezi a forgalmat a nginx-es belső IP felé. HA nagyon paranoiás vagy, akkor hasonlóan a dstnat szabályodhoz limitáld mit engedsz be (port), ha kevésbé, akkor elég a dstnat-nál kikötni
Ja, és ne felejtsd el engedélyezni a szabályokat, itt a példában ki van kapcsolva (bár gondolom szándékosan).

Az input szabály pedig nem kell, hisz nem a router-re engedélyezed. A dst-address-list-nél amúgy mi ez a "Erd DDNS address" az address-list-nél?

[ Szerkesztve ]

üdv, adika4444

Köszi szépen a segítséget kipróbálom majd a dolgot.
A dst-address-listnél abban a router DDNS címe van benne. Az egyik leírásnál amit találtam abban használta így(igaz ott ő a publikus IP címét használta ami nálam ugye változik így beraktam így az address-listbe)

Hello darkness, my old friend...

Ezt már én is kerestem, de sajna nem találtam :-(
Sajnos, csak fabrikálós, barkácsolós megoldásokat tudok

[ Szerkesztve ]

Jó pofának tűnik.
Már csak nyomtatni kéne

Hát eleve van maga a BacNet, majd azon belül
- BacNet Ms/Tp
- BacNet Ethernet
- BacNet IP

Most nézem csak. Létezik BacNet PTP és BacNet Arcnet is.
Nem is tudtam 😁
Soha nem találkoztam velük a gyakorlati életben.

A Bacnet PTP már láttam, de az Arcnet-et még én sem.

Olyan nincs, hogy valami nem sörnyitó ....

Tehát akkor ha jól értem ezekre a szabályokra lenne szükségem?
Filter:
7 X chain=forward action=accept protocol=tcp dst-address=192.168.1.50
in-interface=pppoe-digi dst-port=80 log=yes
log-prefix="nginx_http_forward"
8 X chain=forward action=accept protocol=tcp dst-address=192.168.1.50
in-interface=pppoe-digi dst-port=443 log=yes
log-prefix="nginx_https_forward"

NAT:
4 X ;;; nginx http
chain=dstnat action=dst-nat to-addresses=192.168.1.50 to-ports=80
protocol=tcp dst-port=80 log=yes log-prefix="nginx_http"
5 X ;;; nginx_https
chain=dstnat action=dst-nat to-addresses=192.168.1.50 to-ports=443
protocol=tcp dst-port=443 log=yes log-prefix="nginx_https"

Köszi!

Hello darkness, my old friend...

Igen, de majd a logot vedd ki belole, mert csomagonkent fog egy bejegyzest letrehozni.

Köszi szépen. Igen azt majd kikapcsolom, igazából teszt jelleggel volt benne.
Illetve egy kérdés, hogy jobban értsem a dolgot. Amikor használtam a dst-address-list-et amiben a router WAN ipje volt akkor nem ment a dolog. A mostani konfiggal ahol a dst-address egy konténer ipje úgy meg már megy. Oké más volt a chain, de azon kívül volt még valami gond a dst-address-list dologgal vagy teljesen rosszul használtam/értelmeztem.

Hello darkness, my old friend...

Azert van, mert a forward tabla a nat utan jon, tehat mire oda eljut a csomag mar le van cserelve az interneten levo publikus ipcim a halozatodon beluli gep cimere, ahova tovabb kell kuldeni.

A NAT tablaban levo dst-nat szabaly csereli le az cimet.

[ Szerkesztve ]

Köszi szépen így már világos.

Hello darkness, my old friend...

Most így nagy átlagban hogy áll a 7.x?
Van már olyan stabil mint a 6.x vége?

Szerintem az, hogy párhuzamosan fejlesztik a két rendszert, kb. mindent elmond. Ha a 7-es minden tekintetben jobb lenne, akkor egyrészt mindenki azt használná, másrészt a Mikrotik meg leállna a 6-os folytatásával, és csak a 7-est fejlesztenék a továbbiakban.

[ Szerkesztve ]

Igen, tul sok eroforrast visz el a 6-os. Viszont meg a 7-es nem stabil annyira, hogy at lehessen kenyszeriteni a 7-esre a felhasznalokat. 7-esbol meg long term support sincs.

[ Szerkesztve ]

Otthoni használatra van olyan stabil, de ha valaki komplex hálózatott tart fenn mindenféle fejlett routing protokolokkal, esetleg még szolgáltató is, inkább jobb ha tolja tovább a ROS6-on.

Le az elipszilonos jével, éljen a "j" !!!

RB5009, most írtad. Én hAP AC3-ról írtam.

Amiből lekvárt lehet főzni abból pálinkát is! A csavargó embert nem lehet munkára fogni! Samsung S23 Ultra Dual SIM | Notebook: HP Omen | Car: Volkswagen Passat B6 1.9 PD TDi BLS

Abból is van 3-4 a környezetemben, mind 7-es ROS-al. Semmi gond velük.

CAPs MANAGER mind a 3-4?

Amiből lekvárt lehet főzni abból pálinkát is! A csavargó embert nem lehet munkára fogni! Samsung S23 Ultra Dual SIM | Notebook: HP Omen | Car: Volkswagen Passat B6 1.9 PD TDi BLS

Ezek nem. De az RB5009 igen. Mindegy, csak arra akartam célozni, ha akarnék sem tudnék visszamenni 6-os ROS-ra. Most a 7.2.2 megszívatott, a caps managert hazavágta. 7.2.3 megint ok.

Nekem CAPsMAN az AC3, FB csoportba még mindig van akinek van memory leak. Fura ez nekem, ezért is várok. Stabil a rendszer, így inkább nem variálok, nincs kedvem előtte rostokolni egy up majd ha rossz akkor egy downgrade-re.

Amiből lekvárt lehet főzni abból pálinkát is! A csavargó embert nem lehet munkára fogni! Samsung S23 Ultra Dual SIM | Notebook: HP Omen | Car: Volkswagen Passat B6 1.9 PD TDi BLS

Szia.
A “long-term support” valami speciális dolgot jelent?

(Eszközön kiválasztható a long-trm release, jelenleg 7.1.5.)

NaBaMeg Új ROS7 béta első sora:
What's new in 7.3beta40 (2022-May-11 12:18):

!) queue - do not allow using CAKE type in simple and tree setups (already configured queues will be disabled);

Kellett nekem akadékoskodni a supportnál

Le az elipszilonos jével, éljen a "j" !!!

Még ros6-n vagyok (najó cap lite az ros7), de hap ac3 még ros6.
FB csoportokban milyen gondokat említenek hap ac3-nál ros7-nél?
CapsMan nincs nálam. az nem lenne gond.

Érdekelne engem is mert vennék 3 db ac3-at. De ha nem jó akkor nem tudom mi legyen helyette?

Nem a hap ac3-val van gondom, csak az új szoftver, amire még nem frissítettem.
Nálam sima felhasználás van, plusz beüzemelném wireguard és wifiwave2-t, ha nincs memory leak és fagyás ros7 alatt.

A memory leak úgy tűnik hogy a capsmannel van összefüggésben, ha wifiwave2-t tervezel használni, akkor a capsman eleve ki van lőve

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Mas a release policy. Ritkabban jonnek ki verziok es egy x.y verzion belul csak a fontos javitasokat/frissiteseket rakjak bele, az uj featureket nem. [link]

[ Szerkesztve ]

Köszi, ez megvan.
A support szó jelenlétét nem értettem. Pl. más csapat foglalkozik vele és ők még a 6ost csinálják, vagy valami ilyesmi?

Mikrotikkal nem régóta foglalkozom és csak hobbiból, otthon.

[ Szerkesztve ]

Sziasztok,

Segítséget szeretnék kérni tőletek nordVPN beállításával kapcsolatban:
A beállításokat megcsináltam a következő leírás szerint:
MikroTik IKEv2 setup with NordVPN
7-es ponton annyit változtattam:
/ip firewall address-list
add address=192.64.15.0/24 list=NordVPN

/ip ipsec mode-config
set [ find name=NordVPN ] src-address-list=NordVPN

A routerem hap ac2, router os verzió: 6.49.6 (stable)
A problémám az, hogy bár működik de eszméletlen lassú, percekig tölt egy google kereső is.
Rákeresve a témára azt írták, hogy kapcsoljam ki a fasttrack-et, de így sem az igazi, bár javul a helyzet.
1000mbit/sec-es netből vpn nélkül átlagosan 900, router vpn-nélkül csak böngészős vpn plugginal 600-700, routeren fasttrack kikapcsolásával 100mbit körül. Tudnátok segíteni benne szájba rágós leírással, hogy milyen szabályt kellene még hozzá adnom ami javíthat ezen a sebességen? Kezdő vagyok, kíméljetek

[ Szerkesztve ]

Capsman és Ros6 van tervbe véve. Még nem frissítenék fel úgy sem.

Ha a NordVPN-t kb 100Mbit/s sebességgel tudod a routeren keresztül használni, az lehet, hogy kb reális.
Egy mai PC sokkal erősebb hardveresen, mint egy router, ezért a routertől közel sem várható ugyanaz a sebesség.

Ugyanakkor a fasttrack-nak nem tudom mi köze van ehhez az egészhez,
a router a net felé használhatja szerintem, csak a VPN felé nem. De majd nálam jobban hozzáértők talán megmondják az okokat.

Ha mégis a routeren szeretnéd a VPN-t használni, akkor egy erősebb routerrel, valószínűleg nagyobb sebességet tudnál elérni. A hAPac^2 hardvere kb elegendő a gigabites nethez, de nincs benne túl sok tartalék, azon kívül az alkalmazott titkosítás függvénye is, hogy mekkora processzor teljesítmény kell a VPN használatakor.