Subject: Re: blocking tcsetattr in pppd 2.4.0
To: None <netbsd-users@netbsd.org>
From: Christos Zoulas <christos@zoulas.com>
List: netbsd-users
Date: 05/31/2004 21:04:44
In article <03e701c446f3$e34d7cc0$4a22a8c0@intervid.co.za>,
Brad du Plessis <bradd@cat.co.za> wrote:
>Hi all,
>
>I've had an issue from time to time with pppd 2.4.0. Unfortunately the
>problem is not easily repeatable but it will occur on occasion when I try
>and kill a pppd listening process. Having sent the kill signal (SIGTERM),
>the process fails to exit. I put printouts in the pppd code to figure out
>where exactly the problem lies and it appears that having received the kill
>signal and doing all the tty cleanup before exit, pppd fails to return from
>the restore_tty() function called from finish_tty() in tty.c . Looking at
>restore_tty() in sys-bsd.c, I assume the problems lies with the line:
>
>tcsetattr(fd, TCSAFLUSH, &inittermios)
>
>My thoughts are that before applying the attributes set in the structure
>inittermios, tcsetattr attempts to flush all data written to descriptor fd
>to the terminal and for some reason it is unable to do this.
>
>Does this indicate a problem with the modem or serial port?
>
>The attribute change turns off echoing to avoid a loop between tty and the
>modem, is this line essential, why would echoing be enabled in the first
>place?
>
>What effect would changing the TCSAFLUSH flag to TCSANOW have?
>
>Any ideas why TCSAFLUSH was used instead of TCSANOW?
>
>If TCSANOW was used and the attributes were successfully changed, would I
>then see a problem when a close is called for this descriptor if the close
>tries a flush of some sort?
>
>Any help would be much appreciated.

I have no idea why flush was chosen instead of now. But try your change
and if it works for you, please send-pr.

christos