Upstream report closed "RESOLVED WORKSFORME" on 2019-02-18
Issue resolved by making changes outside of Firefox
Closing as "Invalid" - status to match upstream status
** Changed in: firefox (Ubuntu)
Status: Confirmed => Invalid
--
You received this bug notification because you are a
** Changed in: firefox
Status: New => Invalid
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently can't connect to the server
Status in Mozilla
No worries, Michal. Thank you for your help diagnosing to this level.
I'm rolling along just fine with WINS removed from my nsswitch.conf and
am happy to have helped reach a conclusion on this bug.
--
You received this bug notification because you are a member of Desktop
Packages, which is
I'm closing this as WFM because the bug isn't limited only to firefox.
Any application that calls getaddrinfo quickly enough will trigger it.
Rex, I didn't find anything strange in any config file you've posted. I
tried to reproduce it on Fedora and Valentin tried it on Ubuntu, but we
were unable
Michal, I'm assigning this to you just to get it off the triage list,
leaving UNCONFIRMED. Feel free to revert or anything you seem more fit
for this bug. Thanks.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
Created attachment 9042128
2019-02-07MorningLogs.zip
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently can't connect to the server
Status in Mozilla
Created attachment 9042129
smb.conf
Current smb.conf file with active shares removed.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently can't connect to
Now, it seems to resolve normally. I guess firefox shouldn't fail
anymore. Please, test it for a while without wins resolving. I'm not
sure what's exactly wrong, but according to the rule in nsswitch.conf
dns request should be sent when the host isn't found using wins and
because no request is
Good find Michal! I'm not able to easily reproduce the issue in the old
beta or 66.0a1 alpha. I will continue my normal browsing across the
firefox versions and report if it recurs.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox
Created attachment 9041206
2019-02-04logs.zip
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently can't connect to the server
Status in Mozilla Firefox:
Created attachment 9041298
2019-02-04 afternoon logs.zip
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently can't connect to the server
Status in Mozilla
Created attachment 9042103
test with pauses
(In reply to rex from comment #79)
> Firefox continues to resolve addresses correctly.
>
> Do we know of a difference between Firefox and Chromium in how they interact
> with wins? This may provide further answers as to why Firefox has difficulty
>
Good thinking Michal.
I've put wins back in nsswitch.conf.
Running "make" in the new test directory seems to give good terminal output:
gcc -shared -ldl -fPIC log_getaddrinfo_errors.c -o log_getaddrinfo_errors.so
rm -f logs/*.txt
./run_test.sh
A zip file of the new resulting logs and my
Firefox continues to resolve addresses correctly.
Do we know of a difference between Firefox and Chromium in how they
interact with wins? This may provide further answers as to why Firefox
has difficulty with wins in my system whereas Chromium does not.
--
You received this bug notification
Created attachment 9040821
2019-02-01 HTTP Log
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently can't connect to the server
Status in Mozilla Firefox:
Created attachment 9040823
2019-02-01 HTTP Log-Child
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently can't connect to the server
Status in Mozilla
Yes, there are changes! Below is the terminal output, and the attached logs
follow.
gcc -shared -ldl -fPIC log_getaddrinfo_errors.c -o log_getaddrinfo_errors.so
rm -f logs/*.txt
./run_test.sh
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed
Created attachment 9041202
test.tgz
getaddrinfo fails with EAI_SYSTEM and errno should contain details, but
it's 0.
Could you please extract the attached archive and run "make" in the
extracted directory? It should generate few files in logs directory. I'm
curious whether getaddrinfo called from
Is there any change if you remove wins resolving? I.e. in
/etc/nsswitch.conf change line "hosts: files wins dns" to "hosts: files
dns" and rerun the test.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
Created attachment 9040820
2019-02-01 Fail to Resolve Google
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently can't connect to the server
Status in
Can do, Michal. Below is what printed in the terminal, and the attached logs
follow.
gcc -shared -ldl -fPIC log_getaddrinfo_errors.c -o log_getaddrinfo_errors.so
rm -f logs/*.txt
./run_test.sh
Makefile:5: recipe for target 'test' failed
make: *** [test] Error 1
--
You received this bug
Firefox 66.0a1 running with with that LD_Preload appears to not be able
to resolve any address. :(
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently can't
Thanks Michal. Are you interested in just the terminal output, or would
you still like the HTTP log with MOZ_LOG set to something?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Created attachment 9040578
log_getaddrinfo_errors.c
You could give this version a try. It only prints error message in case
of failure. Use it as the other versions, i.e. compile with:
gcc -shared -ldl -fPIC log_getaddrinfo_errors.c -o
log_getaddrinfo_errors.so
And run it with the official
Created attachment 9040503
ZIP file of HTTP logs, success at reaching google.com, fail at reaching bing.com
These logs were produced using the plain 66.0a1 firefox with
MOZ_LOG=timestamp,GetAddrInfo:5. Firefox successfully resolved
google.com, but failed to resolve bing.com
--
You received this
Created attachment 9040195
pcap for failed request for reddit.com
Was built via 'sudo tcpdump -w /tmp/dump.pcap -s 0 udp and port 53' and
was active when requesting reddit.com. Appears to be empty.
--
You received this bug notification because you are a member of Desktop
Packages, which is
(In reply to rex from comment #60)
> I am able to reproduce the issue with the plain 66.0a1 alpha from a shell
> script or otherwise.
>
> I am not able to reproduce the issue with the plain 66.0a1 alpha from a shell
> script that calls out:
> export
I am able to reproduce the issue with the plain 66.0a1 alpha from a
shell script or otherwise.
I am not able to reproduce the issue with the plain 66.0a1 alpha from a shell
script that calls out:
export MOZ_LOG=timestamp,sync,GetAddrInfo:5,nsHostResolver:5
export MOZ_LOG_FILE=./2019-01-31log.txt
I see. I attempted the special build with
MOZ_LOG=timestamp,GetAddrInfo:5 just in case but am still unable to
reproduce the issue. I will keep it running and logging in case it is a
rare occurrence for whatever reason.
--
You received this bug notification because you are a member of Desktop
Can you please try a special build where I've added a code to log error
returned by GetAddrInfo? The try push is here:
https://treeherder.mozilla.org/#/jobs?repo=try=a9fbc1eae0ad3b6989fd2d2e42b449ae371f8ca0=225192845
Linux builds can be downloaded from:
32-bit -
Thanks, unfortunately this log doesn't contain useful information. I
suggested it mainly to check if removing sync helps with reproducing.
Helpful would be the log from my version which logs the error code.
--
You received this bug notification because you are a member of Desktop
Packages, which
Thanks for the special build, Michal! I've downloaded the 64 bit Linux
build you linked, and am running the following script to produce the
desired log file:
#! /bin/bash
export MOZ_LOG=timestamp,sync,GetAddrInfo:5,nsHostResolver:5
export MOZ_LOG_FILE=~/Desktop/log.txt
./firefox
However, I have
Give a try to both versions. And if it's not reproducible in this 66.0a1
build but is reproducible in 65.0b8, I'll create a testing build from
the same source tree.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
(In reply to rex from comment #50)
> Gladly!
> With only 'nameserver 217.23.2.11' in my /etc/resolv.conf and running sudo
> /etc/init.d/dns-clean start, I appear to be completely unable to resolve any
> name in any of my internet browsers. The dump.pcap simply shows entries like
> 'Standard
I think I've run into some voodoo.
I updated my /etc/resolv.conf to:
nameserver 217.23.2.11
nameserver 8.8.8.8
nameserver 127.0.1.1
and then ran:
sudo /etc/init.d/dns-clean start
as described here: https://tecadmin.net/flush-dns-cache-ubuntu/
In using firefox without any hook, I still
Thanks Michal. From using the dig command, it seems clear that what my
ISP is providing is not a working DNS server. I have changed my top
level router to distribute 8.8.8.8, 8.8.4.4, and 1.1.1.1 as my DNS
servers, and it appears to have propagated correctly.
I've set my /etc/resolv.conf to just
Could you please put only "nameserver 217.23.2.11" to /etc/resolv.conf
and provide HTTP log (the same as in comment #13) and dump of DNS
packets when the failure happens? Use tcpdump to dump the DNS packets:
sudo tcpdump -w /tmp/dump.pcap -s 0 udp and port 53 and host 217.23.2.11
--
You
Created attachment 9039811
tcpdump for 8.8.8.8 dns with cnn.com failing at the end
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently can't connect to the
Created attachment 9040193
HTTP log for failed attempt for reddit.com
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently can't connect to the server
Status
Gladly!
With only 'nameserver 217.23.2.11' in my /etc/resolv.conf and running sudo
/etc/init.d/dns-clean start, I appear to be completely unable to resolve any
name in any of my internet browsers. The dump.pcap simply shows entries like
'Standard query 0x3347 A www.yahoo.com'.
With only
Created attachment 9039812
tcpdump for port 53 with google.com failing at the end
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently can't connect to the
Functions from glibc should be called in both cases (with the LD_PRELOAD
as well as without it). Do you run the same firefox binary with the same
environment? I.e. when running firefox without the hook, do you run it
from console as well? Also, does LD_PRELOAD variable contain anything by
default?
(In reply to rex from comment #21)
> I had some issues with DNSoverHTTPS. I'm thinking firefox had intermittent
> difficulty resolving the host from which I was supposed to do dns services
> with.
>
I would like to understand this: Can you explain what was the issue? How
did firefox behave:
Could you please also provide you DNS setup? Content of /etc/resolv.conf
and line beginning with "hosts" from /etc/nsswitch.conf. If your
resolv.conf contains 127.0.0.53 then also an output from "systemd-
resolve --status".
--
You received this bug notification because you are a member of
:michal, could you take a look at comment #24?
Do you have any idea why this issue is not reproducible with the hook?
Thanks.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Created attachment 9038810
hook3_test1
Thanks for doing the test. Please, try this new file. It only intercepts
the function call but does nothing with the result.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
With this one it looks like I cannot resolve any address.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently can't connect to the server
Status in Mozilla
It should work. Did it compile without any warning?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently can't connect to the server
Status in Mozilla
Where I've spent a little under three business days running the firefox
beta and hook with no issues, I was able to reproduce the issue without
the hook in a minute.
Again I apologize for the following speculation about something I
completely do not understand. I think this issue occurs when
You could try to put ISP's DNS servers to /etc/resolv.conf to make sure
dnsmasq doesn't mess anything up.
I still don't understand why nothing is resolved when hook3_test1.so is
preloaded. I will try to come with something else later.
--
You received this bug notification because you are a
Created attachment 903
Child HTTP log for doh only for google.com
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently can't connect to the server
Status
Hey Michal, sorry if I completely misunderstand, but does your hook ask
the system to resolve the address before firefox makes the attempt? I
have a hunch that, where firefox would fail to resolve an address, if
another program or service had already resolved the address, firefox
would succeed.
Good questions Michal. I had been running firefox without the hook
outside the console, where I was running with the hook in the console.
Turns out the issue persists without the hook in the console though.
I couldn't find how to determine what my LD_PRELOAD variable is by
default, but I ran a
$ resolvectl status
resolvectl: command not found
$ sudo netstat -u -l -p -n | grep -e ":53[[:space:]]"
udp0 0 127.0.1.1:530.0.0.0:*
2325/dnsmasq
--
You received this bug notification because you are a member of Desktop
Packages, which is
I had some issues with DNSoverHTTPS. I'm thinking firefox had
intermittent difficulty resolving the host from which I was supposed to
do dns services with.
For the hook3.c program, I've run it with firefox normally for the few
business days since the time of Michal's post without the issue
Created attachment 9038886
Main HTTP log for doh only for google.com
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently can't connect to the server
Status
(In reply to rex from comment #39)
> Hi :michal, using the gcc command for either one now is about
instantaneous and produces no stderr output.
I meant the output when you run it. You should have output like this in
the console:
getaddrinfo node=detectportal.firefox.com, service=(null),
> I couldn't find how to determine what my LD_PRELOAD variable is by
default, but I ran a script with 'echo "LD_PRELOAD IS ${LD_PRELOAD}"'
and starting up firefox which did not return anything after "LD_PRELOAD
IS ". Not sure if that is applicable though. Is there a different way I
should check?
(In reply to rex from comment #36)
> :michal, it took about 5 seconds to compile and did not return anything to
> the terminal.
>
> :dragana, yes, I did not seem to be able to resolve any addresses and only
> hit server not found pages. Though I had not tested with an IP address as my
>
Hi :michal, using the gcc command for either one now is about
instantaneous and produces no stderr output.
Hi :dragana, I agree mode 2 would make sense long term, but my
intentions for testing was pure doh since currently dns isn't a solid
fallback. I'll attach the log in just a moment.
--
You
(In reply to rex from comment #21)
> I had some issues with DNSoverHTTPS. I'm thinking firefox had
intermittent difficulty resolving the host from which I was supposed to
do dns services with.
You can use the network.trr.bootstrapAddress pref to set the IP of the DoH
service you want to use.
(In reply to rex from comment #23)
> Hey Michal, sorry if I completely misunderstand, but does your hook
ask the system to resolve the address before firefox makes the attempt?
I have a hunch that, where firefox would fail to resolve an address, if
another program or service had already resolved
Thanks for the explanation, :michal. Is there any chance that the hook
utility could be calling the functions differently than firefox
(especially if it was doing so incorrectly somehow) or is using a
different process to do so? I'm repeating similar results today.
Firefox+hook resolves
(In reply to rex from comment #36)
> :michal, it took about 5 seconds to compile and did not return
anything to the terminal.
So, how the output written to stderr by hook3.so (which resolves
correctly) looks like?
--
You received this bug notification because you are a member of Desktop
:michal, it took about 5 seconds to compile and did not return anything
to the terminal.
:dragana, yes, I did not seem to be able to resolve any addresses and
only hit server not found pages. Though I had not tested with an IP
address as my network.trr.uri, testing now shows the same thing. To be
Ah, thanks for clarifying Michal.
The original hook3 running firefox provides output like yours:
gethostbyname_r=myhostname, retval=0, succeeded
address: 127.0.1.1
gethostbyname_r=myhostname, retval=0, succeeded
address: 127.0.1.1
getaddrinfo node=detectportal.firefox.com, service=(null),
I've made a newhook3.c, renaming getaddrinfo to dontgetaddrinfo (heh),
used the gcc command to produce a newhook3.so, and using that new .so, I
am able to reproduce the issue.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in
(In reply to rex from comment #44)
> The original hook3 running firefox provides output like yours:
> gethostbyname_r=myhostname, retval=0, succeeded
> address: 127.0.1.1
> gethostbyname_r=myhostname, retval=0, succeeded
> address: 127.0.1.1
> getaddrinfo node=detectportal.firefox.com,
** Bug watch added: Mozilla Bugzilla #1439780
https://bugzilla.mozilla.org/show_bug.cgi?id=1439780
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently
I ran into this issue again trying to get to google.com.
The nslookup appeared to be successful, but the issue persisted after the
seemingly successful lookup:
Server: 127.0.1.1
Address:127.0.1.1#53
Non-authoritative answer:
Name: www.google.com
Address: 172.217.9.164
I will
(In reply to Dragana Damjanovic [:dragana] from comment #17)
> (In reply to Honza Bambas (:mayhemer) from comment #16)
>
> > Thanks. Dragana, Michal, Valentin, any ideas what more to check here?
>
> The only suggestion I have is to run nslookup www.cnn.com when problem occurs.
> You os does
(In reply to Honza Bambas (:mayhemer) from comment #16)
> Thanks. Dragana, Michal, Valentin, any ideas what more to check here?
In bug 1439780 there is a simple program (hook3.c) that hooks resolver
functions and dumps info to standard error, see
(In reply to Honza Bambas (:mayhemer) from comment #16)
> Thanks. Dragana, Michal, Valentin, any ideas what more to check here?
The only suggestion I have is to run nslookup www.cnn.com when problem occurs.
You os does not give us a ip address for www.cnn.com, we cannot do much about
it.
--
Created attachment 9034839
log.txt-main.8416
Started logging after the issue started while attempting to visit
CNN.com. Was given "We can’t connect to the server at www.cnn.com" page.
Started logging and hit refresh, and was shown the same page. Then
stopped logging.
--
You received this bug
rex, could you please provide HTTP logs as described here:
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
it may shade some light on this issue. thanks!
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox
(In reply to rex from comment #13)
> Created attachment 9034842
> log.txt-main.9860
>
> Aha! I started the log right before attempting to connect to CNN.com,
> received the "can't connect to the server" page, and stopped logging.
Thank you.
Looks like your local resolver has an issue:
```
Hi Honza! Thanks for the tip!
I'm currently unable to reproduce the issue at will with the current 65.0b8
beta. I will continue to use it until I notice an issue and then try to
reproduce it while logging.
--
You received this bug notification because you are a member of Desktop
Packages,
Hey Honza!
rex@ofc-ate ~ $ nslookup www.cnn.com
Server: 127.0.1.1
Address:127.0.1.1#53
Non-authoritative answer:
www.cnn.com canonical name = turner-tls.map.fastly.net.
Name: turner-tls.map.fastly.net
Address: 151.101.1.67
Name: turner-tls.map.fastly.net
Address:
Created attachment 9034842
log.txt-main.9860
Aha! I started the log right before attempting to connect to CNN.com,
received the "can't connect to the server" page, and stopped logging.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
Thanks. Dragana, Michal, Valentin, any ideas what more to check here?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently can't connect to the server
I'm clearing the needinfo request since I cannot provide info without
assistance myself.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently can't connect to
Launchpad has imported 9 comments from the remote bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=1499825.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
** Also affects: firefox via
https://bugzilla.mozilla.org/show_bug.cgi?id=1499825
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Thanks Olivier. I was able to reproduce the issue with that firefox
(63.0b14), and the upstream bug can be found at
https://bugzilla.mozilla.org/show_bug.cgi?id=1499825 .
** Bug watch added: Mozilla Bugzilla #1499825
https://bugzilla.mozilla.org/show_bug.cgi?id=1499825
--
You received this
@Rex: can you download the official firefox beta build at
https://download.mozilla.org/?product=firefox-beta-latest-
ssl=linux64=en-US and check whether that one is affected by the
issue, too?
If so, would you mind filing a bug upstream at
The issue persists in 63.0~b14+build1-0ubuntu0.16.04.1 .
I am continuing to run chromium without this issue.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: firefox (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
Public bug reported:
Intermittently while browsing old and new sites, I run into a Server Not
Found, "Hmm. We’re having trouble finding that site.", "We can’t connect
to the server" page. To workaround I will often hold down the enter key
to rapidly re-attempt to get to the page or close the tab,
88 matches
Mail list logo
