Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 04 Aug 2000 11:44:34 +0200
From:      tobi@bland.fido.de (Tobias Ernst)
To:        freebsd-isdn@freebsd.org
Subject:   hangup bug in i4b / ppp code
Message-ID:  <MSGID_242=3A7600=2F1_398aabc5@Fido.DE>

next in thread | raw e-mail | index | archive | help
Hallo!

In February, under the subject "early hangup causing exorbitant telecom
fees",
I reported a problem with i4b/sppp, where every connection was closed
with "normal call clearing" right after it had been established,
causing an endless number of failed connection attemps, each being
charged with DM 0.12, which caused me over 2000 DM of telecom fees just
for 6 hours of fruitless connnection attempts.

At that time, the conclusion was that I must have been hit by the "lcp
loop bug" in sppp. Consequently, I switched to user ppp. Today I have
been hit by the problem again (but now I use a flatrate, so at least no
problem with the fees ...), so now I thinkg that it must be a bug in
i4b. Here is the logfile from isdnd:

04.08.2000 10:38:41 CHD 01949 userppp0 dialing out from 8700334 to
0192071
04.08.2000 10:38:42 CHD 01949 userppp0 outgoing call proceeding (ctl 0,
ch 0)
04.08.2000 10:38:42 CHD 01949 userppp0 outgoing call active (ctl 0, ch
0, rbch0)
04.08.2000 10:38:45 CHD 01949 userppp0 outgoing call disconnected
(local)
04.08.2000 10:38:45 CHD 01949 userppp0 cause 0: normal call clearing
(I4B)
04.08.2000 10:38:45 CHD 01949 userppp0 charging: 1 units, 3 seconds
04.08.2000 10:38:48 CHD 01950 userppp0 rate 1000 sec/unit (conf)

And here the one from ppp:

Aug  4 10:38:41 romulus ppp[1035]: tun0: Phase: Phone: 0192071
Aug  4 10:38:41 romulus ppp[1035]: tun0: Phase: deflink: Connected!
Aug  4 10:38:41 romulus ppp[1035]: tun0: Phase: deflink: opening ->
dial
Aug  4 10:38:41 romulus ppp[1035]: tun0: Chat: deflink: Dial attempt 1
of 2
Aug  4 10:38:41 romulus ppp[1035]: tun0: Phase: deflink: dial ->
carrier
Aug  4 10:38:43 romulus ppp[1035]: tun0: Phase: deflink: /dev/i4brbch0:
CD detected
Aug  4 10:38:43 romulus ppp[1035]: tun0: Phase: deflink: carrier ->
login
Aug  4 10:38:43 romulus ppp[1035]: tun0: Phase: deflink: login -> lcp

Aug  4 10:38:44 romulus ppp[1035]: tun0: Phase: bundle: Authenticate
Aug  4 10:38:44 romulus ppp[1035]: tun0: Phase: deflink: his =3D CHAP
0x05, mine =3Dnone
Aug  4 10:38:44 romulus ppp[1035]: tun0: Phase: Chap Input: CHALLENGE
(16 bytes from stgdiinternet)
Aug  4 10:38:44 romulus ppp[1035]: tun0: Phase: Chap Output: RESPONSE
(tobias.ernst)
Aug  4 10:38:44 romulus ppp[1035]: tun0: Phase: Chap Input: SUCCESS
Aug  4 10:38:44 romulus ppp[1035]: tun0: Phase: mpserver: can't connect
to bundle socket /var/run/ppp--01-7374676469696e7465726e6574
(Connection refused)
Aug  4 10:38:44 romulus ppp[1035]: tun0: Phase:           Has the
previous server died badly ?
Aug  4 10:38:45 romulus ppp[1035]: tun0: Phase: deflink: Disconnected!
Aug  4 10:38:45 romulus ppp[1035]: tun0: Phase: deflink: lcp -> logout
Aug  4 10:38:45 romulus ppp[1035]: tun0: Phase: deflink: logout ->
hangup
Aug  4 10:38:45 romulus ppp[1035]: tun0: Phase: deflink: Disconnected!

The interesting point is the error message with the "bundle socket".
This socket file name is the same on each fruitless attempt. I tried
restarting ppp and also isdnd, but it did not help. 

However, I also had another provider configured in ppp.conf, and
switching to this provider worked (ppp was using a differentd bundle
socket filename then), but when I switched back to the old provider, it
did not work (ppp was then again using the bad bundle socket filename).

At first I thought it was a problem at the provider side, but then
their hotline talked me into setting up the account on a Windows
machine, and there, everything worked. The only cure I found was to
reboot the FreeBSD machine (admittedly, at that time I had not yet
inspected ppp.log, only isdnd.log). After that, ppp was still using the
same socket filename, but there were no more errors.

Question a: What was happening there? Could it be the same bug that hit
me in February?

Question b: Could I have fixed it without rebooting?

Question c: Given that ppp obviously detects a problem on the local
side, why does ppp retry endlessly? Can ppp configured to stop trying
to connect for some hours after n numbers of failed login attempts? Now
that I have a flatrate I don't really mind any more, but other users
could be safed from trouble if the default behaviour of ppp would be
changed into this direction.

BTW, the system is FreeBSD 3.4-STABLE, but not cvsupped for some months
now.

Viele Gr=FC=DFe,
Tobias


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isdn" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MSGID_242=3A7600=2F1_398aabc5>