mdavidsaver / pvxs

PVA protocol client/server library and utilities.
https://mdavidsaver.github.io/pvxs/
Other
19 stars 25 forks source link

Portable capture of destination interface and IP address #21

Closed mdavidsaver closed 2 years ago

mdavidsaver commented 2 years ago

Some OS dependent preliminaries which I think will be necessary to support search/beacon via IPv4 multicast in the pathological case of a PVA gateway, which would have to function as something like a multicast router, sitting at the boundary between several multicast "domains".

As I see it now, this can't be done portably without always binding to 0.0.0.0:5076. The usual trick of binding a pair of sockets to interface and broadcast addresses doesn't work since neither could receive multicasts. And winsock has no support for binding to the multicast address to receive only mcasts. So I think I'm left binding a single socket to 0.0.0.0:5076, and separating traffic myself. To do so PVXS would have to be able to distinguish which logical interface a packet has arrived by. I think this is possible, but requires resorting to recvmsg() and OS specific control messages to get the extra information.

These are IP_PKTINFO (Linux, OSX, Windows) or IP_ORIGDSTADDR and IP_RECVIF (RTEMS) to find the index of the logical interface through which a UDP packet was received, and the destination address from the IPv4 header.

@anjohnson A brief search leads me to believe that vxWorks has IP_ORIGDSTADDR and IP_RECVIF as well.

@FreddieAkeroyd If you have a chance, can you take a look at src/os/WIN32/osdSockExt.cpp.

Also, clear IP_MULTICAST_ALL on Linux to disable non-compliant legacy brokenness and receive only those multicasts we are interested in.

AppVeyorBot commented 2 years ago

:white_check_mark: Build pvxs 1.0.658 completed (commit https://github.com/mdavidsaver/pvxs/commit/475a3457be by @mdavidsaver)

anjohnson commented 2 years ago

The vxWorks-6.8 and 6.9 headers define IP_RECVIF but there's no sign of IP_ORIGDSTADDR. IP_PKTINFO is provided in both cases however.

FreddieAkeroyd commented 2 years ago

Hi, I noticed that IfaceMap::refresh currently adds both the assigned IP address and a 169.254 Automatic Private IP address to the list for some interfaces on my computer, probably not an issue. Did it matter if an adapter in the list was live or not? You could check iface->OperStatus & IfOperStatusUp if you only wanted active ones. Otherwise looks good to me.

mdavidsaver commented 2 years ago

iface->OperStatus & IfOperStatusUp

Ah, there it is. I was looking for IFF_UP.

mdavidsaver commented 2 years ago

Superseded by #22