Australialainen RADIUS- ja suomalainen Internet-insinööriosaaminen yhteen

Tamperelainen Internet-ratkaisutoimittaja Arch Red Oy laajentaa toimintaansa ostamalla australialaisen ohjelmistoyrityksen Open System Consultants Pty Ltd:n (OSC). OSC:n päätuote Radiator RADIUS on markkinoiden monipuolisin Radius-palvelinohjelmisto, johon perustuu laaja portfolio langattomia verkkoja (WLAN, 3G, 4G) yhdistäviä käyttäjätunnistusratkaisuja. Arch Red on tuottanut näitä ratkaisuja operaattori- ja yritysasiakkailleen yhteistyössä OSC:n kanssa jo useiden vuosien ajan.

Yrityskaupan myötä Arch Redille avautuu OSC:n kymmenien aktiivisten jälleenmyyjien verkosto lähes 50 maahan sekä suorat asiakaskontaktit kymmeniin operaattoreihin ja vielä useampiin suuryrityksiin, yliopistoihin ja organisaatioihin ympäri maailman.

"Yhdistämällä Arch Redin ja OSC:n pystymme tarjoamaan yhteisille asiakkaillemme ratkaisuja Internet- ja käyttäjäntunnistus- ja hallintapalveluiden toteuttamiseen entistä paremmin ja monipuolisemmin", kertoo Arch Red Oy:n toimitusjohtaja, Karri Huhtanen ja jatkaa:

"Emme tule pelkästään jatkamaan Radiatorin kehitystä vaan haemme nopeasti merkittävää lisäkasvua tarjoamalla myös valmiita käyttäjäntunnistusratkaisuja Internetin yli muun muassa tilauspohjaisina pilvipalveluina."

Lisätietoja:

Karri Huhtanen

toimitusjohtaja, Arch Red Oy

+358 44 087 6546

www.archred.fi

Taustaa yrityksistä

Arch Red on Internet-asiantuntijayritys, joka tarjoaa sekä tuotteita että palveluita palveluntarjoajille langattomien verkkojen (WLAN, 3G, 4G) käyttäjäntunnistukseen, -hallintaan ja näiden väliseen verkkovierailuun. Arch Red tarjoaa myös ratkaisuja ja palveluita white-label WLAN- ja yhteisöverkkojen käyttäjien ja vieraiden tunnistukseen.

Open System Consultants on australialainen yritys, jonka päätuotteena on Radiator RADIUS-palvelinohjelmisto, jolla on asiakkaita 180 eri maassa ja jälleenmyyjiä yli 46 maassa maailman ympäri. Radiator RADIUS-palvelinohjelmistoa käytetään operaattori- ja palveluntarjoajaverkoissa käyttäjäntunnistuksen, provisioinnin ja konfiguraationhallintaan. Radius-palvelin on keskeinen komponentti, kun toteutettaan esimerkiksi WLAN-verkkojen käyttäjäntunnistusratkaisuja tai kun niitä yhdistetään 3G/4G-verkkojen käyttäjätunnistukseen.

eduroamin vianselvitys, osa 2: Yleisimmät syyt autentikaatiovirheisiin

eduroamin vianselvitys, osa 2: Yleisimmät syyt autentikaatiovirheisiin

Taustaa

Seuraava lista pohjautuu meidän (Arch Red) kokemuksillemme sekä eduroam Suomeen että Langattomaan Tampereeseen kuuluvien organisaatioiden ongelmien ratkaisussa koottuihin kokemuksiin. Jos listasta tuntuu puuttuvan syitä tai jotkin kaipaavat lisäkommentteja niin blogiartikkelin kommentteihin voi lisätä kysymyksiä tai omia näkemyksiään aiheista. Esitellyt ongelmat eivät ole missään erityisessä yleisyys- tai muussa järjestyksessä vaan niitä on kerätty sitä mukaa kun niitä on tullut mieleen. Alunperin nämä tuli kerättyä sähköpostiin, josta parhaita paloja on jo käsitelty MobileFunet-työryhmässä.

Päätelaitteiden konfigurointivirheet

Yleisellä tasolla päätelaitteiden konfigurointivirheet on ongelma numero 1. Virheet harvemmin johtuvat RADIUS-palvelinten väärinkonfiguroinnista. Juuripalvelinten tilastoinnissa epäonnistuneita autentikaatioita voi näkyä organisaatioiden osalta suurissakin määrissä, mutta niitä tulee jokatapauksessa koska yksikin virheellisesti konfiguroitu client pommittaa kyllä onnistuneesti organisaation kotipalvelinta kasvattaen virheiden tai epäonnistuneiden tunnistautumisten määrää tilastoissa.

Vanhemmat päätelaitteet ja tunnistamismenetelmäoletukset

Tälläisistä parhaana esimerkkinä toimivat Nokian vanhat puhelimet ja niissä 802.1X:n konfiguroinnin vaikeus. Symbian oletuksena tarjosi WPA/WPA2-autentikoiduille verkoille EAP-SIM/EAP-AKA -tunnistamista oletuksena. Tämä jouduttiin aktiivisesti kääntämään pois päältä sekä syöttämään sekä ulkoinen (eli vaikka anon@tut.fi) että sisäinen (karri@tut.fi) username erikseen sekä valikoimaan PEAP/EAP-TTLS asetuksista päälle. Tämä ongelma ei ole enää niin olennainen iOS-, Android- ja Windows Phone -laitteiden yleistyessä ja Symbianin vähitellen hävitessä. Myös kannettavien käyttöjärjestelmissä tämän konfigurointi on muuttunut helpommaksi, joskaan ei välttämättä turvallisemmaksi. Tämä virhe näkyy tyypillisesti 3gpp-realmien yrittämisenä organisaation proxyävällä RADIUS-palvelimena tai viimeistään juurella, jonne nuo realmit maadoitetaan.

Varmenteiden tarkistusongelmat

Kaikki WPA-asiakasohjelmat (WPA supplicant) eivät toimi samalla tavalla. Jotkut WPA-supplicantit on konfiguroitu toisia tiukemmaksi RADIUS-palvelimen varmenteen tarkastuksessa. Jos varmenteen tarkastus ei onnistu (tai tarkemmin jää kesken), eivät useimmat supplicantit luovuta vaan yrittävät aina vain uudelleen. Jotkut supplicantit eivät mahdollista varmenteen tarkistusta (ja joudutaan luottamaan MSCHAPV2 haaste-vasteeseen). Jotkut tarjoavat vain SSH:n tyyliin fingerprintin ja ilmoittavat uudelleen, jos varmenne on muuttunut (tämä ei ole varsinaisesti huono tapa). Jotkut taas vaativat, että supplicantille on määritelty palvelimen varmentavan CA:n varmenneketju, ja että RADIUS-palvelin palauttaa sen varmenteiden yhteydessä. Virheet RADIUS-palvelimen konfiguroinnissa tai käyttäjän tekemässä supplicantin konfiguroinnissa sitten aiheuttavat jälleen kerran epäonnistuneita autentikointiyrityksiä ja yleensä paljon ja nopeallakin vauhdilla.

Salasanan vaihtovaatimukset organisaatioissa

Tietyn kuukausimäärän sisään vaihtuvan salasanan käytäntö aiheuttaa sen, että käyttäjien päätelaitteisiin jää vanhoja salasanoja, jotka eivät kelpaa, mutta joita päätelaite sitten yrittää uudelleen ja uudelleen.

Kirjoitusvirheet konfiguraatiossa

Kirjoitusvirheet konfiguraatiossa esim. tuon aiemmin mainitun  ulomman kuoren ja sisemmän kuoren tunnusten määrittelyssä aiheuttavat päätelaitteita, jotka jatkuvasti yrittävät hakata päätään organisaation tunnistuspalvelimelle tai verkkovierailupalvelun seinään.

Organisaatioiden virheelliset konfiguraatio-ohjeet: Ei realmia ohjeistuksessa

Tätä Suomessa on käsittääkseni vähemmän tavattu, mutta kaikki ne organisaatiot, jotka hyväksyvät organisaationsa sisällä tunnistautumiset, joissa ei konfiguroida realmia sekä ulko- että sisä-EAP:piin, saisivat muuttaa ohjeistustaan ja konfiguraatiotaan niin, että ilman tuota realmia, autentikaatio ei onnistu organisaation sisälläkään. Tämän perustelu on se, että käyttäjä pystyy tekemään organisaation sisällä näennäisesti toimivan, mutta roamauskelvottoman konfiguraation, joka ei sitten tietenkään toimi vierailtaessa jossain muualla.

Organisaatioiden virheelliset konfiguraatio-ohjeet: RADIUS-palvelimen varmenteen tarkistuksesta lintsaaminen

Tätä harrastetaan jonkin verran Suomessakin, sillä vastaan on tullut useampiakin ammattikorkeakoulujen ja yliopistojen ohjeita, joissa ohjeistetaan kääntämään esim. Windowsissa RADIUS-palvelimen varmenteen tai nimen tarkistus pois päältä. Kun RADIUS-palvelimen varmenteen tarkistuksen ohjeistamisesta on tällä tavoin lintsattu, aiheutetaan ongelmia niille käyttäjille, joiden supplicant vaatii sitä, että se konfiguroidaan tarkemmin tuon palvelinvarmenteen varmentamista varten. Tyypillinen tälläiseen johtava virhe konfiguraatio-ohjeissa on se, että ohjeistetaan, että RADIUS-palvelinvarmenteen varmentaminen pitää kytkeä pois päältä. Tälläinen lintsaaminen olisi syytä kitkeä pois ja ohjeistaa sekä CA-varmenteiden asennus, että tuo fingerprintin tarkistus, joka esim. Mac OS X:ssä ja Windows 8:ssa on käytössä.

Päätelaitteiden bugit käyttöliittymässä ja varmenteiden hallinnassa

Mm. Nokian N900- ja Nokian N9- sekä joillain Android-laitteilla, laitteistovalmistaja on tehnyt itse supplicantin hallinnan, siihen varmenteiden konfiguroinnin ja yleisen käyttöjärjestelmän varmenteiden hallinnan. Mainituilla Nokian laitteilla mm. eräs ongelma oli, että RADIUS-palvelimeen varmenteen varmistusta varten ei pystynyt käyttöliittymästä konfiguroimaan olemassa olevia juurivarmenteita kelvolliseksi varmentamaan RADIUS-palvelimen varmennetta. Ongelmaa pystyi jossain määrin kiertämään asentamalla päävarmentajan varmenteen uudelleen tai käyttämällä privaattipäävarmentajaa.

Androidissa puolestaan jotkut laitteistovalmistajat eivät tarjoa mahdollisuutta ollenkaan varmistaa RADIUS-palvelimen varmennetta. Jos varmenteen tarkistus on mahdollista, päävarmentajan varmenteet on asennettava erikseen ja mitä vanhempi Android-versio, sen hankalampi käyttäjälle. Tilanne on hieman parantanut Android 4.0+:ssa, mutta turvallisen konfiguraation tekeminen sielläkin vaatii hyvää ohjeistusta tai automatisointia. Kuten muissakin tilanteissa, virheet näissäkin sitten kostautuvat lisääntyneinä virhemäärinä tilastoissa.

Puolinaisen konfiguraation teko päätelaitteisiin

Tämä ongelma perustuu tilanteeseen, jossa käyttäjä aloittaa konfiguraation teon, mutta tekee konfiguroidessa jonkun virheen ja viallinen/puolitoimiva konfiguraatio jää mobiililaitteeseen. Käyttäjän tietämättä mobiililaite kuitenkin yrittää tuolla viallisella konfiguraatiolla verkkoon aiheuttaen kuormaa ja virheitä tilastoihin. Esim. vaikka tilanne, että ulkoinen realm on kunnossa, mutta sisäinen käyttäjätunnus, salasana tai niihin liittyvät asetukset on pielessä. Jälleen saadaan virheitä tilastoihin ilman, että käyttäjä edes huomaa laitteensa yrittävän hakata itseään sisälle eduroam-verkkoon.

Vaihtelevat eduroam-verkon konfiguraatiot

Tämä tarkoittaa organisaatioissa olevia erilaisia eduroam-verkon konfiguraatioita ja niitä aiheutuvia ongelmia. Esimerkiksi se, että eduroam-verkko tarjoaa sekä WPA2 että WPA1 -kykyisen tunnistaumisen, voi aiheuttaa sen, että osa päätelaitteista konfiguroituukin käyttämään ja olettamaan, että eduroam tarjoaa aina molemmat autentikaatiotavat tai vähintään WPA1:n. Erityisesti Windows voi kunnostautua siinä, että sille ei kelpaa saman nimisestä verkosta sekä WPA- että WPA2-profiilit, vaan käyttäjän on valittava joko tai. Olisikin yleisen toiminnallisuuden kannalta suotavaa, että eduroam lukittaisiin jo WPA2 only -profiiliin kaikkialla Suomessa ja WPA1 sekä siihen liittyvät kryptot poistettaisiin konfiguraatioprofiileista kaikkialla.

Loppukommentit

Ehdottomasti suurin osa eduroamin ongelmista liittyy nykyään siihen, miten organisaatioiden pitäisi ohjeistaa ja hoitaa käyttäjien päätelaitteiden konfigurointi tai sen oikeellisuus. Terena Mobility -työryhmässä tätä on pyritty ratkomaan ja siellä on kokeiltu apuohjelmia mobiilipuhelimiin (tämä voi mielestäni auttaa) sekä erillisiä supplicanteja kannettaviin (tämä taas on mielestäni huonompi idea). Konfiguraatiota avustava ohjelma/webbipalvelu on mielestäni hyvä idea siksi, että sillä tavalla voidaan puskea varmemmin toimiva konfiguraatio päätelaitteisiin. Oma supplicant on puolestaan huono idea sen takia, että erilaisia laitteita on paljon ja tuollaisen asentaminen voi sotkea niiden toimintaa muuten. Omaa supplicantia parempi lähestyminen on, että pysytään niistä standardi WPA2-autentikointitavoissa, joita päätelaitteiden käyttöjärjestelmien omat supplicantit tukevat natiivisti ja keskitytään niiden konfiguraation ohjeistamiseen ja automatisointiin.

eduroamin vianselvitys, osa 1: Juuripalvelun rooli

eduroamin vianselvitys, osa 1: Juuripalvelun rooli

Idea näihin blogipostauksiin lähti CSC:n meiltä tekemästä kyselystä siitä, että olisiko meillä (Arch Redillä) Suomen eduroamin juuripalvelun ylläpitäjinä tietoja siitä, mitkä ovat 10 yleisintä autentikaatiovirhettä eduroam-verkoissa. Tälläisiä virheitä tulikin sitten mietittyä, mutta niitä analysoidessa kävi selväksi se, että mitkään niistä eivät varsinaisesti liittyneet tai olleet selvitettävissä tai ratkaistavissa juuripalvelun kautta. Päinvastoin suurin osa niistä oli selvitettävissä ainoastaan organisaatioiden omien tunnistuspalveluiden ja käytäntöjen kautta.

Ymmärtääkseen kuitenkin kokonaiskuvan on tärkeä hahmottaa ensin se, mikä on juuripalvelun rooli ja kyvyt eduroam-verkkovierailussa. Yksi eduroamin parhaista ominaisuuksista nimittäin on myös sen heikkous ajatellen yleistä vianselvitystä. Eduroamin autentikaatioliikennettä ei nimittäin pystytä välityspisteissä purkamaan vaan autentikointi tehdään salatun putken suojassa käyttäjät kotiorganisaatioon. Näin ollen myös lähes kaikki ongelmiin ja epäonnistumisiin liittyvä tieto on kerättävissä pelkästään organisaatioiden (IdP) RADIUS-palvelimen lokeista ja tiedoista.

Juuripalvelimelta ei siis pystytä selvittämään sitä, miksi joku autentikointi epäonnistuu ellei sitä pystytä päättelemään ulomman kuoren reititysongelmaksi (väärä realm) tai organisaation RADIUS-palvelimen vastaamattomuudeksi. Sisällä liikkuvaan tietoon ei välityspisteissä päästä käsiksi. Edes kaikki epäonnistumisetkaan eivät juuripalvelussa näy vaan jos esim. varmenneongelman takia TLS-tunnelin muodostus keskeytyy, tätä ei nähdä epäonnistuneena tai onnistuneena autentikaationa juuripalvelimella ollenkaan. Vain selvät IdP:n päätökseen johtaneet verkkovierailut näkyvät lokeissa onnistuneina tai epäonnistuneina autentikaatiopyyntöinä, eikä näistä useinkaan nähdä varsinaista syytä onnistumiseen tai epäonnistumiseen vaan nämä tiedot on organisaation tarkistettava omilta autentikaatiopalvelimiensa lokeista.

Tästä syystä tunnistamisongelmien syyt sekä niihin liittyvä vianselvitys tai yleisempien vikojen tilastointi pitää tehdä organisaatioiden RADIUS-palvelimilta. Juuripalvelimilta tuota tietoa ei pystytä keräämään.

Arch Redissä me olemme kuitenkin avustaneet monia yliopistoja liittymään eduroamiin. Joillekin olemme toimittaneet avaimet käteen integrointeja ja auttaneet tukisopimusten puitteissa selvittämään RADIUS-palvelimeen liittyviä autentikaatiovirheitä. Tälläiset autentikaatiovirheet ovat olleet juuri niitä, joita juuripalvelusta ei pääse näkemään vaan jotka kokemuksen kautta tulevat vastaan useimmin organisaatioiden omissa verkoissa. Seuraavassa osassa käydäänkin läpi yleisimmät eduroam-organisaatioissa autentikaatiovirheitä aiheuttavat tekijät.

eduroam ennen, nyt ja tulevaisuudessa esitys

Pidin viime perjantaina 16.9.2011 esityksen CSC40v -juhlaseminaarista eduroamista ennen, nyt ja tulevaisuudessa. Esityksen kalvot löytyvät jälleen Slidesharesta:

eduroam ennen, nyt ja tulevaisuudessa

View more presentations from Karri Huhtanen

eduroamin historiaa TTY:n Rajapinta-verkkolehdessä

Tampereen teknillisen yliopiston Rajapinta-verkkolehden artikkeli "Vierasverkkoon nopeasti ja helposti" kertaa Funetin WLAN-verkkovierailun ja eduroamin taustaa ja kehitystä Suomessa.

Arch Red Oy on vuodesta 2004 huolehtinut Funetin WLAN-verkkovierailun ja eduroamin Suomen osuuden toteuttavien juuripalvelinten käytännön toteutuksesta ja ylläpidosta CSC:n huolehtiessa verkkovierailufederaatioiden koordinoinnista.

Arch Red Guest Server 3.0 - uusi versio vierailijapalvelimesta

Arch Red Guest Server 3.0 eli vierailijapalvelimen versio 3.0 on julkaistu. Tärkeimät muutokset ja uudet ominaisuudet ovat:

• Uusittu ja parannettu käyttöliittymä
  
• Helpompi ja joustavampi mukautus
  
• Active Directory- ja LDAP-tuki
• Aikavyöhykeet: vierastunnusten ajat ovat aina paikallista aikaa
  
• Laajempi tuki kansainvälisille merkistöille
• Vierastunnusten hallinta web-pohjaisella rajapinnalla
  
• Täydellinen IPv6-tuki

Versiossa 3.0 keskityttiin parantamaan käyttöliittymää, mukautettavuutta oman organisaation tarpeisiin ja tukea etenkin suurille organisaatioille.

Käyttöliittymän ulkoasua kohennettiin, näkymiä yhdenmukaistettiin ja esimerkiksi vierastunnusten ja niiden salasanojen kirjasimet on valittu selkeiksi ja yksikäsitteisiksi tulostusta ja käyttöä varten. Muutokset käyttöliittymään tehtiin testausammattilaisen palautteen perusteella.

Mukautettavuus tarjoaa paremman mahdollisuuden omien tulostuspohjien, ohjeiden tai esimerkiksi SMS-lähetysten käyttöön. Mukautus voi olla yksinkertaisimmillaan tulostuspohjan logon vaihto ja esimerkiksi oman tarrapohjan teko on täysin mahdollista.

Etenkin suurille ja myös pienille organisaatioille versio 3.0 tarjoaa mahdollisuuden käyttää LDAP- ja AD-käyttäjätietokantoja vierastunnusten luojien eli käyttäjien tunnistamiseen ja valtuuttamiseen. Mikäli toimipisteitä on eri aikavyöhykkeillä, tunnukset voidaan aina luoda paikallisen ajan mukaan. Aikavyöhykkeiden lisäksi paikallisia käyttäjiä varten voidaan tulostuspohjat tehdä esimerkiksi kyrillisillä kirjaimilla.

Vierastunnusten luonti web-pohjaisella rajapinnalla on uusi tapa luoda vierastunnuksia. Vierastunnuksia voidaan nyt luoda sekä web-käyttöliittymällä että suoraan toisista sovelluksista. Uusi rajapinta antaa mahdollisuuden liittää vierailijapalvelin ja vieraiden tunnistaminen esimerkiksi intranet-sovellukseen, jolla jo nyt hoidetaan vieraiden vastaanotto. Liitoksella saadaan nopeasti lisättyä vierashallinnan intranet-sovellukseen WLAN-tunnusten luonti. Rajapinta eli Arch Red Guest Server Extension API sopii mihin tahansa automatisoituun tunnusten luontiin.

Vieralijapalvelimen tuki IPv6:lle on tarkistettu, ja esimerkiksi demopalvelinta voi käyttää yhtälailla sekä IPv4:n että IPv6:n kautta.

Uusin version löytyy demopalvelimelta. Kommentit ja muut yhteydenotot ovat aina tervetulleita!

Konferenssiverkot, osa 1: MindTrek 2010 WLAN-verkon tilastoja ja kokemuksia

Nyt MindTrek 2010 -konferenssin loputtua voi vihdoin todeta, että tällä kertaa konferenssin verkko oli sellainen, jonka konferenssin verkon meidän mielestämme pitää olla. Iso merkitys oli sillä, että verkon suhteen oltiin hyvissä ajoin liikkeellä, lainattiin hyvät yritystason WLAN-laitteet Ciscolta sekä sovittiin Tampereen Puhelimen kanssa riittävän kaistan toimittamisesta. Arch Redin rooli verkonrakentamisessa oli huolehtia laitteiden saamisesta lainaan Ciscolta, verkonsuunnittelusta sekä laitteiden konfiguroinnista ja asentamisesta. Hyviä vihjeitä laitteiden konfiguraatioon saimme Ciscolta Tomi Järventieltä ja lisäksi koko konferenssin verkon rakentamisessa oli sellainen hieno säätäjädraivi mm. Ilkka Lehtisen ja Heikki Ilvespakan "johto"töiden muodossa.

Kun kerran palautekin konferenssin verkosta oli poikkeuksetta positiivista, päätimme kerätä kasaan tilastot ja kokemukset verkon käytöstä, konfiguraatioasetuksista ja parhaista käytännöistä eli käytännössä siitä, miten konferenssi- ja muita korkean käyttöasteen verkkoja meidän mielestämme kannattaa tehdä. Yhdessä blogipostauksessa ei kaikkia asioita kannata käydä läpi, joten julkaisemme konferenssiverkkojen rakentamisesta juttusarjan täällä Arch Redin blogissa aloittaen MindTrek 2010 WLAN-verkon käyttötilastoista.

MindTrek 2010 -konferenssia varten saimme tänä vuonna ensimmäistä kertaa kuituyhteyden ja ethernettiä edellisten vuosien SHDSL-yhteyksien sijaan. Mittausten mukaan yhteys oli n. 100Mbps Internetistä MindTrek-verkkoon päin ja 10Mbps MindTrek-verkosta Internettiin. Konferenssin aikana ei kuitenkaan päästy edes testaamaan yhteyden rajoja liikennöinnin pysyessä lähinnä 10Mbps tasolla. Tosin 10Mbps nimellisnopeudella varustetulla linkillä verkko olisikin ollut jo oikeasti jumissa, kuten MRTG:llä piirretystä kuvaajasta alhaalla näkee.

Liikennettä mitattiin 5 minuutin välein, joka tarkoittaa, että esim. graafissa oleva huippuarvo tarkoittaa, että ko. hetkenä liikennettä on siirretty 5 minuutin keskiarvonakin jo 10Mbps:n yhteyden teoreettisen maksimin verran jatkuvasti. Liikennekäyrän leikkautumiseen (suora viiva) muutamassa kohdassa ei ole varmistettua selitystä. Eräs selitys voisi olla koneen kellon edistäminen/jäljestäminen ja sen siirtäminen takaisin aikaansa. Muita selityksiä taas esim. se, että jotkut palvelut tai palveluntarjoajat, kuten YouTube saattavat rajoittaa tiettyyn IP-osoitteeseen tilatun liikenteen määrää ja koska kaikki MindTrek-verkon koneet olivat yhden IP:n takana, annettiin liikennettä YouTuvesta putkeen vain tietyn rajoituksen mukaan.

Käyttäjien määrää verkossa tilastoitiin varsinaisen konferenssin alusta loppuun. Alla olevasta kuvasta voidaan nähdä, että vaikka suurin osa käyttäjistä käytti avointa ja salaamatonta WLAN-verkkoa, myös salattuihin ja käyttäjätunnistettuihin verkkoihin riitti sekä Langattoman Tampereen että eduroamin verkkovierailijoita. Käyttäjämäärän huippu mittauskaudella oli 165 yhtäaikaista käyttäjää.

Keskellä oleva laakso tarkoittaa yöaikaa, jolloin silloinkin verkkoon oli liittyneinä muutamia päätelaitteita. Kuopat päivien keskellä taas sijoittuvat konferenssin lounasaikoihin.

Ciscon suosituksesta kokeilimme myös konfiguroida tukiasemat tarjoamaan kahta WLAN-taajuusaluetta (2.4GHz ja 5GHz) tukeville päätelaitteille ensisijaisesti 5GHz aluetta. Yllätykseksemme näitä olikin päätelaitteista selvä enemmistö 2.4GHz:n päätelaitteiden jäädessä huomattavasti pienempään osaan, kuten kuvasta voi nähdä.

Kuvassa dot11a ja dot11n5 tarkoittavat WLANin 5GHz:in alueella toimivia IEEE 802.11a ja IEEE 802.11n päätelaitteita. 2.4GHz:n alueelta löytyi sitten 802.11g ja myös 802.11n standardi mukaisia päätelaitteita tunnisteilla dot11g ja dot11n24. Pelkkä IEEE 802.11g standardi näytti olevan selkeässä vähemmistössä käyttäjien päätelaitteissa. Useampaa taajuusaluetta käyttävät päätelaitteet kun valitsivat tukiasemien ohjeistamina mieluummin jonkun 5GHz:n taajuusalueen standardeista.

WLAN-verkoissa käytettävä taajuusalue vaikuttaa huomattavasti verkon toimivuuteen. 5GHz:n verkoissa on pienempi kantama, mutta enemmän toisiaan häiritsemättömiä kanavia (8 kpl) tukiasemille. Yleisemmällä 2.4GHz alueella puolestaan sitten on vain 3 täysin toisiaan häiritsemätöntä kanavaa (1, 5/6 ja 11) ja kyseinen taajuusalue onkin usein hyvin ruuhkainen jo pelkästään eri WLAN-verkkojen ansiosta. Usein myös konferensseissa on myös langattomia mikkejä yms. häiriölähteitä samoilla taajuusalueilla, joten 5GHz:n suosiminen ja tiheä tukiasemaverkko näyttää oikealta ratkaisulta varmistaa, että radioverkkokapasiteettia riittää kaikille käyttäjille.

Tämän pohjalta voimmekin antaa suosituksen, että päätelaitteissa ja tukiasemissa kannattaa suosia laitteita, jotka tukevat molempia radiotaajuusalueita ja tukiasemissa vieläpä yhtäaikaista taajuusalueiden käyttöä. Uusi 802.11n standardi tuo myös enemmän nopeutta ja kantavuutta verkkoon, mutta sitäkin ostaessa kannattaa huomata, että standardilla markkinoidaan myös laitteita, jotka osaavat toimia vain 2.4GHz:n alueella molempien alueiden (dual band, simultaneous dual band 802.11n) sijaan.

PÄIVITYS 2010-10-26: Ciscon Tomi Järventieltä tuli muutama lisäkommentti liittyen noihin jo esitettyihin suosituksiin. Kommentit ovat tässä alla:

Suositusten osalta haluaisin tuoda vielä esiin pari huomionarvoista asiaa:

1. Tukeeko WLAN-ratkaisu 802.11n-speksiä molemmilla taajuusalueilla, vai ainoastaan 5 GHz alueella. On useampia valmistajia, jotka myyvät 802.11n-ratkaisuja, mutta tukevat sitä vain 5 GHz alueella. 2,4 GHz alueella tuetaan vain b/g-speksejä, jolloin n-tukareihin investointi ei tuo kaikkea tarjolla olevaa hyötyä.

2. Kuinka suurta kanavajoukkoa ratkaisu tukee 5 GHz alueella. Osassa 5 GHz taajuusaluetta on _pakollista_ toteuttaa ns. DFS-ominaisuus (tutkanväistely), ja jotkut valmistajat oikovat jopa yritystason ratkaisuissa sen osalta aika tavalla. Oikominen johtaa siihen, että likimainkaan kaikkia olemassa olevia kanavia ei voida käyttää, ja pahimmillaan yli puolet mahdollisesta kapasiteetista joudutaan "heittämään hukkaan".