oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: wireless

hw per montar un firewall, router, ap, etc.

Reading time: 2 – 3 minutes

Gràcies al meu nou proveedor de hardware enquestat, mds 2000, m’he posat al dia del catàleg de productes d’AAEON una marca de material embedded molt interessant. El millor del tema és saber que pots comprar-ho a Barcelona mateix i a preu de PVD (Preu de venta distribuidor).

Doncs bé concretament hi ha un model que m’ha agradat molt per montar firewalls en linux (ve amb el Montavista Linux de serie) a casa dels clients, a més gràcies als dos slots mini-PCI tipus III que porta la placa puc posar-hi una o dues targetes wifi. Però el que potser m’ha agrada més són els 6 ports ethernet de que disposa el SBC.

Amb una RAM de 32 o 64Mb segons el model, un processador RISC d’Intel (XScale IXP420/422/425) amb 266 o 533MHz i amb 16Mb de flash. Per si tot això us sembla poc encara n’hi ha més 2 ports serie, 2 ports USB (1 USB 2.0 i 1 USB 1.1) i com no quatre sortides DIO, per controlar altres perifèrics amb protocols I2C, SPI o SMBus.

gene-1425.jpg

Al tractar-se d’un dispositiu embedded les seves mides són minúscules 156mm x 101.6mm i s’alimenta amb corrent continua amb un voltatge que pot anar dels 9 als 24v. O sigui, que tenim on triar. Ara només cal trobar-li una caixa que li vagi com un gua. Amb els ~275$ de cost, més els aproximadament ~10$ de la caixa i uns altres ~15$ de la font d’alimentació podem tenir un firewall, router o el que volguem per un preu molt raonable.

Si voleu aprofundir més sobre el producte:

SAX 2006 (Salut Amor i Xarxa)

Reading time: 4 – 6 minutes

La setmana passada vaig agafar la furgo i en Lluis i camí cap a Manresa. On varem assistir a la SAX 2006, ara no recordo si és la segona o tercera edició. Aquesta cita anual és on ens reunim les comunitats lliures de comunicacions sense fils. Durant el matí hi varen haver algunes xerrades tècniques tot i que molt interessants diria que poc preparades, suposo que tots anem de cul. Tot i amb això el nivell tècnic en alguns temes era més que interessant. A veure si l’any que ve ara que ja sé de que va el tema em preparo alguna coseta i així hi aporto el meu granet d’arena.

Després del dinar, que va ser molt suau, tot s’ha de dir. Varem fer una taula rodona molt i molt interessant. On es varen parlar sobretot de temes referents a la inter-relació de totes aquestes comunitats entre elles. Per tal de sumar esforços, tan a nivell tècnic, com de documentació i organització. Jo diria que va ser la part que més s’hauria de descatar en aquestes jornades. Per tal de poder unificar encara més els esforços que com sempre acaben sent massa dispersos. Així doncs la meva proposta en aquest punt seria la de fer unes SAX dels cores de cada xarxa sense fils per tal de parlar de temes específics de col·laboracions entre nosaltres.

En aquest punt de la col·laboració entre xarxes sense fils es va acordar de publicar una especie de Planet RSS de les comunitats(*). Això consisteix en la idea de que cada web, weblog, portal o el que sigui de cada comunitat hauria de disposar de tres categories obligatories de contingut que es publicarien a través d’RSS. Això permetrà que es sindiqui des d’una web central, segurament www.guifi.net aquests continguts des de cada comunitat i que s’autopubliquin. El que es preten aconseguir amb aquesta iniciativa és:

  • No dubplicar esforços en la documentació generada per cada comunitat
  • No explicar de forma redundants noticies que afecten al món del wifi
  • Posar en comú els avenços de la nostre comunitat que poden interessar a la resta de comunitats
  • Tenir un únic punt de consulta d’informacions tècniques, consulta de propostes semblants o iguals
  • Enriquir amb més comentaris els articles que es publiquen, això enriqueix substancialment el contingut del propi autor, ja que en matitza aspectes que l’autor no ha pensat o no ha descrit prou bé
  • Es pot treballar de forma coordinada sense fer un sobre-esforç ja que fent el que fariem de forma normal ho posem en coneixement del resta de comunitats

Com que s’ha de predicar en l’exemple, podreu veure que en el meu bloc he creat una categoria que es diu Wireless dintre hi ha 3 subcategories, que són just les categories que varem acordar que cada comunitat ha de publicar via RSS:

  • eBosc: noticies de la propia comunitat (p.e. novetats eBosc)
  • wireless-docs: documents tècnics i/o informatius sobre wifi (p.e. com configurar un dongle usb wifi en linux)
  • wireless-news: novetats del món wifi: tècniques, productes, normatives, estàndars, etc.

Sota el meu punt de vista el nom de les 3 categories no és gaire important, sempre i quan sigui rellevant respecte el que contenen. A més s’ha de deixar ben clar aquests tres tipus de continguts perquè després es puguin recuperar des del lloc web central. En principi, el drupal que corre a www.guifi.net, el que no recordo és quin tipus d’RSS s’ha de publicar perquè el drupal el pugui importar automàticament a la categoria que toca. A l’espera de parlar aquest tema amb els administradors de guifi.net deixo pendent generar els meus 3 RSS.

Sobre el tema dels RSS als que no estigueu acostumants a treballar amb aquest tipus d’XML’s no us preocupeu ja que ús puc donar suport per tal de que us sigui més senzill fer-ho. A més la majoria d’aplicacions que s’usen avui en dia com a CMS ja suporten aquesta opció de serie. Així que només s’haurà de configurar convenienment el vostre aplicatiu web perquè publiqui els RSS.

Pels que durant la lectura d’aquest article us hagin sonat a japonés algunes de les sigles que he usat, us recomano que llegiu aquest article: ¿Què és RSS, sindicar, weblog, bitacora, etc?.

* Planet is a flexible feed aggregator. It downloads news feeds published by web sites and aggregates their content together into a single combined feed, latest news first.

Configurant OvisLink Evo-W54USB (rt2570) – WiFi USB dongle

Reading time: 3 – 4 minutes

ovislink-wifi-usb.jpg

No sé si heu intentat alguna vegada comprar un dongle USB amb Wifi i que funcioni amb Linux. Doncs realment no és cosa fàcil, quasi sense voler aquesta setmana n’he comprat dos es tracta concretament un dongle força petito compatible amb IEEE 802.11g, suport WPA, etc. Doncs bé, hi ha una web on s’esta desenvolupament el driver per les targetes wifi que disposen d’aquest chipset tan les USB com les PCI i les PCMCIA. En el nostre cas la que interessa és la USB, malgrat el chipset en si s’anomena rt2500 concretament el model USB usa el chipset 2570. A més potser el millor és el seu cost a preu de PVD m’ha costat 24€ (kinyo) però si mireu per les webs fraceses podreu veure que el preu de frança de PVP val 18€. És el bonic del nostre país.

Un cop aclarit això quan entreu a la web del projecte: rt2x00 Open Source Project ja sabeu quins drivers heu de descarregar. Potser heu sentit a parlar de que s’esta treballant en unificar tots els drivers de targetes wifi sobre uns mòduls base que implementin de la mateixa forma una serie d’interficies d’accés als dispositius. Amb això es preten que sigui més senzill desenvolupar software wifi que funcioni en totes les targetes de xarxa inal·lambriques per wifi. Cosa que ara mateix es complicat, degut a que cada desenvolupador ha tirat pel seu cantó. Així doncs, el que intento explicar és que s’esta treballant en que aquest driver també funcioni sobre aquesta base comuna. Malgrat això no he aconseguit fer-lo funcionar, compilava i es carregava correctament però després la targeta no acabava de funciona no detectava cap xarxa ni tan sols s’encenia l’únic LED que porta.

Així doncs, us recomano que descarregueu el paquet “Latest BETA rt2570 driver: v1.1.0-b1” de la secció de download de la web del driver opensource. Això m’ha funcionat perfecte amb un kernel 2.6.13.2 però no m’ha funcionat amb un kernel 2.6.14.2, per aquest he hagut de baixar el paquet “rt2x00 nightly CVS tarball: rt2x00-CVS”, concretament la nightly version del dia d’avui (3 de Febrer del 2006). Aquesta versió m’ha compilat sense problemes amb un kernel 2.6.14.2. Els passos per la instal·lació del driver ben senzills:

# tar xvfz rt2570-1.1.0-b1.tar.gz
# cd rt2570-1.1.0-b1/Module
# make
# make install

Això ens instal·la el següent mòdul rt2570.ko aquest al fer l’install es posa a /lib/modules/2.6.14.2/extra/rt2570.ko. Després com sempre fem un depmod -a i ja podem carregar el mòdul modprobe rt2570, un cop carregat el mòdul llavors el kernel ens torna el següent missatge (dmesg):

RT25usb  Driver version 1.0.0

Després d’això ja podem usar les típiques eines per configurar el nostre enllaç wifi amb linux: iwconfig, iwpriv, etc. un petit consell és que primer configureu la IP del dispositiu amb l’ifconfig i després els paràmetres wifi, ara s’hauria de fer pampallugues el LED del dongle. Sinó fa pampallugues no funciona, almenys a mi no m’ha funcionat cap cop, encara que si que és capaç de detectar-me xarxes però res no enllaça amb res. Encanvi quan fa pampallugues llavors ja teniu possibilitats de que funcioni 🙂

Que hi hagi sort amb el tema…

Linksys: WAP54GPE i WRTSL54GS

Reading time: 3 – 4 minutes

Ja fa dies que costa trobar el mític WRT54G, sinó que els hi preguntin a la gent de guifi. Així que toca pensar en els nous models de linksys que hi han i que venen. Curiosament després de llegir una discusió sobre aquest tema a la llista de correu de la colla d’osona avui m’estava posant al dia del meu bloglines, quan he vist que a linksysinfo ens parlen dels dos models que estan al caure WAP54GPE i WRTSL54GS (review de Tom’s networkinglocal).

El WAP54GPE crec que és un bon substitut del WRT54G per enllaços en exteriors. Almenys si mirem la foto sembla força robust no sé si aguantarà gaire la duresa d’estar a l’exterior però això no se sap si no es prova. Suposo que mica en mica els firmwars com els d’sveasoft i tota la colla aniran treien versions impresionants per aquest dispositiu i podrem disposar d’aquests entorns que ja ens semblen tan i tan habituals en els nostres linksys però que de fet, no són els firmwares originals.

WAP54GPE.png

Per interiors i amb funcions que sumen la potència del WRT54G amb les del NSLU2 podem trobar el WRTSL54GS.

wrtsl54gs.png

El que no sabia jo és que hi havia un estàndard que es diu UPnP Media que ens permet connectar infinitat de hardware i software a storage de la xarxa sigui quin sigui el format del sistema de fitxers del dispositiu (HD,flash, CD, etc) que l’enmagatzema. Si tampoc ho coneixieu us recomano que li doneu un cop d’ull al hardware i software (també per linux) que implementen aquest interessant sistema. Fins hi tot he vist un plug-in pel famós gallery que ens permet veure el nostre album de fotografies a través de UPnP Media.

wrtsl54gs_front_panel.png
vista frontal
wrtsl54gs_rear_panel_sm.png
vista posterior

Malgrat només té un connector USB per un disc dur, o una memòria flash, no sé si arribaria a funcionar també un CD o DVD, jo diria que si. Doncs malgrat això trobo que és un dispositiu que esta molt bé. Ja que ens permet tenir connectat el nostre disc dur portàtil sempre apunt per anar on sigui i a més el podem tenir al lloc de casa que més ens agradi.

Un altre cop Linksys m’ha tornat a sorprendre de forma agradable, tot i que he de dir que la nostalgia pel WRT54G trigarà temps a desapareixer. Realment és un dispositiu al que tots li hem agafat carinyu,oi?

Primer enllaç wifi a base de Nesquik a Torrelavit

Reading time: 1 – 2 minutes

Tal com s’explicava a comesfa, el nostre mestre de les manualitats en Toni amb la incalculable ajuda del Jordi tal com explica el Toni al seu propi blog s’han currat una anteneta a base de Nesquik. Així que ja hem substituït un dels colls de d’ampolla que teniem a la xarxa per un enllaç tipus g que de moment rendeix a 36Mbps.

UPDATE 14/09/2005: ja teniu més fotos del procés de l’antena Nesquik penjades per si us pot ser útil i/o curiós veure-les.

Truquillo: Linksys WRT54G configuració via tftp

Reading time: 6 – 9 minutes

linksys.gif

Aquest agost vaig ‘postejar’ el nou mapa de la xarxa de Torrelavit. Doncs bé com haureu vist en el gràfic els APs tenen en molts casos múltiples interficies virtuals i rutes estàtiques. Ja que degut a la naturalesa de la nostre petita i modesta xarxa ciutadana no ens encaixa gaire el tema de l’enrutament dinàmic per OSPF i coses d’aquestes tan xules. Així doncs, vam trobar-nos en el dilema de com posar més d’una IP per cada interficie, cosa que la interficie web del router no permet. A més per afegir rutes estàtiques sense usar un adreçament dinàmic com RIP2 o OSPF la interficie gràfica tampoc ens ho permet.

Per tal de solucionar aquests problemes i de centralitzar el sistema de configuració dels APs en un punt. El que hem fet és montar un servidor TFTP al firewall. Amb accés només de les IPs dels APs. Un bon manual per configurar el atftp en gentoo: Gentoo Linux based Netboot HOWTO (cache)mireu-vos només la secció: The tftpd Daemon.

Una de les coses interessants que hem fet és usar només un fitxer de configuració per tots els APs de forma que aquest script sigui prou espavilat per poder configurar les particularitats diferents de cada AP. Després us explico com ho hem fet. Abans d’entrar en materia també us comento que tot el que explico només ho hem provat amb Alchemy. Imagino que amb altres firmwares també es deu poder fer però no ho hem provat.

La primera dificultat és com dir-li al Linksys que després d’arrencar s’ha de connectar al servidor TFTP s’ha de baixar el fitxer de configuració i l’ha d’executar després de baixar-lo. A més el que no voliem és que pas del TFTP pogués fallar i l’AP quedes desconfigurat a l’espera de que el tornessim a resetejar. O sigui, que el TFT s’ha de repetir fins que aconsegueixi connectar-se i agafar el fitxer. Tampoc cal una solució perfecte però si amb un mínim de control d’errors.

Com sabreu, si accedim per telnet al Linksys podem fer un nvram show per veure les variables que es guarden a la NVRAM (non-volatile RAM) on realment es guarda la configuració de l’AP. Doncs bé la variable que concretament ens interessa és la rc_startup podem consultar el seu valor: nvram get rc_startup. Doncs bé el que nosaltres volem és col·locar el següent codi dins la variable:

while sleep 30s;
do
 if ping -c 1 172.25.0.2>/dev/null;
 then
  tftp -g -l /tmp/s.sh -r s.sh 172.25.0.2;
  sh /tmp/s.sh;
  break;
 fi;
done

Com podeu veure el codi el que fa és que cada 30s intenta descarregar per TFTP el fitxer s.sh i el guarda a /tmp després l’executa. Això es repeteix fins que es pugui completar el cicle amb èxit. Ara només queda fixar aquest codi dins de la variable rc_startup i després guardar el codi a la NVRAM.

Ho podem fer així:

nvram set rc_startup="while sleep 30s;do if ping -c 1 172.25.0.2>/dev/null;then tftp -g -l /tmp/s.sh -r s.sh 172.25.0.2;sh /tmp/s.sh;break;fi;done"
nvram commit

Ara ja ens podem centrar en l’script en qüestió. Per complicar la cosa, aquí només explicaré com creem els alias de les interficies i les rutes estàtiques no posaré cap opció de firewalling ni de filtratge de MACs. Com he comentat la gràcia de l’script és que és el mateix per tots els APs de la xarxa, així que en algún lloc s’han de guardar els paràmetres pròpis de cada AP. Doncs bé per fer això hem fet un petit ‘trick’. Es tracta d’usar la interficie de definició de rutes estàtiques que té la interficie web per entrar totes les direccions que ens interessen.

Aquesta interficie gràfica l’usen els protocols dinàmics RIP2 i OSPF per definir rutes estàtiques. Si marquem la opció d’enrutament dinàmic com a ‘disable’ llavors podem afegir rutes a la configuració del sistema qu no s’executaràn degut al que acabo de dir, però si que estan guardades en la configuració. Això és el que aprofiarem per després recollir la informació i segons la lògica següent les usarem en el nostre script:

La lògica és molt senzilla, penseu que quan volem definir l’alias d’una interficie de xarxa ecencialment només ens cal la IP de la mateixa i la màscara. Així doncs en la interficie de de rutes estàtiques només haurem de definir aquestes dues dades si volem que la informació serveixi per declarar l’alias.

alias.png

Si pel contrari el que volem afegir a la interficie és una ruta estàtica aquesta haurà d’usar un gateway. O sigui, una direcció de xarxa, una màscara i un gateway això ho interpretarà l’script per definir una ruta estàtica.

route.png

Amb aquest petit ‘trick’ ja tenim una interficie que ens permet de forma molt senzilla en cada AP per guardar-hi la informació que el diferenciarà dels seus veins. Després el que fa el nostre script s.sh és mirar les variables d’NVRAM on es guarden i tractar aquesta informació segons la lògica que he comentat anteriorment. A continuació us enganxo un tros del contingut del s.sh on podeu veure com es fa això.

# Rutes i interficies virtuals
COMPTADOR=0
for AD in `nvram get static_route`;
do
        IP=`echo $AD | cut -f 1 -d ":"`
        MASK=`echo $AD | cut -f 2 -d ":"`
        GW=`echo $AD | cut -f 3 -d ":"`
        IF=`echo $AD | cut -f 4 -d ":"`
        echo $IP $MASK $GW $IF
        # es un enllas punt a punt
        if [ $GW = "0.0.0.0" ];
        then
                # creem les ips virutals de la interficie lan/wlan
                # trafic backbone
                COMPTADOR=`dc $COMPTADOR 1 + p`
                ifconfig br0:$COMPTADOR $IP netmask $MASK
        else
                # afegim rutes cap a trafic d'usuaris
                route add -net $IP netmask $MASK gw $GW
        fi
done

Encara que sembli mentida el que més va costar en aquest script és implementar el comptador, ja que la shell del Alchemy és molt reduida i no ens permet implementar comptadors de forma directa. Per fer això varem trobar un petit paquet que va instal·lat al sistema que es diu dc, és semblant al bc la famosa calculadora en format CLI que porten els linux, però la sintaxi és una mica diferent. Així que el tema ens va fer suar una bon estona.

La resta de l’script no té cap misteri com podeu comprovar. Obviament és molt millorable i es poden integrar moltes més funcions, però com a introducció a la idea crec que ja he donat prou dades sinó trobo que ho complicaria massa. Així que espero que us sigui útil i si en voleu més o teniu algún dubte ja sabeu on sóc.

Truquillo: Linksys WRT54G en mode client

Reading time: 2 – 2 minutes

La veritat és que no sé si algú ja hi havia pensat, jo crec que si però no ho he vist en cap manual i m’he trobat a molta gent que es queixava del mateix. Així que hi he pensat una solució que com dic imagino que més d’un ja hi deu haver pensat. Bé comencem explicant el problema:

El Linksys WRT54G si el fas treballar en mode client, jo només ho he provat de fer amb el firmware Alchemy, té problemes per enllaçar amb l’SSID que l’hi hem especificat i connecta al primer AP que troba tingui el nostre SSID o no. Així que a més d’un l’obliga a fer filigranes perquè enllaci a l’AP que l’interessa.

Doncs bé, el tema és tan senzill com aprofitar les funcionalitats de filtratge de MAC que porta el propi firmware. Per dir-li o bé que només pugui connectar a la MAC de l’AP que té l’SSID que ens interessa o bé, just el contrari. Podem indicar a quines MAC dels AP veins no volem que s’associï el nostre linksys.

Tonta la cosa,eh!? doncs a mi m’ha funcionat a la primera, a continuació us poso un screenshot on podeu veure on posar lo del filtratge de MACs.

apclient.png

En aquesta captura de pantalla es pot veure com li diem que només connecti a la MAC indicada. Que és la del AP al que vull connectar-me.

re-numerant la xarxa wifi de Torrelavit

Reading time: < 1 minute

Malgrat la gent de guifi.net s’ha currat molt el tema del WDS per montar la xarxa mallada qeu tenen (mesh) a Torrelavit no tenim prou nodes com per montar una infraestructura d’aquest estil i el fet de tenir gran part de la xarxa via cable i no via wifi encara la fa més particular. Així doncs, no hem heredat el seu sistema de capa 2 però si el de capa 3. Aquí teniu el nou pla d’IPs que estem aplicant a la xarxa de Torrelavit.

UTStarcom F1000

Reading time: 3 – 5 minutes

Ahir vaig estar jugant una estona amb el F1000, per fi l’he pogut configurar perquè treballi amb l’asterisk i fer proves de roaming al canviar d’AP enmig d’una trucada.

utstarcom.jpg

Configurant-lo per Asterisk

Doncs bé configurar-lo a l’asterisk té el seu truquillo. Perquè jo no acostumo a usar un parell de paràmetres que són indispensables perquè es pugui registrar el tlf com a extensió SIP. Aquí us poso la meva configuració al fitxer sip.conf:

[ebosc112]
type=friend
username=ebosc112
secret=ebosc112
host=dynamic
dtmfmode = rfc2833
callerid = "ebosc112" <112>
context=sip
mailbox=112
context=usuaris
defaultip=192.168.27.122

No acostumo a posar la defaultip a cap extensió SIP, però degut a que el tlf quan fem molts salts entre APs a vegades queda desregistrat de la PBX això m’ajuda a que pugui rebri trucades malgrat no està registrat. Tot i resoldre el problema de rebre trucades no serveix per solucionar el problema de no poder trucar per no estar registrat i s’ha d’apagar el terminal i tornar-lo a encendre. Sort que va ràpid, uns 20seg.

Quan configureu el tlf tot s’ha de fer normal tal i com explica el manual, només comentaré la part de configurar el SIP que és on es fa una mica més complicat.(us comento la meva configuració)

Anem al menú de configuració SIP: MENU->WiFi Settings->Signal Protocol->SIP

Usem IP per referir-nos al servidor SIP: SIP Proxy Mode->IP

Definim IP del servidor SIP: SIP Proxy IP address->192.168.1.1

Usem IP per referir-nos al servidor SIP: SIP Proxy Mode->IP

Definim el nom d’usuari SIP: SIP User Name->ebosc112

Paraula d’accés al servidor SIP: SIP Authentication String->ebosc112

Paraula clau d’accés al server SIP: SIP Password->ebosc112 per introduir aquesta paraula hi ha ‘truquillo’ ja que en principi el tlf ús demana un codi numeric que es mostrarà per pantalla amb ‘*’ el codi de desbloqueix per poder escriure el ‘password’ heu de posar ‘888888’. Llavors saltarà a una altre pantalla que us deixarà escriure el password.

Doncs bé tota la problemàtica venia perquè aquest útlim detallet que he comentat no ho posava al manual i ho he trobat al forum de suport a l’usuari d’UTStarcom. Una suada per trobar això 😉

Roaming

Com sabeu el que realment m’interessa és poder anar saltant entre diferents APs sense que es tallin les trucades. Doncs bé tot i el gran resultat obtingut amb el Cisco 7920 aquest terminal triga una mica més a fer el canvi d’AP i almenys durant uns 5s es perden paquets i es per la veu de la trucada, tot i que per sort no es talla la trucada.

També he fet una prova una mica més radical i és que quan estic sota la cobertura de dos APs si apago un dels APs he comprobat que la trucada es talla i que el telèfon no es registra altre cop fins que no l’apaguem i l’encenem de nou.

Valoració

Malgrat va prou bé i les trucades se senten força bé i el rendiment de la bateria és molt bo. Cal dir que després de tocar el Cisco 7920 es nota que l’UTStarcom F1000 costa 1/5 part que el Cisco. Tot i que com dic és un terminal molt recomanable ja que la relació qualitat preu és molt bona.

El proper objectiu és provar el Zyxel que segons m’ha dit el Xoli a MicroBR el tenen en súper-oferta per 130¤, pensant que abans valia més de 300¤ la diferència és substancial… bé ja us comentaré quan el provi.