31
/dev/null / Re:Erouška
« kdy: 05. 05. 2020, 19:32:02 »
Nikde přece nemůže nutit, aby si instaloval cokoli na svůj telefon.
Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
32
Software / Re:Wireshark: capture filtry pro monitor mode (radiotap)
« kdy: 05. 05. 2020, 19:29:10 »=> jak wireshark dekoduje WPA2 traffic...Jistěže. To je samozřejmé, že jsem to nezminoval. Bez toho to nejde. To je nutná podmínka, ale já jsem upozorňoval na další podmínku, že dekryptovat u WPA2 lze pouze traffic, ke kterému Wireshark rovnako zachytil EAPOL pakety. Chápeme? A já se ptám, ako zadám capture filter TCP, ked k tomu najprv potrebuje zachytit EAPOL (EAPOL!=TCP) .
Jednoducho, zadáme dekryptovací key vo Wiresharku, ale človek, ktorý si hovorí pokročilý by o tom mal vedieť.
Napadá mě jediné řešení capture filtru: tcp && eapol. Ale funguje to?
Nepotřebuji radit, decryptovaný WPA2 traffic dávno umím si otevřít.
33
O serveru Root.cz / Re:Nečekané odhlašování , tentokrát se příspěvek odeslal.
« kdy: 05. 05. 2020, 13:42:58 »
Teď se stala věc z podobného soudku, ale opačná. Měl jsem rozepsaný příspvěk, dal ho odeslat,
po načtení stránky : Příspěvek se vložil ale byl jsem odhlášený.
čili to musí být nějaké dvojjaké, že mě to odhlásí aktivně, jelikož příspěvek mi to schroustne OK.
po načtení stránky : Příspěvek se vložil ale byl jsem odhlášený.
čili to musí být nějaké dvojjaké, že mě to odhlásí aktivně, jelikož příspěvek mi to schroustne OK.
34
O serveru Root.cz / Re:Místní fórum – uživatelská blokace některých uživatelů
« kdy: 05. 05. 2020, 13:39:56 »
Já se ptám věci, na který je google krátký. Občas mi tam ujede nějaká chybová hláška, ale většinou se ptám na komplexní problém, na který nestačí vysvětlení jednoho termínu.
10 x zmíněno mé ctěné jméno, tolik publicity si nezasloužím.
Spíš bysme si měli dát pozor na Grétu. Není zdaleka na root.cz, ale na řadě předních českých webů všeljakého zaměření. Zhruba asi od podzimu 2019, hodně ji vzal hackerský útok na nějaké Tykačovy elektrárny a asi se pomstila na mimibazaru
10 x zmíněno mé ctěné jméno, tolik publicity si nezasloužím.
Spíš bysme si měli dát pozor na Grétu. Není zdaleka na root.cz, ale na řadě předních českých webů všeljakého zaměření. Zhruba asi od podzimu 2019, hodně ji vzal hackerský útok na nějaké Tykačovy elektrárny a asi se pomstila na mimibazaru
35
Sítě / Vytvoření izolované podsítě s využitím brány
« kdy: 05. 05. 2020, 13:36:13 »
Chtěl bych vědět, jak prakticky na linuxovém stroji vytvořím subsíť, která bude mít určité vlasnosti z nadřazené sítě. S možností přístupu na internet přes bránu, ale bez komunikace mezi jednotlivými sítěmi)
Začnu popisem nadřazené sítě: je to 192.168.0.0/16 s bránou a DHCP 192.168.1.1 a . Tu mohou využívat, ale nemohu ji konfigurovat.
Do té sítě jsem připojen přes první rozhraní a do vnitřní sítě přes druhé rozhraní.
Chci udělat to, aby zařízením z vnitřní sítě byla přidělována IP z pod-rozsahu, tedy 192.168.200.xxx/24. (to by jim zařídil zde běžící DHCP server, který ale nějakým způsobem bude muset spolupracovat s DHCP původní sítě) Zároveň aby zařízení z vnější sítě nemohly komunikovat s vnitřní sítí (kromě brány) a zařízení z vnitřní sítě se nemohly napojit na vnější nadřazenou síť (kromě brány a na internet ale ano). Chtěl bych to bez natu (ano vím, že nařazená síť NAT určitě používá).
Samozřejmě to jde zprovoznit tak NATovaně (1:N - PNAT - překlad portů i adres), že dhcp klient na vnějším rozhraní si vezme 192.168.xxx.xxx a na vnitřním pojede DHCP server třeba 172.16.0.xxx, a oba budou oddělené. a samozřejmě se přidá pravidlo do iptables (-t nat - A POSTROUTING -i in0 -o out0 -j MASQ.)
Zajímá mě druhé (vlastně jediné)alternativní řešení a SICE 1:1 natem (defacto jen NAT, pouze překlad adres) s tím, že by vnitřní síť byla třeba 172.16.
Podmínka je, aby to fungovalo bez žádné konfigurace klientských PC (ty se ostatně stejně budou připojovat na vnitřní rozhraní.
To taky vylučuje, že by se tedy klienti připojovaly rovnou do vnější sítě.
Taky jsem zavrhl vytvoření bridge. Má někdo názor, že by to bylas chůdná cesta (ale muselo by se dát hodně pravidel to ebtables, jestli to nazývám správně) ?
Dál bych se chtěl zeptat, zda k tomu budou potřeba věci jako
- IP Scope (to je co zač? neříká to, že adresa je platná jen v rámci rozhraní, to by umožnilo mít 2 různé sítě např 192.168/16, který by ale spolu nemluvily, neboť by jejich hranice končila rozhraním ; nebo scope global či jiný?)
- DHCP relay (pro to a aby stroj mohl dělat ty kouzla s DHCP, že se bude snažit u nadřazeného DHCP vyjednat 192.168.200.xxx, ale klientům posílat zůženou masku sítě /24 místo /16 a )
- je potřeba dávat do iptables nějaká pravidla, nebo definice sítí je dostatečná, aby zařízení o existenci nadřazené sítě neměly páru (to koliduje s adresou brány) a zároveň ,aby zařízení z nadřazené sítě kromě brány nemohly komunikovat s mojí sítí?
- nazývá se toto podsíť/ subnet?
Začnu popisem nadřazené sítě: je to 192.168.0.0/16 s bránou a DHCP 192.168.1.1 a . Tu mohou využívat, ale nemohu ji konfigurovat.
Do té sítě jsem připojen přes první rozhraní a do vnitřní sítě přes druhé rozhraní.
Chci udělat to, aby zařízením z vnitřní sítě byla přidělována IP z pod-rozsahu, tedy 192.168.200.xxx/24. (to by jim zařídil zde běžící DHCP server, který ale nějakým způsobem bude muset spolupracovat s DHCP původní sítě) Zároveň aby zařízení z vnější sítě nemohly komunikovat s vnitřní sítí (kromě brány) a zařízení z vnitřní sítě se nemohly napojit na vnější nadřazenou síť (kromě brány a na internet ale ano). Chtěl bych to bez natu (ano vím, že nařazená síť NAT určitě používá).
Samozřejmě to jde zprovoznit tak NATovaně (1:N - PNAT - překlad portů i adres), že dhcp klient na vnějším rozhraní si vezme 192.168.xxx.xxx a na vnitřním pojede DHCP server třeba 172.16.0.xxx, a oba budou oddělené. a samozřejmě se přidá pravidlo do iptables (-t nat - A POSTROUTING -i in0 -o out0 -j MASQ.)
Zajímá mě druhé (vlastně jediné)alternativní řešení a SICE 1:1 natem (defacto jen NAT, pouze překlad adres) s tím, že by vnitřní síť byla třeba 172.16.
Podmínka je, aby to fungovalo bez žádné konfigurace klientských PC (ty se ostatně stejně budou připojovat na vnitřní rozhraní.
To taky vylučuje, že by se tedy klienti připojovaly rovnou do vnější sítě.
Taky jsem zavrhl vytvoření bridge. Má někdo názor, že by to bylas chůdná cesta (ale muselo by se dát hodně pravidel to ebtables, jestli to nazývám správně) ?
Dál bych se chtěl zeptat, zda k tomu budou potřeba věci jako
- IP Scope (to je co zač? neříká to, že adresa je platná jen v rámci rozhraní, to by umožnilo mít 2 různé sítě např 192.168/16, který by ale spolu nemluvily, neboť by jejich hranice končila rozhraním ; nebo scope global či jiný?)
- DHCP relay (pro to a aby stroj mohl dělat ty kouzla s DHCP, že se bude snažit u nadřazeného DHCP vyjednat 192.168.200.xxx, ale klientům posílat zůženou masku sítě /24 místo /16 a )
- je potřeba dávat do iptables nějaká pravidla, nebo definice sítí je dostatečná, aby zařízení o existenci nadřazené sítě neměly páru (to koliduje s adresou brány) a zároveň ,aby zařízení z nadřazené sítě kromě brány nemohly komunikovat s mojí sítí?
- nazývá se toto podsíť/ subnet?
36
Software / Re:Wireshark: capture filtry pro monitor mode (radiotap)
« kdy: 05. 05. 2020, 10:06:33 »
Môžeš mi vysvětlit, jak wireshark dekoduje WPA2 traffic, ked nepozná EAPOL handshake? Nepozná ho lebo ho nestiahne lebo EAPOL nevyhovi filtru TCP. Nechci být zlý, ale pokud pokud bys tvrdil, že tam žádná problém není , tek neznáš základy ty. Není možné zároveň zachytit EAPOL paket, který je nutný pro rozšifrování, pokud capture filtr je TCP. Protože EAPOL není TCP (nezachytí EAPOL) a bez EAPOL nerozšifruje komunikaci a ... Nebo wireshark snad magicky udeli vyjimku pro capture filtr, aby zachytil handshake EAPOL?
Připouštím, že neznám základy capture filtrov (toto "link layer applied in wrong context" me celkem vydesilo), ale wireshark ovládám ako pokročilý.
je z roku 2007, je tam zmíněn Ethereal (wireshark), slovo filtr se tam vyskytuje 5x, capture 0x, bpf 0x.
Pro mě bezcenné.
Připouštím, že neznám základy capture filtrov (toto "link layer applied in wrong context" me celkem vydesilo), ale wireshark ovládám ako pokročilý.
Citace
wlan dir 3Odkial znas tyto filtre? Kde se daju najit?
Citace
diplomovka_szarkova pdfTěch 90 stránek jsem prošel za 4 minuty. nedozvedel jsem se nic nového (okrem prehledné tabulky DA/SA/BSS,TA). A z oblasti capture filtru wiresharku tuplem nic."Diplomka" prilis popisuje obecne veci , prokousal jsem se jimi, ty nehodnotim, byt jsou celkem korektni, ale s bidou bych to uznal jako balalarku. Co hur, tyka se jen WEP.
je z roku 2007, je tam zmíněn Ethereal (wireshark), slovo filtr se tam vyskytuje 5x, capture 0x, bpf 0x.
Pro mě bezcenné.
37
Software / Re:Wireshark: capture filtry pro monitor mode;nefungují=žádné zachycené pakety
« kdy: 04. 05. 2020, 20:56:03 »
Pokud zadám jakýkoli filtr (zkoušel jsem wlan type 2 nebo tcp*), wireshark nezachytí žiadný paket.
* je to validní filtr? Protože je to problém slepice a vejce: aby bylo možné dekódovat wlan traffic je nutné zachytit handshake (samozřejmě jsem se associoval po spuštění wiresharku, i přesto jsem nevěřil, že to bude fungovat). Jenže handshake není TCP, že áno.
* je to validní filtr? Protože je to problém slepice a vejce: aby bylo možné dekódovat wlan traffic je nutné zachytit handshake (samozřejmě jsem se associoval po spuštění wiresharku, i přesto jsem nevěřil, že to bude fungovat). Jenže handshake není TCP, že áno.
38
Server / Re:Tor exit node ; používá multihoming ? (jiným uchem ven než dovnitř)
« kdy: 04. 05. 2020, 19:50:42 »
Když jsme u těch exit nodů , zajímalo by mě ,jak je typické nebo nutné nebo zbytečné,aby měl multihoming ? Tzn, že do internetu se připojuje jiným připojením než do sítě tor? Alias jestli připojení k exit nodu z TOR klienta je stejné/jiné než to, kudy se on sám připojuje do internetu.
Je vůbec smysluplné, aby exit nody byly do internetu připojené pouze jedním připojením.
Je vůbec smysluplné, aby exit nody byly do internetu připojené pouze jedním připojením.
39
/dev/null / router" Podivné ICMP na WAN: dovnitř Unreachable port 137,ven,80,443 DNS rebind
« kdy: 04. 05. 2020, 18:28:27 »
Tak upřesňuji ty podivné ICMP pakety. ono jich je víc skupin. obojí se odehrává pouze na rozhraní "ven" (192.168.1.5).
směrem z routeru :
DNS (port 53) dotazy klientů "router" přeposílá na zvolený DNS server na internetu. Na A dotazy přijde v pořádku odpověď. Na AAAA dotazy přichází odpověď Refused, Additional Record Name explanation.invalid a zpráva TXT "blocked by DNS rebinding protection". Následně na tuto DNS odpověď pošle router ICMP Port not reachable (a kopii paketu DNS odpovědi)
-Proč DNS server posílá tohle? Kde je problém?
-Jak zablokovat, aby se "router" ptal na AAAA dotazy, stejně IPv6 nemám a nepoužívám a mám ho zakázaný.
- Proč se to týká jen DNS AAAA dotazů? a Proč na ně odpovídá? Kde je problém a co s tím?
-Souvisí to nějak s tím, že dnsmasq je spuštěn s parametrem --stop-dns-rebind)? Ale nerozumím jak, když ten text o prevenci dns rebind nejprve přijde v odpovědi.
- ( port SSL 443) pakety. - jde o různé pakety HTTPS komunikace, většinou se to odehraje na pakety vyznačené černě (spurious retransmision,, Dup) nebo s příznaky FIN PSH, ACK., nebo RST,ACK Vrací Host unreachable. je jich asi 80% ze všech ICMP.
- to samé na Port HTTP (80) -identická situace (až na to že jich není tolik ,HTTPS je častější než HTTP)
Pakety směrem dovnitř:
Nevím jak to možné, ale na notebooku připojeném notebooku k routermjsem si pustil ivysilání české televize. Proč to píšu, protože mi přišly ICMP pakety z nějakého cdn ČT ICMP Port unreachable na UDP komunikaci daného ntb mezi porty 137-137.. Co je tohle k sakru zař?
Přitom, všechny weby a ivysílání jdou jak po másle
směrem z routeru :
DNS (port 53) dotazy klientů "router" přeposílá na zvolený DNS server na internetu. Na A dotazy přijde v pořádku odpověď. Na AAAA dotazy přichází odpověď Refused, Additional Record Name explanation.invalid a zpráva TXT "blocked by DNS rebinding protection". Následně na tuto DNS odpověď pošle router ICMP Port not reachable (a kopii paketu DNS odpovědi)
-Proč DNS server posílá tohle? Kde je problém?
-Jak zablokovat, aby se "router" ptal na AAAA dotazy, stejně IPv6 nemám a nepoužívám a mám ho zakázaný.
- Proč se to týká jen DNS AAAA dotazů? a Proč na ně odpovídá? Kde je problém a co s tím?
-Souvisí to nějak s tím, že dnsmasq je spuštěn s parametrem --stop-dns-rebind)? Ale nerozumím jak, když ten text o prevenci dns rebind nejprve přijde v odpovědi.
- ( port SSL 443) pakety. - jde o různé pakety HTTPS komunikace, většinou se to odehraje na pakety vyznačené černě (spurious retransmision,, Dup) nebo s příznaky FIN PSH, ACK., nebo RST,ACK Vrací Host unreachable. je jich asi 80% ze všech ICMP.
- to samé na Port HTTP (80) -identická situace (až na to že jich není tolik ,HTTPS je častější než HTTP)
Pakety směrem dovnitř:
Nevím jak to možné, ale na notebooku připojeném notebooku k routermjsem si pustil ivysilání české televize. Proč to píšu, protože mi přišly ICMP pakety z nějakého cdn ČT ICMP Port unreachable na UDP komunikaci daného ntb mezi porty 137-137.. Co je tohle k sakru zař?
Přitom, všechny weby a ivysílání jdou jak po másle
40
/dev/null / prohlížení webu na klientu - "router" posílá serveru ICMP Not reachable
« kdy: 04. 05. 2020, 14:50:51 »
Dobrý den, zprovoznil jsem linuxový router, který je připojen do "do internetu" *** (sítě ven) a zároveň se na něj připojit přes wifi (v režimu master-hostpad), je routováno přes net.ip...forward=1. Použit je dnsmasq (-b -D alias --bogus-priv --domain-needed --stop-dns--rebind)
Wwebové stránky HTTP i HTTPS se v pohodě načítají. no problem. Jenže sám linuxový router někdy cílovému serveru posílá ICMP pakety Not reachable (source: ip adresa linux.routeru na rozhraní do stíě ven 192.168.1.5, destination je IP serveru ). Zkoušeno na víc klientech. Nějak to snad asi může souviset s firewallem. Policy mám accept/accept, a klasické pravidlo pro masquerade (-t nat -A POSTROUTING -i phy0wlan0inner -o wlan phy0wlan1outer -J MASQUERADE) . Stává se to zhruba po ukončení http spojení a odeslání fin paketů
Samozřejmě jsem na to pustil wireshark(pro vnitřní síť i vnější současně). Na vnitřní síti je vše korektní. Na vnější síti tam po (connection=close) nebo po nějaké době(keepalive timeout) u tcp zakončovacích paketů je toho hodně černého jako retransmision, dup.... a hned poté ty ICMP (tady to asi bude chtít trochu upřesnit, co za pakety nebo důvod označení černě konrétně... doplním... ) ... Ale opakuji prohlížení webu je naprosto OK.
Proč to dělá? Jak se toho zbavit.?
*** onen router používá privántní rozsah (172.16.0 /24 např)pro klienty a proužívá NAT na překlad (MASQUERADE). Je připojen na další router (192.168.1.1 (/16) , ip např 192.168.1.5) ,který dělá další NAT a možná ještě je tam třetí NAT. Tak to je, nejde s tím nic udělat. Nemyslím si že je to příčina , jen to uvádím pro úplnost. Ostatně nikdy jsem si podobného nevšiml když jsem také měl víc natů a sniffoval na jiné síťové situaci .
Wwebové stránky HTTP i HTTPS se v pohodě načítají. no problem. Jenže sám linuxový router někdy cílovému serveru posílá ICMP pakety Not reachable (source: ip adresa linux.routeru na rozhraní do stíě ven 192.168.1.5, destination je IP serveru ). Zkoušeno na víc klientech. Nějak to snad asi může souviset s firewallem. Policy mám accept/accept, a klasické pravidlo pro masquerade (-t nat -A POSTROUTING -i phy0wlan0inner -o wlan phy0wlan1outer -J MASQUERADE) . Stává se to zhruba po ukončení http spojení a odeslání fin paketů
Samozřejmě jsem na to pustil wireshark(pro vnitřní síť i vnější současně). Na vnitřní síti je vše korektní. Na vnější síti tam po (connection=close) nebo po nějaké době(keepalive timeout) u tcp zakončovacích paketů je toho hodně černého jako retransmision, dup.... a hned poté ty ICMP (tady to asi bude chtít trochu upřesnit, co za pakety nebo důvod označení černě konrétně... doplním... ) ... Ale opakuji prohlížení webu je naprosto OK.
Proč to dělá? Jak se toho zbavit.?
*** onen router používá privántní rozsah (172.16.0 /24 např)pro klienty a proužívá NAT na překlad (MASQUERADE). Je připojen na další router (192.168.1.1 (/16) , ip např 192.168.1.5) ,který dělá další NAT a možná ještě je tam třetí NAT. Tak to je, nejde s tím nic udělat. Nemyslím si že je to příčina , jen to uvádím pro úplnost. Ostatně nikdy jsem si podobného nevšiml když jsem také měl víc natů a sniffoval na jiné síťové situaci .
41
/dev/null / PTR DNS ...udp.z.y.x.z.in-addr.arpa prochází na druhé rozhraní i zpět vč.odpověd
« kdy: 04. 05. 2020, 12:46:31 »
mám bridge na 2 sítích. jedna síť je vnitřní (privátní 192.168/16), druhá vnější. dnsmasq obsluhuje vnitřní rozhraní (argumenty dnsmasq -k -dhcp-range=192....,255.0.0 -D - b -i eth0 --server 8.8.8.8 - tedy statická konfigurace bez načítání konfigurace ze souboru. )
1. Co je zač DNS PTR dotaz {lb,b,db}._dns_sd._udp.0.0.168.192.in-addr.arpa ? Resp. proč se ptá na 192.168.0.0 ?
2. Z jakého důvodu (doufám že dnsmasq) posílá dotazy ven?
3. Z jakého DNS dotazy posílá rovnou na rozhraní (8.8.8.8 definovaný pro zařízení na eth0, ale proč i na 192.168.2.1 , což je "upstream DNS" na vnějším rozhraní, které bylo přiřazeno z dhclienta)
4. Co je přesně zač volba -b (--bogus-priv) ? Dle manu "Bogus private reverse lookups . All rev.lookups are answered nxdomain rather than forwarded upstream)... Tedy uvedení této volby by mělo zabránit tomu co se děje, nepletu se
Otázka mimo: je lepší dnsmasq a nebo isc-dhcp-server ?
1. Co je zač DNS PTR dotaz {lb,b,db}._dns_sd._udp.0.0.168.192.in-addr.arpa ? Resp. proč se ptá na 192.168.0.0 ?
2. Z jakého důvodu (doufám že dnsmasq) posílá dotazy ven?
3. Z jakého DNS dotazy posílá rovnou na rozhraní (8.8.8.8 definovaný pro zařízení na eth0, ale proč i na 192.168.2.1 , což je "upstream DNS" na vnějším rozhraní, které bylo přiřazeno z dhclienta)
4. Co je přesně zač volba -b (--bogus-priv) ? Dle manu "Bogus private reverse lookups . All rev.lookups are answered nxdomain rather than forwarded upstream)... Tedy uvedení této volby by mělo zabránit tomu co se děje, nepletu se
Otázka mimo: je lepší dnsmasq a nebo isc-dhcp-server ?
42
Software / Re:Wireshark: capture filtry pro monitor mode (radiotap)
« kdy: 03. 05. 2020, 20:06:14 »
No je to takové polovičaté. První funguje, druhé nefunguje.
Navíc to má nějaké odlišné názvy parametrů (odlišná syntaxe je očekávatelná). Nelze tam vkládat libovolné pole (napadl mě například) dokonce mám takové nemilé tušení, že to umí jen úzký obor polí.
Jak například vyberu pakety na kanálu 48, / pakety na kanálu >66, broadcast pakety s SSID hodnotou "VOIP"?
Mimojiné mi wireshark častokrát spadne při manipulaci s textem v poli pro filtr (opakovaný backspace, když nezbyde žádný znak například)
Navíc to má nějaké odlišné názvy parametrů (odlišná syntaxe je očekávatelná). Nelze tam vkládat libovolné pole (napadl mě například) dokonce mám takové nemilé tušení, že to umí jen úzký obor polí.
Jak například vyberu pakety na kanálu 48, / pakety na kanálu >66, broadcast pakety s SSID hodnotou "VOIP"?
Mimojiné mi wireshark častokrát spadne při manipulaci s textem v poli pro filtr (opakovaný backspace, když nezbyde žádný znak například)
43
Software / Re:Wireshark: capture filtry pro monitor mode (radiotap)
« kdy: 02. 05. 2020, 17:01:02 »
Nevíte, zda proběhl nějaký vývoj v této věci? (Jestli už existují capture filtry pro kartu v režimu monitor modu)
44
Sítě / Re:Síťovka Ralink se nepřipojí k AP ; přes wpa_supplicant -c <() vyřešeno
« kdy: 02. 05. 2020, 16:59:43 »a v ramci zkusil??Vím, že dorážíš a jsi netrpělivý
, když jsi nabídl své řešení a čekáš jak to dopadlo. Já jsem psal, že jsem to zatím nezkoušel a současně na netu narazil na ten návod wpa_supplicant s argumentem -c <(wpa_passphrase ssid heslo). (jak jsem psal v příspěvku)Mezitím se věci hnuly. Já jsem zkusil to wpa_supplicant -c a jsem s tím spokojený, takže tvé řešení jsem už nezkoušel.
Ale stále visí ve vzduchu otázka, proč to nejde přes iw ap connect ... Invalid argument...
Pro upřesnění : z dané wifi karty to nejde na na žádnou wifi síť, ale z jiné karty to jde na libovolnou síť....
45
Software / Zachování h264@youtube s blokovanými cookies : místo addonu h264 užij userscript
« kdy: 02. 05. 2020, 15:50:27 »
Vrtalo mi to hlavou, proč na jiném PC to na youtube jde H264 i s blokovanými cookies (což jsem zjistil, že byla příčina, že to hrálo VP9).
Řešení je použítmísto rozšíření H264ify identický userscript h264ify od stejného autora (přes správce userscriptů v rolirozšíření Tampermonkey ; ale chrom by uměl umět i userscripty nativně ) .
Dobré vědět
Řešení je použít
Dobré vědět
