[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: linux bash stty bug

From: Bob Proulx
Subject: Re: linux bash stty bug
Date: Fri, 1 Mar 2002 21:50:29 -0700

>    Probles description:
>       I tried to send data from Linux /dev/ttyS0 to a SCO unix serial
> port.   The two serial ports are connected with a NULL MODEM.
> If XON/XOFF flow control is used, I set the linux /dev/ttyS0 with:
>       ( stty 9600 ixon ixoff -crtscts cs8 ;
>          while : ; do sleep 3600 ; done ) < /dev/ttyS0 &
> and set the SCO serial port same way. Now I can send data by
>        echo "some data" > /dev/ttyS0
> There is no trouble at all.

Very clever!  However you are not able to send arbitrary binary data
in this way.  If that data itself contained XOFF characters you would
find the connection hung.  You would need to escape the control
characters in the data stream.  This is known as "inband control".
The control is sent in the same channel as the data.

> But if I use Hardware flow control, the case is different.

Hardware flow control uses hardware handshake lines and is "out of
band control".  The data no longer needs to be escaped.  FTP as one
notable example uses out of band control by keeping separate data and
control streams.

>     First I set up the linux terminal as:
>       ( stty 9600 crtscts -ixon -ixoff -ixany ;
>          while : ; do sleep 3600 ; done ) < /dev/ttyS0 &
> The SCO serial port is set as Hardware flow control same way.
> If I use :
>         echo "some data" > /dev/ttyS0
> It will send nothing and the command never return.
> Later I wrote a c program to send the data.  The C code works only if
> the port is opened as:
>      int fd = open("/dev/ttyS0", O_RDWR | O_NONBLOCK );
> If the O_NONBLOCK micro is not there, the c code does not send
> any data either.

80% of the problems with serial port connections are people using a
cable that does not include the hardware handshake lines.  19% of the
remaining problems are due to Carrier Detect (CD) being expected from
something that is not a modem and does not generate CD or using a
cable that not route CD.  0.9% of the remaining problems are incorrect
setup of the serial port driver.  The remaining .1% are software
bugs.  And most of those are in the application code.

>     I am not sure where is the bug: in the tty driver, in the shell, or need 
> another flag in the stty command ?

I am betting your tty is configured to wait for CD and since none is
present it waits forever.  By opening in non-blocking I/O mode you are
avoiding the hardware handshake entirely and effectively have no flow
control.  Which is why that is working for you.  The 'setserial'
command is probably going to be useful to you.

Read the Linux HOWTOS on the serial port for more information.
Start here:


I would also check out the sources to other terminal programs and see
how they handle 'direct' serial connections.  Programs like Seyon,
Minicom, Kermit, the names are endless. are good places to start.

None of this applies to the sh-utils package.  I would look for
further help in the news group comp.unix.misc.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]