(dspace link pending)
summary & reflections
Your newline-delimited Arduino serial data stream actually wants to be a sequence of network frames. You don't really care how the data gets to your host computer, how it's delimited, how it's framed, how it's buffered, what baud rate to use, how to bridge it between neighboring nodes: your application concerns are interpreting sensor data and sending control commands. But you're going to spend a lot of time and effort manually solving these problems anyway. It sure seems like something like IP over an existing link layer would be nice, since it solves all of this for you: these are actually core networking problems. The thesis develops multihop point-to-point IP networks over PPP on top of various serial links.
It partially gets there. It does what it says on the tin, but not much more — I actually spent most of my implementation effort reading, patching, debugging, and testing third-party embedded Rust code, which I found to be at a much lower state of readiness than I had anticipated when starting out. I trapped myself between "it's almost working" and sunk cost fallacy for a very long time, and so the networking results, analysis, and thesis writeup are as a whole anemic and underdeveloped. I probably have a whole additional thesis worth of writing about embedded Rust and considerations for designing firmware in the language (lots of reflection about allocation strategies, dealing with lifetimes, monomorphization vs dynamic dispatch, suggestions and sketches of new libraries), but this discussion didn't align with my committee or my proposed thesis plan, so it's largely left out from the manuscript. I will probably come back and organize those thoughts here.
In retrospect, what the thesis (qua networking thesis) actually wanted was a stable, battle-tested networking stack (e.g. lwIP) with an existing, bug-free PPP implementation and a distance-vector router (probably AODV). Likely I could have gotten things running way faster this way, and could have spent a lot more time investigating the actual networking concerns rather than debugging someone else's code. I'm happy with having used Rust, but probably this would have been more practical.