Příspěvky

1

Sítě / Re:Připojení ke SmartTV přes síť (ne bezdrátový displej)

« kdy: 15. 11. 2024, 13:55:03 »

Ahoj,
nemáte někdo vyřešené, jak z počítačů (notebooků) v síti (kabelové, WiFi) zobrazovat obraz na SmartTV (Samsung), které jsou také připojené do sítě?
Jedná se o učebny, ve kterých jsou SmartTV napevno na zdi a připojené kabelem do sítě. Učitelé si nosí svoje notebooky, které připojují buď kabelem nebo WiFi.
S HDMI jsou problémy: kabel je nemotorný a konektor není příliš odolný, výměna drahá. Průzkumem u jiných organizací vyšlo najevo, že s HDMI mají podobné problémy. Většinou je řeší umístěním pevných počítačů do učeben. Touto cestou jít nechceme.
Bezdrátový displej také (zřejmě z důvodu velkého počtu zařízení) nefunguje spolehlivě.

Pokud to bude televize s vestavěným Chromecastem, mělo by to fungovat přinejmenším s prohlížečem Chrome.

Já bych ale asi spíš doporučil použít nějaký HDMI extender přes CAT5 kabely, tak aby na místě katedry stačil jen krátký a levný HDMI kabel, který je možné snadno a levně vyměnit.

2

Hardware / Re:Sériová konzole z PC do Raspberry

« kdy: 13. 09. 2024, 12:11:40 »

Jinak to vysvětlení, proč vidíš nesmysly, spočívá v tom, že RS232 má invertované logické úrovně. Logická 0 je kladné napětí, logická 1 je záporné napětí. Tohle se dá vyřešit jedním tranzistorem, ale rozhodně bych jako nejjednodušší řešení doporučoval na straně PC standardní kablík s DB-9 male konektorem, pak null-modem kabel se dvěma female DB-9 konektory a zapojením 2-3, 3-2, 5-5 a nakonec USB to serial kabel končící opět male DB-9 konektorem.

3

Software / Re:Čím nahradit Stocard?

« kdy: 09. 09. 2024, 16:26:18 »

Platit 20% navíc - což je teď naprosto běžný stav u kasy v Tescu - u průměrného nákupu základních věcí. To opravdu nejde.
Tesco je v tom napřed, ale bohužel mám dojem, že tam tak nějak směřují ty řetězce všechny ...

Asi nejlepší je ty kartičky sdílet ve velké skupině, tím se stanou sbíraná data bezcenná. Snad někdo udělá českou verzi stránek jako https://welbonusgeendata.nl/ nebo https://randombonuskaart.nl/

I když je možné, že supermarkety tohle dřív nebo později zablokují.

4

Software / Re:Čím nahradit Stocard?

« kdy: 09. 09. 2024, 11:13:05 »

Adresářem v /sdcard/DCIM/podslozka-urcujici-Album . pak album jde vybrat v aplikacii galerie

Má to nějaké limitace?proč bystevtohle řešení nepřijali?

Například to samo nezvýší jas displeje. Navíc je potřeba nějak vyrobit obrázky s čárovými kódy, což je pracné. Používat pouze fotku kartičky možné je, ale zbytečně ubírá na ostrosti. (Trošku mi to připomnělo kopírování softwaru pro ZX Spectrum, které se taky dalo dělat buď kombinací LOAD a SAVE nebo jednodušeji, ale méně kvalitně přímo na kazeťáku „dvojčeti”.)

5

Server / Re:Integrace Fail2Ban přímo do OpenSSH

« kdy: 14. 08. 2024, 10:49:17 »

Vývojáři to mají skutečně připravené a mělo by to být součástí příštího vydání OpenSSH 7.6. Hlavní volby jsou PerSourcePenalties a PerSourcePenaltyExemptList.

Aktuální vydání má číslo 9.8 a tuhle funkci už obsahuje.

6

Sítě / Re:IPv6 router na Debianu

« kdy: 29. 07. 2024, 16:15:27 »

Asi to nechápu, ale to je přece naprosto v pořádku, že adresa na WAN rozhraní je z jiného prefixu než je prefix distribuovaný pomocí DHCP-PD. Naopak kdyby byla ze stejného bylo by to zvláštní.

Pokud adresu na WAN rozhraní nevyžaduje ISP - což jak se zdá nevyžaduje - tak ji prostě nemusíte řešit a k routeru se připojovat pomocí adresy na LAN rozhraní z delegovaného prefixu.

7

Sítě / Re:Mechanické spojení optického vlákna s SC-PC konektorem

« kdy: 28. 05. 2024, 10:09:53 »

Můj tip by byl použít místo jednoho dva kabely SC-LC, protáhnout zdí ten LC konektor, který je maličký a použít spojku na spojení dvou LC konektorů.

8

Sítě / Re:Je používání domén z pohodlnosti bezpečnostní riziko?

« kdy: 24. 04. 2024, 09:48:42 »

Mám 9 fyzických serverů, každý má svoje jméno pod kterým se eviduje a má také veřejnou adresu. Nabízí se použití domény, která by ukazovala na ip adresu serveru. Ale napadá mne, jestli není nebezpečné někde takto vyjmenovat všechny veřejné ip adresy serverů.

Krátce: ne. Pokud máte veřejné IPv4 adresy, útočníci je dávno skenují a testují, protože prostě skenují všechny.

Je možné aby někdo zjistit, jaké existují subdomény (a k ním ip adresy) k dané doméně jinak než pokusem a omylem?

Samotný pokus a omyl je překvapivě účinná metoda, vzhledem k tomu, že subdomény bývají slovníková slova.

Dále, jak bylo řečeno, může DNS server povolovat přenos zóny, může používat DNSSEC v (preferované) variantě NSEC, kdy jako vedlejší efekt vyzradí informace o všech jménech v zóně. Při použití NSEC3 se subdomény opět dají uhodnout hrubou silou, tentokrát ale z velké části offline. Nějaký odepsaný hardware na těžení bitcoinů vám vytěží NSEC3 zónu za pár sekund nebo minut i v případě, že nepůjde o slovníková slova.

Je používání domén z pohodlnosti bezpečné? Existuje nějak u nějaké domény  zjistit všechny subdomény?

Ano a ano.

Nebojím se ani tak poskytovatele internetu nebo googlu, ale spíše náhodné člověka z druhého konce světa, který skenuje internet ve velkém. Nebo se také bojím člověka co si nějakou službu vyhlídne zkoumá možné zranitelnosti. Ten ale celkem jistě nebude schopen odchytávat můj vlastní dns provoz, nebo provoz všech zákazníků.

Takový člověk (nebo spíš stroj) se neobtěžuje s DNS a skenuje rovnou IP adresy.

Nebylo by možné mít vlastní DNS server, který bych nastavil na počítačích na kterých pracuji jako třeba třetí v pořadí?
A ten by našel záznam jen když veřejné servery nic najít nedovedou?

Nebylo. Protokol DNS nepodporuje různé názory různých serverů. První finální odpověď platí. Pokud první server odpoví, že doménové jméno neexistuje, tak prostě neexistuje a není důvod ptát se dalších serverů.

  Ten neveřejný DNS server by mohl být chráněn firewalem jen pro přístup z jistých ip adres + VPN. Takto by možná šlo vytvořit celý nový doménový neveřejný prostor.

Ano, pokud rád věci komplikujete, můžete si zaregistrovat veřejné doménové jméno, které nadelegujete na autoritativní servery za firewallem. Takže k datům uvnitř dané zóny se dostanou jen resolvery, kterým to na firewallu povolíte. Pak bude fungovat i výše uvedená myšlenka s třetím resolverem. Ostatní resolvery totiž budou hlásit chybu SERVFAIL, což povede klienta ke zkoušení dalších resolverů až narazí na ten jeden povolený. Může to ale trvat poměrně dlouho.

9

Sítě / Re:Odpojování od datových schránek při větším stahování

« kdy: 17. 04. 2024, 14:34:02 »

Za mne by měl klient změnit IP adresu jen když už mu nic jiného nezbývá, ne jen tak, protože tím možná ušetří tři milisekundy.

Mimochodem, nevíte, o jaký prohlížeč se jednalo? Zrovna u Chrome, který je zmíněn v otázce, by mne to docela překvapilo, protože bych čekal, že v Googlu lidé od cloudu vysvětlí kolegům od prohlížeče, že to není dobrý nápad.

Algoritmus Happy Eyeballs nepoužívá žádnou historickou zkušenost. Jednak proto, že by se tím komplikoval, jednak proto, že podmínky se v čase mění (například slavný půl roku trvající výpadek IPv6 u T-mobile, kde se IPv6 každé dvě minuty rozbilo na 20 sekund).

Je to spíš odpovědnost autoritativního DNS, aby nenabízelo k jednomu doménovému jménu zároveň IP adresy ležící v různých datacentrech.

Kontrola IP adresy je podle mě nesmysl, v době CGNATů, VPN a dual-stacku má tolik falešných poplachů, že se zcela míjí účinkem.

Který OS mění MAC adresu při každém připojení ke stejné síti? To rozhodně není běžné, běžně jsou náhodné MAC adresy v rámci jedné sítě stabilní.

Minimálně Graphene OS (mám za to, že od nějaké verze i Vanilla Android) defaultně ano. Na desktopu nevím.

Android má od verze 12 skutečně také neperzistentní MAC adresy, ale jednak jsou ve výchozím stavu vypnuté a  i při jejich aktivaci to rozhodně není tak, že by telefon při každém připojení používal jinou MAC adresu. Dělá to nejvýše jednou za 24 hodin a pouze pokud vypršela DHCP zápůjčka a uplynuly víc než 4 hodiny od posledního připojení.

10

Sítě / Re:Odpojování od datových schránek při větším stahování

« kdy: 15. 04. 2024, 15:09:32 »

Ochrana na straně serveru proti změně IP adresy klienta je vždycky problematická a je dobře, že to jde na straně DS alespoň vypnout. Ale pokud klient při komunikaci s jedním serverem střídá IPv4 a IPv6, je to problém klienta.

Je to problém klienta, ale není to nic divného, je to standardizované chování zvané Happy Eyeballs, kdy spolu zápasí IPv6 a IPv4 o to, kterému se podaří navázat spojení dřív. Pokud oba protokoly fungují zhruba stejně dobře (resp. IPv6 funguje o trochu hůř než IPv4 - ale právě o takovou trochu, o jakou dostává od algoritmu HE náskok), pak se klient náhodně připojuje tu po IPv4, tu po IPv6.

Nemá v OS náhodou zapnutou randomizaci MAC adresy? Protože pak při každém bliknutí wifiny dostane od DHCPka novou IP adresu.

Který OS mění MAC adresu při každém připojení ke stejné síti? To rozhodně není běžné, běžně jsou náhodné MAC adresy v rámci jedné sítě stabilní.

11

Sítě / Re:Doporučte Wi-Fi router pro OpenWrt

« kdy: 09. 04. 2024, 14:06:50 »

Pokud jde o ohled na cenu, doporučuji něco od GL.iNet. Výrobce sám dodává firmware založený na OpenWRT a není žádný problém ho přepsat nejnovější verzí OpenWRT z upstreamu.

12

Hardware / Re:Tip na USB-C stojánek pro security token

« kdy: 09. 04. 2024, 14:04:23 »

Ano, i zakázané kabely a redukce nepochybně za jistých podmínek fungují, jinak by je asi nikdo nevyráběl. Ta kapitola se ale stejně jmenuje Prohibited Cable Assemblies, to jsem zapomněl vytučnit a jedná se o normativní část. Takže ony vysvětlující komentáře jsou určené k pochopení, proč je daná věc zakázaná, nikoli jako výčet podmínek, za kterých zákaz neplatí.

13

Hardware / Re:Tip na USB-C stojánek pro security token

« kdy: 09. 04. 2024, 09:52:01 »

Já bych jen dodal, že nic jako USB prodlužka nebo A-C adaptér nemá existovat, taková zařízení jsou explicitně zakázána autory specifikací USB.

Zajímavé, můžeš prosím nalinkovat specifikaci, kde se zakazuje USB prodlužka (samozřejmě se zachováním celkové max délky)? Ještě jsem se s tím nesetkal, díky

Specifikace je zde. V kapitole 6.4.4 na straně 92 se píše:

6.4.4 Prohibited Cable Assemblies
USB is optimized for ease of use. The expectation is that if the device can be plugged in, it will work. By specification, the only conditions that prevent a USB device from being successfully utilized are lack of power, lack of bandwidth, and excessive topology depth. These conditions are well understood by the system software.
Prohibited cable assemblies may work in some situations, but they cannot be guaranteed to work in all instances.
• Extension cable assembly
A cable assembly that provides a Series “A” plug with a series “A” receptacle or a Series “B” plug with a Series “B” receptacle. This allows multiple cable segments to be connected together, possibly exceeding the maximum permissible cable length.
• Cable assembly that violates USB topology rules
A cable assembly with both ends terminated in either Series “A” plugs or Series “B” receptacles. This allows two downstream ports to be directly connected.
Note: This prohibition does not prevent using a USB device to provide a bridge between two USB buses.
• Standard detachable cables for low-speed devices
Low-speed devices are prohibited from using standard detachable cables. A standard detachable cable assembly must be high-/full-speed. Since a standard detachable cable assembly is high-/full- speed rated, using a long high-/full-speed cable exceeds the capacitive load of low-speed.

O něco méně explicitní je zmínka ve specifikaci USB type-C v sekci 2.2 na straně 35:

Cables and connectors, including USB Type-C to USB legacy cables and adapters, are explicitly defined within
this specification. These are the only connectors and cables that are authorized by the licensing terms of this
specification.
(…)
The following USB Type-C cables are defined.
• USB Full-Featured Type-C cable with a USB Full-Featured Type-C plug at both ends for USB 3.2, USB4
and full-featured applications.
• USB 2.0 Type-C cable with a USB 2.0 Type-C plug at both ends for USB 2.0 applications.
• Captive cable with either a USB Full-Featured Type-C plug or USB 2.0 Type-C plug at one end.
• Active cables as defined in Chapter 6.
(…)
USB Type-C receptacle to USB legacy adapters are explicitly not defined or allowed. Such adapters would
allow many invalid, and potentially unsafe, cable connections to be constructed by users.

14

Hardware / Re:Tip na USB-C stojánek pro security token

« kdy: 08. 04. 2024, 11:57:05 »

Já bych jen dodal, že nic jako USB prodlužka nebo A-C adaptér nemá existovat, taková zařízení jsou explicitně zakázána autory specifikací USB.

Jediné podporované řešení podle specifikací USB je aktivní prvek, tedy nějaký hub. Samozřejmě, pro popsaný účel připojování tokenu je to asi zbytečně komplikované a obyčejná prodlužka bude fungovat dobře. Ale pokud náhodou ne, nebo pokud to bude fungovat jen napůl, například jen v jedné orientaci konektoru, je potřeba se tomu nedivit a rozhodně nevinit USB z toho, že zakázané zařízení správně nefunguje.

15

Hardware / Re:Kabel Thunderbolt kombinující mDP a USB-C

« kdy: 11. 03. 2024, 12:52:38 »

Apple predáva redukciu TB2 <-> TB3, je to káblik asi 10 cm dlhý, a funguje to. Aj keď nie som si istý, či cez to ide aj natívny DP, to som neskúšal.

Nativní DP to nepodporuje. Je to sice napsané v popisku, ale já to stejně zkusil, takže můžu potvrdit, že popisek říká pravdu.