Re: [PATCH] tidbits: net-udp: add server and client mode

Am 25.05.26 um 23:02 schrieb Hannes Diethelm:
> Am 25.05.26 um 18:51 schrieb Philippe Gerum:
>> Hannes Diethelm <[email protected]> writes:
>>
>>> Additionally, fix memory leaks
>>>
>>> Signed-off-by: Hannes Diethelm <[email protected]>
>>> ---
>>>   tidbits/oob-net-udp.c | 258 +++++++++++++++++++++++++++++++++++++++---
>>>   1 file changed, 240 insertions(+), 18 deletions(-)
>>>
>>
>> Merged, thanks. Would you mind sending a patch to update the related doc
>> on the website at [1], regarding the new -S mode? The pages can be
>> downloaded from [2].
>>
>> [1] https://v4.xenomai.org/core/net/udp-demo/index.html
>> [2] https://gitlab.com/Xenomai/xenomai4/website.git
>>
> 
> Sure, done. Is there any way to preview the website? I just used a markdown
> preview, I hope it did the job and I did not introduce format issues.
> 
> By the way:
> I had sometimes issues in my VM. It might just be that I am using two
> interfaces on the same subnet and disabled the non-oob one after
> enabling the oob mode on the other one or there might also be an issue
> somewhere in the evl code. I am not yet able to reproduce it clearly.
> Sometimes it is all fine, sometimes not. Until now, it did not happen on
> the real PC or in loopback mode. But I also don't have a good setup with 
> two
> PC's to really test this (yet). I will follow up when I have something 
> reproducible.
> 
> If it went wrong, the following happened. After a reboot, all was fine 
> again:
> In client mode, the sender address was from the wrong interface:
> 192.168.255.245 instead of 192.168.122.155
> 
> In server mode, the sender address was just 0.0.0.0.
> 
> In both cases, there is no answer from the other side due to the 
> response was sent
> to the wrong IP address.
> 
> I think the issue is not in my code, due to when I use the standard libc 
> functions
> in otherwise the same code, the issue disappeared. Attached the code I 
> was using
> for tests and also on the host to test server/client.
> 
> Regards
> Hannes

So, I was able to create something reproducible. I was a bit confused first
due to sometimes it worked, sometimes not. But this was my fault, not
rebooting before the test and not exactly using the same commands in the same order.

All command blocks below where performed after a reboot.

I have two network interfaces:
enp1s0: virtio
enp7s0: e1000e

After boot:
enp1s0: 192.168.122.246 nm 255.255.255.0
enp7s0: No address

First Scenario-------------------

The client works fine:
dhclient enp7s0 # 192.168.122.155 nm 255.255.255.0
ifconfig enp1s0 down
evl net -ei enp7s0
./oob-net-udp -d -i enp7s0 -a 192.168.122.1 -C -p 5201 -m "Client"

The server sometimes fails:
dhclient enp7s0 # 192.168.122.155 nm 255.255.255.0
ifconfig enp1s0 down
evl net -ei enp7s0
./oob-net-udp -d -i enp7s0 -a 0.0.0.0 -S -p 5201 -m "Server"

There is sometimes the error:
oob-net-udp: oob_sendmsg() failed: Operation now in progress
This goes away after a few tries and then it works afterwards.

If I bind to the interface address instead of INADDR_ANY, same issue:
./oob-net-udp -d -i enp7s0 -a 192.168.122.155 -S -p 5201 -m "Server"

Second Scenario-------------------

Here, I do not set an IP address for enp7s0. This was a mistake on my side. Disregard,
more careful testing showed the exact same behavior for posix / vanilla kernel. But it is
important for the third scenario.

ifconfig enp1s0 down
ifconfig enp7s0 up
evl net -ei enp7s0
./oob-net-udp -d -i enp7s0 -a 192.168.122.1 -T -p 2501

Here, the sender address shown in wireshark is 192.168.122.246. This is the address from enp1s0
that is disabled. Exactly the same for posix / debian kernel.

ifconfig:
enp7s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
         inet6 fe80::5054:ff:fe5a:79c5  prefixlen 64  scopeid 0x20<link>
         ether 52:54:00:5a:79:c5  txqueuelen 1000  (Ethernet)
         RX packets 15  bytes 960 (960.0 B)
         RX errors 28  dropped 0  overruns 0  frame 28
         TX packets 30  bytes 3332 (3.2 KiB)
         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
         device interrupt 22  memory 0xfdc40000-fdc60000

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
         inet 127.0.0.1  netmask 255.0.0.0
         inet6 ::1  prefixlen 128  scopeid 0x10<host>
         loop  txqueuelen 1000  (Lokale Schleife)
         RX packets 28  bytes 2672 (2.6 KiB)
         RX errors 0  dropped 0  overruns 0  frame 0
         TX packets 28  bytes 2672 (2.6 KiB)
         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Third scenario------------------

Setting an IP address after evl net -ei and the first package sent doesn't work. It looks like
the info is copied once and not updated later, also not when disabled and enabled
again.

The following does not work:
ifconfig enp1s0 down
ifconfig enp7s0 up 192.168.122.100
evl net -ei enp7s0
./oob-net-udp -d -i enp7s0 -a 192.168.122.1 -T -p 2501 # Fine, sender address is 192.168.122.100
evl net -di enp7s0
ifconfig enp7s0 192.168.122.110
evl net -ei enp7s0
./oob-net-udp -d -i enp7s0 -a 192.168.122.1 -T -p 2501 # Sender address is still 192.168.122.100, should be 192.168.122.110

This works:
ifconfig enp1s0 down
ifconfig enp7s0 up
evl net -ei enp7s0
ifconfig enp7s0 192.168.122.155
./oob-net-udp -d -i enp7s0 -a 192.168.122.1 -T -p 2501 # Fine, the sender address is 192.168.122.155

This also doesn't work and created the confusion:
ifconfig enp1s0 down
ifconfig enp7s0 up
evl net -ei enp7s0
./oob-net-udp -d -i enp7s0 -a 192.168.122.1 -T -p 2501 # Same behavior as in second scenario, sender address is 192.168.122.246
ifconfig enp7s0 192.168.122.155 #Note, setting the IP address is after the first package sent
./oob-net-udp -d -i enp7s0 -a 192.168.122.1 -T -p 2501 # Same behavior as in second scenario, sender address is 192.168.122.246
evl net -di enp7s0
evl net -ei enp7s0
./oob-net-udp -d -i enp7s0 -a 192.168.122.1 -T -p 2501 # Same behavior as in second scenario, sender address is 192.168.122.246
evl net -di enp7s0
ifconfig enp7s0 192.168.122.155
evl net -ei enp7s0
./oob-net-udp -d -i enp7s0 -a 192.168.122.1 -T -p 2501 # Same behavior as in second scenario, sender address is 192.168.122.246

Can you reproduce this? It is of now importance for what I am using EVL for. I just discovered this while testing the server / client mode.
So no urgency from my side.

Regards
Hannes