Jump to content

The "Getting Bolo to work over the internet" challenge


Recommended Posts

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.

Link to post
Share on other sites
  • Replies 97
  • Created
  • Last Reply

Top Posters In This Topic

6 hours ago, olePigeon said:

 

 

B2.gif.cba9066bd7b59357c1a146908a17f5a6.gif

 

 

 

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.

Link to post
Share on other sites

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

 

Quote

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 IP:port?" 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

 

Link to post
Share on other sites
4 hours ago, superjer2000 said:

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?

 

4 hours ago, superjer2000 said:

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.

Link to post
Share on other sites
4 hours ago, superjer2000 said:

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.

Link to post
Share on other sites
4 hours ago, superjer2000 said:

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?

Link to post
Share on other sites
4 hours ago, cheesestraws said:

 

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?

 

Link to post
Share on other sites
6 hours ago, superjer2000 said:

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

 

25707134_ScreenShot2021-02-09at20_45_01.png.989bb077ab754ae26e67554f0e99f87b.png

 

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.

Edited by cheesestraws
Link to post
Share on other sites
5 hours ago, cheesestraws said:

 

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

 

25707134_ScreenShot2021-02-09at20_45_01.png.989bb077ab754ae26e67554f0e99f87b.png

 

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.

 

That's awesome cheesestraws!!  

 

I wonder exactly how that is used?  I.e. When bolo wants to communicate with another machine I guess it takes the IP address from the packet instead of whatever header or other network information would typically be used?  If a bolo packet does make it back to another computer, I wonder if the client looks at the packet and confirms the IP address in the packet against the client as well?

 

For clarity: Would it be feasible to do a find/replace on these packets?  So in your case above, when System 1 sends out a bolo packet that has 10.0.0.1 in it, that gets replaced with the external IP.  So now System 2 sees the correct external IP and can get it's packets back to System 1's internal network.  But that packet still has the external IP address in it and so even though the router 'routes' it to Server 1 on the internal network, will Bolo ignore it because the IP in the packet (external) doesn't match System 1's internal IP?

 

That would require monitoring of packets going out and coming back.  

 

I also have no clue if it's as easy as just doing a find replace, or are there checksums that need to be recalculated as well?  Time to do a little bit more reading on this stuff.  I have very fond memories of all night Bolo LAN parties and would love to play again.

Link to post
Share on other sites
4 hours ago, superjer2000 said:

Would it be feasible to do a find/replace on these packets?

 

This is essentially what an ALG (Application Layer Gateway) does.  SIP, which is a popular protocol for VoIP, does something kind of similar, where the IP address of the SIP speaker is embedded into the data stream.  So a lot of especially home/office routers have SIP ALGs, which essentially replace the IP addresses on the way through.  My intuition is that the same approach would work here, though note that you'd have to do the same in each direction, so you'd have to replace the IP with the internal IP on the way in as well, because...

 

4 hours ago, superjer2000 said:

will Bolo ignore it because the IP in the packet (external) doesn't match System 1's internal IP?

 

Probably!  So you need to translate in both directions, same as you would in the packet header.

 

That said, that is only an intuition.  I haven't tried it.  But—Bolo does the same thing in AppleTalk, it embeds the DDP address in the payload.  bbraun's AppleTalk VPN thingy does precisely this, rewrites the DDP addresses in the packet payload to match the header when it does its kind of AppleTalk NAT trick, and apparently that works well enough to play Bolo over his VPN thing.  So my bet is that that strategy would work with IP as well.

Link to post
Share on other sites

There is a Linux program called Mallory that at first glance seems to have be ability to modify UDP packets on the fly with a find replace type function. 
 

I haven’t looked too far into this but it might be an option to route Mac traffic to a Pi and change the relevant parts of the UDP packets. 
 

Is this along the lines of what @anthon was considering?

Link to post
Share on other sites
4 hours ago, olePigeon said:

Would everyone need to do this?  Or only the person hosting?

 

There's no such thing as "hosting", because Bolo is weird.  There's no client-server here.  Instead:

 

The players in a game are arranged in a logical ring, around which messages are passed.  Kind of like a bus network; a message is received from one neighbour, you act on it, and forward it to your next neighbour.  I assume that if your own packet returns to you you just drop it on the floor.

 

When you join a game by giving the IP address of a node playing, every other player in the ring measures their latency to you and you get inserted into the ring somewhere where you will have the lowest latency to your neighbours.  So every player node needs to be able to talk to any other player node, because as the ring grows and shrinks as people join, you might find yourself needing to communicate with totally different computers.

 

So everyone needs to be emitting packets onto the Internet with the right IP addresses in, which means that everyone needs to be doing the packet rewriting.  Alternatively, you could have a central proxy that would create a "pretend" ring and act like a switching point in the overlay network.

 

If you think this sounds mad, it sounds mad to me too.

Link to post
Share on other sites

Sorry, I bounced my idea off cheesestraws for sanity checking but didn't post the details here. My idea was for all the Bolo players to join a virtual private network. Then there would be no NAT and Bolo would work. The Raspberry Pi would act as the VPN gateway (since a retro Mac has no hope of running VPN software).

 

But based on some information from the nubolo develolper on the rec.games.bolo usenet group, it sounded like there might be functionality for a tracker to tell Bolo what IP address it should use in its packets. Since that would be an easy development task compared to a server, and only require operation of a central tracker not a network appliance on everyone's premises, I did some investigating into that. It turns out that nubolo and Bolo use entirely different tracker protocols. Apparently the bolo.usu.edu tracker server supported both.

 

During that investigation, I ended up with enough info that I thought it might not be too much effort to implement a proxy server. So currently a friend and I are working on reversing the network protocol. Everyone would connect to the proxy server as the "host" machine, and it would forward all the packets to the individual players, re-writing ip addresses as needed.

 

cheesestraws helped me devise a network setup for testing with Basilisk II. But since Basilisk II's networking is so kludgy, I wasn't 100% sure I wouldn't spend days getting it working, so instead I set up a physical test environment. Turns out I don't actually own a network hub anymore (now I have ordered one from ebay), so in order to snoop traffic I had to set up shop outside my network closet with all the bolo computers connected directly to my core switch. That way I can use the switch's monitoring port to capture traffic.

 

Bolo protocol reversing in progress:

 

PXL_20210211_003731893_crop.thumb.jpg.e7441159367221a6993a027d5a91d552.jpg

Link to post
Share on other sites
4 hours ago, olePigeon said:

But if everyone needs a forward-facing IP, then that answers my question.

 

Yup - as I understand it, the place you get put in the ring has basically nothing to do with what IP you join to, if that makes sense.  So all the other players need to know your public IP, and you need to know theirs, because you could end up with any of them as neighbours.

Link to post
Share on other sites

What kills me is that if the source code for bolo was public it would likely be pretty trivial to add a text box to enter your external IP address and embed that into the packets being sent rather than your macs internal IP address.  The code would then also look for that external IP address rather than the internal one on received packets. 
 

the nubolo guys said they built there game on The bolo object code. I’m not sure exactly what they mean by that - ie they disassembled it or they had access to the source code?

Link to post
Share on other sites
4 hours ago, superjer2000 said:

object code. I’m not sure exactly what they mean by that - ie they disassembled it or they had access to the source code?

 

'object code' usually means the output of compilation (e.g. the traditional .o suffix on binary files compiled from C).  So I'm guessing they mean the binaries here.

Link to post
Share on other sites
4 hours ago, cheesestraws said:

 

'object code' usually means the output of compilation (e.g. the traditional .o suffix on binary files compiled from C).  So I'm guessing they mean the binaries here.

Agreed but how would that help them to port the game to a totally different processor?

Link to post
Share on other sites

Nubolo claims they examined the original Bolo code to figure out game mechanics: tank acceleration, firing rate, pillbox firing rate based on health, various timers, etc. In Winbolo, those various mechanics were just made-up and did not match Bolo.

Edited by anthon
Link to post
Share on other sites

Correct me if I am wrong (I am not a programmer of any sort), but it seems like from what you are saying is that there isn't really a reliable way to centrally do this. Each and every machine has to send out modified packets?

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...