Now that you have created your
/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
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
(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 the remote host (and beyond). To do this, issue the command
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 initialisation files to find out
where this default route is being set up (it will use a
default... command). Change this command to something like
Now test the link by 'pinging' the server at its IP number as reported by the ifconfig output, i.e.
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
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
/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 (22.214.171.124): 56 data bytes 64 bytes from 126.96.36.199: icmp_seq=0 ttl=254 time=190.1 ms 64 bytes from 188.8.131.52: icmp_seq=1 ttl=254 time=180.6 ms 64 bytes from 184.108.40.206: icmp_seq=2 ttl=254 time=169.8 ms 64 bytes from 220.127.116.11: icmp_seq=3 ttl=254 time=170.6 ms 64 bytes from 18.104.22.168: 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
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
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