HDTenEightyP/NetNews huggingface dataset:
From: tony@mtu.edu (Tony Dal Santo)
Subject: Re: Limiting Telnet access.
Organization: Michigan Technological University
Date: Mon, 21 Dec 1992 21:15:08 GMT

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.

Along these lines, I am curious if anyone has an idea how to allow
certain users access to the network, and deny others.  Something
like putting the user in group "network" to grant them access.  By
access, I mean system call level access like socket().  Even better
would be to provide a list of addresses/networks that are restricted/
allowed.

I imagine with a streams implementation of tcp/ip, you could change
the perms on /dev/ip or /dev/tcp.

Does anyone have any utilities for tracing a TCP port to a process number?

Tony Dal Santo
tony@mtu.edu
From: bill@twg.bc.ca (Bill Irwin)
Newsgroups: comp.protocols.tcp-ip
Subject: Trouble configuring UUCP on TCP/IP
Date: 2 Jan 93 11:09:45 GMT
Reply-To: bill@twg.bc.ca (Bill Irwin)
Organization: The Westrheim Group, Vancouver, B.C., Canada

A piece of information that I forgot to provide:  I had to change
the entry in /etc/inetd.conf for uucpd from "/etc/uucpd" to
"/usr/lib/uucp/uucpd" in order to get to the password prompt.  I
just changed the entry back to "/etc/uucpd" in both system's
files and got the following:

mchFind called (McDonal)
list (rmail) num = 1
fillFlds: entered
fillFlds: returning
list (/) num = 1
list (/) num = 1
list (ALL) num = 1
_Request (TRUE), _Switch (TRUE), _CallBack (FALSE), _MyName (), _Commands ALL
chdir(/usr/spool/uucp/McDonal)
conn(McDonal)
ProtoStr = e
Device Type TCP wanted
Internal caller type TCP
tcpdial host McDonald, port 540
family: 2
port: 7170
addr: 02029384
set interface TCP
processdev: calling setdevcfg(uucico, TCP)
getto ret 5
sendthem (^M)
expect: (gin:)
login:got it
sendthem (hammond^M)
expect: (word:)
 user unknown^Jlost line errno - 108
 ^^^^^^^^^^^^
close caller (5)
delock(TCP,e)
Call Failed: LOGIN FAILED
exit code 101
Conversation Complete: Status FAILED

TM_cnt: 0

Notice the "user unknown" above?  I was getting this when there
used to be a password on the account, before the password was
even prompted for!  Now I have removed the password because of
some recent postings about two Sun systems needing the parity
changed for the password.  Since this is a TCP connection, the
password is not necessary, so I've removed it.

I don't know why there are two "uucpd" programs, one in "/etc"
and the other in "/usr/lib/uucp", but using the one in uucp does
not produce the "user unknown" message.  I think that there is
some TCP configuration info either missing or incorrect so that a
UUCP connection attempt bombs this way.

This is new territory for me so I'm just guessing at what could
be wrong.  The documentation does not cover setting up UUCP on
TCP/IP very well at all.

Thanks for any help you may be able to provide.
-- 
Bill Irwin    -       The Westrheim Group     -    Vancouver, BC, Canada
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uunet!twg!bill            (604) 431-9600 (voice) |     Your Computer  
bill@twg.bc.ca            (604) 430-4329 (fax)   |    Systems Partner
From: brinkema@fjc.GOV (John R. Brinkema)
Newsgroups: comp.protocols.tcp-ip
Subject: Sun RPC ported to DOS environment?
Summary: Anyone done it?
Keywords: RPC, DOS
Date: 21 Dec 92 19:09:44 GMT
Distribution: comp
Organization: Federal Judicial Center, Washington, D.C.

Has anyone ported either TIRPC or Sun RPC 4.0 to the DOS environment?  Is
there a public domain version?  tnx.  jb.
From: geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: PC-NFS SLIP and telnet problem
Date: 23 Dec 1992 19:38:51 GMT
Organization: SunSelect
NNTP-Posting-Host: tyger.east.sun.com

Quoth bob@MorningStar.Com (Bob Sutterfield) (in <BOB.92Dec23111456@volitans.MorningStar.Com>):
#In article <105528@bu.edu> apollo@buengc.bu.edu (Doug A. Chan) writes:
#   I'm trying to get SLIP working between a PC using PC-NFS 4.0 and a
#   Xylogics Annex 3 terminal server.  I've gotten as far as getting
#   NFS to work (mounting a unix directory on the PC over SLIP)
#
#Beware!  Unless you have turned on UDP checksumming on both your NFS
#server and your PC, you're in danger of corrupting your files.  SLIP
#offers no link-level error detection, and even if you're using modems
#with MNP4 or V.42 error correction, things like UART overruns can
#introduce errors into the data stream.

Agreed. Note that PC-NFS 4.0 ships with UDP checksumming turned on;
you have to explicitly turn it off if you wish to live dangerously.
As Bob says, you still have to check your server, however. On Solaris 2.x
(and, I believe, all SVR4 Unix systems) UDP checksumming is on by default.
On SunOS 4.1.2 it is OFF; to turn it on, patch the value _udp_cksum
in /vmunix to 1 and reboot.

Geoff
--
Geoff Arnold, PC-NFS architect, Sun Select. (geoff.arnold@East.Sun.COM)
****************** Please reply to the above address (or geoff@east.sun.com).
* BOGOSITY ALERT * Our netnews software is currently generating bogus sender
****************** addresses. I'll get them to fix it is soon as possible...
Xref: sparky comp.protocols.tcp-ip:5743 comp.unix.questions:14965
From: dyck@mpr.ca (Trevor Dyck)
Newsgroups: comp.protocols.tcp-ip,comp.unix.questions
Subject: Lachman TCP/IP
Date: 24 Dec 92 18:50:56 GMT
Article-I.D.: mprgate.1992Dec24.185056.27726
Organization: MPR Teltech Ltd., Burnaby, B.C., Canada



Does anyone have the phone number or address for Lachman Associates, Inc.??
They make Lachman TCP/IP which is running on my Unix SVR4.

Actually, any info on Lachman TCP/IP would be appreciated!!

Thanks a lot,

Trevor.
-- 
Trevor Dyck (dyck@mpr.ca)      | "The number of Unix installations has grown 
Advanced Technology Division   |  to 10, with more expected" 
MPR Teltech Ltd. 	       |  -- The Unix Programmer's Manual, 2nd Edition,
8999 Nelson Way, Burnaby, BC   |     June, 1972 
Newsgroups: comp.protocols.tcp-ip,comp.unix.bsd
From: tony@mtu.edu (Tony Dal Santo)
Subject: Re: Limiting Telnet access.
Organization: Michigan Technological University
Date: Tue, 22 Dec 1992 18:32:13 GMT

tony@mtu.edu (Tony Dal Santo) writes:
>
>Along these lines, I am curious if anyone has an idea how to allow
>certain users access to the network, and deny others.  Something
>like putting the user in group "network" to grant them access.  By
>access, I mean system call level access like socket().  Even better
>would be to provide a list of addresses/networks that are restricted/
>allowed.
>
>I imagine with a streams implementation of tcp/ip, you could change
>the perms on /dev/ip or /dev/tcp.
>
>Does anyone have any utilities for tracing a TCP port to a process number?
>
>Tony Dal Santo
>tony@mtu.edu

Evidently I was not too clear since I have received a few pointers
directing me to inetd wrappers.  I am interested in restricting/granting
users access TO the network FROM my hosts.  I can restrict access to
the binaries (telnet, ftp, etc), but this doesn't stop them from compiling
their own copies of these utilities.  The only way I see to filter access
is to control system calls like socket(), bind(), accept().  I can limit
access to networks via routing tables, but this doesn't provide user-level
granularity.

While inetd wrappers are nice, I don't see them addressing the problem.
Once I get access to your machine, I will bring my own set of utilities
with me (inetd), and avoid the administrators attempts at logging.
Granted that some of the users "daemons" (e.g. ftpd) won't be as functional
as the real ones because they don't run as root, but they will certainly
let me gain access and avoid being logged.  Sure, as an administrator I
can see these processes, and kill them off.  Then the users will restart
them via cron(8) and at(1).  I don't have the time to play hide and seek
with users.

Tony Dal Santo
From: scoggin@mercury.delmarva.com (John K. Scoggin)
Newsgroups: comp.protocols.tcp-ip
Subject: RMON-Compliant Ethernet Monitors
Date: 29 Dec 1992 08:40:15 -0500
Organization: Delmarva Power & Light Company
Distribution: world
NNTP-Posting-Host: mercury.delmarva.com

Does anyone have a list of RMON-compliant ethernet monitors?  I am familiar
with Hewlett-Packard, TTC, and Novell - are there others?

Many thanks.  I will post a summary.

	- John

+---------------------------------------------------------------------+    
|  John K. Scoggin, Jr.			Email: scoggin@delmarva.com   |
|  Supervisor, Network Operations       Phone: (302) 451-5200         |
|  Delmarva Power & Light Company       Fax:   (302) 451-5321         |
|  500 N. Wakefield Drive               NOC:   (800) 388-7076         |
|  Newark, DE 19714-6066		                              |
+---------------------------------------------------------------------+
Newsgroups: comp.protocols.tcp-ip
From: ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
Subject: Re: PCS WITH DUPLICATE TCP ADDRESSES
Date: Tue, 22 Dec 92 19:19:07 GMT

BOOTP is major bad idea.  You have to configure your routers to pass the
silly stuff 'cuz you won't necessarily have a load host in all subnets.
This means you lose the usual isolation that IP provides you between 
subnets (BOOTP uses a global IP broadcast).

Also, if your BOOTP logs all requests, a station whose download doesn't
get satisfied typically requests every five seconds and ends up filling
up the logs on systems.

Charles.
--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IS&DP Network Services		AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689
Newsgroups: comp.protocols.tcp-ip
From: peter@cujo.curtin.edu.au (Peter N Lewis)
Subject: Re: Limiting Telnet access.
Followup-To: comp.protocols.tcp-ip,comp.unix.bsd
Organization: NCRPDA, Curtin University
Date: Mon, 21 Dec 1992 05:15:08 GMT

In article <1992Dec17.230214.16501@vector.dallas.tx.us>,
tbo@vector.dallas.tx.us (Terry Bohaning) wrote:
> 
> 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.

Grab log_tcp.  It will log all tcp connections, and deny access to 
certain sets of them (or all except certain sets) on an individual
program basis (as long as the program is started via inetd).  For
example, my setup looks something like this:

ALL : 123.4.567. : NOLOG
in.identd : ALL : LOG
in.ftpd : 123.4.789.80 : NOLOG
gopherd in.ftpd in.telnetd in.rshd in.rlogind in.rexecd : 123.4.789.81
123.4.789.80 : LOG
in.fingerd : ALL : LOG
in.telnetd gopherd in.ftpd : ALL : LOG : /usr/ucb/finger -l @%a |
/usr/ucb/mail -s "Warning, service %d requested by %h [%a]" root &
ALL : ALL : DENY : /usr/ucb/finger -l @%a | /usr/ucb/mail -s "Warning,
service %d requested by %h [%a]" root &

So it allows all services from my logal domain without any logging (which
helps keep the log file size down), logs all identd accesses, no logging of
ftp accesses from a local machine, allows accesses from a few other local
machines (with logging), logs all finger requests, logs all telnet, gopher
and ftp requests and fingers the machine and sends a warning to root (but
of course, all local accesses were previously dealt with, so this only
happens for accesses from strange places), and deny all other access (and
report the possible attack).

BTW, the above includes extensions I made that havent been released to
allow the NOLOG option, but the log_tcp package should do what you want
anyway.

Everyone should be running this, it gives you lots of early warnings, and
totally cuts off a lot of potential attacks.

Have fun all,
   Peter.

_______________________________________________________________________
Peter N Lewis <peter@cujo.curtin.edu.au>             Ph: +61 9 368 2055
From: bansal@cis.ksu.edu (Vivek Bansal)
Newsgroups: comp.protocols.tcp-ip
Subject: Books....
Date: 29 Dec 1992 17:09:06 GMT
Organization: Kansas State University, Dept. of Computing and Information Sciences
Distribution: world
NNTP-Posting-Host: depot.cis.ksu.edu


I am looking references to some books which deals with writing system 
software using UNIX and TCP/IP. I already have Comer and Stevens .

I intend to write some device driver using STREAMS, switch software and
other such kind of network software in near future. Any references in this
context would be really appreciated.

Thanks in advance.

Vivek...
Newsgroups: comp.protocols.tcp-ip
From: amarkel@encore.com (Arieh Markel)
Subject: Help with udp-ip message broadcast
Organization: Encore Computer Corporation
Date: Wed, 30 Dec 1992 22:02:58 GMT
Summary: Need some help regarding multicast protocols over IP
Keywords: udp,tcp,broadcast,multicast

I would appreciate any help, pointers, related RFCs to the area
of protocols of message multicasting.

The problem I am trying to resolve is how to issue a single send
to a (possibly known) set of destination machines that is connected
via IP.

Acknowledgements will (obviously) come at different times from
the different machines that received the message.

Please, respond via e-mail.

Thanks in advance.

Arieh Markel
-- 
 Arieh Markel		  		        Tel: (305)-797-2403
 Encore Computer Corporation                    amarkel@encore.COM
 Optimizer & Instruction Scheduler Group        uunet!gould!amarkel
 Ft. Lauderdale, FL
From: ajudge@maths.tcd.ie (Alan Judge)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Any good TCP/IP books?
Date: 29 Dec 92 17:49:52 GMT
Organization: Dept. of Maths, Trinity College, Dublin, Ireland.

jonathan@rahul.net (Jonathan Heiliger) writes:
>    Would anyone reccomend a particular book for learning TCP/IP, and 
>networking in general to a greater extent.  I'm planning on taking quite a 
>few Data Communications classes, however I would like to have some 
>information before I start!

For TCP/IP comms in the Unix world, Unix Network Programming by W.
Richard Stevens is the best that I have ever seen.

It is published by Prentice Hall, ISBN 0-13-949876-1
-- 
Alan Judge   ajudge@maths.tcd.ie  a.k.a. amjudge@dsg.cs.tcd.ie +353-1-7021782

"The path of my life is strewn with cowpats from the devils' own herd."
                                          -- Edmund Blackadder II
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: PCS WITH DUPLICATE TCP ADDRESSES
Date: 21 Dec 92 23:14:02 MDT
Organization: Utah State University

In article <1992Dec20.094107.1@kean.ucs.mun.ca>, wayne@kean.ucs.mun.ca writes:
> In article <1992Dec19.135454.548@fallst>, tkevans@fallst (Tim Evans) writes:
>> wayne@kean.ucs.mun.ca writes:
>> 
>>>My question is " Is there a way to prevent a pc from accessing the network 
>>>if there is already a pc on the network at that moment with the same tcp 
>>>address as the one attempting access ?
>> 
>> If kermit supports use of 'bootp' (I don't know if it does), you can
>> use it to control IP addresses from a central server.  This works on
>> a real network.  You can get UNIX bootp from CMU.
>> -- 
>> UUCP:		{rutgers|ames|uunet}!mimsy!wb3ffv!fallst!tkevans
>> INTERNET:	tkevans%fallst@wb3ffv.ampr.org
>> Tim Evans	2201 Brookhaven Ct, Fallston, MD 21047
> 
> Is there a VMS bootp from CMU ? I looked via FTP and saw unix-based bootp 
> files but no VMS-based ones.
> 
> /sig
--------------
	Yes, MS-DOS Kermit supports both Bootp and RARP. My site prefers
Bootp. However, when we had the main VAX service it with TGV's Multinet
the console log registered each request (translation: monitor screen gets
written all over by such traffic). So we moved the main Bootp server to
a Sun box.
	Just the other day I added a small item which might be useful in
the next release of Kermit. If the Bootp server includes the client's IP
name in the response then I strip off the first word and dot and use the
remainder as the domain extension appended during DNS lookups. It seems 
to be ok so far, and I'll provide an out just in case.
        What I have not done is ping my own IP looking for conficts. I have
a Ping built-in but the trouble of doing this (and explaining results to
users) seems more than it's worth. However, if people feel strongly about it
I can turn on the feature. Last year my students did some simple tests of
bringing up Kermits with the same IP. The worst that happened was a connection
would be dropped as routers got confused. Of course, just plucking IP addresses
out of thin air is plenty of trouble.
        Joe D.
Newsgroups: comp.protocols.tcp-ip,comp.protocols.nfs
From: bob@MorningStar.Com (Bob Sutterfield)
Subject: Re: PC-NFS SLIP and telnet problem
Followup-To: comp.protocols.tcp-ip
Organization: Morning Star Technologies
Date: Wed, 23 Dec 1992 16:15:00 GMT

In article <105528@bu.edu> apollo@buengc.bu.edu (Doug A. Chan) writes:
   I'm trying to get SLIP working between a PC using PC-NFS 4.0 and a
   Xylogics Annex 3 terminal server.  I've gotten as far as getting
   NFS to work (mounting a unix directory on the PC over SLIP)

Beware!  Unless you have turned on UDP checksumming on both your NFS
server and your PC, you're in danger of corrupting your files.  SLIP
offers no link-level error detection, and even if you're using modems
with MNP4 or V.42 error correction, things like UART overruns can
introduce errors into the data stream.

SLIP won't notice an error unless the error damages the SLIP frame
flag itself.  IP won't notice an error unless the error damaged the IP
header, which is subject to a checksum.  IP doesn't checksum the rest
of the user data in the packet.  Unless you've turned on UDP
checksumming on both ends of the NFS transaction, UDP won't notice the
error in the user data, and will pass the packet on up the protocol
stack to the NFS software layer.  NFS (at the application layer)
naively assumes it's getting good data from the underlying layers, and
will swallow the bad packet without question.

I have personally experienced file corruption because I used NFS over
a SLIP link.  It can give some very mysterious symptoms...
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221           +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)
Newsgroups: comp.protocols.tcp-ip
From: klaatu@rose.handy.co.kr (Kim)
Subject: How can I get RFC?
Organization: HandySoft Institute of Technology, HandySoft Corp.
X-Newsreader: Tin 1.1 PL3
Date: Mon, 21 Dec 92 09:04:06 GMT

Hi,

I want to obtain some RFCs for tcp/ip, SMTP, and so on. I read the book
"Internetworking with TCP/IP" by D. Comer, and found that mailing to
info-server@sh.cs.net could let me to get them, but it does not work now.
Please let me know how I can get RFCs.
Thanks in advance.

-- Kim, Young Hoon
   klaatu@rose.handy.co.kr
   klaatu@sorak.kaist.ac.kr --
Newsgroups: comp.protocols.tcp-ip
From: shaman@cix.compulink.co.uk (Leo Smith)
Subject: Re: TCP/IP vs. PATHWORKS
Reply-To: shaman@cix.compulink.co.uk
Date: Fri, 1 Jan 1993 18:41:00 +0000


..Not forgetting Pathworks for Macintosh, which is an appletalk 
server on your DEC mini...:-)
From: klaus@kphunix.han.de (Klaus Peter Herrmann)
Newsgroups: comp.protocols.tcp-ip
Subject: LAN 8bit
Date: 1 Jan 93 16:59:53 GMT
Organization: kphunix  Hannover Niedersachsen Germany Europa

I like to have an 8 bit connection on the remote login (abount telnetd).
The LAN is from Lachman. The Terminal-emulation on my PC can work
in 7-bit or 8-bit mode. But the System (SCO Unix) gives only an 
7-bit connection. Where can I change this?

Klaus

-- 
-------------------------------------------------------------------
Klaus - Peter Herrmann  	klaus@kphunix.UUCP
W-3000 Hannover   		klaus@kphunix.han.de
-------------------------------------------------------------------
From: wjq@uts.amdahl.com (Bill Quigley)
Newsgroups: comp.protocols.tcp-ip
Subject: what to do with those pesky Unix domain socket files
Keywords: tcp/ip sockets
Date: 23 Dec 92 00:31:24 GMT
Organization: Amdahl Corporation, Sunnyvale CA

In our new SVR4 kernel, bind() to a unix domain socket creates a file
with the name specified in the bind call.  But if the process is killed,
the file stays around, and when the process comes up again, it cannot
bind to the same name, and gets EADDRINUSE, even though there isn't
a valid socket using that name.

How do others get around this problem?

Thanks.
-- 
Flower Cake - Trends in food come and go, but
the popularity of cookies never wanes - easy to make, easy to eat.
Bill Quigley
Amdahl - UTS CCE
wjq@charon.amdahl.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: PCS WITH DUPLICATE TCP ADDRESSES
Date: 23 Dec 92 03:51:10 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1992Dec22.191907.23824@mmm.serc.3m.com>, ccg@tcdsp1.mmm.com ("Charles Ganzhorn") writes:
> BOOTP is major bad idea.  You have to configure your routers to pass the
> silly stuff 'cuz you won't necessarily have a load host in all subnets.
> This means you lose the usual isolation that IP provides you between 
> subnets (BOOTP uses a global IP broadcast).
> 
> Also, if your BOOTP logs all requests, a station whose download doesn't
> get satisfied typically requests every five seconds and ends up filling
> up the logs on systems.


These complaints concern some implementations of bootp clients,
servers, and forwarders, not of the protocol itself.


Vernon Schryver,  vjs@sgi.com
From: panvalka@cs.unc.edu (Anay Panvalkar)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Books....
Date: 1 Jan 1993 23:21:53 -0500
Organization: The University of North Carolina at Chapel Hill
NNTP-Posting-Host: opsin.cs.unc.edu

In article <bansal.725649006@depot.cis.ksu.edu.cis.ksu.edu> bansal@cis.ksu.edu (Vivek Bansal) writes:
>
>I am looking references to some books which deals with writing system 
>software using UNIX and TCP/IP. I already have Comer and Stevens .
>
>I intend to write some device driver using STREAMS, switch software and
>other such kind of network software in near future. Any references in this
>context would be really appreciated.

I find the Sun Network Programming manual (Sun OS 4.1.2) very useful for 
STREAMS programming.

-Anay
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Problems detecting a dead client connections ??????
Keywords: TCP crashes
Date: 1 Jan 93 22:34:18 GMT
Organization: Auspex Systems, Santa Clara

>But this may well annoy (or bankrupt) users of PayPerPacket networks, or
>those with Dial On Demand serial links.

It may well also annoy people who don't want the application to give up
on the machine on the other end of the connection just because some
router or link between the two machines was down for a while....
Newsgroups: comp.protocols.tcp-ip
From: rstevens@noao.edu (W. Richard Stevens)
Subject: Re: what to do with those pesky Unix domain socket files
Keywords: tcp/ip sockets
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Date: Wed, 23 Dec 1992 12:43:15 GMT

> In our new SVR4 kernel, bind() to a unix domain socket creates a file
> with the name specified in the bind call.  But if the process is killed,
> the file stays around, and when the process comes up again, it cannot
> bind to the same name, and gets EADDRINUSE, even though there isn't
> a valid socket using that name.
>
> How do others get around this problem?

SOP is an unlink() before the bind(), ignoring the return code.

	Rich Stevens  (rstevens@noao.edu)
Newsgroups: comp.protocols.tcp-ip