Now that you have created your /etc/ppp/options and
/etc/resolv.conf files (and, if necessary, the
/etc/ppp/pap|chap-secrets file), you can test the settings by
manually establishing a PPP connection. (Once we have the manual
connection working, we will automate the process).
To do this, your communications software must be capable of quitting WITHOUT resetting the modem. Minicom can do this - ALT Q (or in older version of minicom CTRL A Q)
Make sure you are logged in as root.
Fire up you communications software (such as minicom), dial into the PPP server and log in as normal. If you need to issue a command to start up PPP on the server, do so. You will now see the garbage you saw before.
If you are using pap/chap, then merely connecting to the remote system should start ppp on the remote and you will see the garbage without logging in (although this may not happen for some servers).
Now quit the communications software without resetting the modem (ALT Q or CTL A Q in minicom) and at the Linux prompt (as root) type
pppd -d -detach /dev/cuaX &
The -d option turns on debugging - the ppp connection start up "conversation" will be logged to your system log - which is useful if you are having trouble.
Naturally, you should use cua0 or cua1 etc - the actual port
to which your modem is connected, NOT cuaX!
Your modem lights should now flash as the PPP connection is established. It will take a short while for the PPP connection to be made.
At this point you can look at the PPP interface, by issuing the command
ifconfig
In addition to any Ethernet and loop back devices you have, you should see something like :-
ppp0 Link encap:Point-Point Protocol
inet addr:10.144.153.104 P-t-P:10.144.153.51 Mask:255.255.255.0
UP POINTOPOINT RUNNING MTU:552 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
Where
(Naturally, ifconfig will not report these IP numbers, but the ones used by your PPP server.)
Note: ifconfig also tells you that the link is UP and RUNNING!
If you get something like
ppp0 Link encap:Point-Point Protocol
inet addr:0.0.0.0 P-t-P:0.0.0.0 Mask:0.0.0.0
POINTOPOINT MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
Your PPP connection has not been made...see the later section on debugging!
You should also be able to see a route to the the remote host (and beyond). To do this, issue the command
route -n>
You should se something like:-
Kernel routing table Destination Gateway Genmask Flags MSS Window Use Iface 10.144.153.3 * 255.255.255.255 UH 1500 0 1 ppp0 127.0.0.0 * 255.0.0.0 U 3584 0 11 lo 10.0.0.0 * 255.0.0.0 U 1500 0 35 eth0 default 10.144.153.3 * UG 1500 0 5 ppp0
Of particular importance here, notice we have TWO entries pointing to our ppp interface.
The first is a HOST route (indicated by the H flag) and that allows us to see the host to which we are connected to - but no further.
The second is the default route - this is the route that tells our
Linux PC to send any packets NOT destined for the local Ethernet(s) - to
which we have specific network routes - to the PPP server itself. The
PPP server then is responsible for routing our packets out onto the
Internet and routing the return packets back to us.
If you do not see a routing table with two entries, something is wrong (see the debugging section).
Now test the link by 'pinging' the server at its IP number as reported by the ifconfig output, i.e.
ping 10.144.153.51
You should receive output like
PING 10.144.153.51 (10.144.153.51): 56 data bytes
64 bytes from 10.144.153.51: icmp_seq=0 ttl=255 time=328.3 ms
64 bytes from 10.144.153.51: icmp_seq=1 ttl=255 time=190.5 ms
64 bytes from 10.144.153.51: icmp_seq=2 ttl=255 time=187.5 ms
64 bytes from 10.144.153.51: icmp_seq=3 ttl=255 time=170.7 ms
This listing will go on for ever - to stop it press CTRL C, at which point you will receive some more information :-
--- 10.144.153.51 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 170.7/219.2/328.3 ms
So far so good.
Now try pinging a host by name (not the name of the PPP server itself) but a host at another site that you KNOW is probably going to be up and running...). For example
ping sunsite.unc.edu
This time there will be a bit of a pause as Linux obtains the IP number
for the fully qualified host name you have 'ping'ed from the DNS you
specified in /etc/resolv.conf - so don't worry (but you will
see your modem lights flash). Shortly you will receive output like
PING sunsite.unc.edu (152.2.254.81): 56 data bytes
64 bytes from 152.2.254.81: icmp_seq=0 ttl=254 time=190.1 ms
64 bytes from 152.2.254.81: icmp_seq=1 ttl=254 time=180.6 ms
64 bytes from 152.2.254.81: icmp_seq=2 ttl=254 time=169.8 ms
64 bytes from 152.2.254.81: icmp_seq=3 ttl=254 time=170.6 ms
64 bytes from 152.2.254.81: icmp_seq=4 ttl=254 time=170.6 ms
Again, stop the output by pressing CTRL C and get the statistics...
--- sunsite.unc.edu ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 169.8/176.3/190.1 ms
If you don't get any response, check in the debugging section of this document.
If everything works, shut down the connection by typing
ppp-off
After a short pause, the modem should hang itself up.
If that does not work, either turn off your modem or fire up your communications software and interrupt the modem with +++ and then hang up with ATH0 when you receive the modem's OK prompt.
You may also need to clean up the lock file created by pppd
rm -f /var/lock/LCK..cuaX