Hi all

I am using FC4. I want to set up dial on demand for a modem connection
to my isp.

I found the following article, dated 2002, which explains how to do it
using wvdial and pppd -

http://www.davidpashley.com/tutorial...-pppd-dod.html

I have followed the instructions and it seems to work pretty well.

Is this the preferred way to do it these days? I see that diald is no
longer included in the standard distribution, which seems to indicate
that it is not the current preference.

I have one small problem. I have included the option 'demand' in
/etc/ppp/peers/dod, but it stills dials the modem when I activate pppd
the first time, using 'pon dod' or 'pppd call dod'. My understanding is
that it should just start pppd, but it should not dial the modem until
the first request for a connection.

man pppd states that the remote IP address must be specified when using
the demand option. My isp assigns the local and remote ip addresses
dynamically, so I do not know what to put here. Could this be the cause
of the problem?

Thanks for any assistance.

Frank Millman

In the Usenet newsgroup comp.os.linux.setup, in article
<1127453581.494849.43550@o13g2000cwo.googlegroups. com>,
frank@chagford.com wrote:

>I am using FC4. I want to set up dial on demand for a modem connection
>to my isp.
>
>I found the following article, dated 2002, which explains how to do it
>using wvdial and pppd -
>
> http://www.davidpashley.com/tutorial...-pppd-dod.html

Why make it so complex? Create a dumb script that looks something like
this:

[compton ~]$ cat /usr/local/bin/dialin
#!/bin/bash
exec /usr/sbin/pppd connect "/usr/sbin/chat -f /etc/ppp/dialscript" \
defaultroute lock noipdefault modem /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 ~]$

That's a standard PAP style connection as mandated by windoze. The AT&F1
is for a US Robotics modem, but most others want AT&F0. See your modem
manual. This script is based on Bill Unruh's web page at
http://axion.physics.ubc.ca/ppp-linux.html or
http://www.theory.physics.ubc.ca/ppp-linux.html but all of the options
are in the man pages. Oh, don't forget to correct the phone number. The
script also uses /dev/modem - if that's not used, correct as required.

Get that script working from the command line as root. Obviously, that
means replacing the user name, and having /etc/ppp/pap-secrets (and/or
/etc/ppp/chap-secrets) with username and password. Once this is working
from the command line, replace the 'nodetach' with 'demand idle 300
holdoff 15', and run the script out of rc.local (which is the last
boot script, and is run by root). You also need the line

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

ahead of the line that starts pppd in demand mode.

>Is this the preferred way to do it these days? I see that diald is no
>longer included in the standard distribution, which seems to indicate
>that it is not the current preference.

diald fell out of favor when pppd acquired the demand capability in
ppp-2.3.0 about 9 years ago. As for what is preferred today - it's
what-ever makes you happy.

>I have one small problem. I have included the option 'demand' in
>/etc/ppp/peers/dod, but it stills dials the modem when I activate pppd
>the first time, using 'pon dod' or 'pppd call dod'. My understanding is
>that it should just start pppd, but it should not dial the modem until
>the first request for a connection.

Only thing I can think of is perhaps something is triggering the call,
perhaps a DNS lookup. What is in /etc/resolv.conf BEFORE you start
pppd? You could TEMPORARILY start tcpdump out of /etc/ppp/ip-up.local
to see what traffic is going out. Try '/usr/sbin/tcpdump -n -i ppp0'
as a minimum. Do kill tcpdump in ip.down.local, or you'll run into
problems with multiple instances.

>man pppd states that the remote IP address must be specified when using
>the demand option.

It does??? Hmmm, that conflicts with the changes to ppp-2.3.10 - see
the file "Changes-2.3"... here:

* 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.)

Looks like the man page never got updated. Yup - the man entry is the same
for ppp-2.3.5, which is the oldest 2.3 man page I have handy.

Old guy

Moe Trin wrote:
> In the Usenet newsgroup comp.os.linux.setup, in article
> <1127453581.494849.43550@o13g2000cwo.googlegroups. com>,
> frank@chagford.com wrote:
>
> >I am using FC4. I want to set up dial on demand for a modem connection
> >to my isp.
> >
[snip]
>
> >I have one small problem. I have included the option 'demand' in
> >/etc/ppp/peers/dod, but it stills dials the modem when I activate pppd
> >the first time, using 'pon dod' or 'pppd call dod'. My understanding is
> >that it should just start pppd, but it should not dial the modem until
> >the first request for a connection.
>
> Only thing I can think of is perhaps something is triggering the call,
> perhaps a DNS lookup. What is in /etc/resolv.conf BEFORE you start
> pppd? You could TEMPORARILY start tcpdump out of /etc/ppp/ip-up.local
> to see what traffic is going out. Try '/usr/sbin/tcpdump -n -i ppp0'
> as a minimum. Do kill tcpdump in ip.down.local, or you'll run into
> problems with multiple instances.
>

Thanks for the really useful reply, Moe. Sorry about the delay in
responding, but it took me a while to carry out the test you proposed.

/etc/resolv.conf just has two nameserver lines for the IP addresses of
the DNS servers that my isp gave me.

This is what tcpdump showed -

'11:45:15 IP 155.239.110.127 > 224.0.0.22: igmp v3 report, 1 group
record(s)'

The first address is the one that my ISP dynamically assigned to me.
According to what I have read, the second address is a multicast
address. Here is a quote that I found -

'IGMP (configured on a router) periodically sends out IGMP general
queries. A host responds to these queries with IGMP membership reports
for groups that it is interested in.'

I am not using a router. It is a plain FC4 box, not connected to a lan,
with a modem for dialup to the ISP.

It is running IP-Masquerading, which I have set up according to the
latest HOWTO, as I want to use the machine as an internet server for a
small lan. The HOWTO gives details of two firewall setups - one very
simple one for testing, and one much stronger one for the real world.
At this stage I am using the simple one.

Let me know if there is any other information I can provide.

Any assistance will be much appreciated.

Frank Millman

In the Usenet newsgroup comp.os.linux.setup, in article
<1127828989.110260.93260@g47g2000cwa.googlegroups. com>, Frank Millman wrote:

>This is what tcpdump showed -
>
>'11:45:15 IP 155.239.110.127 > 224.0.0.22: igmp v3 report, 1 group record(s)'

OK - that's RFC3376 "Internet Group Management Protocol, Version 3"

>The first address is the one that my ISP dynamically assigned to me.
>According to what I have read, the second address is a multicast
>address. Here is a quote that I found -
>
>'IGMP (configured on a router) periodically sends out IGMP general
>queries. A host responds to these queries with IGMP membership reports
>for groups that it is interested in.'
>
>I am not using a router. It is a plain FC4 box, not connected to a lan,
>with a modem for dialup to the ISP.

You have something that is interested in receiving Multicast. This could
be something like RealAudio, or similar. You could change your tcpdump
command to increase the length of the packet you are grabbing (the
default is 68 bytes) with the -s option to '-s 256' - that should tell
you which multicast connection you are looking for.

As you don't have a LAN behind this box, this infers that the application
has to be something on this box. I'd review what services you have running
to identify the trigger. By the way, IP Masquerading is implying a router
function. That isn't needed on a standalone box, but the moment you put
other hosts onto a LAN and use this system as the gateway to the world,
then you are running a router.

>It is running IP-Masquerading, which I have set up according to the
>latest HOWTO, as I want to use the machine as an internet server for a
>small lan.

When you say 'internet server', do you mean running a server (web, ftp,
or whatever) for use by clients out here, or do you mean providing
internet services to your LAN - allowing them to access the world. The
first is a lot harder and more risky than the second.

Old guy

Moe Trin wrote:
> In the Usenet newsgroup comp.os.linux.setup, in article
> <1127828989.110260.93260@g47g2000cwa.googlegroups. com>, Frank Millman wrote:
>
> >This is what tcpdump showed -
> >
> >'11:45:15 IP 155.239.110.127 > 224.0.0.22: igmp v3 report, 1 group record(s)'
>
> OK - that's RFC3376 "Internet Group Management Protocol, Version 3"
>
> You have something that is interested in receiving Multicast. This could
> be something like RealAudio, or similar. You could change your tcpdump
> command to increase the length of the packet you are grabbing (the
> default is 68 bytes) with the -s option to '-s 256' - that should tell
> you which multicast connection you are looking for.
>

Found it - thanks! I found it by selectively disabling services until
it stopped. It turns out that it was a combination of mDNSResponder and
nifd. If both of these are running, it sends the request. If either of
them are off, it does not. They both seem to have something to do with
Howl (whatever that is), which I am not using, so I turned them both
off. I also turned off a number of other services which seemed
redundant, so it was a good exercise.

> >It is running IP-Masquerading, which I have set up according to the
> >latest HOWTO, as I want to use the machine as an internet server for a
> >small lan.
>
> When you say 'internet server', do you mean running a server (web, ftp,
> or whatever) for use by clients out here, or do you mean providing
> internet services to your LAN - allowing them to access the world. The
> first is a lot harder and more risky than the second.
>

Definitely the second. Even that is a bit risky, but I found the
IP-Masquerade HOWTO invaluable in giving advice on protecting yourself.

Many thanks for your assistance.

Frank