12. syncppp: Sync PPP

12.1 syncppp_whichppp: pppd, ipppd, syncPPP, asyncPPP .. what is they? Which should I use?

See this question in the asnyc PPP; section: asyncppp_whichppp.

12.2 syncppp_compile: How do I compile isdn4linux with syncPPP?

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.)

12.3 syncppp_netinterface: How should I name my network interface?

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 ifconfig.

12.4 syncppp_config: How do I configure isdn4linux with syncPPP?

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/ippp0 to /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 level.

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 etc/rc.isdn.syncppp in the isdn4kernel-util package.

You can also run several ipppds to allow for different configurations, in such a case use the "isdnctrl pppbind" 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.

12.5 syncppp_busy: How can I tell if a connection is unsuccessful (busy)?

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 "Local IP: x.y.z.a" and/or "Remote IP: x.y.z.a" in syslog. In either case, the connection is up.

12.6 syncppp_logindelay: How can I reduce login delay?

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".

12.7 syncppp_2configs: I want to talk to remote machines which needs different configurations. 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.

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

12.8 syncppp_pppbind: How does the (little-documented) "pppbind" command in isdnctrl work?

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"

12.9 syncppp_dynip: I want to use dynamic IP address assignment. How must I configure the network device?

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

12.10 syncppp_msgetdns: How do I configure ipppd to obtain or provide the nameserver address at dial in?

Use the configuration option ms-get-dns to obtain the nameserver ip address when you dial up your internet provider. Use ms-dns to publish the nameserver ip address when someone dials up your ipppd.

12.11 syncppp_ipx: How can I do IPX over ipppd?

Give the option +ipx-protocol to the ipppd.

12.12 syncppp_faster: How can I increase my PPP data transfer rates?

You can establish more channels with MPPP (see the MPPP section). Another way is to use compression, see question syncppp_compression.

12.13 syncppp_compression: Which compressions can I use with ipppd?

Several compressions can now be used with ipppd. However, if in doubt and it does not work: disable it.

• Van Jacobson compression (header compression). Should work fine now for current kernels (later than 2.2.14). To use it you have to compile it into the kernel. To get around some problems with automatic loading of the VJ module try to also compile SLIP and CSLIP into the kernel. Disable with options "-vj -vjccomp".
• BSD compression. Seems to work quite well if your peer supports it. It is independent of Van Jacobson compression, so you can use them both together.
• LZS compression (sometimes also called Stac compression). Also works quite well. To enable it, some manual work has to be done to add the code to the ipppd (see the isdn4k-util package).

12.14 syncppp_strategy: I can't get a connect. How can I find out where the problem is?

The output of ipppd is very helpful... (see next question: syncppp_log)

• Have a look at the error messages and see the following questions...
• Check whether you can find a few "LCP-conf-req SENT" messages (less than ten) and then a "TERM-REF".
• Check whether the ISDN card was configured properly. It seems the computer doesn't dial (IRQ, IO, protocol wrong?)
• At least a few "RECV" messages: good! The card is dialing and your dialin computer tries to communicate. Maybe the pap/chap authentication doesn't work (see question pap). Check the ipppd configuration!
• The message that ipppd was exited for some reason: not so good! Check /var/log/messages, /var/log/debug, and /var/adm/daemon (if existing). Could be a bug in ipppd.
• The error/cause E0010 is NOT an error! It is just the informal message that the call has ended.

12.15 syncppp_log: How can I get a log for ipppd?

Normally when giving the option "debug" to ipppd, the debbuging output may be logged in /var/log/messages, /var/log/debug, or /var/adm/daemon (depends on your distribution, look around).

For debugging purposes you can redirect the PPP log into a separate file. Just edit /etc/syslog.conf and add the following line (caution: do NOT use blanks or tabs - check "man syslog.conf(5)" for more details):

daemon.*                      /var/log/ppp-log

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.

12.16 syncppp_nopppsupport: Starting ipppd I get the error message "this systems lacks ppp support" or "isdn driver is out of date. maybe ippp0 has no syncppp0 encapsulation".

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...)

12.17 syncppp_nousabledevice: When I try to start ipppd it says "Can't find usable ippp device"

This message occurs when the linklevel interface is told to dial out, but ipppd is not running, or not available.

12.18 syncppp_starterror: When I start ipppd, I only get error messages from the i4l driver.

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.

12.19 syncppp_framesdelayed: I get the message IP frames delayed - but no connection.

Have you really dialed out? Check question dialout_dialmode and your configuration on the different dialmodes.

12.20 syncppp_noroute: I cannot dial out with 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.

12.21 syncppp_nodefaultroute: After ipppd dials out my default route is gone.

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

12.22 syncppp_packettoolarge: I often get the error message 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).

12.23 syncppp_slow: The connection with ipppd seems to work, but eventually it crashes or is very slow.

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.

12.24 syncppp_loadproblem: I only have problems with ipppd when the connection is being heavily burdened. Then everything stops. What could be causing this?

Sven Engelhardt sven@sik.de 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: http://www.winfiles.com/connect/trouble.html)

Erik Corry ec@sign-tronic.dk 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.

12.25 syncppp_mtu: My ipppd works, but I keep getting the message pppd(104): ioctl(SIOCSIFMTU): Invalid argument"?

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).

12.26 syncppp_1stpacket: The first IP packet gets lost on automatic dialout with dynamic IP address allocation.

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:

• Dial out manually with "isdnctrl dial ippp*"
• Use diald to control when the connection goes up or down.
• Get a permanent IP address
• A workaround is included in the newest kernels, which can be activated like this:

  ---

  echo 7 > /proc/sys/net/ipv4/ip_dynaddr
  

  ---

  (use 5 instad of 7 to not get warnings into /var/log/messages) If you have a SuSE distribution, this workaround can also be configured by setting IP_DYNIP="yes" in /etc/rc.config.
• Increase the number of retries on your Windows machine for setting up the connection. Change the registry entry Hkey_Local_Machine\\System\\CurrentControlSet\\Services\\VxD\\MSTCP\\MaxConnectRetries from 3 to a larger value (e.g. 5 or 7).

12.27 syncppp_droppacket: What does the message "No phone number, packet dropped" mean?

Michael Engert michi@bello.wor.de 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.

12.28 syncppp_leadingzero: Why does my ipppd dial one too many zeros ("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 to the isdnctrl dialmax parameter.

12.29 syncppp_ethfake: My ISDN device is shown with HWaddr and IRQ=0 and base address = 0 when I list it with ifconfig

The ISDN device fakes an Ethernet device. It ignores IRQ and baseaddr and just needs the HWaddr for the Ethernet encapsulation.

12.30 syncppp_lzsproblem: I get an error message like 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 providing noccp as an option for ipppd, or compile and load the lzs module.