The Fragment reassembly time exceeded ICMP message and the traceroute ewarnings you reported before can point to some issue in the network between you host and github.com. Which could explains why you don’t face the same issue with other online git repositories while still, probably, using TLS 1.3 with them, or duckduckgo.com, for instance.
I guess it matter to understand that openssl 3.5 introduced some changes, in particular regarding default ciphers, keyshares, which impact the behavior compared to previous versions of openssl 3.x.
While I’m quite sure the CA file is not responsible of the root issue here, I’m more suspecting that the switch to openssl 3.5 (which comes by dependency, maybe) make a dormant cornercase - like maybe in the IP fragmentation on Haiku or on some equipement on the route between you and some servers like github, duckduckgo, but not some others - now happened due to larger messages exchanged in TLS v1.3.
@grexe, you can also use some online TLS server to see if, from server side, the client connection seems ok or not.
For instance:
As you encounter SSL/TLS issue when trying to access github, duckduckgo even from WebPositive, you can try it with this URL and share the output of the server page about your Web browser connection from Haiku.
As it seems to happens not on all servers (and gitlab.com, github.com, duckduckgo.com all will accept TSL v1.3, so it’s not because some are only accepting 1.2…), it seems to be related to the specific route followed by packets between @grexe host and these servers.
Which doesn’t mean that Haiku TCP/IP can’t be involved here, maybe some expectation regarding MTU and IP fragmentations are not correctly implemented.
Or maybe the issue is actually between his Haiku and these servers.
In parent topic, @grexe were reporting some long DNS lookup times, for instance. You can’t exclude some issue on the network itself, maybe due to his
ISP, or the kind of gateway in front of his ISP.
As no everyone are facing the same issue, the network interface or network route is a factor, here, otherwise everyone will have the same issue.
Clearly, it could be investigate more deeply only with having the actual TCP ClientHello and ServerHello packets content, if any.
For such few packets, @grexe you can use Wireshark to edit the captured pcap to replace your private IP address(es) by dummy IP(v4 I guess) address like 1.2.3.4 if you care about not exposing personal data, which I can understand well.
2 Likes
Ah, MTU problems!
Currently Haiku does not do MTU path discovery. That means it always sends packets of the maximal size on the local network, and in theory, the routers along the way should split and reassemble these as needed.
But this often doesn’t work, and it is good practise to discover the maximum MTU along the path, and not send IP packets larger than that. I’m sure there is an RFC with the algorithm for that? The basig idea being that if you start getting these ICMP errors meaning that some router along the way had to split your packets, you should send smaller packets.
This also explains why no one else had the issue: it depends on your local network and internet connection. For example, vlan or bridging between ethernet and wifi could reduce the MTU (but also it could be something your Internet provider is doing).
As a workaround you can reduce the MTU manually (in a boot script, I think we don’t have it in network preferences directly?) and you should be fine.
3 Likes
ah so it is the MTU after all, that makes sense but is quite annoying;-)
As for the impact, I guess a lot of users in the DACH region will face this issue, since I am using a standard Magenta / Telekom router which is very widely used in Germany and Austria, and I am using the default settings (except for password oc;-).
The router is a Technicolor CGA4336 with latest firmware.
I am using Wifi 6 but not sure which network Haiku connects to, as I see two WLAN networks with the same name.
I found a useful standard which you might have been referring to, I think this should definitely be implemented in the Haiku network stack…
and the latest RFC (extending 2 previous ones) on that standard:
Will try that setting now, what’s the option called?
Update ok easy enough, for reference (replace with your network device, obviously):
ifconfig /dev/net/iaxwifi200/0 mtu 1024
Now git, SoftwareUpdater and DuckDuckGo work as expected again…
Thanks to all helpful people involved in solving this pesky issue!
3 Likes
I think we can start with the absolute simplest kind of path MTU discovery, which is simply to propagate those ICMP errors up to the TCP layer, and then let the TCP layer adjust MTU and resend packets. More advanced kinds we can implement later.
2 Likes
can’t we reuse the algo from BSD here?
Update found this MIT licensed C source code which offers a safe alternative to checking for ICMP fragmentation errors which are not always handed through by some routers:
might be a starting point?
Making sure you're not a bot! has links to 3 other (older) RFCs about it.
1 Like
I’m in Vienna and not using Magenta of course 
Ah bad infrastructure in your ghetto then😅
Seriously though, a fellow Haiku developer in Vienna and we haven’t met yet? Let’s do a spontaneous meetup with @BlueSky and connect🤓
Anubis strikes again 
1 Like
I see the issue has a 9 year cycle, so maybe 2025 is the right time to tackle this one after all
As a workaround you can reduce the MTU manually (in a boot script, I think we don’t have it in network preferences directly?)
Well, until we add support for more magic MTU discovery to Haiku TCP/IP stack, maybe a quicker fix will be indeed to allow user to override a network device MTU in Network Settings preflet, to avoid tweaking manually at boot script level ?
Also, maybe we can also add in Network Preflet some way to show user sent / receive errors counters in IPv4 panel, as we do for sent/write packets at device level ?
Currently, even via ifconfig command line, I’m not sure user has a way to see that on some interface that kind of stats.
3 Likes
I guess the Haiku devs strategy regarding this issue is to wait even longer that everybody has switched to IPv6, in which this issue is managed directly at IPv6 level by specification
1 Like