Questions and Suggestions for Connection Emulator

A new Connection Emulator user here - have to say thanks to Andrew (technical support) for his great pre-sales help . I'm now using the Bridging mode with two USB-Ethernet adapters connected to a notebook, to achieve an easy-to-use and well-controlled test environment for a real-time audio-streaming product.

A few questions and suggestions about Connection Emulator:
Why is the Packet Loss Percentage slider limited to 50%? I realize >50% packet loss might not be generally useful, but I can imagine there could be occasional uses for statistical/random loss of more than 50%.
What do the colors on the Network Flow graph mean? I looked through the online manual and did some searching and couldn't find any explanation.

Some suggestions for product enhancements:
Add options to adjust both X and Y scales on the graph, plus update time. ie: be able to zoom in to certain areas of the graph.
Add option to export graph data to a file (csv, txt) for import into a spreadsheet so that the graph data could be presented in different ways.
Add an option to log packet flow through a bridged connection and identify dropped/delayed/duplicated/reordered packets.

Thanks!
Lance Carlson

Hi Lance,

Once again, thank you for your purchase and please see the answers below.

About the 50% packet loss limit
There no specific reason to limit the packet loss at 50%, in fact we went ahead with the update and changed the maximum to be 100% should that ever become necessary.

About Graph Colours
The graph uses three colours:

• Red. When only incoming traffic is recorded, it is painted as a red bar.
• Green. When only outgoing traffic is recorded, it is painted as a green bar.
• Orange. When both incoming and outgoing traffic are recorded, a part of the bar is painted orange and the top of that bar is either red or green, depending on which traffic prevails in that measurement.

This allows to see both In and Out traffic on a single graph.

About custom X/Y scales, zoom and export
There are a few settings available when you right-click the graph. Custom Y scale is already supported, so is moving back and forth. There's no zoom as such, so yes, this could be added.



Exporting is available through the Save command.

About logging
This is indeed a good idea. Do you think it would suffice to write everything to a standard libpcap/Wireshark capture file?
The only issue I foresee here is how to deal with dropped packets, perhaps write two logs (before processing and after processing)?

Hi Andrew,

Thanks for the information.

Exporting traffic in standard libcap/wireshark format would be really great. For me - especially in bridged mode.

If there were some way to include the dropped packets in the same export file but tag them somehow as "dropped", so that they could be filtered in/out as needed in a Wireshark display filter, I think this would be best, but alternately a separate export file would be OK too (so long as the timestamps are sync'd between the two files).

Maybe one way to tag dropped packets would be to give the user a dialog to choose a "replacement" IP source or destination address, something one would never see on the subnet being tested, and include wildcards in the user specification. Then in the export you could replace the dropped packet source, destination, or both with what the user chose.

For example, let the user specify 111.111.*.* as the source replacement. Then in the export all the dropped packets would show up with sources like:
Orig Source IP In Export Trace
192.168.3.37 111.111.3.37
192.168.3.241 111.111.3.241

In almost all cases the user would know precisely what source device the packet was dropped from because the last part of the source address remains the same, but the 111.111 is an easy-to-see (in the wireshark trace) marker for a dropped packet which can also be easily filtered.

Let the user define replacement rules for source, destination, or both in the dialog - blank entry means no replacement.

Let the user choose to not have the dropped packets included in the export also - give them a radio button in the replacement dialog...

Something like this would be a great addition to your software.

Thanks!

It's probably a better idea to indicate dropped packets by changing their MAC address, in this case we don't need to recalculate IP checksums.

We'll see what we can do, probably give a choice of one or two logs and how to indicate dropped packets. It appears that Wireshark has a built-in tool for comparing captures, in this case two log files should work perfectly, indicating major delays and losses.