Details of ppp & modem shut-down - PPP

This is a discussion on Details of ppp & modem shut-down - PPP ; Netters ! I get the impression that few people really know the detailed shut-down procedure that happens when one 'exits ppp and disconnects the modem from the telco-line'. By using "ATM2D 3407501" to my modem ( M2 for sound on), ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Details of ppp & modem shut-down

  1. Details of ppp & modem shut-down

    Netters !

    I get the impression that few people really know the detailed
    shut-down procedure that happens when one 'exits ppp and
    disconnects the modem from the telco-line'.

    By using "ATM2D 3407501" to my modem ( M2 for sound on),
    I can hear when the carrier stops. Perhaps the CD led would
    show this. But carrier TX and Rx are different.

    There is 2 to 3 seconds delay from the 'ppp-off' command until
    the carrier sound stops.

    Apparently the modem must exit the talking-ppp-mode
    into the command-mode, to drop-out the line-relay ?

    Q1. what are the ppp steps/states during exit ?

    Q2. what are the *details* of the modem changing from
    'talking ppp' to command mode ?

    Q3. Are talking-ppp-mode and command-mode 7 or 8 bit ?

    Q4. going the other direction: what tells the modem to exit
    command-mode into talking-ppp-mode ?

    Thanks for any info,

    Chris Glur.



  2. Re: Details of ppp & modem shut-down

    eas-lab@absamail.co.za writes:
    >Netters !
    >
    > I get the impression that few people really know the detailed
    >shut-down procedure that happens when one 'exits ppp and
    >disconnects the modem from the telco-line'.
    >
    >By using "ATM2D 3407501" to my modem ( M2 for sound on),
    >I can hear when the carrier stops. Perhaps the CD led would
    >show this. But carrier TX and Rx are different.
    >
    >There is 2 to 3 seconds delay from the 'ppp-off' command until
    >the carrier sound stops.
    >
    >Apparently the modem must exit the talking-ppp-mode
    >into the command-mode, to drop-out the line-relay ?
    >


    No. Get an RS232 breakout box with lights on the control
    pins, and watch the DTR pin coming from the computer.

    Pppd is most likely sending a PPP packet requesting disconnect to
    the other end (I can't remember the correct name for the packet),
    and waiting for a confirmation response. Then pppd performs a
    close() on the serial port device, which makes the serial port driver
    turn the DTR pin off. Then your modem sends its own disconnect
    packet to the other modem (part of the error control protocol being
    used by the modems). Most modems wait briefly for a confirmation
    packet from the other modem. Then most modems using a 9600 bps or
    faster modulation send a brief "cleardown" signal to indicate the
    connection will be broken soon. Then your modem stops transmitting
    and goes "on-hook" to disconnect from the phone line.

    The exchange of PPP disconnect packets is usually where the 2-3 second
    time delay occurs. You'll also see the Tx and Rx lights flicker as
    those packets are sent and received. After the DTR pin turns off,
    the modem will very quickly stop transmitting and go on-hook. Almost
    always within one second, usually within .25-.30 seconds.

    Modem compatibility problems or long-delay connections (e.g. over a
    satellite or two) can delay the modem disconnect after DTR drops.

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

  3. Re: Details of ppp & modem shut-down

    On 30 Jun 2003 10:28:20 GMT, eas-lab@absamail.co.za put finger to
    keyboard and composed:

    >Netters !
    >
    > I get the impression that few people really know the detailed
    >shut-down procedure that happens when one 'exits ppp and
    >disconnects the modem from the telco-line'.
    >
    >By using "ATM2D 3407501" to my modem ( M2 for sound on),
    >I can hear when the carrier stops. Perhaps the CD led would
    >show this. But carrier TX and Rx are different.
    >
    >There is 2 to 3 seconds delay from the 'ppp-off' command until
    >the carrier sound stops.
    >
    >Apparently the modem must exit the talking-ppp-mode
    >into the command-mode, to drop-out the line-relay ?
    >
    >Q1. what are the ppp steps/states during exit ?


    See my other post in this thread.

    >Q2. what are the *details* of the modem changing from
    >'talking ppp' to command mode ?
    >
    >Q3. Are talking-ppp-mode and command-mode 7 or 8 bit ?


    In my case (Windows 95B, DUN 1.4) both are set to 8N1. In fact, as PPP
    is an 8-bit protocol, selecting 7E1 makes no sense.

    >Q4. going the other direction: what tells the modem to exit
    >command-mode into talking-ppp-mode ?


    The modem automatically switches from command mode to on-line mode
    after a successful CONNECT. Depending on your ISP, DUN will then
    complete a login process involving a username and password, after
    which your ISP will begin sending PPP packets. You can see this
    happening if you use a terminal app such as HyperTerminal to manually
    dial your ISP.

    >Thanks for any info,
    >
    >Chris Glur.
    >



    -- Franc Zabkar

    Please remove one 's' from my address when replying by email.

  4. Re: Details of ppp & modem shut-down

    On Mon, 30 Jun 2003 12:19:23 GMT, "Hooda Gest" put
    finger to keyboard and composed:

    >
    > wrote in message
    >news:3f0010c4$0$230@hades.is.co.za...
    >> Netters !
    >>
    >> I get the impression that few people really know the detailed
    >> shut-down procedure that happens when one 'exits ppp and
    >> disconnects the modem from the telco-line'.
    >>
    >> By using "ATM2D 3407501" to my modem ( M2 for sound on),
    >> I can hear when the carrier stops. Perhaps the CD led would
    >> show this. But carrier TX and Rx are different.
    >>
    >> There is 2 to 3 seconds delay from the 'ppp-off' command until
    >> the carrier sound stops.

    >
    >
    >What operating system?
    >
    >I do not get a 2-3 second delay with Windows after telling the system to
    >hang up by right-clicking on the connection icon and selecting disconnect.
    >It is less than half a second.


    I'm running Win95B, DUN 1.4. After clicking the "disconnect" tab in my
    DUN connectoid at 00:00, my logs show the following data (date/time
    edited for clarity):

    ppplog
    ------

    00.61 - Remote access driver is shutting down.
    00.61 - CRC Errors 0
    00.61 - Timeout Errors 0
    00.61 - Alignment Errors 0
    00.61 - Overrun Errors 0
    00.61 - Framing Errors 0
    00.61 - Buffer Overrun Errors 0
    00.61 - Incomplete Packets 0
    00.61 - Bytes Received 2013799
    00.61 - Bytes Transmittted 190303
    00.61 - Frames Received 4116
    00.61 - Frames Transmitted 2598
    00.61 - LCP : Layer down.
    00.61 - IPCP : Layer down.
    00.61 - CCP : Layer started.
    00.61 - PPP : Transmitting Control Packet of length: 6
    00.61 - Data 0000: c0 21 05 03 00 04 00 00 | .!......
    00.72 - PPP : Received Control Packet of length: 6
    00.72 - Data 0000: c0 21 06 03 00 04 00 00 | .!......
    00.72 - LCP : Received terminate acknowledgement.
    00.72 - LCP : Layer finished.
    00.72 - Microsoft Dial Up Adapter log closed.

    modemlog
    --------

    00.76 - Hanging up the modem.
    00.76 - Hardware hangup by lowering DTR.
    02.37 - Recv: NO CARRIER
    02.37 - Interpreted response: No Carrier
    02.37 - Send: ATH
    02.37 - Recv: ATH
    02.37 - Recv: OK
    02.37 - Interpreted response: Ok
    02.41 - Session Statistics:
    02.41 - Reads : 2014132 bytes
    02.41 - Writes: 190449 bytes
    02.41 - Rockwell 56K ACF II Fax+Data+Voice Modem closed.


    -- Franc Zabkar

    Please remove one 's' from my address when replying by email.

  5. Re: Details of ppp & modem shut-down


    "Franc Zabkar" wrote in message
    news:qs02gv4s0q5jb798vpbap3bo4ffc8oq520@4ax.com...
    > On Mon, 30 Jun 2003 12:19:23 GMT, "Hooda Gest" put
    > finger to keyboard and composed:
    >
    > >
    > > wrote in message
    > >news:3f0010c4$0$230@hades.is.co.za...
    > >> Netters !
    > >>
    > >> I get the impression that few people really know the detailed
    > >> shut-down procedure that happens when one 'exits ppp and
    > >> disconnects the modem from the telco-line'.
    > >>
    > >> By using "ATM2D 3407501" to my modem ( M2 for sound on),
    > >> I can hear when the carrier stops. Perhaps the CD led would
    > >> show this. But carrier TX and Rx are different.
    > >>
    > >> There is 2 to 3 seconds delay from the 'ppp-off' command until
    > >> the carrier sound stops.

    > >
    > >
    > >What operating system?
    > >
    > >I do not get a 2-3 second delay with Windows after telling the system to
    > >hang up by right-clicking on the connection icon and selecting

    disconnect.
    > >It is less than half a second.

    >
    > I'm running Win95B, DUN 1.4. After clicking the "disconnect" tab in my
    > DUN connectoid at 00:00, my logs show the following data (date/time
    > edited for clarity):
    >
    > ppplog
    > ------
    >
    > 00.61 - Remote access driver is shutting down.
    > 00.61 - CRC Errors 0
    > 00.61 - Timeout Errors 0
    > 00.61 - Alignment Errors 0
    > 00.61 - Overrun Errors 0
    > 00.61 - Framing Errors 0
    > 00.61 - Buffer Overrun Errors 0
    > 00.61 - Incomplete Packets 0
    > 00.61 - Bytes Received 2013799
    > 00.61 - Bytes Transmittted 190303
    > 00.61 - Frames Received 4116
    > 00.61 - Frames Transmitted 2598
    > 00.61 - LCP : Layer down.
    > 00.61 - IPCP : Layer down.
    > 00.61 - CCP : Layer started.
    > 00.61 - PPP : Transmitting Control Packet of length: 6
    > 00.61 - Data 0000: c0 21 05 03 00 04 00 00 | .!......
    > 00.72 - PPP : Received Control Packet of length: 6
    > 00.72 - Data 0000: c0 21 06 03 00 04 00 00 | .!......
    > 00.72 - LCP : Received terminate acknowledgement.
    > 00.72 - LCP : Layer finished.
    > 00.72 - Microsoft Dial Up Adapter log closed.
    >
    > modemlog
    > --------
    >
    > 00.76 - Hanging up the modem.
    > 00.76 - Hardware hangup by lowering DTR.
    > 02.37 - Recv: NO CARRIER


    Your modem responded quite poorly to a drop of DTR, don't you think?

    From my log...

    07-01-2003 08:35:00.13 - Hanging up the modem.
    07-01-2003 08:35:00.13 - Hardware hangup by lowering DTR.
    07-01-2003 08:35:00.95 - Recv: OK
    07-01-2003 08:35:00.95 - Interpreted response: Ok
    07-01-2003 08:35:00.95 - Send: ATH
    07-01-2003 08:35:00.97 - Recv: OK
    07-01-2003 08:35:00.97 - Interpreted response: Ok
    07-01-2003 08:35:00.97 - 115200,N,8,1
    07-01-2003 08:35:02.12 - Session Statistics:
    07-01-2003 08:35:02.12 - Reads : 1927269 bytes
    07-01-2003 08:35:02.12 - Writes: 205407 bytes
    07-01-2003 08:35:02.12 - SupraMax 56i Voice PCI closed.


    Note that the 2 second delay is *after* the modem has disconnected.

    --

    Hooda Gest
    "The only thing I do immediately is procrastinate."








  6. Re: Details of ppp & modem shut-down

    On Tue, 01 Jul 2003 12:38:24 GMT, "Hooda Gest" put
    finger to keyboard and composed:

    >
    >"Franc Zabkar" wrote in message
    >news:qs02gv4s0q5jb798vpbap3bo4ffc8oq520@4ax.com...
    >> On Mon, 30 Jun 2003 12:19:23 GMT, "Hooda Gest" put
    >> finger to keyboard and composed:
    >>
    >> >
    >> > wrote in message
    >> >news:3f0010c4$0$230@hades.is.co.za...
    >> >> Netters !
    >> >>
    >> >> I get the impression that few people really know the detailed
    >> >> shut-down procedure that happens when one 'exits ppp and
    >> >> disconnects the modem from the telco-line'.
    >> >>
    >> >> By using "ATM2D 3407501" to my modem ( M2 for sound on),
    >> >> I can hear when the carrier stops. Perhaps the CD led would
    >> >> show this. But carrier TX and Rx are different.
    >> >>
    >> >> There is 2 to 3 seconds delay from the 'ppp-off' command until
    >> >> the carrier sound stops.
    >> >
    >> >
    >> >What operating system?
    >> >
    >> >I do not get a 2-3 second delay with Windows after telling the system to
    >> >hang up by right-clicking on the connection icon and selecting

    >disconnect.
    >> >It is less than half a second.

    >>
    >> I'm running Win95B, DUN 1.4. After clicking the "disconnect" tab in my
    >> DUN connectoid at 00:00, my logs show the following data (date/time
    >> edited for clarity):
    >>
    >> ppplog
    >> ------
    >>
    >> 00.61 - Remote access driver is shutting down.
    >> 00.61 - CRC Errors 0
    >> 00.61 - Timeout Errors 0
    >> 00.61 - Alignment Errors 0
    >> 00.61 - Overrun Errors 0
    >> 00.61 - Framing Errors 0
    >> 00.61 - Buffer Overrun Errors 0
    >> 00.61 - Incomplete Packets 0
    >> 00.61 - Bytes Received 2013799
    >> 00.61 - Bytes Transmittted 190303
    >> 00.61 - Frames Received 4116
    >> 00.61 - Frames Transmitted 2598
    >> 00.61 - LCP : Layer down.
    >> 00.61 - IPCP : Layer down.
    >> 00.61 - CCP : Layer started.
    >> 00.61 - PPP : Transmitting Control Packet of length: 6
    >> 00.61 - Data 0000: c0 21 05 03 00 04 00 00 | .!......
    >> 00.72 - PPP : Received Control Packet of length: 6
    >> 00.72 - Data 0000: c0 21 06 03 00 04 00 00 | .!......
    >> 00.72 - LCP : Received terminate acknowledgement.
    >> 00.72 - LCP : Layer finished.
    >> 00.72 - Microsoft Dial Up Adapter log closed.
    >>
    >> modemlog
    >> --------
    >>
    >> 00.76 - Hanging up the modem.
    >> 00.76 - Hardware hangup by lowering DTR.
    >> 02.37 - Recv: NO CARRIER

    >
    >Your modem responded quite poorly to a drop of DTR, don't you think?


    Hmm. Your modem requires 0.82 sec to respond to a drop in DTR, while
    mine requires 1.61 sec. I wouldn't say that's too bad. In any case,
    both modems lower CD within the 1.2 sec allowed for by DUN, which is
    the important thing. BTW, I have always had S38=0 in my init string,
    so the 1.6 second delay is not due to the modem emptying its Tx/Rx
    buffers. See the documentation below.

    >From my log...
    >
    >07-01-2003 08:35:00.13 - Hanging up the modem.
    >07-01-2003 08:35:00.13 - Hardware hangup by lowering DTR.
    >07-01-2003 08:35:00.95 - Recv: OK
    >07-01-2003 08:35:00.95 - Interpreted response: Ok
    >07-01-2003 08:35:00.95 - Send: ATH
    >07-01-2003 08:35:00.97 - Recv: OK
    >07-01-2003 08:35:00.97 - Interpreted response: Ok
    >07-01-2003 08:35:00.97 - 115200,N,8,1
    >07-01-2003 08:35:02.12 - Session Statistics:
    >07-01-2003 08:35:02.12 - Reads : 1927269 bytes
    >07-01-2003 08:35:02.12 - Writes: 205407 bytes
    >07-01-2003 08:35:02.12 - SupraMax 56i Voice PCI closed.
    >
    >
    >Note that the 2 second delay is *after* the modem has disconnected.


    Actually, it's more like a 1.17 sec delay after disconnection. My log
    closes within 0.04 sec of the final ATH command, whereas yours takes a
    relatively long time, possibly because controllerless modems require
    more housekeeping (?). Or perhaps your version of DUN behaves
    differently?

    Here is an excerpt from Rockwell's documentation for the S38 register
    alluded to previously.

    ================================================== ====================
    S38 specifies the delay between the modem's receipt of the H command
    to disconnect (or ON-to-OFF transition of DTR if the modem is
    programmed to follow the signal), and the disconnect operation.
    Applicable to error-correction connection only. This register can be
    used to ensure that data in the modem buffer is sent before the modem
    disconnects.

    1. If S38 is set to a value between 0 and 254, the modem will wait
    that number of seconds for the remote modem to acknowledge all data in
    the modem buffer before disconnecting. If time expires before all data
    is sent, the NO CARRIER result code will be issued to indicate that
    data has been lost. If all data is transmitted prior to time-out, the
    response to the H0 command will be OK.
    ================================================== ====================

    Strangely, my modemlogs *always* show a NO CARRIER response after
    disconnection, never an OK, suggesting that data have been lost. This
    is despite closing down all my Internet applications well before
    logout.


    - Franc Zabkar
    --
    Please remove one 's' from my address when replying by email.

  7. Re: Details of ppp & modem shut-down


    "Franc Zabkar" wrote in message
    news:9e65gv8e9sksgdh8vjnpj2l9sairltfav5@4ax.com...
    > On Tue, 01 Jul 2003 12:38:24 GMT, "Hooda Gest" put
    > finger to keyboard and composed:
    >
    > >
    > >"Franc Zabkar" wrote in message
    > >news:qs02gv4s0q5jb798vpbap3bo4ffc8oq520@4ax.com...
    > >> On Mon, 30 Jun 2003 12:19:23 GMT, "Hooda Gest" put
    > >> finger to keyboard and composed:
    > >>
    > >> >
    > >> > wrote in message
    > >> >news:3f0010c4$0$230@hades.is.co.za...
    > >> >> Netters !
    > >> >>
    > >> >> I get the impression that few people really know the detailed
    > >> >> shut-down procedure that happens when one 'exits ppp and
    > >> >> disconnects the modem from the telco-line'.
    > >> >>
    > >> >> By using "ATM2D 3407501" to my modem ( M2 for sound on),
    > >> >> I can hear when the carrier stops. Perhaps the CD led would
    > >> >> show this. But carrier TX and Rx are different.
    > >> >>
    > >> >> There is 2 to 3 seconds delay from the 'ppp-off' command until
    > >> >> the carrier sound stops.
    > >> >
    > >> >
    > >> >What operating system?
    > >> >
    > >> >I do not get a 2-3 second delay with Windows after telling the system

    to
    > >> >hang up by right-clicking on the connection icon and selecting

    > >disconnect.
    > >> >It is less than half a second.
    > >>
    > >> I'm running Win95B, DUN 1.4. After clicking the "disconnect" tab in my
    > >> DUN connectoid at 00:00, my logs show the following data (date/time
    > >> edited for clarity):
    > >>
    > >> ppplog
    > >> ------
    > >>
    > >> 00.61 - Remote access driver is shutting down.
    > >> 00.61 - CRC Errors 0
    > >> 00.61 - Timeout Errors 0
    > >> 00.61 - Alignment Errors 0
    > >> 00.61 - Overrun Errors 0
    > >> 00.61 - Framing Errors 0
    > >> 00.61 - Buffer Overrun Errors 0
    > >> 00.61 - Incomplete Packets 0
    > >> 00.61 - Bytes Received 2013799
    > >> 00.61 - Bytes Transmittted 190303
    > >> 00.61 - Frames Received 4116
    > >> 00.61 - Frames Transmitted 2598
    > >> 00.61 - LCP : Layer down.
    > >> 00.61 - IPCP : Layer down.
    > >> 00.61 - CCP : Layer started.
    > >> 00.61 - PPP : Transmitting Control Packet of length: 6
    > >> 00.61 - Data 0000: c0 21 05 03 00 04 00 00 | .!......
    > >> 00.72 - PPP : Received Control Packet of length: 6
    > >> 00.72 - Data 0000: c0 21 06 03 00 04 00 00 | .!......
    > >> 00.72 - LCP : Received terminate acknowledgement.
    > >> 00.72 - LCP : Layer finished.
    > >> 00.72 - Microsoft Dial Up Adapter log closed.
    > >>
    > >> modemlog
    > >> --------
    > >>
    > >> 00.76 - Hanging up the modem.
    > >> 00.76 - Hardware hangup by lowering DTR.
    > >> 02.37 - Recv: NO CARRIER

    > >
    > >Your modem responded quite poorly to a drop of DTR, don't you think?

    >
    > Hmm. Your modem requires 0.82 sec to respond to a drop in DTR, while
    > mine requires 1.61 sec. I wouldn't say that's too bad. In any case,
    > both modems lower CD within the 1.2 sec allowed for by DUN, which is
    > the important thing. BTW, I have always had S38=0 in my init string,
    > so the 1.6 second delay is not due to the modem emptying its Tx/Rx
    > buffers. See the documentation below.



    Then, basically, it's a "6 of one, half dozen of the other" situation...

    >
    > >From my log...
    > >
    > >07-01-2003 08:35:00.13 - Hanging up the modem.
    > >07-01-2003 08:35:00.13 - Hardware hangup by lowering DTR.
    > >07-01-2003 08:35:00.95 - Recv: OK
    > >07-01-2003 08:35:00.95 - Interpreted response: Ok
    > >07-01-2003 08:35:00.95 - Send: ATH
    > >07-01-2003 08:35:00.97 - Recv: OK
    > >07-01-2003 08:35:00.97 - Interpreted response: Ok
    > >07-01-2003 08:35:00.97 - 115200,N,8,1
    > >07-01-2003 08:35:02.12 - Session Statistics:
    > >07-01-2003 08:35:02.12 - Reads : 1927269 bytes
    > >07-01-2003 08:35:02.12 - Writes: 205407 bytes
    > >07-01-2003 08:35:02.12 - SupraMax 56i Voice PCI closed.
    > >
    > >
    > >Note that the 2 second delay is *after* the modem has disconnected.

    >
    > Actually, it's more like a 1.17 sec delay after disconnection. My log
    > closes within 0.04 sec of the final ATH command, whereas yours takes a
    > relatively long time, possibly because controllerless modems require
    > more housekeeping (?). Or perhaps your version of DUN behaves
    > differently?


    Both good possibilities. I am running version 1.4 of DUN under Win98SE.

    I'll have to check this under my home system which uses an external serial
    modem.


    > Here is an excerpt from Rockwell's documentation for the S38 register
    > alluded to previously.
    >
    > ================================================== ====================
    > S38 specifies the delay between the modem's receipt of the H command
    > to disconnect (or ON-to-OFF transition of DTR if the modem is
    > programmed to follow the signal), and the disconnect operation.
    > Applicable to error-correction connection only. This register can be
    > used to ensure that data in the modem buffer is sent before the modem
    > disconnects.
    >
    > 1. If S38 is set to a value between 0 and 254, the modem will wait
    > that number of seconds for the remote modem to acknowledge all data in
    > the modem buffer before disconnecting. If time expires before all data
    > is sent, the NO CARRIER result code will be issued to indicate that
    > data has been lost. If all data is transmitted prior to time-out, the
    > response to the H0 command will be OK.
    > ================================================== ====================
    >
    > Strangely, my modemlogs *always* show a NO CARRIER response after
    > disconnection, never an OK, suggesting that data have been lost. This
    > is despite closing down all my Internet applications well before
    > logout.



    Wouldn't be the first time a design spec didn't match with reality, I guess.
    But my SupraMax uses the Conexant chipset and it does respond with "OK"...


    --

    Hooda Gest
    "The only thing I do immediately is procrastinate."







  8. Re: Details of ppp & modem shut-down


    "Greg Andrews" wrote in message
    news:be32pr$8if$2@reader1.panix.com...
    > "Hooda Gest" writes:
    > >
    > >
    > >07-01-2003 08:35:00.13 - Hanging up the modem.
    > >07-01-2003 08:35:00.13 - Hardware hangup by lowering DTR.
    > >07-01-2003 08:35:00.95 - Recv: OK

    >
    > Egad. That's broken.


    No, it isn't.

    >
    > >07-01-2003 08:35:00.95 - Interpreted response: Ok
    > >07-01-2003 08:35:00.95 - Send: ATH
    > >07-01-2003 08:35:00.97 - Recv: OK

    >
    > Oh. Your modem is configured to go into command mode when
    > DTR stops, instead of disconnect. Not a broken modem, just
    > a broken (most likely) init string.



    And, no, it isn't. That is exactly how the modem is supposed to behave.


    --
    Hooda Gest
    "In a New York minute, everything can change..."



  9. Re: Details of ppp & modem shut-down


    "Greg Andrews" wrote in message
    news:beuovm$kpp$1@reader1.panix.com...
    > "Hooda Gest" writes:
    > >
    > >"Greg Andrews" wrote in message
    > >news:be32pr$8if$2@reader1.panix.com...
    > >> "Hooda Gest" writes:
    > >> >
    > >> >
    > >> >07-01-2003 08:35:00.13 - Hanging up the modem.
    > >> >07-01-2003 08:35:00.13 - Hardware hangup by lowering DTR.
    > >> >07-01-2003 08:35:00.95 - Recv: OK
    > >> >07-01-2003 08:35:00.95 - Interpreted response: Ok
    > >> >07-01-2003 08:35:00.95 - Send: ATH
    > >> >07-01-2003 08:35:00.97 - Recv: OK
    > >>
    > >> Oh. Your modem is configured to go into command mode when
    > >> DTR stops, instead of disconnect. Not a broken modem, just
    > >> a broken (most likely) init string.

    > >
    > >
    > >And, no, it isn't. That is exactly how the modem is supposed to behave.
    > >

    >
    > Your software testifies otherwise. It declares in its log that
    > it expects the modem to hang up the phone line when it drops DTR.
    > It's intelligent enough to fall back to sending ATH when the modem
    > doesn't cooperate, but it's clear that's a fallback when the modem
    > does not behave the way it's supposed to.



    The correct response to DTR being dropped in the USR is "OK". Exactly what
    shows in the log. The ATH is simply something DUN sends for "housekeeping".
    If DUN had failed to recognize that the modem had disconnected, it would
    have reported that the hardware attempt to hangup had filaed and that it was
    trying to do it with software. In which case, the ATH would have been
    preceded by the three plus symbols.


    --

    Hooda Gest
    "The only thing I do immediately is procrastinate."





+ Reply to Thread