Re: Modem changes behavior after Sarge Update
On Tuesday 21 February 2006 17:41, Mike McCarty wrote:
> Hal Vaughan wrote:
>
> [snip]
>
> > Now whenever a program ends, or if I kill a program (so it doesn't have
> > time to exit), I can tell by watching the modem that it hangs up
> > immediately (the carrier detect led goes off instantly, along with the
> > clear-to-send light). I'd think this was a Perl problem, since my
> > programs are in Perl, but it can't be a reset routine, since I lose the
> > connection even if I kill the program, without it being able to go
> > through closing down.
>
> This type of behavior is usually caused by "dropping DTR".
Sounds VERY reasonable. Something I overlooked because I was searching
elsewhere for answers. I can see how that could be changed in the
configuration somewhere during the update, or in a module. I'll check it out
and test it out by connecting to another system on my LAN through the 2nd
phone line.
> > I do not have a detailed knowledge of serial interfaces, but my best
> > guess is that a setting was changed on the serial port or there is
> > something different in the newer kernel in device drivers. Any help in
> > figuring out what I need to check in serial port settings or device
> > drivers would be extremely helpful. (The modem does not use a special
> > driver.)
>
> There are handshake signals used in the RS232. The Data Terminal
> Equipment (DTE) (in this case, your computer) signals that it is ready
> by asserting Data Terminal Ready (DTR). The Data Communications
> Equipment (DCE) signals it is ready by asserting Data Set Ready
> (DSR). When the DTE wants to send something, it asserts Request
> To Send (RTS). When the DCE is then ready to transmit, it asserts
> Clear To Send (CTS). Most modems are configured so that if DTR
> is deasserted, they go back on-hook. If your modem displays DTR,
> you can check to see whether it is being "dropped".
>
> You might find this http://www.arcelect.com/rs232.htm helpful
That's more useful information about the serial port than I've found in one
place before. Thanks for the resource. I've bookmarked it so I can use it
for future reference. I've found that detailed information on the serial
port and modems, especially from the settings and software point of view, is
not always easy to find -- at least if you're looking for info that a
non-systems programmer can understand.
> [snip]
>
> > Today, the modem can dial and function, EXCEPT whenever the program using
> > it ends or is killed, the modem drops its connection. I have no idea
> > why, so any help is appreciated. What could be changed that could force
> > the modem to hang up whenever the controlling program is killed?
>
> The first step is to find out why the modem is dropping carrier
> and going on-hook. Either:
>
> (1) the modem was ignoring DTR before, but has
> been reconfigured, possibly by the driver
> (2) something changed on your computer so that
> DTR is now dropped when it was not before
> (3) a change in software (possibly driver) now
> commands the modem to go on-hook when the
> device is closed
> (4) something else I haven't thought of yet
I notice the key element in a number of these is DTR. I missed it. (I was
checking for carrier detect values and some other things.) If that's it,
it's easily fixed by making sure my programs specifically set the port and
modem to deal with this as they always did before, by default.
> I suggest you look into whether you can configure your modem
> not to drop carrier when DTR is dropped. If you can, then
> changing this setting may show that it is indeed the cause.
> You can just run this way, or get someone who knows more
> about configuring serial ports in Debian to help you set it
> so that DTR does not get dropped when the port is closed.
>
> If dropping DTR is not the cause, then something else is
> happening. You'll have to find out what that is before
> you can make progress making it not happen.
And that's what I'm hoping is NOT going on. If it's the DTR, I can fix it in
short order and actually get to sleep tonight.
Thanks for such a quick, full, and helpful reply. One thing I really like
about this list is the depth of expertise of the people on this list and
their willingness to share it.
I'll post what the results turn out to be.
Thanks!
Hal
Reply to: