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
* Fix SA_SIZE definition for MacOS
* Use sdl_index instead of rtm_index as the ifIndex
* Remove the embedded ifIndex in link local addresses
* Extract default IPv6 gateway correctly
This better reflects the following -
RPC fail : complete failure of the RPC; no changes were made
RPC error: partial failure of the RPC; some changes were made, some had
errors
Currently these are printed at the end of init when we start waiting for
client connections - this was done so that this info doesn't get lost in
the barrage of init logs. The downside is if there is a crash during
init, we don't get to know the version/revision from the logs. With this
change this info is printed twice - first thing when we start and just
after init when we start waiting for client connections
errMsg used toLocal8Bit() which uses a temporary stack variable which
could go out of scope if the function is not inlined by compiler, so
avoid it by returning QString and use qPrintable
... instead of the PCAP returned description. This allows for a better
UX since user can more easily identify which port is which.
This will work only Windows Vista and higher since IPHLPAPI.DLL has
published APIs only for these versions. Older windows versions such as
XP will continue to use the PCAP returned description
Fixes#222
