Based on kernel version 4.16.1. Page generated on 2018-04-09 11:53 EST.
1 simple isdn4linux PPP FAQ .. to be continued .. not 'debugged' 2 ------------------------------------------------------------------- 3 4 Q01: what's pppd, ipppd, syncPPP, asyncPPP ?? 5 Q02: error message "this system lacks PPP support" 6 Q03: strange information using 'ifconfig' 7 Q04: MPPP?? What's that and how can I use it ... 8 Q05: I tried MPPP but it doesn't work 9 Q06: can I use asynchronous PPP encapsulation with network devices 10 Q07: A SunISDN machine can't connect to my i4l system 11 Q08: I wanna talk to several machines, which need different configs 12 Q09: Starting the ipppd, I get only error messages from i4l 13 Q10: I wanna use dynamic IP address assignment 14 Q11: I can't connect. How can I check where the problem is. 15 Q12: How can I reduce login delay? 16 17 ------------------------------------------------------------------- 18 19 Q01: pppd, ipppd, syncPPP, asyncPPP .. what is that ? 20 what should I use? 21 A: 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 47 Q02: when I start the ipppd .. I only get the 48 error message "this system lacks PPP support" 49 A: 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) ... 56 A: Maybe you have compiled the ipppd with another 57 kernel source tree than the kernel you currently 58 run ... 59 60 -- 61 62 Q03: 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 65 A: The device is a fake ethernet device .. ignore IRQ and baseaddr 66 You need the HWaddr only for ethernet encapsulation. 67 68 -- 69 70 Q04: MPPP?? What's that and how can I use it ... 71 72 A: 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 93 Q05: 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 98 A: you forgot to compile MPPP/RFC1717 support into the 99 ISDN Subsystem. Recompile with this option enabled. 100 101 -- 102 103 Q06: can I use asynchronous PPP encapsulation 104 over the network interface of isdn4linux .. 105 106 A: 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 112 Q07: 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 117 A: 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 121 A: (from Alexanter Strauss: ) 122 !![ ... fill in mail ]!! 123 124 -- 125 126 Q08: 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 132 A: 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 138 Q09: When I start the ipppd I only get error messages 139 from the i4l driver .. 140 141 A: 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 152 Q10: I wanna use dynamic IP address assignment ... How 153 must I configure the network device. 154 155 A: 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 169 A: 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 184 A: 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 193 Q11: I can't connect. How can I check where the problem is. 194 195 A: 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 215 Q12: How can I reduce login delay? 216 217 A: 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