Re: [EVL] Client UDP not receiving data

Am 23.05.26 um 10:42 schrieb Philippe Gerum:
> Hannes Diethelm <[email protected]> writes:
> 
>> Am 22.05.26 um 17:40 schrieb Philippe Gerum:
>>> Hannes Diethelm <[email protected]> writes:
>>>
>>>>
>>>> Thanks for the detailed answer. I might have been not precise enough.
>>>>
>>>> The -S and the -R mode work as designed. To show the issue with connect() in evl, I changed
>>>> the -S mode to:
>>>> connect()
>>>> while{
>>>>     oob_sendmsg()
>>>>     oob_recvmsg()
>>>> }
>>>>
>>>> This is the classical UDP client pattern. It works with vanilla linux (net-udp.c)
>>>> but not with evl (oob-net-udp.c), I do not receive any data.
>>>>
>>>> By just sending the modified code, it is easy to explain and hopefully for you to
>>>> reproduce. This is also why I attached the files instead of sending a patch.
>>>> Be aware that this is just to demonstrate what is not working, not intended as a patch.
>>>>
>>>> I run Xenomai4 in a VM and communicate with the host for debugging
>>>> but I have also a real PC as the final target where I have the same issues.
>>>>
>>>> First start on the host:
>>>> echo Hello | nc -u -l 5201
>>>>
>>>> Then in the VM:
>>>> sudo evl net -ei enp7s0
>>>> sudo oob-net-udp -d -i enp7s0 -a 192.168.122.1 -p 5201 -S
>>>>
>>>> On the host:
>>>> Mellow sword!
>>>>
>>>> In the VM:
>>>> == bound to enp7s0
>>>> == sender mode (=> 192.168.122.1:5201)
>>>> --------tx--------
>>>> IP-Adresse: 192.168.122.1
>>>> Port:       5201
>>>> Family:     512
>>>> --------rx--------
>>>> IP-Adresse: 192.168.122.155
>>>> Port:       58422
>>>> Family:     512
>>>>
>>>> The package is visible in wireshark but oob_recvmsg does not return:
>>>> No "= 6 bytes received: Hello" and no second transmit.
>>> Ok, I totally misinterpreted your previous post, sorry for
>>> that. Brain received -ENOCOFFEE.
>>>
>>>>
>>>> It looks like the auto assigned and bound port from connect() is not forwarded
>>>> to the oob stage, so no data is received in oob_recvmsg().
>>>>
>>> This is exactly the point, indeed. Could you please try this branch
>>> [1]?
>>> The two commits on top improve the situation with your test code here.
>> Thanks for the very fast fix. Connect works now as expected. And I was able to remove the workaround.
>>
>> I switched to libevl r58, r57 did not work any more. Is there any visible link libevl->kernel? I just
>> got an operation not permitted in oob_sleep_until.
>>
> 
> Recent evl ABI updates are likely causing this, r58 is required to run
> any kernel with ABI #44. Every single change affecting the ABI also used
> to cause its revision number to be incremented, hence the seemingly high
> value (implementing the evl core started back in 2018). The model has
> recently switched to bulk updates instead, i.e. a series of ABI updates
> under a single revision.
> 
> On the kernel side, the file include/uapi/evl/control-abi.h tracks the
> base/earliest and current ABI revisions the evl core supports, such
> decoupling helps in providing backward compatibility from the latter to
> the former, e.g. if EVL_ABI_BASE is 30 and EVL_ABI_LEVEL is 45, then an
> application which was compiled against any ABI level >= 30 can use this
> core. Looking at include/evl/version.h in libevl, you should see the
> symbol EVL_ABI_PREREQ set to the earliest ABI revision that particular
> version of libevl can work with, i.e. matched to EVL_ABI_BASE.
> 
> A recent string of ABI changes went in to support the upcoming POSIX
> interface, they have been grouped in a single update which triggered ABI
> #44. That one was going to break backward compat as I hinted at a couple
> of months ago, aligning EVL_ABI_BASE on EVL_ABI_LEVEL to #44.
> 
> The development tip for each kernel is now hosted in some next/* branch
> in the repo, e.g. next/v6.12.y-cip-evl-rebase, which contains staging
> code until it moves to the rebase/ branch,
> e.g. v6.12.y-cip-evl-rebase. The next/* kernel branches match the libevl
> -next branch ABI-wise.
> 
> IOW, in order to work with the bleeding-edge code implementing any
> recently discussed changes, you may want to switch to libevl/next and
> any next/* branch on the kernel side (v6.12.y-cip-evl, v6.18.y-evl, or
> v7.0-evl ATM).
> 

Thanks for the details. For now, libevl r58 works well with next kernel but I will go to next on both
repos if I see any issues and test it there also before reporting them.
The inegrated check works if I go back to r57 with a small test program:
evl: ABI mismatch, see -ENOEXEC at https://v4.xenomai.org/core/user-api/init/#evl_init
./oob-net-udp: cannot attach to the EVL core: Exec format error

I think I just had so many error messages that I did not see ^ in the real application.

>> But there are two new issues:
>>
>> -oob_sendmsg returns "Invalid argument" errno 22 exactly every second. The last number is the
>> system time in ns.
>> ERROR: oob_sendmsg Invalid argument 22 806999652287
>> ERROR: oob_sendmsg Invalid argument 22 807999655503
>> ERROR: oob_sendmsg Invalid argument 22 808999650416
>>
>> I have this with the exact same code as before using bind() and also with the now working connect().
>> There are 3000 tx / 1000 rx packages/s.
>>
>> I tried do{oob_sendmsg}while(errno == 22) but that resulted in a full freeze of the PC.
>>
> 
> Sounds like an ABI issue, I cannot reproduce this. Switching to the
> 'next' branches on both sides may help.

This was an -ENOCOFFEE on my side. I was using:
evl_read_clock(EVL_CLOCK_MONOTONIC, &ts_timeout);
ts_timeout.tv_nsec += 1000*1000;
...
oob_sendmsg(board->sockfd, &msghdr, &ts_timeout, flags);

Of course this overflows tv_nsec exactly every second. It seams you or some else verifyes this now
and return "Invalid argument".

With this, everything works now:
evl_read_clock(EVL_CLOCK_MONOTONIC, &ts_timeout);
ts_timeout.tv_nsec += 1000*1000;
while(ts_timeout.tv_nsec >= 1000000000){
     ts_timeout.tv_nsec -= 1000000000;
     ts_timeout.tv_sec ++;
}
...
oob_sendmsg(board->sockfd, &msghdr, &ts_timeout, flags);

> 
>> -The last commit a4cc7967 on the next branch doesn't compile. Just FYI, I took one commit before, so I was able to test it.
>>
> 
> My bad, fixed in the kernel next/* branch.
> 
>>>>
>>> I think we need a simple agent somewhere in the evl netstack in
>>> kernel
>>> space answering ICMP_ECHO requests flowing in oob channels directly,
>>> just like the in-band stack does for in-band traffic. I can look into
>>> this.
>> The oob-net-ping sends out pings, so basically the inverse of the existing oob-net-icmp. Now you can run
>> oob-net-ping on one machine and oob-net-icmp on the other to ping between. For my application, I use it to ping an FPGA
>> board to see if the connection basically works.
>>
> 
> Ok, makes sense too. I'm ok with both approaches actually, it's your call.
> 
>> ICMP_ECHO would help in some cases, but ^ works also.
>>
> 
> Agreed, we need a built-in ICMP_ECHO responder in the core, which we
> could disable programmatically as well, so that a ping service
> implemented in userland which would use the raw packet interface may
> switch it off for receiving ICMP requests.
> 
Ok, I will send a patch as soon as it is ready. Can take some time, depending on what is going on otherwhise.