To: "Karl O. Pinc" <kop@meme.com>
Subject: diald-config
Date: Wed, 16 Apr 1997 16:28:22 -0400
From: "John A. Martin" <jam@jamux.com>
Status: RO

Your work finally pushed me to rationalize my diald/ppp configuration
which was a legacy from way back when I maintained my linux box
without benefit of any distribution.  Many thanks.

A couple of small items follow relative to diald-config-0.1-1.

1.  It looks as if /usr/local/lib/diald/standard.filter.m4 got to me
with a couple of typos.

----------------- cut here ---->8
*** standard.filter.m4-orig	Thu Apr  3 02:40:22 1997
--- standard.filter.m4	Wed Apr 16 10:36:55 1997
***************
*** 53,59 ****
  ')dnl
  
  
! ifdef(`NAMESERVER',dnl
  # Keep named xfers from holding the link up
  ignore tcp tcp.dest=tcp.domain
  ignore tcp tcp.source=tcp.domain
--- 53,59 ----
  ')dnl
  
  
! ifdef(`NAMESERVER',`dnl
  # Keep named xfers from holding the link up
  ignore tcp tcp.dest=tcp.domain
  ignore tcp tcp.source=tcp.domain
***************
*** 110,116 ****
  accept tcp MAILCHECK_TIMEOUT tcp.dest=tcp.pop-3
  accept tcp MAILCHECK_TIMEOUT tcp.source=tcp.pop-3
  
! accept tcp MAILCHECK_TIMEOUT tcp.dest=tcp.pop-3
  accept tcp MAILCHECK_TIMEOUT tcp.source=tcp.pop-2
  ')dnl
  
--- 110,116 ----
  accept tcp MAILCHECK_TIMEOUT tcp.dest=tcp.pop-3
  accept tcp MAILCHECK_TIMEOUT tcp.source=tcp.pop-3
  
! accept tcp MAILCHECK_TIMEOUT tcp.dest=tcp.pop-2
  accept tcp MAILCHECK_TIMEOUT tcp.source=tcp.pop-2
  ')dnl

----------------- cut here ---->8

2.  Diald seems to work fine for me without the `dynamic' option when
only the remote address is not fixed and seems a little cleaner.

----------------- cut here ---->8
*** diald-orig	Thu Apr  3 02:40:21 1997
--- diald	Wed Apr 16 15:20:56 1997
***************
*** 105,111 ****
  else
    echo "remote 192.168.0.2"
  fi
! if [ -z "${REMIP}" -o -z "${IPADDR}" ] ; then
    echo "dynamic"
  fi
  
--- 105,112 ----
  else
    echo "remote 192.168.0.2"
  fi
! #if [ -z "${REMIP}" -o -z "${IPADDR}" ] ; then
! if [ -z "${IPADDR}" ] ; then
    echo "dynamic"
  fi
----------------- cut here ---->8

3.  I have not tested to see the ill effects but it seems it might be
better to let /etc/ppp/options be just a zero length file.  It looks
as if after installing successively ppp-2.2.0f-3, diald-0.16-3, and
diald-config-0.1-1 without stopping I was left with a /etc/ppp/options
containing just the `lock' option which may not be too good.

Inexplicably I was unable to get diald to start pppd the first time
until I caused a `mode ppp' to appear in /tmp/blah in addition to
being in /etc/xxx.  After everything was running I could not reproduce
the problem by reverting /etc/sysconfig/network-scripts/diald to the
way it came from the package.  I have yet to see how diald comes up
from a boot however.

I hope this is helpful and I thank you for the fine package.
==========================================================
To: "Karl O. Pinc" <kop@meme.com>
Subject: Re: diald-config 
Date: Thu, 17 Apr 1997 13:19:41 -0400
From: "John A. Martin" <jam@jamux.com>
Status: RO

>>>>> On Thu, 17 Apr 1997 10:44:48 -0500, "Karl O. Pinc" <kop@meme.com> said:

    >> 1.  It looks as if /usr/local/lib/diald/standard.filter.m4 got
    >> to me with a couple of typos.

    Karl> Very likely they are the product of my very own
    Karl> typo-generator.

Perhaps there is yet more to look at in ../standard.filter.m4.

1.  `MAIL_TIMEOUT' (/etc/sysconfig/diald and
/etc/sysconfig/network-scripts/diald) seems to be missed by
../standard.filter.m4 who looks for `MAIL_CHECK_TIMEOUT' _and_
`MAILCHECK_TIMEOUT' as if to be a little independent minded.

2.  Methinks imap might be happy in the company of pop2 and pop3 and
even perhaps a little left out otherwise.

3.  It might do to consider giving smtp a separate timeout.  Eric
Allman might argue for one hour (SMM 4.1.2) but many folks would do
with 5 minutes perhaps, or 3 min if only sending to a "smarthost",
which might be a reasonable default value because that is probably
what one should be doing from the end of a wet string anyway.

    >>  2.  Diald seems to work fine for me without the `dynamic'
    >> option when only the remote address is not fixed and seems a
    >> little cleaner.

    Karl> This bears looking into.  Do you know that "dynamic" is only
    Karl> good for when the remote end is dynamic?  I suspect this is
    Karl> not the case, only because diald does seem to want to know
    Karl> about the ip's at both ends of the link.  Do you know if
    Karl> this would be a good question for the diald mailing list?

Its a ppp thing and I've done without "dynamic" with a fixed (aka
"static") local IP but a throw of the dice on the remote end for years
with and without diald.  An unneeded "dynamic" may be harmless except
perhaps as an opening for needless troubles, I dunno.  I haven't
looked at the diald list for years.  NB my local is where I type on a
keyboard the other end is the "remote", right?

    >>  3.  I have not tested to see the ill effects but it seems it
    >> might be better to let /etc/ppp/options be just a zero length
    >> file.  It looks as if after installing successively
    >> ppp-2.2.0f-3, diald-0.16-3, and diald-config-0.1-1 without
    >> stopping I was left with a /etc/ppp/options containing just the
    >> `lock' option which may not be too good.

    Karl> The only change in the rpm release -3 that I did for ppp was
    Karl> to make /etc/ppp/options an empty file.  Obviously, this was
    Karl> not good enough because rpm dosen't want to eat your
    Karl> existing config files.  Time to hit the rpm list to see if
    Karl> there's a way to alert the installer that a config file
    Karl> change is necessary.

    >>  Inexplicably I was unable to get diald to start pppd the first
    >> time until I caused a `mode ppp' to appear in /tmp/blah in
    >> addition to being in /etc/xxx.  After everything was running I
    >> could not reproduce the problem by reverting
    >> /etc/sysconfig/network-scripts/diald to the way it came from
    >> the package.  I have yet to see how diald comes up from a boot
    >> however.

    Karl> I recall deliberately leaving the mode ppp out because the
    Karl> diald doc said it was the default.  I suppose it should go
    Karl> back in if it's a problem.

Sorry I forgot to fill in the place holders with the right filenames
above.  Of course it was /tmp/diald.conf that I buggered and it looks
to me like you _do_ have `mode ppp' in /etc/diald.conf.  I still do
not understand why that did not work originally and I have still not
reproduced the problem that plagued me at the outset, but I have not
yet rebooted.

    Karl> Upgrade warning: I'm going to require the local and remote
    Karl> IP's be specified in the diald config file.  The
    Karl> administrator needs to know what they are, instead of just
    Karl> having them be magic, so he can set up /etc/hosts entries or
    Karl> whatnot and so they don't conflict with any actually used on
    Karl> the local net.

Yes, and unless you go to great lengths you will then leave it to the
user to decide whether or not the "dynamic" option is needed.  If she
reads the existing documentation she will see that "dynamic" is only
needed if she has a "dynamic" IP for her _local host_.

			jam
======================================================
To: "Karl O. Pinc" <kop@meme.com>
Subject: Re: diald-config 
Date: Fri, 18 Apr 1997 19:02:31 -0400
From: "John A. Martin" <jam@jamux.com>

The word for today is "Standard is better than better".

>>>>> On Thu, 17 Apr 1997 17:46:10 -0500, "Karl O. Pinc" <kop@meme.com> said:

    >> Consider 
    >> # 
    >> # These timeouts should correspond to the timeouts in the 
    >> # respective applications.plus a little slack if experience dictates.  
    >> # FETCHMAIL_TIMEOUT=240 
    >> # SENDMAIL_TIMEOUT=240

The version of fetchmail that I have at hand has a default timeout of
5 minutes.  Currently sendmail has 13 pertinent adjustable timeouts.
The distributed defaults range from 0 to 1 hour.  The the largest of
the minimums allowed by RFC 1123 section 5.3.2 is 10 minutes.  Allman
has good reasons for the 1 hour timeouts but, like I said, folks
without a full time connection probably ought to avoid those
situations perhaps by sending all outgoing mail to a reasonable
"smarthost".  If you do the mail timeout thing at all you might want
to offer

# FETCHMAIL_TIMEOUT=300
# SENDMAIL_TIMEOUT=600

which have at least some rhyme and reason.  You do of course want the
default filtering to do your "QUICK_DROP", right?

    >> Actually I found myself thinking on what you _meant_ rather
    >> than what you said on first reading of the commentary in
    >> /etc/sysconfig/diald.

    Karl> Um, which?  Does something need rewriting?

The commentary with MAIL_TIMEOUT in /etc/sysconfig/diald.

    Karl> Got a point there.  Does SENDMAIL_TIMEOUT=0 make sense if
    Karl> you want smtp to be ignored so that the link dosen't come
    Karl> up?  As opposed to SENDMAIL_TIMEOUT= (or just not defining
    Karl> it) for having the smtp have the default timeouts?

I would either leave the mail timeouts alone or do as above.  Beyond
assuring that the connection does not go away before the application
timeouts expire, which can cause real havoc with sendmail if not
fetchmail, it is probably best to leave applications problems to the
applications and not to use diald's filtering rules to address
problems that have to do with managing applications.  Sendmail in
particular has ample options available to let it be run exactly how
and when the user (administrator) wants it to be run.  If the
alternatives to sendmail fail in that respect then they are broken.

    Karl> This is sort of off topic, but I try to get my apps to use
    Karl> localhost.  By putting a fully qualified alias in /etc/hosts
    Karl> for localhost, so that the domain is the same as that
    Karl> returned by "hostname", emacs, sendmail and whatnot will all
    Karl> use localhost.  This has to be more efficent anyhow.

I dunno what advantages that might have but efficiency would be one of
them only if something is broken.  The kernel and the device drivers
are smart enough to route self addressed stuff the same way no mater
what the form of the address might be.  On a properly conventionally
configured box that is up and running there should be no discernible
difference in ping time or whatever between localhost, nickname, or
FQDN addressing one of its own interfaces.

    >>  Yes, sounds good.  Also give a script that tries alternate
    >> numbers when getting busy signals.  Another thing to make easy
    >> is to switch from one destination to another with only a single
    >> line.  I see folks do the latter fairly often but not too
    >> gracefully I think.  (I live much more simply.)

    Karl> Good ideas.  The trouble with these suggestions is that I'm
    Karl> trying to have the diald integrate with redhat's ppp
    Karl> configuration, which, AFIK, only allows one
    Karl> number/destination per interface.  The advantage of
    Karl> integration is, the user has only to configure once and can
    Karl> then use diald or manual ppp, and, once ppp is fixed up with
    Karl> these options, diald will have them too.  So, the redhat
    Karl> dialing config needs support for dialing destinations as
    Karl> separate database entities.  I'm not really up for it, I'm
    Karl> just looking to make stable what I've already done.

Do you have any word on the promise that the next pppd will do the
diald tricks itself?

One way to get alternate destinations for the present might be to have
several devices ppp0, ppp1, ... pointing to a single port, like
/dev/modem, but with different telephone numbers and chat scripts.
Alternate numbers for the same destination with busy signals should
only be a somewhat fancier script.  I dunno,

    Karl> Maybe we should have been discussing this on
    Karl> redhat-devel-list.

I had no idea of getting so deep into this.

BTW your stuff continued working for me after a reboot.  I'm writing
off my initial problems getting diald to start ppp to a kink of some
kind in what I did trying not to break my old stuff while integrating
the new.

Now for some gratuitous remarks.

In keeping with "standard is better than better" it seems like it
might be a good idea to let the diald-configure'ed diald work out of
the box just like Schenk's would, at least in principle.

Eric's defaults have been unchanged for like three years since he was
in Toronto and reflect a lot of experience and good thinking.  Any
changes should IMHO be very carefully thought out.  Updates to keep
pace with the now much better /etc/services files in circulation and
the widespread use of fetchmail and sendmail on lonely boxes at the
end of the line are good however.

Before chucking redundant stuff, I did an Ediff (emacs) between
/usr/lib/diald/standard.filter and my present /tmp/diald.filter.  They
are close enough that it might be worth just a little work to make
sure there are no gratuitous differences at all.  Anyway, below is a
list of what that comparison brought to mind.  Since I've hacked on
your stuff and was not planning on this exercise I may see differences
that are not in your distribution and more likely missed some that
are.

1. Let Eric's `accept tcp 15 tcp.syn' stand at the top unless you know
of a good reason not to.  Would that interfere with the lcp stuff you
include?  How would a user know which he needed?  Perhaps both can
live side by side as the default.

2. (Very important) keep as the default

	keepup tcp 5 !tcp.live
	ignore tcp !tcp.live

3. keep the domain stuff in the default.

4. www --> http : good, 120 --> 1800 : bad <-- (put it back as default).

5. Uncommenting ftp-data : good, 120 --> 1800 : bad <--.

6. Do _not_ lump ftp with www!  Use two parameters.

7. udp.domain 30 --> 50 : bad <--

8. Put the SCO and netbios filters back in the default set.

Because the sequence of filter rules is significant, consider putting
/etc/sysconfig/diald in the filter sequence so that folks are not
confused.  It is maddening enough without needing to jump around
various files covering the same ground but in different order.  It is
nice to think about a GUI tool, but do not make it unnecessarily
difficult for those that may need or prefer to do things the old
fashioned way.  Not every box running diald should have X.

I hope these comments are helpful and again thanks for a good package.

			jam
==========================================================
X-Sender: kop-mail@meme.com
Mime-Version: 1.0
Date: Mon, 21 Apr 1997 01:02:06 -0600
To: "John A. Martin" <jam@jamux.com>
From: "Karl O. Pinc" <kop@meme.com>
Subject: Re: diald-config
Bcc:
Status: RO

Once again, I'm responding without looking at the package.

>The word for today is "Standard is better than better".
>
>>>>>> On Thu, 17 Apr 1997 17:46:10 -0500, "Karl O. Pinc" <kop@meme.com> said:
>
>    >> Consider 
>    >> # 
>    >> # These timeouts should correspond to the timeouts in the 
>    >> # respective applications.plus a little slack if experience dictates.  
>    >> # FETCHMAIL_TIMEOUT=240 
>    >> # SENDMAIL_TIMEOUT=240
>
>The version of fetchmail that I have at hand has a default timeout of
>5 minutes.  Currently sendmail has 13 pertinent adjustable timeouts.
>The distributed defaults range from 0 to 1 hour.  The the largest of
>the minimums allowed by RFC 1123 section 5.3.2 is 10 minutes.  Allman
>has good reasons for the 1 hour timeouts but, like I said, folks
>without a full time connection probably ought to avoid those
>situations perhaps by sending all outgoing mail to a reasonable
>"smarthost".  If you do the mail timeout thing at all you might want
>to offer
>
># FETCHMAIL_TIMEOUT=300
># SENDMAIL_TIMEOUT=600
>
>which have at least some rhyme and reason.  You do of course want the
>default filtering to do your "QUICK_DROP", right?

Yes.  

I'll take your numbers as reasonable.  What I was thinking of when doing the mail timeout thing was of, what seems to me the typical case, standalone single user dialin-to-the-net machines.
>
>    >> Actually I found myself thinking on what you _meant_ rather
>    >> than what you said on first reading of the commentary in
>    >> /etc/sysconfig/diald.
>
>    Karl> Um, which?  Does something need rewriting?
>
>The commentary with MAIL_TIMEOUT in /etc/sysconfig/diald.

I'll take a look.

>
>    Karl> Got a point there.  Does SENDMAIL_TIMEOUT=0 make sense if
>    Karl> you want smtp to be ignored so that the link dosen't come
>    Karl> up?  As opposed to SENDMAIL_TIMEOUT= (or just not defining
>    Karl> it) for having the smtp have the default timeouts?
>
>I would either leave the mail timeouts alone or do as above.  Beyond
>assuring that the connection does not go away before the application
>timeouts expire, which can cause real havoc with sendmail if not
>fetchmail, it is probably best to leave applications problems to the
>applications and not to use diald's filtering rules to address
>problems that have to do with managing applications.  Sendmail in
>particular has ample options available to let it be run exactly how
>and when the user (administrator) wants it to be run.  If the
>alternatives to sendmail fail in that respect then they are broken.

I'll separate the get/send mail timeouts into two parameters with recommened defaults per above.  Given my druthers, I'd avoid application specific names for the parameters, but I like FETCH/SEND too much.

If I was going to try to configure a dial-in business network, I'd probably want sendmail to reprocess the queue at regular intervals, smarthost or no, just to ensure delivery.  But I probably wouldn't want sendmail's queue processing to keep the link up.  I figured a diald "ignore smtp" option might give somebody a start at trying to come up with a configuration that would approximate this behavior.
>
>    Karl> This is sort of off topic, but I try to get my apps to use
>    Karl> localhost.  By putting a fully qualified alias in /etc/hosts
>    Karl> for localhost, so that the domain is the same as that
>    Karl> returned by "hostname", emacs, sendmail and whatnot will all
>    Karl> use localhost.  This has to be more efficent anyhow.
>
>I dunno what advantages that might have but efficiency would be one of
>them only if something is broken.  The kernel and the device drivers
>are smart enough to route self addressed stuff the same way no mater
>what the form of the address might be.  On a properly conventionally
>configured box that is up and running there should be no discernible
>difference in ping time or whatever between localhost, nickname, or
>FQDN addressing one of its own interfaces.

Ok, so the kernel's smarter than me.  :-)  Efficency was not really my concern anyhow. There are dns timout issues on machines that use the ISP's dns but are not connected to the net.  It's particularly annyoing to have to wait for emacs to start up, it initiates some sort of dns activity.  And it would be annoying/expensive to force a net connection whenever starting emacs or at boot when sendmail starts.
>
>    >>  Yes, sounds good.  Also give a script that tries alternate
>    >> numbers when getting busy signals.  Another thing to make easy
>    >> is to switch from one destination to another with only a single
>    >> line.  I see folks do the latter fairly often but not too
>    >> gracefully I think.  (I live much more simply.)
>
>    Karl> Good ideas.  The trouble with these suggestions is that I'm
>    Karl> trying to have the diald integrate with redhat's ppp
>    Karl> configuration, which, AFIK, only allows one
>    Karl> number/destination per interface.  The advantage of
>    Karl> integration is, the user has only to configure once and can
>    Karl> then use diald or manual ppp, and, once ppp is fixed up with
>    Karl> these options, diald will have them too.  So, the redhat
>    Karl> dialing config needs support for dialing destinations as
>    Karl> separate database entities.  I'm not really up for it, I'm
>    Karl> just looking to make stable what I've already done.
>
>Do you have any word on the promise that the next pppd will do the
>diald tricks itself?

None.  I saw that and was sort of hoping they'd give up on it.  Emacs notwithstanding, I'm opposed to the monolithic software approach.

>
>One way to get alternate destinations for the present might be to have
>several devices ppp0, ppp1, ... pointing to a single port, like
>/dev/modem, but with different telephone numbers and chat scripts.
>Alternate numbers for the same destination with busy signals should
>only be a somewhat fancier script.  I dunno,

It could certainally be done.  Beyond my ambitions for now.
>
>    Karl> Maybe we should have been discussing this on
>    Karl> redhat-devel-list.
>
>I had no idea of getting so deep into this.

You?  Hell, when I started the diald-config I was just going to slap something together for my brother and post the results to the net.  :^)
>
>BTW your stuff continued working for me after a reboot.  I'm writing
>off my initial problems getting diald to start ppp to a kink of some
>kind in what I did trying not to break my old stuff while integrating
>the new.

Good.

>
>Now for some gratuitous remarks.
>
>In keeping with "standard is better than better" it seems like it
>might be a good idea to let the diald-configure'ed diald work out of
>the box just like Schenk's would, at least in principle.

Well....  You're right.  Trouble for me was, standard didn't work any of the times I wanted to use it.  (Office network running dns & standalone single user dialin.)  Still, it's a goal.

Sounds good to me.  That's why I left the mail stuff commented out of the config file.
>
>Eric's defaults have been unchanged for like three years since he was
>in Toronto and reflect a lot of experience and good thinking.  Any
>changes should IMHO be very carefully thought out.  Updates to keep
>pace with the now much better /etc/services files in circulation and
>the widespread use of fetchmail and sendmail on lonely boxes at the
>end of the line are good however.

I take it Eric Shenk is the diald man? (My Linix box is off just now.)  I recall working straight from the diald standard filter and I'm pretty sure that my out-of-the-box defaults act on the same services/flags. (After reading your diff, obviously not.)  I'm sure I changed a couple of the timeout values though.   The standard config seems to be designed for a local network/office dialing in whereas I had in mind a single user (me) at the end of the wire.  (Who pays 5 cents for the phone call and nothing thereafter, as opposed to a business which pays by the minute regardless.)  The single user config is based on my usage patterns.  Do you have a feel for how the majority of diald users are using it?  Maybe the answer is to have alternate suggested values for each type of use (business-network/personal) written into the sample config.  Whaddayathink?

>
>Before chucking redundant stuff, I did an Ediff (emacs) between
>/usr/lib/diald/standard.filter and my present /tmp/diald.filter.  They
>are close enough that it might be worth just a little work to make
>sure there are no gratuitous differences at all.  Anyway, below is a

Good idea.

>list of what that comparison brought to mind.  Since I've hacked on
>your stuff and was not planning on this exercise I may see differences
>that are not in your distribution and more likely missed some that
>are.
>
>1. Let Eric's `accept tcp 15 tcp.syn' stand at the top unless you know
>of a good reason not to.  Would that interfere with the lcp stuff you
>include?  How would a user know which he needed?  Perhaps both can
>live side by side as the default.


The tcp.syn stuff is complely redundant in the presence of ppp lcp.  It's only possible effect would be to cause problems if the value is not large enough.  It's purpose is to detect when the link fails to come up, a speical case of a purpose of the lcp which is to detect when the link is up.  However, because tcp.syn is a network layer event driven process attempting to detect link layer failure, it's less relyable.  The only use for tcp.syn is when lcp stuff is not working.  I don't know how mandatory the lcp "pings" are in the ppp protocol, but I'd bet money they are mandatory.  So, at a guess, so long as ppp is used for the protocol tcp.syn should not be used.

>
>2. (Very important) keep as the default
>
>	keepup tcp 5 !tcp.live
>	ignore tcp !tcp.live

Ok.  I'm not sure what I was thinking.  Probably I didn't want to trouble a config arg for it and wanted everything configurable so as to make /etc/diald/diald.config work.  I'll make a arg.
>
>3. keep the domain stuff in the default.

I had some good reason for taking it out.  I'll have to look into it.
>
>4. www --> http : good, 120 --> 1800 : bad <-- (put it back as default).
(personal useage pattern again, see above)
>
>5. Uncommenting ftp-data : good, 120 --> 1800 : bad <--.

I recall, at some point, having problems because ftp-data was not in /etc/services.  I'm not sure it's in the assigned numbers at all, which sounds stupid...
>
>6. Do _not_ lump ftp with www!  Use two parameters.

I s'pose.  It's looking like the m4 stuff should be used to make it easier to configure without losing any detail.  You've convinced me.
>
>7. udp.domain 30 --> 50 : bad <--

Do you have a good reason for this?  It was consitantly taking me 40 to 45 seconds to bring the network up on a dial-in connection.  I was suprised, but what with lots of new area codes (Chicago),  constantly changing modem protocols, loaded ISPs, etc, etc, 50 dosen't sound unreasonable.  Correct me if I'm wrong, but if the app is waiting for dns, and the dns times out and brings the link down before the dns reply can arrive, the net will never come up.  (I didn't take a look at the queue to see if the resolver was persistantly sending more dns packets when it found the first one was taking a long time.  It didn't seem like something to rely on.)  Standard's aside, it's gotta work.
>
>8. Put the SCO and netbios filters back in the default set.

Poo.  I'll have to think on how to be sure standard is there for people when they need it.  Double poo.
>
>Because the sequence of filter rules is significant, consider putting
>/etc/sysconfig/diald in the filter sequence so that folks are not
>confused.  It is maddening enough without needing to jump around
>various files covering the same ground but in different order.  It is
>nice to think about a GUI tool, but do not make it unnecessarily
>difficult for those that may need or prefer to do things the old
>fashioned way.  Not every box running diald should have X.

I agree, it should be hand configurable.  (I've no idea how the GUI stuff deals with comments in the config files, certainly the default redhat config's arn't commented.)  I'm not sure what you mean by "putting /etc/sysconfig/diald in the filter sequence".  I don't think diald would like shell script variable assignments in its config file, and it dosen't sound like good design to have a file that mutates it's data type so that sometimes it's a shell script and sometimes a diald config file.  If you want to do things the old fashioned way, standard diald filter stuff can be put into /etc/diald/diald.config, and all the stuff in /etc/sysconfig/diald (except the grand ultimate default timeout) can be commented out.  I suppose that I should allow the ultimate default to be commented out also.
>
>I hope these comments are helpful and again thanks for a good package.

Very helpful.  Thanks for the comments, and you're welcome.  I was hoping to put out a new release this weekend, but I guess not.

Ok, my present plan is this:  comment at the top of the readme to explain how to use /etc/diald/diald.config to get a totally standard/out-of-the-box diald config.  Note that the business-localnetwork config settings noted in the config result in an "almost standard" diald config (would be missing SCO and netbios).  Have the "default" config be a "single user" config, because I believe that most people dialing in to the net are using their machines for personal use.

Out of curiousity, are you associated with the diald effort or are you an innocent bystander?

Karl                    e-mail: kop@meme.com,  karl@meme.net, kop@acm.org
----               
Karl O. Pinc           e-tattoo: Ride hard and die free.
===================================================
To: "Karl O. Pinc" <kop@meme.com>
Subject: Re: diald-config 
Date: Mon, 21 Apr 1997 14:23:52 -0400
From: "John A. Martin" <jam@jamux.com>
Status: RO

I am continuing on the risky assumption that you are not annoyed by
someone having a lot to say who is not in a position to do anything
except talk (NATO == No Action, Talk Only).

Some (annotated) design assumptions.

	1.  Using diald implies a desire to let the modem line give an
	    illusion of a "real" network connection without driving
	    one into the poor house (were connect time no object pppd
	    with keepalive/respawn would be used).

	2.  The filtering rules are primarily intended to facilitate
	    background operations.  Force and unforce by signals or
	    the control pipe perhaps by using dctrl are there to let
	    folks do interactive net stuff on a single user box
	    without having the connection go away while they are
	    "thinking".  (A friend who has several of his neighbor
	    households on his private network with a diald connection
	    uses cron to manage force/unforce during certain time
	    periods on a flat rate phone line to an "unlimited use"
	    provider.  I dunno why he doesn't use diald's "restrict"
	    instead.)

	3.  The default objective is to minimize total connect time
	    while having reasonable service.  The diald "impulse"
	    features should accommodate most other objectives.
	    (Around here, and I thought throughout North America, flat
	    rate residential service is the norm, pay by the minute
	    commercial service, with connect time being an issue at
	    the ISP.  Here most ISPs offer "unlimited" connect time
	    (cheap) and "dedicated" connection (_very_ expensive).
	    Since "unlimited" is poorly defined, those who choose not
	    to fight their ISP generally, I think, try to economize on
	    their connect time especially if busy signals are
	    uncommon, as has been normal around here for as long as
	    recent memory extends.  (It is common practice here for
	    "unlimited" ISPs to take down idle connections or
	    persistent connections ("we thought you had a stuck
	    process") but not to tell what their parameters are
	    ("perhaps you need a dedicated connection").))

	4.  A diald connected Red Hat Linux box will run sendmail,
	    fetchmail, either a "caching only" or some hacked up DNS
	    configuration (named), and probably xntpd.  (Somehow,
	    non-network experienced Linux users were slow to learn the
	    benefits of a caching-only DNS for a dial up box.  Now I
	    think there is a (mini)HOWTO and even a rpm for help with
	    caching only DNS.  The considerations for configuring DNS
	    for RFC 1918 private networks seem to be similar with and
	    without diald.  (For private networks behind diald I have
	    only the limited experience of my own home setup where I
	    run 0-2 private networks depending on the projects
	    underway but I am a fair hand at
	    private-intra/inter-networking in the "real world".))

At a recent dc-linux meeting the guy who described his neighborhood
private network (an early linux kernel hacker and experienced network
administrator from way before linux was thought of) asked an audience
of about 100 for a show of hands on several questions:

	1.  How many have some sort of network at home?  All but a
	    handful.

	2.  How many do something other than tcp/ip at home.  Only two
	    or three.

	3.  How many use ppp?  All (a small number of ppp-ISDN).  How
	    many use slip?  None.

	4.  How many use diald?  Three, including the speaker.

I'm an independent consultant doing a fair amount of my work by
accessing client sites from home.  For those sessions I do diald
"force", otherwise I try to be nice to my provider.  Until just now I
ran diald with the default filter rules adjusted for a proper
/etc/services and used one line scripts writing to the control pipe
implementing "diald-do-force", "diald-do-unforce", and the like
(before that I just did signals).  I ran an ancient version of a pop3
client by hand, sendmail to the net (not just to a smarthost), a
caching only DNS, xntpd, and a number of networking jobs that run
automatically in the background whether the machine is attended or
not.  The biggest operational problem for me with that set up was the
manual pop mail which would soak up bandwidth for long enough that
there was frequently tension between getting mail and doing other
work.  I had not automated the pop client because it was too fragile to
be trusted without attention, though in fact there had not been any
actual problem for many months (hmm..., now that I think about it I
realize that the problems had to have been on the server side, I did
nothing yet they went away.).  The whole setup was unmaintainable
because when I first did Red Hat my stuff diald/ppp/popmail were all
newer (more "bleeding edge") than Red Hat, and so I installed "around"
them so to speak and of course they each became obsolete long ago.

Now, for a few days I use your stuff buggered to give the old filter
defaults plus your ppp lcp and the values I suggested.  Otherwise I do
the same as above except with the latest version of fetchmail
configured to run as root's daemon polling every 12 min if and only if
the connection is up.  This with the diald "restrict" forcing the
connection up for 15 minutes 4 times a day and cron "awakening" the
fetchmail daemon two minutes after the diald "force".  This seems to
be working quite well for me.

So much for where I'm coming from.

>>>>> On Mon, 21 Apr 1997 01:02:06 -0600 you said:

    Karl> I'll take your numbers as reasonable.  What I was thinking
    Karl> of when doing the mail timeout thing was of, what seems to
    Karl> me the typical case, standalone single user
    Karl> dialin-to-the-net machines.

Me too.  Like I do.  If the sendmail timeout doesn't work, consider
mailing to a smarthost or some other relay.  One cannot probably
afford to wait for some distant sendmail to resolve a large list
managed solely by sendmail's /etc/aliases which is one of the
pathologies that can cause long delays.

    Karl> I'll separate the get/send mail timeouts into two parameters
    Karl> with recommened defaults per above.  Given my druthers, I'd
    Karl> avoid application specific names for the parameters, but I
    Karl> like FETCH/SEND too much.

In this context I would view these as generic terms.  Perhaps
SEND_MAIL_TIMEOUT and FETCH_MAIL_TIMEOUT would do better?

    Karl> If I was going to try to configure a dial-in business
    Karl> network, I'd probably want sendmail to reprocess the queue
    Karl> at regular intervals, smarthost or no, just to ensure
    Karl> delivery.  But I probably wouldn't want sendmail's queue
    Karl> processing to keep the link up.  I figured a diald "ignore
    Karl> smtp" option might give somebody a start at trying to come
    Karl> up with a configuration that would approximate this
    Karl> behavior.

My sendmail does _not_ keep the connection up between queue runs.  Are
you using your QUICK_DROP?

    Karl> Ok, so the kernel's smarter than me.  :-) Efficency was not
    Karl> really my concern anyhow. There are dns timout issues on
    Karl> machines that use the ISP's dns but are not connected to the
    Karl> net.  It's particularly annyoing to have to wait for emacs
    Karl> to start up, it initiates some sort of dns activity.  And it
    Karl> would be annoying/expensive to force a net connection
    Karl> whenever starting emacs or at boot when sendmail starts.

I dunno why starting emacs should initiate DNS activity.  I run emacs
(mostly XEmacs the last 2-3 years) lots of places some of which where
such DNS activity would be _very_ noticeable, but I don't see it.
Perhaps something else is amiss.  On boxes with private and public
networks where one or the other may be absent either permanently or
temporarily I use just two lines in /etc/hosts:

	127.0.0.1	localhost
	<public IP number or 0.0.0.0> <FQDN> <nickname>

They all run either caching only nameservers or something configured
in such a way that all info needed at startup (at least) is either in
zone files or in zone backup files.  In that environment going to
either a private or public network at boot time is unacceptable.
Works like a charm.  Easy to maintain without reference to local
issues.  Cooked /etc/hosts are evil IMHO.

Use tcpdump to figure what is really going on.  I don't think the
solution should lie in diald filter rules.

Everyone with a slow connection should do at least a caching only DNS,
but that has nothing to do with your emacs problem.

When I said my setup with your stuff was OK on reboot, that meant,
among other things of course, no gratuitous dialup.  Not for named,
sendmail, or anything else.

Actually there have been times when I did force a dialup at boot as an
"all is well" indicator.  But I very seldom reboot except to install a
new kernel.

    >> Do you have any word on the promise that the next pppd will do
    >> the diald tricks itself?

    Karl> None.  I saw that and was sort of hoping they'd give up on
    Karl> it.  Emacs notwithstanding, I'm opposed to the monolithic
    Karl> software approach.

Me too.  Vehemently.  However it seems vastly simpler to let pppd do
it presumably without the need for the slip hack.

If you really oppose monoliths you must be using only mh-e, right?

    >> Now for some gratuitous remarks.
    >>
    >> In keeping with "standard is better than better" it seems like
    >> it might be a good idea to let the diald-configure'ed diald
    >> work out of the box just like Schenk's would, at least in
    >> principle.

    Karl> Well....  You're right.  Trouble for me was, standard didn't
    Karl> work any of the times I wanted to use it.  (Office network
    Karl> running dns & standalone single user dialin.)  Still, it's a
    Karl> goal.

It should.  It has for me been a non-issue for like 3 years except
that I did not have it done with Red Hat packages.

    Karl> I take it Eric Shenk is the diald man?

Yup.  Erick Schenk, that is.  He was at Toronto when he did most of
the work and was in close touch with Al Longyear who did the linux
port of pppd and much other Linux networking and other stuff.

    Karl> The standard config seems to be designed for a local
    Karl> network/office dialing in whereas I had in mind a single
    Karl> user (me) at the end of the wire.

My sense of it is that the standard config is designed for either.
The SCO and netbios stuff is probably for the office, as you call it,
but that does not conflict with the single user's needs.
 
    Karl> (Who pays 5 cents for the phone call and nothing thereafter,
    Karl> as opposed to a business which pays by the minute
    Karl> regardless.)

You might want to look at diald's "impulse" features.

    Karl> Do you have a feel for how the majority of diald users are
    Karl> using it?

Only what is at the very top of this missive.

    Karl> Maybe the answer is to have alternate suggested values for
    Karl> each type of use (business-network/personal) written into
    Karl> the sample config.  Whaddayathink?

The important distinction is not, I believe, between home and office,
but between "impulse" and flat rate.

    >> 1. Let Eric's `accept tcp 15 tcp.syn' stand at the top unless
    >> you know of a good reason not to.  Would that interfere with
    >> the lcp stuff you include?  How would a user know which he
    >> needed?  Perhaps both can live side by side as the default.

    Karl> The tcp.syn stuff is complely redundant in the presence of
    Karl> ppp lcp.  It's only possible effect would be to cause
    Karl> problems if the value is not large enough.  It's purpose is
    Karl> to detect when the link fails to come up, a speical case of
    Karl> a purpose of the lcp which is to detect when the link is up.
    Karl> However, because tcp.syn is a network layer event driven
    Karl> process attempting to detect link layer failure, it's less
    Karl> relyable.  The only use for tcp.syn is when lcp stuff is not
    Karl> working.  I don't know how mandatory the lcp "pings" are in
    Karl> the ppp protocol, but I'd bet money they are mandatory.  So,
    Karl> at a guess, so long as ppp is used for the protocol tcp.syn
    Karl> should not be used.

I suspect you are right on the money (say I not having taken the
trouble to check the specs), but I suspect further that the tcp.syn
stuff is there for broken pppd guys at the other end.  Do you know for
a fact that pppd does not do something reasonable with ppp.lcp without
being told?  FWIW doing both by the respective defaults seems to work
fine for me.  That is not to say it is a god idea.  The main issue is,
methinks, how does the user know if he needs the tcp.syn stuff?

    >> 4. www --> http : good, 120 --> 1800 : bad <-- (put it back as
    >>    default).

    Karl> (personal useage pattern again, see above)

Use force for interactive use, if that is where your pattern comes
from.  1800 is way too long for a background job to wait, methinks.

    >> 5. Uncommenting ftp-data : good, 120 --> 1800 : bad <--.

    Karl> I recall, at some point, having problems because ftp-data
    Karl> was not in /etc/services.  I'm not sure it's in the assigned
    Karl> numbers at all, which sounds stupid...

It is in recent /etc/services in the Linux and Red Hat communities.

    >> 7. udp.domain 30 --> 50 : bad <--

    Karl> Do you have a good reason for this?  It was consitantly
    Karl> taking me 40 to 45 seconds to bring the network up on a
    Karl> dial-in connection.  I was suprised, but what with lots of
    Karl> new area codes (Chicago), constantly changing modem
    Karl> protocols, loaded ISPs, etc, etc, 50 dosen't sound
    Karl> unreasonable.  Correct me if I'm wrong, but if the app is
    Karl> waiting for dns, and the dns times out and brings the link
    Karl> down before the dns reply can arrive, the net will never
    Karl> come up.  (I didn't take a look at the queue to see if the
    Karl> resolver was persistantly sending more dns packets when it
    Karl> found the first one was taking a long time.  It didn't seem
    Karl> like something to rely on.)  Standard's aside, it's gotta
    Karl> work.

It takes almost exactly 50 seconds for me to make a dialup connection
and the Schenk default of 30 works fine for me.  Again, the difference
between the way I run my home box and one on a typical Ethernet is
that at home I do a caching only DNS where on an ordinary workstation
on a reasonable Ethernet I would not.

It is fairly typical of applications to give up on DNS in 5 seconds.

    >> Because the sequence of filter rules is significant, consider
    >> putting /etc/sysconfig/diald in the filter sequence so that
    >> folks are not confused.  It is maddening enough without needing
    >> to jump around various files covering the same ground but in
    >> different order.  It is nice to think about a GUI tool, but do
    >> not make it unnecessarily difficult for those that may need or
    >> prefer to do things the old fashioned way.  Not every box
    >> running diald should have X.

    Karl> I agree, it should be hand configurable.  (I've no idea how
    Karl> the GUI stuff deals with comments in the config files,
    Karl> certainly the default redhat config's arn't commented.)  I'm
    Karl> not sure what you mean by "putting /etc/sysconfig/diald in
    Karl> the filter sequence".

I mean put stuff in /etc/sysconfig/diald in the sequence the related
stuff appears in the filter table, not in the order you think they may
be first recognized by a naive user.  There is a rhyme and reason to
the order in the filter sequence, to say nothing of the convenience
of having something reasonable with /etc/sysconfig/diald and
/tmp/diald.filter in side by side windows.  Cater to the naive user
with clear comments, not by reordering something that has an inherent
sequence.

    Karl> Ok, my present plan is this: comment at the top of the
    Karl> readme to explain how to use /etc/diald/diald.config to get
    Karl> a totally standard/out-of-the-box diald config.  Note that
    Karl> the business-localnetwork config settings noted in the
    Karl> config result in an "almost standard" diald config (would be
    Karl> missing SCO and netbios).  Have the "default" config be a
    Karl> "single user" config, because I believe that most people
    Karl> dialing in to the net are using their machines for personal
    Karl> use.

Like, I said, I think the useful distinction is between flat rate and
impulse, not between personal and business use.

    Karl> Out of curiousity, are you associated with the diald effort
    Karl> or are you an innocent bystander?

Innocent bystander.

Another note perhaps relevant to who to design for and what is the
default.  The folks at Red Hat have put their arms around pppd but not
diald.  See also the show of hands mentioned above.  I think diald is
not for the masses because it is ignored by those who set the pace and
not used by many of the knowledgeable types because it is viewed as
just a huge hack on a problem that should be solve otherwise, like in
pppd.

You may of course get a different impression reading the diald list,
which I have not done for a very long time.  In many ways your
impressions are probably more reliable than mine.

			jam
=========================================================
X-Sender: kop-mail@meme.com
Mime-Version: 1.0
Date: Tue, 6 May 1997 12:12:04 -0600
To: "John A. Martin" <jam@jamux.com>
From: "Karl O. Pinc" <kop@meme.com>
Subject: Re: diald-config
Bcc:

>I am continuing on the risky assumption that you are not annoyed by
>someone having a lot to say who is not in a position to do anything
>except talk (NATO == No Action, Talk Only).

So long as you're not annoyed at a developer who spends time reading e-mail
messages and not developing.

I appreciate having someone to tell me of stupids and to bounce things off of.  I won't thank you for commenting any more if you won't apoligise for same.

I should be able to get back to it "real soon now."

I've been writing pieces of this response as time has become available.  I _think_ I'll be sitting down today and working on the package itself.  Hopefully knock it out.

>
>Some (annotated) design assumptions.
>
>	1.  Using diald implies a desire to let the modem line give an
>	    illusion of a "real" network connection without driving
>	    one into the poor house (were connect time no object pppd
>	    with keepalive/respawn would be used).

Check.

>
>	2.  The filtering rules are primarily intended to facilitate
>	    background operations.  Force and unforce by signals or
>	    the control pipe perhaps by using dctrl are there to let
>	    folks do interactive net stuff on a single user box
>	    without having the connection go away while they are
>	    "thinking".  (A friend who has several of his neighbor
>	    households on his private network with a diald connection
>	    uses cron to manage force/unforce during certain time
>	    periods on a flat rate phone line to an "unlimited use"
>	    provider.  I dunno why he doesn't use diald's "restrict"
>	    instead.)

I disagree, this violates the "transparency" of criteria 1.  I'm much more interested in having the entire network operate in the background, as it were.

At least in the case of the US domestic phone service
customer.  It costs only the loss of use of the phone line to leave the
phone line connected to the net.  This is (IMHO) lower than the cost of
having to interrupt one's thinking to force or unforce the link.

>
>	3.  The default objective is to minimize total connect time
>	    while having reasonable service.  The diald "impulse"
>	    features should accommodate most other objectives.
>	    (Around here, and I thought throughout North America, flat
>	    rate residential service is the norm, pay by the minute
>	    commercial service, with connect time being an issue at
>	    the ISP.  Here most ISPs offer "unlimited" connect time
>	    (cheap) and "dedicated" connection (_very_ expensive).
>	    Since "unlimited" is poorly defined, those who choose not
>	    to fight their ISP generally, I think, try to economize on
>	    their connect time especially if busy signals are
>	    uncommon, as has been normal around here for as long as
>	    recent memory extends.  (It is common practice here for
>	    "unlimited" ISPs to take down idle connections or
>	    persistent connections ("we thought you had a stuck
>	    process") but not to tell what their parameters are
>	    ("perhaps you need a dedicated connection").))

I would agree that econonomizing on connect time is important, but more important is econonomizing on dollars.  

The issue is what constitutes econonimizing on connect time.  My
feeling is that as long as I'm sitting in front of the computer and paying
attention to it, "reasonable" use would allow me to be connected to the
net.  As, at any time while so engaged, I might wish to do something net
related and would not like to suffer the cost/delay of connecting.  (I've
been corresponding with a lawyer a lot lately. :-)  And this dosen't seem
to be "fighting" the ISP as the total amount of time spent in front of the
computer is always a low compared to the total elapsed time.  And the
ultimate in unecononmical behavior is to just auto connect on boot.  In some ways, this is the behavior you advocate, in that you force the connection when you sit down and unforce it when you leave.  However, I don't want to have to do that.  I want to be able to sit down and use the computer instantly, or  walk away from it for a moment that turns into hours.  And there are many times I sit in front of it for hours without using the net.  Why should I have to think about whether I'm going to be using the net or not?  The net should be transparent.

Yes, ISPs take down people's connections.  The simplest way among many to
avoid this is to have you're e-mail program pop on a regular basis.  This
was the motivation behind my addtion of e-mail protocols to the diald
config.  Usually, when I shut down the e-mail system, I'm pretty much ready
to leave the computer.  Thus, e-mail (now read pop) timeouts should be long
enough to ensure the link dosen't go down between pop checks, but not much
longer.

>
>	4.  A diald connected Red Hat Linux box will run sendmail,
>	    fetchmail, either a "caching only" or some hacked up DNS
>	    configuration (named), and probably xntpd.  (Somehow,
>	    non-network experienced Linux users were slow to learn the
>	    benefits of a caching-only DNS for a dial up box.  Now I
>	    think there is a (mini)HOWTO and even a rpm for help with
>	    caching only DNS.  The considerations for configuring DNS
>	    for RFC 1918 private networks seem to be similar with and
>	    without diald.  (For private networks behind diald I have
>	    only the limited experience of my own home setup where I
>	    run 0-2 private networks depending on the projects
>	    underway but I am a fair hand at
>	    private-intra/inter-networking in the "real world".))

FWIW: I'd bet most still don't run a caching dns, just because it's another
thing to configure.  (On the other hand, maybe another thing to configure
will motivate people to run it.)  I got lazy and didn't put one on my
brother's machine.

For that matter, what's the advantage of running xntpd?  You'd do pull on
the newsgroups you read and have a local cache?  Does this require ISP
cooperation?  I pretty much don't read the newsgroups.  The volume daunt's
me in the one's I'm interested in.

>
>At a recent dc-linux meeting the guy who described his neighborhood
>private network (an early linux kernel hacker and experienced network
>administrator from way before linux was thought of) asked an audience
>of about 100 for a show of hands on several questions:
>
>	1.  How many have some sort of network at home?  All but a
>	    handful.
>
>	2.  How many do something other than tcp/ip at home.  Only two
>	    or three.
>
>	3.  How many use ppp?  All (a small number of ppp-ISDN).  How
>	    many use slip?  None.
>
>	4.  How many use diald?  Three, including the speaker.

As a guess, people don't use diald because it's not essential.  If it was
convenient to install, they'd use it.  It's just convenient to _use_.

>
>I'm an independent consultant doing a fair amount of my work by
>accessing client sites from home.  For those sessions I do diald
>"force", otherwise I try to be nice to my provider.  Until just now I
>ran diald with the default filter rules adjusted for a proper
>/etc/services and used one line scripts writing to the control pipe
>implementing "diald-do-force", "diald-do-unforce", and the like
>(before that I just did signals).  I ran an ancient version of a pop3
>client by hand, sendmail to the net (not just to a smarthost), a
>caching only DNS, xntpd, and a number of networking jobs that run
>automatically in the background whether the machine is attended or
>not.  The biggest operational problem for me with that set up was the
>manual pop mail which would soak up bandwidth for long enough that
>there was frequently tension between getting mail and doing other
>work.  I had not automated the pop client because it was too fragile to
>be trusted without attention, though in fact there had not been any
>actual problem for many months (hmm..., now that I think about it I
>realize that the problems had to have been on the server side, I did
>nothing yet they went away.).  The whole setup was unmaintainable
>because when I first did Red Hat my stuff diald/ppp/popmail were all
>newer (more "bleeding edge") than Red Hat, and so I installed "around"
>them so to speak and of course they each became obsolete long ago.

I've installed xfmail but haven't started using it much.
>
>Now, for a few days I use your stuff buggered to give the old filter
>defaults plus your ppp lcp and the values I suggested.  Otherwise I do
>the same as above except with the latest version of fetchmail
>configured to run as root's daemon polling every 12 min if and only if
>the connection is up.  This with the diald "restrict" forcing the
>connection up for 15 minutes 4 times a day and cron "awakening" the
>fetchmail daemon two minutes after the diald "force".  This seems to
>be working quite well for me.

Sounds like a good setup.

If this ever pulls together maybe you can write up something describing it.
>
>So much for where I'm coming from.

I too am an independent consultant.  I do database design, network consulting, lease web space on the net, and act as an all-round computer jock.  Most of my consulting is done on site, although some is done over the net.
>
>>>>>> On Mon, 21 Apr 1997 01:02:06 -0600 you said:
>
>    Karl> I'll take your numbers as reasonable.  What I was thinking
>    Karl> of when doing the mail timeout thing was of, what seems to
>    Karl> me the typical case, standalone single user
>    Karl> dialin-to-the-net machines.
>
>Me too.  Like I do.  If the sendmail timeout doesn't work, consider
>mailing to a smarthost or some other relay.  One cannot probably
>afford to wait for some distant sendmail to resolve a large list
>managed solely by sendmail's /etc/aliases which is one of the
>pathologies that can cause long delays.
>
>    Karl> I'll separate the get/send mail timeouts into two parameters
>    Karl> with recommened defaults per above.  Given my druthers, I'd
>    Karl> avoid application specific names for the parameters, but I
>    Karl> like FETCH/SEND too much.
>
>In this context I would view these as generic terms.  Perhaps
>SEND_MAIL_TIMEOUT and FETCH_MAIL_TIMEOUT would do better?

Let's pretend this is an improvement and I'll go with it.
>
>    Karl> If I was going to try to configure a dial-in business
>    Karl> network, I'd probably want sendmail to reprocess the queue
>    Karl> at regular intervals, smarthost or no, just to ensure
>    Karl> delivery.  But I probably wouldn't want sendmail's queue
>    Karl> processing to keep the link up.  I figured a diald "ignore
>    Karl> smtp" option might give somebody a start at trying to come
>    Karl> up with a configuration that would approximate this
>    Karl> behavior.
>
>My sendmail does _not_ keep the connection up between queue runs.  Are
>you using your QUICK_DROP?

I've not tried to configure such a setup.  It seems to me that popping the link up and down with the queue runs could be almost as expensive as keeping it up, hence the utility of an option to ignore smtp network traffic entirely.
>
>    Karl> Ok, so the kernel's smarter than me.  :-) Efficency was not
>    Karl> really my concern anyhow. There are dns timout issues on
>    Karl> machines that use the ISP's dns but are not connected to the
>    Karl> net.  It's particularly annyoing to have to wait for emacs
>    Karl> to start up, it initiates some sort of dns activity.  And it
>    Karl> would be annoying/expensive to force a net connection
>    Karl> whenever starting emacs or at boot when sendmail starts.
>
>I dunno why starting emacs should initiate DNS activity.  I run emacs
>(mostly XEmacs the last 2-3 years) lots of places some of which where
>such DNS activity would be _very_ noticeable, but I don't see it.

The activity takes place when emacs starts.

>Perhaps something else is amiss.  On boxes with private and public
>networks where one or the other may be absent either permanently or
>temporarily I use just two lines in /etc/hosts:
>
>	127.0.0.1	localhost
>	<public IP number or 0.0.0.0> <FQDN> <nickname>

It is the FQDN on the second line that is being resolved at emacs/sendmail startup.
>
>They all run either caching only nameservers or something configured
>in such a way that all info needed at startup (at least) is either in
>zone files or in zone backup files.  In that environment going to
>either a private or public network at boot time is unacceptable.
>Works like a charm.  Easy to maintain without reference to local
>issues.  Cooked /etc/hosts are evil IMHO.

I simply put the (bogus) FQDN & nickname as localhost aliases on those machines receiving IP dynamically through ppp.  The way I look at it, the hostname is "cooked" because it hasn't been coordinated with the domain name owner, but you need something for a hostname.  What can you do?  It's a valid configuration in all other respects, far as I can tell.
>
>Use tcpdump to figure what is really going on.  I don't think the
>solution should lie in diald filter rules.
>
>Everyone with a slow connection should do at least a caching only DNS,
>but that has nothing to do with your emacs problem.
>
>When I said my setup with your stuff was OK on reboot, that meant,
>among other things of course, no gratuitous dialup.  Not for named,
>sendmail, or anything else.
>
>Actually there have been times when I did force a dialup at boot as an
>"all is well" indicator.  But I very seldom reboot except to install a
>new kernel.
>
>    >> Do you have any word on the promise that the next pppd will do
>    >> the diald tricks itself?
>
>    Karl> None.  I saw that and was sort of hoping they'd give up on
>    Karl> it.  Emacs notwithstanding, I'm opposed to the monolithic
>    Karl> software approach.
>
>Me too.  Vehemently.  However it seems vastly simpler to let pppd do
>it presumably without the need for the slip hack.

>From the user perspective, I wouldn't say vastly simpler.  You'd want pppd to do everything that diald now does.  The only impovement would be that there would be no possiblity of conflicting arguments, as in the  disallowed use of "lock" in both programs.  But there are only 3 or 4 of these conflicts, I'm not sure that offsets the cognative jumble you get when merging the programs.

The slip hack does have to go.
>
>If you really oppose monoliths you must be using only mh-e, right?

I used to use mh.  (What's mh-e?  mh with emacs?)  Then I just used emacs.  Then I switched to eudora on a mac.  Now I'm wandering back to unix with fxmail.

>
>    >> Now for some gratuitous remarks.
>    >>
>    >> In keeping with "standard is better than better" it seems like
>    >> it might be a good idea to let the diald-configure'ed diald
>    >> work out of the box just like Schenk's would, at least in
>    >> principle.
>
>    Karl> Well....  You're right.  Trouble for me was, standard didn't
>    Karl> work any of the times I wanted to use it.  (Office network
>    Karl> running dns & standalone single user dialin.)  Still, it's a
>    Karl> goal.
>
>It should.  It has for me been a non-issue for like 3 years except
>that I did not have it done with Red Hat packages.
>
>    Karl> I take it Eric Shenk is the diald man?
>
>Yup.  Erick Schenk, that is.  He was at Toronto when he did most of
>the work and was in close touch with Al Longyear who did the linux
>port of pppd and much other Linux networking and other stuff.
>
>    Karl> The standard config seems to be designed for a local
>    Karl> network/office dialing in whereas I had in mind a single
>    Karl> user (me) at the end of the wire.
>
>My sense of it is that the standard config is designed for either.
>The SCO and netbios stuff is probably for the office, as you call it,
>but that does not conflict with the single user's needs.
>
>    Karl> (Who pays 5 cents for the phone call and nothing thereafter,
>    Karl> as opposed to a business which pays by the minute
>    Karl> regardless.)
>
>You might want to look at diald's "impulse" features.
>
>    Karl> Do you have a feel for how the majority of diald users are
>    Karl> using it?
>
>Only what is at the very top of this missive.
>
>    Karl> Maybe the answer is to have alternate suggested values for
>    Karl> each type of use (business-network/personal) written into
>    Karl> the sample config.  Whaddayathink?
>
>The important distinction is not, I believe, between home and office,
>but between "impulse" and flat rate.

Yes.

>
>    >> 1. Let Eric's `accept tcp 15 tcp.syn' stand at the top unless
>    >> you know of a good reason not to.  Would that interfere with
>    >> the lcp stuff you include?  How would a user know which he
>    >> needed?  Perhaps both can live side by side as the default.
>
>    Karl> The tcp.syn stuff is complely redundant in the presence of
>    Karl> ppp lcp.  It's only possible effect would be to cause
>    Karl> problems if the value is not large enough.  It's purpose is
>    Karl> to detect when the link fails to come up, a speical case of
>    Karl> a purpose of the lcp which is to detect when the link is up.
>    Karl> However, because tcp.syn is a network layer event driven
>    Karl> process attempting to detect link layer failure, it's less
>    Karl> relyable.  The only use for tcp.syn is when lcp stuff is not
>    Karl> working.  I don't know how mandatory the lcp "pings" are in
>    Karl> the ppp protocol, but I'd bet money they are mandatory.  So,
>    Karl> at a guess, so long as ppp is used for the protocol tcp.syn
>    Karl> should not be used.
>
>I suspect you are right on the money (say I not having taken the
>trouble to check the specs), but I suspect further that the tcp.syn
>stuff is there for broken pppd guys at the other end.  

ppp must do lcp to initialize the link.  I suppose a broken ppp implementation _could_ refuse to do lcp thereafter, but it sounds really strange as lcp manages the "link" that the communication uses.

>Do you know for
>a fact that pppd does not do something reasonable with ppp.lcp without
>being told?
It does use lcp to initialize the link, and will continue to respond to lcp.  But it won't regularly check the status of the link without being told to do so.
>  FWIW doing both by the respective defaults seems to work
>fine for me.  That is not to say it is a god idea.  The main issue is,
>methinks, how does the user know if he needs the tcp.syn stuff?

I'd say emperically.  If the link stays up without lcp and data passes back and forth, but goes down when the lcp checks are enabled, then the other end is not properly responding to lcp.  In that case, turn off lcp and turn on tcp.syn.
>
>    >> 4. www --> http : good, 120 --> 1800 : bad <-- (put it back as
>    >>    default).
>
>    Karl> (personal useage pattern again, see above)
>
>Use force for interactive use, if that is where your pattern comes
>from.  1800 is way too long for a background job to wait, methinks.
>
>    >> 5. Uncommenting ftp-data : good, 120 --> 1800 : bad <--.
>
>    Karl> I recall, at some point, having problems because ftp-data
>    Karl> was not in /etc/services.  I'm not sure it's in the assigned
>    Karl> numbers at all, which sounds stupid...
>
>It is in recent /etc/services in the Linux and Red Hat communities.
>
>    >> 7. udp.domain 30 --> 50 : bad <--
>
>    Karl> Do you have a good reason for this?  It was consitantly
>    Karl> taking me 40 to 45 seconds to bring the network up on a
>    Karl> dial-in connection.  I was suprised, but what with lots of
>    Karl> new area codes (Chicago), constantly changing modem
>    Karl> protocols, loaded ISPs, etc, etc, 50 dosen't sound
>    Karl> unreasonable.  Correct me if I'm wrong, but if the app is
>    Karl> waiting for dns, and the dns times out and brings the link
>    Karl> down before the dns reply can arrive, the net will never
>    Karl> come up.  (I didn't take a look at the queue to see if the
>    Karl> resolver was persistantly sending more dns packets when it
>    Karl> found the first one was taking a long time.  It didn't seem
>    Karl> like something to rely on.)  Standard's aside, it's gotta
>    Karl> work.
>
>It takes almost exactly 50 seconds for me to make a dialup connection
>and the Schenk default of 30 works fine for me.  Again, the difference
>between the way I run my home box and one on a typical Ethernet is
>that at home I do a caching only DNS where on an ordinary workstation
>on a reasonable Ethernet I would not.

So, you must be getting multiple dns packets.  I'll try 30.
>
>It is fairly typical of applications to give up on DNS in 5 seconds.
>
>    >> Because the sequence of filter rules is significant, consider
>    >> putting /etc/sysconfig/diald in the filter sequence so that
>    >> folks are not confused.  It is maddening enough without needing
>    >> to jump around various files covering the same ground but in
>    >> different order.  It is nice to think about a GUI tool, but do
>    >> not make it unnecessarily difficult for those that may need or
>    >> prefer to do things the old fashioned way.  Not every box
>    >> running diald should have X.
>
>    Karl> I agree, it should be hand configurable.  (I've no idea how
>    Karl> the GUI stuff deals with comments in the config files,
>    Karl> certainly the default redhat config's arn't commented.)  I'm
>    Karl> not sure what you mean by "putting /etc/sysconfig/diald in
>    Karl> the filter sequence".
>
>I mean put stuff in /etc/sysconfig/diald in the sequence the related
>stuff appears in the filter table, not in the order you think they may
>be first recognized by a naive user.  There is a rhyme and reason to
>the order in the filter sequence, to say nothing of the convenience
>of having something reasonable with /etc/sysconfig/diald and
>/tmp/diald.filter in side by side windows.  Cater to the naive user
>with clear comments, not by reordering something that has an inherent
>sequence.

Ah, I see.  Well, I'll take a look at it.  I do agree with your last sentence.  But consider this as an argument.  All the protocol filters are mutually exclusive (offhand), and so are really order independent.  The whole point of the configuration is to abstract away from the filter rule details.  In this sense, allowing the underlying filter rules to show through the abstraction would be a design flaw.  First, the abstraction would gain less advantage -- it would be less clear.  Basically, it would be foolish not to take advantage of the order independence of the abstraction.  Second, a series of shell script variable assignments to different variables is inherently re-sequenceable -- to "force" an ordering violates the model of the abstraction.  If the person configuring the variable assignments must be aware of an ordering then the choice of a set of variable assignments as an abstraction is a bad one because it does not reflect the actual operation of the software.  (I don't think the notion of a default violates a "non-ordered" view of the operation as a default by definition operates on a set of packets who's members do not affect any other rule.  What's really critical is that the available options effect mutually exclusive sets of packets.)
>
>    Karl> Ok, my present plan is this: comment at the top of the
>    Karl> readme to explain how to use /etc/diald/diald.config to get
>    Karl> a totally standard/out-of-the-box diald config.  Note that
>    Karl> the business-localnetwork config settings noted in the
>    Karl> config result in an "almost standard" diald config (would be
>    Karl> missing SCO and netbios).  Have the "default" config be a
>    Karl> "single user" config, because I believe that most people
>    Karl> dialing in to the net are using their machines for personal
>    Karl> use.
>
>Like, I said, I think the useful distinction is between flat rate and
>impulse, not between personal and business use.

Yup.
>
>    Karl> Out of curiousity, are you associated with the diald effort
>    Karl> or are you an innocent bystander?
>
>Innocent bystander.
>
>Another note perhaps relevant to who to design for and what is the
>default.  The folks at Red Hat have put their arms around pppd but not
>diald.  See also the show of hands mentioned above.  I think diald is
>not for the masses because it is ignored by those who set the pace and
>not used by many of the knowledgeable types because it is viewed as
>just a huge hack on a problem that should be solve otherwise, like in
>pppd.

The operation of the guts, what makes it work, do seem a hack.  The  features on the other hand seem well thought out.
>
>You may of course get a different impression reading the diald list,
>which I have not done for a very long time.  In many ways your
>impressions are probably more reliable than mine.


Karl                    e-mail: kop@meme.com,  karl@meme.net, kop@acm.org
----               
Karl O. Pinc           e-tattoo: Ride hard and die free.

X-RDate: Fri, 27 Jun 1997 14:26:42 -0500 (CDT)
Return-Path: bgeer@xmission.xmission.com
Received: from xmission.xmission.com (xmission.xmission.com [198.60.22.2]) by
 arthur.meme.com (8.7.6/8.7.3) with ESMTP id XAA23956 for <kop@meme.com>;
 Tue, 27 May 1997 23:06:24 -0500
Received: (from bgeer@localhost) by xmission.xmission.com (8.8.5/8.7.5) id
 WAA02007 for kop@meme.com; Tue, 27 May 1997 22:00:16 -0600 (MDT)
Date: Tue, 27 May 1997 22:00:16 -0600 (MDT)
Message-Id: <199705280400.WAA02007@xmission.xmission.com>
X-UIDL: c21cf9566d9cb3df2bd6ad1850490dce
XFMstatus: 0000
From: bgeer <bgeer@xmission.com>
To: kop@meme.com
Subject: Re: I'd like to extend chat a bit.

Hi Karl,

 >Would it be possible and how would I go about getting my changes incorporated into the "official" release, whatever that is?

I sent my REPORT command code to Al Longyear - his email address is in
chat.c.

Cheers, Bob






----- bgeer@xmission.com -----
X-RDate: Mon, 30 Jun 1997 11:19:01 -0500 (CDT)
Return-Path: anttix@cyberix.edu.ee
Received: from jorh.edu.ee (jorh.edu.ee [193.40.56.251]) by arthur.meme.com
 (8.7.6/8.7.3) with ESMTP id XAA10542 for <kop@meme.com>;
 Fri, 27 Jun 1997 23:14:05 -0500
Received: from cyberix.edu.ee (uucp@localhost) by jorh.edu.ee (8.8.5/8.6.9)
 with UUCP id GAA08407 for meme.com!kop; Sat, 28 Jun 1997 06:48:51 +0300
Received: (from anttix@localhost) by cyberix.edu.ee (8.8.5/8.7.3) id GAA10440
 for kop@meme.com; Sat, 28 Jun 1997 06:06:11 +0300
Message-Id: <199706280306.GAA10440@cyberix.edu.ee>
Date: Sat, 28 Jun 1997 06:06:11 +0300 (EET DST)
Content-Type: text
X-UIDL: 409fab281d3a6afd0edf453c7218454a
XFMstatus: 0200
From: Antti Andreimann <anttix@cyberix.edu.ee>
To: meme.com!kop@cyberix.edu.ee
Subject: Diald config

Hi!
I have to say, that I really like this configuration system .
When it gets a control panel interface, it will be really cool.
I have found a little bug in this package also: 
in /usr/local/lib/diald/standard.filter.m4 at line 56 there is: 
	ifdef(`NAMESERVER',dnl 
but there should be: 
	ifdef(`NAMESERVER',`dnl
Also I think, that putting an RPM packaged files to /usr/local is not a
good idea at all. As far as I can see this violates The Linux FileSystem
Standard. /usr/lib and /usr/bin would be much better choices.
In readme file you wondered where diald pipes should go .
I think /var/run would be a good place, but maybe /dev/ is even better,
because initctl (witch is also a pipe) lives there. In any case you'll
not have to worry about filesystem writeablility when dealing with pipes.
As long as you will not need to create or delete one, every other operation
(read/write from/to pipe) will work fine on read only filesystem ;-)
There is another little problem with RIP: when a request comes to route port
and there is no routed running, an ICMP message will be generated and link
remains up. I don't know witch icmp messages should keep the link up, but
I assume, that only ICMP ECHO and ICMP ECHO-REPLY (ping) should be accepted.
Maybe some other ones also. Don't know much about ICMP ;-(
Anyway, keep up the good work ;-)

With best wishes:
-- 
========================================================================

            \||||||||||/                    Antti Andreimann
          \||||||||||||||/                  nickname: Cyber
       \|||||||||||||||||\                  anttix@cyberix.edu.ee
       /||||||||||||||||0\__@     ______    
       /|||||||||||||||||__/     (______)   Redistibution via Microsoft
        \||||||||||||||||/          {}      Network is prohibited.
(c)siil    L L       L L           _||_ 
========================================================================
X-RDate: Mon, 07 Jul 1997 11:42:17 -0500 (CDT)
Return-Path: frog.meme.com!kop@cyberix.edu.ee
Received: from jorh.edu.ee (jorh.edu.ee [193.40.56.251]) by arthur.meme.com
 (8.7.6/8.7.3) with ESMTP id HAA27930 for <kop@meme.com>;
 Tue, 1 Jul 1997 07:14:28 -0500
Received: from cyberix.edu.ee (uucp@localhost) by jorh.edu.ee (8.8.5/8.6.9)
 with UUCP id OAA28547 for meme.com!kop; Tue, 1 Jul 1997 14:18:44 +0300
Received: (from uucp@localhost) by cyberix.edu.ee (8.8.5/8.7.3) with UUCP id
 NAA02035; Tue, 1 Jul 1997 13:15:51 +0300
Received: from frog.meme.com (d86.loop.interaccess.com [206.183.68.86]) by
 jorh.edu.ee (8.8.5/8.6.9) with ESMTP id AAA17075;
 Tue, 1 Jul 1997 00:11:34 +0300
Received: (from kop@localhost) by frog.meme.com (8.7.6/8.7.3) id OAA01538;
 Mon, 30 Jun 1997 14:48:22 -0500
Message-ID: <XFMail.970630144821.kop@meme.com>
X-Mailer: XFMail 1.0 [p0] on Linux
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199706280306.GAA10440@cyberix.edu.ee>
Date: Mon, 30 Jun 1997 14:28:05 -0500 (CDT)
X-UIDL: 4c42b9ce4bb30e24abb133795a7c27c9
XFMstatus: 0000
Sender: frog.meme.com!kop@cyberix.edu.ee
From: "Karl O. Pinc" <meme.com!kop@cyberix.edu.ee>
To: Antti Andreimann <anttix@cyberix.edu.ee>
Subject: RE: Diald config
Cc: meme.com!kop@cyberix.edu.ee


On 28-Jun-97 Antti Andreimann wrote:
>Hi!
>I have to say, that I really like this configuration system .

Thanks.

>When it gets a control panel interface, it will be really cool.

There probably won't be a control panel interface, at least not from me.

>I have found a little bug in this package also: 
>in /usr/local/lib/diald/standard.filter.m4 at line 56 there is: 
>       ifdef(`NAMESERVER',dnl 
>but there should be: 
>       ifdef(`NAMESERVER',`dnl

Thanks.  I've a release 1.0 I haven't released yet that fixes this and
several other problems.

What's holding me up is that I can't seem to redirect standard error
from a chat script in a shell script (bash) invoked by diald to
connect.  Any clues?  I haven't really started looking at it and it's
already greatly annoying me.

>Also I think, that putting an RPM packaged files to /usr/local is not a
>good idea at all. As far as I can see this violates The Linux FileSystem
>Standard. /usr/lib and /usr/bin would be much better choices.

/usr/local is where RedHat wants it, and since it's designed to work in the
RedHat distribution...

>In readme file you wondered where diald pipes should go .
>I think /var/run would be a good place, but maybe /dev/ is even better,
>because initctl (witch is also a pipe) lives there. In any case you'll
>not have to worry about filesystem writeablility when dealing with pipes.
>As long as you will not need to create or delete one, every other operation
>(read/write from/to pipe) will work fine on read only filesystem ;-)

Good.  Thanks.  I don't know I'll mess with moving it.

>There is another little problem with RIP: when a request comes to route port
>and there is no routed running, an ICMP message will be generated and link
>remains up. I don't know witch icmp messages should keep the link up, but
>I assume, that only ICMP ECHO and ICMP ECHO-REPLY (ping) should be accepted.
>Maybe some other ones also. Don't know much about ICMP ;-(

I belive that the new release also addresses this issue.

>Anyway, keep up the good work ;-)

Thanks
X-RDate: Mon, 07 Jul 1997 11:48:52 -0500 (CDT)
Return-Path: anttix@cyberix.edu.ee
Received: from jorh.edu.ee (jorh.edu.ee [193.40.56.251]) by arthur.meme.com
 (8.7.6/8.7.3) with ESMTP id RAA01199 for <kop@meme.com>;
 Wed, 2 Jul 1997 17:14:36 -0500
Received: from cyberix.edu.ee (uucp@localhost) by jorh.edu.ee (8.8.5/8.6.9)
 with UUCP id AAA04980 for meme.com!kop; Thu, 3 Jul 1997 00:19:26 +0300
Received: (from anttix@localhost) by cyberix.edu.ee (8.8.5/8.7.3) id XAA03832
 for kop@meme.com; Wed, 2 Jul 1997 23:56:59 +0300
Message-Id: <199707022056.XAA03832@cyberix.edu.ee>
Date: Wed, 2 Jul 1997 23:56:59 +0300 (EET DST)
In-Reply-To: <XFMail.970630144821.kop@meme.com> from "Karl O. Pinc" at Jun 30,
 97 02:28:05 pm
Content-Type: text
X-UIDL: 276411723acef578be3c3c65ac0b0588
XFMstatus: 0200
From: Antti Andreimann <anttix@cyberix.edu.ee>
To: (Karl O. Pinc) <meme.com!kop@cyberix.edu.ee>
Subject: Re: Diald config

> 
> 
> >       ifdef(`NAMESERVER',`dnl
> 
> Thanks.  I've a release 1.0 I haven't released yet that fixes this and
> several other problems.
Hi! 

In the meantime I have found some other things, that should be changed:
	/etc/diald/diald.conf - is not used 
	these values should be also configurable via /etc/sysconfig/diald:
		nodev-retry-timeout
		retry-count
		redial-backoff-start
		redial-backoff-limit

> 
> What's holding me up is that I can't seem to redirect standard error
> from a chat script in a shell script (bash) invoked by diald to
> connect.  Any clues?  I haven't really started looking at it and it's
> already greatly annoying me.
Hmm. I have allways redirected stderr with '2>' in bash 
(noisy_program 2> /dev/null). But there are some circumstances, where it may
not work . Anyway try one of the following combinations:
	2> file - outputs stderr to file
	2>&1 - redirects stderr to stdout (can be used to fill variables like:
				a=`<program> 2>&1` )
	2>&- - closes stderr (no output can be produced, will break some progs).
	1>&2 - redirects stdout to stderr. Can be used to generate an error 
		message like: echo "Error: Help ! My pants are in fire" 1>&2
chat -V '' AT OK 2> /tmp/test  logged all sent and received data to /tmp/test 
with no problem.
It will not log the usual "chat[3650]: expect (OK)" lines to stdout .
Maybe you'll have to strip it out from syslog if you need this kind of 
report .
Tell me more about that problem, then I maybe able to help or at least
think about it ;-)
> 
> >Also I think, that putting an RPM packaged files to /usr/local is not a
> >good idea at all. As far as I can see this violates The Linux FileSystem
> >Standard. /usr/lib and /usr/bin would be much better choices.
> 
> /usr/local is where RedHat wants it, and since it's designed to work in the
> RedHat distribution...
I still don't think its a good idea, but if this is what redhat wants then 
let it be that way (who the hell in that company came out with such a stupid 
idea).
> 
-- 
========================================================================

            \||||||||||/                    Antti Andreimann
          \||||||||||||||/                  nickname: Cyber
       \|||||||||||||||||\                  anttix@cyberix.edu.ee
       /||||||||||||||||0\__@     ______    
       /|||||||||||||||||__/     (______)   Redistibution via Microsoft
        \||||||||||||||||/          {}      Network is prohibited.
(c)siil    L L       L L           _||_ 
========================================================================
X-RDate: Wed, 09 Jul 1997 10:21:58 -0500 (CDT)
Return-Path: frog.meme.com!kop@cyberix.edu.ee
Received: from jorh.edu.ee (jorh.edu.ee [193.40.56.251]) by arthur.meme.com
 (8.7.6/8.7.3) with ESMTP id KAA26956 for <kop@meme.com>;
 Tue, 8 Jul 1997 10:38:28 -0500
Received: from cyberix.edu.ee (uucp@localhost) by jorh.edu.ee (8.8.5/8.6.9)
 with UUCP id RAA14806 for meme.com!kop; Tue, 8 Jul 1997 17:49:20 +0300
Received: (from uucp@localhost) by cyberix.edu.ee (8.8.5/8.7.3) with UUCP id
 QAA10931; Tue, 8 Jul 1997 16:54:29 +0300
Received: from frog.meme.com (d198.loop.interaccess.com [206.183.68.198]) by
 jorh.edu.ee (8.8.5/8.6.9) with ESMTP id XAA14986;
 Mon, 7 Jul 1997 23:39:03 +0300
Received: (from kop@localhost) by frog.meme.com (8.7.6/8.7.3) id OAA01202;
 Mon, 7 Jul 1997 14:14:40 -0500
Message-ID: <XFMail.970707141439.kop@meme.com>
X-Mailer: XFMail 1.0 [p0] on Linux
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199707022056.XAA03832@cyberix.edu.ee>
Date: Mon, 07 Jul 1997 14:03:21 -0500 (CDT)
X-UIDL: 76aecba92095293bc9974de02f72767f
XFMstatus: 0000
Sender: frog.meme.com!kop@cyberix.edu.ee
From: "Karl O. Pinc" <meme.com!kop@cyberix.edu.ee>
To: Antti Andreimann <anttix@cyberix.edu.ee>
Subject: Re: Diald config
Cc: (Karl O. Pinc) <meme.com!kop@cyberix.edu.ee>


On 02-Jul-97 Antti Andreimann wrote:
>> 
>> 
>> >       ifdef(`NAMESERVER',`dnl
>> 
>> Thanks.  I've a release 1.0 I haven't released yet that fixes this and
>> several other problems.
>Hi! 
>
>In the meantime I have found some other things, that should be changed:
>       /etc/diald/diald.conf - is not used 

Poo.  This I'll have to check.

>       these values should be also configurable via /etc/sysconfig/diald:
>               nodev-retry-timeout
>               retry-count
>               redial-backoff-start
>               redial-backoff-limit
>

Sounds like a good idea on the face of it, but I'm not sure how it
will interact with the redhat ppp dialer config which is also what I'm
using.  I'll definately look into it.

>> 
>> What's holding me up is that I can't seem to redirect standard error
>> from a chat script in a shell script (bash) invoked by diald to
>> connect.  Any clues?  I haven't really started looking at it and it's
>> already greatly annoying me.
>Hmm. I have allways redirected stderr with '2>' in bash 
>(noisy_program 2> /dev/null). But there are some circumstances, where it may
>not work . Anyway try one of the following combinations:
>       2> file - outputs stderr to file
>       2>&1 - redirects stderr to stdout (can be used to fill variables like:
>                               a=`<program> 2>&1` )
>       2>&- - closes stderr (no output can be produced, will break some progs).
>       1>&2 - redirects stdout to stderr. Can be used to generate an error 
>               message like: echo "Error: Help ! My pants are in fire" 1>&2
>chat -V '' AT OK 2> /tmp/test  logged all sent and received data to /tmp/test 
>with no problem.
>It will not log the usual "chat[3650]: expect (OK)" lines to stdout .
>Maybe you'll have to strip it out from syslog if you need this kind of 
>report .
>Tell me more about that problem, then I maybe able to help or at least
>think about it ;-)

Thanks very much for the offer to help.  I use the '2> file' syntax,
which should work, but dosen't.  See the comment in the man page for
chat:

       -V     Request that the  chat  script  be  executed  in  a
              stderr verbose mode. The chat program will then log
              all text received from the  modem  and  the  output
              strings  which  it sends to the stderr device. This
              device is usually the local console at the  station
              running  the chat or pppd program. This option will
              not work properly if the stderr  is  redirected  to
              the  /dev/null  locaiton as is the case should pppd
              be run in the 'detached' mode. In  that  case,  use
              the '-v' option to record the session on the SYSLOG
              device.

I just read the ppp FAQ and didn't see any mention of it, I think it
might be some sort of unix internal thing.  Or maybe something to do
with the way shells work.  The version you are using goes all round
the barn using -v to log to the syslog and then syslog pipes the
output back to dctrl, but that is really a horrible hack, a big
hassle, and won't always work.  Any help you could give me would be
very welcome.

>> >Also I think, that putting an RPM packaged files to /usr/local is not a
>> >good idea at all. As far as I can see this violates The Linux FileSystem
>> >Standard. /usr/lib and /usr/bin would be much better choices.
>> 
>> /usr/local is where RedHat wants it, and since it's designed to work in the
>> RedHat distribution...
>I still don't think its a good idea, but if this is what redhat wants then 
>let it be that way (who the hell in that company came out with such a stupid 
>idea).

I have to say it dosen't really bother me.  /usr/local is for locally
developed programs, where /usr/share is for sitewide shareing of
stuff.
X-RDate: Sun, 03 Aug 1997 19:31:32 -0500 (CDT)
Return-Path: redhat-devel-list-request@redhat.com
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247]) by
 arthur.meme.com (8.7.6/8.7.3) with SMTP id LAA04147 for <kop@meme.com>;
 Thu, 31 Jul 1997 11:44:54 -0500
Received: (qmail 3764 invoked by uid 501); 31 Jul 1997 16:38:32 -0000
Resent-Date: 31 Jul 1997 16:38:31 -0000
Resent-Cc: recipient list not shown: ;
MBOX-Line: From redhat-devel-list-request@redhat.com  Thu Jul 31 12:38:30 1997
Date: Thu, 31 Jul 1997 10:09:22 -0500
Message-Id: <199707311509.KAA01890@frog.meme.com>
Resent-Message-ID: <"hpmFV3.0.Bu.5-Bup"@mail2.redhat.com>
Resent-From: redhat-devel-list@redhat.com
Reply-To: redhat-devel-list@redhat.com
X-Mailing-List: <redhat-devel-list@redhat.com> archive/latest/2029
X-Loop: redhat-devel-list@redhat.com
Precedence: list
Resent-Sender: redhat-devel-list-request@redhat.com
X-URL: http://www.redhat.com
X-UIDL: 40ed677257f143d33e3cdf9918b31613
XFMstatus: 0000
From: "Karl O. Pinc" <kop@meme.com>
To: redhat-devel-list@redhat.com
Subject: fifo my eye-fo

The following script produces inconsistant results, typically stopping
after printing "one", but sometimes going all the way to "four".
After "hanging" on "one", ls lists the fifo with a size of 20, yet
when "five" is sent to the fifo, no output is produced even though the
script completes and the size of the fifo goes back to zero.

The problem is particularly evident when you uncomment the sleep
statement.

Looks like some sort of race condition.  FWIW, I'm running this on a
33MHz 486; GNU bash, version 1.14.7(1); kernel 2.0.30.


#!/bin/bash

mkfifo /tmp/test.fifo

while read l < /tmp/test.fifo \
      && [ "$l" != "five" ] ; do 
  echo $l
#  sleep 1s
done &
pid=$!

( echo one 
  echo two 
  echo three 
  echo four 
  echo five ) > /tmp/test.fifo

wait $pid

rm /tmp/test.fifo



My actual goal, is to filter stderr produced by chat, prepending the
string "message " to each line and forwarding the result to the diald
control fifo.  This results in the messages being sent to the user
watching the dctrl program.  I can't seem to figure out how to pipe
stderr without messing with sdtout, hence the pipe through the fifo to
the background read loop which does the filtering -- and my encounter
with the above problem.

--
To unsubscribe:
mail -s unsubscribe redhat-devel-list-request@redhat.com < /dev/null
X-RDate: Thu, 07 Aug 1997 15:56:39 -0500 (CDT)
Return-Path: gbarr@pobox.com
Received: from vision.connect.net (vision.connect.net [199.1.91.168]) by
 arthur.meme.com (8.7.6/8.7.3) with ESMTP id VAA30251 for <kop@meme.com>;
 Tue, 5 Aug 1997 21:01:22 -0500
Received: from monty (a1p43.connect.net [199.1.91.53]) by vision.connect.net
 (Post.Office MTA v3.1 release PO203a  ID# 100-35121U5000L500S0) with ESMTP id
 AAA9853; Tue, 5 Aug 1997 20:56:04 -0500
Message-ID: <33E7DA2D.3DEF06F@pobox.com>
Date: Tue, 05 Aug 1997 20:58:05 -0500
X-Mailer: Mozilla 4.01b6C [en] (X11; I; Linux 2.0.30 i586)
MIME-Version: 1.0
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-UIDL: cd15c95f167f3f08a122ee0bee2d8699
XFMstatus: 0200
Sender: gbarr
From: Graham Barr <gbarr@pobox.com>
To: "Karl O. Pinc" <kop@meme.com>
Subject: diald-config

Hi,

I currently use your diald-config rpm for RedHat Linux. However
I now have two connections, one two work and one to my ISP. I was
just about to start modifying things to support multiple diald's
when I thought maybe you are already working on this. Do you have any
plans to support multiple diald's ??

If not are you interested in any changes I make ??

Regards,
Graham.
X-RDate: Sat, 30 Aug 1997 09:42:11 -0500 (CDT)
Return-Path: longyear@longyear.com
Received: from mail5.netcom.com (mail5.netcom.com [192.100.81.141]) by
 arthur.meme.com (8.7.6/8.7.3) with ESMTP id GAA13660 for <kop@meme.com>;
 Sat, 23 Aug 1997 06:25:35 -0500
Received: from longyear.com (longyear.com [192.187.163.32]) by mail5.netcom.com
 (8.8.5-r-beta/8.8.5/(NETCOM v1.01)) with ESMTP id EAA01410;
 Sat, 23 Aug 1997 04:01:02 -0700 (PDT)
Received: (from longyear@localhost) by longyear.com (8.8.6/8.8.6) id DAA07816;
 Sat, 23 Aug 1997 03:19:55 -0700
Message-Id: <199708231019.DAA07816@longyear.com>
In-Reply-To: <XFMail.970714111818.kop@meme.com> from "Karl O. Pinc" at "Jul 14,
 97 10:40:21 am"
Date: Sat, 23 Aug 1997 03:19:55 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-UIDL: 25e2e3e06e7de7e987f2921da065b274
XFMstatus: 0200
From: longyear <longyear@longyear.com>
To: (Karl O. Pinc) <kop@meme.com>
Subject: Re: Making a package and need chat help
Cc: paul.mackerras@cs.anu.edu.au

The man page for chat is out of date. The pppd process no longer makes
stderr point to /dev/null. It now points to the file
/etc/ppp/connect-errors.  The -V output would be logged there. The
pppd process opens this file. It may be any file type. If you wish to
divert the output directly to a process then create a named pipe at
that location.

For instructions on mknod to create the named pipe (or FIFO as it is
called), see

man 2 mknod.


> Hi,
> 
> I'm working on a diald (demand dialing deamon, for automagic
> maintenance of a network link over the phone system) rpm and, as the
> contact person for chat, was hoping you could point me to a solution,
> or at least more info.  I would like to be able to get the output of
> chat's verbose mode to dctrl, the diald monitor program, so that the
> user can tell what's going on with his connect script when a
> connection fails.  The released version of the diald rpm uses chat's
> -v option, and then goes all round the barn to get the messages from
> syslogd to dctrl.  Frankly, it's a hack.  I'd like to be able to use
> the -V option, and pick up the messages from stderr, but I don't get
> any output.  I seem to be running into the problem mentioned in the
> chat man page:
> 
>        -V     Request that the  chat  script  be  executed  in  a
>               stderr verbose mode. The chat program will then log
>               all text received from the  modem  and  the  output
>               strings  which  it sends to the stderr device. This
>               device is usually the local console at the  station
>         --->  running  the chat or pppd program. This option will
>         --->  not work properly if the stderr  is  redirected  to
>         --->  the  /dev/null  locaiton as is the case should pppd
>         --->  be run in the 'detached' mode. In  that  case,  use
>               the '-v' option to record the session on the SYSLOG
>               device.
> 
> Clearly, there's something I'm not understanding about unix streams,
> or something, because I'm running chat from a script invoked by diald,
> which (I think! -- this project's been on hold a while) can send to
> stderr just fine, and yet chat's stderr output dosen't get redirected.
> 
> I'm pretty much ready to release a beta version of the diald rpm (the
> last was alpha and had some potentially ugly problems) but I want to
> get this ironed out first.  Any help would be very much appreciated.
> 
> I'd be happy to send you the rpm or anything else you'd want to look
> at.
> 
X-RDate: Sat, 30 Aug 1997 09:42:16 -0500 (CDT)
Return-Path: longyear@longyear.com
Received: from mail5.netcom.com (mail5.netcom.com [192.100.81.141]) by
 arthur.meme.com (8.7.6/8.7.3) with ESMTP id HAA13758 for <kop@meme.com>;
 Sat, 23 Aug 1997 07:01:02 -0500
Received: from longyear.com (longyear.com [192.187.163.32]) by mail5.netcom.com
 (8.8.5-r-beta/8.8.5/(NETCOM v1.01)) with ESMTP id EAA06515 for <kop@meme.com>;
 Sat, 23 Aug 1997 04:54:30 -0700 (PDT)
Received: (from longyear@localhost) by longyear.com (8.8.6/8.8.6) id DAA07816;
 Sat, 23 Aug 1997 03:19:55 -0700
Message-Id: <199708231019.DAA07816@longyear.com>
In-Reply-To: <XFMail.970714111818.kop@meme.com> from "Karl O. Pinc" at "Jul 14,
 97 10:40:21 am"
Date: Sat, 23 Aug 1997 03:19:55 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-UIDL: 944ea6168f9ebd4b059a0ae7cb602c2d
XFMstatus: 0000
From: longyear <longyear@longyear.com>
To: (Karl O. Pinc) <kop@meme.com>
Subject: Re: Making a package and need chat help
Cc: paul.mackerras@cs.anu.edu.au

The man page for chat is out of date. The pppd process no longer makes
stderr point to /dev/null. It now points to the file
/etc/ppp/connect-errors.  The -V output would be logged there. The
pppd process opens this file. It may be any file type. If you wish to
divert the output directly to a process then create a named pipe at
that location.

For instructions on mknod to create the named pipe (or FIFO as it is
called), see

man 2 mknod.


> Hi,
> 
> I'm working on a diald (demand dialing deamon, for automagic
> maintenance of a network link over the phone system) rpm and, as the
> contact person for chat, was hoping you could point me to a solution,
> or at least more info.  I would like to be able to get the output of
> chat's verbose mode to dctrl, the diald monitor program, so that the
> user can tell what's going on with his connect script when a
> connection fails.  The released version of the diald rpm uses chat's
> -v option, and then goes all round the barn to get the messages from
> syslogd to dctrl.  Frankly, it's a hack.  I'd like to be able to use
> the -V option, and pick up the messages from stderr, but I don't get
> any output.  I seem to be running into the problem mentioned in the
> chat man page:
> 
>        -V     Request that the  chat  script  be  executed  in  a
>               stderr verbose mode. The chat program will then log
>               all text received from the  modem  and  the  output
>               strings  which  it sends to the stderr device. This
>               device is usually the local console at the  station
>         --->  running  the chat or pppd program. This option will
>         --->  not work properly if the stderr  is  redirected  to
>         --->  the  /dev/null  locaiton as is the case should pppd
>         --->  be run in the 'detached' mode. In  that  case,  use
>               the '-v' option to record the session on the SYSLOG
>               device.
> 
> Clearly, there's something I'm not understanding about unix streams,
> or something, because I'm running chat from a script invoked by diald,
> which (I think! -- this project's been on hold a while) can send to
> stderr just fine, and yet chat's stderr output dosen't get redirected.
> 
> I'm pretty much ready to release a beta version of the diald rpm (the
> last was alpha and had some potentially ugly problems) but I want to
> get this ironed out first.  Any help would be very much appreciated.
> 
> I'd be happy to send you the rpm or anything else you'd want to look
> at.
> 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
In-Reply-To: <199708231019.DAA07816@longyear.com>
Date: Sat, 30 Aug 1997 16:01:36 -0500 (CDT)
XFMstatus: 0001
From: "Karl O. Pinc" <kop@meme.com>
To: longyear <longyear@longyear.com>
Subject: Re: Making a package and need chat help
Cc: paul.mackerras@cs.anu.edu.au

Thank you both very much for your help.  With this information I should be able
to make things work quite spiffey.

In the FWIW catagory, I did discover something strange I couldn't figure out
with fifos.  To quote:

Date: Thu, 31 Jul 1997 10:09:22 -0500
From: "Karl O. Pinc" <kop@meme.com>
To: redhat-devel-list@redhat.com
Subject: fifo my eye-fo

The following script produces inconsistant results, typically stopping
after printing "one", but sometimes going all the way to "four".
After "hanging" on "one", ls lists the fifo with a size of 20, yet
when "five" is sent to the fifo, no output is produced even though the
script completes and the size of the fifo goes back to zero.

The problem is particularly evident when you uncomment the sleep
statement.

Looks like some sort of race condition.  FWIW, I'm running this on a
33MHz 486; GNU bash, version 1.14.7(1); kernel 2.0.30.


#!/bin/bash

mkfifo /tmp/test.fifo

while read l < /tmp/test.fifo \
      && [ "$l" != "five" ] ; do 
  echo $l
#  sleep 1s
done &
pid=$!

( echo one 
  echo two 
  echo three 
  echo four 
  echo five ) > /tmp/test.fifo

wait $pid

rm /tmp/test.fifo



My actual goal, is to filter stderr produced by chat, prepending the
string "message " to each line and forwarding the result to the diald
control fifo.  This results in the messages being sent to the user
watching the dctrl program.  I can't seem to figure out how to pipe
stderr without messing with sdtout, hence the pipe through the fifo to
the background read loop which does the filtering -- and my encounter
with the above problem.

--

On 23-Aug-97 longyear wrote:
>The man page for chat is out of date. The pppd process no longer makes
>stderr point to /dev/null. It now points to the file
>/etc/ppp/connect-errors.  The -V output would be logged there. The
>pppd process opens this file. It may be any file type. If you wish to
>divert the output directly to a process then create a named pipe at
>that location.
>
>For instructions on mknod to create the named pipe (or FIFO as it is
>called), see
>
>man 2 mknod.
>
>
>> Hi,
>> 
>> I'm working on a diald (demand dialing deamon, for automagic
>> maintenance of a network link over the phone system) rpm and, as the
>> contact person for chat, was hoping you could point me to a solution,
>> or at least more info.  I would like to be able to get the output of
>> chat's verbose mode to dctrl, the diald monitor program, so that the
>> user can tell what's going on with his connect script when a
>> connection fails.  The released version of the diald rpm uses chat's
>> -v option, and then goes all round the barn to get the messages from
>> syslogd to dctrl.  Frankly, it's a hack.  I'd like to be able to use
>> the -V option, and pick up the messages from stderr, but I don't get
>> any output.  I seem to be running into the problem mentioned in the
>> chat man page:
>> 
>>        -V     Request that the  chat  script  be  executed  in  a
>>               stderr verbose mode. The chat program will then log
>>               all text received from the  modem  and  the  output
>>               strings  which  it sends to the stderr device. This
>>               device is usually the local console at the  station
>>         --->  running  the chat or pppd program. This option will
>>         --->  not work properly if the stderr  is  redirected  to
>>         --->  the  /dev/null  locaiton as is the case should pppd
>>         --->  be run in the 'detached' mode. In  that  case,  use
>>               the '-v' option to record the session on the SYSLOG
>>               device.
>> 
>> Clearly, there's something I'm not understanding about unix streams,
>> or something, because I'm running chat from a script invoked by diald,
>> which (I think! -- this project's been on hold a while) can send to
>> stderr just fine, and yet chat's stderr output dosen't get redirected.
>> 
>> I'm pretty much ready to release a beta version of the diald rpm (the
>> last was alpha and had some potentially ugly problems) but I want to
>> get this ironed out first.  Any help would be very much appreciated.
>> 
>> I'd be happy to send you the rpm or anything else you'd want to look
>> at.
>> 
X-RDate: Tue, 02 Sep 1997 09:25:52 -0500 (CDT)
Return-Path: kfleming@access-laserpress.com
Received: from gatekeeper.access-laserpress.com
 (gatekeeper.access-laserpress.com [38.253.165.3]) by arthur.meme.com
 (8.7.6/8.7.3) with ESMTP id BAA12761 for <kop@meme.com>;
 Tue, 2 Sep 1997 01:04:04 -0500
Received: from access-laserpress.com ([192.168.1.201]) by
 gatekeeper.access-laserpress.com (8.8.5/8.8.5) with ESMTP id WAA18061 for
 <kop@meme.com>; Mon, 1 Sep 1997 22:55:12 -0700
Message-ID: <340BAA37.C7160B20@access-laserpress.com>
Date: Mon, 01 Sep 1997 22:55:03 -0700
Organization: Access Laserpress, Inc.
X-Mailer: Mozilla 4.02b7 [en] (X11; I; Linux 2.0.30 i586)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------50B1778F59014C8C7413BCA0"
X-UIDL: 4b2a55a6350f59ef2a6c10b19e62897a
XFMstatus: 0200
Sender: root@gatekeeper.access-laserpress.com
From: "Kevin P. Fleming" <kfleming@access-laserpress.com>
To: kop@meme.com
Subject: Enhancements to diald-config-0.1-1.i386.rpm

This is a multi-part message in MIME format.
--------------50B1778F59014C8C7413BCA0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I've composed and tested the attached enhancements; all are context
diffs against the appropriate files. The new features are:

1) Security holes in /etc/sysconfig/diald are closed by forcing the
permissions on /tmp/diald.filter and /tmp/diald.conf to be 0600.

2) /etc/sysconfig/network-scripts/diald will now operate correctly if
the ppp0 device was configured to use PAP by the RedHat netcfg tool.

3) /etc/diald/diald.conf is now processed by m4 when /tmp/diald.filter
is created, allowing it to reference existing m4 definitions and macros
(like WEB_BROWSING_TIMEOUT, for example).

4) start-dctrl now supports additional configuration parameters to tell
dctrl to start up with the connection queue, numeric load, graphic load
or dialing log panes open.

If you need any additional information from me, please don't hesitate to
ask. Thanks for a well put together package!
--------------50B1778F59014C8C7413BCA0
Content-Type: application/octet-stream; name="etc.sysconfig.diald.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="etc.sysconfig.diald.diff"

KioqIHdvcmsvZXRjL3N5c2NvbmZpZy9kaWFsZAlNb24gU2VwICAxIDIyOjI2OjA2IDE5OTcK
LS0tIC9ldGMvc3lzY29uZmlnL2RpYWxkCU1vbiBTZXAgIDEgMjE6MjY6NTMgMTk5NwoqKioq
KioqKioqKioqKioKKioqIDM3LDQ4ICoqKioKICAjIFNUQVJUX1NUQVRFICYgIGZvciBNT05f
Q09OTkVDVD15ZXMKICBGSUZPPS9ldGMvZGlhbGQvZGlhbGQuY3RsCiAgCiAgIyBBbmltYXRl
IHRoZSBkY3RybCBpY29uICh3aGVuIHRoZSB3aW5kb3cgaXMgaWNvbmlmaWVkLikKICBBTklN
QVRFX0RDVFJMPQogIAogICMgU3RhcnQgZGN0cmwgYXMgYW4gaWNvbi4KICBJQ09OSUZZX0RD
VFJMPQogIAogICMgU2VuZCBsb2cgbWVzc2FnZXMgcmVnYXJkaW5nIHRoZSBjb25uZWN0IHNj
cmlwdCB0byB0aGUgRklGTy4KICAjIChVc3VhbGx5IGRjdHJsLCB3aGljaCBkaXNwbGF5cyB0
aGVtIGluIGl0J3MgZGlhbGluZyBsb2cuKQogIE1PTl9DT05ORUNUPXllcwotLS0gMzcsNjAg
LS0tLQogICMgU1RBUlRfU1RBVEUgJiAgZm9yIE1PTl9DT05ORUNUPXllcwogIEZJRk89L2V0
Yy9kaWFsZC9kaWFsZC5jdGwKICAKICAjIEFuaW1hdGUgdGhlIGRjdHJsIGljb24gKHdoZW4g
dGhlIHdpbmRvdyBpcyBpY29uaWZpZWQuKQogIEFOSU1BVEVfRENUUkw9CiAgCiAgIyBTdGFy
dCBkY3RybCBhcyBhbiBpY29uLgogIElDT05JRllfRENUUkw9CiEgCiEgIyBUZWxsIGRjdHJs
IHRvIGRpc3BsYXkgdGhlIGNvbm5lY3Rpb24gdGltZXJzLgohIFBRVUVVRV9EQ1RSTD15ZXMK
ISAKISAjIFRlbGwgZGN0cmwgdG8gZGlzcGxheSB0aGUgdG90YWwgY29ubmVjdGlvbiBsb2Fk
IChpbiBudW1iZXJzKS4KISBUTE9BRF9EQ1RSTD15ZXMKISAKISAjIFRlbGwgZGN0cmwgdG8g
ZGlzcGxheSB0aGUgdG90YWwgY29ubmVjdGlvbiBsb2FkIChncmFwaGljYWxseSkuCiEgR0xP
QURfRENUUkw9CiEgCiEgIyBUZWxsIGRjdHJsIHRvIGRpc3BsYXkgdGhlIGRpYWxpbmcgbG9n
LgohIERMT0dfRENUUkw9CiAgCiAgIyBTZW5kIGxvZyBtZXNzYWdlcyByZWdhcmRpbmcgdGhl
IGNvbm5lY3Qgc2NyaXB0IHRvIHRoZSBGSUZPLgogICMgKFVzdWFsbHkgZGN0cmwsIHdoaWNo
IGRpc3BsYXlzIHRoZW0gaW4gaXQncyBkaWFsaW5nIGxvZy4pCiAgTU9OX0NPTk5FQ1Q9eWVz
CiAgCg==
--------------50B1778F59014C8C7413BCA0
Content-Type: application/octet-stream; name="etc.sysconfig.network-scripts.diald.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="etc.sysconfig.network-scripts.diald.diff"

KioqIHdvcmsvZXRjL3N5c2NvbmZpZy9uZXR3b3JrLXNjcmlwdHMvZGlhbGQJTW9uIFNlcCAg
MSAyMjoyNjowNiAxOTk3Ci0tLSAvZXRjL3N5c2NvbmZpZy9uZXR3b3JrLXNjcmlwdHMvZGlh
bGQJTW9uIFNlcCAgMSAyMjoxODoyNSAxOTk3CioqKioqKioqKioqKioqKgoqKiogMjYsMzMg
KioqKgotLS0gMjYsMzcgLS0tLQogIGZpCiAgCiAgLiAvZXRjL3N5c2NvbmZpZy9uZXR3b3Jr
LXNjcmlwdHMvaWZjZmctJElGQUNFCiAgCisgRElBTERfRklMVEVSX1BBVEg9Ii90bXAvZGlh
bGQuZmlsdGVyIgorIERJQUxEX0NPTkZfUEFUSD0iL3RtcC9kaWFsZC5jb25mIgorIERJQUxE
X1VNQVNLPSIwNzciCisgCiAgIyBNYWtlIHVzIGEgY3VzdG9tIGRpYWxkIG5ldHdvcmsgZmls
dGVyLgogIAogIGRlZnM9Ii1EREVGQVVMVF9USU1FT1VUPSR7REVGQVVMVF9USU1FT1VUfSIK
ICBpZiBbIC1uICIke1NUQVJUVVBfVElNRU9VVH0iIF0gOyB0aGVuCioqKioqKioqKioqKioq
KgoqKiogNjAsNzUgKioqKgogIGlmIFsgIiR7TkFNRVNFUlZFUn0iID0gInllcyIgXSA7IHRo
ZW4KICAgIGRlZnM9IiRkZWZzIC1ETkFNRVNFUlZFUiIKICBmaQogIAohICMgVGhlcmUncyBw
cm9iYWx5IGEgc2VjdXJpdHkgaG9sZSBoZXJlLgogIG00ICRkZWZzIC91c3IvbG9jYWwvbGli
L2RpYWxkL3N0YW5kYXJkLmZpbHRlci5tNCA+IC90bXAvZGlhbGQuZmlsdGVyCiAgCiAgIyBk
aWFsZCBpc24ndCB0b28gaGFwcHkgYWJvdXQgdGFraW5nIGNvbW1hbmQgbGluZSBhcmd1bWVu
dHMsIHNvCiEgIyBzdGFzaCAnZW0gaW4gYSBmaWxlLiAgKFByb2JhYmx5IGFub3RoZXIgc2Vj
dXJpdHkgaG9sZS4pCiAgCiAgIyBMb2dpYyBzbmFyZmVkIGZyb20gL2V0Yy9zeXNjb25maWcv
bmV0d29yay1zY3JpcHRzL2lmdXAtcHBwLgogIAogICggIyBBbGwgdGhpcyBzdGFuZGFyZCBv
dXQgZ2V0cyBzdGFzaGVkLgogIAogIGlmIFsgLW4gIiR7RklGT30iIF0gOyB0aGVuCiAgICBl
Y2hvICJmaWZvICR7RklGT30iCi0tLSA2NCw4MyAtLS0tCiAgaWYgWyAiJHtOQU1FU0VSVkVS
fSIgPSAieWVzIiBdIDsgdGhlbgogICAgZGVmcz0iJGRlZnMgLUROQU1FU0VSVkVSIgogIGZp
CiAgCiEgU0FWRV9VTUFTSz1gdW1hc2tgCiEgdW1hc2sgJHtESUFMRF9VTUFTS30KICBtNCAk
ZGVmcyAvdXNyL2xvY2FsL2xpYi9kaWFsZC9zdGFuZGFyZC5maWx0ZXIubTQgPiAvdG1wL2Rp
YWxkLmZpbHRlcgorIHVtYXNrICR7U0FWRV9VTUFTS30KICAKICAjIGRpYWxkIGlzbid0IHRv
byBoYXBweSBhYm91dCB0YWtpbmcgY29tbWFuZCBsaW5lIGFyZ3VtZW50cywgc28KISAjIHN0
YXNoICdlbSBpbiBhIGZpbGUuCiAgCiAgIyBMb2dpYyBzbmFyZmVkIGZyb20gL2V0Yy9zeXNj
b25maWcvbmV0d29yay1zY3JpcHRzL2lmdXAtcHBwLgogIAorIFNBVkVfVU1BU0s9YHVtYXNr
YAorIHVtYXNrICR7RElBTERfVU1BU0t9CiAgKCAjIEFsbCB0aGlzIHN0YW5kYXJkIG91dCBn
ZXRzIHN0YXNoZWQuCiAgCiAgaWYgWyAtbiAiJHtGSUZPfSIgXSA7IHRoZW4KICAgIGVjaG8g
ImZpZm8gJHtGSUZPfSIKKioqKioqKioqKioqKioqCioqKiAxMTksMTMxICoqKioKICBpZiBb
IC1uICIke0xDUF9FQ0hPX0lOVEVSVkFMfSIgXSA7IHRoZW4KICAgIHBwcG9wdHM9IiRwcHBv
cHRzIGxjcC1lY2hvLWludGVydmFsICR7TENQX0VDSE9fSU5URVJWQUx9IgogIGZpCiAgCiAg
aWYgWyAtbiAiJHBwcG9wdHMiIF0gOyB0aGVuCiAgICBlY2hvICJwcHBkLW9wdGlvbnMgJHBw
cG9wdHMiCiAgZmkKICApID4gL3RtcC9kaWFsZC5jb25mCiEgCiAgCiAgIyBEbyB0aGUgZGly
dHkgZGVlZC4KICBkaWFsZAogIHJlc3VsdD0kPwotLS0gMTI3LDE0NCAtLS0tCiAgaWYgWyAt
biAiJHtMQ1BfRUNIT19JTlRFUlZBTH0iIF0gOyB0aGVuCiAgICBwcHBvcHRzPSIkcHBwb3B0
cyBsY3AtZWNoby1pbnRlcnZhbCAke0xDUF9FQ0hPX0lOVEVSVkFMfSIKICBmaQogIAorICMg
SWYgUEFQIGF1dGhlbnRpY2F0aW9uIHdhcyBjb25maWd1cmVkIGJ5IG5ldGNmZywgcGFzcyB0
aGUgaW5mbyB0byBwcHBkLgorIGlmIFsgLW4gIiR7UEFQTkFNRX0iIF0gOyB0aGVuCisgICBw
cHBvcHRzPSIkcHBwb3B0cyBuYW1lICR7UEFQTkFNRX0gcmVtb3RlbmFtZSAke0lGQUNFfSIK
KyBmaQorIAogIGlmIFsgLW4gIiRwcHBvcHRzIiBdIDsgdGhlbgogICAgZWNobyAicHBwZC1v
cHRpb25zICRwcHBvcHRzIgogIGZpCiAgKSA+IC90bXAvZGlhbGQuY29uZgohIHVtYXNrICR7
U0FWRV9VTUFTS30KICAKICAjIERvIHRoZSBkaXJ0eSBkZWVkLgogIGRpYWxkCiAgcmVzdWx0
PSQ/Cg==
--------------50B1778F59014C8C7413BCA0
Content-Type: application/octet-stream; name="usr.doc.diald-config.README.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="usr.doc.diald-config.README.diff"

KioqIHdvcmsvdXNyL2RvYy9kaWFsZC1jb25maWctMC4xLTEvUkVBRE1FCU1vbiBTZXAgIDEg
MjI6MjY6MDYgMTk5NwotLS0gL3Vzci9kb2MvZGlhbGQtY29uZmlnLTAuMS0xL1JFQURNRQlN
b24gU2VwICAxIDIxOjIwOjU3IDE5OTcKKioqKioqKioqKioqKioqCioqKiAxMzEsMTM4ICoq
KioKLS0tIDEzMSwxNTAgLS0tLQogIAogICMgU3RhcnQgZGN0cmwgYXMgYW4gaWNvbi4KICBJ
Q09OSUZZX0RDVFJMPQogIAorICMgVGVsbCBkY3RybCB0byBkaXNwbGF5IHRoZSBjb25uZWN0
aW9uIHRpbWVycy4KKyBQUVVFVUVfRENUUkw9CisgCisgIyBUZWxsIGRjdHJsIHRvIGRpc3Bs
YXkgdGhlIHRvdGFsIGNvbm5lY3Rpb24gbG9hZCAoaW4gbnVtYmVycykuCisgVExPQURfRENU
Ukw9CisgCisgIyBUZWxsIGRjdHJsIHRvIGRpc3BsYXkgdGhlIHRvdGFsIGNvbm5lY3Rpb24g
bG9hZCAoZ3JhcGhpY2FsbHkpLgorIEdMT0FEX0RDVFJMPQorIAorICMgVGVsbCBkY3RybCB0
byBkaXNwbGF5IHRoZSBkaWFsaW5nIGxvZy4KKyBETE9HX0RDVFJMPQorIAogICMgU2VuZCBs
b2cgbWVzc2FnZXMgcmVnYXJkaW5nIHRoZSBjb25uZWN0IHNjcmlwdCB0byB0aGUgRklGTy4K
ICAjIChVc3VhbGx5IGRjdHJsLCB3aGljaCBkaXNwbGF5cyB0aGVtIGluIGl0J3MgZGlhbGlu
ZyBsb2cuKQogIE1PTl9DT05ORUNUPXllcwogIAo=
--------------50B1778F59014C8C7413BCA0
Content-Type: application/octet-stream; name="usr.local.bin.start-dctrl.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="usr.local.bin.start-dctrl.diff"

KioqIHdvcmsvdXNyL2xvY2FsL2Jpbi9zdGFydC1kY3RybAlNb24gU2VwICAxIDIyOjI2OjA2
IDE5OTcKLS0tIC91c3IvbG9jYWwvYmluL3N0YXJ0LWRjdHJsCU1vbiBTZXAgIDEgMTQ6NDM6
NTggMTk5NwoqKioqKioqKioqKioqKioKKioqIDEyLDI3ICoqKioKICAgIGxvZ2dlciAtdCBk
Y3RybCAtcCBkYWVtb24uaW5mbyAibm8gZmlmbyBzcGVjaWZpZWQsIGNhbm5vdCBzdGFydCIK
ICAgIGV4aXQgMQogIGZpCiAgCiAgaWYgWyAiJHtJQ09OSUZZX0RDVFJMfSIgPSAieWVzIiBd
IDsgdGhlbgohICAgaWNvbmljPSItaWNvbmljIgogIGZpCiAgCiAgaWYgWyAiJHtBTklNQVRF
X0RDVFJMfSIgPSAieWVzIiBdIDsgdGhlbgohICAgaT0iLWkiCiAgZmkKICAKISBub2h1cCBk
Y3RybCAkaSAkaWNvbmljID4vZGV2L251bGwgJgogIAogIGVjaG8gJCEgPiAvdmFyL3J1bi9k
Y3RybC5waWQKICAKLS0tIDEyLDQ1IC0tLS0KICAgIGxvZ2dlciAtdCBkY3RybCAtcCBkYWVt
b24uaW5mbyAibm8gZmlmbyBzcGVjaWZpZWQsIGNhbm5vdCBzdGFydCIKICAgIGV4aXQgMQog
IGZpCiAgCisgRENUUkxfT1BUSU9OUz0iIgorIAogIGlmIFsgIiR7SUNPTklGWV9EQ1RSTH0i
ID0gInllcyIgXSA7IHRoZW4KISAgIERDVFJMX09QVElPTlM9Ii1pY29uaWMiCiAgZmkKICAK
ICBpZiBbICIke0FOSU1BVEVfRENUUkx9IiA9ICJ5ZXMiIF0gOyB0aGVuCiEgICBEQ1RSTF9P
UFRJT05TPSIkRENUUkxfT1BUSU9OUyAtaSIKISBmaQohIAohIGlmIFsgIiR7RExPR19EQ1RS
TH0iID0gInllcyIgXSA7IHRoZW4KISAgIERDVFJMX09QVElPTlM9IiREQ1RSTF9PUFRJT05T
IC1kbG9nIgohIGZpCiEgCiEgaWYgWyAiJHtQUVVFVUVfRENUUkx9IiA9ICJ5ZXMiIF0gOyB0
aGVuCiEgICBEQ1RSTF9PUFRJT05TPSIkRENUUkxfT1BUSU9OUyAtcHF1ZXVlIgohIGZpCiEg
CiEgaWYgWyAiJHtUTE9BRF9EQ1RSTH0iID0gInllcyIgXSA7IHRoZW4KISAgIERDVFJMX09Q
VElPTlM9IiREQ1RSTF9PUFRJT05TIC10bG9hZCIKISBmaQohIAohIGlmIFsgIiR7R0xPQURf
RENUUkx9IiA9ICJ5ZXMiIF0gOyB0aGVuCiEgICBEQ1RSTF9PUFRJT05TPSIkRENUUkxfT1BU
SU9OUyAtZ2xvYWQiCiAgZmkKICAKISBub2h1cCBkY3RybCAkRENUUkxfT1BUSU9OUyA+L2Rl
di9udWxsICYKICAKICBlY2hvICQhID4gL3Zhci9ydW4vZGN0cmwucGlkCiAgCg==
--------------50B1778F59014C8C7413BCA0
Content-Type: application/octet-stream; name="usr.local.lib.diald.standard.filter.m4.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="usr.local.lib.diald.standard.filter.m4.diff"

KioqIHdvcmsvdXNyL2xvY2FsL2xpYi9kaWFsZC9zdGFuZGFyZC5maWx0ZXIubTQJTW9uIFNl
cCAgMSAyMjoyNjowNiAxOTk3Ci0tLSAvdXNyL2xvY2FsL2xpYi9kaWFsZC9zdGFuZGFyZC5m
aWx0ZXIubTQJTW9uIFNlcCAgMSAyMTozODozMyAxOTk3CioqKioqKioqKioqKioqKgoqKiog
MTcxLDE3OSAqKioqCiAgaWdub3JlIHVkcCB0Y3Auc291cmNlPXVkcC5yb3V0ZQogICcpZG5s
CiAgCiAgIyBBbnkgY3VzdG9tIHVzZXIgY29uZmlndXJhdGlvbiBjb21lcyBuZXh0IHRvIGxh
c3QuCiEgaW5jbHVkZSAvZXRjL2RpYWxkL2RpYWxkLmNvbmYKICAKICBpZmRlZihgT1RIRVJf
VENQX1RJTUVPVVQnLGBkbmwKICAjIElmIHdlIGRvbiJ0IGNhdGNoIGl0IGFib3ZlLCBnaXZl
IHRoZSBsaW5rIE9USEVSX1RDUF9USU1FT1VUIHNlY29uZHMgdXAgdGltZS4KICBhY2NlcHQg
dGNwIE9USEVSX1RDUF9USU1FT1VUIGFueQotLS0gMTcxLDE3OSAtLS0tCiAgaWdub3JlIHVk
cCB0Y3Auc291cmNlPXVkcC5yb3V0ZQogICcpZG5sCiAgCiAgIyBBbnkgY3VzdG9tIHVzZXIg
Y29uZmlndXJhdGlvbiBjb21lcyBuZXh0IHRvIGxhc3QuCiEgc2luY2x1ZGUoL2V0Yy9kaWFs
ZC9kaWFsZC5jb25mKQogIAogIGlmZGVmKGBPVEhFUl9UQ1BfVElNRU9VVCcsYGRubAogICMg
SWYgd2UgZG9uInQgY2F0Y2ggaXQgYWJvdmUsIGdpdmUgdGhlIGxpbmsgT1RIRVJfVENQX1RJ
TUVPVVQgc2Vjb25kcyB1cCB0aW1lLgogIGFjY2VwdCB0Y3AgT1RIRVJfVENQX1RJTUVPVVQg
YW55Cg==
--------------50B1778F59014C8C7413BCA0--
X-RDate: Wed, 03 Sep 1997 20:13:05 -0500 (CDT)
Return-Path: kfleming@access-laserpress.com
Received: from gatekeeper.access-laserpress.com
 (gatekeeper.access-laserpress.com [38.253.165.3]) by arthur.meme.com
 (8.7.6/8.7.3) with ESMTP id MAA19818 for <kop@meme.com>;
 Wed, 3 Sep 1997 12:31:04 -0500
Received: from access-laserpress.com (KEVIN.access.internal [192.168.1.100]) by
 gatekeeper.access-laserpress.com (8.8.5/8.8.5) with ESMTP id KAA00960 for
 <kop@meme.com>; Wed, 3 Sep 1997 10:22:25 -0700
Message-ID: <340D9CD0.FC71DB9C@access-laserpress.com>
Date: Wed, 03 Sep 1997 10:22:24 -0700
Organization: Access Laserpress, Inc.
X-Mailer: Mozilla 4.02 [en] (Win95; U)
MIME-Version: 1.0
References: <XFMail.970902093518.kop@meme.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-UIDL: dab362589452cd54b3daa6a348ec52db
XFMstatus: 0200
From: "Kevin P. Fleming" <kfleming@access-laserpress.com>
To: "Karl O. Pinc" <kop@meme.com>
Subject: Re: Enhancements to diald-config-0.1-1.i386.rpm

(for reference, I'm running the same kernel version and bash version as you
are)

It doesn't look like this is a race condition; rather, the process _reading_
from the fifo has to only open it once and keep it open, not open it, read
one line, then close. The modified script below works perfectly on my
system, with no sleep delays.

Karl O. Pinc wrote:
> 
> Thanks much.
> 
> I've a new release that supports multiple diald connections and fixes some
> other problems.  However, the sending of messages to dctrl is wacky in the
> original release and won't really adapt to multiple connections.  I'd have
> released it long ago, but have the following problem with fifo's.  Any help
> would be appreaciated.
> 
<snip> 

#!/bin/bash

mkfifo /tmp/test.fifo

( while read l && [ "$l" != "five" ] ; do
    echo $l
  done ) < /tmp/test.fifo &
pid=$!

( echo one
  echo two
  echo three
  echo four
  echo five ) > /tmp/test.fifo

wait $pid

rm /tmp/test.fifo
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
In-Reply-To: <340D9CD0.FC71DB9C@access-laserpress.com>
Date: Wed, 03 Sep 1997 20:46:48 -0500 (CDT)
XFMstatus: 0001
From: "Karl O. Pinc" <kop@meme.com>
To: "Kevin P. Fleming" <kfleming@access-laserpress.com>
Subject: Re: Enhancements to diald-config-0.1-1.i386.rpm

Thanks!  I'll give it a go.  (Still seems wierd that the original script
dosen't work tho'.)

On 03-Sep-97 Kevin P. Fleming wrote:
>(for reference, I'm running the same kernel version and bash version as you
>are)
>
>It doesn't look like this is a race condition; rather, the process _reading_
>from the fifo has to only open it once and keep it open, not open it, read
>one line, then close. The modified script below works perfectly on my
>system, with no sleep delays.
>
>Karl O. Pinc wrote:
>> 
>> Thanks much.
>> 
>> I've a new release that supports multiple diald connections and fixes some
>> other problems.  However, the sending of messages to dctrl is wacky in the
>> original release and won't really adapt to multiple connections.  I'd have
>> released it long ago, but have the following problem with fifo's.  Any help
>> would be appreaciated.
>> 
><snip> 
>
>#!/bin/bash
>
>mkfifo /tmp/test.fifo
>
>( while read l && [ "$l" != "five" ] ; do
>    echo $l
>  done ) < /tmp/test.fifo &
>pid=$!
>
>( echo one
>  echo two
>  echo three
>  echo four
>  echo five ) > /tmp/test.fifo
>
>wait $pid
>
>rm /tmp/test.fifo
X-RDate: Sat, 27 Sep 1997 21:21:49 -0500 (CDT)
Return-Path: kop@meme.com
Received: from frog.meme.com (d131.ch.interaccess.com [207.208.15.131]) by
 arthur.meme.com (8.7.6/8.7.3) with ESMTP id XAA11215 for <kop@meme.com>;
 Sat, 27 Sep 1997 23:04:35 -0500
Received: (from kop@localhost) by frog.meme.com (8.8.5/8.8.5) id VAA20106;
 Sat, 27 Sep 1997 21:16:02 -0500
Message-ID: <XFMail.970927211602.kop@meme.com>
X-Mailer: XFMail 1.0 [p0] on Linux
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Sat, 27 Sep 1997 20:50:30 -0500 (CDT)
X-UIDL: 9d463b69cab81a1bf26fb2eef3f27533
XFMstatus: 0002
Sender: kop@meme.com
From: "Karl O. Pinc" <kop@meme.com>
To: lsm@execpc.com
Subject: add

Begin3
Title:          ppp
Version:        2.2.0g
Entered-date:   27SEP97
Description:    Daemon for the PPP protocol for Linux. This includes
                the chat utility program.

                This version is designed to work with the 2.2.0 version
                of the linux kernel driver. This release will work
                properly with the 1.3.85 kernel as well as the 1.2.13
                kernel.  The only difference between this release and
                the previous version is some enhancements to chat.
Keywords:       ppp, network, drivers
Author:         paulus@cs.anu.edu.au (Paul Mackerras)
Maintained-by:  longyear@netcom.com (Al Longyear)
                callahan@maths.ox.ac.uk (Michael Callahan)
Primary-site:   sunsite.unc.edu /pub/Linux/system/Network/serial
                376920 bytes
Original-site:  cs.anu.edu.au /pub/ppp
Copying-policy: BSD
End

MD5-Checksum:	043216021eab9dac0d8d14a07a64fc4f
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Sat, 27 Sep 1997 23:59:49 -0500 (CDT)
XFMstatus: 0001
From: "Karl O. Pinc" <kop@meme.com>
To: paulus@cs.anu.edu.au, redhat-devel-list@redhat.com
Subject: ANNOUNCE: Enhancement to chat.
Cc: callahan@maths.ox.ac.uk, dick@tasking.nl, Francis@swissmail.com,
 bgeer@xmission.com, longyear@netcom.com

I have added two new options to chat, -s and -S.  These options
control where erorrs are sent and where the output of the -v option is
sent.

>From the man page:

       -v     Request  that the chat script be executed in a ver-
              bose mode. The chat program will then log the  exe-
              cution state of the chat script as well as all text
              received from the modem and the output strings sent
              to  the  modem.   The default is to log through the
              SYSLOG; the logging method may be altered with  the
              -S and -s flags.

       -s     Use  stderr.   All  log  messages from '-v' and all
              error messages will be sent to stderr.

       -S     Do not use the SYSLOG.  By default, error  messages
              are sent to the SYSLOG.  The use of -S will prevent
              both log messages from '-v' and error messages from
              being sent to the SYSLOG.

The changes are based on the ppp-2.2.0f release found at sunsite.  The
new version has been uploaded to sunsite as ppp-2.2.0g.  An rpm
incorporating the changes has been uploaded to ftp.redhat.com.

I have tested these changes.  Please let me know if you find any bugs
in the new code.

For those using the 2.3.1 version of ppp found at
ftp://cs.anu.edu.au/pub/software/ppp/ppp-2.3.1.tar.gz, there is a
patch (which has not been tested much) available at
ftp://ftp.meme.com/pub/software/ppp-2.3.2-patch.gz
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Sun, 28 Sep 1997 00:04:28 -0500 (CDT)
XFMstatus: 0001
From: "Karl O. Pinc" <kop@meme.com>
To: paulus@cs.anu.edu.au
Subject: PATCH: Enhancements to chat.

As your at the site of the latest ppp I could find, and your fingerprints are
all over chat.  I figured I'd also send you the patch for my changes.
----------------<patch snipped>------------------
  
X-RDate: Mon, 29 Sep 1997 11:34:25 -0500 (CDT)
Return-Path: snowman@maribor.zrcalo.si
Received: from maribor.zrcalo.si (maribor.zrcalo.si [193.77.90.34]) by
 arthur.meme.com (8.7.6/8.7.3) with ESMTP id KAA05458 for <kop@meme.com>;
 Mon, 29 Sep 1997 10:08:05 -0500
Received: (from snowman@localhost) by maribor.zrcalo.si (8.8.5/8.8.5) id
 QAA11705 for kop@meme.com; Mon, 29 Sep 1997 16:58:34 +0200
Message-ID: <XFMail.970929165834.snowman@zrcalo.si>
X-Mailer: XFMail 1.2-alpha [p0] on Linux
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Mon, 29 Sep 1997 16:52:18 +0200 (MET DST)
X-UIDL: a4c139dff96e74dfe8ecd990a3b0e6b2
XFMstatus: 0200
Sender: snowman@maribor.zrcalo.si
From: Alen Salamun <snowman@zrcalo.si>
To: kop@meme.com
Subject: diald-config-0.1-1.rpm

Hi!

I have found some BUGS in you package. First one (I needed 4 hrs to debug it) is
 that if I use PAP it doesn't work because you don't include name and remotename
 parameter for pppd. So I added in /etc/sysconfig/network-scripts/diald in line 
that parses pppd parameters:

name <name of my host> (U get it from /etc/sysconfig/netwrok-scripts/ifcfg-ppp0 
under PAPNAME=)
remotename ppp0

And it worked.... Another bug is in /usr/local/lib/diald/standard.filter.m4
U have frogot to put on ` (turned in other side) to line for NAMESERVER:

IFDEF('NAMESERVER', ` <- U frogot that one)

Let me know of new package...

Regards, Alen

         | Alen Salamun |    EMAIL:  snowman@hal9000.zrcalo.si    | 
         |             -= LiNUX =-   The only REAL OS             |     
         | Microsoft is not the answer, Microsoft is the question |
         |                 and the answer is NO!!                 |
From: Antoni Pamies Olive <toni@readysoft.es>
To: "Karl O. Pinc" <kop@meme.com>
Subject: dialdconfig

Hello, I'm Antoni Pamies from Ready Soft.

I use your dialdconfig with RedHat 4.2 and i need to add the following lines to
diald-up:

 # If PAP authentication was configured by netcfg, pass the info to pppd.
 if [ -n "${PAPNAME}" ] ; then
   pppopts="$pppopts name ${PAPNAME} remotename ${IFACE}"
 fi

+
+if [ -n "${DEVICE}" ] ; then
+  pppopts="$pppopts ipparam ${DEVICE}"
+fi
+

 if [ -n "$pppopts" ] ; then
   echo "pppd-options $pppopts"
 fi



Best Regards

             \\|//                                             
             (@ @)                                          
+--------ooO--(_)--Ooo-----------------+------------------------------------+
|  Antoni Pamies Olive                 |  Et Portem el mon a casa           |
|  Ready Soft                          |  http://www.readysoft.es           |
|  Av. Maria Fortuny 87 3 planta       |  toni@readysoft.net                |
|  Reus (Catalunya)                    |                                    |
+--------------------------------------+------------------------------------+

From: Hal Wine <hal@dtor.com>
To: "Karl O. Pinc" <kop@meme.com>
Subject: Re: ANNOUNCE: diald-config-1.1 -- demand dialing made easy

"Karl O. Pinc" (<kop@meme.com>) wrote:
>Version 1.1 of diald-config has just been released.

>Release Notes:
>
>install Added support for RPM_BUILD_ROOT, ensured /etc/diald creation,
>used set -e for to ensure exit immediately on error.

FYI, I found the SRPM's I downloaded today from your ftp site were 
missing BuildRoot: statements in the spec file, and would not rebuild 
without that.

RedHat 3.2
rpm 2.3.10
diald-config-1.1-1.src.rpm
diald-config-metered-0.2-1.src.rpm


Thanks for the work -- I'd delayed installing diald for years now 
because I didn't want to tackle the config (good thing I have a stable 
phone connection, eh?).  Just gotta update ppp and in it will go....
-- 
Hal Wine <hal@dtor.com>                         DTOR Consulting

Date: Wed, 07 Jan 1998 20:56:12 -0600 (CST)
XFMstatus: 0001
From: "Karl O. Pinc" <kop@meme.com>
To: Hal Wine <hal@dtor.com>
Subject: Re: ANNOUNCE: diald-config-1.1 -- demand dialing made easy


On 08-Jan-98 Hal Wine wrote:
>"Karl O. Pinc" (<kop@meme.com>) wrote:
>>Version 1.1 of diald-config has just been released.
>
>>Release Notes:
>>
>>install Added support for RPM_BUILD_ROOT, ensured /etc/diald creation,
>>used set -e for to ensure exit immediately on error.
>
>FYI, I found the SRPM's I downloaded today from your ftp site were 
>missing BuildRoot: statements in the spec file, and would not rebuild 
>without that.

Whoops.  Thanks.  I'll have to put out a new rpm version.  (I've buildroot: in
my rpmrc file.)

>
>RedHat 3.2
>rpm 2.3.10
>diald-config-1.1-1.src.rpm
>diald-config-metered-0.2-1.src.rpm
>
>
>Thanks for the work -- I'd delayed installing diald for years now 
>because I didn't want to tackle the config (good thing I have a stable 
>phone connection, eh?).  Just gotta update ppp and in it will go....

You'll have to get the new pppd out of contrib.

I had to update quite a few packages to get it to work when I first wrote it. 
I'd be interested in hearing how easy it is to install.

For that matter I'd be interested in any feedback.  Haven't gotten much since
the early fixes.   I presume no news is good news.

Date: Wed, 07 Jan 1998 19:49:02 -0600 (CST)
XFMstatus: 0001
From: "Karl O. Pinc" <kop@meme.com>
To: Chris Savage <chris@cti-vision.demon.co.uk>
Subject: RE: ppp-2.2.0g?


On 06-Jan-98 Chris Savage wrote:
>Hello Karl,
>
>I've tried to install diald-config-1.1.noarch.rpm and it says I need
>ppp.2.2.0g
>
>My RedHat 4.2 has ppp.2.2.0f and I can't anything newer than that anywhere.
>Any pointers please?

ftp://ftp.redhat.com/contrib/i386

2.2.0 release greater than or equal to "g" have the necessary patch, as do 2.3
release >= 2.3.3

Please let me know what you think of diald-config!

Karl <kop@meme.com>

Date: Thu, 08 Jan 1998 07:42:10 -0800
X-UIDL: b8d2b4d71499e5ebfbd46e1f5fc83f5c
XFMstatus: 0200
From: Hal Wine <hal@dtor.com>
To: "Karl O. Pinc" <kop@meme.com>
Subject: Re: ANNOUNCE: diald-config-1.1 -- demand dialing made easy

"Karl O. Pinc" (<kop@meme.com>) wrote:
>Whoops.  Thanks.  I'll have to put out a new rpm version.  (I've 
buildroot: in
>my rpmrc file.)

Before you do that, there's another fix or two:  I had problems with 2 
scripts having syntax errors -- perhaps only for non RH 5.0 case.  
Patch file for one attached, the other was /etc/sysconfig/network-script
s/diald-connect with the same "elif" -> "else" change needed (at line 
31, I believe).

FWIW, I had to back off from the install for now.  The chat script kept 
failing, and I couldn't understand why, or get verbose debug for chat 
to work.  I'll have to wait until I have more time.  (I do have a 
working chat script, but I don't use the RH config tools -- they 
weren't too stable before 4.2 and I learned to avoid them.  So my ppp 
logins don't happen the "standard" way.)

>For that matter I'd be interested in any feedback.  Haven't gotten 
much since
>the early fixes.   I presume no news is good news.

Well, I didn't take the time to read all the documentation, just the 
README's. So maybe my confusion was because of that, but I couldn't 
figure out where to insert the "debug 31" for diald.  Finally stuck it 
in /etc/sysconfig/dialdcfg and I think that worked.  But I wasn't sure 
which file used which syntax.

Also, it's not clear to me why the new pppd is required (I actually did 
a --nodeps install, so that might be my problem, too).  From the 
updated pppd spec file change log, it appeared that the only changes 
were Win95 support and the one duplicate lock in /etc/ppp/options 
(which I removed by hand).  Since I don't care about win95, and I 
noticed that RH has not included the changes in 5.0, I figured there 
was no real reason to upgrade.

Okay, that's all the comments that I have.  Here's the one patch file I 
have

--- diald-up.orig	Thu Jan  8 07:39:09 1998
+++ diald-up	Wed Jan  7 18:07:03 1998
@@ -43,7 +43,7 @@
   fi
   . network-functions
   source_config
-elif
+else
   if [ ! -f /etc/sysconfig/network-scripts/ifcfg-$IFACE ] ; then
     error "/etc/sysconfig/network-scripts/ifcfg-$IFACE does not exist"
   fi
@@ -51,7 +51,7 @@
 fi
 
 # Compatiblity support.
-if [ "${CONFPROG"} = "REDHAT" ] ; then
+if [ "${CONFPROG}" = "REDHAT" ] ; then
   if [ -z "${REMOTENAME}" ] ; then
     REMOTENAME="${DEVICE}"
   fi


Date: Thu, 08 Jan 1998 08:53:52 -0800
X-UIDL: ea70e9b2049825e2e69d63767ce4d3a8
XFMstatus: 0000
From: Hal Wine <hal@dtor.com>
To: "Karl O. Pinc" <kop@meme.com>
Subject: Re: ANNOUNCE: diald-config-1.1 -- demand dialing made easy

Hal Wine (<hal@dtor.com>) wrote:
>Before you do that, there's another fix or two: 

Add one other I just remembered.  When using BuildRoot, you need to add 
%attr(,root,root) to each file in the files section.  Otherwise, the 
files end up owned by the person who did the packaging (okay on my 
single user system, but not in general)!

-- 
Hal Wine <hal@dtor.com>                         DTOR Consulting


From kop@meme.com  Thu Jan  8 23:01:07 1998
Status: RO
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="_=XFMail.1.0.p0.Linux:980109003034:748=_"
In-Reply-To: <199801081542.HAA03435@MyShadow.dtor.com>
Date: Thu, 08 Jan 1998 23:01:07 -0600 (CST)
From: "Karl O. Pinc" <kop@meme.com>
To: Hal Wine <hal@dtor.com>
Subject: Re: ANNOUNCE: diald-config-1.1 -- demand dialing made easy

This message is in MIME format
--_=XFMail.1.0.p0.Linux:980109003034:748=_
Content-Type: text/plain; charset=us-ascii


On 08-Jan-98 Hal Wine wrote:
>"Karl O. Pinc" (<kop@meme.com>) wrote:
>>Whoops.  Thanks.  I'll have to put out a new rpm version.  (I've 
>buildroot: in
>>my rpmrc file.)
>
>Before you do that, there's another fix or two:  I had problems with 2 
>scripts having syntax errors -- perhaps only for non RH 5.0 case.  
>Patch file for one attached, the other was /etc/sysconfig/network-script
>s/diald-connect with the same "elif" -> "else" change needed (at line 
>31, I believe).


Thanks.  Something wierd happened.  rpm tells me that diald-config-1.1
is installed, but it's not.  So the 1.1 changes didn't get properly
tested.  *poo*  Sorry about that.

>
>FWIW, I had to back off from the install for now.  The chat script kept 
>failing, and I couldn't understand why, or get verbose debug for chat 
>to work.  I'll have to wait until I have more time.  (I do have a 
>working chat script, but I don't use the RH config tools -- they 
>weren't too stable before 4.2 and I learned to avoid them.  So my ppp 
>logins don't happen the "standard" way.)
>
>>For that matter I'd be interested in any feedback.  Haven't gotten 
>much since
>>the early fixes.   I presume no news is good news.
>
>Well, I didn't take the time to read all the documentation, just the 
>README's. So maybe my confusion was because of that, but I couldn't 
>figure out where to insert the "debug 31" for diald.  Finally stuck it 
>in /etc/sysconfig/dialdcfg and I think that worked.  But I wasn't sure 
>which file used which syntax.

The README's are all there is, I'll add the following parenthetical
descriptions:

------------------------
  File Descriptions

High level configuration files (shell variable assignment syntax):

/etc/sysconfig/dialdcfg 
Default diald configuration file.  Any changes to this file apply to
all diald daemons.

/etc/sysconfig/network-scripts/dialdcfg-<iface> 
Configuration file for a specific interface.  There must be a
/etc/sysconfig/network-scripts/dialdcfg-<iface> for every interface
who's establishment is controlled by diald.  This file may contain any
or all of the variables allowed in /etc/sysconfig/dialdcfg, and vice
versa.  The interface specific variable values override the default
values.

<snip>

Low level configuration files (standard diald directive syntax):

/usr/lib/diald/diald.defs
--------------------------------------

Does this make it clear?

So, I don't think that your "debug 31" would have worked.


>Also, it's not clear to me why the new pppd is required (I actually did 
>a --nodeps install, so that might be my problem, too).  From the 
>updated pppd spec file change log, it appeared that the only changes 
>were Win95 support and the one duplicate lock in /etc/ppp/options 
>(which I removed by hand).  Since I don't care about win95, and I 
>noticed that RH has not included the changes in 5.0, I figured there 
>was no real reason to upgrade.

The changelog on pppd dosen't say so, but there's a necessary change
to chat.  Addition of the -s and -S command line options.  So that's
why your chat failed.  So long as the chat script is in the same place
as redhat's chat script, you shouldn't have a problem.  (Dosen't
matter if you maintain the chat script with the redhat tools.)
Likewise, tho you don't need to use the redhat config tools, the
redhat "shell variable assignments" for pppd need to be in the
expected place (as the readme says.)

And thanks also for the %attr report.

I don't believe that rpm --rebuild will correctly rebuild the binary
as a noarch rpm unless you also do a --buildarch noarch.  Is there a
fix for this you know of?

I've put diald-config-1.2 incorporating the fixes to your bugs out to
ftp://ftp.redhat.com/pub/incoming.  Let me know how you like it.  If
you don't have any more changes, I'll put it out to sunsite and the
lsm.  (For technical reasons at the moment it's easier to put it on
redhat's ftp site than on mine.  *ick*)

Karl

--_=XFMail.1.0.p0.Linux:980109003034:748=_
Content-Description: diald-up.patch
Content-Type: application/x-patch

--- diald-up.orig	Thu Jan  8 07:39:09 1998
+++ diald-up	Wed Jan  7 18:07:03 1998
@@ -43,7 +43,7 @@
   fi
   . network-functions
   source_config
-elif
+else
   if [ ! -f /etc/sysconfig/network-scripts/ifcfg-$IFACE ] ; then
     error "/etc/sysconfig/network-scripts/ifcfg-$IFACE does not exist"
   fi
@@ -51,7 +51,7 @@
 fi
 
 # Compatiblity support.
-if [ "${CONFPROG"} = "REDHAT" ] ; then
+if [ "${CONFPROG}" = "REDHAT" ] ; then
   if [ -z "${REMOTENAME}" ] ; then
     REMOTENAME="${DEVICE}"
   fi

--_=XFMail.1.0.p0.Linux:980109003034:748=_
Content-Type: text/plain; charset=us-ascii

Hal Wine <hal@dtor.com>				DTOR Consulting

--_=XFMail.1.0.p0.Linux:980109003034:748=_--
End of MIME message

From hal@dtor.com  Sun Jan 11 21:22:35 1998
Status: RO
Return-Path: <hal@dtor.com>
Received: from JustMe.dtor.com (dtor.com [206.14.4.240]) by arthur.meme.com
 (8.8.5/8.8.5) with ESMTP id MAA08043 for <kop@meme.com>;
 Fri, 9 Jan 1998 12:46:11 -0600
Received: from MyShadow.dtor.com (netcom11.netcom.com [192.100.81.121]) by
 JustMe.dtor.com (8.8.5/8.8.5) with ESMTP id KAA15532 for <kop@meme.com>;
 Fri, 9 Jan 1998 10:33:46 -0800
Received: from MyShadow.dtor.com (localhost [127.0.0.1]) by MyShadow.dtor.com
 (8.8.5/8.8.5) with ESMTP id KAA04260; Fri, 9 Jan 1998 10:28:00 -0800
Message-Id: <199801091828.KAA04260@MyShadow.dtor.com>
X-Mailer: exmh version 1.6.9 05/05/96
In-reply-to: Your message of "Thu,
 08 Jan 1998 23:01:07 CST." <XFMail.980109003034.kop@meme.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 09 Jan 1998 10:28:00 -0800
X-UIDL: bbc108f1f725cdd676d03d32d2bdbcf3
From: Hal Wine <hal@dtor.com>
To: "Karl O. Pinc" <kop@meme.com>
Subject: Re: ANNOUNCE: diald-config-1.1 -- demand dialing made easy

On Thu 1998-01-08 about 23:01 CST, "Karl O. Pinc"(<kop@meme.com>) wrote:
>This message is in MIME format
>--_=XFMail.1.0.p0.Linux:980109003034:748=_
>Content-Type: text/plain; charset=us-ascii
>
>
>Thanks.  Something wierd happened.  rpm tells me that diald-config-1.1
>is installed, but it's not.  So the 1.1 changes didn't get properly
>tested.  *poo*  Sorry about that.

Did you bump the sequence number between tests?  Or use --force for the 
2nd install?  That's what I usually forget...

>The README's are all there is, I'll add the following parenthetical
>descriptions:
>
>------------------------
>  File Descriptions
>
>High level configuration files (shell variable assignment syntax):
><snip>
>
>Low level configuration files (standard diald directive syntax):

>Does this make it clear?

Much clearer.  I'd only add (somewhere) that "high level" means 
"diald-config" and "low level" means "standard diald".  That might help 
when reading the diald documentation.

>>Also, it's not clear to me why the new pppd is required.
>The changelog on pppd dosen't say so, but there's a necessary change
>to chat.  Addition of the -s and -S command line options.  So that's
>why your chat failed.  So long as the chat script is in the same place
>as redhat's chat script, you shouldn't have a problem.

Personally, since they just released 5.0 with ppp 2.2.0f, I'd suggest 
only requiring 2.2.0f, and adding a note that if someone wants to move 
the chat script, they have to upgrade to 2.2.0g.

>I don't believe that rpm --rebuild will correctly rebuild the binary
>as a noarch rpm unless you also do a --buildarch noarch.  Is there a
>fix for this you know of?

Uhh, I've not done anything with noarch myself.  I vaguely recall some 
discussion of this on the redhat rpm-list.  You might want to search 
the archives for it.  I know I only got i386 versions on my system with 
--rebuild of the sources.

>
>I've put diald-config-1.2 incorporating the fixes to your bugs out to
>ftp://ftp.redhat.com/pub/incoming.  Let me know how you like it.  If
>you don't have any more changes, I'll put it out to sunsite and the
>lsm.  (For technical reasons at the moment it's easier to put it on
>redhat's ftp site than on mine.  *ick*)

I'll try them later today or Monday.
-- 
Hal Wine <hal@dtor.com>				DTOR Consulting

From hal@dtor.com  Sun Jan 11 21:22:36 1998
Status: RO
Return-Path: <hal@dtor.com>
Received: from JustMe.dtor.com (dtor.com [206.14.4.240]) by arthur.meme.com
 (8.8.5/8.8.5) with ESMTP id MAA08061 for <kop@meme.com>;
 Fri, 9 Jan 1998 12:53:25 -0600
Received: from MyShadow.dtor.com (netcom11.netcom.com [192.100.81.121]) by
 JustMe.dtor.com (8.8.5/8.8.5) with ESMTP id KAA15624 for <kop@meme.com>;
 Fri, 9 Jan 1998 10:40:59 -0800
Received: from MyShadow.dtor.com (localhost [127.0.0.1]) by MyShadow.dtor.com
 (8.8.5/8.8.5) with ESMTP id KAA04684; Fri, 9 Jan 1998 10:41:42 -0800
Message-Id: <199801091841.KAA04684@MyShadow.dtor.com>
X-Mailer: exmh version 1.6.9 05/05/96
In-reply-to: Your message of "Fri,
 09 Jan 1998 10:28:00 PST." <199801091828.KAA04260@MyShadow.dtor.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 09 Jan 1998 10:41:42 -0800
X-UIDL: f578e76fa9b621f02789a9d59aeab590
From: Hal Wine <hal@dtor.com>
Subject: Re: ANNOUNCE: diald-config-1.1 -- demand dialing made easy
Cc: "Karl O. Pinc" <kop@meme.com>

On Fri 1998-01-09 about 10:28 PST, Hal Wine(<hal@dtor.com>) wrote:
>On Thu 1998-01-08 about 23:01 CST, "Karl O. Pinc"(<kop@meme.com>) 
wrote:
>>I've put diald-config-1.2 incorporating the fixes to your bugs out to
>>ftp://ftp.redhat.com/pub/incoming.
>
>I'll try them later today or Monday.

I'll have to wait until Monday, unless you want to email them to me -- 
nothing in /pub/incoming is readable
-- 
Hal Wine <hal@dtor.com>				DTOR Consulting

From kop@meme.com  Sun Jan 11 21:57:32 1998
Status: RO
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199801091841.KAA04684@MyShadow.dtor.com>
Date: Sun, 11 Jan 1998 21:57:32 -0600 (CST)
From: "Karl O. Pinc" <kop@meme.com>
To: Hal Wine <hal@dtor.com>
Subject: Re: ANNOUNCE: diald-config-1.1 -- demand dialing made easy
Cc: vage <chris@cti-vision.demon.co.uk>


On 09-Jan-98 Hal Wine wrote:
>On Fri 1998-01-09 about 10:28 PST, Hal Wine(<hal@dtor.com>) wrote:
>>On Thu 1998-01-08 about 23:01 CST, "Karl O. Pinc"(<kop@meme.com>) 
>wrote:
>>>I've put diald-config-1.2 incorporating the fixes to your bugs out to
>>>ftp://ftp.redhat.com/pub/incoming.
>>
>>I'll try them later today or Monday.
>
>I'll have to wait until Monday, unless you want to email them to me -- 
>nothing in /pub/incoming is readable

I put it on my ftp site at:
ftp://ftp.meme.com/pub/software/diald-config

From kop@meme.com  Sun Jan 11 23:16:37 1998
Status: RO
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199801091828.KAA04260@MyShadow.dtor.com>
Date: Sun, 11 Jan 1998 23:16:37 -0600 (CST)
From: "Karl O. Pinc" <kop@meme.com>
To: Hal Wine <hal@dtor.com>
Subject: Re: ANNOUNCE: diald-config-1.1 -- demand dialing made easy


On 09-Jan-98 Hal Wine wrote:
>On Thu 1998-01-08 about 23:01 CST, "Karl O. Pinc"(<kop@meme.com>) wrote:
>>
>>
>>Thanks.  Something wierd happened.  rpm tells me that diald-config-1.1
>>is installed, but it's not.  So the 1.1 changes didn't get properly
>>tested.  *poo*  Sorry about that.
>
>Did you bump the sequence number between tests?  Or use --force for the 
>2nd install?  That's what I usually forget...

Nah.  I suspect something in the build process, maybe having to do
with --buildroot.

>>The README's are all there is, I'll add the following parenthetical
>>descriptions:
>>
<snip>
>>
>>Does this make it clear?
>
>Much clearer.  I'd only add (somewhere) that "high level" means 
>"diald-config" and "low level" means "standard diald".  That might help 
>when reading the diald documentation.

Hopefully, that's clear from the get go, 

---------<quote>-------------

INTRODUCTION

The purpose of this package is to make it easy to setup a system so
that it automatically connects to the net whenever needed and
disconnects when not needed.  Because "needed" is a relative term, to
meet this goal it must be easy to make changes to the system
configuration.  To that end, this package provides a high level
configuration system supporting diald, a "demand dialding daemon".
The system is driven from files which employ shell variable assignment
to configure diald -- set a variable to change a behavior.  Most users
will want configure diald by using only the high level configuration
files.  The low level configuration files contain diald configuration
directives as described in the diald man page.

--------<endquote>-------------

You think?

>
>>>Also, it's not clear to me why the new pppd is required.
>>The changelog on pppd dosen't say so, but there's a necessary change
>>to chat.  Addition of the -s and -S command line options.  So that's
>>why your chat failed.  So long as the chat script is in the same place
>>as redhat's chat script, you shouldn't have a problem.
>
>Personally, since they just released 5.0 with ppp 2.2.0f, I'd suggest 
>only requiring 2.2.0f, and adding a note that if someone wants to move 
>the chat script, they have to upgrade to 2.2.0g.

Except that it won't work unless the new chat is there.  (Although it
might be possible to get it to work with the old chat by turning off
chat logging and other chat monitoring in the high level config
statements.  But I'm not interested in figuring that out.)  If it's
going to "plug & play", which is the point, the new chat's gotta be
there.

>>I don't believe that rpm --rebuild will correctly rebuild the binary
>>as a noarch rpm unless you also do a --buildarch noarch.  Is there a
>>fix for this you know of?
>
>Uhh, I've not done anything with noarch myself.  I vaguely recall some 
>discussion of this on the redhat rpm-list.  You might want to search 
>the archives for it.  I know I only got i386 versions on my system with 
>--rebuild of the sources.

Actually, the binary's you produce will work on any architecture, its'
just that rpm dosn't advertise that they will, and maybe won't allow
installation or something.

Karl

From hal@dtor.com  Mon Jan 12 20:03:52 1998
Status: RO
Return-Path: <hal@dtor.com>
Received: from JustMe.dtor.com (dtor.com [206.14.4.240]) by arthur.meme.com
 (8.8.5/8.8.5) with ESMTP id KAA21911 for <kop@meme.com>;
 Mon, 12 Jan 1998 10:45:16 -0600
Received: from MyShadow.dtor.com (netcom3.netcom.com [192.100.81.103]) by
 JustMe.dtor.com (8.8.5/8.8.5) with ESMTP id IAA17557 for <kop@meme.com>;
 Mon, 12 Jan 1998 08:33:03 -0800
Received: from MyShadow.dtor.com (localhost [127.0.0.1]) by MyShadow.dtor.com
 (8.8.5/8.8.5) with ESMTP id IAA05189; Mon, 12 Jan 1998 08:07:32 -0800
Message-Id: <199801121607.IAA05189@MyShadow.dtor.com>
X-Mailer: exmh version 1.6.9 05/05/96
In-reply-to: Your message of "Sun,
 11 Jan 1998 23:16:37 CST." <XFMail.980111232559.kop@meme.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 12 Jan 1998 08:07:32 -0800
X-UIDL: 155d5d8d426991805cb4329283d00c46
From: Hal Wine <hal@dtor.com>
To: "Karl O. Pinc" <kop@meme.com>
Subject: Re: ANNOUNCE: diald-config-1.1 -- demand dialing made easy

On Sun 1998-01-11 about 23:16 CST, "Karl O. Pinc"(<kop@meme.com>) wrote:
>
>On 09-Jan-98 Hal Wine wrote:
>>Much clearer.  I'd only add (somewhere) that "high level" means 
>>"diald-config" and "low level" means "standard diald".  That might 
help
>>when reading the diald documentation.
>
>Hopefully, that's clear from the get go, 
>
>---------<quote>-------------
>--------<endquote>-------------
>
>You think?

Well, I missed it.  IMO, it's an important enough distinction not to be 
buried at the end of a paragraph.  Maybe something like:

Diald-config provides a high level configuration of diald using shell 
environment variables.  Diald-config should handle all of the 
configuration for most users, however users are still free to modify 
the standard diald config files (called "low level" configuration in 
this documentation) to handle exceptional cases.

>>>>Also, it's not clear to me why the new pppd is required.
>
>Except that it won't work unless the new chat is there.  (Although it
>might be possible to get it to work with the old chat by turning off
>chat logging and other chat monitoring in the high level config
>statements.  But I'm not interested in figuring that out.)  If it's
>going to "plug & play", which is the point, the new chat's gotta be
>there.

Got it.  Hmm, that'll delay my implementation for a while :-(

Thanks for your help
-- 
Hal Wine <hal@dtor.com>				DTOR Consulting

From kop@meme.com  Mon Jan 12 21:27:01 1998
Status: RO
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199801121607.IAA05189@MyShadow.dtor.com>
Date: Mon, 12 Jan 1998 21:27:01 -0600 (CST)
From: "Karl O. Pinc" <kop@meme.com>
To: Hal Wine <hal@dtor.com>
Subject: Re: ANNOUNCE: diald-config-1.1 -- demand dialing made easy


On 12-Jan-98 Hal Wine wrote:
>
>Well, I missed it.  IMO, it's an important enough distinction not to be 
>buried at the end of a paragraph.  Maybe something like:
>
>Diald-config provides a high level configuration of diald using shell 
>environment variables.  Diald-config should handle all of the 
>configuration for most users, however users are still free to modify 
>the standard diald config files (called "low level" configuration in 
>this documentation) to handle exceptional cases.

Well, I didn't want to, but you turned my brain on so I rewrote it.  Hows this?

--------------------------------
INTRODUCTION

The purpose of this package is to make it easy to setup a system so
that it automatically connects to the net whenever needed and
disconnects when not needed.  Because "needed" is a relative term, to
meet this goal it must be easy to make changes to the system
configuration.  To that end, this package provides a configuration
system supporting diald, a "demand dialding daemon".

Configuring diald is easy using diald-config's high level
configuration files.  The high level files have a syntax which looks
like variable assignment in shell -- set a variable to change a
behavior.  Most users will want configure diald using only the high
level configuration files.  To handle exceptional cases, the diald
configuration directives (described in the diald man page) can also be
used.  These should be placed in the low level configuration files.

>
>>>>>Also, it's not clear to me why the new pppd is required.
>>
>>Except that it won't work unless the new chat is there.  (Although it
>>might be possible to get it to work with the old chat by turning off
>>chat logging and other chat monitoring in the high level config
>>statements.  But I'm not interested in figuring that out.)  If it's
>>going to "plug & play", which is the point, the new chat's gotta be
>>there.
>
>Got it.  Hmm, that'll delay my implementation for a while :-(

Oh well.  If you felt like just wacking something together, you could just get
chat.c from the tar and recompile it.

Karl

From hal@dtor.com  Tue Jan 13 22:55:35 1998
Status: RO
Return-Path: <hal@dtor.com>
Received: from JustMe.dtor.com (dtor.com [206.14.4.240]) by arthur.meme.com
 (8.8.5/8.8.5) with ESMTP id MAA26858 for <kop@meme.com>;
 Tue, 13 Jan 1998 12:10:47 -0600
Received: from MyShadow.dtor.com (netcom5.netcom.com [192.100.81.113]) by
 JustMe.dtor.com (8.8.5/8.8.5) with ESMTP id JAA28438 for <kop@meme.com>;
 Tue, 13 Jan 1998 09:58:30 -0800
Received: from MyShadow.dtor.com (localhost [127.0.0.1]) by MyShadow.dtor.com
 (8.8.5/8.8.5) with ESMTP id JAA08160; Tue, 13 Jan 1998 09:58:29 -0800
Message-Id: <199801131758.JAA08160@MyShadow.dtor.com>
X-Mailer: exmh version 1.6.9 05/05/96
In-reply-to: Your message of "Mon,
 12 Jan 1998 21:27:01 CST." <XFMail.980112213056.kop@meme.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 13 Jan 1998 09:58:29 -0800
X-UIDL: 084f177a04d2377a1ee5120183ef85bf
From: Hal Wine <hal@dtor.com>
To: "Karl O. Pinc" <kop@meme.com>
Subject: Re: ANNOUNCE: diald-config-1.1 -- demand dialing made easy

On Mon 1998-01-12 about 21:27 CST, "Karl O. Pinc"(<kop@meme.com>) wrote:
>
>On 12-Jan-98 Hal Wine wrote:
>>
>>Well, I missed it.  IMO, it's an important enough distinction not to 
be
>>buried at the end of a paragraph. 

>Well, I didn't want to, but you turned my brain on so I rewrote it.  
Hows this
>?

Sorry about that :-)

I like the rewrite -- even folks like me can understand it!

>Oh well.  If you felt like just wacking something together, you could 
just get
>chat.c from the tar and recompile it.

Yah, but that's why I like RPM....  Maybe I'll package a pppd w/o the 
MS support but with the new chat.  Or maybe just the new chat as a 
seperate RPM. Sigh.

This process did finally motivate me to dig into (low level) diald, and 
I have that mostly running (had to turn off Samba to avoid constant 
connects -- gotta tweak various filter files to reject sending *those* 
over the internet...)

One question I have on diald vs. diald-config.  It looks to be fairly 
easy to modify diald's /etc/ppp/connect script to support dialing into 
multiple phone numbers.  It didn't look like diald-config supported 
that concept, though.

Do I have that right?
-- 
Hal Wine <hal@dtor.com>				DTOR Consulting

From kop@meme.com  Tue Jan 13 23:28:07 1998
Status: RO
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199801131758.JAA08160@MyShadow.dtor.com>
Date: Tue, 13 Jan 1998 23:28:07 -0600 (CST)
From: "Karl O. Pinc" <kop@meme.com>
To: Hal Wine <hal@dtor.com>
Subject: Re: ANNOUNCE: diald-config-1.1 -- demand dialing made easy
Bcc: kop@meme.com


On 13-Jan-98 Hal Wine wrote:
>
>I like the rewrite -- even folks like me can understand it!

Good.

>>Oh well.  If you felt like just wacking something together, you could 
>just get
>>chat.c from the tar and recompile it.
>
>Yah, but that's why I like RPM....  Maybe I'll package a pppd w/o the 
>MS support but with the new chat.  Or maybe just the new chat as a 
>seperate RPM. Sigh.

Yeah.


>This process did finally motivate me to dig into (low level) diald, and 
>I have that mostly running (had to turn off Samba to avoid constant 
>connects -- gotta tweak various filter files to reject sending *those* 
>over the internet...)

There's a diald-config variable (defaults to off I think -- don't
netbui with the world :-).

>One question I have on diald vs. diald-config.  It looks to be fairly 
>easy to modify diald's /etc/ppp/connect script to support dialing into 
>multiple phone numbers.  It didn't look like diald-config supported 
>that concept, though.
>
>Do I have that right?

No and yes, depending on whether you want to support multiple phone
numbers on multiple interfaces (easy) or in just what way you want to
support multiple numbers per interface.  diald-config is not as
flexable as shell scripting.  For simple "dial this number and not
that" stuff it's easist to just change the phone number by hand as to
configure any other way.  You could mess around with, for instance,
the "clone" config files to have multiple phone numbers per interface,
but on what basis would you want to choose one phone number (or
interface) over another?  Route is the the selection critera that
comes to my mind and is supported by diald-config.  What it comes down
to is diald-config only supports one dial-out chat script per route,
and you've only one default route so...  The chat script would support
fallback numbers on the same route.  diald-config really relys on the
design of the redhat PPP config tool (to maintain compatability) for
it's phone and ppp related config, and is only as good as that design.
If you need to go to phone number rotation on a single route you'll
have to decend to the diald directives & the low level files and it
may not be doable as diald-config already uses the diald config
directive that controls this.  Likewise, selection of phone number on
the basis of protocol, interface rotation on a single route, or
similar hackery, can be done but would require the low level files.
diald's good at that sort of stuff and I saw no way to make it
simpler.

So, diald-config directly supports automatic remote site and/or
dialout interface selection on the basis of route, and provides a
framework driven by global route and global interface settings with
local per-route/interface pair overrides in which the standard diald
configuration directives can be placed to support other configurations
of multiple remote sites and dial-out interfaces.  Diald-config
supports multiple diald deamons, which are activated by packets
following specific routes.  Each daemon is associated by default with
a single (not necessarily unique) interface/interface alias, and also
by default is associated with a single (again not necessairly unique)
chat script for accessing some remote site.  Overriding these defaults
requires association of standard diald directives with deamons
and/orinterfaces.  To make multiple interfaces act as a single
interface, for example, you'd associate diald "device" directives with
an interface.  (I see a limitation in the current version in that
diald directives can only be associated with real interfaces, not
interface ailases so this sort of thing is all-or-nothing per real
interface.)  If you wish to ensure compatabiltiy with the Redhat
configuration tools, your configuration will have to retain a one to
one relation between interfaces and chat scripts.

Overrriding of previously supplied diald directives is not defined in
diald and so not all diald directives can be associated with
interfaces or routes.  Which are usable and which arn't are not
documented by me, a deficency that I don't see a good remidy for as
I'd like to reserve the right to use any of them in the future.  So,
for example, because diald-config uses the diald "connect" directive,
it may or may not be possible to decide to override this and use your
own "connect" script to establish a connection; and so may not be able
to associate multiple chat scripts with a route or interface.  Depends
on diald's undocumented behavior.  Even if there is documented
behavior for repeating a diald directive, there is still a problem
because diald-config generated directives would then override the
"gobal" diald directives in /etc/diald.conf so this file would not
support _any_ diald directive, just the ones not used by diald-config.

Wonder if I need to support diald directives on a per-interface-alias
basis.

I had in mind the redhat configuration tool user when I wrote
diald-config, so the redhat "high-level" config files are not listed
with the "high level" diald config files.  Think this is a problem?

See any documentation flaws in this conversation?  Comments?

*whew*

Karl

From kop@meme.com  Wed Jan 14 11:47:54 1998
Status: O
Return-Path: <kop@meme.com>
Received: from frog.meme.com (d115.loop2.interaccess.com [207.70.96.115]) by
 arthur.meme.com (8.8.5/8.8.5) with SMTP id BAA30025;
 Wed, 14 Jan 1998 01:58:30 -0600
Message-ID: <XFMail.980114012743.kop@meme.com>
X-Mailer: XFMail 1.0 [p0] on Linux
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199801131758.JAA08160@MyShadow.dtor.com>
Date: Tue, 13 Jan 1998 23:28:07 -0600 (CST)
X-UIDL: ca298ee06f52c4db1f4d45cdc5571e16
Sender: kop@meme.com
From: "Karl O. Pinc" <kop@meme.com>
To: Hal Wine <hal@dtor.com>
Subject: Re: ANNOUNCE: diald-config-1.1 -- demand dialing made easy


On 13-Jan-98 Hal Wine wrote:
>
>I like the rewrite -- even folks like me can understand it!

Good.

>>Oh well.  If you felt like just wacking something together, you could 
>just get
>>chat.c from the tar and recompile it.
>
>Yah, but that's why I like RPM....  Maybe I'll package a pppd w/o the 
>MS support but with the new chat.  Or maybe just the new chat as a 
>seperate RPM. Sigh.

Yeah.


>This process did finally motivate me to dig into (low level) diald, and 
>I have that mostly running (had to turn off Samba to avoid constant 
>connects -- gotta tweak various filter files to reject sending *those* 
>over the internet...)

There's a diald-config variable (defaults to off I think -- don't
netbui with the world :-).

>One question I have on diald vs. diald-config.  It looks to be fairly 
>easy to modify diald's /etc/ppp/connect script to support dialing into 
>multiple phone numbers.  It didn't look like diald-config supported 
>that concept, though.
>
>Do I have that right?

No and yes, depending on whether you want to support multiple phone
numbers on multiple interfaces (easy) or in just what way you want to
support multiple numbers per interface.  diald-config is not as
flexable as shell scripting.  For simple "dial this number and not
that" stuff it's easist to just change the phone number by hand as to
configure any other way.  You could mess around with, for instance,
the "clone" config files to have multiple phone numbers per interface,
but on what basis would you want to choose one phone number (or
interface) over another?  Route is the the selection critera that
comes to my mind and is supported by diald-config.  What it comes down
to is diald-config only supports one dial-out chat script per route,
and you've only one default route so...  The chat script would support
fallback numbers on the same route.  diald-config really relys on the
design of the redhat PPP config tool (to maintain compatability) for
it's phone and ppp related config, and is only as good as that design.
If you need to go to phone number rotation on a single route you'll
have to decend to the diald directives & the low level files and it
may not be doable as diald-config already uses the diald config
directive that controls this.  Likewise, selection of phone number on
the basis of protocol, interface rotation on a single route, or
similar hackery, can be done but would require the low level files.
diald's good at that sort of stuff and I saw no way to make it
simpler.

So, diald-config directly supports automatic remote site and/or
dialout interface selection on the basis of route, and provides a
framework driven by global route and global interface settings with
local per-route/interface pair overrides in which the standard diald
configuration directives can be placed to support other configurations
of multiple remote sites and dial-out interfaces.  Diald-config
supports multiple diald deamons, which are activated by packets
following specific routes.  Each daemon is associated by default with
a single (not necessarily unique) interface/interface alias, and also
by default is associated with a single (again not necessairly unique)
chat script for accessing some remote site.  Overriding these defaults
requires association of standard diald directives with deamons
and/orinterfaces.  To make multiple interfaces act as a single
interface, for example, you'd associate diald "device" directives with
an interface.  (I see a limitation in the current version in that
diald directives can only be associated with real interfaces, not
interface ailases so this sort of thing is all-or-nothing per real
interface.)  If you wish to ensure compatabiltiy with the Redhat
configuration tools, your configuration will have to retain a one to
one relation between interfaces and chat scripts.

Overrriding of previously supplied diald directives is not defined in
diald and so not all diald directives can be associated with
interfaces or routes.  Which are usable and which arn't are not
documented by me, a deficency that I don't see a good remidy for as
I'd like to reserve the right to use any of them in the future.  So,
for example, because diald-config uses the diald "connect" directive,
it may or may not be possible to decide to override this and use your
own "connect" script to establish a connection; and so may not be able
to associate multiple chat scripts with a route or interface.  Depends
on diald's undocumented behavior.  Even if there is documented
behavior for repeating a diald directive, there is still a problem
because diald-config generated directives would then override the
"gobal" diald directives in /etc/diald.conf so this file would not
support _any_ diald directive, just the ones not used by diald-config.

Wonder if I need to support diald directives on a per-interface-alias
basis.

I had in mind the redhat configuration tool user when I wrote
diald-config, so the redhat "high-level" config files are not listed
with the "high level" diald config files.  Think this is a problem?

See any documentation flaws in this conversation?  Comments?

*whew*

Karl

From hal@dtor.com  Wed Jan 14 11:49:23 1998
Status: RO
Return-Path: <hal@dtor.com>
Received: from JustMe.dtor.com (dtor.com [206.14.4.240]) by arthur.meme.com
 (8.8.5/8.8.5) with ESMTP id MAA31707 for <kop@meme.com>;
 Wed, 14 Jan 1998 12:17:48 -0600
Received: from MyShadow.dtor.com (netcom3.netcom.com [192.100.81.103]) by
 JustMe.dtor.com (8.8.5/8.8.5) with ESMTP id KAA06303 for <kop@meme.com>;
 Wed, 14 Jan 1998 10:05:36 -0800
Received: from MyShadow.dtor.com (localhost [127.0.0.1]) by MyShadow.dtor.com
 (8.8.5/8.8.5) with ESMTP id JAA04229; Wed, 14 Jan 1998 09:37:46 -0800
Message-Id: <199801141737.JAA04229@MyShadow.dtor.com>
X-Mailer: exmh version 1.6.9 05/05/96
In-reply-to: Your message of "Tue,
 13 Jan 1998 23:28:07 CST." <XFMail.980114012743.kop@meme.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 14 Jan 1998 09:37:46 -0800
X-UIDL: f510bec045806ba4e59e72415843150b
From: Hal Wine <hal@dtor.com>
To: "Karl O. Pinc" <kop@meme.com>
Subject: Re: ANNOUNCE: diald-config-1.1 -- demand dialing made easy

On Tue 1998-01-13 about 23:28 CST, "Karl O. Pinc"(<kop@meme.com>) wrote:
>
>On 13-Jan-98 Hal Wine wrote:
>>This process did finally motivate me to dig into (low level) diald, 
and
>>I have that mostly running (had to turn off Samba to avoid constant 
>>connects -- gotta tweak various filter files to reject sending 
*those*
>>over the internet...)
>
>There's a diald-config variable (defaults to off I think -- don't
>netbui with the world :-).

Well, it keeps the link from coming up, but doesn't prevent NETBIOS 
traffic once the link is up.  That's what I need to prevent.

>
>>One question I have on diald vs. diald-config.  It looks to be fairly 
>>easy to modify diald's /etc/ppp/connect script to support dialing 
into
>>multiple phone numbers.  It didn't look like diald-config supported 
>>that concept, though.
>>
>>Do I have that right?
>
>No and yes, depending on whether you want to support multiple phone
>numbers on multiple interfaces (easy) or in just what way you want to
>support multiple numbers per interface.

Hmm, very interesting description.  I wish RedHat documented their 
interface strategy more thourougly, especially for those  of use who 
don't use the gui tools!  It sounds like they've made it very difficult 
to handle traveling laptops.

What I want is something as simple as the Mac gives me (which is better 
than what Win95 gives me).  As a user, I set (in one place) my current 
location (home, work, Boston, Houston), and I set the service (actually 
POP) I want to connect to (ISP1-SanJose, ISP2-Boston, company intranet, 
etc.).  After that, everything works!

And by everything, I mean everything: phone numbers are properly dialed 
(access codes, area codes, etc.), the proper DNS is used, proper local 
IP number, proper proxy server addresses and types, etc..  Each service 
can have a series of phone numbers to try (not everyone has hunt groups 
set up properly on their inbound lines).  (The proxy/tcp settings do 
take some extra work on both Mac and Win, but different work :-(....)

Yah, I'm dreaming, but you gotta have goals....

> Wonder if I need to support diald directives on a per-interface-alias 
> basis.

That'd be nice, if I understood things correctly.  Then I could set up 
the alternate numbers as seperate aliases, then let diald rotate 
devices.  (Of course, locking needs to occur on the physical interface.)

> I had in mind the redhat configuration tool user when I wrote 
> diald-config, so the redhat "high-level" config files are not listed 
> with the "high level" diald config files.  Think this is a problem?

Only for folks who want to tweak things beyond the current limits.  
Actually, it seems like you understand, and presented, the RedHat PPP 
"structure" better than they do!  That sort of information as a 
seperate "README" would be a great help to those of us that need to 
break those boundaries....

(Ain't it grand that "rpm -qd netcfg" is empty?)

> See any documentation flaws in this conversation?  Comments?
> *whew* 

I agree!  It's always tough to set the scope of a wrapper program.  If 
you build in all the framework to allow local config without 
constraining your future development (i.e. to ensure backward 
compatibility), you end up with something so long in development that 
it doesn't see the light of day!

Unless you really want to migrate diald-config in the direction of 
supporting many of the features not present in the RedHat setup, I'd 
just say "caveat emptor" to anyone (like me) who wants to muck around 
with such wierdnesses....
-- 
Hal Wine <hal@dtor.com>				DTOR Consulting

From kop@meme.com  Wed Jan 14 11:58:11 1998
Status: RO
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199801141737.JAA04229@MyShadow.dtor.com>
Date: Wed, 14 Jan 1998 11:58:11 -0600 (CST)
From: "Karl O. Pinc" <kop@meme.com>
To: Hal Wine <hal@dtor.com>
Subject: Re: ANNOUNCE: diald-config-1.1 -- demand dialing made easy
Bcc: kop@meme.com


On 14-Jan-98 Hal Wine wrote:
>On Tue 1998-01-13 about 23:28 CST, "Karl O. Pinc"(<kop@meme.com>) wrote:
>>
>>On 13-Jan-98 Hal Wine wrote:
>>
>>There's a diald-config variable (defaults to off I think -- don't
>>netbui with the world :-).
>
>Well, it keeps the link from coming up, but doesn't prevent NETBIOS 
>traffic once the link is up.  That's what I need to prevent.

Ah, yes.  Quite right.  It would be a routing issue.  Can netbui even
_have_ configured routing?

>>
>>>One question I have on diald vs. diald-config.  It looks to be fairly 
>>>easy to modify diald's /etc/ppp/connect script to support dialing 
>into
>>>multiple phone numbers.  It didn't look like diald-config supported 
>>>that concept, though.
>>>
>>>Do I have that right?
>>
>>No and yes, depending on whether you want to support multiple phone
>>numbers on multiple interfaces (easy) or in just what way you want to
>>support multiple numbers per interface.
>
>Hmm, very interesting description.  

Yeah, that's what I thought after I wrote it; as in, nobody's gonnna
be able to understand this description.

>I wish RedHat documented their 
>interface strategy more thourougly, especially for those  of use who 
>don't use the gui tools!  It sounds like they've made it very difficult 
>to handle traveling laptops.

I've been thinking that diald-config needs an entity relationship
diagram to document what amounts to its configuration database.

>What I want is something as simple as the Mac gives me (which is better 
>than what Win95 gives me).  As a user, I set (in one place) my current 
>location (home, work, Boston, Houston), and I set the service (actually 
>POP) I want to connect to (ISP1-SanJose, ISP2-Boston, company intranet, 
>etc.).  After that, everything works!

>And by everything, I mean everything: phone numbers are properly dialed 
>(access codes, area codes, etc.), the proper DNS is used, proper local 
>IP number, proper proxy server addresses and types, etc..  Each service 
>can have a series of phone numbers to try (not everyone has hunt groups 
>set up properly on their inbound lines).  (The proxy/tcp settings do 
>take some extra work on both Mac and Win, but different work :-(....)
>
>Yah, I'm dreaming, but you gotta have goals....

Lessie...  Sounds like you've only got one interface, and one route
(the default).  diald-config should be able to take care of the
connection part.  Set up separate "clones" of your one interface, one
for each home/remote combo (weak, I know.)  Then switch between these
manually by changing the diald CLONE variable.  This takes care of the
ip connection; route, ip number, dialing in, etc.  Chat scripts can do
fallback numbers for no answers, but can't test for anything above
detection of modem carrier (weak again).  To take care of server
configuration, dns, proxy, whatever, the clones would have to set the
IPPARM variable and your /etc/ppp/ip-up script would look at this
value to set up the servers.

>> Wonder if I need to support diald directives on a per-interface-alias 
>> basis.
>
>That'd be nice, if I understood things correctly.  Then I could set up 
>the alternate numbers as seperate aliases, then let diald rotate 
>devices.  (Of course, locking needs to occur on the physical interface.)

There's locking, but the problem is that the same connection script
would be used for each device anyhow.  You can't tell diald to rotate
connection scripts and the diald-config diald-connect script dosen't
rotate scripts.  I think that's the place where it should be done.

>> I had in mind the redhat configuration tool user when I wrote 
>> diald-config, so the redhat "high-level" config files are not listed 
>> with the "high level" diald config files.  Think this is a problem?
>
>Only for folks who want to tweak things beyond the current limits.  
>Actually, it seems like you understand, and presented, the RedHat PPP 
>"structure" better than they do!  That sort of information as a 
>seperate "README" would be a great help to those of us that need to 
>break those boundaries....

Configuration directives need to be slotted into catagories that
correspond directly to real world objects; the database should model
the application domain.  The Mac does this, but is limited in that
there's no provision for more than one interface or anything other
than a default route.  I know what the design should be, but damm if
I've time to implement it.  If somebody else would do it, I'd give
them the design.  I gave one to Redhat quite a while ago.

If you think I've got a good presentation of RedHat ppp buried
somewhere in these writings I'd be happy to submit it somewhere.  But
it all sort of blurs together for me right now, I'd want you to pick
out the goodies for me first.

>(Ain't it grand that "rpm -qd netcfg" is empty?

The code is clean (ish) and it's not really hard to see what's what at
any particular spot.  The documentation of the design is missing so
there's no overview.  The design is good up through beginning dialup,
it's just advanced dynamic connection management is completely
missing.  A good start.

>> See any documentation flaws in this conversation?  Comments?
>> *whew* 
>
>I agree!  It's always tough to set the scope of a wrapper program.  If 
>you build in all the framework to allow local config without 
>constraining your future development (i.e. to ensure backward 
>compatibility), you end up with something so long in development that 
>it doesn't see the light of day!
>
>Unless you really want to migrate diald-config in the direction of 
>supporting many of the features not present in the RedHat setup, I'd 
>just say "caveat emptor" to anyone (like me) who wants to muck around 
>with such wierdnesses....

I've pretty much decided that I don't have the time to do any more
development.  I was talked into doing a GUI based on Gile (scheme) by
the GNU people to support the config, so I'll get around to that.
It's 'cause I love scheme.  The only language that's better is haskell,
and that dosen't really run yet.

From kop@meme.com  Wed Jan 14 13:02:50 1998
Status: O
Return-Path: <kop@meme.com>
Received: from frog.meme.com (d53.loop3.interaccess.com [207.70.97.53]) by
 arthur.meme.com (8.8.5/8.8.5) with SMTP id NAA31960;
 Wed, 14 Jan 1998 13:32:26 -0600
Message-ID: <XFMail.980114130131.kop@meme.com>
X-Mailer: XFMail 1.0 [p0] on Linux
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199801141737.JAA04229@MyShadow.dtor.com>
Date: Wed, 14 Jan 1998 11:58:11 -0600 (CST)
X-UIDL: ae498082114397d72e14a9d93193ad5f
Sender: kop@meme.com
From: "Karl O. Pinc" <kop@meme.com>
To: Hal Wine <hal@dtor.com>
Subject: Re: ANNOUNCE: diald-config-1.1 -- demand dialing made easy


On 14-Jan-98 Hal Wine wrote:
>On Tue 1998-01-13 about 23:28 CST, "Karl O. Pinc"(<kop@meme.com>) wrote:
>>
>>On 13-Jan-98 Hal Wine wrote:
>>
>>There's a diald-config variable (defaults to off I think -- don't
>>netbui with the world :-).
>
>Well, it keeps the link from coming up, but doesn't prevent NETBIOS 
>traffic once the link is up.  That's what I need to prevent.

Ah, yes.  Quite right.  It would be a routing issue.  Can netbui even
_have_ configured routing?

>>
>>>One question I have on diald vs. diald-config.  It looks to be fairly 
>>>easy to modify diald's /etc/ppp/connect script to support dialing 
>into
>>>multiple phone numbers.  It didn't look like diald-config supported 
>>>that concept, though.
>>>
>>>Do I have that right?
>>
>>No and yes, depending on whether you want to support multiple phone
>>numbers on multiple interfaces (easy) or in just what way you want to
>>support multiple numbers per interface.
>
>Hmm, very interesting description.  

Yeah, that's what I thought after I wrote it; as in, nobody's gonnna
be able to understand this description.

>I wish RedHat documented their 
>interface strategy more thourougly, especially for those  of use who 
>don't use the gui tools!  It sounds like they've made it very difficult 
>to handle traveling laptops.

I've been thinking that diald-config needs an entity relationship
diagram to document what amounts to its configuration database.

>What I want is something as simple as the Mac gives me (which is better 
>than what Win95 gives me).  As a user, I set (in one place) my current 
>location (home, work, Boston, Houston), and I set the service (actually 
>POP) I want to connect to (ISP1-SanJose, ISP2-Boston, company intranet, 
>etc.).  After that, everything works!

>And by everything, I mean everything: phone numbers are properly dialed 
>(access codes, area codes, etc.), the proper DNS is used, proper local 
>IP number, proper proxy server addresses and types, etc..  Each service 
>can have a series of phone numbers to try (not everyone has hunt groups 
>set up properly on their inbound lines).  (The proxy/tcp settings do 
>take some extra work on both Mac and Win, but different work :-(....)
>
>Yah, I'm dreaming, but you gotta have goals....

Lessie...  Sounds like you've only got one interface, and one route
(the default).  diald-config should be able to take care of the
connection part.  Set up separate "clones" of your one interface, one
for each home/remote combo (weak, I know.)  Then switch between these
manually by changing the diald CLONE variable.  This takes care of the
ip connection; route, ip number, dialing in, etc.  Chat scripts can do
fallback numbers for no answers, but can't test for anything above
detection of modem carrier (weak again).  To take care of server
configuration, dns, proxy, whatever, the clones would have to set the
IPPARM variable and your /etc/ppp/ip-up script would look at this
value to set up the servers.

>> Wonder if I need to support diald directives on a per-interface-alias 
>> basis.
>
>That'd be nice, if I understood things correctly.  Then I could set up 
>the alternate numbers as seperate aliases, then let diald rotate 
>devices.  (Of course, locking needs to occur on the physical interface.)

There's locking, but the problem is that the same connection script
would be used for each device anyhow.  You can't tell diald to rotate
connection scripts and the diald-config diald-connect script dosen't
rotate scripts.  I think that's the place where it should be done.

>> I had in mind the redhat configuration tool user when I wrote 
>> diald-config, so the redhat "high-level" config files are not listed 
>> with the "high level" diald config files.  Think this is a problem?
>
>Only for folks who want to tweak things beyond the current limits.  
>Actually, it seems like you understand, and presented, the RedHat PPP 
>"structure" better than they do!  That sort of information as a 
>seperate "README" would be a great help to those of us that need to 
>break those boundaries....

Configuration directives need to be slotted into catagories that
correspond directly to real world objects; the database should model
the application domain.  The Mac does this, but is limited in that
there's no provision for more than one interface or anything other
than a default route.  I know what the design should be, but damm if
I've time to implement it.  If somebody else would do it, I'd give
them the design.  I gave one to Redhat quite a while ago.

If you think I've got a good presentation of RedHat ppp buried
somewhere in these writings I'd be happy to submit it somewhere.  But
it all sort of blurs together for me right now, I'd want you to pick
out the goodies for me first.

>(Ain't it grand that "rpm -qd netcfg" is empty?

The code is clean (ish) and it's not really hard to see what's what at
any particular spot.  The documentation of the design is missing so
there's no overview.  The design is good up through beginning dialup,
it's just advanced dynamic connection management is completely
missing.  A good start.

>> See any documentation flaws in this conversation?  Comments?
>> *whew* 
>
>I agree!  It's always tough to set the scope of a wrapper program.  If 
>you build in all the framework to allow local config without 
>constraining your future development (i.e. to ensure backward 
>compatibility), you end up with something so long in development that 
>it doesn't see the light of day!
>
>Unless you really want to migrate diald-config in the direction of 
>supporting many of the features not present in the RedHat setup, I'd 
>just say "caveat emptor" to anyone (like me) who wants to muck around 
>with such wierdnesses....

I've pretty much decided that I don't have the time to do any more
development.  I was talked into doing a GUI based on Gile (scheme) by
the GNU people to support the config, so I'll get around to that.
It's 'cause I love scheme.  The only language that's better is haskell,
and that dosen't really run yet.

From paleface@netserf.rhk.dk  Tue Jan 13 22:55:59 1998
Status: RO
Return-Path: <paleface@netserf.rhk.dk>
Received: from farside.rhk.dk (farside.rhk.dk [195.41.67.5]) by arthur.meme.com
 (8.8.5/8.8.5) with ESMTP id PAA27461 for <kop@meme.com>;
 Tue, 13 Jan 1998 15:48:42 -0600
Received: from netserf.rhk.dk (ns.rhk.dk [195.41.67.2]) by farside.rhk.dk
 (8.8.5/8.8.5) with ESMTP id WAA15776 for <kop@meme.com>;
 Tue, 13 Jan 1998 22:37:39 +0100
Received: from localhost (paleface@localhost) by netserf.rhk.dk (8.8.5/8.8.5)
 with SMTP id XAA25223 for <kop@meme.com>; Tue, 13 Jan 1998 23:36:24 +0100
Date: Tue, 13 Jan 1998 23:36:23 +0100 (MET)
Message-ID: <Pine.LNX.3.95.980113233025.25124A-100000@netserf.rhk.dk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: d55bc99e372817f6b1c80569891300a5
From: Jacob Gorm Hansen <paleface@netserf.rhk.dk>
To: kop@meme.com
Subject: Problems with diald-config on RH5.0


Hi,

I have been trying to install diald, diald-config on a brand new Redhat5
system. I have some problems with the script diald-up. /bin/sh says it has
syntax errors on line 51 and 276 (at the end). I can patch my way out of
'51 since I just go for redhat-5, but the other one I can't figure. seems
to be a problem with the elif?? (not much of a scripting man myself).

By the way, does ppp-2.2.0g really need to be installed as the RPM says??
I can't find an upgrade for it anywhere, except the 2.3 versions that
demand a 2.1 kernel.

best regards,
Jacob Gorm Hansen

From kop@meme.com  Tue Jan 13 23:04:57 1998
Status: RO
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.LNX.3.95.980113233025.25124A-100000@netserf.rhk.dk>
Date: Tue, 13 Jan 1998 23:04:57 -0600 (CST)
From: "Karl O. Pinc" <kop@meme.com>
To: Jacob Gorm Hansen <paleface@netserf.rhk.dk>
Subject: RE: Problems with diald-config on RH5.0


On 13-Jan-98 Jacob Gorm Hansen wrote:
>
>Hi,
>
>I have been trying to install diald, diald-config on a brand new Redhat5
>system. I have some problems with the script diald-up. /bin/sh says it has
>syntax errors on line 51 and 276 (at the end). I can patch my way out of
>'51 since I just go for redhat-5, but the other one I can't figure. seems
>to be a problem with the elif?? (not much of a scripting man myself).

Yes, 2 egris bugs slipped out.  Sorry.  There's a new version on my ftp site
ftp://ftp.meme.com/pub/software/diald-config/diald-config-1.2.* and at Redhat,
tho not accessable at Redhat yet last time I looked. I've not announced it yet.

>
>By the way, does ppp-2.2.0g really need to be installed as the RPM says??

Yes.

>I can't find an upgrade for it anywhere, except the 2.3 versions that
>demand a 2.1 kernel.

I posted pppd-2.2.0g for a 2.0 kernel, but people have since added to it. 
Maybe do a "rpm --rebuild pppd-2.2.*.src.rpm" to get a 2.0 kernel binary and
then install that?

Please let me know what you think.  I've been waiting for some feedback before
announcing the new version to be sure that no more bugs are lurking.

From xmm@ugai.kcn.ru  Thu Jan 15 12:24:13 1998
Status: RO
Return-Path: <xmm@ugai.kcn.ru>
Received: from xoxma.ugai.kcn.ru ([195.12.32.110]) by arthur.meme.com
 (8.8.5/8.8.5) with ESMTP id XAA00872 for <kop@meme.com>;
 Wed, 14 Jan 1998 23:28:45 -0600
Received: (from xmm@localhost) by xoxma.ugai.kcn.ru (8.8.8/8.8.8) id IAA07814;
 Thu, 15 Jan 1998 08:16:57 +0300
Date: 15 Jan 1998 08:16:52 +0300
Message-ID: <rn67nmb9kr.fsf@xoxma.ugai.kcn.ru>
Lines: 12
X-Mailer: Gnus v5.3/Emacs 19.34
X-UIDL: 6841fcc2a374633148af3644bfcc7135
From: (Marat M. Khairullin) <xmm@ugai.kcn.ru>
To: "Karl O. Pinc" <kop@meme.com>
Subject: diald reject pap authentication
Cc: linux-admin@vger.rutgers.edu


Hi,

I try use diald-0.16.4-1 and diald-config-0.1-1 packages on RedHat-4.2
but diald reject pap authentication and disconnect.
What i must do?

pppd[6263]: rcvd [LCP ConfReq id=0x91 <asyncmap 0xa0000> <auth pap> <magic 0x475bcc8> <pcomp> < 0b 04 07 00>]
pppd[6263]: sent [LCP ConfRej id=0x91 <auth pap> < 0b 04 07 00>]

-- 
Marat Khairullin	8->	mailto:xmm@ugai.kcn.ru

From kop@meme.com  Thu Jan 15 13:06:12 1998
Status: RO
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <rn67nmb9kr.fsf@xoxma.ugai.kcn.ru>
Date: Thu, 15 Jan 1998 13:06:12 -0600 (CST)
From: "Karl O. Pinc" <kop@meme.com>
To: (Marat M. Khairullin) <xmm@ugai.kcn.ru>
Subject: RE: diald reject pap authentication
Cc: linux-admin@vger.rutgers.edu


On 15-Jan-98 Marat M. Khairullin wrote:
>
>Hi,
>
>I try use diald-0.16.4-1 and diald-config-0.1-1 packages on RedHat-4.2
>but diald reject pap authentication and disconnect.
>What i must do?
>
>pppd[6263]: rcvd [LCP ConfReq id=0x91 <asyncmap 0xa0000> <auth pap> <magic
0x475bcc8> <pcomp> < 0b 04 07 00>]
>pppd[6263]: sent [LCP ConfRej id=0x91 <auth pap> < 0b 04 07 00>]

diald-config-0.1 was a alpha release.  Try the latest release,
diald-config-1.2.  Available at ftp.meme.com/pub/software/diald-config & soon
to be available at ftp.redhat.com/pub/contrib/noarch

From xmm@ugai.kcn.ru  Fri Jan 16 22:59:48 1998
Status: RO
Return-Path: <xmm@ugai.kcn.ru>
Received: from xoxma.ugai.kcn.ru ([195.12.32.110]) by arthur.meme.com
 (8.8.5/8.8.5) with ESMTP id SAA09757 for <kop@meme.com>;
 Fri, 16 Jan 1998 18:36:30 -0600
Received: (from xmm@localhost) by xoxma.ugai.kcn.ru (8.8.8/8.8.8) id DAA10943;
 Sat, 17 Jan 1998 03:25:50 +0300
References: <XFMail.980115131158.kop@meme.com>
Date: 17 Jan 1998 03:25:45 +0300
In-Reply-To: "Karl O. Pinc"'s message of Thu, 15 Jan 1998 13:06:12 -0600 (CST)
Message-ID: <rnzpkw0wvq.fsf@xoxma.ugai.kcn.ru>
Lines: 62
X-Mailer: Gnus v5.3/Emacs 19.34
X-UIDL: 29928dfd6bef82679ffde4bac3591ad8
From: (Marat M. Khairullin) <xmm@ugai.kcn.ru>
To: "Karl O. Pinc" <kop@meme.com>
Subject: Re: diald reject pap authentication

"Karl O. Pinc" <kop@meme.com> writes:

> 
> diald-config-0.1 was a alpha release.  Try the latest release,
> diald-config-1.2.  Available at ftp.meme.com/pub/software/diald-config & soon
> to be available at ftp.redhat.com/pub/contrib/noarch
> 

Hi Karl,

I have installed diald-config-1.2 and diald-config-metered-0.2 packages.
In ifcfg-ppp0 I defined REMIP and IPADDR:

REMIP=195.12.32.48
IPADDR=195.12.32.110	<- I want use that address for connecting to ISP (for smtp)

pppd use my local eth0 address, but not IPADDR !

pppd[5104]: pppd 2.2.0 started by root, uid 0
pppd[5104]: Connect: ppp0 <--> /dev/ttyS1
pppd[5104]: local  IP address 195.0.0.7
pppd[5104]: remote IP address 195.12.33.48

I try to uncomment NOIPDEFAULT=yes in dialdcfg :

pppd[5123]: Connect: ppp0 <--> /dev/ttyS1
pppd[5123]: local  IP address 195.12.32.182	<- came from ISP
pppd[5123]: remote IP address 195.12.33.48

And second problem:
My ISP have two dial in server with two ip address 195.12.33.48 and 195.12.32.33,
therefore I can't use REMIP.
To solve this problem I insert few line in diald-up:

cd /etc/sysconfig/network-scripts/
diff -c /etc/sysconfig/network-scripts/diald-up /etc/sysconfig/network-scripts/diald-up.old
*** /etc/sysconfig/network-scripts/diald-up	Sat Jan 17 02:07:18 1998
--- /etc/sysconfig/network-scripts/diald-up.old	Sat Jan 17 02:59:47 1998
***************
*** 216,224 ****
  if [ -z "${REMIP}" ] ; then
    pppopts="$pppopts ipcp-accept-remote"
  fi
- if [ -n "${IPADDR}${REMIP}" ] ; then
-   pppopts="$pppopts ${IPADDR}:${REMIP}"
- fi
  # If PAP authentication was configured by netcfg, pass the info to pppd.
  if [ -n "${PAPNAME}" ] ; then
    pppopts="$pppopts name ${PAPNAME} remotename ${IFACE}"
--- 216,221 ----

and setup 

LINK_DOWN_REMIP=192.12.32.33	<- or 192.12.33.48
REMIP=
IPADDR=195.12.32.110

This is work for my configuration.
Write me if you know better decision.

-- 
Marat Khairullin	8->	mailto:xmm@ugai.kcn.ru

From kop@meme.com  Fri Jan 16 23:35:37 1998
Status: RO
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="_=XFMail.1.0.p0.Linux:980117002452:699=_"
Message-ID: <XFMail.980117002405.kop@meme.com>
X-Mailer: XFMail 1.0 [p0] on Linux
In-Reply-To: <rnzpkw0wvq.fsf@xoxma.ugai.kcn.ru>
Date: Fri, 16 Jan 1998 23:35:37 -0600 (CST)
Sender: kop@frog.meme.com
From: "Karl O. Pinc" <kop@meme.com>
To: (Marat M. Khairullin) <xmm@ugai.kcn.ru>
Subject: Re: diald reject pap authentication
Bcc: kop@meme.com

This message is in MIME format
--_=XFMail.1.0.p0.Linux:980117002452:699=_
Content-Type: text/plain; charset=us-ascii


On 17-Jan-98 Marat M. Khairullin wrote:
>"Karl O. Pinc" <kop@meme.com> writes:
>
>> 
>> diald-config-0.1 was a alpha release.  Try the latest release,
>> diald-config-1.2.  Available at ftp.meme.com/pub/software/diald-config & soon
>> to be available at ftp.redhat.com/pub/contrib/noarch
>> 
>
>Hi Karl,
>
>I have installed diald-config-1.2 and diald-config-metered-0.2 packages.
>In ifcfg-ppp0 I defined REMIP and IPADDR:

Why did you want to do this and, more importantly, what happens if you
dont?

You may have a routing problem.  Have you established a (non-default)
route for your local network?

You may have another problem.  Is 195.0.0.0/24 really your local
network?  You've likely used illegal addresses for your local
network's IP numbers.  Were these IP numbers given to you by the
internic, whatever local body substitues for the internic, or your
ISP?  See attached.  I'd also refer you to the LDP Network
Administrator's Guide.  Pardon me if you know exactly what you're
doing with networking and English is the problem.

You may also want to look into compiling your kernel with 'masqurade'
turned on.

Please let me know what your problem is so that if anybody else reports
something similar I'll know what it is.  Thanks.

>REMIP=195.12.32.48
>IPADDR=195.12.32.110   <- I want use that address for connecting to ISP (for
smtp)
>
>pppd use my local eth0 address, but not IPADDR !
>
>pppd[5104]: pppd 2.2.0 started by root, uid 0
>pppd[5104]: Connect: ppp0 <--> /dev/ttyS1
>pppd[5104]: local  IP address 195.0.0.7
>pppd[5104]: remote IP address 195.12.33.48
>
>I try to uncomment NOIPDEFAULT=yes in dialdcfg :
>
>pppd[5123]: Connect: ppp0 <--> /dev/ttyS1
>pppd[5123]: local  IP address 195.12.32.182    <- came from ISP
>pppd[5123]: remote IP address 195.12.33.48
>
>And second problem:
>My ISP have two dial in server with two ip address 195.12.33.48 and
195.12.32.33,
>therefore I can't use REMIP.
>To solve this problem I insert few line in diald-up:
>
>cd /etc/sysconfig/network-scripts/
>diff -c /etc/sysconfig/network-scripts/diald-up
/etc/sysconfig/network-scripts/diald-up.old
>*** /etc/sysconfig/network-scripts/diald-up    Sat Jan 17 02:07:18 1998
>--- /etc/sysconfig/network-scripts/diald-up.old        Sat Jan 17 02:59:47 1998
>***************
>*** 216,224 ****
>  if [ -z "${REMIP}" ] ; then
>    pppopts="$pppopts ipcp-accept-remote"
>  fi
>- if [ -n "${IPADDR}${REMIP}" ] ; then
>-   pppopts="$pppopts ${IPADDR}:${REMIP}"
>- fi
>  # If PAP authentication was configured by netcfg, pass the info to pppd.
>  if [ -n "${PAPNAME}" ] ; then
>    pppopts="$pppopts name ${PAPNAME} remotename ${IFACE}"
>--- 216,221 ----
>
>and setup 
>
>LINK_DOWN_REMIP=192.12.32.33   <- or 192.12.33.48
>REMIP=
>IPADDR=195.12.32.110
>
>This is work for my configuration.
>Write me if you know better decision.
>
>-- 
>Marat Khairullin       8->     mailto:xmm@ugai.kcn.ru

--_=XFMail.1.0.p0.Linux:980117002452:699=_
Content-Type: text/plain; charset=us-ascii; name=rfc1918.txt; SizeOnDisk=22271
Content-Description: rfc1918.txt
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="rfc1918.txt"

	





Network Working Group                                         Y. Rekhter
Request for Comments: 1918                                 Cisco Systems
Obsoletes: 1627, 1597                                       B. Moskowitz
BCP: 5                                                    Chrysler Corp.
Category: Best Current Practice                            D. Karrenberg
                                                                RIPE NCC
                                                          G. J. de Groot
                                                                RIPE NCC
                                                                 E. Lear
                                                  Silicon Graphics, Inc.
                                                           February 1996


                Address Allocation for Private Internets

<body snipped> 

--_=XFMail.1.0.p0.Linux:980117002452:699=_--
End of MIME message

From: kop@meme.com
Date: Jan 18, 1998
To: Marat Khairullin     mailto:<xmm@ugai.kcn.ru>

I've a new release, diald-config-1.2.1, available that fixes your
problem.  Please let me know if you have any problems with it, I'd
like to wait for some feedback before releasing it just in case
there's some problem.

When it is released it will take some time to work through the system
at ftp://ftp.redhat.com/pub/contrib/noarch and
ftp://sunsite.unc.edu/pub/Linux/system/network/serial.  Until then you
can find it at ftp://ftp.meme.com/pub/software/diald-config.

>Hi Karl,
>
>I have installed diald-config-1.2 and diald-config-metered-0.2 packages.
>In ifcfg-ppp0 I defined REMIP and IPADDR:
>
>REMIP=195.12.32.48
>IPADDR=195.12.32.110    <- I want use that address for connecting to ISP (for
>smtp)
>
>pppd use my local eth0 address, but not IPADDR !
>
>pppd[5104]: pppd 2.2.0 started by root, uid 0
>pppd[5104]: Connect: ppp0 <--> /dev/ttyS1
>pppd[5104]: local  IP address 195.0.0.7
>pppd[5104]: remote IP address 195.12.33.48

Yes.  This should not happen.

>I try to uncomment NOIPDEFAULT=yes in dialdcfg :
>
>pppd[5123]: Connect: ppp0 <--> /dev/ttyS1
>pppd[5123]: local  IP address 195.12.32.182     <- came from ISP
>pppd[5123]: remote IP address 195.12.33.48

The point of NOIPDEFAULT is to have pppd get it's ip's from the remote
end, so that dosen't work.

>And second problem:
>My ISP have two dial in server with two ip address 195.12.33.48 and
>195.12.32.33,
>therefore I can't use REMIP.
>To solve this problem I insert few line in diald-up:
>
>cd /etc/sysconfig/network-scripts/
>diff -c /etc/sysconfig/network-scripts/diald-up
>/etc/sysconfig/network-scripts/diald-up.old
>*** /etc/sysconfig/network-scripts/diald-up     Sat Jan 17 02:07:18 1998
>--- /etc/sysconfig/network-scripts/diald-up.old Sat Jan 17 02:59:47 1998
>***************
>*** 216,224 ****
>  if [ -z "${REMIP}" ] ; then
>    pppopts="$pppopts ipcp-accept-remote"
>  fi
>- if [ -n "${IPADDR}${REMIP}" ] ; then
>-   pppopts="$pppopts ${IPADDR}:${REMIP}"
>- fi
>  # If PAP authentication was configured by netcfg, pass the info to pppd.
>  if [ -n "${PAPNAME}" ] ; then
>    pppopts="$pppopts name ${PAPNAME} remotename ${IFACE}"
>--- 216,221 ----

Yes, your're right this is the problem.  I missed it the first time I
read the patch because you've got the old and new versions reversed
from the usual ordering in a patch.  Couldn't figure out why you'd
remove code that looks like that.  :-)

>
>and setup 
>
>LINK_DOWN_REMIP=192.12.32.33    <- or 192.12.33.48
>REMIP=
>IPADDR=195.12.32.110
>
>This is work for my configuration.
>Write me if you know better decision.

It actually dosen't matter what LINK_DOWN_REMIP is, so long as it's
not being used by any attached network when the link is down.  My
tendency would be to emphasise this by using a 192.168.0.0/24 address.

>-- 
>Marat Khairullin        8->     mailto:xmm@ugai.kcn.ru

On 18-Jan-98 Marat M. Khairullin wrote:
>"Karl O. Pinc" <kop@meme.com> writes:
>
> 
>> Why did you want to do this and, more importantly, what happens if you
>> dont?
>
>I must use IPADDR=195.12.32.110 to downloading mail from ISP by SMTP.
>When I connect to ISP I send command ETRN <my-name> to SMTP server
>that initiate mail sending to me.

Ok.  So <my-name> resolves to 195.12.32.110.

>> You may have a routing problem.  Have you established a (non-default)
>> route for your local network?
>> 
>
>I haven't routing problem. This is my routing table.
> 195.0.0.0       0.0.0.0         255.255.255.0   U      1500 0          0 eth0
> 127.0.0.0       0.0.0.0         255.0.0.0       U      3584 0          0 lo
	
Yup, right.

>> You may have another problem.  Is 195.0.0.0/24 really your local
>> network?  You've likely used illegal addresses for your local
>> network's IP numbers.  Were these IP numbers given to you by the
>> internic, whatever local body substitues for the internic, or your
>> ISP?  See attached.  I'd also refer you to the LDP Network
>> Administrator's Guide.  Pardon me if you know exactly what you're
>
>These addresses had been set by previous administrator. He has picked out
>from air. I can't change these addresses for the present. 

Oh well.  DHCP may help.  http://www.vix.com

>
>> doing with networking and English is the problem.
>> 
>
>English is really problem for me. 

Well, your english works fine.

http://c.gp.cs.cmu.edu:5103/prog/webster
http://wombat.doc.ic.ac.uk/

>Thank you for your diald-config.

Your welcome.  Thanks for alearting me to the problem.  Please let me know if there are any more.

>-- 
>Marat Khairullin       8->     mailto:xmm@ugai.kcn.ru

Karl <kop@meme.com>