--On Montag, Januar 15, 2007 16:40:04 +0100 Ignatios Souvatzis 
<is@netbsd.org> wrote:
> On Mon, Jan 15, 2007 at 02:40:45AM +0100, Matthias Ferdinand wrote:
>
>>    Jan 15 01:20:38 shlab /netbsd:
>> ff03c0210101001402060000000005064e3dfd3107020802
>
> LCP configuration request #1 length 20
> * length 6: asyncmap all 0
> * length 6: magic cookie 0x4e3dfd31
> * length 2: protocol field compression
> * length 2: address and control field compression
>
> + 4 bytes of the configuration-request header, thats 20, so
> that one packge got into your kernel ok.
>
> Hm, but why doesn't it answer?

Hi, I guess it does not answer because pppd has already exited and removed 
the ppp interface. I can't tell how reliable the syslog sequencing is, but 
in all cases the kernel message ("bad protocol" or "got 24 bytes") comes 
after "Connection terminated". And only with the USB device it receives 
enough data to form a complete packet (as it does not cause the modem to 
actually hangup, while on tty00 it does).

Well, using minicom, the phone modem actually connects, even to the same 
dialin server, so my guess is there is some problem with the tty settings 
that pppd makes.

I just found out that I can use minicom to setup the connection and call 
pppd from within minicom via a runscript(1) script. That way, the pppd 
connection finally succeeds and is usable! (pppd config with option 
"local", and none of "crtscts" and co., but setting "tty00")

Is it possible to log events on a serial interface? Things like changes in 
signalling lines, baud rate and data sent/received. That might give an idea 
as to what is wrongly interpreted as a hangup and then perhaps hint at how 
to set line discipline to correct that. Since I now have a way to use the 
standard serial port with that cellphone modem, the problem must be either 
in pppds modem hangling or in the chat program (while both run flawless 
using a standard modem).

Still very strange, but at least I found a hack to get online from abroad.

Best regards
Matthias Ferdinand