Últimos Cambios
|
|
|
|
Últimos Cambios |
|
|
|
||
| Mi estado actual
en Jabber/XMPP:
| |||
Última Actualización: 22 de Septiembre de 1.999 - Miércoles
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.
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:
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:
No voy a dar detalles de cómo acceder a esas informaciones o para qué sirven. Es bastante evidente.
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é?
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...
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. |
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.
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!
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
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
> 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:
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.
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..
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.
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.
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.
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.
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.
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.
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.
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.
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.
El documento inicial crece considerablemente gracias a las aportaciones de otros miembros de la lista de proveedores.
Los problemas que se indican los había detectado yo mismo.
Desde Julio es posible utilizar más de 16 caracteres (al menos hasta 30) (Rev.3 - svt@svt.es)
Cuando los CPI asociados utilizan el mismo RADIUS que el servidor principal (son alias del CPI principal), funciona correctamente (Rev.3 - svt@svt.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".
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.
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.
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 - 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 ...
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 - 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.
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):
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:
(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.
(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?
Hay proveedores que no tienen problemas con los Cisco. Cuando no funciona, tampoco funcionan las llamadas de modem normales (Rev.2 - jgomez@canaldata.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.
(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 - 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
(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.
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.).
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.
(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.
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.
ppp authentication chap ppp chap hostname usuario@knet ppp chap password 0 contraseña
y funciona.
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
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.
(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.
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.
Además, no siempre les pasa a los mismos usuarios, y no a todos... y no siempre... Pero a algunos casi siempre.
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:
Este problema tiene dos causas:
(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.
Para probar si el problema se debe a esta causa, se siguen los siguientes pasos:
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 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.
O sea, el campo EnablePMTUBHDetect a enable (1)
(Rev.9 - jsalas@alcavia.net)
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:
añadir IPMTU (Dword)=600 (decimal)
En Windows 95-98
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)
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)
http://www.demonweb.co.uk/c3sys/ppp.htm.
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)
HKEY_LOCAL_MACHINE
\SYSTEM\CurrentControlSet\Services\tcpip\parameters
\EnablePMTUBHDetect : REG_DWORD: 0x1
SOLUCIONADO:
HKLM\SYSTEM\CCS\Services\NdisWAN\parameters
HKLM\SYSTEM\CCS\services\class\net\000X
(donde X es la interfaz que lleve el acceso telefonico a redes),
IPMTU=600
Atencion, correccion al mail de ayer.
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:
(Rev.10 - hostmaster@danysoft.es)
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
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 :-)
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.
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
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
(Rev.4 - jcea@argo.es) Con la actualización del sistema operativo de los servidores de túneles, esto ya funciona.
(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.
(Rev.4 - jcea@argo.es) Con la actualización del sistema operativo de los servidores de túneles, esto ya funciona.
(Rev.4 - jcea@argo.es) Con la actualización del sistema operativo de los servidores de túneles, esto ya funciona.
(Rev.4 - savage@apostols.org)
Hey, que estoy haciendo un PPTP server para Linux y debugando he
descubierto lo siguiente:
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.
Hay mucha información sobre los protocolos empleados en Infovía Plus en mi página sobre Redes Privadas Virtuales.
Desplegada por British Telecom.
Diseñada por Retevisión para proporcionar acceso a su proveedor Iddeo.
