problems with persist option and all(?) pppd versions

[t***@web.de]

Hi,

i am using linux.2.6.13. I want to build up a connection to the
internet with a PCMCIA UMTS card (Sierra Wireless AirCard 850). The
card often builds up a connection succesfully but sometimes when i got
a Modem hangup pppd dies while trying to reconnect to the internet.
I have tried pppd 2.4.1, 2.4.2, 2.4.3,2.4.4b1 with the same result.

The message in the ppp-logfile sound like this:

Jul 21 14:19:06 gate pppd[1973]: Hangup (SIGHUP)
Jul 21 14:19:06 gate pppd[1973]: Modem hangup
Jul 21 14:19:06 gate pppd[1973]: Connection terminated.
Jul 21 14:19:06 gate pppd[1973]: Connect time 0.3 minutes.
Jul 21 14:19:06 gate pppd[1973]: Sent 0 bytes, received 0 bytes.
Jul 21 14:19:06 gate pppd[1973]: tcgetattr: No such device or address
(line 906)
Jul 21 14:19:06 gate pppd[1973]: Exit.

But when i restart after this my script to build up a connection it is
working fine again.
It is really necessary to solve this because our device has to stay or
has try to stay always connected to the internet.

Regards

Tobias

[Pascal Hambourg]

Hello,

Post by t***@web.de
i am using linux.2.6.13. I want to build up a connection to the
internet with a PCMCIA UMTS card (Sierra Wireless AirCard 850). The
card often builds up a connection succesfully but sometimes when i got
a Modem hangup pppd dies while trying to reconnect to the internet.
I have tried pppd 2.4.1, 2.4.2, 2.4.3,2.4.4b1 with the same result.
Jul 21 14:19:06 gate pppd[1973]: Hangup (SIGHUP)

This looks like the disconnect was initiated locally by sending a HUP
signal to pppd, doesn't it ?

Post by t***@web.de
Jul 21 14:19:06 gate pppd[1973]: Modem hangup
Jul 21 14:19:06 gate pppd[1973]: Connection terminated.
Jul 21 14:19:06 gate pppd[1973]: Connect time 0.3 minutes.
Jul 21 14:19:06 gate pppd[1973]: Sent 0 bytes, received 0 bytes.
Jul 21 14:19:06 gate pppd[1973]: tcgetattr: No such device or address
(line 906)
Jul 21 14:19:06 gate pppd[1973]: Exit.
But when i restart after this my script to build up a connection it is
working fine again.

Did you try to increase the "holdoff" value ?
I have encountered similar problems with different error messages. pppd
unexpectedly exits after disconnecting, or keeps failing to reconnect
forever. I set up what I consider is a hugly workaround, but it has
seemed to work so far. It is a script in /etc/ppp/ip-down.d/ which is
run each time the connection closes. It waits for a short delay, then
parses pppd's logs in syslog for the error message and takes the
appropriate action.

=========
#/bin/sh
if [ $PPP_IPPARAM == "myisp" ]; then
sleep 5s
# this error causes pppd to exit unexpectedly
if grep -qi "pppd\[${PPPD_PID}\].*PPPIOCSASYNCMAP" /var/log/syslog
then
# restart pppd
pon myisp
fi

# this error causes pppd to fail to reconnect forever
if grep -qi "pppd\[${PPPD_PID}\].*Couldn't release PPP unit" \
/var/log/syslog
then
# stop and restart pppd
poff myisp
pon myisp
fi
fi
=========

The "myisp" stuff is because I run several pppd sessions and I need to
identify the one which terminates. $PPPD_PID makes sure logs from other
pppd processes are ignored.

Another workaround I have not tried is to run pppd without the "persist"
option and with the "nodetach" option in a script that loops and restart
pppd right after it terminates.

[Pascal Hambourg]

[supersedes to fix a typo]

Hello,

Post by t***@web.de
i am using linux.2.6.13. I want to build up a connection to the
internet with a PCMCIA UMTS card (Sierra Wireless AirCard 850). The
card often builds up a connection succesfully but sometimes when i got
a Modem hangup pppd dies while trying to reconnect to the internet.
I have tried pppd 2.4.1, 2.4.2, 2.4.3,2.4.4b1 with the same result.
Jul 21 14:19:06 gate pppd[1973]: Hangup (SIGHUP)

This looks like the disconnect was initiated locally by sending a HUP
signal to pppd, doesn't it ?

Post by t***@web.de
Jul 21 14:19:06 gate pppd[1973]: Modem hangup
Jul 21 14:19:06 gate pppd[1973]: Connection terminated.
Jul 21 14:19:06 gate pppd[1973]: Connect time 0.3 minutes.
Jul 21 14:19:06 gate pppd[1973]: Sent 0 bytes, received 0 bytes.
Jul 21 14:19:06 gate pppd[1973]: tcgetattr: No such device or address
(line 906)
Jul 21 14:19:06 gate pppd[1973]: Exit.
But when i restart after this my script to build up a connection it is
working fine again.

Did you try to increase the "holdoff" value ?
I have encountered similar problems with different error messages. pppd
unexpectedly exits after disconnecting, or keeps failing to reconnect
forever. I set up what I consider is a hugly workaround, but it has
seemed to work so far. It is a script in /etc/ppp/ip-down.d/ which is
run each time the connection closes. It waits for a short delay, then
parses pppd's logs in syslog for the error message and takes the
appropriate action.

=========
#!/bin/sh
if [ $PPP_IPPARAM == "myisp" ]; then
sleep 5s
# this error causes pppd to exit unexpectedly
if grep -qi "pppd\[${PPPD_PID}\].*PPPIOCSASYNCMAP" /var/log/syslog
then
# restart pppd
pon myisp
fi

# this error causes pppd to fail to reconnect forever
if grep -qi "pppd\[${PPPD_PID}\].*Couldn't release PPP unit" \
/var/log/syslog
then
# stop and restart pppd
poff myisp
pon myisp
fi
fi
=========

The "myisp" stuff is because I run several pppd sessions and I need to
identify the one which terminates. $PPPD_PID makes sure logs from other
pppd processes are ignored.

Another workaround I have not tried is to run pppd without the "persist"
option and with the "nodetach" option in a script that loops and restart
pppd right after it terminates.

[t***@web.de]

Post by Pascal Hambourg
This looks like the disconnect was initiated locally by sending a HUP
signal to pppd, doesn't it ?

Yes this is right. The server has closed the connection.

Post by Pascal Hambourg
Did you try to increase the "holdoff" value ?
I have encountered similar problems with different error messages. pppd
unexpectedly exits after disconnecting, or keeps failing to reconnect
forever. I set up what I consider is a hugly workaround, but it has
seemed to work so far. It is a script in /etc/ppp/ip-down.d/ which is
run each time the connection closes. It waits for a short delay, then
parses pppd's logs in syslog for the error message and takes the
appropriate action.
=========
#!/bin/sh
if [ $PPP_IPPARAM == "myisp" ]; then
sleep 5s
# this error causes pppd to exit unexpectedly
if grep -qi "pppd\[${PPPD_PID}\].*PPPIOCSASYNCMAP" /var/log/syslog
then
# restart pppd
pon myisp
fi
# this error causes pppd to fail to reconnect forever
if grep -qi "pppd\[${PPPD_PID}\].*Couldn't release PPP unit" \
/var/log/syslog
then
# stop and restart pppd
poff myisp
pon myisp
fi
fi
=========
The "myisp" stuff is because I run several pppd sessions and I need to
identify the one which terminates. $PPPD_PID makes sure logs from other
pppd processes are ignored.

This does not work for me. If no connection is build up the ip-down
script is not executed.

Post by Pascal Hambourg
Another workaround I have not tried is to run pppd without the "persist"
option and with the "nodetach" option in a script that loops and restart
pppd right after it terminates.

This solves also not my problem, i hjave to run pppd detached.

Regards

Tobias

[Pascal Hambourg]

Post by t***@web.de

Post by Pascal Hambourg
I have encountered similar problems with different error messages. pppd
unexpectedly exits after disconnecting, or keeps failing to reconnect
forever. I set up what I consider is a hugly workaround, but it has
seemed to work so far. It is a script in /etc/ppp/ip-down.d/ which is
run each time the connection closes. It waits for a short delay, then
parses pppd's logs in syslog for the error message and takes the
appropriate action.

[example of script]

Post by t***@web.de
This does not work for me. If no connection is build up the ip-down
script is not executed.

Do you mean that the problem also happens when pppd first tries to
connect and not only when it tries to reconnect after a modem hangup ?

[t***@web.de]

Post by Pascal Hambourg
Do you mean that the problem also happens when pppd first tries to
connect and not only when it tries to reconnect after a modem hangup ?

This does sometimes happen when the first try does fail to connect. I
get these messages on my first try:

serial connection established
usign channel 1
usign interface ppp0
Connect: ppp0 <--> /dev/modem
..
..
Hangup (SIGHUP)
MOodem hangup
Connection terminated

The when it tries to reconnect i get this message
tcgetattr: No such device or address (line 907)
Exit.

The first connection try fails (for example no umts signal is there),
then the next try can produce this error, but this does not happen
always.

regards

Tobias

[Clifford Kite]

Post by t***@web.de
Hi,
i am using linux.2.6.13. I want to build up a connection to the
internet with a PCMCIA UMTS card (Sierra Wireless AirCard 850). The
card often builds up a connection succesfully but sometimes when i got
a Modem hangup pppd dies while trying to reconnect to the internet.
I have tried pppd 2.4.1, 2.4.2, 2.4.3,2.4.4b1 with the same result.
Jul 21 14:19:06 gate pppd[1973]: Hangup (SIGHUP)
Jul 21 14:19:06 gate pppd[1973]: Modem hangup
Jul 21 14:19:06 gate pppd[1973]: Connection terminated.
Jul 21 14:19:06 gate pppd[1973]: Connect time 0.3 minutes.
Jul 21 14:19:06 gate pppd[1973]: Sent 0 bytes, received 0 bytes.
Jul 21 14:19:06 gate pppd[1973]: tcgetattr: No such device or address
(line 906)

The "tcgetattr" almost always means that there is another process
contending with for the modem IRQ. Some examples are (1) an
ethernet card that used the same IRQ as the modem, (2) a misconfigured
ppp script that launched pppd twice, and (3) a mingetty that somehow
had been configured for call-in.

Post by t***@web.de
Jul 21 14:19:06 gate pppd[1973]: Exit.
But when i restart after this my script to build up a connection it is
working fine again.
It is really necessary to solve this because our device has to stay or
has try to stay always connected to the internet.
Regards
Tobias

[t***@web.de]

Post by Clifford Kite
The "tcgetattr" almost always means that there is another process
contending with for the modem IRQ. Some examples are (1) an
ethernet card that used the same IRQ as the modem, (2) a misconfigured
ppp script that launched pppd twice, and (3) a mingetty that somehow
had been configured for call-in.

No other device uses the same irq. And i don't think that pppd script
is launched twice
because ps -A does not show any toher pppd process. Mingetty is not
existing on this system.

[Clifford Kite]

Post by t***@web.de

Post by Clifford Kite
The "tcgetattr" almost always means that there is another process
contending with for the modem IRQ. Some examples are (1) an
ethernet card that used the same IRQ as the modem, (2) a misconfigured
ppp script that launched pppd twice, and (3) a mingetty that somehow
had been configured for call-in.

No other device uses the same irq. And i don't think that pppd script
is launched twice
because ps -A does not show any toher pppd process. Mingetty is not
existing on this system.

Yes, my bad. Wrong tcgetattr error message.

You may need to specify the holdoff option with, say, 30 seconds.
(If that works then you can try lower values.) This answer assumes
pppd tries to dial out before unlocking the tty. The timestamps
of your original post suggests that this could be happening.

[t***@web.de]

Post by Clifford Kite
Yes, my bad. Wrong tcgetattr error message.
You may need to specify the holdoff option with, say, 30 seconds.
(If that works then you can try lower values.) This answer assumes
pppd tries to dial out before unlocking the tty. The timestamps
of your original post suggests that this could be happening.

I have already set the holdoff option...
I tested it with 60 seconds, the error is still there. I don't think
that ppp has still locked the device when its dialing out again (can i
check this ?).
But 60 seconds should be enough time to unlock the tty, right ?

Tobias

[Clifford Kite]

Post by t***@web.de

Post by Clifford Kite
You may need to specify the holdoff option with, say, 30 seconds.
(If that works then you can try lower values.) This answer assumes
pppd tries to dial out before unlocking the tty. The timestamps
of your original post suggests that this could be happening.

I have already set the holdoff option...

Sorry, I didn't read the other replies.

Post by t***@web.de
I tested it with 60 seconds, the error is still there. I don't think
that ppp has still locked the device when its dialing out again (can i
check this ?).

Maybe. A lock file should be present during the pppd connection:

/var/lock/LCK..ttyS1

It goes away when pppd quits. You can try to check as to whether
the lock file exists at the moment the error message appears.

Post by t***@web.de
But 60 seconds should be enough time to unlock the tty, right ?

Right.

I have a patch for 2.4.2 that _might_ help. It keeps pppd from leaving
the serial device file in a state other than the state in which pppd
found it, which has occasionally happened to me when an abrupt hangup
occured. It's not long (and not eloquent) but if you get desperate and
are able to patch and recompile pppd then let me know and I'll post it.
No guarantee.

[t***@web.de]

Post by Clifford Kite

Post by Clifford Kite
You may need to specify the holdoff option with, say, 30 seconds.

/var/lock/LCK..ttyS1
It goes away when pppd quits. You can try to check as to whether
the lock file exists at the moment the error message appears.

This lock file does only exist, when i use the lock option for pppd i
think.
When i don't use it, the lock file should not exist, right ?

Post by Clifford Kite
I have a patch for 2.4.2 that _might_ help. It keeps pppd from leaving
the serial device file in a state other than the state in which pppd
found it, which has occasionally happened to me when an abrupt hangup
occured. It's not long (and not eloquent) but if you get desperate and
are able to patch and recompile pppd then let me know and I'll post it.
No guarantee.

This would be nice, i am able to recompile it (i have done this many
times to trace down the error).

Tobias

[Clifford Kite]

Post by t***@web.de
This lock file does only exist, when i use the lock option for pppd i
think.
When i don't use it, the lock file should not exist, right ?

Right.

Post by t***@web.de

Post by Clifford Kite
I have a patch for 2.4.2 that _might_ help. It keeps pppd from leaving
the serial device file in a state other than the state in which pppd
found it, which has occasionally happened to me when an abrupt hangup
occurred. It's not long (and not eloquent) but if you get desperate and
are able to patch and recompile pppd then let me know and I'll post it.
No guarantee.

This would be nice, i am able to recompile it (i have done this many
times to trace down the error).

Okay, the patch is below (in the form of a diff -u).


--- tty.c-original Mon Jan 12 22:17:59 2004
+++ tty.c Sat Jan 31 11:23:32 2004
@@ -804,8 +804,16 @@
sleep(1);
}

+ close(real_ttyfd);
+ while ((real_ttyfd = open(devnam, O_NONBLOCK | O_RDWR, 0)) < 0) {
+ if (errno != EINTR) {
+ syslog(LOG_ERR, "close_tty: Failed to reopen %s: %m", devnam);
+ goto fail;
+ }
+ }
restore_tty(real_ttyfd);

+fail:
#ifndef __linux__
if (tty_mode != (mode_t) -1) {
if (fchmod(real_ttyfd, tty_mode) != 0) {