> |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.
I'll save that problem for later, and come back to it if we hit a
deadend for the main problem of why a certain file will not download.
> I can't help but remark that the link negotiation message formatting in
> your log is terrific. :)
Thanks. I was afraid people were going to make fun of me for it...
> 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 will try with 'nobsdcomp' and see if anything different happens. My
expectation is that the negotiation will be a little different, but
that the base problem of broken frames will be unchanged. We'll see.
> 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).
I tried deciphering them a little bit. I concluded that the IP packet
inside was intended (according to the length) to be a full 1500 bytes
long, but was truncated to some shorter number. How is the length of
a PPP frame conveyed? In the kernel when an sk_buff is being built?
How can I peek at that raw serial data? I'm trying to learn that now.
> 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)
There was a disk that came with it, but I'm pretty sure that the
driver is not relevant. The modem does work quite well for almost all
other files, including large binary downloads. But subtle flaws in
the modem are possible, so I'll look for another modem to test with.
> 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.
That's a little difficult, as the location changes day by day. The
easiest thing to do is to go to <http://www.real.com/player> and fill
out the form. If it concerns you, the data entered is not verified.
I tried something else that was very interesting, although confusing.
I downloaded the file onto a different net accessible computer, and
then tried downloading it from there. It failed to download, but got
hung up on a different frame! This confuses me.
My plan was to start chopping off pieces of the file until it worked,
and then put things back until it failed again. I haven't done this
yet, but should be able to later tonight. I'll post a URL for that
test case once I've managed to create it.
> You were right. It _is_ an "interesting" problem. :)
I think it is. It is possible that it is as simple as a Linux
incompatibility with the modem, but to me that does not explain the
data specific nature of the problem. And I'm encouraged that other
people have reported seeing identical symptoms with different systems.
But I'm going to go out into the daylight while there still is some.
I'll keep working on the problem later tonight. Thanks for your
continued support and thought. It helps to have someone to show the
confusing points of data to, even if only for moral support :).
--nate
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
