"pon" fails and gives "ttyS overrun" in syslog - PPP

This is a discussion on "pon" fails and gives "ttyS overrun" in syslog - PPP ; I'm a Debian user and I did an "apt-get upgrade" which upgrades all the Debian packages. However, now, when I execute "pon", my modem won't connect. The modem seems to be making the same connection sounds as before the upgrade; ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: "pon" fails and gives "ttyS overrun" in syslog

  1. "pon" fails and gives "ttyS overrun" in syslog

    I'm a Debian user and I did an "apt-get upgrade" which upgrades
    all the Debian packages. However, now, when I execute "pon", my modem
    won't connect. The modem seems to be making the same connection
    sounds as before the upgrade; also, the modem is working in Window98.

    I have syslog records from before/after the upgrade. After upgrade,
    I notice this message:

    kernel: ttyS: 1 input overrun(s)

    In the remainder of this posting, I provide the following information:

    - miscellaneous command-line
    - /etc/ppp/peers/provider
    - successful syslog before the upgrade
    - unsuccessful syslog after the upgrade

    Any help would be greatly appreciated. I've run dry on ideas and am
    on the verge of doing a reinstall of Linux.

    =============================================
    =============================================
    =============================================

    ==== start of miscellaneous command-line ====

    $ setserial -bg /dev/ttyS*
    /dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A
    /dev/ttyS1 at 0x02f8 (irq = 3) is a 16550A
    /dev/ttyS2 at 0x03e8 (irq = 4) is a 16550A

    $ setserial -aq /dev/ttyS2
    /dev/ttyS2, Line 2, UART: 16550A, Port: 0x03e8, IRQ: 4
    Baud_base: 115200, close_delay: 50, divisor: 0
    closing_wait: 3000
    Flags: spd_normal skip_test

    ==== end of miscellaneous command-line ====

    ==== start of /etc/ppp/peers/provider ====

    # This optionfile was generated by pppconfig 2.3.2.
    #
    #
    hide-password
    noauth
    connect "/usr/sbin/chat -v -f /etc/chatscripts/provider"
    debug
    /dev/ttyS2
    115200
    defaultroute
    noipdefault
    user "###MY_USER_ID###"
    remotename provider
    ipparam provider
    usepeerdns

    ==== end of /etc/ppp/peers/provider ====

    ==== start of successful syslog before the upgrade ====

    Jun 30 08:59:23 box pppd[10108]: pppd 2.4.1 started by knoppix, uid
    1000
    Jun 30 08:59:24 box chat[10112]: abort on (BUSY)
    Jun 30 08:59:24 box chat[10112]: abort on (NO CARRIER)
    Jun 30 08:59:24 box chat[10112]: abort on (VOICE)
    Jun 30 08:59:24 box chat[10112]: abort on (NO DIALTONE)
    Jun 30 08:59:24 box chat[10112]: abort on (NO DIAL TONE)
    Jun 30 08:59:24 box chat[10112]: abort on (NO ANSWER)
    Jun 30 08:59:24 box chat[10112]: abort on (DELAYED)
    Jun 30 08:59:24 box chat[10112]: send (ATZ^M)
    Jun 30 08:59:25 box chat[10112]: expect (OK)
    Jun 30 08:59:25 box chat[10112]: Zz^PCARRIER^M
    Jun 30 08:59:25 box chat[10112]: ATZ^M^M
    Jun 30 08:59:25 box chat[10112]: OK
    Jun 30 08:59:25 box chat[10112]: -- got it
    Jun 30 08:59:25 box chat[10112]: send (ATDP###My_ISP_Number####^M)
    Jun 30 08:59:25 box chat[10112]: expect (CONNECT)
    Jun 30 08:59:25 box chat[10112]: ^M
    ---no "kernel: ttyS: 1 input overrun(s)" occurs
    Jun 30 08:59:50 box chat[10112]: ATDP###My_ISP_Number####^M^M
    Jun 30 08:59:50 box chat[10112]: CONNECT
    Jun 30 08:59:50 box chat[10112]: -- got it
    Jun 30 08:59:50 box chat[10112]: send (\d)
    Jun 30 08:59:51 box pppd[10108]: Serial connection established.
    Jun 30 08:59:51 box pppd[10108]: Using interface ppp0
    Jun 30 08:59:51 box pppd[10108]: Connect: ppp0 <--> /dev/ttyS2
    ----key delta point
    Jun 30 08:59:53 box pppd[10108]: local IP address 209.226.185.176
    Jun 30 08:59:53 box pppd[10108]: remote IP address 209.226.185.241
    Jun 30 08:59:53 box pppd[10108]: primary DNS address 199.166.210.2
    Jun 30 08:59:53 box pppd[10108]: secondary DNS address 199.166.210.5
    ....
    Jun 30 14:57:19 box pppd[10108]: Terminating on signal 15.
    Jun 30 14:57:19 box last message repeated 2 times
    Jun 30 14:57:19 box pppd[10108]: Connection terminated.
    Jun 30 14:57:19 box pppd[10108]: Connect time 357.5 minutes.
    Jun 30 14:57:19 box pppd[10108]: Sent 1710469 bytes, received 52530926
    bytes.
    Jun 30 14:57:19 box pppd[10108]: Terminating on signal 15.
    Jun 30 14:57:19 box pppd[10108]: Exit.

    ==== end of successful syslog before the upgrade ====

    ==== start of unsuccessful syslog after the upgrade ====

    Jul 3 20:28:38 box kernel: CSLIP: code copyright 1989 Regents of the
    University of California
    Jul 3 20:28:38 box kernel: PPP generic driver version 2.4.2
    Jul 3 20:28:38 box pppd[1177]: pppd 2.4.2 started by knoppix, uid
    1000
    Jul 3 20:28:39 box chat[1179]: abort on (BUSY)
    Jul 3 20:28:39 box chat[1179]: abort on (NO CARRIER)
    Jul 3 20:28:39 box chat[1179]: abort on (VOICE)
    Jul 3 20:28:39 box chat[1179]: abort on (NO DIALTONE)
    Jul 3 20:28:39 box chat[1179]: abort on (NO DIAL TONE)
    Jul 3 20:28:39 box chat[1179]: abort on (NO ANSWER)
    Jul 3 20:28:39 box chat[1179]: abort on (DELAYED)
    Jul 3 20:28:39 box chat[1179]: send (ATZ^M)
    Jul 3 20:28:39 box chat[1179]: expect (OK)
    Jul 3 20:28:43 box chat[1179]: ATZ^M^M
    Jul 3 20:28:43 box chat[1179]: OK
    Jul 3 20:28:43 box chat[1179]: -- got it
    Jul 3 20:28:43 box chat[1179]: send (ATDP###My_ISP_Number####^M)
    Jul 3 20:28:43 box chat[1179]: expect (CONNECT)
    Jul 3 20:28:43 box chat[1179]: ^M
    ---BAD!!!
    Jul 3 20:29:12 box kernel: ttyS: 1 input overrun(s)
    Jul 3 20:29:12 box chat[1179]: ATDP###My_ISP_Number####^M
    Jul 3 20:29:12 box chat[1179]: CONNECT
    Jul 3 20:29:12 box chat[1179]: -- got it
    Jul 3 20:29:12 box chat[1179]: send (\d)
    Jul 3 20:29:13 box pppd[1177]: Serial connection established.
    Jul 3 20:29:14 box pppd[1177]: Using interface ppp0
    Jul 3 20:29:14 box pppd[1177]: Connect: ppp0 <--> /dev/ttyS2
    ---key delta point
    Jul 3 20:29:39 box pppd[1177]: Hangup (SIGHUP)
    Jul 3 20:29:39 box pppd[1177]: Modem hangup
    Jul 3 20:29:39 box pppd[1177]: Connection terminated.
    Jul 3 20:29:40 box pppd[1177]: Exit.

    ==== end of unsuccessful syslog after the upgrade ====

  2. Re: "pon" fails and gives "ttyS overrun" in syslog

    ashayes@gto.net (Al Hayes) writes:
    >
    >I'm a Debian user and I did an "apt-get upgrade" which upgrades
    >all the Debian packages.
    >


    Are you using "stable" (woody), or "testing" (sarge)?

    -Greg
    --
    Do NOT reply via e-mail.
    Reply in the newsgroup.

  3. Re: "pon" fails and gives "ttyS overrun" in syslog

    gerg@panix.com (Greg Andrews) wrote in message news:...
    > Are you using "stable" (woody), or "testing" (sarge)?
    > -Greg


    I am using "testing" (sarge)

  4. Re: "pon" fails and gives "ttyS overrun" in syslog

    ashayes@gto.net (Al Hayes) writes:
    >gerg@panix.com (Greg Andrews) wrote in message
    >news:...
    >> Are you using "stable" (woody), or "testing" (sarge)?
    >>

    >
    >I am using "testing" (sarge)
    >


    Isn't this one of the risks of using a non-stable version?

    -Greg
    --
    Do NOT reply via e-mail.
    Reply in the newsgroup.

  5. Re: "pon" fails and gives "ttyS overrun" in syslog

    gerg@panix.com (Greg Andrews) wrote in message news:...
    > Isn't this one of the risks of using a non-stable version?


    Sure, I guess. Although with Debian, there are three versions:
    stable, testing, and experimental

    "testing" has the occasional hiccups but it's "experimental"
    that is subject to the serious problems.
    Using "testing" helps to shake out bugs and gives one the opportunity
    to try out the wide range of free software that is available.
    So both oneself and the community benefits.

    Indeed, the kind of serious problem that I am currently
    is quite rare under testing. Also, the problem is quite mystifying.
    There seems to be some unusal combination and, if one thinks about it,
    such problems also occur on the supposedly stable systems.

    As to my current situation, I have done searches against both google
    and against Debian's bug tracking system.
    However, I have yet to find anything useful.

    Perhaps I need to ask an even lower-level questions.
    What _is_ this "overrun" problem that I describe at the start of the thread?
    How can such basic functionality mess up?
    Surely, there has to be some way to track down this problem.
    So any guesses/ideas out there? What could possibly be triggering
    these "overrun" problems?

  6. Re: "pon" fails and gives "ttyS overrun" in syslog

    In comp.os.linux.networking Al Hayes wrote:
    > I'm a Debian user and I did an "apt-get upgrade" which upgrades
    > all the Debian packages. However, now, when I execute "pon", my modem
    > won't connect. The modem seems to be making the same connection
    > sounds as before the upgrade; also, the modem is working in Window98.


    > I have syslog records from before/after the upgrade. After upgrade,
    > I notice this message:


    > kernel: ttyS: 1 input overrun(s)

    ^^^^
    This is the device file that the kernel uses to generate this message,
    see line 504 of the file drivers/char/n_tty.c (at least in a kernel.org
    2.6.4 source). The 1 refers to the number of "input overrun(s)".

    I'd expect it to see ttyS2 since pppd was configured to use ttyS2,
    the serial connection seemed successful, and it appeared that
    ppp0 was attached to ttyS2. Whatever provides the kernel with the
    device file name used in that line seems to have the wrong name.
    I'm not much of a C programmer and trying to follow the code to find
    where the ttyS came from and why it's not ttyS2 is really beyond me.
    But the overrun error is apparently real, although I haven't a clue
    as to what is being overrun.

    The hangup occurs 25 seconds after ppp0 is attached to ttyS2, suggesting
    to me that pppd may have timed out sending LCP Configure-Requests at the
    beginning of the PPP link negotiations, although it's a little shy of
    the 30 seconds that one usually sees when that happens. Adding the pppd
    debug option and looking at the appropriate log file could show whether
    that's what's happening. The log file varies according to distribution
    and I don't use Debian.

    If this is a winmodem, or relative thereof, I'd suspect the kernel
    changed and now the "modem" module is not functioning correctly when
    it starts to send data through the device file.

    ....

    > ==== start of unsuccessful syslog after the upgrade ====


    > Jul 3 20:28:38 box kernel: CSLIP: code copyright 1989 Regents of the
    > University of California
    > Jul 3 20:28:38 box kernel: PPP generic driver version 2.4.2
    > Jul 3 20:28:38 box pppd[1177]: pppd 2.4.2 started by knoppix, uid
    > 1000


    "Started by knoppix?"

    -- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/

  7. Re: "pon" fails and gives "ttyS overrun" in syslog

    Clifford Kite wrote in message news:<0glecc.6v9.ln@corncob.localhost.tld>...
    > In comp.os.linux.networking Al Hayes wrote:
    > > I have syslog records from before/after the upgrade. After upgrade,
    > > I notice this message:

    >
    > > kernel: ttyS: 1 input overrun(s)

    > ^^^^
    > This is the device file that the kernel uses to generate this message,
    > see line 504 of the file drivers/char/n_tty.c (at least in a kernel.org
    > 2.6.4 source). The 1 refers to the number of "input overrun(s)".
    >
    > [... other good analysis follows]


    Thanks for the tips. I ended up using "pppd" in debug mode.
    Also, I followed the painstakingly complete instructions
    of this excellent webpage: http://axion.physics.ubc.ca/ppp-linux.html
    The webpage is entitled "How to hook up PPP in Linux" by W.G. Unruh.

    Anyway, none of this was really the problem.
    As it turn out, few people would be able to guess the solution.
    For any unfortunate spirit caught in my version of this bug,
    I hereby archive the solution so that you don't have
    to go through the pain that I went through.

    The problem is some kind of conflict with the application brltty.
    This is the brltty Debian package for "braille terminals".
    Specifically, /etc/rcS.d/S25brltty and /sbin/brltty
    will cause much grief.

    Not actually being blind, I have little excuse for having
    brltty installed on my PC; I can only plead stupidity
    and greedy curiosity. This app was installed and forgotten
    about months ago. Then my recent upgrade triggered
    this nasty Easter egg.

    So, If you don't need brltty then _remove_ this package.
    For example, in Debian "apt-get remove brltty".
    Or, as root, you can just "rm /etc/rcS.d/S25brltty".

    If you need this package, well, you've got some debugging to do.
    Or, alternatively, come up with a different way
    to set up your internet connection.

    More generally, you might be suffering a similar conflict
    that is inducing a "ttyS input overrun". However, in your case,
    the conflict may not specifically be from the brltty app.
    Debugging this situation is unpleasant when one is unaware
    of the app causing the conflict. I happened to notice
    some odd stuff during booting. So, yesterday, I learned all about
    "System V init" which starts your Linux OS during boot time.

    In the end, I created this /etc/rcS.d/00pondebug script:

    #! /bin/sh
    PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
    pon
    sleep 60

    and a dozen scripts with names like /etc/rcS.d/S##aTest
    but replacing ## with 20, 30, ..., 70:

    #! /bin/sh
    PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
    echo "!!!!!! connection test ## !!!!!!"
    lynx -dump google.com | head -10

    "lynx" is just a way to test if your internet connection is still working.
    Just pick some reliable URL during testing.
    You'll get "Google Error Bad Request ..." but that's irrelevant.
    When "lynx" still works, the bad app hasn't been triggered yet.

    If you know all about boot-time initialization, then use this technique
    (with some care and much patience) to isolate the problem area.
    Otherwise, learn about "System V init" or get a Linux expert to debug
    your Linux installation.

  8. Re: "pon" fails and gives "ttyS overrun" in syslog

    Clifford Kite wrote in message news:<0glecc.6v9.ln@corncob.localhost.tld>...
    > In comp.os.linux.networking Al Hayes wrote:
    > > I have syslog records from before/after the upgrade. After upgrade,
    > > I notice this message:

    >
    > > kernel: ttyS: 1 input overrun(s)

    > ^^^^
    > This is the device file that the kernel uses to generate this message,
    > see line 504 of the file drivers/char/n_tty.c (at least in a kernel.org
    > 2.6.4 source). The 1 refers to the number of "input overrun(s)".
    >
    > [... other good analysis follows]


    Thanks for the tips. I ended up using "pppd" in debug mode.
    Also, I followed the painstakingly complete instructions
    of this excellent webpage: http://axion.physics.ubc.ca/ppp-linux.html
    The webpage is entitled "How to hook up PPP in Linux" by W.G. Unruh.

    Anyway, none of this was really the problem.
    As it turn out, few people would be able to guess the solution.
    For any unfortunate spirit caught in my version of this bug,
    I hereby archive the solution so that you don't have
    to go through the pain that I went through.

    The problem is some kind of conflict with the application brltty.
    This is the brltty Debian package for "braille terminals".
    Specifically, /etc/rcS.d/S25brltty and /sbin/brltty
    will cause much grief.

    Not actually being blind, I have little excuse for having
    brltty installed on my PC; I can only plead stupidity
    and greedy curiosity. This app was installed and forgotten
    about months ago. Then my recent upgrade triggered
    this nasty Easter egg.

    So, If you don't need brltty then _remove_ this package.
    For example, in Debian "apt-get remove brltty".
    Or, as root, you can just "rm /etc/rcS.d/S25brltty".

    If you need this package, well, you've got some debugging to do.
    Or, alternatively, come up with a different way
    to set up your internet connection.

    More generally, you might be suffering a similar conflict
    that is inducing a "ttyS input overrun". However, in your case,
    the conflict may not specifically be from the brltty app.
    Debugging this situation is unpleasant when one is unaware
    of the app causing the conflict. I happened to notice
    some odd stuff during booting. So, yesterday, I learned all about
    "System V init" which starts your Linux OS during boot time.

    In the end, I created this /etc/rcS.d/00pondebug script:

    #! /bin/sh
    PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
    pon
    sleep 60

    and a dozen scripts with names like /etc/rcS.d/S##aTest
    but replacing ## with 20, 30, ..., 70:

    #! /bin/sh
    PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
    echo "!!!!!! connection test ## !!!!!!"
    lynx -dump google.com | head -10

    "lynx" is just a way to test if your internet connection is still working.
    Just pick some reliable URL during testing.
    You'll get "Google Error Bad Request ..." but that's irrelevant.
    When "lynx" still works, the bad app hasn't been triggered yet.

    If you know all about boot-time initialization, then use this technique
    (with some care and much patience) to isolate the problem area.
    Otherwise, learn about "System V init" or get a Linux expert to debug
    your Linux installation.

+ Reply to Thread