Does anyone know why the password is shown, and how to get it to not echo wh the user types it in?
Re: openbsd telnet to serial
By: bbsing to All on Mon Nov 24 2025 09:36 pm
Does anyone know why the password is shown, and how to get it to not echo wh the user types it in?
Have you tried using a raw connection into it instead of telnet? Try this for science.. make sure you have netcat (nc)
installed.
Create a file called raw.sh with this in it:
settings=$(stty -g)
stty raw -echo
nc $1 $2
stty $settings
then 'chmod +x raw.sh' and then './raw.sh ipaddress port'. Just one thing to note, when you finally disconnect, you need to hit
a
key to return to your prompt.
The reason for this is telnet does some negotiation on connect, and you're not running telnetd. Your client says "Hey, let's
agree
on some stuff!" but your server isn't listening for that.
Re: openbsd telnet to serial
By: phigan to bbsing on Wed Nov 26 2025 05:43:54
Re: openbsd telnet to serial
Have you tried using a raw connection into it instead of telnet? Try this for science.. make sure you have netcat (nc)
installed.
Create a file called raw.sh with this in it:
settings=$(stty -g)
stty raw -echo
nc $1 $2
stty $settings
then 'chmod +x raw.sh' and then './raw.sh ipaddress port'. Just one thing to note, when you finally disconnect, you need to
hit
a
key to return to your prompt.
The reason for this is telnet does some negotiation on connect, and you're not running telnetd. Your client says "Hey, let's
agree
on some stuff!" but your server isn't listening for that.
So somehow I have to get my modem to use telnetd as the program instead of going to getty, then when a client telnet's to my system the password will n
Exactly. That's what I was trying to say in the earlier message. When you use a telnet client connecting into getty, the client can't do its expected negotiation. Same if you do the opposite, connect raw into a telnetd.
I don't see any way to tell telnetd to only use the serial port. I think telnetd likes psuedo ttys .
terminal, or the terminal emulation software, from "half duplex" or "local echo" to "full duplex."
Well no, you'd tell the software using telnetd to use the serial port instead.
terminal, or the terminal emulation software, from "half duplex" or "local echo" to "full duplex."
The half/full duplex thing is unrelated. Yes, you can set "half duplex", meaning the other end won't send stuff back to you so
you
need your local terminal to "echo" the characters you type for you. Or "full duplex" where the stuff you send out gets sent
back,
so you don't need your terminal to do it. Most (if not all, now) connections you make will be full duplex, so if you have your
terminal set at "half" (aka "local echo on"), you will see double characters... the ones echoed locally by your terminal as well
as
the ones sent back from the other side. When typing your password, the other side doesn't send back characters, but you will
still
see the locally echoed characters if you are in half duplex.
So, very similar problem with the telnet vs raw connection mismatch, but in this case you are not setting the duplex with your
terminal program. It is being auto-negotiated (or attempting to be) by 'telnet' on one side or the other.
If you are connecting to a telnetd, you should use a telnet client. If you are connecting to getty or something else answering
the
connection and just passing it along to 'login' or what-have-you, you should make a raw connection (like with netcat or a BBSing
terminal program).
Thank you for this information. In a world that is perdominantly full duplex. In the old days using modems often times the local echo wasn't on, and I couldn't see what I typed with out setting echo to on. A telnet connection via client must be full duplex, without a way to change that.
| Sysop: | MarisaG |
|---|---|
| Location: | South San Francisco, CA |
| Users: | 6 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 118:45:44 |
| Calls: | 180 |
| Files: | 36 |
| Messages: | 32,283 |