1simple isdn4linux PPP FAQ .. to be continued .. not 'debugged' 
2-------------------------------------------------------------------
3
4Q01: what's pppd, ipppd, syncPPP, asyncPPP ??
5Q02: error message "this system lacks PPP support"
6Q03: strange information using 'ifconfig'
7Q04: MPPP?? What's that and how can I use it ...
8Q05: I tried MPPP but it doesn't work 
9Q06: can I use asynchronous PPP encapsulation with network devices
10Q07: A SunISDN machine can't connect to my i4l system
11Q08: I wanna talk to several machines, which need different configs
12Q09: Starting the ipppd, I get only error messages from i4l
13Q10: I wanna use dynamic IP address assignment 
14Q11: I can't connect. How can I check where the problem is.
15Q12: How can I reduce login delay? 
16
17-------------------------------------------------------------------
18
19Q01: pppd, ipppd, syncPPP, asyncPPP .. what is that ?
20   what should I use?
21A: The pppd is for asynchronous PPP .. asynchronous means
22   here, the framing is character based. (e.g when
23   using ttyI* or tty* devices)
24
25   The ipppd handles PPP packets coming in HDLC
26   frames (bit based protocol) ... The PPP driver
27   in isdn4linux pushes all IP packets direct
28   to the network layer and all PPP protocol
29   frames to the /dev/ippp* device. 
30   So, the ipppd is a simple external network
31   protocol handler.
32
33   If you login into a remote machine using the
34   /dev/ttyI* devices and then enable PPP on the
35   remote terminal server -> use the 'old' pppd
36
37   If your remote side immediately starts to send
38   frames ... you probably connect to a 
39   syncPPP machine .. use the network device part
40   of isdn4linux with the 'syncppp' encapsulation
41   and make sure, that the ipppd is running and 
42   connected to at least one /dev/ippp*. Check the 
43   isdn4linux manual on how to configure a network device.
44
45--
46
47Q02: when I start the ipppd .. I only get the
48   error message "this system lacks PPP support"
49A: check that at least the device 'ippp0' exists.
50   (you can check this e.g with the program 'ifconfig')
51   The ipppd NEEDS this device under THIS name .. 
52   If this device doesn't exists, use:
53	isdnctrl addif ippp0
54	isdnctrl encap ippp0 syncppp
55	... (see isdn4linux doc for more) ...
56A: Maybe you have compiled the ipppd with another
57   kernel source tree than the kernel you currently
58   run ... 
59
60--
61
62Q03: when I list the netdevices with ifconfig I see, that
63   my ISDN interface has a HWaddr and IRQ=0 and Base 
64   address = 0 
65A: The device is a fake ethernet device .. ignore IRQ and baseaddr
66   You need the HWaddr only for ethernet encapsulation.
67   
68--
69
70Q04: MPPP?? What's that and how can I use it ...
71
72A: MPPP or MP or MPP (Warning: MP is also an 
73   acronym for 'Multi Processor') stands for
74   Multi Point to Point and means bundling
75   of several channels to one logical stream.
76   To enable MPPP negotiation you must call the
77   ipppd with the '+mp' option. 
78   You must also configure a slave device for
79   every additional channel. (see the i4l manual
80   for more)
81   To use channel bundling you must first activate
82   the 'master' or initial call. Now you can add 
83   the slave channels with the command:
84       isdnctrl addlink <device>
85   e.g:
86       isdnctrl addlink ippp0
87   This is different from other encapsulations of
88   isdn4linux! With syncPPP, there is no automatic
89   activation of slave devices.
90
91--
92
93Q05: I tried MPPP but it doesn't work .. the ipppd
94   writes in the debug log something like:
95   .. rcvd [0][proto=0x3d] c0 00 00 00 80 fd 01 01 00 0a ...
96   .. sent [0][LCP ProtRej id=0x2 00 3d c0 00 00 00 80 fd 01 ...
97
98A: you forgot to compile MPPP/RFC1717 support into the
99   ISDN Subsystem. Recompile with this option enabled.
100
101--
102
103Q06: can I use asynchronous PPP encapsulation
104   over the network interface of isdn4linux ..
105
106A: No .. that's not possible .. Use the standard
107   PPP package over the /dev/ttyI* devices. You
108   must not use the ipppd for this.
109   
110--
111
112Q07: A SunISDN machine tries to connect my i4l system,
113   which doesn't work.
114   Checking the debug log I just saw garbage like:
115!![ ... fill in the line ... ]!!
116
117A: The Sun tries to talk asynchronous PPP ... i4l
118   can't understand this ... try to use the ttyI*
119   devices with the standard PPP/pppd package
120
121A: (from Alexanter Strauss: )
122!![ ... fill in mail ]!!
123
124--
125
126Q08: I wanna talk to remote machines, which need
127   a different configuration. The only way
128   I found to do this is to kill the ipppd and
129   start a new one with another config to connect
130   to the second machine. 
131
132A: you must bind a network interface explicitly to
133   an ippp device, where you can connect a (for this
134   interface) individually configured ipppd.
135
136--
137
138Q09: When I start the ipppd I only get error messages
139   from the i4l driver .. 
140
141A: When starting, the ipppd calls functions which may 
142   trigger a network packet. (e.g gethostbyname()).
143   Without the ipppd (at this moment, it is not
144   fully started) we can't handle this network request.
145   Try to configure hostnames necessary for the ipppd
146   in your local /etc/hosts file or in a way, that
147   your system can resolve it without using an
148   isdn/ippp network-interface.
149
150--
151
152Q10: I wanna use dynamic IP address assignment ... How 
153   must I configure the network device.
154
155A: At least you must have a route which forwards
156   a packet to the ippp network-interface to trigger
157   the dial-on-demand.
158   A default route to the ippp-interface will work.
159   Now you must choose a dummy IP address for your
160   interface.
161   If for some reason you can't set the default
162   route to the ippp interface, you may take any 
163   address of the subnet from which you expect your
164   dynamic IP number and set a 'network route' for
165   this subnet to the ippp interface.
166   To allow overriding of the dummy address you
167   must call the ipppd with the 'ipcp-accept-local' option.
168
169A: You must know, how the ipppd gets the addresses it wanna
170   configure. If you don't give any option, the ipppd
171   tries to negotiate the local host address!
172   With the option 'noipdefault' it requests an address
173   from the remote machine. With 'useifip' it gets the
174   addresses from the net interface. Or you set the address
175   on the option line with the <a.b.c.d:e.f.g.h> option.
176   Note: the IP address of the remote machine must be configured
177   locally or the remote machine must send it in an IPCP request.
178   If your side doesn't know the IP address after negotiation, it
179   closes the connection!
180   You must allow overriding of address with the 'ipcp-accept-*'
181   options, if you have set your own or the remote address 
182   explicitly.
183
184A: Maybe you try these options .. e.g:   
185
186    /sbin/ipppd :$REMOTE noipdefault /dev/ippp0
187
188   where REMOTE must be the address of the remote machine (the
189   machine, which gives you your address)
190
191--
192
193Q11: I can't connect. How can I check where the problem is.
194
195A: A good help log is the debug output from the ipppd...
196   Check whether you can find there:
197   - only a few LCP-conf-req SENT messages (less then 10)
198     and then a Term-REQ:
199     -> check whether your ISDN card is well configured
200        it seems, that your machine doesn't dial
201        (IRQ,IO,Proto, etc problems)
202        Configure your ISDN card to print debug messages and
203        check the /dev/isdnctrl output next time. There
204        you can see, whether there is activity on the card/line.
205   - there are at least a few RECV messages in the log:
206     -> fine: your card is dialing and your remote machine
207        tries to talk with you. Maybe only a missing 
208        authentication. Check your ipppd configuration again.
209   - the ipppd exits for some reason:
210     -> not good ... check /var/adm/syslog and /var/adm/daemon.
211        Could be a bug in the ipppd.
212
213--
214
215Q12: How can I reduce login delay?
216
217A: Log a login session ('debug' log) and check which options 
218  your remote side rejects. Next time configure your ipppd
219  to not negotiate these options. Another 'side effect' is, that
220  this increases redundancy. (e.g your remote side is buggy and
221  rejects options in a wrong way).
222
223
224
225