Re: [MirageOS-devel] Concerning testing network protocols

[Luke Dunstan <lukedunstan81@xxxxxxxxx>]

On 28 March 2015 at 01:29, Richard Mortier <richard.mortier@xxxxxxxxxxxx> wrote:
> On 27 March 2015 at 17:17, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>>> 1. Split all wire format de/serialization code out of each protocol
>>> into a distinct library. Link against this library in both
>>> `pcap-format` and `ocaml-<protocol>`. Unit test the protocol
>>> implementation separately (perhaps via property-based testing which
>>> might not require a separate implementation, perhaps relying on
>>> completely distinct implementations like `libpcap`).
>>
>> This one sounds best to me.
>
> Good -- it's probably my preferred one too. Guess it would mean
> creating `x` and `x-format` (and perhaps `x-unix` to capture the
> values that convert files to streams of captured packets) for x =
> pcap, tcpip, dns, etc etc; and then a separate `trace-analysis`
> library or something...
>
>> Although, it sounds like there's a
>> certain amount of feature creep going into pcap-format.
>>
>> Why not just parse the raw pcap format in pcap-format, and have a new
>> pcap-format-analysis library that depends on both pcap-format and ocaml-dns?
>
> Not sure what you mean. What was the intended feature set of `pcap-format`?
>
> The first version of `pcap-format` parsed the PCAP container format,
> Ethernet, IP, TCP from Unix files iirc.

The version of pcap-format that the ocaml-dns unit tests were written
against only supported the PCAP container format in its interface:

https://github.com/mirage/ocaml-pcap/blob/d3f127d160c0f484a9364a25f274926b7a416ab7/lib/pcap.ml

The print.ml program supported Ethernet, IP, and TCP structs (not UDP)
and printing, but those weren't exposed.

>
> I hacked about to add some more, but then stopped doing that and
> started trying to use existing implementations, starting with
> `ocaml-dns` as that seemed easier than trying to use `tcipip` to cover
> TCP and IP (and Ethernet?), and I wanted a `libpcap` lookalike for
> Mirage.

Sounds good.

>
> Are you suggesting
>
> 4. Strip `pcap-format` back to just the PCAP container parsing code,
> and create `pcap-format-analysis` as a separate library?
>
> In which case the same problem will arise as I believe the current
> unit test code in `ocaml-dns` will end up relying on
> `pcap-format-analysis` as currently posed. (Presumably the point being
> to use an independent implementation of the wire format parsers to
> unit test the `ocaml-dns` implementations.)

The ocaml-dns unit tests needed Ethernet, IP, and UDP structs (not
pretty printing), so those ~50 lines of code was copied and pasted
from print.ml as a temporary solution. So yes, if the packet structs
for UDP and lower layers were moved to pcap-format-analysis then the
DNS unit tests would have to continue to duplicate them to avoid a
circular dependency.

On the other hand, if the transport layer was available as
tcpip-format and pcap-format was doing nothing but PCAP then the DNS
unit tests could depend on those two packages. Then
pcap-format-analysis would be free to depend on ocaml-dns (or
dns-format).

I am imagining that pcap-format-analysis would mainly be the glue that
figures out which x-format libraries to call based on port numbers (if
not overridden by the user). It would also be doing the top-level
pretty printing, while x-format libraries would still implement
to_string functions, like Dns.Packet does.


Luke

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel