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 or 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 - try pressing Enter and see if the garbage starts up).
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/ttySx 38400 & |
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.
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
inet addr:10.144.153.10 is the IP number of your end of the link.
P-t-P:10.144.153.5 is the SERVER's IP number.
(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 no ppp device listed or 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 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, (established by giving pppd the option defaultroute. 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. In particular if your syslog shows a message telling you pppd is not replacing an existing default route, then you have a default route pointing at your Ethernet interface - which MUST be replaced by a specific network route: YOU CAN ONLY HAVE ONE DEFAULT ROUTE!!!
You will need to explore your system initialization files to find out where this default route is being set up (it will use a route add default... command). Change this command to something like route add net....
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, try pinging the IP address of the DNS server at your ISP's site. If you get a result from this, then it looks like you have a problem with /etc/resolv.conf.
If this doesn't work, you have a routing problem, or your ISP has a problem routing packets back to you. Check your routing table as shown above and if that is OK, contact your ISP. A good test of the ISP is to use another operating system to connect. If you can get beyond your ISP with that, then the problem is at your end.
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..ttySx |