|
|
ARCHIVE: TCP-IP Distribution List - Archives (1990)
DOCUMENT: TCP-IP Distribution List for May 1990 (395 messages, 213025 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1990/05.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: 1 May 90 01:26:35 GMT From: xanadu!michael@apple.com (Michael McClary) To: tcp-ip@nic.ddn.mil Subject: Re: anonymous ftp, and the dangers thereof
In article <10309@yunexus.UUCP> davecb@yunexus.UUCP (David Collier-Brown) writes: >How about: > This mechanism will ensure that only files in the directories > "under" the chroot-point are acessable: > > if program is not setuid-root, > program exits forthwith Note that it's not sufficient to limit a chroot to going leafword on a tree but leave it executable by non-root users. A generally-executable chroot lets a user build a directory tree like this: user_home user_root etc passwd then chroot to user_root and exec login.
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 1 May 90 03:35:43 GMT From: stealth.acf.nyu.edu!brnstnd@nyu.edu To: tcp-ip@nic.ddn.mil Subject: Re: seeking info on Acces Control List (ACL) mods to inetd
In article <2006@tuminfo1.lan.informatik.tu-muenchen.dbp.de> k2@charly.bl.physik.tu-muenchen.de (Klaus Steinberger) writes:
> > Has anyone hacked inetd to consult an Access Control List or other
> > security extensions, ...
> >Yes. HP-UX has had this extension for several years. We use the
> >file /usr/adm/inetd.sec. I've appended a sample to this message.
> Is it possible to post the modifications to inetd ?
> Or will it be propietary code?
> I think there is some interest on the net for ACL's on inetd
Well, you could pick up my auth package, which was sent out today on
comp.sources.unix. If you use attachport rather than inetd to handle
connections, you can set these things up without much trouble:
#!/bin/sh
# Untested. Should allow connections from anyone at 128.9.0.32,
# anyone in 192.48.96.*, and authenticated root at 128.122.128.22.
# Should disallow connections from hacker@128.9.0.32 as well as all
# unauthenticated connections from 128.9.0.32.
# We should really test for PROTO=TCP first, since other communications
# mechanisms might not have the same REMOTE format. Instead we'll
# assume (ha!) that we're only invoked from the Internet.
if /usr/ucb/printenv REMOTE | /usr/bin/egrep -s \
'^((.*@128\.9\.0\.32)|(.*@192\.48\.96\.[^\.]*)|(root@128\.122\.128\.22))$'
then if /usr/ucb/printenv REMOTE | /usr/bin/egrep -s \
'^((shmoe@128\.9\.0\.32)|(@128\.9\.0\.32))$'
then exit 1 # perhaps log error somewhere
else exec /etc/whateverd
fi
else exit 2 # perhaps log error somewhere
fi
Notice how you can test for the username as easily as the host.
To better simulate the HP/UX functionality, you'd have to write a
program that would take those ``inetd.sec'' files, parse them, and check
REMOTE accordingly. Anyone like writing text processing programs? ... If
there's enough interest I'll do this and send it out.
---Dan
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 1 May 90 04:21:38 GMT From: stealth.acf.nyu.edu!brnstnd@nyu.edu To: tcp-ip@nic.ddn.mil Subject: Re: Remote Netstat
In article <9004262255.AA14530@chico> mja@chico.simpact.com (Mike Anello) writes: > Does any have a public domain version of a remote netstat program available ? > I know about SNMP but I need something even simpler. Thanks. Pick up auth and authutil from comp.sources.unix. Install auth; follow the client-server examples in authutil. The basic idea is server% attachport -vp 52000 /usr/ucb/netstat -n & client% authtcp server 52000 /bin/sh -c '/bin/cat <&6' You can make arbitrarily complicated clients and servers. The authtcp client receives its connection in fd 6; the attachport server receives each connection in fds 0 and 1. Unless you specify -R to attachport, the server will see the client's user@in.et.num.ber in environment variable REMOTE, and vice versa for specifying -R to authtcp. (If the connection is unauthenticated, user will be blank.) ---Dan
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 1 May 90 11:38:10 GMT From: cucstud!tfd!tons61!harrys@uunet.uu.net (Harry Skelton) To: tcp-ip@nic.ddn.mil Subject: Re: anonymous ftp, and the dangers thereof
In article <10309@yunexus.UUCP> davecb@yunexus.UUCP (David Collier-Brown) writes:
>harrys@tons61.UUCP (Harry Skelton) writes:
>>allow the local site to include security measures for such a problem. Like
>>a chroot() before any work is done, or allocate spool directories that work
>>like the chroot command/uucp environments. This would resolve all of these
>>problems.
>
>How about:
> This mechanism will ensure that only files in the directories
> "under" the chroot-point are acessable:
>
> if program is not setuid-root,
> program exits forthwith
> if program is setuid-root
> program changes directory to chroot-point
> program changes root to chroot-point
> program gives up privilege by setting euid to uid.
>
> Note that this does not protect the system from any manipulations
> that the program does to the directorys below the chroot-point, only
> limits changes to files outside that area.
>
>Corrections and suggestions welcome!
Add to the list:
o make config file much like HDB to control available commands
for a particular user(s) (i.e. be able to limit CWD, etc)
o allow for separate log files for each user (config?)
o allow for 'secure' files although readable by anyone
- be able to exclude files from a user
- be able to include files for a user
o Add dual logfile/console logging of transmistions
- record user commands
- add record output for accounting purposes
o allow limits on amount of data passed or time consumed
- modification to RFC's necessary for new result codes
- changes in FTP commands to include overide protections?
Changes other than security....
o Add protocols other than ethernet connections
- add uucp transmitions interfaces
- add xmodem/ymodem/zmodem transmitions interfaces
o Add new binary standards
- header/noheader options (good for Mac Binary and other such codes)
- compress/nocompress options (for 56k/38.6k links, etc..)
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 1 May 90 13:59:24 GMT From: mcsun!ukc!mucs!cns!ran@uunet.uu.net (Bob Nutter) To: tcp-ip@nic.ddn.mil Subject: What do FIN_WAIT_2 & CLOSE_WAIT mean?
Could anyone elighten me with regards to the meanings of FIN_WAIT_2 and CLOSE_WAIT (and for that matter ESTABLISHED) when they appear in the socket state column for the default netstat output? We can't seem to find an explanation in any of our documentation. One of our (apollo dn4000) nodes has a *lot* of FIN_WAIT_2 entries and seems to be slowing down, hence the need to figure this out. Please reply by email. Thanx in advance, bob ------------------------------------------------------------------------------ bob nutter, computer officer | (Witty message on vacation) dept. of computation, UMIST | po box 88, m60 1qd uk | tel:+44 61 200 3386 | email:ran@cns.umist.ac.uk |
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 1 May 90 19:02:20 GMT From: zaphod.mps.ohio-state.edu!samsung!xylogics!transfer!lectroid!jjmhome!banyan!gordon@tut.cis.ohio-state.edu (Gordon Lee@Eng@Banyan) To: tcp-ip@nic.ddn.mil Subject: PC-LAN connection to Usenet
In article <2745@psueea.UUCP> dmatlock@eecs.UUCP (Delbert Matlock) writes: >In article <4950@netxcom.DHL.COM> cmoussav@dhlmis.DHL.COM (C. Ognibene-Moussavi) writes: >>I am asking the following question on behalf of my husband - at his work >>there is only a LAN - he would like to know what hardware, software and >>phone number he needs for a dial-up connection to Usenet - he would like >>to be able to read the newsgroups and post to them as well. > >Actually, I'de like to know if there is an implementation out there that >will run on a DOS or OS/2 based LAN. To be specific, a 3+Open LAN Manager >network. This LAN could easily be fitted with any protocols (TCP/IP) or >gateway equipment (X.25) needed, but I would like to avoid having to put >a 386 UNIX box on the network for just running Usenet. > I haven't heard of any implementations, but certainly wouldn't be conceptually difficult to write one. I've been thinking about this problem for the last two weeks or so. For cases where you have an Internet connection, it is possible to write an NNTP server for an OS/2 machine. The NNTP protocol can run over any stream oriented transport protocol, of course the protocol of choice would be TCP/IP stack since NNTP implementations within USENET are usually talking TCP/IP, (I haven't heard of an implementation which uses a different protocol). But NNTP could also be spoken over named pipes to transfer news to other OS/2 NNTP services. For that matter, it is possible to write an NNTP service for a DOS machine. Boot the pc, mount a large network file volume, fire up the NNTP server and leave the machine running on a continuous basis. The server fills the network volume up with USENET news. The directory structure would follow the same scheme found under UNIX implementations. Write a newsreader for DOS, and use it from other PC's to read news on the network file volume, no network code in the newsreader, it is doing sinple read system calls to the network file volume as if it were a local disk. Write an NNTP xmit client program to run under DOS and you can also post news. But where do you put the .newsrc file ? Oh, I dunno, punt for now, put it anywhere and then point an environment variable to it. Then of course, you'd also want to port all the other netnews support tools and utilities, like expire, and have something like cron to make them run on a schedule. And of course you'd have to leave the PC's running during the scheduled times. It all adds up to a large project made up of a lot of pieces, some of which are small though. Of course the whole thing rests on the assumption that you have network file volumes and a TCP/IP stack, but both of these have been commercially available for quite a while. I'd be interested in hearing of experiences or implementations from anyone else has looked at this problem, but please, no flames about DOS and/or OS/2, I am not interested in any Operating System holy wars. I am only interested in the communications aspects of the problem. - Gordon -- ============================================================================= Gordon Lee gordon@banyan.com Banyan Systems, Inc. Westboro, MA
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 2 May 90 00:32:48 GMT From: paperboy!snorkelwacker!ira.uka.de!smurf!wrkof!dksoft!dirk@think.com (Dirk Koeppen) To: tcp-ip@nic.ddn.mil Subject: TCP and UDP socket write limits
Where can I find information about the length I can write to a UDP or TCP socket. On my system (386/ix) I found out (try and error method) that SOCK_DGRAM sockets are limited to 1024 byte and SOCK_STREAM are limited to 4096 byte per write. There are some calls to increase the SOCK_STREAM buffer size but can I rely that another system will accept > 4096 byte packets ? Can't I let the kernel do the fragmentation ? cu, Dirk Koeppen dirk@incom.de
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Wed, 2 May 90 07:41:30 EST From: seadog!stan@uu.psi.com (Stanfield L. Smith) To: tcp-ip@nic.ddn.mil Subject: Local bridge w/SNMP
>Date: 23 Apr 90 20:24:12 GMT >From: Mitch Wood >Organization: Federal Express Corp., Memphis, TN >Subject: LoNeed Local Bridge w/SNMP > >Does anyone have a suggestion for a Local Bridge with SNMP support? > >thanx in advance >Mitch Wood` > Emerging Technologies Inc has a PC-based local bridge which supports SNMP. Its a hybrid bridge (it supports concurrent IP router and MAC-level bridging), and it can support up to 4 Ethernet networks. It uses the Western Digital WD8013E 16-bit card. Runs on any 25mhz AT, and the software is fairly inexpensive (about $1K). They are on Email: etinc!info@uu.psi.com Stan ----------------------------------------------------------------- Real Name : Stanfield L. Smith USmail : CNS Enterprises Internet : stan@seadog.cns.com : P.O. Box 1127 UUCP : uupsi!seadog!stan : Lk Ronkonkoma Phone : 516-737-2238 : New York 11779 -----------------------------------------------------------------
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Wed, 2 May 90 14:21:59 CDT From: cei001@uc.msc.umn.edu To: tcp-ip@NIC.DDN.MIL Subject: IP based job submission services..
I'm am sure that this story has been told before but I can't find it in the archives: A large organization decides to get its act together and connect the numerous machines with an open and robust communication network based on TCP/IP. Everything gets installed just fine, and the next day people are telnet'ing and ftp'ing to their hearts content. (Sounds great, doesn't it?) Now along comes a user who wants to do "batch" processing. He'd like to "submit" a job to another system. Imagine his surprise to find no popular IP service for this. He protests the "new" network and in order to avoid deinstalling the entire net, the organization quickly establishshes a RJE network (or equivalent) of sync lines between the very same host. Is it possible that there is some answer to this problem, and it just hasn't made it out to the commercial market yet? The only two published services I can find is the (old?) RJE spec, and the NQS code. Are there other common ones that I'm missing? I am interested in who's running what out there in field for this problem.. Now for the one little question I had (and I will repost this to IBMTCP list): Is there any sites that have a method for IP systems to submit MVS jobs? (On most other systems, ftp [or mail!] and some deamons will work..) ------- John Curran Engineering Computer Services Asea Brown Boveri (203) 285-652 cei001@uc.msc.umn.edu
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: 2 May 90 12:48:52 GMT From: mcsun!ukc!axion!masalla.fulcrum.bt.co.uk!igb@uunet.uu.net (Ian G Batten) To: tcp-ip@nic.ddn.mil Subject: Bootp, Rarpd Wanted
I'm looking for sources to either an implementation of bootp or, failing that, rarp. It's for System 5, but I'd be happy with anything Unix-y! Thanks for any pointers ian
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 2 May 90 19:29:54 GMT From: mcsun!unido!fauern!fauern!eckert@uunet.uu.net (Toerless Eckert) To: tcp-ip@nic.ddn.mil Subject: FAX over IP software wanted.
Sorry, i lost all my pointers on this subject.
Can anyone give me a hint, where to find such a beast ?
Thanks
--
Toerless Eckert Internet: eckert@informatik.uni-erlangen.de
X.400: /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=eckert/
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 2 May 90 23:15:57 GMT From: spdcc!ima!minya!jc@husc6.harvard.edu (John Chambers) To: tcp-ip@nic.ddn.mil Subject: Addressing SNMP proxy agents
Hi, y'all. My question today is triggered by a request by the folks I'm
working for that I see if our SNMP agents can be made to act as proxies
for machines that don't talk IP. On perusing rfc1085, I get the impression
that it is supposed to be possible. On the other hand, I don't quite know
enough to be able to say for sure how the code should be modified, if it
is even possible.
Several times in the past, I've written proxy agents for other configurations,
but then I've always had the advantage of writing both the client and the
agent code, so of course I could make them understand each other. In this
case, I'm just the proud posessor of the source code to the agent, which is
expected to talk to assorted SNMP clients from assorted vendors. This isn't
too surprising; this is what SNMP is all about, after all.
My problem is that I can't quite determine from the rfcs just what sort of
byte string (ASN.1, of course) to expect from a client that has sent me a
message. The current agent only understands addresses like:
40 4 16 121 0 95
where 40=IPaddress, 4 is the size, and the address is 16.1212.0.95. We've
gotten a couple of sessions together to bat about ideas, and the ways this
might be extended to indirect through a proxy, well, let's say that if you
have N people in the discussion, you probably have N*log(N) ways of doing
the job.
What I'm interested in is hearing how others expect this to work. If you
are writing an application that deals with proxy agents, what sort of
addresses will you be sending my agent?
To make things more concrete, suppose that behind the above proxy agent,
which is listening on the SNMP port, we have a bunch of machines on the
local FOOnet, and they have n-byte addresses. These could be represented
in various ways, such as a string:
4 3 54 71 71
where 4=string, 3 is its size, 54='f', 71='o', etc. The easiest way to
combine this with the agent's IP address would be as a 7-octet string:
40 7 16 121 0 95 54 77 71
This is, of course, far too simple-minded for any self-respecting hacker
(oops, I mean professional software engineer) to even consider, so obviously
it's not correct, and we must think of another method. One possibility
is to combine them into an ASN.1 sequence:
30 14 40 4 16 121 0 95 54 77 71 4 3 54 71 71
Many other possibilities come easily to mind, especially after a few
drinks (or perhaps something stronger than ethanol :-). I'd like to
find out which (if any) are "correct", and also which are likely to
be encountered in the Real World. (Note the implicit admission that
these aren't synonymous.)
On reading rfc1085, I find mention of something called a "presentation
selector", though I can't find anything that tells me how to recognize
one when it bites me. There's also a comment mentioning a 16-bit port
number, as well as something about a set indicating which transport
services are available. I speculate that this has something to do
with the problem but I can't quite decide what.
The whole problem is, of course, isomorphic to the older problem of
routing to indirectly reach machines that can't be reached directly.
We know lots of ways of doing this, and it's obvious that the SNMP
people, as well as the CMIP people, have considered it. They even
seem to have decided that they've solved the problem. Now someone
should be getting across to dummies like me just what the solution(s)
might look like.
I'd prefer email responses, since I've been sort of falling behind in
reading all the netnews that I should...
--
John Chambers ...!{harvard,ima,mit-eddie}!minya!jc
--
If you're not part of the solution, you're part of the precipitate.
[Kiel oni ^ci tiun diras esperante?]
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Thu, 03 May 90 12:07:48 -0700 From: wrs!yuba!hwajin@uunet.UU.NET (Hwa Jin Bae) To: uunet!think.com!barmar@uunet.UU.NET (Barry Margolin) Cc: tcp-ip@nic.ddn.mil, hwajin@uunet.UU.NET Subject: Re: TCP and UDP socket write limits
> > In article <982@dksoft.incom.de> dirk@dksoft.incom.de (Dirk Koeppen) writes: > >that SOCK_DGRAM sockets are limited to 1024 byte and SOCK_STREAM are > >limited to 4096 byte per write. There are some calls to increase the > >SOCK_STREAM buffer size but can I rely that another system will accept > >> 4096 byte packets ? Can't I let the kernel do the fragmentation ? > > There's should be no necessary relationship between kernel buffer size and > packet/datagram sizes for stream sockets. Stream sockets are byte streams, > and they can be packetized arbitrarily. During TCP connection setup each > side tells the other the largest packet size it's willing to accept. Also, > while the connection is open windows are increased and decreased to > accommodate the receiver's available buffer space. There kernel will have > to buffer data and/or block the sending process in order to accommodate the > other system's limits. > > Barry Margolin, Thinking Machines Corp. the socket level buffering is mostly independent of the protocol level buffering. tcp connection goes through max segment negotiation at the connection setup time but this is unrelated to the socket level buffer size; it is more dependent upon the mtu of the interface you're using. (see in tcp_mss() in tcp_input.c in 4.3 bsd tahoe tcp/ip implementation). the receive side tcp buffer window adjustments are related to the socket level buffer space. tcp uses the size of socket level buffers in calculating its receive window size. the socket level buffers are mbufs whose size can be adjusted via setsockopt() commands SO_RCVBUF and SO_SNDBUF. the default values for these buffers in stock 4.3 bsd tahoe tcp/ip are: tcp-receive (4K), tcp-send (4k), udp-receive (4k), udp-send (2k). if not enough space is available at the socket level and you're sending large piece of buffer you'll get an EMSGSIZE error. hwajin
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 3 May 90 00:36:53 GMT From: usc!samsung!munnari.oz.au!metro!bunyip!cuscus.cc.uq.oz.au!ggm@ucsd.edu (George Michaelson) To: tcp-ip@nic.ddn.mil Subject: Re: Could MX <pref> be made to do more?
craig@NNSC.NSF.NET (Craig Partridge) writes:
>> this means.... your mail sits in the local queue.
>Why are all the MX RRs on the wrong side of the pipe??
Good question. In general, one does not have control over the MX
records of ones elders and betters (c/f kre@munnari.oz.AU)
or (being less flippant) of distant hosts.
>In general, your lowest MXs ought to be very close to your system. So
>if you miss munnari, you oughtta be getting an MX nearby.
I'm confused by the "your" in there. Whose MXs should be close to me?
*my* MX records are: 0 myself 100 munnari 200 uunet.uu.net
but thats how I assert people should reach me. In sending stuff outwards
its "their" MX I'm using and for a.n.other's MX records you are dependant
on the sanity of the individual unknown sysop.
Munnari, in offering wildcard MXs for "big" networks is doing me a favour
so I don't want to cause any ill feeling there. Do they need gentle hints
about extending their MX structure?
-George
--
George Michaelson
Internet: G.Michaelson@cc.uq.oz.au Phone: +61 7 377 4079
Postal: George Michaelson, Prentice Computer Centre
Queensland University, St Lucia, QLD Australia 4067.
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Thu, 3 May 90 09:09:18 PDT From: braden@venera.isi.edu To: cei001@uc.msc.umn.edu, tcp-ip@nic.ddn.mil Subject: Re: IP based job submission services..
Is there any sites that have a method for IP systems to submit MVS jobs? (On most other systems, ftp [or mail!] and some deamons will work..) The UCLA ACP implementation of TCP/IP, running on a 3090 under OS/MVS, supports batch submission via SMTP. Bob Braden
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 3 May 90 02:35:59 GMT From: spdcc!ima!minya!jc@husc6.harvard.edu (John Chambers) To: tcp-ip@nic.ddn.mil Subject: Re: Is there SNMP Certification Testing?
In article <EMV.90Apr20103423@duby.math.lsa.umich.edu>, emv@math.lsa.umich.edu (Edward Vielmetti) writes:
> In article <9004200313.AA22741@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes:
> ... Now add
> a full-time neutral coordinator, ready to work with the various
> communities,from small startups, to the researchers, to big dinosaurs,
> to users, and we might catalyze the process.
>
> Ah, but who will pay the salary of this full-time coordinator? You're not
> going to find too many volunteers for the task.
> sounds like real work (but interesting) to me.
Yah; I've been volunteering for such a lab at various places for years,
and I've even been told I'd be good at it. ("Man, you sure know how to
find ways to make things fail!" ;-) So far, everyone thinks it's a real
good idea, but they want someone else to pay for it.
And people wonder why our stuff doesn't interoperate very well.
--
John Chambers ...!{harvard,ima,mit-eddie}!minya!jc
--
If you're not part of the solution, you're part of the precipitate.
[Kiel oni ^ci tiun diras esperante?]
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Thu, 03 May 90 08:50:17 cst From: (strick) <strick@ttuvm2.ttu.edu> To: TCP-IP%NIC.DDN.MIL@pucc.PRINCETON.EDU Subject: Re: IP based job submission services..
> Is there any sites that have a method for IP systems to submit MVS jobs? > > (On most other systems, ftp [or mail!] and some deamons will work..) > >The UCLA ACP implementation of TCP/IP, running on a 3090 under OS/MVS, >supports batch submission via SMTP. > >Bob Braden How can I get more information about UCLA ACP? strick
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 3 May 90 03:48:21 GMT From: spdcc!ima!minya!jc@husc6.harvard.edu (John Chambers) To: tcp-ip@nic.ddn.mil Subject: Is the hostname "foo" or "foo.bar.com"?
While I'm at it, I'll ask another question that has triggered a raging
religious war at work. The subject summarizes it, but I oughta give
some more details.
At this site, and at several others I've seen, there are some machines
on which if you type a
hostname
command you get a response like:
foo.bar.com
while on other machines, you would get only
foo
with the domain junk added by the mailer. The managers of each sort
of machine generally insist that they are doing it right, and it's the
idiots who do it the other way that are responsible for all the network
screwups that result.
I've just spent an hour or so perusing the RFCs, and I can see why there
is a question. There seems to be no unambiguous definition of "hostname"
that I can find. There are several apparently-relevant passages, but it
doesn't take a fine legal mind to pick holes in the wording of any of them.
For instance, in RFC883 we find:
| The labels must follow the rules for ARPANET host names. They must
| start with a letter, end with a letter or digit, and have as interior
| characters only letters, digits, and hyphen. There are also some
| restrictions on the length. Labels must be 63 characters or less.
|
| For example, the following strings identify hosts in the ARPA
| Internet:
|
| F.ISI.ARPA LINKABIT-DCN5.ARPA UCL-TAC.ARPA
This is at first glance self-inconsistent. At second glance, we see that
it in fact doesn't state the rules for a "hostname" It says that "labels"
contain only letters, digits, and hyphen. Leaving aside the question as
to whether two hyphens might be legal, we just note that the "foo.bar.com"
faction would simply say "Fine, the *label* `foo' follows the rules, and
the hostname is `foo.bar.com'." But the above examples aren't actually
stated to be hostnames; they are rather "strings [that] identify hosts",
something to which both factions would readily agree. The "foo" faction
would note that "foo.bar.com" identifies a host, and consists of two main
portions: "foo" is the hostname, and "bar.com" is the (2-level) domain.
My only contribution to this battle so far is to mention that I've seen cases
in which a mailer would take a name like "foo.bar.com" and append the domain
"bar.com" to it, giving "foo.bar.com.bar.com". Then there's the fun you can
have if JNET is involved: "com.bar.foo.bar.com". This is clearly brain damage
on the part of the mailer; it can be fixed easily by telling the kernel that
its hostname is "foo". This also satisfies my penchant for less typing, so
I tend to go with it. But it'd be nice to know which (if any) is correct.
It'd also be nice to have an official document to point to to settle the
debate when it rears its time-wasting head again.
There is also the problem with a hostname of foo.bar.com, in that many common
commands (such as who) truncate the hostname to N bytes, where N is typically
in the 10-16 range. The truncated output of such programs can't be used as
input to others, because the "hostnames" don't match anything in /etc/hosts,
although that's where they came from. Of course, this can happen with the
short form, since the RFCs state that 40-char names are legal, but have you
tried using one?
Part of the basis of the battle is that both factions "prove" their point
of view in terms of /etc/hosts. The "foo" crowd says that a proper entry
looks like:
16.37.91.42 foo foo.bar.com baz fliorph
while the "foo.bar.com" faction insists that the entry should read:
16.37.91.42 foo.bar.com foo baz fliorph
It's easy to show that BSD systems (and sendmail) require that the first
field of the localhost's entry by the same as the output of the hostname
command. If this isn't true, things can get very weird. But experiment
doesn't seem to say which is the One True Host Entry. It does show that
if both ends of a conversation do it differently, things can also get a
bit weird.
Anyone know what the answer to this is? (If history is any guide, I'd
expect followups proving that both are correct, and I'll have one more
entry in my growing list of Why Networks Are So Messed Up. ;-)
--
John Chambers ...!{harvard,ima,mit-eddie}!minya!jc
--
If you're not part of the solution, you're part of the precipitate.
[Kiel oni ^ci tiun diras esperante?]
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Thu, 03 May 90 11:30:23 -0400 From: Craig Partridge <craig@NNSC.NSF.NET> To: jc@minya.uucp Cc: tcp-ip@nic.ddn.mil Subject: re: Is the hostname "foo" or "foo.bar.com"?
John:
I think the proper answer to your question is:
``who cares what hostname says?''
Hostname is simply a UNIX program to let you give your host a name. It
has no standing in the Internet protocol suite.
What the RFCs are about is what comes out of your system. On that subject,
they're pretty clear (see RFCs 1122 and 1123). You're supposed to deliver
fully qualified domain names to the outside world. If you want to lie
internally to your users and call yourself "foo" that's your problem --
just make sure that when the mail comes off your host, it reads
"foo.bar.com"
That having been said, there's considerable annecdotal evidence that using
just "foo" is a mistake. Users assume that the name space is universal,
and will do things like tell their colleagues at other companies that
their e-mail address is "joe@foo" -- which isn't true, the actual address
is "joe@foo.bar.com" The result is upset and confused users -- if they
learn to think of their host as "foo.bar.com" they won't make this
mistake. [Hunt-and-peck typists will grumble briefly about the extra
typing and then write their own shell scripts so they can connect to
their favorite hosts by just typing "foo"]
Craig
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Thu, 03 May 90 11:03:37 cst From: (strick) <strick@ttuvm2.ttu.edu> To: TCP-IP%NIC.DDN.MIL@pucc.PRINCETON.EDU Subject: ACP basic info...
>The UCLA ACP software is available from UCLA for a $500 handling fee, >it includes most but all of the source code... the JOB Submittal code >is not available in source form as it was funded by IBM Federal Systems >Division. > >I'll be away until the end of the month, if you have any other questions >or wish to secure our code, with the limitations outlined, we can talk >more then. > >-- Denis DeLaRoca > UCLA Office of Academic Computing Thanks for your response. My director has OK'd payment of the $500. I need to find out What language(s) the code is written in. Also, what hardware does the program use to connect to ethernet? Steve Strickland Mgr. Network Services Texas Tech University
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 3 May 90 05:06:23 GMT From: barmar@think.com (Barry Margolin) To: tcp-ip@nic.ddn.mil Subject: Re: TCP and UDP socket write limits
In article <982@dksoft.incom.de> dirk@dksoft.incom.de (Dirk Koeppen) writes:
>that SOCK_DGRAM sockets are limited to 1024 byte and SOCK_STREAM are
>limited to 4096 byte per write. There are some calls to increase the
>SOCK_STREAM buffer size but can I rely that another system will accept
>> 4096 byte packets ? Can't I let the kernel do the fragmentation ?
There's should be no necessary relationship between kernel buffer size and
packet/datagram sizes for stream sockets. Stream sockets are byte streams,
and they can be packetized arbitrarily. During TCP connection setup each
side tells the other the largest packet size it's willing to accept. Also,
while the connection is open windows are increased and decreased to
accommodate the receiver's available buffer space. There kernel will have
to buffer data and/or block the sending process in order to accommodate the
other system's limits.
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Thu, 03 May 90 17:07:57 -0700 From: wrs!yuba!hwajin@uunet.UU.NET (Hwa Jin Bae) To: uunet!ucsd.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!@uunet.UU.NET, enea!mats@uunet.UU.NET (Mats Josefsson) Cc: tcp-ip@nic.ddn.mil, hwajin@uunet.UU.NET Subject: Re: The best TCP/IP implementation to base a port on?
> > We're in the process of implementing the TCP/IP protocol suite on a > Motorola 680x0 based system. It is running a Real-Time Operating > system radically different from Unix (more about that below). > what is the name of the OS? i work for wind river systems which develops & sells a realtime OS and development environment called VxWorks for a wide variety of motorola 680x0 based VME SBC's. VxWorks comes complete with 4.3 bsd tahoe tcp/ip, socket interface, NFS client implementation, RPC, etc. > It should be possible to boot our system from a Unix host over > Ethernet (this will require a minimal implementation of ARP/RARP, > BOOTP and TFTP, right?). > you'll definitely need ARP and TFTP (or FTP), but not necessary either BOOTP or RARP unless you don't know your Internet address at the time you boot your machine. if you're putting in the tcp/ip code in your EPROM, when the board powers up you can change the boot parameters (via a command line interface) or just use the default parameters to initialize the network device with a set Internet address, in which case you don't have to use RARP or BOOTP to get boot info. if you don't know the file name your loading or need some vendor specific info at boot time, you'll need to use BOOTP rather than RARP. overall, this is not a hard problem compared to the rest of the work you'll need to do to port/implement tcp/ip on your OS. > 1. Which TCP/IP implementation would be the best to start from? My > understanding is that we could use the 'BSD 4.3-Tahoe' > implementation. It is free (with some restrictions), implements > most of the required functionality, and it is widely used. I'm sure > there are several other alternatives. > the 4.3 bsd tahoe tcp/ip code is one of the best implementation (if not the best). many people are familiar with it and many are still working on some incredible optimization work. > The Real-Time OS we are using supports processes with hard > priorities, messages between processes, shared memory, semaphores, > timers, interrupt handlers etc. It is very fast. Process switch and > message sending takes about ten microseconds (on a 25 MHz MC68020). > gee... this sounds awful familiar to our system (minus tcp/ip and other networking stuff) ... 8-) hwajin bae wind river systems, emeryville, california, usa
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Thu, 3 May 90 11:53:24 CDT From: pdurrant@ub.d.umn.edu (Paul Durrant) To: TCP-IP@NIC.DDN.MIL Subject: Re: Is the hostname "foo" or "foo.bar.com"?
Mr. Chambers,
I'd appreciate learning what responses you get to the question
on the subject line.
Thanks, Paul Durrant
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 3 May 90 09:03:17 GMT From: paolo@semto.sem.it (Paolo Zeppegno) To: comp.protocols.tcp-ip Subject: help with ntp
Hi, here is a very simple question. I have a very small network, just a couple of machines (more to come real soon now) running ultrix 3.1. I have compiled ntp and I would like to have the clocks in my network synchronized. How do I do it? My brain is probably dead, but the doc is very hard to understand. Keep in mind that I have no access to any reference clock. Thanks a lot in advance. Paolo Zeppegno
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Thu, 03 May 90 16:32:12 EDT From: Bob Haring-Smith <RHH@brownvm.brown.edu> To: TCP-IP@SRI-NIC.ARPA Subject: Tektronix emulation
Does anyone know of software permitting Tektronix emulation over tcp/ip?
The sorts of connections for which I'm interested in this are PC to
MicroVax or VaxStation, Mac to IBM Mainframe, and PC to RT. Thanks.
--Bob
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 3 May 90 14:19:52 GMT From: netnews.upenn.edu!eniac.seas.upenn.edu!tao@rutgers.edu (Chun Tao) To: tcp-ip@nic.ddn.mil Subject: tn3270
I'm looking for the sources of tn3270 wrote by Mark Solomon from U. of Wisc. (not Berkeley version). Anyone can tell me where I can get this. Please e-mail to tao@eniac.seas.upenn.edu. Thanks. Regards, Chun Tao Chun Tao tao@mickey.nic.kingston.ibm.com
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 3 May 90 14:50:17 GMT From: strick@TTUVM2.TTU.EDU (strick) To: comp.protocols.tcp-ip Subject: Re: IP based job submission services..
> Is there any sites that have a method for IP systems to submit MVS jobs? > > (On most other systems, ftp [or mail!] and some deamons will work..) > >The UCLA ACP implementation of TCP/IP, running on a 3090 under OS/MVS, >supports batch submission via SMTP. > >Bob Braden How can I get more information about UCLA ACP? strick
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 3 May 90 15:30:23 GMT From: craig@NNSC.NSF.NET (Craig Partridge) To: comp.protocols.tcp-ip Subject: re: Is the hostname "foo" or "foo.bar.com"?
John:
I think the proper answer to your question is:
``who cares what hostname says?''
Hostname is simply a UNIX program to let you give your host a name. It
has no standing in the Internet protocol suite.
What the RFCs are about is what comes out of your system. On that subject,
they're pretty clear (see RFCs 1122 and 1123). You're supposed to deliver
fully qualified domain names to the outside world. If you want to lie
internally to your users and call yourself "foo" that's your problem --
just make sure that when the mail comes off your host, it reads
"foo.bar.com"
That having been said, there's considerable annecdotal evidence that using
just "foo" is a mistake. Users assume that the name space is universal,
and will do things like tell their colleagues at other companies that
their e-mail address is "joe@foo" -- which isn't true, the actual address
is "joe@foo.bar.com" The result is upset and confused users -- if they
learn to think of their host as "foo.bar.com" they won't make this
mistake. [Hunt-and-peck typists will grumble briefly about the extra
typing and then write their own shell scripts so they can connect to
their favorite hosts by just typing "foo"]
Craig
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 3 May 90 19:32:31 GMT From: new@louie.udel.edu (Darren New) To: tcp-ip@nic.ddn.mil Subject: Estelle Specifications On-Line
This is an announcement of the availability of specifications written
in the Estelle formal description technique.
These specifications are provided as a public service. The only requirement
for obtaining any specifications so available are the following:
1) Your name, organization, state, and country are provided in the
request. This is to allow us to send updates and to stay in touch
with other users of Estelle. It would be best to specify enough
information that anyone worldwide could contact you via postal mail.
This list will be distributed only to others on the same list; if you
so specify, we will avoid distributing your information at all.
2) Your email address is provided. Contact us if email is inapproriate;
we will try to accomodate your needs.
3) You agree to the disclaimer below.
We also have various tools and memoranda concerning Estelle. Contact
GROPE@UDEL.EDU for details. The NIST also provides an assortment of
tools; see below.
It is hoped that others will contribute specifications of real-world
protocols. Appropriate credit will of course be given and any copyright
restrictions will be observed. I hope this will become a major resource
in the research and engineering community.
In addition, additions to the "people" list and the "biblio" list are
welcome.
Points of contact at University of Delaware:
amer@udel.edu -- Prof. Paul Amer -- Advisor
new@udel.edu -- Graphical Representation of Protocols in Estelle
chun@udel.edu -- Test Sequence Generation from Estelle
chamber@udel.edu -- Adding Broadcast, RendezVous, and Real-Time
to Estelle.
est-specs@udel.edu -- Currently aliases to new@udel.edu. This is where
to send requests for specs. This may eventually
become automated or moved to another individual.
grope@udel.edu -- Requests about Graphical Representation Of
Protocols in Estelle (aka GROPE).
Unless otherwise noted in the individual specification, the following
conditions are taken to apply:
This specification and all derivative works are copyright 1990 by the
University of Delaware. All Rights Reserved.
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted, provided
that the above copyright notice appear in all copies and that both that
copyright notice and this permission notice appear in supporting
documentation, and that the names of the copyright holder or author not be
used in advertising or publicity pertaining to distribution of the
software without specific, written prior permission.
BOTH THE AUTHOR AND THE COPYRIGHT HOLDER DISCLAIM ALL WARRANTIES WITH
REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDER OR THE
AUTHOR BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY
DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The specifications which are commented as "compilable" means that the
specification has been checked and found to be statically correct
using the version of PET available 5/1/90 from NIST. It does NOT mean
that the specification is an official standard, nor does it mean that
the specification is complete or correct relative to the English
version of the standard. Even some of the "non-compilable" specs
can be compiled with the NBS prototype compiler.
WISE is available directly from National Institute of Standards
and Technology (NIST, formerly NBS), without whose help GROPE would
never have come to be.
>From: Rachid Sijelmassi <sijel@apm1.ncsl.nist.gov>
>Organization: National Institute of Standards and Technology (NIST)
>Sub-Organization: National Computer Systems Laboratory
>
>The latest version of WISE is available by anonymous FTP
>from osi.ncsl.nist.gov. The code for WISE is part of
>the OSIkit package, so you can take all or part of it.
>Once you are on osi.ncsl.nist.gov, go to pub/osikit.
>You will find the Estelle-to-C compiler (estpc.tar),
>the ASN1 tool (asnfvt.tar), Wizard (estwizard.tar),
>WISE (estwise.tar) and the manuals (mansrc.tar).
Please note that to translate from Estelle to Smalltalk,
estwizard.tar will be needed in addition to estwise.tar.
Files you should receive:
README -- This file
biblio -- A bibliographic database of FDT infomation
(Scribe/LaTeX format)
people -- Other people to whom this has been sent
vtp.e -- ISO Virtual Terminal Protocol
sess.e -- ISO Session Layer
ntp.tex -- RFC1119 Network Time Protocol
ip.e -- CLNP in Estelle
ab.e -- Alternating Bit (again)
bump.e -- R. Tenney's bumpgame
fep.e -- The Fact Exchange Protocol
Thanks for your interest! -- Darren
------------------------------------------------------------
These people are already on the list and will receive the
first batch of specs:
alex@comsys.COM -- IF I CAN GET TO YOU! MY HOST DOES NOT KNOW COMSYS.COM
dabbous@mirsa.inria.fr
thomson@unix.sri.com
calvert@cs.utexas.edu
mondain@iro.umontreal.ca
Others are expected shortly as the result of mailing this announcement
to various conference-proceedings lists. Thank you -- Darren
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 3 May 90 20:32:12 GMT From: RHH@BROWNVM.BROWN.EDU (Bob Haring-Smith) To: comp.protocols.tcp-ip Subject: Tektronix emulation
Does anyone know of software permitting Tektronix emulation over tcp/ip?
The sorts of connections for which I'm interested in this are PC to
MicroVax or VaxStation, Mac to IBM Mainframe, and PC to RT. Thanks.
--Bob
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 4 May 90 02:30:28 GMT From: law@louie.udel.edu (Jeff Law) To: tcp-ip@nic.ddn.mil Subject: Re: Is the hostname "foo" or "foo.bar.com"?
In article <9005032308.AA14782@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET (Craig Partridge) writes: >John: >I think the proper answer to your question is: > ``who cares what hostname says?'' > >Hostname is simply a UNIX program to let you give your host a name. It >has no standing in the Internet protocol suite. >That having been said, there's considerable annecdotal evidence that using >just "foo" is a mistake. Users assume that the name space is universal, >and will do things like tell their colleagues at other companies that >their e-mail address is "joe@foo" -- which isn't true, the actual address >is "joe@foo.bar.com" The result is upset and confused users -- if they >learn to think of their host as "foo.bar.com" they won't make this >mistake. [Hunt-and-peck typists will grumble briefly about the extra >typing and then write their own shell scripts so they can connect to >their favorite hosts by just typing "foo"] agreed. you wouldnt believe how true this is... we found out the hard way, we've changed all the machines we run to return fully qualified hostnames... interesting side effects are that braindamaged mail agents work much better with the rest of the world now. you will never see a mail message like From: Joe User <user@supid> from any of our machines... whatever you set hostname to will be returned as the official name when gethostname is called.. mucho better! now i wont mention what YP and some braindamaged shell scripts that only looked for unqualified hostnames think of this change :) jeff -- Jeff Law University of Delaware PHONE: (302)-451-8005 work, (302) 731-1462 home E-Mail: law@ee.udel.edu, UUCP: ...!<your_favorite_arpa_gateway>!udel.edu!law
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Fri, 4 May 90 11:03 CDT From: "Paul W. Fakler" <PWF@vx.acs.umn.edu> To: tcp-ip@nic.ddn.mil, bobr@dbm1.mpc.af.mil Subject: Re: Bad domain name
>From: Robert Reed <bobr@dbm1.mpc.af.mil>
>As one of the AF.MIL domain name servers, I have noticed that you are one
>of the 100 sites that are sending queries for the address of
>
> GENTER-ADAM.AF.MIL
>
>As this name is not in the domain, and has never been, these queries are
>a large overhead with no payback. We receive an average of 1500 per hour
>just for this host.
>
>Please help us trace down where these queries are originating from. Any info
>will be welcome, address of originating host, or a copy of mail that is
>generating the request.
I checked out the information in the nameserver on vx.acs.umn.edu, and found
a record for GENTER-ADAM.AF.MIL listed as one of the root name servers!
> set q=ns
> .
Server: vx.acs.umn.edu
Address: 128.101.63.1
(root) server name = GENTER-ADAM.AF.MIL
(root) server name = NS.NASA.GOV
...
Unless it happens again, I am assuming for the moment that a typo got into the
configuration file on one of the root servers, and GENTER-ADAM.AF.MIL should
have been GUNTER-ADAM.AF.MIL. When I restarted the name server, the cache was
initialized correctly (and had a root server record for GUNTER-ADAM.AF.MIL).
Paul Fakler.
My cache initialization file follows:
------------------------------------------------------------------------------
$ORIGIN .
99999999 IN NS NS.NIC.DDN.MIL.
99999999 IN NS C.NYSER.NET.
99999999 IN NS NS.NASA.GOV.
99999999 IN NS TERP.UMD.EDU.
99999999 IN NS A.ISI.EDU.
99999999 IN NS AOS.BRL.MIL.
;
NS.NIC.DDN.MIL. 99999999 IN A 192.67.67.53
C.NYSER.NET. 99999999 IN A 192.33.4.12
NS.NASA.GOV. 99999999 IN A 128.102.16.10
NS.NASA.GOV. 99999999 IN A 192.52.195.10
TERP.UMD.EDU. 99999999 IN A 128.8.10.90
A.ISI.EDU. 99999999 IN A 128.9.0.107
AOS.BRL.MIL. 99999999 IN A 192.5.25.82
AOS.BRL.MIL. 99999999 IN A 128.20.1.2
--------------------------------------------------------------------------------
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Fri, 4 May 90 18:38 PDT From: "Henry W. Miller" <HMILLER%SCU.BITNET@CORNELLC.cit.cornell.edu> To: tcp-ip@nic.ddn.MIL Subject: Ingres certification of TCP/IP
We are in the process of augmenting our current TCP/IP software with
a version that is "Ingres certified". I can't seem to get a decent answer
to what this means. Can anyone out there fill me in?
Thanks in advance,
-HWM
----------
Henry W. Miller
U.S. Bureau of Reclamation
Assistant Systems Manager, Mid Pacific Region
2800 Cottage Way, MP-1100
Sacramento, CA 95825
(916) 978-5108 / FTS 460-5108
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 4 May 90 13:29:01 GMT From: aecom!naftoli@uunet.uu.net (Robert N. Berlinger) To: tcp-ip@nic.ddn.mil Subject: Re: rlogin and security
In article <9004300749.AA01275@ISIS.U-STRASBG.FR> pansiot@isis.u-strasbg.FR (Jean-Jacques Pansiot Departement d'Informatique Universite Louis Pasteur Strasbourg FRANCE) writes: > >I know that rlogin is not secure, but its worse than what i thought. >Basically with rlogin anybody can break into your computer (at leasr Sun, >Silicon Graphics,...) provided you have entries in your /etc/passwd with >* as a password. I thought * was used to forbid login, it is quite the >contrary. >Is this a well known Bug of rlogin? Is there a Fix ? I'm running SunOS 4.1 and don't have the same behavior. Perhaps you left the default /etc/hosts.equiv in place, which opens the host to all other hosts in the NIS. -- Robert N. Berlinger |Domain: naftoli@aecom.yu.edu Supervisor of Systems Support |UUCP: ...uunet!aecom!naftoli Scientific Computing Center |CompuServe: 76067.1114@compuserve.com Albert Einstein College of Medicine |AppleLink: D3913@applelink.apple.com
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 4 May 90 16:20:36 GMT From: stan!dancer!imp@boulder.colorado.edu (Warner Losh) To: tcp-ip@nic.ddn.mil Subject: Re: Is the hostname "foo" or "foo.bar.com"?
In article <9005032308.AA14782@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET (Craig Partridge) writes: >[Hunt-and-peck typists will grumble briefly about the extra >typing and then write their own shell scripts so they can connect to >their favorite hosts by just typing "foo"] Most TCP/IP's that I have abused (er ah used) have a feature that lets you say telnet foo when you mean telnet foo.bar.com. That is they add the current domain to the name if there are no dots (some do even if there are). Others there is a list of domains to append to the hostname when trying. The only draw back to doing a "hostname foo.bar.com" in your rc.local (or where ever) file is that the default csh prompt is "foo.bar.com% " rather than "foo% ". Warner Losh imp@Solbourne.COM
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 4 May 90 16:27:13 GMT From: mcsun!cernvax!chx400!hslrswi!aut!huber@uunet.uu.net (Daniel Huber) To: tcp-ip@nic.ddn.mil Subject: Connect AS/400 and UNIX (TCP/IP). HOW?
Hi
We have some UNIX Computers : 30 Sun's (SunOS 4), 34 HP's (HP-UX 7.0),
2 NCR's (SysV.2), 2 Plexus (SysV.2), some PC's (Interactiv UNIX),
about 50 Mac's (MultiFinder) and about 120 PC's (MSDOS).
All are connected together with ETHERNET 802.3 (TCP/IP). Some Mac's
with AppleTalk (there is actually a GatorBox in test for AppleTalk -
TCP/IP connectivity).
Then I have an AS/400 and 2 System/36. ;-(
My problem is:
How can I connect the AS/400 and /36's to the UNIX-TCP/IP
world.
I've tried with an ASTEK-Box (Mytek). Works ok (ftp, telnet), but we
need more.
We want something like NFS.
How can I realise that.
- Is it true that AS400 supports TCP/IP ?
- Can I directly connect an AS400 to 802.3 ?
- Is there a product for "NFS" filesystems, from and to AS400
( UNIX <-> AS400) ?
- I heard something about OS/2 EE 1.2. What's that ?
(could be a similar thing as OS/2-LanManager for sharing AS400
disk with OS/2-PC's ? Or perhaps a gateway between SNA and
TCP/IP ?)
- If OS/2 EE is a software (like LanManager), does it run with
Microsoft's LanManager for OS/2, so I'm able to export AS400
directories via OS/2 EE and OS/2-LanManager to LanManager/X
an then to other users.
Utopia ? Who knows ?
Please e-mail, if you can help me.
Thanks
Daniel
--
Daniel Huber Tel. +41 31 52 96 64
Ascom Autelca Fax. +41 31 52 77 45
CH-3073 Guemligen email: huber@aut.uucp
Switzerland uucp: uunet!mcsun!cernvax!hslrswi!aut!huber
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 4 May 90 18:02:00 GMT From: usc!snorkelwacker!spdcc!xylogics!transfer!lectroid!jjmhome!cpoint!frog!barr@ucsd.edu (Chris Barr) To: tcp-ip@nic.ddn.mil Subject: /etc/hosts used for 2 protocols' addresses
I'd like to use an IP-format /etc/hosts file to lookup network addresses
used by a another protocol run on the same host. (The addresses happen to
be Ethernet card hardware addresses.) I wonder if anyone else has
faced this question of entering a second network address in /etc/hosts.
TCP/IP will continue to use the same /etc/hosts file.
The simplest extension seems to be using the comment field for the 2nd
protocol's address ----------------
|
v
nnn.nnn.nnn.nnn name name ... # 0xnn0xnn0xnn0xnn0xnn0xnn
A new entry in /etc/protocols doesn't make sense, because this protocol
doesn't use IP.
Thanks, in advance, for any comments.
barr@frog
{!harvard !mit-eddie} !frog!barr
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 4 May 90 20:37:19 GMT From: intercon!news@uunet.uu.net (Kurt Baumann) To: tcp-ip@nic.ddn.mil Subject: Re: Tektronix emulation
In article <9005040701.AA12937@ucbvax.Berkeley.EDU>, RHH@BROWNVM.BROWN.EDU (Bob Haring-Smith) writes: > Does anyone know of software permitting Tektronix emulation over tcp/ip? > The sorts of connections for which I'm interested in this are PC to > MicroVax or VaxStation, Mac to IBM Mainframe, and PC to RT. Thanks. > --Bob There are a couple of packages that you might want to look at. One is the NCSA telnet for the PC and Mac that does tektronix 4014 emulation. Our product TCP/Connect II does 4014 emulation on the PC and Mac, as well as IBM 3278 emulation. We also have a package called InterCon Telnet Driver which runs on the Mac and allows VersaTerm Pro (tek 4105 emulation) and MicroPhone II to run over a telnet session. You can get NCSA telnet from zaphod.uiuc.edu (I believe). You can get info on TCP/Connect II and the Telnet Driver by dropping a note to comment@intercon.com or to me. Hope that helps.--
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: 4 May 90 21:57:31 GMT From: swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!mike@ucsd.edu (Mike Trogni) To: tcp-ip@nic.ddn.mil Subject: Re: NCSA Telnet availability
In article <2641E7FF.3E13@intercon.com> kdb@macaw.intercon.com (Kurt Baumann) writes: > >You can get NCSA telnet from zaphod.uiuc.edu (I believe). > actually its available from ftp.ncsa.uiuc.edu which is Cname for zaphod.ncsa. uiuc.edu (128.174.20.50). - mike -- mike@uxa.cso.uiuc.edu
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 4 May 90 23:27:41 GMT From: phoenix!phoenix.princeton.edu!eho@princeton.edu (Eric Ho) To: tcp-ip@nic.ddn.mil Subject: PPP ??
I'm not sure if these are the right newsgroups to send to but I'm interested in knowing current developments concerning PPP. I would be very much appreciated if anyone can give me any pointers on this. -- Eric Ho Princeton University eho@clarity.princeton.edu
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 5 May 90 01:16:51 GMT From: excelan!manoj@ames.arc.nasa.gov (manoj @ Prod Mktg) To: tcp-ip@nic.ddn.mil Subject: Re: Tektronix emulation
In article <9005040701.AA12937@ucbvax.Berkeley.EDU>, RHH@BROWNVM.BROWN.EDU (Bob Haring-Smith) writes:
> Does anyone know of software permitting Tektronix emulation over tcp/ip?
> The sorts of connections for which I'm interested in this are PC to
> MicroVax or VaxStation, Mac to IBM Mainframe, and PC to RT. Thanks.
A number of coompanies offer tektronix term. emulators that write to int14
or int6b and can be used as is on top of tcp/ip networks that have int14 & 6b
support..
With LAN WorkPlace for DOS (Novell's TCP/IP for DOS), these are some of the
3rd party term emulators..
walker richer quinn, seattle, WA
kea systems, vancouver , canada
softronics,
grafpoint, saratoga, ca
persoft,
polygon,
diversified computer systems
thx..
manoj goel, 0 0
Product Marketing ^
Novell/Excelan Inc., San Jose, CA \_/
(408) 473-8369 (voice) / 433-0775 (fax) Internet: manoj@novell.com
___________________________________________________________________________
"For every vision, there is an equal but opposite revision"
__
((__ \
\\ !
!!!
o_@@--.\
(___, /
___! ! Regards!
/ .-! ! _)
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 5 May 90 01:23:15 GMT From: van-bc!mplex!fff@ucbvax.Berkeley.EDU (Fred Fierling) To: tcp-ip@nic.ddn.mil Subject: Re: The best TCP/IP implementation to base a port on?
In article <9005040007.AA13233@yuba.WRS.COM>, hwajin@yuba.UUCP (Hwa Jin Bae) writes: > > 1. Which TCP/IP implementation would be the best to start from? My > > understanding is that we could use the 'BSD 4.3-Tahoe' > > implementation. It is free (with some restrictions), implements From where can you get BSD 4.3-Tahoe TCP/IP? -- Fred Fierling uunet!van-bc!mplex!fff Tel: 604 875-1461 Fax: 604 875-9029 Microplex Systems Ltd 265 East 1st Avenue Vancouver, BC V5T 1A7, Canada
-----------[000042][next][prev][last][first]----------------------------------------------------
Date: 5 May 90 01:38:00 GMT
From: HMILLER@SCU.BITNET ("Henry W. Miller")
To: comp.protocols.tcp-ip
Subject: Ingres certification of TCP/IP
We are in the process of augmenting our current TCP/IP software with
a version that is "Ingres certified". I can't seem to get a decent answer
to what this means. Can anyone out there fill me in?
Thanks in advance,
-HWM
----------
Henry W. Miller
U.S. Bureau of Reclamation
Assistant Systems Manager, Mid Pacific Region
2800 Cottage Way, MP-1100
Sacramento, CA 95825
(916) 978-5108 / FTS 460-5108
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 5 May 90 02:19:10 GMT From: CCECHAN@NUSVM.BITNET (Luther Chan) To: comp.protocols.tcp-ip Subject: How to turn RIP off in Sun 3/50??
Dear Networkers, Can anyone tell me how to turn the RIP in Sun 3/50 with Sun OS 3.3 or 3.4? Please tell where is the file contain the switch and the file name. Thank you in advance! Luther
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 5 May 90 02:19:52 GMT From: sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU (Vernon Schryver) To: tcp-ip@nic.ddn.mil Subject: Re: Is the hostname "foo" or "foo.bar.com"?
In article <376@minya.UUCP>, jc@minya.UUCP (John Chambers) writes:
> It's easy to show that BSD systems (and sendmail) require that the first
> field of the localhost's entry by the same as the output of the hostname
> command.
I know of a few thousand hosts running 4.3BSD networking code and sendmail
which violate this rule, and send and receive mail all over the Internet,
UUCP, BITNET, and beyond. These machines are configured so that `hostname`
returns "foo", but the moral equivalent of gethostbyname("foo") returns an
pointer to foo.bar.com as the first name.
Vernon Schryver
vjs@sgi.com
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 5 May 90 02:29:41 GMT From: swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!mlb.semi.harris.com!thrush.mlb.semi.harris.com!del@ucsd.edu (Don Lewis) To: tcp-ip@nic.ddn.mil Subject: Re: Bad domain name
In article <9D496D584DDFE0551B@UMNACVX.BITNET> PWF@VX.ACS.UMN.EDU ("Paul W. Fakler") writes:
>>From: Robert Reed <bobr@dbm1.mpc.af.mil>
>>As one of the AF.MIL domain name servers, I have noticed that you are one
>>of the 100 sites that are sending queries for the address of
>>
>> GENTER-ADAM.AF.MIL
>>
>>As this name is not in the domain, and has never been, these queries are
>>a large overhead with no payback. We receive an average of 1500 per hour
>>just for this host.
>>
>>Please help us trace down where these queries are originating from. Any info
>>will be welcome, address of originating host, or a copy of mail that is
>>generating the request.
>
>I checked out the information in the nameserver on vx.acs.umn.edu, and found
>a record for GENTER-ADAM.AF.MIL listed as one of the root name servers!
>
>> set q=ns
>> .
>Server: vx.acs.umn.edu
>Address: 128.101.63.1
>
>(root) server name = GENTER-ADAM.AF.MIL
>(root) server name = NS.NASA.GOV
>...
>
>Unless it happens again, I am assuming for the moment that a typo got into the
>configuration file on one of the root servers, and GENTER-ADAM.AF.MIL should
>have been GUNTER-ADAM.AF.MIL. When I restarted the name server, the cache was
>initialized correctly (and had a root server record for GUNTER-ADAM.AF.MIL).
Ah, GENTER-ADAM.AF.MIL is back again. I haven't seen that one in a couple
of months. Last week it was SRI-NIC.ARPA and BRL-AOS.ARPA. I don't think
the fault lies with the root name servers, it is mainly due to
misconfiguration the name servers for some of the subdomains, typically
in-addr.arpa subdomains.
Let's say that hosts X and Y are listed as the name servers for
xxx.128.in-addr.arpa. Now lets assume that Y thinks that GENTER-ADAM
is one of the root name servers. If host Z queries host Y for the
PTR record for aaa.bbb.xxx.128.in-addr.arpa, and host Y is *not*
actually a name server for xxx.128.in-addr.arpa, then host Y will
respond with a referral message. In this example the message will
contain an empty answer section, a list of the root name servers
in the authority section, and the addresses of these name servers
in the additional section. Now host Z will believe that
GENTER-ADAM.AF.MIL is a root name server. If Z is also listed
as a name server for a zone that it is not actually a server for,
it will in turn pass on this information.
I have also observed hosts returning a list of the root name
servers in the authority section when in fact they are authoritative
name servers for the domain, but I don't know whether this is
due to broken software or some other type of misconfiguration.
Let's stamp out DTB's (DNS Transmitted Bogosities)!
Now as far as the large number of queries to the root name servers
is concerned, there appears to be a nasty bug in BIND 4.8.1,
and probably other versions as well. When a resolver is referred
to a name server in order to the answer a query and it does not
have the address of the name server, the resolver must start
a second query for the address of the name server. In BIND,
if the result of the query for the address of the name server
is a CNAME, it is not smart enough to follow the CNAME to
get the address. If the result is NXDOMAIN, this information
is not cached. Now if one of the name servers that BIND doesn't
have an address for is one of the *root* name servers, this will
probably happen quite a lot considering that BIND has to consult
the root name servers in order to look up the address of one of the
root servers. It gets worse if there are other problems, like
unreachable name servers if BIND's clients don't understand
how to correctly deal with temporary failure and keep retrying.
I've seen its rubber band get wound pretty tight.
I keep hearing rumors of a new version of BIND, but I haven't
seen any official word. Having negative caching and a few
bug fixes would help the situation a lot.
--
Don "Truck" Lewis Harris Semiconductor
Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028
Phone: (407) 729-5205 Melbourne, FL 32901
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Sat, 05 May 90 18:27:20 -0700 From: wrs!yuba!hwajin@uunet.UU.NET (Hwa Jin Bae) To: uunet!ucbvax.Berkeley.EDU!van-bc!mplex!fff@uunet.UU.NET (Fred Fierling) Cc: tcp-ip@nic.ddn.mil Subject: Re: The best TCP/IP implementation to base a port on?
> >From where can you get BSD 4.3-Tahoe TCP/IP? > -- > Fred Fierling uunet!van-bc!mplex!fff Tel: 604 875-1461 Fax: 604 875-9029 via anonymous ftp or uucp from uunet machine. look under the directory: /usr/spool/ftp/bsd-sources hwajin wind river systems
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Sat, 05 May 90 09:17:48 SST From: Luther Chan <CCECHAN%NUSVM.BITNET@CUNYVM.CUNY.EDU> To: Vivian Neou <TCP-IP@SRI-NIC.ARPA> Subject: How to turn RIP off in Sun 3/50??
Dear Networkers, Can anyone tell me how to turn the RIP in Sun 3/50 with Sun OS 3.3 or 3.4? Please tell where is the file contain the switch and the file name. Thank you in advance! Luther
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Sat, 05 May 90 17:42:24 EDT From: "Lee C. Varian" <LVARIAN@pucc.PRINCETON.EDU> To: TCP-IP@NIC.DDN.MIL Subject: Re: IP based job submission services..
On Wed, 2 May 90 14:21:59 CDT <cei001@UC.MSC.UMN.EDU> said: >Now along comes a user who wants to do "batch" processing. He'd like to >"submit" a job to another system. Imagine his surprise to find no popular >IP service for this. He protests the "new" network and in order to avoid >deinstalling the entire net, the organization quickly establishshes a RJE >network (or equivalent) of sync lines between the very same host. John, Another approach is simply to run NJE as an application on top of TCP/IP. This is being done by about 100 sites worldwide, using the BITNET II protocol (for NJE over TCP) developed at Princeton University and implemented for IBM VM systems by Princeton University (VMNET); for VMS systems by Joiner Associates (JNET TCP NJE) and Hebrew University of Jerusalem (HUJI-NJE); and for Berkeley Unix systems by Harvard University (UREP TCP/IP) and Technion-Haifa. Lee Varian lvarian@pucc.princeton.edu Princeton University
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 5 May 90 17:18:00 GMT From: ogicse!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!gupta@ucsd.edu To: tcp-ip@nic.ddn.mil Subject: protocol tester wanted
I'm looking for a C package that can be used to test various protocols over
a network. I'm currently trying to port x-kernel, but am wondering if there
are any other packages (preferably ones that don't simulate an entire kernel!)
that will do the job.
Please email all replies to rohit@uiuc.edu because I do not read this group.
Thanks in advance!
Rohit
NOTE: this is being cross-posted to a couple of groups, my apologies if you see
it more than once...
-------------------------------------------------------------------------------
Internet:rohit@uiuc.edu UUCP:uunet!uiucuxc!ux1!gupta BITnet:GUPTA@UIUCVMD
"There are no good wars, with the following exceptions: the American
Revolution, World War II, and the Star Wars Trilogy..."
-- Bart Simpson
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 5 May 90 19:18:11 GMT From: rogue.llnl.gov!oberman@lll-winken.llnl.gov To: tcp-ip@nic.ddn.mil Subject: Re: Bridges not passing bcasts (update)
In article <7594@uswat.UUCP>, matthews@uswat.uswest.com (John Matthews) writes: > Please give a little detail if possible. What other bridges does everyone > know about that learn these bad source addresses? I can also confirm the reports, but what you really need to know is that this bad behaviour is the result of a bug in V2.0 ROMs. If you get your ROMs updated, the problem will go away. 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.
-----------[000051][next][prev][last][first]----------------------------------------------------
Date: 5 May 90 21:42:24 GMT
From: LVARIAN@PUCC.PRINCETON.EDU ("Lee C. Varian")
To: comp.protocols.tcp-ip
Subject: Re: IP based job submission services..On Wed, 2 May 90 14:21:59 CDT <cei001@UC.MSC.UMN.EDU> said: >Now along comes a user who wants to do "batch" processing. He'd like to >"submit" a job to another system. Imagine his surprise to find no popular >IP service for this. He protests the "new" network and in order to avoid >deinstalling the entire net, the organization quickly establishshes a RJE >network (or equivalent) of sync lines between the very same host. John, Another approach is simply to run NJE as an application on top of TCP/IP. This is being done by about 100 sites worldwide, using the BITNET II protocol (for NJE over TCP) developed at Princeton University and implemented for IBM VM systems by Princeton University (VMNET); for VMS systems by Joiner Associates (JNET TCP NJE) and Hebrew University of Jerusalem (HUJI-NJE); and for Berkeley Unix systems by Harvard University (UREP TCP/IP) and Technion-Haifa. Lee Varian lvarian@pucc.princeton.edu Princeton University
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 6 May 90 20:50:38 GMT From: minya!jc@eddie.mit.edu (John Chambers) To: tcp-ip@nic.ddn.mil Subject: Re: Is the hostname "foo" or "foo.bar.com"?
In article <18464@nigel.udel.EDU>, law@udel.EDU (Jeff Law) writes:
> In article <9005032308.AA14782@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET (Craig Partridge) writes:
> >John:
> >I think the proper answer to your question is:
> > ``who cares what hostname says?''
For starters: sendmail, rsh, rcp, telnet, gethostbyname(), ...
> >Hostname is simply a UNIX program to let you give your host a name. It
> >has no standing in the Internet protocol suite.
If true, then how could SMTP ever possibly work? One of the documentable
anomalies is host foo.bar.com calling bletch.org's SMTP port, and one of
them rejecting the other because they disagree on the hostname convention.
If there were a paragraph in an RFC I could point to, perhaps I could say
"All you guys doing it *that* way are wrong." But it looks like I can't
say that, so the turkeys will continue insisting they're right, and the
anomalies will continue.
> agreed. you wouldnt believe how true this is... we found out the hard way,
> we've changed all the machines we run to return fully qualified hostnames...
>
> now i wont mention what YP and some braindamaged shell scripts that only
> looked for unqualified hostnames think of this change :)
But this is the whole point of the question. Personally, I think that any
software that can't handle both conventions is braindamaged. But I can't
correct them all; I don't have the time or the source code.
Perhaps I could ask it this way: Suppose we were to uniformly adopt one
convention of the other. Is there a straighforward way to identify the
programs that have problems with it, and diddle their config files so they
work correctly? If this can be answered for one convention or the other,
that would also answer the original question, at least for pragmatists
like me.
BTW, are you aware that there are systems being sold that limit hostnames
(sometimes doubling as sysnames or nodenames) to 16 bytes?
--
John Chambers ...!{harvard,ima,mit-eddie}!minya!jc
--
If you're not part of the solution, you're part of the precipitate.
[Kiel oni ^ci tiun diras esperante?]
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 6 May 90 23:08:41 GMT From: phri!news@nyu.edu (Roy Smith) To: tcp-ip@nic.ddn.mil Subject: How to discover current list of DNS root servers
If I want to find out the most current list of DNS root servers,
does it suffice to run nslookup and do the following?
> server suspected.root.server
> set type=ns
> .
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Mon, 7 May 90 14:24:36 -0500 (CDT) From: Wayne Richardson <wdr+@rchland.ibm.com> To: tcp-ip@nic.ddn.mil Subject: Re: Connect AS/400 and UNIX (TCP/IP). HOW?
Daniel,
In response to your specific questions:
1) Yes, there is a new LP for the AS/400 called TCP/IP Connectivity
Utilities. It started shipping 1/26/90. The S/36 is still only
available through Business Partners (like Mytek).
2) The AS/400 only attaches through 802.5 (Token-Ring) in the
initial release, but native Ethernet V2 and 802.3 are coming
very soon (there are SOD's for them now).
3) NFS Server is also a Statement-of-Direction, but is farther
out than 802.3.
For everyone, there is an excellent list of all the IBM platforms
and what they support in the way of TCP/IP, OSI, LU6.2, etc.
It is a list that came out when the RS/6000 was announced and is
titled, "IBM Interoperability for SAA and AIX environments".
The Date on it is 900215, and the Number is 290-070.
It talks about everything from SAA compilers to SNMP to X.400
and should be available through the IBM branches. It may answer
a lot of questions like yours.
Bob Dick
TCP/IP DCG 51E/015-2, (507) 253-3014
Rochester, Minnesota 55901
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 7 May 90 09:26:01 GMT From: mcsun!hp4nl!tnosoes!tom@uunet.uu.net (Tom Vijlbrief) To: tcp-ip@nic.ddn.mil Subject: A SUSPICIOUS SECURE GATEWAY
I modified a version of Phil Karns KA9Q internet package
so it acts as a suspicious secure gateway.
The goal of this gateway is to establish security of a local network
at the gateway instead of securing every host on your local network.
One would for example disallow excess to rlogin, rsh, ftp and telnet
because many users have bad passwords.
I'll make the binary and sources available to those who are
interested.
The README follows. (start reading at 'Security Features' if
you are only interested in the secure gateway extensions)
I would like to receive suggestions and comments about this package.
=====================================================================
Microsoft C 4.00 Changes to KA9Q
================================
The assembler files are translated to a format suitable for the
MASM assembler.
The clocktick rate has been increased from 1 tick per second to
10 ticks per seconds. (This is useful for fast transmission paths
like ethernet).
A little bug in the ping command (Concerning echo timing) has been fixed.
One can now specify TCP receive window and mss sizes which are different
from the send sizes. The is needed for dumb ethernet cards (3C501, 3C503)
which are easily overrun when a fast TCP peer (e.g. a Sun) sends bursts
of ethernet packets.
'tcp rwin 512' and 'tcp rmss 512' are appropriate values.
Some little improvements has been made to the TCP timeout mechanisms.
The file 'autoexec.net' is now searched for in the working directory and
subsequently in the root. (This allows easy customization for different
users).
Command line arguments are now interpreted as NET commands.
(It used to be the name of a startup file).
These commands are executed after the default startup file has been
read. Multiple command may be given when delimited by ';'.
The FTP server now recognizes printer names, so you can use NET
as a print server. (e.g.: put text lpt1).
Function keys are transmitted as \033[ sequences. (Useful for emacs, etc).
Four additional commands has been added:
funkeys [on|off]
funkeys on will disable Functionkey-10 so one can use emacs. Abort is
by means of CTRL-FN10 when funkeys are on.
rsh host command
will execute a shell command on the specified host by means of the
rexecd(8) or rshd(8) daemon.
uprsh file host command
acts like rsh but gives file as standard input.
buprsh file host command
acts like rsh but gives binary file as standard input.
Before a rsh command may be given you should identify yourself
by means of the name command. ("name username password" or
"name username RSH localname" for use of rshd instead of rexed).
examples:
DOS PROMPT> net rsh rainbow date
will show the date on the unix host rainbow and return to DOS.
DOS PROMPT> net uprsh \mail\greeting rainbow mail tom
will mail the contents of DOS-file \mail\greeting to tom from host
rainbow.
DOS PROMPT> net buprsh \dos\del.com rainbow cat ">" binfile
will copy the contents of DOS-file \dos\del.com to "binfile"
in your home directory on host rainbow.
A new server has been added. This server allows a tcp-stream to
a serial line (COMx) or the screen of a PC. (Could be used for a
remotely accessible printer).
start com 20000 1 silent
This starts the server which listens on port 20000 and directs all
incoming data to the first attached serial line. (Use 0 for the screen).
In the attach command one should specify the COM-port, baudrate, etc.
(E.g.: "attach asy 0x3f8 4 slip sl0 1024 576 9600").
If the fourth argument is omitted then diagnostic output will be
printed on the screen. (E.g.: "Incoming com session from.....")
A WD8003E ethernet driver has been added.
This version of the KA9Q internet package has been tested on a
IBM-AT communicating with Suns running SunOS 3.2/3.5/4.0.3 and Masscomps.
Slip has also been tested.
SMTP mail has been tested.
The log command now has an onscreen option which duplicates messages
on the screen. The logfile is now cyclic and will be rewritten after
500kB of messages. When net is started it will begin writing at the
start of the logfile. The best strategy is to start with a logfile
with a (random) contents of about 501kB. This will garantee that
messages can be logged even if the disk is completely full.
The NET program can act as a real gateway by giving an ethernet interface
a different IP address:
gateway ec0 [131.34.2.8]
On this gateway interface is only ping (= ICMP Echo Request) allowed.
SECURITY Features
=================
This version of net can act as a secure gateway between a local net
and an external IP network.
It allows connections to be initiated from the local network(s) to the
external network(s) but it disallows all connection attempts from the
external networks(s) the the local network(s).
Note that the gateway itself is always accesible over all interfaces.
So it can act as FTP server for the external insecure networks.
(This has ofcourse a negative impact on its performance as a
secure internetwork router.)
Be carefull to configure the file '\ftpusers` before you start FTP service
with the 'start ftp' command. Disallow access to the root directory or the
NET binary!
The insecure external network interface has to be attached with a name
that starts with 'Se' (Secure).
The local network(s) has to be specified with the command:
secure localnet <network>[/<bits>]
Example: secure localnet [140.24.67]/24
This will add the specified network to the list of protected (local) networks.
The protection is established by examination of packets which enter the network
over the 'Secure' interface:
1:
==
A packet which has an IP-source which matches one of the specified local
networks is considered a faked packet and is simply dropped. A warning
is written in the logfile.
2:
==
Every UDP packet with a port destination number < 1024 is rejected
with an ICMP Port Unreachable message.
3:
==
Every TCP packet with a port destination number < 1024 is rejected
with an ICMP Port Unreachable number.
4:
==
ICMP redirect packets are dropped.
5:
==
Source Routed packets are rejected with an ICMP Parameter Problem.
Local networks (or hosts) can be completely isolated from the external networks
by specifying a 'sink' route. The will reject EVERY packet with an
IP-source or IP-destination that matches the specified sink route with
an ICMP Host Unreachable message.
Example:
route add lonely sink
route add [140.24.67.128]/25 sink
A local network can be completely isolated with the exception of 1 or more
specific hosts by:
route add [197.25.45.0]/25 sink
route add [197.25.45.128]/25 sink
route add [197.25.45.212] ec0
route add [197.25.45.213] ec0
Tracing
=======
The command: secure trace on
will trace incoming packets on the 'Secure' interface. Remember that
turning trace on has a negative impact on routing performance.
Creating (dangerous) exceptions
===============================
It is possible to allow TCP connections to special hosts in order to
establish anonymous FTP connections or incoming mail.
This can be very dangerous because many older Unix FTP- and SMTP-
(= sendmail) daemons have dangerous security holes. A safe alternative
is to use a PC which runs this NET program as anonymous FTP server.
Many mail SMTP (and FTP) daemons have the famous Morris internet worm holes.
Do not allow connections until you are certain that your version is
secure. The safest way to assure this is to install the latest
Berkeley sendmail and ftpd sources which are publicly available.
The use of mail-aliases which resolve to programs (like |uudecode) is
also considered insecure.
This is an extract of:
===============================================================================
CERT Advisory
March 19, 1990
Internet Intruder Warning
-------------------------------------------------------------------------------
3) Exploit holes in sendmail.
Make sure you are running the latest sendmail from your vendor.
BSD 5.61 fixes all known holes that the intruder is using.
4) Exploit bugs in old versions of FTP; exploit mis-configured
anonymous FTP
Make sure you are running the most recent version of FTP which is
the Berkeley version 4.163 of Nov. 8 1988. Check with your vendor
for information on configuration upgrades. Also check
your anonymous FTP configuration. It is important to follow the
instructions provided with the operating system to properly configure
the files available through anonymous ftp (e.g., file permissions,
ownership, group, etc.). Note especially that you should not use your
system's standard password file as the password file for FTP.
9) Examine the /usr/lib/aliases (mail alias) file for unauthorized
entries. Some alias files include an alias named 'uudecode'; if this
alias exists on your system, and you are not explicitly using it, then
it should be removed.
=========================End of extract===============
After you have convinced yourself that your Unix servers are really
secure you can execute an secure allow command.
Example: secure allow mailhost TCP 25
This will allow TCP connections to be established over the Secure
interface to tcp port 25 on host 'mailhost'. 25 is the TCP port number
of the SMTP mail daemon.
The general syntax is:
secure allow <host/ALL> <TCP/UDP/RPC-UDP> <port/ALL> [source-host]
If no source-host is specified then it defaults to ALL.
RPC-UDP specifies a filter which examines UDP packets and determines
if these packets are RPC calls to a RPC based server. The port number
contains the RPC program number which should be filtered.
Example:
sec allow ALL RPC-UDP 100012 ALL
One can also specify disallows:
secure disallow <host/ALL> <TCP/UDP/RPC-UDP> <port/ALL> [source-host]
Example:
secure disallow ALL RPC-UDP ALL
NOTE that 'disallow' specifiers always overrule 'allow' specifiers
except 'allows' which have specified all four fields without any 'ALL' wildcard.
===============================================================================
Tom Vijlbrief
TNO Institute for Perception
P.O. Box 23 Phone: +31 34 63 562 11
3769 ZG Soesterberg E-mail: tnosoes!tom@hp4nl.nluug.nl
The Netherlands or: uunet!hp4nl.nluug.nl!tnosoes!tom
===============================================================================
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Mon, 7 May 90 11:26:21 N From: virchaux%CLSEPF51.BITNET@CUNYVM.CUNY.EDU (Jacques Virchaux) To: tcp-ip@nic.ddn.mil Subject: Upgrade kit LAN100 -> LAN150
Does anyone know if there is a kit available to upgrade a LanBridge 100 to a LanBridge 150. DEC offers an exchange rather expensive and there are only two PROMs to change and one wire to add !
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 7 May 90 12:54:32 GMT From: daemon@tut.cis.ohio-state.edu (Bob Dixon) To: tcp-ip@nic.ddn.mil Subject: IBM Batch Job Submission via tcp/ip
The ACC implementation of tcp/ip (called Access/Mvs) allows easy submission
of batch jobs via ftp, using the "site submit" option.
Bob
-------
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 7 May 90 14:39:42 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!umich!terminator!terminator.cc.umich.edu!bryan@ucsd.edu (Bryan Beecher) To: tcp-ip@nic.ddn.mil Subject: Re: How to discover current list of DNS root servers
In article <1990May6.230841.11143@phri.nyu.edu> roy@alanine.phri.nyu.edu (Roy Smith) writes: > > If I want to find out the most current list of DNS root servers, >does it suffice to run nslookup and do the following? > >> server suspected.root.server >> set type=ns >> . The only way to make sure you've got the current list of root servers is to pick up a copy of NETINFO:ROOT-SERVERS.TXT from the NIC. The suspected.root.server could have all kinds of bogus NS RR's for root in its cache along with the list of correct ones (which could be incomplete or incorrect itself). -- Bryan Beecher, U-M Information Technology Division (+1 313 747 4050) Domain: bryan@terminator.cc.umich.edu Path: mailrus!terminator!bryan
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: 7 May 90 16:13:53 GMT From: mcsun!cernvax!chx400!hslrswi!aut!huber@uunet.uu.net (Daniel Huber) To: tcp-ip@nic.ddn.mil Subject: UUCP over TCP/IP with HP9000/835S (HP-UX 7.0) ?????
I tried to set up uucp connections to other computers on our ethernet. But UUCP over TCP/IP seems not working with HP-UX 7.0 and 835S. I have HDB on both sides, or uucp version 2. HP9000/835S called is "aut" (HDB), other machine is NCR Tower 650 SysV.2 (HDB) called "telsys", or a Plexus P75 SysV.2 (uucp V2) called "autte". Here are my File entrys: Systems: telsys Any telsys Any nophone "" \d "" \r ogin: nuucp ssword: uucpuucp autte Any autte Any nophone "" \d "" \r ogin: nuucp ssword: uucpuucp Devices: I tried many different entrys telsys - - Any TCP or telsys TCP - Any TCP or telsys TCP - - TCP and more.... (similar entrys for autte) Permissions: #entry for system called "telsys" MACHINE=telsys LOGNAME=nuucp \ SENDFILES=yes REQUEST=yes CALLBACK=no \ READ=/usr/spool/uucppublic \ WRITE=/usr/spool/uucppublic \ COMMANDS=rmail:uux:uucp:pr #entry for system called "autte" MACHINE=autte LOGNAME=nuucp \ SENDFILES=yes REQUEST=yes CALLBACK=no \ READ=/usr/spool/uucppublic \ WRITE=/usr/spool/uucppublic \ COMMANDS=rmail:uux:uucp:pr And that's what Uutry means: # ~uucp/Uutry -r telsys /usr/lib/uucp/uucico -r1 -stelsys -x5 >/tmp/telsys 2>&1& tmp=/tmp/telsys mchFind called (telsys) conn(telsys) Device Type telsys wanted mlock - succeeded generic open failed, errno = 9 getto ret -1 Call Failed: CAN'T ACCESS DEVICE exit code 101 Conversation Complete: Status FAILED What's wrong? Does HP not support UUCP over TCP/IP ? Please e-mail, if you can help me. Thanks Daniel -- Daniel Huber Tel. +41 31 52 96 64 Ascom Autelca Fax. +41 31 52 77 45 CH-3073 Guemligen email: huber@aut.uucp Switzerland uucp: uunet!mcsun!cernvax!hslrswi!aut!huber
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 7 May 90 16:23:16 GMT From: hpfcso!hpldola!hpctdlb!hpctdkp!jeff@hplabs.hp.com (Jeff Hughes) To: tcp-ip@nic.ddn.mil Subject: Re: Re: question about caching in UDP based RPC
>Caching can be thought of as a kludge which is needed to try to give >UDP the same reliablity as TCP. Why not use TCP directly? I am not sure I follow your reasoning here. I believe that RPC provides the necessary retransmission feature. Therefore, it is RPC which is attempting to provide the reliability of TCP, caching is a separate issue. TCP may be more desirable because it is usually tied more directly to the operating system and would perform better under heavy loads than RPC/UDP (less likely to suffer retransmissions). Also, it would not double buffer an RPC request because it only keeps around 1 copy of an incoming packet. >Your cache will not ensure execute at most once behavior. Think about >a server and three clients. The server gets an RPC from client 1, >then 2, then 3. But it must trash the cache from client 1 in order >to store client 3's result. Now it gets a resend from client 1; it >will execute the service routine a second time. >The trick to caching UDP/RPC results it to cache exactly one result for >each client the server has. The cost is 8K per client, max. You never >need to cache more than one response from each client, since a client >will only send a new RPC only if the old one has been completed. This is a good idea. I believe there are some exceptions to the 1 reply per request rule, however. I believe the "spray" application will blast a host with a number of packets before requiring a reply. Also, keep in mind that this caching scheme will not work for RPC/TCP connections where batched RPC is being used. Again, multiple requests will be received before a response is required. *** These opinions are my own, blah, blah, blah *********** jeff@hpctdlb.hp.com
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 7 May 90 17:21:22 GMT From: news@psuvax1.cs.psu.edu (Daniel Ehrlich) To: tcp-ip@nic.ddn.mil Subject: Re: How to turn RIP off in Sun 3/50??
In article <9005050218.AA16274@ucbvax.Berkeley.EDU> CCECHAN@NUSVM.BITNET (Luther Chan) writes: Luther> Can anyone tell me how to turn the RIP in Sun 3/50 with Sun OS 3.3 or 3.4? Luther> Please tell where is the file contain the switch and the file name. If you run routed there are two choices. 1) Stop running routed, in which case you need to install a default route in rc.local at boot time. 2) Run routed with the '-q' switch which says do not under any conditions send RIP packets. Hope this helps. -- Dan Ehrlich <ehrlich@cs.psu.edu>/Voice: +1 814 863 1142/FAX: +1 814 865 3176
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 7 May 90 19:10:20 GMT From: bywater!arnor!news@uunet.uu.net To: tcp-ip@nic.ddn.mil Subject: RE: IP based job submission services..
John Curran (cei001@uc.msc.umn.edu) writes: > > Is there any sites that have a method for IP systems to submit MVS jobs? > > John Curran While IBM's TCP/IP for MVS does not provide this function today, we are currently working on code which will allow remote job submission via FTP and will distribute it via normal service channels when it is complete. Bill Rubin IBM TJ Watson Research
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 8 May 90 02:42:44 GMT From: CCECHAN@NUSVM.BITNET (Luther Chan) To: comp.protocols.tcp-ip Subject: SUN 3/50 PROBLEM: HELP
Hi, Thanks for the two reply on my previous question about turn the RIP off. Now I have a problem when the Sun 3/50 bootup, note I have not changed any- thing yet. The Sun 3/50 in here asked for Internet address after the selftest but unable to abort the request. The ethernet connector was terminated without any external connection. It act as a stand alone with a SCSI harddisk. The harddisk did fail once and later it was working again. The symptom was not the same as when the harddisk fail(was the handdisk unable to spin reported ). I can get into the PROM but I do not know what can I do except reset the system. Anyone has any idea what can I do to make the request of internet address by passed. (Note I have not been able to get to the login prompt). Luther Chan PS. I am from National University of Singapore. This message has nothing to do with the University. I am acting on my own opinion.
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 8 May 90 05:08:55 GMT From: mailrus!cs.utexas.edu!samsung!munnari.oz.au!ditmela!yarra!melba.bby.oz.au!gnb@tut.cis.ohio-state.edu (Gregory N. Bond) To: tcp-ip@nic.ddn.mil Subject: Re: help with ntp
In article <800@semto.sem.it> paolo@semto.sem.it (Paolo Zeppegno) writes:
I have a very small network, just a couple of machines (more to come
real soon now) running ultrix 3.1. I have compiled ntp and I would like
to have the clocks in my network synchronized. How do I do it? My brain
is probably dead, but the doc is very hard to understand. Keep in mind
that I have no access to any reference clock.
This is what I did here. I run a network of some 20 Suns.
I used the talking telephone clock over a period of a week or so to
find a server with the smallest clock drift (in free-running mode, no
ntp or rdate etc). It turned out (by luck) that my workstation has
the lowest drift of any I measured.
So I run my workstation as an NTP stratum-3 server, synced to the
local clock. A second stable workstation syncs to my machine and
its own internal clock (at stratum-4) so will take over the time
server role if my machine dies.
All the file servers on my net (and the backup master) are synced to
my machine, and to one other server.
All diskless clients are synced to their respective file servers.
This means that I can set the absolute time from my workstation, and
the rest of the net will track it. And my clock drifts only a few
seconds a week, so the effort is minimal.
Greg.
some ntp.conf files:
my workstation (the master):
----
# ntp.conf file for baby - the master clock server
precision -7
tickadj 10
# Use my clock as a reference
peer /dev/null LOCL 3 -5 local
------
One file server:
---
# ntp slave server configuration
tickadj 10
precision -6
peer baby
peer sid
---
The backup server
---
# bottle : the backup time server
tickadj 10
precision -6
peer baby
peer melba
peer /dev/null LOCL 4 -5 local
-----
--
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
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: 8 May 90 05:23:36 GMT From: cs.utexas.edu!execu!sequoia!sequoia.execu.com!dewey@tut.cis.ohio-state.edu (Dewey Henize) To: tcp-ip@nic.ddn.mil Subject: Broadcasts and YP service(s)
Perhaps the collective wisdom of the net will come to my ignorant aid... Our network is an 'interesting' collection of various machines, including Suns, a Sequent, and an HP. We are running YP (NIS now I guess). In the past, we used one of the Suns, the Sequent, and the HP (under HP-UP) as YP servers. The Sun was/is the master, the other two slaves. Things went pretty well until recently when we started added more machines and we noticed some pretty big slowdowns. Tracking things for a while, it became apparent that machines that had bound to the HP for a YP server were getting slowed down a LOT by the responses from it. Since it was already as unloaded as possible, I wanted to take it out of the YP server business (I've got other machines I can draft later). HOWEVER, if it doesn't come up with the ypserv daemon, it doesn't seem to be able to find a ypserver anywhere. Once they are up, however, I can use ypset to redirect them to using other servers and kill off the HP's ypserv daemon and go on merrily about my business. The only thing I can figure out is that the sequent and sun use a broadcast of 130.211.200.0 (class B, subnetted) while the HP appears to use 130.211.200.255. I can't figure out any way to make the HP use anything else, since the ifconfig on it doesn't know about the broadcast parameter. Ideas? Suggestions? Help!? Thanks in advance. I'm sure this is in TFM somewhere, but I haven't been able to find it after looking all afternoon. Dewey
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: Tue 8 May 90 13:32:24-PDT From: William "Chops" Westfield <BILLW@mathom.cisco.com> To: shelby!cis!interran@eos.arc.nasa.gov Cc: tcp-ip@nic.ddn.mil Subject: Re: pinging a remote TCP port to see if it's in use
I want the ping to tell me whether or not an attempt to connect to the
TCP port would succeed (i.e., whether or not the TCP port's in use).
How do I find out if a given TCP port on a given host is in use without
affecting the remote program's behavior?
This is next to impossible.
The problem is that in theory, you can have any number of connections to
a particular tcp port, as long as the source host and/or port are different.
Thus you can have many connections to the SMTP or Telnet ports of a host,
and you can't easilly tell how many more will be accepted.
Of course, some host/port combinations are "stupid", and will accept only
one connection to a particular port. (The obvious example being a port
tied to a particular line on a tcp terminal server.) If you KNOW that
the port you are trying to reach is of this type, your best bet may be
to use a network managment protocol (eg SNMP) to see if that port already
has a connection. Of course, this may be more expensive in many ways than
just trying the TCP connection...
Bill Westfield
cisco Systems.
-------
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: Tue, 8 May 90 14:52:04 -0400 (EDT) From: Drew Daniel Perkins <ddp+@andrew.cmu.edu> To: tcp-ip@nic.ddn.mil, phoenix!phoenix.princeton.edu!eho@princeton.edu (Eric Ho) Subject: Re: PPP ??
> Excerpts from internet.tcp-ip: 4-May-90 PPP ?? Eric Ho@princeton.edu (264) > I'm not sure if these are the right newsgroups to send to but I'm interested > in knowing current developments concerning PPP. I would be very much > appreciated if anyone can give me any pointers on this. The most recent developments: 1. The IESG has recommended to the IAB that PPP be advanced to Draft Standard status. 2. Draft proposals for 802.3 and 802.5 Bridging and OSI Network Layer over PPP have been submitted. 3. Two PD implementations are available, one for 4.3 BSD the other for KA9Q on PCs. Another two for SunOs will become available shortly. 4. A number of manufacturers have already implement/ported or plan to implement/port PPP very soon. Drew
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: Tue, 08 May 90 21:09:18 -0700 From: wrs!yuba!hwajin@uunet.UU.NET (Hwa Jin Bae) To: uunet!mathom.cisco.com!BILLW@uunet.UU.NET Cc: shelby!cis!interran@eos.arc.nasa.gov, tcp-ip@nic.ddn.mil Subject: Re: pinging a remote TCP port to see if it's in use
> I want the ping to tell me whether or not an attempt to connect to the > TCP port would succeed (i.e., whether or not the TCP port's in use). > How do I find out if a given TCP port on a given host is in use without > affecting the remote program's behavior? > > This is next to impossible. > using ping which uses ICMP for something like this is inconsistent. ICMP is at the same level as IP (network layer in osi terms) and has no relevant information about the transport level concept of a "port" per se although some transport protocol implementations make use of ICMP "port unreachable" message type to tell the remote machine when there's no one bound to a particular target port requested by incoming packets. > The problem is that in theory, you can have any number of connections to > a particular tcp port, as long as the source host and/or port are different. > Thus you can have many connections to the SMTP or Telnet ports of a host, > and you can't easilly tell how many more will be accepted. > i think the original question is asking for a way to tell whether or not it is possible to make a connection. a connection attempt will hang if there's an existing connection between TCP sockets that are bound to the same combinations of the port numbers (i.e. the case where the source port and destination port combination is already being used by an existing connection between the machines in question). that is, i don't think he's asking for the number of max connections a server process is willing to accept on a given listener port. assuming that i'm interpreting his question correctly, i'll say that pretty much the only way is to use the non-blocking I/O on the socket (via FIONBIO ioctl command) and selecting on the writing side of the socket with a set time limitation (an argument to select). you'll do a ioctl of FIONBIO on the socket and then issue a connect on the socket and then select on the writing side for a give time. if the select times out you have not successfully connected to the remote machine within a given amount of time. you can try two things at this time: (a) increase the time interval, or (b) try to use a different port number on your side. and try again until you succeed. this procedure will help when the remote machine refuses time out zombie sockets that are hung up by some previous connections that are terminated inconsistenly. hwajin, wind river systems
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 8 May 90 09:45:56 GMT From: shelby!cis!interran@eos.arc.nasa.gov (John Interrante) To: tcp-ip@nic.ddn.mil Subject: pinging a remote TCP port to see if it's in use
I would like to "ping" a program listening to a TCP port to find out if it's alive without actually creating a connection to that program's TCP port. I want the ping to tell me whether or not an attempt to connect to the TCP port would succeed (i.e., whether or not the TCP port's in use). How do I find out if a given TCP port on a given host is in use without affecting the remote program's behavior? (I don't want the remote program to have to accept a new connection and then tear it down.) John Interrante interran@lurch.stanford.edu
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: Tue, 08 May 90 16:48:15 PDT From: Paul Mockapetris <pvm@ISI.EDU> To: swrinde!zaphod.mps.ohio-state.edu!samsung!umich!terminator!terminator.cc.umich.edu!bryan@ucsd.edu (Bryan Beecher) Cc: tcp-ip@nic.ddn.mil Subject: Re: How to discover current list of DNS root servers
> In article <1990May6.230841.11143@phri.nyu.edu> roy@alanine.phri.nyu.edu (Roy Smith) writes: > > > > If I want to find out the most current list of DNS root servers, > >does it suffice to run nslookup and do the following? > > > >> server suspected.root.server > >> set type=ns > >> . > > The only way to make sure you've got the current list of root > servers is to pick up a copy of NETINFO:ROOT-SERVERS.TXT from > the NIC. The suspected.root.server could have all kinds of > bogus NS RR's for root in its cache along with the list of > correct ones (which could be incomplete or incorrect itself). > -- > Bryan Beecher, U-M Information Technology Division (+1 313 747 4050) > Domain: bryan@terminator.cc.umich.edu Path: mailrus!terminator!bryan I'd maintain that doing the query is EXACTLY the right way to get the current list of root servers IF the suspected.root.server is chosen from a reputable set. Just as you know that NIC.DDN.MIL is the host to FTP the NETINFO:ROOT-SERVERS.TXT file from, you could just as easily know one machine that is a root server, say NS.NIC.DDN.MIL or whatever. paul
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: Tue, 8 May 90 14:37:09 EDT From: BDK@UNB.CA To: TCP-IP@NIC.DDN.MIL Subject: Re: IP based job submission services..
What about retreiving jobs? Is it in the same package? Brian Kaye University of New Brunswick > > While IBM's TCP/IP for MVS does not provide this function today, we > are currently working on code which will allow remote job submission > via FTP and will distribute it via normal service channels when it is > complete. > Bill Rubin > IBM TJ Watson Research
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: Tue, 08 May 90 09:36:05 SST From: Luther Chan <CCECHAN%NUSVM.BITNET@CUNYVM.CUNY.EDU> To: Vivian Neou <TCP-IP@SRI-NIC.ARPA> Subject: SUN 3/50 PROBLEM: HELP
Hi, Thanks for the two reply on my previous question about turn the RIP off. Now I have a problem when the Sun 3/50 bootup, note I have not changed any- thing yet. The Sun 3/50 in here asked for Internet address after the selftest but unable to abort the request. The ethernet connector was terminated without any external connection. It act as a stand alone with a SCSI harddisk. The harddisk did fail once and later it was working again. The symptom was not the same as when the harddisk fail(was the handdisk unable to spin reported ). I can get into the PROM but I do not know what can I do except reset the system. Anyone has any idea what can I do to make the request of internet address by passed. (Note I have not been able to get to the login prompt). Luther Chan PS. I am from National University of Singapore. This message has nothing to do with the University. I am acting on my own opinion.
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 8 May 90 12:46:12 GMT From: mcsun!unido!quando!wichert@uunet.uu.net (Peter Wichert) To: tcp-ip@nic.ddn.mil Subject: Looking for fast file-transfer on ethernet
Hi,
I want to do a fast file-transfer between hosts using ethernet.
I have implemented a file-transfer based on the BSD socket interface
with TCP protocol. My problem is that the transmission rate is too slow,
so to speed things up I want to do the same with UDP protocol, but UDP
is unreliable.
What I'm looking for is an interface that supports reliable byte/sec streams
using UDP.
What does rcp use?, it is a lot faster than ftp'ing?
Any ideas ????
Many Thanks, for any replies.
Please DON'T send sources, send me mail first...
--
Peter Wichert UUCP: {backbone}!unido!quando!wichert OR wichert@quando.uucp
Quantum GmbH Bitnet: UNIDO!quando!wichert OR wichert%quando@UNIDO(.bitnet)
Dortmund internet: wichert%quando%unido.UUCP@mcsun.cwi.nl
Germany internet: wichert@quando.quantum.de
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: 8 May 90 14:15:34 GMT From: sparkyfs!arsocomvax.socom.mil!news@ames.arc.nasa.gov (Ted Nolan) To: tcp-ip@nic.ddn.mil Subject: Re: PC-LAN connection to Usenet
>In article <4950@netxcom.DHL.COM> cmoussav@dhlmis.DHL.COM (C. Ognibene-Moussavi) writes: >I am asking the following question on behalf of my husband - at his work >there is only a LAN - he would like to know what hardware, software and >phone number he needs for a dial-up connection to Usenet - he would like >to be able to read the newsgroups and post to them as well. I think Lauren Weinstein wrote a complete netnews/uucp (commercial) package for DOS PCs a couple of years ago. It may be that you could put this on one PC and have the rest get at it over the LAN. According to whois, his address is: Weinstein, Lauren (LW2) Lauren@RAND.ORG Vortex Technology P.O. Box 1323 Topanga, CA 90290 (213) 455-9300 Ted Nolan ted@usasoc.soc.mil
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: 8 May 90 15:23:10 GMT From: usc!srhqla!nrcvax!bvs@ucsd.edu (Bill Versteeg) To: tcp-ip@nic.ddn.mil Subject: Re: pinging a remote TCP port to see if it's in use
In article <INTERRAN.90May8024556@lurch.Stanford.EDU> interran@lurch.Stanford.EDU (John Interrante) writes: >I would like to "ping" a program listening to a TCP port to find out >if it's alive without actually creating a connection to that program's >TCP port. If the machine in question speaks SNMP, the information is available. The easiest way to get it is using "snmpnetstat host_name community_string -a". If you don't have snmpnetstat, a snmpwalk of the tcp group will do. If the machine does not speak SNMP, you could log onto the machine and use "netstat -a". Yet another example of why EVERYONE SHOULD IMPLEMENT SNMP!!!! Bill VerSteeg -- Bill VerSteeg Network Research Corporation 170 Watermill Falls Alpharetta Ga. 30201 bvs@nrc.com
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: 8 May 90 15:33:31 GMT From: usc!cs.utexas.edu!oakhill!guri@ucsd.edu (Gurvinder Singh Ahluwalia) To: tcp-ip@nic.ddn.mil Subject: NNTP-socket-based News Interface (Eg: "rrn")
I am looking for a NNTP-based news reader interface like "rrn".
Currently we have a "rrn" binary in place [as also the "rn"
scheme]. The "rrn" interface we have is either not complete
or terribly out-dated unless what we suffer from is due to an
inherent drawback of "rrn". I do not know.
"rrn" we have does not give any WRITE capabilites to users, i.e.
one cannot follow-up ('f' or 'F') or reply ('r' or 'R') to a
posting. Quite logically it follows that one also cannot 'postnews'
through "rrn".
What I am interested in is any or all of the following:
1. A cleaner and more complete implementation of "rrn",
and/or more generally,
2. An IP socket-based (NNTP or other) Bulletin Board/News Reader
interface that works.
Are there any out there running or aware of such implementations?
We have the GNU Emacs package that comes with a built in
NNTP-based news reader interface. Emacs is something that many
do not use and we are looking for a more common-place alternative
that would keep the user-learning curves and migration to new
Bulletin Board features simple and minimal.
I would also like to hear if the capabilities we lack in "rrn"
are endemic to it or is there someone running "rrn" with write
capabilities (say, comparable to "rn") other than thru GNU Emacs.
Also, it is not clear whether the "rrn" deficiency we face is in
the client part or server or both.
I would prefer EMail. If there is interest, I shall consolidate
responses and post.
-----
Gurvinder Ahluwalia Internet: guri@apogee.sps.mot.com
Software Engineer UUCP : <world>oakhill!apogee!guri@cs.utexas.edu
Global Networking Phone : 512/891-3310
MOTOROLA - SPS
Austin, TX 78735
-----
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: 8 May 90 18:56:37 GMT From: usc!cs.utexas.edu!oakhill!guri@ucsd.edu (Gurvinder Singh Ahluwalia) To: tcp-ip@nic.ddn.mil Subject: Re: pinging a remote TCP port to see if it's in use
In article <INTERRAN.90May8024556@lurch.Stanford.EDU> interran@lurch.Stanford.EDU (John Interrante) writes:
>I would like to "ping" a program listening to a TCP port to find out
>if it's alive without actually creating a connection to that program's
>TCP port. I want the ping to tell me whether or not an attempt to
>connect to the TCP port would succeed (i.e., whether or not the TCP
>port's in use).
... stuff deleted ...
>
>John Interrante interran@lurch.stanford.edu
I don't belive you can do this thru ping. ping is an echo
program at the Network Layer (IP) (without a Transport Layer,
if you may). It does not take port connections into its folds.
It uses "raw sockets" to interface between the Application and
Network Layers.
If you figure out a something to the contrary, I would like
to know.
Gurvinder.
----------
Gurvinder Ahluwalia Internet: guri@apogee.sps.mot.com
Software Engineer UUCP : {}oakhill!apogee!guri@cs.utexas.edu
Global Networking Phone : 512/891-3310
Motorola SPS
Austin, TX
----------
#include <std/disclaimer>
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: 8 May 90 21:07:26 GMT From: cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!prls!pyramid!infmx!briand@tut.cis.ohio-state.edu (brian donat) To: tcp-ip@nic.ddn.mil Subject: gated
Hello, Some time ago, somebody brought up a discussion aobut Dave Mill's Fuzzballs. I'd like to dig up some further info on cost metrics, so if anybody knows of any good references on this topic, could you please advise me. Also, I don't seem to be able to access 'devvax.tn.cornell.edu' and would like to obtain gated. Can anybody help me here? --briand
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: 8 May 90 21:15:29 GMT From: ftp!fks@BLOOM-BEACON.MIT.EDU (Frances Selkirk) To: tcp-ip@nic.ddn.mil Subject: Re: Tektronix emulation
In article <1306@excelan.COM>, manoj@excelan.COM (manoj @ Prod Mktg) writes: > With LAN WorkPlace for DOS (Novell's TCP/IP for DOS), these are some of the > 3rd party term emulators.. > walker richer quinn, seattle, WA > kea systems, vancouver , canada > softronics, > grafpoint, saratoga, ca > persoft, > polygon, > diversified computer systems These packages are a good way to get many terminal emulator, especially those for graphics terminals. FTP Software's PC/TCP also supports INT-14 emulators. Any other compatible telnets/rlogins out there? To the list of companies making INT-14 emulators, you should add Pericom and Mitek. Again, any others present or known? Enjoy! Frances -- Frances Kirk Selkirk info@ftp.com (617) 246-0900 FTP Software, Inc. 26 Princess Street, Wakefield, MA 01880
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: 8 May 90 22:09:18 GMT From: oliveb!orc!bu.edu!bu-it!kwe@apple.com (Kent England) To: tcp-ip@nic.ddn.mil Subject: Re: A SUSPICIOUS SECURE GATEWAY
In article <1158@tnosoes.UUCP>, tom@tnosoes.UUCP (Tom Vijlbrief) writes: > I modified a version of Phil Karns KA9Q internet package > so it acts as a suspicious secure gateway. > > The goal of this gateway is to establish security of a local network > at the gateway instead of securing every host on your local network. > > One would for example disallow excess to rlogin, rsh, ftp and telnet > because many users have bad passwords. > Source address "authentication" is very weak security. If you allow any ftp connections to any host on your net, a way will be found to attempt ftp connections to all your hosts. The path to good internet security is to build security hooks into the protocol suite and the applications software and implement a robust authentication protocol, like Kerberos or the Privacy Enhanced Mail protocol. There are no shortcuts. [Jon Rochlis from MIT has pounded this point of view into my head.] The IETF is addressing this need by requiring security (among other things) to be accounted for in every new protocol proposal. Sort of like a security environmental impact statement. Steve Crocker of Trusted Information Systems is the Area Director of Security in the IETF. He is worrying about all kinds and levels of security. This is a very active area of research in the IETF, in other words. It is affecting PPP, OSPF, BGP to name a few new protocols. Stay tuned. Meanwhile, if you want to use this modified KA9Q, just be aware of how weak this approach really is. --Kent
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: Wed, 09 May 90 14:13:08 -0700 From: Marshall Rose <mrose@cheetah.nyser.net> To: johns@hpwade.UUCP Cc: tcp-ip@nic.ddn.mil Subject: Re: pinging a remote TCP port to see if it's in use
Actually, there are at least three non-proprietary implementations of SNMP available, of which you described one. Parties interested in hearing more about SNMP are invited to join the snmp list (drop a note to snmp-request@nisc.nyser.net.) /mtr
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: Wed, 09 May 90 14:32:55 -0700 From: Marshall Rose <mrose@cheetah.nyser.net> To: HAGGAR@bnr.ca (Haggar Alsaleh, H.) Cc: tcp-ip@nic.ddn.mil Subject: Re: IEEE 802.1 Network Management.
There is a "transmission working group" that is working on defining MIBs
for things below the IP (e.g., 802.3). If you want to get on the
mailing list, send a note to trans-wg-request@nisc.nyser.net.
For the last couple of years, it has generally been felt that management
protocols specific to the data-link layer are not all that helpful. The
reason is:
If you have a well-engineered management protocol for your protocol
suite (e.g., the SNMP for the Internet suite of protocols), then the
additional amount of work required to implement the protocols
between the data-link protocol and the management protocol, should
be quite small. In the case of the SNMP, you implement both the IP
and the UDP. Minimal implementations of these are straight-forward.
Once you have these protocols in place, management requests can be
fielded across an internet, instead of restricting them to the local
LAN. As such, you can do remote management of your LAN using the
same applications and techniques that you use locally. This gives
you tremendous leverage!
Of course, not all management protocols are this well-engineered.
As such, other management frameworks may not enjoy this advantage.
In brief, true power in a well-designed system comes from simplicity
in design, not over-wrought complexity.
So, the answer to your question is: look at trans-wg if you're
interested in 802 managed objects ... and use the SNMP to manage them!
/mtr
Thank-you for your support! --the SNMP PAC (-:
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: Wed, 9 May 90 11:12:13 GMT-0400 From: ad@cis.brown.edu (Arif Diwan) To: TCP-IP@nic.ddn.mil Subject: Returned mail: User unknown
>>>Original Msg<<<
Most TCP/IP's that I have abused (er ah used) have a feature that lets you say telnet
foo when you mean telnet foo.bar.com. That is they add the current domain to the
name if htere are no dots (some do even if there are). Others there is a list of domains
to append to the hostname when trying. The only draw back to doing a "hostname
foo.bar.com" in your rc.local (or where eveer) file is that the default csh prompt is
foo.bar.com%" rather than "foo%".
>>EOM<<<
Actually the default prompt is usually set in the .cshrc file and one could use
something similar to :
set host="`whoami`@`hostname`"
set host=`expr $host : '\([@a-zA-Z0-9]*\)'`
set prompt="${host}> "
and the prompt would not be a problem either.
We have over a 1000 nodes and we use fully qualified 4 level domain names in most
cases (We use 3 level names for major routers and just Brown.EDU for our main
nameserver/router/etc). Within each sub-domain, we only have to specify the "1st"
label, and never more than 2 labels to refer to any host within Brown.EDU using the
usuall network client programs (telnet, ftp etc). We are using bind4.8.2+ resolver code.
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: Wed, 9 May 90 11:39:32 GMT-0400 From: ad@cis.brown.edu (Arif Diwan) To: tcp-ip@nic.ddn.mil Subject: GENTER-ADAM.AF.MIL && BIND && root nameservers ...
>>>Original Msg<<< .... there appears to be a nasty bug in Bind 4.8.1 ... >>>EOM<<< you should use bind4.8.2. You can get bind4.8.2.tar.Z from netlab.cis.brown.edu. It is in the pub directory.
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: Wed, 9 May 90 11:45:56 GMT-0400 From: ad@cis.brown.edu (Arif Diwan) To: tcp-ip@nic.ddn.mil Subject: Find out the current list of root nameservers
Roy - You got it right: nslookup > server suspected.root.server > set type=ns > . This will give you the suspected server's current root cache. You may want to compare that with ns.nic.ddn.mil
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: 9 May 90 05:24:17 GMT From: dna@psuvax1.cs.psu.edu (Douglas N. Arnold) To: tcp-ip@nic.ddn.mil Subject: Re: PPP ??
> ... current developments concerning PPP. I would be very much > appreciated if anyone can give me any pointers on this. >> Two PD implementations are available, one for 4.3 BSD the other for >> KA9Q on PCs. Another two for SunOs will become available shortly. Available where? -- Douglas N. Arnold dna@math.psu.edu Dept. of Mathematics, Penn State Univ. (814) 865-0246
-----------[000087][next][prev][last][first]---------------------------------------------------- Date: 9 May 90 07:20:09 GMT From: mcsun!hp4nl!tnosoes!tom@uunet.uu.net (Tom Vijlbrief) To: tcp-ip@nic.ddn.mil Subject: Re: A SUSPICIOUS SECURE GATEWAY
kwe@bu-it.bu.edu (Kent England) writes: >In article <1158@tnosoes.UUCP>, tom@tnosoes.UUCP (Tom Vijlbrief) writes: >> I modified a version of Phil Karns KA9Q internet package >> so it acts as a suspicious secure gateway. >> >> The goal of this gateway is to establish security of a local network >> at the gateway instead of securing every host on your local network. >> >> One would for example disallow excess to rlogin, rsh, ftp and telnet >> because many users have bad passwords. >> > Source address "authentication" is very weak security. If you >allow any ftp connections to any host on your net, a way will be found >to attempt ftp connections to all your hosts. What do you mean ? Can you be a little bit more specific? Authentication is not done on source address at all. One should disallow all FTP connections from the outside world, except to a special host. If this host is the PC which runs the gateway software than you can be sure that NO ONE WILL EVER access a FTP server on any other host on your local network from the outside internet. The idea is to make inaccessible well known ports from the outside internet except those you need to establish mail and FTP connections. Filtering is done on destination port number, there is no way you can break this if it is properly implemented. Prove me wrong. > The path to good internet security is to build security hooks into >the protocol suite and the applications software and implement a robust >authentication protocol, like Kerberos or the Privacy Enhanced Mail protocol. >There are no shortcuts. [Jon Rochlis from MIT has pounded this point >of view into my head.] This is nice but it does not help when it is not implemented in vendors software. Kerberos and other authentication protocols are needed when possible intruders have access to your local physical layer (your ethernet backbone). If you don't need or want remote logins and remote shells to be initiated from the outside world at all, then there is no need for kerberos or other more secure protocols. My approach is sufficient and works for all TCP/IP hosts on your local network without the need to install new software. Again prove me wrong. > The IETF is addressing this need by requiring security (among >other things) to be accounted for in every new protocol proposal. Sort >of like a security environmental impact statement. Steve Crocker of >Trusted Information Systems is the Area Director of Security in the >IETF. He is worrying about all kinds and levels of security. This >is a very active area of research in the IETF, in other words. It >is affecting PPP, OSPF, BGP to name a few new protocols. Stay tuned. > Meanwhile, if you want to use this modified KA9Q, just be >aware of how weak this approach really is. I hope you can indicate REAL holes in my security approach, otherwise your statement is really weak, instead of the modified KA9Q. (I don't want to be offensive but I really figured out many different ways of attack and iterated my gateway implementation till it was secure. I really like (constructive) criticism, so I can make it better). > --Kent Tom
-----------[000088][next][prev][last][first]---------------------------------------------------- Date: Wed 9 May 90 14:25:11-PDT From: William "Chops" Westfield <BILLW@mathom.cisco.com> To: usc!cs.utexas.edu!oakhill!guri@ucsd.edu Cc: tcp-ip@nic.ddn.mil Subject: Re: pinging a remote TCP port to see if it's in use
Please, people: "ping" is not a specific network protocol - it is a concept. The unix "ping" command happens to use ICMP ECHO packets, but there are also XNS, CLNS, Appletalk, Chaosnet, PUP equivilents of ping, as well as conceptually similar concepts for UDP, TCP, and so on. The original request asked for a way of determining the status of a particular TCP port, which is more or less within the scope of "pinging" - I don't think there was any intentiion of using ICMP for this. BillW -------
-----------[000089][next][prev][last][first]---------------------------------------------------- Date: 9 May 90 08:32:28 GMT From: usc!samsung!munnari.oz.au!bruce!goanna!dmh@ucsd.edu (Darren Hosking) To: tcp-ip@nic.ddn.mil Subject: Too many tftp requests causes "Connection Refused"
I have cross posted this to comp.windows.x because the problem was highlighted by a lab of X terminals and someone may have had a similar problem. We have a lab full of X terminals that all use tftp to fetch the downloadable server and fonts. If I start one X terminal at a time the terminal boots up (and fetches its fonts) without any problems, however, if I start several at once the machine that they are all trying to tftp from comes up with the following console messages: May 7 15:29:41 yallara.oz tftpd[2009]: tftpd: read: Connection refused May 7 15:29:42 yallara.oz tftpd[2015]: tftpd: read: Connection refused May 7 15:29:44 yallara.oz tftpd[2019]: tftpd: read: Connection refused ... May 7 15:29:54 yallara.oz tftpd[2072]: tftpd: read: Connection refused May 7 15:29:55 yallara.oz inetd[169]: tftp/udp server failing (looping), servic e terminated After which inetd will no longer run tftpd. The X terminals report errors when the above happens. This problem occurs on an Encore Multimax running UMAXV 2.2J, a VAX 11/750 running 4.3 BSD, and a Sony 1850 running 4.3 BSD. However, the problem does NOT occur on an Encore running 4.3 BSD (R4_0.0). Tftpd appears to be failing in recvfrom() and is returned "Connection Refused". My question is this, why do lots of tftp's work on one machine and not most others? Is there are kernel configurable parameter that will increase the backlog of UDP packets (if this is the problem)? The problem can be recreated without using X terminals by using two shell scripts that generates several tftp requests for a small file on a particular machine in the background. For example: #! /bin/csh # Filename: t # foreach f (1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0) tf & end #! /bin/csh # Filename: tf # tftp MACHINENAME << EOF get /FILENAME q EOF Thanks in advance, dmh Darren Hosking ACSnet: dmh@goanna.oz Department Of Computer Science ARPA: dmh%goanna.oz.au@uunet.uu.net RMIT CSNET: dmh%goanna.oz.au@australia GPO Box 2476V UUCP: ...!uunet!goanna.oz.au!dmh Melbourne Vic., Australia 3001
-----------[000090][next][prev][last][first]---------------------------------------------------- Date: Wed, 9 May 90 13:09:00 EDT From: Haggar (H.) Alsaleh <HAGGAR@BNR.CA> To: tcp-ip@nic.ddn.mil Subject: IEEE 802.1 Network Management.
Is anybody looking at alternative network management protocol
such us IEEE 802.1b, I have the standard but I need more info
If you could help or know where I could find it, I would very
much appreciate it.
Thanks
Haggar Alsaleh
1150 E. Arapho Rd.
Richardson, TX 75081.
(214) 997-4806.
Haggar@bnr.ca
-----------[000091][next][prev][last][first]---------------------------------------------------- Date: 9 May 90 12:52:13 GMT From: hpda!hpwala!hpwade!johns@ucbvax.Berkeley.EDU (John Silva) To: tcp-ip@nic.ddn.mil Subject: Re: pinging a remote TCP port to see if it's in use
In article <INTERRAN.90May8024556@lurch.Stanford.EDU> interran@lurch.Stanford.EDU (John Interrante) writes: >I would like to "ping" a program listening to a TCP port to find out >if it's alive without actually creating a connection to that program's >TCP port. I want the ping to tell me whether or not an attempt to Well, this may not exactly be the answer you are looking for but ... If your target machine is running SNMP (i.e. snmpd) and you have the snmpwalk program on your source machine you can do the following to query SNMP for an available service : $ snmpwalk <target> <community-name> \ tcp.tcpConnTable.tcpConnEntry.tcpConnState.0.0.0.0.25 Name: tcp.tcpConnTable.tcpConnEntry.tcpConnState.0.0.0.0.25.0.0.0.0.0 INTEGER: listen(2) (This example would check to see if the SMTP [sendmail] port is listening. To check for another service port, just put its number in place of the 25.) I believe that the SNMP package is available from CMU (I do not have the FTP address available). >John Interrante interran@lurch.stanford.edu Hope this helps, John Silva johns@hpwarf.hp.com
-----------[000092][next][prev][last][first]---------------------------------------------------- Date: 9 May 90 15:18:14 GMT From: grebyn!pat@decuac.dec.com (Pat Bahn) To: tcp-ip@nic.ddn.mil Subject: Re: IP based job submission services..
JTM in OSI does this, course that means someone would actually have to implement it. then put in the bridges to TCP. Any volunteers? -- ============================================================================= Pat @ grebyn.com | If the human mind was simple enough to understand, 301-948-8142 | We'd be too simple to understand it. -Emerson Pugh =============================================================================
-----------[000093][next][prev][last][first]---------------------------------------------------- Date: 9 May 90 17:34:20 GMT From: pollux!ccruss@ucdavis.ucdavis.edu (Russ Hobby) To: tcp-ip@nic.ddn.mil Subject: Re: Ingres certification of TCP/IP
Hi Henry,
Funny you should bring this up. Although I can't answer you specific
question on Ingres, I do have a comment. One problem we have with SQL
databases running over TCP/IP networks is that each vendor is starting
to do it their own way. From the users porint of view, this won't do!
Thus, I have just formed an Internet Engineering Task Force Working
Group to standardize SQL over IP. The WG has the goals of getting the
vendors together and agreeing on a standard. After that the WG will
move on to Z39.50 over the Internet.
The chair of the WG is Cliff Lynch and if you are interested following the
WG or partisipating, you can write to him at lynch@postgres.berkeley.edu
Russ Hobby INTERNET: rdhobby@ucdavis.edu
IETF Area Director - Applications BITNET: RDHOBBY@UCDAVIS
UUCP: ...!ucbvax!ucdavis!rdhobby
-----------[000094][next][prev][last][first]---------------------------------------------------- Date: 9 May 90 18:29:03 GMT From: eru!luth!sunic!tut!jh@bloom-beacon.mit.edu (Juha Heinanen) To: tcp-ip@nic.ddn.mil Subject: Re: PPP ??
In article <YaFlJIe00iU4E5A3w0@andrew.cmu.edu> ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) writes: 2. Draft proposals for 802.3 and 802.5 Bridging and OSI Network Layer over PPP have been submitted. Any idea if the latter is going to be submitted also to ISO? The current ISO standard (8880-3) lists ISO 8473 over ISO 7809 BAC in the Point-to-Point case. -- -- Juha Heinanen, Tampere Univ. of Technology, Finland jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)
-----------[000095][next][prev][last][first]---------------------------------------------------- Date: 9 May 90 20:44:09 GMT From: sgi!pchin%midautumn.wpd.sgi.com@ucbvax.Berkeley.EDU (Phil Chin) To: tcp-ip@nic.ddn.mil Subject: Looking for Kermit Protocol Manual
Any one know where I can get the following manuals from? "Kermit, A File Transfer Protocol", Frank de Cruz "Kermit Protocol Manual", Frank de Cruz Thanks Philip
-----------[000096][next][prev][last][first]---------------------------------------------------- Date: 9 May 90 21:04:41 GMT From: att!cbnewsh!fsi@ucbvax.Berkeley.EDU (furrokh.s.irani) To: tcp-ip@nic.ddn.mil Subject: comparision of sockets to tli
Does anyone have a comparision of the 'TLI' interface versus the 'socket' interface? Please email to att!odyssey!fsi. Thanks v. much. -Furrokh S. Irani
-----------[000097][next][prev][last][first]---------------------------------------------------- Date: 9 May 90 21:52:51 GMT From: cbmvax!grr@uunet.uu.net (George Robbins) To: tcp-ip@nic.ddn.mil Subject: Lantastic vs. the World - Problems?
One of our user areas here has decided that they want to use one of those
PC network products call "Lantastic" with WD8003 Ethernet cards. Up to
now our LAN has been exclusivly TCP/DECnet/XNS and we've standardized on
3c503 cards for PC's.
The apparent reason for going with the WD8003 cards is lack of Netbios
support for the 3c503. I find this somewhat hard to argue with.
Has anyone had any interoperbility problems with Lantastic and traditional
protcols on the same Ethernet? I know there shouldn't be, but I'd like be
sure before these guys commit (me) to a bunch of new hardware and software.
Is the Lantastic stuff yet another unique proprietary protocol or is it
related to something more generic?
Apologies to tcp/ip folk who find this somewhat peripheral...
--
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)
-----------[000098][next][prev][last][first]---------------------------------------------------- Date: 9 May 90 22:56:17 GMT From: agate!shelby!cis!interran@ucbvax.Berkeley.EDU (John Interrante) To: tcp-ip@nic.ddn.mil Subject: Re: pinging a remote TCP port to see if it's in use
I got about four types of responses: 1. There is no way to get this information from the TCP protocol layer. [ Everybody agreed on this one. ] 2. If you have a way to bypass the TCP protocol layer and access the raw packet layer, you can send a SYN to the remote port. If there is no server listening on the other end, but the host is reachable, you should get a RST back. If there is a server listening on the other end, then the remote TCP will set up a connection block to handle your SYN and return a SYN ACK. The remote TCP will not have reached established state yet, so the listening server should still be unaffected. You would tear down your connection block and send a RST. The other end will tear down its connection block when it gets the RST. If your RST gets lost, the other end will retransmit the SYN ACK and your TCP will send a RST (as usual). Another person had a similar response with slightly different details: You can send and receive arbitrary packets behind TCP's back with Sun's Network Interface Tap (NIT) facility. You would synthesize the initial TCP SYN packet, listen for the SYN-ACK, and send an ABORT if one is received (to prevent the connection from being accepted). If no SYN-ACK is received, despite repeated retransmissions of the initial SYN, the remote port is not accepting connections. [ This is what I wanted to know. Unfortunately, it's too OS-specific to be worth implementing in my portmapper. ] 3. A network management protocol such as SNMP can tell you if a port already has a connection. Etc. [ No mention was made of a programmer-level interface to the network management protocol. Even if there was one, I wouldn't use it because it's not a standard part of most Unix systems (yet). ] 4. You can avoid a connection that hangs (because there's already an existing connection between the same TCP ports on both machines) by ioctling the socket with FIONBIO to put it in non-blocking I/O, issuing a connect on the socket, and then selecting on the socket for a ready to write condition with a timeout set. If the select times out, you have not successfully connected to the remote machine within that amount of time and you have the choice of increasing the time interval or using a different port on your side. [ This answer was very interesting even though it wasn't what I was asking for. If you use ANYPORT (i.e., a zero port), you're supposed to get an unused port on your side. Would or wouldn't ANYPORT prevent this kind of problem from occurring? ] A couple of people were curious why I wanted to know how to validate a port number. I don't mind explaining that the reason I asked was to improve a portmapper I wrote for InterViews programs making RPC calls. We couldn't use Sun's /etc/portmap because we wanted servers to register their TCP port numbers under a variable-length string of characters (i.e., a name), not a tuple of integers (i.e., a program number and a version number). I noticed that SunOS 4.1's /etc/portmap will let you register the port number of a non-existent server, but it will unregister the port number and give you zero when you try to ask for the non-existent server's port number. I set a breakpoint in a server to find out how portmap validated the server's port number and I know that the server never noticed a new connection. Yet portmap definitely WAS validating port numbers in some way because I never got a port number for a non-existent server. I checked the public RPC sources on gatekeeper.dec.com but the source for portmap didn't include this kind of code so that's why I posted my question. I wanted to be able to validate port numbers in my portmapper too because it would prevent clients from trying to connect to a server that crashed after registering its port number with the portmapper. I want to thank everybody who replied to my question. You all were very helpful in letting me know that the way Sun's /etc/portmap validates port numbers is too OS-specific to be worth duplicating. John Interrante interran@lurch.stanford.edu
-----------[000099][next][prev][last][first]---------------------------------------------------- Date: 10 May 90 00:25:06 GMT From: usc!cs.utexas.edu!execu!sequoia!sequoia.execu.com!dewey@ucsd.edu (Dewey Henize) To: tcp-ip@nic.ddn.mil Subject: 1's broadcast vs 0's broadcast (summary and thanks)
In article <15346@sequoia.execu.com> I asked about a problem with YP and IP broadcasts. I recieved a good bit of help from folks out there, and wanted to thank you all! The overall concensus was that the 1's broadcast was the only good way to go to be sure of continued compliance. (We had been using the 0's broadcast as a relic from our first couple Sun-2's - amazing how a network can grow.) It also appears that HP has support for broadcast selection in their (later? latest) OS upgrade/release, should someone find themselves in the corner I was in. I did do a convert on all the machines around to all 1's though, and was then able to remove the HP from the YP/NIS server business. In the middle we had one nice ARP storm as some clients got confused, but it all settled out and without the HP slowing the other machines down, our net is more responsive now. Thanks to those that posted suggestions, and I'd like to especially thank the following folks who wrote me with references and suggestions: WLV.IMSD.CONTEL.COM!mcc Merton Campbell Crockett mlb.semi.harris.com!del Don "Truck" Lewis ongs.LANCE.ColoState.Edu!steved Steve Dempsey idt.unit.no!he Haavard Eidnes tuegate.tue.nl!rcjoep Joep Brand uhura.cc.rochester.edu!leadley Scott Leadley Regards, Dew
-----------[000100][next][prev][last][first]---------------------------------------------------- Date: 10 May 90 01:21:07 GMT From: snorkelwacker!bu.edu!mirror!adelie!minya!jc@uunet.uu.net (John Chambers) To: tcp-ip@nic.ddn.mil Subject: Re: Is the hostname "foo" or "foo.bar.com"?
From mail Tue May 8 03:37 EDT 1990
>From cfisun!ima!haddock.ima.isc.com!ico!stan!imp Tue May 8 03:37:53 1990 remote from adelie
Received: by minya.uucp (smail2.5)
id AA27964; 8 May 90 03:37:53 EDT (Tue)
Received: by adelie.Adelie.COM (5.57/smail2.2/02-18-87)
Received: from ima.UUCP by cfisun.cfi.com (4.1/SMI-4.0)
id AA14084; Mon, 7 May 90 14:34:34 EDT
Received: from haddock.ima.isc.com by ima.ima.isc.com (5.61/1.35f)
id AA03828; Mon, 7 May 90 13:20:34 -0400
Received: from ico by haddock.ima.isc.com (5.61/1.36)
id AA22163; Mon, 7 May 90 13:20:58 -0400
Received: by ico.isc.com (5.61/1.35)
id AA00739; Mon, 7 May 90 11:14:36 -0600
Received: by stan.UUCP (smail2.5)
id AA06715; 7 May 90 10:55:23 MDT (Mon)
Received: from dancer.Solbourne.COM (dancer-gw) by Solbourne.COM (4.0/SMI-4.0)
id AA06706; Mon, 7 May 90 10:55:18 MDT
Received: by dancer.Solbourne.COM (4.0/SMI-4.0)
id AA04231; Mon, 7 May 90 10:55:17 MDT
Date: Mon, 7 May 90 10:55:17 MDT
From: cfisun!ima.ima.isc.com!Solbourne.COM!ico.isc.com!imp (Warner Losh)
Message-Id: <9005071655.AA04231@dancer.Solbourne.COM>
To: minya!jc
Subject: Re: Is the hostname "foo" or "foo.bar.com"?
Newsgroups: comp.protocols.tcp-ip
In-Reply-To: <380@minya.UUCP>
References: <9005032308.AA14782@ucbvax.Berkeley.EDU> <18464@nigel.udel.EDU>
Organization: Solbourne Computers Inc.
Cc:
| give me details and I will quote you RFC's. EVERY SMTP IMPLENETATION
| MUST ACCEPT MAIL THAT IS GIVEN TO IT, EVEN IF IT LOOKS "Forged".
Hmmm....If this is true, then there isn't, and never will be a compliant
implementation, unless someone finds a way to build a computer with
unlimited memory. All existing implementations are guaranteed to not
accept mail when their file system is full.
I've also been amused on many occasions by sendmail's "I refuse to
talk to myself" message. This is one of the cleverest screwups, in
which the mail actually makes it to the destination machine, and is
rejected in a totally demented fashion. I suppose this could be a
violation of the RFC, but my impression is that the authors of the
program intended it to act that way, and they don't consider it a
violation (or a bug). It's just a screwup on the part of the machine's
administrator. "If you'd done it right, you wouldn't have problems."
| >BTW, are you aware that there are systems being sold that limit hostnames
| >(sometimes doubling as sysnames or nodenames) to 16 bytes?
|
| Those hosts are brain dead. They do not conform to the internet
| standard of 256 characters in a host name. Limits on nodename that
| never leave the machine are fine, but limits that are exported are as
| bogus as 14 character file names. :-)
I'm not sure I totally agree. Sure, I think the limit should be larger.
But as for the idea that the designers of system X (e.g., the Internet)
should come along and tell the designers of system Y (e.g., Sys/V) that
"You don't do it our way, so you're brain dead", well, I'll reserve
judgement. I've seen too much of this sort of thing, and it's a game
that nobody wins.
This is a Sys/V machine with a 9-byte limit to the sysname and the
nodename. I would have made the limit larger, but in fact, it isn't
a problem. These names clearly aren't supposed to include domain info.
It makes a lot more sense to have the domain junk added by the mailer.
One effect the small limit has had is that people who ported BSD software
had to make sure it all allowed short names. I've found this to be a
real advantage against the BSD-based systems where I must constantly
type very long names.
An interesting case arises when (as is true here) a machine is in more
than one domain (.edu and .com), and there's no "correct" domain for
the machine as a whole. This situation is the main reason (other than
being a lazy typist ;-) that I personally prefer non-domainized hostnames.
If your machine always identifies itself as being in exactly one domain,
a lot of problems arise that are more easily solved if it doesn't know
its own domain. It's useful to be able to partition the problems, and
say that domains are email artifacts that are best localized in the
mail software.
In any case, I'm not trying to insult anyone (well, maybe a few :-).
I'm looking at complicated software that doesn't work very well, people
are saying incompatible things about the "right" way to do it, and I'd
like to find out if there is indeed a right way.
So far, the answer seems to be that various pieces of software decide
that different ways are right, the standards don't give answers, so
it'll remain a mess for some time. (It'll probably get straightened
out when IBM comes along and says how we'll do it, and we'll be stuck
with a bumbling, incompetent email system for the next 5 decades. ;-)
Sigh.
--
John Chambers ...!{harvard,ima,mit-eddie}!minya!jc
--
If you're not part of the solution, you're part of the precipitate.
[Kiel oni ^ci tiun diras esperante?]
-----------[000101][next][prev][last][first]---------------------------------------------------- Date: Thu, 10 May 90 07:36:16 EDT From: Robert Craig <ROBERT@VM1.MCGILL.CA> To: tcp-ip@nic.ddn.mil Subject: tcp/ip for Prime
I remember seeing a few months ago a message (I think it was on this list) concerning TCP/IP for Primes. We have a department with a Prime which they desperately want to connect, but can't afford the outrageous price for the ethernet adapter and TCP/IP that Prime wants to charge. The message seemed to imply that there were implementations of TCP/IP other than that sold by the vendor, which might cost significantly less. I've looked in the vendors' guide from the nic, but all I find in there is the stuff sold by Prime. Robert Craig domain: robert@vm1.mcgill.ca Network Analyst bitnet: robert@mcgill1 McGill University Computing Centre Tel: (514) 398-3710 (office) 805 Sherbrooke St. W. FAX: (514) 398-6876 Montreal, Quebec H3A 2K6 CORISQ: (514) 398-RISQ
-----------[000102][next][prev][last][first]---------------------------------------------------- Date: Thu, 10 May 90 09:47:11 EDT From: melling@gateway.mitre.org To: tcp-ip@nic.ddn.mil Cc: infsecur@smiley.mitre.org Subject: IETF Security
I am interested in finding out the role of the IETF security group (?) and which security issues it is dealing with in particular. What is its role/charter concerning security services? Phil Mellinger
-----------[000103][next][prev][last][first]---------------------------------------------------- Date: Thu 10 May 90 10:43:08 EDT From: Dan Lynch <LYNCH@A.ISI.EDU> To: pollux!ccruss@ucdavis.ucdavis.edu Cc: tcp-ip@nic.ddn.mil, lynch@A.ISI.EDU Subject: Re: Ingres certification of TCP/IP
Russ, THis is interesting. I thought there was a vendor coalition of SQL providers that is called the SQL access group and that they were coming up with interoperability standards. Are they missing something you folks have latched on to? Roger Sippl of Informix is the chair of this group. Dan -------
-----------[000104][next][prev][last][first]---------------------------------------------------- Date: Thu, 10 May 90 13:55:50 PDT From: postel@venera.isi.edu To: phri!news@nyu.edu Cc: tcp-ip@nic.ddn.mil Subject: What is the IAB?
Roy Smith: Please see RFC-1120 for an explanation of the IAB. --jon.
-----------[000105][next][prev][last][first]---------------------------------------------------- Date: Thu, 10 May 90 14:10:15 PDT From: postel@venera.isi.edu To: phri!news@nyu.edu Cc: tcp-ip@nic.ddn.mil Subject: What is the IAB?
Roy Smith: The Internet Activities Board (IAB) is the coordinating committee for Internet design, engineering and management. The Internet is a collection of over a thousand packet switched networks located principally in the U.S., but also includes systems in many other parts of the world, all interlinked and operating using the protocols of the TCP/IP protocol suite. The IAB is an independent committee of researchers and professionals with a technical interest in the health and evolution of the Internet system. Membership changes with time to adjust to the current realities of the research interests of the participants, the needs of the Internet system and the concerns of the U.S. Government, university and industrial sponsors of the elements of the Internet. IAB members are deeply committed to making the Internet function effectively and evolve to meet a large scale, high speed future. All IAB members are required to have at least one other major role in the Internet community in addition to their IAB membership. New members are appointed by the chairman of the IAB, with the advice and consent of the remaining members. The chairman serves a term of two years. [From RFC-1120] --jon.
-----------[000106][next][prev][last][first]---------------------------------------------------- Date: 10 May 90 11:36:16 GMT From: ROBERT@VM1.MCGILL.CA (Robert Craig) To: comp.protocols.tcp-ip Subject: tcp/ip for Prime
I remember seeing a few months ago a message (I think it was on this list) concerning TCP/IP for Primes. We have a department with a Prime which they desperately want to connect, but can't afford the outrageous price for the ethernet adapter and TCP/IP that Prime wants to charge. The message seemed to imply that there were implementations of TCP/IP other than that sold by the vendor, which might cost significantly less. I've looked in the vendors' guide from the nic, but all I find in there is the stuff sold by Prime. Robert Craig domain: robert@vm1.mcgill.ca Network Analyst bitnet: robert@mcgill1 McGill University Computing Centre Tel: (514) 398-3710 (office) 805 Sherbrooke St. W. FAX: (514) 398-6876 Montreal, Quebec H3A 2K6 CORISQ: (514) 398-RISQ
-----------[000107][next][prev][last][first]---------------------------------------------------- Date: Thu, 10 May 90 13:02:29 GMT From: Mills@udel.edu To: brian donat <cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!prls!pyramid!infmx!briand@tut.cis.ohio-state.edu> Cc: tcp-ip@nic.ddn.mil Subject: Re: gated
briand, I'm not sure what you mean by cost metrics on the fuzzlings, but if you want more information, see my paper in SIGCOMM 88 and/or the info in the SRI Vendor's Guide. If that doesn't work, light a match in a dark corner of your junkbox and whisper "fuzzbug" and see if an old backplane comes to life. Dave
-----------[000108][next][prev][last][first]---------------------------------------------------- Date: 10 May 90 13:20:15 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!kaarne.tut.fi!jja@ucsd.edu (Ahola Jari) To: tcp-ip@nic.ddn.mil Subject: Microsoft's ? SMB protocol - info needed.
Hello all! Im in a desperate need of information concerning a PC protocol called SMB (Send Message Block ??) possibly by Microsoft. This protocol is at least used by DCA's networking software and I know that there is servers for Unix machines using this protocol. But I haven't succeeded to find any other information except what's in this message. So if YOU have any single piece of information about SMB, drop me a line. I'm especially interested to get my hands in the specification of SMB. -jja Jari 'jja' Ahola |Tampere University of Technology, Signal Processing Lab Opiskelijankatu 16A12 |P.O. Box 527, 33101 Tampere, Finland 33720 Tampere, Finland|Tel (intl) 358 31 162708 (work)/358 31 174009 (home) Puh. 931-174009 |Net address: jja@tut.fi, AHOLA@FINTUTA (BITNET), bix:jja
-----------[000109][next][prev][last][first]---------------------------------------------------- Date: 10 May 90 15:02:07 GMT From: PIRARD@BLIULG11.BITNET (Andr'e PIRARD) To: comp.protocols.tcp-ip Subject: Re: Looking for Kermit Protocol Manual
> "Kermit, A File Transfer Protocol", Frank de Cruz Digital Press DEC 12 Crosby Drive Bedford Massach 01730 Order EY-6705E-DP > "Kermit Protocol Manual", Frank de Cruz The file KPROTO.DOC, maybe still missing the latest features. Open the mass of data with HELP mail to KERMSRV@CUVMA on BITNET. Andr).
-----------[000110][next][prev][last][first]---------------------------------------------------- Date: 10 May 90 15:07:44 GMT From: phri!news@nyu.edu (Roy Smith) To: tcp-ip@nic.ddn.mil Subject: What is the IAB?
At the recent PSI Internetworking Tutorial, I asked two people who
should have known the answer, "Exactly what *is* the Internet Activities
Board?" and in both cases all I got were some random moderately derogatory
comments but no real answer (which I found somewhat annoying, BTW).
So, can anybody on this list answer my question?
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"
-----------[000111][next][prev][last][first]---------------------------------------------------- Date: 10 May 90 17:22:59 GMT From: bu.edu!bu-it!kwe@uunet.uu.net (Kent England) To: tcp-ip@nic.ddn.mil Subject: Re: What is the IAB?
In article <1990May10.150744.12108@phri.nyu.edu>, roy@alanine.phri.nyu.edu (Roy Smith) writes: > > At the recent PSI Internetworking Tutorial, I asked two people who > should have known the answer, "Exactly what *is* the Internet Activities > Board?" and in both cases all I got were some random moderately derogatory > comments but no real answer (which I found somewhat annoying, BTW). > > So, can anybody on this list answer my question? > -- Some wires must have gotten crossed. It would be very strange indeed for anyone in PSI to take this view, since several of the principals at PSI have been involved in TCP/IP standards, including SNMP and "ISO-on-TCP", and that work would be exactly nowhere without the IAB. Strange, indeed. The IAB is sponsored by the Federal Networking Committee (formerly the Federal Research Internet Coordinating Committee or FRICC). The FNC is made up of government agencies (DARPA, NSF, DoE, NASA, HHS, et al) that fund research and education networks, like NSFnet, ESnet, NSI, et al. The IAB has two steering committees reporting to it, one of which is responsible for the Internet Engineering Task Force. The IETF is where the engineering work of TCP/IP gets done, thru the WGs and the RFC process. IETF meets quarterly and the last meeting was just last week at PSC in Pittsburgh. The IETF is open and you can learn more by subscribing to ietf-request@venera.isi.edu. Vint Cerf is the Chair of the IAB and Phill Gross is the Chair of the IETF and perhaps they may have some words to say about the IAB. You can also learn a great deal more about the IAB by ftp'ing to nnsc.nsf.net and looking thru the directories there. There are charters and reports from all the IETF working groups, as well as drafts that might eventually be submitted as RFCs. Most WGs have active mailing lists that you can subscribe to and that info is on NNSC. The IAB and IETF are open, very open in my opinion. All you have to do is roll up your sleeves and decide to join the process and everyone will be delighted to have you participate in whatever you find interesting. It is much easier to participate in the IETF than any other standards process that I am aware of. Only vendors can afford ANSI, IEEE, and OSI (exaggeration, perhaps, but there are few users in those bodies). On the other hand, IETF is overwhelmingly attended by users and network managers, although vendors are well represented and take particular interest in those issues that affect their bottom lines. That's enough from me, but the IAB/IESG/IETF don't do as well as others at self promotion, so perhaps this exposition will be useful to some. As they say, enjoy. Kent England, Boston University
-----------[000112][next][prev][last][first]---------------------------------------------------- Date: 10 May 90 17:38:01 GMT From: hsi!stevens@uunet.uu.net (Richard Stevens) To: tcp-ip@nic.ddn.mil Subject: Re: Microsoft's ? SMB protocol - info needed.
The references in
%T OS/2 to UNIX LAN
%A M. R. M. Dunsmuir
%B UNIX Networking
%E S. G. Kochan and P. H. Wood
%I Howard W. Sams and Company
%C Indianapolis, Ind.
%P 237-284
%D 1989
state that "Server Message Block, Protocol Specification (Core,
Extended, XENIX)" is published by Microsoft and is available
from the OEM marketing department at Micrsoft.
Richard Stevens
Health Systems International, New Haven, CT
stevens@hsi.com
... { uunet | yale } ! hsi ! stevens
-----------[000113][next][prev][last][first]---------------------------------------------------- Date: Thu, 10 May 90 14:48:31 +0200 From: root%ISIS.U-STRASBG.FR(Operator)@CUNYVM.CUNY.EDU To: tcpipl@UNKNOWN.DOMAIN Cc: hajjam@OSIRIS1.BITNET Subject: Setting multicast addresses
I am currently working on multicast protocols over Ethernet . Now my question: how is it possible to set multicast (ethernet) addresses, using streams, on a sun 3, SunOS4.0.3 ? If this is not possible using streams, are there any other simple solutions ? Thanks for your help moha hajjam@osiris1.u-strasbg.fr Universite louis Pasteur, Strasbourg , France
-----------[000114][next][prev][last][first]---------------------------------------------------- Date: Thu, 10 May 90 17:02:07 +0200 From: Andr'e PIRARD <PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@NIC.DDN.MIL Subject: Re: Looking for Kermit Protocol Manual
> "Kermit, A File Transfer Protocol", Frank de Cruz Digital Press DEC 12 Crosby Drive Bedford Massach 01730 Order EY-6705E-DP > "Kermit Protocol Manual", Frank de Cruz The file KPROTO.DOC, maybe still missing the latest features. Open the mass of data with HELP mail to KERMSRV@CUVMA on BITNET. Andr).
-----------[000115][next][prev][last][first]---------------------------------------------------- Date: Fri, 11 May 90 15:00:02 -0700 From: Marshall Rose <mrose@cheetah.nyser.net> To: john@pcsbst.pcs.com Cc: tcp-ip@nic.ddn.mil Subject: Re: In search of SNMP Sources
Get a copy of RFC1147 which should contain all the information you need. Also, please direct further questions regarding the SNMP, products, etc., to the snmp list. You can join by sending a note to snmp-request@nisc.nyser.net Thanks, /mtr
-----------[000116][next][prev][last][first]---------------------------------------------------- Date: 11 May 90 09:30:00 EST From: "Carla" <bazemore@nrl3.arpa> To: "tcp-ip" <tcp-ip@nic.ddn.mil> Subject: TCP-IP BULLETIN BOARD TOPIC
I am the Bulletin Board manager at the Naval Research Laboratory's Central Computing Facility. I would like to subscribe to your topic board, TCP-IP. Please add the mailing address, CCF_BITNET@CCF.NRL.NAVY.MIL, to your distribution list. If additional information is required, please send mail to BAZEMORE@CCF.NRL.NAVY.MIL. Thank you, Carla Bazemore (202) 767-3884
-----------[000117][next][prev][last][first]---------------------------------------------------- Date: Fri, 11 May 90 11:25:45 EDT From: Don Merritt <don@BRL.MIL> To: Joerg Hertzer <zrfp0128%awssn3.rus.uni-stuttgart.de@relay.cs.net> Cc: tcp-ip@nic.ddn.mil Subject: Re: "ttcp" program
>In a c program I found the following coment: > >/* > * This program is based on the "ttcp" program originally developed by > * T.C. Slattery, USNA, and improved by Mike Muuss and Terry Slattery. > * Due to the large number of changes, however (asynchio, data checking, > * random length and offset, fake-data option, ...), it has effectively > * been completely rewritten. > */ > >Where can I get the original ttcp program or the mentioned improved version? The original ttcp program is available for anonymous ftp from vgr.brl.mil (26.2.0.29) in pub/ttcp.c Don
-----------[000118][next][prev][last][first]---------------------------------------------------- Date: 11 May 90 09:35:13 GMT From: zrfp0128@AWSSN3.RUS.UNI-STUTTGART.DE (Joerg Hertzer) To: comp.protocols.tcp-ip Subject: "ttcp" program
In a c program I found the following coment:
/*
* This program is based on the "ttcp" program originally developed by
* T.C. Slattery, USNA, and improved by Mike Muuss and Terry Slattery.
* Due to the large number of changes, however (asynchio, data checking,
* random length and offset, fake-data option, ...), it has effectively
* been completely rewritten.
*/
Where can I get the original ttcp program or the mentioned improved version?
Thanks for your help
Joerg Hertzer
Computer Center University Stuttgart
Allmandring 30
D-7000 Stuttgart 80
West Germany
Phone: ++49-711-685-5803
Fax: ++49-711-682357
E-Mail: zrfp0128@awssn3.rus.uni-stuttgart.de (favored)
hertzer@rus.uni-stuttgart.dbp.de
S=hertzer;OU=rus;P=uni-stuttgart;A=dbp;C=de
ZRFP@DS0RUS1I.bitnet
"Life is satire"
-----------[000119][next][prev][last][first]---------------------------------------------------- Date: Fri, 11 May 90 17:10:47 PDT From: postel@venera.isi.edu To: mussar@bnr.ca Cc: tcp-ip@nic.ddn.mil Subject: Re: Obtaining PPP (draft) spec
Hi. The PPP Specificarion id RFC-1134. --jon.
-----------[000120][next][prev][last][first]---------------------------------------------------- Date: Fri, 11 May 90 16:11:05 EDT From: BDK@UNB.CA To: TCP-IP@NIC.DDN.MIL Subject: Re: tcp/ip for Prime
I don't have an answer for you but am interested in the replies. Brian Kaye University Of New Brunswick On Thu, 10 May 90 09:57:29 ADT Robert Craig <ROBERT@VM1.MCGILL.CA> writes: > I remember seeing a few months ago a message (I think it > was on this list) concerning TCP/IP for Primes. We have > a department with a Prime which they desperately want to > connect, but can't afford the outrageous price for the > ethernet adapter and TCP/IP that Prime wants to charge. > The message seemed to imply that there were implementations > of TCP/IP other than that sold by the vendor, which might > cost significantly less. > > I've looked in the vendors' guide from the nic, but all I find > in there is the stuff sold by Prime. > > Robert Craig domain: robert@vm1.mcgill.ca > Network Analyst bitnet: robert@mcgill1 > McGill University Computing Centre Tel: (514) 398-3710 (office) > 805 Sherbrooke St. W. FAX: (514) 398-6876 > Montreal, Quebec H3A 2K6 CORISQ: (514) 398-RISQ
-----------[000121][next][prev][last][first]---------------------------------------------------- Date: Fri, 11 May 90 20:27:24 PDT From: LiBai!tinker@ames.arc.nasa.gov (Don Tinker) To: zrfp0128%awssn3.rus.uni-stuttgart.de@ames!RELAY.CS.NET Cc: tcp-ip@NIC.DDN.MIL Subject: "ttcp" program
>
>In a c program I found the following coment:
>
>/*
> * This program is based on the "ttcp" program originally developed by
> * T.C. Slattery, USNA, and improved by Mike Muuss and Terry Slattery.
> * Due to the large number of changes, however (asynchio, data checking,
> * random length and offset, fake-data option, ...), it has effectively
> * been completely rewritten.
> */
>
>Where can I get the original ttcp program or the mentioned improved version?
What you have is a copy of a program "tsock", written by the folks at
Ultra Network Technologies (my company) in order to test
high-performance i/o through high-performance networks. I'll mail you
a copy, and because this is the third or fourth request for it I've
gotten lately, I'll see about putting it on someplace ftp-able-to.
Don Tinker tinker@ultra.com
Senior Field Support Engineer {core}!ames!ultra!tinker
UltraNetwork Technologies Inc. (703) 821-8393
-----------[000122][next][prev][last][first]---------------------------------------------------- Date: Fri, 11 May 90 18:41 CDT From: Buckaroo Bonzai and the Team of Baker Street Irregulars, <ELEE6WK@jetson.uh.edu> To: NEXT-L@BROWNVM.BITNET, INFO-UNIX@BRL.ARPA, TCP-IP@NIC.DDN.MIL, DLV@CUNYVMS1.BITNET, GAELIC-L@IRLEARN.BITNET, Info-Mac@sumex-aim.stanford.edu, space+@andrew.cmu.edu, I-PACRAD@UIUCVMD.BITNET, Packet-Radio@UCSD.Edu, Info-IBMPC@WSMR-SIMTEL20.ARMY.mil Subject: this is a test... disregard if you receive this
this is a test.. please disregard if you get this... my mail router here at the university of houston has died a death or two. william sanders, a subscriber to this list
-----------[000123][next][prev][last][first]----------------------------------------------------
Date: 11 May 90 14:30:00 GMT
From: bazemore@CCF3.NRL.NAVY.MIL ("Carla")
To: comp.protocols.tcp-ip
Subject: TCP-IP BULLETIN BOARD TOPICI am the Bulletin Board manager at the Naval Research Laboratory's Central Computing Facility. I would like to subscribe to your topic board, TCP-IP. Please add the mailing address, CCF_BITNET@CCF.NRL.NAVY.MIL, to your distribution list. If additional information is required, please send mail to BAZEMORE@CCF.NRL.NAVY.MIL. Thank you, Carla Bazemore (202) 767-3884
-----------[000124][next][prev][last][first]---------------------------------------------------- Date: 11 May 90 14:37:12 GMT From: crdgw1!gecrdvm1!hathawa@uunet.uu.net (Barry Hathaway) To: tcp-ip@nic.ddn.mil Subject: tn3270 for Suns
This is a reposting of an earlier note in hopes that someone can help me find a tn3270 that works correctly. HELP! Thanks in advance. Recently I retreived the latest version (4.1.1) of tn3270 from Berkeley and have been playing around it. The reason I went to the new version was that our prior version had cursor positioning problems. When users would tn3270 to our VTAM session manager (Netview/Access Services) on MVS the cursor would appear 1 position to the left of the first (userid) unprotected field on the screen - so if the user wanted to enter his userid he would have to move the cursor one position to the right. This only seemed to happen with this particular application. Happily, Version 4.1.1 fixed that problem; however, it introduced a much more serious problem - improper highlighing. (Note: the termcap entry is set up to do bold instead of reverse video.) In some, but important, applications some things are hightligted when they are not supposed to be. I have seen this most in IDMS applications. For example: in one application the date and time appears in the upper right corner of the screen and the lower portion of the screen contains a number of unprotected fields, and some highlighted fields. When you press enter or a PF key the application does some things and updates the time in the upper right corner. When it does this the seconds become highlighted. If one waits until the minute changes then the minutes will also become highlighted. This is only one example, but it happens often. Apparently some strange cursor positioning orders are generated by IDMS. This did not seems to happen in the older version (unknown version) of tn3270. Any ideas? Is anyone else having the same problem?
-----------[000125][next][prev][last][first]---------------------------------------------------- Date: Fri, 11 May 90 11:35:13 +0200 From: Joerg Hertzer <zrfp0128%awssn3.rus.uni-stuttgart.de@RELAY.CS.NET> To: tcp-ip@NIC.DDN.MIL Subject: "ttcp" program
In a c program I found the following coment:
/*
* This program is based on the "ttcp" program originally developed by
* T.C. Slattery, USNA, and improved by Mike Muuss and Terry Slattery.
* Due to the large number of changes, however (asynchio, data checking,
* random length and offset, fake-data option, ...), it has effectively
* been completely rewritten.
*/
Where can I get the original ttcp program or the mentioned improved version?
Thanks for your help
Joerg Hertzer
Computer Center University Stuttgart
Allmandring 30
D-7000 Stuttgart 80
West Germany
Phone: ++49-711-685-5803
Fax: ++49-711-682357
E-Mail: zrfp0128@awssn3.rus.uni-stuttgart.de (favored)
hertzer@rus.uni-stuttgart.dbp.de
S=hertzer;OU=rus;P=uni-stuttgart;A=dbp;C=de
ZRFP@DS0RUS1I.bitnet
"Life is satire"
-----------[000126][next][prev][last][first]---------------------------------------------------- Date: 11 May 90 15:09:59 GMT From: mcsun!unido!fauern!tumuc!guug!pcsbst!john@uunet.uu.net (John Ludbrook (Marketing)) To: tcp-ip@nic.ddn.mil Subject: In search of SNMP Sources
Hi Networkers, I am currently seeking SNMP Source to run on UNIX V.3.2 and have only the names of the following companies/ institutes ( but no contacts) : Epilogue Technologies MIT ( Network Manager Lab.?) Perfomance Systems International SNMP Research Netlabs Carnegie Mellon University Can anyone help out with names, phone/fax nos., mail addresses etc? appreciate your help. john ludbrook
-----------[000127][next][prev][last][first]---------------------------------------------------- Date: 11 May 90 15:18:31 GMT From: hercules!sparkyfs!arsocomvax.socom.mil!news@apple.com (Ted Nolan) To: tcp-ip@nic.ddn.mil Subject: 4.3BSD VAX/sendmail vs Sperry 5000/MMDF?
I'm having kind of a strange problem. For our mailhost and gateway, we have a Vax 11/780 running (fairly vanilla) 4.3BSD (with a recent sendmail). This vax sits on our ethernet and has an ACC ACP6250 connection to our MILNET PSN. Recently we've had users trying to send mail to a couple of Serry-5000/80 Unix systems running MMDF as the SMTP server. The mail never gets there, sitting queued on a "Bad file number". Here's the strange part. From the vax, I can telnet to both of these hosts with no problem (quite a good connection as a matter of fact). However, if I try to manually talk to the SMTP server (for example): telnet fulda-emh1.army.mil 25 I get: Trying... Connected to fulda-emh1.army.mil. Escape character is '^]'. Connection closed by foreign host. And the connection closes immediately, before getting any response from MMDF. This is apparently the same thing sendmail sees when it declares a "bad file number". But, if I try the same thing from one of our Suns, which all use the vax as a gateway, I get a connection with no problem: telnet 26.14.0.175 25 Trying 26.14.0.175 ... Connected to 26.14.0.175. Escape character is '^]'. 220 s5000 Server SMTP (Complaints/bugs to: mmdf@fulda-emh1.army.mil) Are there any known problems between 4.3 and Sperry? Since telnet doesn't work on port 25 either, I don't really think it's a sendmail/mmdf problem.. Thoughts appreciated, Ted Nolan ted@usasoc.soc.mil
-----------[000128][next][prev][last][first]---------------------------------------------------- Date: 11 May 90 16:49:02 GMT From: usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!cunews!bcars8!bnrgate!bigsur!bcars53!mussar@ucsd.edu (G. Mussar) To: tcp-ip@nic.ddn.mil Subject: Obtaining PPP (draft) spec
Can anyone tell me where to find the PPP spec. Is it sitting as an RFC at the NIC? Email to either of the addresses should reach me (but I have never tried them myself). Thanks in advance. -- ------------------------------------------------------------------------------- Gary Mussar |Bitnet: mussar@bnr.ca | Phone: (613) 763-4937 BNR Ltd. | UUCP: ..uunet!bnrgate!bcars53!mussar | FAX: (613) 763-2626
-----------[000129][next][prev][last][first]---------------------------------------------------- Date: 11 May 90 17:37:22 GMT From: ccncsu!longs.LANCE.ColoState.Edu!steved@boulder.colorado.edu (Steve Dempsey) To: tcp-ip@nic.ddn.mil Subject: BSD networking installation
I've been playing with the [March '89] BSD networking code,
(ftp'd from uunet:bsd-sources/src/network/sys.tar.Z) and
incorporating pieces of it into Ultrix3.1. I've had a bit
of difficulty getting the ICMP record-route to work correctly.
Specifically, icmp_reflect() in ip_icmp.c contains the
following:
* @(#)ip_icmp.c 7.8.1.2 (Berkeley) 3/2/89
/* Retrieve any source routing from the incoming packet;
* add on any record-route or timestamp options.
*/
[much code deleted]
/* Now strip out original options by copying rest of first
* mbuf's data back, and adjust the IP length.
*/
ip->ip_len -= optlen;
ip->ip_hl = sizeof(struct ip) >> 2;
/*XX*/ m->m_len -= optlen;
optlen += sizeof(struct ip);
bcopy((caddr_t)ip + optlen, (caddr_t)(ip + 1),
/*XX*/ m->m_len - sizeof(struct ip));
It's obvious that the variable m in the marked lines is a pointer
to struct mbuf, but m is neither referenced nor declared in this
routine, nor anywhere else that I can find. I've tried various
things to get this to work and have not yet found a stable
solution; my kernel debugging skills are sorely lacking.
So my questions are: has anyone fixed this, and where might I
find the right code?
Steve Dempsey, Center for Computer Assisted Engineering
Colorado State University, Fort Collins, CO 80523 +1 303 491 0630
INET: steved@longs.LANCE.ColoState.Edu, dempsey@handel.CS.ColoState.Edu
UUCP: boulder!ccncsu!longs.LANCE.ColoState.Edu!steved, ...!ncar!handel!dempsey
-----------[000130][next][prev][last][first]---------------------------------------------------- Date: 11 May 90 17:49:14 GMT From: ccncsu!longs.LANCE.ColoState.Edu!steved@boulder.colorado.edu (Steve Dempsey) To: tcp-ip@nic.ddn.mil Subject: BSD networking installation
I've been playing with the [March '89] BSD networking code,
(ftp'd from uunet:bsd-sources/src/network/sys.tar.Z) and
incorporating pieces of it into Ultrix3.1. I've had a bit
of difficulty getting the ICMP record-route to work correctly.
Specifically, icmp_reflect() in ip_icmp.c contains the
following:
* @(#)ip_icmp.c 7.8.1.2 (Berkeley) 3/2/89
/* Retrieve any source routing from the incoming packet;
* add on any record-route or timestamp options.
*/
[much code deleted]
/* Now strip out original options by copying rest of first
* mbuf's data back, and adjust the IP length.
*/
ip->ip_len -= optlen;
ip->ip_hl = sizeof(struct ip) >> 2;
/*XX*/ m->m_len -= optlen;
optlen += sizeof(struct ip);
bcopy((caddr_t)ip + optlen, (caddr_t)(ip + 1),
/*XX*/ m->m_len - sizeof(struct ip));
It's obvious that the variable m in the marked lines is a pointer
to struct mbuf, but m is neither referenced nor otherwise declared
in this routine, nor anywhere else that I can find. I've tried
various things to get this to work and have not yet found a stable
solution; my kernel debugging skills are sorely lacking.
So my questions are: has anyone fixed this, and where might I
find the right code?
Steve Dempsey, Center for Computer Assisted Engineering
Colorado State University, Fort Collins, CO 80523 +1 303 491 0630
INET: steved@longs.LANCE.ColoState.Edu, dempsey@handel.CS.ColoState.Edu
UUCP: boulder!ccncsu!longs.LANCE.ColoState.Edu!steved, ...!ncar!handel!dempsey
-----------[000131][next][prev][last][first]---------------------------------------------------- Date: 11 May 90 18:10:35 GMT From: usc!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls@ucsd.edu (David L Stevens) To: tcp-ip@nic.ddn.mil Subject: Re: BSD networking installation
*** /tmp/,RCSt1019886 Fri May 11 13:07:41 1990 --- ip_icmp.c Tue Jun 13 00:18:11 1989 *************** *** 349,354 **** --- 349,355 ---- register struct in_ifaddr *ia; struct in_addr t; struct mbuf *opts = 0, *ip_srcroute(); + struct mbuf *m = dtom(ip); int optlen = (ip->ip_hl << 2) - sizeof(struct ip); t = ip->ip_dst; -- +-DLS (dls@mentor.cc.purdue.edu)
-----------[000132][next][prev][last][first]---------------------------------------------------- Date: 11 May 90 18:41:31 GMT From: voder!pyramid!infmx!kwang@ucbvax.Berkeley.EDU (Kwang Sung) To: tcp-ip@nic.ddn.mil Subject: Re: comparision of sockets to tli
>From: fsi@cbnewsh.att.com (furrokh.s.irani)
>Organization: AT&T Bell Laboratories
>
> Does anyone have a comparision of the 'TLI' interface versus
>the 'socket' interface?
> Please email to att!odyssey!fsi. Thanks v. much.
>-Furrokh S. Irani
Dear Mr. Furrokh Irani:
Currently, I am not working on 'TLI' or 'socket', but here are the
differences I can think of.
1. In order to establish a transport endpoint....
TLI: "t_open" call which can open any minor devices. Those devices can
be shared by unrelated processes.
Sockets: "socket" call which uses different parameters such as type, domain,
protocol. It can not access a minor device which is already opened,
except if the processes are related.
2. In order to establish a connection...
TLI: "t_listen" call which can be done without accepting a connection.
One can listen multiple times without accepting a connection.
"t_bind" call will set the queue length for the incoming connections.
"t_connect" is used for connection with another transport user.
The endpoint should be bound to a protocol address before that.
Sockets: "listen" call which is followed by an "accept". This is necessary
as "listen" only sets the queue length.
"connect" used for connection initiation. It's possible to connect
without being bound to a protocol address.
3. In order to accept a connect request...
TLI: "t_accept" can be used. You have to allocate a file descriptor,
upon which the connection is accepted. This will give more
flexibility of accepting the connection. It also give the option
of not accepting, or delaying for the multiple t_listens. It's
possible to accept connection request in any order.
Sockets: "accept" can be use, which returns a socket file descriptor.
It's not possible to select which connect request to accept.
4. For user date on connection or disconnection...
TLI: One can receive the user data in the "t_listen". One can send
the user data in both the "t_connect", and the "t_accept".
One can both send and receive the user data on all the disconnection
primitives. This will be determined by "t_getinfo".
Sockets: There is no concept of sending or receiving the user data on any of
the connection/disconnection primitives.
5. For the asynchronous processing...
TLI: It's possible to send connection request, and receive asynchrously
thru "t_sndconnect" and "t_rcvconnect".
Sockets: It has similar feature, but one can get errors and will be lost
after an asynchronous operation.
6. For getting address info for an established connection...
TLI: It's not possible to get the connection address info, but one
can get the connection status.
Sockets: "getsockname", "getpeername" will give the address info.
7. For the data transfer...
TLI: MORE_flag specifies record boundaries.
Sockets: There is no way of reading/writing partial records.
8. For the urgent or out of band data...
TLI: The only way is to read all the data, and then find out in the
data queue.
Sockets: The socket can be registered to receive a SIGURG signal.
9. For other misc....
TLI: On System V.3, one has to push "tirdwr" module, otherwise Read/Write
will fail.
Sockets: Read/Write calls work directly on a socket.
10. Other problems on TLI...
The interactions between the "t_listen" and "t_accept" is too tight.
The "t_snd" should permit a scatter/gather array for an argument.
---
By the way, please don't trust TLI !! There are a lot other problems on
TLI implementation besides the above. It was actually poorly designed. But
still you can migrate to OSI world easily, since it was modelled after
ISO 8072. That's why I am enjoying OSI protocols now. Thanx.
Kwang Sung
Informix Software, Inc.
4100 Bohannon Dr.
Menlo Park, CA 94025
415 / 926 - 6758 (O)
UUCP: ...!uunet!infmx!kwang
-----------[000133][next][prev][last][first]---------------------------------------------------- Date: 11 May 90 22:00:40 GMT From: snorkelwacker!bu.edu!mirror!redsox!campbell@tut.cis.ohio-state.edu (Larry Campbell) To: tcp-ip@nic.ddn.mil Subject: Re: Microsoft's ? SMB protocol - info needed.
In article <13013@etana.tut.fi> jja@kaarne.tut.fi (Ahola Jari) writes: -Im in a desperate need of information concerning a PC protocol called SMB -(Send Message Block ??) possibly by Microsoft. It's "Server Message Block". Perhaps this is just too obvious, but why don't you call Microsoft and ask them? It's their protocol. -- Larry Campbell The Boston Software Works, Inc. campbell@redsox.bsw.com 120 Fulton Street wjh12!redsox!campbell Boston, MA 02109
-----------[000134][next][prev][last][first]---------------------------------------------------- Date: 11 May 90 22:04:29 GMT From: usc!snorkelwacker!bu.edu!bu-it!kwe@ucsd.edu (Kent England) To: tcp-ip@nic.ddn.mil Subject: Re: What is the IAB?
I said: > The IAB is sponsored by the Federal Networking Committee (formerly >the Federal Research Internet Coordinating Committee or FRICC). in my response to Roy Smith's question, and some people took pains to point out to me that sponsor is an unfortunate term. The IAB is independent of the FNC, even though the FNC does contribute funds to the operation of the IAB, and obviously serves a wider constituency that simply the FNC agencies. Perhaps "support" is a better term? --Kent "not a spokesman for the IAB"
-----------[000135][next][prev][last][first]---------------------------------------------------- Date: 12 May 90 01:50:38 GMT From: van-bc!mplex!fff@ucbvax.Berkeley.EDU (Fred Fierling) To: tcp-ip@nic.ddn.mil Subject: thin ethernet tcpip to printer interface
Does anyone know of a device which: - connects a single parallel port of a printer to a thin ethernet - allows a host running tcp/ip to spool data to it - costs less than $1k ? -- Fred Fierling uunet!van-bc!mplex!fff Tel: 604 875-1461 Fax: 604 875-9029 Microplex Systems Ltd 265 East 1st Avenue Vancouver, BC V5T 1A7, Canada
-----------[000136][next][prev][last][first]---------------------------------------------------- Date: 12 May 90 11:02:09 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!chic@ucsd.edu (Chris C. L. CHING) To: tcp-ip@nic.ddn.mil Subject: (HELP!) Question on socket (Datagram)
Hi, I got a problem of using socket on sun. The "recmsg" call is
supposed to wait for a message to arrive if no messages are available at
the socket. But I don't know why it does not do that in my program.
My program terminated normally and received 0 byte. I was running my
program in SunOS 4.0.3 environment.
Does anyone know how to solve my problem?
Thanks in advance.
Here is my program
-------------------------------------------------------------------------
#include <stdio.h>
#include <sys/un.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/uio.h>
#include <errno.h>
#define NAME "sock"
#define NAMESIZE 256
#define STDOUT 1
extern int errno;
caddr_t malloc();
main()
{
int sd;
int fd;
int nc;
struct sockaddr_un master;
struct msghdr *msg;
struct iovec *iobuf;
sd = socket(AF_UNIX, SOCK_DGRAM,0); /* datagram */
iobuf = (struct iovec *) malloc(sizeof(struct iovec));
msg = (struct msghdr *) malloc(sizeof(struct msghdr));
bzero ((char *) msg, sizeof *msg);
msg->msg_name = (caddr_t) malloc(NAMESIZE);
msg->msg_namelen = NAMESIZE;
msg->msg_iov = iobuf;
msg->msg_iovlen = 1;
msg->msg_accrights = (caddr_t) malloc(NAMESIZE);
msg->msg_accrightslen = NAMESIZE;
master.sun_family = AF_UNIX;
strcpy(master.sun_path, NAME);
if (bind(sd, (struct sockaddr *)&master, strlen(master.sun_path) +
sizeof(master.sun_family))<0) {
perror("bind");
}
if ((nc = recvmsg(sd, msg, 0))<0)
perror("recverr");
fd = *((int *) msg->msg_accrights);
close(sd);
unlink(NAME);
}
---------------------------------------------------------------------------
|Chris Ching
|The University of Melbourne
|Department of Computer Science
|Parkville, 3052, Australia
|ACSNET: chic@munmurra.cs.mu.OZ.AU
-----------[000137][next][prev][last][first]---------------------------------------------------- Date: 12 May 90 14:39:48 GMT From: mcsun!unido!uklirb!incas!popper!zessel@uunet.uu.net (Holger Zessel) To: tcp-ip@nic.ddn.mil Subject: Re: question about caching in UDP based RPC (AND bug in UDP Cache?!)
jeff@hpctdkp.HP.COM (Jeff Hughes) writes:
>>Your cache will not ensure execute at most once behavior. Think about
>>a server and three clients. The server gets an RPC from client 1,
>>then 2, then 3. But it must trash the cache from client 1 in order
>>to store client 3's result. Now it gets a resend from client 1; it
>>will execute the service routine a second time.
>>The trick to caching UDP/RPC results it to cache exactly one result for
>>each client the server has. The cost is 8K per client, max. You never
>>need to cache more than one response from each client, since a client
>>will only send a new RPC only if the old one has been completed.
>This is a good idea. I believe there are some exceptions to the 1 reply
>per request rule, however. I believe the "spray" application will blast
>a host with a number of packets before requiring a reply.
There is no need to implement a cache for RPC replies in UDP.
At least RPC3.9 and 4.0 contain a call "svcudp_enablecache" which does
exactly what you want !
Its arguments are the transp and the cachesize. The cache is implemented as a
fifo.
With cache enabled RPC will cache every sent reply until it has to be trashed
as the fifo pointer is at the same cell again.
You don't have to worry about collisions between client replies. The
cache can distinguish between all clients and all their messages using
the RPC transaction id's and the sockaddr_in structure of the clients
(and some other additional values).
I used it successfully in a not-in-kernel implementation of an NFS server.
I first noticed its correct working every time in dbx where clients
always time out when I single step through the server code. I added some
"sent cached reply"-line to RPC which told me it worked.
BUT BEWARE !
In some RPC3.9 the cache is ok. In 4.0 a simple bug was introduced.
Therefore the cache did not work for SunOS4.03. As I had to use
our suns I took RPC4.0 sources and made a really LITTLE patch to them:
In file rpc/svc_udp.c, routine svcudp_recv, which is called by the server
getting packets from the clients.
....getting a packet through recvfrom...
....some xdr managing...
and now: /* comments are mine */
if (su->su_cache != NULL) { /* cache yes/no */
if (cache_get(xprt, msg, &reply, &replylen)) { /* cache hit ? */
/* yes ! a hit ! therefore send stored reply ! */
(void) sendto(xprt->xp_sock, reply, (int) replylen, 0,
(struct sockaddr *) &xprt->xp_raddr, xprt->xp_addrlen);
fprintf(stderr,"Sending cached reply...\n"); /* my debug line !*/
return (FALSE); /* Here was TRUE before !!! And this was
the bug ! Returning true causes the
the serverfunction to be called despite
a reply was sent already ! */
}
...
I hope that helps some other people trying to use the cache too.
Keep hacking !
Holger
>jeff@hpctdlb.hp.com
----------------------------------------------------------------
Holger Zessel, uucp: ...!uunet!unido!uklirb!incas!zessel
or zessel@informatik.uni-kl.de
or zessel%informatik.uni-kl.de@relay.cs.net (from usa)
Fachbereich Informatik, SFB124-D1
Universitaet Kaiserslautern, West-Germany
-----------[000138][next][prev][last][first]---------------------------------------------------- Date: 12 May 90 18:29:43 GMT From: bu.edu!polygen!bill@uunet.uu.net (Bill Poitras) To: tcp-ip@nic.ddn.mil Subject: rwhod problems with Xenix/286
I installed Xenix/286 2.3.2, and Excelan's LAN Workplace for Xenix/286 and
have noticed a problem. When the system starts up, everything starts up
great, ecept for the rwhod program. When the rc script file is excecuted,
I get the following message:
rwhod: send:Bad address
I have all my routing info set up, the Excelan driver works perfectly. Any
help would greatly be apprecited.
+-----------------+---------------------------+-----------------------------+
| Bill Poitras | Polygen Corporation | {princeton mit-eddie |
| (bill) | Waltham, MA USA | bu sunne}!polygen!bill |
| | | bill@polygen.com |
+-----------------+---------------------------+-----------------------------+
-----------[000139][next][prev][last][first]---------------------------------------------------- Date: 12 May 90 18:35:03 GMT From: bu.edu!polygen!bill@uunet.uu.net (Bill Poitras) To: tcp-ip@nic.ddn.mil Subject: ftp on Xenix/286
I have a 386SX system set up with Xenix/286 2.3.2, and Excelan's LAN Workplace
for Xenix/286. When I use ftp, after every command, I get "error on read". During
a get, I get it multiple times. TFM (as in RTFM :-) doesn't tell me squat. Telnet works
great, and installation went by flawlessly. The only other problem is when rwhod gets
installed, but thats a different problem. Thanks for any help you can give me.
+-----------------+---------------------------+-----------------------------+
| Bill Poitras | Polygen Corporation | {princeton mit-eddie |
| (bill) | Waltham, MA USA | bu sunne}!polygen!bill |
| | | bill@polygen.com |
+-----------------+---------------------------+-----------------------------+
-----------[000140][next][prev][last][first]---------------------------------------------------- Date: 12 May 90 18:58:06 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!lth.se!newsuser@ucsd.edu (Jan Engvald) To: tcp-ip@nic.ddn.mil Subject: Re: Lantastic vs. the World - Problems?
In article <11484@cbmvax.commodore.com> grr@cbmvax (George Robbins) writes:
>One of our user areas here has decided that they want to use one of those
>PC network products call "Lantastic" with WD8003 Ethernet cards. Up to
>now our LAN has been exclusivly TCP/DECnet/XNS and we've standardized on
>3c503 cards for PC's.
>
>The apparent reason for going with the WD8003 cards is lack of Netbios
>support for the 3c503. I find this somewhat hard to argue with.
>
>Has anyone had any interoperbility problems with Lantastic and traditional
>protcols on the same Ethernet? I know there shouldn't be, but I'd like be
>sure before these guys commit (me) to a bunch of new hardware and software.
>
>Is the Lantastic stuff yet another unique proprietary protocol or is it
>related to something more generic?
Don't run Lantastic on a big LAN or you can expect interference with
other protocols sooner or later. We have had to forbid Lantastic nets
to be connected to our backbone because it upsets our HP computers
(HP 3000 type).
The reason for this is that Lantastic is NOT runing ethernet 2
protocol (which have protocol id in byte 13-14 of the ethernet
packet), but is using an ISO-like packet (with a length in byte
13-14). However, they don't continue like an ISO-packet, instead of
required headers they have their own data. This confuses for all of
those that uses ISO-packets the right way (or almost right :-).
I know for sure that it affects HP Advancenet used by HP 3000
computers. I expect it will affect DECnet phase 5 too and also
ISO IP protocols.
There are two ways for the Lantastic developers to fix it:
- They can make it an ethernet 2 packet by applying for a unique
protocol id that they can put into byte 13-14.
- They can add the required ISO headers after byte 14.
I have several times sent the above info to the Lantastic developers
(and Lantastic engineering management have visited me to discuss
it!!), but as of yet they have not changed their protocol. Its a
pity, because Lantastic is otherwise a very good low cost network.
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%24020031020720::xjeldc
Telephone: +46 46 107458 (X.400: C=se; A=Delta; P=Sunet; O=lu;
Telefax: +46 46 138225 OU=ldc; S=Engvald; G=Jan)
Telex: 33533 LUNIVER S
-----------[000141][next][prev][last][first]---------------------------------------------------- Date: 13 May 90 02:04:05 GMT From: sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU (Vernon Schryver) To: tcp-ip@nic.ddn.mil Subject: Re: "ttcp" program
Ttcp is handy for tuning a TCP or UDP implementation. Versions of ttcp can be found in sgi/src on sgi.sgi.com, currently 192.48.153.1. ttcp.c.brl is the most recent BRL version I've seen. Ttcp.shar is from last August. Ttcp.c is our current understanding of what was acceptable to BRL. It includes controls for buffer alignment and other things. By default it is a file transfer program, needing '-s' to make it generate and sink data as a test program. I think there are also versions available from BRL, perhaps on brl.mil. They are probably newer than sgi:.../ttcp.c.brl. Ttcp has never appeared in comp.sources.unix, although I understood from the moderator that it would someday. If you buy a Silicon Graphics "IRIS", you'll find ttcp.c among other example and test programs in /usr/people/4Dgifts. There was some hassle with the port number. The original port 2000 conflicted with a certain solar window manager, currently the default window manager for SGI. BRL and SGI checked with the Net Gods about getting an official port number for ttcp, but failed. Be careful to understand the numbers people give you. Not long ago a vendor trying to sell stuff gave me what I thought were some good numbers. A few weeks later they happened to mention to some of my colleagues that the numbers were obtained by summing some simultaneous tests. It is as they say, "lies, damn lies, and benchmarks." Vernon Schryver Silicon Graphics vjs@sgi.com
-----------[000142][next][prev][last][first]---------------------------------------------------- Date: 13 May 90 02:24:43 GMT From: watson!sob@tmc.edu (Stan Barber) To: tcp-ip@nic.ddn.mil Subject: Re: PC-LAN connection to Usenet
In article <798@banyan.UUCP> gordon@banyan.com (Gordon Lee@Eng@Banyan) writes:
>For cases where you have an Internet connection, it is possible to write
>an NNTP server for an OS/2 machine. The NNTP protocol can run over any
>stream oriented transport protocol, of course the protocol of choice would
>be TCP/IP stack since NNTP implementations within USENET are usually talking
>TCP/IP, (I haven't heard of an implementation which uses a different protocol).
The "canonical" NNTP for Unix has supported TCP/IP and DECNET for a very
very long time.
There is an implementation that run on VMS that supports TCP/IP and DECNET.
There are rumors of other implementations (on VM) that may support other
transports.
Please see "news.announce.newusers" for the "USENET: History and Sources"
posting for more information on NNTP and the platforms is it available on.
Maintainer of NNTP and RN/RRN,
--
Stan internet: sob@bcm.tmc.edu Director, Networking
Olan uucp: {rutgers,mailrus}!bcm!sob and Systems Support
Barber Opinions expressed are only mine. Baylor College of Medicine
-----------[000143][next][prev][last][first]---------------------------------------------------- Date: 13 May 90 04:58:51 GMT From: iscden!jbev@boulder.colorado.edu (J.Bevier @ Home on Hipeak) To: tcp-ip@nic.ddn.mil Subject: tcp/ip software
I am looking for public domain software for tcp, ip, tftp, ftp, and telnet. I am doing a port to a new environment and need all of the software. Could someone please direct me to an archive site or UUCP site were I can download the the software. Thanks, Jim Bevier --- +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+ From the mountains of Colorado: +=+ +=+ when it's not snowing, the sun is shining +=+ +=+ Jim Bevier - J B Systems (303)-697-1038 +=+ +=+ 10136 Horizon View, Morrison, CO 80465 +=+ +=+ jbev@iscden.UUCP or ...!boulder!iscden!jbev +=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
-----------[000144][next][prev][last][first]---------------------------------------------------- Date: Sun, 13 May 90 21:08:49 -0400 From: vcerf@NRI.Reston.VA.US To: tcp-ip@nic.ddn.mil Cc: jif@venera.isi.edu Subject: What is the IAB?
Roy Smith: Please see RFC 1120 which you can obtain by anonymous FTP from the DDN NIC (nic.ddn.mil). This RFC will be updated soon to reflect the addition of several new members to the IAB (Tony Lauck from Digital Equipment Corporation and Lyman Chapin of Data General - who is also chairman of ANSI X3S3.3). Those interested in IAB actions may find monthly summaries in the Internet Monthly published by Joyce K. Reynolds and Jonathan Postel of USC-ISI. The Executive Director of IAB is Bob Braden also of ISI. Vint Cerf Chairman, IAB Corp. for National Research Initiatives
-----------[000145][next][prev][last][first]---------------------------------------------------- Date: 13 May 90 22:20:49 GMT From: ka9q.bellcore.com!karn@bellcore.com (Phil Karn) To: tcp-ip@nic.ddn.mil Subject: Re: A SUSPICIOUS SECURE GATEWAY
I have a few comments on the use of gateway filtering for security purposes. In my opinion, it is suitable only as a temporary, emergency response to an actual attack, and for "buying time" until the security holes in individual hosts can be fixed. It is admittedly preferable to going off the Internet entirely. As standard operating procedure, however, gateway filtering has two serious drawbacks: 1. It makes life much more difficult for the legitimate users. You are often forced to "stage" your operations through a "secure" gateway. This is not the seamless, easy-to-use network that the Internet was supposed to be all about. 2. It is not entirely secure, either. The usual goal in gateway filtering is to allow locally originated connections to go out while keeping externally originated ones from coming in except to specified hosts. But an IP router is a connectionless entity, so this can only be done heuristically, typically by violating layering and examining the destination port fields of the TCP and UDP headers. Although it is currently fashionable to think of the "layering violation" as an obsolete taboo, experience has taught me to stop and think hard before committing one because they have a way of coming back to bite you, albeit not for a while. The problem here is that "only the hosts know for sure" when it comes to the meaning of a port number. True, *most* do adhere to Internet convention in that servers usually listen on ports less than 1000 while clients usually originate using ports above 1000, so a gateway that discards incoming packets destined to ports below 1000 *usually* has the desired effect of allowing outbound traffic while blocking incoming traffic. But what about hosts that don't follow this convention? I only recently discovered that Xylogics AnnexII terminal servers listen on TCP port 5000 in addition to the standard Telnet port, 23. So if somebody puts up an Annex box on your "safe" network and doesn't turn on the security option, he has just made all the hosts on your network accessible from the outside even though your gateway is supposedly blocking all incoming traffic. And even if you take care of this specific problem, how do you know that somebody on some machine somewhere on your network isn't running a homegrown server that listens on an unrestricted port, creating yet another opening? I feel very strongly that true Internet security can only be achieved when it is widely recognized that each host must take the responsibility of protecting itself instead of relying on other network entities to do it. Yes, it takes more work to do it right, but the results will be worth it. Phil
-----------[000146][next][prev][last][first]---------------------------------------------------- Date: Mon 14 May 90 10:26:55-PDT From: Ole J. Jacobsen <OLE@CSLI.Stanford.EDU> To: tcp-ip@nic.ddn.mil Cc: ietf@venera.isi.edu Subject: Commercial IP service offerings
Hi, One of the sessions planned for INTEROP 90 (Oct 8-12) deals with commercial IP services, that is companies offering internet (or Internet) connectivity for a fee. We know about PSI and UUNET's AlterNet, but we are looking for concrete information about RBOCs offering similar services. So far, all I've heard are rumors. Any information would be greatly appreciated. Thanks, Ole -------
-----------[000147][next][prev][last][first]---------------------------------------------------- Date: Mon, 14 May 90 12:22:07 -0400 From: Michael T. Stolarchuk <mts@terminator.cc.umich.edu> To: zessel%popper%incas%uklirb%unido%mcsun.uucp@uunet.uu.net Cc: tcp-ip@nic.ddn.mil Subject: Re: question about caching in UDP based RPC (AND bug in UDP Cache?!)
>>The trick to caching UDP/RPC results it to cache exactly one result for >>each client the server has. The cost is 8K per client, max. You never >>need to cache more than one response from each client, since a client >>will only send a new RPC only if the old one has been completed. >This is a good idea. I believe there are some exceptions to the 1 reply >per request rule, however. I believe the "spray" application will blast >a host with a number of packets before requiring a reply. I don't really want to get too involved in this discussion, but I have decided to add my (short) thoughts. Maybe I'm adding some complexity to an already noisy issue... One of the (current) largest uses of RPC's around here is for NFS. I mentioning that not because I think we ought to tune RPC's for NFS, but rather to point out that there are RPC's which are used to exchange large amounts of data. Painful delays exist. Partially due to (MOST) RPC's not using windoing to transmit data... like TCP... Mostly people make a decision not to do windoing since they assume they are shipping small amounts of data... I don't windowing will help NFS too much, since most of the UDP packets it wants to send out are either 8 or 4k. But if your needs are 'exchange of large amounts of data in one direction' and you would like to use an RPC, some attributes of TCP would be *real nice*. mts. the snail. ann arbor, mi.
-----------[000148][next][prev][last][first]---------------------------------------------------- Date: Mon, 14 May 90 11:02:13 EDT From: jas@proteon.com (John A. Shriver) To: tcp-ip@nic.ddn.mil Subject: Lantastic vs. the World (& Novell) - Problems?
Oh boy, another protocol using IEEE 802.3 without IEEE 802.2! Novell NetWare does that out of the box on "Ethernet" as well. I bet Lantastic and Novell NetWare absolutely go crazy trying to share one Ethernet! I guess people still don't understand the why's and wherefores of layered network architectures. My Sun with ISO didn't crash over NetWare, but it did log one message to disk for every NetWare broadcast packet. Ran out of disk space real fast. At least you can repair NetWare, using the barely documented ECONFIG program. It will change back to using Ethernet frames with type 8137, at least for most NetWare Ethernet drivers.
-----------[000149][next][prev][last][first]---------------------------------------------------- Date: Mon, 14 May 90 14:00:21 GMT-0400 From: ad@cis.brown.edu (Arif Diwan) To: tcp-ip@nic.ddn.mil Subject: "pop" Reply to Lloyd Buchanan
>>>Original msg<<< ... Is there a BSD/SunOS compatible version .... >>>EOM<<< We have three BSD compatible pop servers: 1. POP II which came from IBM YorkTown which has been hacked around at several sites 2. MHPOP by Marshall T. Rose, which we have used 3. MHPOP modified at MIT using Kerberos authentication. You can get the latter two from athena-dist.mit.edu. If you use the Kerberized version you will also need the Kerberos authentication package from athena-dist. We are using that with another package from MIT - Techmail. Which runs on the MAC. It is great. That is also available from athena-dist via anonymous ftp.
-----------[000150][next][prev][last][first]---------------------------------------------------- Date: 14 May 90 13:57:08 GMT From: axecore!lloyd@uunet.uu.net (Lloyd Buchanan) To: tcp-ip@nic.ddn.mil Subject: pop
Just received a marvelous, though expensive, product for the Macintosh called TCP/Connect. For the purpose of receiving mail, this program requires a "pop" server. Never heard of it. Is there a BSD/SunOS compatible version of this protocol around. Please email any suggestions. thanks -- Lloyd Buchanan lloyd@Axecore.COM Axe Core Investors uunet!axecore!lloyd Axe Castle (914) 333-5226 (phone) Tarrytown, NY 10591 (914) 333-5208 (FAX)
-----------[000151][next][prev][last][first]---------------------------------------------------- Date: 14 May 90 17:56:42 GMT From: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!nic.MR.NET!ns!jmh@tut.cis.ohio-state.edu (Joel Halpern) To: tcp-ip@nic.ddn.mil Subject: Re: A SUSPICIOUS SECURE GATEWAY
An article proposed using a filtering gateway to improve security of an internet connection. Phil commented that he considers this an emergency measure, and pointed out that one telnet server listens on port 5000, which breaks the filtering. I agree with Phil (and several other people) that overall security requires that hosts be improved. I will note however that, by assumption, perfect security is impossible. There will always be holes. Ignoring the case where you do not know what your local servers are doing, a filtering gateway can provide significant security enhancements. It is certainly not perfect. But the statelessness is not a difficulty, if the filtering can be sufficiently smart. We have a router here which filters such that I can initiate FTP sessions outward from my host, but they can not be initiated inwards. Similarly with regard to telnet. Now, we have a machine which does have inward access, and if security were breached on that one could go anywhere. Therefore, we can focus most of our energy on managing that machine well. (Not that we can neglect everything else, but it is ehlpful to know where ones biggest weakness is.) Joel M. Halpern jmh@nsco.network.com Network Systems Corporation
-----------[000152][next][prev][last][first]---------------------------------------------------- Date: 14 May 90 23:32:43 GMT From: cayz@louie.udel.edu (James Cayz) To: tcp-ip@nic.ddn.mil Subject: Mac <-> SMTP via Enet box info needed
Hi all, If this is posted in the wrong place, I do apologize, I tried to pick the most applicable groups.... Scenerio: Localtalk Net, Macs for now, PC probably later, using LocaltalkPC or LocaltalkPS/2 cards, all on Farallon network. Ethernet, with a KA9Q-based SMTP server in-place (IBM PC), 2 IBM PC/AT's with 3C501 or 503 cards in them, running (as need be) KA9Q (for mail), and NCSA (for telnet, etc) (Can't get KA9Q termcap on remote Unix boxes to work right!). Questions: I am looking for Mail for the Macs. Both Mac<->Mac and Mac<->Outside world (via Ethernet). I know that most Mac<->Mac systems require a server, which I don't have available (I have an AppleShare Server, with the Printer Spooler in the foreground, and a 128K Mac working not doing anything). I would like to know: 1) Are there any mac<->mac systems that don't require a server (or maybe use a 128K Mac, or a remote server on the Ethernet?) ??? 2) Are there any Mac<->Ethernet smtp systems, given that I get a Fastpath, Shiva EtherGate (with TCP/IP) or GatorBox? KA9Q for the Mac??? 3) If there are no server-less mac<->mac systems, but there are mac<->smtp systems, can I go macA->smtp->macB given some funky routing on my smtp router? Please, Please, Please mail all replies directly to me, cayz@louie.udel.edu (Internet). I don't get to read this groups as often as I should..... Thank you all in advance for your replies. James Cayz |James Cayz can be found via: USPS: Educational Technology Laboratory |EMAIL Internet: cayz@louie.udel.edu : 203 Willard Hall Education Building |PHONE: +1 302 451-6307 : University of Delaware, Newark DE 19716
-----------[000153][next][prev][last][first]---------------------------------------------------- Date: Tue, 15 May 90 10:43:25 PDT From: braden@venera.isi.edu To: iesg@venera.isi.edu, ietf@venera.isi.edu, irsg@venera.isi.edu, tcp-ip@nic.ddn.mil Subject: IAB Monthly Report -- April 1990
IAB Report for April 1990:
A. MEETING
The IAB held a video teleconference on May 26, 1990. Minutes of this
meeting will be published as soon as possible.
B. STANDARDS ACTIONS
During April, the IAB took the following actions concerning Internet
standards, following recommendations from the IESG. These changes
will be reflected in the next edition of the IAB Official Protocols
RFC.
1. Advance to Standard:
SNMP -- Simple Network Management Protocol (RFC-1098)
SMI -- Structure and Identification of Management Information
for TCP/IP-based internets (RFC-1065)
MIB I -- Management Information Base for Network Management
for TCP/IP-based internets (RFC-1066)
2. Advance to Draft Standard:
RFC-1006 -- ISO Transport Service on top of TCP
RIP -- Routing Information Protocol (RFC-1058)
NICNAME -- WhoIs Protocol (RFC-954)
3. Designate as Proposed Standard:
MIB II -- Extensions to MIB
OSPF -- Open Shortest Path First IGP (RFC-1131)
4. Retain as Proposed Standard:
NNTP -- Network News Transfer Protocol (RFC-977)
5. Move back to Experimental:
VMTP -- Versative Message Transaction Protocol (RFC-1045)
C. STANDARDS STATUS
The IAB has held extensive discussions on possible improvements in
the way that status (e.g., Elective vs. Recommended) and
applicability is attached to Internet protocol specifications, but
decision has not yet been reached on these issues. The intent of
any change would be to give vendors and users better guidance in
determining the relevance of each standard.
The IAB welcomes constructive input from any member of the Internet
community on these and any other issues relating to the standard-
ization process. Send comments to Vint Cerf, chair of the IAB
(VCerf@NRI.RESTON.VA.US) or to Phill Gross, chair of the IETF
(PGross@NRI.RESTON.VA.US).
D. WORKING WITH ANSI
Three members of the IAB, along with interested IETF members, met
with ANSI X3S3.3 on April 18 and April 20 in Tucson, Arizona. At
that meeting we discussed the possibility of introducing several
new work items for entering IP, ICMP, TCP and UCP into the American
National Standards track. A vote by the members of X3S3.3 was put
off until June 27th, to allow X3S3.3 members to discuss these
proposals with their respective organizations and to come to
conclusions about the advisability and feasibility of entering the
TCP/IP protocols into ANSI.
Joint work with ANSI is already under way within the IETF OSI area,
specifically with respect to the IS-IS dual routing protocols (OSI
and TCP/IP). It is anticipated that joint meetings or, at least,
colocated IETF and ANSI X3S3.3 meetings, will be scheduled in the
future.
Bob Braden
-----------[000154][next][prev][last][first]---------------------------------------------------- Date: Tue, 15 May 90 12:36:34 MST From: cire|eric <cire@cisco.com> To: hal@gateway.mitre.org (Hal Feinstein) Cc: tcp-ip@nic.ddn.mil, dscott@gateway.mitre.org Subject: Re: SNAP on Ethernet
Hal, Your message appeared very confusing to me. Perhaps I can clear some of that up. SNAP (Sub-Network Access Protocol, don't ask me) is a 5 byte header appended after the 802.2 header in 802 packets. Its use is denoted by the use of the LSAPs 0xAA (170 decimal, internet network order) and Unnumbered Information. It consists of two fields, a three byte OUI (organizational unique identifier) and a prototcol type. The OUI identifies the prototcol family that the protocol type field values come from. One common use of SNAP is to allow the use of ethernet type codes to denote what kind of information is inside a packet. You will have a MAC header (802 mac), 802.2 header (DSAP=0xAA, SSAP=0xAA, CTL=0x3 (UI)), SNAP header (OUI=0x000000, type field), and protocol data. The type field for an OUI of 0 is exactly the same 16 bits of what Ethernet uses. >> Date: Tue, 15 May 90 10:47:29 EDT >> From: hal@gateway.mitre.org (Hal Feinstein) >> Subject: SNAP on Ethernet >> >> The Subnetwork Addressing Protocol is an 8 byte long auxiliary protocol >> defined by ISO to rides just above the Ethernet LLC layer to indicate >> (among other things) the protocol ID of the next higher layer of >> protocol (IP, ARP, etc.). There is talk of using SNAP with IP-on-Ethernet, >> replacing the current trick (see RFC-1042) used to identify this >> next higher protocol layer. But the jury is out as >> far as if and when this replacement will occur. RFC-1042 defines how to use SNAP to encapsulate protocols using ethertypes and notably IP on 802 media. Since 802.3 is already an 802 media it already defines how do using snap on 802.3. At this time few people do it. There is no such thing as using SNAP with IP-on-Ethernet. It is IP on 802.3 which would use 1042 mechanisms including SNAP to incapsulate the IP packet. There is no jury. Whether this is implemented or not depends mostly on vendor implementations in primarily the end nodes. Yes routers have to do it too. However, this stuff already exists and some people are using it. >> I'm trying to get a better view of what experiences people have using or >> planning for SNAP (if they have at all) and what commercial products >> people have run into (gateways for example) that contemplate introducing >> it. Is it worth designing into a future product? Any information would >> be highly appreciated. Cisco already handles SNAP'd protocols. >> Thanks in advance. -hal@gateway.mitre.org -c cisco engineering
-----------[000155][next][prev][last][first]---------------------------------------------------- Date: Tue, 15 May 90 10:47:29 EDT From: hal@gateway.mitre.org (Hal Feinstein) To: -v@gateway.mitre.org, tcp-ip@nic.ddn.mil Cc: dscott@gateway.mitre.org Subject: SNAP on Ethernet
The Subnetwork Addressing Protocol is an 8 byte long auxiliary protocol defined by ISO to rides just above the Ethernet LLC layer to indicate (among other things) the protocol ID of the next higher layer of protocol (IP, ARP, etc.). There is talk of using SNAP with IP-on-Ethernet, replacing the current trick (see RFC-1042) used to identify this next higher protocol layer. But the jury is out as far as if and when this replacement will occur. I'm trying to get a better view of what experiences people have using or planning for SNAP (if they have at all) and what commercial products people have run into (gateways for example) that contemplate introducing it. Is it worth designing into a future product? Any information would be highly appreciated. Thanks in advance. -hal@gateway.mitre.org
-----------[000156][next][prev][last][first]---------------------------------------------------- Date: Tue, 15 May 90 13:15:08 EDT From: Dave_Katz@um.cc.umich.edu To: tcp-ip@nic.ddn.mil Cc: dscott@gateway.mitre.org Subject: SNAP on Ethernet
>The Subnetwork Addressing Protocol is an 8 byte long auxiliary protocol >defined by ISO to rides just above the Ethernet LLC layer to indicate >(among other things) the protocol ID of the next higher layer of >protocol (IP, ARP, etc.). There is talk of using SNAP with IP-on-Ethernet, >replacing the current trick (see RFC-1042) used to identify this >next higher protocol layer. But the jury is out as >far as if and when this replacement will occur. A few technical nits: The Subnetwork *Access* Protocol (SNAP) is defined by IEEE 802.1a and is *5* bytes long. It rides just above the *802.2* LLC layer (which in turn runs over 802.3, *not* Ethernet). The SNAP protocol is intended to be used by "non-standard" protocols (those not assigned an LSAP value by IEEE), and includes a 3 octet Organizationally Unique Indentifier (OUI, otherwise known as the Manufacturer ID in MAC addresses) and a 2 octet protocol indentifier assigned by the owner of the OUI. If the OUI field is all zeroes, the protocol identifier field is defined as carrying the familiar 2 octet Ethernet Type value. This is the more- or-less standard way of carrying Ethernet protocols across true 802 media (which cannot use the EtherType field). RFC1042 in fact uses the SNAP "trick" to carry IP and ARP over 802 media, and RFC1103 (and the Internet Draft that replaces it) specifies the same for FDDI. The use of SNAP to carry IP over 802 media is extremely unlikely to change. Be careful about the terms "Ethernet" and "802.3"--they refer to the same media, but different framing conventions. Ethernet frames carry a 2 octet type field for higher layer protocol identification, while 802.3 frames carry a 2 octet length field and a 3 octet 802.2 LLC header. Both can run simultaneously on the same wire. There is very little use of 802.3/SNAP for IP, due to interoperability difficulties with Ethernet/IP. 802.5/SNAP/IP is used exclusively on token rings, and FDDI/SNAP/IP will be used on FDDI rings.
-----------[000157][next][prev][last][first]---------------------------------------------------- Date: Tue, 15 May 90 17:12:19 PDT From: braden@venera.isi.edu To: hal@gateway.mitre.org, jas@proteon.com Cc: -v@gateway.mitre.org, dscott@gateway.mitre.org, tcp-ip@nic.ddn.mil Subject: Re: SNAP on Ethernet
Not implementing SNAP in an IEEE 802.2 implementation would be incredibly shortsighted, unless the only protocol stack you want is ISO. It would also violate the Host Requirements RFC; please see section 2.3.3 of RFC-1122. Bob Braden
-----------[000158][next][prev][last][first]---------------------------------------------------- Date: Tue, 15 May 90 14:40:42 EDT From: jas@proteon.com (John A. Shriver) To: hal@gateway.mitre.org Cc: -v@gateway.mitre.org, tcp-ip@nic.ddn.mil, dscott@gateway.mitre.org Subject: SNAP on Ethernet
SNAP is not used on Ethernet. (It uses Ethernet types.) You might see SNAP used on IEEE 802.3, as well as IEEE 802.4 and IEEE 802.5. In all cases, it runs on top of IEEE 802.2. The definition of SNAP will be in IEEE 802.1a, whenever it is approved. It's in the current draft. Almost all protocols on IEEE 802.2 will use SNAP, since IEEE 802.2 SAP's are only available to protocols defined by established international standards bodies. Realize that the (generally unused) DoD IP SAP in IEEE 802.2 was an *exception* to these rules, and they would not give out a further SAP for ARP. (The need for ARP is what caused us to search out SNAP.) However, anyone who owns a vendor block (3-byte prefix of Ethernet/IEEE 802 address) can assign his own SNAP types. Also, vendor block 00-00-00 incorporates the existing Xerox-assigned Ethernet types. SNAP is only 5 bytes. The preceeding IEEE 802.2 is 3 bytes. This sums to 8 bytes. Not implementing SNAP in an IEEE 802.2 implementation would be incredibly shortsighted, unless the only protocol stack you want is ISO.
-----------[000159][next][prev][last][first]---------------------------------------------------- Date: 15 May 90 14:20:37 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!jh@ucsd.edu (Juha Heinanen) To: tcp-ip@nic.ddn.mil Subject: Re: Commercial IP service offerings
In Finland there has been a commercial IP service called DataNet offered by the state PTT for about a year now. It's backbone covers all major cities in Finland and has many large and small customers. Another competing IP service called LanLink is starting operation in September. You will meet people from both of these in Interop 90. -- -- Juha Heinanen, Tampere Univ. of Technology, Finland jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)
-----------[000160][next][prev][last][first]---------------------------------------------------- Date: 15 May 90 16:00:00 GMT From: usc!zaphod.mps.ohio-state.edu!sdd.hp.com!apollo!apollo.hp.com!mishkin@ucsd.edu (Nathaniel Mishkin) To: tcp-ip@nic.ddn.mil Subject: Re: question about caching in UDP based RPC (AND bug in UDP Cache?!)
In article <9005141622.AA17355@terminator.cc.umich.edu>,
mts@TERMINATOR.CC.UMICH.EDU (Michael T. Stolarchuk) writes:
|> Painful delays exist. Partially due to (MOST) RPC's not using windoing
|> to transmit data... like TCP...
|>
|> Mostly people make a decision not to do windoing since they assume
|> they are shipping small amounts of data... I don't windowing will
|> help NFS too much, since most of the UDP packets it wants to send out
|> are either 8 or 4k.
|>
|> But if your needs are 'exchange of large amounts of data in one direction'
|> and you would like to use an RPC, some attributes of TCP would be
|> *real nice*.
Yeah, I'll admit that when I built the first version of our RPC system
(NCS), I said: "Ah, who'd want to send more than a few K of data in
a remote call anyway; why bother with all the hair?" But of course,
it's not only the file system types who want to do that, but you run
into these people who want to pass some 1000x1000 array of double precision
floating point numbers from their workstation to their minisuper. I
heard from them pretty quick. The latest version of our system does
windowing just like the big boys. The hard thing is to keep the machinery
that supports all that out of the way of the person who wants to make
a call whose in's and out's can each be represented in one datagram.
-- Nat Mishkin
Hewlett Packard Company / Apollo Systems Division
mishkin@apollo.com
-----------[000161][next][prev][last][first]---------------------------------------------------- Date: 15 May 90 19:36:34 GMT From: cire@CISCO.COM (cire|eric) To: comp.protocols.tcp-ip Subject: Re: SNAP on Ethernet
Hal, Your message appeared very confusing to me. Perhaps I can clear some of that up. SNAP (Sub-Network Access Protocol, don't ask me) is a 5 byte header appended after the 802.2 header in 802 packets. Its use is denoted by the use of the LSAPs 0xAA (170 decimal, internet network order) and Unnumbered Information. It consists of two fields, a three byte OUI (organizational unique identifier) and a prototcol type. The OUI identifies the prototcol family that the protocol type field values come from. One common use of SNAP is to allow the use of ethernet type codes to denote what kind of information is inside a packet. You will have a MAC header (802 mac), 802.2 header (DSAP=0xAA, SSAP=0xAA, CTL=0x3 (UI)), SNAP header (OUI=0x000000, type field), and protocol data. The type field for an OUI of 0 is exactly the same 16 bits of what Ethernet uses. >> Date: Tue, 15 May 90 10:47:29 EDT >> From: hal@gateway.mitre.org (Hal Feinstein) >> Subject: SNAP on Ethernet >> >> The Subnetwork Addressing Protocol is an 8 byte long auxiliary protocol >> defined by ISO to rides just above the Ethernet LLC layer to indicate >> (among other things) the protocol ID of the next higher layer of >> protocol (IP, ARP, etc.). There is talk of using SNAP with IP-on-Ethernet, >> replacing the current trick (see RFC-1042) used to identify this >> next higher protocol layer. But the jury is out as >> far as if and when this replacement will occur. RFC-1042 defines how to use SNAP to encapsulate protocols using ethertypes and notably IP on 802 media. Since 802.3 is already an 802 media it already defines how do using snap on 802.3. At this time few people do it. There is no such thing as using SNAP with IP-on-Ethernet. It is IP on 802.3 which would use 1042 mechanisms including SNAP to incapsulate the IP packet. There is no jury. Whether this is implemented or not depends mostly on vendor implementations in primarily the end nodes. Yes routers have to do it too. However, this stuff already exists and some people are using it. >> I'm trying to get a better view of what experiences people have using or >> planning for SNAP (if they have at all) and what commercial products >> people have run into (gateways for example) that contemplate introducing >> it. Is it worth designing into a future product? Any information would >> be highly appreciated. Cisco already handles SNAP'd protocols. >> Thanks in advance. -hal@gateway.mitre.org -c cisco engineering
-----------[000162][next][prev][last][first]---------------------------------------------------- Date: Wed, 16 May 90 09:38:46 -0400 From: "Louis A. Mamakos" <louie@sayshell.umd.edu> To: tcp-ip@nic.ddn.mil, jmh@ns.network.com (Joel Halpern) Subject: Re: A SUSPICIOUS SECURE GATEWAY
> We have a router here which filters such that I can initiate FTP > sessions outward from my host, but they can not be initiated inwards. > Similarly with regard to telnet. I wonder what would happen if I kludged up a client telnet that used a local port number of 23, and then tried to connect to your TELNET server? Maybe you thought about this particular problem, but there are lots of interesting things you can do with source routed packets. I know that I can't sleep any better at night knowing that I have a filtering gateway "protecting" me. If you want security, you need to take a comprehensive approach to providing it, not shots in the dark here and there. louie
-----------[000163][next][prev][last][first]---------------------------------------------------- Date: Wed 16 May 90 18:44:31-PDT From: William "Chops" Westfield <BILLW@mathom.cisco.com> To: kwe@bu.edu Cc: tcp-ip@nic.ddn.mil Subject: Re: Max FDDI frame rate on the glass
With FDDI things get more complicated. FDDI signals in 5 bit symbols.
Four bits of data go into every five bits on the wire, so a byte takes
10 bits.
:
:
Then; 10**8 bits/sec x (1 frame/675 bits) = 148,000 pps
Well, if you are going to count the 4 to 5 encoding, then you also have
to count the wire data rate as 1.25e8 bps. The 100 Mbps everyone talks
about is AFTER the funny bit encoding... I doubt this makes much difference
the the 10x faster generalization.
BillW
-------
-----------[000164][next][prev][last][first]---------------------------------------------------- Date: 16 May 90 14:23:08 GMT From: e2big.dec.com!shlump.nac.dec.com!killie.enet.dec.com!colliton@decuac.dec.com To: tcp-ip@nic.ddn.mil Subject: tcp protocol
Is there a field in the tcp protocol or other protocol that will allow
me to collect/rollup stats (frames, byte , duration ) on active between ports
by user. I do not wish to identify the user but log the start of
active and
collect stats to the end of the active.
Luke
-----------[000165][next][prev][last][first]---------------------------------------------------- Date: 16 May 90 16:13:08 GMT From: mailrus!accuvax.nwu.edu!delta.eecs.nwu.edu!morrison@uunet.uu.net (Vance Morrison) To: tcp-ip@nic.ddn.mil Subject: 56K, T1 Boards for PC : cheap bridge/IP router
Hello
Here are the results from my question on synchronous serial (56K or T1)
cards for the IBM-PC. Actually I got many more requests for this information
than reply's giving information, so the list below is not that long.
I am certainly willing to post an adendum to this list if anyone else
knows of any leads that do not apear below.
For those intrested in cheap bridges or routers, check my comment
below on Emerging Technologies. They are commercially selling a
product very simmilar to PCroute/bridge (but developed independantly).
Note that I have no knowledge of how good or bad this product is and
have no stake in its success. I merely present the information
because I believe it may be on interest to those who for whatever
reason can't/won't use PCroute/bridge.
Vance
-----------------------------------------------------------------------
From: "John D. Balogh" <JDB@ecl.psu.edu>
Check out the Proteon p4100 router options. That box is approximatly a PC with
some option cards (Ethernet, Token Ring, SIO (Slow {56K}, Fast {T1}).
I would assume that Proteon selected "good" SIO cards for thier box.
-----------------------------------------------------------------------
From: macy@fmsystm.UUCP
I understand Dialogic makes such a beast. They have offices
in Austin, TX and in the Boston area.
---------------------------------------------------------------------------
From: "Dennis E. Baasch" (516)271-4525 <dennis@etinc.UUCP>
Regarding your request for high speed synchronous cards for a PC,
Emerging Technologies has several cards which might meet your requirements.
We have both 8 and 16-bit cards, with each card a few different options.
The 8-bit card will run any speed up to 1.544mbs, while the 16-bit card
will run 2.048mbs. We're coming out with a new 8-bit card (which will be
100% software compatible with the existing one) in a couple of months.
Both cards have a LAPB/HDLC chip which provide co-processor like
functionality with a high-speed access shared memory interface. The cards
are capable of about 3500 frames per second at 1.544mbs.
There are 2 development type products available for the cards, both
with 'C' language interfaces and drivers for MS-DOS or SCO XENIX. One is
an HDLC development system, and the other is a full X.25 development system.
Both use the same drivers for the cards, and both can support up to 4 cards
per machine. The X.25 driver allows individual cards to be run in HDLC mode,
allowing for mixed-mode applications (like routers) where you need a T1
line and an X.25 line.
The 8-bit card (8mbs bus transfer rate) with a V.35 interface is
priced at $725 for 56kbs and $925 for T1. The 16-bit card (14mbs transfer
rate) is $995 for 56kbs and $1495. for T1. The HDLC driver is $285 per
CPU, X.25 is $375. per CPU, and there is a one-time fee of $325. for the
'C' libraries for either product.
For further info, send me your address or give me a call
at (516) 271-4525.
900 Walt Whitman Rd.
Melville, NY. 11747
Note: Denis is the Network Products manager for Emerging Technologies.
---------------------------------------------------------------------------
From: "Steven P. Donegan" <donegan@usc.edu>
The Sea Level Systems ACB-II card does quite a nice job of sync HDLC handling
at speeds from 0 to 1.544 MBPS.
Sealevel Communications & I/O
P.O. Box 1808
Easley, SC 29641
803-855-1581
---------------------------------------------------------------------------
Additional Comments: I check into the cards offered by Emerging Technologies
and SeaLevel Systems and have some addtional Info on them
Emerging Technologies:
From what I could tell Emerging Technologies is actually
in the buisness of selling a router/bridge that works
on a IBM PC. (Basically PCroute/bridge). However in
some ways it is superior. For example their package has
SNMP, T1 and X.25 interface (if desired), as well as
(I assume) support. There prices are actually pretty
good (for $2500 you could put together a nice
ether-ether bridge or router). They do sell the
T1 and X.25 cards seperately but the price is reasonably
steep (since that is not really what they are in the
business of selling). They do have XENIX and DOS
drivers for those who are interested.
Sea Level Systems:
The ACB-II card Steve talks about is a nice board
and has a good price ($299). Also for $20 more you
can get a board that is identical except that it has
two serial interfaces instead of just one.
The literature I have says the ACB-II only goes up
to about 1.0 MBit/Sec. This precluded T1 use.
However talking with the people at SLS, it seems that
reasonably easy hardware mods may fix that. If enough
people ask, I suspect they would come out with a card
capable of T1 speeds.
DISCLAMER: I am only relying what I read from the literature I have.
Thus take all of this with a grain of salt. If you
REALLY want to know, call these people up yourself and ask.
Vance
-----------[000166][next][prev][last][first]---------------------------------------------------- Date: Wed, 16 May 90 23:31:59 PDT From: Greg Satz <satz@cisco.com> To: swrinde!cs.utexas.edu!oakhill!guri@ucsd.edu (Gurvinder Singh Ahluwalia) Cc: tcp-ip@nic.ddn.mil Subject: Re: "LARP" on Port 91 ?
According to the latest Assigned Numbers RFC, protocol number 91 is:
91 LARP Locus Address Resolution Protocol [BXH]
and BXH is:
[BXH] Brian Horn Locus ---none---
Apparently LARP is a protocol above IP, so any router, including those from
cisco Systems, Inc., should forward those packets just fine.
If you have any further questions about cisco products or technical
issues/interoperability questions, feel free to drop a note to
customer-service@cisco.com.
Greg Satz
cisco
-----------[000167][next][prev][last][first]---------------------------------------------------- Date: 16 May 90 18:59:54 GMT From: psuvm!ysub!doug@psuvax1.cs.psu.edu (Doug Sewell) To: tcp-ip@nic.ddn.mil Subject: tcp-ip source for SysV multi-user environment
I'm looking for tcp-ip source for a small SysV multi-user environment - sufficient to support telnet in/out, ftp in/out, and e-mail in/out. There will not be very many concurrent users. I looked at the KA9Q SysV source (thanks to those that directed me to vax.cs.pitt.edu) but as far as I could tell could support only one user at a time. I've also downloaded the Berkeley source, but I'd rather not attempt to convert the code to SysV myself. I will be writing my own driver for a non-standard adapter. Any help, pointers, and recommendations are welcome. Please reply to me directly at one of the addresses below (doug@ysub.ysu.edu is probably best). I have FTP available, but no UUCP. Doug Sewell, Tech Support, Computer Center, Youngstown State University, Youngstown, OH 44555 E-mail: DOUG@YSUB.BITNET, DOUG@YSUB.YSU.EDU, ...!uunet!ysub.bitnet!doug >> I am not a wizard. What I do isn't magic. I am a computer professional.
-----------[000168][next][prev][last][first]---------------------------------------------------- Date: 16 May 90 19:05:38 GMT From: swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bu.edu!kwe@ucsd.edu (Kent England) To: tcp-ip@nic.ddn.mil Subject: Max FDDI frame rate on the glass
I was wondering what the maximum packet per second rate an
FDDI network would experience if 3 million monkeys were running
telnet, ie minimum sized frames, across an FDDI backbone. I made some
calculations, with help from Ram Das Rao, who knows all about FDDI
frames, even if he hasn't seen many. :-)
With Ethernet the computation goes like so:
Interframe gap of 9.6 us = 96 bits = 12 bytes
Preamble 8
MAC 14
Data 46 min (that covers IP and TCP mins)
CRC 4
--
Total 84 bytes/frame
This is the absolute minimum frame size that an Ethernet can support
on the wire, taking account of the interframe gap and all real bits.
Then; 10**7 bits/sec x (1 byte/8 bits) x (1 frame/84 bytes) = 14,880 pps.
Maximum sized packets fill up the wire at about 800 pps.
Those should be familiar numbers to most of you. With FDDI things get
more complicated. FDDI signals in 5 bit symbols. Four bits of data
go into every five bits on the wire, so a byte takes 10 bits. There
is also no interframe gap required in a token ring protocol.
For FDDI the calculations go like:
Preamble (PA/SD/FC) = 19 symbols = 95 bits
MAC 12 bytes =120 bits
Data (TCP min) 41 bytes =410 (there is no FDDI min value)
FCS/ED/FS 10 symbols = 50
---
Total 675 bits/frame (min size)
Then; 10**8 bits/sec x (1 frame/675 bits) = 148,000 pps
FDDI supports about 4k bytes as the maximum frame size. That
is approximately 4000 bytes at 10 bits/byte;
10**8 bits/sec x (1 frame/40,000 bits) = 2500 pps. So, max
sized packets fill up the wire at a 2500 pps rate, versus about 800
for Ethernet.
Conclusion:
Guess what? FDDI is 10x more than Ethernet, almost exactly.
Who would have thought? [So we aren't talking 3 million monkeys- more
like a quarter million would do the job.]
I thought you might be interested in the 150 kpps number for
future reference. Sock it away up in the gray matter along with 15
kpps for Ethernet. Or just know that the 10x approximation is
actually pretty good, all things considered.
--Kent
-----------[000169][next][prev][last][first]---------------------------------------------------- Date: 16 May 90 20:41:23 GMT From: swrinde!cs.utexas.edu!oakhill!guri@ucsd.edu (Gurvinder Singh Ahluwalia) To: tcp-ip@nic.ddn.mil Subject: "LARP" on Port 91 ?
Has anyone heard of a protocol called LARP?
Context in which I have encountered this is IBMs Transparent Cluster
Facility (TCF) on the 4381 running VM/AIX. IBM indicates it employs
port # 91.
For those out there aware of this and also running cisco routers,
I would like to go a step further to find out compatibility of this
protocol on ciscos, including access/passage of LARP traffic through
cisc.o Is there something that has to be enabled to allow LARP through
cisco? What is the default?
- Gurvinder
------
Gurvinder Ahluwalia Internet: guri@apogee.sps.mot.com
Software Engineer uucp : {}oakhill!apogee!guri@cs.utexas.edu
Global Networking Phone : 512/891-3310
Motorola SPS
Austin, TX.
------
-----------[000170][next][prev][last][first]---------------------------------------------------- Date: 16 May 90 21:10:57 GMT From: orion.oac.uci.edu!uci.edu!DHWalker@ucsd.edu (David Walker) To: tcp-ip@nic.ddn.mil Subject: Re: Max FDDI frame rate on the glass
Kent,
In article <57399@bu.edu.bu.edu> kwe@bu.edu (Kent England) writes:
> Conclusion:
>
> Guess what? FDDI is 10x more than Ethernet, almost exactly.
> Who would have thought? [So we aren't talking 3 million monkeys- more
> like a quarter million would do the job.]
Actually, I think it may really be more like 3 million, depending on the
size of the ring. Since FDDI allows a device to release the token after
finishing its transmission (rather than after it receives the message it
sent), it's possible to have multiple packets on the ring, particularly if
they're small packets. Does anyone feel like calculating how many packets
can be carried per second by FDDI as a function of the number of nodes and
length of fiber? I don't know enough about the delay introduced by each
node to do it.
David Walker
Network Services Manager
UC Irvine
DHWalker@uci.edu
-----------[000171][next][prev][last][first]---------------------------------------------------- Date: Wed, 16 May 90 08:21:43 +0900 From: David C. Hagiwara <Hagiwara@sm.sony.co.jp> To: ietf@venera.isi.edu, tcp-ip@nic.ddn.mil Subject: Info.wanted on Dial up PPP
Does anyone inplemnt "Dial up PPP" ? Are there any RFCs describing the matter on dialing ? (I have got the PPP of Perkins from CMU) Takashi Hagiwara (Hagiwara@Sm.Sony.Co.Jp)
-----------[000172][next][prev][last][first]---------------------------------------------------- Date: 17 May 90 00:52:00 GMT From: TAYBENGH@NUSDISCS.BITNET To: comp.protocols.tcp-ip Subject: RE: pinging a remote TCP port to see if it's in used
John Interrante,
>port number. I don't mind explaining that the reason I asked was to
>improve a portmapper I wrote for InterViews programs making RPC calls.
>We couldn't use Sun's /etc/portmap because we wanted servers to
>register their TCP port numbers under a variable-length string of
>characters (i.e., a name), not a tuple of integers (i.e., a program
>number and a version number). I noticed that SunOS 4.1's /etc/portmap
>will let you register the port number of a non-existent server, but it
Do u mean non-existent server as those server dies/crashes after
registerred the port number to portmap?
>will unregister the port number and give you zero when you try to ask
>for the non-existent server's port number. I set a breakpoint in a
>server to find out how portmap validated the server's port number and
>I know that the server never noticed a new connection. Yet portmap
>definitely WAS validating port numbers in some way because I never got
>a port number for a non-existent server. I checked the public RPC
>sources on gatekeeper.dec.com but the source for portmap didn't
>include this kind of code so that's why I posted my question. I
>wanted to be able to validate port numbers in my portmapper too
>because it would prevent clients from trying to connect to a server
>that crashed after registering its port number with the portmapper.
Since your server resides in the same host as portmap and your
server port number is kept by portmap, what you can do is to create a
dummy socket and bind this socket to the server port number. If the
bind fails and returns an error saying that the port number is in used, then
the server is still alive. If the binding is successful, then most likely
that particular server is dead since port number cannot be re-used. Note that
this technique can apply to check both UDP and TCP servers.
- Beng Hang Tay (email: taybengh@nusdiscs)
Dept. Info. and Comp. Sc.
National University of Singapore (NUS)
-----------[000173][next][prev][last][first]---------------------------------------------------- Date: Thu, 17 May 90 05:02 EDT From: Fitch@DOCKMASTER.NCSC.MIL To: tcp-ip@NIC.DDN.MIL Subject: COMTEN TCP
I would like to talk with someone about COMTEN TCP. COMTEN's are front-ends for IBM mainframes made by NCR. I believe they also market a TCP. Right now I'm looking for basic product info. Please provide a phone number if you care to help. Thanks. --Jack (Fitch -at dockmaster.ncsc.mil) (301)738-8018
-----------[000174][next][prev][last][first]---------------------------------------------------- Date: Thu, 17 May 90 08:14:02 EDT From: Frank Kastenholz <kasten%europa.interlan.com@RELAY.CS.NET> To: swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bu.edu!kwe@UCSD.EDU, tcp-ip@NIC.DDN.MIL Subject: Re: Max FDDI frame rate on the glass
> For FDDI the calculations go like: > > Preamble (PA/SD/FC) = 19 symbols = 95 bits > MAC 12 bytes =120 bits > Data (TCP min) 41 bytes =410 (there is no FDDI min value) > FCS/ED/FS 10 symbols = 50 > --- > Total 675 bits/frame (min size) > > Then; 10**8 bits/sec x (1 frame/675 bits) = 148,000 pps > > FDDI supports about 4k bytes as the maximum frame size. That > is approximately 4000 bytes at 10 bits/byte; > > 10**8 bits/sec x (1 frame/40,000 bits) = 2500 pps. So, max > sized packets fill up the wire at a 2500 pps rate, versus about 800 > for Ethernet. Kent, The FDDI signalling rate is 125,000,000 bits per second. With the 4/5 encoding, that comes to 100,000,000 effective data bits per second. This comes to just over 185Kpps for the telnet monkeys and 3032pps for the 4096 data byte packets. Frank Kastenholz Racal Interlan
-----------[000175][next][prev][last][first]---------------------------------------------------- Date: Wed, 16 May 90 16:52 H From: <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU> To: tcp-ip@nic.ddn.mil Subject: RE: pinging a remote TCP port to see if it's in used
John Interrante,
>port number. I don't mind explaining that the reason I asked was to
>improve a portmapper I wrote for InterViews programs making RPC calls.
>We couldn't use Sun's /etc/portmap because we wanted servers to
>register their TCP port numbers under a variable-length string of
>characters (i.e., a name), not a tuple of integers (i.e., a program
>number and a version number). I noticed that SunOS 4.1's /etc/portmap
>will let you register the port number of a non-existent server, but it
Do u mean non-existent server as those server dies/crashes after
registerred the port number to portmap?
>will unregister the port number and give you zero when you try to ask
>for the non-existent server's port number. I set a breakpoint in a
>server to find out how portmap validated the server's port number and
>I know that the server never noticed a new connection. Yet portmap
>definitely WAS validating port numbers in some way because I never got
>a port number for a non-existent server. I checked the public RPC
>sources on gatekeeper.dec.com but the source for portmap didn't
>include this kind of code so that's why I posted my question. I
>wanted to be able to validate port numbers in my portmapper too
>because it would prevent clients from trying to connect to a server
>that crashed after registering its port number with the portmapper.
Since your server resides in the same host as portmap and your
server port number is kept by portmap, what you can do is to create a
dummy socket and bind this socket to the server port number. If the
bind fails and returns an error saying that the port number is in used, then
the server is still alive. If the binding is successful, then most likely
that particular server is dead since port number cannot be re-used. Note that
this technique can apply to check both UDP and TCP servers.
- Beng Hang Tay (email: taybengh@nusdiscs)
Dept. Info. and Comp. Sc.
National University of Singapore (NUS)
-----------[000176][next][prev][last][first]---------------------------------------------------- Date: 17 May 90 06:31:59 GMT From: satz@CISCO.COM (Greg Satz) To: comp.protocols.tcp-ip Subject: Re: "LARP" on Port 91 ?
According to the latest Assigned Numbers RFC, protocol number 91 is:
91 LARP Locus Address Resolution Protocol [BXH]
and BXH is:
[BXH] Brian Horn Locus ---none---
Apparently LARP is a protocol above IP, so any router, including those from
cisco Systems, Inc., should forward those packets just fine.
If you have any further questions about cisco products or technical
issues/interoperability questions, feel free to drop a note to
customer-service@cisco.com.
Greg Satz
cisco
-----------[000177][next][prev][last][first]---------------------------------------------------- Date: Thu, 17 May 90 10:58:39 EDT From: Bill Streilein <bstreile@wellfleet.com> To: philipp@gipsi.gipsi.fr Cc: tcp-ip@nic.ddn.mil Subject: Arp on point-to-point
Phillipe, We solve this problem by running ARP over our point-to-point links. Although there's a direct connection to a specific host/gateway on the other side, this allows dynamic mapping. Bill Streilein / bstreile@wellfleet.com / Wellfleet Communications, Inc
-----------[000178][next][prev][last][first]---------------------------------------------------- Date: 17 May 90 07:04:03 GMT From: sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU (Rob Warnock) To: tcp-ip@nic.ddn.mil Subject: Re: Max FDDI frame rate on the glass
In article <2651C1E1.23165@orion.oac.uci.edu> DHWalker@uci.edu (David Walker) writes: +--------------- | ... Since FDDI allows a device to release the token after | finishing its transmission (rather than after it receives the message it | sent), it's possible to have multiple packets on the ring, particularly if | they're small packets. Does anyone feel like calculating how many packets | can be carried per second by FDDI as a function of the number of nodes and | length of fiber? +--------------- According to the FDDI MAC spec I have (ANSI draft X3T9.5/88-139 Revision 1), the maximum (idle-net) ring latency "D_Max" is 1.617 milliseconds, thus the longest permitted ring has 20212.5 bytes of delay in the ring. This is enough for about 4.5 maximum-length frames, or 631 claim frames, or just under 266 TCP/IP "ack" packets (assuming RFC 1103 encapsulation). This is why you don't wait for your message to come back. Ring throughput would be horrible if you did. -Rob p.s. The delay is a combination of fiber (speed-of-light) delay and station (MAC entity) delay. There is a max of 1000 "MAC entities" and a max of 2km between "PHY entities". (Loosely speaking, "PHY" is the optoelectronics, and "MAC" is the byte-level state machine. These aren't one-to-one, because you can have "single-attach stations" = 1 PHY / 1 MAC, "dual-attach" = 2 PHY / 1 MAC, "dual-MAC" = 2 PHY / 2 MAC, and "concentrator"= n+2 PHY/1 MAC.) The spec shows how this delay can results from 200km of fiber (100 km "circumference", to allow for ring "wrap" on failure) and 1000 stations, assuming 5.085ns/m in the fiber and 600ns (15 symbols) in the PHY/MAC. If on the other hand, you max out the distance between stations with single-MAC dual-attach stations, you get another set of numbers. Since a given fiber must be less than 2km, we have one 0.6us station delay (15 symbols, including PHY, MAC, elasticity buffer, etc.) and 20.34us fiber delay (2 fibers, 2km, 5.085ns/m) per hop. That gives 1617/20.94 or 77 stations max, for a 154km (duplex) circumference (308km of fiber). (I'm not sure this configuration is permitted. Anybody know?) ----- 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
-----------[000179][next][prev][last][first]---------------------------------------------------- Date: Thu, 17 May 90 13:31:08 CST From: POSTMASTER <CCBUSTER@VM.CC.OLEMISS.EDU> To: TCP-IP <tcp-ip@nic.ddn.mil> Subject: AEDAVIS
Please remove AEDAVIS@VM.CC.OLEMISS.EDU or AEDAVIS@UMSVM from this list. He is no longer here.
-----------[000180][next][prev][last][first]---------------------------------------------------- Date: 17 May 90 10:33:05 GMT From: mcsun!hp4nl!tnosoes!tom@uunet.uu.net (Tom Vijlbrief) To: tcp-ip@nic.ddn.mil Subject: Re: A SUSPICIOUS SECURE GATEWAY
louie@SAYSHELL.UMD.EDU ("Louis A. Mamakos") writes:
>> We have a router here which filters such that I can initiate FTP
>> sessions outward from my host, but they can not be initiated inwards.
>> Similarly with regard to telnet.
>I wonder what would happen if I kludged up a client telnet that used a local
>port number of 23, and then tried to connect to your TELNET server? Maybe
>you thought about this particular problem, but there are lots of interesting
>things you can do with source routed packets.
Filtering is done on destination port number (at least in my
adapted KA9Q) and not on host source port number. If you read the
posted README you would see that source-routed packets are rejected.
>I know that I can't sleep any better at night knowing that I have a filtering
>gateway "protecting" me. If you want security, you need to take a comprehensive
>approach to providing it, not shots in the dark here and there.
You are correct, but how can you be sure that a local network
with dozens of Unix boxes with different administrators are
correctly installing their machines ? (E.g. not export NFS-filesystems
to the world as is the default).
How can you be sure that hunderds of users have non trivial passwords, etc.
Eliminating access to NFS, rlogin, telnet, FTP, ... from the outside
world to all the machines (or a selected group of machines) does
certainly make ME sleep much better.
I think that inspecting each host on your network is an example
of "shots in the dark here and there". Is a secure gateway not
an example of a comprehensive approach because it does effect all hosts on your
local network? (The KA9Q-gateway for examples catches by default all
RPC calls, so for example rwalld calls are catched. Did you
for example disable the rwalld on every host on your local
network ? And would did you do about source-routed packet attacks ?)
Tom
-----------[000181][next][prev][last][first]---------------------------------------------------- Date: Thu 17 May 90 15:45:34-CDT From: AFDDN.BEACH@GUNTER-ADAM.AF.MIL To: tcp-Ip@nic.ddn.mil Cc: AFDDN.BEACH@GUNTER-ADAM.AF.MIL Subject: CLNS and routing (IS-IS) and ES-IS
Help....
.
.
Can anybody tell me where to get any info at all on proposed routing
protocols and implementations of them for the GOSIP world. I assume
OSPF will be used. What I'd really like is pointers to discussions
of how the routing would operate and clues on what implementations
might look like. I'd also like any comments on resource utilization.
I think the ISO address formats look a lot harder to deal with than IP.
Please send responses directly to me so as not to clutter up this list...
AND if there's another list I should be talking to, feel free to flame
as long as you tell me the list's address.
Going from TCP/IP is like teaching a sho'nuff southern boy to talk with
a french accent. It ain't easy!
Darrel B.
-------
-----------[000182][next][prev][last][first]---------------------------------------------------- Date: 17 May 90 12:53:26 GMT From: fernwood!portal!cup.portal.com!thad@uunet.uu.net (Thad P Floryan) To: tcp-ip@nic.ddn.mil Subject: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
{Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW}
{unix-pc.general,comp.sys.att,comp.dcom.lans,comp.protocols.tcp-ip}
If you have the WIN/3B card and the Wollongong Software on your 3B1, are YOU
happy with the performance?
My experiences recently show the 10Mbit/S Ethernet to be an order of magnitude
SLOWER than the 1Mbit/S StarLAN between the same two systems under identical
load conditions, etc. These tests were run on the SAME two systems with both
networks' cards and software installed.
To test, I alternated between:
ftp> put /unix (or get /unix depending on the direction)
and
uuto unix tlabs3!thad
multiple times. For uucp I've set up ",e" protocol; for the TCP/IP stuff
there isn't anything than can be set (yeah, I've read all the docs).
With uucp over StarLAN (1BASE5), the average tranfer is 40,000 to 50,000 bytes
per second, end-to-end, disk-to-disk.
With ftp over Ethernet (10BASE2 (ThinNet)), the average transfer is 5,000 to
8,000 bytes/second, end-to-end, disk-to-disk, though I once, just once, had
a peak of 24,000 bytes/second.
The only conclusion I can draw is that the Wollongong WIN/3B Applications
Package, version 1.4, for the UNIXPC/3B1 is seriously flawed. Some of the
support programs (e.g. telnet, sendmail, etc.) are buggy beyond belief, but
this level of "performance" is so poor I wonder if there's something I might
be missing.
And, yes, I did check whether the SQE (heartbeat) signal is enabled; it's not
(when it WAS enabled for another set of tests, the transfer rates dropped to
about 400 bytes/second, TWO orders of magnitude less than the StarLAN).
I placed a simple Ethernet monitor (POWER, Collision, Transmit, Receive LEDS)
on the AUI cables, and it looks like there's a 1/2 second of activity followed
by several seconds of NO activity ANYPLACE on the net ... this inactivity
would explain the poor overall transfer performance, but the question is "WHY?"
I'm convinced there's nothing wrong with the hardware.
I also ran some tests using the "loopback" mode, again using ftp with the same
file, and there wasn't any appreciable change in performance.
Also, if anyone knows how/where to get the Ethernet software for a Motorola
6300 (similar to the 3B1) for placement in /usr/sys/LAN/* in order to do a
sysgen, I'd appreciate hearing about that, too. My Motorola 6300 does have
the comm expansion card with the Ethernet D-15 (and the board uses the Lance
chip set, same as does the 3B1).
Thad
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
-----------[000183][next][prev][last][first]---------------------------------------------------- Date: Thu, 17 May 90 18:29:52 CDT From: stanley@visual1.tamu.edu (Stanley Guan) To: tcp-ip@nic.ddn.mil Subject: stanley@visual1.tamu.edu
Please remove me from this list.
-----------[000184][next][prev][last][first]---------------------------------------------------- Date: 17 May 90 14:54:50 GMT From: swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!turnkey!jackv@ucsd.edu (Jack F. Vogel) To: tcp-ip@nic.ddn.mil Subject: Re: "LARP" on Port 91 ?
In article <3315@apogee.oakhill.UUCP> guri@oakhill.UUCP (Gurvinder Singh Ahluwalia) writes: > >Has anyone heard of a protocol called LARP? Well, yes you might say I've heard of it, considering we invented it :-}. Locus has two officially registered IP protocol's, LARP is, as you noted number 91, another is number 87 which is an IP packet containing what is called a net message which is an inter-kernel communication packet. The former is used to initialize TCF it resolves an address to a TCF site number. The later lays the foundation for TCF. Since the registration of these protocols was relatively recent some sniffers will see the packets but not give you a protocol name. >For those out there aware of this and also running cisco routers, >I would like to go a step further to find out compatibility of this >protocol on ciscos, including access/passage of LARP traffic through >cisc.o Is there something that has to be enabled to allow LARP through >cisco? What is the default? We use Proteon routers here at LCC but I know that Cisco is in use at a couple of locations running AIX370. I don't believe there is anything that you need to do to the router, it should pass the packets through by default, it is just an IP packet. Disclaimer: I speak for myself, not my employer. -- Jack F. Vogel jackv@locus.com AIX370 Technical Support - or - Locus Computing Corp. jackv@turnkey.TCC.COM
-----------[000185][next][prev][last][first]---------------------------------------------------- Date: 17 May 90 17:55:33 GMT From: mcsun!unido!zgdvda!zhang@uunet.uu.net (Ning Zhang) To: tcp-ip@nic.ddn.mil Subject: help wanted for installing MIT/CMU PC/IP public domain package on NI5210
Sorry for crossposting. Please reply me by email (unido!zgdvda!zhang or zhang@agd.fhg.de), since I have no access to these newsgroups. We just received a public domain PC/IP package, which was originally developed at the Lab of CS at MIT and later enhanced by CMU. I compiled this TCP/IP package on a Compaq At with MSC 5.0 without any problem. Since the default configuration did not support Interlan NI5210A ethernet card, I relinked the whole exe commands with the NI5210A driver library (instead of the old NI5010 driver library), which was developed by at B. N. Davis at Darbick Instructional Software Systems in 1988, also without any problem. Then I had to customize the netdev.sys file to set up correct parameters about the hardware, internet address, etc., and also turned all debug options on. The RACAL Interlan ethernet card we have is NI5210A-8-V (REV AA). The IO address was configured as 0x360, the base memory address was 0xC0000 and the interrupt vector was at IRQ2 level. I would think I had correctly set up all parameters. Then I changed my config.sys file for installing netdev.sys and rebooted the pc. After the machine came up again, I simply tried the iping command, but it didn't work. It complained that "Error: board not responding". This message came from the i_init.c file in the NI5210 driver directory. I also tried hopelessly by changing the DMA channel numbers. I thought I might have done something wrong during the compiling or configuration. Here I ask you PC/IP gurus to enlight me about the problem. Enclosed here is the first few lines of the "i82586.h" about the version I have. /* See permission and disclaimer notice in file "bnd-note.h" */ #include "bnd-note.h" /* Copyright 1986 by Carnegie Mellon */ /* See permission and disclaimer notice in file "cmu-note.h" */ #include <cmu-note.h> /* Copyright 1984 by the Massachusetts Institute of Technology */ /* See permission and disclaimer notice in file "notice.h" */ #include <notice.h> /* This header file includes register descriptions of the Ethernet boards for the IBM PC based on the Intel 82586 chip (hence known as "the ethernet"). */ As we are in a poor institute and cannot afford to buy a expensive package for network monitoring, we only need two program included in this PD PC/IP package, i.e. netwatch, monitor. If you know PD stuff else for this purpose, please also let me know. Thanks in advance, Ning Zhang unido!zgdvda!zhang zhang@agd.fhg.de
-----------[000186][next][prev][last][first]---------------------------------------------------- Date: 17 May 90 19:31:08 GMT From: CCBUSTER@VM.CC.OLEMISS.EDU (POSTMASTER) To: comp.protocols.tcp-ip Subject: AEDAVIS
Please remove AEDAVIS@VM.CC.OLEMISS.EDU or AEDAVIS@UMSVM from this list. He is no longer here.
-----------[000187][next][prev][last][first]---------------------------------------------------- Date: 17 May 90 20:35:14 GMT From: shlump.nac.dec.com!delni.dec.com!mcclellan@decuac.dec.com (Rolf McClellan) To: tcp-ip@nic.ddn.mil Subject: Announcing biz.dec.ip--a newsgroup on DEC's TCP/IP products
This posting is to announce a USENET newsgroup for the discussion of products from Digital Equipment Corporation that support the Internet protocol suite (TCP/IP). The newsgroup will be unmoderated, but will be read regularly by employees of Digital, including some of the engineers who develop TCP/IP networking products, as well as marketing and field support personnel. The goal of the newsgroup is to provide a forum for the exchange of information from user-user, as well as user-Digital, and Digital-user. Digital employees intend to contribute to the newsgroup by posting detailed product descriptions and specifications similar to Digital's Software Products Descriptions (SPDs), and by trying to answer questions about the applicability and use of Digital's TCP/IP products. There is no intention of posting the sort of marketing literature that simply extols product virtues in general terms. The newsgroup is also not intended as an alternative to normal channels for product support. However, every attempt will be made to respond in some way to postings that are addressed to Digital. Because of the unavoidable commercial nature of product descriptions and application notes, it was felt that the newsgroup should be established as biz.dec.ip. In spite of this, it is hoped that the nature of the newsgroup will be very similar to user-sponsored newsgroups. Rolf McClellan mcclellan@delni.enet.dec.com
-----------[000188][next][prev][last][first]---------------------------------------------------- Date: 17 May 90 21:03:26 GMT From: amdcad!pepsi!ohara@ucbvax.Berkeley.EDU (Bob O'Hara) To: tcp-ip@nic.ddn.mil Subject: Re: Max FDDI frame rate on the glass
In article <2651C1E1.23165@orion.oac.uci.edu> DHWalker@uci.edu (David Walker) writes: [stuff from Kent's earlier post deleted.] > >Actually, I think it may really be more like 3 million, depending on the >size of the ring. Since FDDI allows a device to release the token after >finishing its transmission (rather than after it receives the message it >sent), it's possible to have multiple packets on the ring, particularly if >they're small packets. Does anyone feel like calculating how many packets >can be carried per second by FDDI as a function of the number of nodes and >length of fiber? I don't know enough about the delay introduced by each >node to do it. > > David Walker > Network Services Manager > UC Irvine > DHWalker@uci.edu David, Kent was pretty close. You have probably seen my response to him just prior to this posting. You are correct that there may be many frames on the ring simultaneously, but any one node will only see the one passing immediately in front of it. Therfore, a node needs to support only 100 Mbps into and out of the ring. Only if a node has multiple connections to the ring (i.e. a dual MAC, dual attachment station) would it need anything beyond 100 Mbps. The FDDI standard does specify a maximum latency for each node and a delay figure for the fiber, so it is possible to calculate (approximately, since bits in the preamble can be eaten and created as a frame goes round the ring) how many bits and from that how many frames are on a ring. I think the equation would look like this: n = number of stations, l = length of fiber in meters. # of data bits on the ring = ((n * 756ns) + (l * 5ns/m)) / 10ns per bit These numbers are taken from ANSI X3.148-1988, the Physical protocol sublayer standard. Divide the number of bits by your favorite average frame length and you will have your answer. -Bob Bob O'Hara Net: ohara@pepsi.amd.com Advanced Micro Devices, Inc. Phone: +408-749-2321 P.O. Box 3453 MS 70 Fax: +408-749-2825 Sunnyvale, Ca. 94088-3000 Disclaimer: Everyone needs a disclaimer and I disclaim this one.
-----------[000189][next][prev][last][first]---------------------------------------------------- Date: 18 May 90 03:10:50 GMT From: hercules!dirt.cisco.com!kph@apple.com (Kevin Paul Herbert) To: tcp-ip@nic.ddn.mil Subject: Re: CLNS and routing (IS-IS) and ES-IS
At cisco, we just released support for CLNS routing based on a proprietary protocol, ISO IGRP. We support ES-IS, so we'll autoconfigure and do dynamic routing based on addresses learned from end systems, although our routing won't interroperate in the same CLNS area with routers using IS-IS (although, to our knowledge, there are no IS-IS routers today). If you want to learn more about the features and capabilities of ISO IGRP, we can move this discussion to comp.dcom.sys.cisco. Kevin
-----------[000190][next][prev][last][first]---------------------------------------------------- Date: 18 May 90 04:49:32 GMT From: news-server.csri.toronto.edu!torsqnt!hybrid!robohack!woods@rutgers.edu (Greg A. Woods) To: tcp-ip@nic.ddn.mil Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <29973@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes:
> {Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW}
> {unix-pc.general,comp.sys.att,comp.dcom.lans,comp.protocols.tcp-ip}
>
> If you have the WIN/3B card and the Wollongong Software on your 3B1, are YOU
> happy with the performance?
>
> The only conclusion I can draw is that the Wollongong WIN/3B Applications
> Package, version 1.4, for the UNIXPC/3B1 is seriously flawed. Some of the
> support programs (e.g. telnet, sendmail, etc.) are buggy beyond belief, but
> this level of "performance" is so poor I wonder if there's something I might
> be missing.
Please don't infer too much from my posting, BUT.... Everything I've
ever heard about Wollongong WIN/TCP products leaves a lot to be
desired. Certainly they are over-priced ($7,500 for binaries, $35,000
for sources for a 3b2 at announcement). A colleague who has seen the
sources of early versions says they are a very sorry sight.
I'm not entirely surprised to hear that the WIN/3B1 version suffers
from poor performance, especially given that it was never marketed to
any degree. I'm not too surprised to hear of any nasty bugs either,
and I would consider the several second pauses between activity to be
a bug too!. You might consider porting much of the BSD4.3 code....
--
Greg A. Woods
woods@{robohack,gate,eci386,tmsoft,ontmoh}.UUCP
+1 416 443-1734 [h] +1 416 595-5425 [w] VE3-TCP Toronto, Ontario; CANADA
-----------[000191][next][prev][last][first]---------------------------------------------------- Date: 18 May 90 07:58:00 GMT From: rogue.llnl.gov!oberman@lll-winken.llnl.gov (Oberman, Kevin) To: tcp-ip@nic.ddn.mil Subject: Re: CLNS and routing (IS-IS) and ES-IS
In article <12590478782.15.AFDDN.BEACH@GUNTER-ADAM.AF.MIL>, AFDDN.BEACH@GUNTER-ADAM.AF.MIL writes... >Can anybody tell me where to get any info at all on proposed routing >protocols and implementations of them for the GOSIP world. I assume >OSPF will be used. What I'd really like is pointers to discussions >of how the routing would operate and clues on what implementations >might look like. I'd also like any comments on resource utilization. >I think the ISO address formats look a lot harder to deal with than IP. > >Please send responses directly to me so as not to clutter up this list... >AND if there's another list I should be talking to, feel free to flame >as long as you tell me the list's address. > >Going from TCP/IP is like teaching a sho'nuff southern boy to talk with >a french accent. It ain't easy! The IS-IS standard is currently in DP (Draft Proposal) status. It is DP 10589. I'm posting to the list because I suspect lots of people are not familiar with the status of this (unless they read the OSI group). The full title of the beast is "Intermediate system to Intermediate system Intra-Domaon routeing exchange protocol for use in Conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)". The spelling and caps ARE exact to the best of my proof reading. The proposal is similar to OSPF in concept, but very different in detail. It is far from certain that IETF will recommend OSPF as the Internet standard, but it looks to be the front-runner. 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.
-----------[000192][next][prev][last][first]---------------------------------------------------- Date: Fri 18 May 90 16:40:04-PDT From: VANCE@TGV.COM (L. Stuart Vance) To: tcp-ip@nic.ddn.mil Subject: Interesting uses of networking
I'm putting together a talk on interesting uses of networking, and am looking for good stories/applications that people have run across. I'm very familiar with two: o TCP (Mr. Romkey's Toaster Control Protocol) o An SNMP controlled CD player If anyone has any information on other uses (in particular, I'd like to find people with information on the coke machine wired up to a DEC-20[?] at MIT[?] and/or the geographic coordinates server at [I believe] MERIT), I'd be most interested in talking you. Many thanks, ----Stuart -------
-----------[000193][next][prev][last][first]---------------------------------------------------- Date: 18 May 90 12:20:25 GMT From: pandora!scj@bellcore.com (Steve Johnson) To: tcp-ip@nic.ddn.mil Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <1990May18.044932.28911@robohack.UUCP> woods@robohack.UUCP (Greg A. Woods) writes:
>In article <29973@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes:
>> {Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW}
>> {unix-pc.general,comp.sys.att,comp.dcom.lans,comp.protocols.tcp-ip}
>>
>> If you have the WIN/3B card and the Wollongong Software on your 3B1, are YOU
>> happy with the performance?
...
>I'm not entirely surprised to hear that the WIN/3B1 version suffers
>from poor performance, especially given that it was never marketed to
>any degree. I'm not too surprised to hear of any nasty bugs either,
>and I would consider the several second pauses between activity to be
>a bug too!. You might consider porting much of the BSD4.3 code....
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Two points:
1. If anyone begins the port of BSD code, I suggest using Alex Crain's
UnixPC socket implementation *OR* spending the time to re-write the
BSD code using TLI as provided with the WIN/3B package. Having used
(both UnixPC and 3B2) WIN/3B, my personal opinion is that the concept
of socket emulation is 90% of the reason WIN/3B is a poor performer.
(most socket calls are actually TLI calls wrapped with a function that
is supposed to behave like a socket call). In the case of the UnixPC,
I hope to be proven wrong but it looks like TLI may done using *sockets*
at the kernel level! (If true, this means socket "calls" invoking TLI
"calls" invoking socket calls -- blecch!)
(Anyone with decent Motorola 68k assembler and device driver experience
want to take a look at a disassembled socket.o? :-) I'm having trouble
making sense of the assembler code).
2. Although well known in sun (workstation) circles, the fact that rwhod and
routed are BIG cpu hogs seems lost on Wollongong - NO mention of the
potentially anti-social behavior of these bad boys in the manual! The
Moral? Don't run these guys unless you need them, our UnixPC's are
already anaemic by today's standards.
BTW, NFS for the UnixPC (WIN/3B or ??) is in my queue (right after I finish
my gas project 8-( ).
-----------[000194][next][prev][last][first]---------------------------------------------------- Date: 18 May 90 12:52:21 GMT From: pmf@mimsy.umd.edu (Paul M. Franceus) To: tcp-ip@nic.ddn.mil Subject: Re: Max FDDI frame rate on the glass
In article <2651C1E1.23165@orion.oac.uci.edu> DHWalker@uci.edu (David Walker) writes:
>sent), it's possible to have multiple packets on the ring, particularly if
>they're small packets. Does anyone feel like calculating how many packets
>can be carried per second by FDDI as a function of the number of nodes and
>length of fiber? I don't know enough about the delay introduced by each
>
...
> David Walker
I don't believe that the maximum frame rate depends on the latency of the
ring. The FDDI still only transmits at 100Mb/sec (125 Mb/sec if you are
being technical.) The latency in the ring may decrease the maximum number
of usable frames per second, and there may be many frames in transit at
any time.
If you ignore IP and TCP overhead (don't forget the 802.2 and
SNAP headers) the FDDI can go much faster than 14,000 pps. The maximum
frame rate is really something around 480,000( given the 17 Byte min frame and
the preamble).
Paul Franceus
-----------[000195][next][prev][last][first]---------------------------------------------------- Date: 18 May 90 12:59:57 GMT From: pmf@mimsy.umd.edu (Paul M. Franceus) To: tcp-ip@nic.ddn.mil Subject: Re: A SUSPICIOUS SECURE GATEWAY
While Gateway filtering is not a cure-all, Host based security is
not a cure all either. In any security architecture it is important that
each piece of the system do its part. Any individual "secure" component
of a system will not give "total" security. Security will not be achieved
unless you have mapped out a security architecture where each part of the
system does its piece. It is important also, for functions to overlap
somewhat to provide a layered security approach.
Filtering gateways can be an important part of such a security architecture.
Paul Franceus
-----------[000196][next][prev][last][first]---------------------------------------------------- Date: Fri, 18 May 90 17:35:51 EDT From: Doug Nelson <08071TCP%MSU.BITNET@CORNELLC.cit.cornell.edu> To: Campus-Size LAN Discussion Group <BIG-LAN@SUVM>, Don Lewis <LEWIS@UMSLVMA> Cc: "TCP/IP list (plus more)" <tcp-ip@nic.ddn.mil> Subject: Re: Dial up access to Internet facilities
> We are in the process of evaluating terminal severvs that provide >TCP/IP support for dialup users. We are currently having a philosphical >discussion on what users should have acces to once dialed in. We, >University of Missouri - St. Louis, are part of a TCP/IP network that is >associatied with MIDnet. I have no problems allowing users access to >our local TCP/IP host plus the other hosts in the U. of Mo. network. >Should dialup users have access to the Internet? There is something >about allowing this type of access that doesn't sound right to me. >Should this be a concern? How are other institutions handling this >type of access? Yes, this should be a concern. As I understand it, NSFnet policy is that unlimited access is not permitted. You would have to check to see if MIDnet has its own policy. What this policy seems to translate to in practice is that you should only permit "known" users to have access outside of your local net (and perhaps your regional net, if it is within their guidelines). This generally means that terminal servers should be restricted to local use, requiring dial-up users to access a workstation or larger system and identify themselves (as something other than "guest", hopefully!) in order to have unlimited Internet access. Here at MSU, we are part of two regional networks - Merit and CICnet. Our dial-up lines have unlimited access to any hosts at MSU or within the Merit Network, but not CICnet or beyond. This is true of all the dial-up lines within the Merit Network and its member institutions as well. Doug Nelson Network Software Manager Michigan State University
-----------[000197][next][prev][last][first]---------------------------------------------------- Date: 18 May 90 14:48:20 GMT From: haven!umbc3!umbc5.umbc.edu!alex@ames.arc.nasa.gov (Alex S. Crain) To: tcp-ip@nic.ddn.mil Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <1990May18.044932.28911@robohack.UUCP> woods@robohack.UUCP (Greg A. Woods) writes: >I'm not entirely surprised to hear that the WIN/3B1 version suffers >from poor performance, especially given that it was never marketed to >any degree. I'm not too surprised to hear of any nasty bugs either, >and I would consider the several second pauses between activity to be >a bug too!. You might consider porting much of the BSD4.3 code.... >-- > Greg A. Woods Just a passing note, the uipc driver thats going around is directly derived from BSD, all you need to do is add the driver for the ethernet card and the af_inet code, available from uunet. I haven't looked at the code in awhile, but I did finish most of the top level, and a few things were added later. I had always planned to add a slip interface, but it never got finished because of hardware problems on my end (I may find some time for it this summer, in between rebuilding my Harley, rehabbing my house, getting married, etc ... ). t################################# :alex. #Disclamer: Anyone who agrees # Systems Programmer #with me deserves what they get.# University of Maryland Baltimore County ################################# alex@umbc3.umbc.edu
-----------[000198][next][prev][last][first]---------------------------------------------------- Date: 18 May 90 15:33:21 GMT From: swrinde!emory!km@ucsd.edu (Ken Mandelberg) To: tcp-ip@nic.ddn.mil Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <23377@bellcore.bellcore.com> scj@pandora.UUCP (Steve Johnson) writes:
>In article <1990May18.044932.28911@robohack.UUCP> woods@robohack.UUCP (Greg A. Woods) writes:
>>In article <29973@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes:
>
>2. Although well known in sun (workstation) circles, the fact that rwhod and
> routed are BIG cpu hogs seems lost on Wollongong - NO mention of the
> potentially anti-social behavior of these bad boys in the manual! The
> Moral? Don't run these guys unless you need them, our UnixPC's are
> already anaemic by today's standards.
>
The problem with rwhod on Suns is not really that it is a CPU hog, but
relates to diskless workstations. On a Sun network with well
synchronized clocks all the diskless workstations send out a broadcast
packet at almost the same moment once a minute, with their own load
info. Each one receives all its fellows packets and tries to write the
updated info to the /usr/spool/rwho directory, each to a separte file.
These files are all NFS so each takes several additional packets for
the write. The broadcasts don't really hurt much, its the NFS writes.
If you have N machines there are N^2 NFS writes per minute, all at
about the same moment. This causes many collisions and retries.
On our diskless Suns we patched rwho to do the broadcasts but not
update its own /usr/spool/rwho. Only the server updates this directory,
and it is mounted on all the clients. This cuts out the NFS packets
entirely, there are just N broadcast packets a minute.
For the 3B1, there is nothing to do since /usr/spool/rwho is already
local.
With this in place, with in execess of 50 rwhod machines on our net,
rwhod consumes on the order of 10 seconds an hour. If all you have is
diskfull machines (like 3B1s) that would be what you should expect with
no patches. In fact I got the 10 second estimate from "ps" on one of
our 3B1s. Even if you have unpatched diskless Suns and 3B1s, the 3B1s
would not see high cpu usage on rwhod, just the Suns. However, everyone
would suffer the network congestion for the NFS writes.
If N gets very large (say 1000), and the clocks are very well
synchronized (say with timed), the broadcasts and collisions alone
would kill you (even with the patch). The very large /usr/spool/rwho
directory on the server would also degrade performance on the
server and thrash the inode cache. Rwhod clearly doesn't scale well,
but is really not much of a problem (with the patch) on relatively
small nets.
--
Ken Mandelberg | km@mathcs.emory.edu PREFERRED
Emory University | {rutgers,gatech}!emory!km UUCP
Dept of Math and CS | km@emory.bitnet NON-DOMAIN BITNET
Atlanta, GA 30322 | Phone: (404) 727-7963
-----------[000199][next][prev][last][first]---------------------------------------------------- Date: 18 May 90 17:45:13 GMT From: swrinde!zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!dan@ucsd.edu (Dan Schlitt) To: tcp-ip@nic.ddn.mil Subject: Re: What is the IAB?
In article <57064@bu.edu.bu.edu> kwe@bu-it.bu.edu (Kent England) writes: :In article <1990May10.150744.12108@phri.nyu.edu>, :roy@alanine.phri.nyu.edu (Roy Smith) writes: :> :> At the recent PSI Internetworking Tutorial, I asked two people who :> should have known the answer, "Exactly what *is* the Internet Activities :> Board?" and in both cases all I got were some random moderately derogatory :> comments but no real answer (which I found somewhat annoying, BTW). :> :> So, can anybody on this list answer my question? :> -- : : Some wires must have gotten crossed. It would be very strange indeed :for anyone in PSI to take this view, since several of the principals at PSI :have been involved in TCP/IP standards, including SNMP and "ISO-on-TCP", and :that work would be exactly nowhere without the IAB. Strange, indeed. : I have my doubts about Roy's interpretation too. However one should also note the anonymous critique of the governance of the Internet that was published in Goodfellow's newsletter. Participation in the IAB and the IETF can't be read as 100% support. -- Dan Schlitt Manager, Science Division Computer Facility dan@sci.ccny.cuny.edu City College of New York dan@ccnysci.uucp New York, NY 10031 dan@ccnysci.bitnet (212)690-6868
-----------[000200][next][prev][last][first]---------------------------------------------------- Date: 18 May 90 19:23:13 GMT From: zaphod.mps.ohio-state.edu!uwm.edu!bbn.com!mmcintos@tut.cis.ohio-state.edu (Martin M. McIntosh) To: tcp-ip@nic.ddn.mil Subject: Re: Max FDDI frame rate on the glass
The maximum throughput of a FDDI ring *does* depend on the propagation delay, as many people have pointed out. More accurate, the throughput depends on the delay between adjacent stations, since no traffic can enter the ring as the token is passed. The TTRT will also have some effect on the throughput, since this will determine the rate that the token must be passed. If you assume that each station will send for the entire TTRT, the next station cannot send until one-ring-rotation + time-to-next-station after the TTRT expires. If the stations can only send one frame (each monkey types slowly) per token, the time between frames will be time-to-next-station until the TTRT expires and then the time will be equal to the above.If you want a lower bound on PPS, pick a ring with - TRT set to expire just before the last bit of the frame is transmited - maximim ring size - only two stations (one terminal with monkey and one server not sending) This will get one frame per *two* rotations of the ring. The maximum throughput will be a small ring with large TTRT and lots and lots of stations all sending frames until the TTRT expires. I would recommend reading "Analysis and Tuning of the FDDI Media Access Protocol", D. Dykeman and W. Bux, IEEE Journal on Selected Areas in Communications, July 1988. This provides very good analytic solutions to throughput on FDDI. At least it was confirmed by some simulation work that I have done. [much of this information was included in a past posting by myself. I am sorry for any duplication] Martin McIntosh Bolt Beranek and Newman Network Analysis mmintosh@BBN.COM
-----------[000201][next][prev][last][first]---------------------------------------------------- Date: 18 May 90 19:55:43 GMT From: zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!david@tut.cis.ohio-state.edu (David H. Wolfskill) To: tcp-ip@nic.ddn.mil Subject: IBM MVS[/XA or /ESA] TCP/IP Implementations
I am seeking information about implementations of the TCP/IP protocol
suite for use in an MVS/XA (or MVS/ESA) environment on an IBM 3090.
(This is for my employer, who shall remain mercifully nameless. :-)
I have heard reports that there may be implementations other than the
IBM one that may be worth examining; I would appreciate knowing:
* Who the vendors are
* What experiences folks have had with the products (and the vendors)
(Naturally, I am also interested in folk's experiences with the IBM
product, although I already am aware of its existence....)
I much prefer mail; I will certainly post a summary if more than a
couple of folks request it -- probably around the middle of June (unless
I get inundated by responses well before then). If you can't reach me
any other way, my (work) telephone number is (714) 385-4055.
Thank you,
david
--
David H. Wolfskill
uucp: ...{spsd,zardoz,felix}!dhw68k!david InterNet: david@dhw68k.cts.com
CompuServe: >internet:david@dhw68k.cts.com
-----------[000202][next][prev][last][first]---------------------------------------------------- Date: Fri, 18 May 90 20:06:09 GMT From: "Douglas P. Ambort" <douglas@TWG.COM> To: tcp-ip@nic.ddn.mil Cc: fernwood!portal!cup.portal.com!thad@uunet.uu.net Subject: Re. Wollongong TCP/IP
Ouch! Mr. Floryan's indictment of AT&T's implementation of a very old outdated version of Wollongong TCP/IP, ported a long time ago by AT&T to its 3B1's is harsh. Given the 3B1, his indictment may not be altogether off base; but it could be misconstrued by netnews readers as a general indictment of all Wollongong TCP/IP (past, present, future, and on good, bad or indifferent platforms). And such an indictment would not only be unfair, but misinformed. Wollongong continues to upgrade its TCP/IP with _significant_ enhancements. And AT&T continues to select Wollonong as its TCP/IP vendor of choice, for current and future platforms. Why? Because of our TCP/IP's performance and features, our commitment to continued enhancement, and because of the solid OEM support we provide. In this case of the (the 3B1 shortcomings described by Mr. Floryan), AT&T has simply chosen not to upgrade an ancient TCP/IP on a platform that has been retired. Perhaps AT&T is concentrating on new platforms? If you want to see the best TCP/IP in its class, check out the TCP/IP on UNIX System Release V 4.0 on AT&T's 6386 WGS series of machines. It's Wollongong's. And we're proud of it. On the other hand, if someone must rail against an old TCP/IP implementation on (let's face it) 'old iron', go ahead. You could just as easily criticise the skinny tires on a Model T for not being steel belted radials. Time passes. Technology progresses. And so has Wollongong's TCP/IP! .--------------------------------------------------------------------. | Douglas Ambort The Wollongong Group, Inc. | | Product Manager 1129 San Antonio Road | | INTERNET: douglas@twg.com Palo Alto, CA 94303 | | (415) 962-7248 | | FAX: (415) 969-5547 | `--------------------------------------------------------------------'
-----------[000203][next][prev][last][first]---------------------------------------------------- Date: 18 May 90 21:35:51 GMT From: 08071TCP@MSU.BITNET (Doug Nelson) To: comp.protocols.tcp-ip Subject: Re: Dial up access to Internet facilities
> We are in the process of evaluating terminal severvs that provide >TCP/IP support for dialup users. We are currently having a philosphical >discussion on what users should have acces to once dialed in. We, >University of Missouri - St. Louis, are part of a TCP/IP network that is >associatied with MIDnet. I have no problems allowing users access to >our local TCP/IP host plus the other hosts in the U. of Mo. network. >Should dialup users have access to the Internet? There is something >about allowing this type of access that doesn't sound right to me. >Should this be a concern? How are other institutions handling this >type of access? Yes, this should be a concern. As I understand it, NSFnet policy is that unlimited access is not permitted. You would have to check to see if MIDnet has its own policy. What this policy seems to translate to in practice is that you should only permit "known" users to have access outside of your local net (and perhaps your regional net, if it is within their guidelines). This generally means that terminal servers should be restricted to local use, requiring dial-up users to access a workstation or larger system and identify themselves (as something other than "guest", hopefully!) in order to have unlimited Internet access. Here at MSU, we are part of two regional networks - Merit and CICnet. Our dial-up lines have unlimited access to any hosts at MSU or within the Merit Network, but not CICnet or beyond. This is true of all the dial-up lines within the Merit Network and its member institutions as well. Doug Nelson Network Software Manager Michigan State University
-----------[000204][next][prev][last][first]---------------------------------------------------- Date: 19 May 90 00:08:04 GMT From: usc!orion.oac.uci.edu!uci.edu!DHWalker@ucsd.edu (David Walker) To: tcp-ip@nic.ddn.mil Subject: Re: Max FDDI frame rate on the glass
In article <24484@mimsy.umd.edu> pmf@mimsy.umd.edu (Paul M. Franceus)
writes:
> I don't believe that the maximum frame rate depends on the latency
of the
> ring. The FDDI still only transmits at 100Mb/sec (125 Mb/sec if you are
> being technical.) The latency in the ring may decrease the maximum
number
> of usable frames per second, and there may be many frames in transit at
> any time.
> If you ignore IP and TCP overhead (don't forget the 802.2 and
> SNAP headers) the FDDI can go much faster than 14,000 pps. The maximum
> frame rate is really something around 480,000( given the 17 Byte min
frame and
> the preamble).
>
> Paul Franceus
Thanks, Paul. I can see that I misunderstood Kent's original question.
What I'm interested in is what *aggregate* packet rate can be carried by
FDDI for *multiple* sources (i.e., the monkeys are not all at one node),
so your 480K is what I was looking for. Of course, none of us would ever
expect to actually achieve that rate any more than we'd expect to achieve
14,000 pps on an Ethernet.
All of the other discussion of the maximum rate that's available to a
*single* node is sure interesting, though; I had no idea that FDDI was so
(mis)tunable.
David Walker
Network Services Manager
UC Irvine
DHWalker@uci.edu
-----------[000205][next][prev][last][first]---------------------------------------------------- Date: 19 May 90 05:39:20 GMT From: karn@ka9q.bellcore.com (Phil Karn) To: rec.ham-radio.packet,comp.protocols.tcp-ip Subject: Quote without comment
Advertisement in the October 7, 1989 issue of the British magazine
"New Scientist", page 15:
"The International Organization for Standardization (ISO) is seeking, for its
new project based on OSI LAN with distributed environment including servers
and VM and VMS hosts (PC or PS/2 user terminals), an experienced
NETWORK SYSTEMS SPECIALIST
familiar with the hardware/software aspects of LAN, network management and
operating systems, terminal emulation and host coupling, OSI protocols
INCLUDING TCP/IP [my emphasis - Phil], X.400 and X.25, to be responsible
for overall implementation of the network system. Please apply with cv to
ISO Personnel Services, Case postale 56, CH-1211 Geneva 20, Switzerland."
--Phil
-----------[000206][next][prev][last][first]---------------------------------------------------- Date: 19 May 90 15:10:24 GMT From: vmp!sonyd1!blilly!bruce@uunet.uu.net (Bruce Lilly) To: tcp-ip@nic.ddn.mil Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <23377@bellcore.bellcore.com> scj@pandora.UUCP (Steve Johnson) writes: [ several lines from other postings deleted ] >Two points: > >1. If anyone begins the port of BSD code, I suggest using Alex Crain's > UnixPC socket implementation *OR* spending the time to re-write the > BSD code using TLI as provided with the WIN/3B package. Having used > (both UnixPC and 3B2) WIN/3B, my personal opinion is that the concept > of socket emulation is 90% of the reason WIN/3B is a poor performer. > (most socket calls are actually TLI calls wrapped with a function that > is supposed to behave like a socket call). In the case of the UnixPC, > I hope to be proven wrong but it looks like TLI may done using *sockets* > at the kernel level! (If true, this means socket "calls" invoking TLI > "calls" invoking socket calls -- blecch!) > Forget it. The Wollongong ``emulation'' of TLI is extremely buggy -- it does not comply with any of the standards (SVID, POSIX, X/OPEN). It is so brain-damaged that I have found it impossible to write even a trivial program with it. The biggest problem is that asynchronous events are returned as a bit map, rather than one-at-a-time events in a queue. As a result, it is possible (even very likely) for a function to fail due to an asynchronous event, with no way to recover because of other ``events'' in the bit map. [ more lines deleted ] >2. Although well known in sun (workstation) circles, the fact that rwhod and > routed are BIG cpu hogs seems lost on Wollongong - NO mention of the > potentially anti-social behavior of these bad boys in the manual! The > Moral? Don't run these guys unless you need them, our UnixPC's are > already anaemic by today's standards. > Routed from Wollongong doesn't even work AT ALL. It dies after not finding a non-existent symbol in the kernel's nlist. >BTW, NFS for the UnixPC (WIN/3B or ??) is in my queue (right after I finish >my gas project 8-( ). -- Bruce Lilly uunet!vmp!sonyd1!blilly!bruce
-----------[000207][next][prev][last][first]---------------------------------------------------- Date: Saturday, 19 May 1990 23:54:28 EDT From: Gene.Hastings@boole.ece.cmu.edu To: emv@math.lsa.umich.edu (Edward Vielmetti) Cc: tcp-ip@nic.ddn.mil Subject: Re: archives of ietf "network joint management" list ?
I am the chair of tha Network Joint Management working group of the IETF. There is no formal archive of the mailing list <njm@merit.edu>, but there are public agendae and reports from meetings, and specific documents online in multiple places. Is there specific information you're seeking? Gene Hastings Pittsburgh Supercomputing Center
-----------[000208][next][prev][last][first]---------------------------------------------------- Date: 19 May 90 22:21:49 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!nuug!ifi!barsoom!tih@ucsd.edu (Tom Ivar Helbekkmo) To: tcp-ip@nic.ddn.mil Subject: Re: Re. Wollongong TCP/IP
douglas@TWG.COM ("Douglas P. Ambort") writes (among other things):
>Time passes. Technology progresses. And so has Wollongong's TCP/IP!
Yeah, you're right about that. We used to call it "Willgowrong" here,
but after receiving our last upgrade (to version 5.1 for VAX/VMS),
we've had to reevaluate. It's a darn good package, and well
documented. Congratulations!
-tih
--
Tom Ivar Helbekkmo, NHH, Bergen, Norway. Telephone: +47-5-959205
tih@barsoom.nhh.no, thelbekk@norunit.bitnet, edb_tom@debet.nhh.no
-----------[000209][next][prev][last][first]---------------------------------------------------- Date: 20 May 90 00:39:32 GMT From: zaphod.mps.ohio-state.edu!math.lsa.umich.edu!emv@tut.cis.ohio-state.edu (Edward Vielmetti) To: tcp-ip@nic.ddn.mil Subject: archives of ietf "network joint management" list ?
hi. I'm trying to find the site which archives the IETF "network joint management" mailing list. So far no luck. Can someone help? thanks. --Ed Edward Vielmetti, U of Michigan math dept. emv@math.lsa.umich.edu moderator, comp.archives
-----------[000210][next][prev][last][first]---------------------------------------------------- Date: Mon, 21 May 90 08:48:37 -0700 From: Stan Stead <stan@anes.ucla.edu> To: tcp-ip@sri-nic.arpa Subject: Dealing with systems without nameservice.
Greetings:
We are running 4.3 BSD. We currently use nameservice. However,
a site that we wish to exchange mail and files, while connected to the
internet, does not use nameservice. We can access the site by internet
number, but not by name. Is there anyway to "hot-wire" an address
(perhaps via /etc/hosts). Currently, the only way /etc/hosts is read
is if named is not running. Please reply to my email address directly.
Thank you.
Stan
Stanley W. Stead
UCLA School of Medicine / Dept of Anesthesiology
BELL: (213) 206-6238
ARPA: stan@anes.ucla.edu
BITNET: stan@anes.UCLA.EDU
UUCP: {randvax | ucla-cs}\
!ucla-an!stan
UUCP: {att|decvax}!hermix/
-----------[000211][next][prev][last][first]---------------------------------------------------- Date: 20 May 90 22:36:30 GMT From: ka9q.bellcore.com!karn@bellcore.com (Phil Karn) To: tcp-ip@nic.ddn.mil Subject: Re: A SUSPICIOUS SECURE GATEWAY
In article <1173@tnosoes.UUCP> tom@tnosoes.UUCP (Tom Vijlbrief) writes: >[...] but how can you be sure that a local network >with dozens of Unix boxes with different administrators are >correctly installing their machines ? (E.g. not export NFS-filesystems >to the world as is the default). >How can you be sure that hunderds of users have non trivial passwords, etc. One way is to build and use "sweep" programs that regularly test each machine on your local network for a list of specific security holes. For maximum effectiveness, you should not rely solely on your domain database or host tables for a list of machines to sweep; you should also look for unregistered "squatters" by monitoring ARP packets, probing your entire IP address space, etc. According to my conversations with the folks at CERT, all of the break-ins to computers on the Internet over the past year have exploited holes that have been well known for some time. I've found it fairly easy to construct programs that automatically test large numbers of machines for these known holes. The hard problem, as it turns out, lies not in generating a list of vulnerable systems, but in getting the administrators of those machines to update their software or to fix their system configurations. Gateway filtering is useful as a TEMPORARY protective measure while this process continues, but it does NOT lessen in any way the need to fix the vulnerable hosts. In my opinion, host security is both necessary and sufficient to prevent break-ins. Phil
-----------[000212][next][prev][last][first]---------------------------------------------------- Date: 21 May 90 01:22:55 GMT From: aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu (Charles Hedrick) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
>Yes, this should be a concern. As I understand it, NSFnet policy is >that unlimited access is not permitted. We have been unable to find any definite statement of policy in this area. However a number of system managers have gotten tired of responding to complaints about intrusions from their terminal servers, and have instituted restrictions. I have a feeling that over the course of the next year or so even without a definite policy, the number of unrestricted terminal servers is going to fall off to nearly zero. Another policy issue is preventing people from telnetting in and then out in an attempt to obscure their identity by going through many sites. I believe there is a growing concensus that this should be stopped in some way. If anyone knows of more definite policies in this area I'd like to hear about them.
-----------[000213][next][prev][last][first]---------------------------------------------------- Date: Mon, 21 May 90 08:33:03 EDT From: hal@gateway.mitre.org (Hal Feinstein) To: tcp-ip@nic.ddn.mil Subject: Wither Ethernet?
It has been suggested by some standards gurus that in the future
all LANs will be "standardized" to ISO/IEEE802 and that ethernet is a dead
(or possibly dying) protocol. That a couple of vendors (like Sun or CISCO)
supporting "dual stacks" (that is both protocols) are simply
startling a changing marketplace. There really will not be two different
standards. Now I've found strong avocates who disagree and say that
ethernet will be around and, others who say that current ethernet users
will stay with ethernet (because they already have it installed) but
*future* installations will use ISO/IEEE802. I have not seen any rush to
man ethernets lifeboats at the trade shows so I wonder if
what the standards gurus are saying is true? Have you faced this
questions also? If you have I'd appreciate hearing from you.
Hal
-----------[000214][next][prev][last][first]---------------------------------------------------- Date: Mon 21 May 90 14:43:11-PDT From: William Chops Westfield <BILLW@MATHOM.CISCO.COM> To: mmorse@note.nsf.gov Cc: tcp-ip@NSF.GOV Subject: Re: A SUSPICIOUS SECURE GATEWAY
cisco routers have supported very general packet access list mechanisms for some time. I believe that the ciscos can do everything the modified KA9Q can do, as well as other things (although in a rather more complex manner). Similar access list mechanisms are supported for otehr protocols. Bill Westfield cisco Systems. -------
-----------[000215][next][prev][last][first]---------------------------------------------------- Date: Mon, 21 May 90 13:49:48 EDT From: Michael Morse <mmorse@note.nsf.gov> To: tcp-ip@NSF.GOV Subject: Re: A SUSPICIOUS SECURE GATEWAY
Are any commercial router vendors considering implementing this kind of security? --Mike
-----------[000216][next][prev][last][first]---------------------------------------------------- Date: Mon, 21 May 90 21:35:36 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) To: tcp-ip@nic.ddn.mil Subject: ATT and TWG Products
My group is responsible for the installation and distribution of a number of different software products on a number of different platforms. I appreciate the alerts of problems with an application in a given software environment on a given hardware system. I don't appreciate, generalized, bashing of a specific product or vendor without stating the equivalent of name, rank, and serial number. It strikes me as being counter-productive to the goals that one wants to achieve--namely, a solution to a specific problem, If you have a plaint concerning a product, please be specific about the part, model, or other identification of the product, Also be clear about the en- vironment in which you are using the product. Now that I've aired my beef, please continue with reporting of problems. This allows me to approach the vendor to verify that the problem has been resolved or to suggest to my customers other products that do not exhibit the problems. Merton
-----------[000217][next][prev][last][first]---------------------------------------------------- Date: 21 May 90 11:00:30 GMT From: vsi1!teda!ditka!kls@apple.com (Karl Swartz) To: tcp-ip@nic.ddn.mil Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <29973@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >If you have the WIN/3B card and the Wollongong Software on your 3B1, are YOU >happy with the performance? Well, at present there's just ditka, without even a transceiver cable connected to the back. The other machine expected to be on my Bedroom Area Network (BAN) doesn't have a board yet. And I'm still unhappy with the network performance of with LOSE/3B (er, WIN/3B) package. Shortly after installing the stuff I noticed that my UUCP connections were taking dramatically longer. Looking at xferstats the reason became apparent -- while outgoing TrailBlazer traffic was going at full speed, incoming traffic had dropped from 1100 BPS down to around 200 - 300 BPS, with one large news batch turning in an astoundingly bad 84 BPS. Further investigation revealed that incoming characters were dropping like crazy. Hmmmm ... all the HFC control signals were still there and seemed to be doing the right things. Besides, with g-protocol and the stock 3 windows, it shouldn't matter. The only way to lose in this case would be the device driver simply not responding in time. Yet the characters dropped even when nothing else was happening on the machine, not even any activity shown by Metermaid. Thinking about recent changes, I disabled the WIN/3B stuff, and low and behold, uucp ran at full speed again. Still no observable change in the Metermaid. I turned WIN/3B back on, and bits started spewing all over the floor again. As a further experiment, I disabled all the TCP/IP daemons (fingerd, ftpd, rlogind, rshd, and telnetd) but left the driver and other stuff running. That returned uucp to normal. So, running one or more of these daemons somehow screws up incoming uucp ports. I haven't tried to figure which one or ones is at fault. For reference, ditka is a 3B1 with 3.5 MB and two disks using the ICUS upgrade, running the 3.51dG1 kernel, which is almost 3.51m. I normally run the TrailBlazer Plus (4.0 ROMs) on tty000 but also gave it a try on the combo board's tty002 with similar results. >With uucp over StarLAN (1BASE5) ... Too bad their uucp doesn't run over TCP connections as it will with Starlan. And it's not just a documentation issue -- I ran strings on uucico and there's nothing in there that would suggest TCP support. :-( (This is HoneyDanBer; I could care less about broken uucp.) -- Karl Swartz |UUCP uunet!apple!zygot!ditka!kls 1-408/223-1308 |INet zygot!ditka!kls@apple.com "I never let my schooling get in |BIX kswartz the way of my education."(Twain) |Snail 1738 Deer Creek Ct., San Jose CA 95148
-----------[000218][next][prev][last][first]---------------------------------------------------- Date: 21 May 90 11:12:31 GMT From: vsi1!teda!ditka!kls@apple.com (Karl Swartz) To: tcp-ip@nic.ddn.mil Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <3333@umbc3.UMBC.EDU> alex@umbc5.umbc.edu.UUCP (Alex S. Crain) writes: >Just a passing note, the uipc driver thats going around is >directly derived from BSD, all you need to do is add the driver for >the ethernet card and the af_inet code, available from uunet. Well, I've grabbed some of the higher level BSD code and started looking at the effort required to port it. Things like inetd, ping, and BIND for starters. And the BSD lpr package as I hate, despise, loath, and am otherwise disgusted by the System V lp rubbish. Alas, I've never done device drivers ... surely somebody must be able and willing to fill in this missing piece?! I'll happily do as much higher level stuff as I can. >I had always planned to add a slip interface ... SLIP was high on my list of wants. Ethernet has diminished my desire for it but I'd still like to have it. How 'bout it, folks? Seems we have several nice pieces here needing some attention. Here's your big chance to save the world! :-) >in between rebuilding my Harley, rehabbing my house, getting married, etc Minor problems, Alex. Get on with the important things! :-) -- Karl Swartz |UUCP uunet!apple!zygot!ditka!kls 1-408/223-1308 |INet zygot!ditka!kls@apple.com "I never let my schooling get in |BIX kswartz the way of my education."(Twain) |Snail 1738 Deer Creek Ct., San Jose CA 95148
-----------[000219][next][prev][last][first]---------------------------------------------------- Date: 21 May 90 12:55:41 GMT From: taber@pstjtt.enet.dec.com To: rec.ham-radio.packet,comp.protocols.tcp-ip Subject: Re: Quote without comment
In article <23433@bellcore.bellcore.com>, karn@ka9q.bellcore.com (Phil Karn) writes... > NETWORK SYSTEMS SPECIALIST > >familiar with the hardware/software aspects of LAN, network management and >operating systems, terminal emulation and host coupling, OSI protocols >INCLUDING TCP/IP [my emphasis - Phil], ... Yeah, so? OSI's TP4 is almost exactly TCP/IP -- that's no secret. >>>==>PStJTT Patrick St. Joseph Teahan Taber Mail address: Nahhhhh, you don't want to send me mail....
-----------[000220][next][prev][last][first]---------------------------------------------------- Date: 21 May 90 17:39:02 GMT From: auspex!guy@uunet.uu.net (Guy Harris) To: tcp-ip@nic.ddn.mil Subject: Re: Re. Wollongong TCP/IP
>If you want to see the best TCP/IP in its class, check out the TCP/IP >on UNIX System Release V 4.0 on AT&T's 6386 WGS series of machines. >It's Wollongong's. And we're proud of it. So AT&T threw out the Lachman-based one they supply standard with S5R4 and supply a Woolongong-based release instead?
-----------[000221][next][prev][last][first]---------------------------------------------------- Date: 21 May 90 20:30:56 GMT From: sdd.hp.com!elroy.jpl.nasa.gov!zardoz.cpd.com!fiuggi!fiuggi!dds@ucsd.edu (Dennis D. Sherod) To: tcp-ip@nic.ddn.mil Subject: RFI -- TCP/IP in Fortran
Please don't make me explain why I need this info ;-} I would like to know if anyone has ever done a TCP/IP implementation in Fortran (flavor not important). I need some of the utilities (ftp, telnet, r*, smtp) as well as the kernel pieces. Again, please don't ask. -- Dennis Sherod, Data General Corporation UUCP: ..!uunet!spsd!d_sherod 2603 Main St., Ste. 360, Irvine, CA 92714 ARPA: d_sherod@irvine.dg.com FAX: +1 714 250 6061 VOICE: +1 714 250 6005 x4233
-----------[000222][next][prev][last][first]---------------------------------------------------- Date: Tue, 22 May 90 08:30:50 -0700 From: Marshall Rose <mrose@cheetah.nyser.net> To: menges@menges.UUCP Cc: tcp-ip@nic.ddn.mil Subject: Re: SNMP Application Query
Check out RFC1147. In addition there are now unlicensed SNMP implementations: MIT, CMU, and ISODE. Please direct further questions to the SNMP list (send a note to snmp-request@nisc.nyser.net to subscribe). /mtr
-----------[000223][next][prev][last][first]---------------------------------------------------- Date: 21 May 90 23:48:34 GMT From: ekrell@ulysses.att.com (Eduardo Krell) To: comp.protocols.tcp-ip Subject: Re: Re. Wollongong TCP/IP
In article <3362@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>So AT&T threw out the Lachman-based one they supply standard with S5R4
>and supply a Woolongong-based release instead?
Not so, a quick scan at the header files shows that they all contain:
* System V STREAMS TCP was jointly developed by Lachman Associates and
* Convergent Technologies.
Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ
UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
-----------[000224][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 00:01:52 GMT From: cs.umn.edu!wsmith@ub.d.umn.edu (Warren Smith [Randy]) To: tcp-ip@nic.ddn.mil Subject: Re: A SUSPICIOUS SECURE GATEWAY
In article <23444@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes: > .... >In my opinion, host security is both necessary and sufficient to prevent >break-ins. > >Phil I'll agree with necessary, but I'm not so sure about sufficient. Just because most break-ins so far have used known bugs doesn't mean they always will. The suspicious secure gateway seems to add an extra layer of security that can complement host security. Then of course, there is always the question of who the "known" bugs are known to. -Randy -- Randy Smith wsmith@umn-cs.cs.umn.edu ...!rutgers!umn-cs!wsmith
-----------[000225][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 00:16:42 GMT From: andante!cbnewsm!cbnewsd!cage@EDDIE.MIT.EDU (charles.gerlach) To: tcp-ip@nic.ddn.mil Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
Enough is enough. The 3B1 WIN release you are complaining about is over 4 years old. To the best of my knowledge, there has never been another release for the 3B1. (To say the 3B1 is "mature" is probably an understatement.) But in the meantime, there have been 2 major releases to the WIN/3B and WIN/386 product lines. To imply that what you got has any resemblance to the current releases is stretching it a bit. I agree with you when you talk about the problems with the 3B1 WIN release. After 4 years, it would be unrealistic to expect it not to have any. I totally disagree when you extrapolate these problems to cover the entire WIN/3B product line to date. To take the 3B1 WIN release as a fair representation of the current products is wrong. I think your real problem is what do you do now? How do you solve your problems? Unfortunately I don't have a solution. Hopefully someone else does. It just that bashing AT&T or TWG is not productive and does not get you closer to a solution. It may make you feel better but ... Well thanks for listening. Chuck Gerlach AT&T Bell Labs cag@iwlcs.att.com ...!att!iwlcs!cag
-----------[000226][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 01:29:55 GMT From: mailrus!sharkey!cfctech!kevin@tut.cis.ohio-state.edu (Kevin Darcy) To: tcp-ip@nic.ddn.mil Subject: Re: Re. Wollongong TCP/IP
In article <9005182006.AA00073@dragon.twg.com> douglas@TWG.COM ("Douglas P. Ambort") writes:
>Ouch! Mr. Floryan's indictment of AT&T's implementation of a very old
>outdated version of Wollongong TCP/IP, ported a long time ago by AT&T
>to its 3B1's is harsh. Given the 3B1, his indictment may not be
>altogether off base; but it could be misconstrued by netnews readers as
>a general indictment of all Wollongong TCP/IP (past, present, future,
>and on good, bad or indifferent platforms). And such an indictment
>would not only be unfair, but misinformed.
He (Thad Floryan) criticizes the "latest" version of TCP/IP software
publically available (and, if I'm not mistaken, still sold, perhaps only by
Wollongong directly) for a still-existing base of 3B1's, based on his own
personal experiences and professional expertise. I don't know what *you* would
qualify as an "informed indictment"...?
>In this case of the (the 3B1 shortcomings described by Mr. Floryan),
>AT&T has simply chosen not to upgrade an ancient TCP/IP
>on a platform that has been retired. Perhaps AT&T is concentrating on
>new platforms?
How convenient for Wollongong to blame AT&T for not updating the product,
while AT&T can cite the unfeasibility of doing so, given the state of the
original version (perhaps even give that as one of the marketing reasons that
the UNIX PC line was discontinued). At some point, I would think that one or
the other party would admit their mistake - either Wollongong for providing a
flawed product, or AT&T for distributing it without adequate updates.
>If you want to see the best TCP/IP in its class, check out the TCP/IP
>on UNIX System Release V 4.0 on AT&T's 6386 WGS series of machines.
>It's Wollongong's. And we're proud of it.
Sorry, I don't have a 6386, I have a 3B1, along with a lot of other "cult
diehards" who haven't joined the 80x86 tribe. I just bought a 3B1 ethernet
card, and was looking forward to running TCP/IP on it to see what makes it
tick. Now I hesitate. Would I be learning the *wrong* things from this setup?
Is this really the ancestor of Wollongong's later products?
>On the other hand, if someone must rail against an old TCP/IP
>implementation on (let's face it) 'old iron', go ahead.
And what happens when 3B2's or WGS's become 'old iron'? Cast them off in the
same manner?
I don't accuse Wollongong of being opportunistic and of only hyping their
latest, sexiest implementations of TCP/IP on AT&T products, but if Mr. Ambort's
attitude is representative of Wollongong's as a whole, it seems to be bordering
very close to that...
>You could just as easily criticise the skinny tires on a Model T
>for not being steel belted radials.
But, then again, software and tires differ in significant ways: one seemingly
small deficiency or bug can render software useless for a given environment.
It's not a question of *performance*, but (as I understand Mr. Floryan's
comments), one of *functionality*. Those old tires *did work*, in other words.
(Since this is at this point mainly a vendor-support and 3B1 performance issue,
respondents please do not follow up to comp.protocols.tcp-ip. Thank you.)
DISCLAIMERS: I speak only for myself (*not* at all for Chrysler); a concerned
3B1 owner who has not yet used the product, but heard of its shortcomings
secondhand.
------------------------------------------------------------------------------
kevin@cfctech.cfc.com | Kevin Darcy, Unix Systems Administrator
...[mailrus!]sharkey!cfctech!kevin | Technical Services (CFC)
Voice: (313) 948-4863 | Chrysler Corporation
Fax: (313) 948-4975 | 27777 Franklin, Southfield, MI 48034
------------------------------------------------------------------------------
-----------[000227][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 01:35:24 GMT From: ekrell@ulysses.att.com (Eduardo Krell[dgb]) To: comp.protocols.tcp-ip Subject: Re: Re. Wollongong TCP/IP
In article <12981@ulysses.att.com> I wrote:
>Not so, a quick scan at the header files shows that they all contain:
>
> * System V STREAMS TCP was jointly developed by Lachman Associates and
> * Convergent Technologies.
This is what I saw in the SVR4 source distribution. The binaries shipped
with the AT&T machines are from Wollongong, though. Go figure ...
--
Eduardo Krell AT&T Bell Laboratories, Murray Hill
{att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
-----------[000228][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 03:08:44 GMT From: cs.utexas.edu!uwm.edu!rpi!image.soe.clarkson.edu!news@tut.cis.ohio-state.edu (Russ Nelson) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
In article <May.20.21.22.54.1990.4008@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: I have a feeling that over the course of the next year or so even without a definite policy, the number of unrestricted terminal servers is going to fall off to nearly zero. That's too bad, because when I've gone travelling in the past, I've called the local university, asked for their terminal server's phone number, and telnetted back to Clarkson to check my mail. It's a shame that that kind of service has to go away... -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667 Violence never solves problems, it just changes them into more subtle problems
-----------[000229][next][prev][last][first]---------------------------------------------------- Date: Tue, 22 May 90 08:31:09 EST From: bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu> To: tcp-ip@nic.ddn.mil Subject: TCPIP for the 3B1
I find all this talk about WINTCP and BSD and 3B1s very interesting, but
it leaves one very big question (at least to me.) Where does one look to
find an ethernet card for a 3B1?? I have a pair of them that I would love
to put on my ethernet and then start writing some decent software for them.
I would have to write it myself, cause I sure couldn't afford to buy it
from Wolongong!!!
Any ideas about where I can find real cheap ethernet cards for a couple of
3B1s???
bill
bill gunshannon
702WFG@SCRVMSYS.BITNET
-----------[000230][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 04:26:51 GMT From: mojo!smaug@mimsy.umd.edu (Kurt Lidl) To: tcp-ip@nic.ddn.mil Subject: Re: Dealing with systems without nameservice.
In article <9005211548.AA13756@ucla-an.anes.ucla.edu> stan@ANES.UCLA.EDU (Stan Stead) writes: > We are running 4.3 BSD. We currently use nameservice. >Is there anyway to "hot-wire" an address >(perhaps via /etc/hosts). Currently, the only way /etc/hosts is read >is if named is not running. Please reply to my email address directly. I was thinking about hacking in some changes to our version of libc gethost*() routines. We are currently running SunOS 4.0.3c on our Suns, but are looking at upgrading to 4.1... Sun has been good enough to tell us all how to make our own dynamically run libraries and I was thinking about putting in the U of Toronto's version of the resolver routines. One of the things that we have noticed is that if the nameservers are down, with the current version of libc (from uunet), nothing works. We have a small /etc/hosts file on all our machines that is kept up to date... What it all boils down to is this: If I alter the gethost*() routines to try the nameservers first, and then, if they fail, check the /etc/hosts files, will anything go terribly wrong? I am wondering why the current routines don't fall back on the hosts in /etc/hosts? Thanks. E-Mail is preferred, but I also read this newsgroup. -Kurt -- /* Kurt J. Lidl (smaug@eng.umd.edu) | Unix is the answer, but only if you */ /* UUCP: uunet!eng.umd.edu!smaug | phrase the question very carefully. */
-----------[000231][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 04:53:58 GMT From: sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU (Rob Warnock) To: tcp-ip@nic.ddn.mil Subject: Re: Max FDDI frame rate on the glass
Anyone not yet saturated by the FDDI (mis)tuning discussion should also check out traffic posted recently on "comp.dcom.lan" on the same subject. (Some of the stuff may duplicate what has been said here recently, but not all.) -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
-----------[000232][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 07:05:17 GMT From: wichert@quando.UUCP (Peter Wichert) To: comp.protocols.tcp-ip Subject: tcp problem auf MX500
Hallo,
Ich habe das Problem, eine tcp-ip Verbindung mit Siemens MX500 Rechnern
aufzubauen.
In unserem Netz gibt es diverse Rechner verschiedener
Hersteller (HP, Nixdorf, Sun), und zwischen allen laeuft das
Programm (Client/Server).
Auf der MX500 liefert aus mir unerklaerlichen Gruenden das 'connect'
die Fehlermeldung "connection refused", was natuerlich nicht viel aussagt.
ftp, rlogin usw. funktioniert, lokale Verbindungen innerhalb
der MX500 klappen auch, nur zu anderen Rechnern per eigenen Sockets
geht's nicht.
Hat jemand eine Idee ????
--
Peter Wichert UUCP: {backbone}!unido!quando!wichert OR wichert@quando.uucp
Quantum GmbH Bitnet: UNIDO!quando!wichert OR wichert%quando@UNIDO(.bitnet)
Dortmund internet: wichert%quando%unido.UUCP@mcsun.cwi.nl
Germany internet: wichert@quando.quantum.de
-----------[000233][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 08:14:45 GMT From: mcsun!ukc!acorn!tenset!paul@uunet.uu.net (Paul Andrews) To: tcp-ip@nic.ddn.mil Subject: Packet drivers & Novell (confused...)
I'm getting confused about whats needed to run IPX over a packet driver on a Novell diskless workstation (as you can probably guess, I haven't tried it yet but I will have to in the future). A document that comes with 6.x of the packet drivers says you need to run romrel because simply delaying the card initialisation by the packet driver doesn't work. A recent posting of a mod to the 5.x head & tail.asm suggested that a delay was sufficient. I know that there may be many variables here, but can people with experience of this let me know which approach worked for them? I guess for a true comparison you would really have had to use John's mods in case he does something different for the initialisation delay, but anyway... I was in the process of making a similar mod to the 6.x head and tail.asm that John had made to 5.x, I wouldn't have got it working without Johns posting though. I have an addition that you can turn of the 802.3<->DIX translation with an optional command line switch if you want to run in 'pure' mode. If anyone is interested in having the mod, mail me and I'll arrange it. All the mods are ifdef'd so you can assemble the original code using an assembler switch. - Paul -- ------------------------------------------------------------------ | Paul Andrews | Post: Tenset Technologies Limited, | | paul@tenset.uucp | Norfolk House, | | Phone: +44 223 328886 | 301 Histon Road, | | Fax: +44 223 460929 | Cambridge CB4 3NF, UK. | ------------------------------------------------------------------
-----------[000234][next][prev][last][first]---------------------------------------------------- Date: Tue May 22 08:44:40 1990 From: cctal!andrew@relay.EU.net To: tcp-ip@nic.ddn.mil Cc: cctal!andrew@relay.EU.net Subject: Background Ethernet under MS-DOS?
Does any one know of a way or a product to give background file transfer over Ethernet with an Ethernet card in a PC running MS-DOS? I am looking for the Ethernet equivalent of the program "Backmail" which gives this sort of function over modem dialup. background while foregound word processor (Wordperfect) continues. Thanks Replies+Interest--->Summary to net Andrew Hardie
-----------[000235][next][prev][last][first]---------------------------------------------------- Date: Tue, 22 May 90 13:46:51 EDT From: Doug Nelson <08071TCP%MSU.BITNET@CORNELLC.cit.cornell.edu> To: Stan Stead <stan@anes.ucla.edu>, "TCP/IP list (plus more)" <tcp-ip@nic.ddn.mil>, "Kurt J. Lidl" <smaug@eng.umd.edu> Subject: Re: Dealing with systems without nameservice.
From Stan Stead: > We are running 4.3 BSD. We currently use nameservice. However, >a site that we wish to exchange mail and files, while connected to the >internet, does not use nameservice. We can access the site by internet >number, but not by name. Is there anyway to "hot-wire" an address >(perhaps via /etc/hosts). Currently, the only way /etc/hosts is read >is if named is not running. The real answer is for them to set up name service. I can't think of any good reason for sites attached to the internet to not be running name service, or to find a site that can run name service for them. And from Kurt Lidl: >One of the things that we have noticed is that if the nameservers >are down, with the current version of libc (from uunet), nothing >works. We have a small /etc/hosts file on all our machines that is >kept up to date... If the name servers go down too frequently, you may want to set up more name servers, at least in caching mode. >What it all boils down to is this: If I alter the gethost*() >routines to try the nameservers first, and then, if they fail, check >the /etc/hosts files, will anything go terribly wrong? I am >wondering why the current routines don't fall back on the hosts in >/etc/hosts? This topic has been discussed. The answer is that for most applications (Telnet, FTP, etc.) the worst that will happen is that you will use the wrong address for a host due to old information. For mail, it can be worse - an SMTP mailer will likely bounce some mail because the host isn't listed in the hosts file. Or it may mis-deliver it due to the use of old information, or the failure to take MX records into account. Doug Nelson Michigan State University
-----------[000236][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 11:50:43 GMT From: usc!samsung!emory!hubcap!ncrcae!secola!syackey@ucsd.edu (Steve Yackey) To: tcp-ip@nic.ddn.mil Subject: Re: Re. Wollongong TCP/IP
In article <3362@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>If you want to see the best TCP/IP in its class, check out the TCP/IP >>on UNIX System Release V 4.0 on AT&T's 6386 WGS series of machines. >>It's Wollongong's. And we're proud of it. > >So AT&T threw out the Lachman-based one they supply standard with S5R4 >and supply a Woolongong-based release instead? no, when you buy 5.4 you get lachman tcp. when you buy a 6386, you get wollongong. for the 6386 at&t "upgraded" the tcp.
-----------[000237][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 12:08:35 GMT From: psuvm!pmw1@psuvax1.cs.psu.edu (Peter Weiss) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
In article <NELSON.90May21230840@image.clarkson.edu>, nelson@sun.soe.clarkson.edu (Russ Nelson) says: >That's too bad, because when I've gone travelling in the past, I've called >the local university, asked for their terminal server's phone number, and >telnetted back to Clarkson to check my mail. It's a shame that that kind >of service has to go away... Actually, you can still check your mail, but for the price of a toll call back to your own terminal server. Maybe this is the price we have to pay for added security? /Pete -- Peter M. Weiss | (this line intentionally left blank) 31 Shields Bldg (the AIS people) | 2 4 6 8 We don't want to calculate! University Park, PA USA 16802 | Disclaimer -* +* applies herein
-----------[000238][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 12:39:34 GMT From: zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!news-server.csri.toronto.edu!torsqnt!hybrid!robohack!woods@tut.cis.ohio-state.edu (Greg A. Woods) To: tcp-ip@nic.ddn.mil Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <1990May21.162713.1244@cbnewsd.att.com> cage@cbnewsd.att.com (charles.gerlach) writes:
> I agree with you when you talk about the problems with the 3B1 WIN
> release. After 4 years, it would be unrealistic to expect it not to
> have any. I totally disagree when you extrapolate these problems to
> cover the entire WIN/3B product line to date. To take the 3B1 WIN
> release as a fair representation of the current products is wrong.
I assume, from what I see on the References line, that you are
refering to the "flame" I wrote. I must appologize if it sounded like
I was flaming AT&T or the current WIN/3B product. I've never seen the
WIN/3B1 software, and I'm unlikely to ever get much direct experience
with it. The WIN/3B I was refering to was either for the 3B2 or some
non-AT&T machine. It was also at least two years old. However, I do
know that there are still sites hobbling along on with it. They don't
know any better solution, and they do flame AT&T and TWG.
It is unfortunate that AT&T chose the original WIN/3B. The original
WIN/3B has tainted my feelings, and I'm unlikely to ever try any
current version.
--
Greg A. Woods
woods@{robohack,gate,eci386,tmsoft,ontmoh}.UUCP
+1 416 443-1734 [h] +1 416 595-5425 [w] VE3-TCP Toronto, Ontario; CANADA
-----------[000239][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 13:31:09 GMT From: 702WFG@SCRVMSYS.BITNET (bill gunshannon) To: comp.protocols.tcp-ip Subject: TCPIP for the 3B1
I find all this talk about WINTCP and BSD and 3B1s very interesting, but
it leaves one very big question (at least to me.) Where does one look to
find an ethernet card for a 3B1?? I have a pair of them that I would love
to put on my ethernet and then start writing some decent software for them.
I would have to write it myself, cause I sure couldn't afford to buy it
from Wolongong!!!
Any ideas about where I can find real cheap ethernet cards for a couple of
3B1s???
bill
bill gunshannon
702WFG@SCRVMSYS.BITNET
-----------[000240][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 13:35:32 GMT From: thorin!menges!menges@mcnc.org (John Menges) To: tcp-ip@nic.ddn.mil Subject: SNMP Application Query
I've been away from network management for a while and need an update on what's available in the way of SNMP applications for under, say, $2500. A year ago I'd have chosen Nysernet's SNMP distribution, possibly augmented by CMU's or MIT's public domain stuff. Is anything else available now?
-----------[000241][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 14:23:16 GMT From: usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!jhunix!ereiamjh@ucsd.edu (Tom B. O'Toole) To: tcp-ip@nic.ddn.mil Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <1990May21.162713.1244@cbnewsd.att.com> cage@cbnewsd.att.com (charles.gerlach) writes: >Enough is enough. >The 3B1 WIN release you are complaining about is over 4 years old. To >the best of my knowledge, there has never been another release for the >3B1. (To say the 3B1 is "mature" is probably an understatement.) If it's so "mature" (translation "we won't support you any more"), shouldn't it at least work? It doesn't make much sense to declare something "mature" if it's obviously so immature... I also find it suspect that something that is not all THAT old should have been retired over 4 years ago. The VAX 11/780 is much older and new software releases are still coming out for that platform. An eye towards compatibility can work wonders... >I totally disagree when you extrapolate these problems to >cover the entire WIN/3B product line to date. To take the 3B1 WIN >release as a fair representation of the current products is wrong. Is the release of WIN/3b for the 3b/4000 considered current? It still has myriad problems. But I guess that doesn't matter because the 3b/4000 is now "mature", right??? Everyone should move on to yet another platform which is not binary compatible at the OS or applications level. > >I think your real problem is what do you do now? How do you >solve your problems? Unfortunately I don't have a solution. For starters, maybe AT&T should stop moving rapidly from platform to non-compatible platform, stating that each is the next "great thing" only to abandon it two years down the road. But since they keep doing this, I agree, there isn't a solution; the user is totally hosed. >Hopefully someone else does. It just that bashing AT&T or TWG >is not productive and does not get you closer to a solution. It >may make you feel better but ... People will feel even better when AT&T and TWG don't deserve to be bashed, but for now, it's the only "solution" they have... >Well thanks for listening. Is AT&T? -- Tom O'Toole - ecf_stbo@jhuvms.bitnet "Internet is the wide area network JHUVMS system programmer protocol packaged with TCP/IP that unix systems Homewood Computing Facilities rely on to communicate remotely with each other" Johns Hopkins University, Balto. Md. 21218 -Digital Review
-----------[000242][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 14:32:05 GMT From: paperboy!meissner@think.com (Michael Meissner) To: tcp-ip@nic.ddn.mil Subject: Re: Dealing with systems without nameservice.
In article <1990May22.042651.1911@eng.umd.edu> smaug@eng.umd.edu (Kurt
Lidl) writes:
| I was thinking about hacking in some changes to our version of libc
| gethost*() routines. We are currently running SunOS 4.0.3c on our
| Suns, but are looking at upgrading to 4.1... Sun has been good
| enough to tell us all how to make our own dynamically run libraries
| and I was thinking about putting in the U of Toronto's version of
| the resolver routines.
|
| One of the things that we have noticed is that if the nameservers
| are down, with the current version of libc (from uunet), nothing
| works. We have a small /etc/hosts file on all our machines that is
| kept up to date...
|
| What it all boils down to is this: If I alter the gethost*()
| routines to try the nameservers first, and then, if they fail, check
| the /etc/hosts files, will anything go terribly wrong? I am
| wondering why the current routines don't fall back on the hosts in
| /etc/hosts?
While this may not apply to Suns, other systems provide means that a
system manager can configure the order hosts are searched (/etc/hosts,
yp, and DNS). I know both DG/UX and Ultrix provide this capability
(in a slightly different fashion). Here is the appropriate man page
from Ultrix:
NAME
svcorder - designate the order and selection of services
SYNTAX
/etc/svcorder
DESCRIPTION
The file designates the order and selection of name services
that will be queried to resolve host names and addresses.
The queries to the services are made through the interface.
The file must exist if your system accesses host names and
addresses by database lookup services such as Yellow Pages
(YP) or BIND. You do not need the file if you only have
local access, that is, if you are using only the local file
to obtain host name and address information.
The service names are defined in the file.
The order in which the service names are placed in the file
indicates the order that they are queried to resolve a given
name or address. The following example shows the contents
of the file if YP will be queried first, then BIND, and then
the local service, if YP cannot resolve the data: yp bind
local The file must have an entry for Otherwise, your system
cannot resolve any queries in the event that the lookup
services, other than local, are down.
If you set up a database lookup service such as YP or BIND,
be sure that the file exists. Create the file if it does
not. The and commands do this automatically.
FILES
/etc/hosts
/usr/include/netdb.h
/etc/svcorder
SEE ALSO
gethostent(3n), hosts(5), bindsetup(8), ypsetup(8yp)
Guide to the BIND Service
Guide to the Yellow Pages Service
--
Michael Meissner email: meissner@osf.org phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA
Catproof is an oxymoron, Childproof is nearly so
-----------[000243][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 17:46:51 GMT From: 08071TCP@MSU.BITNET (Doug Nelson) To: comp.protocols.tcp-ip Subject: Re: Dealing with systems without nameservice.
From Stan Stead: > We are running 4.3 BSD. We currently use nameservice. However, >a site that we wish to exchange mail and files, while connected to the >internet, does not use nameservice. We can access the site by internet >number, but not by name. Is there anyway to "hot-wire" an address >(perhaps via /etc/hosts). Currently, the only way /etc/hosts is read >is if named is not running. The real answer is for them to set up name service. I can't think of any good reason for sites attached to the internet to not be running name service, or to find a site that can run name service for them. And from Kurt Lidl: >One of the things that we have noticed is that if the nameservers >are down, with the current version of libc (from uunet), nothing >works. We have a small /etc/hosts file on all our machines that is >kept up to date... If the name servers go down too frequently, you may want to set up more name servers, at least in caching mode. >What it all boils down to is this: If I alter the gethost*() >routines to try the nameservers first, and then, if they fail, check >the /etc/hosts files, will anything go terribly wrong? I am >wondering why the current routines don't fall back on the hosts in >/etc/hosts? This topic has been discussed. The answer is that for most applications (Telnet, FTP, etc.) the worst that will happen is that you will use the wrong address for a host due to old information. For mail, it can be worse - an SMTP mailer will likely bounce some mail because the host isn't listed in the hosts file. Or it may mis-deliver it due to the use of old information, or the failure to take MX records into account. Doug Nelson Michigan State University
-----------[000244][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 19:05:12 GMT From: vmp!sonyd1!bruce@uunet.uu.net (Bruce Lilly) To: tcp-ip@nic.ddn.mil Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <1990May21.162713.1244@cbnewsd.att.com> cage@cbnewsd.att.com (charles.gerlach) writes:
>Enough is enough.
>
>The 3B1 WIN release you are complaining about is over 4 years old. To
>the best of my knowledge, there has never been another release for the
>3B1. (To say the 3B1 is "mature" is probably an understatement.)
>
>But in the meantime, there have been 2 major releases to the WIN/3B and
>WIN/386 product lines. To imply that what you got has any resemblance
>to the current releases is stretching it a bit.
>
>I agree with you when you talk about the problems with the 3B1 WIN
>release. After 4 years, it would be unrealistic to expect it not to
>have any. I totally disagree when you extrapolate these problems to
>cover the entire WIN/3B product line to date. To take the 3B1 WIN
>release as a fair representation of the current products is wrong.
If one's sole experience with WIN/3B is the version for the 3B1, and
neither Wollongong nor AT&T has issued a fixdisk or other update for
the product, then it is reasonable to expect that the vendor(s) are
not interested in correcting the problems, and therefore the product
IS probably representative of other products from the vendor(s).
>I think your real problem is what do you do now? How do you
>solve your problems? Unfortunately I don't have a solution.
>Hopefully someone else does. It just that bashing AT&T or TWG
>is not productive and does not get you closer to a solution. It
>may make you feel better but ...
The real problem is what should AT&T and Wollongong do now? Speaking
for myself, I will certainly not buy any other Wollongong/AT&T
product unless and until they ``make good'' that which I have
purchased. Although the 3B1 has been discontinued, AT&T has
supported it with fixdisks. A similar policy regarding the
AT&T/Wollongong WIN/3B product for the 3B1 would go a long way
towards easing the current hard feelings toward the product.
It would seem to be in AT&T's interest to ensure that the product
works reasonably (especially the TLI routines -- AT&T's answer to
Berkeley-style networking) since AT&T's name is on the product.
Similarly, it is in Wollongong's interest to make a reasonable
effort to correct the product's deficiencies in order to AVOID
the impression that all Wollongong products are similarly
deficient. This is simply good business practice.
Finally, I don't recall seeing any ``bashing'' of either AT&T
or Wollongong -- simply the result of frustrations caused by
a clearly deficient product.
Disclaimer: these are my opinions, not my employer's.
--
Bruce Lilly, Product Manager, | bruce@sonyd1.Broadcast.Sony.COM
Digital Television Tape Recording, | uunet!{sonyusa,vmp}!sonyd1!bruce
Sony Communications Products Co. | lilb@sony.compuserve.com (slow)
Telephone: 1(201)833-5693 | FAX: 1(201)833-9279
-----------[000245][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 19:53:20 GMT From: pete@sinix.UUCP (Pete Delany) To: comp.protocols.nfs,comp.protocols.tcp-ip,bit.listserv.tcpip-l,comp.lang.postscript,comp.windows.news Subject: NeFS - Network Extensible File System
Carl Smith <cs@Eng.Sun.COM> mentioned that: > > The NFS version 3 protocol (now called NeFS - Network extensible > File System) is available as a PostScript file via anonymous > FTP as > > ./public/nefs.doc.ps on titan.rice.EDU (128.42.1.30). > > the file is ~250K and generates 52 pages. Is there a recient posting on usenet and if not could someone post one to make it easily available? It would take a non-trivial amount of work to FTP a copy and get it here. It sounds very important, and more than worthy of a posting. For those that have read the new NFS spec, any opinion? Sounds a bit like Microsoft focusing more on Windows 3.0 than OS2 (See Wall Street Journal 22-May-90). -pete
-----------[000246][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 20:36:34 GMT From: stealth.acf.nyu.edu!brnstnd@nyu.edu To: tcp-ip@nic.ddn.mil Subject: Re: Dealing with systems without nameservice.
Perhaps gethostbyname() should use intra-machine IPC (e.g., UNIX-domain sockets) to connect to the nameserver. This would have the advantage of strict modularity: you could change the name lookup mechanism without even recompiling any programs. It also wouldn't require the burden of shared libraries. /dev/hostbyname, maybe. > One of the things that we have noticed is that if the nameservers > are down, Gasp! Your nameservers go down? This can't be the ultra-reliable DNS we're talking about here? ---Dan
-----------[000247][next][prev][last][first]---------------------------------------------------- Date: 22 May 90 22:15:30 GMT From: cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!alberta!atha!lyndon@tut.cis.ohio-state.edu (Lyndon Nerenberg) To: tcp-ip@nic.ddn.mil Subject: is "localhost" an official name?
I seem to recall reading in an RFC somewhere that the loopback interface
must have loopback[.domain] as it's name, or as an alias. Is this in
fact the case? If so, I would appreciate a reference ...
--
Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University
{alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca
-----------[000248][next][prev][last][first]---------------------------------------------------- Date: 23 May 90 00:15:17 GMT From: mogul@decwrl.dec.com (Jeffrey Mogul) To: tcp-ip@nic.ddn.mil Subject: Re: A SUSPICIOUS SECURE GATEWAY
Phil Karn and Louie Mamakos have come down pretty hard against
filtering in routers. Phil sez
In my opinion, host security is both necessary and sufficient to prevent
break-ins.
Well, we've had a fair amount of experience with a screening gateway
between thousands of hosts inside DEC and the cruel world out there.
(People who want to know the details: see my paper in Proc. USENIX
Summer '89.) Anyone who thinks that it is possible to keep that many
hosts secure (most of them run by people who aren't interested in
keeping them secure, and probably wouldn't know how to do it) is dreaming.
Of course these machines can and should be fixed; at the same time,
we would be fools to believe that they all ever will be.
The advantage of the screening gateway is that we reduce the size of
the set of must-be-secure hosts from 10K or 100K down to around 10
or 100. I assert that it is possible to build a screening gateway
that will guarantee that only these hosts are exposed to attacks from
the network. (This is not to say that all implementations are secure,
of course!)
There is always the temptation to push the limits of this guarantee.
For example, we do allow certain kinds of packets to flow between
the Internet and random DEC hosts. This is done in the belief that
what we are doing is safe, but ultimately it is a tradeoff between
possibly impairing security and definitely impairing functionality.
If we discover that we have misunderstood the security implications,
we can pull the plug on this bypass at one place: the screening
gateway. We don't have to run around to 100K hosts and fix them all,
and we don't have to unplug from the network entirely while we
try to discover what happened.
Louie sez
I know that I can't sleep any better at night knowing that I have a
filtering gateway "protecting" me. If you want security, you need
to take a comprehensive approach to providing it, not shots in the
dark here and there.
I do sleep better knowing that the screening gateway is there. We've
had machines attacked by numerous and occasionally clever hackers,
but as far as we know (we could be wrong) the hosts inside the screen
have been untouched by such attacks as the Morris Worm and the
Australians earlier this year. In both those instances, I can point
to specific ways in which the screen prevented the problem from
spreading. I would not want to say that any of these hackers would
have been stopped forever by the screen, and I would not want to
say that I am sure that the screen protects me ... but I do sleep
better. (I know that the lock on my front door could be picked,
but I wouldn't get as much sleep if it were removed!)
In summary, a screening gateway is NOT a "shot in the dark", and it
IS part of a "comprehensive approach" to security. I claim that
for the time being, it is a required part of any approach that could
be claimed to be comprehensive; you can't rely on one mechanism for
security. Think of an ocean liner: the captain had better not let
the ship hit an iceberg, but when it happens (and it does!) those
watertight bulkhead doors may well save the passengers.
-Jeff
-----------[000249][next][prev][last][first]---------------------------------------------------- Date: Wed, 23 May 90 07:28:54 -0400 From: Stephen Wolff <steve@cise.nsf.gov> To: psuvm!pmw1@PSUVAX1.CS.PSU.EDU Cc: tcp-ip@NIC.DDN.MIL Subject: Re: Dial up access to Internet facilities
In article <NELSON.90May21230840@image.clarkson.edu>, nelson@sun.soe.clarkson.edu (Russ Nelson) says: >That's too bad, because when I've gone travelling in the past, I've called >the local university, asked for their terminal server's phone number, and >telnetted back to Clarkson to check my mail. It's a shame that that kind >of service has to go away... Dial-up access is now offered as a commercial service in some cities. It's all a part of the Internet's growing up... -s
-----------[000250][next][prev][last][first]---------------------------------------------------- Date: Wed, 23 May 90 10:23:41 pdt From: Walter Underwood <wunder@hp-ses.sde.hp.com> To: tcp-ip@nic.ddn.mil, comp.protocols.tcp-ip Subject: Re: A SUSPICIOUS SECURE GATEWAY
Jeff Mogul: The advantage of the screening gateway is that we reduce the size of the set of must-be-secure hosts from 10K or 100K down to around 10 or 100. HP does exactly the same thing. I think of it as similar to international borders. If you are flying into the US, you must land at an international airport. You can't land at any random airstrip. Maybe 1% of the airports in the US are set up with customs agents and all that border jazz. Same thing for hosts in HP. Less than 1% are "open subnet hosts", and those get special attention. We don't issue visas, though. That is Jeff's department. wunder
-----------[000251][next][prev][last][first]---------------------------------------------------- Date: 23 May 90 03:47:21 GMT From: ka9q.bellcore.com!karn@bellcore.com (Phil Karn) To: tcp-ip@nic.ddn.mil Subject: Re: A SUSPICIOUS SECURE GATEWAY
In article <435@jove.dec.com> mogul@decwrl.dec.com (Jeffrey Mogul) writes: >[...] I assert that it is possible to build a screening gateway >that will guarantee that only these hosts are exposed to attacks from >the network. (This is not to say that all implementations are secure, >of course!) How sure are you? You have a pretty big network, probably much larger than ours, and if it's at all like ours I bet you don't keep perfect track of *everything* that might be attached to it. Are you willing to bet that in some remote backwater of your network there isn't an unprotected Cisco terminal server or a Xylogics Annex box connected to a bunch of outside modem lines? How about the BSD workstation or PC running KA9Q or PCroute that somebody sets up in his office between his Ethernet tap and his office phone to give himself unpassworded, ad-hoc SLIP access from home? And are you willing to bet that every host on your network with outside dialups is completely secure? I think it's a rare organization whose ONLY possible route to the outside world is through exactly one IP router. I think that filtering IP routers are like the Maginot Line. The latter did exactly what it was designed to do. It's just that the Germans had plenty of other routes for attacking the West, so they simply went around it. Phil
-----------[000252][next][prev][last][first]---------------------------------------------------- Date: 23 May 90 06:46:39 GMT From: eru!luth!sunic!mcsun!inria!irisa!leconte@bloom-beacon.mit.edu (Thierry Leconte) To: tcp-ip@nic.ddn.mil Subject: C source of sftp (RFC913) wanted
I'm looking for public domain C sources of the Simple File Transfer Protocol (RFC 913) or any other simple file transfer protocol that use exclusively tcp (and not udp ). Please answer by email Thanks in advance ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Thierry LECONTE | , ,--- ,--- | | INRIA/IRISA | / / /--- | | Campus de Beaulieu | (___ (___ (___ | | 35042 RENNES CEDEX | | | FRANCE | GOTHIC project (INRIA/BULL) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Tel: 99 36 20 00 e-mail: Thierry.Leconte@irisa.fr | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------[000253][next][prev][last][first]---------------------------------------------------- Date: Wed, 23 May 90 11:19 EDT From: PARCHAMB@ecs.umass.edu To: tcp-ip@nic.ddn.mil Subject: mailing list
Please Remove my name from the mailing list Thanks, Peter
-----------[000254][next][prev][last][first]---------------------------------------------------- Date: 23 May 90 11:26:19 GMT From: mojo!smaug@mimsy.umd.edu (Kurt Lidl) To: tcp-ip@nic.ddn.mil Subject: Re: Dealing with systems without nameservice.
Doug Nelson (08071TCP@MSU.BITNET) writes: >And from Kurt Lidl: >>One of the things that we have noticed is that if the nameservers >>are down, with the current version of libc (from uunet), nothing >>works. We have a small /etc/hosts file on all our machines that is >>kept up to date... > >If the name servers go down too frequently, you may want to set up >more name servers, at least in caching mode. The particular incident that started this line of questioning on my part was dealing with a one second power glitch that nailed the SOA nameserver and the two caching nameservers for our network. All the dataless clients that were hit came up first (just a local hard disk to fsck, compared to a couple of gigabytes of storage on the nameserving machines), and then failed to add the default gateway when "route" was unable to get the address of the gateway from the nameservers. I guess the real solution to the problem is giving the SOA nameserver have a UPS of its own. (Aha! The solution involves spending money. Luckily, it is not my money.) >>[my naive question was here] >This topic has been discussed. Are there a comprehensive sets of archives that I can FTP from someplace or another? I assume that someone must archive this group for posterity's sake. (I don't remember seeing a "Commonly Asked Questions" message, or any announcements of a archive site for this newsgroup. Maybe I just missed them.) >Doug Nelson I would also like to take this opportunity to thank all of the individuals who responded to my questions in a most helpful manner. Jim Guyton guyton@rand.org Richard Dunbar rdunbar@dftsrv.gsfc.nasa.gov Tony Nardo trn@warper.jhuapl.edu Steve Miller steve@umiacs.umd.edu Doug Nelson 08071TCP%MSU.BITNET@CORNELLC.cit.cornell.edu (reply posted to tcp-ip as well as mailed) The general concensus was that having the gethost*() routines fall back on the /etc/hosts file is "iffy at best". I may try the modifications for the heck of it, at least for the simple address lookup call. Several of the responses pointed out that bad interactions would happen with MX-record things and so forth... Steve pointed out that keeping anything in the /etc/hosts file that was not under my administrative control would be a *bad* thing to do. I agree with this whole-heartedly. If I have any really outrageous problems with the modifications, I will let the list know about them. Also, if anyone can give a really good reason NOT to make these changes, please mail me. The worst that has been pointed out to me was the possibility of some bounced mail. Thanks again. -- /* Kurt J. Lidl (smaug@eng.umd.edu) | Unix is the answer, but only if you */ /* UUCP: uunet!eng.umd.edu!smaug | phrase the question very carefully. */
-----------[000255][next][prev][last][first]---------------------------------------------------- Date: Wed, 23 May 90 18:54:09 -0400 From: "Martin Lee Schoffstall" <schoff@psi.com> To: snorkelwacker!spdcc!dyer@tut.cis.ohio-state.edu (Steve Dyer) Cc: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
Steve and Steve,
PSI does not offer Internet access through its free dialups scattered
throughout the US, the access is restricted to its customer base
by using validated network numbers.
This service has been advertised through our brochure since Janaury.
Aside from any economic considerations in providing an Internet wide
terminal service there are two issues that are of signifcant concern
to us:
1) Is it appropriate for any organization to provide this service in
consideration of the security issues, and appropriate use
of many people's network.
2) What are the legal/monetary liability issues for an organization
who's customer did something "bad".
Essentially we're concerned about being good Internet citizens here,
we could price, bill, and deliver Internet access dialups throughout
the US. But is that a good thing?
I believe that a number of network providers may require active
filtering against this type of dialup to protect themselves. Our
current customers certainly ask and we provide the addresses
for that purpose.
Marty
------------------------
In article <9005231128.AA19114@ncri.cise.nsf.gov> steve@cise.nsf.gov (Stephen
Wolff) writes:
>Dial-up access is now offered as a commercial service in some cities. It's
>all a part of the Internet's growing up... -s
And when they start advertising so that potential clients actually *know*
about it, then the Internet will really have passed adolescence. :-)
I'd love to hear more about this. I hope such services don't require that
you have a direct hookup to their own network in order to take advantage
of the dialups (i.e., TACACS at the dialup point only authorizes you iff
you are in their databases, and you only get into their databases if your
site is spending big bucks for a direct connection to their network.)
That is, as a NEARnet/CENTnet site, I'd hardly have a preexisting arrangement
with PSI, UUNET, MERIT, etc. Maybe we need something like cellular
"roaming"...
--
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
-----------[000256][next][prev][last][first]---------------------------------------------------- Date: 23 May 90 12:49:08 GMT From: att!dptg!mtune!rkh@ucbvax.Berkeley.EDU (Robert Halloran) To: tcp-ip@nic.ddn.mil Subject: Re: Re. Wollongong TCP/IP
In article <539@secola.Columbia.NCR.COM> syackey@secola.UUCP (steve yackey) writes: >In article <3362@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>>If you want to see the best TCP/IP in its class, check out the TCP/IP >>>on UNIX System Release V 4.0 on AT&T's 6386 WGS series of machines. >>>It's Wollongong's. And we're proud of it. >> >>So AT&T threw out the Lachman-based one they supply standard with S5R4 >>and supply a Woolongong-based release instead? > >no, when you buy 5.4 you get lachman tcp. >when you buy a 6386, you get wollongong. for the 6386 at&t "upgraded" the tcp. The SVr4 source package includes Lachman TCP/IP code. Binary distributions for AT&T 3B (and probably 386 - haven't seen it) have TWG binaries included. On the 6386, the Micom/Interlan package we OEM'd has been replaced with TWG. Bob Halloran ========================================================================= UUCP: att!mtune!rkh Internet: rkh@mtune.dptg.att.com Disclaimer: If you think AT&T would have ME as a spokesman, you're crazed. Quote: "Remember, kids, if some weirdo in a blue suit offers you some DOS, JUST SAY NO!!!" =========================================================================
-----------[000257][next][prev][last][first]---------------------------------------------------- Date: 23 May 90 14:45:43 GMT From: mitel!sce!cognos!dy4!paul@uunet.uu.net (Paul Burry) To: tcp-ip@nic.ddn.mil Subject: Request for protocol overhead references
We are interested in any information that may be available regarding the processing overhead associated with network protocols such as TCP/IP, TP4, etc. In particular, we are interested in the amount of processing required per unit of data transferred via these protocols. Could someone please refer me to any relevant articles? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Paul Burry PHONE: (613)-596-9911 UUCP: ...!cognos!dy4!paul POST: Dy4 Systems Inc., 21 Fitzgerald Road, or ...!cognos!dy4!seu13!paul Nepean, Ontario, Canada K2H 9J4 -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Paul Burry PHONE: (613)-596-9911 UUCP: ...!cognos!dy4!paul POST: Dy4 Systems Inc., 21 Fitzgerald Road, or ...!cognos!dy4!seu13!paul Nepean, Ontario, Canada K2H 9J4
-----------[000258][next][prev][last][first]---------------------------------------------------- Date: 23 May 90 15:20:48 GMT From: mcsun!hp4nl!ncsbv!peter@uunet.uu.net (Peter Jannesen) To: tcp-ip@nic.ddn.mil Subject: PC-LAN and TCP-IP
A client of use has a tokenring network running IBM's pc-network. We would like to add to this network a UNIX box running 386/ix or SCO-UNIX. The only thing we want is a telnet session to the UNIX box. So I have the following questions: 1. Is there a tokenringcard driver for 386/ix or SCO-UNIX? 2. Is there a streams devices driver in sources avaible for UNIX. (To adopt this driver to the tokenring card). 3. Is there a driver for the tokenringcard from IBM which is capable to run PC-LAN and TCP-IP on the same time. 4. which products are availble to run TELNET/TCP-IP on a PC. How much memory use those product. =============================================================================== Peter Jannesen Network Communication Systems (N.C.S), The Netherlands Phone: +31104130093 Fax: +31104146452 Address: Westbaak 96 3012 KM Rotterdam, The Netherlands ===============================================================================
-----------[000259][next][prev][last][first]---------------------------------------------------- Date: Wed, 23 May 90 22:15:01 -0400 From: "Martin Lee Schoffstall" <schoff@psi.com> To: snorkelwacker!spdcc!dyer@think.com (Steve Dyer) Cc: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
> On this topic, I am concerned about the balkanization of the Internet > in the interest of "security" without attention being payed to what > customers want. I think that laying the blame for the balkanization of the Internet at the feet of security is a pretty superficial analysis. Most of the balkanization is an effect of the very concept of "regional networks" which have customers tied together by a national network which effectively has no customers. Some indviduals might posit that the model is exhausted and that national/international networks that have customers directly is the future for the Internet. > Clearly a dialup facility which restricts access to > members of a particular commercial network (like PSI) is one very > proper service, and I'm glad it's offered to its customers, but it > doesn't yet address the needs of people associated with regional > networks trying to stay in touch when they're out of town. Given that it is free to its customer base (a point that seems to have been overlooked) others might perceive it as a value added that a "competitor" doesn't have. You might even sell it that way to prospective customers.... :-) > Thus, I > applaud the efforts of CERFnet and UUNET to offer authenticated, > for-fee access to Internet as a whole. I can guarantee that I'll > be interested in using their services whereas Marty's (if I understand > him correctly) just looks like an interesting service. You don't understand me correctly. Essentially we've been waiting for the time that a prescedent is set, permission is granted, or a consensus may be achievable in the Internet community. That time may be now, and the PSI blitzkreig may descend. I'll of course let you know in the least crass commercial manner that I can, if it is of interest..... Marty
-----------[000260][next][prev][last][first]---------------------------------------------------- Date: 23 May 90 16:38:25 GMT From: snorkelwacker!spdcc!dyer@tut.cis.ohio-state.edu (Steve Dyer) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
In article <9005231128.AA19114@ncri.cise.nsf.gov> steve@cise.nsf.gov (Stephen Wolff) writes:
>Dial-up access is now offered as a commercial service in some cities. It's
>all a part of the Internet's growing up... -s
And when they start advertising so that potential clients actually *know*
about it, then the Internet will really have passed adolescence. :-)
I'd love to hear more about this. I hope such services don't require that
you have a direct hookup to their own network in order to take advantage
of the dialups (i.e., TACACS at the dialup point only authorizes you iff
you are in their databases, and you only get into their databases if your
site is spending big bucks for a direct connection to their network.)
That is, as a NEARnet/CENTnet site, I'd hardly have a preexisting arrangement
with PSI, UUNET, MERIT, etc. Maybe we need something like cellular
"roaming"...
--
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
-----------[000261][next][prev][last][first]---------------------------------------------------- Date: 23 May 90 16:48:07 GMT From: hercules!heap.cisco.com!byrd@apple.com (Bruce Byrd) To: tcp-ip@nic.ddn.mil Subject: MAC with SLIP
I'm trying to find software packages for the MAC that support SLIP (commercial and public domain). Can you send me an email if you know of any (besides cisco's public domain version). Thx, Bruce Byrd cisco Systems byrd@cisco.com
-----------[000262][next][prev][last][first]---------------------------------------------------- Date: 23 May 90 17:40:34 GMT From: auspex!guy@uunet.uu.net (Guy Harris) To: tcp-ip@nic.ddn.mil Subject: Re: Re. Wollongong TCP/IP
>>So AT&T threw out the Lachman-based one they supply standard with S5R4 >>and supply a Woolongong-based release instead? > >no, when you buy 5.4 you get lachman tcp. >when you buy a 6386, you get wollongong. for the 6386 at&t "upgraded" the tcp. Lots of people seem to have misread what I said. In the hope that nobody who hasn't yet had the opportunity to do so does so, I'll note that I said > ...the Lachman-based one they supply standard with S5R4... *explicitly acknowledging* that "when you buy 5.4 you get lachman tcp", and that what I was asking was whether AT&T, when building the S5R4 release that they supply as the OS for their 386-based machines, threw out the Lachman-based TCP/IP supplied in source form with S5R4 source, and replaced it with Woolongong's version. The answer to that question is "yes, they did".
-----------[000263][next][prev][last][first]---------------------------------------------------- Date: 23 May 90 18:25:53 GMT From: cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@tut.cis.ohio-state.edu (Henry Spencer) To: tcp-ip@nic.ddn.mil Subject: Re: A SUSPICIOUS SECURE GATEWAY
In article <23521@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes: >I think that filtering IP routers are like the Maginot Line. The latter did >exactly what it was designed to do. It's just that the Germans had plenty of >other routes for attacking the West, so they simply went around it. If one wishes a complete and accurate analogy, one should note that the original planners of the Maginot Line specified that it should cover the routes the Germans ended up using... it was cut back by the politicians to save money. -- Life is too short to spend | Henry Spencer at U of Toronto Zoology debugging Intel parts. -Van J.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
-----------[000264][next][prev][last][first]---------------------------------------------------- Date: 23 May 90 18:29:34 GMT From: rick@uunet.uu.net (Rick Adams) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
UUNET plans to offer access to any Internet site from any Compuserve Dialup in the continental US. All access will require an individual login/password for accountability and authorization to use the Internet will be verified before the account is established. Performance is "acceptable". Certainly better than the MILNET TACs, but not quite as good as a direct modem connection. We plan to charge $5 per connect hour (in increments of 1 minute). We could start tomorrow if I could figure out how to bill for it. Its not worth sending out invoices for only $5. --rick
-----------[000265][next][prev][last][first]---------------------------------------------------- Date: 23 May 90 18:31:48 GMT From: zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@tut.cis.ohio-state.edu (Henry Spencer) To: tcp-ip@nic.ddn.mil Subject: Re: Wither Ethernet?
In article <9005211233.AA15946@gateway.mitre.org> hal@GATEWAY.MITRE.ORG (Hal Feinstein) writes: >It has been suggested by some standards gurus that in the future >all LANs will be "standardized" to ISO/IEEE802 and that ethernet is a dead >(or possibly dying) protocol... Um, what do you mean by "Ethernet"? If you're referring to the hardware, all three flavors -- Ethernet 1, Ethernet 2, and 802.3 -- are pretty much cable-compatible and there is no issue here. Half the people with Ethernet networks probably don't even know exactly which flavor all their boxes are. Or care. If you're thinking of the 802.2 protocol stuff as opposed to Ethernet packet-type codes, or the OSI protocol stack as opposed to TCP/IP (neither of which is tied to Ethernet in any way), then to borrow a phrase from the past, if this is so, it's one of the few known protocols that is dying out on a steep upward curve. -- Life is too short to spend | Henry Spencer at U of Toronto Zoology debugging Intel parts. -Van J.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
-----------[000266][next][prev][last][first]---------------------------------------------------- Date: 23 May 90 21:04:43 GMT From: usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali!ogicse!plains!lodin@ucsd.edu (Joe Schmo) To: tcp-ip@nic.ddn.mil Subject: Subnetting problems
I have a question relating to subnetting. We at GM/EDS/Delco are starting
to get our act together and registering all TCP/IP hosts on the company
internetwork. As far as I know, GM/EDS has been given the class B Internet
Address 130.171. Delco has been given the address range 130.171.8-15 from
EDS. They (EDS) have decided to divide it as such for Delco:
130.171.8.0 - 130.171.11.255 subnet mask 0xfffffc00 broadcast 130.171.11.255
130.171.12.0 - 130.171.12.15 subnet mask 0xfffffff0 broadcast 130.171.12.15
130.171.12.16 - 130.171.12.31 subnet mask 0xfffffff0 broadcast 130.171.12.31
...
130.171.12.128 - 130.171.12.159 subnet mask 0xfffffe0 broadcast 130.171.12.159
130.171.12.160 - 130.171.12.191 subnet mask 0xfffffe0 broadcast 130.171.12.151
...
130.171.14.0 - 130.171.14.63 subnet mask 0xffffffc0 broadcast 130.171.14.63
130.171.14.64 - 130.171.14.127 subnet mask 0xffffffc0 broadcast 130.171.14.127
...
130.171.15.0 - 130.171.14.127 subnet mask 0xffffff80 broadcast 130.171.14.127
130.171.15.128 - 130.171.14.255 subnet mask 0xffffff80 broadcast 130.171.14.255
Essentially what they have done is subdivide our subnet into unequal
networks that would seem to require different netmasks. I have a gateway
workstation with one LANIC connected to the backbone with address
130.171.8.204 and then I have the network 130.171.12.1-15. If I set my
netmasks different, 0xfffffc00 on the gateway LANIC and 0xfffffff0 on the
local LANIC, my networking software has problems getting thru the gateway.
If I set them the same (0xfffffc00) then I can get thru the gateway fine,
but now the the range 130.171.12-15.xx seem to be on the same physical wire.
The machines involved are HP 9000/3XX w/HP-UX 7.0, Sun 386i w/SunOS 4.0.2,
Sun 4 w/SunOS 4.0.3, and eventually Intergraphs. The HP's are running gated
and the Suns are running routed.
Customer reps with HP and Sun recommended we keep the same netmask on all
machines regardless of the network, and for now that works until I want to
talk to machines in the rest of the 130.171.12-15 range.
Comer's book alludes to being able to have multiple subnets on the same
physical wire with discrete fixed routing tables. As an experiment, we
tried this (metric 0) and it didn't work. It also said something
about netmask information being kept in the routing tables, but I haven't
seen that in dumps from routed and gated. I could only see it in ifconfig
information.
From what I can determine, we may need to go to multiple virtual subnets on
one network like described in "Introduction to Administration of an
Internet-based Local Network". Yet this seems to imply that all subnets will
be of the same size.
I'm not sure of the planning or analysis that went into this method of
address allocation, but it seems to be improper. I understand that will a
company of our size, there will be tradeoffs in any decision involving
networking adminstration. We have small local department networks and large
company-wide networks, that in some instances, are all connected on the same
physical wire. EDS has traditionally been an IBM house, so I'm not sure of
their TCP/IP networking experience (go ahead and send flames), and I
question their network administrative tactics.
Please send any answers (:-), comments, references, or experiences to:
Steve Lodin
Advanced Instrumentation Engineering
-------------
Delco |Electronics| Corp
-------------
\
\
It's who we are
Tel: ATT 317-451-8722 GM 8-322-8722
Domain: lodin%koiasvr01.uucp@ee.ecn.purdue.edu
or swlodin@koess.gm.hac.com
UUCP: <backbone>![iuvax|pur-ee]!koiasvr01!lodin
GM: LODIN,SW <KOESS::SWLODIN>
-----------[000267][next][prev][last][first]---------------------------------------------------- Date: 23 May 90 22:59:24 GMT From: sdcc6!ee299at@ucsd.edu To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
In article <2936@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes:
>In article <9005231128.AA19114@ncri.cise.nsf.gov> steve@cise.nsf.gov (Stephen Wolff) writes:
>>Dial-up access is now offered as a commercial service in some cities. It's
>>all a part of the Internet's growing up... -s
>
>And when they start advertising so that potential clients actually *know*
>about it, then the Internet will really have passed adolescence. :-)
>
>I'd love to hear more about this. I hope such services don't require that
>you have a direct hookup to their own network in order to take advantage
>of the dialups (i.e., TACACS at the dialup point only authorizes you iff
>you are in their databases, and you only get into their databases if your
>site is spending big bucks for a direct connection to their network.)
>
>
>--
>Steve Dyer
>dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
>dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
CERFNet recently announced a dial-up internet access service
from terminal servers at UCLA , UCIrvine , Caltech , SDSC and UCOP(Oakland)
and will be expanding to other sites on demand.
The service also offers SLIP
A direct connection from your site to CERFNet is *NOT* required .
In fact we designed this service for those who do not need /cannot afford
the high-end service and those who like to "roam" ( we also offer mail and netnews)
You do need to prove that your use is commensurate with the "Internet Acceptable
Use Policy" and you will need to authenticate yourself whenever you login.
There will be a monthly fee and connect charges of $5/hr.
--pushpendra
pushp@cerf.net
(619) 534-5067
-----------[000268][next][prev][last][first]---------------------------------------------------- Date: 24 May 90 00:15:29 GMT From: snorkelwacker!spdcc!dyer@think.com (Steve Dyer) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
On this topic, I am concerned about the balkanization of the Internet
in the interest of "security" without attention being payed to what
customers want. Clearly a dialup facility which restricts access to
members of a particular commercial network (like PSI) is one very
proper service, and I'm glad it's offered to its customers, but it
doesn't yet address the needs of people associated with regional
networks trying to stay in touch when they're out of town. Thus, I
applaud the efforts of CERFnet and UUNET to offer authenticated,
for-fee access to Internet as a whole. I can guarantee that I'll
be interested in using their services whereas Marty's (if I understand
him correctly) just looks like an interesting service.
Of course, there are all sorts of ways to have your cake and eat it
too: I wouldn't have any problem with using a dialup service which
associated an authenticated dialup account with some restriction on the
target nets (or even hosts) which could be reached. Thus, an account
whose password was improperly disseminated would not be such a gaping
security hole. You're talking database lookups rather than static
address matching, of course.
--
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
-----------[000269][next][prev][last][first]---------------------------------------------------- Date: 24 May 90 03:16:38 GMT From: swrinde!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!news@ucsd.edu (Russ Nelson) To: tcp-ip@nic.ddn.mil Subject: UDP protocol for short messages?
Has anyone implemented a UDP protocol for sending short messages to a resource- limited host? If so, I'd like to see how you did it. I'm working on such a protocol, and I'd prefer to make new mistakes, rather than repeat any of yours. :-) -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667 Violence never solves problems, it just changes them into more subtle problems
-----------[000270][next][prev][last][first]---------------------------------------------------- Date: Thu, 24 May 90 10:12 EDT From: dangelo@whuts.att.com To: tcp-ip@nic.ddn.mil Subject: remove name from list
Please remove my name from the mailing list. Thank you. Diana
-----------[000271][next][prev][last][first]---------------------------------------------------- Date: Thu, 24 May 90 10:12:34 edt From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) To: rick@uunet.uu.net, tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
Since mail is one of the big uses of the Internet, do most people that subscribe to dial-up internet already have directly connected machines in other places at which they receive mail? Or will someone start selling permantly attached accounts in addition to dial-up, so that one can retrieve their mail after they dial-up? PT
-----------[000272][next][prev][last][first]---------------------------------------------------- Date: Thu, 24 May 90 15:10:10 -0400 From: Craig Partridge <craig@NNSC.NSF.NET> To: tcp-ip@nic.ddn.mil Subject: re: Dial up access to Internet facilities
I've always felt that the best solution to the dial-up access problem was to make it easy for people to hook up their PC to your local Ethernet, get a temporary IP address (via some address assignment protocol) and voila, they are connected. One could do similar things with a 900 voice line [dial 1-900-ARPANET, negotiate for a temporary IP address, you're off]. In other words, the key problem is making it easy for someone with a PC to get a local IP address and do something. Craig
-----------[000273][next][prev][last][first]---------------------------------------------------- Date: Thu 24 May 90 14:45:32-CDT From: Matt Jonson <AFDDN.JONSON@GUNTER-ADAM.AF.MIL> To: tcp-ip@nic.ddn.mil Subject: Netwatch ???
I heard that there was an ethernet monitor package called netwatch, and that the latest version was available for anonymous ftp from either husc6.harvard.edu or lancaster.andrew.cmu.edu. Unfortunately, I could not find it in either place. Am I blind? Is it called something other than netwatch? I got my original info off this mailing list, so please everyone bear with this repeat question. Thanks for any help. -Matt -------
-----------[000274][next][prev][last][first]---------------------------------------------------- Date: Thu, 24 May 90 16:51:54 EDT From: Mary Byrne <mbyrne@BBN.COM> To: tcp-ip@nic.ddn.mil Cc: mbyrne@BBN.COM Subject: remove me please
Kindly remove me from the list.
-----------[000275][next][prev][last][first]---------------------------------------------------- Date: 24 May 90 13:05:36 GMT From: sdd.hp.com!uakari.primate.wisc.edu!ark1!skister!tdrake@ucsd.edu (Tim Drake - E41) To: tcp-ip@nic.ddn.mil Subject: TCP/IP for ROLM 1666, in Fortran ??
Keywords:
I am a member of a team seeking to find/make a TCP/IP implemen-
tation for a ROLM 1666 (mainly the FTP portion). The only languages
available are assembly and FORTRAN. We have a TCP/IP implementation
for a General Data MV20000 which has a similar OS and the same
controller board as the ROLM. Unfortunately, this implementation is
written in C. We will consider any alternative that will aid in the
development/reuse of a TCP/IP package for a ROLM 1666.
1) Does a TCP/IP (at least the FTP portion) already exist for the ROLM
1666?
2) Is there a TCP/IP implementation already in FORTRAN (any flavor) for
any computer and OS?
3) Are there any C to FORTRAN translators available?
4) Does anybody have a C compiler front end that is suitable for a
plug-in code generator?
5) Is there a generic C compiler (or C compiler writing system) that
accepts some sort of target computer description?
6) Is there a near context-free grammar description available for C
that is suitable for YACC?
Please respond to any of these questions if you can. Thanks!
John J. Zaloudek
Naval Surface Warfare Center Phone: (703) 663-8547
Code N44 (DSN) 249-8547
Dahlgren, VA 22448 MILNET: jzaloud@relay.nswc.navy.mil
-----------[000276][next][prev][last][first]---------------------------------------------------- Date: 24 May 90 14:12:00 GMT From: dangelo@whuts.att.com To: comp.protocols.tcp-ip Subject: remove name from list
Please remove my name from the mailing list. Thank you. Diana
-----------[000277][next][prev][last][first]---------------------------------------------------- Date: 24 May 90 14:20:20 GMT From: matrix!venkat@uunet.uu.net (D Venkatrangan) To: tcp-ip@nic.ddn.mil Subject: TCP Urgent Mode.
I am looking for ways to determine where exactly in the sequence space
at the receive side, Urgent Data begins. The RFC793 on Transmission Contol
Protocol does not appear to be very clear on this.
TCP also provides a means to communicate to the receiver of data that
at some point further along in the data stream than the receiver is
currently reading there is urgent data. TCP does not attempt to
define what the user specifically does upon being notified of pending
urgent data, but the general notion is that the receiving process will
take action to process the urgent data quickly.
The above paragraph describes the general philosophy.
Urgent Pointer: 16 bits
This field communicates the current value of the urgent pointer as a
positive offset from the sequence number in this segment. The
urgent pointer points to the sequence number of the octet following
the urgent data. This field is only be interpreted in segments with
the URG control bit set.
Does this mean than Urgent Data starts at the beginning of this segment and
extends up to current segment's sequence number + urgent data pointer?
The objective of the TCP urgent mechanism is to allow the sending user
to stimulate the receiving user to accept some urgent data and to
permit the receiving TCP to indicate to the receiving user when all
the currently known urgent data has been received by the user.
This mechanism permits a point in the data stream to be designated as
the end of urgent information. Whenever this point is in advance of
the receive sequence number (RCV.NXT) at the receiving TCP, that TCP
must tell the user to go into "urgent mode"; when the receive sequence
number catches up to the urgent pointer, the TCP must tell user to go
into "normal mode". If the urgent pointer is updated while the user
is in "urgent mode", the update will be invisible to the user.
This again describes when "urgent mode" starts, but not where urgent data
starts. Do users of TCP, such as Telnet, agree on how many bytes of urgent
data exist and thereby know the start of urgent data?
Is there an update to RFC793 since Sept. 1981 that describes changes if any
to the TCP urgent mechanism?
If one were to implement the TLI API on top of TCP and were to provide the
t_rcv(fd, buf, nbytes, flagsp)
call, how would they be able to provide T_EXPEDITED data? TLI appears to
treat normal and expedited data as two independent streams.
Thanks.
-----------[000278][next][prev][last][first]---------------------------------------------------- Date: 24 May 90 15:42:07 GMT From: fernwood!hercules!dirt.cisco.com!kph@uunet.uu.net (Kevin Paul Herbert) To: tcp-ip@nic.ddn.mil Subject: Re: TCP/IP for ROLM 1666, in Fortran ??
I suggest checking out use of gcc from project GNU - it is a portable C compiler designed to be easy to retarget to different host architectures. Check out the gnu.* newsgroups for more information. Kevin
-----------[000279][next][prev][last][first]---------------------------------------------------- Date: 24 May 90 15:57:20 GMT From: bu.edu!bu-it!kwe@uunet.uu.net (Kent England) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up [blitzkreig]
In article <9005240215.AA01426@psi.com>,
schoff@PSI.COM ("Martin Lee Schoffstall") writes:
> ... That time may
> be now, and the PSI blitzkreig may descend.
>
Man the bunkers.
-----------[000280][next][prev][last][first]---------------------------------------------------- Date: 24 May 90 17:18:11 GMT From: rick@uunet.uu.net (Rick Adams) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
There already exist several places that will let you have an account that can send and receive Internet mail. They are not on the Internet and have no need to be. (Portal and the World are two examples). The major point of having dialup internet access is for people who alerady have accounts on Internet machines and need to "call home".
-----------[000281][next][prev][last][first]---------------------------------------------------- Date: 24 May 90 18:01:42 GMT From: intercon!news@uunet.uu.net (Amanda Walker) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
In article <9005240215.AA01426@psi.com>, schoff@PSI.COM ("Martin Lee
Schoffstall") writes:
> Some indviduals might posit that the model is exhausted and that
> national/international networks that have customers directly is the future
> for the Internet.
This, in fact, seems to be how many people (myself included) view things
even now. In fact, several people at PSI are probably all too aware that
I'm interested in being a customer of the Internet as a whole, and am
not particularly interested in what PSI can do for me except in pursuit of
that goal :-). Anyway...
I know that I tend to think of "the Internet" along the same
lines that I think of the interstate highway system. I know that each
piece is maintained by its oown tax base and personnel, but each piece is
also part an overall system. When I drive to NYC from DC, I think of it
as "getting on I-95 and heading north until I get to the George Washington
Bridge", not as getting on a series of "X Memorial Highways". Likewise,
when I was at OSU and FTP'd something from Stanford, I thought of it as
"using the Internet", not "using ORnet and PSCnet and MERIT and BARRnet...".
And, just as I avoid taking toll roads unless I have to, I'd prefer to have
the underlying partitioning of the Internet to be as invisible as possible.
Where this analogy breaks down, of course, is that the interstates are a
public resource (despite their "official" designation as the Defense Highway
System), and the Internet is not. On the other hand, the interstate system
shows that public access and subsidization is not necessarily a bad thing
either, even for a resource developed by the government.
--
Amanda Walker, InterCon Systems Corporation
--
"Go not to the elves for counsel, for they will say both no and yes."
--J.R.R. Tolkien, The Lord of the Rings
-----------[000282][next][prev][last][first]---------------------------------------------------- Date: 24 May 90 18:34:36 GMT From: sdcc6!cerf.net@ucsd.edu (Pushpendra Mohta) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
In article <9005241412.AA08804@chiya.bellcore.com> tsuchiya@THUMPER.BELLCORE.COM (Paul Tsuchiya) writes: >Since mail is one of the big uses of the Internet, do most people >that subscribe to dial-up internet already have directly connected >machines in other places at which they receive mail? Or will >someone start selling permantly attached accounts in addition to >dial-up, so that one can retrieve their mail after they dial-up? > >PT As I said earlier , if you can demonstrate that your use of the Internet is bonafide , CERFNet will offer you a "permanently attached account" on one of our machines . Other than helping the "roamers" our intention is to provide a low cost service to people with no current Internet access. In conjunction with our SLIP service, we are working on providing mail services through POP and alikes--- bringing the Internet to your portable PC.:-) --pushpendra CERFNet (619) 534-5056
-----------[000283][next][prev][last][first]---------------------------------------------------- Date: 24 May 90 19:10:10 GMT From: craig@NNSC.NSF.NET (Craig Partridge) To: comp.protocols.tcp-ip Subject: re: Dial up access to Internet facilities
I've always felt that the best solution to the dial-up access problem was to make it easy for people to hook up their PC to your local Ethernet, get a temporary IP address (via some address assignment protocol) and voila, they are connected. One could do similar things with a 900 voice line [dial 1-900-ARPANET, negotiate for a temporary IP address, you're off]. In other words, the key problem is making it easy for someone with a PC to get a local IP address and do something. Craig
-----------[000284][next][prev][last][first]---------------------------------------------------- Date: 24 May 90 19:10:58 GMT From: paperboy!meissner@think.com (Michael Meissner) To: tcp-ip@nic.ddn.mil Subject: Re: TCP/IP for ROLM 1666, in Fortran ??
In article <18329@hercules.csl.sri.com> kph@dirt.cisco.com (Kevin Paul
Herbert) writes:
| I suggest checking out use of gcc from project GNU - it is a portable C
| compiler designed to be easy to retarget to different host
| architectures. Check out the gnu.* newsgroups for more information.
Reality check time.
I believe that the ROLM 1666 computer is instruction compatible with
the DG MV/Eclipse computers. I wrote the front end for the DG C
compiler on the MV/Eclipse computers, and then switched over to
working on GNU C for the 88k (and now MIPS + ns32k). IMHO, it would
be a hericulean effort to port GCC to the MV architecture.
The biggest problem is that the MV has three types of pointers:
* bit pointers consisting of a word pointer in one register and
a bit offset in another, or alternatively, the word pointer
shifted left 4 bits + the bit offset in one register, which
restricts the range pointed to;
* word pointers (words are 16 bits, but word pointers can also
load 32 bits in one operation), which have three parts, an
indirect bit (which isn't always used), a segment field
(always 7 in normal user code), and the word offset.
* byte pointers, which is the word pointer shifted left one bit
position (loosing the indirect bit), and the byte number
within the 16-bit word in the least significant bit.
GCC firmly believes that there is only type of pointer (in fact, it
took somebody else a good month or two to just get the 88k compiler
running as a cross compiler on the MV, to straighten out the pointer
kinks in the compiler itself). The internal language has no means of
expressing the different pointer types, so you would have to always
resprent things as byte pointers, and continually do word <-> byte
pointer conversions.
The second biggest problem is the lack of registers. The machine only
has 4 integer registers and 4 floating point registers (the stack
registers are present in the machine, but you have to use explicit
instructions to move them to the integer registers to use them as
indexes, except directly after a SAVE). I suspect that the GCC
algorithms will break down if confronted with so few registers. The
registers are also not completely regular either -- memory references
involving word pointers can only be done from two registers, etc.
Finally, writing ANY new machine description for GCC is a #!$% of a
lot of work. It was a year of my time before I felt the 88k port was
reliable, and I was starting from a 3/4 finished port done by a person
who had done 2 other GCC ports previously.
It might be easier, to poke around, and see if the object formats are
compatible and if so, cross develop on the MV. Or write a translator
from the MV object format to the ROLM, if different.
--
Michael Meissner email: meissner@osf.org phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA
Catproof is an oxymoron, Childproof is nearly so
-----------[000285][next][prev][last][first]---------------------------------------------------- Date: 24 May 90 19:36:35 GMT From: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv!oss670!tkevans@tut.cis.ohio-state.edu (Tim Evans) To: tcp-ip@nic.ddn.mil Subject: TCP/IP for the MacIntosh?
My boss has just asked about putting Mac's on our TCP/IP Ethernet. Since I'm
not a regular reader of the Mac groups, can someone give me an E-mail
yell and let me know what's available and what's required to
implement it? Thanks.
PLEASE: Use the E-mail address BELOW, not the one above.
--
cc:Mail Tim K. Evans at ~OSS
UUCP ...!{rutgers|ames|uunet}!mimsy!woodb!tkevans
INTERNET tkevans%woodb@mimsy.umd.edu PHONE: (301) 965-3286
US MAIL 6401 Security Blvd, 2-Q-2 Operations, Baltimore, MD 21235
-----------[000286][next][prev][last][first]---------------------------------------------------- Date: 24 May 90 20:51:54 GMT From: mbyrne@BBN.COM (Mary Byrne) To: comp.protocols.tcp-ip Subject: remove me please
Kindly remove me from the list.
-----------[000287][next][prev][last][first]---------------------------------------------------- Date: 25 May 90 07:31:38 PDT (Friday) From: "Jeff_Lloyd.WGC1RX"@Xerox.COM To: mcsun!hp4nl!ncsbv!peter@uunet.uu.NET Cc: tcp-ip@nic.ddn.MIL Subject: Re: PC-LAN and TCP-IP
Peter, SCOs Open Desktop product (SCO UNIX 3.2 etc) is shipped with Lachmans' TCP/IP support. This product supports a nice range of standard (ish) ethernet cards PLUS Token Ring Boards. The system (ODT-NET) supports TCP/IP, Streams and IBM Lan Manager (NetBIOS) protocols. Therefore you can have all these from one ethernet or Token Ring board !!. Item 3. See Above. Item 4 has many options, those that come to mind are, Sun's PC-NFS - Telnet, FTP et al, Ethernet only, NFS (Of Course) would work nice with Open Desktop (Is as NFS too !) Uses Loadsa RAM. FTP TCP/IP Package Excelan - Telnet, FTP etc. LAN-Workplace Ethernet only (I Think) for DOS NetBIOS Support IBM LAN Manager support can be used to mount PC-Net disks from ODT. Most of the TCP/IP protocol support is down loaded to their board, (it has a 80186) this frees up loadsa RAM. Many others I can't think of...... Hope this helps -jeff BTW: I Don't work for sco :-) I just develop with ODT.
-----------[000288][next][prev][last][first]---------------------------------------------------- Date: Fri May 25 09:24:01 1990 From: robjohn@ocdis01.af.mil (Robert Johnson (CDC Contractor);CDC;) To: tcp-ip@nic.ddn.mil Subject: dial-up access to the Internet
It seems to me that the real question of dial-up access for the Internet stems from folks who travel and need to "phone home". The most obvious solution is to have a dial-up modem on their "home" system and stay off the Internet altogether. That way, their home system does all the user verification and auditing. But that's not how the real world works - right? I get a the willies about letting anyone dial up and get on the Internet without authentication and audit trail. That would seem to invite abuse. The open-door "guest" account is an invitation to disaster (or hassle, if the FBI asks why your system allowed the bad guy access to the Internet). Unfortunately, all sites seem to have their share of traveling dignitaries who need to check their email in some other corner of the world. To handle these, we set up a "guest" account which is password protected. When a user logs into this account, they see a list of systems that they can connect to. When a travelling dignitary comes on base, our customer support folks offer the courtesy of using the guest account, and provide him with the current password (they also make sure the right "home system" is currently on the menu). After he leaves, they change the password on the account. No logins to this guest account are allowed over modem or >from the Internet. The user must be "on base" to use the account. Not only are we controlling guest access, but visitors are impressed by our "thoughtfulness" in providing them with this "phone home" capability, without them having to ask for it. Bob Johnson Tinker AFB
-----------[000289][next][prev][last][first]---------------------------------------------------- Date: Fri, 25 May 90 10:05:34 -0500 From: Guy Almes <almes@rice.edu> To: robjohn@ocdis01.af.mil, tcp-ip@nic.ddn.mil Subject: Re: dial-up access to the Internet
robjohn@ocdis01.af.mil (Robert Johnson (CDC Contractor);CDC;) writes:<< But that's not how the real world works - right? I get a the willies about letting anyone dial up and get on the Internet without authentication and audit trail. That would seem to invite abuse. The open-door "guest" account is an invitation to disaster (or hassle, if the FBI asks why your system allowed the bad guy access to the Internet). Unfortunately, all sites seem to have their share of traveling dignitaries who need to check their email in some other corner of the world. >> Bob makes a good point which I'd like to strengthen. The Federation of American Research Networks (FARnet) has gone on record as urging its mid-level networks and the campuses they serve to dis-allow any unauthenticated access to the Internet. Specifically, terminal servers that require no authentication and then allow the caller full access to the Internet must be reconfigured to either require authentication or to provide access only to a set of hosts on campus that *do* require authentication. I also like his later example of how to be both courteous and careful:<< To handle these, we set up a "guest" account which is password protected. When a user logs into this account, they see a list of systems that they can connect to. When a travelling dignitary comes on base, our customer support folks offer the courtesy of using the guest account, and provide him with the current password (they also make sure the right "home system" is currently on the menu). After he leaves, they change the password on the account. No logins to this guest account are allowed over modem or >from the Internet. The user must be "on base" to use the account. Not only are we controlling guest access, but visitors are impressed by our "thoughtfulness" in providing them with this "phone home" capability, without them having to ask for it. Bob Johnson Tinker AFB >> This is one example, among many possibilities, of how to be responsible. -- Guy Almes
-----------[000290][next][prev][last][first]---------------------------------------------------- Date: Fri, 25 May 90 07:24:25 EDT From: rich@gateway.mitre.org To: tcp-ip@nic.ddn.mil
Subject: re: Dial up access to Internet facilities Date: Thu, 24 May 90 15:10:10 -0400 From: Craig Partridge <craig@NNSC.NSF.NET> Status: R Craig Partridge writes... > I've always felt that the best solution to the dial-up access problem > was to make it easy for people to hook up their PC to your local Ethernet, > get a temporary IP address (via some address assignment protocol) and > voila, they are connected. One could do similar things with a > 900 voice line [dial 1-900-ARPANET, negotiate for a temporary IP address, > you're off]. > In other words, the key problem is making it easy for someone with a > PC to get a local IP address and do something. > Craig While at Unisys, myself and others developed and implemented a system that did exactly what Craig describes... A PC user could dial into a gateway that would give the PC a temporary IP address. A protocol was also developed that would allow the PC user to update a modified Domain Name Server with its temporary IP address so that other hosts could initiate connections to the PC. An FTP user protocol, Telnet user protocol, and SMTP server protocol implementations were written to run on the PC. The usefulness is that a user with a portable PC can dial into a system and his email would automatically be sent to the PC at the temporary location. More information on this system can be found in the conference record of MILCOM '89, under "PHASE, A Portable Host Access System Environment". Rich Verjinski rich@gateway.mitre.org
-----------[000291][next][prev][last][first]---------------------------------------------------- Date: Fri, 25 May 90 10:35:42 PDT From: braden@venera.isi.edu To: matrix!venkat@uunet.uu.net, tcp-ip@nic.ddn.mil Cc: braden@venera.isi.edu Subject: Re: TCP Urgent Mode.
From tcp-ip-RELAY@NIC.DDN.MIL Fri May 25 01:59:41 1990 Date: 24 May 90 14:20:20 GMT From: matrix!venkat@uunet.uu.net (D Venkatrangan) Organization: Matrix Computer Systems, Nashua, NH Subject: TCP Urgent Mode. Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am looking for ways to determine where exactly in the sequence space at the receive side, Urgent Data begins. The RFC793 on Transmission Contol Protocol does not appear to be very clear on this. TCP also provides a means to communicate to the receiver of data that at some point further along in the data stream than the receiver is currently reading there is urgent data. TCP does not attempt to define what the user specifically does upon being notified of pending urgent data, but the general notion is that the receiving process will take action to process the urgent data quickly. The above paragraph describes the general philosophy. Urgent Pointer: 16 bits This field communicates the current value of the urgent pointer as a positive offset from the sequence number in this segment. The urgent pointer points to the sequence number of the octet following the urgent data. This field is only be interpreted in segments with the URG control bit set. Does this mean than Urgent Data starts at the beginning of this segment and extends up to current segment's sequence number + urgent data pointer? Yes. Up to, but not including. See RFC-1122 p. 84 for more info. This again describes when "urgent mode" starts, but not where urgent data starts. Do users of TCP, such as Telnet, agree on how many bytes of urgent data exist and thereby know the start of urgent data? Urgent data starts as soon as an Urgent Ptr appears. Is there an update to RFC793 since Sept. 1981 that describes changes if any to the TCP urgent mechanism? If one were to implement the TLI API on top of TCP and were to provide the t_rcv(fd, buf, nbytes, flagsp) call, how would they be able to provide T_EXPEDITED data? TLI appears to treat normal and expedited data as two independent streams. Thanks. It's not clear you can map TCP urgent into a user interface that has two independent streams. The essential piece of information that the receiving application has to be able to get is: How many bytes of urgent data remain to be read? As long as the answer is non-zero, the application has to be in "urgent mode"; when the result reaches zero, normal mode resumes. Bob Braden
-----------[000292][next][prev][last][first]---------------------------------------------------- Date: Fri, 25 May 90 10:27 EST From: <MLEVIN%TUFTS.BITNET@mitvma.mit.edu> To: tcp-ip@nic.ddn.mil Subject: multinet problem
We (Tufts U) have an Encore running Umax 4.2 on a network with
a VAX running VMS. The vax has the multinet package, and
I was trying the ttcp.c program supplied in [multinet.examples].
It seems that the only way it works with the sender on VMS
and the reciever on the UMAX system is with the -u option (using
datagrams, instead of SOCK_STREAM). Why? Is there any way to
get it to use the stream protocol? I note that it works fine
without the -u when the vax program recieves, and the Umax sends.
It also works fine when both modules are run on VMS machines.
Any ideas?
Mike Levin
-----------[000293][next][prev][last][first]---------------------------------------------------- Date: Fri, 25 May 90 10:29:53 EDT From: rich@gateway.mitre.org (Richard Verjinski) To: tcp-ip@nic.ddn.mil
Craig Partridge writes...
> I've always felt that the best solution to the dial-up access problem
> was to make it easy for people to hook up their PC to your local Ethernet,
> get a temporary IP address (via some address assignment protocol) and
> voila, they are connected. One could do similar things with a
> 900 voice line [dial 1-900-ARPANET, negotiate for a temporary IP address,
> you're off].
> In other words, the key problem is making it easy for someone with a
> PC to get a local IP address and do something.
> Craig
While at Unisys, myself and others developed and implemented a system that
did exactly what Craig describes...
****
I feel it necessary to publicly acknowledge the persons
described as "others" in the above statement.
Those people are: John Swanson, Jose Rodrigues, Jim O'Conner,
and Ed Yancy.
I apologize for not mentioning each person explicitly.
Rich Verjinski
-----------[000294][next][prev][last][first]---------------------------------------------------- Date: 25 May 90 08:32:32 GMT From: ka9q.bellcore.com!karn@bellcore.com (Phil Karn) To: tcp-ip@nic.ddn.mil Subject: Re: A SUSPICIOUS SECURE GATEWAY
In article <9005231723.AA20278@hp-ses.sde.hp.com> wunder@HP-SES.SDE.HP.COM (Walter Underwood) writes: >HP does exactly the same thing. I think of it as similar to >international borders.[...] That's not a bad analogy, because I absolutely detest having to deal with customs stations. And I certainly don't depend on US customs to protect my house (or computer) from being burglarized. My personal favorite analogy is the Berlin Wall. Shortly after the wall was opened some East German official was quoted by the AP as saying that the wall as a whole would stay up because it was "necessary to protect East Germans against AIDS", among other things. Unfortunately, this kind of thinking is not unheard of in the computer security business. Once again, I argue that there is no substitute for each individual taking the responsibility for protecting his own local domain. Security mechanisms are always most effectively implemented as close as possible to whatever is being protected. Phil
-----------[000295][next][prev][last][first]---------------------------------------------------- Date: Fri, 25 May 90 15:38:54 pdt From: Walter Underwood <wunder@hpsdel.sde.hp.com> To: tcp-ip@nic.ddn.mil, comp.protocols.tcp-ip Subject: Re: Wither Ethernet?
If find it really amusing that the vendor independent standard, IEEE 802, is mostly used for proprietary protocols (HP, IBM, and Apple), while the proprietary standard, Ethernet (remember DEC, Intel, and Xerox?) carries all the multi-vendor protocols. Just goes to show that you can't judge a standard by its cover. wunder PS: Nearly all HP equipment can talk Ethernet and ARP these days. Only one OS, MPE/XL, is still 802-only, and Ethernet is scheduled for release on that, too.
-----------[000296][next][prev][last][first]---------------------------------------------------- Date: Fri, 25 May 90 12:51:54 EDT From: stine@sparta.com (Robert Havens Stine) To: AFDDN.JONSON@GUNTER-ADAM.AF.MIL, tcp-ip@nic.ddn.mil Subject: Re: 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.
Available in a standalone package via anonymous FTP
from windom.ucar.edu, in file pc/network/netwatch.arc;
a binary "dearc" program is also available from
windom.ucar.edu.
Cheers,
Bob Stine
-----------[000297][next][prev][last][first]---------------------------------------------------- Date: Fri, 25 May 90 17:28:54 -0400 From: Craig Partridge <craig@NNSC.NSF.NET> To: tcp-ip@nic.ddn.mil Subject: SIGCOMM '90 Information
Hi folks:
Postscript copies of the SIGCOMM '90 Program and Registration form can
FTPed at the following location:
nnsc.nsf.net:CCR/sigcomm90-prog.ps
nnsc.nsf.net:CCR/sigcomm90-reg.ps
For those of you who don't have FTP access or prefer plain text, please
be patient -- plain text copies of the registration materials will be
e-mailed out sometime next week.
Craig
PS: Please note, the SIGCOMM '90 phone number and e-mail address may work
until June 1st.
-----------[000298][next][prev][last][first]---------------------------------------------------- Date: 25 May 90 11:22:22 GMT From: psuvm!pmw1@cunyvm.cuny.edu (Peter Weiss) To: tcp-ip@nic.ddn.mil Subject: Anonymous FTP case sensitivity
Being an Anonymous FTP neophite, I discovered at least one host that was case sensitive to the userid _anonymous_. Is this standard practice? /Pete
-----------[000299][next][prev][last][first]---------------------------------------------------- Date: 25 May 90 12:48:54 GMT From: swrinde!zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!roy@ucsd.edu (Roy Smith) To: tcp-ip@nic.ddn.mil Subject: Re: (none)
In <9005251124.AA00811@mercury.mitre.org> rich@GATEWAY.MITRE.ORG writes:
> A PC user could dial into a gateway that would give the PC a temporary IP
> address. A protocol was also developed that would allow the PC user to
> update a modified Domain Name Server with its temporary IP address so
> that other hosts could initiate connections to the PC.
One could set up a Shiva NetModem in dial-in-network-access mode on
an AppleTalk net behind a FastPath running KIP and then anybody with a Mac
could do exactly that. KIP hands out IP addresses from a pool on a dynamic
basis and all you need at the remote end is a Mac, any of a number of
commercial or free IP packages, and a regular 1200/2400/9600 bps modem.
The only thing missing is the automatic updating of DNS, but if your intent
is to just let the roming user get his/her mail, all you need is an account
on a POP server and DNS doesn't have to know anything.
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"
-----------[000300][next][prev][last][first]---------------------------------------------------- Date: 25 May 90 15:27:00 GMT From: MLEVIN@TUFTS.BITNET To: comp.protocols.tcp-ip Subject: multinet problem
We (Tufts U) have an Encore running Umax 4.2 on a network with
a VAX running VMS. The vax has the multinet package, and
I was trying the ttcp.c program supplied in [multinet.examples].
It seems that the only way it works with the sender on VMS
and the reciever on the UMAX system is with the -u option (using
datagrams, instead of SOCK_STREAM). Why? Is there any way to
get it to use the stream protocol? I note that it works fine
without the -u when the vax program recieves, and the Umax sends.
It also works fine when both modules are run on VMS machines.
Any ideas?
Mike Levin
-----------[000301][next][prev][last][first]---------------------------------------------------- Date: 25 May 90 15:58:40 GMT From: silver!hughes@iuvax.cs.indiana.edu (larry hughes) To: tcp-ip@nic.ddn.mil Subject: tn3270 daemon?
Does anyone know of a tn3270 daemon, somewhat of a hybrid between telnetd and (reverse) tn3270? I'm fairly certain there's no such animal, but if there is we'd have a good use for it. Please respond via email...thanks in advance. //=========================================================================\\ || Larry J. Hughes, Jr. || hughes@ucs.indiana.edu || || Indiana University || || || University Computing Services || "The person who knows everything || || 750 N. State Road 46 Bypass || has a lot to learn." || || Bloomington, IN 47405 || || || (812) 855-9255 || Disclaimer: Same as my quote... || \\==========================================================================//
-----------[000302][next][prev][last][first]---------------------------------------------------- Date: 25 May 90 16:35:28 GMT From: ameristar!rick@sbcs.sunysb.edu (Rick Spanbauer) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
In article <9005240215.AA01426@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes:
>> Thus, I
>> applaud the efforts of CERFnet and UUNET to offer authenticated,
>> for-fee access to Internet as a whole. I can guarantee that I'll
>> be interested in using their services whereas Marty's (if I understand
>> him correctly) just looks like an interesting service.
>
>You don't understand me correctly. Essentially we've been waiting
>for the time that a prescedent is set, permission is granted, or
>a consensus may be achievable in the Internet community. That time may
>be now, and the PSI blitzkreig may descend.
The plight of many small technical businesses is that we just cannot
justify spending $30K+ for access into the Internet for the occasional
FTP/smtp transfer. Were access fees brought inline with the level of
service offered, eg $2K-5K/yr for dialup SLIP is reasonable, surely PSI
and other regionals would see their business pick up substantially.
Note that it isn't small business alone that has a problem with
the high connection costs to the Internet. Ameristar sells IP/TCP
network products and every once in a while I ask some of our larger
customers ($20M & up) why they are not on the Internet. The answer is
usually that the perceived value of the connection is not in line with
the yearly access fee. In such cases, a low cost dialup SLIP service
would go a long way in giving people a chance to experiment with
Internet access to evaluate its usefullness to their organization.
Dialup SLIP is also a safe way for the regionals to toy with their
price/volume curve without having to add infastructure (ie additional
or higher capacity links) at the outset of the experiment.
One other suggestion I have is that the regionals ought to survey
potential customers about the sort of connectivity and services they
would purchase as a function of cost. Good starting sample data sets
might be the lists of technical companies that local business
organizations or government maintains, or even UUCP maps.
>I'll of course let you know in the least crass commercial manner that
>I can, if it is of interest.....
Please do make an announcement of any new services PSI introduces. I
for one would like to hear what PSI is doing to moderate access fees
without having to ping your sales organization every few months.
>Marty
Rick Spanbauer
Ameristar Technology
Usual disclaimers: my opinions are my own, etc.
-----------[000303][next][prev][last][first]---------------------------------------------------- Date: 25 May 90 18:05:51 GMT From: zaphod.mps.ohio-state.edu!rpi!crdgw1!gecrdvm1!hathawa@tut.cis.ohio-state.edu (Barry Hathaway) To: tcp-ip@nic.ddn.mil Subject: Re: tn3270 daemon?
In article <45793@iuvax.cs.indiana.edu>, hughes@silver.ucs.indiana.edu (larry hughes) says: > >Does anyone know of a tn3270 daemon, somewhat of a hybrid between >telnetd and (reverse) tn3270? I'm fairly certain there's no such >animal, but if there is we'd have a good use for it. > Many TCP/IP packages for IBM mainframes offer terminal emulation on the host side - which I guess could be called a tn3270 daemon. Fibronics (aka Sparticus) KNET package has this as an option. Simware offers SIM/TCPIP an add-on to IBM's TCP/IP package which does terminal emulation.
-----------[000304][next][prev][last][first]---------------------------------------------------- Date: 25 May 90 18:25:03 GMT From: auspex!guy@uunet.uu.net (Guy Harris) To: tcp-ip@nic.ddn.mil Subject: Re: TCP Urgent Mode.
>If one were to implement the TLI API on top of TCP and were to provide the > > t_rcv(fd, buf, nbytes, flagsp) > >call, how would they be able to provide T_EXPEDITED data? TCP doesn't really have expedited data in the same way that, say, TP4 does; it has an urgent pointer. >TLI appears to treat normal and expedited data as two independent streams. Yup. S5R4's streams code implements the notion of a "marked" message for precisely that reason; that's how it handles the urgent pointer. It may also support the notion that the last byte of urgent data is treated as expedited data, as per, say, 4.2BSD, and 4.3BSD when SO_OOBINLINE isn't set.
-----------[000305][next][prev][last][first]---------------------------------------------------- Date: 25 May 90 19:33:22 GMT From: usc!samsung!dali!uakari.primate.wisc.edu!sdd.hp.com!elroy.jpl.nasa.gov!aero!aerospace.aero.org!obrien@ucsd.edu (Michael O'Brien) To: tcp-ip@nic.ddn.mil Subject: IP/TCP/UDP benchmarks?
Some folks around here have to benchmark a number of different boxes, and they've asked me to help with the part that benchmarks TCP/IP and UDP performance. Before I go off developing wheels, I'd like to know of any prior art. I already know about "ttcp.c" on brl.mil. Is there any other IP/TCP/UDP benchmarking software out there? As always, please respond by email and I'll summarize if there's interest. -- Mike O'Brien obrien@aerospace.aero.org
-----------[000306][next][prev][last][first]---------------------------------------------------- Date: 25 May 90 20:53:09 GMT From: smb@ulysses.att.com (Steven Bellovin) To: comp.protocols.tcp-ip Subject: Re: Wither Ethernet?
In article <9005211233.AA15946@gateway.mitre.org>, hal@GATEWAY.MITRE.ORG (Hal Feinstein) writes: > It has been suggested by some standards gurus that in the future > all LANs will be "standardized" to ISO/IEEE802 and that ethernet is a dead > (or possibly dying) protocol. I've never been a worshipper of ``standards'' that try to impose rather than describe. 802.3 would seem to me to meet that criterion, I'm afraid. At least in the TCP/IP world, I don't see that much movement to 802.3 (and away from Ethernet) simply because there's no compelling reason to. The current technology is here, it works, and it's compatible with (almost) everyone else. I'm sure folks will correct me if I'm wrong, but I thought that HP was the only major vendor to try to use 802.3 encapsulation for IP over Ethernet, and that a few others (i.e., Cisco) would accomdate them, mostly for compatibility. Furthermore, as a result, it was hard to talk to some HP machines. The 802.3 format -- and in particular the 802.2 goo you're supposed to use -- makes sense if you're trying to do routing at that layer. In ``our'' world, there's a better, more flexible way to do routing, and that's at the IP layer. So why switch? The situation is different for other media. Token ring is inhabited by bluish PCs, and FDDI was decreed from the outset to use 802.2. For those, a simpler (or at least different) encapsulation has never had a chance to take hold. Thus, 802.2 will rule, even for IP. The higher levels? I'm *not* going to start another TCP/IP vs OSI flamefest here today... --Steve Bellovin P.S. I don't have a very good track record as a prophet; beware...
-----------[000307][next][prev][last][first]---------------------------------------------------- Date: 25 May 90 21:04:45 GMT From: smb@ulysses.att.com (Steven Bellovin) To: comp.protocols.tcp-ip Subject: Re: A SUSPICIOUS SECURE GATEWAY
In article <9005231723.AA20278@hp-ses.sde.hp.com>, wunder@HP-SES.SDE.HP.COM (Walter Underwood) writes: > HP does exactly the same thing. And Bell Labs goes even farther; we have just 2 non-isolated machines on the Internet. Application-level gateways do the rest. Why? Because in the Real World (whatever that is), our machines are not secure enough today. Blame complacent vendors, blame lazy administrators, blame careless users -- it doesn't matter much, since the empirical fact remains: a very significant fraction of hosts (and not just ours, I might add) are vulnerable. We, as a corporation, have chosen not to take the risk of exposure. Total isolation would be a serious problem; as is, most of what most people need to do on the Internet -- mail, FTP out, telnet both ways -- can be handled in a safer fashion. And most of the exceptions can be dealt with in other ways -- we do have a few more hosts that are directly connected to the Internet, but they're used for special purposes, and don't talk to anything else internally; they're dead ends. In the abstract, I mostly agree with Phil Karn -- hosts should be able to protect themselves. In fact, I spend a lot of my time working on mechanisms to help that cause. In practice, neither he nor I can administer every machine in our respective companies. I'll quote Phil's own article: The hard problem, as it turns out, lies not in generating a list of vulnerable systems, but in getting the administrators of those machines to update their software or to fix their system configurations. It's not a technical problem, but it's very real. And, given rlogin and its friends, if one host falls, a lot more will fall with it. Incidentally, I say ``mostly'' because there's an important class of device -- dial-out modems -- that is not capable of security today, and is not likely to be in the forseeable future. Finding a dialer pool on the Internet would be a hacker's idea of heaven.
-----------[000308][next][prev][last][first]---------------------------------------------------- Date: 25 May 90 21:28:54 GMT From: craig@NNSC.NSF.NET (Craig Partridge) To: comp.protocols.tcp-ip Subject: SIGCOMM '90 Information
Hi folks:
Postscript copies of the SIGCOMM '90 Program and Registration form can
FTPed at the following location:
nnsc.nsf.net:CCR/sigcomm90-prog.ps
nnsc.nsf.net:CCR/sigcomm90-reg.ps
For those of you who don't have FTP access or prefer plain text, please
be patient -- plain text copies of the registration materials will be
e-mailed out sometime next week.
Craig
PS: Please note, the SIGCOMM '90 phone number and e-mail address may work
until June 1st.
-----------[000309][next][prev][last][first]---------------------------------------------------- Date: 25 May 90 23:25:56 GMT From: van-bc!sl@ucbvax.Berkeley.EDU (Stuart Lynne) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
In article <1990May25.163528.14300@ameristar> rick@ameristar (Rick Spanbauer) writes:
>In article <9005240215.AA01426@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes:
} The plight of many small technical businesses is that we just cannot
} justify spending $30K+ for access into the Internet for the occasional
} FTP/smtp transfer. Were access fees brought inline with the level of
} service offered, eg $2K-5K/yr for dialup SLIP is reasonable, surely PSI
} and other regionals would see their business pick up substantially.
van-bc has a dialup SLIP link (9600 bps) into BCNet and it works quite well.
It's low cost, but effective for an NNTP news feed, mail and the occasion FTP.
We have configured the modems (T2500's in V.32 mode) to auto-dial our private
phone number on DTR. Every ten minutes we run a script which tests if the link
is alive. If not we turn it off and on again. This drops the line and redials
it.
Works fairly reliably, and the cost is low. Now that we have it we couldn't
do without it.
--
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
-----------[000310][next][prev][last][first]---------------------------------------------------- Date: 26 May 90 02:14:51 GMT From: amelia!orville.nas.nasa.gov!jmccabe@ames.arc.nasa.gov (James D. McCabe) To: tcp-ip@nic.ddn.mil Subject: Please help! - History of Networking
I have been tasked to develop a "History of Networking" document that describes (in gory detail) the significant events of the networking world since the Big Bang. I would appreciate any pointers to good historical literature (besides IEEE journals) about networking hardware and protocols. Please send e-mail responses to my address. Thanks. Jim D. McCabe Numerical Aerodynamic Simulation (NAS) Program NASA/Ames Research Center jmccabe@nas.nasa.gov
-----------[000311][next][prev][last][first]---------------------------------------------------- Date: Fri, 25 May 90 23:00 +0200 (NBI, Copenhagen) From: ALLAN ENGELHARDT <ENGELHARDT%nbivax.nbi.dk@CORNELLC.cit.cornell.edu> To: TCP-IP@NIC.DDN.mil Subject: Will *somebody* PLEASE remove me from this list.
Copenhagen, 25-MAY-1990
HELP. I did an UNSUB * (NETWIDE and it worked on every other list than
this. Will somebody please delete me from this list?
Allan Engelhardt
Internet: ENGELHARDT@nbivax.nbi.dk (nbivax.nbi.dk=129.142.100.3)
HEPnet: NBIVAX::ENGELHARDT (NBIVAX=21.106=22105)
-----------[000312][next][prev][last][first]---------------------------------------------------- Date: Sat, 26 May 90 10:11:49 -0400 From: Craig Partridge <craig@NNSC.NSF.NET> To: tcp-ip@nic.ddn.mil Subject: re: SIGCOMM '90 Information
Hi folks:
Despite proof reading twice, my little note had an error.
The SIGCOMM '90 e-mail address and phone number may NOT work until
June 1st (In other words, after June 1 you can expect them to be up and
running).
My apologies to the University of Pennsylvania people who are working
hard to set up the phone line and e-mail address.
Craig
-----------[000313][next][prev][last][first]---------------------------------------------------- Date: Sat, 26 May 90 10:12:52 EST From: bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu> To: tcp-ip@nic.ddn.mil Subject: Re: Netwatch ???
And while we are on the subject, I have heard there is a version of
NETWATCH that uses Packet Drivers that meet the FTP Assoc. Spec.
Does anyone have any idea where I might find an EXE for this vesion??
bill
bill gunshannon
702WFG@SCRVMSYS.BITNET
-----------[000314][next][prev][last][first]---------------------------------------------------- Date: 26 May 90 14:11:49 GMT From: craig@NNSC.NSF.NET (Craig Partridge) To: comp.protocols.tcp-ip Subject: re: SIGCOMM '90 Information
Hi folks:
Despite proof reading twice, my little note had an error.
The SIGCOMM '90 e-mail address and phone number may NOT work until
June 1st (In other words, after June 1 you can expect them to be up and
running).
My apologies to the University of Pennsylvania people who are working
hard to set up the phone line and e-mail address.
Craig
-----------[000315][next][prev][last][first]---------------------------------------------------- Date: 26 May 90 15:12:52 GMT From: 702WFG@SCRVMSYS.BITNET (bill gunshannon) To: comp.protocols.tcp-ip Subject: Re: Netwatch ???
And while we are on the subject, I have heard there is a version of
NETWATCH that uses Packet Drivers that meet the FTP Assoc. Spec.
Does anyone have any idea where I might find an EXE for this vesion??
bill
bill gunshannon
702WFG@SCRVMSYS.BITNET
-----------[000316][next][prev][last][first]---------------------------------------------------- Date: Sun, 27 May 90 00:23:12 -0400 From: "Martin Lee Schoffstall" <schoff@psi.com> To: ameristar!rick@sbcs.sunysb.edu (Rick Spanbauer) Cc: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
Rick, Someday I hope to meet you..... 5 years of private and public email and our paths haven't crossed yet, just swords.... :-) The plight of many small technical businesses is that we just cannot justify spending $30K+ for access into the Internet for the occasional FTP/smtp transfer. Were access fees brought inline with the level of service offered, eg $2K-5K/yr for dialup SLIP is reasonable, surely PSI and other regionals would see their business pick up substantially. Aside for PSI/PSINet not being a regional, (think about th N word), I think most of us have recognized an entry level market. There must be half a dozen providers who have something that looks like ~$10K with dedicated facilities. One of the issues on the dialup front is that a major cost is hidden, the message units that all businesses have to pay. In many LATA's a 4wire unconditioned analog circuit costs $100/mo, the cross over point where the message units are more expensive is probably not too many of the 3 hour periods described below. Somehow dialup Internet access and SMTP don't go hand and hand in my mind, my estimate is that your going to have keep a connection open for about 3 hours every day to have some probablity of synchronizing with all the SMTP agents pushing mail out of their queues for the site. Realistically you'll be running uucp/tcp to a site like UUPSI who is MX'ing for your domain. Note that it isn't small business alone that has a problem with the high connection costs to the Internet. Ameristar sells IP/TCP network products and every once in a while I ask some of our larger customers ($20M & up) why they are not on the Internet. The answer is usually that the perceived value of the connection is not in line with the yearly access fee. In such cases, a low cost dialup SLIP service would go a long way in giving people a chance to experiment with Internet access to evaluate its usefullness to their organization. Dialup SLIP is also a safe way for the regionals to toy with their price/volume curve without having to add infastructure (ie additional or higher capacity links) at the outset of the experiment. At least you could talk them into getting a good quality UUCP connection so they can do email. I'm frightened by the lack of participation of many vertical industries in communicating with their customers, suppliers, except through phones. (Have you ever entered voice mail grid lock, where neither party ever gets through due to synchronization problems, and the use of voice mail systems as filtering devices. Someday the only time you'll ever get an answer is by dialing 1-900.lovenow). One other suggestion I have is that the regionals ought to survey potential customers about the sort of connectivity and services they would purchase as a function of cost. Good starting sample data sets might be the lists of technical companies that local business organizations or government maintains, or even UUCP maps. This has been done, but your sampling focus is a good suggestion. Please do make an announcement of any new services PSI introduces. I for one would like to hear what PSI is doing to moderate access fees without having to ping your sales organization every few months. Maybe Kent England will radio you in reports from "The Front", rumored to have been named "Operation Fortress Beantown", BarHarborAirlines has guaranteed that they can airlift as many cisco's as they will need to sustain the battle. :-) Marty
-----------[000317][next][prev][last][first]---------------------------------------------------- Date: 26 May 90 18:59:41 GMT From: swrinde!cs.utexas.edu!mailrus!b-tech!zeeff@ucsd.edu (Jon Zeeff) To: tcp-ip@nic.ddn.mil Subject: Re: A SUSPICIOUS SECURE GATEWAY
>not secure enough today. Blame complacent vendors, blame lazy >administrators, blame careless users -- it doesn't matter much, >since the empirical fact remains: a very significant fraction While it may not matter when deciding to use a "secure" gateway, the cause matters very much when you go to fix the problems (which I hope you are still doing). It doesn't inspire confidence - even AT&T can't make a Unix they trust. >Incidentally, I say ``mostly'' because there's an important class of >device -- dial-out modems -- that is not capable of security today, and >is not likely to be in the forseeable future. Finding a dialer pool on There are these $100 toll restrictors (a little box) that help quite a bit. -- Jon Zeeff (NIC handle JZ) zeeff@b-tech.ann-arbor.mi.us
-----------[000318][next][prev][last][first]---------------------------------------------------- Date: 26 May 90 19:47:13 GMT From: netnews.upenn.edu!pcpond.cis.upenn.edu!farber@rutgers.edu (David J. Farber) To: tcp-ip@nic.ddn.mil Subject: SIGCOMM90 email is operational since 25 May
The email query address is available as of this time. Send any requests etc to: sigcomm90@cis.upenn.edu Dave David Farber; Prof. of CIS and EE, U of Penn, Philadelphia, PA 19104-6389 Tele: 215-898-9508(off); 215-274-8292 (home); FAX: 215-274-8293; Cellular: 302-740- 1198 "The fundamental principle of science, the definition almost, is this: the sole test of the validity of any idea is experiment." -- R. P. Feynman
-----------[000319][next][prev][last][first]---------------------------------------------------- Date: 27 May 90 00:41:49 GMT From: smb@ulysses.att.com (Steven Bellovin) To: comp.protocols.tcp-ip Subject: Re: A SUSPICIOUS SECURE GATEWAY
In article <46F%_++@b-tech.uucp>, zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: > It doesn't inspire confidence - even AT&T can't make a Unix they trust. AT&T is not a homogeneous place -- for example, we have a lot of Sun workstations. (Remember the joint development deal, if nothing else.) We have an OEM agreement with Pyramid. We buy other machines for other reasons. And the best system in the world can be totally hosed by an incompetent administrator. And even on 6386s or 3B2s with good administrators, sometimes a machine *must* run back releases of the software, with known bugs not yet fixed. > >Incidentally, I say ``mostly'' because there's an important class of > >device -- dial-out modems -- that is not capable of security today, and > >is not likely to be in the forseeable future. Finding a dialer pool on > > There are these $100 toll restrictors (a little box) that help quite a bit. No, they don't. Why should we prevent ourselves from making long-distance calls? We have dial-out modems because we need them and use them, and often -- generally? -- not for local use. To give an important case in point, there's an AT&T office in Tokyo; we call it often via uucp.
-----------[000320][next][prev][last][first]---------------------------------------------------- Date: 27 May 90 01:25:50 GMT From: attcan!utgpu!utzoo!henry@uunet.uu.net (Henry Spencer) To: tcp-ip@nic.ddn.mil Subject: Re: A SUSPICIOUS SECURE GATEWAY
In article <46F%_++@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >It doesn't inspire confidence - even AT&T can't make a Unix they trust. More precisely, they can't make a Unix that they can trust when it is administered by incompetents. Nobody else can make such a system either. -- As a user I'll take speed over| Henry Spencer at U of Toronto Zoology features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
-----------[000321][next][prev][last][first]---------------------------------------------------- Date: 27 May 90 04:03:30 GMT From: usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali!rpi!image.soe.clarkson.edu!news@ucsd.edu (Russ Nelson) To: tcp-ip@nic.ddn.mil Subject: Re: Netwatch ???
In article <9005262224.AA16033@ucbvax.Berkeley.EDU> 702WFG@SCRVMSYS.BITNET (bill gunshannon) writes: And while we are on the subject, I have heard there is a version of NETWATCH that uses Packet Drivers that meet the FTP Assoc. Spec. Does anyone have any idea where I might find an EXE for this vesion?? FTP to sun.soe.clarkson.edu:/pub/ka9q/pcippkt.arc. Or call (315)268-6667, log in, change to the TCP/IP area, and download pcippkt.arc -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667 Violence never solves problems, it just changes them into more subtle problems
-----------[000322][next][prev][last][first]---------------------------------------------------- Date: Sun May 27 20:52:36 1990 From: robjohn@ocdis01.af.mil (Robert Johnson (CDC Contractor);CDC;) To: tcp-ip@nic.ddn.mil Subject: toll restrictors
There are software products on the market which allow the system administrator to automate and control connections to other systems. We use a product that automates phone, network and direct connections, and restricts access to specified users or groups of users. The user picks the system they want from a menu, and the software handles the connection automatically. A few seconds later, they see the banner and login prompt of the system they wanted to use. There are two drawbacks. The administrator must set up access to new systems as needed, and must turn off other avenues such as tip, cu, and telnet. The product we use replaces telnet, but does not yet replace ftp. We have limited ftp access to a specified group of users, and we log their usage. At our site, the advantages far outweigh the disadvantages - simpler for the user, less user training/support, and a full audit trail of outbound connections made from our system. As background info, we have nearly 1500 users, about 550 people use the system each day, and several dozen use our system as a gateway to others. We plan on doubling this usage within a year. We have a Class A Internet address, a Class C Ethernet connection, outbound modems, and connection to several other systems through a base-wide broadband LAN. The product we use allows us to provide better service to our user community, reduce our training and support burden, and provide accountability and auditability. Bob Johnson, System Administrator Tinker Air Force Base, Oklahoma
-----------[000323][next][prev][last][first]---------------------------------------------------- Date: 27 May 90 21:01:15 GMT From: mailrus!b-tech!zeeff@tut.cis.ohio-state.edu (Jon Zeeff) To: tcp-ip@nic.ddn.mil Subject: Re: A SUSPICIOUS SECURE GATEWAY
>> There are these $100 toll restrictors (a little box) that help quite a bit. > >No, they don't. Why should we prevent ourselves from making long-distance >calls? We have dial-out modems because we need them and use them, and They don't prevent long distance calls - you just have to program in the numbers that are allowed. Even so, I will admit that that aren't suitable for all situations. -- Jon Zeeff (NIC handle JZ) zeeff@b-tech.ann-arbor.mi.us
-----------[000324][next][prev][last][first]---------------------------------------------------- Date: 27 May 90 21:58:07 GMT From: bbn.com!wbe@apple.com (Winston Edmond) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
In article <90121@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes: >UUNET plans to offer access to any Internet site from any Compuserve Dialup >in the continental US. >All access will require an individual login/password for accountability and >authorization to use the Internet will be verified before the account is >established. >We plan to charge $5 per connect hour (in increments of 1 minute). Would UUNET be a CompuServe service provider, charging a $5/hr. surcharge, or are you talking about using the CompuServe network and somehow bypassing logging in to CompuServe itself? Is the individual login/password the usual CompuServe user number and password, or a UUNET login? >We could start tomorrow if I could figure out how to bill for it. >Its not worth sending out invoices for only $5. There are a number of CompuServe service providers that collect surcharges directly from CompuServe -- the user gets a single bill, and CompuServe's billing system keeps track of the surcharges in case the user has questions about his bill. This allows a service provider to charge small amounts, like the $.02 stock quote charge, or the $.90 car profile charge, and still be able to make money -- you don't have to bill the customer yourself. -WBE
-----------[000325][next][prev][last][first]---------------------------------------------------- Date: Mon, 28 May 90 10:37:16 -0400 (EDT) From: Michael Ginsberg <mg32+@andrew.cmu.edu> To: tcp-ip@nic.ddn.mil, Outbound News <outnews+netnews.comp.protocols.tcp-ip@andrew.cmu.edu>, Outbound News <outnews+netnews.comp.unix.questions@andrew.cmu.edu>, Outbound News <outnews+netnews.comp.unix.wizards@andrew.cmu.edu> Subject: SLIP - Serial Line Internet Protocol
I would like to be able to transfer data from a networked unix machine to a portable computer which cannot be put on the network. Both machines do have serial ports, and it was suggested that I look into SLIP, the Serial Line Internet Protocol. However, I have been very unsucccessful in tracking down information on how I can go about using SLIP. Can someone please tell mewhat I must do to use SLIP? Is there public domain software out there? Is it part of the system already? Thanks alot for any useful information/pointers. Please respond via email as I don't read this board. If there is any/enough response, I will post a summary. --Michael Ginsberg, i386 Mach Group, School of Computer Science Carnegie Mellon University, Pittsburgh, Pennsylvania, USA --------------------------------------------------------------------------- ARPA: mg32+@andrew.cmu.edu |Electrocution, n: BITNET: mg32@cmccvb | Burning at the stake with UUCP: ...!harvard!andrew.cmu.edu!mg32+ | all the modern improvements. --------------------------------------------------------------------------- Sex is not the answer. Sex is the question. Yes is the answer.
-----------[000326][next][prev][last][first]---------------------------------------------------- Date: 28 May 90 17:43:47 GMT From: bronze.ucs.indiana.edu!mckimg@iuvax.cs.indiana.edu (geoffrey mckim) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
>In article <NELSON.90May21230840@image.clarkson.edu>, >nelson@sun.soe.clarkson.edu (Russ Nelson) says: >>That's too bad, because when I've gone travelling in the past, I've called >>the local university, asked for their terminal server's phone number, and >>telnetted back to Clarkson to check my mail. It's a shame that that kind >>of service has to go away... > >Actually, you can still check your mail, but for the price of a toll call >back to your own terminal server. > >Maybe this is the price we have to pay for added security? > >/Pete >-- >Peter M. Weiss I don't mean to flame but... Obviously one of the primary benefits of something like the Internet is fast, efficient connections around the world. Sure, if we wanted to, we could all just have cheapo 1200 baud modems on our desks and dial up whatever machine we want to directly. But that sort of defeats the purpose of a high-speed network. In other words, the easiest way to improve security is to simply disconnect all the machines on the network from all others. But then we've got no network eh? I'm afraid that knee-jerk reactions have long been the hallmark of those in charge of computer security. I realize that it will always be difficult to balance functionality and security, but I also hope that people realize that the reason for the network's existence is FUNCTIONALITY. I for one will certainly work to fight the elimination of dial-up terminal servers connected to the internet. Let's make our hosts more secure and not intentionally cripple the internet. Geoffrey McKim *** Standard disclaimers apply *** Indiana University
-----------[000327][next][prev][last][first]---------------------------------------------------- Date: Tue, 29 May 90 11:54:56 -0700 From: chris@salt.acc.com (Chris VandenBerg) To: tcp-ip@nic.ddn.mil Subject: HPLaserJet Ethernet board?
Good morning all, I was asked a question this morning about whether you could hook an HPLaserJet printer directly onto an Ethernet without using a terminal server port. I seem to remember hearing that someomne made a card that fit into the expansion slot that had an Ethernet connector and TCP/IP software righton it. Does anyone else know anything about this type of setup or am I sufferingillusions of connectivity? (:*) Thanks in advance, Chris VandenBerg ACC (chris@salt.acc.com) 805-963-9431
-----------[000328][next][prev][last][first]---------------------------------------------------- Date: Tue, 29 May 90 10:05:26 -0400 From: Craig Partridge <craig@NNSC.NSF.NET> To: tcp-ip@nic.ddn.mil Subject: SIGCOMM '90 Advance Program [Text]
SIGCOMM '90 - General Information
SIGCOMM is the annual conference of the ACM Special Interest Group
in Computer Communication. This year's conference will be held at
the University City Sheraton Hotel in Philadelphia, Pennsylvania,
September 24-27th. This program contains the advance schedule for
the conference, registration information, and hotel information.
If you have any questions, feel free to contact the SIGCOMM '90
conference committee, at 215-898-0016 or sigcomm90@cis.upenn.edu.
SIGCOMM Conference Committee
General Chair: Prof. David J. Farber (Univ. Pennsylvania)
Program Chair: Phil Karn (Bellcore)
Tutorial Chair: Prof. Magda El-Zarki (Univ. Pennsylvania)
Local Arrangements: Dan Finnigan (Univ. Pennsylvania)
Publicity Chair: Craig Partridge (Bolt Beranek and Newman)
Advisors: Prof. Larry Landweber (Univ. Wisconsin), Prof. Chris
Edmondson-Yurkanan (Univ. Texas), Dr. Vint Cerf (CNRI)
SIGCOMM Program Committee
Phil Karn (Bellcore), Ernst Biersack (Bellcore), Vint Cerf (CNRI),
Doug Comer (Purdue), Jon Crowcroft (Univ. College London), Gary
Delp (IBM), John Demco (CDNnet), Magda El-Zarki (Univ. Pennsyl-
vania), Zygmunt Haas (AT&T), Raj Jain (DEC), Larry Landweber (Univ.
Wisconsin), Craig Partridge (BBN), Guru Parulkar (Washington Univ.
St. Louis), Larry L. Peterson (Univ. Arizona), Steve Pink (SICS),
Marshall T. Rose (PSI), Harry Rudin (IBM), Jonathan M. Smith (Univ.
Pennsylvania)
Tutorials: September 24th [9 AM to 5 PM]
Tutorial #1: Protocols for High-Speed Networks
Instructors: Harry Rudin and Van Jacobson
Part A: High-Performance, Transport-Level Protocols (Rudin)
Made possible by progress in fiber-optic and VLSI technologies,
networks offering increasing transmission capacity at decreasing
error rates are becoming available. New applications would benefit
from this bandwidth but software protocol processing rates have not
kept up with available raw transmission speed. The presentation is
a comparative survey of techniques used at the transport layer in
eight representative protocols, most of which were designed to
improve the protocol processing rate. The protocols are the
relevant portions of the APPN, Datakit, Delta-t, NETBLT, OSI/TP4,
TCP, VMTP, and XTP architectures. The main functions covered are:
connection management, acknowledgements, flow control, and error
handling.
Part B: Efficient TCP Implementation (Jacobson)
Network protocol processing time has long been viewed as THE deter-
miner of perceived network performance. For at least one well
known suite, the TCP and IP Internet protocols, recent measurement
has shown this view to be false: The protocol *implementation*
affects perceived performance, as does the way in which the network
interface hardware interacts with the entire software/hardware sys-
tem it is a part of. But there is no inherent performance limit
in the TCP/IP protocols themselves. In fact, a Unix TCP/IP imple-
mentation has been constructed that runs at a essentially the
information-theoretic minimum time for the the problem being
solved.
This tutorial will describe an efficient TCP/IP implementation in
agonizing detail. It will describe where time goes in a typical
implementation and what can be done in the protocol and system
software to reclaim that time. It will discuss how the network
interface hardware affects processing time and what hardware archi-
tectures lead to cheap, efficient processing.
Familiarity with the TCP and IP protocols will be assumed.
Although the implementation described will be based on a real, pro-
duction, Berkeley Unix TCP/IP, no Unix kernel expertise will be
assumed, only familiarity with operating system issues and imple-
mentations.
Harry Rudin received the B.E. and D.Eng. degrees from Yale Univer-
sity, where he also taught until 1964. He worked at Bell Telephone
Laboratories in the area of data communications until 1968. Since
then he has been doing research in computer communications systems
at the Zurich Research Laboratory, IBM Research Division, in
Rueschlikon, Switzerland. His interests are high-speed protocols
and the use of formal description techniques for protocol develop-
ment. He is a Fellow of the IEEE, Chairman of IFIP WG6.1, gives a
graduate course on computer networks at the Swiss Federal Institute
of Technology in Zurich, and is a senior editor of Computer Net-
works and ISDN Systems magazine.
Van Jacobson received a MS in Physics and a BS in Mathematics from
the University of Arizona in 1972. Since then he has been a Staff
Scientist in the Real Time Systems Group of Lawrence Berkeley
Laboratory, developing high performance, distributed, data acquisi-
tion and control systems. Since 1984 his research has concentrated
on network protocols and the dynamics of large-scale networks.
Since 1985 he has served as an adjunct lecturer in Computer Science
at the University of California, Berkeley, and Stanford University.
Tutorial #2: Object-Oriented Network Management and Control
Instructors: Aurel Lazar and Mark W. Sylor
The objective of this tutorial is to present a structured approach
to problems arising in network management and control. Object-
oriented modeling of communication networks. Knowledge representa-
tion, entity/relationship models for data representation. Models
of network management and control. Managed and managing objects.
Performance management. Computational models for data abstraction.
The OSI Information Model and the Management Information Base.
Knowledge based monitoring and control. Modeling examples of real
networks. DECnet - EMA Entities, TCP/IP - MIB definitions. Exam-
ples will also be drawn from AT&T's UNMA and IBM's Netview. Sup-
porting capabilities and architectures: testing, down/line loading,
event logging, time service and naming.
Aurel A. Lazar is a Professor of Electrical Engineering and Direc-
tor of the Telecommunication Networks Laboratory at Columbia
University. He received the Dipl.-Ing. degree in communications
engineering (Nachrichtentechnik) from the Technische Hochschule
Darmstadt, Darmstadt, Federal Republic of Germany, in 1976, and the
Ph.D. degree in information sciences and systems from Princeton
University, Princeton, NJ, in 1980. During the 80's he was
involved in the design and implementation of integrated networks
supporting video, voice and data services. Most recently, he was
the chief architect of MAGNET II a metropolitan area network based
on Asynchronous Time Sharing. Currently he is leading the design
and implementation of a real-time traffic control architecture for
integrated networks.
Mark W. Sylor is a member of the Enterprise Management Architecture
group at Digital Equipment Corperation in Littleton, MA, where he
works on the EMA Entity Model, and the Phase V DECnet Network
Management Specification. He has been a member of the ISO and ANSI
committees working on OSI System Management, and was formerly the
ANSI T5.4 ad-hoc group leader on the Structure of Management Infor-
mation (SMI). Mark has been involved with the design and implemen-
tation of many of Digital's Network Management systems, in particu-
lar the NMCC/DECnet Monitor, where he was the principle designer
and development supervisor. Mark earned a B.A. degreee at S.U.N.Y.
at Geneseo in 1971 and an M.S. degree at the University of Notre
Dame in 1975, both in Mathematics.
Technical Program: September 25-27th
MONDAY, September 24th
RECEPTION [7 PM to 9 PM]
TUESDAY, September 25th
Keynote Address: SIGCOMM AWARD Winner [9:00 - 9:30]
Session #1: Congestion Control [10:00 - 12:00] Chair: Jon Smith
Random Drop Congestion Control, A. Mankin (Mitre)
A Stop-and-Go Queueing Framework for Congestion Management, S.J.
Golestani (Bellcore)
Virtual Clock: a new traffic control algorithm for packet switch-
ing networks, L. Zhang (Xerox PARC)
Dynamic Adaptive Windows for High Speed Data Networks: Theory and
Simulations, D. Mitra (AT&T Bell Laboratories)
Lunch [12:00 - 1:30]
Session #2: Applications and Distributed Systems [1:30 - 3:00]
Chair: Larry Peterson
Efficient At-Most-Once Messages Based on Synchronized Clocks, L.
Shrira, J. Wroclawski, B. Liskov (MIT)
Uniform Access to Internet Directory Services, D. Comer (Purdue
Univ.) and R.E. Droms (Bucknell Univ.)
A Data Processing Performance Model for the OSI Application Layer
Protocols, T. Shiroshita (NTT)
Session #3: MANs and WANs [3:30 - 5:00] Chair: Jon Crowcroft
A Simple Multiple Access Protocol for Metropolitan Area Networks,
J.O. Limb (Hewlett-Packard)
The BBN Dual Bus Protocol: Performance in a Wide Area Network, W.
Edmond, K. Seo, M. Leib, C. Topolcic (BBN)
Machnet: A Simple Access Protocol for High Speed or Long Haul Com-
munications, P. Jacquet, P. Muhlethaler (INRIA)
SIGCOMM Business Meeting [5:15 - 6:00]
WEDNESDAY, September 26th
Session #4: Multimedia Protocols and Protocol Testing [9:00 -
10:30] Chair: Guru Parulkar
Mechanisms for Integrated Voice and Data Conferencing, C. Ziegler,
G. Weiss (Brooklyn College)
Link Access Blocking in Very Large Multi-Media Networks, J.-F.
Labourdette, G. Hart (Columbia Univ.)
Protocol Conformance Test Generation Using Multiple UIO Sequences
with Overlapping, B. Yang, H. Ural (University of Ottawa)
Session #5: High-Speed Switching [11:00 - 12:30] Chair: Zygmunt
Haas
Gauss: a simple high performance switch architecture for ATM,
R.J.F. de Vries (PTT Research, Netherlands)
Protocol Implementation on the Nectar Communication Processor,
E.C. Cooper, P.A. Steenkiste, R.D. Sansom, B.D. Zill (Carnegie
Mellon Univ.)
Pulsar: Non-blocking Packet Switching with Shift-Register Rings,
G.J. Murakami, R.H. Campbell, M. Faiman (Univ. of Illinois)
Lunch [12:30 - 2:00]
Session #6: Routing and Flow Control [2:00 - 3:30] Chair: Raj Jain
A Theoretical Analysis of Feedback Flow Control, S. Shenker (Xerox
PARC)
Shortest Path First with Emergency Exits, Z. Wang, J. Crowcroft
(University College London)
Shortest Paths and Loop-Free Routing in Dynamic Networks, B. Awer-
buch (MIT)
Session #7: Gigabit Protocols [4:00 - 5:30] Chair: Craig Partridge
Transport Protocol Processing at GBPS rates, N. Jain, M. Schwartz
(Columbia University)
Architectural Considerations for a New Generation of Protocols,
D.D. Clark, D.L. Tennenhouse (MIT)
Multiplexing Issues in Transport Protocol Design, D.C. Feldmeier
(Bellcore)
Banquet [6:30 - 8:00]
THURSDAY, September 27th
Session #8: Routing [9:00 - 10:30] Chair: Steve Pink
Avoiding Name Resolution Loops and Duplications in Group Communi-
cations, L. Liang, G.W. Neufeld, S.T. Chanson (Univ. of British
Columbia)
Design of Inter-Administrative Domain Routing Protocols L.
Breslau, D. Estrin (USC)
Topology Distribution Cost vs. Efficient Routing In Large Net-
works, A. Bar-Noy, M. Gopal (IBM Watson)
Session #9: LAN Issues [11:00 - 12:30] Chair: John Demco
Efficient Use of Workstations for Passive Monitoring of Local Area
Networks, J. Mogul (DEC)
Performance Analysis of FDDI Token Ring Networks: Effect of Param-
eters and Guidelines for Setting TTRT, R. Jain (DEC)
Frame Content Independent Stripping for Token Rings, H. Yang, K.
K. Ramakrishnan (DEC)
Lunch [12:30 - 2:00]
Session #10: Protocol Design [2:00 - 3:30] Chair: Ernst Biersack
Fast Connection Establishment in High Speed Networks, I. Cidon, I.
Gopal, A. Segall (IBM Watson and Technion)
Reliable Broadband Communications Using a Burst Erasure Correcting
Code, A.J. McAuley (Bellcore)
An Inclusive Session Protocol for Distributed Applications, V.S.
Sunderam (Emory Univ.)
SIGCOMM '90 wishes to thank our host site, the University of
Pennsylvania for its considerable support in putting on this
conference.
SIGCOMM '90 would also like to acknowledge the generous support of
the following corporations: Advance Computer Communications,
Bellcore, FTP Software, Digital Equipment Corporation's Network
Systems Lab, and Interop Inc.
Mark your calendars for SIGCOMM '91, September 3-6, 1991 at ETH Zurich,
in Zurich, Switzerland.
*******************************************************************************
SIGCOMM '90 Advance Registration Form
mail to: SIGCOMM '90, attn: Dan Finnigan, University of Pennsylvania,
329 Moore Bldg, 200 South 33rd St, Philadelphia, PA 19104, USA
NAME ____________________________________
AFFILIATION _____________________________
ADDRESS _________________________________
____________________________________
____________________________________
Phone: __________________________________
E-mail: _________________________________
SIGCOMM/ACM Member # ____________________
Tutorials: before 9/1 after 9/1
Members $175 $230
Non-Members $230 $280
Students $100 $100
[student tutorial rates on space available basis]
Tutorial #1 ___ or Tutorial #2 ___ $_____
Conference: before 9/1 after 9/1
Members $230 $280
Non-Members $280 $330
Students $100 $100
$_____
Total $_____
dietary restrictions ___ kosher ___ vegetarian
*******************************************************************************
SIGCOMM '90 Hotel Registration Form
mail to: University City Sheraton Hotel, 36th and Chestnut St,
Philadelphia, PA 19104 (215-387-8000)
Registration must be received 8/23 to ensure these rates
NAME ____________________________________ ___ Single $80 + tax
AFFILIATION _____________________________ ___ Double $90 + tax
ADDRESS _________________________________ Univ. of Pennsylvania CIS rate
____________________________________
____________________________________
Phone: __________________________________
Arrival Date: ___________________________
Departure Date: _________________________
to guarantee arrival after 4PM please provide credit card information
Card Name & Number _______________________________ Expires _______
Name on Card _________________________________ Signature _________________
-----------[000329][next][prev][last][first]---------------------------------------------------- Date: Tue, 29 May 90 09:15:25 EDT From: stev@vax.ftp.com To: swrinde!zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!dan@ucsd.edu (Dan Schlitt) Cc: tcp-ip@nic.ddn.mil Subject: Re: What is the IAB?
>I have my doubts about Roy's interpretation too. However one should >also note the anonymous critique of the governance of the Internet >that was published in Goodfellow's newsletter. Participation in the >IAB and the IETF can't be read as 100% support. >Dan Schlitt Manager, Science Division Computer Facility well, i am not on the IAB. i am an active participant in the IETF though. i am currently the PPP working group chair. while i do not support the actions of the organizations 100%, i do believe the process is the best one out there, and i also believe that one person, with well thought out arguements, and careful planning, can make a diffrence. i can also say that the IAB/IETF/IESG has never tried to shut me up, they has asked me to talk about something later, but always at reasonable times. they also have called on me many times at the IETF meetings to let me say my piece. it may not have always been in their best interest, and i am sure there have been times they wished i didnt open my mouth, but they do seem to put up with people with disenting opinions if these people are willing to work in the system to fix the problems they see. could be worse, i am told that the ISO people have to submit their statements in written form. they would get to miss my booming voice wafting out over the lecture hall. . . . :) stev knowles IETF PPP working group chair ftp software stev@ftp.com "Maybe they are all Bozo's on this bus, but they are *our* clowns, not someone elses!"
-----------[000330][next][prev][last][first]---------------------------------------------------- Date: Tue, 29 May 90 13:04:25 PDT From: estrin@usc.edu (Deborah Estrin) To: paul%dy4%cognos%sce%mitel.uucp@uunet.uu.net Cc: tcp-ip@nic.ddn.mil Subject: Re: Request for protocol overhead references
I believe that Dr. Liba Svobodova et. al. had a paper in Computer Networks and ISDN Systems (late '89 or early '90) with performance measures for TCP and TP4...
-----------[000331][next][prev][last][first]---------------------------------------------------- Date: 29 May 90 13:22:55 GMT From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) To: comp.protocols.tcp-ip Subject: Re: Dial up access to Internet facilities
>I think that "fast connections around the world" does not mean that we
>have to allow anyone with a modem and terminal to telnet/rlogin into any
>host at will on the Internet. Doesn't compute.
dont agree - we have just been checking how fast you can clock a line
based on the copper used for UK phones, and managed 200kbps without
much trouble - i.e. multiple basic rate ISDNs (without even needing
much tcp header compression) will make a X and NFS to 20 million UK homes
feasible before the year 2000 - if anyone thought building such a
wacky service ... if they do, security on my VCR is gonna be
ultra-tight (i dont want some hacker making me miss my favourite
show)...
jon {p.s. this is not entirely serious:-}
-----------[000332][next][prev][last][first]---------------------------------------------------- Date: 29 May 90 14:05:26 GMT From: craig@NNSC.NSF.NET (Craig Partridge) To: comp.protocols.tcp-ip Subject: SIGCOMM '90 Advance Program [Text]
SIGCOMM '90 - General Information
SIGCOMM is the annual conference of the ACM Special Interest Group
in Computer Communication. This year's conference will be held at
the University City Sheraton Hotel in Philadelphia, Pennsylvania,
September 24-27th. This program contains the advance schedule for
the conference, registration information, and hotel information.
If you have any questions, feel free to contact the SIGCOMM '90
conference committee, at 215-898-0016 or sigcomm90@cis.upenn.edu.
SIGCOMM Conference Committee
General Chair: Prof. David J. Farber (Univ. Pennsylvania)
Program Chair: Phil Karn (Bellcore)
Tutorial Chair: Prof. Magda El-Zarki (Univ. Pennsylvania)
Local Arrangements: Dan Finnigan (Univ. Pennsylvania)
Publicity Chair: Craig Partridge (Bolt Beranek and Newman)
Advisors: Prof. Larry Landweber (Univ. Wisconsin), Prof. Chris
Edmondson-Yurkanan (Univ. Texas), Dr. Vint Cerf (CNRI)
SIGCOMM Program Committee
Phil Karn (Bellcore), Ernst Biersack (Bellcore), Vint Cerf (CNRI),
Doug Comer (Purdue), Jon Crowcroft (Univ. College London), Gary
Delp (IBM), John Demco (CDNnet), Magda El-Zarki (Univ. Pennsyl-
vania), Zygmunt Haas (AT&T), Raj Jain (DEC), Larry Landweber (Univ.
Wisconsin), Craig Partridge (BBN), Guru Parulkar (Washington Univ.
St. Louis), Larry L. Peterson (Univ. Arizona), Steve Pink (SICS),
Marshall T. Rose (PSI), Harry Rudin (IBM), Jonathan M. Smith (Univ.
Pennsylvania)
Tutorials: September 24th [9 AM to 5 PM]
Tutorial #1: Protocols for High-Speed Networks
Instructors: Harry Rudin and Van Jacobson
Part A: High-Performance, Transport-Level Protocols (Rudin)
Made possible by progress in fiber-optic and VLSI technologies,
networks offering increasing transmission capacity at decreasing
error rates are becoming available. New applications would benefit
from this bandwidth but software protocol processing rates have not
kept up with available raw transmission speed. The presentation is
a comparative survey of techniques used at the transport layer in
eight representative protocols, most of which were designed to
improve the protocol processing rate. The protocols are the
relevant portions of the APPN, Datakit, Delta-t, NETBLT, OSI/TP4,
TCP, VMTP, and XTP architectures. The main functions covered are:
connection management, acknowledgements, flow control, and error
handling.
Part B: Efficient TCP Implementation (Jacobson)
Network protocol processing time has long been viewed as THE deter-
miner of perceived network performance. For at least one well
known suite, the TCP and IP Internet protocols, recent measurement
has shown this view to be false: The protocol *implementation*
affects perceived performance, as does the way in which the network
interface hardware interacts with the entire software/hardware sys-
tem it is a part of. But there is no inherent performance limit
in the TCP/IP protocols themselves. In fact, a Unix TCP/IP imple-
mentation has been constructed that runs at a essentially the
information-theoretic minimum time for the the problem being
solved.
This tutorial will describe an efficient TCP/IP implementation in
agonizing detail. It will describe where time goes in a typical
implementation and what can be done in the protocol and system
software to reclaim that time. It will discuss how the network
interface hardware affects processing time and what hardware archi-
tectures lead to cheap, efficient processing.
Familiarity with the TCP and IP protocols will be assumed.
Although the implementation described will be based on a real, pro-
duction, Berkeley Unix TCP/IP, no Unix kernel expertise will be
assumed, only familiarity with operating system issues and imple-
mentations.
Harry Rudin received the B.E. and D.Eng. degrees from Yale Univer-
sity, where he also taught until 1964. He worked at Bell Telephone
Laboratories in the area of data communications until 1968. Since
then he has been doing research in computer communications systems
at the Zurich Research Laboratory, IBM Research Division, in
Rueschlikon, Switzerland. His interests are high-speed protocols
and the use of formal description techniques for protocol develop-
ment. He is a Fellow of the IEEE, Chairman of IFIP WG6.1, gives a
graduate course on computer networks at the Swiss Federal Institute
of Technology in Zurich, and is a senior editor of Computer Net-
works and ISDN Systems magazine.
Van Jacobson received a MS in Physics and a BS in Mathematics from
the University of Arizona in 1972. Since then he has been a Staff
Scientist in the Real Time Systems Group of Lawrence Berkeley
Laboratory, developing high performance, distributed, data acquisi-
tion and control systems. Since 1984 his research has concentrated
on network protocols and the dynamics of large-scale networks.
Since 1985 he has served as an adjunct lecturer in Computer Science
at the University of California, Berkeley, and Stanford University.
Tutorial #2: Object-Oriented Network Management and Control
Instructors: Aurel Lazar and Mark W. Sylor
The objective of this tutorial is to present a structured approach
to problems arising in network management and control. Object-
oriented modeling of communication networks. Knowledge representa-
tion, entity/relationship models for data representation. Models
of network management and control. Managed and managing objects.
Performance management. Computational models for data abstraction.
The OSI Information Model and the Management Information Base.
Knowledge based monitoring and control. Modeling examples of real
networks. DECnet - EMA Entities, TCP/IP - MIB definitions. Exam-
ples will also be drawn from AT&T's UNMA and IBM's Netview. Sup-
porting capabilities and architectures: testing, down/line loading,
event logging, time service and naming.
Aurel A. Lazar is a Professor of Electrical Engineering and Direc-
tor of the Telecommunication Networks Laboratory at Columbia
University. He received the Dipl.-Ing. degree in communications
engineering (Nachrichtentechnik) from the Technische Hochschule
Darmstadt, Darmstadt, Federal Republic of Germany, in 1976, and the
Ph.D. degree in information sciences and systems from Princeton
University, Princeton, NJ, in 1980. During the 80's he was
involved in the design and implementation of integrated networks
supporting video, voice and data services. Most recently, he was
the chief architect of MAGNET II a metropolitan area network based
on Asynchronous Time Sharing. Currently he is leading the design
and implementation of a real-time traffic control architecture for
integrated networks.
Mark W. Sylor is a member of the Enterprise Management Architecture
group at Digital Equipment Corperation in Littleton, MA, where he
works on the EMA Entity Model, and the Phase V DECnet Network
Management Specification. He has been a member of the ISO and ANSI
committees working on OSI System Management, and was formerly the
ANSI T5.4 ad-hoc group leader on the Structure of Management Infor-
mation (SMI). Mark has been involved with the design and implemen-
tation of many of Digital's Network Management systems, in particu-
lar the NMCC/DECnet Monitor, where he was the principle designer
and development supervisor. Mark earned a B.A. degreee at S.U.N.Y.
at Geneseo in 1971 and an M.S. degree at the University of Notre
Dame in 1975, both in Mathematics.
Technical Program: September 25-27th
MONDAY, September 24th
RECEPTION [7 PM to 9 PM]
TUESDAY, September 25th
Keynote Address: SIGCOMM AWARD Winner [9:00 - 9:30]
Session #1: Congestion Control [10:00 - 12:00] Chair: Jon Smith
Random Drop Congestion Control, A. Mankin (Mitre)
A Stop-and-Go Queueing Framework for Congestion Management, S.J.
Golestani (Bellcore)
Virtual Clock: a new traffic control algorithm for packet switch-
ing networks, L. Zhang (Xerox PARC)
Dynamic Adaptive Windows for High Speed Data Networks: Theory and
Simulations, D. Mitra (AT&T Bell Laboratories)
Lunch [12:00 - 1:30]
Session #2: Applications and Distributed Systems [1:30 - 3:00]
Chair: Larry Peterson
Efficient At-Most-Once Messages Based on Synchronized Clocks, L.
Shrira, J. Wroclawski, B. Liskov (MIT)
Uniform Access to Internet Directory Services, D. Comer (Purdue
Univ.) and R.E. Droms (Bucknell Univ.)
A Data Processing Performance Model for the OSI Application Layer
Protocols, T. Shiroshita (NTT)
Session #3: MANs and WANs [3:30 - 5:00] Chair: Jon Crowcroft
A Simple Multiple Access Protocol for Metropolitan Area Networks,
J.O. Limb (Hewlett-Packard)
The BBN Dual Bus Protocol: Performance in a Wide Area Network, W.
Edmond, K. Seo, M. Leib, C. Topolcic (BBN)
Machnet: A Simple Access Protocol for High Speed or Long Haul Com-
munications, P. Jacquet, P. Muhlethaler (INRIA)
SIGCOMM Business Meeting [5:15 - 6:00]
WEDNESDAY, September 26th
Session #4: Multimedia Protocols and Protocol Testing [9:00 -
10:30] Chair: Guru Parulkar
Mechanisms for Integrated Voice and Data Conferencing, C. Ziegler,
G. Weiss (Brooklyn College)
Link Access Blocking in Very Large Multi-Media Networks, J.-F.
Labourdette, G. Hart (Columbia Univ.)
Protocol Conformance Test Generation Using Multiple UIO Sequences
with Overlapping, B. Yang, H. Ural (University of Ottawa)
Session #5: High-Speed Switching [11:00 - 12:30] Chair: Zygmunt
Haas
Gauss: a simple high performance switch architecture for ATM,
R.J.F. de Vries (PTT Research, Netherlands)
Protocol Implementation on the Nectar Communication Processor,
E.C. Cooper, P.A. Steenkiste, R.D. Sansom, B.D. Zill (Carnegie
Mellon Univ.)
Pulsar: Non-blocking Packet Switching with Shift-Register Rings,
G.J. Murakami, R.H. Campbell, M. Faiman (Univ. of Illinois)
Lunch [12:30 - 2:00]
Session #6: Routing and Flow Control [2:00 - 3:30] Chair: Raj Jain
A Theoretical Analysis of Feedback Flow Control, S. Shenker (Xerox
PARC)
Shortest Path First with Emergency Exits, Z. Wang, J. Crowcroft
(University College London)
Shortest Paths and Loop-Free Routing in Dynamic Networks, B. Awer-
buch (MIT)
Session #7: Gigabit Protocols [4:00 - 5:30] Chair: Craig Partridge
Transport Protocol Processing at GBPS rates, N. Jain, M. Schwartz
(Columbia University)
Architectural Considerations for a New Generation of Protocols,
D.D. Clark, D.L. Tennenhouse (MIT)
Multiplexing Issues in Transport Protocol Design, D.C. Feldmeier
(Bellcore)
Banquet [6:30 - 8:00]
THURSDAY, September 27th
Session #8: Routing [9:00 - 10:30] Chair: Steve Pink
Avoiding Name Resolution Loops and Duplications in Group Communi-
cations, L. Liang, G.W. Neufeld, S.T. Chanson (Univ. of British
Columbia)
Design of Inter-Administrative Domain Routing Protocols L.
Breslau, D. Estrin (USC)
Topology Distribution Cost vs. Efficient Routing In Large Net-
works, A. Bar-Noy, M. Gopal (IBM Watson)
Session #9: LAN Issues [11:00 - 12:30] Chair: John Demco
Efficient Use of Workstations for Passive Monitoring of Local Area
Networks, J. Mogul (DEC)
Performance Analysis of FDDI Token Ring Networks: Effect of Param-
eters and Guidelines for Setting TTRT, R. Jain (DEC)
Frame Content Independent Stripping for Token Rings, H. Yang, K.
K. Ramakrishnan (DEC)
Lunch [12:30 - 2:00]
Session #10: Protocol Design [2:00 - 3:30] Chair: Ernst Biersack
Fast Connection Establishment in High Speed Networks, I. Cidon, I.
Gopal, A. Segall (IBM Watson and Technion)
Reliable Broadband Communications Using a Burst Erasure Correcting
Code, A.J. McAuley (Bellcore)
An Inclusive Session Protocol for Distributed Applications, V.S.
Sunderam (Emory Univ.)
SIGCOMM '90 wishes to thank our host site, the University of
Pennsylvania for its considerable support in putting on this
conference.
SIGCOMM '90 would also like to acknowledge the generous support of
the following corporations: Advance Computer Communications,
Bellcore, FTP Software, Digital Equipment Corporation's Network
Systems Lab, and Interop Inc.
Mark your calendars for SIGCOMM '91, September 3-6, 1991 at ETH Zurich,
in Zurich, Switzerland.
*******************************************************************************
SIGCOMM '90 Advance Registration Form
mail to: SIGCOMM '90, attn: Dan Finnigan, University of Pennsylvania,
329 Moore Bldg, 200 South 33rd St, Philadelphia, PA 19104, USA
NAME ____________________________________
AFFILIATION _____________________________
ADDRESS _________________________________
____________________________________
____________________________________
Phone: __________________________________
E-mail: _________________________________
SIGCOMM/ACM Member # ____________________
Tutorials: before 9/1 after 9/1
Members $175 $230
Non-Members $230 $280
Students $100 $100
[student tutorial rates on space available basis]
Tutorial #1 ___ or Tutorial #2 ___ $_____
Conference: before 9/1 after 9/1
Members $230 $280
Non-Members $280 $330
Students $100 $100
$_____
Total $_____
dietary restrictions ___ kosher ___ vegetarian
*******************************************************************************
SIGCOMM '90 Hotel Registration Form
mail to: University City Sheraton Hotel, 36th and Chestnut St,
Philadelphia, PA 19104 (215-387-8000)
Registration must be received 8/23 to ensure these rates
NAME ____________________________________ ___ Single $80 + tax
AFFILIATION _____________________________ ___ Double $90 + tax
ADDRESS _________________________________ Univ. of Pennsylvania CIS rate
____________________________________
____________________________________
Phone: __________________________________
Arrival Date: ___________________________
Departure Date: _________________________
to guarantee arrival after 4PM please provide credit card information
Card Name & Number _______________________________ Expires _______
Name on Card _________________________________ Signature _________________
-----------[000333][next][prev][last][first]---------------------------------------------------- Date: 29 May 90 14:31:45 GMT From: mcsun!cernvax!chx400!hslrswi!aut!ruef@uunet.uu.net (Bernhard Ruef) To: tcp-ip@nic.ddn.mil Subject: NFS for NCR TOWER
Well, the subject line says it all: Does anybody know about the availability of NFS for a NCR TOWER 32/[46]X0 running System V.3 (Release 3.00.01 in NCR speak) ? Yes, I do know that this question has been asked before in comp.sys.ncr but I haven't yet seen a satisfactory, i.e. definite answer :-) Cheers -Beni -- Bernhard D. Ruef Ascom Autelca AG CH-3073 Guemligen/Switzerland E-mail: ruef@aut.UUCP FAX: +41 31 527 745 Voice mail: +41 31 529 602 "UNIX is the answer - what was the question ?"
-----------[000334][next][prev][last][first]---------------------------------------------------- Date: 29 May 90 15:01:47 GMT From: usc!jarthur!elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!fedeva!bill@ucsd.edu (Bill Daniels) To: tcp-ip@nic.ddn.mil Subject: Query - Ethernet collisions
We recently acquired an Exelan LANalyzer. During our first uses of it,
we noticed that about 40% of the packets on one ethernet segment (which
is remotely bridged to another) show up as "Collision detected in preamble".
This segment is not busy necessarily when this happens. The actual number of
collisions reported seems fairly constant even as traffic picks up. On
a very quiet net (~ 2 packets / sec.) I see about 20 errors over ~ 30 secs.
When the segment is a little more active (~ 1000 packets / sec.) the error
rate is just about the same.
I have tried disconnecting the devices that the errors are associated with
but the collisions just move to the packets associated with other devices.
Any clues?
bd
--
bill daniels
federal express, memphis, tn
{hplabs!csun,mit-eddie!premise}!fedeva!bill
-----------[000335][next][prev][last][first]---------------------------------------------------- Date: Tue, 29 May 90 22:34:26 -0400 From: "Martin Lee Schoffstall" <schoff@psi.com> To: ka9q.bellcore.com!karn@bellcore.com (Phil Karn) Cc: tcp-ip@nic.ddn.mil Subject: Re: What is the IAB?
Phil, Your almost correct.... > Perhaps the most important thing about the IAB is its "fly before buy" > policy. For a protocol to reach internet standard status, it must first be > implemented and widely used, and there must be a substantial body of > perational experience. CMOT was elevated to DIS without the above. Marty
-----------[000336][next][prev][last][first]---------------------------------------------------- Date: 29 May 90 15:58:46 GMT From: cica!ssw@iuvax.cs.indiana.edu (Steve Wallace) To: tcp-ip@nic.ddn.mil Subject: When is an ethernet full?
When is an ethernet full? We have a campus backbone composed of a chipcom 10 Mbs ethernet over broadband and a UB 5 Mbs ethernet over broadband (buffered repeaters). The UB and chipcom networks are bridged to form one logical networks. According to our Network General sniffer, we constantly maintain about 10-15 percent utilization or (300 - 1000 packets per second). How much more traffic can this network support before performance falls off measurably? Any ideas? Thanks, Steven Wallace Indiana University wallaces@ucs.indiana.edu
-----------[000337][next][prev][last][first]---------------------------------------------------- Date: Tue, 29 May 90 14:22:55 +0100 From: Jon Crowcroft <J.Crowcroft@Cs.Ucl.AC.UK> To: "Martin L. Schoffstall" <schoff@uu.psi.com> Cc: uupsi!iuvax.cs.indiana.edu!bronze.ucs.indiana.edu!mckimg@uu.psi.com, tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
>I think that "fast connections around the world" does not mean that we
>have to allow anyone with a modem and terminal to telnet/rlogin into any
>host at will on the Internet. Doesn't compute.
dont agree - we have just been checking how fast you can clock a line
based on the copper used for UK phones, and managed 200kbps without
much trouble - i.e. multiple basic rate ISDNs (without even needing
much tcp header compression) will make a X and NFS to 20 million UK homes
feasible before the year 2000 - if anyone thought building such a
wacky service ... if they do, security on my VCR is gonna be
ultra-tight (i dont want some hacker making me miss my favourite
show)...
jon {p.s. this is not entirely serious:-}
-----------[000338][next][prev][last][first]---------------------------------------------------- Date: 29 May 90 16:53:31 GMT From: oliveb!orc!bbn.com!craig@apple.com (Craig Partridge) To: tcp-ip@nic.ddn.mil Subject: Re: When is an ethernet full?
> When is an ethernet full? .... > According to our Network General sniffer, > we constantly maintain about 10-15 percent utilization or (300 - 1000 > packets per second). How much more traffic can this network support > before performance falls off measurably? Any ideas? The best place I know of to start answering this question is Boggs, Mogul and Kent's article in Proc. of SIGCOMM '88 pp. 222-233. The gist of that article is that you can drive the Ethernet all the way to its rated capacity assuming you are careful in the way you lay out your network, and all your systems have good Ethernet hardware. In practice of course, many of the systems won't have good Ethernet hardware (for example, Jacobson's talk at SIGCOMM '88 indicated he'd found an Ethernet chipset that could only go about 6 Mbits/sec). So you need to find some people out there with some good practical experience about when some of their systems start breaking down, to figure out when your network will die due to poor hardware/software. Craig
-----------[000339][next][prev][last][first]---------------------------------------------------- Date: 29 May 90 17:24:02 GMT From: usc!cs.utexas.edu!uwm.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu (Kent England) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
In article <9005270423.AA19852@psi.com>, schoff@PSI.COM ("Martin Lee
Schoffstall") writes:
...
> At least you could talk them into getting a good quality UUCP connection
> so they can do email. I'm frightened by the lack of participation of
> many vertical industries in communicating with their customers, suppliers,
> except through phones. (Have you ever entered voice mail grid lock, where
> neither party ever gets through due to synchronization problems, and
> the use of voice mail systems as filtering devices. Someday the only
> time you'll ever get an answer is by dialing 1-900.lovenow).
>
...
> Please do make an announcement of any new services PSI introduces. I
> for one would like to hear what PSI is doing to moderate access fees
> without having to ping your sales organization every few months.
>
> Maybe Kent England will radio you in reports from "The Front", rumored
> to have been named "Operation Fortress Beantown", BarHarborAirlines has
> guaranteed that they can airlift as many cisco's as they will need to
> sustain the battle. :-)
>
> Marty
Glad to! [BTW, it's not "Operation Fortress Beantown". Only
folks from elsewhere and local sportswriters call Boston Beantown. :-]
We got the three inches of water pumped out of the main bunker
and the dehumidifier is fixed now, so it's bearable down here. I have
a pretty good view of the harbor and Logan airport. PSI has been airlifting
in dial-up servers, but we shot down most of them, since the visibility
was pretty poor and PSI didn't pay for good IFR gear. Better luck next
time, Marty. :-)
Seriously, though, I share Marty's concern about a lack of interest
in commercial enterprises in supporting business using modern internetworks.
It would seem obvious to me what the benefits are, so perhaps we just need
to be more aggressive in touting the capabilities of the technology we know
and love. Marty will see to that, as far as he can, since his livelihood
depends on it. I see a definite interest on the part of commercial
organizations
wishing to join the research and education (R&E) Internet, but I see much
less interest from them in joining a purely commercial internet service-
they don't seem to understand who they would be able to talk to on a purely
commercial internet. Come to think of it, neither do I. But certainly
there is a lot of interest from commercial outfits in becoming a part of
our R&E Internet and in exploiting that technology to talk to the existing
base of constituents.
NEARnet has had a phenomenal response from commercial organizations
joining NEARnet and the Internet. There are a lot of research labs in the
Boston area, and they are very eager to be a part of the R&E Internet.
Perhaps it is just that they are able to move more quickly allocating budget
to the NEARnet connection, and are therefore able to connect more quickly
than some of our colleagues in the academic field in New England. We'll see.
Like the PSI folk, NEARnet is aware of an untapped potential base
for lower cost access to the Internet, from both the commercial organizations
and from academic organizations. As might be expected, this is due mostly
to a scale pyramid= there are simply more small sites than large.
NEARnet is committed to broadening its base of support to include
smaller sites at lower cost. We are chafing against technical issues in
being able to offer high quality service at lower costs, since we balance
hardware and people costs, and people costs are not really that bandwidth
sensitive. We also have strict standards on quality of service, and we
do not wish to compromise these standards in offering less costly access,
since we know that later on our customers would regret the compromise as
much as we. Then there is the issue of just what is part-time access;
is it terminal dial-ups, SLIP/PPP (host or router?), uucp, what? We have
to keep in mind what services we provide and we have to make sure that
our clients understand what they can and can't do with new service offerings.
All in all, though we have been able to keep costs quite
reasonable, so far as we can tell in comparing costs with our neighbors.
As far as keeping up with new service offerings, you should
keep an eye on comp.newprod. PSI always posts announcements of new service
offerings there, and NEARnet will as well.
Must get back to work; we have air raid drills scheduled for 2pm
this afternoon and my anti-aircraft gun needs greasing. I'll radio in
future reports so long as my lines to Princeton aren't cut.
--Kent England, Boston University
-----------[000340][next][prev][last][first]---------------------------------------------------- Date: 29 May 90 18:41:46 GMT From: ka9q.bellcore.com!karn@bellcore.com (Phil Karn) To: tcp-ip@nic.ddn.mil Subject: Re: What is the IAB?
I have to agree with Stev Knowles. The IAB/IETF is the *only* standards body that actually seems to work. I've never seen an important technical decision made by anyone other than the members of the working group in charge of a given topic, and anyone with a technical interest is free to join and contribute. Perhaps the most important thing about the IAB is its "fly before buy" policy. For a protocol to reach internet standard status, it must first be implemented and widely used, and there must be a substantial body of operational experience. If only other standards organizations could follow this principle the world would be a far better place. Phil
-----------[000341][next][prev][last][first]---------------------------------------------------- Date: 29 May 90 18:42:25 GMT From: usc!cs.utexas.edu!uwm.edu!dogie.macc.wisc.edu!vms.macc.wisc.edu@ucsd.edu (Rusty Smith, MACC) To: tcp-ip@nic.ddn.mil Subject: Re: When is an ethernet full?
In article <1141@cica.cica.indiana.edu>, ssw@cica.cica.indiana.edu (Steve Wallace) writes... > >When is an ethernet full? We have a campus backbone composed of a >chipcom 10 Mbs ethernet over broadband and a UB 5 Mbs ethernet over >broadband (buffered repeaters). The UB and chipcom networks are bridged >to form one logical networks. According to our Network General sniffer, >we constantly maintain about 10-15 percent utilization or (300 - 1000 >packets per second). How much more traffic can this network support >before performance falls off measurably? Any ideas? > We have a similar setup here. There are about 50 Chipcom's connected to our broadband backbone. All but 3 are coupled to DEC Lanbridges to keep local traffic local. We have had similar 1 minute averages and peaks of 3-4 times as much. As far as we can tell everyone is satisfied with the performance with these numbers. We have had other performance problems not caused by traffic volume. Rusty Smith Internet: rsmith@vms.macc.wisc.edu MACC Data Communications Bitnet: rsmith@wiscmacc (608) 263-6307 Univ. of Wisconsin @ Madison
-----------[000342][next][prev][last][first]---------------------------------------------------- Date: 29 May 90 19:11:25 GMT From: shelby!portia.stanford.edu!jessica.stanford.edu!morgan@eos.arc.nasa.gov (RL "Bob" Morgan) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
> Somehow dialup Internet access and SMTP don't go hand and hand in my > mind, my estimate is that your going to have keep a connection open > for about 3 hours every day to have some probablity of synchronizing > with all the SMTP agents pushing mail out of their queues for the > site. Realistically you'll be running uucp/tcp to a site like UUPSI > who is MX'ing for your domain. Indeed, SMTP's assumption that everybody's connected all the time doesn't work well with occasionally-connected hosts. It would seem that the time is ripe for some sort of extension to SMTP to do receiver-initiated transfers to meet this need. Of course you'll still need the MXing host to hold your mail for you. Presumably getting away from uucp is one of the points of all this. Note that POP doesn't make it for the small-business customer. I want my address to be "morgan@mybusiness.com" not "morgan@barrnet.net". I also want to manage my own accounts on my own multi-user system, not ask my provider every time I need a new one. - RL "Bob" Morgan Networking Systems Stanford
-----------[000343][next][prev][last][first]---------------------------------------------------- Date: 29 May 90 21:28:21 GMT From: aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu (Charles Hedrick) To: tcp-ip@nic.ddn.mil Subject: Re: When is an ethernet full?
>When is an ethernet full? We have a campus backbone composed of a >chipcom 10 Mbs ethernet over broadband and a UB 5 Mbs ethernet over >broadband (buffered repeaters). The UB and chipcom networks are bridged >to form one logical networks. According to our Network General sniffer, >we constantly maintain about 10-15 percent utilization or (300 - 1000 >packets per second). How much more traffic can this network support >before performance falls off measurably? Any ideas? I'd like to see you get data with a bit more time resolution. It's a bit unusual for networks to run at 10-15% all the time, day and night. More typically, there's a long-term variation over the course of a day, with more traffic during the day than night, and short-term variation as people boot machines, transfer big files, or do other things that cause a short-term demand for bandwidth. If you're running at 10% 24 hours a day, this suggests either a very odd mix of users and applications, or that most of your bandwidth is going to broadcast packets produced by rwhod or things of that nature. I have heard of networks with a constant broadcast load of that sort. In that case, replacing some or all of your bridges with routers might be more useful than trying to increase the bandwidth. In general I'd expect a peak to average ratio of about 10 to 1. That is, if you are averaging 10% usage, you are probably using 100% during brief periods. So you're about at capacity. If your 10% is made up mostly of a continuous background of broadcast packets, this might not be the case. But if you've really got that much broadcast traffic, you've got other problems. Like your hosts are all spending significant CPU dealing with it. If your 10% represents the maxima of your peaks, rather than a true average, then you're probably in good shape and still have some room to grow.
-----------[000344][next][prev][last][first]---------------------------------------------------- Date: 29 May 90 21:45:00 GMT From: TAYBENGH@NUSDISCS.BITNET To: comp.protocols.tcp-ip Subject: Public domain TCP/IP Software for VAX?
Hi, Netlander!
Does anybody know whether there is any public domain software
TCP/IP for VAX? Please reply to me directly, I will summarize if there
is enough interest.
p/s: please inlcude the anonymous FTP site if there is
- Beng Hang Tay (email: taybengh@nusdiscs)
Dept. of Info. Sys. and Comp. Sc.
NATIONAL UNIVERSITY OF SINGAPORE
-----------[000345][next][prev][last][first]---------------------------------------------------- Date: 29 May 90 22:12:16 GMT From: barmar@think.com (Barry Margolin) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
In article <1990May29.191125.9800@portia.Stanford.EDU> morgan@jessica.stanford.edu (RL "Bob" Morgan) writes:
>Indeed, SMTP's assumption that everybody's connected all the time
>doesn't work well with occasionally-connected hosts. It would seem
>that the time is ripe for some sort of extension to SMTP to do
>receiver-initiated transfers to meet this need.
No extension is needed: see the TURN command. However, most SMTP
implementation don't enable this command for security reasons. To make it
secure you need a way of authenticating the calling SMTP. One possibility
would be to allow it only in cases where the name given in the HELO command
corresponds to the address being used by the transport layer; however, not
all transport layers make this available (what do you do if SMTP is being
done over dialup lines?).
>Note that POP doesn't make it for the small-business customer. I want
>my address to be "morgan@mybusiness.com" not "morgan@barrnet.net". I
>also want to manage my own accounts on my own multi-user system, not
>ask my provider every time I need a new one.
MX records solve the first problem.
However, I'm not sure why you need any of this. What's wrong with the
MX'ing host periodically trying to connect to the occasionally-connected
hosts? Much of the time it will just time out, but when it succeeds it can
forward all the accumulated mail. This is the default behavior, so no
extensions are necessary.
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar
-----------[000346][next][prev][last][first]---------------------------------------------------- Date: 29 May 90 23:36:15 GMT From: netcom!hinton@apple.com (Greg Hinton) To: tcp-ip@nic.ddn.mil Subject: What is VMTP?
I've read bits & pieces about something called VMTP. From what I've seen, it appears to be a reliable counterpart of UDP. Can someone explain in more depth exactly what VMTP is and/or provide easily available references? Are there any implementations under UNIX? Thanks. -- Greg Hinton DOMAIN: hinton@netcom.uucp UUCP: uunet!apple!netcom!hinton
-----------[000347][next][prev][last][first]---------------------------------------------------- Date: 30 May 90 00:10:09 GMT From: intercon!news@uunet.uu.net (Amanda Walker) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
In article <57875@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes:
> I see a definite interest on the part of commercial organizations
> wishing to join the research and education (R&E) Internet, but I see much
> less interest from them in joining a purely commercial internet service-
> they don't seem to understand who they would be able to talk to on a purely
> commercial internet. Come to think of it, neither do I.
In our case, at least, one of the reasons that a connection to what you call
the R&E Internet would/will be so valuable is that a lot of the people that
we want to communicate with are already there. I suspect that the companies
that are currently most interested in the Internet fall into one of two
categories:
1. Companies whose customer base is largely already on the Internet.
TCP/IP vendors, supercomputer vendors, and so on. We fall into this
category, for example.
2. Companies that want to reap the benefits of wide-area networking
without having to develop their own infrastructure. Some bicoastal
computer corporations fall into this category, for example.
As the number of companies in category 2 increase, the perceived value
of a purely commercial internet will also increase. At some point, also,
commercial service providers may increase its value by allowing it to
mediate services that the R&E Internet cannot or by policy will not support.
--
Amanda Walker
--
This posting is cursed. As you read it you will be confuset by ther
printeb wertz. Yer intelijen will vabni ..... XRT! XRT!
-----------[000348][next][prev][last][first]---------------------------------------------------- Date: 30 May 90 01:59:32 GMT From: zaphod.mps.ohio-state.edu!mips!cmic!garvey@tut.cis.ohio-state.edu (Joe Garvey) To: tcp-ip@nic.ddn.mil Subject: tcp/ip services <--> decnet connectivity, help wanted
I need to connect a DEC (decnet) system to an HP unix system. My objective
is to make the remote login, and file transfer services work.
I can make the required physical connections of the LAN's involved...
However, I assume a direct connection won't work. I need some kind of
protocol tranlator in the middle.
For a number of reasons, each machine must think it's working in its native
services (decnet or arpa-berkeley).
Can I use a PC and some netware?
Does someone make a translator?
Can I directly connect the two networks, and put some software package on
my HP (9000/370)? It's out of the question to add software to the
DEC machines (PDP/RSTS) ;-(.
I've got some PC's and terminal servers using the arpa-berkeley tools, what
about them?
Am I crazy? :-)
E-mail response preferred. ... normal stuff about summarizing ...
Thanx.
--
Joe Garvey UUCP: {apple,backbone}!versatc!mips!cmic!garvey
California Microwave Internet: garvey%cmic@mips.com
990 Almanor Ave HP Desk: garvey (cmic@mips.com) /hp1900/ux
Sunnyvale, Ca, 94086 800-831-3104 (outside CA)
408-720-6439 (let it ring) 800-824-7814 (inside CA)
-----------[000349][next][prev][last][first]---------------------------------------------------- From: lefty@obelix.twg.com To: tcp-ip@nic.ddn.mil Cc: Subject: Re: Query - Ethernet collisions
In <98@fedeva.UUCP>, Bill Daniels <usc!jarthur!elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!fedeva!bill@ucsd.edu> writes: > We recently acquired an Exelan LANalyzer. During our first uses of it, > we noticed that about 40% of the packets on one ethernet segment (which > is remotely bridged to another) show up as "Collision detected in preamble". > This segment is not busy necessarily when this happens. The actual number > of collisions reported seems fairly constant even as traffic picks up. On > a very quiet net (~ 2 packets / sec.) I see about 20 errors over ~ 30 secs. > When the segment is a little more active (~ 1000 packets / sec.) the error > rate is just about the same. > > I have tried disconnecting the devices that the errors are associated with > but the collisions just move to the packets associated with other devices. > > Any clues? My immediate guess would be a marginal terminator somewhere... |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>| | David N. Schlesinger || "When I have nothing to say, | | The Wollongong Group || my lips are sealed; | | Internet: Lefty@twg.com || say something once, | | POTS: 415/962-7219 || why say it again?" -- David Byrne | |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|
-----------[000350][next][prev][last][first]---------------------------------------------------- Date: 30 May 90 02:25:24 GMT From: zaphod.mps.ohio-state.edu!samsung!sol.ctr.columbia.edu!cica!ssw@tut.cis.ohio-state.edu (Steve Wallace) To: tcp-ip@nic.ddn.mil Subject: Re: When is an ethernet full?
A little more info.
We have about 45 IP subnets all behind cisco routers. We
route appletalk phase I, DECnet, and bridge IPX. Between the
hours of 9am to 5pm we see a pretty steady 10 - 15 percent load.
Sometimes this drops to 2 percent but only for very brief
periods.
Steven Wallace
wallaces@ucs.indiana.edu
-----------[000351][next][prev][last][first]---------------------------------------------------- Date: 30 May 90 02:35:49 GMT From: sumax!ctsx!dms@beaver.cs.washington.edu (Dave Stanhope) To: tcp-ip@nic.ddn.mil Subject: Internet access
Is it possible (assuming correct usage) to get access to the Internet
via the commercial X25 networks (Telenet and/or Tymnet). The connection
would use TCP/IP over X25. Any comments would be appreciated!
Reply to:
..!uwbeaver!sumax!ctsx!dms
Thanks, Dave S.
-----------[000352][next][prev][last][first]---------------------------------------------------- Date: Tue, 29 May 90 13:45 H From: <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU> To: tcp-ip@sri-nic.arpa Subject: Public domain TCP/IP Software for VAX?
Hi, Netlander!
Does anybody know whether there is any public domain software
TCP/IP for VAX? Please reply to me directly, I will summarize if there
is enough interest.
p/s: please inlcude the anonymous FTP site if there is
- Beng Hang Tay (email: taybengh@nusdiscs)
Dept. of Info. Sys. and Comp. Sc.
NATIONAL UNIVERSITY OF SINGAPORE
-----------[000353][next][prev][last][first]---------------------------------------------------- Date: Wed, 30 May 90 10:13:29 PDT From: postel@venera.isi.edu To: netcom!hinton@apple.com Cc: tcp-ip@nic.ddn.mil Subject: Re: What is VMTP?
Hi. See RFC-1045 and the papers by Cheriton in various places (e.g., Sigcomm conference proceedings). --jon.
-----------[000354][next][prev][last][first]---------------------------------------------------- Date: 30 May 90 07:57:00 EDT From: "VAXB::DBURKE" <dburke%vaxb.decnet@nusc-npt.navy.mil> To: "tcp-ip" <tcp-ip@nic.ddn.mil> Subject: LanTastic NOS and TCP/IP
Date sent: 30-MAY-1990 07:56:35 Hi, Does anyone know/have/hear of a gateway from Lantastic to TCP/IP? Dave ================================================================================ Dave Burke || ___________ Aquidneck Data Corporation || // || || 170 Enterprise Center || // || || Middletown, R.I. 02840 || // || || dburke%vaxb.decnet@nusc-npt.navy.mil || //-----|| || (401) 847-7260 || // || || (This line left intentionally blank) || // ||_____|| ================================================================================
-----------[000355][next][prev][last][first]---------------------------------------------------- Date: 30 May 90 05:29:38 GMT From: nsc!pyramid!athertn!joshua@decwrl.dec.com (Flame Bait) To: tcp-ip@nic.ddn.mil Subject: Looking For Commercial RPC Protocols
About a year and a half ago I wrote a paper comparing RPC protocols from
Sun, Apollo, and Netwise. I'm now updating and expanding this paper,
since there have been many changes to all of those RPC systems over the
last year and a half.
I'm looking for other commercial RPC protocols to compare. If you know of
a such a product, please send me the companies address, phone, and email.
By commercial, I mean widely available and supported. I may include non
commercial RPCs if they are especially interesting or important.
RPC = Remote Procedure Call
Joshua Levy
-------- Quote: "If you haven't ported your program, it's not
Addresses: a portable program. No exceptions."
joshua@atherton.com
{decwrl|sun|coherent}!athertn!joshua work:(408)734-9822 home:(415)968-3718
-----------[000356][next][prev][last][first]---------------------------------------------------- Date: 30 May 90 07:16:22 GMT From: eru!luth!sunic!mcsun!ub4b!syteke!jim@BLOOM-BEACON.MIT.EDU (Jim Sanchez) To: tcp-ip@nic.ddn.mil Subject: Re: When is an ethernet full?
One thing you want to be SURE and remember is that the ethernet on
broadband stuff has a significant distance limitation. If your campus
cable system is a as large as I suspect, then the 10broad36 channel is
probably working more as csma than csma/cd and the effective channel
capacity is ~2 Mb not 10 Mb. That is why we use 802.4 for backbone
applications it also uses much less bandwidth. The UB stuff is also
just CSMA (if my memory serves me). In both cases, the effective
channel capacity is approximately 35% of the data rate. If you
calculate the maximum number of packets on an 802.3 channel it is
about 13,000 and scale accordingly I don't think you are overloaded
based on your numbers. However, this is a tricky thing to find out.
--
Jim Sanchez | jim@syteke.be (PREFERRED)
| OR {sun,hplabs}!sytek!syteke!jim
Hughes LAN Systems | OR uunet!mcsun!ub4b!syteke!jim
Brussels
--
Jim Sanchez | jim@syteke.be (PREFERRED)
| OR {sun,hplabs}!sytek!syteke!jim
Hughes LAN Systems | OR uunet!mcsun!ub4b!syteke!jim
Brussels
-----------[000357][next][prev][last][first]---------------------------------------------------- Date: 30 May 1990 17:12-PDT From: Steve Deering <deering@pescadero.stanford.edu> To: netcom!hinton@apple.com (Greg Hinton) Cc: tcp-ip@nic.ddn.mil Subject: Re: What is VMTP?
> I've read bits & pieces about something called VMTP. From what I've seen, > it appears to be a reliable counterpart of UDP. > Can someone explain in more depth exactly what VMTP is and/or provide > easily available references? VMTP is a transport-layer protocol that provides a reliable request/response or RPC style of service, rather than the reliable stream service of TCP or the unreliable datagram service of UDP. As others have pointed out, it has been described in several papers by David Cheriton of Stanford; the protocol specification can be found in RFC-1045. > Are there any implementations under UNIX? Yes, there is an implementation for 4.3BSD and derivitives (SunOS, Ultrix) that may be obtained by anonymous FTP from host gregorio.stanford.edu, in the vmtp-ip directory. The software is free but covered by a Stanford license agreement, which can be found in the file vmtp.LICENSE in that directory. Steve Deering
-----------[000358][next][prev][last][first]---------------------------------------------------- Date: Wed, 30 May 90 17:48:40 -0400 From: "Martin Lee Schoffstall" <schoff@psi.com> To: jbloom@uhasun.hartford.edu Cc: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
Jon, I think the counter argument is that if it doesn't work reliably/well especially in the beginning then people won't rely on it to provide communications for their everyday needs. If they don't use it everyday then it is luxury suitable for axing at the appropriate belt-tightening time. Marty --------------- > Speaking as one who is trying to figure out how to convince management that > $10k/yr would be well spent, I would be willing to accept service limitations > for a lower-cost net access. If the service truly is as useful to the > organization as I believe it would be, the demonstration of that usefulness > might just break loose the dollars for a higher quality ($10K) connection. So > providing low-cost, restricted service connections may well have the effect > of enhancing the number of sites getting full-service connections eventually.
-----------[000359][next][prev][last][first]---------------------------------------------------- Date: Wed, 30 May 90 15:34:19 EDT From: stev@vax.ftp.com To: "Martin Lee Schoffstall" <schoff@psi.com> Cc: tcp-ip@nic.ddn.mil, ka9q.bellcore.com!karn@bellcore.com (Phil Karn) Subject: Re: What is the IAB?
>CMOT was elevated to DIS without the above. >Marty after the abuse they got, i *doubt* that will ever happen again. i never said it was perfect. they *do* do some stupid things. but, then again, so do i . . . . . .
-----------[000360][next][prev][last][first]----------------------------------------------------
Date: 30 May 90 11:57:00 GMT
From: dburke%vaxb.decnet@NUSC-NPT.NAVY.MIL ("VAXB::DBURKE")
To: comp.protocols.tcp-ip
Subject: LanTastic NOS and TCP/IPDate sent: 30-MAY-1990 07:56:35 Hi, Does anyone know/have/hear of a gateway from Lantastic to TCP/IP? Dave ================================================================================ Dave Burke || ___________ Aquidneck Data Corporation || // || || 170 Enterprise Center || // || || Middletown, R.I. 02840 || // || || dburke%vaxb.decnet@nusc-npt.navy.mil || //-----|| || (401) 847-7260 || // || || (This line left intentionally blank) || // ||_____|| ================================================================================
-----------[000361][next][prev][last][first]---------------------------------------------------- Date: 30 May 90 12:20:44 GMT From: mailrus!bbn.com!craig@uunet.uu.net (Craig Partridge) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
In article <1990May29.191125.9800@portia.Stanford.EDU> morgan@jessica.stanford.edu (RL "Bob" Morgan) writes: > >Indeed, SMTP's assumption that everybody's connected all the time >doesn't work well with occasionally-connected hosts. It would seem >that the time is ripe for some sort of extension to SMTP to do >receiver-initiated transfers to meet this need. Of course you'll >still need the MXing host to hold your mail for you. Presumably >getting away from uucp is one of the points of all this. CSNET did this some time ago with MMDF2b. Some of the dial-up sites run a script every night which brings up the dial-up line, and then opens a connection to a port on relay.cs.net and tells it to start delivering mail to the site. The application at that connection starts up the appropriate MMDF channel (mmdf can have multiple SMTP delivery channels, where a channel typically has messages destined for a particular site), which delivers the mail to the site. [Note there's no security problem here -- anyone can start up the channel, but the channel will only deliver to the proper remote system(s)] Craig
-----------[000362][next][prev][last][first]---------------------------------------------------- Date: Wed, 30 May 90 19:03:58 -0400 From: schoff@psi.com (Marty Schoffstall) To: ietf@venera.isi.edu, tcp-ip@nic.ddn.mil Subject: new mailing list of Commercial Internetworking Issues
A new mailing list has been created: comint@psi.com (to post, and respond) comint-request@psi.com (to be added) To discuss commercial aspects of participation in the Internet. Marty
-----------[000363][next][prev][last][first]---------------------------------------------------- Date: 30 May 90 13:20:11 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!uhasun!jbloom@ucsd.edu (Jon Bloom) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
In article <57875@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes: > > NEARnet is committed to broadening its base of support to include > smaller sites at lower cost. We are chafing against technical issues in > being able to offer high quality service at lower costs, since we balance > hardware and people costs, and people costs are not really that bandwidth > sensitive. We also have strict standards on quality of service, and we > do not wish to compromise these standards in offering less costly access, > since we know that later on our customers would regret the compromise as > much as we. Then there is the issue of just what is part-time access; > is it terminal dial-ups, SLIP/PPP (host or router?), uucp, what? We have > to keep in mind what services we provide and we have to make sure that > our clients understand what they can and can't do with new service offerings. > Speaking as one who is trying to figure out how to convince management that $10k/yr would be well spent, I would be willing to accept service limitations for a lower-cost net access. If the service truly is as useful to the organization as I believe it would be, the demonstration of that usefulness might just break loose the dollars for a higher quality ($10K) connection. So providing low-cost, restricted service connections may well have the effect of enhancing the number of sites getting full-service connections eventually. Jon -- Jon Bloom, KE3Z -- jbloom@uhasun.hartford.edu
-----------[000364][next][prev][last][first]---------------------------------------------------- Date: 30 May 90 15:47:42 GMT From: fernwood!hercules!dirt.cisco.com!kph@uunet.uu.net (Kevin Paul Herbert) To: tcp-ip@nic.ddn.mil Subject: Re: tcp/ip services <--> decnet connectivity, help wanted
The easiest thing to do would be to get a DECstation 3100 (or something else running Ultrix) and use the DECnet-Internet gateway software. I don't know many product specifics, but I know that you can use it for remote login and file transfer. You should also be running at least DECnet/E V4.0 (RSTS/E V9.3) as previous versions had some problems dealing with Ultrix, if I recall correctly. I've always thought it would be *fun* to put up TCP/IP on RSTS, though. It really wouldn't be that hard to do for someone that was good with RSTS monitor internals. Kevin
-----------[000365][next][prev][last][first]---------------------------------------------------- Date: 30 May 90 16:35:44 GMT From: kmeyer@decwrl.dec.com (Kraig Meyer) To: tcp-ip@nic.ddn.mil Subject: Re: What is VMTP?
In article <12637@netcom.UUCP> hinton@netcom.UUCP (Greg Hinton) writes: ||I've read bits & pieces about something called VMTP. From what I've seen, ||it appears to be a reliable counterpart of UDP. ||Can someone explain in more depth exactly what VMTP is and/or provide ||easily available references? ||Are there any implementations under UNIX? VMTP was developed as a transport protocol for the V distributed system at Stanford. Try "VMTP as the Transport Layer for High-Performance Distributed Systems" by David Cheriton and Carey Williamson, IEEE Communications Magazine, June 1989, p. 37. **************************************************** Kraig Meyer kraig@wrl.dec.com On parole from the University of Southern California My views do not necessarily represent those of DEC.
-----------[000366][next][prev][last][first]---------------------------------------------------- Date: 30 May 90 16:36:19 GMT From: intercon!news@uunet.uu.net (Amanda Walker) To: tcp-ip@nic.ddn.mil Subject: Re: What is the IAB?
In article <9005300234.AA07597@psi.com>, schoff@PSI.COM ("Martin Lee
Schoffstall") writes:
> CMOT was elevated to DIS without the above.
It was my understanding that this was done by the ISO, not the IAB. The
IAB has no authority to designate things DIS or IS.
--
Amanda Walker
InterCon Systems Corporation
-----------[000367][next][prev][last][first]---------------------------------------------------- Date: 30 May 90 16:42:29 GMT From: frooz!cfa250!cliff@husc6.harvard.edu (Cliff Stoll) To: tcp-ip@nic.ddn.mil Subject: Re: A SUSPICIOUS SECURE GATEWAY
From henry@utzoo.uucp (Henry Spencer): > they can't make a Unix that they can trust when it is > administered by incompetents. Nobody else can make such a system either. I second that!
-----------[000368][next][prev][last][first]---------------------------------------------------- Date: Wed, 30 May 90 23:51:30 -0400 From: "Martin Lee Schoffstall" <schoff@psi.com> To: intercon!news@uunet.uu.net (Amanda Walker) Cc: tcp-ip@nic.ddn.mil Subject: Re: What is the IAB?
> It was my understanding that this was done by the ISO, not the IAB. The > IAB has no authority to designate things DIS or IS. No, the "Internet" has a somewhat parallel concept with Draft Internet Standards (DIS) Internet Standards (IS) Which is outlined in one of the RFC's, the process of standardization is somewhat obscure. Marty
-----------[000369][next][prev][last][first]---------------------------------------------------- Date: 30 May 90 17:14:47 GMT From: bu.edu!bu-it!kwe@eddie.mit.edu (Kent England) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
In article <118@ultrix.uhasun.hartford.edu>, jbloom@uhasun.hartford.edu (Jon Bloom) writes: > In article <57875@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes: > > We also have strict standards on quality of service, and we > > do not wish to compromise these standards in offering less costly access, ... > > > Speaking as one who is trying to figure out how to convince management that > $10k/yr would be well spent, I would be willing to accept service limitations > for a lower-cost net access. If the service truly is as useful to the > organization as I believe it would be, the demonstration of that usefulness > might just break loose the dollars for a higher quality ($10K) connection. So > providing low-cost, restricted service connections may well have the effect > of enhancing the number of sites getting full-service connections eventually. > We hear you. Let me elaborate on some of the costs hidden in a NEARnet service fee. Consider these representative of a mid-level network service provider. I certainly don't mean this as an advertisement, but as explanation of the costs of internetworking. It might be helpful for someone starting from a UUCP or BITnet point of view. Cost of the router on your end. NEARnet requires that the demarcation point be on the local LAN and not somewhere on the leased line. In other words, NEARnet has to own and control the router at your site. You have to pay for that. But this has proved critical to achieving service objectives. Cost of the router on our end. It takes a lot of hardware to make the NEARnet core work and provide access to NSFnet and other services. Leased line charges. Leased lines are expensive and difficult to move and change. Fractional T1 is helping that a little, but still, we are in large part unable to provide distance-insensitive fees, and some of our clients pay large fees because of geography. Depreciation. What does your service provider do for you when your router is obsolete and can no longer function in an Internet? Do they make you pay for a new one? NEARnet builds depreciation into its fee schedules, so you pay for the cost of hardware and software continually, and not in a lump sum, or worse, never. Depreciation is critically important to a network service provider being able to keep up with the technology. People costs. It is very expensive in man-hours to run a mid-level network, but we have found that it does not pay to scrimp on people. I think new network management tools will help, particularly as we gain control of the wide area network, but it is still an expense that we feel is justified to provide a sufficiently high level of service. NOCs should be 24 hours a day, seven days a week, and that will never be cheap. User services. We have found it absolutely critical to be able to offer some minimal user services to our members. This is extremely important to some of our clients. Some of these services are things like name servers for their domains and help with registration and connected-status. But it also includes a committment from NEARnet to take responsibility for tracking down, identifying, and, to the extent possible, fixing users' connectivity problems, no matter where in the Internet the problem is lurking. This is a service available to anyone, anywhere. Finger @nic.near.net for details. It also includes Dan Long's time and effort in the IETF in the User Connectivity Problems Working Group to try to spread this capability and commitment throughout the Internet. All this adds up to quite a chunk of change. Makes UUCP look pretty good, eh? :-) I understand, though, that money is money and it still costs too much. I believe the NSF is sympathetic, as they are still considering proposals for grants to connect qualified sites to the Internet. You may be able to turn to the NSF for grant aid. It's all part of the Internet growing up, running like a business, going private, etc. And NEARnet is not the only mid-level network service provider working these issues. More and more operational people are getting into the IETF and there is the Federation of American Research Networks which is populated by the mid-level networks, among others, and is working on these sorts of issues. --Kent England
-----------[000370][next][prev][last][first]---------------------------------------------------- Date: Wed, 30 May 90 22:07:16 EDT From: farber@pcpond.cis.upenn.edu (David J. Farber) To: stev@vax.ftp.com Cc: tcp-ip@nic.ddn.mil
In reply to: Date: Wed, 30 May 90 15:34:19 -0400Subject: Re: What is the IAB? From: stev@vax.ftp.com To: "Martin Lee Schoffstall" <schoff@psi.com> cc: tcp-ip@nic.ddn.mil, karn@ka9q.bellcore.com (Phil Karn) >CMOT was elevated to DIS without the above. >Marty after the abuse they got, i *doubt* that will ever happen again. ..... ============================================ If it was the wrong thing, then why haven't they rescinded the CMOT status? Dave
-----------[000371][next][prev][last][first]---------------------------------------------------- Date: 30 May 90 19:12:00 GMT From: att!cbnewsh!eric@ucbvax.Berkeley.EDU (eric.l.asbeck) To: tcp-ip@nic.ddn.mil Subject: IBM 5250 support on TCP/IP
I want to connect a TCP/IP workstation and 5250-based applications on an AS/400. 5250 is the default or native data stream supported on the IBM AS/400 and the IBM S/3x (as opposed to the 3270 data stream used for MVS and VM systems). The workstation is on Ethernet and runs HP-UX, which is compatible with UNIX System 5.2 and BSD 4.2. The AS/400 is on a Token Ring and I know how to bridge the Token Ring to the Ethernet. Based on what I've learned so far, one of the following might work if I can find the necessary components: 1) "TN 5250" extensions to Telnet. I know that RFC 1041 defines a Telnet 3270 Regime Option which supports the 3270 data stream within the Telnet protocol. I've not been able to find a similar regime option for the 5250 protocol stream. I also understand that IBM does not presently include Telnet as part of its TCP/IP support on the AS/400, but that they have made a Statement of Direction for it. 2) An X-Windows 5250 emulation package for the workstation which can talk directly to the AS/400 or go through an intermediary system. I'd prefer a full-blown X application, but I'd consider a character-based application accessed by something like xterm. 3) Support of APPC/LU6.2 on HP-UX over the workstation's Ethernet interface. Ideally this would include support for the 5250 data stream under LU6.2, but I'd be happy just to find a vendor that provides the LU6.2 support. Any pointers or suggestions would be greatly appreciated. I don't regularly subscribe to this newsgroup, so I'd appreciate your replying directly to me via email at the address given below. Thanks in advance! Eric Asbeck AT&T Bell Labs ela@homxb.att.com or att!homxb!ela
-----------[000372][next][prev][last][first]---------------------------------------------------- Date: Thu, 31 May 90 0:05:41 EDT From: "Robert J. Reschly Jr." <reschly@BRL.MIL> To: tcp-ip@nic.ddn.mil Subject: Namespace clashes (was: What is the IAB?)
Good evening,
A quick point worth noting. I read Marty's note about CMOT being
advanced to DIS; thinking, "Yeah, it did get advanced to Draft Internet
Standard status". I later read Amanda's note about Draft International
Standards under the same thread; again nodding in agreement. Only when I
read the next followup (again referring to Draft Internet Standards) did
I tumble -- namespace clash.
I would propose PINS, DINS and INS where 'IN' comes from "InterNet"
but fear that is still to close to ISOese. Maybe PIPS, DIPS, and IPS
with 'IP' coming from "Internet Protocol". By tucking in the extra
word, the likelyhood of these acronyms being collapsed back to TLAs
(Three Letter Acronyms) is reduced.
Later,
Bob
--------
IP: reschly@BRL.MIL UUCP: ...!{{cmcl2,nlm-mcs,husc6}!adm,smoke}!reschly
U.S. Army Ballistic Research Lab. / Systems Eng. & Concepts Analysis Div. /
Networking & Systems Dev. Team / ATTN: SLCBR-SE-A (Reschly) /
Aberdeen Proving Grounds, MD 21005-5066 / (301)278-6808 AV: 298-6808
**** For a good time, call: (303) 499-7111. Seriously! ****
-----------[000373][next][prev][last][first]---------------------------------------------------- Date: 30 May 90 22:23:00 GMT From: mogul@decwrl.dec.com (Jeffrey Mogul) To: tcp-ip@nic.ddn.mil Subject: Re: When is an ethernet full?
When is an ethernet full? ....
According to our Network General sniffer,
we constantly maintain about 10-15 percent utilization or (300 - 1000
packets per second). How much more traffic can this network support
before performance falls off measurably? Any ideas?
The best place I know of to start answering this question is Boggs,
Mogul and Kent's article in Proc. of SIGCOMM '88 pp. 222-233. The
gist of that article is that you can drive the Ethernet all the way
to its rated capacity assuming you are careful in the way you lay out
your network, and all your systems have good Ethernet hardware.
Thanks for the plug, Craig ... but I think you have misconstrued
our results, at least in trying to apply them to the question at hand.
True, "you can drive the Ethernet all the way to its rated capacity"
(well, at least 95% of the way) if what you are trying to do is to
make full use of the bandwidth. This is NOT the same thing as saying
that you will have a useful network if the average load is 95%. In
fact, as I found out last night (while running some TCP benchmarks
on our lab's main Ether) if you use 90%+ of the network between one set
of hosts, other hosts are going to suffer badly.
The reason is queueing delay. Think of an arbitrary host with a
stream of packets it wants to send. If the load on the network is
100%, then its output queue will grow forever and the effective delay
will become infinite. Actually, I think you can show that the
asymptote for infinite delay happens at a load below 100%, for any
finite inter-arrival time for new packets.
What then is the "right" level at which to declare an Ethernet "full"?
That depends. If you are running a real-time application that can
never accept a delay > 1.2 milliseconds, then you may not be able
to use an Ethernet at all. If you are only using the net to carry
non-interactive traffic (like electronic mail) then you might get
away with an average load above 90%. In the usual "NFS+xterm+other
stuff" kind of environment that we run, I've seen 5-second load
averages above 50% without hearing users complain, although I would
probably complain myself if the load stayed this high all the time.
If your average load (calculated over one-second intervals, as is
the usual practice) is only 15%, then you are probably not going
to notice any problems.
The point of our paper is not that you should run your net at 50%
(or 70% or 90%) utilization; we even said ``Don't try this at home.''
The point is that an Ethernet is no worse when carrying high loads
than other 10Mbit/sec multi-access LANs.
In practice of course, many of the systems won't have good Ethernet
hardware (for example, Jacobson's talk at SIGCOMM '88 indicated he'd
found an Ethernet chipset that could only go about 6 Mbits/sec). So
you need to find some people out there with some good practical experience
about when some of their systems start breaking down, to figure out when
your network will die due to poor hardware/software.
In general, even the hosts with the full-speed ethernet interfaces
won't be using them at full speed (because most protocols are
flow-controlled at some level, and the ultimate data sources and
sinks seldom run at 10Mbits/sec.) If you are worried about worst-case
scenarios, such as somebody like David Boggs or myself running network
benchmarks on your net, then you might want to pay attention to the
capabilities of your host interfaces. But in most cases, your network
load comes from a composite of many slower sources, and what matters
is how many hosts you have and what fraction of them are going to
be active at once.
-Jeff
-----------[000374][next][prev][last][first]---------------------------------------------------- Date: 30 May 90 22:25:44 GMT From: cs.utexas.edu!texbell!moxie!hack@tut.cis.ohio-state.edu (Greg Hackney) To: tcp-ip@nic.ddn.mil Subject: Re: NFS for NCR TOWER
In article <1332@telsys.aut.UUCP> ruef@aut.UUCP (Bernhard Ruef) writes: > >Does anybody know about the availability of NFS for a NCR TOWER 32/[46]X0 >running System V.3 (Release 3.00.01 in NCR speak) ? >Bernhard D. Ruef Ascom Autelca AG CH-3073 Guemligen/Switzerland >E-mail: ruef@aut.UUCP FAX: +41 31 527 745 Voice mail: +41 31 529 602 I'm curious too. A friend at Cornell said he seemed to recollect a PD version of NFS than ran outside the kernel. -- Greg
-----------[000375][next][prev][last][first]---------------------------------------------------- Date: 31 May 90 00:12:00 GMT From: deering@PESCADERO.STANFORD.EDU (Steve Deering) To: comp.protocols.tcp-ip Subject: Re: What is VMTP?
> I've read bits & pieces about something called VMTP. From what I've seen, > it appears to be a reliable counterpart of UDP. > Can someone explain in more depth exactly what VMTP is and/or provide > easily available references? VMTP is a transport-layer protocol that provides a reliable request/response or RPC style of service, rather than the reliable stream service of TCP or the unreliable datagram service of UDP. As others have pointed out, it has been described in several papers by David Cheriton of Stanford; the protocol specification can be found in RFC-1045. > Are there any implementations under UNIX? Yes, there is an implementation for 4.3BSD and derivitives (SunOS, Ultrix) that may be obtained by anonymous FTP from host gregorio.stanford.edu, in the vmtp-ip directory. The software is free but covered by a Stanford license agreement, which can be found in the file vmtp.LICENSE in that directory. Steve Deering
-----------[000376][next][prev][last][first]---------------------------------------------------- Date: 31 May 90 01:07:48 GMT From: smb@ulysses.att.com (Steven Bellovin) To: comp.protocols.tcp-ip Subject: Re: Dial up access to Internet facilities
There's no reason, of course, why the dial-up hub can't call out. As long as the time to complete the call (including login) is less than 30 seconds or so, most TCPs won't care (too much).
-----------[000377][next][prev][last][first]---------------------------------------------------- Date: 31 May 90 01:25:50 GMT From: zaphod.mps.ohio-state.edu!mips!prls!pyramid!infmx!aland@tut.cis.ohio-state.edu (Colonel Panic) To: tcp-ip@nic.ddn.mil Subject: Re: Re. Wollongong TCP/IP
In article <539@secola.Columbia.NCR.COM> syackey@secola.UUCP (steve yackey) writes:
>>So AT&T threw out the Lachman-based one they supply standard with S5R4
>>and supply a Woolongong-based release instead?
>
>no, when you buy 5.4 you get lachman tcp.
>when you buy a 6386, you get wollongong. for the 6386 at&t "upgraded" the tcp.
Uh, the 6386 definitely does not come with WIN/TCP automatically. It
is an *option*, as is the Interlan solution. You can get either
WIN/TCP 3.0 for StarLAN cards or a Racal Interlan s/w-card combo.
Note that AT&T's version of WIN/TCP is still 3.0. Wollongong sells
3.1 themselves as the current release, and they include drivers for
a number of common ethernet cards (AT&T strips those out). On my
6386s, I'm running Wollongong's own 3.1 version on WD cards because I have
to use interrupt 2 (=9), and WIN/TCP 3.0 doesn't handle that interrupt
properly...
--
Alan Denney # Informix # aland@informix.com # {pyramid|uunet}!infmx!aland
"These tests will have no effect on your grades. They will merely
determine your future social status and financial success, if any."
-----------[000378][next][prev][last][first]---------------------------------------------------- Date: 31 May 90 01:40:41 GMT From: cs.umn.edu!wsmith@ub.d.umn.edu (Warren Smith [Randy]) To: tcp-ip@nic.ddn.mil Subject: Re: When is an ethernet full?
In article <56724@bbn.BBN.COM> craig@ws6.nnsc.nsf.net.BBN.COM (Craig Partridge) writes: >> When is an ethernet full? .... > >The best place I know of to start answering this question is Boggs, >Mogul and Kent's article in Proc. of SIGCOMM '88 pp. 222-233. The >gist of that article is that you can drive the Ethernet all the way >to its rated capacity assuming you are careful in the way you lay out >your network, and all your systems have good Ethernet hardware. > .... > >Craig One thing to remember - while Boggs, Mogul and Kent's article shows that the Ethernet will run right up to saturation (~95% depending on packet size and number of stations), it does not fully address the matter of delay. Delay increases as your Ethernet becomes more heavily loaded. BMK's measurement of delay does not include measurement of queueing delays, and thus underestimates the real delays that will be seen by many hosts (and users) on your network. I have seen real Ethernets running more than 40% load (averaged over 1 hour!, bursts up in the 80-95% range). Most of those nets aren't around any more - they've been split to improve performance. These networks were (and are) growing, so they would have had to split at some point anyway. When you should split depends on what the needs are for your network, and what the growth rate is. -Randy -- Randy Smith wsmith@umn-cs.cs.umn.edu ...!rutgers!umn-cs!wsmith
-----------[000379][next][prev][last][first]---------------------------------------------------- Date: 31 May 90 02:52:44 GMT From: deimos.cis.ksu.edu!dino!cs.iastate.edu!hascall@uunet.uu.net (John Hascall) To: tcp-ip@nic.ddn.mil Subject: Trying to write a bootp client for Ultrix
I am working on a bootp client which I hope to use as follows (in
/etc/rc.local):
ifconfig `bootp-client`
The aim of the program is to produce a string like the following:
se0 129.186.1.62 netmask 255.255.255.0 broadcast 129.186.1.255
The client program creates a datagram socket, but when it attempts
to bind (to addr=INADDR_ANY, port=BOOTP) it fails unless I preceed
the bind with a SIOCSIFADDR (set address) ioctl call%. Herein lies the
problem: the whole reason for this program is to discover the address!
If I just stick in a bogus address (say 129.186.0.0) I get the bootp
request sent fine, but I don't receive the reply. I have tried all
sorts of things but none have worked...
...does any one have any ideas on how to make this work?
Thanks again,
John Hascall hascall@atanasoff.cs.iastate.edu
% according to man side effect of SIOCSIFADDR is to initialize the interface
-----------[000380][next][prev][last][first]---------------------------------------------------- Date: Thu, 31 May 90 08:55:28 EDT From: Frank J. Robey <fjr@ulana.mitre.org> To: tcp-ip@nic.ddn.mil Subject: Re-posting of question on National Voluntary Lab Program
I posted this question several weeks ago and never received any replies so I'll assume that there has been no interest in having products undergo this testing. Haven't any of you that sell products to the Government been asked to certify your products?? >I was wondering if anyone has had any experience with the NVLAP Testing? If >so, how much work was involved in preparing your component for testing, what >the results were and how accurate you felt that the tests were. >Frank J. Robey >The MITRE Corporation >fjr@mitre.org
-----------[000381][next][prev][last][first]---------------------------------------------------- Date: Thu May 31 13:22:04 1990 From: robjohn@ocdis01.af.mil (Robert Johnson (CDC Contractor);CDC;) To: tcp-ip@nic.ddn.mil Cc: ath@ptt.lcs.mit.edu Subject: re: toll restrictors
In response to my recent posting about using a software product rather than a toll restrictor to control outbound connectivity, Andrew Heybey writes: > I'm curious as to what you mean by "turn off telnet". Of course, I don't > know what sort of system you're running and what sort of capabilities it > provides, but on a unix system, telnet is a user program that opens a > socket. If you remove the telnet program, all I have to do to get that > capability back is get the source to a telnet program from somewhere and > compile it in my home directory. Voila, I can telnet anywhere I want to. > I can do the same with ftp (in fact, I would write a crude ftp first so as > to be able to go get a better ftp and telnet from someplace else). Does > your system not allow unprivilidged users to open network connections? Are > you relying on nobody knowing how to write/compile/etc their own program to > use the net? Or does your system have some other mechanism for controlling > network access? Good question - nothing's ever as simple as it sounds, is it? By 'turn off', I mean we change permissions so only a trusted group of individuals can use it - not the user population at large. We protect telnet, ftp, cu, tip, and the compilers and debuggers this way. We also have daily reports showing who is using these functions. Rather than digress into a diatribe about system administration, I'll just say that our philosophy is not to deny service to our users, but to be fully accountable. Certain users need to use these compilers, debuggers and communications (other than we have provided by menu access) for valid purposes. We allow them to use them, but they must prove a valid need. And, they know that we regularly monitor these activities. Running the system this way provides full functionality for all users (based on a valid need), and yet maintains full accountability of our connectivity with other systems. Bob Johnson, System Administrator Tinker Air Force Base, Oklahoma
-----------[000382][next][prev][last][first]---------------------------------------------------- Date: Thu, 31 May 90 10:33:47 EDT From: jbvb@vax.ftp.com (James Van Bokkelen) To: tcp-ip@nic.ddn.mil Subject: LANWatch dumps of OSI ES-IS, CLNP/TP traffic wanted
I asked this on comp.protocols.iso and got no replies... I tested our LANWatch product's OSI parsers at InterOp, but when I got home I discovered that the only CLNP packets I'd saved were an artifact of a router bug, and weren't adequate as examples or for further testing. Any LANWatch owners who have CLNP traffic on their local nets (802.5 or Ether), and would be willing to make me a few dump files, please reply via e-mail. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000383][next][prev][last][first]---------------------------------------------------- Date: Thu, 31 May 90 11:46:30 EDT From: stev@vax.ftp.com To: intercon!news@uunet.uu.net (Amanda Walker) Cc: tcp-ip@nic.ddn.mil Subject: Re: What is the IAB?
>In article <9005300234.AA07597@psi.com>, schoff@PSI.COM ("Martin Lee
>Schoffstall") writes:
>> CMOT was elevated to DIS without the above.
>
>It was my understanding that this was done by the ISO, not the IAB. The
>IAB has no authority to designate things DIS or IS.
>
>--
>Amanda Walker
>InterCon Systems Corporation
marty was refering to Draft Internet Standard, while you are refering to
Draft International Standard.
-----------[000384][next][prev][last][first]---------------------------------------------------- Date: Thu, 31 May 90 15:03:10 CDT From: MAINT@ASNTSU.asn.net To: tcp-ip@nic.ddn.mil
In-Reply-To: usc!uscd!uwm!zaphod.cs.ohio-state!HERE!THERE!EVERYWHERE!BIFF AT ucbvax.Berkeley.EDU
-- 31 May 90 12:45:41 GMT
I have only been subscribed to this list for a short time and the discussions
seemed to be at a professional level. This looks to me like an unauthorized
hacker. Can I assume this is atypical of this list?
It seems someone is adding fuel to the flames being sent about dial-up
access to the internet. This certainly points out the need for tracability
if it is unauthorized.
>HIYA D00DS!! ICUZ MY BBROTHER <--BIG BROTHER, NEET HUH? WUZ BBSITTING ME AND
>MY MOM WULD KILL HIM IF ANYTING HAPENED TO ME. THEES SHUR R
>NIFTY BBOARDS!! IZ ANYWON MODURATING THEM?? I CAN DO IT D00DS!!
>I PROVED MY BABAILITY BY MODURATING NEWS.GROUPS. SO FROM NOW ON
>IC0WABUNGA!!
>
>------
>BIFF@BIFFVM.BIT.NET
>BIFF+@ANDREW.CMU.EDU
>BIFF@BIT.NET.GATE.WAY.MAN.WOMAN.BIRTH.DEATH.ALPHA.OMEGA.BIFF
--------------------------------------------------------------------------------
Dennis Putnam, Service Manager
Boeing Computer Services
Alabama Supercomputer Network
-----------[000385][next][prev][last][first]---------------------------------------------------- Date: Thu, 31 May 90 22:06:50 -0700 From: "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov> To: "Martin Lee Schoffstall" <schoff@psi.com> Cc: jbloom@uhasun.hartford.edu, tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
. . . I think the counter argument is that if it doesn't work reliably/well especially in the beginning then people won't rely on it to provide communications for their everyday needs. If they don't use it everyday then it is luxury suitable for axing at the appropriate belt-tightening time. Marty Marty, I think John was trying to espouse the "crack dealer's" approach to Internetting. First, you give them a little something either free or very low in cost. Then, once they are hooked, you stick it to them with high cost, high performance solutions, and by this time, they are screaming for more and can't do without. They will pay and and pay at this point. Those of us who work in the government side of networking don't use this exact tactic, but I know of many large organizations who were "hooked" this way... Thanks, Milo
-----------[000386][next][prev][last][first]---------------------------------------------------- Date: 31 May 90 12:08:39 GMT From: galbp!bagend!bvsatl!root@gatech.edu (Super user) To: tcp-ip@nic.ddn.mil Subject: Re: Query - Ethernet collisions
In article <98@fedeva.UUCP>, bill@fedeva.UUCP (Bill Daniels) writes:
> We recently acquired an Exelan LANalyzer. During our first uses of it,
> we noticed that about 40% of the packets on one ethernet segment (which
> is remotely bridged to another)
> Any clues?
>
> bill daniels
> federal express, memphis, tn
> {hplabs!csun,mit-eddie!premise}!fedeva!bill
I had a similiar problem in the past. After much hair pulling, we
found that you can not cascade DELNIs. That is, don't put the
drop cable from a DELNI into a DELNI more than one level deep.
While this may not be your problem, it sounds similiar. If this is not
it, you may want to check cable lengths, cable types (ie rg58), etc.
Bill VerSteeg
-----------[000387][next][prev][last][first]---------------------------------------------------- Date: Thu May 31 12:30:44 1990 From: cctal!andrew@relay.EU.net To: tcp-ip@nic.ddn.mil Cc: cctal!andrew@relay.EU.net Subject: SLIP Information
SLIP fans, old and new Having been watching the traffic for the past few weeks and noticed all the people looking for more info on SLIP, I think it's high time something was done about this, so (I'll probably regret this) I volunteer! Apart from the fact that I am looking for the same thing (and have had some modest success) I think it is a worthwhile exercise. So, I will undertake to prepare a summary for the net on SLIP and its availability and use. What I want to do this is info from SLIP users. All those of you out there using SLIP, please email me summaries of: Equipment Configuration SLIP software version, where you got it etc Usage Problems Any other info In particular, I think people wanting SLIP are looking for the PC + modem to Brand X UNIX box solution - feel free to correct me if I am wrong. No summary of SLIP would be complete without reference to ka9q and ppp, so info from actual users of these is solicited as well. Please do not send source code, RFCs, or long specifications of any sort, user experiences and known locations (USA, UK and Europe) of SLIP code is what is wanted. Look forward to hearing from you Andrew Hardie London, England
-----------[000388][next][prev][last][first]---------------------------------------------------- Date: 31 May 90 12:45:41 GMT From: usc!uscd!uwm!zaphod.cs.ohio-state!HERE!THERE!EVERYWHERE!BIFF@ucbvax.Berkeley.EDU (THE BIFFMAN COMETH) To: tcp-ip@nic.ddn.mil Subject: C0WABUNGA!!
HIYA D00DS!! ICUZ MY BBROTHER <--BIG BROTHER, NEET HUH? WUZ BBSITTING ME AND MY MOM WULD KILL HIM IF ANYTING HAPENED TO ME. THEES SHUR R NIFTY BBOARDS!! IZ ANYWON MODURATING THEM?? I CAN DO IT D00DS!! I PROVED MY BABAILITY BY MODURATING NEWS.GROUPS. SO FROM NOW ON IC0WABUNGA!! ------ BIFF@BIFFVM.BIT.NET BIFF+@ANDREW.CMU.EDU BIFF@BIT.NET.GATE.WAY.MAN.WOMAN.BIRTH.DEATH.ALPHA.OMEGA.BIFF
-----------[000389][next][prev][last][first]---------------------------------------------------- Date: 31 May 90 14:52:05 GMT From: csusac!csuchico.edu!robin@ucdavis.ucdavis.edu (Robin Goldstone) To: tcp-ip@nic.ddn.mil Subject: Re: tcp/ip services <--> decnet connectivity, help wanted
In article <18409@hercules.csl.sri.com> kph@dirt.cisco.com (Kevin Paul Herbert) writes: >The easiest thing to do would be to get a DECstation 3100 (or something >else running Ultrix) and use the DECnet-Internet gateway software. I >don't know many product specifics, but I know that you can use it for >remote login and file transfer. You should also be running at least >DECnet/E V4.0 (RSTS/E V9.3) as previous versions had some problems >dealing with Ultrix, if I recall correctly. > >I've always thought it would be *fun* to put up TCP/IP on RSTS, though. >It really wouldn't be that hard to do for someone that was good with >RSTS monitor internals. > >Kevin I also spent a long time looking for a TCP/IP implementation for RSTS. After giving up on that, I looked at the solution described above, i.e. an Ultrix VAX as a gateway. All you need to run on it is DECnet-Ultrix. This automatically does conversion between DECnet protocols and TCP/IP protocols (according to DEC). Get DEC's "Local Area Network Solutions Guidebook" and read page 74. Well, in the end we decided that this solution was too indirect and ended up replacing our three RSTS systems with a VAX 6310! Too bad there wasn't a real TCP/IP solution for RSTS. I kinda miss it... Robin Goldstone, Systems Software Specialist California State University, Chico Computing Services robin@csuchico.edu
-----------[000390][next][prev][last][first]---------------------------------------------------- Date: 31 May 90 15:29:58 GMT From: intercon!news@uunet.uu.net (Amanda Walker) To: tcp-ip@nic.ddn.mil Subject: Re: Namespace clashes (was: What is the IAB?)
In article <9005310005.aa26406@SPARK.BRL.MIL>, reschly@BRL.MIL ("Robert J.
Reschly Jr.") writes:
> I read Marty's note about CMOT being
> advanced to DIS; thinking, "Yeah, it did get advanced to Draft Internet
> Standard status". I later read Amanda's note about Draft International
> Standards under the same thread; again nodding in agreement. Only when I
> read the next followup (again referring to Draft Internet Standards) did
> I tumble -- namespace clash.
I do apologize for that--I must admit that I hadn't seen the Internet version
written as a TLA recently, and so the ISO interpretation was in my mental
cache, reinforced by the fact that I think of CMOT as an ISO protocol that
some strange people just happen to run over TCP :-).
Sorry for any confusion...
--
Amanda Walker
InterCon Systems Corporation
-----------[000391][next][prev][last][first]---------------------------------------------------- Date: 31 May 90 17:22:34 GMT From: silver!hughes@iuvax.cs.indiana.edu (larry hughes) To: tcp-ip@nic.ddn.mil Subject: Re: tn3270 daemon?
In article <90145.140551HATHAWA@gecrdvm1.crd.ge.com> HATHAWA@gecrdvm1.crd.ge.com (Barry Hathaway) writes: >In article <45793@iuvax.cs.indiana.edu>, hughes@silver.ucs.indiana.edu (larry >hughes) says: >> >>Does anyone know of a tn3270 daemon, somewhat of a hybrid between >>telnetd and (reverse) tn3270? I'm fairly certain there's no such >>animal, but if there is we'd have a good use for it. >> >Many TCP/IP packages for IBM mainframes offer terminal emulation on the host >side - which I guess could be called a tn3270 daemon. Fibronics (aka Sparticus) >KNET package has this as an option. Simware offers SIM/TCPIP an add-on to >IBM's TCP/IP package which does terminal emulation. Yes, thanks for the information, but I was aware of these. My question still stands in spite of them! Thanks, and I request further responses... //=========================================================================\\ || Larry J. Hughes, Jr. || hughes@ucs.indiana.edu || || Indiana University || || || University Computing Services || "The person who knows everything || || 750 N. State Road 46 Bypass || has a lot to learn." || || Bloomington, IN 47405 || || || (812) 855-9255 || Disclaimer: Same as my quote... || \\==========================================================================//
-----------[000392][next][prev][last][first]---------------------------------------------------- Date: 31 May 90 20:03:10 GMT From: MAINT@ASNTSU.ASN.NET To: comp.protocols.tcp-ip Subject: (none)
In-Reply-To: usc!uscd!uwm!zaphod.cs.ohio-state!HERE!THERE!EVERYWHERE!BIFF AT ucbvax.Berkeley.EDU
-- 31 May 90 12:45:41 GMT
I have only been subscribed to this list for a short time and the discussions
seemed to be at a professional level. This looks to me like an unauthorized
hacker. Can I assume this is atypical of this list?
It seems someone is adding fuel to the flames being sent about dial-up
access to the internet. This certainly points out the need for tracability
if it is unauthorized.
>HIYA D00DS!! ICUZ MY BBROTHER <--BIG BROTHER, NEET HUH? WUZ BBSITTING ME AND
>MY MOM WULD KILL HIM IF ANYTING HAPENED TO ME. THEES SHUR R
>NIFTY BBOARDS!! IZ ANYWON MODURATING THEM?? I CAN DO IT D00DS!!
>I PROVED MY BABAILITY BY MODURATING NEWS.GROUPS. SO FROM NOW ON
>IC0WABUNGA!!
>
>------
>BIFF@BIFFVM.BIT.NET
>BIFF+@ANDREW.CMU.EDU
>BIFF@BIT.NET.GATE.WAY.MAN.WOMAN.BIRTH.DEATH.ALPHA.OMEGA.BIFF
--------------------------------------------------------------------------------
Dennis Putnam, Service Manager
Boeing Computer Services
Alabama Supercomputer Network
-----------[000393][next][prev][last][first]---------------------------------------------------- Date: 31 May 90 21:14:14 GMT From: elroy.jpl.nasa.gov!usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@decwrl.dec.com (Henry Spencer) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
In article <9005302148.AA02245@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes:
>I think the counter argument is that if it doesn't work reliably/well
>especially in the beginning then people won't rely on it to provide
>communications for their everyday needs...
True in general, but one must beware of thinking of "reliably" and "well"
as Booleans. Uucp mail is unreliable and ungodly slow by Internet
standards, but vast numbers of sites found it reliable *enough* and
workable *enough* to come to rely on it very extensively.
The reason why a zoology department (!) was a major networking hub
at U of T for some years was that everybody else was so obsessed with
Internet (or better) performance that they wouldn't even look at silly
ideas like networking via low-speed modems. We set up our phone links
and started shipping mail and news, and pretty soon half the campus
had uucp links to us. Half a loaf is much more nutritious than none.
--
As a user I'll take speed over| Henry Spencer at U of Toronto Zoology
features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
-----------[000394][next][prev][last][first]---------------------------------------------------- Date: 31 May 90 23:14:45 GMT From: paperboy!meissner@think.com (Michael Meissner) To: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities
In article <9005301640.6.142@cup.portal.com> jb.loom@uhasun.UUCP writes: | In article <57875@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes: | > | > NEARnet is committed to broadening its base of support to include | > smaller sites at lower cost. We are chafing against technical issues in | > being able to offer high quality service at lower costs, since we balance | > hardware and people costs, and people costs are not really that bandwidth | > sensitive. We also have strict standards on quality of service, and we | > do not wish to compromise these standards in offering less costly access, | > since we know that later on our customers would regret the compromise as | > much as we. Then there is the issue of just what is part-time access; | > is it terminal dial-ups, SLIP/PPP (host or router?), uucp, what? We have | > to keep in mind what services we provide and we have to make sure that | > our clients understand what they can and can't do with new service offerings. | > | Speaking as one who is trying to figure out how to convince management that | $10k/yr would be well spent, I would be willing to accept service limitations | for a lower-cost net access. If the service truly is as useful to the | organization as I believe it would be, the demonstration of that usefulness | might just break loose the dollars for a higher quality ($10K) connection. So | providing low-cost, restricted service connections may well have the effect | of enhancing the number of sites getting full-service connections eventually. If all you currently want is SMTP and FTP initially, then uunet may be a way to start. They obviously will do mail, but another service they offer to paying customers is to do anonymous FTP's on request, and UUCP it to your machine. When I was at Data General, and the internet connection was extremely flakey (it did get better before I left), I begged, pleaded, and such to management to establish such a UUNET connection and buy the Telebit Trailblazer modem. I was able to get GCC releases and prereleases in a timely manner (though there was the time when I couldn't keep an internet connection or modem connection open long enough, thanks to the lousy GTE phone service in the RTP area of North Carolina or the lousy internal DG phone service). The last time I looked, the uunet charges where $35/month, $2/hour if you called their local number (using company WATTS lines if you have them), or $16/hour if you used their 800 number. A Telebit T2500 modem sells in the range of $1000. Obviously this is subject to change, as is their willingness to do anonymous FTP's for you (though they have most of the stuff people want directly on uunet). -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Catproof is an oxymoron, Childproof is nearly so
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |