Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Impossible to use an unusual port number in local URL

  • 10 tontu
  • 1 am na jafe-jafe bii
  • 352 views
  • i mujjee tontu mooy estebann

more options

Hi all :)

From a fresh Linux Debian Bullseye I try to connect to a local machine with Firefox (v97 64-bits) by its hostname (avahi server with default domain "local") with the port 6180 bound to a remote web service port (61 is the distant machine IP and 80 is the forwarded port).

When I want to open this URL : http://bionic.local:6180/ FF displays "We can't find this site ... Unable to connect to server at bionic.local ... check your network connection and firewall"

BUT ping bionic.local works perfectly and resolve the good IP address from the Chromium navigator the same URL works without a problem, I can open the distant web site.

This workaround works : add a static resolution in the /etc/hosts file : 192.168.0.71 bionic bionic.local => so FF works in the expected way for now ! But as I said this a workaround and a bad solution.

I supposed too the port was blocked because I accessed an unusual port. So I tried this without success.

How the hell make that FF v97 allows me to use an unusual port ? Or is it bound to the domain "local" which is no more accepted by FF ?

Thank you in advance for your help. With adelphity, lnj

How to do

Hi all :) From a fresh '''Linux Debian Bullseye''' I try to connect to a local machine with Firefox ('''v97 64-bits''') by its hostname (avahi server with default domain "local") with the port '''6180''' bound to a remote web service port (61 is the distant machine IP and 80 is the forwarded port). When I want to open this URL : http://bionic.local:6180/ FF displays "We can't find this site ... Unable to connect to server at bionic.local ... check your network connection and firewall" BUT ping bionic.local works perfectly and resolve the good IP address from the Chromium navigator the same URL works without a problem, I can open the distant web site. This workaround works : add a static resolution in the /etc/hosts file : 192.168.0.71 bionic bionic.local => so FF works in the expected way for now ! But as I said this a workaround and a bad solution. I supposed too the port was blocked because I accessed an unusual port. So I tried [https://support.mozilla.org/en-US/questions/1083282 this] without success. How the hell make that FF v97 allows me to use an unusual port ? Or is it bound to the domain "local" which is no more accepted by FF ? Thank you in advance for your help. With adelphity, lnj How to do

Saafara biñ tànn

Sorry to answer so late... but I am having a lot of trouble organizing myself between my salaried activity, my passion, my private life and my health (especially not to put myself in burnout) :)

I delineated the problem more precisely and I wanted to apologize because I forgot an important thing : check which version I was using.

My install of Debian Bullseye is not as clean like I announced in the beggining because I installed Firefox v99.0 (64 bits) from the flatpak channel (mozilla-flatpak - 1.0). I do not remembered exactly why (surely to have the latest version) but I forgot this point.

Here I get the flatpak version and run it : root@host:~# flatpak info org.mozilla.firefox Firefox - Fast, Private & Safe Web Browser

         ID: org.mozilla.firefox
        Ref: app/org.mozilla.firefox/x86_64/stable
       Arch: x86_64
     Branch: stable
    Version: 99.0
    License: MPL-2.0
     Origin: flathub
 Collection: org.flathub.Stable

Installation: system

  Installed: 241,0 MB
    Runtime: org.freedesktop.Platform/x86_64/21.08
        Sdk: org.freedesktop.Sdk/x86_64/21.08
     Commit: eaa594cc6c883939651c711930c426dd873e054bc804f32a14548551cb7e55da
     Parent: fac014e055e82ba3a18677a72cbdb54578e28d6b852508539d1445e87cbc77eb
    Subject: Export org.mozilla.firefox
       Date: 2022-04-05 12:44:02 +0000

root@host:~# /usr/bin/flatpak run --branch=stable --arch=x86_64 --command=firefox --file-forwarding org.mozilla.firefox @@u %u @@

So I tried to install and run the FF Debian official package (apt install firefox-esr) which is the ESR version : user@host:~$ firefox -v Mozilla Firefox 91.7.0esr user@host:~$ firefox --no-remote &

Finally I tried to install the same standard FF version than the FF flatpak : user@host:~$ cd /data/noinstall/firefox user@host:~$ wget https://ftp.mozilla.org/pub/firefox/releases/99.0/linux-x86_64/fr/firefox-99.0.tar.bz2 user@host:~$ mkdir 99_0 user@host:~$ tar -xvf firefox-99.0.tar.bz2 -C 99_0 user@host:~$ 99_0/firefox/firefox --no-remote &

From the host bionic.local I ran this command to make a test webserver (needs python - tested with v2.7.17 in my case) : root@bionic:~# python -m SimpleHTTPServer 6181 Serving HTTP on 0.0.0.0 port 6181 ... ...

And from the different versions I tried to open the same URL http://bionic.local:6181 :

  • With FF v91.7.0-esr => it displays the contents of the directory from which I ran the webserver
  • With FF flatpak v99.0 => Address not found
  • With FF v99.0 (standard) => it displays the contents of the directory from which I ran the webserver

Note : for FF flatpak if I replace the domain with its IP which gives (in my case http://192.168.0.71:6181), the content is yet displayed by magic ...

=> so I conclude that the problem is not related to ports but is related to some domains like the local zeroconf default domain with FF v99 flatpak, and potentially other FF flatpak packages !


Chris Ilias said

WARNING: Changing preferences through the about:config interface is not officially supported Hidden settings edited using the about:config tool are explicitly not supported, which means that Mozilla makes no guarantees they will be supported in the future, or that Mozilla will fix them if they break. Mozilla does not test these preferences, and will not in the future. That includes security and performance testing which these preferences may affect.

OK, I did not know about this limitation... I am sad to see that in an Open Source project, the user will see his rights gradually being restricted and could no longer use the application at his convenience ...

cor-el said

You can find "Edit this question" under the "Question Tools" menu in the sidebar. For a reply, Edit is in the three dot menu next to a reply.

Yes thank you, I missed it and I saw it after writing my new posts ;)

Jàng tontu lii ci fi mu bokk 👍 0

All Replies (10)

more options

I'm not sure if this is about the port number as it can also be about resolving the local host name to an IP address (i.e a DNS issue).

You can try to add this domaint to the network.dns.localDomains pref.

  • about:config => network.dns.localDomains = "bionic.local"

See also the DNS Lookup tool on the about:networking psge.

WARNING: Changing preferences through this interface not officially supported Hidden settings edited using the about:config tool are explicitly not supported, which means that Mozilla makes no guarantees they will be supported in the future, or that Mozilla will fix them if they break. Mozilla does not test these preferences, and will not in the future. That includes security and performance testing which these preferences may affect.

[Warning added by moderator]

Chris Ilias moo ko soppali ci

more options

cor-el said

You can try to add this domaint to the network.dns.localDomains pref.
  • about:config => network.dns.localDomains = "bionic.local"
I never noticed that preference before. If this problem occurs while DNS over HTTPS is in use, I was going to suggest adding it to network.trr.excluded-domains (especially if network.trr.mode is set to 3).
more options

Hello everybody and thank you for your help :)

cor-el said

I'm not sure if this is about the port number as it can also be about resolving the local host name to an IP address (i.e a DNS issue). You can try to add this domaint to the network.dns.localDomains pref.
  • about:config => network.dns.localDomains = "bionic.local"

Nope that does not working. I tried the strings bionic.local and local (as network.dns.localDomains suggests a domain and not a machine). None working.

cor-el said

See also the DNS Lookup tool on the about:networking psge.

Ok I do not know these tools so thank you :).

When I try to resolve with DNS search tab with the domains strings bionic.local and local I obtain : NS_ERROR_UNKNOWN_HOST

When I look in HTTP tab I see :

Hostname 	Port 	HTTP version SSL 	Active 	Inactive
...
bionic.local	6180	HTTP <= 1.1	false	0	0


And the logging tool gives this pastebin when I try to open http://bionic.local:6180 that I will try to decode but in a quick view I see some interesting lines :

2022-04-03 18:11:05.189275 UTC - [Parent 2: Main Thread]: D/nsHostResolver Resolving host [bionic.local]<^partitionKey=%28https%2Cbionic.local%29> - bypassing cache type 65. [this=7fda55392580]
2022-04-03 18:11:05.189294 UTC - [Parent 2: Main Thread]: D/nsHostResolver Subdomain [local] of host [bionic.local] Is Excluded From TRR via pref
2022-04-03 18:11:05.189311 UTC - [Parent 2: Main Thread]: D/nsHostResolver   No usable record in cache for host [bionic.local] type 65.


So D/nsHostResolver Subdomain [local] of host [bionic.local] Is Excluded From TRR via pref is the node of the problem in my opinion.

jscher2000 - Support Volunteer said

You can try to add this domaint to the network.dns.localDomains pref.
  • about:config => network.dns.localDomains = "bionic.local"
I never noticed that preference before. If this problem occurs while DNS over HTTPS is in use, I was going to suggest adding it to network.trr.excluded-domains (especially if network.trr.mode is set to 3).

OK this confirms what I discovered in the log : the TRR (Trusted Recursive Resolver) for DoH (DNS-over-HTTPS), but I find it strange to discuss about HTTPS because in my case I try a HTTP (without SSL) URL.

In my case network.trr.excluded-domains is set to "0" (Off, default, which do not use TRR at all).

So I tried local for network.trr.excluded-domains without more success !

But I think I am heating up and heading in the right direction ... :)

more options

estebann said

In my case network.trr.excluded-domains is set to "0" (Off, default, which do not use TRR at all). So I tried local for network.trr.excluded-domains without more success !

I think it is meant to contain a comma separated list of domain names that need to be looked up in local DNS, for example:

network.trr.excluded-domains => bionic.local

more options

jscher2000 - Support Volunteer said

estebann said

In my case network.trr.excluded-domains is set to "0" (Off, default, which do not use TRR at all). So I tried local for network.trr.excluded-domains without more success !

I think it is meant to contain a comma separated list of domain names that need to be looked up in local DNS, for example:

network.trr.excluded-domains => bionic.local

I tried both without success !

In fact I asked to myself if testing the string bionic.local is relevant as for me it is not a domain but a FQDN.

Also as now I understand a little more the process, I noticed after the lines I reported from the log (see this pastebin link), a strange line : 2022-04-03 18:11:05.189351 UTC - [Parent 2: Main Thread]: D/nsHostResolver NameLookup: bionic.local effectiveTRRmode: 1 flags: 201

In my case network.trr.mode is set to 0 so why the log reports an effectiveTRRmode to 1

Ultimately, wouldn't that look like a bug ?

estebann moo ko soppali ci

more options

@modos : error as I did not seen that we can edit our old posts

estebann moo ko soppali ci

more options

@modos : error as I did not seen that we can edit our old posts

estebann moo ko soppali ci

more options

WARNING: Changing preferences through the about:config interface is not officially supported Hidden settings edited using the about:config tool are explicitly not supported, which means that Mozilla makes no guarantees they will be supported in the future, or that Mozilla will fix them if they break. Mozilla does not test these preferences, and will not in the future. That includes security and performance testing which these preferences may affect.

more options

You can find "Edit this question" under the "Question Tools" menu in the sidebar. For a reply, Edit is in the three dot menu next to a reply.

more options

Saafara yiñ Tànn

Sorry to answer so late... but I am having a lot of trouble organizing myself between my salaried activity, my passion, my private life and my health (especially not to put myself in burnout) :)

I delineated the problem more precisely and I wanted to apologize because I forgot an important thing : check which version I was using.

My install of Debian Bullseye is not as clean like I announced in the beggining because I installed Firefox v99.0 (64 bits) from the flatpak channel (mozilla-flatpak - 1.0). I do not remembered exactly why (surely to have the latest version) but I forgot this point.

Here I get the flatpak version and run it : root@host:~# flatpak info org.mozilla.firefox Firefox - Fast, Private & Safe Web Browser

         ID: org.mozilla.firefox
        Ref: app/org.mozilla.firefox/x86_64/stable
       Arch: x86_64
     Branch: stable
    Version: 99.0
    License: MPL-2.0
     Origin: flathub
 Collection: org.flathub.Stable

Installation: system

  Installed: 241,0 MB
    Runtime: org.freedesktop.Platform/x86_64/21.08
        Sdk: org.freedesktop.Sdk/x86_64/21.08
     Commit: eaa594cc6c883939651c711930c426dd873e054bc804f32a14548551cb7e55da
     Parent: fac014e055e82ba3a18677a72cbdb54578e28d6b852508539d1445e87cbc77eb
    Subject: Export org.mozilla.firefox
       Date: 2022-04-05 12:44:02 +0000

root@host:~# /usr/bin/flatpak run --branch=stable --arch=x86_64 --command=firefox --file-forwarding org.mozilla.firefox @@u %u @@

So I tried to install and run the FF Debian official package (apt install firefox-esr) which is the ESR version : user@host:~$ firefox -v Mozilla Firefox 91.7.0esr user@host:~$ firefox --no-remote &

Finally I tried to install the same standard FF version than the FF flatpak : user@host:~$ cd /data/noinstall/firefox user@host:~$ wget https://ftp.mozilla.org/pub/firefox/releases/99.0/linux-x86_64/fr/firefox-99.0.tar.bz2 user@host:~$ mkdir 99_0 user@host:~$ tar -xvf firefox-99.0.tar.bz2 -C 99_0 user@host:~$ 99_0/firefox/firefox --no-remote &

From the host bionic.local I ran this command to make a test webserver (needs python - tested with v2.7.17 in my case) : root@bionic:~# python -m SimpleHTTPServer 6181 Serving HTTP on 0.0.0.0 port 6181 ... ...

And from the different versions I tried to open the same URL http://bionic.local:6181 :

  • With FF v91.7.0-esr => it displays the contents of the directory from which I ran the webserver
  • With FF flatpak v99.0 => Address not found
  • With FF v99.0 (standard) => it displays the contents of the directory from which I ran the webserver

Note : for FF flatpak if I replace the domain with its IP which gives (in my case http://192.168.0.71:6181), the content is yet displayed by magic ...

=> so I conclude that the problem is not related to ports but is related to some domains like the local zeroconf default domain with FF v99 flatpak, and potentially other FF flatpak packages !


Chris Ilias said

WARNING: Changing preferences through the about:config interface is not officially supported Hidden settings edited using the about:config tool are explicitly not supported, which means that Mozilla makes no guarantees they will be supported in the future, or that Mozilla will fix them if they break. Mozilla does not test these preferences, and will not in the future. That includes security and performance testing which these preferences may affect.

OK, I did not know about this limitation... I am sad to see that in an Open Source project, the user will see his rights gradually being restricted and could no longer use the application at his convenience ...

cor-el said

You can find "Edit this question" under the "Question Tools" menu in the sidebar. For a reply, Edit is in the three dot menu next to a reply.

Yes thank you, I missed it and I saw it after writing my new posts ;)

estebann moo ko soppali ci