ppp

This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.



Subject: Re: Chat script
From: George Cingolani <gcingo@accesscom.com>
Date: Mon, 12 Apr 1999 04:53:09 -0700 (PDT)

On Mon, 12 Apr 1999 NoelTinCA@aol.com wrote:


> 	I have run into a new road block trying to dial into
> the university.  I have read some more documentation and
> have made some headway, but I am still not able to make it
> work right. I am able to dial in and connect to the
> server, but I wind up getting disconnected right away. I
> use the following command line to connect:

> pppd connect "chat -vf /etc/ppp/chatscript" /dev/ttyS2
> 38400 -detach \crtscts modem defaultroute noauth
 
> The file /etc/ppp/chatscript contains the following:
> TIMEOUT 5
> ABORT "NO CARRIER"
> ABORT "BUSY"
> ABORT "NO DIALTONE"
> ABORT "WAITING"
> ECHO ON
> "" ATZ
> SAY "Dialing your ISP...\n"
> OK AT&F1E0V1Q0S0=0&C1&D2&B1&A3&M4^M #modem string recommended by my modem 
> manufacturer
> OK ATDT3464000
> TIMEOUT 45
> CONNECT ""
> #TIMEOUT 5
> ogin:--BREAK--ogin: noelt #myLogonID
> word: myPassWord

> Does anybody see something in what I am doing that might
> cause me to not be able to stay connected?  I don't know
> for sure, but I think that I might not be getting
> authorized.

try this one

exec /usr/sbin/pppd debug lock modem crtscts /dev/ttyS0 38400 \
	asyncmap 20A0000 escape FF kdebug 0 $LOCAL_IP:$REMOTE_IP \
	noipdefault netmask $NETMASK defaultroute connect $DIALER_SCRIPT

===

Subject: Re: Modem connection speed?
From: Ramon Gandia <rfg@nook.net>
Date: Sat, 10 Apr 1999 10:41:23 -0800

John Mai wrote:
> 
> Hello
> 
> How can you tell the actual modem connection rate in RedHat Linux during
> connection to ISP??

This is a trick question with a trick answer.

If you want to know your ONGOING speed DURING a ppp session;
ie, a speed indicator of some sort, or a program that asks
what the speed is, etc. you are basically out of luck.  The
ppp connection will die if you access the modem register for
this.  Having said that, some EXTERNAL modems will report
speed on the LED or LCD indicator.  They do not do this via
the serial ppp cable, but directly to the indicator, so the
ppp link stays up.  Of the inexpensive ones, the ones by
Multitech do this.  You can watch your speed go down, up, back
down, etc as line conditions change.

If all you want to know is your INITIAL connect speed; ie
the speed you happen to get when you first connect to the ISP
for your ppp session, then that is a lot easier.  It should
be reported in /var/log/messages.  If not, increase the
level of verbosity in pppd.

Lastly, if your connection is not PPP, you can often interrupt
the data stream by sending +++ top the modem to put it in
command mode, then accessing the proper register to see your
speed, then go back to data mode.  You will need your modem
manual to see what exact commands you need.  Most modems, alas,
do not have such a register....only the one with the initial
connect speed.

There are also some programs that will count bytes in and out
of the modem port.  This will give you an idea of the transfer
speed, but is of course unrelated to the modem connect speed.

===

Subject: pppsetup - good program
From: Mark Price <prim0001@unf.edu>
Date: Tue, 13 Apr 1999 02:42:57 -0400 (EDT)
 
This [pppsetup] is a good program for a beginner that just
wants a basic ppp connection, and doesn't want to deal with
composing chat scripts, and rooting around in Linuxconf.  It
will work with no graphics, and will help build your
chatscript, is good for those that need more than just
serid: and assword: in their chat script...  The rpm can be
found at redhat mirror sites.  I learned a lot about all the
technical stuff before I got it, but it is a good quick-fix.


===



===



Subject: Re: Anyone know what this is? 
From: Eddie Kuns <ekuns@kilroy.chi.il.us>
Date: Mon, 15 Mar 1999 08:56:56 -0600



darryl@myemail.com.au said:
] When dialing my ISP and establishing connection, My PPPD log always
] has this;
]
] Mar 14 11:29:45 gw1 pppd[9186]: Unsupported protocol (0x8207) received

The remote end is offering that protocol.  I received
exactly the same message while dialing into my work.  I also
had other issues dialing into work that at the time I
assumed were related to the message.  That turned out to be
"pilot error" on my part, whoops!  I fixed those mistakes
and all works, and I still get that message.  When I thought
it indicated a problem, I spend a couple hours trying to
figure out what it was.  I finally located the list of ppp
protocols.  The full (?) list of ppp protocol numbers can be
located at:

ftp://ftp.isi.edu/in-notes/iana/assignments/ppp-numbers

The one you are curious about is:

8207            Cisco Discovery Protocol Control

Thus, I'll bet a dollar the device at the other end of the
phone is a Cisco device.  <grin>

You aren't missing anything.  I'm not sure what this
protocol is, exactly, or what it does.  When establishing a
PPP connection, the remote end offers all the protocols it
knows.  Linux PPP complains when it is offered a protocol it
doesn't know about.  Win9x PPP, on the other hand, seems to
just ignore any protocols it doesn't know about.  I'm not
sure which behavior I prefer!

Anyway, PPP's complaint is just informational.  Feel free to
ignore it.

===

Subject: Re: Re: Re: ppp connect script -Reply
From: Steve Borho <sborho@ststech.com>
Date: Mon, 26 Apr 1999 13:08:31 -0500

On Mon, Apr 26, 1999 at 11:51:06AM -0500, Godfried Duodu wrote:
> Is there anyway I can see the expect/send format used in the ifup
> command, since that works fine,  so that I can repeat that in my script?

/etc/sysconfig/network-scripts/chat-ppp0

========

===
===
Subject: Re: ppp connect script -Reply
From: Jan Carlson <janc@iname.com>
Date: Mon, 26 Apr 1999 17:25:11 -0400

Godfried Duodu wrote:
> 
> ** Reply Requested When Convenient **
> 
> Is there anyway I can see the expect/send format used in the ifup
> command, since that works fine,  so that I can repeat that in my script?

Did you know that a chat script is totally unnecessary
if your ISP supports PAP authentication?  Also, most ISPs
do use PAP these days.

Try having no chat script at all, and enable PAP.
You might be very happily surprised.

====
Subject: Re: ppp logs
From: Ramon Gandia <rfg@nook.net>
Date: Mon, 26 Apr 1999 18:51:38 -0800


Mark Anthony wrote:
> 
> i tried your advised and it seems successful
> but i still have some problems. my ISP is using
> Cisco 2511 router and Radtac 3.1 for authentication.
> here's my ppp logs.
> 
> Apr 27 05:01:09 hehe pppd[421]: pppd 2.3.5 started by root, uid 0
> Apr 27 05:01:10 hehe chat[422]: send (AT^M)
> Apr 27 05:01:10 hehe chat[422]: expect (OK)
> Apr 27 05:01:39 hehe chat[422]: AT^M^M
> Apr 27 05:01:39 hehe chat[422]: OK
> Apr 27 05:01:39 hehe chat[422]:  -- got it
> Apr 27 05:01:39 hehe chat[422]: send (ATD2225614^M)
> Apr 27 05:01:39 hehe chat[422]: expect (CONNECT)
> Apr 27 05:01:39 hehe chat[422]: ^M
> Apr 27 05:02:19 hehe chat[422]: ATD2225614^M^M
> Apr 27 05:02:19 hehe chat[422]: CONNECT
> Apr 27 05:02:19 hehe chat[422]:  -- got it
> Apr 27 05:02:19 hehe chat[422]: send (57600^M)
> Apr 27 05:02:19 hehe chat[422]: send (ame^M)
> Apr 27 05:02:19 hehe chat[422]: expect (:)
> Apr 27 05:02:29 hehe chat[422]:  57600^M
> Apr 27 05:02:39 hehe chat[422]: ^M
> Apr 27 05:02:39 hehe chat[422]: Username :
> Apr 27 05:02:39 hehe chat[422]:  -- got it
> Apr 27 05:02:39 hehe chat[422]: send (mark^M)
> Apr 27 05:02:39 hehe chat[422]: expect (57600)
> Apr 27 05:02:49 hehe chat[422]:  57600
> Apr 27 05:02:49 hehe chat[422]:  -- got it
> Apr 27 05:02:49 hehe chat[422]: send (word^M)
> Apr 27 05:02:49 hehe chat[422]: expect (:)
> Apr 27 05:02:49 hehe chat[422]: ^M
> Apr 27 05:02:49 hehe chat[422]: Password :
> Apr 27 05:02:49 hehe chat[422]:  -- got it
> Apr 27 05:02:49 hehe chat[422]: send (kram^M)
> Apr 27 05:02:49 hehe pppd[421]: Serial connection established.
> Apr 27 05:02:59 hehe pppd[421]: Using interface ppp0
> Apr 27 05:02:59 hehe pppd[421]: Connect: ppp0 <--> /dev/ttyS0
> Apr 27 05:02:59 hehe pppd[421]: sent [LCP ConfReq id=0x1 <magic 0xb043b9a0>
> <pcomp> <accomp>]
> Apr 27 05:03:29 hehe pppd[421]: LCP: timeout sending Config-Requests
> Apr 27 05:03:29 hehe pppd[421]: Connection terminated.
> Apr 27 05:03:29 hehe pppd[421]: Receive serial link is not 8-bit clean:
> Apr 27 05:03:29 hehe pppd[421]: Problem: all had bit 7 set to 0
> Apr 27 05:03:39 hehe pppd[421]: Hangup (SIGHUP)
> Apr 27 05:03:40 hehe pppd[421]: Exit.

I took a look at your mail header, and see that it was sent
from Eudora mail for Windows 95.

Presumably, the computer you are using now on Windows 95 is the
same one you are trying to make connect in Linux?

If yes, I want to ask if your ISP uses a connect SCRIPT.  This
is a specific action on the part of Windows 95. The vast majority
of users on Windows 95 simply fill in the username and password
on the CONNECT window, and check the "save password" then press
the connect button.  Is this what you do?

Or do you need to bring up a script or a "Terminal Window" in
Win95 ??

If you do not need a script or a terminal window in Windows 95,
then why are you forcing RedHat to execute a SCRIPT?  I notice
that you are doing so in your ppp log.  You are expecting
username :, then sending a username.  Expecting Password :,
then sending it.  This is a script.

At Nook NEt, my server will do the same thing, send you all
those username and password prompts, but if you answer them it
will never give you a connection.  YOU MUST NOT USE A SCRIPT OR
AN EXPECT-SEND SEQUENCE for you ppp to work.  What 95% of all
ISP's use nowadays is called PAP authentication.  This does
not use username and passwords in the sense that you are doing.
Its a binary protocol that contains those elements and is called
PAP authentication.  Its automatic between you and the server.

In Windows 95, the username and password that you fill in on
the box that has the CONNECT button is NOT an expect-send
sequence; it is rather the PAP authentication parameters.  This
is no end of confusion for newbies.... they log in with minicom
and see a username prompt....or they look at the RedHat ppp
configuration and see a place to fill in the username and
password and immediately fill it in.  THIS will NOT work with
most ISP's and will not work with Nook Net.

Instead, leave all of that junk blank.  Yes, blank.

Now go find the PAP authentication button, and in the PAP
place go and fill in the username and password.  When you
finish you will notice that you have created a file called
/etc/ppp/pap-secrets which contains the username and password
(the password is called a "secret" in PAP parlance).

Although I am not 100% sure that is your problem, I am betting
that it is and that you will have a much easier time of it
if you follow my advice above and get rid of the SCRIPTED
logon that you are using.
========

Subject: Re: ppp-stats monitoring
From: James Michael Keller <jmkeller@radix.net>
Date: Sat, 01 May 1999 18:49:00 -0400


Larry Mintz wrote:
> 
> Is there anyway I can check out if my modem is running at full speed ?
> I know there is the tool pppstat, but this tool doesn't help. I am looking
> for a tool similar to the Dial-Up Networking Monitor in NT. Does such a thing
> exists in Linux ?

	An excellent little package to have at hand is
iptraf.  Among it's many screens, there is a detailed traffic
monitor for interfaces, in this case ppp0 probably is what
you would use.  Will give you a meter of total k/s and
packets/s.

	I open up a desk top with three terminal windows,
one full hight showing the iptraffic monitor screen, another
half high window next to it with detailed info on the ppp0
interface for the net connection, and a detailed protocol
window below that that shows me what ports have trafic ( and
what those ports are ie tcp/http, tcp/telnet, etc ) and how
much data is moving across them.

	Very handy tool, and the description in the rpm when
I found it on filewatcher.org was so unassuming :)

=======

Subject: Diald and timeout.
From: "Fathi Ben Nasr" <fathi.bennasr@sfa.com>
Date: Sun, 2 May 1999 01:14:29 +0100

I set up my linux box to access Internet via a modem using diald. I used 
Jan Carlson post on 29/03/99 to this list, which was very clear.
I added the four lines suggested in step 16:

>impluse 30,0,0
>redial-timeout 10
>up-delay 5
>buffer-packets on

but to the /usr/lib/diald/standard.filter instead of 

/var/run/pppd-diald-coors.conf as linuxconf overwrites it
when activating changes and removes this four lines.

Pinging from a w9x client to remote hosts gives me a line
saying pinging www.remote.host.com [remote.host.ip.number]
and then four lines of timed out requests. It is also
impossible to browse the net or do ftp from any w95 browser
or msdos command line.

When pinging any host from a w95/98 client with the
connection not established, the client waits until the
connection is up to do the dns resolution and then gives the
same timeout request messages.


==============

Subject: Re: pppd problems
From: Bruce Richardson <brichardson@lineone.net>
Date: Sun, 2 May 1999 14:12:14 +0100 (GMT)

On Sun, 2 May 1999, Paul Mezzanini wrote:

> so bruce.. got any ideas on my pppd problem?  :)

Ok, here's an embarrassing one that tripped me up when I
first set up ppp - one of the scripts (I think it was
ppp-on-dialer) wasn't executable.  I found out when I put
debug-logging.  I put this in /etc/syslog.conf:

#PPP
daemon,local2.debug /etc/ppp/ppp.log

and added "kdebug 4" to the pppd command line.  I could
check it after each failure - spotted the "permission
denied" problem.  Whatever your problem is, having the debug
messages should help.

=========

Date: Sun, 27 Sep 1998 17:46:53 -0700
To: computing@kzsu.stanford.edu
From: Stefan Lisowski <stefan@kzsu.stanford.edu>
Subject: KZSU QPOP/ Hacker warning

The LAN on my block (where I'll live for the next two weeks) was hacked
from the outside again. I had "APOP" chosen in my Eudora mail client, but
apparently KZSU's pop server doesn't currently support APOP, thus my
password (now changed) was sniffed by my unencrypted popping.

The latest QPopper supports APOP, and also:

>
>Another good reason to upgrade KZSU:
>
>"Qpopper2.41 and prior versions are vulnerable to buffer overflow. Remote
>users can obtain root access on systems running these versions. Releases
>of Qpopper 2.5 and later are immune from all known buffer overrun security
>holes posted in bugtraq. Please upgrade your server if you are running any
>qpopper older than 2.5."

I'd thought that using only ssh and APOP I was set, but Eudora 3.1 doesn't
warn you if your APOP is reverting to just cleartext passwords...

Anyway, any chance that someone could download compile and install the
latest qpopper from Qualcomm? Below are instructions to support APOP in the
compile:

http://eudora.qualcomm.com/freeware/qpop_faq.html

>How do I setup APOP authorization?
>
>       APOP is an alternate authentication method. It is able to
>authenticate without passing the password in cleartext
>       over the wire. To enable this feature, you need to define the
>following compiler definitions:
>
>              APOP=\"/etc/pop.auth\"
>              POPUID=\"pop\"
>
>       The first definition is the location of the database; the second
>specifies the user/password entry that will own
>       the authorization database. When you build the qpopper with APOP,
>you also get a program called popauth
>       which must be installed in a public location. This program must
>also run SUID as the 'pop' user so that it can
>       make modifications to the pop.auth database.
>
>       NOTE: Make sure the database /etc/pop.auth is owned by POPUID and
>that the permissions are 600. popauth
>       -init creates the file with the proper owner and perms.
>
>       The database must be initialized by root with the following command:
>
>              popauth -init
>
>       New users can be added by root or the 'pop' user with the following
>command:
>
>              popauth -user
>
>       Or removed with the following command:
>
>              popauth -delete
>
>       Any user on the host can add themselves or change their password
>with the following command:
>
>              popauth


Yuck. Dealing with hackers is a pain.

======

Subject: Re: External vs. Internal Modems
From: Ramon Gandia <rfg@nook.net>
Date: Tue, 18 May 1999 17:29:22 -0800


Ryan Ware wrote:
> 
> The only way you will need isapnp is if you get an ISA modem.  As for
> setup, I believe all you need to do is make a link called /dev/modem to
> the proper com port (/dev/ttyS0 or /dev/ttyS1), although I'm not
> completely sure for an external modem.  I have ISA.  Good luck.

You only need isapnp is your modem is internal, ISA and PnP
enabled.  Some, like the US Robotics Internal Sporster, have
jumpers:  COM1 com2 PNP etc.  If you disable pnp in the jumpers
then you do not need isapnp.

With a modem set with jumpers to a port, you need to go into
the BIOS and disable the motherboard port.

Example.  A USR Sporster internal. You set it for non-pnp on
COM2 (cua1).  Plug it in.  Restart the computer and go into
BIOS setup.  Look for the serial port configuration.  Typically
you will have two serial ports on the motherboard, called A and
B.  Usually A will be set to COM1, and B will be set to COM2.
Assuming this is the case, you go into port B setup and set
it to "disable".  That frees up COM2.  Or you could set up the
port to some different com port assignment.

With an external modem, you want to ENABLE the com port that
your cable attaches to, obviously.

Be forewarned about COM ports.  COM1 and COM3 share the same
interrupt (4), and COM2 and COM4 share irq 3.  The lower the
number of the interrupt, the higher priority.  It is best
to give modems a fairly high priority as the data coming
down the modem cannot be 'put on hold', it just keeps streaming
in.  ON a pentium, this is not too critical.

COM4 (cua3) is a bad choice because video cards often use
the i/o space.  You never should use COM4/cua3 unless you are
sure your hardware lets you with no conflicts.  Some people
think they are okay, and they notice strange glitches later
on.

If you think PnP avoids all these problems, be assured that
there is nothing worse than a PnP situation that does not work
properly.  It can drive you to distraction because its like
nailing jelly to a try.  You fix THIS, and then THAT changes
or freezes the computer....  Jumpers  type of modem or an
external are best.

===

Subject: Re: PPP 
From: John Summerfield <summer@OS2.ami.com.au>
Date: Wed, 26 May 1999 08:47:20 +0800


> I have been trying without success to get my computer to dial up my ISP via
> Linux 5.2. I have read all of the HOW-TO's and MAN pages on setting up
> Linux, but still can't seem to get it to work. I can get minicom to dial up
> and actually log-in to my ISP, but it won't hold the connection. I have
> tried to set the PPP Options to make the LCD (I think that's right) to 30,
> so it would not disconnect but that did not work. I really at my last straw.
> I am wanting to get an Internet link to download a new XFree86 so I can use
> my Matrox Millennium video card. Anyway, if there is anyone who can give me
> any insight....

None of this GUI nonsense for me: I based my dialup procedure on samples 
in /usr/doc/ppp*

To be fair, the network configuration tool attached to the control panel 
works well too. I've not tried linuxconf.

===

Subject: PPP . . . kind of . . . sort of . . . sometimes
From: "Yuki Taga" <yukitaga@twics.com>
Date: Mon, 31 May 1999 22:41:01 +0900


Hi Guys!

Okay, I can now establish a ppp session at will.  <sound of one hand 
clapping>  The way I have to do it is hard to believe, however, and I don't 
think most of you would accept it.  I sure can't.

1) On any boot into Linux *after* using the modem in NT or Windows, the 
command /sbin/ifup ppp0 will fail.  The modem absolutely will not dial.

2) In the same situation, the command /usr/local/bin/wvdial will always 
cause the modem to dial, and connect, but the wvdial program cannot 
establish a ppp connection, because it is waiting for something that 
doesn't happen.  Why this program can't finish the job is beyond me.  It 
says it's waiting for something.  But I really don't want to use this 
program anyway.  Go to the next step.  ^_^

3) After the failure in step 2, regardless of whether step 1 was even 
attempted or not, the command /sbin/ifup ppp0 now successfully dials 
and immediately establishes a working ppp connection every single 
time.  Moreover, a reboot into Linux that does not involve modem use in 
another OS means the command will work instead of failing in step 1.

I am at a complete loss to explain this.  I truly hope someone else can.
There is one possible hint here.  The program wvdial autoprobed my 
moden when I installed it, and it came up with an init string I never heard 
of and cannot find in the manual.  I think there may be some magic in 
that init string.  However, step 3 above does not use that string.

===

Subject: Re: PPP . . . kind of . . . sort of . . . sometimes
From: "Greg W" <redhat_list@hotmail.com>
Date: Mon, 31 May 1999 14:25:37 GMT


I am not sure of your procedure.....but, if you boot to Linux after 
something has accessed your modem, always turn it off then on, you are 
probably aware of this...

With the string, it may be worth trying &fx3  or  at&fx3 , keep all 
characters in one case, do not mix them.

In short the string tells the modem to wake up, set itself to factory 
default, then dial regardless (forced dial).

===

Subject: Re: PPP . . . kind of . . . sort of . . . sometimes
From: "Yuki Taga" <yukitaga@twics.com>
Date: Tue, 1 Jun 1999 07:23:45 +0900


On 31 May 99, at 10:39, Steve "Stevers!" Coile wrote:

> On Mon, 31 May 1999, Yuki Taga wrote:
> [...]
> > 1) On any boot into Linux *after* using the modem in NT or Windows, the
> > command /sbin/ifup ppp0 will fail.  The modem absolutely will not dial.
> 
> Is the modem getting different IRQ, DMA, or IO settings under Windows than
> it has under Linux?

Ouch.  I know how to check this in M$, but not in Linux.  Please teach me.

> Does /etc/sysconfig/network-scripts/chat-ppp0 include any initialization
> strings for your modem?  Perhaps your modem isn't being properly reset.
> Try adding ATZ to the chat script and see if that fixes things.

Will do and will advise.  Thanks.
 
> > 2) In the same situation, the command /usr/local/bin/wvdial will...
> 
> What is /usr/local/bin/wvdial?

This is the command that fires the wvdial program.  It's similar to 
something called xisp, the rpm for which I cannot seem to install 
because of a libforms.so.86 dependency.  I can --nodeps the rpm, but 
the program won't run without the right libforms package.

Wvdial is interesting.  When you initialize it the first time it probes the 
modem and reports a lot of interesting information.  It came up with an 
init string that isn't in my manual and I never heard of.  But it works.

> [...]
> > 3) After the failure in step 2, regardless of whether step 1 was even
> > attempted or not, the command /sbin/ifup ppp0 now successfully dials and
> > immediately establishes a working ppp connection every single time. 
> > Moreover, a reboot into Linux that does not involve modem use in another
> > OS means the command will work instead of failing in step 1.
> 
> Sounds like the modem isn't being left in a clean state after its use
> elsewhere.  I'd definitely try to put some initialization settings into
> the chat script in /etc/sysconfig/network-scripts.

Again, too logical for me to think of first.  ^^_^^  Will try, will advise.

===

Subject: Re: PPP . . . kind of . . . sort of . . . sometimes
From: "Yuki Taga" <yukitaga@twics.com>
Date: Tue, 1 Jun 1999 12:50:18 +0900


Still investigating this, Greg.  But for starters the cycling of modem
power didn't work.  Now, I turned it off and on *between* OSes, not after
I booted into Linux, but after I booted out of NT.  So I'll try that next
(probably won't make any difference but worth a try) and then I'll play
with init strings.

Quick question, though.  Wvdial found an init string that apparently works
on the first try, even coming from NT.  Instead of the strings you have
below, shouldn't I try that one first?  One thing to note here:  NEC is
one of those companies that is extremely proprietary.  They would play the
M$ game in a second if they could.  Had I known this about them, I would
never have bought their IDSN TA/DSU, even though it's popular here in
Japan.  Example:  They don't use standard AT commands.  That's right.  Try
AT&W in this modem, and it returns ERROR.

So, maybe that wvdail init program probed and found a good string?

===

Subject: Re: Can a shell script replace 'diald'? 
From: John Summerfield <summer@OS2.ami.com.au>
Date: Tue, 01 Jun 1999 22:34:18 +0800


> I was wondering if it is possible to achieve the functionality of 'diald'
> just using "stock" Linux net utils and shell scripts.  Here is what I am
> proposing:
> 
> 1. Set up a script that runs in a loop, monitoring network traffic using
> some network utility or log file.  (Does a machine keep a log of IP address
> requests somewhere?)
> 2. When the script encounters an outside IP address, it just issues 'ifup
> ppp0'.
> 3. After a five minute interval of no Internet activity, it issues 'ifdown
> ppp0'.
> 

Recent versions of pppd do dial on demand. Read its docs,

===

Subject: RE: Can a shell script replace 'diald'? 
From: "George Lenzer" <glenzer@chuhpl.lib.oh.us>
Date: Tue, 1 Jun 1999 11:39:53 -0400


Will this work with dynamic IPs?  I had heard that it wouldn't, and from
what I saw in the docs, it sounds like it won't either.  Perhaps, I'm
looking in the wrong place? /usr/doc

===

Subject: RE: Can a shell script replace 'diald'? 
From: Ryan Ware <ware@shocking.com>
Date: Tue, 1 Jun 1999 09:54:40 -0700 (PDT)


It'll work.  Just make sure to use the ipcp-accept-local and
ipcp-accept-remote options.

===

Subject: Re: Firewalling 101
From: "Justin Oelgoetz \(chemistry.ohio-state.edu\)" <joelgoet@chemistry.ohio-state.edu>
Date: Tue, 1 Jun 1999 18:05:21 -0400 (EDT)


On Wed, 2 Jun 1999, Peter Kiem wrote:

> >what's in that, but it's probably ok.  Definitely kill the webserver.
                               <snip. . .>
> But if the only machine allowed to accept WWW packets is the Linux
> server then having web server on the firewall machine wouldn't be a
> security risk?  And Linuxconf can be configured that only my
> workstation can connect to it?

The only reason I say it's a risk is that I got the impression that we
were using an NT box inside the firewall to do our Web stuff.  If we need
apache or a web server on the firewall for linuxconf only, it's a risk
because it is an unnecessary service.  It increases one's exposure to future
exploits.  If it's going to be used to do real web servicing then great,
but otherwise it's unnecessary.  (All services are potential security holes
thus risks.  Run only what you absolutely need on the firewall).

> Yes I intend to do that but maybe I didn't explain myself enough. 
> Should I be putting in routing rules for *ALL* of the private address
> ranges or does the routing automatically trap these?
> e.g. I have a cracker at my ISP (unlikely) that is using address
> 10.0.0.1 to hide his real IP address.  If I don't route the 10.x.x.x
> addresses to my internet network ethernet card then I would be sending
> reply packets to him right?

I'd go w/ the networks when you do the routes.  Maintaining the files if
you did the ip's individually would be painful.  A hacker could always try
a private IP's until one worked if they were inside your building anyways.
If you set up your firewall right, you shouldn't be routing private
packets to the internet.  As mater of fact your upstream provider should
kill them if they see them.

> >> 4. PPP.  THAT will be a whole can of worms in itself 8(
> >
> >Actually use linuxconf, and if-up ppp0 to bring the interface up,
> works
> >great.  Don't do this file editing stuff if you don't have to.
> 
> That sounds great 8)  It seems an arcane art to get PPP running from
> what I have read.

Linuxconf rocks.  Under redhat if you use linuxconf (which has X and
ncurses interfaces) to set up ppp all you need to do to bring up the
connection is type if-up ppp0 as root.  if-down ppp0 brings it down.  It
works just like any other interface.


===


Subject: Re: Can a shell script replace 'diald'? 
From: Ryan Ware <ware@shocking.com>
Date: Tue, 1 Jun 1999 22:53:11 -0700 (PDT)


Hello,

I've posted this before, but since the archives are of little use at the
moment, it's a bit hard to find.  This is an explanation of how I got the
demand function of pppd working and what options I used.  Hopefully this
will help and maybe make the man page a bit more understandable.

Ryan Ware
(ware@shocking.com)

To begin with, I used RedHat's netcfg program to originally connect to
the internet so that's where the ppp0 device was created and also the
chat-ppp0 file (amongst others.)  You also need a 2.2.x kernel (or late
2.1.x.)
The following is the command I use to invoke pppd:

/usr/sbin/pppd -detach 204.119.204.71:204.119.204.2 ipcp-accept-local
ipcp-accept-remote demand holdoff 5 idle 360 lock modem crtscts
defaultroute name ware /dev/modem 115200 remotename ppp0 ipparam ppp0
connect '/usr/sbin/chat -f /etc/sysconfig/network-scripts/chat-ppp0' & >
/dev/null

So that it is started automatically upon boot, I put the above command in
a file called /etc/rc.d/init.d/pppd and made it executable.  Then I made a
link called /etc/rc.d/rc3.d/S90pppd that points to the previous file.  As
far as I know, the demand option only works with version 2.3.5 or later.
I use 2.3.5 and I think the newest version is 2.3.7.

Now let me explain the options I use with the pppd command:

-detach - This detaches pppd from the controling terminal so that closing
the terminal has no effect upon pppd.

204.119.204.17:204.119.204.2 - This is the local_ip:remote_ip.  local_ip
is the IP you are assigned when you connect to your ISP.  remote_ip is the
ip of the machine that you connect to at your ISP.  If you aren't sure
what this is, connect to your ISP and issue the command 'traceroute -i
ppp0 isp.domain.name'.  The first line in the listing should contain the
IP of the remote machine.  If you do not have either one of these (i.e.
dynamic allocation of IP's,) it is no problem.  The following options take
care of the problem.

ipcp-accept-local - This option allows the local IP to be changed by the
value supplied by the server at connect time.

ipcp-accept-remote - This option allows the remote IP to be changed by the
value supplied by the server at connect time.

demand - This option turns on the demand feature so that a connection is
automatically created when network traffic exists.

holdoff 5 - This option specifies ho many seconds to wait before
re-initiating a link after it terminates

idle 360 - This option tells how many seconds to wait before disconnecting
because of lack of traffic.

lock - Creates a lock file for the serial device used for the modem.

modem - Use the modem control lines.

crtscts - Use hardware flow control.

defaultroute - Have this be the default route in the routing table.

name ware - This is for PAP.  ware is my username that corresponds to my
secret in my pap-secrets file.

/dev/modem - This is the serial device to use for your modem.

115200 - This is the speed of your serial connection.

remotename ppp0 - Sets the assumed name of the remote system.

ipparam ppp0 - Needed for the ip-up and ip-down scripts.

connect '/usr/sbin/chat -f /etc/sysconfig/network-scripts/chat-ppp0' -
Tells pppd what to use to make the actual connection.

& - Ensures pppd runs in the background.

> /dev/null - Redirects any output away from the terminal to oblivion.


On Tue, 1 Jun 1999 taj@cyber-wizard.com wrote:

> On Tue, 1 Jun 1999, John Summerfield wrote:
> 
> > Recent versions of pppd do dial on demand. Read its docs,
> 
> Heh. But did you understand it? *I* didn't. I tried modifying the
> /etc/ppp/options file as follows:
> 
> lock            # here by default
> demand          # dial on demand
> nopersist       # don't keep up a permanent connection
> holdoff 30      # wait 30 seconds before redialing if dropped
> idle 300        # timeout after 5 minutes of no traffic
> noipdefault     # I *hope* it turns off the static IP requirement
> 
> But it just sat there when I tried dialing using /sbin/ifup ppp0. How many
> french fries short of a happy meal does that make me? :)
> 
> Have you gotten it to work? If so, mind sharing your incantation with me?

===

Subject: Re: PPP refuses to work as user
From: Jan Carlson <janc@iname.com>
Date: Mon, 31 May 1999 23:48:40 -0400


Michael Ghens wrote:
[...]
> chmod u+s /usr/sbin/pppd

This is the wrong way to fix it on Red Hat,
and it's a security hole too.

Use netcfg or linuxconf to select the option that
allows any user to start or stop ppp0.
  
Linuxconf can run without X Windows also.

===

Subject: Re: PPP and Pacbell/Ascend Pipeline Terminal Server
From: Ramon Gandia <rfg@nook.net>
Date: Fri, 04 Jun 1999 08:47:43 -0800


Hal Burgiss wrote:
> 
> On Fri, Jun 04, 1999 at 01:28:50AM -0700, Paul R. Watkins wrote:

> > It seems that the serial connection is made ok but that
> > the LCP times out -- how do I fix this.  Also look at
> > last 2 lines of file -- "Receive serial link is not
> > 8-bit clean Problem: all had bit 7 set to 0 -- what
> > should I do about this?

> They are not talking the same lingo. Try using minicom to
> set your port to '8N1', see if that clears it up.

Nothing to do with it.  The "all had bit 7 set to 0" means that
the PPP link was not negotiated.  It is one of those techno-geek
error messages that gets people to think of 8N1 things or a
broken UART chip, etc.

You will see the same message if the scripted password fails,
for instance, or any other error in the expect-send script.

More often, you will see it when an expect-send script is used
when the ISP is set to purposely ignore scripted logins (most
Livingston based ISP'), or PAP was not used or used incorrectly.

Any of those will result in non-PPP negotiation and the error
message is --you guessed it-- 'bit 7 set to 0'.

===

Subject: Re: PPP and Pacbell/Ascend Pipeline Terminal Server
From: Ramon Gandia <rfg@nook.net>
Date: Sat, 05 Jun 1999 01:01:41 +0000

Hal Burgiss wrote:

> > More often, you will see it when an expect-send script is used
> > when the ISP is set to purposely ignore scripted logins (most
> > Livingston based ISP'), or PAP was not used or used incorrectly.
> >
> 
> I get something to the effect of 'PAP Authentication failure' in this
> scenario. I recently changed ISPs to one who uses PAP and does not
> support linux. I eventually got it going only by trial and error, but
> never got the '7 bit' message despite a lot of tinkering with the
> scripts and many, many failures in the process.

If PAP does not work, try CHAP.  It is set up very similarly;
the instructions are in the PPP=HOWTO, however, with CHAP you
will be outside the limits of linuxconf.  What will work is
to set up with PAP, then manually add the CHAP file which is
/etc/chap-secrets or something similar.

CHAP is not a popular protocol, but there are a few out there
that do use it.

As to an "ISP that supports PAP but not Linux" is nonsense. 
What they mean is that they have no one on staff to answer
Linux related questions.  It certainly does not mean that
their equipment or PAP does not work with Linux.

For instance, here in Nome, I do not support Windows NT.  Why?
Because I only have ONE customer that uses NT, and I know
nothing about it.  

===

Subject: Re: MasqDialler or diald???
From: Jan Carlson <janc@iname.com>
Date: Sat, 05 Jun 1999 15:02:32 -0400


Ken Walker wrote:
[...]
> 
> What I am wondering is which dialer people find best to use?
> 
> So far, it looks to me like diald may be more complicated to
> configure and may be hard to tame so it isn't dialing in more often
> than I would like.  It may also be the sort of thing where it logs
> off as you read something you are browsing on the web.  I am not sure
> I like the idea of it deciding when it should dial rather than the
> choice being made manually by the user.
[...]

What you say about diald is generally true, however I found
the magic bullet to tame diald.  It's called dctrl,
and it comes with diald.

. Dctrl shows me exactly what packet is triggering diald.
  Then I tweak the diald filter to ignore the
  packet type that's making it dial, or change its time-out.

. The diald filter file has a readable syntax.

. I can set diald so ALL its config files are in /etc/diald/

. When iconified, dctrl shows me with red, green and yellow lights
  whether diald is down, up or in transition.

. Dctrl lets me nail the connection up, or down, or let it decide.

. Diald16 is stable.

. Diald16 starts and and stops nicely, controlled by ntsysv.

. Dctrl helps me know what packets I receive, which is handy
  to keep an eye on port scans and misbehaving programs on my side.

. Diald can run independently of linuxconf.

. Diald16 works with all the Linux kernels from early 2.0 through 2.2.9,
  and all the distros I tried - Red Hat, Caldera, Slackware, Debian.

. The 2.2 kernel grumbles about diald's use of routes, but diald seems
  to work fine anyway.

. Diald does not interfere with the default RH scripts, or those used by
  /sbin/ifup and ifdown.

Diald is very trainable.

===

Subject: Re: PPP permissions
From: Jan Carlson <janc@iname.com>
Date: Thu, 01 Jul 1999 21:47:48 -0400


Sam wrote:
> 
> To get this working I used the following methods:
> 
> 1. If you have a LAN, make sure your hosts, lmhosts, hosts.conf, and
> resolv.conf files are setup properly.
> 
> 2. For the PPP options (ie, put in options.ttyS0 if you're using
> multiple serial ports for modem access or /etc/ppp/options if single
> use) use: -detach, modem, lock, crtscts, defaultroute, mtu=576, and
> mru=536 (these numbers may vary for you).
> 
> 3. Set the permissions as follows:
> 
>         /usr/bin/pppd to SetId using chmod 4755
>         /etc/ppp/ directory and files using chmod 775
> 
> 4. Set the Group for all the above to PPPUSERS (this group is setup by
> default for RH6) using chgrp PPPUSERS
> 
> 5. Edit the /etc/group file and add your username to the PPPUSERS group.

Or, press the button in Linuxconf that allows any user
to start/stop the ppp connection.

===

Subject: Re: modems
From: Ramon Gandia <rfg@nook.net>
Date: Fri, 11 Jun 1999 01:31:51 -0800


Dan Wedeking wrote:
> 
> Then I go into the minicom program and put a number to dial.
> The modem dials it, minicom says it's connected, then it disconnects right
> away.
> I wonder if it's because I typed my login name or password in wrong or if
> it's the
> PnP thing making it disconnect.  Or maybe minicom is only for connecting to
> BBS's
> and not ISP's.  But I get the same result trying to connect with PPP.

Sounds like your modem is working ok.  Most ISPs use PAP 
authentication, and not scripted or terminal.

For instance, here at Nook Net, if you dial into me, you will
get a welcome banner and a login: prompt.

Lets say you put in your username, then get the Password: prompt,
and you put that in too.

Then my system will disconnect you.  This is because my equipment
(Livingston) is set to disconnect ALL attempts to log in via
a username/password.  This is the default behavior and is in use
by the vast majority of ISPs.

What you need to do --strange as it sounds-- is to IGNORE the
login: prompt.  When you see it, TERMINATE minicom but stay
connected using CONTROL-A Q,  then start your pppd program. Of
course, you MUST have PAP authentication enabled by having the
proper entries in /etc/ppp/pap-secrets.  This is merely your
username and password, but for PAP - not for an expect-send 
sequence.

Unfortunately, although quite a few of us have told RedHat that
the default PPP installation in RedHat is scripted, and will not
work for most isp's, they persist in making this the default.

Look at Windows 95.  If you did not write a script, and if you
do not use a "terminal window", but merely put your username
and password in the "connect to" box just before you dial the
isp, then you are using PAP authentication and none of that
terminal or scripted junk.  You must likewise do in Linux.

Onions to RedHat for this newbie-eating trap.  They need to
reverse the thing.  By making PAP the default, and the
scripted expect-send thing the OPTION.

===

Subject: Re: trouble with ppp
From: Jan Carlson <janc@iname.com>
Date: Sun, 13 Jun 1999 01:21:55 -0400


Gary Neff wrote:
> 
> I have upgraded to redhat 6.0 and everything works fine , I have one problem
> I cant seem to figure out. I can connect my isdn external modem to my isp if
> I utilize linuxconf and go to the ppp/slip/plip section and then click on
> ppp and then use the connect button displayed.
> I cannot connect using kppp or the ppp dialer in gnome which shows a
> connection but no data flows. as they do not seem to see the carrier. kppp
> worked fine before upgrade and I am stumped can anyone offer any advice?

In Linuxconf PPP setup:
Turn on PAP.
Erase all expect and send blanks.
Fill in your ISP username/password in the PAP tab.

Linuxconf nameserver setup:
Enter your ISP's nameservers IP numbers.

Check "user can start/stop connection"

===

Subject: Re: Well I'll be damned!
From: Ramon Gandia <rfg@nook.net>
Date: Sun, 13 Jun 1999 00:47:30 -0800


Peter Kiem wrote:
> 
> >What method did you use to set up PPP?  PAP or chat scripts?
> 
> I just fired up Linuxconf, selected the modem port (/dev/ttys0), put in the
> phone number, put in my fixed IP address in the "Local IP address" area and
> put my username and password in the PAP area.
> 
> Told it to connect and it dialed out and connected - no fuss.

This is what I have been saying all along.  Leave the chat
scripts BLANK, and use PAP.  It will be just like a Win95
hookup then.

===

Subject: Re: RH6 / pppd
From: Steve Borho <sborho@ststech.com>
Date: Fri, 18 Jun 1999 15:57:05 -0500


On Fri, Jun 18, 1999 at 03:16:28PM -0500, Joel Golden wrote:
> 	I have created the scripts found at
> metalab.unc.edu/LPB/HOWTO/PPP-HOWTO.  The scripts run fine under root.
> I've chmod +s /etc/ppp/ppp(allscripts) and /usr/sbin/pppd.  However, it
> still denies permissions to /dev/ttyS2 to a standard user.  I'm running
> pppd as dial on demand.  Any ideas?

The chat script needs rw access to /dev/ttyS2.

gauss% ls -l /dev/ttyS2
crw-------   1 root     tty        4,  66 May  5  1998 /dev/ttyS2
gauss% chmod g+rw /dev/ttyS2

Now, add any user you want to allow the ability to bring PPP up to the
tty group.

===

Subject: Re: ifdown ppp0 not always working
From: Hal Burgiss <hdb@iglou.com>
Date: Wed, 21 Jul 1999 18:37:40 -0400


On Wed, Jul 21, 1999 at 02:24:44PM -0400, mepr@ilnk.com wrote:
> A great deal of the time, when I do "ifdown ppp0" it does not
> work.  What could be wrong?  The only way I have found to disconnect
> when that happens is to kill the pppd process manually.  That is
> not cool
> 
> Mark
> 

This doesn't really solve your problem, but this is from the ppp-down
script that is included with pppd rpm:


  # kill the ppp daemon ...
  if [ -f /var/run/$DEVICE.pid ]
   then
    kill -INT `cat /var/run/$DEVICE.pid`

      if [ ! "$?" = "0" ]; then
          rm -f /var/run/$DEVICE.pid
          echo > "`basename $0`: ERROR, Removed stale pid file"
      fi

  fi

which is just a controlled manual kill in script form. Note the "-INT"
in the kill command.


AFAIK, the only thing that might make this a little sticky is if you have
anything in ifup-post (or similar), then this may not be resetting
everything as it should.

===

Subject: Re: 56k CONNECTS at last but no web pages
From: Hal Burgiss <hdb@iglou.com>
Date: Wed, 21 Jul 1999 20:41:44 -0400


On Wed, Jul 21, 1999 at 07:38:00PM -0500, Benjamin Sher wrote:
> Dear Brian and friends:
> 
> Yes, I am sure that's the problem. But I don't know how to switch from
> my ADSL modem to my 56k modem. I have been told by many that it's a
> question of routing, that I have to set the routing correctly. But
> that's the whole issue. I don't know quite what I should do. I know one
> thing for sure: the ADSL works perfectly and the 56k modem connects to
> the Internet (through Bellsouth) perfectly (at 38,000) but I cannot
> connect to any Web server. Thus no web pages. I am sure the main utility
> to configure all this is netcfg but I just don't know what data I should
> enter and where.
> 

Save a copy of your /etc/ppp/options, and try adding these lines. Note
that this may screw with your ADSL config, but I know nothing of how
that is setup. You probably can do this with netcfg, but I don't use it
so not for sure.

         defaultroute
         0.0.0.0:0.0.0.0
         noipdefault
         netmask 255.0.0.0 
                                     

===

Subject: CNET 56k and ADSL Saga -- Routing SOLVED!
From: Benjamin Sher <sher07@bellsouth.net>
Date: Wed, 21 Jul 1999 20:44:37 -0500

Thanks to the suggestions and advice of so many wonderful people on both
the Red Hat and Hedwig Lists, I have finally found the solution to the
CNET 56k Routing problem.

After 13 hours straight online, I was finally able to find the missing
link in this puzzle. Of course, I would have never figured this out
without the help of so many of you. The consensus by late afternoon was
clearly that this was a routing issue, that Linux did not have the
routing information for my 56k to enable it to connect to a Web server.
That was right on target. Similarly, my earlier problem of an infinite
loop of connecting and reconnecting was caused by setting the connection
speed at 56k. When I lowered it to 38,000, my modem connected fine every
time.

So, what's the solution? The solution is to assign the default gateway
route to the modem. Several people said so in just these words. But the
place for this switch is not only in netcfg (where there is an option
for this under ppp0) but also, that is, in addition to netcfg, in KDE's
kppp. In kppp, under Accounts (of all places), highlight your IP
(bellsouth, in my case). This brings up a whole new set of tabs, one of
which is Gateway. On this tab, select Default Gateway at the top and
then, the critical and key option, at the bottom, select "Assign the
Default Route to this Gateway." It was this that finally made it
possible for me to connect to the Web, etc. in Netscape. After using my
ADSL for four months (the CNET 56k is a backup for it), I have never
been so happy to see a Web page download so slowly!

You should, of course, also add ppp0 to your netcfg and configure it
before using KDE's kppp Setup.

However, the solution is not quite perfect, as it turns out. So, there
remains one final puzzle. When I turn on my dial-up modem and connect to
the Internet, I find that I cannot launch ANY application, either from
KDE's menu or panel. The only way it works right now is for me to bring
up Netscape FIRST, then get rid of any error messages by clicking on the
OK on the Error box and then dial my 56k modem. It will dial perfectly
well each time (ending with "Done"), then I minimize it and go to
Netscape and go to any Web site I wish and get my mail. However, if I
want to launch xterm or an FTP client or any application AFTER I am
already online, I can't. Hopefully, one of you gurus can help me through
this last step, though I am quite relieved to get online with my dial-up
modem.

My thanks again to everyone who helped. It's been quite an ordeal. If
anyone has any suggestions on how to overcome the last obstacle, please
let me know.

===

From: ymg@azstarnet.com (Warrior)
Date: Sat, 16 Jan 1999 21:19:05 -0700
Subject: Re: Linux PPP Interface Setup Help
Newsgroups: comp.os.linux.setup

In article <77rivr$iem$1@nnrp1.dejanews.com>, vdavis@nerds.com writes:

> I am having trouble establishing a connection with the
> XWindows PPP Interface. After dialing, the modem looks
> like it is attempting to negotiate a connection, but after
> 45 seconds it drops the connection.  It looks like it is
> unable to authenticate username and password.  I have it
> setup to expect "ogin:" then send my username, then
> "word:" then send my password.  I am using a External
> USRobitics 56k X2 modem and I am using AT&F1 for an init
> string.  I have the Debug box checked in the Interface
> setup but I never see a debug dialog.  Is there another
> init string I should be using? How can I see what is going
> on?

Add `debug' and `kdebug 7' to your /etc/ppp/options file,
try to dial out, then check /var/log/messages to see what's
going on.

===

Subject: Re: How do you dial isp via win 95
From: Jan Carlson <janc@iname.com>
Date: Wed, 15 Sep 1999 22:08:52 +0000


Syd Carter wrote:
> 
> Is there a program like dialup networking program that would initiate the
> /sbin/ifup ppp0 command to the linux server?

I like "modem-lights".  It's small, cute and it works.

Run RH6 and Gnome.  Right-click task bar.  
Add Applet | Network | Modem-Lights.

Configure it - 
up command = /sbin/ifup ppp0
down command = /sbin/ifdown ppp0
lockfile = blabla..ttyS0  (Use the same device ppp0 uses.)

===

Subject: Re: ssh
From: "Todd A. Jacobs" <nospam@codegnome.org>
Date: Tue, 7 Dec 1999 13:41:25 -0800 (PST)


On Tue, 7 Dec 1999, Steve Lee wrote:

> how do i setup ssh not to timeout at all.

Remove the IdleTimeout setting in sshd_config.

===

Subject: Re: ssh
From: Steve Lee <maillist@blitzen.net>
Date: Tue, 7 Dec 1999 13:56:07 -0800 (PST)


i don't have that in my sshd_config
is it this instead

LoginGraceTime 600

===

Subject: ssh-1.2.27-7 RPMs (security update)
From: Jan Kasprzak <kas@informatics.muni.cz>
Date: Tue, 7 Dec 1999 11:51:07 +0100

	I have built the new RPMs of secure shell. The only one fix
since the previous release is the buffer overrun fix in RSAref (rsa.c),
described in Core-SDI advisory from December 1. Thanks to Oystein Viggen
for reporting this.

	RPMs are available in source form as well as the binaries for
i386 (glibc2.1 and 2.0), alpha and sparc (32-bit). All packages are
PGP-signed by my key <kas@fi.muni.cz> and are available at

	ftp://ftp.fi.muni.cz/pub/ssh/local-fi.muni.cz/linux/

and they will be available at ftp.zedz.net (used to be ftp.replay.com)
soon (currently the packages are uploaded in /pub/replay/incoming).

===

Subject: Re: restricted shells
From: Rick Moen <rick@hugin.imat.com>
Date: Wed, 15 Sep 1999 10:58:36 -0700


Quoting Jerry Wilcox (jwilcox@slip.net):

[http://linuxmafia.com/pub/linux/security/ssh-clients:]

> In case you haven't already found out, this link, plus other links 
> you posted in this series of articles, gets a '404 Not Found'.

My apologies:  I moved my public ftp tree, late last night, and
forgot to tell Apache about it.  All the aforementioned URLs should
be fixed, now.

I was trying to find a more-secure ftpd than wu-ftpd-academ and ProFTPd,
both of which have crufty design and a history of problems.  I finally
settled on TrollTech's free-software troll-ftp (after a bizarre
misadventure with Dan Bernstein's anonftpd).

===
Subject: Re: cron job and ppp
From: Jan Carlson <janc@iname.com>
Date: Wed, 15 Sep 1999 19:15:38 +0000


David Talkington wrote:
> 
> > The commands to connect and disconnect ppp, on rh6, are
> >
> > /sbin/ifup ppp0
> > /sbin/ifdown ppp0
> >
> > assuming that ppp0 is the one you want.
> 
> An aside here, but could you perhaps explain why that doesn't work on my
> installation?  

If you use Linuxconf, netcfg or netconf to set up your ppp connections, 
ifup ppp0 will work. Linuxconf is the method Red Hat documents in their 
Installation Guide.
It's the method I was talking about, since this is a Red Hat list.

There are other methods that use different connect/disconnect commands. 

IMHO, linuxconf ppp is the one that works easiest, out of the box on Red Hat,
and is quickest to learn for beginners.  Old guys like you and me
have learned other methods in the past, but those are harder to explain
to beginners.

===

Subject: Re: Modem Configuration
From: Steve Borho <steve@borho.myip.org>
Date: Thu, 16 Sep 1999 13:59:09 -0500


On Thu, Sep 16, 1999 at 10:47:17AM -0700, James Fitzgerald wrote:
> It seems that somewhere along the line the route default gets changed and I'm
> not really sure where that is (or when) that is yet. After this command is
> issued the connections will work well for a while, when they stop working this
> command as root will fix things. What I need to figure out is how to prevent
> this default route from getting messed up in the first place. I am not sure
> how this effects the ethernet connections on this system, as there are none as
> of yet. Anyone out there have any ideas of suggested reading material that
> could enlighten me on how to understand/fix this?

if pppd is given the 'defaultroute' option (either through the command
line or placed in /etc/ppp/options), it will attempt to create a default
route through your IP link every time it brings up an PPP connection to
your ISP.  This default route is deleted automatically when the IP link
goes away.  Linuxconf has a box you can check that will automagically add
the defaultroute option to pppd for you. kppp does this by default, since
it assumes that your PPP link will always be your default route to the
internet.

Where you run into problems is when your initscripts set up a default
route through some other network device when your machine is booted.  pppd
cannot create a default route if one already exists.  To make sure your
Red Hat box doesn't do this to you, edit /etc/sysconfig/network and
comment out the two GATEWAY lines.

===




the rest of The Pile (a partial mailing list archive)

doom@kzsu.stanford.edu