PPP: Connection broken

Hoy voy a contar una historia de terror informático, de esas que recuerdan el día en que a Enjuto Mojamuto se le fue Internet.

El Jueves 10, víspera de festivo en Barcelona, llegué a casa del trabajo… Internet no funcionaba (conexion de Fibra/FTTH -Movistar-). Por suerte con el Tethering de Android tenía un acceso alternativo desde el portatil mientras solventaba el problema (aunque andar cambiando de la LAN al 3G era bastante tedioso).

Como buen “friki” miré mi Uptime Robot; la conexión se había caido a las 12:20PM (media mañana). Ese día hubo tormenta, asi que temía que se me hubiera quemado el router, hubiera caido un arbol y roto las lineas, una excabadora, o vete a saber…

Primero hice las tipicas pruebas…
– La voz funcionaba (es Voz IP y va conectado directamente a la ONT), asi que la linea y en teoria, el ONT estaban bien.
– El ping a mi router, tanto WiFi, como cable, respondían bien.
– El ping a mi IP publica desde el 3G, no respondía. Aqui supuse que sería un problema de routing en Movistar.
– Hablé con vecinos, no tenían ningun problema, eso podría descartar el tema del Routing, a menos que en mi caso, que tengo IP estatica sea un Pool diferente con tablas de routing diferentes.
– El traceroute se quedaba despues del segundo salto (primero el router, luego el ONT y a partir de ahi, nada).
– En el router aparecia la IP publica correctamente asignada (asi que en teoria el servidor PPP no esta caido y los cables estaban bien).
– De nuevo pensé en un problema de Routing.
– Evidentemente reinicie el Router, la ONT. Varias veces… sin cambios.
– Llamé al 1004/1002, para abrir incidencia… Sorpresa, ningun humano. Solo una locución, me hizo preguntas básicas para acabar diciendome que tomaban nota de la avería.
– Pasan 4 horas, llamo al 1002, locucion, reitero avería… pasan 8h, lo mismo.
– Llevamos 24h, llamada automatica del 1002 diciendo que ya estaba resuelto… pruebo y NO; reitero avería. Vuelve a llamar la locución con el “funciona”, reitero.
– Voy llamando cada 4h u 8h reiterando la avería, sin respuesta “humana” por parte de Movistar.
– Dan las 10:00 del dia 12, casi 48h sin servicio, al final me llama un humano, casi no lo creo… aún quedan humanos! Hace un ping a la IP publica, reinicia la ONT remotamente, otro ping… y vaya, como no funciona, se rinde. La conversación más o menos sigue asi: (1002) Su router es antiguo, el firmware no es el ultimo, blabla, le mandaremos un tecnico (el lunes). (Yo) Seguro que no podemos solucionarlo sin que tenga que venir un tecnico? Desactivar la IP estatica temporalmente, revisar el servidor de acceso? no se, algo… (1002) Desde aqui no se puede hacer nada mas. (Yo) OK.
– Pasadas 48h me canso de estar sin Internet, y siguiendo la filosofía GNU/Linux: “Do It Yourself”, me decido a montar un Linux con PPPoE para reemplazar el “supuesto” router roto (si realmente es eso no me voy a pasar 2 días más sin conexión).

Arranco el PPPoE, pero sigue sin funcionar, asigna la IP, pero se comporta igual que el router de Movistar, así que es la hora de tcpdump, hay que ver el trafico entre la ONT y el “router”.

# tcpdump -pni eth0.6
12:22:25.693304 PPPoE  [ses 0x56d] IP 80.xx.yy.zz > 212.aa.bb.cc: ICMP echo request, id 30301, seq 36, length 64
12:22:25.697409 PPPoE  [ses 0x1d3d] IP 212.aa.bb.cc > 80.xx.yy.zz: ICMP echo reply, id 30301, seq 36, length 64
12:22:26.701302 PPPoE  [ses 0x56d] IP 80.xx.yy.zz > 212.aa.bb.cc: ICMP echo request, id 30301, seq 37, length 64
12:22:26.705865 PPPoE  [ses 0x1d3d] IP 212.aa.bb.cc > 80.xx.yy.zz: ICMP echo reply, id 30301, seq 37, length 64
12:22:27.709282 PPPoE  [ses 0x56d] IP 80.xx.yy.zz > 212.aa.bb.cc: ICMP echo request, id 30301, seq 38, length 64
12:22:27.713471 PPPoE  [ses 0x1d3d] IP 212.aa.bb.cc > 80.xx.yy.zz: ICMP echo reply, id 30301, seq 38, length 64

Vaya, parece que no es un problema de routing, el tráfico sale, el tráfico entra… Pero el ping no ve las respuestas al ping?!?

# tcpdump -ptuneli ppp0
Out ethertype IPv4 (0x0800), length 100: 80.xx.yy.zz > 212.aa.bb.cc: ICMP echo request, id 30072, seq 11, length 64
Out ethertype IPv4 (0x0800), length 100: 80.xx.yy.zz > 212.aa.bb.cc: ICMP echo request, id 30072, seq 12, length 64
Out ethertype IPv4 (0x0800), length 100: 80.xx.yy.zz > 212.aa.bb.cc: ICMP echo request, id 30072, seq 13, length 64

Los paquetes salen, pero no vuelven en el PPP? Al principio no reparé en esos “ses 0x1d3d”, pense en un problema de CRC o similar… pero aún habiendo apagado el PPPoE seguía entrando tráfico PPP:

# tcpdump -pnei eth0.6
13:24:38.561206 4c:xx:xx:xx:xx:4a > 38:xx:xx:xx:xx:76, ethertype PPPoE S (0x8864), length 148: PPPoE  [ses 0x1d3d] IP (0x0021), length 128: 109.a.b.c.12486 > 80.xx.yy.zz.68xx: UDP, length 98
13:24:43.711453 4c:xx:xx:xx:xx:4a > 38:xx:xx:xx:xx:76, ethertype PPPoE S (0x8864), length 151: PPPoE  [ses 0x1d3d] IP (0x0021), length 131: 114.a.b.c.26300 > 80.xx.yy.zz.68xx: UDP, length 101
13:24:45.390778 4c:xx:xx:xx:xx:4a > 38:xx:xx:xx:xx:76, ethertype PPPoE S (0x8864), length 151: PPPoE  [ses 0x1d3d] IP (0x0021), length 131: 218.a.b.c.16001 > 80.xx.yy.zz.68xx: UDP, length 101
13:24:46.190387 4c:xx:xx:xx:xx:4a > 38:xx:xx:xx:xx:76, ethertype PPPoE S (0x8864), length 151: PPPoE  [ses 0x1d3d] IP (0x0021), length 131: 218.a.b.c.16001 > 80.xx.yy.zz.68xx: UDP, length 101
13:24:52.422005 4c:xx:xx:xx:xx:4a > 38:xx:xx:xx:xx:76, ethertype PPPoE S (0x8864), length 156: PPPoE  [ses 0x1d3d] IP (0x0021), length 136: 2.a.b.c.26085 > 80.xx.yy.zz.68xx: UDP, length 106
13:25:03.069791 4c:xx:xx:xx:xx:4a > 38:xx:xx:xx:xx:76, ethertype PPPoE S (0x8864), length 147: PPPoE  [ses 0x1d3d] IP (0x0021), length 127: 94.a.b.c.65500 > 80.xx.yy.zz.68xx: UDP, length 97
13:25:07.995349 4c:xx:xx:xx:xx:4a > 38:xx:xx:xx:xx:76, ethertype PPPoE S (0x8864), length 151: PPPoE  [ses 0x1d3d] IP (0x0021), length 131: 218.a.b.c.16001 > 80.xx.yy.zz.68xx: UDP, length 101

Ahí empecé a sospechar de esa sesión 0x1d3d. Busqué en Internet “pppoe kill session” y encontré este salvavidas: PPPoE Session Killer [GitHub]

Eso si, tuve que cambiar la MAC address de la eth0 para que coincidiera con la vieja MAC address del router de Movistar (tb modifique el código para que mandara una segunda trama con src <-> dst intercambiados -por si acaso-).

# ip link set dev eth0 address 38:xx:xx:xx:xx:76
# ./pppoesk -i eth0.6
Using ethernet interface : eth0.6
Waiting for packet...
PPPoE session ID: 3d1d
Ethernet interface MAC: 4c:xx:xx:xx:xx:4a
Access Concentrator MAC: 38:xx:xx:xx:xx:76
Packet sent !

Y solucionado! Aún recuerdo hace algunos años cuando usaba ADSL que cuando habia un problema, antes de enviarte un técnico, el paso 1 era reiniciar el concentrado ADSL para eliminar las sesiones PPP “colgadas”, será que con el FTTH eso ya no existe? o es que en fin de semana en el 1002 nadie sabe de esa opción?

Esta es la configuración que use para el PPPoE (Ubuntu 14.04)

# /etc/network/interfaces
auto eth0.6
iface eth0.6 inet manual
# pppoeconf eth0.6
# /etc/ppp/peers/[profile]
noipdefault
defaultroute
replacedefaultroute
hide-password
noauth
persist
noendpoint
plugin rp-pppoe.so eth0.6
user "adslppp@telefonicanetpa"
# password: adslppp
# pon [profile]
# poff [profile]

Referencias:
Configuracion PPPoE en Debian
Suprimiendo el router de Movistar FTTH
Router Cisco con Movistar FTTH

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: