Add an Identity Daemon to Mushclient.

Title says it all.

Many MUDs and server types (SMAUG being one) send out Identd requests but very few clients actually supprt Identd's which means the players either have to run a 3rd party program to listen and respond to port 113, or no response is ever sent.

A simple panel in the configuration menu, similar to the one where proxies are listed would be sufficient.

Instead of proxy type, server, and port it would just be OS (from a pull down list of the few supported by the standard in rfc 1430 if i recall), text to respond with, and port to listen in on, with an additional checkbox for enabled or not.

I've seen sufficient debate on whether this protcol is obsolete, a security risk, blah blah, so please no responses a long those lines to this suggestion from anyone other than Nick.

References:
http://www.faqs.org/rfcs/rfc931.html
http://www.faqs.org/rfcs/rfc1413.html

OK, I suppose it would be easy enough to do, but can you explain why? I have heard about identd for about 10 years, and have not really seen an explanation for what it does, or why you need it on a MUD.

I assume the response can be forged (eg. you would configure MUSHclient to respond however it wants) so what does the MUD really learn about you?

Valid question, and easy to answer.

The main reason for it, is to provide proof that Person A) and person B) are on separate computers, even though they have the same network address.

While both can make it say anything they want, they cannot both respond at the same time with two different answers.

MUDs that restrict multiplay make use of IdentD to verify that player (A) and (B) really are two different people/machines.

Even the best IdentD daemons i've seen can not outwit that simple test, and I've seen several attempts to try.

(It can't be done by sending different answers based on port, because the MUD only uses 1 port to make the request, and it can't be done by sending a different answer based on host becuase the MUD only has 1 host, and that only leaves alternating names, which is pretty easily spotted if every time the MUD requests the names start swapping).

At this time we require players to download and install a small IdentD daemon if they intend to multiplay via network to prove they're separate people (its a tiny 20k program so its not exactly a massive hassle) but it occurred to me that MushClient could do it itself (mIRC does), so I thought it worth suggesting since it would be another useful feature from a players persective when dealing with LANs and multiplay restricted MUDs.

Did all that make sense or did I slip into babble somewhere?

Hmmm - the same IP address but different computers, are you talking NAT here?

I don't quite see how this will work. Say you have PC A and PC B and they both have the same IP address (ie. they are behind a router) then how can they both be serving incoming identd requests, whether by MUSHclient or a standalone daemon?

It has to do with the descriptor.

The actual connection by which each computer is sending/recieving information to the MUD is the same one used to send the IdentD request, so that each request goes only to the origininating computer.

Routers/network cards know which computer is in charge of each inbound/outbound connection, so its a fairly straightforward path that always gets where its going if their legitimately are two or more computers and both are listening.

Each computer has its own port 113, so routers recieving a request on port 113 just forward that request to whichever computer is the one actually be polled.

Have you tried this with your standalone daemon?

I understand how routers and NAT work, however in most cases a MUD client makes an outbound connection to a MUD, and the router tracks that connection by reassigning a different port number to it, so it can tell when responses come back in - to the MUD.

eg.

PC A --> port 4000 --> router --> port 32000 --> MUD
PC B --> port 4000 --> router --> port 32001 --> MUD

MUD --> port 32000 --> router --> port 4000 --> PC A
MUD --> port 32001 --> router --> port 4000 --> PC B

However a request from the MUD to a *different* port (eg. 113) is not going to go to PC A automatically - how does it know not to send it to PC B instead?

Or are you saying the identd runs on the router? In that case, adding it into MUSHclient won't help - it will be on the wrong PC.

How does the router know which PC that is? If they are all running a MUD session?

>Have you tried this with your standalone daemon?

Yes. My mother and my aunt both used to play from different rooms of the house with separate identd daemons running and it always identified them correctly, likewise when we would be on various IRC servers mIRC's daemon always identified each computer correctly individually.

I don't know the exact specifics of how it works, just that it does, and is about the only way to track that sort of thing.

>How does the router know which PC that is? If they are all running a MUD session?

The same way the router knows which computer to send information to.

If the router couldn't tell one computers input/output from the other it wouldn't be much use. Signals sent to Character A travel to computer A, signals sent to character B travel to character b, and vice versa.

The descriptors act as a permanent channel leading to the computer that originated them. The identd request is sent back a long that channel so it always goes back to the right place. Since the response is also sent back a long the descriptor, it too always goes back to the right character.

If the router didn't know how to tell who spawned which descriptor etc, mudding over a network would be impossible because only one person would recieve all the input/output or both of them would recieve everyones.

I understand that bit, but the descriptor established by the MUD is different from a separate call from the MUD to an ident daemon.

Anyway, it seems you already have a solution that works. I am a bit reluctant to start adding things to MUSHclient that already exist in an easy-to-use format. For instance, some people wanted it to support MUD-ftp, when you can use your own ftp client. Others wanted it to have support for SSH connections. I worked out a way of doing that by using a stand-alone SSH program.

What happens if I start adding all these things is that it eventually gets to be "bloat ware".

That chat system, which I recently did, was different, because the client needed to listen to chat sessions, and integrate them into the world window, so it was hard to do that as a separate program.

However I lean towards the Unix way of doing things - have a lot of specialised programs, and tie them together, rather than one huge program that tries to do everything.

In my experience using mIRC, if you are behind a router/firewall, the identd does not work. The router receives a request for an identd port, and unless it knows to forward all identd to one computer, it'll take the "call" itself, and produce incorrect results.

The only time that a router will forward automatically is if the connection was established by a computer inside the network, e.g. a computer behind the router. That is why, for example, I can connect to port 5432 on my MUD - but nobody can connect to port 5432 on my router because there is no port forwarding set up. Then again, my router is also a firewall, which could be blocking things.

Still, I don't really see how you can guarantee that two people are different.

How can the same descriptor be used? Does that mean that you have a program listening on your TCP/IP connection? As far as I understood, the identd request is sent to port 113, which means that it cannot use the same descriptor.



This is not accurate. The difference is that the characters already have established connections - so the router knows where to forward the requests (see Nick's discussion on ports, how it changes the ports so it knows which computer to send it to.) But if it receives a NEW connection - e.g. on the telnet, ftp, identd ports - it won't know what to do with it and will likely throw it away.



I'm not sure how this helps you. Does this mean that both people will have the same answer? How does this uniquely identify both computers?

I would pretty much agree with Nick here; since you seem to have a working solution, and this problem seems to be fairly rare, it probably isn't worth the slowdown to add it into MUSHc. The reason I chose MUSHc over zMud is, among other things, the fact that it's so much faster, without loss of core functionality. OK, I don't have a GUI automapper, but I can live with that. It doesn't really work too well anyways on zMud... :P

You misunderstood the context of this quote:

"While both can make it say anything they want, they cannot both respond at the same time with two different answers."

That's if both users are on the same computer. The same computer can not respond with two different answers. Two different computers can, even through firewalls and routers in many circumstances.

I see what you meant now... but could the same computer's daemon start the server with name "Fred", respond to the MUD's request and tell it Fred, and then shut down the daemon, start it again, set it as "Joe", make a new MUD connection and respond to that one as Joe... and then you have two connections, one of which is from Fred and the other from Joe? I don't believe that the identd request is repeated, so I believe that sort of solution would allow you to fool the server into believing you're running on two computers from the same IP address (i.e. behind a router.)

The other problem I see here is that one person could always have two computers and run on both of them, and you'd never know the difference, unless you snooped and figured it out... I guess that there is no way to prevent multiplaying completely. Oh well...

If he can play on two computers, I say he deserves to multiplay :P

Yeah, Ksilyan. That is one issue I wondered about. All someone would need to do to spoof this is write their own daemon that mimics the existing one, then have it reply with a different ID depending on which connection it was responding to. If the connection to the daemon is temporary or permanent until log off, it can still be faked, since you can have multiple connections on the same port at one time. Unless you could do something like they do for 802.11b networks and lock the connection to a unique MAC address, it would be quite easy to fake such an ID, all you need to do it capture the packets, then code a 100 line application to generate the same type of reply, unless they are doing something far more complex.