demand dialing - Networking

This is a discussion on demand dialing - Networking ; 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 ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: demand dialing

  1. 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 QebWenE01R@vTerYizUonI.nOetP 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_

  2. Re: demand dialing

    On Fri, 03 Aug 2007 20:07:47 GMT, ebenZEROONE@verizon.net (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

  3. Re: demand dialing

    In article <8om7b396v1tt2654bs0fnf19ven1c8a22p@4ax.com>,
    buck wrote:
    > On Fri, 03 Aug 2007 20:07:47 GMT, ebenZEROONE@verizon.net (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

  4. Re: demand dialing

    Hactar wrote:
    > In article <8om7b396v1tt2654bs0fnf19ven1c8a22p@4ax.com>,
    > buck 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. */

  5. Re: demand dialing

    On Sat, 04 Aug 2007, in the Usenet newsgroup comp.os.linux.networking, in
    article , Hactar wrote:

    >buck wrote:


    >> ebenZEROONE@verizon.net (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

  6. Re: demand dialing

    In article ,
    Moe Trin wrote:
    > On Sat, 04 Aug 2007, in the Usenet newsgroup comp.os.linux.networking, in
    > article , Hactar wrote:
    >
    > >buck wrote:

    >
    > >> ebenZEROONE@verizon.net (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 QebWenE01R@vTerYizUonI.nOetP 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_

  7. Re: demand dialing

    In article ,
    Hactar wrote:
    > In article ,
    > Moe Trin wrote:
    > > On Sat, 04 Aug 2007, in the Usenet newsgroup comp.os.linux.networking, in
    > > article , Hactar wrote:
    > >
    > > >buck wrote:

    > >
    > > >> ebenZEROONE@verizon.net (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 QebWenE01R@vTerYizUonI.nOetP 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

  8. Re: demand dialing

    On Sat, 04 Aug 2007, in the Usenet newsgroup comp.os.linux.networking, in
    article , Hactar wrote:

    >Moe Trin 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 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

  9. Re: demand dialing

    On Sun, 5 Aug 2007, in the Usenet newsgroup comp.os.linux.networking, in article
    , Clifford Kite wrote:

    Hi Clifford!

    >Moe Trin 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


  10. Re: demand dialing

    Moe Trin wrote:
    > On Sun, 5 Aug 2007, in the Usenet newsgroup comp.os.linux.networking,
    > in article , Clifford Kite wrote:


    > Hi Clifford!


    Back at ya Moe!

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


    The honest answer is I don't know. I'd forgotten about those defaults
    and had looked in man pppd for pppd 2.4.4 to refresh memory about demand:

    demand Initiate the link only on demand, i.e. when data
    traffic is present. With this option, the remote
    IP address must be specified by the user on the
    command line or in an options file.

    And I haven't dappled in demand lately.

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


    I doubt they are worst than mine. But just now a grep -rs 70 pppd/*.[hc]
    (ppp-2.4.4) yielded, among others,

    pppd/ipcp.c: wo->hisaddr = htonl(0x0a707070 + ifunit);

    which is in the function ip_demand_conf(u) so it's probably still a
    default despite the explicit wording of the man pages.

    >>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


    The only other reason I know that might cause that message appearing
    instantly with a default route present is the absence of nameservers
    in resolv.conf.

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


    I think my comment may need rewriting - replace "will" with "may."

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


    I'm not sure what you have in mind but there doesn't seem to be a type 3
    for code 0, only a type 0. Stevens Vol 1..

    --
    Clifford Kite
    /* Slogan appropriate for a certain well-known software company:
    FAILURE IS NOT AN OPTION - it is built into the operating system
    and comes bundled with the software. And it attracts maggots. */

  11. Re: demand dialing

    Hi Clifford!

    On Sun, 5 Aug 2007, in the Usenet newsgroup comp.os.linux.networking, in article
    <4ob59f.u71.ln@corncob.inetport.tld>, Clifford Kite wrote:

    >The honest answer is I don't know. I'd forgotten about those defaults
    >and had looked in man pppd for pppd 2.4.4 to refresh memory about demand:
    >
    > demand Initiate the link only on demand, i.e. when data
    > traffic is present. With this option, the remote
    > IP address must be specified by the user on the
    > command line or in an options file.


    Well, let's mark that up as another section that needs to be re-written.
    I copied the demand option section (2 paragraphs, 15 lines) from the 2.3.5
    and 2.4.4 pages to a pair of files...

    [compton ~]$ diff -b -w demand-2.3.5 demand-2.4.4
    1c1
    < 2.3.5
    ---
    > 2.4.4

    [compton ~]$

    Are you still in contact with Paul? As this is a Linux only mode, I'm
    not sure James would be interested.

    >And I haven't dappled in demand lately.


    Same here - I'm still using ppp, but it's a backup for when the
    broad-band goes out.

    >The only other reason I know that might cause that message appearing
    >instantly with a default route present is the absence of nameservers
    >in resolv.conf.


    I'm not so sure - the original posting said:

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

    A DNS problem would be "unknown host", would it not? "Host Unreachable"
    says that it knows an IP, but either the gateway is dead, or the
    destination host (or something in-between)is returning an ICMP Unreachable.

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

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

    >
    >I'm not sure what you have in mind but there doesn't seem to be a type 3
    >for code 0, only a type 0. Stevens Vol 1..


    Blame that on the confusion surrounding the tcpdump man page. I'm reading
    that '[0]' as the byte offset relative to the protocol layer, hence the
    example

    To print all ICMP packets that are not echo
    requests/replies (i.e., not ping packets):
    tcpdump 'icmp[0] != 8 and icmp[0] != 0"

    Are we having fun yet? ;-)

    Old guy

  12. Re: demand dialing

    Moe Trin wrote:
    > Hi Clifford!


    > On Sun, 5 Aug 2007, in the Usenet newsgroup comp.os.linux.networking,
    > in article <4ob59f.u71.ln@corncob.inetport.tld>, Clifford Kite wrote:
    >>

    > Are you still in contact with Paul? As this is a Linux only mode, I'm
    > not sure James would be interested.


    No, I dropped out of the linux-ppp mailing list some time ago and haven't
    been in a hurry to get back in - it seemed to generate a lot of spam.

    >>The only other reason I know that might cause that message appearing
    >>instantly with a default route present is the absence of nameservers
    >>in resolv.conf.


    > I'm not so sure - the original posting said:


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


    > A DNS problem would be "unknown host", would it not? "Host Unreachable"
    > says that it knows an IP, but either the gateway is dead, or the
    > destination host (or something in-between)is returning an ICMP Unreachable.


    I think the message is whatever the coder (or whomever) wants it to be.
    And yes, I'm more comfortable with "unknown host" in cases where a FQDN
    cannot be resolved but if the FQDN can't be resolved then the host is
    also unreachable.

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

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

    >>
    >>I'm not sure what you have in mind but there doesn't seem to be a type 3
    >>for code 0, only a type 0. Stevens Vol 1..


    > Blame that on the confusion surrounding the tcpdump man page.


    I think I'll blame my preceding remark on _my_ confusion. You are right,
    it has to be icmp(0)=type and icmp(1)=code.

    I'm reading
    > that '[0]' as the byte offset relative to the protocol layer, hence the
    > example


    > To print all ICMP packets that are not echo
    > requests/replies (i.e., not ping packets):
    > tcpdump 'icmp[0] != 8 and icmp[0] != 0"


    Which is correct. Tcpdump expressions always did give me a headache.

    FYI, the tcpdump man pages here (April 2005) explain the usage better
    and introduce names that can be used as arguments. In particular above
    example is presented as

    To print all ICMP packets that are not echo
    requests/replies (i.e., not ping packets):
    tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'

    > Are we having fun yet? ;-)


    :%P

    --
    Clifford Kite
    /* "They that can give up essential liberty to obtain a little temporary
    safety deserve neither liberty nor safety." Benjamin Franklin */


  13. Re: demand dialing

    On Mon, 6 Aug 2007, in the Usenet newsgroup comp.os.linux.networking, in article
    , Clifford Kite wrote:

    >Moe Trin wrote:


    >> Are you still in contact with Paul? As this is a Linux only mode, I'm
    >> not sure James would be interested.

    >
    >No, I dropped out of the linux-ppp mailing list some time ago and haven't
    >been in a hurry to get back in - it seemed to generate a lot of spam.


    I normally don't subscribe to mailing lists directly, just for that
    reason. I had a look at the Usenet mirrors, and find about a dozen
    groups that are possible, but only 'apana.lists.os.linux.ppp' has any
    articles, and they are all spam from 2004/2005. So it looks as if the
    mirrors gave up for the same reasons. Do you know if the address in the
    README works? I hesitate to mail Paul without having actual corrections
    (rather than just "paragraph so-and-so in the manual is wrong")

    >Tcpdump expressions always did give me a headache.


    I've been using tcpdump since the early 1990s (somewhere, I still have an
    ancient man page for 2.2.x from 1992), and I still have troubles with the
    syntax. About half the time, I'm running from a get of notes that give
    me something to 'cut-and-paste' which is usually developed by capturing
    everything to a file, then running (and re-running until I get it right)
    off that file. Obviously wouldn't work well in this situation. Thing
    is, there are a number of applications that tell you to use the same
    'syntax from the tcpdump man page' and often don't even come with
    examples.

    Old guy

  14. Re: demand dialing

    Moe Trin wrote:

    > Do you know if the address in the
    > README works? I hesitate to mail Paul without having actual corrections
    > (rather than just "paragraph so-and-so in the manual is wrong")


    It probably works is as good an answer as I have. 2.4.4 is only about
    a year old and there's none newer.

    Chow-
    --
    Clifford Kite


+ Reply to Thread