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.
[display_podcast]
Reading time: 6 – 10 minutes
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:
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.
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.
Se han hecho infinidad de pruebas y de combinaciones:
5 servidores distintos:
el comportamiento es el mismo con todas la combinaciones
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.
Los ficheros de los que se habla en este correo de pueden descargar de:
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.
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.
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:
[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.
Reading time: 4 – 6 minutes
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:
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:
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
Reading time: 1 – 2 minutes
Fins ara per poder seguir un protocol dins del enllaç TCP, o sigui els missatges de la capa 5, sempre acabava capturant-lo amb el wireshark o en el seu defecte amb el tcpdump generava un fitxer .cap que després obria al wireshark i a través d’una funció tan simple com el Follow TCP stream em montava la sessió de capa d’aplciació que podia seguir de forma ben còmode. El gran descobriment que vaig fer l’altre dia és el tcpflow una eina la mar de simple i lleugera que com no podia ser d’altre forma usa les llibreries libpcap, le mateixes que el tcpdump i el wireshark per mostrar-nos de forma completament visual i simple a través de la consola o contra un fitxer el contingut de la sessió TCP. Espero que li tregueu tan profit com jo a l’eina.
Reading time: 6 – 9 minutes
Aquest inici de setmana l’he passat moltes i moltes hores llegint documentació del Postfix per tal de solucionar un problema a un client que tenia una cua de correu inmensa i que no hi havia manera de servir perquè el servidor no donava coll. Doncs bé, degut a això m’he hagut de llegir molts documents i volia referenciar-los per no perdre’ls de vista ja que molts d’ells són interessentíssims. Realment cada dia que passa estic més convensut que Postfix és la millor opció com a MTA, diria que he passat moltes hores i molts anys provant sendmail, exim i qmail. Però l’experiència sempre m’ha dit que Postfix era el que em solucionava les problemàtiques més inversemblants i així ha estat aquest cop també.
Volia comentar de forma explícita una de les solucions ineressants que es presenta al primer document, el que parla sobre qshape. La idea és que a través d’aquesta utilitat podem trobar un domini sobrel el que s’hi encuen molts correus i per tant la cua de sortida de correus es veu perjudicada perquè aquest destí monopolitza gran part de la cua. Doncs bé, es tracta de construir una cua de sortida de correu només per aquest destí i fer que els correus que vagin cap allà es processin a part.
Per montar això cal:
/etc/postfix/master.cf: # service type private unpriv chroot wakeup maxproc command fragile unix - - n - 20 smtp
/etc/postfix/main.cf: transport_maps = hash:/etc/postfix/transport fragile_destination_concurrency_failed_cohort_limit = 100 fragile_destination_concurrency_limit = 20
/etc/postfix/transport:
example.com fragile:
Espero que si no coneixieu postfix aquest petit post hagi servit per veure fins a quin punt és simple i dinàmic de configurar, no pretenia fer cap introducció només una pura referència de documentació que crec que a partir d’ara intentaré tenir aprop.
Reading time: 3 – 4 minutes
A través d’un howto de howtoforge he descobert aquesta eina anomenada Pound. Realment m’ha deixat impressionat per la seva simplicitat i potència al mateix temps. A més m’ha donat molt confiança saber que hi ha almenys un site processant 30M de peticions al dia, unes 600 per segon amb aquest aplicatiu. Aquest tipus de números sempre ajuden a donar confiança en les eines.
Doncs bé, l’eina bàsicament es dedica a capturar totes les peticions HTTP i HTTPs repartint-les després contra els servidors que té en el backend. En cap moment fa de caché ni res similar. Tot i que cal destacar la capacitat de poder fer de SSL wrapper. Així doncs, no cal que els backend facin de servidors SSL, només de servidor HTTP. Obviament pel client s’establirà una connexió HTTPs completament transparent. Si la validació SSL no és correcte Pound ja no envia peticions als servidors que té darrera.
Les funcions de balancejador de càrrega (load balancer) permeten no perdre les sessions establertes pels navegadors dels clients contra els servidor de backend, de fet, Pound implementa sis formes diferents de capturar una sessió per tal de no enviar peticions a un dels backends que no conegui la sessió del navegador.
Suporta funcions de fail-over, així doncs totes les peticions es direccionen només als servidors de backend que se sap que funcionen, la validació que es fa per saber si un servidor esta actiu o no és força simple i a grans trets es basa en paquets ICMP.
Finalment també cal destacar una funcionalitat que m’ha cridat molt l’atenció, ja que permet fer de wrapper d’URL i enviar les peticions que acompleixin certes expressions regulars cap a un o altre servdidor. Això permet, per exemple, enviar els dominis virtuals cap a un o altre servidor. A més, també podem per exemple, enviar les peticions d’imatges cap certs servidors de backend específics.
Al llegir-me la documentació d’aquesta eina el que més m’ha intrigat és saber com resolien el típic problema que presenten les eines d’aquest tipus, els fitxers de logs. M’explico, una cosa molt important a poder controlar des del punt de vista d’un servidor web és saber d’on arriben les peticions si el servidor web no rep les peticions directes d’internet sinó a través d’un balancejador com Pound la IP origen de la petició es perd i per tant, els fitxers de logs dels servidors web no són reals sinó que tenen com a origen sempre el balencejador. A més de totes els problemes associats a no saber d’on venen les peticions, com el control d’accés i d’altres similars.
Doncs bé, bàsicament això es soluciona a través d’una capçalera HTTP afegida des de Pound a la petició web. Així doncs és en aquesta capçalera que s’han d’anar a buscar les dades necessaries per recomposar el fitxer de logs del servidor web. També hi ha mod’s d’apache que ja solucionen aquest tema directament capturant aquesta nova entrada en la capçalera HTTP, concretametn val la pena que no perdeu de vista mod_extract_forwarded2.
Sota el meu punt de vista un gran descobrint i una eina molt interessant per tal de poder montar servidors web’s amb més cara i ulls. No sé si algú l’haura provat 😉
Reading time: 2 – 3 minutes
A primer com de vista i pel que puc veure en la demo, ja que no l’he usat mai encara, m’agrada molt el que preten fer el Rack Tables. Bàsicament la idea és mantenir un inventari de què hi tenim montat a cada un dels armaris rack que tenim destribuits per tot el món. Això quan tens un garbuix al cap del que té cada client com em passa a mi sovint pot ser molt útil. Sobretot perquè s’hi poden adjuntar fotografies o portar un control exahustiu de les U’s que hi tenim lliures, dels ports de switch ocupats, etc. Per tant, diria que és una eina molt recomanable per administradors de sistemes. Fins hi tot diria que imprescindible per admins d’empreses de serveis que no tenen contacte diari amb els datacenters dels clients.
També permet portar un registre dels espais d’IPv4 en això s’assembla una mia al IPplan malgrat les funcions d’aquest aplicatiu són molt més simples i es redueixen a funcions purament d’inventari. Al estar orientat a servidors ens permet mantenir un registre dels serveis virtuals que tenim corrent, pools de màquines i fins hi tot algunes funcions de monitorització a nivell de gràfiques sobretot. Per cert, m’agradaria descatar que potm ostrar l’estat dels balancejadors de carrega web, per exemple.
És important recordar que és una eina d’inventari, en això vull dir que el que aquí interessa no és pas veure com les coses canvien en temps real. Sinó poder mantenir un registre de com tenim o volem tenir montada l’infraestructura. És a dir quelcom més proper a una ajuda per mantenir la documentació que no pas una eina de supervisió. Per això ja tenim nagios, no?
No ho havia comentat però l’aplicació funciona via web i malgrat no m’hi he fixat massa diria que és la típica aplicació feta amb PHP i MySQL. Potser per ser una aplicació web la trobo una mica massa anticuada tan en el disseny com en la poca introducció de funcionalitats AJAX que la facin més usable i atractiva a l’usuari.
Reading time: 1 – 2 minutes
Aquesta setmana arran d’un article de bandaancha he descobert el P4P. La idea té molt bona pinta, a més és una solució en la que sembla que tots hi sortirem guanyant els usuaris de P2P i els operadors. Es tracta de que quan fem una connexió P2P el ISP intentarà que el tràfic dels nostres peers vingui de dintre de la mateixa xarxa. Així doncs, l’operador no ha d’enviar tràfic cap a d’altres operadors sinó que tot queda a casa. A més als usuaris ens beneficiem perquè ens arribarà més ràpid.
Doncs pel que he pogut investigar el tema esta encara molt verd. Ja que no he trobat cap prova de concepte i tampoc cap snippet ni res de res. Així doncs encara estic amb les ganes de veure alguna cosa decent. Tot i que resulta que hi ha operadors com Telefonica que estan fent proves, estaria bé que expliquessin com. Perquè molt presentar resultats però res més.
Si algú sap algo del tema que avisi…
