When go-dcpp receives a DCTM:
1) it sends to the recipient the fake info that the sender has updated its IP
2) then, it propagates the DCTM
The problem is that the fake IP update is not done correctly, as it is sent through an IINF, that is intended for updating Hub infos, not user ones, resulting in:
IINF I4192.168.8.8
DCTM ....
The IINF does not even contain the sender session ID. The procedure should be done with a BINF, that is intended for updating user infos (even if they're not really broadcasted) and contains the sender session ID:
When go-dcpp receives a DCTM: 1) it sends to the recipient the fake info that the sender has updated its IP 2) then, it propagates the DCTM
The problem is that the fake IP update is not done correctly, as it is sent through an IINF, that is intended for updating Hub infos, not user ones, resulting in:
The IINF does not even contain the sender session ID. The procedure should be done with a BINF, that is intended for updating user infos (even if they're not really broadcasted) and contains the sender session ID:
This should fix the problem.