[Pan-users] Re: problem with multipart messages

[Duncan]

wim delvaux posted <address@hidden>,
excerpted below,  on Fri, 12 Dec 2003 03:08:54 +0100:

> Since a couple of months I have been experiencing problems with multipart 
> messages : ALL of them in ALL newsgroups are incomplete ?

> What I want to ask is what do you all think of this problem.  Could it
> be a PAN bug or an corrupt file of some sort ? Are there means to verify
> the correctness or incorrectness of the news server at my end ? Is there
> any tool or technique I could use that would help me to debug their
> problem (which would make things advance !)

There are a couple possible causes for SOME such incompletes, but ALL is
a pretty strong qualifier.  I know of no causes for ALL messages to be
incomplete.

Several reasons why SOME might be incomplete.   Is there any pattern to
the missing parts?

1) Rouge cancels, if your server accepts cancels, or isn't well connected
enough to avoid propagation errors with canceled parts not getting
through.  In particular, there's been apparent attempts many think are
RIAA connected to cancel a single part out of every MP3 multipart, for
instance.  In at least some reported cases of this, it's been the first
part that gets canceled.

2) You may have an anti-text filter/rule combo set up to avoid spam and
text posts in binary groups, that is going wild.  In this case, it would
likely be the LAST and normally SMALLEST part that disappears.  If you
have such a rule/filter, try adding a clause that causes it NOT to match
"incomplete attachments", or simply disable the rule altogether, for
testing.

3)  THIS one might cause ALL of them (of any significant size, anyway) to
be bad.  What's your cache size, and how are you using it?  Is it set big
enough for what you are trying to do?  I believe PAN's cache still
defaults to something ridiculously small for serious binary users, 10MB or
some such.  That's probably good for text only users, but doesn't work to
well if you are downloading 800 MB ISO images..  <g>  Of course, in this
case the overviews would display as complete, but you'd go to do something
with the message after d/ling and it'd be incomplete and need to go to the
server again.

4) Is your server (or it's main upline sources) possibly filtering on post
size, killing the big ones?  This has been reported to be standard
practice with at least one of the satellite feeds, as they simply don't
have the bandwidth to carry everything.  Only the small (<500 lines,
or 500kb, or some such) parts would get thru, with occasional large parts
getting through as they had extra bandwidth -- enough to frustrate
debugging the cause.

Debugging..

Some of the things I'd try..

1) Use Knode or some such that will post binaries, to post a test to your
own server's testing group.  Does that come thru OK?

2) Verify your pan cache size, and free space on that partition.

3) Add a new server to PAN, but point it at the same physical server you
use now.  Does it have the same problems?

4) Rename (or delete) the ~/.pan dir, and see if PAN with a fresh config
has the same issue.  (If not, it's something in the old one, maybe the
server config if the results of #2 are appropriate, maybe the cache..

5) pan has a number of debug switches you could look at, to see if any are
suitable for debugging this.  From a console, try pan --help, for a list. 
You can either run pan from the console and watch the output, or redirect
it to a log file of some sort.

6)  The classic manual debug method for news, mail, AND http/web, has
always been a telnet session to the appropriate port on the appropriate
server.  You will of of course need to know the appropriate commands to
type in manually, but those are of course covered in the RFCs for the
protocol in question.  If you are just checking connectivity &&/|| the
welcome banner returned by the server, knowing that QUIT or quit is the
normal command used to gracefully terminate a session is helpful.

7)  Try an alternative server, and of course try an alternative news
client.  Knode has already been mentioned as one possibility..

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin