|
|
ARCHIVE: TCP-IP Distribution List - Archives (1992)
DOCUMENT: TCP-IP Distribution List for April 1992 (280 messages, 137950 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1992/04.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Apr 1992 22:02:46 GMT From: emv@msen.com (Edward Vielmetti) To: alt.wais,alt.cd-rom,comp.ai,comp.multimedia,comp.protocols.tcp-ip Subject: current.cites - Library Technology Watch newsletter
This newsletter is now available for anonymous FTP (from a.cni.org)
and in a WAIS server noted below. Current issues are sent to the
PACS-L mailing list, which is available on finer news sites as
"bit.listserv.pacs-l".
(:source
:version 3
:database-name "current.cites"
:ip-name "wais.cic.net"
:tcp-port 210
:cost 0.00
:cost-unit :free
:maintainer "emv@wais.cic.net"
:description "
Date: Wed, 1 Apr 92 11:04:04 PST
From: rtennant@library.Berkeley.EDU (Roy Tennant)
Subject: Current Cites "charter"
* * * * CURRENT CITES * * * *
Current Cites is a monthly publication of the Library Technology Watch
Program -- The Library, University of California at Berkeley.
Over 30 journals in librarianship and computer technology are scanned
for selected articles on electronic publishing, optical disk
technologies, computer networks and networking, information transfer,
expert systems and artificial intelligence, and hypermedia and
multimedia. Brief annotations accompany most of the citations.
The Library Technology Watch Program was created to increase the
technical knowledge of Library staff, optimize staff time devoted to
learning about technical issues, and monitor the changing electronic
environment as it applies to library systems and services. Participants
include Teri Rinne, David Robison, Vivienne Roumani, Lisa Rowlison,
Mark Takaro, and Roy Tennant, all of the University of California,
Berkeley Library.
The Editor of Current Cites is David F. W. Robison, who can be reached
at drobison@library.berkeley.edu or drobison@ucblibrar.bitnet. If you
would like more information about the Library Technology Watch Program,
contact Roy Tennant, The Library, 130 Doe, University of California,
Berkeley, CA 94720 or rtennant@library.berkeley.edu, or
rtennant@ucblibra.bitnet.
"
)
--
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
MSEN Inc., 628 Brooks, Ann Arbor MI 48103 +1 313 741 1120
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 92 15:03:26 EST From: spe@icf.hrb.com (Steven P. Eberly) To: comp.protocols.tcp-ip,comp.sys.sun.misc,comp.unix.questions Subject: TCP socket questions (SUNOS)
I have a couple socket programming questions (SUNOS 4.1 environment): The BSD "select" and SYS5 "poll" can be setup to return when a socket or TLI endpoint is ready for writing. Does this mean that the TCP send buffer is empty or that at least one byte can be written to it? The number of bytes in the TCP receive buffer can be read using ioctl, can the number of bytes in the TCP send buffer be check? Is there a way to know when all data in the TCP send buffer has been successfully sent, without a user level ack? Is there a method to flush the TCP transmit and receive buffers? It appears as though the TCP keep-alive does not start until after a large period of inactivity. What are the time value(s) for keep-alive, are they configurable on a socket-by-socket or only a system wide basis? What happens if keep-alive fails, ... signal? -- | Steve Eberly --+-- spe@icf.hrb.com | |
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Thu, 2 Apr 1992 16:05:52 GMT From: Edward Vielmetti <emv@msen.com> To: news.announce.newgroups,news.groups,alt.gopher,alt.wais,comp.protocols.tcp-ip,bit.listserv.cwis-l Subject: RFD: comp.infosystems.gopher
This is a request for discussion and a proposal for a new newsgroup,
"comp.infosystems.gopher", to replace the existing group "alt.gopher".
For more information see alt.gopher or look at the distribution on
boombox.micro.umn.edu:/pub/gopher/. There is a demonstration system
which you can connect to by telnetting to
consultant.micro.umn.edu
and logging in as "gopher"; the services there are also available as a
native application for Macs, PCs, NeXT machines, VMS, IBM mainframes,
X Windows, and of course a Unix shell.
Gopher is a distributed information system; menus within a gopher
can be made up of resources on the local system, on other gophers,
or even to other non-gopher systems via gateways. There are front
ends in place for telnet, WAIS, finger, FTP, archie, and other internet
resources. Building your own gopher is as easy as making a few links
to other systems that you like and putting some ordinary text files
out in a public area.
This is *not* a call for votes; Usenet protocol suggests about a month's
worth of discussion to make sure that the name is right and to get
people aware that there's something going on. If you want to discuss
substantive matters the group alt.gopher is ready there to take them.
On the other hand if you want to argue about names, that's what news.groups
is for. (This name was suggested by the reaction to the
"comp.infosystems.wais" vote that's in progress; WAIS and gopher fill
a similar sort of need on the net so it seems reasonable to put them
close together in the hierarchy.) When a real call for votes is
issued, you will know about it.
--
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
MSEN Inc., 628 Brooks, Ann Arbor MI 48103 +1 313 741 1120
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 92 02:49:21 GMT From: Frank@mindlink.bc.ca (Frank I. Reiter) To: comp.protocols.tcp-ip Subject: Telnet option codes
In the process of adding telnet client support to a locally developed application I have com across a few option codes not defined in my telnet.h. Can anyone tell me what option codes 31, 33, 35, and 36 are? Frank. -- ___________________________________________________________________ Frank I. Reiter Internet: Frank@mindlink.bc.ca MIND LINK! Communications Corp. Surrey, British Columbia, Canada
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 92 03:47:08 GMT From: Frank@mindlink.bc.ca (Frank I. Reiter) To: comp.protocols.tcp-ip Subject: Telnet ECHO option
In the course of adding telnet client ability to another application I've discovered that the telnetd at a local IRIX system sends out a DO ECHO request. I can understand that a telnet client would want characters echoed back to it (as indeed mine does), but I cannot udnerstand why a telnetd would want a telnet client to echo back everything it receives. At present we reply WONT ECHO. Can anyone shed any light on this? Frank. -- ___________________________________________________________________ Frank I. Reiter Internet: Frank@mindlink.bc.ca MIND LINK! Communications Corp. Surrey, British Columbia, Canada
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 92 05:08:15 GMT From: mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) To: comp.protocols.tcp-ip, "Frank I. Reiter" <Frank@mindlink.bc.ca> Subject: re: Telnet ECHO option
Indeed. I've been fighting this battle for a long time -- 15 years in fact. It is foolish and ridiculous for Telnet servers to send IAC DO ECHO and for Telnet clients to send IAC WILL ECHO, but both types of software persist. So do individuals who claim this is reasonable behavior.
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 1992 09:27:43 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: Telnet ECHO option
In article <11203@mindlink.bc.ca> Frank@mindlink.bc.ca (Frank I. Reiter) writes:
>In the course of adding telnet client ability to another application I've
>discovered that the telnetd at a local IRIX system sends out a DO ECHO request.
Sounds like the implementor of that telnetd was confused about the meaning
of the Telnet ECHO option. He probably thought he was telling the client
telnet to perform local echoing.
--
Barry Margolin
System Manager, Thinking Machines Corp.
barmar@think.com {uunet,harvard}!think!barmar
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 92 14:03:41 GMT From: johna@mobdig.ncal.mobdig.com (John Antypas) To: comp.protocols.tcp-ip Subject: Service of PSI
Just thought I'd throw this out to the net to get others views on this.
We've been a PSI dialup IP customer for about a year now and on the
whole, been quite pleased with them -- when things work. I'm not
saying PSI is "at fault" directly, but over the last six months, the
point-of-presense we use in San Fransisco has gone down several times and
stayed that way for and hour or more -- in some cases several hours.
Perhaps this is all one can expect from a dialup IP arrangment -- the
real solution may be a leased circuit but I'm short about $10K a year
right now.
Does anyone else in Netland, a) have these problems with PSI b)
have similar POP problems with the other two dialup IP providers.
Perhaps it's time to switch?
As I said, perhaps this the best we can get in this arrangment, but
at points, we're simply down without a cost-effective backup and I
wonder if other providers have solutions.
--
John Antypas / Software Engineer
MobileDigital Corp -- Wireless Network Wizards (this one in training...)
90s: johna@mobdig.com 80s: ...!{uupsi, rtech}!mobdig!johna
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Fri, 3 Apr 1992 18:27:43 GMT From: jik@athena.mit.edu (Jonathan I. Kamens) To: comp.protocols.tcp-ip Subject: Re: TCP socket questions (SUNOS)
I don't know 100% if my answers are correct for SunOS TLI; I am fairly certain
they are correct for more "traditional" (i.e. BSD :-) socket implementations.
In article <1992Apr2.150326.19039@icf.hrb.com>, spe@icf.hrb.com (Steven P. Eberly) writes:
|> The BSD "select" and SYS5 "poll" can be setup to return when a socket or
|> TLI endpoint is ready for writing. Does this mean that the TCP send buffer
|> is empty or that at least one byte can be written to it?
It means that there is room for at least one byte in the kernel buffer.
|> The number of bytes in the TCP receive buffer can be read using ioctl, can
|> the number of bytes in the TCP send buffer be check? Is there a way to
|> know when all data in the TCP send buffer has been successfully sent,
|> without a user level ack?
No.
|> Is there a method to flush the TCP transmit and receive buffers?
Not short of doing a shutdown() or close() on the socket, no.
--
Jonathan Kamens jik@MIT.Edu
MIT Information Systems/Athena Moderator, news.answers
(Send correspondence related to the news.answers newsgroup
{and ONLY correspondence related to the newsgroup}
to news-answers-request@MIT.Edu.)
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 92 18:57:03 GMT From: mjs@s4mjs.UUCP (M.J.Shannon) To: comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.sysv386 Subject: Commercial Internet connections
A client of mine wants/needs to get Internet connected. What I need to know is who all offers such a commercial connection to Internet. I've heard that UUNET sells connections to Alter-Net, and I believe PSI has some similar capability. Who else is in the game? I'd appreciate company names and phone numbers; extra points for a technical contact's name. Please email as well as post, and when I've collected the info from the vendors, I'll summarize to comp.dcom.lans (unless someone tells me of a better newsgroup I missed). Thanks much, -- --------------+ <Delapsus Resurgam: When I fall I shall rise. --(10cc)> Marty Shannon | My opinions are just that. You may share them. No one mjs@s4mjs.uucp| speaks for me, and I speak only for myself -- no matter --------------+ where I post from. Get it? Post no flames.
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 92 21:44:10 GMT From: ian@unipalm.co.uk (Ian Phillipps) To: comp.protocols.tcp-ip Subject: Telnet option codes - a list
Frank@mindlink.bc.ca (Frank I. Reiter) writes: >Can anyone tell me what option codes 31, 33, 35, and 36 are? A while ago, I needed similar info, so I mailed Jon Postel. Here, for the benefit of the Usenet, is the list he sent back. RFC 1060 was current then, and still is, so there isn't a public more "official" list than this one. Date: Tue, 20 Aug 91 13:25:34 PDT From: postel@isi.edu Message-Id: <9108202025.AA07975@bel.isi.edu> To: ian@unipalm.co.uk Subject: Re: Telnet option numbers Ian: Hi. The next edition of Assigned Numbers will include the telnet options. --jon. Options Name References ------- ----------------------- ---------- 0 Binary Transmission [110,JBP] 1 Echo [111,JBP] 2 Reconnection [42,JBP] 3 Suppress Go Ahead [114,JBP] 4 Approx Message Size Negotiation [133,JBP] 5 Status [113,JBP] 6 Timing Mark [115,JBP] 7 Remote Controlled Trans and Echo [107,JBP] 8 Output Line Width [40,JBP] 9 Output Page Size [41,JBP] 10 Output Carriage-Return Disposition [28,JBP] 11 Output Horizontal Tab Stops [32,JBP] 12 Output Horizontal Tab Disposition [31,JBP] 13 Output Formfeed Disposition [29,JBP] 14 Output Vertical Tabstops [34,JBP] 15 Output Vertical Tab Disposition [33,JBP] 16 Output Linefeed Disposition [30,JBP] 17 Extended ASCII [136,JBP] 18 Logout [25,MRC] 19 Byte Macro [35,JBP] 20 Data Entry Terminal [145,38,JBP] 22 SUPDUP [26,27,MRC] 22 SUPDUP Output [51,MRC] 23 Send Location [68,EAK1] 24 Terminal Type [128,MS56] 25 End of Record [103,JBP] 26 TACACS User Identification [1,BA4] 27 Output Marking [125,SXS] 28 Terminal Location Number [84,RN6] 29 Telnet 3270 Regime [116,JXR] 30 X.3 PAD [70,SL70] 31 Negotiate About Window Size [139,DW183] 32 Terminal Speed [57,CLH3] 33 Remote Flow Control [58,CLH3] 34 Linemode [9,DB14] 35 X Display Location [75,GM23] 36 Environment Option [RFC-XXXX,DB14] 37 Authentication Option [RFC-XXXX,DB14] 38 Encryption Option [RFC-XXXX,DB14] 255 Extended-Options-List [109,JBP] -- Ian Phillipps, Unipalm Ltd, 216 Science Park, Phone +44 223 420002 Milton Road, Cambridge, CB4 4WA, England. Phax +44 223 426868 Vapourware is the programming industry's answer to solid-state computers.
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 92 21:47:21 GMT From: srikanth@cs.tulane.edu (R. Srikanth) To: comp.protocols.tcp-ip Subject: finger protocol
Hi, I am looking for some information on how the finger protocol works. Does anyone have any information on the finger protocol or know where one can get this information ? Thanks in advance. Srikanth -- srikanth@rex.cs.tulane.edu Dept of Computer Science, Tulane University, New Orleans, La - 70118 GOOOOOOO SAINTS !!!!!!
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 92 23:05:05 GMT From: clunie@bloch.ohsu.edu (David Clunie) To: comp.protocols.tcp-ip Subject: Firewall machines - documents ?
I remember someone mentioned recently a document describing how to setup Internet firewall machines, and I though it was available on cert, but I can't find it. Does anyone have this or know where to get it ? Thanks ... david (clunie@ohsu.edu)
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 1992 23:58:34 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: finger protocol
In article <1992Apr3.214721.29917@cs.tulane.edu> srikanth@cs.tulane.edu (R. Srikanth) writes:
>I am looking for some information on how the finger protocol works.
See RFC 1196.
--
Barry Margolin
System Manager, Thinking Machines Corp.
barmar@think.com {uunet,harvard}!think!barmar
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 92 00:57:24 GMT From: xwu@ACSC.COM (Xinhua Wu) To: comp.protocols.tcp-ip Subject: client fails if runs on server machine
What might be the reasons for a client-server application working when the client and the server running on different machines but not working when they are running on a same machine? We are using IBM RS/6000. Communication between the client and the server is handled by using TCP sockets. The client side is implemented as a kernel extension. The same problem had happened a few times when we were using AIX 3.1 and we didn't find the reason. Now we are working on a newer version of the application for AIX 3.2. Everything seemed fine until we ran the application on a single machine where it has never worked. One symptom for the problem is: A call to recv() on the client side received nothing due to error "no body" (i.e., the packet contains no data part: m_type != MT_DATA). But when the client and the server are running on different machines, that's not the case (i.e., m_type == MT_DATA). Before the above recv() failure, we have fp_poll() on sockets. Another symptom is: During the whole delay period (fp_poll delays some time and we try fp_poll several times when needed) the machine hangs. This symptom is not present if we use two machines (first fp_poll() succeeds). Any help will be very much appreciated. Thanks in advance, -- Xinhua Wu xwu@acsc.com
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Sat, 4 Apr 92 06:50:35 GMT From: hgv@herring.network.com (Harry G. Varnis) To: comp.protocols.tcp-ip Subject: Sockets vs TLI in Future SunOS (Was: Re: TCP socket questions (SUNOS)
In SunOS 4.1.x TLI is implemented as a library while socket functions are system calls. Not too long ago there was some discussion about this positioning being reversed in the future. Would someone summarize the discussion, please? I didn't care about TLI much at the time, but...things change. Has anyone noticed problems with the TLI library? In particular with data loss if one's "sends" are larger than 4K? Thanks, -- Harry Varnis <hgv@anubis.network.com> +1 612 493 1042
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 92 09:42:24 GMT From: torkel@bibsyst.no (Torkel Hasle) To: comp.protocols.tcp-ip,comp.unix.programmer,comp.unix.sysv386 Subject: Re: Problem with System V IP Sockets
In article <9527@pluto.dss.com> cat@pluto.dss.com (Iain Wacey) writes: > > I am writing a program under System V that takes in data and sends it >across to a terminal server using IP sockets. The problem is that if any >data remains to be sent to the server when I close the socket the data >is droped instead of delivered. You have to set the SO_LINGER flag with function call setsockopt(). The value of l_linger in struct linger determines the time the socket will wait. According to W. Richard Stevens (Unix Network Programming), the value og l_linger does not matter, as long as it is nonzero. +----------------------------------------------------------------------+ ! Torkel Hasle, Bibliotek-Systemer A/S, N-3250 Larvik, Norway ! ! tel: +47 34 82 202 fax: +47 34 85 185 uucp: torkel@bibsyst.no ! +----------------------------------------------------------------------+
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Saturday, 4 Apr 1992 14:56:46 CDT From: <K3006E7@ALIJKU11.BITNET> To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Question: installing NCSA
I wish to use the NCSA v2.3.03 FTP and TELNET package on our
IBM PC. I am having very much trouble getting it to work.
Right now, our hardware is:
"4-Dimension Quick BROM Version 6.0
Ether Board 16 V1.31 200-5009A"
which is hooked up to the ethernet.
In the config.sys, IPCUST.SYS and IFCUST.SYS are loaded. In
the autoexec.bat, the commands:
NE2000.com 0x60 0x3 0x300
ETHDRV
I think these are old "FTP Software" that was put into our
hard-disk when the local administrator hooked up our pc to
the network. Unfortunatly, he left absolutely no documentation
behind.
In anycase, we use the pc mostly to log onto to the local system
running VM/XA SP release 2.1. But the trouble starts when I try
to log directly to other machines with the old "FTP Software" TN
command, such as archie at Rutgers or McGill, which do not run
VM-style operating systems.
I therefore would like to install NCSA from scratch, and learn to
configure it correctly. If anyone could point me in the right
direction as to literature, or installation software, I would
greatly appreciate it| I need information such as:
what is this IPCUST.SYS and IFCUST.SYS, is this
necessary for the NCSA telnet?
which drivers should I use for our Ether card as
stated above? and what are the options I should
try (interrupt levels, etc.)?
Is there any software out there that does this
automatically in regards to installation?
etc, etc
Any and all information would be greatly appreciated. I prefer
personal e-mail since I suspect these questions are probably
irritatingly juvenile for most readers. But if you feel it is
of general interest, I will look forward to your followup posts.
Thank you.
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Sat, 4 Apr 1992 17:14:16 GMT From: scoggin@daisy.udel.edu (John K Scoggin) To: comp.protocols.tcp-ip Subject: Re: Service of PSI
In article <1992Apr03.140341.20828@mobdig.ncal.mobdig.com> johna@mobdig.ncal.mobdig.com (John Antypas) writes:
>Just thought I'd throw this out to the net to get others views on this.
>
>We've been a PSI dialup IP customer for about a year now and on the
>whole, been quite pleased with them -- when things work. I'm not
>saying PSI is "at fault" directly, but over the last six months, the
>point-of-presense we use in San Fransisco has gone down several times and
>stayed that way for and hour or more -- in some cases several hours.
>
>Perhaps this is all one can expect from a dialup IP arrangment -- the
>real solution may be a leased circuit but I'm short about $10K a year
>right now.
>
>Does anyone else in Netland, a) have these problems with PSI b)
>have similar POP problems with the other two dialup IP providers.
>Perhaps it's time to switch?
>
a. Yes, we have had two distinct problems. The NetBlazer in
Reston VA POP hanging on several occasions and loss of
the T-1 linking Reston to the rest of the Internet. Could
it be that PSI doesn't build any redundancy into their
net? Can't tell - they don't have a topology map in any
of the normal places.
b. Can't comment on this. PSI is our first Internet service
provider.
>As I said, perhaps this the best we can get in this arrangment, but
>at points, we're simply down without a cost-effective backup and I
>wonder if other providers have solutions.
>
>
I'm not really complaining. A certain amount of pain is probably
due to the dialup nature of the service and the difficulties that
it presents to the carrier in terms of monitoring.
What HAS annoyed me was PSI knocking links down for maintenance
without notification. It happened a few weeks ago in the middle of
a big FTP - I was slightly PO'd and let them know it!
All in all, though, I find their service to be acceptable. Their
tech support has been nothing short of outstanding (thanks, Mark
Fedor!).
>--
>John Antypas / Software Engineer
>MobileDigital Corp -- Wireless Network Wizards (this one in training...)
>90s: johna@mobdig.com 80s: ...!{uupsi, rtech}!mobdig!johna
- John
-------------------------------------------------------------------------
John K. Scoggin, Jr. Email: scoggin@udel.edu
Supervisor, Network Operations scoggin@delmarva.com
Delmarva Power & Light Co. Voice: 302-451-5200
P.O. Box 6066 Fax: 302-451-5321
Newark, DE 19714-6066
-------------------------------------------------------------------------
Your milage may vary. Void where prohibited by law (or common sense).
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 92 19:16:01 GMT From: mikec@cardinals (Mike Catalanotti) To: comp.protocols.tcp-ip, srikanth@cs.tulane.edu (R. Srikanth) Subject: Re: finger protocol
Well, The FINGER protocol is really no different than any other of the protocols lying on the TCP/IP stack. It's at layer 5 (Session) of the OSI model. I don't know what info you want in paricular but I'll try: I just recently wrote a finger daemon for OS/2, and in and of itself, the code is no longer than a page (using Sockets libraries). Basically it is a service (at the UDP layer) that sits and listens for incoming STREAM requests via port 79. Upon a finger request, it just blasts out any text back to the asker. It's no different that, say, SMTP, FTP, TELNET, etc., except that it listens for requests on s different port than those other services. If you need any other info, detailed or not, write me back directly if you can and I'll try to help out. Mike Catalanotti Systems Software Engineer Cabletron Systems, Inc. mikec@mikec1.ctron.com -or- mikec@ctron.com
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 92 19:21:23 GMT From: ewilts@mr.gov.bc.ca (Ed Wilts) To: comp.protocols.tcp-ip Subject: Re: Firewall machines - documents ?
In article <1992Apr3.230505.6667@ohsu.edu>, clunie@bloch.ohsu.edu (David Clunie) writes: > > I remember someone mentioned recently a document describing how > to setup Internet firewall machines, and I though it was available > on cert, but I can't find it. > > Does anyone have this or know where to get it ? > > Thanks ... david (clunie@ohsu.edu) ftp to research.att.com. Get file /dist/Secure_Internet_Gateway.ps -- Ed Wilts, BC Systems Corp., 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8 EWilts@MR.Gov.BC.CA | Ed.Wilts@BCSystems.Gov.BC.CA | (604) 389-3430
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 92 06:45:23 GMT From: mju@mudos.ann-arbor.mi.us (Marc Unangst) To: comp.protocols.tcp-ip,comp.unix.sysv386 Subject: Tunnel driver or PPP for SysVr4/386?
I'm trying to get PPP running on my SysVr4/386 (ESIX) system. Before I go ahead and try to port the SunOS PPP implementation, has anyone done this before? Is there a free PPP out there somewhere that compiles on SysVr4/386? Failing that, I anticipate the most difficult part of SunOS PPP to port will be the tunnel driver, simply because the device-driver semantics are likely to be very different. So, has anyone implemented an IP tunnel driver on SysVr4? -- Marc Unangst | You know that funny-looking bump on your mju@mudos.ann-arbor.mi.us | leg? It's your kneecap. Leave it alone. <backbone>!sharkey!mudos!mju|
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 92 15:07:18 From: vixie@pa.dec.com (Paul A Vixie) To: comp.unix.ultrix,comp.unix.bsd,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: GATEKEEPER.DEC.COM'S address is wrong in the root servers
the NIC made a boo-boo in the root zone glue, mixing up the address records of GATEKEEPER.DEC.COM and GATEKEEPER.CALERA.COM. one of the three DEC.COM servers (DECUAC.DEC.COM) has become confused about GATEKEEPER.DEC.COM's address, but the other two (GATEKEEPER.DEC.COM and CRL.DEC.COM) are OK. chances are very good that if you try to ftp to GATEKEEPER.DEC.COM, you will find yourself connected to a SunOS 4.1 machine whose name also happens to be "gatekeeper" but which does not have anonymous FTP. if this happens, you will have to exit from ftp and retry with "ftp 16.1.0.2". 16.1.0.2 is the right address for GATEKEEPER.DEC.COM. we regret the inconvenience. we're doing everything we can, which is nothing. -- Paul Vixie, DEC Network Systems Lab Palo Alto, California, USA "Ready, Fire, Aim" <vixie@pa.dec.com> decwrl!vixie <paul@vix.com> vixie!paul alt.pink.bunny.boom.boom.boom moderator
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Sun, 5 Apr 1992 12:14:58 GMT From: scoggin@daisy.udel.edu (John K Scoggin) To: comp.protocols.tcp-ip Subject: Re: Firewall machines - documents ?
In article <1992Apr4.112123.384@mr.gov.bc.ca> ewilts@mr.gov.bc.ca (Ed Wilts) writes: >In article <1992Apr3.230505.6667@ohsu.edu>, clunie@bloch.ohsu.edu (David Clunie) writes: >> >> I remember someone mentioned recently a document describing how >> to setup Internet firewall machines, and I though it was available >> on cert, but I can't find it. >> >> Does anyone have this or know where to get it ? >> >> Thanks ... david (clunie@ohsu.edu) > >ftp to research.att.com. Get file /dist/Secure_Internet_Gateway.ps > >-- >Ed Wilts, BC Systems Corp., 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8 >EWilts@MR.Gov.BC.CA | Ed.Wilts@BCSystems.Gov.BC.CA | (604) 389-3430 Only one problem - that paper describes an approach which requires some pretty specialized resources (like AT&T DataKit, for example). For a little more practical approach, see "Practical Unix Security" by Simson Garfinkel and Gene Spafford (of Purdue fame). The publisher is O'Reilly & Associates, 800-338-6887 (707-829-0515 for you folks offshore). The ISBN is 0-937175-72-2. Chapter 14 is devoted to the care and feeding of firewall machines. Highly recommended. There are also several commercially available systems available. Sun's consulting division markets "IGATEWAY" which provides proxy Telnet and FTP. I believe that Advanced Networks & Services (ANS), the NSFnet folks, market one called ANSgate. Finally, Raptor Systems markets a more complete package, including both firewall and intruder detection systems. Hope this helps. - John ------------------------------------------------------------------------- John K. Scoggin, Jr. Email: scoggin@udel.edu Supervisor, Network Operations scoggin@delmarva.com Delmarva Power & Light Co. Voice: 302-451-5200 P.O. Box 6066 Fax: 302-451-5321 Newark, DE 19714-6066 ------------------------------------------------------------------------- Your milage may vary. Void where prohibited by law (or common sense).
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 92 14:55:45 GMT From: iglesias@hydra.acs.uci.edu (Mike Iglesias) To: vmsnet.networks.tcp-ip.misc,comp.protocols.tcp-ip Subject: Re: BSD TALK protocol documented?
In article <1992Apr2.134420.1@indyvax.iupui.edu> harvey@indyvax.iupui.edu writes: >Is there a formal specification for the BSD TALK protocol available anywhere? >The new one, not the old one (i.e., the one that works between big-endian and >little-endian systems). I need to write a server and client to run under a >non-Unix operating system. There doesn't appear to be an RFC on the talk protocol, but you could pick up a copy of the sources from one of the BSD source archives (gatekeeper.dec.com or uunet.uu.net) and use the source as your guide. Mike Iglesias Internet: iglesias@draco.acs.uci.edu University of California, Irvine BITNET: iglesias@uci Office of Academic Computing uucp: ...!ucbvax!ucivax!iglesias Distributed Computing Support phone: (714) 856-6926
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 92 17:34:16 GMT From: hgschulz@gaia.cs.umass.edu (Henning Schulzrinne) To: comp.protocols.tcp-ip Subject: Re: BSD TALK protocol documented?
As part of the networking class I'm teaching right now, I have students program the talk part (using the standard talkd server). It seems to serve as a good example since it uses both datagram and stream services, name lookup, features issues of host/network data representation, client/server architecture, etc. As part as the project description, I have assembled a reasonably detailed "protocol" description, deduced from the Berkeley sources and some experiments. Interested parties are welcome to request the project writeup by e-mail. --- Henning Schulzrinne (hgschulz@cs.umass.edu) Dept. of CS and Dept. of ECE; Univ. of Massachusetts at Amherst Amherst, MA 01003 - USA === phone: +1 (413) 545-3179 (EST); FAX: (413) 545-1249
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 92 01:37:18 GMT From: subhodip@paul.rutgers.edu (SUBHODIP GHOSH) To: comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.nfs Subject: TROLL-NETWORK SIMULATOR/DATAGRAM FORWARDER
I am looking for the utility "troll" - network simulator/datagram. It think it comes with the unix software for SUN machines.I need to do some performmence benchmark of the client/server protocols using UDP. Some more details about the utility: Troll is an application designed to simulate the various quirks and vagaries of a network envirnment.The troll forwards UDP datagrams between processes, possibly dropping, delaying,garbling,and/or duplicating those datagrams. Does anyone know from where I can get the relevant files. OR is there a ftp site where I can get the files, OR is there any public domain copy of this software available.. Send me e-mail . Thanks.
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 92 02:52:58 GMT From: ittai@news.ans.net (Ittai Hershman) To: comp.protocols.tcp-ip Subject: Re: Firewall machines - documents ?
>I believe that Advanced Networks & Services (ANS), the NSFnet folks, market
>one called ANSgate.
It is called "Interlock". We will be demonstrating Interlock in the
ANS booth at Interop East next month (it was first announced at Interop '91).
-Ittai
PS: Please don't send me mail for more information on Interlock:
please use our "info@ans.net" address instead. Thanks...
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Mon, 6 Apr 1992 12:40:15 GMT From: a722756@pan.mc.ti.com (W. D. Rolph) To: comp.protocols.tcp-ip Subject: Re: Wanted: TCP/IP BSD-sockets for Windows 3.x
In article <477@kommu.UUCP>, anderl@kommu.UUCP (Horst Anderl) writes: |> Where can I get a TCP/IP BSD-socket library for MS-Windows 3.x? |> HP in thier ARPA services 2.1 for the pc has available sockets for use under Windows 3.0. Unfortunately they do not have a part number, and can not sell it to you (or couldn't to me in any event). ARPA services 2.1 will be the basis for the upcoming release of Pathworks TCP/IP from DEc, and is reuputed to include the windows based socket libraries and program development software. A windows based socket library is also reputedly available from Frontier Technologies for their SUPT TCP product. -- Regards. Don Rolph a722756@pan.mc.ti.com WD3 MS10-13 (508)-699-1263
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Mon, 6 Apr 1992 19:51:29 GMT From: garnett@news.Colorado.EDU (Santiago de la Paz) To: comp.protocols.tcp-ip Subject: Prepending custom IP headers
I need to generate IP packets which have a source address that is not at all related to the machine which is generating them. This would be a simple task if it were not for the fact that the kernel tacks an IP header auto- matically to my data. I seem to remember several threads on this topic, and that specifying IPPROTO_RAW for the protocol of a SOCK_RAW socket was one way of doing it with certain kernels patched for traceroute. The kernel I wish to do this under is a SunOS4.1.1 kernel, which already supports the use of traceroute, so can I make my own headers in this situation? If so, how? Does the kernel examine the data in a send() to ensure that a valid IP header is present, and prepend its own header if not? Many thanks for any information... ~james James Garnett garnett@boulder.Colorado.EDU UnixOps/Distributed Computing ...!ncar!boulder!garnett University of Colorado at Boulder +1 303 492 0264
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 92 21:10:33 GMT From: psirakis@yoko.rutgers.edu (Psirakis Alexander) To: comp.protocols.tcp-ip Subject: Question on bind-socket
I am currently working on a term project concerning network programming.
I want to bind a second socket descriptor (sockt2) to a port that is
already assigned to another socket (sockt).
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.
But when I try to bind the same port address to the second socket descriptor
the bind system call fails ("address already in use").
The critical code segment is the following:
sockt = socket(AF_INET, SOCK_DGRAM, 0);
bind(sockt, &addr, sizeof(addr), 0);
length = sizeof(addr);
getsockname(sockt, &addr, &length);
optval=1;
temp=sizeof(optval);
setsockopt(sockt,SOL_SOCKET,SO_REUSEADDR,(char *)&optval, sizeof(optval);
optval=0;
getsockopt(sockt,SOL_SOCKET,SO_REUSEADDR,(char *)&optval, (int *)&temp);
sockt2 = socket(AF_INET, SOCK_DGRAM, 0);
if (bind(sockt2, &addr, sizeof(addr)) != 0)
^ perror("Binding local socket");
|
here is the fail!!!
I appreciate any kind of help
Thank you
Alexander Psirakis
e-mail: psirakis@yoko.rutgers.edu
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Mon, 6 Apr 1992 21:15:24 GMT From: chris@gargoyle.uchicago.edu (Chris Johnston) To: comp.protocols.tcp-ip Subject: tcp printer servers
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
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 92 21:53:35 GMT From: thorinn@diku.dk (Lars Henrik Mathiesen) To: comp.protocols.tcp-ip Subject: Re: Telnet ECHO option
Frank@mindlink.bc.ca (Frank I. Reiter) writes:
>In the course of adding telnet client ability to another application
>I've discovered that the telnetd at a local IRIX system sends out a
>DO ECHO request.
>I can understand that a telnet client would want characters echoed
>back to it (as indeed mine does), but I cannot udnerstand why a
>telnetd would want a telnet client to echo back everything it
>receives. At present we reply WONT ECHO.
The 4.3BSD telnetd (from which the IRIX version probably derives) does
not want the echoes. The reason for the WILL ECHO is given in this
comment in the source:
/*
* Is the client side a 4.2 (NOT 4.3) system? We need to know this
* because 4.2 clients are unable to deal with TCP urgent data.
*
* To find out, we send out a "DO ECHO". If the remote system
* answers "WILL ECHO" it is probably a 4.2 client, and we note
* that fact ("WILL ECHO" ==> that the client will echo what
* WE, the server, sends it; it does NOT mean that the client will
* echo the terminal input).
*/
This server first sends WILL ECHO and WILL SGA, and then the DO ECHO.
When talking to one flavor of sane clients, the 4.3BSD one among them,
it gets a WONT ECHO back, and everything is fine.
The 4.2BSD client is (was?) broken, however, and takes DO ECHO as a
request to start echoing terminal input itself --- which it is willing
to do. The command is really a request to echo the server output back,
and there are client programs that are willing to do that, as well;
after all, TELNET is supposed to be a symmetrical protocol. To handle
both cases, if the 4.3BSD server gets a WILL ECHO in response, it
sends out _both_ WILL ECHO and DONT ECHO --- the former seems to be
needed to get a 4.2BSD client back in the correct state, and the
latter will prevent the other clients from echoing the server output
back.
In my opinion, this way of checking for client 4.2-ness is vastly
bogus, even though it does not involve technically incorrect TELNET
behavior. It will identify some reasonable TELNET clients as the
deeply broken 4.2BSD one, while it doesn't detect the similar deep
brokenness of some terminal concentrators which do answer DONT ECHO
but still don't understand about output flushing.
But to address your problem: DONT ECHO is the right thing to answer to
a 4.3BSD-derived telnetd, if you want it to use TELNET SYNCH.
Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 92 22:51:00 GMT From: thomson@hub.toronto.edu (Brian Thomson) To: comp.protocols.tcp-ip Subject: Re: Prepending custom IP headers
In article <1992Apr6.195129.22522@colorado.edu> garnett@news.Colorado.EDU (Santiago de la Paz) writes: > >I seem to remember several threads on this topic, and that specifying >IPPROTO_RAW for the protocol of a SOCK_RAW socket was one way of doing it >with certain kernels patched for traceroute. The kernel I wish to do >this under is a SunOS4.1.1 kernel, which already supports the use of >traceroute, so can I make my own headers in this situation? Looking at our 4.1, it appears that IPPROTO_RAW overwrites the supplied source IP address with the socket's address, if it has been bound, or (eventually) the outgoing interface address if it hasn't. In either case, the result is a valid address for the sending host. To do what you want to do, you need direct access to the interface output routines, and I believe NIT is the only way to get that. -- Brian Thomson, CSRI Univ. of Toronto utcsri!uthub!thomson, thomson@hub.toronto.edu
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 92 23:07:28 GMT From: thomson@hub.toronto.edu (Brian Thomson) To: comp.protocols.tcp-ip Subject: Re: Question on bind-socket
In article <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).
>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.
>But when I try to bind the same port address to the second socket descriptor
>the bind system call fails ("address already in use").
SO_REUSEADDR does not mean what you think it means.
Don't let that worry you, though, few people do know what it is for.
Basically, SO_REUSEADDR lets you have two sockets with *similar*
local & foreign address bindings, but nothing will allow you to have
two *identically* bound sockets, and that is what you are trying to do.
--
Brian Thomson, CSRI Univ. of Toronto
utcsri!uthub!thomson, thomson@hub.toronto.edu
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 7 Apr 92 00:21:46 GMT From: Frank@mindlink.bc.ca (Frank I. Reiter) To: comp.protocols.tcp-ip Subject: WHOIS at nic.dn.mil
I've been playing around with whois and I wonder if some netland wizard could explain something to me: When I do a lookup on MIT.EDU (the example given in the documentation I am reading) there is all sorts of information, but when I do a lookup on ubc.ca or sfu.ca, two local universities, there is no match. Why would that be? Frank. -- ___________________________________________________________________ Frank I. Reiter Internet: Frank@mindlink.bc.ca MIND LINK! Communications Corp. Surrey, British Columbia, Canada
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Tue, 07 Apr 92 01:14:18 GMT From: sss@netcom.com (Small Systems Solutions) To: comp.protocols.tcp-ip Subject: Re: WHOIS at nic.dn.mil
In article <11285@mindlink.bc.ca> Frank@mindlink.bc.ca (Frank I. Reiter) writes: >I've been playing around with whois and I wonder if some netland wizard could >explain something to me: > >When I do a lookup on MIT.EDU (the example given in the documentation I am >reading) there is all sorts of information, but when I do a lookup on ubc.ca or >sfu.ca, two local universities, there is no match. What are you looking for? The University of California at Berkeley is BERKELEY.EDU and as for 'sfu', I have no idea what you mean. San Francisco State University? The University of California at San Francisco? Remember the expression "Garbage in, garbage out" ??? -- Small Systems Solutions 1563 Solano Avenue, Suite 123 sss@netcom.com Berkeley, CA 94707-2116 The above-expressed opinions aren't necessarily
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 7 Apr 92 02:05:40 GMT From: Frank@mindlink.bc.ca (Frank I. Reiter) To: comp.protocols.tcp-ip Subject: Re: WHOIS at nic.dn.mil
> Small Systems Solution writes: > > What are you looking for? The University of California at Berkeley is > > BERKELEY.EDU > > and as for 'sfu', I have no idea what you mean. San Francisco State > University? The University of California at San Francisco? > > Remember the expression "Garbage in, garbage out" ??? Yes, and I also know that .ca means Canada. Apparently you are thinking of California. UBC is the University of British Columbia, and SFU is Simon Fraser University. Data in, garbage out. Frank. -- ___________________________________________________________________ Frank I. Reiter Internet: Frank@mindlink.bc.ca MIND LINK! Communications Corp. Surrey, British Columbia, Canada
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: 7 Apr 92 03:26:25 GMT From: jjm13@po.cwru.edu (Jeff Murphy) To: comp.protocols.tcp-ip Subject: Re: WHOIS at nic.dn.mil
In article <11286@mindlink.bc.ca> Frank@mindlink.bc.ca (Frank I. Reiter) writes: >> Small Systems Solution writes: >> >> What are you looking for? The University of California at Berkeley is >> >> BERKELEY.EDU >> >> and as for 'sfu', I have no idea what you mean. San Francisco State >> University? The University of California at San Francisco? >> >> Remember the expression "Garbage in, garbage out" ??? >Yes, and I also know that .ca means Canada. Apparently you are thinking of >California. UBC is the University of British Columbia, and SFU is Simon Fraser >University. >Data in, garbage out. >Frank. Try it *without* the .CA on the end. Those sites are listed as UBC and SFU in the nic database, *not* as UBC.CA and SFU.CA. A little garbage got in there somewhere... Jeff
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Apr 1992 07:17:30 GMT From: smd@uunet.ca (Sean Doran) To: comp.protocols.tcp-ip Subject: Re: WHOIS at nic.dn.mil
jjm13@po.cwru.edu (Jeff Murphy) writes: >Try it *without* the .CA on the end. Those sites are listed as UBC and SFU >in the nic database, *not* as UBC.CA and SFU.CA. Close, but this is not quite what was being looked for. The records that one can get with "whois ubc" or "whois sfu" are NET ones, not DOM ones, which is what was being searched for. The NET records will only tell you about 137.82.0.0 (NET-UBC) and 142.58.0.0 (NET-SFU), and not about the domains ubc.ca or sfu.ca. The NIC does not list sites under CA-DOM in the whois database, but (as with all valid top-level-domains) lists a DOM record for CA. Authoritative information about any registered domain in .ca can be found for anonymous ftp at cs.ubc.ca:/ca-domain, relay.cdnnet.ca:/ca-domain, clouso.crim.ca:/CAnet/ca-domain, and ftp.cs.utoronto.ca (ftp.cs.toronto.edu) in /ca-domain. We also mirror this information, and make it available at ftp.uunet.ca:/ca-domain. Sean.
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 7 Apr 1992 20:47:13 -0700 From: vlachopo@nunki.usc.edu (Panagiotis Vlachopoulos) To: comp.protocols.tcp-ip Subject: SRP - CRC
Hi Netters, I am searching for two things: (1) A simulation of the Selective Repeat Protocol written in ANY computer language. It will be used to calculate and plot the efficiency of the protocol vs. buffer size. (I know it's in Tanenbaum, but I'd rather have it in anything else than Pascal). (2) A piece of code that calculates CRC's for a given generator. As I'm not reading this group I would like to have any responses sent to panosv@theseas.ntua.gr Thanx in advance :-)
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 7 Apr 92 09:26:12 GMT From: liam@dcs.qmw.ac.uk (William Roberts) To: comp.protocols.tcp-ip Subject: Re: Question on bind-socket
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
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 7 Apr 92 10:35:21 GMT From: ian@spider.co.uk (Ian Heavens) To: comp.protocols.tcp-ip Subject: TCP/IP & UDP/IP throughput on FDDI
Does anyone have figures or references for the performance on appropriate hardware of TCP and UDP over FDDI? thanks ian --- Ian Heavens ian@spider.co.uk Spider Systems Ltd Spider Park, Stanwell Street Edinburgh, EH6 5NG, Scotland +44 31 554 9424 (Ext 4166) --
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Apr 1992 14:18:01 GMT From: srp@modcomp.uucp (Steve Pietrowicz) To: comp.protocols.tcp-ip Subject: Packet sniffer for IBM-PC?
Is there a PD packet sniffer available for the PC? If so, where can I get it? Thanks Steve
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 7 Apr 92 15:39:01 GMT From: gsa@easyaspi.udev.cdc.com (gary s anderson) To: comp.protocols.tcp-ip Subject: Re: Question on bind-socket
In article <Apr.6.17.10.32.1992.6859@yoko.rutgers.edu>, psirakis@yoko.rutgers.edu (Psirakis Alexander) writes:
|>
|>
|> I am currently working on a term project concerning network programming.
|>
|> I want to bind a second socket descriptor (sockt2) to a port that is
|> already assigned to another socket (sockt).
|> 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.
|> But when I try to bind the same port address to the second socket descriptor
|> the bind system call fails ("address already in use").
|>
|> The critical code segment is the following:
|>
|>
|> sockt = socket(AF_INET, SOCK_DGRAM, 0);
|> bind(sockt, &addr, sizeof(addr), 0);
|> length = sizeof(addr);
|> getsockname(sockt, &addr, &length);
|> optval=1;
|> temp=sizeof(optval);
|> setsockopt(sockt,SOL_SOCKET,SO_REUSEADDR,(char *)&optval, sizeof(optval);
|> optval=0;
|> getsockopt(sockt,SOL_SOCKET,SO_REUSEADDR,(char *)&optval, (int *)&temp);
|> sockt2 = socket(AF_INET, SOCK_DGRAM, 0);
|> if (bind(sockt2, &addr, sizeof(addr)) != 0)
|> ^ perror("Binding local socket");
|> |
|> here is the fail!!!
|>
|>
|> I appreciate any kind of help
|> Thank you
|>
|> Alexander Psirakis
|> e-mail: psirakis@yoko.rutgers.edu
|>
|>
In order to make your code work you must select the SO_REUSEADDR on
the second socket (sockt2).
It is not clear what you intend to do with this feature, however, you
need to understand that all incoming data will only go to one of
the sockets (depending on what level of BSD sockets you are running,
either all incoming data will go to the first one defined or all incoming
data will go to the last one defined).
If you had planned to use this for load-leveling across processes then
a fork operation is sufficient to make the socket available to
subordinate processes.
If you are trying to set up an IPC mechanism then you need to bind
unique local ports (or possibly just unique IP addresses, if you are
writing a special multi-homing application) in order to pass information
between the socket pair.
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 7 Apr 92 15:54:42 GMT From: caxbf@pkinbg.UUCP ( Bernd Fohringer ) To: vmsnet.networks.tcp-ip.misc,comp.protocols.tcp-ip Subject: Configuring Wallfleet Routers
Hey, is there anyone in the field who has experiences in configuring a Wallfleet Link Node Communication Server Modell 2002 for advanced IP requirements ??? What we like to do is the same we did with the Cisco Routers before. We want to open certain TCP/UDP ports for IP-broadcast-propagation (e.g. DOMAIN or RWHO). ============================================================================== Bernd Fohringer Phone: 0049 911 526-3735 Philips Kommunikations Industrie Fax: 0049 911 526-2063 Nuernberg, West Germany Mail: caxbf@pki-nbg.philips.de or: caxbf@pkinbg.uucp ============================================================================== -- ============================================================================== Bernd Fohringer Phone: 0049 911 526-3735 Philips Kommunikations Industrie Fax: 0049 911 526-2063 Nuernberg, West Germany Mail: caxbf@pki-nbg.philips.de
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 7 Apr 92 17:05:28 GMT From: 880274d@aucs.acadiau.ca (Ralph I. Doncaster) To: comp.protocols.tcp-ip Subject: Re: Packet sniffer for IBM-PC?
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 |
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 7 Apr 92 19:33:34 GMT From: josevela@mtecv2.mty.itesm.mx (Jose A. Vela A.) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: Where has the Bootp command gone in recent Net.exe
wmah@ersys.edmonton.ab.ca (Wayne Mah) writes:
>Just a note on bootp for KA9Q (or NOS). The version I have allocates
>memory for the bootp via static array is thus is limited to hold only
>12 bootp entries. Hopefully the code has been modified to allocate
>this structures dynamically in a newer version. Otherwise, if you
>have more than 12 bootp clients you are out of luck.
Sorry what version is that you called 'new' ??
Thank you...
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
<_/
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Apr 1992 20:05:41 GMT From: vittallo@ssd.comm.mot.com (John Vittallo) To: comp.protocols.tcp-ip Subject: gethostent() how does it know
I am trying to use gethostent() on both a UNIX R3 V7 and vmexgen target
VME board, but type are not working. For example on the UNIX host which
is named eagle, I currently have a hard-coded line that says
gethostbyname("eagle") but I want to use gethostent(). What will
gethostent use as the host in the hostfile. Should I have an entry
in the /etc/hosts file that says
eagle 1.1.1.4
host 1.1.1.4 ?
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 7 Apr 92 23:51:18 GMT From: hom00@ccc.amdahl.com (Harold O Morris) To: comp.protocols.tcp-ip Subject: tn3270 Failure - Not Enough Fields?
We are running a version of tn3270 - seems to be 4.1.1, and about 3 years old (but I find the same version - at least is called 4.1.1, on ftp.uu.net). It works on most applications, but on one it always fails. This application has a very large number of single-character fields (kind of like checkmarks), and one theory a colleague had was that some array was designed to accommodate too few fields, if I just knew where to look. If anyone has heard of such a problem, or knows where I should look for the most current version of tn3270, I would appreciate hearing from you.
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 92 06:49:00 GMT From: AKayser@dnpap.et.tudelft.nl (Alfred Kayser) To: comp.protocols.tcp-ip Subject: Re: Packet sniffer for IBM-PC?
880274d@aucs.acadiau.ca (Ralph I. Doncaster) writes: >srp@modcomp.uucp (Steve Pietrowicz) writes: >>Is there a PD packet sniffer available for the PC? If so, where can I >>get it? >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 And there is our wonderfull tool called 'The Gobbler'. It is a development of the Beholder group. It can capture, filter, store and view all packets on ethernet, and this operation can even be controlled via SNMP!! Get it and try it! using anonymous ftp: Host: dutepp0.et.tudelft.nl path: /pub/Gobbler name: gobbler.zip Or using the mailserver at dnpap@dnpap.et.tudelft.nl: put in the subject or body of the mail: send /Gobbler/gobbler.zip and expect to receive four parts... Greetings, Alfred >-- >|Ralph Doncaster, Acadia Univ. ph & fax: (902)542-3010 | >|880274d@aucs.acadiau.ca ASU box 6585, Wolfville, NS B0P 1Z1 | -- -- 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 --
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 92 08:09:41 GMT From: frank@rniwi.rni.sub.org (Frank Mogaddedi) To: comp.protocols.tcp-ip Subject: NIS, broadcast, etc. Need help
Dear World, I hope this is the group to post to. I have the following situation: I have one Token-Ring Network, running Novell3.11 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 outside of the office-buildings to the world. 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? I have tried to read the manuals concerning addresses, broadcasts etc., but I don't understand them fully. 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.. Anybody out there who can help? Thanks in advance Frank Mogaddedi -- +-----------------------------------------------------------------------------+ | e-mail: frank@rniwi.rni.sub.org | Disclaimer: "Read my lips" (George Bush) | | Beauty is only skin-deep, but ugliness goes clean to the bone | | Maybe life is but a nightmare? |
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 92 08:26:01 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: TCP/IP & UDP/IP throughput on FDDI
In article <1992Apr7.103521.8796@spider.co.uk>, ian@spider.co.uk (Ian Heavens) writes: > Does anyone have figures or references for the performance on appropriate > hardware of TCP and UDP over FDDI? "appropriate hardware" for what purpose? Many common VME FDDI systems get 25-35Mbits/sec measured by ttcp. Others get considerably more. Van Jacobson at Interop91 reported filling the fibre with special hardware on HP machines with TCP. I've heard one super computer company gets 70Mbit/sec, perhaps measured by nettest, with relatively standard hardware. UDP is now faster or slower, depending on various things. In less than 18 months, FDDI will be as commonly saturated by UNIX workstations as ethernet was in 1989. Just as with ethernet, the problem is not hardware, but software. This can be seen in one VME card which does more about twice as well depending on firmware and host. Just as is still true with ethernet, some people will claim 30% is a lot or that special hardware is needed to get above 50%. (Both have been false for FDDI for more than 6 months.) Then again, doesn't Spider make bridges and routers? If you're talking about the packet/second rates which bridge & router guys care about, I don't know. A ring with 3,000 reasonably sized packets per second is in collapse, but 3,000 p/s is a puny number for the current bridge guys. Vernon Schryver, vjs@sgi.com
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Wed, 8 Apr 1992 10:20:26 GMT From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) To: comp.protocols.tcp-ip Subject: terminal concentrators
I'm looking for the measured throughput figures for various terminal concentrators. How many full-speed connections can the various vendor's TCs handle before 1) output slows down and 2) input gets dropped? I saw several reviews of various router's throughputs. Hopefully there is something similar for TC's. -wolfgang -- Wolfgang Rupprecht wolfgang@wsrcc.com (or) wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 92 12:41:57 GMT From: chris@visionware.co.uk (Chris Davies) To: comp.protocols.tcp-ip,comp.windows.x,comp.unix.admin,comp.dcom.lans.misc Subject: Re: LAN and WAN speeds (summary)
In article <9204021327.AA10923@poohbear.visionware.co.uk> I wrote:
> Considering a link speed of around 64 or 128 kbit/sec.
> We're planning to run IP over the link; I'd imagine a
> couple of rlogin sessions at any one time, plus several (6 or so?) X
> display servers, etc.
I'd like to thank all those who emailed me with comments. It appears
that a fair number of sites run X over 64kbit and 128kbit likes. Some
people find the speed acceptable, others find it "alright". The
prinicpal difficulty occurs if you try to manipulate (or use) large
bitmaps.
The consensus was that about 5-10 xterms would work over a 64kbit link
without too many problems. However, my question was rather like the
"how long's a piece of string" one.
NFS/RFS was considered a no-no (however, I believe it depends on all
sorts of things like buffer size, etc).
Regarding routers, Cisco, or Morning Star's Snaplink appeared to be the
main contenders to a NetBlazer (as I expected). All of these use PPP
in varying degrees. SnapLink and NetBlazers support on-demand dialup
IP; I don't know about the Cisco.
Again, thanks to those who replied.
Chris
--
VISIONWARE LTD, 57 Cardigan Lane, LEEDS LS4 2LE, England
Tel +44 532 788858 x238. Fax +44 532 304676. Email chris@visionware.co.uk
------------ "VisionWare: The home of DOS/SQL/UNIX/X integration" -----------
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 92 14:04:29 GMT From: Thomas.Tornblom@nexus.comm.se (Thomas Tornblom) To: comp.protocols.tcp-ip Subject: Support for IP options (or lack thereof)
How come so many TCP/IP products doesn't support IP properly?
I'm doing some experiments with the "Loose Source and Record Route"
option and have become a bit depressed about the performance of
some more or less well known implementations of TCP/IP.
Please note that according to RFC-791 the implementation if IP options
is by no mean optional, only the use of them.
I have had various machines crash painfully by sending a perfectly
valid IP datagram to it. I even managed to crash two machines with the
same datagram!
This was SunOS 4.1.1b before I applied patch 100149-3 (mclput panic).
SunOS 4.0.2 on a 386i doesn't forward datagrams with LSRR option.
ka9q handled the options OK but forgot to recompute the IP checksum
before forwarding the datagram.
The Cayman gatorbox wont route LSRR datagrams.
NCSA Telnet with MacTCP on a NuvoLINK SC SCSI-Ethernet adapter dies
horribly when LSRR datagrams are in the neighborhood.
Thomas
--
Real life: Thomas Tornblom Email: Thomas.Tornblom@nexus.comm.se
Snail mail: Communicator Nexus AB Phone: +46 18 171814
Box 857 Fax: +46 18 696516
S - 751 08 Uppsala, Sweden
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Wed, 8 Apr 1992 15:21:40 GMT From: k@hprnd.rose.hp.com (Steve Kao) To: comp.protocols.tcp-ip Subject: Re: tcp printer servers
Why not get an HP LaserJet with the appropriate TCP/IP card? You can then plug the printer directly onto the TCP/IP network. - Steve Kao
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: Wed, 8 Apr 1992 16:22:58 GMT From: bob@MorningStar.Com (Bob Sutterfield) To: comp.protocols.tcp-ip Subject: default address mask selection for a point-to-point network?
In RFC-1122 section 3.2.2.9 we see
(b) Until it has received an Address Mask Reply, the host SHOULD
assume a mask appropriate for the address class of the IP
address, i.e., assume that the connected network is not
subnetted.
The implementation is obvious for a connection a broadcast network
like an Ethernet - just derive the mask from the IP address of the
interface. But a point-to-point network connection (PPP, SLIP, or
whatever) has two IP addresses, one each for the "local" and "remote"
ends of the link.
From which address (local or remote) should a host infer the default
subnet address mask for a point-to-point network?
(My opinion: it should look at the remote address, because that's
where it looks for routing decisions.)
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 92 16:25:05 GMT From: gsa@easyaspi.udev.cdc.com (gary s anderson) To: comp.protocols.tcp-ip Subject: Re: Question on bind-socket
In article <1992Apr6.190727.3157@jarvis.csri.toronto.edu>, thomson@hub.toronto.edu (Brian Thomson) writes:
|> In article <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).
|> >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.
|> >But when I try to bind the same port address to the second socket descriptor
|> >the bind system call fails ("address already in use").
|>
|> SO_REUSEADDR does not mean what you think it means.
|> Don't let that worry you, though, few people do know what it is for.
|>
|> Basically, SO_REUSEADDR lets you have two sockets with *similar*
|> local & foreign address bindings, but nothing will allow you to have
|> two *identically* bound sockets, and that is what you are trying to do.
|> --
|> Brian Thomson, CSRI Univ. of Toronto
|> utcsri!uthub!thomson, thomson@hub.toronto.edu
The constraint is two identical "connected" sockets not two identical
"bound" sockets. See earlier posting on why the original code failed.
Please note this is not an endorsement of the original poster's technique,
rather, this is merely an attempt to properly identify the constraint.
If you are bored and would like a little test to shake-down your tcp
implementation: bind two tcp sockets (SOCK_STREAM) to the same local
address (loopback works fine) and the same port (choose any free port), be
sure to select the SO_REUSEADDR on the socket used in the second bind. Issue
a listen on one of the sockets and then issue a connect on the other
socket using the same address you used in the bind. If you get an
error on the connect, then your tcp implementation is OK. If not .......
WARNING - you may not want to do this on a production system.........
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 92 17:00:42 GMT From: andersen@unidoct.chemietechnik.uni-dortmund.de (Frank-Uwe Andersen) To: comp.protocols.tcp-ip Subject: NE1000-Standard: description wanted!
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.........
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: Wed, 8 Apr 1992 17:31:49 GMT From: mtcusa@tigger.jvnc.net (Multilingual Technogies Corporation) To: comp.protocols.tcp-ip Subject: Trouble with NCSA TCP/IP for MS-DOS
TO: Anyone
FROM: Mark Zeiger mtcusa@tigger.jvnc.net
DATE: April 8, 1992
RE: Trouble with NCSA Telnet for MS-DOS
We are trying to set up IBM compatible PCs to talk with our SCO Unix
TCP/IP network.
HARDWARE:
Fountain 486/33 ISA with 512K VGA
or
Fountain 386/33 ISA with 256K VGA
SMC (aka Western Digital) 8003E Ethercard PLUS Elite with settings:
Software setting: Int 5 I/O Addr 0x240 Base Mem 0xce00:0
or
Hardwire setting Int 5 I/O Addr 0x300 Base Mem 0xca00:0
Thin COAX
PROBLEMS:
1. Can not communicate with any SCO Unix system on network. NCSA
Telnet will not recognize any systems.
2. Hooked up two computers running NCSA Telnet only and isolated from
rest of network. Left one computer in server mode. When I tried to
connect with other computer using NCSA Telnet, server showed message:
Packet received for invalid port -- reset sent
Port 23
Server remained in server mode and second computer retruned to DOS.
3. ON 486 ONLY - when exitting NCSA Telnet, all screen functions lost.
Computer is active (i.e. DIR A: shows floppy being accessed), but I
must reboot computer to regain display.
OBSERVATIONS:
1. Using PKTALL showed packets being received by NCSA Telnet when it
was pinged from a SCO Unix computer.
2. All problems were consistent no matter what combination of hardware/
software settings were used (except for problem 3 naturally).
If anybody has any suggestions, we would really appreciate your help. Please
respond via email to Mark Zeiger at mtcusa@tigger.jvnc.net or we may be
reached locally if you're in New Jersey at Multilingual Technologies
Corporation at (201) 808-3344.
Thanks
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 92 19:41:02 GMT From: gsa@easyaspi.udev.cdc.com (gary s anderson) To: comp.protocols.tcp-ip Subject: Re: default address mask selection for a point-to-point network?
In article <BOB.92Apr8122251@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes: |> In RFC-1122 section 3.2.2.9 we see |> |> (b) Until it has received an Address Mask Reply, the host SHOULD |> assume a mask appropriate for the address class of the IP |> address, i.e., assume that the connected network is not |> subnetted. |> |> The implementation is obvious for a connection a broadcast network |> like an Ethernet - just derive the mask from the IP address of the |> interface. But a point-to-point network connection (PPP, SLIP, or |> whatever) has two IP addresses, one each for the "local" and "remote" |> ends of the link. |> |> From which address (local or remote) should a host infer the default |> subnet address mask for a point-to-point network? |> |> (My opinion: it should look at the remote address, because that's |> where it looks for routing decisions.) Point-to-point links typically show up in routing tables as "host entries" and not as "network entries". Therefore, the "mask" associated with routing is 32-bits, i.e. must match the complete IP address. The 32-bit mask would explicitly eliminate one from responding to an ICMP Address Mask Request because an "all 1's" response is illegal. Additionally, one would assume that you would not issue a mask request for either of the addresses because the full mask is already known. The one interesting point in your request is the possibility of the local and remote IP address for a point to point link to be in different subnets. This seems like an odd configuration, however, it seems that you would use the subnet assigned to the local address in order to be consistent with other interfaces (on the curious side, where would you get the remote subnet mask from, another routing table entry). RFC950 seems to indicate that the authors considered this feature to be a LAN broadcast tool and not a WAN or point-to-point tool. Consequently, there is no reference to implications in a point-to-point world. In fact does anyone really use the ICMP Address Mask Request on point-to- point links (does it even make sense)? If what you really want is to advertise information about the network (or subnet) accessible via the point-to-point link, which matches the network (or subnet) in the point-to-point link IP address, then define another routing table entry which explicitly defines the information you want to disseminate.
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 92 23:11:16 GMT From: thomson@hub.toronto.edu (Brian Thomson) To: comp.protocols.tcp-ip Subject: Re: Question on bind-socket
In article <40625@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
>In article <1992Apr6.190727.3157@jarvis.csri.toronto.edu>, thomson@hub.toronto.edu (Brian Thomson) writes:
>|>
>|> SO_REUSEADDR does not mean what you think it means.
>|> Don't let that worry you, though, few people do know what it is for.
>|>
>|> Basically, SO_REUSEADDR lets you have two sockets with *similar*
>|> local & foreign address bindings, but nothing will allow you to have
>|> two *identically* bound sockets, and that is what you are trying to do.
>
>The constraint is two identical "connected" sockets not two identical
>"bound" sockets. See earlier posting on why the original code failed.
Sorry, this is not correct in BSD or SunOS.
The second bind will fail whether or not SO_REUSEADDR is specified,
even if it is specified for the correct (the second) socket.
The only time you may have two sockets with exactly the same local and
foreign addresses and ports is when they are both "brand new" and
completely unbound.
As a demonstration, I tried the first part of your suggested:
>If you are bored and would like a little test to shake-down your tcp
>implementation: bind two tcp sockets (SOCK_STREAM) to the same local
>address (loopback works fine) and the same port (choose any free port), be
>sure to select the SO_REUSEADDR on the socket used in the second bind. Issue
>a listen on one of the sockets and then issue a connect on the other
>socket using the same address you used in the bind. If you get an
>error on the connect, then your tcp implementation is OK. If not .......
Here it is:
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
main(){
struct sockaddr_in addr;
int i,j;
int one = 1;
bzero((char *)&addr, sizeof addr);
addr.sin_family = AF_INET;
addr.sin_port = htons(12321);
addr.sin_addr.s_addr = inet_addr("127.0.0.1");
i = socket(PF_INET, SOCK_STREAM, 0);
if(bind(i, (char *)&addr, sizeof addr)<0)
perror("bind1");
j = socket(PF_INET, SOCK_STREAM, 0);
setsockopt(j, SOL_SOCKET, SO_REUSEADDR, &one, sizeof one);
if(bind(j, (char *)&addr, sizeof addr)<0)
perror("bind2");
}
I think you will agree that this follows your plan. It fails with
bind2: Address already in use
under SunOS4.1. It fails in the same way if I create SOCK_DGRAM sockets,
too.
--
Brian Thomson, CSRI Univ. of Toronto
utcsri!uthub!thomson, thomson@hub.toronto.edu
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 92 05:35:13 GMT From: pwickman@cerebus.cc.edu (Paul J. Wickman) To: comp.protocols.tcp-ip Subject: ping question
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
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 92 13:38:34 GMT From: xeee01@mixcom.com (Aniruddh Chawda) To: comp.protocols.tcp-ip Subject: One physical wire, multiple logical networks question
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?
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 92 14:36:37 GMT From: dletcher@umaxc.weeg.uiowa.edu (Drew Letcher) To: comp.dcom.sys.cisco,comp.dcom.lans,comp.protocols.ibm,comp.protocols.tcp-ip Subject: IBM 3270/telnet to non-IBM machine
Problem: IBM mainframe telnet uses 3270 protocol encapsulated
in the telnet protocol. Which is only useful if you telnet to another
IBM mainframe. We have a full screen application that people can access
through telnet. But our telnet server does not support 3270/telnet.
Q1: Does anyone know of a way to convert 3270/telnet into telnet using
another emulation such as VT100?
Q2: Does anyone know of a tn3270 telnet daemon for IBM PC compatibles?
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 92 14:51:40 GMT From: sblair@upurbmw.dell.com (Steven C. Blair "Unix Network Services") To: comp.protocols.tcp-ip Subject: Re: One physical wire, multiple logical networks question
In article <1992Apr09.133834.14574@mixcom.com>, xeee01@mixcom.com (Aniruddh Chawda) writes:
>
> 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?
Not if you want to set the subnet masks very wide(255.255.0.0(example),
and do something really nasty like having one host do route advertising
for all the other networks, as well as doing a bunch of arp -s addr
to fake stuff out. A fairly normal thing to do to a class B network, when
*and only when* one needs to do some testing. Best way is to take a
machine, put 2 interfaces in it, and fake it out(UNIX/routing information)
via the second interface.
good luck,
--
Steven C. Blair DELL UNIX NETWORK OPERATIONS sblair@dell.com
==========================================================================
"One form to rule them all, one form to find them, one form to bring them"
"all and in the darkness rewrite the hell out of them."
-- Sendmail ruleset 3 comment from DEC
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 92 15:00:19 GMT From: psirakis@yoko.rutgers.edu (Psirakis Alexander) To: comp.protocols.tcp-ip Subject: bind-socket #2
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
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: Thu, 9 Apr 1992 15:19:41 GMT From: aep@icd.ab.com (Alexander E. Pensky) To: comp.protocols.tcp-ip Subject: Re: Question on bind-socket
In article <1992Apr8.191115.26347@jarvis.csri.toronto.edu>, thomson@hub.toronto.edu (Brian Thomson) writes: > >|> > >|> Basically, SO_REUSEADDR lets you have two sockets with *similar* > >|> local & foreign address bindings, but nothing will allow you to have > >|> two *identically* bound sockets, and that is what you are trying to do. > > > >The constraint is two identical "connected" sockets not two identical > >"bound" sockets. See earlier posting on why the original code failed. > > Sorry, this is not correct in BSD or SunOS. > The second bind will fail whether or not SO_REUSEADDR is specified, > even if it is specified for the correct (the second) socket. > The only time you may have two sockets with exactly the same local and > foreign addresses and ports is when they are both "brand new" and > completely unbound. Sorry, Brian, this is not correct either. If SO_REUSEADDR is specified, you may have two sockets bound to the same local address, as long as their remote addresses are different. This is true if both are bound to the same local address, but one has connected to a remote port and the other has not. It is also true when both are connected to two different remote ports. Thus SO_REUSEADDR can be used in a client-server design when a client wants to use several servers simultaneously, but would like to use the same local port number for all the connections. > > As a demonstration, I tried the first part of your suggested: [example program deleted...] Wrong demonstration. At the time of the second bind(), both sockets will have the same complete address, that is, Local=(127.0.0.1,12321), Remote=(*,*) Better demonstration: After binding the first socket, connect() it to some port that another program is listening on, _then_ try to bind() the second socket. The addresses will then be: Socket i: Local=(127.0.0.1,12321), Remote=(Somehost,Someport) Socket j: Local=(127.0.0.1,12321), Remote=(*,*) and the second bind() will succeed. ----------------------------------------------------------------------------- Alex Pensky (aep@icd.ab.com) (216)646-5211 Allen-Bradley Company 747 Alpha Drive, Highland Heights, OH 44143 -----------------------------------------------------------------------------
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: Thu, 9 Apr 1992 15:51:24 GMT From: bourman@hpcc01.corp.hp.com (Bob Bourman) To: comp.protocols.tcp-ip Subject: Re: programming tools for TCP/IP on PCs
FTP Software Inc. P.O.Box 150 Boston, Ma. 02142-9922
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: Thu, 9 Apr 1992 19:56:43 GMT From: bob@MorningStar.Com (Bob Sutterfield) To: comp.protocols.tcp-ip Subject: Re: default address mask selection for a point-to-point network?
In article <40635@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
In article <BOB.92Apr8122251@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
From which address (local or remote) should a host infer the
default subnet address mask for a point-to-point network?
one would assume that you would not issue a mask request for either
of the addresses because the full mask is already known.
Though RFC-1122 section 3.2.2.9 talks about ICMP Address Mask
transactions, it was the only place I could find *any* discussion of
decisions leading to picking a particular address mask size and shape.
The one interesting point in your request is the possibility of the
local and remote IP address for a point to point link to be in
different subnets. This seems like an odd configuration,
Not at all, here's an example from a Sun. du0 is our dialup link to
OARnet, and du1 is a fabricated link to the old ohio-state.arpa:
3:27pm> ifconfig -a
le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
inet 137.175.2.11 netmask ffffff00 broadcast 137.175.2.255
ether 0:c0:7:0:0:1e
lo0: flags=49<UP,LOOPBACK,RUNNING>
inet 127.0.0.1 netmask ff000000
du0: flags=51<UP,POINTOPOINT,RUNNING>
inet 137.175.2.11 --> 131.187.1.12 netmask ffff0000
du1: flags=51<UP,POINTOPOINT,RUNNING>
inet 137.175.2.11 --> 192.5.58.18 netmask ffff0000
3:27pm>
It's very common for point-to-point links to run between networks. In
such a case, the routing tables look like
3:27pm> netstat -rn | egrep du\|table\|Flag
Routing tables
Destination Gateway Flags Refcnt Use Interface
192.5.58.18 137.175.2.11 UH 0 0 du1
131.187.1.12 137.175.2.11 UH 0 24 du0
default 131.187.1.12 UG 10 10051 du0
3:27pm>
As you note from du1's ifconfig above, our PPP software's behavior
(which I'm questioning) is to deduce a default netmask based on the
address class of the local end of the wire.
however, it seems that you would use the subnet assigned to the
local address in order to be consistent with other interfaces
The need for consistency between interfaces is, I think, an artifact
of deficiencies in some vendors' 4.3BSD-based code, or perhaps in
4.3BSD itself. I haven't examined tahoe, reno, BSDI, or 4.4 to see
what they do. I don't believe non-4.3 IP implementations (e.g. in a
real router) require or enforce netmask consistency between
interfaces.
And besides, which other local non-point-to-point interface should I
choose as my sample netmask? The example above shows one Class-A and
one Class-B with Class-C style subnetting.
(on the curious side, where would you get the remote subnet mask
from, another routing table entry).
Since PPP's IPCP lacks an address mask negotiation option, we depend
upon the user to set it from the daemon startup command line if (a)
they care and (b) the default was inappropriate.
In fact does anyone really use the ICMP Address Mask Request on
point-to-point links (does it even make sense)?
I don't think so, and I don't think it even makes sense. But some
software (e.g. routed) cares about the mask it sees on "up"
interfaces, so we try to set the masks appropriately when we ifconfig
the point-to-point interface.
If what you really want is to advertise information about the
network (or subnet) accessible via the point-to-point link, which
matches the network (or subnet) in the point-to-point link IP
address, then define another routing table entry which explicitly
defines the information you want to disseminate.
Today, our users with gated set the netmask explicitly from the pppd
command line, if the default is inappropriate, before starting gated.
This gets the correct information disseminated. And BSD netmasks are
stored in per-interface information, not in the routing table.
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 92 20:02:51 GMT From: tneff@bfmny0.BFM.COM (Tom Neff) To: comp.windows.x,comp.unix.sysv386,comp.protocols.tcp-ip Subject: Cannot create address for system xxxxx
Can anyone tell me what the error message Cannot create address for system xxxxx means, where 'xxxxx' is the name of another system on the network? I am getting this from X clients I try to attach to other systems' servers. What is likely to be misconfigured? Thanks in advance... -- "Why don't you get me some coffee while ||[]|| Tom Neff I'm looking over your application?" /\/\ tneff@bfmny0.BFM.COM
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 92 20:41:25 GMT From: pmarimut@eos.ncsu.edu (PERAM MARIMUTHU) To: comp.protocols.tcp-ip Subject: getpeername...help
How can I use the getpeername function to get the name of the machine
that is connected to a socket. The following code returns the internet
address (a.b.c.d) correctly but not the name.
getpeername(msgsock,(struct sockaddr *)&peer,&length)
printf("%s\n",inet_ntoa(peer.sin_addr));
so far its OK-----
What should I do next?
Thanks
peram
pmarimut@eos.ncsu.edu
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 92 21:12:30 GMT From: cmo@pogo.wv.tek.com (Christine Olsen) To: comp.protocols.tcp-ip Subject: SNMP MIBs
I know that MIBs are kept on venera.isi.edu. Does anyone know if there are other machines where MIBs are kept? Please reply via email: cmo@pogo.wv.tek.com Thank you for any help on this. Christine Olsen Tektronix, Inc.
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 92 22:00:41 GMT From: roy@alanine.phri.nyu.edu (Roy Smith) To: comp.protocols.tcp-ip Subject: Minimal ping object?
What is the absolute cheapest pingable object I can put on an ethernet? I supose to be practical, I should limit the field to commercially available devices, but just for fun, let's assume I was willing to build or modify something as long as it's reasonable (and no, I'm not exactly sure what the limits of reasonable are). -- roy@alanine.phri.nyu.edu (Roy Smith) Public Health Research Institute 455 First Avenue, New York, NY 10016, USA "This never happened to Bart Simpson."
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 92 22:16:00 GMT From: gsa@easyaspi.udev.cdc.com (gary s anderson) To: comp.protocols.tcp-ip Subject: Re: default address mask selection for a point-to-point network?
In article <BOB.92Apr9155631@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes: |> In article <40635@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes: |> In article <BOB.92Apr8122251@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes: |> From which address (local or remote) should a host infer the |> default subnet address mask for a point-to-point network? |> |> one would assume that you would not issue a mask request for either |> of the addresses because the full mask is already known. |> |> Though RFC-1122 section 3.2.2.9 talks about ICMP Address Mask |> transactions, it was the only place I could find *any* discussion of |> decisions leading to picking a particular address mask size and shape. |> |> The one interesting point in your request is the possibility of the |> local and remote IP address for a point to point link to be in |> different subnets. This seems like an odd configuration, |> |> Not at all, here's an example from a Sun. du0 is our dialup link to |> OARnet, and du1 is a fabricated link to the old ohio-state.arpa: |> |> 3:27pm> ifconfig -a |> le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING> |> inet 137.175.2.11 netmask ffffff00 broadcast 137.175.2.255 |> ether 0:c0:7:0:0:1e |> lo0: flags=49<UP,LOOPBACK,RUNNING> |> inet 127.0.0.1 netmask ff000000 |> du0: flags=51<UP,POINTOPOINT,RUNNING> |> inet 137.175.2.11 --> 131.187.1.12 netmask ffff0000 |> du1: flags=51<UP,POINTOPOINT,RUNNING> |> inet 137.175.2.11 --> 192.5.58.18 netmask ffff0000 |> 3:27pm> |> |> It's very common for point-to-point links to run between networks. In |> such a case, the routing tables look like |> |> 3:27pm> netstat -rn | egrep du\|table\|Flag |> Routing tables |> Destination Gateway Flags Refcnt Use Interface |> 192.5.58.18 137.175.2.11 UH 0 0 du1 |> 131.187.1.12 137.175.2.11 UH 0 24 du0 |> default 131.187.1.12 UG 10 10051 du0 |> 3:27pm> This was my initial point. From a routing perspective, a point-to-point link uses full 32-bit addressing. In this configuration the network mask associated with the interface is not used in any routing decisions. |> |> As you note from du1's ifconfig above, our PPP software's behavior |> (which I'm questioning) is to deduce a default netmask based on the |> address class of the local end of the wire. |> |> however, it seems that you would use the subnet assigned to the |> local address in order to be consistent with other interfaces |> |> The need for consistency between interfaces is, I think, an artifact |> of deficiencies in some vendors' 4.3BSD-based code, or perhaps in |> 4.3BSD itself. I haven't examined tahoe, reno, BSDI, or 4.4 to see |> what they do. I don't believe non-4.3 IP implementations (e.g. in a |> real router) require or enforce netmask consistency between |> interfaces. |> |> And besides, which other local non-point-to-point interface should I |> choose as my sample netmask? The example above shows one Class-A and |> one Class-B with Class-C style subnetting. |> I probably wasn't clear here. The ICMP Address Mask Response code dips into the *ia* structure to find the subnet mask. This structure contains the interface address subnet mask for the local IP address. By "consistent" I meant to use the same code for all interfaces (i.e. supply the subnet mask of the corresponding local IP address), including point to point links. (NOTE - this is what you should get from a BSD-based solution). I did not mean to imply that you would use the mask from a different interface..... |> (on the curious side, where would you get the remote subnet mask |> from, another routing table entry). |> |> Since PPP's IPCP lacks an address mask negotiation option, we depend |> upon the user to set it from the daemon startup command line if (a) |> they care and (b) the default was inappropriate. |> |> In fact does anyone really use the ICMP Address Mask Request on |> point-to-point links (does it even make sense)? |> |> I don't think so, and I don't think it even makes sense. But some |> software (e.g. routed) cares about the mask it sees on "up" |> interfaces, so we try to set the masks appropriately when we ifconfig |> the point-to-point interface. May I ask what particular piece of software cares? My limited view of the world has seen code which special cases point to point links and looks at them as src/dest pairs rather than src/mask pairs. Are there SNMP managers which flag an interface as a bogus point to point link if the subnet mask is not what was expected? Even if they did, is this a major problem (i.e. can't the manager reset the mask or, worst case, isn't this a one time change to some initialization script (if you made an error the first time))? |> |> If what you really want is to advertise information about the |> network (or subnet) accessible via the point-to-point link, which |> matches the network (or subnet) in the point-to-point link IP |> address, then define another routing table entry which explicitly |> defines the information you want to disseminate. |> |> Today, our users with gated set the netmask explicitly from the pppd |> command line, if the default is inappropriate, before starting gated. |> This gets the correct information disseminated. And BSD netmasks are |> stored in per-interface information, not in the routing table.
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: Thu, 9 Apr 1992 23:05:33 GMT From: k2@bl.physik.tu-muenchen.de (Klaus Steinberger) To: comp.protocols.tcp-ip Subject: Re: NIS, broadcast, etc. Need help
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
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: Thu, 9 Apr 1992 23:20:11 GMT From: mike@gordian.com (Michael Thomas) To: comp.protocols.tcp-ip,comp.unix.wizards Subject: LPR on a terminal server, Opinions?
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? ;-).
What I am interested in hearing is whether some of the options which
LPR supports are dispensable or work-aroundable on the server/host side:
1) The control file, seems to come second (after the data file).
On a terminal server, there isn't any spool area, and this
means that a terminal server would have to ignore it.
a) Is there a way to get the control file to come before the
data file, and if so how.
b) If (a) cannot be worked around, how serious a limitation would
this be? (Ie no server generated banner pages, none of the
various filtering options, etc)
2) Assuming (1) can be worked around, there are several options which
would _never_ be implemented on the terminal server (Troff-X, DVI,
plot/raster filters etc). Would an LPRd which lacked these features
be a serious hinderance? Would it be possible to work around these
by having the host side (ie LPR side) pre format the data stream and
send it to the LPRd raw?
Comments greatly welcomed.
--
Michael Thomas (mike@gordian.com)
"I don't think Bambi Eyes will get you that flame thrower..."
-- Hobbes to Calvin
USnail: 20361 Irvine Ave Santa Ana Heights, Ca, 92707-5637
PaBell: (714) 850-0205 (714) 850-0533 (fax)
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 92 00:22:28 GMT From: u8551044@ucsvc.ucs.unimelb.edu.au To: comp.protocols.tcp-ip Subject: FTP not timing out?
Hello,
subject: FTP not timing out?
When one of our machines crash (host A), a decstation ds5200,
ultrix v4.2 (rev. 96), scripted ftp processes on other machines get into
in an idle state and stay this way for days. When host A is rebooted, the
processes on hosts B and C doing scripted ftps do not abort, they remain is
an idle state (don't chew up cpu).
Unfortunately we are testing a new package on A (which used to be
healthy), so I am trying to work out why the ftp processes on B and C
do not time out or fail as I think they should. The crash simply hangs A.
I do a regular (scripted) anonymous ftp to get files off host A
"decstation ds5200, ultrix v4.2 (rev. 96)" from host B
(VAX/VMS version V5.4-2).
I do an anonymous ftp to place files regularly (in a script) from
host C "OS/MP 4.1A.2 UNIX (SunOS 4.1 compatible)" to host A.
ie: C execs ---> put--> A
B execs <--get <--- A
Any ideas appreciated,
many thanks,
Greg Chenhall, The University of Melbourne, GMC@unimelb.edu.au
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 92 01:00:52 GMT From: thomson@hub.toronto.edu (Brian Thomson) To: comp.protocols.tcp-ip Subject: Re: Question on bind-socket