HDTenEightyP/NetNews huggingface dataset:
From: brad@Cayman.COM (Brad Parker)
Newsgroups: comp.protocols.ppp
Subject: Re: AppleTalk via PPP?
Date: 1 Sep 92 11:16:05 GMT
Followup-To: comp.protocols.ppp
Organization: Cayman Systems Inc., Cambridge, MA
In-reply-to: jnm@ornl.gov's message of 31 Aug 92 17:50:35 GMT

In article <jnm-310892135014@baloo.ctd.ornl.gov> jnm@ornl.gov (Jamey Maze) writes:

   I'm reading an article from the 2/24/92 issue of Communications Week which
   has John Veizades from Apple saying that the IETF AppleTalk/TCP/IP Working
   Group is "firming up a specification for AppleTalk over the Point-to-Point
   protocol". Does anyone have any information about this?

The latest (and hopefully final) version of the specification is up a an
internet-draft.  Here is a copy of the announcement:


A Revised Internet Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the 
Point-to-Point Protocol Extensions Working Group of the IETF.

Note: This revision reflects comments received during the last call period.

       Title     : The PPP AppleTalk Control Protocol (ATCP))         
       Author(s) : Brad Parker
       Filename  : draft-ietf-pppext-appletalk-03.txt
       Pages     : 20

The Point-to-Point Protocol (PPP) provides a standard method of 
encapsulating Network Layer protocol information over point-to-point 
links.  PPP also defines an extensible Link Control Protocol, and 
proposes a family of Network Control Protocols (NCPs) for establishing
and configuring different network-layer protocols.                    

This document defines the NCP for establishing and configuring the  
AppleTalk Protocol over PPP.                                          

Internet-Drafts are available by anonymous FTP.  Login with the	
username "anonymous" and password "guest".  After logging in,
Type "cd internet-drafts".
     "get draft-ietf-pppext-appletalk-03.txt".
 
Internet-Drafts directories are located at:	
	                                                
     o  East Coast (US)                          
        Address:  nnsc.nsf.net (128.89.1.178)	
	                                                
     o  West Coast (US)                          
        Address:  ftp.nisc.sri.com (192.33.33.22)
							
     o  Pacific Rim                              
        Address:  munnari.oz.au (128.250.1.21)	
	                                                
     o  Europe                                   
        Address:  nic.nordu.net (192.36.148.17)	
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mail-server@nisc.sri.com. In the body type: 
     "SEND draft-ietf-pppext-appletalk-03.txt".
							
For questions, please mail to internet-drafts@nri.reston.va.us.
--
A metaphor is like a simile.

Brad Parker	Cayman Systems, Inc., Cambridge, Ma.	brad@cayman.com
Newsgroups: comp.protocols.ppp
From: rparra@usachux1.usach.cl (Rafael de la Parra)
Subject: Where can I find something about ppp?
Organization: Pontificia Universidad Catolica de Chile
X-Newsreader: Tin 1.1 PL4
Date: Wed, 26 Aug 1992 01:51:52 GMT


	Hello 



	I want to learn something about ppp where do I must start???





Newsgroups: comp.protocols.ppp
From: bob@MorningStar.Com (Bob Sutterfield)
Subject: Re: ppp on SLC help.
Organization: Morning Star Technologies
Date: Thu, 27 Aug 1992 21:08:21 GMT

In article <stevew.714932367@helios> stevew@helios.unl.edu (Steve Wu) writes:
   Hi, I need some help on MorningStar PPP setup.  We have one SS2 run
   4.1.2 with PPPbeta1.01 ...

That's not a version number that corresponds to anything we've ever
used for our UNIX networking product, Morning Star PPP.  I suspect
you're using the popular free PPP implementation that's widely
available around the Internet.  It passed through here and got some
porting and polishing work on its way to its current maintainers,
which is why you see our company's name on the READMEs, but what you
have is definitely not our very own Morning Star PPP.  If it were our
product, (a) this bug wouldn't have happened, and (b) if it had
happened, you could have written to support@morningstar.com and it
would have been quickly fixed.

   The problem I have now is when I run ppp on SLC, I have the
   following message:

      ppp:  tcsetpgrp(): inappropriate ioctl ...

That's a problem I seem to remember some users of the free stuff
discussing in this forum, but I don't remember the resolution.  Sorry,
but I doubt that anyone here (including our long-lost vacationing
Karl) will be able to help you much, since it's not our product and we
haven't seen that code for well over a year now.
From: perkins@cps.msu.edu (Stephen Perkins)
Newsgroups: comp.protocols.ppp
Subject: assertion failure when FTPing
Date: 30 Aug 92 05:31:49 GMT
Organization: Dept. of Computer Science, Michigan State University
Originator: perkins@indian.cps.msu.edu


I have installed ppp-sunos4.1.pl6.tar with patches:
   ppp-sunos4.1.patch6
   ppp-sunos4.1.pl6.mem_leak.patch

on a Sparc1.  I am running the NeXT PD version of PPP from home.  I
had a similar setup working from a Sparc IPX and my NeXT with no
problems.  However, now, when I try to FTP a large file on the new
setup, I get a system crash and a reboot.  The transfer starts
normally and after about 60K, the /usr/adm/messages file gets (and the
machine reboots):


Aug 30 01:17:11 sol vmunix: assertion failed: dbp->db_ref > 0, file: ../../os/str_buf.c, line: 526
Aug 30 01:17:11 sol vmunix: panic: assertion failed
Aug 30 01:17:11 sol vmunix: syncing file systems... done
Aug 30 01:17:11 sol vmunix: 00000 low-memory static kernel pages
Aug 30 01:17:11 sol vmunix: 00726 additional static and sysmap kernel pages
Aug 30 01:17:11 sol vmunix: 00000 dynamic kernel data pages
Aug 30 01:17:11 sol vmunix: 00140 additional user structure pages
Aug 30 01:17:11 sol vmunix: 00000 segmap kernel pages
Aug 30 01:17:11 sol vmunix: 00000 segvn kernel pages
Aug 30 01:17:11 sol vmunix: 00041 current user process pages
Aug 30 01:17:11 sol vmunix: 00055 user stack pages
Aug 30 01:17:11 sol vmunix: 00962 total pages (962 chunks)
Aug 30 01:17:11 sol vmunix: 
Aug 30 01:17:11 sol vmunix: dumping to vp ff022a64, offset 20420
Aug 30 01:17:11 sol vmunix: 962 total pages, dump succeeded
Aug 30 01:17:11 sol vmunix: rebooting...

Anybody have any ideas what the problem may be??  Help would be
appreciated! 

Steve

-- 
====================================================================
Stephen Perkins                    |
Department of Computer Science     | perkins@cps.msu.edu
Michigan State University          |
Xref: sparky comp.protocols.ppp:745 comp.dcom.modems:12881
From: alan@ernest.dseg.ti.com (Alan Edmonds)
Newsgroups: comp.protocols.ppp,comp.dcom.modems
Subject: Re: Help with World Blazer
Date: 2 Sep 92 20:16:56 GMT
Organization: Texas Instruments, Inc. - Plano, Tx

In article <1992Sep2.172450.10844@ntg.com> dplatt@ntg.com (Dave Platt) writes:
>I have noticed that the WorldBlazer command-parser seems to have trouble
>if you blast dialing commands at it at a high serial-port speed.  Last
>night, I tried using Taylor uucp (1.03) to dial out using our
>WorldBlazer with the serial-port speed set to 38400 (and the WorldBlazer
>configuration set to use that speed, only).  The first few bytes of the
>dial-and-configuration command went out OK, as each one is followed by a
>pause to allow the modem to autobaud (not necessary in this case).

Don't take this as a flame, but
why are you using autobaud?  Just lock the DTE speed and be done with it.
That might solve your problem.  You could also break the dialing command into
pieces.    I use about a 60-80 char string for some dialing and don't
have a problem.  This is at 19200 though.  But, I would assume the input
buffer is the same size.
-- 
Alan Edmonds                                     Texas Instruments, Inc.
I don't speak for TI; TI doesn't speak for me    M/S 8513
Work phone: (214)575-6427                        6620 Chase Oaks Blvd.
Email: alan@ernest.dseg.ti.com                   Plano, Texas  75023
Newsgroups: comp.protocols.ppp,comp.dcom.modems
From: bob@MorningStar.Com (Bob Sutterfield)
Subject: Re: Help with World Blazer
Organization: Morning Star Technologies
Date: Tue, 1 Sep 1992 22:16:47 GMT

In article <1992Sep1.172122.8640@colorado.edu> laura@boulder.colorado.edu (Laura Compagnoni) writes:
   Is anybody using this modem with better luck than me?

We like ours fine.  We set it up first with

at&f9 s0=1 s7=120 s48=1 s51=6 s58=2 s59=15 s61=0 s63=1 s92=1 tq2x12&c1&d3&s1&w

which results in

WorldBlazer - SA - Version LA5.01 - Active Configuration
 B1  E1  L1  M1  Q2  T   V1  X12  Y0
&C1 &D3 &G0 &J0 &L0 &Q0 &R3 &S1 &T4 &X0
S000:1   S001=0   S002=43  S003=13  S004=10  S005=8   S006=2   S007:120
S008=2   S009=6   S010=14  S011=70  S012=50  S018=0   S025=5   S026=1
S038=0   S041=0   S045=0   S046=0   S047=4   S048:1   S050=0   S051:6
S056=17  S057=19  S058:2   S059:15  S060=0   S061:0   S062=15  S063:1
S064=0   S068=255 S069=0   S090=0   S092:1   S093=8   S094=1   S100=0
S104=0   S105=1   S111=255 S112=1   S151=4   S155=0   S180=2   S181=1
S183=25  S190=1   S191=7   S253=10  S254=255 S255=255
OK

which differs from your registers in some perhaps-significant ways.
Newsgroups: comp.protocols.ppp
From: lengge@chx400.switch.ch (Thomas Lenggenhager)
Subject: Synchronous PPP for SunOS 4.1.2 Sparc 2
Organization: Swiss Academic and Research Network SWITCH
Date: Wed, 26 Aug 1992 13:07:43 GMT

I am looking for a PPP implementation (that can be used for IP)
for SunOS 4.1.2 for a Sparcstation 2 (actually a TriGem
TGstation SDT-400).  It must run synchronously.  Preferably I
want an implementation that will run over a CPU serial port but
I am prepared to consider add-on hardware if absolutely
necessary.  I know about the stuff from Morning Star.

Please reply by e-mail to <Alan.Young@Calibre.CH>.

Thanks, Alan Young.
-- 
===============================================================================
               SWITCH - The Swiss Academic and Research Network
   Thomas Lenggenhager, SWITCH, Limmatquai 138, CH-8001 Zurich, Switzerland
   INET: lenggenhager@switch.ch | Tel: +41 1 261 8178 | Fax: +41 1 261 8133
From: pankaj@bass.bu.edu (Pankaj Tyagi)
Newsgroups: comp.protocols.ppp
Subject: Why is PPP better than SLIP
Summary: Request for Comparision of SlIP and PPP based solutions.
Date: 27 Aug 92 16:13:52 GMT
Reply-To: pankaj@bass.bu.edu (Pankaj Tyagi)
Followup-To: comp.protocols.ppp
Distribution: usa
Organization: Boston University



	Hi, This may be  a FAQ question but I have been unable to find
the answer to this question for a long time.
	WHY IS PPP BETTER THAN SLIP?

	To make this question less general I'll give a scenario that
I'm currently invloved in. 

	o I'm developing an application in which a 486 based
workstation connects to a central database (after dialing up to a
terminal server). A lot of data is interchanged between the user at
the workstationa and the central database over tcp socket connection.
Currently I'm using on the PC side SLIP provided by Chameleon with a
8250 UART talking to a Racal-Milgo Modem V42bis. That modem is capable
of giving sustained 14.4kbs and 38.2kbs burst. Using SLIP my
throughput (that is counting only usable data, not counting headers
and retransmission) is around 8kbs. which I believe is pretty good,
given thae fact that the database is not physically located in the
same place as the terminal server but is about 250 miles away
connected to the terminal server through a router and leased line.

	o Given this how much can PPP improve performance or what value
can it add to the whole process.

	o As a side note, I have before me a recent article in CW
titled "Remote user get TCP/IP sans LAN" which goes on to describe
this prduct called "SupperPPP" whic is "...layered over the Microsoft
Corp. Windows operating environment and Frontier's TCP/IP or any
industry-standard Open System Interconnect communications protocols."
	This product, it seems provides TCP/IP functionality over
serial lines and it "adds error correction, retransmission and speed
to the older SLIP for remote TCP/IP networking.....speedwise PPP could
translate into a tenfold improvement over SLIP"

	NOW is that really true. I mean I thought I was getting almost
all I could bet from my POTS line using SLIP. Can it really be true
that PPP is really that much superior to SLIP?


	Any help is appreciated.


Pankaj Tyagi
-------------------------------------------------------------------------------
#include std.disclaimer| pankaj@bass.bu.edu,pankaj@pub2.bu.edu
#if IDONTLIKEYUORQUOTE |"..I mean if I said that I'm the king just because some
#include local.joke    | watery tart lobbed me a scimitar, they'd put me away"
--
#include std.disclaimer| pankaj@bass.bu.edu,pankaj@pub2.bu.edu
#if IDONTLIKEYUORQUOTE |"..I mean if I said that I'm the king just because some
#include local.joke    | watery tart lobbed me a scimitar, they'd put me away"
----------------------- Quote from Monty Pythons "Quest of the Holy Grail------
Newsgroups: comp.protocols.ppp
From: ccewch@nuscc.nus.sg (Wong Chee Heng)
Subject: IP address allocation
Organization: National University of Singapore
Date: Thu, 27 Aug 1992 07:21:54 GMT

I am new to this group and do not know much about PPP. I just want to know 
how IP address is allocated in PPP, does the end user has to set it of the 
host being dialed can actually allocate before hand? 

Also what are the advantage of PPP over slip? Is there a FAQ somewhere that 
I can find answers to my questions? Thank you.


--
Wong Chee Heng
Systems Programmer

Newsgroups: comp.protocols.ppp
From: rypma@waterloo.hp.com (Ted Rypma)
Subject: Re: Why is PPP better than SLIP
Date: Sun, 30 Aug 1992 04:11:05 GMT
Organization: HP Panacom Div Waterloo ON Canada
X-Newsreader: Tin 1.1.3 PL5

Bob Sutterfield (bob@MorningStar.Com) wrote:
: 
:    "... speedwise PPP could translate into a tenfold improvement over
:    SLIP"
: 
: Actually, that's attributed to someone from HDS, a company that
: recently started shipping "its own version of PPP" with its X
: terminals.  The article says they started shipping PPP "after rigorous
: performance testing of PPP and SLIP," but I haven't been able to
: reproduce their results.
: 
:    NOW is that really true. I mean I thought I was getting almost all
:    I could bet from my POTS line using SLIP. Can it really be true
:    that PPP is really that much superior to SLIP?
: 
: That's marketing hype.  Don't believe it.  They're constrained, like
: everyone else, by (1) the amount of user data that must traverse the
: link, and (2) current modem technology.  Since it's the same amount of
: user data, and since they're presumably using the same type modem,
: there's no difference between PPP and SLIP.

I suspect that they are mixing apples and oranges in the package. What HDS
was probably referring to was an X protocol speed improvement, which they
probably got by both using Van Jacobson's header compression to get 40
byte IP/TCP headers down to 5 or 6 bytes AND compressing the average 32 byte
short X protocol request/reply down to 5 or 6 bytes.

That IS 10-fold; 5 x for each "header". But nothing to do with PPP vs SLIP
without header compression.

Ted Rypma
HP Panacom Division
(A happy user of X over CSLIP at 38.4 Kbps)
Newsgroups: comp.protocols.ppp
From: karl@MorningStar.Com (Karl Fox)
Subject: Re: Why is PPP better than SLIP
Reply-To: Karl Fox <karl@MorningStar.Com>
Organization: Morning Star Technologies
Date: Tue, 1 Sep 1992 15:31:51 GMT

Ted Rypma writes:

   I suspect that they are mixing apples and oranges in the package. What HDS
   was probably referring to was an X protocol speed improvement, which they
   probably got by both using Van Jacobson's header compression to get 40
   byte IP/TCP headers down to 5 or 6 bytes AND compressing the average 32 byte
   short X protocol request/reply down to 5 or 6 bytes.

   That IS 10-fold; 5 x for each "header". But nothing to do with PPP vs SLIP
   without header compression.

I think you need to check your arithmetic.
--
Karl Fox, Morning Star Technologies                            +1 800 558 7827
1760 Zollinger Road, Columbus, Ohio 43221                      +1 614 451 1883
From: kees@ooc.uva.nl (Kees de Ridder)
Newsgroups: comp.protocols.ppp
Subject: ppp on RS6000
Date: 27 Aug 92 09:01:13 GMT
Organization: Center for Innovation and Cooperative Technology, University of Amsterdam


-------------------------------------------------------
In the process of evaluating possible connections between two IBM RS/6000
machines over telecommunications lines, I  would like to have some answers
on the following questions concerning the Point to Point protocol between
routers (PPP)
1- IBM does not support PPP on the RS/6000 AIX system today. Is there
anywhere a PPP version which runs without problems on an IBM RS/6000 over
the serial interface?
2- PPP is an alternative for a point-to-point SLIP connection between two
RS/6000 machines.
I would like to know what relative performance the two mentioned have on a
noncompresses (modems) 14k4 V32-bis analoge telecommunication line. Does
PPP have also a minimum packet length (overhead), and so on, and so on
Thanks in advance
 
-------------------------------------------------------
kees de Ridder
kees@ooc.uva.nl

Xref: sparky comp.protocols.ppp:744 comp.dcom.modems:12868
From: dplatt@ntg.com (Dave Platt)
Newsgroups: comp.protocols.ppp,comp.dcom.modems
Subject: Re: Help with World Blazer
Date: 2 Sep 92 17:24:50 GMT
Organization: New Technologies Group, Inc.  Palo Alto CA

>I have two WorldBlazer's wich I want to use to run PPP.
>I was successfull in setting the modems up in such a way that the one I use
>for dial in works fine when I call using a T2500.
>But if I use the other WB to dial out the chat program can not communicate
>well with the modem and the call aborts before the modem goes on hook.
>I tried to dial out with tip, the version that comes with slip, and the
>dialer get confused as well.
>Is anybody using this modem with better luck than me?

I have noticed that the WorldBlazer command-parser seems to have trouble
if you blast dialing commands at it at a high serial-port speed.  Last
night, I tried using Taylor uucp (1.03) to dial out using our
WorldBlazer with the serial-port speed set to 38400 (and the WorldBlazer
configuration set to use that speed, only).  The first few bytes of the
dial-and-configuration command went out OK, as each one is followed by a
pause to allow the modem to autobaud (not necessary in this case).
However, when the remainder of the command was blasted out at 38400 bps,
the WorldBlazer abruptly deasserted CTS and failed to respond.

You may need to hack your dialer so that the dialing command is
"paced"... that is, your dialer must send each individual character, and
then pause for 10 milliseconds or so before sending the next character.
This may enable the WorldBlazer to keep up with the command.

-- 
Dave Platt                                                VOICE: (415) 813-8917
              Domain: dplatt@ntg.com      UUCP: ...netcomsv!ntg!dplatt
 USNAIL: New Technologies Group Inc. 2468 Embarcardero Way, Palo Alto CA 94303
Newsgroups: comp.protocols.ppp
From: jnm@ornl.gov (Jamey Maze)
Subject: AppleTalk via PPP?
Followup-To: comp.protocols.ppp
Organization: Oak Ridge National Lab
Date: Mon, 31 Aug 1992 17:50:35 GMT

I'm reading an article from the 2/24/92 issue of Communications Week which
has John Veizades from Apple saying that the IETF AppleTalk/TCP/IP Working
Group is "firming up a specification for AppleTalk over the Point-to-Point
protocol". Does anyone have any information about this?

--
Jamey Maze, Oak Ridge National Lab     
Newsgroups: comp.protocols.ppp
From: bob@MorningStar.Com (Bob Sutterfield)
Subject: Re: IP address allocation
Organization: Morning Star Technologies
Date: Thu, 27 Aug 1992 18:10:01 GMT

In article <1992Aug27.072154.20745@nuscc.nus.sg> ccewch@nuscc.nus.sg (Wong Chee Heng) writes:
   I just want to know how IP address is allocated in PPP, does the
   end user has to set it of the host being dialed can actually
   allocate before hand?

PPP provides the mechanism, but the implementation and the user must
specify the policy.  

Here's the mechanism: Before exchanging IP packets across a PPP link,
the peers must agree on link parameters like packet size, control
character encoding, etc. during the LCP (Link Control Protocol)
negotiation phase.  Then they must agree on IP addresses and TCP
header compression parameters during the IPCP (IP Control Protocol)
negotiation phase.  Then they're finally ready to exchange user data
packets.  (By the way, all this negotiation happens very quickly,
typically requiring only two packet round-trip times, which amounts to
a few tenths of a second over dial-up modems.)

Here's the policy: whatever semantics you want to attach to the values
agreed upon during IPCP negotiation.  For example, a calling peer and
an answering peermight tell each other their addresses, but at least
the calling peer already knew the answering peer's address before
calling (how else would it know that it wanted to call?).  Or maybe
the calling peer waits for the answering peer to say what the
answering peer wants the calling peer's address to be, and then the
calling peer configures itself accordingly.  

If the PPP package is flexible enough, the user can implement just
about any policy {s}he can imagine.  Consider what you could do with
creative DNS hacquery and a shell (or Perl) script, wrapped around a
PPP invocation...

   Also what are the advantage of PPP over slip? 

Read the Deficiencies section of RFC 1055, and the Introductions of
RFCs 1331, 1332, and 1333.  You may also find some useful comparisons
in the paper I presented at last December's Sun User Group conference.
Get ftp.uu.net:vendor/MorningStar/papers/sug91-cheapIP.ps.Z.

   Is there a FAQ somewhere that I can find answers to my questions?

Ed Vielmetti was maintaining merit.edu:pub/ppp/emv-ppp-faq-0.1.txt for
a while, but it hasn't been updated recently.  Still, it's fresh
enough that you should be able to find something useful by using its
pointers.
Newsgroups: comp.protocols.ppp
From: laura@boulder.colorado.edu (Laura Compagnoni)
Subject: Help with World Blazer
Reply-To: laura@boulder.colorado.edu (Laura Compagnoni)
Organization: University of Colorado, Boulder
Date: Tue, 1 Sep 1992 17:21:22 GMT

I have two WorldBlazer's wich I want to use to run PPP.
I was successfull in setting the modems up in such a way that the one I use
for dial in works fine when I call using a T2500.
But if I use the other WB to dial out the chat program can not communicate
well with the modem and the call aborts before the modem goes on hook.
I tried to dial out with tip, the version that comes with slip, and the
dialer get confused as well.
Is anybody using this modem with better luck than me?
I should mention that the only way I can dial out using the WB is with kermit.

This is the configuration of the dialing out modem:

WorldBlazer - SA - Version LA5.00W- Active Configuration
 B1  E0  L2  M1  Q0  T   V1  X1  Y0 
&C1 &D3 &G0 &J0 &L0 &Q0 &R3 &S1 &T4 &X0 
S000=0   S001=0   S002:128 S003=13  S004=10  S005:254 S006=2   S007=40 
S008=2   S009=6   S010=14  S011=70  S012=50  S018=0   S025=5   S026=1  
S038=0   S041=0   S045=0   S046=0   S047=4   S048=0   S050=0   S051:254
S056=17  S057=19  S058:2   S059=0   S060=0   S061:0   S062=15  S063=0  
S064=0   S068=255 S069=0   S090=0   S092=0   S093=8   S094=1   S100=0  
S104=0   S105=1   S111:0   S112=1   S151=4   S155=0   S180=2   S181=1  
S183=25  S190:0   S191=7   S253=10  S254=255 S255=255 
OK


Thanks for any help

Laura Compagnoni
laura@alumni.colorado.edu
Newsgroups: comp.protocols.ppp