On 19.12.23 00:00, Maciej Żenczykowski wrote:
On Mon, Dec 18, 2023 at 1:00 PM Hiago De Franco <hiagofranco@xxxxxxxxx> wrote:
Hi,
Everything basically worked, without any freezing/slowness (please note
that during the test I wasn't using the VNC client, only the arping). I
also did it using screen with ssh/serial console disconnected.
Although I passed -U flag to arping, I still get replies. Is this
expected?
No. this defeats the purpose of the (since it's not unidirectional).
Perhaps -A would work better.
You could also probably pick an ip as the destination that isn't the
device on the other side of the cable, so that it *doesn't* respond.
The following seems to work for me:
while true; do sudo arping -c 1 -i $DEV -b 1.2.3.4; sleep 10; done
since nothing responds to 1.2.3.4 on my lan.
But Oliver's point about it possibly needing 10 or 11 queued packets
is also interesting...
though that would be very very weird...
Probably not 10 or 11 but more than 1. Sorry for being unclear. Let me
explain.
The timer should not run for an idle interface, should it?
Thus we have three situations
A - first network packet to be transmitted:
queue it and start a timer
B - further network packet to be transmitted:
queue it and modify the timer
C - enough network packets:
transmit
It seems to me that Hiago has just shown that A works. Lowering the threshold
also solves the issue, so C works. Case B seems to be the issue, yet the test
setup tests case A. That is my issue.
Regards
Oliver
