1-way modem - Hardware

This is a discussion on 1-way modem - Hardware ; Just upgrade from 2.6.9 to 2.6.18 (RHEL4.6 to RHEL 5), and my dialup is malfunctioning. I can turn ppp debug on, and see that LCP config requests are being sent, I can snoop the other side and see that it's ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: 1-way modem

  1. 1-way modem

    Just upgrade from 2.6.9 to 2.6.18 (RHEL4.6 to RHEL 5), and my dialup
    is malfunctioning. I can turn ppp debug on, and see that LCP config
    requests are being sent, I can snoop the other side and see that
    it's sending the LCP ACK's back, but there's no sign of them back
    on the original side.

    I also tried a manual test of using minicom to dialing another box, manually
    ATAing from minicom, the connect happens, but only when I type on host-A
    does it show up on destination host-B. Not the reverse. So it's like
    a 1-way port or something. Anyone have any debug ideas for this sort
    of problem? Anyone seen it before?

    Looking at a working case, I see that stty -a < /dev/ttyS0 (the modem
    port) looks the same, and setserial -a /dev/ttyS0 is basically the same
    (I tried setting it to auto_irq with no diff). Looking at
    /proc/tty/driver/serial during the PPP negotiation seem to only show
    transmissions, not receptions.

    I'm past doing the dumber things like trying to run a console at the
    same time on the same port.

    Thanks for any ideas! (Ideally, someone's hit the same thing and
    solved it.)

  2. Re: 1-way modem

    bfc@fenway.UUCP (Time Waster) wrote:
    >Just upgrade from 2.6.9 to 2.6.18 (RHEL4.6 to RHEL 5),


    That would suggest that the hardware is functional, and
    whatever this is, it's software.

    >and my dialup
    >is malfunctioning. I can turn ppp debug on, and see that LCP config
    >requests are being sent, I can snoop the other side and see that
    >it's sending the LCP ACK's back, but there's no sign of them back
    >on the original side.
    >
    >I also tried a manual test of using minicom to dialing another box, manually
    >ATAing from minicom, the connect happens, but only when I type on host-A
    >does it show up on destination host-B. Not the reverse. So it's like
    >a 1-way port or something. Anyone have any debug ideas for this sort
    >of problem? Anyone seen it before?


    Yep. The incoming data, to be seen, requires that the
    UART chip be serviced by the driver/kernel... and that
    means an interupt routine gets called when there is
    data. That requires two things, usually, one is the IRQ
    be correct and the other is the port address be correct.

    I suppose there might be something else, but those two are the
    clear choices for a culprit...

    >Looking at a working case, I see that stty -a < /dev/ttyS0 (the modem
    >port) looks the same, and setserial -a /dev/ttyS0 is basically the same


    ttyS0 should be IRQ 4, port 0x03f8.

    >(I tried setting it to auto_irq with no diff). Looking at
    >/proc/tty/driver/serial during the PPP negotiation seem to only show
    >transmissions, not receptions.
    >
    >I'm past doing the dumber things like trying to run a console at the
    >same time on the same port.
    >
    >Thanks for any ideas! (Ideally, someone's hit the same thing and
    >solved it.)


    --
    Floyd L. Davidson
    Ukpeagvik (Barrow, Alaska) floyd@apaflo.com

  3. Re: 1-way modem

    In article <87fxvc8rq2.fld@apaflo.com>,
    Floyd L. Davidson wrote:
    >>Looking at a working case, I see that stty -a < /dev/ttyS0 (the modem
    >>port) looks the same, and setserial -a /dev/ttyS0 is basically the same

    >
    >ttyS0 should be IRQ 4, port 0x03f8.


    That it is:

    setserial -a /dev/ttyS0
    /dev/ttyS0, Line 0, UART: 16550A, Port: 0x03f8, IRQ: 4
    Baud_base: 115200, close_delay: 50, divisor: 0
    closing_wait: 3000
    Flags: spd_normal skip_test

    (Also tried the autoconfig, and this didn't change anything.)

  4. Re: 1-way modem


    "Time Waster" wrote in message
    news:KRIxj.4659$A93.2571@trndny08...
    > Just upgrade from 2.6.9 to 2.6.18 (RHEL4.6 to RHEL 5), and my dialup
    > is malfunctioning. I can turn ppp debug on, and see that LCP config
    > requests are being sent, I can snoop the other side and see that
    > it's sending the LCP ACK's back, but there's no sign of them back
    > on the original side.
    >
    > I also tried a manual test of using minicom to dialing another box,
    > manually
    > ATAing from minicom, the connect happens, but only when I type on host-A
    > does it show up on destination host-B. Not the reverse. So it's like
    > a 1-way port or something. Anyone have any debug ideas for this sort
    > of problem? Anyone seen it before?
    >
    > Looking at a working case, I see that stty -a < /dev/ttyS0 (the modem
    > port) looks the same, and setserial -a /dev/ttyS0 is basically the same
    > (I tried setting it to auto_irq with no diff). Looking at
    > /proc/tty/driver/serial during the PPP negotiation seem to only show
    > transmissions, not receptions.
    >
    > I'm past doing the dumber things like trying to run a console at the
    > same time on the same port.
    >
    > Thanks for any ideas! (Ideally, someone's hit the same thing and
    > solved it.)


    Had the same issue when a modem and COM port shared an IRQ. I only found out
    what the problem was because I had a mouse in the COM port... I'd only
    recieve data from the modem if I moved the mouse around.



  5. Re: 1-way modem

    In article , Calab wrote:
    >Had the same issue when a modem and COM port shared an IRQ. I only found out
    >what the problem was because I had a mouse in the COM port... I'd only
    >recieve data from the modem if I moved the mouse around.


    I really like that theory the best -- because a missing interrupt seems
    like it would explain the behavior. I don't see anything else with IRQ4
    in /proc/interrupts, but.. didn't those IRQ's get tied to particular
    other IRQ's in the olden days. Maybe we're way past that now, and
    this is a modern machine. I thought maybe 4 was tied to 9, which on
    our box would put it with acpi.

    But i'm not googling any such pairings so far.

  6. Re: 1-way modem

    Time Waster (bfc@fenway.UUCP) writes:
    > Just upgrade from 2.6.9 to 2.6.18 (RHEL4.6 to RHEL 5), and my dialup
    > is malfunctioning. I can turn ppp debug on, and see that LCP config
    > requests are being sent, I can snoop the other side and see that
    > it's sending the LCP ACK's back, but there's no sign of them back
    > on the original side.
    >

    Is the modem okay?

    At one point, my 14.4K external modem started acting up, I forget the
    exact details, but it was only working one way. After checking the
    serial cable (and I've had that break), I came to the conclusion (there
    was logic to it, but I can't remember details) that the modem was faulty.
    I opened it up, and found one of the line drivers or receivers wasn't
    working. I cut the pins on the offending section, glued an identical
    IC on top, and wired it in. WOrked fine, right up until I took it out
    of service with a faster modem.

    It's a long shot, but it can indeed happen.

    Michael

  7. Re: 1-way modem


    "Time Waster" wrote in message
    news:exMxj.37019$v57.16852@trnddc05...
    > In article , Calab wrote:
    >>Had the same issue when a modem and COM port shared an IRQ. I only found
    >>out
    >>what the problem was because I had a mouse in the COM port... I'd only
    >>recieve data from the modem if I moved the mouse around.

    >
    > I really like that theory the best -- because a missing interrupt seems
    > like it would explain the behavior. I don't see anything else with IRQ4
    > in /proc/interrupts, but.. didn't those IRQ's get tied to particular
    > other IRQ's in the olden days. Maybe we're way past that now, and
    > this is a modern machine. I thought maybe 4 was tied to 9, which on
    > our box would put it with acpi.


    IRQ 2 is used for the IRQs between 9 and 16.

    IRQ 3 is used for COM1 (and was also used for COM3)
    IRQ 4 is used for COM2 (and was also used for COM4)

    As you can see, the conflicts between the COM ports is a real hassle. I
    even went to the trouble of cutting traces and adding wires to move modems
    to IRQ 7, etc.

    That was many moons ago.



  8. Re: 1-way modem

    On Fri, 29 Feb 2008, in the Usenet newsgroup comp.os.linux.hardware, in article
    , Time Waster wrote:

    >Just upgrade from 2.6.9 to 2.6.18 (RHEL4.6 to RHEL 5), and my dialup
    >is malfunctioning. I can turn ppp debug on, and see that LCP config
    >requests are being sent, I can snoop the other side and see that
    >it's sending the LCP ACK's back, but there's no sign of them back
    >on the original side.


    What KIND of modem? External? Internal? Built-in? PCI? USB? ISA? How
    is is connected to the computer? What shows up in /var/log/messages
    at boot time related to the appropriate serial port? Which serial
    driver is being used? Is it appropriate to your unspecified hardware?

    Are you using some form of 'connect' option such as '/usr/sbin/chat' to
    dial the modem? Set that tool into the debug or verbose mode (for
    '/usr/sbin/chat', add the -v option), and look at the resulting logs.
    Does the modem respond (more or less) instantly?

    Jul 3 09:55:00 gtech chat[925]: send (AT&F1)
    Jul 3 09:55:01 gtech chat[925]: expect (OK)
    Jul 3 09:55:01 gtech chat[925]: AT&F1
    Jul 3 09:55:01 gtech chat[925]: OK
    Jul 3 09:55:01 gtech chat[925]: -- got it

    or is there a 19 second delay?

    Jul 3 09:55:00 gtech chat[925]: send (AT&F1)
    Jul 3 09:55:01 gtech chat[925]: expect (OK)
    Jul 3 09:55:20 gtech chat[925]: AT&F1
    Jul 3 09:55:20 gtech chat[925]: OK
    Jul 3 09:55:20 gtech chat[925]: -- got it

    The latter is an indication that the interrupts are screwed up - either
    the serial port is using a different IRQ from what the kernel expects,
    or (in the case of non-PCI hardware) an IRQ sharing problem (ISA and
    most built-in serial ports do not tolerate shared interrupts).

    >I also tried a manual test of using minicom to dialing another box, manually
    >ATAing from minicom, the connect happens, but only when I type on host-A
    >does it show up on destination host-B. Not the reverse.


    On the upgraded box, is minicom using an appropriate (as defined by the
    manufacturer) modem init string? (That usually means something like AT&F0
    or AT&F1, and NOT "ATZ" which may just reset the modem to what-ever you
    may have saved into NVRAM.) Are the modem commands being echoed back?
    Does the echo or the result code occur within a fraction of a second, or
    is there a long (up to a half minute) delay? Does your modem have lights
    on it, and are they blinking appropriately? (If no lights, there are a
    number of applications that can mimic these lights - "modemlights" is
    but one example.)

    >Looking at a working case, I see that stty -a < /dev/ttyS0 (the modem
    >port) looks the same, and setserial -a /dev/ttyS0 is basically the same
    >(I tried setting it to auto_irq with no diff). Looking at
    >/proc/tty/driver/serial during the PPP negotiation seem to only show
    >transmissions, not receptions.


    Fire up minicom. Look at the contents of /proc/interrupts:

    7: 969503 + serial

    (Here, the modem is configured to use IRQ 7, because other devices are
    using the so-called "standard" values of 4 or 3. Note also that the data
    is only present when some application is actually USING the interrupt.)
    In minicom, press the A, T, and return key - which should send the
    Hayes command prefix to the modem. The modem should respond with a
    non-error result - the number 0 if non-verbal result codes are selected,
    or the letters "OK". Now look again at /proc/interrupts:

    7: 969515 + serial

    Echoing the command, and then producing the "verbal result" here caused
    12 interrupts. What do _you_ see on your system?

    Old guy

  9. Re: 1-way modem

    Thanks for your excellent thoughts Moe!

    > What KIND of modem? External? Internal? Built-in? PCI? USB? ISA? How
    > is is connected to the computer? What shows up in /var/log/messages
    > at boot time related to the appropriate serial port? Which serial
    > driver is being used? Is it appropriate to your unspecified hardware?


    I could easily screw up this definition, but it's on COM1 which
    from lspci is on a ISA bridge:

    0b:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface
    Controller (rev 09)
    Subsystem: NEC Corporation Unknown device 8350
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Step
    ping- SERR+ FastB2B-
    Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- - SERR- Latency: 0

    The messages file shows the 2 active serial ports at the correct IRQ:

    Feb 29 17:20:53 box kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
    Feb 29 17:20:53 box kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

    setserial agrees on the IRQ:

    /dev/ttyS0, Line 0, UART: 16550A, Port: 0x03f8, IRQ: 4
    Baud_base: 115200, close_delay: 50, divisor: 0
    closing_wait: 3000
    Flags: spd_normal skip_test


    I do get occasional messages like:
    Feb 29 17:15:06 box pppd[7197]: Connect: ppp0 <--> /dev/ttyS0
    Feb 29 17:15:37 box pppd[7197]: LCP: timeout sending Config-Requests
    Feb 29 17:15:37 box pppd[7197]: Connection terminated.
    Feb 29 17:15:37 box pppd[7197]: Receive serial link is not 8-bit clean:
    Feb 29 17:15:37 box pppd[7197]: Problem: all had bit 7 set to 0

    Though i think the 8-bit stuff could be a red-herring. I believe the
    16550A identification is correct.

    > Are you using some form of 'connect' option such as '/usr/sbin/chat' to
    > dial the modem? Set that tool into the debug or verbose mode (for
    > '/usr/sbin/chat', add the -v option), and look at the resulting logs.
    > Does the modem respond (more or less) instantly?
    >
    > Jul 3 09:55:00 gtech chat[925]: send (AT&F1)
    > Jul 3 09:55:01 gtech chat[925]: expect (OK)
    > Jul 3 09:55:01 gtech chat[925]: AT&F1
    > Jul 3 09:55:01 gtech chat[925]: OK
    > Jul 3 09:55:01 gtech chat[925]: -- got it


    Great tip, yes we're using chat, and mostly they fall close together --
    certainly no 19 second delay, but there is a 2-second delay I see:

    Mar 1 10:03:25 box pppd[8453]: pppd 2.4.4 started by root, uid 0
    Mar 1 10:03:26 box chat[8454]: abort on (NO CARRIER)
    Mar 1 10:03:26 box chat[8454]: abort on (NO DIALTONE)
    Mar 1 10:03:26 box chat[8454]: abort on (ERROR)
    Mar 1 10:03:26 box chat[8454]: abort on (BUSY)
    Mar 1 10:03:26 box chat[8454]: send (ATH^M)
    Mar 1 10:03:26 box chat[8454]: expect (OK)
    Mar 1 10:03:28 box chat[8454]: ^M <<<---- relevant gap??
    Mar 1 10:03:28 box chat[8454]: OK
    Mar 1 10:03:28 box chat[8454]: -- got it
    Mar 1 10:03:28 box chat[8454]: send (ATE0^M)
    Mar 1 10:03:28 box chat[8454]: expect (OK)
    Mar 1 10:03:28 box chat[8454]: ^M
    Mar 1 10:03:28 box chat[8454]: ^M
    Mar 1 10:03:28 box chat[8454]: OK
    Mar 1 10:03:28 box chat[8454]: -- got it
    Mar 1 10:03:28 box chat[8454]: send (AT^M)
    Mar 1 10:03:28 box chat[8454]: expect (OK)
    Mar 1 10:03:28 box chat[8454]: ^M
    Mar 1 10:03:28 box chat[8454]: ^M
    Mar 1 10:03:28 box chat[8454]: OK
    Mar 1 10:03:28 box chat[8454]: -- got it
    Mar 1 10:03:28 box chat[8454]: send (ATDT5591^M)
    Mar 1 10:03:28 box chat[8454]: timeout set to 120 seconds
    Mar 1 10:03:28 box chat[8454]: expect (CONNECT)
    Mar 1 10:03:28 box chat[8454]: ^M
    Mar 1 10:03:54 box chat[8454]: ^M
    Mar 1 10:03:54 box chat[8454]: CONNECT
    Mar 1 10:03:54 box chat[8454]: -- got it
    Mar 1 10:03:54 box pppd[8453]: Serial connection established.

    > On the upgraded box, is minicom using an appropriate (as defined by the
    > manufacturer) modem init string? (That usually means something like AT&F0
    > or AT&F1, and NOT "ATZ" which may just reset the modem to what-ever you
    > may have saved into NVRAM.) Are the modem commands being echoed back?
    > Does the echo or the result code occur within a fraction of a second, or
    > is there a long (up to a half minute) delay? Does your modem have lights
    > on it, and are they blinking appropriately? (If no lights, there are a
    > number of applications that can mimic these lights - "modemlights" is
    > but one example.)


    The commands get their OKs echo'd back promptly. We're not sending
    AT&F1 or ATZ, but during my manual test i sent it AT&F1 and it didn't
    make a difference. I've watched the lights via statserial, and they
    seem like appropriate settings during the state transitions -- on
    ever-lasting CD or anything.

    > >Looking at a working case, I see that stty -a < /dev/ttyS0 (the modem
    > >port) looks the same, and setserial -a /dev/ttyS0 is basically the same
    > >(I tried setting it to auto_irq with no diff). Looking at
    > >/proc/tty/driver/serial during the PPP negotiation seem to only show
    > >transmissions, not receptions.

    >
    > Fire up minicom. Look at the contents of /proc/interrupts:
    >
    > 7: 969503 + serial


    We only have serial showing up in 3 and 4 as expected, the IRQ
    of interest being 4 (3/COM2 is a console).

    >
    > (Here, the modem is configured to use IRQ 7, because other devices are
    > using the so-called "standard" values of 4 or 3. Note also that the data
    > is only present when some application is actually USING the interrupt.)
    > In minicom, press the A, T, and return key - which should send the
    > Hayes command prefix to the modem. The modem should respond with a
    > non-error result - the number 0 if non-verbal result codes are selected,
    > or the letters "OK". Now look again at /proc/interrupts:
    >
    > 7: 969515 + serial
    >
    > Echoing the command, and then producing the "verbal result" here caused
    > 12 interrupts. What do _you_ see on your system?


    This works normally, but when the LCP/IPCP fragments are going to
    the other side, only TX is bumped in /proc/tty/driver/serial, not the
    RX count.

    > Old guy


    Damn, i thought i was the old guy. But excellent tip about the chat
    timings.


  10. Re: 1-way modem

    bfc@fenway.UUCP (Time Waster) wrote:
    >>
    >> Jul 3 09:55:00 gtech chat[925]: send (AT&F1)
    >> Jul 3 09:55:01 gtech chat[925]: expect (OK)
    >> Jul 3 09:55:01 gtech chat[925]: AT&F1
    >> Jul 3 09:55:01 gtech chat[925]: OK
    >> Jul 3 09:55:01 gtech chat[925]: -- got it


    Your serial port is working just fine. It is clearly
    talking to the modem, and receiving data.

    The problem you have is either a broken modem, or a
    configuration problem.

    --
    Floyd L. Davidson
    Ukpeagvik (Barrow, Alaska) floyd@apaflo.com

  11. Re: 1-way modem

    In article <87wsommnm1.fld@apaflo.com>,
    Floyd L. Davidson wrote:
    >
    >
    >bfc@fenway.UUCP (Time Waster) wrote:
    >Your serial port is working just fine. It is clearly
    >talking to the modem, and receiving data.
    >
    >The problem you have is either a broken modem, or a
    >configuration problem.


    Thanks Floyd, if the modem is broken it's certainly a coincidental time.
    It'll be worth checking when I get back to work, but I like the configuration
    problem thoery better. Anyone have ideas of what kind of configuration
    error would cause a lack of inbound data? What things should I check?

    It feels like a lower-level problem, but unfortunately the serial
    driver's built in to the kernel, and doesn't have debug options available
    (that I can see) even if I rebuilt it as a module. I'm gonna dig in that
    direction though.


  12. Re: 1-way modem

    On Sat, 01 Mar 2008, in the Usenet newsgroup comp.os.linux.hardware, in article
    , Time Waster wrote:

    >Thanks for your excellent thoughts Moe!


    You're welcome!

    [I wrote]

    >> What KIND of modem? External? Internal? Built-in? PCI? USB? ISA? How
    >> is is connected to the computer? What shows up in /var/log/messages
    >> at boot time related to the appropriate serial port? Which serial
    >> driver is being used? Is it appropriate to your unspecified hardware?


    >I could easily screw up this definition, but it's on COM1 which
    >from lspci is on a ISA bridge:


    I was hoping for something like "It's a USR Courier external model blah"
    but let's see what we've got.

    >The messages file shows the 2 active serial ports at the correct IRQ:
    >
    >Feb 29 17:20:53 box kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is

    a 16550A
    >Feb 29 17:20:53 box kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is

    a 16550A

    OK - that looks like the old fashioned standard serial ports on the
    motherboard. The driver used is the modern kernel driver.

    >setserial agrees on the IRQ:


    OK

    >I do get occasional messages like:
    >Feb 29 17:15:06 box pppd[7197]: Connect: ppp0 <--> /dev/ttyS0
    >Feb 29 17:15:37 box pppd[7197]: LCP: timeout sending Config-Requests
    >Feb 29 17:15:37 box pppd[7197]: Connection terminated.
    >Feb 29 17:15:37 box pppd[7197]: Receive serial link is not 8-bit clean:
    >Feb 29 17:15:37 box pppd[7197]: Problem: all had bit 7 set to 0


    OK - you've found a terminal server that is configured for AutoPPP, and
    they can be faked into thinking you want to use an ASCII login that was
    all the rage before microsoft invented the telephone in 1995. Very few
    system are actually configured to accept that mode, as opposed to the
    more common 'chat/pap' style authentication. See below for a possible
    fix.

    >Though i think the 8-bit stuff could be a red-herring. I believe the
    >16550A identification is correct.


    You might notice that it's an application (pppd) that is complaining,
    not the kernel or serial driver. It's a real problem, but there is a
    normally a very simple fix.

    >Great tip, yes we're using chat, and mostly they fall close together --
    >certainly no 19 second delay, but there is a 2-second delay I see:
    >
    >Mar 1 10:03:25 box pppd[8453]: pppd 2.4.4 started by root, uid 0
    >Mar 1 10:03:26 box chat[8454]: abort on (NO CARRIER)
    >Mar 1 10:03:26 box chat[8454]: abort on (NO DIALTONE)
    >Mar 1 10:03:26 box chat[8454]: abort on (ERROR)
    >Mar 1 10:03:26 box chat[8454]: abort on (BUSY)
    >Mar 1 10:03:26 box chat[8454]: send (ATH^M)
    >Mar 1 10:03:26 box chat[8454]: expect (OK)
    >Mar 1 10:03:28 box chat[8454]: ^M <<<---- relevant gap??
    >Mar 1 10:03:28 box chat[8454]: OK
    >Mar 1 10:03:28 box chat[8454]: -- got it
    >Mar 1 10:03:28 box chat[8454]: send (ATE0^M)
    >Mar 1 10:03:28 box chat[8454]: expect (OK)
    >Mar 1 10:03:28 box chat[8454]: ^M
    >Mar 1 10:03:28 box chat[8454]: ^M
    >Mar 1 10:03:28 box chat[8454]: OK
    >Mar 1 10:03:28 box chat[8454]: -- got it
    >Mar 1 10:03:28 box chat[8454]: send (AT^M)
    >Mar 1 10:03:28 box chat[8454]: expect (OK)
    >Mar 1 10:03:28 box chat[8454]: ^M
    >Mar 1 10:03:28 box chat[8454]: ^M
    >Mar 1 10:03:28 box chat[8454]: OK
    >Mar 1 10:03:28 box chat[8454]: -- got it


    No interrupt problem, but where did you dig up this set of commands?
    First you tell the modem "Hang up the phone" (the modem says HUH???),
    and hopefully it is on hook, or it would never respond to the command.
    Next, you tell it to turn off command echo (which chat ignores if they
    aren't the expected strings, and pppd never sees because the modems are
    in data mode rather than command mode when pppd is talking/listening),
    and then you tell it "I'm going to send a Hayes command" (the bare "AT")
    and never do. But you've never initialized the modem, so who knows what
    settings are in effect.

    >Mar 1 10:03:28 box chat[8454]: send (ATDT5591^M)
    >Mar 1 10:03:28 box chat[8454]: timeout set to 120 seconds
    >Mar 1 10:03:28 box chat[8454]: expect (CONNECT)
    >Mar 1 10:03:28 box chat[8454]: ^M
    >Mar 1 10:03:54 box chat[8454]: ^M
    >Mar 1 10:03:54 box chat[8454]: CONNECT
    >Mar 1 10:03:54 box chat[8454]: -- got it


    Dial the phone - it's taking 26 seconds for the call to go through, the
    modems to scream at each other and recognize how to talk, and your
    modem then reports establishing a connection. Pretty much normal.

    >Mar 1 10:03:54 box pppd[8453]: Serial connection established.


    pppd then reports that the 'connect' command has given it a serial
    connection, and we'll go on from there.

    I'd really recommend changing that script. Right now, it looks as if
    you have

    ABORT "NO CARRIER" ABORT "NO DIALTONE" ABORT ERROR ABORT BUSY "" ATH \
    OK ATE0 OK AT OK ATDT5591 TIMEOUT 120 CONNECT

    which says to set four abort conditions, tell the modem to hang up the
    phone, set command echo off, nothing, dial 5591 using tones, and wait
    up to 2 minutes (default is 45 seconds, usually more than enough) for
    the modem to report 'CONNECT'. What might be better is

    ABORT "NO CARRIER" ABORT BUSY "" AT&F0 OK ATDT5591 CONNECT \d\c

    with AT&F0 being the most common init-string used. The \d\c at the
    end tells /usr/sbin/chat to wait one second after connecting, then
    exit _without_ sending anything else. Normally, 'chat' would send a
    carriage return, and this is what triggers the AutoPPP mode which gets
    you into that 'not 8-bit clean' problem.

    >The commands get their OKs echo'd back promptly. We're not sending
    >AT&F1 or ATZ, but during my manual test i sent it AT&F1 and it didn't
    >make a difference.


    It's really desirable to initialize the modem to a known state.

    >This works normally, but when the LCP/IPCP fragments are going to
    >the other side, only TX is bumped in /proc/tty/driver/serial, not the
    >RX count.


    I hesitate to suggest this (as it results in a LOT of output that is
    normally useless), but try TEMPORARILY adding 'kdebug 7' as an option
    to pppd, and then look at the log outputs to see if pppd is dropping
    frames because of errors. It _shouldn't_ be dropping anything.

    >> Old guy

    >
    >Damn, i thought i was the old guy. But excellent tip about the chat
    >timings.


    Suffice to say I'm old enough that I really should think about retiring
    while I'm still mobile enough to enjoy it.

    Old guy

+ Reply to Thread