1) PROJECT INFORMATION

1.1) What is the bnetd Project?

1.2) What is Battle.net®?

1.3) What is Starcraft®?

1.4) Why create bnetd when Battle.net® already exists?

1.5) What is the history of bnetd?

2) DEVELOPMENT INFORMATION

2.1) How complete is bnetd right now?

2.2) On what systems does bnetd work?

2.3) Who is the bnetd team?

2.4) Where is the bnetd changelog?

2.5) Is there a todo list?

3) INSTALLING THE SERVER

3.1) Where can I download bnetd?

3.2) What version should I use?

4) RUNNING THE SERVER

4.1) How do I start bnetd?

4.2) Why don't I see anything when I start bnetd?

4.3) How do I customize the server?

4.4) Why can't I start Diablo® games?

4.5) Why can't I connect with Diablo® II?

4.6) How do I enable autoupdates?

4.7) How do I add admin rights to an account?

5) CLIENT QUESTIONS

5.1) How do I connect to a server through my firewall?

5.2) How do I choose which server to connect to?

5.3) I'm using BNS but it doesn't select my server?

5.4) How do I connect to the original Battle.net® server?

The project is a collaboration focusing on development of the bnetd server. This is a program that attempts to emulate Blizzard's Battle.net® service. The bnetd project is run by volunteers and neither supported by nor otherwise affiliated with Blizzard Entertainment®.

A major part of the effort is supporting all Bizzard's Battle.net® compatible games. The server may eventually support some non-Blizzard clients as well, but no work is currently being put into that. Certain software in addition to the bnetd server should also be considered part of the bnetd project. This includes BNS (BNetd Selector), bnchat (a text-based chat client), the BNI utilities, and bntrackd (BNetd TRACKing Daemon). The bnetd team also produces documentation about these programs and the Battle.net® protocol.

To avoid confusion please note that Battle.net® is a trademark and/or trademark of Blizzard Entertainment in the U.S. and other countries. The term is used here to refer to their free (as in beer) online gaming services.

Battle.net®'s servers communicate with their client products like Starcraft®, Diablo®, and Warcraft®. The servers provide chat rooms and lists of multi-player games to join. Other services they provide include ladder rankings, permanant accounts, and client upgrades.

Starcraft® is an RTS (real time strategy) game produced by Blizzard Entertainment®. It is unique in the fact that the game may be played from the point of view of three warring races. The races are completely different to one another, and a great deal of design and thought has gone to creating a balance between the participating races. Up to eight players (people or computer-controlled AIs) may play in a game at once. The game has remained wildly popular years after it was first released.

Quite simply it's one of the most perfect examples of an RTS game currently available.

Starcraft® provides no method to play TCP/IP games other than using a proprietary service provided by Blizzard. This service is often slow, and is sometimes down due to a crash or maintanence.

For some people (at LAN parties, school networks, etc.) it is not possible to access Battle.net® because of a lack of Internet connectivity or because of a firewall. Using Battle.net® chat rooms brings attention to your computer similar to using IRC.

With the staggering numbers of players on Battle.net®, it can be difficult to locate friends or other players willing to avoid using cheats or disconnecting when things aren't going their way.

Running your own server allows you to customize the login banner, the ad banners, channel names, account attributes (you can decide who is an operator or admin), and the ability to delete accounts of abusive players.

Last but not least, you have a significant chance to register an account with your favorite nick. :)

The project started around the time Starcraft® was released. It was created for hack value and as a solution for the problems mentioned in the reply to question 1.4.

The original work was done by Mark, who maintained releases on http://www.starhack.ml.org/ through version 0.3. That version spawned several ports to MS-Windows, most notably FSGS. The ml.org domain went away and the original code languished for a while. Ross began working on patches to the code but found it difficult to distribute them. Then Josh and his friends set up a site to revive the project on http://bnetd.unleashed.org/ and collaboration quickly ensued producing the 0.4 release which supported account passwords (yea!). Tim set up the bnetd.org domain and a permanent net connection.

The bnetd project was shut down in February 2002. You can read about it in the Slashdot article. The last release of bnetd was release 0.4.25 in January 2002.

It currently supports most Battle.net® functionality. Features include:

• Highly configurable
• Starcraft® and Brood War® clients
• Diablo® 1.05 and later clients
• Warcraft® II BNE clients
• Diablo® II (closed characters can't play) clients
• Chat and bot clients
• Account creation, login, and changing passwords
• Permanent and user-created channels
• Player record statistics for Starcraft®, Brood War®, and Warcraft®
• Player character stats for Diablo®
• Game reports
• Channel operators and server admins
• Logging of server activity
• Ladder games and rankings
• Customizable channel icons
• Customizable channel banner ads
• IP bans
• Auto-updates for clients

Some things on the TODO list are:

• Inter-server connectivity (BITS)
• Latency status reports are using TCP instead of UDP
• Idle logout
• User limit config option
• Relaxed game report checks
• User limit config option
• Improved game status tracking (interpreting STARTGAME packets)

0.4 should work on almost any Unix-like system. Systems that have been tested are AIX, FreeBSD, HP-UX, Irix, OpenBSD, NetBSD, Solaris, SunOS (gcc only). Even Win32 works.

If you are installing from source, you will need an ANSI C compiler for 0.4.x and earlier either an ANSI or K&R compiler for 0.6.x and later.

For details, see the CREDITS file which is included in the source tarfile.

You can look for the file CHANGELOG in the top level directory of the source tarfile or you may read the latest version from the CVS Browser. Use the direct link to the CHANGELOG, and if you are interested in a really detailed ChangeLog, look at the ChangeLog.cvs2cl, which is auto-generated nightly.

Look for the file TODO in the source tarfile. You can also read the latest version from the CVS Browser. Use the direct link to the TODO file. The order of the items in the list is not significant.

There is no longer an official download location for bnetd. You may be able to find the sources or perhaps even compiled packages in the archives of one of the Linux distributions or *BSD ports collections.

The last release of bnetd, 0.4.25, works sufficiently well for the old Blizzard games, but see question 4.5.

After you have built the source, the program binary is put into sbin/bnetd. To run the server, just type: sbin/bnetd from the bnetd main directory.

By default, the bnetd process runs as a daemon in the background. If you want to run it in the foreground, use the -f option when you launch the server.

Note that when the server is run in daemon mode, the first thing it does is a change directory to / so you need to make sure that all paths in your bnetd.conf are absolute paths.

The bnetd configuration file can be found in /etc/bnetd/bnetd.conf. This contains pointers to where log and player files may be found and also some tuning information so you can customize it to fit your needs. See the bnetd.conf(4) manual page found in the man subdirectory of the distribution for details on each possible setting.

The support for games other than Starcraft® and Brood War® was in its infancy at the time 0.4 was released. So when using bnetd 0.4, some versions of Diablo difficulty connecting or starting games. Versions of bnetd after 0.4.22 have good Diablo I support as long as your client is upgraded to version 1.05 or greater.

Before 1.05, Battle.net® used a completely different protocol which looked liked database transactions and ran on a low port number. Support for this is now difficult to add since we don't have any packet traces. If someone really wants support for this we would be willing to work with them.

Diablo II uses a new connection type that was not supported before bnetd version 0.4.23. Later versions support this feature. If you are already running 0.4.23 or later but still have problems, see the next paragraph.

With patch 1.08 of Diablo® II, Blizzard changed its CD Key authentification (again). Release 0.4.25pre3 and earlier don't unterstand the new packet type. Later releases should handle this properly.

It is unknown whether later patches of Diablo® II work with bnetd. If you are having troubles, you may need to look for an alternative to bnetd.

Autoupdates are Blizzard's method of automatically upgrading game clients to the latest version when they connect to Battle.net®. Doing this ensures that all users have compatible game versions and will not have syncronization errors during game play.

Autoupdate was not easily usable with bnetd until version 0.4.22. This option can now be enabled by editing two configuration files and placing at a version authorization MPQ and an upgrade MPQ in the files directory..

First open your bnetd.conf and find the "Downloadable files" section. Change the allow_autoupdate option to true. This enables client version authorization. Now change mpqauthfile to be the filename of an authorization MPQ. This should just be the filename, not the full path. An example filename is IX86ver1.mpq.

Second, open your autoupdate configuration file and uncomment the lines for the clients you wish to upgrade. The middle column should just be a filename not a complete path. The version field can be computed from the upgraded client version number. For example 1.05 becomes 105 and 1.08 becomes 108.

The MPQ files can be obtained from Battle.net® using bnftp(1) or you can search for them on the world wide web or get them from an FSGS distribution.

Find the account file with the uid of the user you want to change (you can use grep from the shell or the /whois command on the server). Then shut down the server if it is running. Using any text editor you like add a line like this:
"BNET\\auth\\admin"="true"

There are other authorizations you can enable on accounts. Most of them are documented in the bnetd_default_user configuration file. For example, you can prevent an account from ever becoming an operator by adding this line:
"BNET\\auth\\operator"="false"

This is one of the most asked questions and also one of the hardest to answer. Of course the answer depends on your network setup and which OS you use on your firewall. If you use NAT (or masquerading) then it gets even more complicated.

The first thing you might want is the port information. The protocol uses TCP port 6112 on the bnetd server. It also uses UDP port 6112 on both the client and the bnetd server. If you use Diablo® II, then TCP port 4000 also needs to be open to the server. The clients will also talk to each other on UDP port 6112 during a game. If port 6112 is not available on the client when it binds the socket, it will receive on a random port number.

Even if your setup works with a single machine one game or two machines in two different games, that is no guarantee that more than one machine will work smoothly in the same game. The most common symptom of a setup problem is "serious" lag during gameplay. The current theory is that the game is sending the traffic for all the clients through a single client.

A thorough writeup of the issue was done by Dizzy. It's called bnet-masq-howto and while it focuses on Linux 2.2, it has lots of general information as well.

For Linux 2.4 using iptables (AKA Netfilter), there is good news. It is possible using full NAT (SNAT+DNAT) to get rid of the lag for any combination of machines inside or outside the firewall. There is a message from Rick Kramer on the Netfilter mailing lists describing how to set it up. In his case, he is assuming the bnetd server is outside the local network.

The instructions for Linux kernels 2.0.36 have been recorded below:

A simple way to connect to a Battle.net®-like server is to use the ipautofw program to add a forwarding rule for the packets, where x.x.x.x is the client machine.

   /sbin/ipautofw -A -r tcp 6112 6112 -h x.x.x.x -v -u
   /sbin/ipautofw -A -r udp 6112 6112 -h x.x.x.x -v -u
      

This works for single-user games or for games with only one computer from the internal network or for games hosted by an external computer with any number of external computers and at most one internal computer. Confusing enough?

Normally when the bnetd server is also behind the firewall, and a game is hosted by an internal computer, only other internal computers can join. The gametrans settings can use used to tell bnetd about the address translation that is happening so that this does not happen. This way, bnetd will know not to give out the local addresses (10.x.x.x, 192.168.x.x, or whatever) to computers outside the firewall.

Even when you do that, as soon as you have two or more players from the local network in the same externally-hosted game serious lag will occur. As far as we can tell this is unavoidable on non Linux-2.4 sytems without a kernel module or proxy.

Similarly, if two or more computers are in the same internally-hosted game from outside the local network, serious lag will occur. A solution for this has been found (it worked for me). All of the details are in this message on the official Linux Masquerading list available at http://home.indyramp.com/lists/masq/msg03024.html. What it basically says is that the kernel connection tracking will get confused by multiple remote computers talking to the same port on an internal computer (actually it will think the other computers are trying to break through the firewall). The solution for this is known as loose UDP port management.

This isn't enabled by default in any Linux kernel version it is a slight security risk. If you have a UDP server running on say port 9999 and your computer sends a UDP packet from port 9999 to Internet host A, then Internet host B can connect back to your server on port 9999 if it guesses the correct proxy port number. This isn't an issue if the only UDP traffic will come to and from bnetd. Keep in mind that DNS requests are UDP. If you decide not to do this, you can still make things work by setting up manual port forwarding entries for each client machine (FIXME: I think... or does that need loose UDP as well?).

For 2.0.36 and below you must add two kernel patches for loose UDP. The first patch is called "LooseUDP" and updates the masquerading code to include an experimental option "CONFIG_IP_MASQ_LOOSE_UDP". FIXME: I don't know what the second patch is... maybe that was a typo above in a previous version of this document.

For 2.2.15 and later kernels, no patches are needed. These kernels include a sysctl which is accessable as /proc/sys/net/ipv4/ip_masq_udp_dloose. There are three possible values which can be echoed into this file. A "0" (default) means not to allow loose UDP port management. A "1" means to allow it for unprivileged ports. A "2" means to allow it for all ports (bnetd should work fine with "1").

For 2.4.x, there doesn't seem to be a sysctl for Loose UDP handling. This means you will need to use manual port forwarding for each machine as described in the Netfilter mail list message listed above.

So now you've got bnetd running, how do you point your Starcraft client at the server?

Once Starcraft, Diablo, or another client is installed, you can use a program named BNSv1103.exe to switch between different bnetd servers and Blizzard's Battle.net®.

This program has a simple interface that has a radio button that lets you switch between the Blizzard Battle.net® server or Other. To use Other click on the radio button next to that entry and type in your hostname or IP address below.

You can also use BNS to launch your game automatically by selecting it inside the Launch box.

You can also change the server while the client is running. For example, with Starcraft® you should return to the first screen past Multiplayer where you can choose Ok or Cancel to connect to the Battle.net® server. Use Alt-Tab to switch to either BNS (if it is still running) or to Windows Explorer and select a new server and click Apply. Then switch back to Starcraft® and click Ok to connect to the new server.

If you are using BNS 1.1.0.3 or older with Starcraft®/Brood War® 1.08 or newer, Diablo® 1.08 or newer, or Diablo® II then you are not alone.

This is because Blizzard has changed the registry format to support client-side selection of the Battle.net® gateway (USWest, USEast, etc.). While this is a very nice change, BNS hasn't yet been updated to handle the new format.

The MyBnet project provides a selection utility which is reported to work quite nicely. Jeff has kindly offered to contribute the program to the bnetd project.

There is a gatesel.exe program which could be found on Blizzard's ftp site which is supposed to be able to handle the new format.

Failing that, there are instructions for how to use regedit to manually enter the server. These instructions are included in current bnetd releases as docs/README.diablo108. Note that some versions of Windows use 16 bit characters in the text fields.

For BNS users: start BNS, make sure Battle.net is selected as the server, and then click Ok.