[Galene] galene on IPv6 only

[Galene] galene on IPv6 only

[Curtis Villamizar]

It looks like galene does not want to work on an IPv6 only server.
This server has no IPv4 address at all, not even loopback 127.0.0.1.
When I use -http [<myprefix>::6106]:8443 it does not bind to that
address.  I do get a UDP bind to a random UDP port.  I see the UDP
range option but it is not clear to me what that is for.

I also get messages related to IPv4-ish stuff.
  Failed to enable mDNS over IPv4:
    (listen udp4 224.0.0.0:5353: socket: protocol not supported)
and
  Relay test failed: timeout 2026/03/19 07:41:38
    Perhaps you didn't configure a TURN server?
  TURN: no public addresses

The second message is benign and only indicates the relayTest() test
has failed even though it should not be run if there is no IPv4.

This is despite both mDNS and TURN supposedly disabled.

This is IPv6 so no need for ICE, STUN, TURN, etc.  There is nothing on
the local lan (its in a datacenter) so no need for mDNS and running
mDNS is *very* bad form in that type of environment.

I should mention that this is FreeBSD inside an IPv6 only jail.

I have patches that get me to connect via tcp6.  See below.  This also
gets rid of the mDNS attempt so that seems tied to the bind previously
not working.  So this is sort of a solved problem.  If instead of
using the IPv6 address inside [] I use the host name, then not solved.
Even though the host has an AAAA DNS record and no A record, the bind
does not work if the host name is specified.  This may be an upstream
problem in the go net library.

This could be solved by doing a DNS lookup and seeing the AAAA record
(and A record if used) and listenning with tcp6 (and tcp4 if A used).
This would be needed anyway if you wanted to be like apache and
support binding to more than one address with one instance of the
server.  It would be a lot cleaner.  Maybe later I'll refile the
patches.

Curtis


--- galene.go.orig	2025-08-09 10:26:35.000000000 -0400
+++ galene.go	2026-03-19 09:42:32.995605000 -0400
@@ -53,6 +53,13 @@
 		"built-in TURN server `address` (\"\" to disable)")
 	flag.Parse()
 
+	log.Printf("httpAddr = %s", httpAddr)
+	if strings.HasPrefix(httpAddr, "[") {
+		group.UseMDNS = false
+		turnserver.Address = ""
+		log.Printf("Using IPv6, disable mDNS and TURN")
+	}
+
 	if udpRange != "" {
 		if strings.ContainsRune(udpRange, '-') {
 			var min, max uint16
@@ -145,7 +152,9 @@
 	terminate := make(chan os.Signal, 1)
 	signal.Notify(terminate, syscall.SIGINT, syscall.SIGTERM)
 
-	go relayTest()
+	if ! strings.HasPrefix(httpAddr, "[") {
+		go relayTest()
+	}
 
 	ticker := time.NewTicker(15 * time.Minute)
 	defer ticker.Stop()

--- webserver/webserver.go.orig	2025-08-09 10:26:35.000000000 -0400
+++ webserver/webserver.go	2026-03-19 08:54:40.982460000 -0400
@@ -72,6 +72,10 @@
 	proto := "tcp"
 	if strings.HasPrefix(address, "/") {
 		proto = "unix"
+	}
+	if strings.HasPrefix(address, "[") {
+		proto = "tcp6"
+		log.Printf("Using IPv6, set proto to tcp6")
 	}
 
 	listener, err := net.Listen(proto, address)

[Galene] Re: galene on IPv6 only

[Juliusz Chroboczek]

Hello,

> It looks like galene does not want to work on an IPv6 only server.

Thanks a lot for your testing, that's the kind of deployment that we
should be supporting.

> I also get messages related to IPv4-ish stuff.
>   Failed to enable mDNS over IPv4:
>     (listen udp4 224.0.0.0:5353: socket: protocol not supported)


mDNS is disabled by default for a very long time.  See galene.go line 49:

    flag.BoolVar(&group.UseMDNS, "mdns", false, "gather mDNS addresses")

I think the issue here is that UseMDNS is not obeyed by the relay test.
I'll fix that ASAP.

>   Relay test failed: timeout 2026/03/19 07:41:38
>     Perhaps you didn't configure a TURN server?
>   TURN: no public addresses
> 
> The second message is benign and only indicates the relayTest() test
> has failed even though it should not be run if there is no IPv4.

RelayTest is run unconditionally, since it should be successful with an
IPv6 TURN server.  The issue here is that the built-in TURN server does
not implement RFC 6156, you need to use Coturn or some other full-featured
TURN server.

We should probably run two relay tests, one over IPv4 and one over IPv6.

> This is IPv6 so no need for ICE, STUN, TURN, etc.

I, too, used to be optimistic about IPv6 ;-)

ICE is still required, since both address selection and blackhole
detection are done by ICE.  STUN and TURN are useful if there's a firewall
in the way, which sadly is often the case, even with IPv6.

> There is nothing on the local lan (its in a datacenter) so no need for
> mDNS and running mDNS is *very* bad form in that type of environment.

Yes, mDNS is disabled by default.  I need more information to understand
why it's not being disabled in your case.

> If instead of using the IPv6 address inside [] I use the host name, then
> not solved.  Even though the host has an AAAA DNS record and no
> A record, the bind does not work if the host name is specified.  This
> may be an upstream problem in the go net library.

Interesting.  I'll see if I can reproduce it.

-- Juliusz

[Galene] Re: galene on IPv6 only

[Curtis Villamizar]

In message <874imask25.wl-jch@irif.fr>
Juliusz Chroboczek writes:
 
> Hello,
>  
> > It looks like galene does not want to work on an IPv6 only server.
>  
> Thanks a lot for your testing, that's the kind of deployment that we
> should be supporting.
>  
> > I also get messages related to IPv4-ish stuff.
> >   Failed to enable mDNS over IPv4:
> >     (listen udp4 224.0.0.0:5353: socket: protocol not supported)
>  
>  
> mDNS is disabled by default for a very long time.  See galene.go line 49:
>  
>     flag.BoolVar(&group.UseMDNS, "mdns", false, "gather mDNS addresses")
>  
> I think the issue here is that UseMDNS is not obeyed by the relay test.
> I'll fix that ASAP.

Thanks.  Very responsive on your part.

> >   Relay test failed: timeout 2026/03/19 07:41:38
> >     Perhaps you didn't configure a TURN server?
> >   TURN: no public addresses
> > 
> > The second message is benign and only indicates the relayTest() test
> > has failed even though it should not be run if there is no IPv4.
>  
> RelayTest is run unconditionally, since it should be successful with an
> IPv6 TURN server.  The issue here is that the built-in TURN server does
> not implement RFC 6156, you need to use Coturn or some other full-featured
> TURN server.

There needs to be an ability to disable the loopback test.  I have no
need for a TURN server and I think this will be common among those
running IPv6 only.

> We should probably run two relay tests, one over IPv4 and one over IPv6.
>  
> > This is IPv6 so no need for ICE, STUN, TURN, etc.
>  
> I, too, used to be optimistic about IPv6 ;-)

That is another discussion.  So I'll try to be brief.

Even here in the laggard US more consumer ISPs are offering IPv6
either enabled by default or enabled on request.  Nearly all business
service from ISPs offers IPv6.

I've been involved with IPv6 since before the beginning and had a lot
to do with OSI not being picked for the basis of IPv6.  I argued for a
64 bit address.  Then high end router manufacturers insisted they
would only fast path the top 64 bits and the bottom should be used for
LAN only (enterprise routing, etc) where speeds in PPS were not as
high so IETF decided the bottom 64 would not be used for routing at
all.  Since most LANs are under 256 hosts and nearly all under 64K
hosts, they wasted at least 48 bits.

Working for an ISP and then later high end routing and fiber optic
transport equipment I used to say that anyone that didn't have IPv6
was probably not someone I needed to talk to and likely someone I
didn't want to here from.  This worked in that community as PGP worked
in the security community.  For a while I ran an IPv6 only mail server
and generally that was fine except mailing lists hosted on Cloudflare.

I am now finding that even most people in my personal life with
consumer Internet now have access to IPv6 (no NAT afaik) so I am still
hopeful.  In some cases I've had to resort to tunnels to my datacenter
servers to get IPv6 if using my laptop when visiting friends or family
and even hotels and consumer oriented businesses so not there yet.

> ICE is still required, since both address selection and blackhole
> detection are done by ICE.  STUN and TURN are useful if there's a firewall
> in the way, which sadly is often the case, even with IPv6.

This is not a problem in my case.  IPv6 in the clear, no NAT.

> > There is nothing on the local lan (its in a datacenter) so no need for
> > mDNS and running mDNS is *very* bad form in that type of environment.
>  
> Yes, mDNS is disabled by default.  I need more information to understand
> why it's not being disabled in your case.

With the admitedly kludgy patch the problem is gone so maybe it was
the relay test which I now disabled.  That saying, I didn't look at
the code much.

> > If instead of using the IPv6 address inside [] I use the host name, then
> > not solved.  Even though the host has an AAAA DNS record and no
> > A record, the bind does not work if the host name is specified.  This
> > may be an upstream problem in the go net library.
>  
> Interesting.  I'll see if I can reproduce it.

That's with my kludgy patch.  Maybe standby and I'll put together a
more robust patch.

Up and sort of running but I still need some work.  This would have
gone a lot faster if there were better documentation and better
diagnostics on json issues.  I have to say that initial setup was
somewhat painful.  I'll let you if there are any further problems that
are not unique to my misconfiguration.  I'll try to help rather than
just whine.

> -- Juliusz
> _______________________________________________
> Galene mailing list -- galene@lists.galene.org
> To unsubscribe send an email to galene-leave@lists.galene.org

[Galene] IPv6 and ICE [was: galene on IPv6 only]

[Juliusz Chroboczek]

I'm separating this into its own thread, so we can focus on Galene
improvements in the main thread.

>> I, too, used to be optimistic about IPv6 ;-)
> 
> That is another discussion.  So I'll try to be brief.

No need to be brief, people who are not interested will hit delete.

> Even here in the laggard US more consumer ISPs are offering IPv6
> either enabled by default or enabled on request.

Oh, fully agreed, sorry for the misunderstanding.  I have no doubts that
IPv6 is being widely deployed.  I'm also fully committed to having Galene
work well in v6-only networks.  (In fact, Nexedi, one of the former
sponsors of Galene, are running a v6-only network internally, using
reverse proxies for all v4 access.)

What I'm no longer optimistic about is IPv6 traffic being end-to-end, with
no middleboxes.  People are putting stateful firewalls around their IPv6
networks, so we still need things like STUN and TURN in order to cross
these firewalls.  And I have it on good authority that people are doing
NAT in IPv6.  Granted, it's 1-to-1 NAT, not NAPT, but it's still NAT.

And then there's the issue of corporate firewalls (that whitelist web
traffic and Zoom, because the web and Zoom are supposedly not threats, but
block anything else).  And don't get me started on state-sponsored
firewalls (China, of course, but also Russia and other petrodictatorships).

>> ICE is still required, since both address selection and blackhole
>> detection are done by ICE.

> This is not a problem in my case.  IPv6 in the clear, no NAT.

How I wish that were true!

There's the issue of the client-side firewall.  If it's a simple stateful
firewall, as in most residential networks, then you need ICE in order
to ensure that the first packet in a UDP flow goes from client to server.
If it's a fascist corporate firewall that blocks all non-web traffic, then
you need a TURN server on port 443 (and preferably more than one, on
different IP ranges).

Even when there's no firewall, ICE is the mechanism that allows Galene to
detect that a UDP flow is no longer functioning, and therefore to reliably
restart a flow after a UDP outage: it detects the case when UDP suddenly
gets filtered but the TCP WebSocket remains functional.

-- Juliusz

[Galene] Re: IPv6 and ICE [was: galene on IPv6 only]

[Craig Miller]

I think the goal needs to be better described.

In an IPv6-only environment, there is NO NAT. Yes there is a stateful 
firewall, but ports are opened to destinations in a DMZ network for 
services offered from the DMZ.

For Galene, if a pool of UDP ports were be defined, then that pool could 
be opened in the stateful firewall allowing incoming UDP to the Galene 
server. There would be no need for ICE or STUN, since those address/port 
destinations would be available to the internet.

Craig...

On 3/21/26 04:44, Juliusz Chroboczek wrote:
> I'm separating this into its own thread, so we can focus on Galene
> improvements in the main thread.
>
>>> I, too, used to be optimistic about IPv6 ;-)
>> That is another discussion.  So I'll try to be brief.
> No need to be brief, people who are not interested will hit delete.
>
>> Even here in the laggard US more consumer ISPs are offering IPv6
>> either enabled by default or enabled on request.
> Oh, fully agreed, sorry for the misunderstanding.  I have no doubts that
> IPv6 is being widely deployed.  I'm also fully committed to having Galene
> work well in v6-only networks.  (In fact, Nexedi, one of the former
> sponsors of Galene, are running a v6-only network internally, using
> reverse proxies for all v4 access.)
>
> What I'm no longer optimistic about is IPv6 traffic being end-to-end, with
> no middleboxes.  People are putting stateful firewalls around their IPv6
> networks, so we still need things like STUN and TURN in order to cross
> these firewalls.  And I have it on good authority that people are doing
> NAT in IPv6.  Granted, it's 1-to-1 NAT, not NAPT, but it's still NAT.
>
> And then there's the issue of corporate firewalls (that whitelist web
> traffic and Zoom, because the web and Zoom are supposedly not threats, but
> block anything else).  And don't get me started on state-sponsored
> firewalls (China, of course, but also Russia and other petrodictatorships).
>
>>> ICE is still required, since both address selection and blackhole
>>> detection are done by ICE.
>> This is not a problem in my case.  IPv6 in the clear, no NAT.
> How I wish that were true!
>
> There's the issue of the client-side firewall.  If it's a simple stateful
> firewall, as in most residential networks, then you need ICE in order
> to ensure that the first packet in a UDP flow goes from client to server.
> If it's a fascist corporate firewall that blocks all non-web traffic, then
> you need a TURN server on port 443 (and preferably more than one, on
> different IP ranges).
>
> Even when there's no firewall, ICE is the mechanism that allows Galene to
> detect that a UDP flow is no longer functioning, and therefore to reliably
> restart a flow after a UDP outage: it detects the case when UDP suddenly
> gets filtered but the TCP WebSocket remains functional.
>
> -- Juliusz
> _______________________________________________
> Galene mailing list -- galene@lists.galene.org
> To unsubscribe send an email to galene-leave@lists.galene.org

-- 
IPv6 is the future, the future is here
http://ipv6hawaii.org/

[Galene] Re: IPv6 and ICE [was: galene on IPv6 only]

[Craig Miller]

I think the goal needs to be better described.

In an IPv6-only environment, there is NO NAT. Yes there is a stateful 
firewall, but ports are opened to destinations in a DMZ network for 
services offered from the DMZ.

For Galene, if a pool of UDP ports were be defined, then that pool could 
be opened in the stateful firewall allowing incoming UDP to the Galene 
server. There would be no need for ICE or STUN, since those address/port 
destinations would be available to the internet.

Craig...

On 3/21/26 04:44, Juliusz Chroboczek wrote:
> I'm separating this into its own thread, so we can focus on Galene
> improvements in the main thread.
>
>>> I, too, used to be optimistic about IPv6 ;-)
>> That is another discussion.  So I'll try to be brief.
> No need to be brief, people who are not interested will hit delete.
>
>> Even here in the laggard US more consumer ISPs are offering IPv6
>> either enabled by default or enabled on request.
> Oh, fully agreed, sorry for the misunderstanding.  I have no doubts that
> IPv6 is being widely deployed.  I'm also fully committed to having Galene
> work well in v6-only networks.  (In fact, Nexedi, one of the former
> sponsors of Galene, are running a v6-only network internally, using
> reverse proxies for all v4 access.)
>
> What I'm no longer optimistic about is IPv6 traffic being end-to-end, with
> no middleboxes.  People are putting stateful firewalls around their IPv6
> networks, so we still need things like STUN and TURN in order to cross
> these firewalls.  And I have it on good authority that people are doing
> NAT in IPv6.  Granted, it's 1-to-1 NAT, not NAPT, but it's still NAT.
>
> And then there's the issue of corporate firewalls (that whitelist web
> traffic and Zoom, because the web and Zoom are supposedly not threats, but
> block anything else).  And don't get me started on state-sponsored
> firewalls (China, of course, but also Russia and other petrodictatorships).
>
>>> ICE is still required, since both address selection and blackhole
>>> detection are done by ICE.
>> This is not a problem in my case.  IPv6 in the clear, no NAT.
> How I wish that were true!
>
> There's the issue of the client-side firewall.  If it's a simple stateful
> firewall, as in most residential networks, then you need ICE in order
> to ensure that the first packet in a UDP flow goes from client to server.
> If it's a fascist corporate firewall that blocks all non-web traffic, then
> you need a TURN server on port 443 (and preferably more than one, on
> different IP ranges).
>
> Even when there's no firewall, ICE is the mechanism that allows Galene to
> detect that a UDP flow is no longer functioning, and therefore to reliably
> restart a flow after a UDP outage: it detects the case when UDP suddenly
> gets filtered but the TCP WebSocket remains functional.
>
> -- Juliusz
> _______________________________________________
> Galene mailing list -- galene@lists.galene.org
> To unsubscribe send an email to galene-leave@lists.galene.org

-- 
IPv6 is the future, the future is here
http://ipv6hawaii.org/

[Galene] Re: IPv6 and ICE [was: galene on IPv6 only]

[Curtis Villamizar]

In message <87ikapo195.wl-jch@irif.fr>
Juliusz Chroboczek writes:
 
> I'm separating this into its own thread, so we can focus on Galene
> improvements in the main thread.

Good idea.

> >> I, too, used to be optimistic about IPv6 ;-)
> > 
> > That is another discussion.  So I'll try to be brief.
>  
> No need to be brief, people who are not interested will hit delete.
>  
> > Even here in the laggard US more consumer ISPs are offering IPv6
> > either enabled by default or enabled on request.
>  
> Oh, fully agreed, sorry for the misunderstanding.  I have no doubts that
> IPv6 is being widely deployed.  I'm also fully committed to having Galene
> work well in v6-only networks.  (In fact, Nexedi, one of the former
> sponsors of Galene, are running a v6-only network internally, using
> reverse proxies for all v4 access.)
>  
> What I'm no longer optimistic about is IPv6 traffic being end-to-end, with
> no middleboxes.  People are putting stateful firewalls around their IPv6
> networks, so we still need things like STUN and TURN in order to cross
> these firewalls.  And I have it on good authority that people are doing
> NAT in IPv6.  Granted, it's 1-to-1 NAT, not NAPT, but it's still NAT.
>  
> And then there's the issue of corporate firewalls (that whitelist web
> traffic and Zoom, because the web and Zoom are supposedly not threats, but
> block anything else).  And don't get me started on state-sponsored
> firewalls (China, of course, but also Russia and other petrodictatorships).

So we can agree that some people need to support IPv6 and NAT on their
server.  Therefore galene needs to support ICE.

> >> ICE is still required, since both address selection and blackhole
> >> detection are done by ICE.
>  
> > This is not a problem in my case.  IPv6 in the clear, no NAT.
>  
> How I wish that were true!

It is true in my case since I am not serving the masses but rather a
small group of people.

> There's the issue of the client-side firewall.  If it's a simple stateful
> firewall, as in most residential networks, then you need ICE in order
> to ensure that the first packet in a UDP flow goes from client to server.
> If it's a fascist corporate firewall that blocks all non-web traffic, then
> you need a TURN server on port 443 (and preferably more than one, on
> different IP ranges).
>  
> Even when there's no firewall, ICE is the mechanism that allows Galene to
> detect that a UDP flow is no longer functioning, and therefore to reliably
> restart a flow after a UDP outage: it detects the case when UDP suddenly
> gets filtered but the TCP WebSocket remains functional.

So you seem to be saying that galene needs ICE.  That is different
from I need ICE (for any reason other than getting galene to work).

> -- Juliusz

If that is true that galene can't function without ICE then I can stop
chasing down failures to display video.

I'd prefer my galene neat rather than on ice.  :)  Thanks,

Curtis

[Galene] Re: IPv6 and ICE [was: galene on IPv6 only]

[Curtis Villamizar]

In message <e864dc2c-2164-4d6c-8863-ffc1a658c193@gmail.com>
Craig Miller writes:
 
> I think the goal needs to be better described.

I'm not sure there was a goal here.  This was a discussion of why
supporting NAT even when running IPv6 is needed.  For the case of the
galene software Juliusz makes a convincing case that it is needed.

> In an IPv6-only environment, there is NO NAT. Yes there is a stateful 
> firewall, but ports are opened to destinations in a DMZ network for 
> services offered from the DMZ.

In my case there are no NATs in the way.  I'm testing at home so I
made sure that there would be no NAT by tunneling IPv6 past my ISP (in
IPv4) directly to a host at the datacenter.  Since this case isn't
working it may be that gelene doesn't just support ICE, it needs ICE
to function.  Just speculative, waiting for Juliusz to confirm.

Late breaking (or unbroken) news.  I just tried with the built in TURN
serve enabled and it works.  So yes, it appears galene needs ICE.
That would be a bug IMHO but I'm not sure my opinion matters enough to
make it worth addressing unless it bugs me enough for me to (attempt
to) "fix" the code.  Seems harmless so maybe doesn't need fixing.

> For Galene, if a pool of UDP ports were be defined, then that pool could 
> be opened in the stateful firewall allowing incoming UDP to the Galene 
> server. There would be no need for ICE or STUN, since those address/port 
> destinations would be available to the internet.

Good workaround for that case.  Thanks.

> Craig...

Curtis

> On 3/21/26 04:44, Juliusz Chroboczek wrote:
> > I'm separating this into its own thread, so we can focus on Galene
> > improvements in the main thread.
> >
> >>> I, too, used to be optimistic about IPv6 ;-)
> >> That is another discussion.  So I'll try to be brief.
> > No need to be brief, people who are not interested will hit delete.
> >
> >> Even here in the laggard US more consumer ISPs are offering IPv6
> >> either enabled by default or enabled on request.
> > Oh, fully agreed, sorry for the misunderstanding.  I have no doubts that
> > IPv6 is being widely deployed.  I'm also fully committed to having Galene
> > work well in v6-only networks.  (In fact, Nexedi, one of the former
> > sponsors of Galene, are running a v6-only network internally, using
> > reverse proxies for all v4 access.)
> >
> > What I'm no longer optimistic about is IPv6 traffic being end-to-end, with
> > no middleboxes.  People are putting stateful firewalls around their IPv6
> > networks, so we still need things like STUN and TURN in order to cross
> > these firewalls.  And I have it on good authority that people are doing
> > NAT in IPv6.  Granted, it's 1-to-1 NAT, not NAPT, but it's still NAT.
> >
> > And then there's the issue of corporate firewalls (that whitelist web
> > traffic and Zoom, because the web and Zoom are supposedly not threats, but
> > block anything else).  And don't get me started on state-sponsored
> > firewalls (China, of course, but also Russia and other petrodictatorships).
> >
> >>> ICE is still required, since both address selection and blackhole
> >>> detection are done by ICE.
> >> This is not a problem in my case.  IPv6 in the clear, no NAT.
> > How I wish that were true!
> >
> > There's the issue of the client-side firewall.  If it's a simple stateful
> > firewall, as in most residential networks, then you need ICE in order
> > to ensure that the first packet in a UDP flow goes from client to server.
> > If it's a fascist corporate firewall that blocks all non-web traffic, then
> > you need a TURN server on port 443 (and preferably more than one, on
> > different IP ranges).
> >
> > Even when there's no firewall, ICE is the mechanism that allows Galene to
> > detect that a UDP flow is no longer functioning, and therefore to reliably
> > restart a flow after a UDP outage: it detects the case when UDP suddenly
> > gets filtered but the TCP WebSocket remains functional.
> >
> > -- Juliusz

[... trim ...]

[Galene] Re: galene on IPv6 only

[Curtis Villamizar]

replying to myself ...

In message <cmu-lmtpd-35891-1774022493-0@mda62.andover.occnc.com>
Curtis Villamizar writes:
> 
> In message <874imask25.wl-jch@irif.fr>
> Juliusz Chroboczek writes:
>  
> > Hello,
> >  
> > > It looks like galene does not want to work on an IPv6 only server.
> >  
> > Thanks a lot for your testing, that's the kind of deployment that we
> > should be supporting.
> >  
> > > I also get messages related to IPv4-ish stuff.
> > >   Failed to enable mDNS over IPv4:
> > >     (listen udp4 224.0.0.0:5353: socket: protocol not supported)
> >  
> >  
> > mDNS is disabled by default for a very long time.  See galene.go line 49:
> >  
> >     flag.BoolVar(&group.UseMDNS, "mdns", false, "gather mDNS addresses")
> >  
> > I think the issue here is that UseMDNS is not obeyed by the relay test.
> > I'll fix that ASAP.
>  
> Thanks.  Very responsive on your part.

It seems mDNS is attempted for some reason if relay test fails.
Otherwise no issue.

> > >   Relay test failed: timeout 2026/03/19 07:41:38
> > >     Perhaps you didn't configure a TURN server?
> > >   TURN: no public addresses
> > > 
> > > The second message is benign and only indicates the relayTest() test
> > > has failed even though it should not be run if there is no IPv4.
> >  
> > RelayTest is run unconditionally, since it should be successful with an
> > IPv6 TURN server.  The issue here is that the built-in TURN server does
> > not implement RFC 6156, you need to use Coturn or some other full-featured
> > TURN server.

Understood after your later reply on this.  btw- works fine with
builtin server and no IPv6 NAT in the way.

> There needs to be an ability to disable the loopback test.  I have no
> need for a TURN server and I think this will be common among those
> running IPv6 only.

Still would be nice but since I may be the only one asking for this
I'll look into whether it is feasible.

> > We should probably run two relay tests, one over IPv4 and one over IPv6.
> >  
> > > This is IPv6 so no need for ICE, STUN, TURN, etc.
> >  
> > I, too, used to be optimistic about IPv6 ;-)
>  
> That is another discussion.  So I'll try to be brief.

[ ... trim ... opinions on IPv6 omitted ... ]

> > ICE is still required, since both address selection and blackhole
> > detection are done by ICE.  STUN and TURN are useful if there's a firewall
> > in the way, which sadly is often the case, even with IPv6.
>  
> This is not a problem in my case.  IPv6 in the clear, no NAT.

Maybe you can convince me on the blackhole detection.

> > > There is nothing on the local lan (its in a datacenter) so no need for
> > > mDNS and running mDNS is *very* bad form in that type of environment.
> >  
> > Yes, mDNS is disabled by default.  I need more information to understand
> > why it's not being disabled in your case.
>  
> With the admitedly kludgy patch the problem is gone so maybe it was
> the relay test which I now disabled.  That saying, I didn't look at
> the code much.

Now conditionally disabled in latest patch.

> > > If instead of using the IPv6 address inside [] I use the host name, then
> > > not solved.  Even though the host has an AAAA DNS record and no
> > > A record, the bind does not work if the host name is specified.  This
> > > may be an upstream problem in the go net library.
> >  
> > Interesting.  I'll see if I can reproduce it.
>  
> That's with my kludgy patch.  Maybe standby and I'll put together a
> more robust patch.

Somewhat less kludgy patch provided for your entertainment and feedback.

> Up and sort of running but I still need some work.  This would have
> gone a lot faster if there were better documentation and better
> diagnostics on json issues.  I have to say that initial setup was
> somewhat painful.  I'll let you if there are any further problems that
> are not unique to my misconfiguration.  I'll try to help rather than
> just whine.
>  
> > -- Juliusz
> > _______________________________________________
> > Galene mailing list -- galene@lists.galene.org
> > To unsubscribe send an email to galene-leave@lists.galene.org

Seems the problem is some go functions in the standard library want
tcp6 rather than TCP when running on FreeBSD (and probably *BSD but
not confirmed).  Some short(ish) patches are attached.  You may not
want to take the disable-turn patches (or any at this point).
Comments welcome and encouraged.

Main change is verbosely named GetTCPProtoOfAddrString function that
takes the address string and returns a protocol name of tcp4 for IPv4
only, tcp6 for IPv6 only, and tcp for dual stack (which won't work for
the IPv6 port), and tcp for unknown (ie: :8443 with no addr).

This approach needs improvement but this is the less kludgy 2nd
iteration.  I think what should happen for FreeBSD is two or more
listens in the dual stack case with the port only format looking at
all interface addresses and creating a listen for each one.

This patch works for the IPv6 only case.  Using -disable-relay-test
suppresses the relay test and therefore nMDS getting tried and the
relay test failed complaint in the log.  I still get "TURN: no public
addresses" in the log but everything works.  With -disable-turn I
don't get video or audio.

I should be able to "borrow" a global routable IPv4 address for the
purpose of testing dual stack, even though they are in short supply.

Curtis


--- galene.go.orig	2025-08-09 10:26:35.000000000 -0400
+++ galene.go	2026-03-21 17:29:18.061013000 -0400
@@ -26,6 +26,7 @@
 func main() {
 	var cpuprofile, memprofile, mutexprofile, httpAddr string
 	var udpRange string
+	var disableturn, disablerelaytest bool
 
 	flag.StringVar(&httpAddr, "http", ":8443", "web server `address`")
 	flag.StringVar(&webserver.StaticRoot, "static", "./static/",
@@ -47,12 +48,22 @@
 	flag.StringVar(&udpRange, "udp-range", "",
 		"UDP `port` (multiplexing) or port1-port2 (range)")
 	flag.BoolVar(&group.UseMDNS, "mdns", false, "gather mDNS addresses")
+	flag.BoolVar(&disablerelaytest, "disable-relay-test", false,
+		"disable the relay test")
+	flag.BoolVar(&disableturn, "disable-turn", false,
+		"disable TURN (if true overrides -turn)")
 	flag.BoolVar(&ice.ICERelayOnly, "relay-only", false,
 		"require use of TURN relays for all media traffic")
 	flag.StringVar(&turnserver.Address, "turn", "auto",
 		"built-in TURN server `address` (\"\" to disable)")
 	flag.Parse()
 
+	log.Printf("starting: httpAddr = %s", httpAddr)
+
+	if (disableturn) {
+		turnserver.Address = ""
+	}
+
 	if udpRange != "" {
 		if strings.ContainsRune(udpRange, '-') {
 			var min, max uint16
@@ -145,7 +156,9 @@
 	terminate := make(chan os.Signal, 1)
 	signal.Notify(terminate, syscall.SIGINT, syscall.SIGTERM)
 
-	go relayTest()
+	if ! disablerelaytest {
+		go relayTest()
+	}
 
 	ticker := time.NewTicker(15 * time.Minute)
 	defer ticker.Stop()

--- webserver/webserver.go.orig	2025-08-09 10:26:35.000000000 -0400
+++ webserver/webserver.go	2026-03-21 11:35:42.778748000 -0400
@@ -32,6 +32,55 @@
 var StaticRoot string
 
 var Insecure bool
+
+//  GetTCPProtoOfAddrString
+//    returns tcp4 if using IPv4 only
+//    returns tcp6 if using IPv6 only
+//    returns tcp if dual stack or unspecified (ie: address form ":port")
+
+func GetTCPProtoOfAddrString(address string) (string, error) {
+	host, port, err := net.SplitHostPort(address)
+	_ = port
+	if (err != nil) {
+		log.Printf("SplitHostPort: %s got error %s\n",
+			   address, err.Error())
+		return "tcp", err;
+	}
+	if (len(host) == 0) {
+		return "tcp", nil  // no host part of address
+	}
+	var addrs []string
+	addrs, err = net.LookupHost(host)
+	if (err != nil) {
+		log.Printf("LookupHost: %s got error %s\n",
+			   host, err.Error())
+		return "tcp", err;
+	}
+	var addr, proto string
+	proto = "any"
+	for i := 0; i < len(addrs); i++ {
+		addr = addrs[i]
+		if (strings.ContainsAny(addr, ":")) {
+			if (proto == "any") {
+				proto = "tcp6"
+			} else if (proto == "tcp4") {
+				proto = "tcp"
+				break
+			}
+		} else {
+			if (proto == "any") {
+				proto = "tcp4"
+			} else if (proto == "tcp6") {
+				proto = "tcp"
+				break
+			}
+		}
+	}
+	if (proto == "any") {
+		proto = "tcp"
+	}
+	return proto, nil
+}
 
 func Serve(address string, dataDir string) error {
 	http.Handle("/", &fileHandler{http.Dir(StaticRoot)})
@@ -69,12 +118,19 @@
 
 	server = s
 
-	proto := "tcp"
+	var proto string
+	var err error
 	if strings.HasPrefix(address, "/") {
 		proto = "unix"
+	} else {
+		proto, err = GetTCPProtoOfAddrString(address)
+		if (err != nil) {
+			return err
+		}
 	}
 
-	listener, err := net.Listen(proto, address)
+	var listener net.Listener
+	listener, err = net.Listen(proto, address)
 	if err != nil {
 		return err
 	}
@@ -553,7 +609,13 @@
 	}
 
 	var addr net.Addr
-	tcpaddr, err := net.ResolveTCPAddr("tcp", r.RemoteAddr)
+	proto, err := GetTCPProtoOfAddrString(r.RemoteAddr)
+	if (err != nil) {
+		log.Printf("ResolveTCPAddr: addr= %s, error= %s",
+			   r.RemoteAddr, err.Error())
+		proto = "tcp"
+	}
+	tcpaddr, err := net.ResolveTCPAddr(proto, r.RemoteAddr)
 	if err != nil {
 		log.Printf("ResolveTCPAddr: %v", err)
 	} else {

--- webserver/whip.go.orig	2025-08-09 10:26:35.000000000 -0400
+++ webserver/whip.go	2026-03-21 10:23:48.856329000 -0400
@@ -212,7 +212,15 @@
 	}
 
 	var addr net.Addr
-	tcpaddr, err := net.ResolveTCPAddr("tcp", r.RemoteAddr)
+	proto, err := GetTCPProtoOfAddrString(r.RemoteAddr)
+	if (err != nil) {
+		log.Printf("ResolveTCPAddr: addr= %s, error= %s",
+			   r.RemoteAddr, err.Error())
+		proto = "tcp"
+	}
+	log.Printf("ResolveTCPAddr: addr= %s, proto= %s",
+		   r.RemoteAddr, proto)
+	tcpaddr, err := net.ResolveTCPAddr(proto, r.RemoteAddr)
 	if err != nil {
 		log.Printf("ResolveTCPAddr: %v", err)
 	} else {