CZFree Wiki - Příspěvky uživatele [cs]

Workshop IPTV-VOIP-WiFi

2010-01-01T19:11:50Z

Dulik:

=Motivace=
*Na [http://www.nfx.cz/zapisy/13/ 13. VH NFX 12.12.2009] byl odsouhlasen vznik NFX operátora - FreeTel, s.r.o. S využitím tohoto subjektu můžeme realizovat projekty, pro které legislativa ČR vyžaduje statut podnikatelského subjektu - zejména v oblasti IPTV a VOIP. Jedním z cílů tohoto workshopu je tyto projekty nadefinovat a rozjet
*Na 13. VH NFX bylo velmi málo času k diskusím o fungování a financování pracovní skupiny Výzkum a Vývoj (VaV). Diskuse bude proto pokračovat na tomto workshopu. Předtím proběhne krátká prezentace aktuálního stavu jednotlivých projektů.

=Čas a místo konání=
*Na 13. VH NFX bylo odhlasováno datum 23.1.2010 - tj. týden před vysvědčením (a [http://www.e-dovolena.cz/clanky/jarni-prazdniny-2010-terminy-595.html jarními prázdninami v některých krajích])
*Sdružení Bubakov.net se vzápětí nabídlo, že seminář připraví na své půdě, takže předpokládané místo konání je
[http://www.mapy.cz/#mm=ZP@sa=s@st=s@ssq=havl%C3%AD%C4%8Dkova%201155,%20nov%C3%A9%20stra%C5%A1ec%C3%AD@sss=1@ssp=131876864_136199584_131887232_136208432@x=131881114@y=136203428@z=16 Klubovna O.s. Bubakov.net] (Havlíčkova 1155, Nové Strašecí)
*Předpokládaný čas začátku: 10:00 (dle vašich požadavků je možno změnit)

=Program=
'''1) sezení pracovní skupiny IPTV''' celkem asi tři hodiny
*1a) start 1. fáze (=neplacené TV), czela/evkanet, server v Sitelu
*1b) ValXdater hodinka a půl povídání
*1c) návrh pro statutáry na start 2. fáze (placené TV), licence
'''2) sezení pracovní skupiny VOIP''' asi tři hodiny
*2a) aktuální stav registrace FreeTel s.r.o.
*2b) koncepce a zásady fungování operátora
*2c) financování činnosti operátora, obchodní plán
'''3) sezení pracovní skupiny Výzkum a vývoj'''
*8an-ův report - co nového ve vývoji, jaké jsou plány na další období
*financování a koncepce činnosti skupiny

=Registrace=
{| border="1"
!Nr. !! Jméno/user !! email !! Organizace !! Příjezd !! Odjezd !! Nocleh !! Požadavky na jídlo !! Počet volných míst v autě !! Poznámka
|-
|1.||[[user:Dulik|Tomáš Dulík]] || dulik@unart.cz || O. s. UnArt || ještě nevím || ještě nevím || ještě nevím || klidně nějaká pizza na místě, ať se zbytečně nezdržujeme || ještě nevím ||
|-
|}

[[Kategorie:Workshops]][[Kategorie:VAV]][[Kategorie:IPTV]][[Kategorie:VOIP]]

Workshop IPTV-VOIP-WiFi

2009-12-31T18:02:45Z

Dulik: Založena nová stránka: =Motivace= *Na [http://www.nfx.cz/zapisy/13/ 13. VH NFX 12.12.2009] byl odsouhlasen vznik NFX operátora - FreeTel, s.r.o. S využitím tohoto subjektu můžeme realizovat …

=Motivace=
*Na [http://www.nfx.cz/zapisy/13/ 13. VH NFX 12.12.2009] byl odsouhlasen vznik NFX operátora - FreeTel, s.r.o. S využitím tohoto subjektu můžeme realizovat projekty, pro které legislativa ČR vyžaduje statut podnikatelského subjektu - zejména v oblasti IPTV a VOIP. Jedním z cílů tohoto workshopu je tyto projekty nadefinovat a rozjet
*Na 13. VH NFX bylo velmi málo času k diskusím o fungování a financování pracovní skupiny Výzkum a Vývoj (VaV). Diskuse bude proto pokračovat na tomto workshopu. Předtím proběhne krátká prezentace aktuálního stavu jednotlivých projektů.

=Čas a místo konání=
*Na 13. VH NFX bylo odhlasováno datum 23.1.2009 - tj. týden před vysvědčením (a [http://www.e-dovolena.cz/clanky/jarni-prazdniny-2010-terminy-595.html jarními prázdninami v některých krajích])
*Sdružení Bubakov.net se vzápětí nabídlo, že seminář připraví na své půdě, takže předpokládané místo konání je
[http://www.mapy.cz/#mm=ZP@sa=s@st=s@ssq=havl%C3%AD%C4%8Dkova%201155,%20nov%C3%A9%20stra%C5%A1ec%C3%AD@sss=1@ssp=131876864_136199584_131887232_136208432@x=131881114@y=136203428@z=16 Klubovna O.s. Bubakov.net] (Havlíčkova 1155, Nové Strašecí)
*Předpokládaný čas začátku: 10:00 (dle vašich požadavků je možno změnit)

=Program=
'''1) sezení pracovní skupiny IPTV''' celkem asi tři hodiny
*1a) start 1. fáze (=neplacené TV), czela/evkanet, server v Sitelu
*1b) ValXdater hodinka a půl povídání
*1c) návrh pro statutáry na start 2. fáze (placené TV), licence
'''2) sezení pracovní skupiny VOIP''' asi tři hodiny
*2a) aktuální stav registrace FreeTel s.r.o.
*2b) koncepce a zásady fungování operátora
*2c) financování činnosti operátora, obchodní plán
'''3) sezení pracovní skupiny Výzkum a vývoj'''
*8an-ův report - co nového ve vývoji, jaké jsou plány na další období
*financování a koncepce činnosti skupiny

=Registrace=
{| border="1"
!Nr. !! Jméno/user !! email !! Organizace !! Příjezd !! Odjezd !! Nocleh !! Požadavky na jídlo !! Počet volných míst v autě !! Poznámka
|-
|1.||[[user:Dulik|Tomáš Dulík]] || dulik@unart.cz || O. s. UnArt || ještě nevím || ještě nevím || ještě nevím || klidně nějaká pizza na místě, ať se zbytečně nezdržujeme || ještě nevím ||
|-
|}

[[Kategorie:Workshops]][[Kategorie:VAV]][[Kategorie:IPTV]][[Kategorie:VOIP]]

CZFROAM

2009-09-25T12:26:24Z

Dulik: /* CAPWAP */

=Management summary=
CZFROAM je projekt jednotné Autentizační a Autorizační Infrastruktury (AAI) pro CZFree sítě.
Je inspirován projekty Eduroam a Edugain, které umožňují studentům používat zdarma počítačové sítě a aplikace vzdělávacích institucí po celé Evropě.

Co tento projekt přináší zapojeným sítím:
*možnost připojit se k plnohodnotnému rychlému internetu '''kdekoli''' v rámci vlastní sítě a také kdekoli v rámci sítí dalších sdružení, zapojených do projektu. Zapojená sdružení tím pro své členy získají výhodu rychlého připojení s roamingem, kterou v ČR poskytují pouze mobilní operátoři (TMobile/O2/Vodafone a jejich 3G zatím jen ve velkých městech, Ufon i v menších), ostatní operátoři (poskytovatelé ADSL/kabelovek/bezdrátů) nic podobného nemají.
*silné zabezpečení vlastních wifi sítí s centralizovanou správou oprávnění k použití sítě a jejích aplikací

=Garanti projektu=
*[http://www.unart.cz O. s. UnArt]
**zástupce: [[user:Dulik|Dulik]]
**schválení účasti v projektu Správní radou: ([http://vyuka.slfree.net/mod/forum/discuss.php?d=701 v řešení])
*[http://www.jmnet.cz O. s. JM-Net]
**zástupce: [[user:Jakubl|Jakubl]]
**schválení účasti v projektu Správní radou: schváleno

=Základní požadavky na celý systém=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Roaming vs. vrstvy L1 - L3 =
Realizace roamingu je mnohem zapeklitější než než běžné "pevné" připojení k WiFi.
*Problémy L1/L2 vs. roaming jsou [http://czfree.net/forum/showthread.php?postid=218249#post218249 zde] a [http://czfree.net/forum/showthread.php?postid=218078#post218078 zde].

Možné řešení - CapWap..
==Access Controller - CAPWAP==
Článek o OpenCapwap [http://zamestnanci.fai.utb.cz/~dulik/unart/OpenCapwap.pdf je zde].

=Zabezpečení=

==Certifikáty==
Certifikáty jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX. Je potřeba ale zjistit cenové podmínky a dle nich nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===

Nejdříve nastavíme radius:

Položka v menu: radius
+
Service (dle sítě, při Wi-Fi wireless)
Address: adresa radius serveru
Secret: heslo
Auth. port: obvykle 1812
Accounting Port: 1813
Timeout: 10 000 ms
Zapamatovat ID (dle # v listu)

Wireless ->

záložka security profiles
+
Name: eduroam
Mode: dynamic keys
Authentification types: zaškrtnout pouze WPA EAP a WPA2 EAP
Unicast Ciphers: tkip a aes ccm zaškrtnout
Group Ciphers: tkip a aes ccm zaškrtnout
Supplicant Identify: {ID} DLE # V LISTU

Záložka RADIUS
MAC Mode: as username as password

záložka interfaces -> + virtual AP

Záložka wireless

SSID: eduroam
Master interface: 2,4 ci 5 GHz sektor/všesměr
Security Profile: eduroam

Hotovo :) a ještě pak ip adresy apod., ale to je na Vás.

==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

=Právní a organizační náležitosti (dohody, smlouvy...)=

Eduroam má toto vše pěkně definováno v dokumentu "[http://www.eduroam.cz/doku.php?id=cs:roamingova_politika Roamingová politika]".

Ath5k

2009-09-25T03:16:07Z

Dulik: /* Cíle projektu */

Toto je kopie textu z wiki.nfx.cz
= Úvod =

Vývoj ovladače Madwifi byl ukončen, nelze čekat přidání podpory dalšího hardwaru, nanejvýš portování na nové verze kernelu. Kód se dostal do stavu, kdy je další vývoj v podstatě nemožný, uvědomují si to i jeho autoři. Ti proto od Madwifi utekli k ovladači Ath5k, který je součástí kernelu. Bohužel zatím není příliš stabilní, především v režimu AP (jsou problémy s beacony). O historii i současném stavu projektu Ath5k se můžete informovat v [http://iptv.klfree.cz/downloads/ath5k.mpeg prezentaci jednoho z hlavních vývojářů Ath5k - Jirky Slabého] (soubor má 1GB...), která proběhla na semináři NFX v červnu 2009.

= Cíl projektu =
Cílem tohoto našeho projektu je opravit chyby ovladače Ath5k, aby se dal používat na našich AP namísto Madwifi a začlenit tyto změny do kernelu, abychom si nemuseli udržovat vlastní větev (což by bylo náročnější než samotná oprava chyb).

Inspirovat se můžeme ovladačem Atheros ve FreeBSD, který

* funguje bez problémů
* od verze 7.2 je i kompletně open-source (včetně HALu)
* od [http://svn.freebsd.org/viewvc/base?view=revision&revision=186904 ledna 2009] má [http://svn.freebsd.org/viewvc/base/head/sbin/ifconfig/ifconfig.8?r1=184057&r2=186904&pathrev=186904 základní podporu přístupové metody TDMA], která (kdyby byla dotažena do detailů) by vyřešila problém skrytých uzlů ve venkovních wifi sítích

= Finance =
Na 12. VH NFX (6.9.2009 ve Slavičíně) byl odsouhlasen následující rozpis příspěvků na tento projekt do konce roku 2009 (pozn. Dulik: rozpis částek je neveřejný, nemám explicitní svolení od jednotlivých sdružení ke zveřejňování jejich příspěvků)
* Klfree
* Unart
* Czf-praha
* Unhfree
* KHnet
* Bubakov.net

== Kontaktní osoby ==
Za výše uvedená sdružení budou o směrování projektu rozhodovat následující garanti:
* KLFree: [[user:JaSt|Jast]] ?
* UnArt: [[user:Dulik|Dulik]]
* Czf-praha: [[user:8an|8an]] ?
* Unhfree: [[user:Litin|Litin]] ?
* Bubakov.net:

= Návrh harmonogramu prací =
Harmonogram vychází z toho, že pro začátek nemáme ani jeden měřící přístroj, který by umožňoval zobrazovat TX power a EVM vysílaných packetů pro každý packet zvlášť - viz odstavec „TX power“. Musíme proto začít vývoj tam, kde měření TX power nepotřebujeme – např. testováním & případnými úpravami modu „AP“.

== Administrativa ==
Co je potřeba udělat hned na začátku:
# Dulik: Napsat ostatním vývojářům ath5k, že NFX se rozhodlo podpořit vývoj ath5k vlastním fulltime vývojářem a poslat jim níže uvedený návrh oblastí, které chceme vylepšit. Hotovo, viz [https://lists.ath5k.org/pipermail/ath5k-devel/2009-September/002744.html mailing list ath5k].

== Testy/úpravy modu AP ==
ath5k, stejně jako další drivery založené na novém kernel API mac80211, nemá mód AP implementovaný přímo v sobě. Mod AP se tedy nerealizuje přímo na úrovni kernel driveru jako v Madwifi, ale na úrovni userspace démona [http://linuxwireless.org/en/users/Documentation/hostapd#About_hostapd hostapd], který přijímá a odesílá 802.11 control frames packety z interface nastaveného do monitor modu.

Ve srovnání s Madwifi je toto naprosto jiný přístup a dá se očekávat, že vše nebude fungovat tak, jak má.

Úvodní testy modu AP dělal 8an (prosím o doplnění, co funguje nebo nefunguje ...)

== TX power ==
Ath5k i Madwifi nastavují špatně vysílací výkon (TX power), který je nastavován zesílením výstupního zesilovače.

Každý typ karty má trochu jinak udělanou výstupní (TX) část, takže jednotlivé typy karet se od sebe dost liší charakteristikami TX komponent.

Protože vyšší data rates (např. 54MBit/s – 64QAM) mají mnohem vyšší nároky na linearitu výstupního zesilovače než nižší modulace (6Mbit/s – BPSK), je nutné TX power nastavovat před vysláním každého packetu podle data rate daného packetu.

TX power by měl být nastavován na hodnoty, doporučené výrobcem karty, které jsou uloženy v EEPROM(??) každé karty. Tyto hodnoty výrobce získá např. tak, že změří EVM svojí karty na jednotlivých bit rates v závislosti na nastaveném TX power, s tím, že pro každou bit rate zaznamená hodnotu TX power, při které EVM nepřekračuje meze definované daným standardem 802.11a/b/g.

Je možné, že někteří výrobci hodnoty v EEPROM neuvádějí správně (tj. nechce se jim měřit EVM), proto by ath5k měl umožňovat nastavit TX power pro každý bit rate ručně – tak, jak to umí Mikrotik (nebo se tak aspoň tváří). Popřípadě by alespoň mělo být možné do EEPROM nějaký nástrojem zapsat správné hodnoty.

Současný stav:

Z měření na spektráku FSV vyplynulo toto:

* ath5k (kernel 2.6.30 z debian unstable) vůbec nenastavuje vysílací výkon dle aktuálního data rate. Všechny packety jsou odesílány se stejným vysílacím výkonem, takže EVM u vyšších data rates pak překračuje povolené hodnoty
* Madwifi (poslední SVN verze) nastavuje vysílací výkon pro každý packet zvlášť, ale není jasné, jak – packety při pevně nastaveném bitrate a pevných vnějších podmínkách jsou vysílány s různými hodnotami TX power, následkem čehož EVM občas „vystřelí“ mimo povolené mezi. Pokud je toto implementace TPC, pak se chová dost podivně.
* Ath5k (Madwifi už si nepamatuju) neumí nastavit vysílací výkon u čipsetu AR5007 - příkaz „iwconfig athX txpower Y“ nemá vůbec žádný efekt. Přitom čipset AR5007 při měření vykazoval velmi pěkné výsledky, bylo by tedy dobré ho podporovat.

=== Implementace ===
Pro implementaci správného nastavování TX power je potřeba mít měřák, který umí změřit EVM a vysílací výkon pro každý packet zvlášť.

To je např. R&S FSV nebo možná i Agilent N4010A. Ani jeden z nich teď bohužel nemáme k dispozici.

== Ambient noise immunity - ANI ==
Karty Atheros mají přímo v HW implementováno "vylepšení" příjmu za přítomnosti šumu. Popis této funkce včetně kritiky všech problémů tohoto řešení [http://research.tid.es/domenic/images/computer_networks_giustiniano.pdf najdete zde]

Ve [http://madwifi-project.org/ticket/705 starém Madwifi] a v Mikrotiku je s nastavováním ANI spojen bug, který např. u karet CM9 způsobí, že karta v modu AP při jakémkoli rušení (i ve vedlejších kanálech) přestane téměř uplně vysílat.

Novější Madwifi mají v sobě pro mod AP patch, který ale způsobuje problém "Stuck beacon", tj. karta přestane vysílat beacony a tím se spojení rozpadne (AP "zmizí").

ath5k má podporu ANI na svém TODO listu s tím, že zatím se vlastnost ANI v ovladači vůbec neřeší.

Vývoj podpory ANI v ath5k jsme si vzali na starost my (za [https://lists.ath5k.org/pipermail/ath5k-devel/2009-September/002745.html nadšeného výskotu] ostatních vývojářů] ath5k).

== Ruční testování - podprojekt "měřící pracoviště" ==
Abychom vlastnosti "TX Power" a "ANI" neladili naslepo, je vysoce vhodné mít k dispozici měřáky, které teď bohužel nemáme.
A nemáme na ně ani peníze. Více v mailech.

== Automatické testování - podprojekt "WiFi pískoviště" ==

Vývojáři kernelové skupiny Linux Wireless mají na svých stránkách téma pro Google Summer of Code 2009: [http://linuxwireless.org/en/developers/GSoC Automation of testing using mac80211_hwsim and Orbit].

[http://www.orbit-lab.org/ Projekt Orbit] (tj. WiFi sandbox s více než 400 uzly) je super nápad, ale bohužel zaměřený jen na vnitřní wifi sítě.

Já navrhuji dotáhnout tento nápad ještě dál:
#do projektu "Databáze HW" přijímat pokud možno vždy 2 zařízení (pro možnost testování funkce příjmu & vysílání na jednom typu zařízení, což by mělo vždy fungovat nejlíp)
#zařízení nevracet hned, ale zapojovat je na delší dobu do našeho vlastního "pískoviště" (sandbox-u)
#náš sandbox nebude mít antény (jako projekt Orbit), ale jednotlivá zařízení budeme propojovat kabely, couplery, atenuátory (nejlépe programovatelnými), a RF switchi (nejlépe programovatelnými). Tím budeme schopni simulovat téměř jakoukoli topoligii a téměř jakékoli vnější podmínky, které se vyskytují v našich sítích - včetně efektů skrytých uzlů, multipath šíření (s použitím generátorů R&S nebo GNU radio), lokálních šumů, velkých zpoždění (speciální zařízení = "kilometrový koaxiál").
#jako diplomku zadat testovací SW, který pojede na některých uzlech tohoto pískoviště a bude testovat a měřit chování driveru za definovaných a opakovatelných podmínek.

Ath5k

2009-09-25T03:15:54Z

Dulik: /* Úvod */

Toto je kopie textu z wiki.nfx.cz
= Úvod =

Vývoj ovladače Madwifi byl ukončen, nelze čekat přidání podpory dalšího hardwaru, nanejvýš portování na nové verze kernelu. Kód se dostal do stavu, kdy je další vývoj v podstatě nemožný, uvědomují si to i jeho autoři. Ti proto od Madwifi utekli k ovladači Ath5k, který je součástí kernelu. Bohužel zatím není příliš stabilní, především v režimu AP (jsou problémy s beacony). O historii i současném stavu projektu Ath5k se můžete informovat v [http://iptv.klfree.cz/downloads/ath5k.mpeg prezentaci jednoho z hlavních vývojářů Ath5k - Jirky Slabého] (soubor má 1GB...), která proběhla na semináři NFX v červnu 2009.

= Cíle projektu =
Cílem tohoto našeho projektu je opravit chyby ovladače Ath5k, aby se dal používat na našich AP namísto Madwifi a začlenit tyto změny do kernelu, abychom si nemuseli udržovat vlastní větev (což by bylo náročnější než samotná oprava chyb).

Inspirovat se můžeme ovladačem Atheros ve FreeBSD, který

* funguje bez problémů
* od verze 7.2 je i kompletně open-source (včetně HALu)
* od [http://svn.freebsd.org/viewvc/base?view=revision&revision=186904 ledna 2009] má [http://svn.freebsd.org/viewvc/base/head/sbin/ifconfig/ifconfig.8?r1=184057&r2=186904&pathrev=186904 základní podporu přístupové metody TDMA], která (kdyby byla dotažena do detailů) by vyřešila problém skrytých uzlů ve venkovních wifi sítích

= Finance =
Na 12. VH NFX (6.9.2009 ve Slavičíně) byl odsouhlasen následující rozpis příspěvků na tento projekt do konce roku 2009 (pozn. Dulik: rozpis částek je neveřejný, nemám explicitní svolení od jednotlivých sdružení ke zveřejňování jejich příspěvků)
* Klfree
* Unart
* Czf-praha
* Unhfree
* KHnet
* Bubakov.net

== Kontaktní osoby ==
Za výše uvedená sdružení budou o směrování projektu rozhodovat následující garanti:
* KLFree: [[user:JaSt|Jast]] ?
* UnArt: [[user:Dulik|Dulik]]
* Czf-praha: [[user:8an|8an]] ?
* Unhfree: [[user:Litin|Litin]] ?
* Bubakov.net:

= Návrh harmonogramu prací =
Harmonogram vychází z toho, že pro začátek nemáme ani jeden měřící přístroj, který by umožňoval zobrazovat TX power a EVM vysílaných packetů pro každý packet zvlášť - viz odstavec „TX power“. Musíme proto začít vývoj tam, kde měření TX power nepotřebujeme – např. testováním & případnými úpravami modu „AP“.

== Administrativa ==
Co je potřeba udělat hned na začátku:
# Dulik: Napsat ostatním vývojářům ath5k, že NFX se rozhodlo podpořit vývoj ath5k vlastním fulltime vývojářem a poslat jim níže uvedený návrh oblastí, které chceme vylepšit. Hotovo, viz [https://lists.ath5k.org/pipermail/ath5k-devel/2009-September/002744.html mailing list ath5k].

== Testy/úpravy modu AP ==
ath5k, stejně jako další drivery založené na novém kernel API mac80211, nemá mód AP implementovaný přímo v sobě. Mod AP se tedy nerealizuje přímo na úrovni kernel driveru jako v Madwifi, ale na úrovni userspace démona [http://linuxwireless.org/en/users/Documentation/hostapd#About_hostapd hostapd], který přijímá a odesílá 802.11 control frames packety z interface nastaveného do monitor modu.

Ve srovnání s Madwifi je toto naprosto jiný přístup a dá se očekávat, že vše nebude fungovat tak, jak má.

Úvodní testy modu AP dělal 8an (prosím o doplnění, co funguje nebo nefunguje ...)

== TX power ==
Ath5k i Madwifi nastavují špatně vysílací výkon (TX power), který je nastavován zesílením výstupního zesilovače.

Každý typ karty má trochu jinak udělanou výstupní (TX) část, takže jednotlivé typy karet se od sebe dost liší charakteristikami TX komponent.

Protože vyšší data rates (např. 54MBit/s – 64QAM) mají mnohem vyšší nároky na linearitu výstupního zesilovače než nižší modulace (6Mbit/s – BPSK), je nutné TX power nastavovat před vysláním každého packetu podle data rate daného packetu.

TX power by měl být nastavován na hodnoty, doporučené výrobcem karty, které jsou uloženy v EEPROM(??) každé karty. Tyto hodnoty výrobce získá např. tak, že změří EVM svojí karty na jednotlivých bit rates v závislosti na nastaveném TX power, s tím, že pro každou bit rate zaznamená hodnotu TX power, při které EVM nepřekračuje meze definované daným standardem 802.11a/b/g.

Je možné, že někteří výrobci hodnoty v EEPROM neuvádějí správně (tj. nechce se jim měřit EVM), proto by ath5k měl umožňovat nastavit TX power pro každý bit rate ručně – tak, jak to umí Mikrotik (nebo se tak aspoň tváří). Popřípadě by alespoň mělo být možné do EEPROM nějaký nástrojem zapsat správné hodnoty.

Současný stav:

Z měření na spektráku FSV vyplynulo toto:

* ath5k (kernel 2.6.30 z debian unstable) vůbec nenastavuje vysílací výkon dle aktuálního data rate. Všechny packety jsou odesílány se stejným vysílacím výkonem, takže EVM u vyšších data rates pak překračuje povolené hodnoty
* Madwifi (poslední SVN verze) nastavuje vysílací výkon pro každý packet zvlášť, ale není jasné, jak – packety při pevně nastaveném bitrate a pevných vnějších podmínkách jsou vysílány s různými hodnotami TX power, následkem čehož EVM občas „vystřelí“ mimo povolené mezi. Pokud je toto implementace TPC, pak se chová dost podivně.
* Ath5k (Madwifi už si nepamatuju) neumí nastavit vysílací výkon u čipsetu AR5007 - příkaz „iwconfig athX txpower Y“ nemá vůbec žádný efekt. Přitom čipset AR5007 při měření vykazoval velmi pěkné výsledky, bylo by tedy dobré ho podporovat.

=== Implementace ===
Pro implementaci správného nastavování TX power je potřeba mít měřák, který umí změřit EVM a vysílací výkon pro každý packet zvlášť.

To je např. R&S FSV nebo možná i Agilent N4010A. Ani jeden z nich teď bohužel nemáme k dispozici.

== Ambient noise immunity - ANI ==
Karty Atheros mají přímo v HW implementováno "vylepšení" příjmu za přítomnosti šumu. Popis této funkce včetně kritiky všech problémů tohoto řešení [http://research.tid.es/domenic/images/computer_networks_giustiniano.pdf najdete zde]

Ve [http://madwifi-project.org/ticket/705 starém Madwifi] a v Mikrotiku je s nastavováním ANI spojen bug, který např. u karet CM9 způsobí, že karta v modu AP při jakémkoli rušení (i ve vedlejších kanálech) přestane téměř uplně vysílat.

Novější Madwifi mají v sobě pro mod AP patch, který ale způsobuje problém "Stuck beacon", tj. karta přestane vysílat beacony a tím se spojení rozpadne (AP "zmizí").

ath5k má podporu ANI na svém TODO listu s tím, že zatím se vlastnost ANI v ovladači vůbec neřeší.

Vývoj podpory ANI v ath5k jsme si vzali na starost my (za [https://lists.ath5k.org/pipermail/ath5k-devel/2009-September/002745.html nadšeného výskotu] ostatních vývojářů] ath5k).

== Ruční testování - podprojekt "měřící pracoviště" ==
Abychom vlastnosti "TX Power" a "ANI" neladili naslepo, je vysoce vhodné mít k dispozici měřáky, které teď bohužel nemáme.
A nemáme na ně ani peníze. Více v mailech.

== Automatické testování - podprojekt "WiFi pískoviště" ==

Vývojáři kernelové skupiny Linux Wireless mají na svých stránkách téma pro Google Summer of Code 2009: [http://linuxwireless.org/en/developers/GSoC Automation of testing using mac80211_hwsim and Orbit].

[http://www.orbit-lab.org/ Projekt Orbit] (tj. WiFi sandbox s více než 400 uzly) je super nápad, ale bohužel zaměřený jen na vnitřní wifi sítě.

Já navrhuji dotáhnout tento nápad ještě dál:
#do projektu "Databáze HW" přijímat pokud možno vždy 2 zařízení (pro možnost testování funkce příjmu & vysílání na jednom typu zařízení, což by mělo vždy fungovat nejlíp)
#zařízení nevracet hned, ale zapojovat je na delší dobu do našeho vlastního "pískoviště" (sandbox-u)
#náš sandbox nebude mít antény (jako projekt Orbit), ale jednotlivá zařízení budeme propojovat kabely, couplery, atenuátory (nejlépe programovatelnými), a RF switchi (nejlépe programovatelnými). Tím budeme schopni simulovat téměř jakoukoli topoligii a téměř jakékoli vnější podmínky, které se vyskytují v našich sítích - včetně efektů skrytých uzlů, multipath šíření (s použitím generátorů R&S nebo GNU radio), lokálních šumů, velkých zpoždění (speciální zařízení = "kilometrový koaxiál").
#jako diplomku zadat testovací SW, který pojede na některých uzlech tohoto pískoviště a bude testovat a měřit chování driveru za definovaných a opakovatelných podmínek.

Ath5k

2009-09-25T03:15:13Z

Dulik: /* Úvod */

Toto je kopie textu z wiki.nfx.cz
= Úvod =

Vývoj ovladače Madwifi byl ukončen, nelze čekat přidání podpory dalšího hardwaru, nanejvýš portování na nové verze kernelu. Kód se dostal do stavu, kdy je další vývoj v podstatě nemožný, uvědomují si to i jeho autoři. Ti proto od Madwifi utekli k ovladači Ath5k, který je součástí kernelu. Bohužel zatím není příliš stabilní, především v režimu AP (jsou problémy s beacony). O historii i současném stavu projektu Ath5k se můžete informovat v [http://iptv.klfree.cz/downloads/ath5k.mpeg prezentaci jednoho z hlavních vývojářů Ath5k - Jirky Slabého] (soubor má 1GB...), která proběhla na semináři NFX v červnu 2009.

Cílem tohoto našeho projektu je opravit chyby ovladače Ath5k, aby se dal používat na našich AP namísto Madwifi a začlenit tyto změny do kernelu, abychom si nemuseli udržovat vlastní větev (což by bylo náročnější než samotná oprava chyb).

Inspirovat se můžeme ovladačem Atheros ve FreeBSD, který

* funguje bez problémů
* od verze 7.2 je i kompletně open-source (včetně HALu)
* od [http://svn.freebsd.org/viewvc/base?view=revision&revision=186904 ledna 2009] má [http://svn.freebsd.org/viewvc/base/head/sbin/ifconfig/ifconfig.8?r1=184057&r2=186904&pathrev=186904 základní podporu přístupové metody TDMA], která (kdyby byla dotažena do detailů) by vyřešila problém skrytých uzlů ve venkovních wifi sítích

= Finance =
Na 12. VH NFX (6.9.2009 ve Slavičíně) byl odsouhlasen následující rozpis příspěvků na tento projekt do konce roku 2009 (pozn. Dulik: rozpis částek je neveřejný, nemám explicitní svolení od jednotlivých sdružení ke zveřejňování jejich příspěvků)
* Klfree
* Unart
* Czf-praha
* Unhfree
* KHnet
* Bubakov.net

== Kontaktní osoby ==
Za výše uvedená sdružení budou o směrování projektu rozhodovat následující garanti:
* KLFree: [[user:JaSt|Jast]] ?
* UnArt: [[user:Dulik|Dulik]]
* Czf-praha: [[user:8an|8an]] ?
* Unhfree: [[user:Litin|Litin]] ?
* Bubakov.net:

= Návrh harmonogramu prací =
Harmonogram vychází z toho, že pro začátek nemáme ani jeden měřící přístroj, který by umožňoval zobrazovat TX power a EVM vysílaných packetů pro každý packet zvlášť - viz odstavec „TX power“. Musíme proto začít vývoj tam, kde měření TX power nepotřebujeme – např. testováním & případnými úpravami modu „AP“.

== Administrativa ==
Co je potřeba udělat hned na začátku:
# Dulik: Napsat ostatním vývojářům ath5k, že NFX se rozhodlo podpořit vývoj ath5k vlastním fulltime vývojářem a poslat jim níže uvedený návrh oblastí, které chceme vylepšit. Hotovo, viz [https://lists.ath5k.org/pipermail/ath5k-devel/2009-September/002744.html mailing list ath5k].

== Testy/úpravy modu AP ==
ath5k, stejně jako další drivery založené na novém kernel API mac80211, nemá mód AP implementovaný přímo v sobě. Mod AP se tedy nerealizuje přímo na úrovni kernel driveru jako v Madwifi, ale na úrovni userspace démona [http://linuxwireless.org/en/users/Documentation/hostapd#About_hostapd hostapd], který přijímá a odesílá 802.11 control frames packety z interface nastaveného do monitor modu.

Ve srovnání s Madwifi je toto naprosto jiný přístup a dá se očekávat, že vše nebude fungovat tak, jak má.

Úvodní testy modu AP dělal 8an (prosím o doplnění, co funguje nebo nefunguje ...)

== TX power ==
Ath5k i Madwifi nastavují špatně vysílací výkon (TX power), který je nastavován zesílením výstupního zesilovače.

Každý typ karty má trochu jinak udělanou výstupní (TX) část, takže jednotlivé typy karet se od sebe dost liší charakteristikami TX komponent.

Protože vyšší data rates (např. 54MBit/s – 64QAM) mají mnohem vyšší nároky na linearitu výstupního zesilovače než nižší modulace (6Mbit/s – BPSK), je nutné TX power nastavovat před vysláním každého packetu podle data rate daného packetu.

TX power by měl být nastavován na hodnoty, doporučené výrobcem karty, které jsou uloženy v EEPROM(??) každé karty. Tyto hodnoty výrobce získá např. tak, že změří EVM svojí karty na jednotlivých bit rates v závislosti na nastaveném TX power, s tím, že pro každou bit rate zaznamená hodnotu TX power, při které EVM nepřekračuje meze definované daným standardem 802.11a/b/g.

Je možné, že někteří výrobci hodnoty v EEPROM neuvádějí správně (tj. nechce se jim měřit EVM), proto by ath5k měl umožňovat nastavit TX power pro každý bit rate ručně – tak, jak to umí Mikrotik (nebo se tak aspoň tváří). Popřípadě by alespoň mělo být možné do EEPROM nějaký nástrojem zapsat správné hodnoty.

Současný stav:

Z měření na spektráku FSV vyplynulo toto:

* ath5k (kernel 2.6.30 z debian unstable) vůbec nenastavuje vysílací výkon dle aktuálního data rate. Všechny packety jsou odesílány se stejným vysílacím výkonem, takže EVM u vyšších data rates pak překračuje povolené hodnoty
* Madwifi (poslední SVN verze) nastavuje vysílací výkon pro každý packet zvlášť, ale není jasné, jak – packety při pevně nastaveném bitrate a pevných vnějších podmínkách jsou vysílány s různými hodnotami TX power, následkem čehož EVM občas „vystřelí“ mimo povolené mezi. Pokud je toto implementace TPC, pak se chová dost podivně.
* Ath5k (Madwifi už si nepamatuju) neumí nastavit vysílací výkon u čipsetu AR5007 - příkaz „iwconfig athX txpower Y“ nemá vůbec žádný efekt. Přitom čipset AR5007 při měření vykazoval velmi pěkné výsledky, bylo by tedy dobré ho podporovat.

=== Implementace ===
Pro implementaci správného nastavování TX power je potřeba mít měřák, který umí změřit EVM a vysílací výkon pro každý packet zvlášť.

To je např. R&S FSV nebo možná i Agilent N4010A. Ani jeden z nich teď bohužel nemáme k dispozici.

== Ambient noise immunity - ANI ==
Karty Atheros mají přímo v HW implementováno "vylepšení" příjmu za přítomnosti šumu. Popis této funkce včetně kritiky všech problémů tohoto řešení [http://research.tid.es/domenic/images/computer_networks_giustiniano.pdf najdete zde]

Ve [http://madwifi-project.org/ticket/705 starém Madwifi] a v Mikrotiku je s nastavováním ANI spojen bug, který např. u karet CM9 způsobí, že karta v modu AP při jakémkoli rušení (i ve vedlejších kanálech) přestane téměř uplně vysílat.

Novější Madwifi mají v sobě pro mod AP patch, který ale způsobuje problém "Stuck beacon", tj. karta přestane vysílat beacony a tím se spojení rozpadne (AP "zmizí").

ath5k má podporu ANI na svém TODO listu s tím, že zatím se vlastnost ANI v ovladači vůbec neřeší.

Vývoj podpory ANI v ath5k jsme si vzali na starost my (za [https://lists.ath5k.org/pipermail/ath5k-devel/2009-September/002745.html nadšeného výskotu] ostatních vývojářů] ath5k).

== Ruční testování - podprojekt "měřící pracoviště" ==
Abychom vlastnosti "TX Power" a "ANI" neladili naslepo, je vysoce vhodné mít k dispozici měřáky, které teď bohužel nemáme.
A nemáme na ně ani peníze. Více v mailech.

== Automatické testování - podprojekt "WiFi pískoviště" ==

Vývojáři kernelové skupiny Linux Wireless mají na svých stránkách téma pro Google Summer of Code 2009: [http://linuxwireless.org/en/developers/GSoC Automation of testing using mac80211_hwsim and Orbit].

[http://www.orbit-lab.org/ Projekt Orbit] (tj. WiFi sandbox s více než 400 uzly) je super nápad, ale bohužel zaměřený jen na vnitřní wifi sítě.

Já navrhuji dotáhnout tento nápad ještě dál:
#do projektu "Databáze HW" přijímat pokud možno vždy 2 zařízení (pro možnost testování funkce příjmu & vysílání na jednom typu zařízení, což by mělo vždy fungovat nejlíp)
#zařízení nevracet hned, ale zapojovat je na delší dobu do našeho vlastního "pískoviště" (sandbox-u)
#náš sandbox nebude mít antény (jako projekt Orbit), ale jednotlivá zařízení budeme propojovat kabely, couplery, atenuátory (nejlépe programovatelnými), a RF switchi (nejlépe programovatelnými). Tím budeme schopni simulovat téměř jakoukoli topoligii a téměř jakékoli vnější podmínky, které se vyskytují v našich sítích - včetně efektů skrytých uzlů, multipath šíření (s použitím generátorů R&S nebo GNU radio), lokálních šumů, velkých zpoždění (speciální zařízení = "kilometrový koaxiál").
#jako diplomku zadat testovací SW, který pojede na některých uzlech tohoto pískoviště a bude testovat a měřit chování driveru za definovaných a opakovatelných podmínek.

Ath5k

2009-09-25T03:09:40Z

Dulik: /* Ambient noise immunity - ANI */

Toto je kopie textu z wiki.nfx.cz
= Úvod =

Vývoj ovladače Madwifi byl ukončen, nelze čekat přidání podpory dalšího hardwaru, nanejvýš portování na nové verze kernelu. Kód se dostal do stavu, kdy je další vývoj v podstatě nemožný, uvědomují si to i jeho autoři. Ti proto od Madwifi utekli k ovladači Ath5k, který je součástí kernelu. Bohužel zatím není příliš stabilní, především v režimu AP (jsou problémy s beacony).

Cílem tohoto projektu je opravit chyby ovladače Ath5k, aby se dal používat na našich AP namísto Madwifi a začlenit tyto změny do kernelu, abychom si nemuseli udržovat vlastní větev (což by bylo náročnější než samotná oprava chyb).

Inspirovat se můžeme ovladačem Atheros ve FreeBSD, který

* funguje bez problémů
* od verze 7.2 je i kompletně open-source (včetně HALu)
* od [http://svn.freebsd.org/viewvc/base?view=revision&revision=186904 ledna 2009] má [http://svn.freebsd.org/viewvc/base/head/sbin/ifconfig/ifconfig.8?r1=184057&r2=186904&pathrev=186904 základní podporu přístupové metody TDMA], která (kdyby byla dotažena do detailů) by vyřešila problém skrytých uzlů ve venkovních wifi sítích

= Finance =
Na 12. VH NFX (6.9.2009 ve Slavičíně) byl odsouhlasen následující rozpis příspěvků na tento projekt do konce roku 2009 (pozn. Dulik: rozpis částek je neveřejný, nemám explicitní svolení od jednotlivých sdružení ke zveřejňování jejich příspěvků)
* Klfree
* Unart
* Czf-praha
* Unhfree
* KHnet
* Bubakov.net

== Kontaktní osoby ==
Za výše uvedená sdružení budou o směrování projektu rozhodovat následující garanti:
* KLFree: [[user:JaSt|Jast]] ?
* UnArt: [[user:Dulik|Dulik]]
* Czf-praha: [[user:8an|8an]] ?
* Unhfree: [[user:Litin|Litin]] ?
* Bubakov.net:

= Návrh harmonogramu prací =
Harmonogram vychází z toho, že pro začátek nemáme ani jeden měřící přístroj, který by umožňoval zobrazovat TX power a EVM vysílaných packetů pro každý packet zvlášť - viz odstavec „TX power“. Musíme proto začít vývoj tam, kde měření TX power nepotřebujeme – např. testováním & případnými úpravami modu „AP“.

== Administrativa ==
Co je potřeba udělat hned na začátku:
# Dulik: Napsat ostatním vývojářům ath5k, že NFX se rozhodlo podpořit vývoj ath5k vlastním fulltime vývojářem a poslat jim níže uvedený návrh oblastí, které chceme vylepšit. Hotovo, viz [https://lists.ath5k.org/pipermail/ath5k-devel/2009-September/002744.html mailing list ath5k].

== Testy/úpravy modu AP ==
ath5k, stejně jako další drivery založené na novém kernel API mac80211, nemá mód AP implementovaný přímo v sobě. Mod AP se tedy nerealizuje přímo na úrovni kernel driveru jako v Madwifi, ale na úrovni userspace démona [http://linuxwireless.org/en/users/Documentation/hostapd#About_hostapd hostapd], který přijímá a odesílá 802.11 control frames packety z interface nastaveného do monitor modu.

Ve srovnání s Madwifi je toto naprosto jiný přístup a dá se očekávat, že vše nebude fungovat tak, jak má.

Úvodní testy modu AP dělal 8an (prosím o doplnění, co funguje nebo nefunguje ...)

== TX power ==
Ath5k i Madwifi nastavují špatně vysílací výkon (TX power), který je nastavován zesílením výstupního zesilovače.

Každý typ karty má trochu jinak udělanou výstupní (TX) část, takže jednotlivé typy karet se od sebe dost liší charakteristikami TX komponent.

Protože vyšší data rates (např. 54MBit/s – 64QAM) mají mnohem vyšší nároky na linearitu výstupního zesilovače než nižší modulace (6Mbit/s – BPSK), je nutné TX power nastavovat před vysláním každého packetu podle data rate daného packetu.

TX power by měl být nastavován na hodnoty, doporučené výrobcem karty, které jsou uloženy v EEPROM(??) každé karty. Tyto hodnoty výrobce získá např. tak, že změří EVM svojí karty na jednotlivých bit rates v závislosti na nastaveném TX power, s tím, že pro každou bit rate zaznamená hodnotu TX power, při které EVM nepřekračuje meze definované daným standardem 802.11a/b/g.

Je možné, že někteří výrobci hodnoty v EEPROM neuvádějí správně (tj. nechce se jim měřit EVM), proto by ath5k měl umožňovat nastavit TX power pro každý bit rate ručně – tak, jak to umí Mikrotik (nebo se tak aspoň tváří). Popřípadě by alespoň mělo být možné do EEPROM nějaký nástrojem zapsat správné hodnoty.

Současný stav:

Z měření na spektráku FSV vyplynulo toto:

* ath5k (kernel 2.6.30 z debian unstable) vůbec nenastavuje vysílací výkon dle aktuálního data rate. Všechny packety jsou odesílány se stejným vysílacím výkonem, takže EVM u vyšších data rates pak překračuje povolené hodnoty
* Madwifi (poslední SVN verze) nastavuje vysílací výkon pro každý packet zvlášť, ale není jasné, jak – packety při pevně nastaveném bitrate a pevných vnějších podmínkách jsou vysílány s různými hodnotami TX power, následkem čehož EVM občas „vystřelí“ mimo povolené mezi. Pokud je toto implementace TPC, pak se chová dost podivně.
* Ath5k (Madwifi už si nepamatuju) neumí nastavit vysílací výkon u čipsetu AR5007 - příkaz „iwconfig athX txpower Y“ nemá vůbec žádný efekt. Přitom čipset AR5007 při měření vykazoval velmi pěkné výsledky, bylo by tedy dobré ho podporovat.

=== Implementace ===
Pro implementaci správného nastavování TX power je potřeba mít měřák, který umí změřit EVM a vysílací výkon pro každý packet zvlášť.

To je např. R&S FSV nebo možná i Agilent N4010A. Ani jeden z nich teď bohužel nemáme k dispozici.

== Ambient noise immunity - ANI ==
Karty Atheros mají přímo v HW implementováno "vylepšení" příjmu za přítomnosti šumu. Popis této funkce včetně kritiky všech problémů tohoto řešení [http://research.tid.es/domenic/images/computer_networks_giustiniano.pdf najdete zde]

Ve [http://madwifi-project.org/ticket/705 starém Madwifi] a v Mikrotiku je s nastavováním ANI spojen bug, který např. u karet CM9 způsobí, že karta v modu AP při jakémkoli rušení (i ve vedlejších kanálech) přestane téměř uplně vysílat.

Novější Madwifi mají v sobě pro mod AP patch, který ale způsobuje problém "Stuck beacon", tj. karta přestane vysílat beacony a tím se spojení rozpadne (AP "zmizí").

ath5k má podporu ANI na svém TODO listu s tím, že zatím se vlastnost ANI v ovladači vůbec neřeší.

Vývoj podpory ANI v ath5k jsme si vzali na starost my (za [https://lists.ath5k.org/pipermail/ath5k-devel/2009-September/002745.html nadšeného výskotu] ostatních vývojářů] ath5k).

== Ruční testování - podprojekt "měřící pracoviště" ==
Abychom vlastnosti "TX Power" a "ANI" neladili naslepo, je vysoce vhodné mít k dispozici měřáky, které teď bohužel nemáme.
A nemáme na ně ani peníze. Více v mailech.

== Automatické testování - podprojekt "WiFi pískoviště" ==

Vývojáři kernelové skupiny Linux Wireless mají na svých stránkách téma pro Google Summer of Code 2009: [http://linuxwireless.org/en/developers/GSoC Automation of testing using mac80211_hwsim and Orbit].

[http://www.orbit-lab.org/ Projekt Orbit] (tj. WiFi sandbox s více než 400 uzly) je super nápad, ale bohužel zaměřený jen na vnitřní wifi sítě.

Já navrhuji dotáhnout tento nápad ještě dál:
#do projektu "Databáze HW" přijímat pokud možno vždy 2 zařízení (pro možnost testování funkce příjmu & vysílání na jednom typu zařízení, což by mělo vždy fungovat nejlíp)
#zařízení nevracet hned, ale zapojovat je na delší dobu do našeho vlastního "pískoviště" (sandbox-u)
#náš sandbox nebude mít antény (jako projekt Orbit), ale jednotlivá zařízení budeme propojovat kabely, couplery, atenuátory (nejlépe programovatelnými), a RF switchi (nejlépe programovatelnými). Tím budeme schopni simulovat téměř jakoukoli topoligii a téměř jakékoli vnější podmínky, které se vyskytují v našich sítích - včetně efektů skrytých uzlů, multipath šíření (s použitím generátorů R&S nebo GNU radio), lokálních šumů, velkých zpoždění (speciální zařízení = "kilometrový koaxiál").
#jako diplomku zadat testovací SW, který pojede na některých uzlech tohoto pískoviště a bude testovat a měřit chování driveru za definovaných a opakovatelných podmínek.

Ath5k

2009-09-25T03:09:17Z

Dulik: /* Ambient noise immunity - ANI */

Toto je kopie textu z wiki.nfx.cz
= Úvod =

Vývoj ovladače Madwifi byl ukončen, nelze čekat přidání podpory dalšího hardwaru, nanejvýš portování na nové verze kernelu. Kód se dostal do stavu, kdy je další vývoj v podstatě nemožný, uvědomují si to i jeho autoři. Ti proto od Madwifi utekli k ovladači Ath5k, který je součástí kernelu. Bohužel zatím není příliš stabilní, především v režimu AP (jsou problémy s beacony).

Cílem tohoto projektu je opravit chyby ovladače Ath5k, aby se dal používat na našich AP namísto Madwifi a začlenit tyto změny do kernelu, abychom si nemuseli udržovat vlastní větev (což by bylo náročnější než samotná oprava chyb).

Inspirovat se můžeme ovladačem Atheros ve FreeBSD, který

* funguje bez problémů
* od verze 7.2 je i kompletně open-source (včetně HALu)
* od [http://svn.freebsd.org/viewvc/base?view=revision&revision=186904 ledna 2009] má [http://svn.freebsd.org/viewvc/base/head/sbin/ifconfig/ifconfig.8?r1=184057&r2=186904&pathrev=186904 základní podporu přístupové metody TDMA], která (kdyby byla dotažena do detailů) by vyřešila problém skrytých uzlů ve venkovních wifi sítích

= Finance =
Na 12. VH NFX (6.9.2009 ve Slavičíně) byl odsouhlasen následující rozpis příspěvků na tento projekt do konce roku 2009 (pozn. Dulik: rozpis částek je neveřejný, nemám explicitní svolení od jednotlivých sdružení ke zveřejňování jejich příspěvků)
* Klfree
* Unart
* Czf-praha
* Unhfree
* KHnet
* Bubakov.net

== Kontaktní osoby ==
Za výše uvedená sdružení budou o směrování projektu rozhodovat následující garanti:
* KLFree: [[user:JaSt|Jast]] ?
* UnArt: [[user:Dulik|Dulik]]
* Czf-praha: [[user:8an|8an]] ?
* Unhfree: [[user:Litin|Litin]] ?
* Bubakov.net:

= Návrh harmonogramu prací =
Harmonogram vychází z toho, že pro začátek nemáme ani jeden měřící přístroj, který by umožňoval zobrazovat TX power a EVM vysílaných packetů pro každý packet zvlášť - viz odstavec „TX power“. Musíme proto začít vývoj tam, kde měření TX power nepotřebujeme – např. testováním & případnými úpravami modu „AP“.

== Administrativa ==
Co je potřeba udělat hned na začátku:
# Dulik: Napsat ostatním vývojářům ath5k, že NFX se rozhodlo podpořit vývoj ath5k vlastním fulltime vývojářem a poslat jim níže uvedený návrh oblastí, které chceme vylepšit. Hotovo, viz [https://lists.ath5k.org/pipermail/ath5k-devel/2009-September/002744.html mailing list ath5k].

== Testy/úpravy modu AP ==
ath5k, stejně jako další drivery založené na novém kernel API mac80211, nemá mód AP implementovaný přímo v sobě. Mod AP se tedy nerealizuje přímo na úrovni kernel driveru jako v Madwifi, ale na úrovni userspace démona [http://linuxwireless.org/en/users/Documentation/hostapd#About_hostapd hostapd], který přijímá a odesílá 802.11 control frames packety z interface nastaveného do monitor modu.

Ve srovnání s Madwifi je toto naprosto jiný přístup a dá se očekávat, že vše nebude fungovat tak, jak má.

Úvodní testy modu AP dělal 8an (prosím o doplnění, co funguje nebo nefunguje ...)

== TX power ==
Ath5k i Madwifi nastavují špatně vysílací výkon (TX power), který je nastavován zesílením výstupního zesilovače.

Každý typ karty má trochu jinak udělanou výstupní (TX) část, takže jednotlivé typy karet se od sebe dost liší charakteristikami TX komponent.

Protože vyšší data rates (např. 54MBit/s – 64QAM) mají mnohem vyšší nároky na linearitu výstupního zesilovače než nižší modulace (6Mbit/s – BPSK), je nutné TX power nastavovat před vysláním každého packetu podle data rate daného packetu.

TX power by měl být nastavován na hodnoty, doporučené výrobcem karty, které jsou uloženy v EEPROM(??) každé karty. Tyto hodnoty výrobce získá např. tak, že změří EVM svojí karty na jednotlivých bit rates v závislosti na nastaveném TX power, s tím, že pro každou bit rate zaznamená hodnotu TX power, při které EVM nepřekračuje meze definované daným standardem 802.11a/b/g.

Je možné, že někteří výrobci hodnoty v EEPROM neuvádějí správně (tj. nechce se jim měřit EVM), proto by ath5k měl umožňovat nastavit TX power pro každý bit rate ručně – tak, jak to umí Mikrotik (nebo se tak aspoň tváří). Popřípadě by alespoň mělo být možné do EEPROM nějaký nástrojem zapsat správné hodnoty.

Současný stav:

Z měření na spektráku FSV vyplynulo toto:

* ath5k (kernel 2.6.30 z debian unstable) vůbec nenastavuje vysílací výkon dle aktuálního data rate. Všechny packety jsou odesílány se stejným vysílacím výkonem, takže EVM u vyšších data rates pak překračuje povolené hodnoty
* Madwifi (poslední SVN verze) nastavuje vysílací výkon pro každý packet zvlášť, ale není jasné, jak – packety při pevně nastaveném bitrate a pevných vnějších podmínkách jsou vysílány s různými hodnotami TX power, následkem čehož EVM občas „vystřelí“ mimo povolené mezi. Pokud je toto implementace TPC, pak se chová dost podivně.
* Ath5k (Madwifi už si nepamatuju) neumí nastavit vysílací výkon u čipsetu AR5007 - příkaz „iwconfig athX txpower Y“ nemá vůbec žádný efekt. Přitom čipset AR5007 při měření vykazoval velmi pěkné výsledky, bylo by tedy dobré ho podporovat.

=== Implementace ===
Pro implementaci správného nastavování TX power je potřeba mít měřák, který umí změřit EVM a vysílací výkon pro každý packet zvlášť.

To je např. R&S FSV nebo možná i Agilent N4010A. Ani jeden z nich teď bohužel nemáme k dispozici.

== Ambient noise immunity - ANI ==
Karty Atheros mají přímo v HW implementováno "vylepšení" příjmu za přítomnosti šumu. Popis této funkce včetně kritiky všech problémů tohoto řešení [http://research.tid.es/domenic/images/computer_networks_giustiniano.pdf najdete zde]

Ve [http://madwifi-project.org/ticket/705 starém Madwifi] a v Mikrotiku je s nastavováním ANI spojen bug, který např. u karet CM9 způsobí, že karta v modu AP při jakémkoli rušení (i ve vedlejších kanálech) přestane téměř uplně vysílat.

Novější Madwifi mají v sobě pro mod AP patch, který ale způsobuje problém "Stuck beacon", tj. karta přestane vysílat beacony a tím se spojení rozpadne (AP "zmizí").

ath5k má podporu ANI na svém TODO listu s tím, že zatím se vlastnost ANI v ovladači vůbec neřeší.

Vývoj podpory ANI v ath5k jsme si vzali na starost my (za [https://lists.ath5k.org/pipermail/ath5k-devel/2009-September/002745.html]nadšeného výskotu ostatních vývojářů] ath5k).

== Ruční testování - podprojekt "měřící pracoviště" ==
Abychom vlastnosti "TX Power" a "ANI" neladili naslepo, je vysoce vhodné mít k dispozici měřáky, které teď bohužel nemáme.
A nemáme na ně ani peníze. Více v mailech.

== Automatické testování - podprojekt "WiFi pískoviště" ==

Vývojáři kernelové skupiny Linux Wireless mají na svých stránkách téma pro Google Summer of Code 2009: [http://linuxwireless.org/en/developers/GSoC Automation of testing using mac80211_hwsim and Orbit].

[http://www.orbit-lab.org/ Projekt Orbit] (tj. WiFi sandbox s více než 400 uzly) je super nápad, ale bohužel zaměřený jen na vnitřní wifi sítě.

Já navrhuji dotáhnout tento nápad ještě dál:
#do projektu "Databáze HW" přijímat pokud možno vždy 2 zařízení (pro možnost testování funkce příjmu & vysílání na jednom typu zařízení, což by mělo vždy fungovat nejlíp)
#zařízení nevracet hned, ale zapojovat je na delší dobu do našeho vlastního "pískoviště" (sandbox-u)
#náš sandbox nebude mít antény (jako projekt Orbit), ale jednotlivá zařízení budeme propojovat kabely, couplery, atenuátory (nejlépe programovatelnými), a RF switchi (nejlépe programovatelnými). Tím budeme schopni simulovat téměř jakoukoli topoligii a téměř jakékoli vnější podmínky, které se vyskytují v našich sítích - včetně efektů skrytých uzlů, multipath šíření (s použitím generátorů R&S nebo GNU radio), lokálních šumů, velkých zpoždění (speciální zařízení = "kilometrový koaxiál").
#jako diplomku zadat testovací SW, který pojede na některých uzlech tohoto pískoviště a bude testovat a měřit chování driveru za definovaných a opakovatelných podmínek.

Ath5k

2009-09-25T03:08:50Z

Dulik: /* Ambient noise immunity - ANI */

Toto je kopie textu z wiki.nfx.cz
= Úvod =

Vývoj ovladače Madwifi byl ukončen, nelze čekat přidání podpory dalšího hardwaru, nanejvýš portování na nové verze kernelu. Kód se dostal do stavu, kdy je další vývoj v podstatě nemožný, uvědomují si to i jeho autoři. Ti proto od Madwifi utekli k ovladači Ath5k, který je součástí kernelu. Bohužel zatím není příliš stabilní, především v režimu AP (jsou problémy s beacony).

Cílem tohoto projektu je opravit chyby ovladače Ath5k, aby se dal používat na našich AP namísto Madwifi a začlenit tyto změny do kernelu, abychom si nemuseli udržovat vlastní větev (což by bylo náročnější než samotná oprava chyb).

Inspirovat se můžeme ovladačem Atheros ve FreeBSD, který

* funguje bez problémů
* od verze 7.2 je i kompletně open-source (včetně HALu)
* od [http://svn.freebsd.org/viewvc/base?view=revision&revision=186904 ledna 2009] má [http://svn.freebsd.org/viewvc/base/head/sbin/ifconfig/ifconfig.8?r1=184057&r2=186904&pathrev=186904 základní podporu přístupové metody TDMA], která (kdyby byla dotažena do detailů) by vyřešila problém skrytých uzlů ve venkovních wifi sítích

= Finance =
Na 12. VH NFX (6.9.2009 ve Slavičíně) byl odsouhlasen následující rozpis příspěvků na tento projekt do konce roku 2009 (pozn. Dulik: rozpis částek je neveřejný, nemám explicitní svolení od jednotlivých sdružení ke zveřejňování jejich příspěvků)
* Klfree
* Unart
* Czf-praha
* Unhfree
* KHnet
* Bubakov.net

== Kontaktní osoby ==
Za výše uvedená sdružení budou o směrování projektu rozhodovat následující garanti:
* KLFree: [[user:JaSt|Jast]] ?
* UnArt: [[user:Dulik|Dulik]]
* Czf-praha: [[user:8an|8an]] ?
* Unhfree: [[user:Litin|Litin]] ?
* Bubakov.net:

= Návrh harmonogramu prací =
Harmonogram vychází z toho, že pro začátek nemáme ani jeden měřící přístroj, který by umožňoval zobrazovat TX power a EVM vysílaných packetů pro každý packet zvlášť - viz odstavec „TX power“. Musíme proto začít vývoj tam, kde měření TX power nepotřebujeme – např. testováním & případnými úpravami modu „AP“.

== Administrativa ==
Co je potřeba udělat hned na začátku:
# Dulik: Napsat ostatním vývojářům ath5k, že NFX se rozhodlo podpořit vývoj ath5k vlastním fulltime vývojářem a poslat jim níže uvedený návrh oblastí, které chceme vylepšit. Hotovo, viz [https://lists.ath5k.org/pipermail/ath5k-devel/2009-September/002744.html mailing list ath5k].

== Testy/úpravy modu AP ==
ath5k, stejně jako další drivery založené na novém kernel API mac80211, nemá mód AP implementovaný přímo v sobě. Mod AP se tedy nerealizuje přímo na úrovni kernel driveru jako v Madwifi, ale na úrovni userspace démona [http://linuxwireless.org/en/users/Documentation/hostapd#About_hostapd hostapd], který přijímá a odesílá 802.11 control frames packety z interface nastaveného do monitor modu.

Ve srovnání s Madwifi je toto naprosto jiný přístup a dá se očekávat, že vše nebude fungovat tak, jak má.

Úvodní testy modu AP dělal 8an (prosím o doplnění, co funguje nebo nefunguje ...)

== TX power ==
Ath5k i Madwifi nastavují špatně vysílací výkon (TX power), který je nastavován zesílením výstupního zesilovače.

Každý typ karty má trochu jinak udělanou výstupní (TX) část, takže jednotlivé typy karet se od sebe dost liší charakteristikami TX komponent.

Protože vyšší data rates (např. 54MBit/s – 64QAM) mají mnohem vyšší nároky na linearitu výstupního zesilovače než nižší modulace (6Mbit/s – BPSK), je nutné TX power nastavovat před vysláním každého packetu podle data rate daného packetu.

TX power by měl být nastavován na hodnoty, doporučené výrobcem karty, které jsou uloženy v EEPROM(??) každé karty. Tyto hodnoty výrobce získá např. tak, že změří EVM svojí karty na jednotlivých bit rates v závislosti na nastaveném TX power, s tím, že pro každou bit rate zaznamená hodnotu TX power, při které EVM nepřekračuje meze definované daným standardem 802.11a/b/g.

Je možné, že někteří výrobci hodnoty v EEPROM neuvádějí správně (tj. nechce se jim měřit EVM), proto by ath5k měl umožňovat nastavit TX power pro každý bit rate ručně – tak, jak to umí Mikrotik (nebo se tak aspoň tváří). Popřípadě by alespoň mělo být možné do EEPROM nějaký nástrojem zapsat správné hodnoty.

Současný stav:

Z měření na spektráku FSV vyplynulo toto:

* ath5k (kernel 2.6.30 z debian unstable) vůbec nenastavuje vysílací výkon dle aktuálního data rate. Všechny packety jsou odesílány se stejným vysílacím výkonem, takže EVM u vyšších data rates pak překračuje povolené hodnoty
* Madwifi (poslední SVN verze) nastavuje vysílací výkon pro každý packet zvlášť, ale není jasné, jak – packety při pevně nastaveném bitrate a pevných vnějších podmínkách jsou vysílány s různými hodnotami TX power, následkem čehož EVM občas „vystřelí“ mimo povolené mezi. Pokud je toto implementace TPC, pak se chová dost podivně.
* Ath5k (Madwifi už si nepamatuju) neumí nastavit vysílací výkon u čipsetu AR5007 - příkaz „iwconfig athX txpower Y“ nemá vůbec žádný efekt. Přitom čipset AR5007 při měření vykazoval velmi pěkné výsledky, bylo by tedy dobré ho podporovat.

=== Implementace ===
Pro implementaci správného nastavování TX power je potřeba mít měřák, který umí změřit EVM a vysílací výkon pro každý packet zvlášť.

To je např. R&S FSV nebo možná i Agilent N4010A. Ani jeden z nich teď bohužel nemáme k dispozici.

== Ambient noise immunity - ANI ==
Karty Atheros mají přímo v HW implementováno "vylepšení" příjmu za přítomnosti šumu. Popis této funkce včetně kritiky všech problémů tohoto řešení [http://research.tid.es/domenic/images/computer_networks_giustiniano.pdf najdete zde]

Ve [url=http://madwifi-project.org/ticket/705]starém Madwifi[/url] a v Mikrotiku je s nastavováním ANI spojen bug, který např. u karet CM9 způsobí, že karta v modu AP při jakémkoli rušení (i ve vedlejších kanálech) přestane téměř uplně vysílat.

Novější Madwifi mají v sobě pro mod AP patch, který ale způsobuje problém "Stuck beacon", tj. karta přestane vysílat beacony a tím se spojení rozpadne (AP "zmizí").

ath5k má podporu ANI na svém TODO listu s tím, že zatím se vlastnost ANI v ovladači vůbec neřeší.

Vývoj podpory ANI v ath5k jsme si vzali na starost my (za [https://lists.ath5k.org/pipermail/ath5k-devel/2009-September/002745.html]nadšeného výskotu ostatních vývojářů] ath5k).

== Ruční testování - podprojekt "měřící pracoviště" ==
Abychom vlastnosti "TX Power" a "ANI" neladili naslepo, je vysoce vhodné mít k dispozici měřáky, které teď bohužel nemáme.
A nemáme na ně ani peníze. Více v mailech.

== Automatické testování - podprojekt "WiFi pískoviště" ==

Vývojáři kernelové skupiny Linux Wireless mají na svých stránkách téma pro Google Summer of Code 2009: [http://linuxwireless.org/en/developers/GSoC Automation of testing using mac80211_hwsim and Orbit].

[http://www.orbit-lab.org/ Projekt Orbit] (tj. WiFi sandbox s více než 400 uzly) je super nápad, ale bohužel zaměřený jen na vnitřní wifi sítě.

Já navrhuji dotáhnout tento nápad ještě dál:
#do projektu "Databáze HW" přijímat pokud možno vždy 2 zařízení (pro možnost testování funkce příjmu & vysílání na jednom typu zařízení, což by mělo vždy fungovat nejlíp)
#zařízení nevracet hned, ale zapojovat je na delší dobu do našeho vlastního "pískoviště" (sandbox-u)
#náš sandbox nebude mít antény (jako projekt Orbit), ale jednotlivá zařízení budeme propojovat kabely, couplery, atenuátory (nejlépe programovatelnými), a RF switchi (nejlépe programovatelnými). Tím budeme schopni simulovat téměř jakoukoli topoligii a téměř jakékoli vnější podmínky, které se vyskytují v našich sítích - včetně efektů skrytých uzlů, multipath šíření (s použitím generátorů R&S nebo GNU radio), lokálních šumů, velkých zpoždění (speciální zařízení = "kilometrový koaxiál").
#jako diplomku zadat testovací SW, který pojede na některých uzlech tohoto pískoviště a bude testovat a měřit chování driveru za definovaných a opakovatelných podmínek.

CZFROAM

2009-09-22T08:25:32Z

Dulik: /* CAPWAP */

=Management summary=
CZFROAM je projekt jednotné Autentizační a Autorizační Infrastruktury (AAI) pro CZFree sítě.
Je inspirován projekty Eduroam a Edugain, které umožňují studentům používat zdarma počítačové sítě a aplikace vzdělávacích institucí po celé Evropě.

Co tento projekt přináší zapojeným sítím:
*možnost připojit se k plnohodnotnému rychlému internetu '''kdekoli''' v rámci vlastní sítě a také kdekoli v rámci sítí dalších sdružení, zapojených do projektu. Zapojená sdružení tím pro své členy získají výhodu rychlého připojení s roamingem, kterou v ČR poskytují pouze mobilní operátoři (TMobile/O2/Vodafone a jejich 3G zatím jen ve velkých městech, Ufon i v menších), ostatní operátoři (poskytovatelé ADSL/kabelovek/bezdrátů) nic podobného nemají.
*silné zabezpečení vlastních wifi sítí s centralizovanou správou oprávnění k použití sítě a jejích aplikací

=Garanti projektu=
*[http://www.unart.cz O. s. UnArt]
**zástupce: [[user:Dulik|Dulik]]
**schválení účasti v projektu Správní radou: ([http://vyuka.slfree.net/mod/forum/discuss.php?d=701 v řešení])
*[http://www.jmnet.cz O. s. JM-Net]
**zástupce: [[user:Jakubl|Jakubl]]
**schválení účasti v projektu Správní radou: schváleno

=Základní požadavky na celý systém=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Roaming vs. vrstvy L1 - L3 =
==CAPWAP==
Článek o OpenCapwap [http://zamestnanci.fai.utb.cz/~dulik/unart/OpenCapwap.pdf je zde].

=Zabezpečení=

==Certifikáty==
Certifikáty jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX. Je potřeba ale zjistit cenové podmínky a dle nich nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===

Nejdříve nastavíme radius:

Položka v menu: radius
+
Service (dle sítě, při Wi-Fi wireless)
Address: adresa radius serveru
Secret: heslo
Auth. port: obvykle 1812
Accounting Port: 1813
Timeout: 10 000 ms
Zapamatovat ID (dle # v listu)

Wireless ->

záložka security profiles
+
Name: eduroam
Mode: dynamic keys
Authentification types: zaškrtnout pouze WPA EAP a WPA2 EAP
Unicast Ciphers: tkip a aes ccm zaškrtnout
Group Ciphers: tkip a aes ccm zaškrtnout
Supplicant Identify: {ID} DLE # V LISTU

Záložka RADIUS
MAC Mode: as username as password

záložka interfaces -> + virtual AP

Záložka wireless

SSID: eduroam
Master interface: 2,4 ci 5 GHz sektor/všesměr
Security Profile: eduroam

Hotovo :) a ještě pak ip adresy apod., ale to je na Vás.

==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

=Právní a organizační náležitosti (dohody, smlouvy...)=

Eduroam má toto vše pěkně definováno v dokumentu "[http://www.eduroam.cz/doku.php?id=cs:roamingova_politika Roamingová politika]".

CZFROAM

2009-09-22T08:13:59Z

Dulik: /* Zabezpečení */

=Management summary=
CZFROAM je projekt jednotné Autentizační a Autorizační Infrastruktury (AAI) pro CZFree sítě.
Je inspirován projekty Eduroam a Edugain, které umožňují studentům používat zdarma počítačové sítě a aplikace vzdělávacích institucí po celé Evropě.

Co tento projekt přináší zapojeným sítím:
*možnost připojit se k plnohodnotnému rychlému internetu '''kdekoli''' v rámci vlastní sítě a také kdekoli v rámci sítí dalších sdružení, zapojených do projektu. Zapojená sdružení tím pro své členy získají výhodu rychlého připojení s roamingem, kterou v ČR poskytují pouze mobilní operátoři (TMobile/O2/Vodafone a jejich 3G zatím jen ve velkých městech, Ufon i v menších), ostatní operátoři (poskytovatelé ADSL/kabelovek/bezdrátů) nic podobného nemají.
*silné zabezpečení vlastních wifi sítí s centralizovanou správou oprávnění k použití sítě a jejích aplikací

=Garanti projektu=
*[http://www.unart.cz O. s. UnArt]
**zástupce: [[user:Dulik|Dulik]]
**schválení účasti v projektu Správní radou: ([http://vyuka.slfree.net/mod/forum/discuss.php?d=701 v řešení])
*[http://www.jmnet.cz O. s. JM-Net]
**zástupce: [[user:Jakubl|Jakubl]]
**schválení účasti v projektu Správní radou: schváleno

=Základní požadavky na celý systém=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Roaming vs. vrstvy L1 - L3 =
==CAPWAP==
Popis OpenCapwap je zde.

=Zabezpečení=

==Certifikáty==
Certifikáty jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX. Je potřeba ale zjistit cenové podmínky a dle nich nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===

Nejdříve nastavíme radius:

Položka v menu: radius
+
Service (dle sítě, při Wi-Fi wireless)
Address: adresa radius serveru
Secret: heslo
Auth. port: obvykle 1812
Accounting Port: 1813
Timeout: 10 000 ms
Zapamatovat ID (dle # v listu)

Wireless ->

záložka security profiles
+
Name: eduroam
Mode: dynamic keys
Authentification types: zaškrtnout pouze WPA EAP a WPA2 EAP
Unicast Ciphers: tkip a aes ccm zaškrtnout
Group Ciphers: tkip a aes ccm zaškrtnout
Supplicant Identify: {ID} DLE # V LISTU

Záložka RADIUS
MAC Mode: as username as password

záložka interfaces -> + virtual AP

Záložka wireless

SSID: eduroam
Master interface: 2,4 ci 5 GHz sektor/všesměr
Security Profile: eduroam

Hotovo :) a ještě pak ip adresy apod., ale to je na Vás.

==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

=Právní a organizační náležitosti (dohody, smlouvy...)=

Eduroam má toto vše pěkně definováno v dokumentu "[http://www.eduroam.cz/doku.php?id=cs:roamingova_politika Roamingová politika]".

CZFROAM

2009-09-21T05:57:55Z

Dulik: /* Garanti projektu */

=Management summary=
CZFROAM je projekt jednotné Autentizační a Autorizační Infrastruktury (AAI) pro CZFree sítě.
Je inspirován projekty Eduroam a Edugain, které umožňují studentům používat zdarma počítačové sítě a aplikace vzdělávacích institucí po celé Evropě.

Co tento projekt přináší zapojeným sítím:
*možnost připojit se k plnohodnotnému rychlému internetu '''kdekoli''' v rámci vlastní sítě a také kdekoli v rámci sítí dalších sdružení, zapojených do projektu. Zapojená sdružení tím pro své členy získají výhodu rychlého připojení s roamingem, kterou v ČR poskytují pouze mobilní operátoři (TMobile/O2/Vodafone a jejich 3G zatím jen ve velkých městech, Ufon i v menších), ostatní operátoři (poskytovatelé ADSL/kabelovek/bezdrátů) nic podobného nemají.
*silné zabezpečení vlastních wifi sítí s centralizovanou správou oprávnění k použití sítě a jejích aplikací

=Garanti projektu=
*[http://www.unart.cz O. s. UnArt]
**zástupce: [[user:Dulik|Dulik]]
**schválení účasti v projektu Správní radou: ([http://vyuka.slfree.net/mod/forum/discuss.php?d=701 v řešení])

=Základní požadavky na celý systém=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Zabezpečení=

==Certifikáty==
Certifikáty jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX. Je potřeba ale zjistit cenové podmínky a dle nich nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===

Nejdříve nastavíme radius:

Položka v menu: radius
+
Service (dle sítě, při Wi-Fi wireless)
Address: adresa radius serveru
Secret: heslo
Auth. port: obvykle 1812
Accounting Port: 1813
Timeout: 10 000 ms
Zapamatovat ID (dle # v listu)

Wireless ->

záložka security profiles
+
Name: eduroam
Mode: dynamic keys
Authentification types: zaškrtnout pouze WPA EAP a WPA2 EAP
Unicast Ciphers: tkip a aes ccm zaškrtnout
Group Ciphers: tkip a aes ccm zaškrtnout
Supplicant Identify: {ID} DLE # V LISTU

Záložka RADIUS
MAC Mode: as username as password

záložka interfaces -> + virtual AP

Záložka wireless

SSID: eduroam
Master interface: 2,4 ci 5 GHz sektor/všesměr
Security Profile: eduroam

Hotovo :) a ještě pak ip adresy apod., ale to je na Vás.

==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

=Právní a organizační náležitosti (dohody, smlouvy...)=

Eduroam má toto vše pěkně definováno v dokumentu "[http://www.eduroam.cz/doku.php?id=cs:roamingova_politika Roamingová politika]".

CZFROAM

2009-09-21T05:42:34Z

Dulik: /* Garanti projektu */

=Management summary=
CZFROAM je projekt jednotné Autentizační a Autorizační Infrastruktury (AAI) pro CZFree sítě.
Je inspirován projekty Eduroam a Edugain, které umožňují studentům používat zdarma počítačové sítě a aplikace vzdělávacích institucí po celé Evropě.

Co tento projekt přináší zapojeným sítím:
*možnost připojit se k plnohodnotnému rychlému internetu '''kdekoli''' v rámci vlastní sítě a také kdekoli v rámci sítí dalších sdružení, zapojených do projektu. Zapojená sdružení tím pro své členy získají výhodu rychlého připojení s roamingem, kterou v ČR poskytují pouze mobilní operátoři (TMobile/O2/Vodafone a jejich 3G zatím jen ve velkých městech, Ufon i v menších), ostatní operátoři (poskytovatelé ADSL/kabelovek/bezdrátů) nic podobného nemají.
*silné zabezpečení vlastních wifi sítí s centralizovanou správou oprávnění k použití sítě a jejích aplikací

=Garanti projektu=
*[http://www.unart.cz O. s. UnArt]
**zástupce: [[user:Dulik|Dulik]]
**účast v projektu schválena Správní radou zde: (v řešení)
**maximální roční finanční příspěvek: xxx Kč (v řešení)

=Základní požadavky na celý systém=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Zabezpečení=

==Certifikáty==
Certifikáty jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX. Je potřeba ale zjistit cenové podmínky a dle nich nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===

Nejdříve nastavíme radius:

Položka v menu: radius
+
Service (dle sítě, při Wi-Fi wireless)
Address: adresa radius serveru
Secret: heslo
Auth. port: obvykle 1812
Accounting Port: 1813
Timeout: 10 000 ms
Zapamatovat ID (dle # v listu)

Wireless ->

záložka security profiles
+
Name: eduroam
Mode: dynamic keys
Authentification types: zaškrtnout pouze WPA EAP a WPA2 EAP
Unicast Ciphers: tkip a aes ccm zaškrtnout
Group Ciphers: tkip a aes ccm zaškrtnout
Supplicant Identify: {ID} DLE # V LISTU

Záložka RADIUS
MAC Mode: as username as password

záložka interfaces -> + virtual AP

Záložka wireless

SSID: eduroam
Master interface: 2,4 ci 5 GHz sektor/všesměr
Security Profile: eduroam

Hotovo :) a ještě pak ip adresy apod., ale to je na Vás.

==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

=Právní a organizační náležitosti (dohody, smlouvy...)=

Eduroam má toto vše pěkně definováno v dokumentu "[http://www.eduroam.cz/doku.php?id=cs:roamingova_politika Roamingová politika]".

CZFROAM

2009-09-21T05:32:09Z

Dulik: /* Management summary */

=Management summary=
CZFROAM je projekt jednotné Autentizační a Autorizační Infrastruktury (AAI) pro CZFree sítě.
Je inspirován projekty Eduroam a Edugain, které umožňují studentům používat zdarma počítačové sítě a aplikace vzdělávacích institucí po celé Evropě.

Co tento projekt přináší zapojeným sítím:
*možnost připojit se k plnohodnotnému rychlému internetu '''kdekoli''' v rámci vlastní sítě a také kdekoli v rámci sítí dalších sdružení, zapojených do projektu. Zapojená sdružení tím pro své členy získají výhodu rychlého připojení s roamingem, kterou v ČR poskytují pouze mobilní operátoři (TMobile/O2/Vodafone a jejich 3G zatím jen ve velkých městech, Ufon i v menších), ostatní operátoři (poskytovatelé ADSL/kabelovek/bezdrátů) nic podobného nemají.
*silné zabezpečení vlastních wifi sítí s centralizovanou správou oprávnění k použití sítě a jejích aplikací

=Garanti projektu=
*[http://www.unart.cz O. s. UnArt], zástupce: [[user:Dulik|Dulik]]

=Základní požadavky na celý systém=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Zabezpečení=

==Certifikáty==
Certifikáty jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX. Je potřeba ale zjistit cenové podmínky a dle nich nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===

Nejdříve nastavíme radius:

Položka v menu: radius
+
Service (dle sítě, při Wi-Fi wireless)
Address: adresa radius serveru
Secret: heslo
Auth. port: obvykle 1812
Accounting Port: 1813
Timeout: 10 000 ms
Zapamatovat ID (dle # v listu)

Wireless ->

záložka security profiles
+
Name: eduroam
Mode: dynamic keys
Authentification types: zaškrtnout pouze WPA EAP a WPA2 EAP
Unicast Ciphers: tkip a aes ccm zaškrtnout
Group Ciphers: tkip a aes ccm zaškrtnout
Supplicant Identify: {ID} DLE # V LISTU

Záložka RADIUS
MAC Mode: as username as password

záložka interfaces -> + virtual AP

Záložka wireless

SSID: eduroam
Master interface: 2,4 ci 5 GHz sektor/všesměr
Security Profile: eduroam

Hotovo :) a ještě pak ip adresy apod., ale to je na Vás.

==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

=Právní a organizační náležitosti (dohody, smlouvy...)=

Eduroam má toto vše pěkně definováno v dokumentu "[http://www.eduroam.cz/doku.php?id=cs:roamingova_politika Roamingová politika]".

Uživatel:Dulik

2009-09-21T05:29:49Z

Dulik:

=Kontakt=
*Jabber: dulik@slavek.unart.cz
*ICQ: 38057207
*Skype (zapínám jen na vyžádání): tomasdulik
*mobil: +420 774 313 854
*VOIP do školy: 57 603 5187
=Životopis=
*1993-1998: FEI VUTBR v Brně, obor Informatika + obrážení kateder Biomedicíny (zpracování signálů) a Tele/Radiokomunikací (návrh elektronických systémů)
*Zaměstnání:
**1997-1999: Camea Brno, HW&SW designér (projekty "[http://www.unicam.cz/cz/produkty/zjistovani-dopravnich-prestupku/detekce-jizdy-na-cervenou/ Detekce jízdy na červenou]", "Multikanálový DTMF dekodér", "[http://www.camea.cz/cz/produkty/kontrola-soucastek/ Vizuální systém pro kontrolu SMD součástek]"
**1999-2001: UNIS Brno, HW&SW designér (projekty [http://www.processorexpert.com/Devkit.html DevKit16], [http://www.processorexpert.com/FlashKit.html FlashKit], EU IST FP5 Mobivas, [http://www.ist-mobilife.org/ IST FP6 Mobilife])
**2001-2003: Civilka (poskok sekretářek na rektorátě UTB ve Zlíně :-(
**2003-dodnes: [http://web.fai.utb.cz/?id=0_2_1_7&iid=14&type=0&lang=cs asistent na FAI UTB ve Zlíně]

=Osobní info=
*Rodinný stav: [http://www.unart.cz/gottfriedova/ ženáč] a [http://www.unart.cz/gottfriedova/lukas/ dětináč], takže volného času moc není
*Koníčky:
**Ferda Mravenec, práce všeho druhu
**kapely [http://www.youtube.com/watch?v=_pGteX6E3jM&feature=channel_page HUP], [http://www.youtube.com/watch?v=p2Fh5ZVDCkI&feature=channel_page U5], a samozřejmě O.s. UnArt a aktivní lidi v něm
**člen Správní rady [http://www.unart.cz Občanského sdružení UnArt Slavičín].

Uživatel:Dulik

2009-09-21T05:28:10Z

Dulik:

*Jabber: dulik@slavek.unart.cz
*ICQ: 38057207
*Skype (zapínám jen na vyžádání): tomasdulik
*mobil: +420 774 313 854
*VOIP do školy: 57 603 5187

*Životopis:
**1993-1998: FEI VUTBR v Brně, obor Informatika + obrážení kateder Biomedicíny (zpracování signálů) a Tele/Radiokomunikací (návrh elektronických systémů)
*Zaměstnání:
**1997-1999: Camea Brno, HW&SW designér (projekty "[http://www.unicam.cz/cz/produkty/zjistovani-dopravnich-prestupku/detekce-jizdy-na-cervenou/ Detekce jízdy na červenou]", "Multikanálový DTMF dekodér", "[http://www.camea.cz/cz/produkty/kontrola-soucastek/ Vizuální systém pro kontrolu SMD součástek]"
**1999-2001: UNIS Brno, HW&SW designér (projekty [http://www.processorexpert.com/Devkit.html DevKit16], [http://www.processorexpert.com/FlashKit.html FlashKit], EU IST FP5 Mobivas, [http://www.ist-mobilife.org/ IST FP6 Mobilife])
**2001-2003: Civilka (poskok sekretářek na rektorátě UTB ve Zlíně :-(
**2003-dodnes: [http://web.fai.utb.cz/?id=0_2_1_7&iid=14&type=0&lang=cs asistent na FAI UTB ve Zlíně]

*Volný čas:
**Rodinný stav: [http://www.unart.cz/gottfriedova/ ženáč] a [http://www.unart.cz/gottfriedova/lukas/ dětináč], takže volného času moc není
**Koníčky: kapely [http://www.youtube.com/watch?v=_pGteX6E3jM&feature=channel_page HUP], [http://www.youtube.com/watch?v=p2Fh5ZVDCkI&feature=channel_page U5], a samozřejmě O.s. UnArt a aktivní lidi v něm
**Zakladatel a (zatím ještě) člen rady [http://www.unart.cz O. s. UnArt Slavičín].
**Ferda Mravenec, práce všeho druhu

CZFROAM

2009-09-21T05:26:45Z

Dulik: /* Management summary */

=Management summary=
CZFROAM je projekt jednotné Autentizační a Autorizační Infrastruktury (AAI) pro CZFree sítě.
Je inspirován projekty Eduroam a Edugain, které umožňují studentům používat zdarma počítačové sítě a aplikace vzdělávacích institucí po celé Evropě.

Co tento projekt přináší zapojeným sítím:
*možnost připojit se k plnohodnotnému rychlému internetu '''kdekoli''' v rámci vlastní sítě a také kdekoli v rámci sítí dalších sdružení, zapojených do projektu. Zapojená sdružení tím pro své členy získají výhodu rychlého připojení s roamingem, kterou v ČR částečně poskytují pouze mobilní operátoři (TMobile/O2/Vodafone mají 3G zatím jen ve velkých městech, Ufon i v menších), ostatní operátoři (ADSL/kabelovky/lokální komerční poskytovatelé internetu) nic podobného nemají.
*silné zabezpečení vlastních wifi sítí s centralizovanou správou oprávnění k použití sítě

=Garanti projektu=
*[http://www.unart.cz O. s. UnArt], zástupce: [[user:Dulik|Dulik]]

=Základní požadavky na celý systém=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Zabezpečení=

==Certifikáty==
Certifikáty jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX. Je potřeba ale zjistit cenové podmínky a dle nich nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===

Nejdříve nastavíme radius:

Položka v menu: radius
+
Service (dle sítě, při Wi-Fi wireless)
Address: adresa radius serveru
Secret: heslo
Auth. port: obvykle 1812
Accounting Port: 1813
Timeout: 10 000 ms
Zapamatovat ID (dle # v listu)

Wireless ->

záložka security profiles
+
Name: eduroam
Mode: dynamic keys
Authentification types: zaškrtnout pouze WPA EAP a WPA2 EAP
Unicast Ciphers: tkip a aes ccm zaškrtnout
Group Ciphers: tkip a aes ccm zaškrtnout
Supplicant Identify: {ID} DLE # V LISTU

Záložka RADIUS
MAC Mode: as username as password

záložka interfaces -> + virtual AP

Záložka wireless

SSID: eduroam
Master interface: 2,4 ci 5 GHz sektor/všesměr
Security Profile: eduroam

Hotovo :) a ještě pak ip adresy apod., ale to je na Vás.

==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

=Právní a organizační náležitosti (dohody, smlouvy...)=

Eduroam má toto vše pěkně definováno v dokumentu "[http://www.eduroam.cz/doku.php?id=cs:roamingova_politika Roamingová politika]".

CZFROAM

2009-09-21T05:26:22Z

Dulik: /* Management summary */

=Management summary=
CZFROAM je projekt jednotné Autentizační a Autorizační Infrastruktury (AAI) pro CZFree sítě.
Je inspirován projekty Eduroam a Edugain, které umožňují studentům používat zdarma počítačové sítě a aplikace vzdělávacích institucí po celé Evropě.

Co tento projekt přináší zapojeným sítím:
*možnost připojit se k plnohodnotnému rychlému internetu '''kdekoli''' v rámci vlastní sítě a také kdekoli v rámci sítí dalších sdružení, zapojených do projektu. Zapojená sdružení tím pro své členy získají výhodu rychlého připojení s roamingem, kterou v ČR částečně poskytují pouze mobilní operátoři (TM/O2/Vodafone mají 3G zatím jen ve velkých městech, Ufon i v menších), ostatní operátoři (ADSL/kabelovky/lokální komerční poskytovatelé internetu) nic podobného nemají.
*silné zabezpečení vlastních wifi sítí s centralizovanou správou oprávnění k použití sítě

=Garanti projektu=
*[http://www.unart.cz O. s. UnArt], zástupce: [[user:Dulik|Dulik]]

=Základní požadavky na celý systém=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Zabezpečení=

==Certifikáty==
Certifikáty jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX. Je potřeba ale zjistit cenové podmínky a dle nich nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===

Nejdříve nastavíme radius:

Položka v menu: radius
+
Service (dle sítě, při Wi-Fi wireless)
Address: adresa radius serveru
Secret: heslo
Auth. port: obvykle 1812
Accounting Port: 1813
Timeout: 10 000 ms
Zapamatovat ID (dle # v listu)

Wireless ->

záložka security profiles
+
Name: eduroam
Mode: dynamic keys
Authentification types: zaškrtnout pouze WPA EAP a WPA2 EAP
Unicast Ciphers: tkip a aes ccm zaškrtnout
Group Ciphers: tkip a aes ccm zaškrtnout
Supplicant Identify: {ID} DLE # V LISTU

Záložka RADIUS
MAC Mode: as username as password

záložka interfaces -> + virtual AP

Záložka wireless

SSID: eduroam
Master interface: 2,4 ci 5 GHz sektor/všesměr
Security Profile: eduroam

Hotovo :) a ještě pak ip adresy apod., ale to je na Vás.

==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

=Právní a organizační náležitosti (dohody, smlouvy...)=

Eduroam má toto vše pěkně definováno v dokumentu "[http://www.eduroam.cz/doku.php?id=cs:roamingova_politika Roamingová politika]".

CZFROAM

2009-09-21T05:25:42Z

Dulik: /* Management summary */

=Management summary=
CZFROAM je projekt jednotné Autentizační a Autorizační Infrastruktury (AAI) pro CZFree sítě.
Je inspirován projekty Eduroam a Edugain, které umožňují studentům používat zdarma počítačové sítě a aplikace vzdělávacích institucí po celé Evropě.

Co tento projekt přináší zapojeným sítím:
*možnost připojit se k plnohodnotnému rychlému internetu nejen kdekoli v rámci vlastní sítě, ale také kdekoli v rámci sítí dalších sdružení, zapojených do projektu. Zapojená sdružení tím pro své členy získají výhodu rychlého připojení s roamingem, kterou v ČR částečně poskytují pouze mobilní operátoři (TM/O2/Vodafone mají 3G zatím jen ve velkých městech, Ufon i v menších), ostatní operátoři (ADSL/kabelovky/lokální komerční poskytovatelé internetu) nic podobného nemají.
*silné zabezpečení vlastních wifi sítí s centralizovanou správou oprávnění k použití sítě

=Garanti projektu=
*[http://www.unart.cz O. s. UnArt], zástupce: [[user:Dulik|Dulik]]

=Základní požadavky na celý systém=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Zabezpečení=

==Certifikáty==
Certifikáty jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX. Je potřeba ale zjistit cenové podmínky a dle nich nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===

Nejdříve nastavíme radius:

Položka v menu: radius
+
Service (dle sítě, při Wi-Fi wireless)
Address: adresa radius serveru
Secret: heslo
Auth. port: obvykle 1812
Accounting Port: 1813
Timeout: 10 000 ms
Zapamatovat ID (dle # v listu)

Wireless ->

záložka security profiles
+
Name: eduroam
Mode: dynamic keys
Authentification types: zaškrtnout pouze WPA EAP a WPA2 EAP
Unicast Ciphers: tkip a aes ccm zaškrtnout
Group Ciphers: tkip a aes ccm zaškrtnout
Supplicant Identify: {ID} DLE # V LISTU

Záložka RADIUS
MAC Mode: as username as password

záložka interfaces -> + virtual AP

Záložka wireless

SSID: eduroam
Master interface: 2,4 ci 5 GHz sektor/všesměr
Security Profile: eduroam

Hotovo :) a ještě pak ip adresy apod., ale to je na Vás.

==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

=Právní a organizační náležitosti (dohody, smlouvy...)=

Eduroam má toto vše pěkně definováno v dokumentu "[http://www.eduroam.cz/doku.php?id=cs:roamingova_politika Roamingová politika]".

CZFROAM

2009-09-21T05:25:14Z

Dulik: /* Úvod */

=Management summary=
CZFROAM je projekt jednotné Autentizační a Autorizační Infrastruktury (AAI) pro CZFree sítě.
Je inspirován projekty Eduroam a Edugain, které umožňují studentům používat zdarma počítačové sítě a aplikace vzdělávacích institucí po celé Evropě.

Co tento projekt přináší zapojeným sítím:
[*]možnost připojit se k plnohodnotnému rychlému internetu nejen kdekoli v rámci vlastní sítě, ale také kdekoli v rámci sítí dalších sdružení, zapojených do projektu. Zapojená sdružení tím pro své členy získají výhodu rychlého připojení s roamingem, kterou v ČR částečně poskytují pouze mobilní operátoři (TM/O2/Vodafone mají 3G zatím jen ve velkých městech, Ufon i v menších), ostatní operátoři (ADSL/kabelovky/lokální komerční poskytovatelé internetu) nic podobného nemají.
[*]silné zabezpečení vlastních wifi sítí s centralizovanou správou oprávnění k použití sítě

=Garanti projektu=
*[http://www.unart.cz O. s. UnArt], zástupce: [[user:Dulik|Dulik]]

=Základní požadavky na celý systém=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Zabezpečení=

==Certifikáty==
Certifikáty jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX. Je potřeba ale zjistit cenové podmínky a dle nich nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===

Nejdříve nastavíme radius:

Položka v menu: radius
+
Service (dle sítě, při Wi-Fi wireless)
Address: adresa radius serveru
Secret: heslo
Auth. port: obvykle 1812
Accounting Port: 1813
Timeout: 10 000 ms
Zapamatovat ID (dle # v listu)

Wireless ->

záložka security profiles
+
Name: eduroam
Mode: dynamic keys
Authentification types: zaškrtnout pouze WPA EAP a WPA2 EAP
Unicast Ciphers: tkip a aes ccm zaškrtnout
Group Ciphers: tkip a aes ccm zaškrtnout
Supplicant Identify: {ID} DLE # V LISTU

Záložka RADIUS
MAC Mode: as username as password

záložka interfaces -> + virtual AP

Záložka wireless

SSID: eduroam
Master interface: 2,4 ci 5 GHz sektor/všesměr
Security Profile: eduroam

Hotovo :) a ještě pak ip adresy apod., ale to je na Vás.

==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

=Právní a organizační náležitosti (dohody, smlouvy...)=

Eduroam má toto vše pěkně definováno v dokumentu "[http://www.eduroam.cz/doku.php?id=cs:roamingova_politika Roamingová politika]".

CZFROAM

2009-09-21T05:01:07Z

Dulik: /* Účastníci (garanti) projektu */

=Úvod=
CZFROAM je projekt jednotné Autentizační a Autorizační Infrastruktury (AAI) pro CZFree sítě.
Je inspirován projekty Eduroam a Edugain, které umožňují studentům používat zdarma počítačové sítě a aplikace vzdělávacích institucí po celé Evropě.

=Garanti projektu=
*[http://www.unart.cz O. s. UnArt], zástupce: [[user:Dulik|Dulik]]

=Základní požadavky na celý systém=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Zabezpečení=

==Certifikáty==
Certifikáty jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX. Je potřeba ale zjistit cenové podmínky a dle nich nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===

Nejdříve nastavíme radius:

Položka v menu: radius
+
Service (dle sítě, při Wi-Fi wireless)
Address: adresa radius serveru
Secret: heslo
Auth. port: obvykle 1812
Accounting Port: 1813
Timeout: 10 000 ms
Zapamatovat ID (dle # v listu)

Wireless ->

záložka security profiles
+
Name: eduroam
Mode: dynamic keys
Authentification types: zaškrtnout pouze WPA EAP a WPA2 EAP
Unicast Ciphers: tkip a aes ccm zaškrtnout
Group Ciphers: tkip a aes ccm zaškrtnout
Supplicant Identify: {ID} DLE # V LISTU

Záložka RADIUS
MAC Mode: as username as password

záložka interfaces -> + virtual AP

Záložka wireless

SSID: eduroam
Master interface: 2,4 ci 5 GHz sektor/všesměr
Security Profile: eduroam

Hotovo :) a ještě pak ip adresy apod., ale to je na Vás.

==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

=Právní a organizační náležitosti (dohody, smlouvy...)=

Eduroam má toto vše pěkně definováno v dokumentu "[http://www.eduroam.cz/doku.php?id=cs:roamingova_politika Roamingová politika]".

CZFROAM

2009-09-21T05:00:38Z

Dulik: /* Garanti projektu */

=Úvod=
CZFROAM je projekt jednotné Autentizační a Autorizační Infrastruktury (AAI) pro CZFree sítě.
Je inspirován projekty Eduroam a Edugain, které umožňují studentům používat zdarma počítačové sítě a aplikace vzdělávacích institucí po celé Evropě.

=Účastníci (garanti) projektu=
*[http://www.unart.cz O. s. UnArt], zástupce: [[user:Dulik|Dulik]]

=Základní požadavky na celý systém=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Zabezpečení=

==Certifikáty==
Certifikáty jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX. Je potřeba ale zjistit cenové podmínky a dle nich nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===

Nejdříve nastavíme radius:

Položka v menu: radius
+
Service (dle sítě, při Wi-Fi wireless)
Address: adresa radius serveru
Secret: heslo
Auth. port: obvykle 1812
Accounting Port: 1813
Timeout: 10 000 ms
Zapamatovat ID (dle # v listu)

Wireless ->

záložka security profiles
+
Name: eduroam
Mode: dynamic keys
Authentification types: zaškrtnout pouze WPA EAP a WPA2 EAP
Unicast Ciphers: tkip a aes ccm zaškrtnout
Group Ciphers: tkip a aes ccm zaškrtnout
Supplicant Identify: {ID} DLE # V LISTU

Záložka RADIUS
MAC Mode: as username as password

záložka interfaces -> + virtual AP

Záložka wireless

SSID: eduroam
Master interface: 2,4 ci 5 GHz sektor/všesměr
Security Profile: eduroam

Hotovo :) a ještě pak ip adresy apod., ale to je na Vás.

==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

=Právní a organizační náležitosti (dohody, smlouvy...)=

Eduroam má toto vše pěkně definováno v dokumentu "[http://www.eduroam.cz/doku.php?id=cs:roamingova_politika Roamingová politika]".

Uživatel:Dulik

2009-09-21T04:58:45Z

Dulik: Nová stránka: *Jabber: dulik@slavek.unart.cz *ICQ: 38057207 *Skype (zapínám jen na vyžádání): tomasdulik *mobil: +420 774 313 854 *VOIP do školy: 57 603 5187 Něco o mně: *Zakladatel a (z...

*Jabber: dulik@slavek.unart.cz
*ICQ: 38057207
*Skype (zapínám jen na vyžádání): tomasdulik
*mobil: +420 774 313 854
*VOIP do školy: 57 603 5187

Něco o mně:
*Zakladatel a (zatím ještě) člen rady [http://www.unart.cz O. s. UnArt Slavičín].
*Ferda Mravenec, práce všeho druhu
*Rodinný stav: [http://www.unart.cz/gottfriedova/ ženáč] a [http://www.unart.cz/gottfriedova/lukas/ dětináč]
*Koníčky: kapely [http://www.youtube.com/watch?v=_pGteX6E3jM&feature=channel_page HUP], [http://www.youtube.com/watch?v=p2Fh5ZVDCkI&feature=channel_page U5], a samozřejmě O.s. UnArt a aktivní lidi v něm
*Studium:
**1993-1998: FEI VUTBR v Brně, obor Informatika + obrážení kateder Biomedicíny (zpracování signálů) a Tele/Radiokomunikací (návrh elektronických systémů)
*Zaměstnání:
**1997-1999: Camea Brno, HW&SW designér (projekty "[http://www.unicam.cz/cz/produkty/zjistovani-dopravnich-prestupku/detekce-jizdy-na-cervenou/ Detekce jízdy na červenou]", "Multikanálový DTMF dekodér", "[http://www.camea.cz/cz/produkty/kontrola-soucastek/ Vizuální systém pro kontrolu SMD součástek]"
**1999-2001: UNIS Brno, HW&SW designér (projekty [http://www.processorexpert.com/Devkit.html DevKit16], [http://www.processorexpert.com/FlashKit.html FlashKit], EU IST FP5 Mobivas, [http://www.ist-mobilife.org/ IST FP6 Mobilife])
**2001-2003: Civilka (poskok sekretářek na rektorátě UTB ve Zlíně :-(
**2003-dodnes: [http://web.fai.utb.cz/?id=0_2_1_7&iid=14&type=0&lang=cs asistent na FAI UTB ve Zlíně]

CZFROAM

2009-09-21T04:57:56Z

Dulik: /* Úvod */

Ath5k

2009-09-19T07:05:16Z

Dulik: /* Administrativa */

Toto je kopie textu z wiki.nfx.cz
= Úvod =

Vývoj ovladače Madwifi byl ukončen, nelze čekat přidání podpory dalšího hardwaru, nanejvýš portování na nové verze kernelu. Kód se dostal do stavu, kdy je další vývoj v podstatě nemožný, uvědomují si to i jeho autoři. Ti proto od Madwifi utekli k ovladači Ath5k, který je součástí kernelu. Bohužel zatím není příliš stabilní, především v režimu AP (jsou problémy s beacony).

Cílem tohoto projektu je opravit chyby ovladače Ath5k, aby se dal používat na našich AP namísto Madwifi a začlenit tyto změny do kernelu, abychom si nemuseli udržovat vlastní větev (což by bylo náročnější než samotná oprava chyb).

Inspirovat se můžeme ovladačem Atheros ve FreeBSD, který

* funguje bez problémů
* od verze 7.2 je i kompletně open-source (včetně HALu)
* od [http://svn.freebsd.org/viewvc/base?view=revision&revision=186904 ledna 2009] má [http://svn.freebsd.org/viewvc/base/head/sbin/ifconfig/ifconfig.8?r1=184057&r2=186904&pathrev=186904 základní podporu přístupové metody TDMA], která (kdyby byla dotažena do detailů) by vyřešila problém skrytých uzlů ve venkovních wifi sítích

= Finance =
Na 12. VH NFX (6.9.2009 ve Slavičíně) byl odsouhlasen následující rozpis příspěvků na tento projekt do konce roku 2009 (pozn. Dulik: rozpis částek je neveřejný, nemám explicitní svolení od jednotlivých sdružení ke zveřejňování jejich příspěvků)
* Klfree
* Unart
* Czf-praha
* Unhfree
* KHnet
* Bubakov.net

== Kontaktní osoby ==
Za výše uvedená sdružení budou o směrování projektu rozhodovat následující garanti:
* KLFree: [[user:JaSt|Jast]] ?
* UnArt: [[user:Dulik|Dulik]]
* Czf-praha: [[user:8an|8an]] ?
* Unhfree: [[user:Litin|Litin]] ?
* Bubakov.net:

= Návrh harmonogramu prací =
Harmonogram vychází z toho, že pro začátek nemáme ani jeden měřící přístroj, který by umožňoval zobrazovat TX power a EVM vysílaných packetů pro každý packet zvlášť - viz odstavec „TX power“. Musíme proto začít vývoj tam, kde měření TX power nepotřebujeme – např. testováním & případnými úpravami modu „AP“.

== Administrativa ==
Co je potřeba udělat hned na začátku:
# Dulik: Napsat ostatním vývojářům ath5k, že NFX se rozhodlo podpořit vývoj ath5k vlastním fulltime vývojářem a poslat jim níže uvedený návrh oblastí, které chceme vylepšit. Hotovo, viz [https://lists.ath5k.org/pipermail/ath5k-devel/2009-September/002744.html mailing list ath5k].

== Testy/úpravy modu AP ==
ath5k, stejně jako další drivery založené na novém kernel API mac80211, nemá mód AP implementovaný přímo v sobě. Mod AP se tedy nerealizuje přímo na úrovni kernel driveru jako v Madwifi, ale na úrovni userspace démona [http://linuxwireless.org/en/users/Documentation/hostapd#About_hostapd hostapd], který přijímá a odesílá 802.11 control frames packety z interface nastaveného do monitor modu.

Ve srovnání s Madwifi je toto naprosto jiný přístup a dá se očekávat, že vše nebude fungovat tak, jak má.

Úvodní testy modu AP dělal 8an (prosím o doplnění, co funguje nebo nefunguje ...)

== TX power ==
Ath5k i Madwifi nastavují špatně vysílací výkon (TX power), který je nastavován zesílením výstupního zesilovače.

Každý typ karty má trochu jinak udělanou výstupní (TX) část, takže jednotlivé typy karet se od sebe dost liší charakteristikami TX komponent.

Protože vyšší data rates (např. 54MBit/s – 64QAM) mají mnohem vyšší nároky na linearitu výstupního zesilovače než nižší modulace (6Mbit/s – BPSK), je nutné TX power nastavovat před vysláním každého packetu podle data rate daného packetu.

TX power by měl být nastavován na hodnoty, doporučené výrobcem karty, které jsou uloženy v EEPROM(??) každé karty. Tyto hodnoty výrobce získá např. tak, že změří EVM svojí karty na jednotlivých bit rates v závislosti na nastaveném TX power, s tím, že pro každou bit rate zaznamená hodnotu TX power, při které EVM nepřekračuje meze definované daným standardem 802.11a/b/g.

Je možné, že někteří výrobci hodnoty v EEPROM neuvádějí správně (tj. nechce se jim měřit EVM), proto by ath5k měl umožňovat nastavit TX power pro každý bit rate ručně – tak, jak to umí Mikrotik (nebo se tak aspoň tváří). Popřípadě by alespoň mělo být možné do EEPROM nějaký nástrojem zapsat správné hodnoty.

Současný stav:

Z měření na spektráku FSV vyplynulo toto:

* ath5k (kernel 2.6.30 z debian unstable) vůbec nenastavuje vysílací výkon dle aktuálního data rate. Všechny packety jsou odesílány se stejným vysílacím výkonem, takže EVM u vyšších data rates pak překračuje povolené hodnoty
* Madwifi (poslední SVN verze) nastavuje vysílací výkon pro každý packet zvlášť, ale není jasné, jak – packety při pevně nastaveném bitrate a pevných vnějších podmínkách jsou vysílány s různými hodnotami TX power, následkem čehož EVM občas „vystřelí“ mimo povolené mezi. Pokud je toto implementace TPC, pak se chová dost podivně.
* Ath5k (Madwifi už si nepamatuju) neumí nastavit vysílací výkon u čipsetu AR5007 - příkaz „iwconfig athX txpower Y“ nemá vůbec žádný efekt. Přitom čipset AR5007 při měření vykazoval velmi pěkné výsledky, bylo by tedy dobré ho podporovat.

=== Implementace ===
Pro implementaci správného nastavování TX power je potřeba mít měřák, který umí změřit EVM a vysílací výkon pro každý packet zvlášť.

To je např. R&S FSV nebo možná i Agilent N4010A. Ani jeden z nich teď bohužel nemáme k dispozici.

== Ambient noise immunity - ANI ==
Karty Atheros mají přímo v HW implementováno "vylepšení" funkce za přítomnosti šumu, o kterém zatím pořádně nevíme, jak funguje.

Nicméně víme, že ve starém Madwifi a v Mikrotiku je s nastavováním ANI spojen bug, který např. u karet CM9 způsobí, že karta při jakémkoli rušení (i ve vedlejších kanálech) přestane téměř uplně vysílat.

ath5k má podporu ANI na svém TODO listu s tím, že zatím se vlastnost ANI v ovladači vůbec neřeší.

== Ruční testování - podprojekt "měřící pracoviště" ==
Abychom vlastnosti "TX Power" a "ANI" neladili naslepo, je vysoce vhodné mít k dispozici měřáky, které teď bohužel nemáme.
A nemáme na ně ani peníze. Více v mailech.

== Automatické testování - podprojekt "WiFi pískoviště" ==

Vývojáři kernelové skupiny Linux Wireless mají na svých stránkách téma pro Google Summer of Code 2009: [http://linuxwireless.org/en/developers/GSoC Automation of testing using mac80211_hwsim and Orbit].

[http://www.orbit-lab.org/ Projekt Orbit] (tj. WiFi sandbox s více než 400 uzly) je super nápad, ale bohužel zaměřený jen na vnitřní wifi sítě.

Já navrhuji dotáhnout tento nápad ještě dál:
#do projektu "Databáze HW" přijímat pokud možno vždy 2 zařízení (pro možnost testování funkce příjmu & vysílání na jednom typu zařízení, což by mělo vždy fungovat nejlíp)
#zařízení nevracet hned, ale zapojovat je na delší dobu do našeho vlastního "pískoviště" (sandbox-u)
#náš sandbox nebude mít antény (jako projekt Orbit), ale jednotlivá zařízení budeme propojovat kabely, couplery, atenuátory (nejlépe programovatelnými), a RF switchi (nejlépe programovatelnými). Tím budeme schopni simulovat téměř jakoukoli topoligii a téměř jakékoli vnější podmínky, které se vyskytují v našich sítích - včetně efektů skrytých uzlů, multipath šíření (s použitím generátorů R&S nebo GNU radio), lokálních šumů, velkých zpoždění (speciální zařízení = "kilometrový koaxiál").
#jako diplomku zadat testovací SW, který pojede na některých uzlech tohoto pískoviště a bude testovat a měřit chování driveru za definovaných a opakovatelných podmínek.

Ath5k

2009-09-19T07:00:53Z

Dulik: /* Administrativa */

Toto je kopie textu z wiki.nfx.cz
= Úvod =

Vývoj ovladače Madwifi byl ukončen, nelze čekat přidání podpory dalšího hardwaru, nanejvýš portování na nové verze kernelu. Kód se dostal do stavu, kdy je další vývoj v podstatě nemožný, uvědomují si to i jeho autoři. Ti proto od Madwifi utekli k ovladači Ath5k, který je součástí kernelu. Bohužel zatím není příliš stabilní, především v režimu AP (jsou problémy s beacony).

Cílem tohoto projektu je opravit chyby ovladače Ath5k, aby se dal používat na našich AP namísto Madwifi a začlenit tyto změny do kernelu, abychom si nemuseli udržovat vlastní větev (což by bylo náročnější než samotná oprava chyb).

Inspirovat se můžeme ovladačem Atheros ve FreeBSD, který

* funguje bez problémů
* od verze 7.2 je i kompletně open-source (včetně HALu)
* od [http://svn.freebsd.org/viewvc/base?view=revision&revision=186904 ledna 2009] má [http://svn.freebsd.org/viewvc/base/head/sbin/ifconfig/ifconfig.8?r1=184057&r2=186904&pathrev=186904 základní podporu přístupové metody TDMA], která (kdyby byla dotažena do detailů) by vyřešila problém skrytých uzlů ve venkovních wifi sítích

= Finance =
Na 12. VH NFX (6.9.2009 ve Slavičíně) byl odsouhlasen následující rozpis příspěvků na tento projekt do konce roku 2009 (pozn. Dulik: rozpis částek je neveřejný, nemám explicitní svolení od jednotlivých sdružení ke zveřejňování jejich příspěvků)
* Klfree
* Unart
* Czf-praha
* Unhfree
* KHnet
* Bubakov.net

== Kontaktní osoby ==
Za výše uvedená sdružení budou o směrování projektu rozhodovat následující garanti:
* KLFree: [[user:JaSt|Jast]] ?
* UnArt: [[user:Dulik|Dulik]]
* Czf-praha: [[user:8an|8an]] ?
* Unhfree: [[user:Litin|Litin]] ?
* Bubakov.net:

= Návrh harmonogramu prací =
Harmonogram vychází z toho, že pro začátek nemáme ani jeden měřící přístroj, který by umožňoval zobrazovat TX power a EVM vysílaných packetů pro každý packet zvlášť - viz odstavec „TX power“. Musíme proto začít vývoj tam, kde měření TX power nepotřebujeme – např. testováním & případnými úpravami modu „AP“.

== Administrativa ==
Co je potřeba udělat hned na začátku:
# Dulik: Napsat ostatním vývojářům ath5k (asi na mailing list ath5k-devel@lists.ath5k.org), že NFX se rozhodlo podpořit vývoj ath5k vlastním fulltime vývojářem a poslat jim níže uvedený návrh oblastí, které chceme vylepšit. Hotovo, viz [https://lists.ath5k.org/pipermail/ath5k-devel/2009-September/002744.html mailing list ath5k].

== Testy/úpravy modu AP ==
ath5k, stejně jako další drivery založené na novém kernel API mac80211, nemá mód AP implementovaný přímo v sobě. Mod AP se tedy nerealizuje přímo na úrovni kernel driveru jako v Madwifi, ale na úrovni userspace démona [http://linuxwireless.org/en/users/Documentation/hostapd#About_hostapd hostapd], který přijímá a odesílá 802.11 control frames packety z interface nastaveného do monitor modu.

Ve srovnání s Madwifi je toto naprosto jiný přístup a dá se očekávat, že vše nebude fungovat tak, jak má.

Úvodní testy modu AP dělal 8an (prosím o doplnění, co funguje nebo nefunguje ...)

== TX power ==
Ath5k i Madwifi nastavují špatně vysílací výkon (TX power), který je nastavován zesílením výstupního zesilovače.

Každý typ karty má trochu jinak udělanou výstupní (TX) část, takže jednotlivé typy karet se od sebe dost liší charakteristikami TX komponent.

Protože vyšší data rates (např. 54MBit/s – 64QAM) mají mnohem vyšší nároky na linearitu výstupního zesilovače než nižší modulace (6Mbit/s – BPSK), je nutné TX power nastavovat před vysláním každého packetu podle data rate daného packetu.

TX power by měl být nastavován na hodnoty, doporučené výrobcem karty, které jsou uloženy v EEPROM(??) každé karty. Tyto hodnoty výrobce získá např. tak, že změří EVM svojí karty na jednotlivých bit rates v závislosti na nastaveném TX power, s tím, že pro každou bit rate zaznamená hodnotu TX power, při které EVM nepřekračuje meze definované daným standardem 802.11a/b/g.

Je možné, že někteří výrobci hodnoty v EEPROM neuvádějí správně (tj. nechce se jim měřit EVM), proto by ath5k měl umožňovat nastavit TX power pro každý bit rate ručně – tak, jak to umí Mikrotik (nebo se tak aspoň tváří). Popřípadě by alespoň mělo být možné do EEPROM nějaký nástrojem zapsat správné hodnoty.

Současný stav:

Z měření na spektráku FSV vyplynulo toto:

* ath5k (kernel 2.6.30 z debian unstable) vůbec nenastavuje vysílací výkon dle aktuálního data rate. Všechny packety jsou odesílány se stejným vysílacím výkonem, takže EVM u vyšších data rates pak překračuje povolené hodnoty
* Madwifi (poslední SVN verze) nastavuje vysílací výkon pro každý packet zvlášť, ale není jasné, jak – packety při pevně nastaveném bitrate a pevných vnějších podmínkách jsou vysílány s různými hodnotami TX power, následkem čehož EVM občas „vystřelí“ mimo povolené mezi. Pokud je toto implementace TPC, pak se chová dost podivně.
* Ath5k (Madwifi už si nepamatuju) neumí nastavit vysílací výkon u čipsetu AR5007 - příkaz „iwconfig athX txpower Y“ nemá vůbec žádný efekt. Přitom čipset AR5007 při měření vykazoval velmi pěkné výsledky, bylo by tedy dobré ho podporovat.

=== Implementace ===
Pro implementaci správného nastavování TX power je potřeba mít měřák, který umí změřit EVM a vysílací výkon pro každý packet zvlášť.

To je např. R&S FSV nebo možná i Agilent N4010A. Ani jeden z nich teď bohužel nemáme k dispozici.

== Ambient noise immunity - ANI ==
Karty Atheros mají přímo v HW implementováno "vylepšení" funkce za přítomnosti šumu, o kterém zatím pořádně nevíme, jak funguje.

Nicméně víme, že ve starém Madwifi a v Mikrotiku je s nastavováním ANI spojen bug, který např. u karet CM9 způsobí, že karta při jakémkoli rušení (i ve vedlejších kanálech) přestane téměř uplně vysílat.

ath5k má podporu ANI na svém TODO listu s tím, že zatím se vlastnost ANI v ovladači vůbec neřeší.

== Ruční testování - podprojekt "měřící pracoviště" ==
Abychom vlastnosti "TX Power" a "ANI" neladili naslepo, je vysoce vhodné mít k dispozici měřáky, které teď bohužel nemáme.
A nemáme na ně ani peníze. Více v mailech.

== Automatické testování - podprojekt "WiFi pískoviště" ==

Vývojáři kernelové skupiny Linux Wireless mají na svých stránkách téma pro Google Summer of Code 2009: [http://linuxwireless.org/en/developers/GSoC Automation of testing using mac80211_hwsim and Orbit].

[http://www.orbit-lab.org/ Projekt Orbit] (tj. WiFi sandbox s více než 400 uzly) je super nápad, ale bohužel zaměřený jen na vnitřní wifi sítě.

Já navrhuji dotáhnout tento nápad ještě dál:
#do projektu "Databáze HW" přijímat pokud možno vždy 2 zařízení (pro možnost testování funkce příjmu & vysílání na jednom typu zařízení, což by mělo vždy fungovat nejlíp)
#zařízení nevracet hned, ale zapojovat je na delší dobu do našeho vlastního "pískoviště" (sandbox-u)
#náš sandbox nebude mít antény (jako projekt Orbit), ale jednotlivá zařízení budeme propojovat kabely, couplery, atenuátory (nejlépe programovatelnými), a RF switchi (nejlépe programovatelnými). Tím budeme schopni simulovat téměř jakoukoli topoligii a téměř jakékoli vnější podmínky, které se vyskytují v našich sítích - včetně efektů skrytých uzlů, multipath šíření (s použitím generátorů R&S nebo GNU radio), lokálních šumů, velkých zpoždění (speciální zařízení = "kilometrový koaxiál").
#jako diplomku zadat testovací SW, který pojede na některých uzlech tohoto pískoviště a bude testovat a měřit chování driveru za definovaných a opakovatelných podmínek.

Ath5k

2009-09-19T07:00:29Z

Dulik: /* Administrativa */

Toto je kopie textu z wiki.nfx.cz
= Úvod =

Vývoj ovladače Madwifi byl ukončen, nelze čekat přidání podpory dalšího hardwaru, nanejvýš portování na nové verze kernelu. Kód se dostal do stavu, kdy je další vývoj v podstatě nemožný, uvědomují si to i jeho autoři. Ti proto od Madwifi utekli k ovladači Ath5k, který je součástí kernelu. Bohužel zatím není příliš stabilní, především v režimu AP (jsou problémy s beacony).

Cílem tohoto projektu je opravit chyby ovladače Ath5k, aby se dal používat na našich AP namísto Madwifi a začlenit tyto změny do kernelu, abychom si nemuseli udržovat vlastní větev (což by bylo náročnější než samotná oprava chyb).

Inspirovat se můžeme ovladačem Atheros ve FreeBSD, který

* funguje bez problémů
* od verze 7.2 je i kompletně open-source (včetně HALu)
* od [http://svn.freebsd.org/viewvc/base?view=revision&revision=186904 ledna 2009] má [http://svn.freebsd.org/viewvc/base/head/sbin/ifconfig/ifconfig.8?r1=184057&r2=186904&pathrev=186904 základní podporu přístupové metody TDMA], která (kdyby byla dotažena do detailů) by vyřešila problém skrytých uzlů ve venkovních wifi sítích

= Finance =
Na 12. VH NFX (6.9.2009 ve Slavičíně) byl odsouhlasen následující rozpis příspěvků na tento projekt do konce roku 2009 (pozn. Dulik: rozpis částek je neveřejný, nemám explicitní svolení od jednotlivých sdružení ke zveřejňování jejich příspěvků)
* Klfree
* Unart
* Czf-praha
* Unhfree
* KHnet
* Bubakov.net

== Kontaktní osoby ==
Za výše uvedená sdružení budou o směrování projektu rozhodovat následující garanti:
* KLFree: [[user:JaSt|Jast]] ?
* UnArt: [[user:Dulik|Dulik]]
* Czf-praha: [[user:8an|8an]] ?
* Unhfree: [[user:Litin|Litin]] ?
* Bubakov.net:

= Návrh harmonogramu prací =
Harmonogram vychází z toho, že pro začátek nemáme ani jeden měřící přístroj, který by umožňoval zobrazovat TX power a EVM vysílaných packetů pro každý packet zvlášť - viz odstavec „TX power“. Musíme proto začít vývoj tam, kde měření TX power nepotřebujeme – např. testováním & případnými úpravami modu „AP“.

== Administrativa ==
Co je potřeba udělat hned na začátku:
# Dulik: Napsat ostatním vývojářům ath5k (asi na mailing list ath5k-devel@lists.ath5k.org), že NFX se rozhodlo podpořit vývoj ath5k vlastním fulltime vývojářem a poslat jim níže uvedený návrh oblastí, které chceme vylepšit. Hotovo, viz [https://lists.ath5k.org/pipermail/ath5k-devel/2009-September/002744.html mailing list ath5k.

== Testy/úpravy modu AP ==
ath5k, stejně jako další drivery založené na novém kernel API mac80211, nemá mód AP implementovaný přímo v sobě. Mod AP se tedy nerealizuje přímo na úrovni kernel driveru jako v Madwifi, ale na úrovni userspace démona [http://linuxwireless.org/en/users/Documentation/hostapd#About_hostapd hostapd], který přijímá a odesílá 802.11 control frames packety z interface nastaveného do monitor modu.

Ve srovnání s Madwifi je toto naprosto jiný přístup a dá se očekávat, že vše nebude fungovat tak, jak má.

Úvodní testy modu AP dělal 8an (prosím o doplnění, co funguje nebo nefunguje ...)

== TX power ==
Ath5k i Madwifi nastavují špatně vysílací výkon (TX power), který je nastavován zesílením výstupního zesilovače.

Každý typ karty má trochu jinak udělanou výstupní (TX) část, takže jednotlivé typy karet se od sebe dost liší charakteristikami TX komponent.

Protože vyšší data rates (např. 54MBit/s – 64QAM) mají mnohem vyšší nároky na linearitu výstupního zesilovače než nižší modulace (6Mbit/s – BPSK), je nutné TX power nastavovat před vysláním každého packetu podle data rate daného packetu.

TX power by měl být nastavován na hodnoty, doporučené výrobcem karty, které jsou uloženy v EEPROM(??) každé karty. Tyto hodnoty výrobce získá např. tak, že změří EVM svojí karty na jednotlivých bit rates v závislosti na nastaveném TX power, s tím, že pro každou bit rate zaznamená hodnotu TX power, při které EVM nepřekračuje meze definované daným standardem 802.11a/b/g.

Je možné, že někteří výrobci hodnoty v EEPROM neuvádějí správně (tj. nechce se jim měřit EVM), proto by ath5k měl umožňovat nastavit TX power pro každý bit rate ručně – tak, jak to umí Mikrotik (nebo se tak aspoň tváří). Popřípadě by alespoň mělo být možné do EEPROM nějaký nástrojem zapsat správné hodnoty.

Současný stav:

Z měření na spektráku FSV vyplynulo toto:

* ath5k (kernel 2.6.30 z debian unstable) vůbec nenastavuje vysílací výkon dle aktuálního data rate. Všechny packety jsou odesílány se stejným vysílacím výkonem, takže EVM u vyšších data rates pak překračuje povolené hodnoty
* Madwifi (poslední SVN verze) nastavuje vysílací výkon pro každý packet zvlášť, ale není jasné, jak – packety při pevně nastaveném bitrate a pevných vnějších podmínkách jsou vysílány s různými hodnotami TX power, následkem čehož EVM občas „vystřelí“ mimo povolené mezi. Pokud je toto implementace TPC, pak se chová dost podivně.
* Ath5k (Madwifi už si nepamatuju) neumí nastavit vysílací výkon u čipsetu AR5007 - příkaz „iwconfig athX txpower Y“ nemá vůbec žádný efekt. Přitom čipset AR5007 při měření vykazoval velmi pěkné výsledky, bylo by tedy dobré ho podporovat.

=== Implementace ===
Pro implementaci správného nastavování TX power je potřeba mít měřák, který umí změřit EVM a vysílací výkon pro každý packet zvlášť.

To je např. R&S FSV nebo možná i Agilent N4010A. Ani jeden z nich teď bohužel nemáme k dispozici.

== Ambient noise immunity - ANI ==
Karty Atheros mají přímo v HW implementováno "vylepšení" funkce za přítomnosti šumu, o kterém zatím pořádně nevíme, jak funguje.

Nicméně víme, že ve starém Madwifi a v Mikrotiku je s nastavováním ANI spojen bug, který např. u karet CM9 způsobí, že karta při jakémkoli rušení (i ve vedlejších kanálech) přestane téměř uplně vysílat.

ath5k má podporu ANI na svém TODO listu s tím, že zatím se vlastnost ANI v ovladači vůbec neřeší.

== Ruční testování - podprojekt "měřící pracoviště" ==
Abychom vlastnosti "TX Power" a "ANI" neladili naslepo, je vysoce vhodné mít k dispozici měřáky, které teď bohužel nemáme.
A nemáme na ně ani peníze. Více v mailech.

== Automatické testování - podprojekt "WiFi pískoviště" ==

Vývojáři kernelové skupiny Linux Wireless mají na svých stránkách téma pro Google Summer of Code 2009: [http://linuxwireless.org/en/developers/GSoC Automation of testing using mac80211_hwsim and Orbit].

[http://www.orbit-lab.org/ Projekt Orbit] (tj. WiFi sandbox s více než 400 uzly) je super nápad, ale bohužel zaměřený jen na vnitřní wifi sítě.

Já navrhuji dotáhnout tento nápad ještě dál:
#do projektu "Databáze HW" přijímat pokud možno vždy 2 zařízení (pro možnost testování funkce příjmu & vysílání na jednom typu zařízení, což by mělo vždy fungovat nejlíp)
#zařízení nevracet hned, ale zapojovat je na delší dobu do našeho vlastního "pískoviště" (sandbox-u)
#náš sandbox nebude mít antény (jako projekt Orbit), ale jednotlivá zařízení budeme propojovat kabely, couplery, atenuátory (nejlépe programovatelnými), a RF switchi (nejlépe programovatelnými). Tím budeme schopni simulovat téměř jakoukoli topoligii a téměř jakékoli vnější podmínky, které se vyskytují v našich sítích - včetně efektů skrytých uzlů, multipath šíření (s použitím generátorů R&S nebo GNU radio), lokálních šumů, velkých zpoždění (speciální zařízení = "kilometrový koaxiál").
#jako diplomku zadat testovací SW, který pojede na některých uzlech tohoto pískoviště a bude testovat a měřit chování driveru za definovaných a opakovatelných podmínek.

Ath5k

2009-09-19T07:00:06Z

Dulik: /* Administrativa */

Toto je kopie textu z wiki.nfx.cz
= Úvod =

Vývoj ovladače Madwifi byl ukončen, nelze čekat přidání podpory dalšího hardwaru, nanejvýš portování na nové verze kernelu. Kód se dostal do stavu, kdy je další vývoj v podstatě nemožný, uvědomují si to i jeho autoři. Ti proto od Madwifi utekli k ovladači Ath5k, který je součástí kernelu. Bohužel zatím není příliš stabilní, především v režimu AP (jsou problémy s beacony).

Cílem tohoto projektu je opravit chyby ovladače Ath5k, aby se dal používat na našich AP namísto Madwifi a začlenit tyto změny do kernelu, abychom si nemuseli udržovat vlastní větev (což by bylo náročnější než samotná oprava chyb).

Inspirovat se můžeme ovladačem Atheros ve FreeBSD, který

* funguje bez problémů
* od verze 7.2 je i kompletně open-source (včetně HALu)
* od [http://svn.freebsd.org/viewvc/base?view=revision&revision=186904 ledna 2009] má [http://svn.freebsd.org/viewvc/base/head/sbin/ifconfig/ifconfig.8?r1=184057&r2=186904&pathrev=186904 základní podporu přístupové metody TDMA], která (kdyby byla dotažena do detailů) by vyřešila problém skrytých uzlů ve venkovních wifi sítích

= Finance =
Na 12. VH NFX (6.9.2009 ve Slavičíně) byl odsouhlasen následující rozpis příspěvků na tento projekt do konce roku 2009 (pozn. Dulik: rozpis částek je neveřejný, nemám explicitní svolení od jednotlivých sdružení ke zveřejňování jejich příspěvků)
* Klfree
* Unart
* Czf-praha
* Unhfree
* KHnet
* Bubakov.net

== Kontaktní osoby ==
Za výše uvedená sdružení budou o směrování projektu rozhodovat následující garanti:
* KLFree: [[user:JaSt|Jast]] ?
* UnArt: [[user:Dulik|Dulik]]
* Czf-praha: [[user:8an|8an]] ?
* Unhfree: [[user:Litin|Litin]] ?
* Bubakov.net:

= Návrh harmonogramu prací =
Harmonogram vychází z toho, že pro začátek nemáme ani jeden měřící přístroj, který by umožňoval zobrazovat TX power a EVM vysílaných packetů pro každý packet zvlášť - viz odstavec „TX power“. Musíme proto začít vývoj tam, kde měření TX power nepotřebujeme – např. testováním & případnými úpravami modu „AP“.

== Administrativa ==
Co je potřeba udělat hned na začátku:
# Dulik: Napsat ostatním vývojářům ath5k (asi na mailing list ath5k-devel@lists.ath5k.org), že NFX se rozhodlo podpořit vývoj ath5k vlastním fulltime vývojářem a poslat jim níže uvedený návrh oblastí, které chceme vylepšit. Hotovo, viz [url=https://lists.ath5k.org/pipermail/ath5k-devel/2009-September/002744.html]mailing list ath5k[/url].

== Testy/úpravy modu AP ==
ath5k, stejně jako další drivery založené na novém kernel API mac80211, nemá mód AP implementovaný přímo v sobě. Mod AP se tedy nerealizuje přímo na úrovni kernel driveru jako v Madwifi, ale na úrovni userspace démona [http://linuxwireless.org/en/users/Documentation/hostapd#About_hostapd hostapd], který přijímá a odesílá 802.11 control frames packety z interface nastaveného do monitor modu.

Ve srovnání s Madwifi je toto naprosto jiný přístup a dá se očekávat, že vše nebude fungovat tak, jak má.

Úvodní testy modu AP dělal 8an (prosím o doplnění, co funguje nebo nefunguje ...)

== TX power ==
Ath5k i Madwifi nastavují špatně vysílací výkon (TX power), který je nastavován zesílením výstupního zesilovače.

Každý typ karty má trochu jinak udělanou výstupní (TX) část, takže jednotlivé typy karet se od sebe dost liší charakteristikami TX komponent.

Protože vyšší data rates (např. 54MBit/s – 64QAM) mají mnohem vyšší nároky na linearitu výstupního zesilovače než nižší modulace (6Mbit/s – BPSK), je nutné TX power nastavovat před vysláním každého packetu podle data rate daného packetu.

TX power by měl být nastavován na hodnoty, doporučené výrobcem karty, které jsou uloženy v EEPROM(??) každé karty. Tyto hodnoty výrobce získá např. tak, že změří EVM svojí karty na jednotlivých bit rates v závislosti na nastaveném TX power, s tím, že pro každou bit rate zaznamená hodnotu TX power, při které EVM nepřekračuje meze definované daným standardem 802.11a/b/g.

Je možné, že někteří výrobci hodnoty v EEPROM neuvádějí správně (tj. nechce se jim měřit EVM), proto by ath5k měl umožňovat nastavit TX power pro každý bit rate ručně – tak, jak to umí Mikrotik (nebo se tak aspoň tváří). Popřípadě by alespoň mělo být možné do EEPROM nějaký nástrojem zapsat správné hodnoty.

Současný stav:

Z měření na spektráku FSV vyplynulo toto:

* ath5k (kernel 2.6.30 z debian unstable) vůbec nenastavuje vysílací výkon dle aktuálního data rate. Všechny packety jsou odesílány se stejným vysílacím výkonem, takže EVM u vyšších data rates pak překračuje povolené hodnoty
* Madwifi (poslední SVN verze) nastavuje vysílací výkon pro každý packet zvlášť, ale není jasné, jak – packety při pevně nastaveném bitrate a pevných vnějších podmínkách jsou vysílány s různými hodnotami TX power, následkem čehož EVM občas „vystřelí“ mimo povolené mezi. Pokud je toto implementace TPC, pak se chová dost podivně.
* Ath5k (Madwifi už si nepamatuju) neumí nastavit vysílací výkon u čipsetu AR5007 - příkaz „iwconfig athX txpower Y“ nemá vůbec žádný efekt. Přitom čipset AR5007 při měření vykazoval velmi pěkné výsledky, bylo by tedy dobré ho podporovat.

=== Implementace ===
Pro implementaci správného nastavování TX power je potřeba mít měřák, který umí změřit EVM a vysílací výkon pro každý packet zvlášť.

To je např. R&S FSV nebo možná i Agilent N4010A. Ani jeden z nich teď bohužel nemáme k dispozici.

== Ambient noise immunity - ANI ==
Karty Atheros mají přímo v HW implementováno "vylepšení" funkce za přítomnosti šumu, o kterém zatím pořádně nevíme, jak funguje.

Nicméně víme, že ve starém Madwifi a v Mikrotiku je s nastavováním ANI spojen bug, který např. u karet CM9 způsobí, že karta při jakémkoli rušení (i ve vedlejších kanálech) přestane téměř uplně vysílat.

ath5k má podporu ANI na svém TODO listu s tím, že zatím se vlastnost ANI v ovladači vůbec neřeší.

== Ruční testování - podprojekt "měřící pracoviště" ==
Abychom vlastnosti "TX Power" a "ANI" neladili naslepo, je vysoce vhodné mít k dispozici měřáky, které teď bohužel nemáme.
A nemáme na ně ani peníze. Více v mailech.

== Automatické testování - podprojekt "WiFi pískoviště" ==

Vývojáři kernelové skupiny Linux Wireless mají na svých stránkách téma pro Google Summer of Code 2009: [http://linuxwireless.org/en/developers/GSoC Automation of testing using mac80211_hwsim and Orbit].

[http://www.orbit-lab.org/ Projekt Orbit] (tj. WiFi sandbox s více než 400 uzly) je super nápad, ale bohužel zaměřený jen na vnitřní wifi sítě.

Já navrhuji dotáhnout tento nápad ještě dál:
#do projektu "Databáze HW" přijímat pokud možno vždy 2 zařízení (pro možnost testování funkce příjmu & vysílání na jednom typu zařízení, což by mělo vždy fungovat nejlíp)
#zařízení nevracet hned, ale zapojovat je na delší dobu do našeho vlastního "pískoviště" (sandbox-u)
#náš sandbox nebude mít antény (jako projekt Orbit), ale jednotlivá zařízení budeme propojovat kabely, couplery, atenuátory (nejlépe programovatelnými), a RF switchi (nejlépe programovatelnými). Tím budeme schopni simulovat téměř jakoukoli topoligii a téměř jakékoli vnější podmínky, které se vyskytují v našich sítích - včetně efektů skrytých uzlů, multipath šíření (s použitím generátorů R&S nebo GNU radio), lokálních šumů, velkých zpoždění (speciální zařízení = "kilometrový koaxiál").
#jako diplomku zadat testovací SW, který pojede na některých uzlech tohoto pískoviště a bude testovat a měřit chování driveru za definovaných a opakovatelných podmínek.

Ath5k

2009-09-19T06:49:58Z

Dulik: Nová stránka: Toto je kopie textu z wiki.nfx.cz = Úvod = Vývoj ovladače Madwifi byl ukončen, nelze čekat přidání podpory dalšího hardwaru, nanejvýš portování na nové verze kernelu....

Toto je kopie textu z wiki.nfx.cz
= Úvod =

Vývoj ovladače Madwifi byl ukončen, nelze čekat přidání podpory dalšího hardwaru, nanejvýš portování na nové verze kernelu. Kód se dostal do stavu, kdy je další vývoj v podstatě nemožný, uvědomují si to i jeho autoři. Ti proto od Madwifi utekli k ovladači Ath5k, který je součástí kernelu. Bohužel zatím není příliš stabilní, především v režimu AP (jsou problémy s beacony).

Cílem tohoto projektu je opravit chyby ovladače Ath5k, aby se dal používat na našich AP namísto Madwifi a začlenit tyto změny do kernelu, abychom si nemuseli udržovat vlastní větev (což by bylo náročnější než samotná oprava chyb).

Inspirovat se můžeme ovladačem Atheros ve FreeBSD, který

* funguje bez problémů
* od verze 7.2 je i kompletně open-source (včetně HALu)
* od [http://svn.freebsd.org/viewvc/base?view=revision&revision=186904 ledna 2009] má [http://svn.freebsd.org/viewvc/base/head/sbin/ifconfig/ifconfig.8?r1=184057&r2=186904&pathrev=186904 základní podporu přístupové metody TDMA], která (kdyby byla dotažena do detailů) by vyřešila problém skrytých uzlů ve venkovních wifi sítích

= Finance =
Na 12. VH NFX (6.9.2009 ve Slavičíně) byl odsouhlasen následující rozpis příspěvků na tento projekt do konce roku 2009 (pozn. Dulik: rozpis částek je neveřejný, nemám explicitní svolení od jednotlivých sdružení ke zveřejňování jejich příspěvků)
* Klfree
* Unart
* Czf-praha
* Unhfree
* KHnet
* Bubakov.net

== Kontaktní osoby ==
Za výše uvedená sdružení budou o směrování projektu rozhodovat následující garanti:
* KLFree: [[user:JaSt|Jast]] ?
* UnArt: [[user:Dulik|Dulik]]
* Czf-praha: [[user:8an|8an]] ?
* Unhfree: [[user:Litin|Litin]] ?
* Bubakov.net:

= Návrh harmonogramu prací =
Harmonogram vychází z toho, že pro začátek nemáme ani jeden měřící přístroj, který by umožňoval zobrazovat TX power a EVM vysílaných packetů pro každý packet zvlášť - viz odstavec „TX power“. Musíme proto začít vývoj tam, kde měření TX power nepotřebujeme – např. testováním & případnými úpravami modu „AP“.

== Administrativa ==
Co je potřeba udělat hned na začátku:
# 8an: vyřídit živnosťák
# 8an: Poslat statutárům NFX fakturační údaje pro vystavení objednávky
# Dulik: Napsat ostatním vývojářům ath5k (asi na mailing list ath5k-devel@lists.ath5k.org), že NFX se rozhodlo podpořit vývoj ath5k vlastním fulltime vývojářem a poslat jim níže uvedený návrh oblastí, které chceme vylepšit. Hotovo, viz [url=https://lists.ath5k.org/pipermail/ath5k-devel/2009-September/002744.html]mailing list ath5k[/url].

== Testy/úpravy modu AP ==
ath5k, stejně jako další drivery založené na novém kernel API mac80211, nemá mód AP implementovaný přímo v sobě. Mod AP se tedy nerealizuje přímo na úrovni kernel driveru jako v Madwifi, ale na úrovni userspace démona [http://linuxwireless.org/en/users/Documentation/hostapd#About_hostapd hostapd], který přijímá a odesílá 802.11 control frames packety z interface nastaveného do monitor modu.

Ve srovnání s Madwifi je toto naprosto jiný přístup a dá se očekávat, že vše nebude fungovat tak, jak má.

Úvodní testy modu AP dělal 8an (prosím o doplnění, co funguje nebo nefunguje ...)

== TX power ==
Ath5k i Madwifi nastavují špatně vysílací výkon (TX power), který je nastavován zesílením výstupního zesilovače.

Každý typ karty má trochu jinak udělanou výstupní (TX) část, takže jednotlivé typy karet se od sebe dost liší charakteristikami TX komponent.

Protože vyšší data rates (např. 54MBit/s – 64QAM) mají mnohem vyšší nároky na linearitu výstupního zesilovače než nižší modulace (6Mbit/s – BPSK), je nutné TX power nastavovat před vysláním každého packetu podle data rate daného packetu.

TX power by měl být nastavován na hodnoty, doporučené výrobcem karty, které jsou uloženy v EEPROM(??) každé karty. Tyto hodnoty výrobce získá např. tak, že změří EVM svojí karty na jednotlivých bit rates v závislosti na nastaveném TX power, s tím, že pro každou bit rate zaznamená hodnotu TX power, při které EVM nepřekračuje meze definované daným standardem 802.11a/b/g.

Je možné, že někteří výrobci hodnoty v EEPROM neuvádějí správně (tj. nechce se jim měřit EVM), proto by ath5k měl umožňovat nastavit TX power pro každý bit rate ručně – tak, jak to umí Mikrotik (nebo se tak aspoň tváří). Popřípadě by alespoň mělo být možné do EEPROM nějaký nástrojem zapsat správné hodnoty.

Současný stav:

Z měření na spektráku FSV vyplynulo toto:

* ath5k (kernel 2.6.30 z debian unstable) vůbec nenastavuje vysílací výkon dle aktuálního data rate. Všechny packety jsou odesílány se stejným vysílacím výkonem, takže EVM u vyšších data rates pak překračuje povolené hodnoty
* Madwifi (poslední SVN verze) nastavuje vysílací výkon pro každý packet zvlášť, ale není jasné, jak – packety při pevně nastaveném bitrate a pevných vnějších podmínkách jsou vysílány s různými hodnotami TX power, následkem čehož EVM občas „vystřelí“ mimo povolené mezi. Pokud je toto implementace TPC, pak se chová dost podivně.
* Ath5k (Madwifi už si nepamatuju) neumí nastavit vysílací výkon u čipsetu AR5007 - příkaz „iwconfig athX txpower Y“ nemá vůbec žádný efekt. Přitom čipset AR5007 při měření vykazoval velmi pěkné výsledky, bylo by tedy dobré ho podporovat.

=== Implementace ===
Pro implementaci správného nastavování TX power je potřeba mít měřák, který umí změřit EVM a vysílací výkon pro každý packet zvlášť.

To je např. R&S FSV nebo možná i Agilent N4010A. Ani jeden z nich teď bohužel nemáme k dispozici.

== Ambient noise immunity - ANI ==
Karty Atheros mají přímo v HW implementováno "vylepšení" funkce za přítomnosti šumu, o kterém zatím pořádně nevíme, jak funguje.

Nicméně víme, že ve starém Madwifi a v Mikrotiku je s nastavováním ANI spojen bug, který např. u karet CM9 způsobí, že karta při jakémkoli rušení (i ve vedlejších kanálech) přestane téměř uplně vysílat.

ath5k má podporu ANI na svém TODO listu s tím, že zatím se vlastnost ANI v ovladači vůbec neřeší.

== Ruční testování - podprojekt "měřící pracoviště" ==
Abychom vlastnosti "TX Power" a "ANI" neladili naslepo, je vysoce vhodné mít k dispozici měřáky, které teď bohužel nemáme.
A nemáme na ně ani peníze. Více v mailech.

== Automatické testování - podprojekt "WiFi pískoviště" ==

Vývojáři kernelové skupiny Linux Wireless mají na svých stránkách téma pro Google Summer of Code 2009: [http://linuxwireless.org/en/developers/GSoC Automation of testing using mac80211_hwsim and Orbit].

[http://www.orbit-lab.org/ Projekt Orbit] (tj. WiFi sandbox s více než 400 uzly) je super nápad, ale bohužel zaměřený jen na vnitřní wifi sítě.

Já navrhuji dotáhnout tento nápad ještě dál:
#do projektu "Databáze HW" přijímat pokud možno vždy 2 zařízení (pro možnost testování funkce příjmu & vysílání na jednom typu zařízení, což by mělo vždy fungovat nejlíp)
#zařízení nevracet hned, ale zapojovat je na delší dobu do našeho vlastního "pískoviště" (sandbox-u)
#náš sandbox nebude mít antény (jako projekt Orbit), ale jednotlivá zařízení budeme propojovat kabely, couplery, atenuátory (nejlépe programovatelnými), a RF switchi (nejlépe programovatelnými). Tím budeme schopni simulovat téměř jakoukoli topoligii a téměř jakékoli vnější podmínky, které se vyskytují v našich sítích - včetně efektů skrytých uzlů, multipath šíření (s použitím generátorů R&S nebo GNU radio), lokálních šumů, velkých zpoždění (speciální zařízení = "kilometrový koaxiál").
#jako diplomku zadat testovací SW, který pojede na některých uzlech tohoto pískoviště a bude testovat a měřit chování driveru za definovaných a opakovatelných podmínek.

CZFROAM

2009-09-18T08:36:44Z

Dulik: /* Právní a organizační náležitosti (dohody, smlouvy...) */

=Úvod=
CZFROAM je projekt jednotné Autentizační a Autorizační Infrastruktury (AAI) pro CZFree sítě.
Je inspirován projekty Eduroam a Edugain, které umožňují studentům používat zdarma počítačové sítě a aplikace vzdělávacích institucí po celé Evropě.

=Základní požadavky na celý systém=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Zabezpečení=

==Certifikáty==
Certifikáty jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX. Je potřeba ale zjistit cenové podmínky a dle nich nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===
==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

=Právní a organizační náležitosti (dohody, smlouvy...)=

Eduroam má toto vše pěkně definováno v dokumentu "[http://www.eduroam.cz/doku.php?id=cs:roamingova_politika Roamingová politika]".

CZFROAM

2009-09-18T08:31:54Z

Dulik: /* Úvod */

=Úvod=
CZFROAM je projekt jednotné Autentizační a Autorizační Infrastruktury (AAI) pro CZFree sítě.
Je inspirován projekty Eduroam a Edugain, které umožňují studentům používat zdarma počítačové sítě a aplikace vzdělávacích institucí po celé Evropě.

=Základní požadavky na celý systém=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Zabezpečení=

==Certifikáty==
Certifikáty jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX. Je potřeba ale zjistit cenové podmínky a dle nich nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===
==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

=Právní a organizační náležitosti (dohody, smlouvy...)=

CZFROAM

2009-09-18T08:30:54Z

Dulik: /* Základní požadavky */

=Úvod=
CZFROAM je projekt jednotné Autentizační a Autorizační Infrastruktury (AAI) pro CZFree sítě.
Je inspirován projekty Eduroam a Edugain, které umožňují studentům

=Základní požadavky na celý systém=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Zabezpečení=

==Certifikáty==
Certifikáty jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX. Je potřeba ale zjistit cenové podmínky a dle nich nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===
==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

=Právní a organizační náležitosti (dohody, smlouvy...)=

CZFROAM

2009-09-18T08:27:36Z

Dulik: /* Security */

=Základní požadavky=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Zabezpečení=

==Certifikáty==
Certifikáty jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX. Je potřeba ale zjistit cenové podmínky a dle nich nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===
==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

=Právní a organizační náležitosti (dohody, smlouvy...)=

CZFROAM

2009-09-18T08:27:10Z

Dulik: /* Certifikáty */

=Základní požadavky=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Security=

==Certifikáty==
Certifikáty jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX. Je potřeba ale zjistit cenové podmínky a dle nich nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===
==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

=Právní a organizační náležitosti (dohody, smlouvy...)=

CZFROAM

2009-09-18T08:26:39Z

Dulik: /* Certifikáty */

=Základní požadavky=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Security=

==Certifikáty==
Jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX. Je potřeba ale zjistit cenové podmínky a dle nich nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===
==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

=Právní a organizační náležitosti (dohody, smlouvy...)=

CZFROAM

2009-09-18T08:26:02Z

Dulik: /* CZFROAM-simple */

=Základní požadavky=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Security=

==Certifikáty==
Jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX.

Je potřeba ale zjistit cenové podmínky a nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===
==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

=Právní a organizační náležitosti (dohody, smlouvy...)=

CZFROAM

2009-09-18T08:24:41Z

Dulik: /* Certifikáty */

=Základní požadavky=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Security=

==Certifikáty==
Jsou potřeba jak pro [[#CZFROAM-simple|CZFROAM-simple]], tak pro [[#WPA2|WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX.

Je potřeba ale zjistit cenové podmínky a nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===
==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

CZFROAM

2009-09-18T08:24:11Z

Dulik: /* Security */

=Základní požadavky=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Security=

==Certifikáty==
Jsou potřeba jak pro [[#CZFROAM-simple]], tak pro [[#WPA2]].

[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX.

Je potřeba ale zjistit cenové podmínky a nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.
==WPA2==
(doplnit)
===Nastavení Linux AP===
===Nastavení Mikrotik AP===
==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

CZFROAM

2009-09-18T08:22:38Z

Dulik: /* Certifikáty */

=Základní požadavky=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Security=
==WPA2==
(doplnit)
==Certifikáty==
[http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html Free certifikáty] bohužel nejsou vydávány CA uznávanými všemi web prohlížeči.

CESNET (nejen) pro Eduroam používá certifikáty [http://www.cesnet.cz/pki/cs/st-guide-gs.html SureServerEDU] společnosti GlobalSign, které mají členové CESNETu "zdarma". Cenu certifikátů SureServerEDU se mi bohužel nepodařilo vypátrat, ale něco takového (projekt "společný nákup certifikátů" od nějaké velké autority, defaultně instalované ve všech prohlížečích), bychom mohli spáchat i pod křídly NFX.

Je potřeba ale zjistit cenové podmínky a nadefinovat, za jakých podmínek se budou certifikáty členům NFX poskytovat.

===Nastavení Linux AP===
===Nastavení Mikrotik AP===
==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

CZFROAM

2009-09-18T07:57:30Z

Dulik:

=Základní požadavky=
*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - [[#CZFROAM-simple|czfroam(.czf)-simple]] či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

=Security=
==WPA2==
(doplnit)
===Certifikáty===
===Nastavení Linux AP===
===Nastavení Mikrotik AP===
==CZFROAM-simple==
Pro AP, která neumožňují virtuální SSID popř. nemají dostatečnou implementaci WPA2.
Pro zamezení útoků phishing/pharming lze při webovém přihlašování použít:
#InfoCards popř. InfoCards + OpenID
#One-Time-Password kalkulátor (implementace pro mobilní telefon)

CZFROAM

2009-09-18T07:50:17Z

Dulik:

*sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.
*sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.
*Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - czfroam(.czf)-simple či jakýkoli jiný essid.
*Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf
*Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

* id 1 - řádní členové
* id 2 - czf only
* id 3 - nonczf sítě
* id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

CZFROAM

2009-09-18T07:49:15Z

Dulik:

Snažil jsem se zapracovat různé hinty, které mi za posledních XY dní přišli na mail/icq/pm.

- Existuje následující řešení:

- sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu.

- sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu.

- Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - czfroam(.czf)-simple či jakýkoli jiný essid.

- Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf

- Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.

Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:

- id 1 - řádní členové
- id 2 - czf only
- id 3 - nonczf sítě
- id 4 - zahraniční CZF-like sítě

To pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)

Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.

Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné.

Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat

Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).

Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek .

Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf

Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

CZFROAM

2009-09-18T07:48:37Z

Dulik: Nová stránka: Snažil jsem se zapracovat různé hinty, které mi za posledních XY dní přišli na mail/icq/pm.- Existuje následující řešení: - sdružení s peeringem do CZF a internetem b...

Snažil jsem se zapracovat různé hinty, které mi za posledních XY dní přišli na mail/icq/pm.- Existuje následující řešení: - sdružení s peeringem do CZF a internetem budou moct používat czfroam - budou přímo lidi autentizovat pomoci radiusu. - sdružení s peeringem pouze do CZF budou moct používat czfroam.czf, - budou přímo lidi autentizovat pomoci radiusu. - Sdružení, které nebude roamovat přímo pomocí radiusu (např. má problém s virtual AP - viz P12, bude moct použít autentizaci přes web (tam je essid jedno). Tj. bude autentizovat vzdálene uživatele pomocí webu - czfroam(.czf)-simple či jakýkoli jiný essid.- Poté tu máme síť, která přímo nepatří pod CZF ale chce CZFRoamu nabídnout např. internet (když se nám podaří třeba dohodnout s nějakým úřadem apod) czfroam.nonczf- Nakonec, pokud projekt dozraje se k nám můžou přidat i zahraniční sítě, tam bych nechal pravidla celkem otevřená a byla by dle dohody se skupinami.Uživatelské třídy se dají řešit také. Vrámci radiusu můžeme udělat tzv. skupiny ID:- id 1 - řádní členové- id 2 - czf only- id 3 - nonczf sítě- id 4 - zahraniční CZF-like sítěTo pokud jsem správně pochopil se dělá dle vlanů na radiusu (jsi skupina 1? Letiš do Vlanu id ..., skupina 2? Letiš tam a tam..)Každý subjekt si bude moct vybrat jak koho bude priorizovat, může například i členy jednotlivých sítí odmítat. Může i například vybrat, že VIP bude moct na internet, členové nikoliv. Nonczf sítě budou moct třeba jen do CZFree a pokud budou dosti šikovní, udělají si nějakou rouru do CZFree kde budou mít možnost svůj provoz směrovat přes VPN.'''Jelikož žijeme ve svobodné síti, měli by si všechny subjekty peeringy mezi sebou dohadovat. Tj. princip NIX-u - může vstoupit kdokoli, ale svoje kamarády si musí sehnat. A to jakým způsobem uzná za vhodné. Každý subjekt by si mohl zvolit, zda-li bude mít open peering nebo closed. Open by znamenal, že se bude moct přímo připojit na hlavní radius server, na kterém budou ostatní otevřené sítě a bude tak moct ihned s nimi peerovat bez jakékoli dohody (pokud budou dva subjekty v nepohodě vrámci jedné oblasti, můžou ve vyjímečných případech peering mezi sebou odmítat - jednoduché zabanování realmu v radiusu). V případě closed policy si holt bude muset každého peera nasmlouvat [[Image:smile.gif]] '''Bylo by také možné, že se seskupí pár subjektů, které si založí vlastni peering skupinu a do ní budou moci přijímat členy dle svých pravidel, které si ve skupině zvolí. Bude možné i propojovat více skupin dohromady (logicky budou muset mít vlastní radius server).Napadá mě ještě, že czfroam by byl jakoby samostatný subjekt (něco podobného jako NFX). Pak by každý subjekt, který je czfroamu členem, musel platit nějaký symbolický měsíční příspevek [[Image:smile.gif]].Bude také možné, že nějake sdružení si dohodne s jiným sdružením možnost přístupu na net pro svoje členy (výměnou). Poté pořád budou muset mit czfroam.czf [[Image:smile.gif]]Ještě doplnění - vrámci skupin bude možné třeba i pořídit internetovou konektivitu dohromady (každý člen zaplatí nějaký díl) a případně se o to dělit..

Projekty

2009-09-18T07:46:28Z

Dulik:

* [[CZF NIC]] - centální autorita zajišťující provoz a administraci DNS uvnitř sítě
* [[CZF RIPE]] (nebo take CZF INR) - snaha zjednodušit, zpřehlednit a zdokumentovat alokaci CZF IP, ASN atd.
* [[NCX]] (Neutral Czfree eXchange) - projekt, jehož cílem je koordinovat propojení sítí pomocí tunelů
* [[NFX]] (Neutral czFree eXchange) - zajmové sdružení právnických osob, které se snaží o nativní propojení CZF-compatible sítí
* [[IRC]] (Internet Relay Chat) - realtime komunikační síť CZFree
* [[CZF4BFU]] (CZFree For BFU) - system inzerovani internich zdroju CZFree
* [[VF]] (Veřejné fórum) - veřejná diskuse CZFree
* [[CZFROAM]]

WRT-311/312

2009-06-02T11:39:27Z

Dulik: /* JTAG */

Někomu se prý zahřívá až do zatuhnutí. Já ho mám na dvou šrouber na zdi, konektorama a anténou nahoru a je v pohodě, naplacato by asi potřeboval přidat větrák.

{{Hardware samostatný síťový
| obrázek = Wrt-311.jpg
| normy = asi IEEE 802.3 i/u/x IEEE 802.11 b
| módy = Ethernet 10BASE-T Ethernet 100BASE-T AP Klient
| konektory = neznámé
| systém = neznámý
| chipset = Realtek 8186
| služby = neznámé
| zabezpečení = neznámé
| výrobce = neznámý
| dokumentace = žádná
| prodejce = neznámý
| poznámky = -
}}

== Seriová konzole ==
*[[Seriová konzole WRT-311]]

== JTAG ==
*[http://olomouc.czfree.net/forum/showthread.php?postid=178899#post178899 Rozchození JTAG na RTL8186]

== Firmware ==

Kompletně v češtině

==Externí odkazy==
http://www.straightcore.net/cz/products.php

WRT-311/312

2009-06-02T11:39:09Z

Dulik: /* Firmware */

Někomu se prý zahřívá až do zatuhnutí. Já ho mám na dvou šrouber na zdi, konektorama a anténou nahoru a je v pohodě, naplacato by asi potřeboval přidat větrák.

{{Hardware samostatný síťový
| obrázek = Wrt-311.jpg
| normy = asi IEEE 802.3 i/u/x IEEE 802.11 b
| módy = Ethernet 10BASE-T Ethernet 100BASE-T AP Klient
| konektory = neznámé
| systém = neznámý
| chipset = Realtek 8186
| služby = neznámé
| zabezpečení = neznámé
| výrobce = neznámý
| dokumentace = žádná
| prodejce = neznámý
| poznámky = -
}}

== Seriová konzole ==
*[[Seriová konzole WRT-311]]

== JTAG ==
*[Rozchození JTAG na RTL8186 http://olomouc.czfree.net/forum/showthread.php?postid=178899#post178899]

== Firmware ==

Kompletně v češtině

==Externí odkazy==
http://www.straightcore.net/cz/products.php

Seriová konzole WRT-311

2009-06-02T10:12:24Z

Dulik:

[http://ispforum.cz/viewtopic.php?f=10&t=2276 Na této stránce se objevila následující informace]:

WRT-311 změna MAC - rozchození konzole

od Jiří Staněk v 10 kvě 2007 00:40

Zdravím,

Laboruji tady zrovna s WRT-311, pokud by se někomu hodila konzole pro zotavení tak tady je návod:

Připojení:
sys konektor s označením J4
Při pohledu od portu:
*1 - VCC (3,2V)
*2 - TX
*3 - RX
*4 - GND

nastavení terminálu:

Rychlost 38400
8 bit
žádná parita
1 stop bit
Xon/Soft

A hurá na to!

Po připojení vypíše asi něco takového:

UART1 output test ok
Uart init
mfid=000000c2 devid=00002249
Found 1 x 2M flash memory
---RealTek(RTL8186)at 2005.09.14-18:49+0800 version 1.3b [32bit](180MHz)
no sys signature at 00010000!
Jump to image start=0x80300000...
decompressing kernel:
Uncompressing Linux... done, booting the kernel.
done decompressing kernel.
early printk enabled
Determined physical RAM map:
memory: 01000000 @ 00000000 (usable)
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/mtdblock1 console=0 single
Calibrating delay loop... 178.99 BogoMIPS
Memory: 14252k/16384k available (1604k kernel code, 2132k reserved, 128k data, 48k init, 0k highmem)
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
check_wait... unavailable.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Serial driver version 6.02 (2003-03-12) with no serial options enabled
ttyS00 at 0x00c3 (irq = 3) is a rtl_uart1
state->flags=00000000
Realtek GPIO Driver for Flash Reload Default
block: 64 slots per queue, batch=16
PPP generic driver version 2.4.1
PPP MPPE Compression module registered
RealTek E-Flash System Driver. (C) 2002 RealTek Corp.
Found 1 x 2M Byte MXIC MX29LV160AB at 0xbe000000
Creating 2 MTD partitions on "DiskOnChip Millennium":
0x00000000-0x00100000 : "boot+cfg+linux"
0x00100000-0x00200000 : "root fs"
RTL8185 driver version 1.9 (2006-03-16)
8186NIC Ethernet driver v0.0.5 (Mar 3, 2006)
eth0: RTL8186-NIC at 0xbd200000, 00:01:02:03:04:05, IRQ 4
eth1: RTL8186-NIC at 0xbd300000, 04:05:06:07:08:09, IRQ 5
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 2048)
ip_conntrack version 2.1 (128 buckets, 1024 max) - 312 bytes per conntrack
PPTP netfilter connection tracking: registered
PPTP netfilter NAT helper: registered
ip_tables: (C) 2000-2002 Netfilter core team
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Ethernet Bridge 008 for NET4.0
VFS: Mounted root (squashfs filesystem) readonly.
Freeing unused kernel memory: 48k freed
mount /proc file system ok!
mount /var file system ok!
init started: BusyBox v1.1.0-pre1 (2006.05.29-20:45+0000) multi-call binary
BusyBox v1.1.0-pre1 (2006.05.29-20:45+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.
Setting opmode
Killing tasks then interfaces
Setting MACs
Setup bridge(s)
device eth0 entered promiscuous mode
eth0:phy is 8305
device wlan0 entered promiscuous mode
device eth1 entered promiscuous mode
eth1:phy is 8305
br0: port 2(wlan0) entering disabled state
device wlan0 left promiscuous mode
br0: port 3(eth1) entering listening state
br0: port 1(eth0) entering listening state
br0: port 3(eth1) entering learning state
br0: port 3(eth1) entering forwarding state
br0: topology change detected, propagating
br0: port 1(eth0) entering learning state
br0: port 1(eth0) entering forwarding state
br0: topology change detected, propagating
Setting up IP
Starting services
Setting Routes
Setting up Firewall
#

Seriová konzole WRT-311

2009-06-02T10:11:25Z

Dulik:

[http://ispforum.cz/viewtopic.php?f=10&t=2276 Na této stránce se objevila následující informace]:

WRT-311 změna MAC - rozchození konzole

od Jiří Staněk v 10 kvě 2007 00:40

Zdravím,

Laboruji tady zrovna s WRT-311, pokud by se někomu hodila konzole pro zotavení tak tady je návod:

Připojení:
sys konektor s označením J4
Při pohledu od portu:
1 - VCC (3,2V)
2 - TX
3 - RX
4 - GND

nastavení terminálu:

Rychlost 38400
8 bit
žádná parita
1 stop bit
Xon/Soft

A hurá na to!

Po připojení vypíše asi něco takového:

UART1 output test ok
Uart init
mfid=000000c2 devid=00002249
Found 1 x 2M flash memory
---RealTek(RTL8186)at 2005.09.14-18:49+0800 version 1.3b [32bit](180MHz)
no sys signature at 00010000!
Jump to image start=0x80300000...
decompressing kernel:
Uncompressing Linux... done, booting the kernel.
done decompressing kernel.
early printk enabled
Determined physical RAM map:
memory: 01000000 @ 00000000 (usable)
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/mtdblock1 console=0 single
Calibrating delay loop... 178.99 BogoMIPS
Memory: 14252k/16384k available (1604k kernel code, 2132k reserved, 128k data, 48k init, 0k highmem)
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
check_wait... unavailable.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Serial driver version 6.02 (2003-03-12) with no serial options enabled
ttyS00 at 0x00c3 (irq = 3) is a rtl_uart1
state->flags=00000000
Realtek GPIO Driver for Flash Reload Default
block: 64 slots per queue, batch=16
PPP generic driver version 2.4.1
PPP MPPE Compression module registered
RealTek E-Flash System Driver. (C) 2002 RealTek Corp.
Found 1 x 2M Byte MXIC MX29LV160AB at 0xbe000000
Creating 2 MTD partitions on "DiskOnChip Millennium":
0x00000000-0x00100000 : "boot+cfg+linux"
0x00100000-0x00200000 : "root fs"
RTL8185 driver version 1.9 (2006-03-16)
8186NIC Ethernet driver v0.0.5 (Mar 3, 2006)
eth0: RTL8186-NIC at 0xbd200000, 00:01:02:03:04:05, IRQ 4
eth1: RTL8186-NIC at 0xbd300000, 04:05:06:07:08:09, IRQ 5
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 2048)
ip_conntrack version 2.1 (128 buckets, 1024 max) - 312 bytes per conntrack
PPTP netfilter connection tracking: registered
PPTP netfilter NAT helper: registered
ip_tables: (C) 2000-2002 Netfilter core team
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Ethernet Bridge 008 for NET4.0
VFS: Mounted root (squashfs filesystem) readonly.
Freeing unused kernel memory: 48k freed
mount /proc file system ok!
mount /var file system ok!
init started: BusyBox v1.1.0-pre1 (2006.05.29-20:45+0000) multi-call binary

BusyBox v1.1.0-pre1 (2006.05.29-20:45+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.
Setting opmode
Killing tasks then interfaces
Setting MACs
Setup bridge(s)
device eth0 entered promiscuous mode
eth0:phy is 8305
device wlan0 entered promiscuous mode
device eth1 entered promiscuous mode
eth1:phy is 8305
br0: port 2(wlan0) entering disabled state
device wlan0 left promiscuous mode
br0: port 3(eth1) entering listening state
br0: port 1(eth0) entering listening state
br0: port 3(eth1) entering learning state
br0: port 3(eth1) entering forwarding state
br0: topology change detected, propagating
br0: port 1(eth0) entering learning state
br0: port 1(eth0) entering forwarding state
br0: topology change detected, propagating
Setting up IP
Starting services
Setting Routes
Setting up Firewall
#

Seriová konzole WRT-311

2009-06-02T10:08:07Z

Dulik: Nová stránka: [http://ispforum.cz/viewtopic.php?f=10&t=2276 Na této stránce se objevila následující informace]: WRT-311 změna MAC - rozchození konzole od Jiří Staněk v 10 kvě 2007 00...

[http://ispforum.cz/viewtopic.php?f=10&t=2276 Na této stránce se objevila následující informace]:

WRT-311 změna MAC - rozchození konzole

od Jiří Staněk v 10 kvě 2007 00:40

Zdravím,

Laboruji tady zrovna s WRT-311, pokud by se někomu hodila konzole pro zotavení tak tady je návod:

Připojení:
sys konektor s označením J4
Při pohledu od portu:
1 - VCC (3,2V)
2 - TX
3 - RX
4 - GND

nastavení terminálu:

Rychlost 38400
8 bit
žádná parita
1 stop bit
Xon/Soft

A hurá na to!

Po připojení vypíše asi něco takového:

UART1 output test ok
Uart init
mfid=000000c2 devid=00002249
Found 1 x 2M flash memory

---RealTek(RTL8186)at 2005.09.14-18:49+0800 version 1.3b [32bit](180MHz)
no sys signature at 00010000!
Jump to image start=0x80300000...
decompressing kernel:
Uncompressing Linux... done, booting the kernel.
done decompressing kernel.
early printk enabled
Determined physical RAM map:
memory: 01000000 @ 00000000 (usable)
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/mtdblock1 console=0 single
Calibrating delay loop... 178.99 BogoMIPS
Memory: 14252k/16384k available (1604k kernel code, 2132k reserved, 128k data, 4
8k init, 0k highmem)
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
check_wait... unavailable.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Serial driver version 6.02 (2003-03-12) with no serial options enabled
ttyS00 at 0x00c3 (irq = 3) is a rtl_uart1
state->flags=00000000
Realtek GPIO Driver for Flash Reload Default
block: 64 slots per queue, batch=16
PPP generic driver version 2.4.1
PPP MPPE Compression module registered
RealTek E-Flash System Driver. (C) 2002 RealTek Corp.
Found 1 x 2M Byte MXIC MX29LV160AB at 0xbe000000
Creating 2 MTD partitions on "DiskOnChip Millennium":
0x00000000-0x00100000 : "boot+cfg+linux"
0x00100000-0x00200000 : "root fs"
RTL8185 driver version 1.9 (2006-03-16)
8186NIC Ethernet driver v0.0.5 (Mar 3, 2006)
eth0: RTL8186-NIC at 0xbd200000, 00:01:02:03:04:05, IRQ 4
eth1: RTL8186-NIC at 0xbd300000, 04:05:06:07:08:09, IRQ 5
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 2048)
ip_conntrack version 2.1 (128 buckets, 1024 max) - 312 bytes per conntrack
PPTP netfilter connection tracking: registered
PPTP netfilter NAT helper: registered
ip_tables: (C) 2000-2002 Netfilter core team
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Ethernet Bridge 008 for NET4.0
VFS: Mounted root (squashfs filesystem) readonly.
Freeing unused kernel memory: 48k freed
mount /proc file system ok!
mount /var file system ok!
init started: BusyBox v1.1.0-pre1 (2006.05.29-20:45+0000) multi-call binary

BusyBox v1.1.0-pre1 (2006.05.29-20:45+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.

Setting opmode
Killing tasks then interfaces
Setting MACs
Setup bridge(s)
device eth0 entered promiscuous mode
eth0:phy is 8305
device wlan0 entered promiscuous mode
device eth1 entered promiscuous mode
eth1:phy is 8305
br0: port 2(wlan0) entering disabled state
device wlan0 left promiscuous mode
br0: port 3(eth1) entering listening state
br0: port 1(eth0) entering listening state
br0: port 3(eth1) entering learning state
br0: port 3(eth1) entering forwarding state
br0: topology change detected, propagating
br0: port 1(eth0) entering learning state
br0: port 1(eth0) entering forwarding state
br0: topology change detected, propagating
Setting up IP
Starting services
Setting Routes
Setting up Firewall
#

WRT-311

2009-06-02T10:06:24Z

Dulik: Nová stránka: *Seriová konzole WRT-311

*[[Seriová konzole WRT-311]]