See this question in the asnyc PPP; section: asyncppp_whichppp.
To compile the kernel with syncPPP included in ISDN4Linux, you have to answer the appropriate questions with "yes". Don't forget to load the module slhc.o before isdn.o, if VJ compression is not compiled into the kernel e.g. if you have no PPP and no CSLIP in the kernel. (Note that the use of VJ is problematic for elder kernels and does not work reliably - however, the support should still be included in the kernel, since there can otherwise be side effects.)
The name of the network interface should always begin with
"ippp", not with "syncppp" or
"isdn"; otherwise the communication with ipppd will not work
correctly. Please note that at least one of the interfaces has to be
"ippp0", otherwise ipppd will not start. Check your
interfaces with the command
Synchronous PPP is simply another encapsulation for ISDN4Linux. This encapsulation is called "syncppp". Here is an example to configure the link level device ippp0:
/sbin/isdnctrl addif ippp0 /sbin/isdnctrl encap ippp0 syncppp
To use these devices you need the program
ipppd, which you have to
configure. You have to start ipppd once after the modules are installed. ipppd
needs to be constantly running to allow dialout/dialin. It communicates with
the isdn4linux link level devices through
/dev/ippp63. A single ipppd can handle all devices at once. If you
want two PPP connections at the same time, you need to bind ipppd to two
devices, etc. As a result,
ipppd provides the network device
ippp0, which can be checked with ifconfig (even so it has the same
name, the network device
ippp0 is not to be confused with
/dev/ippp0 which is used for communication between ipppd and link
ipppd has an additional option: "useifip" uses the IP address of the connected network interface (if it is not 0.0.0.0). (Even then, ipppd tries to use the pointopoint address as the remote IP.) For the beginning, disable all compression (lzs/stac, bsd, van jacobson), later you can try to enable it (see question syncppp_compression).
It is very important to set up the authentication information properly. Improper authentication is probably the most frequently reported problem on the mailing list. Please, work through section pap completely yourself, before asking others for help.
You can find an example configuration in the file
in the isdn4kernel-util package.
You can also run several ipppds to allow for different configurations,
in such a case use the
functionality. However, normally one ipppd is meant to handle all traffic,
so it is highly recommended to only set up several ipppds if their
configuration has to be different.
When giving the option
defaultroute, then you can wait a few seconds, then
check whether the default route exists. Another way, when giving option
useifip is to check whether you find entries like
"Remote IP: x.y.z.a" in syslog.
In either case, the connection is up.
You can write out a login session with ("Debug-Log"), and see which options the other computer is refusing. Next time, configure ipppd without these unused options. A further side effect is that such unused options increase the redundance (e.g. when the other computer has bugs and refuses the options incorrectly). To create a log file, see "How to I create a log for ipppd".
You must bind a network interface explicitly to an ippp device, where you can connect a (for this interface) individually configured ipppd. With the (unfortunately poorly documented) command
isdnctrl pppbind interface Number
You have to first know how ipppd gets its data. All data that come in over the ISDN line is received by the network devices (these are set up with isdnctrl). Then the data given to one of the /dev/ippp* devices - to one where a ipppd daemon is waiting for data.
To the network interfaces, all ipppd's appear to be able to handle the just-received data - therefore it is normally impossible to predict which ipppd will receive data from which network interface.
In practice, you usually install several ipppd's with differing configurations. Each of these should receive data exclusively from a certain network interface (that has also be specially configured). The "pppdbind" command serves just this purpose. With:
"isdnctrl pppbind interface number"
Example: To attach the interface "ippp5" to /dev/ippp2, the following configuration should be used:
"isdnctrl pppbind ippp5 2"
At least you must have a route, which forwards a packet to the ippp network interface to trigger dialing. 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. You must know how the ipppd gets the addresses it has to 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. You also can set the addresses in 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 will close the connection! You must allow overriding of addresses with the 'ipcp-accept-*' options, if you have set your own or the remote address explicitly. Try these options, e.g.:
/sbin/ipppd :$REMOTE noipdefault /dev/ippp0
Use the configuration option
ms-get-dns to obtain the nameserver ip
address when you dial up your internet provider. Use
publish the nameserver ip address when someone dials up your ipppd.
Give the option
+ipx-protocol to the ipppd.
You can establish more channels with MPPP (see the MPPP section). Another way is to use compression, see question syncppp_compression.
Several compressions can now be used with ipppd. However, if in doubt and it does not work: disable it.
The output of ipppd is very helpful... (see next question: syncppp_log)
/var/adm/daemon(if existing). Could be a bug in ipppd.
Normally when giving the option "debug" to ipppd, the debbuging output
may be logged in
/var/adm/daemon (depends on your distribution, look around).
For debugging purposes you can redirect the PPP log into a separate file.
/etc/syslog.conf and add the following line (caution:
do NOT use blanks or tabs - check "man syslog.conf(5)" for more details):
Remove the comment sign in front of this line in /etc/syslog.conf: #*.=debug /tmp/debug After changing this file you can restart syslogd with "kill -1 pid of syslogd". The output in /tmp/debug can be used to optimize the handshaking of PPP options.
Check whether the device "ippp0" exists (i.e. with the program "ifconfig"). See question syncppp_netinterface for details on the naming conventions for net interfaces. The ipppd *needs* this device with exactly *that* name and *syncppp* encapsulation. If it doesn't exist then you have to define it:
isdnctrl addif ippp0 isdnctrl encap ippp0 syncppp (see i4l documentation or question <ref id="syncppp_config" name="syncppp_config"> for more information...)
This message occurs when the linklevel interface is told to dial out, but ipppd is not running, or not available.
When ipppd is started, it calls functions that can trigger a network packet (e.g. gethostbyname()). Without ipppd (since at this time, ipppd it has not been fully started), this network access cannot be processed, You should try to put the needed hostnames in the local /etc/hosts or in some way define the name so that it can be resolved without having the access the ISDN/ippp interface.
IP frames delayed- but no connection.
Have you really dialed out? Check question dialout_dialmode and your configuration on the different dialmodes.
isdnctrl dial ippp0. It seems as if the route to ipppd is missing although I did set it (
network unreachable). With my old kernel 2.0 everything works fine!
In the newer kernels you have to place
route as the very last command
before the dialout command. Otherwise the kernel will delete the route.
It's the kernel's fault. Newer kernels (= 2.0.x) have some changes in the routing. Workaround: install a script /etc/ppp/ip-up like this:
#!/bin/sh /sbin/route add default ippp*
If you make your connections manually, can use something like this script:
/sbin/isdn #! /bin/sh case $1 in on) /sbin/isdnctrl dial ippp0 # build up connection sleep 5 # wait until line open /sbin/route add default ippp0 # set route ;; off) /sbin/isdnctrl hangup ippp0 # hangup connection /sbin/route del default # and delete route again ;; *) echo -e "\a Usage: 'isdn on' or 'isdn off'" ;; esac
route add default, and
route del defaultcommands. Instead, give the "defaultroute" option to ipppd.
hscx_empty_fifo: incoming packet too large
Probably one of the compressions is activated (i4l can't handle those very well). See also next question. Another possible reason could be an IRQ problem - see question "Why should I avoid IRQ 12 and 15 for my ISDN card?". Another problem can be `#' characters in your pap-secrets file. In this case you have to surround user name and/or password with quotation marks (depending on which one is affected).
It could be that some compression is activated (that i4l can't handle properly). Common error: "-vj" has to be used *additionally* to "-vjccomp" (to completely switch off the VJ compression) - the example scripts coming with ipppd don't have that option included already. Other compression modes (bsd, pccomp) can cause trouble, too. Therefore, you should switch off all compression options (see also question syncppp_compression). Also giving the option "noccp" can help.
firstname.lastname@example.org wrote on 12 Dec 1996:
We are an ISP here in Dresden and use Linux (among other systems) for our access (with I4L as well as with external terminal adapters). We have this problem mostly with Windows 95 and NT customers who are using the "included" (modem network) software. It doesn't make any difference whether the customer is dialing with async or sync PPP. It also doesn't matter which modem emulation he is using on his side. What they have in common is that the connection is made with Microsoft modem adapter + Microsoft PPP (although a colleague recently told me about a similar problem with a Macintosh customer). Since it doesn't matter to PPP who is the server and who is the client, ask your ISP what kind of hardware you are dialing into (we have had no problems with Linux customers and Trumpet Winsock users, therefore I suspect a bug in MS-PPP). The following workaround usually works for us: (it's not a cure, but helps to reduce the pain...) * Reduce the Max MTU to 576 or even (296) * Reduce the DefaultRcvWindow to 2144 On the Windows 95 side these are 2 Registry entries; on the Linux side you can set "mtu 576" and "mru 576" in the PPP options. (See also:
email@example.com added on 16 Dec 1996:
For me, neither PPP compression option nor mru/mtu 296 helped. What did help was the AT command: AT&B512 that limits the sent packets to 512 bytes.
If mtu is not set, then a default value is assumed - possibly "0"
(which of course cannot be correct). Add
"mtu 1024" to
your ipppd options (1500 could also be ok).
There are some dialout problems in connection with syncPPP and dynamic IP address allocation. In this case your IP address will change while packets are waiting to be sent. All packets that should be sent before the change in IP address have the wrong response ip address and will therefore never receive an answer. The problem is that this may cause multiple dialouts (see section dod). Possible solutions:
echo 7 > /proc/sys/net/ipv4/ip_dynaddr
Hkey_Local_Machine\\System\\CurrentControlSet\\Services\\VxD\\MSTCP\\MaxConnectRetriesfrom 3 to a larger value (e.g. 5 or 7).
firstname.lastname@example.org wrote in Nov/Dec 1996:
That means that your computer has an IP packet from somewhat who was logged on a few seconds before, but has since broken the connection. Your computer tries to send this packet on and finds an appropriate route. But the interface isdn(0|1|...) can't reach the other computer, since it has no telephone number to dial.
"ippp0: dialing 0 089XXXXXX...")? I don't have any extensions!
The first zero is not dialed. It only shows the retry counter, which is related
isdnctrl dialmax parameter.
The ISDN device fakes an Ethernet device. It ignores IRQ and baseaddr and just needs the HWaddr for the Ethernet encapsulation.
kernel check for lzs failed?
This means that ipppd tries to use lzs compression, but can't find a
compiled module which contains the code. The error message is only cosmetic,
since the system will still work fine. Either disable lzs compression by
noccp as an option for ipppd, or compile and load the