On Tue, Dec 19, 2023 at 12:45 AM Oliver Neukum <oneukum@xxxxxxxx> wrote: > > > > 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. Perhaps. I've been looking at the gadget tx code, and assuming hrtimers work, I don't see how it could possibly screw up... the hrtimer arm/cancel are clearly at the same spot in the code where we allocate/unqueue the ncm->skb_tx_data (I have found a potential use-after-free-on-error bug and a stupidity that I'll send fixes for, but that doesn't appear related to this thread) But the host side driver seems more complex/confusing. However, I've not really ever looked at it previously though, so it might just be that... Maybe there's some case where we end up with no timer and queued packets?? Haven't found it yet though... > > Regards > Oliver
