|
|
ARCHIVE: TCP-IP Distribution List - Archives (1990)
DOCUMENT: TCP-IP Distribution List for October 1990 (463 messages, 278793 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1990/10.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Mon, 1 Oct 90 14:55:35 CDT From: darrel beach <beach@ddnuvax.af.mil> To: tcp-ip@nic.ddn.mil Cc: beach@ddnuvax.af.mil Subject: TCP/IP for DEPCA boards
Another plea for info... Can anyone point me to drivers, software, vendors to let me run TCP/IP on PCs which have a DEPCA (Digitals Ethernet PC bus Adapter) cards. Packet drivers compatible with NCSA, KA9Q, or even a commercial package would be appreciated. Thanx in advance... Darrel Beach
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Mon, 1 Oct 90 15:34:00 EDT From: Tom Seto <Seto%UNCAMULT.bitnet@ugw.utcs.utoronto.ca> To: tcp-ip@NIC.DDN.MIL Subject: TCP/IP products
Hello. We are currently putting together a RFP to obtain more computing
power of the UNIX variety. While we were reviewing the various aspects
of the request, a question came up: Is there a measure for the
"Goodness" of a particular tcp/ip product, ie how well does it conform
to the standards, how well does it perform, etc? We have in the passed
tossed a package from one vendor and purchased one from another on our
VAX/VMS. The UNIX systems presumably comes with a tcp in the system,
but is there anyway to measure whether a vendor has done a particularly
good or bad job of it? I would also welcome comments regarding products
that are out there, especially products that come with a particular
brand of hardware.
Thanks for your time.
Tom Seto
Mgr, Data Comm
ACS
U of Calgary
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 1 Oct 90 13:55:07 GMT From: mailrus!sharkey!cfctech!alexb@uunet.uu.net (Alex Beylin) To: tcp-ip@nic.ddn.mil Subject: SLIP, IP Routers and Named Pipes
A project have come up around here that require multiple PCs to get dial-in access to the TCP/IP network. One of the major requirements is support for Named Pipes down to the PC. Current plan is to use SLIP and a router with dial-in ports. Would someone care to recommend a PC package that would do good SLIP emulation and a router that would be suitable for this job? Comments, suggestions are most welcome. Thanks in advance, -- Alex Alex Beylin, Unix Specialist | +1 313 948-3386 alexb@cfctech.cfc.com | Chrysler Financial Corp. sharkey!cfctech!alexb | MIS, Distributed Systems ATT Mail ID: attmail!abeylin | Southfield, MI 48034
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 1 Oct 90 15:19:10 GMT From: bu.edu!rpi!zaphod.mps.ohio-state.edu!mips!ultra!wayne@bloom-beacon.mit.edu (Wayne Hathaway) To: tcp-ip@nic.ddn.mil Subject: Re: Question on forwarding broadcasts
Thanks to all who responded to my "Question on forwarding broadcasts"
posting. Two quickies.
One, I apologize for over-simplifying the picture. In the real life
situation both hosts do in fact have other network connections, so
they really SHOULD be forwarding packets. If I had drawn a couple
more lines it would have been clearer.
But mostly, I should have read RFC 1009 more carefully, 'cause sure
enough, there it is right on page 36:
In general, a gateway must not forward a datagram which
arrives via local network broadcast, and must not send
an ICMP error message when dropping the datagram. A
discussion of the rules will be found in Appendix A;
see also [50].
(Interesting that this specific situation does NOT seem to be
mentioned anywhere in Appendix A, however!)
Now the only question is when the support for the above requirement
(that is, Data Link telling IP whether a packet arrived via broadcast
or multicast) will get out in the various host implementations. And
THAT is what I should/would have asked, if I had read RFC 1009 better!
Anyway, apologies for the wasted net bandwidth on red herrings. Now,
about the REAL question ... ?
Wayne Hathaway domain: wayne@Ultra.COM
Ultra Network Technologies uucp: ...!ames!ultra!wayne
101 Daggett Drive phone: 408-922-0100 x132
San Jose, CA 95134 direct: Hey, you!
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Tue, 2 Oct 90 03:49:22 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) To: tcp-ip@nic.ddn.mil Subject: Maintainability of TELNET Sessions Over Marginal Circuits
A site that I'm involved with has an interesting problem involving TELNET,
specifically, and TCP/IP, in general, over encrypted and/or marginal links.
I'm interested in comments from this group that might suggest a solution
to this problem.
For want of a better description, the organization of this network might
be described as a WAN. It consists of a number of LANS each of which has,
at least, one router with, at least, two direct links to other LANS. Each
of the links is encrypted. The purpose of multiple direct links is to pro-
vide redundant paths to a central system that provides a common database
and a common set of services for the workstations on each of the LANS.
When the user wishes to make use of the central system, the user establishes
a TELNET connection to the central system through a process that also provides
an emulation of a terminal supported by the central system.
They had expected the router on loss of a circuit (loss of crypto synch)
to switch over to an alternate circuit and maintain the TELNET connection.
When they brought up the first LAN, they encountered two problems--the link
was of poorer quality than they had thought and continually looses synch
and the router did not switch circuits as they thought it would. When the
TELNET connection is re-established, they are not reconnected to their pre-
vious session.
When crypto synchronization is lost, random data will appear on the circuit
until both crypto units detect the loss of synchronization and have re-synched.
The questions:
1. Do routers generally have the capability to re-route traffic over
an alternate circuit?
2. How robust is IP in dealing with corrupted data streams when crypto
synch is lost in the header? In the body?
3. How robust is TCP in dealing with corrupted data streams?
4. Would fudging IP, TCP, or TELNET timers by a "crypto resync constant"
alleviate problems?
Any comments would be appreciated.
Merton
,
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 1 Oct 90 17:08:58 GMT From: kdb@macaw.intercon.com (Kurt Baumann) To: comp.protocols.appletalk,comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: MAC MS-MAIL to SMTP gateway?
In article <546@fciva.FRANKLIN.COM>, dag@fciva.FRANKLIN.COM (Daniel A. Graifer) writes: > I thought the GatorMail products were software to run on the GatorBox. Am I > mistaken? Hard to believe that products designed for a GatorBox would run > on Kinetics-oops-Novell-oops-Shiva FastPath. I might be mistaken, but they do sell it as a seperate product. The last I knew it ran with any AppleTalk-IP gateway product. Course this might have changed as well. Anyone listening from Cayman, Brad? Kurt -- Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh.
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 01:31:00 GMT From: adelphi!news@uunet.uu.net (News Feed) To: tcp-ip@nic.ddn.mil Subject: Re: Please boycott Xircom
In article <NELSON.90Sep28233146@image.clarkson.edu>, nelson@sun.soe.clarkson.edu (Russ Nelson) writes: > > [2] I have also been advised that, lacking copyright registration, all > that I could accomplish is to force you to stop distributing the driver, > which you have already agreed to do. > > -- > --russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667 > It's better to get mugged than to live a life of fear -- Freeman Dyson I myself hold 3 copyrights on software I developed for the printing industry dealing with CAM and I remember posing the following question to my lawyer: How long do I have to register my copyright, and when does the copyright take effect? According to him and the form TX as well as the related booklet on filing form TX from the Library of Congress, you have up to 2 years to file your copyright registration, and the code that comes off ones pen is copyright by him/her, as long as it is not a work for hire or contracted oherwise. The implied registration covers the period before registration. As a matter of fact my lawyer told me, and I did in all cases, to just file the docuemtation and a binary listing of the code, thus leaving the source to be considered "trade secret". He stated this gives better protection. My point is, why is the above listed driver not copyright in the same manner. I certainly am confused now. Can anyone state the facts? I hate to see people get burned like that.
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 01:41:47 GMT From: brooks@apple.com (Kevin Brooks) To: tcp-ip@nic.ddn.mil Subject: HP TCP/IP router/bridge?
Does anyone know of a bridge or router that will allow HP hosts running
TCP/IP which speak IEEE style packets (802.2 encapsulated) to
communicate with ethernet style IP implementations? Do most of the
router/bridge vendors support both IEEE and ethernet style IP packets?
Thanks in advance
Kevin
--
Kevin Brooks A/UX Specialist, Apple Computer
UUCP: {mtxinu,sun,nsc,voder}!apple!brooks
APPLELINK: AUX.DUDE@applelink.apple.com
Internet: brooks@apple.com
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 01:48:56 GMT From: news@ncsuvx.ncsu.edu (Shahrooz A Alavi) To: tcp-ip@nic.ddn.mil Subject: >>> Internetworking with TCP/IP book FOR SALE <<<
NEW "Internetworking with TCP/IP. Principles, Protocols and Arch." by D Comer [Prentice Hall] $35 (includes shipping) Send me an email with your daytime mailing address and I will send it to you UPS/COD. ----------------------------------------------------------- S. Alavi (919) 467-7909 ssa@eceugs.ece.ncsu.edu
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Tue, 02 Oct 90 09:21:09 -0400 From: H. Craig McKee <mckee@chance.mitre.org> To: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) Cc: tcp-ip@nic.ddn.mil Subject: Re: Maintainability of TELNET Sessions Over Marginal Circuits
>When they brought up the first LAN ... the link was of poorer quality >than they had thought and continually looses [crypto] synch .... Is the link protocol synchronous (eg, HDLC) or asynchronous (start/ stop bits)? My experience with synchronous links is that a crypto like the KG-84 rarely looses synch (because modem clock recovery circuits are generally very good). For some cryptos there is a mode of operation called CTAC that is self-synchronizing; it does not require loss-of- synch logic in another box. The site can get expert advice from their cryptologic support center or the National Security Agency. >2. How robust is IP in dealing with corrupted data streams when crypto > synch is lost in the header? In the body? >3. How robust is TCP in dealing with corrupted data streams? Corrupted data will be detected and discarded by error detection logic at the link, IP, and TCP layers. >4. Would fudging IP, TCP, or TELNET timers by a "crypto resync constant" > alleviate problems? Give it a try; it's not a good hack, but I've done some bizarre things when trying to get a circuit up. Regards - Craig
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Tue, 2 Oct 90 11:39:51 -0500 From: jbvb@ftp.com (James B. Van Bokkelen) To: darrel beach <beach@ddnuvax.af.mil> Cc: tcp-ip@nic.ddn.mil Subject: Re: TCP/IP for DEPCA boards
I'm posting to the list because this question gets asked awfully frequently: DEC's PCSA and DECNet/DOS products currently use a hardware-independent interface-sharing driver spec called "DLL". It is documented in the VaxMate Tech Ref. DEC supplies DLL drivers for various interfaces (theirs and 3Com's, I think) with PCSA and DECNet/DOS, and a number of other board vendors (e.g. Western Digital, Interlan that I know of) also offer DLL drivers for their own boards. FTP's PC/TCP (part PC-223) and Wollongong's WIN/PC can use DLL drivers. In addition, DEC has or will soon release an NDIS driver for the DEPCA. If you have this, you can use it with our freeware NDIS to Packet Driver adapter module (in pub/packet.driver/NDIS on vax.ftp.com, I won't mail it to you) and any of the TCP/IPs that support the Packet Driver (PC/TCP, WIN/PC, BWTCP, PCIP, KA9Q, NCSA, CUTCP, PCRoute, etc.). James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 05:22:52 GMT From: swrinde!zaphod.mps.ohio-state.edu!rpi!clarkson!news.clarkson.edu!nelson@ucsd.edu (Russ Nelson) To: tcp-ip@nic.ddn.mil Subject: Re: TCP/IP for DEPCA boards
In article <CMM.0.88.654810935.beach@ddnuvax.af.mil> beach@DDNUVAX.AF.MIL (darrel beach) writes:
Can anyone point me to drivers, software, vendors to let me run
TCP/IP on PCs which have a DEPCA (Digitals Ethernet PC bus Adapter)
cards. Packet drivers compatible with NCSA, KA9Q, or even a commercial
package would be appreciated.
Not yet, but the picture is coming into focus. We've gone from
"Digital refuses to release programming information" (that was just a
rumor) to "How may I help get you the information you need to write a
packet driver?"
Maybe in a couple of months...
--
--russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667
It's better to get mugged than to live a life of fear -- Freeman Dyson
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Tue, 2 Oct 90 15:23:14 MDT From: <wbaggett@NMSU.Edu> To: tcp-ip@sri-nic.arpa
subscribe Tim Baggett
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 12:23:34 GMT From: ingr!b11!usenet@uunet.uu.net (Usenet Network) To: tcp-ip@nic.ddn.mil Subject: Re: SLIP, IP Routers and Named Pipes
in article <1990Oct1.135507.27559@cfctech.cfc.com>, alexb@cfctech.cfc.com (Alex Beylin) says:
>
> Would someone care to recommend a PC package that would do good
> SLIP emulation and a router that would be suitable for this job?
---
The company I work for sells PC/NFS. I do not have experiance with
the product over serial lines, but PC/NFS (from Sun) does support SLIP.
SUN US SALES is listed as:
1-800-821-4643
For routers see cisco or there are terminal servers that support SLIP.
I worked for an outfit that sold cisco and the company I work for now
sells the Encore Annex II.
cisco
415-326-1941
encore (terminal server with slip)
617-460-0500
NOTE: I am not endorsing these products, but they are worth investigation.
--
* John E. Allen - Intergraph Corporation - (205) 730-8627 *
* System Sales Support *
* ingr!b23b!allen!jallen@uunet.uu.net *
**************************************************************
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 13:28:35 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!rphroy!cfctech!sharkey!fmsrl7!slee01!hugh@ucsd.edu (Hugh Fader) To: tcp-ip@nic.ddn.mil Subject: Is there a program like telnet, but driven by a script?
I need to duplicate UNIX-to-UNIX rsh functionality going UNIX-to-VMS. I am running a Sun Sparcstation and can communicate with the VAX using telnet and ftp via an ULTRIX gateway (the VAX only runs DECNET). One solution to my problem would be a telnet-like program which accepts a script containing expect/send pairs much like UUCP and some PC communications programs. Does such a program exist? I would also appreciate any suggestions of alternate solutions. Thanks in advance. -- Hugh Fader hugh@slee01.srl.ford.com
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 14:20:36 GMT From: pacbell.com!pacbell!varian!vaxwaller!phil@ucsd.edu (Phil Newton) To: tcp-ip@nic.ddn.mil Subject: HOW CAN I GET ON THE INTERNET???
I am interested in finding out HOW to gain access to the Internet.
Would anyone out there who knows how to so this please let me know, too?
Thanks in advance for your assistance!
--
Philip T. Newton (415)945-2272
Varian Instruments 2700 Mitchell Drive Walnut Creek, CA. 94598
{zehntel,pacbell,lll-winken}!varian!phil
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 17:51:49 GMT From: prang!marciano@lll-winken.llnl.gov (marciano pitargue) To: tcp-ip@nic.ddn.mil Subject: Re: SNMP comparison
>Something? Vitalink ( I think it's a repackaged HP product ) ... >-- >Per Andersson (perand@admin.kth.se, perand@stacken.kth.se) >Trying a new job at Bofors Electronics, >still reading news at the Royal Institute of Technology >Time, got the time tick tick tickin' in my head - Joe Jackson it's called the Wan Manager. it's is _not_ a repackaged HP product. /marciano marciano@vitalink.com vitam6!marciano@uunet.uu.net ...uunet!!vitam6!marciano disclaimer: noun. 1. a denial or disavowal of legal claim: relinquishment of or formal refusal to accept an interest or estate. 2. a writing that embodies a legal disclaimer.
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 18:25:41 GMT From: HANK@TAUNIVM.BITNET (Hank Nussbacher) To: comp.protocols.tcp-ip Subject: Router scorecard V1.6
CAVEATS
-------
The following scorecard tries to compare various multi-protocol
routers. The current scorecard mainly contains information for
cisco and Wellfleet but any other vendor is welcome to send me a
complete set of manuals for their equipment so that I can analyze
and update the scorecard.
The fact of the matter is that certain features and "gotchas"
only appear when testing the actual equipment. I hope that the user
population of multi-protocol routers will assist me in making this
scorecard as comprehensive as possible so that people who follow do
not have to go through what I have gone through.
It was difficult to decide whether to include future release
notes in this scorecard. I trust the user population in the
Internet to take each promise for a "future feature" with a grain of
salt and to keep watch on the vendors that indeed they follow
through with their promises. All too often vendors state certain
features will be available in a certain release and sometimes their
deadlines slip. It is advised that people should not base their
decisions on the future release notes. [That was a long caveat].
If you have comments, suggestions, additions, or subtractions
or corrections, please send them to:
HANK@VM.TAU.AC.IL or HANK@TAUNIVM.BITNET (but not to both!)
The scorecard will be updated on a monthly basis. This report
may be freely reproduced as long as nothing is altered or removed.
If you read this report and are not connected to the Internet,
you can send your comments to:
Hank Nussbacher
Computer Center
Tel Aviv University
Ramat Aviv
Israel
[The above employer has nothing to do with this scorecard so if
something bothers you about it, I take full responsibility.]
END OF CAVEATS
--------------------------------------------------------------------
V1.6 update: Various vendors have been in contact with me but after
expressing interest in having an entry for their machine they disappear.
Other vendors have tried to change the particular hardware box that
is being compared to another box. I hope that vendors will participate
in keeping this scorecard up-to-date.
--------------------------------------------------------------------
Distribution:
cisco@spot.colorado.edu
wellfleet@nstn.ns.ca
tcpip@nic.ddn.mil
ripe@mcsun.eu.net
p4200@devvax.tn.cornell.edu
Usenet: comp.dcom.lans
--------------------------------------------------------------------
Comparison of Multiprotocol Routers
Henry Nussbacher
October 1990
Version 1.6
+--------------+--------------+---------------+
Multiprotocol | cisco AGS+ | Wellfleet LN | Proteon p4200 |
Router | Rel. 8.1(14) | Rel. 5.35 | |
+--------------+--------------+---------------+
1. General | | | |
- # of slots | 9 | 4 | 7 |
- Processor | 68020 | 68020 | 68020 |
- Memory | 4Mbyte | 4Mbyte | 2Mbyte |
- Updates via | ROM, TFTP | diskette,TFTP| diskette,TFTP |
- Speed of bus | 530Mb/sec (a)| 320Mb/sec | |
- Boot from | | | |
- ROM | Yes | No | No |
- Net-boot | | | |
- IP | Yes | No | Yes |
- Decnet (MOP) | No | No | No |
- Diskette | No | Yes | No |
- Another router | Yes | No | No |
- Volatile changes | Yes (b) | No | Yes (h) |
- CPU statistics | Yes (c) | No | Yes |
- Memory stats | Yes | No | Yes |
- Ease of install | Very easy | menu driven | |
- Documentation | Difficult | Skimpy | Clear, orderly|
- Autorestart (d) | Yes | Yes | Yes |
- Restart for | | | |
config changes | No | Yes | Yes |
- Watchdog timer | Yes | | Yes |
- Reboot time (e) | 29 sec (f) | 60 sec | 32 sec (i) |
- Power-up time (g)| 29 sec | 120 sec | 32 sec (i) |
Notes:
a. Speed of old AGS bus is 160Mb.
b. Volatile changes represents the ability of the router to accept a
configuration change that is dynamic that only affects the current
running system and once the system is rebooted, the change
disappears.
c. CPU statistics refers to the ability of the router to provide
a monitoring facility to see what the CPU is doing and how often
it is doing it.
d. Autorestart in the event of a power failure.
e. Reboot time refers to the amount of elapsed time needed to
perform a logical restart (reboot) from the fastest available
media.
f. cisco timings are for older AGS system.
g. Power-up time refers to the amount of elapsed time needed from
the time of a power failure and recovery until the router is up and
operational.
h. Only available for DECnet and OSPF, and only for a subset of
available parameters.
i. Booting via Proteon's Intergrated Boot Device, with running
diagnostics.
2. Interfaces (a) | | | |
- Ethernet | | | |
(802.3 10Base5) | 24x10Mb | 8x10Mb | 7x10Mb |
- Thin Ethernet (b)| | | |
(802.3 10Base2) | No | 8x10Mb | No |
- 4Mb Token Ring | 3x4Mb (i) | 4x4Mb | 7x4Mb |
- 16Mb Token Ring | Rel 8.2 (j) | Rel 5.40 (c) | No |
- RS232 | 24x64kb | 16x64kb | 14x64kb |
- RS449 | 12x64kb | 16x64kb | 14x64kb |
- V.35 | 12x64kb | 16x64kb | 14x64kb |
- T1 | 12x1.544Mb | 8x1.544Mb | 14x1.544Mb |
- CEPT DS1 (2Mb) | 12x2Mb | 8x2Mb | 12x2Mb |
- FDDI | 2x100Mb | Rel 5.50 (d) | 2x100Mb |
- DAS (Dual) (e)| Yes | Yes | Yes |
- SAS (Single) | Yes | No | Yes |
- Ultranet | Rel 8.2 (k)| | |
- X.25 | | | |
- Max # of VCs | Unlimited (f)| 254 | 255 |
- Card types (g) | 6E, 1E2S, | 2E, 1E1S, | 1E, 2S, 4S, |
per slot | 2E2S, 4S, | 1E2S, 2E2S, | 1TR, .5F |
| 1TR, 1F (h)| 1TR2S, 4S, | |
| | 1TR | |
Notes:
a. Each interface subsection represents the maximum number of LANs
or WANS that can be configured for that particular subsection.
It is possible to "mix and match" various subsections by reducing
the upper limit.
b. Thin Ethernet refers to a standard BNC connector available directly
on the router.
c. 4x16Mb.
d. 1x100Mb.
e. Dual is also known as Type A and Single is also known as Type B.
f. Depends on memory limitations.
g. Card types: E: Ethernet, S: Serial/Synchronous line
TR: Token-Ring, F: FDDI
h. The 6E and 1F cards are for the faster cBus only.
i. The AGS can take 4 Token Rings while the AGS+ can only take 3.
j. To be supported in later release of Version 8.2.
k. Ultranet support will be in a later release of 8.2 but will
only support a 125Mb full-duplex connection to Ultranet's 1Gb LAN.
3. Interface part II | | | |
- Frame Relay (a) | Rel 8.2 | | |
- Ethernet | | | |
encapsulation | | | |
- Standard v2.0 | Yes | | Yes |
- IEEE 802.3 | Yes | | Yes |
- SNAP 802.2 | | | |
(RFC1042) | Yes | Yes | No |
- Serial | | | |
encapsulation | | | |
- HDLC | Yes | | Yes |
- LAPB | Yes | | No |
- PPP (RFC1134) | Yes | | |
- DDCMP | No | No | No |
- X.25 | Yes | | Yes |
- SVC | Yes | Yes | Yes |
- PVC | Yes | Yes | Yes |
- Encryption (b) | Pulse-time | | |
- Filtering by | | | |
source/dest | Yes | Yes | Yes |
Notes:
a. CCITT standards Q.931 (Frame Relay) and I.122 (Lap-D)
b. Encryption refers to the ability of the router to compensate for
encrypting devices on various interfaces or circuits.
c. For CLNP only.
4. IP | | | |
- Subnetting | | | |
(RFC950) | Yes | Yes | Yes |
- ARP (RFC826) | Yes | Yes | Yes |
- RARP (RFC903) | Yes | No | No |
- BOOTP (RFC951) | Yes | No | No |
- proxy ARP | | | |
(RFC1027) | Yes | Yes | Yes |
- ICMP | Yes | Yes | Yes |
- Name-server | Yes | No | No |
- Accounting | Yes | No | No |
- MTU | Yes | No | No |
- Security - IPSO | Yes | No | |
- Static routing | Yes | Yes | Yes |
- Source routing | Yes | No | Yes |
- Filters | | | |
- source/dest | Yes | Yes | Yes |
- TCP | Yes | | |
- UDP | Yes | | |
- ICMP | Yes | | |
- by protocol (b)| Yes (a) | Yes | |
- Routing protocols| | | |
- RIP (RFC1058) | Yes | Yes | Yes |
- EGP (RFC904) | Yes | Yes | Yes |
- BGP (RFC1105) | Yes | No | |
- Proprietary | IGRP | eRIP | No |
- Filtering | Yes | No | Yes |
- Default routes | Yes | Yes | Yes |
- OSPF | Rel 9.0 | Rel 5.6 | Yes |
Notes:
a. Can be done but is difficult and requires advanced knowledge of the
specific protocols.
b. Filtering by protocol can also be viewed as filtering by port
number.
5. DECNET | | | |
- Phase IV Router | Yes | Yes | Yes |
- Area Router | Yes | No | Yes |
- Phase IV+ (a) | Rel 8.2 | No | |
- Phase IV-V | | | |
Transitional gty | Rel 8.2 | | |
- Phase V | Yes (b) | No | Yes (b) |
- Address xlation | | | |
gateway (c) | Yes | No | No |
- NCP | | | |
- area-max-cost | Yes | Yes | Yes |
- area-max-hops | Yes | Yes | Yes |
- max-address | Yes | Yes | Yes |
- max-area | Yes | Yes | Yes |
- max-cost | Yes | Yes | Yes |
- max-hops | Yes | Yes | Yes |
- max-visits | Yes | Yes | Yes |
- router-priority| Yes | Yes | Yes (e) |
- hello-timer | Yes | Yes | Yes |
- routing-timer | Yes | Yes | Yes |
- Filtering | | | |
- source/dest | Yes | No | Yes |
- by protocol | No | No | No |
- by object | No | No | No |
- routing | Yes (d) | No | Yes (d) |
- MOP | Bridged | Bridged | Yes (f) |
- Static routing | No | No | No |
- Max routing table| 1023 | 1023 | 1023 |
- Max # of broad. | | | |
router adjencency| 32 | | |
Notes:
a. Phase IV+ refers to path-split capability. This means "normal" and
not "interim". Normal allows out-of-sequence packets to arrive.
Interim does not allow out-of-sequence packets to arrive.
b. cisco claims that it's ISO CLNS support is compatible with Decnet
Phase V.
c. Address Translation Gateway is the ability to connect two separate
Decnet networks with overlapping addresses.
d. It is not possible to filter out of area addresses. It is only
possible to filter an entire area or addresses within one's area.
e. On a per circuit basis, as required by DECnet specs.
f. MOP System ID.
6. Bridging | | | |
- Local bridging | Yes | Yes | No |
- LAVC (a) | Yes | Yes | No |
- Remote bridging | Yes (b) | Yes | No |
- Transparent | | | |
- Learning | Yes | Yes | No |
- Spanning tree | | | |
(IEEE 802.1) | Yes | Yes | No |
- Priority (c) | Rel 8.2 | No | No |
- Filtering | | | |
- Multicast | Yes | Yes | No |
- Protocol | Yes | Yes | No |
- Source/dest | Yes | Yes (g) | No |
- Masking (d) | No | No | No |
- Load sharing | Yes (e) | Yes | |
- Token Ring | | | |
- Source route | Yes | | Yes |
- Multi-ring (f) | Yes | | No |
Notes
a. LAVC refers to the ability to act as a local bridge between two Vax
clusters using the DEC LAVC protocol.
b. cisco does not support bridging over X.25 or LAPB.
c. Priority refers to the ability to assign a priority to a specific
protocol so that that protocol is sent faster than any other
protocol over a specific circuit/interface.
d. Masking refers to the ability to specify some pattern string to be
matched within the packet, so that the user can specify almost any
filter.
e. cisco load sharing (balancing) is on a per-node basis and not on
a per packet basis. That means that over 2 parallel serial lines
the cisco will automatically allocate 50% of the learned Ethernet
addresses to one line and the other 50% to the other line.
f. Multi-ring refers to bridging between multiple Token Ring networks
(all hosts must understand RIF).
g. Wellfleet can only filter on destination address and not on source
address.
7. Other protocols | | | |
(ability to route) | | | |
- XNS | Yes (a) | Yes | Yes |
- UB derivitive | Yes | | Yes |
- Appletalk | | | |
- Phase 1 | Yes | Yes | Yes |
- Phase 2 | Rel 8.2 | Rel 5.40 | No |
- Tokentalk | Rel 8.2 | Yes | No |
- Ethertalk | Yes | Yes | Yes |
- Localtalk | No | | No |
- RTMP | Yes | Rel 5.40 | Yes |
- AARP | Yes | Rel 5.40 | Yes |
- NBP | Yes | Rel 5.40 | Yes |
- EP | Yes | Rel 5.40 | Yes |
- ATP | Yes | | Yes |
- ZIP | Yes | Rel 5.40 | Yes |
- DDP | Yes | Yes | Yes |
- ISO | | | |
- ISO 8473 CLNP | Yes | No | Yes |
- ISO 9542 ES-IS | Yes | No | Yes |
- Apollo Domain | Yes | No | Yes |
- Novell IPX | Yes (a) | Yes | Yes |
- Banyan Vines | Rel 8.2 | | |
- X.25 | Yes | Yes | Yes |
- bridging | Rel 9.0 | Yes | No |
- routing | Yes | Yes | Yes |
- switching | Yes | Yes ??? | No |
- Security | Yes (b) | | |
Notes:
a. With cisco equipment, if there are both Ethernet and Token Ring
interfaces, then DECnet cannot be run simultaneously with either
Novell IPX or XNS. This restriction will be removed in Release 8.2.
b. cisco provides filtering/permitting/denying certain packets
only for IPX, XNS and Appletalk in the section listed above.
8. Management | | | |
- Central managed | Yes | Yes | Yes |
- SNMP | | | |
- Platform | Sun 3, Sparc | Sun 3 | 80286 AT |
- External | | | |
software (b) | No (c) | No | No |
- X netmap | Yes | Yes | |
- Telnet to | | | |
device (d) | Yes | No | |
- X interactive | Yes | | |
performance | | Yes | |
- History stats | Yes | No | |
- Report writer | Yes (c) | No | |
- Alerts (e) | No | No | |
- User defined | | | |
extensions (m) | Yes | No | |
- Usage stats | Yes | Yes (f) | |
- Direct MIB access| No | Yes | |
- PING | Yes | Yes (g) | No |
- Traceroute | Yes | No | |
- Telnet | Yes (h) | Yes (i) | Yes (n) |
- MOP Remote Cons. | Rel. 8.2 | Bridged | No |
- NICE (j) | No | No | No |
- Decnet connect | No | No | No |
- Passwords (k) | Yes | Yes | Yes |
- Netview support | | | |
- Disable lines | | | |
dynamically | Yes (l) | Yes | Yes |
Notes:
b. External software refers to the need to have some external
software package available in order to run SNMP monitoring.
c. cisco requires the Sybase database system in order to run their
NMS software. This package is bundled with their NMS.
d. Ability to click on an icon on the X-11 network map and open
a telnet connection to the device in question.
e. Alerts refers to the ability to define a preset limit for a
specific MIB variable at which point the SNMP monitoring software
will present a window on top of the network map informing the
network operator of the problem.
f. Wellfleet interactive usage statistics are only for (ISO model)
level 2. Upper level statistics (such as RIP, UDP, TCP, Decnet
HELLO, ARP) are not available.
g. Wellfleet PING command stops after first failure and waits for
user response. This makes it very hard to check the total
percentage of line failures over a short period of time.
h. cisco is limited to 5 incoming Telnet sessions but has no
limitation on outgoing Telnet sessions.
i. Wellfleet Telnet is limited to one incoming and one outgoing
session.
j. NICE refers to the ability of the router to accept "SET EXECUTOR"
as well as initiate a "SET EXECUTOR" to a remote host.
k. Passwords refers to the ability to limit certain configuration and
customization options only to those users who supply a password.
l. cisco command is not an EXEC command but actually requires a
configuration change to disable a line.
m. The ability for the NMS software to add other vendor MIBs to their
database, in order to manage these particular hardware units.
n. Proteon is limited to 2 incoming and no outgoing sessions.
9. Debugging & | | | |
Monitoring | | | |
- Data-Link Layer | Yes | Yes | Yes |
- LAN | Yes | Yes | Yes |
- Link | Yes | Yes | Yes |
- Decnet | Yes | Yes | Yes |
- Tcp/Ip | Yes | Yes | Yes |
- Event log | Yes | Yes | Yes |
- Environmentals | Yes | No | No |
Notes:
a. Environmentals refers to the monitoring of variables such as
fan, power supply, memory, temperature, etc.
10. Performance (a) | | | |
- Router forward | 2917 (b) | 3757 (c) | 902 |
- Router filter (d)| 2279 (b) | 3757 | 902 |
- Bridge forward | | | |
- Bridge filter | | | |
- LAT compression | Yes | No | |
Notes:
a. Performance based on 256 byte packets, between separate
interface cards, with no packet loss. Numbers listed are in
packets per second. Numbers based on Bradner report, Harvard
University, Sept 1989. A revised benchmark is expected sometime in
Sept 1990.
b. cisco performance numbers based on AGS and CSC2 hardware.
c. Wellfleet numbers may be higher but equipment was not able to
generate packets faster than the LN.
d. Filter is based on 10 packet filters enabled.
11. Survivability | | | |
- alternate power | | | |
supply | No | Yes (d) | No |
- standby line (a)| No | No | No |
- fault tolerant(b)| No | No | No |
- field tolerant(c)| No | No | No |
- broadcast storms | Yes | No | Yes |
Notes:
a. Standby line refers to the ability to define a line that is to be a
hot standby, in the event that the primary line goes down. The
software switches all traffic automatically to the backup line.
b. Fault tolerant refers to having redundent systems that are normally
in standby mode, and that are only called into active mode in the
event that the primary system fails. Various systems are the power
supply, the fan, the bus, the controller cards, etc.
c. Field tolerant refers to the ability to withstand harsh elements
and conditions out in the "field."
d. Alternate power supply only available in large Concentrator model.
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Tue, 02 Oct 90 15:03:34 IST From: Hank Nussbacher <HANK%TAUNIVM.BITNET@CUNYVM.CUNY.EDU> To: cisco@spot.colorado.edu, wellfleet@nstn.ns.ca, tcp-ip@nic.ddn.mil, ripe@mcsun.EU.NET, p4200@devvax.tn.cornell.edu Subject: Router scorecard V1.6
CAVEATS
-------
The following scorecard tries to compare various multi-protocol
routers. The current scorecard mainly contains information for
cisco and Wellfleet but any other vendor is welcome to send me a
complete set of manuals for their equipment so that I can analyze
and update the scorecard.
The fact of the matter is that certain features and "gotchas"
only appear when testing the actual equipment. I hope that the user
population of multi-protocol routers will assist me in making this
scorecard as comprehensive as possible so that people who follow do
not have to go through what I have gone through.
It was difficult to decide whether to include future release
notes in this scorecard. I trust the user population in the
Internet to take each promise for a "future feature" with a grain of
salt and to keep watch on the vendors that indeed they follow
through with their promises. All too often vendors state certain
features will be available in a certain release and sometimes their
deadlines slip. It is advised that people should not base their
decisions on the future release notes. [That was a long caveat].
If you have comments, suggestions, additions, or subtractions
or corrections, please send them to:
HANK@VM.TAU.AC.IL or HANK@TAUNIVM.BITNET (but not to both!)
The scorecard will be updated on a monthly basis. This report
may be freely reproduced as long as nothing is altered or removed.
If you read this report and are not connected to the Internet,
you can send your comments to:
Hank Nussbacher
Computer Center
Tel Aviv University
Ramat Aviv
Israel
[The above employer has nothing to do with this scorecard so if
something bothers you about it, I take full responsibility.]
END OF CAVEATS
--------------------------------------------------------------------
V1.6 update: Various vendors have been in contact with me but after
expressing interest in having an entry for their machine they disappear.
Other vendors have tried to change the particular hardware box that
is being compared to another box. I hope that vendors will participate
in keeping this scorecard up-to-date.
--------------------------------------------------------------------
Distribution:
cisco@spot.colorado.edu
wellfleet@nstn.ns.ca
tcpip@nic.ddn.mil
ripe@mcsun.eu.net
p4200@devvax.tn.cornell.edu
Usenet: comp.dcom.lans
--------------------------------------------------------------------
Comparison of Multiprotocol Routers
Henry Nussbacher
October 1990
Version 1.6
+--------------+--------------+---------------+
Multiprotocol | cisco AGS+ | Wellfleet LN | Proteon p4200 |
Router | Rel. 8.1(14) | Rel. 5.35 | |
+--------------+--------------+---------------+
1. General | | | |
- # of slots | 9 | 4 | 7 |
- Processor | 68020 | 68020 | 68020 |
- Memory | 4Mbyte | 4Mbyte | 2Mbyte |
- Updates via | ROM, TFTP | diskette,TFTP| diskette,TFTP |
- Speed of bus | 530Mb/sec (a)| 320Mb/sec | |
- Boot from | | | |
- ROM | Yes | No | No |
- Net-boot | | | |
- IP | Yes | No | Yes |
- Decnet (MOP) | No | No | No |
- Diskette | No | Yes | No |
- Another router | Yes | No | No |
- Volatile changes | Yes (b) | No | Yes (h) |
- CPU statistics | Yes (c) | No | Yes |
- Memory stats | Yes | No | Yes |
- Ease of install | Very easy | menu driven | |
- Documentation | Difficult | Skimpy | Clear, orderly|
- Autorestart (d) | Yes | Yes | Yes |
- Restart for | | | |
config changes | No | Yes | Yes |
- Watchdog timer | Yes | | Yes |
- Reboot time (e) | 29 sec (f) | 60 sec | 32 sec (i) |
- Power-up time (g)| 29 sec | 120 sec | 32 sec (i) |
Notes:
a. Speed of old AGS bus is 160Mb.
b. Volatile changes represents the ability of the router to accept a
configuration change that is dynamic that only affects the current
running system and once the system is rebooted, the change
disappears.
c. CPU statistics refers to the ability of the router to provide
a monitoring facility to see what the CPU is doing and how often
it is doing it.
d. Autorestart in the event of a power failure.
e. Reboot time refers to the amount of elapsed time needed to
perform a logical restart (reboot) from the fastest available
media.
f. cisco timings are for older AGS system.
g. Power-up time refers to the amount of elapsed time needed from
the time of a power failure and recovery until the router is up and
operational.
h. Only available for DECnet and OSPF, and only for a subset of
available parameters.
i. Booting via Proteon's Intergrated Boot Device, with running
diagnostics.
2. Interfaces (a) | | | |
- Ethernet | | | |
(802.3 10Base5) | 24x10Mb | 8x10Mb | 7x10Mb |
- Thin Ethernet (b)| | | |
(802.3 10Base2) | No | 8x10Mb | No |
- 4Mb Token Ring | 3x4Mb (i) | 4x4Mb | 7x4Mb |
- 16Mb Token Ring | Rel 8.2 (j) | Rel 5.40 (c) | No |
- RS232 | 24x64kb | 16x64kb | 14x64kb |
- RS449 | 12x64kb | 16x64kb | 14x64kb |
- V.35 | 12x64kb | 16x64kb | 14x64kb |
- T1 | 12x1.544Mb | 8x1.544Mb | 14x1.544Mb |
- CEPT DS1 (2Mb) | 12x2Mb | 8x2Mb | 12x2Mb |
- FDDI | 2x100Mb | Rel 5.50 (d) | 2x100Mb |
- DAS (Dual) (e)| Yes | Yes | Yes |
- SAS (Single) | Yes | No | Yes |
- Ultranet | Rel 8.2 (k)| | |
- X.25 | | | |
- Max # of VCs | Unlimited (f)| 254 | 255 |
- Card types (g) | 6E, 1E2S, | 2E, 1E1S, | 1E, 2S, 4S, |
per slot | 2E2S, 4S, | 1E2S, 2E2S, | 1TR, .5F |
| 1TR, 1F (h)| 1TR2S, 4S, | |
| | 1TR | |
Notes:
a. Each interface subsection represents the maximum number of LANs
or WANS that can be configured for that particular subsection.
It is possible to "mix and match" various subsections by reducing
the upper limit.
b. Thin Ethernet refers to a standard BNC connector available directly
on the router.
c. 4x16Mb.
d. 1x100Mb.
e. Dual is also known as Type A and Single is also known as Type B.
f. Depends on memory limitations.
g. Card types: E: Ethernet, S: Serial/Synchronous line
TR: Token-Ring, F: FDDI
h. The 6E and 1F cards are for the faster cBus only.
i. The AGS can take 4 Token Rings while the AGS+ can only take 3.
j. To be supported in later release of Version 8.2.
k. Ultranet support will be in a later release of 8.2 but will
only support a 125Mb full-duplex connection to Ultranet's 1Gb LAN.
3. Interface part II | | | |
- Frame Relay (a) | Rel 8.2 | | |
- Ethernet | | | |
encapsulation | | | |
- Standard v2.0 | Yes | | Yes |
- IEEE 802.3 | Yes | | Yes |
- SNAP 802.2 | | | |
(RFC1042) | Yes | Yes | No |
- Serial | | | |
encapsulation | | | |
- HDLC | Yes | | Yes |
- LAPB | Yes | | No |
- PPP (RFC1134) | Yes | | |
- DDCMP | No | No | No |
- X.25 | Yes | | Yes |
- SVC | Yes | Yes | Yes |
- PVC | Yes | Yes | Yes |
- Encryption (b) | Pulse-time | | |
- Filtering by | | | |
source/dest | Yes | Yes | Yes |
Notes:
a. CCITT standards Q.931 (Frame Relay) and I.122 (Lap-D)
b. Encryption refers to the ability of the router to compensate for
encrypting devices on various interfaces or circuits.
c. For CLNP only.
4. IP | | | |
- Subnetting | | | |
(RFC950) | Yes | Yes | Yes |
- ARP (RFC826) | Yes | Yes | Yes |
- RARP (RFC903) | Yes | No | No |
- BOOTP (RFC951) | Yes | No | No |
- proxy ARP | | | |
(RFC1027) | Yes | Yes | Yes |
- ICMP | Yes | Yes | Yes |
- Name-server | Yes | No | No |
- Accounting | Yes | No | No |
- MTU | Yes | No | No |
- Security - IPSO | Yes | No | |
- Static routing | Yes | Yes | Yes |
- Source routing | Yes | No | Yes |
- Filters | | | |
- source/dest | Yes | Yes | Yes |
- TCP | Yes | | |
- UDP | Yes | | |
- ICMP | Yes | | |
- by protocol (b)| Yes (a) | Yes | |
- Routing protocols| | | |
- RIP (RFC1058) | Yes | Yes | Yes |
- EGP (RFC904) | Yes | Yes | Yes |
- BGP (RFC1105) | Yes | No | |
- Proprietary | IGRP | eRIP | No |
- Filtering | Yes | No | Yes |
- Default routes | Yes | Yes | Yes |
- OSPF | Rel 9.0 | Rel 5.6 | Yes |
Notes:
a. Can be done but is difficult and requires advanced knowledge of the
specific protocols.
b. Filtering by protocol can also be viewed as filtering by port
number.
5. DECNET | | | |
- Phase IV Router | Yes | Yes | Yes |
- Area Router | Yes | No | Yes |
- Phase IV+ (a) | Rel 8.2 | No | |
- Phase IV-V | | | |
Transitional gty | Rel 8.2 | | |
- Phase V | Yes (b) | No | Yes (b) |
- Address xlation | | | |
gateway (c) | Yes | No | No |
- NCP | | | |
- area-max-cost | Yes | Yes | Yes |
- area-max-hops | Yes | Yes | Yes |
- max-address | Yes | Yes | Yes |
- max-area | Yes | Yes | Yes |
- max-cost | Yes | Yes | Yes |
- max-hops | Yes | Yes | Yes |
- max-visits | Yes | Yes | Yes |
- router-priority| Yes | Yes | Yes (e) |
- hello-timer | Yes | Yes | Yes |
- routing-timer | Yes | Yes | Yes |
- Filtering | | | |
- source/dest | Yes | No | Yes |
- by protocol | No | No | No |
- by object | No | No | No |
- routing | Yes (d) | No | Yes (d) |
- MOP | Bridged | Bridged | Yes (f) |
- Static routing | No | No | No |
- Max routing table| 1023 | 1023 | 1023 |
- Max # of broad. | | | |
router adjencency| 32 | | |
Notes:
a. Phase IV+ refers to path-split capability. This means "normal" and
not "interim". Normal allows out-of-sequence packets to arrive.
Interim does not allow out-of-sequence packets to arrive.
b. cisco claims that it's ISO CLNS support is compatible with Decnet
Phase V.
c. Address Translation Gateway is the ability to connect two separate
Decnet networks with overlapping addresses.
d. It is not possible to filter out of area addresses. It is only
possible to filter an entire area or addresses within one's area.
e. On a per circuit basis, as required by DECnet specs.
f. MOP System ID.
6. Bridging | | | |
- Local bridging | Yes | Yes | No |
- LAVC (a) | Yes | Yes | No |
- Remote bridging | Yes (b) | Yes | No |
- Transparent | | | |
- Learning | Yes | Yes | No |
- Spanning tree | | | |
(IEEE 802.1) | Yes | Yes | No |
- Priority (c) | Rel 8.2 | No | No |
- Filtering | | | |
- Multicast | Yes | Yes | No |
- Protocol | Yes | Yes | No |
- Source/dest | Yes | Yes (g) | No |
- Masking (d) | No | No | No |
- Load sharing | Yes (e) | Yes | |
- Token Ring | | | |
- Source route | Yes | | Yes |
- Multi-ring (f) | Yes | | No |
Notes
a. LAVC refers to the ability to act as a local bridge between two Vax
clusters using the DEC LAVC protocol.
b. cisco does not support bridging over X.25 or LAPB.
c. Priority refers to the ability to assign a priority to a specific
protocol so that that protocol is sent faster than any other
protocol over a specific circuit/interface.
d. Masking refers to the ability to specify some pattern string to be
matched within the packet, so that the user can specify almost any
filter.
e. cisco load sharing (balancing) is on a per-node basis and not on
a per packet basis. That means that over 2 parallel serial lines
the cisco will automatically allocate 50% of the learned Ethernet
addresses to one line and the other 50% to the other line.
f. Multi-ring refers to bridging between multiple Token Ring networks
(all hosts must understand RIF).
g. Wellfleet can only filter on destination address and not on source
address.
7. Other protocols | | | |
(ability to route) | | | |
- XNS | Yes (a) | Yes | Yes |
- UB derivitive | Yes | | Yes |
- Appletalk | | | |
- Phase 1 | Yes | Yes | Yes |
- Phase 2 | Rel 8.2 | Rel 5.40 | No |
- Tokentalk | Rel 8.2 | Yes | No |
- Ethertalk | Yes | Yes | Yes |
- Localtalk | No | | No |
- RTMP | Yes | Rel 5.40 | Yes |
- AARP | Yes | Rel 5.40 | Yes |
- NBP | Yes | Rel 5.40 | Yes |
- EP | Yes | Rel 5.40 | Yes |
- ATP | Yes | | Yes |
- ZIP | Yes | Rel 5.40 | Yes |
- DDP | Yes | Yes | Yes |
- ISO | | | |
- ISO 8473 CLNP | Yes | No | Yes |
- ISO 9542 ES-IS | Yes | No | Yes |
- Apollo Domain | Yes | No | Yes |
- Novell IPX | Yes (a) | Yes | Yes |
- Banyan Vines | Rel 8.2 | | |
- X.25 | Yes | Yes | Yes |
- bridging | Rel 9.0 | Yes | No |
- routing | Yes | Yes | Yes |
- switching | Yes | Yes ??? | No |
- Security | Yes (b) | | |
Notes:
a. With cisco equipment, if there are both Ethernet and Token Ring
interfaces, then DECnet cannot be run simultaneously with either
Novell IPX or XNS. This restriction will be removed in Release 8.2.
b. cisco provides filtering/permitting/denying certain packets
only for IPX, XNS and Appletalk in the section listed above.
8. Management | | | |
- Central managed | Yes | Yes | Yes |
- SNMP | | | |
- Platform | Sun 3, Sparc | Sun 3 | 80286 AT |
- External | | | |
software (b) | No (c) | No | No |
- X netmap | Yes | Yes | |
- Telnet to | | | |
device (d) | Yes | No | |
- X interactive | Yes | | |
performance | | Yes | |
- History stats | Yes | No | |
- Report writer | Yes (c) | No | |
- Alerts (e) | No | No | |
- User defined | | | |
extensions (m) | Yes | No | |
- Usage stats | Yes | Yes (f) | |
- Direct MIB access| No | Yes | |
- PING | Yes | Yes (g) | No |
- Traceroute | Yes | No | |
- Telnet | Yes (h) | Yes (i) | Yes (n) |
- MOP Remote Cons. | Rel. 8.2 | Bridged | No |
- NICE (j) | No | No | No |
- Decnet connect | No | No | No |
- Passwords (k) | Yes | Yes | Yes |
- Netview support | | | |
- Disable lines | | | |
dynamically | Yes (l) | Yes | Yes |
Notes:
b. External software refers to the need to have some external
software package available in order to run SNMP monitoring.
c. cisco requires the Sybase database system in order to run their
NMS software. This package is bundled with their NMS.
d. Ability to click on an icon on the X-11 network map and open
a telnet connection to the device in question.
e. Alerts refers to the ability to define a preset limit for a
specific MIB variable at which point the SNMP monitoring software
will present a window on top of the network map informing the
network operator of the problem.
f. Wellfleet interactive usage statistics are only for (ISO model)
level 2. Upper level statistics (such as RIP, UDP, TCP, Decnet
HELLO, ARP) are not available.
g. Wellfleet PING command stops after first failure and waits for
user response. This makes it very hard to check the total
percentage of line failures over a short period of time.
h. cisco is limited to 5 incoming Telnet sessions but has no
limitation on outgoing Telnet sessions.
i. Wellfleet Telnet is limited to one incoming and one outgoing
session.
j. NICE refers to the ability of the router to accept "SET EXECUTOR"
as well as initiate a "SET EXECUTOR" to a remote host.
k. Passwords refers to the ability to limit certain configuration and
customization options only to those users who supply a password.
l. cisco command is not an EXEC command but actually requires a
configuration change to disable a line.
m. The ability for the NMS software to add other vendor MIBs to their
database, in order to manage these particular hardware units.
n. Proteon is limited to 2 incoming and no outgoing sessions.
9. Debugging & | | | |
Monitoring | | | |
- Data-Link Layer | Yes | Yes | Yes |
- LAN | Yes | Yes | Yes |
- Link | Yes | Yes | Yes |
- Decnet | Yes | Yes | Yes |
- Tcp/Ip | Yes | Yes | Yes |
- Event log | Yes | Yes | Yes |
- Environmentals | Yes | No | No |
Notes:
a. Environmentals refers to the monitoring of variables such as
fan, power supply, memory, temperature, etc.
10. Performance (a) | | | |
- Router forward | 2917 (b) | 3757 (c) | 902 |
- Router filter (d)| 2279 (b) | 3757 | 902 |
- Bridge forward | | | |
- Bridge filter | | | |
- LAT compression | Yes | No | |
Notes:
a. Performance based on 256 byte packets, between separate
interface cards, with no packet loss. Numbers listed are in
packets per second. Numbers based on Bradner report, Harvard
University, Sept 1989. A revised benchmark is expected sometime in
Sept 1990.
b. cisco performance numbers based on AGS and CSC2 hardware.
c. Wellfleet numbers may be higher but equipment was not able to
generate packets faster than the LN.
d. Filter is based on 10 packet filters enabled.
11. Survivability | | | |
- alternate power | | | |
supply | No | Yes (d) | No |
- standby line (a)| No | No | No |
- fault tolerant(b)| No | No | No |
- field tolerant(c)| No | No | No |
- broadcast storms | Yes | No | Yes |
Notes:
a. Standby line refers to the ability to define a line that is to be a
hot standby, in the event that the primary line goes down. The
software switches all traffic automatically to the backup line.
b. Fault tolerant refers to having redundent systems that are normally
in standby mode, and that are only called into active mode in the
event that the primary system fails. Various systems are the power
supply, the fan, the bus, the controller cards, etc.
c. Field tolerant refers to the ability to withstand harsh elements
and conditions out in the "field."
d. Alternate power supply only available in large Concentrator model.
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 18:56:14 GMT From: bu.edu!buit13!kwe@uunet.uu.net (Kent England) To: tcp-ip@nic.ddn.mil Subject: Re: Maintainability of TELNET ...
In article <9010021049.AA06180@WLV.IMSD.CONTEL.COM> mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: >... > 1. Do routers generally have the capability to re-route traffic over > an alternate circuit? ... > 4. Would fudging IP, TCP, or TELNET timers by a "crypto resync constant" > alleviate problems? > One problem with routing fallback has to do with the time constants of the routing protocols (and link level fault protocols, if any) and the time constant of the failure. Sounds to me like crypto sync loss is a fast time constant sort of error. This begs the question of whether the routing protocol should spend the time required to re-route or whether it should hold off and wait for the link to come back up. With the advent of open link state protocols which converge "instantly", perhaps this point is becoming moot, but with distance vector protocols it is very hard to deal with link level state "flapping" side effects and still keep routing traffic down. Same thinking applies to TCP or Telnet timers. Should they wait a short time or a long time? How should they treat redirects and black holes? I think that should be up to the application, since mail usually has a different idea than telnet would. Put me in the "hate TCP/IP keepalives" camp. --Kent
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 20:58:54 GMT From: crash!ncr-sd!ncrcae!wingo@nosc.mil (Dave Wingo) To: tcp-ip@nic.ddn.mil Subject: network file backup
Does anyone know of a network based (TCP/IP) file system back-up/restore product that is currently available for UNIX 5.3 or 5.4. How about one that would also be available on OS/2 based systems..... We are very interested in this type of product.... Thanks in advance for your help..... David Wingo, NCR Corp System 3000 voice 803-791-6476 email: wingo@Columbia.NCR.COM
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 21:46:58 GMT From: julius.cs.uiuc.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!wls@apple.com (Bill Stapleton) To: tcp-ip@nic.ddn.mil Subject: IBM 9000 TCP/IP, lpr?
Another campus entity is looking into purchasing an IBM 9000 system, which
would run VM, and comes with some sort of TCP/IP package. They want to be
sure it works with our (BSD) network, especially for printing. Does anybody
know if it's possible for an IBM 9000 VM system to talk Berkeley lpr protocol?
Any information is most appreciated.
--
Bill Stapleton
wls@csd4.csd.uwm.edu
uwmcsd4!wls
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 90 00:58:36 GMT From: snorkelwacker!usc!zaphod.mps.ohio-state.edu!uwm.edu!srcsip!pserv!stevem@bloom-beacon.mit.edu (Steve Mestad) To: tcp-ip@nic.ddn.mil Subject: Looking for Rarpd
I am looking for source for the rarp daemon. I would like it for HP-UX 7.0 on the HP 9000 series 300 systems but at this point I would be willing to take any source and hope for the best. Please let me know where I can find this beastie. Thanks. SM stevem@cfsmo.honeywell.com stevem%pserv@src.honeywell.com (if the above is ill from your location)
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Wed, 03 Oct 90 08:34:49 MDT From: Greg Satz <satz@cisco.com> To: brooks@apple.com (Kevin Brooks) Cc: tcp-ip@nic.ddn.mil Subject: Re: HP TCP/IP router/bridge?
The cisco router will do this and has for the last three year. Drop a note to customer-service@cisco.com for more information. Greg
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Wed, 3 Oct 90 11:42:22 -0500 From: jbvb@ftp.com (James B. Van Bokkelen) To: mailrus!sharkey!cfctech!alexb@uunet.uu.net (Alex Beylin) Cc: tcp-ip@nic.ddn.mil Subject: Re: SLIP, IP Routers and Named Pipes
If you want Named Pipes, you need LAN Manager, which means Netbios, which means RFC 1001/1002 if you want it over TCP/IP. I don't know of any RFC 1001/1002 Netbioses which implement "p-nodes" or "m-nodes", so you can't use a conventional router. TWG has a hack which uses static client configuration to avoid this problem, but a cleaner alternative (IMHO) is to use the cisco SLIP concentrator, which keeps the clients on the same net/subnet as its attached ethernet (fine as long as your servers are on that ethernet). If you use the latter approach, you can use our PC/TCP as well as TWG's WIN/PC. I can never remember if Beame & Whiteside has an RFC Netbios, but none of the others (Excelan, U-B, CMC, Interlan, Bridge) support SLIP. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Wed, 03 Oct 90 13:12:12 PST From: "Donald R. Proctor" <SPGDRP%UCCVMA.UCOP.EDU@CORNELLC.cit.cornell.edu> To: Alex Beylin <mailrus!sharkey!cfctech!alexb@UUNET.UU.NET>, tcp-ip@nic.ddn.mil Subject: Re: SLIP, IP Routers and Named Pipes
>A project have come up around here that require multiple >PCs to get dial-in access to the TCP/IP network. One of the >major requirements is support for Named Pipes down to the PC. >Current plan is to use SLIP and a router with dial-in ports. > >Would someone care to recommend a PC package that would do good >SLIP emulation and a router that would be suitable for this job? > Alex: We intend on implementing a similar system here, although we don't have the named pipes requirement. We have a cisco terminal server that can be configured with several dial-in ports. The software angle is a bit more complex. As I understand it, the remote PC user will need to use a communications package like kermit or xmodem to connect to the terminal server. A commercial (such as FTP's PC/TCP) or public domain (such as NCSA telnet) TCP-IP package can then be run over SLIP. FTP's package can be ordered with SLIP, and there is a SLIP driver in Clarkson's pd packet driver distribution. I should point out that cisco's box can provide the telnet connection itself, so that a remote PC user can dial in and start a telnet session from the server without having the TCP-IP software installed on the PC. However, if need 3270 emulation (as we do), the current release of the cisco's software won't do the job. I hope my more knowledgeable colleagues will correct me if I have made any egregious errors... Don Proctor <spgdrp@uccvma.ucop.edu> Information Systems & Computing <spgdrp@uccvma.bitnet> University of California 415/987-0356
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 90 05:27:08 GMT From: munnari.oz.au!mtiame!ubeaut!mwp@uunet.uu.net (Michael Paddon) To: tcp-ip@nic.ddn.mil Subject: Re: TCP segment size -- user defined?
From article <266@aldetec.oz.au>, by mawson@aldetec.oz.au (Graeme Mawson): > > We are presently experimenting with the TCP/IP protcol suite over an Ethernet > LAN. A useful guide to TCP/IP by Comer seems to suggest that TCP segment > size is user-definable. Is this true? Does anyone know how to define it? It surely is. On BSD based systems, the macro TCP_MSS is defined in /usr/include/netinet/tcp.h. This may be changed with impunity since the negotiation undergone at connection setup time chooses the smaller of the segment sizes supported by each implementation. There is not much point setting TCP_MSS to be greater than (maximum IP packet size - IP header size - TCP header size) [536 octets] since IP fragmentation will take place. Receipt of a fragmented packet is an all or nothing proposition; a good thing to avoid for throughput reasons. In general, the BSD TCP parameters in tcp.h and tcp_timers.h are close to optimal for ethernet (default RTT is a little pessimistic, but that is so the latter stages of backoff work properly). I found I had to do a fair bit of tuning to get everything right for a SLIP environment with flakey link hardware. Michael ------------------------------------------------------------------- | | Internet: paddon@meo78b.enet.dec.com | | | ACSnet: mwp@ubeaut.oz.au | | Michael Paddon | ACSnet: mwp@munnari.oz.au | | | EasyNet: meo78b::paddon | | | Voice: +61 3 895 9392 | -------------------------------------------------------------------
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Wed, 03 Oct 90 13:36:01 PST From: "Donald R. Proctor" <SPGDRP%UCCVMA.UCOP.EDU@CORNELLC.cit.cornell.edu> To: tcp-ip-relay@NIC.DDN.MIL, tcp-ip@nic.ddn.mil Subject: Re: Is there a program like telnet, but driven by a script?
>I need to duplicate UNIX-to-UNIX rsh functionality going UNIX-to-VMS. >I am running a Sun Sparcstation and can communicate with the VAX using >telnet and ftp via an ULTRIX gateway (the VAX only runs DECNET). One >solution to my problem would be a telnet-like program which accepts a >script containing expect/send pairs much like UUCP and some PC >communications programs. Does such a program exist? > >I would also appreciate any suggestions of alternate solutions. > We run TGV's MultiNet on our VMS machine. It does a remarkable job of bringing Unix/Ultrix connectivity to the VMS world. Don Proctor <spgdrp@uccvma.ucop.edu> Information Systems & Computing <spgdrp@uccvma.bitnet> University of California 415/987-0356 Office of the President The opinions expressed do not necessarily reflect the opions of my employer. The University of California does not endorse any commercial products mentioned.
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Wed 3 Oct 90 14:26:43-PDT From: VANCE@TGV.COM (Icarus) To: sdd.hp.com!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!rphroy!cfctech!sharkey!fmsrl7!slee01!hugh@ucsd.edu Cc: tcp-ip@nic.ddn.mil Subject: Re: Is there a program like telnet, but driven by a script?
>I need to duplicate UNIX-to-UNIX rsh functionality going UNIX-to-VMS. >I am running a Sun Sparcstation and can communicate with the VAX using >telnet and ftp via an ULTRIX gateway (the VAX only runs DECNET). One >solution to my problem would be a telnet-like program which accepts a >script containing expect/send pairs much like UUCP and some PC >communications programs. Does such a program exist? One solution would be to put a TCP/IP package that supports rsh on your VAX. There are several that do (MultiNet, WIN/TCP, Fusion, possibly others...) Scripted TELNET is another issue. I don't know of any of the IP for VMS (or for other platforms for that matter) that support this. -----Stuart -------
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Wed, 3 Oct 90 18:48 MST From: WIMMER@Arizona.edu To: TCP-IP@NIC.DDN.MIL Subject: UN-Subscribe
Apologies to the Network for posting this here.
Please drop me from this list.
Terry Wimmer
Wimmer@rvax.ccit.arizona.edu (old account address)
or
Wimmer@Arizona.edu (current address)
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 90 16:24:46 GMT From: usc!snorkelwacker!ai-lab!ai.mit.edu!dms@ucsd.edu (David M. Siegel) To: tcp-ip@nic.ddn.mil Subject: Heathkit Weather Computer (IDW5001)
We have just ordered a Heathkit IDW5001 weather computer. Our plans are to make the readings from the computer available over our network. It would be nice to use a "standard" weather TCP/UDP protocol for this purpose. Ideally, all Internet sites with weather data could support this protocol. The protocol should be extensible, since it is hard to anticipate all types of weather data that people might have. I'm wondering, does such a protocol exist? Also, does anyone else have IDW5001 weather computers. We'd be interested in obtaining your software to interface to the computer, and for client programs. Our plans are to run it on a Unix box, connected via the RS232 port. -Dave
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 90 19:23:49 GMT From: eru!hagbard!sunic!dkuug!resam!andrew@bloom-beacon.mit.edu (Leif Andrew Rump) To: tcp-ip@nic.ddn.mil Subject: Does anybody know LM-X or Lackman?
Do any one of you know where we can get LM-X (Lan Manager) software for the 386-UNIX System V rel 4 running on top of TCP/IP. We would also like to know the address of a company called Lackman who supplies TCP/IP software for UNIX systems. Thank you in advance Leif Andrew Leif Andrew Rump, AmbraSoft A/S, Stroedamvej 50, DK-2100 Copenhagen OE, Denmark UUCP: andrew@ambra.dk, phone: +45 39 27 11 77 / Currently at Scandinavian Airline Systems =======/ UUCP: andrew@resam.dk, phone: +45 32 32 22 79 \ SAS, RESAM Project Office, CPHML-V, P.O.BOX 150, DK-2770 Kastrup, Denmark > > Read oe as: o <backspace> / (slash) and OE as O <backspace> / (slash) < <
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 90 20:07:49 GMT From: att!cbnewsk!lih@ucbvax.Berkeley.EDU (andrew.a.lih) To: tcp-ip@nic.ddn.mil Subject: Re: quick check for available host
In article <771@tiamat.fsc.com>, jim@tiamat.fsc.com (Jim O'Connor) writes: > What is a quick way for a shell script to find out if a networked > host is currently available? If you just want to know if the host is alive, then the 'ping' program will suffice. It basically sends packets over to the host you specify and returns the round trip time for the packet. Most of the time it is used to detect delays and transmission times, but in this case you can use it to see if the machine is up. /lih AT&T Bell Labs Middletown, NJ
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 90 20:15:35 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!kriger@ucsd.edu (Sidney Kriger) To: tcp-ip@nic.ddn.mil Subject: Re: SLIP, IP Routers and Named Pipes
In article <8879@allen.ingr.com> usenet@b11.ingr.com (Usenet Network) writes: >For routers see cisco or there are terminal servers that support SLIP. >I worked for an outfit that sold cisco and the company I work for now >sells the Encore Annex II. > >encore (terminal server with slip) >617-460-0500 > > * John E. Allen - Intergraph Corporation - (205) 730-8627 * > * System Sales Support * > * ingr!b23b!allen!jallen@uunet.uu.net * Xylogics now manufactures the Annex II terminal server and has for about 2 years, not Encore. 800-225-3317 Sidney Kriger Xylogics, Inc. voice: 617-272-8140 53 Third Ave. fax: 617-273-5392 Burlington, MA 01803 email: kriger@Xylogics.COM
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 90 20:27:45 GMT From: bcstec!bcstec.uucp@uunet.uu.net (Charles Derykus) To: tcp-ip@nic.ddn.mil Subject: Nameservice questions
I have several questions regarding nameserver:
(1) Can nameservice resolve reverse translation queries "up the tree"
towards the root domain if the domains of the requested node and
the requesting node are at the same level, e.g.
Nameserver Node Domain
--------------- ------
cabbage vegetable
parsley herb.vegetable
carrot underground.vegetable
can "carrot" ask "cabbage" to reverse translate an I.P. in
"herb.vegetable" and if so, how?
We have gotten it to work only by specifying in the named.boot
on carrot a line like the one below where 192.33.72.10 is the
I.P. of parsley
secondary 72.33.192.in-addr-arpa 192.33.72.10 herb.bak
In other words, carrot seems to have to know that parsley is
authoratative for the herb.vegetable domain and doesn't seem to be
able to pull it down from a server such as cabbage in a higher
domain.
(2) A named.rev with multiple $ORIGIN lines worked fine on out primary
nameserver for a while but then the secondary nameserver starting
breaking. The only way we get it working now is by specifying separate
reverse translation files for each $ORIGIN line, e.g.
in the primary's named.boot:
primary 207.128.in-addr.arpa herb.207.128.in-addr.arpa
primary 79.33.192.in-addr.arpa herb.79.33.192.in-addr.arpa
in the secondary's named.boot: (primary's I.P. is 128.207.254.44)
secondary 207.128.in-addr.arpa 128.207.254.44
secondary 79.33.192.in-addr.arpa 128.207.254.44
Does nameservice break if these separate reverse files exceed some
limit- either in number of files or memory capacity- as the
"named.rev" file apparently does?
Thanks for listening. Any help greatly appreciated.
Charles DeRykus Internet: ced@bcstec.boeing.com
Boeing Computer Services UUCP: ...!uunet!bcstec!ced
Renton, WA. M/S 6R-37 (206) 938-4520 (home)
(206) 234-9223
-----------[000035][next][prev][last][first]----------------------------------------------------
Date: 3 Oct 90 21:12:12 GMT
From: SPGDRP@UCCVMA.UCOP.EDU ("Donald R. Proctor")
To: comp.protocols.tcp-ip
Subject: Re: SLIP, IP Routers and Named Pipes>A project have come up around here that require multiple >PCs to get dial-in access to the TCP/IP network. One of the >major requirements is support for Named Pipes down to the PC. >Current plan is to use SLIP and a router with dial-in ports. > >Would someone care to recommend a PC package that would do good >SLIP emulation and a router that would be suitable for this job? > Alex: We intend on implementing a similar system here, although we don't have the named pipes requirement. We have a cisco terminal server that can be configured with several dial-in ports. The software angle is a bit more complex. As I understand it, the remote PC user will need to use a communications package like kermit or xmodem to connect to the terminal server. A commercial (such as FTP's PC/TCP) or public domain (such as NCSA telnet) TCP-IP package can then be run over SLIP. FTP's package can be ordered with SLIP, and there is a SLIP driver in Clarkson's pd packet driver distribution. I should point out that cisco's box can provide the telnet connection itself, so that a remote PC user can dial in and start a telnet session from the server without having the TCP-IP software installed on the PC. However, if need 3270 emulation (as we do), the current release of the cisco's software won't do the job. I hope my more knowledgeable colleagues will correct me if I have made any egregious errors... Don Proctor <spgdrp@uccvma.ucop.edu> Information Systems & Computing <spgdrp@uccvma.bitnet> University of California 415/987-0356
-----------[000036][next][prev][last][first]----------------------------------------------------
Date: 3 Oct 90 21:36:01 GMT
From: SPGDRP@UCCVMA.UCOP.EDU ("Donald R. Proctor")
To: comp.protocols.tcp-ip
Subject: Re: Is there a program like telnet, but driven by a script?>I need to duplicate UNIX-to-UNIX rsh functionality going UNIX-to-VMS. >I am running a Sun Sparcstation and can communicate with the VAX using >telnet and ftp via an ULTRIX gateway (the VAX only runs DECNET). One >solution to my problem would be a telnet-like program which accepts a >script containing expect/send pairs much like UUCP and some PC >communications programs. Does such a program exist? > >I would also appreciate any suggestions of alternate solutions. > We run TGV's MultiNet on our VMS machine. It does a remarkable job of bringing Unix/Ultrix connectivity to the VMS world. Don Proctor <spgdrp@uccvma.ucop.edu> Information Systems & Computing <spgdrp@uccvma.bitnet> University of California 415/987-0356 Office of the President The opinions expressed do not necessarily reflect the opions of my employer. The University of California does not endorse any commercial products mentioned.
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 90 21:48:47 GMT From: issm!wraith.wtp.contel.com!powell@uunet.uu.net (Mike Powell "CFS Net Ops") To: tcp-ip@nic.ddn.mil Subject: Network Monitors/Managment ... again (repost)
Since the first one appears to have gone to /dev/null due to a missing
Date:, we will try again....
We are in the process of evaluating Network Monitor/Management packages.
I missed most of the previous discussion.
We have looked at/read glossies from Cisco, Cabletron, Excelan (Novell),
Silicon Graphics, ACC, and Micro Technologies (inhouse demo, high
pressure salesman). I've only read a short article about the HP stuff.
MT is the only one we have taken an in-depth look at, but we are
working on others.
Three Questions:
1) anybody out there dealt with or have installed and operating any of
these packages? how was the sales and technical staff? MT seems like
they will eventually have a good product, but the level of the
visible technical personnel is less than what I would expect of a
major player in this game.
2) are the respective companies product groups reading this stuff?
I would like to hear from you (I've already heard from two).
3) has anyone considered piecing one entity from one vendor with another?
Direct replys appreciated, I will post a summary.
Thanks,
Mike
--
Mike Powell PPASEL
"arp, arp, arp" The mating call of the lonely packet.
Disclaimer: I speak for myself. No relation to the DUAT folks.
internet: powell@wraith.wtp.contel.com Usenet: {contel-fss}!powell
-----------[000038][next][prev][last][first]---------------------------------------------------- From: ljm@mercury.twg.com To: tcp-ip@nic.ddn.mil Cc: Subject: Re: SLIP, IP Routers and Named Pipes
>A project have come up around here that require multiple >PCs to get dial-in access to the TCP/IP network. One of the >major requirements is support for Named Pipes down to the PC. >Current plan is to use SLIP and a router with dial-in ports. > >Would someone care to recommend a PC package that would do good >SLIP emulation and a router that would be suitable for this job? > Given your Named Pipes requirement, you actually have a much more fun problem to solve. You need a TCP/IP with support for not only SLIP but also NetBIOS over TCP/IP which works through IP routers. I think we are currently the only TCP/IP product with both, but I think FTP Software will be able to provide a NetBIOS which works through routers in the near to medium future. By the way, I do have to ask. Why Named Pipes? enjoy, leo j mclaughlin iii ljm@twg.com
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Thu, 4 Oct 90 09:40:01 pdt From: Walter Underwood <wunder@hpsdel.sde.hp.com> To: tcp-ip@nic.ddn.mil, comp.protocols.tcp-ip Subject: Re: HP TCP/IP router/bridge?
Does anyone know of a bridge or router that will allow HP hosts running
TCP/IP which speak IEEE style packets (802.2 encapsulated) to
communicate with ethernet style IP implementations?
I've answered Kevin separately, but here is the info for everyone
else:
1. The old-style HP 802.2/802.3 encapsulation pre-dates SNAP. It
uses the SAP originally reserved for IP (06) and uses a separate
protocol for address resolution (Probe). All this design was
done back in 1981-82, when no one but the 802 committee and HP
were interested in 802.
2. HP does not encourage new implementations of HP 802 and Probe,
because there are standard, and thus better, alternatives.
3. All HP products now support Ethernet and ARP, so no one has to
worry about the HP 802 encapsulation anymore. Just upgrade to
the latest networking bits.
wunder
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Thu, 4 Oct 90 10:26:00 MDT From: cpw%snow-white@LANL.GOV (C. Philip Wood) To: issm!wraith.wtp.contel.com!powell@uunet.uu.net Cc: tcp-ip@nic.ddn.mil Subject: Re: Network Monitors/Managment ... again (repost)
My experience is with Sun Microsystems, Inc. Sun Network Management product (SNM) and HP's network management system. I have spent a lot of time using SNM and find it useful. It is especially good at allowing for the incorporation of user defined applications. However, it's many features and seemingly infinite configuration capabilities are not for the novice. HP has a good product which should be the network management answer for 85 percent of the networks out there. The user interface is easy. It can learn about the networks it is attached to and provides a number of useful problem solving features. Phil
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 14:02:43 GMT From: eagle!news@ucbvax.Berkeley.EDU (Keith Jackson) To: tcp-ip@nic.ddn.mil Subject: Re: IBM MVS TCP/IP info wanted
NASA Lewis has the KNET product running on our VM system and from what I gather it has not been entirely happy. TCP/IP was just installed on the MVS system and the same product was also installed on VM replacing KNET. Sorry about being so vaque, but I not in charge of those systems. If you would like more info, give my a call and I can get you in touch with the appropriate system people. -- ----------------------------------------------------------------------------- Keith Jackson | phone: 216-433-5105 or Sverdrup Technology, Inc | 216-891-2946 NASA Lewis Research Center | email: vvkmj@spica.lerc.nasa.gov
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Thu, 4 Oct 90 18:32:40 EDT From: fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca To: TCP-IP@NIC.DDN.MIL Subject: Reply to network file backup
We back up our two Sun 3/60 workstations to a CDC Cyber 840 by using the standard "dump" command with the output directed to a NFS-mounted file on the Cyber. We do incremental dumps every night and full dumps once per week. It's all automatic - controlled by a crontab entry. This is a very efficient way of doing it - we can back up 100 megabytes in about 25 minutes, all unattended. You also have to back up the root partition to tape once in a while in case you have to do a full restore. Try it, you'll like it! - Bob Fillmore
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 15:38:42 GMT From: uokmax!munnari.oz.au!bruce!merlin!morgana!ianh@apple.com (Ian Hoyle) To: tcp-ip@nic.ddn.mil Subject: Re: TCP/IP for DEPCA boards
nelson@sun.soe.clarkson.edu (Russ Nelson) writes:
>In article <CMM.0.88.654810935.beach@ddnuvax.af.mil> beach@DDNUVAX.AF.MIL (darrel beach) writes:
> Can anyone point me to drivers, software, vendors to let me run
> TCP/IP on PCs which have a DEPCA (Digitals Ethernet PC bus Adapter)
> cards. Packet drivers compatible with NCSA, KA9Q, or even a commercial
> package would be appreciated.
>Not yet, but the picture is coming into focus. We've gone from
>"Digital refuses to release programming information" (that was just a
>rumor) to "How may I help get you the information you need to write a
>packet driver?"
Wollongong's TCP for DOS has appropriate drivers etc. for DEPCA cards *but*
like PCSA, they only seem to provide full functionality on the supported PC
platforms ie IBM, Compaq etc. Clones of various types (with their myriad
BIOS's) just don't work at all sometimes. This seems to occur with
monotonous regularity.
When it does work it's just fine :-)
ian
--
Ian Hoyle
/\/\ Image Processing & Data Analysis Group
/ / /\ BHP Melbourne Research Laboratories
/ / / \ 245 Wellington Rd, Mulgrave, 3170
/ / / /\ \ AUSTRALIA
\ \/ / / /
\ / / / Phone : +61-3-560-7066
\/\/\/ FAX : +61-3-561-6709
E-mail : ianh@bhpmrl.oz.au
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 16:01:28 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!ernie.viewlogic.com!curly!alan@ucsd.edu (Alan Medsker) To: tcp-ip@nic.ddn.mil Subject: Re: network file backup
I think Legato, or some company with a similar name, has such a product. I don't see the ad in Sun Tech Journal that I think might have been the last issue. Alan -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alan Medsker Viewlogic Systems, Inc. Voice: (508) 480-0881 293 Boston Post Road West Fax: (508) 480-0882 Marlboro, MA 01752 Internet: amedsker@Viewlogic.COM cc:Mail: Alan Medsker at Viewlogic CI$: 76376,662 BIX: amedsker 2 Meters: WB0SQR =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= My opinions, of course. And don't hold me to them. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 16:14:35 GMT From: bywater!arnor!news@uunet.uu.net To: tcp-ip@nic.ddn.mil Subject: RE: IBM 9000 TCP/IP, lpr?
> Another campus entity is looking into purchasing an IBM 9000 system, which > would run VM, and comes with some sort of TCP/IP package. They want to be > sure it works with our (BSD) network, especially for printing. Does anybody > know if it's possible for an IBM 9000 VM system to talk Berkeley lpr protocol? > Any information is most appreciated. > > -- > Bill Stapleton IBM's TCP/IP Version 2 for VM product, due out at the end of the year, includes an LPR client and LPD server. They have been written to interoperate with 4.3 LPR/LPD and work fine. If you're running our Version 1 product, I believe there is at least one LPR/LPD implementation available, from Columbia University. I believe it is free, but you'd have to contact them directly. Bill Rubin IBM TJ Watson Research rubin@ibm.com
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Thu, 04 Oct 90 14:35:48 +0100 From: Denis.Russell@newcastle.ac.uk To: tcp-ip@nic.ddn.mil Subject: IP over X.25
I have an interest in routing IP datagrams over an X.25 network,
and would like some information on the characteristics actual
products (routers) that do this. The kind of completely
hypothetical (!) setup that interests me is a set of say 50 to
100 mainly Ethernet LANs connected by a wide-area X.25 network
with X.25 speeds in the 9.6kbps-64kbps-2Mbps range.
In the worst case one might imagine a permanent 2 * N^2
network of X.25 calls, and clearly some intermediate plan using
an hierarchy of routers would be preferable.
However, I am primarily interested in an intermediate
scenario where the X.25 calls are established and cleared down
as required. Clearly the practicality of this this would depend
on the traffic pattern - but that is not the primary focus of
this query. The primary focus is to find out whether routers
that support X.25 as an IP bearer have the right sort of
characteristic for such an application. For example, one would
require support for a substantial number of such calls (10, 20,
30?), and the automatic clearing down of calls after some
inactivity timeout. What speed X.25 is supported (preferably
well beyond 64kbps)? Does a router exploit already existing
inbound X.25 calls to send outbound datagrams or does traffic
always result in two calls, one used in each direction? What
other questions are important?
As some examples of the clarifications we would value are
that we understand that Sunlink supports only 4 X.25 calls by
default, but can be configured for any larger number. On the
other hand, the calls are never cleared due to inactivity. We
don't know whether any routers exploit X.25 in a duplex manner
or whether two calls are always/sometimes/never set up.
I'll summarise to the list if there is interest in the
results.
Denis Russell JANET: Denis.Russell@uk.ac.newcastle
Computing Laboratory Internet: Denis.Russell@newcastle.ac.uk
The University
Claremont Road Tel: (+44) 91 222 8243
Newcastle upon Tyne Fax: (+44) 91 222 8232
NE1 7RU Telex: 53 65 4 UNINEW G
ENGLAND
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 16:18:09 GMT From: munnari.oz.au!murdu!viccol!gjocc@uunet.uu.net To: tcp-ip@nic.ddn.mil Subject: Assigning IP addresses
What is the best method for dynamically assigning IP addresses to PC's that are directly on our main ethernet? I have heard of the BOOTP and RARP protocols, so I guess what I need is BOOTP or RARP server software. Our main machines are VAX running VMS with 6.4 CMU TCP/IP and a Sequent S27 with DYNIX (BSD 4.2 UNIX). The PCs will probably be running NCSA telnet (which does RARP I believe). Any pointers to cheap software that can assign IP addresses to the PCs on our ethernet would be welcome. Greg O'Sullivan (gjocc@csv.viccol.edu.au)
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 17:10:05 GMT From: hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu (Lars Poulsen) To: tcp-ip@nic.ddn.mil Subject: Re: Does anybody know LM-X or Lackman?
In article <1990Oct3.192349.781@resam.dk>
andrew@resam.dk (Leif Andrew Rump) writes:
>We would also like to know the address of a company called Lackman
>who supplies TCP/IP software for UNIX systems.
Results of WHOIS LACHMAN.COM:
----------------------------
Lachman Associates, Inc. (LACHMAN-DOM)
1901 North Naper Boulevard
Naperville, IL 60540-1031
Domain Name: LACHMAN.COM
Administrative Contact:
Goldman, Ezra (EG56) ez%laidbak@SUN.COM
(312) 505-9100 ext 233
Technical Contact, Zone Contact:
Alexander, Steve (SA65) stevea@i88.isc.com
(708) 505-9100 ext 256
Record last updated on 01-Sep-88.
Domain servers in listed order:
LAIZY.LACHMAN.COM 192.35.52.1
LAIDBAK.LACHMAN.COM 192.35.52.2
--
/ Lars Poulsen, SMTS Software Engineer
CMC Rockwell lars@CMC.COM
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 18:14:00 GMT From: van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bwdls49!linegar@ucbvax.Berkeley.EDU (Derick Linegar) To: tcp-ip@nic.ddn.mil Subject: Ethernet Address Uniqueness...
In trying to debug a problem we are having here with our file server with 2 ethernet boards connected to 2 *different* subnets on the same network, our vendor eluded to us that the 2 ethernet cards assume the *same* Ethernet address, obtained from the primary ethernet board. Of course, warning bells are going of here. Now I've been searching the RFC and IEEE docs and I cannot find any documentation that sort of says that Ethernet Addresses are assigned to Ethernet boards, not hosts. Anyone have an idea where it might be. I cannot go back to the vendor and say " .... well everyone *knows* that ethernet addresses *must* be unique..." -derick- -- #include <disclaimer.h> Derick Linegar, Internet Systems 4P27, Bell-Northern Research BITNET: LINEGAR@BNR.ca P.O. Box 3511 Station C UUCP: ...uunet!bnrgate!bwdls49!linegar Ottawa ONT. K1Y 4H7
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 19:01:08 GMT From: synoptics!sblair@decwrl.dec.com (Steven Blair) To: tcp-ip@nic.ddn.mil Subject: Re: network file backup
We here use a very nive networked backup system called "budtool(BackUp Daemon Tool) from Delta Microsystems in Livermore Calif. Their phone is (415) 449-6881. We do nightly -0- backups of 10 Gbytes of machines. Without a hitch. Has an incredibly felxible timing mechanism, history mechanisms, scheduling tools, labeling tools, tape testing tools, and is affordable. We've got no releationship with them, than a very satisfied customer<->vendor relationship. They have always answered calls promptly, provided bug fixes promptly, and are generally very nice folks. The Legato Networker was evaluated here. We already had too much invested in Delta Micro's solution to justify using it. -- Steven C. Blair Network Operations Center SynOptics Communications Inc. Mountain View, California INTERNET: sblair@synoptics.com sblair@excalibur.synoptics.com PROBLEMS/EMAIL: HOSTMASTER@SYNOPTICS.COM postmaster@synoptics.com ---->>RIP Stevie Ray Vaughan 1954-1990 You Will Be *Missed*<<----
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 19:59:18 GMT From: eplrx7!mcneill@louie.udel.edu (Keith McNeill) To: tcp-ip@nic.ddn.mil Subject: Where is latest/greatest version of proxyarpd?
Subject says it....I tried comp.sources.wanted but I got no replies.
Thanks,
Keith
--
Keith D. McNeill | E.I. du Pont de Nemours & Co.
eplrx7!mcneill@uunet.uu.net | Engineering Physics Laboratory
(302) 695-9353/7395 | P.O. Box 80357
| Wilmington, Delaware 19880-0357
--
The UUCP Mailer
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Fri, 05 Oct 90 09:40:12 -0700 From: jqj@hogg.cc.uoregon.edu To: fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca Cc: tcp-ip@nic.ddn.mil Subject: Re: Reply to Ethernet Address Uniqueness...
Having the same MAC-level address for all interfaces (phrased differently, associating the MAC-level address with the NODE rather than with the INTERFACE) is part of the spec for both DECNET IV and XNS. It falls out of a design that has an algorithmic link between the MAC address and the protocol address. Many people believe that having a protocol address that belongs to the node rather than to the interface is a Good Idea, and that doing it the other way was a bad decision in the IP suite. I don't have a strong opinion, but I do know that the XNS/DECNET way of doing things makes routing to multihomed hosts easier. In the IP world there is no unambiguous way to decide whether 2 IP addresses refer to the same host; sure I can look in the DNS, but there is no guarantee that either or both addresses will be in the in-addr.arpa tree. Other people like the idea of algorithmic mapping from protocol to MAC address. It means that you don't need something like ARP, but it also limits your flexibility substantially, especially on physical networks like arcnet or 3mb Ethernet where the range of MAC addresses is very limited or hardwired in the interface. And it of course fails to generalize to cases where one needs to support multiple protocol stacks that each want to change the MAC address based on the protocol address!
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 23:36:19 GMT From: pilchuck!amc-gw!morpho!erik@uunet.uu.net (Erik Vollemaere) To: tcp-ip@nic.ddn.mil Subject: R/S 6000 raw I/O on Ethernet
We're attempting to establish communications between an IBM
R/S 6000 and a remote host with a CMC-20 board through Ethernet.
The communication must be done through non-encapsulated Ethernet
packets. The idea is to send it a packet of type AM and to
wait untill we receive a -broadcast- packet from it of type
PU. Then we send it a packet of type BS with the bootstrap
program. The first portion of this works fine. We open the
device (in this case /dev/ent0) and write() the packet. The
remote host responds with alternating BR - and PU type packets
(verified through an Ethernet analyzer). The problem is that
we do not "recognize" the packets from the remote host. Reads
fail with an EIO error ("An I/O error occurred while reading
from the file system"). Even if we get the read to succeed
(suggestions?), we prefer not to have to analyze every packet
looking for our target.
The question is: what call(s) do we use and how do we set it up
to return an Ethernet broadcast packet of type PU and ignore
everything else? We can accomplish this on different platforms
using raw socket I/O but those same calls fail on the R/S 6000.
The error messages are "Can't assign requested address" or
"Destination address required" (protocol interference). IBM
recommended using the device driver directly (/dev/ent0) and
that works fine for the write portion of the problem, but we're
now stuck on the read portion. We've been waiting for a solution
from IBM but so far their suggestions have not given us the
desired result.
___________________________________________________________________________
Standard disclaimer... the above opinions are mine, all mine.
Erik J.P. Vollemaere (B) / (VL)
____________________________________________________________________________
amc-gw!morpho!erik
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 01:20:32 GMT From: agate!linus!philabs!ttidca!quad1!srhqla!avatar!kory@ucbvax.Berkeley.EDU (Kory Hamzeh) To: tcp-ip@nic.ddn.mil Subject: Need a RARP Demon
Does anyone know where I can get my hands on source code for a Reverse
ARP demon to work on a Sun Sparcstation? I know Sun already has one, but
we have a special application where we need to slightly modify the Sun
version.
Thanks,
--kory
--
-------------------------------------------------------------------------------
Kory Hamzeh UUCP: avatar!kory or ..!uunet!avatar!kory
INTERNET: kory@avatar.com
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 01:23:19 GMT From: bacchus.pa.dec.com!mogul@decwrl.dec.com (Jeffrey Mogul) To: tcp-ip@nic.ddn.mil Subject: Re: 9 interesting & challenging problems for Netman
In article <9009210641.AA20321@ucbvax.Berkeley.EDU> J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes: >1. given the trace of packets between two end points on a LAN, >and a FSM, petri net, lotos/csp/ccs/Estelle spec for the protocol, >detect protocol (elements of procedure) errors. (easier, do the same >given ASN or XDR for packet formats:-) > >2. Given same data, automatically ascribe performance problems >to incorrect packet size, timeout, window etc... > This is similar to research reported on by Bruce L. Hitson in "Knowledge-Based Monitoring and Control: An Approach to Understanding the Behavior of TCP/IP Network Protocols", Proc. SIGCOMM '88. This was a rule-based system, not a "specification-based" system, but perhaps that is not such a big difference. >4. Find a good way to visualise the "closeness" of hosts based on the >frequency with which they communicate (this is non-trivial) > >5. Automatically draw a "tube" map (friendly/Metro) of the net given >the topography... Jon sent his message before he attended SIGCOMM '90 last week, where I gave a paper that touched on this topic. This is "work in progress" so it will be a while before I can publish a detailed paper. >7. Interpret auto-correllation between packets from/to and/or >same src/dst in a sensible fashion... I suppose this depends on one's definition of "sensible", but I've seen a few papers on this. For example, Mark J. Lorence and M. Satyanarayanan, "IPwatch: A Tool For Monitoring Network Locality", Operating Systems Review 24:1 (January 1990). These all seem to be fertile areas for research, as Jon has pointed out. -Jeff
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 01:26:02 GMT From: asylum!sharon@decwrl.dec.com (Sharon Fisher) To: tcp-ip@nic.ddn.mil Subject: Re: Does anybody know LM-X or Lackman?
In article <1990Oct3.192349.781@resam.dk> andrew@resam.dk (Leif Andrew Rump) writes: >Do any one of you know where we can get LM-X (Lan Manager) software >for the 386-UNIX System V rel 4 running on top of TCP/IP. > >We would also like to know the address of a company called Lackman >who supplies TCP/IP software for UNIX systems. Lachman Associates -- the last address I have for them is 1901 N. Naper Blvd., Naperville, IL 60540-1031; (312) 505-9100; fax (312) 505-9133.-- "Drive carefully." "What is it with women and 'drive carefully'? 'No, I'm going to steer with my feet and read the comic paper.'"
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 01:29:20 GMT From: bacchus.pa.dec.com!mogul@decwrl.dec.com (Jeffrey Mogul) To: tcp-ip@nic.ddn.mil Subject: Re: TCP segment size -- user defined?
In article <ID9478.D900921.T090901.DEDOUREK@UNB.CA> DEDOUREK@UNB.CA writes: >To avoid fragmentation, can TCP MSS be equal to path MTU, or must >it be less by some number of octets to allow for TCP and IP headers? >If so, what is a good value? The Path MTU Discovery document (now an Internet Draft, soon to be an RFC if all goes well) says: Note: The TCP MSS is defined to be the relevant IP datagram size minus 40 [see RFC879]. The default of 576 octets for the maximum IP datagram size yields a default of 536 octets for the TCP MSS. In other words, the TCP MSS should be at least 40 octets less than the path MTU. -Jeff
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Fri, 5 Oct 90 08:51:58 PDT From: postel@venera.isi.edu To: tcp-ip@nic.ddn.mil Subject: Re: TCP segment size -- user defined?
Hi. For further discussion of the TCP MSS see RFC 879. --jon. Date: 5 Oct 90 01:29:20 GMT From: bacchus.pa.dec.com!mogul@decwrl.dec.com (Jeffrey Mogul) Subject: Re: TCP segment size -- user defined? Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <ID9478.D900921.T090901.DEDOUREK@UNB.CA> DEDOUREK@UNB.CA writes: >To avoid fragmentation, can TCP MSS be equal to path MTU, or must >it be less by some number of octets to allow for TCP and IP headers? >If so, what is a good value? The Path MTU Discovery document (now an Internet Draft, soon to be an RFC if all goes well) says: Note: The TCP MSS is defined to be the relevant IP datagram size minus 40 [see RFC879]. The default of 576 octets for the maximum IP datagram size yields a default of 536 octets for the TCP MSS. In other words, the TCP MSS should be at least 40 octets less than the path MTU. -Jeff
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 04:23:20 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!bruce!trlluna!ilium!andrews@ucsd.edu (Murray Andrews) To: tcp-ip@nic.ddn.mil Subject: SNMP product guide (was Re: SNMP comparison)
In article <900925212840.581117@DOCKMASTER.NCSC.MIL>, Sabo@DOCKMASTER.NCSC.MIL writes: > > The second version of the SNMP product guide has just been published by > McGraw Hill's Datapro Research. This guide covers all of the SNMP NMSs > which were on the market as of a few weeks ago. Contact Jill > Huntington-Lee at 1 (800) 328-2776 extension 2444. Rumor has it that > copies of this report will be distributed free of charge at the Datapro > booth during INTEROP 90. > > L. Michael Sabo Does anyone have a fax number, email or snail mail address for this contact or an Australian distributor? An email response would be appreciated since I will be away for a couple of weeks and a response may get expired in my absence. But then again it might not. Thanks, Murray Andrews Telecom Australia Research Laboratories.
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 04:36:43 GMT From: world!ddern@uunet.uu.net (Daniel P Dern) To: tcp-ip@nic.ddn.mil Subject: RFC 1174 in the news (also, Internet Toaster)
The current (October 1990) issue of Data Communications has
a news article on RFC 1174 (not mentioned by [name]), "Federal
Networking Council to Widen Access to the Internet; Agrees to
Drop Requirement that New Members Obtain a Government Sponsor."
by yours truly.
I haven't read through the final printed version carefully, but
suspect there are some inaccuracies due to editing and condensing
and late night phone discussions with the editors .... I'm considering
posting an alternate version. For members of the Internet community
up to date on what's happening, one or two paragraphs would say all;
for others, it seemed to take more thousands of words than I was given...
Also, on the last page, a preview of John Romkey's Internet
Toaster, and other networked appliances/devices (some of which
were discussed here in the past month or two...).
Daniel Dern
(Don't ask me for copies; call McGraw-Hill. Tnx)
--
Daniel Dern, Ministry of Public Relations (MiniPurl) (617) 926-8743
High-tech journalism, PR and humor; substitute dance/Unix instructor
Internet: ddern@world.std.com UncaSam: PO Box 114 Belmont MA 02178
"No! We Don't Sell Frozen Yogurt Here!"
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 06:03:27 GMT From: mcsun!tuvie!edvvie!eliza!schweigl@uunet.uu.net (Johnny Schweigl) To: tcp-ip@nic.ddn.mil Subject: FTP client source available as PD ?
I am looking for the source of an FTP client program. If something like this is available in the public domain could anyone please mail it to me? BTW: I've got no FTP access, so please use email Thanks in advance, Johnny -- This does not reflect the | Johann Schweigl | DOS? opinions of my employer. | johnny@edvvie.at | Kind of complicated I am busy enough by talking | | bootstrap loader ... about my own ... | EDVG Vienna |
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Fri, 5 Oct 90 11:25:44 EDT From: Bob Stratton <dsc3rjs@nmdsc20.nmdsc.nnmc.navy.mil> To: TCP-IP@nic.ddn.mil Subject: Traceroute for 3B2/600's under sys V R3.2.2
Hello, I am looking for a copy of traceroute that runs on the AT&T 3B2/600, under System V Release 3.2.2. I am particularly curious as to whether Sys V requires the raw IP kernel hack that BSD systems do. Please mail your responses directly to me so as not to clog the list. Thanks in advance! Bob Stratton | dsc3rjs@nmdsc20.nmdsc.nnmc.navy.mil [DDN/Internet] NAVMEDATASERVCEN | dsc3rjs@vmnmdsc [BITNET only] (Innova Comms. / AT&T) | 295-3371 [AV] +1 301 295 3371 [PSTNet]
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: Fri, 5 Oct 90 11:59:38 EDT From: Bob Stewart <stewart@xyplex.com> To: fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca Cc: TCP-IP@nic.ddn.mil Subject: Reply to Ethernet Address Uniqueness...
>In the DEC VAX environment the unique Ethernet address on each board is >overridden by DECNET when it starts to use that board. The address is set >to four bytes of a constant value plus two bytes which contain the DECNET >area and node numbers. Lots of opportunity for duplication! >Does anyone know why DEC chose this scheme? > > - Bob Fillmore FILLMORE@EMRCAN.BITNET I believe it was to keep down the size of routing tables. Since the Ethernet address can be calculated from the DECnet address, you don't have to keep a 48-bit MAC address in your mapping from Network layer to Data Link layer. Bob ----------- Bob Stewart (rlstewart@eng.xyplex.com) Xyplex, Boxborough, Massachusetts (508) 264-9900
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: Fri, 5 Oct 90 12:05:47 EDT From: fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca To: TCP-IP@NIC.DDN.MIL Subject: Reply to Ethernet Address Uniqueness...
In the DEC VAX environment the unique Ethernet address on each board is overridden by DECNET when it starts to use that board. The address is set to four bytes of a constant value plus two bytes which contain the DECNET area and node numbers. Lots of opportunity for duplication! Does anyone know why DEC chose this scheme? - Bob Fillmore FILLMORE@EMRCAN.BITNET
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 09:55:24 GMT From: eru!hagbard!sunic!mcsun!hp4nl!nikhefh!a20@bloom-beacon.mit.edu (Marten Terpstra) To: tcp-ip@nic.ddn.mil Subject: Re: IP over X.25
In article <emu-ul20.1990.1004.143548.cl04@uk.ac.ncl.mts> Denis.Russell@newcastle.ac.uk writes:
[stuf deleted]
>this query. The primary focus is to find out whether routers
>that support X.25 as an IP bearer have the right sort of
>characteristic for such an application. For example, one would
>require support for a substantial number of such calls (10, 20,
>30?), and the automatic clearing down of calls after some
>inactivity timeout. What speed X.25 is supported (preferably
>well beyond 64kbps)? Does a router exploit already existing
>inbound X.25 calls to send outbound datagrams or does traffic
>always result in two calls, one used in each direction? What
>other questions are important?
CISCO IP routers can provide you with everything you want.
The max speed for normal serial interfaces in these boxes is T1
(or 1.544 Mbit/s). You can of course get higher speed interfaces.
The set-up and clearing of calls can simply be done by specifying an
idle timer. Only one call is needed for two way traffic. It will set
up a call if it has traffic to route. CISCO even provides x25 switching
if you want this. Ask CISCO for some info or drop a line at
customer-support@cisco.com.
Marten
--
Marten Terpstra National Institute for Nuclear
Internet : terpstra@nikhef.nl and High Energy Physics
Oldie-net: {....}mcsun!nikhefh!terpstra (NIKHEF-H), PO Box 41882, 1009 DB
Phone : +31 20 592 5102 Amsterdam, The Netherlands
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 11:03:16 GMT From: matthew@ooc.uva.nl (Matthew Lewis) To: comp.protocols.appletalk,comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: MAC MS-MAIL to SMTP gateway?
kdb@macaw.intercon.com (Kurt Baumann) writes: >In article <546@fciva.FRANKLIN.COM>, dag@fciva.FRANKLIN.COM (Daniel A. Graifer) >writes: >> I thought the GatorMail products were software to run on the GatorBox. Am I >> mistaken? Hard to believe that products designed for a GatorBox would run >> on Kinetics-oops-Novell-oops-Shiva FastPath. >I might be mistaken, but they do sell it as a seperate product. The last >I knew it ran with any AppleTalk-IP gateway product. Course this might have >changed as well. Anyone listening from Cayman, Brad? >Kurt i When Cayman took over marketing the Mail*Link software from StarNine, they changed the name to GatorMail. This has no relationship to the GatorBox, except that the first 5 letters are the same :-). It will run on a QuickMail center with access to your Unix box via TCP/IP. That means via Ethernet FastPath Multigate GatorBox (Have I left any out? Probably!) We run GatorMail-Q via a Multigate, with no problems. Matthew Lewis -- Matthew Lewis, University of Amsterdam Grote Bickersstraat 72 +31-20-52 51 220 1013 KS Amsterdam Internet: matthew@ooc.uva.nl The Netherlands UUCP: uunet!mcsun!hp4nl!uvabick!matthew
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 16:24:00 EST From: system@lns61.tn.cornell.edu To: "tcp-ip" <tcp-ip@nic.ddn.mil> Subject: re: Reply to Ethernet Address Uniqueness...
Bob, >In the DEC VAX environment the unique Ethernet address on each board is >overridden by DECNET when it starts to use that board. The address is set >to four bytes of a constant value plus two bytes which contain the DECNET >area and node numbers. Lots of opportunity for duplication! >Does anyone know why DEC chose this scheme? The "four constant bytes" are reserved to DEC (for DECnet) just as the high-order butes of the physical hardware Ethernet addresses in those Ethernet boards' address ROMs are also reserved to DEC. In a given DECnet wide-area network, all DECnet node addresses are required to be unique. As a result, there is no opportunity for duplication on a local Ethernet either. (I am ignoring the complications introduced by setting limits on the address ranges passed by routers.) One reason that DEC chose this scheme is that it allows "end-node" DECnet systems, which have no routing information whatsoever, to be able to send messages to other end-node systems on the same Ethernet even when there are no DECnet routers present. They just calculate what the Ethernet address must be and blindly transmit the message into the ether. Of course, the fact that DECnet addresses are limited to 16 bits means that larger networks are limited to a maximum of about 64K systems. My guess is that there are fewer than a dozen networks for which this causes problems. This address limitation in Phase IV DECnet is one of the reasons that DEC is moving to OSI for DECnet Phase V. I hope this helps. Selden E. Ball, Jr. (Wilson Lab's network and system manager) Cornell University Voice: +1-607-255-0688 Laboratory of Nuclear Studies FAX: +1-607-255-8062 Wilson Synchrotron Lab BITNET: SYSTEM@CRNLNS Judd Falls & Dryden Road Internet: SYSTEM@LNS61.TN.CORNELL.EDU Ithaca, NY, USA 14853-8001 HEPnet/SPAN: LNS61::SYSTEM = 44283::SYSTEM
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 11:53:23 GMT From: att!mcdchg!ddsw1!proxima!olsa99!iosys!icl011!root@ucbvax.Berkeley.EDU (Super user) To: tcp-ip@nic.ddn.mil Subject: Re: Looking for POP mail for MAC
> We are looking for various POP/SMTP implementations for the Macintosh. > Our requirements include support for MacTCP and source code > availability. hi Steven Wallace of Indiana Uv did you ever find the POP/Coke for your Mac/Rain/Coats, will not to panic if've just the thing for you. 1. find a pen. 2. find a paper ( used may suit ) 3. use 'effort' to scribe pen on paper! 5(a) not what you may have wonted but it's a good, ain't it! /******************************************************************************* * Sean J & Associates. * * COPYRIGHT (c) 1984-1989 Sean J & Ass, Knockyrourke Co Cork, Ireland. * * All rights reserved. No part of this work covered by the * * copyright hereon may be reproduced or used in any form or by any means * * -- graphic, electronic, or mechanical, including photocopying, * * recording, taping, or information storage and retrieval systems -- * * without permission of Sean J & Associates. * ******************************************************************************/ Very Best Regards, SEan S.
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 14:55:59 GMT From: bu.edu!polygen!bill@uunet.uu.net (Bill Poitras) To: tcp-ip@nic.ddn.mil Subject: Re: SLIP, IP Routers and Named Pipes
Phil Karn's KA9Q package would do just fine. KA9Q is a program that allows connection to the PC via ftp, telnet, smtp, et. al. at the same time. It has a builtin multitasking mechanism. It also supports slip, and routing. I have used it for a slip to ethernet router before. You can find it on thumper.bellcore.com under the /pub/ka9q directory.
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 14:57:23 GMT From: swrinde!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!sun-barr!olivea!oliveb!felix!dhw68k!zardoz.cpd.com!durin!frankh@ucsd.edu (Frank Halsema) To: tcp-ip@nic.ddn.mil Subject: PCPOP hangs
I just picked up PC POP from nasa.trident.gov. I set up the popd on my sun 3/280 running SunOS 4.1. I have had NCSA telnet with packet drivers for a while and they work fine. The set up is a com 3c503 card with the memory jumper on CC000 packet driver version 4.2 the command for the driver is c:\ncsa\3c503 0x7e 3 0x300 1 I enter set configtel=c:\ncsa\config.tel when i run pcpop in the directory pcpop I comes up with the initial configuration screen. If I type with minimal delays I can get the information in but after entering yes to confirm the configuration it hangs. Also if I delay in entering the configuration data I get a hang immediately. I have taken everything out of my config.sys except for the ANSI.SYS, FILES, and BUFFERS lines. There is also a break=on. below is my config.tel. Any help would be greatly appreciated. # # Example host file for Telnet 2.2 # # "funny, this configuration file is readable ..." # # This file is free form # Separators are any char <33 and :;= # # The form is keyword=value for each parameter. # The first set of parameters refer to the whole program's defaults. # These parameter values can be in any order. # Following this are the individual machine specs. # If the first machine is name "default", then it contains default # values for the rest of the machines. # myip=192.42.141.101 name=pippin netmask=255.255.255.0 # subnetting mask hardware=packet # values are: 3c501,ni5210,pcnic,wd8003 # for ps/2: nicps2,3c523 tek=yes # enable tektronix graphics video=ega # type of video screen # Legal values for video are: # cga,ega,no9,hercules bios=no # don't use slow BIOS screen access # bios=yes to reduce flicker on cga # bios=yes for TopView or Windows interrupt=3 # hardware IRQ interrupt for 3C501 board address=0 ioaddr=7E # base address for I/O registers ftp=yes # do you want ftp enabled? rcp=yes # do you want rcp enabled? capfile=mycap # default name for capture file domain="sparta.com" # default domain for name lookups hpfile=hp.out # file to write HPGL to, # COM1 can be used for attached plotter psfile=ps.out # file to write postscript to tekfile=tek.out # file to write Tek codes to arptime=4 # arp timeout in seconds # affects machines on your local network #passfile="c:\ncsa\ftppass" # name of file to find FTP passwords in # # Following are individual machine specifications # Gateways are used in order that they appear in the file # Nameservers rotate, #1, #2, #3, #1, #2 when a request fails # # The machine named "default" contains the fields which are automatically # filled in for other hosts. name=default machine should appear first. # name = default # Session name, "default" is a reserved name # Not a real machine, default parameters only # # #gateway=1 # This machine is a gateway for me # scrollback=100 # number of lines of scrollback per session erase=delete # use delete code or backspace code for <- key? # legal values are "delete" and "backspace" vtwrap=yes # should VT100 be in wrap mode or not? nfcolor=green # normal, foreground nbcolor=black # normal, background rfcolor=black # reverse, foreground rbcolor=white # reverse, background ufcolor=blue # underline, foreground ubcolor=black # underline, background #crmap=4.3BSDCRNUL # map of the CR key for compatibility #duplex=half # modifier for non-echo mode, forces send clearsave=yes # save lines on clear screen yes/no # The following entries affect the tuning of TCP connections to this host. # They should be set by the network administrator who is familiar with # the requirements of your specific network. contime=20 # timeout in seconds to try connection retrans=7 # starting retransmit time out in ticks # 1/18ths of sec mtu=512 # maximum transmit unit in bytes # outgoing packet size, MAX=1024 maxseg=512 # largest segment we can receive # whatever the hardware can take, MAX=1536 rwin=512 # TCP window size, MAX=4096 # # Below this line, most of the communication parameters are obtained # from the "default" host entry. # Machine names, IP addresses, and special communication parameters are # present when needed. # name=durin ; hostip=192.42.141.7 ; nameserver=1 #name=mynameserver ; hostip=127.0.0.2 ; nameserver=1 -- Frank Halsema UUCP: durin!frankh SPARTA, Inc. Internet: frankh%durin@uunet.uu.net 23041 de la Carlota, Suite 400 Laguna Hills Ca, 92653 (714) 768-8161 EXT 339 (714)583-9114 FAX
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 15:22:31 GMT From: world!esegue!johnl@uunet.uu.net (John R. Levine) To: tcp-ip@nic.ddn.mil Subject: Re: Does anybody know LM-X or Lackman?
In article <12817@asylum.SF.CA.US> sharon@asylum.UUCP (Sharon Fisher) writes:
>Lachman Associates -- the last address I have for them is 1901 N.
>Naper Blvd., Naperville, IL 60540-1031; (312) 505-9100; fax (312) 505-9133.
Lachman is now a subsidiary of Interactive Systems, but they're still at the
same address. On the net they're known as laidbak.uucp or i88.isc.com. The
telephone area code has changed from 312 to 708, the postal zip to 60563-8895.
--
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|spdcc|world}!esegue!johnl
Atlantic City gamblers lose $8200 per minute. -NY Times
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 16:23:16 GMT From: sdd.hp.com!usc!isi.edu!gremlin!nrtc.northrop.com!domae@ucsd.edu (Terry Domae) To: tcp-ip@nic.ddn.mil Subject: CSLIP/PPP Status?
Does anyone know the current status of CSLIP and PPP? I have not seen any real news in almost a year. Terry Domae Northrop Research and Technology Center Terry Domae
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 16:41:59 GMT From: hpda!hpcupt1!hpindwa!raj@ucbvax.Berkeley.EDU (Rick Jones) To: tcp-ip@nic.ddn.mil Subject: Re: SLIP, IP Routers and Named Pipes
A few new-to-named-pipes questions... Am I correct in assuming that it is the 'non-passing' for certain IP/UDP broadcast packets that prevents 'stock' named-pipes from working across IP routers? If that is the only reason, then could one expect named-pipes to work across a router that could be configured to pass these broadcasts in a controlled manner? (no loops and all that...) inquireing minds and all... rick ___ _ ___ |__) /_\ | Richard Anders Jones | MPE/XL Networking Engineer | \_/ \_/ Hewlett-Packard Co. | 'Tis nobler to suffer... ------------------------------------------------------------------------ Being an employee of a Standards Company, all Standard Disclaimers Apply
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 17:03:13 GMT From: ogicse!plains!kapoor%plains.NoDak.edu@decwrl.dec.com (Sanju Kapoor) To: tcp-ip@nic.ddn.mil Subject: Broadcasting on Sockets
I am sending this for a friend of mine who does not have access to this
net group. I would send all replies to him. Here is his question :
/******************************************************************************
I am having problems with broadcasting on socket. I keep getting the
message "Can't assign requested address" when I call the function sendto.
What am I doing WRONG. I am sending the code where I am having the problem.
When I do "ifconfig le0" on the interface I do see the broadcast address of
my network interface(lance ethernet). ALL machines are SUN SPARCstation SLC
running SunOS 4.1.
I am trying to write a function that will find a resource on the network.
On each of the host machine on the network there is a server which keeps
track of the resources available on the local host. When a client needs a
resource "X" it sends a broadcast message to locate the resource and waits
for the response from the server which owns the resource. Assume that the
resources uniquely exist on the network.
I may be doing something wrong here but can't seem to fix it. If anyone
can give suggestions I would appreciate it . Also, I would like to know
how does the server on the host listen for broadcast message. Thanks in advance.
*******************************************************************************/
int
find_resource(resource,location)
char *resource, /* resource to be located */
*location; /* location of the resource */
/* to be set by this function */
{
int brd_socket,
brd_on,
cnt,
len;
char buf[BUFSIZ];
struct sockaddr_in clnt_addr,
serv_addr;
struct sockaddr dest_addr;
struct ifconf ifc;
struct ifreq *ifr;
if ((brd_socket = socket(AF_INET,SOCK_DGRAM,0)) < 0)
return (-1);
brd_on = 1;
if (setsockopt(brd_socket,SOL_SOCKET,SO_BROADCAST,
&brd_on,sizeof(brd_on)) == -1)
return(-1);
clnt_addr.sin_family = AF_INET;
clnt_addr.sin_addr.s_addr = htonl(INADDR_ANY);
clnt_addr.sin_port = 0;
len = sizeof(clnt_addr);
if (bind(brd_socket,(struct sockaddr *) &clnt_addr,len) < 0)
return(-1);
ifc.ifc_len = sizeof(buf);
ifc.ifc_buf = buf;
if (ioctl(brd_socket,SIOCGIFCONF,(char *) &ifc) < 0)
return(-1);
ifr = ifc.ifc_req;
for (cnt = ifc.ifc_len/sizeof(struct ifreq); --cnt >0 ; ifr++) {
if (ifr->ifr_addr.sa_family != AF_INET)
continue;
if (ioctl(brd_socket,SIOCGIFFLAGS,(char *) ifr) < 0)
return(-1);
if (((ifr->ifr_flags & IFF_UP) == 0) ||
(ifr->ifr_flags & IFF_LOOPBACK) ||
((ifr->ifr_flags & IFF_BROADCAST) == 0))
continue;
if (ifr->ifr_flags & IFF_BROADCAST)
if (ioctl(brd_socket,SIOCGIFBRDADDR,(char *) ifr) < 0)
return(-1);
bcopy(ifr->ifr_broadaddr,(char *)&dest_addr,
sizeof(ifr->ifr_broadaddr));
len = strlen(resource);
if (sendto(brd_socket,resource,len,0,(struct sockaddr *)
&dest_addr,sizeof(dest_addr))== -1)
return(-1);
}
if (recvfrom(brd_socket,location,sizeof(location),0,
(struct sockaddr*)&serv_addr,&len) == -1)
return(-1);
return(0);
}
----------------------------------------------------------------------------
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 17:26:28 GMT From: zaphod.mps.ohio-state.edu!samsung!olivea!oliveb!felix!dhw68k!fedeva!bill@tut.cis.ohio-state.edu (Bill Daniels) To: tcp-ip@nic.ddn.mil Subject: is syslog(3) to remote possible?
I posted a similar request about a week or two ago. Just as luck would
have it my news machine went away for a couple of days right afterwards.
I have need to log operator messages via syslog(3) on a remote machine. I
am sure that this is possible because of the way the docs and headers read.
It seems however that Ultrix has coded up syslog() so that all messages go
to the local machine.
If there is a way around this I would be ever grateful to the one who shares
the insight. If there is not a workaround, could someone mail me the source
to syslog(3) and syslog(8) if it is publicly available?
Thanks for your help
bill daniels
--
bill daniels
federal express, memphis, tn
{zardoz!dhw68k,mit-eddie!premise}!fedeva!bill
bill@fedeva.UUCP
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 17:54:14 GMT From: tjh+@andrew.cmu.edu (Tom Holodnik) To: tcp-ip@nic.ddn.mil Subject: SLIP for the NeXT machine?
Is there a (preferably free) SLIP implementation for the NeXT machine? Thanks in advance. ____________________________ Tom Holodnik Networking & Communications Carnegie-Mellon University UCC-137 4910 Forbes Avenue Pittsburgh PA 15213 (412)-268-2028 ____________________________
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 19:09:22 GMT From: rogue.llnl.gov!oberman@lll-winken.llnl.gov To: tcp-ip@nic.ddn.mil Subject: Re: Reply to Ethernet Address Uniqueness...
In article <5A0A050B012801FE-MTAEMR1*fillmore@emrcan>, fillmore@emrcan.BITNET writes: > In the DEC VAX environment the unique Ethernet address on each board is > overridden by DECNET when it starts to use that board. The address is set > to four bytes of a constant value plus two bytes which contain the DECNET > area and node numbers. Lots of opportunity for duplication! > Does anyone know why DEC chose this scheme? Basic answer- They messed up! DECnet Phase V will abandon this ill concieved idea. It was a clever idea to allow a direct and unambiguous translation from DECnet address to Ehternet address which eliminates the need for ARP or some similar method of Ethernet address resolution. They have since learned the folly of this and do the reverse in Phase V. They code the 6 bytes of the Ethernet address into the system's NSAP (OSI address). R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 19:10:33 GMT From: sunquest!alpha.sunquest.com!gavron@arizona.edu (Ehud Gavron) To: tcp-ip@nic.ddn.mil Subject: Re: Reply to Ethernet Address Uniqueness...
In article <5A0A050B012801FE-MTAEMR1*fillmore@emrcan>, fillmore@emrcan.BITNET writes...
#In the DEC VAX environment the unique Ethernet address on each board is
#overridden by DECNET when it starts to use that board. The address is set
#to four bytes of a constant value plus two bytes which contain the DECNET
#area and node numbers. Lots of opportunity for duplication!
#Does anyone know why DEC chose this scheme?
On one ethernet, the duplication only occurs if two
nodes have the same DECnet address -- which is not
only a no-no but since both would have terrible
problems, this condition would not persist long.
There is therfore not "lots of opportunity for
duplication." It also is completely immaterial
why DEC chose this scheme. Suffice to say that
the next major DECnet release (now targeted for
'92) will be completely different.
#
# - Bob Fillmore FILLMORE@EMRCAN.BITNET
^^^^^^
Ehud
/----------------------------------------------------------------------------\
| Ehud Gavron, Systems analyst | gavron@vesta.sunquest.com (Internet) |
| Sunquest Information Systems | uunet!sunquest!gavron (UUCP) |
| 930 N. Finance Center Drive | gavron@lampf (BITNET) |
| Tucson, Arizona, 85710 | (602)722-7546/885-7700 x.2546 (AT&Tnet) |
|----------------------------------------------------------------------------|
| your cute quote here |
\----------------------------------------------------------------------------/
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 19:16:35 GMT From: bu.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!aero!ctw@bloom-beacon.mit.edu (Charles T. Wolverton) To: tcp-ip@nic.ddn.mil Subject: Re: TCP/IP for DEPCA boards
In Article: 13237, ianh@bhpmrl.oz.au (Ian Hoyle) says:
> Wollongong's TCP for DOS has appropriate drivers etc. for DEPCA cards ...
ian
My Wollongong documentation has installation instructions for
1. "an existing DEC LAN in working condition"
2. "an existing 3com 3+Open LAN in working condition"
Is this equivalent to:
1.' "a network card with the appropriate DEC DLL-compliant driver"
2.' "a network card with the appropriate MS NDIS-compliant driver and
protocol manager software" ???
If no, I don't understand the response quoted above. If yes, wouldn't
the restated versions (possibly corrected, since I don't really
understand yet how NDIS works and know nothing about DLL) be more
generally useful??
Edification, please.
-chas ctw@aero.org
--
*** Charles T. Wolverton ***** Aerospace Corporation ***
*** ctw@aerospace.aero.org ***** P.O. Box 92957 M1-023 ***
*** (213) 336-5204 ***** Los Angeles, CA 90009 ***
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 19:23:23 GMT From: olivea!orc!bu.edu!mirror!roskuski@apple.com (Barry J. Roskuski) To: tcp-ip@nic.ddn.mil Subject: Long distance TCP/IP
Please excuse the dumb question, but I am utterly ignorant about
this stuff.
What is necessary to set up a TCP/IP network between two UNIX
systems at 2 different sites? I've guessed that we can use SLIP
over a modem, but performance probably wouldn't be what we'd like.
I've heard mention of T1 lines, but am not sure how I would connect
to them (or even what they are for that matter). Can you hang a T1
line off of an ethernet with the appropriate bridge? Is this what
I need, or am I way off base? And how does X.25 fit into this. Any
help or pointers in the right direction would be appreciated.
---
Barry J. Roskuski Mirror Systems
2067 Massachusetts Ave.
Cambridge, MA 01240
roskuski@mirror.TMC.COM
{mit-eddie, pyramid, harvard!wjh12, xait}!mirror!roskuski
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 19:33:49 GMT From: arizona.edu!leonard@arizona.edu To: tcp-ip@nic.ddn.mil Subject: Re: Ethernet Address Uniqueness...
In article <5A0A050B012801FE-MTAEMR1*fillmore@emrcan>, fillmore@emrcan.BITNET writes: > In the DEC VAX environment the unique Ethernet address on each board is > overridden by DECNET when it starts to use that board. The address is set > to four bytes of a constant value plus two bytes which contain the DECNET > area and node numbers. Lots of opportunity for duplication! > Does anyone know why DEC chose this scheme? Sure, it saves DECnet having to have an address resolution protocol a la ARP ... if a DECnet node wants to find the MAC address for a given DECnet address, it already knows what the address *should* be. There's a couple of problems with this approach: 1. If you are running different network protocols on the same Ethernet board, then obviously they can't *all* do this! I believe that Novell's IPX similarly hacks the Ethernet address, which (if true) means that DECnet and IPX can't share the same board. 2. A DECnet node can't have multiple Ethernet interfaces running DECnet on the same bridge-extended Ethernet. (Because the bridges will see the same Ethernet addr on both sides!) This may seem like a perverse topology to IP oriented folks, but given DEC's historical MAC layer uber alles approach, in some situations this can be exactly what you would want. In DECnet Phase V (due out twelve months from any given point in time ;-) ), DECnet is supposed to stop resetting the hardware addresses on its Ethernet adapters, and will presumably adopt some ARP protocol.
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 19:52:37 GMT From: sun-barr!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@decwrl.dec.com (Henry Spencer) To: tcp-ip@nic.ddn.mil Subject: Re: Ethernet Address Uniqueness...
In article <linegar.655064040@bwdls49> linegar@bwdls49.bnr.ca (Derick Linegar) writes: >our vendor eluded to us that the 2 ethernet cards assume the *same* Ethernet >address, obtained from the primary ethernet board. Of course, warning bells >are going of here. Now I've been searching the RFC and IEEE docs and I cannot >find any documentation that sort of says that Ethernet Addresses are assigned >to Ethernet boards, not hosts. This seems to come up fairly often... The original intent of Ethernet was quite specifically to assign addresses to hosts, not boards, which is one reason why Ethernet addresses are required to be programmable instead of being locked into the boards. The XNS protocols use Ethernet addresses as host numbers and *must* have exactly one address per host. With TCP/IP, the Ethernet addresses are largely invisible to the upper levels and it doesn't really matter much either way, unless for some reason you've got two boards on the same network (in which case you will have other problems...). -- Imagine life with OS/360 the standard | Henry Spencer at U of Toronto Zoology operating system. Now think about X. | henry@zoo.toronto.edu utzoo!henry
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 20:33:50 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!rphroy!cfctech!alexb@decwrl.dec.com (Alex Beylin) To: tcp-ip@nic.ddn.mil Subject: Re: SLIP with Named Pipes
First, thanks to everyone for many helpfull responces regarding SLIP and Named Pipes. From the responces I see that more details are in order. What ww would like to do is allow users with portable computers and modems to user DCA's CommServer in order to access 3090 resources. As James Van Bokkelen pointed out, we have to use Lan Manager. CommServer can use a number of APIs, but Named Pipes seems the cleanest. In order to carry it all the way to the PC we will need NetBios and SLIP software on the PC. The solution seems to be cisco SLIP concentrator and PC/TCP (Thank you, James). We will be running tests late October. I will post results to this group. Again, thanks to everyone for all the help. -- Alex Alex Beylin, Unix Specialist | +1 313 948-3386 alexb@cfctech.cfc.com | Chrysler Financial Corp. sharkey!cfctech!alexb | MIS, Distributed Systems ATT Mail ID: attmail!abeylin | Southfield, MI 48034
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 21:24:00 GMT From: system@LNS61.TN.CORNELL.EDU To: comp.protocols.tcp-ip Subject: re: Reply to Ethernet Address Uniqueness...
Bob, >In the DEC VAX environment the unique Ethernet address on each board is >overridden by DECNET when it starts to use that board. The address is set >to four bytes of a constant value plus two bytes which contain the DECNET >area and node numbers. Lots of opportunity for duplication! >Does anyone know why DEC chose this scheme? The "four constant bytes" are reserved to DEC (for DECnet) just as the high-order butes of the physical hardware Ethernet addresses in those Ethernet boards' address ROMs are also reserved to DEC. In a given DECnet wide-area network, all DECnet node addresses are required to be unique. As a result, there is no opportunity for duplication on a local Ethernet either. (I am ignoring the complications introduced by setting limits on the address ranges passed by routers.) One reason that DEC chose this scheme is that it allows "end-node" DECnet systems, which have no routing information whatsoever, to be able to send messages to other end-node systems on the same Ethernet even when there are no DECnet routers present. They just calculate what the Ethernet address must be and blindly transmit the message into the ether. Of course, the fact that DECnet addresses are limited to 16 bits means that larger networks are limited to a maximum of about 64K systems. My guess is that there are fewer than a dozen networks for which this causes problems. This address limitation in Phase IV DECnet is one of the reasons that DEC is moving to OSI for DECnet Phase V. I hope this helps. Selden E. Ball, Jr. (Wilson Lab's network and system manager) Cornell University Voice: +1-607-255-0688 Laboratory of Nuclear Studies FAX: +1-607-255-8062 Wilson Synchrotron Lab BITNET: SYSTEM@CRNLNS Judd Falls & Dryden Road Internet: SYSTEM@LNS61.TN.CORNELL.EDU Ithaca, NY, USA 14853-8001 HEPnet/SPAN: LNS61::SYSTEM = 44283::SYSTEM
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: 6 Oct 90 09:38:17 PDT (Sat) From: romkey@asylum.sf.ca.us (John Romkey) To: oberman@rogue.llnl.gov Cc: tcp-ip@nic.ddn.mil Subject: Reply to Ethernet Address Uniqueness...
Date: 5 Oct 90 19:09:22 GMT From: decwrl!lll-winken.llnl.gov!rogue.llnl.gov!oberman References: <5A0A050B012801FE-MTAEMR1*fillmore@emrcan> Sender: tcp-ip-relay@nic.ddn.mil They code the 6 bytes of the Ethernet address into the system's NSAP (OSI address). What a great idea. So if you change your ethernet card, your machine's address changes too? - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: 6 Oct 90 03:32:37 GMT From: shelby!msi.umn.edu!cs.umn.edu!peiffer@decwrl.dec.com (Tim Peiffer (The Net Guy)) To: tcp-ip@nic.ddn.mil Subject: Re: SLIP, IP Routers and Named Pipes
In article <9987@xenna.Xylogics.COM> kriger@Xylogics.COM (Sidney Kriger) writes: >In article <8879@allen.ingr.com> usenet@b11.ingr.com (Usenet Network) writes: >>I worked for an outfit that sold cisco and the company I work for now >>sells the Encore Annex II. >Xylogics now manufactures the Annex II terminal server and has for about >2 years, not Encore. 800-225-3317 I have both the Encore and Xylogics varients of the Annex II terminal server running some ports under slip. I am very happy with the ease in configuration, but I would like to see something that supports the Van Jacobsen hdr compression algorithms( RFC 1144). Does anyone know of a product that supports this scheme? SLIP is sssoooo easy to configure slip on an Annex. It seems like a shame to waste it, but ftp and telnet are so gawdawfully slow even over a 38.4k link that I still resist putting it in place. For those that care, Xylogics is the Manufacturer of the Annex now, but Encore still oem's the product, and they have their own software line to support the normal Encore line of multimaxen. Tim -- ----------- Tim Peiffer peiffer@cs.umn.edu or Computer Science Dept ..!rutgers!umn-cs!peiffer University of Minnesota
-----------[000087][next][prev][last][first]---------------------------------------------------- Date: 6 Oct 90 03:56:25 GMT From: agate!shelby!msi.umn.edu!cs.umn.edu!peiffer@apple.com (Tim Peiffer (The Net Guy)) To: tcp-ip@nic.ddn.mil Subject: Re: Nameservice questions
In article <465@bcstec.UUCP> ced@bcstec.uucp (Charles Derykus) writes: > (1) Can nameservice resolve reverse translation queries "up the tree" > towards the root domain if the domains of the requested node and > the requesting node are at the same level, e.g. [...} > can "carrot" ask "cabbage" to reverse translate an I.P. in > "herb.vegetable" and if so, how? Yes, you can forward unresolved entries (those not in your domain or in your secondary zones) by using the forwarding construct in named.boot. ; forward name-service request when we can't (won't) handle them forwarders first_forwarder_ipaddr second_forwarder_ipaddr > (2) A named.rev with multiple $ORIGIN lines worked fine on out primary > nameserver for a while but then the secondary nameserver starting > breaking. The only way we get it working now is by specifying separate > reverse translation files for each $ORIGIN line, e.g. I do not really understand. I would answer your question with no. The in-addr.arpa domain is rather unusual and should be treated differently than most others. The declaration in named.boot specifies service for a particular domain. I think that your declaration would break unless it were of the following form: named.boot ---------- primary 207.128.in-addr.arpa. herb.file_name herb.file_name ---------- $ORIGIN 254.207.128.in-addr.arpa. 44 IN PTR parsley.herb.blah.blah. $ORIGIN 253.207.128.in-addr.arpa. 1 IN PTR oregano.herb.blah.blah. Tim -- ----------- Tim Peiffer peiffer@cs.umn.edu or Computer Science Dept ..!rutgers!umn-cs!peiffer University of Minnesota
-----------[000088][next][prev][last][first]---------------------------------------------------- Date: 6 Oct 90 04:00:29 GMT From: agate!shelby!msi.umn.edu!cs.umn.edu!peiffer@apple.com (Tim Peiffer (The Net Guy)) To: tcp-ip@nic.ddn.mil Subject: Re: quick check for available host
In article <1990Oct3.200749.16049@cbnewsk.att.com> lih@cbnewsk.att.com (andrew.a.lih) writes: >In article <771@tiamat.fsc.com>, jim@tiamat.fsc.com (Jim O'Connor) writes: >> What is a quick way for a shell script to find out if a networked >> host is currently available? If you want more than what 'ping' offers, but not the mess that rwho provides, check out rup(), and rusers(). Tim -- ----------- Tim Peiffer peiffer@cs.umn.edu or Computer Science Dept ..!rutgers!umn-cs!peiffer University of Minnesota
-----------[000089][next][prev][last][first]---------------------------------------------------- Date: 6 Oct 90 04:32:56 GMT From: mimos!rangkom!napi@uunet.uu.net (Mazli Hashim) To: tcp-ip@nic.ddn.mil Subject: Problem with remote printing
Hi netters When I send a job for remote printing from a Convex via an Apollo workstation which is attached to an Apple Laser Writer II, the 'lpd' on the Convex gives this error message in 'lpd-errs':- /usr/lib/lpd: lw: lost connection or error in recvjob and the 'lpd' on the Apollo gives this error message in its 'lpd-errs':- Oct 6 12:05:28 t1a lpd[1537]: cannot find device 1222352, 1 What could be the problem(s)? Any pointers are appreciated. Napi
-----------[000090][next][prev][last][first]---------------------------------------------------- Date: 6 Oct 90 15:13:29 GMT From: att!cbnews!junk1@ucbvax.Berkeley.EDU (eric.a.olson) To: tcp-ip@nic.ddn.mil Subject: Re: Does anybody know LM-X or Lackman?
I have heard that if you run a program on a virtual console (vt??), the console will not be subject to screen-scrambling with console error messages. This appears to be true, as my machine running X never gets bothered by the messages. How do I force the console into this mode?
-----------[000091][next][prev][last][first]---------------------------------------------------- Date: 6 Oct 90 19:07:34 GMT From: swrinde!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu (Edward Vielmetti) To: tcp-ip@nic.ddn.mil Subject: Re: Is there a program like telnet, but driven by a script?
In article <26797@fmsrl7.UUCP> hugh@slee01.srl.ford.com (Hugh Fader) writes:
I need to duplicate UNIX-to-UNIX rsh functionality going UNIX-to-VMS.
I am running a Sun Sparcstation and can communicate with the VAX using
telnet and ftp via an ULTRIX gateway (the VAX only runs DECNET). One
solution to my problem would be a telnet-like program which accepts a
script containing expect/send pairs much like UUCP and some PC
communications programs. Does such a program exist?
See "expect" from Don Libes, ftp'able from durer.cme.nist.gov. An extract
from the man page:
expect is a program that "talks" to other interactive pro-
grams according to a script. Following the script, expect
knows what can be expected from a program and what the
correct response should be. An interpreted language pro-
vides branching and high-level control structures to direct
the dialogue. In addition, the user can take control and
interact directly when desired, afterward returning control
to the script.
Since this is a program which isn't necessarily related to tcp/ip, please
follow up to comp.unix.misc.
--Ed
Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
moderator, comp.archives
-----------[000092][next][prev][last][first]---------------------------------------------------- Date: 6 Oct 90 21:21:13 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!pluto!rstevens@ucsd.edu (Rich Stevens) To: tcp-ip@nic.ddn.mil Subject: Re: >>> Internetworking with TCP/IP book FOR SALE <<<
Be aware that the 2nd edition of this book was just published by Prentice Hall. I've only glanced at it, so I can't give a list of what's changed, but it is about 150 pages longer. This 2nd edition retains the subtitle "Principles, Protocols, and Architectures" and is listed as Volume I. The back cover lists Volume II with the subtitle "Implementation and Internals" and its by Comer and David L. Stevens. I believe that Volume II will be out in 1991 and will contain the source code to the Xinu implementation of TCP/IP. Richard Stevens
-----------[000093][next][prev][last][first]---------------------------------------------------- Date: 7 Oct 90 00:04:48 GMT From: zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!news@tut.cis.ohio-state.edu (Cliff Yamamoto) To: tcp-ip@nic.ddn.mil Subject: Our Sun isn't "RIPing"
Greetings network gurus!
We have a Sun Sparc+ running as a file server and router for our building's
LAN. We also have a Banyan server running as passive router on the same
physical ethernet. On this same ethernet, we have various PCs. Some are
running PC-NFS while others are running PC/TCP on top of Vines. A picture
is probably in order:
PC . . . PC . . . PC . . . etc Banyan
| | | +--Server--+
| | | | | x.x.63.1
+-----------+-----------+---------------+----------+-----------+
x.x.63.10 x.x.91.20 x.x.91.21 x.x.63.107 x.x.91.1 |
Sun
Sparc+
where: x.x.63.x is Tcp/Ip & NFS |
x.x.91.x is Banyan/Vines x.x.1.137 x.x.1.xxx |
x.x.1.xx is Labwide backbone ----------------------------+
| | x.x.1.165
Sun other
A hosts & subnets
The situation:
- We have /etc/gateways on the Sun Sparc+ configured as required.
- All the PCs on the 63.x and 91.x subnets can ping each other fine.
- All the PCs on the 63.x can ping the x.x.1.xxx hosts and vice-versa.
- The Sun Sparc+ can ping all hosts on all subnets.
The problem:
- NONE of the 91.x hosts can ping the x.x.1.xxx hosts and vice-versa.
The probable cause?
- The Sun Sparc+ is not sending out RIP info to the hosts on x.x.1.xxx
about the 91.x subnet.
The test:
- We added an explicit /etc/gateway routing entry at Sun A. It basically
tells Sun A that all x.x.91.0 traffic should route to x.x.1.165 with a
metric of 1 and passive. THIS WORKED!! Sun A was able to ping all PCs
on the 91.x subnet and vice-versa.
The question:
So does anyone know what causes this? We don't have access to a sniffer so
it makes it difficult to see if the Sparc+ is sending out info. Is there
something we missed? Any help would be appreciated.
Thanks in advance!
Cliff Yamamoto
-----------[000094][next][prev][last][first]---------------------------------------------------- Date: Sun 7 Oct 90 22:44:48-PDT From: William "Chops" Westfield <BILLW@mathom.cisco.com> To: shelby!msi.umn.edu!cs.umn.edu!peiffer@decwrl.dec.com Cc: tcp-ip@nic.ddn.mil Subject: Re: SLIP, IP Routers and Named Pipes
Does anyone know of a product that supports [cslip]? SLIP is sssoooo easy to configure slip on an Annex. It seems like a shame to waste it, but ftp and telnet are so gawdawfully slow even over a 38.4k link that I still resist putting it in place. Really? FTP is slow? Our experience at cisco (with our own terminal servers, of course) was that FTP was quite zippy - the sliding window of TCP bought you much more than you lost from the big headers. Compared to DEC-20 to PC kermit, FTP's FTP over slip was nearly twice as fast. Telnet, however, was quite painful, and I don't even want to think about running telnet and FTP at the same time. BillW -------
-----------[000095][next][prev][last][first]---------------------------------------------------- Date: 7 Oct 90 22:50:12 GMT From: bionet!turbo.bio.net!lear@apple.com (Eliot) To: tcp-ip@nic.ddn.mil Subject: Re: Need a RARP Demon
Kory Hamzeh asks for information on a PD rarpd. I don't know about rarpd, but would bootp serve your purposes? -- Eliot Lear [lear@turbo.bio.net]
-----------[000096][next][prev][last][first]---------------------------------------------------- Date: 8 Oct 90 07:04:48 GMT From: wuarchive!zaphod.mps.ohio-state.edu!usc!neuro.usc.edu!dra@decwrl.dec.com (Diane Annala) To: tcp-ip@nic.ddn.mil Subject: Re: Please boycott Xircom
In article <NELSON.90Sep28233146@image.clarkson.edu> nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) writes: # #Prudent or not, you agreed to do so, yet you have not. That makes you #liars. I suggest to dear gentle readers that they keep that in mind. # # Xircom will be # discontinuing the shipment of the Packet Driver based # on the Clarkson Packet driver and will be replacing it # with a fully compliant Packet Driver developed # independently. # #You can bet your bippy I'm going to go over your "independently developed" #packet driver with a fine-toothed comb. Of course, Xircom could include a provision in their copyright notice forbidding nelson@image.clarkson.edu from disassembling, decompiling, or otherwise going over the new packet driver with a fine toothed comb.
-----------[000097][next][prev][last][first]---------------------------------------------------- Date: 8 Oct 90 20:39:29 GMT From: news!german@iuvax.cs.indiana.edu (Chad W. German) To: tcp-ip@nic.ddn.mil Subject: NCSA TELNET / BANYAN
Does anyone have Telnet running concurrently along with Banyan Vines network.... What set-up are you using. With Telnet installed on each workstation every thing works fine as long as your not logged into the file server. Once logged in or having Telnet reside on a network drive, the PC and network loses communications. I'm fimiliar with the way Novell can function with Telnet by the use of packet drivers..... What is the secret for Vines.....?? Thanks in advance for any info../
-----------[000098][next][prev][last][first]---------------------------------------------------- Date: 8 Oct 90 23:35:11 GMT From: gohp3!dc@uunet.uu.net (Darren Croke) To: tcp-ip@nic.ddn.mil Subject: Re: TCP segment size -- user defined?
In article <256@ubeaut.oz.au> mwp@ubeaut.oz.au (Michael Paddon) writes: > > text deleted > >There is not much point setting TCP_MSS to be greater than > (maximum IP packet size - IP header size - TCP header size) >[536 octets] since IP fragmentation will take place. Receipt of a >fragmented packet is an all or nothing proposition; a good thing to >avoid for throughput reasons. > The 536 octects in brackets is the minimum but by no means always equal to (maximum IP packet size - IP header size - TCP header size). Look at the packets on an Ethernet sometime. I am running a 4.3 BSD TCP/IP implementation here that quite happily negotiates a MSS of 1000 bytes and then proceeds to send unfragmented 1000 byte packets. I think you will find that it is common for IP implementations to send and accept datagrams without fragmentation up to (connected network MTU - IP header size - TCP header size). Darren Croke. dc@graphon.com
-----------[000099][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 90 02:03:02 GMT From: smb@ulysses.att.com (Steven Bellovin) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: rfc1183: new RR types
I just retrieved an RFC defining some new RR types for the DNS. A few things bother me. First, it isn't clear to me that X25 address and ISDN address should be separate types. There are a number of other media where a similar record is needed, such as the Datakit VCS(R) and dial-up SLIP or PPP. I think I'd prefer a media address RR, with a subtype field first. I understand why in some cases one might opt for different records (and the matter is discussed in the RFC for an Andrew File System RR), but I'd vote differently than did the authors. My reasoning is simple: there are, I think, many different media for which the concept is applicable. If the vendor supports media address, I can create my own subtypes; it's much harder to add new RR types without the vendor's name server source. Second, it isn't clear to me who should be using the Route Through RR. Under what circumstances should a router do this (expensive) query? When there's no route to the host? To the network? What if the router doesn't have a direct link to the preferred forwarding host? Route towards is, and hope that the next hop knows enough to use the new record? I'm not saying RT is a bad idea, or hasn't been thought through; I am saying that I'd like to see some discussion on how it's intended to be used in a real Internet. --Steve Bellovin smb@ulysses.att.com
-----------[000100][next][prev][last][first]---------------------------------------------------- Date: 9 October 1990 15:15:13 CDT From: <DANIEL@UIUCVMD> To: <tcp-ip@nic.ddn.mil> Subject: .netrc equivalent
I'm porting an UNIX/VMS TCP/IP based application written in C to VM/CMS. This application normally refers to the .netrc file to get password information. Are there any convensions on CMS for the equivalent? Also, the program does not like to send the password across the net in clear text so it calls the standard UNIX crypt command to do the DES encryption of the password. Is the DES encription available on VM/CMS systems if I don't own the standard IBM box to do this? What is the standard calling procedure for programs using an IBM DES configuration? -- Daniel Pommert pommert@uiuc.edu
-----------[000101][next][prev][last][first]---------------------------------------------------- Date: Tue, 9 Oct 90 14:15:17 EDT From: fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca To: TCP-IP@NIC.DDN.MIL Subject: Reply to Re: Ethernet Address Uniqueness...
In my recent message about DECNET Ethernet address non-uniqueness I should have mentioned that my site works in a mixed DECNET - TCP/IP environment (plus Appletalk, etc.). Problems arise in VAXes which run both DECNET and TCP/IP on the same Ethernet interface - the Ethernet address used in ARP responses depends on whether DECNET was started before or after TCP/IP, because DECNET changes the Ethernet address in the interface hardware (in RAM memory). If the TCP/IP software uses the modified DECNET Ethernet address then there might be address duplication because IP addresses are connection oriented, not node oriented. ________________________ Bob Fillmore, Systems Software & Communications BITNET: FILLMORE@EMRCAN Computer Services Centre, BIX: bfillmore Energy, Mines, & Resources Canada Voice: (613) 992-2832 588 Booth St., Ottawa, Ontario, Canada K1A 0E4 FAX: (613) 996-2953
-----------[000102][next][prev][last][first]---------------------------------------------------- Date: Tue, 9 Oct 90 18:46:29 -0500 From: jbvb@ftp.com (James B. Van Bokkelen) To: zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!news@tut.cis.ohio-state.edu (Cliff Yamamoto) Cc: tcp-ip@nic.ddn.mil Subject: Re: Our Sun isn't "RIPing"
VINES servers act as very simple IP routers, and as far as I know do not support any dynamic routing protocols (no RIP). If the Sun doesn't hear about about the VINES subnet via RIP, it has to be told via a static route. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000103][next][prev][last][first]---------------------------------------------------- Date: Tue, 9 Oct 90 18:46:31 -0500 From: jbvb@ftp.com (James B. Van Bokkelen) To: fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca Cc: TCP-IP@NIC.DDN.MIL Subject: Re: Reply to Re: Ethernet Address Uniqueness...
This is a standard gotcha of using protocols that change the address. There is no solution other than to make sure that DECNet is always started before anything else that cares about the Ethernet address. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000104][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 90 13:35:29 GMT From: usenet.ins.cwru.edu!po.CWRU.Edu!cjs@tut.cis.ohio-state.edu (Christopher J. Seline) To: tcp-ip@nic.ddn.mil Subject: How do I make 'calls' to Standford TCPIP for the PC
Hi, We've got Stanford's PC TCPIP software on our PCs. Is there some type of standard for placing calls to it? thanks in advance, cjs@cwru.cwru.edu
-----------[000105][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 90 13:44:06 GMT From: sun-barr!newstop!texsun!letni!mic!supernet!gtoye@decwrl.dec.com (Gene Toye) To: tcp-ip@nic.ddn.mil Subject: Info on TN3270 Protocol
Does anyone know where I can get a specification for the protocol
used by TN3270 for communicating with the IBM host/controller?
I specifically mean the protocol for data to/from the TN3270 application,
not SNA or 3270 Data Stream.
Thanks for your assistance.
--
Gene Toye: Harris Adacom Corporation / 16001 Dallas Pkwy. / Dallas, TX 75248
Internet: gtoye@supernet.haus.com or gtoye@supernet.lonestar.org
Usenet: uunet!{iex,ntvax}!supernet!gtoye
DISCLAIMER: My employer never knows what I am going to say next.
-----------[000106][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 90 14:54:01 GMT From: PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD) To: comp.protocols.tcp-ip Subject: in-addr.arpa used?
Our name server, on a VM system, receives reverse mapping queries.
One reason found is mailing on Unix systems, that also produces other
strange requests (sendmail.mx on SunOS, see below).
I am wondering how many such requests will come from the Internet when
we will be connected.
So, my question is: how useful is it to ask our administrators
to implement their in-addr.arpa domains?
Is it usually done?
Andr'e PIRARD SEGI, Univ. de Li`ege
B26 - Sart Tilman B-4000 Li`ege 1 (Belgium)
pirard@vm1.ulg.ac.be or PIRARD@BLIULG11 on EARN/BITNET
Received: from BLIULG11 by BLIULG11 (Mailer R2.07) with BSMTP id 5355; Tue, 09
Oct 90 15:49:11 +0100
Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP R1.2.2MX)
with TCP; Tue, 09 Oct 90 15:49:09 +01
Received: from rib1 ([139.165.8.17]) by montefiore.ulg.ac.be (4.0/SMI-4.0)
id AA08359; Tue, 9 Oct 90 15:49:38 +0100
Received: by rib1 (4.0/SMI-4.0)
id AA06469; Tue, 9 Oct 90 15:49:26 +0100
Date: Tue, 9 Oct 90 15:49:26 +0100
From: pirard@montefiore.ulg.ac.be (PIRARD ANDRE tel 4932 SEGI)
Message-Id: <9010091449.AA06469@rib1>
To: pirard@vm1.ulg.ac.be
datagram from 139.165.16.1 port 2013, fd 8, len 43
req: nlookup(17.8.165.139.in-addr.arpa) id 2 type=12
req: missed '17.8.165.139.in-addr.arpa' as '' (cname=0)
forw: forw -> 139.165.2.1 8 (53) nsid=80 id=2 3225ms retry 6 sec
datagram from 139.165.2.1 port 53, fd 8, len 43
send_msg -> 139.165.16.1 (UDP 11 2013) id=2
datagram from 139.165.16.1 port 2014, fd 8, len 42
req: nlookup(vm1.montefiore.ulg.ac.be) id 3 type=1
req: found 'vm1.montefiore.ulg.ac.be' as 'vm1.montefiore.ulg.ac.be' (cname=0)
req: answer -> 139.165.16.1 11 (2014) id=3 Local
datagram from 139.165.16.1 port 2015, fd 8, len 31
req: nlookup(vm1.ulg.ac.be) id 4 type=1
req: found 'vm1.ulg.ac.be' as 'vm1.ulg.ac.be' (cname=0)
req: answer -> 139.165.16.1 11 (2015) id=4 Local
datagram from 139.165.16.1 port 2016, fd 8, len 31
req: nlookup(vm1.ulg.ac.be) id 5 type=15
req: found 'vm1.ulg.ac.be' as 'vm1.ulg.ac.be' (cname=0)
req: answer -> 139.165.16.1 11 (2016) id=5 Local
-----------[000107][next][prev][last][first]---------------------------------------------------- Date: Tue, 09 Oct 90 15:54:01 +0100 From: Andr'e PIRARD <PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU> To: tcp-ip@nic.ddn.mil, IBM TCP/IP List <IBMTCP-L@PUCC> Subject: in-addr.arpa used?
Our name server, on a VM system, receives reverse mapping queries.
One reason found is mailing on Unix systems, that also produces other
strange requests (sendmail.mx on SunOS, see below).
I am wondering how many such requests will come from the Internet when
we will be connected.
So, my question is: how useful is it to ask our administrators
to implement their in-addr.arpa domains?
Is it usually done?
Andr'e PIRARD SEGI, Univ. de Li`ege
B26 - Sart Tilman B-4000 Li`ege 1 (Belgium)
pirard@vm1.ulg.ac.be or PIRARD@BLIULG11 on EARN/BITNET
Received: from BLIULG11 by BLIULG11 (Mailer R2.07) with BSMTP id 5355; Tue, 09
Oct 90 15:49:11 +0100
Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP R1.2.2MX)
with TCP; Tue, 09 Oct 90 15:49:09 +01
Received: from rib1 ([139.165.8.17]) by montefiore.ulg.ac.be (4.0/SMI-4.0)
id AA08359; Tue, 9 Oct 90 15:49:38 +0100
Received: by rib1 (4.0/SMI-4.0)
id AA06469; Tue, 9 Oct 90 15:49:26 +0100
Date: Tue, 9 Oct 90 15:49:26 +0100
From: pirard@montefiore.ulg.ac.be (PIRARD ANDRE tel 4932 SEGI)
Message-Id: <9010091449.AA06469@rib1>
To: pirard@vm1.ulg.ac.be
datagram from 139.165.16.1 port 2013, fd 8, len 43
req: nlookup(17.8.165.139.in-addr.arpa) id 2 type=12
req: missed '17.8.165.139.in-addr.arpa' as '' (cname=0)
forw: forw -> 139.165.2.1 8 (53) nsid=80 id=2 3225ms retry 6 sec
datagram from 139.165.2.1 port 53, fd 8, len 43
send_msg -> 139.165.16.1 (UDP 11 2013) id=2
datagram from 139.165.16.1 port 2014, fd 8, len 42
req: nlookup(vm1.montefiore.ulg.ac.be) id 3 type=1
req: found 'vm1.montefiore.ulg.ac.be' as 'vm1.montefiore.ulg.ac.be' (cname=0)
req: answer -> 139.165.16.1 11 (2014) id=3 Local
datagram from 139.165.16.1 port 2015, fd 8, len 31
req: nlookup(vm1.ulg.ac.be) id 4 type=1
req: found 'vm1.ulg.ac.be' as 'vm1.ulg.ac.be' (cname=0)
req: answer -> 139.165.16.1 11 (2015) id=4 Local
datagram from 139.165.16.1 port 2016, fd 8, len 31
req: nlookup(vm1.ulg.ac.be) id 5 type=15
req: found 'vm1.ulg.ac.be' as 'vm1.ulg.ac.be' (cname=0)
req: answer -> 139.165.16.1 11 (2016) id=5 Local
-----------[000108][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 90 18:44:31 GMT From: maytag!focsys!larry@iuvax.cs.indiana.edu (Larry Williamson) To: tcp-ip@nic.ddn.mil Subject: telnet & rlogin set /dev/ttyp* mod differently
people that rlogin to machines here have their /dev/ttp* entries mod's set differently. In particular, if one telnets, then /dev/ttyp* is set with mod 111, whereas if one logs in with rlogin, then it is set 666. Why is this? How can I define what the setting should be? I don't want to put chmod commands in /etc/profile or the user's profiles. the systems involved here are Interactive's 386/ix 2.2. Rlogins and telnets are from many different types of machines and terminal servers. -Larry
-----------[000109][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 90 20:15:13 GMT From: DANIEL@UIUCVMD To: comp.protocols.tcp-ip Subject: .netrc equivalent
I'm porting an UNIX/VMS TCP/IP based application written in C to VM/CMS. This application normally refers to the .netrc file to get password information. Are there any convensions on CMS for the equivalent? Also, the program does not like to send the password across the net in clear text so it calls the standard UNIX crypt command to do the DES encryption of the password. Is the DES encription available on VM/CMS systems if I don't own the standard IBM box to do this? What is the standard calling procedure for programs using an IBM DES configuration? -- Daniel Pommert pommert@uiuc.edu
-----------[000110][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 90 20:28:02 GMT From: mcsun!ukc!dcl-cs!aber-cs!athene!pcg@uunet.uu.net (Piercarlo Grandi) To: tcp-ip@nic.ddn.mil Subject: Re: What is a UNIX Domain Socket?
On 27 Sep 90 18:06:32 GMT, harvey@dg-rtp.dg.com (Michael Harvey) said: harvey> In article <82@unigold.UUCP>, lance@unigold.UUCP (Lance harvey> Ellinghouse) writes: lance> Ok, I know this is a dumb question.. What exactly is a Unix lance> Domain Socket? What makes it different from a INET Socket? harvey> A socket is simply a communication endpoint. Sockets support harvey> two communications domains: the UNIX domain for harvey> process-to-process communication on the same host, and the harvey> Internet domain for process-to-process communication between harvey> hosts that communicate with one another using the DARPA standard harvey> communication protocols, such as IP, TCP, and UDP. harvey> In the UNIX domain, socket names are UNIX pathnames; harvey> for example, a socket may be named /tmp/foo. harvey> Naming sockets in the Internet domain involve concatenating harvey> the Internet address with a port number. harvey> I think that covers the basics. Comments? I think I can do better :-). Under Unix all out-of-address space communication (except for ptrace(2) and signals) is via file descriptors; file descriptors have a common interface, based on read/write readv/writev, and ioctl(), etc..., and a type. One of the types of a file descriptor is socket; when a file descriptor is a socket, it is attached using a full duplex channel to another socket file descriptor somewhere. Socket file descriptors have a number of properties that normal file descriptors do not have; among these are the type of communication (stream, message, etc...), an identifier, two modes of connecting a socket to another for transmitting data, and whether there is the possibility to transmit file descriptors over the channel. Socket file descriptors are supported by a a set of protocol implementations called a 'domain'; only sockets in the same domain may be connected. The UNIX domain is a domain where there is only one socket type, only one protocol, the pipe protocol, where the only socket type allowed is stream, where socket identifiers are pathnames in the UNIX filesystem, and where filedescriptors may be passed thru the communication channel between two sockets. By contrast the INET domain supports three socket types (stream, datagram and raw), a number of protocols, socket identifiers are internet 32 bit numbers, and filedescriptors may not be passed thru the channel between two sockets. Many other domains exist. In the original 4.2BSD design it was to be possible to have user processes implement domains, by putting the protocol code in the user process, and having all communications between two sockets in that user domain be interepted by the user process implementing that domain. This is still possible by using the UNIX domain, even if in a contrived way (in particular it is not possible to support other than stream sockets), by having users for that domain connect in the UNIX domain to the user implemented domain server, that would return a socket in that domain (actually a socket to itself, usually, in the UNIX domain). -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
-----------[000111][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 90 21:29:05 GMT From: elroy.jpl.nasa.gov!aero!obrien@decwrl.dec.com (Michael O'Brien) To: tcp-ip@nic.ddn.mil Subject: Use of TCP/IP with satellite delays
Someone recently asked a question about use of TCP/IP over a satellite link, and since I've never worked in that realm, the ground got mushy under my feet. I'd like a reality check. I seem to recall that TCP/IP is perfectly usable over a satellite link that has reasonably high bandwidth, but 300msec propagation delays. Adaptive retransmission and multi-packet frames get around this problem, no? Of course, char-at-a-time telnet will lose no matter what, but mail and file transfers should move acceptably, right? More specifically I'm talking about something like a KA9Q implementation running via satellite radio link from a research vessel at sea. -- Mike O'Brien obrien@aerospace.aero.org
-----------[000112][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 90 21:53:06 GMT From: mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu (Bob Sutterfield) To: tcp-ip@nic.ddn.mil Subject: Re: in-addr.arpa used?
In article <9010091715.AA05649@ucbvax.Berkeley.EDU> PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD) writes:
...how useful is it to ask our administrators to implement their
in-addr.arpa domains? Is it usually done?
See RFC1123 ("Requirements for Internet Hosts -- Application and
Support"), section 6.1.1:
Every host MUST implement a resolver for the Domain Name
System (DNS), and it MUST implement a mechanism using this
DNS resolver to convert host names to IP addresses and
vice-versa [DNS:1, DNS:2].
Yes, it's very useful. It's usually done. Addresses for which
reverse mapping is not maintained are not in conformance to the
applicable standards, and should receive a firm finger-wagging. If
your local administrators hesitate, bash them over the head with a
printed copy of RFC1123, all 98 pages.
Hmmm, I just noticed upon closer reading that this requirement only
applies to the resolver that must be available on each host. It
doesn't say that an authoritative reverse mapping must be available
(from some name server somewhere) for every address. So bash them
gently, if you must :-)
-----------[000113][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 90 22:18:43 GMT From: ubc-cs!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bwdls56!fortinp@beaver.cs.washington.edu (Pierre Fortin) To: tcp-ip@nic.ddn.mil Subject: Re: SLIP, IP Routers and Named Pipes
In article <12628063537.11.BILLW@mathom.cisco.com>, BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes: > > Does anyone know of a product that supports [cslip]? SLIP is > sssoooo easy to configure slip on an Annex. It seems like a shame > to waste it, but ftp and telnet are so gawdawfully slow even over > a 38.4k link that I still resist putting it in place. > > Really? FTP is slow? Our experience at cisco (with our own terminal > servers, of course) was that FTP was quite zippy - the sliding window > of TCP bought you much more than you lost from the big headers. Compared > to DEC-20 to PC kermit, FTP's FTP over slip was nearly twice as fast. Care to share the test configuration with us? I use SLIP over a Microcom AX/9624c MNP Class 6 modem and a cisco terminal server. I see the modem lights grinding away, waiting..., grinding away, waiting..., etc. It's almost as though the VJ algorithms were throttling... I found I could get more files through by starting 2-3 FTPs so that one is still running when the other 1-2 are stalled. Sort of round-robin FTP transfers; doesn't work if I've only got one file to transfer though... :^( > > Telnet, however, was quite painful, and I don't even want to think about > running telnet and FTP at the same time. When you're FTPing and your only link is tied up, you're quite happy to be able to get *any* response to keep working. If only I had what ammounts to "local echo" or tn3270-type buffering on telnet over SLIP... sigh. > > BillW > ------- Pierre Fortin Bell-Northern Research I know, my postings are Internet Systems P.O.Box 3511, Stn C terse and humourless. So? (613)763-2598 Ottawa, Ontario RIP: aptly named protocol fortinp@bnr.ca Canada K1Y 4H7 AppleTalk: Adam&Eve's design
-----------[000114][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 90 22:58:36 GMT From: apple.com!erekose@apple.com (Erik Scheelke) To: tcp-ip@nic.ddn.mil Subject: File Broadcast
We have a local area network of UNIX based PCs running TCP-IP, and I was asked if there was any software that will broadcast a file to all machines on the network. I didn't know of any and was wondering if anyone out there in netland knew of any. If not, I guess I will have to write something myself. I would appreciate any infomation about programs or algorithms that do file broadcasting. It must use a broadcast, not a copy to one machine then copy to another method (i.e. UDP), and if a machine is up it must reliably send the file. Thanks in advance for any help! Erik Scheelke
-----------[000115][next][prev][last][first]---------------------------------------------------- Date: Wed, 10 Oct 90 10:51:51 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) To: elroy.jpl.nasa.gov!aero!obrien@decwrl.dec.com, tcp-ip@nic.ddn.mil Subject: Re: Use of TCP/IP with satellite delays
It works fine. TELNET on the other hand is something of a pain. I have done a TELNET connection between Stuttgart-Vaihingen, FRG and Westlake Village CA (LA area) with two satellite hops and a 9600 baud link between Westlake and Marina Del Rey. Found you forget what you typed and can almost go out- side for a smoke waiting for the echo. Merton
-----------[000116][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 90 23:16:54 GMT From: spdcc!dyer@husc6.harvard.edu (Steve Dyer) To: tcp-ip@nic.ddn.mil Subject: Bad SLIP performance (was Re: SLIP, IP Routers and Named Pipes)
I think your problems are more to do with the nature of your modems
than any inherent problems with medium speed SLIP links. I lived for
two years quite happily with a LADS circuit supporting a full time
point-to-point SLIP connection running at 19.2kb. No fancy modems,
just a pair of local data sets. 19.2kb SLIP is subjectively quite
reasonable, and I found that even on a heavily loaded line supporting
NNTP, a couple of telnet/rlogin sessions, regular SMTP traffic and the
occasional FTP, the delay wasn't all THAT bad.
All bets are off when you start talking about pseudo-full-duplex modems
like Telebit Trailblazers or MNP6, or noisy lines or lossy serial interfaces.
But let's identify *these* as potential areas of problems, and not tar
the underlying technology unjustly.
--
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
-----------[000117][next][prev][last][first]---------------------------------------------------- Date: 10 Oct 90 03:16:26 GMT From: brunix!euclid.math.temple.edu!freedman@uunet.uu.net (Avi Freedman) To: tcp-ip@nic.ddn.mil Subject: Can I use the Berkeley lp protocol for remote DOS prints from COM1?
I've got NCSA telnet configured and printing remotely off of a Sun, but is there any commercial/pd program out there which lets me trap what goes to com1/com2/prn from an application? (I've got an application which can't print to a file). Any pointers would be greatly appreciated. - Avi
-----------[000118][next][prev][last][first]---------------------------------------------------- Date: Wed 10 Oct 90 12:24:44-PDT From: William "Chops" Westfield <BILLW@mathom.cisco.com> To: fortinp@bnr.ca Cc: tcp-ip@nic.ddn.mil Subject: Re: SLIP, IP Routers and Named Pipes
>
> Really? FTP is slow? Our experience at cisco (with our own terminal
> servers, of course) was that FTP was quite zippy - the sliding window
> of TCP bought you much more than you lost from the big headers. Compared
> to DEC-20 to PC kermit, FTP's FTP over slip was nearly twice as fast.
Care to share the test configuration with us? I use SLIP over a
Microcom AX/9624c MNP Class 6 modem and a cisco terminal server. I
see the modem lights grinding away, waiting..., grinding away,
waiting..., etc. It's almost as though the VJ algorithms were
throttling... I found I could get more files through by starting 2-3
FTPs so that one is still running when the other 1-2 are stalled.
Sort of round-robin FTP transfers; doesn't work if I've only got one
file to transfer though... :^(
The configuration was a 286 based PC clone running either (old, non-sliding
window, 92 byte packet) MSDOS kermit or FTP software's package v 1.16,
connected vai a 19.2kbps direct line to aa cisco terminal server (v6.1
software? This was slightly before SLIP was released on the cisco TS)
We were talking to either HPUX or TOPS20 (no VJ algorthims in sight!)
FTP software was configured with a window size of 1024, and an MSS of 512,
if I remember correctly. It's sort of important (with no slow start) that
the number of MSS packets in a window be both larger than 1 and smaller than
the effective queue-size on the terminal server (then 3, now settable). (Your
description of the problem sounds exactly like the MSS is > window/2, so that
you end up operating lock-step instead of sliding windows, by the time SWS
algorithms come into play.)
FTP file transfer speeds were about 13kbps, while kermit was about half that.
I haven't done those tests in a couple of years, though - I would hope that
everything still works at least as well as it did then!
Bill Westfield
cisco Systems.
-------
-----------[000119][next][prev][last][first]---------------------------------------------------- Date: 10 Oct 90 06:04:40 GMT From: cbmvax!grr@uunet.uu.net (George Robbins) To: tcp-ip@nic.ddn.mil Subject: Re: is syslog(3) to remote possible?
In article <111@fedeva.UUCP> bill@fedeva.UUCP (Bill Daniels) writes:
> I posted a similar request about a week or two ago. Just as luck would
> have it my news machine went away for a couple of days right afterwards.
>
> I have need to log operator messages via syslog(3) on a remote machine. I
> am sure that this is possible because of the way the docs and headers read.
> It seems however that Ultrix has coded up syslog() so that all messages go
> to the local machine.
The Ultrix syslog seems to be able to capture and display remote syslog
messages, but doesn't seem to be able to direct it's own messages to
another system.
Other people have claimed that the BSD 4.3 syslog stuff is easy to get
working with Ultrix, but I haven't tried it (yet).
Note that having Ultrix syslog capture messages originating from a Sun system
results in a ugly syslog file, apparently there is some format divergence.
--
George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing: domain: grr@cbmvax.commodore.com
Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
-----------[000120][next][prev][last][first]---------------------------------------------------- Date: Wed, 10 Oct 90 10:29:26 EDT From: Chris Weider <clw@merit.edu> To: system@lns61.tn.cornell.edu, tcp-ip@nic.ddn.mil Subject: re: Reply to Ethernet Address Uniqueness...
In a recent message (10/5), Selden E. Ball, Jr. states that:
>Of course, the fact that DECnet addresses are limited to 16 bits
>means that larger networks are limited to a maximum of about 64K
>systems. My guess is that there are fewer than a dozen networks
>for which this causes problems.
I think this estimate is conservative. :)
On CICNet, we've had to jerry-rig our routers to get a true heirarchical
DECNet architechture; I suspect that a lot of other regionals have had to also.
I'm eagerly awaiting DECnet Phase 5.
Chris Weider
-----------------------------------------------------------------------------
Chris Weider | -Geteilte Freude ist
MERIT's CICNet Technical Rep. | doppelte Freude
email: clw@merit.edu | -Goethe
Phone: (313) 936-2090 or | -Party on, dudes!
1-800-66-MERIT | -Abraham Lincoln, "Bill and Ted"
-----------[000121][next][prev][last][first]---------------------------------------------------- Date: 10 Oct 90 13:54:58 GMT From: mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu (Bob Sutterfield) To: tcp-ip@nic.ddn.mil Subject: Re: Bad SLIP performance (was Re: SLIP, IP Routers and Named Pipes)
In article <4401@spdcc.SPDCC.COM> dyer@spdcc.COM (Steve Dyer) writes: All bets are off when you start talking about pseudo-full-duplex modems like Telebit Trailblazers or MNP6, or noisy lines or lossy serial interfaces. But let's identify *these* as potential areas of problems, and not tar the underlying technology unjustly. We see very reasonable performance with compressed-header SLIP or PPP between Sun-4/60s over a pair or Trailblazer Plusses: 1.3-1.5Kb/sec FTP throughput with PPP, nearing the modem's advertised pipe diameter. Interactive response OK too, though not what you'd call "pleasant" if you're used to fatter hoses. I haven't tried high values of MNP or HST. Don't bother with Classic SLIP, particularly not with TBs.
-----------[000122][next][prev][last][first]---------------------------------------------------- Date: 10 Oct 90 16:36:46 GMT From: clyde.concordia.ca!news-server.csri.toronto.edu!utgpu!cunews!mentor.gandalf.ca!ddrg@uunet.uu.net (Duncan Glendinning) To: tcp-ip@nic.ddn.mil Subject: Re: Use of TCP/IP with satellite delays
In article <88084@aerospace.AERO.ORG> obrien@aero.aero.org (Michael O'Brien) writes:
>Someone recently asked a question about use of TCP/IP over a satellite
>link, and since I've never worked in that realm, the ground got mushy
>under my feet. I'd like a reality check.
>
>I seem to recall that TCP/IP is perfectly usable over a satellite link
>that has reasonably high bandwidth, but 300msec propagation delays.
>Adaptive retransmission and multi-packet frames get around this problem,
>no? Of course, char-at-a-time telnet will lose no matter what, but
>mail and file transfers should move acceptably, right?
>
>More specifically I'm talking about something like a KA9Q implementation
>running via satellite radio link from a research vessel at sea.
>--
>Mike O'Brien
>obrien@aerospace.aero.org
We've successfully run SLIP over a satelite link between our offices
here in Ottawa, and both Wheeling IL, and Warrington UK. Though a bit
slow for interactive use (9600 baud) it was possible. The primary
use was for large (>1M byte) file transfers, where we saw better
throughput than kermit. Here are some results:
Wheeling IL to Ottawa Ont:
file size: 2744320 bytes ftp: 76 min kermit: 995 min
Please note that the 9600 baud channel is just one of a number that
are stat muxed.
--
Duncan Glendinning CAnet: ddrg@mentor.gandalf.ca, ddrg@gandalf.ca
Gandalf Data Ltd. Voice: (613) 723-6500
Nepean, Ontario Fax: (613) 226-1717
Canada K2E 7M4
-----------[000123][next][prev][last][first]---------------------------------------------------- Date: 10 Oct 90 17:11:02 GMT From: psuvm!drj100@psuvax1.cs.psu.edu (Daniel R. Jeuch) To: tcp-ip@nic.ddn.mil Subject: Re: Bad SLIP performance (was Re: SLIP, IP Routers and Named Pipes)
In article <BOB.90Oct10095447@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) says: > >We see very reasonable performance with compressed-header SLIP or PPP >between Sun-4/60s over a pair or Trailblazer Plusses: 1.3-1.5Kb/sec >FTP throughput with PPP, nearing the modem's advertised pipe diameter. >Interactive response OK too, though not what you'd call "pleasant" if >you're used to fatter hoses. I haven't tried high values of MNP or >HST. > >Don't bother with Classic SLIP, particularly not with TBs. Unfortunately, here at Penn State, all we have is MNP5 9600 V.32 dial-in lines... I get throughput with classic SLIP (PSU also doesn't use compression) of somewhere between .8-.9kb/sec. Not great, but it's free for Penn State students... (Kind of important for my budget!) TN3270 does suffer, though! ----- Daniel R. Jeuch Microsoft Corp. Student Rep. 10 Vario Blvd., Box 185 DRJ100@PSUVM, drj100@psuvm.psu.edu State College, PA 16803 (814) 867-4622, (800) 232-5129
-----------[000124][next][prev][last][first]---------------------------------------------------- Date: 10 Oct 90 18:00:22 GMT From: timbuk!redwood22!nrd@uunet.uu.net (Neal Dalton) To: tcp-ip@nic.ddn.mil Subject: I there a Compressed SLIP for Sun OS 4.1
I've seen slip for Sun OS 4.1 and am tring to find out how to implement cslip on Sun OS 4.1
In cslip for Sun OS 4.0 they provided a tty driver modified for compression. Will this
work for OS 4.1 or did 4.1 fix the problems with 4.0.
--
Neal /\ / _ / \|||/ Neal Dalton
/ \ / _ _\ / / \ Cray Research, inc
/ \/_</_(_/\_/ ( o o ) _________ 655-F Lone Oak Dr.
\ ^ / / \ Eagan, MN 55121
\ 0 / < OH NO, )
Internet: nrd@cray.com \_/ \ not him!/ Fax: (612) 683-5599
uucp: uunet!cray!nrd \_______/ Phone: (612) 683-5607
-----------[000125][next][prev][last][first]---------------------------------------------------- Date: 10 Oct 90 18:12:47 GMT From: GHOLAN@vm.ucs.UAlberta.CA (Geoffrey Holan) To: comp.protocols.appletalk,comp.protocols.tcp-ip Subject: runing ka9q on appletalk
Has anyone got the localtlk packet driver working, this is for use with a ka9q router. I am unable to load-up the correct appletalk drivers for localtlk to talk to. I am using the lsl.com, atalk.com and ltalkp.com, but none of them seem to be the proper driver(s) that localtlk needs to use to talk to the ibm pc appletalk board. I am using the 7 version of Clarkson's packet drivers.. any hints would be appr. thanks
-----------[000126][next][prev][last][first]---------------------------------------------------- Date: 10 Oct 90 23:18:00 EDT From: "SWEIGERT, DAVID" <dsweigert@paxrv-nes.navy.mil> To: "tcp-ip" <tcp-ip@nic.ddn.mil> Subject: SNMP Agent by Proxy
From: David Sweigert supporting U.S. Special Operations Command We are trying to find the public domain software for a SNMP package that can run off a PC. We would like to modify the source code to acquire data from a Veristron TCU. Anyone know where we can get an SNMP Agent for a PC. ??? po box 4423 annapolis, md 21403 301-637-5098
-----------[000127][next][prev][last][first]---------------------------------------------------- Date: 10 Oct 90 20:03:07 GMT From: pacbell.com!pacbell!dplace!hicom!toshiya@decwrl.dec.com (Toshiya Itoh) To: tcp-ip@nic.ddn.mil Subject: Connectathon??
Does anybody know the word "Connectathon?" (may not be right spell) I heard it's the name of a kind of competition of TCP/IP implementations. If it was true, how can I get the information about the result of this competition? Thank you very much in advance, Toshiya Itoh. ========================================================== Software Engineer Hitachi Computer Products Inc. 3101 Tasman Dr. Santa Clara, Ca. 95054 E-mail t_itoh@hitachi.com ==========================================================
-----------[000128][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 90 00:22:25 GMT From: munnari.oz.au!metro!natmlab.dap.csiro.au!megadata!andrew@uunet.uu.net (Andrew McRae) To: tcp-ip@nic.ddn.mil Subject: Looking for in_cksum for 68k.
Does anyone have a 68000 specific in_cksum routine for doing IP checksums? I have been using the machine independent version, but I have looked at the VAX and CCI routines that came with the 4.3 BSD network source, and it seems it would be a big win to have a 68k version. I am actually running a 68000 rather than a 68020, but a 68020 version would be useful as a starting point. Thanks! Andrew McRae inet: andrew@megadata.mega.oz.au Megadata Pty Ltd, uucp: ..!uunet!megadata.mega.oz.au!andrew North Ryde 2113 Phone: +61 2 805 0899 NSW AUSTRALIA Fax: +61 2 887 4847
-----------[000129][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 90 03:14:33 GMT From: pyrdc!pyrnj!bartal!monymsys!sonyd1.Broadcast.Sony.COM!blilly.UUCP!balilly.UUCP!bruce@uunet.uu.net (Bruce Lilly) To: tcp-ip@nic.ddn.mil Subject: Re: Ethernet Address Uniqueness...
In article <linegar.655064040@bwdls49> linegar@bwdls49.bnr.ca (Derick Linegar) writes: > >[ ... ] > Now I've been searching the RFC and IEEE docs and I cannot >find any documentation that sort of says that Ethernet Addresses are assigned >to Ethernet boards, not hosts. > >Anyone have an idea where it might be. I cannot go back to the vendor and >say > > " .... well everyone *knows* that ethernet addresses *must* be unique..." ``For information on global (U) address administration contact the Secretary, IEEE Standards Board, 345 East 47 Street, New York, NY 10017.'' (Footnote on page 26 of ANSI/IEEE Standard 802.3-1985 ISO/DIS 8802/3) My recollection is that each manufacturer is assigned a group of addresses and is expected to make the hardware address unique for each interface. As has been pointed out (for the specific case of DECnet) it is also possible to override the hardware address via software, and that may be a part of your problem. The IEEE Secretary ought to be able to clarify this situation, and may be able to tell you what range of addresses are assigned to your particular vendor. Late flash: after checking several references, I found: ``14.4.2 Ethernet addresses Host computers on Ethernet are identified by two addresses, the Ethernet address (a 48-bit hardware address) and an IP or software address. Ethernet addresses are guaranteed unique because vendors building Ethernet interfaces have a set of addresses assigned to them. The IEEE Standards Board in New York City assigns the first 24 bits to a manufacturer, which then allocates the last 24 bits sequentially. The address is either built into the interface board or stored in ROM on the board.'' (From _UNIX(R)_System_Administration_Handbook_ by Nemeth, Snyder, and Seebass, published by Prentice-Hall, p. 243) An excellent book, by the way, although it is heavily biased toward BSD. Note however that the IEEE standard permits either 16-bit or 48-bit addresses, so don't take that too literally. Hope this helps. -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
-----------[000130][next][prev][last][first]----------------------------------------------------
Date: 11 Oct 90 03:18:00 GMT
From: dsweigert@PAXRV-NES.NAVY.MIL ("SWEIGERT, DAVID")
To: comp.protocols.tcp-ip
Subject: SNMP Agent by ProxyFrom: David Sweigert supporting U.S. Special Operations Command We are trying to find the public domain software for a SNMP package that can run off a PC. We would like to modify the source code to acquire data from a Veristron TCU. Anyone know where we can get an SNMP Agent for a PC. ??? po box 4423 annapolis, md 21403 301-637-5098
-----------[000131][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 90 09:14:00 CDT From: "Nunez, Paul" <nunez@tawc1.eglin.af.mil> To: "tcp-ip" <tcp-ip@nic.ddn.mil> Subject: Need SMB Info
I need information on SMB. I've seen it referred to as both Server Message Block protocol and Server Management Block protocol - which is correct? Where can I get more information on what it is and how it works? Also, would those of you running in an SMB client/server environment please pass on information concerning your server product (Company names, phone numbers, problems, etc.). I am especially interested in a comparison of Wollongong's SMB server product vs. Syntax's. Someone told me Syntax's product (name unknown) is licensed by Wollongong (is OEM'd the correct term?). Is this true? We have 6 uVAX 3600's running VMS 5.3-1 and Wollongong's WIN/TCP for VMS V5.1. Please reply to me directly; I'll summarize and post if enough interest. Thanks, ======================================================================= PAUL E. NUNEZ (nunez@tawc1.eglin.af.mil) or (nunez@uv4.eglin.af.mil) USAFTAWC/SCAM EGLIN AFB, FL 32542 (904-882-4100)
-----------[000132][next][prev][last][first]---------------------------------------------------- Date: Thu, 11 Oct 90 11:41:41 EDT From: Frank Kastenholz <kasten%europa.interlan.com@RELAY.CS.NET> To: munnari.oz.au!metro!natmlab.dap.csiro.au!megadata!andrew@UUNET.UU.NET, tcp-ip@NIC.DDN.MIL Subject: Re: Looking for in_cksum for 68k.
>
> Does anyone have a 68000 specific in_cksum routine for
> doing IP checksums?
>
> I have been using the machine independent version,
> but I have looked at the VAX and CCI routines that came
> with the 4.3 BSD network source, and it seems it would be
> a big win to have a 68k version. I am actually running a
> 68000 rather than a 68020, but a 68020 version would be
> useful as a starting point.
Look at RFC 1071....
1071 Braden, R.T.; Borman, D.A.; Partridge, C. Computing the Internet
checksum. 1988 September; 24 p. (Format: TXT=54941 bytes) (Updated by
RFC 1141)
Frank Kastenholz
Racal Interlan
-----------[000133][next][prev][last][first]---------------------------------------------------- Date: Thu, 11 Oct 90 11:59:26 EDT From: Bob Stratton <dsc3rjs@nmdsc20.nmdsc.nnmc.navy.mil> To: TCP-IP@NIC.DDN.MIL Subject: traceroute on 3B2/600 under TWG's TCP/IP
Hello all, I am in the process of porting traceroute to an AT&T 3B2/600 with the AT&T Enhanced WIN/3B TCP/IP software from Wollongong. Will the IPPROTO_RAW work as delivered? I noticed that the docs for traceroute indicate a mod to the BSD kernel's raw IP output routine is required, but I have no clue as to whether the same is true for System V/3.2.2. On execution, I get SO_SNDBUF: Bad protocol option, which would lead me to believe that there is some lower-lever work needed. Of course, if I #undef SO_SNDBUF, the code runs, but all I see are lines with "* * *". Failing that, does anyone know where I might find a version of traceroute already written for System V machines? Thanks in advance! Bob Stratton | dsc3rjs@nmdsc20.nmdsc.nnmc.navy.mil [DDN/Internet] NAVMEDATASERVCEN | dsc3rjs@vmnmdsc [BITNET] (Innova Comms. / AT&T) | 295-3371 [AV] +1 301 295 3371 [PSTNet]
-----------[000134][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 90 10:21:18 GMT From: mcsun!i2unix!alessia!athena@uunet.uu.net (Matteo Frigo) To: tcp-ip@nic.ddn.mil Subject: Strange bahaviour of an LSX3020 with tcp protocol
I have an Olivetti LSX3020 with Ethernet card, 8Mb ram and 280MB hard disk. I am on Internet. I have this problem: I can connect to Europe from here (Padova, Italy) and and to East Coast (NY and Boston), but I cannot have any tcp service from Berkeley, ucsd and so on. Next to the LSX I have a Sun 3 which works and has no problem in telnetting and ftp-ing to the entire world. I suspect it is a problem of timeouts, but I have absolutely no idea of where to put my hands on. I noted the machine worked before the new link between CNUCE and SURA, and in some moments it works again for a few minutes. Any help would be appreciated. I am quite disperate because the LSX acts as nameserver and mail exchanger for the domain dei.unipd.it, as other machines cannot be used for that for technical and administrative reasons, and my system has stopped working with no apparent reason. Matteo Frigo athena@alessia.dei.unipd.it ( try to reply with athena%alessia.dei.unipd.it@mcsun.eu.net because of these problems)
-----------[000135][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 90 13:35:25 GMT From: van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bwdlh131!mleech@ucbvax.Berkeley.EDU (Marcus Leech) To: tcp-ip@nic.ddn.mil Subject: Re: Use of TCP/IP with satellite delays
In article <88084@aerospace.AERO.ORG>, obrien@aero.aero.org (Michael O'Brien) writes: > More specifically I'm talking about something like a KA9Q implementation > running via satellite radio link from a research vessel at sea. KA9Q works very well in this type of environment--Phils round-trip-timer algorithm is generally acknowledged to be the best in the business. It's quite accurate, and converges quickly. I've used KA9Q over a satellite link between Ottawa, and Calgary. Provided you have a low BER, you can simply crank up your TCP WINDOW and MSS and expect to get quite good performance for FTP, etc. ----------------- Marcus Leech, 4Y11 Bell-Northern Research |opinions expressed mleech@bnr.ca P.O. Box 3511, Stn. C |are my own, and not VE3MDL@VE3JF.ON.CAN.NA Ottawa, ON, CANADA |necessarily BNRs
-----------[000136][next][prev][last][first]----------------------------------------------------
Date: 11 Oct 90 14:14:00 GMT
From: nunez@TAWC1.EGLIN.AF.MIL ("Nunez, Paul")
To: comp.protocols.tcp-ip
Subject: Need SMB InfoI need information on SMB. I've seen it referred to as both Server Message Block protocol and Server Management Block protocol - which is correct? Where can I get more information on what it is and how it works? Also, would those of you running in an SMB client/server environment please pass on information concerning your server product (Company names, phone numbers, problems, etc.). I am especially interested in a comparison of Wollongong's SMB server product vs. Syntax's. Someone told me Syntax's product (name unknown) is licensed by Wollongong (is OEM'd the correct term?). Is this true? We have 6 uVAX 3600's running VMS 5.3-1 and Wollongong's WIN/TCP for VMS V5.1. Please reply to me directly; I'll summarize and post if enough interest. Thanks, ======================================================================= PAUL E. NUNEZ (nunez@tawc1.eglin.af.mil) or (nunez@uv4.eglin.af.mil) USAFTAWC/SCAM EGLIN AFB, FL 32542 (904-882-4100)
-----------[000137][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 90 17:15:34 GMT From: usc!cs.utexas.edu!execu!sequoia!cb@ucsd.edu (Christopher D. Brown) To: tcp-ip@nic.ddn.mil Subject: TCP/IP (socket library) for MS Windows 3
Execucom is building an MS Windows 3.0 software product
which supports TCP/IP using the socket library model.
Frankly, we were hoping that Sun would have already
delivered the supporting network software ... In any case,
we need to get on with this aspect of the project and are
looking for commercial software supporting TCP/IP via
sockets under Windows 3 (including 386 enhanced mode).
I am doubtful about using the public domain software so
frequently discussed here. This route would seem to require
a good deal more technical expertise than a commercial
package. A commercial package would also seem to reduce
legal difficulties when reselling the software. Is this too
conservative?
"Network Windows (TM) Software Development Kit" from
Distinct Corporation in Saratoga, CA claims to meet my
requirements. I would appreciate hearing from anyone who
has experience with this product and/or company. Pointers
to alternate products would be gratefully accepted.
If there appears to be any interest, I post any alternate
vendors and product reviews.
Thanks in advance.
Chris
--
Christopher D. Brown
Digital: {uunet|cs.utexas.edu}!execu!cb
Analog: (512) 327-7070
Physical: Execucom, 108 Wild Basin Road, Two Wild Basin, Austin, TX 78764
-----------[000138][next][prev][last][first]---------------------------------------------------- Date: Thu, 11 Oct 90 16:38:43 +0100 From: "Alain FONTAINE (Postmaster - NAD)" <af%sei.ucl.ac.be@CUNYVM.CUNY.EDU> To: TCP-IP@NIC.DDN.MIL Subject: Re: Heathkit Weather Computer (IDW5001)
On Wed, 3 Oct 90 16:24:46 GMT David M. Siegel said: >would be nice to use a "standard" weather TCP/UDP protocol for this >purpose. Ideally, all Internet sites with weather data could support >this protocol. The protocol should be extensible, since it is hard to >anticipate all types of weather data that people might have. > >I'm wondering, does such a protocol exist? > This question has been discussed some months ago. The conclusion was that no new protocol is needed: this is an ideal application for SNMP. Just define a weather-report MIB.... P.S. I tried a private reply, but it was bounced at uunet..... Alain FONTAINE +--------------------------------+ Universite Catholique de Louvain | If your mail software barks at | Service d'Etudes Informatiques | my address, you may try : | Batiment Pythagore | | Place des Sciences, 4 | FNTA80@BUCLLN11.BITNET | B-1348 Louvain-la-Neuve, BELGIUM +--------------------------------+ phone +32 (10) 47-2625 z * * * 47745578 'Alain FONTAINE (Pos David M. Siegel 10/11/90*Heathkit Weather Computer (IDW
-----------[000139][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 90 23:55:50 GMT From: jay@axiom.maths.uq.oz.au (Joseph Young) To: comp.protocols.appletalk,comp.dcom.lans,comp.protocols.tcp-ip Subject: Mac Access to TCP/IP
I'm faced with the following configuration:
+-----+ +-----+
! Mac ! ! IBM !
+--+--+ ! PCs !
! +--------+ +--+--+
Novell Trunk - LocalTalk ! Novell ! Novell Trunk - Ethernet !
-------------+----------------+ File +----------+-----------------+--->
! Server ! !
+--------+ !
(NetWare 2.15) +--+---+
!Bridge!(Brand: Wellfleet)
!Router!
+--+---+
Ethernet to remote hosts ! (TCP/IP)
---------------------------------------+-----------------------
Question: How can I get the Macintoshes on the Novell LocalTalk trunk talking
to the remote hosts on the Ethernet running TCP/IP. The type of
services I'm interested in are Telnet, FTP and mail.
Any help would be greatly appreciated .. I'm fairly new at this type of thing.
Joe Young
jay@axiom.maths.uq.oz.au
-----------[000140][next][prev][last][first]---------------------------------------------------- Date: 12 October 1990 0933-PDT (Friday) From: stanonik@nprdc.navy.mil (Ron Stanonik) To: tcp-ip@nic.ddn.mil Subject: Re: Re: Ethernet Address Uniqueness...
The 10base5 NI cards in our AT&T 3b2's were all delivered with the same ethernet address. This was a big surprise, because we too had come to expect manufacturer's would assign unique addresses. The similar ethernet addresses didn't cause any problems because the IP layer in each machine filtered out only those packets destined for the local machine. Everyone ARP'ed to the same ethernet address. Sort of like multicasting (unicasting?). We didn't realize what was happening until packet tracing to find an unrelated problem. We've since found an undocumented command which allows setting the ethernet address and the machines now all have unique ethernet addresses. Ron Stanonik stanonik@nprdc.navy.mil
-----------[000141][next][prev][last][first]---------------------------------------------------- Date: Fri, 12 Oct 90 07:40:58 EDT From: R17G000 <R17G@UNB.CA> To: <TCP-IP@NIC.DDN.MIL> Subject: Can I use the Berkeley lp protocol for remote DOS prints fromCOM1?
> I've got NCSA telnet configured and printing remotely off of a Sun, but > is there any commercial/pd program out there which lets me trap what goes > to com1/com2/prn from an application? (I've got an application which > can't print to a file). Any pointers would be greatly appreciated. > > - Avi Could you please post your findings to the list if applicable or forward them to me at R17G@UNB.CA ? Thanks in advance. ---------------------------------------------------------------+ Abdulaziz Al-Zoman | R17G@UNB + Faculty of Computer Science | -or- | University of New Brunswick | r17g@unb.ca + F'ton, N.B | -or- | CANADA E3B 5A3 | r17g@unb.bitnet + ---------------------------------------------------------------+
-----------[000142][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 90 07:42:56 GMT From: mintaka!olivea!samsung!sol.ctr.columbia.edu!ira.uka.de!i32fs2!nipper@bloom-beacon.mit.edu (Arnold Nipper) To: tcp-ip@nic.ddn.mil Subject: Re: access to polydos.uni-konstanz.de
In article <1627.655631099@munnari> kre@MUNNARI.OZ.AU (Robert Elz) writes: >For TCP-IP reades, this was (part of a message) sent to INFO-NETS ... > > Date: Wed, 10 Oct 90 22:44:14 PDT > From: netinfo@violet.berkeley.edu (Postmaster & BITINFO) > Message-ID: <9010110544.AA12667@violet.berkeley.edu> > > I get to Germany in 17 hops, then beyond 188.1.132.24 (21st hop) > packets appear to go into a black hole. > >I didn't believe that number when I first saw it ... thought >it must be a typo, or something, so I just had to try it >for myself... > >But sure enough, its correct, there is something out there, >pretending to be net 188.1, and connected to the Internet. Yes, the netname is WIN-IP (WIssenschaftsNetz) and this net is an IP/X.25 net connecting most of the German universities and other research institutions. > >Unless some very strange thigs have happened, net 188.1 is >not yet allocated to anyone (and perhaps by the time it is >no-one will really care anyway, as its so close to the end >of the available class B numbers). Certainly there are no >allocated 188.* nets listed in the NIC's network-contacts.txt >file. Nets 188.1 - 191.254 are preallocated to what is called PDN cluster. This net clustering is the basis for the PDN cluster addressing scheme which uses it to do efficient routing. Contact C.-H. Rokitansky ( roki@dhafeu52.bitnet ) to get more information about this. He is the former chairman of the IETF working group on PDN. > >Is there some proper person to get in contact with these >people and politely, or very impolitely, suggest that if >they want to be connected to the internet, they should be >using properly allocated numbers? > For more information about this, please contact: Martin Wilhelm Verein zur Foerderung eines Deutschen Forschungsnetzes (DFN) e.V. Zentrale Projektleitung Pariser Strasse 40 W-1000 Berlin 15 Federal Republic of Germany +49 30 884299 30 wilhelm@zpl.dfn.dbp.de If you have problems to reach uni-konstanz.de please contact me or: Jochen Bruening University of Konstanz Universitaetsstrasse 10 Postfach 5560, D-7750 Konstanz +49 7531 88 2410 rzbng@dknkurz1.bitnet >Its no wonder that routing isn't working... Net 188.1 is only the backbone for IP/WIN. Therefor there should be no problems to reach any site in Germany connected to the internet. Of course if you want to connect to some backbone machine with a 188.1 address you will fail. Arnold ******************************************************************************** Arnold Nipper *** Universitaet Karlsruhe, Am Fasanengarten 5 * nipper@ira.uka.de XLINK, Inst. fuer Betr.- und Dialogsysteme, D-7500 Karlsruhe * +49 721 608 4331 ********************************************************************************
-----------[000143][next][prev][last][first]---------------------------------------------------- From: lefty@TWG.COM To: tcp-ip@nic.ddn.mil Subject: Re: Connectathon??
>Does anybody know the word "Connectathon?" (may not be right spell) > >I heard it's the name of a kind of competition of TCP/IP implementations. Connectathon is actually an interoperability testing event for ONC/NFS implementations. Many vendors who have NFS products set them up on a shared network and attempt to run a standard set of test suites in an attempt to get everybody's implementations to work against everybody else's. Connectathon 1991 is scheduled to be held this coming March, in San Jose. -- David N. Schlesinger | Internet: lefty@twg.com The Wollongong Group | AppleLink: D6122 1129 San Antonio Road | AOL: lefty3 Palo Alto, CA 94303 |
-----------[000144][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 90 09:09:26 GMT From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) To: comp.protocols.tcp-ip Subject: Re: Use of TCP/IP with satellite delays
>>Someone recently asked a question about use of TCP/IP over a satellite >>link, and since I've never worked in that realm, the ground got mushy >>under my feet. I'd like a reality check. You should see paper by Seo et al in sigcomm 88 for measurement of TCP & IP over SATNET - the relevant bits include: slow start and mean+variance RTT estimator TCP over the atalantic packet satellite network - even a mere RSRE algoritm RTT TCP ran in service over SATNET for a decade ...it just isnt a problem any more :-) jon
-----------[000145][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 90 10:12:49 GMT From: apple.com!erekose@apple.com (Erik Scheelke) To: tcp-ip@nic.ddn.mil Subject: Reliable Datagram Protocols
Does anyone know of a reliable connectionless datagram protocol that runs on top of UDP? Is so, is there a library out there I can get? Thanks in advance, Erik Scheelke
-----------[000146][next][prev][last][first]---------------------------------------------------- Date: Thu, 11 Oct 90 17:44:59 +1000 From: Robert Elz <kre@munnari.oz.au> To: netinfo@violet.berkeley.edu (Postmaster & BITINFO) Cc: info-nets@Think.COM, TCP-IP@Nic.DDN.MIL Subject: Re: access to polydos.uni-konstanz.de
For TCP-IP reades, this was (part of a message) sent to INFO-NETS ...
Date: Wed, 10 Oct 90 22:44:14 PDT
From: netinfo@violet.berkeley.edu (Postmaster & BITINFO)
Message-ID: <9010110544.AA12667@violet.berkeley.edu>
I get to Germany in 17 hops, then beyond 188.1.132.24 (21st hop)
packets appear to go into a black hole.
I didn't believe that number when I first saw it ... thought
it must be a typo, or something, so I just had to try it
for myself...
But sure enough, its correct, there is something out there,
pretending to be net 188.1, and connected to the Internet.
Unless some very strange thigs have happened, net 188.1 is
not yet allocated to anyone (and perhaps by the time it is
no-one will really care anyway, as its so close to the end
of the available class B numbers). Certainly there are no
allocated 188.* nets listed in the NIC's network-contacts.txt
file.
Is there some proper person to get in contact with these
people and politely, or very impolitely, suggest that if
they want to be connected to the internet, they should be
using properly allocated numbers?
Its no wonder that routing isn't working...
kre
-----------[000147][next][prev][last][first]---------------------------------------------------- Date: Fri, 12 Oct 90 10:09:26 +0100 From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> To: ddrg@mentor.gandalf.ca Cc: tcp-ip@nic.ddn.mil Subject: Re: Use of TCP/IP with satellite delays
>>Someone recently asked a question about use of TCP/IP over a satellite >>link, and since I've never worked in that realm, the ground got mushy >>under my feet. I'd like a reality check. You should see paper by Seo et al in sigcomm 88 for measurement of TCP & IP over SATNET - the relevant bits include: slow start and mean+variance RTT estimator TCP over the atalantic packet satellite network - even a mere RSRE algoritm RTT TCP ran in service over SATNET for a decade ...it just isnt a problem any more :-) jon
-----------[000148][next][prev][last][first]---------------------------------------------------- Date: Fri, 12 Oct 90 13:56:28 MEZ From: Ewald Jenisch <Z00EJR01%AWIUNI11@pucc.PRINCETON.EDU> To: tcp-ip@nic.ddn.mil Subject: ISO Country codes
Does anybody out there in the netland know where I can find a listing
of all ISO Country Codes. As far as I remember there was such a list
hanging around for anonymous FTP but I don't remember which server.
Thanks in advance for any help,
Ewald JENISCH
University Computer Center
University of Vienna, Austria
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-mail: Z00EJR01@AWIUNI11.BITNET Snail-mail:
Z00EJR01@helios.edvz.univie.ac.at Universitaetsstrasse 7
Tel.: (+43 222) 43-61-11/251 A-1010 Vienna, Austria
Fax: (+43 222) 43-61-11/170 Europe
-----------[000149][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 90 16:43:53 GMT From: Z00EJR01%AWIUNI11@PUCC.PRINCETON.EDU (Ewald Jenisch) To: comp.protocols.tcp-ip Subject: ISO Country codes
Does anybody out there in the netland know where I can find a listing
of all ISO Country Codes. As far as I remember there was such a list
hanging around for anonymous FTP but I don't remember which server.
Thanks in advance for any help,
Ewald JENISCH
University Computer Center
University of Vienna, Austria
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-mail: Z00EJR01@AWIUNI11.BITNET Snail-mail:
Z00EJR01@helios.edvz.univie.ac.at Universitaetsstrasse 7
Tel.: (+43 222) 43-61-11/251 A-1010 Vienna, Austria
Fax: (+43 222) 43-61-11/170 Europe
-----------[000150][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 90 17:04:24 GMT From: sdd.hp.com!uakari.primate.wisc.edu!aplcen!haven!ni.umd.edu!sayshell.umd.edu!louie@ucsd.edu (Louis A. Mamakos) To: tcp-ip@nic.ddn.mil Subject: Re: Looking for in_cksum for 68k.
In article <347@megadata.mega.oz.au> andrew@megadata.mega.oz.au (Andrew McRae) writes: >Does anyone have a 68000 specific in_cksum routine for >doing IP checksums? The is the checksum routing that I use in the Amiga port of the KA9Q TCP/IP package. It seems to work. louie ; ; Compute the 1's complement sum of data buffer. Called from C as ; ; unsigned short ; lcsum(buf, cnt) ; unsigned short *buf; ; unsigned short cnt; ; ; _lcsum: MOVE.L 4(A7),A0 ; get pointer to data block MOVE.L 8(A7),D1 ; get number of 16bit words to sum MOVE D2,A1 ; save D2 in a volitile register MOVE D1,D2 ; save a copy of the count LSR.L #1,D1 ; convert from words to longs MOVEQ.L #0,D0 ; D0 used to accumulate the sum, clear CC BRA.S endl ; jump to end of loop to start things off ; ; Take advantage of 68010 loop mode cache and add 2 words at a time until ; a carry propagates out. 68020 users win 'cause of instruction cache. ; loop: ADD.L (A0)+,D0 ; add two words in endl: DBCS D1,loop BCC.S done ; jump if done ADDQ.L #1,D0 ; add in carry BRA.S endl ; resume loop done: BTST #0,D2 ; was word count odd? BEQ.S done2 MOVEQ.L #0,D2 MOVE.W (A0),D2 ; get the last word ADD.L D2,D0 ; add it in BCC.S done2 ; did that cause a carry? ADDQ.L #1,D0 ; yes done2: MOVE.L A1,D2 ; restore register MOVE.L D0,D1 ; get copy of sum D0=ABCD D1=ABCD SWAP.W D1 ; into low order part of D1 D0=ABCD D1=CDAB AND.L #$FFFF,D1 ; zap (is this necessary?) D0=ABCD D1=00AB ADD.W D0,D1 ; two halfs of sum together MOVEQ.L #0,D0 ADDX.W D0,D1 ; get last carry MOVE.W D1,D0 RTS
-----------[000151][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 90 19:42:09 GMT From: media-lab!media-lab.media.mit.edu!dnb@eddie.mit.edu (David N. Blank) To: tcp-ip@nic.ddn.mil Subject: netdiag?
Howdy-
In my travels along the anonymous ftp byways I encountered a file
called netdiag.tar.Z that had what appeared to be a really handy
network debug/display tool with some problems:
1) It was a set of Sun 3 binaries with no source code that ran only
under Suntools.
2) The README file was truncated at 512 bytes, (in mid-sentence,
even).
3) There were not docs external to the program.
Does anyone have any information on this program and where I could get
a more complete version of it? Thanks muchly in advance.
Peace,
dNb
-----------[000152][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 90 23:00:10 GMT From: sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!atmos.washington.edu!harry@ucsd.edu (Harry Edmon) To: tcp-ip@nic.ddn.mil Subject: Where can I find source to PPP or SLIP?
Where can I get source to PPP or SLIP for SunOS 4.1? Please mail responses directly to me. Thanks. -- Harry Edmon INTERNET: harry@atmos.washington.edu (206) 543-0547 UUCP: uw-beaver!atmos.washington.edu!harry Dept of Atmospheric Sciences, AK-40 University of Washington
-----------[000153][next][prev][last][first]---------------------------------------------------- Date: 13 Oct 90 00:21:43 GMT From: excelan!donp@ames.arc.nasa.gov (don provan) To: tcp-ip@nic.ddn.mil Subject: Re: Ethernet Address Uniqueness...
In article <1990Oct5.123350.145@arizona.edu> leonard@arizona.edu writes: >I believe that Novell's IPX similarly hacks the Ethernet address.... This has nothing to do with TCP-IP, but i don't want this rumor to spread. IPX does not modify the ethernet address. don provan donp@novell.com
-----------[000154][next][prev][last][first]---------------------------------------------------- Date: 13 Oct 90 03:44:02 GMT From: sdd.hp.com!uakari.primate.wisc.edu!caen!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu (Edward Vielmetti) To: tcp-ip@nic.ddn.mil Subject: connect: Network is unreachable, (or) I want my FTP
From: emv@math.lsa.umich.edu (Edward Vielmetti) My site gets a feed of the sub.* and dnet.* newsgroups, which are in German. There is a fair amount of interesting stuff discussed in these groups, and it's a good way to put that high school German to practice. More to the point, there is a fair amount of software developed in Germany which is made available for anonymous FTP, that is to say stuff available there and nowhere else. So, when I see in sub.tex that there's an interesting set of TeX macros to be had from "forwiss.uni-passau.de", my first inclination is to go and take a look and get them. And the last thing that I want to see is "Network is unreachable" with the traceroute stopping at my local NSS. It is extremely frustrating, that I can learn about European internet resources via Usenet, but when I go to connect to the the NSF backbone blocks my access. Do any of the USA "commercial" internet service providers provide access to the European networks which aren't permitted to use the NSF backbone? I.e., if my regional network were to get say an Alternet or PSI connection they could receive the Euro-routes that way and there would be access. Or perhaps my regional already has a transatlantic link, and they could bypass the backbone that way? One way or another there has to be a legit way to be "part of" the Euro-internet and not get blockaded by the NSF. --Ed Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu> moderator, comp.archives ps. forwiss.uni-passau.de [132.231.1.10], in /archive/tex/macros/nice20.zoo. "Jetzt hoffe ich, dass das Makropaket einen groesseren Kreis von Anwendern findet."
-----------[000155][next][prev][last][first]---------------------------------------------------- Date: 13 Oct 90 03:58:38 GMT From: jarthur!bridge2!api!gpz@uunet.uu.net (G. Paul Ziemba) To: tcp-ip@nic.ddn.mil Subject: TFTP: should ERROR be ACK-ed?
Please forgive me if this question has been beaten to death
in previous discussions; I am new to this group.
I have seen some TFTP clients exhibit the following behavior, and I
would like to know if it is correct:
1. client sends a RRQ (read request) to a server.
2. server decides it cannot perform the request,
so server sends an ERROR to the client.
3. client sends an ACK to the server.
Should the client have sent an ACK?
~!paul
--
Paul Ziemba api!gpz gpz@ESD.3com.com 408.764.5390 OS/2: just say no.
"How much char could a char star star if char star could star char?"
(quote stolen from mspercy@clemson.clemson.edu)
-----------[000156][next][prev][last][first]---------------------------------------------------- Date: 13 Oct 90 04:05:15 GMT From: swrinde!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu (Edward Vielmetti) To: tcp-ip@nic.ddn.mil Subject: Re: connect: Network is unreachable, (or) I want my FTP
In article <EMV.90Oct12224402@josephus.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: macros to be had from "forwiss.uni-passau.de", my first inclination is to go and take a look and get them. And the last thing that I want to see is "Network is unreachable" with the traceroute stopping at my My local friendly network service trouble desk informs me that the NSFnet has a request to add this to their routing tables, so I guess you should tone down some of the rhetoric of the previous message. --Ed Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu> moderator, comp.archives
-----------[000157][next][prev][last][first]---------------------------------------------------- Date: Sat, 13 Oct 90 16:26 EDT From: BIWINE%vassar.bitnet@pucc.PRINCETON.EDU To: tcp-ip@nic.ddn.mil Subject: Protocol analyzer
Is anyone aware of pd software that would turn a workstation (U*ix, VMS, MS-DOS, or Mac) into an Ethernet protocol analyzer? Thanks for your help. Bill Wine biwine@vassar.bitnet
-----------[000158][next][prev][last][first]---------------------------------------------------- Date: Sat, 13 Oct 90 19:08:22 -0400 From: Hans-Werner Braun <hwb@merit.edu> To: emv@math.lsa.umich.edu Cc: hwb@merit.edu, tcp-ip@nic.ddn.mil Subject: Re: connect: Network is unreachable, (or) I want my FTP
Ed Vielmetti:
Given all your frequent interactions with the Merit/UMnet/NSFNET NOC with
the hope for increased knowledge on your part about how things interact, I
find it regrettable that you have to air your frustrations in public, in
particular given the tone you used. Look, you describe access to a
University, for which in general NSF takes a quite liberal view. If there
is a University in at least a country that the US is friends with, NSF,
to the best of my knowledge, never objected to have them be known to the
NSFNET. With some international sites we need to get concurrance from a
national coordination body, in the case you mentioned, University of Passau in
Germany, we need concurrance from, e.g., DFN as a german national coordination
body. Once we receive a confirmation we need to request permission from
the NSF for each and every international network to be configured. The NSF
confirmation is to protect both NSF as well as Merit. Sometimes, including
in this case, where a network is requested to be configured via multiple NSS
entry points, we also need to confirm the announcements with all the sites a
network should be configured for, to allow for the proper coordination as
well as the proper metric configuration for primary, secondary, etc. paths.
All of this is standard procedure and should not take more than a few days.
If a network is unknown, it has typically either not been requested for
addition to the policy data base or it is not been dynamically announced
at the time you tried by the client network to the NSS where it would be
announced to or there is a time window between a request and the configuration
(which should typically not last for more than a few days and only happen once
until it is configured).
I will attach some relevant messages which show you that you got caught in the
window between request and configuration.
An intelligent approach towards dealing with these kind of issues would be to
communicate with your local provider of campus networking. Generally this
should work fine with most campuses, which then deal with the appropriate
regional network and/or the NSFNET NOC. In your case, as you know, they are
all the same (UMnet + Merit + NSFNET) and you should have been able to get the
information easily. You are otherwise wasting alot of time, effort and
bandwidth.
Hans-Werner Braun
-------------------------------------------------------------------------------
To: nsfnet-admin@merit.edu
Subject: Network Announcement Change Request
Cc: hostmaster@mcsun.EU.net, hostmaster@germany.eu.net, kaehler@zpl.dfn.dbp.de,
wilhelm@zpl.dfn.dbp.de, staff@sunic.sunet.se, ops@uunet.uu.net,
Ruediger Volk <unido!rv@relay.EU.net>
From: hostmaster@mcsun.EU.net
X-Organisation: EUnet/Alternet
X-Phone: +31 20 5924112
Date: Wed, 10 Oct 90 19:50:39 +0100
Sender: dfk@mcsun.EU.net
Hi,
Please add the following networks to the NSFnet routing database.
All networks are in Germany (no problems with east and west anymore :-).
All of them have ICS sponsored by NSF according to their admins.
Routing is coordinated within RIPE and US connectivity is via
EUnet/Alternet with backup via NORDUnet.
Thank you for your cooperation
Daniel Karrenberg
EUnet/Alternet Routing Contact
***** Network Announcement Change Request *****
Inbound Announcements Add/Del
to NSFNET or Change
--------------------------- ---------
Network Number/Name 1stAS# 2ndAS# 3rdAS# 4thAS# A/D/C Country
------------------- ------ ------ ------ ------ --------- -------
130.149 TUB 701 224 97 A Germany
132.180 UNIBT-LAN 701 224 97 A Germany
132.231 UNI-PASSAU 701 224 97 A Germany
134.100 UNIHH 701 224 97 A Germany
134.107 MPPMU-LAN 701 224 97 A Germany
141.1 DFN-WIN1 (ECRCNET) 701 224 97 A Germany
141.2 DFN-WIN2 (UNI-FFM) 701 224 97 A Germany
192.54.41 EMBNET 701 224 97 A Germany
------------------------------------------------------------------------------
Date: 12 Oct 90 15:47 GMT+0100
From: Martin Wilhelm <wilhelm%zpl.dfn.dbp.de@RELAY.CS.NET>
To: ip-register@MERIT.EDU
Cc: hostmaster%germany.eu.dbp.de@RELAY.CS.NET
Subject: Request for Handling
Sheri,
can you please process the following request of Ruediger Volk ?
All he institutes mentioned below belong to the academia and are members
of the DFN association.
Best regards and thanks a lot
-martin
------------------------------ cut here ---------------------------------
>From rv Mon Oct 8 07:57:35 1990
To: kaehler@zpl.dfn.dbp.de, wilhelm@zpl.dfn.dbp.de
Subject: Zulassung zum NSFnet
Cc: hostmaster@Germany.EU.net, hostmaster@noc.EU.net
Dear Colleagues,
please, forward this request to admit the following IP networks to use
the NSFnet backbone to MERIT.
To enable us and other people involved to follow the procedure and
help if anything should hang I suggest to use
Cc: hostmaster@noc.EU.net, hostmaster@Informatik.Uni-Dortmund.DE
on all transactions.
net name net number organization
DMSWWU-ETHER 128.176 Univ. Muenster
UEGNET 132.252 Univ. Essen
UNI-OLDENBURG 134.106 Univ. Oldenburg
WICOB 192.55.244 Wissenschaftskolleg Berlin
For the first three networks listed the appropriate NOCs will be sending
requests for including routing information into the NSFnet routing policy
data base in parallel.
The appropriate NOCs also will request routing support at MERIT for the
following networks, which - to my knowledge - already have NSF's approval;
for smoothing the procedure I ask you to confirm these networks to MERIT
as well.
Net name net number Organization
TUB 130.149 TU Berlin
UNIBT-LAN 132.180 Univ. Bayreuth
UNI-PASSAU 132.231 Uni Passau
UNIHH 134.100 Univ. Hamburg
MPPMU-LAN 134.107 MPI f. Physik, Munich
EMBNET 192.54.41 EMBL Heidelberg
DFN-WIN1 (ECRCNET) 141.1 ECRC Munich
DFN-WIN2 (UNIFFM-NET) 141.2 Univ. Frankfurt
Thanks for your cooperation,
Ruediger Volk
---------- End of Copy ----------
------------------------------------------------------------------------------
-----------[000159][next][prev][last][first]---------------------------------------------------- Date: 13 Oct 90 12:46:02 GMT From: usc!srhqla!quad1!ttidca!mb@ucsd.edu (Michael Bloom) To: tcp-ip@nic.ddn.mil Subject: Re: Looking for in_cksum for 68k.
In article <347@megadata.mega.oz.au> andrew@megadata.mega.oz.au (Andrew McRae) writes:
>Does anyone have a 68000 specific in_cksum routine for
>doing IP checksums?
>
>I have been using the machine independent version,
>but I have looked at the VAX and CCI routines that came
>with the 4.3 BSD network source, and it seems it would be
>a big win to have a 68k version. I am actually running a
>68000 rather than a 68020, but a 68020 version would be
>useful as a starting point.
A number of years back, I posted a request similar to yours and got
not a single response. So I went ahead and hand optimized the
assembly output from compiling the machine independent version,
taking a few hints from RFC 1071.
I measured about 35 % improvement over the straight C file compiled by
PCC. It might be the case that compiling the straight C source with
GNU C is nearly as good as (or perhaps better than) a hand optimized
version. I don't know. We didn't have gcc when I did this.
There's still almost certainly room for some more optimization. I'd like
to see your improvements.
I've been using this for a couple of years on our machines. If you
use it, please do not remove the notice at the start of the file.
By the way, although the routine won't be re-entered if you are using
the bsd networking code, if you are using some other networking code,
you might want to move s_util to the stack.
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create:
# in_cksum.s
# This archive created: Sat Oct 13 05:34:53 1990
export PATH; PATH=/bin:/usr/bin:$PATH
echo shar: "extracting 'in_cksum.s'" '(6279 characters)'
if test -f 'in_cksum.s'
then
echo shar: "will not over-write existing file 'in_cksum.s'"
else
sed 's/^ X//' << \SHAR_EOF > 'in_cksum.s'
X#
X# Please do not remove this comment.
X#
X# This file was created by Michael Bloom (mb@ttidca.tti.com) by hand
X# optimizing the assembly output from compiling the source file "in_cksum.c"
X# which is covered by the following notice allowing redistribution:
X#
X# /*
X# * Copyright (c) 1988 Regents of the University of California.
X# * All rights reserved.
X# *
X# * Redistribution and use in source and binary forms are permitted
X# * provided that this notice is preserved and that due credit is given
X# * to the University of California at Berkeley. The name of the University
X# * may not be used to endorse or promote products derived from this
X# * software without specific prior written permission. This software
X# * is provided ``as is'' without express or implied warranty.
X# *
X# * @(#)in_cksum.c 7.1 (Berkeley) 3/29/88
X# */
X#
X file "in_cksum.c"
X data 1
X lcomm s_util,2
X text
X global nin_cksum,in_cksum
X#
X# in_cksum(m,len)
X# m -> %a0
X# len -> %d2
X#
X# locals:
X# scratch: %a1,%d0,%d1
X# sum: %d3
X# mlen: %d4
X#
Xin_cksum:
Xnin_cksum:
X link.l %fp,&F%1
X movm.l &M%1,(4,%sp)
X mov.l (8,%fp),%a0 # m
X mov.l (12,%fp),%d2 # len
X
X clr.l ((S%1-4).w,%fp) # 59 int byte_swapped = 0;
X
X mov.l &0,%d3 # 60 register sum = 0;3
X mov.l &0,%d4 # register mlen = 0;
XL%cksm50: # 63 for (;m && len; m = m->m_next) {
X mov.l %a0,%d0
X beq L%cksm49
X tst.l %d2
X beq L%cksm49
X tst.w (%a0,8.w) # if (m->m_len == 0)
X beq L%cksm48 # continue;
XL%cksm51:
X mov.l %a0,%d0 # w = (( u_short *)((int)(m) + (m)->m_off));
X add.l (%a0,4.w),%d0 #
X mov.l %d0,%a1 #
X mov.l &-1,%d0 #
X cmp.l %d4,%d0 # if (mlen == -1) {
X bne.b L%cksm52
X# The first byte of this mbuf is the continuation of a word spanning
X# between this mbuf and the last mbuf. s_util.c[0] was already saved
X# when scanning previous mbuf.
X
X mov.b (%a1),s_util+1 # s_util.c[1] = *(char *)w;
X mov.l &0,%d0 #
X mov.w s_util,%d0 #
X add.l %d0,%d3 # sum += s_util.s;
X lea.l (%a1,1.w),%a1 # w = (u_short *)((char *)w + 1);
X mov.w (%a0,8.w),%d0 # mlen = m->m_len - 1;
X ext.l %d0 #
X sub.l &1,%d0 #
X mov.l %d0,%d4 # ""
X sub.l &1,%d2 # len--;
X bra.b L%cksm53 # } else {
XL%cksm52: # not a cont. of word spanning 2 mbufs
X mov.w (%a0,8.w),%d0 #
X ext.l %d0 #
X mov.l %d0,%d4 # mlen = m->m_len;
XL%cksm53: # }
X cmp.l %d2,%d4 # if (len < mlen)
X bge.b L%cksm54 #
X mov.l %d2,%d4 # mlen = len;
XL%cksm54: #
X sub.l %d4,%d2 # len -= mlen;
X# #
X# Force to even boundary #
X# #
X mov.l %a1,%d0 # if ((1 & (int) w) && (mlen > 0)) {
X and.l &1,%d0 #
X beq.b L%cksm55 #
X tst.l %d4 #
X ble.b L%cksm55 #
X mov.l %d3,%d0 # REDUCE
X swap %d0 #
X add.w %d0,%d3 #
X mov.l &0,%d0 #
X addx.w %d0,%d3 #
X and.l &0xffff,%d3 # ""
X
X lsl.l &8,%d3 # sum <<= 8;
X mov.b (%a1),s_util # s_util.c[0] = *(u_char *)w;
X lea.l (%a1,1.w),%a1 # w = (u_short *)((char *)w + 1);
X sub.l &1,%d4 # mlen--;
X mov.l &1,((S%1-4).w,%fp)# byte_swapped = 1;
X # }
XL%cksm55: # if ((2 & (int) w) && (mlen > 0)) {
X mov.l %a1,%d0 # if >= 2 bytes left and now
X and.l &2,%d0 # short aligned, add first
X beq.b L%cksm56 # short so rest is long
X mov.l &2,%d0 # aligned.
X cmp.l %d4,%d0 #
X blt.b L%cksm56 #
X mov.l &0,%d0 # sum += *w++;
X mov.w (%a1)+,%d0 #
X add.l %d0,%d3 #
X sub.l &2,%d4 # mlen-=2;
X # }
XL%cksm56:
X mov.l %d4,%d1 #
X mov.l %d1,%d0 #
X lsr.l &6,%d1 # number of times in loop = mlen/64
X and.l &0x3c,%d0 #
X neg.l %d0 #
X add.l %d0,%d4 #
X and.b &0xf,%cc #
X jmp 66(%pc,%d0.b) # jump into middle of table for first iter
Xnextloop:
X mov.l (%a1)+,%d0
X addx.l %d0,%d3
X mov.l (%a1)+,%d0
X addx.l %d0,%d3
X mov.l (%a1)+,%d0
X addx.l %d0,%d3
X mov.l (%a1)+,%d0
X addx.l %d0,%d3
X mov.l (%a1)+,%d0
X addx.l %d0,%d3
X mov.l (%a1)+,%d0
X addx.l %d0,%d3
X mov.l (%a1)+,%d0
X addx.l %d0,%d3
X mov.l (%a1)+,%d0
X addx.l %d0,%d3
X mov.l (%a1)+,%d0
X addx.l %d0,%d3
X mov.l (%a1)+,%d0
X addx.l %d0,%d3
X mov.l (%a1)+,%d0
X addx.l %d0,%d3
X mov.l (%a1)+,%d0
X addx.l %d0,%d3
X mov.l (%a1)+,%d0
X addx.l %d0,%d3
X mov.l (%a1)+,%d0
X addx.l %d0,%d3
X mov.l (%a1)+,%d0
X addx.l %d0,%d3
X mov.l (%a1)+,%d0
X addx.l %d0,%d3
Xendloop:
X mov.l &0,%d0 # (move does not affect X bit)
X addx.l %d0,%d3 # add in carry from addx last operation
X dbra %d1,nextloop # (dbra does not affect X bit)
X and.l &0x3,%d4 # above loop got all but possibly last 4 bytes
X # if (mlen == 0 && byte_swapped == 0)
X # continue
X bne.b L%cksm57
X tst.l ((S%1-4).w,%fp)
X beq.b L%cksm48
X# REDUCE
XL%cksm57:
X mov.l %d3,%d1
X swap %d1
X add.w %d1,%d3
X mov.l &0,%d0
X addx.w %d0,%d3
X and.l &0xffff,%d3
XL%cksm_11:
XL%cksm58: # while ((mlen -= 2) >= 0) {
X sub.l &2,%d4
X blt.b L%cksm59
X mov.l &0,%d0 # sum += *w++;
X mov.w (%a1)+,%d0
X add.l %d0,%d3
X bra.b L%cksm58 # }
XL%cksm59:
X tst.l ((S%1-4).w,%fp) # if (byte_swapped) {
X beq.b L%cksm60
X # REDUCE
X mov.l %d3,%d1
X swap %d1
X add.w %d1,%d3
X mov.l &0,%d0
X addx.w %d0,%d3
X and.l &0xffff,%d3
XL%cksm_13:
X lsl.l &8,%d3 # sum <<= 8;
X clr.l ((S%1-4).w,%fp) # byte_swapped = 0;
X mov.l &-1,%d0 # if (mlen == -1) {
X cmp.l %d4,%d0
X bne.b L%cksm61
X mov.b (%a1),s_util+1 # s_util.c[1] = *(char *)w;
X mov.l &0,%d0 # sum += s_util.s;
X mov.w s_util,%d0
X add.l %d0,%d3
X mov.l &0,%d4 # mlen = 0;
X # } else
X bra.b L%cksm62
XL%cksm61:
X mov.l &-1,%d4 # mlen = -1;
XL%cksm62:
X bra.b L%cksm63 # } else if (mlen == -1)
XL%cksm60:
X mov.l &-1,%d0
X cmp.l %d4,%d0
X bne.b L%cksm64
X mov.b (%a1),s_util # s_util.c[0] = *(char *)w;
X # }
XL%cksm64:
XL%cksm63:
XL%cksm48:
X mov.l (%a0),%a0
X bra L%cksm50
XL%cksm49:
X tst.l %d2 # if (len)
X beq.b L%cksm65
X data 2 # printf("cksum: out of data\n");
XL%cksm67:
X byte 'c,'k,'s,'u,'m,':,0x20,'o
X byte 'u,'t,0x20,'o,'f,0x20,'d,'a
X byte 't,'a,'\n,0x00
X text
X mov.l &L%cksm67,(%sp)
X jsr printf
XL%cksm65: # if (mlen == -1) {
X mov.l &-1,%d0
X cmp.l %d4,%d0
X bne.b L%cksm68
X clr.b s_util+1 # s_util.c[1] = 0;
X mov.l &0,%d0 # sum += s_util.s;
X mov.w s_util,%d0
X add.l %d0,%d3
X mov.l &0,%d0
X addx.l %d0,%d3 # handle carry
X # 183 }
X # REDUCE
XL%cksm68:
X mov.l %d3,%d1
X swap %d1
X add.w %d1,%d3
X mov.l &0,%d0
X addx.w %d3,%d0
X and.l &0xffff,%d0
X not.w %d0 # return (~sum & 0xffff);
X # 186 }
X movm.l (4,%sp),&M%1
X unlk %fp
X rts
X set S%1,0
X set T%1,0
X set F%1,-28
X set M%1,0x001c
X data 1
SHAR_EOF
if test 6279 -ne "`wc -c < 'in_cksum.s'`"
then
echo shar: "error transmitting 'in_cksum.s'" '(should have been 6279 characters)'
fi
fi
exit 0
# End of shell archive
-----------[000160][next][prev][last][first]---------------------------------------------------- Date: 13 Oct 90 14:22:55 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!i32fs2!nipper@ucsd.edu (Arnold Nipper) To: tcp-ip@nic.ddn.mil Subject: Re: connect: Network is unreachable, (or) I want my FTP
In article <EMV.90Oct12224402@josephus.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: >From: emv@math.lsa.umich.edu (Edward Vielmetti) > >My site gets a feed of the sub.* and dnet.* newsgroups, which are in >German. There is a fair amount of interesting stuff discussed in >these groups, and it's a good way to put that high school German to >practice. More to the point, there is a fair amount of software >developed in Germany which is made available for anonymous FTP, that >is to say stuff available there and nowhere else. > >So, when I see in sub.tex that there's an interesting set of TeX >macros to be had from "forwiss.uni-passau.de", my first inclination is >to go and take a look and get them. And the last thing that I want to >see is "Network is unreachable" with the traceroute stopping at my >local NSS. It is extremely frustrating, that I can learn about >European internet resources via Usenet, but when I go to connect to >the the NSF backbone blocks my access. That's not the right point of view. Obviously U Passau does not want to have access to the Internet. There are at least four access points to the Internet in Germany ( via EASInet, DFN, Unido, XLINK ). > >Do any of the USA "commercial" internet service providers provide >access to the European networks which aren't permitted to use the NSF >backbone? I.e., if my regional network were to get say an Alternet or >PSI connection they could receive the Euro-routes that way and there >would be access. Or perhaps my regional already has a transatlantic XLINK provides access to PSI net for everyone in Germany who wants. But of course you have to pay for services. :-) >link, and they could bypass the backbone that way? One way or another >there has to be a legit way to be "part of" the Euro-internet and not >get blockaded by the NSF. > >--Ed > Arnold ******************************************************************************** Arnold Nipper *** Universitaet Karlsruhe, Am Fasanengarten 5 * nipper@ira.uka.de XLINK, Inst. fuer Betr.- und Dialogsysteme, D-7500 Karlsruhe * +49 721 608 4331 ********************************************************************************
-----------[000161][next][prev][last][first]---------------------------------------------------- Date: 13 Oct 90 21:18:16 GMT From: sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU (Vernon Schryver) To: tcp-ip@nic.ddn.mil Subject: Re: Reply to Re: Ethernet Address Uniqueness...
In article <9010092346.AA29384@ftp.com>, jbvb@FTP.COM (James B. Van Bokkelen) writes: > This is a standard gotcha of using protocols that change the address. > There is no solution other than to make sure that DECNet is always > started before anything else that cares about the Ethernet address. I do not see the problem. When our DECNET stuff changes the MAC address as it starts, it tells the ethernet driver to call arpwhohas() again, just as if the driver were starting from scratch. The result is that the rest of the IP network sees nothing stranger than if you had quickly taken your system down, switched ethernet cards, and rebooted. The general mechanism can be encapsulated in an ioctl() so that all media can be wishywashy about MAC addresses. Changing ethernet MAC addresses using this ioctl() works just fine on our systems. I can't imagine anyone doing less (for DECNET if not the ioctl()), so I'm sure Sun, DEC, and the other UNIX DECNET vendors do the same or better. It is true that bad things happen if you try to start DECNET on two different boxes with the same node and area numbers, or otherwise try to share a single MAC address with more than one machine. However, this is not much worse than assigning a single IP address to more than host. Vernon Schryver, vjs@sgi.com
-----------[000162][next][prev][last][first]---------------------------------------------------- Date: 13 Oct 90 21:35:12 GMT From: swrinde!cs.utexas.edu!sun-barr!newstop!exodus!cs%Eng.Sun.COM@ucsd.edu (Carl Smith) To: tcp-ip@nic.ddn.mil Subject: Re: Connectathon??
> Does anybody know the word "Connectathon?" (may not be right spell) > > I heard it's the name of a kind of competition of TCP/IP implementations. > > If it was true, how can I get the information about the result of this > competition? Connectathon (TM) is the name of an event whose original purpose was to bring together NFS implementations and ensure that they interoperated. In later years, X Window System testing has also been added. I've been there as a vendor and as part of the group putting it on. It was never intended to be a competition. Nor is it intended to be a trade show (although there is a press event at its conclusion). It is purely an engineering event. Any NFS or X Window System implementation is eligible (and should make a concerted effort) to attend. An announcement is normally published in comp.protocols.nfs and comp.windows.x when the dates and location have been decided. Testing results are never published. Sun (the event's major sponsor) doesn't even allow access to the results by any of our employees who aren't directly involved in running the event. Carl
-----------[000163][next][prev][last][first]---------------------------------------------------- Date: 13 Oct 90 22:07:52 GMT From: mcsun!hp4nl!star.cs.vu.nl!rvdp@uunet.uu.net (=Ronald van der Pol) To: tcp-ip@nic.ddn.mil Subject: 3com ethernetcard + SCO TCP/IP
I have some problems with a 3COM 503 Ethernet card. It only seems to work with SCO UNIX 3.2.0 TCP/IP (Lachmann) when I use the default IRQ vector of 2. When I try to set the IRQ to 5 it doesn't work (e.g. when I install the Unix e3B driver). Should I use some additional (MS-DOS??) setup software? (there is no interrupt conflict!) -- Ronald van der Pol <rvdp@cs.vu.nl>
-----------[000164][next][prev][last][first]---------------------------------------------------- Date: 14 Oct 90 02:55:17 GMT From: sdd.hp.com!wuarchive!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucsd.edu (Henry Spencer) To: tcp-ip@nic.ddn.mil Subject: Re: Re: Ethernet Address Uniqueness...
In article <9010121633.AA00795@atlantic.nprdc.navy.mil> stanonik@nprdc.navy.mil writes: >The 10base5 NI cards in our AT&T 3b2's were all delivered with >the same ethernet address... AT&T has probably been bitten by a problem that has affected a number of established companies when they tried to build Ethernet gear: traditional production facilities have a very strong mindset towards building utterly identical boxes, and the only thing they are set up to do with PROMs is to duplicate them. If you simply hand them the new design and tell them to build it, the odds are very good that you will get identical Ethernet addresses, even if it says in the fine print that they should be different. And testing the new boards one at a time won't catch it! -- "...the i860 is a wonderful source | Henry Spencer at U of Toronto Zoology of thesis topics." --Preston Briggs | henry@zoo.toronto.edu utzoo!henry
-----------[000165][next][prev][last][first]---------------------------------------------------- Date: 14 Oct 90 03:34:53 GMT From: mintaka!spdcc!dyer@BLOOM-BEACON.MIT.EDU (Steve Dyer) To: tcp-ip@nic.ddn.mil Subject: Re: connect: Network is unreachable, (or) I want my FTP
In article <9010132308.AA16298@kiddo.merit.edu> hwb@MERIT.EDU (Hans-Werner Braun) writes:
>Given all your frequent interactions with the Merit/UMnet/NSFNET NOC with
>the hope for increased knowledge on your part about how things interact, I
>find it regrettable that you have to air your frustrations in public, in
>particular given the tone you used...You are otherwise wasting alot of time,
>effort and bandwidth.
Sitting here, it is not at all clear which was the more obnoxious message, nor
which the greater waste of bandwidth. I'd rather read a bit of enthusiastic
questioning given the spirit of this list than the same amount of pompous
bureaucratese offered in response.
--
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
-----------[000166][next][prev][last][first]---------------------------------------------------- Date: 14 Oct 90 23:11:39 GMT From: nelson@sun.soe.clarkson.edu (Russ Nelson) To: comp.protocols.nfs,sci.skeptic,comp.protocols.tcp-ip Subject: New product announcement: NFSper
FOR IMMEDIATE PUBLICATION OCT 14, 1990 ESP Software 11 Grant St. Potsdam, NY 13676 ESP Software would like to announce their newest product, NFSper. NFSper is a NFS server with an order of magnitude better performance than any existing NFS server. NFSper uses a proprietary technique to cache NFS requests on the client before they are transmitted to the server. Lab tests have shown that the NFS packet are available on the client an average of 100 microseconds before the client sends the request. Under test conditions, we have observed packets a full 250 uSec before the request transmission! NFSper avoids paradoxical effects by caching the packet rather than actually upcalling it. If the request packet falls on the floor, or the client fails to carry out its intent to send the request, then the client will never request the packet from the cache. Of course, in the case of high network loads or indecisive software, NFSper will rapidly fill your cache, removing any performance advantage. NFSper comes with programmers guidlines for stern, decisive coding. The sooner a decision is made to request a packet, the sooner NFSper can start sending the reply. We have found that most software makes this decision soon enough, but new software should of course take advantage of this new technology. We are currently working on TelePathWay, "All the Network without all the wiring." TelePathWay does away with the need to run coax or twisted pair. TelePathWay plugs into the AUI port found on most Ethernet equipment. You must supply your own telepath. Deliveries are expected by 4Q91. Direct all inquiries To: Russell N. Nelson, President ESP Software 11 Grant St. Potsdam, NY 13696 (315)265-5655 -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667 It's better to get mugged than to live a life of fear -- Freeman Dyson
-----------[000167][next][prev][last][first]---------------------------------------------------- From: ljm@mercury.twg.com To: tcp-ip@nic.ddn.mil Cc: Subject: Re: Can I use the Berkeley lp protocol for remote DOS prints from, COM1?
>I've got NCSA telnet configured and printing remotely off of a Sun, but >is there any commercial/pd program out there which lets me trap what goes >to com1/com2/prn from an application? (I've got an application which >can't print to a file). Any pointers would be greatly appreciated. Wollongong will provide LPR print redirector software in December, FTP Software should also be shipping something 'real soon now'. enjoy, leo j mclaughlin iii The Wollongong Group ljm@twg.com P.S. Please post any follow up comments which require a distribution list audience to pcip@udel.edu.
-----------[000168][next][prev][last][first]---------------------------------------------------- From: ljm@mercury.twg.com To: tcp-ip@nic.ddn.mil Cc: Subject: All nets broadcasts (was: SLIP, IP Routers and Named Pipes)
> >Am I correct in assuming that it is the 'non-passing' for certain >IP/UDP broadcast packets that prevents 'stock' named-pipes from >working across IP routers? > Yes. > >If that is the only reason, then could one expect named-pipes to work >across a router that could be configured to pass these broadcasts in a >controlled manner? (no loops and all that...) > The basic problem is that Lan Manager is trying to overcome its lack of a directory services with a mechanism, all-nets-broadcast, which just doesn't belong in an network with over a million users. If you really need to support LM's naming mechanisms, a more reasonable approach is to catch those broadcast NetBIOS name requests and translate them into DNS requests. enjoy, leo j mclaughlin iii ljm@twg.com P.S. Please pass any comments about the number of nodes/users to /dev/null or just read the archives of the last 'size of the Internet' debates.
-----------[000169][next][prev][last][first]---------------------------------------------------- Date: Mon, 15 Oct 90 09:17 EST From: Bob Stine <0004219666@mcimail.com> To: "SWEIGERT, DAVID" <dsweigert@paxrv-nes.navy.mil> Cc: tcp-ip <tcp-ip@nic.ddn.mil> Subject: RE: SNMP Agent by Proxy
I checked RFC 1147, and found that the CMU SNMP Distribution includes code for an SNMP agent for a Kenetics Fastpath2/3/4, the machine independent portions of which "run on CMU's IBM PC/AT based router." It would be better than starting from scratch... As given in RFC 1147, the CMU SNMP distribution is available via anonymous FTP from lancaster.andrew.cmu.edu (128.2.13.21), as files pub/cmu-snmp.9.tar, and pubkip-snmp.9.tar. You might look for a higher release number. I'm sure that the CMU SNMP has been updated more recently than has its catalog entry. - Bob Stine Applied Cybernetics, Inc.
-----------[000170][next][prev][last][first]---------------------------------------------------- Date: Mon, 15 Oct 90 11:23:32 PDT From: postel@venera.isi.edu To: apple.com!erekose@apple.com, tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols
Hi. "Reliable Datagram" is an oxymoron. --jon. From tcp-ip-RELAY@NIC.DDN.MIL Fri Oct 12 17:39:16 1990 Date: 12 Oct 90 10:12:49 GMT From: apple.com!erekose@apple.com (Erik Scheelke) Subject: Reliable Datagram Protocols Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anyone know of a reliable connectionless datagram protocol that runs on top of UDP? Is so, is there a library out there I can get? Thanks in advance, Erik Scheelke
-----------[000171][next][prev][last][first]---------------------------------------------------- Date: Mon, 15 Oct 90 09:27 EST From: Bob Stine <0004219666@mcimail.com> To: BIWINE <BIWINE%vassar.bitnet@pucc.princeton.edu> Cc: tcp-ip <tcp-ip@nic.ddn.mil> Subject: RE: Protocol analyzer
Bill, A quick scan of RFC 1147 did not turn up a product that would exactly satisfy your request. There is, however, a publically available package that monitors ethernet traffic and displays header fields. It's called "Netwatch". According to RFC 1147, Netwatch is available as a utility program in the pcip distribution from host husc6.harvard.edu, in directory pub/pcip. Its also available as a standalone package from windom.ucar.edu, in file pc/network/netwatch.arc. (A binary "dearc" program is also available from windom.ucar.edu.) Regards, Bob Stine Applied Cybernetics, Inc.
-----------[000172][next][prev][last][first]---------------------------------------------------- Date: Mon, 15 Oct 90 14:38:19 -0500 From: dab@berserkly.cray.com (David Borman) To: elroy.jpl.nasa.gov!aero!obrien@decwrl.dec.com, mcc@WLV.IMSD.CONTEL.COM, tcp-ip@nic.ddn.mil Subject: Re: Use of TCP/IP with satellite delays
> From tcp-ip-RELAY@NIC.DDN.MIL Thu Oct 11 01:16:19 1990 > Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL> > Date: Wed, 10 Oct 90 10:51:51 -0700 > From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) > Message-Id: <9010101751.AA08638@WLV.IMSD.CONTEL.COM> > To: elroy.jpl.nasa.gov!aero!obrien@decwrl.dec.com, tcp-ip@nic.ddn.mil > Subject: Re: Use of TCP/IP with satellite delays > > It works fine. TELNET on the other hand is something of a pain. I have > done a TELNET connection between Stuttgart-Vaihingen, FRG and Westlake Village > CA (LA area) with two satellite hops and a 9600 baud link between Westlake > and Marina Del Rey. Found you forget what you typed and can almost go out- > side for a smoke waiting for the echo. > > Merton But if you have Linemode Telnet, then the tty echo and line buffering happens locally, making a long-delay link like this very usable for interactive traffic, as long as you run line-oriented applications. If you run "vi" or some other screen oriented application that wants to do its own terminal echoing, you switch into remote echo and lose just like before... -David Borman, dab@cray.com
-----------[000173][next][prev][last][first]---------------------------------------------------- Date: Mon, 15 Oct 90 20:36:04 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) To: prism!ccastjr@gatech.edu, tcp-ip@nic.ddn.mil Subject: Re: The network
John: > Somewhere on campus here, we had a Post script formatted > map of the network (showing who is on .mil, and who is on .com > etc etc)...does anyone know where I can find this? Not particularly germane to your question, but this sounds like an interesting map. How is the "class" of the user related to the network to which it is connected? Upon which network would I find *.gov, *.mil, *.com, *.edu, *.de, *.au, *.nz, etc.? How was this determined? As a discrete example, on which network would you find "contel.com"? (A hint--name all network(s) to which contel.com is a member--*.gov, *.mil, *.com, etc. doesn't suggest anything accept the "class" of activity in which the organization is involved.) Merton
-----------[000174][next][prev][last][first]---------------------------------------------------- Date: 15 Oct 90 14:17:00 GMT From: 0004219666@MCIMAIL.COM (Bob Stine) To: comp.protocols.tcp-ip Subject: RE: SNMP Agent by Proxy
I checked RFC 1147, and found that the CMU SNMP Distribution includes code for an SNMP agent for a Kenetics Fastpath2/3/4, the machine independent portions of which "run on CMU's IBM PC/AT based router." It would be better than starting from scratch... As given in RFC 1147, the CMU SNMP distribution is available via anonymous FTP from lancaster.andrew.cmu.edu (128.2.13.21), as files pub/cmu-snmp.9.tar, and pubkip-snmp.9.tar. You might look for a higher release number. I'm sure that the CMU SNMP has been updated more recently than has its catalog entry. - Bob Stine Applied Cybernetics, Inc.
-----------[000175][next][prev][last][first]---------------------------------------------------- Date: 15 Oct 90 14:27:00 GMT From: 0004219666@MCIMAIL.COM (Bob Stine) To: comp.protocols.tcp-ip Subject: RE: Protocol analyzer
Bill, A quick scan of RFC 1147 did not turn up a product that would exactly satisfy your request. There is, however, a publically available package that monitors ethernet traffic and displays header fields. It's called "Netwatch". According to RFC 1147, Netwatch is available as a utility program in the pcip distribution from host husc6.harvard.edu, in directory pub/pcip. Its also available as a standalone package from windom.ucar.edu, in file pc/network/netwatch.arc. (A binary "dearc" program is also available from windom.ucar.edu.) Regards, Bob Stine Applied Cybernetics, Inc.
-----------[000176][next][prev][last][first]---------------------------------------------------- Date: 15 Oct 90 15:42:54 GMT From: sdd.hp.com!samsung!sol.ctr.columbia.edu!cica!greg@ucsd.edu (Gregory TRAVIS) To: tcp-ip@nic.ddn.mil Subject: Need Ethernet driver for CT Megaframe
Posting for a friend, reply to below address. Looking for Ethernet driver for a Convergent Technologies MegaFrame AKA S1280. Running CTIX version 5.1. Willing to pay, vendor won't sell it to us. No "get a new vendor" comments please. Thanks, Mike Mason, ph 202-382-1274 obpa1!mem.UUCP -- Gregory R. Travis Indiana University, Bloomington IN 47405 greg@cica.cica.indiana.edu Center for Innovative Computer Applications
-----------[000177][next][prev][last][first]---------------------------------------------------- Date: 15 Oct 90 17:42:46 GMT From: agate!bionet!uwm.edu!rpi!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!evax!utacfd!letni!mic!ernest!alan@ucbvax.Berkeley.EDU (Alan Edmonds) To: tcp-ip@nic.ddn.mil Subject: Re: Can I use the Berkeley lp protocol for remote DOS prints fromCOM1?
In article <ID3364.D901012.T084058.R17G@UNB.CA> R17G@UNB.CA (R17G000) writes: >> I've got NCSA telnet configured and printing remotely off of a Sun, but >> is there any commercial/pd program out there which lets me trap what goes >> to com1/com2/prn from an application? (I've got an application which >> can't print to a file). Any pointers would be greatly appreciated. >> >> - Avi > >Could you please post your findings to the list if applicable or forward >them to me at R17G@UNB.CA ? Me too. -- Alan Edmonds Texas Instruments, Inc. My opinions are only my own. M/S 8513 Work phone: (214)575-6427 6620 Chase Oaks Blvd. Email: alan@ernest.UUCP or alan@ernest.ti.com Plano, Texas 75023
-----------[000178][next][prev][last][first]---------------------------------------------------- Date: 15 Oct 90 18:54:09 GMT From: dino!sharkey!fmsrl7!teemc!fmeed1!wehr@uunet.uu.net (Bruce Wehr) To: tcp-ip@nic.ddn.mil Subject: Re: HP TCP/IP router/bridge?
In article <45306@apple.Apple.COM>, brooks@Apple.COM (Kevin Brooks) writes: > > Does anyone know of a bridge or router that will allow HP hosts running > TCP/IP which speak IEEE style packets (802.2 encapsulated) to > communicate with ethernet style IP implementations? Do most of the > router/bridge vendors support both IEEE and ethernet style IP packets? I don't have much experience here, but I'm installing a small ethernet network (about a dozen hosts) here at work - and I'm learning while doing. My design includes a bridge in each lab, primarily to aid in fault isolation. The bridge I've chosen is the Retix 2255. The manual says it will pass both style packets transparently, which (I think) answers your second question. It also states that the software on each respective host must deal with packet differences themselves, which (I think) answers your first question (that is, if I understand your first question correctly - you're looking for a bridge that will convert one style packet to another - right? This bridge explicitly *won't* [and I don't know of one that will]. But, it will pass both types, no problem). I hope this helps. -- Bruce Wehr (wehr%dptc.decnet@srlvx0.srl.ford.com) (...uunet!mailrus!sharkey!fmeed1!wehr) (wehr%fmeed1.uucp@mailgw.cc.umich.edu) Ford Motor Company - Electronics Division 17000 Rotunda Drive, ETC Room LN081, Dearborn, Michigan 48121 (313)845-3039
-----------[000179][next][prev][last][first]---------------------------------------------------- Date: 15 Oct 90 19:15:41 GMT From: bacchus.pa.dec.com!deccrl!shlump.nac.dec.com!tkou02.enet.dec.com!jituha!jitgmn.enet.dec.com!shimizu@decwrl.dec.com (Hidetoshi Shimizu) To: tcp-ip@nic.ddn.mil Subject: Re: 3com ethernetcard + SCO TCP/IP
In article <7947@star.cs.vu.nl> rvdp@cs.vu.nl (=Ronald van der Pol) writes:
> Xref: jituha comp.unix.sysv386:1390 comp.dcom.lans:12626 comp.protocols.tcp-ip:13626
> Path: jituha!tkou02.enet.dec.com!shlump.nac.dec.com!bacchus.pa.dec.com!decwrl!uunet!mcsun!hp4nl!star.cs.vu.nl!rvdp
> From: rvdp@cs.vu.nl (=Ronald van der Pol)
> Newsgroups: comp.unix.sysv386,comp.dcom.lans,comp.protocols.tcp-ip
> Date: 13 Oct 90 22:07:52 GMT
> Sender: news@cs.vu.nl
> Lines: 10
>
>
> I have some problems with a 3COM 503 Ethernet card. It only
> seems to work with SCO UNIX 3.2.0 TCP/IP (Lachmann) when I
> use the default IRQ vector of 2. When I try to set the IRQ
> to 5 it doesn't work (e.g. when I install the Unix e3B driver).
> Should I use some additional (MS-DOS??) setup software?
> (there is no interrupt conflict!)
>
> --
> Ronald van der Pol <rvdp@cs.vu.nl>
You should use a EtherLink-II Diagnostic Software under the MS-DOS and setup
Interrupt vector .
--
Hidetoshi Shimizu Digital Equipment Corporation Japan
Financial-2 EIC Urbannet Ikebukuro bldg 3-16-3 Higashi Ikebukuro
Toshima-ku Tokyo 170
-----------[000180][next][prev][last][first]---------------------------------------------------- Date: 15 Oct 90 20:26:00 GMT From: swrinde!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!mtecv2!vmtecmex.cem.itesm.mx!gcavazos@ucsd.edu (Gustavo Cavazos) To: tcp-ip@nic.ddn.mil Subject: What is SNMP
What is SNMP? Here we have a Fastpath IV, when I check the network, besides registering as a Gateway it registers itself as a SNMP. So what is SNMP? -Gus Cavazos -gcavazos at vmtecmex.bitnet -gcavazos at vmtecmex.cem.itesm.mx
-----------[000181][next][prev][last][first]---------------------------------------------------- Date: 15 Oct 90 20:33:48 GMT From: asylum!sharon@decwrl.dec.com (Sharon Fisher) To: tcp-ip@nic.ddn.mil Subject: Looking for SNMP network manager software for article
I'm doing a story on SNMP network manager software (as opposed to agent) for a story for Business Communication Review. If you produce or know of such software, available to users (i.e., not OEM-only), please let me know...or if there's some kind of global list, that'd be great. Thanks! The story will be an overview of the various packages available, with a chart comparing their features. -- "Drive carefully." "What is it with women and 'drive carefully'? 'No, I'm going to steer with my feet and read the comic paper.'"
-----------[000182][next][prev][last][first]---------------------------------------------------- Date: 15 Oct 90 20:39:20 GMT From: prism!ccastjr@gatech.edu (COOOooOoooooOOOOoOOoOOooKIE!!!!!) To: tcp-ip@nic.ddn.mil Subject: The network
I have some questions. This might be better suited to another
group (is there one dedicated to arpa/internet access besides
this one?), but here goes.
What is the cost of having access to the net (via your
own machine)?
Somewhere on campus here, we had a Post script formatted
map of the network (showing who is on .mil, and who is on .com
etc etc)...does anyone know where I can find this?
thanks
John
--
Emporers Thought for the Day: | John E. Rudd jr.
Only the insane have the strength to prosper; | ccastjr@prism.gatech.edu
Only those who prosper judge what is sane. | (ex- kzin@ucscb.ucsc.edu)
#include<std.disclaim> Send all comments, flames, and complaints to /dev/null.
-----------[000183][next][prev][last][first]---------------------------------------------------- Date: Tue, 16 Oct 1990 05:20:06 PDT From: Elayne_McFaul.Wbst128@xerox.com To: TCP-IP-Internet-NS.all_areas@Xerox.com, TCP-IP-NS.all_areas@Xerox.com, tcp-ip@nic.ddn.MIL Cc: McFaul.WBST128@Xerox.com Subject: Protocol specification for Unix rcp
Where can I find a protocol specification for rcp, the 4.3BSD remote copy utility? Elayne McFaul Xerox Corporation mcfaul.wbst128@xerox.com
-----------[000184][next][prev][last][first]---------------------------------------------------- Date: 16 Oct 90 00:49:07 GMT From: netcom!jbreeden@apple.com (John Breeden) To: tcp-ip@nic.ddn.mil Subject: Re: What is SNMP
In article <2396@mtecv2.mty.itesm.mx> gcavazos@vmtecmex.cem.itesm.mx (Gustavo Cavazos) writes: >What is SNMP? >Here we have a Fastpath IV, when I check the network, besides registering >as a Gateway it >registers itself as a SNMP. >So what is SNMP? Simple Network Management Protocol - for more info, get Marshall Rose's book, "The Simple Book", Prentice Hall. ISBN # 0138126119. -- John Robert Breeden, netcom!jbreeden@apple.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden ------------------------------------------------------------------- "The nice thing about standards is that you have so many to choose from. If you don't like any of them, you just wait for next year's model."
-----------[000185][next][prev][last][first]---------------------------------------------------- Date: Tue, 16 Oct 90 12:44:24 -0700 From: bbrooks@salt.acc.com (Bill Brooks) To: tcp-ip@nic.ddn.mil
snmp@psi.com
-----------[000186][next][prev][last][first]---------------------------------------------------- Date: Tue, 16 Oct 90 12:46:49 -0700 From: bbrooks@salt.acc.com (Bill Brooks) To: tcp-ip@nic.ddn.mil
plase add me to the mail list at bbrooks@salt.acc.com
-----------[000187][next][prev][last][first]---------------------------------------------------- Date: Tue, 16 Oct 90 09:04:13 -0400 From: jcurran@SH.CS.NET To: Sharon Fisher <asylum!sharon@decwrl.dec.com> Cc: tcp-ip@nic.ddn.mil Subject: Re: Looking for SNMP network manager software for article
Refer to RFC 1147 (Network Management Tool Catalog) as it lists several SNMP network management tools. It's not necessarily complete, but it's a good start.. /John
-----------[000188][next][prev][last][first]---------------------------------------------------- Date: Tue, 16 Oct 90 07:53 EST From: Bob Stine <0004219666@mcimail.com> To: Sharon Fisher <asylum!sharon@decwrl.dec.com> Cc: tcp ip <tcp-ip@nic.ddn.mil> Subject: Re: Looking for SNMP network manager software for article
Datapro has compiled a list of SNMP management systems. For information on getting their list, dial 1-800-DATAPRO, and ask to speak with Jill Huntington-Lee. Also, RFC 1147, available via anonymous FTP or email from nic.ddn.mil, lists several SNMP packages. - Bob Stine Applied Cybernetics, Inc.
-----------[000189][next][prev][last][first]---------------------------------------------------- Date: 16 Oct 90 03:15:18 GMT From: faatcrl!warb@rutgers.edu (Dan Warburton) To: tcp-ip@nic.ddn.mil Subject: Re: The network
ccastjr@prism.gatech.EDU (COOOooOoooooOOOOoOOoOOooKIE!!!!!) writes:
> What is the cost of having access to the net (via your
>own machine)?
The Answer is: ........... it Depends!!!
It depends mostly on how close the nearest access point is to your computer
and what kind of computer you have and what you purpose for connection is and
and how much bandwitdh to the net you would like. Maybe a couple of examples
might clarify.
Ex. 1 Your network connection is a local machine across the room. Just
string some ethernet cable across the room. Get the SysAdm to
assign you a spare internet number and zoom! You are on the net.
Ex. 2 You don't have a campus connection and want a 56k baud connection.
Start with about 25k in equipment costs, add line connect charges,
annual rental of line (say 40 miles), add private network gateway cost
you should end up with 30k startup plus 20k recurring. This IS just
an example, your milage my vary.
-----------[000190][next][prev][last][first]---------------------------------------------------- Date: Tue, 16 Oct 90 11:20:14 -0400 From: Craig Partridge <craig@NNSC.NSF.NET> To: tcp-ip@nic.ddn.mil Subject: SIGCOMM '91 Call for Papers
Call For Papers ACM SIGCOMM '91 CONFERENCE Communications Applications, Architectures and Protocols ETH Zurich, Zurich, Switzerland September 4-6, 1991 (Tutorials September 3, 1991) The conference provides an international forum for the presentation and discussion of communication network applications and technologies, as well as recent advances and proposals on communication architectures, protocols, algorithms, and performance models. It is the first time that SIGCOMM will hold its conference outside of the United States. Authors are invited to submit full papers concerned with both theory and practice. The areas of interest for the conference include, but are not limited to the following: Analysis and design of computer network architectures and algorithms, innovative results in local area networks, computer-supported cooperative work, network interconnection and mixed-media networks, high-speed networks, resource sharing in distributed systems, network management, distributed operating systems and databases, protocol specification, verification, and analysis. Papers should be about 20 double-spaced pages long and should have an abstract of 100-150 words. All submitted papers will be reviewed and will be judged with respect to their quality and relevance. Authors of accepted papers will be expected to sign an ACM copyright release form. The Proceedings will be distributed at the conference and published as a special issue of ACM SIGCOMM Computer Communication Review. Notable papers will be considered for publication in ACM Transactions on Computer Systems. Submit 5 copies of each paper to the program chairman (or in the US, the US program committee contact): Prof. Bernhard Plattner Technische Informatik und Kommunikationsnetze Telephone: +41 1 254 7000 ETH-Zentrum (IFW) Fax: +41 1 262 3973 8092 Zurich, Switzerland EMAIL: <plattner@komsys.tik.ethz.ch> or <C=ch; ADMD=arcom; PRMD=switch; O=ethz; ou1=tik; ou2=komsys; s=plattner> The US program committee contact is: Greg Wetzel AT&T Bell Laboratories Telephone: +1 (708) 979-4782 M/S IH 1B-213 Fax: +1 (708) 979-2350 2000 N. Naperville Road E-Mail: g_f_wetzel@att.com Naperville, IL 60566 For more information about the conference, e-mail to sicomm91@nri.reston.va.us Special session: Applications of High Speed Networks One or more sessions of the conference will be devoted to the subject of applications of high speed networks. Papers in these sessions will focus on concepts, implementation and experience of applications that need the performance that future high speed networks will offer. Topics include, but are not limited to new approaches to computer-supported cooperative work, graphic visualization, and access to supercomputers. Papers submitted for these topics should address applications and their communications requirements. Student Paper Award Papers submitted by students will enter a student-paper award contest. Among the accepted papers, a maximum of four outstanding papers will be awarded (1) full conference registration and (2) a travel grant of $500 US dollars. To be eligible the student must be the sole author or a primary contributor to the paper. IMPORTANT DATES Deadline for paper submission: March 2, 1991. Notification of acceptance: April 30, 1991. Camera ready papers due: May 31, 1991.
-----------[000191][next][prev][last][first]---------------------------------------------------- Date: 16 Oct 90 05:49:02 GMT From: encore!zelig!jdarcy@husc6.harvard.edu (Floating Exception) To: tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols
apple.com!erekose@apple.com (Erik Scheelke):
> Does anyone know of a reliable connectionless datagram protocol that
> runs on top of UDP? Is so, is there a library out there I can get?
postel@VENERA.ISI.EDU writes:
>Hi.
>
>"Reliable Datagram" is an oxymoron.
Very funny. Really. I would guess, however, that Erik is referring to a
connectionless protocol that preserves message boundaries and guarantees
delivery but not necessarily sequencing or non-duplication. I'm sure such
beasts exist somewhere.
--
Jeff d'Arcy, Generic Software Engineer - jdarcy@encore.com
Nothing was ever achieved by accepting reality
-----------[000192][next][prev][last][first]---------------------------------------------------- Date: Tue, 16 Oct 90 12:45:14 -0400 From: ccastjr@prism.gatech.edu (COOOooOoooooOOOOoOOoOOooKIE!!!!!) To: WLV.IMSD.CONTEL.COM!mcc@gatech.gatech.edu, tcp-ip@nic.ddn.mil Subject: Re: The network
well, there was a horizontal line and off from that broke the basic networks (.com .mil .gov etc) in vertical directions (some up, some down). Each "T" in the network was a further sub net (so, when the .edu broke off the base line, there were further breakoffs to .gatech and .mit and .berkeley etc) I think they put commercial orgs on .com even if they had an additional .mil address.. it wasn't meant to be a geographic map (from what I saw) but a network topology map. hope that explains it..if I find a copy, I'll send it to you. John
-----------[000193][next][prev][last][first]---------------------------------------------------- Date: Tue, 16 Oct 90 11:35:26 EDT From: kate@tecnet1.jcte.jcs.mil To: tcp-ip@nic.ddn.mil Subject: route needed
I am trying to send a message to the UK. The address is: user@company.co.uk I know it is a valid address over there but my DOD machine doesn't know how to get it there. I was wondering if there is a static route I could type that will get it over there? Thanks
-----------[000194][next][prev][last][first]---------------------------------------------------- Date: Tue, 16 Oct 90 20:46:14 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) To: dab@berserkly.cray.com, elroy.jpl.nasa.gov!aero!obrien@decwrl.dec.com, mcc@WLV.IMSD.CONTEL.COM, tcp-ip@nic.ddn.mil Subject: Re: Use of TCP/IP with satellite delays
David: As the author you well know that a valid TELNET line mode didn't exist until you did the necessary work. 4.3 BSD always devolves to an equivalent of an rlogin connection with single character frames. There are toooo many products for other platforms that don't really support all TELNET options and in fact don't work when faced with a system that doesn't devolve to the 4.3 BSD default. Now that you've completed a legitimate line mode are you going to implement a valid NVDET option? Merton
-----------[000195][next][prev][last][first]---------------------------------------------------- Date: Tue, 16 Oct 90 21:19:08 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) To: WLV.IMSD.CONTEL.COM!mcc@gatech.edu, ccastjr@prism.gatech.edu, tcp-ip@nic.ddn.mil Subject: Re: The network
John: I like your statements--they follow the party line. Let me insert a little reality before you send any maps--actually send the maps, I would like to take a look at this make believe world. The point of my interest was that the networks never devolved in the conceptual outlines that were anticipated years earlier. There is no *.org, *.gov, *.edu, or *.com networks. There is an *.mil network but it incorporates all of the preceding "classes" of users. There are regional networks that incorporate these "classes" of users. There are no networks, to my knowledge, that are composed of a single "class" of user. For example, *.contel.com is a member of several networks. The membership is partly historical, it is partly a matter of emphasis, and it is partly a matter of entry and sponsorship in the ARPA and MILNET domains. Actually, one might want to consider the role of acquisition in network membership. The domain *.imsd.contel.com is a MILNET member, all other *.contel.com domains are members of SURAnet. Another example is the *.radc.af.mil domain. The tops20.radc.af.mil system is part of NYSERnet. The lonex.radc.af.mil and subsidiary systems are strictly a part of MILNET. One can access the *.radc.af.mil domain either through NYSERnet or MILNET. Merton
-----------[000196][next][prev][last][first]---------------------------------------------------- Date: 16 Oct 90 12:20:06 GMT From: Elayne_McFaul.Wbst128@xerox.com To: comp.protocols.tcp-ip Subject: Protocol specification for Unix rcp
Where can I find a protocol specification for rcp, the 4.3BSD remote copy utility? Elayne McFaul Xerox Corporation mcfaul.wbst128@xerox.com
-----------[000197][next][prev][last][first]---------------------------------------------------- Date: 16 Oct 90 12:53:00 GMT From: 0004219666@mcimail.com (Bob Stine) To: comp.protocols.tcp-ip Subject: Re: Looking for SNMP network manager software for article
Datapro has compiled a list of SNMP management systems. For information on getting their list, dial 1-800-DATAPRO, and ask to speak with Jill Huntington-Lee. Also, RFC 1147, available via anonymous FTP or email from nic.ddn.mil, lists several SNMP packages. - Bob Stine Applied Cybernetics, Inc.
-----------[000198][next][prev][last][first]---------------------------------------------------- Date: 16 Oct 90 13:04:13 GMT From: jcurran@SH.CS.NET To: comp.protocols.tcp-ip Subject: Re: Looking for SNMP network manager software for article
Refer to RFC 1147 (Network Management Tool Catalog) as it lists several SNMP network management tools. It's not necessarily complete, but it's a good start.. /John
-----------[000199][next][prev][last][first]---------------------------------------------------- Date: 16 Oct 90 15:20:14 GMT From: craig@NNSC.NSF.NET (Craig Partridge) To: comp.protocols.tcp-ip Subject: SIGCOMM '91 Call for Papers
Call For Papers ACM SIGCOMM '91 CONFERENCE Communications Applications, Architectures and Protocols ETH Zurich, Zurich, Switzerland September 4-6, 1991 (Tutorials September 3, 1991) The conference provides an international forum for the presentation and discussion of communication network applications and technologies, as well as recent advances and proposals on communication architectures, protocols, algorithms, and performance models. It is the first time that SIGCOMM will hold its conference outside of the United States. Authors are invited to submit full papers concerned with both theory and practice. The areas of interest for the conference include, but are not limited to the following: Analysis and design of computer network architectures and algorithms, innovative results in local area networks, computer-supported cooperative work, network interconnection and mixed-media networks, high-speed networks, resource sharing in distributed systems, network management, distributed operating systems and databases, protocol specification, verification, and analysis. Papers should be about 20 double-spaced pages long and should have an abstract of 100-150 words. All submitted papers will be reviewed and will be judged with respect to their quality and relevance. Authors of accepted papers will be expected to sign an ACM copyright release form. The Proceedings will be distributed at the conference and published as a special issue of ACM SIGCOMM Computer Communication Review. Notable papers will be considered for publication in ACM Transactions on Computer Systems. Submit 5 copies of each paper to the program chairman (or in the US, the US program committee contact): Prof. Bernhard Plattner Technische Informatik und Kommunikationsnetze Telephone: +41 1 254 7000 ETH-Zentrum (IFW) Fax: +41 1 262 3973 8092 Zurich, Switzerland EMAIL: <plattner@komsys.tik.ethz.ch> or <C=ch; ADMD=arcom; PRMD=switch; O=ethz; ou1=tik; ou2=komsys; s=plattner> The US program committee contact is: Greg Wetzel AT&T Bell Laboratories Telephone: +1 (708) 979-4782 M/S IH 1B-213 Fax: +1 (708) 979-2350 2000 N. Naperville Road E-Mail: g_f_wetzel@att.com Naperville, IL 60566 For more information about the conference, e-mail to sicomm91@nri.reston.va.us Special session: Applications of High Speed Networks One or more sessions of the conference will be devoted to the subject of applications of high speed networks. Papers in these sessions will focus on concepts, implementation and experience of applications that need the performance that future high speed networks will offer. Topics include, but are not limited to new approaches to computer-supported cooperative work, graphic visualization, and access to supercomputers. Papers submitted for these topics should address applications and their communications requirements. Student Paper Award Papers submitted by students will enter a student-paper award contest. Among the accepted papers, a maximum of four outstanding papers will be awarded (1) full conference registration and (2) a travel grant of $500 US dollars. To be eligible the student must be the sole author or a primary contributor to the paper. IMPORTANT DATES Deadline for paper submission: March 2, 1991. Notification of acceptance: April 30, 1991. Camera ready papers due: May 31, 1991.
-----------[000200][next][prev][last][first]---------------------------------------------------- Date: 16 Oct 90 15:45:25 GMT From: asylum!sharon@decwrl.dec.com (Sharon Fisher) To: tcp-ip@nic.ddn.mil Subject: Looking for users who run SNMP in their bridges & routers
I've also gotten an assignment from Datamation to write about the use of SNMP in bridges and routers. I am looking for users in this area. If you're a user, or if you're a vendor who can provide users I can talk to, please let me know. Thanks!
-----------[000201][next][prev][last][first]---------------------------------------------------- Date: 16 Oct 90 16:31:37 GMT From: rogue.llnl.gov!oberman@lll-winken.llnl.gov To: tcp-ip@nic.ddn.mil Subject: Re: Reply to Re: Ethernet Address Uniqueness...
In article <9010092346.AA29384@ftp.com>, jbvb@FTP.COM (James B. Van Bokkelen) writes: > This is a standard gotcha of using protocols that change the address. > There is no solution other than to make sure that DECNet is always > started before anything else that cares about the Ethernet address. This is getting a bit far afield from tcp-ip, but the above is not quite true. By setting the SYSGEN value for SCSSYSTEMID to the value ((DECnet area*1024) + node), the order in which products are started in no longer significant as the MAC address of the Ethernet cards is rewritten before any layered software is run. 48.168 would yield an SCSSYSTEMID of 49320, (48*1024)+168. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.
-----------[000202][next][prev][last][first]---------------------------------------------------- Date: 16 Oct 90 16:34:28 GMT From: mcsun!i2unix!alessia!athena@uunet.uu.net (Matteo Frigo) To: tcp-ip@nic.ddn.mil Subject: Re: Strange bahaviour of an LSX3020 with tcp protocol
[ I reply to myself :-) ] I have been able to solve the problem, and as it is a bug of of X/OS 2.2 I post the solution . The problem was in the incorrect TTL (time to live of tcp packets) which was set to 15, while the sun had 30. The constant TCP_TTL is defined in netinet/tcp_timer.h. My kernel was compiled with this low value, which inhibits tcp connections which far hosts. As I have not access to Olivetti kernel's sources, I made a patch directly on /usr/mixos/kernel/tcpip/libtcp_ip.a, using as guide the tcp sources from BSD4.3 . The constant is used in two object modules. I believe this is a problem of all LSX machines with X/OS 2.2 and I can give details on patching the kernel to anyone who is interested in. I would also thank all the people who gave me suggestions after my news. Matteo Frigo athena@alessia.dei.unipd.it (it works now !)
-----------[000203][next][prev][last][first]---------------------------------------------------- Date: 16 Oct 90 20:54:54 GMT From: wuarchive!emory!hubcap!mmccann@eddie.mit.edu (Mike McCann) To: tcp-ip@nic.ddn.mil Subject: Need phone numbers...
I am interested in subnetting several building off our Ethernet backbone (passing TCP-IP, DECnet and AppleTalk packets) to cut down on the amount of backbone traffic and inefficient IP number usage. Anyone have phone numbers for networking companies (such as Proteon or Sysco)? I also want these routers to be managed by SNMP. Any suggestions? Thanks in advance for your help, -- Mike McCann (803) 656-2721 Internet = mmccann@hubcap.clemson.edu Engineering Computer Operations Bitnet = mmccann@clemson.bitnet Clemson University Clemson, S.C. 29634-2803 DISCLAIMER = I speak only for myself.
-----------[000204][next][prev][last][first]---------------------------------------------------- Date: 16 Oct 90 21:30:00 GMT From: snorkelwacker!mintaka!spdcc!ima!mirror!frog!tdh@apple.com (T. Dave Hudson) To: tcp-ip@nic.ddn.mil Subject: single tcpcb loopback bug
This seems to be a previously unpublished bug.
(Do 4.3BSD TCP/IP bugs belong in comp.bugs.4bsd.ucb-fixes instead?)
We are using the following base revisions of 4.3BSD TCP/IP source
modules:
@(#)tcp_input.c 7.15.1.3 (Berkeley) 2/15/89
@(#)tcp_output.c 7.13.1.4 (Berkeley) 2/15/89
When a user program (which I did not write) does
1) socket(PF_INET, SOCK_STREAM, 0)
2) bind() {PF_INET, port=3000, INADDR_ANY}
3) connect() {PF_INET, port=3000, local host's IP address}
the kernel goes into an infinite "loop" (dump indicates many ACKs but
little data in tcpstats) presumably scheduling SYN/ACK (and possibly
something else; dump only showed last message) messages to and from
presumably the same tcpcb. The tcpcb is in SYN SENT state, with
tcp_output() called from the dropafterack section of tcp_input(), and
with tcp_output() having successfully sent a message, contents unknown
except that the last freed mbuf, appropriately, is SYN/ACK with both
ports equal to 3000 and using the local node's Ethernet interface's IP
address. The SYN/ACK message contains an ISN that disagrees (having
been incremented) with the tcpcb's idea of it, but an acknowledgement
number that (matching the SYN/ACK's ISN, properly incremented from
the tcpcb's ISN) is OK.
I suspect that a workable fix is to use the tcpcb's ISN when sending
any SYN, although I haven't tried this yet. However, the failure to
do this ought to have generated a RST, IMHO, so I guess there are
actually two bugs here.
Has anyone already worked out a fix for this? (I will summarize
responses received by email. My guess is that it will be another
month or two before I can spend time working out a fix myself.)
David Hudson
-----------[000205][next][prev][last][first]---------------------------------------------------- Date: 16 Oct 90 21:39:43 GMT From: sgi!cjohnson%somni.wpd.sgi.com@ucbvax.Berkeley.EDU (Chris Johnson) To: tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols
> postel@VENERA.ISI.EDU sez: > > "Reliable Datagram" is an oxymoron. > > --jon. Perhaps reliable datagram using UDP is an oxymoron, depending on the transport layer. However XTP datagrams *are* reliable. Mail to xtp-request@pei.com for information or a XTP spec. Chris Johnson cjohnson@pei.com
-----------[000206][next][prev][last][first]---------------------------------------------------- Date: 17 Oct 90 01:41:59 GMT From: sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU (Rob Warnock) To: tcp-ip@nic.ddn.mil Subject: Re: File Broadcast
In article <45509@apple.Apple.COM> erekose@apple.com (Erik Scheelke) writes:
+---------------
| We have a local area network of UNIX based PCs running TCP-IP, and I
| was asked if there was any software that will broadcast a file to all
| machines on the network. I didn't know of any and was wondering if
| anyone out there in netland knew of any. If not, I guess I will have
| to write something myself. I would appreciate any infomation about
| programs or algorithms that do file broadcasting. It must use a broadcast,
| not a copy to one machine then copy to another method (i.e. UDP), and
| if a machine is up it must reliably send the file.
+---------------
Using the multicast features of the XTP protocol, you could do what you
want with something like the following:
for i in $MACHINELIST
do
# start each receiver listening
rsh $i 'txtp -r -s -M | tar xf - &'
done
# now multicast the file
txtp -t -s -M <src_file
"Txtp" is an XTP-ized version of "ttcp", the common TCP test program.
Of course, you need XTP support on each machine... ;-}
-Rob
-----
Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com
Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA 94039-7311
-----------[000207][next][prev][last][first]---------------------------------------------------- Date: Wed, 17 Oct 90 10:33:48 -0500 From: jbvb@ftp.com (James B. Van Bokkelen) To: news!german@iuvax.cs.indiana.edu (Chad W. German) Cc: tcp-ip@nic.ddn.mil Subject: Re: NCSA TELNET / BANYAN
VINES doesn't use packet drivers. Instead, they have a hardware device sharing interface built into VINES. We offer a version of PC/TCP which talks to it, and gives the functionality you want. I don't know if any of the freeware developers have ever considered doing drivers for this. I have heard rumors of VINES which can use NDIS, and if you could get it, this could be combined with the NDIS-Packet Driver adapter to use freeware. If this is in fact a feature of their 4.0 release, I have been told it will be available sometime this winter. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000208][next][prev][last][first]---------------------------------------------------- Date: Wed, 17 Oct 90 08:23 EST From: Bob Stine <0004219666@mcimail.com> To: Merton Campbell Crockett <mcc@wlv.imsd.contel.com> Cc: tcp ip <tcp-ip@nic.ddn.mil> Subject: Re: The network
>The point of my interest was that the networks never devolved in the conceptual >outlines that were anticipated years earlier. There is no *.org, *.gov, *.edu, >or *.com networks... There is an *.mil network but it incorporates all of the >preceding "classes" of users. There are regional networks that incorporate >these "classes" of users. There are no networks, to my knowledge, that are >composed of a single "class" of user. My understanding on this issue (such as it is :-) ) is that the name space is independent from the actual network topology. E.g., having an "edu" domain does _NOT_ mean that one should expect to find an education net. If this thread goes much further, it would probably be more appropriate for name-droppers. Bob Stine Applied Cybernetics, Inc.
-----------[000209][next][prev][last][first]---------------------------------------------------- Date: Wed 17 Oct 90 13:24:19-PDT From: VANCE@TGV.COM (Icarus) To: marge%masbull.my.bull.fr@TGV.COM Cc: tcp-ip@nic.ddn.mil
>Does anyone know of a product that supports DOS diskless station on >TCP/IP with UNIX server using TFTP and BOOTP. I know of two. Try: Beame & Whiteside (416) 648-6556 FTP Software (617) 246-0900 Regards, -----Stuart -------
-----------[000210][next][prev][last][first]---------------------------------------------------- Date: Wed, 17 Oct 90 12:14:58 CDT From: mailing list <tcpip@server.af.mil> To: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) Cc: tcp-ip@nic.ddn.mil Subject: Re: The network
> The point of my interest was that the networks never devolved in the conceptual > outlines that were anticipated years earlier. There is no *.org, *.gov, *.edu, > or *.com networks. There is an *.mil network but it incorporates all of the > preceding "classes" of users. There are regional networks that incorporate > these "classes" of users. There are no networks, to my knowledge, that are > composed of a single "class" of user. > Yes, even the milnet has its non-military users. I guess what I wanted to say, is that the map that John is referring to is a map of the Domains of the internet. I remember seeing it once, and it is strictly a break-out of all the domains registered with the SRI-NIC... I don't know that that means you can get it from the NIC, however. I am sure that I did not get it from the NIC myself. I also remember that I got this "map" early this year, and it hadn't been revised since 88. If anyone does run across a really current one, I'd be interested in seeing how well it reflects our af.mil reality (:-> /matt jonson@server.af.mil I speak not for my organization.
-----------[000211][next][prev][last][first]---------------------------------------------------- Date: 17 Oct 90 09:17:23 GMT From: mcsun!hp4nl!dnlunx!dnlts!icp@uunet.uu.net (R. Sonneveld, ICP, NAD, ICP@HLSDNL5.BITnet, +31 70 435362) To: tcp-ip@nic.ddn.mil Subject: Re: ISO Country codes
In article <9010121643.AA28145@ucbvax.Berkeley.EDU>, Z00EJR01%AWIUNI11@PUCC.PRINCETON.EDU (Ewald Jenisch) writes: > Does anybody out there in the netland know where I can find a listing > of all ISO Country Codes. As far as I remember there was such a list > hanging around for anonymous FTP but I don't remember which server. Try your nearest NETSERV, for the file: COUNTRY ISOCODES. Rolf Sonneveld PTT Research The Netherlands
-----------[000212][next][prev][last][first]---------------------------------------------------- Date: Wed, 17 Oct 90 09:23:07 +0100 From: Denis.Russell@newcastle.ac.uk To: kate@tecnet1.jcte.jcs.mil Cc: tcp-ip@nic.ddn.mil Subject: Re: route needed
Re:
> I am trying to send a message to the UK. The address is:
> user@company.co.uk
> I know it is a valid address over there but my DOD machine doesn't know how
> to get it there. I was wondering if there is a static route I could type
> that will get it over there?
> Thanks
Try routing it via nsfnet-relay.ac.uk, i.e. try either
user%company.co.uk@nsfnet-relay.ac.uk
or
user%uk.co.company@nsfnet-relay.ac.uk
(The second form might just be required because our mail
addresses are the other way round).
If you look at the trace of this message to you, you should be
able to see this gateway in the route.
Denis
Denis Russell JANET: Denis.Russell@uk.ac.newcastle
Computing Laboratory Internet: Denis.Russell@newcastle.ac.uk
The University
Claremont Road Tel: (+44) 91 222 8243
Newcastle upon Tyne Fax: (+44) 91 222 8232
NE1 7RU Telex: 53 65 4 UNINEW G
ENGLAND
-----------[000213][next][prev][last][first]---------------------------------------------------- Date: Wed, 17 Oct 90 16:06:00 EDT From: CHRISTOPHER TANNER <TANNERC@CRL.AECL.CA> To: tcp-ip@NIC.DDN.MIL Subject: WIN$LPD on VMS
Greetings Using Wollongong's version of LPD on VMS, is it possible to specify parameters for the VMS PRINT commands such as /FLAG and /FORM=xxx? I would like an lpr -Pxx (on UNIX) to become PRINT /Q=xx/FLAG/FORM=yy on the VMS system. Thanks for your help Chris Tanner AECL Research
-----------[000214][next][prev][last][first]---------------------------------------------------- Date: 17 Oct 90 13:23:00 GMT From: 0004219666@mcimail.com (Bob Stine) To: comp.protocols.tcp-ip Subject: Re: The network
>The point of my interest was that the networks never devolved in the conceptual >outlines that were anticipated years earlier. There is no *.org, *.gov, *.edu, >or *.com networks... There is an *.mil network but it incorporates all of the >preceding "classes" of users. There are regional networks that incorporate >these "classes" of users. There are no networks, to my knowledge, that are >composed of a single "class" of user. My understanding on this issue (such as it is :-) ) is that the name space is independent from the actual network topology. E.g., having an "edu" domain does _NOT_ mean that one should expect to find an education net. If this thread goes much further, it would probably be more appropriate for name-droppers. Bob Stine Applied Cybernetics, Inc.
-----------[000215][next][prev][last][first]---------------------------------------------------- Date: Wed, 17 Oct 90 23:46:45 -0400 From: cfm@sparta.com (Carl Muckenhirn) To: ccastjr@prism.gatech.edu (COOOooOoooooOOOOoOOoOOooKIE!!!!!) Cc: WLV.IMSD.CONTEL.COM!mcc@gatech.gatech.edu, tcp-ip@nic.ddn.mil Subject: Network Maps (was: The network)
the map you are refering to used to be available from the DDN NIC (NIC.DDN.MIL). It has nothing to do with network geography or topology, but is a listing of the domains that are registered with the NIC. It was (is, it is probably still out there somewhere) basically a tree with the "INTERNET" as the root node, .com, .mil, .gov, .org, .us, .uk, ... as the first level descendents, .af.mil, .sparta.com, .mitre.org, ... etc. For the most part the tree is very shallow, but some branches are fairly deep (mit.edu comes to mind). This whole map is just a layout of administrative domains. There are a number (most?) of domains that consist of several "networks" (a group of computers organized under a single network number). There is no reason that a domain (sparta.com for example) cannot be geographically diverse (for example with a "network" in Washington, D.C. and another in Baltimore, MD) but sharing the administrative and naming structure provided by the DNS (all hosts on these networks have hostnames of the form <something>.sparta.com (<something> maybe <foo> or <foo>.<bar> or <foo>.<bar>.<foobar>..... [you get the picture]). If you want a picture of the "network topology" you need to start looking at the network addresses, find the gateways on those networks, hook the gateway's different network addresses together, then go to the next layer of networks and so on. This should be doable (I've been working on related pieces of this problem for the last 2 years on and off) with the information in the NIC (and NSFNET NISC). The hard part comes when you try to display it, what is the point of reference (if I start at the nsfnet the picture is much different than if I start at a stub network), what symbology is appropriate (are the connected networks lines, clouds, layers of an onion) and so on. And once you've figured that out, someone will say, "But WHERE are these things?" and you now have to get all the addresses for the gateways, and now the pretty layered picture is a bowl of spaghetti. (Are there any idle topologists out there?) All this is to say, I doubt that there are any "network maps" out there that show the entire internet. There are some very good geographic maps of some of the regional and educational nets (THENet sticks in my mind) out there, but I think that all were manually done (a Mac, some clip-art, a lot of time). I can't remember right off where they can be found, if anyone is interested drop me a line and I'll see if I can dig it out. A few people here at Sparta have done a lot of thinking about how to do automated generation of topographic and geographic network maps, and we have some of the basics down but we are between contracts and don't know if this work will continue (being a defense contractor is the pits sometimes). If anyone has any other insights on this topic I'd be happy to hear from you. carl.
-----------[000216][next][prev][last][first]---------------------------------------------------- Date: 17 Oct 90 17:06:48 GMT From: VAX1.CC.UAKRON.EDU!mcs.kent.edu!usenet.ins.cwru.edu!cwns1!chet@tut.cis.ohio-state.edu (Chet Ramey) To: tcp-ip@nic.ddn.mil Subject: Re: Protocol specification for Unix rcp
>Where can I find a protocol specification for rcp, the 4.3BSD remote copy utility? /usr/src/bin/rcp.c :-) Chet -- Chet Ramey ``As I recall, Doug was keen on boxing. But Network Services Group when he learned to walk, he took up puttin' Case Western Reserve University the boot in the groin.'' chet@ins.CWRU.Edu
-----------[000217][next][prev][last][first]---------------------------------------------------- Date: 17 Oct 90 17:16:10 GMT From: prism!ccastjr@gatech.edu (COOOooOoooooOOOOoOOoOOooKIE!!!!!) To: tcp-ip@nic.ddn.mil Subject: Re: The network
Sorry if my statements were misleading. I know that the *.mil and *.edu\ don't denote a PHYSICAL network.. but a "logical" network.. The map is drawn along this "logical" network. I understood this, but I guess that didn't come across.. sorry. John -- Emporers Thought for the Day: | John E. Rudd jr. Only the insane have the strength to prosper; | ccastjr@prism.gatech.edu Only those who prosper judge what is sane. | (ex- kzin@ucscb.ucsc.edu) #include<std.disclaim> Send all comments, flames, and complaints to /dev/null.
-----------[000218][next][prev][last][first]---------------------------------------------------- Date: Thu, 18 Oct 1990 0:48:32 PDT From: SRI Network Information Systems Center <nisc@nisc.sri.com> To: tcp-ip@nic.ddn.mil Subject: Domain Survey Results
Network Information Systems Center October 1, 1990
SRI International Domain Survey
INTERNET DOMAIN SURVEY
The Domain Survey statistics are compiled by ZONE, the Zealot Of Name
Edification. ZONE runs on a DEC-2065 mainframe connected to the Internet.
ZONE begins with a list of top-level domains and their associated name-servers.
For each domain, ZONE attempts to make a TCP connection to one of the listed
name-servers. Once connected, ZONE requests a dump (called a zone transfer) of
the domain being served. ZONE collects information on host names, nicknames,
addresses, mail exchanger records (MX records) and name-server records. If a
name-server record refers to a subdomain, then that subdomain is added to the
list of domains that ZONE searches. In this way, ZONE descends through the
entire domain tree trying to find all existing domains. ZONE cycles through
its list of domains left to search until it has gone through the entire list
without receiving any new information.
When ZONE finishes, it dumps out a table of all the information it has
collected in a format similar to HOSTS.TXT. ZONE also creates a file with a
list of all the domains it has found. Sometimes a domain can't be searched
because the servers can't be reached, or because of administrative restrictions
that disallow zone transfers.
ZONE reports the total number of hosts and domains it has found. The total
elapsed and cpu time to run ZONE are also indicated in the statistics, along
with the size of the generated host table. ZONE also keeps track of how many
different IP addresses each individual host has assigned to it. This table is
listed under "Number of Addresses per Host". Hosts with zero addresses are
really just mail forwarding entries, usually to a host that is not connected to
the Internet. Many of these entries are wildcards for entire domains that are
not on the Internet.
A search of a few popular keywords (names of machines and operating systems)
was done on the resulting host table. The results are listed in the section
"String Searches on Host Table". No attempt was made to make sure one of these
strings wasn't just a substring of a larger (possibly unrelated) string.
The first component of each domain name was stripped off and a list of 'host
names' was generated. The top 72 most popular host names are listed along with
the number of occurrences of each.
DOMAIN SURVEY RESULTS
Statistics
Hosts: 313,000 [minimum]
Domains: 9300 [approximately]
Total elapsed time: 5 days
Total cpu time: 4.5 hours
Host table generated: 25 megabytes
Number of Addresses per Host
Addresses Hosts
0 22964 [MX-only entries]
1 306516
2 4929
3 626
4 328
5 148
6 135
7 63
8 43
9 20
10 13
String Searches on Host Table
pc 46600
unix 38700
sun 37700
mac 28400
hp.com 24500
ibm 20700
vax 14300
vms 5900
tops-20 30
Top 72 Most Popular Host Names
171 mars 108 gauss 93 earth 83 hermes 74 europa 68 polaris
169 venus 107 opus 93 athena 82 moe 74 bach 68 odin
168 pluto 107 newton 90 larry 81 sneezy 73 uranus 67 sparky
147 jupiter 104 grumpy 89 titan 81 mozart 71 math 67 maxwell
138 zeus 103 sirius 89 sleepy 81 gandalf 71 falcon 66 pc2
138 mercury 103 gw 89 fred 80 vega 71 alpha 66 bashful
134 iris 100 merlin 87 doc 80 mickey 70 spock 66 altair
133 cs 97 eagle 85 dopey 80 astro 70 pollux 65 ra
130 orion 97 calvin 84 rigel 79 happy 70 pegasus 65 curly
125 saturn 96 thor 84 phoenix 79 cisco 70 hydra 65 castor
123 neptune 96 sol 84 io 78 helios 70 frodo 64 max
117 hobbes 96 apollo 83 snoopy 75 hal 69 euler 64 gemini
-----------[000219][next][prev][last][first]---------------------------------------------------- Date: 17 Oct 90 19:40:59 GMT From: rogue.llnl.gov!oberman@lll-winken.llnl.gov To: tcp-ip@nic.ddn.mil Subject: Re: The network
In article <9010171715.AA01958@server.af.mil>, tcpip@server.af.mil (mailing list) writes: > > I don't know that that means you can get it from the NIC, however. I am > sure that I did not get it from the NIC myself. I also remember that I got > this "map" early this year, and it hadn't been revised since 88. If > anyone does run across a really current one, I'd be interested in seeing > how well it reflects our af.mil reality (:-> The file (in PostScript) is available from nic.ddn.mil. It is netinfo:domain-chart.ps. It has not been updated since it was created in Sept. 1988. It is quite large and prints about 20 pages as I recall. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.
-----------[000220][next][prev][last][first]---------------------------------------------------- Date: 17 Oct 90 19:45:21 GMT From: portal!cup.portal.com!Will@apple.com (Will E Estes) To: tcp-ip@nic.ddn.mil Subject: Can One API Support Both TCP/IP and LU 6.2?
Do TCP/IP and and IBM's LU 6.2 share enough in common as peer-to-peer protocols that it would be possible to build a single API on top of both? I have heard some discussion that IBM's Common Programming Interface - Communications (CPI-C) might evolve into such an approach. Obviously one impediment to a common API is that the two protocols use different naming systems, but assuming you could bridge that difference are the protocols - as protocols only - semantically and syntactically similar enough that one could build a generic model that bridges the two? Thanks, Will Estes (sun!portal!cup.portal.com!Will)
-----------[000221][next][prev][last][first]---------------------------------------------------- Date: Wed, 17 Oct 90 18:30:08 +0100 From: marge@masbull.my.bull.fr (Alain Margeride) To: tcp-ip@nic.ddn.mil
Does anyone know of a product that supports DOS diskless station on TCP/IP with UNIX server using TFTP and BOOTP. Alain MARGERIDE BULL email: margeride@my.bull.fr
-----------[000222][next][prev][last][first]---------------------------------------------------- Date: 17 Oct 90 22:24:50 GMT From: bionet!synoptics!sblair@apple.com (Steven Blair) To: tcp-ip@nic.ddn.mil Subject: Re:
I've tried to respond to the poster, but was unsuccessful. Here's another: Espirit Systems Inc. (408)954-9900 I used to have a friend there, but he quit. Never used their product(s), but know that they're diskless PC's.... -- Steven C. Blair Network Operations Center SynOptics Communications Inc. Mountain View, California INTERNET: sblair@synoptics.com sblair@excalibur.synoptics.com PROBLEMS/EMAIL: HOSTMASTER@SYNOPTICS.COM postmaster@synoptics.com ---->>RIP Stevie Ray Vaughan 1954-1990 You Will Be *Missed*<<----
-----------[000223][next][prev][last][first]---------------------------------------------------- Date: 17 Oct 90 23:15:07 GMT From: palter@cs.Buffalo.EDU (Bill Palter) To: comp.protocols.tcp-ip,comp.os.vms Subject: Re: WIN$LPD on VMS
In article <1AAD8E9AD8BF401F39@CRL.AECL.CA>, TANNERC@CRL.AECL.CA (CHRISTOPHER TANNER) writes: > Greetings > Using Wollongong's version of LPD on VMS, is it possible to specify parameters > for the VMS PRINT commands such as /FLAG and /FORM=xxx? I would like an > lpr -Pxx (on UNIX) to become PRINT /Q=xx/FLAG/FORM=yy on the VMS system. Yes it is, for some reason the text of the /FORM qualifier was omitted from the documentation. In your printcap entry for the printer just specify /FORM=formname. /FLAG is more difficult, since it is basicly useless due to the fact that the filename that would be displayed on it is the name of the spool file and not that of the file that was printed. But if you want it you could take the sample USRJBC procedure from the manual and change the text of the USRJBC_OPEN routine to be: jbc_info.flags |= LPDSMB_M_FILE_FLAG; This with change the attributes of the print job to /FLAG when it is created in the VMS print queue. Bill Palter The Wollongong Group palter@twg.com
-----------[000224][next][prev][last][first]---------------------------------------------------- Date: 18 Oct 90 00:25:01 GMT From: ubc-cs!van-bc!mdivax1!zintel@beaver.cs.washington.edu To: tcp-ip@nic.ddn.mil Subject: Redirecting console IO
I am developing software on a SPARC for a Motorola delta 3400 System V box.
Both boxes are on an ethernet. I am using rsh and rlogin to copy files and
run tests. I would like to be able to access the console (hardware port 0) of
the delta box in a window under sun-os.
Any hints would be greatly appreciated.
--
Mike Zintel It is wiser to be kind
than to be wise.
-----------[000225][next][prev][last][first]---------------------------------------------------- Date: 18 Oct 90 00:35:10 GMT From: netcom!jbreeden@apple.com (John Breeden) To: tcp-ip@nic.ddn.mil Subject: Re: NCSA TELNET / BANYAN
In article <9010171533.AA22340@ftp.com> jbvb@ftp.com writes: >I have heard rumors of VINES which can use NDIS, and if you could get >it, this could be combined with the NDIS-Packet Driver adapter to use >freeware. If this is in fact a feature of their 4.0 release, I have >been told it will be available sometime this winter. > The multi-protocol NDIS interface for Vines 4.0 is available from Banyan N/C - it's patch # 1W. James' NDIS-Packet driver adapter works with Vines 4.0 P1W and cutcp or ka9q. -- John Robert Breeden, netcom!jbreeden@apple.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden ------------------------------------------------------------------- "The nice thing about standards is that you have so many to choose from. If you don't like any of them, you just wait for next year's model."
-----------[000226][next][prev][last][first]---------------------------------------------------- Date: Thu, 18 Oct 90 10:14:09 -0400 From: Craig Partridge <craig@NNSC.NSF.NET> To: tcp-ip@nic.ddn.mil, ietf@isi.edu Subject: SIGCOMM '90 materials
Hi folks:
I'm getting queries about the SIGCOMM '90 proceedings and hope this note
will help reduce the flow.
If you are a member of ACM SIGCOMM, you should receive the proceedings in
the mail any day now. If you are not a member of ACM SIGCOMM you can order
a copy of the proceedings from the ACM Order Dept at 1-800-342-6626. The
item number is 533900.
Also, yes there are some extra copies of the notes for the tutorial on
high speed networking given by Van Jacobson and Harry Rudin. CNRI is
processing orders -- send a note to Lisa Duncan (lduncan@nri.reston.va.us)
for pricing and shipping info.
Craig
PS: Unfortunately, we're out of T-shirts... :-)
-----------[000227][next][prev][last][first]---------------------------------------------------- Date: Thu, 18 Oct 90 8:36:28 CDT From: wmarko@ub.d.umn.edu (William J. Marko) To: tcp-ip@nic.ddn.mil (tcp-ip group) Subject: please use the d key
please excuse...just a test -- Bill Marko wmarko@ub.d.umn.edu internet UMD Information Services wmarko@umndul bitnet 10 University Drive 218-726-8842 work Duluth, MN 55812 218-724-7617 home
-----------[000228][next][prev][last][first]---------------------------------------------------- Date: Thu, 18 Oct 90 09:30:43 EDT From: glenn@sirius.econ.uga.edu (Glenn F. Leavell) To: TCP-IP%NIC.DDN.MIL@uga.cc.uga.edu Subject: Re: Domain Survey Results
Thanks! That's interesting. I see that 'rigel' is the 33rd most popular host name. You can't beat the originality. --Glenn
-----------[000229][next][prev][last][first]---------------------------------------------------- Date: Thu, 18 Oct 90 12:39:22 -0400 From: Steven_Carmody@brown.edu To: TCP-IP@NIC.DDN.MIL Subject: SNMP monitors
WeUre in the process of looking at SNMP based monitors, and expect to use one to monitor gateways and services in the campus network. ThereUs a discussion starting in this digest which seems headed toward developing a RscorecardS comparing many of the currently available products. I think everyone will benefit if the community creates a such a yardstick. However, in an interest in getting our site moving, and at the great risk of oversimplification, IUd like to get a sense of whatUs out there. So far, I can see three groups of products: 1) the PC-based monitors (wollongong, the recently announced novell one, etc), 2) the NyserNet/PSI monitor, and 3) a large number of commercially available, UNIX based monitors (often from router vendors). IUve separated 2 and 3 because the NyserNet package is available to universities for approximately 1/10 the cost of the packages in category 3. The question is -- are there any generalizations which can be made about each of the categories? can the PC-based packages handle a large campus sized network? are there major problems with the NyserNet monitor that the packages in category 3 have corrected? Any info and experiences would be appreciated.
-----------[000230][next][prev][last][first]---------------------------------------------------- Date: 18 October 1990 1322-PDT (Thursday) From: stanonik@nprdc.navy.mil (Ron Stanonik) To: tcp-ip@nic.ddn.mil Subject: 4.3bsd/watching icmp traffic
We've modified a copy of 4.3bsd ping to just watch icmps received; ie, not ping, just watch. We've got it running on our gateway, a vax running 4.3bsd. We'd also like to see icmps being forwarded through the vax. Any suggestions? Maybe using some socket type other than SOCK_RAW? Or maybe 4.3bsd just doesn't give applications a chance to get their hands on packets being forwarded? Thanks, Ron Stanonik stanonik@nprdc.navy.mil
-----------[000231][next][prev][last][first]---------------------------------------------------- Date: 18 Oct 90 09:55:50 GMT From: psuvm!barilvm!p88036@psuvax1.cs.psu.edu To: tcp-ip@nic.ddn.mil Subject: station name
Hi, here is my question:
Is there a way to get the name of the station I actually logged in from,
( this can be an X terminal or another workstation) so that I could direct
Xwindows output to this screen in some automatic way ?
Any information will be appriciated.
Ephraim.
-----------[000232][next][prev][last][first]---------------------------------------------------- Date: 18 Oct 90 10:46:19 GMT From: mcsun!ub4b!dg13!pnoe@uunet.uu.net (Pierre Noel) To: tcp-ip@nic.ddn.mil Subject: Enormous difference of speed between PC/TCP and PCNFS
Hi NetLand, I made a program using socket protocols under TCP/IP Ethernet, to communicate with a Unix Server (in that case, SCO-ODT Unix on a Olivetti's XP9 with a 3COM's 3C503 Ethernet Card), I also made the Server part of the protocol then I can control both sides of the problem. My problem seems to be in the client side of the program : due to our site configuration, I gave two versions of the product, one for PC/TCP (Release 2.04) and the other for PC-NFS (Release 3.01). The main purpose of the application is to download lot of files (2/3 Mbytes each time) from the Server to the Client requesting them; the download is segmented, at the socket level, in records of 1024 bytes each, using the send() and recv() function calls. The sources of the PC/TCP and PC-NFS application are excactly the same, only the libraries linked to are different. I made test on the same machine (Olivetti M300 with a 3COM 3C501 Ethernet Card), the result is absolutely uncomprehensible : the relation between the time spent by the PC/TCP and the PC-NFS application is about 1 to 10 !!! I've checked where was the problem and what I've seen is that the difference of performance is located in the time spent between reception of records. I've also encountered the same kind of problem with PC-NFS when trying to rcp multiple small file one after another : the 2 firsts were transmitted ok but theother ones had also big delay. My question is : do someone has knowledge of similar problem and do you know if it is possible to tune the product to have acceptable performance ? I know that the solution is maybe changing all our PC-NFS to PC/TCP but as our park is about 700 PCs and our needs for the application are really urgent, it must not be the right solution now. I would be very happy to receive clues. Thank you for your attention and apologies for spelling mistakes Pierre Noel pnoe@dg13.cec.be
-----------[000233][next][prev][last][first]---------------------------------------------------- Date: Thu, 18 Oct 90 19:27:18 PDT From: David Doll <davidd@hitl.vrnet.washington.edu> To: craig@nnsc.nsf.net Cc: tcp-ip@nic.ddn.mil, ietf@isi.edu Subject: SIGCOMM '90 materials
So can you let us know when there are more t-shirts? :) David Doll Programmer/Analyst Human Interface Technology Lab FU - 20 Seattle, WA 98195 (206) 543-5075 davidd@hitl.vrnet.washington.edu
-----------[000234][next][prev][last][first]---------------------------------------------------- Date: 18 Oct 90 12:53:29 GMT From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) To: comp.protocols.tcp-ip Subject: load sharing telnet/rlogin/route to mainframe
we have a mainframe with a lot of timesharers who rlogin/telnet from workstations - the mainframe ethernet i/f is a bit slow so we've put several on the machine... can we set up clients so that they pick which i/f to route to uniform random, or even deterministically - we dont want users to know and we dont want to hack rlogin (we've done this before the other way round to loadsare users round a lot of workstations)... could we magic it up by setting a route metric differently for each of the masionframes i/f IP addressses in different clients perhaps? (routing seems the natural place to add loadsharing) but remembering they are all on same net & even subnet...(i.e. add a host route for each i/f/?)? what have other people done (and no humerous remarks about buy a different mainframe or get different i/fs we didnt really have a choice:-) ? thanks jon
-----------[000235][next][prev][last][first]---------------------------------------------------- Date: 18 Oct 90 13:40:55 GMT From: shlump.nac.dec.com!shug.enet.dec.com!ciarfella@decuac.dec.com (Paul Ciarfella) To: tcp-ip@nic.ddn.mil Subject: Does ICMP optional data include IP header + options?
Does the Internet header + 64 bits of data copied into the data field
of an ICMP error message include the options from the original IP
packet (if present), ie.,
data = IP header + options + 64 bits of data
or
data = IP header + 64 bits of data
Thanks,
Paul C
---------------------------------------------------------------------------
Paul Ciarfella Digital Equipment Corporation Littleton, MA
---------------------------------------------------------------------------
Disclaimer : My opinions are my own. | When in doubt, mumble.
Address : ciarfella@shug.enet.dec.com
---------------------------------------------------------------------------
-----------[000236][next][prev][last][first]---------------------------------------------------- Date: 18 Oct 90 14:44:20 GMT From: princeton.edu!tengi@princeton.edu (Christopher Tengi) To: tcp-ip@nic.ddn.mil Subject: Re: in-addr.arpa used?
If you are going to get them to implement in-addr.arpa on your local nameserver, don't forget to have them get authority delegeted to them from the NIC. ie Princeton has authority for Princeton.EDU and 112.128.in-addr.arpa. /Chris -- ==========----------==========---------+---------==========----------========== UUCP: ...princeton!tengi VOICEnet: 609-258-6799 INTERNET: tengi@princeton.edu FAX: 609-258-3943 BITNET: TENGI@PUCC
-----------[000237][next][prev][last][first]---------------------------------------------------- Date: Thu, 18 Oct 90 13:53:29 +0100 From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> To: tcp-ip@nic.ddn.mil Subject: load sharing telnet/rlogin/route to mainframe
we have a mainframe with a lot of timesharers who rlogin/telnet from workstations - the mainframe ethernet i/f is a bit slow so we've put several on the machine... can we set up clients so that they pick which i/f to route to uniform random, or even deterministically - we dont want users to know and we dont want to hack rlogin (we've done this before the other way round to loadsare users round a lot of workstations)... could we magic it up by setting a route metric differently for each of the masionframes i/f IP addressses in different clients perhaps? (routing seems the natural place to add loadsharing) but remembering they are all on same net & even subnet...(i.e. add a host route for each i/f/?)? what have other people done (and no humerous remarks about buy a different mainframe or get different i/fs we didnt really have a choice:-) ? thanks jon
-----------[000238][next][prev][last][first]---------------------------------------------------- Date: 18 Oct 90 16:21:50 GMT From: hpda!hpcuhb!hpindda!subbu@ucbvax.Berkeley.EDU (MCV Subramaniam) To: tcp-ip@nic.ddn.mil Subject: Re: single tcpcb loopback bug
>This seems to be a previously unpublished bug. Yes, it is unpublished, but not unreported. We, at HP have found this bug in 4.3 BSD, and have submitted a fix to Mike Karels. You may not believe it, but 4.3 BSD cannot handle crossing SYNs! (i.e. if two 4.3 machines send SYN to each other and they cross each other, the machines will go in an infinite loop sending SYN|ACKs to each other). Connecting to the same port number causes a similar situation to happen. You send a SYN and go into SYN_SENT state, and you receive the SYN while in SYN_SENT state! The fix involves handling a SYN correctly while in the SYN_SENT state. >I suspect that a workable fix is to use the tcpcb's ISN when sending >any SYN, although I haven't tried this yet. However, the failure to >do this ought to have generated a RST, IMHO, so I guess there are >actually two bugs here. The ISN is already used while sending a SYN. -Subbu
-----------[000239][next][prev][last][first]---------------------------------------------------- Date: 18 Oct 90 16:42:00 GMT From: csusac!csuchico.edu!csuchico.edu!robin@ucdavis.ucdavis.edu (Robin Goldstone) To: tcp-ip@nic.ddn.mil Subject: question about SMTP MX records
I am trying to send a message to someone@applelink.apple.com. This host has no TYPE A record, only an MX record. My mailer currently cannot resolve MX records. As a workaround, I thought I would just send to someone%applelink.apple.com@apple.com. It is my (limited) understanding that addresses are parsed from right to left, so this message would be sent to apple.com, who would then be able to forward it to applelink.apple.com. Some questions: 1) is the syntax of the address I am trying to use valid? 2) am I violating any network rules by routing my message through another host? 3) should this message be getting delivered? I have sent several test messages that have disappeared into a black hole... Thanks in advance for any help you can provide! Robin Goldstone, Systems Software Specialist California State University, Chico Computing Services robin@csuchico.edu
-----------[000240][next][prev][last][first]---------------------------------------------------- Date: 18 Oct 90 18:52:49 GMT From: cunixf.cc.columbia.edu!cs.columbia.edu!ji@rutgers.edu (John Ioannidis) To: tcp-ip@nic.ddn.mil Subject: Re: File Broadcast
>In article <45509@apple.Apple.COM> erekose@apple.com (Erik Scheelke) writes: > > We have a local area network of UNIX based PCs running TCP-IP, and I > was asked if there was any software that will broadcast a file to all > machines on the network. I didn't know of any and was wondering if > anyone out there in netland knew of any. If not, I guess I will have > to write something myself. I would appreciate any infomation about > programs or algorithms that do file broadcasting. It must use a broadcast, > not a copy to one machine then copy to another method (i.e. UDP), and > if a machine is up it must reliably send the file. > > We have written a protocol we call "A Coherent File Transfer Protocol" (RFC number pending). The idea is that the server broadcasts packets from a file, and all the clients grab them as they fly by. If they miss any, they send block requests to the server. We are in the process of polishing the reference port, which will be available from cs.columbia.edu [128.59.16.20] for anonymous ftp. Watch this space! /ji In-Real-Life: John "Heldenprogrammer" Ioannidis E-Mail-To: ji@cs.columbia.edu V-Mail-To: +1 212 854 8120 P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027
-----------[000241][next][prev][last][first]---------------------------------------------------- Date: 18 Oct 90 18:56:38 GMT From: pyramid!lstowell@hplabs.hpl.hp.com (Lon Stowell) To: tcp-ip@nic.ddn.mil Subject: Re: Can One API Support Both TCP/IP and LU 6.2?
Yes, you can build a common API. CPI-C on the AS/400 is such a
product, you can run TCP/IP, OSI, SNA from the same API. The
difficulty in naming conventions is hidden in the fine print of
such API's....as are the other differences in these protocol
stacks. All of them provide essentially similar services, but
the LAYER within which a specific service is performed as well
as the implementation method varies widely.
The IBM technique is to note that all of the naming, route
discovery, etc. methods are "implementation specific" and that
they are utility functions performed by the Physical Unit.
Not only do the naming conventions of LU 6.2 differ from TCP/IP,
the techniques for route discovery and routing differ as well.
About the only thing the two have in common is the ability to
provide a high level common API.
Such a "generic" API implementation will never be as efficient
as a protocol specific one, but it sure makes things a LOT
easier on programmers, user's etc. RAM is cheap, and MIPS are
always available. Programmer's blood pressure and sanity are
a little more precious.....
/|
\'o.O'
=(___)=
U
THPTH! ACKHH!
-----------[000242][next][prev][last][first]---------------------------------------------------- Date: 18 Oct 90 21:59:03 GMT From: harvisr!sob@husc6.harvard.edu (Scott Bradner) To: tcp-ip@nic.ddn.mil Subject: router tests volume 3
Well here it is, the results of the 3rd round of router testing.
This round consists of local Ethernet to Ethernet routers, all of them I
could get.
This document is copyright 1990 by Scott Bradner.
You can repoduce this posting in any way you want as long as the copy
is complete with no modifications.
A set of files for the slides that I used in the InterOp report are on
husc6.harvard.edu in pub/rtests (the old stuff is in "old"), lots of
nice graphs etc.
Scott Bradner, Harvard University, 33 Kirkland St., Cambridge MA 02138
(617)495-3864, sob@harvard.edu
First some history:
I got a call from Wellfleet back in August wondering if I was going
to go through another round of tests. I said that I did not have the
required equipment, since many of the vendors now had equipment that was
faster than the test setup we had used last year. "We will give you some
equipment to do your tests." he said. "Well..." said I, "how about a loan?",
"Sure" he said. So after some discussion they agreed to loan me some of
the equipment that they were using for in house testing. They also agreeed
to provide access to Terry Bradley who had done all the programming on the
test bed. (I, naturally, wanted some changes in the test software.)
Terry spent quite a while making the changes I requested and getting out a
number of small bugs, and I sent out a call for equipment to be tested. I
got back quite a few devices and herein report the results of the tests.
All but one of the vendors sent a person along with the
router to do setup. (So I would not have to read all those manuals and set
the things up wrong in the end.) The tests for each of the devices were
done over one or two days at a lab at Harvard.
The test setup:
A modified Wellfleet router was used a a test source. This device
had two separate channels of test traffic. Each channel consisted
of one packet source port and one "keep alive" port. The "keep alive"
port sent out groups of frames designed to convince the router that a
node existed on this "net" that spoke some specific protocols. The
supported protocols were:
IP ( keep alive was a ARP response)
DECNET (hello packet)
AppleTalk II (AARP packet)
IPX (IPX-RIP? response)
bridge mode ( a packet with a specific source MAC address)
The device-to-be-tested was attached so that an "input" port
was attached to one of the test frame sources and an "output" port
was attached to the corresponding "keep alive" port. If the device had
four or more ports, both sets of test channels were used.
The modified Wellfleet router generated a stream of test frames
consisting of a specific number of frames, in a selected protocol, of a
selected size and with a selected interframe gap (ifg). One of the test
channels (channel 3) was used for all of the tests and the 2nd
channel was used only for the dual stream test.
test source frame rate:
size theoretical channel "3" channel "4"
64 14880 14489 14549
128 8445 8324 8340
256 4528 4494 4498
512 2349 2340 2341
1024 1197 1195 1195
1518 812 812 812
(The Wellfleet test code can do quite a bit more than I made use of,
it can generate mixed protocol packet streams for example, additional
work needs to be done to create a set of test specifications that better
emulate a "real" data network.)
The counter:
A HP 4972A Lan Protocol Analyzer was used to find the frame rates
and to count the output frames. The HP ran the "stats" program
to monitor the network.
The router configuration:
The router was configured at the start of the test suite and the
configuration was not changed throughout the first set of tests.
The configuration was then altered to add a single "filter"
condition, tests were run on that, then the configuration was
changed to add 9 more filter conditions and tests were run on that.
The bridge tests were configured for and run separately.
The tests:
Note:
The design of these tests comes from the work of the IETF
Benchmarking Methodology Working Group.
single channel:
"delay"
Aim - find delay through router.
A Tektronix 2337 scope was attached to both the input and
output router ports.
A stream of frames with a large ifg was sent through the router.
The scope was used to measure the time delay between the end
of the input frame and the start of the output frame.
"raw rate"
Aim - find out impact of max rate input data rate.
The HP was connected to the "output" port of the router.
A stream of frames of a specific protocol and a specific size
with the minimum ifg, was sent to the input port on
the router. The number of frames was selected to produce about
30 sec of data stream.
The "stats" program was reset after the start of the data stream
and the "10 sec avg" value was watched to get the "raw rate".
"max rate"
Aim - find highest rate at which router passes 100% of input frames.
The HP was connected to the "output" port of the router.
A stream of frames of a specific protocol and a specific size
with a selected inter frame gap, was sent to the input port on
the router. The number of frames was selected to produce about
20 sec of data stream.
The "stats" program was reset before the data stream was started.
The "total frames" value was used to see if all of the offered
frames were forwarded. If not, the ifg was increased, if yes
the ifg was reduced. This process was followed until the point
at which a reduction of "1" in the ifg would not pass all the
frames.
The HP was then attached to the frame source and the test rerun
with the determined ifg to get the frame rate.
"dual stream"
Aim - find effect of more than one data stream through router.
"raw rate" test run but with both frame sources sending frames
with the minimum ifg.
The HP was first connected to one "output", a test was run to
find the rate, then the HP was moved to the other output and the
test rerun.
NOTE: this test is flawed, the "right" way to do this is the same
as for the "max rate" test, putting the same frame rate into both
inputs and counting the outputs. But this was just to much work,
strong need for automation.
Some nomenclature:
"one filter"
permit traffic from ip address 192.32.100.1 to 192.32.200.1
"10 filter"
permit traffic from ip address 192.32.100.11 to 192.32.200.11
permit traffic from ip address 192.32.100.12 to 192.32.200.12
permit traffic from ip address 192.32.100.13 to 192.32.200.13
permit traffic from ip address 192.32.100.14 to 192.32.200.14
permit traffic from ip address 192.32.100.15 to 192.32.200.15
permit traffic from ip address 192.32.100.16 to 192.32.200.16
permit traffic from ip address 192.32.100.17 to 192.32.200.17
permit traffic from ip address 192.32.100.18 to 192.32.200.18
permit traffic from ip address 192.32.100.19 to 192.32.200.19
permit traffic from ip address 192.32.100.1 to 192.32.200.1
"between interface cards" for the single channel tests means
a data stream that goes in a port on one Ethernet interface
card and out a port on a 2nd Ethernet interface card.
"within interface card" for the single stream tests means
a data stream that goes in a port on an Ethernet
interface card and out on another port on the same card.
"between interface cards" for the dual stream tests means two data
streams, both of which come in ports on one Ethernet
interface card and both of which exit from ports on a 2nd
Ethernet interface card.
"within interface card" for the dual stream tests means one data
stream that comes in a port on one Ethernet interface card
and exits via another port on the same card, and a 2nd
stream that enters on one port on a separate Ethernet
interface card and exits via a 2nd port on this separate
card.
The results:
(I have checked these numbers but there may be transcription or
typing errors.)
3com NETBuilder - TCP/IP - within interface card
size theo test ip_max ip_fld
64 14880 14489 6404 6401
128 8445 8324 6648 6553
256 4528 4494 4004 3953
512 2349 2340 2202 2183
1024 1197 1195 1010 1153
1518 812 812 799 792
3com NETBuilder - Bridge Mode - within interface card
size theo test br_max br_fld
64 14880 14489 9830 9750
128 8445 8324 6735 6564
256 4528 4494 3994 3953
512 2349 2340 2202 2183
1024 1197 1195 1159 1153
1518 812 812 805 792
BBN T20 - TCP/IP - within interface card
size theo test ip_max ip_fld 1f_max 1f_fld 10f_max 10f_fld
64 14880 14489 4315 4664 2620 2778 2620 2775
128 8445 8324 4339 4654 2433 2777 2433 2777
256 4528 4494 4493 4493 2231 2772 2231 2774
512 2349 2340 2340 2340 2340 2340 2340 2340
1024 1197 1195 1194 1194 1194 1194 1194 1194
1518 812 812 811 811 811 811 811 811
cisco AGS+ - TCP/IP - between interface cards
size theo test ip_max ip_fld 1f_max 1f_fld 10f_max 10f_fld
64 14880 14489 14488 14488 14488 14488 14488 14488
128 8445 8324 8324 8324 8324 8324 8324 8324
256 4528 4494 4493 4493 4494 4494 4494 4494
512 2349 2340 2340 2340 2340 2340 2340 2340
1024 1197 1195 1194 1194 1195 1195 1195 1195
1518 812 812 811 811 812 812 812 812
cisco AGS+ - AppleTalk II - between interface cards
size theo test at2_max at2_fld
64 14880 14489 14488 14488
128 8445 8324 8324 8324
256 4528 4494 4494 4494
512 2349 2340 2340 2340
cisco AGS+ - DECNET - between interface cards
size theo test dn_max dn_fld
64 14880 14489 13097 13270
128 8445 8324 8324 8324
256 4528 4494 4494 4494
512 2349 2340 2340 2340
1024 1197 1195 1195 1195
1518 812 812 812 812
cisco AGS+ - IPX - between interface cards
size theo test ipx_max ipx_fld
64 14880 14489 14488 14488
128 8445 8324 8324 8324
256 4528 4494 4494 4494
512 2349 2340 2340 2340
1024 1197 1195 1195 1195
1518 812 812 812 812
cisco AGS+ - Bridge Mode - between interface cards
size theo test br_max br_fld
64 14880 14489 14488 14488
128 8445 8324 8324 8324
256 4528 4494 4494 4494
512 2349 2340 2340 2340
1024 1197 1195 1195 1195
1518 812 812 812 812
cisco AGS+ - Dual IP Streams - between interface cards
size theo test1 test2 d1_fld d2_fld
64 14880 14489 14549 9682 9700
128 8445 8324 8340 8324 8340
256 4528 4494 4498 4493 4498
512 2349 2340 2341 2340 2341
1024 1197 1195 1195 1194 1195
1518 812 812 812 812 812
cisco AGS+ - TCP/IP - within interface card
size theo test ip_max ip_fld 1f_max 1f_fld 10f_max 10f_fld
64 14880 14489 14488 14488 14488 14488 14488 14488
128 8445 8324 8324 8324 8324 8324 8324 8324
256 4528 4494 4494 4494 4494 4494 4494 4494
512 2349 2340 2340 2340 2340 2340 2340 2340
1024 1197 1195 1195 1195 1194 1194 1194 1194
1518 812 812 812 812 811 811 811 811
cisco AGS+ - AppleTalk II - within interface card
size theo test at2_max at2_fld
64 14880 14489 14488 14488
128 8445 8324 8324 8324
256 4528 4494 4494 4494
512 2349 2340 2340 2340
cisco AGS+ - DECNET - within interface card
size theo test dn_max dn_fld
64 14880 14489 13097 13256
128 8445 8324 8323 8323
256 4528 4494 4494 4494
512 2349 2340 2340 2340
1024 1197 1195 1195 1195
1518 812 812 812 812
cisco AGS+ - IPX - within interface card
size theo test ipx_max ipx_fld
64 14880 14489 14488 14488
128 8445 8324 8324 8324
256 4528 4494 4494 4494
512 2349 2340 2340 2340
1024 1197 1195 1195 1195
1518 812 812 812 812
cisco AGS+ - Bridge Mode - within interface card
size theo test br_max br_fld
64 14880 14489 14488 14488
128 8445 8324 8324 8324
256 4528 4494 4494 4494
512 2349 2340 2340 2340
1024 1197 1195 1195 1195
1518 812 812 812 812
cisco AGS+ - Dual IP Streams - within interface card
size theo test1 test2 d1_fld d2_fld
64 14880 14489 14549 9689 9698
128 8445 8324 8340 8323 8340
256 4528 4494 4498 4494 4498
512 2349 2340 2341 2340 2341
1024 1197 1195 1195 1194 1195
1518 812 812 812 812 812
Network Systems Corporation EN640-8 - TCP/IP - between interface cards
size theo test ip_max ip_fld 1f_max 1f_fld 10f_max 10f_fld
64 14880 14489 6327 6233 4636 4413 1718 1670
128 8445 8324 5105 5189 4111 3875 1629 1576
256 4528 4494 3755 3752 3745 3756 1599 1536
512 2349 2340 2124 2123 2122 2123 1565 1493
1024 1197 1195 1137 1136 1138 1138 1141 1135
1518 812 812 786 784 787 786 788 784
Network Systems Corporation EN640-8 - AppleTalk II - between interface cards
size theo test at2_max at2_fld
64 14880 14489 827 0
128 8445 8324 808 0
256 4528 4494 770 0
512 2349 2340 702 269
Network Systems Corporation EN640-8 - DECNET - between interface cards
size theo test dn_max dn_fld
64 14880 14489 919 0
128 8445 8324 886 0
256 4528 4494 825 0
512 2349 2340 727 280
1024 1197 1195 588 452
1518 812 812 443 381
Network Systems Corporation EN640-8 - Dual IP Streams - between interface cards
size theo test1 test2 d1_fld d2_fld
64 14880 14489 14549 3224 3396
128 8445 8324 8340 2832 2975
256 4528 4494 4498 2638 2651
512 2349 2340 2341 2335 2123
1024 1197 1195 1195 1138 1195
1518 812 812 812 786 812
Network Systems Corporation EN640-8 - TCP/IP - within interface card
size theo test ip_max ip_fld 1f_max 1f_fld 10f_max 10f_fld
64 14880 14489 5986 6604 4775 4630 1732 1702
128 8445 8324 5259 5732 4605 4164 1662 1629
256 4528 4494 3727 3757 3729 3641 1541 1523
512 2349 2340 2128 2123 2122 2123 1508 1450
1024 1197 1195 1140 1138 1139 1135 1139 1135
1518 812 812 788 784 788 783 780 782
Network Systems Corporation EN640-8 - AppleTalk II - within interface card
size theo test at2_max at2_fld
64 14880 14489 828 0
128 8445 8324 805 0
256 4528 4494 767 0
512 2349 2340 701 266
Network Systems Corporation EN640-8 - DECNET - within interface card
size theo test dn_max dn_fld
64 14880 14489 919 0
128 8445 8324 885 0
256 4528 4494 826 0
512 2349 2340 719 278
1024 1197 1195 580 453
1518 812 812 439 381
Novell NetWare 386 - TCP/IP - between interface cards
size theo test ip_max ip_fld
64 14880 14489 3275 3270
128 8445 8324 3207 3202
256 4528 4494 2892 2856
512 2349 2340 1822 1764
1024 1197 1195 1050 1030
1518 812 812 744 731
Novell NetWare 386 - IPX - between interface cards
size theo test ipx_max ipx_fld
64 14880 14489 3295 3240
128 8445 8324 3274 3172
256 4528 4494 2953 2852
512 2349 2340 1861 1768
1024 1197 1195 1078 1031
1518 812 812 787 731
Proteon P4200 - TCP/IP - between interface cards
size theo test ip_max ip_fld 1f_max 1f_fld 10f_max 10f_fld
64 14880 14489 3616 3576 2675 2054 2675 2050
128 8445 8324 3081 3058 2247 1674 2258 1668
256 4528 4494 1667 1529 1493 1253 1493 1248
512 2349 2340 948 896 875 815 876 814
1024 1197 1195 508 473 465 447 465 447
1518 812 812 348 325 324 313 325 313
Proteon P4200 - DECNET - between interface cards
size theo test dn_max dn_fld
64 14880 14489 1747 1469
128 8445 8324 1595 1453
256 4528 4494 1505 1401
512 2349 2340 968 804
1024 1197 1195 539 452
1518 812 812 405 310
Proteon P4200 - IPX - between interface cards
size theo test ipx_max ipx_fld
64 14880 14489 1881 1593
128 8445 8324 1718 1560
256 4528 4494 1608 1503
512 2349 2340 970 812
1024 1197 1195 519 450
1518 812 812 411 310
Proteon P4200 - Dual IP Streams - between interface cards
size theo test1 test2 d1_fld d2_fld
64 14880 14489 14549 1085 1181
128 8445 8324 8340 U U
256 4528 4494 4498 825 833
512 2349 2340 2341 665 1107
1024 1197 1195 1195 1109 665
1518 812 812 812 270 433
Proteon rig - TCP/IP - between interface cards
size theo test ip_max ip_fld 1f_max 1f_fld 10f_max 10f_fld
64 14880 14489 12802 12142 4622 4513 4605 4530
128 8445 8324 7896 7998 4233 4212 4222 4204
256 4528 4494 4351 4350 2964 2944 2964 2943
512 2349 2340 2287 2294 1850 1835 1850 1837
1024 1197 1195 1186 1181 1060 1047 1060 1048
1518 812 812 812 805 749 741 749 742
Proteon rig - Dual IP Streams - between interface cards
size theo test1 test2 d1_fld d2_fld
64 14880 14489 14549 8516 7749
128 8445 8324 8340 8027 6989
256 4528 4494 4498 4494 3936
512 2349 2340 2341 2333 4098
1024 1197 1195 1195 1193 1192
1518 812 812 812 810 809
Timeplex TIME/LAN 100 - TCP/IP - between interface cards
size theo test ip_max ip_fld
64 14880 14489 5480 4822
128 8445 8324 4865 4162
256 4528 4494 3287 3253
512 2349 2340 1969 1949
1024 1197 1195 977 973
1518 812 812 691 687
Wellfleet Link Node - TCP/IP - between interface cards
size theo test ip_max ip_fld 1f_max 1f_fld 10f_max 10f_fld
64 14880 14489 14473 14473 11107 10778 9708 9998
128 8445 8324 8322 8322 8322 8322 8324 8324
256 4528 4494 4493 4493 4494 4494 4494 4494
512 2349 2340 2340 2340 2340 2340 2340 2340
1024 1197 1195 1196 1196 1193 1193 1195 1195
1518 812 812 811 811 811 811 812 812
Wellfleet Link Node - AppleTalk II - between interface cards
size theo test at2_max at2_fld
64 14880 14489 12676 13629
128 8445 8324 8324 8324
256 4528 4494 4493 4493
512 2349 2340 2341 2341
Wellfleet Link Node - DECNET - between interface cards
size theo test dn_max dn_fld
64 14880 14489 10151 10404
128 8445 8324 8322 8322
256 4528 4494 4494 4494
512 2349 2340 2340 2340
1024 1197 1195 1194 1194
1518 812 812 812 812
Wellfleet Link Node - IPX - between interface cards
size theo test ipx_max ipx_fld
64 14880 14489 10420 10642
128 8445 8324 8324 8324
256 4528 4494 4493 4493
512 2349 2340 2340 2340
1024 1197 1195 1194 1194
1518 812 812 812 812
Wellfleet Link Node - Bridge Mode - between interface cards
size theo test br_max br_fld
64 14880 14489 14488 14488
128 8445 8324 8324 8324
256 4528 4494 4494 4494
512 2349 2340 2340 2340
1024 1197 1195 1195 1195
1518 812 812 812 812
Wellfleet Link Node - Dual IP Streams - between interface cards
size theo test1 test2 d1_fld d2_fld
64 14880 14489 14549 7790 7780
128 8445 8324 8340 7186 7196
256 4528 4494 4498 4491 4493
512 2349 2340 2341 2340 2339
1024 1197 1195 1195 1194 1194
1518 812 812 812 811 811
Wellfleet Link Node - TCP/IP - within interface card
size theo test ip_max ip_fld 1f_max 1f_fld 1f_max 1f_fld
64 14880 14489 11086 12646 8983 9636 8930 9655
128 8445 8324 8322 8322 8324 8324 8324 8324
256 4528 4494 4493 4493 4494 4494 4494 4494
512 2349 2340 2340 2340 2340 2340 2340 2340
1024 1197 1195 1196 1196 1193 1193 1193 1193
1518 812 812 811 811 811 811 811 811
Wellfleet Link Node - AppleTalk II - within interface card
size theo test at2_max at2_fld
64 14880 14489 10707 11390
128 8445 8324 8322 8322
256 4528 4494 4493 4493
512 2349 2340 2339 2339
Wellfleet Link Node - DECNET - within interface card
size theo test dn_max dn_fld
64 14880 14489 8634 8982
128 8445 8324 8322 8322
256 4528 4494 4494 4494
512 2349 2340 2340 2340
1024 1197 1195 1193 1193
1518 812 812 811 811
Wellfleet Link Node - IPX - within interface card
size theo test ipx_max ipx_fld
64 14880 14489 8780 9109
128 8445 8324 8322 8322
256 4528 4494 4494 4494
512 2349 2340 2340 2340
1024 1197 1195 1194 1194
1518 812 812 811 811
Wellfleet Link Node - Bridge Mode - within interface card
size theo test br_max br_fld
64 14880 14489 14488 14488
128 8445 8324 8324 8324
256 4528 4494 4494 4494
512 2349 2340 2340 2340
1024 1197 1195 1195 1195
1518 812 812 812 812
Wellfleet Link Node - Dual IP Streams - within interface card
size theo test1 test2 d1_fld d2_fld
64 14880 14489 14549 12652 13024
128 8445 8324 8340 8324 8337
256 4528 4494 4498 4491 4497
512 2349 2340 2341 2334 2341
1024 1197 1195 1195 1195 1195
1518 812 812 812 811 811
-----------[000243][next][prev][last][first]---------------------------------------------------- Date: 18 Oct 90 23:18:54 GMT From: brunner@bullhead.uucp To: comp.sys.ibm.pc.rt,comp.protocols.tcp-ip Subject: Re: X25 for RT running BSD 4.3
In article <788@nikhefk.UUCP> werner@nikhefk.UUCP (Werner Vogels) writes: > >Does anybody know anything about a X25 board and software for a RT running >BSD4.3 . > >Werner H.P. Vogels >Software Expertise Centrum >Haagse Hogeschool, Intersector Informatica tel: +31 70 618419 >Louis Couperusplein 2-19, 2514 HP Den Haag E-mail: werner@nikhefk.nikhef.nl >The Netherlands or werner@hhinsi.uucp I don't know of one, if there is one I would like to know also. I'm cross posting this to the tcp-ip list as someone on the tcp-ip list may know of an X.25 board for the IBM RT running 4.3bsd. #include <std/disclaimer.h> Eric Brunner, Consultant, IBM AWD Palo Alto (415) 855-4486 inet: brunner@monet.berkeley.edu uucp: uunet!ibmsupt!brunner trying to understand multiprocessing is like having bees live inside your head.
-----------[000244][next][prev][last][first]---------------------------------------------------- Date: Fri, 19 Oct 90 07:55:37 -0400 From: Scott Brim <swb@chumley.TN.Cornell.EDU> To: tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols
And don't forget about VMTP.
-----------[000245][next][prev][last][first]---------------------------------------------------- Date: 19 Oct 90 03:19:58 GMT From: olivea!samsung!munnari.oz.au!mtiame!ubeaut!mwp@apple.com (Michael Paddon) To: tcp-ip@nic.ddn.mil Subject: Re: TCP segment size -- user defined?
From article <538@gohp3.graphon.com>, by dc@gohp3.graphon.com (Darren Croke): > In article <256@ubeaut.oz.au> mwp@ubeaut.oz.au (Michael Paddon) writes: >> >>There is not much point setting TCP_MSS to be greater than >> (maximum IP packet size - IP header size - TCP header size) >>[536 octets] since IP fragmentation will take place. Receipt of a >>fragmented packet is an all or nothing proposition; a good thing to >>avoid for throughput reasons. >> > I think you will find that it is common for IP implementations to > send and accept datagrams without fragmentation up to > (connected network MTU - IP header size - TCP header size). You are, of course, correct. The link-layer MTU is the important variable here, determining the maximum size of datagrams (up to 64K octets). I pulled the value 536 from some work I was doing with a SLIP implementation, forgetting at the time that it was a special case. Michael ------------------------------------------------------------------- | | Internet: paddon@meo78b.enet.dec.com | | | ACSnet: mwp@ubeaut.oz.au | | Michael Paddon | ACSnet: mwp@munnari.oz.au | | | EasyNet: meo78b::paddon | | | Voice: +61 3 895 9392 | -------------------------------------------------------------------
-----------[000246][next][prev][last][first]---------------------------------------------------- Date: Fri, 19 Oct 90 08:41 EST From: Bob Stine <0004219666@mcimail.com> To: Chris Johnson <sgi!cjohnson%somni.wpd.sgi.com@ucbvax.berkeley.edu>, tcp-ip <tcp-ip@nic.ddn.mil> Subject: Re: Reliable Datagram ??? Protocols
Your message suggests that you are differing over facts, when it's clear that the difference is in terminology. I'd bet that Jon is one of the original coiners of the term 'datagram'. (If not, I'm sure he rubbed shoulders with the fellow that coined the term.) The XTP use of the term could be considered inappropriate. Perhaps it should have been called something else. (Reliable transaction packet? Unit message?) - Bob Stine
-----------[000247][next][prev][last][first]---------------------------------------------------- Date: Fri, 19 Oct 90 14:40:40 -0400 From: tmallory@BBN.COM To: tcp-ip@nic.ddn.mil Cc: tmallory@BBN.COM Subject: Re: Reliable Datagram Protocol
I've didn't save the original message because I felt sure someone would
chip in the following:
from rfc-index.txt.1174:
1151 Partridge, C.; Hinden, R.M. Version 2 of the Reliable Data Protocol
(RDP). 1990 April; 4 p. (Format: TXT=8293 bytes) (Updates RFC 908)
This is really an addendum to RFC 908, which must also be retrieved.
[the first name for this protocol WAS Reliable Datagram Protocol]
Not that you will find this widely implemented, but it surely ought to be
mentioned given the original request.
Tracy
-----------[000248][next][prev][last][first]---------------------------------------------------- Date: Fri, 19 Oct 90 09:23:17 +0100 From: Denis.Russell@newcastle.ac.uk To: tcp-ip@nic.ddn.mil Subject: IP over X.25 - summary
On 4th Oct I sent out a query about routing extensive IP over an
X.25 network. This is a brief summary of the responses, and
other information gathered at the same time. Many thanks to all
those who responded.
I got several messages in reply. It seems that the main
commercial routers have the right characteristics for the task.
They can support high speed, have settable inactivity timers,
multiple X.25 calls, use X.25 calls for two-way traffic. All
the things we'd hoped for, even expected, but weren't actually
certain about.
It was confirmed that the Sun software established permanent
X.25 calls and never cleared them down, but several people
referred us to the Nottingham software that did not suffer from
these problems.
Several people warned us that large packet and window sizes were
an absolute must for throughput.
Sadly, and despite a couple of specific queries, there were no
responses directly from people relating experience of setting up
an extensive IP network on top of an X.25 network rather than
just operating a few links. However, the second-hand wisdom
(which I do not doubt) was that it was not an ideal way to run
an IP network, but that, subject to tuning, etc, it would work
OK.
Denis.
-----------[000249][next][prev][last][first]---------------------------------------------------- Date: 19 Oct 90 11:06:16 GMT From: clyde.concordia.ca!news-server.csri.toronto.edu!utgpu!watserv1!ria!ria.ccs.uwo.ca!peter@uunet.uu.net (Peter Marshall) To: tcp-ip@nic.ddn.mil Subject: Re: Ethernet Address Uniqueness...
In article <2126@excelan.COM>, donp@na.excelan.com (don provan) writes: |> In article <1990Oct5.123350.145@arizona.edu> leonard@arizona.edu writes: |> >I believe that Novell's IPX similarly hacks the Ethernet address.... |> |> This has nothing to do with TCP-IP, but i don't want this rumor to |> spread. IPX does not modify the ethernet address. While DECnet IV wants to change the ethernet number to match the DECnet node and host number, IPX only requires the same ethernet number to be used on all interfaces to a machine. It doesn't care what they are set to. This allows DECnet and IPX to coexist on the same router as long as you get the DECnet running first and then start the IPX. -- Peter Marshall, Manager (Academic Networking) CCS, NSC, U. of Western Ontario, London, Canada N6A 5B7 (519)661-2111x6032 peter.marshall@uwo.ca pm@uwovax (BITNET); peter@ria.uucp
-----------[000250][next][prev][last][first]---------------------------------------------------- Date: Fri, 19 Oct 90 18:03:51 -0400 From: George Williams <gwilliam@SH.CS.NET> To: Erik Scheelke <apple.com!erekose@apple.com> Cc: tcp-ip@nic.ddn.mil, gwilliam@SH.CS.NET Subject: Re: Reliable Datagram Protocols
All semantics aside there was a working group that had outlined a draft RFC xxxx for doing " OSI Connectionless XPORT Services on top of UDP ".....heresy I know (smile). It was in memo format and comments email addr was listed as 'chi@osf.org'. That is as close as you may come to a non proprietary implementation of what you are looking for. I don't even know if the group still exists, but the draft had some interesting possibilities for certain applications and services over an IP backbone. Good Luck George Williams
-----------[000251][next][prev][last][first]---------------------------------------------------- Date: 19 Oct 90 12:06:34 GMT From: bbn.com!craig@apple.com (Craig Partridge) To: tcp-ip@nic.ddn.mil Subject: Re: question about SMTP MX records
In article <1990Oct18.164200.5699@ecst.csuchico.edu> robin@csuchico.edu (Robin Goldstone) writes:
>... As a workaround, I thought I would just
>send to someone%applelink.apple.com@apple.com. It is my (limited)
>understanding that addresses are parsed from right to left, so this
>message would be sent to apple.com, who would then be able to forward
>it to applelink.apple.com.
>1) is the syntax of the address I am trying to use valid?
Yes the syntax is correct.
>2) am I violating any network rules by routing my message through
>another host?
No, though doing this sort of thing frequently (like sending all
your mail via another system because your system doesn't support MX)
is considered rude.
>3) should this message be getting delivered?
Yes. Apple.com is the MX for applelink.apple.com, so it should
accept mail for applelink.apple.com. Note that if Apple.com was
not the MX for applelink.apple.com, then all bets are off. You
should not assume that via j random host using the %-hack is
safe or reasonable.
You mention your mail is going into a black hole, that's definitely
a problem. Mail should not vanish without a trace...
Craig
-----------[000252][next][prev][last][first]---------------------------------------------------- Date: 19 Oct 90 16:05:43 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu (Kent England) To: tcp-ip@nic.ddn.mil Subject: Re: SNMP monitors
In article <9010181639.AA14322@po.cis.brown.edu> Steven_Carmody@BROWN.EDU writes: >... I'd like to get a sense of what's out there. So far, I >can see three groups of products: 1) the PC-based monitors (wollongong, the >recently announced novell one, etc), 2) the NyserNet/PSI monitor, and 3) a >large number of commercially available, UNIX based monitors (often from >router vendors)... > >The question is -- are there any generalizations which can be made about >each of the categories? I can generalize. :-) 1) I don't like PC based packages because I need workstation power and multitasking. You will need multitasking and virtual memory to do good fault management and data gathering. Of course, you could use a pile of PCs. And I do understand the need for a low end PC package for smallish PC networks. So I would say they are OK for small nets with unsophisticated tool requirements, but not suitable for largish nets. The Proteon Overview PC tool is pretty good, even in its earliest release, with which I am most familiar. 2) The NYSERnet stuff is still pretty good in comparison to other software, and that is disappointing. It indicates that the development of tools has stalled or gotten sidetracked. Some points of interest: 3) Fancy graphics. Migrating from an early X window environment to Motif doesn't buy the network manager a lot. This has distracted developers excessively. But Motif is very pretty; witness the Cabletron displays. Nice pastels, shadows, pictures, etc. Value? To be determined. The people running the InterOp show network used ping and traceroute a lot, but then they may be old fashioned. :-) Databases. A database is an important feature of an advanced network management fault monitor and data gatherer. Early implementations fall short in the ease of use category. We need some database interfaces that match the window environment more closely. Configuration. It is very difficult to adopt or change a tool in a large network if the tool does not help the network manager configure the tool. This is one area where the NYSERnet tool is just awful, requiring the same data to be entered multiple times consistently in the snmpxmon.cf file. Dynamic configuration of commercial products is on the drawing board in the tools I have examined closely, but is not available in a production release. Data gathering and interpretation. This area has been entirely neglected in the tools I have seen. Data gathering and analysis should be database driven. Report generators should be supplied and should be customizable. The database must be accessible outside the network management tool. The database must be custom extensible to deal with such local issues as inventory and cost accounting. There should be utilities for automagic aging and compression of performance data timelines, reducing the demand for disk space growth and easing back-up and archiving. No one is addressing these issues, in the tools I have examined. NYSERnet is still as good as any of the other tools, which is disappointing. One reason I think that progress is disappointing is that the network management market is limited. Developers are getting enamored of the "Distributed Computing Environment Management". I have heard more than one developer talk about stuffing every conceivable variable and extension into the MIB for managing PCs, workstations, and servers and this is a distraction away from the purely Network Management needs of largish networks. However, I understand that tools for DCE management are useful. Sun's tool is interesting. If it saves sysadmin time, it's a good thing. DCE management tools have a wider market than purely NM tools. But DCE management is more embryonic than NM, so I would rather see some vendors concentrate on solving NM problems before turning to DCEM. They could learn from us. One bright note: Cabletron's Network Virtual Machine and object oriented development environment are powerful architectural elements of next generation tools. The NVM can scale well, and holds out some hope of unified Internet management (if such could happen politically and organizationally and could be standardized for interoperability). The OOP model in the Cabletron Spectrum tool is an apparently powerful technique for allowing user customization and for MIB and device tracking. I think object oriented techniques will prove very useful in managing development of sophisticated NM tools, but that is just my embryonic gut feel; it has yet to be demonstrated. --Kent
-----------[000253][next][prev][last][first]---------------------------------------------------- Date: 19 Oct 90 17:52:33 GMT From: agate!shelby!msi.umn.edu!cs.umn.edu!ux.acs!aaron@ucbvax.Berkeley.EDU (Aaron Y.T. Cheung) To: tcp-ip@nic.ddn.mil Subject: Which is the correct/standard way to set up a mail forwarder w/ MX ?
Question being:
I want to set up host abc.edu as MX forwarder for domain xyz.org,
whereas host def.edu (which takes to abc.edu via smtp) takes care
of all xyz.org mails,
could someone point me to the standard way to have it set up, with
sendmail.cf (or elsewhere)? Eg., how does major MX gateways running
SMTP do that, TECHNICALLY?
In short and again, host abc.edu will receive all mails for xyz.org
and forward it to def.edu for final delivery.
NOTE: root@xyz.org should NOT be forwarded to root@abc.edu (ie,
xyz.org is not to be set up as an alias of abc.edu.)
You can assumption:
1. the MX record for xyz.org is already in the DNS system & readily resolvable.
2. abc.edu and def.edu can talk to each other via smtp
Thanks in advance, /aaron.
-----------[000254][next][prev][last][first]---------------------------------------------------- Date: 19 Oct 90 18:40:40 GMT From: tmallory@BBN.COM To: comp.protocols.tcp-ip Subject: Re: Reliable Datagram Protocol
I've didn't save the original message because I felt sure someone would
chip in the following:
from rfc-index.txt.1174:
1151 Partridge, C.; Hinden, R.M. Version 2 of the Reliable Data Protocol
(RDP). 1990 April; 4 p. (Format: TXT=8293 bytes) (Updates RFC 908)
This is really an addendum to RFC 908, which must also be retrieved.
[the first name for this protocol WAS Reliable Datagram Protocol]
Not that you will find this widely implemented, but it surely ought to be
mentioned given the original request.
Tracy
-----------[000255][next][prev][last][first]---------------------------------------------------- Date: 19 Oct 90 20:36:12 GMT From: rogue.llnl.gov!oberman@lll-winken.llnl.gov To: tcp-ip@nic.ddn.mil Subject: Re: question about SMTP MX records
In article <1990Oct18.164200.5699@ecst.csuchico.edu>, robin@csuchico.edu (Robin Goldstone) writes: > I am trying to send a message to someone@applelink.apple.com. This > host has no TYPE A record, only an MX record. My mailer currently > cannot resolve MX records. As a workaround, I thought I would just > send to someone%applelink.apple.com@apple.com. It is my (limited) > understanding that addresses are parsed from right to left, so this > message would be sent to apple.com, who would then be able to forward > it to applelink.apple.com. > > Some questions: > 1) is the syntax of the address I am trying to use valid? > 2) am I violating any network rules by routing my message through > another host? > 3) should this message be getting delivered? > I have sent several test messages that have disappeared into a black hole... The use of the '%' hack is not a part of any standard. But it usually works. So the syntax of the address is probably OK. APPLE.COM is the mail exchanger for APPLE and APPLELINK, so it SHOULD work, but only by convention. It does not violate any "rules", such as they aren't. But this type of routing is quite undesireable--but very common. Mail to APPLELINK is staged on APPLE.COM for delivery, so maybe the route between APPLELINK and APPLE is down. You should really try to get a mailer that handles MX records some day. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.
-----------[000256][next][prev][last][first]---------------------------------------------------- Date: 19 Oct 90 22:03:51 GMT From: gwilliam@SH.CS.NET (George Williams) To: comp.protocols.tcp-ip Subject: Re: Reliable Datagram Protocols
All semantics aside there was a working group that had outlined a draft RFC xxxx for doing " OSI Connectionless XPORT Services on top of UDP ".....heresy I know (smile). It was in memo format and comments email addr was listed as 'chi@osf.org'. That is as close as you may come to a non proprietary implementation of what you are looking for. I don't even know if the group still exists, but the draft had some interesting possibilities for certain applications and services over an IP backbone. Good Luck George Williams
-----------[000257][next][prev][last][first]---------------------------------------------------- Date: 19 Oct 90 22:31:46 GMT From: swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!lth.se!newsuser@ucsd.edu (Jan Engvald) To: tcp-ip@nic.ddn.mil Subject: Re: Ethernet Address Uniqueness...
>While DECnet IV wants to change the ethernet number to match the DECnet node
>and host number, IPX only requires the same ethernet number to be used on all
>interfaces to a machine. It doesn't care what they are set to. This allows
>DECnet and IPX to coexist on the same router as long as you get the DECnet
>running first and then start the IPX.
No, NO. *NOVELL* IPX routers/servers don't change the Ethernet address
of any interface card (*).
We have several servers with two Ethernet cards. One card uses type
8137 protocoll and the other Novells ISO-like protocoll. Both are
connected to the *SAME* Ethernet segment, and if they used the same
Ethernet address it would mean disaster.
Looking with an Ethernet monitor you can see that at the link layer
each card uses its own address that it was born with. However, at the
network layer Novell IPX uses 32 bits of network id + 48 bits node id,
and the node id is the Ethernet address of the first (LAN A) card.
(*) The Cisco router, for some reason I don't understand, say they
do change the adress of its interfaces when Novell IPX routing
is turned on.
Jan Engvald, Lund University Computing Center
________________________________________________________________________
Address: Box 783 E-mail: xjeldc@ldc.lu.se
S-220 07 LUND Earn/Bitnet: xjeldc@seldc52
SWEDEN (Span/Hepnet: Sweden::Gemini::xjeldc)
Office: Soelvegatan 18 VAXPSI: psi%2403732202020::xjeldc
Telephone: +46 46 107458 (X.400: C=se; A=TeDe; P=Sunet; O=lu;
Telefax: +46 46 138225 OU=ldc; S=Engvald; G=Jan)
Telex: 33533 LUNIVER S
-----------[000258][next][prev][last][first]---------------------------------------------------- Date: Sat, 20 Oct 90 14:31:12 -0400 From: ah335@cleveland.Freenet.Edu (Richard Banks) To: tcp-ip@nic.ddn.mil Subject: Test; Please ignore.
This is a test, I don't think i'm receiveing the lsit !
-----------[000259][next][prev][last][first]---------------------------------------------------- Date: Fri, 19 Oct 90 20:15 H From: <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU> To: tcp-ip@nic.ddn.mil Subject: Why Sun adopted UDP-based RPC to implement NFS, but not TCP-based RPC?
Hi, netlander! The title says it all. What is your opinions of why Sun adopted UDP-based RPC to implement NFS, not TCP-based RPC? Since in NFS, the client and server normally would like to maintain the relationship for quite a long time, using TCP-based RPC is supposed to be more economical/efficient (am I rite?). Moreover, by using TCP-based RPC, there is no need to implement a end-to-end mechanism for relaibility, since TPC has the necessary realibility built in. Any ideas/opinions. Thanks - beng hang (email: taybengh@nusdiscs)
-----------[000260][next][prev][last][first]---------------------------------------------------- Date: Sat, 20 Oct 90 16:25:30 EDT From: Michael A. Patton <MAP@lcs.mit.edu> To: wuarchive!emory!hubcap!mmccann@EDDIE.MIT.EDU Cc: tcp-ip@nic.ddn.mil Subject: Need phone numbers...
Date: 16 Oct 90 20:54:54 GMT From: wuarchive!emory!hubcap!mmccann@eddie.mit.edu (Mike McCann) ... networking companies (such as Proteon or Sysco)? Proteon and Sysco are both Boston area companies and while Proteon does do networking, Sysco is a food service company. (You probably meant cisco, it's pronounced the same :-).
-----------[000261][next][prev][last][first]---------------------------------------------------- Date: 20 Oct 90 17:42:59 GMT From: mcsun!unido!wrkof!dksoft!dirk@uunet.uu.net (Dirk Koeppen) To: tcp-ip@nic.ddn.mil Subject: How to configure the network files in the right way ?
When I look at other TCP/IP boxes I mostly find strange configured networks. Some loopback networks do not use the 127.0.0.1 address and so on. Therefore I would like to put the following statements into discussion. I am very interested if the way I configured my network is the right way to do. The machine I configure is called dksoft (192.1.1.99) the network is called incom (my full address is dksoft@incom.de). First the /etc/hosts file: 127.0.0.1 loopback loop 192.1.1.99 dksoft dksoft.incom.de localhost local 192.1.1.100 nix nix.incom.de Note that I put the localhost entry behind the name of the local host. Most hosts have the localhost entry behind the kernel loopback entry. Also an entry loopback names the kernel loopback address. Some systems I have seen (especially SCO-UNIX) return a NULL-pointer on the gethostbyname() call if the domain address is not set in the same line where the hostname appears. Therefore I also addred the *.incom.de entry. The /etc/networks file then looks like: loopback 127 loopback-net software-loopback-net incom 192.1.1 local-net Another important point is how to load the network devices. The Ethernet device I use is wd0, the kernel-loopback is lo0. I found that most standard installations load the lo0 device with localhost. This would set the Internet-address to the lo0 device. I therefore changed my /etc/netd.cf file to the following: ifconfig "wd0" dksoft up ifconfig "lo0" loopback up If I now use netstat -i everything seem all right: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Collis wd0 1500 incom dksoft.incom 2790 0 9522 2 0 lo0 2048 loopback loopback 14418 0 14418 0 0 or netstat -in: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Collis wd0 1500 192.1.1 192.1.1.99 2790 0 9522 2 0 lo0 2048 127 127.0.0.1 14422 0 14422 0 0 Waiting for comments... Dirk -- .............. ............. ........... .......... ........ Dirk Koeppen - Holzwiesenweg 22 - D-6050 Offenbach - Germany ....... ..... Phone: +49 69 89 3000 - FAX: +49 69 89 3004 - uucp: dirk@incom.de .....
-----------[000262][next][prev][last][first]---------------------------------------------------- Date: 20 Oct 90 21:25:48 GMT From: unmvax!pprg.unm.edu!topgun!mustang!nntp-server.caltech.edu!ggumby!tim@ucbvax.Berkeley.EDU (Timothy L. Kay) To: tcp-ip@nic.ddn.mil Subject: Re: question about SMTP MX records
oberman@rogue.llnl.gov writes: >You should really try to get a mailer that handles MX records some day. Fine, but how do we get Silicon Graphics to provide a mailer that supports MX records? Is there a way of putting pressure on them, such as being able to claim that their machines violate internet standards or somesuch? Tim
-----------[000263][next][prev][last][first]---------------------------------------------------- Date: Sun, 21 Oct 90 06:22:58 EDT From: Vint Cerf <vcerf@NRI.Reston.VA.US> To: Craig Partridge <craig@nnsc.nsf.net>, tcp-ip@nic.ddn.mil, ietf@isi.edu Cc: lduncan@NRI.Reston.VA.US Subject: Re: SIGCOMM '90 materials
Regarding Tutorial Notes from SIGCOMM 90, please be aware that we have ONLY the tutorial notes from Rudin/Van Jacobson (tutorial number 1). We don't have any from the other tutorial. The cost for the R/VJ tutorial notes is $30 which includes shipping and handling for North American destinations. Air shipment to places farther away will vary. Vint Cerf CNRI
-----------[000264][next][prev][last][first]---------------------------------------------------- Date: 21 Oct 90 05:19:18 GMT From: bbs!karl@uunet.uu.net (Karl Denninger) To: tcp-ip@nic.ddn.mil Subject: 3c523 packet drivers -- what's the trick?
HELP! We're trying to get a few PS/2s running with the packet drivers, and are having no luck at all. All we get is a "Timed out initializing board" message...... and no function! If anyone out there has this working, PLEASE let me know immediately. Email appreciated with hints, tricks, traps, and new code if we need something other than what we have. The drivers we have are dated mid-august of this year. We really need this working Monday AM! Thanks MUCH in advance! -- Karl Denninger AC Nielsen kdenning@ksun.naitc.com (708) 317-3285 Disclaimer: Contents represent opinions of the author; I do not speak for AC Nielsen on Usenet.
-----------[000265][next][prev][last][first]---------------------------------------------------- Date: 21 Oct 90 08:11:55 GMT From: zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!rsiatl!jgd@tut.cis.ohio-state.edu (John G. DeArmond) To: tcp-ip@nic.ddn.mil Subject: Re: 3c523 packet drivers -- what's the trick?
karl@naitc.naitc.com (Karl Denninger) writes:
>HELP!
>We're trying to get a few PS/2s running with the packet drivers, and are
>having no luck at all. All we get is a "Timed out initializing board"
>message...... and no function!
I had the same problem last year. I stumbled onto a work-around that
you probably won't like. :-) I found that if an old beta version of
the driver was loaded, the machine warm booted and then the new version
loaded, everything worked OK. Great, eh?
One must assume that some memory location is getting twiddled by one
or the other but I never had time to run this one down. If you find
out what it takes to make the new ones work, I'd appreciate hearing.
Since terminal emulation is about all a PS/2 is good for, I expect
to run into a couple more someday.
John
--
John De Armond, WD4OQC | "The truly ignorant in our society are those people
Radiation Systems, Inc. | who would throw away the parts of the Constitution
Atlanta, Ga | they find inconvenient." -me Defend the 2nd
{emory,uunet}!rsiatl!jgd| with the same fervor as you do the 1st.
-----------[000266][next][prev][last][first]---------------------------------------------------- Date: 21 Oct 90 14:15:47 GMT From: bbn.com!craig@apple.com (Craig Partridge) To: tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram Protocol
In article <9010201341.AA18699@ucbvax.Berkeley.EDU> tmallory@BBN.COM writes: >from rfc-index.txt.1174: >1151 Partridge, C.; Hinden, R.M. Version 2 of the Reliable Data Protocol > (RDP). 1990 April; 4 p. (Format: TXT=8293 bytes) (Updates RFC 908) > >[the first name for this protocol WAS Reliable Datagram Protocol] A quick comment on RDP -- there's considerable misunderstanding about what RDP is and is not. When people ask for a reliable datagram protocol (and before Jon Postel jumps on me, yes Jon, I know it is an oxymoron) what they typically mean is a transaction protocol -- a protocol that allows them to exchange data units reliably with multiple remote systems. A sort of reliable version of UDP. RDP should be viewed as a record-oriented TCP. I.e. RDP uses connections, and transmits a reliable stream of delimited data. It is not a transaction protocol. Craig
-----------[000267][next][prev][last][first]---------------------------------------------------- Date: Mon, 22 Oct 90 09:18:35 -0500 From: jbvb@ftp.com (James B. Van Bokkelen) To: encore!zelig!jdarcy@husc6.harvard.edu (Floating Exception) Cc: tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols
apple.com!erekose@apple.com (Erik Scheelke):
> Does anyone know of a reliable connectionless datagram protocol that
> runs on top of UDP? Is so, is there a library out there I can get?
postel@VENERA.ISI.EDU writes:
>Hi.
>
>"Reliable Datagram" is an oxymoron.
Very funny. Really. I would guess, however, that Erik is referring to a
connectionless protocol that preserves message boundaries and guarantees
delivery but not necessarily sequencing or non-duplication. I'm sure such
beasts exist somewhere.
What Jon said was the very, very condensed summary of an issue that he has
no doubt seen hashed over far too many times. Even though I've been over
it twice as many times on the phone to customers as I've seen it discussed
here, I'll try my hand at laying it out in long form.
"Datagrams" are defined as single messages. Sometimes you send one and you
don't expect an answer. Sometimes you kind of hope for a reply, but the
transaction you are attempting isn't worth the overhead of setting up a
connection; if you don't get an answer, the request may have been lost, the
server may be down, or the reply may have been lost. You don't care, there
are many servers, and your timeout handler has just sent a duplicate query
to another of them...
"Connectionless" means that there is no state at either the source or the
destination of the message. Thus, a connectionless protocol cannot
guarantee delivery. If the sender keeps enough state and includes enough
information in each message to guarantee delivery (e.g. some sort of
unique ID, and a timeout if the guaranteed response doesn't arrive), you
only need to add a little state to the receiver to allow sequencing and
non-duplication. If the application must keep track because the
transport doesn't, it still looks like a connection to me...
So, every time this came up in the past, the next stage was to ask the
person looking for a "reliable connectionless protocol" or somesuch what
was really needed. The most frequent goal has been some sort of transport
for a little machine, or a new one for which there is no networking
software yet. The searcher doesn't want to implement all of TCP, and sees
"datagrams" as being easier, particularly on a single Ethernet. Another
common goal has been to get very high throughput by avoiding the "excessive
overhead" of TCP, but Van Jacobsen's research has more or less laid that
one to rest. A third one has been "preservation of message boundaries".
There are a number of 'reliable' alternatives to TCP, including NETBLT
(optimized for block transfers over lossy links), ISO TP, RDP and others.
Those I'm familiar with offer built-in functionality for preserving message
boundaries, along with varying approaches to connection establishment and
acknowlegement. However, it does not appear that they provide enough extra
functionality, or require enough less effort to develop that they (except
for ISO TP) will ever become very widespread.
Frequently, having been made aware of the alternatives, the searcher reads
the specs and decides that he won't save anything. Sometimes the next stage
is a complaint about excessive complexity containing the assertion "I never
see *any* packet loss between my Frobozz boxes on my FooNeT". Whereupon
a large number of people jump down the complainer's throat, mostly network
maintainers suffering the slings and arrows of trying to make protocols
designed for 'little' nets run on 'big, bad' nets...
In summary, if you need reliability in an "internet" protocol, those "in
tune with the Tao of the Internet" assert that you need a connection, flow
control and an end-to-end data integrity check. If all of your
transactions are guaranteed to fit in one packet, you can replace the
connection state with server idempotency. If not, message boundaries are
best not tied to packet boundaries, lest you fall afoul of differing
MTUs and fragmentation (see RFC 1001/1002 Netbios over TCP for an example
of a header/length-based scheme). If you leave the integrity check out,
that's your and your customers' risk, but leaving the flow control out
could get hosts ostracized by offended backbone router operators...
"Those who do not understand TCP are doomed to re-invent it..."
(??? who said that ???)
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000268][next][prev][last][first]---------------------------------------------------- Date: 22 Oct 90 04:15:42 GMT From: swrinde!zaphod.mps.ohio-state.edu!rpi!clarkson!news.clarkson.edu!nelson@ucsd.edu (Russ Nelson) To: tcp-ip@nic.ddn.mil Subject: Re: 3c523 packet drivers -- what's the trick?
In article <1990Oct21.051918.5813@naitc.naitc.com> karl@naitc.naitc.com (Karl Denninger) writes: We're trying to get a few PS/2s running with the packet drivers, and are having no luck at all. All we get is a "Timed out initializing board" message...... and no function! The trick is to fetch sun.soe.clarkson.edu:pub/packet-drivers/3c523.com (in binary mode, of course). I just got it working in the past week. -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667 It's better to get mugged than to live a life of fear -- Freeman Dyson
-----------[000269][next][prev][last][first]---------------------------------------------------- Date: Mon, 22 Oct 90 12:17:56 PDT From: postel@venera.isi.edu To: shlump.nac.dec.com!shug.enet.dec.com!ciarfella@decuac.dec.com, tcp-ip@nic.ddn.mil Subject: Re: Does ICMP optional data include IP header + options?
Paul Ciarfella: Yes. --jon.
-----------[000270][next][prev][last][first]---------------------------------------------------- Date: Mon, 22 Oct 90 10:37:42 EDT From: Bob Stewart <rlstewart@eng.xyplex.com> To: tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols
> > postel@VENERA.ISI.EDU sez: > > > > "Reliable Datagram" is an oxymoron. > > > > --jon. > > Chris Johnson responded: > > Perhaps reliable datagram using UDP is an oxymoron, depending on the > transport layer. > > However XTP datagrams *are* reliable. Mail to xtp-request@pei.com > for information or a XTP spec. If they're "datagrams", then they're not reliable. That's part of the definition. What you might call a "reliable datagram" could also be called a "single-exchange virtual circuit" (yuk). I haven't really thought about the techniques, but I'd expect to see a protocol that looks sort of like a connection setup with data and an implied disconnect. "Reliable datagram" is sort of like "reliable mail", wishing can't make it so. It's really reliable only when the destination application (!) says it got it. Bob
-----------[000271][next][prev][last][first]---------------------------------------------------- Date: Mon, 22 Oct 90 18:40:31 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) To: BILLW@mathom.cisco.com, jbvb@ftp.com Cc: encore!zelig!jdarcy@husc6.harvard.edu, tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols
I may have missed the point but doesn't a PUSH accomplish the same thing? In which case no modification is required. Merton
-----------[000272][next][prev][last][first]---------------------------------------------------- Date: Mon, 22 Oct 90 12:28:35 EDT From: key@cs.utk.edu To: tcp-ip@nic.ddn.mil Cc: key@cs.utk.edu Subject: Looking for PPP for Ultrix (4.0)
Has anyone (DEC?) done PPP for Ultrix 4.0 (RISC) yet? I've seen the BSD 4.3 and SunOS4.0.1/386i distributions. Is there a PPP implementor's mail-list/archive? Thanks in Advance, Ken Key (key@utkux1.utk.edu)
-----------[000273][next][prev][last][first]---------------------------------------------------- Date: Mon 22 Oct 90 15:35:14-PDT From: William "Chops" Westfield <BILLW@mathom.cisco.com> To: jbvb@ftp.com Cc: encore!zelig!jdarcy@husc6.harvard.edu, tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols
I occasionally wonder whether we should just take TCP, add a comment that says "you WILL preserve packet boundries", change the IP protocol type, and say "poof, here is a reliable datagram protocol". BillW -------
-----------[000274][next][prev][last][first]---------------------------------------------------- Date: 22 Oct 90 10:52:09 GMT From: mcsun!inria!ircam!mf@uunet.uu.net (Michel Fingerhut) To: tcp-ip@nic.ddn.mil Subject: named going into an infinite loop ...
Machine: DECsystem 5820 (RISC) OS: Ultrix 4.0 (Rev. 179) Every once in a while (every 3-4 days), the name daemon starts eating CPU time, goes to the top of the queue, and fills the syslog error message table with messages of the form Oct 22 10:23:37 localhost: 93 named: accept: Too many open files (one a second, approximately) until it is killed and/or chokes /usr/spool. Upon restart, it works fine. There is no apparent flood of requests prior to that. Does anyone have a suggestion on how to approach the problem? Thanks, Michael Fingerhut
-----------[000275][next][prev][last][first]---------------------------------------------------- Date: Mon, 22 Oct 90 09:41:31 +0100 From: Andr'e PIRARD <PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU> To: TCP-IP@NIC.DDN.MIL Subject: Re: 3c523 packet drivers -- what's the trick?
On Sun, 21 Oct 90 08:11:55 GMT <tcp-ip-relay@NIC.DDN.MIL> said: >karl@naitc.naitc.com (Karl Denninger) writes: >>We're trying to get a few PS/2s running with the packet drivers, and are >>having no luck at all. All we get is a "Timed out initializing board" >>message...... and no function! > >I had the same problem last year. I stumbled onto a work-around that >you probably won't like. :-) I found that if an old beta version of >the driver was loaded, the machine warm booted and then the new version >loaded, everything worked OK. Great, eh? Indeed 3c523_5 looks to have been included in release 7 for that purpose. But one doesn't need to warm boot. TERMIN will do the trick. >One must assume that some memory location is getting twiddled by one >or the other but I never had time to run this one down. If you find >out what it takes to make the new ones work, I'd appreciate hearing. >Since terminal emulation is about all a PS/2 is good for, I expect >to run into a couple more someday. I have traced the problem some day to occur during board RAM tests. I have suggested that the cause is that the CPU can't accessed that RAM until the chip is initialized, what's apparently done after RAM test. Unfortunately, I haven't got a 523 any more. Will someone who has one give Russ a help? Andr'e PIRARD SEGI, Univ. de Li`ege B26 - Sart Tilman B-4000 Li`ege 1 (Belgium) pirard@vm1.ulg.ac.be or PIRARD@BLIULG11 on EARN/BITNET
-----------[000276][next][prev][last][first]---------------------------------------------------- Date: 22 Oct 90 12:04:20 GMT From: bbn.com!craig@eddie.mit.edu (Craig Partridge) To: tcp-ip@nic.ddn.mil Subject: Re: question about SMTP MX records
In article <tim.656457948@ggumby> tim@ggumby.cs.caltech.edu (Timothy L. Kay) writes:
>Fine, but how do we get Silicon Graphics to provide a mailer that supports
>MX records? Is there a way of putting pressure on them, such as being able
>to claim that their machines violate internet standards or somesuch?
Any host which does not support MX RR's in the mailer is not
Host Requirements conformant. See page 65 of RFC 1123.
-----------[000277][next][prev][last][first]---------------------------------------------------- Date: Mon 22 Oct 90 23:37:02-PDT From: William "Chops" Westfield <BILLW@mathom.cisco.com> To: mcc@WLV.IMSD.CONTEL.COM Cc: jbvb@ftp.com, encore!zelig!jdarcy@husc6.harvard.edu, tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols
I may have missed the point but doesn't a PUSH accomplish the same thing?
[make TCP a datagram-oriented protocol]
Well, no. A major part that is missing is a specification for the
interface between TCP and the next layer up (in ISO, this would likely
be a whole separtate document.) In particular, if a receiver gets
two packets with PUSH set, the interface may put both packets in a
single buffer. To quote RFC793:
The exact push point might not be visible to the receiving user and
the push function does not supply a record boundary marker.
Also, on the sender side, push does not preclude use of algorithms such
as slow start, Nagle, or re-packetization on retransmit. (Hopefully,
a system using a datagram oriented protocol does not involve situations
where these are important (well, slow start would still be useful - you
just have to do it with datagrams rather than stream data))
Finally, TCP as is will send many datagrams if you present more than a
packet-sizes worth of data. For a datagram oriented system, you would
force it to send a fragmented IP packets instead (and the maximum
segment size would have a slightly different meaning.)
The changes to any particular TCP to achieve a reliable datagram model
would not be significant, but it would take a little work.
BillW
-------
-----------[000278][next][prev][last][first]---------------------------------------------------- Date: 22 Oct 90 17:28:20 GMT From: phri!marob!slhisc!jlister@nyu.edu (John Lister) To: tcp-ip@nic.ddn.mil Subject: Re: Can One API Support Both TCP/IP and LU 6.2?
Interesting thought. The answer seems to be that you could implement something on top of RPC that would have similar functionality to LU6.2 for particular applications. Although IBM has been pushing LU6.2 as a commun- ications panacea, in actuality, most implementations use it for transaction processing, and the orientation is definitely towards Logical Units of Work and the questions of atomicity that Distributed Transaction Processing raise. I have been wondering about starting a project to look at writing an RPC interface for CICS Distributed Transaction Processing for some time but haven't actually done anything about it. Is there anyone out there who has already got their fingers wet? John Lister.
-----------[000279][next][prev][last][first]---------------------------------------------------- Date: 22 Oct 90 20:40:07 GMT From: agate!bionet!synoptics!sblair@ucbvax.Berkeley.EDU (Steven Blair) To: tcp-ip@nic.ddn.mil Subject: *looking for implementations of RFC-1112*
I have several users who've recently become aware of RFC1112 written by S.Deering of Stanford(1989) on Host Extensions on IP Multicasting. We're reviewing the paper for possible interest. Questions are: 1) Has any router/bridge company done this? If not, are any working on it. 2) Are there any networks supporting this at this time? Or in the future? 3) Any more interesting comments you can add to this. IP Multicasting, for those of you who'd like to know, is: [quoting from the RFC] "IP multicasting is the transmission of an IP datagram to a "host group", a set of zero, or more hosts identified by a single IP destination address". The RFC112 goes into many unique details that could make this a very flexible protocol to implement, and we'd like to know more. For those of of us with Internet DNS sites, dealing with potential DNS forgeries, this could indeed offer an additional level of complexity in the future, if many adopt it... Please email: craigj@synoptics.com & sblair@synoptics.com -- Steven C. Blair Network Operations Center SynOptics Communications Inc. Mountain View, California INTERNET: sblair@synoptics.com sblair@excalibur.synoptics.com PROBLEMS/EMAIL: HOSTMASTER@SYNOPTICS.COM postmaster@synoptics.com ***Bring Back The USENET Backbone/ARPA Backbone, NOW***
-----------[000280][next][prev][last][first]---------------------------------------------------- Date: 22 Oct 90 21:19:36 GMT From: dino!atanasoff!jacobson@uunet.uu.net (Doug Jacobson) To: tcp-ip@nic.ddn.mil Subject: subnets
I have two general questions about subnetting in TCP/IP. At Iowa State University we have a class B address and our campus network consists of a four large bridged Ethernet segments with a FDDI backbone used to connect these segments. Some of the segments contain IP Gateways. The campus was using transparent subnetting until about a month aao when the campus changed to unsubnetted. The Broadcast addresses and the Netmasks have been changed. (Broadcast changed from 129.186.X.255 to 129.186.255.255 and the netmask changed from 255.255.0.0 to 255.255.255.0). The questions I are: 1) Should we have changed the campus to not support transparent subnetting even though we do have some true subnets within our domain. 2) How do other organizations with class B addresses set up their networks and do they use transparent subnetting. You can mail your responses to me at doug@isuee1.ee.iastate.edu if there is enough interest I will post the results to question 2.
-----------[000281][next][prev][last][first]---------------------------------------------------- Date: 22 Oct 90 21:34:18 GMT From: cs.utexas.edu!usc!orion.oac.uci.edu!mothra.nts.uci.edu!meggers@CS.YALE.EDU (Mark Eggers) To: tcp-ip@nic.ddn.mil Subject: RPC interface across various platforms
Are there any commercial or public domain packages that will allow the construction of a distributed application running on such diverse platforms as IBM MVS/XA, VAX VMS, Macintoshes, PCs, and various BSD flavors of UNIX? thanks for any information - /mde/
-----------[000282][next][prev][last][first]---------------------------------------------------- Date: 22 Oct 90 22:12:38 GMT From: hplred!haddad@hplabs.hpl.hp.com (R. Peter Haddad) To: tcp-ip@nic.ddn.mil Subject: Re: Need phone numbers...
cisco can be reached at 415 326-1941. They probably have an 800 number, but I haven't a clue what it is. I'm suprised they haven't called you. They generally read this notes group. You can also send mail to cs@clash.cisco.com, this is genrally read by sales/technical people at cisco. Good Luck. Peter Haddad HPLabs Network Engineering (415) 857-5618
-----------[000283][next][prev][last][first]---------------------------------------------------- Date: Tue, 23 Oct 90 10:06:28 -0700 From: jqj@hogg.cc.uoregon.edu To: tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols
I think we are being a bit ingenuous in assuming that the only reason one might want "reliable datagrams" is to implement a sequenced packet protocol, or that the only good way to get reliable packet delivery over IP is by using TCP. The current discussion does not, for example, address reliable broadcast or any of a miriad of other real transaction-oriented applications for reliable packet exchange where the cost of setting up a VC is prohibitive. I would even go so far as to suggest that the lack of a standard RPX protocol in the IP suite has inhibited development of reasonable applications that would use it! As an aside, 4.2bsd included Eric Cooper's courier compiler that implemented a Xerox SPP-like protocol over TCP (message boundaries and message types are needed to implement the semantics of Courier). As I recall, Eric just used a simple counted string approach, where messages could span multiple strings and end was delimited by an EOM bit in the message header, totally ignoring IP packet boundaries, PUSHes, etc. (you have to guarantee a PUSH after the EOM, I suppose). Worked just fine if what you wanted was packet boundaries on TCP; no changes to TCP needed.
-----------[000284][next][prev][last][first]---------------------------------------------------- Date: Tue, 23 Oct 90 10:22:37 -0500 From: jbvb@ftp.com (James B. Van Bokkelen) To: William "Chops" Westfield <BILLW@mathom.cisco.com> Cc: tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols
....
Finally, TCP as is will send many datagrams if you present more than a
packet-sizes worth of data. For a datagram oriented system, you would
force it to send a fragmented IP packets instead (and the maximum
segment size would have a slightly different meaning.)
Given my druthers, I'd much rather make message boundaries independent
of IP datagrams, because deliberate fragmentation is EEEVIIILLL!!!. Also,
you'll never hear the end of "why are records limited to 65Kb" and "why
can't I use records bigger than 8Kb on my FooNix system"?
If you're willing to re-implement everywhere
If you're willing to settle for 16 bits of record length
Do something really gross with the Urgent pointer and unused bits in the
TCP header.
Else
Define a new TCP Record Option as: opt_type, opt_len followed by
(opt_len - 2)/2 "start of record offsets within this segment".
Else
Define a formal "Record-Oriented TCP Extension" which uses header/length
and let the applications that want it use it. If enough of them do so,
someone will move support into a library, and then someone else will put
it in the kernel. You could even use ISO Session and get ASN.1 data
abstraction in the ?bargain?
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000285][next][prev][last][first]---------------------------------------------------- Date: Tue, 23 Oct 90 08:52:24 -0400 From: Craig Partridge <craig@NNSC.NSF.NET> To: Steven Blair <sblair@synoptics.com> Cc: tcp-ip@nic.ddn.mil Subject: re: Flexible, Host Extensions for IP Multicasting
Steve:
I can answer some of your questions -- Steve Deering or David Waitzman
will presumably chime in to answer the rest.
> 1) Has any router/bridge company done this? If not, are any
> working on it.
BBN and Stanford did experiments using Butterfly gateways about two
years ago. We also did experiments with the publicly available multicast
code for BSD from Stanford. (I don't know where the current multicast
code is on-line, however, it will appear in 4.4BSD).
The experiments involved trying to do multicast routing over large
areas. The answer is, you can do it, and SPF looks like the better base
on which to build.
Craig
-----------[000286][next][prev][last][first]---------------------------------------------------- Date: Tue, 23 Oct 90 10:28:14 PDT From: braden@venera.isi.edu To: BILLW@mathom.cisco.com, jbvb@ftp.com Cc: tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols
If you need records, you can build a trivial framing protocol on top of TCP. There have been many examples of this... Mike Muuss' PKG, records in Sun's XDR, and Dave Clark's USP come immediately to mind. Bob Braden
-----------[000287][next][prev][last][first]---------------------------------------------------- Date: 23 Oct 90 03:31:32 GMT From: usc!samsung!munnari.oz.au!mel.dit.csiro.au!yarra!melba.bby.oz.au!gnb@ucsd.edu (Gregory N. Bond) To: tcp-ip@nic.ddn.mil Subject: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols)
Well, on a similar note....
I understand James' and Jon's arguments. Reliable datagrams are best
implemented with TCP and a "write(len); write(data);" layer. I am
looking for something a little different.
Consider a net with a server and many (say, 100) workstations, and a
data feed that goes to each workstation. At the moment, I have to
open 100 TCP streams, and so each packet of data generates 200 TCP
packets, all more-or-less identical. What would be nice would be to
broadcast the packet to the local net, and have the clients request
missed packets, thus implementing a sort of reliable broadcast.
I would be happy for some sort of overhead for the reliability (e.g.
server broadcasts empty packets with the highest serial number once
every 10 seconds), but before I re-invent wheels, has someone done
something like this?
Greg.
--
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnb
-----------[000288][next][prev][last][first]---------------------------------------------------- Date: Tue, 23 Oct 90 13:42:55 -0500 From: nancy@ftp.com (Nancy L. Connor) To: fun@ftp.com Cc: tcp-ip@nic.ddn.mil Subject: French experience needed
Does anyone know what the following phrase translates to? ..but as they say in French ca me fait une belle jambe. Thanks for any help. -Nancy
-----------[000289][next][prev][last][first]---------------------------------------------------- Date: Tue, 23 Oct 90 13:02 PDT From: Michael Stein <CSYSMAS@OAC.UCLA.EDU> To: tcp-ip@NIC.DDN.MIL Subject: Re: Reliable Datagram ??? Protocols
> Given my druthers, I'd much rather make message boundaries > independent of IP datagrams, because deliberate fragmentation > is EEEVIIILLL!!!. Also, you'll never hear the end of "why are > records limited to 65Kb" and "why can't I use records bigger > than 8Kb on my FooNix system"? 1000% correct. > If you're willing to re-implement everywhere > If you're willing to settle for 16 bits of record length > Do something really gross with the Urgent pointer and unused bits in the > TCP header. > Else > Define a new TCP Record Option as: opt_type, opt_len followed by > (opt_len - 2)/2 "start of record offsets within this segment". > Else > Define a formal "Record-Oriented TCP Extension" which uses header/length > and let the applications that want it use it. If enough of them do so, > someone will move support into a library, and then someone else will put > it in the kernel. You could even use ISO Session and get ASN.1 data > abstraction in the ?bargain? And what do you do if you *need* to be able to abort a "packet" send before it all makes it through? Say I send a 16M "packet" and change my mind in the middle (but don't want to close the connection...). For this you need some "out of band" alert and flush capability -- TCP urgent data won't do it. (Besides that's 16M of binary data, I'd rather avoid scanning it for escape sequences...)
-----------[000290][next][prev][last][first]---------------------------------------------------- Date: Tue, 23 Oct 90 13:13:02 -0400 From: jcurran@SH.CS.NET To: Merton Campbell Crockett <mcc@wlv.imsd.contel.com> Cc: BILLW@mathom.cisco.com, jbvb@ftp.com, encore!zelig!jdarcy@husc6.harvard.edu, tcp-ip@nic.ddn.mil, jcurran@SH.CS.NET Subject: Re: Reliable Datagram ??? Protocols
>> I may have missed the point but doesn't a PUSH accomplish the same thing? In >> which case no modification is required. "A PSH bit is not a record marker and is independent of segment boundaries." "Passing a received PSH flag to the application layer is now OPTIONAL." (RFC1122) Work on a TCP extension for record information rather than taking a step back.. /John Policy Routing, 2000: "Through the networks according to their abilities, to the applications according to their need."
-----------[000291][next][prev][last][first]---------------------------------------------------- Date: Tue 23 Oct 90 13:44:18-PDT From: William "Chops" Westfield <BILLW@mathom.cisco.com> To: braden@venera.isi.edu Cc: jbvb@ftp.com, tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols
If you need records, you can build a trivial framing protocol on top
of TCP. There have been many examples of this... Mike Muuss' PKG,
records in Sun's XDR, and Dave Clark's USP come immediately to mind.
Yes, yes. This is not difficult, and is clearly the way to do things
within the framework of the currently defined protocols. In fact, the
cisco routers do exactly this sort of thing for running X.25 over TCP.
Aesthetically, though, it bothers me to have to do the extra work of
converting datagrams to streams and back when the underlying transmission
scheme is almost certainly datagram based. (Hmm, is anyone running TCP
over anything other than IP?)
BillW
-------
-----------[000292][next][prev][last][first]---------------------------------------------------- Date: Tue, 23 Oct 90 15:39:47 -0500 From: bruce@128.127.2.105 To: nancy@ftp.com Cc: tcp-ip@nic.ddn.mil, fun@ftp.com Subject: Re: French experience needed
>Does anyone know what the following phrase translates to? >..but as they say in French ca me fait une belle jambe. >Thanks for any help. > -Nancy I think a literal translation is something like "that I make myself a beautiful leg". I am not sure what the colloquialism means. Bruce
-----------[000293][next][prev][last][first]---------------------------------------------------- Date: Tue, 23 Oct 90 14:15:49 -0400 From: George Williams <gwilliam@SH.CS.NET> To: Merton Campbell Crockett <mcc@wlv.imsd.contel.com> Cc: BILLW@mathom.cisco.com, jbvb@ftp.com, encore!zelig!jdarcy@husc6.harvard.edu, tcp-ip@nic.ddn.mil, gwilliam@SH.CS.NET Subject: Re: Reliable Datagram ??? Protocols
The "push" flag, present on tcp packets has nothing to do with
reliabilty. It just says ' forwards what's in the receiving
application buffer ' up...now !
It has nothing to do with Datagram or Reliabilty but is associated
with fragmentation and re-assembly.
Additionally, most APIs don't make this flag user accessible; as a
good working knowledge of systems and protocol(s) as they pertain
to overall response time and throughput is assumed for those who
massage this flag. It can result in overall system degradation in
a distributed compute environment is set inappropriately..
A final word on UDP...if I may:
() Architecturally, UDP is the connection-less transport for IP.
Reliability as in pertains to delivery and retranmissions is
the assumed burden of associated HLPs (higer level protocols)
or service(s) present. I did not write the protocol but did
enough implementations to state this as fact.
() It is generally the protocol of choice when the transmisssion
media has a low error rate or an HLP (e.g. interactive ) that
compensates for deficiencies.
George Williams
( The above are my own humble views and opinions and are not a
critique )
-----------[000294][next][prev][last][first]---------------------------------------------------- Date: 23 Oct 90 08:23:01 GMT From: eru!hagbard!sunic!lth.se!newsuser@bloom-beacon.mit.edu (Ricard Wolf) To: tcp-ip@nic.ddn.mil Subject: Re: telnet problem
In article <9010230414.AA04281@ucbvax.Berkeley.EDU> KCPENG@TWNCTU01.BITNET writes: >Hi, > >the following telnet problem appears after system has booted up a period >of time: > > % telnet xxx > Trying... > Connected to xxx. > Escape charcter is '^[' > >then system hangs. It seems the remote telnetd has been connected, cuz the >escape sequence is in effect. And likely this problem appears only in Sun >W/Ss. Any hint is highly welcome. > >Kai-Chih Peng >kcpeng@twnctu01 Actually, the above message indicates that the remote TCP has responded to the request, not that telnetd has answered. Of course, the telnetd must tell the TCP to open a port for listening (a "passive" port in TCP terminology), but the telnetd doesn't print the above message. Instead, it is the local telnet that desides that once the remote TCP has responded, the connection is fully opened. The escape character mentioned is actually handled by the local telnet, and doesn't have anything to do with the remote telnetd server. -- Ricard Wolf +--------------------------+-------------------------------------+ | Ricard Wolf | Lund Institute of Technology | | email: e85rw@efd.lth.se | If you can't buy 'em - build 'em !! | +--------------------------+-------------------------------------+
-----------[000295][next][prev][last][first]---------------------------------------------------- Date: Tue, 23 Oct 90 13:34:49 EDT From: Phil Dykstra <phil@BRL.MIL> To: William Chops Westfield <BILLW@mathom.cisco.com> Cc: tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols
> The changes to any particular TCP to achieve a reliable datagram model > would not be significant, but it would take a little work. It is easy to layer a reliable message protocol on top of TCP. We designed one such protocol at BRL call PKG (Package Protocol) and have used it for several distributed applications over the past five years (e.g. in BRL-CAD). Messages have user defined "types" and both synchronous and asynchronous message exchanges are supported. At one time a version of it even ran over DECNET, but our current code is BSD socket library oriented only. We should have written an RFC about it years ago. If anyone is interested they can look at brl-cad/pkg.shar.Z via anonymous FTP on ftp.brl.mil (a.k.a. vgr.brl.mil, 192.5.23.6). - Phil
-----------[000296][next][prev][last][first]---------------------------------------------------- Date: 23 Oct 90 13:59:48 GMT From: bu.edu!rpi!zaphod.mps.ohio-state.edu!usc!bbn.com!craig@bloom-beacon.mit.edu (Craig Partridge) To: tcp-ip@nic.ddn.mil Subject: Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols)
In article <GNB.90Oct23133132@leo.bby.oz.au> gnb@bby.oz.au (Gregory N. Bond) writes: >Well, on a similar note.... > >Consider a net with a server and many (say, 100) workstations, and a >data feed that goes to each workstation. At the moment, I have to >open 100 TCP streams, and so each packet of data generates 200 TCP >packets, all more-or-less identical. What would be nice would be to >broadcast the packet to the local net, and have the clients request >missed packets, thus implementing a sort of reliable broadcast. There's been some muttering over beers that this might be feasible in TCP. If you think about the idea, it isn't so crazy. To make sure the workstations are in sync, you'll need some sort of windowing mechanism. To be sure everyone has data, you'll need an acknowledgment scheme. That's pretty close to the basic service TCP offers. So if you could open a TCP connection to an IP multicast address, and figure out how to handle the remote ends cleanly at the sender, you'd be pretty far along. (And 1 sending workstation gets, at worst, 100 acks from 100 receivers -- less if receivers ack every 2nd segment). I believe Van Jacobson and Jon Crowcroft looked at this problem in more detail and may well have something more to add. Craig
-----------[000297][next][prev][last][first]---------------------------------------------------- Date: 23 Oct 90 14:47:14 GMT From: eru!hagbard!sunic!dkuug!daimi!pe!phl@bloom-beacon.mit.edu (Per H Larsen) To: tcp-ip@nic.ddn.mil Subject: TCP/IP on MS-DOS PC
I'm involved in a project where we want our Unix computer to function as a server to some MS/DOS PC's. I want to write MY OWN applications on the PC that communicates with the Unix server. My plan is to do this in a TCP/IP - Ethernet enviroment so I'm looking for Software that implements TCP/IP on a MS/DOS PC and additionally has an Application Programmers Interface from C. Further I'm looking for a realy good Ethernet controler for the PC's. I have heard of Wollongong WIN/TCP but there must be other products ? Has any one had experience with Wollongong WIN/TCP ? or any other product ? Any product is of interest. Please Email me directly. I'll send a summary to the net if there appers to be any interest. ***************************************************************************! ! +-----------------------------------------------------------------------+ ! ! + Per Hyttel Larsen --- Telephone : +45-86 22 25 22 + ! ! + Purup Electronics /---\ Facsimile : +45-86 22 25 11 + ! ! + Soenderskovvej 5 | . . | Telex : 68242 purel dk + ! ! + DK - 8520 Lystrup \ U / Email : phl@pe.dk + ! ! + Denmark \-/ Uucp : ...!dkuug!pe!phl + ! ! +-----------------------------------------------------------------------+ ! ***************************************************************************
-----------[000298][next][prev][last][first]---------------------------------------------------- Date: 23 Oct 90 15:33:02 GMT From: dsl.pitt.edu!pitt!elvis.cs.pitt.edu!field@pt.cs.cmu.edu (Gus) To: tcp-ip@nic.ddn.mil Subject: UDP/IP over ether weirdness
I've got an application that would like to send the largest UDP packet it can. (sun3 - sun3 running 4.0.3 over 10MB ethernet). The only reference to max UDP packet size is in the RPC section where it says the max size the UDP transport mechanism can handle is 8K bytes. (sendto () does not return EMSGSIZE until I try to send >9000 bytes per datagram). Anyway, when I send 8K byte packets, sendto () doesn't complain, but the packets never arrive at the receiver. In fact, if I attempt to send a datagram larger than 2048 bytes, it never arrives at the receiver. Running etherfind on a third machine, and watching the traffic between the UDP src and dst's I see: ----- 2048 byte packet: 1514 udp pebbles wilma 1788 4343 * 610 udp This datagram is delivered correctly to the destination application. ----- 2049 byte packet: 1066 udp pebbles wilma 1790 4343 * 611 udp Now, something is definitely wrong here. ----- So, what is the limit on UDP size messages (besides the 16 bit length field limit)? Is 2048 bytes per UDP datagram the limit? Thanks Brian ----- field@cs.pitt.edu
-----------[000299][next][prev][last][first]---------------------------------------------------- Date: 23 Oct 90 17:29:07 GMT From: hercules!frisbee.cisco.com!allan@apple.com (Allan Leinwand) To: tcp-ip@nic.ddn.mil Subject: Re: Need phone numbers...
Hello all, If there are multiple copies of this around, sorry to waste the bandwidth. I fought the news reader and I think it won.... The cisco 800 number for customer service is 1-800-553-NETS or 1-800-553-6387. Thanks, Allan Leinwand cisco Systems leinwand@cisco.com
-----------[000300][next][prev][last][first]---------------------------------------------------- Date: Tue, 23 Oct 90 15:56:40 +0100 From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> To: William Chops Westfield <BILLW@mathom.cisco.com> Cc: tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols
the world used to divide into datagram & virtual circuit it now cuts many ways - connection oriented versus connectionless is on dimension, but reliability is another orthogonal issue ... some people would assert that using a 'first' datagram to establish buffer allocation for an entry in a router's tables to decide on who gets packets dropped is connection oriented ... it's just not reliable...on the other hand, asking for the right TOS may insure reliability, even though the packet format is datagram... so i dont agree with jon postel...however, "reliable internet" may be an oxymoron:-) but seriously, 'reliable virtual circuits' is an oxymoron if you've ever tries using (I)PSS...calls get ripped out with disconnection reasons like 'congestion' , which doesnt sound too dissimilar from routers dropping packets (except you have to wait a while longer before sending your next packet - or do you - well prob. not if you are running slow start x.25, now there's an idea:-)) jon crowcroft
-----------[000301][next][prev][last][first]---------------------------------------------------- Date: 23 Oct 90 18:09:16 GMT From: hplred!haddad@hplabs.hpl.hp.com (R. Peter Haddad) To: tcp-ip@nic.ddn.mil Subject: Re: subnets
/ hplred:comp.protocols.tcp-ip / jacobson@cs.iastate.edu (Doug Jacobson) / 2:19 pm Oct 22, 1990 / I have two general questions about subnetting in TCP/IP. At Iowa State University we have a class B address and our campus network consists of a four large bridged Ethernet segments with a FDDI backbone used to connect these segments. Some of the segments contain IP Gateways. The campus was using transparent subnetting until about a month aao when the campus changed to unsubnetted. The Broadcast addresses and the Netmasks have been changed. (Broadcast changed from 129.186.X.255 to 129.186.255.255 and the netmask changed from 255.255.0.0 to 255.255.255.0). The questions I are: 1) Should we have changed the campus to not support transparent subnetting even though we do have some true subnets within our domain. 2) How do other organizations with class B addresses set up their networks and do they use transparent subnetting. You can mail your responses to me at doug@isuee1.ee.iastate.edu if there is enough interest I will post the results to question 2. ---------- Doug : Perhaps I am missing something here. Your broadcast address seems to have changed to accomodate a 0 length subnet field, therefore a 16 bit host field. Your netmask however has been changed to allow an 8 bit subnet field, and therefore an 8 bit host field. Am I misunderstanding the situation ? What do you mean by "transparent" subnetting ? Peter Haddad HPLabs Network Eng.
-----------[000302][next][prev][last][first]---------------------------------------------------- Date: 23 Oct 90 19:22:46 GMT From: mips!ultra!rajiv@apple.com (Rajiv Dhingra) To: tcp-ip@nic.ddn.mil Subject: tcp delayed acks
I have a question regarding acks sent out by SUNs implementation of TCP/IP. If SUNs TCP receives a data packet of 1024 bytes followed by a second data packet of 410 bytes, it sends an ACK packet acknowledging the 1434 bytes immediately. However, if it receives a data packet of 1024 bytes followed by a second data packet of 409 bytes, it delays sending an ACK packet for 200 milli-seconds. The window that it advertises in both cases is 4096 bytes. Under what cases does it decide to delay sending out an ACK packet? Thanx in advance for replies. Rajiv Dhingra Ultra Network Technologies domain: rajiv@Ultra.COM 101 Daggett Drive Internet: ultra!rajiv@Ames.ARC.NASA.GOV San Jose, CA 95134 uucp: ...!ames!ultra!rajiv 408-922-0100
-----------[000303][next][prev][last][first]---------------------------------------------------- Date: 23 Oct 90 21:34:28 GMT From: pcg@cs.aber.ac.uk (Piercarlo Grandi) To: comp.protocols.nfs,sci.skeptic,comp.protocols.tcp-ip Subject: Re: New product announcement: NFSper
On 14 Oct 90 23:11:39 GMT, nelson@sun.soe.clarkson.edu (Russ Nelson) said: nelson> ESP Software would like to announce their newest product, nelson> NFSper. NFSper is a NFS server with an order of magnitude nelson> better performance than any existing NFS server. NFSper uses a nelson> proprietary technique to cache NFS requests on the client before nelson> they are transmitted to the server. Lab tests have shown that nelson> the NFS packet are available on the client an average of 100 nelson> microseconds before the client sends the request. Under test nelson> conditions, we have observed packets a full 250 uSec before the nelson> request transmission! Such blatant advertising! Not to mention that the technology used by ESP may be infringing on the original rights held by Prof. Donald Knuth for anticipative algorithms (the so called 'Pasadena street' style), as described in ACP vol. 1, chapter on coroutines. It is also true that Dr. Isaac Asimov, the distinguished inventor of tiotimoline, the intensional solvent, may have also a valid claim to rights on anticipative technologies. I cannot resist mentioning a major player in this market, which is rumoured be on the verge of adopting 'not responding -- still trying' as corporate trademark (unfortunately for them quick research has revealed that many of its competitors h