On Mon, 24 May 2010 00:00:07 +0200 patrick kristensen
<kristensenpatri...@gmail.com> wrote:
> I have managed to get a working connection with the following script
>
>
> /etc/ppp/ppp.conf
>
> default:
> set log Phase Chat LCP IPCP CCP tun command
> set device /dev/cuaU0
> set speed 460800
> set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT OK-AT-OK
> ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT"
>
> esp:
> set device /dev/cuaU0
> set speed 460800
> set timeout 0
> set dial "ABORT BUSY TIMEOUT 5 \
> \"\" \
> AT OK-AT-OK \
> AT+CPIN=\\\"7291\\\" OK-AT-OK \
> AT+CFUN=1 OK-AT-OK \
> AT+CGDCONT=1,\\\"IP\\\",\\\"movistar.es\\\" OK-AT-OK \
> \\dATDT*99***1# TIMEOUT 30 CONNECT"
>
>
> set ifaddr 0 81.47.192.13 255.255.255.255
> add default HISADDR
> enable dns
>
> # ./.
>
> Setting 'set ifaddr to 0.0.0.0/0 0.0.0.0/0 255.255.255.255' gave me an
> ipadress to MYADDR but i did not get a route.
> Setting 'set ifaddr 0.0.0.0/0 194.179.1.100 (which was DNS)
> 255.255.255.255' made it possible to nslookup movistar.es.
> After nslookup the APN and hardcoding the ip to HISADDR i got a
> working connection.
> The APN (Movistar (Telefonica) Spain) is correct
> (http://www.vysoo.com/apn.php#415 and other sources). (I have not been
> able to find other data networks for movistar as with your example
> with Verizon)
> This setup works so far (i can ping external addresses).
> My understanding of ppp(8) is that it should have been enough to 'set
> ifaddr 0 0 255.255.255.255 (0)' and 'add default HISADDR' (if the
> CGDCONT is correct).
> I appreciate any input on the script and log.
It seems your routing is hosed. As the ppp(8) manual states, if you
use "add" it will not overwrite your default route (typically stored
in /etc/mygate). When you want to overwrite the default route, you need
to use "add!" such as:
add! default HISADDR
Typically, you want to overwrite the default route, but note, you'll
probably see some harmless warnings for routes that ppp cannot
overwrite (such as IPv6 when it's not supported by your provider).
As for setting up the interface addresses, you should define all four
parts, rather than defining only three as you have done above.
set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0
part#1 part#2 part#3 part#4
In your script above, your part#1 of "0" is *DEMANDING* that your
address be 0.0.0.0/32 and nothing else, or in other words, you are
*DEMANDING* that you become the default route for the remote system.
Needless to say the remote system will just laugh at you and refuse
to change it's default route (i.e. address your end as 0.0.0.0).
Setting the netmask (part#3) to 0.0.0.0 forces ppp to assign an
appropriate netmask. Since it is a point-to-point link and some
operating systems/kernels do not understand a POINTTOPOINT netmask,
you'll typically end up with 255.255.255.255 or 255.255.255.0 for the
netmask of your tun0 interface *even* if the remote gateway address is
outside of the netmask.
Using part#4 is important. This the address you *SUGGEST* that your
side should be, but you *DEMAND* your side gets and address defined by
part#1 (the /0 netmask on part#1 says any IP address).
Additionally, part#4 is also the "trigger" address when using '-auto'
mode to connect or reconnect.
Lastly, there's no point in defining 'device' 'speed' and 'dial' in the
"default:" section of your config file since you are redefining them in
the "esp:" section.
Once you have the above corrected, look at your CHAP settings. Though
you were able to negotiate IP addresses (according to the log), it
seems your provider wanted to use CHAP authentication. If you made the
previous corrections and you still cannot connect, then you may need
to use CHAP:
set authname myusername
set authkey mypassword
set login
Not all providers require PAP/CHAP authentication through 'authname'
'authkey' and 'login' because the real authentication is being done by
device identifiers (MEID and/or IMEI).
jcr
--
The OpenBSD Journal - http://www.undeadly.org
