Mostrando entradas con la etiqueta internet. Mostrar todas las entradas
Mostrando entradas con la etiqueta internet. Mostrar todas las entradas

lunes, 10 de febrero de 2014

Configurando Quagga para manipular prefijos (Local Preference) utilizando RPKI

Objetivo:
   En el siguiente mini laboratorio configuraremos Quagga para manipular prefijos BGP y asignar Local Preference segun el estado RPKI (valid, invalid, Not Found).
 
Escenario:
- R1 publica un prefijo con un AS que no le corresponde (segun ROA)
- R2 publica el mismo prefijo que R1 pero desde un AS que si es valido
- R2 publica un prefijo sin ROA.
- En este escenario el validador y el router Quagga estan en el mismo equipo

Diagrama del laboratorio:




Requisitos:
- Quagga con soporte para RPKI
- RPKI Validator de RIPE NCC
- Un prefijo que sepamos que se tiene ROA valido. En nuestro caso utilizamos el prefijo 200.85.64.0 que sabiamos que tiene un ROA que indica que debe ser publicado por el AS 7908
- Ejecutar el validador de RIPE NCC antes de ejecutar Quagga


Configuraciones de todos los equipos

Conf-Quagga-RPKI-Mini-LAB.txt

hostname RPKI-RTR
password test
!
router bgp 65000
 bgp router-id 10.0.0.10
 bgp bestpath prefix-validate allow-invalid
 neighbor 10.0.0.1 remote-as 65001
 neighbor 10.0.0.1 route-map rpki in
 neighbor 10.0.0.2 remote-as 7908
 neighbor 10.0.0.2 route-map rpki in
 neighbor 10.0.0.3 remote-as 65003
 neighbor 10.0.0.3 route-map rpki in
!
route-map rpki permit 10
 match rpki invalid
 set local-preference 10
!
route-map rpki permit 20
 match rpki valid
 set local-preference 30
!
route-map rpki permit 30
 match rpki notfound
 set local-preference 20
!        
line vty
!
enable-rpki
  rpki polling_period 1000
  rpki timeout -1216757171
!
  rpki group 1
    rpki cache 127.0.0.1 8282
! 

R1.cfg

!

!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
enable password test
!
memory-size iomem 15
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
no ip icmp rate-limit unreachable
!
!
no ip domain lookup
!
ip cef
ip audit po max-events 100
!
!
!
!
ip tcp synwait-time 5
! 
!
!
!
interface Ethernet0
 ip address 10.0.0.1 255.255.255.0
 half-duplex
!
interface FastEthernet0
 no ip address
 shutdown
 speed auto
!
router bgp 65001
 no synchronization
 bgp log-neighbor-changes
 network 200.85.64.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 200.85.64.0 255.255.255.0 Null0
no ip http server
no ip http secure-server
!
!
!
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 password test
 login
!
end

R2.cfg

!
!
!
!
hostname R2
!
no ip domain lookup
no ip icmp rate-limit unreachable
ip tcp synwait 5
!
!
interface Ethernet0
 ip address 10.0.0.2 255.255.255.0
 half-duplex
!
!
router bgp 7908
 no synchronization
 bgp log-neighbor-changes
 network 200.85.64.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 200.85.64.0 255.255.255.0 Null0
no ip http server
!
line con 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
line aux 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
!
!
end

R3.cfg

!

!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R3
!
boot-start-marker
boot-end-marker
!
!
memory-size iomem 15
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
no ip icmp rate-limit unreachable
!
!
no ip domain lookup
!
ip cef
ip audit po max-events 100
!
!
!
!
ip tcp synwait-time 5
! 
!
!
!
interface Ethernet0
 ip address 10.0.0.3 255.255.255.0
 half-duplex
!
interface FastEthernet0
 no ip address
 shutdown
 speed auto
!
router bgp 65003
 no synchronization
 bgp log-neighbor-changes
 network 192.168.0.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 192.168.0.0 255.255.255.0 Null0
no ip http server
no ip http secure-server
!
!
!
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 login
!
end



Salida final en Quagga:
(Notese los flags N, I, V) (Notese los local preference)

RPKI-RTR# sh ip bgp
BGP table version is 0, local router ID is 10.0.0.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
N*> 192.168.0.0      10.0.0.3                 0     20      0 65003 i
I*  200.85.64.0      10.0.0.1                 0     10      0 65001 i
V*>                  10.0.0.2                 0     30      0 7908 i

Total number of prefixes 2




miércoles, 2 de enero de 2013

DNS64 y NAT64 paso a paso con explicación

Introducción:
DNS64 y NAT64 son dos tecnología diferentes que comunmente trabajan en conjunto.

DNS64 y NAT64 es ideal para colocar en el borde una red donde unicamente existan host con IPv6, algo cada día es más común sobre todo en el mundo de redes celulares y se gran cantidad de sensores.

En Internet hay mucha información sobre como configurar NAT64 y DNS64, la mayoría dice que muy fácil, otros lo colocan más complicado. En lo personal no conseguí ninguna que explicara paso a paso como hacerlo y adicionalmente que explicara la topología de red donde se estaba configurando.

En este post comienzo instalando DNS64 y luego procedemos con NAT64. Se puede instalar en cualquier orden.

Que se necesita antes de comenzar:

- Una subred IPv6 libre (una /96 esta bien) para realizar el mapeo DNS entre IPv4 e IPv6. Esta misma subred la utilizaremos dentro de Tayga para el NAT64

- Logicamente conectividad IPv6 entre los clientes y el servidor DNS64 y NAT64 (no se requiere IPv4)



Topología:
a) Servidor realizando. Solo tiene una interfaz (eth1)

IPv6: 2001:db8:1:1::/64 (eth1).
IPv4: 192.168.124.107

b) IP de un cliente (eth2):

2001:db8:1:1::2/64


c) Subredes IPv6:

Red que "retorna" el DNS64 2001:db8:1:ffff::/96
Pool de NAT en el NAT64: 2001:db8:1:ffff::/96

(si, son el mismo bloque)


d) Interfaz dns64:

192.168.124.107/32
2001:db8:1::1/128


(correcto!, la IPv6 e IPv4 de eth1 se solapan con interfaz dns64)



Procedimiento de DNS64.

Paso 1:

Instalar BIND9:

#aptitude install bind9


Paso 2:

Configurar /etc/bind/named.conf.options:

a) Asegurar que BIND escuche en IPv6 (recordemos que los clientes van a estar en IPv6)

listen-on-v6 { any; };

b) Permitir consultas desde cualquier IP. Si estas utilizando un servidor público o en producción favor restringir las consultas a tus clientes

allow-query { any; };

c) Realizar el DNS64 con la siguiente directiva.

dns64 2001:db8:1:ffff::/96 { 
    clients { 
      any; };
 };

La configuración del punto "c" lo que indica es que aquellas consultas DNS de aquellos registros que SOLO tienen tienen registro A (no tienen registro AAAA) serán entregadas a los clientes añadiendo 2001:db8::1:ffff::/96


d) Reiniciar bind9

#/etc.init.d/bind9 restart


Probar DNS64:

a) En un PC cliente colocar como servidor DNS: 2001:db8:1:1::1


b) Ubicarse en un cliente y realizar consultar DNS de hosts solo con direcciones IPv4 (registros A). Por ejemplo:


root@ubuntu-VirtualBox:~# dig ipv4.google.com aaaa @2001:db8:1:1::1

; <<>> DiG 9.8.0-P4 <<>> ipv4.google.com aaaa @2001:db8:1:1::1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- 64252="64252" br="br" id:="id:" noerror="noerror" opcode:="opcode:" query="query" status:="status:">;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;ipv4.google.com.               IN      AAAA

;; ANSWER SECTION:
ipv4.google.com.        0       IN      CNAME   ipv4.l.google.com.
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8268
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8269
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:826a
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8293
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8263
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8267

;; AUTHORITY SECTION:
google.com.             171975  IN      NS      ns1.google.com.
google.com.             171975  IN      NS      ns4.google.com.
google.com.             171975  IN      NS      ns2.google.com.
google.com.             171975  IN      NS      ns3.google.com.

;; Query time: 219 msec
;; SERVER: 2001:db8:1:1::1#53(2001:db8:1:1::1)
;; WHEN: Wed Jan  2 16:11:57 2013
;; MSG SIZE  rcvd: 294




Nota: La parte a destacar en esta salida son las direcciones IPv6 que comienzan por: 2001:db8:1:ffff..., ya en este momento sabemos que DNS64 esta funcionando.



Ahora NAT64

1) Utilizamos Tayga. El sitio oficial y link para descargarlo se encuentra en: http://www.litech.org/tayga/


2) Lo descomprimimos y desempaquetamos:

#tar -jxvf tayga-0.9.2.tar.bz2
#cd tayga-0.9.2
#./configure
#make
#make install


3) Creamos el directorio donde Tayga guardará los logs:

#mkdir /var/log/tayga

4) Editamos el archivo /usr/local/etc/tayga.conf

y copiamos y pegamos:

tun-device nat64
ipv4-addr 192.168.255.1
prefix 2001:db8:1:ffff::/96
dynamic-pool 192.168.255.0/24
data-dir /var/log/tayga



Tayga es stateless y realiza un nat 1:1 entre IPv6 e IPv4. En la configuración anterior a cada cliente IPv6 se le asignará un IP del pool 192.168.255.0/24; por ello si tenemos más de 255 hosts será necesario utililzar un pool más grande que /24. En caso de que tengas IPv4 públicas suficientes puede ser útil para evitar un doble NAT IPv4.

La directiva prefix indica el prefijo que utilizará Tayga para reconocer los 32 bits de IPv4, es decir, cuando el destino IPv6 sea: 2001:db8:1:ffff::/96, Tayga tomará los ultimos 32 bits para reconocer que ese es el destino IPv4

5) Habilitar routing IPv6 e IPv4 en el servidor.

#echo "1" > /proc/sys/net/ipv6/conf/all/forwarding
#echo "1" > /proc/sys/net/ipv4/ip_forward


6) Creación y configuración de la interfaz nat64:

#tayga --mktun
#ip link set nat64 up
#ip addr add 192.168.124.107 dev nat64
#ip addr add 2001:db8:1::1 dev nat64


(estos comandos crean la interfaz nat64 con las direcciones ip 192.168.0.1/32 y 2001:db8:1::1/128, como dije anteriormente no importa que se solape con los IPs de eth1).

Para revisar:
root@aacosta-ThinkPad-E420:~# ifconfig nat64
nat64     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:192.168.0.1  P-t-P:192.168.0.1  Mask:255.255.255.255
          inet6 addr: 2001:db8:1::1/128 Scope:Global
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:2393 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2395 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:1615556 (1.6 MB)  TX bytes:1614316 (1.6 MB)


7) Creación de rutas:
#ip route add 192.168.255.0/24 dev nat64

#ip route add 2001:db8:1:ffff::/96 dev nat64

8) Ejecutamos Tayga

#tayga -d

(el -d es opcional, solo es para tener más información)


PROBAR NAT64
a) Probamos que todo este bien (el ping debe ser satisfactorio):

root@aacosta-ThinkPad-E420:~# ping6 2001:db8:1:ffff::192.168.0.1
PING 2001:db8:1:ffff::192.168.0.1(2001:db8:1:ffff::c0a8:1) 56 data bytes
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=109 ttl=63 time=2.18 ms
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=110 ttl=63 time=0.209 ms
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=111 ttl=63 time=0.190 ms
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=112 ttl=63 time=0.126 ms



b) Realizamos NAT con la interfaz IPv4 saliente (solo si el pool IPv4 en Tayga es privado):

#iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 
#iptables -A FORWARD -i eth0 -o nat64 -m state --state RELATED,ESTABLISHED -j ACCEPT 
#iptables -A FORWARD -i nat64 -o eth0 -j ACCEPT

c) Ahora solo debes dirigirte a la máquina cliente y todo debe estar funcionando. Ejemplos de ping y trace:


[root@localhost ~]# traceroute6 www.algo.com -n
traceroute to algo-com-prod-elb-170663297.us-east-1.elb.amazonaws.com (2001:db8:1:ffff::36f3:7ac3) from 2001:db8:1:1::2, 30 hops max, 16 byte packets
 1  2001:db8:1:1::1  1.224 ms  3.8 ms  0.352 ms
 2  2001:db8:1:ffff::c0a8:ff01  0.787 ms  0.772 ms  0.268 ms
 3  2001:db8:1:ffff::c0a8:1  0.76 ms  0.869 ms  0.278 ms


[root@localhost ~]# ping6 www.parmalat.com.ve -n
PING www.parmalat.com.ve(2001:db8:1:ffff::c82f:4f04) 56 data bytes
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=1 ttl=56 time=7.30 ms
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=2 ttl=56 time=5.82 ms
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=3 ttl=56 time=5.93 ms
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=4 ttl=56 time=8.38 ms



  Puedes ver un estado de las asignaciones de Tayga en: /var/log/tayga/dynamic.map



Voila!... todo debe estar funcionado en este momento!


Mas información: 
http://www.litech.org/tayga/
http://www.litech.org/tayga/README-0.9.2

http://kurser.iha.dk/eit/itifn/workshops/vne_workshop_2.html
http://ipvsix.me/?tag=tayga

Notas importantes:
- El DNS64 no funciona cuando la respuesta DNS tenga registros AAAA y A. En realidad no es una eroor porque se asume que el host tiene acceso IPv6 a Internet
- Es importante que el DNS64 y NAT64 compartan el mismo prefijo IPv6 (en el ejemplo de este post 2001:db8:1:ffff::/96. 
- Durante todo el post describo el procedimiento utilizando la subred IPv6 2001:db8::/32. Favor notar que esta subred debe ser sustituida por sus redes respectivas (al igual que la información referente a IPv4).
- Pueden utilizar 2001:db8::/32 y va a funcionar igualmente pero sin acceso a destinos a IPv6
- El servidor DNS64 y NAT64 pueden ser diferentes equipos/máquinas



to get detailed information about Managed IT Services visit https://wetheitteam.com

jueves, 9 de junio de 2011

Resultados encuesta antes del World IPv6 Day. Lacnic-LACTF

Introduccion:
  Estos fueron los resultados de una encuestra realizada dos dias antes del World IPv6 Day en la lista LAC-TF (IPv6) de Lacnic:



1) Eres un ISP?
Si
       40,5%   17
No
       59,5%   25


2) Tienes planes de despliegue de IPv6 ?
Ya tengo IPv6
       59,4%   19
Antes de 6 meses
       9,4%    3
Antes de 1 año
       9,4%    3
Antes de 2 años
       6,3%    2
Sin tiempos definidos
       15,6%   5


3) Que esperas del World IPv6 Day?
Menos de 1% de problemas de conexión
       61,0%   25
Entre 1-50% de problemas de conexión
       34,1%   14
Entre 51-99% de problemas de conexión
       4,9%    2
Se perderá la conexión complemamente en Internet
       0,0%    0


4) En tu centro de Help Desk que esperas?
No va a aumentar la cantidad de llamadas
       55,0%   22
Aumentará entre 1-10% la cantidad de llamadas
       40,0%   16
Aumentará más de 10% la cantidad de llamadas
       5,0%    2


5) Tienen estimado algun plan en caso de que el Help Desk se desborde?
Si
       31,7%   13
No
       68,3%   28


6) Estas preocupado por tu servicio de Internet este día?
Nada-Poco
       73,8%   31
Mas o menos
       23,8%   10
Mucho
       2,4%    1


7) Tu organización (alta gerencia) se ha preocupado por este evento?
Nada-Poco
       45,2%   19
Medio
       33,3%   14
Bastante
       21,4%   9

miércoles, 13 de abril de 2011

Utilizar tu celular Nokia como Access Point

Situacion: Has escuchado que puedes convertir tu celular Nokia en un Access Point wireless y otros dispositivos Wi-Fi pueden conectarse a Internet a traves de él. Todo es cierto. Solución Tu solución se llama: JoikuSpot y puedes bajarlo utilizando la tienda OVI.

sábado, 2 de enero de 2010

Como determinar/calcular el ancho de banda para un enlace

Pregunta:
En mi area (mas de 15 anos trabajando en el mundo de proveedores de Internet) en repetidas ocasiones he recibido la pregunta por parte de clientes que quieren contratar un enlace a Internet: ¿Cuanto ancho de banda contrato?

Respuesta:
  La respuesta afortunadamente tiene calculos sencillos matematicos que se pueden utilizar, sin embargo no existe una sola respuesta a la pregunta.
  En fin, supongamos que usted quiere conectar una nueva oficina a Internet para N cantidad de usuarios y no sabe cuanto ancho de banda desea contratar. Esta es la formula a utilizar:

AB = G * C

Donde:

AB = Ancho de banda a contratar
N = Cantidad de usuarios que utilizan Internet en la Oficina. Recordemos que quizas tengan usuarios en la oficina que no utilicen Internet (motorizados, archivistas, etc). Este valor no esta en la formula pero es conveniente conocerlo
G = Ancho de banda a garantizar por usuario. Este valor es muy importante. Al bajar un archivo cuanto ancho de banda quiero que consuma. Un valor en latinoamerica puede ser quizas 256 Kbps, otros paises desarrollados pueden utilizar un valor mayor. Importante destacar que el valor G también puede depender del tipo de aplicativo que queramos usar. Por ejemplo una transmisión de video no es igual a una transacción POS de una tienda.
C = Concurriencia de las personas (cantidad de personas que utilizan Internet simultaneamente). Esto varia mucho entre las oficinas, no todas las oficinas utilizan Internet para lo mismo. No es lo mismo una compania que utiliza los servidores via VPN de otra sede que una que solo usa Internet para Internet-Banking. Probablemente podemos estimar 30% de N

En fin, hagamos un pequeno ejemplo:

N=50 (usuarios con Internet disponible en la oficina)
G=256 Kbps (ancho de banda "garantizado" por usuario)
C = 20 personas (Estimamos que 20 personas de la oficina estaran conectado simultaneamente a Internet)

AB = G * C
AB = 20 * 256 Kbps = 5120 Kbps.

Es decir, 5 Mbps a Internet para una compania de 50 empleados donde se estiman que navegan 20 personas simultaneamente.

Espero este articulo haya sido de tu ayuda.

Suerte,
If you're still having the issue a fatal javascript error has occurred discord after reinstalling Discord, ensure the AppData folder has been deleted before proceeding with the reinstallation.

jueves, 31 de diciembre de 2009

Mejorar el rendimiento de Windows XP en redes P2P / Servidor

Situacion:
Deseo mejorar el rendimiento de Windows XP en redes P2P

Explicacion:
Como todos sabemos el ancho de banda contratado para Internet es subutilizado por la mayoria de las persona, ciertas estadisticas indican que incluso la mayoria de los suscriptores de DSLs aprovechan menos del 60% del ancho de banda que ofrece el proveedor. Por otro lado, Windows XP SP2 aplico en su stack TCP/IP ciertos algoritmos sobre intento de conexiones y conexiones simultaneas, entre ellas una que indica que solo puede realizar hasta 10 intentos de conexiones por segundo. Esta ultima afecta directamente los problemas P2P tales como torrent y emule.

Solucion:
Opcion 1:
1) Instalar el patch que se puede conseguir en: http://www.lvllord.de/?lang=en&url=downloads
El patch fue creado por: http://www.lvllord.de/ y se consigue en ingles y en aleman. Durante la instalacion probablemente Windows indique que se estan modificando archivos del sistema, indicarle que se desea continuar.

Opcion 2:
2) - En un editor hexadecimal localiza del lado izquiero el valor 4F322
- Cambiar 0a 00 00 00 a 00 00 0a 00

Extra #1:
Tambien recomiendo apoyarse en el sencillo programa TCP Optimizer el cual es una aplicacion sencilla, intuitiva que ajusta ciertos valores del registro de windows. No dejes de utilizarlo

Extra #2:
Asignarle más prioridad al proceso de P2P (por ejemplo utorrent o emule): Administrador de Tareas --> Procesos --> Click derecho sobre el proceso --> Arriba de lo normal

SIEMPRE REALIZAR UN BACKUP DEL ARCHIVO TCPIP.SYS

Luego de realizar los cambios mi windows mejoro notablemente en los servicios P2P

Nota:
Este articulo fue basado en http://www.speedguide.net/read_articles.php?id=1497 y en mi propia experiencia

Suerte!

viernes, 30 de octubre de 2009

Linux. Utilizar celular como modem para conectarse a Internet

Necesidad:
Utilizar el celular para conectarse a Internet. En mi caso utilicé el motorola W6 y Linux Mandriva

Que se necesita:
- Celular motorola
- Cable de conexión telefono -- PC

Procedimiento:
1) Instalar wvdial para maneja y discado del modem:

#urpmi wvdial

2) Identificar el nombre con el que Linux reconoce el modem. Para ello, ejecutaremos:

# tail -f /var/log/message

y simultaneamente conectaremos el telefono al PC/Laptop. Conseguiremos un nombre como /dev/ttyACM0

3) Verificar que el device se haya creado correctamente:

#ls -lh /dev/ttyACM0

4) Recomiendo crear un link simbolico entre /dev/modem y /dev/ttyACM0:

#ln -s /dev/ttyACM0 /dev/modem

5) Posteriormente hay que configurar el wvdial (ya estamos casi listos!). Para ello edita /etc/wvdial.conf similar a:

[Dialer Defaults]
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2
Abort on No Dialtone = off
Password = ''
Check Def Route = off
Phone = *99#
Idle Seconds = 0
Abort on Busy = off
;Minimize = on
Modem Type = Analog Modem
Stupid Mode = on
Baud = 115200
Auto DNS = on
Dial Command = ATM1L3DT
Auto Reconnect = off
Ask Password = off
Init = ATX3
ISDN = off
Dial Attempts = 1
Username = ''
;Dock = on
Carrier Check = on
Init3 = AT+CGDCONT=1,"IP","gprsweb.digitel.ve"
Modem = /dev/ttyACM0

La configuración anterior sirve perfectamente para Digitel en Venezuela. Las partes más importantes corresponden a los DNS, baud rate y el APN de digitel (gprsweb.digitel.ve).

6) Por último, ejecuta wvdial desde la consola:

#wvdial

Debes obtener algo como:

[root@localhost etc]# wvdial
--> WvDial: Internet dialer version 1.60
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: ATX3
ATX3
OK
--> Sending: ATQ0 V1 E1 S0=0 &C1 &D2
ATQ0 V1 E1 S0=0 &C1 &D2
OK
--> Sending: AT+CGDCONT=1,"IP","gprsweb.digitel.ve"
AT+CGDCONT=1,"IP","gprsweb.digitel.ve"
OK
--> Modem initialized.
--> Sending: ATM1L3DT*99#
--> Waiting for carrier.
ATM1L3DT*99#
CONNECT
--> Carrier detected. Starting PPP immediately.
--> Starting pppd at Fri Oct 30 15:37:14 2009
--> Pid of pppd: 21573
--> Using interface ppp0
--> pppd: Connect: ppp0 <--> /dev/ttyACM0
--> pppd: PAP authentication succeeded
--> local IP address 10.251.89.163
--> remote IP address 192.168.100.101
--> primary DNS address 10.99.0.11
--> secondary DNS address 204.59.152.208

Espero esta información haya sido útil.

Suerte!

Una propuesta inesperada dentro de IETF – Ethernet sobre HTTPS

En el presente post quiero hablar mayormente sobre un documento con poco tiempo en IETF llamado “Ethernet sobre HTTPS”. Debo confesar que su...