hub: ADC passive download is not possible due to wrong computation of IP version
aler9 opened this issue · 3 comments
Before a DCTM is propagated, the hub checks whether the RECEIVER supports IPv4 or IPv6, and then inserts the proper sender IP in the message:
Line 572 in 9ea4469
In ADC, peer support for IPv4 or IPv6 is inferred from the feature array, and in particular from the TCP4 and TCP6 flags:
Line 766 in 9ea4469
The problem is that the TCP4 and TCP6 flags are added only if the peer is active, as written explicitly in the specification:
The features TCP4 and TCP6 are used to indicate support for incoming TCP connections
This makes downloading impossible if the downloader is passive, as it does not have the TCP4 nor the TCP6 flags.
This can be solved by getting the IP version in another way, for instance by checking the IP version of the hub <-> client connection.
Hi, in case the problem is not clear enough, this is the entire history:
- the passive downloader sends a RCTM, that is correctly routed by the hub
- the active uploader receives the RCTM and sends back the CTM
- this CTM is stopped by the hub, since the downloader does not have TCP4/TCP6.
I did not sent a patch because there are multiple solutions available.
Shouldn't the passive downloader send a RCM instead?
Shouldn't the passive downloader send a
RCMinstead?
yes, it does, i tried to explain it in the previous comment (even if i called RCTM the RCM). The RCM is not blocked, it's the CTM that follows that is blocked.