On Sat, 27 May 2000, Nathan Kurz wrote:
|Clifford Kite writes:
|> You might try the pppd option "noccp" if you haven't already done so, since
|> that's one of the things you didn't address.
|
|I just tried that for the mostly working ISP. I was unable to
|connect, and got an error message regarding 'no response to PAP auth
|requests'. Is this worth pursuing further?
It's certainly peculiar. I'd have to see a debug log to really understand
what was happening. It's remotely possible that the ISP ACKed the LCP
request just to get to the open state, and then silently stole away,
leaving pppd to fail when trying to authenticate with PAP. That would
mean that it couldn't do without VJ compression though, which doesn't
seem likely.
|> Have you compared pppd options you use on the box with the problem with
|> those used on the laptop?
|
|I started out with them identical, and then have played with the
|settings on the new box. Both are essentially:
|
|lock
|defaultroute
|noipdefault
|modem
|/dev/ttyS2
|115200
|crtscts
|debug
|kdebug 7
|asyncmap 0
|name "nate"
|
|By essentially, I mean that I have been fiddling with the
|configuration extensively, but revolving around these base settings.
The LCP messages in the log suggest that you have "noaccomp" too. ?
Unless you know a good reason for that option, remove it, since the peer
wants it and it's always a good idea to accomodate and imitate the peer.
|> Do the files alway stick at the same place during an ftp download? Can you
|> look at a hexdump of one of the troublesome files that you got by download
|> with another box and see anything just before the sticking point that is
|> suggestive?
|
|Yes, it does always stick at the same point. I've looked at it, and
|it appears to be null separated plain text. Nothing fancy.
|
|> Have you tried the pppd option "asyncmap a0000," which sometimes works
|> when the modem is absorbing XON/XOFF characters sent in the data? It
|> doesn't seem right here, but I've seen it work in one instance where I
|> swore that it couldn't help. :/
|
|I just tried it specifically, and it did not seem to help. This would
|have been covered by 'asyncmap ffffffff', wouldn't it?
It should, but PPP implementation are often buggy in one respect
or another. As an example the "escape FF" should not break link
negotiations, yet it did for you, and has for others as well. (PPP
requires that you be prepared to accept any escaped (and escapable)
character at any time.)
|> If you have an IDE hard drive, have you tried hdparm with the -u1 flag?
|
|Problem still exists. And since the problem is reproducible and
|specific to certain files, I think it probably not an IRQ problem.
|
|> Given what you've already done, perhaps it's time to add the option
|> "kdebug 2", and look for a clue in the hex dump during the period
|> leading up to a hang while downloading one of the troublesome files.
|> Since this produces a lot of output you should, if possible, choose a
|> file that not only hangs but does it shortly after the download starts.
|
|I've started down that route. There appear to be a couple frames that
|are always broken. These frames begin normally, but then include a
|few junk characters right at the end. Retransmits of a given frame
|vary in length, and often appear truncated. Sometimes data is missing
|from the middle of the frame. Other frames are occasionally broken.
I can't help but remark that the link negotiation message formatting in
your log is terrific. :)
I'd suggest using the "nobsdcomp" option for two reasons. There are no
common algorithms between the peer and pppd, and the Configure-Reject for
the "empty" pppd CCP request is unusual. At that point in the negotiations
the usual thing is for the peer to ACK the empty CCP request to get CCP to
the open state, or to send a Protocol-Reject for CCP. I don't know what
the effect of a Configure-Reject would be for pppd, and my C skills are too
low for me to easily find out by reading the source.
Since things rarely reach the "kdebug 2" point, so I've little experience
reading hexdumps of IP/PPP packets. Even so there _seemed_ to be nothing
to suggest that highly compressed data is the problem, which is something
that sometimes does cause FCS errors (when the modem flow-control out
of it's FIFO buffer fails because of the flood of previously compressed
octets that decompression generates).
Your observations and comments in the logs were helpful, and the logs
a good compromise between too much and too little, but they are omitted
here since I've no specific comments to make about what they say.
|---------------------------------------------------------------------
[logs elided]
|Looking close at one of the broken frames, I found that data was also
|missing from the middle of one of the retransmits. In particular, the
|six characters 'play/p' where dropped once. But mostly the frames
Yep, I saw another dropout in the 18.43.33 time segment of the kdebug log.
|seem to be truncated, often at the same spot.
Does NT happen to have software drivers for the modem? Probably not,
just grasping at straws. (and I really don't know what a software
driver does for a modem anyway - well, except for Winmodems and friends,
clearly not the case here)
If you'll send the location for the realplayer file then I'll download
enough to see what happens here, and try to compare the relevant parts
of it to your kdebug log.
You were right. It _is_ an "interesting" problem. :)
---
Clifford Kite
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
