As you can probably tell from the Github repo, work was started on the code a long time ago. Initally, a broadcast heartbeat could be sent, and a reply received. This in itself carried a small problem, owing to my limited experience in socket programming - a special permission must be used to successfully broadcast traffic. With that out the way, a simple heartbeat message (literally, the string "heartbeat") could be passed back and forth. At this stage, we're only one-shotting; there is no loop sending the packet repeatedly yet.

The next thing to try was with all 3 nodes. The last test used only 2. This exposed an issue that, in hindsight, should have been obvious - without extra processing, the heartbeat reply can only be received from one host. Something to add to the todo list. However, through multiple SSH sessions, I can confirm that both nodes set to receive did indeed receive (and reply to) the heartbeat. There is massive potential for race conditions here, and care must be taken when we work on this area of the code.

The next thing I tried was to read in the DHCP lease file. This was an absolute PITA. It wasn't hard, in any way, but owing to C's lackluster string processing capabilities, it took many more lines of code than it should, to parse a simple text database into an internal structure, and output it in a neatly formatted (kind-of) table. An exercise in patience, more than anything.

Now onto the issue we hit. After doing all of these, (DHCP client was enabled on wifi for the 2 nodes not acting as the active DHCP server), the next thing to do, or so I thought, was bridge wlan0 and eth0 together; this would simplify things later down the line, as it removes the requirement for NAT, which would make routing much harder. However, it brought issues of its own, namely, the fact that DHCP seems to want to go over eth0 rather than wlan0 (or both, as I thought it would, due to broadcast traffic). After almost 2 weeks of head-scratching, I stumbled upon a resource informing me that, for this to work, the macaddr option must be set in /etc/config/network, to the MAC address of wlan0. I do this, and nothing changes. It's then I notice that the MAC address of eth0 and wlan0 are the same, whether bridged or not. Damn.

There will be a solution, at least I hope, but for now, I've unbridged them, and will work like that. It's not ideal, but it's better than not having an IP on 2 of 3 nodes. One thing I haven't tried yet, and must at some point (as it is roughly how our software will work), is to use a static IP address, and then use the UCI tool (OpenWRTs network manager) to disable static IPs and enable DHCP. The reason this /may/ work, is that UCI may enable the DHCP client before it brings wifi online. I could be very wrong in this, but it would be nice if it were so simple.