IP backwards???
#1
I was helping someone with a server the other day and had an odd problem. When you type /whois the result shows the IP in reverse order so if your IP is 11.22.33.44 the result you see id 44.33.22.x This happens to anyone trying to whois on that server. The server was run on a mac if that makes any difference. Has anyone seen this before? Is there a setting or something to fix this?
Thanks given by:
#2
MEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE!!!

Idk, ive never ran an AC server on Mac OS X. It might be a compatibility problem if hes running Lion/Mountain Lion. I really dont know, Maybe B}RonaldReagan might help, He has a mac.
Thanks given by:
#3
I ran a server on a mac for a while and did not have this issue. It could be mac related, but I didn't experience this. I have Mac OS X 10.6 if that helps.
Thanks given by:
#4
i could test it by downloading mac os x then running a server on it :>
Thanks given by:
#5
Haha, wow, that's something. Where did they get their server binary? Is it stock or one they or someone else compiled? Someone could be playing a subtle prank. If it was compiled you should check from line 2256 of server.cpp for any deviations from a known good copy of the source code.

Otherwise, I'm not sure. All I can think of is to have them monitor server output in terminal and see if client addresses show up in proper order there. This could at least help define the scope of the problem.

If you'll get in touch with Reagan and see if he wants to help, you could have them send over their entire assaultcube directory — minus confidential data — and see if he can reproduce the issue.
Thanks given by:
#6
I will ask for more info about server and OS version and see if I can get that directory.
Thanks given by:
#7
I highly doubt it is related to the operating system. The operating system will more likely cause bugs in the client rather than the servers.
Thanks given by:
#8
Is that a PPC Mac?
Thanks given by:
#9
he says its 10.5 PPC and no mods to server or client, still trying to get a copy of the whole AC folder (minus passwords and maps). If I can't get the folder I will suggest delete and reinstalling AC, unless someone else has seen and knows how to fix this problem.
Thanks.
Thanks given by:
#10
Just guessing here, but how about if he runs ifconfig to see if this is some strange system-wide issue? See if the address there is in correct order. Also, if he watches server output while a client is connected, is the address in each line of that client's actions also backward, or is it only backward in whois?
Thanks given by:
#11
Nope, that looks a lot like an endianness issue. PPC Macs operate in big-endian mode, while almost everything else nowadays uses little-endian.
Thanks given by:
#12
Ah, that makes sense. So I'm guessing some solution could be made using ntohl() or ntohs()? I'm unsure which would be used. I'm still a bit patchy wth programming and haven't dealt with C++ anyway.
Thanks given by:
#13
i thought ac only ran on Intel macs :D

I guess AC has universal binary
Thanks given by:
#14
Ok, he said the logs show the correct IP, I think I should get a screenshot just to make sure. Unless there is a ready made solution I doubt he nor I will be going through the trouble of any C++ programming. I may suggest a different computer type or just not host a server.

...Too many endians an no chiefs, or is it the other way around.... ¯\(°_o)/¯ I DUNNO

Thanks for the help.
Thanks given by:
#15
if i were turdnuget id get a new mac PPC is out dated
Thanks given by:
#16
That problem is easy to fix as far as I can tell, but I doubt it's severe enough for your friend to recompile his server.

Btw, thanks for your insightful comments, Jg99.
Thanks given by:
#17
(19 Aug 12, 05:55AM)[SODA]___ME___ Wrote: Ok, he said the logs show the correct IP [...]

That's normal, since the problem occurs while "packing" the IP address before sending it to the client.
(the IP is sent as an integer, but if the bytes aren't sent in the right order, the received ip address is reversed)
Thanks given by:
#18
Just wondering, wouldn't this affect the demo and map format? iirc the source relies on assuming that the endianness stays the same for these file formats.
Thanks given by:
#19
No, that's taken care of. In both maps and demos (and network traffic as well), endianness is independent of the platform endianness.
This case is special because IP addresses are always stored in network byte order, i.e. big-endian, even on little-endian systems, which caused the problem.
Thanks given by: