abe7af4385ce146cd54cf8a6c852744a8cb4b328
[ppp.git] / README.linux
1
2 PPP for Linux                                             Version 0.2.8
3 =============                                                  based on
4                                                               ppp-2.1.0
5                                                                May 1994
6
7 Michael Callahan    callahan@maths.ox.ac.uk
8 Al Longyear         longyear@netcom.com
9
10   Contents:
11     INTRODUCTION
12     CREDITS
13     FUTURE PLANS
14     INSTALLATION
15     GENERAL NETWORK CONFIGURATION
16     CONNECTING TO A PPP SERVER
17     IF IT WORKS
18     IF IT DOESN'T WORK
19     IF IT STILL DOESN'T WORK (OR, BUG REPORTS)
20     DYNAMIC ADDRESS ASSIGNMENT
21     SETTING UP A MACHINE FOR INCOMING PPP CONNECTIONS
22     ADDING MORE PPP CHANNELS
23     CHANGES FROM LINUX PPP 0.1.x
24     CONCLUSION
25
26
27 INTRODUCTION
28
29 This is a PPP driver for Linux.  It has been used by many people and
30 seems to be quite stable.  It is capable of being used either as a
31 'client'--for connecting a Linux machine to a local Internet provider,
32 for example--or as a 'server'--allowing a Linux machine with a modem
33 and an Ethernet connection to the Internet to provide dial-in PPP
34 links.  (In fact, the PPP protocol does not make the distinction
35 between client and server, but this is the way people often think
36 about it.)
37
38 The PPP protocol consists of two parts.  One is a scheme for framing
39 and encoding packets, the other is a series of protocols called LCP,
40 IPCP, UPAP and CHAP, for negotiating link options and for
41 authentication.  This package similarly consists of two parts: a
42 kernel module which handles PPP's low-level framing protocol, and a
43 user-level program called pppd which implements PPP's negotiation
44 protocols.
45
46 The kernel module assembles/disassembles PPP frames, handles error
47 detection, and forwards packets between the serial port and either the
48 kernel network code or the user-level program pppd.  IP packets go
49 directly to the kernel network code.  So once pppd has negotiated the
50 link, it in practice lies completely dormant until you want to take
51 the link down, when it negotiates a graceful disconnect.
52
53 CREDITS
54
55 I (MJC) wrote the original kernel driver from scratch.  Laurence
56 Culhane and Fred van Kempen's slip.c was priceless as a model (a
57 perusal of the files will reveal that I often mimicked what slip.c
58 did).  Otherwise I just implemented what pppd needs, using RFC1331 as
59 a guide.  For the most part, the Linux driver provides the same
60 interface as the free 386BSD and SunOS drivers.  The exception is that
61 Linux has no support for asynchronous I/O, so I hacked an ioctl into
62 the PPP kernel module that provides a signal when packets appear and
63 made pppd use this instead.
64
65 Al Longyear ported version 2.0.4 of pppd (from the free package
66 ppp-2.0.4) to Linux.  He also provided several enhancements to both
67 the kernel driver and the OS-independent part of pppd.  His
68 contributions to Linux PPP have been immense, and so this release
69 is being distributed over both our names.
70
71 The pppd program comes from the free distribution of PPP for Suns and
72 386BSD machines, maintained by Paul Mackerras.  This package lists
73 "thanks to" Brad Parker, Greg Christy, Drew D. Perkins, Rick Adams and
74 Chris Torek.
75
76
77 FUTURE PLANS
78
79 The main missing feature is the ability to fire up a PPP connection
80 automatically when a packet destined for the remote host is generated
81 ("demand-dialing").  Work is progressing on this, but it involves some
82 nontrivial design issues.
83
84
85 INSTALLATION
86
87 This version of PPP has been tested on 1.0.x (x=0..9) and 1.1.x
88 (x=0..14) kernels.  It will probably not work on kernels much earlier
89 than this due to a change in the routing code.  If you have an earlier
90 kernel, please upgrade.
91
92 joining the PPP channel of linux-activists:
93
94       This isn't really part of installation, but if you DO use
95       Linux PPP you should do this.  Send a message with the line
96         X-Mn-Admin: join PPP
97       contained in the body to linux-activists-request@niksula.hut.fi
98       You can send to the list by mailing to
99       linux-activists@niksula.hut.fi and putting the line
100         X-Mn-Key: PPP
101       at the start of your message.
102
103       The advantage of subscribing is that you'll be informed of
104       updates and patches, and you'll be able to draw on the
105       experience of many PPP users.  If you have a problem, I may not
106       be able to diagnose it, but someone else may have solved it
107       already.
108
109       Note also that I do not read the linux Usenet newsgroups
110       regularly enough to catch any discussions of PPP; if you want to
111       reach the PPP audience you should join the linux-activists
112       channel.
113
114       To leave the PPP mailing list :-(, send a message with the line
115         X-Mn-Admin: leave PPP
116       to linux-activists-request.
117
118 kernel driver installation:
119
120       This depends on the kernel version you're using.
121
122       Since 1.1.14, Linux kernels have had built-in support for PPP.
123       You'll be asked whether you want PPP when you run "make config".
124       It's as easy as that.
125
126       In 1.1.13, PPP is there but the PPP line in config.in is
127       commented out.  If you have 1.1.13, you probably should just
128       upgrade anyway.
129
130       Kernel versions prior to 1.1.13 (including all 1.0.x kernels)
131       have had (hidden) support for PPP in the kernel configuration
132       setup for quite some time.  Adding the PPP kernel driver is
133       easy:
134
135         1) copy ppp.c from the linux subdirectory of the distribution
136            to drivers/net and ppp.h to include/linux
137         2) uncomment the CONFIG_PPP line in config.in
138         3) if you are using 1.1.3 or earlier (including 1.0.x):
139            uncomment the line in ppp.c that begins
140             /* #define NET02D
141            by removing the "/* " characters
142         4) in the top level of the kernel source
143                make config
144                make dep
145                make
146
147       Reboot with the new kernel.  At startup, you should see
148       something line this:
149
150   PPP: version 0.2.8 (4 channels)
151   TCP compression code copyright 1989 Regents of the University of California
152   PPP line discipline registered.
153
154       (If you want more than 4 channels, see the section "ADDING MORE
155       PPP CHANNELS" below.)
156
157       Now, try looking at the contents of /proc/net/dev.  It should
158       look something like this:
159
160   Inter-|   Receive                  |  Transmit
161    face |packets errs drop fifo frame|packets errs drop fifo colls carrier
162       lo:      0    0    0    0    0        0    0    0    0     0    0
163     ppp0:      0    0    0    0    0        0    0    0    0     0    0
164     ppp1:      0    0    0    0    0        0    0    0    0     0    0
165     ppp2:      0    0    0    0    0        0    0    0    0     0    0
166     ppp3:      0    0    0    0    0        0    0    0    0     0    0
167
168       This indicates that the driver is successfully installed.
169
170       (Of course, you should keep a kernel without PPP around, in case
171       something goes wrong.)
172
173 pppd installation:
174
175       First execute the following commands (in the ppp-2.2 directory):
176
177         ./configure
178         make
179
180       This will make the pppd and chat programs.
181
182       To install, type 'make install' (in the ppp-2.2 directory).
183       This will put chat and pppd binaries in /usr/etc
184       and the pppd.8 manual page in /usr/man/man8.
185
186       pppd needs to be run as root.  You can either make it setuid
187       root or just use it when you are root.  'make install' will try
188       to install it setuid root.  Making pppd setuid root is
189       convenient for a single-user machine, but has security
190       implications which you should investigate carefully before
191       making it available on a multiuser machine.
192
193 GENERAL NETWORK CONFIGURATION
194
195 Since many people don't use the Linux networking code at all until
196 they get a PPP link, this section describes generally what's needed to
197 get things running.  In principle none of this is special to PPP.  For
198 more details, you should consult the relevant Linux HOWTOs.  If you
199 already understand network setup, you can skip this section.
200
201 The first file that requires attention is the rc script that does
202 network configuration at boot time, called /etc/rc.net or
203 /etc/rc.d/rc.net.{1,2} or something similar, depending on your Linux
204 distribution.  This file should 'ifconfig' the loopback interface lo,
205 and should add an interface route for it.  These lines might look
206 something like this:
207         $CONFIG lo 127.0.0.1
208         $ROUTE add loopback
209 or
210         /sbin/ifconfig lo 127.0.0.1
211         /sbin/route add 127.0.0.1
212
213 However, it should *not* config an ethernet card or install any other
214 routes (unless you actually have an ethernet card, in which case I'll
215 assume you know what to do).  Many distributions will provide scripts
216 that expect you to have an ethernet card.
217
218 You also need to decide whether you want to allow incoming
219 telnet/ftp/finger, etc.  If so, you should have the rc startup script
220 run the 'inetd' daemon.
221
222 Next, you should set up /etc/hosts to have two lines.  The first
223 should just give the loopback or localhost address and the second
224 should give your own host name and the IP address your PPP connection
225 will use.  For example:
226      127.0.0.1  loopback localhost   # useful aliases
227      192.1.1.17  billpc.whitehouse.gov bill  # my hostname
228 where my IP address is 192.1.1.17 and my hostname is
229 billpc.whitehouse.gov.  (Not really, you understand.)  If your PPP
230 server does dynamic IP address assignment, give a guess as to an
231 address you might get (see also "Dynamic Address Assignment" below).
232
233 Finally, you need to configure the domain name system by putting
234 appropriate lines in /etc/resolv.conf .  It should look something like
235 this:
236      domain whitehouse.gov
237      nameserver 192.1.2.1
238      nameserver 192.1.2.10
239 Assuming there are nameservers at 192.1.2.1 and 192.1.2.10, then when
240 you get connected with PPP, you can reach hosts whose full names are
241 'hillarypc.whitehouse.gov' and 'chelseapc.whitehouse.gov' by the names
242 'hillarypc' and 'chelseapc'.  You can probably find out the right
243 domain name to use and the IP numbers of nameservers from whoever's
244 providing your PPP link.
245
246 CONNECTING TO A PPP SERVER
247
248 To use PPP, you invoke the pppd program with appropriate options.
249 Everything you need to know is contained in the pppd(8) manual page.
250 However, it's useful to see some examples:
251
252 Example 1: A simple dial-up connection.
253
254 Here's a command for connecting to a PPP server by modem.
255
256   pppd connect 'chat -v -f chat-script' \
257       /dev/cua1 38400 -detach debug crtscts modem defaultroute 192.1.1.17:
258
259 where the file chat-script contains:
260
261   "" ATDT5551212 CONNECT "" ogin: ppp word: whitewater
262
263 Going through pppd's options in order:
264    connect 'chat ...'  This gives a command to run to contact the
265     PPP server.  Here the supplied 'chat' program is used to dial a
266     remote computer.  The whole command is enclosed in single quotes
267     because pppd expects a one-word argument for the 'connect' option.
268     The options to 'chat' itself are:
269          -v              verbose mode; log what we do to syslog
270          -f chat-script  expect-send strings are in the file chat-script
271     The strings for chat to look for and to send are stored in the
272     chat-script file.  The strings can be put on the chat command line,
273     but this is not recommended because it makes your password visible
274     to anyone running ps while chat is running.  The strings are:
275          ""            don't wait for any prompt, but instead...
276          ATDT5551212   dial the modem, then
277          CONNECT       wait for answer
278          ""            send a return (null text followed by usual return)
279          ogin: ppp word: whitewater    log in.
280    /dev/cua1  specify the callout serial port cua1
281    38400  specify baud rate
282    -detach   normally, pppd forks and puts itself in the background;
283         this option prevents this
284    debug  log status in syslog
285    crtscts  use hardware flow control between computer and modem
286         (at 38400 this is a must)
287    modem  indicate that this is a modem device; pppd will hang up the
288         phone before and after making the call
289    defaultroute  once the PPP link is established, make it the
290         default route; if you have a PPP link to the Internet this
291         is probably what you want
292    192.1.1.17:  this is a degenerate case of a general option
293         of the form  x.x.x.x:y.y.y.y  .  Here x.x.x.x is the local IP
294         address and y.y.y.y is the IP address of the remote end of the
295         PPP connection.  If this option is not specified, or if just
296         one side is specified, then x.x.x.x defaults to the IP address
297         associated with the local machine's hostname (in /etc/hosts),
298         and y.y.y.y is determined by the remote machine.  So if this
299         example had been taken from the fictional machine 'billpc',
300         this option would actually be redundant.
301
302 pppd will write error messages and debugging logs to the syslogd
303 daemon using the facility name "daemon".  (Verbose output from chat
304 uses facility "local2".)  These messages may already be logged to the
305 console or to a file like /usr/adm/messages; consult your
306 /etc/syslog.conf file to see.  If you want to make all pppd and chat
307 messages go to the console, add the line
308    daemon,local2.*                              /dev/console
309 to syslog.conf; make sure to put one or more TAB characters between
310 the two fields.
311
312 Example 2: Connecting to PPP server over hard-wired link.
313
314 This is a slightly more complicated example.  This is the script I run
315 to make my own PPP link, which is over a hard-wired Gandalf link to an
316 Ultrix machine running Morningstar PPP.
317
318   pppd connect /etc/ppp/ppp-connect defaultroute noipdefault debug \
319       kdebug 2 /dev/cua0 9600
320
321 Here /etc/ppp/ppp-connect is the following script:
322   #! /bin/sh
323   /etc/ppp/sendbreak
324   chat -v -t60 "" \; "service :" blackice ogin: callahan word: PASSWORD \
325       black% "stty -echo; ppp" "Starting PPP now"  && sleep 5
326
327 This sends a break to wake up my terminal server, sends a semicolon
328 (which lets my terminal server do autobaud detection), then says we
329 want the service "blackice".  It logs in, waits for a shell prompt
330 ("black%"), then starts PPP.  The -t60 argument sets the timeout to a
331 minute, since things here are sometimes very slow.  (Ideally the
332 expect-send strings for chat should be in a file.)
333
334 The "&& sleep 5" causes the script to pause for 5 seconds, unless chat
335 fails in which case it exits immediately.  This is just to give the
336 PPP server time to start (it's very slow).  Also, the "stty -echo"
337 turned out to be very important for me; without it, my pppd would
338 sometimes start to send negotiation packets before the remote PPP
339 server had time to turn off echoing.  The negotiation packets would
340 then get sent back to my local machine, be rejected (PPP is able to
341 detect loopback) and pppd would fail before the remote PPP server even
342 got going.  The "stty -echo" command prevents this confusion.  This
343 kind of problem should only ever affect a *very* few people who
344 connect to a PPP server that runs as a command on a slow Unix machine,
345 but I wanted to mention it because it took me several frustrating
346 hours to figure out.
347
348 The pppd options are mostly familiar.  Two that are new are
349 "noipdefault" and "kdebug 2".  "noipdefault" tells pppd to ask the
350 remote end for the IP address to use; this is necessary if the PPP
351 server implements dynamic IP address assignment as mine does (i.e., I
352 don't know what address I'll get ahead of time).  "kdebug 2" sets the
353 kernel debugging level to 2, enabling slightly chattier messages from
354 the ppp kernel code.
355
356
357
358 Anyway, assuming your connection is working, you should see chat dial
359 the modem, then perhaps some messages from pppd (depending on your
360 syslog.conf setup), then some kernel messages like this:
361
362         ppp: channel ppp0 mtu changed to 1500
363         ppp: channel ppp0 open
364         ppp: channel ppp0 going up for IP packets!
365
366 (These messages will only appear if you gave the option "kdebug 2" and
367 have kern.info messages directed to the screen.)  Simultaneously, pppd
368 is also writing interesting things to /usr/adm/messages (or other log
369 file, depending on syslog.conf).
370
371 IF IT WORKS
372
373 If you think you've got a connection, there are a number of things you
374 can do to test it.
375
376 First, type
377         /sbin/ifconfig
378 (ifconfig may live elsewhere, depending on your distribution.)  This
379 should show you all the network interfaces that are 'UP'.  ppp0 should
380 be one of them, and you should recognize the first IP address as your
381 own and the "POINT-TO-POINT ADDR" as the address of your server.
382 Here's what it looks like on my machine:
383
384 lo        Link encap Local Loopback  
385           inet addr 127.0.0.1  Bcast 127.255.255.255  Mask 255.0.0.0
386           UP LOOPBACK RUNNING  MTU 2000  Metric 1
387           RX packets 0 errors 0 dropped 0 overrun 0
388           TX packets 0 errors 0 dropped 0 overrun 0
389
390 ppp0      Link encap Serial Line IP  
391           inet addr 192.76.32.2  P-t-P 129.67.1.165  Mask 255.255.255.0
392           UP POINTOPOINT RUNNING  MTU 1500  Metric 1
393           RX packets 33 errors 0 dropped 0 overrun 0
394           TX packets 42 errors 0 dropped 0 overrun 0
395
396 Now, type
397         ping z.z.z.z
398 where z.z.z.z is the address of your server.  This should work.
399 Here's what it looks like for me:
400   waddington:~$ ping 129.67.1.165
401   PING 129.67.1.165 (129.67.1.165): 56 data bytes
402   64 bytes from 129.67.1.165: icmp_seq=0 ttl=255 time=268 ms
403   64 bytes from 129.67.1.165: icmp_seq=1 ttl=255 time=247 ms
404   64 bytes from 129.67.1.165: icmp_seq=2 ttl=255 time=266 ms
405   ^C
406   --- 129.67.1.165 ping statistics ---
407   3 packets transmitted, 3 packets received, 0% packet loss
408   round-trip min/avg/max = 247/260/268 ms
409   waddington:~$
410
411 Try typing:
412         netstat -nr
413 This should show three routes, something like this:
414 Kernel routing table
415 Destination     Gateway         Genmask         Flags Metric Ref Use    Iface
416 129.67.1.165    0.0.0.0         255.255.255.255 UH    0      0        6 ppp0
417 127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
418 0.0.0.0         129.67.1.165    0.0.0.0         UG    0      0     6298 ppp0
419
420 If your output looks similar but doesn't have the destination 0.0.0.0
421 line (which refers to the default route used for connections), you may
422 have run pppd without the 'defaultroute' option.
423
424 At this point you can try telnetting/ftping/fingering whereever you
425 want, bearing in mind that you'll have to use numeric IP addresses
426 unless you've set up your /etc/resolv.conf correctly.
427
428 IF IT DOESN'T WORK
429
430 If you don't seem to get a connection, the thing to do is to collect
431 'debug' output from pppd.  To do this, make sure you run pppd with the
432 'debug' option, and put the following two lines in your
433 /etc/syslog.conf file:
434     daemon,local2.*                             /dev/console
435     daemon,local2.*                             /usr/adm/ppplog
436 This will cause pppd's messages to be written to the current virtual
437 console and to the file /usr/adm/ppplog.  Note that the left-hand
438 field and the right-hand field must be separated by at least one TAB
439 character.  After modifying /etc/syslog.conf, you must execute the
440 command 'kill -HUP <pid>' where <pid> is the process ID of the
441 currently running syslogd process to cause it to re-read the
442 configuration file.
443
444 Some messages to look for: 
445   - "pppd[NNN]: Connected..." means that the "connect" script has
446     completed successfully.  
447   - "pppd[NNN]: sent [LCP ConfReq"... means that pppd has attempted to
448     begin negotiation with the remote end.  
449   - "pppd[NNN]: recv [LCP ConfReq"... means that pppd has received a
450     negotiation frame from the remote end.
451   - "pppd[NNN]: ipcp up" means that pppd has reached the point where
452     it believes the link is ready for IP traffic to travel across it.
453
454 If you never see a "recv" message then there may be serious problems
455 with your link.  (For example, the link may not be passing all 8
456 bits.)  If that's the case, it would be useful to collect a debug log
457 which contains all the bytes being passed between your computer and
458 the remote PPP server.  To do this, alter your syslog.conf lines to
459 look like this
460     local2.*,kern.*                             /dev/console
461     local2.*,kern.*                             /usr/adm/ppplog
462 and HUP the syslog daemon as before.  Then, run pppd with the option
463 "kdebug 5".  Whatever characters arrive over the PPP terminal line
464 will appear in the debugging output.
465
466 Occasionally you may see a message like
467    ppp_toss: tossing frame, reason = 4
468 The PPP code is throwing away a packet ("frame") from the remote
469 server because of a serial overrun.  This means your CPU isn't able to
470 read characters from the serial port as quickly as they arrive; the
471 best solution is to get a 16550A serial chip, which gives the CPU some
472 grace period.  Reasons other than 4 indicate other kinds of serial
473 errors, which should not occur.
474
475 During the initial connection sequence, you may see one or more
476 messages which indicate "bad fcs".  This refers to a checksum error in
477 a received PPP frame, and usually occurs at the start of a session
478 when the peer system is sending some "text" messages, such as "hello
479 this is the XYZ company".  Messages of "bad fcs" once the link is
480 established and the routes have been added are not normal and indicate
481 transmssion errors or noise on the telephone line.
482
483 IF IT STILL DOESN'T WORK (OR, BUG REPORTS)
484
485 If you're still having difficulty, send the linux-activists PPP
486 channel a bug report.  It is extremely important to include as much
487 information as possible; for example:
488  - the version number of the kernel you are using
489  - the version number of Linux PPP you are using
490  - the exact command you use to start the PPP session
491  - log output from a session run with the 'debug' option, captured
492    using local2.*,kern.* in your syslog.conf file
493  - the type of PPP peer that you are connecting to (eg, Xyzzy Corp
494    terminal server, Morningstar PPP software, etc)
495  - the kind of connection you use (modem, hardwired, etc...)
496
497 DYNAMIC ADDRESS ASSIGNMENT
498
499 You can use Linux PPP with a PPP server which assigns a different IP
500 address every time you connect.  You need to use the 'noipdefault'
501 option to tell pppd to request the IP address from the remote host.
502
503 Sometimes you may get an error message like "Cannot assign requested
504 address" when you use a Linux client (for example, "talk").  This
505 happens when the IP address given in /etc/hosts for our hostname
506 differs from the IP address used by the PPP interface.  The solution
507 is to use ifconfig ppp0 to get the interface address and then edit
508 /etc/hosts appropriately.
509
510 SETTING UP A MACHINE FOR INCOMING PPP CONNECTIONS
511
512 Suppose you want to permit another machine to call yours up and start
513 a PPP session.  This is possible using Linux PPP.
514
515 One way is to create an account named, say, 'ppp', with the login
516 shell being a short script that starts pppd.  For example, the passwd
517 entry might look like this:
518   ppp:(encrypted password):102:50:PPP client login:/tmp:/etc/ppp/ppplogin
519 Here the file /etc/ppp/ppplogin would be an executable script
520 containing something like:
521   #!/bin/sh
522   exec /usr/etc/pppd passive :192.1.2.23
523 Here we will insist that the remote machine use IP address 192.1.2.23,
524 while the local PPP interface will use the IP address associated with
525 this machine's hostname in /etc/hosts.  The 'passive' option (which is
526 not required) just means that pppd will try to open negotiations when
527 it starts, but if it receives no reply it will just wait silently.
528 This is appropriate if the remote end might take some time before it's
529 ready to negotiate.  (Note that the meaning of the 'passive' option
530 changed between ppp-1.3 and ppp-2.0.)
531
532 This setup is sufficient if you just want to connect two machines so
533 that they can talk to one another.  If you want to use Linux PPP to
534 connect a single machine to an entire network, or to connect two
535 networks together, then you need to arrange for packets to be routed
536 from the networks to the PPP link.  Setting up a link between networks
537 is beyond the scope of this document; you should examine the routing
538 options in the manual page for pppd carefully and find out about
539 routed, etc.
540
541 Let's consider just the first case.  Suppose you have a Linux machine
542 attached to an Ethernet, and you want to allow its PPP peer to be able
543 to communicate with hosts on that Ethernet.  To do this, you should
544 have the remote machine use an IP address that would normally appear
545 to be on the local Ethernet segment and you should give the 'proxyarp'
546 option to pppd on the server.  Suppose, for example, we have this
547 setup:
548
549  192.1.2.23                        192.1.2.17
550 +-----------+      PPP link       +----------+
551 | chelseapc | ------------------- |  billpc  |
552 +-----------+                     +----------+
553                                         |           Ethernet 
554                             ----------------------------------- 192.1.2.x 
555
556 Here the PPP and Ethernet interfaces of billpc will have IP address
557 192.1.2.17.  (It's OK for one or more PPP interfaces on a machine to
558 share an IP address with an Ethernet interface.)  There is an
559 appropriate entry in /etc/passwd on billpc to allow chelseapc to call
560 in, with the /etc/ppp/ppplogin script containing
561   #!/bin/sh
562   exec /usr/etc/pppd passive proxyarp :192.1.2.23
563 When the link comes up, pppd will enter a "proxy arp" entry for
564 chelseapc into the arp table on billpc.  What this means effectively
565 is that billpc will pretend to the other machines on the 192.1.2.x
566 Ethernet that its Ethernet interface is ALSO the interface for
567 chelseapc (192.1.2.23) as well as billpc (192.1.2.17).  In practice
568 this means that chelseapc can communicate just as if it was directly
569 connected to the Ethernet.
570
571 ADDING MORE PPP CHANNELS
572
573 By default, Linux PPP comes with 4 kernel channels, which means that
574 at most 4 simultaneous PPP sessions are possible.  If you desire more
575 such sessions (for example if you are serving many dialup lines), you
576 can easily reconfigure the kernel to add new channels.  There are two
577 steps.
578
579 First you need to edit the kernel file drivers/net/Space.c .  As
580 distributed, it contains a section that looks like this:
581   
582 #if defined(CONFIG_PPP)
583 extern int ppp_init(struct device *);
584 static struct device ppp3_dev = {
585     "ppp3", 0x0, 0x0, 0x0, 0x0, 3, 0, 0, 0, 0, NEXT_DEV,  ppp_init, };
586 static struct device ppp2_dev = {
587     "ppp2", 0x0, 0x0, 0x0, 0x0, 2, 0, 0, 0, 0, &ppp3_dev, ppp_init, };
588 static struct device ppp1_dev = {
589     "ppp1", 0x0, 0x0, 0x0, 0x0, 1, 0, 0, 0, 0, &ppp2_dev, ppp_init, };
590 static struct device ppp0_dev = {
591     "ppp0", 0x0, 0x0, 0x0, 0x0, 0, 0, 0, 0, 0, &ppp1_dev, ppp_init, };
592 #undef NEXT_DEV
593 #define NEXT_DEV (&ppp0_dev)
594 #endif   /* PPP */
595
596 The pattern should be obvious.  For more channels, you need to add
597 more "static struct device pppN_dev" lines, changing the first, sixth
598 and eleventh structure entries as appropriate.  The highest numbered
599 PPP device should have NEXT_DEV in its eleventh structure field, and
600 you should change the ppp3_dev structure to have &ppp4_dev there
601 instead.
602
603 For example, to add 2 extra channels, you would have
604
605 #if defined(CONFIG_PPP)
606 extern int ppp_init(struct device *);
607 static struct device ppp5_dev = {
608     "ppp5", 0x0, 0x0, 0x0, 0x0, 5, 0, 0, 0, 0, NEXT_DEV,  ppp_init, };
609 static struct device ppp4_dev = {
610     "ppp4", 0x0, 0x0, 0x0, 0x0, 4, 0, 0, 0, 0, &ppp5_dev,  ppp_init, };
611 static struct device ppp3_dev = {
612     "ppp3", 0x0, 0x0, 0x0, 0x0, 3, 0, 0, 0, 0, &ppp4_dev,  ppp_init, };
613 ... etc.
614
615 Second, you need to change the line in ppp.h (in include/linux) to
616 change the line that reads
617
618 #define PPP_NRUNIT     4
619
620 to show the new number of channels; in our case it would become
621
622 #define PPP_NRUNIT     6
623
624 Finally, recompile and reboot.  The bootup message and the contents of
625 /proc/net/dev should show the correct number of channels.
626
627 CHANGES FROM LINUX PPP 0.1.x
628
629 Linux PPP 0.1.x was based on the free PPP package PPP-1.3.  Linux PPP
630 0.2.1 is based on PPP-2.0.4.  There have been some changes to the pppd
631 options along with significant enhancements.  You should read
632 "RELNOTES" in the pppd directory for a description of the changes.
633
634 Also, some options which were added to PPP-1.3 for the Linux version
635 have now changed names:
636     'defroute'  is now 'defaultroute'
637     'kerndebug' is now 'kdebug'
638     'dropdtr'   is now 'modem'
639 In addition, it is now necessary to use the 'noipdefault' option if
640 you want to get the local IP address from the remote PPP server.
641
642 CONCLUSION
643
644 Good luck!
645
646 Michael