Get Firefox!

El discreto diario de Laz

Usando Linux a diario, sin muchos alardes
Kernel desarrollo: 4.4-rc1 4.3
Kernel estable:
Sacado de CollegeHumor

Sobre escritorios remotos. Alternativas a TeamViewer


Entrada 206 escrita por laz, el miércoles, 08 de mayo de 2019

Privacidad a tutiplén

Consejos, software y formación/información sobre privacidad "personal":
-- privacytools

Entrada 205 escrita por laz, el sábado, 28 de enero de 2017

Afinando el PPP para la FTTH


Ultimamente venía observando una merma apreciable de la velocidad de bajada de los supuestos 300Mbit/s de la conexión FTTH.
Tras muchas pruebas, llegué a la conclusión que no pasaba de unos 18MB/s (lo que, redondeando, serían unos 150-160Mbit/s).
Estas prueba consistián en transferencias FTP de servidores conocidos por su velocidad, y sobre todo, la comparación con otras conexiones FTTH a las que tengo acceso, concretamente, a otras tres conexiones. Todas ellas cumplian el objetivo: rondaban unos excelentes 34MB/s de velocidad de bajada.
¿Cuál es la diferencia? Sólo en mi conexión he sustituido el router del proveedor, por el servidor con PPP/PPPoE/VLAN. Así que empecé a buscar problemas en el servidor:
  • Actualicé todo lo que pude el soft de Debian/Linux
  • Sustituí la tarjeta de red. Gigabit ethernet, por supuesto
  • Amplié CPU y RAM
Pero nada parecía dar resultado, así que empecé asospechar de la conexión.
Conecté un router FTTH (el Amper EG-663), aislé el servidor y probé con un portátil Windows (triste, pero cierto y necesario, para poder certificar, en caso de abrir avería, los síntomas) y pasé la prueba de Movistar. Resultado: ¡¡¡34MB/s!!!
Así que es cosa del servidor, con total certeza.
Configuro el servidor en "multipuesto" y hago que navegue toda la red a través de él. Con el doble NAT (en servidor y en router) el resultado es idéntico: ¡¡¡34MB/s!!!
Acotando el problema, me queda sólamente el software del servidor que se ocupa de la conexión, es decir, PPP/PPPoE/VLAN. Buscando información de algún problema similar por Duckduckgo y demás buscadores, no encuentro nada parecido a mi caso, y casi me doy por vencido y me planteaba reinstalar un nuevo Linux (Debian unstable 64bits, sería lo elegido para tener el último y más arriesgado software), cuando se me ocurrió "mirar" cómo hacía las cosas el Amper EG-663.
Con mucha suerte, este router corre un Linux y se puede acceder a él muy fácilmente vía telnet (tras pasar por el Portal Alejandra y desbloquear la clave para acceder y demás). Así que fusilé las opciones de conexión del PPP/PPPoE y ahora está funcionando al 100% de la capacidad.
Creo que el problema está en la "antigua" manera (de cuando se hacía en los ADSL de baja velocidad) de conectar el PPPoE, Para ello Debian tiene un paquete específico, pero el paquete de PPP ya incluye un módulo opcional (rp-pppoe.so), que creo que es más moderno y eficaz.
El fichero /etc/ppp/peers/ftth ha quedado así:
user "adslppp@telefonicanetpa"
password "adslppp"
plugin rp-pppoe.so eth1.6
lcp-echo-interval 30
lcp-echo-failure 4
mtu 1492
mru 1492
unit 0
persist 
hide-password
nobsdcomp 
nodeflate 
nopcomp 
novj 
novjccomp 
noipdefault 
noaccomp -am 
noauth
holdoff 10
maxfail 0
+ipv6
noipx
defaultroute

Es prácticamente idéntico (salvo dos cosillas) al fichero que existe en el router Amper. Y la prueba a pasar para probar la transferencia es la siguiente:
Server:/tmp# wget http://mirrors.evowise.com/linuxmint//stable/18/linuxmint-18-cinnamon-64bit.iso
--2016-10-09 --  http://mirrors.evowise.com/linuxmint//stable/18/linuxmint-18-cinnamon-64bit.iso
Resolviendo mirrors.evowise.com (mirrors.evowise.com)... 2a05:84c7::1005, 89.45.92.5
Conectando con mirrors.evowise.com (mirrors.evowise.com)[89.45.92.5]:80... conectado.
Petición HTTP enviada, esperando respuesta... 200 OK
Longitud: 1697906688 (1,6G) [application/octet-stream]
Grabando a: “linuxmint-18-cinnamon-64bit.iso”

linuxmint-18-cinnam  15%[==>                   ] 256,32M  36,4MB/s   eta 39s



Entrada 204 escrita por laz, el domingo, 09 de octubre de 2016

Actualizado a Debian Jessie


Tras varios intentos y pruebas, se ha actualizado el servidor a Debian Jessie (8.2).
La distribución antigua, un híbrido entre Debian 7, librerías parcheadas y programas recompilados para que funcionaran, ya era casi insostenible y de muy difícil mantenimiento o actualización.

¿Los mayores problemas?:
  • Pasar de Apache 2.0/2.2 a 2.4. Cambian un montón de cosas en las configuraciones y el PHP nuevo.
  • Mailman y Postfix. Muchas cosas raras han pasado con las configuraciones antiguas, y alguna sigue pasando (imposibilidad de autentificarse con AuthSMTP y TLS. Estoy trabajando en ello.
  • Recodificación del ISO8859 a UTF-8, por ejemplo en consolas de comandos, o en MySQL.
  • Cambio de Squid2.4 a Squid3, y la combinación con Privoxy+TOR, claro.

De momento, parece ir todo bien, como la seda. Se nota la mejora de rendimiento con PPPoE sobre la FTTH, y el sistema se nota mucho más fluído y estable. A ver lo que dura así.


Entrada 203 escrita por laz, el jueves, 17 de diciembre de 2015

Cambio a FTTH

La enorme complicación de poner en monopuesto una FTTH:

Conectar una de nuestras ethernets (en este caso eth0) a la ONT, boca rotulada "eth1".

VLAN 6: vconfig add eth0 6

PPPoE sobre la eth0.6 y activar el pppd

y vooilá!

Si hay televisión de por medio, otra VLAN, la 3, es la encargada de llevar dicho servicio, pero no con PPPoE sino con una IP fija que tenemos que conocer previamente.
Podemos verla en el gigantesco router que nos suministran, por ejemplo.

Pero esto ya no lo tengo controlado. Intentaré probarlo en alguna línea provista de televisión.

Entrada 202 escrita por laz, el sábado, 09 de mayo de 2015

Cambiando a multipuesto


Hoy he tenido obra. He cambiado el "anciano" router CISCO 1801M ADSL por un modernillo Homestation Amper con su menú oculto y todo.
Y lo he configurado en multipuesto, ya que últimamente ente tanto heartbleed (circustancial, porque poco o nada tiene que ver con el router adsl) y tanto ataque DDOS al ntp y similares preferiría que el tráfico UDP generado se lo "coma" el router y no el servidor. Así que lo tengo en pruebas en multipuesto.

Los motivos para cambiarme han sido, básicamente, estos:
  • Modernizar el hardware del ATU-R ADSL2+. Del CISCO 1801-M ya no encontraba actualizaciones IOS o firmware DSL. Y los equipos de central están constantemente evolucionando y mejorando.
  • Pasar toda la red local a gigabit. El CISCO trae un switch de 8 puertos ethernet a 100Mbps, que era muy útil en su tiempo. Hoy ya hay que pasarse a gigabit, por precio y prestaciones.
  • Tamaño, consumo y sobre todo, RUIDO. El ventilador del CISCO, cuando llega el verano, es un poco molesto.

A cambio me "como" un NAT que no controlo, pero bueno.
Espero que resulte. Aún en pruebas.

Entrada 201 escrita por laz, el sábado, 12 de abril de 2014

El HeartBleed explicado :-)


Entrada 200 escrita por laz, el viernes, 11 de abril de 2014

CutreDebugging: Usando strace para cosas útiles.


Hace poco reinstalé una Debian en el ordenata potente, arriesgando y poniendo una testing (codename jessie a la fecha de hoy), con los problema que ello me iba a crear (uso cosas bastante sensibles a los cambios de kernel, mucho más frecuentes en versiones no estables, como VirtualBox, VMPlayer, los drivers de Nvidia y alguna otra cosa que no me acuerdo.
Poco a poco he ido salvando los problemas (me he pasado a nouveau, por ejemplo), pero hoy me he puesto a ver la tele con Xine, ya que Kaffeine es mi aplicación de TV normal, pero no tenía sintonizados los canales de ETB para ver el partido de basket entre bilbaínos y vitorianos.
Tengo una lista de canales (channels.conf) actualizada con el comando w_scan, y la puse en los sitios habituales: /etc/channels.conf y el más moderno ~/.xine/channels.conf.
Ni con uno ni con otro ni con ambos; Xine insiste en que no encuentra el fichero channels.conf. Tras leer alguna documentación, no llego a ninguna conclusión rápida y me decido por desempolvar (ni lo tenía instalado) el viejo strace, que como dice su página de manual:
strace - trace system calls and signals
o la descripción del paquete Debian:
Description-es: Un rastreador de llamadas al sistema
strace es un rastreador de llamadas al sistema, es decir, una herramienta
de detección de errores que muestra un historial de todas las llamadas al
sistema realizadas por otro proceso/programa. No hay que recompilar el
programa a rastrear, así que puede usarse en binarios cuyo código
fuente no está disponible.
.
Las llamadas y señales del sistema son eventos que suceden en la
interfaz usuario/núcleo. Un examen más minucioso de este límite es
muy útil para aislar fallos, realizar comprobaciones de integridad e intentar capturar condiciones de carrera.

Resumiendo, es un rastreador de lo que hace (llamadas del sistema, archivos que se abren, cierrar, leen y escriben, etc) un programa. En este caso, lo uso de la siguiente manera, para que nos guarde, en modo texto, lo que hace el ejecutable Xine, y con el parámetro "-f" para que siga las llamadas externas. Todo ello desde una consola en entorno X con la variable DISPLAY correctamente establecida, si hiciera falta:

strace -f -o /tmp/Salida.txt xine

Una vez hecho esto hacemos una búsqueda simple:

grep channels.conf /tmp/Salida.txt
18556 open("/home/usuario/.config/xine-lib/channels.conf", O_RDONLY) = -1 ENOENT (No such file or directory)
18556 open("Sorry, No valid channels.conf found", O_RDONLY|O_CLOEXEC


Y ahí está lo que busca el ejecutable: quiere que el fichero esté en el dammed "/root/.config/xine-lib/".
Solucionado
.


Entrada 199 escrita por laz, el domingo, 22 de diciembre de 2013

Tema friki: Software Defined Radio y el RTL2832U


Leyendo esto de aquí, me he enterado que existe la posibilidad de usar un sintonizador TDT basado en el chipset Realtek 2832U como sintonizador (o receptor) de radio de cualquier banda, incluyendo bandas de radioaficionados, móviles, etc, etc.
El tema es recompilar un código muy sencillo en Linux (o buscarse la vida con drivers especiales en Windows), para activar el modo "oculto" del chip de Realtek. Puede funcionar incluso por red local, y en teoría, por Internet, esto es , el sintonizador con el soporte adecuado estaría en un servidor, y los clientes (receptores de radio como por ejemplo el sdrsharp se conectaría vía TCP/IP.
El inconveniente -ya que lo he probado- es que el ancho de banda de subida del servidor cuando le pedimos que sintonice una frecuencia y nos envíe datos, ronda los 30 mbit/s. Salvo que dispongamos que una conexión de banda ancha moderna, tanto en el cliente (RX) como en el servidor (TX), ¡no va a funcionar muy bien! :-)

Algunos enlaces:
  • Wikipedia en inglés
  • WIki SDR RTL.org

  • Entrada 198 escrita por laz, el sábado, 23 de marzo de 2013

    Hay mucho friki de Star Wars, me temo.


    traceroute 216.81.59.173
    
    más extendido incluso (para Win, mirar el manual :-)
    traceroute -q 2 -m 60 216.81.59.173
    
    
    Y también:
    telnet towel.blinkenlights.nl
    


    Entrada 197 escrita por laz, el domingo, 24 de febrero de 2013

      Página siguiente

    Enlaces

    Calendario

    mayo 2023
    LMXJVSD
    1234567
    891011121314
    15161718192021
    22232425262728
    293031
    <<<>>>


    Acerca de Mlog