Hello any tty gurus,
If a modem is connected to /dev/ttyS0 and a getty (actually agetty)
is associated with that device, one can log-in using that modem.
This is how we've operated for many years. But, Linux version 2.4.20
presents a new problem.
When a logged-in caller logs out, it is mandatory for the modem
to disconnect. This has previously been done automatically when
the terminal is closed. The closing of the tasks file-descriptors
will eventually call tty_hangup() and the modem would (previously)
hang up.
Something has changed so that the hang-up sequence doesn't happen if
agetty has already opened the terminal for another possible connection.
It used to be that the caller, calling close(), did not get control
back until the modem had been hung up. This prevented another agetty
from opening that terminal for I/O because the previous task had not
completed its exit procedure until the terminal was hung up.
Now, the hang-up sequence appears to be queued. It can (and does)
happen after the previous terminal owner has expired and another
owner has opened the device. This makes /dev/ttyS0 useless for remote
log-ins.
It needs to be, that a 'close()' of a terminal, configured as a modem,
cannot return to the caller until after the DTR has been lowered, and
preferably, after waiting a few hundred milliseconds. Without this,
once logged in, the modem will never disconnect so a new caller
can't log in.
With faster machines, it is not sufficient to just lower DTR. One
needs to lower DTR and then wait. This is because the next task
can open that terminal in a few hundred microseconds, raising
DTR again. This is not enough time for the modem to hang up because
there is "glitch-filtering" on all modem-control leads. The hang-up
event won't even be seen by the modem.
So, either the modem control needs to be reverted to its previous
functionality or `agetty` needs to hang up its terminal when it
starts, which seems backwards. In other words, the user of kernel
services should not have to compensate for a defect in the logic
of that service.
I have temporarily "fixed" this problem by modifying `agetty`.
Can the kernel please be fixed instead?
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
Richard B. Johnson wrote:
> Now, the hang-up sequence appears to be queued. It can (and does)
> happen after the previous terminal owner has expired and another
> owner has opened the device. This makes /dev/ttyS0 useless for remote
> log-ins.
>
> It needs to be, that a 'close()' of a terminal, configured as a modem,
> cannot return to the caller until after the DTR has been lowered, and
> preferably, after waiting a few hundred milliseconds. Without this,
> once logged in, the modem will never disconnect so a new caller
> can't log in.
Better would be if the hang-up sequence is still queued, but a new
open() is delayed until the hangup has completed.
-- Jamie
On Mon, Mar 17, 2003 at 8:19 AM, Richard B. Johnson wrote:
> Hello any tty gurus,
>
> If a modem is connected to /dev/ttyS0 and a getty (actually agetty)
> is associated with that device, one can log-in using that modem.
>
> This is how we've operated for many years. But, Linux version 2.4.20
> presents a new problem.
>
> When a logged-in caller logs out, it is mandatory for the modem
> to disconnect. This has previously been done automatically when
> the terminal is closed. The closing of the tasks file-descriptors
> will eventually call tty_hangup() and the modem would (previously)
> hang up.
>
> Something has changed so that the hang-up sequence doesn't happen if
> agetty has already opened the terminal for another possible
> connection.
> It used to be that the caller, calling close(), did not get control
> back until the modem had been hung up. This prevented another agetty
> from opening that terminal for I/O because the previous task had not
> completed its exit procedure until the terminal was hung up.
>
> Now, the hang-up sequence appears to be queued. It can (and does)
> happen after the previous terminal owner has expired and another
> owner has opened the device. This makes /dev/ttyS0 useless for remote
> log-ins.
>
> It needs to be, that a 'close()' of a terminal, configured as a modem,
> cannot return to the caller until after the DTR has been lowered, and
> preferably, after waiting a few hundred milliseconds. Without this,
> once logged in, the modem will never disconnect so a new caller
> can't log in.
>
> With faster machines, it is not sufficient to just lower DTR. One
> needs to lower DTR and then wait. This is because the next task
> can open that terminal in a few hundred microseconds, raising
> DTR again. This is not enough time for the modem to hang up because
> there is "glitch-filtering" on all modem-control leads. The hang-up
> event won't even be seen by the modem.
>
> So, either the modem control needs to be reverted to its previous
> functionality or `agetty` needs to hang up its terminal when it
> starts, which seems backwards. In other words, the user of kernel
> services should not have to compensate for a defect in the logic
> of that service.
>
> I have temporarily "fixed" this problem by modifying `agetty`.
> Can the kernel please be fixed instead?
>
Hi Richard,
Is the HUPCL cflags option (termio hang-up-on-close) asserted
when the close happens?
The "drop DTR and then wait a bit" behavior is requested by the
HUPCL termio option. Otherwise, if CLOCAL is off, it is supposed
to just drop DTR with no guarantee of holding it low for any
particular amount of time.
cheers,
Ed
----------------------------------------------------------------
Ed Vance edv (at) macrolink (dot) com
Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807
----------------------------------------------------------------
On Mon, 17 Mar 2003, Jamie Lokier wrote:
> Richard B. Johnson wrote:
> > Now, the hang-up sequence appears to be queued. It can (and does)
> > happen after the previous terminal owner has expired and another
> > owner has opened the device. This makes /dev/ttyS0 useless for remote
> > log-ins.
> >
> > It needs to be, that a 'close()' of a terminal, configured as a modem,
> > cannot return to the caller until after the DTR has been lowered, and
> > preferably, after waiting a few hundred milliseconds. Without this,
> > once logged in, the modem will never disconnect so a new caller
> > can't log in.
>
> Better would be if the hang-up sequence is still queued, but a new
> open() is delayed until the hangup has completed.
>
> -- Jamie
>
Yes, something like that. Modems are "special" only one task is
going to access that device at one time.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
On Mon, 17 Mar 2003, Ed Vance wrote:
> On Mon, Mar 17, 2003 at 8:19 AM, Richard B. Johnson wrote:
> > Hello any tty gurus,
> >
> > If a modem is connected to /dev/ttyS0 and a getty (actually agetty)
> > is associated with that device, one can log-in using that modem.
> >
> > This is how we've operated for many years. But, Linux version 2.4.20
> > presents a new problem.
> >
> > When a logged-in caller logs out, it is mandatory for the modem
> > to disconnect. This has previously been done automatically when
> > the terminal is closed. The closing of the tasks file-descriptors
> > will eventually call tty_hangup() and the modem would (previously)
> > hang up.
> >
> > Something has changed so that the hang-up sequence doesn't happen if
> > agetty has already opened the terminal for another possible
> > connection.
> > It used to be that the caller, calling close(), did not get control
> > back until the modem had been hung up. This prevented another agetty
> > from opening that terminal for I/O because the previous task had not
> > completed its exit procedure until the terminal was hung up.
> >
> > Now, the hang-up sequence appears to be queued. It can (and does)
> > happen after the previous terminal owner has expired and another
> > owner has opened the device. This makes /dev/ttyS0 useless for remote
> > log-ins.
> >
> > It needs to be, that a 'close()' of a terminal, configured as a modem,
> > cannot return to the caller until after the DTR has been lowered, and
> > preferably, after waiting a few hundred milliseconds. Without this,
> > once logged in, the modem will never disconnect so a new caller
> > can't log in.
> >
> > With faster machines, it is not sufficient to just lower DTR. One
> > needs to lower DTR and then wait. This is because the next task
> > can open that terminal in a few hundred microseconds, raising
> > DTR again. This is not enough time for the modem to hang up because
> > there is "glitch-filtering" on all modem-control leads. The hang-up
> > event won't even be seen by the modem.
> >
> > So, either the modem control needs to be reverted to its previous
> > functionality or `agetty` needs to hang up its terminal when it
> > starts, which seems backwards. In other words, the user of kernel
> > services should not have to compensate for a defect in the logic
> > of that service.
> >
> > I have temporarily "fixed" this problem by modifying `agetty`.
> > Can the kernel please be fixed instead?
> >
> Hi Richard,
>
> Is the HUPCL cflags option (termio hang-up-on-close) asserted
> when the close happens?
>
> The "drop DTR and then wait a bit" behavior is requested by the
> HUPCL termio option. Otherwise, if CLOCAL is off, it is supposed
> to just drop DTR with no guarantee of holding it low for any
> particular amount of time.
>
> cheers,
> Ed
Well I didn't want to have to re-write agetty. Upon boot, before
init spawns an agetty, I initialize the modem in 'raw' mode like
this......
/*
* Set to dumb RAW mode with no echo and no character interpretation.
*/
memset(&io_mod, 0x00, sizeof(io_mod)); /* bzero() is obsolete */
io_mod.c_cflag = B57600|CS8|CREAD|CLOCAL;
io_mod.c_iflag = IGNBRK|IGNPAR;
io_mod.c_cc[VMIN] = (cc_t) 1;
io_mod.c_cc[VTIME] = (cc_t) 1;
if(ioctl(fd, TCSETS, &io_mod) < 0)
{
fprintf(stderr, "ioctl of %s failed setting parameters (%s)\n",
argv[1], strerror(errno));
ERROR_EXIT;
}
(void)hangup(fd, buffer);
Hangup just sets the baud-rate to B0 while keeing all other parameters
the same. It waits a second, then restores the c_clag variables.
This program then sends initialization strings to the modem, reads
any echo, then closes. This makes sure that agetty gets connected
to a modem that will actually answer a call. Agetty sleeps in open()
because it attempts to open the terminal in blocking mode. That way
agetty will only wake up after a connection is made. Agetty then
sets its own parameters which include HUPCL Line 1116:
tp->c_cflag = CS8|HUPCL|CREAD| op->speeds[FIRST_SPEED];
Later on, it sets CRTSCTS when it examines the device parameters.
So, although my initialization program didn't set HUPCL, agetty did.
The problem is that agetty execs (does not fork and exec) so it becomes
/bin/login. /bin/login execs and becomes /bin/bash. There is no
program waiting to restore modem parameters. When /bin/bash exits,
/sbin/init will spawn another agetty task and the process repeats.
If, when /bin/bash exits, the close doesn't lower DTR long enough,
the modem will not hang up.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
On Mon, Mar 17, 2003 at 1:33 PM, Richard B. Johnson wrote:
>
> On Mon, 17 Mar 2003, Ed Vance wrote:
>
> > On Mon, Mar 17, 2003 at 8:19 AM, Richard B. Johnson wrote:
> > > Hello any tty gurus,
> > >
> > > If a modem is connected to /dev/ttyS0 and a getty
> (actually agetty)
> > > is associated with that device, one can log-in using that modem.
> > >
> > > This is how we've operated for many years. But, Linux
> version 2.4.20
> > > presents a new problem.
> > >
> > > When a logged-in caller logs out, it is mandatory for the modem
> > > to disconnect. This has previously been done automatically when
> > > the terminal is closed. The closing of the tasks file-descriptors
> > > will eventually call tty_hangup() and the modem would (previously)
> > > hang up.
> > >
> > > Something has changed so that the hang-up sequence
> doesn't happen if
> > > agetty has already opened the terminal for another possible
> > > connection.
> > > It used to be that the caller, calling close(), did not
> get control
> > > back until the modem had been hung up. This prevented
> another agetty
> > > from opening that terminal for I/O because the previous
> task had not
> > > completed its exit procedure until the terminal was hung up.
> > >
> > > Now, the hang-up sequence appears to be queued. It can (and does)
> > > happen after the previous terminal owner has expired and another
> > > owner has opened the device. This makes /dev/ttyS0
> useless for remote
> > > log-ins.
> > >
> > > It needs to be, that a 'close()' of a terminal,
> configured as a modem,
> > > cannot return to the caller until after the DTR has been
> lowered, and
> > > preferably, after waiting a few hundred milliseconds.
> Without this,
> > > once logged in, the modem will never disconnect so a new caller
> > > can't log in.
> > >
> > > With faster machines, it is not sufficient to just lower DTR. One
> > > needs to lower DTR and then wait. This is because the next task
> > > can open that terminal in a few hundred microseconds, raising
> > > DTR again. This is not enough time for the modem to hang
> up because
> > > there is "glitch-filtering" on all modem-control leads.
> The hang-up
> > > event won't even be seen by the modem.
> > >
> > > So, either the modem control needs to be reverted to its previous
> > > functionality or `agetty` needs to hang up its terminal when it
> > > starts, which seems backwards. In other words, the user of kernel
> > > services should not have to compensate for a defect in the logic
> > > of that service.
> > >
> > > I have temporarily "fixed" this problem by modifying `agetty`.
> > > Can the kernel please be fixed instead?
> > >
> > Hi Richard,
> >
> > Is the HUPCL cflags option (termio hang-up-on-close) asserted
> > when the close happens?
> >
> > The "drop DTR and then wait a bit" behavior is requested by the
> > HUPCL termio option. Otherwise, if CLOCAL is off, it is supposed
> > to just drop DTR with no guarantee of holding it low for any
> > particular amount of time.
> >
> > cheers,
> > Ed
>
> Well I didn't want to have to re-write agetty. Upon boot, before
> init spawns an agetty, I initialize the modem in 'raw' mode like
> this......
>
> /*
> * Set to dumb RAW mode with no echo and no character
> interpretation.
> */
> memset(&io_mod, 0x00, sizeof(io_mod)); /* bzero() is
> obsolete */
> io_mod.c_cflag = B57600|CS8|CREAD|CLOCAL;
> io_mod.c_iflag = IGNBRK|IGNPAR;
> io_mod.c_cc[VMIN] = (cc_t) 1;
> io_mod.c_cc[VTIME] = (cc_t) 1;
> if(ioctl(fd, TCSETS, &io_mod) < 0)
> {
> fprintf(stderr, "ioctl of %s failed setting
> parameters (%s)\n",
> argv[1], strerror(errno));
> ERROR_EXIT;
> }
> (void)hangup(fd, buffer);
>
> Hangup just sets the baud-rate to B0 while keeing all other parameters
> the same. It waits a second, then restores the c_clag variables.
>
> This program then sends initialization strings to the modem, reads
> any echo, then closes. This makes sure that agetty gets connected
> to a modem that will actually answer a call. Agetty sleeps in open()
> because it attempts to open the terminal in blocking mode. That way
> agetty will only wake up after a connection is made. Agetty then
> sets its own parameters which include HUPCL Line 1116:
> tp->c_cflag = CS8|HUPCL|CREAD| op->speeds[FIRST_SPEED];
> Later on, it sets CRTSCTS when it examines the device parameters.
>
> So, although my initialization program didn't set HUPCL, agetty did.
>
> The problem is that agetty execs (does not fork and exec) so
> it becomes
> /bin/login. /bin/login execs and becomes /bin/bash. There is no
> program waiting to restore modem parameters. When /bin/bash exits,
> /sbin/init will spawn another agetty task and the process repeats.
> If, when /bin/bash exits, the close doesn't lower DTR long enough,
> the modem will not hang up.
>
Hi Richard,
What you are doing looks just fine.
As long as HUPCL is set when the close happens, DTR will drop. There are
delays that are enforced in both open and close when a second process is
blocked opening a closing port. Of course, that would not be your case,
because the open does not occur until the closing process terminates. In a
quick look, I didn't see an enforced close-to-open delay for your case.
Maybe I missed something. I am looking at 2.4.18 Red Hat -3. I didn't notice
a patch to serial.c in the 2.4.19 or 2.4.20 changelog that would affect
this. There are some weird calculations that appear to scale the close_delay
field value based on HZ.
Which was the last "working" kernel rev that you used?
Did you switch to a faster CPU?
Are you using any "low latency" patches?
Did the HZ value change between the last rev that worked and 2.4.20?
What HZ value are you running with?
Cheers,
Ed
----------------------------------------------------------------
Ed Vance edv (at) macrolink (dot) com
Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807
----------------------------------------------------------------
On Mon, 17 Mar 2003, Ed Vance wrote:
[SNIPPED...]
> >
> Hi Richard,
>
> What you are doing looks just fine.
>
> As long as HUPCL is set when the close happens, DTR will drop. There are
> delays that are enforced in both open and close when a second process is
> blocked opening a closing port. Of course, that would not be your case,
> because the open does not occur until the closing process terminates. In a
> quick look, I didn't see an enforced close-to-open delay for your case.
> Maybe I missed something. I am looking at 2.4.18 Red Hat -3. I didn't notice
> a patch to serial.c in the 2.4.19 or 2.4.20 changelog that would affect
> this. There are some weird calculations that appear to scale the close_delay
> field value based on HZ.
>
> Which was the last "working" kernel rev that you used?
>
> Did you switch to a faster CPU?
>
> Are you using any "low latency" patches?
>
> Did the HZ value change between the last rev that worked and 2.4.20?
>
> What HZ value are you running with?
>
> Cheers,
> Ed
I'm now using 2.4.20. The previous version was 2.2.18 (yikes)!
I just transferred my old hard disks (SCSI) to a new system and
everything worked fine, so I decided to upgrade to a later more
stable kernel. I use this system to be my own internet provider
and I am, in fact, logged in running a ppp link from home over
the modem at this time. I had to modify `agetty` to make it
work with the new kernel and a faster CPU (1.2 GHz, 330 MHz
front-side bus, Tyan Thunder-II).
The agetty code is attached. It hangs up before it sleeps for
a new connection because when the previous process terminates,
init instantly starts a new instance, the modem never hangs up
even though, possibly the DTR was lowered for that instant.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
On Mon, Mar 17, 2003 at 4:34 PM, Richard B. Johnson wrote:
>
> On Mon, 17 Mar 2003, Ed Vance wrote:
> [SNIPPED...]
>
> > >
> > Hi Richard,
> >
> > What you are doing looks just fine.
> >
> > As long as HUPCL is set when the close happens, DTR will
> > drop. There are delays that are enforced in both open and
> > close when a second process is blocked opening a closing
> > port. Of course, that would not be your case, because the
> > open does not occur until the closing process terminates.
> > In a quick look, I didn't see an enforced close-to-open
> > delay for your case. Maybe I missed something. I am
> > looking at 2.4.18 Red Hat -3. I didn't notice a patch to
> > serial.c in the 2.4.19 or 2.4.20 changelog that would
> > affect this. There are some weird calculations that
> > appear to scale the close_delay field value based on HZ.
> >
> > Which was the last "working" kernel rev that you used?
> >
> > Did you switch to a faster CPU?
> >
> > Are you using any "low latency" patches?
> >
> > Did the HZ value change between the last rev that worked
> > and 2.4.20?
> >
> > What HZ value are you running with?
> >
> > Cheers,
> > Ed
>
> I'm now using 2.4.20. The previous version was 2.2.18 (yikes)!
> I just transferred my old hard disks (SCSI) to a new system and
> everything worked fine, so I decided to upgrade to a later more
> stable kernel. I use this system to be my own internet provider
> and I am, in fact, logged in running a ppp link from home over
> the modem at this time. I had to modify `agetty` to make it
> work with the new kernel and a faster CPU (1.2 GHz, 330 MHz
> front-side bus, Tyan Thunder-II).
>
> The agetty code is attached. It hangs up before it sleeps for
> a new connection because when the previous process terminates,
> init instantly starts a new instance, the modem never hangs up
> even though, possibly the DTR was lowered for that instant.
>
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
> Why is the government concerned about the lunatic fringe?
> Think about it.
>
Hi,
Yep. 2.2.18 was a good one.
I'll look at it.
Cheers,
Ed
----------------------------------------------------------------
Ed Vance edv (at) macrolink (dot) com
Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807
----------------------------------------------------------------
Richard,
You might give mgetty a try. I've been doing the same thing as
you with almost every version of Linux 2.4.x and some of 2.2.x. I don't
know the differences between agetty and mgetty, but I would like mgetty
could handle your needs.
Steve
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Richard B.
Johnson
Sent: Monday, March 17, 2003 6:34 PM
To: Ed Vance
Cc: Linux kernel
Subject: RE: Linux-2.4.20 modem control
On Mon, 17 Mar 2003, Ed Vance wrote:
[SNIPPED...]
> >
> Hi Richard,
>
> What you are doing looks just fine.
>
> As long as HUPCL is set when the close happens, DTR will drop. There
are
> delays that are enforced in both open and close when a second process
is
> blocked opening a closing port. Of course, that would not be your
case,
> because the open does not occur until the closing process terminates.
In a
> quick look, I didn't see an enforced close-to-open delay for your
case.
> Maybe I missed something. I am looking at 2.4.18 Red Hat -3. I didn't
notice
> a patch to serial.c in the 2.4.19 or 2.4.20 changelog that would
affect
> this. There are some weird calculations that appear to scale the
close_delay
> field value based on HZ.
>
> Which was the last "working" kernel rev that you used?
>
> Did you switch to a faster CPU?
>
> Are you using any "low latency" patches?
>
> Did the HZ value change between the last rev that worked and 2.4.20?
>
> What HZ value are you running with?
>
> Cheers,
> Ed
I'm now using 2.4.20. The previous version was 2.2.18 (yikes)!
I just transferred my old hard disks (SCSI) to a new system and
everything worked fine, so I decided to upgrade to a later more
stable kernel. I use this system to be my own internet provider
and I am, in fact, logged in running a ppp link from home over
the modem at this time. I had to modify `agetty` to make it
work with the new kernel and a faster CPU (1.2 GHz, 330 MHz
front-side bus, Tyan Thunder-II).
The agetty code is attached. It hangs up before it sleeps for
a new connection because when the previous process terminates,
init instantly starts a new instance, the modem never hangs up
even though, possibly the DTR was lowered for that instant.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about
it.
On Tue, 18 Mar 2003, Steve Lee wrote:
> Richard,
> You might give mgetty a try. I've been doing the same thing as
> you with almost every version of Linux 2.4.x and some of 2.2.x. I don't
> know the differences between agetty and mgetty, but I would like mgetty
> could handle your needs.
>
> Steve
They are all basically the same with certain "enhancements"
(work-arounds) for different things. You can run any of them
and hook a RS-232C terminal to your 'COM' port and log-in.
The problem is when you log out! With a terminal connected,
you get the login prompt again. This is no good if you are
connected to a modem. The modem will not be disconnected
and you have to forcably disconnect at the remote end by
disconnecting the phone line or lowering DTR with your remote
terminal program. Then the modem will not be ready to
answer another call. It will remain in a off-line condition
forever.
What needs to be done, is when the program (probably /bin/bash)
logs off (calls exit()), and STDIN_FILENO, STDOUT_FILENO, and
STDERR_FILENO get closed, the closure of that terminal must
cause the modem to hang-up and then, when init starts another
`getty` the modem will wait for another connection. The current
work-around is to modify a `getty` to hangup the modem, then
initialize I/O to wait for a new connection. This logic is
"backwards" and should be done transparently in the terminal
driver.
This problem is a 'discovered check` which happens with higher
speed machines. At one time, init was so slow in getting another
getty on-line that the modem had a chance to hang up. This is
no longer the case and is being worked on by one of the terminal
driver contributors as I write this.
It will eventually be fixed. I included the source-code of a
work-around in some previous communications, just in case others
have the same problem. Many will not because very few log-in
using a modem anymore.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
Please excuse my lack of understanding. My dial-in box (using mgetty)
is running on a dual Athlon 1900 MP system. Previous system was a dual
P3 450. I've called into the Athlon system multiple times a day for
almost a year now, the previous system, for several years. What issue
should I be seeing? At times, I send some files home and when I get
home I'll have to manually reset the modem (reset button), however,
mgetty resets and is ready to answer again. I have mgetty configured to
skip the first call, then answer with the modem if another call happens
within 45 seconds.
Steve
-----Original Message-----
From: Richard B. Johnson [mailto:[email protected]]
Sent: Tuesday, March 18, 2003 1:17 PM
To: Steve Lee
Cc: Linux kernel
Subject: RE: Linux-2.4.20 modem control
On Tue, 18 Mar 2003, Steve Lee wrote:
> Richard,
> You might give mgetty a try. I've been doing the same thing as
> you with almost every version of Linux 2.4.x and some of 2.2.x. I
don't
> know the differences between agetty and mgetty, but I would like
mgetty
> could handle your needs.
>
> Steve
They are all basically the same with certain "enhancements"
(work-arounds) for different things. You can run any of them
and hook a RS-232C terminal to your 'COM' port and log-in.
The problem is when you log out! With a terminal connected,
you get the login prompt again. This is no good if you are
connected to a modem. The modem will not be disconnected
and you have to forcably disconnect at the remote end by
disconnecting the phone line or lowering DTR with your remote
terminal program. Then the modem will not be ready to
answer another call. It will remain in a off-line condition
forever.
What needs to be done, is when the program (probably /bin/bash)
logs off (calls exit()), and STDIN_FILENO, STDOUT_FILENO, and
STDERR_FILENO get closed, the closure of that terminal must
cause the modem to hang-up and then, when init starts another
`getty` the modem will wait for another connection. The current
work-around is to modify a `getty` to hangup the modem, then
initialize I/O to wait for a new connection. This logic is
"backwards" and should be done transparently in the terminal
driver.
This problem is a 'discovered check` which happens with higher
speed machines. At one time, init was so slow in getting another
getty on-line that the modem had a chance to hang up. This is
no longer the case and is being worked on by one of the terminal
driver contributors as I write this.
It will eventually be fixed. I included the source-code of a
work-around in some previous communications, just in case others
have the same problem. Many will not because very few log-in
using a modem anymore.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about
it.
On Tue, 18 Mar 2003, Steve Lee wrote:
> Please excuse my lack of understanding. My dial-in box (using mgetty)
> is running on a dual Athlon 1900 MP system. Previous system was a dual
> P3 450. I've called into the Athlon system multiple times a day for
> almost a year now, the previous system, for several years. What issue
> should I be seeing? At times, I send some files home and when I get
> home I'll have to manually reset the modem (reset button), however,
> mgetty resets and is ready to answer again. I have mgetty configured to
> skip the first call, then answer with the modem if another call happens
> within 45 seconds.
>
> Steve
My modem is initialized upon boot using a program that writes
the correct initialization strings to it so it will answer on
the first ring as long as DTR is high. This is never changed
nor touched until the next boot. FYI the correct settings are
not set into the modem's NVRAM (using AT&W) because the NVRAM
will wear out and not retain any settings. I ran BBS systems
since CP/M days so I know how to set up a modem. The terminal
driver is set at a high-speed with hardware flow-control. The
speed is never changed either.
A terminal driver `agetty` is set up in /etc/inittab to handle
logins. The speed is set to the same high-speed as in above. The
getty is set to leave the driver speed alone (no auto-baud). You
can use mgetty agetty, etc. They all work the same. You just don't
use mingetty because it doesn't "do" modems.
I dial up from home (or duplicate it from my office so I can
see and measure what happends). The modem answers and synchronizes.
Once the getty's open() succeeds, it writes the contents of
/etc/issue out the modem and presents me with a login prompt.
I log-in. Fine. Wonderful. Great. It works! NOT! Now log out.
Do you have the "NO CARRIER" message from your modem? No. You
get the damn login prompt again because the terminal didn't
hang up. So, you type "+++", get your "Ok", and enter ATH. You
forced a hang-up. The modem, 66 miles away in your office, will
never answer again. It is now permanently off-line because
your getty is waiting for an open() which will never happen
because DTR went low on the forced disconnect and only something
that opens O_NONBLOCK will ever open the terminal to raise the
DTR so it will answer calls again.
You can configure your modem to ignore DTR. If you do, you will
invite every kid in the neighborhood to become root because you
can (read will) end up with a live shell connected to the modem.
It is necessary that, upon the final close, a terminal defined
to be a modem (not CLOCAL, with HUPCL enabled), lower DTR for
at least a few hundred milliseconds. It must then raise DTR
before the final close() returns to the caller. That way, when
the next instance of a getty gets control from init, its DTR
is enabled, waiting for another call. All these getties sleep
(block) in open().
The temporary work-around is to modify a getty so it opens
the modem non-blocking, hangs up (lowers DTR), then raises
DTR, then closes(). After that, it can sleep in a blocking-
open for the next caller.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
On Mon, Mar 17, 2003 at 8:19 AM, Richard B. Johnson wrote:
>
> If a modem is connected to /dev/ttyS0 and a getty (actually agetty)
> is associated with that device, one can log-in using that modem.
>
> This is how we've operated for many years. But, Linux version 2.4.20
> presents a new problem.
>
> When a logged-in caller logs out, it is mandatory for the modem
> to disconnect. This has previously been done automatically when
> the terminal is closed. The closing of the tasks file-descriptors
> will eventually call tty_hangup() and the modem would (previously)
> hang up.
>
> Something has changed so that the hang-up sequence doesn't happen if
> agetty has already opened the terminal for another possible
> connection.
> It used to be that the caller, calling close(), did not get control
> back until the modem had been hung up. This prevented another agetty
> from opening that terminal for I/O because the previous task had not
> completed its exit procedure until the terminal was hung up.
>
> Now, the hang-up sequence appears to be queued. It can (and does)
> happen after the previous terminal owner has expired and another
> owner has opened the device. This makes /dev/ttyS0 useless for remote
> log-ins.
>
> It needs to be, that a 'close()' of a terminal, configured as a modem,
> cannot return to the caller until after the DTR has been lowered, and
> preferably, after waiting a few hundred milliseconds. Without this,
> once logged in, the modem will never disconnect so a new caller
> can't log in.
>
> With faster machines, it is not sufficient to just lower DTR. One
> needs to lower DTR and then wait. This is because the next task
> can open that terminal in a few hundred microseconds, raising
> DTR again. This is not enough time for the modem to hang up because
> there is "glitch-filtering" on all modem-control leads. The hang-up
> event won't even be seen by the modem.
>
> So, either the modem control needs to be reverted to its previous
> functionality or `agetty` needs to hang up its terminal when it
> starts, which seems backwards. In other words, the user of kernel
> services should not have to compensate for a defect in the logic
> of that service.
>
> I have temporarily "fixed" this problem by modifying `agetty`.
> Can the kernel please be fixed instead?
>
Hi Richard,
The following patch to serial.c in 2.4.20 is a brute-force addition
of a hang-up delay of 0.5 sec just before close returns to the user,
if the hupcl flag is set. Please try this to determine if there are
any other issues with the remote login. If it works, I'll write a
better patch that does not duplicate other delays, etc.
Cheers,
Ed
diff -urN -X dontdiff.txt linux-2.4.20/drivers/char/serial.c
patched-2.4.20/drivers/char/serial.c
--- linux-2.4.20/drivers/char/serial.c Thu Nov 28 15:53:12 2002
+++ patched-2.4.20/drivers/char/serial.c Tue Mar 18 16:03:43 2003
@@ -2848,6 +2848,10 @@
tty->driver.flush_buffer(tty);
if (tty->ldisc.flush_buffer)
tty->ldisc.flush_buffer(tty);
+ if (tty->termios->c_cflag & HUPCL) {
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ/2); /* 0.5 sec to disconnect modem */
+ }
tty->closing = 0;
info->event = 0;
info->tty = 0;
On Wed, 19 Mar 2003, Ed Vance wrote:
[SNIPPED...]
> >
> Hi Richard,
>
> The following patch to serial.c in 2.4.20 is a brute-force addition
> of a hang-up delay of 0.5 sec just before close returns to the user,
> if the hupcl flag is set. Please try this to determine if there are
> any other issues with the remote login. If it works, I'll write a
> better patch that does not duplicate other delays, etc.
>
> Cheers,
> Ed
Okay. I will test this after about 4:00 PM when I can shut down
that machine. Thanks.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
On Wed, 19 Mar 2003, Ed Vance wrote:
[SNIPPED...]
> Hi Richard,
>
> The following patch to serial.c in 2.4.20 is a brute-force addition
> of a hang-up delay of 0.5 sec just before close returns to the user,
> if the hupcl flag is set. Please try this to determine if there are
> any other issues with the remote login. If it works, I'll write a
> better patch that does not duplicate other delays, etc.
>
> Cheers,
> Ed
>
Well, it's the "right church, but wrong pew". As soon as anything
closes STDIO_FILENO, **bang** the modem hangs up. NotGood(tm)!
So as long as I just execute the shell which was exec'ed ...
getty...rlogin...bash never called close. However, `ls` on my
machine is `color-ls` when it calls exit(0)... well you get
the idea! I can log in, but can't actually execute anything that
terminates, closing STDIO_FILENO...
> diff -urN -X dontdiff.txt linux-2.4.20/drivers/char/serial.c
> patched-2.4.20/drivers/char/serial.c
> --- linux-2.4.20/drivers/char/serial.c Thu Nov 28 15:53:12 2002
> +++ patched-2.4.20/drivers/char/serial.c Tue Mar 18 16:03:43 2003
> @@ -2848,6 +2848,10 @@
> tty->driver.flush_buffer(tty);
> if (tty->ldisc.flush_buffer)
> tty->ldisc.flush_buffer(tty);
> + if (tty->termios->c_cflag & HUPCL) {
> + set_current_state(TASK_INTERRUPTIBLE);
> + schedule_timeout(HZ/2); /* 0.5 sec to disconnect modem */
> + }
> tty->closing = 0;
> info->event = 0;
> info->tty = 0;
>
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
On Wed, Mar 19, 2003 2:32 PM, Richard B. Johnson wrote:
> On Wed, 19 Mar 2003, Ed Vance wrote:
> [SNIPPED...]
>
> > Hi Richard,
> >
> > The following patch to serial.c in 2.4.20 is a brute-force addition
> > of a hang-up delay of 0.5 sec just before close returns to the user,
> > if the hupcl flag is set. Please try this to determine if there are
> > any other issues with the remote login. If it works, I'll write a
> > better patch that does not duplicate other delays, etc.
> >
> > Cheers,
> > Ed
> >
>
> Well, it's the "right church, but wrong pew". As soon as anything
> closes STDIO_FILENO, **bang** the modem hangs up. NotGood(tm)!
> So as long as I just execute the shell which was exec'ed ...
> getty...rlogin...bash never called close. However, `ls` on my
> machine is `color-ls` when it calls exit(0)... well you get
> the idea! I can log in, but can't actually execute anything that
> terminates, closing STDIO_FILENO...
>
>
Hi Richard,
Bummer! Do you think that each of those events was a "last close"
of the port? Doesn't bash hold the port open while the `color-ls`
runs?
Since the path only delays (doesn't change modem control), these
closes must have been hidden by quick reopens. Does the unmodified
agetty set the baud rate to zero to hangup, or was that your change?
I was thinking that I could move the delay to the code that
disconnects when baud rate zero is set.
your thoughts?
Cheers,
Ed
----------------------------------------------------------------
Ed Vance edv (at) macrolink (dot) com
Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807
----------------------------------------------------------------
On Wed, 19 Mar 2003, Ed Vance wrote:
> On Wed, Mar 19, 2003 2:32 PM, Richard B. Johnson wrote:
> > On Wed, 19 Mar 2003, Ed Vance wrote:
> > [SNIPPED...]
> >
> > > Hi Richard,
> > >
> > > The following patch to serial.c in 2.4.20 is a brute-force addition
> > > of a hang-up delay of 0.5 sec just before close returns to the user,
> > > if the hupcl flag is set. Please try this to determine if there are
> > > any other issues with the remote login. If it works, I'll write a
> > > better patch that does not duplicate other delays, etc.
> > >
> > > Cheers,
> > > Ed
> > >
> >
> > Well, it's the "right church, but wrong pew". As soon as anything
> > closes STDIO_FILENO, **bang** the modem hangs up. NotGood(tm)!
> > So as long as I just execute the shell which was exec'ed ...
> > getty...rlogin...bash never called close. However, `ls` on my
> > machine is `color-ls` when it calls exit(0)... well you get
> > the idea! I can log in, but can't actually execute anything that
> > terminates, closing STDIO_FILENO...
> >
> >
> Hi Richard,
>
> Bummer! Do you think that each of those events was a "last close"
> of the port? Doesn't bash hold the port open while the `color-ls`
> runs?
>
> Since the path only delays (doesn't change modem control), these
> closes must have been hidden by quick reopens. Does the unmodified
> agetty set the baud rate to zero to hangup, or was that your change?
> I was thinking that I could move the delay to the code that
> disconnects when baud rate zero is set.
>
> your thoughts?
>
> Cheers,
> Ed
I'm pretty sure somebody had that port open all the while.
If you are looking for the 'last close' they may be a problem
with when it happens, i.e., the driver may not get closes in
"order".
I think the only "safe" thing is to delay returning from
the hangup caused by any reason (including baud-rate of zero).
Otherwise, some non-delayed path may do another open()
followed by a close() while you are sleeping in close().
That way, all previous logic that was destroyed by faster
CPUs, gets restored by simply slowing the rate at which
the DTR line can toggle.
As I have shown, I can "fix" the problem external to the
kernel, but it's "unclean". Any program should be be able
to, using tcsetattr() or its underlying ioctl(), be able
to set baud-rate to B0, then immediately to some rate and have
the modem-control lead (DTR) actually toggle. It doesn't
happen right now. Programs that I (we) write in the future
could of course usleep() between subsequent calls, but with
the fast fork() that we have now, one task hanging up
closing the terminal, followed by init starting another,
isn't slow enough to hang up the modem either.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
On Wed, 19 Mar 2003, Richard B. Johnson wrote:
> On Wed, 19 Mar 2003, Ed Vance wrote:
>
> > On Wed, Mar 19, 2003 2:32 PM, Richard B. Johnson wrote:
> > > On Wed, 19 Mar 2003, Ed Vance wrote:
> > > [SNIPPED...]
> > >
> > > > Hi Richard,
> > > >
> > > > The following patch to serial.c in 2.4.20 is a brute-force addition
> > > > of a hang-up delay of 0.5 sec just before close returns to the user,
> > > > if the hupcl flag is set. Please try this to determine if there are
> > > > any other issues with the remote login. If it works, I'll write a
> > > > better patch that does not duplicate other delays, etc.
> > > >
> > > > Cheers,
> > > > Ed
> > > >
> > >
> > > Well, it's the "right church, but wrong pew". As soon as anything
> > > closes STDIO_FILENO, **bang** the modem hangs up. NotGood(tm)!
> > > So as long as I just execute the shell which was exec'ed ...
> > > getty...rlogin...bash never called close. However, `ls` on my
> > > machine is `color-ls` when it calls exit(0)... well you get
> > > the idea! I can log in, but can't actually execute anything that
> > > terminates, closing STDIO_FILENO...
> > >
> > >
> > Hi Richard,
> >
> > Bummer! Do you think that each of those events was a "last close"
> > of the port? Doesn't bash hold the port open while the `color-ls`
> > runs?
> >
> > Since the path only delays (doesn't change modem control), these
> > closes must have been hidden by quick reopens. Does the unmodified
> > agetty set the baud rate to zero to hangup, or was that your change?
> > I was thinking that I could move the delay to the code that
> > disconnects when baud rate zero is set.
> >
> > your thoughts?
> >
> > Cheers,
> > Ed
[SNIPPED...]
This patch works (no other promises).
--- linux-2.4.20/drivers/char/serial.c.orig 2003-03-20 16:21:55.000000000 -0500
+++ linux-2.4.20/drivers/char/serial.c 2003-03-20 16:31:23.000000000 -0500
@@ -1538,8 +1538,12 @@
serial_out(info, UART_LCR, serial_inp(info, UART_LCR) & ~UART_LCR_SBC);
if (!info->tty || (info->tty->termios->c_cflag & HUPCL))
- info->MCR &= ~(UART_MCR_DTR|UART_MCR_RTS);
- serial_outp(info, UART_MCR, info->MCR);
+ {
+ serial_outp(info, UART_MCR,info->MCR & ~(UART_MCR_DTR|UART_MCR_RTS));
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ/2); /* Disconnect modem */
+ }
+ serial_outp(info, UART_MCR, info->MCR); /* Don't keep it off */
/* disable FIFO's */
serial_outp(info, UART_FCR, (UART_FCR_ENABLE_FIFO |
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
On Thu, Mar 20, 2003 at 2:14 PM, Richard B. Johnson wrote:
>
> [SNIPPED...]
>
> This patch works (no other promises).
>
> --- linux-2.4.20/drivers/char/serial.c.orig 2003-03-20
> 16:21:55.000000000 -0500
> +++ linux-2.4.20/drivers/char/serial.c 2003-03-20
> 16:31:23.000000000 -0500
> @@ -1538,8 +1538,12 @@
> serial_out(info, UART_LCR, serial_inp(info, UART_LCR) &
> ~UART_LCR_SBC);
>
> if (!info->tty || (info->tty->termios->c_cflag & HUPCL))
> - info->MCR &= ~(UART_MCR_DTR|UART_MCR_RTS);
> - serial_outp(info, UART_MCR, info->MCR);
> + {
> + serial_outp(info, UART_MCR,info->MCR &
> ~(UART_MCR_DTR|UART_MCR_RTS));
> + set_current_state(TASK_INTERRUPTIBLE);
> + schedule_timeout(HZ/2); /*
> Disconnect modem */
> + }
> + serial_outp(info, UART_MCR, info->MCR); /* Don't keep it off */
>
> /* disable FIFO's */
> serial_outp(info, UART_FCR, (UART_FCR_ENABLE_FIFO |
>
Hi Richard,
I'm not sure it's a Good Thing(tm) to call schedule_timeout() with
the interrupts disabled. The shutdown function is framed by
save_flags();cli and restore_flags(). Don't know exactly what the
downside of that could be.
Is the re-enable of DTR actually necessary to get agetty to work?
DTR is supposed to stay off until the next open.
Still, if it works for you, it works.
Cheers,
Ed
----------------------------------------------------------------
Ed Vance edv (at) macrolink (dot) com
Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807
----------------------------------------------------------------
On Thu, 20 Mar 2003, Ed Vance wrote:
> On Thu, Mar 20, 2003 at 2:14 PM, Richard B. Johnson wrote:
> >
> > [SNIPPED...]
> >
> > This patch works (no other promises).
> >
> > --- linux-2.4.20/drivers/char/serial.c.orig 2003-03-20
> > 16:21:55.000000000 -0500
> > +++ linux-2.4.20/drivers/char/serial.c 2003-03-20
> > 16:31:23.000000000 -0500
> > @@ -1538,8 +1538,12 @@
> > serial_out(info, UART_LCR, serial_inp(info, UART_LCR) &
> > ~UART_LCR_SBC);
> >
> > if (!info->tty || (info->tty->termios->c_cflag & HUPCL))
> > - info->MCR &= ~(UART_MCR_DTR|UART_MCR_RTS);
> > - serial_outp(info, UART_MCR, info->MCR);
> > + {
> > + serial_outp(info, UART_MCR,info->MCR &
> > ~(UART_MCR_DTR|UART_MCR_RTS));
> > + set_current_state(TASK_INTERRUPTIBLE);
> > + schedule_timeout(HZ/2); /*
> > Disconnect modem */
> > + }
> > + serial_outp(info, UART_MCR, info->MCR); /* Don't keep it off */
> >
> > /* disable FIFO's */
> > serial_outp(info, UART_FCR, (UART_FCR_ENABLE_FIFO |
> >
> Hi Richard,
>
> I'm not sure it's a Good Thing(tm) to call schedule_timeout() with
> the interrupts disabled. The shutdown function is framed by
> save_flags();cli and restore_flags(). Don't know exactly what the
> downside of that could be.
>
> Is the re-enable of DTR actually necessary to get agetty to work?
> DTR is supposed to stay off until the next open.
>
> Still, if it works for you, it works.
>
> Cheers,
> Ed
Yes. DTR must be high or the modem will never answer an incoming call.
The `getty` waits in a blocking open until the carrier is detected.
The carrier will never be detected if DTR is low. After the hangup
occurs, you need to restore the modem settings.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
Hi Folks: I was wondering if anyone knew of any driver support for
the system monitoring functions of the Winbond w83697hf or any of that
family of support chips.
I have done searches on google and through the 2.4.20 source code but
can only find reference to the chip as an identifier in the parport_pc.c
file. Google finds nothing accept as a component on many mother
boards.
Any pointers would be appreciated.
Kirk
--
Kirk Reiser The Computer Braille Facility
e-mail: [email protected] University of Western Ontario
phone: (519) 661-3061
"Richard B. Johnson" <[email protected]> writes:
> The problem is when you log out! With a terminal connected,
> you get the login prompt again. This is no good if you are
> connected to a modem.
How would that happen? Even assuming the modem doesn't see DTR line
being lowered (for a short time - say, too short) while closing the
device, getty should initialize the modem correctly, i.e. lowering DTR
first for ~1 s.
> The modem will not be disconnected
> and you have to forcably disconnect at the remote end by
> disconnecting the phone line or lowering DTR with your remote
> terminal program. Then the modem will not be ready to
> answer another call. It will remain in a off-line condition
> forever.
Why? Does your modem report on/off-line status using DCD (carrier detect)
line correctly?
The shell should get HUP/disconnect after DCD drops.
BTW: there is (and always was) another issue, security-related.
Normally the user can issue "stty clocal" command which disables DCD
level detection. Thus, the /dev/ttyS* device will be owned by the user
((s)he will have an open file descriptor to the device) after the line
is disconnected. The shell will not be terminated and no getty will be
spawn.
It allows making a script simulating getty/login and ie. collecting
passwords/sessions etc.
This isn't a kernel issue - the kernel has "LOCK TERMIOS" ioctl in place,
and it's probably enough to stop this attack. The problem is no getty
uses that ioctl (it might have changed from the last time I checked,
though - but I would rather check it again if I had untrusted users).
--
Krzysztof Halasa
Network Administrator