`Terminating on signal 2'

[Rodolfo Medina]

Hi all.

During ppp connection, very often it happens that it sticks, i.e. it's still
open but it's not possibile navigate, browser can't open pages. Then I do
`C-c' from command line and the connection stops showing the above message.
Please help, whoever can, about diagnostic and - possibily - solution of the
problem.

Thanks,

Rodolfo

$ pon motorola
abort on (BUSY)
abort on (NO CARRIER)
abort on (VOICE)
abort on (NO DIALTONE)
abort on (NO DIAL TONE)
abort on (NO ANSWER)
abort on (DELAYED)
send (ATZ^M)
expect (OK)
ATZ^M^M
OK
-- got it

send (AT+CGDCONT=1,"IP","internet.wind"^M)
expect (OK)
^M
AT+CGDCONT=1,"IP","internet.wind"^M^M
OK
-- got it

send (AT+CGQREQ=1,2,4,3,6,31^M)
expect (OK)
^M
AT+CGQREQ=1,2,4,3,6,31^M^M
OK
-- got it

send (AT+CGQMIN=1,2,4,3,6,31^M)
expect (OK)
^M
AT+CGQMIN=1,2,4,3,6,31^M^M
OK
-- got it

send (AT+CGATT=1^M)
expect (OK)
^M
AT+CGATT=1^M^M
OK
-- got it

send (ATD*99#^M)
expect (CONNECT)
^M
ATD*99#^M^M
CONNECT
-- got it

send (^M)
Script /usr/sbin/chat -v -s -f /etc/chatscripts/motorola finished (pid 2746), status = 0x0
Serial connection established.
using channel 4
Using interface ppp0
Connect: ppp0 <--> /dev/ttyUSB0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xd75c2a2d> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x8 <asyncmap 0x0> <auth chap MD5> <magic 0x1c08649> <pcomp> <accomp>]
No auth is possible
sent [LCP ConfRej id=0x8 <auth chap MD5>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xd75c2a2d> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x9 <asyncmap 0x0> <magic 0x1c08649> <pcomp> <accomp>]
sent [LCP ConfAck id=0x9 <asyncmap 0x0> <magic 0x1c08649> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0xd75c2a2d]
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
rcvd [LCP DiscReq id=0xa magic=0x1c08649]
rcvd [LCP ProtRej id=0xb 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
rcvd [IPCP ConfNak id=0x1 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
rcvd [IPCP ConfNak id=0x2 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x3 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
rcvd [IPCP ConfReq id=0x4]
sent [IPCP ConfNak id=0x4 <addr 0.0.0.0>]
rcvd [IPCP ConfRej id=0x3 <compress VJ 0f 01> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x4 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14>]
rcvd [IPCP ConfNak id=0x4 <addr 10.57.244.99> <ms-dns1 193.70.152.25> <ms-dns2 212.52.97.25>]
sent [IPCP ConfReq id=0x5 <addr 10.57.244.99> <ms-dns1 193.70.152.25> <ms-dns2 212.52.97.25>]
rcvd [IPCP ConfAck id=0x5 <addr 10.57.244.99> <ms-dns1 193.70.152.25> <ms-dns2 212.52.97.25>]
rcvd [IPCP ConfReq id=0x5]
sent [IPCP ConfAck id=0x5]
Could not determine remote IP address: defaulting to 10.64.64.64
local IP address 10.57.244.99
remote IP address 10.64.64.64
primary DNS address 193.70.152.25
secondary DNS address 212.52.97.25
Script /etc/ppp/ip-up started (pid 2790)
Script /etc/ppp/ip-up finished (pid 2790), status = 0x0
^CTerminating on signal 2
Connect time 13.4 minutes.
Sent 2563537 bytes, received 16419927 bytes.
Script /etc/ppp/ip-down started (pid 2972)
sent [LCP TermReq id=0x2 "User request"]
Script /etc/ppp/ip-down finished (pid 2972), status = 0x0
^CTerminating on signal 2
^CTerminating on signal 2
^CTerminating on signal 2
^CTerminating on signal 2
^CTerminating on signal 2
^CTerminating on signal 2
^CTerminating on signal 2
^CTerminating on signal 2
^CTerminating on signal 2
^CTerminating on signal 2
sent [LCP TermReq id=0x3 "User request"]
^CTerminating on signal 2
^CTerminating on signal 2
^CTerminating on signal 2
^CTerminating on signal 2
^CTerminating on signal 2
^CTerminating on signal 2
^CTerminating on signal 2
^CTerminating on signal 2
^CTerminating on signal 2
^CTerminating on signal 2
Connection terminated.
^Cioctl(TIOCSETD, N_TTY): Interrupted system call (line 576)
^C^Ctcsetattr: Interrupted system call (line 1054)
Terminating on signal 2
Modem hangup

[Anssi Saari]

Rodolfo Medina <rodolfo...@gmail.com> writes:

> Hi all.
>
> During ppp connection, very often it happens that it sticks, i.e. it's still
> open but it's not possibile navigate, browser can't open pages. Then I do
> `C-c' from command line and the connection stops showing the above message.

Well, that's what C-c does, it sends signal number 2 aka INT aka
interrupt to the pppd process which then dutifully quits. Exactly as
documented too.

If reconnecting helps then you could add the persist option for ppp and
send SIGHUP to it (guessing Linux, that'd be killall -HUP pppd) which
will cause pppd to restart the connection.

Your modem is presumably cellular so that sticking issue may be due to
the modem itself or the cellular network. For example, the network might
prioritize voice calls. Not much you can do from your end in other
words except reconnect.

[Rodolfo Medina]

Anssi Saari <a...@sci.fi> writes:

> Rodolfo Medina <rodolfo...@gmail.com> writes:
>
>> During ppp connection, very often it happens that it sticks, i.e. it's still
>> open but it's not possibile navigate, browser can't open pages. Then I do
>> `C-c' from command line and the connection stops showing the above message.
>
> Well, that's what C-c does, it sends signal number 2 aka INT aka
> interrupt to the pppd process which then dutifully quits. Exactly as
> documented too.
>
> If reconnecting helps then you could add the persist option for ppp and
> send SIGHUP to it (guessing Linux, that'd be killall -HUP pppd) which
> will cause pppd to restart the connection.

For ppp configuration, I have two files, that I called both `motorola': one in
/etc/ppp/peers:

hide-password
noauth
connect "/usr/sbin/chat -v -s -f /etc/chatscripts/motorola"
debug
-crtscts
/dev/ttyUSB0
460800
defaultroute
noipdefault
remotename motorola
ipparam motorola
nodetach

, and another in /etc/chatscripts:

ABORT BUSY
ABORT 'NO CARRIER'
ABORT VOICE
ABORT 'NO DIALTONE'
ABORT 'NO DIAL TONE'
ABORT 'NO ANSWER'
ABORT DELAYED
'' ATZ
OK-AT-OK AT+CGDCONT=1,"IP","internet.wind"
OK-AT-OK AT+CGQREQ=1,2,4,3,6,31
OK-AT-OK AT+CGQMIN=1,2,4,3,6,31
OK-AT-OK AT+CGATT=1 OK-AT-OK ATD*99#
CONNECT ''

. Moreover, in /etc, I have resolv.conf:

nameserver 193.70.152.25
nameserver 193.70.192.25

. According to what you suggest, how should I edit those files?

> Your modem is presumably cellular so that sticking issue may be due to
> the modem itself or the cellular network. For example, the network might
> prioritize voice calls. Not much you can do from your end in other
> words except reconnect.

. But I use the sim card that's inside the device only to naviate in internet,
not also for voice calls.

Thanks indeed,

Rodolfo

[Eric Pozharski]

with <87r3q79...@gmail.com> Rodolfo Medina wrote:
> Anssi Saari <a...@sci.fi> writes:
>> Rodolfo Medina <rodolfo...@gmail.com> writes:

*SKIP*

> . According to what you suggest, how should I edit those files?

Let me get it straight. You start connection with pon(1), but it
(pon(1)) never terminates because of 'nodetach' in peers. Then pppd(8)
and pon(1) together keep your spare terminal forever. If my
understanding is correct then you have two options:

AFAIR (I'm not doing pon(1) for years now) that's not the way to use
pon(1). Drop 'nodetach' from peers, start connection with pon(1), then
terminate it with poff(1). You can give it (poff(1)) a try right away
-- just do it from other spare terminal. Also, you most probably should
drop '-s' option of chat(8) from 'connect' line. syslog(7) is fine too.

Other way is to drop pon(1) and use pppd(8) directly. That's obvious,
you must do it as root then.

As a suboption of second option you can switch to ifup(8)/ifdown(8).
And, if you can afford it (I'm UMTS myself, I know what I'm talking
about) you can configure pppd(8) to be permanently ready however
disconnected from interwebs. Then whenever you need them you just
attempt to use them, then pppd(8) will obey (after some minimal time,
it's unavoidable) (sometimes that "minimal time" may take couple of
hours).

However, if I misinterpreted contents of your first message, then please
explain what you're doing.

*CUT*

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

[Rodolfo Medina]

Thanks. As you suggest, I dropped `nodetach' and `-s' option from peers, but
the problem persists: the internet browser sticks and can't open pages. Then I
have to `poff' and then `pon' again. This every five, ten minutes.

Cheers,

Rodolfo

[Anssi Saari]

Rodolfo Medina <rodolfo...@gmail.com> writes:

> Anssi Saari <a...@sci.fi> writes:
>
>> If reconnecting helps then you could add the persist option for ppp and
>> send SIGHUP to it (guessing Linux, that'd be killall -HUP pppd) which
>> will cause pppd to restart the connection.
>
> For ppp configuration, I have two files, that I called both `motorola': one in
> /etc/ppp/peers:

That would be it. But I guess it's no easier to run killall than poff
and pon.

>> Your modem is presumably cellular so that sticking issue may be due to
>> the modem itself or the cellular network. For example, the network might
>> prioritize voice calls. Not much you can do from your end in other
>> words except reconnect.
>
> . But I use the sim card that's inside the device only to naviate in internet,
> not also for voice calls.

Usually cellular networks have multiple users so it's the other people's
calls that trample your data.

[Eric Pozharski]

with <87iobe5...@gmail.com> Rodolfo Medina wrote:
> Eric Pozharski <why...@pozharski.name> writes:
>
>> with <87r3q79...@gmail.com> Rodolfo Medina wrote:
>>> Anssi Saari <a...@sci.fi> writes:
>>>> Rodolfo Medina <rodolfo...@gmail.com> writes:

>>> . According to what you suggest, how should I edit those files?
>> Let me get it straight.

*SKIP*

> Thanks. As you suggest, I dropped `nodetach' and `-s' option from
> peers, but the problem persists: the internet browser sticks and can't
> open pages. Then I have to `poff' and then `pon' again. This every
> five, ten minutes.

Well, if screw up isn't on your side there's no much you can do about
it. If there's (or are) alternative *and* such alternative is any
better then don't hesitate to switch.

(disclaimer: I'm just a curious user, I don't have any other
connection with cellular busyness) From what I've read that GSM stack
has been (intentionally?) designed this way. See, IP (and TCP, UDP, and
so on) lay on NCP (Network Control Protocol). What in turn lays on LCP
(Link Control Protocol). And GSM and compatible younger variations and
EVDO (what's incompatible) go even deeper. And, from what I've read,
it's explicitly specified that LCP must come up even before GSM is up.
Nobody, except designing committee, understands why it's done this way.
Now, if GSM goes down then LCP has no obligations to go down too. So
pppd can't possibly know that link is effectevely down.

However, the issue at hands might be different. For me, sometimes, it
looks like this: outgoing packets go out without acknowledgement; that
makes TCP/IP to stop sending and start timeouting; then TCP/IP
timeouts, reports it, and program re-opens, and everything is
more-or-less fine; then out of nothing comes shitload of packets from
already severed connections, and all of them are rejected on firewall
because they've came on already closed outgoing ports. Most interesting
is that couple of times I've seen that silence period isn't actually
silent -- there's a NETBIOS noise on operator's network (my operator does
ADSL too).

Just to add some optimism here. You can actually automate your
connection maintenance. Write a script (shell is just fine) that will
do pon, then go in endless loop with condition that connection is
functional. Than, when connection should be considered dead your script
should do poff, then pon again, then loop again. Catch would be how
long to wait before reconnecting. Most probably your operator uses
DHCP, and on re-connection you'll have different IP Address, and that
will fubar all your present connections. If timeout is too short then
you'd drop connection that could recover in a moment later. If timeout
is too long then you'd be better wasting time reconnecting instead of
timeouting.

Switch if you can, get used to it if you can't.