Known Server Issues

This focuses on the technical issues present on official Classic Battle.net™ servers.

Issue List

[Top]

DNS record contains offline servers

Reported: July 26, 2021 Resolved: August 5, 2021

When games wish to connect to U.S. East, they connect to useast.battle.net or connect-use.classic.blizzard.com. The same pattern exists for other realms like U.S. West (uswest/usw), and so on. On at least the U.S. East realm, there appear to be one or more servers that do not actively wait for connections; that is, they appear offline and do not accept inbound connections, while behind a production DNS endpoint that should always be waiting for new connections.

As of July 26, 2021, the following are the IP addresses that sit behind two known DNS records for U.S. East: *

* August 5, 2021 Update: The records have since changed since this issue was reported.

$ host connect-use.classic.blizzard.com | sort ; host useast.battle.net | sort
connect-use.classic.blizzard.com has address 199.108.55.51
connect-use.classic.blizzard.com has address 199.108.55.52
connect-use.classic.blizzard.com has address 199.108.55.53
useast.battle.net has address 199.108.55.54
useast.battle.net has address 199.108.55.55
useast.battle.net has address 199.108.55.56

Sorted alphabetically, the active IP range becomes clear: 199.108.55.51 through 56. Note that Anycast DNS is not involved here; the set of IP addresses are the same anywhere in the world one could lookup these records.

To test each IP address, a method was proposed wherein the client must attempt connecting to the IP address, logging in, and joining the Open Tech Support channel. This test was performed for each of the 6 IP addresses listed above (screenshot). The server at octet 53 is not accepting connections, however since it's listed in DNS, an official game client such as Diablo II or StarCraft may resolve the DNS record to that octet and would receive an error while connecting.

If one were unlucky enough to have this octet be resolved, the connection error would persist until the DNS cache expired, then after the client would hopefully resolve the DNS record to a different octet and be able to connect. All of this behind the scenes, unknown to the end user, who would simply see a connection error, then the error would disappear moments later, all the while their friends could be telling them they can connect just fine and it's on their end not Blizzard's, while in fact it is actually Blizzard's end.

Ghosts in channels

If an individual server in a realm restarts, all users in that particular server remain in channel permanently for all other servers in that cluster, until a global server restart occurs.

It is also possible to cause a user to ghost in a channel by reconnecting in succession fast enough to cause the server not to remove the user from online presence. The exact methodology to reproducing this effect is still in testing. Once this occurs, the user will remain online indefinitely until next server restart. Clients looking for "invisible" users will notice the product icon may change entirely if the user logs on and enters the channel with a different game than the ghost user had been using, other clients will simply notice two users with the same username in channel since EID_SHOWUSER/EID_JOIN are interpreted as never being non-unique.

IP ban allows partial handshake

When sending invalid or too frequent messages to the server, an IP ban is issued. A further attempt to reconnect used to disconnect the connection immediately, ignoring any data that followed from the client. Currently, the handshake progresses through until SID_AUTH_CHECK is sent, then it hangs until exactly 1 minute later the connection is disconnected.

It is assumed that this is intentional, so that Blizzard can learn of additional IP addresses and game keys from previous offending users.

Noticeable delay in chat events

When receiving SID_CHATEVENT, there are many event ids that seem to cause some sort of a delay of about 150-230ms*.

These delays appear to be present regardless of realm or individual server IPs in each cluster.

* Measured using Wireshark and own ping is removed.

Reconnecting too fast causes key in use

When connected with a game key, the key is considered in use. If reconnecting within a short time span, around less than 500ms, the key will still be in use. After the delay, the key is no longer in use and reconnecting works normally.

This may be related to the noticeable delay in chat events.

Spam filter silently drops messages

Battle.net's new anti-spam system will sometimes drop messages arbitrarily without notifying the user, even if you aren't necessarily "spamming". There is presently no implemented solution to determine on the fly when this is happening.

System-generated friend whispers use incorrect locale

When the server sends a notification via whisper about your friend, it uses your friend's locale instead of your locale to notify you of the event. So for example, if your Spanish friend enters a game and you're English, the system uses Spanish locale to tell you instead of your native English locale.

Squelch no longer mutes by IP

The /squelch command no longer ignores all users on the target's IP address. This is probably unintentional and related to the tunneling system that StarCraft uses.

Servers do not respond to UDP connections

When clients that utilize UDP (W2BN, DRTL/DSHR) attempt a test connection the server does not accept (or ignores) this, resulting in the test failing and the user being given the no-UDP chat flag.

/users command does not return anything

The /users command, which normally returns the number of users and games on the current product and the server as a whole, no longer returns anything. The output of this command that is usually sent as part of the server MotD is also not sent.

SID_STARTVERSIONING is never sent to Diablo: Hellfire clients

Traditional Battle.net servers allow Diablo: Hellfire (HRTL) clients to connect and begin the connection handshake, but never sends back a SID_STARTVERSIONING packet, causing the connection to indefinitely hang. On connect-forever.classic.blizzard.com, the connection gets closed by the server.

| Edited: Caaaaarrrrlll

Comments

no one has commented yet.