HDTenEightyP/NetNews huggingface dataset:
From: bob@MorningStar.Com (Bob Sutterfield)
Subject: Re: Dial on demand ppp & slip together ?
Organization: Morning Star Technologies
Date: Sat, 26 Sep 1992 23:05:04 GMT

In article <1a1imaINNbdo@huon.itd.adelaide.edu.au> dclunie@sirius.ucs.adelaide.edu.au (David Clunie) writes:
   ...I thought I'd get the ppp one going and later hack it do both
   ppp and slip depending on some configuartion parameter.

   Before I start, I thought I'd just ask if anyone else had done this
   before and had any success !

When we released v1.0 of Morning Star PPP, it did only PPP.  We stuck
our noses in the air and proclaimed that we were such purists that we
wouldn't bother supporting the ancient, ill-defined, less-functional,
nonstandard SLIP.  But then we kept hearing from customers who had to
talk to hosts that talked only SLIP, and the protocol purity party
line seemed to make less and less capitalistic sense.

So I spent a morning experimenting, and found that once the on-demand
dialing, idle-line hangup, packet filtering, IP interface, VJ
compression, and all that other work has been done, it's really pretty
simple to short-circuit the FCS generation and checking, the asyncmap
handling, and all of PPP's other useful features.  I hot-wired the
finite state machine to "Opened", since SLIP has no negotiation phase.

So our PPP daemon quickly had a "slip" command line option.  Since it
was already there, it was easier to delta it into our SCCS'd sources
than to rip it out again.  Maybe another half-day total since then has
been spent debugging and documenting it, and adding a convenient
peer-CSLIP-capability-detection feature.  So it shipped in v1.1, and
now the marketing folks have another feature for their bullet list.

Our source is probably significantly different from source of the
Purdue on-demand dialing implementation you said you were about to
try, but I don't know how different because I haven't looked at the
Purdue code.  I know for sure that our product is quite a bit
different from the other popular free Sun-based PPP code.  But you
still shouldn't have too much trouble making any existing PPP
implementation do SLIP, since SLIP is such a simple protocol.
From: bill@mars.dgrc.doc.ca (Bill Robertson)
Newsgroups: comp.protocols.ppp
Subject: ka9q/net
Date: 2 Oct 92 17:59:56 GMT
Reply-To: brobert@oups.dgrc.doc.ca
Organization: Sun Microsystems, Inc.

I'm setting up a ppp connection between a PC running KA9Q/net and a sun running
MST ppp.
Is this a good forum to ask questions?
Is there a better place?
Is there a mailing list for KA9Q (I couldn't find one in the list of lists).
---
Bill Robertson CRC/DRL Box 11490 Station H, Ottawa, ON CANADA K2H 8S2
Voice:(613)998-2819 Fax:990-7987 bill@mars.dgrc.doc.ca 
Newsgroups: comp.protocols.ppp
From: souva@aibn58.mpifr-bonn.mpg.de (Ignatios Souvatzis)
Subject: Re: Dial on demand ppp & slip together ?
Reply-To: isouvatzis@babsy.mpifr-bonn.mpg.de
Organization: Radioastronomisches Institut der Universitaet Bonn, Bonn, FRG
	<BGLENDEN.92Sep28101658@colobus.cv.nrao.edu>
Date: Mon, 28 Sep 1992 19:11:34 GMT

Err...  get dp-2.2-beta.tar.Z, there are only two swall typos in the
Makefile (I can send you the patches), and it's much better documented
and usable than -2.0.


--
Paper mail: Ignatios Souvatzis, Radioastronomisches Institut der 
            Universitaet Bonn, Auf dem Huegel 71, D-5300 Bonn 1, FRG
Internet:   souva@babsy.mpifr-bonn.mpg.de ignatios@cs.uni-bonn.de
From: perkins@cps.msu.edu (Stephen Perkins)
Newsgroups: comp.protocols.ppp
Subject: Sparc eating extra characters
Date: 28 Sep 92 02:23:13 GMT
Organization: Dept. of Computer Science, Michigan State University
Originator: perkins@indian.cps.msu.edu

I have had a terrible time getting PPP to run on my
current setup.  I had it working at one location, and
after I moved, I tried to install it at another.  The
configuration is that I have PPP running on a Sparc1+
running SunOS 4.1.1 and PPP on a NeXT at home.  Everything
works fine except that when I try to do binary FTP transfers,
9 times out of 10, the Sparc will crash.

I think that I have narrowed down the problem. I wrote two simple test
programs that are designed to test the link.  They determine which
characters are being eaten as they are sent across (One program
writes, one reads).  Now, if I run the programs like:

   writeit | readit

without going over the link I get:
  Lost char number 9
  Lost char number 10
  Lost char number 11
  Lost char number 12
  Lost char number 13
  Lost char number 32
This is true on my NeXT and on our sun server.

When I run this over the modem link (and through the terminal server
that was in binary mode) I get the same thing.  This is OK because PPP
automatically escapes these characters and they get sent across fine
(asyncmap of all ones).

However, when I run the same program at the command prompt on the
Sparc running PPP I get (Please note that I am using kermit
to do these tests, not telnet or rlogin via PPP):

  Lost char number 9
  Lost char number 10
  Lost char number 11
  Lost char number 12
  Lost char number 13
  Lost char number 32
  Lost char number 134
  Lost char number 142
  Lost char number 150
  Lost char number 158
  Lost char number 166
  Lost char number 174
  Lost char number 182
  Lost char number 198
  Lost char number 206
  Lost char number 214
  Lost char number 221
  Lost char number 222
  Lost char number 234
  Lost char number 249
  Lost char number 250

Low and behold, I get the same characters lost when going over the
modem link.  These characters (the ones of value > 32) are not
automatically quoted by PPP.  They are being eaten and this is 
probably what causes the kernel to crash.

I checked the tty settings (via "stty everything") and they are
identical between the PPP sparc and our Sun server.  I also tried the
csh instead of tcsh. Both Suns (PPP Sparc and server) are running
SunOS 4.1.1.

Anybody have any ideas why the PPP Sparc is eating the extra
characters??

Any help would be sincerely appreciated.

Thanks,

Steve




-- 
====================================================================
Stephen Perkins                    |
Department of Computer Science     | perkins@cps.msu.edu
Michigan State University          |
Newsgroups: comp.protocols.ppp
From: mishra@controls.ccd.harris.com (Sanjoy Mishra)
Subject: ppp on 386 SVR4
Originator: mishra@sp1
Organization: Harris Controls
Date: Mon, 28 Sep 1992 17:43:05 GMT


Hi:

   Has anyone ported ppp to 386 based unix (SVR4). I have two PC
    and modems. I would like to explore how ppp works. 

   Thanks for all the help in advance

Xref: sparky comp.protocols.ppp:823 comp.sys.sun.admin:6893
From: rob@violet.berkeley.edu (Rob Robertson)
Newsgroups: comp.protocols.ppp,comp.sys.sun.admin
Subject: sun 4/470 + ALM-2 dies panics with "mget".  SunOS 4.1.1
Date: 2 Oct 92 13:59:41
Organization: /home/math_a/cc/rob/.organization
NNTP-Posting-Host: hanalei.berkeley.edu


This is probably a FAQ, but...

I'm running Cslip on our sun4/470 with SunOS 4.1.1, and it routinely
dies with a 'panic: mget'.  it only does this with connections over
our ALM-2 board, not ttyb....

Does anyone know of a sun patch to fix this?  What causes it?

rob



--
			  william robertson
		       rob@violet.berkeley.edu

     "when i was your age, i walked 10 miles to school, unarmed."
Newsgroups: comp.protocols.ppp,comp.dcom.isdn
From: vulture@carrion.cc.ic.ac.uk (Thomas Sippel - Dau)
Subject: Re: compression over isdn links
Reply-To: cmaae47@cc.ic.ac.uk
Organization: Imperial College of Science, Technology and Medicine
Date: Mon, 28 Sep 92 09:53:19 BST

In article <1992Sep24.183440.2719@advtech.uswest.com>, huntting@advtech.uswest.com (Brad Huntting) writes:
- In article <1992Sep22.202619.3942@cc.ic.ac.uk> cmaae47@cc.ic.ac.uk (me):
- > compression "belongs" into layer 6 (presentation)
.....
- Putting compression above the network layer is a mistake.  I dought
- that compression would help speed up a large file transfer over FDDI.

Only if the file has not been encrypted. Thus you may catch a lot now,
but soon you will have no more benefit from compression, as most network
traffic will become encrypted.

- The complexity you would add to each application would be expensive
- enough that noone would use it.

That's why it should be in the presentation layer, so that no application
needs to bother with compression.

- You can deal with bad interactive response by devising a good heuristic
- method to determine the nature of the trafic over the line.

Actually, no, heuristics don't help, devolving response management to 
somewhere near the user would. Unfortuanately (misguided) software develoment
has put response (for screen editors) as far as possible away from the user,
but that is another battle.

                                    Thomas
--
*** This is the operative statement, all previous statements are inoperative.
*   email: cmaae47 @ cc.ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic.cc on Janet)
*   voice: +44 71 589 5111 x4937 or 4934 (day), or +44 71 823 9497 (fax)
*   snail: Imperial College of Science, Technology and Medicine
*   The Center for Computing Services, Kensington SW7 2BX, Great Britain
From: edhall@rand.org (Ed Hall)
Newsgroups: comp.protocols.ppp
Subject: Re: Modem Advice
Date: 28 Sep 92 23:09:53 GMT
Organization: RAND

On getting reasonable interactive performance during bulk data transfers:

One of the reasons re-ordering the transmit queue only produces a
moderate gain in interactive responsiveness is buffering in the modem
itself.  The packet may go to the front of the queue, but there can be
more than a kilobyte of data that needs to be transmitted before it
reaches the wire.  See if your modem allows adjustment of its internal
buffer size.

Lowering the MTU can help, too, since once a 1500-byte packet starts
its way to the modem, you're going to have to wait for it to finish.

If you can lower the TCP window size to something small (~512 bytes)
you'll improve interactive performance during FTP's a /lot/.  This will
slow down your transfer some (as will lowering the MTU), but it will
actually help interactive performance in spite of any modem buffering.
Alas, it can be difficult to coax most Unix systems to lower their TCP
window size; I did it with KA9Q and managed a threefold improvement in
round-trip times with only a 20% hit on the (one-way) FTP throughput.
The trick was getting the window size down to the point where ACKs
were getting back just in time.  (It was a while ago, but I think
this was with an MTU of 384 and window size of 512.)

I wish that Unix allowed more tinkering with TCP/IP parameters...

		-Ed Hall
		edhall@rand.org
Newsgroups: comp.protocols.ppp
From: mikey@yoho.carleton.ca (Mike G McFaul)
Subject: Does ppp run on a sun386i running 4.0.3?
Organization: Carleton University, Ottawa, Canada
Date: Tue, 29 Sep 1992 14:22:45 GMT


I know the public domain 'ppp' runs on sparc systems (I'm using 'ppp
patch level 6 right now), but a friend of mine is purchasing a Sun386i
for a home computer and wants to use 'ppp' to connect to work. The
readme file for the product says it was originally developed on a
386i, but that was probably a long time ago. Does anyone know if it
works and is anyone doing this with a 386i? If you have it working what
is it like?

Email or post, I'll summarize back here...
Newsgroups: comp.protocols.ppp
From: rees@pisa.citi.umich.edu (Jim Rees)
Subject: Re: Looking for help with a PPP problem
Reply-To: Jim.Rees@umich.edu
Organization: University of Michigan IFS Project
Date: Mon, 28 Sep 1992 21:39:10 GMT

In article <3832@randvax.rand.org>, edhall@rand.org (Ed Hall) writes:

  Telebit Worldblazers work just fine with PPP--many people use them
  for that purpose--but TurboPEP is simply not compatible with PPP
  and interactive use.

If you use vj header compression and have a clean line, you can get the
modem to go into micro/long mode (I think that's right) and the latency goes
way down.  It doesn't turn the channel around in this mode.  I used to run
that way and it was fine for interactive use, if you didn't have anything
else going on at the same time.

But for general purpose ip use, you're usually better off with v.32bis.
PEP is for people stuck with obsolete, window-deprived software that the
modem knows how to spoof (uucp or kermit, for example).  Or for people stuck
with inferior phone lines.
From: claes@sparc2.ikb.uni-essen.de (Heinz-Josef Claes)
Newsgroups: comp.protocols.ppp
Subject: PPP for Atari-ST
Keywords: PPP Atari
Date: 28 Sep 92 12:02:18 GMT
Organization: University of Essen, Germany


I've a Sparc and an Atari-ST. Till now, I've a connection with SLIP, and I would
like to use PPP between them. At work, I've connected to Sparcs with PPP, an it
runs very fine. Someone told me, that PPP is now also awailable for Atari.

Is there any implementation of PPP for Atari-ST?

Thanks in advance.


Heinz-Josef Claes
University of Essen
Germany

email: claes@sparc2.ikb.uni-essen.de



Newsgroups: comp.protocols.ppp
From: souva@aibn58.mpifr-bonn.mpg.de (Ignatios Souvatzis)
Subject: dp-2.2-beta ftp site
Reply-To: isouvatzis@babsy.mpifr-bonn.mpg.de
Organization: Radioastronomisches Institut der Universitaet Bonn, Bonn, FRG
Date: Tue, 29 Sep 1992 17:48:08 GMT

Before I get drenched by mail messages:

dp-2.2-beta.tar.Z can  be  found on  phoenix.acn.purdue.edu, user ftp,
directory pub/

Look for Readme's etc. there, too. Don't ask me.

--
Paper mail: Ignatios Souvatzis, Radioastronomisches Institut der 
            Universitaet Bonn, Auf dem Huegel 71, D-5300 Bonn 1, FRG
Internet:   souva@babsy.mpifr-bonn.mpg.de ignatios@cs.uni-bonn.de


Newsgroups: comp.protocols.ppp
From: rees@pisa.citi.umich.edu (Jim Rees)
Subject: Re: Broadcast over SLIP
Reply-To: Jim.Rees@umich.edu
Organization: University of Michigan IFS Project
Date: Tue, 29 Sep 1992 21:41:12 GMT

You've missed the point.  He's using proxy arp to make his serial link (and
the machine at the other end of it) seem to be part of his ethernet, and now
he's surprised when broadcast packets on the ethernet don't reach the far
end of the serial link.  This is yet another example of why proxy arp is bad
and routing is good.
Newsgroups: comp.protocols.ppp
From: Klaus P. Fechner <klaus@sparky.rad.med.umich.edu>
Subject: Re: PPP for the mac?
Date: Sat, 03 Oct 92 23:22:10 EDT
Organization: University of Michigan
X-Useragent: Nuntius v1.1.1d12
X-Xxdate: Sat, 3 Oct 92 23:26:34 GMT

Merit in Ann Arbor, Michigan, info@merit.edu, is working on it; last I
heard they will have it finished 
before year's end.

Klaus

klaus@sparky.rad.med.umich.edu


In article <1543600002@igc.apc.org> Howard Levine, hlevine@igc.apc.org
writes:
>
>I'm not sure about ppp, but I know that VersaTerm v4.6.1 comes with a
>program called VersaTerm ADMIN-Slip which allows SLIP connections
>over the modem.  You then can Telnet to other IP hosts.
>
>hlevine@igc.org
>
Newsgroups: comp.protocols.ppp
From: bglenden@colobus.cv.nrao.edu (Brian Glendenning)
Subject: Re: Dial on demand ppp & slip together ?
Organization: National Radio Astronomy Observatory
Date: Mon, 28 Sep 1992 15:16:58 GMT

In article <1a1imaINNbdo@huon.itd.adelaide.edu.au> dclunie@sirius.ucs.adelaide.edu.au (David Clunie) writes:
   I am about to set up a dial-on-demand style ppp link (you know - when
   a tcp/ip packet or whatever comes along it gets queued until the
   phone link is dial, which later times out if not needed). I am
   planning on using "dp.2.0.tar.Z" to do the job, which seems easy
   enough to install.
   [...]

The copy of this I have doesn't have any documentation on how to
actually use the programs that get made (the README says what the
various directories contain in a very general way). While I can
probably figure it out from the etc/* samples, I thought I'd ask for
documentation first.

Brian
--
       Brian Glendenning - National Radio Astronomy Observatory
bglenden@nrao.edu          Charlottesville Va.           (804) 296-0286
Newsgroups: comp.protocols.ppp
From: cbwierda@ar14darlrk.er.usgs.gov (Clark B. Wierda)
Subject: Re: Broadcast over SLIP
Organization: US Geological Survey, WRD, Arkansas District
	<9209291627.AA01593@volitans.morningstar.com>
	<5b773038.1bc5b@pisa.citi.umich.edu>
Reply-To: cbwierda@ar14darlrk.er.usgs.gov
Date: Thu, 1 Oct 1992 01:42:27 GMT
X-Posted-From: ar14darlrk.er.usgs.gov
NNTP-Posting-Host: sol.ctr.columbia.edu

Thanks for the info.  I wouldn't call either method 'good' or 'bad'.
Each has certain advantages and problems.  The lack of broadcast is a
very minor point to me.  The simpler routing administration required
is much more important

--
Clark B. Wierda	               	    Phone:     501-324-6391
Federal Office Building, Room 2301  Internet:  cbwierda@ar14darlrk.er.usgs.gov
Little Rock, AR 72201
Newsgroups: comp.protocols.ppp,de.comm.internet
From: ignatios@theory.cs.uni-bonn.de (Ignatios Souvatzis)
Subject: cs.uni-bonn.de patches to dp-2.2-beta
Organization: /home/theory/ignatios/.organization
Date: Fri, 2 Oct 1992 16:01:23 GMT

I uploaded the cs.uni-bonn.de patches to dp-2.2-beta to 

* phoenix.acn.purdue.edu, directory incoming/ (hopefully soon in pub/)
* theory.cs.uni-bonn.de, directory pub/ppp/

Read the README-2.2-beta-cs.uni-bonn.de file for the changes made.

--
	Ignatios Souvatzis
	ignatios@cs.uni-bonn.de souva@babsy.mpifr-bonn.mpg.de
Newsgroups: comp.protocols.ppp
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Modem Advice
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 29 Sep 1992 02:35:36 GMT

In article <1a817gINNmn2@nigel.msen.com>, emv@msen.com (Edward Vielmetti) writes:
> Jim Rees (rees@pisa.citi.umich.edu) wrote:
> : 
> : I don't understand why this queueing was done on the basis of tcp port
> : number rather than packet size.  Wouldn't it be far more general to put all
> : packets below a certain size on the fast queue?  I know this would result in
> : some packet re-ordering within connections, but that should be ok.
> 
> my guess is that this would do perverse things to round-trip estimators,
> and that you'd have tcp implementations getting confused about just how
> fast and how congested the link was.  e.g. the acks would come back "too
> fast" and overly encourage the production of new big packets to clog the link.
> 
> you'd want to try it out to see, of course, but i suspect that in general
> you'll have better results if you skew performance on a per-connection
> basis rather than a per-packet basis.


Using packet size works fine for me with SLIP.  I have never noticed
any RTT related oddities.

It seems much cleaner to look at packet sizes than having a list of
"interactive" port numbers wired into a kernel driver.  Which port
numbers would you use?  How do you handle local interactive protocols?
What about interactive ports dynamically allocated by the RPC
portmapper?  Are rsh port numbers "interactive"?  What about rcp
traffic?  What about X--much of it is clearly interactive, but some of
it will saturate a T3 link for as long as you want to pay for it.

Of course, you have to check both the source and the destination port
number.

Feel free to buy an SGI machine and check it out for yourself.  Don't
forget to tell the salescritter who sent you.  I won't get any
commission, but maybe they'll stop saying those things about me.

Slow start does terrible things on very slow links if your hosts use
windows larger than the queues on the links.  Eventually it causes a
lost packet, and then a retransmission of a window's worth.  That has
caused me far more irritation than any bogus RTT values.

I do wish common non-PPP routers would do some, any kind of TOS
queuing.  The default window size on SGI machines is 60K (helps FDDI
benchmarks).  Trying to use the SGI corporate WAN for interactive
traffic while someone is rcp'ing a 600 MByte CDROM over the same 56K
links is Not Fun.  Character echos suffer 6-12 second delays.
(again, should "rsh" be counted "interactive" traffic?)


No matter what TOS queuing you use, if you use Telebit modems, it pays
to reduce the 3.5KBytes of in-the-modem buffering with PEP.  They gave
me a secret, magic S register to do that.  I decided it wasn't worth
the customer hassles with new modems to ship configuraton files to use
it and so forgot it.


Vernon Schryver,  vjs@sgi.com
From: dclunie@sirius.ucs.adelaide.edu.au (David Clunie)
Newsgroups: comp.protocols.ppp
Subject: Re: Dial on demand ppp & slip together ?
Date: 29 Sep 92 09:42:44 GMT
Organization: Her Master's Voice
NNTP-Posting-Host: sirius.itd.adelaide.edu.au


> The copy of this I have doesn't have any documentation ...

No. A pity ... but I have found lots of useful and relevant
advice by reviewing the documentation with dialupip - the slip
predeccessor of dp.2.0. This is particlularly true of the scripts,
though there are small "enhancements" !

Maybe if I learn enough about the program while I am hacking at it
I will write some docs ! No promises.

david
-- 
David Clunie (dclunie@itd.adelaide.edu.au)
From: dclunie@sirius.ucs.adelaide.edu.au (David Clunie)
Newsgroups: comp.protocols.ppp
Subject: Dial on demand ppp & slip together ?
Date: 26 Sep 92 11:48:26 GMT
Organization: Her Master's Voice
NNTP-Posting-Host: sirius.itd.adelaide.edu.au


I am about to set up a dial-on-demand style ppp link (you know - when
a tcp/ip packet or whatever comes along it gets queued until the
phone link is dial, which later times out if not needed). I am
planning on using "dp.2.0.tar.Z" to do the job, which seems easy
enough to install.

However some of the sites I want to connect to want to use slip not
ppp, so then I thought fine, I'll just install "dialupip2.0.tar.Z"
as well.

Then I thought, this is silly, duplicating all that functionality,
and there is bound to be a conflict somewhere, so I thought I'd
get the ppp one going and later hack it do both ppp and slip depending
on some configuartion parameter.

Before I start, I thought I'd just ask if anyone else had done
this before and had any success !

-- 
David Clunie (dclunie@itd.adelaide.edu.au)
Newsgroups: comp.protocols.ppp
From: bob@MorningStar.Com (Bob Sutterfield)
Subject: Re: Broadcast over SLIP
Organization: Morning Star Technologies
Date: Mon, 28 Sep 1992 02:12:52 GMT

In article <CBWIERDA.92Sep25095844@ar14darlrk.er.usgs.gov> cbwierda@ar14darlrk.er.usgs.gov (Clark B. Wierda) writes:
   Does anyone have any experience with broadcast over SLIP?  

There's no such thing as a broadcast packet on a point-to-point link.
You either hand it to the unique peer, or you don't.  Nobody else is
listening on the wire.

   We are using NIS and this is more automatic and robust if the
   remote system can send and receive broadcasts.

Try making the remote system a slave server, rather than a client.
That way, the master server will explicitly yppush the NIS maps to the
slave server(s) whenever the maps are updated.
Newsgroups: comp.protocols.ppp
From: souva@aibn58.mpifr-bonn.mpg.de (Ignatios Souvatzis)
Subject: which dp-2* version to use
	(Was: Re: Dial on demand ppp & slip together ?)
Reply-To: isouvatzis@babsy.mpifr-bonn.mpg.de
Organization: Radioastronomisches Institut der Universitaet Bonn, Bonn, FRG
	<BGLENDEN.92Sep28101658@colobus.cv.nrao.edu>
Date: Mon, 28 Sep 1992 19:12:45 GMT

Err...  get dp-2.2-beta.tar.Z, there are only two swall typos in the
Makefile (I can send you the patches), and it's much better documented
and usable than -2.0.


--
Paper mail: Ignatios Souvatzis, Radioastronomisches Institut der 
            Universitaet Bonn, Auf dem Huegel 71, D-5300 Bonn 1, FRG
Internet:   souva@babsy.mpifr-bonn.mpg.de ignatios@cs.uni-bonn.de


Xref: sparky comp.protocols.ppp:820 comp.dcom.modems:14299
From: rouquett@Aig.Jpl.Nasa.Gov (Nicolas Rouquette)
Subject: PPP for the mac?
Reply-To: rouquett@aig.jpl.nasa.gov
Organization: NASA/Jet Propulsion Laboratory
Date: Mon, 28 Sep 1992 23:46:33 GMT

Is there any version of PPP for the mac (PD or MorningStar)?
I.e., work: sun, home: mac, in between ppp over modems.

-- 
----------Nicolas Rouquette----------rouquett@aig.jpl.nasa.gov
    Artificial Intelligence Group
      Jet Propulsion Laboratory