Closed Bug 1750318 Opened 3 years ago Closed 3 years ago

Failed to connect to IMAPS server (likely DNS/TRR-related) - with network.trr.mode=3 (default is 0)

Categories

(Thunderbird :: General, defect)

Unspecified
Linux
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1747320

People

(Reporter: kevin, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file)

With Thunderbird Daily build 20220114122738 attempting to open a folder on any of several IMAPS accounts in the profile results in a "Failed to connect to server $server" error. I'm unable to reproduce the error in a fresh profile after importing data from the bad profile. Bisection with mozregression --profile $bad gave me:

Last good revision: 981e6ad79c782bf84c9083332a0bac30593f472d
First bad revision: 48f3c81757e35efc3b5e47a5da907368ac091e06
Pushlog: https://hg.mozilla.org/comm-central/pushloghtml?fromchange=981e6ad79c782bf84c9083332a0bac30593f472d&tochange=48f3c81757e35efc3b5e47a5da907368ac091e06

I can confirm that 981e6ad7 is reliably good and 48f3c817 is reliably bad, although the pushlog seems to indicate that doesn't make sense. I've attached a log with MOZ_LOG=timestamp,nsHttp:5,cache2:5,nsSocketTransport:5,nsHostResolver:5,IMAP:5,IMAPCache:5 from build 20220114122738. Let me know if there's any additional info I can provide.

(Alternatively, if you'd like to write it off as profile corruption or anything else, since I can't reproduce it, that's fine with me.)

Thanks,
Kevin

I forgot to mention some important information: The profile has network.trr.mode=3. After resetting it to network.trr.mode=0, everything works fine. Changing it back to network.trr.mode=3 causes connections to fail again. (However, network.trr.mode=3 is set after importing the bad profile and doesn't reproduce the error, so the config alone is insufficient.)

And mozilla-central change from 20220113220344 (c-c 981e6ad79c782bf84c9083332a0bac30593f472d) and 20220114061606 (c-c 48f3c81757e35efc3b5e47a5da907368ac091e06.
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=afb99f2fbec3d8dd7e10978354a73bc29c3765d7&tochange=344f14b85f84dabbc7709b5fc5d23e9471060d75

Bug 1747320?
m-c changeset d4a6f5cb9b3f66a9c2282b334b087503e99c462d is backed out by m-c changeset f00c5f3ac20092dc89512735a759f25a29b42467.
So this bug is from bug 1747320, it will be fixed in next daily build.

Summary: Failed to connect to IMAPS server (likely DNS/TRR-related) → Failed to connect to IMAPS server (likely DNS/TRR-related) - with network.trr.mode=3 (default is 0)
Keywords: regression

(In reply to Takanori MATSUURA from comment #4)

Bug 1747320?
m-c changeset d4a6f5cb9b3f66a9c2282b334b087503e99c462d is backed out by m-c changeset f00c5f3ac20092dc89512735a759f25a29b42467.
So this bug is from bug 1747320, it will be fixed in next daily build.

I am unable to reproduce the issue with build 20220115103459. I think you are right about Bug 1747320. Marking as duplicate.

Also, thank you for the mozilla-central commit ranges for the Thunderbird builds! Could you describe how to find those, or point me toward some docs, so that I could do the same for future regression finding?

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE

(In reply to Takanori MATSUURA from comment #4)
Could you describe how to find those, or point me toward some docs, so that I could do the same for future regression finding?

Help -> Troubleshooting Information -> about:buildconfig
or
thunderbird-98.0a1.en-US.win64.txt file at https://archive.mozilla.org/pub/thunderbird/nightly/

(In reply to Takanori MATSUURA from comment #6)

Help -> Troubleshooting Information -> about:buildconfig
or
thunderbird-98.0a1.en-US.win64.txt file at https://archive.mozilla.org/pub/thunderbird/nightly/

Perfect! Thanks again.

Issue has been resolved. I uninstalled all Windows Updates from Jan 11 onward (2022-01 Feature update to Windows 10 21H2 and 2022-01 Quality Update to Windows 10 21H2), and also uninstalled Daily. I then reinstalled Daily from Jan 11 and let it update, and let Windows Update bring that up to date. Everything is working properly now. Not sure what the issue was, but it is now solved.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: