linuxdcpp-team team mailing list archive

[eMTee <1979900@xxxxxxxxxxxxxxxxxx>]

Fixed in DC++ 0.880

** Changed in: dcplusplus
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1979900

Title:
  Outgoing connections are attempted on IPv6 on some cases when there's
  no v6 connectivity

Status in DC++:
  Fix Released

Bug description:
  [2022-06-17 17:13] <eMTee> Recently I was surprised seeing "::" in the IP column in the hubframe userlist for all other DC++ users in each LuaDCH hubs I'm in. I've never seen such thing before.
  [2022-06-17 17:14] <eMTee> Actually the hub sends I6:: in BINF for all DC++ users but not for users of some other clients.
  [2022-06-17 17:16] <eMTee> LuaDCH devs confirmed that it is a known issue and they're working on it. 
  [2022-06-17 17:18] <eMTee> They did not tell the cause but I'm guessing it is because DC++ doesn't support HBRI, an unofficial ADC extension developed by maksis in AirDC++ and what they're using for managing hybrid v4/v6 connetions.
  [2022-06-17 17:20] <eMTee> I checked why this zero IP value is displayed instead of the usual v4 address in DC++. Turned out it's User::Identity::getIp() which prefers returning IPv6 when both IP adresses are available.
  [2022-06-17 17:22] <eMTee> This a hub bug and since I see we accept whatever the hub send in an ADC command param without checking for format/value so it causes a visual disruption. 
  [2022-06-17 17:24] <eMTee> But. I checked where User::Identity::getIp() used elsewhere. Actually it is used for getting the IP for outgoing connections in ConnectionManager and ClientManager.
  [2022-06-17 17:26] <eMTee> In this buggy case it would return the IPv6 value for all outgoing connection attempts, even if you have IPv4 connectivity only. That obviously breaks outgoing connections to those users for whom the hub supplies a wrong I6 value. Still, this isn't much of a problem as it caused by getting some nonsense from a buggy hub.
  [2022-06-17 17:28] <eMTee> Sending zero IP value from a hub is indeed nonsense but if the hub sends the valid IPv6 address of the user in I6 then this will actually break your outgoing connections the same way in case you have v4 connectivity only.
  [2022-06-17 17:29] <eMTee> It breaks uploads, CCPM and sending udp search responds.
  [2022-06-17 17:34] <eMTee> Looks like getting IPv6 addresses in BINF from the hub seems to be nonexistent thing even from hubs running in dual IP mode. 
  [2022-06-17 17:39] <eMTee> Relevant parts of the code are https://sourceforge.net/p/dcplusplus/code/ci/93a0986b55c5b07038451fd336a30149076a21d1/tree/dcpp/User.cpp#l86 , https://sourceforge.net/p/dcplusplus/code/ci/93a0986b55c5b07038451fd336a30149076a21d1/tree/dcpp/ConnectionManager.cpp#l410 , https://sourceforge.net/p/dcplusplus/code/ci/93a0986b55c5b07038451fd336a30149076a21d1/tree/dcpp/ClientManager.cpp#l455
  [2022-06-17 17:41] <eMTee> tl;dr is that we should not attempt to estabilish an outgoing connection using a v6 IP address when we have only v4 connectivity. 
  [2022-06-18 08:49] <eMTee> Possible fix is to check for the current connectivity status and choose the right IP before attempting the connection.
  [2022-06-18 08:56] <eMTee> As we see IPv4 is still the go to connection around the network I guess we must make sure such connections work properly. This bug can be clearly triggered by receiving a valid ADC command parameter from a hub.

  See also https://bugs.launchpad.net/adchpp/+bug/309402 regarding all
  the ipv6 issues. The above linked parts of the code suggest that plans
  in https://bugs.launchpad.net/adchpp/+bug/309402/comments/23 has not
  been implemented yet in DC++.

  The attached patch fixes this issue by using info from
  ConnectivityManager and forces IPv4 address/connection when there's no
  IPv6 connectivity set/detected. Otherwise it does the same as before,
  allowing User::Identity::getIp() to decide what protocol to be
  used/preferred.

  But the question is do we need to care of this at all or just rely on
  what the hub sends... in other words is this kind of safeguard worth
  or needed at all? Or it's useful for a temporary fix until one of the
  few maintained ADC hubs fixes its bug?

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1979900/+subscriptions