The "Getting Bolo to work over the internet" challenge

[Scott Squires]

Well the greater issue I see is that each client contacts another client, so everyone connecting needs to be reachable by everyone else.

If it really does this "ring" method described in the dissertation, I'm not sure how a server would have been possible. It makes sense for an AppleTalk network. But hopefully a different protocol was introduced when UDP support was added. Looking forward to hearing your findings after you get a test network set up.

 

[olePigeon]

The tracker software is the part that we really need.  If anyone can source that, we'd be all set.

As a side note ... I seem to recall that the WinBolo tracker kinda worked in one way or another.  I don't quite remember in which way.  I think I remember BoloTracker being able to query the WinBolo server just fine and list games.  But I don't think the WinBolo tracker would track Mac Bolo games, though.  Nor would it forward IPs to allow you to connect.

Edit:  As a side note, I've both emailed and called / left a message for Stuart.  He never replied.

 

[olePigeon]

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

I'll send him an email if you like.  We're looking for the Tracker server software.  If he has a copy, then we could get it running and play some Bolo games.

 

[LaPorta]

For reference, here is a screen shot of the dialog box to input the info to broadcast a game to a tracker:

 

[Scott Squires]

The tracker software is the part that we really need.  If anyone can source that, we'd be all set.

How do you figure that the tracker software would solve things?

 

[CC_333]

For reference, here is a screen shot of the dialog box to input the info to broadcast a game to a tracker:

Said screenshot appears to be missing....

c

 

[olePigeon]

How do you figure that the tracker software would solve things?

It's essential for bypassing NAT since Bolo is dependent on a front-facing IP address to communicate.  You can still find old USENET groups discussing the server software.  As speculated earlier in the thread, it likely modifies the packets to include the real IP address, enabling the games to talk to each other.

 

[olePigeon]

 

[olePigeon]

So there's a Mike Ellis still on USU's faculty page.  I emailed him.  Hopefully it's the right Mike Ellis.  *crosses fingers*

Mark Ellis is still at Utah State.  Wrong person.    Darn it!

 

[olePigeon]

I found a Mike Ellis at Colorado State who had previously attended Utah State.  I emailed them.  It's a long shot.

 

[olePigeon]

Wrong Mike Ellis.  Shucks.

 

[LaPorta]

Sorry, the damn upload failed on the screen shot. I think a good deal of the info that the tracker gathered and displayed was in the packet itself, it looks like it in the network packet example that comes in the Bolo documentation.

 

[superjer2000]

View attachment 40554

I am coming into this a little bit less well-versed on the background of this thread than many of you here are, but looking at this it makes me think that the tracker is an optional step to allow others to join a game.  If two Macs were each directly plugged into a cable model and the IP address of one of them was entered into the above, I would assume the game would work without any issue.

Has anyone yet gone through the process to capture the packets of a Mac that is running bolo after the above has been entered and join has been pressed to see if the game is, in fact, embedding the local IP address (192.168.x) in the packets?  Is it possible that instead the firewalls that were in play when this was being tested earlier weren't actually configured properly to pass along UDP at the right port?

I would be happy to work with somebody to try to give it another go after making the relevant tweaks to open up and forward the relevant port.

 

[Scott Squires]

All the wording around the tracker implies that it is an outside service not in involved in hosting the game itself, just tracking games in progress. If it's not hosting the games then it can't rewrite packets.

However, I did find this, which would explain things. The tracker wouldn't rewrite any packets, it would just tell Bolo what address to put inside it's own packets (nubolo apparently used the same tracker protocol as original bolo):

It keeps a list of games and listens on port 50000 for UDP packets.  One is a request for the game list, which it then sends.  Another is a "what is my real IPort?" request from a nubolo client wanting into or starting a game.  Finally the tracker periodically pings game members to get the game stats needed to update the list.

https://groups.google.com/forum/embed/#!topic/rec.games.bolo/2myCvlYNyX4

 

[Scott Squires]

Has anyone yet gone through the process to capture the packets of a Mac that is running bolo after the above has been entered and join has been pressed to see if the game is, in fact, embedding the local IP address (192.168.x) in the packets?

Is it possible that instead the firewalls that were in play when this was being tested earlier weren't actually configured properly to pass along UDP at the right port?

LaPorta and cheesestraws did both of these already. I haven't verified myself, but I trust the result.

 

[cheesestraws]

Is it possible that instead the firewalls that were in play when this was being tested earlier weren't actually configured properly to pass along UDP at the right port?

No.  I was capturing on the far side of my edge firewall/router, in practical terms just after the ONT.  (Specifically, I have a port mirror set up on my core switch which can divert all traffic coming in and out from the Internet to an analysis box on which I can run packet capture stuff.  Yes, my home network is overcomplicated, I have a warped sense of fun).  I would not have made the claim if I did not have reasonable grounds for believing it to be true.

 

[LaPorta]

I am coming into this a little bit less well-versed on the background of this thread than many of you here are, but looking at this it makes me think that the tracker is an optional step to allow others to join a game.  If two Macs were each directly plugged into a cable model and the IP address of one of them was entered into the above, I would assume the game would work without any issue.

Has anyone yet gone through the process to capture the packets of a Mac that is running bolo after the above has been entered and join has been pressed to see if the game is, in fact, embedding the local IP address (192.168.x) in the packets?  Is it possible that instead the firewalls that were in play when this was being tested earlier weren't actually configured properly to pass along UDP at the right port?

I would be happy to work with somebody to try to give it another go after making the relevant tweaks to open up and forward the relevant port.

That's probably true. You could do direct IP to IP back in the day. The tracker just allowed people to find the game without knowing the IP. What mystifies me, however, is if the game continues after the original host quits, then WHICH player's IP is sent to the tracker, and which one is connected to? How does that work if the machines are all essentially in a ring that goes round and round?

 

[superjer2000]

No.  I was capturing on the far side of my edge firewall/router, in practical terms just after the ONT.  (Specifically, I have a port mirror set up on my core switch which can divert all traffic coming in and out from the Internet to an analysis box on which I can run packet capture stuff.  Yes, my home network is overcomplicated, I have a warped sense of fun).  I would not have made the claim if I did not have reasonable grounds for believing it to be true.

Thanks - cheesestraws - I'm just trying to wrap my mind around what's being confirmed here - It's that the firewall was properly configured to allow traffic through, or that you captured the packets pushed out by Bolo and confirmed they had the local IP address embedded?

 

[cheesestraws]

Definitely the former, pretty sure on the latter.  I will revisit the packet dumps when I have a chance to absolutely confirm.

 

[cheesestraws]

that you captured the packets pushed out by Bolo and confirmed they had the local IP address embedded?

To make sure this is the case, I just re-ran this test in a more controlled environment.  That environment was: two Basilisk II instances each using ethernet-over-UDP (so I didn't have to muck about with actual hardware).  Bolo running on both.  Machine 1 IP address 10.0.0.1, machine 2 10.0.0.2.  Wireshark running on the host of machine 1.

Here is one of the packets involved in the connection process.  Please disregard the extra framing: Wireshark doesn't know how to dissect the BII Ethernet Tunneling gubbins.  The Bolo packet payload starts, appropriately, with the word 'Bolo' (outlined in both the hex and the ASCII).



Below this, at $0060, you can see $0a $00 $00 $01 (outlined in green), which in decimal is 10 0 0 1.  This is the local IP address of the machine embedded in the payload of the packet and is why NAT breaks this game.