Hopefully the following questions and answers will prove useful.  If these don't answer your question, please send your question by email to This e-mail address is being protected from spambots. You need JavaScript enabled to view it .

We also suggest that you take a look at the list of known issues.

1. Why are there hundreds of protocol tests rather than hundreds of thousands?

   People who test protocols usually have schedules to meet.  Maxwell is designed to allow the operator to get a lot of test value out of a limited period of test time.

   It is rarely necessary to test every possible value of every protocol field.  For most protocol fields there are certain values that are likely to cause trouble, for example, zero, 1, -1, and values where a bit at a byte boundary goes from 0 to 1 or vice versa.

   Some test suites enumerate every possible every possible value.  This allows those suites to claim prodigious numbers of test cases.  However, it is almost always the case that all but a very few of those test cases are of very little, if any, value.

   For example, one might test every possible value of a TCP segment size, all 4,294,967,295 possible values.  But experience has shown that programmers are likely to make errors when the value is at 0, 1, 0xFFFFFFFF, 0x80000000, 0x0000FFFF, 0x00010000, or +/-1 one from those values.  In other words, problems are likely due to programmers who mistakenly use signed rather than unsigned arithmetic, who use 16-bit variables rather than 32-bit, or who do not properly calculate differences when one of the two values being compared has a high order bit set and the other value does not (for example when computing the effect of a TCP window wrap.)

   Maxwell does more than mere "fuzzing" of protocol fields.  Many of Maxwell's protocol tests split single packets into several packets.  For example, one of Maxwell's TCP/IP tests splits what is the typical FIN/ACK packet used when closing a TCP connection into a pair of packets, one with the FIN and another with the ACK.  Test suites that simply enumerate all possible field values do not do this kind of thing.

2. How were Maxwell's tests selected?

   Maxwell is based on years of real experience with protocol implementation.

   We have drawn upon the following sources for guidance about what tests would be useful:

   • Internet RFCs often highlight areas of concern by marking certain protocol aspects as "MUST", or "SHOULD".  Those are usually good things to test.  But even more useful are often those things that RFC's mark as "MUST NOT" or "SHOULD NOT".

   • Reports from security groups such as the CERT.
   • Anecdotes about protocol failures and penetrations.
   • Comments made by system crackers.
   • Observation of common programming errors, most notably the improper mixing of signed and unsigned arithmetic, the use of variables that are too-small to hold the range of data that may be loaded into them, inadequate attention to arithmetic in a wrapping number space, and opportunities for buffer overruns.

   We, of course, appreciate suggestions for new tests.

3. Why are my impairment settings not having any effect?

   The most frequent reasons why a user's settings are not having any apparent effect are these:

   • The impairment was applied to the other direction.  Each of Maxwell's "flows" is composed of a pair of impairment settings.  One of these settings establishes the impairments to be used on packets arriving on PORT0 and leaving via PORT1.  The other establishes the impairments to be used on packets arriving on PORT1 and leaving via PORT0.

   • The impairment was applied to a different flow than the one that the packets are flowing through.  Maxwell uses the user-specified flow specification to sort incoming packets into the various flows.  There are different impairment settings for each flow.

   A useful trick for isolating these kinds of problems is to go through all of the flows, and for the PORT0 to PORT1 (uphill) and PORT1 to PORT0 (downhill) directions and set the drop probability to 100%.  This should have the effect of stopping all traffic.  Then those drop settings can be removed, one by one, until the traffic resumes.  That should give a good indication of which group of settings is affecting (and not affecting) your traffic.

4. If a packet does not match a filter what flow does it go into?

   When a packet arrives it is compared against the packet specification for the first flow.  If it is a match, the packet is accepted into the first flow.  The packet matching stops when the packet is accepted into the flow.

   If a packet does not meet the flow specification for the first flow then the next flow is tried, and then the next, and the next, and so forth.

   If the packet runs the gauntlet and does not match the specification for any flow, the packet is discarded.

   For this reason it is often useful to set some obvious impairment - like a large delay - on both the uphill and downill sides of the last flow so that any packets that slip past the filter settings will be impaired in a way that is fairly easy to notice.

5. How do I use Maxwell with wireless?

   The easiest way to do this is to attach a wireless "access point" to either Port0 (eth1) or Port1 (eth2) on Maxwell.

   Some wireless base stations act as more than a mere access point - for instance many act as routers, firewalls, or network address translators.  In nearly every case you simply want to attach Maxwell to the wireless base station in the same way you would attach other wired devices that need to communicate with wireless devices.  Often this means attaching Maxwell to the "harmonica" of wired network ports found on many wireless stations that also include a built-in ethernet switch.

   Some wireless base station devices work under the control of a manager.  In these cases please feel free to discuss this with our support staff.

6. How do I use Maxwell with fiber optic Ethernet?

   We have had good luck using external copper-to-fiber conversion boxes such as the TRENDnet TFC-1000MSC Multi-Mode Fiber Converter with SC-Type Connector which is available from many on-line sellers, such as Newegg.  Other converters will probably work.

   Note: Some types of converter may lock link-state on the copper ethernet side to an "on" state without regard whether optical link state has been achieved.

7. Can Maxwell support High Definition television traffic?

   Maxwell can handle more than about 25,000 packets per second.  This is more than adequate to handle most forms of compressed HDTV traffic.

   For example, consider a compressed HDTV stream that of about 18,000,000 bits/second.  Most of these bits will be carried in full-sized packets of about 1500 bytes each.  That works out to about 1500 packets per second, well within Maxwell's packet per second capacity.

8. What about tagged VLANs?

   Maxwell supports tagged VLANs.

9. Can Maxwell limit bandwidth?

   Yes.

   Maxwell's bandwidth limitation mechanism are quite sophisticated.  Rather than using a typical token bucket queue, Maxwell takes into account several parameters, including, among others, data propagation rates, link distance, and frame encapsulation overhead.

   Maxwell's approach to bandwidth limitation is to compute when the last bit of a packet should arrive at the destination's network interface.  Maxwell holds the packet until that time and then releases it.  Because Maxwell generally is used in a lab environment in which Ethernet paths are virtually instantaneous, this approach yields a very good approximation of actual packet flow rates across a bandwidth limited network path.