The problem happens for bidirectional flows. The sequence of events is
as follows when you start Tx on Ports p1, p2 with the current code -
1. Clear stream stats on p1
2. Start tx on p1
3. Clear stream stats on p2
4. Start tx on p2
By the time #3 is executed, it may have already rx packets from p1 which
are being incorrectly cleared, this will cause these number of packets
to show up as dropped instead - incorrectly.
The fix is to change the order like this -
1. Clear stream stats on p1
2. Clear stream stats on p2
3. Start tx on p1
4. Start tx on p2
Unidirectional flows will not see this problem - as long as startTx is
done only on the Tx port and not the Rx port.
This bug is a regression caused due to the code changes introduced for the
stream stats rates feature implemented in 1.2.0
* No ugly #ifdef TURBO
* Turbo ports need to be specified explicitly in drone.ini
* If a port is not a turbo port, fall back to LinuxPort
* Turbo ports set their description as 'Turbo' which shows up in GUI
* Some XdpPort creation/destruction error checks
When building packets in interleaved mode, we do 2 passes over the
streams.
In the first pass, we build a number of lists of variables for each
**enabled** stream. One of these variables is the pktBuf content.
In the second pass, we use these lists to build the packets. If the
stream is not variable, we just use the packet content built in the
first pass. However, if the stream is variable we call frameValue to get
the packet content, but we index with the wrong value into stream list
if we have some disabled streams before us.
Fixes#328
For now both winpcap and npcap are supported with the latter being
experimentally supported till we get some feedback from users and
confirm that things are all working fine with npcap.
OID for link state has been changed to one that supports both.
To check which is being used, run 'drone -v'.
Fixes#236
The previous fix in 6977278654 was incorrect and incomplete since it
won't handle the case when emulated devices have PRIO and/or CFI/DEI
set.
This is the correct fix where Prio and CFI/DEI are no longer part of the
device key.
Device emulation packets are received and processed in a different
thread compared to the main RPC processing thread where the emulated
devices are created/deleted. No packets should be processed while the
latter is in progress otherwise the former may access devices that have
been deleted.
On some platforms and/or some libpcap verisons, libpcap doesn't support a
timeout which makes interactive stop not possible. So we now use a UNIX
signal to break out. Obviously this works only on *nix platforms - which
includes MacOS. For now the problem is not seen on Windows with WinPCAP,
so we should be fine. May need to revisit when we add Npcap support.
Fixes#215, #234
Enable logs if '-d' command-line option is given.
Additional command-line options -
-v : print version
-h : print usage
Drone only:
-p <port-number> : use given port number for the RPC service
