Re: [EVL] Client UDP not receiving data

Hannes Diethelm <[email protected]> writes:

> Hello
>
> I have issue porting an application that runs as an UDP client to OOB networking.
>
> The standard client pattern:
> -connect
> -oob_sendmsg
> -oob_recvmsg
> does not work.
>
> In Wireshark, i see the packages going out and returning with the correct ip/port
> but oob_recvmsg() doesn't return.
>
> To debug, I modified the oob-net-udp example, attached. Additionally, I ported it back
> to posix networking where it works as expected.
>
> Send only mode / receive with bind works well.
>
> Config:
> Debian Trixie
> linux-evl v6.12.y-cip-evl-rebase 569beef0
> libevl r57 877d5ca
>

I believe oob-net-udp does work as is, but not the way you seem to
expect it, which led your to change the original logic so that two
instances of this program always run head to tail, each one running a
sender+receiver loop.

The original intent was to implement half-duplex roles instead, starting
each instance either with the -S (send mode) or -R (receive mode,
default) option switch, in order to explicitly select a role.

This allows for more configurations, like mixing the network stacks to
use for testing. For instance, we are currently able to broadcast
packets to listeners on port #42042 over the wire from a vanilla linux
system (no evl) to an evl-enabled one, using VLAN-based selection of
packets:

/*
 * From the vanilla system, through VLAN device eno2.1
 */

$ echo -n "Hello world" | sudo socat - udp-datagram:255.255.255.255:42042,broadcast,so-bindtodevice=eno2.1

/*
 * From the evl system, listening to all oob interfaces using VLAN-based
 * packet selection.
 */

~# oob-net-udp -R -a broadcast
== receiver mode (<= broadcast:42042)
== bound to port 42042
= 11 bytes received: Hello world

With a different setup, we could connect two evl-enabled systems, like:

/*
 * From the first evl-enabled system, sending through eth1
 * to 10.10.10.11:42042
 */

~# oob-net-udp -S -a 10.10.10.11
== sender mode (=> 10.10.10.11:42042)

/*
 * From the second evl-enabled system, receiving from eth0,
 * bound to 10.10.10.11 on port #42042
 */

~# oob-net-udp -R -a 10.10.10.11
== receiver mode (<= 10.10.10.11:42042)
== bound to port 42042

This said, if you believe that a dual role setup like the one you
suggested would be nice to have to users as well, we could add it to
oob-net-udp alongside the existing half-duplex modes. For instance,
omitting the -R and -S keys on the command line currently defaults to
-R. Instead, we could select the new "dual role" mode.

PS: please send (diff context, -u or git-diff) formatted patches instead
of entire modified files, so that we can immediately grasp the essence
of the proposed changes. Also, please make sure to separate unrelated
changes sets in distinct patches (e.g. those changing a particular
aspect of the logic from others which may be coding style
fixups). Generally speaking, we follow the linux kernel coding style and
process when it comes to submitting patches [1].

[1] https://docs.kernel.org/process/submitting-patches.html

-- 
Philippe.