Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
		
			
				
	
	
		
			224 lines
		
	
	
	
		
			7.9 KiB
			
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			224 lines
		
	
	
	
		
			7.9 KiB
			
		
	
	
	
		
			Text
		
	
	
	
	
	
simple isdn4linux PPP FAQ .. to be continued .. not 'debugged' 
 | 
						|
-------------------------------------------------------------------
 | 
						|
 | 
						|
Q01: what's pppd, ipppd, syncPPP, asyncPPP ??
 | 
						|
Q02: error message "this system lacks PPP support"
 | 
						|
Q03: strange information using 'ifconfig'
 | 
						|
Q04: MPPP?? What's that and how can I use it ...
 | 
						|
Q05: I tried MPPP but it doesn't work 
 | 
						|
Q06: can I use asynchronous PPP encapsulation with network devices
 | 
						|
Q07: A SunISDN machine can't connect to my i4l system
 | 
						|
Q08: I wanna talk to several machines, which need different configs
 | 
						|
Q09: Starting the ipppd, I get only error messages from i4l
 | 
						|
Q10: I wanna use dynamic IP address assignment 
 | 
						|
Q11: I can't connect. How can I check where the problem is.
 | 
						|
Q12: How can I reduce login delay? 
 | 
						|
 | 
						|
-------------------------------------------------------------------
 | 
						|
 | 
						|
Q01: pppd, ipppd, syncPPP, asyncPPP .. what is that ?
 | 
						|
   what should I use?
 | 
						|
A: The pppd is for asynchronous PPP .. asynchronous means
 | 
						|
   here, the framing is character based. (e.g when
 | 
						|
   using ttyI* or tty* devices)
 | 
						|
 | 
						|
   The ipppd handles PPP packets coming in HDLC
 | 
						|
   frames (bit based protocol) ... The PPP driver
 | 
						|
   in isdn4linux pushes all IP packets direct
 | 
						|
   to the network layer and all PPP protocol
 | 
						|
   frames to the /dev/ippp* device. 
 | 
						|
   So, the ipppd is a simple external network
 | 
						|
   protocol handler.
 | 
						|
 | 
						|
   If you login into a remote machine using the
 | 
						|
   /dev/ttyI* devices and then enable PPP on the
 | 
						|
   remote terminal server -> use the 'old' pppd
 | 
						|
 | 
						|
   If your remote side immediately starts to send
 | 
						|
   frames ... you probably connect to a 
 | 
						|
   syncPPP machine .. use the network device part
 | 
						|
   of isdn4linux with the 'syncppp' encapsulation
 | 
						|
   and make sure, that the ipppd is running and 
 | 
						|
   connected to at least one /dev/ippp*. Check the 
 | 
						|
   isdn4linux manual on how to configure a network device.
 | 
						|
 | 
						|
--
 | 
						|
 | 
						|
Q02: when I start the ipppd .. I only get the
 | 
						|
   error message "this system lacks PPP support"
 | 
						|
A: check that at least the device 'ippp0' exists.
 | 
						|
   (you can check this e.g with the program 'ifconfig')
 | 
						|
   The ipppd NEEDS this device under THIS name .. 
 | 
						|
   If this device doesn't exists, use:
 | 
						|
	isdnctrl addif ippp0
 | 
						|
	isdnctrl encap ippp0 syncppp
 | 
						|
	... (see isdn4linux doc for more) ...
 | 
						|
A: Maybe you have compiled the ipppd with another
 | 
						|
   kernel source tree than the kernel you currently
 | 
						|
   run ... 
 | 
						|
 | 
						|
--
 | 
						|
 | 
						|
Q03: when I list the netdevices with ifconfig I see, that
 | 
						|
   my ISDN interface has a HWaddr and IRQ=0 and Base 
 | 
						|
   address = 0 
 | 
						|
A: The device is a fake ethernet device .. ignore IRQ and baseaddr
 | 
						|
   You need the HWaddr only for ethernet encapsulation.
 | 
						|
   
 | 
						|
--
 | 
						|
 | 
						|
Q04: MPPP?? What's that and how can I use it ...
 | 
						|
 | 
						|
A: MPPP or MP or MPP (Warning: MP is also an 
 | 
						|
   acronym for 'Multi Processor') stands for
 | 
						|
   Multi Point to Point and means bundling
 | 
						|
   of several channels to one logical stream.
 | 
						|
   To enable MPPP negotiation you must call the
 | 
						|
   ipppd with the '+mp' option. 
 | 
						|
   You must also configure a slave device for
 | 
						|
   every additional channel. (see the i4l manual
 | 
						|
   for more)
 | 
						|
   To use channel bundling you must first activate
 | 
						|
   the 'master' or initial call. Now you can add 
 | 
						|
   the slave channels with the command:
 | 
						|
       isdnctrl addlink <device>
 | 
						|
   e.g:
 | 
						|
       isdnctrl addlink ippp0
 | 
						|
   This is different from other encapsulations of
 | 
						|
   isdn4linux! With syncPPP, there is no automatic
 | 
						|
   activation of slave devices.
 | 
						|
 | 
						|
--
 | 
						|
 | 
						|
Q05: I tried MPPP but it doesn't work .. the ipppd
 | 
						|
   writes in the debug log something like:
 | 
						|
   .. rcvd [0][proto=0x3d] c0 00 00 00 80 fd 01 01 00 0a ...
 | 
						|
   .. sent [0][LCP ProtRej id=0x2 00 3d c0 00 00 00 80 fd 01 ...
 | 
						|
 | 
						|
A: you forgot to compile MPPP/RFC1717 support into the
 | 
						|
   ISDN Subsystem. Recompile with this option enabled.
 | 
						|
 | 
						|
--
 | 
						|
 | 
						|
Q06: can I use asynchronous PPP encapsulation
 | 
						|
   over the network interface of isdn4linux ..
 | 
						|
 | 
						|
A: No .. that's not possible .. Use the standard
 | 
						|
   PPP package over the /dev/ttyI* devices. You
 | 
						|
   must not use the ipppd for this.
 | 
						|
   
 | 
						|
--
 | 
						|
 | 
						|
Q07: A SunISDN machine tries to connect my i4l system,
 | 
						|
   which doesn't work.
 | 
						|
   Checking the debug log I just saw garbage like:
 | 
						|
!![ ... fill in the line ... ]!!
 | 
						|
 | 
						|
A: The Sun tries to talk asynchronous PPP ... i4l
 | 
						|
   can't understand this ... try to use the ttyI*
 | 
						|
   devices with the standard PPP/pppd package
 | 
						|
 | 
						|
A: (from Alexanter Strauss: )
 | 
						|
!![ ... fill in mail ]!!
 | 
						|
 | 
						|
--
 | 
						|
 | 
						|
Q08: I wanna talk to remote machines, which need
 | 
						|
   a different configuration. The only way
 | 
						|
   I found to do this is to kill the ipppd and
 | 
						|
   start a new one with another config to connect
 | 
						|
   to the second machine. 
 | 
						|
 | 
						|
A: you must bind a network interface explicitly to
 | 
						|
   an ippp device, where you can connect a (for this
 | 
						|
   interface) individually configured ipppd.
 | 
						|
 | 
						|
--
 | 
						|
 | 
						|
Q09: When I start the ipppd I only get error messages
 | 
						|
   from the i4l driver .. 
 | 
						|
 | 
						|
A: When starting, the ipppd calls functions which may 
 | 
						|
   trigger a network packet. (e.g gethostbyname()).
 | 
						|
   Without the ipppd (at this moment, it is not
 | 
						|
   fully started) we can't handle this network request.
 | 
						|
   Try to configure hostnames necessary for the ipppd
 | 
						|
   in your local /etc/hosts file or in a way, that
 | 
						|
   your system can resolve it without using an
 | 
						|
   isdn/ippp network-interface.
 | 
						|
 | 
						|
--
 | 
						|
 | 
						|
Q10: I wanna use dynamic IP address assignment ... How 
 | 
						|
   must I configure the network device.
 | 
						|
 | 
						|
A: At least you must have a route which forwards
 | 
						|
   a packet to the ippp network-interface to trigger
 | 
						|
   the dial-on-demand.
 | 
						|
   A default route to the ippp-interface will work.
 | 
						|
   Now you must choose a dummy IP address for your
 | 
						|
   interface.
 | 
						|
   If for some reason you can't set the default
 | 
						|
   route to the ippp interface, you may take any 
 | 
						|
   address of the subnet from which you expect your
 | 
						|
   dynamic IP number and set a 'network route' for
 | 
						|
   this subnet to the ippp interface.
 | 
						|
   To allow overriding of the dummy address you
 | 
						|
   must call the ipppd with the 'ipcp-accept-local' option.
 | 
						|
 | 
						|
A: You must know, how the ipppd gets the addresses it wanna
 | 
						|
   configure. If you don't give any option, the ipppd
 | 
						|
   tries to negotiate the local host address!
 | 
						|
   With the option 'noipdefault' it requests an address
 | 
						|
   from the remote machine. With 'useifip' it gets the
 | 
						|
   addresses from the net interface. Or you set the address
 | 
						|
   on the option line with the <a.b.c.d:e.f.g.h> option.
 | 
						|
   Note: the IP address of the remote machine must be configured
 | 
						|
   locally or the remote machine must send it in an IPCP request.
 | 
						|
   If your side doesn't know the IP address after negotiation, it
 | 
						|
   closes the connection!
 | 
						|
   You must allow overriding of address with the 'ipcp-accept-*'
 | 
						|
   options, if you have set your own or the remote address 
 | 
						|
   explicitly.
 | 
						|
 | 
						|
A: Maybe you try these options .. e.g:   
 | 
						|
 | 
						|
    /sbin/ipppd :$REMOTE noipdefault /dev/ippp0
 | 
						|
 | 
						|
   where REMOTE must be the address of the remote machine (the
 | 
						|
   machine, which gives you your address)
 | 
						|
 | 
						|
--
 | 
						|
 | 
						|
Q11: I can't connect. How can I check where the problem is.
 | 
						|
 | 
						|
A: A good help log is the debug output from the ipppd...
 | 
						|
   Check whether you can find there:
 | 
						|
   - only a few LCP-conf-req SENT messages (less then 10)
 | 
						|
     and then a Term-REQ:
 | 
						|
     -> check whether your ISDN card is well configured
 | 
						|
        it seems, that your machine doesn't dial
 | 
						|
        (IRQ,IO,Proto, etc problems)
 | 
						|
        Configure your ISDN card to print debug messages and
 | 
						|
        check the /dev/isdnctrl output next time. There
 | 
						|
        you can see, whether there is activity on the card/line.
 | 
						|
   - there are at least a few RECV messages in the log:
 | 
						|
     -> fine: your card is dialing and your remote machine
 | 
						|
        tries to talk with you. Maybe only a missing 
 | 
						|
        authentication. Check your ipppd configuration again.
 | 
						|
   - the ipppd exits for some reason:
 | 
						|
     -> not good ... check /var/adm/syslog and /var/adm/daemon.
 | 
						|
        Could be a bug in the ipppd.
 | 
						|
 | 
						|
--
 | 
						|
 | 
						|
Q12: How can I reduce login delay?
 | 
						|
 | 
						|
A: Log a login session ('debug' log) and check which options 
 | 
						|
  your remote side rejects. Next time configure your ipppd
 | 
						|
  to not negotiate these options. Another 'side effect' is, that
 | 
						|
  this increases redundancy. (e.g your remote side is buggy and
 | 
						|
  rejects options in a wrong way).
 | 
						|
 | 
						|
 | 
						|
 |