View Issue Details

IDProjectCategoryView StatusLast Update
0009029GNUnettransport servicepublic2024-10-12 18:05
Reporterxrs Assigned Toschanzen  
PrioritynormalSeverityminorReproducibilityalways
Status confirmedResolutionopen 
Platformx86_64OSalpine linuxOS Version3.20.2
Product Version0.21.2 
Target Version0.22.2 
Summary0009029: problem "network ist unreachable" with 0.21.1 and 0.21.2
DescriptionStandard installation of gnunet on alpine linux.

After starting gnunet peer the logs show signs of network problems, see files attached.

The firewall on the LAN forwards TCP/UDP traffic on port 2086 (extern=intern).
TagsNo tags attached.
Attached Files
logs-0.21.1.png (213,116 bytes)   
logs-0.21.1.png (213,116 bytes)   
logs-0.21.2.png (182,391 bytes)   
logs-0.21.2.png (182,391 bytes)   

Activities

schanzen

2024-08-29 17:25

administrator   ~0023106

This is likely an issue with interface/address selection and I can confirm this happens, but does not prevent connections. May only occur with IPv6 and/or TCP or UDP.

thejackimonster

2024-10-10 03:19

developer   ~0023492

I think this can happen when the router blocks outgoing IPv6 traffic. I assume in such a case it should be detected by the communicator and automatically disable its IPv6 functionality (or at least tell the transport service, there's no need to forward IPv6 addresses to it for opening connections because it simply does not work). If it can be detected by the communicator, it should also be possible to re-enable it (if not explicitly disabled via configuration).

schanzen

2024-10-11 11:10

administrator   ~0023512

Did you fix this with the last commits made to master?

thejackimonster

2024-10-11 13:14

developer   ~0023515

No, this isn't fixed yet.

schanzen

2024-10-11 13:26

administrator   ~0023516

I'm not sure if we should handle "network is unreachable" errors. Those are networks/system misconfigurations that the user/admin is the only person able to fix that.

thejackimonster

2024-10-12 18:05

developer   ~0023524

Maybe we could workaround this at least to reduce such errors. If IPv4 and IPv6 were separated acting as own communicators and transport would be rating communicators on a rate of successful connections, transport could at least understand if there are issues with some protocol and default to use a different communicator if possible to make connections to a certain peer.

Issue History

Date Modified Username Field Change
2024-07-29 22:31 xrs New Issue
2024-07-29 22:31 xrs File Added: logs-0.21.1.png
2024-07-29 22:31 xrs File Added: logs-0.21.2.png
2024-08-29 17:25 schanzen Note Added: 0023106
2024-08-29 17:25 schanzen Assigned To => schanzen
2024-08-29 17:25 schanzen Status new => confirmed
2024-08-30 12:21 schanzen Severity major => minor
2024-10-10 03:19 thejackimonster Note Added: 0023492
2024-10-10 10:22 schanzen Target Version => 0.22.2
2024-10-11 11:10 schanzen Note Added: 0023512
2024-10-11 13:14 thejackimonster Note Added: 0023515
2024-10-11 13:26 schanzen Note Added: 0023516
2024-10-12 18:05 thejackimonster Note Added: 0023524