Added extraction of IP_PKTINFO when reading and setting it when sending back #456
Conversation
…very source. CHECK ON MAC PENDING.
ethouris
added
Priority: High
Type: Enhancement
|
This PR requires to be tested for whether it adds any performance penalty. |
CMakeLists.txt
Outdated
| @@ -144,6 +148,7 @@ option(ENABLE_HEAVY_LOGGING "Should heavy debug logging be enabled" ${ENABLE_HEA | |||
| option(ENABLE_HAICRYPT_LOGGING "Should logging in haicrypt be enabled" 0) | |||
| option(ENABLE_SHARED "Should libsrt be built as a shared library" ON) | |||
| option(ENABLE_STATIC "Should libsrt be built as a static library" ON) | |||
| option(ENABLE_PKTINFO "Enable target IP address extraction on listner" ${ENABLE_PKTINFO_DEFAULT}) | |||
There was a problem hiding this comment.
| option(ENABLE_PKTINFO "Enable target IP address extraction on listner" ${ENABLE_PKTINFO_DEFAULT}) | |
| option(ENABLE_PKTINFO "Enable using IP_PKTINFO to allow the listener extracting the target IP address from incoming packets" ${ENABLE_PKTINFO_DEFAULT}) |
There was a problem hiding this comment.
Maybe just use OFF here?
There was a problem hiding this comment.
We may decide in the future to turn it to ON on all supporting platforms, and this way it will be only OFF on platforms that do not support it.
Note also that this IS supported on Windows, just the procedure of sending and receiving UDP packets is using a function that doesn't allow the use of CMSG. To enable that it would have to be reimplemented.
| // XXX Unknown why this has to be off. RETEST. | ||
| //::setsockopt(m_iSocket, IPPROTO_IPV6, IPV6_V6ONLY, &off, sizeof(off)); |
There was a problem hiding this comment.
I found this line in the old implementation that was there years ago. Unsure what this was about. Left for a case when someone finds a problem on IPv6 using it.
| Note that this feature is available only on certain platforms. Notably the BSD | ||
| systems are known to not provide this feature and the current implementation | ||
| doesn't support this feature on Windows systems. |
There was a problem hiding this comment.
| Note that this feature is available only on certain platforms. Notably the BSD | |
| systems are known to not provide this feature and the current implementation | |
| doesn't support this feature on Windows systems. | |
| Note that this feature is not supported on BSD or Windows systems. |
There was a problem hiding this comment.
By treating these systems differently in the description I wanted to highlight the fact that in BSD systems this feature really isn't implemented and there's no known way to implement it, while in case of Windows it is possible, but the API used currently for sending and receiving UDP packets does not allow the use of CMSG messages. Such an API exists, so for Windows this would only require changing the API functions used for sending/receiving (use WSASendMsg instead of WSASendTo etc.).
There was a problem hiding this comment.
| Note that this feature is available only on certain platforms. Notably the BSD | |
| systems are known to not provide this feature and the current implementation | |
| doesn't support this feature on Windows systems. | |
| Note that this feature is not supported on BSD systems. On Windows systems it is possible, but the API used currently for sending and receiving UDP packets does not allow the use of CMSG messages. Such an API exists, so for Windows this would only require changing the API functions used for sending/receiving (use `WSASendMsg` instead of `WSASendTo` etc.). |
There was a problem hiding this comment.
Well, I wouldn't go into such details - maybe this way:
Note that this feature is not supported on BSD systems (not possible due to lacking IP_PKTINFO feature). On Windows it is theoretically possible, but currently not implemented.
Co-authored-by: stevomatthews <smatthews@haivision.com>
|
@ethouris Note AppVeyor build failures. |
Co-authored-by: stevomatthews <smatthews@haivision.com>
This fixes the problem that is caused by sending back packets in response to a caller's connection request with the IP address that happens to not be the address from which the caller's packets have come. This made the caller confused as it received the response from different IP address than to which it has sent, and recognize this as an attack attempt.
This case happens when you have more than one local IP address that refers to the same network, and your listener socket is bound to "any" wildcard (
INADDR_ANYfor IPv4 andin6addr_anyfor IPv6). In this case the source address of the packet being sent through such a socket might be different than the destination address to which a packet was sent to this socket.The source address is selected by first extracting the network broadcast address from the destination IP address, then the source IP address is chosen through the routing table, as assigned to this network broadcast address. So if there is more than one IP address matching this network broadcast address, only one of them will be selected as the source address and this won't necessarily be the right one.
The assignment of the target IP address to a particular connection session is the SRT logics about which the system has no idea. This fixes then the problem by reading the target IP address from the incoming UDP packets, and then this address is passed down the path in the
CPacketobject. When the accepted socket is created, this address is recorded in the socket for permanent use, and then it will be passed to the channel when sending.This whole procedure will not be used in case when the socket is bound to an address explicitly. In this case the source address will always be the address to which the socket was bound, at least as long as the target address matches the network broadcast address of this bound address - but in SRT, as it works on bidirectional UDP channels, this will never be the case because a socket bound to a specific IP address will be only able to receive packets from the IP address that matches the network broadcast address of its bound address (or at least the default routing rules will never reroute other UDP packets to this socket).
Fixes #431
Update 11.08.22
Portability (FreeBSD, Windows, ...) might be an issue here. E.g. see this StackOverflow discussion.