[Khadgar]

I just got back into coding my mud this month after a long semester of college - took 21 credits.. will never do that again..

Nevertheless.. I have been implementing telnet negotiations such as the echo option.  My ultimate goal was to have asterisks "*" in place of user passwords to resolve the security risk of somebody overseeing it.  After sending IAC DO ECHO to the client, i receive IAC WILL ECHO.  For every character received while the client is in the ENTER_PASS state, I send an asterisk to the client.  For telnet, this works great - it does exactly what I want it to..

However, for clients such as ZMud, a player can enter input it two places.. directly on the console screen like telnet.. or in the input box at the bottom of the screen. This input box is giving me issues.. It writes whatever the user types to the console screen.. and then echos it to the server.. the server thinks it should echo the characters the user types because the client sent IAC WILL ECHO.. Thus, the client will see ouput on the console screen such as:

Username: testuser
Password: testpass
********

Does anybody know how to resolve this issue?  Any help will be greatly appreciated.  Thanks in advance!

- Khadgar

[Khadgar]

I managed to get a hold of the Zugg and he had the following to say about the issue:

Originally Posted by That is correct.  The ECHO option is ignored by the command line.  There is no way around this that I'm aware of.  The way zMUD itself handles this is that any line containing the password (as entered in the Edit page on the character selection screen) is gagged from the main zMUD window.  So normally, if you Edit your character icon and go to the Character tab and enter your username and password there, then you'll never see your password echoed no matter what.  This is why zMUD tries to handle login automatically to prevent stuff like this from getting displayed. Zugg

Thus, it appears to be a client issue.  However, I would still like to find a way around it.  Is there a way to identify the type of client that is connecting to the server? For example, telnet or zMUD could be uniquely identified.  If that is possible, then perhaps I could code where the asterisks would not even be sent with zMUD since more people use the command line input box at the bottom moreso than the console window itself.

[eiz]

I believe zMUD supports the TERMINAL-TYPE option, which will allow you to distinguish it.

[shadowfyr]

Mushclient also correctly identifies it and several glitches that existed in negotions have been corrected in recent versions. There is even an option you can turn on to convert certain codes, which some muds use to indicate a prompt, into a "newline+charage return" as they arrive, so the client actually sees a prompt. Other clients get around this I believe by keeping the current 'state' of the input and matching on partial lines, which haven't terminated. I'm not sure if I agree with the reasoning of that allowing this, except that you can't do:

Match="You see a red bunny", sequence=1
Match="You see a *", sequence=2

And avoid having the second one match on a partial line, even when it should only match the first one. While there are obviously solutions to this, Nick chose to simply only deal with lines that end with /n/r.

Anyway, sorry for the side track, but I think most clients do respond to the client ID sequence, but I might be wrong.

[Khadgar]

I finally got a little break again before next semester

I have a quick dumb question concerning the NAWS protocol.

The following quote is from the NAWS RFC:

Originally Posted by As required by the Telnet protocol, any occurrence of 255 in the subnegotiation must be doubled to distinguish it from the IAC character (which has a value of 255).

IAC SB NAWS <16-bit value> <16-bit value> IAC SE

What if one of the 16 bit values is 255? Should I expect another occurance of 255?  Thanks in advance.

[Khadgar]

Whenever I use the NAWS protocol, I noticed localecho on telnet does not seem to work anymore.  Would there be a reason for this?

I know I can use the ECHO protocol and send any input I receive back to the client as output.  However, always doing this seems like unnecessary processing on the server side.

Thanks again!

- Khadgar

[Kastagaar]

Originally Posted by (Khadgar @ Jan. 06 2006,12:35) I finally got a little break again before next semester I have a quick dumb question concerning the NAWS protocol. The following quote is from the NAWS RFC: Originally Posted by As required by the Telnet protocol, any occurrence of 255 in the subnegotiation must be doubled to distinguish it from the IAC character (which has a value of 255). IAC SB NAWS <16-bit value> <16-bit value> IAC SE What if one of the 16 bit values is 255? Should I expect another occurance of 255?  Thanks in advance.

All occurrences of 255 should be doubled when sent, to differentiate them from IAC. Hence, any incoming IAC IAC should be interpreted as a 255.

Thus, if you were receiving a NAWS subnegotiation which reported a width and height of 255, 256, then you would receive:

IAC SB NAWS 0 255 255 1 0 IAC SE

Note the double-255.