no servers in server select Project 1999 Files (V40)

[Vart]

Like the title says , I have been away for over a year and decided to login again, updated my P99 files to V40 and the sever select screen is empty.

If i revert back to my old patch files the servers are all listed but can`t login due to outdated spell files. What is changed in V40 that would cause my server list to not show?

Thanks for any info.

[Boilon]

My friend is also having a similar issue. Not sure why that is and having difficulties helping him out. He says sometimes server selects show up but an error happens when trying to connect to the server.

[Wisteso]

Server select isn't part of P99.

That said, keep trying. Blank server select / error when connecting is usually due to packet loss.

EQ is really bad with packet loss recovery, so retrying is all you can do. Aside from using a VPN.

[Boilon]

Also had problems from character select in to game. Waited over a minute and would just get Not Responding

[Wisteso]

Then it's probably packet loss.

Keep trying until you get in. If most people on P99 aren't having this issue, then the packet loss is either happening due to some problem in your residence OR your internet provider is having its own issues.

Either way, VPN can sometimes bypass the problem.

[Vart]

Still cant login :(

It definitely isn't packet loss , when I revert back to V33 all the servers pop up instantly. When I update to V40... no servers.

Something different from V33 to V40 is clearly the issue.

Who write/codes these patches? Maybe I could PM them or get them to post to this thread as to what changed between V33 to V40. Because with V33 all is fine. With V40.. I cant play... :(:mad::(:confused::mad::mad::(:(:(:

[Wisteso]

It's not V40. Those files aren't even loaded until you connect to the server.

If you're technically savvy, look at Zaela's tool in this thread...
http://www.project1999.com/forums/showthread.php?t=218666

[Zaela]

Could maybe somehow be caused by the DLL injection that is done, in which case good luck getting any info about that. I don't know if this is the same issue that the tool Wisteso linked helps with on Linux machines, it's really unclear what the issue there even is. Maybe, though.

For posterity, you can diagnose whether the problem with server select is packet loss or a problem with the client using Wireshark. The process is reasonably user-friendly:

1. Install Wireshark (https://www.wireshark.org/). If you're on Windows, the installer will probably ask you for permission to install the special network driver it uses at some point; agree to that. If you're on Linux, there's a good chance your distro came with Wireshark already installed.

2. Start Wireshark. On the left pane you'll see your available network interfaces. (If you're on Linux, you may need to start wireshark from the terminal with "sudo wireshark" to see anything here.)

http://i.imgur.com/115vMlM.png
Select your interface and hit the "Start" button just above. If you're on Wi-Fi, you'll want the Wi-Fi interface. Otherwise you'll probably need one of the Ethernet interfaces. (These are called wlan0 and eth0 on Linux.)

3. The packet capture interface will open up, and if you have a browser open or anything you'll probably start getting spammed with packets. We want to filter out all packets not related to the EQEmu login server:

http://i.imgur.com/75vNbRd.png
Click on the "Filter" text area near the top of the window and enter the following

udp.port eq 5998

and then hit Enter. Any packets that were in the main window should be filtered out.

4. Start up EQ and log in. When you get to server select, go back to Wireshark and hit the red "Stop" button just above the filter text area.

http://i.imgur.com/HQtq4Lc.png

You should see a number of captured packets. In particular, you should see a run of 10 or so packets from port 5998 with a length of 554, followed by one with a shorter length (100 in the screenshot).

This is the server list. If you see these packets, you most likely don't have packet loss.

If you want to be extra sure, you can briefly look at the contents of the packets to see if everything lines up correctly:

http://i.imgur.com/Rb5ybwj.png

Find the first packet with a length of 554 and click on the "Data" header toward the bottom of the window, so that the data section of the packet is highlighted, as in the screenshot.

The part with the purple box around it is the client's "Protocol" header. The first two bytes say what kind of packet this is; for all the packets in our sequence, these should be "00 0d". The next two bytes ("00 02" in the screenshot) are a sequence number; you can check this for all the packets in the sequence to see if they were received in order. In my case, the first packet is "00 02", the next is "00 03", and so on until it reaches "00 0e" in the last packet since there were 13 in the sequence (it's hexadecimal, "00 0a" comes after "00 09").

In the first packet only, the part surrounded by the red box in the screenshot is the total length for our sequence of server list packets. In the screenshot, it is "00 00 18 01", which we can enter into the hexidecimal field of a hex calculator (https://www.mathsisfun.com/binary-decimal-hexadecimal-converter.html) to find out equals 6145 in decimal.

We need to do a little calculation to find out the effective length of our sequence, since the headers aren't counted.

First, add up the total length of all the packets in the sequence with all of the overhead. In my case, this is:
(554 * 12) + 100 = 6748

Next, subtract 46 for each packet to remove all the per-packet overhead:
6748 - (46 * 13) = 6150

Then, subtract 4 to account for the "total length" field from the first packet:
6150 - 4 = 6146

This is our final value. You'll notice that we were looking for 6145 but got 6146; this is okay, since the calculations the server uses are not exact. The actual length may be a little higher than the expected value. If the actual length is less than the expected length, then we have a problem: we didn't get all the packets we need. Packet loss!

[Wisteso]

Zaela, when the DLLs are injected, no other server can be logged into without getting an error. It instructs you to restart the game before connecting to a different server.

Since that only happens after logging in to P99, isnt it pretty safe to assume that the injection happens then?

---

As for the tool, even though it was written for linux, I'd imagine it could still help if they are receiving 100% of the packets but still having issues.

[Vart]

After a reinstall of titanium and then V40 I can now see the servers and login , no idea why I couldn't from just over writing V30 but all seems to be working now.

Thanks for the help guys.

[Zaela]

Zaela, when the DLLs are injected, no other server can be logged into without getting an error. It instructs you to restart the game before connecting to a different server.

Since that only happens after logging in to P99, isnt it pretty safe to assume that the injection happens then?

Dunno. I know some of the injected changes will be active if you log onto other servers first (like map being disabled). Also, the payload checks for running debuggers and aborts as soon as eqgame.exe starts up, so it's already doing something by then.

I assume the packet encryption/extra control messages/whatever are the one thing that turns on specifically when you connect to a P99 server, and that there was no point in adding code to turn this off at runtime.

[Wisteso]

Good to know, Zaela.

Vart, glad you got it working.