Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.protocols.ppp > #105

Re: `Terminating on signal 2'

Show all headers | View raw

with <87iobe5m3m.fsf@gmail.com> Rodolfo Medina wrote:
> Eric Pozharski <whynot@pozharski.name> writes:
>
>> with <87r3q79r4m.fsf@gmail.com> Rodolfo Medina wrote:
>>> Anssi Saari <as@sci.fi> writes:
>>>> Rodolfo Medina <rodolfo.medina@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.

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

Back to comp.protocols.ppp | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

`Terminating on signal 2' Rodolfo Medina <rodolfo.medina@gmail.com> - 2015-05-04 11:35 +0000
  Re: `Terminating on signal 2' Anssi Saari <as@sci.fi> - 2015-05-19 17:54 +0300
    Re: `Terminating on signal 2' Rodolfo Medina <rodolfo.medina@gmail.com> - 2015-05-23 16:48 +0000
      Re: `Terminating on signal 2' Eric Pozharski <whynot@pozharski.name> - 2015-05-24 11:22 +0300
        Re: `Terminating on signal 2' Rodolfo Medina <rodolfo.medina@gmail.com> - 2015-05-27 10:52 +0000
          Re: `Terminating on signal 2' Eric Pozharski <whynot@pozharski.name> - 2015-05-29 12:02 +0300
      Re: `Terminating on signal 2' Anssi Saari <as@sci.fi> - 2015-05-28 17:07 +0300

csiph-web