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 staggaring 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 hosted by are older and have more subscribers. The ones on SourceForge are nice because they are archived.

If anyone has a bunch of old bnetd-dev messages, please contact Ross so he can put together a historic archive.

list name	host	topic	traffic
bnetd	igateway.net	User discussion and announcements	very low
bnetd-dev	igateway.net	Development discussion	medium
bnetd-users	sourceforge.net	User discussion	very low
bnetd-announce	sourceforge.net	Announcements	very low
bnetd-devel	sourceforge.net	Development discussion	low

The igateway.net lists use standard Majordomo address and commands. To subscribe, you mail Majordomo@igateway.net a message with a single line like:
subscribe bnetd-dev myuser@myhost.com
It is best to avoid HTML-mail, quoted-printable, and base64 encodings when sending Majordomo commands (though it usually works anyway).

The sourceforge.net lists use GNU Mailman which allows you to subscribe with a web browser. See the list page on SourceForge for the subscribe links.

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:

• 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)

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:

0.3	stable
0.3.X	development
0.4	stable
0.4.X	development
0.4.XpreX	prerelease
0.5	nonexistant
0.5.X	nonexistant
0.6.X	stable
0.6.XpreX	prerelease
0.7.X	development
0.7.XpreX	prerelease

You can see the changelog here or you can look for the file CHANGELOG in the source tarfile. You can also read the latest version from the CVS Browser.

Yes, you can see the list here or you can look for the file TODO in the source tarfile. You can also read the latest version from the CVS Browser. The order of the items isn't 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.

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.

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 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 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 BNS.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 and Starcraft/Brood War 1.08 or newer, Diablo 1.08 or newer, or Diablo II then you are not alone.

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 is supposed to be able to handle it. Failing that, there are instructions for how to use rededit 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 those text fields.

Use the program BNS.exe, leave Battle.net checked, and choose Ok.