version 3.3, updated Aug 5, 2001
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 of Davidson & Associates, Inc. The term is used here to refer to their free (as in beer) online gaming services. Their game division (maybe subsidiary?) is commonly called "Blizzard Entertainment" or just "Blizzard".
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. Work continues, and an 0.6.x release should be out soon (0.5 will be skipped, see question 2.5).
There are actually two different sets of mailing lists. The ones at bnetd.org (hosted by igateway.net) are older and have more subscribers. The ones on SourceForge are nice because they are archived.
If anyone has bnetd-dev messages before June of 2000, please contact Ross so he can put together a historic archive.
Both list hosts use GNU Mailman which allows you to subscribe an unsubscribe with a web browser.
First of all, the project is alive. It will continue to be alive as long as there are people willing to work on it.
Some of the main developers are very busy with their jobs, school, and life in general. Releases aren't made as often as they used to be. However those who wish to be on the cutting edge can still do so via preleases (which are made every few weeks) and the public CVS tree on SourceForge (which contains all the latest patches).
It currently supports most Battle.net functionality. Features include:
Some things on the TODO list are:
The answer of course depends on the version number. 0.4 should work on most systems after fixing the bug mentioned in question 3.4. Later 0.4.x development versions and 0.6.x when it is released should work on almost any Unix-like system. Systems that have been tested recently 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.
The makeup of the team isn't set in stone. Currently there are only a few active developers, Ross and Typhoon. Rob and Dizzy send in occasional patches. Lots of others have sent in bug reports, patches, and useful information. Tim provides a nice network connection, DNS, and a machine to run our webserver on. For more details, see the CREDITS file which is included in the source tarfile.
If you have experience with C programming then grab the source and hack away. Or if you don't have experience with programming go pick up some books on C, Unix, sockets, or whatever you are intererested in. We are always glad to answer questions about the source or to help people develop their patches. See the TODO file included with the source distribution for ideas to work on. We are in need of a Macintosh network programming person to help port bnetd to the Macintosh.
If you are into GUIs, you can work on the Win32 or Macintosh connection utilities called BNS.
If you aren't into programming, download the source and compile it (or install a binary package), play with it, and tell us if you find problems and we'll add them to the TODO list.
There are two active releases at any point in time: "stable" and "development". The development versions eventually become the next stable release and a new development branch is opened.
The first two numbers separated by decimal points determine the release number. So 0.3 and 0.4 are not only separate versions, but separate releases (instead of being two revisions from release "0").
Either type of release should compile and generally work (in theory). More testing and effort is put into validating stable releases. There are also "pre" releases like 0.4.22pre6. They were introduced late in the 0.4.x development cycle and are mostly intended for keeping developers in sync.
In the past, stable releases didn't have a third component. The next development after stable release X.Y would be X.Y.1. The obvious problem with this is that it doesn't leave any room for having new versions in a stable release. An example of the kind of problem this causes is the well-known bug described in question 3.4. For this reason, the next stable release after the 0.4.x development cycle will be 0.6.x, not 0.5. The development cycle after that will be 0.7.x.
This system is bascially be the same as the even/odd system used by the Linux kernel developers.
If that was just too confusing, you may find this table easier to understand:
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.
Yes, you can see the list at TODO or you can 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.
If you wish to install from source, the main web site has a file download section which is usually up to date. There is also a file archive on Mike's box. And as a last resort, Ross also puts recent releases on his CS account.
Daily snapshots of the source can also be found at the Anonymous FTP Space at sourceforge.
If you want an RPM, you can also find those on the main web site and Mike's page. Debian and *BSD packages are avaliable when installing those systems.
The 0.4 stable release has troubles compiling on recent glibc versions so I recommend not using it. 0.3 has so many features lacking that the only viable option is a recent 0.4.x development release. Typically development versions are ok to use. When 0.6.x is released, it should be the "default" install option for end users.
The bnetd configuration file can be found in conf/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(5) manual page found in the man subdirectory of the distribution for details on each possible setting.
This is due to a bug in bnetd-0.4.0 and some earlier versions. Basically the code is assuming that stderr is a constant but that is untrue on newer glibc systems.
There are several ways to fix it. The simplest fix is to change stderr to NULL at the top of eventlog.c and recompile. Upgrading to a newer version of bnetd also fixes the problem. The 0.4 series can not be patched because of the way the versioning scheme works. The new scheme does not have this problem.
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 conf/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 (try the nightly CVS build if you wish to test the fix before the next release).
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:
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
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 Battle.net 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 126.96.36.199 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.
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.