Příspěvky

61

Sítě / Re:Nutnost delšího rozsahu pro IPv6 než /64

« kdy: 30. 01. 2024, 09:59:33 »

No a /64 si rozsekat nemůžu? ...

Nemuzes, protoze to nebude fungovat a to tak, ze vubec. Routery to neumi routovat a zarizeni si neumi pridelit IP.

Fakticky - může si to rozsekat na menší. Jakýkoliv slušnější router s routováním nemá problém. ALE nebude fungovat SLAAC, což je u řady věcí jediný způsob autokonfigrace koncových zařízení, tam to bez /64 nebude fungovat (a proto řada SOHO krabiček vůbec nevažuje o jiném, než /64 režimu). Pokud se to konfiguruje manálně vše nebo to umí plnohodnotný DHCPv6 (řada věcí neumí, není to povinné), tak maska může být libovolná.
Ale pokud chci mít jistotu, že vše bude fungovat, tak to /64 na LAN segment je  nutnost..

Ano, za toto bych někoho z O2 nechal hodně dlouho na dešti. Neumí to dokonce ani na bussines službách, takže na firemních sítích kde mám VLANy bych brečel.

Hele, tohle není primárně o O2/CETIN, ale neschopným jejich obchoďákovi. Naprosot normálně nám O2 dává na business linky na žádost /56 IPv6 na pobočky za nějaký drobný. Ano, jso kreténi, kde ti k 10 Gbps lince na optice po žádosti o /56 naúčtují 256x poplatek skoro dvě kila za každou /64, ale takové je třeba vyměnit. :-/
Jiná věc je ten SOHO segment, kde tlačí tu svoji /64 jako politiku, nejso jediní. Takže tam je lepší se poohlédno po jiném ISP.

62

Sítě / Re:Státní služby jen na IPv6 ze zahraničí

« kdy: 24. 01. 2024, 18:19:21 »

Hele, už stát přestal blokovat IPv6 přístup z IPček mimo Česko? Jednu dobu, co bylo dostupné po IPv6, tak něco z toho nešlo z tunelů od Hurricane. Aktivně to blokovali. Prý přes to vytěžovali data. :-)

63

Sítě / Re:O2 Optický internet a Mikrotik

« kdy: 24. 01. 2024, 18:17:27 »

Od pohledu, to interface=ether1 u PPPoE klienta je blbě. Vidím, že máš VLAN848 udělánu, tak to PPPoE strč až do ní (interface=vlan-848). Doufám, že ta VLAN je udělaná nad ether1.
A záleží pak na tom, jak má zbytek konfigurace, hlavně firewall a maěkarádu, budeš msuet z defultu upravit, že nneí WAN interface ether1, ale pppoe-out1.

64

Windows a jiné systémy / Re:Vzdálená plocha a deaktivace monitoru

« kdy: 17. 01. 2024, 20:24:17 »

NoMachine Desktop to umí také (volba EnableScreenBlanking=1).

65

Sítě / Re:Jak nastavit priority DSCP u switche MikroTik

« kdy: 17. 01. 2024, 17:49:00 »

Hele, Mikrotik dobastlit to HW QoS i pro řadu 3xx. Hm, ale chce to hodně aktuální ROS. To zatím pokoušet nebudu.
K tomu AES67, dle DOC má řada CRS3xx switchů podporu pro PTPv2?
Takže pokud to Dante používáš s PTPv2/AES67 a ne se starším PTPv1, tak možná switch by mohl GM poznat a reportovat ho. Zkusil bych na switchi zapout profil 802.1AE  a uvidíš, zda něco najde: https://help.mikrotik.com/docs/display/ROS/Precision+Time+Protocol

66

Sítě / Re:Jak nastavit priority DSCP u switche MikroTik

« kdy: 13. 01. 2024, 17:53:30 »

A jaký switch máš? Ono to tvrdě záleží od typu switch chipu, aby uměl prioritizaci provozu v HW. Jinak DSCP priorit je hromada, v tvé aplikci se používaj jen 4. Switche, co to umí, tak mají 8 výstupních front, dle DSCP se nastaví 802.1p priorita, dle té PCP priority se paket strčí do zvolené výstupní fronty a je nastaveno tvrdé pořadí odbavování dat z jednotlivých fron ven.
Já mám třeba switche řady CRS3xx, ty to neumí.
Viz: https://help.mikrotik.com/docs/display/ROS/QoS+with+Switch+Chip

67

Sítě / Re:Mesh Wi-Fi síť po domě

« kdy: 13. 01. 2024, 11:05:30 »

Ted jsem se na to dival a MESH se pouziva na propojeni zarizeni pomoci Wi-Fi
(kdyz nejsou kabely).

...

Kdyz rozdelili ty ovladace, daji se ted upgradovat pres CLI?

V Mikrotiku MESH funguje i na metalice. Můžeš ho použít i kombinovaně metalika/wireless. Např: máš tři routery zapojené do kruhu, pokud použiju bridge a xSTP, tak se posílá provoz dle STP stromu někdy zbytečně oklikou. Pokud použiju mesh, tak se posílá nejkratší cestou (v podstatě routing MAC adres, takový jednodušší TRILL). Ano, má to i slabiny, mesh proti bridge nemá L2 firewall, IVL, VLAN filtrace, ..., ale jde kombinovat mesh+bridge v určité míře.


Add ta aktualizace. IMHO jednoduše ne a je to tak schválně, protoře nedojde k přechodu konfigurace z wireless balíčki na wifi-... Takže leda tak, že z cmd uninstall wireless, reboot, fetch wifi-... balíček, reboot a máš upgrade wireless->wifi-..., ale musíš pak naskriptit novou cfg.

68

Sítě / Re:MAC address generator na MikroTik

« kdy: 12. 01. 2024, 18:17:14 »

Pokud chceš dodržet kostelní pořádek, tak pro náhodné lokální unicast MAC adresy je vyhrazena forma x2:xx:xx:xx:xx:xx  (x2=AAI segment=lokálně administrativně přiděleny). To x si tak můžeš nagenerovat náhodně jak chceš, ale pokud možno si neudělat v LAN konflikt. Jinak jsou unicast adresy (v nejvyšším bajtu mají 0. bit=0), multicast (v nejvyšším bajtu mají 0. bit=1) a broadcast (to je ff:ff:ff:ff:ff:ff). {Labužníci s Token ring by ještě vytáhli na scénu functional MAC adresy}
Jo, Y sudé je unicast adresa. Malá/velká písmena, pomlčky vs dvojtečky, to je jen forma zápisu.

69

Odkladiště / Re:Nové technické průkazy a QR

« kdy: 10. 01. 2024, 16:47:09 »

A radostne k budoucim zitrkum, mrknete se do portalu ovcana, pokud se vam tam chce lizt, na svuj technicak ... ono toho tam spousta vubec neni, treba povolene typy gum. Videl sem to u par lidi, a z jejich 8-15 ruznych, vypsanych na tom papirovem, se staly treba 2.

Už jsem viděl někde nářky, že už teď z STK stihli pár lidí vyhodit, protože na autě byly gumy, co v elektronickém techničáku nejsou uvedeny, ale v papírovém byly. :-(

70

Studium a uplatnění / Re:OSVČ jak vybrat právníka a pojištění

« kdy: 10. 01. 2024, 16:38:14 »

Není to megablábol, jen to greenlinux možná trochu popletl. To, že otrokáři podepisuji normalizovanou smlouvu o znění jako jako všichni ostatní, tak se střílím do vlastní nohy v bodě, že plním některou z podmínek Švarcu.
Co uváděl green, tak je "slabší strana smlouvy", té náleží určitá forma ochrany a posuzuje se vždy individuálně. V případě OSVČ versus prodejce duší, tak pokud je mým oborem podníkání psaní SW a uzavři smlouvu o svém přeprodeji agentuře, která provádí bodyshoping, tak budu vnímán jako slabší strana, protože jednám mimo svůj hlavní podnikateský obor a budu pravděpodobně i ekonomicky slabší strana. Pokud bych byl já expert na prodej lidí a jako OSVČ se budu nabízet jako podotrok pro ně shánět další lidi, tak už to může být naopak, jednám z pztice experta v oboru. Proti bude pozice ekonomick silnějšího protejěku, což se také počítá a v takévém případě obvykle vyrovná.
Jinak viz §433 OZ.

71

Sítě / Re:MikroTik: sdílení tiskárny napříč VLAN

« kdy: 07. 01. 2024, 22:42:26 »

Tak jsem si s tím chvilku hrál. Android pro vyhledávání používá asi jen mDNS (224.0.0.251:5353) a ne UPnP/SSDP (239.255.255.250:1900). Takže blbnutí s routingem multicastu nemá smysl a musí se použít něco výše, co bude mDNS přehazovat řízeně.
Do Mikrotiku je k mání konteiner s mdns-repeater. Viz: https://forum.mikrotik.com/viewtopic.php?p=988215

72

Sítě / Re:MikroTik: sdílení tiskárny napříč VLAN

« kdy: 07. 01. 2024, 11:52:39 »

Ne, PIM opravdu nemá smysl. Ten přichází v úvahu, kdy mám víc routerů, smyčky, ...
Tady by se hodil ekvivalent toho smcroute, který v ROSu není. Pokud se použije novější verze smcroue. Staré byly nepříjemné v tom, že se muselo konfigruvoat [(zdrojová IP adresa, mcast adresa), in_iface->out_ifaces], takže pokud má v těch dvou VLANách masku /24, tak cca 500 záznamů. V nových už jde napsat s maskou a je to na 2 záznamy. Jinak první došlý mcast paket udělá smyčku a pak jen power off (to bylo při konfiguraci [(*, mcast adresa),  in_iface->out_ifaces]). Ale tady půjde i o to, zda ten multicast socket na routeru má nastaveno, že přijme zpět loopbackově to, co sám vyšle.
Ta IGMP proxina je ohejbák, umí předávat multicast jen z jednoho iface (který je definován jako upstream) na X dalších. Jakmile by bylo zadání, že mám vlan_dmz0 s tiskárnou a vlan_lan + vlan_guest, tak už smůla. Respektive v tom případě by jako upstrem musela být ta vlan_dmz0 a doufat, že tiskárna dost často sama posílá advertise, aby ji klienti uviděli. Ale bude to celé o tom, zda klient nebo tiskárna akceptuje, když zdrojová adresa multicastu leží mimo lokální LAN segment. Mám doma Brothera a dle pokusu, tak naprosto ignoruje, pokud neopovídá zdrojová adresa lokální LAN (odpovídá jen na search z AutoIP 169.254... a lokální LAN segment).

73

Sítě / Re:MikroTik: sdílení tiskárny napříč VLAN

« kdy: 06. 01. 2024, 20:44:21 »

Pokud daná tiskárna je ochotna odpovídat na vzdálené UPnP SEARCH dotazy (ne každé zařízení přijme multicast, kde zdrojová adresa nepatří do lokálního segmentu), tak za pokus stojí použití IGMP proxy v Mikrotiku (PIM-SM je trošku overkill). Potřebujeme multicast propasovat od mobilů směrem k tiskárně, tiskárna by měla odpovídat již unicastově:
/routing igmp-proxy interface
add interface=host_vlan upstream=yes
add interface=fix_vlan
Po tomto bych měl pomocí torchu vidět, že na fix_vlan se objeví UDP 239.255.255.250:1900 a zdrojová IP od mobilu. Taktéž v přehledu té igmp-proxy by mělo být vidět, že chytgá pakety na host-vlan a jako downstream je posílá na fix_vlan.

74

Studium a uplatnění / Re:OSVČ jak vybrat právníka a pojištění

« kdy: 06. 01. 2024, 20:32:39 »

Tazatel chce pro otrokáře pracovat jako OSVČ a ne zaměstnanec, tam pro Zákaz Konkurence/Konkurenční doložku (dva různé instituty) jsou trochu jiná pravidla. Viz: https://dostupnyadvokat.cz/blog/konkurencni-dolozka-v-obchodnich-vztazich

75

Sítě / Re:VPN - detekce zda jsem doma nebo ne

« kdy: 02. 01. 2024, 17:31:28 »

Hm, tohle řešilo MobileIP (MIP). Otázka je, zda existuje dneska nějaká rozumně funkční implementace pro home agenta/mobilní nód? Kdysi dávno jsme to používali (v době Symbianových Nokií). Pokud mobil nebyl přímo v síti, kde měl svého home agenta, tak nahodil tunel s vnořeným IPsec spojením domů a v lokální síti byl pořad dostupný/vystupoval pod stejnou IP, ať cestoval nebo byl na domácí wifi.
Ale tak rozhládnutím to vypadá, že tato oblast je mrtvá. :-(