IPv6 support #1191
Merged
IPv6 support #1191
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Workaround RS single local address flawed assumption by spreading all viables local addrresses via discovery Spread addresses also through hidden node as they are the only hope to help direct connection happening for common trusted nodes behind nasty firewalls
Changed unix_connect signature to be more comfortable for dual stack usage Remove dead code in pqissl::pqissl(...) Adapt p3I2pBob::connectI2P() to new unix_connect Adapt extaddrfinder to new unix_connect Add sockaddr_storage_ipv4_to_ipv6 to convert from flat IPv4 to IPv4 mapped as IPv6
|
Great to see that IPv6 support is still alive 😄 |
G10h4ck
force-pushed
the
IPv6-v3
branch
5 times, most recently
from
31c3b09
to
ea671b2
Compare
With this commit IPv6-v3 surpass v0.6-IPv6-2 in term of features obsoleting it. p3BitDht handle gracefully unwanted non IPv4 addresses rsUdpStack handle gracefully unwanted non IPv4 addresses pqissludp handle gracefully unwanted non IPv4 addresses Move single address limitation workaround from p3discovery2::sendOwnContactInfo to better place p3PeerMgrIMPL::UpdateOwnAddress this way local address list is queried less often and only id there is some suggestion that it may have changed (probably ir will not be called all the times there is a changes in local network interfaces but is good enough) Implement crossplatform rs_setsockopt to avoid too much ifdef around Implement sockaddr_storage_copy to safely copy sockaddr_storage objects
More safe sockaddr_storage copy
Due to a regression introduced in dedfcb2 the local address was not updated correctly causing part of RS networking being stuck and printing lot of invalid sockaddr_storage messages, this commit fix the regression
|
Since 0.6.4 is out, can this be merged now? 😸 |
|
For the tests I have made this is ready to go |
|
Does it supports DHT in ipv6？ When would the 0.6.5 including ipv6 be released？ Thanks. |
|
No libbitdht doesn't support IPv6 and we don't plan to add IPv6 support to libbitdht ATM, we have been considering to switch to an independently maintained DHT library that supports IPv6 already. Next release will include the IPv6 support already included in master branch. |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Attempt to implement IPv6 dual stack operation in a retro-compatible non chain reaction manner