Author: Oriol Rius

Desafio Networking [el problema]

Reading time: 27 – 44 minutes

Escenario

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:

# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off

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:

tcp_adv_win_sacle = 0,1,2
tcp_allowed_congestion_control = cubic, bic, reno, etc.
tcp_base_mss = 512, 1024, 1500
tcp_dsack = 0,1
tcp_ecn = 0,1
tcp_fack = 0,1
tcp_sack = 0,1
tcp_syncookies = 0,1
tcp_timestamps = 0,1
tcp_workaround_signed_windows = 0,1
tcp_window_scaling = 0,1

infinidad de valores y combinaciones probadas en:

tcp_mem
tcp_moderate_rcvbuf
tcp_mtu_probing
tcp_rmem
tcp_tso_win_divisor
tcp_wmem

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

  1. Es obvio que el firmware del dispositivo esta mal hecho, pero esto no se puede tocar.
  2. 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.
  3. 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?
  4. 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.
  5. 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.

iG:Syntax Hiliter plugin amb WordPress 2.5.1

Reading time: 12 – 20 minutes

Per fi he trobat un plugin de highlighting que m’agrada, l’he trobat avui a través del blog del François Zaninotto. Llàstima que el plugin és força antic, no hi ha actualitzacions des de l’any 2006. Quan l’he instal·lat al WordPress 2.5.1 m’ha donat un problema amb els permisos malgrat estava com a administrador. Així doncs en un moment li he fet un workaround, o sigui, com que el blog només l’uso jo ara mateix i no uso els usuaris m’he saltat la validació que fa de si tinc permisos. D’aquesta manera l’he pogut configurar com pertoca.

Per si algú vol fer el mateix, al fitxer syntax_hilite.php li he comentat les línies que podem veure a continuació:

[php num=268]<br>//function for the Admin GUI<br>function igSynHilite_GUI() {<br>global $user_level, $igWpVersion;<br>get_currentuserinfo();<br>//if user is not an admin equalling/above level 8, then don't give any GUI<br>/*<br>if ($user_level < 8) { ?><br><div class="wrap"><br><h2>iG:Syntax Hiliter(v<!--?php print(IG_VERSION); ?-->) Configuration</h2><br><!--?php _e("<br><br><div style="color:#770000;">You are not a <strong>LEVEL 8</strong> or above USER &amp;<br ?--> hence you cannot configure <strong>iG:Syntax Hiliter</strong>. If you are a <strong>LEVEL 8</strong> or above USER,<br>then please Logout & Login again.<br><br></div><br>"); ?><br><br><?php return; } */ if(!empty($_POST['igsh_plainTxt'])) { [/php]

A més, els directoris que crea el fitxer .zip de la pàgina del plugin no són compatibles amb el WordPress 2.5.1. O sigui, que adjunto un .tar.gz amb els fitxers que he posat a BLOG_HOME/wp-content/plugins.

Per cert, el look’&’feel del plugin és el que podeu veure en el codi que hi ha aquí dalt.

podcast 1×10: La solució als problemes de Twitter

Reading time: 1 – 2 minutes

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:

twitter schema solution

[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.

spacewalk – el RedHat Network Satellite alliberat

Reading time: 4 – 6 minutes

spacewalk logoNo 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.

rinetd – un altre bouncer per TCP

Reading time: 2 – 2 minutes

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:

# bindadress    bindport  connectaddress  connectport
1.2.3.4         80        4.3.2.1         80
1.2.3.4         443       4.3.2.1         443

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:

YourIP=1.2.3.4
YourPort=80
TargetIP=2.3.4.5
TargetPort=22

iptables -t nat -A PREROUTING --dst $YourIP -p tcp --dport $YourPort -j DNAT --to-destination $TargetIP:$TargetPort
iptables -t nat -A POSTROUTING -p tcp --dst $TargetIP --dport $TargetPort -j SNAT --to-source $YourIP
iptables -t nat -A OUTPUT --dst $YourIP -p tcp --dport $YourPort -j DNAT --to-destination $TargetIP:$TargetPort

Microfon intern del Dell XPS m1330 funciona amb Linux

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:

gnome volume manager

La veritat és que he tingut molta sort 😉

Penedesfera: 1ers jornades

Reading time: 2 – 4 minutes

logo penedesferaDivendres passat i per casualitats de la vida em vaig enterar de que es celebraven a Gelida les primeres jornades de la Penedesfera. Doncs bé, la casualitat va ser gràcies a un twit del marcvidal que vaig començar a estirar del tema fins a descobrir que també hi havia convocada la gent de guifi.net per parlar del seu projecte. Doncs com que fa temps que els tinc molt abandonats a la colla de guifi.net li vaig fer un toc a en Ramon em va dir que si que hi seria i vaig agafar el cotxe i cap a Gelida.

1era jornada de la Penedesfera

Allà vaig retrobar-me amb una bona colla de guiferos i bloguers, a més de poder coneixer en persona al Marc Vidal que és un dels molts contactes que tinc a twitter i que no tenia el plaer de coneixer en persona. Llàstima no poder quedar-me fins al final de la sessió i encara menys no poder assistir a les jornades del dissabte. El que més em va agradar és veure el viva que esta la comunitat. Amb gent que té ganes de fer coses i el millor és veure com cada cop les barreres tecnològiques són un problema menys per sumar esforços.

De fet, jo mai m’he considerat un bon divulgador de tecnologia pel ‘poble’, de fet, tampoc ho he pretès això si he intentat posar el meu granet d’arena en la part més tecnòloga profunda que és on realment crec que aporto algo de valor. Diria que hi ha d’haver gent per tot per fer de ‘professors’, investigadors, desenvolupadors, analísties, etc. tampoc sabria on posar-me jo de totes aquestes etiquetes però de divulgador de temes iniciàtics segur que no.

Bé doncs, a veure si hi ha sort i tot això continua amb tanta o més força. A més ja m’he donat d’alta a la web de penedesfera i m’he posat el logo per donar-hi suport a la part dreta del blog. Com hi va la gent de les meves comarques, eh!?

Actualització: si voleu accedir a material  de les jornades esta disponible a l’arxiu de les jornades de la Penedesfera.

Reddit open source: aplicacions que destaco…

Reading time: 4 – 6 minutes

reddit logoAquest matí l’Alfredo m’ha informat que reddit ha obert el seu codi. Doncs bé després de mirar-me cada un dels components que ha explicat que esta usant m’ha faltat temps per passar-me per cada una de les pàgines web de les aplicacions per mirar-me a veure què tal. A continuació ús faig una llista del que més destaco, obviament són les aplicacions més inusuals i menys conegudes.

  • HAProxy: és un aplicatiu molt semblant al Pound, la seva finalitat es balacejar les peticions HTTP entre diferents servidors. Malgrat són aplicacions similars Pound i HAProxy poden treballar de forma combinada. Diguem que HAProxy esta molt més orientat a grans infraestructures i Pound és per entorns de carrega mitjana. El bo és que podem usar HAProxy i darrera usar Pound per fer redireccions més refinades en funció da la URL o certs paràmetres de les HTTP headers. També és diferencien bàsicament amb el tractament que fan dels paquets HTTPs, la qual també convida a treballar amb les dues eines a la vegada. Ja que podriem montar un sistema per escalar peticions HTTPs de forma segura i simple.
  • Slony-l:és un sistema de replicació master-slave que suporta treballar en cascada i amb failover. A més esta pensat per treballar amb bases de dades grans. Bàsicament usat pel PostgreSQL que usa reddit, això els permet tenir molts servidors de bases de dades de lectura que són les peticions que bàsicament tenen a la base de dades.
  • Pylons: es tracta d’un framework MVC que usa Python, és realment lleuger i combina idees del món Ruby, Python i Perl. Potser una de les coses que més sobte és que els projectes de Pylons no requereixe servidor web sinó es vol, ja que ells mateixos ja n’implementen un amb Python, a més de tenir un instal·lador del projecte que creem només pel sol fet de crear el projecte. Si ja controleu algún tipus d’MVC i esteu una mica familiaritzats amb la sintaxis de Python podeu veure l’screencast: Special Edition Screencast: Pylons with Tesla. Amb aquest screencast ús podreu fer una molt bona idea de com funciona aquest MVC i de la seva potència. S’ha de reconeixer que promet molt no ús perdeu el sistema de debug, realment m’ha agradat moltíssim pensava que el debug de Symfony era bo, però aquest encara el supera.
  • Slor: es tracta d’un servidor d’indexació d’informació web implementat sobre Tomcat i que ofereix serveis de consulta via JSON i d’altres sistemes webservice que simplifiquen moltíssim la seva integració amb d’altres arquitectures. A més disposa d’una llista de funcionalitats molt atractives.
  • Daemontools: una eina realment senzilla i potent, bàsicament només serveix per llençar processos com a dimonis o directament dimonis en si mateixos. El bo és que controla aquests dimonis per si aquests cauen tornar-los a aixecar. La veritat és que malgrat ser una mica més gran diria que és millor monit. Tot i que s’ha de dir que es triga molt mé  montar monit que no pas daemontools i com que la gent de reddit ja usen Ganglia com a sistema de monitorització no s’han complicat amb el monit.

S’ha de reconeixer que han fet molt bones eleccions aquesta colla, a més s’ha demostrat que són realment escalables i que la seva disponibilitat és envejable. Un bon exemple de com fer les coses bé i senzilles des del principi. La gent de twitter en podrien prendre bona nota. Si ús fa il·lusió un dia d’aquests ús explicaré les meves idees de com fer que twitter sigui molt escalable i no s’enfosi amb els 2M d’usuaris que té diariament, la qual cosa no em sembla cap exageració amb un bon disseny darrera segur que en Pau pateix molt més amb els seus milions de megues a indexar diarimant.

gDevilspie: entorn GTK per configurar el devilspie

Reading time: 2 – 2 minutes

Aquest ja és el tercer article que escric parlant de devilspie, així doncs no tornaré a explicar el perquè serveix si ho voleu saber:

Però la veritat és que feia uns mesos que l’havia deixat d’usar però hi he hagut de tornar. Des de fa força temps treballo amb dues pantalles, la del portàtil i una de 22″ tan a l’oficina com a casa. Doncs bé, fins ara ho feia amb Xinerama però degut als problemes que vaig tenir amb la NVidia i el Xinerama m’he passat a TwinView així puc usar el Compiz i uso les X’s al més pur estil Mac. De fet, jo diria al més pur estil Oriol 😉

screenshot of my laptop desktop

Doncs bé, tornant al que volia comentar el gDevilspie és un projecte que afeix una interficie gràfica que malgrat limita les amplies funcions de configuració que té el devilspie serveix per la majoria de configuracions i simplifica infinitament l’obtenció de propietats d’una finestra i a partir d’aquí generar les configuracions amb quatre clicks. Realment fa molt més agradable la tasca de configurar el devilspie que és per on coixeja més sota el meu punt de vista.

Scroll to Top