1) Wide deployment of a network stack or application has not been shown, per se, to provide reliable information on conformance or robustness. A few examples:

1 a) Maxwell has found non-conformance in Linux TCP/IP stacks, which are very widely deployed and open source.

1 b) The Maxwell tests have managed to crash versions of the Linux open source DHCPv6 servers.

1 c) In another case, Maxwell's tests revealed a flaw in a vendor's TCP/IPv4 stack causing it to crash its operating system. In this case the TCP/IPv4 stack was already embedded in a product in which millions of units had already shipped. (The discovery actually occurred during an on-site demo; the customer was actually interested in testing their up-coming IPv6 extensions and merely wanted us to prove how quick and easy Maxwell was to use by asking us to test against their existing IPv4 stack during the meeting. It came as a shock to them to have Maxwell find a fatal bug at all, never mind so quickly.)

(2) We know of no free software tools that perform stack robustness testing beyond trying a couple well known attacks. And none that attempt to do conformance testing.   An experienced software engineer could invest man-years of effort and expense developing a suite of tests large enough to develop confidence in the tested product  using a number of useful, free, open source development tools and frameworks.

(3) Maxwell Pro uses better algorithms than netem, so it does the correct thing for all types of traffic flows. For example, it computes the proper delay for each packet according to the requested bit rate and size of packet. Netem uses token bucket for rate emulation, which only yields correct average values over a large number of packets; on single isolated packets it can and will fail. The same is true for bit errors - Maxwell Pro corrupts bits while netem corrupts packets - the difference is significant when trying to test against traffic with varying sizes of packets.