Estoy recibiendo un E1 vía SIP Trunk por lo que la manera de monitorear el servicio no es la convencional, y por convencional me refiero a la que estoy acostumbrado y que está más ampliamente desplegada por los proveedores de telefonía en el país, recibir con un hardware E1 como una tarjeta PCI u otra.

Para vigilar el servicio al recibir de un convertidor de medios E1 hacia mi tarjeta E1 en Asterisk, uso el plugin de nagios check_e1t1 el cual monitorea el estado de sincronía de un puerto en específico usando el comando “dahdi show status” el cual a su vez depende de el archivo /dev/dahdi/ctl.

En el caso del troncal SIP no hay puerto físico que verificar por lo cual uso Nagisk, este plugin escrito en perl permite monitorear “peers” de Asterisk entre otras cosas.

La sintaxis correcta para monitorear una troncal en específico es:

/usr/local/nagios/lib/nagisk.pl -p NombreDeTroncal -c peer

La sintaxis que nos arroja la ayuda del comando no me quedaba muy clara:

Syntax: /usr/local/nagios/lib/nagisk.pl [-hv] [-c OPT] [-s NB|-p NAME|-b BUDDY] [-w TRESH -x TRESH]

Yendo al tema de cual de las dos tecnologías es mejor para recibir el servicio, soy nuevo en el tema de SIP Trunk, pero prefiero optar por él debido a que no hay hardware E1 de por medio actuando como SPOF (punto único de fallas).

Este es un gran dolor de cabeza para SysAdmins de PBX Asterisk o Elastix cuando se toman en cuenta costos de tarjetas E1, módulos de cancelación de eco, u otros y tiempo de importación en un país en el que ningún proveedor local mantiene este tipo de piezas en existencia o si quiera mantienen relaciones directas de socio comercial con fabricantes.

A partir de la versión 197 de udev se ha habilitado una función para una nueva nomenclatura en el nombre de las interfaces de red dejando de usar nombres tradicionales tales como eth0, wlan0, etc. Probablemente ya se han topado con los wls1, ens5, enp2s0 y otras aberraciones. Este cambio viene a meter más polémica y oposición a la adopción de Systemd ya que muchos programas usan por defecto la interfaz eth0, dando por hecho que esta existe, una mala práctica que muchos desarrolladores usaron como por ejemplo arping

La razón para realizar este cambio se debe, según argumentan en la documentación de systemd, a que el orden en que se asignan nombres a las interfaces de red por parte del kernel de sistema operativo va de acuerdo al orden en que se realiza sondeo de controladores de las interfaces y que en las tecnologías mas recientes este orden ya no es predecible. Esto ocasiona que en el siguiente arranque del sistema operativo el nombre de las interfaces se cambie o invierta. Read More

De un día para otro un E1 fraccionado de voz que me entrega un proveedor local empezó a producir un zumbido que únicamente era escuchado internamente, el zumbido o interferencia venía acompañado de mensajes de error y caídas de llamadas al abrirse el canal con la PSTN.

No se tenían alarmas de sincronía u otro indicio de que el medio físico estuviese fallando además de que el E1 se recibe por fibra óptica por lo que se descartaba que la interferencia fuese inducida por alguna línea eléctrica.

Los principales mensajes de error eran:

  • PRI got event: HDLC Abort (6) on D-channel of span 1
  • HDLC Bad FCS (8) on D-channel of span 1

Después de muchas horas y pruebas con otras tarjetas E1 y otros servidores volví a llamar a mi proveedor con la certeza de que algo había cambiado de su lado.

Resulta que habían deshabilitado el CRC de la señal del E1 y de mi lado seguía habilitado.

Procedieron a habilitarlo nuevamente y se limpiaron los errores.

También hubiese sido suficiente con deshabilitarlo en mi archivo /etc/dahdi/system.conf y reiniciar el dahdi:

# Autogenerated by /usr/sbin/dahdi_genconf on Sun Mar 29 00:47:35 2015
# If you edit this file and execute /usr/sbin/dahdi_genconf again,
# your manual changes will be LOST.
# Dahdi Configuration File
#
# This file is parsed by the Dahdi Configurator, dahdi_cfg
#
# Span 1: D130/0/1 “D130 (E1|T1) Card 0 Span 1” (MASTER) HDB3/CCS/CRC4
span=1,1,0,ccs,hdb3,crc4
# termtype: te
bchan=1-10
dchan=16
echocanceller=mg2,1-10

# Global data

loadzone = us
defaultzone = us

Fue así:

Tenía una máquina virtual que cada vez que arrancaba cambiaba la hora. En los logs no había información que indicara de donde provenía el cambio de hora así que revisé la configuración regional, la hora del BIOS de la máquina virtual, servidores NTP configurados y no nada con la respuesta.

Lo que ignoraba es que una vez que se instalan las vmware tools estas traen una opción para sincronizar la hora entre el guest host (máquiva virtual) y el anfitrión (bare metal donde corre el hipervisor).

En este caso el anfitrión es un esxi 5.5 y con el vsphere se cambia la configuración en NTP Servers: “Configuration” ->”Time Configuration” y acá podés ajustar la hora o detener el NTP.

date and time conf -2

Después de estar suspendida mi portátil acelera los ventiladores causando bastante ruido.

Luego de un tiempo ha empezado a interferir con el correcto funcionamiento de la tarjeta de red inalámbrica y el teclado.

Me encontré con una solución temporal para después de cada suspensión en los foros de arch linux:

for i in {1..15}; do echo 0 > /sys/class/thermal/cooling_device$i/cur_state; done

El amigo de un amigo actualizó su versión de bash para superar la vulnerabilidad conocida como shellshock en openSUSE 12.3:

zypper update bash

Luego de la actualización empezó a obtener mensajes de error:

Target initialization failed:
rpmdb2solv -r ‘/’ -p ‘/etc/products.d’  > ‘/var/cache/zypp/solv/@System/solvBx3cgH’
/bin/sh: /lib/libc.so.6: version `GLIBC_2.15′ not found (required by /bin/sh)

Puedo intuir que la versión de bash no encontraba compatibilidad con la versión de Libc instalada. No suena lógico que teniendo una dependencia esta no se actualice durante el zypper up. Pero bueno, yendo al grano.

Estaba en una situación en la que no podía actualizar el resto de paquetes porque estos usaban bash y bash no estaba ejecutandose correctamente por la incompabilidad. zypper, yast, export, setenv no podían ser ejecutados.

La solución fue descargar glibc-2.15-22.9.1.i686.rpm e instalarlo usando –replacefiles para que omitiera conflictos y reemplazara los paquetes por los nuevos:

rpm -ivh –replacefiles glibc-2.15-22.9.1.i686.rpm