The "Getting Bolo to work over the internet" challenge

[cheesestraws]

I've been considering how to build a kind of plug and play retro VPN box for 68kmla users that would allow the creation of one big virtual IP and ideally AppleTalk network that people could just plug their retro machines into when they wanted and connect to a hub somewhere to talk to other MLA users.  But while I'm reasonably sure how to do it, in theory, I also don't have either the time or the health to take on maintaining an Internet service in my spare time right now.

 

[LaPorta]

Here are my thoughts: the original Bolo trackers did more than just track the Bolo games and relay that information. I would summise that they actually took the packets from each game, renumbered the incoming packet with the host's actual IP address, and then sent them on the way to the corresponding machines. Maybe that never happened, but I would think that would happen. If we could make a similar program to do that, today's internet throughput is so vast that the amount of traffic would be trivial. Perhaps easier than modifying Bolo would be to make a modern-day program that simply re-routes the game packets, and also shows games in play.

 

[cheesestraws]

Here are my thoughts: the original Bolo trackers did more than just track the Bolo games and relay that information. I would summise that they actually took the packets from each game, renumbered the incoming packet with the host's actual IP address, and then sent them on the way to the corresponding machines

That's a really sensible idea, actually.  I didn't think of that.

 

[LaPorta]

Something the Internet Bolo Buddy could connect to.

By the way, I’m effectively the “Steve Jobs” of this: I’ll have grand ideas and visions, but know nothing about programming or how it works.

 

[FunnymanSE30]

I'm no programer but, I see that winbolo has been made open source, also the documentation seems to suggest that modern networking was implemented, theres a client software and a server software. I wonder if the src can be modified to work on a 68k mac again. Or possibly a PC could serve a tracker anyways here's a link to the project's files, the main site seems to be down with Archive's snapshot being rather limited.

https://code.google.com/archive/p/winbolo/

 

[LaPorta]

If someone can make a Unix command line program I can run it on my Mac mini server.

 

[Scott Squires]

@LaPorta, I had been thinking along similar lines: I do think that the Bolo server was forwarding modified packets. If we figured out the packet format we could re-implement it.

Like @cheesestraws, I also have an idea for a "VPN appliance" (AKA Raspberry Pi) that would enable internet Bolo games. It could be a stop-gap to use before the network protocol is reverse engineered. Our ideas might be basically the same. I'm working on setting up a test environment for this idea.

 

[Chopsticks]

has anyone tried emailing stuart, the author of Bolo
StuartCheshire@apple.com

 

[LaPorta]

Yes. No one ever receives replies from him,  unfortunately.

So, here is what is probably a long-winded suggestion from me.

The program Internet Bolo Buddy worked very well, and was able to connect to different "tracker" servers over the internet (North America and Eurpoe are two that come to mine, one I think was bolo.abo.fi). That program can be re-directed to another server of our choosing via preferences. Since that is an already stable, known-good front end to what we are attempting to do that I would suggest that we turn our efforts to that. Setting up some sort of redirect machine on the user end would mean that every single person wanting to play Bolo would have to implement the same kind of solution, which is probably beyond what only the most haedcore Bolo followers would do.

Therefore, I would say that a program should be created that will exist on a server of some sort and take care of the following:

1. Field incoming Bolo tracker requests. There is a way to direct Bolo to specify what tracker it reports its game to in the preferences if I am not mistaken. Bolo can then send these requests to the IP of the server. My assumption is the server would be listening for these requests on a designated port.

2. Be able to accept incoming packets from a given IP, and re-create these packets exactly with the exception of replacing the designated internal IP with the internet IP that the machine sending the packets registers as.

3. Forward these modified packets to the receiving computers. Accept packets and modify them from each machine playing the game in the same manner.

4. Collate information from the hosting computer and present it to Internet Bolo Buddy in a meaningful fashion so that the tracker will correctly display the map name, number of players, game style, etc.

In brief, I believe that is what a program of this sort would need. I, for one, would be willing to host such a service on my Mac Mini server to be on most of the time here in North America. A European counterpart could be hosted by Cheesestraws or some other person.

Now that I have framed this out, anyone want to add or correct me at all? Plus, who would take this on?

 

[Scott Squires]

This is a case of the perfect being the enemy of the good. Do you want to be playing Bolo this week, or next year?

¯\_(ツ)_/¯

 

[LaPorta]

Well sure, we could just make it so we could play right now, but personally I'd be interested in making it so anyone, anywhere, anytime could play Bolo into the future.

That said, far be it from me to dissuade someone from just making a personal solution!

 

[Scott Squires]

I absolutely also want a server (or other similar user-transparent solution). My perspective is that I can quickly create a workaround right now. That doesn't stop us from also creating a replacement server. But that is a nontrivial project that I won't have time to undertake for several months. If someone else gets started before I get to it, that would be awesome. But in the meantime, there would at least be a way to play, for those willing to use a raspberry pi.

 

[LaPorta]

Best of luck! I am sure that it will be a huge step in the right direction. I am excited to see what you come up with.

 

[SuperSVGA]

Once I get home and on a 68k or PPC computer I'll take a crack at it.

I found some source code digging around online, but I'll have to experiment with it to see if any of it is useful.

 

[Scott Squires]

Great to have more eyes on it! Did you find anything beyond the snippet I posted a couple days ago?

https://68kmla.org/forums/topic/61483-the-getting-bolo-to-work-over-the-internet-challenge/?do=findComment&comment=665333

 

[SuperSVGA]

So I've done a bit of digging and found some of the answers, but also more questions...

First of all, the main problem seems to be that Bolo was designed poorly to only work with computers directly connected to the internet (this was quite common in the earlier days of the internet), not behind a router or firewall. 

4. Bolo.NetworkingFAQ

• "My Mac has no direct Internet connection. Can I write a Unix proxy for playing Bolo?"

No. Your Mac itself needs to be connected to the Internet. Bolo is not a client-server program and cannot easily be modified to connect via some other computer acting as its proxy on the Internet. Purists will argue that this is false -- anything is possible on a Turing Complete computer, given enough programming. They are right of course, but in this case, "enough programming" is enough to effectively connect your computer to the Internet, at which point it becomes easier to *actually* connect your computer to the Internet using existing software. You should also note that in order to provide sufficient real-time performance, the Bolo proxy could not be written as a user-level program, or even as a root-level program. On Unix, protocols like TCP/IP do not run as separate programs because they require accurate timing to work reliably, so they have to be compiled into kernel itself, and the same would be true of the Bolo protocol.

Here's another snippet I found which probably explains why connections are problematic today.

http://web.archive.org/web/20030620123025/http://www.lgm.com/bolo/guides/longfaq.html#netbolo

Unlike most other network games, Bolo is not a client-server system. Bolo forms a network of Macs by linking them in a ring where one player sends packets of game information to a neighbor, who in turn sends packets to the next neighbor on the ring, and so on. These packets are either DDP on AppleTalk or UDP over the Internet. When a new player joins, he sends a packet to each machine in the ring to figure out the delay between it and all Macs, then it adds itself into the ring in such a way as to minimize the total time around the ring. The advantage of a ring is its flexibility: nobody needs to maintain a server, and anybody can start or join any game. The disadvantage is that everybody is limited by the slowest connection in the ring. This is why it's a very bad idea for a modem player to join a game with direct ethernet players, because they must then continuously wait on the slow modem connection, resulting in lag which is characterized by jerky, unresponsive play or outright errors when the ring is broken and the game is frozen.

I've yet to figure out those internet games people mentioned worked. As far as I can see the tracking servers have nothing to do with this, they simply list games, but it's possible there's something going on behind the scenes that's built in to Bolo and not documented?

The nuBolo page has some interesting notes:

Using the external nuBolo game tracker (bolo.usu.edu, port 50000), it is now possible for players using Network Address Translation (NAT) firewalls to start games.

I'm fairly certain that's a standard Bolo tracker they're stating nuBolo is compatible with.

And a bit further down, a note about getting around other connection issues:

Fortunately, nuBolo has a built-in protocol called firewall tunneling that is designed get around such lists. In a nutshell, firewall tunneling works by getting all the computers involved in a nuBolo game (or those who wish to join a game) to send packets to each other, thereby getting themselves on any approved sender lists. When a new computer tries to join a game, it sends a special packet to the nuBolo game tracker, and another one to the computer already in the game. The game tracker then relays the request, and the node sends its own special packet to the person wanting to join. 

You also have to keep in mind nuBolo and WinBolo likely did not have access to the original source of Bolo so they are more clones than ports. I'm not sure how compatible they are with the original Bolo.

Here are some additional resources I've found while searching around:

BoloWeb, a 68k web server that gets running games from trackers and displays them on the Web.

I've archived a copy of it on GitHub:

https://github.com/SuperSVGA/BoloWeb

https://supersvga.github.io/BoloWeb/

An archived BoloWeb page listing running games:

http://web.archive.org/web/19990117023011/http://boloweb.stanford.edu:80/BoloWeb.ACGI

An article on Bolo from NetGuide in 1995:

http://www.bolo.net/O Bolo Mio, Steve Silberman, NetGuide Magazine, May 1995.pdf

Stuart Cheshire's Dissertation, may have some useful networking details:

http://web.archive.org/web/20030512180643/http://www.lgm.com/bolo/guides/dissertation/

Another Bolo FAQ:

http://web.archive.org/web/20030620123025/http://www.lgm.com/bolo/guides/longfaq.html

WinBolo Source, with tracker server source code:

https://github.com/kippandrew/winbolo

 

[History_SE30_Dude]

Not sure if this helps at all, Peter N Lewis (peter.lewis@info.curtin.edu.au) wrote a program called Bolo Finder that searched a tracker that was run by Mike Ellis. Perhaps if they can be contacted they might have some useful information. In the help document Peter Lewis provides several e-mail addresses. I'd e-mail him but wouldn't even know what to ask.

Alternative addresses (in order from best to worst) peter@cujo.curtin.edu.au peter@ncrpda.curtin.edu.au peter@rocky.curtin.edu.au peter@gu.uwa.edu.au

 

[cheesestraws]

And a bit further down, a note about getting around other connection issues:

There are two distinct connectivity issues going on here, and I think it's important not to conflate them:

1. Firewalls.  Port forwarding/opening is going to be essential to play Bolo, regardless, because of the bonkers overlay network stuff it does.
   
2. NAT.  Routers that don't use NAT will be fine; it's not a problem with routers.  It's a NAT problem.  This is not really due to the bonkers overlay network stuff; so long as port forwarding is set up, it should work fine so long as it is the apparent sending address in the packet that is trusted, rather than the one in the payload.  This actually is poor design, I'm afraid.
   

Stuart Cheshire's Dissertation, may have some useful networking details:

Oh, well found.  That looks like it has some fun information in it

 

[SuperSVGA]

There are two distinct connectivity issues going on here, and I think it's important not to conflate them:

Well the greater issue I see is that each client contacts another client, so everyone connecting needs to be reachable by everyone else. All the client’s would have to have a compatible networking setup, but possibly you might be able to get around this with an advanced relay to rewrite the packets and port forwarding on each client. 
Although NAT is part of the issue saying it’s just NAT doesn’t really get us to the right point.  I’m guessing the important part is finding out how it interacts with Port Address Translation(PAT)/NAT Masquerade, and if Source NAT might be part of the solution. 
 

Once I get enough time I’ll get a third client and some routers and do some testing. Unless I can find a reliable way to make them run in VMs, so I don’t have to climb around to touch each system with a dislocated shoulder. 

 

[LaPorta]

I can always do "offsite testing" whenever that is needed, as well.