Okay I have noresolve on (so DNS names are used instead of IPs) but what would cause the MUD to still show an IP over a DNS name? This player somehow had one character on with his IP and another with his DNS thus multiplaying without our multiplay alarm going off. (Since it was strcmp the IP and DNS and not matching) It seems like the player forced the MUD to resolve it to an IP.
Here's what happened: (IPs & names changed from original)
Quote: Comm: Alt@pcp02934895pcs.planfd01.in.comcast.net has connected.
Comm: Main@203.240.225.27 has connected.
203.240.225.27 is an IP in South Korea. pcp02934895pcs.planfd01.in.comcast.net does not resolve to anything. Repeated attempts show it as a host not found. So it's not possible, at least from where I sit, to tie the 2 together.
Er, as I said the IPs and DNS names were changed. When "Comm: Sock.sinaddr: <IP>, port 1809." came up, both those characters logged on from as we compare the port to the users list when signed on.
if Sock.sinaddr can read both the IP, couldn't there be a way to tie your alarm into it somehow?
On another note, maybe you could add in somewhere that someone logging via IP will get a refused connection, though I'm not sure what all kinda of problems that could cause besides maybe restricting new players.
I think he changed the code to read DNS instead of IPs because of the apparently large number of IP proxies there are out to keep people from running one and logging all the people at once they want to
Well, you seemed to imply that by turning on noresolve, you never see the IP address and only use the hostname. That doesn't make a lot of sense to me; I'd have figured that it'd give the opposite i.e. IP address but no hostname.
In any case, the reason some people's hostnames won't show up would be if the DNS lookup fails for some reason. There are plenty of reasons why that could be: it could be a timeout, maybe the person really has no hostname handed out by the IP, the IP is spoofed and the spoofed IP has no hostname associated with it, etc.
Well then ignore my comment about noresolve since I probably had what I meant backwards.
Basically, Alt always had the DNS and Main always had the IP. It didn't seem like a simple lookup error because it happened everytime and yet the IP resolves to the DNS.
First off an issue of vocabulary; they're hostnames, not DNSs; a DNS is a domain name server, it's the computer that holds the mappings of IPs to domain names (hostnames).
I'm a little surprised that two connections would have the same port. Normally, if two have the same port, it means that it's literally the same connection, not two connections from the same source.
When you say 'check users' you mean typing in the users command, right? And you saw two distinct lines with the same port, but one with an IP and the other with a hostname?
Yeah, I know I have an issue with explaining in exact words or even the right words. Thanks.
I meant that as I saw Sock.sinaddr with the IP, I waited until the next player signed on and compared ports via the users command. That way I knew the IP.
Quote: I meant that as I saw Sock.sinaddr with the IP, I waited until the next player signed on and compared ports via the users command. That way I knew the IP.
I don't understand what you mean. Like I said, it doesn't make sense for two separate connections to come from the same place with the same port. The very meaning of a port is that it services one connection.
Comm: Sock.sinaddr: 203.240.225.27, port 1809.
Alt@pcp02934895pcs.planfd01.in.comcast.net has connected.
<I type users>
Desc|Con|Idle| Port | Player @HostIP
39| 0| 14| 1809| Alt @pcp02934895pcs.planfd01.in.comcast.net
Does that make sense? I watched the port that connected and looked at the character that just signed on. Therefor, 203.240.225.27 = pcp02934895pcs.planfd01.in.comcast.net
So, the character you have labeled as 'main' there. You're saying that no matter when he logs on, he always has only the IP address? But when the character labeled 'alt' logs on, the resolve gives you a hostname? Even though both are (apparently) coming from the same IP?
Right. To be more specific, it wasn't myself who caught him, it was a supervisor. What I'm really asking is that is it possible for a person/computer to "force" their IP to not be resolved to a hostname? I mean it wasn't a proxy because the person always used that comcast address. The two characters were signing on and off at long lengths between each of the time trading shards between each other. Which is highly illegal in our MUD.
It could be possible if there is some form of spoofing going on, or if there's a proxy, firewall, etc. somewhere, that might be refusing DNS lookups after the first one. Seems funny though that somebody would go to that much trouble to cheat. Is there any reason to believe this player is the kind of person who would do that?
A firewall eh? Well I am not positive it was intentional, but I'm nearly sure it was.
Oh yes, he's caused so much trouble before. His first chat replying to a PK hate discussion was "I love PK, it gets me into the game" or something of the sort. A week later he gets his first shard, gets killed twice, complains that he was killed within 5 minutes twice (when it was really 30min) and then chats "F*** THIS MUD" and quits. A week later he is back and causing more trouble.
I'm not entirely familiar with how one could block DNS lookups however if he's behind a firewall and his firewall acts as the DNS node for his connections, it might do the trick for him.
I'd suggest that you rewrite your mplay detection to go off of IP addresses and not hostmasks. You might have to store the IP address in addition to the resolved hostmask, so that you can always compare from straight hostmask.
An interesting thing to try, next time this happens, is to ping both the IP address and the hostname. The hostname should, in principle, resolve to the IP address you first pinged; the ping tool will tell you what IP address it resolves to. If they don't match, and if you have reason to believe it's the same connection, something is afoot.
Of course, if this guy is that much trouble, and you know who it is, and you are absolutely sure he's cheating, just ban his IP and be done with it. Why worry about going through all this :)
You don't need to look up the IP address on connection; you already have it. What you do need to do is write it in string form. Fortunately, that's fairly easy.
strcpy( buf, inet_ntoa( sock.sin_addr ) );
That's all you've got to do, assuming that 'buf' is an appropriate char[]. You probably shouldn't store it in pcdata, though; just leave it in the connection data structure with the rest of the connection information.
Eh.. umm.. if there is no connection, how will you have an IP to begin with? Are you saying that you need the IP to be persistent for e.g. a link-dead player? Then yes, you'll need to put it into the pcdata...
That piece of code I gave you is taken from the connection accepting. It only works when you just accepted the connection and still have the socket structure lying around. And yes, you do need to include whatever's necessary, although I forget which files exactly you need.
Yeah that's what I meant, I'd like finger to show the IP of players even if they aren't on. Right now it shows the last hostname (something I added). Why shouldn't I store it in pcdata? Or did you say that just because it already existed?
I still don't understand how this line:
strcpy( buf4, inet_ntoa( sock.sin_addr ) );
Will store the IP of the victim (and not ch, or who for that matter) in buf4.
I said to not store it in pcdata because conceptually that's not where it belongs, but if you have extra requirements (e.g. IP addresses persist after deconnection) then it makes sense to put it there.
The line I give you doesn't target anybody. As I said, it comes from the code that accepts connections. It takes the socket structure that was just obtained from accept() and grabs the socket address. It is not something you would use anywhere else in your code. In fact, if you grep for inet_ntoa you will probably end up in the socket accepting code.
Well I don't understand since if it is only used in new_descriptor, how am I suppose to display it with a character? The character loading is dealt with in nanny.
When you load the character in nanny, you have the descriptor, right? So if you store the IP address (in string form after inet_ntoa or in the sock_sinaddr form), you can then stick it into the pcdata structure or wherever it is you want to put it.
So STRALLOC the result of inet_ntoa into a string on the DESCRIPTOR_DATA structure to save it and have an in game one easily available? Make sense.
Does your finger code load the charactes to read in the data? Or does it write to a file, and the finger command checks that?
Either way, you could just copy the value from ch->desc->ipstring to ch->pcdata->ipstring, or you could write to the file(s) from ch->desc->ipstring directly, though with this the IP will not persist if the character is loaded by an imm and forced to save.
The finger is the latest snippet, so it loads and reads the player file.
Storing it in a buf yes I know, but I need to write the buf someone in order to read it in another function. Are you saying to change the header of the functions to store this buf?
This should create a a string based on the ip, allocate the memory for it, and change d->ipstring to point to that memory. You should, I beleive add it right above:
if (!sysdata.NO_NAME_RESOLVING)
No testing was done, but that should give you the ip adress as a string allocated into a field in their descriptor data, and this would allow you to copy it later into their pcdata.