Sendto pktinfo #101
Sendto pktinfo #101
Conversation
wrapper sendmsg() and WSASendMsg() Linux and Windows support IPv4 IP_PKTINFO. BSD, Linux, and Windows support IPV6_PKTINFO So far RTEMS and OSX, the extra sendto() overrides will be ignored.
|
While I hope this PR will be a practical no-op for the vast majority of hosts, I see a significant chance of some serious regression or interoperability issue. So this PR will likely "age" a bit until I can do (or receive) some test results with the various other PVA implementations (core.pva, pvAccessCPP/Java). So far I have done some interop testing with phoebus. |
| origin_t origin = Direct; | ||
| if(manager->ifmap.is_lo(rx.dstif) && dest.compare(lo_mcast_addr.addr,false)==0) { | ||
| // packet forwarded by a local PVA peer (maybe us) as IPv4 local multicast | ||
| origin = Forward; |
There was a problem hiding this comment.
@FreddieAkeroyd This is the change to detect a "forwarded" packet, arriving via a loopback interface, with the (multicast) destination address of 224.0.0.128. This is distinct from eg. a packet arriving by loopback destined for 127.0.0.1 or 127.255.255.255.
With this PR, it is possible to achieve the same effect as the Linux specific 127.255.255.255 in a portable way.
EPICS_PVA_ADDR_LIST=127.0.0.1 \
EPICS_PVA_AUTO_ADDR_LIST=NO \
./bin/linux-x86_64/pvxget from:ioc1 from:ioc2However, this will need some interop testing to make sure that other implementations treat this situation sensibly.
Better test of whether received packet was forwarded, based on OS provided meta-data instead of peer provided unicast flag. Also use ORIGIN_TAG (original destination) address as UDP source address if a local interface address.
mdavidsaver
force-pushed
the
sendto-pktinfo
branch
from
1200b72 to
7323794
Compare
|
Hi @mdavidsaver i tried this with a |
Could you try
I don't think so. |
|
While It looks like
|
|
With 127.0.0.1 address list: pvxget works fine pvget works but i get the following printed in the ioc log each time i run it pvlist, pvxlist work fine, no warning/error messages; - however just after printing all its output pvxlist pauses for about 5 second before giving the prompt back whereas pvlist gives the prompt back immediately after output With 127.255.255.255 address list: pvget works with same socket close error as above appearing in ioc log pvxget prints pvlists results in a pvxlist is like pvxget with warning at both client and ioc windows; the same 5 second pause as for 127.0.0.1 is present |
Attempts to address this situation encountered with p4p.gw epics-base/p4p#162 where a PVA client host is intentionally reachable by routes from multiple interfaces of a gateway host. Because PVXS binds UDP sockets to
0.0.0.0and[::], a SEARCH reply will currently be sent by the most direct route, which may not be the one by which the original SEARCH request arrived.This PR changes from
sendto()tosendmsg()with aIP_PKTINFOorIPV6_PKTINFOcontrol message specifying the requested outbound interface and/or source address.The source address for a message forwarded by local multicast is taken from the
ORIGIN_TAGmessage, when available and when an interface address. An interface index is looked up from this.Currently neither override is specified for non-unicast SEARCH replies, nor for BEACON.
This PR also changes the criteria for identifying a UDP message which has been forwarded by a local peer, even when a ORIGIN_TAG is not present. This is done by looking at OS provided interface and destination address, which I think can be trusted. This should also make it possible to distinguish traffic arriving over the loopback which has not be forwarded.
wrt. portability. All major IP stacks I looked at (BSD, Linux, Windows) provide
IPV6_PKTINFO.IP_PKTINFOis provided by Linux and Windows, but not BSD. So for RTEMS or OSX, a call tosendmsg()will be equivalent tosendto().@kasemir @FreddieAkeroyd fyi.