anthon

Wireshark has a Lua API that you can use to write "packet dissector" plugins. Wireshark sends your Lua plugin the raw packet buffer and you tell Wireshark what it means.

Status update. I have written the network proxy code that can rewrite packets as they pass between players. At first I just implemented the packets that have a fixed position format. This worked surprisingly well. There are at least two issues. One is when players leave, one of the opcode-based packets tells the ring how to adjust itself to remove the player. In that situation, the ring sometimes gets messed up depending on who leaves. The other issue I'm not sure exactly how it arises, but sometimes the Network Info dialog (for a player other than the one to start the game) will show the firs

Please by all means feel free to do this modification, should you wish to. I agree, it would be awesome if gcp would implement this.

We can add tracker functionality to the proxy. Right now I'm just focused on getting the proxy to work for a single game. Then we can make it support multiple games. For tracking, maybe just start with a web page. The utility:effort ratio decreases significantly at this point, because I don't expect a lot of active games at once.

It lives up in the clouds! I plan to host it on my server. But it will also be open source, so anyone could run their own proxy.

Right. The proxy essentially converts the protocol into a client-server model. Every Bolo instance sends and receives its packets to/from the proxy. This will have repercussions in the form of increased latency. But it has a side-benefit of possibly not requiring port forwarding. Here's a diagram comparing normal Bolo networking and Bolo with a proxy:

The problem with doing "search and replace" on the UDP packets is that the 4 bytes that represent a player's IP address can also completely legitimately be game data. Blindly replacing that data will cause infrequent but infuriating bugs. The simplest thing to deal with would have been packet types that contain data in a fixed-position format. Unfortunately it's rather more annoying than that, but we're making good progress on it. Aside from bus order negotiation and exchanging game map and status data upon joining, all the events in the game are transmitted using Bolo packet id 2.

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.

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

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

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

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

I don't think Hackaday pretends to be traditional journalism. The internet is going to internet. It will make more people aware of your project and that's a good thing.

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.