Project

General

Profile

Actions

Bug #2274

closed

C12 problem on leaf.dragonflybsd.org

Added by robin.carey1 almost 13 years ago. Updated over 12 years ago.

Status:
Rejected
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Dear DragonFlyBSD bugs,

I reported this problem just recently, and then mistakenly believed an O/S
upgrade on
leaf.dragonflybsd.org had solved the problem. Unfortunately, that was not
the case (I
had changed the code during testing/debugging and had forgot that I had
changed
the code, which led to me believing the problem had been solved).

The problem is with C12 (C12G22r2) operation on leaf.dragonflybsd.org; the
source
code can be downloaded from:

http://www.leopard.uk.com/C12

The problem manifests as a termios(4)/Terminal problem, e.g.

Local echo is not switched off (there are probably other problems
aswell).

Since C12G22r2 works fine on OpenBSD-4.7/i386 and
FreeBSD-9.0/i386, I conclude the problem is with
DragonFlyBSD.

--
Sincerely,

Robin Carey BSc

Actions #1

Updated by alexh over 12 years ago

Would be nice if you could narrow it down to a particular call, etc not working as expected.

Cheers,
Alex

Actions #2

Updated by robin.carey1 over 12 years ago

Dear Alex & DFlyBSD-bugs,

With regard to Issue-2274:

It would appear C12 works OK on leaf.dragonflybsd.org, except Local-Echo is
switched on all the time (when it should be switched off).

In the C12 source-code, Local-Echo is switched off during the method:

Terminal::RawInput() -- in the file Terminal.h

The Terminal::RawInput() method is only called in:

Terminal::GetNextInputChar() -- in the file Terminal.h

The Terminal::GetNextInputChar method is only called from 2 places:

Key.h ; class Key ; method Key::WriteKey()

and

Passwd.h ; class Passwd ; method Passwd::Password().

As I said before, C12G22r2 works fine on both FreeBSD-9.0/i386 and
OpenBSD-4.7/i386.

Also, as I said before the C12 source-code can be downloaded from:

http://www.leopard.uk.com/C12

There might be more problems than the one outlined above ....

If there are any other problems, it would probably make sense to resolve
this problem, before finding out if there are any others.

On 24 February 2012 20:41, Alex Hornung via Redmine <
> wrote:

Issue #2274 has been updated by Alex Hornung.

Would be nice if you could narrow it down to a particular call, etc not
working as expected.

Cheers,
Alex
----------------------------------------
Bug #2274: C12 problem on leaf.dragonflybsd.org
http://bugs.dragonflybsd.org/issues/2274

Author: Robin Carey
Status: New
Priority: Normal
Assignee:
Category:
Target version:

Dear DragonFlyBSD bugs,

I reported this problem just recently, and then mistakenly believed an O/S
upgrade on
leaf.dragonflybsd.org had solved the problem. Unfortunately, that was not
the case (I
had changed the code during testing/debugging and had forgot that I had
changed
the code, which led to me believing the problem had been solved).

The problem is with C12 (C12G22r2) operation on leaf.dragonflybsd.org; the
source
code can be downloaded from:

http://www.leopard.uk.com/C12

The problem manifests as a termios(4)/Terminal problem, e.g.

Local echo is not switched off (there are probably other problems
aswell).

Since C12G22r2 works fine on OpenBSD-4.7/i386 and
FreeBSD-9.0/i386, I conclude the problem is with
DragonFlyBSD.

--
Sincerely,

Robin Carey BSc

--
You have received this notification because you have either subscribed to
it, or are involved in it.
To change your notification preferences, please click here:
http://bugs.dragonflybsd.org/my/account

--
Sincerely,

Robin Carey BSc

Actions #3

Updated by alexh over 12 years ago

  • Priority changed from Normal to Low

I've added some very simple "instrumentation", printing a dot "." when it calls tcsetattr to disable local echo, and a dash "-" when it restores the local echo. The outcome is:

Encrypt public-key (y/n) ? .-.-.-.-.-y.-
Choose password: /root/caesarion/public-key: .-.-y.-.-.-y.-.-y.-.-y.-.-y.-.-y.-.-y.-.-y.-.-y.-.-y.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-n.-.-.-m.-.-o.-.-o.-.-.-o.-.-o.-.-o.-.-.-.-.-.-.-.-.-.-.-.

As you can see, this looks more like a problem with the code. It keeps toggling between one and the other, and every time you press a button, it restores the old settings first, before taking the input, it seems.

Disabling local echo itself definitely works just fine, because it's used in e.g. tcplay.

In any case I'll look a bit further into this.

Cheers,
Alex

Actions #4

Updated by alexh over 12 years ago

  • Status changed from New to Rejected

It's quite surprising that it works anywhere, I think. You are enabling local echo while the character is buffered (i.e. select has returned what you wanted), then disabling it again before it's read. It doesn't strike me as a good idea that should work anywhere.

Changing your GetNextInputChar as follows (note that #if 0), makes it work just fine and is in line with good UNIX programming:

int                 GetNextInputChar (void) const {
int retVal;

#if 1
RawInput();

do {
fd_set readfs;
FD_ZERO(&readfs);
FD_SET (fileno(stdin), &readfs);
struct timeval timeout = { 2, 0 };

#if 0
RawInput (); // A ^Z can reset the terminal/termios(4)
// setting, so we set it to the desired
// configuration just before any I/O
// operating (including select(2)).
//
#endif
retVal = select ((fileno(stdin) + 1), &readfs, NULL, NULL, &timeout);
#if 0
Restore (); // Restore termios(4) ASAP after RawInput().
#endif
ASSERT (retVal != -1);
} while (retVal <= 0);
#endif

#if 0
RawInput (); // A ^Z can reset the terminal/termios(4)
// setting, so we set it to the desired
// configuration just before any I/O
// operating (including select(2)).
//
#endif
const int key = fgetc (stdin);
Restore (); // Restore termios(4) ASAP after RawInput().
ASSERT (!ferror (stdin));
ASSERT (!feof (stdin));

return key;
}

Actions #5

Updated by alexh over 12 years ago

Forgot to mention it in my last message:
using the TIOCSETA ioctl on a pty device (i.e. tcsetattr) causes a flush. This happens on most BSDs, and there is no guarantee that I'm aware of that it shouldn't happen. If you rely on it not happening, you are relying on undefined behaviour.

Cheers,
Alex

Actions

Also available in: Atom PDF