Questions and Suggestions for Connection Emulator
Started by lrc
Questions and Suggestions for Connection Emulator 20 May 2015, 03:23
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.
Re: Questions and Suggestions for Connection Emulator 20 May 2015, 13:37
Registered: 12 years ago
Posts: 5 589
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 I went ahead 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.
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.
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)?
Re: Questions and Suggestions for Connection Emulator 21 May 2015, 00:38
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
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.
Re: Questions and Suggestions for Connection Emulator 25 May 2015, 13:22
Registered: 12 years ago
Posts: 5 589
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.