This focuses on the technical issues present on official Classic Battle.net™ servers.
- DNS record contains offline servers
- Ghosts in channels
- IP ban allows partial handshake
- Noticeable delay in chat events
- Reconnecting too fast causes key in use
- Spam filter silently drops messages
- System-generated friend whispers use incorrect locale
- Squelch no longer mutes by IP
- Servers do not respond to UDP connections
- /users command does not return anything
- SID_STARTVERSIONING is never sent to Diablo: Hellfire clients
Reported: July 26, 2021 Resolved: August 5, 2021
When games wish to connect to U.S. East, they connect to
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 18.104.22.168 connect-use.classic.blizzard.com has address 22.214.171.124 connect-use.classic.blizzard.com has address 126.96.36.199 useast.battle.net has address 188.8.131.52 useast.battle.net has address 184.108.40.206 useast.battle.net has address 220.127.116.11
Sorted alphabetically, the active IP range becomes clear:
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.
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.
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.
When receiving SID_CHATEVENT, there are many event ids that seem to cause some sort of a delay of about 150-230ms*.
- Immediately after a EID_CHANNEL, the following EID_SHOWUSER events are delayed.
- Immediately after a EID_WHISPERSENT to yourself, the following EID_WHISPER event is delayed.
- Immediately after a sending a chat command for querying your friends list, an EID_INFO is received with the message
Your friends are:, then the delay occurs, followed by additional EID_INFO(s) containing your friends.
These delays appear to be present regardless of realm or individual server IPs in each cluster.
* Measured using Wireshark and own ping is removed.
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.
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.
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.
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.
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.
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.
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.
no one has commented yet.