HDTenEightyP/NetNews huggingface dataset:
From: psirakis@yoko.rutgers.edu (Psirakis Alexander)
Newsgroups: comp.protocols.tcp-ip
Subject: bind-socket #2
Date: 9 Apr 92 15:00:19 GMT
Organization: Rutgers Univ., New Brunswick, N.J.



Thanks to everyone who answered to my question concerning the 
the "bind" of two or more socket descriptors to the same local port.

I thought that this is possible by using the "setsockopt" system
call with "SO_REUSEADDR" as an argument.

I tried all the possibly correct sequencies of system calls (socket, bind, 
setsockopt etc) but always the same result:
              "Address already in use"

So I came to the conclusion that this is impossible to be done (at least at 
the SunOS where I am working).

Again thank you 

Alexander Psirakis
e-mail: psirakis@yoko.rutgers.edu
From: rlk@VisiCom.COM (Bob Kitzberger)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: mayonnaise
Date: 16 Apr 92 22:34:12 GMT
Article-I.D.: visicom.174
Organization: VisiCom Laboratories, Inc., San Diego, California

In article <10682@platypus.uofs.uofs.edu> bill@platypus.uofs.edu writes:
>|> 
>|> I also encourage you not to investigate any RFC issued on April 1st of
>|> any year (particularly RFC 1149 and RFC 1097).
>|> 
>|> Oh, and :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
>
>And especially, Do Not under any circumstances look up RECURSION in the old
>UCSD PASCAL Manual from Softech Microsystems.

...nor look up "camels" in "Programming Perl",  

...nor "laziness", "hubris", "great programmer", and "impatience" in the 
same book.    

...nor more apropos for this group, "carrier pigeon" in the same book. 

...nor "squirrel" in the original K&R C...


Any more, and this'll belong in alt.folklore.something-or-other

	.Bob.
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
			+1 619 457 2111    FAX +1 619 457 0888
From: "william mercer" <william.mercer@canrem.com>
Newsgroups: comp.protocols.tcp-ip
Subject: pd ftp without telnet
Date: 16 Apr 92 14:19:43 EST
Reply-To: "william mercer" <william.mercer@canrem.com>
Distribution: comp
Organization: Canada Remote Systems

Recently johnw@medisg.Stanford.EDU (John Wiederhold) writes:

(request for PD or commercial FTP software package....)

John, we're currently using Novell's (formerly Excelan's) LAN WorkPlace
for DOS which runs over Novell's ODI.  Pretty good, allows for a wide
variety of NICs.  I selected this over Beame & Whiteside, FTP Software,
Wollongong, and another one (the name of which escapes me now) for
reasons of cost (about CA$1800.00 for 10-user pkg.), compatibility
(allows for Novell's IPX protocol concurrently), flexibility (didn't
need to buy a package specific to my needs or hardware, like FTP
Software), and support (corporate commitment to Novell, Oracle support
extremely desireable for client-server).  I suppose I should mention
memory:  No drivers get loaded from CONFIG.SYS, and the requisite ones
can be loaded/unloaded in a BAT file.  Caveat:  There's a known bug in
TELAPI.EXE which doesn't release two file handles upon unloading from
RAM, hence if, for example, your FILES=30 (in CONFIG.SYS), then you'll
notice odd problems (e.g., File Creation Error) after your 15th unload.
Of course, you can up your FILES= value to delay the problem, but the
probability of going in and out of telnet this many times is low.
Hmm...just realized that telnet isn't the issue here.  Since FTP.EXE
doesn't need TELAPI.EXE, you're all set.

Having said that, you may want to consider Beame & Whiteside's TCP/IP
package.  This was the one serious contender against LWP, but because
the Oracle support was lacking....  One of the bonus features of this
vendor's package is that it can use the Clarkson packet drivers.  In
fact, I've seen a history file (which was included in the PD sniffer
developed at on of the universities in Holland - "Netcure," perhaps?)
which mentioned Carl Beame's contribution to the Clarkson packet
drivers.  Naturally, B&W claim that their implementation is the fastest
performer, a claim I cannot prove or disprove.  If you're already using
Clarkson packet drivers, this may be the ticket for you.

A question to all (putting on the Corporate Hat):  If we were to move to
Clarkson packet drivers, whose neck would be on the line for support?

Jim Carroll (william.mercer@canrem.uucp)
--
Canada Remote Systems  - Toronto, Ontario/Detroit, MI
World's Largest PCBOARD System - 416-629-7000/629-7044
From: mwitt@ogicse.ogi.edu (Mike Witt)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Negative ping times
Date: 17 Apr 92 06:03:36 GMT
Article-I.D.: ogicse.36382
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR


Frank,

Sometimes on a very fast optical link, packets can actually
exceed the speed of light.  This has been known to cause negetive
"ping" times, as well as an occasional ack for a packet that has not 
yet been sent.

It's nothing to worry about.

-Mike
From: 880274d@aucs.acadiau.ca (Ralph I. Doncaster)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Packet sniffer for IBM-PC?
Date: 7 Apr 92 17:05:28 GMT
Organization: Acadia University

srp@modcomp.uucp (Steve Pietrowicz) writes:

>Is there a PD packet sniffer available for the PC?  If so, where can I
>get it?

>Thanks

>Steve
Mit's netwatch if quite good.
you'll need drivers.zip and pcippkt.arc from /ka9q dir in
sun.soe.clarkson.edu.
(This was as of about 2 months ago; could have changed by now.
-Ralph

--
|Ralph Doncaster, Acadia Univ.     ph & fax: (902)542-3010      |
|880274d@aucs.acadiau.ca   ASU box 6585, Wolfville, NS B0P 1Z1  |
From: liam@dcs.qmw.ac.uk (William Roberts)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Question on bind-socket
Date: 7 Apr 92 09:26:12 GMT
Organization: Computer Science Dept, QMW, University of London

In <Apr.6.17.10.32.1992.6859@yoko.rutgers.edu> psirakis@yoko.rutgers.edu 
(Psirakis Alexander) writes:

>I want to bind a second socket descriptor (sockt2) to a port that is
>already assigned to another socket (sockt).

Stop right there. You absolutely cannot do this because it just isn't possible 
given the semantics and implementation of BSD sockets. If I guess correctly 
about what you want to do, you are going to need to open two separate sockets, 
one for each address, and then use select() rather than recvfrom() to find out 
when datagrams are available.

>I tried to use the setsockopt system call, with arguments SOL_SOCKET and
>SO_REUSEADDR. The setsockopt is correctly executed and I also test it
>with the getsockopt system call.

SO_REUSEADDR is about something else (possibly waiving the "twice 
mean-segment-lifetime" delay on TCP sockets which prevents accidental 
acceptance of delayed traffic?), it isn't relevant to your problem anyway.
--

% William Roberts                 Internet:  liam@dcs.qmw.ac.uk
% Computer Science Department     
% Queen Mary & Westfield College  UUCP:      liam@qmw-dcs.UUCP
% Mile End Road                   Telephone: +44 71 975 5234
% LONDON, E1 4NS, UK              Fax:       +44 81-980 6533
From: Dean.Roth@mixcom.mixcom.com (Dean.Roth)
Newsgroups: comp.protocols.tcp-ip
Subject: 3B2 client-server latency problem
Date: 17 Apr 92 15:09:57 GMT
Article-I.D.: mixcom.1992Apr17.150957.17268
Distribution: usa
Organization: Milwaukee Internet Xchange BBS, Milwaukee, WI U.S.A.


I'm new to an organization that has a server running on
a 3B2.  I've seen a large latency between when data is
sent by a client and when the read in the server completes.

I created test client and server programs that simply 
exchange a 1K block of data. When run on any machine
other than the 3B2 the latency between write and read 
is nearly zero. However, when both the client and server
operate on the 3B2 there is a 1-2 second lag between the
client's write and when the server's read completes.

I've never worked with a 3B2 before. Is this behavior
characteristic of this machine?  The software is using 
the socket API.  Thank you.

Dean
Xref: sparky comp.protocols.tcp-ip:2491 comp.unix.wizards:2156
From: wswietse@wsbs06.bs.win.tue.nl (Wietse Venema)
Newsgroups: comp.protocols.tcp-ip,comp.unix.wizards
Subject: Re: LPR on a terminal server, Opinions?
Date: 10 Apr 92 14:52:48 GMT
Reply-To: wswietse@bs.win.tue.nl
Followup-To: comp.protocols.tcp-ip

mike@gordian.com (Michael Thomas) writes:


>   I am considering writing a LPRd for a terminal/printer server (from
> RFC 1179).  The obvious win with implementing LPR within a terminal server
>is that no special host software is needed. The loses, however, appear to be
>many. The basic problem is that LPR expects another unix system on the remote
>side with spooling capabilities, and various output filters. A terminal
>server is a limited environment though (how many have you seen with 100 meg
>drives? ;-).

There may be a simpler alternative. This is what we do:

Some terminal servers allow you to "reverse" one or more ports. The 
result is that a connection to a user-defined socket number on the
terminal server gives bidirectional access to one of its serial ports.

On the UNIX host we run a trivial program that connects a pty (master
end) to the above-mentioned socket on the terminal server. The link
is bidirectional.

In order to access the printer, the lpd daemon opens the pty (slave
end) just like any hard-wired serial port. 

    lpd <--> pty <--> daemon <--> server <--> printer

This setup works fine with our postscript printers.

	Wietse
Newsgroups: comp.protocols.tcp-ip
From: k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
Subject: Re: NIS, broadcast, etc. Need help
Keywords: NIS, YP, broadcast - help
Organization: Technische Universitaet Muenchen, Germany
Date: Thu, 9 Apr 1992 23:05:33 GMT

frank@rniwi.rni.sub.org (Frank Mogaddedi) writes:

>Connected to that are 3 *nix-Boxes only capable of ethernet-connections,
>integrated into the TR thru 3 Novell-3.11 Routers.

>ftp, rlogin, telnet, nfs etc. all work fine over the net. I currently
>have the nets set up as 4 different class A Networks, 1.0.0.0, 2.0.0.0
>3.0.0.0 and 4.0.0.0. I feel this is OK, since we don't plan to go
That's really ok, as long as you didn't want to connect to the world,
but even in this case its better to get a official net. You don't know
what the future brings to you, maybe you decide in the future to
connect to the net ? As I know you can get a Class C net at no more
cost as writing a letter, as long as you didn't connect.

>Now my problem: I would like to only have one NIS(YP) Server.
>How can I do this? How do I convince th other machines to look beyond
>their own net? What has the broadcast-address to do with it?
NIS didn't work outside a net or subnet, as broadcast wouldn't forwarded
by the routers. With some routers you could do some hacks, to let them
forward, but I suspect this isn't possible with your Novell boxes.

Maybe a explicit "ypset server" works. At least this works with my
CDC boxes, but I don't do it regularly, I only tried it sometimes for
debugging purposes.

It's generally a bad idea to have only one NIS server, as you get a
single point of failure. This wouldn't matter, as long as your homedirs
are at the same server, but if your homedirs are spread over your boxes,
you could avoid complete failure. In my configuration (10 Unix-boxes 
on two subnets, and numerous X-Terms) I did have at least two NIS
servers on every subnet.

>I can change the IP-Addresses, if necessary, but I understand that I still
>need subnetworks, since the novell-router doesn't do what I hav been said
>is called 'source-routing' on ethernet..
Yes you need subnetworks, or hostroutes, if there's only one Unix-box
after each Novell Box. Wouldn't it simpler to connect the three Unix-boxes
with Ethernet, and use one Novel Box to connect them to your TR ?
Or is it a matter of distance or cabling?

Sincerely,
Klaus Steinberger
--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-8046 Garching, Germany
Internet: Klaus.Steinberger@bl.physik.uni-muenchen.de
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
From: pct@leo.stanford.edu (Peter C Tam)
Subject: Intel EtherExpress 16/16TP Clarkson Driver
Originator: pct@leo.Stanford.EDU
Organization: Research Libraries Group, Inc. Mountain View, CA.
Date: Tue, 14 Apr 92 17:01:48 GMT


HI,
  I am looking for a better, improved, bug fixed version of Intel EtherExpress
16/16TP FTP spec/Clarkson packet driver than the one provided by the hardware
vendor.
  Thanks for any help........
From: wswietse@wsbs06.bs.win.tue.nl (Wietse Venema)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: "Future" TCP/IP and Security?
Date: 30 Mar 92 10:41:27 GMT
Reply-To: wswietse@bs.win.tue.nl

greenie@drycas.club.cc.cmu.edu writes:

>Does anyone know of any future implementations of TCP/IP or modifications
>to the current processes which would improve security?  IE, preventing
>"anybody" from TELNETting to the SMTP port and sending anonymous hate
>mail and other such things like that?

For a simple way to implement access control to network daemons, see:

    cert.sei.cmu.edu:/pub/network_tools:/tcp_wrapper.shar
    ftp.win.tue.nl:/pub/security/log_tcp.shar.Z
    ftp.win.tue.nl:/pub/security/log_tcp_patch

It was originally intended to add some security to daemons started by
the inetd, but it can be used for the sendmail daemon, too, by having
it run "on demand". A sample inetd.conf entry would be:

    smtp stream tcp nowait root /usr/etc/tcpd /usr/lib/sendmail -bs

Where tcpd is the tcp wrapper from the above archives. You'll probably
need to apply the log_tcp_patch file if the sendmail daemon needs to be
specified with an absolute path name.

Now that the sendmail daemon is started "on demand", you will also have
to run a cron job that at regular intervals scans the sendmail mail
queue. Something like:

    0,15,30,45 * * * * /usr/lib/sendmail -q

should take care of that.

	Wietse
From: pjangli@afterlife.ncsc.mil (Philip Anglin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: LPR on a terminal server, Opinions?
Date: 10 Apr 92 22:04:52 GMT
Organization: The Great Beyond

In article <3293@svin02.info.win.tue.nl> wswietse@bs.win.tue.nl writes:
>mike@gordian.com (Michael Thomas) writes:
>
>
>>   I am considering writing a LPRd for a terminal/printer server (from
>> RFC 1179).  The obvious win with implementing LPR within a terminal server
>>is that no special host software is needed. The loses, however, appear to be
>>many. The basic problem is that LPR expects another unix system on the remote
>>side with spooling capabilities, and various output filters. A terminal
>>server is a limited environment though (how many have you seen with 100 meg
>>drives? ;-).
>
>There may be a simpler alternative. This is what we do:
>
>Some terminal servers allow you to "reverse" one or more ports. The 
>result is that a connection to a user-defined socket number on the
>terminal server gives bidirectional access to one of its serial ports.
>
>On the UNIX host we run a trivial program that connects a pty (master
>end) to the above-mentioned socket on the terminal server. The link
>is bidirectional.
>
>In order to access the printer, the lpd daemon opens the pty (slave
>end) just like any hard-wired serial port. 
>
>    lpd <--> pty <--> daemon <--> server <--> printer
>
>This setup works fine with our postscript printers.
>
>	Wietse

We have this type of setup, but it breaks all the time (broken pipes).
The program is some public-domain thing called collect that our
terminal server vendor gave us.

-- 
Name:         Philip J. Anglin
Mail address: pjangli@afterlife.ncsc.mil
Disclaimer:   Opinions stated are those of the author alone,
              not the Department of Defense or the U.S. Government.
Newsgroups: comp.protocols.tcp-ip
From: chris@gargoyle.uchicago.edu (Chris Johnston)
Subject: tcp printer servers
Keywords: lpd/tcp/print
Organization: University of Chicago Computing Organizations
Date: Mon, 6 Apr 1992 21:15:24 GMT

    Anyone used any of the tcp printer servers?  With a Sun?  With
LPD?  Do they work?  With a laserjet?  Postscript?  NeWSprint?  The
marketing info is summarized below.

    The Microplex M200 sits on the ethernet and has three ports, one
parallel at 50 kBps and two serial at 38.4 kbps.

    The Milan Fastport has three flavors of ethernet ports, one
parallel port and one 38.4k baud serial port.  It also has a switch to
fully support Adobe's fancy parallel protocol.

thanks,
cj
From: pwickman@cerebus.cc.edu (Paul J. Wickman)
Newsgroups: comp.protocols.tcp-ip
Subject: ping question
Date: 9 Apr 92 05:35:13 GMT
Article-I.D.: carroll1.3097
Reply-To: pwickman@cerebus.cc.edu (Paul J. Wickman)
Organization: Carroll College-Waukesha, WI


	Does anybody have the code for the Sun/IBM/whatever version
of ping?  The one that can report "host is alive" in addition to the
verbose mode?


--
Paul J. Wickman - Systems/Network Administrator, Computer Science Dept.
Carroll College	 Waukesha, WI 53186
Internet: pwickman@carroll1.cc.edu	Phone: 414-524-7343
From: sob@hsdndev.UUCP (Scott Bradner)
Newsgroups: comp.protocols.tcp-ip
Subject: FDDI & token ring router & bridge tests at Harvard
Date: 12 Apr 92 23:44:21 GMT
Organization: Harvard University


Well, its that time again.  I'm starting a new round of router &
bridge tests.  This round will deal with FDDI & token ring using the
following arangements: (DUT = Device Under Test, a router or a bridge)

    -------------  -----------  --------------
   /             \ |         | /              \
  < fddi ring #1  >|   DUT   |<  fddi ring #2  >
   \             / |         | \              /
    -------------  -----------  --------------

    --------------  -----------  ---------------
   /              \ |         | /               \
  < token ring #1  >|   DUT   |<  token ring #2  >
   \              / |         | \               /
    --------------  -----------  ---------------

    --------------  -----------        -----------  ---------------
   /              \ |         |        |         | /               \
  < token ring #1  >|   DUT   |==WAN===|   DUT   |<  token ring #2  >
   \              / |         |        |         | \               /
    --------------  -----------        -----------  ---------------

          -----------  ---------------  -----------
up to-----|         | /               \ |         |----- up to
  6  -----|   DUT   |<   fddi ring     >|   DUT   |-----   6
Enets-----|         | \               / |         |----- Ethernets
          -----------  ---------------  -----------

    --------------  -----------  -----------  -----------  --------------
   /              \ |         | /           \ |         | /              \
  < token ring #1  >|   DUT   |<  fddi ring  >|   DUT   |<  token ring #2 >
   \              / |         | \           / |         | \              /
    --------------  -----------  -----------  -----------  --------------

Tests will be run using a number of protocols to measure throughput and
aggregate packet handling ability.  The tests will be run in the Harvard
Network Device Test Lab in Cambridge MA.

The results of the tests will be reported during my tutorial and at a BOF
on Wed night at Interop in DC in May.  The results will also be put
on hsdndev.harvard.edu for anonymous FTP and appear in an article in Data
Communications.

If you have any suggestions for specific tests please let me know.

The tests are open to all vendors who would like to show up, there is no
fee.  There two required and one suggested condition for inclusion:

required:
	1/ the router or bridge hardware and software must be available to
	customers within 3 months of Interop or at the next "normal"
	software release if a calandar-based schedule is used.
	2/ all results of the tests will be reported unless superceded
	during the test period with other results. (i.e. you are allowed
	to fix bugs)

suggested:
	a vendor representative should be present during the tests to
	do the device setup to ensure that it is done correctly.

Please contact me via email at the address below or via phone at
617-495-3864 if you would like to be included.


	Scott Bradner
	sob@harvard.edu
From: xeee01@mixcom.com (Aniruddh Chawda)
Newsgroups: comp.protocols.tcp-ip
Subject: One physical wire, multiple logical networks question
Date: 9 Apr 92 13:38:34 GMT
Article-I.D.: mixcom.1992Apr09.133834.14574
Distribution: usa
Organization: Milwaukee Internet Xchange BBS, Milwaukee, WI U.S.A.


I have run into a situation where there is one physical
network, but a need to have multiple logical networks.
(Product testing and evaluation.)

If different computers are attached to the same wire, but
use different network addresses, is a router required
so that they will talk to each other?
From: tjg01@thdhub.UUCP (Terry Gardner)
Newsgroups: comp.protocols.tcp-ip
Subject: Reverse telnet
Date: 14 Apr 92 15:21:10 GMT
Organization: The Home Depot, Inc.


What is 'reverse telnet'? I've seen it advertised by some PC net software
vendors, but I've never heard of it.

-- 
Terry Gardner, terry@thdhub, terry%thdhub@uunet
Senior Network Systems Programmer @ The Home Depot, Inc.
404-433-8211 x 5124 Message Generated with GNU Emacs 18.58...
Aborting, Retrying, Failing, and Ignoring.....
From: andersen@unidoct.chemietechnik.uni-dortmund.de (Frank-Uwe Andersen)
Newsgroups: comp.protocols.tcp-ip
Subject: NE1000-Standard: description wanted!
Summary: How to program at low-level (driver-level) with NE1000-ethernetcards.
Keywords: NE1000, NOVELL, D-LINK, ETHERNET, PROTOCOL
Date: 8 Apr 92 17:00:42 GMT
Organization: University of Dortmund, Germany

Hello wizards!

After a long period of searching for a NE1000-description without ANY success
(I phoned NOVELL and other manufacturers and distributors) I decided to give
it a try on the news system. What I need in detail is:

Which commands does a "standard" NE1000-compatible ethernet-card (e.g. D-link
model DE-100) understand? 
Programming in machine language, which codes do I have to use to tell
the card which IP-adress it is going to have and which codes tell the card
to read one "packet" of data from the net?
A full table of commands either on machine-level or at the driver-label
(this means one level upwards) would be even more useful....

All of the officials I have spoken to seemed to be worried about a potential
concurrent programmer who could program better software than they did.........
Newsgroups: comp.protocols.tcp-ip