PenUltima Online

I always wondered why, when you connect to a pol server, it does not show you the latency or packet loss. It turns out that the server is sending the ping ip incorrectly according to:
http://kec.cz/tartaros/steamengine/uplo ... style=gold

If you connect to the ip of 127.0.0.1 it will send it as:
7F 00 00 01

According to the packet guide above it says it should be sent in reverse:
01 00 00 7F

I wrote a packet hook to SetInt32Flipped the correct pingip but it still did not work. I tried it with localhost, my network address and connecting to another server on my network. Perhaps the client just doesn't like to ping on the network, perhaps the client doesn't ping anymore, perhaps POL is sending everything correctly and it just seems like it isn't. I tried printing out the pingip from the packet hook before it was flipped and it matched what uolog said, and the pol packet guide mentions nothing about how the IP should be sent in reverse order.

Uhm............

Firewall blocking ping requests maybe? Worth checking

Oh yeah, updated the packet list site also for the entry. When I get time, I'll look into testing this via packethook. Can you send me or post your hook you are using? Will help speed things along for me

Also, would need verified for client 2.0.0 also, as we do support it

It's definitely not a firewall since the machines involved didn't have any running. I can ping everything just fine. Wireshark (network analyzer) never reported any pinging going on between me and the other computer on the network when I connected either. It's like the client doesn't try. I'd like to try it with a server on the internet.

Here is a perl script building up the 0xA8 packet, and it puts the least significant byte in first (line 202-205):
http://www.koders.com/perl/fid43F8A7C80 ... 124CC.aspx

But, this guide says it should be big endian:
http://kec.cz/tartaros/steamengine/uplo ... cketa8.htm




I'm going to keep poking around.

I checked an OSI packet, and the ip is reverse order, corrected the core in 097 already. Since no more 096 subs will be done, left it alone for now.

Also, it takes a little time for the request and listing. Even on OSI, it takes up to 5 seconds or more to get this field populated in the client. Although, they have a lot of servers that ping out. It "could" be a client packet, but I doubt it, since no logger picks it up. Although it could be that they are ignoring it. Will have to check into that.

I did not see any packet with all filters disabled, so wonder how it's doing it. Direct connection maybe? Hrm...............

Local host is working for me in my test with the IP reversed as said. When I enable my firewall, it stops reporting MS and latency %. Need to do testing via internet connection though, instead of local host, to be positive it is working.

Seems to be working now for me.

Enabled logging in my router, and found out the client sends it's pings in UDP to port 12000. I set port forwarding on for 12000, and it started reporting a latency time for me on the wan port. Will need to find a sucker to test from their end for me to be sure though.

I'm game. What's the login info?

Sent it to ya in a pm

Just posting for an update here.

Locally I can get this working, from the net no.

Will prob end up requiring testing with stuff such as DMZ enabled, and so forth, to see if we can narrow down why it doesn't report it correctly. I feel it's a client issue now that the IP is correctly given, but, you never know. It may expect it's response from the server too (but I doubt it).

oh, that's what the client is trying to do when i see a request for 1.0.0.127 at port 12000...

strange thing is, i am using the lastest 97 core on windows, and seems the client still gets the ip in the wrong endian

btw, i think the client waits for a response ? there's nothing listening @ port 12000 so even if it was right the client would not connect to anything

Correct, Unsure if it sends it to that port on the server, or elsewhere at the moment. I have corrected the endian for the next 097 release, but there still seems to be some sort of issue. I can see latency reported as 0 on localhost now, but, outside localhost, people did not see it reported (yes, port forwarding correct and so on).

May need a reverser to see how the client is sending this info. Shini, go bug your friend for me to see if he can tell how it sends out that request to port 12000, so we can try to see what is going on... please