Depends on #7

Depends on #3

This should definitely be broken up into a few stories:

• Create TLV code
• Create marshalling/unmarshalling code
• Create protocol code
• Hook all this up to UDP (maybe at the same time as protocol code?)

This doubtless will involve some kind of cache of ARP info.

Depends on #7

• Figure out where to host it
• Discuss this with team
• Create it

As suggested by Lars Marowsky-Bree. Some of the unsafe blocks are far too large. It would be better to create smaller blocks which do only what needs doing, and one operation each. These smaller blocks would create more tasks to run between fork and exec.

• Discovery: result is JSON, exit code indicates unable to discover
• Monitoring: result is success/fail AND text (probably not JSON)

Ideally, this will work like the code in the old Assimilation code, but that’s not a solid requirement.

Depends on #7

Of course, reverse engineering open source software with some existing documents isn’t as hard as most reverse engineering wink.

The top level document for this activity is in the project wiki. It draws from two previous articles written long ago:

• RNNIGN protocol blog article
• Wire format document - on TypePad

Although these are not enough, they provide great fodder for how it works in some aspects.
They lack on explaining how startup and shutdown occur.

1. Standards for code creation (formatting, etc)
2. Standards for where to put documents (wiki??) - this may depend on the intended audience - developer versus end user, for example.
3. Standards for creating unit tests
4. Standards for tracking progress (should it be Trello, GitHub, other?)
5. Standards for communication

It is understood that this will change over time. That’s expected!

• Figure out where all the right places are (add to this item, or comments)
• Write general text
• Send the text out

Depends on #4 and #5

• Standards for code creation (formatting, etc)
• Standards for where to put documents (wiki??) - this may depend on the intended audience - developer versus end user, for example.
• Standards for creating unit tests
• Standards for tracking progress (should it be Trello, GitHub, other?)
• Standards for communication

It is understood that this will change over time. That’s expected!

On Linux the current C code does this without enabling promiscuous mode. The Rust code should do the same.

Create new version of Assimilation Nanoprobe in Rust.

Tasks

• #2
• #3
• #4