BandaAncha

  • 🔍 en 📰 artículos ⏎
  • 🔍 en 💬 foros ⏎
  • 🔍 en 👇 este 💬 foro ⏎
  • 🔍 en 👇 este 💬 tema ⏎
Regístrate Regístrate Identifícate Identifícate

HFC - en modo puente cortes con Newifi-D2 cortes cada 2 horas (Solucionado)

1
Jeronimo17
✎
1
⋮

Hola,

Hace poco cambié de Finetwork a Vadavo sobre todo por el tema del fijo que lo tenia en una virtual (Netelip), me cambiaron del Sagemcom F@st 3686 a Technicolor TC7230 y tengo un segundo router con OpenWrt así que pongo el router de la operadora en modo puente.

Me he dado cuenta que descargando de sitios a baja velocidad (keep2share.cc…) las descargas siempre se interrumpen haciendo un test simultaneo a 1.1.1.1 veo que tambien deja de responder en ese momento, he probado con otras versiones de OpenWrt y con otros routers y por último he puesto en un PC con Linux mint con conexion directa (teniendo el router de Vadavo en modo puente) y también sucede.

Estos días me di cuenta que si quito el modo puente del Technicolor TC7230 no sucede y la descarga de horas se completa perfectamente, así que he puesto la doble NAT con los 2 router y efectivamente no falla.

Por lo que he visto a un familiar que tiene Sagemcom F@st 3686 con Vadavo y yo con Technicolor TC7230 tienen el mismo fimware de Vodafone hasta el logo por fuera en el router, pero he visto que mi firmware por lo que leo esta antiguo STEB.80.50

De este router veo poca información sobre menus ocultos como el otro

¿Que prodria hace para evitar los microcortes en modo puente?

Gracias

Añado solución:

Al final después de muchas pruebas era todo mucho mas sencillo que todo lo que esta investigando sobre el protocolo DHCP.

El problema era mi dirección MAC D4:EE:07:61:AC:87 esta viene por defecto en todos los Newifi-D2 con OpenWrt, parece que por alguna razón no es capaz de saber su MAC verdadera (preguntaré en OpenWrt)

2050001891.webp
No tengo ninguna problema a parte de lo de la MAC con el router me parece bastante bueno por el precio 512MB de RAM, 4 hilos de CPU a 880MHz, 5 puertos LAN de 1 Gb/s, wifi de 2,4 y 5 GHz USB 3.0 NAT por HW y todo soportado por OpenWrt

Y parece que el servidor DHCP de Vodafone tiene múltiples solicitudes de IP con esta MAC y por eso deniega con NAK cuando se le solicita continuar con la IP.

He puesto la que trae en la etiqueta que nada tiene que ver y parece que ya no hay problema, me confundió que probé directamente con el PC y también con otro router, pero claro a ambos le puse esta misma MAC para no tener que reiniciar el router de Vodafone.

Solución 2:

Tampoco es problema de OpenWrt, es del vendedor o fabricante, en la memoria donde debe ir la MAC parece que en casi todos (si no todos) los aparato aparece D4:EE:07:61:AC:87 pero por suerte en la etiqueta física si está la MAC correcta y se puede añadir así:

El método de acceso es: cuando la energía está apagada, presione y mantenga presionado el RESET botón en la parte posterior del enrutador y conectar la energía. Si tiene éxito, verá que todos los LED parpadean 4 veces rápidamente. Visite http://192.168.1.1 para ingresar a la interfaz web de Breed.

forum.openwrt.org/t/same-mac-by-default-…-87/114298/6

Y se introduce la MAC de la etiqueta en LAN y se aumenta o disminuye uno el final en hexadecimal conforme a la foto aportada ahí

¿Alguien sabe por que es necesario reiniciar el router HFC si cambias de MAC?

Weikis
1
⋮

Pinta a más problema del firmware del tc7230

Jeronimo17
1
⋮

Les he escrito a Vadavo a ver que me responden

vukits
⋮

me cambiaron del Sagemcom F@st 3686 a Technicolor TC7230

ahora, compi, explicame por qué cambiaste de modelo de router cuando con el que tenías, te iba bien.

abre incidencia y pide que te pongan el modelo que te funcionaba bien

el coaxial ya no va tan bien como antes… si con un equipo te va bien, estate quieto,jeje

🗨️ 7
✖
Jeronimo17
1
⋮

Jeje se te ha pasado leer esto "cambié de Finetwork a Vadavo" donde vivo creo que seria de lo último en instalar Ono, todo se hizo subterraneo no hay cable por la falladas exteriores (se exigió asi en barriada en su momento) esta bastante nuevo dentro de lo que cabe

🗨️ 6
✖
vukits
⋮

llevas bastante por estos foros (antes que yo :P) como para saber de que el coaxial puede ser muy tiquismiquis ;)

(o tu router ha salido defectuoso, vaya)

🗨️ 5
✖
Jeronimo17
1
⋮

Aquí solo tengo o coaxial o fibra Movistar y bueno creo que también fibra del operador local; Llevo una descarga de más de 12 horas sin problemas, tiene que ser por fuerza el firmware del router cuando se pone en modo puente, yo tengo la versión STEB.80.50 y leo en foros gente que tienen la versión STEB.87.05

🗨️ 4
✖
vukits
vukits
1
⋮
🗨️ 1
✖
Skid Row
Skid Row
⋮
🗨️ 1
✖
pepejil
1
⋮

El Technicolor TC7230 es un router más viejo que el Sagemcom F@st 3686. Mira si es viejo que el TC7230 no tiene WPA2-PSK-AES (sólo funciona bajo TKIP), de hecho esta chorrada hace que esté empezando a ser incompatibles con ciertos dispositivos de Apple porque reflejan que la seguridad no es la adecuada.

El firmware siempre ha sido una castaña. En el caso del firmware para Vodafone Enabler se reiniciaba cada vez que estabas navegando por el configurador (hay muchos casos documentados en este foro), de hecho he notado que pasado un tiempo, el problema se agravaba. Motivo de por qué pedí cambio de router a Lowi.

Sinceramente que te cambiaran por un router peor me parece una chapuza por parte de Vadavo. Si este es el truco de su bajo precio, la verdad, me empezaría a replantear muchas cosas de cara a contratar con este operador.

🗨️ 1
✖
Jeronimo17
2
⋮

No he usado nunca el wifi del router.

No, yo no tenia Vadavo tenia FI y he devuelto su router, un familiar ha contratado como yo Vadavo y le ha tocado el otro, estos router NO son los de Vodafone Enabler, son los propios de Vodafone con mismo logo y firmware ya que incorporan la VoIP

Jeronimo17
⋮

He visto que en el protocolo DHCP justo a la mitad del tiempo es cuando se tiene que hacer una nueva solicitud

dhcp-lease-time.webp

Y cuando esto pasa, se recibe un NAK que significa "El servidor envía al cliente un mensaje indicando que el contrato ha terminado o que la dirección IP asignada no es válida."

dhcp.webp

No estoy seguro de si esto pasaba tambien con el otro router ¿El servidor DHCP está en el router o es externo? ¿Problema de firmware o externo al router?

Jeronimo17
⋮

Buscando por DHCP NAK, veo en un foro de Vodafone Alemania el mismo problema forum.vodafone.de/t5/Archiv-Internet-Tel…td-p/1004152 en 2014

Sobre el problema actual:

Tengo un router basado en Linux (TP-Link con OpenWrt) detrás del módem Hitron de KD que está configurado en modo puente.

Cada 90 minutos, todas las conexiones a Internet se desconectan por completo. Las investigaciones han demostrado que Kabel-Deutschland asigna la IP pública a través de DHCP con un tiempo de arrendamiento de 5400 segundos (90min).

Fri Jan 24 16:38:59 2014 daemon.notice netifd: WAN (2070): Se ha obtenido el alquiler de 24.134.249.xxx, tiempo de alquiler 5400

Antes de que expire este tiempo de arrendamiento, el cliente DHCP del router pregunta al servidor DHCP (de KD) si puede mantener la dirección IP pública actual (DHCP RENEW).

Aquí es donde surge el problema:

Fri Jan 24 17:24:00 2014 daemon.notice netifd: WAN (2070): Sending renew…

Fri Jan 24 17:24:00 2014 daemon.notice netifd: WAN (2070): Received DHCP NAK

Sin embargo, el servidor DHCP lo rechaza (DHCP NAK). Esto hace que el router apague la interfaz WAN, luego la reinicie y trate de obtener una dirección IP válida del servidor DHCP como lo hizo al principio después de encenderla.

Y aquí viene la ironía. Tras la desconexión forzada por el comportamiento descrito, en el 100% de los casos vuelvo a tener exactamente la misma dirección IP pública que tenía antes. Así que podría ahorrarse todas estas molestias.

Dos posibles soluciones:

a) Ampliar el tiempo de alquiler a 24 horas.

o lo que sería mucho mejor

b) Persuadir al servidor DHCP para que no acuse recibo de las solicitudes de renovación de DHCP del router del cliente con un NAK, sino que permita una extensión.

Parece algo generalizado aunque con otros tiempos allí.

No entiendo por que si no esta en modo puente no se nota ningún corte (supongo que el router hace de cliente DHCP). Si esto es como digo ¿Es posible con OpenWrt imitar al router en la petición DHCP para evitar el corte cada 2 horas?

Jeronimo17
✎
⋮
dhcpo.webp

No entiendo nada, parece que si dejo de usar udhcpc que viene por defecto en OpenWrt, configuro la interfaz WAN como no administrado e instalo el paquete isc-DHCP-client-IPv4 para poder usar dhclient e inicio en consola por ssh dhclient WAN -d no hay error en la renovación DHCP y no hay corte. ¿Problema de OpenWrt o Vodafone?

🗨️ 8
✖
apocalypse
1
⋮

Las mayores diferencias que observo son que dhclient envía en el option 55, el item 2 (Time Offset) y udhcpc no. Además este último también solicita servidores NTP (item 42), item 121 y envía el option 60 (vendor class). Probaría deshabilitando la obtencción de servidores NTP (en la configuración de la interfaz y en System → System → Time Synchronization: Use DHCP advertised servers).

Creo que la clave puede estar en el item 2 Time Offset, es el valor para informar de la hora local del cliente basado en UTC (+-). Creo que debe informar correctamente este valor para que el servidor sepa si la solicitud de renovación está dentro del plazo.

🗨️ 7
✖
Jeronimo17
⋮

Probaría deshabilitando la obtencción de servidores NTP (en la configuración de la interfaz y en System → System → Time Synchronization: Use DHCP advertised servers).

Eso no cambia la petición del udhcpc pues son las opciones que manda por defecto menos la 121, iba a dejar el dhclient para ver si efectivamente se mantenía la conexión pero como hoy me da otra IP y sin los scripts no me configura la ruta y por ahí no tengo tanto conocimiento como para hacerlo a mano todo.

Pero si he conseguido cambiar un scripts para que se le mande los parámetros

-o -O 1 -O 28 -O 2 -O 3 -O 15 -O 6 -O 12 en /lib/netifd/proto/dhcp.sh (-o para anular todo los por defecto)

Y a ver si varia el resultado…

🗨️ 6
✖
apocalypse
⋮

Eso no cambia la petición del udhcpc pues son las opciones que manda por defecto menos la 121

Hombre, sí que la cambia. Dhclient no solicita la opción 42 que es la de los servidores NTP.

udhcpc envía 121, 42 y 60.

dhclient envía la 2.

Esas son las diferencias. Para que udhcpc no envíe la 42 hay que deshabilitar la petición de servidores NTP por DHCP. Hazlo, ya tienes configurados por defecto los de OpenWrt y dudo que VF tenga servidores NTP advertidos en el DHCP.

Pero si he conseguido cambiar un scripts para que se le mande los parámetros -o -O 1 -O 28 -O 2 -O 3 -O 15 -O 6 -O 12 en /lib/netifd/proto/dhcp.sh

Comprueba con wireshark que esté funcionando bien. Con estas opciones debería imitar a dhclient y funcionar. Pero creo recordar que aún con esos parámetros sigue enviando el option 42. La única forma de que no lo envíe es desactivar lo que te dije.

🗨️ 5
✖
✖
apocalypse
apocalypse
⋮
🗨️ 3
✖
Jeronimo17
Jeronimo17 ✎
⋮
🗨️ 2
✖
apocalypse
apocalypse
⋮
🗨️ 1
✖
vukits
1
⋮

¡ostras! eso sí que es curioso… me trago mis palabras pues muchas gracias por enserñarnos la solución

jaja.

en su día, pasaba eso con DD-WRT … pero de eso hace ya muchos años…

¿Alguien sabe por que es necesario reiniciar el router HFC si cambias de MAC?

hombre, eso ha sido de toda la vida … no me preguntes por qué, no lo sé

🗨️ 1
✖
Jeronimo17
1
⋮

De nada, en su momento tuve DD-WRT con Linksys con Ono pero no recuerdo lo de la MAC