I have set up my own gemini server:

gemini://bisse.nl/

It works in most, but not all clients. Some clients take a very
long time to load the page, while others just give an error.

But these same clients work fine on other sites, like
gemini://geminiprotocol.net/ , so I think there may be something
wrong with my server.

Clients that don't work, online:
https://portal.mozz.us/gemini/bisse.nl/
https://gemini.tildeverse.org/?gemini://bisse.nl/
Android:
Buran https://github.com/Corewala/Buran

I have tried different servers, all with the same problems:
Molly Brown https://tildegit.org/solderpunk/molly-brown
Shavit https://git.sr.ht/~yotam/shavit
net-gemini https://github.com/jackdoe/net-gemini
Agate https://github.com/mbrubeck/agate

Any ideas? What server software should I be using?

The only thing I can think of is that these servers don't
implement TLS exactly as gemini demands, and some clients
depend on it.

--
Peter Kleiweg
https://bisse.nl/

On 2023-09-20, Peter Kleiweg <kleiweg@ziggo.nl> wrote:
>
> I have set up my own gemini server:
>
> gemini://bisse.nl/
>
> It works in most, but not all clients. Some clients take a very
> long time to load the page, while others just give an error.
>
> But these same clients work fine on other sites, like
> gemini://geminiprotocol.net/ , so I think there may be something
> wrong with my server.
>
> Clients that don't work, online:
> https://portal.mozz.us/gemini/bisse.nl/
> https://gemini.tildeverse.org/?gemini://bisse.nl/
> Android:
> Buran https://github.com/Corewala/Buran
>
> I have tried different servers, all with the same problems:
> Molly Brown https://tildegit.org/solderpunk/molly-brown
> Shavit https://git.sr.ht/~yotam/shavit
> net-gemini https://github.com/jackdoe/net-gemini
> Agate https://github.com/mbrubeck/agate
>
>
> Any ideas? What server software should I be using?
>
> The only thing I can think of is that these servers don't
> implement TLS exactly as gemini demands, and some clients
> depend on it.
>

This has happened to me many times, when I hosted it locally on a
rasperry pi had that issue, so I eventually moved it all to sourcehut
since it supports git-email, gemini and https but still sometimes
depending on the client it does not work, but happens much much less
than when I was hosting it. To be fair I had the same suspicion about
TLS as well.

ReK2
Happy Hacking

--
- {gemini,https}://{,rek2.}hispagatos.org - mastodon: @rek2@hispagatos.space
- [https|gemini]://2600.Madrid - https://hispagatos.space/@rek2
- https://keyoxide.org/A31C7CE19D9C58084EA42BA26C0B0D11E9303EC5

Am 20.09.2023 um 18:19:56 Uhr schrieb Peter Kleiweg:

> The only thing I can think of is that these servers don't
> implement TLS exactly as gemini demands, and some clients
> depend on it.

Use a sniffer like Wireshark and check the TLS packages.
Do retransmissions occur?

Do you block ICMP?
TLS isn't fault-tolerant to PMTU-blackholes.

Marco Moock schreef op de 20e dag van de herfstmaand van het jaar 2023:

> Am 20.09.2023 um 18:19:56 Uhr schrieb Peter Kleiweg:
>
> > The only thing I can think of is that these servers don't
> > implement TLS exactly as gemini demands, and some clients
> > depend on it.
>
> Use a sniffer like Wireshark and check the TLS packages.
> Do retransmissions occur?
>
> Do you block ICMP?
> TLS isn't fault-tolerant to PMTU-blackholes.

I disabled ICMP flood detection, that's the only ICMP setting in
my router. This didn't have any effect.

Using wireshark with these clients:

https://gemini.tildeverse.org/?gemini://bisse.nl/
Android: Buran https://github.com/Corewala/Buran

....both hang for 130 seconds, and there is no traffic at all.
When the first package from the client arrives, the whole
transaction finishes in less than 0.1 seconds.

With this client: https://portal.mozz.us/gemini/bisse.nl/
.... I get a timeout before any package arrives at the server.

--
Peter Kleiweg
https://bisse.nl/

Peter Kleiweg schreef op de 20e dag van de herfstmaand van het jaar 2023:

> Using wireshark with these clients:
>
> https://gemini.tildeverse.org/?gemini://bisse.nl/
> Android: Buran https://github.com/Corewala/Buran
>
> ...both hang for 130 seconds, and there is no traffic at all.
> When the first package from the client arrives, the whole
> transaction finishes in less than 0.1 seconds.

So TLS is not the problem. The first package is not TLS.

It's weird that two completely different clients, one an android
app, the other a web interface, both suffer from the same delay
of 130 seconds. That's peculiar!

By the way, I tested with my server on a Raspberry Pi, and on a
Linux PC. I didn't see any difference.

--
Peter Kleiweg
https://bisse.nl/

Peter Kleiweg <kleiweg@ziggo.nl> wrote:
> Any ideas? What server software should I be using?
>
> The only thing I can think of is that these servers don't
> implement TLS exactly as gemini demands, and some clients
> depend on it.

I've never looked closely into Gemini or hosted anything over it.
But I looked at the debugging output from the Dillo-Gemini plug-in
and even though your Gemini site loads fine in that, I notice that
there's one thing different compared to the other sites linked from
your Gemini homepage:

Other sites:

gemini://geminiprotocol.net/
depth=0 CN = geminiprotocol.net

gemini://geminispace.info/
depth=0 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = geminispace.info, emailAddress = spacecaptain@geminispace.info

gemini://gemini.conman.org/
depth=0 C = US, ST = FL, L = Boca Raton, O = Conman Labs, OU = R&D, CN = gemini.conman.org, emailAddress = sean@conman.org

gemini://smol.earth/compendium/
depth=0 CN = smol.earth

gemini://astrobotany.mozz.us/
depth=0 CN = mozz.us

Your site:

gemini://bisse.nl/
depth=0 C = NL, ST = Groningen, L = Groningen, O = De laatste huismus, CN = Peter Kleiweg

The odd thing out seems to be that "CN" equals either the main
domain, or a sub-domain, of the Gemini server on all the other
sites, but not on your site.

Maybe this is perfectly fine and there are other such Gemini sites
that work fine in all browsers. But it's something to check, and
as it's a certificate problem it would explain why your problem
happens with multiple Gemini servers.

The Dillo Gemini plug-in that I'm using is a Bash script wrapped
around this command, with which you could probably do your
debugging without setting up Gemini support in Dillo:

openssl s_client -quiet -connect "$host:$port"

Dillo-Gemini:
https://git.scuttlebot.io/%25V0D7DtSnZyyAp1NbgOJF2ZAFMeUy9eXwyClCEKYUYAI%3D.sha256

--
__ __
#_ < |\| |< _#

Peter Kleiweg schreef op de 21e dag van de herfstmaand van het jaar 2023:

> Peter Kleiweg schreef op de 20e dag van de herfstmaand van het jaar 2023:
>
> > Using wireshark with these clients:
> >
> > https://gemini.tildeverse.org/?gemini://bisse.nl/
> > Android: Buran https://github.com/Corewala/Buran
> >
> > ...both hang for 130 seconds, and there is no traffic at all.
> > When the first package from the client arrives, the whole
> > transaction finishes in less than 0.1 seconds.
>
> So TLS is not the problem. The first package is not TLS.
>
> It's weird that two completely different clients, one an android
> app, the other a web interface, both suffer from the same delay
> of 130 seconds. That's peculiar!

Found it! I searched for "130 seconds" and stumbled on some
messages about standard time-out for IPv6 look-up, which happens
to be 130 seconds.

Could these clients be trying to connect through IPv6, and only
switch to IPv4 after the time-out?

I did some more reading, and concluded that I hadn't set up
my IPv6 address correctly with my DNS provider. So I just
disabled it. Removed the AAAA record.

Tested again. Gone are the delays. All clients that were having
trouble connecting are now working perfectly without any delay.

To summarize: no server/client mismatch in Gemini software.

--
Peter Kleiweg
https://bisse.nl/

>
> Found it! I searched for "130 seconds" and stumbled on some
> messages about standard time-out for IPv6 look-up, which happens
> to be 130 seconds.
>
> Could these clients be trying to connect through IPv6, and only
> switch to IPv4 after the time-out?
>
> I did some more reading, and concluded that I hadn't set up
> my IPv6 address correctly with my DNS provider. So I just
> disabled it. Removed the AAAA record.
>
> Tested again. Gone are the delays. All clients that were having
> trouble connecting are now working perfectly without any delay.
>
> To summarize: no server/client mismatch in Gemini software.
>

Grats! and this makes total sense now.
Thanks for looking into this.

ReK2
Happy Hacking

--
- {gemini,https}://{,rek2.}hispagatos.org - mastodon: @rek2@hispagatos.space
- [https|gemini]://2600.Madrid - https://hispagatos.space/@rek2
- https://keyoxide.org/A31C7CE19D9C58084EA42BA26C0B0D11E9303EC5

Am 21.09.2023 um 02:11:35 Uhr schrieb Peter Kleiweg:

> Could these clients be trying to connect through IPv6, and only
> switch to IPv4 after the time-out?

That is a reasonable default.

> I did some more reading, and concluded that I hadn't set up
> my IPv6 address correctly with my DNS provider. So I just
> disabled it. Removed the AAAA record.

Then configure your IPv6 connection properly and enable it.
If you need help, simply ask.

Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
> Am 21.09.2023 um 02:11:35 Uhr schrieb Peter Kleiweg:
>> Could these clients be trying to connect through IPv6, and only
>> switch to IPv4 after the time-out?
>
> That is a reasonable default.

It doesn't seem so to me. If the client knows there's an IPv4
address for that domain, that's the more established, and therefore
more reliable, addressing scheme. So I'd expect the default to be
trying IPv4 first if both are available, and falling back to IPv6
if it fails.

--
__ __
#_ < |\| |< _#

On 22 Sep 2023 07:27:50 +1000, Computer Nerd Kev wrote:
> It doesn't seem so to me. If the client knows there's an IPv4
> address for that domain, that's the more established, and therefore
> more reliable, addressing scheme. So I'd expect the default to be
> trying IPv4 first if both are available, and falling back to IPv6
> if it fails.

IPv6 is 28 years old, I'd say it's reasonable, when presented with both
options to prefer the "newer" protocol version. Especially since both
the client requirement of a valid, routable IPv6 address and the server
requirement of publishing a AAAA RR fairly explicitly opts both parties
in to the behavior.

--
"The avalanche has started, it is too late for the pebbles to vote."
--Kosh

Am 22.09.2023 um 07:27:50 Uhr schrieb Computer Nerd Kev:

> Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
> > Am 21.09.2023 um 02:11:35 Uhr schrieb Peter Kleiweg:
> >> Could these clients be trying to connect through IPv6, and only
> >> switch to IPv4 after the time-out?
> >
> > That is a reasonable default.
>
> It doesn't seem so to me. If the client knows there's an IPv4
> address for that domain, that's the more established, and therefore
> more reliable, addressing scheme. So I'd expect the default to be
> trying IPv4 first if both are available, and falling back to IPv6
> if it fails.

IPv4 uses NAT, that makes it slower and it need more resources.
IPv6 works fine, you simply need to configure it properly, like IPv4.

IPv6 is the new and reasonable default, I only need IPv4 to connect to
machines that aren't reachable by IPv6, either because of lazy ISPs or
admins.

IPv4 is nasty because not enough addresses are available. The faster
the complete switchover to IPv6 is, the less trouble with IPv4 and all
its bad aspects like NAT and CGNAT.

On Fri, 22 Sep 2023 20:07:39 +0200, Marco Moock wrote:
> IPv4 uses NAT, that makes it slower and it need more resources.

If you're seeing any sort of noticable slowdowns because of NAT on
anything that even smells a little bit like modern hardware I'd be
absolutely staggered.

--
"The avalanche has started, it is too late for the pebbles to vote."
--Kosh

Am 22.09.2023 um 21:46:54 Uhr schrieb Matthew Ernisse:

> On Fri, 22 Sep 2023 20:07:39 +0200, Marco Moock wrote:
> > IPv4 uses NAT, that makes it slower and it need more resources.
>
> If you're seeing any sort of noticable slowdowns because of NAT on
> anything that even smells a little bit like modern hardware I'd be
> absolutely staggered.

It seems you don't know about CG-NAT at the provider side.
If you had experience with that, you will love IPv6.

I also don't understand the excuses for not implementing it.

On Sat, 23 Sep 2023 15:17:54 +0200, Marco Moock wrote:
>
> It seems you don't know about CG-NAT at the provider side.
> If you had experience with that, you will love IPv6.

I don't dislike IPv6, in fact I worked quite hard at a US national ISP
to ensure all of our services supported it as soon as we got our very first
/32 allocation.

I also know plenty about CG-NAT, it and NAT64 were key parts of our FMC
mobility platform.

I simply generally object to blaming NAT for poor performance when
it is more likely to be misconfiguration or undersizing of equipment
which will likely affect non-NATted connections and IPv6 traffic as
well (IME ISPs tend to configure equipment to minimize calls, not to
maximize performance).

> I also don't understand the excuses for not implementing it.

On this we agree, though I suspect they are so varied and numerous that
we'd never understand them all.

--
"The avalanche has started, it is too late for the pebbles to vote."
--Kosh

On 21/09/2023 01:11, Peter Kleiweg wrote:
> Peter Kleiweg schreef op de 21e dag van de herfstmaand van het jaar 2023:
>
>> Peter Kleiweg schreef op de 20e dag van de herfstmaand van het jaar 2023:
>>
>>> Using wireshark with these clients:
>>>
>>> https://gemini.tildeverse.org/?gemini://bisse.nl/
>>> Android: Buran https://github.com/Corewala/Buran
>>>
>>> ...both hang for 130 seconds, and there is no traffic at all.
>>> When the first package from the client arrives, the whole
>>> transaction finishes in less than 0.1 seconds.
>>
>> So TLS is not the problem. The first package is not TLS.
>>
>> It's weird that two completely different clients, one an android
>> app, the other a web interface, both suffer from the same delay
>> of 130 seconds. That's peculiar!
>
> Found it! I searched for "130 seconds" and stumbled on some
> messages about standard time-out for IPv6 look-up, which happens
> to be 130 seconds.

I love that you found it by searching for "130 seconds", because that's
the magic number. It's like that old anecdote about the 500-mile
email... <http://web.mit.edu/jemorris/humor/500-miles>

--
Dan Q | https://danq.me | gemini://danq.me