Top Mud Sites Forum Return to TopMudSites.com
Go Back   Top Mud Sites Forum > Mud Development and Administration > MUD Coding
Click here to Register

Reply
 
Thread Tools
Old 08-09-2005, 04:32 PM   #1
Khadgar
New Member
 
Join Date: Mar 2003
Posts: 29
Khadgar is on a distinguished road
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 is offline   Reply With Quote
Old 08-09-2005, 11:42 PM   #2
Khadgar
New Member
 
Join Date: Mar 2003
Posts: 29
Khadgar is on a distinguished road
I managed to get a hold of the Zugg and he had the following to say about the issue:
Quote:
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.
Khadgar is offline   Reply With Quote
Old 08-10-2005, 02:06 AM   #3
eiz
New Member
 
Join Date: Feb 2005
Posts: 25
eiz is on a distinguished road
I believe zMUD supports the TERMINAL-TYPE option, which will allow you to distinguish it.
eiz is offline   Reply With Quote
Old 08-11-2005, 08:22 PM   #4
shadowfyr
Senior Member
 
Join Date: Oct 2002
Posts: 310
shadowfyr will become famous soon enough
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.
shadowfyr is offline   Reply With Quote
Old 01-06-2006, 06:35 AM   #5
Khadgar
New Member
 
Join Date: Mar 2003
Posts: 29
Khadgar is on a distinguished road
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:
Quote:
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 is offline   Reply With Quote
Old 01-07-2006, 01:52 AM   #6
Khadgar
New Member
 
Join Date: Mar 2003
Posts: 29
Khadgar is on a distinguished road
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
Khadgar is offline   Reply With Quote
Old 01-09-2006, 10:02 AM   #7
Kastagaar
Member
 
Join Date: Apr 2002
Location: Hampshire, UK
Posts: 117
Kastagaar is on a distinguished road
Send a message via Yahoo to Kastagaar
Quote:
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:
Quote:
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.
Kastagaar is offline   Reply With Quote
Reply


Thread Tools


Telnet Negotiations - Similar Threads
Thread Thread Starter Forum Replies Last Post
Why not exploit the telnet protocol? erdos Advanced MUD Concepts 53 05-16-2012 01:00 AM
Java Telnet Applet Crystal MUD and RPG Webmasters 3 03-19-2008 09:42 AM
Beyond Telnet Rathik Advanced MUD Concepts 52 09-01-2006 02:21 AM
Telnet Options? Raewyn MUD Coding 1 02-05-2006 10:58 AM
Cant type in telnet window! Chobbie Newbie Help 2 07-17-2002 03:38 PM

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

All times are GMT -4. The time now is 10:37 PM.


Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Style based on a design by Essilor
Copyright Top Mud Sites.com 2014