Closed Bug 470907 Opened 12 years ago Closed 12 years ago

Thunderbird always uses port 119 for NNTP, ignoring port configured in server settings

Categories

(MailNews Core :: Networking: NNTP, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b3

People

(Reporter: alex, Assigned: standard8)

References

Details

(Keywords: regression, Whiteboard: [has patch])

Attachments

(2 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081222 Shredder/3.0b2pre

In Thunderbird 3.0b1 and the latest Shredder build (20081222),
Thunderbird cannot read news messages if a news server uses non-standard NNTP port (as configured in Account Settings --> Server Settings --> Port). 

In my case, the local news server runs on port 2119 instead of the standard port 119. Thunderbird can download and display headers as expected. 
However, clicking on any message to display its body causes the following error:

"The connection was refused when attempting to contact 192.168.1.2:119"
(note port 119, not 2119 in the error message).

This server used to work with Thunderbird 2.0.

Reproducible: Always

Steps to Reproduce:
1. Configure a newsserver using a non-standard port different from 119.
For testing, it is possible to simply forward port 2119 to some other nntp server, using socat utility:
$ socat  TCP4-LISTEN:2119,fork,reuseaddr      TCP:news.microsoft.com:119


2. Configure new newsgroup account in Thunderbird (File-->New Account-->Newsgroup Account, enter the local server name)

3. Open settings of the newly created account, go to Server Settings, change NNTP port to 2119

4. Close account settings, right-click the account, click Subscribe

5. Subscribe to any newsgroup (microsoft.public.access), let Thunderbird download headers from the newsgroup

6. Attempt to open or preview any message by clicking it
Actual Results:  
The news message doesn't open, an error is displayed:
"The connection was refused when attempting to contact 192.168.1.2:119"
the error message shows port 119 instead of the configured port 2119

Expected Results:  
The news message should open, as connection to the server is possible (Thunderbird can obtain list of newsgroups and list of messages in the newsgroup).


Thunderbird 2.0 was working without any problem in the same configuration
This works fine for me with my local tests.

Can you try getting a protocol log as described here: https://wiki.mozilla.org/MailNews:Logging - this should give us more information as to what is going on.

Are you connecting via SSL? It may be worth retrying on today's nightly which is out in the next couple of hours, as there was one configuration issue fixed, although I do doubt it will fix your problem.
Component: General → Networking: News
Keywords: regression
Product: Thunderbird → Core
QA Contact: general → networking.news
Version: unspecified → Trunk
I can confirm this bug with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081223 Shredder/3.0b2pre

NNTP port at localhost:120
Attached file Logfile
Attachment #354301 - Attachment mime type: application/octet-stream → text/plain
That's an interesting log, and explains why I may not have seen the problem.

It looks like we initially get the port right, so that we're able to get information about the messages etc, but then when you select a message, we're reverting to the old port.

Does anyone have any idea when this started to be a problem (just pre or post beta 1 initially would be useful)?

Confirming based on comment 2.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I wonder if the reworking of the nntp connection cache might be involved? That was post b1.
Product: Core → MailNews Core
I can confirm this problem with:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2
confirming on windows port 1198
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090312 Shredder/3.0b3pre
Unable to log results.
Based on the comments, this is a problem that people will hit and an obvious regression. I think we need to fix this so setting blocking TB3.
Assignee: nobody → bugzilla
Flags: blocking-thunderbird3+
Target Milestone: --- → Thunderbird 3.0b3
Either the code or the comment from bug 213729 in nsNntpService::DisplayMessage certainly seems wrong, since the comment says "We need to set the port on the url, just like nsNNTPProtocol::Initialize does" and then proceeds to set it to the default port, unlike nsNNTPProtocol::Initialize which sets it to the port in the URI it was handed.
Attached patch The fix (obsolete) — Splinter Review
Fix with testcase. As Phil said in comment 9, we're currently always assuming the default port.

Note, I've also included a fix in nsNNTPNewsgroupList::CleanUp to prevent/fix a debug assertion occurring. The assertion was:

###!!! ASSERTION: invalid min or max param: 'min <= max && min > 0', file /Users/moztest/comm/main/src/mailnews/base/util/nsMsgKeySet.cpp, line 1075

I think this is occurring because with the testcase when we get to nsNNTPNewsgroupList::CleanUp both m_knownArts.set and m_set are empty. A few lines down in CleanUp, firstKnown and lastKnown (obtained from m_knownArts.set) are both 0, when the loop starts processing, firstKnown gets incremented (because its zero) but lastKnown doesn't. Hence the assertion.

As m_set->FirstMissingRange will just return if we're not in debug mode, and as a result nothing would end up happening, I think its reasonable to do the same if both m_knownArts.set and m_set are empty.

I couldn't reproduce the problem on my debug build when subscribing to a new newsgroup so it could just be the way the testcase is written (i.e. not doing a proper display of the message or something), but I'm still not sure we should assert in this case.
Attachment #367982 - Flags: superreview?(bienvenu)
Attachment #367982 - Flags: review?(bienvenu)
Whiteboard: [has patch][needs review bienvenu]
I got a test failure when running on windows with this patch:

*** exiting
*** TEST-UNEXPECTED-FAIL | ../../../mozilla/_tests/xpcshell/test_news/unit/test_
getNewsMessage.js | From: John Doe <john.doe@example.com>
Date: Sat, 24 Mar 1990 10:59:24 -0500
Newsgroups: test.subscribe.simple
Subject: H2G2 -- What does it mean?
Message-ID: <TSS1@nntp.test>

What does the acronym H2G2 stand for? I've seen it before...
 == From: John Doe <john.doe@example.com>
Date: Sat, 24 Mar 1990 10:59:24 -0500
Newsgroups: test.subscribe.simple
Subject: H2G2 -- What does it mean?
Message-ID: <TSS1@nntp.test>

What does the acronym H2G2 stand for? I've seen it before...

JS frame :: C:/mozilla-build/msys/tbirdcheck/mozilla/testing/xpcshell/head.js ::
 do_throw :: line 101
JS frame :: C:/mozilla-build/msys/tbirdcheck/mozilla/testing/xpcshell/head.js ::
 do_check_eq :: line 120
JS frame :: ../../../mozilla/_tests/xpcshell/test_news/unit/test_getNewsMessage.
js :: anonymous :: line 41
native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0
JS frame :: ../../../mozilla/_tests/xpcshell/test_news/unit/test_getNewsMessage.
js :: anonymous :: line 32
*** exiting
*** TEST-UNEXPECTED-FAIL | ../../../mozilla/_tests/xpcshell/test_news/unit/test_
getNewsMessage.js | From: John Doe <john.doe@example.com>
Date: Sat, 24 Mar 1990 10:59:24 -0500
Newsgroups: test.subscribe.simple
Subject: H2G2 -- What does it mean?
Message-ID: <TSS1@nntp.test>

What does the acronym H2G2 stand for? I've seen it before...
 == From: John Doe <john.doe@example.com>
Date: Sat, 24 Mar 1990 10:59:24 -0500
Newsgroups: test.subscribe.simple
Subject: H2G2 -- What does it mean?
Message-ID: <TSS1@nntp.test>

What does the acronym H2G2 stand for? I've seen it before...

JS frame :: C:/mozilla-build/msys/tbirdcheck/mozilla/testing/xpcshell/head.js ::
 do_throw :: line 101
JS frame :: C:/mozilla-build/msys/tbirdcheck/mozilla/testing/xpcshell/head.js ::
 do_check_eq :: line 120
JS frame :: ../../../mozilla/_tests/xpcshell/test_news/unit/test_getNewsMessage.
js :: anonymous :: line 41
*** FAIL ***
WARNING: nsExceptionService ignoring thread destruction after shutdown: file C:/
mozilla-build/msys/tbirdcheck/mozilla/xpcom/base/nsExceptionService.cpp, line 19
4
recorder: started(36), aborted(31), completed(5), different header(0), trees tra
shed(0), slot promoted(0), unstable loop variable(1), breaks(2), returns(0), uns
tableInnerCalls(0)
Attached patch The fix v2 (obsolete) — Splinter Review
We seem to be sending everything across the interface right (i.e. using crlf), its just the storage at the mailnews side varies crlf according to platform. Therefore I've just added a crlf -> lf replacement before the comparison function.
Attachment #367982 - Attachment is obsolete: true
Attachment #368220 - Flags: superreview?(bienvenu)
Attachment #368220 - Flags: review?(bienvenu)
Attachment #367982 - Flags: superreview?(bienvenu)
Attachment #367982 - Flags: review?(bienvenu)
Comment on attachment 368220 [details] [diff] [review]
The fix v2

sadly, this is still failing for me on windows. The code looks right, though. I'm sure I've got the right patch and I have rebuilt...I'll try it in an other tree just to be sure.
Comment on attachment 368220 [details] [diff] [review]
The fix v2

test fails on an other machine as well
Attached patch The fix v3Splinter Review
Ok, this should use the form of the replace function that works...
Attachment #368220 - Attachment is obsolete: true
Attachment #368274 - Flags: superreview?(bienvenu)
Attachment #368274 - Flags: review?(bienvenu)
Attachment #368220 - Flags: superreview?(bienvenu)
Attachment #368220 - Flags: review?(bienvenu)
Comment on attachment 368274 [details] [diff] [review]
The fix v3

great, that worked.

one nit - can use existing declared rv here instead of declaring a new one.

+        nsresult rv = server->GetSocketType(&socketType);
Attachment #368274 - Flags: superreview?(bienvenu)
Attachment #368274 - Flags: superreview+
Attachment #368274 - Flags: review?(bienvenu)
Attachment #368274 - Flags: review+
Checked in: http://hg.mozilla.org/comm-central/rev/1d0fcdefa375
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: in-testsuite+
OS: Windows XP → All
Hardware: x86 → All
Resolution: --- → FIXED
Whiteboard: [has patch][needs review bienvenu] → [has patch]
Duplicate of this bug: 500809
You need to log in before you can comment on or make changes to this bug.