Red Hat řeší bezpečnostní incident, při kterém došlo k neoprávněnému přístupu do GitLab instance používané svým konzultačním týmem.
Immich byl vydán v první stabilní verzi 2.0.0 (YouTube). Jedná se o alternativu k výchozím aplikacím od Googlu a Applu pro správu fotografií a videí umožňující vlastní hosting serveru Immich. K vyzkoušení je demo. Immich je součástí balíčků open source aplikací FUTO. Zdrojové kódy jsou k dispozici na GitHubu pod licencí AGPL-3.0.
Český telekomunikační úřad vydal zprávy o vývoji cen a trhu elektronických komunikací se zaměřením na rok 2024. Jaká jsou hlavní zjištění? V roce 2024 bylo v ČR v rámci služeb přístupu k internetu v pevném místě přeneseno v průměru téměř 366 GB dat na jednu aktivní přípojku měsíčně – celkově jich tak uživateli bylo přeneseno přes 18 EB (Exabyte). Nejvyužívanějším způsobem přístupu k internetu v pevném místě zůstal v roce 2024 bezdrátový
… více »Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-10-01. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Jedná o první verzi postavenou na Debianu 13 Trixie.
Byla vydána nová verze 4.6 svobodného notačního programu MuseScore Studio (Wikipedie). Představení novinek v oznámení v diskusním fóru a také na YouTube.
Společnost DuckDuckGo stojící za stejnojmenným vyhledávačem věnovala 1,1 milionu dolarů (stejně jako loni) na podporu digitálních práv, online soukromí a lepšího internetového ekosystému. Rozdělila je mezi 29 organizací a projektů. Za 15 let rozdala 8 050 000 dolarů.
Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.17. Díky 278 přispěvatelům.
Bylo vydáno openSUSE Leap 16 (cs). Ve výchozím nastavení přichází s vypnutou 32bitovou (ia32) podporou. Uživatelům však poskytuje možnost ji ručně povolit a užívat si tak hraní her ve Steamu, který stále závisí na 32bitových knihovnách. Změnily se požadavky na hardware. Leap 16 nyní vyžaduje jako minimální úroveň architektury procesoru x86-64-v2, což obecně znamená procesory zakoupené v roce 2008 nebo později. Uživatelé se starším hardwarem mohou migrovat na Slowroll nebo Tumbleweed.
Ministerstvo průmyslu a obchodu (MPO) ve spolupráci s Národní rozvojovou investiční (NRI) připravuje nový investiční nástroj zaměřený na podporu špičkových technologií – DeepTech fond. Jeho cílem je posílit inovační ekosystém české ekonomiky, rozvíjet projekty s vysokou přidanou hodnotou, podpořit vznik nových technologických lídrů a postupně zařadit Českou republiku mezi země s nejvyspělejší technologickou základnou.
… více »Radicle byl vydán ve verzi 1.5.0 s kódovým jménem Hibiscus. Jedná se o distribuovanou alternativu k softwarům pro spolupráci jako např. GitLab.
ci pri scanovani okolia vidi vsetky alebo len jeden s najsilnejsim signalomKdyž AP vysílá beacon rámce, tak se o něm klient dozví tak jako tak. Pokud klient pošle probe dotaz, tak se dozví jen o těch AP, které mu odpoví. Klient samozřejmě může pasivně sledovat rádiový provoz a může se tak dozvědět i o strojích, který se s ním bavit nechtějí.
rozlisuje podla MAC adresyV principu asociace na AP se řídí podle BSSID, což není nic jiného než MAC adresa AP. Takže ano, rozlišuje. Otázka ale je, jak je udělaný stavový automat uvnitř klienta. Obvykle se pro podpoření mobility považují všechny AP se stejným ESSID za jednu síť a klient si automaticky vybírá AP s nejlepším signálem. Samozřejmě při přechodu se musí od starého AP odhlásit a přihlásit se k novému. Např. iwconfig z wireless-tools má parametr ap, kterým si můžete vynutit konkrétní AP podle jeho MAC adresy.
Jednotlivé AP fungují na linkové vrstvě, takže celá síť se jeví jako jediný ethernetový segment, jako by všude byly switche. Směrování pak probíhá rovněž na druhé vrstvě podle MAC addres.Toto je automaticky mechanizmus? Znamena to, ze ked zapojim 3 AP do jednej siete/segmentu. Sami si preposielaju ramce pre inych klientov. Alebo sa to routovanie musi nastavovat? Inymi slovami, ked router siete dostane paket pre nejakeho klienta posle ho na hociktory AP, kt. ho preposle pripadne na ine AP?Poznate nejaky zdroj kde je tento mechanizmus opisany? Este k tej reasociacii.
Když pak přechází, tak se od sítě neodpojuje (protože by vznikla prodleva, ve které by nebyl nepřipojený, i když by byl v dosahu obou AP), ale pošle na nové AP požadavek na reasociaciMohli by ste mi prosim opisat tu reasociaciu krokovo? Je tam nejaka podpora v standarde? Moja predstava je : 1. Klient je pripojeny k jendemu ap 2. Klient scanuje okolie 3. Klient sa prepaja na druhe ap. co pozostava z krokov: odpojit, pripojit k novemu
Jednotlivé AP fungují na linkové vrstvě, takže celá síť se jeví jako jediný ethernetový segment, jako by všude byly switche. Směrování pak probíhá rovněž na druhé vrstvě podle MAC addres.Toto je automaticky mechanizmus? Znamena to, ze ked zapojim 3 AP do jednej siete/segmentu. Sami si preposielaju ramce pre inych klientov. Alebo sa to routovanie musi nastavovat? Inymi slovami, ked router siete dostane paket pre nejakeho klienta posle ho na hociktory AP, kt. ho preposle pripadne na ine AP?Poznate nejaky zdroj kde je tento mechanizmus opisany?
Ano, je automatický mechanismus do té míry, že není třeba nastavovat nějaká pravidla pro směrování.
Jediné, co je třeba udělat, je zapnout bridge mezi rádiovým a drátovým rozhraním v AP.
I když 802.11 (WiFi) se snaží být podobný 802.3 (kabelový Ethernet), je zde jistý rozdíl ve struktuře rámců. Tohle musí ovladač rádia vzít na vědomí a umět mezi těmito dvěma formáty převádět. Je to vidět např. v programu tcpdump, který, když se pustí nad 802.11 rozhraním, tak o tom informuje a vypisuje 802.11 rámce se všemi čtyřmi MAC adresami (zdrojová a cílová 802 rámce, zdrojová a cílová 802.11 rádia).
Jednotlivé uzly se směrovací pravidla učí za běhu podle toho, kudy chodí rámce pocházející ze stroje s danou MAC adresou.
Příklad: Router se rozhodne odeslat packet do segmentu s AP, přes ARP/NDP zjistí MAC adresu stroje, který má danou IP adresu, a odešle rámec. Přijme jej switch, zkusí najít cílovou adresu ve své tabulce adresa−port. Když ji tam najde, přepošle rámec daným portem na jediné AP. Když ji nenajde, rozešle stejný rámec skrze všechny porty (až na ten, kudy rámec přišel). Rámec přijme AP a udělá úplně stejnou věc jako switch. Pokud je k němu daný klient připojen, odešle mu rámec. Když není, tak rámec zahodí (předpokládejme, že AP má jen dvě rozhraní: jedno 802.3 a jedno 802.11).
Příklad přeposílání rámce odešlému klientu: výše popsaným způsobem doputuje rámec na AP, avšak mezi tím se klient naasociaval na jiné nové AP. Staré AP to zatím neví, rezervuje si kanál pro sebe a odešle rámec a čeká na potvrzení příjetí klientem. Potvrzení nedostane, protože klient je pryč. Zkouší to dokud nevyprší limit opakovaných pokusů na doručení. (Pokud potvrzování přijetí není implementováno – je to volitelná součást protokolu 802.11, budou rámce odvysílány do éteru, aniž by je někdo zpracoval.) Mezitím si AP uvědomí, že klient je dosažitelný přes 802.3 port (ať už příkazem z jiného AP nebo sledováním bridgovací tabulky adresa-port). Nyní vyjme rámce z odesílacího bufferu 802.11 rozhraní, vymaže si klienta ze seznamu asociovaných klientů, rovněž odmaže záznam z bridgovací tabulky ukazující na tento 802.11 port a nakonec vyjmuté rámce pošle do bridgovací kódu. Ten buďto záznam nemá, a tak rámce odešle na obě strany (přičemž na rádiu budou zahozeny, protože tam už není klient naasociván), nebo záznam už má ukazující na drátové rozhraní, a tak budou rámce odeslány jenom tam. Rámce opět přijme switch a podle dříve popsaného mechanismu je přepošle jinam.
Při pečlivém průzkumu lze najít místa, kdy se rámce prostě ztratí. Ale to je již riziko Ethernetu, protože ten obecně nezaručuje doručení.
Mezitím si AP uvědomí, že klient je dosažitelný přes 802.3 port (ať už příkazem z jiného AP nebo sledováním bridgovací tabulky adresa-port). Nyní vyjme rámce z odesílacího bufferu 802.11 rozhraní, vymaže si klienta ze seznamu asociovaných klientů, rovněž odmaže záznam z bridgovací tabulky ukazující na tento 802.11 port a nakonec vyjmuté rámce pošle do bridgovací kódu. Ten buďto záznam nemá, a tak rámce odešle na obě strany (přičemž na rádiu budou zahozeny, protože tam už není klient naasociván), nebo záznam už má ukazující na drátové rozhraní, a tak budou rámce odeslány jenom tam.Toto je kompletne automaticky mechanizmus? Asi su tam nejake limity ohladne buffera a takisto casu. V pripade, ze sa klient uspesne reasocioval s inym AP, kolko casu zabere, pokym sa to prve ap od ktoreho sa disasocioval dozvie o nom, aby mu tie ramce z bufferu mohol poslat? Nebol by tomu dobre nejak pomoct? Napr. tak, ze by klient po reasociaci, pingol na prve ap aby sa zmenili ARP tabulky. V sieti, proste aby dal o sebe nejako vediet. Rozmyslal som o bezpecnosti v takychto sietach? Nastavit rovnake hesla na vsetky ap by asi nebol najstastnejsi napad. Napadol ma radius server, ale neviem kolko autentizacia zabere casu.
Toto je kompletne automaticky mechanizmus?
Jak vidíte, nic nikde nemusíte konfigurovat, sít si sama uvědomí, že klient je jinde a začne rámce směrovat na správné místo.
Asi su tam nejake limity ohladne buffera a takisto casu.
Samožejmě, buffer není neomezený. Když se zaplní, tak se nové pakety budou zahazovat. Rovněž existují časové limity na asociaci klienta, který se dlouho nezval. Tohle ale všechno jsou lokální záležitosti, které nemění princip směrování v síti. Mají pouze vliv na výkonnost sítě.
V pripade, ze sa klient uspesne reasocioval s inym AP, kolko casu zabere, pokym sa to prve ap od ktoreho sa disasocioval dozvie o nom, aby mu tie ramce z bufferu mohol poslat?
To záleží, jak je to udělané. V nejkratším prípadě je to doba nutná na dopravení jednoho rámce z nového AP na staré přes drátové rozhraní.
Nebol by tomu dobre nejak pomoct? Napr. tak, ze by klient po reasociaci, pingol na prve ap aby sa zmenili ARP tabulky. V sieti, proste aby dal o sebe nejako vediet.
Jistě, že je dobrý nápad. Nicméně to vyžaduje spolupráci od klienta, kterou standard nepožaduje. Proto je možná vhodnější (i když ne tak účinné) nechat udělat to nové AP. Stačí odeslat rámec se zdrojovou adresou klienta a všesmerovou cílovou adresou, čímž se aktualizují tabulky v celé síti.
Rozmyslal som o bezpecnosti v takychto sietach? Nastavit rovnake hesla na vsetky ap by asi nebol najstastnejsi napad. Napadol ma radius server, ale neviem kolko autentizacia zabere casu.
Proč by to bylo špatné. V okamžiku, kdy potřebujete mobilní klienty a celá síť je propojená na linkové vrstvě, tak nemá smysl, aby se některá AP chovala jinak.
Jinak radius se na tohle obvykle používá. A ano, 802.1x autentizace je pomalá. Proto se obvykle celá autentizace provádí jen při první asociaci a při reasociaci si AP stáhne klíče z autentizačního centra.
Po pravdě řečeno se zde používají tzv. lehká AP, která řeší jen věci přímo související s rádiovým přenosem a zbytek včetně šifrování se deleguje do centra přes drátovou síť.
Navíc výměnu klíčů lze urychlit spekulativním rozkopírováním klíčů mezi sousední AP, takže když klient přechází, tak už je vše připraveno a stačí případně provést standardní WPA rekeying (tedy dojednání nových klíčů za pomoci těch starých).
Mohli by ste mi prosim opisat tu reasociaciu krokovo?
Může to být tak, jak to popisujete (třeba CISCO si tak zjednodušuje život). Nicméně standard definuje služební rámec pro reasociaci, který zasílá klient novému AP, přičemž starému AP nic neoznamuje (např. rámcem pro disociaci). Je na AP, aby se mezi sebou o tom domluvila.
Např. ovladač hostap pro (dnes již historické) karty ZCOM XI-626 tyto informace vypisuje jak do jaderného logu, tak je lze najít v souborovém systému procNeviete konktetny subor v proc, pre hostap?
V adresáři /proc/net/hostap/NÁZEV_ROZHRANÍ jsou asociovaní klienti reprezentováni jako soubory, jejichž jméno je rovno jejich MAC adrese.
V logu pak připojení vypadí takto:
wifi0: 00:13:ce:61:b9:63 auth_cb - alg=0 trans#=2 status=0 - STA authenticated wifi0: 00:13:ce:61:b9:63 assoc_cb - STA associated
a odpojení pro nečinnost klienta takto:
wifi0: disassociation: 00:13:ce:61:b9:63 len=2, reason_code=1 wifi0: STA 00:13:ce:61:b9:63 did not ACK activity poll frame wifi0: sending disassociation info to STA 00:13:ce:61:b9:63(last=42782363, jiffies=42857613) wifi0: sending deauthentication info to STA 00:13:ce:61:b9:63(last=42782363, jiffies=42857863) wifi0: Could not find STA 00:13:ce:61:b9:63 for this TX error (@42857865)
Tiskni
Sdílej: