If you had a chain of packets being sent all at once, the latter
section of packets could be delayed, theoretically infinitely.
If queue1 was filled and enqueued for transmit, then queue2
had packets enqueued in it while queue1 was still transmitting,
we'd try to fill queue2 further rather than waiting for queue1's
transmit to finish.
However, in that case, we wouldn't check if we could transmit
queue2 again until the next packet. If the user application
was waiting for the response from something in queue2
before pushing more packets, it could hang indefinitely.
This also fixes a subtle bug where hitting the "not safe to try
to fit any more packets in this queue" limit would cause a
packet to drop, as it would be dequeued and then tossed.
Closes GH-42
The following fixups were added during the squash/merge:
Fix formatting in EthPhyMessage and EthPhyRegPacket
Device: Use std::make_shared when creating the EthPHYControl filter
Network: Create NetID String for EthPHYControl
EthPhyRegPacket: Constants in PascalCase
We need at least C++11.
If we're statically compiling into an application, we want to be using the same
CXX_STANDARD as it for ABI compatibility (particularly with icsneo::optional),
hence having the check around it.
Vehicle Spy 3 does this, it's a long-standing firmware idiosyncrasy.
Due to the way the device handles packets, this didn't cause a loss of
communication, only a "host to device byte" app error under certain
circumstances.
We need at least C++11.
If we're statically compiling into an application, we want to be using the same
CXX_STANDARD as it for ABI compatibility (particularly with icsneo::optional),
hence having the check around it.
Vehicle Spy 3 does this, it's a long-standing firmware idiosyncrasy.
Due to the way the device handles packets, this didn't cause a loss of
communication, only a "host to device byte" app error under certain
circumstances.
If an external project links to the icsneocpp target and pcap has
been installed in a non-standard location, the build will fail to find
pcap.h because PCAP_INCLUDE_DIR is not associated with the
target.
Closes#58
If an external project links to the icsneocpp target and libusb has
been installed in a non-standard location, the build will fail to find
libusb.h because LIBUSB_INCLUDE_DIR is not associated with the
target.
Closes#57
If an external project links to the icsneocpp target and pcap has
been installed in a non-standard location, the build will fail to find
pcap.h because PCAP_INCLUDE_DIR is not associated with the
target.
Closes#58
If an external project links to the icsneocpp target and libusb has
been installed in a non-standard location, the build will fail to find
libusb.h because LIBUSB_INCLUDE_DIR is not associated with the
target.
Closes#57
Description:
Possibly was an type - casting was done different structure.
Was not possible to determine or setup settings for ValueCan4 Industrial.
Whitespace fixed from the original commit
Co-authored-by: Paul Hollinsky <phollinsky@intrepidcs.com>
Paul Hollinsky
Kyle Johannes
Kyle Schwarz
Tomasz Ziobrowski
sbo79