> Hi Bruce,
> does anyone who is experiencing these problems have the chance
> to run a pppd _on the other end of the connection_ with
> "kdebug 31"? The pppd(8) man page only mentions kdebug bits
> up to 7, but there are more options, see /usr/include/net/if_ppp.h.
> The most interesting is SC_LOG_RAWIN which logs all incoming
> bytes before the get assembled (and CRCed) into packets
> (you won't see discarded packets with SC_LOG_INPKT).
> However, there's no corresponding SC_LOG_RAWOUT so in order
> to see the raw bytes sent from your pppd you must log them
> on the other side.
Unfortunatly I don't have such access as I don't think my ISP would concider
it worth the trouble :)
> The reason one should look at the raw bytes
> is that from your LCP logs I suspect the other pppd doesn't see
> any valid packet at all (it never answers to our requests and
> retries the same ConfReq over and over, because it obviously
> never saw our ConfAck).
>
>
> The reasons for invalid packets could be manyfold, e.g.
> data corruption on the port, or not using escaping on control
> characters (despite the setting of the send asyncmap).
Well if this helps I can use minicom to dialup the ISP and use the shell
account with no problem. I was able do download about 300k of rpm and tgz
files with zmodem in one session with no apparent problems.
----------------------------------------------------------------------
Bruce A. Locke blocke@lizard.org
http://www.lizard.org/blocke/
http://www.lizard.org/dragonlinux
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html