On Sun, 20 Feb 2005 17:10:18 -0500
"steyla" wrote:

> Well - it seems I have almost the same problem here.
> I can do what I want, send what I want, the remote side is simply ignoring
> everything and sends
>
> LCP ConfReq id=0x3
>
> even if I offer (and ACK) a pap auth. To make sure I am not sending any
> junk, I patched serial_core.c, uart_write() to dump everythink I am
> sending. No linefeeds or cr's in my data stream.



Well, my best suggestion is for you to try to find out what Windows
is doing differently. This includes any INIT strings that it is
sending to the modem.

You can use the trial version of the Advanced Serial Port monitor
to find out what Windows is doing:

http://www.aggsoft.com/serial-port-monitor.htm

Likewise you can use slsnif under Linux:

http://www.dakotacom.net/~ymg/software.html

Be warned that pppd changes the serial port from 7 bit mode
to 8 bit mode when the chat script ends. So, you must
use slsnif 0.4.4 or later and send it a SIGUSR1 signal
after the chat script ends so that slsnif will resync the
ports to 8 bit mode:

kill -SIGUSR1 slsnifPID

where slsnifPID is the process ID of slsnif.

If you don't do it, pppd will complain (correctly) that the
line is not 8 bit clean.

You can also try to use minicom to login manually - can
you do so with the text based login, or does the ISP go
straight to PPP mode (as most of them do now days)?


Please do show us the complete pppd log so that we can have
more information and do let us all know what the problem
turned out to be.


Cheers,

Mike