problems with persist option and all(?) pppd versions - PPP

This is a discussion on problems with persist option and all(?) pppd versions - PPP ; 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 ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: problems with persist option and all(?) pppd versions

  1. problems with persist option and all(?) pppd versions

    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


  2. Re: problems with persist option and all(?) pppd versions

    Hello,

    tobiasarp@web.de a écrit :
    >
    > 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)


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

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

  3. Re: problems with persist option and all(?) pppd versions

    [supersedes to fix a typo]

    Hello,

    tobiasarp@web.de a écrit :
    >
    > 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)


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

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

  4. Re: problems with persist option and all(?) pppd versions

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


    > 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


  5. Re: problems with persist option and all(?) pppd versions

    tobiasarp@web.de a écrit :
    >
    >>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]
    >
    > 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 ?

  6. Re: problems with persist option and all(?) pppd versions


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


  7. Re: problems with persist option and all(?) pppd versions

    tobiasarp@web.de wrote:
    > 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)


    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.

    > 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



    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* The signal-to-noise ratio is too low in many [news] groups to make
    * them good candidates for archiving.
    * --- Mike Moraes, Answers to FAQs about Usenet */

  8. Re: problems with persist option and all(?) pppd versions


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


  9. Re: problems with persist option and all(?) pppd versions

    tobiasarp@web.de wrote:

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

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* Better is the enemy of good enough. */

  10. Re: problems with persist option and all(?) pppd versions

    > 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


  11. Re: problems with persist option and all(?) pppd versions

    tobiasarp@web.de wrote:
    >>
    >> 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.

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

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

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    /* Better is the enemy of good enough. */

  12. Re: problems with persist option and all(?) pppd versions


    Clifford Kite schrieb:

    > tobiasarp@web.de wrote:
    > >>
    > >> You may need to specify the holdoff option with, say, 30 seconds.

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


    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 ?

    > 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


  13. Re: problems with persist option and all(?) pppd versions

    tobiasarp@web.de wrote:

    > Clifford Kite schrieb:


    >> tobiasarp@web.de wrote:


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

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


    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    /* "Be liberal in what you accept, and conservative in what you send"
    RFC 1122 */

+ Reply to Thread