demand dialing

Hi, I have a variant of Debian installed. Is there a pointy-clicky way
of enabling dial on demand for a regular analog (not ADSL) modem?
(This computer's for a very computer-illiterate person. While I have no
problem editing text files and writing scripts, she feels differently.)
Actually, it only has to be usable (not necessarily configurable) by a
non-privileged user. I'm not using Gnome (computer's too RAM-deprived
and slow) but the infrastructure's installed, thanks to the distro.
Thanks.

--
-eben (E-Mail Removed)P http://royalty.mine.nu:81
AQUARIUS: There's travel in your future when your tongue freezes to the
back of a speeding bus. Fill the void in your pathetic life by playing
Whack-a-Mole 17 hours a day. -- Weird Al, _Your Horoscope for Today_

On Fri, 03 Aug 2007 20:07:47 GMT, (E-Mail Removed) (Hactar)
wrote:

>Hi, I have a variant of Debian installed. Is there a pointy-clicky way
>of enabling dial on demand for a regular analog (not ADSL) modem?
>(This computer's for a very computer-illiterate person. While I have no
>problem editing text files and writing scripts, she feels differently.)
>Actually, it only has to be usable (not necessarily configurable) by a
>non-privileged user. I'm not using Gnome (computer's too RAM-deprived
>and slow) but the infrastructure's installed, thanks to the distro.
>Thanks.

What's wrong with the demand option to pppd?
--
buck

In article <(E-Mail Removed)>,
buck <(E-Mail Removed)> wrote:
> On Fri, 03 Aug 2007 20:07:47 GMT, (E-Mail Removed) (Hactar)
> wrote:
>
> >Hi, I have a variant of Debian installed. Is there a pointy-clicky way
> >of enabling dial on demand for a regular analog (not ADSL) modem?
> >(This computer's for a very computer-illiterate person. While I have no
> >problem editing text files and writing scripts, she feels differently.)
> >Actually, it only has to be usable (not necessarily configurable) by a
> >non-privileged user. I'm not using Gnome (computer's too RAM-deprived
> >and slow) but the infrastructure's installed, thanks to the distro.
> >Thanks.
>
> What's wrong with the demand option to pppd?

It doesn't bring the link up when I ping an outside site. resolv.conf
has the name servers from the previous time it was up. Otherwise,
that's good.

--
"The Web brings people together because no matter what kind of a
twisted sexual mutant you happen to be, you've got millions of pals
out there. Type in 'Find people that have sex with goats that are on
fire' and the computer will say, 'Specify type of goat.'" -- Rich Jeni

Hactar <(E-Mail Removed)> wrote:
> In article <(E-Mail Removed)>,
> buck <(E-Mail Removed)> wrote:
>>
>> What's wrong with the demand option to pppd?

> It doesn't bring the link up when I ping an outside site. resolv.conf
> has the name servers from the previous time it was up. Otherwise,
> that's good.

I don't understand why nameservers from a previous link via the modem
should prevent a demand configuration from bringing up another such link.
The resolver simply trying to access a nameserver, old or new, should
bring it up.

In addition, ISP nameservers don't change that often. Even so, I'd
think a Debian-provided demand setup would have something rigged to
replace the previous nameservers with the new ones. It's easy enough
to do.

Regards-
--
Clifford Kite
/* Better is the enemy of good enough. */

On Sat, 04 Aug 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <fo8do4-(E-Mail Removed)>, Hactar wrote:

>buck <(E-Mail Removed)> wrote:

>> (E-Mail Removed) (Hactar) wrote:

>>> Hi, I have a variant of Debian installed. Is there a pointy-clicky
>>> way of enabling dial on demand for a regular analog (not ADSL) modem?
>>> (This computer's for a very computer-illiterate person. While I have
>>> no problem editing text files and writing scripts, she feels
>>> differently.)

Why does it have to be a pointy-clicky? This is a one-time shot, and
needs only to add a line to the boot scripts.

>> What's wrong with the demand option to pppd?

>It doesn't bring the link up when I ping an outside site.

How exactly are you trying to do this? All that is needed is a dumb
script that is runnable by root - something like

[compton ~]$ cat /usr/local/bin/dialin
#!/bin/bash
exec /usr/sbin/pppd connect "/usr/sbin/chat -f /etc/ppp/dialscript" lock \
defaultroute noipdefault /dev/modem 115200 crtscts user ibuprofin \
nodetach
[compton ~]$

There must not be anything after the \ in those two lines.

[compton ~]$ cat /etc/ppp/dialscript
ABORT BUSY ABORT 'NO CARRIER' "" AT&F1 OK ATDT2662902 CONNECT \d\c
[compton ~]$

There is also the file /etc/ppp/pap-secrets (or possibly chap-secrets)
that has the username/password in the form

ibuprofin * p42Sw0rD~

and the right nameserver data in /etc/resolv.conf, and that's basically
it. Get this running from the command line in a separate terminal. When
you have done so, change the last line of the /usr/local/bin/dialin
script so that it now reads:"

[compton ~]$ cat /usr/local/bin/dialin
#!/bin/bash
exec /usr/sbin/pppd connect "/usr/sbin/chat -f /etc/ppp/dialscript" lock \
defaultroute noipdefault /dev/modem 115200 crtscts user ibuprofin \
demand idle 300 holdoff 15
[compton ~]$

and then add two lines to the local boot script (usually rc.local) that
read

echo -n 1 > /proc/sys/net/ipv4/ip_dynaddr
/usr/local/bin/dialin

The first line is used to tell a 2.2.x or later kernel that the system will
have dynamic IP addresses, while the second line runs the dialin script. As
this file (rc.local) is run by root, the daemon will be running as root.
Now, pppd will start, but stay in the background and respond to requests for
IP services after that. The idle 300 will cause the system to disconnect
when the ppp link has been idle for 5 minutes (300 seconds). The holdoff 15
means the system will not try to redial for 15 seconds after an idle
timeout, to allow everything to recover.

Other things to consider: You may want to be running a firewall (hint -
hint) to protect you from the outside world. If masquerading for windoze
boxes, be sure to block ports 137, 138, and 139 with a firewall, and disable
sharing on them, so that the idle timer has a chance to work. Windoze boxes
are extremely chatty, and would otherwise prevent timeouts. You may need to
monitor the ppp0 interface with tcpdump to detect such problems. You may
also want to (at least temporarily) monitor the ppp0 interface with a
simple packet sniffer, and see that you aren't being constantly probed by
other windoze boxes on the net (connection attempts to ports 135, 139, 445
among others) looking to share. The problem with that crap is that the
outside generated packets are resetting the "idle" timer, and this may
prevent pppd from deciding that the link is not in use. The solution
to that problem is "active-filter" option to pppd.

Old guy

In article <(E-Mail Removed)>,
Moe Trin <(E-Mail Removed)> wrote:
> On Sat, 04 Aug 2007, in the Usenet newsgroup comp.os.linux.networking, in
> article <fo8do4-(E-Mail Removed)>, Hactar wrote:
>
> >buck <(E-Mail Removed)> wrote:
>
> >> (E-Mail Removed) (Hactar) wrote:
>
> >>> Hi, I have a variant of Debian installed. Is there a pointy-clicky
> >>> way of enabling dial on demand for a regular analog (not ADSL) modem?
> >>> (This computer's for a very computer-illiterate person. While I have
> >>> no problem editing text files and writing scripts, she feels
> >>> differently.)
>
> Why does it have to be a pointy-clicky?

I guess it doesn't, if the end user never has to touch it. I just had
this idealized view of this distro as "for newbies, so everything's done
in a GUI". I guess not...

> This is a one-time shot, and needs only to add a line to the boot scripts.

I don't see a file /etc/.../*local* in Ubuntu 5.10; is there one (or a
work-alike) in 7.04?

> >> What's wrong with the demand option to pppd?
>
> >It doesn't bring the link up when I ping an outside site.
>
> How exactly are you trying to do this?

% ping foo.com
Host unreachable. <-- instant

But I'll try again and see if my futzing around changed things.

> All that is needed is a dumb script that is runnable by root - something
> like
>
> [compton ~]$ cat /usr/local/bin/dialin
> #!/bin/bash
> exec /usr/sbin/pppd connect "/usr/sbin/chat -f /etc/ppp/dialscript" lock \
> defaultroute noipdefault /dev/modem 115200 crtscts user ibuprofin \
> nodetach
> [compton ~]$

Doesn't have to be root, since pppd is SUID root, right? I mean, I ran
pppd as me (no sudo) and it worked.

> change the last line of the /usr/local/bin/dialin script so that it now
> reads:"
>
> [compton ~]$ cat /usr/local/bin/dialin
> #!/bin/bash
> exec /usr/sbin/pppd connect "/usr/sbin/chat -f /etc/ppp/dialscript" lock \
> defaultroute noipdefault /dev/modem 115200 crtscts user ibuprofin \
> demand idle 300 holdoff 15
> [compton ~]$

What's holdoff do?

> and then add two lines to the local boot script (usually rc.local) that
> read
>
> echo -n 1 > /proc/sys/net/ipv4/ip_dynaddr
> /usr/local/bin/dialin
>
> The first line is used to tell a 2.2.x or later kernel that the system will
> have dynamic IP addresses, while the second line runs the dialin script.

This is an example of Linux being user-hostile. Not that I'm
complaining...

> As
> this file (rc.local) is run by root, the daemon will be running as root.
> Now, pppd will start, but stay in the background and respond to requests for
> IP services after that. The idle 300 will cause the system to disconnect
> when the ppp link has been idle for 5 minutes (300 seconds). The holdoff 15
> means the system will not try to redial for 15 seconds after an idle
> timeout, to allow everything to recover.

Thanks. Disregard that last question then. :-)

> You may need to
> monitor the ppp0 interface with tcpdump to detect such problems. You may
> also want to (at least temporarily) monitor the ppp0 interface with a
> simple packet sniffer, and see that you aren't being constantly probed by
> other windoze boxes on the net (connection attempts to ports 135, 139, 445
> among others) looking to share. The problem with that crap is that the
> outside generated packets are resetting the "idle" timer, and this may
> prevent pppd from deciding that the link is not in use. The solution
> to that problem is "active-filter" option to pppd.

Is there a way to disregard _all_ packets that aren't a reply? Except
I'll need a way in to fix things...

--
-eben (E-Mail Removed)P http://royalty.mine.nu:81
ARIES: The look on your face will be priceless when you find that 40lb
watermelon in your colon. Trade toothbrushes with an albino dwarf, then
give a hickey to Meryl Streep. -- Weird Al, _Your Horoscope for Today_

In article <k3afo4-(E-Mail Removed)>,
Hactar <(E-Mail Removed)> wrote:
> In article <(E-Mail Removed)>,
> Moe Trin <(E-Mail Removed)> wrote:
> > On Sat, 04 Aug 2007, in the Usenet newsgroup comp.os.linux.networking, in
> > article <fo8do4-(E-Mail Removed)>, Hactar wrote:
> >
> > >buck <(E-Mail Removed)> wrote:
> >
> > >> (E-Mail Removed) (Hactar) wrote:
> >
> > This is a one-time shot, and needs only to add a line to the boot scripts.
>
> I don't see a file /etc/.../*local* in Ubuntu 5.10; is there one (or a
> work-alike) in 7.04?

There is an /etc/rc.local, which is called from /etc/init.d/rc.local,
which is linked to /etc/rc?.d/S99rc.local .

> > >> What's wrong with the demand option to pppd?
> >
> > >It doesn't bring the link up when I ping an outside site.
> >
> > How exactly are you trying to do this?
>
> % ping foo.com
> Host unreachable. <-- instant
>
> But I'll try again and see if my futzing around changed things.

Does now. Probably copying the lines pppd puts in /etc/resolv.conf and
adding them to it when the link _isn't_ up did it.

> > All that is needed is a dumb script that is runnable by root - something
> > like
> >
> > [compton ~]$ cat /usr/local/bin/dialin
> > #!/bin/bash
> > exec /usr/sbin/pppd connect "/usr/sbin/chat -f /etc/ppp/dialscript" lock \
> > defaultroute noipdefault /dev/modem 115200 crtscts user ibuprofin \
> > nodetach
> > [compton ~]$
>
> Doesn't have to be root, since pppd is SUID root, right? I mean, I ran
> pppd as me (no sudo) and it worked.

Ah well, is anyhow.

> > and then add two lines to the local boot script (usually rc.local) that
> > read
> >
> > echo -n 1 > /proc/sys/net/ipv4/ip_dynaddr
> > /usr/local/bin/dialin
> >
> > The first line is used to tell a 2.2.x or later kernel that the system will
> > have dynamic IP addresses, while the second line runs the dialin script.

Just for kicks, what happens if you don't have the first line? The link
will come up, but may not work?

--
-eben (E-Mail Removed)P http://royalty.mine.nu:81

"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert

On Sat, 04 Aug 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <k3afo4-(E-Mail Removed)>, Hactar wrote:

>Moe Trin <(E-Mail Removed)> wrote:

>> Why does it have to be a pointy-clicky?
>
>I guess it doesn't, if the end user never has to touch it. I just had
>this idealized view of this distro as "for newbies, so everything's done
>in a GUI". I guess not...

Actually, even with a GUI, most of the "system" stuff, such as your boot
scripts that wake the system up, are exactly that - scripts. A GUI is a
needless complication at that point.

>> This is a one-time shot, and needs only to add a line to the boot scripts.

>I don't see a file /etc/.../*local* in Ubuntu 5.10; is there one (or a
>work-alike) in 7.04?

Standards are wonderful thing;
everyone should have one of his very own

Are you using 'upstart' or the more traditional SysVinit?

>> How exactly are you trying to do this?
>
>% ping foo.com
>Host unreachable. <-- instant

OK - if you looked at your routing table you would have seen no existing
default route, I suspect you hadn't restarted pppd into the demand mode,
which creates a route using (checks man page... checks README.... checks
Changes-2.3) 10.112.112.112. (Just a comment, I'm no longer using demand
mode, as the cable and phone companies finally pulled their fingers out
and got wide-band available where I live. If I make a mistake here,
hopefully the other responder [Clifford Kite] will correct me.)

>Doesn't have to be root, since pppd is SUID root, right? I mean, I ran
>pppd as me (no sudo) and it worked.

pppd is not SUID by default - that's a distribution "improvement". The
reason I was specifying getting it running as root (the default mode) is
that normally trying to do things as a user runs into problems. The
script will be run at boot as root, so the extra hoops aren't needed.

>> The first line is used to tell a 2.2.x or later kernel that the system
>> will have dynamic IP addresses, while the second line runs the dialin
>> script.
>
>This is an example of Linux being user-hostile. Not that I'm
>complaining...

This is actually a standard thing in *nix - which was designed from
scratch for a multi-user mode. This means you don't want the users
effecting _other_ users. That's why bringing the networking up/down,
or mounting/unmounting disks and the like is not a "user" task. Face
it, most users don't think about other users who could be using a
resource that they're finished with.

>Is there a way to disregard _all_ packets that aren't a reply?
>Except I'll need a way in to fix things...

Ubuntu... I'm pretty sure it has the "standard" LBL version of tcpdump,
and yes you can set things that way. Top of the head, I'd suggest
something like

active-filter port 135 and port 139 and port 445

which if memory serves will cause packets in both directions to those
ports to be ignored. Hopefully, Clifford will notice this and make
any corrections, as he did a lot more work with the filters than I
had to.

As for needing a way to fix things, I'm assuming you're meaning coming
in over the Internet (SSH), which the above active-filter line would
have no effect upon. There will be plenty of other ways things can go
boom, but this isn't one of them.

Might as well combine the followup. In your other reply, you
wrote:"

>Hactar <(E-Mail Removed)> wrote:

>> I don't see a file /etc/.../*local* in Ubuntu 5.10; is there one
>>(or a work-alike) in 7.04?
>
>There is an /etc/rc.local, which is called from /etc/init.d/rc.local,
>which is linked to /etc/rc?.d/S99rc.local .

That sounds good

>> But I'll try again and see if my futzing around changed things.
>
>Does now. Probably copying the lines pppd puts in /etc/resolv.conf
>and adding them to it when the link _isn't_ up did it.

Above

>>> echo -n 1 > /proc/sys/net/ipv4/ip_dynaddr

>Just for kicks, what happens if you don't have the first line? The
>link will come up, but may not work?

That's my understanding, but as mentioned I haven't used this in a
while. You'll have to remember that this (ANU) ppp daemon is written
for more than just Linux, so the Linux specific stuff isn't as well
covered. But look at the paragraph in the man page before the section
labeled "MULTILINK" (roughly line 1450 to 1467 depending on the version
of pppd you are using, and assuming an 80 character wide screen).

Old guy

Moe Trin <(E-Mail Removed)> wrote:

> [compton ~]$ cat /usr/local/bin/dialin
> #!/bin/bash
> exec /usr/sbin/pppd connect "/usr/sbin/chat -f /etc/ppp/dialscript" lock \
> defaultroute noipdefault /dev/modem 115200 crtscts user ibuprofin \
> demand idle 300 holdoff 15
> [compton ~]$

You will also need to specify a remote IP address, e.g.,

:192.168.123.242

in order to get the PPP interface to come up with a default route after
the script is executed and, perhaps,

ipcp-accept-remote

so that pppd will accept a peer's request to use a different IP address.
Not all peers will insist on choosing their own IP address but some will.
And any private IP address should work if accepted.

After executing the script check to see if the PPP interface is up
with ifconfig. This pre-remote-connection interface is monitored by
pppd running in the "background" and must exist for demand to work.
It's absence may well be the reason for the ping instant "Host
unreachable" message.

> and then add two lines to the local boot script (usually rc.local) that
> read

> echo -n 1 > /proc/sys/net/ipv4/ip_dynaddr
> /usr/local/bin/dialin

In the kernel documentation:

/usr/src/linux-2.6.21.6/Documentation/networking/ip_dynaddr.txt

I think it essentially says that this will help whatever caused the link
through the modem to be established to finish what it started.

> The first line is used to tell a 2.2.x or later kernel that the system will
> have dynamic IP addresses, while the second line runs the dialin script. As
> this file (rc.local) is run by root, the daemon will be running as root.
> Now, pppd will start, but stay in the background and respond to requests for
> IP services after that. The idle 300 will cause the system to disconnect
> when the ppp link has been idle for 5 minutes (300 seconds). The holdoff 15
> means the system will not try to redial for 15 seconds after an idle
> timeout, to allow everything to recover.

> Other things to consider: You may want to be running a firewall (hint -
> hint) to protect you from the outside world. If masquerading for windoze
> boxes, be sure to block ports 137, 138, and 139 with a firewall, and disable
> sharing on them, so that the idle timer has a chance to work. Windoze boxes
> are extremely chatty, and would otherwise prevent timeouts. You may need to
> monitor the ppp0 interface with tcpdump to detect such problems. You may
> also want to (at least temporarily) monitor the ppp0 interface with a
> simple packet sniffer, and see that you aren't being constantly probed by
> other windoze boxes on the net (connection attempts to ports 135, 139, 445
> among others) looking to share. The problem with that crap is that the
> outside generated packets are resetting the "idle" timer, and this may
> prevent pppd from deciding that the link is not in use. The solution
> to that problem is "active-filter" option to pppd.

E.g.,

active-filter '(outbound and not (icmp[0] = 0))'

allows only outbound traffic that is not a ping echo-reply to reset the
idle timer. If you run a firewall and block ping echo-requests then
outbound is all that is needed.

--
Clifford Kite
/* Speak softly and carry a sucker rod (See man syslogd, footnote to
recommendation 4 under SECURITY THREATS). */

On Sun, 5 Aug 2007, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed)>, Clifford Kite wrote:

Hi Clifford!

>Moe Trin <(E-Mail Removed)> wrote:
>
>> [compton ~]$ cat /usr/local/bin/dialin
>> #!/bin/bash
>> exec /usr/sbin/pppd connect "/usr/sbin/chat -f /etc/ppp/dialscript" lock \
>> defaultroute noipdefault /dev/modem 115200 crtscts user ibuprofin \
>> demand idle 300 holdoff 15
>> [compton ~]$
>
>You will also need to specify a remote IP address, e.g.,
>
>:192.168.123.242
>
>in order to get the PPP interface to come up with a default route after
>the script is executed

Now I don't know why, but my notes (how I was running this) don't mention
this as being needed. In the "Changes-2.3" file (the old ChangeLog for the
2.3.x series), there is an entry for 2.3.10 that says:

* Pppd no longer requires a remote address to be specified for demand
dialling. If none is specified, it will use a default value of
10.112.112.112+unit_number. (It will not propose this default to
the peer.)

Did this change back in the 2.4.x releases? I know that 2.4.4 (which I'm
not running - still on 2.4.2) mentions (in the README)

* Lots of bugs fixed, particularly in the area of demand-dialled and
persistent connections.

but I haven't diff'ed the files to see what might have changed (recall
that my C skills are abysmal at best).

>After executing the script check to see if the PPP interface is up
>with ifconfig. This pre-remote-connection interface is monitored by
>pppd running in the "background" and must exist for demand to work.
>It's absence may well be the reason for the ping instant "Host
>unreachable" message.

That was my take

>/usr/src/linux-2.6.21.6/Documentation/networking/ip_dynaddr.txt
>
>I think it essentially says that this will help whatever caused the link
>through the modem to be established to finish what it started.

Looking through the man pages, I found the section commenting about the
changing addresses - roughly line 1469 on the page for ppp-2.4.4. It
turns out the paragraph is identical to the one in the man page for
ppp-2.3.5 (roughly line 956). I guess this is a section that needs to
be pulled (or at least re-written).

>active-filter '(outbound and not (icmp[0] = 0))'
>
>allows only outbound traffic that is not a ping echo-reply to reset the
>idle timer. If you run a firewall and block ping echo-requests then
>outbound is all that is needed.

Yeah - that would be perfect. I haven't used pppd in demand mode for several
years now, so I had forgotten the syntax even. I might suggest using

'(outbound and not (icmp[0] = 3))'

so that the timer ignores inbounds and any ICMP Type 3 (unreachable) in
either direction.

Old guy