Després de molts mesos amb un greu problema de rendiment al servidor SAN/NAS de casa que tinc montat en una màqina virtual d’VMWare Server sobre Ubuntu 8.04 LTS, per fi m’he decidit a arreglar el problema. En algún altre post havia comentat el problema, la qüestió és que el rendiment dels 1.5Tb que tinc al servidor des del sistema operatiu de Host és d’uns 70MB/s però les mateixes proves des dels discos gestionats per la màquina Guest, o sigui l’OpenFiler, donaven uns patetis 3, 4 o com a molt 5MB/s. O sigui, que quan s’accedia per NFS o SMB als recursos compartits el rendiment era insuficient i d’altres servidors o màquines que usen aquests recursos se’n veien repercutits.
Finalment després de buscar una mica vaig veure que el problema venia de les interrupcions del sistema que es perdien degut a que el clock rate del servidor Host no era capaç de processar tantes interrupcions. Així doncs, investigant sobre el tema vaig veure que el que cal fer és donar suport HPET, en el meu cas perquè això funcioni ho he hagut d’activar també a la BIOS del HP ML110 que uso com a servidor físic. Amb aquests canvis els tests de velocitat de la màquina virtual amb OpenFiler m’han millorat substancialment i ara mateix donen resultats al voltant de 50MB/s. Obviament, encara estic lluny d’un rendiment òptim però ja no sé si això és tema de configuració o si el problema és més profund i ja depèn de la propia gestió interna que fa l’VMWare amb els mòduls que fan d’interficies entre el hardware real i el virtual.
Si voleu saber si teniu el HPET activat o no al kernel és tan senzill com mirar al dmesg:
A part d’això hi ha d’altres opcions per tal d’acotar aquest tipus de problemes, algunes que permeten estabilitzar les màquines virtuals malgrat no les expremem al màxim ens poden permetre funcionar millor si el rendiment no és el màxim dels nostres problemes i no saturem el Host. Per exemple, es pot afegir al fitxer .vmx de la màquina virtual la següent opció:
host.useFastClock=FALSE
Per cert, si voleu identificar el problema el kernel de la màquina Host dona errors de l’estil:
Com sempre a google podeu trobar moltíssima informació de com ajustar el vostre Linux perquè rendeixi al màxim amb VMWare. Per la meva part, ara hem queda posar en marxa mil i una coses que depenien d’aquest servidor de fitxers que mica en mica anava obligant-me a parar serveis per manca de rendiment. Espero que properament ja pugui posar en marxa funcions com l’album de fotografies i d’altres similars.
Aquesta tarda he estat provant el Huawei E960 de Voafone, després de l’experiència llarga i dur amb els Linksys WRT54G3G avui tocava descobrir el nou producte de Vodafone. Doncs bé, dir que venint dels Linksys que tants i tants problemes m’han donat, penseu que en tenim ara mateix instal·lats més de 200 i s’espera tenir-ne molts més en els propers mesos i la cosa esta lluny de funcionar bé. Per un costat els problemes de cobertura de l’operadora sobre els que no s’hi poden fer res i per l’altre el fet de que les targetes PCMCIA no acaben de funcionar massa bé ni soles ni amb el router Linksys com a host.
Els problemes típics han estat connexions que el router no informava correctament amb els leds, problemes de bloqueix de SIM per excés de reintents després de que la configuració es guardés malament, molts problemes d’accés a l’interficie web per la configuració i moltes connexions en falç fetes pel propi router. O sigui, connexions no demanades, connexions demanades i no detectades, etc. Per no parlar de la pobre configuració del linux que porta el Linksys dintre que fan que el rendiment del petit switch que incorpora l’aparell funcioni prou malament amb d’altres linux connectats a ell.
Bé doncs, al que toca. El nou router de Vodafone no és pas la ‘panacea‘ ni la solució a tots els malts de caps, però de moment sembla molt més estable i el que ja salta a la vista és que aquest mateix article l’estic escribint connectat des de casa meva a 2.6Mbps que malgrat estar lluny de ser reals donen un bon servei. Així doncs, això pot ser una gran notícia per alguns torrelavidencs que no disposen d’ADSL per manca de qualitat en les seves línies.
Pros a favor del modem/router:
Pots connectar-hi un telèfon analògic i usar el router per trucar com si es tractés d’un fix
4 ports ethernet, que sembla que funcionen millor que en el Linksys
CD d’instal·lació com a dispositiu Mass Storage USB dins el propi router
Alimentació amb connector USB tipus B, via port USB o via transformador
Suporta molts mètodes d’autenticació wi-fi, lluny de ser professional però destaca el suport d’WPA2
Molt compacte
No usa PCMCIA, per tant, disposa d’un compartiment especial per la SIM
Sembla estable, de moment
Bones orelles, o sigui, deu tenir una bona antena per aconseguir treure connexions HDSPA des del meu poble
Fàcil usar-lo en mode DMZ o redirigit conta un servidor/firewall
Contres:
No hem funciona com a modem USB a la primera al connectar-lo a un WinXP amb SP2, no he intentat arreglar el problema
Interficie web de configuració molt pobre i lletja, malgrat això sembla que funciona ràpid i bé
Firewall intern molt lamentable, lleig i limitat. Poc intuitiu el tema del NAT
No suporta DynDNS (o similars), el Linksys si que ho suportava
En poques paraules aquest és el meu anàlisis del dispositiu. Com ja deia no és per tirar coets però sembla que algo de millora si que és sobre el Linksys.
UPDATE: ahir estava una mica espès i no se’m va acudir enganxar el test de velocitat que vaig fer amb el dispositiu, aquí teniu el test fet des de casa meva al mig de la muntanya 😉
GatV2 es un servidor de correo para hacer smart-relay o para que se entienda mejor el concepto para usar como frontend del servidor de correo de la empresa o del ISP (backend). GatV2 nos filtra todo el correo UCE y nos ofrece una herramienta de gestión del SPAM.
El siguiente esquema ofrece una idea de donde estaría el GatV2:
A través del podcast podreis seguir cual es el proceso que sigue un correo para pasar através del GatV2. Obviamente no es sencillo entender a la primera todo lo que hace pero a través de este gráfico (pinchar encima para zoom), de la explicación y de la documentación de la web del proyecto espero que podais comprender mejor el proceso.
Para ver las capturas de pantalla a las que se habla durante el podcast pasarós por la documentación del proyeco GatV2.
Finalmente el podcast:
[display_podcast]
El podcast dur alrededor de 1h, así pues Jorge me ha ayudado a hacer una tabla de contenidos del mismo así pues, podeis ir directamente al minuto que os interesa del podcast gracias a la siguiente información:
Presentación: 0-1m44s
Historia: 1m44s – 3m
En que consiste: 3m – 8m15s
Los componentes: 8m15s – 24m20s
Como funciona: 24m20s – 42m49s
WebUI del DSPAM: 42m49 – 55m55s
Despedida y cierre: 55m55s – 56m56s
En los próximos dias publicaremos (Jorge y yo) el podcast dividido en pequeños MP3 en l página del proyecto GatV2 para mayor comodidad de los interesados en el proyecto.
Tal dia com avui a la bonica vila de Vinaròs (Castelló) vaig començar a escriure el meu blog, tranquils no tornaré a explicar la història que he explicat mil vegades sobre els inicis del mateix. Això si referenciaré el podcast 1×01 on explico els inicis del mateix per si algú encara no ho sap. Per altre banda, fa uns mesos no recordo qui hem va comentar la possibilitat de fer una gran festa per celebrar el 10è aniversari del blog i crec que agafaré la idea i des de ja començaré a pensar alguna forma ben original, i com sempre ben acompanyat dels mussols, per celebrar aquest fet tan insòlit. No tothom té la paciència d’aguantar tan de temps online 😉
Bé doncs aprofito aquest post que no ve a dir res d’interessant més enllà de l’efemèride per posar-vos una mica al dia de la meva vida i del perquè aquest mes he postejat tan poc, a més d’engaxar unes quantes fotos que tenia perdudes pel mòbil i que sota el meu punt de vista són dignes de comentar.
El primer i principal motiu del meu silenci és el que ja explico al podcast 1×11 i a l’article del ‘desafio networking‘, o sigui, el problema amb el ditxós dispositiu que m’ha portat pel camí de l’amargura alguns mesos fins que la situació ha estat insostenible i m’he hagut de buscar la vida buscant una solució urgent abans el mal no fos major. La resta de motius són de caire més personal, així doncs aprofito per comentar-vos en primícia que a partir del dimarts que ve ja no viuré sol. O sigui, que obro un nou cercle en la meva vida acompanyat de l’Estefania. Com a soferts lectors del meu blog haureu d’aguantar els comentaris que sovint es derivaran de la meva vida personal al costat d’aquesta persona tan especial per mi, ho sento per vosaltres però me n’alegro molt per mi 😉
Un cop fet aquest petit update a la meva vida i al meu silenci, una foto ben distesa d’una raqueta i una pilota de tenis gegants que hem vaig trobar pel carrer sortint d’un dinar familiar. Pels que no estigueu al corrent el tenis és un dels pocs hobbies no relacionats amb la tecnologia que hi ha a la meva vida i he de dir que malgrat sóc un paquet m’encanta jugar i ho passo genial.
Anant a temes més tècnics comentar que he hagut de canviar els dos estractors d’aire que tinc al petit-CPD de casa ja que s’havien fet malbé els motors que porten de tan donar voltes. N’he instal·lat un parell de nous i ara els he posat uns simples i ecònomics termostats de calefacció però en mode NC, d’aquesta manera malgrat són termostats de calefacció puc usar-los just amb la funció inversa. És a dir, mentre la temperatura ambient no baixa de una temperatura prefixada els estractors tenen corrent per funcionar, quan la temperatura baixa el termostat activa el relé i el que fa és tallar la corrent parant els motors. Comento això perquè fins ara jo només coneixia termostats que funcionaben en mode NO, o sigui, just alrevés del que he comentat. Però gràcies al Magí ara tinc aquest parell de termostats que funcionen la mar de bé, llàstima que hagin d’anar alimentats amb 2 piles AAA.
Comentar també que ahir vaig ser a l’oficina fins ben tard acompanyat de tres bons geeks: el Pof, l’Esteve i en Marc. Realment va ser una sessió molt constructiva sobre temes de cross-compiling per ARM9 una informació molt valuosa i que gràcies a l’Alfredo ben aviat serà una solució al problema que he tingut aquests mesos i que unes ratlles més amunt comentava.
Abans d’acabar no podia deixar de comentar que també vaig tenir l’oportunitat de jugar amb la HTC Diamondd que tan l’Esteve com en Pof ja tenen des d’ahir. Realment ha millorat molt aquesta HTC i ja es perfila com un ferma candidata a la meva pobre HTC Artemis que esta patint les més dures proves per ser el meu mòbil personal. No només vaig poder comprovar que el Diamond soluciona molt bé els problemes de velocitat que tenen els dispositius amb Windows Mobile sinó que l’accelerometre que incorpora és genial. En Pof també em va fer una demostració de tots els hacks que li ha fet la HTC Shift, a la que ja li ha canviat la ROM del Windows Mobile que incorpora i ha substituit el Windows Vista per una Ubuntu 8.04 que va com una seda, tota una delicia de dispositiu. La seva mida com a ultra-mobile PC esta molt bé, i si no fos pels inconvenients de no fer de telèfon malgrat tenir funcions de HDSPA i similars es consolidaria com un ferm candidat a substituir l’HTC Kaiser que em té aborrit amb la seva lentitut. Si la comparem amb un mòbil és molt gran, però és realment útil per treballar i que en el futur algún germanet seu espero que acabi sent la meva eina de treball de capçalera si no fos pel tema de no poder fer de telèfon ja ho seria aquesta però hauré d’esperar.
Reading time: < 1 minute
Hablando sobre el problema del articulo sobre el desafio de networking. También aprovecho para enlazar una buena referencia sobre como comprender los problemas de secuencias TCP:
Espero haberme explicado bien y haber podido describir el problema algo mejor que en el articulo anterior, ya que no es sencillo describir un problema tan inusual.
Se dispone de un dispositivo de hardware con un linux embedded al que no se puede acceder ya que el fabricante no lo facilita, se ha intentado acceder pero no hemos sido capaces de acceder ni con nuestros medios ni con los de una importante empresa de electrónica. Creemos que el kernel es un 2.4.X por lo que observamos. El dispositivo tiene una pantalla y su finlidad es mediante un protocolo propietario y un protocolo de transporte de ficheros (FTP) descargar una playlist para reproducir en la pantalla.
A través de red se conecta al servidor del fabricante de donde recoje una playlist y unos contenidos multimedia. Escencialmente usa los puertos:
TCP/8889 (protocolo de control del fabricante) va en ‘plain text’ ya le hemos hecho la ingenieria inversa.
FTP en modo pasivo
Con el servidor del fabricante descarga el 99% de la veces correctamente y sin problemas. En el fichero adjunto ‘korea-ok.cap’ si lo examinais podreis ver que todo se desarrolla perfectamente. La IP privada que podeis ver es del dispositivo en la LAN y a través de una LMDS se conecta a Korea a la IP: 210.114.220.180, si os fijais el fabricante usa como servidor FTP un ‘Serv-U’ para Windows.
Problema
Se ha implementado el protocolo propietario del fabricante con Python y funciona perfectamente, el problema es al hacer la descarga por FTP. El dispositivo se conecta a nuestro servidor FTP y de forma completamente aleatoria cierra la transmisión sin motivo aparente y se reinicia el dispositivo. Esto siempre pasa mientras se esta haciendo una conexión FTP-control (21/tcp) o FTP-data (puerto aleatorio del ftp pasivo/tcp).
En el fichero ‘cwd-fail.cap’ se puede ver uno de los típicos fallos que tiene el dispositivo al intentar descargar a un servidor FTP local (en este caso un proftpd en una Gentoo). Concrectamente al mandar el comando FTP ‘CWD’ el dispositivo decide cerrar la conexión y no seguir con la descarga. Después de varios intentos se reinicia. Para no perderos con los paquetes he dejado en la captura sólo el socket que tiene el problema.
Para no despistar recordar que esto no tiene porqué pasar en el canal de FTP-control puede pasar también en un FTP-data, puede pasar al 1% de descarga del fichero, al 30%, 50%, 98%… es completamente aleatorio.
Para tener más ejemplos de errores se adjunta el fichero ‘local-fail.cap’ donde se puede ver como se da un error igual al anterior pero ahora en el canal de datos de FTP. Concretamente podeis ver como se cierra el socket en el paquete 916 sin motivo apararente. Comentar que los errores de checksum de TCP no son relevantes ya que son debidos a que la tarjeta de red no estaba como sigue:
En otras pruebas se han hecho con los parametros comentados y el error es el mismo. A pesar de que ya no aparecen las alertas por ‘checksum error’. Si se cree vital tener una captura sin los errores de checksum no hay problema en hacerla. Pero después de meses de pruebas esta claro que esto no es relevante.
Para demostrar que el comportamiento es aleatorio a continuación se adjunta un fichero ‘local-ok.cap’ con la captura de una sesión en el serividor FTP local que ha funcionado perfectamente. Se puede observar en el paquete: 18975 que se descarga bien el contenido de un fichero, concretamente un fichero .mpg, con este fichero finaliza todo el traspaso de datos correctamente.
Hardware y soft probado
Se han hecho infinidad de pruebas y de combinaciones:
5 servidores distintos:
1 debian con kernel 2.6.24.5-grsec-xxxx-grs-ipv4-64 en el proveedor ovh.es (100Mpbs simétricos sin restricciones), servidor FTP proftpd puerto 2090/tcp
1 debian con kernel 2.6.18-5-686 proveedor jazztel sin fw, ni restricción de ningún tipo 100Mbps simétricos contra internet y servidores FTP en el puerto 21 pure-ftpd y en el puerto 2090 proftpd.
1 ubuntu con kernel 2.6.24-16-server proveedor jazztel con fortinet como fw en modo transparente, proftpd en puerto 2090.
1 gentoo con kernel 2.6.25-gentoo-r5 en red local con proftpd en puerto 2090.
1 windows xp virtualizado con vmware workstation 6 sobre gentoo con un servidor FTP Serv-U, la tarjeta de red virtual en modo bridget con la del sistema operativo host.
el comportamiento es el mismo con todas la combinaciones
Intuición de solución
Jugando con los parámetros del kernel de TCP (/proc/sys/net/ipv4) se consiguen hacer cambios de comportamiento en el error. Por ejemplo, se han hecho pruebas con:
También se han hecho pruebas limitando el ancho de banda, y con algunos otros parámetros de kernel que ahora no recuerdo. Se ha probado de opimitzar los servers para rendir al máximo, al mínimo, por defecto… etc.
Lo que se consigue con todo esto es conseguir que algunas veces se haga la descarga, pero no se consigue afianzar patrones de forma feaciente, es decir, a menudo se sigue cerrando la conexión TCP.
FAQ de obviedades
Es obvio que el firmware del dispositivo esta mal hecho, pero esto no se puede tocar.
El dispositivo se puede configurar via una compact flash, donde se guarda un fichero de configuración, un fichero binario compilado para ARM y el contenido multimedia que se va descargando.
Se ha intentado hablar mil veces con el fabricante pero es como hablar con una pared, a parte los técnicos no hablan inglés, sólo coreano. Increible, no?
El problema lo tiene el stack TCP del dispositivo o algún otro elemento similar. Este es el que cierra la conexión!!! no se puede mantener la conexión abierta des del servidor cuando el dispositivo la ha cerrado, lo único que se puede hacer es evitar que el cliente la cierre. El problema es como.
Si! el server del fabricante descarga bien via FTP en el 99% de los casos. Este es el gran probleam, parece tonta la pregunta pero me la han hecho como 20 veces, así que merecia estar aquí.
Ficheros
Los ficheros de los que se habla en este correo de pueden descargar de:
http://oriolrius.cat/downloads/korea-ok.cap
http://oriolrius.cat/downloads/cwd-fail.cap
http://oriolrius.cat/downloads/local-fail.cap
http://oriolrius.cat/downloads/local-ok.cap
Desafio
El entorno de laboratorio lo tengo montado en la oficina, esta abierta 24×7 para quedar conmigo para hacer pruebas in-situ. Obviamente responderé todo lo que sea online y orientaré con lo que pueda y más.
Este problema lo arrastro desde hace unos 4 meses y llevo casi 4 dias sin vida, sólo obsesionado buscando la solución pero no hay manera de ver la luz.
No dispongo de muchos recursos, debido a que ya he perdido muchísmo dinero buscando la solución durante todo este tiempo, pero bajo resultados se recompensará tanto como sea posible a la mente privilegiada que consiga dar con la solución.
Ya tengo solución
Después de darle vueltas al tema de momento no contaré las varias soluciones que a dia de hoy ya he enontrado al problemón. Así pue aprovecharé el problema para lanzar el podcast 1×11 describiendo con todo detalle el problema y dando algunas pistas de como llegar a la solución. Quizá a nadie le pique tanto la curiosidad como para seguir la solución con este detalle pero de esta forma mantengo un poco la intriga y si alguien realmente necesita saber la solución sin seguir el culebrón sólo tiene que mandarme un correo privado y se lo contaré. Para hacer boca deciros que la intuición de solución que tenia no era mala.
Aquest podcast és un experiment entre el Pau Freixes i jo mateix parlant sobre com es podria solucionar els grans problemes de disponibilitat de twitter. Fa molt de temps que dono voltes en com es podria solucionar tota la problemàtica de twitter via un backend de jabber i xmpp. Aquest esquema descriu una mica la idea que s’explica al blog:
[display_podcast]
NOTA: a partir d’ara ja no posaré més música de fons als podcast i intentaré no fer gens o quasi gens de post-producció al que gravo. Ja que ni se’m dona bé ni tinc ganes d’invertir el temps en fer coses qu no m’aporten ni em motiven. Crec que el que intento transmetre ja queda clar.
No sóc un gran coneixedor dels productes de RH, ni tampoc de Fedora ni CentOS. Malgrat això per temes de Kerberos, LDAP i d’altres similars m’estic endinsant força en aquest món. Doncs bé, el dia 20 de juny la gent de RH van alliberar el codi del RedHat Network Satellite al project l’han anomenat spacewalk. Després d’una bona estona llegint la seva documentació volia comentar que la idea que proposen i el nivell d’integració que té l’eina és molt bona, malgrat això he de dir que no hem serveix de gran cosa degut a que esta massa orientat a distribucions amb sistemes de paquets .rpm, o sigui, la propia RH i Fedora sobretot, de CentOS i la resta en parla ben poc.
Cal dir però que les funcionalitats que ofereix són relment una font d’inspiració per d’altres productes que algún dia algú haurà de dissenya per distribucions basades en .deb, o sigui, debian i ubuntu bàsicament.
Llistat de funcionaltats de l’spacewalk:
Inventory your systems (hardware and software information)
Install and update software on your systems
Collect and distribute your custom software packages into manageable groups
Provision (kickstart) your systems
Manage and deploy configuration files to your systems
Monitor your systems
Provision and start/stop/configure virtual guests
Distribute content across multiple geographical sites in an efficient manner.
A continució ús dono una petita llista d’eines que malgrat no estar tan ben integrades com l’spacewalk i sovint no disposar de bones interficies poden ser un bon punt per començar a solucionar alguns problemes:
puppet: basada en un llenguatge ruby com a llenguatge d’scripting per llençar funcions remotament contra sistemes remots, l’eina és realment potent però la veig poc integrada amb el sistema operatiu i es basa molt en funcions com expect per capturar les sortides de les comandes de sistema executades remotament. A més considero que no té un bon sistema d’informes per saber com ha anat el deploy.
capistrano: molt semblant a puppet, tan és així que usa també ruby com a llenguatge d’scripting i tots els problemes comentats antiriorment els hi veig també a aquest. Té una mica més ben resolt el tema del feedback dels deploys però sota el meu punt de vista no acaba de ser suficient.
func: projecte que també ve de RH i que té el codi alliberat, actualment en fan el manteniment la gent de Fedora. Es basa en Python com a llenguatge d’scripting i ofereix tota una API per la gestió de comandes remotes, ben pensat per xarxes grans ja que permet llençar comandes de forma asícrona. Disposa d’una molt bona integració amb el sistema operatiu gràcies a la gran quantitat de bindings que te Python. Per exemple, com que és un producte de fedora només disposa de binding genèric de yum per instal·lar paquets remotament, però gràcies a que el llenguatge d’scripting és Python és molt senzill crear un mòdul de func que enllaci amb python-apt i permetre instal·lar paquets a una ubuntu. Aquesta bona integració permet controlar els feedbacks d’una forma molt eficients malgrat no disposa d’eines d’informes pròpies.
fai: és una eina pensada per fer instal·lacions automàtiques de distribucions linux o de sistemes de clusters, ja siguin virtualitzats o amb màquines reals. El projecte té uns grans avals i porta moltíssims anys online i actiu. Per tant, dona moltíssima confiança. El dolent és que no sembla trivial d’usar i malgrat té una eina per monitoritzar l’estat del deploy és basa moltíssim en CLI. No he vist cap GUI que en faciliti l’ús excepte GOSA, el qual és un projecte molt ampli d’LDAP bàsicament usat per la migració a Linux de l’ajuntament de Berlin.
cobbler: una eina molt semblant a fai, però de la gent de RH i amb el codi alliberat. Té molt bona pinta i a més s’integra amb func. No l’he estudiat a fons encara per saber on té els punts febles, ja que com sempre el que més por fa és la dependència de paquets .rpm; malgrat això disposa d’una interficie web per la gestió, línia de comandes i API en python per extendre les seves funcionalitats i sempre es podria lligar una instal·lació cobbler amb func perquè fos compatible amb ubuntu tal com havia comentat abans.
L’abril del 2007 ja vaig parlar sobre tcpxd el qual permetia fer el mateix que rinetd. Obviament tenen algunes diferencies funcionals, sota el meu punt de vista rinetd és més professional ja que integra a partir d’un fitxer de coniguració la possibilitat de redireccionar un port TCP en qualsevol de les IPs que estem publicant en el host on es llenci el servei. A més el fitxer de configuració ja diu tot el que cal saber de com funiona:
Algunes altres funconalitats que m’han agradat molt és la possibilitat de fer una llista ACL de rangs d’IPs permesos i no permesos. Per si això fos poc suporta logging. A més el podem trobar com a paquet de les distribucions de linux: gentoo, ubuntu i debian. Potser hi ha altres distribucions que el tenen però la veritat és que no les uso. També aprofitor per recordar-vos que si necessiteu fer coses d’aquest estil amb windows podeu llegir aquest article: Redirigir ports amb Windows (Port Forwarding, DNAT, NAPT).
Si esteu familiaritzats amb iptables i voleu fer una redirecció poseu-hi una mica d’enginy i podreu fer-ho amb relges tan simples com aquesta:
Reading time: < 1 minute
No m'havia posat a provar mai el microfon intern del portàtil ja que sempre havia llegit que no funcionava. Però ahir vaig actualitzar el kernel a la verisó 2.6.25-gentoo-r5 i hem vaig decidir a provar a veure què tal. Doncs bé la veritat és que oli en un llum. Ja que només he hagut de canviar la font d’entrada de gravacions i ha funcionat a la primera així és com l’he de deixar:
Aquesta tarda he estat provant el 
