Příspěvky

1

Sítě / Re:Vodafone (exUPC) vs. PODA (GPON) Internet

« kdy: 15. 04. 2025, 11:27:06 »

To bude možná tím, že vlastní ONT u PODA prakticky nikdo nemá a tudíž to ani PODA zatím nijak neřeší. Ale pokud by takových userů přibývalo, tak sotva bude PODA všem přidělovat /30 (4x IPv4), když jich má sama nedostatek. Neboli bych rozhodně nesázel na to, že když teď má někdo s vlastním ONT k dispozici 4x IPv4, tak mu to vydrží navěky věků. Ostatně i ve smlouvě se garantuje IPv4 jedna jediná.

Ale oni musia pridelovat /30 z technickych dovodov; (to neznamena, ze moze pouzivat vsetky 4: jedna padne na adresu siete, jedna na gateway na strane isp, jedna na router zakaznika, jedna broadcast). Niektore routery zvladaju /31 (rfc 3021, predpoklada sa point to point, stacia dve adresy, jedna pre router zakaznika, druha pre gateway na strane ISP), ale tipoval by som, ze infrastruktura na strane poda nie. Ak by chceli ist na 1 IP adresu na zakaznika, tak im zostava NAT 1:1, alebo kulehy so zdielanim rovnakej IP na rozlicnych interfaces, (ktore boli tu na roote popisane).

2

Desktop / Re:Náhrada Skype pro Linux

« kdy: 08. 04. 2025, 15:28:05 »

Upoutal mě Jitsi Meet. 
https://flathub.org/apps/org.jitsi.jitsi-meet
Vypadá pěkně a video kvalita zatím nejlepší.
Taky to je systém primárně na video hovory. Chat chybí. Kontakty taky. Škoda. Je to takový open source Zoom.
Naplánujete si video meeting, vygenerujete kód meetingu a ten pošlete tomu s kým chcete mluvit.
Fungu je to, ale náhrada Skype to není.

Vo firme mame rozchodny self-hosted jitsi meet spolu so zulipom. Jitsi je na video/audio, zulip na chat (taky open source Slack). V zulipe sa da jednym klikom v chate vygenerovat linka na adhoc meeting v jitsi a prijemcovia si na nu len kliknu. Obe su za SSO, takze neotravuje s dalsim loginom (ale desktopovy jitsi meet ma problem, nevie spravne handlovat jwt tokeny od OIDC SSO. Desktopovy klient na linuxe dlhu dobu bezal na historickom electrone, takze dlho nevedel hidp a aj zdielanie obrazovky pod waylandom je novinka v 2025.2. Browserovi a mobilni klienti su ok).

Minusom je rozchodit to, nie je to uplne jednoduche a treba sa o to starat. Je jednoduchsie zaplatit za teams.

Pre normalnych domacich userov s linuxom sa mi najviac pozdava telegram. Je to nativna aplikacia v qt, ziadny pochybny home-made electron wrapper ako teams-for-linux, oficialne podporovana a so 100% funkcnostou na linuxe (na rozdiel od whatsapp), nikto s tym nemal problem, ze by nieco nefungovalo. Jedina vytka bola, ze nema normalne skupinove hovory, ktore by ostatnym ucastnikom zvonili, ale v skupine musi vlastnik skupiny vytvorit hovor a ostatni sa musia pripojit (v podstate ako teams).

3

Sítě / Re:MikroTik mDNS: nefunguje video napříč VLAN

« kdy: 23. 02. 2025, 20:02:53 »

Caute chlapy,
sorry, ze zase ozivujem tuto temu, ale asi nie je vhodne stale zakladat nove temy, ked tak nech ma moderatori upozornia a zalozim novu. Stale mam problem s tlaciarnou (tiskarnou) a myslim si, ze problem bude vo firewalle, ale neviem kde, takze sem vyprintujem cely filter.
Situacia sa v podstate dotyka styroch vlan:
...

V akych interface listoch su jednotlive vlany? A ostatne interfejsy?

Inak v pripade mikrotiku odporucam exportovat nastavenie cez terminal; /interface/list/export a /ip/firewall/filter/export. Alebo pre cely config /export. Pre RouterOS < 7 pridat hide-sensitive=yes.

4

Sítě / Re:Více než /64 IPv6 adres u O2

« kdy: 18. 02. 2025, 13:36:55 »

A pokud si to trochu sumarizuju, tak v podstatě pár relevantních technických obtíží spočívá v podpoře DHCPv6-PD a to jak u ISP, kde by to museli na mobilních sítích implementovat (to by pravděpodobně neslo i určité další náklady včetně souběhu s bezstavovým SLAAC pro hromady "legacy" zařízení), tak na straně některých platforem (jestli se nepletu, tak třeba Android tohle pořád neumí).

Pozor, DHCP-v6 a DHCP-PD su dve rozlicne veci! Je uplne v poriadku mat v sieti SLAAC a DHCP-PD; PD je "prefix delegation", nim si zariadenie pyta dalsie prefixy pre siete, do ktorych routuje (to by sa Androidu potencioalne tykalo len pri tetheringu). DHCP-v6 resp SLAAC je pre priradenie adresy samotnemu zariadeniu.

Zaroven SLAAC nie je legacy a DHCP-v6 nie je new hotness. SLAAC je plne dostacujuci a DHCP-v6 je len pre tych, co nepochopili IPv6 a prenasaju svoje navyky z IPv4 ;-).

5

Software / Re:max.com na Linuxu nejede ve FullHD

« kdy: 11. 02. 2025, 22:01:05 »

Nemá zmysel toto riešiť, nejde ti to viac ako 720p, lebo na druhej strane ti viacej nepustia.

Tá zázračná akceleračná technológia vo Windows sa nazýva obchodná dohoda, keď sa Microsoft dohodol s poskytovateľmi obsahu, že to takto bude. Ani Chrome nepustia viac ako 1080p, 4K, nebodaj HDR obsah na počítači býva len pre Edge + Windows DRM.

Ja fakt nechápem, prečo za toto platíte. Keď vám vendor povie, že Linux je nepodporovaná platforma pre ich streaming, treba mu povedať naspäť, že ich služba je teda nepodporovaná vašou peňaženkou. Keď sa vás nájde dostatočný počet, vtedy pochopia a začne to fungovať. Keď nie a potrebujete latest shiny, tak nie.

6

Sítě / Re:Nastavení a ověření DoH DNS na MikroTiku

« kdy: 11. 02. 2025, 13:32:33 »

No ako sledujem tu debatu, tak sa asi vykaslem na Mikrotik DNS a rozbeham radsej pihole pod proxmox. BTW: Preco by ste preferovali DoT pred DoH?

Pihole nevie ani DoT, ani DoH. Na to potrebuje bud proxy, ako je stubby, alebo rovno cely resolver, ako je unboud. Takze pokial nejde o filtrovanie, pihole straca vyznam.

7

Sítě / Re:Nastavení a ověření DoH DNS na MikroTiku

« kdy: 10. 02. 2025, 22:31:51 »

- Po takto nastavenom DNS som cez sniffer zistil, ze na WAN rozhrani cez port 53 UDP prebieha komunikacia medzi branou od mojho ISP a DNS servermi Google (8.8.8.. Vobec nerozumiem na zaklade coho sa tam objavuju DNS Google pretoze v DNS nastaveniach ani v DHCP nemam servery Google.

Urcite je to z portu WAN, alebo je to forwardnute zvnutra? Nemas v sieti Chromecast alebo nejake ine embedded zariadenie, ktore zvysoka kasle na to, co hovori DHCP a pouzije well-known resolver lebo chce?

8

Sítě / Re:MikroTik mDNS: nefunguje video napříč VLAN

« kdy: 06. 02. 2025, 16:18:42 »

Ahojte, dodatocne som zistil, ze mam problem s tlaciarnou (tiskarnou) HP M377dw, ktora je v IoT VLAN:
1. Po nejakom case prestane byt pristupna na webe cez hostname.local aj ked cez ip je web pristupny. Tlaciaren tiez po nejakom case presta byt automaticky objavitelna v ramci novych "instalacii", ale na zariadeniach na ktorych uz je "nainstalovana prostrednictvom mDNS"  reaguje v poriadku na tlacove / scan ulohy aj ked je nefunkcny web.

2. Tlaciaren nie je mozne vyhladat na zariadeniach v hostovskej VLANe.

Suvisiace pravidla: ip -> firewall -> filter:

Kód: [Vybrat]

13    chain=forward action=accept in-interface=fix_vlan out-interface=all-vlan log=no log-prefix=""
19    ;;; Tlac_Host
      chain=forward action=accept dst-address-list=tlaciaren log=no log-prefix=""
23    chain=forward action=drop src-address-list=!fix_ip in-interface=fix_vlan log=no log-prefix=""
28    chain=forward action=drop in-interface=veci_vlan out-interface=fix_vlan log=no log-prefix=""
 chain=forward action=drop log=no log-prefix=""
Pravidlo 19 nespracovalo ziadne pakety, tlaciaren nema povolenu ziadnu komunikaciu do domacej siete (fix_vlan).

Na akych zariadeniach to nie je mozne resolvovat? Android, Mac/iOS, Windows 10, 11?

Obzvlast Windows 10 je jeden velky bordel, kazda jedna verzia (22H2, 1903, atd) je ina, na starsie verzie bolo treba instalovat Apple Bonjour, na novsie uz nie.

Tlaciarni staci established,related. Na tlaciaren treba 631 pre ipp a cokolvek je nastavene ako web port. Na tlaciarni si treba spontrolovat povolene protokoly, aj discovery (HP vie aj vyssie spominany WS-Discovery, tak ci sa Windows nesnazi o to).

9

Sítě / Re:MikroTik mDNS: nefunguje video napříč VLAN

« kdy: 03. 02. 2025, 01:22:07 »

Musim si nastudovat ako zmonitorovat komunikaciu. Ked som to pravidlo prepisal len na established, related tak sa obnovil predchadzajuci nefunkcny stav.

Vyssie som uviedol linku, kde Google dokumentuje, co potrebuje mat otvorene:

• k pouzivanemu DNS serveru 53/udp, 53/tcp
• do internetu https: 443/tcp, 443/udp a rtm: 19305/tcp, 19305/udp
• inbound googlecast: 8008-8009/tcp
• inboud: 1-65535/udp
• outboud: 1-65535/udp
• outbound tcp: established, related

Pre VLC sa k tomu pridava nasledovne (VLC si vytvori server, a posle receiveru linku na seba; receiver si teda taha data od pocitaca, na ktorom bezi VLC):

• outbound http 8010/tcp (default, da sa zmenit v nastaveniach, zobrazit vsetko, vystup streamu, sout stream, chromecast, port http)
• outbound 32768-61000/udp (t.j. uspokoji sa s mensim rozsahom, ako normalny cast)

Na pocitaci ak ma lokalny firewall to treba otvorit tiez.

10

Sítě / Re:MikroTik mDNS: nefunguje video napříč VLAN

« kdy: 01. 02. 2025, 22:24:42 »

Caute, viem, ze na tomto fore sa velmi neriesia taketo "home" temy, ale skusim to. Konecne som sa dokopal k pokusu rozbehat MDNS na Mikrotiku, Funguje to tak napolovicu, strucne napisat co som urobil:

OK

- Na Mikrotiku som povolil port 5353 z predmetnych VLAN do inputu a v IP - DNS som povolil MDNS na predmetnych VLANach

Dobry krok, len si treba uvedomit, ze mDNS je len discovery. Tu jednotlivi klienti len ziskaju informaciu, na akej ip, akom porte bezi dana sluzba. Este musia mat moznost sa na nu aj pripojit.

- Na TP-Link smart switch som povolil IGMP

Naco presne? IGMP pouziva multicast, ale nie vsetok multicast je IGMP. Pouzivas nejaky zdroj videa z multicastu (IPTV)? To je vtedy tiez trocha zlozitejsie, nez len povolit IGMP. Na mDNS IGMP nepotrebujes.

- Na Ubiquiti AP som povolil multicast v predmetnych VLANach

OK.

Vysledok:
- Tlaciaren je pristupna napriec VLANami v poriadku

Tak zjavne port 631 (ipp) ma prestup medzi VLAN.

- Mirroring Chrome prehliadaca funguje, s vinimkou prehravania videa na webe, ale to bude asi problem iba niektorych webovych prehravacov

Chromecast (aj ten v TV) potrebuje mat pristup na Internet. Pri castovani tabu z prehliadaca ide stream z pocitaca, ale pri castovani video streamu taha renderer stream priamo zo zdroja. (Preto je mozne pocitac/telefon/whatever vypnut a castovanie pokracuje).

Poziadavky na siet pre renderer (receiver): https://support.google.com/chrome/a/answer/12256492?hl=en

- Vobec nefunguje mirroring videa (cast) priamo cez Windows resp. Windows nevidi TV, v inej VLANe, ako cast zariadenie.

To preto, ze Windows nepouziva mDNS, kedze je to "konkurencna" technologia. Windows pouziva SSDP alebo WS-Discovery, podla toho, aky stary je prislusny komponent, co robi discovery. Mikrotik toto neriesi.

- VLC (na rovnakom Windowse) cez funkciu Render danu TV vidi, pokusi sa video aj prehrat (na TV sa zobrazi prehravac s nazvom videa, ale prehravanie na TV sa nespusti.

VLC tlaci stream cez port 8010. Ma prestup?

Testoval som to aj na inom Windows zariadeni a problemy su rovnake (Linux som neskusal). Len podotknem, ze v jednom pripade islo o TV a PC, ktore su do switchu zapojene cez kabel a v druhom pripade islo o NTB (wifi) a TV (kabel).

OK

Ma niekto tipy na mozne riesenie? THX

Tip: Wifi nema rada multicast -- pretoze tam nie je ack. Nemoze teda vediet, ci bol multicast packet doruceny alebo nie. Preto pri multicaste spomaluje na co najnizsi link rate a zvycajne aj dole na 802.11b. Pri discovery packetoch sa to da prezit, tych nie je vela, ale streaming cez multicast a wifi nie je to prave orechove. Prave preto existuju nastroje ako udpxy, ktore prevedu multicast na unicast.

11

Hardware / Re:Vícenásobný passthrough hardwaru (GPU)

« kdy: 29. 01. 2025, 11:33:52 »

Vite nekdo jak je to s pristupem k GPU(pres CUDA) z LXC kontejneru?
Diky.

CUDA z LXC je jednoduchá, pretože je to len kontajner. Takže na hostovi treba mať kernel driver, bind mountnúť všetky `/dev/nv*` do kontajnera.

12

Hardware / Re:Vícenásobný passthrough hardwaru (GPU)

« kdy: 29. 01. 2025, 11:19:13 »

A sitovka skrze SR-IOV bude mit ruznou mac v ruznych VM?
Takze je to vlastne neco jako "hw switch" zdarma (ve srovnani s klasicky resenim hw nic - sw bridge - virt nic ) ?

Áno. A nielen mac, ale jednotliví guesti môžu byť aj v rozličných VLAN. Na fyzický port môže ísť trunk a jednotlivé VM dostanú access pre im patriace VLAN.

13

Hardware / Re:Vícenásobný passthrough hardwaru (GPU)

« kdy: 29. 01. 2025, 10:34:34 »

Na fyzickém HW který má jednu grafickou kartu(konkrétně iGPU) . Je možné při virtualizaci  dosáhnout toho, aby více běžících systému mělo přístup k GPU (a tedy vyššímu výkonu)? současně. Například proxmox. pokud ano, kolik je limit, nebo co určuje limit ( plnost grafické VRAM)

Záleží od toho, o akú iGPU ide. Intel 12-14th gen zvláda (nepíšem podporuje, kvôli stavu, v akom to je) SR-IOV, kde je možné vytvoriť virtuálnu funkciu a túto sprístupniť vovnútri VM. Je to pomerne tŕnistá cesta, treba vlastný modul na hostovi aj guestoch, Intel to len pomaly upstreamuje, zjavne to nie je priorita: https://github.com/strongtz/i915-sriov-dkms

Karty s diskrétnymi GPU v consumer segment (vrátane Intel Arc) toto nevedia, úmyselne. Je to vyhradené pre drahšie modely.

-Když to zobecním, i k jinému HW, třeba USB, nebo NPU? (Jak je to řešeno, musí být na to v host os nějaký dríver nebo přímo podpora v HW)
-liší se to model od modelu? (jak tento parametr je nazvaný)?

Podpora SR-IOV je častá pri lepších sieťových adaptéroch. V podstate to môže implementovať každé PCIe zariadenie, akurát väčšina to nerobí.

14

Windows a jiné systémy / Re:Koupě levných Windows 11 a legalita

« kdy: 25. 01. 2025, 18:43:02 »

Potíž současných druhotných licencí je především v tom, že k nim nemáte poskytnutý ten "rodokmen" - tedy, kdo danou licenci koupil, jaký typ licence to byl, jak přecházela přes další osoby až k Vám. Kdyby - čistě hypoteticky - došlo k nějakému sporu, bylo by na Vás prokázat, že je licence v souladu se zákonem.

No to ale nemáte nikdy. Bez ohľadu kde ju kúpite, ten rodokmeň nemáte. Aj keď som si ju kúpil v Alze, tak neviem, akými rukami putovala. To, že som dostal kartónovú krabičku a v nej stierateľný kód nepreukazuje jej legálnosť ((keby som ich teda po tých rokoch ešte mal,  sú už dávno skartované) , len mám o trochu silnejšiu pozíciu v tom, keď argumentujem o konaní v dobrej viere. Tiež to nič nedokazuje.

15

Software / Re:Linux mi nepřehraje nic z Canal+

« kdy: 27. 11. 2024, 16:42:00 »

Me by zajimalo, proc by nekdo v roce 2024 graboval vystup grafarny (coz mimochodem samozrejme jde a samozrejme ze system muze nafejkovat podporu naprosto cehokoli), kdyz si totez muze grabnout treba rovnou z http(s) streamu.

A i kdyz si pred ten monitor postavi mobil, poridi rozhodne nasobne kvalitnejsi cam nez nekde v kine.

Uz vubec nemluve o tom, ze ti cely hdcp rozbiju jednou redukci za pet korun padesat.

Pretože ten http(s) stream je zašifrovaný a kľúč k nemu nemáte. Ten je schovaný v hlbinách hardvéru, ktorý ho nechce dať von. Nemusí ísť nutne o grabovanie výstupu grafiky, aj keď to môže byť relatívne jednoduché (svojho času sa predávali framegrabbery, ktoré mali FHD HDMI vstup a USB UVC výstup, a popri svojej činnosti akosi ignorovali HDCP).

Hovorí sa, že určitú dobu sa streamy grabovali tak, že existoval TEE exploit na Nvidia Shield, ako dostať už dekomprimovaný stream z VRAM. Bohužiaľ, v tom streame bol vodoznak, ktorý jednoznačne identifikoval ktorý konkrétny Shield môže za únik a licenciu (kľúč na dešifrovanie streamu, zašifrovaný kľúčom zariadenia) na ďalšie streamy po zaradení na blacklist už nedostal. To znamenalo obetovať jeden shield na jeden release, čo je dosť drahé hobby. Dnes už bude situácia iná, ale tí, čo to vedia, si svoje know-how dosť prísne strážia.