Member of The Internet Defense League Últimos cambios
Últimos Cambios
Blog personal: El hilo del laberinto Geocaching

Infovía Plus

Última Actualización: 22 de Septiembre de 1.999 - Miércoles


Últimos comentarios Infovía Plus

Hace ya bastante tiempo que no toco esta página, ya que el tema Infovía Plus parece haberse estabilizado: no va mi mejor ni peor que antes :-). En esta sección añadiré algunos comentarios sueltos, nada más.

  • Sincronización RADIUS <-> Servidor de Túneles (jcea@argo.es - 09/Feb/99)

    Todos sabemos que uno de los grandes problemas que tenemos es la sincronización entre el servidor de túneles y el servidor RADIUS. Ello tiene dos consecuencias:

    1. Si el radius se reinicia, no aparecerá ningún usuario conectado AUNQUE haya conexiones previas y estén funcionando correctamente. No nos aparecerá ningún usuario conectado, tendremos marcadas IPs asignadas como libres, etc..

    2. Si se reinicia el servidor de túneles, el servidor RADIUS tendrá constancia de conexiones que ya no existen. Más grave aún, cuando los usuarios intenten volver a entrar, serán rechazados porque al servidor RADIUS ya le consta que hay una conexión activa.

      Este problema es más grave todavía debido a la tendencia de los servidores de túneles (al menos hasta la versión 20 del S.O.) a "olvidarse" de decirnos que los usuarios se han desconectado.

    No hay una solución sencilla al punto A, como no sea reiniciar el servidor de túneles.

    En cuanto al punto B, con anterioridad se podían ver los usuarios conectados a través del servidor de túneles mediante Telnet o SNMP (en el SNMP se obtiene un volcado de rutas y, de forma indirecta, de usuarios). Lamentablemente TD (Telefónica Data - ya no es Telefónica Transmisión de Datos) ha restringido el acceso a los servidores de túneles desde que I+ entró en funcionamiento "oficialmente".

    ¿Qué se puede hacer?.

    Podemos seguir teniendo acceso a la parte de la tabla de rutas que nos interesa mediante dos formas:

    1. Aprendizaje por RIP: El servidor de túneles propaga las rutas de los usuarios mediante RIP. Si tenemos algún proceso que lea dichas tablas y las contraste con los usuarios conocidos por nuestro RADIUS, es posible detectar discrepancias.

    2. Aprendizaje por ARP: Simplemente volcamos la lista de usuarios conocidos por nuestro RADIUS, y le hacemos un "ping" uno a uno (normalmente ese ping se haría en paralelo). Da igual que el ping tenga éxito o no; lo que queremos es "actualizar" nuestra tabla ARP. Tras un par de segundos (no hace falta recibir respuesta de los ping) volcamos la tabla ARP de nuestra máquina.

    No voy a dar detalles de cómo acceder a esas informaciones o para qué sirven. Es bastante evidente.

  • router 3com office conect 511 (jmvalades@bme.es - 09/Feb/99)

    Hola, tengo un router 3com office conect 511 y no soy capaz de conectarme de una forma continua, ya he actualizado el soft, he realizado todos los pasos según se describen en las instrucciones e incluso las que he encontrado aquí, pero sigo sin poder conectarme, lo curioso es que si intento conectarme 4 o 5 veces seguidas "a veces" conecto. Si cambio el router y le pongo un shiva, conecto a la primera siempre y sin ningún tipo de prolema. He realizado la configuración como tropecientas veces, e incluso he intentado hacer cambios por mi cuenta como aumentar el tiempo de autentificacion y cosas por el estilo, pero naaaaaaaaaaa de naaaaa. Alguien sabe que pasa?, es que estos router son una patata, o qué?

  • modo texto (domenech@tarraco.xeric.es - 10/Feb/99)

    hola Jesus,

    seguramente ya lo sabras, pero hay un pequeño truco que puede ser interesante investigar su potencial.

    consiste en llamar a un nodo de I+ con un programa de terminal 'a pelo', sin acceso telefonico a redes ni nada de eso.

    yo estoy un poco chapado a la antigua y prefiero utilizar un Terminate desde MSDOS o un sencillo Minicom en Linux.

    una vez tienes CONNECT tecleas un par de ENTERs ( esto me trae recuerdos ) y te aparece una prompt.

    si tecleas user: infovia , pass: infovia , caes en una 'shell' etiquetada ASCEND%

    solo encontre un comando valido que arrancaba el PPP pero ahora no recuerdo cual era...

    no se, quizas sea una tonteria, pero me parecio muy interesante.

    Comentario de JCEA: ¿No es esa precisamente la forma de entrar para Apple Macintosh y demás equipos con problemas?. Se usa un terminal para lanzar la sesión PPP...

  • Informe técnico sobre el Acceso a Internet a través de la Red IP (jcea@argo.es - 15/Feb/99)

    El 15 de Febrero de 1.999 la Dirección de Marketing (ojo, marketing :-) de la de entonces Telefónica Transmisión de Datos, hace público un documento de 17 páginas llamado "Informe técnico sobre el Acceso a Internet a través de la Red IP". En el nuevo web de Telefónica Data no parece estar disponible, por lo que he puesto una copia en mi propio servidor, en formato PDF (267Kbytes). Curiosamente en el documento pone "queda prohibida qualquier reproducción, distribución o comunicación pública, salvo autorización expresa de Telefónica de España, S.A.". Dado que el documento estuvo disponible en su propio web durante varias semanas, deduzco que se trata de un documento público.

    Un detalle importante que se deduce del documento, es que para que funcionen las llamadas al 901, en las zonas sin nodo local, es necesario tener activado el Caller-ID.

    No hago ningún otro comentario sobre el texto.

    Tras solicitar consejo legal (mi agradecimiento a Carlos Sanchez Almeida - sanchezalmeida@bufetalmeida.com), elimino de mi web el enlace al documento descrito.

  • Más problemas con Ivia (domenech@tarraco.xeric.es - 17/Feb/99)

    hola Jesus,

    te envio otro problemilla que tiene Infovia+, que seguro que ya conoces:

    hace un tiempo, con la antigua Infovia, era bastante dificil poder 'tracear' el trafico que generaban los usuarios desde y hacia Internet, debido a que el trafico llegaba al router y 'rebotaba' hacia la red otra vez.

    ahora esto ha cambiado.

    el trafico llega al servidor de tuneles, se 'destuneliza', cae a la ethernet del ISP y de alli al router.

    esto posibilita, con extrema facilidad, que cualquier maquina conectada a esa ethernet pueda observar todo ese trafico y hacer con el lo que le plazca.

    es realmente inquietante, poner un sencillo 'sniffer' y observar como crece el log.

    evidentemente, esto no es ningun problema para ISPs serios, con empleados de confianza y con la ethernet de los routers separada del resto de la empresa, etc., pero como tu ya sabes, todo esto, no ocurre muy amenudo.

    Comentario de JCEA: Correcto. Pero cualquier proveedor desaprensivo podía obtener casi la misma información analizando las conexiones SMTP y HTTP, siempre que -en este último caso- los usuarios utilicen un sistema proxy/caché tipo SQUID.

  • Cambiar Tamaño MTU en Windows NT (jmvalades@bme.es - 23/Feb/99)

    Disponible en Windows 3.1x/95/NT MTU Settings.

    Windows NT 
    
         Unlike Windows95 setting of "MaxMTU" the correct syntax for NT 3.5x and 4.0 is "MTU". You'll need to edit the registery, the local one if your on a 
         network.
            #First run regedt32
            #You'll be presented with several folders. Look for and click on the "HKEY_LOCAL_MACHINE" folder/window.
            #Click on the '+' next to "SYSTEM"
            #Click on the '+' next to "CurrentControlSet"
            #Click on the '+' next to "Services"
            #You'll now see a bunch of 'services' listed. Scroll down the list until you find your NIC (Network card, ie: NE2000, 3Com, Proteon, etc).
            #You should have 2 entries for each card in your system, go to the second entry and click on the '+' next to the NIC name.
            #Next you should see 2 folders. "Linkage" and "Parameters". Click on the '+' net to "Parameters".
            #You should now see all the protocols on your NIC, and more specifically the TCPIP folder.
            #Click on the "TCPIP" folder. In the window to the right you should see all the settings for this card/protocol (ie: DefaultGateway, IPAddress, 
              SubnetMask, etc).
            #Make sure that the "TCPIP" folder is highlighted and not one of the entries in the window to the right where your TCPIP settings are. On the top menu, 
              select: 
            #click - [EDIT]
            #click - [ADD VALUE]
            #You'll be presented with a pop-up window for "ADD VALUE" with 1 input field and 1 list-box.
            #Enter/Select the following:
            #[Value Name:] ------ MTU
            #[Data Type:] -------- REG_DWORD
            #click - [OK]
            #Next you'll be presented with another pop-up windows for "DWORD Editor" with 1 input field and 3 radio buttons. 
            #Enter/Select the following: 
            #*IMPORTANT* 
            #[click on the radio button "FIRST" and select "DECIMAL"]
            #*IMPORTANT* 
            #[Radix] ----- Decimal
            #[Data:] ----- 1400 (if on a local network) or 1024 (on a dial-up connection)
            #Click - [OK]
            #The new MTU setting should show up in the window to the right and should look something like the following:
            #MTU:REG_WORD:0x578
            #Exit/Close the Registery (Changes will be saved automatically), and reboot.
            #That's it!
    

  • Problemas con router Digital (optima@optimat.com - 25/Feb/99)

    Estimado Jesus,

    he encontrado muy interesante tu página sobre los problemas que está dando Infovía Plus... por fin veo que no somos sólo nosotros los que los tenemos :-)

    Lo que no he encontrado en tu documento es información sobre routers Digital. En concreto hemos probado un Routeabout Access ISDN que no parece poder conectarse. Tras muchas pruebas hemos averiguado que no manda la clave Chap codificada (la manda en texto plano), con lo que no se autentifica con Infovía Plus. Por cierto, este router funcionaba perfectamente con la antigua Infovía.

    Este router en concreto no ha sido diseñado por Digital, así que te agradecería mucho si alguien pudiera comentarnos quién lo fabrica para buscar algún parche o alguna actualización del software por Internet.

    Gracias por adelantado y espero que entre todos podamos solucionar los problemas que está generando el cambio a Infovía Plus

                        Javier Prieto Martínez
                        Optima Technologies
                        optima@optimat.com
    

  • Tres problemillas, ¿alguna ayuda? (oskar.linares@upc.es - 24/Mar/99)

    Primer problemilla:

    Hemos detectado que de vez en cuando el identificador de llamadas en el radius se 'resetea' volviendo el contador a cero. Esto coincide con la conexión de un usuario ADMIN_USER que es el que obtiene el id de conexion 00000000. Habiamos pensado que esto podrian ser conexiones desde TTD. Esas conexiones se producian a horas de trabajo (10h, 13h), pero el otro dia tuvimos una conexion a las 00:28, y esto nos parece sospechoso.

    En el log aparece lo siguiente:

    22-03-1999 00:28:18
            User-Name = "ADMIN_USER"
            NAS-IP-Address = 0.0.0.0
            NAS-Port = 0
            Acct-Status-Type = 7
            Acct-Session-Id = "00000001"
    

    El codigo 7 corresponde con un Admin-Reboot.

    Alguien ha notado algo parecido ?Es un proceso automatico del radius ? Los de TTD trabajan hasta la 1 de la madrugada ? : )

    Segundo:

    Otro problema que tenemos es que en los logs del radius nos aparecen STOPS con codigo de desconexion 1 (liberado por el usuario), sin START asociado.

    Estos STOPS se reciben con todos los campos a 0 (menos el de status):

    24-03-1999 02:41:28
            User-Name = "xxx"
            NAS-IP-Address = 195.77.8.130
            NAS-Port = 166
            Acct-Status-Type = Stop
            Acct-Delay-Time = 0
            Acct-Input-Octets = 0
            Acct-Output-Octets = 0
            Acct-Session-Id = "00011522"
            Acct-Session-Time = 0
            Acct-Input-Packets = 0
            Acct-Output-Packets = 0
            Acct-Terminate-Cause = 1
            NAS-Port-Type = Async
    

    Esto no sería muy preocupante si no fuera por el hecho de que hemos pasado de tener en el mes de febrero unos 80 casos al mes, a tener 21.300 en lo que llevamos de mes de marzo. A partir del 4-Marzo empezamos a tener una media de unos 1000 stops sin start, con picos de hasta 2500 en un mismo dia.

    No es una situacion que se produzca de forma esporadica, sino en franjas de tiempo en las cuales no se acepta ni una sola conexion. Estas franjas son totalmente aleatorias.

    Alguien ha notado lo mismo ? Alguna solucion ? Consuelo ?

    Tercero:

    Tenemos instalada la version S32 del servidor de tuneles, que nos prometia acabar con el problema de las sesiones colgadas, y éste no solo no ha cesado, sino que sigue su ritmo creciente de conexiones colgadas. De momento vamos por unas 35 al dia, con picos a veces de hasta 140 conexiones colgadas. Tenemos un proceso que se dedica a liberar estas conexiones y anotarlas en un log, y la tendencia es a la alza. Alguien con la misma version del servidor de tuneles tiene los mismos problemas ? O somos los unicos ?

                                  oSKaR@upc.es
    

  • Re: Sobre el MTU (jcea@argo.es - 24/Mar/99)

    > Entiendo que si cambiamos el MTU en nuestros servidores solo afecta al
    > usuario cuando accede a nuestros servidores. Pero si el usuario esta
    > navegando por internet o bajandose algo de dios sabe donde, el cambio
    > en nuestros servidores no le afecta. En ese caso habria que cambiar el
    > MTU de los routers tambien.

    Sí, muchos proveedores no se dan cuenta de esto. Hay dos soluciones simples, a la espera de que la gran T :-) arregle el problema:

    • Bajar la MTU del router de entrada en la red (normalmente depende de TTD)

    • Que nuestros usuarios naveguen a través de un proxy o caché.

  • aportación (pnte@pnte.cfnavarra.es - 23/Jun/99)

    Hola, me llamo Miguel y administro un pequeño proveedor de Internet para centros educativos en Navarra. He visto la página sobre Infovía Plus y me ha resultado muy interesante. Me he fijado que la última fecha de actualización es de marzo del 99 y como en ella se dice que si alguien puede aportar algo que te lo comente, me he decidido es enviar este mail. Vaya por adelantado que si no tiene interés lo olvidas y punto.

    Nosotros (el Departamento de Educación) hemos montado un ISP hace unos meses y desde entonces todo han sido quebraderos de cabeza con Telefónica y su infovía Plus. El último, hace dos semanas, ha sido con la versión S32 del servidor de túneles. Estuvo funcionando "bien" durante dos meses pero un buen día empezó a dejar IP-s colgadas hasta que al final no dejaba acceder a ningún usuario. Abrimos la pertinete avería, resetearon el servidor de túneles y volvió a funcionar. Pero a las pocas horas otra vez lo mismo. Nos dijeron que tenían que actualizarnos a la S39 pero no conseguían realizar la transmisión del software por FTP al servidor de túneles a través de su red IP. Al final (tres días más tarde) lo consiguieron haciéndolo a través de Internet. Instalaron la versión S39 y desde entonces parece funcionar bien. Y digo parece porque una de las últimas noches dejó seis IP-s enganchadas que tuve que soltar con el rad_tool al día siguiente.

    Explícaciones de un técnico de ttd:

    Mi pregunta: ¿Cómo es posible que un software que ha funcinado durante dos meses deje de funcionar de repente?

    Respuesta del técnico: No sabemos muy bien la razón. Parece que se trata de un problema de "degradación" de los protocolos PPTP.????

    Bueno no quiero ser pesado.

    Saludos.

    P.D.: Tengo más problemas para comentar, por ejemplo los problemas de conexión con los routers OfficeConnect de 3Com, pero los dejo para otro mail posterior, si te parece de interés.

  • Problemas con Router que se conectan con Chap (jmvalades@bme.es - 16/Sep/99)

    Esto parece como un cuento, todo comienza cuando un cliente nos contrata una conexión RDSI, todo sigue los trámites normales, se le da de alta en el radius con las configuraciones de RDSI, y se espera a que el cliente comience a hacer pruebas.

    Primera llamada del cliente al que le han instalado un Router Nautica 2000 de By Network, "la conexión no funciona con usted pero sí con Teleline y con Infonegocio". Primera sorpresa, no puede ser, tengo tropecientos clientes con conexiones RDSI con routers y funcionan perfectamente.

    Me tiro de los pelos, comienzo ha hacer pruebas con la conexión con modems, routers,, etc, "a mí me funciona". Comienzo a mirar el log del radius y el fichero detalle, algo raro ocurre, la conexión del cliente con su router Nautica 2000, solo deja en el fichero paquetes Stop, ni siquiera hace el Start.

    Paso siguiente, llamada al 902 11 35 24, explicamos el caso y debido a mi insistencia me hacen una incidencia. Al día siguiente me llaman de TTD, les vuelvo a explicar el caso y se pone una chica, Ana, comienza a repasar las configuraciones de los 3Com y yasta, no estaba activada la petición por CHAP, da la casualidad de que el router dichoso "Nautica 2000" solo se conecta por CHAP y no por PAP, por lo que si la gente de TTD te ha quitado o no ha configurado CHAP este tipo de routers no se conectarán.

    Conclusión, en los sitemas NT, TTD suele desactivar el CHAP, por lo que los router que solo utilizan CHAP para conectarse darán problemas, pedirles a la gente de TTD que os los dejen activados.

    Saludos y espero que te sea útil la información.

    Comentario de JCEA: Si el servidor de túneles acepta CHAP y tenemos las claves RADIUS cifradas en el servidor RADIUS, la autentificación fallará, ya que no se puede autentificar por CHAP si no se dispone de la clave en texto llano. Por tanto, los routers RDSI que sólo se pueden conectar con CHAP son incompatibles con los proveedores que empleen tecnología tipo "shadow" para proteger sus claves..


Historia de Infovía Plus

  • Comisión del Mercado de las Telecomunicaciones - ACUERDO (Ampliación moratoria INFOVÍA) - 26/Nov/98

    ACUERDO POR EL QUE SE ESTABLECE UN PERIODO TRANSITORIO PARA EL CESE GRADUAL DE LA PRESTACIÓN DEL SERVICIO DE ACCESO A LA INFORMACIÓN POR PARTE DE TELEFÓNICA DE ESPAÑA, S.A. SEGÚN VIENE REGULADO EN LA ORDEN DEL MINISTERIO DE FOMENTO DE 11 DE ENERO DE 1.996.

    Debido a los problemas de despliegue, funcionamiento y difusión pública de la desaparición de Infovía y la todavía deficiente implantación de Infovía Plus, se prorroga la desaparición de Infovía (055) del 1 de Diciembre de 1.998 al 17 de Enero de 1.999.

    Es curioso que en el acuerdo se defina "un periodo transitorio de cese gradual de prestación de servicio", pero no entra en ningún momento en definir en qué consiste dicho cese gradual.

    Esta prórroga se suma a la que ya se definió el 12 de Marzo de 1.998.

  • Comisión del Mercado de las Telecomunicaciones - RESOLUCIÓN (Expediente S.C. 54/98) - 12/Nov/98

    RESOLUCIÓN SOBRE LA SOLICITUD FORMULADA POR LA ENTIDAD BTTEL RESPECTO DE ACCESO ESPECIAL.

    BTTel reclama, pero parece que el tipo de acceso solicitado en su día no se corresponde con el reclamado en este momento, por lo que la CMT no lo admite a trámite.

  • Comisión del Mercado de las Telecomunicaciones - RESOLUCION (Expediente M.E. 36/98) - 29/Oct/98

    RESOLUCIÓN SOBRE LA SOLICITUD DE BT TELECOMUNICACIONES, S.A. A TELEFÓNICA, S.A. DEL ACCESO ESPECIAL PARA SU SERVICIO INTERPISTA.

    Reclamación por la que BTTel reclama a Telefónica un número único para todo el territorio nacional, a precio de llamada metropolitana. Telefónica propone el uso de un número 901 5xx xxx, lo que supone para el usuario un coste de llamada metropolitana, pero un coste elevado para el proveedor. Esa es, no obstante, la solución adoptada por Telefónica Transmisión de Datos.

    La resolución concluye denegando a BTTel el acceso en el modo que esa empresa lo demanda, y obligando a Telefónica a que preste el servicio 901 5xx xxx a BTTel en las mismas condiciones que a su filial TTD.

  • Comisión del Mercado de las Telecomunicaciones - ACUERDO (Expediente ME 6/97) - 12/Mar/98

    ACUERDO POR EL QUE SE AMPLIA EL PLAZO EN EL QUE EL SERVICIO DE ACCESO A INFORMACIÓN REGULADO EN LA ORDEN DEL MINISTERIO DE FOMENTO DE 11 DE ENERO DE 1996 HABRÁ DE SEGUIRSE PRESTANDO POR TELEFÓNICA DE ESPAÑA S.A.

    Inicialmente se mantendría Infovía hasta la entrada del nuevo plan de numeración o hasta, como muy tarde, el 1 de Agosto de 1.998. Dada la inexistencia de una oferta variada (libre competencia), se obliga a Telefónica a proporcionar el servicio hasta el 1 de Diciembre de 1.998.

  • Derogación del Ministerio de Fomento - 8/Sep/97

    ORDEN DE 8 DE SEPTIEMBRE DE 1997 POR LA QUE SE DETERMINAN LAS CONDICIONES DE COMPETENCIA EFECTIVA PARA LA PRESTACION DEL SERVICIO DE ACCESO A INFORMACION A TRAVES DE LAS REDES TELEFONICAS PUBLICAS CONMUTADAS O DE LAS REDES DIGITALES DE SERVICIOS INTEGRADOS.

    Publicado en el BOE del 16 de Septiembre de 1.996, página 27297.

  • Modificación del Ministerio de Fomento - 22/Nov/96

  • Orden del Ministerio de Fomento - 11/Ene/96

    ORDEN DE 11 DE ENERO DE 1996 POR LA QUE SE DICTAN INSTRUCCIONES A TELEFONICA DE ESPAÑA, SOCIEDAD ANONIMA, PARA ESTABLECER UN SERVICIO DE ACCESO A INFORMACION A TRAVES DE LA RED TELEFONICA PUBLICA CONMUTADA Y RED DIGITAL DE SERVICIOS INTEGRADOS.

    Publicado en el BOE del 27 de Enero de 1.996, página 2635.


Problemas de Infovía Plus

Estoy documentando una lista de problemas de Infovía Plus. Por favor, los que conozcan o tengan problemas adicionales, que me lo hagan saber y enviaré una versión actualizada.

Los añadidos en cada revisión de este texto se indican claramente.

  • Revisión 10: 02/Mar/99

    • Problemas con el Router RDSI Intel 9300.
    • Nuevo Firmware para los Shiva AccessPort.
    • Nuevo Firmware para los ZyXel.
    • Nuevo Firmware para los D-Link.
    • Actualización del Software del Servidor de Túneles de la versión 20 a la 22.
    • Actualización del Software del Servidor de Túneles de la versión 22 a la 29.
    • Actualización del Software del Servidor de Túneles de la versión 29 a la 32.
    • Experimentos con la versión S39 del software del Servidor de Túneles.
    • Identificación de la versión del Software del Servidor de Túneles.
    • Conexiones de usuarios que no aparecen en el RADIUS.
    • Script para detectar y solucionar el problema de los usuarios enganchados en el RADIUS.

  • Revisión 9: 09/Feb/99

    • Solución a cuando a los usuarios se les pide constantemente el nombre de usuario y contraseña.
    • URL de una pila TCP/IP que sí funciona en Macintosh.
    • MTU.
    • Sistema Operativo actualizado para los routers Náutica de Bay Networks.
    • Aclarados más puntos con los routers Office Connect 511.
    • Disponible una versión del sistema operativo del Intel 8100 compatible con Infovía Plus.
    • Otra vez problemas con los routers Zyxel prestige 100/100ih.
    • Problemas con la tarjeta RDSI Compaq Microcom 610.
    • Más información sobre el Cisco 1603, con IOS 11.1.
    • Problemas con la tarjeta Hayes Accura ISDN, y posible solución.
    • Método alternativo para conexión desde Windows 3.1x.

  • Revisión 8: 21/Ene/99

    • Problemas con las tarjetas Diva Sever BRI-2M.
    • Actualización de software para los routers 3COM.
    • Problema con la tarjeta RDSI TELES también sobre Windows 95.
    • Actualización para el router CBra de Teldat.
    • Solucionado el problema de la tarjeta RDSI TELES con Linux.
    • Problemas con los routers Compaq Microcom 808.
    • Router Cisco 2503.
    • Problemas de conexiones por considerarse RDSI.
    • Uso de subredes en Infovía Plus.
    • Cambios de última hora en Infovía Plus.
    • Cisco 1603.
    • Problemas de acceso para los usuarios de Windows 3.x y Macintosh.
    • Multilink y Cisco 761.
    • La tarjeta TELES funciona dependiendo del nodo de acceso a Infovía Plus que se esté utilizando.
    • Se ha dilucidado el tema de si el límite de los servidores de túneles corresponde al número de túneles o al número de sesiones.
    • Sesiones colgadas.
    • Aclarado nuevamente el tema de reutilizar_dirección.

  • Revisión 7: 12/Ene/99

    • Problema con la tarjeta RDSI TELES sobre Solaris.
    • Problemas de acceso con los Macintosh.

  • Revisión 6: 08/Ene/99

    • Solucionados los problemas con los routers Bay Networks.
    • Solucionados los problemas con los routers OfficeConnect 5x1.
    • Limitación de 48/512.
    • Nueva versión del sistema operativo para la versión DPE del servidor de túneles.
    • Problemas con la longitud de las claves.
    • Navegación anónima por Internet.
    • Uso de Proxies, IRC, News y demás servicios desde un acceso anónimo de Red IP.

  • Revisión 5: 04/Dic/98

    • Aclarados algunos puntos respecto al tema PAP/CHAP.
    • Telefónica presenta una página con diversos parches para los problemas de los routers.
    • El atributo NAS-Port-Type no funciona correctamente.

  • Revisión 4: 01/Dic/98

    No se documentaron los problemas solucionados con el cambio de sistema operativo en los servidores de túneles.

    Se identifican dos tipos de servidores RAS en la infraestructura de acceso de I+, y se documentan parte de sus características PPTP.

  • Revisión 3: 26/Nov/98

    Este fin de semana pasado se nos ha actualizado a casi todos los proveedores el sistema operativo del servidor de túneles, corrigiendo con ello muchos de los problemas comunicados en boletines anteriores. No obstante siguen existiendo detalles por pulir.

    El software instalado actualmente es

    SW/NBSI-CF,11.1.0.00S20 - Modelo de 48 túneles
    SW/NBDPE-DW,11.1.0.00S20 - Modelo de 512 túneles

    Se añaden algunas soluciones para el acceso de los routers RDSI problemáticos.

  • Revisión 2: 19/Nov/98

    El documento inicial crece considerablemente gracias a las aportaciones de otros miembros de la lista de proveedores.

  • Revisión 1: 18/Nov/98

    Los problemas que se indican los había detectado yo mismo.


Infovía Plus

  • Parece que la combinación usuario@cpi no puede superar los 16 caracteres.

    Desde Julio es posible utilizar más de 16 caracteres (al menos hasta 30) (Rev.3 - svt@svt.es)

  • En este momento los CPI asociados no funcionan en I+ (Rev.2).

    Cuando los CPI asociados utilizan el mismo RADIUS que el servidor principal (son alias del CPI principal), funciona correctamente (Rev.3 - svt@svt.es)

  • A muchos usuarios simplemente no les funciona Infovía Plus, aunque el acceso anónimo funciona perfectamente.

  • El promedio de llamadas exitosas no supera el 33%.

  • Algunos nodos de acceso no funcionan con determinados proveedores (Rev.3 - master@atlas-iap.es)

  • Un usuario que conecte por CHAP suele ser rechazado (Rev.3 - master@atlas-iap.es) (Rev.3 - jmiguel@virtualsw.es)

    (Rev.3 - jcea@argo.es)
    Hay que tener cuidado en que la autentificación CHAP *OBLIGA* a que el servidor disponga de las claves de usuario en texto claro. Por tanto un proveedor que utilice el /etc/passwd o el /etc/shadow nunca podrá verificar autentificaciones CHAP.

    Dado que parece que la idea de Telefónica es migrarlo todo a CHAP, los proveedores en estas condiciones tendrán que plantearse cambiar, o bien modificar la configuración de su servidor de túneles para que no negocie CHAP en el PPP.

    (Rev.5 - master@atlas-iap.es)
    El servidor de túneles debe ser configurado para negociar con PAP. No es posible tener CHAP con password "UNIX".

  • El ancho de banda efectivo disponible para los usuarios que entran por I+ parece ser mucho menor que el de Infovía, a pesar de que teóricamente los caudales contratados son iguales (Rev.3 - deinfo@deinfo.es)

  • (Rev.6 - jcea@argo.es)
    Dependiendo del nodo y del momento concreto en que se haga, un usuario puede acceder a internet a través de un acceso anónimo a Infovía Plus. Las direcciones IP que da Infovía Plus a los usuarios anónimos son válidas en Internet, y no siempre se están filtrando en el "Toll Gate". Ello hace que un usuario pueda navegar por internet sin necesidad de tener contratado ningún proveedor, o sin necesidad de autentificarse.

  • (Rev.6 - jcea@argo.es)
    Muchos proveedores proporcionan servicios sin verificar o controlar las direcciones IP de las peticiones. Ello hace que, por ejemplo, si un proveedor tiene instalado un Proxy Web sin limitar los clientes que pueden usarlos, cualquier usuario anónimo de Infovía Plus podrá utilizar dicho servicio para acceder a internet. Lo mismo se puede decir de servicios como POP, IRC o News.

    Las clases asignadas a Telefónica para la Red IP son: 193.152.*.* y 193.153.*.*.

    El problema es debido a que cuando se rellenó el cuestionario de alta en Red IP, la mayoría de los proveedores situaron sus redes locales en la zona accesible de forma anónima, sin ser conscientes de lo que ello supone.

  • (Rev.7 - dmgomez@virtualcom.es)
    No es posible establecer conexiones con I+ utilizando tarjetas TELES sobre Solaris (Drivers proporcionados por el fabricante) y sobre Linux (tarjeta ampliamente soportada en la comunidad LINUX).

    La conexion funciona perfectamente sobre Infovia pero con I+ no es capaz de superar la fase de negociacion LCP.

    (Rev.8 - jordi@webarna.com)
    Lo segundo es (ahora) incorrecto. Quizá ya lo sepas. Te mando (por si a alguien le ayuda) la configuración del ipppd que yo utilizo... está bastante optimizada, aunque es difícil asegurarlo dada la particular doble negociación LCP que se genera en I+. Tuve que desactivar cualquier tipo de compresión... no se si esto es general o afecta solamente a Linux. En cualquier caso es una pena...

    # Options file for ipppd.
    # ipppd will not read /etc/ppp/options or /etc/ppp/ioptions or any other
    # config file. Everything has to be in here.
    
    # "peer" is the name for our syncppp partner.
    
    # STANDARD OPTIONS
    
    debug                   # enable debugging
    kdebug 15       # set kernel debugging level to X
    #nodetach               # (no) fork to the background
    #callback X             # ask for callback (parameter X ?)
    #lock                   # create a lock file for device 
    #domain X               # add domain X to a given hostname
    #pidfile X              # save pid in file X
    #call X                 # take options from privileges file (???)
    #idle X                 # idle time limit (seconds)
    #holdoff X              # holdoff time limit (seconds)
    #maxconnect X           # set maximum connection time (in seconds ?)
    +mp                     # enable multi line ppp
    #+pwlog                 # log password (WARNING: possible security hole)
    #nomagic                # magic number negotiation
    
    # ppp handshake : tuning
    
    #silent                 # don't even try to initiate the connection
    #passive                # wait for the peer to initiate the connection
    #lcp-echo-failure X     # consecutive echo failures
    #lcp-echo-interval X    # time for lcp echo events 
    lcp-restart 1           # Set timeout for LCP 
    #lcp-max-terminate X    # Set max #xmits for term-reqs
    #lcp-max-configure X    # Set max #xmits for conf-reqs 
    #lcp-max-failure X      # Set max #conf-naks for LCP
    
    
    # AUTHENTICATION
    
    #name servidor          # set local name for auth
    user usuario@proveedor                      # set name for auth with peer
    #usehostname            # use hostname for auth
    #remotename infovia      # set remote name for auth
    noauth                  # (dont) require peer (the other) to auth
    #require-pap            # allow only pap authetication
    #require-chap           # allow only chap authentication
    #login                  # use system password database for pap
    #papcrypt               # pap passwords are encrypted
    
    # AUTHENTICATION TUNING
    #pap-restart X          # Set retransmit timeout for PAP 
    #pap-max-authreq X      # Set max #xmits for auth-reqs
    #pap-timeout X          # Set time limit for peer PAP auth.
    #chap-restart X         # Set timeout for CHAP 
    #chap-max-challenge X   # Set max #xmits for challenge 
    #chap-interval X        # Set interval for rechallenge
    
    # COMPRESSION
    
    #noaccomp               # address compression on/off
    #nopcomp                # protocol field compression on/off
    novj                    # van jacobsen compression on/off
    novjccomp               # van jacobsen connection-ID compression on/off
    #vj-max-slots X         # tune maximum vj header slots
    nobsdcomp               # bsd compression on/off
    nodeflate               # deflate compression on/off
    nopredictor1            # predictor1 compression in/off
    noccp                   # compression negotation on/off
    
    
    # IP NETWORKING
    
    #noip                   # en/disable ip transfer
    #X:Y                    # set local ip to X, remote ip to Y
    noipdefault             # don't use name for default ip addr
    #useifip                # use ip addresses form interface
    #usefirstip             # use first ip from auth file for remote
    #netmask X              # set netmask X
    defaultroute            # (dont) set default route 
    hostroute               # (dont) set host route
    #proxyarp               # (dont) set an proxy arp entry
    mru 1524                # set maximum size of recive units to X
    #default-mru            # disable mru negotation
    mtu 1524                # set maximum size of transmit units to X (1500 is OK)
    #useifmtu               # use mtu from interface
    #ipparam X              # set ip parameters in script X
    #ms-dns X               # dns address for the peers use
    #ms-wins X              # wins address for the peers use
    #set_userip             # define valid ip addresses in /etc/ppp/useriptab
    
    
    #ipcp-restart X         # Set timeout for IPCP 
    #ipcp-max-terminate X   # Set max #xmits for term-reqs 
    #ipcp-max-configure X   # Set max #xmits for conf-reqs 
    #ipcp-max-failure X     # Set max #conf-naks for IPCP 
    ipcp-accept-local       # Accept peer's address for us 
    ipcp-accept-remote      # Accept peer's address for it 
    
    # IPX NETWORKING
    
    #noipx                  # en/disable ipx
    #ipx-network X          # IPX network number 
    #ipxcp-accept-network   #  Accept peer netowrk
    #ipx-node X             # IPX node number 
    #ipxcp-accept-local     # Accept our address 
    #ipxcp-accept-remote    # Accept peer's address
    #ipx-routing X          # IPX routing proto number 
    #ipx-router-name X      # IPX router name
    #ipxcp-restart X        # Set timeout for IPXCP 
    #ipxcp-max-terminate X  # max #xmits for term-reqs 
    #ipxcp-max-configure X  # max #xmits for conf-reqs 
    #ipxcp-max-failure X    # max #conf-naks for IPXCP 
    

    (Rev.8 - albert@ordenatas.es)
    Al respecto de la Teles bajo linux, yo pensaba que no habian problemas, ya que siempre la habia probado contra Barcelona. Ahora estoy viendo que no funciona ni desde Valencia, Madrid, Bilbao... . Si desde estos puntos hago la llamada a Barcelona o Alicante, entonces si que va.

  • (Rev.8 - antoni@ibernet.com)
    Tengo problemas con usuarios que acceden a traves de RDSI tanto en Windows como en Mac. No hay forma humana de que conecten.

    Mas concretamente con Windows 95 y tarjetas Diva Sever BRI-2M.

    (Rev.8 - torri@futurnet.es)
    Solo comentarte que he observado algunos otros problemas con adaptadores RDSI Teles tambien en PC con W95.

  • (Rev.7 - jcea@argo.es) (Rev.7 - icordoba@skios.es)
    Desde el 4 de Enero de 1.999, los ordenadores Macintosh que utilizan "Open Transport", que es el stack TCP/IP nativo de Apple, no pueden conectar a Infovía Plus. Utilizando otros stacks parece que el problema se soluciona.

    (Rev.7 - hostmaster@entorno.es)
    Si nosotros tambien teniamos ese problema, aunque lo solucionamos sustituyendo el PPP (este por defecto autentica por CHAP segun su log e Ivia+ deberia permitir CHAP) del MacOS por el FreePPP (que este te permite la autenticacion por PAP), desde entonces todo va perfectamente.

    (Rev.7 - hostmaster@accesocero.es)
    Tengo un problema con un cliente que tiene Mac OS 8.1 que no consigue entrar en modo autentificado desde el 4 de Enero, bueno, la verdad es que entra y a los 4 segundos se corta. A mi me da error "2" pero a el le da error de autentificacion, aunque a mi si me aparece en el Radius (!?!?)

    No he podido probar a cambiarle el PPP ya que no lo tengo disponible, pero resulta que tampoco consigue entrar en modo anonimo usando el login "infoviaplus/infoviaplus". Se autentifica bien, dice que conectado con IP 193.152.24.XX (Barcelona), pero luego no trafica datos.

    Creo que debe haber algun problema subyacente aparte del CHAP ...

    (Rev.7 - antoni@ibernet.com)
    A partir del Lunes empezaron a fallar todas las conexiones a InfoVia Plus con Macintosh que utilicen OpenTransport PPP, es decir, todos aquellos que tengan MacOS 8.0 o superior. Al monitorizar el servidor de tuneles da el siguiente error:

    Thu Jan 7 06:25:05 1999 ERROR - PAP on Port !V28 failed - AuthRemoteUser

    En teoria OpenTransport PPP es capaz de negociar y trabajar tanto con autentificacion CHAP como PAP, pero en algun punto no se ponen de acuerdo. La manera que funcione es instalando otro PPP. Yo he probado con MacPPP 2.5 y conecta bien. Lo que no se si manana tambien funcionara.

    (Rev.7 - hostmaster@accesocero.es)
    Juan Manuel Lopez, coordinador de Red IP, me ha comentado que no tenia constancia de los problemas especificos con Macintosh, que los unicos cambios que ultimamente se habian hecho en Red IP eran de RIP porque habia excesivo trafico de propagacion de rutas, pero que no sabia nada de problemas con autentificaciones CHAP/PAP

    De todas formas, acabo de mantener una conversacion telefonica con el Responsable de Soporte Tecnico de Apple Computer en Madrid, una persona realmente amable, y me ha comentado que tienen constancia de que Telefonica esta teniendo problemas serios con un gran numero de servidores de acceso y que les han prometido oficialmente que se solucionara antes del 17 de Enero ...

    Me ha comentado que parece que existen problemas en muchos NAS que necesitan una actualizacion. Nodos de ciudades pequenas, como Granada o Mallorca, ya estan parcheados y aceptan sin problemas los accesos de los Macintosh, pero ciudades grandes como Madrid o Barcelona son tan complejas que seran las ultimas en ser modificadas.

    Parece ser que Open Transport o Remote Access inicia primero una autentificacion CHAP y no existe la posibilidad de ser reconfiguradas para que fuercen PAP. Los antiguos MacPPP o FreePPP usados en los tiempos de MacOS 6.X funcionaban solo con PAP. Linux entra sin ningun problema con PAP y casca la mitad de las veces si usa CHAP, por lo que -aparte de la doble autentificacion- puede ser una de las causas de los problemas ...

  • (Rev.8 - jcea@argo.es)
    Los usuarios de Windows 3.x y Macintosh tienen muchos problemas para conectar a través de Infovía Plus, tal y como se ha detallado en los párrafos anteriores.

    Telefónica ha reconocido el problema y proporciona varias "soluciones" en la página de kits de acceso, en http://www.ttd.es/nuevosip/kit_frames.htm.

    La solución que estamos usando muchos proveedores es utilizar stacks TCP/IP mejores que los que vienen con Windows 3.x. Una solución es usar Trumpet. Otra solución es usar el dialer que viene, por ejemplo, con el IEK (Internet Explorer Kit).

    Para Apple, Telefónica propone crear un script de conexión, como puede verse en su web. En muchos casos resulta más sencillo, sencillamente, el utilizar un stack alternativo al de Apple.

    (Rev.8 - antoni@ibernet.com)
    Con Windows 3.11 necesitas el Software de InfoVia 2.3 o 2.3.1 e instalar un servidor ftp anonimo en tu red con direccion 10.0.1.1 y un sistema de directorios determinado. TTD tiene que hacerte una ruta en el Terminador de Tuneles para que los usuarios de InfoVia puedan ver la direccion 10.0.1.1. Pide toda la info a TTD.

    Con MAC, puedes mirar diferentes configuraciones en:

    http://www.ibernet.com/infoviaplus/macplus.htm

    Funcionan ambos sistemas, salvando los problemas intrinsecos de InfoVia Plus.

    (Rev.8 - admin@ceca.es)
    De este tema ya se ha hablado en anteriores ocasiones en la lista.

    Antes de realizar los cambios para pasar de I a I+, TTD envió a todos los proveedores (por lo menos a nosotros si) un CD titulado Documentación para CPI's y Kit de Usuario. Servicios IP, en este cd uno de los apartados dice : Acceso a I+ con el soft. 2.3 de InfoVía y Windows 3.11. Aunque no se extiende en detalles, te dice lo que hay que hacer.

    Tienes que montar un servidor ftp en alguna de tus máquinas con la ip 10.0.1.1, con un directorio /pub/arranque en el cual tengas un directorio con el nombre de tu cpi, y dentro de el dos ficheros uno llamado arranque con contenido (Location: http://casyc.inf/default.htm) y otro dns con contenido (194.222.nn.nn). Debes permitir el ftp anónimo.

    Una vez que tengas esto te tienen que poner en tu router una ruta para que cuando alquien pregunte por la máquina 10.0.1.1, la mande a la parte interna de tu red y pueda encontrar ese servidor.

    Con esto configurado, el acceso a I+, con Win3.11 y con el soft InfoVía 2.3, funciona correctamente.

    Probado en el día de ayer.

    (Rev.8 - admin@ceca.es)
    Poner un fichero de texto con nombre arranque y con contenido (Location: http://xxxx.inf/default.htm) Lógicamente aquí se debe poner la home page a la cual querais que el cliente acceda la primera vez que realice la conexión, por tanto debe ser una url de internet, imagino que el servidor vuestro. Y en el otro fichero de texto con nombre dns con contenido (194.222.nn.nn), vuestro DNS.

    Estas son las dos cosas que el Soft. de I, entregaba al cliente cuando realizaba la conexión.

    (Rev.9 - lsore@maresme.net)
    Si el PPP de Apple no te va, puedes probar FreePPP en http://www.rockstar.com/ppp.shtml (aunque a veces también falla). A mí me ha resuelto el problema con un cliente que tiene un modem RDSI.

    (Rev.9 - padin@corevia.com)
    Yo si he conseguido conectarme con windows 3.11. y la pila de Microsoft osea lo del shiva, pero la forma de acerlo es a pedales o mano, como mejor os guste.

    Os describo los pasos:

    1.- Hacemos doble clip en el icono que tengamos para la conexion.

    2.- damos en opciones

    3.- marcamos la ultima casilla, que pone algo asi como abrir ventana despues de marcar y damos a aceptar

    4.- Pulsamos en marcar y nos marca y despues de marcar no abre la ventana y pulsamos enter.

    5.- Nos dice alga asi como Telefonica -Red IP y no pide el login.

    6.- Ponemos el nombre de usuario@proveedor

    7.- y con algunos nodos nos sale otro prompt pidiendo la clave, en otros nodos simplemte nos salen unas cosas raras, pero da igual, ponemos nuestra clave, aqui no nos devolvera el echo, osea no sale ni asteriscos ni nada, damos intro y alehooopppp, ya nos sale nuestro ip del servidor de tuneles.

    8.- Y damos continuar en la opcion de la ventana

    Solo he podido dedicarle unos 10 minutos a esto, de todos modos dentro del directorio donde intala todo esto, esisten unos ejecutables llamados algo asi como eiscript.exe y script.exe, a lo mejor con eso se podria hacer automatico, si lo haceis decirmelo.

  • (Rev.9 - angel@stalker.es)
    Hola a todos, tengo un problema con una tarjeta RDSI para conectarme a I+. El modelo es Compaq Microcom 610 ISDN y en Infovia conectaba bien. ¿Alguien ha tenido el mismo problema y ya lo ha resuelto?

  • (Rev.9 - info@surnet.es)
    Tengo un cliente con NT Server que no puede conectar con nosotros vía RDSI. Tiene un adaptador -Hayes Accura ISDN-. Falla la autentificación vía I+. En cambio como anónimo -infoviaplus/infoviaplus- si conecta.

    (Rev.9 - webmaster@macom.es)
    Intenta reducir la longitud de la clave o del nombre de usuario, sorprendentemente yo lo conseguí así con un par de usuarios.


Routers RDSI

Existen multitud de routers que no son capaces de autentificar ante un CPI, pero que consiguen conectar perfectamente a Infovía Plus de forma no autentificada. ¿Alguien tiene volcados de debug del problema?. Personalmente no he estudiado el tema, aunque puede ser debido (especulo):

  • Timeout de la autentificación del Router.

  • El túnel intenta negociar opciones desconocidas por el router y uno de los dos decide colgar.

  • Telefónica, cuando hace de pasarela hacia el CPI (I+), intenta autentificar dos veces, y al router no le gusta.

  • Telefónica intenta autentificar sin haber terminado la negociación LCP.

  • ¿Otra posibilidad?

Se agradecen más detalles.

(Rev.5 - txuso@nexnet.es) TTD ha creado una página en la que se puede obtener las versiones actualizadas del S.O. de los routers RDSI, para que sean compatibles con Infovía Plus.

En este momento los Routers que parecen dar problemas son, al menos, los siguientes:

  • Intel 8100

    (Rev.3 - alberto@ccoo.es)
    Si se configura el enlace para que sea "single" y no Multilink PPP, funciona.

    (Rev.9 - jcea@argo.es)
    He recibido una copia de la versión er8100i_320i del sistema operativo del Intel 8100. Al parecer esta versión es compatible con Infovía Plus. El remitente me escribe: (Jesus.Maximoff@intel.com)

    Jesus,

    Te remito el patch de actualizacion para los routers de intel, en caso de que puedas ponerlo en tu pagina referente a Infovia +. Si esto no fuera posible podrias dirigir a las personas que leen tus paginas a los distribuidores de estos productos. Muchas gracias de antemano.

    Jesus Maximoff
    Networking System Engineering
    Jesus.Maximoff@intel.com

    No pongo el parche en mi web porque ocupa 2 Megabytes. Os podeis dirigir a los distribuidores o al propio Jesús Maximoff.

  • Intel 9300:

    (Rev.10 - jlfernandez@fimac.net)
    Tenemos conectadas diversas oficinas en Granada,Sevilla,Palma y Murcia conectadas con routers intel 9300. Mientras funcionaba infovia podian conectar sin ningun problema. Intente varias veces antes de que venciera el plazo del 17 de enero probar con la conexión del nodo local sin exito. Curiosamente instale uno en mis oficinas de Madrid y funcionaba sin problemas, probe en los demas a traves de I+ y seguia sin funcionar.

    Pense entonces que deberia ser un problema de los nodos locales y tras pasar la incidencia a telefonica, supuse que el problema se solucionaria cuando pasara la primera avalancha de I+.

    Una vez conseguido hablar con tecnicos de I+ me comentaron que los nodos de acceso de Madrid y del resto de España son diferentes y que los servidores de tuneles locales podian tener la incidencia de enganchar usuarios a traves de RDSI. Me hicieron probar que llamara al nodo de Merida desde el router que tengo en Granada sin llegar a ningún tipo de solución.

    Despues de 2 dias me llamaron y me dijeron que cambiara el valor del nombre del router por Usuario@fimac y que enablara el CHAP para ver si así funcionaba, todo lo cual me da un resultado negativo.

    Creo que nadie en la lista tiene routers de este modelo ya que he mandado un par de mensajes sin exito.

    Puede alguien arrojar algo de luz al respecto... El radius lo tenemos instalado en una maquina con FreeBSD con la versión del Radius que proporcionó en su dia Telefonica.

    Alguien ha pasado por el mismo problema de que una configuración funcione perfectamente en Madrid y que en el resto de España no vaya?

  • NAUTICA 200 de Bay Networks
    Ver la sección de routers que SI funcionan.

  • Netgear RT328 de Bay Networks

  • Cisco 760

    Hay proveedores que no tienen problemas con los Cisco. Cuando no funciona, tampoco funcionan las llamadas de modem normales (Rev.2 - jgomez@canaldata.es)

  • Clam

  • 3Com OfficeConnect Remote 5x0 / 5x1 (Rev.2 - jverde@red3i.es)

    (Rev.6 - xavi@caballe.com)
    3Com también dispone de una actualización para los OfficeConnect 5x1:

    http://www.3com.es/products/5x1_serie.htm

    (Rev.8 - jverde@red3i.es)
    Cambia el soft:
    http://www.3com.es/products/redip.htm

    (Rev.9 - hostmaster@dracnet.es)
    Ademas, recuerda que has de ir a configurar uno de los puertos ISDN, hacer el lcp y activar los magic numbers. ^E para salir, y antes de hacer save, escribe reset. Y solo a uno de los puertos. Si lo haces a los dos, o haces un save antes del reset del puerto o alguna cosa similar, el router se vuelve lelo (soy especialista en hacerlo...) y necesitas resetearlo por hard, volver a los standards de fabrica y volver a empezar.

  • D-Link DI-106 (Rev.3 - hostmaster@bemarnet.es)

    (Rev.3 - juanjo.listas@doblej.net):
    Acabo de probar el D-Link DI-106 con I+ y funciona. La unica pega es que va lentiiiiiiiiiiiiisimo. La misma conexion por Infovia y va mas decentemente.

    (Rev.10 - microbyr.tec@ncsa.es)
    Hola Jesús,

    Soy el director técnico de Micro ByR, distribuidor de D-Link de siempre y ahora de ZyXEL. Hemos estado trabajando con nuestro routers, todos los modelos, tanto de D-Link como de ZyXEL (Mismo WAN controller) y tenemos el software actualizado y testeado con Infovia Plus.

    El software, para todos aquellos que lo precisen (tenemos muchos clientes en toda España que no lo necesitan) está disponible en nuestra ftp:

    ftp.microbyr.com

    Sólo hay que ir a la carpeta de D-Link o ZyXEL, coger el "firmware" y leel el fichero LEEME.TXT.

    Por favor, anuncialo en tu estupenda página.

    Gracias y saludos.

    Antonio Cebrian
    Departamento Tecnico
    microbyr.tec@ncsa.es

  • (Rev.8 - webmaster@ibercom.com)
    Tenemos un router Compaq Microcom 808 y nos es imposible conectar a Infovía Plus.

Routers que sí funcionan

  • Zyxel prestige 100 y el 100 IH (Rev.2 - cgalve@hipocom.es)

    (Rev.8 - cgalve@ipocom.es)
    Por si quieres actualizar la lista de problemas comentarte que esta mañana he conseguido hacer que funcione un router zyxel prestige 100 IH (yo mismo di el aviso de que no funcionaban con infovia plus). La solución ha sido actualizar a la ultima version del firmware y ya ha funcionado casi perfectamente (salvo los errores más normales de Infovia Plus).

    (Rev.9 - cgalve@ipocom.es)
    Siento decirlo pero... han debido cambiar algo en los nodos habituales de mis clientes por que otra vez no me entran los clientes que tienen el router zyxel prestige 100/100ih

    Es duro, muy duro...

    (Rev.10 - microbyr.tec@ncsa.es)
    Hola Jesús,

    Soy el director técnico de Micro ByR, distribuidor de D-Link de siempre y ahora de ZyXEL. Hemos estado trabajando con nuestro routers, todos los modelos, tanto de D-Link como de ZyXEL (Mismo WAN controller) y tenemos el software actualizado y testeado con Infovia Plus.

    El software, para todos aquellos que lo precisen (tenemos muchos clientes en toda España que no lo necesitan) está disponible en nuestra ftp:

    ftp.microbyr.com

    Sólo hay que ir a la carpeta de D-Link o ZyXEL, coger el "firmware" y leel el fichero LEEME.TXT.

    Por favor, anuncialo en tu estupenda página.

    Gracias y saludos.

    Antonio Cebrian
    Departamento Tecnico
    microbyr.tec@ncsa.es

  • Cisco 761 (Rev.2 - jgomez@canaldata.es)

    (Rev.3 - root@canaldata.es)
    Como veo que se siguen cruzando mensajes sobre la autenticación que hay que hacer con los Cisco 761 repito:

    Las líneas de autenticación que hay que poner son:

    set ppp auth out none
    set ppp pass client

    Olvidaros de poner CHAP o PAP. Si lo haceis intentará hacer autenticación bidireccional y os fallará. El none significa que no intente autentificar a InfoVía, pero responderá a la autenticación que infoVía le solicite.

    (Rev.3 - root@canaldata.es)
    Siento negar lo que dices, pero a mi me funciona el Cisco 761 con sólo cambiar el número de teléfono. Por cierto, como ampliación a mi anterior mensaje, acabo de migrar a dos usuarios que tenían el soft 4.1.1. Esto quiere decir que virtualmente todas las versiones de soft para Cisco 761 que andan por ahí rulando funcionan correctamente con InfoVía Plus. Esto es porque las versiones anteriores a la 4.1.1 tenían un problema con la MTU que daba muchísimos problemas, de forma que todo el mundo debe tener actualizada la versión por viejo que sea su router.

    El 761 funciona con InfoVía Plus. Otra cosa es que InfoVía Plus funcione.

    (Rev.8 - fede@limit4.com)
    Por si te interesa, hoy lunes 18/01/99, despues de cargar el software para el Cisco 761 que TTD publica en su Web, he seguido sin poder conectar con mi ISP a traves de INFOVIA Plus.

    Finalmente he podido conectarme con la configuración standard que viene en el manual del Cisco, añadiendo la siguiente opcion a nivel de sistema

    SET PPP MULTILINK OFF
    

    No se si con la version anterior y desactivando multilink hubiera funcionado.

  • Cisco 7xx (Rev.3 - dserena@nova.es)

    Os paso las "soluciones" que he conseguido para que esto casi funcione....

    Desde que te configuran el servidor de tuneles para que solo use PAP (por defecto intenta CHAP, y luego PAP), todo va "muuuucho" mejor.

    Desde que lo han hecho, hay llamadas que fallan pero parece que el % de fallos disminuye (aunque es aun insufrible).

    Los Cisco 700 (todos los 76x y 77x) me han entrado haciendo las modificaciones seguientes:

    A nivel de sistema pones los valores de negociacion del PPP por las nubes (el router se queja de que le des esa pasada de valores, pero se los traga), y le dices que no rechaze intentos de CHAP:

    SET PPP CHAPREFUSE NONE
    SET PPP NEGOTIATION INTEGRITY 60
    SET PPP NEGOTIATION COUNT 100
    SET PPP NEGOTIATION RETRY 3000

    Dentro del perfil de llamada, se suele dar solo PAP, y como de primeras se intenta hacer saltar CHAP, da un error de que no encuentra la contraseña, por lo que hay que indicarsela en ambos campos.

    SET PPP CLIENTNAME usuario@loquesea
    SET PPP PASSWORD CLIENT contraseña <-- PAP
    SET PPP SECRET CLIENT contraseña <-- CHAP

    Con esto he conseguido que entren siempre (siempre que me llega desde Infovia la peticion de autentificacion, que algun dia supongo haran que nos lleguen el 100% de las peticiones).

    El router ha de tener S.0. Version 4.1.2 o superior (yo he probado con la 4.1.2 y la 4.2.2)

    Aparte, para sacar todos estos problemas (ver si llega al servidor de tuneles la autentificacion - bastantes veces no lo hace -, etc.) lo mejor es conectar un cable a la consola del servidor de tunels y ver que debug va dando (al menos en el mio me aparece cada intento de autentificacion, desde donde viene, si se crea o no el tunel, la causa, etc.).

  • Shiva

    Estos routers pueden utilizarse cambiando su configuración (Rev.2 - padin@corevia.com):

    Hola:

    Como ya lo comunique a lista de proveedores de rediris, el error del shiva accessPort es que intentar negociar dos veces el nombre de usuario y contraseña, te paso la solucion:

    Cambio para conectar a INFOVIA PLUS con SHIVA AccesPort:

    Entramos en la configuracion por comandos

    AccessPort: net isdn2 ppp
    Circuit name : corevia
    Use default circuit's configuration (no) :
    Link Quality Management Request (disabled) :
    Echo request timer in seconds <1 - 10> (5) :
    Echo frames allowed to be lost <2 - 4> (4) :
    TENEMOS QUE CAMBIAR LA SIGUIENTE OPCION, por defecto trae no , tenemos que poner YES
    Ignore LCP number errors (yes) :
    Peer is Shiva device (no) :
    Restart timer in seconds <1 - 16> (3) :
    Maximum number of Configure-Requests sent <1 - 10> (10) :
    Maximum number of Configure-Naks sent <1 - 5> (5) :
    Maximum number of Terminate-Requests sent <1 - 2> (2) :
    Y salvamos la configuracion
    AccessPort: b
    Do you wish to restart the unit now (no) :YES

    (Rev.3 - hostmaster@entorno.es)
    Seguro ??????? Yo lo probe y aunque conectes no acaba de rular porque... el hecho que inhabilites el chequeo del LCP te permite "parecer" conectado aunque no lo esteis... habeis probado a enviar algun paquete y digo esto, porque en -ayer estuvimos en contacto con ellos- Shiva (Canada) estan trabajando en nuevo firmware (han reconocido que su PPP no standard 100 por 100) y que lo enviaran a los distribuidores Españoles (Santa Barbara, etc..) antes del 1 de Diciembre..

    (Rev.5 - hostmaster@entorno.es)
    Para aquellos que tengan Shiva Accesport, me ha llegado de Canada (SHIVA) el nuevo firmware (release 3) para Ivia+ y este funciona bien 100x100.

    El que lo necesite (o crea que lo necesite) que me envie un email.

    (Rev.10 - xamill@agsistemas.es)
    Sobre el Shiva Acces Port /D , solo mencionar que a dia de hoy ya estan disponibles las firmware (version 2.11) totalmente compatibles con Infovia+. Para solventar los problemas solo es necesario actualizar la firmware a traves de la opcion correspondiente. Remarcar que existen dos modelos diferentes de firmware , segun el modelo de Shiva y la cantidad de memoria que incorpora,pero de todos modos, el Shiva Monitor solo nos dejara actualizarla si es la correcta.

  • Bay Networks

    (Rev.6 - rivas@caymasa.es)
    Me han funcionado los routers RDSI NAUTICA MARLIN y NAUTICA 200 conectando a InfoviaPLUS, entrando por Sevilla y teniendo en el servidor de tuneles, la version S20 de los pequeños y CHAP habilitado.

    La configuracion debe ser:

    Nombre del router (System Name): usuario@proveedor
    Telefono: 954547000 (Sevilla)
    PATH Name: InfoviaPLUS
    Authentication Name: usuario@proveedor
    PPP Profile: CHAP
    CHAP Password Out: *******

    Tambien funciona poniendo:

    Nombre del router (System Name): usuario@proveedor
    Telefono: 954547000 (Sevilla)
    PATH Name: InfoviaPLUS
    Authentication Name: usuario@proveedor
    PPP Profile: Either
    PAP Password Out: *******
    CHAP Password Out: *******

    Es chungo que haya que poner como Nombre del Sistema: usuario@proveedor, pero eso es lo que hay por ahora.

    (Rev.9 - info@knet.es)
    En http://support.baynetworks.com/ encontraras las 5.016R compatible con I+, aunque en esa web ya esta la 5.514R, aun no la he probado.

  • (Rev.8 - torri@futurnet.es)
    Respecto a routers, comentarte que el CBra de Teldat funciona bien actualizando el software a la version disponible en http://www.teldat.es/productos/internetworking/cbra.asp#Versiones.

  • (Rev.8 - jordi@t800.grn.es)
    Tengo otra experiencia con un router Cisco 2503 y la conexión a Infovia Plus por el puerto RDSI. Con versiones del software IOS 11.3.1 e inferiores el aparato no conecta. Con la versión 11.3.7 si lo hace. No es ninguna versión específica para I+, puesto que se ha descargado de Cisco.com.

    La autentificación se realiza mediante el protocolo CHAP. Me han comentado que esta ultima versión también admite MSCHAP.

    El aparato está configurado para que mande su nombre de máquina como nombre de usuario.

  • (Rev.8 - info@knet.es)
    En nuestro servidor de tuneles esta activado el chap y para que caminen algunos Cisco 1603 que tenemos hemos tenido que poner en el dialer:
     ppp authentication chap
     ppp chap hostname usuario@knet
     ppp chap password 0 contraseña
    

    y funciona.

  • (Rev.8 - root@gna.es)
    Hola Jesus, no funciona. Y lo he probado en 2 nodos diferentes. Se me olvida algo... Tengo:
    hostname usuario@cpi
    ...
    NO tengo usernames definidos
    ...
    interf BRI0
    encapsulation ppp
    dialer idle-timeout 240
    dialer string 932345000
    dialer-group 1
    ppp authentication chap
    ppp chap hostname usuario@cpi
    ppp chap password 0 contrasena
    

    y ahi se acaba. Luego tengo al dialer-group con permiso para ip y las rutas hacia BRI0.

    (Rev.8 - root@knet.es)
    Esta es la configuracion que yo utilizo. Tampoco entiendo mucho, pero funciona

    !
    version 11.3
    no service udp-small-servers
    no service tcp-small-servers
    !
    hostname cisco7
    !
    enable secret 0 xxxxxx
    enable password xxxxxx
    !
    ip nat inside source list 101 interface Dialer1 overload
    isdn switch-type basic-net3
    !
    interface Ethernet0
     ip address 192.168.0.1 255.255.255.0
     ip nat inside
     no ip mroute-cache
    !
    interface BRI0
     description infovia
     no ip address
     encapsulation ppp
     dialer pool-member 1
    !
    interface Dialer1
     ip address negotiated
     ip nat outside
     encapsulation ppp
     dialer remote-name infovia
     dialer idle-timeout 3600
     dialer string 941498000
     dialer pool 1
     dialer-group 1
     ppp authentication chap
     ppp chap hostname usuario@knet
     ppp chap password 0 contraseña
    !
    router igrp 1
     redistribute connected
     network 192.168.0.0
    !
    no ip classless
    ip route 0.0.0.0 0.0.0.0 Dialer1
    ip route 195.76.176.0 255.255.255.0 Dialer1
    access-list 101 permit icmp any any
    access-list 101 permit ip any any
    snmp-server community public RO
    dialer-list 1 protocol ip list 101
    !
    line con 0
    line vty 0 4
     password xxxxxx
     login
    !
    end
    

    Para que funcione la configuracion es necesario 11.3 y ip-plus, ya que dicha configuracion contempla ip negociada y nat.

    (Rev.9 - root@gna.es)
    El problema que tuve con el 1603 IOS 11.1 lo solucioné haciendoles quitar el CHAP del servidor de tuneles. No tuve que modificar nada en la configuración salvo en el numero de telefono del nodo de IV+ en el dialer string:

    interf BRI0
    encapsulation ppp
    dialer idle-timeout 240
    dialer string 932345000
    dialer-group 1
    ppp authentication pap
    ppp sent username usu@cpi password 0 xxx
    

Servidor de Túneles

  • A veces la única forma de que el servidor de túneles vuelva a funcionar correctamente es apagándolo y volviéndolo a encender (Rev.2 - svt@svt.es)

  • Existen dos versiones del servidor de túneles. Uno admite sólo 48 conexiones simultaneas, y el otro 512. Según dice la gente de Telefónica, el poner uno u otro ha sido una decisión tomada "monitorizando" el acceso de cada CPI durante una semana.

    El problema es que nadie nos ha dicho nada. Si tenemos el servidor de túneles de 48 y dentro de dos semanas contratamos una VPN de 40 nodos, nos podemos encontrar que no conseguimos que funcione correctamente y no seremos capaces de detectar la razón.

    Por tanto, ojo :-)

    (Rev.6 - jcea@argo.es)
    > > Dado que hay modelos de 512 y que no existen 512 nodos en Infovía
    > > Plus, asumo que ese valor se corresponde al número de usuarios
    > > concurrentes que soporta, no el número de nodos de acceso.
    >
    > Hay mas de un AS por nodo (no en todos) ;)

    Excelentísima precisión, Juan Antonio. Probablemente se trate de eso. Cada AS abre un túnel, dentro del cual (con túneles lógicos) encapsula a sus usuarios.

    Por lo que veo de un rápido vistazo al borrado de estándar, cada AS abre un túnel con el 3COM y, dentro de él, establece una sesión por cada usuario que esté sirviendo.

    Ahora la duda está en... ¿el límite es de 48 túneles (48 AS simultaneos) o de 48 sesiones (48 usuarios)?.

    A saber...

    (Rev.8 - hostmaster@entorno.es)
    Bueno..comprobado y requetechequeado y confirmado por la gente de TTD que sabe algo de esto. Es un tunel por USUARIO con lo cual solo se puede tener 48 o 512 concurrencias.

  • Algunos servidores de túneles están configurados para aceptar CHAP en la negociación LCP, lo que da problemas con el RADIUS y con muchos routers.

  • La conexión actual entre los nodos I+ y el servidor de túneles es mediante PPTP. ¿Algún día se migrará a L2TP?. Ello permitiría utilizar hardware de proveedores alternativos. L2TP es, también, un protocolo más avanzado (por ejemplo, en el control de flujo y en utilizar protocolos IP estándares, y no el GRE)

  • Tras un tiempo de conexión (variable pero corto) la transferencia de datos se bloquea.

  • (Rev.6 - jcea@argo.es)
    A los proveedores que disponen de la versión "grande" (DPE) del servidor de túneles se les ha instalado la versión S22 del sistema operativo, que deja muchas menos sesiones "colgadas". Los proveedores con modelo NBSI siguen con la versión S20.

    (Rev.8 - hostmaster@entorno.es)
    Pero esto ya lo saben en TTD desde hace tiempo. Y efectivamente los TotalControl de 3COM dejan COLGADAS las RDSI, mientras que si tienes suerte y sigues pillando alguno de nuestros viejos conocidos (Ascend Pipeline) va bien !. Estan actualizando los soft de los 3COM con la prisa que pueden !! 8((((

    (Rev.10 - jcea@argo.es)
    Los proveedores con servidor de túneles DPE están siendo actualizados a la versión S32 del software. Previamente se habían instalado las versiones S20, S22 y S29. Algunos proveedores están experimentando ya con la versión S39 del sistema.

    Los proveedores con servidor de túneles NBI siguen con la versión S20.

  • (Rev.6 - karlos_fx@svalero.es)
    >El usuario que intenta conectarse no lo consigue, y recibe el error de
    >"reintente cambiando el password"

    Si, eso es un error comun y se soluciona facilmente, el login del usuario no puede tner nunca 8 caracteres justos, o mas o menos pero nunca exactos y procura que no pasen de ocho para mas seguridad.

    (Rev.6 - jcea@argo.es)
    Yo no he tenido problemas con usuarios con clave de longitud 8 caracteres.

  • (Rev.8 - info@costasol.net)
    El "nuevo" problema que detectamos en Infovía Plus es que algunos usuarios acceden desde una línea analógica y el radius los echa fuera porque cree que acceden por RDSI.

    Además, no siempre les pasa a los mismos usuarios, y no a todos... y no siempre... Pero a algunos casi siempre.

  • (Rev.8 - hostmaster@dracnet.es)
    ¿Alguno de vosotros asigna a algún usuario todo un rango de IPs fijas?. Osea, la máscara no es 255.255.255.255, sino algo tipo 255.255.255.252.

    Es que por Infovía antigua funciona perfecto, pero por Infovía Plus no hay manera.

    (Rev.8 - dherrera@audifilm.com)
    Nosotros tenemos CISCOs con IOS 11.X y CISCOs de la serie 7XX con esa configuración (en concreto máscara 255.255.255.252).

    Los 7XX aún no los hemos migrado, los IOS 11.X se conectan y funcionan bien es este sentido.

    No obstante tenemos MUCHOS problemas, ej:

    • El router esta conectado al número de teléfono de Iplus en cambio no aparece en el radius como usuario conectado.

      Este problema tiene dos causas:

      • Infovía plus lo ha desconectado pero no le ha enviado señal al router.

      • La negociación ppp no acaba nunca (seguramente por "usuario sin sesiones" o alguna cosa parecida").

    • Los otros problemas ya os los sabéis.

    (Rev.8 - jcea@argo.es)
    Haz una prueba: define una ruta en tu servidor para que encamine todos los paquetes para esa subred hacia el servidor de túneles. Si eso funciona, el problema es que el servidor de túneles no hace "proxy-ARP" de subredes, sino exclusivamente de IPs.

    Pruébalo.

  • (Rev.9 - jcea@argo.es)
    Algunos nodos de Infovía Plus parecen tener problemas de MTU y fragmentación IP, lo que hace que una transferencia de un volumen de información mediano dé problemas. Lo curioso es que no ocurre con todos los nodos de I+, sino sólo con algunos (por ejemplo, Pamplona).

    Para probar si el problema se debe a esta causa, se siguen los siguientes pasos:

    1. El usuario se conecta a través de Infovía Plus, usando el nodo problemático, e intenta descargar la información desde nuestro servidor (por ejemplo, email).

    2. Si la descarga no tiene éxito, modificamos la MTU de nuestro servidor a un valor inferior a 1500 bytes. Por ejemplo, 1300 bytes o menos.

    3. Repetimos el paso (a).

    4. Si ahora la descarga sí que funciona, tenemos un problema de MTU.

    En el caso en que se compruebe que que efectivamente estamos ante un problema de MTU, no basta con usar un valor reducido en nuestros servidores, ya que cuando el usuario intente descargar información de servidores externos (navegación web, FTP, etc.) se encontrará con el mismo problema.

    La solución pasa, en cambio, por modificar los parámetros MRU del servidor de túneles, de forma tal que se evite fragmentar las tramas encapsuladas en el túnel, ya que parece que hay routers intermedios (o el propio NAS final) que tienen problemas con la fragmentación. De esta forma las tramas PPP no se fragmentan nunca. Todo lo más, se fragmenta el datagrama IP antes de ser encapsulado en el túnel.

    (Rev.9 - radamuz@infoservei.es)
    Os envio la solucion que os comenté ayer para los cuelgues del correo derivados de la gestion del mtu por parte del router 3com de Infovia Plus.

    Lo primero es comprobar que efectivamente, este es nuestro problema.

    Para ello a una IP conectada a vuestro servidor enviadle un paquete del tamaño que por defecto envia el nt 1472 bytes, algo así

    ping -f -l 1472

    El -l es el tamaño del paquete y el -f es para que no lo trunque.

    Si os devuelve una respuesta correcta buscad por otro sitio, no teneis aqui el problema, si os devuelve un error, el tipico "request time out" u otro, vamos bien.

    Enviad otro paquete mas pequeño (el minimo es 576), si la respuesta es correcta entonces si, la cosa va por aqui.

    Habeis de añadir al registro del servidor NT la siguiente linea, esto le hará ir ajustando los paquetes hasta que encuentre el optimo.

     HKEY_LOCAL_MACHINE
     \SYSTEM\CurrentControlSet\Services\tcpip\parameters
     \EnablePMTUBHDetect : REG_DWORD: 0x1
    

    O sea, el campo EnablePMTUBHDetect a enable (1)

    (Rev.9 - jsalas@alcavia.net)
    SOLUCIONADO:

    Pero hay que intervenir en los clientes, solo hay que ajustarle el tamaño del MTU a 512 o 600 bytes y funciona perfecto.

    En Windows NT:

    HKLM\SYSTEM\CCS\Services\NdisWAN\parameters
    

    añadir IPMTU (Dword)=600 (decimal)

    En Windows 95-98

    HKLM\SYSTEM\CCS\services\class\net\000X
    
    (donde X es la interfaz que lleve el acceso telefonico a redes), IPMTU=600

    Con esto funciona perfecto, no es para romper campanas, pero mis clientes estaban haciendo acceso a nuestro nodo local a 3.000 ptas hora.

    (Rev.9 - jsalas@alcavia.net)
    Atencion, correccion al mail de ayer.

    La entrada IPMTU (Dword) hay que añadirla, ya que en NT no suele estar y en 95 no siempre.

    Para que sea "efestiva" en Windows NT hay que tener puesto el SP-4, o el "Post-SP3 Wan-fix", y claro como no le va hasta que no baje el MTU, no se los puede bajar.

    HKLM\SYSTEM\CCS\services\class\net\000X, significa para los menos eruditos HkeyLocalMachine\System\CurrentControlSet.....

    (Rev.9 - listaprv@accesocero.es)
    Te aconsejo que uses un software freeware, PPP Boost 1.4, que lo hace solo automaticamente. Yo lo estoy recomendando a los clientes mas desesperados, pero aun asi, tengo a gente con RDSI que va a 0.3 kb/s mientras que por modem funciona mucho mejor (?). Lo puedes encontrar en:

    http://www.demonweb.co.uk/c3sys/ppp.htm.

  • Identificación de la versión del servidor de túneles
    (Rev.10 - hostmaster@danysoft.es)

    Yo utilizo una forma sencilla.

    Abres una conexion desde el Hyperteminal (si utilizas W9x) o el minicom en linux, poniendo como número de teléfono un nodo de Infovía. Entonces te pide usuario, pones el acrónimo del proveedor correspondiente, y un password. Te sale una serie de código entre el que se encuentra el tipo de máquina y la versión del software.

    Ha fecha de hoy, se puede ver que hay de todo (no he puesto a quien pertenecen), pero por mi pequeña estimación abunda más el S32 (sobretodo entre los más grandes)

    VI=3COM SP=SW/NBDPE-DW,11.1.0.00S32 SV=version 11.1.0.00S32
    VI=3COM SP=SW/NBDPE-DW,11.1.0.00S22 SV=version 11.1.0.00S22
    VI=3COM SP=SW/NBDPE-DW,11.1.0.00S29 SV=version 11.1.0.00S29
    VI=3COM SP=SW/NBSI-CF,11.1.0.00S20 SV=version 11.1.0.00S20

RADIUS

  • El SNMP del servidor de túneles no proporciona un lista de usuarios "tunelizados", por lo que es imposible sincronizar el Radius con el servidor de túneles (situación típica si una de las dos máquinas se reinicia, por ejemplo).

  • No funciona el Timeout por inactividad.

  • No funciona el tiempo límite de conexión para el usuario.

  • No se puede desconectar a un usuario usando el "radtool". Algunos proveedores dicen que sí pueden. ¿Acaso depende de la versión de servidor que se tenga? (Rev.3 - hostmaster@entorno.es):
    rad_tool desconectar_usuario
    rad_tool reutilizar_direccion

    Esta ultima fuerza su devolucion al pool.

    Y ENTONCES y SOLO ENTONCES es liberada.

    (Rev.4 - jcea@argo.es)
    Con el procedimiento anterior, la IP es marcada como libre en el RADIUS, por lo que puede ser asignada a otro usuario nuevo. No obstante la sesión del usuario primitivo sigue funcionando sin ningún tipo de problema. Puede navegar, usar el correo, etc. A todos los efectos, sigue conectado.

    Por tanto, lo anterior no funciona. Aunque nos salga en el RADIUS que el usuario está desconectado, realmente sigue activo.

    (Rev.8 - carlos@develnet.es)
    Quiero hacer un comentario sobre la opción reutilizar_direccion de rad_tool. Resulta que dicha opción sólo libera la dirección del pool, es decir, que con ver_status no ves al usuario conectado. Sin embargo (y probadlo si no lo creeis) si el usuario no ha colgado, puede seguir navegando y la IP sigue enrutada (con un ping lo podreis probar). Si por un casual entra otro usuario y se le asigna esa IP, pues a la porra los dos.

    Por otra parte, para los usuarios que tienen IP fija el problema es mayor, ya que siempre que intente conectar se le asignará la misma IP y se montará la repera.

    Después de mucho pegarme con la gente de telefónica resulta que no es posible desconectar realmente a los usuarios, y esto es un fallo de los 3COM que intentan que en la próxima versión se resuelva con una variable SNMP. Me parece que esto es un fallo en el diseño del servicio que se les ha pasado y que hace que una migración plana desde INFOVIA no sea posible (por lo menos no tan fácilmente como dicen ellos).

    Lo que me sangra un poco es que la gente del 902 11 35 24 te siga diciendo que con rad_tool reutilizar_direccion se desconectan a los usuarios. Digamos que no aparecen con ver_status y hacen que nos callemos de momento. Así que la idea que saco yo es que o no saben (pues vaya confianza en el servicio que me dan) o me quieren engañar para que me calle (tres cuartos de lo mismo).

    Bueno, podríamos hacer una compra conjunta de pastillas anti-stress :-)

  • No funciona "sesiones-infovia",por lo que no se puede limitar el número de conexiones por usuario (Rev.2 - webmaster@europa.alphacom.es)

  • Si un usuario se queda conectado en el servidor de túneles, pero no tiene reflejo en el radius (por ejemplo, porque lo hemos reiniciado) no hay ningún control sobre él. De hecho ni siquiera sabemos que existe.

  • (Rev.9 - dserena@nova.es)
    Alguno comentabais que cuando el usuario conectaba, le pedia continuamente la contraseña, y nunca podia llegar a conectar.

    Nos pasaba eso mismo en un asociado que esta en NT. Pero si lo pasabas a un Linux iba perfecto.

    Despues de mirar, y mirar (en TTD no sabian ni daban con que podia ser), y hacer lo propio aqui, hemos dado con ello.

    Si en el NT esta dada de alta (en el TCP/IP), la IP que se usaba en ese radius para Infovia (la 10.x.x.x), no consigue autentificar ni a patadas. Realmente, si que autentifica, y deja al usuario "pillado" en el radius. Lo que el usuario ve es que le pide continuamente usuario/contraseña, y acaba echandole, y dejando la sesion pillada.

    Si quitas esa IP (10.x.x.x) del TCP/IP, todo funciona perfectamente.

    Supongo (no he puesto un sniffer para comprobarlo, no hay ganas), que el NT debe de estar mandado la respuesta con la IP 10.x.x.x o algo por el estilo, y eso es lo que debe causar el error.

    NT y su forma de manejar rutas es maravilloso.....

    Bueno, culturilla si que es.

  • Usuarios conectados que no aparecen en el RADIUS y usuarios desconectados que sí aparecen
    (Rev.10 - jcea@argo.es)

    De todos es sabido que es bastante habitual tener usuarios que se han desconectado pero que el RADIUS mantiene "enganchados", debido a que el servidor de túneles no informa de este hecho. Esto ocasiona que el usuario no se pueda conectar en otra ocasión, ya que consta como ya conectado y nuestro RADIUS lo rechazará por superación del número de sesiones simultaneas permitidas (por defecto, una).

    Cuando se detecta este hecho, y tras verificar que el usuario, en efecto, está desconectado, se puede utilizar el comando rad_tool reutilizar_direccion ip para desbloquear a mano esa conexión.

    Menos conocido es el hecho de que, en algunos casos, un usuario llegue a conectarse sin quedar ningún tipo de reflejo en el RADIUS. Ello, aparte del anonimato y los problemas de "accounting" puede provocar que otro usuario se conecte y utilice la misma IP.

    (Rev.10 - tecnico@cherrytel.com)
    Hola Jesús, he modificado el script siguiendo tus indicaciones para que emplee el mecanismo ARP.

    Me parece que ya vale poco, nos han actualizado el software y, de momento (toco madera), no han aparecido más bloqueos. De todas formas ya he aprendido algo nuevo, así que te lo agradezco mucho.

    Un saludo,

    Fernando Fernández Sánchez

    #!/bin/sh
    
    LOG=/etc/raddb/Estado_del_cliente_195.57.103.5
    RAD=/etc/raddb/
    
    
    cd $RAD
    ./rad_tool ver_status > /dev/null
    
    
    cat $LOG | grep 195 | sed 's/  */ /g' | cut -f2 -d' ' | grep 195 > /tmp/_tmpInfovia
    
    # Elimino a los usuarios activos su entrada en la tabla ARP y les envio un paquete
    (
    while read USER
    do
    # Borro la entrada ARP del usuario si existe
      /sbin/arp -d $USER > /dev/null
    # Hago ping a la direccion
      ping -c 1 $USER > /dev/null &
    done
    ) < /tmp/_tmpInfovia
    
    # Espero un segundo y vuelco la tabla ARP con la IP de los HOSTS
    sleep 1s
    /sbin/arp -a -n > /tmp/_arpInfovia
    
    (
    FECHA=`date "+%D  %H:%M"`
    echo "$FECHA: Comprobando bloqueos de Infovia" >> /tmp/logsBloqueosInfovia
    while read USER
    do
      grep "$USER " /tmp/_arpInfovia
    
      if [ $? = 1 ]
      then
        FECHA=`date "+%D  %H:%M"`
        (echo -n "$FECHA: $USER no esta activo. Desbloqueando "
        grep $USER $LOG | sed 's/  */ /g' | cut -f3 -d ':' | cut -f2 -d' ' | \
             (read a; echo "$a.")) >> /tmp/logsBloqueosInfovia
        ./rad_tool reutilizar_direccion $USER
      fi
    done
    ) < /tmp/_tmpInfovia
    cd -
    rm /tmp/_tmpInfovia
    rm /tmp/_arpInfovia
    

RADIUS Accounting

  • Cuando la conexión es fallida no queda ningún tipo de constancia, aunque la denegación de acceso la haya realizado el propio RADIUS (por ejemplo, clave incorrecta) (Rev.2 - carlos@develnet.es)

  • Para que salga la causa de desconexión hay que instalar el nuevo diccionario infovía, o bien el RADIUS entero de nuevo. Se puede encontrar en ftp://in1.ral.telefonica.es/pub/RadiusInfoVia/. Las causas de desconexión no son las mismas que en los ASCEND, por lo que hay que hacerse una tabla nueva.

  • La siguiente tabla indica los nuevos códigos de desconexión, grabados bajo el atributo Acct-Terminate-Cause (Rev.2 - info@cim.es)
    1.- Por petición del usuario
    2.- Pérdida de portadora
    3.- Sin Servicio
    4.- Iddle timeout (inactividad)
    5.- Session timeout
    6.- Admin reset
    7.- Admin reboot
    8.- Port error
    9.- Nas error
    10.- Nas request
    11.- Nas reboot
    12.- Port uneeded
    13.- Port preempted
    14.- Port suspended
    15.- Service unable
    16.- Callback
    17.- User error
    18.- Host request

  • No aparece el Session-ID en los paquetes START (al menos no en todos).

    (Rev.4 - jcea@argo.es) Con la actualización del sistema operativo de los servidores de túneles, esto ya funciona.

  • Los Session-ID se reutilizan si se reinicia el servidor de túneles.

  • No sale el campo "NAS-Port-Type" en los paquetes START, pero sí en los paquetes STOP.

    (Rev.4 - jcea@argo.es) Con la actualización del sistema operativo de los servidores de túneles, esto ya funciona.

    (Rev.5 - info@cin.es) En ocasiones el valor del NAS-Port-Type no se corresponde con la realidad. Se da el caso de realizar conexión RDSI y desconexión RTC. Se reconoce la existencia del problema pero no hay ningún plazo para su solución.

  • Session-Time en los STOP parece indicar el número de segundos desde 1970, no el número de segundos de la conexión.

    (Rev.4 - jcea@argo.es) Con la actualización del sistema operativo de los servidores de túneles, esto ya funciona.

  • El tráfico de bytes y de paquetes que se indica en el STOP parece corresponder al acumulado de todo el túnel desde su creación. Por lo que parece, en el servidor de 512 conexiones sí que funciona correctamente :-?.

    (Rev.4 - jcea@argo.es) Con la actualización del sistema operativo de los servidores de túneles, esto ya funciona.

  • No tenemos información sobre la velocidad de la conexión, ni en los START ni en los STOP.

  • No se puede limitar el acceso a los usuarios que conectan vía RDSI.

  • No sale: acct-Authentic, caller-id, client-port-dnis y client-protocol. Los números del usuario llamante y del nodo llamado aparecen en la conexión de control PPTP entre I+ y el Túnel, pero no se proporcionan al RADIUS.

    (Rev.4 - savage@apostols.org)
    Hey, que estoy haciendo un PPTP server para Linux y debugando he descubierto lo siguiente:

    • Conexiones PPTP desde equipos 3COM/USR TotalControl
      • Pakete PPTP_START_CTRL_CONN_RQST:
        • Nos indica el Framing de la llamada (1-Asyn o 2-Sync)
        • Nos indica el Bearer de la llamada (1-Analogico o 2-Digital)
        • Nos indica "local" como Hostname del equipo
        • Nos indica "USR" como vendor string
        • Nos indica 0 en la Firmware revision.
      • Pakete PPTP_IN_CALL_REQUEST:
        • Nos indica Bearer=3 (Analog+Digital) -No el de la llamada-
        • Nos indica el Dialer y Dialed number con las 9 cifras.
      • Pakete PPTP_IN_CALL_CONNECT:
        • Nos indica Speed 1 bps
        • Nos indica el Framing usado (1-Async o 2-Async)

    • Conexiones PPTP desde equipos Ascend MAX
      • Pakete PPTP_START_CTRL_CONN_RQST:
        • Nos indica el Framing de la llamada == 3 (1-Asyn+2-Sync)
        • Nos indica el Bearer de la llamada == 3 (1-Analogico+2-Digital)
        • Nos indica un nombre como Hostname del equipo
        • Nos indica "" como vendor string
        • Nos indica 1280 en la Firmware revision.
      • Pakete PPTP_IN_CALL_REQUEST:
        • Nos indica Bearer de llamada (1-Analog o 2-Digital)
        • NO indica NI el Dialer NI el Dialed number.
      • Pakete PPTP_IN_CALL_CONNECT:
        • Nos indica Speed 64000/56000 bps
        • Nos indica el Framing usado (1-Async o 2-Async)

    Bueno, si te entretienes un momento en mirar como determinar si es RDSI, te daras cuenta que tengo que empezar a montar excepciones para cada modelo de aparatito, entiendo que el correcto es el de ascend. El de 3com/usr tiene de bueno que nos proporciona el telefono del llamante y el del nodo de acceso que usa.


Si alguien tiene problemas no reseñados en este documento, que me lo haga saber.


Protocolos utilizados en Infovía Plus

Hay mucha información sobre los protocolos empleados en Infovía Plus en mi página sobre Redes Privadas Virtuales.


La Competencia de Infovía Plus


Páginas Oficiales de Infovía Plus


Historia

  • 22/Sep/99: Por consejo legal, retiro el documento "Informe técnico sobre el Acceso a Internet a través de la Red IP".

  • 16/Sep/99: Se añade el "Informe técnico sobre el Acceso a Internet a través de la Red IP" y la solución de jmvalades@bme.es a los problemas con el router Nautica 2000.

  • 15/Sep/99: Se crea la sección "últimos comentarios" para zanjar el desarrollo de esta página.

  • 02/Mar/99: Revisión 10 de los problemas de Infovía Plus.

  • 02/Feb/99: Revisión 9 de los problemas de Infovía Plus.

  • 21/Ene/99: Revisión 8 de los problemas de Infovía Plus.

  • 12/Ene/99: Revisión 7 de los problemas de Infovía Plus.

  • 08/Ene/99: Revisión 6 de los problema de Infovía Plus. Añadidos enlaces a dentro de la lista de problemas, por secciones.

  • 04/Dic/98: Revisión 5 de los problemas de Infovía Plus.

  • 01/Dic/98: Primera versión de esta página, con la revisión 4 de los errores y problemas detectados en Infovía Plus, legislación, enlaces a la competencia, etc.



Python Zope ©1998-99 jcea@jcea.es

Más información sobre los OpenBadges

Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS