Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
ifconfig ath0 0.0.0.0 up
ifconfig ath1 0.0.0.0 up
ifconfig eth0 0.0.0.0 up
brctl addbr br0
brctl addif br0 ath0
brctl addbr br0 ath1
brctl addbr br0 eth0
ifconfig br0 1.2.3.4....
Pokud na to AP nemas pristup a potrebujes resit takovehle veci, tak se tak trochu nabizi otazka co je to za AP? Ze by nejake KFC nebo sousedovo ADSL?
Zdenek
Jo, taky jsem uz nekde cetl, ze MadWifi umi WDS (jako jeden z mala WiFi ovladacu ve svobodnem linuxu). Nicmene par veci se mi na WDS nelibi:
- pokud se tyce sifrovani, umi bezne jenom WEP (v nekterych implementacich udajne i WPA-PSK)
- pokud z toho vyplyne vice radiovych hopu na spolecnem kanale, tak s kazdym hopem spadne efektivni kapacita na polovinu, coz mi pro me pouziti vadi (pokud to potrebujete na jeden hop, tak je to kapacitne srovnatelne s AP/Client)
- smiseny provoz WDS+Client je opet k dispozici pouze v nekterych implementacich
Proste pro prakticke pouziti je WDS docela hnus. Oni ale ty "hnusne vlastnosti" plynou nejspis z principu - radiovy kanal je kolizni segment s Alohou, lepsi sifry jako WPA/WPA2 jsou point-to-point (takze s multihop WDS nejdou zkombinovat) apod.
Trochu s nadeji sleduju 802.11s mesh, ale spis mam strach, ze to nakonec bude stizeno obdobnym klubkem principialnich problemu, jako svazuje prave WDS. Navic je to zatim jenom draft, a linuxova implementace tohoto draftu zatim autentikaci natozpak sifrovani payloadu nijak neresi.
Pokud se tyce Vaseho pripadu, opravdu by to neslo routovat? Pokud na tom "klientskem" APcku nechcete rozjizdet plnohodnotny DHCP server, co treba jenom DHCP relay? Na treti vrstve uz by to zase bylo koser i s wifinou v obycejnem rezimu AP/Client.
MACky klientu (treba za switchem) byly vsechny videt i na APTo bych docela chtěl vidět... jak AP (bez WDS) vidělo za klienta (bez WDS), když klient posílá rámec jenom se třema MAC adresama, z nichž jedna je MAC AP, druhá MAC cílovýho stroje za AP. Nevěřim tomu.
kurviSpíš nemá ty dvě pozice v rámcích pro svoji MAC i MAC skutečného odesilatele. Takže bude umět obsloužit jen jednoho odesilatele přes svoji vlastní jedinou MAC adresu (případně naklonovanou MAC toho jediného odesílatele).
Problemy s timhle spojene jsou straslive. Napr. neni mozne za takovou wifi krabickou mit router.Tenhle nesmysl bereš kde? Router (jeden) tam samozřejmě být může. Má jednu MAC adresu na rozhraní k wifi klientovi, stejně jako jakýkoli jiný stroj. Směšuješ dvě vrstvy.
Zkousel jsi ten WRAP nastavit s bridgem a klientum na svem AP nastavit staticke IP adresy.Problém není s klientama, ale s tím, že za klientem může být několik zařízení s různými MAC. Statická nebo dynamická IP na tohle nejspíš nebude mít tak úplně vliv (i kdyby, switch to celé rozbije filtrováním MAC).
broadcasty tam litaj jak splasenyNelítaj. Neni důvod.
Vubec to primarni AP je dost zmagoreny ze ma vetsi mnozstvi IP adres se stejnou MAC adresou.Zrovna s tím nebude mít AP nejmenší problém. Zvlášť pokud se jedná o transparentní AP, které používá IP vrstvu jen na konfiguraci a rovnání času.
Tak si nejakej sezen. Dlink se asicouje na AP nekolikrat, za kazdou MACku prichazejici z ethernetu.MACky klientu (treba za switchem) byly vsechny videt i na APTo bych docela chtěl vidět... jak AP (bez WDS) vidělo za klienta (bez WDS), když klient posílá rámec jenom se třema MAC adresama, z nichž jedna je MAC AP, druhá MAC cílovýho stroje za AP. Nevěřim tomu.
Ze zkusenosti (edimax 5409APg + edimax BR6104K). Router s NATem tam byt muze, ale jak jsem NAT vypnul a nastavil bezne staticke routovani tak jsem si ani neskrtl. Do te doby jsem to s dlinky (dlink 900 + edimax BR6104K) pouzival bezne. Pak uz prisly na trh zarizeni s wifi a routerem v jednom.Problemy s timhle spojene jsou straslive. Napr. neni mozne za takovou wifi krabickou mit router.Tenhle nesmysl bereš kde? Router (jeden) tam samozřejmě být může. Má jednu MAC adresu na rozhraní k wifi klientovi, stejně jako jakýkoli jiný stroj. Směšuješ dvě vrstvy.
Mel jsem na mysli router, proste branu toho subnetu. AP samotne to vlastne byt nemusi, i kdyz vetsinou miva. ------ Osobne tuhle zrudnost povazuju za nejvetsi prusvih na wifine.Vubec to primarni AP je dost zmagoreny ze ma vetsi mnozstvi IP adres se stejnou MAC adresou.Zrovna s tím nebude mít AP nejmenší problém. Zvlášť pokud se jedná o transparentní AP, které používá IP vrstvu jen na konfiguraci a rovnání času.
Tak si nejakej sezen. Dlink se asicouje na AP nekolikrat, za kazdou MACku prichazejici z ethernetu.Jako odpověď stačí :). Shánět si to nepotřebuju. Vícenásobná asociace by leccos vysvětlovala, i když je to totální alchymie na jinak bezstavovym ethernetu. Docela by mě zajímalo, za jakých okolností ty asociace ruší, ale to už je vrtání se v nějakém konkrétním řešení. Good point, beru jako přínos do diskuze.
Ze zkusenosti (edimax 5409APg + edimax BR6104K). Router s NATem tam byt muze, ale jak jsem NAT vypnul a nastavil bezne staticke routovani tak jsem si ani neskrtl. Do te doby jsem to s dlinky (dlink 900 + edimax BR6104K) pouzival bezne. Pak uz prisly na trh zarizeni s wifi a routerem v jednom.Hádám na špatné nastavení IP vrstvy, tzn spíš konfigurační chybu než technické omezení.
Mel jsem na mysli router, proste branu toho subnetu. AP samotne to vlastne byt nemusi, i kdyz vetsinou miva.
Osobne tuhle zrudnost povazuju za nejvetsi prusvih na wifine.Mno... osobně považuju za největší zrůdnost směšování různých vrstev tam, kde k tomu není *velmi* dobrý důvod. Jediný problém v adresování wifi rámců vidím v tom tříadresovém formátu, který prostě nepočítal s bridgováním na klientské straně. Na druhou stranu vyhybání se bridgingu mezi wired a wireless celý problém řeší (pokud člověk zvládne nakonfigurovat routing).
Tiskni Sdílej: