HDTenEightyP/NetNews huggingface dataset:
From: trier@slc6.ins.cwru.edu (Stephen C. Trier)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Winsock available?
Date: 18 Dec 1992 19:05:42 GMT
Organization: Case Western Reserve University, Cleveland OH (USA)
NNTP-Posting-Host: slc6.ins.cwru.edu

In article <BzGuFA.4FG@cedb.dpcsys.org> dan@cedb.dpcsys.org (Dan Busarow) writes:
>Are there any plans to develop a 'winsock' API library which could
>be used by non-windows dos programs?

That would be nice, but part of the problem is that compatibility at
the library level in DOS requires relinking an application for each
version of the library.  One would need to define, rather than just
library calls, an ABI, or Application Binary Interface, by which the
application can communicate with the TCP.

This problem is solved in Windows by the dynamic linking Windows does
when any program is loaded.  In Windows, every system call is really
just a library call.

The big problem with developing an ABI for MS-DOS TCP is that most
developers agree it would be great, as long as it is the ABI they
developed for their own applications.  This obviously puts everyone
else at a disadvantage.  So far, there has been only scattered support
for a vendor-independent TCP binary interface for MS-DOS.

-- 
Stephen Trier                      "We want to offer you a price that you
Network software type               just can't afford to take advantage of."
Case Western Reserve University         - Sales blurb from HSC Software
trier@ins.cwru.edu
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: sctchen@kraken.itc.gu.edu.au (Jinghong Chen)
Subject: Re: kermit  +  ethernet,  pc  -  sun  Date:   16 Dec  1992  10:06  PDT
Reply-To: sctchen@kraken.itc.gu.edu.au (Jinghong Chen)
Organization: Griffith University, Brisbane, Australia
Distribution: world Keywords:  kermit,ethernet,sun,ibm
Date: Sat, 19 Dec 92 11:38:05 GMT

In article <16DEC199210122099@eql.caltech.edu> jack@eql.caltech.edu (Jack Williamson) writes:
>does anyone have info on how to set up kermit to connect a pc to a sun o  sun
>over ethernet?  we've already got 3 other PC's on this network running PCNFS;
>the pc's  have got 3C507-TP  cards.   want to  set  up  kermit  on additional
>machines to do terminal emulation and file transfer w/o the cost of PCNFS.
>
>thanks ex ante for your suggestions.

Kermit version 3.11 or above will support TCP/IP (ethernet). However you
need a driver (may packet driver) for your specific card.

J.CHEN (sctchen@kraken.itc.gu.edu.au)
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: GAYNOR@agvax2.ag.ohio-state.edu (Jim Gaynor)
Subject: Pocket Lan Adaptors and Packet Drivers...
Organization: The Ohio State University - OCES
Date: Wed, 16 Dec 1992 14:51:31 GMT
X-News-Reader: VMS NEWS 1.24

First off,

Has anyone found and/or written a Packet Driver for the Solectec
pocket LAN adaptor?  The manufacturer "claimed" to have one, which we
later found out was simply a piece of code that requires PC/TCP (which
we don't use).  Further calls to their Tech Support have resulted in
the revised statement that they have not written a apacket driver for
it.  <sigh>  I've checked the Release 10 collection, and done an
Archie search on 'solec', but to no avail.  Any help would be appreciated.

On a similar subject, does anyone have reccomendations on a pocket LAN
adaptor (the kind that you attach to LPT1) for which a packet driver
exists, and seems to work well with apps such as NCSA Telnet, POPmail,
Gopher, and other packet-driver based apps?  Again, thank you.


---
   Jim Gaynor    | "Man-of-Many-Beeping-Sounds-and-Flashing-Lights" - KAJ
OSU/ACS/FMS/OSUE | <gaynor@agvax2.ag.ohio-state.edu> or <gaynor.4@osu.edu>
Disclaimer: Everything stated here and above is -my- opinion.  Mine mine mine!
Witty Quote: "AWESOME COSMIC POWER... itty-bitty living space." - Aladdin
From: wendy@sw.stratus.com (Wendy McNaughton)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TLI: t_accept returns TLOOK (why?)
Date: 16 Dec 1992 15:26:20 GMT
Organization: Stratus Computer, Inc.
Distribution: world
NNTP-Posting-Host: cowabunga.sw.stratus.com

> In article <1992Dec2.215556.25482@bnrmtl.bnr.ca> kenneth@bnr.ca (Ken Rosenfeld) writes:
> >I'm writing a server using the TLI library for TCP
> >(on a Sun).
> >
> >The server executes the following in a loop:
> >
> >  t_listen(listenfd, ...)        /* receive connect indication */
> >    
> >  t_accept(listenfd, newfd, ...) /* accept the call */
> >
> >There is a case where this code does not work: Two clients
> >make connect requests before the server executes the t_listen().
> >The t_listen() then receives the first connect indication.
> >The t_accept() fails, however, with t_errno = TLOOK.  
> >A subsequent call to t_look() returns the T_LISTEN event.
> >

I ran into the same situation here with our SVR4-based UNIX (FTX).
Our RPC implementation always assumes that if t_accept() fails
with t_errno = TLOOK, it is as a result of a disconnect (and therefore
calls t_rcvdis).  As Mat Cucuzella pointed out, this is consistent with
the examples in Stevens' UNIX Network Programming book.  I also found
similar examples in the AT&T SVR4 manuals.  

The consensus here seemed to be that this is incorrect behaviour for
t_accept.  It seems silly to interrupt one connection establishment
just to process another.  Since we have access to the sources, we were 
thinking of modifying our TLI library such that the t_accept call will 
not be interrupted by another connection request.  This seems to work 
well but was wondering if this is the proper thing to do. 

-- 
Wendy McNaughton		| wendy@sw.stratus.com              
Stratus Computer, Inc.		| Wendy_McNaughton@vos.stratus.com
55 Fairbanks Blvd.
Marlboro, MA  01752
Xref: sparky comp.protocols.tcp-ip:5657 comp.sys.sun.admin:9519
From: lars@spectrum.CMC.COM (Lars Poulsen)
Newsgroups: comp.protocols.tcp-ip,comp.sys.sun.admin
Subject: Re: Routing IP over X25
Date: 16 Dec 92 06:50:46 GMT
Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA

In article <1992Dec11.123440.17671@medusa.prime.com>
	davidh@CIS.Prime.COM (Dave Hill) writes:
>>I am having a problem routing IP packets over an X25 WAN using Sunlink
>>X25 version 7.0. The problem is as follows:-
>>Using the dynamic interface (std0) in Sunlink X25, I can connect to
>>hosts that have a different IP network number to my own interface, but I
>>cannot use those hosts as routers.

In article <1992Dec15.173348.24581@acc.com> art@acc.com (Art Berggreen) writes:
>Sorry, but fairly fundamental to IP routing, is the assumption that for two
>nodes to communicate directly, that they both have interfaces on a common IP
>(sub)network.

There are two different ways to productively view an X.25 interface in
an IP context:
(1) An interface to one IP network. All neighbors on that network are
    one hop away and the network is expected to be fully interconnected.
(2) A collection of (possibly unnumbered) point to point links.

Sun has two different X.25 products that implement the two strategies.

The first strategy is used in the product that Sun sells to the MILNET
market. This is especially useful in the MILNET context where there is
no need for table lookups, since there is an algorithmic equivalence
between IP addresses and X.25 addresses.

The second strategy is used in the commercial Sunlink X.25 product.

The point-to-point strategy needs an IP interface entity per neighbor.
You probably need to put the neighbor's IP address in the PEER field of
the interface data structure in order to allow routes though that peer.

I believe that ACC Systems has an external SCSI-attached X.25 box that
comes with drivers that will do the fully-connected subnet model of the
interface using commercial X.25 networks with table driven address
conversion.

-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256
From: k@hprnd.rose.hp.com (Steve Kao)
Date: Mon, 14 Dec 1992 19:43:47 GMT
Subject: Re: Network Engineer Certification (HOW? WHERE?)
Organization: HP Roseville Networks Division
Newsgroups: comp.protocols.tcp-ip

Ramon J. Hontanon:
> Not long ago, I came across the term "Certified Network Engineer" in a
> computing magazine (can't remember which one). My job includes a lot
> of local networking, and I'm becoming very interested in such topics,
> so I thought I'd tap the collective knowledge of this forum.

You need to take an exam from Novell to become a CNE.  This means taking
classes provided by Novell or from a Certified Novell Instructor (CNI).
This will probably cost you big bucks, but you'll get a complete set of
Novell manuals from taking the classes.

Novell networking has very little to do with TCP/IP.

- Steve Kao
Organization: Ryerson Polytechnical Institute
Distribution: na
Date: Tuesday, 8 Dec 1992 10:50:43 EST
From: <ADMN8684@RyeVm.Ryerson.Ca>
Newsgroups: comp.protocols.tcp-ip
Subject: STII

I am interested in talking to any one who has implemented ST-II
in a UNIX kernel or who knows where I could get a UNIX kernel
with ST-II in it.
Thank you in advance.
West Suhanic, (416) 979-5000 ext 7420
E-Mail ADMN8684@RYEVM.RYERSON.CA
Newsgroups: comp.protocols.tcp-ip
From: Jan.vOorschot@dnpap.et.tudelft.nl (Jan van Oorschot)
Subject: ipmulti for SUNOS 4.1.3
Organization: Delft University of Technology, Dept. of Electrical Engineering
Date: Fri, 18 Dec 1992 08:00:16 GMT

Hi,

As the title says, i'am looking for ipmulti for SUNOS 4.1.3.
The standard distribution 

	'ipmulti-sunos41x.tar.Z'
	
contains kernel patches for SUNOS 4.1.1 and SUNOS4.1.2, but ...., not
for SUNOS4.1.3.
Since i'am not much of a Unix kernel patcher myself, i would like 
to make use of the work of some kind patcher out there.

Any help will sure be appreciated,

Jan


-- 
-- Ir. Jan van Oorschot.      --- Email: Jan.vOorschot@dnpap.et.tudelft.nl --
-- Data Network Performance Analysis Project                               --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --
--
-- Ir. Jan van Oorschot.      --- Email: Jan.vOorschot@dnpap.et.tudelft.nl --
-- Data Network Performance Analysis Project                               --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
From: mshah@next3.corp.mot.com
Subject: ROOT Server Problem ?? 
Organization: MOTOROLA 
Date: Tue, 15 Dec 1992 15:27:44 GMT

I noticed that I was not getting the right info. when I was querying the root  
server "ns.nic.ddn.mil" about an internet domain (osf.org), Instead of  
returning the correct nameservers it was returning our local root nameservers  
as the authoritative for that domain. Please note that the domain name is not  
ended with a trailing dot in the nslookup that I have done below:

---------------------
> osf.org
Server:  ns.nic.ddn.mil
Address:  192.112.36.4

Authoritative answers can be found from:
MOT.COM nameserver = MOTGATE.MOT.COM
MOT.COM nameserver = FTPBOX.MOT.COM
MOT.COM nameserver = NISCA.ACS.OHIO-STATE.EDU
MOT.COM nameserver = NIC.NEAR.NET
----------------------

The above  is not right information (i.e motgate and ftpbox are not  
authoratative  servers for osf.org domain). This can be illustrated by changing  
the server to  say "ns.nasa.gov" and doing an nslookup again. In the following  
nslookup output with server as ns.nasa.gov, eventhough the doamin name is not  
ended with a trailing dot, the nameserver comes up with the right information. 

-----------------------
> server NS.NASA.GOV
Default Server:  NS.NASA.GOV
Addresses:  128.102.16.10, 192.52.195.10

> osf.org
Server:  NS.NASA.GOV
Addresses:  128.102.16.10, 192.52.195.10

Non-authoritative answer:
osf.org nameserver = POOCH.OSF.ORG
osf.org nameserver = PAPERBOY.OSF.ORG
osf.org nameserver = MAILBOX.OSF.ORG
osf.org nameserver = NIC.NEAR.NET

Authoritative answers can be found from:
OSF.ORG nameserver = POOCH.OSF.ORG
OSF.ORG nameserver = PAPERBOY.OSF.ORG
OSF.ORG nameserver = MAILBOX.OSF.ORG
OSF.ORG nameserver = NIC.NEAR.NET
POOCH.OSF.ORG   internet address = 130.105.1.156
PAPERBOY.OSF.ORG        internet address = 130.105.1.137
MAILBOX.OSF.ORG internet address = 130.105.1.8
NIC.NEAR.NET    internet address = 192.52.71.4
-----------------------

My question is why is there an anamoly in the information that the root server
"ns.nic.ddn.mil" is giving out or there is a misunderstanding on my part. 
Thanks in advance.

--Manish Shah
Newsgroups: comp.protocols.tcp-ip
From: chk@alias.com (C. Harald Koch)
Subject: Re: Multiport repeaters and collision propagation
Organization: Alias Research, Inc., Toronto ON Canada
Date: Mon, 14 Dec 1992 19:38:52 GMT

In <ric.724092787@updike> ric@updike..sri.com (Richard Steinberger) writes:

>	He claims that it is not uncommon for multiport repeaters
>and even transceivers to NOT propagate collision signals to
>nodes on the repeater where the collision did not occur.  In other
>words,  he says that some multiport devices isolate collision signals
>to the branch where they occur.  Can anyone confirm such behavior?

I have been having problems with several machines on our Ethernets here,
that could be caused by this. (They could also be caused by malfunctioning
hardware, non-compliant transceivers; etc.; but several repeaters exhibit
the same symptoms, so I'm pretty sure it's the repeater itself).

What I'm seeing is strange; I can blast data over a TCP/IP connection at
over 800Kb/s from host A to host B, but throughput is around 20Kb/s in the
reverse direction. Blasting UDP data across the network shows extremely high
packet losses in one directory.

There are two multi-port repeaters between the hosts; all cabling is
thin-Ethernet. All of my test hosts are the same (SGI Indigos with Allied
Telesis Micro-transceivers, all running the same OS revision).

Hosts that are both on the same local thin-net cable (i.e. not talking
through a repeater) can talk to each other at high-speed, bi-directionally,
without problems. Also, not all repeaters show these symptoms.

I've been monitoring packets on the cables lately to try to figure out
what's wrong. If I run monitors on machines 'next to' A and B, I see many
packets transmitted by machine B, but that never appear on machine A's
cable. The only conclusion I've reached so far is that for some reason, the
repeater is dropping packets. (This is supposed to be impossible, due to
collision propogation and Ethernet's exponential backoff). Incidentally,
netstat on the transmitter shows no output errors and no dropped packets.

Different manufacturer's repeaters behave differently (even when replaced by
each other), but so far the problem is consistent to certain manufacturers,
which is why I suspect a design flaw of some sort.

I'm sorry this is so anecdotal, but I'm still running tests and collecting
data (This is difficult on an operational network, and I don't have the
resources for a test net).

If you find any more concrete information, I'd love to hear about it!

--
Main's Law: For every       | C. Harald Koch  Alias Research, Inc. Toronto, ON
action, there is an equal   | chk@alias.com                (work-related mail)
and opposite goverment      | chk@gpu.utcs.utoronto.ca     (permanent address)
program.                    | VE3TLA@VE3OY.#SCON.ON.CA.NA            (AMPRNet)
Xref: sparky comp.protocols.tcp-ip:5676 comp.unix.bsd:10340
From: tbo@vector.dallas.tx.us (Terry Bohaning)
Newsgroups: comp.protocols.tcp-ip,comp.unix.bsd
Subject: Limiting Telnet access.
Date: 17 Dec 92 23:02:14 GMT
Organization: Dallas Semiconductor

I've recently become very concerned about the security of many of 
the Unix workstations under my care. Some of the users are overly
free with their passwords and I would really like to limit access
to the systems.

Has anyone modified the telnet daemon to include to capability
for an allow/deny file. What I'm thinking of is a way to prevent
any machine not listed in an allow file or every machine except
those listed in a deny file from telneting into our machines.

I've gotten the BSD Net 2 sources and have started looking at them,
but wondered if anyone else has already tried this yet.

Your comments please......

Terry Bohaning			tbo@vector.dallas.tx.us
From: shuenn@tora.swdc.stratus.com (serene2)
Newsgroups: comp.protocols.tcp-ip
Subject: TCP Window value
Date: 15 Dec 92 23:55:26 GMT
Organization: Stratus Computer, Inc., San Jose, CA

Hi,
	Can someone tell me if there is a standard way of finding
out the TCP Window value (the one in TCP header) in most UNIX hosts?

Thanks, 

shuenn hwang
Newsgroups: comp.protocols.tcp-ip
From:  mark@mcs.spb.su (Mark Orlov)
Subject: Re: ICL OSLAN
Reply-To: mark@mcs.spb.su
Organization: JV Marine Computer Systems (St-Petersburg)
Date: Tue, 15 Dec 1992 13:05:45 GMT

>   In article <Bz1KJo.Ksu@atlas.abccomp.oz.au> phil@atlas.abccomp.oz.au (Phil Stenson) writes:
>
>   >    Over the past few months my search has been directed largely at
>   >ICL directly and with the exception of one or two people within that
>   >organisation I do not even get the courtesy of any form of response to
>   >my requests for information.
>
>   As it turns out 4 days after submitting this article I finally did receive
>   a reply from ICL - the reason for the delay turns out to be a typo in
>   the e-mail address to which the person from ICL has been trying to send.
>
>   >    I have addressed this query to a few of the comp.protocols
>   >groups for two reasons:
>   >
>   >        1. hopefully somebody may have some information for me
>   >
>   >        2. for a company that professes to be an Open System
>   >           company they certainly behave very much like a
>   >           very Closed System company.
>
>   Point 2. in light of the above is not applicable (was more a case of venting
>   some frustration).
>
>

  Our company sells solutions based on ICL products in former Soviet
  Union.
  I work on ICL DRS 6000 and DRS 3000 with SVR4. I mostly use TCP/IP
  connections for PC's and OSLAN for UNIX boxes.
  It's very pleased to find somebody who works (?) with ICL products.
  I will be very glad if you join me in investigation of ICL
  hard/software.


--
        Thanks and best Regards

        Mark Orlov,                          <mark@mcs.spb.su>
        Head of UNIX systems department,     Voice: +7 (812) 5683952
        Marine Computer Systems (ICL)
        St. Petersburg,  Russia.
From: C_S02254@CONRAD.APPSTATE.EDU (Jon C Austin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP Window value
Date: 17 Dec 1992 17:21:12 GMT
Organization: APPALACHIAN STATE UNIVERSITY
Distribution: world
NNTP-Posting-Host: alf.appstate.edu
X-News-Reader: VMS NEWS 1.24

In <8697.17794@stratus.SWDC.Stratus.COM> shuenn@tora.swdc.stratus.com writes:

> Hi,
> 	Can someone tell me if there is a standard way of finding
> out the TCP Window value (the one in TCP header) in most UNIX hosts?
> 
> Thanks, 
> 
> shuenn hwang

Under AIX, I've been able to get lots of stats about the TCP and IP
process with a command no(network options).  

Try:
	" no -a" 
and see if you see anything.

Jon Austin
Appalachian State University
Boone, NC

Newsgroups: comp.protocols.tcp-ip
From: proyse@peeras.demon.co.uk (Phil Royse)
Subject: Routing IP over X25 
Distribution: world
Organization: Peer Association
Date: Wed, 16 Dec 1992 18:34:46 +0000


In article <1992Dec11.123440.17671@medusa.prime.com> davidh@CIS.Prime.COM writes:

>route add net yy.yy.2.0 yy.yy.1.1 1
>
>to which route says "network is unreachable". This is because the kernel
>routing code states that the router must be on the SAME network as your
>interface. 


Hhmmm.. dunno about that last comment...

Dave,

Unless I've misread your explanation, I think the problem lies in your
calling the third host yy.yy.2.0  Because if it is on a separate subnet
from yy.yy.1.1 then its interface must have a different network address.
In your set up I think you're violating IP addressing rules..(?)

If this is the case, you will need to define the output port of the second
host yy.yz.1.1 and the input port of the third (last) host yy.yz.1.2

I.e. if the second and third hosts are joined by a subnetwork, then they 
must have a common subnet number  (yy.yz).

It's easy to forget that in routing the IP address defines the interface
of a router or host, not the actual router.  I.e. a host acting as a router
must have one address for each interface it supports... and the network
number part (in your case the first two octets, as you're Class B).

I hope this helps.

Forgive me if I've given you duff info.   

Regards,



Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      |         (OSI & GOSIP specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 
Xref: sparky comp.protocols.tcp-ip:5687 comp.unix.bsd:10391
From: matt@gecko.oes.orst.edu (Matt Curfman)
Newsgroups: comp.protocols.tcp-ip,comp.unix.bsd
Subject: Re: Limiting Telnet access.
Date: 18 Dec 92 18:10:05 GMT
Article-I.D.: gaia.1gt45tINNprl
Organization: Oregon State University, Corvallis OR USA
NNTP-Posting-Host: ra-box.wtfd.orst.edu

In article <1992Dec17.230214.16501@vector.dallas.tx.us> tbo@vector.dallas.tx.us (Terry Bohaning) writes:
>I've recently become very concerned about the security of many of 
>the Unix workstations under my care. Some of the users are overly
>free with their passwords and I would really like to limit access
>to the systems.
>
>Has anyone modified the telnet daemon to include to capability
>for an allow/deny file. What I'm thinking of is a way to prevent
>any machine not listed in an allow file or every machine except
>those listed in a deny file from telneting into our machines.
>
>I've gotten the BSD Net 2 sources and have started looking at them,
>but wondered if anyone else has already tried this yet.
>
>Your comments please......
>
>Terry Bohaning			tbo@vector.dallas.tx.us

I have installed on my 386bsd machine a package called wrapper.  From the
Readme:

                                --o--

This package provides a couple of tiny programs that monitor incoming
requests for IP services such as TFTP, EXEC, FTP, RSH, TELNET, RLOGIN,
FINGER, SYSTAT, and many others.
 
Optional features are: access control based on pattern matching; remote
username lookup using the RFC 931 protocol; protection against rsh and
rlogin attacks from hosts that pretend to have someone elses name.
<deleted>
        Wietse Venema (wietse@wzv.win.tue.nl),
        Department of Mathematics and Computing Science,
        Eindhoven University of Technology,
        The Netherlands.

                                --o--

I have placed a copy of wrapper.tar.Z on anonymous ftp at oes.orst.edu in
/pub/386bsd/wrapper.tar.Z.  There are many other sites for this software 
as well.

-mc
_____________________________________________________________________________
Matt Curfman                                    Almanac Information Archivist 
matt@gecko.oes.orst.edu                     Oregon State University Extension
From: jkidwell@pbs.org
Newsgroups: comp.protocols.tcp-ip
Subject: Multi-cast Transport Protocols
Date: 15 Dec 92 12:09:10 EST
Organization: PBS:Public Broadcasting Service, Alexandria, VA

Greetings:

We are designing a VSAT WAN based on TCP/IP and need to improve throughput.
Because much data is shared amoung many sites, multi-casting is potentially
more efficient than N uni-casts.  For example, we need to disseminate a
multimedia hypercard stack to all PBS member stations, but uni-casting takes
too long over a relatively slow VSAT connection.

In RFC-1112 Deering describes extensions for IP multi-casting, limiting
the discussion to the IP layer.  Upper-level protocols are implied, but
not discussed.

Please email suggestions and references to relevant literature about 
data broadcasting protocols to jkidwell@pbs.org.