Al projecte GATv2 fa un parell de dies que hi he publicat un subprojecte que anomeno tcp-fwd. Es tracta d’un petit i simple aplicatiu programat amb Python i Twisted. La funcionalitat és molt senzilla es tracta d’un bouncer TCP que en cas de no poder connectar amb el primer destí on re-enviar el tràfic TCP ho prova amb el segon, sinó el tercer i així fins a tants servidors com s’hagin definit. Si no es pot acabar establint la connexió es desconnecta l’enllaç TCP cap al bouncer. O sigui, el comportament és transparent pel client original. Pels que no estigueu familiaritzats amb la funcionalitat d’un bouncer la intentaré explicar. Es tracta d’un socket TCP que escolta en un port i actua com un reverse proxy. O sigui, quan rep una connexió acte seguis s’obre una altre connexió cap al servidor i si aquesta es pot establir llavors connecta la primera connexió amb la segona.
L’inconvenient més gran que veig en aquesta idea és que la connexió que arriba al servidor final no té com a origien la IP del client, sinó la IP del servidor que fa de bouncer això fa que el fitxer de logs del servidor final no tingui la informació IP del client que realment s’ha connectat. Malgrat axiò hi ha escenaris en que aquesta eina és molt útil, ja que no sempre el més important són aquests logs sinó que el client acaba obtenint el servei que volia de forma trasparent i el sistema de failover que uso sempre segueix la mateixa seqüència de prova i error per cada socket que s’obre, així doncs, el sistema de failover és instantani i no perd ni una sola crida.
Una de les aplicacions per les que l’estic usant és per fer l’entrega de correu a un postfix. Es tracta d’un servidor de correu que només fa filtratge de correu i els correus que passen els filtres s’entreguen al servidor de correu real de l’empresa, doncs bé, per saber quin és el servidor de l’empresa uso el fitxer de configuració /etc/postfix/transport on s’indica segons el domini el servidor on entregar el correu. Però no he sabut veure com dir-li més d’un servidor de correu on fer l’entrega. Així doncs, el que faig és posar com a IP i port de transport una IP localhost i un port al atzar, llavors el postfix entrega el correu al bouncer situat en aquesta IP localhost i és el bouncer que intenta connectar aquest socket amb algún dels servidors de correu interns. Per tant, el tema és completament transparent pel postfix i els servidors que reben el correu tenen la mateixa IP origen que si ho haguessin rebut directament del postfix.
Suposo que la idea ha quedat ben definida, sinó ja sabeu que podeu fer-me les preguntes que calguin. El codi del projecte el teniu a: tcp-fwd.
Tothom coneix el TCPdump i fins hi tot hi ha gent com jo que l’usem a diari, de fet, no fa massa temps vaig re-descobrir el TCPflow (ja l’havia descobert abans, però vaig cometre el gran error d’oblidar-lo). Doncs bé, el problema d’aquestes eines és que són molt útils per tràfic sense xifrar però quan es tracta de tràfic xifrat amb SSL/TLS com ara HTTPs o d’altres protocols que viatgen xifrats i volem saber perquè no funcionen hem de recorrer a eines com el ssldump.
SSLdump permet seguir el fluxe de les conexions TCP xifrades amb SSLv3/TLS. Obviament per aconseguir desxifrar el contingut de l’enllaç hem de facilitar-li els certificats corresponents a l’eina. Però no només ens permet depurar a nivell de dades que corren per TCP sinó que també ens dona informació del propi protocol de xifrat descrita de forma humana. O sigui, que podem saber si el problema de l’enllaç és produeix durant el procés de handshake, ChangeCipherSpec o dins del protocol.
El que jo feia fins ara per poder analitzar el contingut d’un protocol que viatge xifrat és ajudar-me de l’eina sslproxy. La qual feia de bouncer al servidor de protocol o al client, així doncs obtenia un tram de la conexió que no anava xifrat i a través del tcpflow o el tcpdump podia obtenir el tràfic en clar. La tècnica és enginyosa i útil però ferragosa en comparació al ssldump.
La webcam del portàtil és una Omnivision amb resolució VGA, concretametn el model usa el idProduct: 0x7670. Doncs bé, gairebé mai uso la webcam així doncs un dia la vaig configurar i després se’m va oblidar com ho havia fet, avui actualitzant la Gentoo ho he recordat i vaig a posar les quatre notes aquí per si poden ajudar a algú i així ho usaré de recordatori per mi mateix.
En Gentoo la gràcia esta en tenir instal·lat el paquet: media-video/linux-uvc, aquest paquet genera un mòdul del kernel anomenat uvcvideo.ko que podem carregar amb un simple modprobe. Després, per exemple, amb el paquet media-video/luvcview podem llençar un simple aplicatiu anomenat: luvcview que ens permetrar fer captures de pantalla i de video a través de la webcam.
Com podeu veure ben senzill de configurar i d’usar, ara només cal que no feu com jo que no l’he usat mai més que per fer proves.
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.
Aquesta tarda he estat provant el 
