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):
daemon.* /var/log/ppp-log
ste@esqhen.su.eunet.de also wrote:
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"). The ipppd *needs* this device with exactly *that* name. If it doesn't exist one has to define it:
isdnctrl addif ippp0 isdnctrl encap ippp0 syncppp ... (see i4l documentation for more information) ...
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.
This message occurs when the linklevel interface is told to dial out, but ipppd is not running, or not available.
The output of ipppd is very helpful...
See last question: You may have forgotten to use "isdnctrl dial ippp*" before using a net command like telnet, ping, or the like.
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) have some changes in the routing. Workaround: install a script /etc/ppp/ip-up like this:
#!/bin/sh /sbin/route add default ippp*
/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
Most likely the option "auth" was set by mistake. Then the other side is required to be authorized.
Like in the last question, an option was been set that requires the other side to be authorized. These options shouldn't be set. Possible candidates are: "+pap" as well as "+chap".
Your computer is refusing to identify itself with user name (e.g. XXX) and password (e.g. YYY). That only works with the authorization options "user XXX" and "remotename YYY" together with a correct (!) /etc/ppp/pap-secrets. With a password of ZZZ it should ideally look like this:
XXX YYY ZZZ *
* * ZZZ *
http://www.lrz-muenchen.de/~ui161ab/www/isdn/
Also have a look at the next question:
trouble_pap2
.
Stefan A. Muehlenweg
Stefan.A.Muehlenweg@samhh.Hanse.DE wrote on
4 Oct 1996:
I had exactly the same problem/the same error message. The cause for it was that I had three entries in chap-secrets/pap-secrets (for client, server, secret), but not a fourth one (IP addresses). BUT: after the third entry were some BLANKs. After removing the trailing BLANKs and/or TABs (i)pppd is now very satisfied with my auth-files.A further source of problems can be the password itself. If it contains the "#" character, then everything after than is understood as a comment. Spaces or tabs can cause similar problems. Solution: put the password in quotes!
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 cfg_general_compression ). Also giving the option "noccp" can help.
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.windows95.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.
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. Possible solutions:
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.
"ippp0: dialing 0 089XXXXXX...")? I don't have anyextensions!The first zero is not dialed. It only shows which channel is used for dialing.
The ISDN device fakes an Ethernet device. It ignores IRQ and baseaddr and just needs the HWaddr for the Ethernet encapsulation.
Peter Hettkamp
Peter.Hettkamp@kassel.netsurf.de wrote:
xosview reacts, at least for me with version 1.4, to the IP accounting in the kernel. So, configure, if necessary build a new kernel, then couple with: ipfwadm -A -a -S your-ip-address-here -D 0.0.0.0/0 ipfwadm -A -a -D your-ip-address-here -S 0.0.0.0/0 (I don't know who it works with variable IP addresses. I have a fixed address.)
What is entered on the "Win95 box" for the name server? As long as the router has no name server of its own, then the provider's name server of course has to be entered on all computers on the LAN.
Please check:
Wolfgang Barth wrote on 5 Jan 1997:
I've noticed that after the first connection via ippp0 that the local network can again be reached. Then the address 0.0.0.0 is no longer listed in ifconfig for ippp0, but instead the address assigned from the pool by the PPP partner. This was already discussed in de.comp.os.linux.networking, along this possible solution: Simply set ippp0 to a dummy IP number from the pool. Then the local network will have problems after booting, even with the default route, and the IP number in ifconfig will be overwritten anyway.