Changi: Problems retrieving group list
Christian Hennecke
I'm experiencing problems with some news readers and Changi, e.g., Pan for
Linux. Retrieving the list of news groups does not work for
news.ecomstation.nl and a private news server I frequently use. The client
just sits there forever. The clients are said to comply with the GNKSA.
Any ideas?
Frank Beythien
No problems with ProNews/2 and changi. Below is an iptrace with the
LIST command:
-------------------------- #:13 -------------------------- from
changi
Delta Time: 0.000sec Packet Length: 96 bytes (60 hex)
IP: Dest: 127.000.000.001 Source: 127.000.000.001
----------------------- IP HEADER -----------------------
IP: Version: 4 Correct Header Length: 20 bytes
IP: Type Of Service: 00
IP: 000. .... Routine
IP: ...0 .... Normal Delay
IP: .... 0... Normal Throughput
IP: .... .0.. Normal Reliability
IP: Total Len: 96 (x60) bytes Id: 9A80
IP: Flags: 0
IP: .0.. May Fragment
IP: ..0. Last Fragment
IP: Fragment Offset: 000
IP: Time To Live: 64 sec Protocol: 6 TCP
IP: Header Checksum: E215 (Correct)
IP: No Options
---------------------- TCP HEADER ----------------------
TCP: Source Port: 119 (Unassigned port) Dest Port: 50770
(Unassigned port)
TCP: Sequence #: 3190082043
TCP: Ack #: 3189988036
TCP: Offset: 32 bytes
TCP: Flags: 18
TCP: ..0. .... Urgent bit Off
TCP: ...1 .... <ACK> Ack bit On
TCP: .... 1... <PUSH>Push bit On
TCP: .... .0.. Reset bit Off
TCP: .... ..0. Synchronize bit Off
TCP: .... ...0 Finish bit Off
TCP: Window: 17066 Checksum: 382C (Correct)
TCP: Option Code: 01 Length: 1 bytes [NOP]
TCP: No Operation
TCP: Option Code: 01 Length: 1 bytes [NOP]
TCP: No Operation
TCP: Option Code: 08 Length: 10 bytes [TIMESTAMP]
TCP: TimeStamp Value 56408 (xDC58)
TCP: TimeStamp Echo Reply 56408 (xDC58)
--------------------------------- DATA
-----------------------------------
0000 32 30 30 20 43 68 61 6E 67 69 20 4E 4E 54 50 20 200 Changi
NNTP
0010 73 65 72 76 65 72 20 72 65 61 64 79 20 28 70 6F server ready
(po
0020 73 74 69 6E 67 20 6F 6B 29 2E 0D 0A sting ok)...
-------------------------- #:14 -------------------------- to changi
--------------------------------- DATA
-----------------------------------
0000 4C 49 53 54 0D 0A LIST..
-------------------------- #:15 -------------------------- from
changi
--------------------------------- DATA
-----------------------------------
0000 32 31 35 20 4E 65 77 73 67 72 6F 75 70 73 20 69 215
Newsgroups i
0010 6E 20 66 6F 72 6D 20 22 67 72 6F 75 70 20 68 69 n form
"group hi
0020 67 68 20 6C 6F 77 20 79 2F 6E 2F 6D 22 2E 0D 0A gh low
y/n/m"...
-------------------------- #:16 -------------------------- from
changi
--------------------------------- DATA
-----------------------------------
0000 62 75 68 6C 2E 73 6F 66 74 77 61 72 65 2E 64 2D
buhl.software.d-
0010 69 6E 66 6F 20 35 30 31 20 35 30 30 20 79 0D 0A info 501 500
y..
0020 62 75 68 6C 2E 73 6F 66 74 77 61 72 65 2E 64 2D
buhl.software.d-
0030 74 6F 6F 6C 73 20 32 31 20 32 31 20 79 0D 0A 62 tools 21 21
y..b
0040 75 68 6C 2E 73 6F 66 74 77 61 72 65 2E 77 69 73
uhl.software.wis
0050 6F 2D 61 6C 6C 67 65 6D 65 69 6E 20 33 31 34 39 o-allgemein
3149
0060 20 33 31 35 30 20 79 0D 0A 62 75 68 6C 2E 73 6F 3150
y..buhl.so
0070 66 74 77 61 72 65 2E 77 69 73 6F 2D 62 6F 65 72
ftware.wiso-boer
0080 73 65 20 31 31 39 37 39 20 31 31 39 38 30 20 79 se 11979
11980 y
0090 0D 0A 62 75 68 6C 2E 73 6F 66 74 77 61 72 65 2E
.buhl.software.
00A0 77 69 73 6F 2D 6D 65 69 6E 67 65 6C 64 20 36 32
wiso-meingeld 62
00B0 30 35 33 20 36 32 30 35 34 20 79 0D 0A 62 75 68 053 62054
y..buh
... and more data
CU/2
--
Frank Beythien fBeythien AT gmx.de
Paul Ratcliffe
As far as I'm aware, Changi has no problems with the newsgroup list.
You need a packet trace to see what you're getting back from the server
and see if the last line with a single dot character is somehow corrupted
or missing.
Christian Hennecke
>> I'm experiencing problems with some news readers and Changi, e.g., Pan
>> for Linux. Retrieving the list of news groups does not work for
>> news.ecomstation.nl and a private news server I frequently use. The
>> client just sits there forever. The clients are said to comply with the
>> GNKSA.
>>
>> Any ideas?
>
> No problems with ProNews/2 and changi. Below is an iptrace with the
> LIST command:
ProNews is working fine here, too. It's other clients that exhibit the
problem.
Christian Hennecke
>> I'm experiencing problems with some news readers and Changi, e.g., Pan
>> for Linux. Retrieving the list of news groups does not work for
>> news.ecomstation.nl and a private news server I frequently use. The
>> client just sits there forever. The clients are said to comply with the
>> GNKSA.
>
> As far as I'm aware, Changi has no problems with the newsgroup list. You
> need a packet trace to see what you're getting back from the server and
> see if the last line with a single dot character is somehow corrupted or
> missing.
I can see that the reader issues a "LIST NEWSGROUPS" command. Changi
answers with "No list of newsgroup descriptions available." So it probably
might work if the reader only issued a "LIST" command?
Paul Ratcliffe
Yes, sounds to me like the client is issuing the wrong command, but even if
it is, it should return no groups rather than "sitting there forever".
The definitive list of groups is retrieved using "LIST" or "LIST ACTIVE"
which both do the same thing. "LIST NEWSGROUPS" retrieves an optional list
of newsgroups and a brief description of each group. It does not have to
contain all the entries returned by "LIST ACTIVE" and in some cases may
return more (for whatever reason).
On Changi the "newsgroups" file contains the newsgroup descriptions and
is not updated when you add or remove groups from the server. Usually
it doesn't exist at all IME as nobody seems to be bothered about the
descriptions.
Jonathan de Boyne Pollard
>>>>
>>>> I'm experiencing problems with some news readers and Changi, e.g.,
>>>> Pan for Linux. Retrieving the list of news groups does not work for
>>>> news.ecomstation.nl and a private news server I frequently use. The
>>>> client just sits there forever. The clients are said to comply with
>>>> the GNKSA.
>>>>
>>> As far as I'm aware, Changi has no problems with the newsgroup list.
>>> You need a packet trace to see what you're getting back from the
>>> server and see if the last line with a single dot character is
>>> somehow corrupted or missing.
>>>
>> I can see that the reader issues a "LIST NEWSGROUPS" command. Changi
>> answers with "No list of newsgroup descriptions available." So it
>> probably might work if the reader only issued a "LIST" command?
>>
> Yes, sounds to me like the client is issuing the wrong command, but
> even if it is, it should return no groups rather than "sitting there
> forever".
>
checking the server capabilities for the LIST capability beforehand, and
is expecting LIST NEWSGROUPS to never result in anything other than a
2xx status code. It wouldn't be the first reader to deviate from the
protocol by not checking status codes with optional commands. And this
is one of the common results of getting the protocol wrong: the client
waiting for a multi-line response that the server has stated it isn't
sending.
It's worth noting that Changi doesn't implement CAPABILITIES, so Pan
really has no business thinking that Changi supports anything more than
the RFC977 protocol, which only includes plain unadorned LIST. As
RFC2980 §2.1.6 makes clear, 503 is most definitely a status that NNTP
clients should expect to see from LIST NEWSGROUPS.
> On Changi the "newsgroups" file contains the newsgroup descriptions
> and is not updated when you add or remove groups from the server.
> Usually it doesn't exist at all IME as nobody seems to be bothered
> about the descriptions.
>
The reported response indicates to me that Changi at least knows how to
respond to the command. (I'd expect a "command not implemented"
response to say something more along those lines.) So one question is
why it's not finding and using the contents of that file.
Jonathan de Boyne Pollard
It sounds as if Pan is badly written, is issuing LIST NEWSGROUPS without checking the server capabilities for the LIST capability beforehand, and is expecting LIST NEWSGROUPS to never result in anything other than a 2xx status code. It wouldn't be the first reader to deviate from the protocol by not checking status codes with optional commands. And this is one of the common results of getting the protocol wrong: the client waiting for a multi-line response that the server has stated it isn't sending.
Hah! A little bit of research shows this indeed to be the case.
Pan is broken. There was a thread about this very bug on the Pan-users
mailing list in July 2008, where Per Hedeland came up with a patch to
Pan's broken response code parser. It became Pan bug #545220.
Christian Hennecke
[snip]
Thanks, guys. Unfortunately, it looks like Pan development has stopped. I
was using it because it's rather light-weight compared to Thunderbird. Oh
well, there really should be ProNews for Linux...
John F. Morse
microsoft.public.internet.news.reader.software were removed -- but then
reentered since I don't know where you lurk.]
[Followups set to news.software.nntp, news.software.readers.]
You trimmed off the attributes, so I have no idea to whom the following
is directed. With that in mind, "To whom it may concern" and "caveat
emptor":
Pan is an old newsreader. It is still a good one, but you need to
realize there are new RFCs, and protocols (status codes, etc.) have
changed since Pan was written.
Furthermore, the "good" Pan is version 0.14.2.91 (August 31, 2003) and
not the more current beta version 0.133 (Aug 1, 2008). There was no
mention above of the version used.
The GNKSA is also very old ("Last modification: Jul 27 2002").
--
John
When a person has -- whether they knew it or not -- already rejected the Truth, by what means do they discern a lie?
Jonathan de Boyne Pollard
>>
>> It's worth noting that Changi doesn't implement CAPABILITIES, so Pan
>> really has no business thinking that Changi supports anything more
>> than the RFC977 protocol, which only includes plain unadorned LIST.
>> As RFC2980 §2.1.6 makes clear, 503 is most definitely a status that
>> NNTP clients should expect to see from LIST NEWSGROUPS.
>>
>>
> Pan is an old newsreader. It is still a good one, but you need to
> realize there are new RFCs, and protocols (status codes, etc.) have
> changed since Pan was written.
>
and not the "new" ones, it would not be using LIST NEWSGROUPS, an
extension to NNTP described in a "new RFC", instead of the "old" RFC977
plain unadorned LIST. Pan's using an NNTP extension that isn't in
RFC977. But it isn't doing what RFC3977 says to do, which is check the
availability of the extension with the CAPABILITIES command first.
Neither is it doing what RFC2980 implies should be done, which is use
the verb but correctly handle the case where the server doesn't actually
implement it, by correctly handling the server replying negatively to
the command (in this particular case with a 503 result code).
> Furthermore, the "good" Pan is version 0.14.2.91 (August 31, 2003) and
> not the more current beta version 0.133 (Aug 1, 2008). There was no
> mention above of the version used.
>
The "good" Pan in this case will be the one with Per Hedeland's
aforementioned July 2008 bugfix in it.
John F. Morse
>>> really has no business thinking that Changi supports anything more
>>> than the RFC977 protocol, which only includes plain unadorned LIST.
>>> As RFC2980 �2.1.6 makes clear, 503 is most definitely a status that
>>> NNTP clients should expect to see from LIST NEWSGROUPS.
>>>
>>> [...]
>>>
>> Pan is an old newsreader. It is still a good one, but you need to
>> realize there are new RFCs, and protocols (status codes, etc.) have
>> changed since Pan was written.
>>
> That doesn't work as an excuse.
I was not offering an "excuse."
> If Pan were adhering to the "old RFCs" and not the "new" ones, it
> would not be using LIST NEWSGROUPS, an extension to NNTP described in
> a "new RFC", instead of the "old" RFC977 plain unadorned LIST. Pan's
> using an NNTP extension that isn't in RFC977. But it isn't doing what
> RFC3977 says to do, which is check the availability of the extension
> with the CAPABILITIES command first. Neither is it doing what RFC2980
> implies should be done, which is use the verb but correctly handle the
> case where the server doesn't actually implement it, by correctly
> handling the server replying negatively to the command (in this
> particular case with a 503 result code).
When did I say Pan was written?
When was CAPABILITIES added to RFC 3977?
http://tools.ietf.org/html/rfc3977#section-5.2
Your cart appears to be in front of your horse.
>> Furthermore, the "good" Pan is version 0.14.2.91 (August 31, 2003)
>> and not the more current beta version 0.133 (Aug 1, 2008). There was
>> no mention above of the version used.
>>
> The "good" Pan in this case will be the one with Per Hedeland's
> aforementioned July 2008 bugfix in it.
That would depend on which Pan his patch is applied. ;-)
I don't have the message and don't know who Per Hedeland is. You must
have added the unneeded crossposting after his message.
Julien ÉLIE
> The reported response indicates to me that Changi at least knows how to respond to
> the command. (I'd expect a "command not implemented" response to say something
> more along those lines.) So one question is why it's not finding and using the
> contents of that file.
Probably because the file does not exist on the news server.
For instance, INN answers 503 when <pathetc>/newsgroups does not exist
or is not readable by the news user. It would be the same for
other files like active.times, distributions, distrib.pats, moderators,
motd.news (for LIST MOTD) or subscriptions.
When the file exists, but is empty, we have 215 followed by an empty
multi-line block (thus directly the final dot ".").
--
Julien ÉLIE
« La médecine est un métier dangereux. Ceux qui ne meurent pas
peuvent vous faire un procès. » (Coluche)
Jonathan de Boyne Pollard
That doesn't work as an excuse. If Pan were adhering to the "old RFCs" and not the "new" ones, it would not be using LIST NEWSGROUPS, an extension to NNTP described in a "new RFC", instead of the "old" RFC977 plain unadorned LIST. Pan's using an NNTP extension that isn't in RFC977. But it isn't doing what RFC3977 says to do, which is check the availability of the extension with the CAPABILITIES command first. Neither is it doing what RFC2980 implies should be done, which is use the verb but correctly handle the case where the server doesn't actually implement it, by correctly handling the server replying negatively to the command (in this particular case with a 503 result code).
When did I say Pan was written? When was CAPABILITIES added to RFC 3977? Your cart appears to be in front of your horse.
No. The excuse that you gave doesn't work, as I said. Think! If
Pan really were written to pre-date all of these things, as
you claimed, then it wouldn't be using a later NNTP extension
instead of the original RFC977 command. And the simple fact
is that it didn't properly account for the fact that the extension
might yield a negative response — something that RFC2980 explicitly
lists as a possibility.
Furthermore, the "good" Pan is version 0.14.2.91 (August 31, 2003) and not the more current beta version 0.133 (Aug 1, 2008). There was no mention above of the version used.
The "good" Pan in this case will be the one with Per Hedeland's aforementioned July 2008 bugfix in it.
I don't have the message and don't know who Per Hedeland is. You must have added the unneeded crossposting after his message.
That's because you haven't read this thread properly. Read all of the messages.