Discussion:
cellphone modem troubles
(too old to reply)
mf+ (Matthias Ferdinand)
2006-12-26 02:53:05 UTC
Permalink
Hello,

I converted my Compaq Armada M700 notebook (P3) from SuSE Linux 9.1 to
NetBSD3.0. While most other things work ok, I seem to have trouble
accessing the data/fax capability of my cellphone (Siemens ME45 or Siemens
S35) from the notebook. Connected via data cable to serial port /dev/tty00.

Settings under /etc/ppp/... are the same as they were before under Linux.

NetBSD 3.0 GENERIC, pppd-2.4.3nb1

Combinations that work, dialing into a Lucent Portmaster digital modem:
a) pppd using a normal voice modem on /dev/tty00 (Creatix 28.800)
b) minicom using ME45 cellphone on /dev/tty00
(Hardware flow control, 19200 8N1)
c) pppd using ME45 cellphone on a Debian Linux host
From b) and c) I conclude that the phone and the cable are ok, from a) I
conclude that pppd and kernel ppp are basically working.

Now trying the ME45, /var/log/messages contains the following:

Dec 26 03:13:37 shlab pppd[173]: pppd 2.4.3 started by adminmf, uid 0
Dec 26 03:13:38 shlab chat[754]: abort on (BUSY)
Dec 26 03:13:38 shlab chat[754]: abort on (NO CARRIER)
Dec 26 03:13:38 shlab chat[754]: abort on (NO DIALTONE)
Dec 26 03:13:38 shlab chat[754]: abort on (NO ANSWER)
Dec 26 03:13:38 shlab chat[754]: abort on (ERROR)
Dec 26 03:13:38 shlab chat[754]: abort on (DELAYED)
Dec 26 03:13:38 shlab chat[754]: send (at S7=45 S0=0 M1 L3 V1 X4 &c1 E1
Q0^M)
Dec 26 03:13:38 shlab chat[754]: expect (OK)
Dec 26 03:13:38 shlab chat[754]: at S7=45 S0=0 M1 L3 V1 X4 &c1 E1 Q0^M^M
Dec 26 03:13:38 shlab chat[754]: OK
Dec 26 03:13:38 shlab chat[754]: -- got it
Dec 26 03:13:38 shlab chat[754]: send (atdt068166810^M)
Dec 26 03:13:39 shlab chat[754]: expect (CONNECT)
Dec 26 03:13:39 shlab chat[754]: ^M
Dec 26 03:14:00 shlab chat[754]: atdt068166810^M^M
Dec 26 03:14:00 shlab chat[754]: CONNECT
Dec 26 03:14:00 shlab chat[754]: -- got it
Dec 26 03:14:00 shlab pppd[173]: Serial connection established.
Dec 26 03:14:00 shlab pppd[173]: Using interface ppp0
Dec 26 03:14:00 shlab pppd[173]: Connect: ppp0 <--> /dev/tty00
Dec 26 03:14:00 shlab pppd[173]: Modem hangup
Dec 26 03:14:00 shlab pppd[173]: Connection terminated.
Dec 26 03:14:02 shlab pppd[173]: Exit.

Immediately after "Serial connection established", pppd says "Modem
hangup".

And sometimes (very rarely, indeed), it says "not 8-bit clean":
Dec 26 03:19:10 shlab pppd[234]: Serial connection established.
Dec 26 03:19:10 shlab pppd[234]: Using interface ppp0
Dec 26 03:19:10 shlab pppd[234]: Connect: ppp0 <--> /dev/tty00
Dec 26 03:19:10 shlab pppd[234]: Modem hangup
Dec 26 03:19:10 shlab pppd[234]: Connection terminated.
Dec 26 03:19:10 shlab pppd[234]: Serial link is not 8-bit clean:
Dec 26 03:19:10 shlab pppd[234]: All received characters had bit 7 set to 0
Dec 26 03:19:10 shlab pppd[234]: Last 2 characters were: \0\0
Dec 26 03:19:12 shlab pppd[234]: Exit.

pppd options I tried (without any difference)
- nocrtscts
- crtscts
- cdtrcts
- nocdtrcts
- crtscts nocdtrcts
- nocrtscts cdtrcts
- none of these settings
- passive

I am running out of things to try. Can somebody give me some more hints?
Perhaps I need to look into 8N1 (... not 8-bit clean ...), where is this
set in pppd (or outside of pppd?) ? Other differences in serial port
handling between NetBSD and Linux?

Thankful for any help.

Best regards
Matthias Ferdinand

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ignatios Souvatzis
2006-12-26 07:26:17 UTC
Permalink
Hi,
Post by mf+ (Matthias Ferdinand)
Hello,
I converted my Compaq Armada M700 notebook (P3) from SuSE Linux 9.1 to
NetBSD3.0. While most other things work ok, I seem to have trouble
accessing the data/fax capability of my cellphone (Siemens ME45 or Siemens
S35) from the notebook. Connected via data cable to serial port /dev/tty00.
This should just work - at least I had another two Siemens phones work
with some Notebooks and NetBSD until very recently.
Post by mf+ (Matthias Ferdinand)
Dec 26 03:14:00 shlab pppd[173]: Modem hangup
Dec 26 03:14:00 shlab pppd[173]: Connection terminated.
Hm. Try to use the non-DCD device, /dev/dty00, instead.
Post by mf+ (Matthias Ferdinand)
Dec 26 03:14:02 shlab pppd[173]: Exit.
Immediately after "Serial connection established", pppd says "Modem
hangup".
This happens when ppp connection is trying to start negotiation while
the modem is in command mode.

crtscts should be ok; combine with (no)modem and maybe (no)local.

And try /dev/dty00 as mentioned above.
Post by mf+ (Matthias Ferdinand)
I am running out of things to try. Can somebody give me some more hints?
Perhaps I need to look into 8N1 (... not 8-bit clean ...), where is this
set in pppd (or outside of pppd?) ?
Always.

If this doesn't help, we'd need a log of the PPP negotiations to find
out what happens - use kdebug 7 and log the kernel debug messages to
some file using appropriate syslog.conf settings.

Regards,

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Matthias Ferdinand
2006-12-26 17:26:35 UTC
Permalink
--On Dienstag, Dezember 26, 2006 08:26:17 +0100 Ignatios Souvatzis
Post by Ignatios Souvatzis
This happens when ppp connection is trying to start negotiation while
the modem is in command mode.
crtscts should be ok; combine with (no)modem and maybe (no)local.
And try /dev/dty00 as mentioned above.
Post by mf+ (Matthias Ferdinand)
I am running out of things to try. Can somebody give me some more hints?
Perhaps I need to look into 8N1 (... not 8-bit clean ...), where is this
set in pppd (or outside of pppd?) ?
Always.
If this doesn't help, we'd need a log of the PPP negotiations to find
out what happens - use kdebug 7 and log the kernel debug messages to
some file using appropriate syslog.conf settings.
Hello,

thanks for your answer. Tried /dev/dty00, modem, local, but none of this
makes any difference. kdebug 7 does not show any packets, the link is
terminated before ppp takes place, this could be confirmed on the dialin
server side.

As the login dialog worked using minicom, I tried to let chat do the login,
so the server side would definitively be in PPP mode. The link is still
terminated immediately, but now there is some kernel message in the log:

Dec 26 13:30:40 shlab chat[9634]: CONNECT
Dec 26 13:30:40 shlab chat[9634]: -- got it
Dec 26 13:30:40 shlab chat[9634]: send ()
Dec 26 13:30:40 shlab chat[9634]: expect (ogin:)
Dec 26 13:30:40 shlab chat[9634]: 9600/RLP^M
Dec 26 13:30:42 shlab chat[9634]: ^M
Dec 26 13:30:42 shlab chat[9634]: ^M
Dec 26 13:30:42 shlab chat[9634]: login:
Dec 26 13:30:42 shlab chat[9634]: -- got it
Dec 26 13:30:42 shlab chat[9634]: send (<user>^M)
Dec 26 13:30:42 shlab chat[9634]: expect (word:)
Dec 26 13:30:42 shlab chat[9634]: <user>^M
Dec 26 13:30:42 shlab chat[9634]: Password:
Dec 26 13:30:42 shlab chat[9634]: -- got it
Dec 26 13:30:42 shlab chat[9634]: send (<pwd>^M)
Dec 26 13:30:43 shlab chat[9634]: expect (~)
Dec 26 13:30:43 shlab chat[9634]: ^M
Dec 26 13:30:44 shlab chat[9634]: PPP session from (<ip1>) to <ip2>
beginning....~
Dec 26 13:30:44 shlab chat[9634]: -- got it
Dec 26 13:30:44 shlab pppd[11205]: Serial connection established.
Dec 26 13:30:44 shlab pppd[11205]: Using interface ppp0
Dec 26 13:30:44 shlab pppd[11205]: Connect: ppp0 <--> /dev/dty00
Dec 26 13:30:44 shlab pppd[11205]: Modem hangup
Dec 26 13:30:44 shlab pppd[11205]: Connection terminated.
Dec 26 13:30:44 shlab /netbsd: ppp0: bad protocol 3402
Dec 26 13:30:46 shlab pppd[11205]: Exit.

There is some variety to that kernel message:

Dec 26 13:05:49 shlab /netbsd: ppp0: bad protocol 206c
...
Dec 26 13:10:20 shlab /netbsd: ppp0: bad protocol 14
...
Dec 26 13:12:31 shlab /netbsd: ppp0: bad protocol 206
...
Dec 26 13:17:46 shlab /netbsd: ppp0: bad fcs 470a
...
Dec 26 13:23:45 shlab /netbsd: ppp0: bad protocol 3402
...
Dec 26 13:30:44 shlab /netbsd: ppp0: bad protocol 3402

Then I started hacking at pppd. In main.c, it decides "Modem hangup"
whenever the read from the ttyfd returns with zero length. I disabled
this code section, and here is the result:

- chat as before
- "bad protocol" kernel message
- receiving packets from the dialin server (!)
(confirmed with a ppp log from server side)
- sending/replying packets to dialin server
(but not received at server)
- lots of "received short packet"


Dec 26 17:55:41 shlab chat[3370]: PPP session from (<ip1>) to <ip2>
beginning....~
Dec 26 17:55:41 shlab chat[3370]: -- got it
Dec 26 17:55:41 shlab /netbsd: ppp0: bad protocol 14
Dec 26 17:55:41 shlab pppd[19684]: Serial connection established.
Dec 26 17:55:41 shlab pppd[19684]: Using interface ppp0
Dec 26 17:55:41 shlab pppd[19684]: Connect: ppp0 <--> /dev/dty00
Dec 26 17:55:41 shlab pppd[19684]: received short packet:
Dec 26 17:55:42 shlab last message repeated 7603 times
Dec 26 17:55:42 shlab pppd[19684]: sent [LCP ConfReq id=0x1 <mru 552>
<asyncmap 0x0> <magic 0x39b2d523> <pcomp> <accomp>]
Dec 26 17:55:42 shlab pppd[19684]: received short packet:
Dec 26 17:55:44 shlab last message repeated 15810 times
Dec 26 17:55:44 shlab /netbsd: ppp0: got 24 bytes
Dec 26 17:55:44 shlab /netbsd:
ff03c02101020014020600000000050633854f1707020802
Dec 26 17:55:44 shlab pppd[19684]: received short packet:
Dec 26 17:55:44 shlab pppd[19684]: rcvd [LCP ConfReq id=0x2 <asyncmap 0x0>
<magic 0x33854f17> <pcomp> <accomp>]
Dec 26 17:55:44 shlab pppd[19684]: lcp_reqci: returning CONFACK.
Dec 26 17:55:44 shlab pppd[19684]: sent [LCP ConfAck id=0x2 <asyncmap 0x0>
<magic 0x33854f17> <pcomp> <accomp>]
Dec 26 17:55:44 shlab pppd[19684]: received short packet:
Dec 26 17:55:45 shlab last message repeated 8592 times
Dec 26 17:55:45 shlab pppd[19684]: sent [LCP ConfReq id=0x1 <mru 552>
<asyncmap 0x0> <magic 0x39b2d523> <pcomp> <accomp>]
Dec 26 17:55:45 shlab pppd[19684]: received short packet:
Dec 26 17:55:47 shlab last message repeated 16211 times
Dec 26 17:55:47 shlab /netbsd: ppp0: got 24 bytes
Dec 26 17:55:47 shlab /netbsd:
ff03c02101030014020600000000050633854f1707020802
Dec 26 17:55:47 shlab pppd[19684]: received short packet:
Dec 26 17:55:47 shlab pppd[19684]: rcvd [LCP ConfReq id=0x3 <asyncmap 0x0>
<magic 0x33854f17> <pcomp> <accomp>]
Dec 26 17:55:47 shlab pppd[19684]: lcp_reqci: returning CONFACK.
Dec 26 17:55:47 shlab pppd[19684]: sent [LCP ConfAck id=0x3 <asyncmap 0x0>
<magic 0x33854f17> <pcomp> <accomp>]
Dec 26 17:55:47 shlab pppd[19684]: received short packet:

Since packets arrive, there actually was no modem hangup.
pppd tries to send packets, but as the kernel sees the line as being
disconnected, it probably just discards them.
The serial driver must be interpreting some signal from the cellphone
as a modem hangup, which apparently is not correct (either the phone
or the serial driver does it not correctly).
I can see this behaviour with a Siemens ME45, and two Siemens S35i. This
probably means that the behaviour of the cellphones is intended and not
because of a single broken unit.

Is there a way to get the kernel to log events on the serial line? Are there
sysctl knobs to tune serial behaviour?

Best regards
Matthias Ferdinand


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ignatios Souvatzis
2007-01-15 15:40:04 UTC
Permalink
Post by mf+ (Matthias Ferdinand)
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?

-is


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
mf+ (Matthias Ferdinand)
2007-01-15 23:12:57 UTC
Permalink
--On Montag, Januar 15, 2007 16:40:04 +0100 Ignatios Souvatzis
Post by Ignatios Souvatzis
Post by mf+ (Matthias Ferdinand)
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


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ignatios Souvatzis
2007-01-16 11:06:03 UTC
Permalink
Post by mf+ (Matthias Ferdinand)
--On Mittwoch, Dezember 27, 2006 21:36:46 +0100 Matthias Ferdinand
Post by mf+ (Matthias Ferdinand)
To be really sure I had not messed with config or compiler or such, I
downloaded the binary NetBSD 3.1 kernel (-GENERIC and -GENERIC_LAPTOP)
from ftp.netbsd.org and tried again with both, but the result is exactly
the same.
Instead of wiping my entire installation to try Linux, I did a cvs-upgrade
for
bash-3.1# uname -a
NetBSD shlab 4.0_BETA2 NetBSD 4.0_BETA2 (GENERIC) #0: Thu Jan 11 09:38:18
But I get the same result: pppd receives hangup immediately, no LCP packets
exchanged.
ff03c0210101001402060000000005064e3dfd3107020802
Try this one with "local" instead of "modem", please.

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ignatios Souvatzis
2006-12-26 21:24:37 UTC
Permalink
Post by Matthias Ferdinand
--On Dienstag, Dezember 26, 2006 08:26:17 +0100 Ignatios Souvatzis
Post by Ignatios Souvatzis
This happens when ppp connection is trying to start negotiation while
the modem is in command mode.
crtscts should be ok; combine with (no)modem and maybe (no)local.
And try /dev/dty00 as mentioned above.
Post by mf+ (Matthias Ferdinand)
I am running out of things to try. Can somebody give me some more hints?
Perhaps I need to look into 8N1 (... not 8-bit clean ...), where is this
set in pppd (or outside of pppd?) ?
Always.
If this doesn't help, we'd need a log of the PPP negotiations to find
out what happens - use kdebug 7 and log the kernel debug messages to
some file using appropriate syslog.conf settings.
Hello,
thanks for your answer. Tried /dev/dty00, modem, local, but none of this
makes any difference. kdebug 7 does not show any packets, the link is
terminated before ppp takes place, this could be confirmed on the dialin
server side.
Then I started hacking at pppd. In main.c, it decides "Modem hangup"
whenever the read from the ttyfd returns with zero length. I disabled
[Deleted by me]

None of this is relevant - if the kernel signals EOF to the userland pppd,
you can't help by ignoring it. Maybe the answer to the 3rd question below
will tell us why it thinks it should do that.

1st question: do you run pppd as root? If not, please do.

2nd question: is the Siemens phone connected by an USB cable or by an
RS232 cable? (Some USB-RS232 dongles have carrier detection
problems in NetBSD-3ish OS kernel versions, and the Siemens USB cables
are RS232 over USB in disguise. In this case, a netbsd-4 beta2 kernel
should help.)

3rd question: can yo please increase the "debug" count to pppd, and show
us pppd's debug output?

Regards,
-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
mf+ (Matthias Ferdinand)
2006-12-26 23:27:53 UTC
Permalink
--On Dienstag, Dezember 26, 2006 22:24:37 +0100 Ignatios Souvatzis
Post by Ignatios Souvatzis
None of this is relevant - if the kernel signals EOF to the userland pppd,
you can't help by ignoring it. Maybe the answer to the 3rd question below
will tell us why it thinks it should do that.
Hello,

no, I did not intend to use that hack for production :-) Just to prove that
the modem does not mean to hangup but actually is still delivering data.
Post by Ignatios Souvatzis
1st question: do you run pppd as root? If not, please do.
yes, I called it as root. Logged in as adminmf, then su, then pppd. Same
when logging in directly as root
Post by Ignatios Souvatzis
2nd question: is the Siemens phone connected by an USB cable or by an
RS232 cable? (Some USB-RS232 dongles have carrier detection
it's an RS232 cable. Sorry for not telling straight away. dmesg excercpt:
isa0 at pcib0
lpt0 at isa0 port 0x378-0x37b irq 7
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com2 at isa0 port 0x3e8-0x3ef irq 5: ns16550a, working fifo
Post by Ignatios Souvatzis
are RS232 over USB in disguise. In this case, a netbsd-4 beta2 kernel
should help.)
I tried with netbsd-3 (3.1) kernel, same result. I will try netbsd-4 next.

Although the issue is probably not the phones, there might still be some
hardware issue in the notebook itself, even though it works with the
standard voice modem. Last time I used that under Linux was about a year
ago, and at the moment I cannot afford to temporarily reinstall just for
checking. Although it lists com0 and com2, there is only one rs232
connector. The other one is presumably an ir adapter, but that does not
seem to connect to the phones ir.
Post by Ignatios Souvatzis
3rd question: can yo please increase the "debug" count to pppd, and show
us pppd's debug output?
It was already running with 4 "debug"s. As the hangup is signalled
immediately after "Serial connection established", pppd does not get a
chance to do any negotiations. Only my hacked pppd that ignored the hangup
could see some LCP packets from remote.

/etc/syslog.conf:
...
kern,daemon,local2.* /var/log/ppp-log


with kdebug 7, 4x debug:
Dec 27 00:05:36 shlab chat[565]: PPP session from (<ip1>) to <ip2>
beginning....~
Dec 27 00:05:36 shlab chat[565]: -- got it
Dec 27 00:05:36 shlab pppd[563]: Serial connection established.
Dec 27 00:05:36 shlab pppd[563]: Using interface ppp0
Dec 27 00:05:36 shlab pppd[563]: Connect: ppp0 <--> /dev/tty00
Dec 27 00:05:36 shlab pppd[563]: Modem hangup
Dec 27 00:05:36 shlab pppd[563]: Connection terminated.
Dec 27 00:05:36 shlab /netbsd: ppp0: bad protocol 206
Dec 27 00:05:38 shlab pppd[563]: Exit.


Thank you.

Best regards
Matthias


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
mf+ (Matthias Ferdinand)
2006-12-26 23:54:55 UTC
Permalink
--On Mittwoch, Dezember 27, 2006 00:27:53 +0100 Matthias Ferdinand
Post by mf+ (Matthias Ferdinand)
I tried with netbsd-3 (3.1) kernel, same result. I will try netbsd-4 next.
just noticed that "config" from NetBSD-3 does not work with kernel
netbsd-4.
I don't know how to convert the complete system to NetBSD-current, seems
possible only via source. I only have 1-2 hours tomorrow evening before I
leave for a short holiday. But I can try afterwards.

Thanks for helping out on a holiday!

Best regards
Matthias

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ignatios Souvatzis
2006-12-27 10:19:27 UTC
Permalink
Post by mf+ (Matthias Ferdinand)
--On Mittwoch, Dezember 27, 2006 00:27:53 +0100 Matthias Ferdinand
Post by mf+ (Matthias Ferdinand)
I tried with netbsd-3 (3.1) kernel, same result. I will try netbsd-4 next.
just noticed that "config" from NetBSD-3 does not work with kernel
netbsd-4.
Sorry - this is the first time I suspect you're using a wrong kernel.
(You mentioned GENERIC in your first message).

What's the difference between GENERIC and your GENERIC?

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
mf+ (Matthias Ferdinand)
2006-12-27 20:36:46 UTC
Permalink
--On Mittwoch, Dezember 27, 2006 11:19:27 +0100 Ignatios Souvatzis
Post by Ignatios Souvatzis
Sorry - this is the first time I suspect you're using a wrong kernel.
(You mentioned GENERIC in your first message).
What's the difference between GENERIC and your GENERIC?
Ah, I tried to save compilation time for netbsd-4 (for which I could not
find a binary version) by using a stripped down config I had been using
before with 3.0, and then config claimed syntax errors after updating the
/usr/src/sys tree to netbsd-4.
To be really sure I had not messed with config or compiler or such, I
downloaded the binary NetBSD 3.1 kernel (-GENERIC and -GENERIC_LAPTOP) from
ftp.netbsd.org and tried again with both, but the result is exactly the
same.

To make sure it is not caused by hardware alone, I will try again with
Linux after I return, in about 10 days. For now, I have a good excuse to
leave my notebook at home during the trip :-)

Best regards
Matthias

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Pavel Cahyna
2006-12-28 12:28:15 UTC
Permalink
Ah, I tried to save compilation time for netbsd-4 (for which I could not find a
binary version)
ftp://ftp.netbsd.org/pub/NetBSD-daily/netbsd-4/200612080000Z/i386/binary/kernel/

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Bill Studenmund
2007-01-03 01:56:38 UTC
Permalink
Post by mf+ (Matthias Ferdinand)
--On Mittwoch, Dezember 27, 2006 11:19:27 +0100 Ignatios Souvatzis
Post by Ignatios Souvatzis
Sorry - this is the first time I suspect you're using a wrong kernel.
(You mentioned GENERIC in your first message).
What's the difference between GENERIC and your GENERIC?
Ah, I tried to save compilation time for netbsd-4 (for which I could not
find a binary version) by using a stripped down config I had been using
before with 3.0, and then config claimed syntax errors after updating the
/usr/src/sys tree to netbsd-4.
Yes, config changes as the kernel source changes.

One solution would be go grab the current (or 4.0 as desired) tree, and
have build.sh build your kernel. See the kernel=FOO directive.

The advantage is that build.sh will also build up-to-date tools. Tools
configured to run on your running OS level.

Yes, it does mean a lot of source...

Take care,

Bill
mf+ (Matthias Ferdinand)
2007-01-15 01:40:45 UTC
Permalink
--On Mittwoch, Dezember 27, 2006 21:36:46 +0100 Matthias Ferdinand
Post by mf+ (Matthias Ferdinand)
To be really sure I had not messed with config or compiler or such, I
downloaded the binary NetBSD 3.1 kernel (-GENERIC and -GENERIC_LAPTOP)
from ftp.netbsd.org and tried again with both, but the result is exactly
the same.
Instead of wiping my entire installation to try Linux, I did a cvs-upgrade
for
/usr/src to "netbsd-4" and ran build.sh. Now with a 4.0 kernel:

bash-3.1# uname -a
NetBSD shlab 4.0_BETA2 NetBSD 4.0_BETA2 (GENERIC) #0: Thu Jan 11 09:38:18
CET 2007 ***@shlab:/usr/obj/sys/arch/i386/compile/GENERIC i386

But I get the same result: pppd receives hangup immediately, no LCP packets
exchanged.

Then I tried with an additional USB<->serial adapter in between:
PC->USB->serial_converter->RS232->mobile

this is an old USB 1.0 chipset:
uhci0 at pci0 dev 7 function 2: Intel 82371AB (PIIX4) USB Host
Controller (rev. 0x01)
uhci0: interrupting at irq 11
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered

and this is the dmesg entry for the converter:
uplcom0 at uhub0 port 1
uplcom0: Prolific Technology Inc. USB-Serial Controller, rev 1.10/3.00,
addr 2
ucom0 at uplcom0

With ttyU0/dtyU0 instead of tty00/dty00 I get nearly the same results.
What's different:
a) the phone does not hangup after pppd has exited,
only when the remote server closes the connection (about 1min later).
b) kernel says "ppp0: got 24 bytes" instead of "ppp0: bad protocol 2206"
Jan 15 01:20:38 shlab pppd[1049]: Serial connection established.
Jan 15 01:20:38 shlab pppd[1049]: Using interface ppp0
Jan 15 01:20:38 shlab pppd[1049]: Connect: ppp0 <--> /dev/dtyU0
Jan 15 01:20:38 shlab pppd[1049]: Modem hangup
Jan 15 01:20:38 shlab pppd[1049]: Connection terminated.
Jan 15 01:20:38 shlab /netbsd: ppp0: got 24 bytes
Jan 15 01:20:38 shlab /netbsd:
ff03c0210101001402060000000005064e3dfd3107020802
Jan 15 01:20:40 shlab pppd[1049]: Exit.
c) a later chat invocation sees lots of noise, probably buffered ppp
packets from previous connect:
Jan 15 01:59:11 shlab chat[1307]: expect (OK)
Jan 15 01:59:11 shlab chat[1307]:
g&^H^F&^F^F&&^F^F^F^F^F&C^N&&F&lwg&^H^F&^F^F&&^F^F^F^F^FveFDEEFEng&^H^F^F^F^F&&^F^F^F^F^F&C^N&&F&Dwg&^H^F^F^F^F&&^F^F
Jan 15 01:59:11 shlab chat[1307]:
^F^F^F&C^N&&F&fwg&^H^F&^F^F&&^F^F^F^F^F&C^N&&F&-wg&^H^F&^F^F&vEDDDDDuC^N&&F&^Owg&^H^FF^F^F&&^F^F^F^F^F&C^N&&F&
Jan 15 01:59:11 shlab chat[1307]:
gwg&^H^FF^F^F&&^F^F^F^F^F&C^N&&F&Ewg&^H^Ff^F^F&&^F^F^F^F^F&C^N&&F&^Nwg&^H^Ff^FvDEEDDDDDeFDEEF^E&wg&^H^FF^F^F&

b and c may result from buffering in the serial adapter or from USB
transferring blocks of data.


I think by now I have ruled out as source of the problem
- the notebook rs232 interface (tty00)
ttyU0 behaves almost the same
- the data cable
works reliably on a different PC
- the phone / phone model
works on a different PC (using Linux)
three phones (Siemens ME45, 2x Siemens S35) behave exactly the same

This would leave the following suspects
- kernel rs232/tty driver or settings
- pppd tty initialisation

Are there perhaps some stty tricks I could try, which would not be
overwritten by pppd? Other things I should look at?

Best regards
Matthias


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ignatios Souvatzis
2007-01-16 10:45:53 UTC
Permalink
On Tue, Dec 26, 2006 at 03:53:05AM +0100, Matthias Ferdinand wrote:

...
Post by mf+ (Matthias Ferdinand)
Dec 26 03:14:00 shlab pppd[173]: Modem hangup
Dec 26 03:14:00 shlab pppd[173]: Connection terminated.
Dec 26 03:14:02 shlab pppd[173]: Exit.
Immediately after "Serial connection established", pppd says "Modem
hangup".
[...]
Post by mf+ (Matthias Ferdinand)
pppd options I tried (without any difference)
- nocrtscts
- crtscts
- cdtrcts
- nocdtrcts
- crtscts nocdtrcts
- nocrtscts cdtrcts
- none of these settings
Those probably aren't relevant.
Post by mf+ (Matthias Ferdinand)
- passive
This would even be harmful, if the other side is "passive" too, as in
this case none of you would initiate negotiations, and one of you would
eventually time out and hang up.

What you did NOT try is:

not to use "modem", but to use

local

(which ignores the carrier detect line).

Please do.

Regards.
-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ignatios Souvatzis
2007-01-16 13:23:07 UTC
Permalink
Post by Ignatios Souvatzis
not to use "modem", but to use
local
Please ignore this - I missed your other message when re-checking today.
However, use local with your latest kernel and hardware, please.

oh - and I'd like to see your configuruation files verbatim.

Regards,
-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
mf+ (Matthias Ferdinand)
2007-01-16 14:03:19 UTC
Permalink
--On Dienstag, Januar 16, 2007 11:45:53 +0100 Ignatios Souvatzis
Post by Ignatios Souvatzis
not to use "modem", but to use
local
(which ignores the carrier detect line).
Please do.
Regards.
-is
Very good! "local" alone did not work (no comm with modem at all), but
"local" together with "crtscts" did. I thought I had tried "local" before,
but obviously not in exactly this combination.
It does not detect when the modem hangs up, but then an LCP timeout will
catch that a little later.
After a hangup, the next pppd call cannot communicate with the modem,
until I do a modem reset from minicom.

Some other oddity in pppd: no matter how many "debug" options I give it,
it does not show negotiations in the log, I only see kernel packet dumps
from "kdebug 7".

My config: (except for "remotename" and "user")
-------------------------------------------------------------------
#nocrtscts
kdebug 7
debug
debug
debug
debug
crtscts
#cdtrcts
#nocdtrcts
asyncmap 0
#auth
lock
hide-password
#passive
#modem
local
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4
#tty00 57600
tty00 19200
connect '/usr/sbin/chat -v \
ABORT BUSY ABORT "NO CARRIER" ABORT "NO DIALTONE" ABORT "NO ANSWER"
\
ABORT ERROR ABORT DELAYED "" \
"at S7=45 S0=0 M1 L3 V1 X4 &c1 E1 Q0" "OK" \
"atdt068166810" "CONNECT"'

#remotename <remote>
#name <user>
#user <user>
#disconnect '/usr/sbin/chat -v -- "" "\\d+++\\d\\c" "OK" "ath0" "OK"'
#noccp
#mtu 296
#mru 296
mtu 552
mru 552
noipdefault
defaultroute
noauth
-------------------------------------------------------------------


Thank you very much for your help!

Best regards
Matthias

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ignatios Souvatzis
2007-01-16 15:02:24 UTC
Permalink
Post by mf+ (Matthias Ferdinand)
Very good! "local" alone did not work (no comm with modem at all), but
"local" together with "crtscts" did. I thought I had tried "local" before,
but obviously not in exactly this combination.
Ah, ok.
Post by mf+ (Matthias Ferdinand)
It does not detect when the modem hangs up, but then an LCP timeout will
catch that a little later.
of course. make usre ot have the echo failures high enough to survive
delayed lcp echos due to intensive downloading.
Post by mf+ (Matthias Ferdinand)
After a hangup, the next pppd call cannot communicate with the modem,
until I do a modem reset from minicom.
My boss just presses the red phone button on the phone ;-) That is,
nowadays he uses GPRS and doesn't care very much (of at least shouldn't
need to...)
Post by mf+ (Matthias Ferdinand)
Some other oddity in pppd: no matter how many "debug" options I give it,
it does not show negotiations in the log, I only see kernel packet dumps
from "kdebug 7".
kdebug N messages come from the kernel and are logged with "kernel.debug".
High level debug messages about negoiation come from pppd and are logged
with daemon.debug; you have to edit /etc/syslog.conf to write those
messages somehwere, and then "/etc/rc.d/syslog restart" to see them.

Regards,
-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
mf+ (Matthias Ferdinand)
2007-01-17 01:29:27 UTC
Permalink
--On Dienstag, Januar 16, 2007 16:02:24 +0100 Ignatios Souvatzis
Post by Ignatios Souvatzis
Post by mf+ (Matthias Ferdinand)
Some other oddity in pppd: no matter how many "debug" options I give it,
it does not show negotiations in the log, I only see kernel packet dumps
from "kdebug 7".
kdebug N messages come from the kernel and are logged with "kernel.debug".
High level debug messages about negoiation come from pppd and are logged
with daemon.debug; you have to edit /etc/syslog.conf to write those
messages somehwere, and then "/etc/rc.d/syslog restart" to see them.
Does not seem to work:

bash-3.1# grep debug /etc/syslog.conf
kern.debug /var/log/messages
*.debug /var/log/debuglog

But no negotiations in /var/log/debuglog (4x "debug" in config):

...
Jan 17 00:35:57 shlab pppd[673]: Serial connection established.
Jan 17 00:35:57 shlab pppd[673]: Using interface ppp0
Jan 17 00:35:57 shlab pppd[673]: Connect: ppp0 <--> /dev/tty00
Jan 17 00:35:58 shlab /netbsd: ppp0 output:
ff03c021010100180104022802060000000005067eff8b1e07020802
Jan 17 00:36:00 shlab /netbsd: ppp0: bad protocol 206c
Jan 17 00:36:00 shlab /netbsd: ppp0: bad fcs 90f1
Jan 17 00:36:00 shlab /netbsd: ppp0: got 28 bytes
Jan 17 00:36:00 shlab /netbsd:
ff03c02101010018020600000000050653f1c2cf070208020304c023
Jan 17 00:36:00 shlab /netbsd: ppp0 output:
ff03c02102010018020600000000050653f1c2cf070208020304c023
Jan 17 00:36:01 shlab /netbsd: ppp0 output:
ff03c021010100180104022802060000000005067eff8b1e07020802
Jan 17 00:36:02 shlab /netbsd: ppp0: got 28 bytes
Jan 17 00:36:02 shlab /netbsd:
ff03c021020100180104022802060000000005067eff8b1e07020802
Jan 17 00:36:02 shlab /netbsd: nd6_setmtu0: new link MTU on ppp0 (552) is
too small for IPv6 which needs 1280
...

Best regards
Matthias


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...