From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description of problem: Using hyperterm to connect to Linux box with 56K internal modem & mgetty configured for ttyS4, abruptly disconnect the connection in the middle of a task (ala cat a file or ls a directory) without logging out completely. The mgetty dies (no longer shows up on ps) but the ttyS4 lock file remains. The mgetty will never respawn, however, and subsequent attempts to dial into the box will never be answered. Version-Release number of selected component (if applicable): How reproducible: Always / Sometimes Steps to Reproduce: 1.spawn mgetty for internal modem 2.dial into box using hyperterm or other equivalent 3.run "cat" on a file or "ls" in a directory 4.abruptly disconnect the connection without logging out 5.redial box, phone line rings, no answer by mgetty 6.run ps on box, see that mgetty has not been respawned 7.check /var/lock dir & see that ttyS4 lock file is still present Actual Results: modem placed into state where mgetty is never respawned and will not answer line (even if lock file is removed). Expected Results: modem cd loss would disable mgetty, cause lock file to be removed, and mgetty respawned & answer subsequent calls to box when ringing. Additional info: One factor may involve phone line quality or modem / RS-232 signal detection re CD + DTR? This problem has not been duplicated using a Black Box phone simulator but very easily using other combinations of modems & phone lines.
mgetty.log entries state that the release is an "Experimental Version"
Unable to duplicate but leaving open since conditions often play a critical part in such things
Closing out old bugs here. I'm unable to duplicate this bug. If anyone can duplicate it with current mgetty versions, please let me know how.
I experienced this bug too when using a cheap dual-RS232 card. I've changed to a USB-RS232 adapter and now _this_ problem has gone away. Now I'm stuck with Bug #167830. Using vanilla FC5 system.