On Wed, 2010-12-29 at 22:50 +0100, Marco d'Itri wrote:
> On Sep 30, Russell Stuart <russell-deb...@stuart.id.au> wrote:
> > I am using pppd to connect via a Nokia E70 phone. This has worked
> > well until recently, where "recently" means it didn't work yesterday,
>
> Any news? Do you mind trying with the new "generic" configuration?
> /usr/share/doc/ppp/examples/peers-gprs and /etc/chatscripts/gprs .
No change when using my configuration. Latest squeeze updates have been
installed:
Package: ppp
Priority: optional
Section: admin
Installed-Size: 1016
Maintainer: Marco d'Itri <m...@linux.it>
Architecture: amd64
Version: 2.4.5-4
The vanilla /usr/share/doc/ppp/examples/peers-gprs
and /etc/chatscripts/gprs don't work when you just insert the right
device and APN. The minimally
modified /usr/share/doc/ppp/examples/peers-gprs is:
# example configuration for a GPRS/UMTS/HDSPA connection
#
# See the manual page pppd(8) for information on all the options.
# If your carrier requires authentication, uncomment this directive
# and replace myusern...@realm with the login name provided by them.
# If authentication is used, there should be a matching entry with the
# password in /etc/ppp/pap-secrets and/or /etc/ppp/chap-secrets.
#user "myusern...@realm"
# MUST CHANGE: replace ******** with the APN name specific to your
# mobile carrier and data plan.
# The /etc/chatscripts/gprs chat script may be modified to change the
# modem initialization string.
connect "/usr/sbin/chat -v -f /etc/chatscripts/gprs -T internet"
# Serial device to which the modem is connected.
/dev/ttyACM0
# Assumes that your IP address is allocated dynamically by the ISP.
noipdefault
# Try to get the name server addresses from the ISP.
usepeerdns
# Use this connection as the default route.
defaultroute
# Makes pppd "dial again" when the connection is lost.
persist
# Do not ask the remote to authenticate.
noauth
# Disable some PPP protocol features which are usually not supported
# by mobile carriers.
novj
novjccomp
noccp
nomagic
Running "sudo pppd updetach call peers-gprs" produces this log:
Dec 30 10:09:23 russell-laptop pppd[22428]: pppd 2.4.5 started by rstuart,
uid 0
Dec 30 10:09:24 russell-laptop chat[22429]: abort on (BUSY)
Dec 30 10:09:24 russell-laptop chat[22429]: abort on (VOICE)
Dec 30 10:09:24 russell-laptop chat[22429]: abort on (NO CARRIER)
Dec 30 10:09:24 russell-laptop chat[22429]: abort on (NO DIALTONE)
Dec 30 10:09:24 russell-laptop chat[22429]: abort on (NO DIAL TONE)
Dec 30 10:09:24 russell-laptop chat[22429]: abort on (NO ANSWER)
Dec 30 10:09:24 russell-laptop chat[22429]: abort on (DELAYED)
Dec 30 10:09:24 russell-laptop chat[22429]: abort on (ERROR)
Dec 30 10:09:24 russell-laptop chat[22429]: abort on (+CGATT: 0)
Dec 30 10:09:24 russell-laptop chat[22429]: send (AT^M)
Dec 30 10:09:24 russell-laptop chat[22429]: timeout set to 12 seconds
Dec 30 10:09:24 russell-laptop chat[22429]: expect (OK)
Dec 30 10:09:24 russell-laptop chat[22429]: ^M
Dec 30 10:09:24 russell-laptop chat[22429]: NO CARRIER
Dec 30 10:09:24 russell-laptop chat[22429]: -- failed
Dec 30 10:09:24 russell-laptop chat[22429]: Failed (NO CARRIER)
Dec 30 10:09:32 russell-laptop pppd[22428]: Terminating on signal 2
Dec 30 10:09:32 russell-laptop pppd[22428]: Exit.
Adding crtscts fixed that problem. Running it in when "sudo pppd
updetach call peers-gprs" then failed in the same way my configuration
does:
Dec 30 10:25:14 russell-laptop pppd[23660]: pppd 2.4.5 started by rstuart,
uid 0
Dec 30 10:25:15 russell-laptop chat[23661]: abort on (BUSY)
Dec 30 10:25:15 russell-laptop chat[23661]: abort on (VOICE)
Dec 30 10:25:15 russell-laptop chat[23661]: abort on (NO CARRIER)
Dec 30 10:25:15 russell-laptop chat[23661]: abort on (NO DIALTONE)
Dec 30 10:25:15 russell-laptop chat[23661]: abort on (NO DIAL TONE)
Dec 30 10:25:15 russell-laptop chat[23661]: abort on (NO ANSWER)
Dec 30 10:25:15 russell-laptop chat[23661]: abort on (DELAYED)
Dec 30 10:25:15 russell-laptop chat[23661]: abort on (ERROR)
Dec 30 10:25:15 russell-laptop chat[23661]: abort on (+CGATT: 0)
Dec 30 10:25:15 russell-laptop chat[23661]: send (AT^M)
Dec 30 10:25:15 russell-laptop chat[23661]: timeout set to 12 seconds
Dec 30 10:25:15 russell-laptop chat[23661]: expect (OK)
Dec 30 10:25:15 russell-laptop chat[23661]: AT^M^M
Dec 30 10:25:15 russell-laptop chat[23661]: OK
Dec 30 10:25:15 russell-laptop chat[23661]: -- got it
Dec 30 10:25:15 russell-laptop chat[23661]: send (ATH^M)
Dec 30 10:25:15 russell-laptop chat[23661]: expect (OK)
Dec 30 10:25:15 russell-laptop chat[23661]: ^M
Dec 30 10:25:15 russell-laptop chat[23661]: ATH^M^M
Dec 30 10:25:15 russell-laptop chat[23661]: OK
Dec 30 10:25:15 russell-laptop chat[23661]: -- got it
Dec 30 10:25:15 russell-laptop chat[23661]: send (ATE1^M)
Dec 30 10:25:15 russell-laptop chat[23661]: expect (OK)
Dec 30 10:25:15 russell-laptop chat[23661]: ^M
Dec 30 10:25:15 russell-laptop chat[23661]: ATE1^M^M
Dec 30 10:25:15 russell-laptop chat[23661]: OK
Dec 30 10:25:15 russell-laptop chat[23661]: -- got it
Dec 30 10:25:15 russell-laptop chat[23661]: send
(AT+CGDCONT=1,"IP","internet","",0,0^M)
Dec 30 10:25:16 russell-laptop chat[23661]: expect (OK)
Dec 30 10:25:16 russell-laptop chat[23661]: ^M
Dec 30 10:25:16 russell-laptop chat[23661]:
AT+CGDCONT=1,"IP","internet","",0,0^M^M
Dec 30 10:25:16 russell-laptop chat[23661]: OK
Dec 30 10:25:16 russell-laptop chat[23661]: -- got it
Dec 30 10:25:16 russell-laptop chat[23661]: send (ATD*99#^M)
Dec 30 10:25:16 russell-laptop chat[23661]: timeout set to 22 seconds
Dec 30 10:25:16 russell-laptop chat[23661]: expect (CONNECT)
Dec 30 10:25:16 russell-laptop chat[23661]: ^M
Dec 30 10:25:18 russell-laptop chat[23661]: ATD*99#^M^M
Dec 30 10:25:18 russell-laptop chat[23661]: CONNECT
Dec 30 10:25:18 russell-laptop chat[23661]: -- got it
Dec 30 10:25:18 russell-laptop chat[23661]: send (^M)
Dec 30 10:25:18 russell-laptop pppd[23660]: Serial connection established.
Dec 30 10:25:18 russell-laptop pppd[23660]: Using interface ppp0
Dec 30 10:25:18 russell-laptop pppd[23660]: Connect: ppp0 <--> /dev/ttyACM0
Dec 30 10:25:19 russell-laptop pppd[23660]: PAP authentication succeeded
Dec 30 10:25:20 russell-laptop pppd[23660]: local IP address 122.110.243.136
Dec 30 10:25:20 russell-laptop pppd[23660]: remote IP address 10.6.6.6
Dec 30 10:25:20 russell-laptop pppd[23660]: primary DNS address
211.29.132.12
Dec 30 10:25:20 russell-laptop pppd[23660]: secondary DNS address 61.88.88.88
Dec 30 10:25:20 russell-laptop pppd[23673]: Modem hangup
Dec 30 10:25:20 russell-laptop pppd[23673]: Connect time 0.0 minutes.
Dec 30 10:25:20 russell-laptop pppd[23673]: Sent 0 bytes, received 0 bytes.
Dec 30 10:25:20 russell-laptop pppd[23673]: Connection terminated.
Dec 30 10:25:21 russell-laptop pppd[23673]: Hangup (SIGHUP)
Dec 30 10:25:21 russell-laptop pppd[23673]: Exit.
However, because it has the "persist" option it tries again after
detaching. It then works. This is what I would have predicted as it
has then become pretty much the same as the working case in the original
bug report. Ie, it is the process of detaching that causes things to go
wrong. Naturally it also works if you omit "updetach" from the command
line, just as my configuration does.
I did an strace on pppd with and without the updetach flag. The
essential is on the one with updetach I see this:
99999 select(11, [9 10], NULL, [9 10], {1, 596948}) = 2 (in [9 10], left {1,
596944})
99999 read(9, "", 1502) = 0
99999 sendto(3, "<149>Dec 30 10:99:99 pppd[24490]: Modem hangup", 46,
MSG_NOSIGNAL, NULL, 0) = 46
On the one without updetach I see this:
99999 select(11, [9 10], NULL, [9 10], {1, 687335} <unfinished ...>
File descriptor 9 was returned earlier by this call:
99999 open("/dev/ppp", O_RDWR) = 9
I have no idea what /dev/ppp does, and it doesn't have a man page.
However, the clone() (ie fork) call which implements the updetach
happens between the above open() and the above select(). My guess if
there has been some change in the kernel which is causing /dev/ppp to be
confused by the clone(). This is either a bug or the kernel has been
changed and a corresponding change needs to be made in pppd.
I don't have time right now to look into it further, but maybe the
kernel might remember something changing in the August/September
timeframe.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
