Seguridad Wireless - Wifi
Equipos y materiales => Puntos de acceso, routers, switchs y bridges => Openwrt & LEDE => Mensaje iniciado por: jordipalet en 26-08-2015, 11:35 (Miércoles)
-
Desde que me han puesto la fibra he tenido varios problemas con los routers y pense que pasando a OpenWRT se me resolveria ... Sin embargo, he detectado que desde algunas partes de la red de Movistar (no se si desde otros puntos del planeta ...) no se accedia por HTTP a mi red.
Dandole vueltas y hablando con gente de Movistar, aseguran que no hay ningun filtrado y que puede ser un problema de negociacion de MTU de los routers del cliente, quizas combinado con que sistema operativo se use, pues al parecer algunos lo resuelven ... a parecer creen que puedan ser los Mitrastar que tengan un fallo en el firmware, por lo que en cuando se intenta acceder a una web que tiene objetos mayores que la MTU se queda ahi, en blanco o cargando a medias, y al final da timeout, etc.
La unica forma de comprobarlo es si los que estais en en este hilo podeis hacer esta prueba.
1) Desde vuestra red, conectaros a http://www.catgenie.es (asi probamos el puerto 80)
2) Conectaros a https://store.catgenie.es (asi probamos el puerto 443)
3) Tanto si os sale la pagina como si no, indicar por aqui:
- Modelo de router
- Sistema Operativo
- Resultado para 1)
- Resultado para 2)
Si os falla, seguramente tendreis el mismo problema con muchas otras paginas web, depende de muchas circunstancias, pero en ningun caso es un fallo de la web, sino del firmware del router, que no negocia la MTU (tamaño maximo de los transmisiones).
Si se confirma el fallo, tendre que mirar la forma de reducir a 1480 u otro valor inferior, quizas haya que probar, la MTU del PPPoE en mi OpenWRT, aun no he mirado como hacerlo pero no creo que sea problematico.
-
flo basico va bien,(yo no tengo ipv6 por eso falla)
ping -4 www.catgenie.es
PING www.catgenie.es (217.126.185.215): 56 data bytes
64 bytes from 217.126.185.215: seq=0 ttl=116 time=62.884 ms
64 bytes from 217.126.185.215: seq=2 ttl=116 time=82.901 ms
64 bytes from 217.126.185.215: seq=4 ttl=116 time=116.382 ms
64 bytes from 217.126.185.215: seq=5 ttl=116 time=138.075 ms
ping -6 www.catgenie.es
PING www.catgenie.es (2001:470:1f09:495::3): 56 data bytes
ping: sendto: Permission denied
resolución de nombres
dig @4.2.2.1 catgenie.es any
; <<>> DiG 9.9.5-11-Debian <<>> @4.2.2.1 catgenie.es any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32548
;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 8192
;; QUESTION SECTION:
;catgenie.es. IN ANY
;; ANSWER SECTION:
catgenie.es. 172495 IN A 217.126.185.215
catgenie.es. 172495 IN NS dns1.consulintel.es.
catgenie.es. 172495 IN NS dns1.consulintel.com.
catgenie.es. 172495 IN NS dns2.consulintel.es.
catgenie.es. 172495 IN NS dns2.consulintel.com.
catgenie.es. 172495 IN SOA dns1.consulintel.es. dnsadmin.consulintel.es. 2015081500 43200 7200 2419200 10800
catgenie.es. 172495 IN MX 30 mail.consulintel.es.
catgenie.es. 172495 IN MX 10 mail.consulintel.com.
catgenie.es. 172495 IN TXT "v=spf1 mx ~all"
catgenie.es. 172495 IN AAAA 2001:470:1f09:495::3
;; Query time: 79 msec
;; SERVER: 4.2.2.1#53(4.2.2.1)
;; WHEN: Wed Aug 26 12:51:39 CEST 2015
;; MSG SIZE rcvd: 301
-
Hola Joseba, tienes razon, si pruebas un ping y no pones el -4 te falla porque intenta con IPv6, pero la pagina web DEBE funcionarte, porque aunque no tengas IPv6 el navegador primero intenta con IPv6 y con un timeout con IPv4.
La duda que me queda es esa, si te ha ido con el browser y que router tienes
Con ping tengo comprobado que va a todos los clientes ...
-
Hola Joseba, tienes razon, si pruebas un ping y no pones el -4 te falla porque intenta con IPv6, pero la pagina web DEBE funcionarte, porque aunque no tengas IPv6 el navegador primero intenta con IPv6 y con un timeout con IPv4.
La duda que me queda es esa, si te ha ido con el browser y que router tienes
Con ping tengo comprobado que va a todos los clientes ...
Buenas jordipalet
Anoche estuvimos hablando desde la comunidad movistar y recuerdo comentarte que cambie el firmware de mi router y despues de eso no he tenido mas problemas, viendo el script de noltari en sus ultimas revisiones añadio la option de mtu a 1492, cosa que en mi firmware antiguo no lo tenia añadido y ahora si...por eso te decia que desde el cambio de firmware parecio solucionarse asi que debido al mtu deberia estar el problema o es que es mucha casualidad :-\
Version Actual en la interface WAN en Chaos Calmer RC3
config interface 'wan'
option ifname 'eth0.6'
option proto 'pppoe'
option username 'adslppp@telefonicanetpa'
option password 'adslppp'
option ipv6 '1'
option mtu '1420'
Version que usaba anteriormente en Chaos Calmer sin Option MTU
config interface 'wan'
option ifname 'eth0.6'
option proto 'pppoe'
option username 'adslppp@telefonicanetpa'
option password 'adslppp'
...Esta tarde he vuelto al firmware anterior sin option mtu y efectivamente desde el trabajo no me deja acceder, desde una vpn entre al router lo añadi y si que me deja acceder al servidor que tengo en la red local en casa.
Conclusion añadir option mtu '1420' ;D (o como dices y probando distintos valores) a la interfaz wan...
Pruebalo y comentamelo a ver si puedo acceder, porque ahora mismo al dominio que has puesto no se puede, y desde red movil si, vamos el mismo problema que tenia yo
-
Hola deejayexe,
Si, ahora lo entiendo, pense que te referias al firmware pero configurado a mano ... que es lo mismo que yo he hecho, y he dejado que la MTU sea negociada automaticamente al establecer el PPPoE, que es lo correcto.
Es cierto que esta solucion seguramente me resuelve el problema a mi, pero a los pobres usuarios que tienen los routers Mitrastar, que ya podran acceder a mi web, sin embargo seguiran sin poder acceder a otras webs que hayan dejado la MTU del PPPoE.
Por cierto, si lo haces asi, la MTU correcta (lo he estado comprobando hoy), seria 1480.
Ya sabes que cuanto mayor sea la MTU mas eficiente es el trafico a y desde a tu red.
A mi me gustan mas las soluciones mas correctas y dinamicas que se ajusten a la realidad de la red en cada momento. Me explico, si pones la MTU a 1480, y manaña hay un cambio en la red de Telefonica o de un ISP del otro lado del mundo que tiene que acceder a tu web, y se reduce la MTU por decir algo a 1280, tendrias de nuevo el mismo problema.
En realidad creo que hay otra posibilidad de resolverlo, estoy con ello.
Basicamente consiste en que en lugar de que ICMP sea respondido por el router, se haga una regla port forward en el OpenWRT que envie todo el trafico ICMP al servidor web que esta en la LAN privada.
En el firewall del servidor web hay que habilitar el trafico ICMP de tipo 3, 4 y 11, yo he habilitado tambien el 0 y 8 para tener ping.
De esta forma, se permite el Path MTU discovery, que permite que el ordenador del cliente, cuando negocia con el servidor web "acuerde" la MTU mas adecuada.
Asi en lugar de dejar la MTU "fija", sera negociada en funcion de cambios que haya en la red de Telefonica, o de otros, tanto si es a mejor como a peor, y no estas pendiente de que vuelva a fallar.
Lo pruebo mañana y confirmo si funciona ...
-
Hola a todos,
Ya he terminado con todas las pruebas y opciones para resolver esto que se me han ocurrido.
Paso a detallar el tema, explicandolo con pocos tecnicismos para que el que no controle de redes lo entienda. Es un poco largo, pero prefiero dar mas detalles, para que sea util.
1) El problema: Algunos usuarios de Telefonica, dependiendo de "en que equipos" de la red de Telefonica estan conectados, bien por algun fallo de configuracion de la red de Telefonica o algun bug del software de esos equipos, etc., se les REDUCE la MTU y por tanto no pueden llegar a muchas paginas web (no solo de España, sino de todo el mundo). He logrado contactar con alguien de Telefonica que ha visto mis pruebas y coincide conmigo en que efectivamente ese problema existe (y hasta ahora Telefonica lo achacaba a fallos de algunos routers, creian de hecho que era el Comtrend, pero ha quedado claro que no es ese el problema).
Ojo que puede haber dos clientes de fibra de Movistar, puerta con puerta, y uno esta conectados a unos equipos de la red de Telefonica y otro a otros, y a uno le falla y al otro no ... Asi que eso despista mucho.
Hemos visto que el problema se da mucho en la red de Canarias, pero tambien he visto casos en Madrid, sierra de Madrid, etc.
2) Solucion ideal: Lo ideal seria que se "negociara" correctamente la MTU entre el router de un cliente y el destino, para lo cual hay un mecanismo de IETF que se llama PMTU (Path MTU discovery), pero como hay filtado en muchas ocasiones de algunos tipos de ICMP, etc., etc., no funciona bien en el caso de IPv4 (en IPv6 es mas raro este filtrado de ICMP y por tanto suele funcionar). Digamos que esta seria la solucion en la que nadie tendria que hacer nada estatico, solo asegurarse que los que tienen servidores web u otros contenidos NO tengan filtrado los tipos de ICMP necesarios, etc. Ademas esta solucion implica que SOLO se pierden prestaciones de la red en aquellos casos en los que el cliente tiene problema de MTU, pero no en el resto. Sin embargo, las pruebas demuestran que quizas haya otros filtrados de ICMP en el camino y por tanto no siempre funciona ... Algo tan sencillo como configurar MSS clamping en cada una de las entradas zonas del firewall deberia funcionar, y aunque hemos visto que en el caso de Movistar no funciona, RECOMIENDO que se marque siempre esa opcion, porque puede resolver muchos casos (fuera de la red de Telefonica).
3) Solucion estatica: El mismo titulo lo dice, es estatica, y funciona, pero NO es optima y si cambian las condiciones de la red, puede volver a fallar, o aunque no falle, estamos "desaprovechando" prestaciones de la red (incluso cuando el trafico es de "entrada", ejemplo cuando nosotros navegamos o descargamos contenidos en lugar de "enviarlos"). Es decir afecta a TODO el trafico aunque no haga falta ya que el problema de la MTU SOLO ocurre en algunos casos (y desaparera si Movistar lo resuelve).
Bien, esta solucion consiste en la Interfaz WAN del router, si lo haceis con luci pestaña "advanced settings", poner en "override mtu" el valor 1484. Si lo haceis por ssh, añadir en la configuracion de la WAN (/etc/config/networks)
option mtu '1484'
De esta forma, al hacer un ifconfig, vereis que la MTU es de 1476 (8 bytes menos que lo indicado, por el propio pppoe, deberia ser el mismo valor, pero creo que esto es un bug de la version que yo uso).
En definitiva, lo importante es que os quede al hacer un ifconfig 1476 (si con otra version de OpenWRT hay que poner este valor en option mtu o en el luci, no lo he podido comprobar. Insisto, lo importante es que al hacer ifconfig, aparezca MTU 1476.
Lo podeis verificar con esta web: http://www.letmecheck.it/mtu-test.php
Porque este valor y no otro ?
a) Porque hemos comprobado que es suficiente en la red de Telefonica
b) Porque tiene que ser un multiplo de 8, sino se toma un valor inferior, asi que mejor hacerlo bien
c) Porque cuando mayor sea el valor, menos "prestaciones" perdemos (menos se fragmentan los paquetes grandes), y cuanto mas pequeño mas prestaciones perdemos
OJO: Inconveniente de poner la MTU estatica - Si un usuario tiene una MTU inferior (lo cual no es normal, pero ocurre), por ejemplo alguien de un pais de Africa que tenga conexion con dial-up (modem) y que la MTU sea de 576 bytes, por decir algo, quizas, no le funcionaria (salvo que en este caso este funcionando MSS clamp, u otros mecanismos). Pero obviamente no interesa poner una MTU tan baja por la perdida de prestaciones, salvo que tengamos ese problema y no nos quede otra.
Si ademas teneis un tunnel IPv6, el valor de MTU correcto PARA este valor de MTU IPv4, seria de 1456, que el ifconfig informara como 1456 igualmente. Porque es inferior en IPv6 ? Porque un tunel IPv6 (tipo 6in4, protocolo 41) necesita una cabecera adicional que ocupa 20 bytes (1476-20).
Por cierto, que se podria hacer una configuracion de mas parametros de IP en el router, para "aprovechar" mucho mas las prestaciones de la fibra, se me ocurre el TCP Window Size. Si alguno puede dedicar una horilla, no me importaria hacer pruebas en mi router y que alguien me confirme que le funciona bien (se pueden hacer mediciones sobre la marcha para comprobarlo).
-
He avanzado un poco mas con este tema ...
Al final, parece que el problema esta en las ONT de Alcatel (creo que son blancas todas), modelo 1240-GT.
El firmware de las mismas tiene un fallo que incrementa la MTU en 2 bytes con un padding y aunque parece una chorrada por 2 bytes, la lia.
A mi me la han reemplazado hoy temprano, por una Huawei, he eliminado en mis servidores la MTU "estatica" y todo parece que funciona perfectamente.
Asi que los que tengais esa MTU, mientras Alcatel no saque una nueva version de firmware que corrija el problema, recomiendo que pidais el cambio.
-
Hola!
Tengo la ONT de Alcatel, y es cierto que desde hace un mes mas o menos al cabo de unas 48 horas me deja de funcionar internet.
He probado con el TP-LINK Archer C7 y desde hace 2 semanas con el LINKSYS WRT1900AC ambos con 15.05 RC3 e incluso con versiones trunk.
Quizás mi problema sea lo que comentas, ¿Como solicitaste el cambio del ONT? Ya que cuando abres incidencia poco puedes solicitar.
Gracias!
-
Estos ultimos 3 dias, de nuevo hemos hecho pruebas con Telefonica (me dejaron 3 ONTs de diversos fabricantes y hemos ido haciendo capuras de trafico con ellas).
Ya no cabe ninguna duda, el problema que tenemos muchos usuarios de acceso a servicios internos, es la MTU mal gestionada por parte de las ONT de Alcatel.
Telefonica va a comunicarselo pero como os podeis imaginar, el tiempo de respuesta y una nueva version de firmware que os lo resuelva es indeterminado, semanas, quizas meses ?
Asi que los mismos de Telefonica me han dicho que a los que tengais problema (yo recomendaria a cualquiera que tenga una ONT de Alcatel que lo haga, porque a veces los problemas no los ves desde todas las lineas hasta que se juntan determinadas circunstancias), os recomiendo llamar al 1004, insistir en que no podeis acceder al interior de vuestra red desde fuera, incluso que os fallan webs de medio mundo (lo cual es real, otra cosa es que deis con ellas), y que los propios ingenieros de Telefonica os han dicho que es un problema de las ONT de Alcatel y que exijis su cambio por otra de otro fabricante.
Con estos datos me han asegurado que en el 1004 saben perfectamente que hace tiempo que han detectado problemas con estas ONT, lo que ocurre que hasta ahora que han encontrado un "conejo de indias" "con conocimientos", no han podido determinar cual era exactamente el problema ...
Hasta ahora, achacaban los problemas a algunos routers, pero ha quedado claro que no.
De esta forma los que tengais configurada la MTU de forma manual en el OpenWRT, podeis quitar esa configuracion y aprovechar la linea al maximo, al no fragmentar mas de lo necesario.
-
Por cierto, si alguno quiere tener soporte IPv6, en ese caso, en el OpenWRT (SIN MODIFICAR LA MTU en el PPPoE), si que hay que poner la MTU tunel IPv6 en 1460 bytes (tanto en el OpenWRT) como en el propio tunel (yo uso https://tunnelbroker.net/).
En caso contrario la MTU del tunel se fija en 1280, lo cual es un desperdicio y de nuevo fragmentacion innnecesaria.
-
Por cierto, si alguno quiere tener soporte IPv6, en ese caso, en el OpenWRT (SIN MODIFICAR LA MTU en el PPPoE), si que hay que poner la MTU tunel IPv6 en 1460 bytes (tanto en el OpenWRT) como en el propio tunel (yo uso https://tunnelbroker.net/).
En caso contrario la MTU del tunel se fija en 1280, lo cual es un desperdicio y de nuevo fragmentacion innnecesaria.
Yo también tengo un tunel con HE; al principio tenía problemas con algunos sitios que aparecían y desaparecían, o que eran totalmente inaccesibles, y resultó ser un problema con el MTU. En mi caso, la conexión PPPoE tiene un MTU de 1492, y por eso ahora en el túnel tengo 1472. Desde entonces, cero problemas.
-
¿Que os parece si os digo que puede ser algo intencionado para que se pueda flodear el router y saltarse la seguridad del mismo?.
No es que diga que sea así, pero viendo los logs del router Mitrastar veo que hay algunos DROP FRAGMENT FLOODING ATTACK y no se si es precisamente por ese problema con la MTU o es que el que tenga ese problema haga que ciertas paginas web que usan ese MTU distinto puedan flodear a estos routers con eficiencia.
Por ejemplo, visitando Htcmania me encuentro con esto en el router:
192.168.208.101 09/23/15 19:01:04 09/23/15 19:01:04 user-level Debug kernel "DoS: Action=DROP FRAGMENT FLOODING ATTACK IN=ppp100 OUT=br0 SRC=244-64.furanet.com DST=pc.HGW-2501GN-R2 LEN=517 TOS=0x00 PREC=0x00 TTL=57 ID=19662 DF PROTO=TCP SPT=80 DPT=58329 WINDOW=119 RES=0x00 ACK PSH URGP=0 "
Entre esto del MTU y lo del SSLV3 me da por pensar que a Movistar se le podria denunciar por descuidar la seguridad de sus clientes y favorecer que las conexiones sean interceptadas, que junto con el que tengas que usar el portal Alejandra (aunque saques el router del portal, este sigue pidiendo la contraseña de la misma manera que en el portal Alejandra, no parece que se desvincule del todo) parece que les pinta el camino de color rosa a los malos.
¿que opinais=
-
Dudo que sea a proposito, porque si fuera asi, ocurriria con todas las ONTs.
El fallo esta detectado con las Alcatel, y de hecho he hecho varias pruebas mas con la gente de Telefonica, que incluso se han desplazado aqui para probar con otros equipos, hacer capturas desde "dentro" de la red, al mismo tiempo que fuera, etc., etc., y se le esta reportando a Alcatel el fallo para que lo corrijan a la mayor brevedad.
-
Eso mismo llevan diciendo con el tema del SSLV3 y el router Mitrastar, meses, y no se ve intención de que lo arreglen, ¿cuanto tardan en corregirlo?, ¿una tarde un ingenierito?, por eso comento la posibilidad de que sea intencionado el tema del MTU y el SSLv3. Si no corrigen los problemas es porque no les interesa arreglarlos, que tampoco tiene tantos routers o modems distintos Movistar como para que desde hace mas de un año no se corrija el tema de los certificados de los Mitrastar.
Y sobre lo del MTU pues otro tanto de lo mismo, si quieres que funcione tienes que desactivar el cortafuegos, o al menos una parte del mismo en el router, esto es, o que dejan la puerta abierta o se aseguran de que tu seas el que deje la puerta abierta porque el hardware no funciona como debería.
Esos ingenieros que hacen los firmwares....varios años de carrera y en esos puestos en estas grandes empresas y ¿nos tenemos que creer que cometen esos errores tan tontos? ¿que no saben hacer las cosas bien?, el tiempo que tardan en arreglar los problemas en el hardware a nivel de firmware, kernels y demas (que no es el caso), si es que lo hacen, es sin duda para que la gente o compre nuevos routers o modems (con sus seguros problemas que todavia se desconocen en el momento de la novedad, como los viruses y troyanos, no se saben que existen hasta que alguien los encuentra) o porque les interesa que se pueda entrar hasta la cocina en cualquier sistema informático domestico y de pequeñas empresas....todas las demás posibles explicaciones derivan en estas dos posibilidades a mi entender.
Y que conste que esa es la respuesta que dan, que reportan el problema al fabricante, cuando son los ingenieros de Movistar los que añaden los datos de configuración a los modems, certificados y demas, es Movistar quien tiene que arreglar los fallos de configuración del router ya que son ellos los que cargan los nuevos firmwares y usan el TR069, por ejemplo, para administrarlos.
-
Eso mismo llevan diciendo con el tema del SSLV3 y el router Mitrastar, meses, y no se ve intención de que lo arreglen, ¿cuanto tardan en corregirlo?, ¿una tarde un ingenierito?, por eso comento la posibilidad de que sea intencionado el tema del MTU y el SSLv3. Si no corrigen los problemas es porque no les interesa arreglarlos, que tampoco tiene tantos routers o modems distintos Movistar como para que desde hace mas de un año no se corrija el tema de los certificados de los Mitrastar.
Y sobre lo del MTU pues otro tanto de lo mismo, si quieres que funcione tienes que desactivar el cortafuegos, o al menos una parte del mismo en el router, esto es, o que dejan la puerta abierta o se aseguran de que tu seas el que deje la puerta abierta porque el hardware no funciona como debería.
Esos ingenieros que hacen los firmwares....varios años de carrera y en esos puestos en estas grandes empresas y ¿nos tenemos que creer que cometen esos errores tan tontos? ¿que no saben hacer las cosas bien?, el tiempo que tardan en arreglar los problemas en el hardware a nivel de firmware, kernels y demas (que no es el caso), si es que lo hacen, es sin duda para que la gente o compre nuevos routers o modems (con sus seguros problemas que todavia se desconocen en el momento de la novedad, como los viruses y troyanos, no se saben que existen hasta que alguien los encuentra) o porque les interesa que se pueda entrar hasta la cocina en cualquier sistema informático domestico y de pequeñas empresas....todas las demás posibles explicaciones derivan en estas dos posibilidades a mi entender.
Y que conste que esa es la respuesta que dan, que reportan el problema al fabricante, cuando son los ingenieros de Movistar los que añaden los datos de configuración a los modems, certificados y demas, es Movistar quien tiene que arreglar los fallos de configuración del router ya que son ellos los que cargan los nuevos firmwares y usan el TR069, por ejemplo, para administrarlos.
El problema de todo esos ingenieros, es que siempre tienen un(os) jefe(s), que les manda(n), y que no tiene ni papa de idea de lo que tiene(n) entre manos, pero cuyo mayor problema es que los colores de la aplicación que estás desarrollando, "no coinciden con los de un amanecer en Suecia". Así que da igual que les digas que necesitan I+D para mejorar las aplicaciones, y que tienen que invertir para que la competencia no se los coma, que como las aplicaciones ya funcionan medianamente bien para la mayoría del propósito, pues pasan.
¡Hala!, ya me he desahogado... :-X
Además, míralo también por el lado del negocio:
Hacer que algo funcione al 90% cuesta 1.000 (es un ejemplo)
Hacer que algo funcione al 95% cuesta 10.000
Hacer que algo funcione al 99% cuesta 100.000
Hacer que algo funcione al 100% es incalculable y a veces incluso inviable tecnológicamente.
No le eches siempre la culpa al "ingenierito"... ;)
Si una compañía notifica a otra un fallo / cambio, es, o bien para quitarse responsabilidades si algo sale mal, o bien para comprobar que los cambios que tenga que hacer son compatibles con lo diseñado por el fabricante...
-
Juraria que conteste ayer, pero ahora veo que no ha salido, igual le di mal al click ...
Llevo muchos años trabajando para ISPs en todo el mundo (consultoria y despliegue de IPv6, soy autor de varios RFCs y muchas contribuciones al respecto en IETF). Igualmente he trabajado con muchos fabricantes, asi que hablo con un poquito de conocimiento de causa.
Ademas de lo que ha dicho Tki2000, la gran mayoria de los ISPs no hacen "nada" con los routers, los compran por volumen al fabricante que cumple unos minimos y da mejor precio, es casi una subasta. Como mucho especifican que se incluya tal o cual funcion y se excluyan otras si no "caben" en la flash, y que traigan una configuracion determinada por defecto y quizas su logo.
Hay un par de ingenieros que "verifican" los equipos, y suele hacerse un piloto, digamos 1000 equipos a clientes nuevos en el barrio tal de Madrid. Pero si esos nuevos clientes no son usuarios avanzados como nosotros, no tienen webs u otros servicios detras del router, los fallos que nos saltan a nosotros NO necesariamente les saltaran.
Movistar no puede "mejorar" el software del router, sino decirle al fabricante que se lo resuelva, pero si ya no tienen previsto comprarle mas, logicamente el fabricante pasa (quizas el contrato no contempla esas mejoras como el tema del SSL3, o ni siquiera contempla bugs si saltan despues de x tiempo de garantia), y menos aun cuando Movistar esta probando un router nuevo que integra la ONT y que en 2-3 meses sera el unico equipo que se instale ...
Yo se de buena fuente, que a Alcatel se le reportan los errores, y son terribles para que los corrijan y desde luego no en un plazo rapido, sino que los ponen en la lista de temas a resolver y cuando toca, si toca, se resuelve.
Ademas es una cadena, es posible que varias empresas, no solo ingenieros y sus jefes, no solo tecnicos, sino marketing, comercial, etc., intervenga en la cadena, y quizas quien diseño el software para la ONT de Alcatel o el firmware del Mitrastar, ya no esta o no existe y nadie tiene capacidad, o ni siquiera las fuentes para resolverlo.
Insisto, no es tan facil, pero sobretodo, puede que no haya un interes economico del fabricante para hacerlo, y en cambio hay mas interese para venderle a Movistar otros equipos mas nuevos ...
-
Esos ingenieros que hacen los firmwares....varios años de carrera y en esos puestos en estas grandes empresas
Lo dices como si esos ingenieros tuvieran puestos de gran relevancia y un salario por el que se deberían matar a trabajar...
El problema es más lo que te ha comentado Tki2000, certificar los equipos para comprobar que funcionan correctamente en la mayoría de casos posibles es MUY costoso, y en ciertas ocasiones puede resultar inviable.
Lo que no está nada bien es que las empresas no certifiquen ni siquiera lo básico, sino que comprueban si funciona y ya está.
Saludos.
-
Ademas hay que tener en cuenta, que los equipos que proporciona un ISP para una linea residencial son para dar "solo" acceso a Internet, no para tener servicios detras ... asi que posiblemente esa "certificacion" posiblemente esta "bien" hecha (el caso de la ONT quizas esta en el limite ... porque puede impedir el acceso a algunas webs, pero se podria decir que solo ocurre con webs que estan detras de esa ONT, que es para residencial).
Por eso los ISPs instalan Cisco y no Mitrastar, Comtrend, etc., en las lineas de empresas ... Es otro servicio, otro precio. Lo que tengo la duda es que ONT ponen en esos casos ...
-
Informacion de ultimo minuto ... Acabo de recibir una llamada del ingeniero que ha estado haciendo las pruebas y capturas de trafico, y ya esta confirmado que el fallo es de la ONT de Alcatel. A los 1.500 bytes de MTU, agrega 2 bytes.
Algunos equipos (que en realidad hace mal), los ignoran, pero si coincide que tu ONT pasa por un equipo Juniper, lo descarta (que es lo suyo, porque no se debe aceptar 2 bytes de padding por la cara si la MTU es de 1500). Este ultimo equipo en realidad lo esta haciendo "correctamente" segun estandares.
Asi que confirmadisimo que el problema es el firmware de las ONT de Alcatel, que, no sabemos porque, agrega esos 2 bytes de padding ...
Ma han indicado que el tema ha sido escalado a "maximos" niveles de autoridad de Movistar y Alcatel, para que den una solucion que podria ser:
1) La ideal y logica, Alcatel reacciona de forma muy rapida y saca un nuevo firmware que deje de hacer el padding.
2) Movistar (no se si se puede, quizas dependa de un cambio de firmware de Juniper o solo de configuracion) reconfigura los Juniper para que cuando lleguen 2 bytes mas NO los descarte (lo cual podria tener consecuencias en otros casos ..., aunque dudo que en ningun punto de la red de Movistar se usen MTUs mayores de 1.500).
3) Movistar reemplaza a todos los clientes que tengan las ONT de Alcatel por las Huawei u otras ...
Lo que es una pena es que Movistar ha malgastado recursos e "incordiado" a usuarios, cambiando routers creyendo que era un problema de los routers, y ahora queda claro que no era el caso ...
Da gusto cuando te encuentras con ingenieros de Movistar que creen lo que les cuentas, lo investigan, comprueban y se preocupan. Entiendo que esto solo lo pueden hacer, como decia en otro post, porque han dado con un usuario "avanzado", otros ni se hubieran sabido explicar o no habrian podido probar el tema con lo cual se habria podido quedar en via muerta.
-
Lo que algunos decis aqui lo haceis como si hubieseis descubierto el problema, desde hace meses que se conoce lo de la MTU, y cuando se ha comentado en otros foros, han dicho lo mismo, que se pondrian en contacto con Alcatel.
Y sigo diciendo que mucho ocultan, y que los problemas son intencionados y/o no quieren ser solucionados, y en el caso de existan culpables en una supuesta premeditacion, hasta los ingenieros ingenieritos serían culpables.
-
No hay mayor ciego que el que no quiere ver...
-
No hay mayor ciego que el que no quiere ver...
Amén.
-
Pues yo que llevo menos tiempo en este foro, no fui capaz de encontrar con las busquedas nada referido a "problema de MTU" que me llevara a un post indicativo de que el problema era la Alcatel, sino hubiera ahorrado muchisimo tiempo !
De todos modos me costo bastante encontar a alguien dentro de Movistar que se preocupara por el problema y que ademas me esta llamando cada semana para informarme de los pasos que se estan dando. Si se quisiera ignorar, creo que hubiera pasado de mi.
Solo queda esperar para comprobar ...
-
desde hace meses que se conoce lo de la MTU, y cuando se ha comentado en otros foros,
-
desde hace meses que se conoce lo de la MTU, y cuando se ha comentado en otros foros,
Lamento mucho tener tan arraigada, ésta, mi supina ignorancia, pero es que empeñado me tengo en no saber, qué piensa la gente o qué foros visita, ya sea por sofisticadas artes adivinatorias, o por habladurías canallescas. Si vuesa merced nos concediera el don de la iluminación, ¿sería tan amable de indicarnos la fuente de esa razón?
-
Tki2000, poeta !!
Has superado al mismísimo Lope de Vega!
A sus pies, maestro....
;D ;D
Ahora quiero un archivo de configuración en prosa.
>:( >:(
Saludos.
-
desde hace meses que se conoce lo de la MTU, y cuando se ha comentado en otros foros,
Lamento mucho tener tan arraigada, ésta, mi supina ignorancia, pero es que empeñado me tengo en no saber, qué piensa la gente o qué foros visita, ya sea por sofisticadas artes adivinatorias, o por habladurías canallescas. Si vuesa merced nos concediera el don de la iluminación, ¿sería tan amable de indicarnos la fuente de esa razón?
Hace meses que lo leí buscando la causa de este error en un huawey hg8240h y ya se hablaba de el problema de la MTU, que supuestamente se solucionaba estableciendo dentro de la ONT el mtu a mano aunque sin éxito ya que se revertían los cambios, el caso es que no consigo encontrarlo, pero como puedes ver no solo es un problema de Alcatel.
Prueba a buscar en google-----movistar "couldn't increase mtu"--- o quizás sobre el Jitter que creo que tambien es problema de la MTU y veras que esto lleva ocurriendo desde bastante tiempo.
De todas formas tu post me ha resultado simpático, lo normal es que te dijese que si tan ilustrado estás que lo buscases tu mismo, pero aquí tienes una muestra....
http://comunidad.movistar.es/t5/Soporte-T%C3%A9cnico-de-Fibra-%C3%93ptica/Solicitar-cambio-de-ONT-problema-de-jitter/td-p/2450582
-
Prueba a buscar en google-----movistar "couldn't increase mtu"--- o quizás sobre el Jitter que creo que tambien es problema de la MTU y veras que esto lleva ocurriendo desde bastante tiempo.
De todas formas tu post me ha resultado simpático, lo normal es que te dijese que si tan ilustrado estás que lo buscases tu mismo, pero aquí tienes una muestra....
http://comunidad.movistar.es/t5/Soporte-T%C3%A9cnico-de-Fibra-%C3%93ptica/Solicitar-cambio-de-ONT-problema-de-jitter/td-p/2450582 (http://comunidad.movistar.es/t5/Soporte-T%C3%A9cnico-de-Fibra-%C3%93ptica/Solicitar-cambio-de-ONT-problema-de-jitter/td-p/2450582)
Si le dices a alguien que has visto un burro volando, y no se lo enseñas, simplemente te ignora, no se pone a buscarlo...
No sé qué tiene qué ver el "desfase" (que tenemos palabras en español para decirlo) de ping con lo que dices. El desfase se produce por el encamiento dinámico del tráfico entre nodos de enrutamiento, material conductivo empleado entre nodos, y por la saturación del nodo, que no es la misma de un milisegundo a otro.
Un paquete normal de ping, no se fragmenta, así que no puede ser problema de MTU.
El problema de pérdida de paquetes entre nodos, puede ser debido, a que el nodo no se encuentre bien configurado para encontrar el siguiente salto en la tabla de nodos, y lo descarte, o a que el paquete no se ciña a los estándares de formato, y se descarte, que es lo que está pasando en este caso, ya que tiene 2 bytes de parcheo de más, y los nodos que se ciñen al estándard simplemente lo descartan. Sin embargo hay otros nodos que son más permisivos y dejan pasar el paquete, aún con la falla de formato, de ahí que sea difícil de averiguar qué está pasando, ya que unas veces podremos ver mensajes fragmentados bien devueltos, y sin embargo, otras veces no (es decir, unas veces podemos ver una página web, y otras veces no), dependiendo del camino (nodos) que toman los datos.
El que una compañía decida arreglar algo o no, simplemente es cuestión de beneficio. Si tengo que invertir 10000 en el estudio y arreglo de algo, para sacar 10 veces menos beneficio, pues simplemente no lo hago, y mucho menos si estoy fuera de la cobertura de la garantía.
Un problema lo tenemos los usuarios, que nos dedicamos a comprar cosas a medio hacer, esperando que, con una actualización de firmware posterior, se arreglen los fallos que ahora vemos, cuando lo que en realidad deberíamos hacer es "castigar" a las compañías y no comprar sus productos hasta que estuvieran terminados del todo. Esta actitud es de la que se benefician las empresas, y se ríen de que luego no haya nada más que unos cuantos usuarios que se quejan de que no funciona, y que por supuesto son los "usuarios exigentes". Habrá compañías que no puedan o sepan arreglar el fallo porque simplemente son consumidoras del producto, no desarrolladoras, y habrá compañías que pasen de arreglar la funcionalidad, por los motivos anteriormente expuestos. Otro problema lo tenemos, cuando no sabemos la funcionalidad que tiene lo que compramos, y descubrimos los fallos después de haberlo comprado, en cuyo caso podemos exclamar que, "nos la han colado".
En definitiva, cuando pasa algo así, sólo podemos esperar que la política de la compañía, vaya más allá del puro beneficio y también se base en la re****ción.