View Issue Details

IDProjectCategoryView StatusLast Update
0009263GNUnettransport servicepublic2025-09-22 07:17
Reporterthejackimonster Assigned Tothejackimonster Due Date
PrioritynormalSeverityminorReproducibilityalways
Status confirmedResolutionopen 
Product VersionGit master 
Target Version1.0.0 
Summary0009263: Transport is ignoring disabled IPv6
DescriptionIf you manually disable IPv6 via configuration, the transport service still forwards IPv6 addresses to the communicators which then can't handle them, causing the queue creation to fail. However transport never really recognizes that it's a ridiculous request that can not work because it only looks at the prefix of addresses which currently specifies underlying protocols like "udp" or "tcp" - not whether IPv4 or IPv6 is supported.
Additional InformationI think we need some kind of error signal for that to reduce unnecessary requests. A different solution would be using a different prefix for IPv6 addresses. So the communicator wouldn't register to all "udp" or "tcp" addresses but only supported IPv4 or IPv6 specifically. Technically both optimizations would also work together. But I think the second option is the cleaner solution to drop IPv6 address requests if not supported more easily. I just don't know how much overhead it brings to change prefixes from "udp-" to "udp4-" and "udp6-".
TagsNo tags attached.

Relationships

related to 0005710 confirmed TNG meta issue 
related to 0009029 closedschanzen problem "network ist unreachable" with 0.21.1 and 0.21.2 
related to 0009314 closedschanzen Cannot connect to peers, gnunet-communicator-tcp-26872 WARNING connect to failed: Invalid argument 

Activities

thejackimonster

2024-11-03 16:29

developer   ~0023641

After some discussion a proper step into solving this is separating IPv4 from IPv6 as different communicators. So one of them could be fully disabled properly. For this the code of TCP and UDP communicators could use macros to build for IPv4 and IPv6 separate own binaries from the same source code.

Issue History

Date ModifiedUsernameFieldChange
2024-10-10 12:25thejackimonsterNew Issue
2024-10-11 09:12schanzenTarget Version1.0.0 => 0.23.0
2024-10-23 19:48schanzenRelationship addedrelated to 0009029
2024-11-03 16:29thejackimonsterNote Added: 0023641
2024-11-04 09:58schanzenRelationship addedrelated to 0009314
2024-11-08 06:43schanzenAssigned To => thejackimonster
2024-11-08 06:43schanzenStatusnew => confirmed
2024-11-14 08:46schanzenTarget Version0.23.0 => 0.24.0
2025-02-17 13:26schanzenTarget Version0.24.0 => 0.25.0
2025-09-16 10:09schanzenTarget Version0.25.0 => 0.26.0
2025-09-22 07:17schanzenRelationship addedrelated to 0005710
2025-09-22 07:17schanzenTarget Version0.26.0 => 1.0.0