The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1991)
DOCUMENT: TCP-IP Distribution List for August 1991 (341 messages, 190041 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1991/08.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 91 00:16:07 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        alt.sys.sun,comp.protocols.tcp-ip
Subject:   Midget thin ethernet tranceiver rec wanted.

We are about to buy about 15 midget thin ethernet trasnsceivers for use
with various compact suns. The last time we did this we stumbled
accross a batch with a very high failure rate. Maybe 25% failed within
a few weeks, and another 25% within a year. The vendor (who I would
prefer not to mention) did make good on the failures, but I don't think
this should happen.

Can anyone recommend one in the <$100 range which has shown to be
reliable.

-- 
Ken Mandelberg      | km@mathcs.emory.edu          PREFERRED
Emory University    | {rutgers,gatech}!emory!km    UUCP 
Dept of Math and CS | km@emory.bitnet              NON-DOMAIN BITNET  
Atlanta, GA 30322   | Phone: Voice (404) 727-7963, FAX 727-5611

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 91 00:21:01 GMT
From:      brunner@telebit.com (Eric Brunner)
To:        comp.protocols.tcp-ip
Subject:   Re: behavior when receiving >1 ARP REPLY

In article <1991Jul26.225607.26001@Think.COM> barmar@think.com writes:
>In article <569@zeuswtc.sbi.com> matt@zeuswtc.sbi.com (Matthew Gutherz ISG) writes:
>>I seem to recall that a host is supposed to keep the last ARP REPLY it
>>receives when it receives more than one reply to a request.  I've looked
>>through a number of RFCs but can't find a reference to this.  Could
>>someone out there provide me with a reference either for or against.
>
>This follows from the original ARP specification in RFC826.  Whenever you
>receive an ARP packet you are supposed to update your ARP cache with the
>information it contains.  This can happen even if you haven't sent an ARP
>request (some systems broadcast an ARP reply when they boot, and if a
>system has an interface that supports changing the hardware address it's
>probably a good idea to broadcast an ARP reply when doing this).

So far so good, however, in multi-path 802.5 rings (with source route
bridges), rfc1042 does not require the implementor(s) any specific
behavior.

From rfc1042 (not yet obsoleted by son-of-1042):

      It is possible that when sending an ARP request via an all-routes
      broadcast that multiple copies of the request will arrive at the
      destination as a result of the request being forwarded by several



Postel & Reynolds                                              [Page 11]
^L
RFC 1042            IP and ARP on IEEE 802 Networks        February 1988


      bridges.  However, these "copies" will have taken different routes
      so the contents of the RIF will differ.  An implementation of ARP
      in this context must determine which of these "copies" to use and
      to ignore the others.  There are three obvious and legal
      strategies: (1) take the first and ignore the rest (that is, once
      you have an entry in the ARP cache don't change it), (2) take the
      last, (that is, always up date the ARP cache with the latest ARP
      message), or (3) take the one with the shortest path, (that is,
      replace the ARP cache information with the latest ARP message data
      if it is a shorter route).  Since there is no problem of
      incompatibility for interworking of different implementations if
      different strategies are chosen, the choice is up to each
      implementor.  The recipient of the ARP request must send an ARP
      reply as a point to point message using the RIF information.

Note that choice #2 is what is actually implemented, since most media
(read ethernet) rarely presents arp requests with small inter-arrival
times except in pathological circumstances. In multi-path SRB 802.5
rings, choice #2 results in pessimal routing, the final ARP Reply recieved
results in the installed route (in the 802.5 SRB sense of link-level routes),
which is probably the longest traversal path in both the query and reply
paths (which are probably distinct).

While pessimal routes are a problem, the undocumented semantics of the 3rd
bit in the RIF cause more problems in the unicast reply, but that is another
subject.


-- 
Eric Brunner
Tule Network Services - 4bsd/rt project

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 91 00:41:09 GMT
From:      mdyoung@AUSTIN.LOCKHEED.COM (Mark D. Young)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.windows.x,comp.windows.x.motif
Subject:   How do I get the file id. for TCP socket from RPC?

We are using the RPC package on the Suns to do network programming in
conjunction with X windows and Motif.  I've gotten stuck because 
XtAddInput needs a file id.  Does anyone know how to get the file id.
of a TCP socket from the RPC package?  Or is there a different way to
use the RPC package with X windows?

Thanks.

Mark Young
mdyoung@austin.lockheed.com

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 91 01:07:36 GMT
From:      rikitake@jrd.dec.com (Kenji Rikitake)
To:        comp.protocols.tcp-ip
Subject:   Internet Society: how to join?

I would like to join Internet Society, just established this June.
I would appreciate any help. Please email to me. (No followup please)

-- Kenji

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 91 01:30:29 GMT
From:      rwmira01@ULKYVX.BITNET (Rob Miracle)
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   Help with Sendmail and WIN/386 TCP-IP

I am having difficulty getting a AT&T 386 with AT&T System V R3.2.3 and
Wollengong WIN/386 TCP/IP 3.2 to receive mail.  I can send from the 386 (ncc02)
to other smtp systems, but when they try to send to ncc02, it fails.  I used to
get a message in the /usr/spool/mqueue/syslog about a Directory not found or
something.  I created the /usr/lib/aliases file, /usr/lib/sendmail.hf and .st
and that seemed to help.  I even created a /usr/spool/mail directory (the
default is /usr/mail) thinking that was the problem.  I would appreciate any
suggestions or help.  Below are the contents of the /usr/spool/mqueue/syslog
file and the mail that is returned to the sender.  It has to be something
simple.

Thanks in advance.
Rob

--
/usr/spool/mqueue/syslog:

Jul 31 20:50:08 [1360] 4 aliases, longest 20 bytes, 77 bytes total
Jul 31 20:50:09 [1360] AA01360: message-id=<9108010051.AA27464@vlsi.louisville.edu>
Jul 31 20:50:09 [1360] AA01360: from=<rwmira01@vlsi.louisville.edu>, size=392, class=0
Jul 31 20:50:11 [1362] AA01360: to=<rob@ncc02.ct.louisville.edu>, delay=00:00:03, stat=Service unavailable
Jul 31 20:50:11 [1362] giveresponse: statmsg: 554 Service unavailable.
Jul 31 20:50:11 [1362] AA01362: message-id=<9108010050.AA01362@ncc02.louisville.edu>
Jul 31 20:50:11 [1362] AA01362: from=MAILER-DAEMON, size=0, class=0
Jul 31 20:50:20 [1365] AA01362: to=<rwmira01@vlsi.louisville.edu>, delay=00:00:09, stat=Sent

After a bit, the following message is returned to to sender:

From MAILER-DAEMON@ncc02.louisville.edu Wed Jul 31 20:53:04 1991
Received: from [136.165.2.13] by ncc02.louisville.edu (5.59/25-eef)
	id AA01362; Wed, 31 Jul 91 20:50:08 EDT
Date: Wed, 31 Jul 91 20:50:08 EDT
From: Mail Delivery Subsystem <MAILER-DAEMON@ncc02.louisville.edu>
Message-Id: <9108010050.AA01362@ncc02.louisville.edu>
Subject: Returned mail: Service unavailable
To: <rwmira01@vlsi.louisville.edu>

   ----- Transcript of session follows -----
>>> HELO ncc02.louisville.edu
<<< 553 ncc02.louisville.edu I refuse to talk to myself
554 <rob@ncc02.ct.louisville.edu>... Service unavailable: No such file or directory

   ----- Unsent message follows -----
Received: from [136.165.2.13] by ncc02.louisville.edu (5.59/25-eef)
	id AA01360; Wed, 31 Jul 91 20:50:08 EDT
Received: from vlsi.louisville.edu by ulkyvx.bitnet with PMDF#10536; Wed, 31
 Jul 1991 20:51 EDT
Received: by vlsi.louisville.edu (5.57/Ultrix4.1) id AA27464; Wed, 31 Jul 91
 20:51:16 -0400
Date: Wed, 31 Jul 91 20:51:16 -0400
From: rwmira01@vlsi.louisville.edu (Robert W. Miracle)
To: rob@ncc02.ct.louisville.edu
Message-Id: <9108010051.AA27464@vlsi.louisville.edu>
Apparently-To: rob@ncc02

Testing

Rob Miracle              | Bitnet   : RWMIRA01@ULKYVX    CIS: 74216,3134
Programmer/Analyst-III   | INTERNET : rwmira01%ulkyvx.bitnet@cunyvm.cuny.edu
University of Louisville | UUCP     : ...ukma!ulkyvx.bitnet!rwmira01

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 91 03:23:00 GMT
From:      ingham@nodecg.ncc.telecomwa.oz.au (bruce ingham 4206700)
To:        comp.protocols.tcp-ip
Subject:   IP routing over ISDN.



	We are currently evaluating methods of routing IP via ISDN.
	Do any products exist that provide IP routing directly onto
	ISDN ?

	While there are ISDN adapters that provide semi permanent
	circuits that could be used by conventional routers, I would
	hope a much neater solution exists.


Bruce Ingham                            Phone: +61 9 4206700
Engineering Computer Centre             Fax:   +61 9 4207585
3rd Floor Telecom Centre                ACSNET: ingham@telecomwa.oz
80 Stirling Street, Perth               Inet:  ingham%telecomwa.oz@uunet.uu.net
Western Australia 6000

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 91 07:24:05 GMT
From:      mouse@thunder.mcrcim.mcgill.edu (der Mouse)
To:        comp.mail.misc,comp.protocols.tcp-ip,comp.unix.misc,comp.unix.wizards
Subject:   Re: TALK (Unix-to-Unix, Unix-to-VMS)

In article <1991Jul26.184754.3298@bernina.ethz.ch>, volkoff@isi.ethz.ch (Serge Volkoff) writes:

> When I type "talk user@host.domain.edu" it displays a split screen,
> then says "No connection yet", then "Checking for invitation on
> caller's machine", and stops there.  No requests appear on the other
> end.  I have tried this with a number of machines, running both Unix
> and VMS (I am using Unix here) and the result is always the same.

I was not aware that VMS was capable of speaking talk protocol....

Part of this confusion is probably arising because there are two talk
protocols, not one.  They are, of course, incompatible, and if you try
to talk from a machine that supports only one of them to a machine that
supports only the other, the above is exactly what you'll get.

The reason for having two protocols is not pure randomness.  The
original protocol was designed by someone who did not understand the
concept of machine independence as applied to network protocols; as I
recall it dumps C structs in raw binary to the network connection....
The new protocol is somewhat better, but still has problems.

Some machines support both talk protocols, typically by having the new
protocol in /usr/ucb/talk and the old one in /usr/old/talk.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 91 08:34:59 GMT
From:      B.Kumar@CS.UCL.AC.UK
To:        comp.protocols.tcp-ip
Subject:   Re: Communication Failure Rates

>I am looking for information on the packet loss rates for wide area
>networks, in particular, how these rates compare to local area
>networks.  Please mail any citations to (pds+@cs.cmu.edu).  If others
>are interested in the information, let me know and I will post a summary.

I am also interested in these figures. Please do post summary on net if 
possible.

Thanks,

--
B Kumar             

Department of Computer Science 
University College London 
London WC1E 6BT(U.K )                       

PH: +44-71-387 7050 EXT 3697   

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 91 12:04:47 GMT
From:      iservice@gourock.sw.stratus.com (Ian Service)
To:        comp.protocols.tcp-ip
Subject:   EARP is it a reality?

I have heard some mention of the Extended ARP protocol, EARP, and have read a draft of an RFC(?) however lately I have heard nothing about the topic. Is EARP a viable protocol, is anybody going to use it. Or are there any alternatives agreed/proposed/under discussion for one to many IP to Link Layer mapping.
-- 
========================================================
All opinions are my own and do not represent anyone else.
Ian Service				iservice@gourock.sw.stratus.com
Stratus Computer Inc.	        	TEL (508) 460-2352
M/S M3-2-COM,  55 Fairbanks Boulevard	FAX (508) 624-7488
Marlboro MA 01752-1298

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 91 12:30:04 GMT
From:      richi@hpopd.pwd.hp.com (Richard Jennings)
To:        comp.protocols.tcp-ip
Subject:   Re: IP routing over ISDN.

bruce ingham 4206700 writes...
> We are currently evaluating methods of routing IP via ISDN.

I believe Hewlett-Packard make such a product.  You could talk to your local
HP sales office.

Regards,

richi.
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -
  Richard Jennings,  Software Development Engineer
  Pinewood Information Systems Division,           the home of HP's Advanced
-----------------------------------------  Image Management System (HP AIMS),
                        AdvanceLink, OpenMail and Multi-media communications
  Hewlett-Packard                        --------------------------------------
  Nine Mile Ride      Voice: (+44)/(0) 344 763738      ADMD=GOLD 400    C=GB
  Wokingham           Fax:   (+44)/(0) 344 763526       OU1=Pinewood  ORG=hp
  Berkshire RG11 3LL  E-mail: richi@hpopd.pwd.hp.com     GN=Richard  PRMD=hp
  England             or:     richi@hpopd.pwd.hp.co.uk   SN=Jennings
--
         >> Of course, I don't speak for Hewlett-Packard <<

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 91 13:36:04 GMT
From:      NU021172@VM1.NODAK.EDU (Marty Hoag)
To:        comp.protocols.tcp-ip
Subject:   Connectivity among EMH ARMY.MIL Hosts and NSFNET


   Bob Stringfield was kind enough to share a couple letters (from
Jeff Funk and Leland Steinke) speculating on causes for poor connectivity
among army.mil hosts (especially the Sperry 5000-80s) and other Internet
hosts (especially those on NSFNET).

   I really think the problem is at a more fundamental layer than SMTP.
Frank Wancho has contributed some information (below) which indicates
that the IP packet TTL is set at 15 for these hosts.  The minimum
recommended value in RFC 1060 is 32 but most sites are now using
at least 60!  A value of 15 would allow the packet to travel only
15 "hops" before it is discarded.

   Evidence that this is a "low level" problem is that the same problem
is seen with PING ICMP packets as with the SMTP packets.  We have seen
hosts (eg. frankfurt-emh1.army.mil) where depending on the routing at
the moment the packets would arrive here with a residual TTL or 2 or
would hit our router with 0.  If they were 0 they would be discarded
of course.

   Below are a couple items on this.  I REALLY wish someone could
declare a communications emergency for the Sperry TCP/IP software
and get this fixed!  ;-)  It is bad enough that your users can't
communicate but it wastes a lot of time for those of us whose
services they are trying to use.

   Anything you can do to expedite a fix would be appreciated.
In particular, if you can trace your packets and find the TTL of
your outgoing and incoming IP packest (8 bytes offset from start
of the IP packet is the one byte TTL field) that would be a good
start.

   Let me know if there is anything I can do to help!  Thanks.

-----------
Marty Hoag
ND Higher Education Computer Network    US Mail: NDSU Computer Center
Phone: (701)-237-8639  Fax: (701)-237-7464       PO Box 5164 / UCCS
Bitnet:   nu021172@NDSUVM1    (NOTE 0 = ZERO)    Fargo, ND  58105
Internet: nu021172@VM1.NoDak.EDU
UUCP:    ...!uunet!plains!vm1.nodak.edu!nu021172




Date: Fri, 26 Jul 1991  11:29 MDT
Message-ID: <WANCHO.12704475680.BABYL@WSMR-SIMTEL20.ARMY.MIL>
Sender: <tcp-ip-relay@nisc.sri.com>
From: "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
To:   Marty Hoag <NU021172@VM1.NODAK.EDU>
Cc:   "Scott D. Martin" <ASQEXLA051A@FRANKFURT-EMH1.ARMY.MIL>,
      ...
Subject: Connectivity Problems
In-reply-to: Msg of 25 Jul 1991  07:50-MDT from Marty Hoag <NU021172 at
 VM1.NODAK.EDU>

Marty,

There are several problems with the Sperry 5000/80 hosts.  The most
severe is that the largest TTL value is 15.  In a previous message Bob
listed some hosts in the EDU and COM domains he couldn't reach.  Most
of them were well beyond 15 hops as measured from here.  However, the
number of hops is not a constant in the policy-based routing of the
NSFnet world, and may be as few as 10 under some circumstances, such
as whether the route goes through FIX EAST or FIX WEST.

The other problem, even when the hop count is under 15, is that the
round trip time may be long enough to cause a timeout.  Of course, when
the hop count is higher, the RTT is higher, too.  In one case, the hop
count went over 30 (to sh.cs.net) before my trace quit.

--Frank




Resent-Date:  Fri, 26 Jul 91 12:16:18 CDT
Resent-From:  Marty Hoag <NU021172@NDSUVM1>
Resent-Organization: North Dakota Higher Education Computer Network
Resent-Subject: mainz-emh2.army.mil connectivity problems
Resent-To:    funkb@zweibrucken-emh1.army.mil
Resent-Reply-To: Marty Hoag <nu021172@vm1.nodak.edu>

Received: from NDSUVM1 by NDSUVM1.BITNET (Mailer R2.07) with BSMTP id 9753;
 Fri, 26 Jul 91 11:32:49 CDT
Received: from NDSUVM1.BITNET by VM1.NoDak.EDU (IBM VM SMTP R1.2.1MX) with BSMTP
 id 6445; Fri, 26 Jul 91 11:32:43 CDT
Received: from NDSUVM1 (INFO) by NDSUVM1.BITNET (Mailer R2.07) with BSMTP id
 9751; Fri, 26 Jul 91 11:32:41 CDT
X-Resent-Date:  Fri, 26 Jul 91 11:32:25 CDT
X-Resent-From:  ND HECN E-mail Postmaster <INFO@VM1.NoDak.EDU>
X-Resent-Organization: North Dakota Higher Education Computer Network
X-Resent-To:    root%mainz-emh2.army.mil@moehringen-emh1.army.mil,
              Marty Hoag <nu021172@vm1.nodak.edu>
X-Resent-Reply-To: ND HECN Postmaster <info@VM1.NoDak.EDU>
Date:         Fri, 26 Jul 91 11:03:56 CDT
Sender: <tcp-ip-relay@nisc.sri.com>
From:         ND HECN E-mail Postmaster <INFO@VM1.NoDak.EDU>
Organization: North Dakota Higher Education Computer Network
Subject:      Re: [To: eurmmdf:  Connect Problems]
To:           Don Ross <mmdf@moehringen-emh1.army.mil>,
              Network Mailer <MAILER@NDSUVM1>,
              postmaster@APPLE.COM,
              postmaster@VM1.NODAK.EDU,
              postmaster@MERIT.EDU,
              postmaster@SH.CS.NET,
              root%MAINZ-EMH2.ARMY.MIL@zweibrucken-emh1.army.mil
cc:           trouble@merit.edu,
              danj@cac.washington.edu,
              ASQEXLA051A@FRANKFURT-EMH1.ARMY.MIL,
              "Billy O. Howard" <A455@HUACHUCA-EMH2.ARMY.MIL>
Reply-To:     Marty Hoag <nu021172@VM1.NoDak.EDU>
In-Reply-To:  Message of Thu, 25 Jul 91 09:04:39 CDT from
 <mmdf@moehringen-emh1.army.mil>

Hi!  Bob Stringfield sent me your note.  I wanted to be sure you got
my reply earlier which explains some of the background.  We are only a few
hops (ie. 3 ticks of the TTL) from the NSFNET backbone but many sites now
are 8-10 hops away (eg. nysernet sites).
   I agree that this "acts" like a routing issue since sites tend to
fade in or out (of course some may never be able to connect).  Again, I
can run LANWatch packet traces here and supply the printed packets if that
would help.
   If there is anything we can do from here please let us know.  Please note
that the frankfurt-emh1.army.mil site seems to be pretty well connectable
lately so I suspect someone did something... ;-)
      Marty
----------------------------Original message----------------------------
   The problem of connectivity between some MILnet sites (especially those
with XXXX-EMHn.ARMY.MIL names) was reported to NSFNET (our Internet backbone)
on 5/8/91.  They opened trouble ticket 13032 at that time.  The host
triggering the report was  frankfurt-emh1.army.mil (26.4.0.116).
   At the time of the reports frankfurt would "fade" in and out of connectivity
depending on the residual IP packet TTL.  When connected it was 2.  When we
could NOT connect it would reach 0 JUST before reaching our router.
At some point a change seemed to be made and the TTL reaching us now is 7
(as is zweibrucken's).
   In simplistic terms it looks like the initial TTL value is just now large
enough for the Internet as it exists today.  But I realize there could be
some other problem (a host using the incoming TTL for outgoing packets,
some gateway problem, etc).
   The most frustrating problem for me in tracking this problem was NOT having
a contact for the MILNET gateway or for MILnet connectivity.  I have included
the folks at Huachuca because I think they are involved with supporting some
of the mail software but this may be a problem at a deeper layer since it
involves IP TTLs (and they are the same for ICMP such as PING as for TCP SMTP
packets in general).
   If you can forward the info to the appropriate people I'd sure appreciate
it.  I have a LANWatch that I can check packet TTLs on quite easily.  I have
used that to find sites which are potential problems (TTLs of 3 or less).
   Let me know if I can help!  We would like to clear up this problem.  Thanks!
           Marty

----------
Marty Hoag                              ND HECN E-mail Postmaster
ND Higher Education Computer Network    US Mail: NDSU Computer Center
Work Phone: (701)-237-8639                       PO Box 5164 / UCCS
      Fax:  (701)-237-7464                       Fargo, ND  58105
Bitnet:    INFO@NDSUVM1    (Including EARN, NetNorth)
Internet:  INFO@VM1.NoDak.EDU
UUCP:      ...!uunet!plains.nodak.edu!vm1.nodak.edu!INFO
Personal address: nu021172@vm1.NoDak.EDU  (nu021172@ndsuvm1.bitnet)


On Thu, 25 Jul 91 09:04:39 CDT you said:
>Attempted as requested.....
>
>
>----- Forwarded message # 1:
>
>Received: from zweibrucken-emh1.army.mil by moehringen-emh1.army.mil id
>aa23936;
>          25 Jul 91 1:34 MDT
>Received: from zweibrucken-emh1 by mini01.zweibrucken-emh1.army.mil id aa17706;
>          25 Jul 91 1:09 MDT
>Received: from mainz-emh2.army.mil by mini01.zweibrucken-emh1.army.mil
>          id aa17593; 25 Jul 91 0:59 MDT
>Date:     Thu, 25 Jul 91 7:45:39 MST
>From:     System Administrator <root@MAINZ-EMH2.ARMY.MIL>
>To:       eurmmdf@zweibrucken-emh1.army.mil
>Subject:  Connect Problems
>
>We're having problems connecting to EDU & COM destinations.
>
>Results are:
>
>    ...can't
>    destination not available, queuing for retry
>
>Contacted MILNET Support.  They are able to connect.  Our forced delivery
>could not be detected by them.   I've rebuilt the tables, even went to
>a prior hosts.txt with no results.
>
>Any ideas.
>
>Would appreciate if some people would attempt delivery
>to some of the following and forward me the results:
>
>130.43.2.2
>134.129.111.1
>35.1.1.42
>128.89.0.92
>
>Thank you,
>Neal Warren
>
>
>----- End of forwarded messages

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 91 15:21:51 GMT
From:      swt@bwdls25.bnr.ca (Steven W. Truelove)
To:        comp.protocols.tcp-ip
Subject:   TFTP block counter


I cannot find any reference that state whether or not the block
counter in the tftp application is a signed or unsigned integer.

Could anyone tell me which it is?



SWT@BNR.CA			These are my own thoughts, even though 
Bell Northern Research 		they are simple ones.
Ottawa, Ontario, Canada	

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 91 15:36:46 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data

On 30 Jul 91 16:31:29 GMT, mike@gordian.com (Michael Thomas) said:

	[ ... the Urgent indicator is just a "water mark" that gives the
	offset of the first byte of urgent data ... ]

mike> I agree that, normally, not all of the data in between the current
mike> stream head and the urgent pointer are likely to be Urgent,
mike> however, I don't see where your're argument spares *any*
mike> application from the nessesity of having buffer the data in
mike> between RCV.NXT and RCV.NXT+Urgent *if* it doesn't desire to lose
mike> bytes.

Correct, but try to read URGENT (a misnomer!) as BREAK/RESYNC instead;
the URGENT indicator simply means, as it is defined, that there is a
pending interrupt, flush the queue, the first valid byte after the
interrupt has this offset.

The facility is designed for the case where the application _wants_ to
lose the data before the BREAK/RESYNC (the classic example is aborting
the current file transfer or remote command, where buffered typeahed has
to be flushed, nothing more).

mike> In the case of urgent data, the maximum amount "out of band" extra
mike> buffering you would need is (64k - open-queue-size) Per occurrence
mike> of urgent data, glech.  Sadly this just seems to be a deficiency
mike> in TCP -- trying to get out-of-band from a mechanism that just
mike> ain't up to the job...

Precisely, because it is not its job.  The URGENT pointer is not meant
to encode an OOB subchannel inside the main channel, it is meant to
provide sort of asynchronous record boundaries. In TCP/IP, OOB must be
_really_ OOB, another connection.

If one wants a control channel and a data channel one does not use
BREAK/RESYNC aka URGENT to multiplex the two channels onto one TCP/IP
connection, one uses *two* TCP/IP connections, maybe making use of the
quality of service options to five one higher "priority" than the other.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 91 16:04:54 GMT
From:      jrb@jove.cs.pdx.edu (James Binkley)
To:        comp.protocols.tcp-ip,comp.unix.internals
Subject:   question about BSD checksum routine error? message

In the BSD p.d. tcp/ip code, in the portable checksum routine, 

in_cksum()

there is a line of code near the end as follows:
	if (len)
		printf("cksum: out of data\n");
I seem to be getting this. This means logically that the mbuf
chain is shorter than the length passed in. Is this a bug?
What underlying circumstances might cause this to happen? 
It crops up during heavy tcp traffic, presumably on the input side.
It seems possible to me that the length is derived from header info
and the actual received data might be short due to traffic accidents;
i.e., this might be a natural occurance??? Or no? On the other hand,
maybe this indicates a driver bug of some sort. Why is there
a printf?
Any info appreciated. Thanks

					Jim Binkley
					jrb@cs.pdx.edu







From: jrb@intel.com (James Binkley)
Newsgroups: comp.protocols.tcp-ip,comp.unix.internals
Subject: question about BSD checksum routine error(?) message
Summary: 
Followup-To: 
Distribution: world
Organization: Embedded Processor Focus Group, Intel Corp.
Keywords: 

--------------------------------------------------------------
In the BSD p.d. tcp/ip code, in the portable checksum routine, 

in_cksum()

there is a line of code near the end as follows:
	if (len)
		printf("cksum: out of data\n");
I seem to be getting this. This means logically that the mbuf
chain is shorter than the length passed in. Is this a bug?
What underlying circumstances might cause this to happen? 
It crops up during heavy tcp traffic, presumably on the input side.
It seems possible to me that since the length is derived from header info, 
and the actual received data might be short due to traffic accidents;
this might be a natural occurance??? Or no? On the other hand,
maybe this indicates a driver bug of some sort. Why is there
a printf? To me, that implies that this is a bug.
Any info appreciated. Thanks

					Jim Binkley
					jrb@ichips.intel.com

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 91 16:36:27 GMT
From:      NU021172@VM1.NODAK.EDU (Marty Hoag)
To:        comp.protocols.tcp-ip
Subject:   Re:  Connectivity Problems


   Thanks for the note Bruce.

   Could you ping these hosts and let me know the results?  I think you
can reach us (the first one) and when we "PING" you the reply comes back
with a "good" TTL value of 7 left (which, in a normal case, would mean it
is 8 "hops" to here).  I'm only about 3 hops from the NSFNET backbone
while CUNYVM.CUNY.EDU (the Internet-Bitnet gateway) is a bit deeper as I
remember.  I'm curious if you can reach all the sites equally well just
with the gateway change.  In other words - is it the gateway itself or
just because of the number of hops needed to get to the unusual gateway
that caused the problem.  If it is the number of hops then there still
could be a problem.

      VM1.NODAK.EDU              134.129.111.1
      CUNYVM.CUNY.EDU            128.228.1.2
      ORST-NWNET-GW.UCS.ORST.EDU 128.193.16.2
      NIC.DDN.MIL                192.67.67.20

   I'd be especially interested in what traceroutes look like from the
various sites or at least whether or not they could each ping each
of these sites.

      Marty

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 91 18:37:42 GMT
From:      NU021172@VM1.NODAK.EDU (Marty Hoag)
To:        comp.protocols.tcp-ip
Subject:   Re:  Connectivity among EMH ARMY.MIL Hosts and NSFNET Reply To:, dmritter@cbg-99sima.army.mil

On Thu, 1 Aug 91 14:21:59 EDT you said:
>Marty,
>
>If I read you correctly, your saying that the Sperry TCP/IP
>software needs to be modified.  Is that correct?  Having just a
>binary release of this software, is there anything we can do to up
>our TTL?
>
>Thanks,
>dave
Dave:
   This discussion has been forwarded to so many folks I no longer remember
who has seen what... ;-)  But Frank Wancho said the Sperry software is using
a TTL value of 15 in the IP packets.  It is probably something that would
have to be changed and redistributed or for which maybe some sort of field
change could be issued (ie. a zap in IBM MVS terms. ;-).

   Apparently at least one site may have had the problem made worse by
using a rather obscure gateway.  But even if that were the particular
problem, I just think 15 is too low to reach many of the Internet hosts
these days.

   If a case could be made that the Sperry binary code is faulty is there
a maintenance contract on it?  Or is what you have what you get?  It would
be nice for the problem to be fixed at all the sites (but I imagine there
are other more urgent problems too...).

       Marty

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 91 20:12:09 GMT
From:      aras@falcon.no (Arne Asplem)
To:        comp.protocols.tcp-ip
Subject:   Routing question (between TCP/IP and dedicated SLIP links)

I've set up a network of 3 UNIX SVR3 systems connected over Ethernet,
running TCP/IP. My Sun 3/50 has a 38kbit/s SLIP link to a Stride 740
UNIX system runnning UniStride 2.x (SVR2 with BSD networking). How
do I set up routing on the SVR3 systems so they directly can telnet/ftp
over the SLIP link ? 

I've set up routed with an entry like this in /etc/gateways

host falc2 gateway walrus metric 2 passive

but it still doesn't work !

Any other files I have to modify ?

  -- Arne

-- 
Arne Asplem                       Address: Falcon  Information  Services A/S
                                           Stranden 1, N-0250 Oslo 2, Norway
Research and Development          Phone:   +47 2 831310    Fax: +47 2 831290
of UNIX based trading systems     E-mail:  aras@falcon.no  

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 91 21:50:48 GMT
From:      rikitake@jrd.dec.com (Kenji Rikitake)
To:        comp.protocols.tcp-ip
Subject:   Re: IP routing over ISDN.

In article <1991Aug1.032300.8756@nodecg.ncc.telecomwa.oz.au>, ingham@nodecg.ncc.telecomwa.oz.au (bruce ingham 4206700) writes:

]	Do any products exist that provide IP routing directly onto
]	ISDN ?

You can attach ISDN boards for Sony NEWS workstations. I've heard several
people doing IP networking on it. The board is intelligent so you need not to
have TA.

-- Kenji

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 91 23:10:40 GMT
From:      NAM@EVAX2.ENGR.ARIZONA.EDU
To:        comp.protocols.tcp-ip
Subject:   Need help on kerberos

Hi,

I need a help on kerberos setup on VAX.
I purchase a 4.3BSD-reno about 3 month ago and
still having trouble on passwd setup using kerberos.
If anyone has experience or referance material, please
give me some help.

Thanks in advance!!!

--- Nam

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 91 00:20:12 GMT
From:      RAF@CU.NIH.GOV ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP Urgent data

> I haven't used a TCP without urgent data, but my (pre-1123) TELNET
> implementations don't use it. When you hit INTR, they send IP, then (by
> default) flush all data until the server responds up to DM. There are no
> surprises, because as far as the user can tell, the server shuts up
> instantly. (I was happy to see that RFC 1123 recommended this practice.
> The user can turn off the flushing, of course, but what sane user would
> want to do so? In fact, what sane TELNET client implementation would do
> anything other than flush data as soon as it sent IP?)

That's usually a reasonable thing to do, but there can be applications
in which it is more important to know at what point the IP was received
and acted upon by the host than to have the output stop immediately.
This may not be true in Unix, but everything is not Unix.

Roger Fajman                                   Telephone:  +1 301 402 1246
National Institutes of Health                  BITNET:     RAF@NIHCU
Bethesda, Maryland, USA                        Internet:   RAF@CU.NIH.GOV

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 91 02:41:56 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.mail.misc,comp.protocols.tcp-ip,comp.unix.misc,comp.unix.wizards
Subject:   Re: TALK (Unix-to-Unix, Unix-to-VMS)

In article <1991Aug1.072405.13249@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
> Part of this confusion is probably arising because there are two talk
> protocols, not one.

It's more accurate to say that there are three in wide use: 4.3, 4.2
with big-endian, 4.2 with little-endian. None of the three is compatible
with any other. Of course, if someone has 4.2 talk running on a PDP,
that's a fourth protocol. The 4.2 protocol can also be affected by
compiler padding, but in practice all compilers do the same thing with
the relevant structures...

> The reason for having two protocols is not pure randomness.  The
> original protocol was designed by someone who did not understand the
> concept of machine independence as applied to network protocols;

I believe the original protocol was designed by someone who was working
solely on VAXen. That's close, but not quite, the same thing as someone
who doesn't understand machine independence. :-)

---Dan

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 91 05:08:39 GMT
From:      jel@xerver.data.nokia.fi (Jerry Lahti)
To:        comp.protocols.tcp-ip
Subject:   Re: TFTP block counter

swt@bwdls25.bnr.ca (Steven W. Truelove) writes:

>I cannot find any reference that state whether or not the block
>counter in the tftp application is a signed or unsigned integer.

TFTP spec (RFC 783) says in the description of the DATA packet (section 5)
that

"The block numbers on data packets begin with one and 
increase by one for each new block of data."

So presumably they are unsigned integers.  However, you probably should 
not be even trying to transfer several megabytes of data in 512 byte blocks 
using a stop and wait protocol, i.e. there should be no need to worry about 
integer overflow.

Regards,

Jerry Lahti
Nokia Data Systems Oy

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 91 05:15:37 GMT
From:      dave@ips.oz.au (Dave Horsfall)
To:        comp.protocols.tcp-ip
Subject:   GATED and SLIP

We have a small network of three SUNs on an Ethernet and two more
connected by SLIP links to one of the hosts.

I want to make the SLIP hosts visible to the rest of the network (and
vice-versa), and I know I have to use GATED, not ROUTED.  Try as I
might, I cannot get GATED to do the right thing.  The documentation
is somewhat less than lucid when talking about pointopoint links.
How should the /etc/gated.conf (and /etc/gateways etc) be set up?

On a related note, I want to make the SLIP hosts visible to an Annex-IIe
on the network as well.  Since GATED is not working, neither will the
Annex, so I can't localise the problem if the Annex is misconfigured.
I know the Annex will support SLIP, but for various reasons the SLIP
hosts have to hang off one of the other hosts.

If it matters, the SUNs are running 4.0.3 & 4.1, and the Annex 6.0.2.

-- 
Dave Horsfall (VK2KFU)         VK2KFU @ VK2RWI.NSW.AUS.OC
dave@ips.OZ.AU                  ...munnari!ips.OZ.AU!dave

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 91 06:24:12 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip,comp.unix.internals
Subject:   Re: question about BSD checksum routine error? message

In <3133@pdxgate.UUCP> jrb@jove.cs.pdx.edu (James Binkley) writes:

>In the BSD p.d. tcp/ip code, in the portable checksum routine, 
 
>in_cksum()
 
>there is a line of code near the end as follows:
>	if (len)
>		printf("cksum: out of data\n");
>I seem to be getting this. This means logically that the mbuf
>chain is shorter than the length passed in. Is this a bug?

My recollection is yes, this means a bug somewhere.  The input
code for both IP and ARP checks to make sure that the amount of data
passed to them is consistent with the protocol lengths (there are cases
where interface hardware can fail and provide partial packets -- that's
why the code checks the lengths).  So one shouldn't hit the IP checksum
routine without some assurance that there's enough data to feed the
checksummer.

Craig Partridge

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 91 12:55:38 GMT
From:      PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   Re: Ftp, Tcp/Ip

On Mon, 8 Jul 91 09:14:46 -0400 you said:
>Ours isn't available as shareware.  At the moment, our Windows support is
>only for 386 Extended mode: a VxD/DLL which allows use of our applications
>in multiple DOS boxes, and developement of WinApps.

And what about the same for DESQview (and DV/X)? (Like Novell told us :-)

Andr'e PIRARD         SEGI, Univ. de Li`ege        139.165 IP coordinator
B26 - Sart Tilman     B-4000 Li`ege 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 91 14:12:03 GMT
From:      SSJACK%ECUVM1@NCSUVM.CC.NCSU.EDU
To:        comp.protocols.tcp-ip
Subject:   VAX TCP/IP Recommendations


We are seeking software recommendations for a TCP/IP package to
run on a VAX 4000 running VMS 5.4. Please send your comments or
suggestions regarding your experience with CMU-TCP, Multinet, or
another solid package.

Thanks in advance for your help.

======================================================================
Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
======================================================================

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 91 15:37:02 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: TFTP block counter

In article <jel.681109719@xerver.data.nokia.fi> jel@xerver.data.nokia.fi (Jerry Lahti) writes:
>So presumably they are unsigned integers.  However, you probably should 
>not be even trying to transfer several megabytes of data in 512 byte blocks 
>using a stop and wait protocol...

Unfortunately, one of the main uses for TFTP is bootstrapping, and multi-
megabyte kernels are getting all too common...
-- 
Arthritic bureaucracies don't tame new  | Henry Spencer @ U of Toronto Zoology
frontiers. -Paul A. Gigot, WSJ, on NASA |  henry@zoo.toronto.edu  utzoo!henry

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 91 16:21:23 GMT
From:      ddl@husc6.harvard.edu (Dan Lanciani)
To:        comp.mail.misc,comp.protocols.tcp-ip,comp.unix.misc,comp.unix.wizards
Subject:   Re: TALK (Unix-to-Unix, Unix-to-VMS)

In article <8926.Aug202.41.5691@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
| In article <1991Aug1.072405.13249@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
| > Part of this confusion is probably arising because there are two talk
| > protocols, not one.
| 
| It's more accurate to say that there are three in wide use: 4.3, 4.2
| with big-endian, 4.2 with little-endian. None of the three is compatible
| with any other.

	This isn't quite true.  For some time, the 4.2 versions
for the Sun 2/3 and the Vax have had code that attempts to handle messages
from a foreign machine.  Generally, they look at the sin_family field of a
socket address and try to decide from that whether the structure
should be "fixed up."
	There are several problems with this.  One is simply that not
everyone got the code "right."  Sun's later versions have it "right" but
Ultrix seems to get confused.  Another problem is that the examined
sin_family field overlays the id number field thus it can happen
to have the "wrong" value and spoof the check.  This can cause great
confusion:  "The first time I talk it works but the second time it doesn't."

| Of course, if someone has 4.2 talk running on a PDP,
| that's a fourth protocol.

	I did but I made it look like a Vax...

| The 4.2 protocol can also be affected by
| compiler padding, but in practice all compilers do the same thing with
| the relevant structures...

	No, in fact, the Sun 2/3 and Vax compilers generate different
structure sizes for the 4.2 talk response message.  This happens because
the Vax's compiler aligns a long/int "id_num" on a 32-bit boundary while
the Sun's does not.  [Sun 4 is another story.]

				Dan Lanciani
				ddl@harvard.*

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 91 17:19:32 GMT
From:      dmicka@MAINZ-EMH2.ARMY.MIL (David A Micka)
To:        comp.protocols.tcp-ip
Subject:   Re:  DDN error message

Bob,

	Following are the host addresses for backed up mail and fragments
	from the ddn error logs.  The logs are kept in /usr/net and are
	- errlog.cur and errlog.pre.

	David


128.112.129.99 PUCC.PRINCETON.EDU 
134.129.111.1 VM1.NODAK.EDU 
129.29.199.2 WESTPOINT-EMH2.ARMY.MIL 
35.1.1.42 MERIT.EDU 
143.78.1.2 ODS-HOST11.ARMY.MIL 


++++++++++++++++++++++++++++ errlog.cur ++++++++++++++++++++++++++++++++++++++++
Fri Aug  2 09:42:47 1991: intermed: PK_REJECT chan 12
Fri Aug  2 09:42:50 1991: intermed: PK_REJECT chan 12
Fri Aug  2 09:42:52 1991: session: ERROR: Remote no response after rtxed 15 times in (CLOSING) on tyx:0
Fri Aug  2 09:42:52 1991: session: forced close tyx:0 and tcp chan 0.
Fri Aug  2 09:42:52 1991: session: ERROR 29 (CLOSED)
Fri Aug  2 09:43:08 1991: intermed: PK_REJECT chan 14
Fri Aug  2 09:43:13 1991: session:tcpeval Opening state receive event 29
Fri Aug  2 09:43:13 1991: intermed: PK_REJECT chan 14
Fri Aug  2 09:43:13 1991: intermed: PK_REJECT chan 14
Fri Aug  2 09:43:23 1991: session:tcpeval Opening state receive event 29
Fri Aug  2 09:43:46 1991: intermed: PK_REJECT chan 14
Fri Aug  2 09:43:53 1991: session: ERROR: Remote no response after rtxed 15 times in (CLOSING) on tyx:0
Fri Aug  2 09:43:53 1991: session: forced close tyx:0 and tcp chan 0.
Fri Aug  2 09:43:53 1991: session: ERROR 29 (CLOSED)
Fri Aug  2 09:44:24 1991: session:tcpeval Opening state receive event 29
Fri Aug  2 09:44:54 1991: session: ERROR: Remote no response after rtxed 15 times in (CLOSING) on tyx:0
Fri Aug  2 09:44:54 1991: session: forced close tyx:0 and tcp chan 0.
Fri Aug  2 09:44:54 1991: session: ERROR 29 (CLOSED)
Fri Aug  2 09:45:20 1991: intermediate: time out. index = 10, real ch# = 3. send msg
Fri Aug  2 09:45:25 1991: session:tcpeval Opening state receive event 29
Fri Aug  2 09:42:41 1991: intermed: PK_REJECT chan 12
Fri Aug  2 09:42:43 1991: intermed: PK_REJECT chan 12
Fri Aug  2 09:42:43 1991: session:tcpeval Opening state receive event 29
Fri Aug  2 09:42:44 1991: intermed: PK_REJECT chan 12
Fri Aug  2 09:42:45 1991: intermed: PK_REJECT chan 12
+++++++++++++++++++++  End of errlog.cur +++++++++++++++++++++++++++++++++++++++

++++++++++++++++++++++ errlog.pre ++++++++++++++++++++++++++++++++++++
Fri Aug  2 06:11:08 1991: intermed: PK_REJECT chan 5
Fri Aug  2 06:11:10 1991: intermed: PK_REJECT chan 5
Fri Aug  2 06:11:10 1991: intermed: PK_REJECT chan 5
Fri Aug  2 06:11:10 1991: intermed: PK_REJECT: channel not S_OPENING!
Fri Aug  2 06:11:12 1991: intermed: PK_REJECT chan 5
Fri Aug  2 06:11:12 1991: intermed: PK_REJECT chan 5
Fri Aug  2 06:11:12 1991: intermed: PK_REJECT: channel not S_OPENING!
Fri Aug  2 06:11:12 1991: session: ERROR: Remote no response after rtxed 15 times in (CLOSING) on tyx:0
Fri Aug  2 06:11:12 1991: session: forced close tyx:0 and tcp chan 0.
Fri Aug  2 06:11:12 1991: session: ERROR 29 (CLOSED)
Fri Aug  2 06:11:12 1991: session:tcpeval Opening state receive event 29
Fri Aug  2 06:11:13 1991: intermed: PK_REJECT chan 5
Fri Aug  2 06:11:14 1991: intermed: PK_REJECT chan 5
Fri Aug  2 06:11:14 1991: intermed: PK_REJECT chan 5
Fri Aug  2 06:11:15 1991: intermed: PK_REJECT chan 5
Fri Aug  2 06:11:16 1991: intermed: PK_REJECT chan 5
Fri Aug  2 06:11:16 1991: intermed: PK_REJECT chan 5
Fri Aug  2 06:11:17 1991: intermediate: time out. index = 2, real ch# = 1. send msg
Fri Aug  2 06:11:17 1991: intermed: PK_REJECT chan 5
Fri Aug  2 06:11:19 1991: intermed: PK_REJECT chan 5
Fri Aug  2 06:11:21 1991: intermed: PK_REJECT chan 5
Fri Aug  2 06:11:22 1991: intermed: PK_REJECT chan 5
Fri Aug  2 06:11:31 1991: intermed: PK_REJECT chan 7
Fri Aug  2 06:11:42 1991: session:tcpeval Opening state receive event 29
Fri Aug  2 06:11:42 1991: intermed: PK_REJECT chan 7
Fri Aug  2 06:11:43 1991: intermed: PK_REJECT chan 2
Fri Aug  2 06:11:43 1991: intermed: PK_REJECT: channel not S_OPENING!
Fri Aug  2 06:11:43 1991: session:tcpeval Opening state receive event 29
Fri Aug  2 04:57:17 1991: session: ERROR: Remote no response after rtxed 15 times in (CLOSING) on tyx:0
+++++++++++++++++++++++++++++ End of errlog.pre+++++++++++++++++++++++++++++++++

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 91 17:43:02 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP Urgent data

My personal taste in this matter is not to provide notification of
things I can't be sure of delivering to the application, which means
that I wouldn't notify of Urgent until data up to the pointer is in
hand.  I realize this offers less functionality than notification
when the URG bit is first received, but I think the world will be
better off overall if the application doesn't have to cope with an
EOF or reset connection error while it's in Urgent mode.  Perhaps
I'm not giving the application developers enough credit here, but
I've seen an awful lot of people assume malloc() can never fail...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 91 18:07:46 GMT
From:      mta@toro.MTS.ML.COM (Michael Askew)
To:        comp.protocols.tcp-ip
Subject:   Reliable Datagram Service




Can anybody tell me anything about the following:

	ISIS V3.x

	Camelot

	VMTP

Answers by e-mail please, thanks

.............Mike :)




Mike Askew                  |   Merrill Lynch & Co., Inc. 
(212) 236-3181              |   Municipal Analytics & Systems., 15th Floor.,
mta@toro.mts.ml.com         |   World Financial Center, South Tower,
uunet!toro!mta              |   New York., New York., 10080-6115., USA

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 91 21:43:15 GMT
From:      l1ngo@copper.denver.colorado.edu (l1ngo)
To:        comp.protocols.tcp-ip,rec.games.mud
Subject:   FIN_WAIT_1 and Copper Diku

I run a DikuMud and I'm having some problems. After I shutdown the mud,
most connections TIME_WAIT and die. Now and then, I get a FIN_WAIT_1
which will not die. The mud needs to bind tcp/ip port 4000 and cannot do
so with FIN_WAIT_1 hanging around. Anyone know how I can kill the connection?
Last time it happened, it prevented the mud from going up on port 4000 for
over 24 hours.

Copper Diku is running off port 4001 temporarily, by the way.

Thanks for any help,
Lin
-----------------------------------------------------------------------------
Copper.Denver.Colorado.Edu 4000 // Mud till you drop...
-----------------------------------------------------------------------------

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 91 23:50:56 GMT
From:      rleeson@relay.nswc.navy.mil (Robert Leeson)
To:        comp.protocols.tcp-ip
Subject:   Remote Sensing of Conditions at Network Distribution Sites


Before I go out and "re-invent a wheel" (which might be "fun" in this 
case), does anyone know of a device that would permit the temperature, 
humidity, and the like at remote distribution points (wiring closets, 
comm. shacks, etc) be monitored and then reported to a central location 
using the network cabling.  If there is an off-the-shelf device it would
probably be cheaper than a "roll your own" solution.

Our network is distributed through several buildings, some seperated 
by miles of fiber.  And many of the distrution points are seldom visited 
except when there is a failure.  (In many cases the failure of a cooling 
system is reported by the failure of the equipment it was intended to 
protect.)

Thanks for your help ---
			Rob Leeson

Internet: rleeson@relay.nswc.navy.mil   
Phone:	  703-663-7745
Autovon:  249-7745
FAX: 	  703-663-1952
Mail:	  Robert Leeson, Naval Surface Warfare Center, Code E41
	    Dahlgren, Virginia  22448-5000

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 91 12:08:13 GMT
From:      merdian@rus.uni-stuttgart.dbp.DE (Peter Merdian)
To:        comp.protocols.tcp-ip
Subject:   NFS and UID mapping

We have in Baden-Wuerrtemberg (a federal state of Germany) a science
network (called BelWue) that connects the universities and colleges.

The problem is, that the UIDs used in the different organisations are 
not coordinated and we will experience conflicts if we mount hosts 
via NFS over BelWue. One solution would be a UID mapping facility for 
NFS mounts. Another solution would be reassigning all the UIDs of the
BelWue organisations (which is hardly possible). Is there another
solution? Do I miss something obvious? 

I have heard that Cray will provide a UID mapping in the near future. 
Are there plans for UID mapping of other workstation companies?

Peter Merdian, BelWue-coordination, university of stuttgart
merdian@rus.uni-stuttgart.dbp.de, merdian@belwue.de

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 91 12:53:16 GMT
From:      sfrazier@mcinix.vlink.COM (Steven E. Frazier)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   ppp vs slip

What is the difference between PPP and SLIP.  I understand that PPP is
suppose to be much better, in what ways?  If you are calling a site using
SLIP, can you change to PPP without the other end changing?  I understand
Morningstar makes a PPP package which I received some information on, but
I still am not clear on the differences, advantages, and useage, could
someone help me out?

Thanks.

Steve


-- 
  Steven E. Frazier
 DID: (614) 761-6612
VNET:       424-6612
 FAX: (614) 761-6679

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 91 17:39:26 GMT
From:      jcurran@SH.CS.NET (John Curran)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP

> From: Stephen B Kutzer <COTRCSBK@sea04vm.navsea.navy.mil>
> 
> My reading of Comer's book and RFC826 make me believe that ARP will
> work independently of Internet addresses.  A friend of mine tells me
> I am wrong.  I am waiting for maintenance time to play with it and thought
> I'd ask this question in the meantime.
> 
> If I have the following network:
> ...
> It looks like you could, and ARP would bind the Ethernet address to the 
> Internet address.  My friend says no, that ARP will only occur for Internet 
> address within a given host's network.  Therefore to go from one to the other
> you need a gateway that has addresses in both networks.

ARP would handle this case, *but* ARP nevers sees this packet.  IP processing
first uses the destination address to determine the correct interface to use
for delivery.  Since the destination address is on a network not connected
to our host, there must exist a route in the routing table to that network
or the packet is dropped (network unreachable).  IP processing in most hosts
does not yet support the concept of multiple logical networks on a physical
network, but it is common in routers and many people are working on a standard
way of handling it.

>It seems wasteful to add the router hop and processing.  Is it an
>implementation issue or am I just missing something inherent to ARP?

IP knows better, and won't even try delivery.  ARP can't help when
it's not called.

A good explanation of the combined IP routing algorithm can also be 
found in Comer. 

/John

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 91 18:53:40 GMT
From:      jdavis@noao.edu (Jim Davis)
To:        comp.protocols.tcp-ip
Subject:   Re: OSPF Information

In article <9107121837.AA00840@bart.> eli@bart.UUCP (Eli Blumenthal) writes:
>
>uunet!mcsun!news.funet.fi!kannel!saruman.it.lut.fi!larry  (Lauri
>Toropainen) writes:
>
>> Another silly question: how to change directory during a ftp session at
>> NIC.DDN.MIL? The CD command only results to an error message. DDN NIC
>> seems to be a VMS host, so this may be the reason.
>
>Directories in VMS are specified as follows:
[... nice VMS ftp tutorial omitted ...]

Actually it's a DEC-20.  Here's a transcript of fetching the RFC index
from a UNIX box.  Note the "cd rfc:", with a colon; also note that the
scary-sounding "Default name accepted. Send password to connect to
it."  message can be ignored.

$ ftp nic.ddn.mil
Connected to nic.ddn.mil.
220 NIC.DDN.MIL FTP Server Process 5Z(47)-6 at Sat 3-Aug-91 11:40-PDT
Name (nic.ddn.mil:jdavis): anonymous
331 ANONYMOUS user ok, send real ident as password.
Password:
230 User ANONYMOUS logged in at Sat 3-Aug-91 11:40-PDT, job 21. 
ftp> cd rfc:
331 Default name accepted. Send password to connect to it.
ftp> dir rfc-index.txt
200 Port 18.24 at host 140.252.1.54 accepted.
150 List started.
RFC-INDEX.TXT.1243;P777752;AREF,61,10-Jul-91 10:01:56,10-Jul-91 10:01:57, 3-Aug-91 06:36:22
226 Transfer completed.
remote: rfc-index.txt
93 bytes received in 0.01 seconds (9.1 Kbytes/s)
ftp> get rfc-index.txt
200 Port 18.25 at host 140.252.1.54 accepted.
150 ASCII retrieve of TS:<RFC>RFC-INDEX.TXT.1243 (61 pages) started.
226 Transfer completed. 155304 (8) bytes transferred.
local: rfc-index.txt remote: rfc-index.txt
155304 bytes received in 8.9 seconds (17 Kbytes/s)
ftp> quit
221 QUIT command received. Goodbye.
$ ls rfc-index.txt
rfc-index.txt

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 91 19:59:28 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: ppp vs slip

In article <23@mcinix.vlink.COM> sfrazier@mcinix.vlink.COM (Steven E. Frazier) writes:
   What is the difference between PPP and SLIP.  

The first thing you'll notice is that their RFCs are numbered
differently - 1055 vs 1171 :-) Also, while SLIP describes itself as a
"non-standard", PPP is the product of the Internet Engineering Task
Force PPP Working Group and is on track to being a "blessed" Internet
Standard.

Read the RFCs for a description of their respective protocols.  SLIP
is a starkly minimalist approach, only suggesting what byte to prepend
and perhaps append to each frame sent across the wire.  PPP addresses
a lot of other issues too.

   I understand that PPP is suppose to be much better, in what ways?

Read the Deficiencies section of RFC-1055 and the Introduction of
RFC-1171 for a definitive discussion.  SLIP was a "first cut", from
which the IETF PPP Working Group learned plenty.  PPP is a more
general solution to the problem.

The most obvious differences that I can think of off the top of my
head:
	PPP incorporates FCS error checking.  SLIP expects higher
	levels of the protocol stack to worry about that sort of
	stuff.

	PPP allows different implementations to agree on a set of
	mutually-acceptable features (what protocol family to carry,
	various compression techniques, frame size (MTU/MRU),
	addresses of both ends, etc.) at connection time.  SLIP only
	carries IP, needs to know in advance whether to use TCP header
	compression and what frame size to use, and needs to know in
	advance what addresses are at each end of the link.

	PPP can negotiate a truly huge frame size, though a MTU of
	1500 seems to be a common compromise between batch throughput
	and interactive responsiveness.  SLIP can send any size that
	both implementations can support, and while the RFC suggests
	1006, many (most?) use 256.

	PPP can be used in either asynchronous or synchronous
	environments.  It has become the standard protocol for
	high-speed routers to talk over leased lines, at speeds up to
	T1.  This allows people to build networks using routers from
	different vendors, and expect them to all work together.

   If you are calling a site using SLIP, can you change to PPP without
   the other end changing?

No, the two use different framing techniques.  PPP is not upward
compatible from SLIP, though some hosts or routers may contain
implementations of both.

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 91 20:09:11 GMT
From:      DUCKY@ACADVM1.UOTTAWA.CA ("Richard V. Janke")
To:        comp.protocols.tcp-ip
Subject:   Internet Society

I would like to learn more about the Internet Society.

Please e-mail me re. this.

Thanks.

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 91 22:04:23 GMT
From:      CCMARK@UMCVMB.MISSOURI.EDU (Mark Moody)
To:        comp.protocols.tcp-ip
Subject:   3270 to vt100


Greetings,

I am looking for ways to allow our IBM mainframes on MOREnet to emulate
vt100 terminals from 3270 devices.  Most of our machines run VM/CMS but
there are MVS systems as well.  We are familiar with the products offered by
A-Net, however they are cost prohibitive at this time.  Does anyone else
know of any other solutions?  any help would be appreciated, and I will post
a summary if warranted.


Mark Moody
MOREnet - MissOuri Research and Educational network
University of Missouri - Columbia
CCMARK@umcvmb.missouri.edu  (preferred)
mark@noc.missouri.edu        (alternate)

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 91 10:46:53 GMT
From:      koerber.sin@sni.de (Mathias Koerber)
To:        comp.protocols.tcp-ip
Subject:   Network Traffic Analyzer?

I'm looking for a PD (or freeware) network traffic anayzer program,
which runs on either SysV or BSD, and recognizes TCP/IP as well
non-TCP/IP packets (OSI, whatever). It should deliver a breakdown of
traffic generated by host (user) and maybe time...

Is there any such thing ?

Oh yeah, something on PC would also work...

Thx, Mathias


Mathias Koerber  | S iemens             | EUnet: koerber.sin@sni.de
2 Kallang Sector | N ixdorf             | USA:   koerber.sin@sni-usa.com 
S'pore 1344      | I nformation Systems | Tel: +65/7402852 | Fax: +65/7402834
"Don't be humble, you're not that great" - Golda Meir | #include <disclaimer.h>

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 91 11:35:59 GMT
From:      mni@CRAYAMID.CRAY.COM (Michael Nittmann)
To:        comp.protocols.tcp-ip
Subject:   Re: Sub standard FTP implementation

on my opinion an implementation must always be complete. give back an error
if there is a request to write into a read only object (card reader 
would then be like a read only file).

michael

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 91 15:08:07 GMT
From:      solensky@ANIMAL.CLEARPOINT.COM (Frank T. Solensky)
To:        comp.protocols.tcp-ip
Subject:   Re:  ARP

Steve --

>If I have the following network:
>
>144.11.100.1                 140.195.203.1
>(mask FFFFFF00)              (mask FFFFFF00)
>      |                             |
>---------------------------------------------------
>             Common Ethernet
>---------------------------------------------------
>
>can I configure each host so that the other is a local delivery? 

I imagine that you might be able to, but it wouldn't be advisable.  The example
you include uses two IP addresses that are, by definition, on different nets
or subnets.  The normal case would be to assign IP addresses out of the same
network or subnet number on the common ethernet, then to use a router in the
same net to talk to "everything else".
--
					Frank Solensky / Clearpoint Research
Red Sox magic number -- 67

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 91 15:37:45 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data


    >The TCP  ...
    >  ... isn't supposed to pass data up until it has been ACKed,
    
    There is no such requirement.  Delayed ACKs exist in many implementations,
    for good reasons and with good results.

I should have said 'can be ACKed'.  I've voiced other opinions about TCP APIs
in a reply to Chrlie Lynn.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 91 16:16:45 GMT
From:      pozar@kumr.lns.com (Tim Pozar)
To:        comp.protocols.tcp-ip
Subject:   Re: IP routing over ISDN.

In article <1991Aug1.215048.12396@jrd.dec.com> rikitake@jrd.dec.com writes:
>]	Do any products exist that provide IP routing directly onto
>]	ISDN ?
>
>You can attach ISDN boards for Sony NEWS workstations. I've heard several
>people doing IP networking on it. The board is intelligent so you need not to
>have TA.

   Hayes makes a modem that will plug into ISDN.  I have been itching
to plug one in and run slip through it.  Unfortunatly, where I want
to pass IP from and to, do not have switches that support ISDN.  Pac
Bell sez "At least two years off". :-(

          Tim


-- 
       pozar@lns.com  Fido: 1:125/555  PaBell: 415-788-3904
    USNail:  KKSF-FM / 77 Maiden Lane /  San Francisco CA 94108

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 91 16:50:44 GMT
From:      NIC@NIC.DDN.MIL (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   Vendors Beware: Hop count and IP Internet "diameter"

The IP Internet has continued to grow at an amazing rate. This has
uncovered problems with vendor software that does not follow the
guidelines in RFC 1122 for the time to live (TTL) field. The
problem manifests as failure of email due to a TTL of only 15.

Now, TTL is defined as a unit of time in seconds, but handled
in gateways as a hop count. The assigned numbers RFC currently
recommends the value 32. It is also required to be configurable.

The IP Internet user community depends upon software vendors to 
provide enough flexibility to allow for continued growth of the
networks we are attached to, and to allow for this growth in
the software we as users are applying in our day to day jobs.

Thank you for taking a moment to review your current software
parameters, and insuring that they provide the maximum in
flexibility at the users site.

Steven
...for the DDN NIC
-------

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 91 17:22:46 GMT
From:      gmc@PREMISES1.QUOTRON.COM (Greg Christy)
To:        comp.protocols.tcp-ip
Subject:   Routing question (between TCP/IP and dedicated SLIP links)


In this situation I would recommend using static routes as there is
only one way to get to the Stride.  On each of your SVR3 machines add
host routes to the rc file which starts the net:

route add host stride_name 3/50_name 1

where stride_name and 3/50_name are the hostnames you have assigned to
these machines.  Likewise add routes to the SVR3 machines on the
Stride using the 3/50 as a gateway.  Make sure that you use the
address of the 3/50 side of the slip link.  You can use 'netstat -in'
and look at the net/dest column to find the address.

Greg

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 91 17:50:26 GMT
From:      rmurthi@cpqhou.uucp (@Strat Mkt)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   FTP sites for RFP's

in article <BOB.91Aug4155922@remora.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) says:
> 
> In article <23@mcinix.vlink.COM> sfrazier@mcinix.vlink.COM (Steven E. Frazier) writes:
>    What is the difference between PPP and SLIP.  
> 
> The first thing you'll notice is that their RFCs are numbered
> differently - 1055 vs 1171 :-) Also, while SLIP describes itself as a
> "non-standard", PPP is the product of the Internet Engineering Task

Is there any sites where these RFC's are stored?  Anonymous FTP sites of
course.  Thanks in advance for the Info.....

Raghu

rmurthi@cpqhou.se.compaq.com
--------------------------------------------------------------
Standard Disclaimer

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 91 18:52:25 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Sub standard FTP implementation

Alex--

It's actually been closer to 20 years than to 15, but still and all I'm quite
confident that my EarlyMiddleAged Memory is in better (well, make that less
bad) shape than yours on this one.  Even though I don't believe it ever saw the
dark of print in any of the RFCs, I'm certain that the "from a keypunch, to a
lineprinter" (or even "from a cardreader, to a cardpunch (and interpreter)")
metaphor was not from FTP, it was from Telnet, and was my own catchphrase for
how a Network Virtual Terminal COULD be instantiated, for all the protocol
"cared".

Of course, there's no particular reason in the abstract for you to believe that
my EMAM actually is functioning better than your EMAM even on this one, but in
practice I believe I can prove you're wrong, which at least lends a bit of
credence to the conviction I'm right.  For, you see, as far back as the August,
1973 version of the FTP spec, there HAS been a "minimum implementation" listed
(RFC 542, p.27, and still findable in the original issue (NCP-based) ARPANET
Protocol Handbook, which I never had the heart to throw out; unfortuantely, the
version of Telnet in it doesn't offer direct confirmation of my theory, at
least to my EMA eyesight).  Actually, that should be "at least as far back"
as RFC 542, since I didn't bother to try to find any of the earlier versions.

Now, maybe the minimum implementation got left out of one iteration or another
of the spec, since I find them a lot harder to lay my hands on than the '73
one, but I don't think it did, especially since at least one other respondent
kindly pointed out which page in the latest RFC the original poster on this
thread had overlooked.  So it does seem you're trying to account for a
non-phenomenon--unless, of course, I unsuccessfully tried to apply my pet NVT
principle to FTP at one of the meetings and that's what you're remembering....

antiquarian (but not, one hopes, antiquated) cheers,
		      map

P.S. Protocol archaeologists might be amused to learn that one interesting
widget that did inadvertantly get left out from one version of a spec to the
next was the "Logger" concept of Telnet.  Myself, I'm more amused that even
without the explanation of what was supposed to be on the other end of the
Telnet Well-Known Socket in the spec, almost everybody did something quite like
the right thing anyway: seems that all those intervening years of practice
reading unixtm manuals must have trained people to furnish and/or invent needed
context, after all (though maybe it was just that they were only iterating
preceding implementations, which were already in the right place).
-------

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 91 19:28:02 GMT
From:      postel@ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Sub standard FTP implementation


Hi.

The "minimum implementation" command set is listed on page 43 of RFC-959.

--jon.

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 91 19:52:54 GMT
From:      finnegan@viewlogic.com (David Finnegan)
To:        comp.protocols.tcp-ip
Subject:   Connected Udp socket question



    I am having some trouble with 'connected' Udp sockets using the
    local interface on a DEC Station 3100.

    If the server end of a connected Udp socket is unreachable
    (closed, for example) then a 'connection refused' error is
    generated on the next system call to the client socket after a
    write is performed.

    This behavior is what I expect.

    What I don't expect is that other processes, on the same machine,
    with local Udp connected sockets also get the connection refused
    error.

    An example:

        I've created three processes: snd, srv and rcv.

        snd reads stdin and writes a connected socket to a srv
        process.

        srv reads a connected socket, writes the data to its stdout
        and then writes the data to another connected socket.

        rcv reads a connected socket and writes the data to its
        stdout. 

        Each process checks for and displays any error detected when
        writing their respective sockets.

        If I chain a snd, multiple srv's and a receive together as
        follows: 

               __ snd_sock
               |   __ srv1_sock1
               |   |    __ srv1_sock2
               |   |    |   __ srv2_sock1
               |   |    |   |    __ srv2_sock2
               |   |    |   |    |   __ srv3_sock1
               |   |    |   |    |   |    __ srv3_sock2
               |   |    |   |    |   |    |   __ rcv_sock
               v   v    v   v    v   v    v   v
            snd --> srv1 --> srv2 --> srv3 --> rcv


        such that snd_sock is a Udp 'connected' socket to srv1_sock1,
        srv1_sock2 is a Udp 'connected' socket to srv2_sock1, ... and
        srv3_sock2 is a Udp 'connected' socket to rcv_sock then I
        observe the following behavior:


            A character (1) typed in to snd is displayed on the stdout
            of each srv? process and the rcv process.

            After terminating the rcv process, a character (2) typed
            in to snd is displayed on the stdout of each srv? process.

            A character (3) typed in to snd results in a connection
            refused error displayed on the stdout of the snd process
            and no other process receives the character.

            A character (4) typed in to snd is displayed on the stdout
            of srv1 and a connection refused error is also displayed
            on the stdout of srv1.  No other process receives the
            character. 

            A character (5) typed in to snd is displayed on the stdout
            of srv1 and srv2, a connection refused error is displayed
            on the stdout of srv2 and no other process receives the
            character.

            A character (6) typed in to snd is displayed on the stdout
            of srv1, srv2 and srv3 and an connection refused error is
            displayed on the stdout of srv3.  No other process
            receives the character (rcv has been killed!).

            Finally, a character (7) typed in to snd is displayed on
            the stdout of all srv? processes.  No other output is
            observed.

            If more characters are entered to snd the above process is
            repeated starting with character (4).

            To summarize:

            char   snd    srv1   srv2   srv3   rcv

             1      1      1      1      1      1
                kill the rcv process
             2      2      2      2      2
             3      3 CR
             4      4      4 CR
             5      5      5      5 CR
             6      6      6      6      6 CR
             7      7      7      7      7
             8      8 CR
             ...

            where CR denotes connection refused error


    It appears, at least to me, that once the rcv process has been
    killed an attempt to send a character to it generates a connection
    refused error for each (and every) process with a locally
    connected Udp socket.  Each process 'trips' the error by trying to
    send on their connected client socket.  Once the final process in
    the chain has 'tripped' their error the process starts over again
    by generating another error with an attempted send to the
    nonexistent rcv socket.

    What I would expect to see is a single connection refused error
    displayed by the last srv process in the chain on every other
    character generated by snd.  This, in fact, is what I see on a
    Sparc Station running the same code.

    Furthermore, the erroneous connection refused errors (at least in
    my opinion) only appear to present themselves to locally,
    connected sockets.  That is, if I run srv2, srv3 and rcv on a remote
    machine then the connection refused errors only propogate through
    srv2 and srv3.  Neither snd nor srv1 ever see a connection refused
    error. 

    Even more suprisingly, if I start a second chain of snd, srv and
    rcv processes as another user and then start up the orignal
    example, processes in the second chain all receive the connection
    refused errors along with the upstream processes on the test set.
    I.e. the same chain of connection refused errors is generated in
    the second chain after each attempt to write to the nonexistent
    process in the first chain!

    My question (albeit long winded) is this: is this really a bug in
    the DS3100 Tcp/Ip code or am I misinterpreting the results?

    If this is a bug, is there a patch or preferred workaround?

    Or, at least, has anyone else observed this behavior?

    [I've declined to post sources, but could provide some if
    necessary]

    Thanks in advance for any information.


        David


    Internet:   dfinnegan@viewlogic.com
    US Mail:    David M Finnegan
                Viewlogic Systems, Inc.
                293 Boston Post Rd West
                Marlboro, MA 01752-4615
                508 480 0881
-- 
David M Finnegan
Internet:   dfinnegan@viewlogic.com
US Mail:    Viewlogic Systems, Inc.
            293 Boston Post Rd West
            Marlboro, MA 01752-4615
            508 480 0881

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 91 21:12:22 GMT
From:      rah@sppy00.UUCP (MOORE ROBIN)
To:        comp.protocols.tcp-ip
Subject:   TN term type


  Could someone answer a question for me about RFC 1091 (the Telnet
Terminal-Type Option)?
  We have an IBM 3090 running version 1 of IBM's TCP/IP software for
that system.  It understands two terminal types: 3270 and Drop Dead
Stupid.
  When someone tries to come into our system from a Vax somewhere out
in the Internet, the Vax issues the command "WILL OPTION TERMINAL TYPE".
The IBM responds with "DO OPTION TERMINAL TYPE".  Then it gets hairy.
The IBM transmits the "SEND" subnegotiation, and the Vax responds
that it "IS VT102".  The IBM, naturally, was hoping for a 3270 and
transmits "SEND" again.  The Vax is apparently set up to only support
one terminal type, so it responds "IS VT102" again.  This concludes
the terminal type negotiation;  things seem to work pretty well from
then on simply because the application on the IBM does not use
any glitzy terminal features at all.
  From my reading of the RFC, the Vax has acted correctly by cycling
through its "list" of options until the server system selects the one
it likes best.  The Vax believes it has been granted VT102 type access.
  Also, it seems the IBM has no way to go back and say "I don't like
your list -- you should realize you're not getting a VT102."  It just
has to do its best with the least unpleasant option presented to it.
  Have I missed something here, or is this really as good as it gets?
  Thanks in advance for any help you can provide.
  Robin H-M
-- 
{ Robin A. Hermance-Moore                     %              OCLC Inc.        }
{ sppy00!rah@cis.ohio-state.edu <== 1st   %%% %%% %% %%%%%   6565 Frantz Road }
{   OR:  rah@rsch.oclc.org      <== 2nd   %   % %    % % %   Dublin, OH 43017 }
{ OCLC => "Services for Libraries"        %   % %    % % %   (614) 764-6215   }

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 91 21:48:36 GMT
From:      mmm@well.UUCP (Michael Hidalgo)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe

please remove my name from the mailing list.
thank you,
Michael Hidalgo

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 91 21:50:43 GMT
From:      mmm@well.UUCP (Michael Hidalgo)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe

Please unsubscribe me from the mailing list.
Thank you.
Michael Hidalgo

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 91 23:47:05 GMT
From:      rwmira01@ulkyvx.bitnet (Rob Miracle)
To:        comp.mail.misc,comp.mail.sendmail,comp.protocols.tcp-ip
Subject:   Followup:  WIN/386 Sendmail problems

I would like to thank those that responded to my query and those who followed
up to the news groups.  

The consensus was that I did not have sendmail configured to know who it was. 
This was in part true.  I had it configured properly, however, I failed to
restart sendmail so that it would reparse the .cf file (slap slap punch
uppercut).

It's always something.

-- 
Rob Miracle              | Bitnet   : RWMIRA01@ULKYVX    CIS: 74216,3134
Programmer/Analyst-III   | INTERNET : rwmira01%ulkyvx.bitnet@cunyvm.cuny.edu
University of Louisville | UUCP     : ...ukma!ulkyvx.bitnet!rwmira01
"Revenge is a dish best served cold.  It is very cold in space" 
       -- Ancient Klingon Proverb

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 91 07:00:55 GMT
From:      mni@CRAYAMID.CRAY.COM (Michael Nittmann)
To:        comp.protocols.tcp-ip
Subject:   Re: TFTP block counter

just a comment: the problem is probably not Mbytes, but the question of 32kB
or (unsigned, one more bit) 64kB blocks buffered on a 16 bit machine. 
There is a problem then. I would be careful and be prepared to handle 64kB 
incoming buffered but send only out max 32kB.



michael

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 91 13:08:21 GMT
From:      tvf@cci632.cci.com (Tom Frauenhofer)
To:        comp.protocols.tcp-ip
Subject:   UUCP versus FTP

I'm interested in any performance comparisons that have been done between
UUCP and FTP file transfer rates over various network configurations
(especially over Ethernet-based systems).  If anyone can send me papers or
point me to the literature I would be most appreciative.

Thanks in advance.
-- 
Thomas V. Frauenhofer, WA2YYW, tvf@cci.com   | "The most depressing part
{uupsi,ccicpg}!cci632!tvf@uunet.uu.net       |  of USENET is that it's
tvf@frau.UUCP                                |  mostly inhabited by people
tvf1477@ma.cs.rit.edu                        |  who think negative." - me

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 91 13:19:37 GMT
From:      utterbac@husc9.harvard.edu (Margot Utterback)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Protocol analyzers

We are evaluating protocol analyzers.  So far we will be looking at 
the Network General Sniffer and the Digilog LanVista 100.  What we are 
looking for is a portable unit that can diagnose as wide a range of
problems as possible.  Price is a consideration but not a show stopper.
Has anyone had any experience with either of these units and can advise
us about them? And are we missing any other candidates?

Thanks in advance.

utterbac@husc.harvard.edu

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 91 13:32:59 GMT
From:      steinkel@CARLISLE-EMH2.ARMY.MIL ("L. Steinke")
To:        comp.protocols.tcp-ip
Subject:   [System Administrator:  TTL]

>the ddnstart.sh script.   Successfully delivered to most of the EDU.
>Now revised the TTL to 100 to see if we reach the IT net.

I am not trying to be a spoilsport here, but what are we losing by upping the
TTLs to ever-higher values?  I am not pretending to know (in other words, I'm
guessing), but isn't there a higher probability of increased network (DDN and
Internet) congestion with all these longer-lived packets running around?

Leland

ps:  Given that the highest TTL for an IP packet is 255 (or 0, depending on 
when TTL is decremented, relative to testing for death), and that it would
appear that for the 3B2 600G, ICMP Echo Replies start out with TTLs of 255,
we might already be on the verge of a problem

pps:  what is the IT net?

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 91 15:15:57 GMT
From:      brendan@cs.widener.edu (Brendan Kehoe)
To:        comp.protocols.tcp-ip
Subject:   Divine Whois

---
% whois god

Davisson, Gordon O. (GOD)	gordon@JUNE.CS.WASHINGTON.EDU	(206) 527-0832
Tria, Brian (BT53)		god@SBCS.SUNYSB.EDU		(516) 632-8751

To single out one record, look it up with "!xxx", where xxx is the
handle, shown in parenthesis following the name, which comes first.
---

Gordon's secret is out.  Now you know.
-- 
     Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu
  Widener University in Chester, PA                A Bloody Sun-Dec War Zone
  "And clever rogues with far less valid cause, have trapped their victims
                       in a web of laws." --- Moliere

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 91 15:54:46 GMT
From:      CMSEDORE@mh.syr.edu ("Christopher M Sedore")
To:        comp.protocols.tcp-ip
Subject:   RE: NET14 redirector


OK, here is the info on the net14 redirector:

    host: 129.97.128.96
    directory: /pub/wattcp
    filename: apps.zip

The source code is also available somewhere near the apps.zip file for those
who are interested.

Good luck!

--Chris

Christopher M Sedore
Systems Programmer
Syracuse University

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 91 16:40:39 GMT
From:      cwk@boomer.ssc.gov (Carl W. Kalbfleisch)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Protocol analyzers

>>>>> On 6 Aug 91 13:19:37 GMT, utterbac@husc9.harvard.edu (Margot Utterback) said:
In article <1991Aug6.091939.2340@husc3.harvard.edu> utterbac@husc9.harvard.edu (Margot Utterback) writes:

Margot> We are evaluating protocol analyzers.  So far we will be looking at 
Margot> the Network General Sniffer and the Digilog LanVista 100.  What we are 
Margot> looking for is a portable unit that can diagnose as wide a range of
Margot> problems as possible.  Price is a consideration but not a show stopper.
Margot> Has anyone had any experience with either of these units and can advise
Margot> us about them? And are we missing any other candidates?

Margot> Thanks in advance.

I contacted a number of vendors on this area recently.  Since you don't
say what type of LAN you are looking at, it is difficult to know which of these
companies have what you want.  I have listed below the companies that I
contacted, as well as the products they have of interest.  I understand
that Novell also has a protocol analysis product, but I don't have a 
contact there.  


In no particular order (and not a complete list I'm sure of protocol analysis
units).

Tekelec 818-880-5656
ChameLAN 100

Cabletron Systems 603-332-9400
LANVIEW Network Analyzer

Network General 415-688-2700
Sniffer
Distributed Sniffer

Hewlett Packard (contact a local rep)
4972A
Network Advisor
LAN Probe

Tektronix/LP COM 800-826-8675
TC1000
TC2000

Carl
--

+--------------------------------------------------------------------------+
|  Carl W. Kalbfleisch                              cwk@psychosis.ssc.gov  |
|  Superconducting Super Collider Laboratory                               |
|  2550 Beckleymeade Avenue, MS-4002                                       |
|  Dallas, Texas 75237                                     (214) 708-3428  |
+--------------------------------------------------------------------------+

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 91 16:49:08 GMT
From:      jik@cats.ucsc.edu (Jonathan I. Kamens)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: FTP sites for RFC's

In article <1991Aug05.175026.24412@cpqhou.uucp>, rmurthi@cpqhou.uucp (@Strat Mkt) writes:
|> Is there any sites where these RFC's are stored?  Anonymous FTP sites of
|> course.  Thanks in advance for the Info.....

They're on uunet.uu.net.  Also, quoting from RFC-INDEX.TXT:

Many RFCs are available online; if not, this is indicated by (Not online). 
Paper copies of all RFCs are available from the NIC, either individually
or on a subscription basis (for more information contact NIC@NIC.DDN.MIL).
Online copies are available via FTP or Kermit from NIC.DDN.MIL as 
RFC:RFC####.TXT or RFC:RFC####.PS (#### is the RFC number without leading 
zeroes).

Additionally, RFCs may be requested through electronic mail from the
automated NIC mail server by sending a message to SERVICE@NIC.DDN.MIL
with a subject line of "RFC ####" for text versions or a subject line
of "RFC ####.PS" for PostScript versions.  To obtain the RFC index,
the subject line of your message should read "RFC index".

-- 
Jonathan Kamens					jik@CATS.UCSC.EDU

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 91 18:49:42 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: TN term type

In article <1317@sppy00.UUCP> rah@sppy00.UUCP (MOORE ROBIN) writes:
>  Could someone answer a question for me about RFC 1091 (the Telnet
>Terminal-Type Option)?
 ...
>  From my reading of the RFC, the Vax has acted correctly by cycling
>through its "list" of options until the server system selects the one
>it likes best.  The Vax believes it has been granted VT102 type access.
>  Also, it seems the IBM has no way to go back and say "I don't like
>your list -- you should realize you're not getting a VT102."  It just
>has to do its best with the least unpleasant option presented to it.
>  Have I missed something here, or is this really as good as it gets?

What does it mean for the TELNET *client* to "get" a particular terminal
type?  The client is simply informing the server of what type of terminal
is attached or is being emulated.  This information is purely for use by
the server.

If the server doesn't know how to do anything useful with the particular
terminal type, the situation is the same as if the terminal type
information had never been transmitted.  You'd still be using a VT102, and
the IBM system wouldn't send any terminal-dependent control operations or
recognize function keys.
-- 
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 91 19:19:39 GMT
From:      peter@ficc.ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: Sub standard FTP implementation

In article <9107312114.AA25385@ftp.com> jbvb@ftp.com writes:
> RFC 1123 remedies that lack - see the section on FTP.  I myself haven't
> seen software that didn't implement LIST or NLST since 1987, and it was
> out of date at that time.

DDN1100 on the Unisys 1100 mainframes.
-- 
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 91 19:56:34 GMT
From:      fyang@nysnet.nys.GOV (Frank Yang)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.sys.ibm.pc.misc,comp.binaries.ibm.pc.wanted
Subject:   X-windows/terminal software for PC <-- info needed

We need infomation on PC X-windows/teminal software. Currently we use
PC Xsight, but we are looking for some other product.

Any suggestion/information will be very appreciated !

Thank,
Frank

fyang@nysnet.ny.gov
uunet!nysnet!fyang

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 91 19:59:46 GMT
From:      RXR300G@ODUVM.BITNET
To:        comp.protocols.tcp-ip
Subject:   explanation of ip-source code 4.3BSD

Can someone who knows e-mail me some explanation/documentation for the 4.3BSD
source code of the internet protocol?
thanks in advance,
-Ramesh

p.s: my email address is radha_s@cs.odu.edu

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 91 21:02:32 GMT
From:      bvk@scharat.uucp (Dr. B.van Kruechten)
To:        comp.protocols.tcp-ip
Subject:   Re: Network printers

bmiller@CABELL.VCU.EDU (Bryan Miller) writes:


>Can anyone give me any hints/suggestions on network printers.  By that
>I mean a printer that can attach directly to Ethernet, be assigned
>an IP address, and then be able to receive printed output.  We are
>looking towards this as an alternative to purchasing terminal servers
>each time we need to connect a remote printer.
 
>Thanks,
 
>Bryan Miller

 We have used a box from SPIDER:

   It's connected to ETHENET
   and has some twelve V24 lines on the other side.


   bvk

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 91 21:04:57 GMT
From:      ado@BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: ARP

You wrote:

   My reading of Comer's book and RFC826 make me believe that ARP will
   work independently of Internet addresses.  A friend of mine tells me
   I am wrong.   ....

I didn't see a reply go by, so I'll give it a try.

You are right about ARP.  It is specified as being independent of the
upper layer protocol, so if the ARP request ever got sent, and a reply
came back, it should provide the desired answer.  But your friend is
right too.

An ARP request won't get sent until the upper layer tries to send on
the locally attached network.  For the upper layer to so decide, it
probably thinks it needs to have an address on that net.  If your
software is able to configure multiple address/mask pairs for a single
interface, it probably doesn't have a way to configure a
netaddress/mask pair, but no hostaddress.  (I don't see that this
would do any harm, but I expect good arguments can be constructed
saying it is wrong for a host to be on a net without a host address on
that net assigned to it.)  So, to configure your host to be on a net,
you would have to allocate a fake address on that net, and then even
if you had the address to spare, the software might decide to send
from that address instead of from the address you want it to use.

Also, if you sent an ARP request, a reply might not come back -- I
would guess that ARP software is often constructed to know (or only
know) about TCP instead of being truly independent, so it might
(although this is improbable,) do some checking and decide the
sender's protocol address is offnet, and decline to reply -- unless
you had configured the target host on both nets also.

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 91 23:29:17 GMT
From:      jtw@lcs.mit.edu (John Wroclawski)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data

In article <9108021743.AA13459@ftp.com> jbvb@FTP.COM (James B. Van Bokkelen) writes:

   My personal taste in this matter is not to provide notification of
   things I can't be sure of delivering to the application, which means
   that I wouldn't notify of Urgent until data up to the pointer is in
   hand.  I realize this offers less functionality than notification
   when the URG bit is first received, but I think the world will be
   better off overall if the application doesn't have to cope with an
   EOF or reset connection error while it's in Urgent mode...

But the whole point of urgent is to get the sleeping critter at the
other end to wake up and do something different. Consider, for
example, a remote invocation server, which is in the middle of
crunching away at some 2-hour computation, and as a result isn't
reading the data stream. If the client has sent any significant
additional data, the TCP window will likely be closed. In this case,
an Urgent indication delivered when the URG bit shows up can still be
used to ^C the remote invocation server, but your way will leave the
client helpless.

There are a number of protocols other than TELNET which can benefit
from TCP Urgent working right. Your approach makes it useless for many
of them...
				-john

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 91 00:25:15 GMT
From:      coates@UC780.UMD.EDU
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Protocol analyzers

In article <1991Aug6.091939.2340@husc3.harvard.edu>, utterbac@husc9.harvard.edu (Margot Utterback) writes:
>We are evaluating protocol analyzers.  So far we will be looking at 
>the Network General Sniffer and the Digilog LanVista 100.  What we are 
>looking for is a portable unit that can diagnose as wide a range of
>problems as possible.  Price is a consideration but not a show stopper.
>Has anyone had any experience with either of these units and can advise
>us about them? And are we missing any other candidates?
>
>Thanks in advance.
>
>utterbac@husc.harvard.edu

Go with the Sniffer, for a single unit it covers the most LAN nad WAN
protocols.

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 91 00:58:09 GMT
From:      dag@unisoft.UUCP (Darren Alex Griffiths)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote Sensing of Conditions at Network Distribution Sites

In article <1991Aug2.235056.10184@relay.nswc.navy.mil> rleeson@relay.nswc.navy.mil (Robert Leeson) writes:
>
>Before I go out and "re-invent a wheel" (which might be "fun" in this 
>case), does anyone know of a device that would permit the temperature, 
>humidity, and the like at remote distribution points (wiring closets, 
>comm. shacks, etc) be monitored and then reported to a central location 
>using the network cabling.  If there is an off-the-shelf device it would
>probably be cheaper than a "roll your own" solution.
>

There are a number of products to monitor environments in catalogs like 
Computer Products and Inmac.  All of the ones I've seen have consisted of
a phone line and water and temperature sensors.  They are designed to call
you at a list of 5-10 numbers when there is a problem, you can also call
them and have them tell you information over the phone.  It's not 
exactly what you asked for, but if you can get fiber to the site you could
probably get a phone line there as well.


   Cheers,
    --darren

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 91 05:45:00 GMT
From:      tb@Materna.DE (Torsten Beyer)
To:        comp.protocols.tcp-ip
Subject:   RPC/XDR weirdness

Hi Netland,

I'm working on a piece of RPC-software part of which transfers lists between
two machines. While debugging the stuff I realized that my program would
slowly grow ( in terms of memory usage ;-). I first thought that I forgot to
put some xdr_free's in the right place but couldn't find a fault on my side.

Finally I decided to look into the xdr routines generated by rpcgen. I think
I have found a bug but correct me if I'm blind. Consider the dir.x demo
software that comes with rpc. Here's what rpcgen generates of dir.x:

bool_t
xdr_nametype(xdrs, objp)
	XDR *xdrs;
	nametype *objp;
{
	if (!xdr_string(xdrs, objp, MAXNAMELEN)) {
		return (FALSE);
	}
 return (TRUE);
}

bool_t
xdr_namelist(xdrs, objp)
	XDR *xdrs;
	namelist *objp;
{
	if (!xdr_pointer(xdrs, (char **)objp, sizeof(struct namenode), xdr_namenode)) {
		return (FALSE);
	}
 return (TRUE);
}

bool_t
xdr_namenode(xdrs, objp)
	XDR *xdrs;
	namenode *objp;
{
	if (!xdr_nametype(xdrs, &objp->name)) {
		return (FALSE);
	}
	if (!xdr_namelist(xdrs, &objp->next)) {
		return (FALSE);
	}
 return (TRUE);
}

Consider a list of n entries. When calling xdr_free for namenode, it would
free it's nametype entry and - by calling xdr_namelist the next one. But not
further.  I'm I right to suspect that in the above case only the second list
element would get free'd by xdr ? Or is there a trick somewhere in
xdr_pointer that enables it to free subsequent list elements ???

Is there any whay to convince rpcgen that a certain struct is part of a list
and that it should generate recursive xdr routines ?? Or do I have to code
all this by hand ???

Any clues greatly appreciated

			thanx in advance

				-Torsten
--
Torsten Beyer                      	e-mail : tb@Materna.DE
Dr. Materna GmbH		   	VOX    : +49 231 5599 225
Vosskuhle 37, D-4600 Dortmund	   	FAX    : +49 231 5599 100
       "Strahlentod und Mutation durch die schnelle Kernfusion..", Kraftwerk

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 91 06:22:20 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   ntalk forwarding daemon


I'm looking for a forwarding talk daemon.  By this I mean that I want
a talk daemon (speaking ntalk) to accept talk requests by proxie for
me and forward them to where ever I am at the time (or where ever I
have registered being).  It would then let me connect to it so I could
talk with the remote person.

Has anybody done anything like this, or am I going to have to spend a
few hours hacking talkd from the tahoe tape?

Warner

P.S.  If you have any good ideas on how to accomplish this, please let
me know.  I think that it can be done w/o extending the protocol (but
extending the protocol would make it more generally useful).
-- 
Warner Losh		imp@Solbourne.COM  uunet bang stan bang imp
"Red hair is caused by sugar and lust," the woman, who was blond, confided.
"Highly evolved beings do not indulge in sugar and lust."

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 91 08:10:49 GMT
From:      anne@spider.co.uk (Anne Ambler)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Protocol analyzers

In article <1991Aug6.091939.2340@husc3.harvard.edu> utterbac@husc9.harvard.edu (Margot Utterback) writes:
>We are evaluating protocol analyzers.  So far we will be looking at 
>the Network General Sniffer and the Digilog LanVista 100.  What we are 
>looking for is a portable unit that can diagnose as wide a range of
>problems as possible.  Price is a consideration but not a show stopper.
>Has anyone had any experience with either of these units and can advise
>us about them? And are we missing any other candidates?
>
>Thanks in advance.
>
>utterbac@husc.harvard.edu

You should also consider the SpiderAnalyzer from Spider Systems.

Their address is:


Spider Systems, Inc.
12 New England Executive Park
Burlington
MA 01803 

tel. (617) 270 3510

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 91 08:31:36 GMT
From:      hiroshi@semicon.sony.co.jp (Hiroshi Miyazawa)
To:        comp.protocols.tcp-ip
Subject:   Re: IP routing over ISDN.


In article <1991Aug1.215048.12396@jrd.dec.com>,
        rikitake@jrd.dec.com (Kenji Rikitake) says:
> In article <1991Aug1.032300.8756@nodecg.ncc.telecomwa.oz.au>, ingham@nodecg.ncc.telecomwa.oz.au (bruce ingham 4206700) writes:
> 
> ]	Do any products exist that provide IP routing directly onto
> ]	ISDN ?
> 
> You can attach ISDN boards for Sony NEWS workstations. I've heard several
> people doing IP networking on it. The board is intelligent so you need not to
> have TA.
> 
> -- Kenji

I'm using the NEWS-workstation with ISDN board as "IP router over ISDN".
This combination of equipments are used at many sites in Japan to build
cost-effective WANs over ISDN.  The board make the workstation behave as a
gateway not only over ISDN but also X.25 .  ISDN I/F is S-point and 8-pin
moduler jack.

When the workstation receive an IP packet which is derected to the remote
network, the board automatically (and quickly) establish the ISDN-connection
with the another ISDN-gateway of designated network.  The relations between
network addresses and ISDN numbers are defined in a database file.
(Of course, the sub-address of ISDN number can be assigned to the board)

For the purpose of security, the board never accept the request of connection
if the callers ISDN number is not defined in the database.

Once the connection is established, both LANs become reachable as if they
are connected with leased 64kbps line.  Futher, the users can talk over this
ISDN link with the analog voice I/F of the board wihle doing IP operation.

Also the board disconnect the ISDN link automatically when a certain time
(may be 1 minute or so) has passed since last packet was transfered.


However, I think those equipments are not suitable for the ISDN in U.S.   As
Richard Jennings wrote, I've also heard HP provides same one.  I hope that
is available in both countries and can be used for the international
internetworking over ISDN. 
--------
Hiroshi Miyazawa			Sony Semiconductor Grp. System Div.
hiroshi@semicon.sony.co.jp		4-14-1 Asahi-cho, Atsugi, Kanagawa
					Tel: (81)462-30-5341

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 91 09:30:23 GMT
From:      daveg@prowler.clearpoint.com (Dave Goldblatt)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: "EtherScope" from Racal-Interlan

On 7 Aug 91 12:46:10 GMT, dag@fciva.FRANKCAP.COM (Daniel A. Graifer) said:

dag> I have been using the ethernet protocol analyzer that was bundled free with
dag> the Racal-Interlan NIA310 MacConnect II ethernet controller card in My Mac
dag> IIcx: EtherScope version 1.0.   I'm just an amateur, so I've learned a lot 
dag> about tcp/ip from trapping various types of traffic.  There appears to be
dag> a bug in the way it translates the source ethenet address to a station 
dag> name (from an internal table) in the header of the packet listing.  Also the
dag> initial sequence number and Ack Number of the tcp/ip packets appear to
dag> be translated incorrectly.   So my questions are:

dag> 	1)	Am I just ignorant, or have others observed these problems?

I seem to recall bugs along those lines in earlier versions.

dag> 	2)	If these problems are real, are there other bugs people have
dag>  	    observed that I should watch out for?

Nothing fatal.  In fact, they should be pretty responsive if you find
anything.

dag>     3)  Is there a more recent version of this with these bugs fixed
dag>         available somewhere?

I think the latest (shipping) version is 1.1 -- at least it was when I
left.

You can either call customer service at 1-800-LAN-TALK, or send email
to pulley@interlan.interlan.com (the director in charge of drivers &
EtherScope) and ask him (probably a better bet).

dag> I don't mean to complain.  The card has been a great performer (I bought
dag> it because it was rated #1 by MacUser in their Ethernet Special last
dag> summer), and the price for the software was certainly right!  You can't
dag> beat free, and I can't justify big bucks for a commercial product.  But
dag> the bugs are annoying, and in at least one instance I had trouble
dag> convincing another software vendor that there really was a bug in his
dag> product, since my packet dumps proving it were "obviously suspect".

You wouldn't believe the fight that occurred over giving it away. :-)
But try sending email to the above address if you find bugs -- I think
that group will be quite responsive.

-dg-
--
"We are young, wandering the face of   |  Dave Goldblatt [daveg@clearpoint.com]
  the Earth, wondering what our dreams |  Subsystems Software Engineering
  might be worth, learning that we're  |  Clearpoint Research Corporation
  only immortal for a limited time.." -- Rush, "Dreamline"

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 91 11:28:57 GMT
From:      mark@labtam.labtam.oz.au (Mark Treacy)
To:        comp.protocols.tcp-ip
Subject:   Re: Connected Udp socket question

finnegan@viewlogic.com (David Finnegan) writes:
>    I am having some trouble with 'connected' Udp sockets using the
>    local interface on a DEC Station 3100.
>
>    If the server end of a connected Udp socket is unreachable
>    (closed, for example) then a 'connection refused' error is
>    generated on the next system call to the client socket after a
>    write is performed.
>
>    This behavior is what I expect.
>
>    What I don't expect is that other processes, on the same machine,
>    with local Udp connected sockets also get the connection refused
>    error.
>

[detailed description deleted]

>    It appears, at least to me, that once the rcv process has been
>    killed an attempt to send a character to it generates a connection
>    refused error for each (and every) process with a locally
>    connected Udp socket.  Each process 'trips' the error by trying to
>    send on their connected client socket.  Once the final process in
>    the chain has 'tripped' their error the process starts over again
>    by generating another error with an attempted send to the
>    nonexistent rcv socket.

Correct

>    My question (albeit long winded) is this: is this really a bug in
>    the DS3100 Tcp/Ip code or am I misinterpreting the results?

It's a generic bug in pre 4.3bsd-reno sources, and hence
some tcp/ip implementations derived from such. (SVR4
for example)

Briefly:

The write to the rcv process causes an ICMP port unreachable to
be generated.  icmp_input() calls the protocol ctlinput routine,
udp_ctlinput(), with the destination address of the original
packet which caused the icmp error. udp_ctlinput() calls
in_pcbnotify() which calls udp_notify() for _all_ udp sockets
connected to the destination address which caused the original
icmp error.

in_pcbnotify() needs more information to be a bit more specific
about who it notifies, but the protocol ctlinput mechanism doesn't
allow for it to be passed along.

4.3bsd-reno solves this problem by having icmp_error() pass
along the errornous ip packet and in_pcbnotify() taking
a few more arguments.

	- Mark.

Mark Treacy
Systems Programmer
Labtam Australia		net:	mark@labtam.labtam.oz[.au]
Melbourne, Australia 		phone:	+61-3-587-1444

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 91 12:46:10 GMT
From:      dag@fciva.FRANKCAP.COM (Daniel A. Graifer)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   "EtherScope" from Racal-Interlan

I have been using the ethernet protocol analyzer that was bundled free with
the Racal-Interlan NIA310 MacConnect II ethernet controller card in My Mac
IIcx: EtherScope version 1.0.   I'm just an amateur, so I've learned a lot 
about tcp/ip from trapping various types of traffic.  There appears to be
a bug in the way it translates the source ethenet address to a station 
name (from an internal table) in the header of the packet listing.  Also the
initial sequence number and Ack Number of the tcp/ip packets appear to
be translated incorrectly.   So my questions are:

	1)	Am I just ignorant, or have others observed these problems?
	2)	If these problems are real, are there other bugs people have
 	    observed that I should watch out for?
    3)  Is there a more recent version of this with these bugs fixed
        available somewhere?

I don't mean to complain.  The card has been a great performer (I bought
it because it was rated #1 by MacUser in their Ethernet Special last
summer), and the price for the software was certainly right!  You can't
beat free, and I can't justify big bucks for a commercial product.  But
the bugs are annoying, and in at least one instance I had trouble
convincing another software vendor that there really was a bug in his
product, since my packet dumps proving it were "obviously suspect".

As usual, many thanks in advance to the net community...
Dan
-- 
Daniel A. Graifer			Coastal Capital Funding Corp.
Sr. Vice President, Financial Systems	7900 Westpark Dr. Suite A-130
(703)821-3244				McLean, VA  22102
uunet!fciva!dag				fciva.FRANKCAP.COM!dag@uunet.uu.net

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 91 13:58:32 GMT
From:      bmiller@VCU1.VCU.EDU (Bryan Miller)
To:        comp.protocols.tcp-ip
Subject:   (none)


Has anyone out there ported ATT ditroff for use with Ultrix?

Bryan

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 91 13:58:38 GMT
From:      ckollars@deitrick.East.Sun.COM (Chuck Kollars - Sun BOS Software)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data

Some folks report that using TCP's Urgent Data feature improves their Telnet. 
(example from Steven Bellovin:)
> You've never tried using a version of TCP without it, obviously.  I have...
> Yes, you need it.  You'd be surprised at how much longer it takes to get
> the remote end to shut up when you hit INTR if you don't have out-of-band.

Other folks report that TCP's urgent data doesn't seem necessary.  
(example from Dan Bernstein:)
> I regularly work over a cross-country connection which approximately 10%
> of the time provides throughput under 3KB/sec. What most people don't
> seem to understand is that it's the *client* queue length, *not* the
> server queue length, which matters for TELNET IP and AO. Do you type
> 3KB/sec?

How can they both be right?  What are we missing?
It depends on the implementation details of the server side Telnet.  

o A server side Telnet daemon that does its own buffering will find
  the IP/AO/DM in the stream right away and do the appropriate thing
  with or without TCP's Urgent Data feature.

o A server side Telnet daemon that relies on TCP do to its buffering
  won't see the IP/AO/DM/etc. until its user process reads the input
  stream.  When the server side TCP sees Urgent Data it "wakes up" the
  server side Telnet, an exception to layering.  

  (The Urgent Data notification "nudges" the server side Telnet, but
  doesn't tell it exactly what to do.  The server side Telnet still has
  to read the data stream to find the IP or AO or whatever, then react
  appropriately.  You can have Telnet without Urgent Data, but you
  can't have Telnet without IP/AO/DM/etc.)

---
chuck kollars <ckollars@East.Sun.COM>		(located in Boston)
Systems and Network Administration Group (SNAG)

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 91 14:45:14 GMT
From:      iain@castle.ed.ac.uk (Iain Lindsay)
To:        comp.protocols.tcp-ip
Subject:   ICMP ECHO TTL (was Re:  Connectivity Problems)

In article <9108021241.AA26833@NISC.SRI.COM> NU021172@VM1.NODAK.EDU (Marty Hoag) writes:
>
> ....  when we "PING" you the reply comes back
>with a "good" TTL value of 7 left (which, in a normal case, would mean it
>is 8 "hops" to here).

The use of the phrase "in a normal case" above brings up something which has
been niggling me for quite a while.  I've never found a definitive answer to
the question "what should the TTL be set to in an ICMP ECHO REPLY.  Most (?)
software seems to set the value to something determined locally (I've seen 15,
30 and 255).  However, given the wording of rfc792:

	....... To form an echo reply
	message, the source and destination addresses are simply reversed,
	the type code changed to 0, and the checksum recomputed.

(and correcting it to ensure the correct outgoing source address) I have always
thought that the TTL should simply be decremented from its value on receipt.
The idea behind this is that the echo datagram is 'the same one' all the way
round.  Changing the type code is done simply to ensure that the datagram is
caught when it gets back to its origin.  I can find no reference to 'correct'
behaviour in rfc1122.  However, rfc1122 does say:

            If a Record Route and/or Time Stamp option is received in an
            ICMP Echo Request, this option (these options) SHOULD be
            updated to include the current host and included in the IP
            header of the Echo Reply message, without "truncation".
            Thus, the recorded route will be for the entire round trip.

Which confirms me in my opinion that the initial TTL should be taken from the
incoming datagram.  This enables the originator to be sure of the round-trip
distance to another host, without requiring knowledge of the remote host's
TTL configuration.  Can anyone point me to a definitive answer, or show why
my opinion is wrong?

-Iain Lindsay..

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 91 14:49:06 GMT
From:      dmritter@CBG-99SIMA.ARMY.MIL (Dave Ritter)
To:        comp.protocols.tcp-ip
Subject:   rejection of unregister host mail

Reply To:      dmritter@cbg-99sima.army.mil
Phone:      DSN/AV: 570-9166   Comm: 717-267-9166
Resent-Date:  Thu, 8 Aug 91 12:38:17 MST
Resent-From:  bstring@mainz-emh2.army.mil
Resent-To:  tcp-ip@NIC.DDN.MIL

Hi,

As you are aware, with the increased use of nameservers on the Internet,
many many hosts are not registered in the hosts.txt file.  Therefore, these
"unregister" hosts do not get into the Sperry's /etc/hosts file.  This leads
to a problem with MMDF.S04.  When an unregister host sends mail to a
Sperry, it is rejected.  When I watch the delivery attempt, I see "problem
reading from net".  And in the chan.log I see "Sys error 203 socket
operation on a non socket, netread: ret=0, fd=3" and "smtpsrvr: wrong number
of args!".  In my smtpd.log, I see "p started", as opposed to an entry for a
register hosts of say "cbg-99sima.army.mil started".

Quoting from the "Installation and Operating MMDF II" document (which came
out when MMDF II came out I _think_, the doc is undated)

	NODOMLIT	Prevents Domain Literals (such as [10.0.0.59]) 
			from appearing in addresses.  Since MMDFII doesn't
			currently handle Domain Literals properly, use of
			this option is strongly advised.

I compiled the smtpsrvr without defining NODOMLIT and experienced the same
failure.

It occures to me that the private/academic community (update 43)
should have already tackled this problem as they're heavy into nameserver
use.

Also, an unregister host can't telnet to a Sperry's smtp port (port 25).

Any ideas/suggestions?

TIA,
dave

  ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~
 % Dave Ritter            % These opinions are     %
 % Programmer/Analyst     % My own and do not      %
 % SIMA                   % Necessarily reflect    %
 % AMXSI-TLB              % Those of Management    %
 % Chambersburg, PA 17201 %                        %
  ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 91 18:27:24 GMT
From:      morphy@nntp-server.caltech.edu (Jones Maxime Murphy)
To:        comp.protocols.tcp-ip
Subject:   Where is the FAQ for this group kept?

Please email me with a telnet site, thanks.
Jones
-- 
:)

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 91 19:21:23 GMT
From:      brian@natinst.com (Brian H. Powell)
To:        comp.protocols.tcp-ip
Subject:   ftp-data service ?


     On SunOS, in /etc/services, there's an entry for:

ftp-data	20/tcp

I'm wondering what ftp-data is used for.  Near as I can tell, FTP uses
port 21.  What's the scoop?
     Just curious.  Please respond by mail.

Brian

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 91 21:16:54 GMT
From:      tleng@faline.bellcore.com (Tony L. Eng)
To:        comp.protocols.tcp-ip
Subject:   question about ftp

I have a question concerning ftp between host A and B, A being the client
to server at B:

at the start of an ftp session, I find that on doing an 'ls' on host A,
it sends  a PORT command to the ftp server on B, then
a packet with data field:

	..9..NLST

to host B, which replies with

        500 '9': command not understood.

what can cause Host A to do such a thing?  On examing packets on the
ethernet, it seems that host B proceeds to send the directory listing,
but host A doesn't display it onto the screen, nor does it process the
226 message that Host B sends (perhaps the 500 message triggers some
blocking mechanism on Host A).  

Aborting the session and trying to ftp again results in some other character
besides '9'.  

does anyone have any ideas?

thanks in advance,
cheers,
Tony

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 91 22:54:42 GMT
From:      dricejb@drilex.UUCP (Craig Jackson drilex1)
To:        comp.protocols.tcp-ip
Subject:   Re: Sub standard FTP implementation

In article <NU0DCI9@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
>In article <9107312114.AA25385@ftp.com> jbvb@ftp.com writes:
>> RFC 1123 remedies that lack - see the section on FTP.  I myself haven't
>> seen software that didn't implement LIST or NLST since 1987, and it was
>> out of date at that time.
>
>DDN1100 on the Unisys 1100 mainframes.

Unisys A-Series boxes aren't any better.
Their current implementation of TCP/IP doesn't do LIST or NLST, either.

They don't even do UDP, so they can't run DNS.

Supposedly, this is all fixed in the next release, whenever that comes out.
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,alliant,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 91 03:32:43 GMT
From:      keith@novell.com (Keith Brown)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Protocol analyzers

>In article <1991Aug6.091939.2340@husc3.harvard.edu>, utterbac@husc9.harvard.edu (Margot Utterback) writes:
>
>Go with the Sniffer, for a single unit it covers the most LAN nad WAN
>protocols.

Hold up! As you might expect, I'm a LANalyzer user myself and I can vouch
for the fact that the thing decodes more protocols than you can shake a
stick at! Also, all these decodes are included for free (very free in
my case :-)). I believe Network General still charge extra for each protocol
family your interested in having broken out for you.

The guys in our lanz group just cranked out a new release (version 3.11)
which decodes a positively horrendous number of protocols. You can even
"feed" it SNMP Management Information Bases and it will start decoding
all your SNMP queeries and responses to and from "proprietary" (vendor
specific) MIBs. You feed it the ascii MIB files in either SMI format
or the newer concise format specified in RFCs 1212 and 1215 (and no I
didn't remember that, I had to look in the manual :-)). The lanz also
comes with over 120 canned experiments to both analyze and characterize
the piece of cable into which it is plugged (from the protocol perspective).
It's great fun to play with :-)

Oh... and in case your wondering.... yes it does decode LAN Manager and
Banyan Vines protocols too. The LANalyzer group can be hailed
on 1-800-243-8526.

Keith

Disclaimer: The Lanalyzer division of Novell is in a completely different
            building to me and I have no affiliation to them whatsoever,
            particularly since they creamed my group in a softball match
            during a company outing last year! In fact, I spit on them :-)
-
Keith Brown                                      Phone: (408) 473 8308
Novell San Jose Development Centre               Fax:   (408) 433 0775
2180 Fortune Dr, San Jose, California 95131      Net:   keith@novell.COM

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 91 14:54:54 GMT
From:      PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   EBCDIC ASCII and *much* more

In answer to the questions of an EBCDIC/ASCII translation and "Which EBCDIC?",
I offer a paper containing in-depth analysis of the situation, extending into
the field of [inter]national characters support in communication protocols.
The concepts and methods hold for TCP/IP applications.
The paper stems from discussion with programmers who wanted to enlarge
usability of their software and takes the form of a how to understand and
do it practically.
Of translation tables data, you'll get your share...

ftp vm1.ulg.ac.be
anonymous
cd anonymous
get ISO8859.NOTES

A broader aspect of the ASCII/EBCDIC or ISCII/EBCDIC is covered in
Edwin Hart's White Paper of SHARE to IBM.
Support of international characters with Kermit is described in
watsun.cc.columbia.edu:kermit/e/isok5.txt

Andr'e PIRARD         SEGI, Univ. de Li`ege        139.165 IP coordinator
B26 - Sart Tilman     B-4000 Li`ege 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 91 15:53:40 GMT
From:      jesmith@gdfwc3 (Jesse Smith)
To:        comp.protocols.tcp-ip
Subject:   POSIX Interface to TCP/IP

Is there a POSIX draft document which describes the application interface to
the transport layer (specifically, TCP/IP and UDP/IP)?  If so, what is its
number and how can I order a copy?

Thanks,
Jesse E. Smith
General Dynamics Corp.
Fort Worth, TX
gdfwc3!jesmith@central.sun.com

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 91 17:10:39 GMT
From:      fmueller@telebit.com (Fritz Mueller)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Authentication

Can anyone tell me how the various terminal server vendors do user
authentication over a network.  I understand that cisco terminal servers
use TACACs and Xylogics uses a proprietary method based on TACACs.  What
do DEC, Xyplex, 3Com and all the others do?  Unless they are keeping
the user ID and password right on a disk on the terminal server they
must be getting the information off a network server with some protocol.



-- 
Fritz Mueller             408-745-3028
Product Manager           

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 91 13:07:32 GMT
From:      mleech@bnr.ca (Marcus Leech)
To:        comp.protocols.tcp-ip
Subject:   Getting a class-C allocation  (FAQ warning)

This is almost certainly an FAQ:

I want to get a class-C network for my basement computing complex ;-)

Do I still do such things via registrar@nic.ddn.mil?  Does the NIC at
  SRI still exist?  It's been a couple of years since I last had to do
  this, and things may have changed.

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 91 14:08:43 GMT
From:      bmiller@VCU1.VCU.EDU (Bryan Miller)
To:        comp.protocols.tcp-ip
Subject:   Broadcast address


Would someone like to share their thoughts on broadcast address for
individual hosts?  We have a class B address, we'll call 150.150.x.x.
As the new network manager here, I was surprised to find all the
broadcast addresses on our machines set to 150.150.1.255.  Our
network is split into 3 campuses.

I would have thought that you would want a broadcast message sent
to ALL hosts on 150.150, not just those on 150.150.1.  Am I missing
something here?

Thanks for any tips.

Bryan Miller
Virginia Commonwealth University

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 91 16:04:45 GMT
From:      rae@s5000.rsvl.unisys.com (Rick Erickson x2132)
To:        comp.protocols.tcp-ip
Subject:   Gratuitous ARP

I've heard references to 'gratuitous ARP'. Can anybody explain this? My
understanding is that hosts and routers that receive an ARP Request will
refresh their ARP caches, but that is how ordinary ARP works, so what is
'gratuitous ARP'? 

Another question is whether there are any ARP implementations that do not
refresh their ARP cache when a broadcasted ARP Request is seen? 

                                         Rick Erickson

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 91 16:13:27 GMT
From:      daveg@prowler.clearpoint.com (Dave Goldblatt)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: "EtherScope" from Racal-Interlan


By the way, I just found out that EtherScope is up to version 1.2.2,
and has full support for System 7.

Contact pulley@interlan.interlan.com with questions, etc.

-dg-

--
"We are young, wandering the face of   |  Dave Goldblatt [daveg@clearpoint.com]
  the Earth, wondering what our dreams |  Subsystems Software Engineering
  might be worth, learning that we're  |  Clearpoint Research Corporation
  only immortal for a limited time.." -- Rush, "Dreamline"

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 91 16:58:39 GMT
From:      rgoldstone@OAVAX.CSUCHICO.EDU (Robin Goldstone)
To:        comp.protocols.tcp-ip
Subject:   Finger server as a requirement for all Internet hosts

I doubt this is the appropriate place to bring this up, so maybe someone
can refer me to a newsgroup or mailing list where issues such as these are
discussed.

I would like to see a requirement for all Internet domains to operate a
finger (or whois) server to serve the top-level domain at their site.
I often have users come to me and say "I want to send e-mail to my colleague
at the University of XYZ.  Is there some way I can look up their address?"
And I feel that the answer to this question should be YES, given that you 
know the person's last name and the domain name for the organization (which
can be obtained from the NIC using WHOIS if you don't know it).  This
would parallel the function of the telephone directory assistance service.
If you know the area code (which you can get from local directory assistance
if you don't know it) then you can contact the desired directory assistance
using (area code) 555-1212.  Users should be able to finger:
lastname@top-level-domain (e.g. goldstone@csuchico.edu) and get back a valid
e-mail address.

So I am wondering if there is any effort under way to standardize on some
form of electronic "directory assistance" on the Internet.  Like I said,
I don't know if this is the place to discuss this. If not, tell me where to
go (well, you know what I mean!).  

***********************************************************************
Robin Goldstone, Systems Software Specialist
California State University, Chico  Computing Services
rgoldstone@oavax.csuchico.edu

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 91 17:27:36 GMT
From:      coates@UC780.UMD.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: POSIX Interface to TCP/IP

In article <JESMITH.91Aug8165340@kuwait.gdfwc3>, jesmith@gdfwc3 (Jesse Smith) writes:
>Is there a POSIX draft document which describes the application interface to
>the transport layer (specifically, TCP/IP and UDP/IP)?  If so, what is its
>number and how can I order a copy?
>
>Thanks,
>Jesse E. Smith
>General Dynamics Corp.
>Fort Worth, TX
>gdfwc3!jesmith@central.sun.com


I don't believe POSIX uses TCP-IP or UDP-IP.  I understand its purpose to be to
provide a uniform interface for applications to OSI transport and network
protocols.

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 91 17:54:32 GMT
From:      raphael@dorsai.com (Raphael Laderman)
To:        comp.protocols.tcp-ip
Subject:   CompressNET

Has anyone any experience or thoughts on Process Software's CompressNET? It 
apparently compresses TCP/IP data before TCP gets it, thereby reducing the 
number of packets and amount of data transmitted between nodes using the 
software. 
 
They claim to be transparent to both the application programs and the TCP. 
I'm wondering how transparent they can be with any stability: how could they 
insert themselves in the datastream without disrupting something. They claim 
to work with anyone's applications and anyone's TCP with no relinking.
 

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 91 18:05:20 GMT
From:      aets-kja-a-ao3@ANSBACH-EMH1.ARMY.MIL ("Thomas F. Pockberger")
To:        comp.protocols.tcp-ip
Subject:   A new dump question

Sorry but I am REALLY new to TCP/IP.

here is my question:

If two Internet sites establish a connection it normally goes thru a couple
of "hops". Each of them uses one TTL count on the packets. Is there
something like a "return receipt" from the receiving machine which also
has TTLs and uses them.

Sample:
I conect to a host, some of the packet goes thrue 13 hops but most thru
16 hops. TTL is set to 15 on our machine. So the packets with 13 hops get
thru the 16 hops not. Can the result be something like "timed out".?
If the receiving machine is sending acknowledgement on the 13 hops packet
can this result in a kind of "loose" connection. (connect; permission denied)

Sorry if this is a dump question. Can somebody shine a light on me.

Pocky

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 91 18:34:06 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re: Sub standard FTP implementation

This message is for history buffs only.

Mike,

I think my memory stands the test.  Now that it has been challenged, I
have gone back to the original RFC's.  

RFC's 171 and 172 were published in June 1971.  I was a co-author of
each.  RFC 171 defined "The Data Transfer Protocol", and RFC 172 defined
"The File Transfer Protocol."  RFC 172:
 - contains the statement "FTP uses the data transfer protocol described
   in RFC 171 to achieve transfer of data."
 - contains the statement "Implementation of a workable* subset of
   opcodes is specifically permitted."
   " * A workable subset is any request, plus terminates."
RFC 171 begins with the sentence:
   "A common protocol is desirable for data transfer in such diverse
   applications as remote job entry, file transfer, network mail system,
   graphics, remote program execution, and communication with block data
   terminals (such as printers, card, paper tape, and magnetic tape
   equipment, expecially [sic] in context of terminal IMPs)."

The first RFC which combined the Data Transfer and File Transfer
protocols is RFC 354, published in July 1972 under the author name Abhay
Bhushan (MIT).  It reports on the work of a committee, listed on the
last page of the RFC.  This RFC does not define a minimum FTP
implementation.

Cheers,
Alex
 

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 91 00:01:04 GMT
From:      small@turing.seas.ucla.edu (James F. Small)
To:        comp.protocols.tcp-ip
Subject:   att 3b2 and slipinks)


I'm trying to set up a slip connection on an att 3b2 running unx sys v r3
with WIN tcpip.  any hints , or anyone know where I can find hints?

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 91 01:05:08 GMT
From:      geertj@philica.ica.philips.nl (Geert Jan de Groot)
To:        comp.protocols.tcp-ip
Subject:   Re: Finger server as a requirement for all Internet hosts

In article <1991Aug09.165839.21578@ecst.csuchico.edu> rgoldstone@OAVAX.CSUCHICO.EDU writes:
>I would like to see a requirement for all Internet domains to operate a
>finger (or whois) server to serve the top-level domain at their site.
>I often have users come to me and say "I want to send e-mail to my colleague
>at the University of XYZ.  Is there some way I can look up their address?"

I don't think this is a good idea. First off, finger sometimes provide
usable hacker info (this is why some sites don't allow finger).

Second, the site might distribute mail internally via aliases, so there is no
account for that user on the mailhost, and no finger info..

Third, not all sites have IP connectivity or are allowed to use part of
the network (in Europe, access on the NSFnet backbone is something
that has to be asked for and doesn't come automatically).

Fourth, some sites are not connected via IP but use UUCP or BITNET or
other means, which means finger doesn't work for them.

In situations like these, I have successfully used sending mail to
postmaster@XYZ.edu. Now, you're talking to a human (postmaster is
defined to be a name that is looked at frequently), and (s)he should
know or should be able to point you to someone who does.

Good hunting,
Geert Jan


--8<--nip-nip---------------------------------------------------------------
"We trained hard - but it seemed that every time we were beginning to form up
into teams, we would be reorganized. It was to learn later in life that we tend
to meet any new situation by reorganizing, and a wonderful method it can be
for creating the illusion of progress while producing confusion, inefficiency,
and demoralisation." - possibly from Petronius, 100 BC

Geert Jan de Groot, Philips ICA, Weisshausstrasse 1, 5100 Aachen, Germany
Email: geertj@ica.philips.nl or ..!hp4nl!philica!geertj
Phone: +49 241 6003 714  FAX: +49 241 6003 709


>And I feel that the answer to this question should be YES, given that you 
>know the person's last name and the domain name for the organization (which
>can be obtained from the NIC using WHOIS if you don't know it).  This
>would parallel the function of the telephone directory assistance service.
>If you know the area code (which you can get from local directory assistance
>if you don't know it) then you can contact the desired directory assistance
>using (area code) 555-1212.  Users should be able to finger:
>lastname@top-level-domain (e.g. goldstone@csuchico.edu) and get back a valid
>e-mail address.
>
>So I am wondering if there is any effort under way to standardize on some
>form of electronic "directory assistance" on the Internet.  Like I said,
>I don't know if this is the place to discuss this. If not, tell me where to
>go (well, you know what I mean!).  
>
>***********************************************************************
>Robin Goldstone, Systems Software Specialist
>California State University, Chico  Computing Services
>rgoldstone@oavax.csuchico.edu

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 91 01:27:20 GMT
From:      coolidge@speaker.sgi.com (Don Coolidge)
To:        comp.protocols.tcp-ip
Subject:   Re: Gratuitous ARP

In article <236@s5000.rsvl.unisys.com> rae@s5000.rsvl.unisys.com (Rick Erickson x2132) writes:
>I've heard references to 'gratuitous ARP'. Can anybody explain this? My
>understanding is that hosts and routers that receive an ARP Request will
>refresh their ARP caches, but that is how ordinary ARP works, so what is
>'gratuitous ARP'? 

Probably when the act of configuring an interface with an IP address causes
the host to send out an ARP request for that address over that interface.
Nobody will answer, but everyone who refreshes his cache will get a guaranteed
up-to-date IP address to match with the meduim address.

(When I worked at a different company, we called ours "Unsolicited ARPs".)

- Don Coolidge 
coolidge@sgi.com

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 91 04:26:08 GMT
From:      ole@CSLI.STANFORD.EDU ("Ole J. Jacobsen")
To:        comp.protocols.tcp-ip
Subject:   TCP Urgent Data


By the way, a discussion of this topic appeared in an article by
Mitch Tasman in the June 1990 issue of ConneXions. The article
was entitled "Telnet Output Discard Processing".

Ole

Ole J Jacobsen, Editor & Publisher ConneXions--The Interoperability Report
Interop, Inc., 480 San Antonio Road, Suite 100, Mountain View, CA 94040,
Phone: (415) 962-2515  FAX: (415) 949-1779  Email: ole@csli.stanford.edu

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 91 05:48:13 GMT
From:      mikeb@polari.UUCP (Mike Branch)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   TCP/IP printing on VMS


Can anyone tell me how to send data to a printer connected to VAX/VMS over
TCP/IP?  I'm interested in using either Wollongong, or getting really creative
and using sockets.  I'd also like to get data back from the printer, in case
it happens to be a PostScript printer.

Please make your responses readable by a 5-year-old, as I am a neophyte
when it comes to TCP/IP.  VMS and DECnet have spoiled me.  Or, if you know
of a lucid hardcopy discussion of the subject, I'd love to hear about it.

Thanks in advance for your help.
  
-- 
Mike Branch, Bellevue, Washington
mikeb@polari.UUCP
uw-beaver!sumax!polari!mikeb

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 91 07:06:24 GMT
From:      greg@gagme.chi.il.us (Gregory Gulik)
To:        comp.sys.att,comp.protocols.tcp-ip
Subject:   3B2 Ethernet problems.

I'm running the following hardware/software:

3B2/400
NI card in slot 6 and other cards
Cabletron Systems ST-500 with LANVIEW transceiver
WIN/3B 1.1

The problem I'm having is that the diagnostics are failing
on the NI card.  At first, I didn't have a transceiver so
I expected that, but it didn't go away once I hooked it up.

The problem with the transceiver is that I don't have
any documentation on it!!  What does the SQE light mean?
Is it suppsed to always be on?  What does the jumper
inside mean?  The PWR light is on, so that's a pretty
good sign.  There is a terminator connected before
anyone asks the obvious.

I looked in the NI card docs, and it doesn't
seem to help.  All is tells you is how to plug
it in.

-greg

-- 
Gregory A. Gulik                                        Call Gagme, a public
       greg@gagme.chi.il.us  ||  gulik@depaul.edu       access UNIX system at
   ||  gulik@motcid.rtsg.mot.com                        (312) 714-8568

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 91 08:51:43 GMT
From:      dhuber@aut.autelca.ascom.ch (Daniel Huber)
To:        comp.protocols.tcp-ip,comp.protocols.ibm,comp.sys.hp
Subject:   tn3270 mapping for HP workstations


I send you this message below for a friend. If you decide to answer, could you
please send him your suggestions directly? (mzahn@autelca.ascom.ch) Thanks. 

Daniel

######################################################################

Programm Documentation for tn3270 - full screen remote login to IBM AS/400

In our company we use HP and SUN workstations for the product development.
On the commercial side we have an IBM/AS400 for the product planning (PPS).
It is essential that our engineers have the possibility of a direct access
to the IBM-AS/400 system with the TELNET-emulation.

We have at our disposal a version of the public domain software tn3270
and we have examined this product.
Our intention is to map the HP/SUN Keyboards to the IBM 5250 Keyboards which
caused us a problem :

- The HP Keyboard has different keys which dont produce an esqcape sequence
so we must use the HIL-Interface to fetch this keys. For this we must write
an own C-programm which conforms to this functionality. For the keys which
delivers an escape sequence we can use the map file /etc/map3270, this keys
are not the problem. But we want to use also the other keys on the HP46021A
keyboard.

- Where do we have to build in our own code in the existing tn3270 code ?

- It takes a lot of time to find out which is the correct tn3270 module ?

Please send us detailled information (if possible) about the programm design 
of tn3270 by E-Mail. Thanks a lot..

We would be very happy to here from you !

Martin

######################################################################

Additional notes:

- HP's are HP9000/3xx
- we have sligthly adapted code for HPUX 7.0. (from iris613.gsfc.nasa.gov)
- tn3270.hp runs fine with keys mapped on ctrl-shift-xy keys, but we want to
  use the function keys f1-f8 and for f9-f12 (f21-f24) the keys, Martin
  mentioned above.
- The question is, where to begin for implementing the solution for the HIL
  keys. Any hint from you, to expand which module, function or file would be 
  the best way to do it, would be greatly appreciated.
- I guess this could be the first step for a patch to tn3270 ?

Thanks a lot..

Daniel


-- 
Daniel Huber AD-KT2.6   VOICE: +41 31 52 96 64 FAX: +41 31 52 97 51
Ascom Autelca AG        Network Engineer ( Network, E-Mail, News )
CH-3073 Guemligen       EMAIL:  dhuber@autelca.ascom.ch
Switzerland             UUCP:   uunet!{chsun,chx400}!hslrswi!aut!dhuber


-- 
Daniel Huber AD-KT2.6   VOICE: +41 31 52 96 64 FAX: +41 31 52 97 51
Ascom Autelca AG        Network Engineer ( Network, E-Mail, News )
CH-3073 Guemligen       EMAIL:  dhuber@autelca.ascom.ch
Switzerland             UUCP:   uunet!{chsun,chx400}!hslrswi!aut!dhuber

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 91 09:00:23 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp-data service ?

In article <26748@natinst.natinst.com>, brian@natinst.com (Brian H. Powell)
 wrote:
>On SunOS, in /etc/services, there's an entry for:
>    ftp-data	20/tcp
>I'm wondering what ftp-data is used for.  Near as I can tell, FTP uses
>port 21.  What's the scoop?

FTP uses port 21 for commands and responses, but uses port 20
to transfer the actual file data.

...Sam
-- 
<skl@wimsey.bc.ca>

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 91 22:40:47 GMT
From:      marikar@digrev.UUCP (Mo)
To:        comp.protocols.tcp-ip
Subject:   Not on mailing list. Need benchmarking tool

Hi,
  
I am in the process of reviewing terminal 
servers that have Telnet to LAT conversion 
capabilities. Is there any benchmarking 
tool in the public domain area that will 
allow me to quantify throughput and 
character response time for terminal 
servers ? 

Thanks.

/Mo Marikar
Digital Review Labs.
  

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 91 22:48:10 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Gratuitous ARP

In article <1991Aug10.012720.7148@odin.corp.sgi.com> coolidge@speaker.UUCP (Don Coolidge) writes:
>In article <236@s5000.rsvl.unisys.com> rae@s5000.rsvl.unisys.com (Rick Erickson x2132) writes:
>>I've heard references to 'gratuitous ARP'. Can anybody explain this?
 
>Probably when the act of configuring an interface with an IP address causes
>the host to send out an ARP request for that address over that interface.
>Nobody will answer, but everyone who refreshes his cache will get a guaranteed
>up-to-date IP address to match with the meduim address.

Sometimes someone *does* answer, in which case you know that there's a
configuration problem.  When SunOS receives a reply to its unsolicited ARP,
it reports "Duplicate IP address".  On the occasions where I've seen this,
the problem wasn't actually that two hosts had the same IP address (most of
our Suns get their IP addresses using RARP), but that the Sun was connected
to the wrong subnet for its IP address; we have a cisco router that does
proxy ARP, and it was responding to the unsolicited ARP.

-- 
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 91 23:18:00 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: TFTP block counter

In article <9108060700.AA08124@crayamid.cray.com> mni@CRAYAMID.CRAY.COM (Michael Nittmann) writes:
>just a comment: the problem is probably not Mbytes, but the question of 32kB
>or (unsigned, one more bit) 64kB blocks buffered on a 16 bit machine. 

No, this is entirely a non-issue for TFTP, whose blocks are at most
512 bytes.  The problem is that its sequence numbers for blocks are only
16 bits long.
-- 
Arthritic bureaucracies don't tame new  | Henry Spencer @ U of Toronto Zoology
frontiers. -Paul A. Gigot, WSJ, on NASA |  henry@zoo.toronto.edu  utzoo!henry

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 91 23:25:16 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Finger server as a requirement for all Internet hosts

In article <1991Aug09.165839.21578@ecst.csuchico.edu> rgoldstone@OAVAX.CSUCHICO.EDU writes:
>I would like to see a requirement for all Internet domains to operate a
>finger (or whois) server to serve the top-level domain at their site.
>I often have users come to me and say "I want to send e-mail to my colleague
>at the University of XYZ.  Is there some way I can look up their address?"

The correct answer to such a question is:  "Phone him up and ask.  That
way you can also ask whether he reads his mail regularly."  Between people
with multiple accounts, people with very similar names (there are two
professors named "A. Zimmerman" in our department, for example), people
on vacation, and people who have accounts but seldom or never read their
mail, a directory lookup service simply is not an adequate solution.
-- 
Arthritic bureaucracies don't tame new  | Henry Spencer @ U of Toronto Zoology
frontiers. -Paul A. Gigot, WSJ, on NASA |  henry@zoo.toronto.edu  utzoo!henry

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 91 17:40:47 GMT
From:      allyn@sleepy.UUCP (Mark Allyn)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Using both /etc/hosts and domain name server to get host addrs

I have a situation here where I need to have some machines access 
both the /etc/hosts file and the domain name server for host  name
and address resolution.

Our site has Suns running sunos 4.1.1. We use network file system and
NIS extensively throughout the site therefore the machines need to 
access the /etc/hosts (which is NIS mapped) so they can know where
to access NFS files at boot time.

Currently, we are not using the name server that is being established
for the company but we are thinking about connecting to it.

I am concerned because once we connect to it (by establishing a 
resolv.conf file) we may no longer have access to the /etc/hosts file
locally. We have requirement where we have to set up temporary machines
in our network which we dont want to have listed in the domain name
server but we want to put in the local NIS host map or the machine's
local /etc/hosts file.

I have tried the manuals and some experimenting and found:

1. The manuals were not clear on how to have the gethost functions access
   both the domain name server and the local host files.

2. A local site that I have an account on using a Vax running ULTRIX seems
   to have done the trick, but I poked around and could not see anything
   special with their resolv.conf file and they are running as a domain
   server (no named.boot files and nothing in rc files to start the named
   daemon).

3. Another site that I have access to which is running resolv but not a
   name server (a Sun running sunos 4.0.3) will not access both the
   name server and the /etc/hosts file at the same time. ( I tried
   to rlogin into itself using the name of the machine without the
   domain name and it could not find it)

I would greatly appreciate any help you folks may have. Thanks!

Mark Allyn
206-526-8852
206-865-4699
 
  

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 01:01:00 GMT
From:      small@turing.seas.ucla.edu (James F. Small)
To:        comp.protocols.tcp-ip
Subject:   subscribe

Please subscribe me to the mailing list

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 04:56:48 GMT
From:      jeff@onion.rain.com (Jeff Beadles)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: Using both /etc/hosts and domain name server to get host addrs

allyn@sleepy.UUCP (Mark Allyn) writes:

>I have a situation here where I need to have some machines access 
>both the /etc/hosts file and the domain name server for host  name
>and address resolution.

Well, I had the same problem when we connected to the Internet.  I didn't see
an apparent solution, so I ended up modifying gethostbyxxx, in libc/libresolv.

If you would like a copy of this, please let me know.  Basically it understands
DNS/bind, and /etc/hosts.  I have no use for YP/NIC, so I didn't bother.  The
order of resolution is configurable.

Drop me a note if you would like a copy.  It's no harder to install than adding
the resolver stuff to libc.

	-Jeff
-- 
Jeff Beadles		jeff@onion.rain.com

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 06:21:22 GMT
From:      skl@cs.sfu.ca (Sam Lam)
To:        comp.protocols.tcp-ip,alt.sys.sun
Subject:   BSD 4.3-Reno routed(8C) on SunOS 4.1.1

Has anyone got the BSD 4.3-Reno/4.4 routed/in.routed(8C) sources
running on a SunOS 4.1.1 SPARC?

Please reply via mail, I will summarize.  Thanks.

...Sam
-- 
<skl@cs.sfu.ca>

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 11:05:57 GMT
From:      ccrth@lut.ac.uk (Rob Thirlby)
To:        comp.protocols.tcp-ip
Subject:   pc-nfs


We are trying to set up a class room of IBM LEO ie PS2/55 machines
packaged with a modified Western Digital Ethernet board.

We wish to run concurrently pc-nfs and novell (the pc-nfs is necessary to
support a proprietary X-windows product).

We seem to have two problems

1) is there a packet driver for this IBM/wd ether board?

2) Is there any way of modifying/patching pc-nfs to make its printer
capture mechanism use drives lower down the alphabet.  
Having to specify lastdrive=V clobbers novell's search path system
which uses drive letters from Z upwards.

Any help or experience on either fron would be appreciated.

Rob Thirlby.




. 

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 11:06:01 GMT
From:      rbrickey@BBN.COM (Ron Brickey)
To:        comp.protocols.tcp-ip
Subject:   Removal


Please remove me from the subject mailinglist.

---
ron

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 13:27:37 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: rejection of unregister host mail

In article <9108081056.AA07170@NISC.SRI.COM> dmritter@CBG-99SIMA.ARMY.MIL (Dave Ritter) writes:
   With the increased use of nameservers on the Internet, many many
   hosts are not registered in the hosts.txt file.  Therefore, these
   "unregister" hosts do not get into the Sperry's /etc/hosts file.
   This leads to a problem with MMDF.S04.  When an unregister host
   sends mail to a Sperry, it is rejected...

See RFC-1031 of November 1987.  Since October 1989, when the use of
the host table was discontinued and the Milnet's mandatory conversion
to the use of domain name service was expected to be completed, hosts
represented in a nameserver are more "registered" than those in
hosts.txt.

Sperry has come catching up to do.

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 18:29:53 GMT
From:      jason@hpcndjdz.CND.HP.COM (Jason Zions)
To:        comp.protocols.tcp-ip
Subject:   Re: POSIX Interface to TCP/IP

The POSIX working group which is developing a set of standards for Protocol-
Independent Interfaces is 1003.12, chaired by Les Wibberley
(lhw25@cas.bitnet). To get current drafts, you really should join the
mailing list; for one-time only sorts of things, contacting the chair
should work.

Wibberley, Les
Chemical Abstracts Service
P.O. Box 3912
Columbus, OH  43210

As was observed, the interfaces are not TCP or UDP specific, and are instead
aimed at being more generic interfaces independent of protocol.
--
This is not an official statement of the IEEE, POSIX, or HP. No warranty is
expressed or implied. The information included herein is not to be construed
as a committment on anyone's part. I'm not speaking on anyone's behalf.

Jason Zions			The Hewlett-Packard Company
Chair, P1003.8, POSIX TFA	3404 E. Harmony Road
Mail Stop 102			Ft. Collins, CO  80525  USA
jason@cnd.hp.com		(303) 229-3800

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 18:40:56 GMT
From:      simon@fuquad.westford.ccur.com (Simon Rosenthal)
To:        comp.protocols.tcp-ip
Subject:   Re: Gratuitous ARP

In article <1991Aug10.012720.7148@odin.corp.sgi.com> coolidge@speaker.UUCP (Don Coolidge) writes:
>In article <236@s5000.rsvl.unisys.com> rae@s5000.rsvl.unisys.com (Rick Erickson x2132) writes:
>>I've heard references to 'gratuitous ARP'. Can anybody explain this?
>> ...
>Probably when the act of configuring an interface with an IP address causes
>the host to send out an ARP request for that address over that interface.
>Nobody will answer, but everyone who refreshes his cache will get a guaranteed
>!!!!!!!!!!!!!!!!!!
>up-to-date IP address to match with the meduim address.
>
>- Don Coolidge 

Well, they do occasionally (even in the most carefully managed networks !). 
Concurrent has a "DUPLICATE IP ADDRESS !!!" message logged and printed out
on the system console, along with the MAC address that generated the ARP
reply, so that the system/network manager can resolve the conflict. 

- Simon
_______________________________________________________________________________
Simon Rosenthal:                         ___________
Concurrent Computer Corporation         / _________/_ 
Westford, MA 01886                     /_/________/ /
Internet: simon@westford.ccur.com       /__________/

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 19:04:05 GMT
From:      ddl@husc6.harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: behavior when receiving >1 ARP REPLY

In article <1991Aug1.002101.17581@telebit.com>, brunner@telebit.com (Eric Brunner) writes:
| While pessimal routes are a problem, the undocumented semantics of the 3rd
| bit in the RIF cause more problems in the unicast reply, but that is another
| subject.

	What are these undocumented semantics?

				Dan Lanciani
				ddl@harvard.*

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 19:06:51 GMT
From:      jbvb@ftp.com (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TN term type

Terminal Type as originally designed (RFC 930) was a simple way of letting
the client tell the server what kind of terminal it was.  RFC 1091 added
support for clients (PCs or the like) which could be several different
kinds of terminal, so the server could pick the one which was the best
match.  The specific problems I was trying to solve were:  First, to eliminate
the need for human intervention when one Telnet client was used to talk to
several different hosts (e.g. mainframes and unix boxes), and second, to
allow the server to ask the client to change the type of emulation in mid-
session (e.g. so applications that work best with different terminals can
be used together).

I didn't try to deal with the more general issue of what happens when the
terminal type the host or application wants doesn't match any of those the
client can provide.  The user loses, as usual, and the only items in
question are when and how he/she finds out.  Since you can't know the
particular combination of applications and functions the user wants before
they try, I vote for the status quo, or maybe a mild "I can only handle
these terminal types {list} that your client supports as NVT Ascii"
warning message from the server at login time.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 19:06:53 GMT
From:      jbvb@ftp.com (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Protocol analyzers

There are a number of software network monitors/protocol analyzers out
there, including LANWatch from FTP Software, WIN/Watch (may have been
renamed recently) from Wollongong and WatchTower from Intercon.  These
use an existing PC (or Mac in the case of WatchTower) and network
interface, and tend to cost between 1/10th and 1/100th of the price of
a similarly-equipped high-end product.  There's also Netwatch, which
is free as part of the MIT/CMU/Harvard PCIP software package.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 19:22:00 GMT
From:      gmc@premises1.quotron.com (Greg Christy)
To:        comp.protocols.tcp-ip
Subject:   Subnet Practice?


While it is recommended practice to make subnet bits contiguous and
use the most significant bits of the local address (for sanity's
sake), it is not required.   See the following RFC excerpts:  

From RFC 950 (Internet Standard Subnetting Practice):

     "Since the bits that identify the subnet are specified by a
      bitmask, they need not be adjacent in the address.  However, we
      recommend that the subnet bits be contiguous and located as the
      most significant bits of the local address."


From RFC 1122 (Requirements for Internet Hosts -- Communications Layers):


            We now summarize the important special cases for Class A, B,
            and C IP addresses, using the following notation for an IP
            address:

                { <Network-number>, <Host-number> }

            or
                { <Network-number>, <Subnet-number>, <Host-number> }

            and the notation "-1" for a field that contains all 1 bits.
            This notation is not intended to imply that the 1-bits in an
            address mask need be contiguous.

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 19:41:13 GMT
From:      carroll@ssc-vax (Jeff Carroll)
To:        comp.protocols.tcp-ip
Subject:   Re: Finger server as a requirement for all Internet hosts

In article <868@philica.ica.philips.nl> geertj@ica00.ica.philips.nl (Geert Jan de Groot) writes:
>In article <1991Aug09.165839.21578@ecst.csuchico.edu> rgoldstone@OAVAX.CSUCHICO.EDU writes:
>>I would like to see a requirement for all Internet domains to operate a
>>finger (or whois) server to serve the top-level domain at their site.
>
>Second, the site might distribute mail internally via aliases, so there is no
>account for that user on the mailhost, and no finger info..

There are now several domains that are nationally if not internationally
distributed (.boeing.com now has sites in at least five states across the
country, and others, particularly large computer manufacturers, are even
more widely distributed). In our case, the people who operate the gateway
have no control over or information about users of other machines; and in
any case, the company considers such information to be proprietary (one
reason is to make unsolicited contacts from outside difficult, in order
to dissuade persistent salesmen. Stockbrokers are particularly notorious.)

Corporations that are cognizant of whois and finger generally disable them;
and it's quite often wrong to assume that people who perform and publish
research are connected to Internet, even in the USA, especially if they
work in the corporate sector.



-- 
Jeff Carroll		carroll@ssc-vax.boeing.com

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 20:16:20 GMT
From:      map@isi.edu (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Sub standard FTP implementation

Alex (and other protocol arachaeologists)--

Hmmmmm.  You appear to have been having meetings behind my back -- or were
RFCs 171/2 complete solos?  (Or was I too busy in May and June of '71
getting Multics Telnet on the air by the July 1 deadline to attend?)
No, on closer inspection you do say "CO-author"; eliminate solo option,
anyway.  Re-hmmm.

At any rate, I must concede that your EMAM is NOT worse than mine on this
one, given the RFC 354 evidence in particular, since that was based on
meetings I did attend.  Of course, RFC 354 was very flawed (containing,
e.g., the infamous Mail should be free, I.E. not require a login solecism,
where it SHOULD have said "e.g."), so maybe we had INTENDED a minimum
implementation list be in it....  (Now I'll probably hear it from Abhay.)

Well, that's a quibble, I guess.  Still, I'll take partial credit, since I
DID use the metaphor w/r/t Telnet (independently of your use w/r/t FTP,
clearly) and the minimum implementation lists WERE in RFCs 542ff.  Besides,
1971 is certainly MUCH closer to 20 years ago than to 15, even if that only
speaks to our respective Early MiddleAged Arithmetic.

Perhaps we should call it a draw.

Whatever it was we were talking about....

Heh, heh.

Rashomoniacal cheers,
	map

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 20:51:31 GMT
From:      tundra@eskimo.chi.il.us ("Tundra" Tim Daneliuk)
To:        comp.protocols.tcp-ip
Subject:   ruptime and multiple networks

(Hope this is the right place to ask...)

I am responsible for a small IP-based network in my department.  This network
is NOT connected to the Internet, but does have NIC-assigned IP addresses.

Some of the hosts are connected to a thin-Ethernet, the others are connected
to a 4 MB/sec Token Ring a' la IBM.  The Ethernet and Token Ring each have
their own, unique Class C address space.  We are using a CISCO MGS router to
establish logical ip connectivity between the two spaces.

I've got everything working (i.e. any host can see any other host on either
the Ethernet or Token-Ring via rlogin, telnet, etc.) except for one strange
thing:  When I do an 'ruptime' I see only the hosts on the network where I
am currently logged-in.

Is this correct ruptime behaviour?  I've tried fiddling with the MGS
configuration to try and make sure UDP broadcasts are making it through the
router, but so far I can't get 'ruptime' (and for that matter 'rwho') to
see anything on the "other side" of the router.

TOPOLOGY:

Sys V.3.2 / Intel 486 / -> Ethernet
BSD 4.3 - Mach / Intel 386/ -> Ethernet
AIX/ Intel 386 (PS/2) / -> Token Ring
PC Running Wollongong Pathway Software -> Token Ring
PCs Running NCSA Telnet -> Ethernet


Comments anyone? (Probably should be mailed to me.)




------------------------------------------------------------------------------
        "Tundra" Tim Daneliuk
        PREFERRED: tundra@eskimo.chi.il.us
        OR (Yuk!): eskimo!tundra@clout.chi.il.us
        ALSO:      ...uunet!gargoyle.uchicago.edu!clout!eskimo!tundra
------------------------------------------------------------------------------

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 21:35:46 GMT
From:      young@alw.nih.gov (Jeff Young)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Protocol analyzers

Look at the Wandel and Goltermann.  Does two ethernets at a time - real-time.
Also has slots for token-ring and a promised fddi card.  919 460-3312
-- 
___________	
	jy
	young@heart.dcrt.nih.gov

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 22:05:05 GMT
From:      bstratton@hns.com (Bob Stratton)
To:        comp.protocols.tcp-ip
Subject:   What's your IP Time to Live?

Hello all,

I've just had to bump my IP Time-To-Live to compensate for some of the
recent routing changes on the Internet. 

Would any of you system administrators, especially those running
Apollo or HP workstations, let me know what you currently have your IP
Time-To-Live set to? I need to make a presentation to
management-types, and could use all of the ammo I can get.

If you're wondering where this value is set, on SR.10.3.4 of
Domain/OS, it's in file /etc/rc.local, on the line where /etc/tcpd is
started. If you see a "-t" switch, that's the value. (BTW, I jacked
mine up to "3c" hexadecimal, which seemed to cure a lot of problems.

Please respond directly to me, as I'm temporarily off of the list. All
replies are welcome.

Thanks in advance,

Bob Stratton           | 
Hughes Network Systems | SMTP: bstratton@hns.com
Germantown, Maryland   | PSTN: +1 301 409 2703
"Personally, I think the DNS administrative interface was designed by the IRS."
							--Mark Beyer

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 22:07:35 GMT
From:      sak@cdg.chalmers.se (Anders Karlsson)
To:        comp.protocols.tcp-ip
Subject:   Re: Finger server as a requirement for all Internet hosts


First rgoldstone@OAVAX.CSUCHICO.EDU writes:
  I often have users come to me and say "I want to send e-mail to my colleague
  at the University of XYZ.  Is there some way I can look up their address?"

And then Henry Spencer writes:
  The correct answer to such a question is:  "Phone him up and ask.  That
  way you can also ask whether he reads his mail regularly."  Between people
  with multiple accounts, people with very similar names (there are two
  professors named "A. Zimmerman" in our department, for example), people
  on vacation, and people who have accounts but seldom or never read their
  mail, a directory lookup service simply is not an adequate solution.

In favor for the world wide electronic directory I must argue against Henry,
and make the folowing statement instead.

  In the near future the correct answer will hopefully be: Look him up
  in "the directory" (read X.500).

This have the potential to work better. For example, if he is on
vacation he will not answer his phone. Also, in the directory there
could, possibly, be included information on how often he reads his
mail.


	-- Anders Karlsson

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 22:13:37 GMT
From:      oldera@twg.com (Ed R. Alcoff)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Protocol analyzers

Don't forget the Novell LANalyzer (originally from
Excelan?).  It's been around longer than most, I believe.

Cheers,

Ed Alcoff

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 22:22:21 GMT
From:      slimick@unix.cis.pitt.edu (John C Slimick)
To:        comp.sys.att,comp.protocols.tcp-ip
Subject:   Re: 3B2 Ethernet problems.



I had problems with the NIC and Cabletronics enet MAU
on our 3b2/400 at bootup time. It seems that the NIC
diagnostics failed every time. My solution was to
isolate the 3b2 (put 2 50 ohm terminators on the MAU
while putting a barrel connector to connect the two parts
of the enet). Then I could boot up with no difficulty.
Once up and running, I would reconnect the network and the MAU.

I'm using a Black Box MAU now, and I don't recall having
as many bootup problems.

John Slimick
slimick@unix.cis.pitt.edu

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 22:31:16 GMT
From:      stevo@elroy.jpl.nasa.gov (Steve Groom)
To:        comp.protocols.tcp-ip
Subject:   Re: Finger server as a requirement for all Internet hosts

In article <1991Aug09.165839.21578@ecst.csuchico.edu> rgoldstone@OAVAX.CSUCHICO.EDU writes:
>
>I would like to see a requirement for all Internet domains to operate a
>finger (or whois) server to serve the top-level domain at their site.
 [...]
>This
>would parallel the function of the telephone directory assistance service.

Well, in a sense this form of service already exists.  And just like
telephone directory assistance, folks can choose to be unlisted.  It's
just that in the case of the Internet, not a whole lot of folks have
chosen to be listed!  If organizations feel that this is a service
worth providing (and one that they want "outsiders" to have access to),
they will.  Mandating such a service is probably not a workable idea,
for the same reason that many companies prohibit (or limit) external
distribution of their internal telephone directories.

-steve
-- 
Steve Groom, Jet Propulsion Laboratory, Pasadena, CA
stevo@elroy.jpl.nasa.gov  {ames,usc}!elroy!stevo
"... and the babe, she needs a chaaaa--nging..." (apologies to Bob Dylan)

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 91 23:37:10 GMT
From:      coolidge@speaker.sgi.com (Don Coolidge)
To:        comp.protocols.tcp-ip
Subject:   Re: Gratuitous ARP

In article <1991Aug10.224810.6202@Think.COM> barmar@think.com writes:
>In article <1991Aug10.012720.7148@odin.corp.sgi.com> coolidge@speaker.UUCP (Don Coolidge) writes:
>>In article <236@s5000.rsvl.unisys.com> rae@s5000.rsvl.unisys.com (Rick Erickson x2132) writes:
>>>I've heard references to 'gratuitous ARP'. Can anybody explain this?
 
>>Probably when the act of configuring an interface with an IP address causes
>>the host to send out an ARP request for that address over that interface.
>>Nobody will answer, but everyone who refreshes his cache will get a guaranteed
>>up-to-date IP address to match with the meduim address.
>
>Sometimes someone *does* answer, in which case you know that there's a
>configuration problem.  When SunOS receives a reply to its unsolicited ARP,
>it reports "Duplicate IP address".  On the occasions where I've seen this,
>the problem wasn't actually that two hosts had the same IP address (most of
>our Suns get their IP addresses using RARP), but that the Sun was connected
>to the wrong subnet for its IP address; we have a cisco router that does
>proxy ARP, and it was responding to the unsolicited ARP.

Absolutely right about the duplicate IP address. That particular reply isn't 
all that rare, especially on nets with gobs of PCs. Everyone who implements
unsolicited ARPs uses that, I'm sure. However, you've raised a religious 
question by bringing up Proxy ARP...shall I dive in?...sure! :^)

Definitive Statement: It is Poor Design to use a Link Level protocol to do 
Network Level routing. You want to solve a Network Level problem, you Should
Do It at the Network level. Amen.

(Even if it is convenient...)

Not to mention that anyone silly enough to use Proxy ARP in conjunction with
default routes (as many older implementations still do, but hopefully fewer
as static routes become thankfully a thing of the past) can doom his 
application to sending packets out into the Internet to die a long and painful
TTL death, and never get a "host unreachable" reply.

- Don Coolidge
coolidge@sgi.com

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 91 01:24:27 GMT
From:      sfrazier@mcinix.vlink.COM (Steven E. Frazier)
To:        comp.protocols.tcp-ip
Subject:   ka9q

I have some questions after reading the docs with ka9q.  Could someone
email me if they have used the ka9q for use as a router?

I am interested in setting up ka9q as a router and have a few questions.

Thanks in advance


Steve


-- 
  Steven E. Frazier
 DID: (614) 761-6612
VNET:       424-6612
 FAX: (614) 761-6679

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 91 03:44:57 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Proxy ARP (was Re: Gratuitous ARP)

In article <1991Aug12.233710.23310@odin.corp.sgi.com> coolidge@speaker.UUCP (Don Coolidge) writes:
>Definitive Statement: It is Poor Design to use a Link Level protocol to do 
>Network Level routing. You want to solve a Network Level problem, you Should
>Do It at the Network level. Amen.

I agree.  The first time I saw proxy ARP result in a workstation
complaining about a duplicate IP address, my immediate response was to turn
off proxy ARP on the cisco router.  Unfortunately, this suddenly cut off
many of our Macintoshes, which were apparently running a flavor of TCP/IP
that didn't have subnet support (or maybe the subnet masks weren't
configured properly).  Rather than run around manually reconfiguring a
hundred Macs, it was simpler to re-enable proxy ARP.

>Not to mention that anyone silly enough to use Proxy ARP in conjunction with
>default routes (as many older implementations still do, but hopefully fewer
>as static routes become thankfully a thing of the past) can doom his 
>application to sending packets out into the Internet to die a long and painful
>TTL death, and never get a "host unreachable" reply.

This is just a problem with default routes, not proxy ARP.  But it's really
only a problem if all the routers are using default routes.  In real life,
you'll eventually encounter a router that doesn't have a default route, and
it will send a host unreachable back.

-- 
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 91 07:56:03 GMT
From:      imo2@cann.stuttgart-emh1.army.mil ("William Dugger at Bad Cannstatt")
To:        comp.protocols.tcp-ip
Subject:   Registration of non-NIC host user

I am not on a NIC registered host, but I am registered with the NIC.  Please
send me your listing at either my primary address which is in the NIC table
imo2@bdcnnsdt-amedd.army.mil or my alternate imo2@stuttgart-emh1.army.mil

Please subscribe me to your list:
William Daniel Dugger, System Administrator
5th General Hospital, Information Management Office
ATTN:  AEMBC-IMO
APO New York 09154-3345
DSN 4222-810 or 0711-5201-810 (Bad Cannstatt, Germany)
Electronic Mail: imo2@bdcnnsdt-amedd.army.mil
Alternative:  imo2@stuttgart-emh1.army.mil

Bill
CANN

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 91 09:33:18 GMT
From:      clu@malihh.hanse.de (Carsten Lutz)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco,comp.unix.sysv386,comp.unix.questions
Subject:   DialUp-IP and SCO-Unix ???

Hello !

We would like to install DialUp-SLIP on our host running SCO-Unix. There are
5 serial ports thie T2500-Modems available over wich we want to run 
DialIn - SLIP-Connections and DialIn/DialOut UUCP & Terminalsessions.

As I understand, the SLIP-implenentation delivered with SCO-Unix is only
for hard-wired SLIP-Connections. This is not what we want. I would like to
know if there is somewhere a package out there that allows SCO-Unix to 
managa real *DialUp* SLIP - Connections. DialIn would suffice. And it
should also allow SLIP-Connection to multiple hosts on the same line.
( At different times of course, I don't want a wonder, just SLIP. ;-)

If such a packet doesn't exist, wich one might be relatively easy to port
to SCO ?

please answer via email.

greetings,	
		Carsten


-- 
* Carsten Lutz, Rellingen, FRG / clu@malihh.hanse.de ( NeXTmail accepted ) *
*   Voice : +49 4101 207871  Fax: +49 4101 27757  Traily : +49 4101 22306  *
----------------------------------------------------------------------------
*				Why do birds sing ?			   *

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 91 14:27:58 GMT
From:      rgoldstone@OAVAX.CSUCHICO.EDU (Robin Goldstone)
To:        comp.protocols.tcp-ip
Subject:   Re: Finger server as a requirement for all Internet hosts

Well, I have seen enough followup postings and private e-mail replies to
realize that finger is apparently not a popular service for most of you.
I hadn't given much thought to the negative uses of finger: unwarranted
solicitation, junk e-mail, privacy violations... I was just thinking in
terms of providing a way for users with legitimate reasons for using
e-mail to determine someone's address.  I guess they'll just have to stick
to calling them on the phone and asking them for their address.

-Robin
***********************************************************************
Robin Goldstone, Systems Software Specialist
California State University, Chico  Computing Services
rgoldstone@oavax.csuchico.edu

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 91 14:33:47 GMT
From:      jonson@NISC.SRI.COM (1Lt Matthew W. Jonson)
To:        comp.protocols.tcp-ip
Subject:   LaTeX

I know that this isn't strictly a topic that belongs on this list,
but I wonder if someone could give me some information.  

I have run across some documentation that is in LaTeX format.  I
was wondering where I could get the latex formatting program.  Is it
public domain?  Any pointers appreciated.  I would like to put it
up on an AT&T 3B2 but there are other Unix machines available.

Thanks in advance.  Please e-mail me direct.

/matt
-- 

Lt Matthew W Jonson       jonson@server.af.mil  snail-mail:
Network Systems Engineer     205-279-4075       SSC/SSMT
USAF DDN Program Office      AV: 596-4075       Gunter AFB, AL  36114

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 91 16:45:29 GMT
From:      lac@HPLB.HPL.HP.COM (Laurence Crutcher)
To:        comp.protocols.tcp-ip
Subject:   Network Status Information


I have a requirement to obtain status information from the Unix kernel,
giving details of the network interface configuration together with 
relevant performance information. The type of information that I want is
very similar to that given by the netstat command, with appropriate options.
However, I want to get this information into a known form inside a C
program.

Can somebody tell me how netstat is implemented. Is it based on ioctl
commands, and if so which ones? Pushing my luck further, is there a site
where I can get the source code for this command?

Thanks for any help

Laurence


======================================================================
 
 Laurence Crutcher

 Hewlett Packard Laboratories         e-mail: lac@hplb.hpl.hp.com
 Filton Road                                  lac@hplb.hpl.hp.co.uk 
 Stoke Gifford                        Tel:    (0272) 799910
 Bristol BS12 6QZ                     Fax:    (0272) 790554 
 UK.

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

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 91 16:53:19 GMT
From:      art@opal.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: A new dump question

In article <9108060906.AA18619@NISC.SRI.COM> aets-kja-a-ao3@ANSBACH-EMH1.ARMY.MIL ("Thomas F. Pockberger") writes:
>Sorry but I am REALLY new to TCP/IP.
>
>here is my question:
>
>If two Internet sites establish a connection it normally goes thru a couple
>of "hops". Each of them uses one TTL count on the packets. Is there
>something like a "return receipt" from the receiving machine which also
>has TTLs and uses them.

If the connection uses TCP, the TCP data sent one way is acknowledged
by the ACK field of a packet going the opposite way.

>Sample:
>I conect to a host, some of the packet goes thrue 13 hops but most thru
>16 hops. TTL is set to 15 on our machine. So the packets with 13 hops get
>thru the 16 hops not. Can the result be something like "timed out".?

From a user perpective, this could definitly happen.  There is an ICMP
error message that is supposed to be sent back when the IP TTL goes to 0,
but that event often is not conveyed to the application affected.

>If the receiving machine is sending acknowledgement on the 13 hops packet
>can this result in a kind of "loose" connection. (connect; permission denied)

Unlikely that a permission denied error would occur in this case.

>Sorry if this is a dump question. Can somebody shine a light on me.
>
>Pocky

Hope this helps,

Art

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 91 16:58:47 GMT
From:      art@opal.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Gratuitous ARP

In article <236@s5000.rsvl.unisys.com> rae@s5000.rsvl.unisys.com (Rick Erickson x2132) writes:
>I've heard references to 'gratuitous ARP'. Can anybody explain this? My
>understanding is that hosts and routers that receive an ARP Request will
>refresh their ARP caches, but that is how ordinary ARP works, so what is
>'gratuitous ARP'? 

This probably refers to the behavior of sending an ARP request to yourself
when the interface first comes up.  This has two effects.  First it lets
everyone cache your ARP information (the gratuitous effect) and lets you
check for IP address conflicts.

>Another question is whether there are any ARP implementations that do not
>refresh their ARP cache when a broadcasted ARP Request is seen? 

I've seen some pretty limited ARP implementations out there, so I would
imagine there are some like that.

>                                         Rick Erickson

Art

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 91 18:39:53 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Gratuitous ARP

In article <1991Aug13.165847.3969@salt.acc.com>, art@opal.acc.com (Art Berggreen) writes:
> when the interface first comes up.  This has two effects.  First it lets
> everyone cache your ARP information (the gratuitous effect)...

	RFC 826 says you only add to the cache if the request is directed to
you (and so you may be talking to that host soon) or it's a reply to a request
you sent. You also update an existing entry, but in general, you don't just
add every ARP reply that comes along to your translation cache, gratuitous or
not.
	I think the two beneficial effects of gratuitous ARP are duplicate
detection and making sure out-of-date translations are updated promptly
(though this will happen with the timeout mechanism eventually, anyway).
	People adding this feature should consider the down side, as well.
What happens when a power failure causes a hundred workstations to send
extraneous ARP packets at the same time?
	I haven't read RFC 826 recently, so a conforming implementation may
be able to add unsolicited translations to its cache, but you generally want
the cache to be small, so whether it says you can or not, you probably wouldn't
want to. Especially on large networks.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 91 21:33:32 GMT
From:      pa335371@longs.LANCE.ColoState.Edu (Paul E. Andrighetti)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip,comp.protocols.ibm,comp.protocols.iso,comp.protocols.tcp-ip.ibmpc,comp.protocols.kerberos
Subject:   X.PC port to UNIX or VMS




Has anyone ever ported the protocol X.PC to UNIX or VMS?

We will be using SCO System V for one implementation.

X.PC is a asynchronous communication protocol that enables you to 
communicate errorfree and simultaneously with up to 15 separate 
destinations.  This protocol came out in the early to mid 80's and was
designed by TYMNET who is now BT North America.  BT North America has
not been any help in locating the right group(s).  

I know that it has already been ported, but can not find those
resources. 

Any help that can point me in the right direction would be greatly
appreciated.

Please respond to the below EMAIL address as soon as possible.

	EMAIL:	Paul_Andrighetti@stortek.com

If not possible just reply to this news group.

I apologize if this is the wrong group to post this message.

Thank You,

Paul E. Andrighetti
StorageTek
2270 South 88th Street
Louisville, CO 80028-2263
USA
(303) 673-3063  

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 91 06:19:04 GMT
From:      jos@bull.nl (Jos Vos)
To:        comp.protocols.tcp-ip
Subject:   Semantics of KEEPALIVE

Who can supply me the detailed semantics of the KEEPALIVE option in
4.3BSD-alike TCP/IP implementations.
What are the roles of the client and the server w.r.t. the so-called
keep-alive packets?

What I also want to know is what happens if the SO_KEEPALIVE option is set,
and what should happen if it is not set.
And what is "normal" for standard applications like telnet, rlogin etc.?
Do they have the option set or not?

Please E-MAIL responses to me. I'll summarize if that is wanted.
Thanks.

-- 
--    Jos Vos <jos@bull.nl>    (UUCP: ...!{uunet,mcsun,hp4nl}!nlbull!jos)
--    Bull Nederland NV, Product Support Unix, Amsterdam, The Netherlands

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 91 12:22:21 GMT
From:      rickert@mp.cs.niu.edu (Neil Rickert)
To:        comp.protocols.tcp-ip
Subject:   Re: Finger server as a requirement for all Internet hosts

In article <3997@chalmers.se> sak@cdg.chalmers.se (Anders Karlsson) writes:
>And then Henry Spencer writes:
>  The correct answer to such a question is:  "Phone him up and ask.  That
>  way you can also ask whether he reads his mail regularly."  Between people
 
>In favor for the world wide electronic directory I must argue against Henry,
>and make the folowing statement instead.
>
>  In the near future the correct answer will hopefully be: Look him up
>  in "the directory" (read X.500).
>
>This have the potential to work better. For example, if he is on
>vacation he will not answer his phone. Also, in the directory there

  If he doesn't answer his phone, you are very likely to notice that when
you call him.  But if he doesn't read his email, you may never know.

>could, possibly, be included information on how often he reads his
>mail.

  Sure.  Somebody who will not go to the trouble of occasionally logging in
to read his mail is going to carefully maintain his X.500 directory info
to inform people he doesn't read it.  Not likely!


-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 91 13:59:03 GMT
From:      ddj@zardoz.club.cc.cmu.edu (Doug DeJulio)
To:        comp.protocols.tcp-ip
Subject:   Re: Finger server as a requirement for all Internet hosts

In article <1991Aug14.122221.4214@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
>>This have the potential to work better. For example, if he is on
>>vacation he will not answer his phone. Also, in the directory there
>
>  If he doesn't answer his phone, you are very likely to notice that when
>you call him.  But if he doesn't read his email, you may never know.

This is untrue these days.  That's one of the reasons I really, really
hate answering machines and voice mail systems.
-- 
Doug DeJulio
ddj@zardoz.club.cc.cmu.edu (NeXT mail)
dd26+@andrew.cmu.edu (AMS/ATK mail)

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 91 14:38:24 GMT
From:      chi@SPARTA.COM (Chi Chu)
To:        comp.protocols.tcp-ip
Subject:   (none)

Subject: NREN

Hey folks,
	Can someone tell me what the NREN email address is?
Thanks.

Chi - SAIC

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 91 15:22:55 GMT
From:      jbev@iscden.jbsys.com ( J B Systems)
To:        comp.protocols.tcp-ip,comp.unix.sysv386,comp.sources.wanted
Subject:   Telnet daemon help


Net People,

I have been trying to get login to work on SCO UNIX 3.2.  I am trying
to replace the telnet daemon with a custom version.  I started with the
telnetd from the BSD source archives and am tring to get it to run on
SCO Unix before I start my hacking.  I seem to be able to get connected
to the person attempting to log into the system, but from there, the
new daemon just hangs.  If I do a ps, login is present.  If the person
who is trying to login, types anything, I receive the data.  I can
also send data back through the socket and see it displayed on his
system.  I also recognize his quit command and can disconnect from
the network. I can not, however, seem to get the user logged in, or send
or receive any data from the assigned pty.  Has anyone modified the BSD telnet
daemon to run on SYSV?  I need to know the following:

1.  How do you correctly allocate and provide the pseudo tty assignment
    information to login so login can talk to the pty's?  What is the
    proper open, dup2, and close sequences for the ptys?

2.  What is the proceedure to exec the login program and the proper
    options.  I am now using execl ("/bin/login", "login", -h, host, 0).
    Where are the options documented?  Where is the pty documented? I
    have almost worn out the pages of the manuals looking.

If some kind person could send me some code samples of how to make
login connect to the pty and the telnet daemon, I would be greatful.
Also, if someone knows of a PD telnet daemon for SYSV that would be even
better. :-)  I have ftp access.  Any help would be welcome.

Thanks in advance.

Jim Bevier
jbev@jbsys.com

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 91 19:38:47 GMT
From:      dyer@motcid.UUCP (Bill Dyer)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   DOS - UNIX communcations.


Well, seeing as I am fairly ignorant when it comes to networking,
I have several questions.   What I want to do is write 2 applications,
one for a UNIX box and one for a PC (running DOS, and no we can't run
unix on the PC for various reasons).  I would like the applications to be 
able to send messages (packets) back and forth over an ethernet link.
I assume TCP/IP would be the way to do this, but I am clueless as to 
what software I need.  I assume that most UNIX implementations have 
TCP/IP built in and I am aware of several TCP/IP packages for the PC.
Now the questions:

How hard is it to do the above?
What software do I need to accomplish this?


Any help would be greatly appreciated.

-Bill


-- 
_____________________________________________________________________________
|  I wish I could sit on soft pillows,      |Bill Dyer  (708) 632-7081      |
|  and eat molten lava.                     | dyer@motcid.rtsg.mot.com      |
|                     -King Missle          | or  uunet!motcid!dyer         |

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 91 20:24:34 GMT
From:      sak@cdg.chalmers.se (Anders Karlsson)
To:        comp.protocols.tcp-ip
Subject:   Re: Finger server as a requirement for all Internet hosts


Neil Rickert:
> If he doesn't answer his phone, you are very likely to notice that when
> you call him.  But if he doesn't read his email, you may never know.

Entierly true, but the usefullness of a directory service that let you
look up someones e-mail address is not negligible.

Further, letting the users maintain the information on whether they
read their e-mail or not, is obviously not a good idea. But gathering
that information could be done (and I have done it at our site) quite
automaticly by sending everyone a letter and simply asking them. One
other good effect of this is that it seems to be kind of an exercise
to a lot of users, thus increasing the number of people who read
their e-mail. Also if they do not answer their question that could be
usefull information as well.

	-- Anders Karlsson

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 91 21:30:18 GMT
From:      tierney@george.lbl.gov (Brian Tierney)
To:        comp.protocols.tcp-ip,ba.internet
Subject:   High Performance Network Computing job at LBL


           High Performance Network Computing and the NREN
               Lawrence Berkeley Laboratory Job Posting

     This position involves defining and exploring new directions for
effective use of the emerging high speed national network, as well as
participating in the National committees working on the design of the
NREN.  Some of the work will entail investigation and use of a wide
range of distributed computing technology, and scientific applications
based on the national deployment of high speed networking technology.


See posting in:  misc.jobs.offered,ba.jobs.offered for more information

(DO NOT respond to this email address)
 

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 91 21:59:34 GMT
From:      dgreen@sti.com (Dan R. Greening)
To:        comp.protocols.tcp-ip
Subject:   Dialin SLIP (or PPP or ?) for SunOS 4.1.1


We want to add a dial-in slip line, with these properties:

1.  Initial contact with the modem results in the normal login
    prompt.  If you login normally, you login.
2.  If you login as "slip", giving the proper password, the slip server
    starts.
3.  When carrier drops, the slip program terminates properly (and getty
    starts again).  (This may actually be the tricky part:  the slip-4.1-beta
    we use for our hard-wired slip implementation doesn't gracefully turn
    itself off.)

Is there an existing program (hopefully PD), for SunOS 4.1.1, which
does this?  It doesn't necessarily have to be slip: we have control of
both sides of the connection, and all participants are SunOS 4.1.1.

Many thanks for any information on this (we're desperate!).  We'll
even help write/test/supply the code if there's a partial
implementation somewhere.

Regards,
-- 
____
\  /Dan Greening    Software Transformation   1601 Saratoga-Sunnyvale Rd, #100
 \/dgreen@sti.com   (408) 973-8081 x313       Cupertino, CA 95014

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 01:45:15 GMT
From:      MAP@LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   Finger server as a requirement for all Internet hosts


   Date: 9 Aug 91 16:58:39 GMT
   From: csusac!cindy!OAVAX.CSUCHICO.EDU!RGOLDSTONE@ucdavis.ucdavis.edu  (Robin Goldstone)

   I would like to see ... domains ... operate a finger server ...  I
   ... have users come to me and say "I want to send e-mail to my
   colleague at the University of XYZ.  Is there some way I can look
   up their address?"

What I do in this case is send mail to Postmaster at that site and ask
them.  I usually include something along the lines, "Because your site
doesn't run a finger server, I am required to waste your time and mine
by sending this request for an address to you.  You should consider
running such a server to cut down on the amount of time you spend
answering such queries."

            __
  /|  /|  /|  \         Michael A. Patton, Network Manager
 / | / | /_|__/         MIT Laboratory for Computer Science
/  |/  |/  |atton        and Postmaster@LCS.MIT.EDU

Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)

P.S.  On the other hand, even though MIT does run such a service, it's
amazing how many people don't think to try and just send to Postmaster
anyway.  At least having the service makes it easy for me to reply.

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 02:02:42 GMT
From:      mcmillan@mizar.usc.edu (Delcina McMillan)
To:        comp.protocols.tcp-ip
Subject:   SLIP Info...

I have been seeing the word Dial-up IP and SLIP lately. I would like to know
just what that means. I have a good guess as to what it might be, but I would
rather have a real answer.
Rather than tie up this group with answers, if anyone would send me mail on
the subject, I would be greatly appreciative

-- 


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Kim C. Callis                                                                +

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 02:04:47 GMT
From:      pte900@jatz.aarnet.edu.au (Peter Elford)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Making the DNS work on System V Release 4 System

I have been trying to help a site with Intel's (?) System V Release 4 
running on a 386 to operate correctly with the DNS. The system
identifies itself at login as follows:

UNIX System V/386 Release 4.0 Version 2.0
Copyright (C) 1984, 1986, 1987, 1988, 1989, 1990 AT&T
Copyright (C) 1987, 1988 Microsoft Corp.

We had no problems running up the name server, but have been unable to
make the IP applications (ftp, telnet, ping, etc) use the DNS rather
than the /etc/hosts file. The /etc/netconfig file has had the resolver
routines added to the name-to-address mapping field:

tcp   tpi_cots_ord  v inet tcp  /dev/tcp   /usr/lib/tcpip.so,/usr/lib/resolv.so
udp   tpi_clts      v inet udp  /dev/udp   /usr/lib/tcpip.so,/usr/lib/resolv.so
rawip tpi_raw       - inet -    /dev/rawip /usr/lib/tcpip.so,/usr/lib/resolv.so
icmp  tpi_raw       - inet icmp /dev/icmp  /usr/lib/tcpip.so,/usr/lib/resolv.so

but noone of the applications are querying the DNS (this can be checked
by truning on named debugging).

We rebooted the system after changing netconfig (is this necessary?) but
this made no difference.

We changed the /etc/resolv.conf file to point to the loopback address
rather that the systems Ethernet address, and I tried running without
a resolv.conf (but didn't reboot between these changes). Aagin, no joy.

Is there some magic trick we are missing ?

PLEASE pass copies of any answers to jd@buc.edu.au (they don't have
a news feed yet) - thanks,

Peter Elford,                           	e-mail: P.Elford@aarnet.edu.au
Network Co-ordinator,	 			phone: +61 6 249 3542
Australian Academic Research Network,		fax:   +61 6 247 3425
c/o, Computer Services Centre,			pager: +61 6 245 3035
Australian National University			post:	PO Box 4     
Canberra, AUSTRALIA					Canberra 2601

ps. mail (to remote Internet destinations) and nslookup work fine ...

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 09:03:10 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   tcpdump port for snap encoded IP?


has anyone done the (small) addon to get tcpdump to pretty snap
encoded IP? if so, can we ftp it/deltas? thanks...if not, we'll doit
anyhow...setting timer event for monday for us to start it:-)

jon 

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 11:08:42 GMT
From:      rbrickey@BBN.COM (Ron Brickey)
To:        comp.protocols.tcp-ip
Subject:   Recoval

Please remove me from this mailing list.

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 14:34:16 GMT
From:      jas@proteon.com (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   Gratuitous ARP

Gratuitous ARP is where a host sends an ARP reply as a broadcast when
there was no ARP query.  It is something polite that hosts having to
change their MAC addresses do.  (Some non-IP protocols sometimes
require changing the MAC address.)  If all of the other hosts on the
LAN correctly implement ARP (not all do!), they will learn the new MAC
address for the host that sent the gratuitous ARP reply.  This is
because they are always supposed to learn from the arp$sha and arp$spa
filed on all incoming ARP packets.  (See the pseudo-code in ARP.)

If all hosts implemented ARP cache aging, Gratuitous ARP probably
would not be as necessary.  However, ARP cache aging was originally
optional.  (Now that there are things like proxy ARP, aging is more
necessary.) 

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 14:59:45 GMT
From:      bb16@prism.gatech.EDU (Scott Bostater)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Problems with PC <-> Unix on Multiport Ethernet Transceiver

We are having problems using NCSA Telnet to connect various IBM PC clones
to various unix machines.  The problem is localized to PC's and a unix host 
that are on the same Multiport transceiver.  This has been a problem for a 
Sun 386i, Sun Sparc Station, and Silicon Graphics IRIS workstations.  All of 
the PC clones are using WD 8003e ethernet cards.  The multiport transceivers
are Cabletron MT-800's (thick ethernet).

The main sympton is either inability to connect at all, or connections where
the data transfer is measured in seconds/byte :-(

We have no network monitering capability here, so I can't get a reading of how
many dropped packets we have.  I am assumming the problem is due to a massive
percentage of lost packets.  Is there any easy way to fix this?

Any help would be greatly appreciated.
-- 
Scott Bostater      Georgia Tech Research Institute - Radar Systems Analysis
"My soul finds rest in God alone; my salvation comes from Him"  -Ps 62.1
uucp:     ...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!bb16
Internet: bb16@prism.gatech.edu

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 15:03:34 GMT
From:      kurt@s5000.rsvl.unisys.com (Kurt Matthys x5693)
To:        comp.protocols.tcp-ip
Subject:   TCP FIN and window

I have recently run into a TCP question that I would like some input on. It 
concerns whether a TCP can send a FIN when the window is closed. I have seen
at least two implementations that do this, but RFC 793 would appear to say 
that it should not be done. The following is my interpretation of the issue:

On page 25 of RFC 793 it states that the segment length  is "the number of
octets occupied by the data in the segment (including SYN and FIN)".

On page 69 the table shows that if the segment length > 0 and the received 
window = 0, the received segment is not acceptable. A couple of lines later
it says that "If the RCV.WND is zero, no segments will be acceptable, but   
special allowance should be made to accept valid ACKs, URGs and RSTs".

Then it states that "if an incoming segment is unacceptable, an acknowledgment
should be sent in reply ... After sending the acknowledgment, drop the
unacceptable segment and return".

On page 70 it talks about trimming an incoming segment so that it is 
completely inside the window by "trimming off any portions that lie outside
the window (including SYN and FIN)".

From the above the FIN is included in the segment length and a TCP that
receives a FIN when the window is closed should discard it (at least this is
how I interpret it). Any comments?

Kurt Matthys
Unisys Corp.
Roseville MN

kurt@s5000.rsvl.unisys.com

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 15:06:25 GMT
From:      dcm@gram.dell.com (Dave McCracken)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: Making the DNS work on System V Release 4 System

pte900@jatz.aarnet.edu.au (Peter Elford) writes:

>I have been trying to help a site with Intel's (?) System V Release 4 
>running on a 386 to operate correctly with the DNS. The system
>identifies itself at login as follows:
 
>UNIX System V/386 Release 4.0 Version 2.0
>Copyright (C) 1984, 1986, 1987, 1988, 1989, 1990 AT&T
>Copyright (C) 1987, 1988 Microsoft Corp.
 
>We had no problems running up the name server, but have been unable to
>make the IP applications (ftp, telnet, ping, etc) use the DNS rather
>than the /etc/hosts file. The /etc/netconfig file has had the resolver
>routines added to the name-to-address mapping field:
 
>tcp   tpi_cots_ord  v inet tcp  /dev/tcp   /usr/lib/tcpip.so,/usr/lib/resolv.so
>udp   tpi_clts      v inet udp  /dev/udp   /usr/lib/tcpip.so,/usr/lib/resolv.so
>rawip tpi_raw       - inet -    /dev/rawip /usr/lib/tcpip.so,/usr/lib/resolv.so
>icmp  tpi_raw       - inet icmp /dev/icmp  /usr/lib/tcpip.so,/usr/lib/resolv.so
 
>but noone of the applications are querying the DNS (this can be checked
>by truning on named debugging).
 
>We rebooted the system after changing netconfig (is this necessary?) but
>this made no difference.
 
>We changed the /etc/resolv.conf file to point to the loopback address
>rather that the systems Ethernet address, and I tried running without
>a resolv.conf (but didn't reboot between these changes). Aagin, no joy.
 
>Is there some magic trick we are missing ?

I suspect your problem is the buggy /usr/lib/resolv.so found in the SVR4.0.2
you have.  As I recall, resolv.so refers to some symbols that are in libc.a
only and not in libc.so, so can not be resolved at dynamic load time.  You
could try to pry a fixed version out of your vendor (or buy Dell SVR4 :-)).

If you do get a working resolv.so, you might want to put resolv.so in front
of tcpip.so, unless you really need to access /etc/hosts first.  That's the
way we run internally, and ship our SVR4.

--
Dave McCracken      dcm@dell.dell.com      (512) 343-3720
Dell Computer       9505 Arboretum Blvd    Austin, TX 78759-7299

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 16:13:23 GMT
From:      YXT108@psuvm.psu.edu
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   connection between mac and vax

Hi there,

I tried to connect to VAX by using NCSA Telnet 2.3 MacTCP.  "Sometimes" the
cursor freezed during the connection and then, after a while, VAX kicked me
out automatically.  "Sometimes" my mac crushed right after above situation.
(screen freezed and no error massage)  But everytinging works well when I
tried to connect to a unix machine.  I also tried to use NCSA Telnet 2.4 and
it didn't help.  I have no idea how to fix the problem.  It looks like
something wrong with the VAX.

I am running 6.0.7 on SE/30 with Dove FastNet SE/30.  Does anyone have similar
experiences?  I'd appreciate any suggestions.  Thanks in advance.

Please reply by e-mail.

Y. C. Tan
Internet yxt108@psuvm.psu.edu
BITNET yxt108 at psuvm

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 16:18:18 GMT
From:      lcz@sat.datapoint.com (Lee Ziegenhals)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: Making the DNS work on System V Release 4 System

pte900@jatz.aarnet.edu.au (Peter Elford) writes:

>I have been trying to help a site with Intel's (?) System V Release 4 
>running on a 386 to operate correctly with the DNS...
 
>We had no problems running up the name server, but have been unable to
>make the IP applications (ftp, telnet, ping, etc) use the DNS rather
>than the /etc/hosts file. The /etc/netconfig file has had the resolver
>routines added to the name-to-address mapping field:

Peter, you have to REBUILD those utilities with the resolv library to get them
to use DNS :-(.  AT&T took the BSD versions of these utilities and ported them
almost verbatum.  They call gethostbyname() to resolve host names, but the
utilities as distrbuted are linked with the non-DNS library.  For some reason,
they did not provide a single compatibility library that uses the netconfig
entries to resolve host names.  To use the netconfig stuff, an application must
call the new SVR4 name-to-address functions.

I couldn't believe this when I found out the hard way, just like you.  I have
considered writing my own resolver library that uses the netconfig entries, and
relinking the utilities.  

Unfortunately, if you don't have a source license you're stuck.  I'd call your
vendor and complain.

If anyone has found a better solution to this problem, a post would be much
appreciated!

Lee Ziegenhals (lcz@sat.datapoint.com)

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 16:27:23 GMT
From:      u5434122@ucsvc.ucs.unimelb.edu.au
To:        comp.protocols.tcp-ip
Subject:   TALK getting stuck and not connecting.


Could anyone please explain why talk occasionally gets stuck at the
"Checking for invitation on caller's machine." message?

It only does this on attempting connection with specific hosts eg
milton.u.washington.edu, and will not connect, regardless of whether
an invitation has been issued by the other party.  

I found the source code for talk, and went through it, 
to find out what the "Checking.." message means, and it 
appears that it means that your talk is checking 
locally to see if the local talk-daemon has received an invitation from
a remote talk.  

Why then should talk get stuck whether there is an
invitation or not?  Does the problem lie in the local talk-daemon,
the remote talk-daemon, local talk, remote talk, or just some mutual
antipathy somewhere?  It was possible to talk between my host
(xvax.ucs.unimelb.edu.au) and milton last week, but now it is impossible.

I have tried both 4.3 and 4.2 talks to respond to talk-requests from milton,
but neither works now, although 4.3 did last week.

Thanks for any help,

Danny

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 17:11:38 GMT
From:      watstar@sail.uwaterloo.ca (WATSTAR at UW)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: RARP vs. BOOTP

In article <paul.682258136@aucs> paul@aucs.acadiau.ca (Paul Steele) writes:
>Which address resolution protocol is more typically used by the rest
>of the world - RARP or BOOTP?  We having been having trouble with

Rarp is a less robust system.  
 
Bootp can often work with multiple subnets (some gateways forward
BOOTP packets).  Also BOOTP can supply much more information such
as local gateways, name servers, etc. 

Of the two, BOOTP is preferred.  

Just for your information, BOOTP does not meet all the needs of the internet,
it does not give all the required information, such as the domain name, its
gateway information is not complete, and there are other deficiencies.
A working group is preparing a proposal for a successor to it, but the
current BOOTP is still far superior to RARP.

Erick Engelke
 

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 17:20:14 GMT
From:      watstar@sail.uwaterloo.ca (WATSTAR at UW)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: DOS - UNIX communcations.

In article <7102@graphite8.UUCP> dyer@motcid.UUCP (Bill Dyer) writes:
>
>I have several questions.   What I want to do is write 2 applications,
>one for a UNIX box and one for a PC (running DOS, and no we can't run
>unix on the PC for various reasons).  I would like the applications to be 
>able to send messages (packets) back and forth over an ethernet link.

For building pc based TCP/IP clients, take a look at the Waterloo TCP
collection available via anonymous ftp to sunee.uwaterloo.ca  in
pub/wattcp/src.zip  

You can use functions roughly similar to BSD type sockets.  There are
some sample applications (Finger for tcp, cookie for udp) and a complete 
programmers guide and reference manual is available to simplify your
task. 


Erick Engelke
Network Systems Manager  
Faculty of Engineering
University of Waterloo

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 18:22:31 GMT
From:      emv@msen.com (Ed Vielmetti)
To:        comp.protocols.tcp-ip,comp.protocols.ppp,alt.sys.sun
Subject:   Re: Dialin SLIP (or PPP or ?) for SunOS 4.1.1


First note: there's a PPP newsgroup (comp.protocols.ppp) worth reading
for questions like this.

I'd look at the BBN dialup-ip code as an example of a configuration
setup, I believe that it can be configured as you expect.  

In article <1991Aug14.215934.603@sti.com> dgreen@sti.com (Dan R. Greening) writes:

   We want to add a dial-in slip line, with these properties:

   1.  Initial contact with the modem results in the normal login
       prompt.  If you login normally, you login.
   2.  If you login as "slip", giving the proper password, the slip server
       starts.
   3.  When carrier drops, the slip program terminates properly (and
       getty starts again).  (This may actually be the tricky part:
       the slip-4.1-beta we use for our hard-wired slip implementation
       doesn't gracefully turn itself off.)
   ____
   \  /Dan Greening    Software Transformation 1601 Saratoga-Sunnyvale Rd, #100
    \/dgreen@sti.com   (408) 973-8081 x313     Cupertino, CA 95014

--
Newsgroups: msen.archives.vrfy
Archive-name: dialupip
Archive-directory: bbn.com:/pub/dialup*
Subject: vrfy dialupip
Date: Thu, 15 Aug 1991 18:20:09 GMT

bbn.com
-rw-r--r--  1 ftp      ftp        197321 Jan 14  1991 /pub/dialup2.0.tar.Z
found dialupip ok
bbn.com:/pub/dialup*

-- 
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
       MSEN, Inc. 628 Brooks Ann Arbor MI 48103 +1 313 741 1120
 for information on MSEN products and services contact info@msen.com

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 19:19:44 GMT
From:      fsimmons@ub.d.umn.edu (Frank Simmons)
To:        comp.protocols.tcp-ip
Subject:   telnet

To whom it may concern:

I am running Campus Wide Information System and I would like to provide
telnet service to off-campus sources of information. As I understand it,
telnet accepts commands from tty only. I would like to be able to have telnet
accept its commands from a file until the file is exhausted and then return
control back to tty for further action. Has anyone done this and if so, would
you be willing to share it with me?

Frank Simmons

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 19:30:12 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Gratuitous ARP

In article <62274@fuquad.westford.ccur.com>, simon@fuquad.westford.ccur.com (Simon Rosenthal) writes:
> 
> Well, they do occasionally (even in the most carefully managed networks !). 
> Concurrent has a "DUPLICATE IP ADDRESS !!!" message logged and printed out
> on the system console, along with the MAC address that generated the ARP
> reply, so that the system/network manager can resolve the conflict. 


Even better is for the system that thinks it's MAC address has been stolen
also to broadcast its own IP address in a "gratuituous ARP" back at the
perpetrator.

With suitable timers (~15 sec) to avoid swamping the ether with the
arguing, this allows the network connections of both hosts to stagger along
well enough for you to get thru to fix remote host tables or whatever.  Try
it on a pair of IRIS's.  (There is a bug in 3.3 which causes the victim
to never stop complaining.)

The code is obvious and trivial to (reverse-)engineer into arptimer()
and in_arpinput() in netinet/if_ether.c in 4.3BSD style network code.
IMinsufficientlyHO, it's a neat idea.


Vernon Schryver,   vjs@sgi.com

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 20:36:45 GMT
From:      stevea@i88.isc.com (Steve Alexander)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: Making the DNS work on System V Release 4 System

I have seen two methods for this.  In earlier versions of 5.4, there
were two socket libraries, libsocket.so and libsockdns.so, and if you
replaced libsocket with the DNS version, things worked OK.

In 5.4 Version 3.0, gethostby* use the netdir routines as you would expect,
and the order of /usr/lib/resolv.so and /usr/lib/tcpip.so control which 
gets searched first.  This is, of course, the preferred approach.

-- 
Steve Alexander, Software Technologies Group    | stevea@i88.isc.com
INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 21:12:49 GMT
From:      jim@lsuc.on.ca (Jim Mercer)
To:        bit.listserv.ibmtcp-l,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,bit.listserv.ibm-main,bit.listserv.ibm-nets
Subject:   telnet and AS400/NCSA/CUTCP/Packetdrivers/AT&T etc

[ forgive the wide posting, but i figured i'd hit what i thought was the
  appropriate groups without too much overlap ]

we have:

IBM AS/400 Midrange with IBM TCP/IP 2.0 in the IBM Ethernet Adapter
AT&T 3b2/500 with Wollongong TCP/IP 3.2 and the AT&T 10base5 card
PC/AT's attached to Novell servers using packet drivers/NCSA/CUTCP to achieve
    TCP/IP connectivity to the AS400 and 3b2's

this works:

smtp between 3b2, as400 and ka9q router
ftp between 3b2, as400, ka9q router and PC's with NCSA telnet/ftp server
telnet between NCSA and 3b2.
telnet from as400 to 3b2 (line mode only)

this don't work:

telnet from 3b2 to as400
telnet from PC's to as400 (NCSA telnet, CUTCP telnet, CUTCP TN3270)

does anyone out there have telnet working INTO an as400?

has anyone heard of a tn5250 for unix and/or PC's ?

thanx


-- 
[ Jim Mercer  jim@lsuc.On.Ca  || ...!uunet!attcan!lsuc!jim    +1 416 947-5258 ]
[ Educational Systems Manager - Law Society of Upper Canada, Toronto, CANADA  ]
[ Standards are great. They give non-conformists something to not conform to. ]
[      The opinions expressed here may or may not be those of my employer     ]

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 22:37:52 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Gratuitous ARP

In article <16086@mentor.cc.purdue.edu>, dls@mentor.cc.purdue.edu (David L Stevens) writes:
>  ...
> 	People adding this feature should consider the down side, as well.
> What happens when a power failure causes a hundred workstations to send
> extraneous ARP packets at the same time?


Is this still a problem?
Given ethernet "deferals" (not collisions), what bad thing happens today
should 100 stations each decide to transmit a 60byte packet in the same
millisecond?  Today, when "low end" engineering workstations can and do
transmit or receive as fast as the ether will go?  Also given that no one
in their right mind puts more than a dozen machines on one ethernet
segment?

This is not 1983, when 100KByte/sec was a respectible number.


Vernon Schryver,   vjs@sgi.com

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 23:03:21 GMT
From:      mjhammel@Kepler.dell.com (Michael J. Hammel)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: Making the DNS work on System V Release 4 System

In article <1991Aug15.020447.22138@newshost.anu.edu.au>,
pte900@jatz.aarnet.edu.au (Peter Elford) writes:
> I have been trying to help a site with Intel's (?) System V Release 4 
> running on a 386 to operate correctly with the DNS. The system
> identifies itself at login as follows:

[stuff deleted]

> We had no problems running up the name server, but have been unable to
> make the IP applications (ftp, telnet, ping, etc) use the DNS rather
> than the /etc/hosts file. The /etc/netconfig file has had the resolver
> routines added to the name-to-address mapping field:

[stuff deleted]
 
> We changed the /etc/resolv.conf file to point to the loopback address
> rather that the systems Ethernet address, and I tried running without
> a resolv.conf (but didn't reboot between these changes). Aagin, no joy.
> 
> Is there some magic trick we are missing ?

You might try making sure the /etc/resolv.conf is a link to
/etc/inet/resolv.conf.  The actual file was moved under /etc/inet in V4,
but many applications still look for /etc/resolv.conf.  Don't know why,
but that seemed to work for most of my needs.

I noticed at one point that these were independent files.  So editing
one did not change the other and thus you got varied results with
different applications.

Hope this helps.

Michael J. Hammel        | mjhammel@{Kepler|socrates|feynman}.dell.com
Dell Computer Corp.      | {73377.3467|76424.3024}@compuserve.com
#include <disclaim/std>  | zzham@ttuvm1.bitnet 
"Jesus Saves!  But Gretzky gets the rebound!  He shoots!  HE SCORES!"

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 91 23:08:14 GMT
From:      mcb@compaq.com (Michael Busby)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: Making the DNS work on System V Release 4 System

lcz@sat.datapoint.com (Lee Ziegenhals) writes:

>pte900@jatz.aarnet.edu.au (Peter Elford) writes:
 
>>I have been trying to help a site with Intel's (?) System V Release 4 
>>running on a 386 to operate correctly with the DNS...
 
>>We had no problems running up the name server, but have been unable to
>>make the IP applications (ftp, telnet, ping, etc) use the DNS rather
>>than the /etc/hosts file. The /etc/netconfig file has had the resolver
>>routines added to the name-to-address mapping field:
 
>Peter, you have to REBUILD those utilities with the resolv library to get them
>to use DNS :-(.  AT&T took the BSD versions of these utilities and ported them
>almost verbatum.  They call gethostbyname() to resolve host names, but the
>utilities as distrbuted are linked with the non-DNS library.  For some reason,
>they did not provide a single compatibility library that uses the netconfig
>entries to resolve host names.  To use the netconfig stuff, an application must
>call the new SVR4 name-to-address functions.
 
>I couldn't believe this when I found out the hard way, just like you.  I have
>considered writing my own resolver library that uses the netconfig entries, and
>relinking the utilities.  
 
>Unfortunately, if you don't have a source license you're stuck.  I'd call your
>vendor and complain.
 
>If anyone has found a better solution to this problem, a post would be much
>appreciated!
 
>Lee Ziegenhals (lcz@sat.datapoint.com)

System V.4 release 3 does not have this problem.  The internet commands are
linked with libnsl.  Yes, release 2 does seem to need the commands
recompiled with libresolv.


Michael C. Busby - Systems Engineer
----------------------------------------------------------------------
Compaq Computer Corporation        |  Internet: mcb@compaq.com        
P.O. Box 692000 m/s 050701         |  Uunet:    uunet!cpqhou!michaelb 
Houston, Texas 77269-2000          |  Phone:    713-374-5638          
----------------------------------------------------------------------
All views and opinions expressed are my own and do not represent the
views and opinions of Compaq Computer Corporation.

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 91 05:27:30 GMT
From:      pte900@jatz.aarnet.edu.au (Peter Elford)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: Making the DNS work on System V Release 4 System

In article <1991Aug15.203645.23468@i88.isc.com>, stevea@i88.isc.com (Steve Alexander) writes:
|> I have seen two methods for this.  In earlier versions of 5.4, there
|> were two socket libraries, libsocket.so and libsockdns.so, and if you
|> replaced libsocket with the DNS version, things worked OK.

Someone who had set up UTS (Fujitsu's System V release 4 for IBM 370
compatible mainframes) suggested this - but I could not find the dns
socket library.

|> In 5.4 Version 3.0, gethostby* use the netdir routines as you would expect,
|> and the order of /usr/lib/resolv.so and /usr/lib/tcpip.so control which 
|> gets searched first.  This is, of course, the preferred approach.

Yep - this seem to be the way to go - version 3.0 it will have to be!

Thanks to all the others that responded!

Peter Elford,                           	e-mail: P.Elford@aarnet.edu.au
Network Co-ordinator,	 			phone: +61 6 249 3542
Australian Academic Research Network,		fax:   +61 6 247 3425
c/o, Computer Services Centre,			pager: +61 6 245 3035
Australian National University			post:	PO Box 4     
Canberra, AUSTRALIA					Canberra 2601

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 91 16:58:36 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window

In article <240@s5000.rsvl.unisys.com> kurt@s5000.rsvl.unisys.com (Kurt Matthys x5693) writes:
>I have recently run into a TCP question that I would like some input on. It 
>concerns whether a TCP can send a FIN when the window is closed. I have seen
>at least two implementations that do this, but RFC 793 would appear to say 
>that it should not be done. The following is my interpretation of the issue:

As you have noted, the RFC does indicate that a lone FIN at the edge of a
zero window is thrown away.  What this means is that you should be prepared
to interoperate with implementations that do follow the spec literally,
whether or not you decide to do so yourself.

As to the question of whether you should send these things, or act on them
when you receive them, hey, be a little brave.  The RFC is not error-free.

Consider the test it describes for acceptability of a nonzero length
segment when the window is open:
	 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
      or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
which, if you believed it, would require that you throw away a segment
that overlaps the window on both ends:

        SEG.SEQ                                  SEG.SEQ+SEG.LEN
           |--------------------------------------------|
		       |                         |
		    RCV.NXT               RCV.NXT+RCV.WND

whereas the reasonable thing to do, is to trim both ends and accept the data.

Getting back to the FIN-at-edge-of-zero-window question, the RFC's
position is probably the result of its authors not recognizing that it
is a special case.  The reasonable thing to do is to go ahead and send the
FINs, and to accept them.  In fact, you could argue that it is necessary,
because it is entirely acceptable for a TCP to never advertise a nonzero
window if it does not expect to receive data (eg. the unused second half
of a half-duplex connection), and following the RFC too closely in this
case would make it impossible to cleanly close the connection.  
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 91 18:20:25 GMT
From:      clayh+@MUDLHEAD.NETWORK.COM (Clayton Haapala)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: Making the DNS work on System V Release 4 System

This won't apply unless the TCP on the system is Wollongong-derived, such as
I've seen on ATT 3B2s and NCR Towers (some of them, anyway), but in these
cases, there is an environment variable called NONAMESERVER that gets set by
default to "true" or "yes" or something to turn the DNS function off.  I've
spent some time getting all the config files right and got named running, but
still couldn't get lookup to work right until that variable got changed.

Again, I've never seen the V.4 TCP.
-- 
Clayton Haapala	(clayh@mudlhead.network.com)	
Network Systems Corp. MS10		"Ahead iWarp factor two, Ensign."
7625 Boone Ave N			"Aye, Aye, Captain."
Minneapolis, MN 55428-1099

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 91 18:30:50 GMT
From:      mike@atc.SP.Unisys.COM (Mike Grenier)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: Making the DNS work on System V Release 4 System

From article <lcz.682273098@dptspd>, by lcz@sat.datapoint.com (Lee Ziegenhals):
> pte900@jatz.aarnet.edu.au (Peter Elford) writes:
> 
>>I have been trying to help a site with Intel's (?) System V Release 4 
>>We had no problems running up the name server, but have been unable to
>>make the IP applications (ftp, telnet, ping, etc) use the DNS rather
>>than the /etc/hosts file. The /etc/netconfig file has had the resolver
>>routines added to the name-to-address mapping field:
> 
> Peter, you have to REBUILD those utilities with the resolv library to get them
> to use DNS :-(.  AT&T took the BSD versions of these utilities and ported them
> almost verbatum.  They call gethostbyname() to resolve host names, but the
> utilities as distrbuted are linked with the non-DNS library.  For some reason,
> they did not provide a single compatibility library that uses the netconfig
> entries to resolve host names.  To use the netconfig stuff, an application must
> call the new SVR4 name-to-address functions.
> 

I don't believe thats true. Simply move /usr/lib/libsocket.so to
somewhere safe and then move /usr/lib/socketdns.so to
/usr/lib/socket.so. This will allow the already compiled utilities to
use the DNS routines.

The only problem with this is that you need to check the startup
script in /etc/inet/rc.inet. Note that the use of uname -n tells
ifconfig to look up the internet address of your box.  Of course, if
ifconfig is not set up yet -- it can't ask the name server for that
information. I just hardcoded the internet address into
/etc/inet/rc.inet.

       -Mike Grenier
        mike@sp.unisys.com


*** rc.inet	Thu Aug  8 12:15:59 1991
--- rc.inet.orig	Thu Aug  8 12:10:57 1991
***************
*** 14,21 ****
  
  # Default (single interface, not a gateway)
  EMDMAJOR=0
! #/usr/sbin/ifconfig emd${EMDMAJOR} `uname -n` up -trailers
! /usr/sbin/ifconfig emd0 129.218.59.165 netmask 255.255.255.0 broadcast 129.218.59.255
  if [ $? -ne 0 ]
  then
  	exitcode=1
--- 14,20 ----
  
  # Default (single interface, not a gateway)
  EMDMAJOR=0
! /usr/sbin/ifconfig emd${EMDMAJOR} `uname -n` up -trailers
  if [ $? -ne 0 ]
  then
  	exitcode=1

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 91 19:05:41 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window

In article <1991Aug16.125836.1187@jarvis.csri.toronto.edu> thomson@hub.toronto.edu (Brian Thomson) writes:
>Consider the test it describes for acceptability of a nonzero length
>segment when the window is open...
>which, if you believed it, would require that you throw away a segment
>that overlaps the window on both ends...
>whereas the reasonable thing to do, is to trim both ends and accept the data.

This is the reasonable thing to do under the "be liberal in what you
accept" rule, but notice that the transmitting TCP has violated the
"be conservative in what you send" rule by transmitting data which
doesn't fit into the window.  Given that the receiving TCP didn't
shrink the window, one might actually consider this a protocol
violation on the part of the transmitter.

>Getting back to the FIN-at-edge-of-zero-window question, the RFC's
>position is probably the result of its authors not recognizing that it
>is a special case.

But it *isn't* a special case.  Typically, the window is closed
because the data is tied up.  In that case, the FIN *can't* be
accepted for exactly the same reason more data can't be accepted: the
previously accepted data has not been processed yet.

>The reasonable thing to do is to go ahead and send the
>FINs, and to accept them.

It's perfectly reasonable to send the FIN if it's the next thing in
the transmission buffer.  In fact, it's required that closed windows
be probed, and if the FIN's the only thing in the transmit queue, it's
what has to be used to probe.

I don't have any problem with a particular implementation accepting a
FIN to a zero window, either, if it wants.  After all, from the
protocol's point of view that could be viewed as TCP suddenly finding
an additional byte of buffer space.  But i do not think it's a good
idea for applications to be written to assume that a FIN sent to a
closed window will be accepted, nor do i think a TCP which advertises
a zero window should expect timely delivery of a FIN, since rfc793
recommends a two minute probe time for closed windows.

>In fact, you could argue that it is necessary,
>because it is entirely acceptable for a TCP to never advertise a nonzero
>window if it does not expect to receive data (eg. the unused second half
>of a half-duplex connection), and following the RFC too closely in this
>case would make it impossible to cleanly close the connection.  

But it *is* expecting data: it's expecting the FIN.  The FIN is *part*
of the data stream.  If the application requires a graceful close, i
don't understand why the TCP wouldn't advertising window space for the
FIN.
						don provan
						donp@novell.com

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 91 21:24:42 GMT
From:      geof@aurora.com (Geoffrey H. Cooper)
To:        comp.protocols.tcp-ip
Subject:   Re: Semantics of KEEPALIVE

In article <1122@nlbull.bull.nl> jos@bull.nl (Jos Vos) writes:
>Who can supply me the detailed semantics of the KEEPALIVE option in
>4.3BSD-alike TCP/IP implementations.
>What are the roles of the client and the server w.r.t. the so-called
>keep-alive packets?

Consider the case of a TCP connection that is quiescent: all data
transmitted by each side has been ACK'd by the other side.

In this case the TCP spec does not mandate any reason to send a packet
over the connection.  If the underlying communications path is
obstructed, or if one peer crashes, this fact can only be known when
one of the two sides of the connection finally decides to send some
data.

Concept: If I use a telnet remote login to connect to a computer,
and leave it idle overnight, the fact that some gateway has gone down
for an hour during the night is of no consequence to me.  Further, I
would rather not use bandwidth when I'm not there, since this might cost
someone money per packet (on some media).  If I need to know if the
other host is there, I can send some telnet data, such as the AYT (are
you there) signal.

Problem: This characteristic of TCP places a burden on higher level
protocols.  There are some HL protocols (e.g., SMTP) that have "crux"
points where they are prohibited from sending any data.  This makes
them sensitive to a severed TCP connection during these times.  These
protocols might be considered buggy, but they are, nonetheless,
pervasive. 

Berkeley Solution: If SO_KEEPALIVE is present, a quiescent TCP will
periodically retransmit the last byte of data that was transmitted to
the other side, and set a timer.  This packet must be interpreted by
the receiver as a retransmission due to a missing ACK, so the receiver
can be expected to retransmit the ACK.  If the sender's timer goes off
before the ACK is received, the connection is reset (actually,
the original packet is retransmitted several times before the
connection is reset).

The effect of this is to have TCP periodically probe an otherwise
quiescent connection.  If the connection becomes untenable, a
deficient higher level protocol is rescued when TCP informs it that
its underlying connection has gone away.

Example:

TCP PEER A			TCP PEER B
------------			---------------
SN 100, ACK 300			SN 300, ACK 100
<idle>				<idle>
SEND(SN 100, ACK 299) ----------> <oh, he missed the ack for 300, so...>
OK <----------------------------SEND(SN 300, ACK 100)

[should that be ACK 301? Never remember these things...]

I have seen some very strange packets transmitted as keepalives in the
rare circumstance where a connection is opened but no data is sent.

- Geof
-- 
geof@aurora.com / aurora!geof@decwrl.dec.com / geof%aurora.com@decwrl.dec.com

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 91 15:55:59 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window


	Someone recently asked me a similar question, put this way:

	If there were one byte in the window and you had one byte of data
and the FIN, do you send the packet with just the data, or with the data and
the FIN.

	I don't have the mail laying around, but the question is so similar
that I suspect it may be the same source, but the wording posted here makes
it sound like you're sending an extra FIN-only bearing packet.
	You could say that question is included in this one, but I think there
is a distinction in sending another packet and, somewhat artificially,
stripping the FIN on a packet you're sending anyway.

	I think the reasonable thing to do is:

Receiver side:

	1) Process the FIN, if it's there. I.e., don't let window checks force
		a retransmission for something that doesn't take buffer space!

Sender side:

	1) Include the FIN if it'll fit in a packet you're already sending.

	2) If you're not already sending it, put it in a probe for more window.

	The person that I was talking to suggested that my implementation was
wrong because I do #1 on the sender side.. I think that's too dogmatic, myself.
I think that's what thompson@hub.toronto.edu (Brian Thompson) was getting at.

donp@novell.com (don provan) writes:

>But it *isn't* a special case.  Typically, the window is closed
>because the data is tied up.  In that case, the FIN *can't* be
>accepted for exactly the same reason more data can't be accepted: the
>previously accepted data has not been processed yet.

and

>But it *is* expecting data: it's expecting the FIN.  The FIN is *part*
>of the data stream.  If the application requires a graceful close, i
>don't understand why the TCP wouldn't advertising window space for the
>FIN.

	But it is a special case, as illuminated above. If you have exactly
4K of buffer space, you can't advertise 4K+1, because it'll force you to drop
the last byte of data (you can't tell a priori it'd be a FIN) during normal
flow and force a retransmit for that 1 byte, but you *can* accepted 4K of
data and the FIN. The FIN is special, because it doesn't require any extra
space in either the packet or the receive buffers. Similarly for the SYN, if
your TCP and its user interface allows you to send data along with the SYN.
For that reason, if you treat it exactly like data in MSS checks or window
checks, you'll force an extra packet that carries only the FIN-- a waste of
network bandwidth and the application's time, if the receiver is overly
dogmatic about windows.

	Also, I thought I'd point out, since it's a pet peeve [:-)], the probe
time should be the same as the retransmission time, with exponential backoff,
and not 2 minutes (!). Berkeley uses a minimum of 5 seconds (as much as a
1000 times too large on an Ethernet), which makes for pretty poor performance
if you do drop a probe. Maybe they'll fix it in 4.4. :-)
	If you have an implementation that uses 2 minutes for a probe time,
or anything more than the smoothed rtt, you should complain to the vendor,
because dropped packets will give you unnecessary and noticeable delays.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 91 18:26:14 GMT
From:      kenny@dit.lth.se (Kenny Ranerup)
To:        alt.sys.sun,comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Diskless Sun 3/50 as X-terminal over SLIP/PPP. How to boot?

We have a number of diskless 3/50s that we would like to run as
X-terminals. The only connection to the 3/50 would be a modem
connected to the serial port. PPP or SLIP would be used to communicate
over this serial line.

Now the problem is how to boot the 3/50 over the serial line so that
it can run a X-server and SLIP/PPP software.

The boot-prom on the 3/50 only supports booting from SCSI-disk or from
ethernet using TFTP. (as far as I know)

The solutions that I can see are
 1. Hack a new boot-prom with possibility to boot via serial port.
     (Can you get source code for existing proms?).
 2. Buy a cheap SCSI-disk large enough for Xkernel & SLIP/PPP.


So, is there anyone out there who has done something like this or have
some ideas how to approach this?

+------------------------------------+----------------------------+
| Kenny Ranerup,                     |  Phone: +46 46 104940      |
| Dept. of Computer Engineering      |  Email: kenny@dit.lth.se   |
| Lund University                    |                            |
| P.O. Box 118, S-221 00, Sweden     |                            |
+------------------------------------+----------------------------+

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 91 19:43:25 GMT
From:      vern@zebra.UUCP (Vernon C. Hoxie)
To:        comp.sys.3b1,comp.protocols.tcp-ip
Subject:   Printing out 'ipctut' from osu archive


I recently downloaded a file from the AT&T-7300/3B1 archive at osu-cis
which is called 'ipctut'.  It is a tutorial originally issued by the
Regents of the University of California.  It contains no programming
code but does have a Makefile to be used in printing out the document.

In the Makefile, 'ditroff' is called using the 'me' macros and appears
to require a preprocessor filter called 'grn'.

Since all of these are foreign to my SYSV type machine, can anyone give
me suggestions about how to get a printout.

	Is there an 'nroff' version available?

	What is 'grn' and is it available for SYSV machines?

	Does 'ditroff' differ appreciably from 'nroff'?

	Will 'me' macros "borrowed" from a BSD machine
	work with 'nroff'?

Thanks to all!!

vern
-- 
Vernon C. Hoxie                            {ncar,boulder}!scicom!zebra!vern
3975 W. 29th Ave.                                       voice: 303-477-1780
Denver, Colo., 80212                          TB+        uucp: 303-455-2670

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 91 21:54:50 GMT
From:      brendan@cs.widener.edu (Brendan Kehoe)
To:        comp.protocols.tcp-ip,comp.windows.x
Subject:   X11R5 Release -- Net Lag?

I was just thinking ... what kind of an effect do you think the
announced X11R5 release on September 5 will have on the overall
performance of the Internet?  (Or 6th, or...)  Mike Schwartz's recent
experiments in Internet connectivity have made me wonder what kind of
load will be on the different networks during early and mid
September--anybody gonna have meters running, to see how things flow?
It'd make for a pretty good experiment, though it's probably too late
by now to start anything sizeable.
-- 
     Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu
  Widener University in Chester, PA                A Bloody Sun-Dec War Zone
  "And clever rogues with far less valid cause, have trapped their victims
                       in a web of laws." --- Moliere

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 91 22:46:57 GMT
From:      coates@UC780.UMD.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: X11R5 Release -- Net Lag?

Would briefly explain X11R5?
Thanks.
---
coates@uc780.umd.edu

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 91 22:49:12 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        alt.sys.sun,comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: Diskless Sun 3/50 as X-terminal over SLIP/PPP. How to boot?

In article <1991Aug17.182614.23792@lth.se> kenny@dit.lth.se (Kenny Ranerup) writes:
> 1. Hack a new boot-prom with possibility to boot via serial port.
>     (Can you get source code for existing proms?).

Much (all?) of the PROM source was included with Sun educational-institution
source distributions at one time.  (Maybe it still is, but we haven't kept
up with the 4.n follies.)

However, be warned that the hardware is undocumented -- well, actually,
some documentation does exist, but you can't get it -- and some aspects of
the boot process are subtle.
-- 
Any program that calls itself an OS     | Henry Spencer @ U of Toronto Zoology
(e.g. "MSDOS") isn't one. -Geoff Collyer|  henry@zoo.toronto.edu  utzoo!henry

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 91 00:48:05 GMT
From:      jg@crl.dec.com (Jim Gettys)
To:        comp.protocols.tcp-ip
Subject:   Re: X11R5 Release -- Net Lag?

In article <kar6paINNhf8@cs.widener.edu> brendan@cs.widener.edu (Brendan Kehoe) writes:
>I was just thinking ... what kind of an effect do you think the
>announced X11R5 release on September 5 will have on the overall
>performance of the Internet?  (Or 6th, or...)  Mike Schwartz's recent
>experiments in Internet connectivity have made me wonder what kind of
>load will be on the different networks during early and mid
>September--anybody gonna have meters running, to see how things flow?
>It'd make for a pretty good experiment, though it's probably too late
>by now to start anything sizeable.
>-- 

Probably alot, but not for very long, is my guess; and folks are way 
ahead of you.  The IETF was informed of the date of the distribution 
becoming available.  I believe the folks who run the internet will 
be watching carefully, and everyone is supposed to make the distribution 
available at the same moment.

This should be an interesting experiment.  At least two of the ftp
sites (crl.dec.com and gatekeeper.dec.com) plan to have 25 MIP machines
with tons of memory which will have the entire distribution in main memory 
and which are directly connected to the regional networks by 10megabit 
connections (NEARnet and BARRnet).  In previous releases, the fact that so 
many people try to ftp at once meant that bandwidths were reduced to that 
of disk drives being driven into random seek patterns (if 50 people are 
ftp'ing at once, and your memory cache is less than the size of the 
distribution, you're generally having to go to disk to get data), and
the machines we had as ftp sites were pretty wimpy.  Last time here at
CRL, we had lots of hassles, needing to add more swap space to our ftp machine
(a poor Microvax II, of all things), build a new kernel with lots of 
processes, etc, given the load.  This time we intend to be prepared!

No such bottlenecks should happen this time; we should be about to send 
out around a distribution every minute or so from our site.  Given the
number of ftp sites (many more than for R4 (around 30) and much better
distributed (on 3 or 4 continents), given the experience we all had with it), 
and the number of minutes in a day, I expect a large, but short, transient.

If memory serves, in R4 we were amused to watch four different hosts inside
of Sun Microsystems simultaneously FTP'ing distributions from two different
Digital servers; this is particularly ironic, since Consortium members 
already had the bits sent to them.

But the internet in the U.S. is now really quite high bandwidth (T3), so
I suspect it will survive ok; it should still be an observable blip
in the statistics, I'll bet.  What happens in Europe, England, Australia,
and Japan, is less clear, given the lower speed links in those parts of
the world.

Should be fun.  Looking forward to it... :-).
				- Jim Gettys
				  Digital Equipment Corporation
				  Cambridge Research Lab.
-- 
Digital Equipment Corporation
Cambridge Research Laboratory

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 91 06:41:34 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   ruptime and multiple networks

You desparately *don't* want UDP broadcasts to make it through a
router, unless they're a directed broadcast for another network.
Imagine the amount of bandwidth consumed if you broadcast a message
across the entire Internet.

ruptime's behaviour is correct; IP broadcasts are limited to a single
network.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice: 617 942-0915

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 91 06:52:24 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Proxy ARP (was Re: Gratuitous ARP)

I generally complain that proxy ARP is evil, as well, but I think
there are two different situations that should be distinguished.

The first is when you have a device like the old Kinetics box which
allows a few hosts on one network to appear to be on another network -
and this is the *only* IP connectivity the original network has. For
instance, you've got some Macs on a localtalk network, and a K-box
connecting them to an ethernet. The Mac's can use IP addresses that
belong on the ethernet, and the K-box can proxy ARP for them and pass
the packets on through. Almost like an IP-level bridge. In this
scenario, the only thing that you're doing with proxy-ARP is hiding
the fact that some hosts are really on the network next door.

The second is where you're using proxy ARP to compensate for the fact
that you have hosts that don't really know how to route packets (don't
understand subnet masks), and further, as a general routing facility.

I think the former is alright, when strictly adhered to, and I've
found that the latter leads you into all sorts of wonderful twilight
zone scenarios of routing loops and packets wandering off to distant
galaxies, never to be seen again.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice: 617 942-0915

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 91 08:23:14 GMT
From:      bill@unixland.natick.ma.us (Bill Heiser)
To:        comp.protocols.tcp-ip
Subject:   Re: X11R5 Release -- Net Lag?

brendan@cs.widener.edu (Brendan Kehoe) writes:

>I was just thinking ... what kind of an effect do you think the
>announced X11R5 release on September 5 will have on the overall

Anyone have "Release Notes" for the X11R5 release?

-- 
bill@unixland.natick.ma.us   ...!uunet!{think,world}!unixland!bill
Dial:  508-655-3848(2400)  508-651-8723(96-HST)  508-651-8733(PEP-V32)
Shell Accounts for USENET (1,491 groups) and E-mail are Still Available!

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 91 11:27:22 GMT
From:      beyo@beyonet.UUCP (Steve Urich)
To:        comp.sys.3b1,comp.protocols.tcp-ip
Subject:   Re: Printing out 'ipctut' from osu archive

In article <260@zebra.UUCP> vern@zebra.UUCP (Vernon C. Hoxie) writes:
>
->I recently downloaded a file from the AT&T-7300/3B1 archive at osu-cis
->which is called 'ipctut'.  It is a tutorial originally issued by the
->Regents of the University of California.  It contains no programming
->code but does have a Makefile to be used in printing out the document.

	<*> I got this file also and had the same problem. I hacked it
	to nroff but it didn't look pretty. 

	Anyone willing to reformat the file to nroff?

>vern
>-- 

							Steve Urich
							WB3FTP

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 91 14:37:32 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: X11R5 Release -- Net Lag?

In article <1991Aug18.004805.13343@crl.dec.com> jg@crl.dec.com (Jim Gettys) writes:
   But the internet in the U.S. is now really quite high bandwidth
   (T3), so I suspect it will survive ok; [X11R5] should still be an
   observable blip in the statistics, I'll bet.

Since the T3 links are not entirely stable yet, X11R5 could be either
(a) an observable statistical blip, or (b) a major practice routing
meltdown exercise for ANS's network engineers.  I'm not betting...

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 91 18:24:11 GMT
From:      verber@pacific.mps.ohio-state.edu (Mark Verber)
To:        alt.sys.sun,comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: Diskless Sun 3/50 as X-terminal over SLIP/PPP. How to boot?

You have somne Sun 3/50 that you would like to boot an Xkernal via a
serial line using PPP?  You are kidding, right?  The options you
thought of were:

> 1. Hack a new boot-prom with possibility to boot via serial port.
>     (Can you get source code for existing proms?).

I believe that the source code to the boot proms was on an early SunOS
source tape to educational sites.  If you are going to the trouble of
burning PPP into the PROMs, why not go all the way and burn an X
server?  I wouldn't look forwarder to watching an extremely stripped
SunOS (I assume the Xkernal you are talking about is the one from
Columbia and not the OS research from Arizona) booting via serial
lines.  I believe this would be a lot more trouble than it is worth.

> 2. Buy a cheap SCSI-disk large enough for Xkernel & SLIP/PPP.

Not a bad option.  Here in the US you could easily do this for a few
hundred US$ since disk requirements are so small.

The preformance for either of these options will not be great.  I have
run X11 over a SLIP w/ VJ header compression on a 38.4kb line.  It is
usable, but far from great.  I have had better luck with terminals
that use some serial line X protocol like GraphOn or NCD Xremote.  I
personally would rather drop ~US$1000 for an Xterminal that is small,
has no fan, and is a supported product that mess around will a
jury-rigged Sun 3/50.

Cheers,
Mark Verber

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 91 18:51:26 GMT
From:      oldera@twg.com (Ed R. Alcoff)
To:        comp.protocols.tcp-ip
Subject:   Re: Protocol analyzers

Well, I dug thru my archives and I found the article that
compares Protocol Analyzers.  It was in May 1991 issue of
Data Communications magazine.  If you would like a copy
call (212) 512 - 2000.

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 91 23:28:31 GMT
From:      pte900@jatz.aarnet.edu.au (Peter Elford)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: Making the DNS work on System V Release 4 System

In article <1991Aug16.183050.6987@atc.SP.Unisys.COM>, mike@atc.SP.Unisys.COM (Mike Grenier) writes:
|> From article <lcz.682273098@dptspd>, by lcz@sat.datapoint.com (Lee Ziegenhals):
|> > pte900@jatz.aarnet.edu.au (Peter Elford) writes:
|> > 
|> >>I have been trying to help a site with Intel's (?) System V Release 4 
|> >>We had no problems running up the name server, but have been unable to
|> >>make the IP applications (ftp, telnet, ping, etc) use the DNS rather
|> >>than the /etc/hosts file. The /etc/netconfig file has had the resolver
|> >>routines added to the name-to-address mapping field:
|> > 
|> > Peter, you have to REBUILD those utilities with the resolv library to get them
|> > to use DNS :-(.  AT&T took the BSD versions of these utilities and ported them
|> > almost verbatum.  They call gethostbyname() to resolve host names, but the
|> > utilities as distrbuted are linked with the non-DNS library.  For some reason,
|> > they did not provide a single compatibility library that uses the netconfig
|> > entries to resolve host names.  To use the netconfig stuff, an application must
|> > call the new SVR4 name-to-address functions.
|> > 
|> 
|> I don't believe thats true. Simply move /usr/lib/libsocket.so to
|> somewhere safe and then move /usr/lib/socketdns.so to
|> /usr/lib/socket.so. This will allow the already compiled utilities to
|> use the DNS routines.

That does not look to be an option they have ...

$ ls /usr/lib/*dns*
/usr/lib/*dns*: No such file or directory

As a previous posting suggested, I think their version of SVR4 is not
quite up to it ... they are trying to get an updated release form thei
supplier.

Peter Elford,                           	e-mail: P.Elford@aarnet.edu.au
Network Co-ordinator,	 			phone: +61 6 249 3542
Australian Academic Research Network,		fax:   +61 6 247 3425
c/o, Computer Services Centre,			pager: +61 6 245 3035
Australian National University			post:	PO Box 4     
Canberra, AUSTRALIA					Canberra 2601

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 91 23:32:52 GMT
From:      pte900@jatz.aarnet.edu.au (Peter Elford)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: Making the DNS work on System V Release 4 System

In article <1991Aug16.182025.2862@ns.network.com>, clayh+@MUDLHEAD.NETWORK.COM (Clayton Haapala) writes:
|> This won't apply unless the TCP on the system is Wollongong-derived, such as
|> I've seen on ATT 3B2s and NCR Towers (some of them, anyway), but in these
|> cases, there is an environment variable called NONAMESERVER that gets set by
|> default to "true" or "yes" or something to turn the DNS function off.  I've
|> spent some time getting all the config files right and got named running, but
|> still couldn't get lookup to work right until that variable got changed.

I have not seen any reference to this in the (voluminous) documentation,
and it does not work if I try it ...

The derivation of the system in question is:

Copyright (C) 1984, 1986, 1987, 1988, 1989, 1990 AT&T
Copyright (C) 1987, 1988 Microsoft Corp.
UNIX System V/386 Release 4.0 Version 2.0

From what others have said the weak link is the "Version 2.0" -
apparently things work better in 3.0.

|> Again, I've never seen the V.4 TCP.

I'm beginning to think it's not something I want to have a lot to do with
either ...

Peter Elford,                           	e-mail: P.Elford@aarnet.edu.au
Network Co-ordinator,	 			phone: +61 6 249 3542
Australian Academic Research Network,		fax:   +61 6 247 3425
c/o, Computer Services Centre,			pager: +61 6 245 3035
Australian National University			post:	PO Box 4     
Canberra, AUSTRALIA					Canberra 2601

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 91 09:56:20 GMT
From:      myn%myn.computerland.kiev.ua@relay.USSR.EU.net (Yuri N. Muraviov)
To:        comp.protocols.tcp-ip
Subject:   (none)

unsubscribe Yuri Muraviov

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 91 11:27:15 GMT
From:      kuyper@cside1.uucp (Kuyper Hoffman)
To:        comp.protocols.tcp-ip
Subject:   Broadcasting with datagrams

I am fiddling with an example from Doug Comer's Internetworking with
TCP/IP book.  One of the code fragments he provides is a simple
"whois" client/server pair.

He uses the Berkeley sockets library, specifically, connected TCP
sockets.

I have subsequently converted this from TCP to UDP (Datagrams) in
the hope of building a broadcast client.  When sending directed
Datagrams (ie filling a specific host address into the address
field) it works great, I can send from a client on any machine to a
server on any machine, the server receives the request and where it
came from, services the request and sends back the reply.

This is the picture (simplified IP numbers):

A client may be run on either machine, a server is already running
on both machines.

 |--T------------------T----------------T--|
	|                  |                |
Machine A          Machine B          Netwatch
192.9.200.1        192.9.200.2        192.9.200.3


3 basic scenarios exist:
**** 1 ****
Client on A sends message to 192.9.200.1 (Machine A itself)
Netwatch indicates NO TRAFFIC (this is fine, a local call to the
								server)
Server on A recvs message from 192.9.200.1
Server on A sends reply to 192.9.200.1
Netwatch indicates NO TRAFFIC (this is fine, a local call to the
								server)
Client on A recvs reply from 192.9.200.1


**** 2 ****
Client on A sends message to 192.9.200.2
Netwatch indicates message from 192.9.200.1 -> 192.9.200.2
Server on B recvs message from 192.9.200.1
Server on B sends reply to 192.9.200.1
Netwatch indicates message from 192.9.200.2 -> 192.9.200.1
Client on A revs reply from 192.9.200.2


**** 3 ****
Client on A sends message to 192.9.200.255 (or 255.255.255.255)
Netwatch indicates message from 192.9.200.1 -> 192.9.200.255
Server on B sees nothing

And that's where it all stops....


Additional info:
UNIX hosts running Intel or Interactive UNIX, with respective TCP/IP
implementation, PC/IP Netwatch v9.6, Western Digital Ethernet cards,
PC running Packet Driver v9.7, etc.... All pretty standard stuff.

Sockets are opened as, address family AF_INET, type SOCK_DGRAM,
protocol IPPROTO_UDP, in both the client and server.

The client process has turned on SO_BROADCAST with the setsockopt
system call, have I missed something, is this not enough?  BTW
turning this on in the server made no difference either....

Ultimately, I'd like to use this from PC/TCP, with a process on the
PC broadcasting to a whole bunch of UNIX hosts.

I'd really appreciate any help with this.  Please e-mail responses
and I'll post a summary when it's all in.
-- 
|      Kuyper Hoffman                   |  Life is just a bowl of All-Bran |
|  kuyper@cside1.UUCP                   |  You wake up every morning       |
|  ....!ddsw1!olsa99!oct1!cside1!kuyper |  And it's there....              |
 \--------------------------------------/ \--------------------------------/
-- 
|      Kuyper Hoffman                   |  Life is just a bowl of All-Bran |
|  kuyper@cside1.UUCP                   |  You wake up every morning       |
|  ....!ddsw1!olsa99!oct1!cside1!kuyper |  And it's there....              |
\--------------------------------------/ \--------------------------------/

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 91 11:58:50 GMT
From:      cattelld@prlhp1.prl.philips.co.uk (David Cattell)
To:        comp.protocols.tcp-ip
Subject:   IP source code request


     
    Has anyone out there got or know where I can get the source code for an 
    IP gateway, preferably in C and for a PC ? 
    
    I need to be able to connect the Ethernet side of the PC to some serial
    lines probably using a intelligent multiple line card like a Digiboard.
    The PC needs to be able to gateway UDP/IP packets to/from the Ethernet
    down the serial lines (possibly PSTN connections) from/to remote UDP/IP 
    users.  
    
    Unfortunately, I have to use email addresses to get the code as I can't 
    do an anonymous FTP from this site.

    Any help would be appreciated.


    Dave Cattell.          cattell@prl.philips.co.uk

        Philips Research Laboratories,
        Redhill,
        Surrey,
        England.

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 91 12:54:56 GMT
From:      mark@TELESYS.NCSC.NAVY.MIL (Williams)
To:        comp.protocols.tcp-ip
Subject:   Re:  Using both /etc/hosts and domain name server to get host addrs

Mark:

I may be able to offer some info on your question.  I'll respond privately
(unless net users ask to see the thread...)

Mark L. Williams
Head, Telecommunications Branch
Code 7630
Naval Coastal Systems Center
Panama City, FL 32407-5000
(904)235-5153
(mark@telesys.ncsc.navy.mil)

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 91 13:16:18 GMT
From:      kevin@msa3b.UUCP (Kevin P. Kleinfelter)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   Slipping on SLIP

I'm setting up a system where many different workstations dialup an
RS/6000, and communicate via TCP/IP with SLIP.  Each serial port to be
used with SLIP has a specific internet address assigned to it.
Each workstation dials the SAME phone number, and the PBX rolls over to the
first available modem.

The problem:

   I need to assign the internet address for the port to the workstation.

I *thought* I'd just have the workstation send a BOOTP. Unfortunately, 
BOOTPD simply does a table lookup from a "hardware" address shipped from
the workstation to an internet address. I was hoping that BOOTPD would use
the hardware address assigned to the serial port that the BOOTP came in on.

So I set off to program my own version of BOOTPD. I did a bind to port 67,
and a recv_mesg.  I still get the address supplied from the workstation.

How can I find out what serial port a UDP packet came from?  Is it possible
to use AIX as a dial-in SLIP server?


-- 
Kevin Kleinfelter @ DBS, Inc (404) 239-2347   ...gatech!nanovx!msa3b!kevin
Dun&Bradstreet Software, 3445 Peachtree Rd, NE, Atlanta GA 30326-1276
WARNING: I have been advised that email to kevin@msa3b.UUCP may bounce.
It looks like email will have to go via 'gatech' because that is well-known.

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 91 13:31:34 GMT
From:      agodwin@acorn.co.uk (Adrian Godwin)
To:        comp.sys.3b1,comp.protocols.tcp-ip
Subject:   Re: Printing out 'ipctut' from osu archive

In article <210@beyonet.UUCP> beyo@beyonet.UUCP (Steve Urich) writes:
>In article <260@zebra.UUCP> vern@zebra.UUCP (Vernon C. Hoxie) writes:
>>
>->I recently downloaded a file from the AT&T-7300/3B1 archive at osu-cis
>->which is called 'ipctut'.  It is a tutorial originally issued by the
>->Regents of the University of California.  It contains no programming
>->code but does have a Makefile to be used in printing out the document.
>
>	<*> I got this file also and had the same problem. I hacked it
>	to nroff but it didn't look pretty. 
>

I printed this quite readably using (as per the makefile)

  tbl tutor.me | nroff -me 

and equally using psroff instead of nroff. However, this was on a BSD
system (though I don't have ditroff) and the -me macros are available.

I've had problems trying to use macro packages between systems - printing
the DDDGuide using psroff on the BSD system with ms macros from CTIX was
a disaster - so I don't know if just installing BSD macros on SysV will
fix up the problem.

Does anyone know if BSD nroff differs from AT&T nroff ?

-adrian

-- 
--------------------------------------------------------------------------
Adrian Godwin                                        (agodwin@acorn.co.uk)

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 91 15:59:46 GMT
From:      louie@sayshell.umd.edu (Louis A. Mamakos)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window

In article <16378@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>	Also, I thought I'd point out, since it's a pet peeve [:-)], the probe
>time should be the same as the retransmission time, with exponential backoff,
>and not 2 minutes (!). Berkeley uses a minimum of 5 seconds (as much as a
>1000 times too large on an Ethernet), which makes for pretty poor performance
>if you do drop a probe. Maybe they'll fix it in 4.4. :-)

But, what does how fast the receiving process can empty the queue have
to do with the retransmission time?  When the processing receiving the
data empties the queue, the TCP one that host should transmit a window
update to the other end causing it to transmit more segments into the
window.  Probing every RTT seems pretty extreme, given that the user
might have suspended his telnet client and has a complete TCP window's
worth of data already "backed up".

The only time you should need do a probe is when the ACK containaing
the window update is lost.  It will also detect a broken connection.
It might be convinced that you could measure the flow rate of the
connection, and use that to estimate how long the other end takes to
consume the data, but that could only be taken as a starting point.

>	If you have an implementation that uses 2 minutes for a probe time,
>or anything more than the smoothed rtt, you should complain to the vendor,
>because dropped packets will give you unnecessary and noticeable delays.

This has not been a noticable problem for us.  Perhaps the solution is
to have the remote TCP emit a window update whenever another MSS worth
of data can be transmitted?

louie

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 91 17:11:07 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window

In article <1991Aug19.155946.3930@ni.umd.edu>, louie@sayshell.umd.edu (Louis A. Mamakos) writes:
> But, what does how fast the receiving process can empty the queue have
> to do with the retransmission time?  When the processing receiving the
> data empties the queue, the TCP one that host should transmit a window
> update to the other end causing it to transmit more segments into the
> window.  Probing every RTT seems pretty extreme, given that the user
> might have suspended his telnet client and has a complete TCP window's
> worth of data already "backed up".

	I won't defend RFC 1122-- the authors can do that. What is important
is that 5 seconds is inordinately long, and not adaptive. It isn't "every RTT",
either, though-- it is exponentially backed off, and that, again, is the
feature missing from many implementations. See my answer to below for some
likely motiviation for the RTT relationship.

> The only time you should need do a probe is when the ACK containaing
> the window update is lost.  It will also detect a broken connection.

	Not really true. As I recall (though I have to hedge my bets, since
I'm not looking at RFC 793 now), window updates, while mentioned and perhaps
even recommended, are not at all required. It is the *transmitter's*
responsibility to make sure data flows. A completely conforming TCP can choose
NOT to send window updates and if the probe time is some fixed (and long)
constant, that delay will be guaranteed every time the window is closed.
	If, on the other hand, the receiver uses the RTT to judge whether
a) a window update was lost, or b) window updates are not being sent, it can
respond quickly to closed windows and see only the delay used to empty the
receive buffer. Even if the RTT isn't the ideal starting point, it doesn't
beat on the machine because of the exponential backoff, and it's much better
than a constant (large or small) when network speeds vary as much as they do.

	I found out about the Berkeley 5 second delay because an early version
of my TCP didn't do window updates (does now), and we saw the 5 second pauses
when talking to BSD machines with enough data to fill the window. When talking
to each other, however, because I used RFC1122, they'd recover from closed
windows just fine. It should only occur among "most" implementations if the
window update is lost, but 5 seconds is a big price for one lost packet.

-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 91 17:32:13 GMT
From:      pjj@interlink.com (Patrick Johnston)
To:        comp.protocols.tcp-ip
Subject:   rdump and rrestore for System V

I have heard of public domain or comercially available sources for rdump
and rrestore but have not been able to find any.  Can anyone help me in
locating sources for these utilities for System V?

Thanx,
------------------------------------------------------------------
Patrick Johnston	Manager, International Marketing & Support
pjj@interlink.com	Interlink Computer Sciences
sun!ntrlink!pjj		47370 Fremont Blvd
			Fremont, California 94538
voice:	415/657-9800	fax:    415/659-6381

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 91 18:22:05 GMT
From:      alpha@hubcap.clemson.edu (Shekhar Borde')
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   TCP Port Assignment


I am writing a client-server application that uses sockets. The port
I need to use for this application has two restrictions.

(1) It should be unassigned (obviously)

(2) It's use should be restricted to the super-user.

The rfc's on my machine list unassigned ports but do not tell if any
are restricted for use by root only.

Does anyone know how to determine a suitable port using the two
aforementioned constraints.

Any help will be greatly appreciated!


-Shekhar Borde
 alpha@hubcap.clemson.edu

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 91 22:00:19 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window

In article <16378@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>	But it is a special case, as illuminated above. If you have exactly
>4K of buffer space, you can't advertise 4K+1, because it'll force you to drop
>the last byte of data (you can't tell a priori it'd be a FIN) during normal
>flow and force a retransmit for that 1 byte, but you *can* accepted 4K of
>data and the FIN.

Well, i don't want to belabor the point, but what you're saying that
FIN is a special case in your implementation.  My point is that FIN
isn't a special case in the protocol and, in fact, it could very well
use up a byte of buffer space in any given implementation.

I don't mean to contradict any of your proposed optimization
techniques for FIN: they all look perfectly reasonable.  But let's not
start writing code that assumes all implementations will behave that
way.  For example, it's not a good idea to advertise a zero window
when you're expecting a FIN because that may delay the FIN's
transmission.

>	Also, I thought I'd point out, since it's a pet peeve [:-)], the probe
>time should be the same as the retransmission time, with exponential backoff,
>and not 2 minutes (!)

What i said was that rfc793 recommended a 2 minute probe time (page 42).
Of course, rfc1122 (page 92) corrected this to be as you described,
but some TCP implementations predate rfc1122.

In article <16460@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>	Not really true. As I recall (though I have to hedge my bets, since
>I'm not looking at RFC 793 now), window updates, while mentioned and perhaps
>even recommended, are not at all required. It is the *transmitter's*
>responsibility to make sure data flows. A completely conforming TCP can choose
>NOT to send window updates and if the probe time is some fixed (and long)
>constant, that delay will be guaranteed every time the window is closed.

While it is the transmitter who ultimately knows if there's any data
to be flowing and to insure that it flows, *both* parties are
responsible for seeing that it flows efficiently.  A completely
conforming TCP can also choose to send a probe packet once an hour.
Of course, that would be silly.  Even waiting two minutes (initially)
between probes would be silly.  But it's just as silly not to send a
window update signaling an open window after the window's been closed.

							don provan
							donp@novell.com

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 91 00:45:29 GMT
From:      revell@uunet.uu.net (James R Revell Jr)
To:        comp.protocols.tcp-ip
Subject:   Re: X11R5 Release -- Net Lag?

In article <1991Aug18.004805.13343@crl.dec.com> jg@crl.dec.com (Jim Gettys) writes:
} This should be an interesting experiment.  At least two of the ftp
} sites (crl.dec.com and gatekeeper.dec.com) plan to have 25 MIP machines
} with tons of memory which will have the entire distribution in main memory 

Plans so far here include using two workstations of similar ability as
special ftp servers just for X11R5.  Although uucp folks will have
access via uunet.uu.net, no ftp access to X11R5 on uunet.uu.net will be
allowed.  We remember the load due to ftping X11R4 when it came out all
too well...
-- 
James Revell   sr uunet postmaster   <revell@uunet.uu.net>   /8^{~

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 91 02:23:01 GMT
From:      visjanap@ubvmsb.cc.buffalo.edu (Jan A. Pisanczyn, SUCB)
To:        comp.protocols.tcp-ip
Subject:   Programming C with TCP/IP

Posting this for a friend who does not have net access at this time, please
reply to him at his e-mail address listed at the end of the message, thanks!

-------------------------------

Hello!

  I am taking an independent study next semester "advanced C", and will be
writing an application program in C using TCP/IP.  My intents are to write
a client and a server obviously...  I have done research papers on TCP/IP
so I understand the basic concepts behind the protocol suite, however, I
have no clue as how to write a client and server using the protocol.  I am
looking for:

   *Example programs in C
   *Names of books I could buy
   *Places on the network I could access with FTP with examples
      OR documentation...

Please reply if you can help out with any of the above... Thanks in advance!

Rob Lizak Jr.

lizak98@snybufva.bitnet   <= E-Mail address...

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 91 03:35:36 GMT
From:      dnichols@ceilidh.beartrack.com (Don Nichols (DoN.))
To:        comp.sys.3b1,comp.protocols.tcp-ip
Subject:   Re: Printing out 'ipctut' from osu archive

In article <9265@acorn.co.uk> agodwin@acorn.co.uk (Adrian Godwin) writes:
>In article <210@beyonet.UUCP> beyo@beyonet.UUCP (Steve Urich) writes:
>>In article <260@zebra.UUCP> vern@zebra.UUCP (Vernon C. Hoxie) writes:
>>>
>>->I recently downloaded a file from the AT&T-7300/3B1 archive at osu-cis
>>->which is called 'ipctut'.  It is a tutorial originally issued by the
>>->Regents of the University of California.  It contains no programming
>>->code but does have a Makefile to be used in printing out the document.
>>
>>	<*> I got this file also and had the same problem. I hacked it
>>	to nroff but it didn't look pretty. 
>>
>
>I printed this quite readably using (as per the makefile)
>
>  tbl tutor.me | nroff -me 
>
>and equally using psroff instead of nroff. However, this was on a BSD
>system (though I don't have ditroff) and the -me macros are available.

	groff compiles and runs on the 3b1, and includes the '-me' macro
package.  It is available on osu-cis (I am assured.)

	Good Luck
		DoN.

-- 
Donald Nichols (DoN.)     | Voice (Days): (703) 664-1585 (Eves): (703) 938-4564
D&D Data                  |  Email: <dnichols@ceilidh.beartrack.com>
I said it - no one else   |         <dnichols@ceilidh.aes.com>
	--- Black Holes are where God is dividing by zero ---

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 91 09:20:16 GMT
From:      simon@liasun2.epfl.ch (Simon Leinen)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: TCP Port Assignment

In article <1991Aug19.182205.12836@hubcap.clemson.edu>
alpha@hubcap.clemson.edu (Shekhar Borde') writes (abridged):

   The port I need to use for this application has two restrictions.
   (1) It should be unassigned (obviously)
   (2) It's use should be restricted to the super-user.

   The rfc's on my machine list unassigned ports but do not tell if
   any are restricted for use by root only.  Does anyone know how to
   determine a suitable port using the two aforementioned constraints.

Because the RFCs are intended to be OS independent, the notion of root
does not make much sense.  But if your application needs only be
portable to UNIX systems, you will find in RFC 1060 that ports 256 to
1023 are used for "Unix Standard" services by convention.  This
implies that they are restricted to root in Unix systems.  The RFC
goes on and lists many such ports, but all in the 512--1023 subrange.
Maybe there is a second (unwritten?) convention that reserves ports
256--511 for ``private'' assignments?
-- 
Simon Leinen.
Laboratoire d'Intelligence Artificielle
Ecole Polytechnique Federale de Lausanne

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 91 12:35:15 GMT
From:      ggt@fstgds03.tu-graz.ac.at (Gerhard Thallinger)
To:        comp.protocols.tcp-ip
Subject:   Assignment of internet addresses and port numbers


I have two questions :

1) How and where do I have to apply for an official internet address range.
   Name of the organisation, E-mail address, or surface mail address, 
   or fax and phone number would be fine.

2) Who is assiging the port numbers for tcp or udp communications.
   Are there any unassigned ones, which can be used by anybody ?

Please respond via E-mail. I will summarize if there is enough interest.

thanks in advance

Gerhard G. Thallinger                     Internet: ggt@fstgds03.tu-graz.ac.at 

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 91 12:57:13 GMT
From:      oldera@twg.com (Ed R. Alcoff)
To:        comp.protocols.tcp-ip
Subject:   Re: Protocol analyzers

In article <9108121906.AA12798@ftp.com> jbvb@ftp.com writes:
>There are a number of software network monitors/protocol analyzers out
>there, including LANWatch from FTP Software, WIN/Watch (may have been
>renamed recently) from Wollongong and WatchTower from Intercon.  These
>use an existing PC (or Mac in the case of WatchTower) and network
>interface, and tend to cost between 1/10th and 1/100th of the price of
>a similarly-equipped high-end product.  There's also Netwatch, which
>is free as part of the MIT/CMU/Harvard PCIP software package.
>
>James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
>FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

James, I believe Intercon (Intecon?)'s WatchTower is something of a
SNMP Management Station- somewhat similar to your own SNMP Tools.

WIN/WATCH is something more akin to a protocol analyzer, I have always
considered it a bargain @ $1,000 if you only need the functionality
set it provides.  

Regards,

Ed Alcoff
Product Manager, 
VMS & Network Management Products
The Wollongong Group, Inc.
1129 San Antonio Rd.
Palo Alto, Ca.  94303

ph  # (415) 962 - 7240
fax # (415) 969 - 5547
e-mail: oldera@twg.com		#include std.disclaimer

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 91 14:49:26 GMT
From:      jas@proteon.com (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   3rd bit of 802.5 Source-routing RIF

Since there is still no approved IEEE standard for 802.5
source-routing (maybe it just got voted in), one has to rely on IBM's
constantly changing non-standard self-defined "architecture".  In the
first versions of their architecture specifications, there was only
one frame type bit in the RIF.  If 1 it was broadcast (all-rings, that
is), if 0 it was non-broadcast.  I think this is what version 1.x of
IBM's bridge software implemented.

In the next IBM "architecture", there are 3 frame type bits. '0XX' is
non-broadcast, '10X' is all-routes broadcast, and '11X' is
single-route broadcast.

Then in IBM proposals to 802.5 (P802.5D/D15, back in 1989 when
attempts were being made to make the SR-TB to Ethernet a functional
part of the architecture), more combinations of these three bits were
proposed.  The bit pattern '111' was proposed as spanning-tree routed
frame.  ('10X' was changed to '100', and '11X' to '110'.)  I would not
be at all surprised if this is what the 2.x versions of the IBM bridge
software do, since they came out at that time, and they interoperate
with the IBM 8209, which is an implementation of the now extremely
deprecated SR-TB.  (The SR-TB, unlike an 802.1D transparent bridge, is
extremely non-idiot proof, and can easily be used to cause fatal
bridging loops!)

In the lastest ballot draft (P802.5M/D4), the bit combinations are
familiar, but the names have been changed to confuse the innocent:
	'0XX'	Specifially Routed (SR) 
	'10X'	All Paths Explorer (APE)
	'11X'	Spanning Tree Explorer (STE)
Note that the third bit has returned to undefined.

(I won't even try and explain what they all mean.  Consider yourself
lucky if you don't care!)

There is a reason that IEEE drafts say "This is an unapproved draft
which is subject to change and cannot be presumed to reflect the
position of Project 802 or the Institute of Electrical and Electronics
Engerrs.  DO NOT SPECIFY OR CLAIM CONFORMANCE TO THIS DOCUMENT."

Implementing drafts can be hazardous to your health and sanity.

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 91 15:24:36 GMT
From:      hzessel@hpugrca.HP.COM (Holger Zessel)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC/XDR weirdness

/ hpugrca:comp.protocols.tcp-ip / tb@Materna.DE (Torsten Beyer) /  7:45 am  Aug  7, 1991 /
Hi Netland,

I'm working on a piece of RPC-software part of which transfers lists between
two machines. While debugging the stuff I realized that my program would
slowly grow ( in terms of memory usage ;-). I first thought that I forgot to
put some xdr_free's in the right place but couldn't find a fault on my side.

Finally I decided to look into the xdr routines generated by rpcgen. I think
I have found a bug but correct me if I'm blind. Consider the dir.x demo
software that comes with rpc. Here's what rpcgen generates of dir.x:

bool_t
xdr_nametype(xdrs, objp)
	XDR *xdrs;
	nametype *objp;
{
	if (!xdr_string(xdrs, objp, MAXNAMELEN)) {
		return (FALSE);
	}
 return (TRUE);
}

bool_t
xdr_namelist(xdrs, objp)
	XDR *xdrs;
	namelist *objp;
{
	if (!xdr_pointer(xdrs, (char **)objp, sizeof(struct namenode), xdr_namenode)) {
		return (FALSE);
	}
 return (TRUE);
}

bool_t
xdr_namenode(xdrs, objp)
	XDR *xdrs;
	namenode *objp;
{
	if (!xdr_nametype(xdrs, &objp->name)) {
		return (FALSE);
	}
	if (!xdr_namelist(xdrs, &objp->next)) {
		return (FALSE);
	}
 return (TRUE);
}

Consider a list of n entries. When calling xdr_free for namenode, it would
free it's nametype entry and - by calling xdr_namelist the next one. But not
further.  I'm I right to suspect that in the above case only the second list
element would get free'd by xdr ? Or is there a trick somewhere in
xdr_pointer that enables it to free subsequent list elements ???

Is there any whay to convince rpcgen that a certain struct is part of a list
and that it should generate recursive xdr routines ?? Or do I have to code
all this by hand ???

Any clues greatly appreciated

			thanx in advance

				-Torsten
--
Torsten Beyer                      	e-mail : tb@Materna.DE
Dr. Materna GmbH		   	VOX    : +49 231 5599 225
Vosskuhle 37, D-4600 Dortmund	   	FAX    : +49 231 5599 100
       "Strahlentod und Mutation durch die schnelle Kernfusion..", Kraftwerk
----------

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 91 16:13:06 GMT
From:      NIC@NIC.DDN.MIL (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   Security books

Attached is a description of books that would be of interest to many
readers of the TCP-IP list. The subject of security is of ongoing
interest in the current internet environment. This announcement is for
informational purpose only, and should not be taken as a guarantee
or recommendation by SRI or the NIC.

Steven
...at the DDN NIC


COMPUTER SECURITY BOOKS

Two computer security books are now available from O'Reilly &
Associates, publishers of the X Window System series and the UNIX
Nutshell Handbook series:

Computer Security Basics
by Deborah Russell and G.T. Gangemi Sr.
464 pages, $29.95

Audience:  Users and managers who need to become security-literate.

This book provides an easy-to-understand introduction to the many
topics encompassed by the term "computer security"--passwords, access
controls, cryptography, trusted operating systems, network security, 
biometric devices, smart cards, and TEMPEST shielding.  It provides 
detailed information on the Orange Book, the government's standard 
for the development of trusted systems.  It also contains 
quick-reference material, including a security glossary and a summary 
of government programs, contacts, and legislation.

Practical UNIX Security
by Simson Garfinkel and Gene Spafford
512 pages, $29.95

Audience:  UNIX users and system administrators.

This book spells out the many security options for systems running
either System V or Berkeley UNIX.  It tells how to keep intruders out,
how to tell if they've gotten in, how to clean up after them, and even
how to prosecute them. It provides numerous scripts, detailed
information on defending against network and communications breaches 
using modems, NFS, Secure NFS, Kerberos, and firewall machines,
and a list of other security sources (books, organizations, etc.).


To order these books or to discuss corporate discounts, contact
O'Reilly & Associates at 632 Petaluma Avenue, Sebastopol, CA, 95472.
In the US and Canada, call 1-800-338-6887.  
Overseas or California, call 707-829-0515.  
To send a FAX, call 707-829-0104."

-------

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 91 17:06:40 GMT
From:      skr@ramnad.sps.mot.com
To:        comp.protocols.tcp-ip
Subject:   POP3 clients for Mac's and PC's

Hi!
  Has anyone heard or seen the " stanford university Macintosh Internet
Protocol MacMH program" and " Personal Computer Internet Protocol MH program". These
programs are mentioned in the popper installation guide which I got from
"ftp.cc.berkeley.edu". I would appriciate any pointer's to these programs.
Thanks in advance

                                                 Vincent Shekher
Email address:Shekher-ayhc30@email.sps.mot.com

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 91 21:19:23 GMT
From:      gwilliam@SH.CS.NET (George Williams)
To:        comp.protocols.tcp-ip
Subject:   Re: EBCDIC ASCII and *much* more


    Date:    Thu, 08 Aug 91 16:54:54 +0200
    From:    Andr'e PIRARD <PIRARD@vm1.ulg.ac.be>
    Subject: EBCDIC ASCII and *much* more

	
Thanks for the abundance of reference your writings afford in this area of
of character representation.It is a good paper which raises a couple of issues
the have been long standing in this increasing complex area, the 
representation and presentation of transmitted data. I have not read all the
above mentioned writings and offer the following on on the subject.

[..........

Is being a standard justification for usage ? I think there are considerations
that should go into determining  code sets and their resulting usage above 
and beyond just standardization. I am not against standards but if you look
around us we are about to come full circle on the issue. What started out 
to unite is serving to divide and the line of demarcation is based on the
highest yielding currency exchange.

I am in agreement that we should be striving for a network-neutral, or common,
character set. If you don't mind my taking the liberty of extending your
language analogies, however - the whole world does not speak english, french,
german, etc., right ( i,e. one language )?

There should be a global standard and the de facto 8859-1 fills many 'now'
requirements. It fulfills the needs of existing textual ( display and
print data, e.g file transfer, email ) applications, but remember there are 
other worlds out there (International Graphics, Product Data, Fax, Video,
 etc.) with still evolving data transmission requirements.
	
Have I been mislead all these years in thinking that syntactical matters of 
usage and association; what gets translated, and where, as well as the 
semantics associated with usage; what code points, character sets, et al. get
used , would get resolved within the architectural framework of something 
called a presentation layer - ISO 8822 ? This is the only way it all serves 
to make since. You make your association(s), describe the semantics. Trans-
formation of inbound and outbound PDU to and from host character to network
neutral format is done ( determination how, where and when ) when an 
association is made ( please note: association does note imply connection ).


A machine can and should store data as best fits it's machine architecture.
Why, the hardware should be able to store a character as a bit if design 
so facilitates. The translation to network neutral format can then be done
in a distributed fashion based on prior element association across 
presentation boundaries. That is, data transformation can be looked at as
within the context of a flow association model; wherever the resource resides
is where the work will get done.

..........]

[The opinions and views expressed above are mine, alone.]

  George Williams

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 91 22:17:14 GMT
From:      bobw@cc.usu.edu
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for DEC PRO-350?

Is there a TCP/IP package that runs on a DEC PRO-350?
Thanks
-- 
===============================================================================
Bob Wood    WA7MXZ                      bobw@cc.usu.edu
Utah State University                   bobw@usu.bitnet
Chemistry and Biochemistry              tel. (801) 750-1614
UMC 0300
Logan, Utah  84322-0300

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

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 91 22:47:21 GMT
From:      Pezely@hitl.washington.edu (Dan)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.protocol.iso,comp.dcom.lan
Subject:   Transport Protocols for Operating Environment platforms


I'd like some feed-back from those knowledgeable and experienced in network
protocol design and implementations, hence the broad list of
cross-postings.  


For Tele-presence/Operating Environment platforms, we need a rugged
transport protocol like in the IP suite since we don't know all of the
network types we'll be running on.  That is, we would like one transport
protocol for LANs and WANs at a wide range of speeds and signal-to-noise
ratios.

Here's what I had in mind.  A lot of thought went into the IP suite and it
was changed as necessary-- a sort of maturation.  That seems to be a good
place to start, considering my lab is not a networking research lab.
(However, I would like to deeply persue such research in grad school or
industry in about a year...)


my idea-- probably not new:

The protocol at the transport level is a cross between datagrams and
connection-oriented communications models.

It's datagrams with configurable options: 
 - toggle acknowledgements on/off 
   and when on, specify the ACK- count size for sequencing;
 - variable time-outs lengths defaulting to the `slow-start' technique;
 - variable retransmission attempt counts.  

Thus, straight datagrams and full connection-oriented models will be
supported with the same protocol.  Has this been attempted before?  

Initial implementations will be built on top of UDP/IP for its existing
header fields.

The application layer protocols are simply messages, but these messages may
be larger than one packet, of course.

Yes, an everything protocol might be nice but could be a nightmare, but
while I'm at it:
Synchronization may become a necessary feature for the applications, so
working NTP into the picture would be nice.


I'm just looking for some quick feedback.  (follow-up to comp.protocols.misc)

Thanks.
-Dan P

ps - this would be interesting to specify in Estelle and to simulate with
GROPE.  gee, I'm not doing too much this week...  :)

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 91 00:03:07 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   export controls


Does anyone know about new export controls to "proscribed destinations"
on anything which uses "datagrams," "adaptive routing", or "fast select",
in a recent Federal Register?  I was just asked if my employer's products
uses such high tech stuff.  Further exchanges with the guvinment obtained
definitions for all three:

    "Fast select" makes no sense to me, except that it sounds x.25-ish.

    "Datagrams" seem to be what you would expect, from ethernet or other
	LAN frames to IP to UDP to postcards from grandma.

    "Adaptive routing" appears to cover everything from routed thru
	the latest OSPF-whatnot.

So what's the deal?  Are our fearless leaders trying to keep that
super top secret BSD IP and routing code away from Naughty Sadam?


Vernon Schryver,   vjs@sgi.com

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 91 00:24:17 GMT
From:      root@CABELL.VCU.EDU (System PRIVILEGED Account)
To:        comp.protocols.tcp-ip
Subject:   Second posting


This is a second posting....and I'm getting desperate.....:)

Several months ago there was several inquiries about a program
that would display active tcp connections....tying together
process id's and port numbers.  At the time our system was
a Pyramid 9810.  I got a copy of the file and it worked great!
Since that time, we have migrated to a DEC 5500 running Ultrix 4.2.
Like a dummy I deleted the source code and the location of the 
original file.  I desperately need that program again....can
someone out there tell me where I can find such a program?

I vaguely remember it being called something like pff or something
like that....

Any help will be greatly appreciated....

Bryan Miller
Network Manager
Virginia Commonwealth University

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 91 01:16:42 GMT
From:      coates@UC780.UMD.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Programming C with TCP/IP

In article <87966@eerie.acsu.Buffalo.EDU>, visjanap@ubvmsb.cc.buffalo.edu
(Jan A. Pisanczyn, SUCB) writes:
>Posting this for a friend who does not have net access at this time, please
>reply to him at his e-mail address listed at the end of the message, thanks!
>
>Hello!
>
>  I am taking an independent study next semester "advanced C", and will be
>writing an application program in C using TCP/IP.  My intents are to write
>a client and a server obviously...  I have done research papers on TCP/IP
>so I understand the basic concepts behind the protocol suite, however, I
>have no clue as how to write a client and server using the protocol.  I am
>looking for:
>
>   *Example programs in C
>   *Names of books I could buy
>   *Places on the network I could access with FTP with examples
>      OR documentation...
>
>Please reply if you can help out with any of the above... Thanks in advance!
>
>Rob Lizak Jr.
>
>lizak98@snybufva.bitnet   <= E-Mail address...

Please post replies, Thanks!
---
coates@uc780.umd.edu

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 91 03:29:42 GMT
From:      cryptkpr@cc.utah.edu (H. CARLTON DOE III)
To:        comp.protocols.tcp-ip
Subject:   Network Performance Tools Needed--Please forward recent info

I need some recommendations on tools (both hardware and software) to analyze
my network performance.  It appears as though this has been a fairly recent
thread based on one post I saw tonight.  What I'd like to get then is a recap
of the info posted if anyone has it.

What I am trying to do is isolate and look at each part of the transmission
and receipt of data and find where potential bottlenecks are.  When finished
I'd like to be able to know what the load on the CPU is, the network interface
card performance etc. for all my machines as well as the load and performance
of the transport medium.  I'm looking at getting some real screamer machines
(in terms of cpu speeds, etc.) but don't want to waste the money if the
interface cards can't keep up or the transport layer is maxed out.

I'm currently running AT&T 386/486 machines with Sys V R. 3.2 & R. 4.  The
TCP/IP is a Wollongong product running over a STARlan 10baseT star topology.
All the network cards are 10mb/s.

If anyone can help me with this request I'd appreciate the e-mail.  My 
thanks in advance to any who reply.


Carlton Doe (aka the Crypt Keeper)
Spectrum Field Services
AT&T Mail: attmail!alexis!carlton
Internet: att!attmail!alexis!carlton@uunet.uu.net  OR  cryptkpr@cc.utah.edu

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 91 07:12:36 GMT
From:      AKayser@dnpap.et.tudelft.nl (Alfred Kayser)
To:        comp.protocols.tcp-ip
Subject:   Re: Protocol analyzers

oldera@twg.com (Ed R. Alcoff) writes:
>In article <9108121906.AA12798@ftp.com> jbvb@ftp.com writes:
>>There are a number of software network monitors/protocol analyzers out
>>there, including LANWatch from FTP Software, WIN/Watch (may have been
>>renamed recently) from Wollongong and WatchTower from Intercon.  These
>>use an existing PC (or Mac in the case of WatchTower) and network
>>interface, and tend to cost between 1/10th and 1/100th of the price of
>>a similarly-equipped high-end product.  There's also Netwatch, which
>>is free as part of the MIT/CMU/Harvard PCIP software package.
>>
>>James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
>>FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
 
>James, I believe Intercon (Intecon?)'s WatchTower is something of a
>SNMP Management Station- somewhat similar to your own SNMP Tools.
 
>WIN/WATCH is something more akin to a protocol analyzer, I have always
>considered it a bargain @ $1,000 if you only need the functionality
>set it provides.  

And there is our very free network monitoring tool called 'The Beholder'
It runs on a standard PC with a network card.
It supports SNMP, UDP/IP with PING and TFTP.
It can monitor network load, type distribution, and length distribution.
It has an source/destination matrix. Up to 5000 connections can be online be
monitored.
It will have protocol analyzers. This is currently being worked on.
It will have host profil watchers for operation and security protection.
It includes (very soon now) the complete source and is easily extendible.

Enough hipe for now. There enough monitors to make a choice.
Make sure you make the right choice. (Before paying a lot of coins.)

Greetings, Alfred

--
-- Ir. Alfred Kayser. PACS, OS/2, TCP/IP. --- Email: AKayser@et.tudelft.nl --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 91 07:40:03 GMT
From:      frank@unibi.uni-bielefeld.de (0015)
To:        comp.protocols.tcp-ip
Subject:   private MIB for MultiNet

I need the private MIB extensions which are used in LANNETs cabling system
MultiNet. Is this available anywhere ?

Frank

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 91 13:01:00 GMT
From:      heisinger@MDCGWY.MDC.COM
To:        comp.protocols.tcp-ip
Subject:   NQS Implementations for IBM MVS


    Is anyone aware of an implementation of NQS (Network Queue Service) 
on top of KNET for MVS or IBM's MVS TCP/IP product?

Thanks in advance.



Patrick D. Heisinger
W126/3062182
McDonnell Douglas
P. O. Box 516
St. Louis, MO 63166

(314) 232-6349

heisinger@mdcgwy.mdc.com

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 91 14:20:43 GMT
From:      poorman@convex.com (Peter W. Poorman)
To:        comp.protocols.tcp-ip
Subject:   Re: Programming C with TCP/IP

The best book for learning TCP/IP-on-UNIX programming that I have seen
is "UNIX Network Programming" by W. Richard Stevens.  (Prentice Hall, 1990,
ISBN 0-13-949876-1.)  Very lucid explainations, plus plenty of C source code.
Includes full implementations of clients and servers.

--Pete Poorman
  poorman@convex.com

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 91 14:36:53 GMT
From:      tcwan@umiami.ir.miami.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Programming C with TCP/IP

In article <1991Aug21.011642.9491@socrates.umd.edu>, coates@UC780.UMD.EDU writes:
> In article <87966@eerie.acsu.Buffalo.EDU>, visjanap@ubvmsb.cc.buffalo.edu
> (Jan A. Pisanczyn, SUCB) writes:
>>Posting this for a friend who does not have net access at this time, please
>>reply to him at his e-mail address listed at the end of the message, thanks!
>>
>>Hello!
>>
>>  I am taking an independent study next semester "advanced C", and will be
>>writing an application program in C using TCP/IP.  My intents are to write
>>a client and a server obviously...  I have done research papers on TCP/IP
>>so I understand the basic concepts behind the protocol suite, however, I
>>have no clue as how to write a client and server using the protocol.  I am
>>looking for:
>>
>>   *Example programs in C
>>   *Names of books I could buy
>>   *Places on the network I could access with FTP with examples
>>      OR documentation...
>>
>>Please reply if you can help out with any of the above... Thanks in advance!
>>
>>Rob Lizak Jr.
>>
>>lizak98@snybufva.bitnet   <= E-Mail address...
> 
> Please post replies, Thanks!
> ---
> coates@uc780.umd.edu


I just discovered a book by W. Richard Stevens, "UNIX Network Programming",
which deals with BSD sockets and SysV TLI/streams (not in as much detail).
Seems to be pretty informative, includes C source for servers and clients
using BSD sockets, etc. Coverage of SysV is a little scant, possibly as
the book was published in 1990. SysVR4 is only mentioned in the Intro, and
examples come from SVR3.

The ISBN is 0-13-949876-1, published by Prentice Hall.
I'm still reading through the book, so I'm not able to give a thorough
impression. Definitely a good intro to Unix networking, though.

Hope this helps.
I'm also interested in other references, etc.

On a related question, I can't seem to find any documentation on how to
set up STREAMs modules for TCP/IP in SysV. I am using an Apollo running 
Domain/OS 10.2, and all the docs, (programming with SysV Streams, etc)
assumes the existence of the interface, without any description of how
to install them. Does anyone have any ideas?

T.C. Wan
Grad. Student, Dept. of ECE,
Univ. of Miami, FL

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 91 15:09:29 GMT
From:      revell@uunet.uu.net (James R Revell Jr)
To:        comp.protocols.tcp-ip
Subject:   Re: Programming C with TCP/IP

In article <poorman.682784443@convex.convex.com> poorman@convex.com (Peter W. Poorman) writes:
} The best book for learning TCP/IP-on-UNIX programming that I have seen
} is "UNIX Network Programming" by W. Richard Stevens.

Sources from the book are in ftp.uu.net:/published/stevens.netprog.tar.Z
-- 
James Revell   sr uunet postmaster   <revell@uunet.uu.net>   /8^{~

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 91 16:21:35 GMT
From:      lars@spike.cmc.com (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Transport Protocols for Operating Environment platforms

Dan Pezely wrote in comp.dcom.telecom:

> For Tele-presence/Operating Environment platforms, we need a rugged
> transport protocol like in the IP suite since we don't know all of the
> network types we'll be running on.  That is, we would like one
> transport protocol for LANs and WANs at a wide range of speeds and
> signal-to-noise ratios.

To which I replied:

> I would suggest that you implement TCP and IP as per the RFC's;
> NO CHANGES. What makes you think you might need to change it ?

And Dan countered:

> We need more than just connection-oriented and straight datagrams; we'd
> like something which is semi-reliable and gives up after a few tries--
> fewer than with TCP.  However, we don't know exactly how many tries to give
> up after, and with newer CPUs and networks, the params may change.
 
> We will, of course, use UDP/IP for its header info for compatibility, but
> some of the organizations funding our lab are willing to run any protocol
> developed for our projects-- protocols which would probably be developed
> jointly with another lab or school.
 
>  Also, IP is being used on the high speed nets, but with gigabit nets, I
>  understand that the ID field can get wrapped around while some packets are
> still traveling from coast-to-coast.  Some of our projects will definately
>  put such things to the test (when, I don't know).

And here I (Lars) speak again:

I am glad to hear that you are willing to use IP; at least this lets
you route through other people's networks, and through local network
built with off-the-shelf components into your (monitoring?) systems.

As to your specific list of issues:

(1) The point at which a TCP implementation gives up and resets the
    connection is an implementation issue, not a protocol issue. You
    could make it tunable and still stay TCP compatible/interoperable.
(2) If you need a "soft reset" capability to allow data loss to be
    recognized without breaking the connection (X.25-like) then you do have
    a requirement that TCP cannot handle.
(3) If you have more than 2**32 bytes in flight, you do have a sequence
    number wrap-around problem. I respectfully submit, though, that if
    you expect to carry gigabits per second over a SINGLE connection, you
    will have MANY technical obstacles to overcome, and you had better have
    beaucoup funding.


>> Thank you!  Does this criteria alter your opinion at all?

Actually, Rockwell is probably fairly indifferent ... but your note
sounded very much like the usual calls for "reliable datagram
protocols" which usualy turn out to require more overhead and work
less well than TCP. In fact the biggest shortcoming of TCP for most
applications that claim to need to invent another protocol, is the
lack of record boundaries. And these can usually be inserted by
prefixing each record with a byte count, and sending the last buffer
of the record with a PUSH bit.

If you need to get something operational with two years, I still think
TCP is your best bet. If you have funding for long-term research, you
could take a look at XTP, and if that doesn't work for you either, you
could start an IETF working group towards a "super-TCP" with the extra
features that you need.

> ps - I'd like to post this to the list of newsgroups which the
> moderator of comp.dcom.telecom forgot to cross-post to:
> comp.protocols.misc, comp.protocols.tcp-ip, comp.protocol.iso,
> comp.dcom.lan, and comp.dcom.telecom
> is this ok with you?

I personally have no objection, but be forewarned, that as a matter of
editorial policy, TELECOM does not accept crosspostings.  In my
opinion, the "right" place for this discussion is on the TCP-IP
mailing list, also seen as comp.protocols.tcp-ip. Thus, I have cc'd
this to both TELECOM and TCP-IP.

Lars Poulsen, SMTS Software Engineer   CMC Rockwell  lars@CMC.COM
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 91 17:27:10 GMT
From:      Mark_McFadyen@mindlink.bc.ca (Mark McFadyen)
To:        comp.protocols.tcp-ip
Subject:   Beame and Whiteside PC-NFS

Does anyone have any experience with setting up B&W PC-NFS?
We have the NFS drive working fine, but we cannot seem to be able
to link a local device (ie LPT3) to a remote printer.  The command
we are using (trying to use) is:

   NET LINK LPT3 \hostname\HPJET
where HPJET is defined in the /dev/printcap file.
This gives us a "Invalid remote device." error message and
refuses to link.

Does anyone have any suggestions?
Or is my PRINTCAP file setup wrong?  What is the format?
Thanks.
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
I could be the Walrus.  It still wouldn't change the fact
that I have to bum rides off people.                 - Ferris.
MRM.

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 91 21:25:24 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: pc-nfs


    We are trying to set up a class room of IBM LEO ie PS2/55 machines
    packaged with a modified Western Digital Ethernet board.
    
    1) is there a packet driver for this IBM/wd ether board?

They changed the Microchannel ID value in the version IBM OEM'ed, so any
drivers which use the ID value to obtain the board's POS configuration
(instead of making the user type it twice) need to try all four possible
values.  Our WD8003 kernel does this since v2.05...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 91 22:42:48 GMT
From:      fillmore@EMR.CA (Bob Fillmore 992-2832)
To:        comp.protocols.tcp-ip
Subject:   unreliable ping with PC-NFS

A client just reported to me a strange problem with PC-NFS:
using the ping comand supplied with that package, he can ping
some hosts reliably, but ping replies "host not responding"
for a couple of others.  When he goes to those hosts and pings back
in the other direction all is OK.  Also, Telnet and FTP work OK
from PC-NFS to any host.

Does anyone know why this is happening?
-- 
Bob Fillmore, Systems Software & Communications    email: fillmore@emr.ca
  Information Technology Branch,                   BIX:   bfillmore      
  Energy, Mines, & Resources Canada                Voice: (613) 992-2832
  588 Booth St., Ottawa, Ontario, Canada  K1A 0E4  FAX:   (613) 996-2953    

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 91 01:21:06 GMT
From:      almquist@JESSICA.STANFORD.EDU ("Philip Almquist")
To:        comp.protocols.tcp-ip
Subject:   Re: What's your IP Time to Live?

Bob,
	The official recommended value for IP Time-to-Live can always be
found in the Assigned Numbers RFC.  The current version of that document,
RFC-1060, recommends a TTL of 32.
							Philip

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 91 06:36:48 GMT
From:      j.onions@XTEL.CO.UK (Julian Onions)
To:        comp.protocols.tcp-ip
Subject:   Re: Finger server as a requirement for all Internet hosts


> In favor for the world wide electronic directory I must argue against Henry,
> and make the folowing statement instead.
> 
>   In the near future the correct answer will hopefully be: Look him up
>   in "the directory" (read X.500).
> 
> This have the potential to work better. For example, if he is on
> vacation he will not answer his phone. Also, in the directory there
> could, possibly, be included information on how often he reads his
> mail.

One of the attibutes of a person in the X.500 schema is
preferredDeliveryMethod, which will tell you how the person prefers to
have their messages arrive. It is an ordered sequence of possibilities
that is made up of
     ANY     - obvious
     MHS     - electronic mail to me and you
     PHYSICAL- postal mail
     TELEX   - do people still use this?
     TELETEX - someone must use this but I have no idea who...
     G3FAX   - everyone uses this
     G4FAX   - everyone wants to use this
     IA5     - I don't quite no what this means (strict translation is
	       "ascii")
     VIDEOTEX- call 'em up on the video phone... oh, don't you have one?
     TELEPHONE work this one out yourself.

So, IF people make sensible use of this attribute you can take a good
guess at how they want to be contacted. (I guess there are a couple of
missing ones such as 
     DONT - I don't want to talk to anyone, I'm a recluse; or
	    alterntively "if you have to ask, don't bother".
     INPERSON - make an appointment with my secretary and we'll "do lunch"
)

Julian.

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 91 09:58:00 GMT
From:      wolf@grasp1.univ-lyon1.fr (Christophe Wolfhugel)
To:        comp.mail.sendmail,comp.protocols.tcp-ip
Subject:   Address / protocol family (sendmail SVR4)

[not sure whether this problem is sendmail specific or not].
I'm trying to use the tcp mailer of a SVR4 sendmail. The mail seems to be
correctly interpreted and when it's time to deliver it over SMTP,
sendmail indicates  following error:

(sent) 1000ad50 1 050 wolf@itesec... Connecting to itecom via ether...
Trying 192.70.106.1... addr= c0466a01 port= 25 family=2 zero=0
Address family not supported by protocol family
(send) 1000ad50 1 554 wolf@itesec... Service unavailable: Address family not supported by protocol family
wolf@itesec... Service unavailable: Address family not supported by protocol family
(sent) 1000ad50 1 554 wolf@itesec... Service unavailable: Address family not supported by protocol family
(send) 1000ad50 1 050 Saving message in //dead.letter

I have absolutely no idea where this error could come from. When I manually
telnet to itecom everything goes fine. Any suggestion?

Chris

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 91 12:24:21 GMT
From:      koelman@issun3.stc.nl (Ton Koelman)
To:        comp.protocols.tcp-ip
Subject:   cisco X.25, suspected bug


From koelman Wed Aug 14 16:44:53 1991
Return-Path: <koelman>
Received: by comsun9.stc.nl (4.1/SMI-4.1)
	id AA00212; Wed, 14 Aug 91 16:44:50 +0100
Date: Wed, 14 Aug 91 16:44:50 +0100
From: koelman (Ton Koelman)
Message-Id: <9108141544.AA00212@comsun9.stc.nl>
To: customer-service%cisco.com@hp4nl.nluug.nl
Subject: suspected bug: clearing of non IP X.25 VCs 
Cc: gerrits@issun3, koelman, robinson@issun3
Status: RO


Hello,

We're setting up an X.25 service across an AGS+ and a CGS (release 8.2)
connected with a 64 kbit/s PPP serial line. A 'pure' (i.e. not using IP) X.25 terminal is connected to each of the routers. When setting up VCs between the X.25 terminals we experience unexpected clearing by the routers with the diagnostics 0x30 (timer expired) on one side and 0x77 (International Routing Problem) on the other side. 

	We have strong suspicion that this is caused by the X.25 idle
timeout used by IP because by disabling that (x25 idle 0) the problem
disappears. This is however costly because the VCs used by IP (which we also
have) stay up indefinitely increasing the X.25 charges from our local PTT...

	The fundamental problem seems to be that the X.25 idle timeout
function is associated with the interface and therefore, incorrectly also operates on VCs that do not carry IP. This must be a known bug because
the X.25 service is not of much use this way.

	If possible could you please confirm our findings and inform us about
potential workarounds....

Regards,

Ton Koelman    koelman@stc.nl
SHAPE Technical Centre
The Netherlands

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 91 13:37:37 GMT
From:      gary@sci34hub.sci.com (Gary Heston)
To:        comp.protocols.tcp-ip
Subject:   Re: IP source code request

In article <1417@prlhp1.prl.philips.co.uk> cattelld@prlhp1.UUCP (David Cattell) writes:
     
>    Has anyone out there got or know where I can get the source code for an 
>    IP gateway, preferably in C and for a PC ? 

Do you mean a real gateway, that interfaces between a domain and an 
internet, or something along the lines of a router or bridge?
    
>    I need to be able to connect the Ethernet side of the PC to some serial
>    lines probably using a intelligent multiple line card like a Digiboard.
>    The PC needs to be able to gateway UDP/IP packets to/from the Ethernet
>    down the serial lines (possibly PSTN connections) from/to remote UDP/IP 
>    users.  

Please clarify--does this code need to think about what packets go
where, or does it simply repeat everything in each direction? If no
intelligence is required, then something like PCBridge should work
fine. It'll bridge between ethernet and serial, although you may need to
work on the serial interface, since it expects one standard COM port
instead of many. If you need to do routing, perhaps a pre-license copy
of PCRoute would help. Both are copyrighted, but available. Note that I
specified the pre-license version of PCRoute; NWU made some licensing
agreement with Lanport for a commercialized version and changed the
copyright notice on the later versions back around February to require
licensing. Don't get that version. (The agreement was made without even
mentioning it to the author, Vance Morrison; he found out when someone
emailed him asking about the change. We can expect a posting from someone
at NWU that believes they can make retroactive copywright changes.)

>    Unfortunately, I have to use email addresses to get the code as I can't 
>    do an anonymous FTP from this site.

In the same situation myself--alleviated somewhat by a direct link to
uunet. They have both packages there.


-- 
Gary Heston   System Mismanager and technoflunky   uunet!sci34hub!gary or
My opinions, not theirs.    SCI Systems, Inc.       gary@sci34hub.sci.com
Become a pheresis donor. Loan your blood to the Red Cross for a couple
of hours. They, and cancer patients, will appreciate it.

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 91 16:21:54 GMT
From:      rpcfod@nimbus@UUNET.UU.NET (Robert Patt-Corner)
To:        comp.protocols.tcp-ip
Subject:   SLIP and data compress/correction

We're having some problems getting slip links to work on a v.32bis/v.42bis
modem pair using anything other than data compression and correction turned
off.  Is there any inherent thing in the SLIP protocol that prevents this?

Result with compression or correction is checksum errors on sender and/or
receiver.

We're testing with KA9Q.

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 91 17:11:26 GMT
From:      lars@spectrum.cmc.com (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP@NIC.DDN.MIL vs USENET's "comp.protocols.tcp-ip"

I originally submitted the message just before this one to
TCP-IP@NIC.DDN.MIL, and it has not been returned as undeliverable, but
after 24 hours, it has not shown up on comp.protocols.tcp-ip yet.

It appears that the mailing list has become separated from the newsgroup,
perhaps intentionally. If so, when did that happen ?

Or is NIC in bad shape ?
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 91 17:19:50 GMT
From:      blknowle@aragorn.jdssc.dca.mil (Brad L. Knowles)
To:        comp.protocols.tcp-ip
Subject:   Request assistance with /etc/sendmail.cf configuration...

Folks,

    I recently posted a question to the Sun-Managers mailing list that I
have since decided is more appropriate here.

    I have a fairly new Sun SPARCstation 2/GX, with 16M RAM, 32M swap,
207M Quantum internal hard drive, and 669M Seagate external hard drive
that I have been trying to set up as the primary mailhost for the domain
JDSSC.DCA.MIL (our previous mailhost bit the dust, and the guy that set it
up no longer works on that project).

    I took the plain vanilla /usr/lib/sendmail.main.cf and copied it to
/etc/sendmail.cf, and made two changes -- I defined the "m" macro to be
JDSSC.DCA.MIL, and changed the primary Mailer to be "ddn", as opposed to
"smartuucp" (all of this, as per the Sun documentation).  The primary
relay mailhost was set to be ddn-gateway, which I have not changed, but I
defined ddn-gateway to be an alias for NIC.DDN.MIL in /etc/hosts on the
NIS Master Server (and thus, for our entire NIS domain).  This proved to
be unreliable, so I changed it to be uunet.uu.net, but they soon stopped
accepting SMTP connections from me.

    Obviously, I am doing something wrong, because when I mentioned my
plight on Sun-Managers, I got two responses.  One of them said (in effect)
"With a properly set up DNS, you should be able to deliver mail directly,
and not have to foist it off on to some unsuspecting host."  The other
said (in effect) "We made some minor changes to our /etc/sendmail.cf file,
commenting out a few things that forward mail to a mailhost, when we want
this particular machine to BE the mailhost."

    Now, I think I set up the DNS properly on this machine, but something
was mentioned about "hostresorder" that could be used to force the
resolver to resolve addresses in a specific order -- would some of you out
there be kind enough to help me set up my hostresorder to be correct?
Also, if there are any "tricks" to setting up /etc/sendmail.cf on a
primary mailhost, would you be kind enough to share some of them with me?
I guess my biggest problem is that the documentation I have available to
me just doesn't give me enough information, and that without
documentation, the only way you know if things have been set up properly
is to have already done it (nice little Catch-22, huh?).

    I don't suppose this problem is somewhere in the FAQ list?  Do we even
have an official FAQ list?

    I would be happy to RTFM, if someone would be kind enough to point me
at the right one (I've read *all* of the appropriate SunOS 4.1.1B
documentation I can find, but may have missed something).

    BTW, I don't know if this helps, but recently, any time I ping a host
not directly on Milnet (like LCS.MIT.EDU, NS.NASA.GOV, UUNET.UU.NET), all
I get is an error bounced back that says:

ICMP Host Unreachable from gateway GW.NIC.DDN.MIL (26.31.0.73)
 for icmp from aragorn (137.130.4.4) to XX.LCS.MIT.EDU (18.26.0.36)

Or something along these lines (I once got a message to this effect back
from moffett-fld-mb.ddn.mil when I tried to ping 192.52.195.10, another
address for NS.NASA.GOV).  I don't know if GW.NIC.DDN.MIL is down, if they
are having problems with their NSFnet connection, or what, but I do know
that I seem to be completely disconnected from anything other than Milnet,
as a result (fortunately for me, the TCP-IP Mailing List is hosted from
NISC.NIC.DDN.MIL).  I understand from Peter Welch (pjw@USNA.NAVY.MIL) that
the two Milnet-Internet gateways get *extremely* congested during the day,
but this shouldn't affect my inbound mail at night, should it?  (I got
only two mail messages last night, and with the mailing lists I am on, 20
to 30 overnight is much more common)

    Oh, BTW, don't ask me to use traceroute to figure out what's
going on -- I don't have it yet.  My lack of Internet connectivity is
greatly hindering my ability to get it, too!

    I hope my tone of "voice" hasn't offended you, I'm just getting a
little desperate right now!

 Please respond via e-mail.  I will summarize and re-post, if appropriate.
 _________________________________________________________________________
| Brad Knowles                 | Internet:  blknowle@frodo.jdssc.dca.mil  |
| DISA/DSSO/JNSL               | Ph: (703) 693-5849   Fax: (703) 693-7329 |
| The Pentagon, Room BE685     |============== DSN: 223-5849 =============|
| Washington, D.C.  20301-7010 | Speaking from, not necessarily for DISA! |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 91 17:20:44 GMT
From:      andy@cs.caltech.edu (Andy Fyfe)
To:        comp.sys.3b1,comp.protocols.tcp-ip
Subject:   Re: Printing out 'ipctut' from osu archive

In article <1991Aug20.033536.19016@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (Don Nichols (DoN.)) writes:
>>>In article <260@zebra.UUCP> vern@zebra.UUCP (Vernon C. Hoxie) writes:
>>>>
>>>->I recently downloaded a file from the AT&T-7300/3B1 archive at osu-cis
>>>->which is called 'ipctut'.  It is a tutorial originally issued by the
>>>->Regents of the University of California.  It contains no programming
>>>->code but does have a Makefile to be used in printing out the document.
>	groff compiles and runs on the 3b1, and includes the '-me' macro
>package.  It is available on osu-cis (I am assured.)

"groff -Txxx -t -me tutor.me" (where xxx is ascii, dvi or ps) works
fine.  Groff binaries for the 3b1 are available for anonymous ftp on
csvax.cs.caltech.edu:/pub/3b1/.  If they aren't yet on OSU, I'll copy
the file to the Temp directory there.

Andy Fyfe					andy@cs.caltech.edu

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 91 03:52:21 GMT
From:      mrc@Tomobiki-Cho.uucp (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP and data compress/correction

In article <2026@nimbus.UUCP> rpcfod@nimbus@UUNET.UU.NET (Robert Patt-Corner) writes:
>We're having some problems getting slip links to work on a v.32bis/v.42bis
>modem pair using anything other than data compression and correction turned
>off.  Is there any inherent thing in the SLIP protocol that prevents this?

I use SLIP on a V.32/V.42bis modem pair with no problems.  I get about
20KB with FTP.  I doubt there is anything with V.32bis that would
change this; I hope not since I'm upgrading to V.32bis very soon!

>Result with compression or correction is checksum errors on sender and/or
>receiver.

One thing to check is to make sure you have flow control set up
properly.  I'll be willing to bet this is your problem.  You should
*not* be using software flow control (XON/XOFF) in any form.  Most
computers can not handle a steady stream of 38,400 baud data on their
serial port without some flow control, so you need to have hardware
flow control (CTS/RTS) set up.

For more information, check the manuals for your modem and for your
serial port.
 -+-+-   | -++-  --|--    /__ Mark ("Gaijin") Crispin "Gaijin!  Gaijin!"
+-|-|-+ -+-++++  +-|-+   /  / R90/6 pilot; DoD #0105  "Chigau. Omae ha gaijin."
+-+-+-+  |\||||  |===|  /  /  Atheist & Proud         "Iie, boku ha nihonjin."
 --|--  /| |/\| -+===+-   /\  (206) 842-2385/543-5762 "Souka. Yappai gaijin!"
  /|\    | |__|  /   \   /  \ FAX: (206) 543-3909
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 91 07:18:46 GMT
From:      gagrawal@sparc18.cs.tamu.edu (Gopal Agrawal)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   A clarification needed on FDDI's Protocol.


-- 
Hi everybody.

I had certain doubts on FDDI's protocol. I couldn't decipher any 
answers to these from the papers of Marjory Johnson, McCool, 
F. Ross etc. Could some one help me out ?


Q1)  A station on receiving a token early transmits synchronous 
and then asynchronous messages for THT time - right ? Suppose 
Initially there are no synchronous messages and the station goes 
ahead to transmit its Asynchronous messages.  Synchronous messages 
come at some time during the transmission of the asynchronous 
messages. Now will the transmission of Asynchronous messages be 
prempted by the higher priority synchronous messages ? Or is it 
that the synchronous messages will not be transmitted.


Q2)  A node recives a token LATE.  It wishes to send synchronous 
messages for its allocated bandwidth 'B'. But the amount of time 
left before the TRT expires (lets call it 'A') is less than B.  
So does the node transmit synchronous messages for time A or B ?



Please e-mail / reply rather than posting answer.  

Thanks in advance,

--------------------------------------------------------------------------------
         ______                 _
	/ ____/ ___ ____  ___  | |          |\/\/\/|  Life is complex.
	| |  __/ _ \| _ \/ _ \ | |          |      |    It has both
	| |_| ||(_)||(_)||(_)|_| |          |  \  /|       real           
 _____	\_____/\___/|  _/\____/|_|    _     | (o)(o)       and           
/  _  \ ___  ___  __| | _    _  ___  | |    C      _)   imaginary
| (_) |/ _ \/ __\/ _ \|| |  | |/ _ \ | |     | \___|      parts.
| ___ ||(_)|| |  |(_)|_| |/\| ||(_)|_| |     |   /
|_| |_|\__ ||_|  \____/\__/\__/\____/|_|    /____\ 
       __| |                               /      \
       \___/ E-MAIL : gagrawal@cs.tamu.edu	All Std. disclaimers apply.
--------------------------------------------------------------------------------

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 91 10:18:45 GMT
From:      REDREC@UNAMVM1.BITNET (Cristina Casimiro)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS and UID mapping


   Peter :
   It exists in CRAY machines .
   In UNICOS 6.0 there is an ID mapping that can help you for solve your
problem . It is part of the UNICOS NFS and permits the use of NFS in
several administratives environments . There are two types of ID maps :
user ID maps and group ID maps .
   Also I think there is a similar facility in Sun Microsystems Network
   It maybe help you .

   Cristina Casimiro
   redrec@unamvm1.dgsca.unam.mx

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 91 15:09:26 GMT
From:      mcneill@eplrx7.uucp (Keith McNeill)
To:        comp.protocols.tcp-ip
Subject:   routing problem from hell

I have a routing problem. 

The site on which I work has a large bridged ethernet with many hosts on it.

A class B address has been assigned to the site (call it XXX.YYY.0.0).  The
network owners have assigned each building a subnet number.  Hosts that sit
on the large bridged ethernet do no use subnetting (i.e. subnet mask
255.255.0.0).  

My network is a separate ethernet.  My network was assigned subnet 252 within
the XXX.YYY.0.0 network.  All hosts on my ethernet, including both interfaces
on the router, use a subnet mask of 255.255.255.0.  My router is a Sun
Workstation running proxy arp.  Proxy arp is used to enable communication
between the subnetted (my network) and non-subnetted (everybody else)
portion of the XXX.YYY.0.0 network.

Communications within the XXX.YYY.0.0 network work perfectly.  The problem
occurs when another network is added, a class C, (call it AAA.BBB.CCC.0).
My router cannot add a route to the new AAA.BBB.CCC.0.  

confused...how about a map...


Topology map:

             My Network
           XXX.YYY.252.0
      --------------------------------
              |
              |     IP addr:  XXX.YYY.252.10
              |
              | Sun Workstation/router running proxyarpd
              |     
              |     IP addr:  XXX.YYY.78.1
              |                                   hundreds of nodes....
      -----------------------------------------------------------------
       Large bridged ethernet         |
            XXX.YYY.0.0               |    IP Addr: XXX.YYY.10.1
                                      |
                                      |  IP Router to AAA.BBB.CCC.0 network
                                      |
                                      |    IP Addr: AAA.BBB.CCC.3
                                      |
      --------------------------------------------
                         AAA.BBB.CCC.0 network

     

On my router I have added a default route pointing to the 78 subnet interface.

netstat -r on my router:

Routing tables
Destination          Gateway              Flags    Refcnt Use        Interface
127.0.0.1            127.0.0.1            UH       3      19989      lo0
default              XXX.YYY.78.1         U        5      2295226    ie3
XXX.YYY.252.0        XXX.YYY.252.10       U        78     1681671    ie0
XXX.YYY.78.0         XXX.YYY.78.1         U        0      4851       ie3

ifconfig -a on my router:

ie0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
        inet XXX.YYY.252.10 netmask ffffff00 broadcast XXX.YYY.252.255
ie3: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
        inet XXX.YYY.78.1 netmask ffffff00 broadcast XXX.YYY.78.255
lo0: flags=49<UP,LOOPBACK,RUNNING>
        inet 127.0.0.1 netmask ff000000


The root of the problem is that my router sits on subnet 78 and the router
to the AAA.BBB.CCC.0 network sits on subnet 10.  When I try to add a route
on my router, this is what happens:

sun-router>> route add net AAA.BBB.CCC.0 XXX.YYY.10.1 1 add net
AAA.BBB.CCC.0: gateway XXX.YYY.10.1: Network is unreachable

My router is confused because subnet 78 & 10 (and many others) are on the
same physical wire.  Now my router can ping/telnet/ftp to XXX.YYY.10.1.  My
router just won't let me add a route through it to AAA.BBB.CCC.0.

Non subnetted machines sitting on the bridged ethernet have no problem
communicating with the AAA.BBB.CCC.0 network.

This leads to 2 questions:

1)	Is my router (i.e. the Sun IP code) acting correctly.

2)	One way to solve this would be to change the subnet mask on the 78
	side of my router to 255.255.0.0.  Can the Sun IP code deal with a
	machine with 2 different subnet masks for the same class B network.

I've asked both of these questions with sun support and have yet to receive
an answer.


Any help is greatly appreciated....

Keith

-- 
    Keith McNeill                 |    Du Pont Company
    eplrx7!mcneill@uunet.uu.net   |    Engineering Physics Laboratory
    (302) 695-9353/7395           |    P.O. Box 80357
                                  |    Wilmington, Delaware 19880-0357
--
The UUCP Mailer

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 91 15:37:39 GMT
From:      pv0618@hertz.njit.edu (Paranjothi Varadarajan)
To:        comp.protocols.tcp-ip
Subject:   tn3270 bugs ...


Posting for a friend who do not have access to net.

I am working on tn3270 (4.1.1) on an hp-ux and having a problem, which
to me looks like a bug in telnet code  used to build tn3270.

I would be more than happy to give details .

Also if any body out there knows of bugs in tn3270 code , please let me
know...
thanks !

you can reply here/ post on the net or call Kamlesh Shah at (919) 481
7877.

Thanks !

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 91 17:16:24 GMT
From:      jmb@ideas.com (Jonathan M. Bresler)
To:        comp.protocols.tcp-ip
Subject:   IPI3 (a protocol ?)


I'm looking for information and references to further details on
"IPI3".  Please respond by direct email.  I will summarize if requested.

If someone knows of a better mail group for posting this note, please
tell me.

Jon Bresler
jmb@ideas.com

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 91 19:13:55 GMT
From:      peter@plato.austin.ibm.com (Peter Jeffe 512.838.4019)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   .netrc, .rhosts, and FQDNs

I'm sure this has already been discussed, but obviously not
resolved.  It seems there has always been an inconsistency in the
way that hostnames are treated in the .rhosts, hosts.equiv, and
.netrc files, and depending on the application.

This is how it stands in BSD reno:

  A. compares using hostname as supplied by user/application
  B. compares using hostname from gethostbyname() of supplied host
  C. adds local domain to non-FQDN hostname from file
  D. does case-insensitive compare

                                 A  B  C  D
                                 ----------
ruserok (.rhosts, hosts.equiv)   Y  N  Y  Y
rexec (.netrc, env)              N  Y  N  N
ftp (.netrc)                     Y  Y  Y  Y

There may be other cases, but these are the ones I'm aware of.

I propose that:

  1. All of these mechanisms should act the same; even though
     .netrc is outgoing and the others are incoming, I can't see
     any reason to deal with them differently.

  2. They should obviously do case-insensitive comparisons, as per
     rfc 952.

  3. They should do a gethostbyname() on BOTH the supplied hostname
     and the one from the file; this will canonicalize it if using
     DNS and gather aliases if using a hosts file.

  4. They should compare the h_name of one with the h_name and
     h_aliases of the other.

I think this should satisfy everything, but there are probably
issues that I'm not seeing.  Any comments?

-- 
peter jeffe  ...cs.utexas.edu!ibmchs!ski.austin.ibm.com!peter

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 91 20:17:38 GMT
From:      ben@moncol.UUCP (Bennett L. Broder)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   What is the name of the packet driver for the NE2000


I know this is probably a simple question, but I am new to Novell hardware
and software.  I am trying to bring up NCSA telnet (a public domain tcp/ip
program for the pc) on some machines currently running Novell netware.
The machines have Novell NE2000 LAN cards, which according to the documentation
supplied with NCSA telnet, are supported via the packet driver.  What is the
name of the packet driver for the NE2000, and on what Novell disk would I
find it?

Thank you for any help you can render.

Ben Broder
uucp  ..princeton!moncol!ben
inet  moncol!ben@princeton.edu

-- 

Bennett Broder               Monmouth College
..princeton!moncol!ben       Computer Services
..tsdiag!moncol!ben          W. Long Branch, NJ 07764

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 91 21:29:45 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.mail.sendmail,comp.mail.uucp,news.admin,comp.protocols.tcp-ip
Subject:   Domain registration for e-mail?

I've been running in circles with NIC trying to figure out how to
register my system as an MX record on the network, so here I am
turning to USENET to figure this one out (sorry for the posting to
probably-inappropriate groups).

In order to prevent the usual problems associated with bang-style
addressing, I want Internet e-mail users to address people at my company
as user@kronos.com instead of kronos!user@eclectic.com or any of
about thirteen variants.  I have an AIX system connected to two
Internet systems via frequently-polled UUCP.

NIC tells me they don't handle MX records and refers me to my local
administrator.  The administrator of my Internet gateway system doesn't
know the process for doing this.  It makes NO logical sense to me that
NIC shouldn't be the entity to assign non-Internet domains.

To whom do I go to get an MX record registered in all Internet domain
name servers?  I want a top-level domain in the "com" namespace.  We
do not buy service from one of the big companies with experience in
this area (like UUNET).

Thanks,
-rich

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 91 01:20:50 GMT
From:      schoff@mail.psi.net ("Martin Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   (none)

There is a mailing list to discuss the NREN which is available at

nren-discuss@uu.psi.com

To be added the Internet standard of sending a request to

nren-discuss-request@uu.psi.com

Marty


>DATE:   Wed, 14 Aug 91 10:38:24 -0400
>FROM:   Chi Chu <chi@sparta.com>
>
>Subject: NREN
>
>Hey folks,
>	Can someone tell me what the NREN email address is?
>Thanks.
>
>Chi - SAIC
>

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 91 10:21:08 GMT
From:      asbjorns@stud.cs.uit.no
To:        comp.protocols.tcp-ip
Subject:   TCP/IP versus LAT

I believe that some time ago there was a discussion in this group on
whether TCP/IP was a good choice for handling terminals, in particular
compared to LAT.  If someone has kept a summary of this thread, could
you please mail it to me?  Or, failing that, could someone please
summarize the conclusions of the discussion.

asbjorns@stud.cs.uit.no  (Asbjoern Saetran).

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 91 14:01:54 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: What is the name of the packet driver for the NE2000

In article <6220@moncol.UUCP> ben@moncol.UUCP (Bennett L. Broder) writes:

   The machines have Novell NE2000 LAN cards, which according to the
   documentation supplied with NCSA telnet, are supported via the
   packet driver.  What is the name of the packet driver for the
   NE2000, and on what Novell disk would I find it?

I'm quite sure that Novell doesn't distribute any packet drivers.  Here's
how to get the Clarkson collection of packet drivers:

		The Clarkson packet driver collection

Availability

The Clarkson collection of packet drivers is available by FTP, by
archive-server, and by modem.  They come in two flavors -- executables
only (drivers.zip), and source+executables (driverss.zip).  All of the
following instructions apply to both drivers.zip and driverss.zip.

Mail:

I distribute the packet drivers on two 360K 5.25" disks, or a 720K
3.5" disk.  I charge a fee for the service of copying and mailing
these disks. You can send me a check for $20, or you can send me a
purchse order and I will bill you for $22.  NY residents add 7% sales
tax, overseas orders add $3 for shipping.  If you send a check,
please be sure it is in US dollars -- the bank charges me $15 to
convert checks drawn in foreign currencies.

	Russell Nelson
	11 Grant St.
	Potsdam, NY 13676

FTP:

sun.soe.clarkson.edu:/pub/ka9q/drivers.zip
grape.ecs.clarkson.edu:/pub/msdos/tcpip/drivers.zip

E-mail:

Send mail to archive-server@sun.soe.clarkson.edu and put the following
command as the body of your message:
	help
This will send you a help message.  Reading this help message will tell
you how to fetch the packet drivers.

Modem:

Call the Clarkson Heath User's Group's BBS: (315)268-6667, 8N1,
1200/2400 Baud, 24 hours.  You may need to press break, or simulate
it using several nulls.  Download pub/msdos/tcpip/drivers.zip.

--
--russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 91 14:26:43 GMT
From:      ken@achilles.coral.com (Ken Benstead)
To:        comp.protocols.tcp-ip
Subject:   Decnet IV Implementation

Hello World,
 
   I known this is probably not the "right place" to ask this question 
but I'm not sure where "right place" would be, so here goes anyway.  Does
anyone know of a Decnet IV router implementation suitable for porting 
(ie includes source code)?  A public domain implementation would be
nice but any information (including commercial packages) would be much
appreciated.  Please E-Mail reponses directly to me.

Thanks in anticipation,
Ken Benstead
kbenstead@coral.com

PS: I have heard a rumor that the University of Texas has an implementation.
    Is there any truth to this?

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 91 15:00:18 GMT
From:      jcurran@NNSC.NSF.NET (John Curran)
To:        comp.protocols.tcp-ip
Subject:   Re: NREN (looking for email address)

] Hey folks,
] 	Can someone tell me what the NREN email address is?
] Thanks.

The NREN hasn't evolved far enough to accept mail "in general".  
The organizations participating in the planning activites are well 
represented on this list (tcp-ip), and also on the com-priv mailing
list.  There are also several study groups organized by the NSF to 
look at particular issues in the NREN architecture.

Until the NREN is fully realized, you might want to send mail to the 
information services groups of the current NSFNET (which serves as 
the Interim NREN).  The contacts are:

NSF Network Service Center  (NNSC)
    nnsc@nnsc.nsf.net

Merit Information Services
    nsfnet-info@merit.edu

They will be able to answer or refer you to the correct people depending
on the question.

/John

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 91 17:27:07 GMT
From:      faunt@CISCO.COM (Doug Faunt N6TQS 415-688-8269)
To:        comp.protocols.tcp-ip
Subject:   Finger server as a requirement for all Internet hosts

My feeling is that "finger" is an invasion of privacy.  Why should
anyone on the internet be able to look and see what my habits are?
There's a fair amount of obfucation in some finger services these
days, but they still give away more information then I'm happy with.

What would make me feel much more comfortable with finger was a finger
server that defaulted to no information (even their existence), but
would allow the user to control what information was given about them.
Is there such readily and easily available?

thanx, doug

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 91 18:16:31 GMT
From:      dboyes@is.rice.edu (David E Boyes)
To:        comp.protocols.tcp-ip
Subject:   Re: Finger server as a requirement for all Internet hosts

In article <9108150145.AA03269@gaak.LCS.MIT.EDU> MAP@LCS.MIT.EDU (Michael A. Patton) writes:
>
>What I do in this case is send mail to Postmaster at that site and ask
>them.  I usually include something along the lines, "Because your site
>doesn't run a finger server, I am required to waste your time and mine
>by sending this request for an address to you.  You should consider
>running such a server to cut down on the amount of time you spend
>answering such queries."

You assume 2 things:

1) all hosts connected to the Internet are capble of supporting a
  "finger" service and can store the necessary information to
  respond to such queries with impunity, and

2) user identification information is considered publically
   available information.

Neither assumption is universally valid, and while it's annoying
to have to trouble a human to do the lookups, it's better to have
a fully reliable service than one that cannot be authoritative.

> Michael A. Patton, Network Manager
> MIT Laboratory for Computer Science
>P.S.  On the other hand, even though MIT does run such a service, it's
>amazing how many people don't think to try and just send to Postmaster
>anyway.  At least having the service makes it easy for me to reply.

Sending mail to postmaster@<site> is supposed to be guaranteed to
reach a knowledgeable human responsible for the mail system,
according to custom and RFC. It amazes me how many sites use
postmaster@site as the mail-daemon, or cause it to be a black
hole for problem reports.


--
David Boyes  
dboyes@rice.edu   |There is nothing true but silence and darkness.

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 91 00:14:36 GMT
From:      dalton@pine.circa.ufl.edu (DALTON)
To:        comp.protocols.tcp-ip
Subject:   NFS vendors, addresses or phones

Does anyone know the phone number or address for info about

PC/TCP Interdrive, ftp Software, Inc. or
Beame & Whitside's, B&W NFS?

Thanks,

Ron Dalton

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 91 02:30:34 GMT
From:      jholmes@mcb.UUCP (jim holmes)
To:        comp.mail.sendmail,comp.mail.uucp,news.admin,comp.protocols.tcp-ip
Subject:   Re: Domain registration for e-mail?

richb@kronos.com (Rich Braun) writes:

> To whom do I go to get an MX record registered in all Internet domain
> name servers?  I want a top-level domain in the "com" namespace.  We
> do not buy service from one of the big companies with experience in
> this area (like UUNET).
> 
> Thanks,
> -rich

uunet will do it for you anyway for $35. write to uunet!info
-jlh

**** Standard junk**** I don't work for uunet i'm just a customer.

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 91 04:35:33 GMT
From:      clewis@ferret.ocunix.on.ca (Chris Lewis)
To:        comp.sys.3b1,comp.protocols.tcp-ip
Subject:   Re: Printing out 'ipctut' from osu archive

Someone mentioned a problem printing ipctut using the -me macros
with psroff, when (I believe) the -me macros were borrowed
from another machine.  Please note that some C/A/T troffs has a slight
incompatibility with other troffs regarding the format of .if's and
associated \{\'s and this problem often hits when using a ditroff version
of -me with C/A/T troff.  This is noted in the psroff TROUBLE file, and
can be fixed by modifying the -me macros according to the instructions.
It's a fairly simple fix (text from the TROUBLE file):

ME macros don't seem to work:

    A friend noted:

    In order to make them useable, I had to modify them somewhat.  The
    problem was with the following syntax:

	.if t \
	\{
	.	zz
	.\}

    Our (Xenix) troff required the following instead:

	.if t \{\
	.	zz
	.\}

    This was required for all occurances of "\{".  It seems "\{" MUST
    terminate a line, and MUST be followed by a "\<NEWLINE>".  Even a ".\{"
    didn't help any.

This can be done with an ed, sed or perl script, but I don't
think there's that many to change.

-- 
Chris Lewis; UUCP: ...!{cunews,uunet,latour}!ecicrl!clewis;
DOMAIN: clewis@ferret.ocunix.on.ca; Phone: Canada 613 832-0541
Psroff info: psroff-request@ferret.ocunix.on.ca
Ferret mailing list: ferret-request@ferret.ocunix.on.ca

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 91 05:33:06 GMT
From:      dyer@spdcc.COM (Steve Dyer)
To:        comp.mail.sendmail,comp.mail.uucp,news.admin,comp.protocols.tcp-ip
Subject:   Re: Domain registration for e-mail?

In article <1991Aug23.212945.16789@kronos.com> richb%kronos.uucp@eclectic.com writes:
>It makes NO logical sense to me that
>NIC shouldn't be the entity to assign non-Internet domains.

The NIC will maintain name server records representing hosts which will
be authoritative for the kronos.com domain.  It's up to these hosts which
act as nameservers for kronos.com to contain whatever RR data is appropriate;
in your case, MX records.  Presumably, you will have negotiated this
function in advance with the administrators of the hosts acting as name
servers.

>To whom do I go to get an MX record registered in all Internet domain
>name servers?  I want a top-level domain in the "com" namespace.  We
>do not buy service from one of the big companies with experience in
>this area (like UUNET).

UUNET will gladly do all this for you for a small fee (< $50, I think)
and act as your nameserver if you like, and you don't even have to be
one of their UUCP customers.

Since spdcc.com is one of your two UUCP sites connected to the Internet,
and since I'd mentioned to you that I was already providing this exact
service to several other UUCP sites, I really don't know why you didn't
approach me with your questions before going ballistic and assuming that
the NIC was stonewalling you or somehow failing you.  What they said was
absolutely correct.

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
"Proletarii vcex stran, izvinite!" -- Anon.

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 91 15:46:23 GMT
From:      rwskubow@GRAND.WATERLOO.EDU (Rog Skubowius)
To:        comp.protocols.tcp-ip
Subject:   Removal from list

Please remove me from this distribution list.

Thankyou,

Roger Skubowius

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 91 19:06:13 GMT
From:      VANCE@TGV.COM (L. Stuart Vance)
To:        comp.protocols.tcp-ip
Subject:   Re:  connection between mac and vax

>I tried to connect to VAX by using NCSA Telnet 2.3 MacTCP.  "Sometimes" the
>cursor freezed during the connection and then, after a while, VAX kicked me
>out automatically.  "Sometimes" my mac crushed right after above situation.
>(screen freezed and no error massage)  But everytinging works well when I
>tried to connect to a unix machine.  I also tried to use NCSA Telnet 2.4 and
>it didn't help.  I have no idea how to fix the problem.  It looks like
>something wrong with the VAX.
>
>I am running 6.0.7 on SE/30 with Dove FastNet SE/30.  Does anyone have similar
>experiences?  I'd appreciate any suggestions.  Thanks in advance.

It might be a TELNET option negotiation problem between NCSA Telnet and the
VAX.  Does NCSA Telnet give you the ability to display TELNET options as they
are negotiated with the server system?  If so, that'll tell you at least if
it is an option problem.  Probably the best thing to do would be to get an
Ethernet protocol analyzer (or even a Sun with etherfind or a system with
TCPDUMP) and monitor the dialog between the Mac and the VAX.  Also, whose
IP software on the VAX are you running?  Have you tried contacting the vendor
directly to see if they know of any problems communicating with NCSA Telnet?

Regards,
-----Stuart

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 91 15:08:15 GMT
From:      prakash@beast.sme.siemens.com (Veera Prakash)
To:        comp.protocols.tcp-ip
Subject:   Removal


Please remove me from this mailing list.

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 91 15:50:47 GMT
From:      gmckee@cpqhou.uucp (George McKee)
To:        comp.protocols.tcp-ip,biz.sco.general
Subject:   SCO vs RFC1122 TCP urgent pointer

First the big question: how do you get a vendor to follow the standard rather
than some broken product(s), when the broken stuff works for their other
customers?

Here's the story:  Sybase's client-server system provides a dbcancel function
to stop the execution of a database query that you change your mind about
(in case you said "select * from everything" and you don't have all day).
They implement it using TCP urgent data; but RFC1122 fixed an off-by-one
error in the definition of the urgent pointer in RFC793.  This means that
an implementation of TCP according to the new spec won't interoperate with
an implementation that follows the old RFC if they use urgent data.  In fact,
the connection will generally hang irrecoverably.  This is ungood for
production work.
	At Compaq, we have an environment that induces us to use for our
database clients FTP software's PC/TCP, which precisely follows RFC1122.
But we also have a relation with SCO that leads us to use their dialect
of Unix on our servers, and their TCP/IP implementation is "mostly compliant"
to 1122, where "mostly" excludes TCP urgent data.  As a consequence, we can't
use any software that utilizes this feature of the protocol.
	SCO claims that they do this because "everybody else's" implementation
also follows the broken part of RFC793 (namely ATT SysVr4, SunOS, Sun PC/NFS,
ISC 386/ix, etc.).  They also say they don't intend to fix the problem until
about 3 versions from now, say in 1994.

Several questions are now in the air:
- are we going to be stuck on this for 3 years?
- is this off-by-one problem really so difficult that it takes 3 years to fix?
- what implementations of Unix do TCP urgent data the right way?
- are there any implementations on any platform that can do it both ways?

	- George

George McKee				gmckee@cpqhou.se.hou.compaq.com
Systems Programmer			uunet!cpqhou!gmckee
Information Management			Voice: 713 378 7991
Compaq Computer Corporation		Fax:   713 374 1740
P.O. Box 692000 M010301			disclaimer: facts are facts,
Houston, TX 77269-2000			Compaq is Compaq, my opinions are mine.
...and a fine how-de-do to anyone who can derive this from quantum mechanics.

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 91 17:55:42 GMT
From:      marcus@cpva.saic.com (Mark Jenkins, SAIC/CIR Network Services)
To:        comp.protocols.tcp-ip
Subject:   Sun gateway proxy ARP software?

I have some people on the network who would like to use Sun workstations as
routers, using two Ethernet interfaces with one on one network, and one on
another network.  The networks that will be behind these Sun workstations are
small, much smaller than our subnet mask's network size.  I would like them to
just use a portion of a subnet instead of assigning a whole subnet.

In order to accomplish this, the Sun workstation has to respond to ARP requests
for all of the nodes it is routing for.  This is generally called proxy ARP.  I
have also been told that there is software available for the Sun which allows
it to act as a gateway doing proxy ARP in this manner.

Can anyone give me a pointer to this software or another way of setting this
up?

Thanks in advance -

Mark
-- 
Mark Jenkins <Marcus@CPVA.SAIC.Com>| My views do not necessarily match yours.
Science Applications               | I've never met an iguana I didn't like.
International Corporation          | But that goes without saying.
San Diego, CA   USA  (619) 458-2794| -------- This space for rent ----------

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 91 18:07:47 GMT
From:      fab@MD.INTERLINK.COM (Fred Bohle)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP FIN and window

>From: rosevax!atc!hawkmoon!nightowl!s5000!kurt@uunet.uu.net  (Kurt Matthys x5693)
>Organization: Unisys - Roseville, MN
>Subject: TCP FIN and window
>Message-Id: <240@s5000.rsvl.unisys.com>
 
>I have recently run into a TCP question that I would like some input on. It 
>concerns whether a TCP can send a FIN when the window is closed. I have seen
>at least two implementations that do this, but RFC 793 would appear to say 
>that it should not be done. The following is my interpretation of the issue:
 
>On page 25 of RFC 793 it states that the segment length  is "the number of
>octets occupied by the data in the segment (including SYN and FIN)".
 
>On page 69 the table shows that if the segment length > 0 and the received 
>window = 0, the received segment is not acceptable. A couple of lines later
>it says that "If the RCV.WND is zero, no segments will be acceptable, but   
>special allowance should be made to accept valid ACKs, URGs and RSTs".
 
>Then it states that "if an incoming segment is unacceptable, an acknowledgment
>should be sent in reply ... After sending the acknowledgment, drop the
>unacceptable segment and return".
 
>On page 70 it talks about trimming an incoming segment so that it is 
>completely inside the window by "trimming off any portions that lie outside
>the window (including SYN and FIN)".
 
>From the above the FIN is included in the segment length and a TCP that
>receives a FIN when the window is closed should discard it (at least this is
>how I interpret it). Any comments?
 
>Kurt Matthys
>Unisys Corp.
>Roseville MN
 
>kurt@s5000.rsvl.unisys.com

This raises an interesting question.  Our implementation (SNS/TCPaccess)
on MVS established all its FTP data connections with a zero receive window
when sending.  No data was expected in the reverse direction, so this
seemed reasonable.  It worked fine for years, with many other implementations.
Then a XEROX user complained that the data connections hung.  Their code
would not send the FIN into a zero window.  The workaround was to artificially
set the window to 1 in our FIN packet.  Then the connection closed OK.

This seems to be a method of informally testing other implementations to see
how they handle sending a FIN into a zero window.  Since the code worked for
years with many other implementations,  it would seem the consensus is that
it is acceptable to send a FIN into a zero window.  But I agree, the RFC's
do not spell out if it is 'required' to be able to do so.

Any comments?

Fred

------------------------------------------------------------------------
Fred Bohle			EMAIL: fab@leo.md.interlink.com
Interlink Computer Sciences	AT&T : 301-317-6600 
9145 Guilford Road, Suite 175
Columbia, MD 21046
------------------------------------------------------------------------

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 91 18:24:33 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet and AS400/NCSA/CUTCP/Packetdrivers/AT&T etc


    has anyone heard of a tn5250 for unix and/or PC's ?

OpenConnect Systems of Carrolton TX (formerly Mitek) has a DOS TN5250
which uses our PC/TCP kernel as the transport layer.  I've heard it said
that IBM offers TN5250 clients for various systems, but I don't think
they have one for either DOS or SysV.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 91 18:42:07 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.text.tex,comp.protocols.tcp-ip
Subject:   rfc.bib?

Has anyone made a bibliography database, digestible by BibTeX or
Scribe, of the Internet ``Requests for Comments'' series?  I'd like to
just say \cite{rfc1149} and have all the Right Things happen.

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 91 19:08:35 GMT
From:      beame@maccs.dcss.mcmaster.ca (Carl Beame)
To:        comp.protocols.tcp-ip
Subject:   Re: Beame and Whiteside PC-NFS

In article <7131@mindlink.bc.ca> Mark_McFadyen@mindlink.bc.ca (Mark McFadyen) writes:
>Does anyone have any experience with setting up B&W PC-NFS?
>We have the NFS drive working fine, but we cannot seem to be able
>to link a local device (ie LPT3) to a remote printer.  The command
>we are using (trying to use) is:
>
>   NET LINK LPT3 \hostname\HPJET
>where HPJET is defined in the /dev/printcap file.
>This gives us a "Invalid remote device." error message and
>refuses to link.
>
>Does anyone have any suggestions?
>Or is my PRINTCAP file setup wrong?  What is the format?
>Thanks.
>--

	The line in your file /etc/printcap not /dev/printcap should read
HPJET|laser printer:\
...

Note that the case is important and that BWNFSD must be restarted after
adding this line to the /etc/printcap file.

- Carl Beame

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 91 02:00:30 GMT
From:      raj@hpindwa.cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Is this IP address "local?"


Has anyone put together a routine that will take as input an IP
address, and return a simple true/false answer to the question "Is
this IP address on a Directly Connected network?" for "BSD" networking
implementations? 

I can do the summary thing if folks like...

rick jones
raj@cup.hp.com

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 91 06:54:30 GMT
From:      craig@SICS.SE (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP on OS/2


Hi folks:
    
    Query for a friend.  I'm looking for TCP/IP products for PCs running
OS/2.  I dunno if this matters, but the PCs are currently connected via
Ethernet (Thin Wire) and use LAN Manager (which I understand they'd like
to continue to be able to use in parallel with TCP/IP, if possible).

    I'd be interested in any products one can recommend.

Thanks!

Craig Partridge
craig@sics.se

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 91 14:51:09 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip
Subject:   KEEPALIVE



   This may not be the appropriate place for this since it may be
really a BSD socket issue - if so I apologize.

   The KEEPALIVE option seems to me to be vaguely funky (kludgy).
What are your views on it. Does it really do what it is supposed to
do? If not why? What would you use in its place?

                                   Jerry Freedman,Jr

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 91 16:07:55 GMT
From:      jona@ils.nwu.edu (Kemi Jona)
To:        comp.os.msdos.programmer,bit.listserv.ibm-nets,bit.listserv.ibmtcp-l,comp.lang.smalltalk,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.windows.ms.programmer
Subject:   Help UNIX-IBM PS/2 TCP communications


I am trying to develop a system that will allow a UNIX box (IBM RS/6000) to communicate via TCP to PS/2's.  Since I'd like to graduate sometime this decade, I'd prefer not to have to write the low-level networking code on either end (esepecially the PS/2 end).  I would appreciate any source code or tips that will help me accomplish this.

Misc. notes:

The PS/2's will be running Smalltalk, so a Smalltalk interface to TCP would be great, but making foreign-function calls from smalltalk to C would be OK too.


Thanks in advance for any pointers,

--Kemi Jona
(jona@ils.nwu.edu)

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 91 16:15:26 GMT
From:      cudcv@warwick.ac.uk (Rob McMahon)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   PC-NFS FTP TTL / NIS

Configuration: PC-NFS 3.5 / Dell 316SX / RM Ethernet 16 / MPS Driver 2.00c

A couple of problems, easy (?) one first.

When using FTP, conections to some sites fail (`ftp: connect: Unknown error').
A tcpdump makes it look suspiciously like the TTL is expiring.  The TTL starts
at only 15, is there any way to increase this ?

The more tricky one is this: We run RARP and NIS.  When the file \nfs\hosts
doesn't contain any entries, we get:

C:\>NET START RDR
NFS029F : Unable to obtain the name of the NIS server.
net:  Unable to get hostname by ip addr (137.205.192.202)

Putting the PCs own address in the hosts file seems to cure this second
message, and seems to be completely necessary to get it to work at all, but
why can't it find the NIS server ?

I can use a NET NISSET to set the NIS server to a host, which must also be in
the hosts table, and then PC-NFS starts working okay, although we still get
that first message from `NET START RDR'.

Any clues ?  I'd rather not wire these things in.

Rob
-- 
UUCP:   ...!mcsun!ukc!warwick!cudcv	PHONE:  +44 203 523037
JANET:  cudcv@uk.ac.warwick             INET:   cudcv@warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 91 16:41:29 GMT
From:      pv0618@hertz.njit.edu (Paranjothi Varadarajan)
To:        comp.protocols.tcp-ip
Subject:   Bug in tn3270 !


Hi Folks !

As the subject says I am using tn3270 ( 4.1.1) to get to an IBM
mainframe machine (running MVS),, and having a prob with it. Here is the
further description of it :

We have a system on IBM MVS where user can get to help screen by using
PF1 and get back to prev screen using PF5. Now, this works fine under
all different screens of the system , except one particular screen,
where once the user goes to help and hits PF5 to backup and the whole
system hangs. ie, it does not recognise any keyboard or any other input.
It doew , however give an error message "Invalid Control sequence" if we
hit certain keys , while it is hung.

BTW , We are running hp-ux 7.05 on the unix side.
The Tn3270 TCP server on the other side is version 1.0.
or rather I should say the Telnet server on the IBM side is v 1.0.

Now, I have the tn3270 code and tried to debug the code to see what may
be wrong. But not much success, however, I did debug the code using xdb
(dbx on some unix) , and the following is the out put of the 'T' stack
with local variables command ....

On one instance :
 0 _Host + 0x9a8 (0x1, 0x1, 0, 0x1, 0x1)
 1 __v1prot_donext + 0x1aa (0x7, 0x82408, 0x1, 0x2, 0x1)
 2 ttyflush (drop = -1069292)    [../../telnet/Source/terminal.c: 98]
        n         = 2
        n0        = 27320
        n1        = 7
 3 __writechars + 0x268 (0x1, 0xffeff7b8, 0x1d640, 0, 0x3)
 4 __cleanup + 0xc (0, 0x3, 0x2c, 0x3, 0x33ab4)
 5 __writechars + 0x160 (0x2, 0xffeff7cc, 0xffeff7d8, 0xffeff8cc,
0xffeff8d0)
************************************************************************

and on other ...
 0 ttyflush (drop = 0)    [../../telnet/Source/terminal.c: 83]
        n         = 80
        n0        = 1
        n1        = 1
 1 EmptyTerminal ()    [../../telnet/Source/utilities.c: 233]
       src       = 0x4dae4
        count     = 80
        o         = 0
 2 FastScreen ()    [termout.c: 661]
        i         = 1
        columnsleft = 80
        i         = 0
        End       = 0
        tmp       = 0xe4000000
        tmpend    = 0x5860c
        tmpbuf    = 0xffeff6dc
        newfield  = 256889
       p         = 0x40504
        fieldattr = 240
        upper     = 0x3fd83
 3 DoTerminalOutput ()    [termout.c: 1044]
 4 telnet ()    [../../telnet/Source/telnet.c: 889]
        schedValue = 0
 5 tn (argc = 2, argv = 0xffeff7cc)    [../../telnet/Source/commands.c:
1260]
        oerrno    = 3564
        sp        = 0x4d640
        sin       = 0x20017
        host      = 0x4dae4
        hnamebuf  = 0x490d4
6 main (argc = 2, argv = 0xffeff7cc)    [../../telnet/Source/main.c:
156]
***************************************************************************

I know it sound CRAZY... but this is really the BEST way I could
figure-out to discuss the problem.

I sure will be willing to give more info, But, DOES THIS SOUND LIKE
SOMETHING KNOWN TO ANY BODY OUT THERE !!

Thanks a bunch folks..

- Kamlesh

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 91 17:24:02 GMT
From:      andi@uni-paderborn.de (Andreas Sorgatz)
To:        comp.protocols.tcp-ip
Subject:   Change Size of Ethernetpackets ?

Hi,

I'm asking this question for someone without an e-mail-address.

SITUATION:
----------
andi> netstat -i
Name  Mtu  Net/Dest      Address        Ipkts  Ierrs Opkts  Oerrs Collis Queue
le0   1500 131.234.104.0 planck         3766490 2083 4501105 371  1532   0
ie1   1500 131.234.2.0   planck-bb      4901944 295  3529696 0    156567 0
lo0   1536 loopback      localhost      984816  0    984816  0    0      0

As default, the ethernet-device uses a maximal transfer unit (Mtu) of 1500 Bytes.

THE QUESTION:
------------
How can I change this value on a sparc-workstation under SunOS 4.1.1, 
without generating a new kernel ?  They told me, under System 4.1 there
was a file (don't know the name) in which the Parameter MTU could be 
redefined, but under System 4.1.1 there isn't. Can anybody help me ?

Please send your answers to:	andi@plato.uni-paderborn.de

If I get any solutions, I will summarize.

Thanks in advance	Andreas Sorgatz

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 91 18:13:10 GMT
From:      karl@ddsw1.MCS.COM (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   CISCO phone number?

Does anyone have CISCO's phone number?

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Data Line: [+1 312 248-0900] Anon. arch. (nuucp) 00:00-06:00 C[SD]T
Request file: /u/public/sources/DIRECTORY/README for instructions

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 91 18:21:10 GMT
From:      spurgeon@ccwf.cc.utexas.edu (Charles Spurgeon)
To:        comp.protocols.tcp-ip
Subject:   Network reading list available

A new version of the document "Network Reading List: TCP/IP, UNIX, and
Ethernet" is now available from the Network Information Center at the
University of Texas at Austin. The list may be found on host
ftp.utexas.edu (128.83.185.16).  This is version 3.0 of the reading
list, dated August, 1991.

-- What is it? --

The network reading list is an annotated list of books and other
resources focusing on three networking technologies that are in wide
use: TCP/IP, UNIX, and Ethernet.  A mix of resources is presented
ranging from introductory information to in-depth technical details.
Version 3.0 of the list has been completely rewritten and updated, and
now includes nearly 70 items.  The list is weighted towards resources
that cover the territory well, and that deal with real-world problems
found on growing networks.  A copy of the table of contents is
included below.

-- How do I get a copy? --

You can retrieve a copy of the list in either PostScript format or as
a plain ASCII text file.  The PostScript format is recommended.  The
PostScript file is 34 pages long, and the ASCII text file contains 51
pages.

Copies of the list may be retrieved using anonymous FTP or a
mail-based archive server program.  

The hostname for anonymous FTP is ftp.utexas.edu, and the files are in
the pub/netinfo/docs and pub/netinfo/ps directories as net-read.txt
and net-read.ps respectively.  

The address of the archive server program is
"archive-server@ftp.utexas.edu". You can retrieve copies of the list
by sending the archive server program a command line in the body of an
electronic mail message.  The command line:

send ps net-read.ps

will cause the archive server program to send you a copy of the
PostScript file, while the command line:

send docs net-read.txt

will retrieve the ASCII text file.  The command line should be placed in
the body of an mail message sent to archive-server@ftp.utexas.edu.
The archive server is just a simple program, so make sure to send the
command line exactly as shown here. 

-- Table of Contents --

Section 1 -- TCP/IP
Introduction To TCP/IP ................................  1.1
Guides To The TCP/IP Internet .........................  1.2
Electronic Mail and the Internet ......................  1.3
TCP/IP Network Administration and Management ..........  1.4
The Request for Comments (RFCs) .......................  1.5
Some Useful RFCs ......................................1.5.1

Section 2 -- UNIX
UNIX In General .......................................  2.1
UNIX Networking In Detail .............................  2.2

Section 3 -- Ethernet
Introduction  To LAN Concepts .........................  3.1
Introduction to Three Ethernet Varieties ..............  3.2
Vendor Guides .........................................  3.3
Hewlett-Packard Manuals ...............................3.3.1
DEC Manuals ...........................................3.3.2
MOD-TAP ...............................................3.3.3
LAN Troubleshooting ...................................  3.4
Ethernet Standards ....................................  3.5
The DIX Standard ......................................3.5.1
The  IEEE 802.3 Standard (ISO 8802.3) .................3.5.2
IEEE Supplements ......................................3.5.3
Twisted-Pair Ethernet Specifications ..................3.5.4
Ethernet Numbers ......................................  3.6
Ethernet Type Numbers and Addresses ...................3.6.1
Assigned Numbers RFC ..................................3.6.2
Administration of Ethernet Numbers ....................3.6.3
Ethernet Performance Analysis .........................  3.7
Ethernet  Hardware and Vendors ........................  3.8

Section  4  --  Interest  Groups,  Periodicals,  and
     Conferences
Interest Groups .......................................  4.1
SRI List of Lists .....................................4.1.1
BITNET ................................................4.1.2
Usenet Groups .........................................4.1.3
Periodicals ...........................................  4.2
Conferences ...........................................  4.3
Access to the Internet ................................  4.4
Access to Books .......................................  4.5


-- 

Charles  Spurgeon		Computation Center Networking Services
c.spurgeon@utexas.edu		University of Texas at Austin
(512) 471-3241 ex 265		Room COM1, Austin TX 78712

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 91 19:22:20 GMT
From:      steveo@world.std.com (Steven W Orr)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Need help selecting Ethernet cards for very high throughput rates.

We are trying to configure an SCO Unix system running some type of
IP, (maybe TCP, maybe UPD) to operate at maximum throughput. Our goal
is to get up to _6_ Megabits/Sec. We realize that we need EISA bus
machines with 32-bit Ethernet cards to do this. We also realize that
we will need multiple cards to accomplish this goal. We have no
problems spending whatever it takes to make this machine as fast as
possible, given the SCO/[34]86/EISA constraints.

Another important detail is that each computer will be talking over a
Cisco router with one ethernet card per computer. This way we
completely eliminate packet collisions.

Does anyone have SCO running with multiple cards? Which cards are you
running? How many? What's your throughput?

We have been in touch with Racal Interlan. They recommended their
6510 card. They told us that it has bus mastering and that it is a 16
bit card. Is this not a contradiction in terms? They said it would
run at 6 Megabits/Sec. All the wisdom so far says that no 16 bit card
will average over 1/4 Mb/sec.

They also told us about their ES3210 card, which they claim can
operate at _13_ Megabits/Sec. I thought that the cable can't operate
faster than 10 Megabits/Sec. Am I missing something? How do I get
real numbers that will tell me what to expect in the field?

I don't know how obvious my lack of network expertise is, but if you
see any questions that I'm not asking, I need to know that also. I'm
sure I'm not asking everything I need to know.

Many thanks in advance.

-- 
----------Time flies like the wind. Fruit flies like bananas.------------------
Steven W. Orr      steveo@world.std.com     uunet!world!steveo
----------Everybody repeat after me: "We are all individuals."-----------------

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 91 19:31:26 GMT
From:      jmb@ideas.com (Jonathan M. Bresler)
To:        comp.protocols.tcp-ip
Subject:   IPI3

for lack of a better place, i'm sending this request to tcp-ip.

waht is IPI3?
where is documentation and other additional info available on IPI3?

thanx in advance,
Jon Bresler

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 91 20:52:32 GMT
From:      wayne@ultra.com (Wayne Hathaway)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window

Following this discussion on "Can you send a FIN into a zero window?"
has been fascinating, because it is amazing to see how easy it is for
things like a particular networking model can become jumbled up with
the protocol itself.

I'd like to point out (as at least one other person has) that there is
no requirement that a TCP advertise a nonzero window if it does not
expect to receive data (other than to accommodate implementations that
won't send a FIN into a zero window, that is).  For example, my
company makes a very fast network that gains a large amount of its
speed by moving data directly from one user buffer to another; it does
NOT buffer data in the kernel at either end (a true "zero copy" model
if ever there was one! :-).  Using this networking model, the
receiving TCP advertises a zero window at any time the user has not
posted a read buffer, since it in fact does not have a place to put
any arriving data (no kernel buffering, remember).  So when the
receiver has done its last read and received its last data, the window
will stay zero for the duration.  We'd sure like the transmitter to go
ahead and send us its FIN, however.  (Some people might say that it is
a shortcoming of TCP that it REQUIRES a nonzero window in order to be
able to close a connection.  That simply points out that dependence on
particular models should be avoided when DESIGNING protocols as well!)

And as an aside, others have mentioned that this is similar to zero
window probing, which I don't think is quite right.  A zero window
probe is really an attempt to elicit a retransmission of the PREVIOUS
ACK (which might have had a nonzero window and been lost), and not so
much an attempt to get the receiver to accept new data.  However,
sending a FIN into a zero window is clearly an attempt to get the
receiver to accept the FIN itself.

Finally, I'd like to close by imploring people to separate out things
like operating system characteristics and particular data movement
models when discussing protocols.  (For example, the receive window
size is NOT how much data the receiving operating system is able to
buffer for the user, in spite of such a description in many texts!)
To do otherwise will at best limit your creativity, and it may well
lead to outright broken protocols and/or implementations.

    Wayne Hathaway               domain: wayne@Ultra.COM
    Ultra Network Technologies     uucp: ...!ames!ultra!wayne
    101 Daggett Drive             phone: 408-922-0100 x132
    San Jose, CA 95134           direct: Hey, you!

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 91 21:30:35 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window

In article <1991Aug27.205232.7303@ultra.com> wayne@ultra.com (Wayne Hathaway) writes:
>So when the receiver has done its last read and received its last
>data, the window will stay zero for the duration.

Just out of curiousity, if the application protocol is such that the
receiver knows when it's done reading, why does it bother with a
graceful close?  Why doesn't it just reset the connection?  (In case
this seems irrelevant: if Mr. Hathaway's protocol depended on the FIN
to indicate the end of the transmission, the reader would have to post
one last receive buffer since it wouldn't know that it wasn't needed,
and that would provide window for the FIN.)
						don provan
						donp@novell.com

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 91 23:16:45 GMT
From:      mlong@IASTATE.EDU (Michael C Long)
To:        comp.protocols.tcp-ip
Subject:   Re: Bug in tn3270 !

In article <1991Aug27.164129.19108@njitgw.njit.edu>, pv0618@hertz.njit.edu
(Paranjothi Varadarajan) writes:
> 
> Hi Folks !
> 
> As the subject says I am using tn3270 ( 4.1.1) to get to an IBM
> mainframe machine (running MVS),, and having a prob with it. Here is the
> further description of it :
> 
> We have a system on IBM MVS where user can get to help screen by using
> PF1 and get back to prev screen using PF5. Now, this works fine under
> all different screens of the system , except one particular screen,
> where once the user goes to help and hits PF5 to backup and the whole
> system hangs. ie, it does not recognise any keyboard or any other input.
> It doew , however give an error message "Invalid Control sequence" if we
> hit certain keys , while it is hung.
> 
> BTW , We are running hp-ux 7.05 on the unix side.
> The Tn3270 TCP server on the other side is version 1.0.
> or rather I should say the Telnet server on the IBM side is v 1.0.
> .......
> 
> I know it sound CRAZY... but this is really the BEST way I could
> figure-out to discuss the problem.
> 
> I sure will be willing to give more info, But, DOES THIS SOUND LIKE
> SOMETHING KNOWN TO ANY BODY OUT THERE !!
> 
> Thanks a bunch folks..
> 
> - Kamlesh
WE HAD SOMETHING VAGUELY SIMILAR TO WHAT YOU SEEM TO BE DESCRIBING HERE.  WE
WERE USING IBM'S TCP/IP FOR THE PC FEATURE OF THE TCP/IP FOR VM AND WERE
TELNETING TO THE VM MACHINE.  WHEN WE WOULD GET INTO CMS AND X-EDIT A FILE THE
'F' KEYS WOULD CAUSE A LOCK-UP, BUT TYPEING IN THE X-EDIT COMMAND (LIKE QQUIT)
WOULD NOT CAUSE A LOCKUP.  THE ONLY WAY WE COULD MAKE THIS WORK WAS TO SET THE
PC'S 'TCP RECEIVE BUFFER' AND 'TCP LOW WINDOW' TO 220 BYTES.  THEN OUR X-EDIT
WORKED PERFECTLY.  AS WE HAVE JUST PUT ON VER. 2.0 ONTO OUR VM MACHINE, I WAS
EXPIRIMENTING TODAY WITH X-EDIT'S F KEYS AND THE PC'S BUFFER SIZES, BUT I COULD
NO LONGER DUPLICATE THIS PARTICULAR PROBLEM.

HOPE THIS HELPS 
MIKE LONG
CENTER FOR AGRICULTURAL AND RURAL DEVELOPMENT
IOWA STATE UNIVERSITY
AMES, IA 50011

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 91 23:26:35 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window

In article <1991Aug27.205232.7303@ultra.com> wayne@ultra.com (Wayne Hathaway) writes:
>Using this [Ultranet] networking model, the
>receiving TCP advertises a zero window at any time the user has not
>posted a read buffer, since it in fact does not have a place to put
>any arriving data (no kernel buffering, remember).  So when the
>receiver has done its last read and received its last data, the window
>will stay zero for the duration.  We'd sure like the transmitter to go
>ahead and send us its FIN, however.  (Some people might say that it is
>a shortcoming of TCP that it REQUIRES a nonzero window in order to be
>able to close a connection.  That simply points out that dependence on
>particular models should be avoided when DESIGNING protocols as well!)

As a supporter of FIN-outside-WIN, I would agree that the RFC's position
on this question is unfortunate.  I don't know if you can attribute it
to "dependence on particular models", though, since the RFC authors in fact
used exactly the same model as you when describing their hypothetical
implementation: they advertise a window only when read buffers have been
posted by the application, and mention that another possible implementation
*might* provide extra buffering in the host.  So, given that they do
consider a model like yours, I have to conclude that their requiring a
nonzero window is a protocol bug.  I, and presumably you, would be
happier if the spec allowed a FIN just past the right edge, or at least
a standalone FIN into a closed window.

But, it don't, and, like it or not, the question remains of what to do
with the standard as she be.  Some implementation out there just might
not send a FIN into a closed window, or not accept the one you send,
and its implementers appear to be within their rights to build it that way.
What to do?

Well, you should certainly send the FIN, and if the other guy keeps
throwing it away, I guess that's his problem.  There doesn't seem
to be any way out of it, except RST, which I would call innapropriate.
Interestingly, BSD4.2 appears to willingly send a lone FIN, retransmit it,
*and* drop the connection for too many retries, even if it was to a closed
window (assuming I'm reading it right).  This seems antisocial to me.

The other side of the question is what to do if he won't send his FIN
to your closed window.  One way out is to advertise a one octet window and,
if you receive real data, shrink it back to zero.  But, we are strongly
advised against window shrinking, so this is not a nice solution.

A second approach is to supply at least one octet of system buffering.
If it fills up and the window closes anyway, that's fine.  The presence
of real data implies that the application should read it at some point,
opening the window up again - the problem we really needed to avoid was
the closed window when the application *wasn't* going to try to read.

I guess that second approach will work for most implementors, because
most of them will have system buffering anyway.  In UltraTechnology's
case, and perhaps in others, it may be very unattractive.  If so, it
will come down to "how important is it to interoperate cleanly with
these RFC sticklers?" which, in turn, depends on how many and who they
are.  Certainly, many implementations are based on the Berkeley one,
which sends the FIN in spite of the RFC.  Are there significant
ones that don't?
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 91 00:54:16 GMT
From:      mailinfo@netcom.COM (Will Estes)
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   Where Can I Get PCMAIL (RFC1056) Clients And Servers?

Can someone point me to an FTP source for any SunOS implementations
of RFC1056 (the PCMAIL server) and any clients for same?

Thanks,
Will Estes         Internet: mailinfo@netcom.com

P.S. Please courtesy copy your response to me directly as I
do not always read this newsgroup.

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 91 10:52:34 GMT
From:      PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   Re: EBCDIC ASCII and *much* more

On Tue, 20 Aug 91 17:19:23 -0400 you said:
>Thanks for the abundance of reference your writings afford in this area of
>of character representation.It is a good paper which raises a couple of issues
>the have been long standing in this increasing complex area, the
>representation and presentation of transmitted data. I have not read all the
>above mentioned writings and offer the following on on the subject.

Although it mentions ISO 10646, my document does not deal with general
character representation. In short, the point is that:
- we've had virtually no support of our national characters until about
  the introduction of the PC and the Mac 10 years ago, on IBM mainframes
  4 years ago and now that Unix enters the game.
- this support is purely local, telecommunication support is virtually null
  because of 7-bit restrictions and the differences in character codes despite
  similar character sets.
- I expect many years before a world wide code will be used effectively.
- all it takes to implement an extremely valuable solution right now is:
  - to get "convinced" that a character is coded on 8 bits and modify
    programs accordingly (easy for many essential protocols).
  - to realize that the difference in character codes is a pain in the neck
    and that translation is "needed somewhere" when data is moving from one
    machine to another, *exactly* like EBCDIC is translated to ASCII. EBCDIC
    software is often easy to adapt because translation is always present.

>Is being a standard justification for usage ?

At least usage is justification for a standard, but when there's only one
official standard that's justification enough to use it.
The point is that it is not reasonable to expect that any machine be able
to recognize any 8-bit code coming its way but that each must translate
to and from a standard code instead. ASCII has proved useful enough, hasn't
it, and you don't use a pile of dictionaries to read this conference.
So, because we restrict ourselves to single-octet codes for now and because
an octet has not enough code points for all languages of the worlds, we must
admit different codes should be used according to the language, but only
one per language.
ISO 8859 is just that: a palette of 8-bit codes covering the widest range of
languages it can. As I am speaking French, I use ISO 8859/1 but I won't be
surprised to receive ISO 8859/7 if some Greek tries to speak to me.
Unhappily, I speak very very little Greek, and I'd reply that in English,
which is all-right in ISO 8859/7. But if I did, I'd surely manage to type
and display that code.
This is the least-annoyance solution to implement to-day, and it's easy
if the principles are agreed.

Now in aix1.segi.ulg.ac.be:iso/iso8859.notes

Thanks for your interest.

Andr'e PIRARD         SEGI, Univ. de Li`ege        139.165 IP coordinator
B26 - Sart Tilman     B-4000 Li`ege 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 91 12:55:20 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window

In article <1991Aug27.213035.10980@novell.com>, donp@novell.com (don provan) writes:
> Just out of curiousity, if the application protocol is such that the
> receiver knows when it's done reading, why does it bother with a
> graceful close?  Why doesn't it just reset the connection?  (In case
> this seems irrelevant: if Mr. Hathaway's protocol depended on the FIN
> to indicate the end of the transmission, the reader would have to post
> one last receive buffer since it wouldn't know that it wasn't needed,
> and that would provide window for the FIN.)

	I think you're making too many assumptions about the protocol here.
Suppose I design a protocol where the server accepts one request, answers it,
and then goes away. Suppose further that the server keeps a log of successful
queries, so in the server I need to know with reasonable surety that the data
I sent was in fact delivered to the client. On the server side, once I've read
the request, I know I no longer need to read anything. But I still want to
(reliably) write stuff.
	That doesn't mean I can do a RESET, even after I've written the reply,
because that will throw away any buffered data that I really do want delivered
to the other end. I need a synchronous close() in the server for the server to
know the data was delivered-- a RESET doesn't cut it.
	So there's a counter-example.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 91 13:39:10 GMT
From:      pv0618@hertz.njit.edu (Paranjothi Varadarajan)
To:        comp.protocols.tcp-ip
Subject:   tn3270 Bug. Follow-up..



Thanks for replying folks ...

I received following response from somebody on the net regarding my
earlier posting, but am not sure how to map this onto my hp-ux tcp
stuff. 
Some further tips would be of great help....

WERE USING IBM'S TCP/IP FOR THE PC FEATURE OF THE TCP/IP FOR VM AND WERE
TELNETING TO THE VM MACHINE.  WHEN WE WOULD GET INTO CMS AND X-EDIT A
FILE THE
'F' KEYS WOULD CAUSE A LOCK-UP, BUT TYPEING IN THE X-EDIT COMMAND (LIKE
QQUIT)
WOULD NOT CAUSE A LOCKUP.  THE ONLY WAY WE COULD MAKE THIS WORK WAS TO
SET THE
PC'S 'TCP RECEIVE BUFFER' AND 'TCP LOW WINDOW' TO 220 BYTES.  THEN OUR
X-EDIT
WORKED PERFECTLY.  AS WE HAVE JUST PUT ON VER. 2.0 ONTO OUR VM MACHINE,
I WAS
EXPIRIMENTING TODAY WITH X-EDIT'S F KEYS AND THE PC'S BUFFER SIZES, BUT
I COULD
NO LONGER DUPLICATE THIS PARTICULAR PROBLEM.

HOPE THIS HELPS
MIKE LONG
CENTER FOR AGRICULTURAL AND RURAL DEVELOPMENT
IOWA STATE UNIVERSITY
AMES, IA 50011

Thanks once again...

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 91 13:52:56 GMT
From:      a20@nikhefh.nikhef.nl (Marten Terpstra)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Any results from Gbits testbeds ?

Hi all,

Couls anyone tell me if there are any (preliminary) test results or other
conclusions available somewhere on the NSF net sponsored Gigabit testbeds ?

And now that I'm more or less on the subject, can anyone suggest some reading
material on ATM and other of these goodies that are to come ?

Thanks,

-Marten
--
Marten Terpstra					     Email : terpstra@nikhef.nl
National Institute for Nuclear			     Phone :    +31 20 592 5102
and High Energy Physics (NIKHEF-H),		       Fax :    +31 20 592 5155
PO Box 1882, NL-1009 DB Amsterdam,
The Netherlands					  Bus error (passengers dumped)

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 91 15:08:00 GMT
From:      A563700@CUCSC.BITNET ("C.H. Cheng, The Chinese Univ. of Hong Kong")
To:        comp.protocols.tcp-ip
Subject:   Support of Multiple Logical Subnetwork by Routers

Hi all,

Is anyone out there using 3Com Brouter (BR/2000)?  I think we have the latest
version (V3.0.2.3).  Unfortunately, although the manual mentions that it
supports Multiple Logical Network (Subnetwork?!) for IP, we are not able to
implement subnet routing through a single port when we set up two addresses
(with different subnet no. of course) to this port.  It seems that the
secondary address is of no use with this brouter.

I personally think that it's quite ridiculous that even UCX 1.3a of DEC
running on VMS can support it successfully although it is critized by many
people as one of the worst TCP/IP implementation for VMS.

Have you experienced the same problem with 3Com Brouter?  Any solutions to
this?  Is there anyone running Multiple Logical (Sub)network successfully with
other brand of bridging router?

Any other comments are welcome also.

Thanks in advance.


Regards,

C.H. Cheng
Computer Services Center
The Chinese Univ of Hong Kong


P.S.  This mail is cross-posted to BIG-LAN list.

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 91 16:45:23 GMT
From:      dmc@doc.Lanl.GOV (dave clark)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe

Please remove me from the mailing list. Thanks!
Dave Clark

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 91 17:22:47 GMT
From:      trey@ut-emx.uucp (Trey Garlough)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS vendors, addresses or phones

In article <30686@uflorida.cis.ufl.EDU> dalton@pine.circa.ufl.edu writes:
>Does anyone know the phone number or address for info about
>
>PC/TCP Interdrive, ftp Software, Inc. or
>Beame & Whitside's, B&W NFS?

FTP Software in Mass (617) 246-0900
B&W in Ont (416) 648-6556

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 91 17:33:14 GMT
From:      jlawton@stardent.com (Jennifer Lawton)
To:        comp.protocols.tcp-ip
Subject:   Re:  Diskless Sun 3/50 as X-terminal over SLIP/PPP. How to boot?

Why serial lines?  We have a lot of 3/50 as X-terminals but they are all
over ethernet.

I can detail, to you, how to do this if you are interested.


Jennifer Lawton			Stardent Computer
jlawton@stardent.com		521 Virginia Road
(508)287-0100 x305		Concord, MA 01742

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 91 21:55:04 GMT
From:      zweig@cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window

How about advertizing a one-octet window?  There's no law that says that you
have to actually _accept_ data -- so advertize a teensy window when you expect
a FIN (I leave it as an exercise to figure a way for the TCP module to know
when to do this) and eat the FIN which doesn't need to be buffered since it
isn't actually a data octet.  If there is more than one octet in the last
packet, something is wrong. I don't see the problem.

-Johnny Singleton

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 91 22:32:21 GMT
From:      mju@mudos.ann-arbor.mi.us (Marc Unangst)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   How to connect to the Internet?

Although I've been dealing with Usenet and Unix for quite a while, I
haven't had to deal with the Internet until recently.  I've used it,
of course, through dialup connections to Internet-connected machines,
but I don't know a whole lot about actually setting up the hardware
end of stuff.

However, the higher-ups at the company have decided that they want an
Internet connection, and it is upon my shoulders that the
responsibility falls, so...

We currently have a small (3 workstation) TCP/IP network with two Open
Desktop machines and an MS-DOS box running NCSA Telnet.  I understand
TCP/IP pretty well on the single-subnet level, and have gotten things
like BIND, ftp/telnet, etc. to work properly.  However, I haven't done
a whole lot with internetworking, routing between subnets, etc.  I
also don't have a whole lot of experience with gateways, routers, and
other such devices, since we currently only have one Ethernet segment.

My question is: How would I go about connecting this network to the
Internet?  What hardware (gateways, leased-line modems, etc.) is
necessary?  Who should I contact in my area (SE Michigan) to get
hooked up?  Will I need any software (routing, etc.) that isn't
included with Open Desktop (which includes things like named, routed,
etc.)?  And finally, what would be a rough estimate of startup costs
and continuing costs for a 56Kbps leased-line connection to the
Internet?

Thanks a lot, and I suppose I'll post a summary when the replies stop
flooding in...

-- 
Marc Unangst               | "I _do_ love my country.  It's my government
mju@mudos.ann-arbor.mi.us  |  that I'm scared of."
...!hela!mudos!mju         |            -Seen on a bumper sticker

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 02:02:35 GMT
From:      mshiels@TMSoftware.ca (Michael A. Shiels)
To:        comp.protocols.tcp-ip
Subject:   2nd release of BSD networking code etc

Does anyone have the 2nd release of BSD networking code etc up for FTP access?
-- 
---

Michael A. Shiels                           | mshiels@masnet.uucp
MaS Network Software and Consulting         | mshiels@tmsoftware.ca

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 04:03:28 GMT
From:      crum@alicudi.usc.edu (Gary L. Crum)
To:        comp.protocols.tcp-ip
Subject:   Scientific American networking issue

I saw in a library yesterday a special issue of Scientific American
devoted to computer communications.  It includes an article by Senator
Al Gore on "Infrastructure for the global village" and an article on
network technologies by Vint Cerf.  (Excuse me but I can't remember the
title of the latter article.)

Don't miss it -- I think the issue is particularly appropriate for
recommendation to people not directly involved in computer networking
research and development.

Is the National Research and Education Network (NREN) effort going well?
NREN is mentioned in the article by Al Gore.

Gary

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 04:17:08 GMT
From:      martin@unislc.uucp (Martin Cryer)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In article <1991Aug27.192220.20958@world.std.com> steveo@world.std.com (Steven W Orr) writes:
>We are trying to configure an SCO Unix system running some type of
>IP, (maybe TCP, maybe UPD) to operate at maximum throughput. Our goal
>is to get up to _6_ Megabits/Sec. We realize that we need EISA bus
>machines with 32-bit Ethernet cards to do this. We also realize that
>we will need multiple cards to accomplish this goal. We have no
>problems spending whatever it takes to make this machine as fast as
>possible, given the SCO/[34]86/EISA constraints.
>
>Another important detail is that each computer will be talking over a
>Cisco router with one ethernet card per computer. This way we
>completely eliminate packet collisions.
>
>Does anyone have SCO running with multiple cards? Which cards are you
>running? How many? What's your throughput?
>
>We have been in touch with Racal Interlan. They recommended their
>6510 card. They told us that it has bus mastering and that it is a 16

No, you can have ISA bus masters (eg Adaptec 1542 SCSI) but be aware
they don't always work in all PCs and often have a memory DMA speed limit
around 5.0MBytes/s (which is below what you may want...)

>bit card. Is this not a contradiction in terms? They said it would
>run at 6 Megabits/Sec. All the wisdom so far says that no 16 bit card
>will average over 1/4 Mb/sec.

Not true, the Adaptec 1542 can do sustained SCSI I/O at around 2.5 MBytes/s
to multiple drives (the EISA 1740 board though does much better and
hogs the I/O bus much less).

>
>They also told us about their ES3210 card, which they claim can
>operate at _13_ Megabits/Sec. I thought that the cable can't operate
>faster than 10 Megabits/Sec. Am I missing something? How do I get
>real numbers that will tell me what to expect in the field?

Mmmm, they may be quoting the burst speed from memory to the controller
across the EISA bus. You will be lucky to get over 75% of 10MBits/s
out of Ethernet really.

>
>I don't know how obvious my lack of network expertise is, but if you
>see any questions that I'm not asking, I need to know that also. I'm
>sure I'm not asking everything I need to know.
>
>Many thanks in advance.
>

I think you are asking too much of a timesharing O/S even with an EISA
PC to get sustained 6Mbytes/s. If you only want it for bursts, you
may have better luck.

Or you might want to try using SCSI as a LAN and use 2 EISA SCSI controllers
(in target and initiator mode) to send the data between systems, though
the range will be limited to 25metres for differential SCSI.

Martin Cryer
Unisys Europe Africa
Unix SVR4 Development
Unisys Salt Lake City

All opinions are my own and not those of my employer.

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 07:08:05 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: Any results from Gbits testbeds ?

>Couls anyone tell me if there are any (preliminary) test results or other
>conclusions available somewhere on the NSF net sponsored Gigabit testbeds ?

Marten:
    
    Sure, there are lots of results beginning to come out.  There are various
sources.  The testbeds produce annual reports on their work and some of them
are publicly available.  Some papers are beginning to be published -- there
will be a few at SIGCOMM '91 in Zurich next week.  I believe we'll see some
articles in the March '92 issue of IEEE Network (though this is still being
worked out).

>And now that I'm more or less on the subject, can anyone suggest some reading
>material on ATM and other of these goodies that are to come ?

Gack -- that's harder.  I teach a course on this material for INTEROP
have found it hard to pull together a good reading list despite requests
from students.  Turner's paper is still the best one for the philosophy
underlying cell-switching (and thus ATM).  What other goodies are you
interested in?

If you're willing to wait there's lots of stuff coming.  There's currently a
plan to do special gigabit issues of all the major IEEE Comm. Soc. magazines
this spring -- which should give you some useful reading.  Also, there are
a couple of books on gigabit networking in preparation (I'm writing one of
them) but they won't appear til late next year.

Craig Partridge
Incoming Editor-in-Chief, IEEE Network Magazine

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 08:29:58 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Transport Protocols for Operating Environment platforms




 >For Tele-presence/Operating Environment platforms, we need a rugged
 >transport protocol like in the IP suite since we don't know all of the
 >network types we'll be running on.  That is, we would like one transport
 >protocol for LANs and WANs at a wide range of speeds and signal-to-noise
 >ratios.

have a look at ST-II, PVP and NVP, 

but also lots of people are looking into
modifiying IP and TCP to have timestamps that can be used to provide
delay skew control, and people are looking at resource guarantee IP
gateways...try end2end-interest@isi.edu

 >The protocol at the transport level is a cross between datagrams and
 >connection-oriented communications models.

yes - agree with this

 > - toggle acknowledgements on/off 
 >   and when on, specify the AC >K- count size for sequencing;
 > - variable time-outs lengths defaulting to the `slow-start' technique;
 > - variable retransmission attempt counts.  

yep, agree with trying these, but there's more (like one to many
communication

 >Synchronization may become a necessary feature for the applications, so
 >working NTP into the picture would be nice.

see ACM SIGCOMM last year - paper by liskov et al

plus also multipath synching etc etc...there is lots of work at
berkeley on this (prof ferrari's group)

 >ps - this would be interesting to specify in Estelle and to simulate with
 >GROPE.  gee, I'm not doing too much this week...  :)

or use bellcore's SPIN system...

cheers

 jon


------------------------------ End of forwarded message 1

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 10:08:11 GMT
From:      DAVID@wcc.govt.nz (David Richards)
To:        comp.protocols.tcp-ip
Subject:   What are the spec's for T3?

Can someone tell me what T3 spec's are.

AdvTHANKSance
---
David

P.S. My return address is screwed,
please SEND not REPLY, to "david@ccc.govt.nz"
+------------------------------------------------------------------------------+
| David Richards, Systems Programmer, | e-mail "david@ccc.govt.nz"             |
| MIS unit, Christchurch City Council | PSI    PSI%0530130010083::DAVID        |
| P.O. Box 237, Christchurch,         | Phone +64 3 711-689, Fax +64 3 796-706 |
| New Zealand              "Do it tomorrow, you've made enough mistakes today" |
 +------------------------------------------------------------------------------+

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 13:07:30 GMT
From:      Y.Murayama@CS.UCL.AC.UK (Yuko Murayama, +44-71-387-7050 ext.3721)
To:        comp.protocols.tcp-ip
Subject:   a minconfigured host


Suppose that an IP host is miconfigured with a forwarding capability, 
i.e. the host would try to forward a packet received which was not destined
to this host,  would it decrease the TTL of the packet?

Yuko Murayama
Dept of Computer Science 
University College London

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 13:15:48 GMT
From:      mike@tredysvr.Tredydev.Unisys.COM (Mike Marciniszyn)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   TCP/IP - C compiler BUG

This article documents a problem with the Lachman TCP/IP implementation
concerning the sequence number macros contained in netinet/tcp_seq.h.
(The problem may also exist in other TCP/IP implementations based on the
original BSD4.3 source.)  A bug exists in the standard AT&T C compiler that
prevents the macro

#define	SEQ_GT(a,b)	((int)((a)-(b)) > 0)

from working properly when the macro is given "a" with the value 0x7fffff6c and
"b" with the value 0x80000520.  In that case the code generated is as follows:

	movl   0x8(%ebp),%eax # load of a
	subl   0xc(%ebp),%eax # subtract b
	jle    0x1c <1c6>     # 

The subtract with the above values sets the SF (sign flag) and the OF
(overflow flag).  The jle in spec in the Intel manual jumps when ZF = 1
or SF != OF.  In this particular case SF and OF are both one so the test
falls through erroneously saying the SEQ_GT is true.  This bug causes
the tcp driver to send erroneous urgent data when the snd.una is equal
to 0x7fffff6c and snd.nxt is equal to 0x80000520.  Code in tcp_output()
then erroneously sends a whole packet marked as urgent data causing the
connection to hang.  (This may not be the only manifestation of the problem!).

There are really two possible solutitons to the problem:

1. Fix the compiler to do the zero compare properly.  In fact the Free Software
   Foundation's compiler gcc (1.39) works correctly because it generates
   the following code:

	movl   0x8(%ebp),%eax
	subl   0xc(%ebp),%eax
	testl  %eax,%eax		# different from standard C
	jle    0x1c <1f9>

   Note the test before the jle.  This zeros out the OF so that the jle
   correctly branches whenever the SF is set or the ZF is set!  All V3.x
   versions of the standard C compiler and the V4.0 version that we have
   exhibit the problem.

2. Fix the macros for the i386 in netinet/tcp_seq.h to the following:

#define	SEQ_LT(a,b)	(((a)-(b))&0x80000000)
#define	SEQ_LEQ(a,b)	(!SEQ_GT(a,b))
#define	SEQ_GT(a,b)	SEQ_LT(b,a)
#define	SEQ_GEQ(a,b)	(!SEQ_LT(a,b))

   This patch is changing the test to always key off of bit 31 of the a - b
   result which is always the sign bit on systems with 2's complement
   arithmetic.  The fix for tcp is to just recompile the tcp driver with the
   an updated netinet/tcp_seq.h.  (Released versions of the V4.0 version of
   netinet/tcp_seq.h have the above fix).

   Unisys suppport may have supplied a CTIX TCP/IP version or patch with
   the macros in netinet/tcp_seq.h as follows:

#define	SEQ_LT(a,b)	((a) < (b))
#define	SEQ_LEQ(a,b)	((a) <= (b))
#define	SEQ_GT(a,b)	((a) > (b))
#define	SEQ_GEQ(a,b)	((a) >= (b))

   This fix is not correct when for example a has the value 0xffffff6c and
   b has the value 0x520.  The same problem will occur!

Attached is a shell archive with contains a client and server program which
can be started through the loopback interface or between two systems to see
if a particular TCP/IP implementation has the problem.  The client program
should be run on the suspect system.  Also contained in the archive is a test
to see if the standard C compiler has the bug.  The archive contains the
follows members:

clnt.c		- client side of TCP/IP test program
seqtest.c	- compiler test program
seqtest.h	- header file with alternate macros
seqtest.mk	- make file for seqtest programs
srvr.c		- server side of TCP/IP test program

When make -f seqtest.mk is entered vaxtest, ctixtest, and v40test are
generated.   The output of the three macro alternatives on our system
with the buggy standard 386 C compiler are as follows:

vaxtest:  (The original BSD4.3 defines)

1 Not Greater than 2 diff = ffffffff
7fffff6c Not Greater than 7fffff6c diff = 0
7fffff6c Not Greater than 7fffff6d diff = ffffffff
7fffff6c Greater than 80000520 diff = fffffa4c
7fffff6c Greater than 80000520 diff = fffffa4c
ffffff6c Not Greater than 520 diff = fffffa4c
80000520 Not Greater than 80000521 diff = ffffffff

ctixtest:  (CTIX's TCP/IP support patch)

1 Not Greater than 2 diff = ffffffff
7fffff6c Not Greater than 7fffff6c diff = 0
7fffff6c Not Greater than 7fffff6d diff = ffffffff
7fffff6c Not Greater than 80000520 diff = fffffa4c
7fffff6c Not Greater than 80000520 diff = fffffa4c
ffffff6c Greater than 520 diff = fffffa4c
80000520 Not Greater than 80000521 diff = ffffffff

v40test:  (V40's correct fix)

1 Not Greater than 2 diff = ffffffff
7fffff6c Not Greater than 7fffff6c diff = 0
7fffff6c Not Greater than 7fffff6d diff = ffffffff
7fffff6c Not Greater than 80000520 diff = fffffa4c
7fffff6c Not Greater than 80000520 diff = fffffa4c
ffffff6c Not Greater than 520 diff = fffffa4c
80000520 Not Greater than 80000521 diff = ffffffff

All tests should have note Not Greater!

Mike Marciniszyn
Maintenance Subsystem Development
Unisys Tredyffrin
DOMAIN: mike@tredysvr.tredydev.unisys.com  UUCP: tredysvr!mike
----------------------------- cut here for archive -----------------------
#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  clnt.c seqtest.c seqtest.h seqtest.mk srvr.c
# Wrapped by mike@tredysvr on Thu Aug 29 09:02:58 1991
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'clnt.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'clnt.c'\"
else
echo shar: Extracting \"'clnt.c'\" \(1889 characters\)
sed "s/^X//" >'clnt.c' <<'END_OF_FILE'
X#include <sys/types.h>
X#include <sys/socket.h>
X#include <sys/time.h>
X#include <netinet/in.h>
X#include <netdb.h>
X#include <stdio.h>
X#include <errno.h>
X
X#define TRUE 1
X#define DATA "Half a league,half a league ..........."
Xchar bufr[20100];
Xchar bufs[20100];
X
Xint sock, length,count;
Xstruct sockaddr_in server;
Xstruct hostent *hp ,*gethostbyname();
Xint rval;
Xstruct timeval to;
Xint rslt;
X
X
X
Xmain(argc,argv)
Xint	argc;
Xchar	**argv;
X{
Xint i, rslt;
X	for(i=0;  i<20100;i++) bufs[i] ='a';
X	sock = socket(AF_INET,SOCK_STREAM,0);
X	if (sock < 0)
X		{
X		perror("opening socket");
X		exit(1);
X		}
X
X	server.sin_family = AF_INET;
X	hp =gethostbyname(argv[1]);
X	if (hp == 0)
X		{
X		perror("gethostbyname ");
X		exit(2);
X		}
X	bcopy(hp->h_addr,&server.sin_addr,hp->h_length);
X	server.sin_port = htons(atoi(argv[2]));
X
X	if (connect(sock,&server,sizeof(server)) < 0)
X	    {
X	    perror("connect error");
X	    exit(2);
X	    }
X
X		do
X		{
X		send_msg();
X		}
X		while(TRUE);
X}
X
X
Xsend_msg()
X
X{
Xint rval;
X		{
X		errno = 0;
X		rval =write(sock,bufs,sizeof(bufs));
X		if (rval == -1)
X			{
X			perror("wrting stream message");
X			exit(4);
X		     }	 
X		else 
X		if (rval == 0)
X			{
X			perror("write error\n");
X			printf("\nEnding Connection.");
X			exit(5);
X			}
X
X		else
X		/* if((count/1000)*1000 == count) */
X			{
X			/*
X			printf("message sent length = #%d\n",rval);
X			printf("errno = #%d\n", errno);
X			*/
X			}
X		count+=1;
X		}
X}
Xrecv_msg()
X{
Xint rval;
X		{
X		rval = read(sock,bufr,20100);
X
X		if (rval == -1)
X			{
X			perror("reading stream message");
X			exit(1);
X			}
X		else 
X		if (rval == 0)
X			{
X			printf("\nEnding Connection.");
X			exit(5);
X			}
X
X		else
X		  /* if ((count/20100)*20100 == count) */
X			{
X			printf("message recvd length = #%d\n",rval);
X			printf("errno = #%d\n", errno);
X			rslt = strncmp(bufr,bufs,rval);
X			if (rslt)
X				{
X				printf("buffers did not compare\n",rslt);
X				}
X			}
X
X          count+=rval;
X		}
X}
X
END_OF_FILE
if test 1889 -ne `wc -c <'clnt.c'`; then
    echo shar: \"'clnt.c'\" unpacked with wrong size!
fi
# end of 'clnt.c'
fi
if test -f 'seqtest.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'seqtest.c'\"
else
echo shar: Extracting \"'seqtest.c'\" \(515 characters\)
sed "s/^X//" >'seqtest.c' <<'END_OF_FILE'
X#include "seqtest.h"
X
Xmain(argc, argv)
Xint argc;
Xchar **argv;
X{
X	testit(0x01, 0x02);
X	testit(0x7fffff6c, 0x7fffff6c);
X	testit(0x7fffff6c, 0x7fffff6d);
X	testit(0x7fffff6c, 0x80000520);
X	testit(0x7fffff6c, 0x80000520);
X	testit(0xffffff6c, 0x00000520);
X	testit(0x80000520, 0x80000521);
X}
X
Xtestit(val1, val2)
Xunsigned long val1, val2;
X{
X	if (SEQ_GT(val1, val2)) {
X		printf("%lx Greater than %lx diff = %lx\n",val1,val2, val1-val2);
X	} else {
X		printf("%lx Not Greater than %lx diff = %lx\n",val1,val2, val1-val2);
X	}
X}
END_OF_FILE
if test 515 -ne `wc -c <'seqtest.c'`; then
    echo shar: \"'seqtest.c'\" unpacked with wrong size!
fi
# end of 'seqtest.c'
fi
if test -f 'seqtest.h' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'seqtest.h'\"
else
echo shar: Extracting \"'seqtest.h'\" \(502 characters\)
sed "s/^X//" >'seqtest.h' <<'END_OF_FILE'
X#ifdef V40
X#define	SEQ_LT(a,b)	(((a)-(b))&0x80000000)
X#define	SEQ_LEQ(a,b)	(!SEQ_GT(a,b))
X#define	SEQ_GT(a,b)	SEQ_LT(b,a)
X#define	SEQ_GEQ(a,b)	(!SEQ_LT(a,b))
X#endif
X#ifdef VAX
X#define	SEQ_LT(a,b)	((int)((a)-(b)) < 0)
X#define	SEQ_LEQ(a,b)	((int)((a)-(b)) <= 0)
X#define	SEQ_GT(a,b)	((int)((a)-(b)) > 0)
X#define	SEQ_GEQ(a,b)	((int)((a)-(b)) >= 0)
X#endif
X#ifdef CTIX
X#define	SEQ_LT(a,b)	((a) < (b))
X#define	SEQ_LEQ(a,b)	((a) <= (b))
X#define	SEQ_GT(a,b)	((a) > (b))
X#define	SEQ_GEQ(a,b)	((a) >= (b))
X#endif
END_OF_FILE
if test 502 -ne `wc -c <'seqtest.h'`; then
    echo shar: \"'seqtest.h'\" unpacked with wrong size!
fi
# end of 'seqtest.h'
fi
if test -f 'seqtest.mk' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'seqtest.mk'\"
else
echo shar: Extracting \"'seqtest.mk'\" \(258 characters\)
sed "s/^X//" >'seqtest.mk' <<'END_OF_FILE'
Xall: ctixtest vaxtest v40test
X
Xctixtest: seqtest.c
X	$(CC) -g -o ctixtest -DCTIX seqtest.c
Xvaxtest: seqtest.c
X	$(CC) -g -o vaxtest -DVAX seqtest.c
Xv40test: seqtest.c
X	$(CC) -g -o v40test -DV40 seqtest.c
Xclean:
X	rm -f ctixtest vaxtest v40test
Xclobber: clean
X	
END_OF_FILE
if test 258 -ne `wc -c <'seqtest.mk'`; then
    echo shar: \"'seqtest.mk'\" unpacked with wrong size!
fi
# end of 'seqtest.mk'
fi
if test -f 'srvr.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'srvr.c'\"
else
echo shar: Extracting \"'srvr.c'\" \(1985 characters\)
sed "s/^X//" >'srvr.c' <<'END_OF_FILE'
X#include <sys/types.h>
X#include <sys/socket.h>
X#include <sys/time.h>
X#include <netinet/in.h>
X#include <netdb.h>
X#include <stdio.h>
X#include <errno.h>
X
X#define TRUE 1
X
Xint sock, length, count;
Xstruct sockaddr_in server;
Xint msgsock;
Xchar bufr[20100];
Xchar bufs[20100];
Xint rval,rslt;
Xstruct timeval to;
X
X
Xrecv_msg()
X{
Xint rval;
X		{
X		rval = read(msgsock,bufr,20100);
X
X		if (rval == -1)
X			{
X			perror("reading stream message");
X			exit(1);
X			}
X		else 
X		if (rval == 0)
X			{
X			printf("\nEnding Connection.");
X			exit(5);
X			}
X
X		else
X		/* if ((count/2010000)*2010000 == count ) */
X			{
X			/*
X			printf("message recvd length = #%d\n",rval);
X			printf("errno = #%d\n", errno);
X			*/
X			rslt = strncmp(bufr,bufs,rval);
X			if (rslt)
X				{
X				printf("buffers did not compare\n",rslt);
X				}
X			}
X
X          count+=rval;
X
X		}
X}
X
X
Xsend_msg ()
X{
Xint rval;
X
X		{
X		errno = 0;
X		rval =write(msgsock,bufs,sizeof(bufs));
X		if (rval == -1)
X			{
X			perror("wrting stream message");
X			exit(4);
X		     }	 
X		else 
X		if (rval == 0)
X			{
X			perror("write error\n");
X			printf("\nEnding Connection.");
X			exit(5);
X			}
X
X		else
X		 /* if((count/1000)*1000 == count) */
X			{
X			printf("message sent length = #%d\n",rval);
X			printf("errno = #%d\n", errno);
X			}
X		count+=1;
X		}
X}
X
Xmain()
X{
Xint i;
X
X	for(i=0;  i<20100;i++) bufs[i] ='a';
X	sock = socket(AF_INET,SOCK_STREAM,0);
X	if (sock < 0)
X		{
X		perror("opening socket");
X		exit(1);
X		}
X
X	server.sin_family = AF_INET;
X	server.sin_addr.s_addr=INADDR_ANY;
X	server.sin_port = 0;
X	if (bind(sock,&server,sizeof(server)))
X	    {
X	    perror("bind error");
X	    exit(2);
X	    }
X	length = sizeof(server);
X	if (getsockname(sock,&server,&length))
X	    {
X	    perror("getsockname error");
X	    exit(3);
X	    }
X	printf("socket has a port number #%d\n",ntohs(server.sin_port));
X
X	listen(sock,5);
X	msgsock = accept(sock,(struct sockaddr *) 0, (int *) 0);
X	if (msgsock == -1)
X	   {
X	   perror("accept");
X	   exit(4);
X	   }
X
X		do
X			{
X			recv_msg();
X			}
X		while(TRUE);
X}
END_OF_FILE
if test 1985 -ne `wc -c <'srvr.c'`; then
    echo shar: \"'srvr.c'\" unpacked with wrong size!
fi
# end of 'srvr.c'
fi
echo shar: End of shell archive.
exit 0

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 13:18:58 GMT
From:      rawe@iwisp1.iwi.uni-sb.de (Ralf Wein)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Route problems


Hi everybody,

I have a problem with my router between Token-Ring and Ethernet.
Both have their own subnets, but only Ethernet is working fine.
The router is an PS/2 with AIX Rel. 1.2 and TCPIP is Version 1.2.
In the Token-Ring are some UNIX-machines (IBM RTs, AIX PS2s, RS/6000),
an IBM AS/400 and DOS-PC with AADU (AIX Access for DOS Users).

When starting the systems, communications work. But when two machines in the
Token-Ring talk together (ping is enough) they loose their route-entry to the
router. This had been static defined with
 oroute add net <subnet> <router> 1o.
The only way to solve this problem was a static host-route entry on my 
router for every machine in the Token-Ring (dont know why but it works).
The second problem is: AADU does not recognize the computers in the
Token-Ring since I have installed the router.

Ralf

Please mail me to address rawe@iwisp1.iwi.uni-sb.de
(this computer is in the ethernet, uff)

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 13:21:58 GMT
From:      ssanbeg@visual.spk.wa.us (Scott Sanbeg)
To:        comp.os.os2.misc,comp.protocols.tcp-ip
Subject:   Building a LAN around OS/2 -- Newbie asks advice

Hello All,

I'd like suggestions/advice for configuring a LAN around OS/2 v1.3 now,
v2.0 later. Please reply via email.

A current project I'm working on involves a SLIP line, one high-speed modem
at each end (Intel 9600EX?), a WD8003 Ehternet card and a seperate PC used
as a router -- this is what has been suggested to me.

Basically, I don't know if PPP is more efficient than SLIP, if TELENET is
better, if I want something NCSA, if the OS/2 machine can also background
the router functions, do I want to use FTP as much as I'd like to, how
well the WD8003 card works with OS/2, if there is a more efficient LAN
I can build than outlined above? You get the picture...

So if you can help, please do.
Scott
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Scott Sanbeg   Spokane, Wa.   Voice:509/535-2561    BIX: ssanbeg
ssanbeg@visual.spk.wa.us (or) visual!ssanbeg@tau-ceti.isc-br.com

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 13:47:49 GMT
From:      bill@connection.prospect.com (Bill Poitras)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In article <1991Aug29.041708.29784@unislc.uucp> martin@unislc.UUCP (Martin Cryer,D1Z01,5754) writes:
>I think you are asking too much of a timesharing O/S even with an EISA
>PC to get sustained 6Mbytes/s. If you only want it for bursts, you
>may have better luck.

Are you kidding?  I have seen 100Mbytes/s when ftping a file to a PS/2
running AIX with a ESDI controller and 16 bit ethernet controller.  I can
consitently get 20Mbytes/s.  Hell, I can get 11Mbytes/s sometimes to a PC
running DOS.  This is a ISA machine with a 16bit RLL controller.  I don't
see your problem.

+-----------------+---------------------------+-----------------------------+
| Bill Poitras    | Polygen Corporation       | {princeton bu}!polygen!bill |
|     (bill)      | Waltham, MA USA           | - This space for rent -     |
|                 | FAX (617)890-8694         | bill@polygen.com            |
+-----------------+---------------------------+-----------------------------+

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 13:54:35 GMT
From:      jjohnson@HNS.COM (Jayne Johnson)
To:        comp.protocols.tcp-ip
Subject:   IP performance evaluation


I'm evaluating the network performance of a single board computer running
a single ethernet controller and TCP/IP. The board supports the Intel 
82596 ethernet controller. Before I start the performance test, I thought
I could ask the community if anyone has tested the CPU overhead in the IP
layer for fragmenting and reassembling frames to and from the ethernet 
device interface. Thanks in advance for your help in this matter.

I am using Wind River System's BSD4.3 tahoe release of TCP/IP. I am interested
in measurements for both TCP and UDP messages. Has any other the TCP/IP
founders written any papers concerning this subject? The numbers I am looking
for are ballpark , does it take N millisecs/frame vs N microsecs / frame ?

Jayne F. Johnson
email: jjohnson@hns.com

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 14:19:02 GMT
From:      ajayshah@alhena.usc.edu (Ajay Shah)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In article <1991Aug29.134749.5982@ctr.columbia.edu> bill@connection.prospect.com (Bill Poitras) writes:
>Are you kidding?  I have seen 100Mbytes/s when ftping a file to a PS/2
>running AIX with a ESDI controller and 16 bit ethernet controller.  I can
>consitently get 20Mbytes/s.  Hell, I can get 11Mbytes/s sometimes to a PC
>running DOS.  This is a ISA machine with a 16bit RLL controller.  I don't
>see your problem.
I thought Ethernet was hardcoded to max out at 10 million _bits_
per second.  Have I been away and missed a lot of action, or is
something going wrong?

Does someone have data of FDDI performance on Suns?  That should
be interesting...
-- 
_______________________________________________________________________________
Ajay Shah, (213)734-3930, ajayshah@usc.edu
                             The more things change, the more they stay insane.
_______________________________________________________________________________

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 14:42:06 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window


    ...the probe time should be the same as the retransmission time, with
    exponential backoff, and not 2 minutes (!). Berkeley uses a minimum of
    5 seconds (as much as a 1000 times too large on an Ethernet), which makes
    for pretty poor performance if you do drop a probe.

Is this the same logic that prevents them from sending a segment if the
foreign window isn't as large as their minimum segment size, even if all
outstanding data is already ack'ed?  If so, there's more than one reason
to work on it...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 14:46:09 GMT
From:      dwex@cbnewsj.cb.att.com (david.e.wexelblat)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In article <1991Aug29.134749.5982@ctr.columbia.edu> bill@connection.prospect.com (Bill Poitras) writes:
> In article <1991Aug29.041708.29784@unislc.uucp> martin@unislc.UUCP (Martin Cryer,D1Z01,5754) writes:
> >I think you are asking too much of a timesharing O/S even with an EISA
> >PC to get sustained 6Mbytes/s. If you only want it for bursts, you
> >may have better luck.
> 
> Are you kidding?  I have seen 100Mbytes/s when ftping a file to a PS/2
> running AIX with a ESDI controller and 16 bit ethernet controller.  I can
> consitently get 20Mbytes/s.  Hell, I can get 11Mbytes/s sometimes to a PC
> running DOS.  This is a ISA machine with a 16bit RLL controller.  I don't
> see your problem.
> 
> +-----------------+---------------------------+-----------------------------+
> | Bill Poitras    | Polygen Corporation       | {princeton bu}!polygen!bill |
> |     (bill)      | Waltham, MA USA           | - This space for rent -     |
> |                 | FAX (617)890-8694         | bill@polygen.com            |
> +-----------------+---------------------------+-----------------------------+


Am I missing something here?  Isn't Ethernet a 10Mb/sec network?  How,
exactly, does one one 100Mbytes/sec over a medium that only supports
10Mb/sec?  Or are you using FDDI?  Or maybe I have no clue?


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Wexelblat             | dwex@mtgzz.att.com    | I asked her her name.
AT&T Bell Laboratories      | ...!att!mtgzz!dwex    |   She said her name was
200 Laurel Ave - 4B-421     |                       |      'Maybe'
Middletown, NJ  07748       | (908) 957-5871        | --Damn Yankees

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 15:39:30 GMT
From:      ats@phoenix.udev.cdc.com (alex t stagg x4718)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In article <1991Aug29.134749.5982@ctr.columbia.edu> bill@polygen.com
(Bill Poitras) writes:
>Are you kidding?  I have seen 100Mbytes/s when ftping a file to a PS/2
>running AIX with a ESDI controller and 16 bit ethernet controller.  I can
>consitently get 20Mbytes/s.  Hell, I can get 11Mbytes/s sometimes to a PC
>running DOS.  This is a ISA machine with a 16bit RLL controller.  I don't
>see your problem.

Hmmm.
100Mbytes/second * 8bits/byte = 800Mbits/second.
Pretty good for a 10Mbit/second media. Roll over, Einstein.

Alex.

----------------------------------------------------------------
A. T. (Alex) Stagg/ARH215      | INTERNET: ats@udev.cdc.com
Control Data Corporation       |
4201 Lexington Ave.N.          | fax:      01-612-482-2791
Arden Hills, MN USA 55126-6198 | Voice:    01-612-482-4718

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 16:15:21 GMT
From:      chip@osh3.OSHA.GOV (Chip Yamasaki)
To:        comp.protocols.tcp-ip
Subject:   Oops,  I missed it. . .

Sorry for the extra chatter, but about three days ago I was reading a
very interesting posting here in this group that must have been about a
3 weeks to a month old.  This posting seemed to be explaining something
about TCP-IP and/or the Internet.  While I was reading it my very
attentive but not very polite C News software expired the article so I
couldn't get a chance to save a copy.

I realize there are a huge number of "very interesting" postings here,
but if anybody can guess what it could have been and where I can get a
copy (or if the Author can re-post it).  I would appreciate it.

Please DON'T E-Mail them directly without contacting me first.  I'm
affraid with all of the well meaning people out there I might get
hundreds of copies of a sizeable document.

Thanks!
-- 
-----------------------+---------------------------------------------------
Charles "Chip" Yamasaki| The opinions expressed here are my own and are not
chip@oshcomm.osha.gov  | supported or even generally accepted by OSHA. :-)
-----------------------+---------------------------------------------------

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 16:39:46 GMT
From:      ghelmer@dsuvax.dsu.edu (Guy Helmer)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In <1991Aug29.134749.5982@ctr.columbia.edu> bill@connection.prospect.com (Bill Poitras) writes:

>In article <1991Aug29.041708.29784@unislc.uucp> martin@unislc.UUCP (Martin Cryer,D1Z01,5754) writes:
>>I think you are asking too much of a timesharing O/S even with an EISA
>>PC to get sustained 6Mbytes/s. If you only want it for bursts, you
>>may have better luck.
 
>Are you kidding?  I have seen 100Mbytes/s when ftping a file to a PS/2
>running AIX with a ESDI controller and 16 bit ethernet controller.  I can
>consitently get 20Mbytes/s.  Hell, I can get 11Mbytes/s sometimes to a PC
>running DOS.  This is a ISA machine with a 16bit RLL controller.  I don't
>see your problem.

I'd be more inclined to think you're kidding, Mr. Poitras!  You may have
seen 100 K (KILOBYTES!) per second.  If you've really seen 100Mbytes/sec
doing anything on a PC over any network, there are a lot of people
out here who'd like to know how you do it.
-- 
          Guy Helmer, Dakota State University Computing Services
ghelmer@dsuvax.dsu.edu, helmer@sdnet.bitnet, dsuvax!ghelmer@wunoc.wustl.edu

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 16:44:08 GMT
From:      torek@elf.ee.lbl.gov (Chris Torek)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

>In article <1991Aug29.041708.29784@unislc.uucp> martin@unislc.UUCP
 (Martin Cryer,D1Z01,5754) writes:
>>I think you are asking too much of a timesharing O/S even with an EISA
>>PC to get sustained 6Mbytes/s. If you only want it for bursts, you
>>may have better luck.

In article <1991Aug29.134749.5982@ctr.columbia.edu>
bill@connection.prospect.com (Bill Poitras) writes:
>Are you kidding?  I have seen 100Mbytes/s when ftping a file to a PS/2
>running AIX with a ESDI controller and 16 bit ethernet controller. ...

100 megaBYTES per second over a ten megaBITS per second link is quite
remarkable.  Even Van Jacobson, long acknowledged the TCP speed wizard,
has yet to exceed the hardware bandwidth limits. :-)

Seriously: full Ethernet wire speed is possible; Van has been doing it
for some time.  It requires tuning the software, and in some cases
discarding broken hardware (such as the Intel 82586 Ethernet controller);
it also tends to put a strain on the bandwidth of the narrower busses
(including many workstation or PC memory busses).  Getting 60%, or
6 MB/s, sustained throughput should not be too hard though.

100 MB (megabytes, not megabits) per second is possible, but requires
the ability to do 25 million 4-byte bus cycles per second, or 50
million 2-byte bus cycles per second; most small-machine busses are
simply not up to this.  Of course, it also requires a `wire' capable of
the same rate.  FDDI is 100 Mb (megaBITS) per second: a mere 12.5 MB/s,
well in reach of current workstation capabilities.

Waiting for 100 Gb/s links :-) ,
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
		new area code as of September 2, 1991: +1 510 486 5427

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 16:55:58 GMT
From:      barns@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window

I proposed the RFC 1122 text in question (actually it was modified
somewhat by the WG and the editor, but not radically altered) so I guess
it falls to me to defend it.  I have some old email discussion of this
point that I can forward to anyone who asks.  It seemed a bit too much
to post (a few pages).  Yes, the exact starting point for zero window
probe interval is not the point, except that it should be small, so
that certain transient pathologies don't waste a lot of real time for no
good reason.  Exponential backoff with constant > 1 is the key.  It's
convenient for the implementor to use the exact same algorithm as for
normal retransmission, so you don't have to write more special code.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 17:34:32 GMT
From:      rusty@b17a.ingr.com (Rusty)
To:        comp.protocols.tcp-ip
Subject:   .netrc


	Excuse me if this is old hat, but I would like to
	see an example of a .netrc file. I am working on
	a script to execpt pass-through commands and would
	like to see if ftp and a resource file like .netrc
	would works. Thanks for your time.
-- 
                                      Thanks,
                                      Rusty Wiginton (205)730-7567 
                                      (UUCP) uunet!ingr!b17a!rusty
                                      (Internet)b17a!rusty@ingr.com

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 18:14:28 GMT
From:      mlong@IASTATE.EDU (Michael C Long)
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 Bug. Follow-up..

In article <1991Aug28.133910.22520@njitgw.njit.edu>, pv0618@hertz.njit.edu
(Paranjothi Varadarajan) writes:
> 
> 
> Thanks for replying folks ...
> 
> I received following response from somebody on the net regarding my
> earlier posting, but am not sure how to map this onto my hp-ux tcp
> stuff. 
> Some further tips would be of great help....
> 
> WERE USING IBM'S TCP/IP FOR THE PC FEATURE OF THE TCP/IP FOR VM AND WERE
> TELNETING TO THE VM MACHINE.  WHEN WE WOULD GET INTO CMS AND X-EDIT A
> FILE THE
> 'F' KEYS WOULD CAUSE A LOCK-UP, BUT TYPEING IN THE X-EDIT COMMAND (LIKE
> QQUIT)
> WOULD NOT CAUSE A LOCKUP.  THE ONLY WAY WE COULD MAKE THIS WORK WAS TO
> SET THE
> PC'S 'TCP RECEIVE BUFFER' AND 'TCP LOW WINDOW' TO 220 BYTES.  THEN OUR
> X-EDIT
> WORKED PERFECTLY.  AS WE HAVE JUST PUT ON VER. 2.0 ONTO OUR VM MACHINE,
> I WAS
> EXPIRIMENTING TODAY WITH X-EDIT'S F KEYS AND THE PC'S BUFFER SIZES, BUT
> I COULD
> NO LONGER DUPLICATE THIS PARTICULAR PROBLEM.
> 
> HOPE THIS HELPS
> MIKE LONG
> CENTER FOR AGRICULTURAL AND RURAL DEVELOPMENT
> IOWA STATE UNIVERSITY
> AMES, IA 50011
> 
> Thanks once again...
I AM SORRY THAT I CAN'T REALLY PROVIDE ANY MORE DETAILS BECAUSE I KNOW NOTHING
ABOUT HOW UNIX DEALS WITH IT'S TCP/IP BUFFER SIZE.  THE ONLY UNIX COMMAND I KNOW
IS 'XRN'.   MY WIFE IS A SYSTEM PROG. FOR A HP UNIX BOX, I CAN ASK HER IF SHE
KNOWS HOW TO DUPLICATE WHAT WE HAVE DONE TO OUR PC DOS TCP/IP.  ALSO, MAYBE TRY
TO GET THE V2R1 OF IBM'S TCP/IP, AS OUR PROBLEM SEEMED TO DISAPPEAR WITH OUR
UPGRADE.

I WILL POST AN UPDATE IF THE WIFE HAS ANY IDEAS...

MIKE LONG (MLONG@ISUCARD.BITNET  OR MLONG@CARD.IASTATE.EDU) 

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 19:19:37 GMT
From:      erikm@hardy.u.washington.edu (Erik Madsen)
To:        comp.protocols.tcp-ip
Subject:   Changing from ASYNC to TCP/IP while still keeping security?

We recently got an Internet feed at my place of employment.  Our MIS 
people have limited our connection from our desktop machines to our internet
gateway to asyncronous connectivity; they claim that by using async, they
can control the flow of traffic to being a one way street: that is, if
anyone logs into our internet server from the outside, they cannot further
get into our corporate subnet.

My problem is I can only connect to the internet server at 9600 baud from
my Mac (my term prog limits me to that using a direct connect) and 19200
from my PC.  Both computers are running Ethernet, however.  What I want to
do is propose to the MIS people that we can still keep the same security
we have now (or maybe do smarter security) and get faster connections between
our corporate net (our desktop computers) to our internet server (and
still convincing them that if we do that, we are not opening our corporate
net to the outside internet world.  

Is there any documented material (with maybe graphic representations!) on
this sort of setup?  I'd like to be able to make a proposal using stuff from
other authors/publishers/or anyone else who's done this sort of thing, so
it doesn't look like I'm some rebel trying to jeopordize security.  We had
this sort of setup at Boeing, or something similar.
We are currently running XNS on our corp net... wouldn't TCP/IP be able
to coexist with this also?


Any help would be much appreciated!

Thanks much
Erik

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 21:12:05 GMT
From:      emcguire@ccad.uiowa.edu (Ed McGuire)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   how to keep /etc/hosts up to date

We've got a few systems running BSD networking without support for
BIND in the network library routines.  Their /etc/hosts, /etc/networks,
/etc/gateways, etc., files are out of date, and I'm looking for
ideas on updating them.

There are three sources of information that I'd like to include in
the updated files.  First, I need our own departmental information.
Since we maintain the local BIND server ourselves, it is easy to
derive the appropriate information from the BIND database source
files by writing a translator.  No problem there.

Second, I need University-wide information.  I'd like to get this
data by querying BIND itself, but I don't know how to get started.
This part of /etc/hosts has been maintained by hand in the past.
Is there a better (i.e., automated, BIND-based) approach?

Third, I need well-known Internet sites and networks.  I can get
the DoD Internet Host Table from the NIC (using gettable), and this
may be enough.  I have a copy of htable which generates /etc/hosts,
/etc/networks, and /etc/gateways data from an RFC 810 input file.
But I am stumped by the "-c" (connected) and "-l" (local) switch
descriptions in the man page, which evidently determine how the
/etc/gateways file is built.  I don't know whether to list the
local subnet, all subnets, or whether to ignore subnetting entirely
and list only nets.  Every combination of arguments I've tried has
given me a blank gateways file.  I don't even know whether to be
concerned about this.
-- 
peace.  -- Ed
"Over here, Bones!  This man's dying!"
"Damn it, Jim!  I'm a doctor, not a . . .  What did you say?"

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 22:04:17 GMT
From:      jreece@stravinsky.intel.com (John Reece)
To:        comp.protocols.tcp-ip
Subject:   Re: Changing from ASYNC to TCP/IP while still keeping security?

In article <1991Aug29.191937.10748@milton.u.washington.edu>, erikm@hardy.u.washington.edu (Erik Madsen) writes:

|> What I want to do is propose to the MIS people that we can still keep 
|> the same security we have now (or maybe do smarter security) and get 
|> faster connections between
|> our corporate net (our desktop computers) to our internet server (and
|> still convincing them that if we do that, we are not opening our corporate
|> net to the outside internet world.  

 
Most gateway routers these days have security filters that at least
allow you to screen incoming and outgoing packets by source address,
destination address, and protocol information.  Try Cisco Systems at (800)
553-NETS.  They also support other protocols such as Decnet.  

If you think your security setup is screwy, there was one site 
here that figured it could protect its machines from Internet raiders
by keeping their hostnames out of the Intel host table...

-- 

John Reece			|   -- You are in a maze of twisty
Not an Intel spokesman          |      little logging roads, all alike --

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 91 22:13:53 GMT
From:      SKDLG@CUNYVM.BITNET (Dimitri)
To:        comp.protocols.tcp-ip
Subject:   QUESTION ON NYSERNET

I don't know if this is the correct section to post this article,but I need
an answer-suggestion as soon as possible!I'm trying to access NYSERNET by
using Telnet at the following Internet address 192.35.82.1. but the system
obviously does not have a guest account where i can hook up as an anonymous
user.Does anybody know any way(s) that I can access NYSERNET as an anonymous
user(guest)?? I would appreciate if somebody can post something on this section
or E-mail me at the following address!SKDLG@CUNYVM.CUNY.EDU
Thank u very much in advance,DIMITRI SKOULARAKOS.

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 91 00:31:40 GMT
From:      mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: What's your IP Time to Live?

In article <9108220121.AA05015@jessica.stanford.edu> almquist@JESSICA.STANFORD.EDU ("Philip Almquist") writes:
>	The official recommended value for IP Time-to-Live can always be
>found in the Assigned Numbers RFC.  The current version of that document,
>RFC-1060, recommends a TTL of 32.

I wonder.  It seems that ICMP Echo Replies and ICMP Port Unreachable
errors from Unix systems use a TTL of 255.  Can anyone summarize the
actual Unix behavior and perhaps revise the Politically Correct
behavior accordingly?
 -+-+-   | -++-  --|--    /__ Mark ("Gaijin") Crispin "Gaijin!  Gaijin!"
+-|-|-+ -+-++++  +-|-+   /  / R90/6 pilot; DoD #0105  "Chigau. Omae ha gaijin."
+-+-+-+  |\||||  |===|  /  /  Atheist & Proud         "Iie, boku ha nihonjin."
 --|--  /| |/\| -+===+-   /\  (206) 842-2385/543-5762 "Souka. Yappari gaijin!"
  /|\    | |__|  /   \   /  \ FAX: (206) 543-3909
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanakute mo shiranai yo.

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 91 00:51:55 GMT
From:      hayes@blaise.trl.OZ.AU (Mark Hayes)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: Any results from Gbits testbeds ?

craig@sics.se (Craig Partridge) writes:

>>Couls anyone tell me if there are any (preliminary) test results or other
>>conclusions available somewhere on the NSF net sponsored Gigabit testbeds ?
 
>Marten:
>    
>    Sure, there are lots of results beginning to come out.  There are various
>sources.  The testbeds produce annual reports on their work and some of them
>are publicly available.  Some papers are beginning to be published -- there
>will be a few at SIGCOMM '91 in Zurich next week.  I believe we'll see some
>articles in the March '92 issue of IEEE Network (though this is still being
>worked out).

Can anyone list the Gigabit testbeds and who one might contact (via
email preferably) for any copies of their reports?

Cheers,
mdh
-----------------------------------------------------------------
Mark Hayes					Research Labs,
m.hayes@trl.oz.au				Telecom Australia

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 91 01:16:52 GMT
From:      glenn@aic.co.jp (Glenn Mansfield)
To:        comp.protocols.tcp-ip
Subject:   Joining the mailing list


Dear Administrator,
Could you please add glenn@aic.co.jp to the TCP-IP mailing list.
Thank you.
				glenn

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 91 01:43:40 GMT
From:      gja@mullian.ee.mu.oz.au (Grenville Armitage)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In article <1991Aug29.134749.5982@ctr.columbia.edu> bill@connection.prospect.com (Bill Poitras) writes:
	[..]
>Are you kidding?  I have seen 100Mbytes/s when ftping a file to a PS/2
>running AIX with a ESDI controller and 16 bit ethernet controller.  I can
>consitently get 20Mbytes/s.

Hey, Bill. I've got this little plan for 'fusion in a jar' that I
was wondering if you'd like to invest in. Yes, it's true.
Cold fusion.

:-)

gja

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 91 02:12:38 GMT
From:      merce@iguana.uucp (Jim Mercer)
To:        bit.listserv.novell,comp.protocols.tcp-ip
Subject:   ka9q bootp and POP (was: Re: KA9Q or PcRoute)

In article <MAILQUEUE-99.910827132859.229@novl1.ci.cuslm.ca> jocelyn@cuslm.ca writes:
>One problem : KA9Q does *NOT* forward bootp packets.  I think PCRoute
>should, but never tried it.

aahh, but you can get source, so there shouldn't be a reason why it can't.

a caveat for ka9q bootp users:

we found that the bootptab entry array in our version (early june 91) was
limited to 12.

increasing it to a "larger" number caused it to run out of dataspace.

compiling in the Huge model proved difficult.

we have hacked it to dynamically allocate entry space.

another caveat:

grep for strcmp/strncmp.  it seems that in some places binary addresses
(ip and/or physical) are being compared as strings (not good for addresses
like 00:C0:...)

while i have some ka9q enthusiasts attention, has anyone got the ka9q POP
server to work with POPmail (PC version)?

-- 
[ Jim Mercer   work: jim@lsuc.on.ca  home: merce@iguana.uucp  +1 519 570-3467 ]
[ ".. a provisioned lunch box was equipment as essential as a rifle had been  ]
[  to earlier pioneers--a shield against an uncertain future, a badge of      ]
[  membership, a friend." -- Scott Bruce                                      ]

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 91 03:50:37 GMT
From:      mikec@dosli.govt.nz (Michael Curtis)
To:        comp.protocols.tcp-ip
Subject:   unused well-known ports


I want to set up a server on a well-known port, and put an entry in 
/etc/services and /etc/inted.conf for it. How do I decide which port to use
(other than just using one of the unused numbers under 1024) ?

------
Michael Curtis (mikec@dosli.govt.nz)
Department of Survey and Land Information
Wellington, New Zealand

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 91 05:51:55 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: Any results from Gbits testbeds ?

In <1991Aug30.005155.13390@trl.oz.au> hayes@blaise.trl.OZ.AU (Mark Hayes) writes:


>Can anyone list the Gigabit testbeds and who one might contact (via
>email preferably) for any copies of their reports?

Ooops, that somehow fell out of my original note.  The testbeds are listed
in IEEE Computer magazine (sept 90) issue along with contact addresses.

Craig

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 91 07:42:49 GMT
From:      AKayser@dnpap.et.tudelft.nl (Alfred Kayser)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
>In article <1991Aug29.134749.5982@ctr.columbia.edu> bill@connection.prospect.com (Bill Poitras) writes:
>> In article <1991Aug29.041708.29784@unislc.uucp> martin@unislc.UUCP (Martin Cryer,D1Z01,5754) writes:
>> >I think you are asking too much of a timesharing O/S even with an EISA
>> >PC to get sustained 6Mbytes/s. If you only want it for bursts, you
>> >may have better luck.
On normal systems it is more around 100-500Kb/s !!

>> Are you kidding?  I have seen 100Mbytes/s when ftping a file to a PS/2
>> running AIX with a ESDI controller and 16 bit ethernet controller.  I can
>> consitently get 20Mbytes/s.  Hell, I can get 11Mbytes/s sometimes to a PC
>> running DOS.  This is a ISA machine with a 16bit RLL controller.  I don't
>> see your problem.
Jokes like these belong in rec.humor!!!!!

>Am I missing something here?  Isn't Ethernet a 10Mb/sec network?  How,
>exactly, does one one 100Mbytes/sec over a medium that only supports
>10Mb/sec?  Or are you using FDDI?  Or maybe I have no clue?
Indeed, ethernet is 10Mbits/sec, so 1.25Mbytes is theoratical maximum.
However the statistics reported by FTP are mostly very wrong,
especially for small files. The timer granularity used by ftp is too large
to accurately measure actual throughputs. Also I've detected that not
all is sent when the socket is closed. After the socket close there are
still packets going over ethernet.

Thanks anyway for the joke, Alfred


>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>David Wexelblat             | dwex@mtgzz.att.com    | I asked her her name.
>AT&T Bell Laboratories      | ...!att!mtgzz!dwex    |   She said her name was
>200 Laurel Ave - 4B-421     |                       |      'Maybe'
>Middletown, NJ  07748       | (908) 957-5871        | --Damn Yankees
--
-- Ir. Alfred Kayser. PACS, OS/2, TCP/IP. --- Email: AKayser@et.tudelft.nl --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 91 13:48:56 GMT
From:      josevela@mtecv2.mty.itesm.mx (Jose Angel Vela Avila)
To:        bit.listserv.novell,comp.protocols.tcp-ip
Subject:   Re: ka9q bootp and POP (was: Re: KA9Q or PcRoute)


 Yes ! PC-ROUTE forwards BOOTP packets ...

 We have running it !!
Bye.

 _____________________________________________________________________________

 Jose Angel Vela Avila. 
  
  Instituto Tecnologico y de Estudios Superiores de Monterrey
    I.T.E.S.M

  Mexico.
  ___               _    ___  _         __
 (   >             ' )  /    //        /  )  josevela@mtecv2.mty.itesm.mx
  __/________    _  (  / _  // __.    /--/   josevela@tecmtyvm.mty.itesm.mx
 / /  (_)  \_)__</_  \/ </_</_(_/|_  /  ( o  josevela@tecmtyvm.BITNET
<_/

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 91 14:24:00 GMT
From:      DAMIAN@SRLVX0.SRL.FORD.COM ("Jerry Damian")
To:        comp.protocols.tcp-ip
Subject:   NFS Network Bandwidth Utilization

I'm looking for information/experiences with the large scale deployment of
NFS on a Ethernet LAN. How can I measure the impact of a client workstation
mounting a remote file system? Long term we are looking at using AFS, but
util most of our workstation move to OSF/DCE, we have to use NFS to share
file systems between Suns, DECs, HP/Apollos, and PCs running PC/NFS. How
many mounts are too much? Also, I have heard that NFS has an impact on the
net even if files are not being copied. Is this true? Please send to me and
I will sumarize and post.

			Jerry Damian
			Ford Motor Car Company
			CAE Workstation Support Unit

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 91 02:31:37 GMT
From:      martillo@crackers.clearpoint.com (Martillo)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Using Wide-Area Point-to-Point Links for Computer Networking (I)

The following memorandum is a first draft of one of a pair of potential
RFCs which specify a methodology for using wide-area serial synchronous
DCE/DTE-type point-to-point links as a computer networking medium.  The
Clearpoint Little Dipper/Auriga product line offer as one of several
configurable options a wide-area interface which implements this
specification, and should a developer implement this interface for his
bridge, router or end host, that network device will be able to
communicate with the Little Dipper/Auriga products over point-to-point
serial links as well as any other device which implements this
specification.  Comments on this draft are welcome. 

----------------------------------------------------------(Cut Here)-----



                                                                        1

            RFC SLITHER              SLITHERNET                July 1991



            Clearpoint Research Corporation                  J. Martillo
            Request for Comments: XXXX                                  
            August 1991                                                 


                              SLITHERNET:  A Proposal
                          for Using Moderate-To-High-Speed
                        Synchronous Serial Connections as a
                             LAN-like Networking Medium

            Status of this Memo

            This RFC  specifies  a  vendor  proposal  for  a  wide  area
            networking  system   which  uses   a  LAN-like  architecture
            (SLITHERNET).  This LAN-like architecture is built on top of
            full-duplex  bidirectional   synchronous  serial   non-self-
            clocking  point-to-point   DTE/DCE  connections   which  are
            supported by  the class  of interfaces  of which RS-232, RS-
            449, V.35, X.21 are representative examples.

            This proposal  formalizes knowledge and experience gained in
            implementing a  IEEE 802.1d  MAC bridge  which supports IEEE
            802.3 and RS-232, RS-449, V.35, RS-530 and X.21 interfaces.

            Abstract

            WANs are  characterized by highly intelligent communications
            subnets  with   Packet  Switching  Nodes  (PSNs)  and  other
            intelligent devices  which carry  out most  of the  work  of
            packet switching  and routing  throughout the  network while
            end hosts  are little  more than almost passive users of the
            services which the WAN communications subnet provides.  LANs
            are characterized  by  rather  unintelligent  communications
            subnets (like  ETHERNET coaxial  cables) which  do little in
            the way  of switching and routing while the end hosts rather
            actively take part in packet routing and transport often via
            methods like  packet  filtering  (ETHERNET)  or  via  packet
            repetition (Token Ring).

            IEEE 802.1d MAC bridging belies this distinction by creating
            a logical  intelligent ETHERNET  communications subnet.  The
            active topology  of this communications subnet is defined by
            the spanning  tree procedure.   The  MAC bridges derive this
            topology via the spanning tree protocol and algorithm.
















                                                                        2

            RFC SLITHER              SLITHERNET                July 1991

            Mathematically and in terms of networking behavior, there is
            essentially no  difference between two MAC bridges connected
            by a  moderate to high speed serial point-to-point wide area
            link and  two bridges  connected   by an  ETHERNET used as a
            point-to-point link  with no  other attached  hosts.    This
            essential equivalence  suggests that  MAC bridges  and hosts
            which are  interconnected via  wide-area serial links with a
            properly defined  link  layer  will  act  as  if  hosts  are
            interconnected via  a logical  ETHERNET with  full broadcast
            capability.

            When  802.1d   MAC  bridges   interconnect  ETHERNETs,  each
            separate spanning  tree  defines  a  logical  ETHERNET.  The
            ETHERNET   hardware   is   actually   unnecessary   in   the
            construction of  a logical  ETHERNET. A network of end hosts
            and MAC  bridges which  route packets  via the spanning tree
            protocol and  algorithm will  appear as  a logical  ETHERNET
            even if  the end  hosts connect  to MAC  bridges and the MAC
            bridges connect  to MAC  bridges via  serial  point-to-point
            DCE/DTE  links.    This  technique  of  creating  a  logical
            ETHERNET  without   any  ETHERNET   hardware  represents  an
            instantiation of the SLITHERNET or Serial LInk ETHERNET.

            I. Motivation

            The following are four reasons for developing the SLITHERNET
            proposal.

             1.  Customers have  expressed great  desire for  wide  area
                 interconnect between  pairs  of  geographically  remote
                 bridges  or  between  pairs  of  geographically  remote
                 routers.

             2.  There is  an increasing trend toward interconnection of
                 LANs  through  serial  line  technologies  besides  the
                 traditional ARPANET,  NSFNET and  PSPDN  communications
                 subnets.   A reasonably  simple  communications  subnet
                 architecture  and   mechanism  would   facilitate  such
                 interconnections, and  there has  been a  great deal of
                 discussion of  architecture and  routing  or  transport
                 mechanisms in many technical fora.

             3.  Wide-area serial-line  technology  and  LAN  technology
                 have matured  in the direction of convergence with each
                 other as  the availability  of parts increases which --
                 like the  AMD Am79C900  (ILACC), Zilog Z16C30 (USC) and
                 the Intel  82596CA -- support HDLC and IEEE 802.3 modes
                 with choice of CRC-32 and CRC-CCITT FCS.














                                                                        3

            RFC SLITHER              SLITHERNET                July 1991

             4.  The increasing number of proposed serial point-to-point
                 encapsulations (SMDS,  Frame Relay,  PPP etc.) suggests
                 that there  may be  some more fundamental architectural
                 issues in  point-to-point serial  networking which  are
                 currently unaddressed.

            The SLITHERNET  proposal represents  an attempt to specify a
            conceptually  simple,   integrative      technological   and
            architectural method  of wide-area  networking which fulfils
            customer needs.

             1.  SLITHERNET permits  the  user  to  choose  bridging  or
                 routing techniques as needed.

             2.  SLITHERNET simplifies  the interconnection  problem  by
                 using several  standard technologies  to  connect  end-
                 hosts to bridges.  If a customer wishes to use a public
                 data network which offers Frame Relay, SMDS or whatever
                 the latest  au courant  technology  should  be,  simply
                 installing  into  one  of  the  SLITHERNET  bridges  an
                 interface, which  supports the chosen technology, would
                 give all  the SLITHERNET  hosts access  to  the  public
                 network without  needing to  install such  an interface
                 into each end host.

             3.  SLITHERNET makes  maximum use  of  the  convergence  of
                 ETHERNET  and  WAN  technologies  so  that  expense  of
                 software and  hardware  development  can  be  decreased
                 through the  reuse of already existent software modules
                 and hardware design units.

             4.  Unlike PPP  which  merely  specifies  an  encapsulation
                 without tackling  the problem of designing a networking
                 architecture and  unlike  SMDS  or  Frame  Relay  which
                 assume customers desire connectivity to a single global
                 communications subnet,  SLITHERNET is  firmly based  in
                 the networking  architectures which have already proven
                 themselves to conform to customer needs and which offer
                 far greater security and control mechanisms.

            Yet, SLITHERNET  applies current  technology,  understanding
            and experience  to the  problem  of  reasonable  cost  high-
            performance WAN LAN internetworking.



















                                                                        4

            RFC SLITHER              SLITHERNET                July 1991

            II. Requirements

            A minimal  SLITHERNET network  consists  of  two  end  hosts
            connected by  a full-duplex bidirectional synchronous serial
            non-self-clocking point-to-point  link.   In this  case, one
            end host must provide clocking as a DCE while the other host
            receives clock  as a  DTE.   If neither end host can provide
            clock, each  end  host  would  connect  to  a  common  modem
            eliminator, or  each end  host would  connect to a DCE which
            can provide  clock  and  which  connects  to  some  sort  of
            telephone network.   The  telephone network  would provide a
            point-to-point connection between the two DCEs.

            A  more   general  SLITHERNET  communications  subnet  would
            consist of MAC bridges which interconnect via point-to-point
            serial links  and which  route frames  via the spanning tree
            algorithm and  protocol.   Some MAC bridges would connect to
            end hosts  rather than other MAC bridges.  Actual individual
            point-to-point connections  between MAC  bridges or  between
            MAC bridges  and end  hosts can  use the same methods as the
            minimal SLITHERNET  network and  can use any of the standard
            synchronous   point-to-point    non-self-clocking    DCE/DTE
            interfaces.   There is no homogeneity requirement either for
            connection method  or interface type.  Too great a diversity
            in link  speeds within the communications subnet is probably
            not a  good idea  without careful  planning, serious network
            design and rigorous traffic analysis.

            III. SLITHERNET Definition

            A SLITHERNET  consists of  N end hosts interconnected with M
            MAC bridges via full-duplex bidirectional synchronous serial
            non-self-clocking point-to-point  DTE/DCE connections  which
            are supported  by the  class of  interfaces of which RS-232,
            RS-449, V.35, X.21 are representative examples.  The details
            of  clocking  are  unimportant  in  that  either  end  of  a
            connection  may  provide  clock.    If  necessary,  a  modem
            eliminator may  be interposed between two devices to provide
            clock to  two devices  which can  only act  as  DTEs.    The
            degenerate case  of a  SLITHERNET consists  of two end hosts
            connected by  a point-to-point  serial connection and no MAC
            bridges.




















                                                                        5

            RFC SLITHER              SLITHERNET                July 1991

            A. SLITHERNET Frame Types

            A given  SLITHERNET link  will  carry  exactly  one  of  the
            following types of frames:

             1.  an ETHERNET 2.0 or IEEE 802.3 frame, EEEE, encapsulated
                 according  to   SLIDE  encapsulation   1  (RFC   SLIDE:
                 FLAG | DATA1 | CRC-CCITT | FLAG,      where       DATA1
                 corresponds to EEEE),

             2.  an ETHERNET 2.0 or IEEE 802.3 frame, EEEE equivalent to
                 NNNN | CRC-32, minus  the CRC-32 encapsulated according
                 to    SLIDE     encapsulation     2     (RFC     SLIDE:
                 FLAG | DATA2 | CRC-32 | FLAG, where  DATA2  corresponds
                 to NNNN  and CRC-32  is in both cases the ETHERNET CRC-
                 32) and

             3.  an ETHERNET 2.0 or IEEE 802.3 frame, EEEE equivalent to
                 NNNN | CRC-32, minus  the CRC-32 encapsulated according
                 to SLIDE  encapsulation  3  (RFC  SLIDE:  FLAG |  DATA3
                 | CRC-CCITT | FLAG, where DATA3 corresponds to NNNN and
                 CRC-32 is absent).

            The SLIDE leaky-bucket algorithm enables both devices at the
            end  of  a  point-to-point  link  to  negotiate  a  mutually
            acceptable encapsulation  mode or  the encapsulation  may be
            set by prior agreement.

            If a  MAC bridge  is primarily  devoted to bridging ETHERNET
            segments, if  the MAC  bridge has  at  least  one  wide-area
            interface without CRC-32 capability and if this interface is
            used for  wide  area  transparent  connectivity  to  another
            similar MAC bridging, using SLITHERNET frame type 1 over the
            associated WAN  link is  the most  natural choice.  In  this
            case,  the   MAC  bridges   are  using   ETHERNET/SLITHERNET
            interworking to achieve remote ETHERNET connectivity.

            SLITHERNET frame  type 2  is most  useful when end hosts and
            SLITHERNET bridges  or routers have a serial interface which
            can check  or transmit  CRC-32.   Such interfaces  might use
            serial chips  like the  Zilog USC  16C30, the  AMD  AM79C900
            (ILACC) or  the Intel  82596.   Frame type  2 is most useful
            when  the   purpose   is   highly   efficient   ETHERNET/WAN
            interworking and  when forwarding  of frames with bad CRC-32
            from one  interface to  another (as  might happen when using
            frame type 1) is particularly undesirable.  If the point-to-
            point speeds  are comparable  to ETHERNET  speeds,   the WAN
            links and  ETHERNET segments might act like a single logical
            ETHERNET with possibly reduced contention.













                                                                        6

            RFC SLITHER              SLITHERNET                July 1991

            SLITHERNET frame  type 3 is most useful in a pure SLITHERNET
            environment in  which the serial interfaces are only able to
            generate and  check CRC-CCITT  as might  be the  case if the
            interface used  were a  Zilog 85230  ESCC or an AMD AM85C30.
            Even in an environment in which ETHERNET and SLITHERNET were
            being interworked,  if the  choice were  between using frame
            type 3  or having a PC/XT generate CRC-32 in software, using
            frame type  3 might  make more  sense because the MAC bridge
            which interworked between ETHERNET and SLITHERNET might have
            a modern  ETHERNET chip which could generate CRC-32 on a per
            packet  basis  or  the  MAC  bridge  might  have  much  more
            horsepower for  the generation  of CRC-32  in software where
            necessary.     In  general,  a  SLITHERNET  network  can  be
            completely heterogeneous with respect to the frame type used
            on each  link.   The MAC  bridges have the responsibility of
            generating or  stripping the  various CRCs  according to the
            frame type used on each link.

            B. Path Selection Within a SLITHERNET Communications Subnet

            In the  actual selection  of paths  for  packets  to  travel
            through a  SLITHERNET communications  subnet, the SLITHERNET
            MAC bridges  use the  logic of spanning tree as specified in
            IEEE specification P802.1d, MAC Bridges.  This specification
            actually pertains  to all  the IEEE  802 technologies.   The
            all-encompassing  nature   of  P802.1d   suggests  that   an
            alternative wide-area  networking strategy  might emulate  a
            set of  bridged token-buses  or bridged  token-ring.    Such
            emulation might  seem reasonable if interworking with token-
            rings or token-buses is the goal.

            The arbitration  methods of  token-ring and token-bus are so
            unnatural in  the full-duplex  point-to-point situation that
            developing WAN  emulations  of  these  technologies  may  be
            unreasonable.   Just as  it is probably much more reasonable
            to route  between one subnetwork which uses one IEEE 802 LAN
            technology and  another subnetwork  which uses  a  different
            IEEE  802   LAN  technology   than  to  bridge  between  one
            subnetwork which  uses  one  IEEE  802  LAN  technology  and
            another  subnetwork   which  uses   a  different   IEEE  LAN
            technology, it  is probably  much more  reasonable to  route
            between a  token ring  or token bus network and a SLITHERNET
            network than  to try to develop WAN formalism which might be
            capable of interworking with the token technologies.


















                                                                        7

            RFC SLITHER              SLITHERNET                July 1991

            By way  of contrast,  the only  major difference  between  a
            point-to-point ETHERNET connection between end devices and a
            point-to-point WAN  connection between  end devices  lies in
            the arbitrary  restriction  that  ETHERNET  be  half-duplex.
            Since the  restriction  is  arbitrary,  and  since  the  WAN
            interface interworks in reality with the internal bridge bus
            which is  probably half-duplex  anyway, interworking between
            ETHERNET   and    WAN   technology    can   be    reasonably
            straightforward.  Developing a WAN formalism on the ETHERNET
            model  is  reasonable.    People  who,  instead,  insist  on
            formalizing   the    bit-diddling   necessary    to   bridge
            transparently from  an ETHERNET to a WAN point-to-point link
            to a token-ring are merely recreating all the problems which
            TCP/IP was invented to overcome almost 20 years ago.

            C. Spanning Tree Extensions and Modifications

            Even  though   the  spanning  tree  protocol  and  algorithm
            provides a  convenient vehicle  to convert  a collection  of
            point-to-point  serial   links  into  a  networking  medium,
            P802.1d is designed with other technologies in mind and some
            extensions might improve performance or be necessary in some
            cases for  successful communications over links which may be
            relatively slower than the 802 technologies.

            The simplest potentially useful modification of the spanning
            tree protocol  is scaling  up the  default timing parameters
            inversely according  to  the  proportion  that  the  average
            serial link data rate is slower than the ETHERNET data rate.

            A more  sophisticated modification  might  allow  a  certain
            amount of  load sharing  by permitting  the transmission and
            reception of  packets on  certain ports  which are  blocked.
            Allowing the  use of  some blocked-yet-forwarding  ports for
            load-sharing would   not  break spanning  tree  because  the
            serial link topology is a degenerate case in which the graph
            node to  which serial  link corresponds connects to only two
            arcs where  one arc  is either a blocked port or a root port
            for a  bridge while  the other arc is the designated port to
            the bus  node to  which the serial link corresponds.  If the
            blocked-yet-forwarding port  transmits  a  packet  (selected
            perhaps by  hashing on  source or  destination address),  it
            will  definitely   get  to  the  destination  without  being
            duplicated.


















                                                                        8

            RFC SLITHER              SLITHERNET                July 1991

            In some cases, routing packets on paths through blocked-yet-
            forwarding ports  might always  be preferable  to the  paths
            which would  be selected  by the  unmodified  spanning  tree
            algorithm. Of  course, in  such cases  incorrect port  costs
            have probably  been selected.  Which blocked  ports  can  or
            should be designated as blocked-yet-forwarding ports depends
            on the  physical topology  of the  network and the nature of
            traffic flow  through the  communications subnet.    If  the
            selection  is   performed  carelessly,  routing  within  the
            communications subnet could break completely.

            A more  important extension  to the  spanning tree  protocol
            might add disconnected and call processing states to list of
            possible port states.  Such an extension would allow dynamic
            link set-up  and tear-down.   If links are set-up on demand,
            the bridging  logic would  probably not  send spanning  tree
            packets to  disconnected ports  but  would  send  broadcast,
            unknown address  or configured  address packets (assuming no
            learning  has   yet  taken   place)  to   ports  which   are
            disconnected.   If such  packets are bridged to disconnected
            ports, connection  management logic could then initiate link
            set-up procedures.

            D. SLITHERNET Addresses and Addressing

            There  is   no  convenient  authority  assigning  SLITHERNET
            addresses to  SLITHERNET interfaces.   If  a manufacturer of
            ETHERNET interfaces  which use  ETHERNET chips which have an
            HDLC mode  replaces the  ETHERNET line  interface with a WAN
            line  interface,   assigning  these   SLITHERNET  interfaces
            addresses from the manufacturer's pool of assigned addresses
            is probably the most straightforward procedure.

            If a SLITHERNET interface is to be implemented when there is
            no block  of ETHERNET addresses conveniently available (e.g.
            an MIT  student implements SLITHERNET support for PC/IP on a
            Sealevel ACB-III  or ACB-IV  card), the  implementer  should
            just leave  the SLITHERNET  address as  a user  configurable
            option.  In an IP environment, the SLITHERNET addresses need
            only be  unique  on  each  separate  IP  subnetwork,  and  a
            workable approach  might assign  hosts SLITHERNET  addresses
            which use  the IP  address as  the last  four bytes  of  the
            SLITHERNET addresses.   In  other  networking  architectures
            other schemes for address assignment might be workable.


















                                                                        9

            RFC SLITHER              SLITHERNET                July 1991

            IV. SLITHERNET Goals and Functionality

            The SLITHERNET  proposal  aims  for  the  maximum  reuse  of
            hardware  and   software  already   developed  for  ETHERNET
            bridging and  routing.   If a  hardware interface  has  been
            developed for a bridge or router which uses an ETHERNET chip
            with an  HDLC mode,  respinning that ETHERNET interface as a
            WAN  interface   which  might  be  useable  in  implementing
            SLITHERNET should  be straightforward  and  relatively  less
            costly than  implementing a  completely new  WAN  networking
            system,  which,  unlike  SLITHERNET,  uses  no  pre-existing
            technology.   Even if  a  SLITHERNET  interface  had  to  be
            developed from  scratch, development  costs could  still  be
            lower  for   SLITHERNET  than   developing  some  other  WAN
            architectural  because  SLITHERNET  uses  standard  ETHERNET
            techniques  (like   ETHERNET  ARP)   and  standard  ETHERNET
            structures and  objects in  the host  software  and  on  the
            transmission medium.

            Once  a   SLITHERNET  interface   exists  for  a  router,  a
            SLITHERNET end-host  could be  connected  directly  to  that
            router via  a point-to-point link.  Using SLITHERNET in this
            way might  be reasonable  in  some  situations  but  a  more
            efficient interconnection  strategy would  connect a  router
            with a SLITHERNET interface to a spanning-tree-algorithm MAC
            bridge with  SLITHERNET interfaces  so that the router could
            route  between   the  logical   subnetwork  defined  by  the
            SLITHERNET spanning  tree and the other subnetworks to which
            the router  connects.    Alternatively,  a  router  with  an
            ETHERNET interface  could be  connected by  an ETHERNET to a
            MAC bridge  with both  ETHERNET and  SLITHERNET  interfaces.
            This MAC  bridge  could  act  as  an  ETHERNET-to-SLITHERNET
            interworking unit.

            A particularly  cost-effective way  to achieve  the  desired
            connectivity might  use a  bridge/router which supports both
            ETHERNET and SLITHERNET interfaces.  The bridge router could
            bridge between  the  ETHERNET  interfaces  and  between  the
            SLITHERNET interfaces separately.  The spanning tree for the
            bridged ETHERNETs  defines  one  logical  subnetwork.    The
            spanning tree  for the  SLITHERNET defines  another  logical
            subnetwork.   The router  functionality of the bridge/router
            could route  between the  two subnetworks defined by the two
            independent spanning trees.


















                                                                        10

            RFC SLITHER              SLITHERNET                July 1991

            V. SLITHERNET Implementation

            Implementing SLITHERNET interfaces is no more difficult than
            implementing ETHERNET  interfaces if ETHERNET chips are used
            which support  HDLC modes  or if  packet-oriented HDLC chips
            like the  AT&T Spyder-T  are employed.   Many developers may
            not have  such luxuries  available to  them and  may have to
            develop a  SLITHERNET interface  with  a  character-oriented
            HDLC device like the Zilog 85230 ESCC.

            If  a   microprocessor  is   devoted  to  servicing  such  a
            character-oriented HDLC device, the combination of dedicated
            microprocessor  and   character-oriented  HDLC   device   is
            equivalent to a packet-oriented HDLC device.

            If the  option of dedicating a microprocessor to servicing a
            character  oriented   HDLC  device  is  not  available,  one
            possible technique  of implementing  the  protocol  software
            would be  to implement  the link-layer  software on top of a
            virtual packet  device driver.    A  virtual  packet  device
            driver would  provide a  means to read data from the virtual
            packet device  and to  write  data  to  the  virtual  packet
            device.   The data would be in the form of chains of buffers
            which comprise a link-level packet.  Of course, some virtual
            device drivers  might use  trivial chains in which the chain
            consists of  exactly one  buffer which  contains  the  whole
            link-level frame.

            The actual  virtual packet  device could be implemented as a
            set of interrupt level routines which understand how to read
            and write  data to  and from  the underside  of the  virtual
            packet  device.     The  interrupt  routines  would  extract
            characters  from  the  data  chains  written  by  link-level
            software to  the virtual  packet device.   These  characters
            could then  be written  to the  real  character  device  for
            transmission.   Likewise characters  read by  the  interrupt
            handling routines from the real packet device are packetized
            into received buffer chains and passed into the underside of
            the virtual  device driver  so that  the link-level software
            may read these chains from the topside of the virtual device
            driver.





















                                                                        11

            RFC SLITHER              SLITHERNET                July 1991

            VI. SLITHERNET Issues

            The service which is provided by the SLITHERNET architecture
            is quite  different than  the  service  which  the  hype  of
            marketeers of  Frame-Relay and  SMDS describes.   This  hype
            envisions a  single global  super-intelligent communications
            subnet providing  services for  an  infinity  of  relatively
            unintelligent end  hosts.   This TELCO  vision, which  is to
            some extent modelled on the voice network, dates back to the
            late  60s   and  early   70s  and   was  obsoleted   by  the
            microprocessor revolution and the proliferation of powerful,
            inexpensive LAN technologies.

            From the  standpoint of  tariffing common  carriage service,
            the TELCO model makes a lot of sense.  Also, there are a few
            technical situations  where the  TELCO model is useful.  But
            generally, modern  successful computer network architectures
            follow an  internetworking approach  which builds  a virtual
            network or  internet out  of a  heterogeneous collection  of
            subnetworks   (a    catenet)   corresponding   to   separate
            communications subnets,  and which  uses some sort of router
            to route  packets between subnetworks. The routers typically
            are outside  any communications subnet and  straddle several
            subnetworks.

            Most often,  the separate  subnetworks among which most data
            traffic travels  are geographically close to one another and
            are situated  at  localized  major  networking  sites.    No
            service from  TELCOs is required to route this traffic among
            subnetworks or  to bridge  communications subnets.  However,
            there is often a small fraction of traffic which may need to
            be transported  over a  large distance  between a  few major
            networking sites.     A small  subnetwork corresponding to a
            wide-area communications  subnet might  be  useful  for  the
            carriage  of  this  traffic.    If  a  TELCO  or  a  private
            organization could  offer a  reasonably inexpensive means to
            provide this  subnetwork, such a subnetwork might correspond
            to a useful service or product which TELCOs or other vendors
            could offer.   This subnetwork might be a sort of networking
            centrex or wantrex in which end-points are a company's major
            networking sites  and over  which a company might be able to
            institute it's  own security  features beyond  what would be
            available  in   the  current   global  super  communications
            subnetwork which  the marketeers  are hyping.   A  long-haul
            SLITHERNET which  gave  the  customer  control  over  packet
            filtering at  MAC bridges  could easily  provide the vehicle
            for such a wantrex service.















                                                                        12

            RFC SLITHER              SLITHERNET                July 1991

            VII. Conclusion

            SLITHERNET represents  a reasonable  WAN architecture  which
            can solve some problems of remote connectivity in reasonably
            cost-effective manner through the use of existing technology
            and  the  adaptation  of  existing  hardware  and  software.
            Because SLITHERNET  requires little,  if any, development of
            software or hardware from scratch and because SLITHERNET has
            no  dependencies   on  the  decisions  of  PSPDN  providers,
            SLITHERNET can  be implemented  in a  relatively short time-
            frame without  any great  expenditure of  funds.    Even  if
            SLITHERNET were to prove only a short-term WAN solution, any
            hardware or  software developed  for  SLITHERNET  should  be
            adaptable to  the other  technologies which are proposed for
            wide area  networking. Because  of the potential of reuse of
            SLITHERNET technology,  there is  no downside  to developing
            SLITHERNET technology and experimenting with it.




















































          I. Motivation                                              2
          II. Requirements                                           4
          III. SLITHERNET Definition                                 4
              A. SLITHERNET Frame Types                              5
              B. Path Selection Within a SLITHERNET Communications Subnet  
                      6
              C. Spanning Tree Extensions and Modifications          7
              D. SLITHERNET Addresses and Addressing                 8
          IV. SLITHERNET Goals and Functionality                     9
          V. SLITHERNET Implementation                              10
          VI. SLITHERNET Issues                                     11
          VII. Conclusion                                           12















































-- 
The statements contained in this article solely represent the views of
the author and in no way do they reflect the official opinion or policy
of Clearpoint Research Corporation.

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 91 02:35:32 GMT
From:      martillo@crackers.clearpoint.com (Martillo)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Using Wide-Area Point-to-Point Links for Computer Networking (II)

The following memorandum is a first draft of the second of a pair of
potential RFCs which specify a methodology for using wide-area serial
synchronous DCE/DTE-type point-to-point links as a computer networking
medium.  The Clearpoint Little Dipper/Auriga product line offer as one
of several configurable options a wide-area interface which implements
this specification, and should a developer implement this interface for
his bridge, router or end host, that network device will be able to
communicate with the Little Dipper/Auriga products over point-to-point
serial links as well as any other device which implements this
specification.  Comments on this draft are welcome. 
----------------------------------------------------------(Cut Here)-----



                                                                        1

            RFC SLIDE                  SLIDE                   July 1991



            Clearpoint Research Corporation                  J. Martillo
            Request for Comments: XXXX                        Dave Emery
            August 1991                                       Avri Doria
                                                        Frank Kastenholz
                                                          Frank Solensky
                                                                        
                                


                           Serial Line Data Encapsulation
                                for the Framing of a
                   Synchronous Serial Point-to-Point Data Stream

            Status of this Memo

            This RFC specifies a vendor proposal for the framing of data
            packets within  full-duplex bidirectional synchronous serial
            non-self-clocking  point-to-point   connections  which   are
            supported by  the class  of interfaces  of which RS-232, RS-
            449, V.35, X.21 are representative examples.

            This proposal  formalizes knowledge and experience gained in
            developing an extremely simple-to-implement high-performance
            interface for  slow to  moderate speed (96 Kbps to 384 Kbps)
            synchronous line connection subsystem for a high performance
            WAN LAN bridge router.

            Abstract

            SLIDE (Serial  LIne Data  Encapsulation) defines a mechanism
            for demarcating  Ethernet 2.0 or IEEE 802.x MAC frames which
            are  being   transmitted  along   a  serial   line.    SLIDE
            facilitates  the   implementation  of   a   high-performance
            transparent WAN-to-LAN  bridge.   In  facilitating  such  an
            implementation, SLIDE essentially performs the same function
            which the 802.3 (Ethernet 2.0) preamble performs on an 802.3
            (Ethernet 2.0)  transmission line.   The ability of SLIDE to
            encapsulate IEEE  802.x MAC  (Ethernet 2.0) frames  suggests
            that SLIDE  is part  of  the  solution  to  the  problem  of
            developing a  reasonable serial  line link  layer  for  high
            performance  computer   networking  in   an  environment  of
            moderate speed serial line connections.


















                                                                        2

            RFC SLIDE                  SLIDE                   July 1991

            I. Motivation

            The Clearpoint  Networking Group found that customers wanted
            a means  of synchronous  moderate speed (96 Kbps - 384 Kbps)
            transparent  wide-area   connectivity  between   802.1d  MAC
            bridges.   802.1d MAC  bridging  is  defined  only  for  the
            technologies defined  by the  IEEE 802.3,  802.4  and  802.5
            standards.  But if the wide-area interface is implemented to
            appear as  much as  possible to the bridging logic as one of
            the 802 technologies, connecting two bridges via a point-to-
            point wide-area  link is  no different  than connecting  two
            bridges via  a single  LAN  to  which  no  other  hosts  are
            connected.

            The similarity  between the  two types  of connectivity  has
            increased as  many of the newer serial controller chips like
            the Zilog  Z16C30 (USC)  support CRC-32 as well as CRC-CCITT
            and as  many of  the newer  802.3 controller  chips like the
            Intel 82586/82596  support HDLC  compatible modes  which use
            either CRC-32 or CRC-CCITT.

            The new  serial controller chip features enable these serial
            controllers to  be used  as 802.3  controller  chips  albeit
            sometimes with  the absence of some typical features like 48
            bit destination  matching.   The new  802.3 controller  chip
            features  enable   these  chips  to  be  used  as  (somewhat
            expensive) serial  HDLC controller chips.  As a consequence,
            an 802.3  controller board design can serve as the basis for
            wide-area serial  controller board  designs with replacement
            of the 802.3 line interface by a wide-areas serial interface
            or vice-versa.

            With an  appropriate definition of an encapsulation of a LAN
            packet for  transmission on  a serial  line, except for some
            extremely low-level  chip commands  almost exactly  the same
            driver software might be usable for both LAN controllers and
            for  WAN   controllers,  and   for   higher-level   protocol
            processing software  layers there  might be no difference at
            all between WAN controllers and LAN controllers.























                                                                        3

            RFC SLIDE                  SLIDE                   July 1991

            Such  absence   of  differences   in  driver   software   is
            particularly useful  in the  case processors  like the Prime
            Series 50  or the  AM29K series  which require  a particular
            alignment of  bytes for  efficient string  comparison (as in
            destination address  look-up).   It would be silly to define
            an encapsulation  for WAN interfaces which would require the
            higher level  protocol software  to know  on which  physical
            interface a  packet arrived  so that  an  efficient  set  of
            string comparison  routines could  be selected.  Even if the
            system processor  characteristics did  not   in  some  cases
            necessitate    different     programming    for    different
            encapsulations, keeping  WAN  and  LAN  driver  software  as
            similar as  possible might  mean some  economies in software
            implementation or maintenance.

            II. Physical Layer Requirements

            SLIDE is  defined for  the encapsulation of data packets  on
            moderate speed  full-duplex bidirectional synchronous serial
            non-self-clocking point-to-point  connections  of  the  sort
            which are supported by interfaces like RS-232, RS-449, V.35,
            X.21.   Moderate speeds  are speeds  between 96 Kbps and 384
            Kbps, but  the encapsulation  may be effective over a larger
            range of data rates.

             1)  The medium  interface should  support flag  framing  as
                 defined by  CCITT Red  Book Fascicle VIII.3 - Rec. X.25
                 section 2.2.2  or by  CCITT Blue Book Fascicle VIII.2 -
                 Rec. X.25 section 2.2.2.

             2)  The medium  interface should  support  transparency  as
                 defined by  CCITT Red  Book Fascicle  VIII.3 - Rec X.25
                 section 2.2.6  or by  CCITT Blue Book Fascicle VIII.2 -
                 Rec. X.25 section 2.2.6.

             3)  The  medium   interface  should   support  frame  check
                 sequence (FCS),  a.k.a CRC-CCITT,  as defined  by CCITT
                 Red Book Fascicle VIII.3 - Rec X.25 section 2.2.7 or by
                 CCITT Blue  Book Fascicle  VIII.2 -  Rec. X.25  section
                 2.2.7.

             4)  Optionally, the  medium interface  should support frame
                 check sequence  (FCS), a.k.a  CRC-32, as defined by ISO
                 8802-3 :  1989 which  is equivalent  to  ANSI/IEEE  Std
                 802.3-1988.

















                                                                        4

            RFC SLIDE                  SLIDE                   July 1991

            SLIDE makes  no specification  on the use of the serial line
            control signals,  whose usage  may be defined in another RFC
            on dynamic  link set-up.   Of  course, if  absence of DCD is
            truly known  to mean  that no data is being transmitted, the
            driver may  detect this  state, "mark  the  link  down"  and
            refrain from  attempting to transmit or receive data.  SLIDE
            makes no requirement that clock be provided independently of
            the interfaces  at the  termination of  the data link, i. e.
            the encapsulation  works whether  in terms  of clocking both
            end hosts  are DTEs or whether one end host is a DTE and the
            other end host is a DCE.

            III. SLIDE Definition

            SLIDE encapsulation has the following three formats.

             1)  FLAG | DATA1 | CRC-CCITT | FLAG

             2)  FLAG | DATA2 | CRC-32 | FLAG

             3)  FLAG | DATA3 | CRC-CCITT | FLAG

            Without prior  agreement between the two circuit termination
            interfaces, DATA1  is assumed  to be  an 802.3 MAC (Ethernet
            2.0)  frame   (except  for  the  bit-stuffing  required  for
            transparency as  defined above),  and  thus  has  a  minimum
            length of  64 bytes.   When  bridging according to 802.1d in
            encapsulation mode  1, the  bridging logic  would strip  off
            CRC-CCITT before  forwarding the packet (minus bit-stuffing)
            out a LAN interface.

            Without prior  agreement between the two circuit termination
            interfaces, DATA2 | CRC-32  is assumed  to be  an 802.3  MAC
            (Ethernet 2.0)  frame (except  for the bit-stuffing required
            for transparency  as defined  above), and thus has a minimum
            length of  60  bytes.    With  this  configuration,  packets
            received correctly  at an  802.3 (Ethernet  2.0) transceiver
            but corrupted  before transmission  out the WAN interface to
            an 802.1d  MAC bridge will not be forwarded beyond the first
            receiving bridge.   When  bridging according  to  802.1d  in
            encapsulation  mode   2,  the   bridging   logic   transmits
            DATA2 | CRC-32 (minus  bit-stuffing) out  the interface to a
            LAN onto  which the  802.x MAC  frame  should  be  forwarded
            without any stripping.


















                                                                        5

            RFC SLIDE                  SLIDE                   July 1991

            Without prior  agreement between the two circuit termination
            interfaces DATA3  is assumed  to be  an 802.3  MAC (Ethernet
            2.0) frame   with CRC-32 absent (except for the bit-stuffing
            fequired for  transparency as defined above), and thus has a
            minimum length  of 60  bytes.   When bridging  according  to
            802.1d in  encapsulation mode  2, the  bridging logic  would
            generate CRC-32 and append it to DATA3 before forwarding the
            packet out  a LAN  interface.   If the  LAN interface uses a
            part like  an AMD  Am79C900 (ILACC),  an Intel  82586 or  an
            Intel 82596,  generation of  CRC-32 is  controlled on  a per
            packet basis,  and generating  CRC-32 just means setting the
            appropriate bit in the buffer chain passed to the controller
            chip.   If the LAN interface uses a part like the AMD Am7990
            (Lance) chip  which cannot  generate CRC-32  on a per packet
            basis, and  if the  LAN interface  is used  for  transparent
            bridging, either  CRC-32 must  be  generated  for  DATA3  by
            software logic  or CRC-32  must be stripped from all packets
            before passing  them  to  the  LAN  interface  so  that  the
            controller  chip   can  generate  CRC-32  for  all  outgoing
            packets.  Such a procedure is impure bridging.

            Any of the three encapsulations can be selected on the basis
            of prior agreement or fall-back from CRC-32 to CRC-CCITT can
            be implemented  on the  basis of  a leaky  bucket procedure.
            [Let mode be encapsulation 2 (CRC-32). Let X be greater than
            0. For  every bad  CRC received  increment counter  Y.   For
            every hundred  packets with  good  CRC  received  and  Y  is
            greater than 0, decrement Y.  If Y ever becomes greater than
            X, set  mode to  encapsulation 1  (CRC-CCITT). If  the  mode
            falls back  to encapsulation  1, for some number of received
            packets, check  for the  presence  of  bad  CRC-32.    If  a
            sufficient number of received frames contain bad CRC-32, set
            encapsulation mode to encapsulation mode 3.]

            IV. Experience and Thoughts

            A functioning  SLIDE-based WAN  interface for  an 802.1d MAC
            bridge for  802.3 (Ethernet  2.0) LANs  has functioned since
            October 1990.    Transparent  LAN-WAN-LAN  bridging  via  an
            802.1d  MAC  Bridge,  which  used  SLIDE  over  a  9600  bps
            synchronous dial-up  link was  demonstrated in Washington in
            January 1991.   At  speeds on  the order  of 384  Kbps,  the
            SLIDE-based WAN  interfaces have  performed quite  well even
            when the traffic has included maximal sized NFS packets.  On
            slower  links,   some  tuning   of  NFS  and  spanning  tree
            parameters is required to get adequate performance.
















                                                                        6

            RFC SLIDE                  SLIDE                   July 1991

            One SLIDE  implementation exists  for an  AMD Z85C30  Serial
            Communications Controller  with only  extremely  rudimentary
            DMA support built into host hardware, and another exists for
            a Zilog  85E230 ESCC with no DMA support built into the host
            hardware.   Implementing WAN-LAN transparent MAC bridging on
            these  devices   was  straightforward.     This   experience
            demonstrates  that   SLIDE  does   not  require  (expensive)
            sophisticated  serial  controller  chips  for  a  successful
            implementation.

            SLIDE does  not support  some of  the sophisticated  control
            mechanisms which  other serial  line encapsulations support.
            But  building   such  control  mechanisms  into  the  lowest
            networking layers  -- especially  from the standpoint of DOD
            style internetworking  -- is really misguided when they have
            to exist in the higher protocol layers as well.  There might
            nevertheless be  some value  in designing  and  implementing
            Short Packet  Diagnostics (SPaD)  which would  use DATA1  or
            DATA2 sizes  less than 60 bytes to distinguish these control
            packets from genuine data packets which are to be bridged.

            SLIDE makes  the  following  type  of  network  connectivity
            possible.

             1)  If a  network host  implements SLITHERNET  (Serial LIne
                 eTHERNET) [RFC  forthcoming], which  defines  the  data
                 frame encapsulated by SLIDE, and

             2)  if that  host connects  to an  802.1d MAC  bridge which
                 supports SLIDE  on a  WAN  interface  via  a  wide-area
                 serial line,

            that host  appears as  if connected  directly to the logical
            802.3  (Ethernet  2.0)  network  which  is  defined  by  the
            spanning tree  topology in which its 802.1d MAC bridge takes
            part.

































          I. Motivation                                              2
          II. Physical Layer Requirements                            3
          III. SLIDE Definition                                      4
          IV. Experience and Thoughts                                5























































-- 
The statements contained in this article solely represent the views of
the author and in no way do they reflect the official opinion or policy
of Clearpoint Research Corporation.

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 91 16:13:27 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

In article <2424@crackers.clearpoint.com> martillo@crackers.clearpoint.com (Martillo) writes:
   ... [S]hould a developer implement this interface ... that network
   device will be able to communicate with the Little Dipper/Auriga
   products ...

Would I still be able to communicate with members of the Little
Dipper/Auriga product line if I don't manage to SLITHER, but instead
only implement something like SLIP or PPP?

Which is to say, will Clearpoint's boxes talk to the rest of the
world?

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 91 23:09:24 GMT
From:      bell@nodename.dec.com (Peter Bell)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: Any results from Gbits testbeds ? (a digression)


In article <1991Aug29.070805.10835@sics.se>, craig@sics.se (Craig Partridge) writes...
[.. much ommitted ..]
>If you're willing to wait there's lots of stuff coming.  There's currently a
>plan to do special gigabit issues of all the major IEEE Comm. Soc. magazines
>this spring -- which should give you some useful reading.  Also, there are
 [...]
>Craig Partridge
>Incoming Editor-in-Chief, IEEE Network Magazine

Where I live (Sydney, Australia) this Spring starts now. So I'm looking forward
to reading about gigabit networking in the next issues I receive.

Peter.

END OF DOCUMENT