|
|
ARCHIVE: TCP-IP Distribution List - Archives (1991)
DOCUMENT: TCP-IP Distribution List for April 1991 (422 messages, 243620 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1991/04.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 91 08:42:30 GMT From: tom@wcc.oz.au (Tom Evans) To: comp.protocols.appletalk,comp.protocols.tcp-ip Subject: Re: Subnetted TCP addresses and Webster MultiGates
In article <1991Mar26.192901.1670@cns.umist.ac.uk>, jf@ap.co.umist.ac.uk (John Forrest) writes: > We have ordered a Webster Multiport Gateway and are about to > put in a Localtalk network for our Macs. In preperation we have > put up CAP (to ensure it compiled on our Apollo's) and a few > other things. We've got hold of atalkad, and have compiled that > too. I am a bit concerned, though, about the issue of TCP > subnets in the configuration. The program obviously supports > them, but only refers to the use of whole number subnets. CAP maps "whole number" Class C subnets to IPTalk (AppleTalk) networks. Thus all CAP hosts that are on a Class C Subnet are deemed to be on the same AppleTalk network. Whether or not you are subnetted as you describe (subnetmask ffffffe0). It should work OK, as long as the routers handle the "full subnet" broadcast IP address properly (192.84.82.255). If this doesn't work properly you may need to run atalkrd. Possibly not though. If the MultiGate and the CAP host are on the same subnet it should be simple. > Essentially we plan to use two of the Multigates four Localtalk > ports for standard use (one is to be dedicated to a laser, and > the other kept spare for the moment). I was hoping to use two > of the subnets for these Completely separate subject. Setting up MacIP (protocol that supports MacTCP and NCSA Telnet etc.) is a completely separate issue to CAP. They aren't really related. I'll send you mail on this. > As far > as I can tell, MacTCP is happy with subnets - it definitely > allows you to set them up. But what it actually does with subnets is a mystery. It probably only uses this information when it is directly on Ethernet. Going through MacIP is another matter - the "routing decisions" are different. ======================== Tom Evans tom@wcc.oz.au ** ADD ".au" MANUALLY (don't trust "reply") ** Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179 Victoria, Australia 61-3-764-1100 FAX ...764-1179 A.C.N. 004 818 455 wcc@cup.portal.com 2109 O'Toole Avenue, Suite J SAN JOSE CA 95131 - 1303 CALIFORNIA 1-408-954-8054 FAX 1-408-954-1832 wcc-uk@cup.portal.com Unit 7, Weltech Centre Ridgeway, Welwyn Garden City Hertfordshire AL7 2AA LONDON UK. Ph 44-707-336969 Mobile 44-836-725849 FAX 44-707-373378
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 91 16:13:27 GMT From: malis@BBN.COM (Andy Malis) To: comp.protocols.tcp-ip Subject: Re: IP over Frame Relay Network
> I am not really sure where to ask this question but here goes... > Is anyone working on or has thoughts concerning running IP over a > Frame Relay network? What I had hoped to see (but didn't) was an RFC > to the tune of "Standard for the transmission of IP datagrams over > Frame Relay networks". Carl, This is actively in progress in the "IP over Large Public Data Networks" working group of the IETF. A new (hopefully close to final) draft of the specification will soon be released, based upon discussion at the St. Louis working group meeting. To join the discussion, send a subscription request to iplpdn-request@nri.reston.va.us . Regards, Andy
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 91 18:38:54 GMT From: bill@polygen.uucp (Bill Poitras) To: news.software.nntp,comp.binaries.ibm.pc.d,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: NNTP news readers for MS-DOS (QUERY)
I have seen a lot of talk about news readers for MS-DOS. Could someone
send me what they know about the various news readers. Things I want to
know are:
- What communications does it need? (pc-nfs,packet tcpip,none)
- How good is it? How much like RN does it work like?
- How configurable is it?
If I get enough responce, I will post a summary to
comp.protocols.tcp-ip.ibmpc. Mail is preferable. Thanks in advance.
+-----------------+---------------------------+-----------------------------+
| Bill Poitras | Polygen Corporation | {princeton mit-eddie |
| (bill) | Waltham, MA USA | bu sunne}!polygen!bill |
| | FAX (617)890-8694 | bill@polygen.com |
+-----------------+---------------------------+-----------------------------+
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 91 19:07:14 GMT From: carlson@mrx.webo.dg.com (James Carlson) To: comp.protocols.tcp-ip Subject: Re: UDP Reliability between processes on same host
Sure ... they can end up out of order -- UDP doesn't guarantee delivery, and packets may arrive out of order or duplicated. (Of course, this shouldn't happen on the *same* host, but .... !) May I ask why you're not just using IPCs, since that's what it sounds like you need? UDP is usually used for self-contained data (like in XDMCP) and as the basis for a more complex protocol (like TFTP). -- Disclaimer: My company neither knows nor cares what I say. .//.
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 91 19:15:39 GMT From: rick@wucs1.wustl.edu (Rick Bubenik) To: comp.protocols.tcp-ip Subject: Public domain, user level TCP/IP
Does anyone know of a public domain implementation of TCP/IP that runs as user level code under Unix (ideally implemented in C or C++)? I'm going to be porting TCP/IP to run over a new network and want to do some experimentation outside of the kernel. rick ++++++ Rick Bubenik rick@cs.wustl.edu Research Associate Department of Computer Science Washington University Campus Box 1045 One Brookings Drive St. Louis, Missouri 63130-4899 (314) 726-7530
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 91 20:30:07 GMT From: enag@ifi.uio.no (Erik Naggum) To: comp.protocols.tcp-ip Subject: Re: UDP Reliability between processes on same host
In article <1991Mar28.220615.5501@newbridge.com> todds@newbridge.com (Todd Sandor) writes:
Please don't flame me, I know UDP is unreliable, but I have a
question concerning using UDP between processes on the same host.
My experience is that UDP is reliable on the same host, and especially
so if you use the loopback (127.0.0.1 on some systems).
The problem with assuming that you talk to the same host is that one
day, you don't. The extra cost of sequence numbers, timeouts and
retransmits (which need only be trivial -- otherwise I would suggest
TCP), won't be incurred as long as you talk to your own host. Sure,
it's more code, and you need to check that you got the right packet
and so on. As message sequence integrity is one of your concerns, I
suggest that you use sequence numbers "just in case". It _could_ be
that the network code implementation on your system uses a LIFO type
buffer for outstanding packets, and that you will find out only under
heavy load, as you allude to.
- socket overflows or
- bad data length fields or
- bad checksums
I have a hard time thinking up conditions under which you'd get more
than the first problem on a local host, but as I said, you could
suddenly find yourself having two hosts communicating. Your code
should work, regardless.
but could we experience out of order packets or duplicate packets.
You should make sufficient safety nets to allow for these conditions.
Sequence numbers will do. For instance, you could provide a minimal
layer which, when expecting n packets, read packets and requested
retransmits until it got all of them, then delivered them back to the
caller in sequence. Or you could make this layer buffer up packets
arriving out of sequence and deliver the "next" (expected) packet when
called. (This will require negotiation of initial packet numbers
between the communicating processes, and dynamic memory handling, both
of which may become costly.)
I can't speak on the relative speed of using (one of) the address(es)
of the host or using the loopback. Intuitively, one would expect a
slightly higher throughput with the loopback, using your reasoning.
All I can say is I'm pretty certain that no implementation is slower
for the loopback than one of its other addresses.
Hope this helps.
--
[Erik Naggum] <enag@ifi.uio.no>
Naggum Software, Oslo, Norway <erik@naggum.uu.no>
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 91 20:30:24 GMT From: enag@IFI.UIO.NO (Erik Naggum, the Internet Purist) To: comp.protocols.tcp-ip Subject: Re: UDP Reliability between processes on same host
In message <1991Mar28.220615.5501@newbridge.com>, Todd Sandor writes:
... I have a question concerning using UDP between processes on the
same host.
My experience is that UDP is reliable on the same host, and especially
so if you use the loopback (127.0.0.1 on some systems).
The problem with assuming that you talk to the same host is that one
day, you don't. The extra cost of sequence numbers, timeouts and
retransmits (which need only be trivial -- otherwise I would suggest
TCP), won't be incurred as long as you talk to your own host. Sure,
it's more code, and you need to check that you got the right packet
and so on. As message sequence integrity is one of your concerns, I
suggest that you use sequence numbers "just in case". It _could_ be
that the network code implementation on your system uses a LIFO type
buffer for outstanding packets, and that you will find out only under
heavy load, as you allude to.
- socket overflows or
- bad data length fields or
- bad checksums
I have a hard time thinking up conditions under which you'd get more
than the first problem on a local host, but as I said, you could
suddenly find yourself having two hosts communicating. Your code
should work, regardless.
but could we experience out of order packets or duplicate packets.
You should make sufficient safety nets to allow for these conditions.
Sequence numbers will do. For instance, you could provide a minimal
layer which, when expecting n packets, read packets and requested
retransmits until it got all of them, then delivered them back to the
caller in sequence. Or you could make this layer buffer up packets
arriving out of sequence and deliver the "next" (expected) packet when
called. (This will require negotiation of initial packet numbers
between the communicating processes, and dynamic memory handling, both
of which may become costly.)
I can't speak on the relative speed of using (one of) the address(es)
of the host or using the loopback. Intuitively, one would expect a
slightly higher throughput with the loopback, using your reasoning.
All I can say is I'm pretty certain that no implementation is slower
for the loopback than one of its other addresses.
Hope this helps.
--
[Erik Naggum] <enag@ifi.uio.no>
Naggum Software, Oslo, Norway <erik@naggum.uu.no>
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 91 22:55:11 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: UDP Reliability between processes on same host
...but could we experience out of order packets or duplicate packets?
Taking an unsophisticated view, one wouldn't expect out of order or duplicate
packets unless IP routers and long-haul paths were involved. However,
consider what happens if a packet is lost due to hardware error on your
local cable (this WILL happen - believe me): You have to have some sort of
mechanism for detecting that it was lost and retransmitting it. If the
product of the probability of packet loss times the number of packets
outstanding (unacknowleged) at any given time gets high enough, your receiver
will see both out of order and duplication. Better to use TCP, IMHO.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 91 16:28:22 GMT From: frankh@durin.laguna.sparta.com (Frank Halsema) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: 10BaseT installation
I have read a lot about 10BaseT and I am considering using it in a new facility. Everything I see has the twisted pair connector as a RJ45 but inplications are that twited pair uses two pair or four wires. My question is how many pair do I need and if it is two pair why does 10BaseT use an RJ45 connector. Frank Halsema UUCP: durin!frankh SPARTA, Inc. Internet: frankh@laguna.sparta.com 23041 de la Carlota, Suite 400 Laguna Hills Ca, 92653 (714) 768-8161 EXT 339 (714)583-9114 FAX
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Tue, 2 Apr 91 17:22:23 GMT From: yjy@stlucia.uucp (Joe Yung) To: comp.sys.att,comp.protocols.tcp-ip Subject: Datakit Interface Through TCP/IP
NOTE: Followup to comp.sys.att I have a SPARC station 2 and a Datakit with a bunch of TTY modules. I am trying to have the SPARC connected to the Datakit so I can use my SPARC to access various TTY line off the Datakit. Does anybody know how ? I heard that AT&T Datakit has a connection to TCP/IP directly. We have a bunch of SPARCs on the Ethernet. It will be a a versatile way to open up the Datakit available to all the SPARCs. Does anybody know anything about this connectivity. Joe Yung yjy@stlucia.bellcore.com (908)699-5344
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 91 19:07:49 GMT From: ramsey@NPIRS.Purdue.EDU (Ed Ramsey) To: comp.protocols.tcp-ip,comp.protocols.nfs Subject: Has anyone updated pcnfsd to use passwd.adjunct?
Has anyone upgraded the pcnfsd program to work with sunos 4.1.1 C2 passwd.adjunct files? If so, could I have a copy? Thanks! -Ed -- Ed Ramsey ramsey@npirs.purdue.edu 317/494-6616 FAX/494-0535 currently: "User Services Manager" soon to be: "Network Services Manager"
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Tue, 2 Apr 91 19:10:23 GMT From: hughes@bronze.ucs.indiana.edu (larry hughes) To: comp.protocols.tcp-ip,vmsnet.mail Subject: VMS POP3 server
IUPOP3, a VMS POP3 (Post Office Protocol Version 3) server, is now available via anonymous ftp from mythos.ucs.indiana.edu (129.79.16.210) in the /pub/iupop3 directory. It was developed here at Indiana University in recent months. IUPOP3 is a static, multithreaded server that can process up to 31 simulataneous POP3 client connections. This does not mean that it can serve only 31 clients; here at IU it serves dozens. It was developed on VMS 5.3 and 5.4 systems, and currently requires the Wollongong WIN/TCP for VMS product. (It uses their $QIO interface extensively). We have not yet attempted to port the code to other TCP/IP products for VMS, although we will likely do so for UCX in the future. We've tested IUPOP3 thoroughly with two POP3 clients: Eudora for the Macintosh, and FTP Software's POP3 for DOS. It will probably work well with others. //=========================================================================\\ || Larry J. Hughes, Jr. || hughes@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... || \\==========================================================================//
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 91 20:45:26 GMT From: van@EE.LBL.GOV (Van Jacobson) To: comp.protocols.tcp-ip Subject: Re: TELNET slow through bridge.
> One difficult tradeoff when deciding which packet to drop is > which end of the TCP window to start from. Most VJ TCPs seem to > react badly when you drop the more recent packets first, so > since v2.04 we drop the older ones. James, Could you elaborate on this a bit? If something's broken, I'd like to fix it. - Van
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 91 21:19:31 GMT From: vances@xenitec.on.ca (Vance Shipley) To: comp.protocols.tcp-ip Subject: Re: Digital phones for SLIP circuits
In article <8204@suned1.Nswses.Navy.MIL> efb@suned1.Nswses.Navy.MIL (Everett F Batey II) writes: >Confronted with an urgent need to run SLIP between two Sun3s (OS 4.1 and >4.1.1) and some easy to comeby telephone assets AND NO money for modems, >we are trying to pick the most trustworthy and easy to accomplish SLIP >link. Sites are within 3 miles, wire, 1/2 mile crow flight. > >- We have Meridian phones for which we can get 9600 baud RS-232 interfaces. >DOES ANYBODY know if with handshaking and async over digitized phone line, >these data phone options WORK SUCCESSFULLY for this purpose ? I have Northern Telecom Meridian 1 telephones also. I also have the data units equipped in EVERY telephone! They work quite well. We use them for modem pooling, we have two T1000's and a pair of UDS 9600 baud modems that every one in house has access to. I plan to use these for slip soon when I get TCP/IP for DOS that supports slip. I do use them for UUCP through the modem pools. These beasts actually run up to 19.2K asynch. Units that run up to 64K sysnchronous are available. If you have digital TIE lines between your sites you should have no problem doing this up to 56K. Vance Shipley vances@ltg ..uunet!watmath!xenitec!ltg!vances
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 91 22:12:25 GMT From: rwolski@lll-crg.llnl.gov (Richard Wolski) To: comp.protocols.tcp-ip Subject: Bootp questions (a possible reposting)
Profuse apologies to those of you who have seen this before. I am posting this request for a friend with a somewhat unreliable news feed. Thanks for your patience, Rich =============================================== Sorry if you have seen this before, but my news feed has been flakey lately and I haven't seen it posted. Hi. I have some questions about bootp that someone out there might be able to answer. Is the bootp 2.1 (cmu) the must current version? What other versions are there out there (and where can I get them)? Is bootp the most widely used protocol to boot up network devices? Are there others? Has anyone run up against the 64 byte limitation of vendor specific data? If so, what did you do you about it? What is the method for specifying a vendor magic cookie (do you have to modify the boop server source?). Thanks any information will be appreciated! If I get responses, I will post the replies. Emily Hipp ehipp@wrs.com
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 91 22:27:23 GMT From: CCMARKM@UMCVMB.MISSOURI.EDU (Mark Moody) To: comp.protocols.tcp-ip Subject: Weird Iron
Greetings, I work in the NOC for MOREnet a new network and some of our members are bringing up TCP/IP implementations on ... some less common systems. I am looking for people who have worked with TCP/IP on systems like these and who would be willing to anwser some questions as they (will) arise down the road here. The systems in question are: an IBM AS/400 Model B55, a HP 3000 Series 58 running MPE-V operating system, and a Unisys mainframe (once a Burroughs) 'A' series A6KX. I personnaly don't have any experience with these but I would like to find *some* help for them. If you can offer any assistance, please let me know. Many thanks, Mark Moody MOREnet - MissOuri Research and Educational network University of Missouri - Columbia CCMARKM@umcvmb.missouri.edu (preffered) mark@noc.missouri.edu (alternate)
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 01:13:01 GMT From: rc@mit-caf.MIT.EDU (Ran-Chi Huang) To: comp.protocols.tcp-ip Subject: Determination of Statistics on a Subnet
I have an application that needs to determine the following : Average Utilization Average Packet Rates Peak Packet Rates Can any netters give me some ideas as to how I can approach the problem. I already have an application that processes packets on a per-packet basis. The aim is to put all this in a C program which will generate the results I need. Please mail responses to me at "rc@caf.mit.edu" because I do not read this list often. Thanks for any pointers. rc@caf.mit.edu
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 02:43:42 GMT From: tridge@anu.oz.au (Andrew Tridgell) To: comp.windows.ms,comp.protocols.tcp-ip Subject: Re: WinQVT/Net and 3C503 DMA support
If the reason you want non-shared memory support is to run in conjunction with SUN's PC-NFS then I suggest you use the pktd.sys driver to make PC-NFS work in shared memory mode. I have done this and have successfull combined PC-NFS, windows and NCSA Telnet, all using packet drivers and shared memory. You can get the "compatibility kit" from falstaff.cwru.edu in /pub/compat.kit it is called compat.zip and includes source. If you have troubles setting it up you can send me mail --- Andrew Tridgell tridge@aerodec.anu.edu.au
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 04:05:00 GMT From: HARISH@ITIVAX.BITNET To: comp.protocols.tcp-ip Subject: Question on FTP's MAC/NDIS driver + WinQVTNet
Folks, I have machines that run 3Com's 3+Open (LAN Manager) and have been trying without too much success to use FTP Software's MAC/NDIS to Packet Driver translator to provide a PktDrvr interface to the MS Windows app WinQVT/Net. WinQVT/Net works just fine when I load up the normal packet drivers and the PKTINT (provided by WinQVT/Net). However, I am then not able to get to my servers. Any suggestions? Please respond by e-mail. I'll summarize. Thanks. -- Harish Pillay harish@itivax.bitnet Senior Software Engineer harish@ece.orst.edu CSA Research Pte Ltd harish%temasek.uucp@cs.orst.edu 12 Science Park Dr #03-01 Singapore 0511 +65-772-0393 (w), +65-278-4191 (h)
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 12:15:21 MST From: haas%basset.utah.edu@cs.utah.edu (Walt Haas) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: 10BaseT installation
In article <1991Apr3.153750.19033@jhereg.osa.com> andrew@jhereg.osa.com (Andrew C. Esh) writes: > >If anyone is interested, I can write a longer posting on the ins and outs >of 10baseT, and the experiences I and my co-workers have had with it. I'd be interested. We have started to do 10BASE-T for offices where there is little chance that a second computer will be added. Thinnet still wins for student bullpens and labs with lots of machines in one room. The cost to us is about $300 + wiring per computer for 10BASE-T. Thinnet cost is a little more than half that. The big win with 10BASE-T is the situation where a computer locked in somebody's office goes nuts and starts to hose the network, or where somebody unplugs their cable. With 10BASE-T we don't have to check every office, we just check the hub, and wiring faults are dealt with automatically. In engineering offices where there are likely to be additional computers we still like the hub idea, but set up a multiport thinnet repeater and assign a port to an office. This gives us the same automatic recovery from wiring faults, at a slightly greater cost per office than 10BASE-T, with the chance to inexpensively add up to 14 more computers per office. -- Walt Haas haas@ski.utah.edu
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 08:11:08 GMT From: woody@ucscb.UCSC.EDU (Bill Woodcock) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: 10BaseT installation
> I have read a lot about 10BaseT and I am
> considering using it in a new facility.
> Everything I see has the twisted pair connector
> as a RJ45 but inplications are that twisted pair
> uses two pair or four wires. My question is how
> many pair do I need and if it is two pair why
> does 10BaseT use an RJ45 connector.
10BASE-T does indeed use four conductors. On an RJ-45 modular jack,
pin 1 is Rx+, pin 2 is Rx-, pin 3 is Tx+, and pin 6 is Tx-. When you
go to your wiring closet, they are normally punched down in that order
as well, pin 1 to row 1, pin 2 to row 2, pin 3 to row 3, and pin 6 to
row 4.
As to why 10BASE-T uses an RJ-45, I know of a couple of reasons, but I
don't know that any of them are "official." First and most important,
it's to keep people from plugging their phones into data jacks, and
vice versa. Secondly, it's to allow for people in the future plugging
their phones into data jacks, but making it work. You'll find that
ISDN normally uses pins 4, 5, 7, and 8.
-Bill Woodcock
BMUG NetAdmin
_______________________________________________________________________________
0000 : 0600 0800 7700 FE00 FF 0 FF8 7F 0 3 00 48 bill.woodcock.iv
0010 : CC00 7C00 0C00 1000 2800 440 8200 40
0020 : C000 4000 8000 C000 C 00 800 80 48 0 9 woody@ucscb.ucsc.edu
0030 : FF00 F000 7F80 CC00 CC 0 7 80 7 80 CC 6
0040 : CC00 7F80 9800 7800 CC00 CC0 CC 0 C 00 2355.virginia.st
0050 : CC00 CC00 FC00 CC00 CC 0 2000 10 0 7 00 C 0
0060 : CC00 CC00 CCC0 4800 2 00 1 00 2 00 48 0 9 berkeley.california
0070 : 4800 2400 1200 1000 2800 4 00 8 00 E0
0080 : 3000 6000 F000 6000 000 60 0 600 C0 0 01C 94709.1315
_______________________________________________________________________________
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 12:29:16 GMT From: kevin@exocet.mentec.ie To: comp.protocols.tcp-ip Subject: Honeywell Bull DPS700 ---> Ethernet (TCP/IP) ???
Hi Netlanders, A sister company has a Honeywell BULL DPS7000 system which needs a connection to an Ethernet lan. Does anyone know if there is a TCP/IP package available for a such a beast. As far as I can gather the system is running an operating system known as GCOS7. Also, any pointers on ethernet cards for the same would be very helpful. I realise that being an old system such hardware/software may not be available. Any help/comments greatly appreciated. thanks, Kevin. ------------------------------------------------------------------------------- Kevin O'Farrell | Internet/EUnet: Kevin@mentec.ie Technical Services Group.| Kevin@mentec.uucp Mentec Computer Systems. | PSI-Mail: PSI%272436059082::Kevin Pottery Road,Dun Laoire, | MCI-Mail: KOFARRELL / 390-4994 Co Dublin. Ireland | Voice: +353-1-858444 -------------------------------------------------------------------------------
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 14:37:37 GMT From: teb@SATURN.ACC.COM (Tom Benkart) To: comp.protocols.tcp-ip Subject: Message compression
In applications involving file transfers (FTP) over low speed lines, has anyone investigated any type of data compression on a message by message basis? I'm familiar with the header compression algorithms, but don't know of any data compression algorithms. The pay-off might not be very high, but any compression could be useful. Tom Benkart ACC
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 15:37:50 GMT From: andrew@jhereg.osa.com (Andrew C. Esh) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: 10BaseT installation
In article <5438@durin.sparta.COM> frankh@durin.laguna.sparta.com (Frank Halsema) writes: >I have read a lot about 10BaseT and I am considering using it in a new >facility. Everything I see has the twisted pair connector as a RJ45 but >inplications are that twited pair uses two pair or four wires. My >question is how many pair do I need and if it is two pair why does >10BaseT use an RJ45 connector. > > >Frank Halsema UUCP: durin!frankh >SPARTA, Inc. Internet: frankh@laguna.sparta.com >23041 de la Carlota, Suite 400 >Laguna Hills Ca, 92653 (714) 768-8161 EXT 339 (714)583-9114 FAX 10baseT tends to be used in the same "wiring closets" (IDF's) as telephone equipment, as well as the same wall plates, so I would guess the use of RJ45 is an attempt to make use of existing telephone wiring, without getting it confused with RJ11. RJ11 won't work with 10baseT jacks or transceivers, since the pairs are 1-2, and 3-6, with the lines as T+, T-, R+, and R-, respectively. Six wire RJ45 doesn't work, since you need pin 1 on the 8 wire RJ45. Pin 1 on the six conductor version connects to pin 2 of the 8 wire outlet. You have to use an 8 conductor RJ45 to plug into the 10baseT outlets and transceivers. Which plugs, punchdowns, wires, and connections you use in between the ends is your business, as long as the connections are fairly secure from EMI ingress, and the wire has at least 3 twists per foot, preferably more. You must maintain the pairs, and the polarity, obviously. Some transceivers will detect backward polarity, and reverse themselves to compensate. Regular "silver ribbon" telephone wire that they use to make desk-to-wall cords will cause collisions on a 10baseT connection. If anyone is interested, I can write a longer posting on the ins and outs of 10baseT, and the experiences I and my co-workers have had with it. -- Andrew C. Esh andrew@osa.com Open Systems Architects, Inc. Minneapolis, MN 55416-1528 So much System, (612) 525-0000 so little CPU time...
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 15:37:55 GMT From: lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) To: comp.protocols.tcp-ip,news.admin,comp.mail.misc Subject: Re: What Is Difference Between Internet And X.400 Style Names?
In article <1991Feb25.185436.11447@watserv1.waterloo.edu> broehl@watserv1.waterloo.edu (Bernie Roehl) writes: >In article <39557@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: >>Can someone please explain the difference between X.400 and Internet-style >>names of the form: USER@SITE.DOMAIN? I had thought that X.400 names >>were of the form /THIS=,/THAT=,/ANDWHATEVER=. > >They are. The standard syntax "user@site.domain" is used throughout the >Internet (and beyond!). The "/this=,that=" is unique to X.400, which is >part of the OSI spec. In any case, part of the confusion is the assumption that a standard's address format must be what is presented to the user. This isn't true. It's quite legal for a single system to have, say, an X.400 mailer, an SMTP (internet) mailer, and a UUCP mailer installed. The usual result would be that the poor users have to figure out for themselves which of the mailers talks to a given machine, and use the correct syntax for that mailer. Sendmail typically comes configured to require this. But this is extremely user-hostile, and there is no real excuse for it. It is quite legal, and not hard to program, to have the user interface accept addresses in multiple formats, parse them, figure out which of the mailers can handle a job, and convert the address to that mailer's format. This is, for example, what the smail package does. Sendmail also has the capability (if you can figure out how to change sendmail.cf to do it right ;-), and some vendors even supply sendmail configured to do this. Forcing the user to figure out bizarre mail syntaxes is inexcusable in these days of mass email confusion. That's what we have computers for. If your mail interface can't do the translation, you should harass your vendor until they get it right.
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 20:15:25 GMT From: albers@ka3ovk (Jon Albers) To: comp.dcom.modems,comp.protocols.tcp-ip Subject: Anyone gotta netblazer
We just got 2 Netblazers (2 serial, 2 ethernet cards, 1 T2500) to evaluate here. We have 2 networks to link via the T2500 and phone line: The ssi network consists of: 100.30.0.1 ssi <-- The netblazer at ssi. 100.30.0.5 irs5 <-- Unix mini 100.30.0.6 irs6 <-- Unix mini 100.30.0.8 irs8 <-- Unix mini 100.30.0.10 ka3ovk <-- SCO Unix micro 100.30.0.11 w3wox <-- SCO Unix micro The bxr network consists of: 89.0.0.1 sys95 <-- Unix mini 89.0.0.2 sys85 <-- Unix mini 89.0.0.3 bxr <-- The netblazer at bxr. Now, the netblazers at both networks are set up and working as terminal servers. I can log in and telnet from the netblazer to any other host on the LOCAL network, and any other host on the LOCAL network can telnet to the LOCAL netblazer. Convincing the netblazer to connect the 2 networks together has been difficlut. I think we have followed the directions in the manual OK, but any attempt to cannect to a host on the 89.x.x.x net from the ssi netblazer still causes it to look out the LOCAL ethernet and vice versa. When I log into the netblazer, and do a 'session dial bxr', it complains that 'no dialout lines are available', although the dialup is defined properly as far as Ican tell. Has anyone set up a netblazer yet!?! I have several calls into our local Telebit office, but I have not gotten a call back in 2 days of trying.. Jon -- | Jon Albers, IRS, Information Systems Management, Support and Installation. | | Office Symbols: ISM:S:S:SI voice: (202/FTS)535-3729 Packet: KA3OVK@N4QQ | | UUCP:(media|teemc|tcsc3b2|ki4pv)!ka3ovk!albers ARPA: JALBERS@SIMTEL20 |
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Wed, 3 Apr 91 21:34:18 GMT From: chlebosc@nadia.stgt.sub.org (Claudius Chlebosch) To: comp.os.os2.programmer,comp.protocols.tcp-ip Subject: Problems with IBMs TCP/IP V1.1 for OS/2
I got some problems with IBMs TCP/IP V1.1 for OS/2 using stream sockets an i hope to get some help on this way. I have to write a program, which transfers data using stream sockets in portions of 32 kByte. The sender should send this portions with one call to the send() function and the receiver should get this portions with one call to the recv() function. This works very well, if the size of the transmitted segments does not exceed about 6000 bytes and only one segment is transferred using the same socket. In the other case the receiving program has to call the function recv() several times to get the complete segment. Normally the recv() function should block the process, until the whole segment is reveived. For example: the client calls send() with the msgLen set to 20000. The server calls the recv() function, which blocks the process, until the whole 20000 bytes are received. The client calls send() once again with the msgLen set to 20000. The server calls the recv() function, which returns with 4360 bytes received. The client has to call the recv() function once again to get the remaining 15640 bytes of the segment. In my opinion this behaviour is not correct. second problem: If the server an the client reside in the same machine, no fragmentation is detected, if the size of the transmitted segments is less than the receivebuffersize (which is 23360 bytes as reported by the function getsockopt() ). This beviaour does not change, even if the receivebuffersize of the receiving socket and the sendbuffersize of the sending socket are increased via the setsockopt() call. The border at which fragmentation begins remains at 23360 bytes. My configuration is: two IBM PS/2 (mod 80 and mod 50Z) both with an Token-Ring adaptercard 16/4 A and OS/2 1.2 EE CSD:4098 and TCP/IP V1.1 for OS/2 (Program number: 5798-RXW Part Number : 66F5612). The mtu parameter of the TCP/IP is set to 4400 as it is recommended in the documentation. I hope somebody can give me a hint how i can solve this problem. Thanx for reading this message. Klaudius Chlebosch -- Klaudius Chlebosch | usenet: ..chlebosc@nadia.stgt.sub.org Eschenweg 1 | Mailbox: *49 711 484464 24 h 1200/2400 Baud D-7045 Nufringen | *49 711 461592 24 h 1200/2400 Baud Tel.: *49 7032 82023 |
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 00:26:58 GMT From: ted@blia.sharebase.com (Ted Marshall) To: comp.protocols.tcp-ip Subject: Re: Problems with TCP, read(), and write()
The problem is that TCP is a pure stream protocol that does not preserve
record boundries. Thus, if something delays the processing on some of the
bytes from one of your write()s, your read can easily complete with only the
beginning of what we written.
Since you know that all "records" are 32 bytes, there is a real easy solution:
if your read() completes with less than 32 bytes, add that count to your
buffer pointer, subtract the count from your buffer size, and repeat the read.
Continue this loop until your buffer is full. For example:
ptr = &buffer[0];
cnt = sizeof buffer;
do
{
i = read(d, ptr, cnt);
if (i <= 0)
<error-processing>
ptr += i;
cnt -= i;
} while (cnt > 0);
--
Ted Marshall ted@airplane.sharebase.com
ShareBase Corp., 14600 Winchester Blvd, Los Gatos, Ca 95030 (408)378-7000
The opinions expressed above are those of the poster and not his employer.
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 01:42:30 GMT From: lee@locus.com (Lee Slaughter) To: comp.protocols.tcp-ip Subject: tn connect closed
On a foreign site, over which we have no control, people need to telnet in from here. An irritating problem that sometimes occurs is "Connection closed by foreign host" right after the login screen (on foreign site) appears. Frequent retries then usually succeed. (debug output shows nothing except some terminal negotiation) I know there are many things (on the foreign site) that can cause this but what can we suggest to the administrator of that foreign site in the way of configuration things to check there. I don't know of any way we can tell from here. Please e-mail me as I can't usually keep up with this group. thanks............. lee@locus.com
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 03:15:06 GMT From: caserta@athena.mit.edu (Francesco Caserta) To: comp.protocols.tcp-ip Subject: finger weather
The Department of Atmospheric Sciences, University of Washington
provides the following service, and also unusual application of finger.
Do you know of any other unusual application of finger?
(RFC742, RFC1194 and RFC1196)
finger [...]@stormy.atmos.washington.edu
[stormy.atmos.washington.edu]
Format: finger weather[-station[-type[-day]]e.g.: finger weather-SEA-zone
where: station = station for required area or hiway (default=SEA)
type = disc, zone, warn, extend (default=zone)
day = day of month forecast was issued (default=today)
Washington SEA Seattle
Oregon PDX Portland
Northern and central California SFO San Francisco
Southern California LAX Los Angeles
Hawaii HNL Honolulu
Nevada RNO Reno
Idaho BOI Boise
Montana GTF Great Falls
Wyoming CYS Cheyenne
Utah SLC Salt Lake City
Arizona PHX Phoenix
Colorado DEN Denver
New Mexico ABQ Albuquerque
North Dakota BIS Bismark
South Dakota FSD Sioux Falls
Nebraska OMA Omaha
Kansas TOP Topeka
Oklahoma OKC Oklahoma City
Western Texas LBB Lubbock
Northern Texas FTW Fort Worth
Southern Texas SAT San Antonio
Minnesota MSP Minneapolis
Iowa DSM Des Moines
Missouri STL St. Louis
Arkansas LIT Little Rock
Louisiana NEW New Orleans
Mississippi JAN Jackson
Wisconsin MKE Milwaukee
Michigan ARB Ann Arbor
Illinois CHI Chicago
Indiana IND Indianapolis
Ohio CLE Cleveland
Kentucky SDF Louisville
Tennessee MEM Memphis
Alabama and northwest Florida BHM Birmingham
Georgia ATL Atlanta
Florida (except northwest) MIA Miami
South Carolina CAE Columbia
North Carolina RDU Raleigh
Virginia RIC (issued by WBC)
West Virginia CRW Charleston
DC and vicinity WBC Washington
Western Pennsyvania PIT Pittsburgh
Eastern Pennsyvania PHL Philadelphia
Western New York BUF Buffalo
Interior eastern New York ALB Albany
S.E. New York and N. New Jersey NYC New York City
Southern New England states BOS Boston
Vermont BTV (issued by ALB)
New Hampshire CON (issued by PWM)
Maine PWM Portland
Francesco Caserta
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 05:23:06 GMT From: faunt@CISCO.COM (Doug Faunt N6TQS 415-688-8269) To: comp.protocols.tcp-ip Subject: 10BaseT installation
We use 10BaseT here, on RJ-11's. We use mass termination on the 10BaseT hubs, to 66 blocks, and cross connect to the 2nd and third pairs of the RJ-11's. We use a custom cable to connect the RJ11 to the MAU, which we have made up for, I think, $8.00. We don't do it, but you could run a telephone connection on the first pair, and 10BaseT on the other two pairs simultaneously. I have a couple of adapters somewhere around that will do that out of one RJ11.
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 11:41:20 GMT From: solensky@animal.clearpoint.com (Frank T. Solensky) To: comp.protocols.tcp-ip Subject: Re: Message compression
In article <9104031437.AA14650@saturn.acc.com> teb@SATURN.ACC.COM (Tom Benkart) writes: In applications involving file transfers (FTP) over low speed lines, has anyone investigated any type of data compression on a message by message basis? I'm familiar with the header compression algorithms, but don't know of any data compression algorithms. The pay-off might not be very high, but any compression could be useful. One of the problems with a number of data compression algorithms (eg: Lempel-Ziv encoding, the one used by the Unix 'compress' command) is that they need to be able to look at the entire data stream before being able to compress any part of it. In this case, it would be about the same as running compress yourself and then FTPing the resulting file. Another approach would be to use something like an adaptive Huffman code (the details of which I know nothing about). The '/usr/old/compact' command on Sun's Release 4.1 takes this approach by encoding the data as it is being read in and sending it out immediately. The man page lists the following reference (and also indicates that the command will NOT be distributed or supported in future releases): Gallager, Robert G., Variations on a Theme of Huffman, IEEE Transactions on Information Theory, vol.IT-24, no. 6, Novermber 1978, pp. 668-674. I believe that the Applications Area of the Internet Engineering Task Force is planning to look into improvements to FTP such as this at some point in the near future, but I'm afraid I don't know what the time frames or immediate plans are. -- -- Frank Solensky / Clearpoint Research Corp. Red Sox magic number: 163
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 14:37:00 GMT From: 0004219666@MCIMAIL.COM (Bob Stine) To: comp.protocols.tcp-ip Subject: Re: Problems with TCP, read(), and write()
>I am having problems with TCP, write(), and read(). I want to send and
>receive 32 byte structures....
>My problem is that if I do no put a sizeable delay in the
>send or receive loop, I end up receiving only part of a 32 byte chunk
>after a number of chunks have been received.
Shawn,
As you have discovered, TCP does not preserve record boundaries. One
work-around makes use the value returned by read(), which is the number of the
bytes read. Keep reading until you get your entire 32 bytes. I.e.,
int bf_ln, /* number of bytes requested */
bc, /* byte count returned by read() */
s; /* socket */
struct shawns_struct { /* whatever, 32 bytes worth */} in_rec;
char *bptr;
/* get the connection. Then, to load a structure... */
bf_ln = sizeof(struct shawns_struct);
bptr = (char *) in_rec;
while (bf_ln)
{
bc = read(s,bptr,bf_ln);
if (bc < 1)
exit(-1);
bf_ln -= bc;
bptr += bc;
}
Note that I exit if read() returns a value of zero. In BSD, select() will
indicate that a closed socket is ready to read, but read() will return zero
bytes. Hence, if the above loop didn't exit when read() returned a zero, then
a closed socket would keep it busy for quite some time... :-)
Regards,
Bob Stine
bstine@MCIMail.com
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 15:23:45 GMT From: andrew@jhereg.osa.com (Andrew C. Esh) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: 10BaseT installation
From the response, both here and in EMail, this sounds like a really hot subject. I will put together as much as I can, and post it soon. -- Andrew C. Esh andrew@osa.com Open Systems Architects, Inc. Minneapolis, MN 55416-1528 So much System, (612) 525-0000 so little CPU time...
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 16:10:19 GMT From: oleg@watson.ibm.com To: comp.os.os2.programmer,comp.protocols.tcp-ip Subject: Re: Problems with IBMs TCP/IP V1.1 for OS/2
In <ZSNPX4T@nadia.stgt.sub.org> chlebosc@nadia.stgt.sub.org (Claudius Chlebosch) writes: > I got some problems with IBMs TCP/IP V1.1 for OS/2 using stream sockets an i > hope to get some help on this way. > > I have to write a program, which transfers data using stream sockets in portions > of 32 kByte. The sender should send this portions with one call to the send() > function and the receiver should get this portions with one call to the recv() > function. > This works very well, if the size of the transmitted segments does not exceed ab > 6000 bytes and only one segment is transferred using the same socket. In the > other case the receiving program has to call the function recv() several times > to get the complete segment. Normally the recv() function should block the proce > until the whole segment is reveived. No, it is not how recv()/send() work. You can't make any assumptions on size of segments that you get with recv(). Also, there is 8K per call limit on send/recv in OS/2 TCP/IP implementation. [TEXT DELETED] > second problem: > If the server an the client reside in the same machine, no fragmentation is > detected, if the size of the transmitted segments is less than the > receivebuffersize (which is 23360 bytes as reported by the function getsockopt() > ). This beviaour does not change, even if the receivebuffersize of the > receiving socket and the sendbuffersize of the sending socket are increased via > the setsockopt() call. The border at which fragmentation begins remains at > 23360 bytes. What do you mean by fragmentation, and what is the problem here ? [TEXT DELETED] > Klaudius Chlebosch | usenet: ..chlebosc@nadia.stgt.sub.org Oleg Vishnepolsky
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Thu, 4 Apr 1991 18:02:39 GMT From: henry@zoo.toronto.edu (Henry Spencer) To: comp.protocols.tcp-ip Subject: Re: Message compression
In article <SOLENSKY.91Apr4114120@animal.clearpoint.com> solensky@animal.clearpoint.com (Frank T. Solensky) writes: >One of the problems with a number of data compression algorithms >(eg: Lempel-Ziv encoding, the one used by the Unix 'compress' command) >is that they need to be able to look at the entire data stream before >being able to compress any part of it... Telebit would be very surprised to hear this; all their modems do Lempel-Ziv compression on the fly. No, LZ does *not* need to look at the entire data stream before being able to compress any part of it. -- "The stories one hears about putting up | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 are all true." -D. Harrison| henry@zoo.toronto.edu utzoo!henry
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 18:05:41 GMT From: solensky@animal.clearpoint.com (Frank T. Solensky) To: comp.protocols.tcp-ip Subject: Re: Message compression
In article <1991Apr4.180239.12442@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: Telebit would be very surprised to hear this; all their modems do Lempel-Ziv compression on the fly. No, LZ does *not* need to look at the entire data stream before being able to compress any part of it. Faux pas, mea culpa, *sigh*! Looking at the man page again, I see that the "compress" command does indeed use an _adaptive_ LZ coding.. The main point I wanted to make was that the IETF is, at least, aware of the desire for compression within FTP. -- -- Frank Solensky / Clearpoint Research Corp. Red Sox magic number: 163
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 18:21:15 GMT From: metzger@watson.ibm.com (Perry E. Metzger) To: comp.protocols.tcp-ip Subject: Re: finger weather
In article <1991Apr4.031506.6778@athena.mit.edu> caserta@athena.mit.edu (Francesco Caserta) writes: >The Department of Atmospheric Sciences, University of Washington >provides the following service, and also unusual application of finger. >Do you know of any other unusual application of finger? The RFC for finger specifies fingers behavior when applied to coke machines. It is my understanding that CMU used to have a coke machine on the internet that followed the stated behavior, although this may be an urban legend. Perry Metzger
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 20:35:15 GMT From: dshardin@zoot.avgrp.cr.rok.com (David Hardin) To: comp.protocols.tcp-ip Subject: XTIS info?
I am looking for information on XTIS, the X/Open Transport Interface
Specification (at least, I think that's what it stands for). Is there
any info available via anonymous ftp, or do I have to contact X/Open?
Thanks in advance,
David Hardin
--
David S. Hardin Collins Commercial Avionics
Rockwell International
M/S 124-211, 400 Collins Rd. NE
INTERNET: dshardin@zoot.avgrp.cr.rok.com Cedar Rapids, IA 52498
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 20:46:14 GMT From: ww0n+@ANDREW.CMU.EDU (Walter Lloyd Wimer III) To: comp.protocols.tcp-ip Subject: Re: Bootp questions (a possible reposting)
Emily,
> Hi.
> I have some questions about bootp that someone out
> there might be able to answer.
> Is the bootp 2.1 (cmu) the must current version?
> What other versions are there out there
> (and where can I get them)?
Bootpd 2.1 is the most recent release of bootpd from CMU. I have not
had time to work on it in quite a while, but I will again eventually.
The IETF Dynamic Host Configuration Working Group is working on a new
Dynamic Host Configuration Protocol (DHCP) based on BOOTP. I will
eventually be writing and releasing a DHCP server which will work with
DHCP clients and old BOOTP clients.
A number of people have suggested improvements to CMU's bootpd. Several
have added their own local extensions or ported it to other operating
systems (Unix System V, MS-DOS, VMS). Unfortunately, there hasn't been
much effort to coordinate these versions or gather them together in a
single place (largely my fault for being unable to devote the time). As
such, I don't really know where to find these other versions.
I know of no independently-developed BOOTP servers; all seem to be
derivations of the Stanford/CMU bootpd for BSD Unix. (Someone please
correct me if I am wrong!)
The CMU distribution of bootpd is available via anonymous FTP from
LANCASTER.ANDREW.CMU.EDU (128.2.13.21) in the file pub/bootp.2.1.tar.
This is actually a slightly newer version which calls itself 2.1a. It
includes just a few minor bug fixes which were often reported to me.
> Is bootp the most widely used protocol
> to boot up network devices? Are there others?
RARP provides another alternative for assigning IP addresses to booting
hosts. It only deals with the IP address assignment issue (unlike BOOTP
which can also pass information such as the subnet mask, default
router(s), etc.). RARP is a link-layer protocol, so it cannot work
across routers like BOOTP can.
There are other protocols which deal with various aspects of the network
boot problem. The DHC "Problem Statement" Internet Draft touches on
some of them. This was available via anonymous FTP from NNSC.NSF.NET in
the internet-drafts/ directory, but seems to have disappeared (it
probably expired).
> Has anyone run up against the 64 byte limitation
> of vendor specific data? If so, what did you
> do you about it?
Yes, CMU certainly has and I know others have. The DHCWG is trying to
address this problem as well. One suggestion has been to modify both
BOOTP clients and servers to simply send larger packets. In many
instances, the network manager knows the minimum MTU (Maximum
Transmission Unit) between the BOOTP server and a given client. The
BOOTP server could be configured with this information and could then
send a packet up to that size.
I must stress that, so far, this is only a suggestion and is not
guaranteed to work in all environments, etc., etc.
Another suggestion is to use the vendor field to communicate a file name
containing configuration information and then use TFTP or something to
transfer that file.
> What is the method for specifying a vendor
> magic cookie (do you have to modify
> the boop server source?).
Yes; this is really the only way if you don't want to use the CMU or
RFC1084/RFC1048 formats. Bootpd does contain some code to let you
specify an arbitrary vendor magic cookie, but there is no way to then
specify what actual information should go in the remaining 60 octets.
This is one of those features that was sort-of half-implemented and then
forgotten/abandoned.
Note that you can stick with RFC1084/RFC1048 format and define your own
custom tags with the generic tag ":Tn=xxxx:" bootptab construct. From
RFC1084:
Reserved Fields (Tag: 128-254, Data: N bytes of undefined
content)
Specifies additional site-specific information, to be
interpreted on an implementation-specific basis. This
should follow all data with the preceding generic tags 0-
127).
> Thanks any information will be appreciated!
> If I get responses, I will post the replies.
There is also a mailing list devoted to open discussion about BOOTP and
questions such as yours. The submission address is:
bootp@andrew.cmu.edu
In the Internet tradition, please send requests to be added to or
removed from the mailing list to:
bootp-request@andrew.cmu.edu
> Emily Hipp
> ehipp@wrs.com
Walt Wimer
Network Development
Carnegie Mellon University
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 23:34:08 GMT From: parr@wglen.ab.ca (Bob Parr) To: comp.protocols.tcp-ip Subject: (none)
To Whom It May Concern ... This is probably a question that has been asked and answered many times in the last six months but we've been unplugged from the USENET for the past year so I'm operating out of a news blackout. In the INTEROP 1991 brochure that advertises Doug Comer's TCP/IP Internals and Implementation tutorial mention is made of his book "Internetworking with TCP/IP: Design, Implementation, and Internals, Vol 2". On a recent business trip to the Bay Area I stopped in at the Stanford Bookstore to see if this book was available and found that it had ( as of the end of January at least ) not yet been published. If you could respond with any information as to the current or future availability of this book I would be greatly appreciative. Thanks in advance, Bob Parr SCADACOM Product Manager Willowglen Systems Ltd. Calgary, Alberta, Canada Tel: (403)-272-1800 Fax: (403)-272-2114 parr@wglen.ab.ca
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 23:50:41 GMT From: rsk@hazel.circ.upenn.edu (Rick Kulawiec) To: comp.protocols.tcp-ip Subject: Re: finger weather
In article <1991Apr4.182115.3531@watson.ibm.com> metzger@watson.ibm.com (Perry E. Metzger) writes: >The RFC for finger specifies fingers behavior when applied to coke >machines. It is my understanding that CMU used to have a coke machine >on the internet that followed the stated behavior, although this may >be an urban legend. I think it was for real...the three notes below cover the story, and are probably worth reposting here since it's been a while since they first appeared. ---Rsk Originally-From: tgl@zog.cs.cmu.edu (Tom Lane) Original-Newsgroups: alt.folklore.computers Original-Subject: The only Coke machine on the Internet Original-Date: 11 Dec 89 15:45:34 GMT This story is old news to ex-CMU folk, but may be amusing to others. Since time immemorial (well, maybe 1970) the Carnegie-Mellon CS department has maintained a departmental Coke machine, which sells bottles of Coke for a dime or so less than other vending machines around campus. As no Real Programmer can function without caffeine, the machine is very popular. (I recall hearing that it had the highest sales volume of any Coke machine in the Pittsburgh area.) The machine is loaded on a rather erratic schedule by grad student volunteers. In the mid-seventies expansion of the department caused people's offices to be located ever further away from the main terminal room where the Coke machine stood. It got rather annoying to traipse down to the third floor only to find the machine empty; or worse, to shell out hard-earned cash to receive a recently loaded, still warm Coke. One day a couple of people got together to devise a solution. They installed microswitches in the Coke machine to sense how many bottles were present in each of its six columns of bottles. The switches were hooked up to CMUA, the PDP-10 that was then the main departmental computer. A server program was written to keep tabs on the Coke machine's state, including how long each bottle had been in the machine. When you ran the companion status inquiry program, you'd get a display that might look like this: EMPTY EMPTY 1h 3m COLD COLD 1h 4m This let you know that cold Coke could be had by pressing the lower-left or lower-center button, while the bottom bottles in the two right-hand columns had been loaded an hour or so beforehand, so were still warm. (I think the display changed to just "COLD" after the bottle had been there 3 hours.) The final piece of the puzzle was needed to let people check Coke status when they were logged in on some other machine than CMUA. CMUA's Finger server was modified to run the Coke status program whenever someone fingered the nonexistent user "coke". (For the uninitiated, Finger normally reports whether a specified user is logged in, and if so where.) Since Finger requests are part of standard ARPANET (now Internet) protocols, people could check the Coke machine from any CMU computer by saying "finger coke@cmua". In fact, you could discover the Coke machine's status from any machine anywhere on the Internet! Not that it would do you much good if you were a few thousand miles away... As far as I know nothing similar has been done elsewhere, so CMU can legitimately boast of having the only Coke machine on the Internet. The Coke machine programs were used for over a decade, and were even rewritten for Unix Vaxen when CMUA was retired in the early eighties. The end came just a couple years ago, when the local Coke bottler discontinued the returnable, coke-bottle-shaped bottles. The old machine couldn't handle the nonreturnable, totally-uninspired-shape bottles, so it was replaced by a new vending machine. This was not long after the New Coke fiasco (undoubtedly the century's greatest example of fixing what wasn't broken). The combination of these events left CMU Coke lovers sufficiently disgruntled that no one has bothered to wire up the new machine. I'm a little fuzzy about the dates, but I believe all the other details are accurate. The man page for the second-generation (Unix) Coke programs credits the hardware work to John Zsarnay, the software to David Nichols and Ivor Durham. I don't recall who did the original PDP-10 programs. tom lane ========== Orginally-From: sgw@cad.cs.cmu.edu (Stephen Wadlow) Orginal-Newsgroups: alt.folklore.computers Orginal-Subject: Re: The only Coke machine on the Internet Orginal-Date: 11 Dec 89 20:26:30 GMT In article <7295@pt.cs.cmu.edu> tgl@zog.cs.cmu.edu (Tom Lane) writes: >This story is old news to ex-CMU folk, but may be amusing to others. [story of the CMU coke machine] At the annual Jimmy Tsang's dinner expedition last saturday, I was talking with a member of the CS Facilities staff [Hi Steve :-)] who is currently working on the new hardware for the coke server. In addition to monitoring the status of the coke machine, the new server will re-implement the JF (junk food) protocol, telling you the status of the CS M&M dispenser and other CS-affiliated junk food dispensers. It's hoped that this will all be finished and installed by early next year, such that any internet site will be able to finger coke@cs.cmu.edu once again. An addendum to the coke story is that for quite sometime there was a Perq sitting behind a large glass window in front of the elevators on the third floor of science hall that frequently ran a variation of the coke program that would display bar graphs indicating the amount of time since the machine had been filled. You now didn't even have to be logged in to find out if the coke was cold, rather you could just be riding by on the elevator and decide on the fly if you wanted to grab a cold coke. You used to (and still may) be able to finger weather@hermes.ai.mit.edu to find out what the weather was like on the 9th floor of tech square (the ai labs). steve ========== Originally-From: colbath@cs.rochester.edu (Sean Colbath) Original-Newsgroups: alt.folklore.computers Original-Subject: Re: The only Coke machine on the Internet Original-Date: 11 Dec 89 19:01:21 GMT I don't think the students at RIT (Rochester Institute of Technology) get this newsgroup, so I'll relate this (true) story. At UR, there is an organization known as the Computer Interest Floor, an area of campus housing where computer oriented people can get together. RIT has a similar organization, known as CSH (Computer Science House, or...). Many of their members are quite hardware oriented. Well, apparently they found an old slightly malfunctioning coke machine that was being thrown out (can-style). They decided to install this on their hall, but were informed by the powers that be that the university had granted a monopoly on vending machines to a city vending machine service, and they couldn't set it up. So, they decided to come up with a way to get around this rule: they changed the coke machine from a vending machine to a peripheral! The vending machine has a serial line running from it to one of the unix systems. It looks much like a regular machine, except it has a red calculator-like display that says "Coke" on it. If you press a button, it'll tell you how many sodas are in that particular bin, or "Empty". Next to it is a terminal with the time of day displayed, and a coke logo. To buy a coke, all you have to do is to "log on" to your coke machine account at the terminal, look at the status report, and "buy" your coke by selecting from a menu. Each user had a bank account that was added to by giving the machine maintainers more money. Now, this isn't all -- you could buy your coke from any terminal in their housing section (every room had one, and they had two semi-public terminal areas. If you wanted to, you could program in a delay before the machine dropped your coke, so you wouldn't get down the hall to find someone had snarfed your coke. Apparently they wanted coke to come do a commercial showing someone hacking on a terminal, pausing with a thirsty look on their face, type "coke", race down the hallway, and arrive just in time to have the machine plop a soda in their hand...! Sean Colbath colbath@cs.rochester.edu ...uunet!rochester!colbath
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 01:27:07 GMT From: mikem@ibmpa.awdpa.ibm.com To: comp.os.os2.programmer,comp.protocols.tcp-ip Subject: Re: Problems with IBMs TCP/IP V1.1 for OS/2
In article <ZSNPX4T@nadia.stgt.sub.org> chlebosc@nadia.stgt.sub.org (Claudius Chlebosch) writes: >I got some problems with IBMs TCP/IP V1.1 for OS/2 using stream sockets an i >hope to get some help on this way. > >I have to write a program, which transfers data using stream sockets in portions >of 32 kByte. The sender should send this portions with one call to the send() >function and the receiver should get this portions with one call to the recv() >function. No. You can *not* code your client program to expect that a block of bytes sent by your server will arrive in a single receive. It doesn't matter what TCP/IP implementation you use. To do so is to cripple your client. What you need to do is place some sort of signature byte so that your client knows when the data block is complete and can process that block at that time. Michael R. MacFaden IBM Palo Alto Marketing Systems mikem@ibmpa.awdpa.ibm.com, macfaden@paloic1.vnet.ibm.com disclaimer: what I write above is not necessarily my employer's opinion
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 04:50:55 GMT From: ww0n+@ANDREW.CMU.EDU (Walter Lloyd Wimer III) To: comp.protocols.tcp-ip Subject: Re: Message compression
> Excerpts from internet.tcp-ip: 4-Apr-91 Re: Message compression Frank T. > Solensky@ucsd.e (1666) > One of the problems with a number of data compression algorithms > (eg: Lempel-Ziv encoding, the one used by the Unix 'compress' command) > is that they need to be able to look at the entire data stream before > being able to compress any part of it. In this case, it would be about > the same as running compress yourself and then FTPing the resulting file. From empirical evidence, I don't believe this is true. The 'compress' program can read from a pipe. I've used this feature to create a compressed tar file of a directory tree in a single step: tar -cf - somedirectory | compress -c > somedirectory.tar.Z Granted, it could be buffering quite a bit of data in virtual memory, but I doubt it was buffering the 90 megabytes worth of data from one particular tar I remember. (My system only has 64 megs of swap space. . . .) Recently, there was also an excellent posting to the comp.sources.unix newsgroup concerning compression techniques. It included a draft of a paper on the workings of various compression algorithms, including a newly-invented variant of Lempel-Ziv which the author seems to claim is free of patent (he calls it "Y-coding"). While I know and understand very little about compression techniques, a brief reading of the paper seems to suggest that these compression techniques work quite well even applied to (relatively small) finite-sized chunks of data. An implementation of the new algorithm is included in the posting. Walt Wimer Network Development Carnegie Mellon University
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 07:55:01 GMT From: romkey@ASYLUM.SF.CA.US (John Romkey) To: comp.protocols.tcp-ip Subject: finger weather
Date: 4 Apr 91 18:21:15 GMT From: decwrl!uunet.uu.net!bywater!arnor!halley!metzger (Perry E. Metzger) The RFC for finger specifies fingers behavior when applied to coke machines. It is my understanding that CMU used to have a coke machine on the internet that followed the stated behavior, although this may be an urban legend. No, it's true. CMU did have a coke machine on the Internet. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice/fax: 415 594-1141
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 08:03:32 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: Bootp questions (a possible reposting)
In article <Ibyt2Ki00WCp44dZAH@andrew.cmu.edu> ww0n+@ANDREW.CMU.EDU (Walter Lloyd Wimer III) writes:
>RARP provides another alternative for assigning IP addresses to booting
>hosts. It only deals with the IP address assignment issue (unlike BOOTP
>which can also pass information such as the subnet mask, default
>router(s), etc.). RARP is a link-layer protocol, so it cannot work
>across routers like BOOTP can.
Why couldn't an RARP server rebroadcast the RARP request on another subnet,
and then forward the response back to the original host? BOOTP's "routing"
is done at the application layer, because IP-layer routing requires the
client to know most of the information it is trying to find out from the
BOOTP server. Since BOOTP does its routing at the application layer, so
could RARP.
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 08:12:03 GMT From: francis@zaphod.uchicago.edu To: comp.protocols.tcp-ip Subject: FTP site for RFCs?
Is there an FTP site with RFCs? I'm kinda interested in seeing the protocol specs for the stuff I'm using, but I'm just a student (not even a CS student at that :-), so I don't have any clue about who handles this stuff. -- /============================================================================\ | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | Earth: Love it or leave it. | | francis@zaphod.uchicago.edu | | \============================================================================/
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 11:59:00 GMT From: CSP1DWD@MVS.OAC.UCLA.EDU (Denis DeLaRoca 825-4580, 213) To: comp.protocols.tcp-ip Subject: Re: Re: finger weather
Alas, the weather finger service at <stormy.atmos.washington.edu> is not more, it's been replaced by an equivalent RPC-based service. The RPC-client source code can be obtained by fingering "weather" at the above host. -- Denis
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Fri, 5 Apr 1991 14:20:41 GMT From: dcarr@hobbit.gandalf.ca (Dave Carr) To: comp.protocols.tcp-ip Subject: Re: Message compression
In <1991Apr4.180239.12442@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <SOLENSKY.91Apr4114120@animal.clearpoint.com> solensky@animal.clearpoint.com (Frank T. Solensky) writes: >>One of the problems with a number of data compression algorithms >>(eg: Lempel-Ziv encoding, the one used by the Unix 'compress' command) >>is that they need to be able to look at the entire data stream before >>being able to compress any part of it... >Telebit would be very surprised to hear this; all their modems do >Lempel-Ziv compression on the fly. No, LZ does *not* need to look at >the entire data stream before being able to compress any part of it. >-- I agree with Henry. LZW type algorithms can me made to adapt very quickly by adjusting the number of characters learned after each match. For example, V.42 bis data compression has the number of characters learned as a settable parameter (N8 I believe). As for speed, LZW can be made very fast. After all, it was designed with disk controller applications. The main problem with LZW is expanding uncompressable (or precompressed) data. Again, this is addressed with V.42 bis (but not with standard LZW). If the compressor can handle the uncompressable cases without expansion (or minimize the expansion), then TCPIP compression is a winning solution. Couple this with Van Jacobson's header compression, (or better the one which we will soon debut) and you can get substantial compression. I won't quote compression rates and spoil the marketting peoples fun. BTW Henry, does Telebit use LZW, LZSS, or LZH ?
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 15:06:54 GMT From: smith@newsserver.sfu.ca (Richard Smith) To: comp.protocols.tcp-ip Subject: Re: finger weather
Here is what fingering "coke" will get you now: [cs.cmu.edu] [ Forwarding coke as "gripe@vega.fac.cs.cmu.edu" ] [VEGA.FAC.CS.CMU.EDU] Login name: gripe In real life: Gripe Directory: /usr1/gripe Shell: /usr/cs/bin/csh Last login Tue Mar 5 10:22 on ttyP7 from GLN.FAC.CS.CMU.EDU Mail came on Fri Apr 5 09:57, last read on Fri Apr 5 09:01 Plan: CS/RI User Services Software and hardware requests, bug reports and fixes, general questions about the facility -- all of these can be sent to "gripe". Gripe mail is *NOT* constantly monitored. If you have a problem which requires immediate attention, please call the CS Operator (x2607).
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 15:53:17 GMT From: ypinn@gpu.utcs.utoronto.ca To: comp.protocols.tcp-ip,comp.protocols.ibm Subject: TCP/IP tunnelled in IBM/SNA
As hideous as this may sound, is there a UNIX TCP/IP implementation that has this capability? In order for this to work, the UNIX box would need to support SDLC based links, SNA services, and TCP/IP tunnelled through SNA using an APPC. Your probably asking yourself, why does this madman want to do this? I work for a large multi-national accounting firm. Our firm uses a public mail system in Canada as the basis of their enterprise-wide mail system. My group is trying to develop a proposal to bring our mail system in house. The system would use a combination of Macintosh computers - 3000 dispersed over 60 offices - and UNIX servers. The UNIX boxes would provide the message routing between offices. Our network design for this system is based on a hub and spoke topology. The remote offices would use dial-up connections running UUCP to communicate with one of eight hubs. Now for the SNA component... We currently have SNA lines running to the eight hub locations. This newtork is well entrenched. We have suggested replacing it with multi-protocol routers which would forward SNA as well as TCP. However, the idea was flatly rejected for two reasons: its cost and the predominance of the technology blind IBM group. Hence the idea of tunnelling TCP/IP in SNA. Of course, the fallback plan would be to exchange mail between the hubs using UUCP, but, I would prefer to have a connected network in place. Does anyone have any suggestions, or comments on this issue? Your assistance would be greatly appreciated. Thanks bruce pinn Manager, NITG Peat Marwick Thorne
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 15:58:36 GMT From: mqh@theory.tn.cornell.edu (Mike Hojnowski) To: comp.protocols.tcp-ip Subject: Old TCP announces MSS of 65496. Fix available?
I'm running AIX/370 with it's built-in ancient BSD 4.3 networking code. Occasionally, it will announce an MSS of around 65496 to sites it connects to on non-local networks. Some of those sites are also running ancient networking code (Ultrix and VaxStations, notably). Those sites tend to panic when we connect to them. We'd like to be better neighbors than that, though I realize that this bug is due to problems on both ends. Is there a reasonably short source patch I can put in our networking code to keep it from announcing an MSS > 32K? I imagine the remote sites are having a problem 'cause they think the MSS is signed and are indexing into hyperspace or something. Just to add to the confusion, we run "gated" on our site. I don't know if this makes a difference or not. Please respond via Email here (this is not an AIX site, so it won't crash you :-)). I don't read this newsgroup regularly. Mike Hojnowski AIX Grunt Cornell University
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 16:01:05 GMT From: ypinn@gpu.utcs.utoronto.ca To: comp.protocols.ibm,comp.protocols.tcp-ip Subject: TCP tunnelled in IBM/SNA (more)
Apologies, but there appears to be a bug in our Pnews command so that
the From: address for my previous message - and probably this one - is
marked as ypinn@gpu.utcs.utoronto.ca. It should read either
craystn@gpu.utcs.utoronto.ca {which is the machine the note was sent from},
or you can reach me at ypinn@gauss.clsc.utoronto.ca
Thanks
bruce pinn
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 16:38:51 GMT From: hathawa@rdsunx.crd.ge.com (Barry Hathaway) To: comp.protocols.tcp-ip,comp.protocols.ibm Subject: Re: TCP/IP tunnelled in IBM/SNA
IBM's TCP/IP software supports TCP/IP tunnelled through SNA. In order to do this in your situation you would have to attach each IBM system to you TCP/IP network. This could be expensive, but it would offer additional capabilities.
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 16:43:46 GMT From: yjy@stlucia.uucp (Joe Yung) To: comp.sys.att,comp.sys.tcp-ip Subject: Re: Datakit Interface Through TCP/IP
>from: yjy@stlucia.bellcore.com (Joe Young)
Previously, I posted the following questions:
>I have a SPARC station 2 and a Datakit with a bunch of TTY modules.
>I am trying to have the SPARC connected to the Datakit so I can use
>my SPARC to access various TTY line off the Datakit.
>Does anybody know how ?
>
>I heard that AT&T Datakit has a connection to TCP/IP directly.
>We have a bunch of SPARCs on the Ethernet. It will be a
>a versatile way to open up the Datakit available to all the SPARCs.
>Does anybody know anything about this connectivity.
I have got many helps from the net.
The following is my conclusion.
There are two possible configurations.
The first configuration is the following:
-------------- Fiber Link ---------
|Sparc server| -----------------|Datakit|-------async terminals
-------------- ---------
A CPM/HS module is required on the Datakit end and a fiber interface
plus some software (DKHOST ?) is requried on the Sparc server.
Based on my experience on the 3B2-to-Datakit fiber link,
I believe this configuration will allow me to use all the fiber link features
including the datakit library.
However this configuration does not apply to the Sparcstations
because the fiber interface requires VME bus architecture which is
on the Sparcserver only.
The Sparcstations use SBUS architecture !
Another configuration is the following:
--------------
|Sparcstation|
--------------
|
| TCP/IP TCP/IP
========================== ================
| | | |
------------------------
|Datakit Interface(NIK)|
------------------------
| Fiber
| Link
Async --------- Async
Serial Printer----------|Datakit|--------async terminals
---------
The Datakit Interface(NIK) is a "telnet" service box which convert the TCP/IP
to URP protocol.
The user login from the async terminals as shown has to select
the "telnet" service on the datakit destination prompt.
This will take the connection to the NIK.
From there, a host address will be entered to connect to the sparcstation.
This configuration is only limited to telnet service.
From the Sparcstation end, type in telnet and open the NIK host connection.
The NIK host can connect to the async lines via the fiber link.
I think the sparcstation is not awared of the NIK as a gateway to the Datakit.
Here are some features provided by NIK(Thanks to Bill Hill):
*Local Routing on NIK
*Routing between LAN and remote LAN through Datakit (DK)
*Up to 4 LANs/NIK
*NIK fiber connected to DK
*Local Mngt of NIK or through StarKeeper NMS
*Capability to act as Terminal Server; a terminal or host directly
connected to DK can log onto any Ethernet LAN host connected to DK
via NIK
*Reverse terminal service; PC on LAN to Access DK hosts or Terms
Joe Yung
-----------------------------------------------------------------
Joe Yung
yjy@stlucia.bellcore.com
(908)699-5344
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 17:02:34 GMT From: smith@newsserver.sfu.ca (Richard Smith) To: comp.protocols.tcp-ip Subject: Re: finger weather
"weather" is now a RPC which will produce similar results (i.e. the weather for your locality - if you live in the U.S :->). I downloaded it and tried it - it works. ...r
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 18:12:11 GMT From: amallic@swtec1.intel.com (Asit Mallick ~) To: comp.protocols.tcp-ip Subject: MIT/CMU implementatin of SNMP
I am looking for source of a public domain implementation of SNMP. I was told that a CMU and MIT version exist. Can anyone send me information about these. Thanks in advance. email addr: amallic@swtec1.intel.com
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 18:35:03 GMT From: SSJACK@ECUVM1.BITNET To: comp.protocols.tcp-ip Subject: Two machine ethernet?
Out of curiosity, I have a question regarding 10BASET wiring: Can two PC's with 10BASET cards be wired back to back using a single twisted pair wire (RJ45s) with the transmit and receive pairs swapped via a crossover block -- effectively producing a two machine ethernet? ====================================================================== Jack E. McCoy SSJACK@ECUVM1.BITNET Systems Programmer (919) 757 - 6401 East Carolina University Greenville, NC 27858 ======================================================================
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 19:28:23 GMT From: hollings@poona.cs.wisc.edu (Jeff Hollingsworth) To: comp.protocols.tcp-ip Subject: Re: finger weather (really Coke machines)
|> |> As far as I know nothing similar has been done elsewhere, so CMU can |> legitimately boast of having the only Coke machine on the Internet. |> Here at the University of Wisconsin we were *FORCED* to computerize our Coke machine a year ago (or they would take it away). The University had given an exclusive vending contract to a local vending company. That company didn't like the fact we were under cutting their prices. But they did permit "coffee clubs" to continue. The idea was people would pay into a club and then only people who payed in could take coffee from the pot. We decided to do the same thing with our Coke machine. A small bit of hardware was built to activiate the Coke machine via a computer, and a program was written to track coke accounts and keep their balances. The coke machine was also modified so that it would NOT take money and could only be activated from the computer. So I guess Wisconsin can claim the only Coke machine that can be controlled via the Internet. ------------------------------------------------------------------------------- Jeff Hollingsworth Work: (608) 262-6617 Internet: hollings@cs.wisc.edu Home: (608) 256-4839 X.400: <pn=Jeff.Hollingsworth;ou=cs;o=uw-madison;prmd=xnren;c=US>
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 20:02:46 GMT From: hollings@poona.cs.wisc.edu (Jeff Hollingsworth) To: comp.protocols.tcp-ip Subject: Re: finger weather (really Coke machines)
!> !> As far as I know nothing similar has been done elsewhere, so CMU can !> legitimately boast of having the only Coke machine on the Internet. Here at the University of Wisconsin we were *FORCED* to computerize our Coke machine a year ago (or they would take it away). The universion had given an exclusive vending contract to a local vending company. But they did prmit "coffee clubs" to continue. The idea is that people pay into a club and then only people in the club get to drink from the coffee. We decided to do the same thing with our Coke machine. A small bit of hardware was built to activate the Coke machine via a computer, and a program was written to track coke accounts and keep their balances. The coke machine was also modified so that it would NOT take money and could only be activated from the computer. So I guess Wisconsin can claim the only Coke machine that can be controlled via the Internet. -- ------------------------------------------------------------------------------- Jeff Hollingsworth Work: (608) 262-6617 Internet: hollings@cs.wisc.edu Home: (608) 256-4839 X.400: <pn=Jeff.Hollingsworth;ou=cs;o=uw-madison;prmd=xnren;c=US>
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 23:31:40 GMT From: art@opal.acc.com (Art Berggreen) To: comp.protocols.tcp-ip Subject: Token Ring ARPs
The research community has been pushing for all MAC addresses carried as data in communication protocols to always be in cannonical format. This is at odds with older implementations for the Token Ring which were based on RFC1042 (use of SNAP). I'm curious as to if and when this might have an effect on products in the marketplace. I believe there is a large installed base that uses the RFC1042 style ARPs where the MAC addresses are in wire order. Are there any products out there that use cannonical order? Are there any coming? Does anyone have any other information? Art
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 23:50:16 GMT From: yates@UNIX1.CS.UMASS.EDU (David Yates) To: comp.protocols.tcp-ip Subject: TCP/IP mailing list
I am interested in adding my name to the TCP/IP mailing list. Is this the right e-mail stop? Thanks in advance, David
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 00:21:06 GMT From: Rudy.Nedved@RUDY.FAC.CS.CMU.EDU To: comp.protocols.tcp-ip Subject: Re: finger weather
John, You know your stuff. CMU still has a coke machine on the network. Alas because of software upgrades being constant that little trick has been divorced from the finger software. Under finger we had coke machine status and "tingle" status... At the current time we have network service for the coke machine and for our M&M machine. We have this under the "junk food" service. -Rudy
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 01:11:39 GMT From: cmilono@netcom.COM (Carlo Milono) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: 10BaseT installation
First, as was stated in an earlier post or RE:, it is *not* true that AT&T uses more than the 4 wires for 10BASE-T - four is IT for the standard and their product is standard. Secondly, it is a misnomer to use the RJ45 name for an 8-pin jack - the correct terminology is the ISO 8877 jack. The RJ stands for Registered Jack and refers to those blocks that terminate a TelCo circuit as a demarcation point to a public service. You may note that if you have a DSU or Modem with a private line, that the connector looks a bit different, possibly with a switch-selectable resistor and it will have a notch on the jack as a key for the data-set plug. Lastly, you can run your 10BASE-T on household 'quad' wire and get an appropriate cord (twisted preferably) to splay the four wires into the 10BASE-T standard spacing within the ISO jack. I have several locations where the only wire available was a six-conductor wire split between two four-wire jacks - the first being a true RJ11. Works fine. I agree with a previous poster in that: 1) the physical arrangement allows for near foolproof use of a phone on the SAME jack (with a splitter) 2) the ISO jack has proven to be sufficient to support 3270, LAN, ISDN, Async, Sync, twin-axial (5251 - yuck!), as well as other less-used transmission schemes (Oh, LADC-II as well!) 8 pins will do most everything in a neat and clean manner, a la AT&T's PDS (as opposed to IBM's multi-gauge, shielded poop). -- +--------------------------------------------------------------------------+ | Carlo Milono: cmilono@netcom.apple.com or apple!netcom!cmilono | |"When a true genius appears in the world, you may know him by this sign, | |that the dunces are all in confederacy against him." - Jonathan Swift | +--------------------------------------------------------------------------+
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 02:15:56 GMT From: pchin@midautumn.wpd.sgi.com (Phil Chin) To: comp.protocols.tcp-ip Subject: How to put tcp/ip over LocalTalk?
Any information or pointers to that information will be very much appreciated. Thanks. Philip
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 03:44:40 GMT From: bruce@camb.com (Barton F. Bruce) To: comp.protocols.tcp-ip,comp.sys.dec Subject: Re: LANTRONIX terminal server comments?
In article <1991Mar26.181532.27542@banana.fedex.com>, bill@banana.fedex.com (bill daniels) writes: > I am interested in comments about Lantronix tcp/ip-LAT terminal servers. We > a looking for some small (physically & # ports) terminal servers and the > good price of lantronix is attractive. I would especially like to hear about Never tried them, but the features you seek are available in DEC's new DS90 that might have been announced by now. I have NOT seen one, but apparently many customers have seen at least non-disclosure units. They target BEATING everyone's price! DEC listening to customers?
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 06:49:46 GMT From: faunt@CISCO.COM (Doug Faunt N6TQS 415-688-8269) To: comp.protocols.tcp-ip Subject: Two machine ethernet?
Yes. It's speced that way. It works. Date: Fri, 05 Apr 91 13:35:03 EST From: SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu Out of curiosity, I have a question regarding 10BASET wiring: Can two PC's with 10BASET cards be wired back to back using a single twisted pair wire (RJ45s) with the transmit and receive pairs swapped via a crossover block -- effectively producing a two machine ethernet? ====================================================================== Jack E. McCoy SSJACK@ECUVM1.BITNET Systems Programmer (919) 757 - 6401 East Carolina University Greenville, NC 27858 ======================================================================
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 09:19:26 GMT From: colin@la.excelan.com (Colin Goldstein) To: comp.os.os2.programmer,comp.protocols.tcp-ip Subject: Re: Problems with IBMs TCP/IP V1.1 for OS/2
The News Manager) Nntp-Posting-Host: la Reply-To: colin@la.novell.com (Colin Goldstein) Organization: Novell, Inc., San Jose, Ca References: <ZSNPX4T@nadia.stgt.sub.org> Date: Thu, 4 Apr 1991 16:17:06 GMT In article <ZSNPX4T@nadia.stgt.sub.org> chlebosc@nadia.stgt.sub.org (Claudius Chlebosch) writes: >The server calls the recv() function, which returns with 4360 bytes >received. The client has to call the recv() function once again to >get the remaining 15640 >bytes of the segment. In my opinion this >behaviour is not correct. > I don't have the IBM TCP/IP package, but the TCP/IP toolkit from Novell works the same way. Although stream sockets give reliable delivery, there is no way to be sure that all the data will arrive at the same time. It is therefore the applications responsibility to recv() until all the data is read. Keep a count of bytes read or use select() to determine if more data is available. Colin -- /-------------------------------------------------------------------\ | The views expressed here are my own. | Norm, what are you | | They do not necessarily represent | up too??? | | the views expressed by my employer. | | | ---------------| My ideal weight if I | | colin@novell.com | Novell Inc., | were 11 feet tall. | | uunet!novell!colin | San Jose | - Cheers | \-------------------------------------------------------------------/
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 12:37:30 GMT From: scoggin@delmarva.delmarva.COM (John Scoggin) To: comp.protocols.tcp-ip Subject: Multi-protocol Routers with Compression
We are currently operating a multi-protocol (IP, XNS, IPX, SNA...) internet
using Wellfleet bridge/routers with 672 kbps links. While this configuration
works quite nicely, it is a bit expensive to implement in smaller offices.
Is anyone aware of a multi-protocol bridge/router which incorporates data
compression techniques for operation on low-speed (56-384 kbps) lines?
It is difficult to justify T-1 circuits to an office with 10-15 office
workers, but a DDS or fractional T-1 circuit might be feasible. A straight-
forward bridge/router without compression would give unacceptable performance
(IMHO) when retrieving mapping data from our NFS servers.
Many thanks for any ideas!
----------------------------------------------------------------------
John K. Scoggin, Jr.
Supervisor, Network Operations Phone: (302) 451-5200
Delmarva Power & Light Company Fax: (302) 451-5321
500 N. Wakefield Drive Email: scoggin@delmarva.com
Newark, DE 19714-6066
-------------------------------
"Never underestimate the bandwidth of a station wagon load of magnetic
tapes screaming down the interstate!"
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 16:12:24 GMT From: smithfd@weiss.cs.unc.edu (Don Smith) To: comp.protocols.tcp-ip,comp.protocols.iso Subject: TriComm'91 Final Call for Registration
FINAL CALL FOR REGISTRATION
[Note: If you plan to attend TriComm'91, please send the registration
information (below) immediately by express mail, FAX or email. Payment
can be made when you pick up your registration material at the conference.
Registrations made after Monday, April 15, 1991, cannot be guaranteed lunch
and dinner tickets.]
TriComm'91
IEEE CONFERENCE ON COMMUNICATIONS SOFTWARE:
COMMUNICATIONS FOR DISTRIBUTED APPLICATIONS AND SYSTEMS
Chapel Hill, NC April 18-19, 1991 (Registration & Reception April 17, 6 pm)
An International Conference Sponsored by the IEEE Communication Society,
the University of North Carolina at Chapel Hill, and MCNC
The decade of the 1980s was a period of rapid advances in communications
technology (both hardware and software) and of pioneering deployment of
distributed systems and applications. At the beginning of the 1990's,
new communications technologies and new distributed applications are
emerging that will have far-reaching impact on communications software.
Very high-speed networks (e.g., from FDDI to Gigabit technologies), multi-
and continuous-media communications, interconnection of workstations and
supercomputers, visualization and image applications, and computer-supported
cooperative work (CSCW) are just a few examples. Participation in the
conference by both developers of advanced distributed applications or
systems and researchers interested in communications software will
provide a mutually beneficial dialogue.
FEATURED SPEAKERS
Ken Birman, Cornell University, "Group Communication in Operating System
Microkernals"
Roger Bushnell, Bell Northern Research, "Subscriber Service Evolution"
J. L. Felton, IBM, "Directions in Information Systems in the 1990s"
John Morris, Open Software Foundation, "Distributed Systems: Meeting the
Needs of the 90s"
Dave Sincoskie, Bellcore, "Gigabit Testbed Activities at Bellcore"
SESSIONS
COMMUNICATIONS FOR MULTIMEDIA
"Multimedia TeleConferencing over International Packet Switched Networks,"
J. Crowcroft, University College-London
"On the Synchronization and Display of Multiple Full-Motion Video Streams,"
Howard Katseff, AT & T Bell Laboratories
"Delay Jitter Control for Real-Time Communication in a Packet Switching
Network,"
Dinesh C. Verma, University of CA-Berkeley & International Computer Science
Institute
"New Virtual Time CSMA/CD Protocols for Real-Time Communication,"
Jaideep Srivastava, University of Minnesota
APPLICATIONS AND ARCHITECTURES
"The Design and Implementation of the MONTAGE Multimedia Mail System,"
Keith Edwards, Georgia Institute of Technology
"A Proposed Extension of the ODA Document Model for the Processing of
Multimedia Documents,"
Hannes P. Lubich, ETH-Zurich
"The Andrew File System on OS/2 and SNA,"
Neil Sullivan, IBM-RTP
"Vector Processor Services for Local Area Networks,"
Scott Midkiff, Virginia Polytechnic Institute and State University
COMPUTER CONFERENCING
"Evaluating Alternative Display Sharing System Architectures,"
Nina Rosson, Southwest Research Institute
"XTV: A Framework for Sharing X Window Clients in Remote Synchronous
Collaboration,"
Hussein Abdel-Wahab, Old Dominion University
"Control Issues in Multimedia Conferencing,"
S. R. Ahuja, AT & T Bell Laboratories
"System Design for Workstation-Based Conferencing with Digital Audio
and Video."
Kevin Jeffay, University of North Carolina-Chapel Hill
NETWORK PROTOCOLS AND IMPLEMENTATIONS
"A Communication Protocol for a Multi-level Secure Network,"
Andrew Mazeikis, Queen's University-Ontario
"Heirarchial Network Routing,"
Alan Fekete, University of Sydney
"A Parallel Implementation of the ISO 8802-2.2 Protocol,"
Matthias Kaiserswerth, IBM Research-Zurich
"A Layered Communication System Generator,"
Gen-Huey Chen, National Taiwan University
PERFORMANCE AND MEASUREMENT
"The Effects of Long Delay and Transmission Errors on the Performance of TP-4
Implementation,"
Randy C. Mitchell, The MITRE Corp.
"HiPPI Link Data Analysis System,"
Dan Winkelstein, MCNC
"Tingle: Suite for Monitoring Networks,"
J. Dean Brock, University of North Carolina-Asheville
"Capability Analysis of Distributed Switching Systems in Interprocessor
Communications,"
Serap Savari, MIT
CONFERENCE COMMITTEE
Alan Blatecky, General Chairman Jurg Nievergelt, International Chairman
MCNC, USA ETH, Switzerland
Peter Calingaert Andre Fournier
UNC-Chapel Hill, USA BNR, USA
David May Joe Rusnak
BNR, USA IBM, USA
Dan Stevenson
MCNC, USA
PROGRAM COMMITTEE
F. Donelson Smith Chairman Yutaka Matsushita
IBM & UNC-Chapel Hill, USA Keio University, Japan
Steven Bellovin Najah Naffah
AT & T Bell Laboratories, USA Bull, France
Rich Chilausky Erich Neuhold
BNR, USA GMD-IPSI, Germany
Brian Coan Bernhard Plattner
Bellcore, USA ETH, Switzerland
Flaviu Cristian Tom Rodeheffer
IBM Research-Almaden, USA DEC System Research Center, USA
Carla Ellis Beverly Sanders
Duke University ETH, Switzerland
Rong-Chin Fang M. Satyanarayanan
Northern Telecom, USA Carnegie Mellon U., USA
Domenico Ferrari H.T. Smith
U. of CA-Berkeley, USA Nottingham University, UK
James P. Gray Jorgen Stanstrup
IBM-RTP, USA Technical University, Denmark
Fukuya Ishino Liba Svobodova
NTT, Japan IBM Res.-Zurich, Switzerland
Kevin Jeffay Mladen Vouk
UNC-Chapel Hill, USA NC State U., USA
Rivka Laden Hussein Abdel-Wahab
DEC CRL. USA Old Dominion University, USA
Simon Lam William Weihl
U. of Texas-Austin, USA MIT, USA
Geovane Magalhaes Jennifer Welch
CPqD/TELEBRAS, Brazil UNC-Chapel Hill, USA
LOCATION
TriComm '91 will take place in Chapel Hill, North Carolina, at the University
of North Carolina. The University of North Carolina is located at one corner
of North Carolina's Research Triangle (Raleigh, Durham, Chapel Hill) in the
center of which is the Research Triangle Park and the Raleigh-Durham Airport.
MCNC, a national resource in microelectronics, is located in the Research
Triangle Park. MCNC is a non-profit corporation established to support and
develop the education and research technology infrastructure in North
Carolina. It has three divisions: microelectronics, supercomputing, and
communications.
All conference sessions and meals will be held at the Carolina Inn, a
charming Chapel Hill landmark, located on the campus of the University of
North Carolina just across the street from Sitterson Hall, the
state-of-the-art building which houses UNC's Computer Science Department.
On Wednesday night, April 17, pre-registration and the conference reception
will take place in Sitterson Hall.
Chapel Hill is a small community of about 40,000. In April the weather will
generally be very pleasant with daytime temperatures in the upper 60's and
nighttime temperatures in the 50's; however, you should be prepared for a
shower. Many spring-flowering plants and shrubs should be in bloom at this
time.
TRANSPORTATION
The local airport is Raleigh-Durham International. American Airlines is
the official carrier of TriComm '91, offering special fares to North
American conferees: 5% saving off published excursion fare within the
US, or 40% (Canada 35%) off the full coach fare with a 7-day advance purchase
valid from April 15-April 21, 1991. Call 1-800-433-1790 and refer to STAR
FILE S0241GC to obtain the discount.
Taxis, which you can take to the Carolina Inn or any other location in
Chapel Hill for about $25.00, are generally waiting outside the airport
terminals. Or you can arrange to be picked up by LTD Services. LTD operates
by reservation. In order to be picked up, call LTD (1-800-787-4474 or
919-840-1829) at least one day in advance and give the time, flight number
and airline you will arrive on. You may call after you arrive but you may
have a substantial wait. The cost is $15.00 per person. Because all
conference events will take place either at the Carolina Inn or Sitterson
Hall just across the street, there is no need to rent a car.
For those commuting, we have arranged for a shuttle bus to run from the
southwest corner of the University Mall parking lot (near First Union Bank)
beginning at 7:00 am on April 18 and 19. The Mall is located at the
intersection of Estes Drive and US 15-501. Parking is not available on the
UNC campus between 8:00 am and 5:00 pm. The Carolina Inn provides free
parking for registered guests only.
-------------------------------------cut here---------------------------------
ADVANCE REGISTRATION FORM (Clip and mail to address below)
Please make checks or money orders payable (in U.S. currency) to TriComm '91.
We cannot accept credit cards. Mail with
completed registration form to: Mary Ducker
TriComm '91
CB #3175, Sitterson Hall
University of North Carolina
Chapel Hill, NC 27599-3175 USA
919-962-1869 FAX 919-962-1799
ducker@cs.unc.edu
Conference registration includes a copy of the proceedings, coffee breaks,
Wednesday evening reception, lunches Thursday and Friday, and the Thursday
evening conference dinner. The basic student fee includes the technical
sessions, proceedings, and coffee breaks. Students who register in
advance may also purchase lunches. No refunds can be given after April 10.
Please indicate the appropriate fee.
IEEE member $225.00
Non-member $275.00
Full time student (basic) $35.00
Full-time student
(including lunches) $55.00
Please print the following information.
Name (for name badge) __________________________________________________
Affiliation (for name badge) ___________________________________________
Address ________________________________________________________________
________________________________________________________________
Phone ______________________________Email_______________________________
IEEE membership number __________________________________
I will attend the reception on Wed., April 17____yes ____no
NOTE: Individuals whose registrations are received after Monday, April 15,
cannot be guaranteed lunch and dinner tickets. If you have any special
dietary needs, please let us know. We will make every effort to work with
our caterers to honor those needs.
------------------------------------cut here-------------------------------
HOTEL RESERVATIONS (Clip and mail to address below or phone for reservation)
CAROLINA INN
PO Box 1110
Chapel Hill, NC 27514
919-933-2001 1-800-962-8519
Please make reservations directly with the Carolina Inn and refer to
TriComm '91 (Group #1960*1). Please complete all information and circle
desired accommodation.
TriComm '91 rates (not including tax): single $42-65 double $52-80
Guest name___________________________________________________________
Phone_______________
Address______________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
Arrival date _________________________Departure date_________________
Number in party__________ Share with ________________________________
_________________________________________________
Reservations will be held until 6:00 p.m. on the arrival date unless a
one night deposit is received or is guaranteed with American Express, Visa,
or Mastercard.
Card name ____________________Expiration date ___________
Card number __________________________
Name on card (please print clearly) ___________________________________
Signature ____________________________________________________________
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 17:05:49 GMT From: romkey@ASYLUM.SF.CA.US (John Romkey) To: comp.protocols.tcp-ip Subject: Token Ring ARPs
There are apparently a number of vendors in the field with token ring products that comply with RFC 1042. Many router vendors and PC vendors, for instance. Interop has a respectable number of hosts on token ring at the show every year, also. I think you're asking for a lot of trouble if you try to change this now. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice/fax: 415 594-1141
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 17:08:52 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: finger weather (really Coke machines)
In article <1991Apr5.192823.400@spool.cs.wisc.edu> hollings@poona.cs.wisc.edu (Jeff Hollingsworth) writes:
>So I guess Wisconsin can claim the only Coke machine that can be controlled
>via the Internet.
Sorry, but Thinking Machines has had its Coke machine on the Internet for
at least five years. If you telnet to Coke5.Think.COM, each character you
type is as if a nickel were dropped into the slot.
The subnet Coke5 is on a subnet to which we don't allow telnet from the
outside world, so you won't have much luck trying this. But it works
in-house. There's a terminal sitting next to the machine, and users can
type their name, get their drink, and then the price is deducted from their
paycheck (we also use the payroll deduction system for lunch and the
postage meter).
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 19:03:00 GMT From: amc@cup.portal.com (Alan Michael Crawley) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: 10baseT Installation costs
Alot of people are talking about the costs of 10baseT vs. cheapnet. My company engineers and INSTALLS large (50-1500 user) 10baseT nets and cable plants. Also FDDI. 10baseT is only cheaper when the net is over 100 users big. Savings is in administration costs.(adds moves and changes) and existing wire savings. Little departmental nets don't benefit that way. Large nets also benefit from existing phone wire. We do cable plant audits to test existing wire for 10baseT. Almost 100% is suitable for ethernet if we change out the 66 blocks for 110 or Krone...plus a few other secrets. Alan Crawley VP Engineering APEX COMMUNICATIONS - MOUNTAIN VIEW CALIFORNIA - 415-967-9200
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 19:36:07 GMT From: mcitron@phad.hsc.usc.edu (Mark Citron) To: comp.protocols.tcp-ip,comp.unix.xenix.sco Subject: tn3270 under SCO Unix
I post this several months ago and got no reponses but it is so important for us I figured it is worth another try. Does anyone have a 3270 emulator that runs under SCO Unix (we already have tcp/ip)? We have a critical need and would even consider paying for a port to SCO Unix. We need to communicate with a remote IBM mainframe via ethernet-tcp/ip (no other protocols or media). Any help or suggestions would be greatly appreciated. Mark Citron Childrens Hospital Los Angeles -- Mark Citron mark@neurosci.usc.edu
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 23:57:49 GMT From: yeh@ubvax.UB.Com (David Yeh) To: comp.protocols.tcp-ip Subject: Re: FTP site for RFCs?
In article <FRANCIS.91Apr5021203@daisy.zaphod.uchicago.edu> francis@zaphod.uchicago.edu writes: > >Is there an FTP site with RFCs? I'm kinda interested in seeing the >protocol specs for the stuff I'm using, but I'm just a student (not >even a CS student at that :-), so I don't have any clue about who >handles this stuff. > > >-- >/============================================================================\ >| Francis Stracke | My opinions are my own. I don't steal them.| >| Department of Mathematics |=============================================| >| University of Chicago | Earth: Love it or leave it. | >| francis@zaphod.uchicago.edu | | >\============================================================================/ For the ftp site on RFC: 1. ftp nic.ddn.mil 2. login with name "anonymous" and password "guest". once logged in, make a connection to the correct directory: 3. cd rfc: and send password "ascii" after you are asked. 4. It's s good idea to get an introduction and index first: get rfc-index.txt Or, you can e-mail to SERVICE@NIC.DDN.MIL and indicate the RFC you need in subject.(e.g. SUBJECT: RFC XXX). David,
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: 7 Apr 91 00:10:20 GMT From: ersys!wmah@nro.cs.athabascau.ca (Wayne Mah) To: comp.protocols.tcp-ip Subject: Re: Two machine ethernet?
faunt@CISCO.COM (Doug Faunt N6TQS 415-688-8269) writes: > Yes. It's speced that way. It works. > > Date: Fri, 05 Apr 91 13:35:03 EST > From: SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu > > > Out of curiosity, I have a question regarding 10BASET wiring: > > Can two PC's with 10BASET cards be wired back to back using a single > twisted pair wire (RJ45s) with the transmit and receive pairs swapped > via a crossover block -- effectively producing a two machine ethernet? > > ====================================================================== > Jack E. McCoy SSJACK@ECUVM1.BITNET > Systems Programmer (919) 757 - 6401 > East Carolina University Greenville, NC 27858 > ====================================================================== I have successly done what you propose. I have the WD EtherCard Plus 10BaseT card that shows a successful connection by lighting its link light. Wayne Mah ersys!wmah@nro.cs.athabascau.ca Edmonton Remote Systems: Serving Northern Alberta since 1982
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: 7 Apr 91 01:13:00 GMT From: JRJONES@ALEX.STKATE.EDU To: comp.protocols.tcp-ip Subject: Re: 10baseT Installation costs
Alan Crawley, Could you please elaborate on the following, what are 110 or Krone, and what is the benefit of them over 66 blocks? > Almost 100% is suitable for ethernet if we change out the 66 blocks > for 110 or Krone...plus a few other secrets. > Alan Crawley > VP Engineering > APEX COMMUNICATIONS - MOUNTAIN VIEW CALIFORNIA - 415-967-9200 Having a lot of 66 blocks and thinking about 10baseT, I would like additional info if possible. Jim Jones jrjones@alex.stkate.edu 612-690-6856
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: 7 Apr 91 01:14:05 GMT From: henry@zoo.toronto.edu (Henry Spencer) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: 10baseT Installation costs
In article <40993@cup.portal.com> amc@cup.portal.com (Alan Michael Crawley) writes: >10baseT is only cheaper when the net is over 100 users big. Savings is in >administration costs.(adds moves and changes) and existing wire savings. Administration costs depend heavily on circumstances. If you've got an abundance of unsophisticated users who will happily unplug things at random times, bus-based technologies like thinwire are a serious mistake, and 10baseT is just what the doctor ordered, even for a small net. -- "The stories one hears about putting up | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 are all true." -D. Harrison| henry@zoo.toronto.edu utzoo!henry
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: 7 Apr 91 16:28:58 GMT From: km3t@jjmhome.UUCP (Dave Pascoe) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.sys.mac.comm Subject: NCSA Telnet-like program for PC w/ LocalTalk card?
Is there a program like NCSA Telnet for IBM PCs with Apple LocalTalk cards? We have a PC on LocalTalk bridged to Ethernet with a Fast Path and would like it to have TCP/IP capability..... Any help appreciated.... -- Dave Pascoe | Internet: km3t@jjmhome.m2c.org or dhp1@gte.com KM3T | UUCP: km3t@jjmhome.UUCP
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: 7 Apr 91 18:22:57 GMT From: swansonc@acc.stolaf.edu (Chris Swanson) To: comp.protocols.tcp-ip Subject: Re: Two machine ethernet?
I have a question about making a two-node ethernet. I will be getting an Amiga 3000UX-D (AUI and thinnet) and a Sun 2 w/ only an AUI port. The machines will be close (within 10 ft, probably within 5 ft). What I want to know is if I can someway reliably tie the two machines together via the AUI ports, excusing me from the cost of a thinnet-to-AUI transciever. If the solution costs more than an AUI-to-thinnet transeiver, then I will just buy the transeiver. On that note, is there someone out there that would be willing to sell (cheaply) a transeiver for thinnet? Please reply via e-mail, I will follow-up if there is intrest. Thank's in advance, -Chris -- Chris Swanson, Chem/CS/Pre-med Undergrad, St. Olaf College, Northfield,MN 55057 DDN: (CDS6) INTERNET: swansonc@acc.stolaf.edu UUCP: uunet!stolaf!swansonc AT&T: Work: (507)-645-4528 Home: (507)-663-6424 I would deny this reality, but that wouldn't pay the bills...
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: 7 Apr 91 18:33:29 GMT From: swansonc@acc.stolaf.edu (Chris Swanson) To: comp.protocols.tcp-ip Subject: CSlip and PPP w/ compression modems
I will be running either PPP or CSlip (any other suggestions for compressed IP over serial lines) over a 2400 bps modem link (yuck - I know, but I am a poor college student) Using compressed SLIP, will MNP5 or V42.bis provide additional througput? If not, what would I be better running - CSLIP or like product w/ MNP 4 error correction, MNP 5 w/ regular SLIP, or V42.bis w/ regular SLIP? Please follow-up to me as I do not always get a chance to peruse the news. Thank's in advance, -Chris -- Chris Swanson, Chem/CS/Pre-med Undergrad, St. Olaf College, Northfield,MN 55057 DDN: (CDS6) INTERNET: swansonc@acc.stolaf.edu UUCP: uunet!stolaf!swansonc AT&T: Work: (507)-645-4528 Home: (507)-663-6424 I would deny this reality, but that wouldn't pay the bills...
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: 7 Apr 91 20:55:32 GMT From: maniac@howlin.cs.unlv.edu (Eric J. Schwertfeger) To: comp.protocols.tcp-ip Subject: Re: Message compression
In article <obz08jq00WCpE4ddc4@andrew.cmu.edu>, ww0n+@ANDREW.CMU.EDU (Walter Lloyd Wimer III) writes: ) > is that they need to be able to look at the entire data stream before ) > being able to compress any part of it. In this case, it would be about ) > the same as running compress yourself and then FTPing the resulting file. ) ) ) From empirical evidence, I don't believe this is true. It isn't. I've written LZW compression code before, and it is highly stream oriented. The hash table is created and updated on both ends on the fly, with only one special case. -- Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: 7 Apr 91 20:56:51 GMT From: bkc@OMNIGATE.CLARKSON.EDU (Brad Clements) To: comp.protocols.tcp-ip Subject: Re: Message compression
Regarding compressing TCP packets for serial transmission. I've developed an extension to Jacobsons TCP header compression routines that will compress the TCP data portion using Splay tree compression. This routine uses 'state trees' with a variable number of trees being assigned to each active TCP connection (and depending on the major data direction of the stream). The routine dynamically moves state trees to connections where it does the most good, and can do so without entirely resetting the trees of existing connections that gain or lose trees. For example, I can support 32 state trees in about 32K of memory. This gives me a 5 to 1 compression on 3278 type datastreams, 3 - 4 to 1 for standard text. The advantage of using state trees where two fold: 1. Low memory overhead in the kernel 2. the ability to dynamically reconfigure memory usage (in this case, moving trees between connections as needed) without having to dump 'all learned patterns' each time. The routine automatically detects uncompressible data (for ftp's of already compressed files, for example). etc etc. Anyway, this is all quite experimental, runs on top of PPP for Sun OS, and isn't yet available for general consumption (please don't ask for the code yet). I know that compressing modems are becoming more prevelant these days, but this cheap solution gives my 2400 baud modem 5600 baud throughput (best case). I have not had a chance to compare this method with compression of the entire datastream within the modem. However I think even using splay trees (which are not as effective as adaptive LZW), I get better compression on serial links which are supporting different TCP sessions, since the compression state information is tracked by TCP connection, and the TCP header data (already 'compressed' by VJC) is not examined during the compression process. Of course, when packets are dropped, VJ compression gives the splay routines enough information to have both the compressor and decompressor reset their trees. | Brad Clements bkc@omnigate.clarkson.edu bkc@clutx.bitnet | Sr. Network Engineer Clarkson University (315)268-2292
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 91 07:53:48 GMT From: neil@pio.gid.co.uk (Neil Todd) To: comp.protocols.tcp-ip,comp.unix.wizards Subject: TCP benchmarking
In the next few months I'm going to be required to benchmark a number of IP implementations. I would like to identify some readily available benchmarking packages, further I would like at least one of the packages to be testing in an "industry standard" way. Any ideas ? Neil Neil Todd | ..In general, it is best to assume that the PSI%234237100122::neil | network is filled with malevolent entities neil@gid.co.uk | that will send in packets designed to have Group-ID Ltd | the worst possible effect...
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 91 11:34:10 GMT From: kevin@msa3b.UUCP (Kevin P. Kleinfelter) To: comp.protocols.ibm,comp.protocols.tcp-ip Subject: Re: TCP tunnelled in IBM/SNA (more)
IBM can do this. We were interested because we have an existing SNA network, and needed to let two TCP/IP machines communicate over the existing network. Trouble is that you have to have a 370 to wrap the IP packets AND a 370 to unwrap. We had a 370 on one end of the link, and would have had to put a 370 on the other end -- too expensive! :-) -- Kevin Kleinfelter @ Dun and Bradstreet Software, Inc (404) 239-2347 ...gatech!nanovx!msa3b!kevin Warning: There seem to be multiple 'msa3b' nodes on Usenet, and it is nanoVX, not nanovAx.
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 91 14:05:07 GMT From: kirchner@informatik.uni-kl.de (Reinhard Kirchner) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: WinQVT problem using NI5210
I have downloaded the packet drivers from sun.soe.clarkson.edu, which allow to use the WinQVT program with MS Windows 3.0. I have installed all the programs and drivers needed and after starting WINQVT from Windows I get the message "packet class invalid (not supported)". My packet class is 0, using NI5210 Ethernet card. Can anybody tell me, what I do wrong in the installation. Do I need some other software to run WinQVT? Thank you Please answer to the following e-mail address: ae18@dkauni2.bitnet Thanks, Michael Neaga
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 91 14:07:08 GMT From: jdeitch@jadpc.cts.com (Jim Deitch) To: comp.protocols.tcp-ip Subject: Packet drivers for Proteon Pronet-10
Can anyone tell me if packet drivers for Proteon Pro-net 10 boards exist? If not, is anyone using NCSA telnet with the Pronet-10 cards, and how are you doing it? Thanks, Jim -- ARPANET: jadpc!jdeitch@nosc.mil INTERNET: jdeitch@jadpc.cts.com UUCP: nosc!jadpc!jdeitch
-----------[000087][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 91 15:28:34 GMT From: jgd@Dixie.Com (John G. DeArmond) To: comp.protocols.tcp-ip Subject: Ethernet spec. - where to get
I'd like to find out where to order the original Ethernet specification. NOT 802.3, which I already have, but the original "Green Book" specification. Commercial or PD sources are fine. Please reply by email. Thanks in advance, John -- John De Armond, WD4OQC | "Purveyors of speed to the Trade" (tm) Rapid Deployment System, Inc. | Home of the Nidgets (tm) Marietta, Ga | jgd@dixie.com |"Politically InCorrect.. And damn proud of it
-----------[000088][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 91 15:38:39 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: Token Ring ARPs
The research community has been pushing for all MAC addresses carried
as data in communication protocols to always be in cannonical format.
I don't think this is the "research community". Instead, I think it is
primarily commercial companies which "believe" in multi-media "bridges"
instead of "routers".
I'm curious as to if and when this might have an effect on products in
the marketplace. I believe there is a large installed base that uses
the RFC1042 style ARPs where the MAC addresses are in wire order.
The proposal I've seen makes it necessary to supply all new 802.5 IP
software with a "new/old bit order" configuration switch, and upgrade
all existing IP hosts on your ring before it can be set to "new" on any
of them. A truly Herculean support hassle, given how much 802.5 is out
there working the old way (IBM, FTP Software, Proteon, cisco, Wellfleet,
3Com, Woolongong etc.).
Are there any products out there that use cannonical order?
No; I've seen a couple of beta test releases that have reached the field
in ignorance of the true state of the world, but it gets fixed quite quickly
once the vendor understands about the installed base.
Are there any coming? Does anyone have any other information?
I don't know of any, barring accidents of the sort I mention above.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000089][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 91 16:45:57 GMT From: tono@sm.luth.se (Tomas Nordstr|m) To: comp.protocols.tcp-ip Subject: Wanted: Information about TCP/IP drivers.
Is there anyone who has written drivers for TCP/IP ? We would like to get some hints and if possible also some useful source code. We have a motorola system using the 68030 and the AM7990-LAN controller. There is no OS running at the moment, but we have a locally made realtime Kernel with higher performance that most of the commercial one. Any code or pointers to code for communication to/from unix workstations or PC/mac computers using ethernet and TCP/IP would be appreciated. Thanks in advance, Tomas Nordstrom posting news for Martin Jonsson <p89-mjn@sm.luth.se> Please send any reply to Martin (p89-mjn@sm.luth.se). PS. Spring time is here, the snow has melted from 1m to 1/2m. -- Tomas Nordstrom Tel: +46 920 91061 Dept. of Computer Engineering Fax: +46 920 98894 Lulea university of Technology Telex: 80447 LUHS S-95187 Lulea, SWEDEN Email: tono@sm.luth.se (internet)
-----------[000090][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 91 17:47:00 GMT From: J_ALVAREZ@UPR1.UPR.CLU.EDU (JUNIOR) To: comp.protocols.tcp-ip Subject: AUTOMATIC COKE MACHINE
I read a mail from Hollings on Wiscosin that have a Automatic Coke machine activate by Computer, and I want more information about how he,she or they constructe the hardware and software for this aplication. .. My name is Jose Alvarez from University of Puerto Rico. We have a Coke, Juice and Snack Machine and I want information about mechanism that put your Coke machine activate by Computer... "Or As a Part of the Internate"... Regards. Junior.. Any information plse send to: j_alvarez@upr1.upr.clu.edu or j_alvare@upr2.clu.net
-----------[000091][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 91 18:15:21 GMT From: greene@coral.com (Jeremy Greene) To: comp.protocols.tcp-ip Subject: Token Ring ARPs
) I don't think this is the "research community". Instead, I think it is ) primarily commercial companies which "believe" in multi-media "bridges" ) instead of "routers". I agree that, because of ARP, bridges highlight the multi-media problem. But what about other applications, say for network management, which also send MAC addresses in data? A router presents the same problem as a brigde in this case. It makes a lot of sense to start now in making sure we do not propagate the mistake made in 1042. Of course, then 1042 implementations would most likely eventually have to be changed... so why not now? Dose 1042 actual say to use wire order? I couldn't find it. JAG
-----------[000092][next][prev][last][first]----------------------------------------------------
Date: 8 Apr 91 18:21:33 GMT
From: ELINSKY@YKTVMZ.BITNET ("Jay Elinsky")
To: comp.protocols.tcp-ip
Subject: Re: Token Ring ARPs
> Are there any products out there that use cannonical order?
>
> No; I've seen a couple of beta test releases that have reached the field
> in ignorance of the true state of the world, but it gets fixed quite quickly
> once the vendor understands about the installed base.
Actually, Version 2 of IBM's VM and MVS TCP/IP products have the "new/old
bit order configuration switch". It's the "CANONICAL/NONCANONICAL"
parameter of the LINK statement for network type IBMTR. The VM manual
mentions it for IBMTR links on LCS devices only, but it applies to ILANS
devices also. The default is NONCANONICAL, of course.
Jay Elinsky
IBM T.J. Watson Research Center
Yorktown Heights, NY
-----------[000093][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 91 19:30:44 GMT From: KOEHLER@awiwuw11.wu-wien.ac.at (Wolfi) To: comp.protocols.tcp-ip Subject: Troubles with BOOTP from FTP
I have troubles using the ethernet generic version of BOOTP from FTP Inc. Although there are 6 BOOTP Servers responding (definitely right responding), my PC cant't get its IP address. I have tried all options and different packet drivers, too. This error is really mysterious, because sometimes it works, but in 95%, it won't. I am using an IBM P70 with an 3C523 Ethernet card, but had the same problem with an IBM 50Z and a WD8003E card, too. Please write, if someone has had similar problems, and if a workable solution is possible.
-----------[000094][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 91 21:22:31 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: Token Ring ARPs
But what about other applications, say for network management, which
also send MAC addresses in data? A router presents the same problem as
a brigde in this case.
If an arbitrary protocol obtains a MAC address in a local LAN context, and
can restrain itself from using the MAC address outside that LAN's context,
there is no problem. Bit order doesn't matter if you treat the address as
opaque. Because not all MAC addresses conform to IEEE 48 bit formats, you
need to know the LAN's physical layer to parse them anyway. Canonical bit
order on all 802.2 LANs would make the parser a little simpler...
... It makes a lot of sense to start now in making
sure we do not propagate the mistake made in 1042. Of course, then 1042
implementations would most likely eventually have to be changed... so
why not now?
As of the moment, neither of the two widely distributed 802.5 driver specs
(IBM's ASI and 3Com/Microsoft NDIS between them represent 95% of the IBM PC
802.5 interfaces, and probably 90% of the total 802.5 installed base) even
have hooks in them to indicate which bit order the MAC address is presented
in. Many of the ASI drivers are at least partly in ROM. So, first you need
to upgrade the specs, then all software drivers that were shipped with the
boards, and maybe the ROMs. It'll be a while.
Dose 1042 actual say to use wire order? I couldn't find it.
It doesn't say. However, IBM chose the order returned by their TOKREUI
program, and everyone else followed suit.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000095][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 91 22:10:38 GMT From: obrien@Aero.org (Michael O'Brien) To: comp.protocols.tcp-ip Subject: Oddball devices on the Internet
This thread about fingering Coke machines (I was previously only aware of the installation at SAIL) has me fascinated. Hence, I'll proceed to collect entries in the form of answers to the following question: What other oddball devices have been hooked to the net? Ideally, entries should not be scientific instrumentation (unless it's a real Dr. Wacko production), but more common things - such as the reputed front door buzzer at the Tech Square building at MIT, where one could supposedly press control-shift-meta-cokebottle-P (this was on an ITS machine, after all) to open the front door, no matter what application you were in. I'll summarize the best responses. Warning: I may also publish entries in my column "Ask Mr. Protocol" in Sun Expert, unless requested not to by the author. Credit will be given, of course. -- Mike O'Brien obrien@aerospace.aero.org
-----------[000096][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 91 22:18:45 GMT From: greene@coral.com (Jeremy Greene) To: comp.protocols.tcp-ip Subject: Token Ring ARPs
) But what about other applications, say for network management, which ) also send MAC addresses in data? A router presents the same problem as ) a brigde in this case. ) ) If an arbitrary protocol obtains a MAC address in a local LAN context, and ) can restrain itself from using the MAC address outside that LAN's context, ) there is no problem. Bit order doesn't matter if you treat the address as ) opaque. Because not all MAC addresses conform to IEEE 48 bit formats, you ) need to know the LAN's physical layer to parse them anyway. Canonical bit ) order on all 802.2 LANs would make the parser a little simpler... ) You were talking about sending mac addresses accross multi-media. I was pointing out that the problem is with ANY mac address in data, not just macs in ARP responses. For macs in data other than ARPs, multi-media routers cause the same problem that bridges do. You brought up another valid issue: how does an application which runs on various media know what the address format is. The right answer is that it always expects it in one format. I'm not sure what you mean by opaque, the point is that the application wants to see the data. ) As of the moment, neither of the two widely distributed 802.5 driver specs ) (IBM's ASI and 3Com/Microsoft NDIS between them represent 95% of the IBM PC ) 802.5 interfaces, and probably 90% of the total 802.5 installed base) even ) have hooks in them to indicate which bit order the MAC address is presented ) in. Many of the ASI drivers are at least partly in ROM. So, first you need ) to upgrade the specs, then all software drivers that were shipped with the ) boards, and maybe the ROMs. It'll be a while. Is it really that bad? You mean there are 802.5 cards/drivers which actually return a canonical format address? I find that hard to believe. It would certainly be nice to have the driver hook, but I think the client of the driver could know the format based on the interface type. JAG
-----------[000097][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 91 23:40:19 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip,comp.unix.wizards Subject: Re: TCP benchmarking
I've encountered another "benchmark." First try the 4.3BSD `ping -l9999999 target` and look at the packet rate. There are commercially available UNIX workstations that will deliver the vast majority of the zillion 98-byte ether packets separated by only 9.6 microseconds. The point is I think there are several vendors' workstatsions that can write at or close to ethernet media speed, <<from a user process>>. Second, modify the more recent 4.3BSD-tahoe or reno ping.c to flush the "." and "\b" characters only occassionally or when things get slow, so that `ping -f` does not spend most of its time fiddling with stdio. Then make `ping -f` compute a packet/sec rate to be displayed at the end. This produces nice numbers that seem to vary depending on the speed of the machines on both ends. Neither of these are very interesting benchmarks; they're just fun. Ttcp is better for TCP or UDP, and FTP for overall file system and network speed. Vernon Schryver, vjs@sgi.com
-----------[000098][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 91 02:00:48 GMT From: rvg@artemis.cs.wayne.edu (Rahul Vijay Garg) To: comp.graphics,comp.windows.x,comp.windows.open-look,alt.sources,alt.sources.wanted,comp.protocols.tcp-ip Subject: Graphical TCP/IP Manager
Hi Netters, I am looking for some kind of a graphical Network Manager which could monitor and display a distributed systems application (using TCP/IP) on an X interface. Any pointers to something similar also would be of great help. Thanks. -- -rahul (rvg@cs.wayne.edu)
-----------[000099][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 91 03:39:19 GMT From: hliu@UCSD.EDU (Hai-Ning Liu) To: comp.protocols.tcp-ip Subject: (none)
please delete my name!!!! hliu@ucsd.edu liu@cs.ucsd.edu
-----------[000100][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 91 14:46:47 GMT From: pansiot@ISIS.U-STRASBG.FR (Jean-Jacques Pansiot Departement d'Informatique Universite Louis Pasteur Strasbourg FRANCE) To: comp.protocols.tcp-ip Subject: NCSA and Tek 4014
I ask this question for a friend who cannot read this list. He is trying to use NCSA telnet to do remote Tektronix emulation. However, it seems that the emulation is not complete, for exemple the Grapical Cursor is not visible, which makes it very difficult to use interactive tools. This happens both on NCSA for PC and Mac. Is he doing something wrong, or is GIN an unimplemneted feature? In the last case, are there any (preferably freeware...) package doing full Tek 4014 ? thanks a lot Please respond to me. I will summarize if there is interest. Jean-Jacques Pansiot, Universite Louis Pasteur, Strasbourg, FRANCE 7, rue Descartes 67084 STRASBOURG CEDEX FRANCE Email: pansiot@isis.u-strasbg.fr Tel: (33) 88 41 64 28 Fax: (33) 88 61 90 69
-----------[000101][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 91 16:44:03 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: Packet drivers for Proteon Pronet-10
As far as I know, there never have been any implementations of Class 2 (Proteon ProNET-10 token ring) Packet Drivers. PC-IP has a linked-in driver for the P1300 interface, so do some of the commercial products. Proteon has an non-board-independent interface-sharing spec, which they've implemented in their Netware and we in our PC-222 part. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000102][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 91 18:01:11 GMT From: dcm@baldur.dell.com (Dave McCracken) To: comp.protocols.tcp-ip Subject: How to set up subnets where logical subnet != physical subnet
I am trying to solve a problem we are having trying to set up a subnet in our corporate network. The current environment is an ethernet with MAC-layer bridges between all subnets, which are necessary because we need to support IP, Netware IPX, and 3com 3+share packets. What we would like to do is split off the Unix development group as an IP-only subnet, with the rest of the network as the other subnet. What we would end up with is a small subnet with 30-40 machines connected to a large subnet with 500-800 machines, of which probably 100-300 will use IP at least some of the time. Our IP address numbering scheme is a class B network address, and we would like to run with a 6-8 bit subnet mask. We have already assigned subnet numbers based on department for administrative reasons. The real problem is when I try to set up a router for this arrangement. Since most of the network is being routed by a layer below IP, it is necessary for several logical subnets, based on the subnet mask, to be on the same physical network. The routing code in the IP driver will cheerfully accept that the other subnets are local when I specify 0 hops to the route command, but it absolutely refuses to let me specify an IP address for the router that is not in the same logical subnet. We are currently running mostly System V Release 4, but the same problem exists on our Suns and in the straight BSD4.3 code (I looked in the source). What I would like to know from the collected wisdom of Usenet is why the restriction is there, and if you think anything would break if I changed the IP driver in SVR4 to accept a router address outside the subnet. I would also like to know is there is a simple way in the router to present miltiple IP addresses without plugging in extra network cards. This would be an alternate solution that would not require changing all clients. Thanks, -- Dave McCracken dcm@dell.dell.com (512) 343-3720 Dell Computer 9505 Arboretum Blvd Austin, TX 78759-7299
-----------[000103][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 91 21:44:05 GMT From: andrew@jhereg.osa.com (Andrew C. Esh) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: 10BaseT installation
In article <1991Apr6.011139.1572@netcom.COM> cmilono@netcom.COM (Carlo Milono) writes: > > > >and their product is standard. Secondly, it is a misnomer to use the RJ45 >name for an 8-pin jack - the correct terminology is the ISO 8877 jack. The ^^^^^^^^ OK, got it... All I knew was RJ45, but in keeping with my good intentions toward solid international standards in technical communication, the above use is noted, and adopted. > >Lastly, you can run your 10BASE-T on household 'quad' wire and get an >appropriate cord (twisted preferably) to splay the four wires into the >10BASE-T standard spacing within the ISO jack. I have several locations >where the only wire available was a six-conductor wire split between two >four-wire jacks - the first being a true RJ11. Works fine. ^^^^ Huh? Now I feel ripped off. I learned "8-pin RJ45" = ISO 8877, but what is the ISO number for RJ11? Why wasn't it used here? I be confuse. >+--------------------------------------------------------------------------+ >| Carlo Milono: cmilono@netcom.apple.com or apple!netcom!cmilono | >|"When a true genius appears in the world, you may know him by this sign, | >|that the dunces are all in confederacy against him." - Jonathan Swift | >+--------------------------------------------------------------------------+ -- Andrew C. Esh andrew@osa.com Open Systems Architects, Inc. Minneapolis, MN 55416-1528 (612) 525-0000 Practicing the OSI Standard
-----------[000104][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 91 22:39:24 GMT From: les@GANG-OF-FOUR.STANFORD.EDU (Les Earnest) To: comp.protocols.tcp-ip Subject: finger weather (really Coke machines)
>> As far as I know nothing similar has been done elsewhere, so CMU can >> legitimately boast of having the only Coke machine on the Internet. > > Here at the University of Wisconsin we were *FORCED* to computerize our Coke > machine a year ago (or they would take it away). . . . > The coke machine was also modified so > that it would NOT take money and could only be activated from the computer. > So I guess Wisconsin can claim the only Coke machine that can be controlled > via the Internet. A vending machine was connected to the SAIL computer at Stanford around 1973, which I believe was much earlier than any other computer- controlled vending machine. It sold snacks, soft drinks, and beer. Everything could be purchased for cash or credit except the beer, which could only be bought on credit and then only if the buyer was over 21. Any attempt by an underage person to buy beer elicited the error message "Sorry, kid." The national wire services ran a story on this machine at the time and some representatives of one of the major vending machine manufacturers came to see if they could turn it into a product. They were apparently deterred by the fact that they didn't understand diddly about computers. They also were put off by the fact that the computer being used for this modest task (a large DEC 10) cost about $1 million. SAIL was one of the earliest systems on ARPAnet and, for no good reason, has been recording both its machine room temperature and the outside air temperature at 10 minute intervals for the last 20 years. SAIL and its vending machine are still in use today at the Computer Science Department at Stanford, but they will soon part company -- SAIL is scheduled to die on June 6, its 25th birthday. It has lived a rather full life as computers go. -Les Earnest (Les@SAIL.Stanford.edu)
-----------[000105][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 91 22:43:33 GMT From: andrew@jhereg.osa.com (Andrew C. Esh) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: 10BaseT installation
Well, the boss put the kaibosh on the 10baseT soliloquy, so all I can do is comment on what you folks are talking about. No paper. Something about having to make money and selling information being our business, and all that. I suppose I can say a few things though. 10baseT is easier to install, requires less experience to connectorize, and is more fault tolerant than coax. It is not, as far as we can tell, being hyped by the box builders to generate sales, since we see a legitimate application for it. If you are going to do-it-yourself, make sure you are using cable that is really rated for 10baseT. I have seen so many wierdo cable type from non-descript manufacturers that does no do the job. This cheap stuff is exactly what the cable vendor and your boss with the checkbook are going to choose for you, so be ready with information. Don't even settle for a written guarantee from the cable vendor that it's good wire, since such a guarantee can rarely cover all the trouble and downtime necessary to replace bad cable. Don't go over spec. You need a certain number of twists per foot, and you can't run it further than 100 meters, so stick with it. Fudge, and you pay the price, or more specifically, you pay people like me to come fix it. Cards? We have had trouble with a certain vendor's card. My advice is: It's still early in the game. A few vendors still have cards that don't cut it. Get an in house demonstration from the vendor. They'll do it for free, if they think you're going to buy some cards. Run some data back and forth across them (a process I call flossing), and see if they work okay. The same goes for hubs. Usually a vendor will let you have a demo unit for a week. For PCs, you can use a 3c503 card with a small 10baseT transceiver plugged into the AUI port, and it runs just fine. 10baseT transceivers are getting smaller and cheaper. We have some that are about the size of a deck of playing cards cut in half. They're great. Be careful of EMI. About all I can say is that it gets into 10baseT more than the other cable types. It comes from some interesting places, many of which are common in an office environment. Test equipment? Yes. Use a pair tester. Use a cable scanner. That's about all I can say about that. Want some philosophy? 10baseT, ThinNet, ThickNet, and Fiber are all here to stay. They all have their applications, and none can completely replace any of the others. Add 10baseT to you list of solutions to apply. Networking is growing as we speak. There is a lot of work and discovery and development out there waiting to happen. I started out in Software Engineering, but now I have made the switch to networking, and I travel all seven layers of the OSI stack. I love it. Have fun ... -- Andrew C. Esh andrew@osa.com Open Systems Architects, Inc. Minneapolis, MN 55416-1528 (612) 525-0000 Practicing the OSI Standard
-----------[000106][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 91 23:50:08 GMT From: guy@auspex.auspex.com (Guy Harris) To: comp.protocols.tcp-ip Subject: Re: finger weather
>The RFC for finger specifies fingers behavior when applied to coke
>machines. It is my understanding that CMU used to have a coke machine
>on the internet that followed the stated behavior, although this may
>be an urban legend.
Well, the specified behavior is:
2.5.5. Vending machines
Vending machines SHOULD respond to a {C} request with a list of all
items currently available for purchase and possible consumption.
Vending machines SHOULD respond to a {U}{C} request with a detailed
count or list of the particular product or product slot. Vending
machines should NEVER NEVER EVER eat requests. Or money.
When last I tried fingering CMU's Coke machine, several years ago, it
did report the status of the Cokes - or, at least, what I received back
was a report that purported to be the status of the Cokes in the
machine. I don't know if that was a *real* status report or not; I also
don't know if the machine in question ever ate money.
-----------[000107][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 02:17:52 GMT From: kmcmilla@ub.d.umn.edu (Ken McMillan) To: comp.protocols.tcp-ip Subject: Network Sniffer questions...
Has anyone got any quick pointers for a soon to be novice Network Sniffer user? We have acquired a Sniffer and have it connected to our Ethernet, yet I haven't had time to read through the manuals yet. Is it possible to monitor the traffic between two bridge boxes, or say a router and a bridge box, or a list of boxes on a specific network segment? Any hints appreciated. Ken McMillan kmcmilla@ub.d.umn.edu
-----------[000108][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 04:00:47 GMT From: 08071TCP@MSU.EDU (Doug Nelson) To: comp.protocols.tcp-ip Subject: Re: 'legal' protocol behavior (was: ARP question summary)
>The intent of my reply was to emphasise the importance of standard >practice over RFC definition as a guide for implementors decisions >as to what is 'legal'. As with the MILSTDs (which are absolutely >and completely correct except when they are wrong), an RFC should >not be strictly followed by an implementor if this causes most >existing hosts to lose. I'll stand by my comments - in general, the RFCs ought to be the definition. Certainly there needs to be room to correct errors, resolve ambiguities, extend protocols, and, in some cases, to make allowance for an implementation error in a common implementation, but such deviations ought to be strictly those that have been accepted in the appropriate public forum (IETF, a mailing list, or whatever), and ought to appear in the next revision of the spec. The problems with the MILSTDs have been well documented, as have other RFC errors (such as those documented in the host requirements RFCs, for example). I'm not willing to define "standard practice" as the way the first or the most prevalent implementation does it, without some good justification to go along with it. And I'm not sure why we're dragging out this discussion, since the RFC and "standard practice" are not in disagreement over the case in point! :-> Doug
-----------[000109][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 04:13:05 GMT From: n8844062@unicorn.cc.wwu.edu (mizoguchi scott d) To: comp.protocols.tcp-ip Subject: SLIP???
I've heard some interesting things about SLIPs but don't know how they work or how to install one. Can anyone enlighten me??? Thanks... Scott Mizoguchi n8844062@unicorn.cc.wwu.edu n8844062@henson.cc.wwu.edu
-----------[000110][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 05:39:06 GMT From: sgs@rand.mel.cocam.oz.au (Stuart Szabo) To: comp.protocols.tcp-ip,alt.sources.wanted,comp.sources.wanted Subject: LPD for Sys V
Anyone know of a public domain lpd for System V ?
I already have the 'lprclient' which was gratefully supplied by
cayman.com, but still need something to act as the daemon
on the other end.
Thanks,
--
===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-
Snail: Co-Cam Computer Services | sgs@rand.mel.cocam.oz.au
Abbotsford, VIC 3067 | +61 3 412-3411 (voice)
Melbourne, Australia | +61 3 417-7857 (fax)
-----------[000111][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 06:37:16 GMT From: ji@cs.columbia.edu (John Ioannidis) To: comp.protocols.tcp-ip Subject: Re: How to set up subnets where logical subnet != physical subnet
In article <dcm.671220071@baldur.dell.com> dcm@baldur.dell.com (Dave McCracken) writes: >I am trying to solve a problem we are having trying to set up a >subnet in our corporate network. > > [ Description of their corporate network with MAC-layer bridges and multiple IP subnets on the same wire delted. ] >is necessary for several logical subnets, based on the subnet >mask, to be on the same physical network. The routing code in the IP >driver will cheerfully accept that the other subnets are local when >I specify 0 hops to the route command, but it absolutely refuses >to let me specify an IP address for the router that is not in the >same logical subnet. We are currently running mostly System V Release 4, >but the same problem exists on our Suns and in the straight BSD4.3 >code (I looked in the source). Let us be specific. Assume your campus network is 182.95 (nice unused Class-B network), and that "subnets" 182.95.20, 182.95.21 and 182.95.22 are all on the same wire. Your hostname is host-20-19 and its address is 182.95.20.19. Your ethernet inteface has been configured as # ifconfig le0 182.95.20.19 up netmask 255.255.255.0 -trailers Your routing table looks something like: # netstat -r -n Routing tables Destination Gateway Flags Refcnt Use Interface 127.0.0.1 127.0.0.1 UH 0 0 lo0 182.95.20 182.95.20.19 U 0 5 le0 Now, in order to access machines on the subnets .21. and .22., you add static routes like this: # route add net 182.95.21 182.95.20.19 0 # route add net 182.95.22 182.95.20.19 0 So that your routing table now looks like: # netstat -r -n Routing tables Destination Gateway Flags Refcnt Use Interface 127.0.0.1 127.0.0.1 UH 0 0 lo0 182.95.20 182.95.20.19 U 0 5 le0 182.95.21 182.95.20.19 U 0 0 le0 182.95.22 182.95.20.19 U 0 0 le0 Now, for reasons that I'd rather not know (!), there exists a router (call it router-21-1, address 182.95.21.1) to some other net(s), that you want to use from subnets .20. and .22.. Evidently, you cannot say # route add default 182.95.21.1 1 on host-20-19; the route command will say (and with good reason): add net default: gateway 182.95.21.1: Network is unreachable > >What I would like to know from the collected wisdom of Usenet is >why the restriction is there, and if you think anything would break >if I changed the IP driver in SVR4 to accept a router address outside The "restriction" is there because of the way routes are set up with SIOCADDRT. For gatewaying through another machine (metric > 0), the code checks whether that gateway is on the same subnet as yourself. If it is not, it gives you a "network is unreachable" error. Conceivably, you may want to check whether the subnet of the gateway you are trying to route through already has a route through yourself (which is your case), and thus allow the addition of routes to machines not on your subnet but still on the same physical network. There is no reason this should create any problems, unless someone deletes those static routes. Of course, the whole reason for these network gymnastics is that you need the *ethernet* address of a gateway to send the packets through. The gateway may be on the same wire as you are (so you can send it the packets), but the routing code will not allow you to add it. Instead, you can fool your code into thinking it's using a gateway on its subnet in the following (hacky) way: Assign a dummy IP address on sunet 20 to your router and a machine on the same physical to proxy-arp for it: We've already said that your router is 182.95.21.1. Now, reserve the address 182.95.20.254 for it. On some machine on the wire, add the following ARP entry: # arp -s 182.95.20.254 <router-21-1's ethernet address> and on all machines on subnet .20. add the routing entry: # route add default 182.95.20.254 1 On router-21-1, add the following static routes: # route add net 182.95.20 182.95.21.1 0 # route add net 182.95.22 182.95.21.1 0 Now, every time you want to send something out that would have to go through router-21-1, host-20-19 will arp for 182.95.20.254. The machine with the static ARP entry will respond with .21.1's ethernet address, and your host will send the IP packet to that ethernet address. Now, the router does not care what the source is; it only cares what the destination is. Upon receipt of a packet, if it can route the packet, it will do so. So this takes care of routing packets out. The static routes we set up on router-21-1 will take care of routing packets back to hosts on .20. and .22. >the subnet. I would also like to know is there is a simple way in the >router to present miltiple IP addresses without plugging in extra >network cards. This would be an alternate solution that would not CISCOs can do that. On BSD-derived Unixes, although there is a linked list of addresses for each interface, there are no ioctl's that will allow you to bind multiple addresses to an interface. The ifnet structure has a pointer to a linked list of addresses for the interface, but I suspect that too much code just assumes that there is only one address per interface. I haven't looked at the multicast code lately, but I don't think it uses the linked list of addresses; someone please correct me if I'm wrong (I hope I am; I'll be needing the ability to have the same interface have multiple addresses very soon!) >require changing all clients. > >Thanks, > >-- >Dave McCracken dcm@dell.dell.com (512) 343-3720 >Dell Computer 9505 Arboretum Blvd Austin, TX 78759-7299 Hope this helps /ji In-Real-Life: John "Heldenprogrammer" Ioannidis E-Mail-To: ji@cs.columbia.edu V-Mail-To: +1 212 854 8120 P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027
-----------[000112][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 12:50:00 GMT From: 0004219666@MCIMAIL.COM (Bob Stine) To: comp.protocols.tcp-ip Subject: Re: Graphical TCP/IP Manager
>I am looking for some kind of a graphical Network Manager which >could monitor and display a distributed systems application >(using TCP/IP) on an X interface. >Any pointers to something similar also would be of great help. Sorry if I sound like a broken record, but take a look at RFC 1147, "FYI on a Network Management Tool Catalog." Look up Dual Manager, snmpxbar, snmpxconn, snmpxperfmon, snmpxrtmetric, WIN/MGT Station, and xnetperfmon. Hope this helps. Bob Stine bstine@MCIMail.com
-----------[000113][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 13:19:18 GMT From: hal@GATEWAY.MITRE.ORG To: comp.protocols.tcp-ip Subject: whereis service needed
Here the issue: I am seeing fully qualified domain names with parts I don't recognize. Not that these are wrong but just unfamilar. It would be useful to have access to a server of some kind that would map fragements of a domain name into an geographical location by political subdivision. This might be a useful extension to the current domain names system. Any thoughts??
-----------[000114][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 13:23:00 GMT From: axw@RELAY.PROTEON.COM To: comp.protocols.tcp-ip Subject: Public domain software
Has anyone compiled a list of public domain routing
software? I'm interested in making a list of what protocols
are available for what OS (in source form), and even a list
of PD binary packages.
Please reply to me and I'll repost results.
Asher Waldfogel
axw@proteon.com
-----------[000115][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 15:25:22 GMT From: BHOLMES@CMS.CC.WAYNE.EDU To: comp.protocols.tcp-ip Subject: KA9Q SMTP Config problem
I'm trying to get SMTP in KA9Q to work, but without success. I can FTP in using the id in /ftpusers, but SMTP sends back: 452 Temp file write error After issuing a SMTP '.' to close the message. Can anyone offer advice?
-----------[000116][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 15:33:36 GMT From: gavron@alpha.sunquest.com (Ehud Gavron) To: comp.protocols.tcp-ip Subject: Re: SLIP???
In article <1991Apr10.041305.12068@unicorn.cc.wwu.edu>, n8844062@unicorn.cc.wwu.edu (mizoguchi scott d) writes... #I've heard some interesting things about SLIPs but don't know #how they work or how to install one. Can anyone enlighten me??? The way slips work is that they stay underneath the dresses and prevent... oh, you mean SLIP (singular) :-) SLIP (Serial Line IP) uses a serial communication line (RS232, 433, etc...) as the physical path over which IP traffic works. It's usually implemented at driver level, much as the ETHERNET driver is. IP over serial lines is for all practical purposes (except bandwidth and throughput) identical to IP over any other medium. Catch me via email for further info... # #Thanks... #Scott Mizoguchi # #n8844062@unicorn.cc.wwu.edu #n8844062@henson.cc.wwu.edu Ehud -- Ehud Gavron (EG76) gavron@vesta.sunquest.com
-----------[000117][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 15:37:56 GMT From: gavron@alpha.sunquest.com (Ehud Gavron) To: comp.protocols.tcp-ip Subject: Re: (none)
In article <9104090339.AA07649@beowulf.ucsd.edu>, hliu@UCSD.EDU (Hai-Ning Liu) writes... #please delete my name!!!! Your name has been deleted, and you no longer exist. thanks, Ehud -- Ehud Gavron (EG76) gavron@vesta.sunquest.com
-----------[000118][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 16:07:57 GMT From: jj@dcs.leeds.ac.uk (J Jackson) To: comp.protocols.tcp-ip Subject: Wanted: /etc/hosts to DNS (rfc1035) format conversion program
Has anybody an off-the-shelf script of program that will read an
/etc/hosts file and create the database fileformat required by the
named daemon?
cheers
=======================================================================
Jim Jackson Email :
School of Computer Studies UK - JANET : jj@uk.ac.leeds.dcs
Leeds University Internet : jj@dcs.leeds.ac.uk
Leeds LS2 9JT
UK Phone : +44 532 335451
=======================================================================
Opinions! What Opinions? I just wield the brush round here.
-----------[000119][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 16:19:48 GMT From: jj@dcs.leeds.ac.uk (J Jackson) To: comp.protocols.tcp-ip Subject: SYS V version of SUN's pcnfsd
We require a SYS V version of SUN's pcnfsd (the authentication
and print server daemon). Can anybody point us to a source?
cheers
=======================================================================
Jim Jackson Email :
School of Computer Studies UK - JANET : jj@uk.ac.leeds.dcs
Leeds University Internet : jj@dcs.leeds.ac.uk
Leeds LS2 9JT
UK Phone : +44 532 335451
=======================================================================
Opinions! What Opinions? I just wield the brush round here.
-----------[000120][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 17:21:04 GMT From: raj@hpindwa.cup.hp.com (Rick Jones) To: comp.protocols.tcp-ip Subject: Re: TCP tunnelled in IBM/SNA (more)
I believe that there are several solutions for TCP/IP over/under/in SNA. At the last Interop, I seem to recall hearing something about cisco's being able to tunnel IP thru SNA (or perhaps real soon then...;-) Also, the HP MPE/XL systems offer a link type for their TCP/IP that puts TCP/IP over an SNA backbone. It might be able to do what you are looking for. I'm sure that your local HP and/or cisco rep people could go on and on about these things ;-) rick jones ___ _ ___ |__) /_\ | Richard Anders Jones | HP-UX Networking Performance | \_/ \_/ Hewlett-Packard Co. | "It's so fast, that _______" ;-) ------------------------------------------------------------------------ Being an employee of a Standards Company, all Standard Disclaimers Apply
-----------[000121][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 17:27:56 GMT From: randall@Virginia.EDU (Randall Atkinson) To: comp.std.internat,comp.protocols.tcp-ip Subject: Re: universality of Latin-1
John Gilmore originally wrote:
% And my windows all use ISO Latin 1. If Torbj|rn would send the
% umlauted letter in that standardized character set, it would look right
% in both the States and in Sweden.
In article <1110@sranha.sra.co.jp>,
Erik M. van der Poel <erik@srava.sra.co.jp> responded:
>Have you ever tried to send yourself a message in Latin-1? Did it
>work? And even if *you* have a reasonable version of sendmail (one
>that doesn't strip the 8th bit), what makes you so certain that
>Torbj|rn's message and anyone else's won't pass through a site that
>*does* strip the 8th bit?
It does work for a fair and ever increasing subset of the Internet.
BITNET doesn't do very well with it. Clearly we need to move towards
8-bit and 16-bit and 32-bit transparent mail transport mechanisms.
Fortunately there are a number of possible transport mechanisms out
there to choose from, some of which are already 8-bit transparent.
>Also, what's so "standardized" about ISO Latin-1? What makes it more
>standard than, say, Latin-2?
ISO 8859/1 is NOT any "more standard" than ISO 8859/2, however sites
in the US are in fact migrating towards ISO 8859/1 from US ASCII and
most sites in the US are NOT migrating towards ISO 8859/2 (though they
might support it on the side as vendors begin to). The languages that
are most commonly used in the US are in ISO 8859/1 and the languages
supported by ISO 8859/2 are less commonly used (again in the US as a
whole).
Note that ISO Latin-1 is ISO 8859/1 which is the 8-bit character set
used for Western European languages. ISO Latin-2 is ISO 8859/2 which
is the 8-bit character set for Eastern European languages.
Clearly we need to add additional information to the header of mail
messages to indicate which character set to use. I'm not sure of
the current state of the Internet protocols (RFC 822 et. al.) with
respect to this. If there isn't the equivalent of a "Character-set:"
header yet, serious consideration should be given to adding one with
clearly defined values for at least existing ANSI and ISO character
sets.
Character sets that should have a defined string to use with such a
header field include at least:
ASCII
ISO 8859/1
...
ISO 8859/N (where N is the last defined set)
ISO 10646 (once it gets completed)
The Internet is the dominant mail transport network at present, partly
because so many other networks gateway with it. Getting the Internet
to convert to supporting such needs would be a big step in the right
direction. Perhaps someone on the IETF can comment on their current
activities in this area ??
Ran Atkinson
randall@Virginia.EDU
-----------[000122][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 18:09:56 GMT From: benny@vlss.amdahl.com (Benny Schnaider) To: comp.protocols.tcp-ip Subject: Internet broadcast: INADDR_BROADCAST
Hi,
I am trying to broadcast a message over the internet by using the
INADDR_BROADCAST shorthand notation. I tried this on SunOS 4.01
and got: Network is unreachable... On other system that I tried
the same code it worked.
Code is enclosed.
1. What is the problem ?
2. How common is it to use INADDR_BROADCAST ?
Thanks,
Benny.
____________________________________________________________________________
int sd, on;
struct sockaddr_in sockAddr;
/*
* zero out the socket structures
*/
bzero(&sockAddr, sizeof(sockAddr));
/*
* Open the socket
*/
if ((sd = socket(AF_INET, SOCK_DGRAM, 0)) == -1) {
close(sd);
BPCerror(LOG_WARNING, "in socket creation (request)");
return(ERROR);
}
/*
* Mark the socket to allow broadcast.
*/
on = 1;
if ((setsockopt(sd, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on))) == -1) {
close(sd);
BPCerror(LOG_WARNING, "in SO_BROADCAST");
return(ERROR);
}
/*
* Fill sockAddrAs
*/
sockAddr.sin_family = AF_INET;
sockAddr.sin_port = IPPORT_BOOTPS;
sockAddr.sin_addr.s_addr = INADDR_ANY;
/*
* Bind the socket
*/
if (bind(sd, &sockAddr, sizeof(sockAddr)) == -1) {
close(sd);
BPCerror(LOG_WARNING, "in socket binding (request)");
return(ERROR);
}
/*
* Broadcast the request
*/
sockAddr.sin_addr.s_addr = INADDR_BROADCAST;
if (sendto(sd, msg, sizeof(*msg), 0, &sockAddr, sizeof(sockAddr)) == -1) {
close(sd);
BPCerror(LOG_WARNING, "sendto");
return(ERROR);
} /* sendto */
close(sd);
return(OK);
} /* BPCrequestIP() */
-----------------------------------------------------------------
Benny Schnaider benny@vlss.amdahl.com
Amdahl Corporation, 1250 EAST Arques Avenue,
M/S 246, Sunnyvale CA, 94088-3470
(408) 296 - 0596, (408) 746-3440
-----------------------------------------------------------------
--
-----------------------------------------------------------------
Benny Schnaider benny@vlss.amdahl.com
Amdahl Corporation, 1250 EAST Arques Avenue,
M/S 246, Sunnyvale CA, 94088-3470
(408) 296 - 0596, (408) 746-3440
-----------------------------------------------------------------
-----------[000123][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 19:04:29 GMT From: gordon@FTP.COM (Gordon Lee) To: comp.protocols.tcp-ip Subject: Re: Ethernet spec. - where to get
>From: ogicse!emory!dixie.com!jgd@decwrl.dec.com (John G. DeArmond)
>Subject: Ethernet spec. - where to get
>
>I'd like to find out where to order the original Ethernet specification.
>NOT 802.3, which I already have, but the original "Green Book" specification.
>Commercial or PD sources are fine. Please reply by email.
Green ? Don't you mean Blue Book ? As in DIX (DecIntelXerox) ethernet ?
contact: Fonda Lix Pallone
Xerox Systems Institute
475 Oakmead Parkway
Sunnyvale, CA 94086
(408) 737-4652
== Gordon Lee FTP Software Inc
== voice: (617) 246-0900 26 Princess St
== fax: (617) 245-7943 Wakefield, MA 01880
-----------[000124][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 19:26:52 GMT From: liu@cornelius.ucsd.edu (Hai-Ning Liu) To: comp.protocols.tcp-ip Subject: Sorry, but here is the story
I sincerely apologize to those who feel being annoyed by my multiple deleting-from-mailing-list requests. The story is the following: I sent to tcp-ip-request some time ago and asked to add my name on it. It was added the second day. Later on, I found I can read those message in the mailing list from Usenet comp.protocols.tcp-ip and I do not like to handle all those emails. So I sent requests to tcp-ip-request and asked them to delete me. Day by day, I kept receiving them and yes, I kept asking tcp-ip-request to delete my name. No answer. I did not know what was going on. I felt being ignored. I asked people around also. Some of them suggested I should sent to tcp-ip-relay. I did sent only one copy it to tcp-ip. However, I did not see it back. ( I just found out our postmaster@ucsd deleted that message.) So I thought tcp-ip was monitored. Finally, I was out patient and mailed multiple copies to the net under the above assumption. Again, please accept my humble apology. Also, if you want to delete your name from the list in the future, you may have to wait for very long time after sending email to tcp-ip-request.
-----------[000125][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 20:21:48 GMT From: rickt@wybbs.mi.org (Rick Tucker ) To: comp.protocols.tcp-ip Subject: Re: tn3270 under SCO Unix
In article <31719@usc> mcitron@phad.hsc.usc.edu (Mark Citron) writes: >I post this several months ago and got no reponses but it is so important >for us I figured it is worth another try. > >Does anyone have a 3270 emulator that runs under SCO Unix (we already have >tcp/ip)? We have a critical need and would even consider paying for >a port to SCO Unix. We need to communicate with a remote IBM mainframe >via ethernet-tcp/ip (no other protocols or media). Any help or suggestions >would be greatly appreciated. >-- >Mark Citron >mark@neurosci.usc.edu Have you tried Cleo 3270? They can be reached at 800-233-2536 (some areas) 313-662-2002 Ask for Teresa Rupert. I have used Cleo 3270 in the past and have found it to be a pretty good product. Teresea stated to me that they do have a way to utilize a tcp/ip/ethernet connection.
-----------[000126][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 21:15:02 GMT From: jcrowder@GroupW.cns.vt.edu (Jeff Crowder) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: 10BaseT installation
In article <1991Apr9.224333.13034@jhereg.osa.com> andrew@jhereg.osa.com (Andrew C. Esh) writes: >stay. They all have their applications, and none can completely replace any >of the others. Add 10baseT to you list of solutions to apply. Networking is And THAT'S the Truth... Forget the rest of the rubbish. Andrew has it right. Jeff Crowder
-----------[000127][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 21:54:12 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: Token Ring ARPs
You brought up another valid issue: how does an application which
runs on various media know what the address format is. The right
answer is that it always expects it in one format. I'm not sure
what you mean by opaque, the point is that the application wants
to see the data.
By 'opaque' I mean "uninterpretable, monolithic". The less applications
have to know about the detailed format of addresses (IP or MAC), the better.
Arbitrary MAC addresses can't be parsed without the context of what sort
of LAN they originated on, so applications that need to know e.g. whether
a specific packet was broadcast or multicast have to have tables of LAN
address formats in any case.
....
It would certainly be nice to have the driver hook, but I think the
client of the driver could know the format based on the interface type.
If you're going to be passing MAC addresses around at all, even if you
don't parse them, you *really* need to be uniform across all protocols.
Otherwise you'll be in real trouble if a node supports two protocol
stacks, one which canonicalizes the bit order and the other which doesn't,
and you only have a management tool for one stack. Thus, everyone I've
discussed the issues with to date assumes that the ASI or NDIS drivers
would have to canonicalize the bit order presented at their API in order
to implement this change.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000128][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 91 22:14:37 GMT From: kasten@EUROPA.CLEARPOINT.COM (Frank Kastenholz) To: comp.protocols.tcp-ip Subject: Re: whereis service needed
> From tcp-ip-RELAY@nic.ddn.mil Wed Apr 10 18:08:51 1991
> From: hal@gateway.mitre.org
> To: tcp-ip@nic.ddn.mil
> Subject: whereis service needed
>
>
> Here the issue:
>
> I am seeing fully qualified domain names with parts I don't recognize.
> Not that these are wrong but just unfamilar. It would be useful to
> have access to a server of some kind that would map fragements of a
> domain name into an geographical location by political subdivision.
> This might be a useful extension to the current domain names system.
> Any thoughts??
>
WHOIS does a reasonably adequate job of starting one on
one's way -- for domains that are registered at the NIC.
Here is the output when I "whois" my domain......
europa{kasten}147: whois clearpoint.com
Clearpoint Corporation (CLEARPOINT-DOM)
35 Parkwood Drive
Hopkingon, MA 01748
Domain Name: CLEARPOINT.COM
Administrative Contact:
O'Conner, Russell (RO88) russ@CLEARPOINT.COM
(508) 435-0900 ext 7454
Technical Contact, Zone Contact:
Emery, David I. (DIE2) die@CLEARPOINT.COM
(508) 435-0900 ext 7462
Record last updated on 28-Sep-90.
Domain servers in listed order:
CRACKERS.CLEARPOINT.COM 131.226.1.60
NIC.NEAR.NET 192.52.71.4
TIBERIUS.CLEARPOINT.COM 131.226.3.1
To see this host record with registered users, repeat the command with
a star ('*') before the name; or, use '%' to show JUST the registered users.
Frank Kastenholz
<take a guess where I work!>
-----------[000129][next][prev][last][first]---------------------------------------------------- Date: 11 Apr 91 02:57:02 GMT From: brinkema@fjc.GOV (John R. Brinkema) To: comp.protocols.tcp-ip Subject: (Practically) How fast go I go?
I am designing a rather crude 'mirrored' database system built out of an standard database product. The baseic idea is to copy transaction entires in the backup-journal file over to the mirror system and post the transactions there also. The mirror database is read only. If something goes wrong (ie the transaction journal is messed up -- which apparently happens although *I* have not experienced the phenominon) the whole master database must be copied from the primary system to the mirror system. The database is about 800Mb (and growing). The question is from your experience, how fast can this be done. The connection between the two systems will be Ethernet; the two systems will be quiescient at the time; they are 486-based running Unix, Enet boards are (currently) 'dumb' with tcp-ip the 'standard' protocol. The two machines are physically next to each other (ie. no internet to deal with - just Ethernet (Enet) ). Specifically: 1) where are the bottle necks in such a configuration: the cpu's, disk, the network (Enet), the protocol? 2) I am willing to consider writing a network program using special protocols to do the transfer if the transfer speed would significantly be reduced. So -- if the time to transfer the file using (Unix's) rcp command is '1', what factors would I get if I used ftp; socket/tli level routines in my own program; lower level (ip-connectionless) routines in my own programs; direct Enet access (if I can do it), via my own routines. Rule of thumb or numbers are fine. tnx. jb.
-----------[000130][next][prev][last][first]---------------------------------------------------- Date: 11 Apr 91 05:53:29 GMT From: ljm@FTP.COM (leo j mclaughlin iii) To: comp.protocols.tcp-ip Subject: Re: 'legal' protocol behavior
>>The intent of my reply was to emphasise the importance of standard >>practice over RFC definition as a guide for implementors decisions >>as to what is 'legal'.... > >I'll stand by my comments - in general, the RFCs ought to be the >definition. Certainly there needs to be room to correct errors... >but such deviations ought to be strictly those that have been accepted >in the appropriate public forum (IETF, a mailing list, or whatever)... > >...I'm not willing to define "standard practice" as the way >the first or the most prevalent implementation does it, without some >good justification to go along with it. > I just get tired of having to debug yet another implementation which was written by someone going off in a corner and developing communications software 'according to the RFC' when the RFC deviates from existing practice. I know a number of TCPs which were written by this method (I'll name names privately if you'ld like) which don't actually work all that well. As for acceptance in a public forum, the last IETF saw yet another rousing cheer for considering conformance testing, much less simple belief in conformance to a document, to be worthless in judging if an implementation is ready to be distributed to the world at large. The point being that it is only by conducting interoperability testing with as many different implementations as possible can the quality or 'legality' of an internetworking product be judged. And that the ability to quote a section from a MILSTD or RFC is insufficent cause to loose a noninteroperable implementation on poor users. enjoy, leo j mclaughlin iii ljm@ftp.com
-----------[000131][next][prev][last][first]---------------------------------------------------- Date: 11 Apr 91 08:44:47 GMT From: kzm@hls.com (Keith McCloghrie) To: comp.protocols.tcp-ip Subject: Re: Token Ring ARPs
Jeremy, > I agree that, because of ARP, bridges highlight the multi-media problem. > But what about other applications, say for network management, which > also send MAC addresses in data? The IETF 802.5 MIB (which has been submitted for publication as an RFC) specifies the use of the (802.1a) canonical ordering for MAC addresses when accessed by SNMP, rather than 802.5 transmission ordering. Keith.
-----------[000132][next][prev][last][first]---------------------------------------------------- Date: 11 Apr 91 13:52:35 GMT From: lap@dvncnms.Devoncnms.Unisys.COM (Lisa A. Phifer) To: comp.protocols.tcp-ip Subject: Re: Graphical TCP/IP Manager
>I am looking for some kind of a graphical Network Manager which >could monitor and display a distributed systems application >(using TCP/IP) on an X interface. >Any pointers to something similar also would be of great help. I suggest getting a copy of the DataPro publication "SNMP Product Guide Part 1: Management Systems", October 1990. This publication lists a few dozen products which provide what you are looking for, along with contact info for the vendors. You can reach DataPro at 609-764-0100.
-----------[000133][next][prev][last][first]---------------------------------------------------- Date: 11 Apr 91 14:28:32 GMT From: fks@FTP.COM (Frances Selkirk) To: comp.protocols.tcp-ip Subject: Re: Troubles with BOOTP from FTP
What version are you running? Also, do you have a direct email address? Your path is beyond my interpretive skills (or, at least, patience). Frances Kirk Selkirk info@ftp.com (617) 246-0900 FTP Software, Inc. 26 Princess Street, Wakefield, MA 01880
-----------[000134][next][prev][last][first]---------------------------------------------------- Date: 11 Apr 91 16:13:39 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: Troubles with BOOTP from FTP
I have troubles using the ethernet generic version of BOOTP from FTP Inc.
Let our tech support people know what version of PC/TCP you have; in one
release we didn't catch a buggy bootp client until we'd shipped a few.
Although there are 6 BOOTP Servers responding (definitely right
responding), my PC cant't get its IP address.
If there are six servers, and sometimes it works, it could simply be that
they are all responding at once, and the PC misses the answer. What sort
of LAN monitoring tools do you have available?
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000135][next][prev][last][first]---------------------------------------------------- Date: 11 Apr 91 16:25:56 GMT From: bstrong@sleepy.bmd.trw.com To: comp.protocols.tcp-ip Subject: Goofy Router?
Hello,
I have a problem. We have lost connection to a site we need to
get to (for e-mail mainly). Pinging it gives no response, although
Nslookup can tell me its ip address. They are not down and can get
out onto the rest of the Internet as can we. I think I'm getting
"stuck" at one certain router and I'd like confirmation/correction on
this. Here's what's going on:
we're oz.bmd.trw.com (129.193.100.6) and we're trying to get to
afsc-bmo.af.mil (132.62.71.1)
When I did a traceroute to afsc-bmo.af.mil on 4/10/91 I got this -
1 outdsg.nba.TRW.COM
.
.
.
13 192.52.195.1
14 * * *
15 * * *
.
.
.
30 * * *
This tells me why I can't get to afsc-bmo - I'm exceeding 30 hops - but
what the heck is happening? I know there's no way it's even 30 hops to
this site - we could mail to them last week. What is this router at
192.52.195.1 doing? When I traceroute just to 192.52.195.1 I got this -
1 outdsg.nba.TRW.COM
.
.
.
13 192.52.195.1 (192.52.195.1) 1080 ms 1030 ms 1070 ms
14 192.52.195.1 (192.52.195.1) 1060 ms !P 1020 ms !P 1050 ms !P
What does the second hop with the bang 'P' for? I've never seen this !P
and didn't see anything in out documentation (using Wollongong TCP/IP for
VMS). Now, one more thing, I did another traceroute this morning
(4/11/91) and got the same thing except that the IP address, 192.52.195.1,
now has a logical address and shows up as MOFFETT-FLD-MB.DDN.MIL in the
traceroute, but the trace is still identical to the previous one. Are
these guys just configuring a new router or what? I don't know who to
contact to ask in person about it. Could someone help???
As is obvious, I'm a real novice so please look past my ignorance.
===============================================================================
Bryan Strong TRW * Ogden, UT * USA
Computing Services / Software Support
Internet: bstrong@oz.bmd.trw.com
Phone: 801.625.8090
-----------[000136][next][prev][last][first]---------------------------------------------------- Date: 11 Apr 91 18:00:45 GMT From: ken@racerx.UUCP (Ken Hardy) To: comp.protocols.tcp-ip Subject: Re: Internet broadcast: INADDR_BROADCAST
In article <BENNY.91Apr10110956@dimona.vlss.amdahl.com>, benny@vlss.amdahl.com (Benny Schnaider) writes:
> Hi,
>
> I am trying to broadcast a message over the internet by using the
> INADDR_BROADCAST shorthand notation. I tried this on SunOS 4.01
> and got: Network is unreachable... On other system that I tried
> the same code it worked.
> Code is enclosed.
>
> 1. What is the problem ?
> 2. How common is it to use INADDR_BROADCAST ?
>
> Thanks,
> Benny.
You need to have a valid network in the network portion of
the internet address. This is a routine I use on Suns to
build a broadcast address. May not be cleanest code, but
it works on Sun 4.0 & 4.1. The print statements yield:
Name = [racerx]
Host ID 80420006
Net ID 00008042
Bcast ID 8042ffff
This get physically resolved on our system to a broadcast ethernet
address. This may or may not be passed by bridges. IP routers
may not pass it based on the network portion of the IP address,
and even if a bridge or router passes it, other IP hosts on another
network may not pay attention to it if they have another network
i.d.
----------------------------------------------------------------
int bcast_address ()
/*
*
*/
{
struct in_addr bcip;
unsigned ipad,
netp;
extern struct hostent *getmyhostent () ;
if (my_he == (struct hostent *)0)
{
my_he = getmyhostent () ;
memcpy (&myip.s_addr, my_he->h_addr, sizeof (myip.s_addr));
memcpy (&my_ipaddr[0], my_he->h_addr, sizeof (myip.s_addr) ) ;
}
netp = inet_netof (myip);
bcip = inet_makeaddr (netp, INADDR_BROADCAST);
if (bug)
{
printf ("Name = [%s]\n", my_he->h_name);
printf ("Host ID %08lx\n", htonl (myip.s_addr));
printf ("Net ID %08lx\n", netp);
printf ("Bcast ID %08lx\n", htonl (bcip.s_addr));
}
RETURN (bcip.s_addr);
}
----------------------------------------------------------------
--
Ken Hardy uunet!racerx!ken ken@racerx.UUCP
-----------[000137][next][prev][last][first]---------------------------------------------------- Date: 11 Apr 91 18:05:20 GMT From: bill@banana.fedex.com (bill daniels) To: comp.protocols.tcp-ip Subject: looking for "spray" source
Can someone point me to an archive (I haven't FTP capabilities) that contains the source for the "spray" utility? bd -- these ravings are in no way sanctioned by federal express corp bill daniels | voice: (901)797-6328 federal express corp | fax: (901)797-6388 box 727-2891, memphis, tn 38194 | email: bill@banana.fedex.com
-----------[000138][next][prev][last][first]---------------------------------------------------- Date: 11 Apr 91 18:41:24 GMT From: sfalken@caen.engin.umich.edu (Steve Falkenburg) To: comp.protocols.tcp-ip Subject: Re: HyperFTP
In article <9103181622.AA01779@elroy.cit.cornell.edu>, dug@CORNELLC.CIT.CORNELL.EDU writes: > > There was a question on this list about client FTP implementations for > the Macintosh. Here's some information from the author, Doug Hornig, > about a Hypercard-based FTP client from Cornell. > > Mark Bodenstein (mab@cornellc.cit.cornell.edu; 607-255-8059) > Cornell University > ----------------------------Original message---------------------------- > Mark, > Yep HyperFTP is in the public domain. I first send copies to > sumex-aim.standford.edu where it can be anonymously FTPd from the > /info-mac/comm directory. I've seen it show up in other places as well. > -- Doug > > Just for some self-advertising, there is a Macintosh Application to do FTP available from mondo.engin.umich.edu (141.212.68.14). It's called XferIt, and is based on a multi-window browser type interface. It supports multiple connections, and will transfer files in the background (including bulk transfers). For more info, etc... just download it from mondo.engin.umich.edu, or mail me (I'm the author) for more info. -steve (P.S. also coming soon: yet another Mac newsreader in the next issue of Apple's "develop" magazine, and probably posted to the net soon after) ---------------------------------------------------------------------- Steve Falkenburg (sfalken@mondo.engin.umich.edu) | Great pate', but Macintosh Programming/Support | I've gotta motor! Computer Aided Engineering Network, U of Michigan | -Heathers
-----------[000139][next][prev][last][first]---------------------------------------------------- Date: 11 Apr 91 19:01:19 GMT From: zweig@cs.uiuc.edu (Johnny Zweig) To: comp.protocols.tcp-ip Subject: TCP/IP traffic characterization
I was just thinking about running benchmarks/test-suites for TCP/IP and realized that I haven't noticed any really thorough traffic characterizations in the literature. I have in mind things like a probability-density function for number of octets sent during a connection, possibly correlated with some burstiness measures and mean throughput. Then there are even cooler things to wonder about, for instance, what percentage of connections are to passive (listening) sockets (I would guess 99+%)? And what percentage of connections follow the "A calls B, B finishes and closes its end of the connection, A closes in response" pattern? How often do SYNs and/or FINs "cross" in the network? What percentage of TCP packets ever require retransmission? I could go on, but you get the point. If I wanted to exercise my TCP/IP in a "realistic" way, I would have to argue that my load-generator did "screwy" things (like active connect-requests crossing in the mail) more or less the right percentage of the time (or enough not to throw all my numbers off). I could see things such as the average number of TCP connections mattering to a benchmark (a naive search algorithm for finding connection descriptors only bites you if there are more than a few of them active at any time, for instance). Does anyone know of what sorts of traffic characterizations for TCP/IP there are out there? Just wondering... -Johnny Curious
-----------[000140][next][prev][last][first]---------------------------------------------------- Date: 11 Apr 91 22:08:39 GMT From: logier@cheops.qld.tne.oz.au (Rob Logie) To: comp.protocols.tcp-ip Subject: Re: Wanted: /etc/hosts to DNS (rfc1035) format conversion program
jj@dcs.leeds.ac.uk (J Jackson) writes: >Has anybody an off-the-shelf script of program that will read an >/etc/hosts file and create the database fileformat required by the >named daemon? >cheers >======================================================================= >Jim Jackson Email : >School of Computer Studies UK - JANET : jj@uk.ac.leeds.dcs >Leeds University Internet : jj@dcs.leeds.ac.uk >Leeds LS2 9JT >UK Phone : +44 532 335451 >======================================================================= > Opinions! What Opinions? I just wield the brush round here. I was faced with a similar problem on my network, but fortunalty I have a few HP9000 running HP-UX 7.0, which just happerns to have a function that does what you want. It will even produce config files for non-HP machines if you throw that right parameters at it (I manage the configuration on a Pyramid MIS with it. Have a look around you network to see if there is a HP9000, and that will solve your problem. Email me if you want more info on how to do it. Regards -- Rob Logie EMAIL: logier@cheops.qld.tne.oz.au Telecom Australia FAX: +61 7 837 4704 TNE Computer Support Services PH: +61 7 837 5174 Brisbane Office "These are my opinions alone"
-----------[000141][next][prev][last][first]---------------------------------------------------- Date: 11 Apr 91 22:20:12 GMT From: erick@sunee.waterloo.edu (Erick Engelke) To: comp.protocols.tcp-ip Subject: Re: Packet drivers for Proteon Pronet-10
as jbvb@ftp.com writes: >As far as I know, there never have been any implementations of Class 2 >(Proteon ProNET-10 token ring) Packet Drivers. PC-IP has a linked-in I'd have to agree with James as far as Class 2 goes, but not Class 1. While the proNET 10 technology is nice, you are better off using it to imitate a Class 1 ethernet system. That's what I did and it works perfectly for every commercial and PD TCP/IP package configured for Ethernet The 48 bit Ethernet address space can be nicely made from a zero extended 8 bit proNET address or even a zero extended 32 bit IP address. I'd love to give you our driver, but it works using our local network/disk bios so it would not be at all useful to you. However, if you are willing to do the development, I could offer some useful hints. Erick -- ---------------------------------------------------------------------------- Erick Engelke Watstar Computer Network Watstar Network Guy University of Waterloo Erick@Development.Watstar.UWaterloo.ca (519) 885-1211 Ext. 2965
-----------[000142][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 00:19:02 GMT From: dlv@cunyvms1.gc.cuny.edu (Dimitri Vulis, CUNY GC Math) To: comp.std.internat,comp.protocols.tcp-ip Subject: Re: universality of Latin-1
In article <1991Apr10.172756.4991@murdoch.acc.Virginia.EDU>, randall@Virginia.EDU (Randall Atkinson) writes:
> ISO 10646 (once it gets completed)
"Unicode" seems both more practical and more realistic.
>Ran Atkinson
>randall@Virginia.EDU
Dimitri Vulis, D&M
BITNET: DLV@CUNYVMS1
Internet: DLV@CUNYVMS1.GC.CUNY.EDU
Snail: Department of Mathematics/Box 330
City University of New York Graduate Center
33 West 42 Street
New York, NY 10036-8099
USA
-----------[000143][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 00:23:12 GMT From: elf@oldearth.EBay.Sun.COM (Ed Fleschute) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Looking for comments on network analyzers
In article <4669@dftsrv.gsfc.nasa.gov>, lanmaint@nssdcb.gsfc.nasa.gov (Dave Yoest) writes: |> (TEXT DELETED) |> We have a LANALYZER (bought from Excelan before the Novell buyout) |> that we have used for 4 or 5 years. I have also demo'ed the SNIFFER |> and find them to be comparable. In my opinion the SNIFFER is just |> a little better at protocol decoding and the LANALYZER is a little |> better at finding physical layer hardware problems. Overall they |> are just about equal, If you're more into protocol "problem tracking" |> then you might be better off with the SNIFFER. If you do more hardware |> problem solving then the LANALYZER might be a better choice. |> I'll second the evaluation that Dave has performed. The LANALYZER is a great tool for doing physical layer analysis. If you are experiencing hardware problems on a cable the LANALYZER is phenominal at pinpointing the source of the trouble very quickly. The SNIFFER is excellent at higher level protocol analysis. If I was looking to find a NFS protocol bug I definitly would prefer the SNIFFER. |> |> Not to cloud the issue since you have already narrowed the field, but |> did you look at the Hewlett Packard 4972 LAN protocol analyzer. |> I like it better than both the SNIFFER and LANALYZER (my opinion). |> (TEXT DELETED) |> Two things I don't like about the HP 4972. 1) It is VERY heavy. If this isn't going to be mounted in a rack or on a cart, get something else. 2) I found the HP difficult to program. With the software they had two years ago it was difficult to do a display sorted on the hosts with the highest error counts. This may have been updated in the last couple of years. Ed Fleschute (My opinion only)
-----------[000144][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 02:36:20 GMT From: dsamperi@Citicorp.COM (Dominick Samperi) To: comp.unix.wizards,comp.protocols.tcp-ip Subject: Thin wire or twisted pair?
My organization is considering the use of twisted pair point-to-point connections as an alternative to thin wire Ethernet. The motivation is to reduce our expenses. The environment is one where there is little tolerance for network failures (a trading floor). I'm familiar with thin wire Ethernet, but know little about twisted pair technology. Could somebody comment on their experiences with twisted pair connections. Are they cheaper than thin wire? More/less reliable? Is there a throughput/bandwidth hit in using twisted pair? How large? Is twisted pair easier/harder to maintain? Thanks for any information on this. -- Dominick Samperi -- Citicorp dsamperi@Citicorp.COM uunet!ccorp!dsamperi
-----------[000145][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 03:31:17 GMT From: HANK@TAUNIVM.TAU.AC.IL (Hank Nussbacher) To: comp.protocols.tcp-ip Subject: Where does one get old RFCs?
I was trying to retrieve an old RFC (468) and tried NIC.DDN.MIL and NIS.NSF.NET (as RFC 1177 tells me to) and each no longer have the old RFCs apparently online. Or am I looking in the wrong place? Can anyone tell me where I should look and perhaps update RFC1177 with the correct information? Thanks, Hank
-----------[000146][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 04:30:24 GMT From: Andy.Linton@comp.vuw.ac.nz (Andy Linton) To: comp.protocols.tcp-ip Subject: Re: Wanted: /etc/hosts to DNS (rfc1035) format conversion program
In article <1991Apr11.220839.17490@cheops.qld.tne.oz.au>, logier@cheops.qld.tne.oz.au (Rob Logie) writes: |> I was faced with a similar problem on my network, but fortunalty I have a |> few HP9000 running HP-UX 7.0, which just happerns to have a function |> that does what you want. What is it called????
-----------[000147][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 04:31:30 GMT From: jay@axiom.maths.uq.oz.au (Joseph Young) To: comp.sys.mac.comm,aus.mac,comp.protocols.tcp-ip Subject: Will KA9Q talk to a Mac SE ethernet card?
I have a Mac SE with a Novell NAE1000 ethernet card ... can KA9Q talk to this card? Most of the documentation I have refers to PC hardware ... I have an example autoexec.net file that shows how to use the AppleTalk port but no mention is made about Macintosh EtherNet cards. Any help would be appreciated. Joe Young jay@axiom.maths.uq.oz.au ... Internet j.young@qut.edu.au ... Internet
-----------[000148][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 04:44:21 GMT From: TAYBENGH@NUSDISCS.BITNET (THE AGEIS) To: comp.protocols.tcp-ip Subject: Is the data received using recvfrom() in SOCK_RAW fragmented by IP?
Hi netlander,
In BSD socket, one can implement a new protocol on top of IP using
SOCK_RAW with the designated protocol number. Then, one can receive the
data using recvfrom() call. The recvfrom() returns the data with the IP header.
So far so good. But if the sender sends large amount of data in one single
send(), and the IP layer needs to fragment the data to a few packets, then
can we receive the data in onr single recvfrom() [Note: this implies the IP
layer on the receiver side re-assemble all the packets b4 passing the data
up to us]? Or do we need to take care of the fragments ourself by inspecting
the IP header and do re-assemble if necessary?
Which one is true? Could somebody shed some light on me please?
Thanks a lot.
- Beng Hang (email: taybengh@nusdiscs.bitnet)
-----------[000149][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 06:04:32 GMT From: brett@solar.card.inpu.oz.au (Brett Sealey) To: comp.protocols.tcp-ip Subject: SLIP problems under SunOS 4.1.1
Lately we have been playing with the "Beta SLIP for SunOS 4.0" written by
Rayan Zachariassen. We have been using it on Sun SPARCstation IPC's
running SunOS 4.1.1 (This may well be the problem).
Occasionally these machines crash with a "panic: mget" or even more rarely
a "panic: mfree" message.
Looking into the SLIP code I can see a MGET call within the tty_slip.c
file. MGET is a macro which can cause a "panic: mget" if the next mbuf on
the free list (mfree) is not correctly marked as "MT_FREE".
As I see it this is reasonable, the question is why does this condition
arise in the first place and, even more importantly, how can it be
prevented.
A comment in tty_slip.c indicates that :-
/* (SLIP_CLUSTERS doesn't work under SunOS 4.0) */
Is this true under SunOS 4.1.1?
If anyone has any clues as to what could be causing this rather
embarassing problem I'd be very keen to hear from them.
Thanks (in advance :-)
Brett Sealey
______________________________________________________________________________
__ __ ___ ____ ____
/__) /__) /_ / / brett@solar.card.inpu.oz.au
/__) / \ /__ / / Brett Sealey
______________________________________________________________________________
-----------[000150][next][prev][last][first]----------------------------------------------------
Date: 12 Apr 91 06:30:37 GMT
From: reschly@BRL.MIL ("Robert J. Reschly Jr.")
To: comp.protocols.tcp-ip
Subject: Re: TCP benchmarking> > I've encountered another "benchmark." > > First try the 4.3BSD `ping -l9999999 target` and look at the packet rate. > ...but before you do that, be sure your mbuf code is fixed. On BSD systems of early 4.3TAHOE vintage or earlier, you could get an mbuf panic from all those unprocessed ICMP Echo Replies. Sure surprised us. Later, Bob P.S. It has been long enough to forget the exact details, but it was caused by a mget() with DONT_WAIT flag set on a receive, or something like that.
-----------[000151][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 11:54:25 GMT From: nrm1838@dsacg3.dsac.dla.mil (James D. Cassell) To: comp.protocols.tcp-ip Subject: Network Management
We are interested in anyone's experience in managing large router networks.
Our network currently consists of 23 routers (cisco) connecting large
(600+ hosts) LANs. The router network will be expanded to bring in
another 250-350 LANs (mostly much smaller LANS than are now on the
network).
We currently have no network management hardware or software (for the
WAN stuff). We have looked at cisco's NetCentral Station, but have
heard mixed reviews of this product from other users (too slow, can't
handle very large networks, etc.).
Any information, experiences, war stories, etc. will be greatly
appreciated. We have our hands full managing the current 23 routers,
I can't immagine 400 of them!
Thanks,
Jim
--
Jim Cassell | jcassell@dsac.dla.mil
DSAC-RMB, P.O. Box 1605 | 614-238-9971
Columbus, Ohio 43216 | Input standard disclaimer here ...
-----------[000152][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 12:33:02 GMT From: rja7m@calico.cs.Virginia.EDU (Ran Atkinson) To: comp.std.internat,comp.protocols.tcp-ip Subject: Re: universality of Latin-1
UNICODE isn't a sufficient solution as it doesn't fully support (for example) Vietnamese. DIS 10646 is a sufficient solution. I wish it were otherwise, but I have to live in the real world...
-----------[000153][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 12:46:14 GMT From: barryf@aix01.aix.rpi.edu (Barry B. Floyd) To: comp.protocols.tcp-ip Subject: Re: finger weather (really Coke machines)
Is anyone archiving this thread of postings (interesting devices attached to networks)? I am interested in receiving the archive when this discussion dies down. respond directly to me or post to the group. -- +--------------------------------------------------------------------+ | Barry B. Floyd \\\ barry_floyd@mts.rpi.edu | | Manager Information Systems - HR \\\ usere9w9@rpitsmts | +-Rensselaer Polytechnic Institute--------------------troy, ny 12180-+
-----------[000154][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 12:47:41 GMT From: eliot@chutney.rtp.dg.com (Topher Eliot) To: comp.std.internat,comp.protocols.tcp-ip Subject: Re: universality of Latin-1
In article <1991Apr10.172756.4991@murdoch.acc.Virginia.EDU>, randall@Virginia.EDU (Randall Atkinson) writes:
|> In article <1110@sranha.sra.co.jp>,
|> Erik M. van der Poel <erik@srava.sra.co.jp> responded:
|> >Have you ever tried to send yourself a message in Latin-1? Did it
|> >work? And even if *you* have a reasonable version of sendmail (one
|> >that doesn't strip the 8th bit), what makes you so certain that
|> >Torbj|rn's message and anyone else's won't pass through a site that
|> >*does* strip the 8th bit?
|> It does work for a fair and ever increasing subset of the Internet.
|> BITNET doesn't do very well with it. Clearly we need to move towards
|> 8-bit and 16-bit and 32-bit transparent mail transport mechanisms.
I expected to see someone else post a more authoritative answer, but since
none has been forthcoming, I will venture. The folks who work on such things
have been considering the 8-bit, different-codeset issues, as part of a much
larger picture of including such things as graphics and other binary
information in mail. Since those are harder problems, it means that they
won't have solutions all that quickly. There is a mailing list on this
subject; if you really need it I can probaly dig out a lead on how to get
onto that mailing list.
|> Fortunately there are a number of possible transport mechanisms out
|> there to choose from, some of which are already 8-bit transparent.
Ack! "Fortunately"? There is an ancient curse: "may you live in interesting
times". I think it's modern equivalent is "may you have many standards to
choose from".
--
Topher Eliot Data General DG/UX Internationalization
(919) 248-6371 62 T. W. Alexander Dr., Research Triangle Park, NC 27709
eliot@dg-rtp.dg.com {backbone}!mcnc!rti!dg-rtp!eliot
Obviously, I speak for myself, not for DG.
-----------[000155][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 13:02:38 GMT From: clu@malihh.hanse.de (Carsten Lutz) To: comp.protocols.tcp-ip Subject: DialUp-IP with Telebit-Modems
Hi !
Some weeks ago, someone posted a pointer to an FTP-archive, where one could
get a DialUp-IP-Source for Telebit-Modems. I missed this posting, could
someone please mail me the name/adress of this FTP-site ?
Thanks in advance,
Carsten
--
+ Carsten Lutz, Rellingen, FRG / clu@malihh.hanse.de +
+ Voice : +49 4101 207871 Fax: +49 4101 27757 Traily : +49 4101 22306 +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ ...This is usually because the networks transfer the mail by emulating +
+ punched cards ! - Donnalyn Frey +
-----------[000156][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 13:29:07 GMT From: caserta@athena.mit.edu (Francesco Caserta) To: comp.protocols.tcp-ip Subject: finger weather is discontinued
Well, I've been the one who has announced in this list the services
provided to the Internet community by stormy.atmos.washington.edu, and
now announce its death (temporarily?). This is what you will now get
by fingering weather @stormy.atmos.washington.edu
====================================================================
[stormy.atmos.washington.edu]
Dear Users of Weather Forecasts,
The Department of Atmospheric Sciences at the University of Washington
receives NWS weather information through a 3rd party vendor. We get
this data at a reduced rate from the vendor. However, as part of the
contract we are not supposed to distribute this data outside the
University without paying an additional $150/month licensing fee. My
department is unwilling to pay such a fee (they aren't too crazy
about providing such a service in the first place).
Therefore, I must restrict access to our forecast information to the
University of Washington. I am sorry to do this, but I will not
knowingly violate the terms of our contract. I do not think offers to
pay the extra $150/month will make any difference in this decision.
If you are on a campus with a Meteorology or Atmospheric Sciences
Department, you might try seeing if they will locally distribute such
information.
I hope you found the service useful while it lasted, and I hope that
the situation will change someday, and that I can provide such a
service in the future.
Harry Edmon (harry@atmos.washington.edu)
=====================================================================
At least my initial posting has been useful to bring up information
(see the subsequent postings) that were unknown to the most.
Francesco Caserta
-----------[000157][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 13:29:12 GMT From: davecb@yunexus.YorkU.CA (David Collier-Brown) To: comp.protocols.tcp-ip,alt.sys.sun Subject: Re: SLIP problems under SunOS 4.1.1
brett@solar.card.inpu.oz.au (Brett Sealey) writes: | Lately we have been playing with the "Beta SLIP for SunOS 4.0" written by | Rayan Zachariassen. We have been using it on Sun SPARCstation IPC's | running SunOS 4.1.1 (This may well be the problem). | | Occasionally these machines crash with a "panic: mget" or even more rarely | a "panic: mfree" message. | | Looking into the SLIP code I can see a MGET call within the tty_slip.c | file. MGET is a macro which can cause a "panic: mget" if the next mbuf on | the free list (mfree) is not correctly marked as "MT_FREE". Oy veh ist mir! We suffered a minor variant of this on StunDOS 3.5, where one could get mgetclr panics by essmingly exhausting the mbuf space. This sounds similar enough to make me suspicious. Can someone comment on the version of tcp/ip code used in SunOS 4.1.1? We only have sources for 3.0, and that's maybe BSD4.2 at the best (:-() --dave -- David Collier-Brown, | davecb@Nexus.YorkU.CA | lethe!dave 72 Abitibi Ave., | Willowdale, Ontario, | Today's featured dish: CANADA. 416-223-8968 | Sun-dried alligator.
-----------[000158][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 13:47:08 GMT From: bmiller@CABELL.VCU.EDU (Bryan Miller) To: comp.protocols.tcp-ip Subject: Sniffer
We are looking at the possibility of purchasing a Sniffer....anyone out there have any experience with it? Thanks, Bryan Miller Network Engineer Virginia Commonwealth University bmiller@cabell.vcu.edu
-----------[000159][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 14:04:04 GMT From: jessea@homecare.uucp (Jesse W. Asher) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: What protocol is used for leased lines?
Our company is planning to hook up 7 remote sites up to our Sun Server
via digital point to point leased lines. My question comes from not
knowing enough about leased lines and about tcp/ip. What the phone
company proposes is DSUs connected to RS-232 ports at each of the
connection. Here is where I get lost. What should I run on either end?
Should I be running SLIP or PPP because the DSU is connected to an
RS-232 port? This doesn't seem right since many people out there are
using leased lines and are not using slip. Can anyone give me any
insights as to how _you_ would connect up two sites via leased lines
and how you would use tcp/ip to do it? Thanks much.
--
Jesse W. Asher NIC Handle: JA268 Phone: (901)386-5061
Health Sphere of America Inc.
5125 Elmore Rd., Suite 1, Memphis, TN 38134
UUCP: ...!banana!homecare!jessea
-----------[000160][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 15:04:59 GMT From: karl.kleinpaste@osc.edu To: comp.protocols.tcp-ip Subject: Re: SLIP problems under SunOS 4.1.1
brett@solar.card.inpu.oz.au writes: Lately we have been playing with the "Beta SLIP for SunOS 4.0" written by Rayan Zachariassen. We have been using it on Sun SPARCstation IPC's running SunOS 4.1.1 (This may well be the problem). Occasionally these machines crash with a "panic: mget" or even more rarely a "panic: mfree" message. I am using Rayan's code on a SunOS 4.1.1 Sun4/110. It works fine after you install Sun PatchID 100149-02, except for an occasional assertion panic of the following form when sliplogin goes down (in my case, when the modem line drops; I'm using it for dialup SLIP): | assertion failed: vp->v_stream == stp, file: ../../os/str_io.c, line: 609 | panic: assertion failed I've written a note about the problem to sunbugs@sun.com, but since it involves use of a non-standard driver, I doubt it'll get much attention. Before installing 100149-02, I consistently got "panic: mclput" whenever substantial amounts of data would begin to transfer. Note that there exist both -01 and -02 versions of this fix; install -02 to be maximally up-to-date. The README for -02 notes that the -01 version didn't deal in IP options properly. 100149-02.tar.Z can be ftp'd from saqqara.cis.ohio-state.edu:pub/slipware. --karl
-----------[000161][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 15:35:35 GMT From: brian@ucsd.Edu (Brian Kantor) To: comp.protocols.tcp-ip Subject: Re: Wanted: /etc/hosts to DNS (rfc1035) format conversion program
1 each stupid awk script that handles 90% of our needs for conversion of
hosts table to domain database format:
/^#/ {print "; "$0;next}
/^$/ {next}
{
split($2,hn,".");
printf("%s\tIN\tA\t%s\n", hn[1], $1);
for(i=3; i< 9; i++)
{
if (!$i) break;
split($i,nn,".");
if (hn[1] != nn[1])
printf("%s\tIN\tCNAME\t%s\n", nn[1], hn[1]);
}
}
-----------[000162][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 15:48:00 GMT From: Sabo@DOCKMASTER.NCSC.MIL To: comp.protocols.tcp-ip Subject: Re: Graphical TCP/IP Manager
>>I am looking for some kind of a graphical Network Manager which >>could monitor and display a distributed systems application >>(using TCP/IP) on an X interface. >>Any pointers to something similar also would be of great help. > >I suggest getting a copy of the DataPro publication "SNMP Product >Guide Part 1: Management Systems", October 1990. This publication >lists a few dozen products which provide what you are looking for, >along with contact info for the vendors. You can reach DataPro >at 609-764-0100. You can also reach DataPro toll-free at (800) 328-2776. Ask for extension 2444. This is Jill Huntington-Lee's line. Jill will send out copy's of the "SNMP Product Guide Part 1: Management Systems" free of charge. Also, a new publication entitled "SNMP Product Guide Part 2: Agents" has just been completed, for those who are interested in knowing what networking products current have SNMP agent support. _Michael
-----------[000163][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 15:49:43 GMT From: bjork@NISC.SRI.COM (Steven Bjork EJ223) To: comp.protocols.tcp-ip Subject: Re: Where does one get old RFCs?
In article <9104120331.AA03866@ucbvax.Berkeley.EDU> HANK@TAUNIVM.TAU.AC.IL (Hank Nussbacher) writes: >I was trying to retrieve an old RFC (468) and tried NIC.DDN.MIL and >NIS.NSF.NET (as RFC 1177 tells me to) and each no longer have the old >RFCs apparently online. Or am I looking in the wrong place? Can anyone The NIC has hard copies of all RFC's in its archives. Some of the early RFC's that may have been online seem to have become "lost", perhaps on someone's backup tapes out there. If you consult the file rfc-index.txt, it will list the online status of any RFC. Any leads, rumours, or otherwise, leading to retrieval of the Missing RFC's, will be rewarded with a batch of my Chocolate Chip Cookies... P.S. The TeX recipe is available on ftp.nisc.sri.com, netinfo/cookies.tex. --Steven
-----------[000164][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 15:54:14 GMT From: fxs@stowe.UUCP (Fran Sullivan) To: comp.protocols.tcp-ip Subject: setting up mail on SCO
One of my co-workers has SCO-Unix running on a AT-386 PC. He is fully connected to our local net with TCP/IP etc. He would like to be able to send mail to other boxes on the local net, but does not have the appropriate software support. IE: SMTP Does anyone know of any Public Domain software i can use to do this.
-----------[000165][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 15:55:25 GMT From: fxs@stowe.UUCP (Fran Sullivan) To: comp.protocols.tcp-ip Subject: setting up mail on SCO
One of my co-workers has SCO-Unix running on a AT-386 PC.
He is fully connected to our local net with TCP/IP etc.
He would like to be able to send mail to other boxes on the
local net, but does not have the appropriate software support.
IE: SMTP
Does anyone know of any Public Domain software i can use to
do this ??
|\/\/\/|
* Fran Sullivan | |
* fmrco!fxs@uunet.uu.net | |
* Unix Tech Support | (o) (o)
* Fidelity Information Systems C _) ...Hey Dude!
* Boston, MA 02109 | `__|
* ( 617 ) 570-2762 | /
/ \
/ ---- \
-----------[000166][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 15:57:22 GMT From: echan@cadev6.intel.com (Eldon Chan ~) To: comp.protocols.tcp-ip Subject: Re: Wanted: /etc/hosts to DNS (rfc1035) format conversion program
IBM RS6000 running AIX 3.1 has such scripts build in too. They are pretty small scripts, it should work on most UNIX. Eldon Chan ------------------------------------------------------------------------ From tcp-ip-RELAY@NIC.DDN.MIL Fri Apr 12 02:37:12 1991 Received: by scdt (5.57/10.0i); Fri, 12 Apr 91 02:37:08 PDT Received: by hermes.intel.com (5.57/10.0i); Fri, 12 Apr 91 02:22:24 PDT Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 11 Apr 91 17:17:51 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA28297; Thu, 11 Apr 91 17:07:36 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Apr 91 22:08:39 GMT From: uhccux!munnari.oz.au!brolga!bunyip.cc.uq.oz.au!cheops!logier@ames.arc.nasa.gov (Rob Logie) Organization: Telecom Australia, TNE Computer Support Services Subject: Re: Wanted: /etc/hosts to DNS (rfc1035) format conversion program Message-Id: <1991Apr11.220839.17490@cheops.qld.tne.oz.au> References: <7571.9104101607@csunb0.dcs.leeds.ac.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Status: R jj@dcs.leeds.ac.uk (J Jackson) writes: >Has anybody an off-the-shelf script of program that will read an >/etc/hosts file and create the database fileformat required by the >named daemon? >cheers >======================================================================= >Jim Jackson Email : >School of Computer Studies UK - JANET : jj@uk.ac.leeds.dcs >Leeds University Internet : jj@dcs.leeds.ac.uk >Leeds LS2 9JT >UK Phone : +44 532 335451 >======================================================================= > Opinions! What Opinions? I just wield the brush round here. I was faced with a similar problem on my network, but fortunalty I have a few HP9000 running HP-UX 7.0, which just happerns to have a function that does what you want. It will even produce config files for non-HP machines if you throw that right parameters at it (I manage the configuration on a Pyramid MIS with it. Have a look around you network to see if there is a HP9000, and that will solve your problem. Email me if you want more info on how to do it. Regards -- Rob Logie EMAIL: logier@cheops.qld.tne.oz.au Telecom Australia FAX: +61 7 837 4704 TNE Computer Support Services PH: +61 7 837 5174 Brisbane Office "These are my opinions alone"
-----------[000167][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 16:25:17 GMT From: PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD) To: comp.protocols.tcp-ip Subject: Re: SLIP??? Scores. MNP???
On Wed, 10 Apr 91 04:13:05 GMT <tcp-ip-relay@NIC.DDN.MIL> said:
>I've heard some interesting things about SLIPs but don't know
>how they work or how to install one. Can anyone enlighten me???
I'll comment about the other often asked questions: whether to, why so slow...
SLIP performance (on low bit rate lines) is that of the (sending) TCP's.
This holds for any slow line, but is aggravated by SLIP's unreliability.
Indeed, a TCP sending data has to figure the timeouts used to resend data
carefully. Too short makes it a plague of duplicate packets. Line errors
may get the value occasionally very high and get things slow if the TCP is
sluggish in reducing the timeout value.
Some rough figures (9600 bauds MNP modems) when FTP receiver is:
SunOS 4.0.3 1.1 Kb/sec (presumably any BSD 4.3)
VM TCP/IP 1.2.2 (IBM) .75
CUTCP .25 (could be improved with other parameters, but
had better do without such customization).
All hosts were on Ethernet, SLIP was between routers.
MNP means that the impact of line errors was almost nil (but another cause
for loosing packets got me mad for some time).
MNP made the throughput very slightly better, nothing to speak of,
but shows an annoying echo latency in terminal mode that doesn't exist without
it. I guess it's because of a time value it uses to wait for enough bytes to
assemble into packets to minimize the checksum overhead, and this has no
reason to be for what's the noninterrupted flow of datagrams.
Is there a way to get rid of this latency?
Andr'e PIRARD SEGI, Univ. de Li`ege
B26 - Sart Tilman B-4000 Li`ege 1 (Belgium)
pirard@vm1.ulg.ac.be or PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU
-----------[000168][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 16:48:26 GMT From: arena@goethe.UUCP (mike arena) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: TCP/IP programming library for PC's
I am looking for an implementation of TCP/IP on the PC which provides a programming library. I would only need the PC to act as a client. Specifically, I am looking for the socket family of functions (socket(), connect(), etc.) I don't need TELNET or FTP (but that wouldn't preclude me from buying the package). Also, if SLIP or even dialup SLIP are supported, I would be very interested. I have information about SUN's PC-NFS product and it seems that it would do all that I want (plus NFS), however, it costs $395 per PC. I would prefer a product which either had a lower run-time system cost or a library which would not need a run-time distribution (i.e. all of the TCP/IP facilities my program uses would be linked into my application). -- -------------------- Michael Arena Credit Technologies bu.EDU!icad!goethe!arena
-----------[000169][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 18:10:08 GMT From: ced@bcstec.uucp (Charles Derykus) To: comp.unix.aix,comp.protocols.tcp-ip Subject: ftp problem
We've encountered a problem ftp'ing from an RS/6000 AIX 3.1 running the 3003 update. No matter what Unix platform is the target, the login fails as though an extra carriage return were appended to the account name. A sample session is included: srloads:/u/sks6373> ftp n1 Connected to n1.ca.boeing.com. 220 n1 FTP server (IBM RT) ready. Name (n1:root): sks6373 331 Password required for sks6373. 500 'PASS ': command not understood. Login failed. ftp> The target here was an IBM/RT but other unix platforms behave identically or pretty near. Has anyone encountered this? Other than a ".netrc" file are there any workarounds? Thanks, Charles DeRykus Internet: ced@bcstec.boeing.com Boeing Computer Services UUCP: ...!uunet!bcstec!ced Renton, WA. M/S 6R-37 (206) 234-9223
-----------[000170][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 18:48:29 GMT From: j_rodin@hpfcso.FC.HP.COM (Jon Rodin) To: comp.protocols.tcp-ip Subject: Re: Packet drivers for Proteon Pronet-10
>As far as I know, there never have been any implementations of Class 2 >(Proteon ProNET-10 token ring) Packet Drivers. PC-IP has a linked-in >driver for the P1300 interface, so do some of the commercial products. >Proteon has an non-board-independent interface-sharing spec, which >they've implemented in their Netware and we in our PC-222 part. Proteon is working on NDIS drivers for their cards, which should be available real-soon-now. Whenever those driver become available, one could use the dis_pkt driver to run packet driver based protocols over Proteon cards. Also I believe Proteon supports the ASI interface. I don't know if a packet driver-to-ASI translater exists, but ASI does support multiple concurrent protocol stacks. Jon j_rodin@cnd.hp.com
-----------[000171][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 19:49:10 GMT From: donp@na.excelan.com (don provan) To: comp.protocols.tcp-ip Subject: Re: 'legal' protocol behavior
The News Manager) Nntp-Posting-Host: na Reply-To: donp@novell.com (don provan) Organization: Novell, Inc., San Jose, California References: <9104110553.AA03082@ftp.com> Date: Thu, 11 Apr 1991 22:04:41 GMT In article <9104110553.AA03082@ftp.com> ljm@ftp.com writes: >I just get tired of having to debug yet another implementation which was >written by someone going off in a corner and developing communications >software 'according to the RFC' when the RFC deviates from existing practice. On the other hand, i got a little tired of people measuring protocol correctness by whether it interoperated with BSD 4.2. >The point being that it is only by conducting interoperability testing with >as many different implementations as possible can the quality or 'legality' >of an internetworking product be judged. Interoperability testing is certainly important, but a failure to ineroperate still requires a way to determine which implementation is in error, and the specs provide a mechanism for making that determination. Depending on interoperability testing only is exactly what got the TCP/IP community into the "BSD mess" that we're finally leaving behind us. I, for one, would rather not see that era repeated. don provan donp@novell.com
-----------[000172][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 20:23:51 GMT From: ric@ace.sri.com (Richard Steinberger) To: comp.protocols.tcp-ip Subject: need network advice
I have a few networking questions that I could use some help answering. I'm still reading Stevens' Unix Coimmunications book and am not a guru. Thanks in advance to all who reply. Configuration: We have a uVAX with TCPIP SW (from DEC, UCX I think) and an attached Aptec interface. The uVAX needs to xfer files to another (unix) computer, and at the moment this computer is a Multiflow (basically a Unix mini-super based on VLIW architecture). In the future, the Multiflow might be replaced by a SUN, DEC or other machine acting as a fileserver. The usual procedure is that the unix computer retrieves files via FTP or by using the APTEC bus. FTP (TCP over enet) transfer rates have been as high as about 100K bytes/second. Aptec rates have been less that that, but the company that developed the Aptec interface promises that they now can transfer files at 2 - 3 times FTP rates. (Aptec sells what they call IO computers. Their forte' is the rapid transfer of data from computer to computer, generally VAX to VAX, but they have an interface for SUN and some [incomplete, if you ask me. Allegedly Mitre has a turnkey file xfer package] interface SW). Question 1: Is FTP considered the fastest reliable way to transfer medium to large files (500KB - 10MB) between a VAX/VMS machine and a BSD-4.3 unix machine (using ethernet as the physical medium)? Would adding another enet interface card to each computer and connecting a second enet cable make any sense? I.e., could a second cable allow multiple (2) file transfers simultaneously, and could a vax and unix machine use both interfaces at once? Would this be transparent to the end user? Are there other (enet-based HW and/or SW) possibilities? A colleague at another company mentioned that something he called a "DECnet-Internet Gateway" would allow file xfer at 2 - 3 times FTP rates. Perhaps he means DECnet-Ultrix network SW. Is this mush? Or can DECnet xfer rates dramatically exceed FTP over enet (or is it the reverse, or is it more complicated than that)? Question 2: I would like a repeatable way to put a known traffic load on an ethernet-based LAN? Is there something more scientific than continuously transfering a large file from one host to another? Are there any (bundled) utilities in VMS or MultiNet that can display some quantifiable measure of network traffic (updating at a selectable interval)? Or, conversely, would it be better to attach a network analyzer (or buy monitoring SW)? Question 3: This is about fileserver performance. Does anyone know of any PD fileserver benchmark tests. I would like to propose a simple (but hopefully not simple-minded) test strategy for evaluating the performance of a few candidate fileservers. We are primarily concerned with a server's ability to provide (via NFS) files to 2 or 3 clients with "minimal" delays. This same server would simultaneously be receiving files via FTP (or other enet SW) and perhaps doing some computation (to reformat the files). Is there something more elaborate than doing one (or several) rcp(s) to/from server to client and measuring the time? What is likely to be the performance "bottleneck"? The ethernet itself, or the fileserver's ability to retrieve and store data from/to disks? Again, thanks to anyone who can provide help, guidance or suggestions on these questions. I do appreciate it. Suggestions for books to read also welcome. regards, ric steinberger ric@rml2.sri.com ric@ace.sri.com 415-859-4300
-----------[000173][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 91 21:38:04 GMT From: MAP@LCS.MIT.EDU (Michael A. Patton) To: comp.protocols.tcp-ip Subject: Oddball devices on the Internet
Here is my contribution for the unusual devices discussion. This is
not all strictly network related, but the connected history is itself
interesting. These are my personal recollections of the last 18 years
at Tech Square, home of the MIT AI Lab and Project MAC (now LCS).
When I first arrived at MIT (1973), the AI Lab's Knight TV (KTV) front
end was already hooked up to control several unusual devices in the
building. The KTVs were special video displays connected through a
PDP11 operating as a front end for the KA10 (at that time MIT-AI,
later AI.AI.MIT.Edu, now scrap metal). The keyboards had several
extra keys for special uses (most were available for special use in
programs). One of these was labeled ESCAPE (there was also an ALTMODE
that generated ASCII code 27 octal) and reserved for interacting with
the front end. There were lots of mundane functions connected with
the key (e.g. ESC-F for "finger" or "free" showed the current list of
users), but there were two that were special. ESC-D operated the
electric lock on the door to the computer room (the entire ninth floor
of the building, which also included a number of hackers offices, the
rest were one floor down). ESC-E summoned an elevator, it knew
whether your display was on the 8th or 9th floor and pushed the
appropriate button. The time it took for an elevator to arrive from
the first floor in the dead of night was about the same as the time to
walk out to the lobby. Initially these were only available from the
special consoles and worked directly off the front-end system, the
host had no real way of affecting this.
Then, in the late 70's, the AI Lab was developing a new style of
operation that used special purpose individual workstations (nobody
had invented the name workstation yet, as I recall, but that's what
they were) that were the predecessors of the Lisp Machines later
manufactured by Symbolics, LMI, TI, and others. These workstations
needed some communications media that was faster than what we commonly
used then and the CHAOSnet was developed. Based loosely on the Xerox
3Mbps Ethernet developed a little earlier, it ran at the blinding
speed of 10Mbps! CHAOSnet was CSMA/CA (that's Collision Avoidance, as
opposed to Ethernet which only does CD, Collision Detection). The
routers used in this net ran on LSI11 systems and the door controls
and elevator controls were moved to one of these boxes so that the
workstations could get the same functionality as the old displays
(they initially used the same keyboards and later an expanded version
referred to as the "Space Cadet" keyboard). As the CHAOSnet expanded
around campus this meant that anyone could open the door or summon an
elevator, even outside the building and these were eventually
disconnected.
Another addition around this time was the Weather Computer and the
Weather Reporting Service. The Weather Computer was an LSI11
(seperate from the routers, but only connected to the network) with a
parallel interface to a HeathKit (I think) weather station. By using
a datagram protocol over the CHAOSnet any system could interrogate the
Weather Computer for the current info about inside and outside
temperature, pressure, and wind speed (actually, I think the "inside
wind speed" was hard coded as zero, we didn't buy two of these). The
Weather Computer didn't have any state, it just engaged in a datagram
exchange where it read the current values and returned them. Then a
daemon was written to run on one of the Labs timesharing systems which
interrogated the Weather Computer frequently and assembled longer term
information. If you fingered "weather" on this machine you got back a
summary report of current and recent past readings, I believe daily
(today and yesterday) and weekly high/low/average for each value.
__
/| /| /| \ Michael A. Patton, Network Manager
/ | / | /_|__/ Laboratory for Computer Science
/ |/ |/ |atton Massachusetts Institute of Technology
Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)
-----------[000174][next][prev][last][first]---------------------------------------------------- Date: 13 Apr 91 01:52:04 GMT From: vcerf@NRI.RESTON.VA.US To: comp.protocols.tcp-ip Subject: RARE Networkshop at Blois May 13-16, 1991 (France)
==================
2nd European Networking Conference
----------------------------------
Blois, 13.5. - 16.5.1991
Final Programme
---------------
Organised by RARE
in collaboration with
EARN, EurOpen, Internet Activities Board, NorduNet,
Ministere de la Recherche et de la Technologie
Monday, 13. 5. 1991
- -------------------
Morning : Registration
12h30 Buffet lunch
Plenary Sessions
- ----------------
Opening
-------
Christian Michau, CNRS, Paris
14h00 Opening Remarks
Juergen Harms, Univ. Geneve
14h10 Official Welcome
Paul Quiles, Ministre des Postes,
Telecommunications et de l'Espace
14h30 The Challenge of Workstations to Networking
Louis Pouzin, THESEUS, Sophia Antipolis
15h15 The Challenge of Networking to Workstations
Greg Chesson, Silicon Graphics, Mountain View
16h00 Coffee
The IT Campus
-------------
Howard Davies, Univ. Exeter
16h30 The Networked Campus
Bernard Levrat, Univ. Geneve
17h00 Workstation to Internet : Problems, Solutions and Challenges
Lee G. Caldwell, Novell, Salt Lake City
17h30 Information Services on the Wired Campu
Bruce Royan, Univ. Stirling
18h00 Recess
(18h30 : Welcome Reception City of Blois at the Palais des Congres)
Tuesday, 14. 5. 1991
- --------------------
Session Group A
- ---------------
Funding and Policy
------------------
Jaime Perez-Vidal, CEC, Bruxelles
9h00 Organisational Structures for Providing International Services
Klaus Ulmann, DFN, Berlin
9h30 Transmission Services in a Deregulated Europe
NN, France Telecom, Paris
10h00 Acceptable Use Policy
James Hutton, JNT, Didcot
10h30 Coffee
11h00 NREN : The Need for High Performance Services
Bill Bostwick, Washington DC
11h30 Report on the RARE High-Speed Networking Symposium
Paul van Binst, Univ. Libre Bruxelles
12h00 Expanding the Internet to a Global Environment.
But ... How to Get Connected?
Elise Gerich, Merit, Ann Arbour
12h30 Lunch
Session Group B
- ---------------
CONS / CLNS Interworking
------------------------
Les Clyne, JNT, Didcot. Phil Gross
9h00 Transatlantic Workshop : Background
Les Clyne, JNT, Didcot
9h15 Transatlantic Workshop : Reports and Recommended Actions
Christian Huitema, INRIA, Sophia Antipolis
9h50 Transatlantic Workshop : Agreed Policy, Subsequent Activities
Phil Gros, CNRI, Washington DC
10h30 Coffee
Lower Layer Technology
----------------------
Sylvain Langlois, EDF, Paris
11h00 FDDI Concentrators and their Environment
Michael Franzen, Siemens, Munchen
11h30 TCP/IP Internetwork Communication Through LANs
Interconnected by Dikon Meganet.
Trond Arne Kongsli, FORUT, Tromsoe
European Engineering Planning Group
-----------------------------------
Sylvain Langlois, EDF, Paris
12h00 Presentation of the EEPG Report
Kees Neggers, SURFnet, Utrecht
12h30 Lunch
Plenary Sessions
- ----------------
Network Management Strategies and Techniques
--------------------------------------------
Christian Michau, CNRS, Paris
14h00 Management of the Operation of the NSF Backbone
Elise Gerich, Merit, Ann Arbour
14h30 NORDUnet Experiences in Network Management
Bernhard Stockmann, NORDUnet, Stockholm
15h00 LAN Management by Cooperation : HP and the University of Geneva
Charlie Solomon, HP Labs, Bristol
15h30 Coffee
Group Communication
-------------------
Claus Sattler, Akad. Wiss., Berlin
16h00 Building Group Communication on OSI
Steve Benford, Univ. Nottingham
16h30 Supporting Collaboration in a Distributed Electronic Environment
Pippa Hennessy, Univ. Nottingham
17h00 Computer supported Cooperative Work;
Origins, Concepts and Research Initiatives
Paul Wilson, CSC, Slough
17h30 Recess
(20h00 : Gala Dinner at the Chateau de Blois)
Wednesday, 15. 5. 1991
- ----------------------
Morning : available for unscheduled meetings
Session Group A
- ---------------
Applications and Services
-------------------------
Dennis Jennings, Univ. College Dublin
14h00 The NSF X.400 Pilot Project
Alf Hansen, Univ. Wisconsin
14h30 Implementing an E-mail Fax Gateway from Scratch
Peter Flynn, Univ. Cork
15h00 The Integration of the X Window System
and ISO Virtual Terminals for a "European Workstation Environment"
John Dyer, JNT, Didcot
15h30 Coffee
16h00 Naming Strategies and Techniques
Christian Huitema, INRIA, Sophia Antipolis
16h40 X.500 Pilot Status
David Goodman, Univ. College London
17h05 The COSINE Information Service
Graham Knight, Level 7 Ltd, Bracknell
17h30 Recess
(Evening : Dinner at the Caves de Montlouis)
Session Group B
- ---------------
High Performance Strategies and Techniques
------------------------------------------
Paul van Binst, Univ. Bruxelles
14h00 Jargon Tutorial and Techniques
John Burren, Rutherford Lab, Didcot
15h00 Global WAN-MAN Architecture for the 90's
Remy Despres, RCE, Paris
15h30 Coffee
16h00 From Megabits to Gigabits : Theory and Practice
Francois Fluckiger, CERN, Geneve
16h30 CHEOPS: Really Using a Satellite
Brian Carpenter, CERN, Geneve
17h00 Transport System for an Integrated Broadband Communication
Environment Proposals of ESP
Horst Westbrock, DETECON, Berlin
18h00 Recess
(20h00 : Dinner at the Caves de Montlouis)
Thursday, 16. 5. 1991
- ---------------------
Session Group A
- ---------------
Multimedia Techniques
---------------------
Robert Cooper, JNT, Didcot
9h00 Facilities for Proposed Pilot Activity Using Office Document
Architecture Facilities from University College London
and the PODA Project
Peter Kirstein, Univ. College, London
9h30 Media Synchronization and High Speed Networking in MultiG
Steve Pink, SICS, Stockholm
10h00 Multimedia Workstations
Jean-Louis Leonhardt, IRPEACS, Lyon
10h30 Coffee
Security
--------
Sven Tafvelin, Chalmers Univ., Gothenburg
11h00 The X.500 Directory Service and the Data Protection Act
Julia M. Hill, Herriot-Watt Univ., Edingburgh
11h30 CERT - Computer Emergency Response Team
Chris Harvey, Observatoire de Paris
Session Group B
- ---------------
Protocol Interworking Techniques
--------------------------------
Vint Cerf, CNRI, Washington
9h00 TCP-IP / OSI Interoperation
Bernard Sales, Univ. Brussels
9h30 DoD Internet Protocols and JANET
Jon Crowcroft, Univ. College London
10h00 Integrated Routing for Dual TCP/IP - OSI Environments
Ross Callon, DEC, Littleton
10h30 Coffee
Distributed Systems
-------------------
Bernard Delcourt, RARE, Amsterdam
11h00 Open Distributed Processing
11h30 Remote Procedure Calls : a Stepping Stone to ODP
David Robinson, DEC, Reading
Plenary Session
- ---------------
Closing
-------
Klaus Ullmann, DFN, Berlin
12h00 Closing Remarks
Klaus Ullmann, DFN, Berlin
12h15 Recess, buffet lunch
-----------[000175][next][prev][last][first]---------------------------------------------------- Date: 13 Apr 91 01:56:38 GMT From: vcerf@NRI.RESTON.VA.US To: comp.protocols.tcp-ip Subject: RARE Networkshop REGISTRATION Information
2nd European Networking Conference
----------------------------------
Blois, 13.5. - 16.5.1991
Final Programme
---------------
Organised by RARE
in collaboration with
EARN, EurOpen, Internet Activities Board, NorduNet,
Ministere de la Recherche et de la Technologie
Registration
- ------------
REGISTRATION FEE
The registration fee covers: coach transfer from and to the
railway station (on May 13 and May 16), a collection of summaries
of presentations distributed in the Conference package, a copy
of the Conference Proceedings (to be distributed in Autumn, 1991),
entry to all sessions, refreshments daily, four lunches, the
Welcome reception on May 13 and the Gala dinner on May 14.
Please note that accompanying persons are welcome to attend all
social events but may not attend any of the technical sessions.
EARLY Registration Fee FF 2,200
LATE Registration Fee FF 2,500
The early registration fee applies to all fees received before
March 15th. Please ensure that your payment is made net of all
bank charges and in French Francs.
Please note that an administration charge of FF 40 will apply in
respect of cancellations received by us, in writing, before April 10.
No registration fees can be refunded in case of cancellations
received by us, in writing, after April 10.
Registration will take place in La Halle aux Grains at Blois,
on Monday May 13 from 9.00 to 14.00.
VENUE
The event will take place in the historic region of the "Chateaux
de la Loire" at Blois, France. The conference itself will be
organized in the ancient building of the "Halle aux Grains",
converted into a modern conference center with ample space for
small meetings in the margin of the conference. The conference aims
at an attendance of no more than 400 participants registered on a
first come - first served basis.
LANGUAGE
The official language of the conference will be English.
ACCOMPANYING PERSONS SOCIAL PROGRAMME
Monday May 13 Evening - Welcome Reception
Tuesday May 14 Visiting Beauregard, Cheverny &
Chambord Castles - FF 350 per person including lunch -
Departure at 09.30hrs from Blois in coach, first visit
of Beauregard Castle and its park. Then Cheverny Castle
which is a seigniorial house with sumptuous decoration
and furniture of the 17th century. At 12.15hrs, lunch at
'Les 3 Marchands' in Cheverny. In the afternoon, visit of
Chambord Castle, which is the biggest Castle of La Vallee
de la Loire, built by King Francois Ier. Back in Blois at 17.00 hrs.
Wednesday May 15 Morning - Visiting Clos Luce, Leonard
de Vinci House - FF 120 per Person (minimum 30 participants) -
Departure at 08.45hrs and back in Blois at 12.30hrs- afternoon -
Visiting Blois, the old town and the Castle - FF 75 per person
or, visiting Chaumont Castle which looks down upon the Loire
river, and its luxurious stables - FF 110 per person
(minimum 30 participants) -
Evening - Dinner at 'Les Caves de Montlouis'
restaurant - FF 250 per person, including cocktail and coach from
and back to Blois.
All tours are based on a minimum of paying participants. In case
there are not enough participants, the right is reserved to cancel
the tour(s), in which case a full refund will be made.
ACCOMMODATION
Accommodation has been reserved in several hotels in Blois,
both 2** and 3*** categories and single and twin rooms.
Please note that no accommodation can be reserved without a
deposit of FF 500 per person and that an administration charge
of FF 40 will apply in respect of cancellation received by us,
in writing, before April 10th. Refund of FF 210 can be made in
respect of cancellations received by us, in writing, between
April 10th and May 10th. No refund can be made after May 10th.
For people wanting to travel during the week-end, some accommodation
will be possible for May 11 and May 12.
Rates include hotel service charges, government taxes and continental
breakfast:
Sharing Single
Twin Room Room
in FF per room in FF
2** hotel 260 - 450 210 - 390
3*** hotel 400 - 550 300 - 460
Hotel prices are correct at time of going to print. However, the
right is reserved to amend some of these prices should any increase
in hotel rates and/or Government taxes occur.
GETTING TO BLOIS
By car Blois is 180 kilometers from Paris (Porte d'Orleans),
driving on the autoroute direction Tours/Bordeaux
until Blois.
By train Trains depart from Paris/Austerlitz station at:
06.25 -> 08.08 in Blois
07.02 -> 08.45 (not on Saturday and Sunday)
07.41 -> 09.09
10.09 -> 12.01 (not on Sunday)
12.00 -> 13.27
13.48 -> 15.40
16.43 -> 18.36 (not on Saturday and Sunday)
17.15 -> 18.39
17.47 -> 19.08 (not on Saturday)
19.32 -> 21.12
On Thursday May 16, trains depart from Blois station at:
08.51 -> 10.33 in Paris
10.29 -> 12.19
12.17 -> 13.43
13.40 -> 15.09
15.37 -> 17.10
16.40 -> 18.25
17.28 -> 19.00
19.05 -> 20.56
The above timings are given in good faith for delegates' assistance.
However, no responsibility can be accepted for changes in these
timings.
Coach transfers to the Conference location will be provided from
the station on Monday 13 May in the morning from 08.45 to 13.27
and on Thursday from the conference location to the station.
It is recommended that all delegates requiring a coach transfer
complete the relevant section on the registration form.
If you need more information, please contact Mrs. Denyset
by e-mail: Denyset@FRORS12.Bitnet
Please complete and return registration form to:
2nd Joint European Networking Conference 1991
La Halle aux Grains
Place de la Republique
41000 - BLOIS
FRANCE
Tel. : (33) 5474 2122
Fax : (33) 5474 8261
Tlx : 752 332 F (Ref: CNRS / JENC)
- ------------please cut here--------please cut here-------------
REGISTRATION FORM
Only One Delegate Per Form (Please photocopy extra forms if required)
family name (1).........................first name ............Mr/Mrs
organization/company.................................................
postal address: street..................city ........................
state/county ...................postal code .........................
country ........................e-mail ..............................
telephone: office .................home ........................
telex ..................fax .........................
accompanied by (2) .................................................
(3) .................................................
I require accommodation for ........... people as follows:
...............single room(s) ............... twin/double room(s)
Arriving May ........ Departing May ........ No. of nights ..........
Hotel PREFERRED: 2** O 3*** O (Please mark)
I shall arrive : by car O
by train O
I shall use coach transfer: on Monday May 13 O
on Thursday May 16 O
PAYMENT:
1. by cheque in French Francs to 'CONGRES RARE'
2. by Bank Transfer in French Francs to:
CONGRES RARE
BRO BLOIS No. 10528 00001 01 00257893 C 26
Bank address : 3, rue Gallois - 41000 BLOIS - FRANCE
Please ensure payment is net of all charges and attach a copy of
your bank slip to assist us in matching this form with your payment.
Payment to cover:
..ONE Registration Fee (FF 2200/FF 2500 late) FF .......
..Ticket(s) for Dinner at Montlouis on May 15 @ FF 250 p.p. FF .......
..Ticket(s) for Chambord/Cheverny tour on May 14 @ FF 355 p.p. FF .......
..Ticket(s) for Clos Luce tour on May 15 morning @ FF 120 p.p. FF .......
..Ticket(s) for Blois tour on May 15 afternoon @ FF 75 p.p. FF .......
..Ticket(s) for Chaumont tour on May 15 afternoon @ FF 110 p.p.FF .......
..Accommodation Deposit(s) @ FF 500 p.p. FF .......
__________
FF .......
SIGNED : Date:
Please complete and return to:
2nd Joint European Networking Conference 1991
c/o Palais des Congres
La Halle aux Grains
Place de la Republique
41000 - BLOIS
FRANCE
Tel.: (33) 5474 2122
Fax: (33) 5474 8261
Tlx.: 752 332 F (Ref: CNRS/JENC)
-----------[000176][next][prev][last][first]---------------------------------------------------- Date: 13 Apr 91 03:15:29 GMT From: RHH@BROWNVM.BROWN.EDU (Bob Haring-Smith) To: comp.protocols.tcp-ip Subject: tn3270 key mapping for DECstations
Has anyone devised a key mapping for tn3270 on DECstations that takes
advantage of the function keys on the keyboard? I would love to
received a copy of the map file if you have. Many thanks in advance.
--Bob Haring-Smith
rhh@brownvm.brown.edu
401-863-1982
-----------[000177][next][prev][last][first]---------------------------------------------------- Date: 13 Apr 91 03:33:31 GMT From: proberts@disk.uucp (Phil Roberts) To: comp.protocols.tcp-ip Subject: Re: whereis service needed
kasten@EUROPA.CLEARPOINT.COM (Frank Kastenholz) writes:
> > From tcp-ip-RELAY@nic.ddn.mil Wed Apr 10 18:08:51 1991
> > From: hal@gateway.mitre.org
> > To: tcp-ip@nic.ddn.mil
> > Subject: whereis service needed
> >
> >
> > Here the issue:
> >
> > I am seeing fully qualified domain names with parts I don't recognize.
> > Not that these are wrong but just unfamilar. It would be useful to
> > have access to a server of some kind that would map fragements of a
> > domain name into an geographical location by political subdivision.
> > This might be a useful extension to the current domain names system.
> > Any thoughts??
> >
>WHOIS does a reasonably adequate job of starting one on
>one's way -- for domains that are registered at the NIC.
[[ His domain listing deleted. ]]
I thought the NIC was for the Milnet only. Am I understanding you correctly
that the NIC can also provide me with domains outside the Milnet? If that
is true, how does one go about finding a site when one doesn't have Telnet
capability?
--
***************************************************************************
|
Phil Roberts | Internet: proberts@disk.uucp
|
-----------[000178][next][prev][last][first]---------------------------------------------------- Date: 13 Apr 91 03:41:08 GMT From: ddl@husc6.harvard.edu (Dan Lanciani) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.dcom.lans Subject: packet driver on ODI converter
A new version of the PD-on-ODI converter is available for anonymous ftp from husc6.harvard.edu in pub/odipkt. All 1.09 functions are now implemented but note the following: -reset_interface and set_address always return failure. -as_send_pkt is as described in the 1.09 spec--this probably isn't what you want. -set_rcv_mode claims success but the ODI interface doesn't allow control of receiver mode anymore. (However multicast support *does* work.) Operation has been tested for blue book and 802.3, but not for 802.5. As I have received no feedback about the last version I'll assume it was bug-free (or unused :). Dan Lanciani ddl@harvard.*
-----------[000179][next][prev][last][first]---------------------------------------------------- Date: 13 Apr 91 07:00:12 GMT From: ji@cs.columbia.edu (John Ioannidis) To: comp.protocols.tcp-ip Subject: Re: Is the data received using recvfrom() in SOCK_RAW fragmented by IP?
In article <912473B7FC7F400347@nusdiscs.bitnet> TAYBENGH@NUSDISCS.BITNET (THE AGEIS) writes:
>
>Hi netlander,
> In BSD socket, one can implement a new protocol on top of IP using
>SOCK_RAW with the designated protocol number. Then, one can receive the
>data using recvfrom() call. The recvfrom() returns the data with the IP header.
Correct. Remember to set the proper protocol type in the third field
of the socket(2) call. There is a kernel patch (see, e.g., the
distribution notes for traceroute) so that if you set IPPROTO_RAW,
you place your own IP header in the packet you are sending rather than
rely on the system for it. This can be useful, e.g., for sending your
own options. In 4.3Reno (at least), you can also accomplish that by
setting the RINPF_HDRINCL flag.
>So far so good. But if the sender sends large amount of data in one single
>send(), and the IP layer needs to fragment the data to a few packets, then
>can we receive the data in onr single recvfrom() [Note: this implies the IP
>layer on the receiver side re-assemble all the packets b4 passing the data
>up to us]?
All of the above. When send-ing the packet, the IP layer will fragment
the datagram if you are trying to send a packet larger than your MTU.
A limitation you may come up against is the send buffer size (2K by
default). You can change that by setting the appropriate socket-level
option, as in the following code:
...
int bufsz=16384; /* send messages up to 16K in length */
int sd;
sd = socket(AF_INET, SOCK_RAW, 42);
if (sd < 0)
perror("rawsocket"), exit();
if (setsockopt(sd, SOL_SOCKET, SO_SNDBUF, &bufsz, sizeof bufsz) < 0)
perror("setting options"), exit();
....
Upon receipt, if the receive buffer size is large enough (again,n
settable with the SO_RCVBUF option), the IP layer will reassemble your
packet and pass it to you. Remember that when the raw socket interface
passes you a packet back, the ip_len field contains the length of the
*protocol* part of the packet (i.e., total length - IP-header lenght),
and that all sizes are in host order (network addresses are still in
network order).
> Or do we need to take care of the fragments ourself by inspecting
>the IP header and do re-assemble if necessary?
I don't think you can do that even if you want.
> Which one is true? Could somebody shed some light on me please?
> Thanks a lot.
>
>- Beng Hang (email: taybengh@nusdiscs.bitnet)
I hope that's enough light!
/ji
In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027
-----------[000180][next][prev][last][first]---------------------------------------------------- Date: 13 Apr 91 17:04:33 GMT From: romkey@ASYLUM.SF.CA.US (John Romkey) To: comp.protocols.tcp-ip Subject: TCP/IP programming library for PC's
FTP Software's dev kit costs (I think) about $500, but you can license a kernel-and-configuration-only run time for around $150 or so. (You better verify those numbers; it's been a while since I knew them for sure) You can ask info@ftp.com for more details. The dev kit includes sockets. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice/fax: 415 594-1141
-----------[000181][next][prev][last][first]---------------------------------------------------- Date: 13 Apr 91 17:18:18 GMT From: csu@alembic.acs.com (Dave Mack) To: comp.protocols.tcp-ip,comp.dcom.modems,alt.sys.sun Subject: Looking for PPP Connection in DC Area
I am looking for someone in the DC area (local phone call from Northern Virginia) who is interested in establishing a Point-to- Point Protocol dialup connection. I would prefer someone who knows more than I do about PPP, but if not, I guess we'll learn together. I would also prefer a V.32 connection (or PEP, but I hear that doesn't work so well.) If you're interested but don't have the software, I can provide a version of the Clement/Fox PPP software for Suns running OS4.x. I also have an older version that allegedly runs on Vaxen under BSD4.3, but I've never tried it. Finally, I have a copy of the KA9Q package that includes PPP support. I've never tried that, either. (Note: installation of anything other than the KA9Q package requires a kernel rebuild, so you have to have root privileges.) Any takers? (For those who don't know, PPP is a data link layer protocol that allows packet transport across serial lines. Its advantage over SLIP is that it can be used with protocols other than IP and it provides link and network control protocols. The PPP specification is contained in RFC1171.) -- Dave Mack csu@alembic.acs.com uunet!alembic!csu (703)883-3812 (work) (703)734-0877 (home)
-----------[000182][next][prev][last][first]---------------------------------------------------- Date: 13 Apr 91 19:41:06 GMT From: romkey@ASYLUM.SF.CA.US (John Romkey) To: comp.protocols.tcp-ip Subject: TCP/IP programming library for PC's
Reply-To: romkey@asylum.sf.ca.us Date: 13 Apr 91 10:04:33 PDT (Sat) From: romkey@asylum.sf.ca.us (John Romkey) FTP Software's dev kit costs ... Sorry, I didn't mean to CC: that to tcp-ip...the mailer got the better of me. - john
-----------[000183][next][prev][last][first]---------------------------------------------------- Date: 13 Apr 91 23:05:50 GMT From: fair@Apple.COM (Erik E. Fair) To: comp.protocols.tcp-ip Subject: Re: What Is Difference Between Internet And X.400 Style Names?
There is a good reason to have the transport address show through everywhere, in the same format, like the Internet domain names do now: It keeps the users from getting confused when they talk to each other, and exchange business cards. When I tell you that my address is "fair@apple.com", there is no question about that on the Internet, or any other place that (sensibly) accepts domain addresses. If I have to know what network you're on (or worse, what mailer you use!) before I can give you my address, then the design of the mail system is wrong. X.400 is the mail system of the future, and I hope it stays that way. Erik E. Fair apple!fair fair@apple.com
-----------[000184][next][prev][last][first]---------------------------------------------------- Date: 13 Apr 91 23:40:05 GMT From: sardella@strfleet.gsfc.nasa.gov (Tom Sardella) To: comp.protocols.tcp-ip,comp.sys.novell,comp.realtime Subject: Excelan EXOS TCP/IP Software Problems
I am working with a custom embedded front-end system that I developed in 1986 which provides a bridge between some special purpose NASA data communication circuits and a VAX computer. Ethernet TCP/IP is used as the interface between the front-end and the VAX. The TCP/IP implementation on the front-end consists of Excelan 201 intelligent Multibus controllers running the EXOS 8010 TCP/IP version 3.2 code. This code runs on the EXOS 201 board. We used the host development package, which provides Unix host driver source code, to develop a driver on the front-end host processor (Heurikon HK68ME 68000 board) running under the VRTX real-time kernel to simultaneously operate 2 controllers. TCP communications with the VAX have worked flawlessly with this configuration. However, we have adapted this front-end for use with a MASSCOMP 6600 and have had problems with the 8010 TCP/IP crashing when the MASSCOMP closes and then reopens the window. I was able to fix the problem by copying the version 3.3 TCP code from their PC-based product, an EXOS 205 board (it appears that exactly the same code runs on all their boards), to the Multibus EXOS 201 board. Further investigation found that buffer management problems with version 3.2 were causing an EXOS PANIC and that version 3.3 fixed those problems. With that as background, this is my real problem: I would like to avoid problems in the future caused by running old buggy versions of this TCP/IP software. I would like to get hold of the latest available version along with the source code and other documentation (Application Notes on the Bus and Message-Level Interface) that are needed for developing and maintaining the host device driver. I'd also like to have the proper license to use it. However, with Excelan having been acquired by Novell, I have had a difficult time finding anyone that supports this code in any manner. A couple of years ago we couldn't even get a straight answer from Excelan on whether we could purchase licenses to make additional copies of the software. From what I've seen of Novell's product line, this on-board TCP/IP code doesn't seem to be used at all anymore. Even if we can't find current support for this product, I'd like to get the latest released version along with the documentation I mentioned. Switching to a different product would be a very expensive proposition at this point and there aren't many vendors that support dual controllers. Does anyone have any suggestions? Please email as our news server seems to have been having problems recently. I'll post a summary if there is sufficient interest. Thanks in advance. Tom Sardella Network Control Systems Branch, Code 532 NASA/Goddard Space Flight Center Greenbelt, MD sardella@strfleet.gsfc.nasa.gov
-----------[000185][next][prev][last][first]---------------------------------------------------- Date: 14 Apr 91 00:33:33 GMT From: jrc@brainiac.mn.org (Jeffrey Comstock) To: comp.protocols.tcp-ip Subject: Re: KA9Q SMTP Config problem
In article <1991Apr10.152522.2472@cs.wayne.edu> BHOLMES@CMS.CC.WAYNE.EDU writes: >I'm trying to get SMTP in KA9Q to work, but without success. >I can FTP in using the id in /ftpusers, but SMTP sends back: > >452 Temp file write error > >After issuing a SMTP '.' to close the message. Can anyone offer advice? Have you created the following subdirs ? \spool \spool\mqueue \spool\rqueue They must be present for it to work. -- Jeffrey Comstock Work jrc@c2s.mn.org Home jrc@brainiac.mn.org Ampr nr0d@nr0d.ampr.org
-----------[000186][next][prev][last][first]---------------------------------------------------- Date: 14 Apr 91 02:52:53 GMT From: cryptkpr@cc.utah.edu (H. CARLTON DOE III) To: comp.protocols.tcp-ip Subject: Return mail routed to root mailbox, HELP!
I have just installed tcp/ip on my network of AT&T machines running SysV
3.2 and SysV 4.0 and have run into a couple of problems.
1. I can send mail _to_ users on the SV 4 machines but they
can't send mail out.
2. Users can send and receive mail between the SV 3.2 machines
provided they invoke the mailx command for each message they
want to send. If, in reading their mail, they try to respond
immediately to the message from within mail, their response
is routed to the root mailbox of the machine they're on. In
looking at the headers of the messages that are coming across
the net, it appears the mail is first being received by root
then routed to the addressed user.
Any help in fixing these problems would be appreciated.
the Crypt Keeper
aka Carlton Doe
at Spectrum Field Services
===========================================================================
| WARNING! This is only a test! Had
cryptkpr@cc.utah.edu | the above been an insightful or
cdoe@peruvian.utah.edu | original thought rather than a waste
or | of bandwidth, you would have been told
attmail!alexis!carlton | where to tune in your area for official
| news and information. I repeat, this is
| only a test!
-----------[000187][next][prev][last][first]---------------------------------------------------- Date: 14 Apr 91 03:08:09 GMT From: PLS@cup.portal.com (Paul L Schauble) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: 10baseT Installation costs
I think I missed the beginning of this discussion....
When you say 10BaseT is cheaper, what are you comparing it to?
++PLS
-----------[000188][next][prev][last][first]---------------------------------------------------- Date: 14 Apr 91 03:55:31 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: TCP benchmarking
In article <9104120230.aa07219@SPARK.BRL.MIL>, reschly@BRL.MIL ("Robert J. Reschly Jr.") writes:
>
> > First try the 4.3BSD `ping -l9999999 target` and look at the packet rate.
> >
> ...but before you do that, be sure your mbuf code is fixed. On BSD
> systems of early 4.3TAHOE vintage or earlier, you could get an mbuf
> panic from all those unprocessed ICMP Echo Replies.
I'll take your word for that.
To really test things, you don't want the replies cluttering up the net,
causing collisions. I forgot to mention that you want to add a suitable
entry to your ARP cache so you can blast something that won't blast back.
And the best 9.6 usec numbers need an otherwise quiet net.
Of course, these fun games would be considered denial-of-service attacks by
anyone trying to use the ethernet for real work.
Vernon Schryver, vjs@sgi.com
-----------[000189][next][prev][last][first]---------------------------------------------------- Date: 14 Apr 91 05:01:54 GMT From: brian@telebit.com (Brian Lloyd) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: What protocol is used for leased lines?
The problem with what to run on leased lines is an old one. Until PPP there simply was no standard. You ran what your router vendor gave you or you ran SLIP over an async link. Interoperability was limited to SLIP and because SLIP runs only on async links, you were limited to relatively slow speeds. Now you did not mention your hardware base so I can't comment too much. If you are trying to plug directly into an async serial port on a workstation, your speeds and options are limited. If you are establishing connections between routers that is a different story. You mention DSU's but you also mention RS-232. Usually when someone mentions a DSU he/she is running a 56Kbps or T1 synchronous link, the former being only marginally compatible with RS-232 (the official "top-speed" of RS-232 is 20Kbps but you can push it to 56bps) and the latter is totally incompatible with RS-232. All of that aside, I would consider adopting PPP as your point-to-point link protocol. It will run on either sync or async lines. PPP is supported by just about all of the router manufacturers for their synchronous serial links. It can also be used on asynchronous links too so it is a win all around. There are public domain versions of async PPP floating around so you can put a network together on a shoestring budget. Actually, you are going to be out of pocket quite a bit if you are talking about leased lines so you might as well do it right and get good routers to tie the whole thing together. Run sync PPP. -- Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@napa.telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333
-----------[000190][next][prev][last][first]---------------------------------------------------- Date: 14 Apr 91 05:53:43 GMT From: brian@telebit.com (Brian Lloyd) To: comp.protocols.tcp-ip Subject: Re: Help designing address allocation in a metronet
GAK! You certainly can eat up a lot of address space using SLIP links. The problem is inherent in the "an IP address per interface" and in the "everybody in a (sub)net must share the same (sub)net number" concepts. In spite of the fact that it violates tradition and the router requirements RFC, we chose not to assign a unique IP address to each interface in the Telebit NetBlazer dial-up router. The SLIP or PPP links do not need their own unique IP address and, in fact, all interfaces are allowed to share the same IP address. This GREATLY reduces the number of (sub)nets required to build a network. The trick that we use is to use an interface name in the routing table rather than the gateway address to determine which interface to use. We count on the fact that in a point-to-point SLIP or PPP connetion there can be only one destination for a packet that is shoved into one end of a link. Therefore we really do not care what the IP address is on either end of the link. We trust that the remote peer will behave in a router-like manner and forward the packet along the way toward its ultimate destination. Bottom line is that it works and doesn't eat up address space. -- Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@napa.telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333
-----------[000191][next][prev][last][first]---------------------------------------------------- Date: 14 Apr 91 05:59:16 GMT From: gah@hood.hood.caltech.edu (Glen Herrmannsfeldt) To: comp.protocols.tcp-ip Subject: Re: How to set up subnets where logical subnet != physical subnet
More than one subnet on a physical cable.... This is possible. I understand that cisco routers actually know how to do this. Otherwise, the two interface method. THe two interface method does not work for machines that assign the same ethernet (hardware) address to all ports on the machine. Suns do this, I don't know about others. The next possible problem is that some machines (suns, again) complain if they see routing packets for the wrong subnet. This can probably be fixed in syslog.conf, but is something to know about. THe messages appear on the console, ordinarily. Here, we have more than one subnet on one cable, in anticipation of splitting it when a new router arrives. All except one are not broadcasting routes, so that static routing must be used.u!
-----------[000192][next][prev][last][first]---------------------------------------------------- Date: Sun, 14 Apr 91 18:32:45 GMT From: ji@cs.columbia.edu (John Ioannidis) To: comp.protocols.tcp-ip,misc.legal Subject: Machine names and trademark law
I have a strange question: Suppose I name a machine "foo.cs.columbia.edu", where "foo" is a trademark or a registered trademark, e.g., the name of a video game, a brand of consumer electronics, the make of an exotic car, or the name of a computer manufacturer. Have I violated trademark law? /ji In-Real-Life: John "Heldenprogrammer" Ioannidis E-Mail-To: ji@cs.columbia.edu V-Mail-To: +1 212 854 8120 P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027
-----------[000193][next][prev][last][first]---------------------------------------------------- Date: 14 Apr 91 20:17:52 GMT From: ho@hoss.unl.edu (Tiny Bubbles...) To: comp.protocols.tcp-ip,misc.legal Subject: Re: Machine names and trademark law
ji@cs.columbia.edu (John Ioannidis) writes:
>Suppose I name a machine "foo.cs.columbia.edu", where "foo" is a
>trademark or a registered trademark, e.g., the name of a video game, a
>brand of consumer electronics, the make of an exotic car, or the name
>of a computer manufacturer. Have I violated trademark law?
I hope not. Remember, Zilog trademarked the letter "Z" and Microsoft
trademarked the letters "MS" when placed next to each other.
Thus naming anything "ZOOMS" would be a double trademark infringement.
I'm probably wasting my time posting this, as our news server doesn't seem
to be letting mail out of the University of Nebraska-Lincoln.
--
... Michael Ho, University of Nebraska
Internet: ho@hoss.unl.edu | Harry was too homely for Sally. (I have proof.)
Disclaimer: Views expressed within are purely personal and should not be
applied to any university agency.
-----------[000194][next][prev][last][first]---------------------------------------------------- Date: 14 Apr 91 21:16:31 GMT From: jkrey@ISI.EDU To: comp.protocols.tcp-ip Subject: re: Where does one get old RFCs?
Hank, Many of the early RFCs were never on-line files. No concerted effort was made to capture on-line versions of those that were. Hence, very few of the RFCs before about RFC 500 are available on line. Joyce and --jon.
-----------[000195][next][prev][last][first]---------------------------------------------------- Date: 15 Apr 91 02:39:47 GMT From: mcitron@phad.hsc.usc.edu (Mark Citron) To: comp.protocols.tcp-ip,comp.unix.xenix.sco Subject: "expect" for SCO unix
Does anyone have an executable copy of the expect program that runs under SCO Unix? It seems like a valuable utility but it is beyond me to compile it under SCO. Thanks for any help or suggestions, Mark Citron Childrens Hospital Los Angeles -- Mark Citron mark@neurosci.usc.edu
-----------[000196][next][prev][last][first]---------------------------------------------------- Date: 15 Apr 91 10:23:32 GMT From: barrett@Daisy.EE.UND.AC.ZA (Alan P. Barrett) To: comp.protocols.tcp-ip Subject: Re: How to set up subnets where logical subnet != physical subnet
In article <1991Apr10.063716.9725@cs.columbia.edu>,
ji@liberty.columbia.edu (John Ioannidis) writes:
> >router to present miltiple IP addresses without plugging in extra
> >network cards. This would be an alternate solution that would not
>
> CISCOs can do that. On BSD-derived Unixes, [you probably can't do it].
PC-Route can do that, if you get the declare.inc file right, which is
not very difficult. However, the documentation doesn't even mention
that this is possible, much less explain how to do it.
OK, now a question for the standards folk.
Section 2.3 of RFC791 (the IP standard) has this to say:
rfc791> Care must be taken in mapping internet addresses to local net
rfc791> addresses; a single physical host must be able to act as if it were
^^^^
rfc791> several distinct hosts to the extent of using several distinct
rfc791> internet addresses. Some hosts will also have several physical
rfc791> interfaces (multi-homing).
If the word "must" here really means MUST in the Host-Requirements
sense, then shouldn't all IP implementations allow a host to present
multiple IP addresses without having multiple interfaces?
--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
Internet: barrett@ee.und.ac.za UUCP: m2xenix!quagga!undeed!barrett
-----------[000197][next][prev][last][first]---------------------------------------------------- Date: 15 Apr 91 12:16:01 GMT From: randall@Virginia.EDU (Ran Atkinson) To: comp.protocols.tcp-ip Subject: Re: universality of Latin-1
Ran Atkinson originally wrote: % Fortunately there are a number of possible transport mechanisms out % there to choose from, some of which are already 8-bit transparent. In article <1991Apr12.124741.11555@dg-rtp.dg.com> eliot@dg-rtp.dg.com writes: >Ack! "Fortunately"? There is an ancient curse: "may you live in interesting >times". I think it's modern equivalent is "may you have many standards to >choose from". I said what I meant, namely that there are several different transport MECHANISMS (i.e. sendmail, MMDF, PMDF, etc.) not several different transport PROTOCOLS. The whole of the Internet uses the same mail protocols and that is a good thing, but the availability of different mechanisms to implement those protocols is also a good thing. Especially since some of the mechanisms are already 8-bit transparent, though not all are. I would like to see the 8-bit transparency with some kind of character set definition be added to the protocol more rapidly than Eliot seems to think likely.
-----------[000198][next][prev][last][first]---------------------------------------------------- Date: 15 Apr 91 15:40:36 GMT From: eric@picard.sbi.com (Eric Ho) To: comp.protocols.appletalk,comp.protocols.tcp-ip,comp.sys.mac.comm Subject: printing to Mac printers....
Hi, Can anyone give me some pointers on freeware on sending print jobs from Unix machines to printers hooked to Macs where the Macs are connected to the ethernet via Gatorbox'es ? I've done setup the other way round -- sending Mac print jobs to Unix printers (and at that time I also heard of solutions to send Unix print jobs to Mac printers but I forgot what those packages are and where to get them). Any poniters appreciated. -- ========================================== + Eric Ho Email: eric@sbi.com + Salomon Brothers, Inc. [SISS] Phone: (201) 896-4356 ==========================================
-----------[000199][next][prev][last][first]----------------------------------------------------
Date: 15 Apr 91 15:59:39 GMT
From: reschly@BRL.MIL ("Robert J. Reschly Jr.")
To: comp.protocols.tcp-ip
Subject: Re: RARE Networkshop at Blois May 13-16, 1991 (France)
Vint,
Thanks for posting the agenda. I must say, this RARE conference
looks well done.
Later,
Bob
-----------[000200][next][prev][last][first]---------------------------------------------------- Date: 15 Apr 91 16:00:55 GMT From: bmiller@CABELL.VCU.EDU (Bryan Miller) To: comp.protocols.tcp-ip Subject: Sniffer
Thanks to all who replied about my Sniffer question.... Does anyone have a contact name or name at Network General? I need to call about local dealers...are they on the Internet? Please respond by 3:00pm EST....under a budget crunch! Thanks, Bryan Miller bmiller@cabell.vcu.edu
-----------[000201][next][prev][last][first]---------------------------------------------------- Date: 15 Apr 91 16:55:08 GMT From: henry@zoo.toronto.edu (Henry Spencer) To: comp.unix.wizards,comp.protocols.tcp-ip Subject: Re: Thin wire or twisted pair?
In article <1991Apr12.023620.6227@Citicorp.COM> dsamperi@Citicorp.COM (Dominick Samperi) writes: >My organization is considering the use of twisted pair point-to-point >connections as an alternative to thin wire Ethernet... little >tolerance for network failures (a trading floor)... You might want to go have a look at comp.dcom.lans, where 10BaseT (standard twisted-pair Ethernet) has had considerable discussion of late. This isn't really a Unix or TCP/IP issue. (To sum up the c.d.l discussions excessively tersely... 10BaseT works well. Relative costs are somewhat debatable; there is no huge difference, but thinwire may still be somewhat cheaper. 10BaseT is parsecs ahead on reliability for complex networks with large user communities, because its star topology tends to localize failures to a single machine, whereas thinwire takes down a whole network segment when one ignorant clod unplugs or damages a connection.) >Is there a throughput/bandwidth hit in using twisted pair? ... There are slower twisted-pair technologies in use, but 10BaseT is Ethernet in all respects as far as performance goes. -- And the bean-counter replied, | Henry Spencer @ U of Toronto Zoology "beans are more important". | henry@zoo.toronto.edu utzoo!henry
-----------[000202][next][prev][last][first]---------------------------------------------------- Date: 15 Apr 91 17:01:56 GMT From: jessea@homecare.uucp (Jesse W. Asher) To: comp.protocols.tcp-ip,comp.sources.wanted Subject: Sources for PPP wanted.
I'm looking for 1) a public domain version of PPP what will run on a
Sparcstation, Sun Server, and 386 based unix, and 2) information about
commercial versions (where to get them) the same as #1. I can ftp the
public domain versions (in other words, ftp site suggestions welcome).
Thanx for any suggestions on this.
--
Jesse W. Asher NIC Handle: JA268 Phone: (901)386-5061
Health Sphere of America Inc.
5125 Elmore Rd., Suite 1, Memphis, TN 38134
UUCP: ...!banana!homecare!jessea
-----------[000203][next][prev][last][first]---------------------------------------------------- Date: 15 Apr 91 17:03:43 GMT From: ckollars@deitrick.East.Sun.COM (Chuck Kollars - Sun Technical Marketing - Boston) To: comp.protocols.tcp-ip Subject: Re: How to set up subnets where logical subnet != physical subnet
In article <gah.671608756@hood> gah@hood.hood.caltech.edu (Glen Herrmannsfeldt) writes: >More than one subnet on a physical cable.... > >This is possible. I understand that cisco routers actually know >how to do this. Otherwise, the two interface method. >THe two interface method does not work for machines that assign >the same ethernet (hardware) address to all ports on the machine. >Suns do this, I don't know about others. Some machines default to using the same Ethernet address on all interfaces, some default to using different Ethernet addresses on all interfaces, and some don't allow you to override the default with whatever you really want. Sun machines have flip-flopped their default behavior, since half the world is unhappy if the default is one way, and the other half the world is unhappy if the default is the other way. More important than the default is that Sun machines don't _force_ you do do it either way -- you're welcome to override the default to meet your needs. cheers! --- chuck kollars <ckollars@East.Sun.COM> Sun Technical Marketing, located in Sun's Boston Development Center
-----------[000204][next][prev][last][first]----------------------------------------------------
Date: 15 Apr 91 17:08:09 GMT
From: spgdrp@GANGES.UCOP.EDU ("Donald R. Proctor spgdrp@ganges.ucop.edu")
To: comp.protocols.tcp-ip
Subject: Re: tn3270 key mapping for DECstationsHas anyone devised a key mapping for tn3270 on DECstations that takes advantage of the function keys on the keyboard? I would love to received a copy of the map file if you have. Many thanks in advance. --Bob Haring-Smith rhh@brownvm.brown.edu 401-863-1982 Gee, I'd even settle for the cursor keys (and maybe more reasonable handling of highlighted screen characters). Would you send me a note if you get replies to this? Thanks, Don. Donald R. Proctor <spgdrp@ganges.ucop.edu> University of California <spgdrp@uccvma.bitnet>
-----------[000205][next][prev][last][first]---------------------------------------------------- Date: 15 Apr 91 17:11:15 GMT From: henry@zoo.toronto.edu (Henry Spencer) To: comp.protocols.tcp-ip,misc.legal Subject: Re: Machine names and trademark law
In article <1991Apr14.183245.345@cs.columbia.edu> ji@cs.columbia.edu (John Ioannidis) writes: >Suppose I name a machine "foo.cs.columbia.edu", where "foo" is a >trademark or a registered trademark, e.g., the name of a video game, a >brand of consumer electronics, the make of an exotic car, or the name >of a computer manufacturer. Have I violated trademark law? Caution: I am not a lawyer. Consult a pro before doing anything rash. :-) The idea behind trademark law is that a trademark denotes a particular vendor's product, so that it will not be confused with competing products. The theory is that you infringe on someone's trademark only when you use it in a way that could cause such confusion. The practice is that different companies have very different ideas about what constitutes potential for confusion, and being sued is painful and costly even if it fails. In practice, the odds are that nobody would care. The odds are good that if anyone did care, they'd send you a nasty letter saying "change those names or we'll sic our lawyers on you". This still wouldn't be fun, mind you. Me, I'd be wary of using names that have anything to do with electronics, but the exotic cars sound reasonably safe. -- And the bean-counter replied, | Henry Spencer @ U of Toronto Zoology "beans are more important". | henry@zoo.toronto.edu utzoo!henry
-----------[000206][next][prev][last][first]---------------------------------------------------- Date: 15 Apr 91 17:44:40 GMT From: osh@jhereg.osa.com (John M. O'Shaughnessy) To: comp.unix.wizards,comp.protocols.tcp-ip Subject: Re: Thin wire or twisted pair?
Twisted Pair networks are likely to cost more in terms of hardware than thin Ethernet networks because they require a concentrator, and you can't daisy chain stations. Twisted Pair 10Base T may save you money in installation costs if the wiring in your facility is up to spec, and if you have enough spare pairs to use for Ethernet (2-pairs). We have found twisted pair networks to be much more reliable due to the terminal-hub nature of the network connection. One station's problems won't affect anyone else. There are also a number of management tools available frm the concentrator manufacturers that help you to manage the network, keeping track of usage, etc. In an area not staffed with technical people, users appreciate the simple telephone cord-like connection as opposed to a cable TV like coaxial connection. I still prefer thin Ethernet for lab areas, or other areas with many machines in close proximity, but for the office environment, we almost always choose twisted pair 10BaseT Ethernet. John -- John M. O'Shaughnessy osh@osa.com Open Systems Architects, Inc. Minneapolis, MN
-----------[000207][next][prev][last][first]---------------------------------------------------- Date: 15 Apr 91 18:19:31 GMT From: lyndon@cs.athabascau.ca (Lyndon Nerenberg) To: comp.protocols.tcp-ip Subject: Re: SLIP problems under SunOS 4.1.1
karl.kleinpaste@osc.edu writes:
>Note that there exist both -01 and -02 versions of this fix; install
>-02 to be maximally up-to-date. The README for -02 notes that the -01
>version didn't deal in IP options properly.
Note that there now exists a -03 version of said patch :-)
>100149-02.tar.Z can be ftp'd from saqqara.cis.ohio-state.edu:pub/slipware.
100149-03.tar.Z can be ftp'd from ftphost.cs.athabascau.ca:sun-patches/
--
Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University
atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca
Packet: ve6bbm@ve6bbm.ab.can.noam
The only thing open about OSF is their mouth. --Chuck Musciano
-----------[000208][next][prev][last][first]---------------------------------------------------- Date: 15 Apr 91 20:56:51 GMT From: andrew@jhereg.osa.com (Andrew C. Esh) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: 10baseT Installation costs
In article <41255@cup.portal.com> PLS@cup.portal.com (Paul L Schauble) writes: >I think I missed the beginning of this discussion.... > >When you say 10BaseT is cheaper, what are you comparing it to? > > ++PLS To this point, the main contender has been ThinNet (RG58 Coax), since it does not require a Hub. I think 10baseT is better because it is physically more reliable, and easier to connectorize and maintain. The wire is cheaper, too. Hey folks, I've noticed hubs are getting down in the $50/port range. Where does that put us with this discussion? Are you ThinNet types gonna go away and cry in your cornflakes yet? :-) (Just kidding, I like ThinNet too.) -- Andrew C. Esh andrew@osa.com Open Systems Architects, Inc. Mpls, MN 55416-1528 Punch down, turn around, do a little crimpin' (612) 525-0000 Punch down, turn around, plug it in and go ...
-----------[000209][next][prev][last][first]---------------------------------------------------- Date: 15 Apr 91 21:27:33 GMT From: ash@omega.UUCP (Andrew Hardie) To: comp.protocols.tcp-ip Subject: Novell 802.3
There was some traffic on the net a month or so ago about Novell 802.3 packets (datagrams, I think, to be accurate), with the comment that these, to *really* be OSI conformant, should have inside them an 802.3 header and a SNAP field. The penny only dropped on me about this one after reading something this week. Does this mean that Novell's "OSI Support" is just protocol tunnelling of IPX inside 802.3 packets and that all that has actually been done is to change from an Ethernet packet with a type field of 8137, useful for separating it from TCP/IP, and replaced it with an 802.3 packet by putting in the ISO "length" field the protocol doesn't actually need in order to operate? This all sounds a bit marginal to me, or have I got the wrong end of the stick here? Andrew -- +----------------------------------------------------------------------------+ | Andrew Hardie ash@omega.uucp | | London, England ukc!cctal!omega!ash | +----------------------------------------------------------------------------+
-----------[000210][next][prev][last][first]---------------------------------------------------- Date: 15 Apr 91 22:11:32 GMT From: rrj@hpctdjl.HP.COM (Roger Jones) To: comp.protocols.tcp-ip Subject: Re: FTP site for RFCs?
> Is there an FTP site with RFCs? I'm kinda interested in seeing the
> protocol specs for the stuff I'm using, but I'm just a student (not
> even a CS student at that :-), so I don't have any clue about who
> handles this stuff.
Try to ftp to nic.ddn.mil, which is 192.67.67.20. This is the main
source for rfc's. Use the user anonymous and your ident as a password.
cd to RFC: <--- the colon is important. The file rfc-index.txt
is the key to all of the files. If you "get" the files using lower
case representation it will create a file locally with lower case, my
personal preference.
Here is part of the 00readme file from there.
Welcome to the DDN Network Information Center! The following public
directories are located on the NIC.DDN.MIL computer system:
DDN-NEWS: DDN Management Bulletins and DDN Newsletters
IEN: Internet Experimental Notes
INTERNET-DRAFTS: Internet Engineering Task Force (IETF) Idea Papers
NETINFO: Contains Admin. notes, Documents, Host/TAC info,
Domain/Internet info, PC/Kermit info, NSC/HA lists,
Network program info, DDN Vendors Guide and DDN New Users Guide
NETPROG: Network programs for WHOIS, HOSTNAME, getting the NIC
host table and host table compiler
PROTOCOLS: Network Protocols Information
RFC: Requests For Comments
To get a listing of filenames within one of these directories while using
FTP, use the "dir" (directory) command, as in "dir RFC:".
Each directory contains an index or indexes to the files within that
directory:
DDN-NEWS:DDN-NEWS-INDEX.TXT
-----------[000211][next][prev][last][first]---------------------------------------------------- Date: 16 Apr 91 00:31:56 GMT From: robert@swanee.ee.uwa.oz.au (Roberto Togneri) To: comp.protocols.tcp-ip Subject: connection from remote host
Hi, Is there a way under Unix (esp. SunOS 4.1.1.) to check from which host a user is logging in from and limit logins to a particular set of hosts or domains. This would be handy for setting up secure nopassword logins. With irises a REMOTEHOST variable is set which can be user. No such variable is defined with our Suns. If anybody help I'd appreciate it. -- Dr. Roberto Togneri Phone: +61-9-380-2535 Dept. of Electrical & Electronic Engineering The University of Western Australia Fax: +61-9-380-1065 NEDLANDS WA 6009 Australia Email: robert@swanee.ee.uwa.oz.au
-----------[000212][next][prev][last][first]---------------------------------------------------- Date: 16 Apr 91 00:34:15 GMT From: wb8foz@mthvax.cs.miami.edu (David Lesher) To: comp.protocols.tcp-ip,misc.legal Subject: Re: Machine names and trademark law
>>Suppose I name a machine "foo.cs.columbia.edu", where "foo" is a >>trademark or a registered trademark, e.g., the name of a video game, a >The idea behind trademark law is that a trademark denotes a particular >vendor's product, so that it will not be confused with competing products. >The theory is that you infringe on someone's trademark only when you use >it in a way that could cause such confusion. On the other hand, guess (;-}) which aerospace firm sued the two-bit manufacturer of the: Stealth Condom - They'll never see you coming! No cheating, now, class........... -- A host is a host from coast to coast.....wb8foz@mthvax.cs.miami.edu & no one will talk to a host that's close............(305) 255-RTFM Unless the host (that isn't close)......................pob 570-335 is busy, hung or dead....................................33257-0335
-----------[000213][next][prev][last][first]---------------------------------------------------- Date: 16 Apr 91 03:48:19 GMT From: Will@cup.portal.com (Will E Estes) To: comp.protocols.tcp-ip Subject: Request For Info On Dynamically Acquiring IP Addresses At Boot
Can someone give me a reference to any research or commercial products
that attempt to solve the problems of 1) allowing a PC or workstation
to dynamically acquire an IP address at boot time, and 2) making it
easier to install IP on a PC or workstation (i.e., an attempt to make
things in general more dynamic so that each client doesn't have so
much static information hard-coded into it at install time).
Thanks,
Will Estes Internet: Will@cup.portal.com
UUCP: apple!cup.portal.com!Will
-----------[000214][next][prev][last][first]---------------------------------------------------- Date: 16 Apr 91 05:19:28 GMT From: dave@fps.com (Dave Smith) To: comp.protocols.tcp-ip Subject: Re: SLIP problems under SunOS 4.1.1
In article <1991Apr12.140605.29819@oar.net> karl.kleinpaste@osc.edu writes: >brett@solar.card.inpu.oz.au writes: >I've written a note about the problem to sunbugs@sun.com, but since it >involves use of a non-standard driver, I doubt it'll get much >attention. Before installing 100149-02, I consistently got "panic: >mclput" whenever substantial amounts of data would begin to transfer. I have been using SLIP 4.0 on SLC's under 4.1.1 for about three weeks now and have run a goodly number of megabytes through them. I saw this mclput panic fairly frequently for a while and then saw a real high correlation with the answering side of the connection (I'm using dialup over T2500's) panicing when the connection was dropped. When I switched to V.42 mode the panic's went away. My feeling is that the utter garbage you get when the other side hangs up is confusing the TCP routines incredibly since they aren't used to being fed complete crap. -- David L. Smith FPS Computing, San Diego ucsd!celit!dave or dave@fps.com "It was time to stop playing games. It was time to put on funny hats and eat ice cream. Froggie played his oboe" - Richard Scarry
-----------[000215][next][prev][last][first]---------------------------------------------------- Date: 16 Apr 91 07:20:26 GMT From: rup@guug.guug.de (Rupert Grafendorfer) To: comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.iso Subject: MOP Protocol implementations
Does anybody know about implementations of MOP for non-DEC PC-controllers for remote booting. I once heard about a implementation at MIT, but I lost the mail-adress. Any help (even just hints or ideas) are welcome. Please mail me. Thanx. -rup
-----------[000216][next][prev][last][first]---------------------------------------------------- Date: 16 Apr 91 10:50:51 GMT From: rainer@hwsw.gedas.de (Rainer Raupach) To: comp.protocols.tcp-ip Subject: PD-SNMP-software
Hi net.lan.ders, we have a company-X.25 network currently working with DECNET and SNA/3270 X.29 ... and installed some ciscos for testing. We are now purchasing some more ciscos with X.25, Ethernet and FDDI for use in the inhouse as well as the wide area net. For general network management we need some SNMP-software. Is there some PD-software somewhere? Hardware is a SUN Spark, X11 is installed. Rgds Rainer -- --- Rainer Raupach Internet: rainer@hwsw.gedas.de Network Coordinator X.400: S=RAUPACH C=DE A=DBP P=VW-GEDAS VW-GEDAS Berlin, GER Phone: +49 30 39007-629 / FAX : ext -999
-----------[000217][next][prev][last][first]---------------------------------------------------- Date: 16 Apr 91 12:46:29 GMT From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) To: comp.protocols.tcp-ip Subject: Re: Goofy Router?
Several points to consider. Afsc-bmo.af.mil is at 131.62.71.1 rather than 132.62.71.1. From my vantage point on DDN, I get a network unreachable. Chances are an AF Concentrator has recently been installed or has failed. The !P response from MOFFETT-FLD-MB.DDN.MIL is a port unreachable. Look at the man page in [NETDIST.DOCS] for the distinction between port (!P), host (!H), and network (!N) unreachable states. MOFFETT-FLD-MB.DDN.MIL appears to be down or overloaded at the moment as the traceroute to your site is getting routed through MCLEAN-MB.DDN.MIL, SURAnet, NSFnet, and CERFnet even though we're only about 45 miles apart. Merton Campbell Crockett Contel Federal Systems, GSysG/WLO
-----------[000218][next][prev][last][first]---------------------------------------------------- Date: 16 Apr 91 13:41:26 GMT From: malis@BBN.COM (Andy Malis) To: comp.protocols.tcp-ip Subject: Re: Goofy Router?
Bryan, > we're oz.bmd.trw.com (129.193.100.6) and we're trying to get to > afsc-bmo.af.mil (132.62.71.1) afsc-bmo.af.mil (actually 131.62.7.1) is an Air Force host at Norton Air Force base, behind an Air Force Concentrator (Cisgo gateway) connected to the MILNET. The Concentrator is norton-piv-1.af.mil, with addresses 26.8.0.39 and 131.62.0.1. > When I did a traceroute to afsc-bmo.af.mil on 4/10/91 I got this - > 1 outdsg.nba.TRW.COM > . > . > . > 13 192.52.195.1 > 14 * * * > 15 * * * > . > . > . > 30 * * * As of 09:30 EDT on 4/16, it appears that norton-piv-1.af.mil is dead. I'm able to ping 26.0.0.39 (another host on the same MILNET PSN), but 26.8.0.39 isn't answering. When trying a traceroute from BBN to afsc-bmo.af.mil, the NSFNET reports that the destination network is unreachable: 7 princeton-nss.near.net (192.80.80.1) 40 ms !N 40 ms !N 20 ms !N I also tried a traceroute via your host, by using "traceroute -g oz.bmd.trw.com afsc-bmo.af.mil", and found a router at TRW was reporting host unreachable: 20 129.193.76.252 (129.193.76.252) 340 ms !H * 400 ms !H > What is this router at 192.52.195.1 doing? When I > traceroute just to 192.52.195.1 I got this - > 14 192.52.195.1 (192.52.195.1) 1060 ms !P 1020 ms !P 1050 ms !P 192.52.195.1 is MOFFETT-FLD-MB.DDN.MIL, a Mailbridge between the NSFNET (and several other nets) and the MILNET. It is responding to traceroute by reporting that it is receiving datagrams using an unsupported protocol (the !P flag). You should read the traceroute man page for more information on how it works, and other indications you can receive from traceroute. In general, if you are having trouble reaching a host on the MILNET, or on a network behind a MILNET-attached router, such as an Air Force Concentrator, you should call the MILNET Monitoring Center at (800) 451-7413, or (202) 692-5726. They are also reachable by email at DCA-MMC@DCA-EMS.DCA.MIL. Regards, Andy Malis BBN Communications
-----------[000219][next][prev][last][first]---------------------------------------------------- Date: 16 Apr 91 16:47:01 GMT From: bill@platypus.uofs.edu (Bill Gunshannon) To: comp.protocols.tcp-ip Subject: Re: finger weather is discontinued
I'm not sure how this commercial outfit gets the data, but it apparently
originates at the various NWS offices. There was a real nice X-windows
Weather Map program that just suffered the same fate.
Now I have a suggestion for a possible solution.
Maybe what is needed is for people to find out how this information is
collected from the NWS and then if possible, try and find INTERNET sites
near each of the NWS stations (I am near AVP) and get them a connection
so that we can gather the info ourselves. Then all we need is a central
site to hold and distribute the information. After all, isn't it our tax
money that is generating this data in the first place??
bill
--
Bill Gunshannon | If this statement wasn't here,
bill@platypus.uofs.edu | This space would be left intentionally blank
bill@tuatara.uofs.edu | #include <std.disclaimer.h>
-----------[000220][next][prev][last][first]---------------------------------------------------- Date: 16 Apr 91 18:09:01 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: Packet drivers for Proteon Pronet-10
Proteon is working on NDIS drivers for their cards....
I am guessing here, but I suspect that these NDIS drivers are actually for
their 802.5-compatible interfaces. NDIS does not attempt to hide the
characteristics of the LAN media from the protocol stack, and the spec
recommends that driver developers who have something which isn't 802.3 or
802.5 (and ProNET-10 certainly isn't) make it look like one or the other
(presumably so that LAN Manager only has to understand those two media).
You could do a ProNET-10 NDIS driver that understood the differences between
IP-over-Ether and IP-over-Pro10 and translated, but I don't think they have...
Also I believe Proteon supports the ASI interface.
Only on 802.5-compatible interfaces.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000221][next][prev][last][first]---------------------------------------------------- Date: 16 Apr 91 19:08:32 GMT From: kurt@photon.tamu.EDU (Kurt Freiberger) To: comp.protocols.tcp-ip Subject: Re: finger weather is discontinued
In article <441@platypus.uofs.edu>, bill@platypus.uofs.edu (Bill Gunshannon) writes: |> |> I'm not sure how this commercial outfit gets the data, but it apparently |> originates at the various NWS offices. There was a real nice X-windows |> Weather Map program that just suffered the same fate. |> Now I have a suggestion for a possible solution. |> Maybe what is needed is for people to find out how this information is |> collected from the NWS and then if possible, try and find INTERNET sites |> near each of the NWS stations (I am near AVP) and get them a connection |> so that we can gather the info ourselves. Then all we need is a central |> site to hold and distribute the information. After all, isn't it our tax |> money that is generating this data in the first place?? Tsk, tsk, tsk. Bill, I'm surprised at your naivete!! They are charging you for the SERVICE of providing this valuable information! After all, it probably takes the equivalent of a bank of Crays to process this so it can be sent to all the radio and TV stations so that they can come up with their authoritative weather predicions. We mere mortals cannot be trusted with this raw information. It might upset the balance of civilization as we know it! As Louie XIV said, "It's good to be the king." #include <boatload_of_smileys> Cheers, Kurt P.S. Willis still doesn't have his call; he's climbing the wall!!!! 8-} -- Kurt Freiberger, wb5bbw kurt@cs.tamu.edu 409/847-8706 Dept. of Computer Science, Texas A&M University
-----------[000222][next][prev][last][first]---------------------------------------------------- Date: 16 Apr 91 19:30:28 GMT From: j_rodin@hpfcso.FC.HP.COM (Jon Rodin) To: comp.protocols.tcp-ip Subject: Re: Packet drivers for Proteon Pronet-10
>Proteon is working on NDIS drivers for their cards, which should be available >real-soon-now. Whenever those driver become available, one could use the >dis_pkt driver to run packet driver based protocols over Proteon cards. > >Also I believe Proteon supports the ASI interface. I don't know if a packet >driver-to-ASI translater exists, but ASI does support multiple concurrent >protocol stacks. Well, I was only partially right here. Proteon is only working on NDIS drivers for the ProNET-4 cards. And the ASI is probably only for ProNET-4, as well. Jon j_rodin@cnd.hp.com
-----------[000223][next][prev][last][first]---------------------------------------------------- Date: 16 Apr 91 19:36:49 GMT From: majumdar@bgsuvax.UUCP (anindo Majumdar) To: comp.protocols.tcp-ip Subject: servers using SUNS rpc protocol
Are the servers created using SUN's rpcgen mechanism capable of supporting
multiple clients? If so how many can they support at one time and do they
have to fork another process for each new client?Is there any way wherby
these servers can have multiple threads of control thus enabling them to supportmultiple clients without the overhead of context switches,new child processes ?
Any pointers will be greatly appreciated.
Thanks
Anindo Majumdar
Internet address : majumdar@andy.bgsu.edu
-----------[000224][next][prev][last][first]---------------------------------------------------- Date: 16 Apr 91 20:48:28 GMT From: mahesh@pyrhard2.pyramid.com (Mahesh Jethanandani) To: comp.protocols.tcp-ip Subject: Generation of CRC as part of Frame Check Sequence Field.
We are bringing up a Ethernet board for our machines, using the LANCE chip. I have to be able to test the CRC logic on the board, by comparing the CRC that I generate in software with what the hardware generates and appends to each packet. I have the 802.3 specs and I can see the polynomial equation used to generate the CRC. What I need is a C program, that I can use to generate CRC for a 32 byte data packet. Has anyone out there written a program to do this. Thanks in advance. mahesh
-----------[000225][next][prev][last][first]---------------------------------------------------- Date: 16 Apr 91 21:34:54 GMT From: erick@sunee.waterloo.edu (Erick Engelke) To: comp.protocols.tcp-ip Subject: Re: Request For Info On Dynamically Acquiring IP Addresses At Boot
In article <41315@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: >Can someone give me a reference to any research or commercial products >that attempt to solve the problems of 1) allowing a PC or workstation >to dynamically acquire an IP address at boot time, and 2) making it >easier to install IP on a PC or workstation (i.e., an attempt to make >things in general more dynamic so that each client doesn't have so >much static information hard-coded into it at install time). > I do this for my 500+ PCs because I could not be botherred doing an installa- tion for each. You need some method of getting ip numbers, I have something running similar to BOOTP which gets run in the batch file immediately after the packet drivers is loaded. My BOOTP-similar program can write the ip address to a file or to an environment variable. With NCSA, Clarkson CUTCP, and Waterloo TCP, you simply insert the line with the correct ip address into the ASCII configuration file using some automatic process such as the one I have described or you select BOOTP for the TCP stacks which support it. Beame&Whiteside's system includes an automated IP generation scheme which, if memory serves me correctly, uses the lowest n bits of the Ethernet address where n is (32 - the number of bits in the network mask). B&W also supports the normal methods listed below. For PCIP based products such as FTP, Wollongong, Beame&Whiteside, etc., you can: 1. Use BOOTP (I think they all support it) 2. Use the configure program with a batch file 3. figure out the data structure and write to it yourself Since you ask about research, the following is a description of what is being done, but not commercially available. The Waterloo TCP system when running on Watstar (a proprietary DOS network) need not be configured with an IP address. It uses one if so supplied, but otherwise requests the address from the the Watstar network. The Watstar system responds with the computers IP address, or generates a new one if the computer is new. Addresses are managed by the subnet's gateway, meaning the gateway never needs to arp a station because it is the authority. Erick -- ---------------------------------------------------------------------------- Erick Engelke Watstar Computer Network Watstar Network Guy University of Waterloo Erick@Development.Watstar.UWaterloo.ca (519) 885-1211 Ext. 2965
-----------[000226][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 91 04:21:34 GMT From: doug@psy.uwa.oz.au (Doug Robb) To: comp.unix.wizards,comp.protocols.tcp-ip Subject: Re: Thin wire or twisted pair?
dsamperi@Citicorp.COM (Dominick Samperi) writes: >My organization is considering the use of twisted pair point-to-point >connections as an alternative to thin wire Ethernet. The motivation is >to reduce our expenses. The environment is one where there is little >tolerance for network failures (a trading floor). I'm familiar with >thin wire Ethernet, but know little about twisted pair technology. >Could somebody comment on their experiences with twisted pair >connections. Are they cheaper than thin wire? More/less reliable? >Is there a throughput/bandwidth hit in using twisted pair? How >large? Is twisted pair easier/harder to maintain? I have recently been to a few seminars where the suggestion has been made that the way to go is to blanket wire with unshielded twisted pair and have a concentrator at some point. With the appropriate cards in the concentrator you can run ethernet, apple talk, token ring etc without having to re-wire the building. Since the seminar's were put on by companies in the market for the above hardware then naturally I'm a bit suspicous as to whether this is any cheaper than using thin wire ethernet in combination with twisted pair as I do here. For a start the concentrator and cards are big dollars.... On the other hand running twisted pair back to a 10baseT hub may be quite cost effective if you are not sure about location of (or want the flexability of moving) serial printers/faxes/terminal etc around the building. The rational would be that you have to run the twisted pair anyway for the above so why not use it for your ethernet devices as well. In the Psychology dep we run twisted pair back to terminal servers, have thick and thin wire coax connecting out mini's, sparcstations and pc's. I think this is the cheapest way to go? Any comments? You could consider running thin wire ethernet and twisted pair? Since thin wire is about $A1.50 a metre you can run one or two segments (up to 180m) on each floor and dont bother with the T connectors etc until you need them. Then for example you want to connect a sparc station you open up the cable tray, fit a faceplate and connector and simply plug in. Since you can hang 29 devices off each segment it seems to me that this is easier than having 29 SEPARATE runs of wire going back to the 10baseT hub rather than the one in the case of the thin wire. Also the mac length of the 10baseT run is 100m , 180 for thin wire and about 500m i think for thick wire. Just to give you an example. I heard of a firm that got 3 floors of a new building in Perth wired up recently. Two thin wire segments on each floor and thick wire segment between floors. No connectors terminators, delni, desta etc because as yet the don't have a computer system. The cost for this $A7,000. They also had 8 pair, PDS (unshielded twisted pair) to 100 outlets with rj45 connectors back to a distrib board put in at the same time, cost $A48,000. To actually get a computer network will need a 10baseT hub etc as you know. Since they don't have a network yet I don't know that the final cost of each scenario would be. doug@psy.uwa.oz.au
-----------[000227][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 91 12:20:10 GMT From: gme@DOLPHIN.NO (Melbye/Nd) To: comp.protocols.tcp-ip Subject: LAN Manager
We would like to use Lan Manager on a TCP/IP network that includes IProuters. Due to the fact that Lan Manager is using netbios, this configuration seems to be impossible. There have been some rumours about some "netbios routers" applications on either DOS/OS2 or Unix that can solve this problem. Does anyone know about this ? Brit Jensen, Norsk Data
-----------[000228][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 91 12:54:31 GMT From: backman@FTP.COM (Larry Backman) To: comp.protocols.tcp-ip Subject: Re: LAN Manager
>> >> >> We would like to use Lan Manager on a TCP/IP network that >> includes IProuters. >> Due to the fact that Lan Manager is using netbios, this >> configuration seems to be impossible. >> >> There have been some rumours about some "netbios routers" >> applications on either DOS/OS2 or Unix that can solve >> this problem. >> >> Does anyone know about this ? >> >> Brit Jensen, Norsk Data >> >> Our OS/2 TCP Netbios has a hack built into it that if a certain switch (-nfilename I think) is set, it searchs that file for a name/internet address combination whenever NETBIOS name queries fail. Thus if your file had: joe silly.foo.com tom 128.127.44.33 and you tried a net use q: \\joe\public when the name query for joe failed on your local net; the netbios would then go off to silly.foo.com via DNS lookups & look there. Does this help you? Larry Backman backman@ftp.com
-----------[000229][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 91 14:06:49 GMT From: scott@hsvaic.boeing.com (Scott Hinckley) To: comp.protocols.tcp-ip Subject: Re: finger weather is discontinued
'finger weather' still works for me,... I just stick my finger out in the weather. If it gets wet it is raining, if it gets bright it is sunny, if it turns white it is snowing, if it gets frost bite it's cold... :-) -- <<<<<<<<<<<Scott Hinckley<<<<<<<<<<<<>>>>>>>>>>VW&Apple][Forever!!!>>>>>>>>>> Internet:scott@hsvaic.boeing.com|UUCP:...!uunet!uw-beaver!bcsaic!hsvaic!scott DISCLAIMER: All contained herein are my opinions, they do not|+1 205 461 2073 represent the opinions or feelings of Boeing or its management| BTN:461-2073
-----------[000230][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 91 14:40:54 GMT From: lhl@CS.WISC.EDU (L.H. Landweber) To: comp.protocols.tcp-ip Subject: (none)
Below please find the electronic version of the second announcement.
It includes the preliminary program, conference information and a
registration form.
This announcement is also on a server as a file for anyone to retrieve
by sending email to listserv@vm.uni-c.dk with the command:
GET INET91 PROGRAM
The social program is in a another file called INET91 SIGHTSEE, which
can be retrieved in the same way.
======================================================================
-------------------------------------------------------------------
DON'T MISS
THE FIRST TRULY GLOBAL CONFERENCE ON ACADEMIC NETWORKING
-------------------------------------------------------------------
II
''''
II NNN NN EEEEEEEEEE TTTTTTTTTT '''' 99999999 111
II NNNN NN EE TT '' 99 99 1111
II NN NN NN EE TT '' 99 99 11 11
II NN NN NN EEEEEEE TT 99999999 11
II NN NN NN EE TT 99 11
II NN NNNN EE TT 99 11
II NN NNN EEEEEEEEEE TT 99 11
International Networking Conference
Copenhagen - June 18-20, 1991
The first international conference focusing on worldwide issues of
research and academic networking - INET'91 - is scheduled for June
18-20, 1991 in Copenhagen, Denmark. University, industry and
government representatives from around the world are invited to meet
and discuss important issues related to planning, implementing,
managing and funding national, regional and international networks.
INET'91 sessions cover the main application areas of physics and
chemistry, space science, education, libraries and life sciences.
Technology sessions include topics such as the Internet,
collaboration techniques, new technology and perspectives of the
future. A track on policy includes sessions in relation to commercial
services, international links, security and open communication.
Finally there will be sessions for discussion of regional issues,
among these a session on Eastern Europe.
Before the conference, on June 17th, two tutorial sessions are
arranged on the topics of building a network and on IP networking.
Furthermore, a workshop for delegates from developing countries will
be held in connection to INET'91. The topic is "How to plan for and
implement research and academic networks". This workshop is held on
June 15-16 (the weekend before INET'91) with a closing session
immediately after INET'91 on June 20th.
Corporate sponsors (preliminary list)
-------------------------------------
IBM, DEC, Novell and Advanced Network & Services Inc.
Sponsoring Organizations
------------------------
Coalition for Networked Information, CREN, EDUCOM, FARNet, IAB and
Net North in North America.
WIDE, TISN and JAIN in Japan.
EARN, NORDUNET, EurOpen (EUnet) and RARE in Europe.
Conference co-chairs
--------------------
Frode Greisen Europe
Jun Murai Pacific Rim
Larry Landweber North America
Program Committee co-chairs
---------------------------
David Farber USA
Juha Heinanen Finland
Yutaka Matsushita Japan
----------------------------------------------------------------------
CONFERENCE INFORMATION
-----------------------------------------------------------------------
INET'91 takes place in Copenhagen, Denmark on June 17-20, 1991.
Hotels are available covering a wide range of cost categories. The
conference will be held at the SAS Scandinavia Hotel, located near
the center of town, but no more than 15 minutes from the airport. The
hotel is the largest in Copenhagen and offers luxurious guest rooms
and suites, an indoor swimming pool, a fitness center and three
excellent restaurants.
Registration
------------
One registration procedure is to use the electronic registration form
appended to this announcement. You can fill out the form and return it
to <inet91@vm.uni-c.dk> and at the same time transfer the money
by cheque or bank order to DIS Congress Service Copenhagen A/S. The
electronic registration becomes valid when the payment has been
received. You will of course be notified.
Alternatively you can register by ordinary mail. You can print the
registration form below or request a copy of the program and
registration form from either <inet91@vm.uni-c.dk>,
<inet91@educom.edu> or <inet91@wide.ad.jp>. Please send the
registration form together with the registration fee and other payments
as a a bank cheque, a bank transfer or a credit card order in Dansish
currency as soon as possible to the INET'91 conference registration:
DIS Congress Service Copenhagen A/S, see address below.
April 15th is the deadline for early registration at the reduced fee.
All registrations postmarked by April 15th, at the latest, will be
accepted (airmail from outside Europe). Registration at the time of
the conference cannot be guaranteed. If you have any questions
regarding the registration, please phone DIS Congress Service
Copenhagen A/S.
Payment must be remitted as follows:
------------------------------------
* Either by bankers' draft or cheque drawn on a Danish bank and
made payable to "INET'91", c/o DIS Congress Service Copenhagen A/S.
* Or by bank transfer to: Account No. 3112-07395-7 (INET)
Den Danske Bank
Nytorv 7
DK-1450 Copenhagen K
Denmark
* Or by credit card order which requires your signature on the
printed registration form to be sent by postal mail.
All payments must be made in Danish Kroner (DKK).
Please remember to state INET'91 and your name on all money transfers
to the conference registration bureau.
All inquiries concerning registration and hotel accommodation must be
directed to DIS Congress Service Copenhagen A/S.
Registration fees
-----------------
The registration fees are (1 US dollar is approximately 6 DKK
(March 1991):
Delegate registered until April 15, 1991 DKK 2,300
registered after April 15, 1991 DKK 2,700
Tutorial on June 17 DKK 1,300
Accompanying Person DKK 0
The following items are included in the conference registration
fee: The fees cover all conference sessions, one copy of the book of
abstracts, the conference banquet with TIVOLI entrance, luncheons and
coffee breaks for all three conference days June 18 -- 20, 1991.
The following items are included in the tutorials registration fee: All
sessions, printed material, luncheons and coffee breaks for June 17,
1991.
On site registration for INET'91 will begin Monday, June 17 from 7:00
p.m. to 9:00 p.m. and continues Tuesday, June 18 at 7:30 a.m.. There
will be a welcoming reception Tuesday evening from 6:30 p.m. to 8:00
p.m. The Conference will end Thursday, June 20, at noon.
Cancellation Policy
-------------------
Preregistered participants who are unable to attend the Conference
will have their paid fees refunded less DKK 300 provided that a
written notice of cancellation (by letter, telefax or telex) is
received by DIS Congress Service Copenhagen A/S before June 10,
1991. If cancellation is made after June 10, 1991 no refund of fee
can be expected.
Hotel Reservations
------------------
The conference bureau, DIS Congress Service Copenhagen A/S, offers
participants hotel rooms at a special conference price. Rooms will be
booked in the price category indicated on the registration form. If
you register after April 15, please note that some price categories
may be fully booked.
Hotel rooms will be booked only if a deposit has been received by the
Conference Bureau. The deposit will be deducted the hotel bill when
you check out. All conference hotels are situated in the centre of
Copenhagen. The conference is held at the 'A' hotel.
Deposit for A, B and C hotel: DKK 1,100
for D hotel: DKK 450
In case of cancellation please note that hotel deposits will be
refunded until May 15, less an administration fee of DKK 300. After
May 15, refunds will only be made if the cancelled room can be relet
to a third party.
Ground Transportation
---------------------
Just outside the Danish customs at the airport, you can board the SAS
bus directly to the Conference hotel. The first stop is the SAS
Scandinavia (Please inform the driver). You can also take a taxi for
approximately 60 DKK.
Exchange Rate and Banks
-----------------------
The present exchange rate (March 1991) is approx. 6 DKK per US
dollar. In other words, a Danish krone is worth 16 US cents.
The banks are open Monday through Friday from 9:30 a.m. to 4:00 p.m.
On Thursday, hours are extended until 6:00 p.m.
All major credit cards are accepted at most restaurants, shops and
hotels. You can draw cash in Danish currency (DKK) on your VISA or
EURO card from cash dispensers 24 hours a day using your cash
dispenser code.
Travel Documents
----------------
A valid passport is required for all international travellers. For
citizens of the U.S., Western European countries, and some other
countries, a visa is not required for entrance into Denmark. Visitors
from other countries may required a visa to enter Denmark. Check with
the Danish Embassy in your country. Foreign nationals coming from
the USA and other countries should also check their visa status for
re-entry to their country of departure.
Social events
-------------
On Tuesday evening, June 18, the participants of INET'91 are invited
to a reception. A gala banquet will take place Wednesday evening at
the restaurant NIMB in the centre of the city. This restaurant is
situated adjacent to the world famous amusement park TIVOLI, where an
ambience of good-will blends itself with the uniquely beautiful
surroundings to give you an unforgettable experience. After the
banquet, the participants will enter the TIVOLI garden, where the
evening ends with the traditional display of fireworks.
E-Mail facilities at INET'91
----------------------------
Access to the Internet will be supplied at the conference site. This
will enable you to attend to your E-Mail activities, while being in
Copenhagen. The terminal room will be open from 7:30 a.m. to 10:00
p.m. for the duration of the conference and attached meetings.
Book of Abstracts
-----------------
All participants will receive a copy of abstracts of all the talks
when they register. Additional copies may be purchased at the
conference for DKK 180.
Tourist and spouse program
--------------------------
If you would like to know more of the spouse program and tourist
opportunities connected to INET'91, please order the hard copy
program or send e-mail to LISTSERV@VM.UNI-C.DK with the command
GET INET91 SIGHTSEE
in the mail body.
Useful Addresses
-----------------------------------------------------------------
Conference Registration, Hotel Reservations and Tours in Denmark.
Office hours 9:00 a.m. -- 16:00 p.m. (time zone GMT + 1):
DIS Congress Service Copenhagen A/S
Herlev Ringvej 2 C
DK-2730 Herlev
Denmark
Telephone +45 44 92 44 92
Telefax +45 44 92 50 50
Telex 15 476 dis dk
-----------------------------------------------------------------
Conference Hotel:
SAS Scandinavia Hotel
Amager Boulevard 70
DK 2300 Copenhagen S
Denmark
Telephone +45 33 11 23 24
Telefax +45 31 57 01 93
-----------------------------------------------------------------
North American regional conference secretariate:
EDUCOM, INET'91 secretariate
1112 16th Street, NW
Washington DC 20036
USA
Telephone +1 202 872 4200
Telefax +1 202 872 4318
EMail <inet91@educom.edu>
-----------------------------------------------------------------
Pacific Rim regional conference secretariate:
WIDE project, INET'91 secretariate
5322 Endo, Fujisawa
Kanagawa 252
Japan
Telephone +81 466 48 9433
Telefax +81 354 90 7002
EMail <inet91@wide.ad.jp>
-----------------------------------------------------------------
Europe regional conference secretariate and local organizers:
UNI-C, INET'91 secretariate
DTH, bygning 305
DK-2800 Lyngby
Denmark
Telephone +45 45 93 83 55
Telefax +45 45 93 02 20
EMail <inet91@vm.uni-c.dk>
--------------------------cut here-------------------------------
E L E C T R O N I C R E G I S T R A T I O N F O R M
for the
International Networking Conference
Copenhagen - June 18-20, 1991
________________________
I For secretariat use I
I I
I I
I I
I I
I112 I
DELEGATE I________________________I
--------
Family name:_______________________________________________________
First name(s):_____________________________________________________
Institution/Company:_______________________________________________MLV
Institution address:_______________________________________________MLV
_______________________________________________
Postal code:_________ City:__________________ Country:_____________
Telephone:_________________ Telefax:___________________
Telex:______________ E-mail address:__________________________
ACCOMPANYING PERSON (Mr./Ms.)
------------------------------
Family name:_______________________________________________________
First name(s):_____________________________________________________
Date of arrival :___________ June 1991 Flight no:______________
Date of departure:___________ June 1991 Flight no:______________
___________________________________________________________________
INo of. I Fee category I I I
Ipersons I (all in Danish currency = DKK) I DKK I DKK I
I________I______________________________________I________I________I
I 1 I Delegate reg. until April 15 I 2,300 I I
I or 1 I Delegate reg. after April 15 I 2,700 I I
I I Tutorial-IP networking, June 17 I 1,300 I I
I or I Tutorial-Network building, June 17 I 1,300 I I
I I Accompanying person(s) I 0 I********I
I I Hotel deposit (room category A, B, C)I 1,100 I I
I I Hotel deposit (room category D) I 450 I I
I________I______________________________________I________I________I
I Social program I
I_________________________________________________________________I
I I North Zealand tour, June 16 I 490 I I
I I Welcome reception, June 18 I incl.I********I
I I Banquet, June 19 -- delegate I incl.I********I
I I Banquet, June 19 -- companion I 300 I I
I________I______________________________________I________I________I
I Accompanying persons program I
I_________________________________________________________________I
I I Copenhagen City tour, June 18 I 190 I I
I I Danish art and design tour, June 19 I 410 I I
I I Danish porcelain tour, June 20 I 350 I I
I________I______________________________________I________I________I
I Post congress tour I
I_________________________________________________________________I
I I Denmark at the sea, June 21--23 I 3,400 I I
I I Extra for single accomodation I 500 I I
I I Forward post congress tour info. I 0 I********I
I________I______________________________________I________I________I
I Total DKK I I I
I________I______________________________________I________I________I
PAYMENT
-------
All payment must be made in Danish kroner (DKK) only to the order of
INET'91, c/o DIS Congress Service Copenhagen A/S. No personal cheques
are accepted.
No registration or room reservation can be confirmed until DIS
Congress Service Copenhagen A/S has received your payment.
Please tick off as appropriate:
___The TOTAL amount has been posted to DIS Congress Service
Copenhagen A/S on banker's cheque/draft drawn on a Danish bank.
___The TOTAL amount has been transferred to account No. 3112-07395-7
(INET) in Den Danske Bank, Nytorv 7, 1450 Copenhagen K, Denmark. (Not
applicable for payments made from Denmark).
___The TOTAL amount, DKK ____________ may be charged to my credit card:
___Access ___Amex ___Diners ___Eurocard ___Master ___Visa
Card No:______________________ Expiration date:____________________
Date:__________________ Signature:__________________________
Please remember to state DELEGATE NAME and INET'91 on all payments.
HOTEL ACCOMODATION
------------------
Date of arrival :______________ June 1991
Date of departure :______________ June 1991
_______________________________________________________________
I Price I Single room I No. of I Double room I No. of I
I category I DKK / night I rooms I DKK / night I rooms I
I____________I_____________I________I_____________I___________I
I Conference I I I I I
I hotel (A) I 1080 I I 1320 I I
I____________I_____________I________I_____________I___________I
I B I 790 -- 940 I I 920 -- 1190 I I
I____________I_____________I________I_____________I___________I
I C I 610 I I 890 I I
I____________I_____________I________I_____________I___________I
I D I 375 I I 450 I I
I____________I_____________I________I_____________I___________I
All rooms are with private bath or shower. The price per night
includes service charge, tax and breakfast buffet (except category D
hotels). The paid deposit will be deducted from the final hotel bill.
Special wishes:_______________________________________________________
______________________________________________________________________
Return this registration form to <inet91@vm.uni-c.dk> and at the same
time send the payment to:
INET'91
c/o DIS Congress Service Copenhagen A/S
Herlev Ringvej 2 C
DK-2730 Herlev
Denmark
Telephone +45 44 92 44 92
Telefax +45 44 92 50 50
Telex 15 476 dis dk
Or print the form and send to the address above with your payment
or payment order.
Please remember to keep a copy of this form for your own record.
-------------------------------------------------------------------
P R O G R A M
-------------------------------------------------------------------
DRAFT PROGRAM INET '91
10.4.1991
PARALLEL TRACKS
Track 1: Application Areas
Track 2: Technology and Services
Track 3: Policy Issues
Track 4: Regional Issues
MONDAY 17.6
Tutorials
Coordinator: Craig Partridge
- Van Jacobson (Lawrence Berkeley Laboratory, USA)
"Issues in Gigabit IP Networking"
- Daniel Karrenberg (CWI, Netherlands) and Niall O'Reilly
(EARN, Netherlands)
"Starting a Research Network: Choosing a Strategy!"
TUESDAY 18.6
8:30-10:30 Plenary Session
- Welcome: Frode Greisen (UNI-C)
- Keynote Talk: "Europe '92"
Horst Huenke, Head of Coordination Operations Division,
DG XIII-A2, Commission of the European Communities
- Plenary Talk: "Future Networking and Infrastructure"
Robert E. Kahn, (Corporation for National Research Initiatives, USA)
10:30-11:00 Coffee
11:00-12:30 Parallel Sessions 1
Track 1: Physical Sciences
Coordinator: Brian Carpenter <brian@cernvax.cern.ch>
- David Williams (CERN, Switzerland-France)
"Worldwide aspects of networking for particle physics"
- Jean-Pierre Peltier (ONERA, France)
"Worldwide aspects of networking for
aerodynamics/fluid computation"
- Lynn F Ten Eyck (SDSC, USA)
"Worldwide aspects of networking for chemical computation"
Track 2: Internet Issues
Coordinator: Torben Nielsen <torben@foralie.ics.Hawaii.Edu>
- Phill Gross (NRI, USA)
"** title not known yet"
- Marshall Rose (PSI Inc.)
"Internet Network Management: History, Status
Report, and Future"
- Massimo Tartamella (Centro Universitario Calcolo, Italy)
"** title not known yet"
Track 3: The Role of Commercial Service Providers
Coordinator: Hank Nussbacher <hank@vm.tau.ac.il>
Presentations by network providers:
- Martin Schoffstall (PSI, USA)
- Rick Adams (Alternet, USA)
- George Abe (Infolan, Europe)
- Dai Davies (IXI, Europe)
Track 4: Europe
Coordinator: Dennis Jennings <jennings@irlearn.bitnet>
- Howard Davies (Univ. of Exeter, Great Brittain)
"Networking in Europe: The COSINE Perspective"
- Rob Blokzijl (NIKHEF, The Netherlands)
"Networking in Europe: The RIPE Perspective"
- Frode Greisen (EARN, Denmark)
"The Regionalisation of EARN"
- Roman Tirler (Commissariat a l'Energie Atomique, France)
"European High Speed Networking: A Critical Survey"
12:30-14:00 Lunch
14:00-15:30 Parallel Sessions 2
Track 1: Space Science
Coordinator: Tony Villasenor <villasen@nsipo.arc.nasa.gov>
Track 3: The Role of Commercial Service Providers
Presentation by network provider:
- Al Weis (ANS/USA)
Panel:
- Rob Blozkzijl, Dai Davies, Martin Schoffstall,
Al Weis, Stephen Wolff
Track 4: Eastern Europe
Coordinator: Peter Bakonyi <h25bak@ella.hu>
Soviet Union - Valerij Udalov
Hungary - Laszlo Csaba
Poland - Daniel Bem
Zechoslovakia - Jan Gruntorad
Bulgaria - Kiril Boyanov
15:30-16:00 Coffee
16:00-17:30 Parallel Sessions 3
Track 1: Education
Coordinator: Hidea Aiso <aiso@sfc.keio.ac.jp>
- Lee Caldwell (Novell Inc., USA)
"** title not known yet"
- Susan Calcari (MERIT, USA)
"Education over the International Internet"
Track 2: Collaboration Technologies
Coordinator: Glenn Ricart <gricart@dcsc.umd.edu>
- Florencio Utreras (?, Chile)
"** title not known yet"
- ** two more not yet confirmed
Track 4: Asia & Pacific Rim
Coordinator: Bob Kummerfeld <bob@cs.su.oz.au>
- Geoff Huston (AARNet, Australia)
"Developing an Academic and Research Network: the
Australian Experience"
- Mohamed b. AwangLah (?)
"The academic and research network in Malaysia"
- ** one more still unconfirmed
WEDNESDAY 19.6
9:00-10:30 Announcements, Keynote and Plenary Talks (15 min + 2 x 45 min)
- Keynote talk: "High Performance Computing and Communications"
Gene Wong, Associate Director
Office of Science and Technology, The White House, USA
- Plenary Talk: Paul van Binst (University of Brussels)
"Future of Networking in Europe"
10:30-11:00 Coffee
11:00-12:30 Parallel Sessions 4
Track 1: Library
Coordinator: Paul Peters <padler@umdc.umd.edu>
- Clifford A. Lynch (Univ. of California, USA)
"Application layer protocols and other architectural
and standards issues presented by networked
information resources and services"
- Peter H. Van Wiechen (Elsevier Science Publishers,
The Netherlands)
"Opportunities and threats for publishers presented
by the application of advanced networks to
scientific and technical communication"
- Peter Stone (Univ. of Sussex, United Kingdom)
(** to be confirmed)
"The organization of libraries and library services
in a national networking setting: The case of the
JANET National Library Users Group"
Track 2: Technologies of the 90s
Coordinator: Christian Huitema
<Christian.Huitema@mirsa.inria.fr>
- David J. Farber (Univ. of Pennsylvania, USA)
"The National Backplane -- a Different Approach to Gigabit
Networking"
- Jim Leighton (ESnet, USA)
"Evaluating US Fast-packet Services for Future
Network Designs"
- Christian Huitema (INRIA, France)
"High speed networks and the design of application
protocols"
Track 4: North America
- Ira Fuchs, Session Chairman (Princeton Univ., USA)
- Guy Almes (Rice Univ., USA)
- Steve Wolff (NSF, USA)
- Richard Mandelbaum (Univ. of Rochester, USA)
12:30-13:30 Lunch
13:30-15:00 Parallel Sessions 5
Track 2: Mail and Directory Services
Coordinator: Alf Hansen <hansen@cs.wisc.edu>
- Shoichiro Asano (U of Tokyo, Japan)
"Japanese Inter-university Mail Service"
- Robert Hagens (UW-Madison, USA)
"Common User-Interfaces for multi protocol
mail-services, case: the ECI project"
- Erik Huizer (SURFnet, The Netherlands)
"European OSI Directory Services, Paradise or
Fata Margana?"
Track 3: Open Scholarly Communication vs. Telecommunications Policy
Coordinator: David Kunkel <kunkel@psi.com>
Track 4: Latin America
Coordinator: Florencio I Utreras <FUTRERAS@UCHCECVM.BITNET>
- Daniel Pimienta (Republica Dominicana)
"REDALC: A Feasibility Study for a Network in Latin America
and the Caribbean"
- Florencio Utreras (Chile)
"SIRIAC: A Latin American Networking Initiative"
- Roberto Loran (Puerto Rico)
"CUNet: A Caribbean Universities Network: A SIRIAC Project"
- Guy de Teramond (Costa Rica)
"A Satellite Internet for Latin America: A SIRIAC Study"
- Victor Cid (Chile)
"SCARNET: The Southern Cone Academic and Research Network: A
SIRIAC Project"
- Alonzo Alvarez (Venezuela)
"Internetworking over X.25: The REACCIUN Network"
15:00-15:30 Coffee
15:30-17:00 Parallel Sessions 6
Track 1: Workstation Teleconferencing
Coordinator: Peter Kirstein <P.Kirstein@cs.ucl.ac.uk>
- Hide Tokuda (CMU, USA and Keio Univ., Japan)
"Operating System Support for Continuous Media Applications"
- S. R. Wilbur (UCL, UK)
"Personal Multimedia Conferencing for CAD/CAM"
- ** one more speaker to be announced
Track 2: Networks and Network Services of Year 2000
Coordinator: Richard Mandelbaum <rma@tsar.cc.rochester.edu>
- Tony Rutkowski (CERN, CH)
"** Title not known yet"
- Vint Cerf (Corp. for National Research Initiatives, USA)
"** Title not known yet"
- Charlie Catlett (NCSA, Champaign-Urbana, USA)
"Life after Internet: Making Room for New Applications"
- Toshiharu Aoki (NTT, Japan)
"Network Service Evolution Toward 2005"
Track 3: CCIRN and Global Networking
Coordinator: Kees Neggers <neggers@surfnet.nl>
- Jon Crowcroft (UCL, Great Britain)
"Traffic on the UK-US Fat Pipe: Usage Patterns"
- ** two other talks to be confirmed
Track 4: Special Issues for the Third World
Coordinator: Werner Zorn <zorn@ira.uka.de>
19:00- Conference Dinner including a Dinner Talk
- Dinner talk: Charles Brownstein (Federal Networking Council, USA)
"Impact of Networking on Science"
THURSDAY 20.6
9:00-10:30 Plenary talk and Rapporteur session
- Plenary Talk: Jun Murai (Keio Univ, Japan)
"Evolution, Technology, and Future of Japanese Research Networks"
- Rapporteur coordinator: Mike Roberts <roberts@educom.edu>
10:30-11:00 Coffee
11:00-12:30 Rapporteur Session continues, a Panel, and Closing
- Rapporteur coordinator: Mike Roberts <roberts@educom.edu>
- Panel on "Pressing needs and things to do"
- Steven Goldstein (NSF, USA), panel chairman
- Panel members:
- Mats Brunell (NORDUNET, Sweden)
- Erik Huitzer (SURFnet, The Netherlands)
- Tadoa Takahashi (PRP, Brazil)
- Florencio Utreras (U de Chile, Chile)
- Erik Naggum (Naggum Software, Norway)
- Closing: Larry Landweber (UW-Madison, USA)
12:30-13:30 Lunch
-----------[000231][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 91 15:33:00 GMT From: XELDIVE@VAX1.CC.LEHIGH.EDU To: comp.protocols.tcp-ip Subject: PPP patch for SunOS 4.x
Does anyone have or know where I can find a PPP patch (as opposed to SLIP) for SunOS 4.x. Please send any responce directly to xeldive@vax1.cc.lehigh.edu as I can't read news regularly. Thanks in advance, -- Gene.
-----------[000232][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 91 16:00:42 GMT From: bryan@tdd.sj.nec.com (Bryan Wear) To: comp.protocols.tcp-ip Subject: Static routes with SLIP under SUNOS4.0.3
I`ve been trying to get a remote SLIP machine to communicate through a point to point link, and a static route, to another machine not running SLIP. So far the only success was an ICMP reply to a ping. Will slip work over a static route? I know gated is out there, but I only need my point to point link to contact one other machine. Bryan Wear bryan@tdd.sj.nec.com NEC America San Jose, CA 94002 408-922-3887
-----------[000233][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 91 16:17:38 GMT From: bob@netlabs.com (Bob Rench) To: comp.protocols.tcp-ip Subject: ETHERNET tapping
I really enjoyed Tomer Geminder's request.
> Is whould thank anyone who will be willing to mail me names of
> products, or program of its oun which can tap to ETHERNET and format the
> received information into readable format. I look also for names of
> workstations and PC boards which their ETHERNET address is writen in the
> software and is not hardware fixed.
I'm not sure how many of you folks in are familiar with an American icon,
Maxwell Smart, a TV spy popular in the '60s, known for being quite a
bumbling fool (worse than Sellers' Inspector Clouseau). Tomer's request
sounds like something from "Get Smart". A sample snippet of dialog from
"Get Smart" goes something like this:
KAOS agent (disguised as a Trap-Net repairman):
Mr. Smart, can you tell me where your hidden Trap-Net is, and
how it works?
Maxwell Smart:
It's the old 'KAOS-agent-asking-for-information-about-my-hidden-
Trap-Net-trick'. That's the oldest trick in the book. Sorry, but
I can't tell you that.
KAOS agent:
But, I'm not a KAOS agent, I'm a Trap-Net repairman, and I'm here
to do some preventative maintenance on your Trap-Net. Got to keep
those things oiled, you know.
Smart:
Well, in that case, pretend that I am a KAOS agent. I stand over
here, and you, pretending to be me, can press that button over by
the door.
[At this point, Trap-Net falls from ceiling trapping Smart.]
KAOS agent (in his German accent):
You haff fallen into our trap, Herr Schmart!
Smart:
Don't tell me you really are a KAOS agent!
KAOS agent:
I am really a KAOS agent!
Smart:
I asked you not to tell me that.
----------------------------------------------------------------------------
These ramblings produced by the twisted mind of
Bob Rench
10920 Wilshire Blvd., # 1860
Los Angeles, Ca., 90024
(213) 824-2500
(213) 443-9740 - FAX
-----------[000234][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 91 16:41:36 GMT From: jonson@SERVER.AF.MIL (Lt. Matt Jonson) To: comp.protocols.tcp-ip Subject: Re: Goofy Router?
<Merton Campbell Crockett writes>
> Subject: Re: Goofy Router?
>
> Several points to consider. Afsc-bmo.af.mil is at 131.62.71.1 rather than
> 132.62.71.1.
Further point to consider: afsc-bmo is at 131.62.7.1...
^^^
> From my vantage point on DDN, I get a network unreachable.
> Chances are an AF Concentrator has recently been installed or has failed.
>
Whoa! The concentrator must not have as good a rep as I thought. As it
happens, the concentrator has been at Norton for quite a while, and
yesterday the cisco gateway's line to the PSN had hung up - probably why
you got the net unreachable. Last night, it hung again at around 1130, so
today (this morning) it had been flushed from the Core Gateways' tables, and
again should have been showing net unreachable. We couldn't get ahold of
anyone at the site to check it during the odd hours. It is now up.
We have had an outstanding problem with ciscos using the MCI card hanging
on the line to the Milnet Node. We have also had a problem with the Milnet
monitors just deciding to loop back ports that concentrators are connected
to without contacting us.
Oh, and if you look it up, the NIC still has the concentrator registered
as NORTON-PIV-I, which is the name of a Unisys mainframe that has been
rehomed behind the concentrator.
You can contact us for further questions, but things seems to be back to
normal.
/matt
--
Lt Matthew W Jonson jonson@server.af.mil snail-mail:
Network Systems Engineer 205-279-4075 SSC/SSMT
USAF DDN Program Office AV: 596-4075 Gunter AFB, AL 36114
-----------[000235][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 91 17:27:03 GMT From: paulo@durin.sparta.COM (Paul Oddo) To: comp.unix.sysv386,comp.protocols.tcp-ip Subject: Problem Configuring SLIP
Help, I have been trying to configure a slip connection from my home machine to the office network for TOO long with no success. I NEED SOME HELP! At home I am running Esix System V R.3.2.D with a SLIP connection configured on com port 2. Hanging off that is a Hayes Smartmodem 9600 configured for 9600 bps connections. At work we have a TCP based (of course) network of Sun Workstations and an Annex II Terminal Server all on the same ethernet backbone. I have configured one of the Annex's ports for a slip connection by setting the mode to slip and the line speed to 9600 bps. This also has a Hayes Smartmodem 9600 attached. I am trying to get a direct connection link. I would like to be seen as a remote node on the office network. Everything on the Esix Sys V side seems to be working properly. The modems seem to connect properly at 9600 and any telnet commands to remote hosts apparently route packets through the modem. The problem seems to be getting the Annex II to recognize its slip connection. A netstat -iS command on the Annex shows no slip interface in use when the modems are hooked up and no received or transmitted packets in the stats. I have tried every different configuration I can think of including all the suggested configurations from every manual I could find. Nothing Works. If anyone has had any luck with this sort of configuration (I know that it cannot be as difficult as it seems) I would appreciate any and all help in setting up the port parameters and configuration files. Thanks. Send replies to this news group or mail to: paulo@durin.laguna.sparta.com voice phone: (714) 768-8161
-----------[000236][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 91 18:32:24 GMT From: davison@menudo.uh.edu (Dan Davison) To: comp.protocols.tcp-ip Subject: Need CMU VMS TCP/IP--where can I get it?
I have been looking for the CMU TCP/IP, but according to ARCHIE it isn't available for FTP. Is there a FTP site somewhere, or a phone number to call? Thanks in advance, dan -- dr. dan davison/dept. of biochemical and biophysical sciences/univ. of Houston/4800 Calhoun/Houston,TX 77054-5500/davison@uh.edu/DAVISON@UHOU Disclaimer: As always, I speak only for myself, and, usually, only to myself.
-----------[000237][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 91 19:25:42 GMT From: andrew@jhereg.osa.com (Andrew C. Esh) To: comp.unix.wizards,comp.protocols.tcp-ip Subject: Re: Thin wire or twisted pair?
Just a suggestion, but wouldn't this subject work a little better in comp.dcom.lans? The discussion there is about cable and boxes. My impression of comp.protocols.tcp-ip is that it is above the physical layer of the OSI stack. -- Andrew C. Esh andrew@osa.com Open Systems Architects, Inc. Mpls, MN 55416-1528 Punch down, turn around, do a little crimpin' (612) 525-0000 Punch down, turn around, plug it in and go ...
-----------[000238][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 91 19:43:43 GMT From: andrew@jhereg.osa.com (Andrew C. Esh) To: comp.protocols.tcp-ip Subject: Re: whereis service needed
In article <1991Apr13.033331.7658@disk.uucp> proberts@disk.uucp (Phil Roberts) writes: > >I thought the NIC was for the Milnet only. Am I understanding you correctly >that the NIC can also provide me with domains outside the Milnet? If that >is true, how does one go about finding a site when one doesn't have Telnet >capability? > >-- > *************************************************************************** > | > Phil Roberts | Internet: proberts@disk.uucp > | Yes, it does include sites outside the Milnet. It also includes the names of the system administrators, and all the registered names of the users. Since the government is fairly good about registering it's employees, you can find out the name, address, and phone number of just about any person who works for the government and who has a login ID on an Internet connected host. Finger food. Try a whois on my site. You will see a couple of contacts, and a couple of the machines in the domain, but since I am not a registered user, you will see no entry for me. -- Andrew C. Esh andrew@osa.com Open Systems Architects, Inc. Mpls, MN 55416-1528 Punch down, turn around, do a little crimpin' (612) 525-0000 Punch down, turn around, plug it in and go ...
-----------[000239][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 91 20:01:40 GMT From: us267388@mmc.mmmg.com (Bradley D. Rhoades) To: comp.protocols.tcp-ip Subject: Re: Need CMU VMS TCP/IP--where can I get it?
In article <1991Apr17.183224.10404@menudo.uh.edu>, davison@menudo.uh.edu (Dan Davison) writes: > I have been looking for the CMU TCP/IP, but according to ARCHIE it > isn't available for FTP. Is there a FTP site somewhere, or a phone > number to call? Dan: The package costs roughly $150 for a site license. You can reach CMU at: Lori Blasik (412) 268-5896 or electronically: tcpip+@andrew.CMU.EDU Good luck, Brad -- Bradley D. Rhoades E/Mail: bdrhoades@mmc.mmmg.com 3M, 2465 Lexington Ave So NIC: BR79 Building 60-1N-01 WRK: +1 (612) 736 2874 Mendota Heights, MN 55120 FAX: +1 (612) 736-0431
-----------[000240][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 91 20:26:35 GMT From: sck@watson.ibm.com (Scott C. Kennedy) To: comp.sys.amiga.misc,compsys.amiga.datacom,comp.protocols.tcp-ip Subject: Once again... ka9q help for Amiga
I am setting up my Amiga at home to slip into work via ka9q yet, I am having problems which is not covered in the documentation, I need to know what ka9q calls the Amiga Serial Port. If anyone has a clue I would be grateful, I have tried all of the obvious ie: ser, ser:, com, com:, sl0, sl0:, sl, sl:, aux:, etc.. etc... And none of these work. If anyone could also answer what is the best defaults for a 9600 baud modem on a clean line, I would also be happy. -- ------------------------------------------------------------------------ Scott C. Kennedy (sck@watson.ibm.com) | "All we are saying ... Distributed High Performance Computing | is give peace a chance..." I.B.M. Thomas J. Watson Research Facility | John Lennon - Dec. 8, 1980 ------------------------------------------------------------------------
-----------[000241][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 91 21:04:32 GMT From: geoff@vax1.mankato.msus.edu To: comp.protocols.tcp-ip Subject: Request for: TCP/IP information...
Is there and archive anywhere that has a description of the tcp/ip protocal? ie. the Ieee definition of writeup of the standard.. please send me information. I am trying to put a reasearch paper together on the subject. Send me any information you might have on the TCP/IP standard. Thanks Geoff... geoff@att1.mankato.msus.edu geoff@vax1.mankato.msus.edu ...
-----------[000242][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 91 22:00:13 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Help designing address allocation in a metronet
The current 4.3BSD routed (maybe tahoe, certainly reno) allows you to put more than 1 interface on the same IP host number. That is, SLIP works fine for us, with the ethernet interface and the point-to-point SLIP interface using the same network/host number. There are a few improvements to routed that can be made to improve things in this situation, but they're fairly obvious. Vernon Schryver, vjs@sgi.com
-----------[000243][next][prev][last][first]---------------------------------------------------- Date: 18 Apr 91 00:59:40 GMT From: jclark@sdcc6.ucsd.edu (John Clark) To: comp.protocols.tcp-ip Subject: Re: finger weather is discontinued
In article <14784@helios.TAMU.EDU> kurt@photon.tamu.EDU (Kurt Freiberger) writes: +Tsk, tsk, tsk. Bill, I'm surprised at your naivete!! They are charging you +for the SERVICE of providing this valuable information! After all, it +probably takes the equivalent of a bank of Crays to process this so it can be +sent to all the radio and TV stations so that they can come up with their +authoritative weather predicions. We mere mortals cannot be trusted with +this raw information. It might upset the balance of civilization as we +know it! There is a magazine titled, 'Weather', which has a number of gizmos to pull down weather maps which are broadcast on some frequency or another, I can't recall specifically. The results can be displayed on the ubiquitus PC or the like. -- John Clark jclark@ucsd.edu
-----------[000244][next][prev][last][first]---------------------------------------------------- Date: 18 Apr 91 03:05:07 GMT From: dan@gacvx2.gac.edu To: comp.protocols.tcp-ip Subject: Re: finger weather is discontinued
In article <441@platypus.uofs.edu>, bill@platypus.uofs.edu (Bill Gunshannon) writes: > > I'm not sure how this commercial outfit gets the data, but it apparently > originates at the various NWS offices. There was a real nice X-windows > Weather Map program that just suffered the same fate. > Now I have a suggestion for a possible solution. > Maybe what is needed is for people to find out how this information is > collected from the NWS and then if possible, try and find INTERNET sites > near each of the NWS stations (I am near AVP) and get them a connection > so that we can gather the info ourselves. Then all we need is a central > site to hold and distribute the information. After all, isn't it our tax > money that is generating this data in the first place?? > > bill > > > -- > Bill Gunshannon | If this statement wasn't here, > bill@platypus.uofs.edu | This space would be left intentionally blank > bill@tuatara.uofs.edu | #include <std.disclaimer.h> Hmmm. How many institutions have a group that is doing some sort of long term weather data gathering. I seems to be a popular study subject here in the midwest, perhaps because of all these fields of crops arround here. Here at GAC we have an Apple // that is hooked to a unit that records temp, wind speed, air presure, etc. It is hooked to the Apple // by a serial port. The Apple // records the data to disk and draws graphs on the screen. Ever since the weather info server was localized I have been wondering if its data and data from others like it could be combined into something usefull. It wouldn't be as much fun as forecasts, but might get a group trying to make it work a grant. The grant might even be able to pay for a couple of years of forcasts from a weather service. It is data that is usefull to researchers, sounds like just the thing NSFnet exists for. Hmmm... -- Dan Boehlke Internet: dan@gac.edu Campus Network Manager BITNET: dan@gacvax1.bitnet Gustavus Adolphus College St. Peter, MN 56082 USA Phone: (507)933-7596
-----------[000245][next][prev][last][first]---------------------------------------------------- Date: Thu, 18 Apr 1991 03:33:45 GMT From: ejbehr@rs6000.cmp.ilstu.edu (Eric Behr) To: comp.unix.wizards,comp.protocols.tcp-ip Subject: Re: Thin wire or twisted pair?
andrew@jhereg.osa.com (Andrew C. Esh) writes: >Just a suggestion, but wouldn't this subject work a little better in >comp.dcom.lans? The discussion there is about cable and boxes. My >impression of comp.protocols.tcp-ip is that it is above the physical layer >of the OSI stack. In fact, a discussion about relative merits of thin Ethernet and 10BaseT has been going on there for a couple of weeks. I'm afraid I caused it by my question 8-() Very true, that doesn't necessarily have much to do with TCP/IP. I've gathered some of the responses - will be glad to send them on request. Please use mail, not a followup to this group. E. -- Eric Behr, Illinois State University, Mathematics Department Internet: ejbehr@rs6000.cmp.ilstu.edu Bitnet: ebehr@ilstu
-----------[000246][next][prev][last][first]---------------------------------------------------- Date: 18 Apr 91 09:13:40 GMT From: donp@na.excelan.com (don provan) To: comp.protocols.tcp-ip Subject: Re: Novell 802.3
The News Manager) Nntp-Posting-Host: na Reply-To: donp@novell.com (don provan) Organization: Novell, Inc., San Jose, California References: <280a1ac8@omega.uucp> Date: Thu, 18 Apr 1991 00:18:19 GMT In article <280a1ac8@omega.uucp> ash@omega.UUCP (Andrew Hardie) writes: >...Does this mean that Novell's "OSI Support" is just >protocol tunnelling of IPX inside 802.3 packets... No. Novell has an FTAM product which provides a full seven layer OSI stack for NetWare 3.11. This allows FTAM clients to access the NetWare file system. The IPX inside 802.3 is something Novell's been doing for years. It has never, to my knowledge, been referred to as "OSI Support". don provan donp@novell.com
-----------[000247][next][prev][last][first]---------------------------------------------------- Date: 18 Apr 91 11:22:43 GMT From: bob@MorningStar.Com (Bob Sutterfield) To: comp.protocols.tcp-ip Subject: Re: Request for: TCP/IP information...
In article <1991Apr17.150433.477@vax1.mankato.msus.edu> geoff@vax1.mankato.msus.edu writes: Send me any information you might have on the TCP/IP standard. Here's the current revision of a "suggested reading" list we tossed together. On paper, it fills a conveniently-sized notebook that can be left on a client's reference shelf, so they aren't such a continuing presence on the support telephone lines. .\" Feed me to troff -ms .TL A Reading List for the New Internet User and Administrator .AU Compiled by Robert A. Sutterfield .I bob@morningstar.com .R .AI Morning Star Technologies 1760 Zollinger Rd Columbus, Ohio 43221 +1 614 451 1883 .ds CH A Reading List for the New Internet User and Administrator .PP We recommend that newly-connected Internet users and administrators become familiar with the contents of the following documents, some themselves reading lists: .IP \(bu 2 .B RFC 1180: A TCP/IP Tutorial .R by T. Socolofsky and C. Kale (1991, 28 pps.) .IP \(bu 2 .B Introduction to the Internet Protocols .R by Charles L. Hedrick (1987, 27 pps.) .IP \(bu 2 .B RFC 1206: Answers to Commonly asked "New Internet User" Questions .R by G. Malkin and A. Marine (1991, 32 pps.) .IP \(bu 2 .B RFC 1207: Answers to Commonly asked "Experienced Internet User" Questions .R by G. Malkin, A. Marine, and J. Reynolds (1991, 15 pps.) .IP \(bu 2 .B RFC 1208: A Glossary of Networking Terms .R by O. Jacobsen and D. Lynch (1991, 18 pps.) .IP \(bu 2 .B RFC 1173: Responsibilities of host and network managers: A summary of the "oral tradition" of the Internet. .R by J. VanBokkelen (1990, 5 pps.) .IP \(bu 2 .B Introduction to Administration of an Internet-based Local Network .R by Charles L. Hedrick (1988, 46 pps.) .IP \(bu 2 .B RFC 1118: The Hitchhiker's Guide to the Internet .R by Ed Krol (1989, 24pps.) .IP \(bu 2 .B Internetworking with TCP/IP \*- Principles, Protocols, and Architecture .R by Douglas Comer (1988, Prentice-Hall, 261 pps. plus 5 appendices, bibliography, and index; ISBN 0-13-470154-2) The first three chapters of this textbook are of particular value to beginners. Comer should be available at any good technical bookstore. A second edition is rumored nearly ready for publication. .IP \(bu 2 .B RFC 1175: A bibliography of internetworking information .R by K. L. Bowers (1990, 42 pps.) .IP \(bu 2 .B Network Manager's Reading List: TCP/IP, UNIX, and Ethernet .R by Charles Spurgeon (1990, 27 pps.) .bp .PP We also recommend that the following be kept available for convenient reference: .IP \(bu 2 .B Improving The Security Of Your UNIX System .R by David A. Curry (1990, 51 pps.) .IP \(bu 2 .B RFC Index: Citations for the Internet Requests For Comment. .R (continuously updated by the Network Information Center) .IP \(bu 2 .B RFC 822: Standard for the format of ARPA Internet text messages .R by David Crocker (1982, 47 pps.) .IP \(bu 2 .B RFC 1035: Domain Names \*- Implementation and Specification .R by Paul Mockapetris (1987, 55 pps.) .IP \(bu 2 .B A Brief Tutorial on Sendmail Rules .R attributed to Charles L. Hedrick (1985, 16Kb). .IP \(bu 2 .B RFC 1036: Standard for interchange of USENET messages .R by Mark Horton and Rick Adams (1987, 19 pps.) .IP \(bu 2 .B RFC 977: Network News Transfer Protocol .R by Brian Kantor and Phil Lapsley (1986, 27 pps.) .IP \(bu 2 .B RFC 1129: Internet time synchronization: The Network Time Protocol .R by Dave Mills (1989, 27 pps.) .IP \(bu 2 .B RFC 1122: Requirements for Internet Hosts \*- Communications Layers. .R (1989, 116 pps.) .IP \(bu 2 .B RFC 1123: Requirements for Internet Hosts \*- Application and Support. .R (1989, 98 pps.) .IP \(bu 2 .B RFC 1200: IAB Official Protocol Standards .R (1991, 31 pps.) .IP \(bu 2 .B RFC 1087: Ethics and the Internet. .R (1989, 2pps.) .IP \(bu 2 .B RFC 1178: Choosing a Name for Your Computer .R by D. Libes (1990, 8 pps.) .IP \(bu 2 .B Inter-Network Mail Guide .R by John J. Chew et al (1990 and 1991, 20 Kb) .IP \(bu 2 .B USENET Software: History and Sources .R by Gene Spafford (1991, 15 Kb) .IP \(bu 2 .B List of Active Newsgroups .R by Gene Spafford (1991, 37 Kb) .IP \(bu 2 .B Netiquette Guides: .R .RS .IP \(bu 2 .B Rules for posting to Usenet .R by Mark Horton (1990, 9Kb) .IP \(bu 2 .B Emily Postnews Answers Your Questions on Netiquette .R by Brad Templeton (1990, 15Kb) .IP \(bu 2 .B A Primer on How to Work With the Usenet Community .R by Chuq Von Rospach (1991, 18Kb) .IP \(bu 2 .B Hints on writing style for Usenet .R by A. Jeff Offutt VI (1991, 4Kb) .RE .\" Local Variables: .\" mode: electric-nroff .\" compile-command: "groff -ms -TX75 mst-reading-list.ms" .\" End:
-----------[000248][next][prev][last][first]---------------------------------------------------- Date: 18 Apr 91 13:21:41 GMT From: tommyp@ida.liu.se (Tommy Pedersen) To: comp.protocols.tcp-ip Subject: NetBIOS vs. TCP/IP
Can anyone tell me the diffs and similarities between NetBIOS and TCP/IP or where to look for info? I would also like to know the same about IP and X.25. Thanks, /Tommy Pedersen ________________________________________________________________ |E-mail: tommyp@isy.liu.se || Telephone: +46 13 282369 | |S-mail: Tommy Pedersen || FAX: +46 13 289282 | | Dept. of EE ||______________________________| | Linkoping University || | | S-581 83 Linkoping || | | SWEDEN || | |________________________________||______________________________|
-----------[000249][next][prev][last][first]---------------------------------------------------- Date: 18 Apr 91 14:40:22 GMT From: alan@pluto.dss.com (Alan Warwick) To: comp.protocols.tcp-ip Subject: Public Domain TCP/IP for Vax/VMS
Hello - Does anyone know of a public domain (or rather cheap) version of TCP/IP that runs on a vax under VMS 4.7 ? Please reply via E-mail to alan@doc.dss.com since I do not have regular access to this group. Thank you very much in advance. Alan Warwick Datability alan@doc.dss.com -- +-----------------------------------------------------------------------------+ | Alan Warwick Datability Software Systems | | alan@doc.dss.com New York City | +-------------HELP !!! My PC has crashed and I can't boot up------------------+
-----------[000250][next][prev][last][first]---------------------------------------------------- Date: 18 Apr 91 15:36:46 GMT From: c_bstratton@HNS.COM (Bob Stratton) To: comp.protocols.tcp-ip Subject: Amiga question...
Mr. Kennedy,
I caught your note about running ka9q on an Amiga, and I had a question:
Are you using one of the new 3000-UX{B | D} machines? Under System V
Release 4? If so, give me a quick idea of their usefulness. I'm
evaluating machines for home/work, and I hate the idea of buying some
lousy Intel-based machine, just because they're easy to find. (I far
prefer Motorola CPU's).
If you're not using a 3000, then tell me how the 2000's are, as I may
pick one of those up anyway.
Thanks in advance!
Bob Stratton
Stratton Systems Design
+1 703 823 6463
strat@gnu.ai.mit.edu
c_bstratton@hns.com
-----------[000251][next][prev][last][first]---------------------------------------------------- Date: 18 Apr 91 17:00:40 GMT From: bmiller@CABELL.VCU.EDU (Bryan Miller) To: comp.protocols.tcp-ip Subject: programming question
I have a problem that is driving me crazy...and was hoping someone could help me. Here is the story: We have an old 3Com NCS-150 along with several CS/1's connected to our Ethernet backbone. Also connected to the backbone is a Pyramid mini. What we want to do is connect the printer port on the NCS-150 to a port on the CS/1. Then, a program running on the Pyramid would be used to gather the log data from the NCS-150 and store it in a file..... Has anyone done anything like this, or something similar, maybe with different equipment? Any pointers, suggestions, or other solutions would be greatly appreciated. Thanks, Bryan Miller
-----------[000252][next][prev][last][first]---------------------------------------------------- Date: 18 Apr 91 17:05:27 GMT From: ian@unipalm.uucp (Ian Phillipps) To: comp.protocols.tcp-ip Subject: Re: Wanted: /etc/hosts to DNS (rfc1035) format conversion program
jj@dcs.leeds.ac.uk (J Jackson) writes:
>Has anybody an off-the-shelf script of program that will read an
>/etc/hosts file and create the database fileformat required by the
>named daemon?
This updates the version number automatically. I run it from a make file in
/etc on our host.
I just noticed that I hard-coded the name (diamond) of our primary server.
Yechhh...
----cut here and put in your domain/network address----
/usr/local/bin/perl <<'END_SCRIPT'
# This script takes the /etc/hosts file, and makes up copies of host->name (named.net) and name->host (named.db) tables
#
$_ =`grep 'serial number' /etc/named.db`;
$major=1; $minor=1;
if ( /([0-9]+)\.([0-9]+).*;.*serial number/ )
{ $major = $1; $minor = $2 + 1; }
$zone = "unipalm.co.uk";
$net = '192\.9\.200';
open( db, '>/etc/named.db' ) || die;
open( net, '>/etc/named.net' ) || die;
open( stdin, '/etc/hosts' ) || die;
print db "@ IN SOA $zone. diamond.$zone. (
$major.$minor ; serial number
7200 ; refresh every two hours
7200 ; retry every two hours
12096000 ; expire in twenty weeks
86400 ) ; time-to-live
IN NS diamond.$zone.
";
print net "@ IN SOA $zone. diamond.$zone. (
$major.$minor ; serial number
7200 ; refresh every two hours
7200 ; retry every two hours
12096000 ; expire in twenty weeks
86400 ) ; time-to-live
IN NS diamond.$zone.
$zone. IN MX 0 mailhost.$zone.
IN A 192.9.200.5
";
while( <> )
{
next unless /^192\.9/;
s/#.*$//;
($number,$name,@alias)=split;
($net1,$net2,$net3,$net4)=split(/\./, $number );
print db "$name\tIN\tA\t$number\n";
print net "$net4\tIN\tPTR\t$name.$zone.\n"
;#if $number =~ /[^0-9]192\.9\.200\./;
#if $number =~ /[^0-9]$net\./;
while( $alias=pop alias )
{ print db "$alias\tIN\tCNAME\t$name\n"; }
}
END_SCRIPT
-----------[000253][next][prev][last][first]---------------------------------------------------- Date: 18 Apr 91 17:12:36 GMT From: dunford@NISD.CAM.UNISYS.COM (Stephen Dunford) To: comp.protocols.tcp-ip Subject: Raw Ip sockets
Dear TCP/IPers I am interested in finding out if there are any Unix applications which use a raw socket interface directly to IP (not ICMP). I would like to get the source code if possible as an example. -Rayna Please send replies to <rayna@cam.unisys.com> -------
-----------[000254][next][prev][last][first]---------------------------------------------------- Date: 18 Apr 91 18:15:04 GMT From: roy@alanine.phri.nyu.edu (Roy Smith) To: comp.protocols.tcp-ip Subject: self-referential arp?
Does it make any sense for something to arp for its own ethernet
address? This is some tcpdump output from a Kinetics FastPath I'm trying
to configure to use KIP/IPTalk:
13:18:44.62 wombat.phri.nyu.edu.16513 > 128.122.136.160.at-nbp: udp 43
13:18:44.62 arp who-has 128.122.136.160 tell 128.122.136.160
13:18:45.66 wombat.phri.nyu.edu.16513 > 128.122.136.160.at-nbp: udp 43
13:18:45.66 arp who-has 128.122.136.160 tell 128.122.136.160
13:18:46.68 wombat.phri.nyu.edu.16513 > 128.122.136.160.at-nbp: udp 43
13:18:46.68 arp who-has 128.122.136.160 tell 128.122.136.160
13:18:47.70 wombat.phri.nyu.edu.16513 > 128.122.136.160.at-nbp: udp 43
13:18:47.70 arp who-has 128.122.136.160 tell 128.122.136.160
13:18:48.72 wombat.phri.nyu.edu.16514 > 128.122.136.160.at-nbp: udp 43
13:18:48.72 128.122.136.160.16514 > wombat.phri.nyu.edu.at-nbp: udp 43
13:18:48.78 wombat.phri.nyu.edu.at-nbp > 128.122.136.160.16513: udp 43
13:18:48.78 128.122.136.160.at-nbp > wombat.phri.nyu.edu.16513: udp 43
What do the "arp who-has 128.122.136.160 tell 128.122.136.160"
packets mean? This is the kbox asking for its own ethernet address. Is
that normal, or something I might have configured wrong, or a bug in the
gateway code?
--
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!"
-----------[000255][next][prev][last][first]---------------------------------------------------- Date: 18 Apr 91 19:05:27 GMT From: ruggeri@ready.com (Francesco Ruggeri) To: comp.protocols.tcp-ip Subject: TCP/IP test suites and benchmarks
I would like to get some information on public domain or commercially available test suites and benchmarks for the TCP/IP protocol suites. Does anyone know where I can get it ? Thanks, Francesco Ruggeri
-----------[000256][next][prev][last][first]---------------------------------------------------- Date: 18 Apr 91 20:05:21 GMT From: c_bstratton@HNS.COM (Bob Stratton) To: comp.protocols.tcp-ip Subject: Finger services (surf server)
I came in on this (neat) discussion a tad late, so forgive me if this question has already been answered. I have heard apocryphal stories about the existence of a "surf server" somewhere on the Left Coast. (UCSD maybe?) The tale describes a wave height/frequency sensor with a line in to a PDP-11 or somesuch, with a finger server on the internet. Can anyone confirm this beastie's existence? Inquiring minds want to know. Bob Stratton strat@gnu.ai.mit.edu c_bstratton@hns.com
-----------[000257][next][prev][last][first]---------------------------------------------------- Date: 18 Apr 91 20:24:42 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: Request For Info On Dynamically Acquiring IP Addresses At Boot
PC/TCP for DOS has included a BOOTP (RFC 951) client since 10/89. It helps a lot, but because of the limit on the BOOTP packet's size and the amount of space reserved for other items, it isn't the be-all and end-all for automatic configuration. The IETF Dynamic Host Configuration working group was chartered sometime in 1990 to figure out what to do next, but I don't know how much progress they've made since. Originally they were considering BOOTP extensions, but they may have swung over to developing a new protocol. One hard problem they're faced with is short-term dynamic IP address assignment, where a PC picks a new address on each boot, and uses it for the life of that bootload.... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000258][next][prev][last][first]---------------------------------------------------- Date: 18 Apr 91 20:50:31 GMT From: rlg@STYX.DESKTALK.COM (Richard L. Gralnik) To: comp.protocols.tcp-ip Subject: An informal survey
Hi. A recent discussion of the comparative merits of slide latches versus screw/thumbscrew as a means of attaching a cable to a system port has prompted this unofficial opinion poll. Which do you prefer and why? or put another way - Do you like slide latches (the connector used for ethernet cables)? Why or why not? Do you like screw on connectors? Why or why not? Feel free to forward this note to friends. Also, please reply directly, not to the list. I'll publish the results if there are any. Thanks, Richard Gralnik (rlg@desktalk.com)
-----------[000259][next][prev][last][first]---------------------------------------------------- Date: 18 Apr 91 22:03:27 GMT From: ted@blia.sharebase.com (Ted Marshall) To: comp.os.vms,comp.sys.dec,comp.protocols.tcp-ip Subject: Query: performance of VMS TCP/IP implementations
We are in the process of selecting a TCP/IP vendor for VAX/VMS for a special project. I am in the process of contacting the vendors for information but I have two questions that may be difficult to get answers for that I was hoping that the net could help with. The implementations I am looking at are: UCX from DEC (is this officially called the "VMS/ULTRIX connection" or are these two different products?); WIN/TCP from The Wollongong Group; Fusion TCP/IP from Network Research; and MultiNet TCP/IP from TGV. I already have a copy of CMU-TEK TCP but this project requires a commercially supported product. My basic requirements include: TCP and IP (supported by ARP and ICMP); Share DEC Ethernet interface with DECnet; Process-to-process TCP connections (other protocols and utilities desired but not required; socket library not required, QIO interface adequite); At least 200 simultaneous TCP connections to other hosts (given a large enough VAX). I believe that all of the implementations I've listed meet these requirement, possibly excepting the last. If anyone knows of other vendors, please feel free to suggest them. My two basic questions: (1) Does anyone know what the actual limit of simultaneous connections is for a given implementation. Or at least, conformation that an implementation can make it to 200. (2) Has anyone benchmarked any of the implementations against another? I am interested in performance of TCP and IP only. For example, Given two VAXen on an Ethernet, a small program on one feeding data to a small program on the other over TCP, how many KB per second? Please mail any information to "ted@airplane.sharebase.com". I will summarize the responses, along with anything I get from calling the vendors. Email from vendors is also welcome. Thanks in advance. -- Ted Marshall ted@airplane.sharebase.com ShareBase Corp., 14600 Winchester Blvd, Los Gatos, Ca 95030 (408)378-7000 The opinions expressed above are those of the poster and not his employer.
-----------[000260][next][prev][last][first]---------------------------------------------------- Date: 18 Apr 91 23:06:37 GMT From: nelson@sun.soe.clarkson.edu (Russ Nelson) To: comp.protocols.tcp-ip Subject: Is the DNS "working"?
In article <1234@foo.bar> name@changed.to.protect (The Guilty) writes: Hi, there, Could somebody mail me the common pc-ftp sites' IP address to me ? My computer cann't check the site's internet name. Thanks, Per the quoted message, I'd have to say "No, the Domain Name System (DNS) is not working". Requests like these are not uncommon. They would be even more common except for the fact that people publishing site names have learned to include the IP address. I run a well-used archive site (grape.ecs.clarkson.edu) that recently (Feb. 20th) changed its IP address. Since then, we have kept a "victim" PC running on the old IP address [128.153.13.196]. The home FTP directory on this PC has files that direct a user to the new IP address. In the past six days, we have had 287 FTP sessions initiated at the OLD IP address. This, to me, is evidence that users have learned to avoid using host names, preferring to use IP addresses. I suppose it's a little unfair to lay the blame at the feet of the DNS. After all, hosts using the DNS can simply FTP to grape. Or, if your host doesn't use the DNS, a moment with nslookup or dig will get you grape's IP address. But it is exactly this latter case that causes the problem. On these hosts, a user must use a program that prints the IP address, then they must reenter the IP address to the FTP client. Once you know the IP address of a machine, why look it up again? Fairness, then, would dictate laying part of the blame on those system administrators who use /etc/hosts in preference to the DNS. And for the sake of truth, both I (on grape) and the sysadmin of sun.soe.clarkson.edu refuse to use the DNS (consider this message a confession, and the TCP-IP list the confessional). For my part, the OS on grape.ecs.clarkson.edu experienced kernel crashes when using the DNS. I went back to /etc/hosts and the crashes went away. But I think that's a minor problem. A more serious problem is faced by servers on the Internet. On the one hand, the sysadmin would like users to be able to access any machine on the Internet, and that means using the DNS. On the other hand, the sysadmin MUST (at least this one must) keep the machine running even if access to the name server is cut off, even temporarily. A typical plaintive user cry is "Why can't we use sun.soe.clarkson.edu just because omnigate.clarkson.edu is down?" Perhaps there is a work-around. If there is, it's not well documented, because as I showed earlier, sun.soe.clarkson.edu is not the only machine relying on /etc/hosts. I think we need a hero to document the work-around. I don't think the grand Usenet tradition of volunteering the complaintant should apply in this case because I'm not the sysadmin on sun.soe.clarkson.edu. Besides, I don't *know* what the work-around is. I just want the person who DOES know to step forward, or at least to remain still while the rest of us step backwards. Thank you, you wonderful person, whoever you might turn out to be. -- --russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker. It's better to get mugged than to live a life of fear -- Freeman Dyson I joined the League for Programming Freedom, and I hope you'll join too.
-----------[000261][next][prev][last][first]---------------------------------------------------- Date: 19 Apr 91 01:20:19 GMT From: wong_a@summer.chem.su.oz.au To: comp.protocols.tcp-ip Subject: Can't ftp to Apollos
For some reason we can't seem to ftp to our Apollo's. The standard login prompt appears but after entering the user-name we get, 530 User <user> access denied login failed Is there some security set-up that we've missed? ----------------------------------------------------------------------------- Adrian Wong, Dept.of Theoretical Chemistry wong_a@summer.chem.su.oz.au University of Sydney NSW 2006 Australia 061-2-692 4137 -----------------------------------------------------------------------------
-----------[000262][next][prev][last][first]---------------------------------------------------- Date: 19 Apr 91 04:13:26 GMT From: emv@OX.COM (Edward Vielmetti) To: comp.protocols.tcp-ip Subject: call for discussion of usenet newsgroup 'comp.protocols.ppp'.
[This will be familiar to you if you have read news.groups or comp.dcom.lans recently. I am not posting it from news because the gateway eats my address.] I am gathering opinions and interest for a new Usenet newsgroup, to be called 'comp.protocols.ppp'. It will discuss the Internet "Point to Point Protocol", implementations, protocol details, interoperability reports, software, hardware, etc. Currently there is a fair amount of discussion of PPP on Usenet; though it's scattered around in a number of groups, I was able to count on the order of 50+ relevant articles in a span of two weeks. Unfortunatly these articles were in more than a dozen different groups, and there's no single one group where the discussion would ordinarily gravitate. This group would cover the following subject: - the Point to Point Protocol - IETF efforts at standardizing and extending the protocol - free and commercial software implementations - interoperability reports - other protocols occupying similar ecological niches, including SLIP, compressed SLIP, and various HDLC things (but not other async protocols like Kermit or xmodem) - hardware details of async and sync communications, whenever that ends up being relevant. The usual Usenet ritual involves a "request for discussion", a period of time for hair-tearing and gnashing of teeth to determine whether the name is suitable, and then a "call for votes". The discussion thus far has centered on whether the name is too narrow and shouldn't be widened to encompass SLIP; I suspect that the actual discussion in a "ppp" group will include slip discussion for a while if only because of the installed base. Comments can go to me or to the list; discussion regarding the name is traditionally the playpen of news.groups. Substantive discussion of PPP would be best done in the two existing usenet groups that get most of the traffic (comp.dcom.lans and comp.dcom.modems) or on the IETF PPP mailing list (mail to ietf-ppp-request@ucdavis.edu to join). -- Msen Edward Vielmetti /|--- moderator, comp.archives emv@msen.com "With all of the attention and publicity focused on gigabit networks, not much notice has been given to small and largely unfunded research efforts which are studying innovative approaches for dealing with technical issues within the constraints of economic science." RFC 1216
-----------[000263][next][prev][last][first]---------------------------------------------------- Date: 19 Apr 91 05:37:49 GMT From: brian@NAPA.TELEBIT.COM (Brian Lloyd) To: comp.protocols.tcp-ip Subject: call for discussion of usenet newsgroup 'comp.protocols.ppp'.
I propose comp.protocols.serial-internetworking. The name is more in line with the likely discussion areas including slip, ppp, and using all this stuff to build or extend networks. Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@napa.telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333
-----------[000264][next][prev][last][first]---------------------------------------------------- Date: 19 Apr 91 06:09:40 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: self-referential arp?
In article <1991Apr18.181504.21390@phri.nyu.edu> roy@alanine.phri.nyu.edu (Roy Smith) writes:
> Does it make any sense for something to arp for its own ethernet
>address?
Many systems do this when they first boot. If it gets a reply, it means
that someone configured two hosts with the same address, and it can then
display an error message.
However, this doesn't seem to be what was happening in your case, because
it ARPs for itself whenever it receives the at-nbp packet. My guess is
that it's a configuration problem.
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar
-----------[000265][next][prev][last][first]---------------------------------------------------- Date: 19 Apr 91 10:41:06 GMT From: cnbs06@vaxa.strath.ac.uk (Bruce Rodger.) To: comp.os.vms,comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc Subject: UCX server implementation problem
We are currently trying to port Geoff Huston's ANU-NEWS server to run under UCX. We are having one major problem - how to start a new server process each time a TCP call is received on the news server port (conventionally port 119), and assign that stream to that process. Under Unix, it would be straightforward - you would just add an entry to /etc/services, specifying the program to be run when a call is received. Similarly, under CMU TCP and WIN TCP, you would modify sys$manager:internet.config or twg$tcp:[netdist.etc]servers.dat & twg$tcp:[netdist.etc]services respectively. Under multinet, you would use the $Multinet config/server command, and even under DECnet, you could use NCP. But how do you do this sort of thing under UCX ? My own feeling is that it can't be done in this way - there is no mention of anything like this in the UCX manuals. We'll probably have to take an approach similar to that used by the UCX FTP utility - a daemon (UCX$FTPD) runs as a detached process, "listening" to the appropriate port. When an incoming call is detected, a server process (UCX$FTPC) is created, and the logical stream assigned to this process. Obviously what we require is a program to performa function similar to the UCX$FTPD program. However, as we don't have the source code for UCX$FTPD available, I'm unsure how to go about writing the news_daemon. In particular, how is the new process created, and how is the stream assigned to that process ? Any information or example code would be gratefully received! Bruce. -- R.B. Rodger |JANET: R.B.Rodger@uk.ac.strath.vaxa OptoElectronics Grp|Internet:R.B.Rodger@vaxa.strath.ac.uk Elec. Eng. Dept | Strathclyde Univ | Thank you for dealing with ByteSabre Software Inc. Your Glasgow G1 1XW | bill is in the post. When it arrives, remember our motto: Scotland. | "We know where you live!"
-----------[000266][next][prev][last][first]---------------------------------------------------- Date: 19 Apr 91 14:37:45 GMT From: splee@gnu.ai.mit.edu (Seng-Poh Lee, Speedy) To: comp.unix.questions,comp.protocols.tcp-ip Subject: How to change the login message of telnetd?
Hi, Does anyone out there know how to change the default login message of telnetd? For example, on my machine, when you telnet to it, it gives HP-UX hostname 5.5 B 9000/330 login: I want to be able to add an additional message to this login message. Is there any way of doing this without having a customized version of /bin/login or /etc/telnetd? -- Seng-Poh Lee splee@gnu.ai.mit.edu
-----------[000267][next][prev][last][first]---------------------------------------------------- Date: 19 Apr 91 15:00:32 GMT From: bergum@SRC.Honeywell.COM (David Bergum) To: comp.protocols.tcp-ip Subject: Re: Is the DNS "working"?
In article <NELSON.91Apr18230637@sun.clarkson.edu> nelson@sun.soe.clarkson.edu (Russ Nelson) writes:
>Russ> In the past six days, we have had 287 FTP sessions initiated at the
>Russ> OLD IP address. This, to me, is evidence that users have learned to
>Russ> avoid using host names, preferring to use IP addresses.
Not neccessarily. It takes time for the old IP address to age out of local
cache, so the users may be using the host name and dns, but getting some
old data from their local server. A good thing to do when you are going to
change an IP address is to set a short TTL for the A RR some time in
advance of the change, so ti will age out more quickly and the old data
will be replaced with the new RR with a normal TTL.
A
-----/|\---------------------------------------+
- / | \ Bergum@CIM-VAX.Honeywell.COM |
- /__|__\ Dave Bergum [MN26-3190] |
- t--'--/ 2701 4-th Ave. S., Mpls, MN 55408 |
-~~~~~~~~~~ (612)870-5839 |
-----------------------------------------------+
-----------[000268][next][prev][last][first]---------------------------------------------------- Date: 19 Apr 91 15:03:33 GMT From: tjs@MSC.EDU (Tim Salo) To: comp.protocols.tcp-ip Subject: Re: An informal survey [slide-locks]
> Hi. A recent discussion of the comparative merits of slide latches versus > screw/thumbscrew as a means of attaching a cable to a system port ... Screw connectors have never brought down our network. Slide-lock connectors, on the other hand, have fallen off, (with or without help), and brought down parts of our network. (I once believed, without evidence, that slide- lock connectors were the largest single source of [LAN] network downtime.) Does anyone have experience replacing Ethernet slide-lock connectors with screw connectors? (Is there a reasonably easy way to do this?) Tim Salo Minnesota Supercomputer Center (612) 626-3047 tjs@msc.edu
-----------[000269][next][prev][last][first]---------------------------------------------------- Date: 19 Apr 91 15:35:18 GMT From: romkey@ASYLUM.SF.CA.US (John Romkey) To: comp.protocols.tcp-ip Subject: Finger services (surf server)
Ask Brian Kantor about the surf server. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice/fax: 415 594-1141
-----------[000270][next][prev][last][first]---------------------------------------------------- Date: 19 Apr 91 17:33:03 GMT From: ckollars@deitrick.East.Sun.COM (Chuck Kollars - Sun Technical Marketing - Boston) To: comp.protocols.tcp-ip Subject: Re: An informal survey
In article <9104182050.AA07838@desktalk.com> rlg@STYX.DESKTALK.COM (Richard L. Gralnik) writes: >Hi. A recent discussion of the comparative merits of slide latches versus >screw/thumbscrew as a means of attaching a cable to a system port has >prompted this unofficial opinion poll. > >Which do you prefer and why? > >or put another way - > >Do you like slide latches (the connector used for ethernet cables)? Why >or why not? The results of your survey are likely to be seriously skewed. Ethernet transceiver cables often don't work, and most folks blame it on the slide latch. So I'd guess you're going to get a lot of responses denigrating the slide latch. But the full story is that, although the Ethernet transceiver cable connector on many systems in fact doesn't work very well, it's _not_ the fault of the slide lock. The spec (see drawing on page 94, just above section 7.6.2) says that the connector should go on the _outside_ of the backpanel. But in order for printed circuit boards to be stuffed and soldered by automatic machinery then married to the system later, the connector is often mounted on the _inside_ of the backpanel. Result -- the connector wobbles and makes poor electrical connection even though the cable is inserted "all the way" and the slide lock is "closed". The Ethernet spec was apparently written by someone who either was not a mechanical engineer, or did not have any experience with automated manufaturing. The reputation of the slide lock will probably never recover from that oversight. --- chuck kollars <ckollars@East.Sun.COM> Sun Technical Marketing, located in Sun's Boston Development Center
-----------[000271][next][prev][last][first]---------------------------------------------------- Date: 19 Apr 91 21:28:30 GMT From: hotz@isi.edu (Steve Hotz) To: comp.protocols.tcp-ip Subject: Re: Is the DNS "working"?
In article <NELSON.91Apr18230637@sun.clarkson.edu> nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) writes: >> Per the quoted message, I'd have to say "No, the Domain Name >> System (DNS) is not working". Whoa whoa whoa there net cowboy ;-). That's a pretty amazing statement considering the hundreds of thousands of hosts that rely on DNS. While it is true that some of the implementations floating about could be better, and that DNS and YP still don't "play together" very well, for the most part DNS problems are due to misconfigurations by administrators. >> I run a well-used archive site (grape.ecs.clarkson.edu) that >> recently (Feb. 20th) changed its IP address. >> In the past six days, we have had 287 FTP sessions initiated at the >> OLD IP address. This, to me, is evidence that users have learned to >> avoid using host names, preferring to use IP addresses. This is usually evidence that DNS caching is working as it is supposed to, and that the reccommended procedure when changing DNS info of reducing the RR TTL before such a change is made wasn't followed. However, if it has been almost two months then there are either some *really* goofy implementations not paying attention to TTLs (the most common implementations do this correctly) or more likely, some folks don't use DNS resolver to get current information, so they use the old IP address they wrote down N months ago. >> I suppose it's a little unfair to lay the blame at the feet of the >> DNS. [... some text deleted ...] Now you're talking. The problem, more generally, is stale data, which by using the DNS mechanisms correctly, is quite nicely avoided. >> A more serious problem is faced by servers on the Internet. >> [... one hand deleted ...] On the other >> hand, the sysadmin MUST (at least this one must) keep the machine >> running even if access to the name server is cut off, even >> temporarily. A typical plaintive user cry is "Why can't we use >> sun.soe.clarkson.edu just because omnigate.clarkson.edu is down?" >> Perhaps there is a work-around. If there is, it's not well >> documented, because as I showed earlier, sun.soe.clarkson.edu is >> not the only machine relying on /etc/hosts. I believe it is documented with emphasis in the appropriate RFCs [1034 & 1035] that domain servers are required to be replicated (two is the required number). In fact, to be delegated a section of the namespace, one is supposed to show that this redundancy exists. If a domain can't keep one of two machines up at all times, then it makes sense to have further replication. With this redundancy, and a correctly configured /etc/resolv.conf life is good and peaceful! >> I think we need a hero to document the work-around. Although it may be reasonable to have the resolver library fall back on hosts.txt (argh) if no nameserver can be reached, i think i'd probably recommend that this "hero" be put on the "domain police" wanted list for crimes against the forward progress of the Internet ;-). Yours resolvedly, steve
-----------[000272][next][prev][last][first]---------------------------------------------------- Date: 19 Apr 91 22:45:40 GMT From: cathyf@lost.rice.edu (Catherine Anne Foulston) To: comp.protocols.tcp-ip Subject: Re: Is the DNS "working"?
In article <NELSON.91Apr18230637@sun.clarkson.edu> nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) writes: >I suppose it's a little unfair to lay the blame at the feet of the >DNS. .... >Fairness, then, would dictate laying part of the blame on those system >administrators who use /etc/hosts in preference to the DNS. Some of the blame should surely be laid at the feet of vendors who implement tcp/ip but not DNS. (Or who implement it so poorly that it's unusable.) If you're going to add tcp/ip capability to a system, you should include the ability to use the nameservice. (See RFC 1123.) Cathy -- Cathy Foulston + cathyf@rice.edu + Rice University, Network & Systems Support
-----------[000273][next][prev][last][first]---------------------------------------------------- Date: 19 Apr 91 23:00:15 GMT From: emv@ox.com (Ed Vielmetti) To: comp.protocols.tcp-ip Subject: Re: Is the DNS "working"?
anonymous ftp sites are particular prone to stale data, to wit: - the 'anonymous ftp site' list which gets posted monthly has ip numbers in it - 'comp.archives' postings have ip numbers in them (and I won't send one out unless I can identify an address - various and sundry of these numbers have been squirreled away on machines of all persuasions, including systems (like pre-NOS versions of KA9Q) with no working name server. If you capture the addresses of the originating sites to the old machine, it would be interesting to see a breakdown of what operating systems were involved. Dollars to donuts quite a few are running KA9Q net.exe. -- Msen Edward Vielmetti /|--- moderator, comp.archives emv@msen.com "With all of the attention and publicity focused on gigabit networks, not much notice has been given to small and largely unfunded research efforts which are studying innovative approaches for dealing with technical issues within the constraints of economic science." RFC 1216
-----------[000274][next][prev][last][first]---------------------------------------------------- Date: 20 Apr 91 02:39:11 GMT From: mclay@zoyd.ae.utexas.edu (Robert McLay) To: comp.dcom.modems,comp.protocols.tcp-ip Subject: PPP: Can't get PPP to work with sunOS 4.1.1 on SS2 (worked with 4.1)
I have been using PPP between a sun 4/330 and a sun SLC (4/20)
connected with 2 T2500 modems. Both systems are running sunOS 4.1
I want to get PPP to work now with a SPARCstation 2 (4/75) running 4.1.1
and it won't work (for me).
What happens is that ppp0 won't come UP
a) I have the source from
tut.cis.ohio-state.edu:pub/ppp/ppp-sparc4.1.tar.Z (patchlevel 4)
b) I installed the bug fix from ftphost.cs.athabascau.ca:
sun-patches/100149-03.tar.Z
c) I have ppp.c which has the following at the remote end (work)
if ((pgrpid = setsid()) < 0)
pgrpid = getpgrp(0);
if (tcsetpgrp(fd, pgrpid) < 0) {
perror("ppp: tcsetpgrp()");
exit(1);
}
and the following code in the ppp.c at the local end
if (setsid() < 0)
{
perror("ppp: setsid()");
exit(1);
}
I had to do this strange thing at home to avoid the
"ppp: tcsetpgrp ..." error.
What happen now when I try to connect to the SS2 running 4.1.1
is nothing ( there are no errors). Running ifconfig -a:
(local end)
vato(10)$ ifconfig -a
le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
inet 128.83.152.135 netmask ffff0000 broadcast 128.83.0.0
ppp0: flags=51<POINTOPOINT,RUNNING>
inet 128.83.152.135 --> 128.83.152.200 netmask ffffff00
lo0: flags=49<UP,LOOPBACK,RUNNING>
inet 127.0.0.1 netmask ff000000
*vato(11)$ netstat -rn
Routing tables
Destination Gateway Flags Refcnt Use Interface
127.0.0.1 127.0.0.1 UH 26 4647 lo0
128.83.152.200 128.83.152.135 UH 0 0 ppp0
128.83.152.135 128.83.152.135 UH 0 0 le0
default 128.83.152.200 UG 2 0 ppp0
As you can see ppp0 is not UP. The same is true at the other end
(remote end)
zoyd(1)$ ifconfig -a
le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
inet 128.83.152.200 netmask ffff0000 broadcast 128.83.0.0
ppp0: flags=10<POINTOPOINT,RUNNING>
inet 128.83.152.200 --> 128.83.152.135 netmask ffffff00
lo0: flags=49<UP,LOOPBACK,RUNNING>
inet 127.0.0.1 netmask ff000000
*zoyd(2)$ netstat -rn
Routing tables
Destination Gateway Flags Refcnt Use Interface
128.83.152.200 128.83.152.200 UH 21 22535 le0
127.0.0.1 127.0.0.1 UH 7 81 lo0
128.83.152.135 128.83.152.200 UH 0 0 ppp0
default 128.83.1.250 UG 0 35 le0
128.83.0.0 128.83.152.200 U 34 5496 le0
Anybody have any clues???
--
______________________________________________________________________________
Robert McLay | When you have a problem, put NO in front of
Manager CFD Lab | it and you have: NO PROBLEM.
Dept ASE-EM |
University of Texas at Austin | -- Eric Beckman's 2nd Law
|
mclay@wilbur.ae.utexas.edu |
-----------[000275][next][prev][last][first]---------------------------------------------------- Date: 20 Apr 91 08:13:53 GMT From: jmg@cernvax.cern.ch (mike gerard) To: comp.protocols.tcp-ip Subject: Re: tn3270 key mapping for DECstations
In article <9104151708.AA14025@ganges.ucop.edu> spgdrp@GANGES.UCOP.EDU ("Donald R. Proctor spgdrp@ganges.ucop.edu") writes:
>
> Has anyone devised a key mapping for tn3270 on DECstations that takes
> advantage of the function keys on the keyboard? I would love to
> received a copy of the map file if you have. Many thanks in advance.
>
>Gee, I'd even settle for the cursor keys (and maybe more reasonable
>handling of highlighted screen characters). Would you send me a note if
>you get replies to this?
Am I being stupid and missing something?
I run a strongly modified version of tn3270 on DECstations including
my own. I have various mappings, which are normally chosen as a function
of the TERM value (but can be overridden with a KEYMAP name).
Normally TERM is either xterm (if I run xterm) or vt300 (if I run a
dxterm window).
The function keys work fine except when the window manager is set up
to grab them first!
I don't understand the "highlighted screen characters" remarks: I do
actually do things with such characters, under the overall control
of the various termcap entries for blink, reverse, bold etc.
--
_ _ o | __ | jmg@cernvax.uucp
| | | | _ / \ _ __ _ __ _| jmg@cernvax.bitnet
| | | | |_) /_) | __/_) | (___\ | (_/ | J. M. Gerard, Div. DD, CERN,
| | |_|_| \_/\___ \__/ \___| (_|_| \_|_ 1211 Geneva 23, Switzerland
-----------[000276][next][prev][last][first]---------------------------------------------------- Date: 20 Apr 91 10:15:30 GMT From: GBODSO1@NUSVM.BITNET (HC Eng) To: comp.protocols.tcp-ip Subject: Re: Thin wire or twisted pair?
>Just a suggestion, but wouldn't this subject work a little better in >comp.dcom.lans? The discussion there is about cable and boxes. My >impression of comp.protocols.tcp-ip is that it is above the physical layer >of the OSI stack. Can someone tell me how to subscribe to lists with names separated by periods, like comp.dcom.lans? I am on BITNET only. From the above, am I right to say that the list which I am now reading from, which I subscribed to by sending a message to LISTSERV at UTDALLLAS, and is now distributed by TCP-IP@NIC.DDN.MIL, is also called comp.protocols.tcp-ip somewhere else? HC Eng - Singapore
-----------[000277][next][prev][last][first]---------------------------------------------------- Date: 20 Apr 91 10:30:52 GMT From: MAP@LCS.MIT.EDU (Michael A. Patton) To: comp.protocols.tcp-ip Subject: convert Ethernet numbers into ASCII text
A simple way to get this list is:
1) Find a unix system on the same wire
2) Ping each of the hosts (once should be enough, i.e. "ping -n1")
3) Type the command /etc/arp -a
You should get back a list of names, IP addresses, and Ethernet
addresses. There, wasn't that simple? Now for the hard question, are
you going to remember to do this every time any machine on your subnet
has maintenance performed on it? That can change the Ethernet
address. I can't tell you how many times someone tracking a problem
with numbers only got misled by using an out-of-date list, and you
often can't generate a new one if the network has problems you're
trying to fix.
__
/| /| /| \ Michael A. Patton, Network Manager
/ | / | /_|__/ Laboratory for Computer Science
/ |/ |/ |atton Massachusetts Institute of Technology
Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)
-----------[000278][next][prev][last][first]---------------------------------------------------- Date: 20 Apr 91 17:14:09 GMT From: davidd@HITL.VRNET.WASHINGTON.EDU (David Doll) To: comp.protocols.tcp-ip Subject: convert Ethernet numbers into ASCII text
Hello, I'm going to be bringing a network analyzer (sniffer) into our department and it displays the Ethernet number (for example: 8:0:2b:18:96:bf). I would prefer to look at the host name (for example: foo.cs.washington.edu). So what I would like to be able to do is to get the names from all the machine numbers in the department (~100 or so). Has anybody did this or know how or know what to do...? I'd appreciate any help. Thanks. If you e-mail me, I could post a summary if theres interest. David Doll Human Interface Technology Lab University of Washington M/S: FU - 20 Seattle, WA 98195 (206) 543-5075 davidd@hitl.vrnet.washington.edu
-----------[000279][next][prev][last][first]---------------------------------------------------- Date: 20 Apr 91 21:24:19 GMT From: sardella@strfleet.gsfc.nasa.gov (Tom Sardella) To: comp.protocols.tcp-ip,comp.sys.novell Subject: SUMMARY - Excelan EXOS TCP/IP Software
Many thanks to all those who responded to my request for help on the current status of the EXOS product. My main concerns were the continued support of this product (updates, new licenses, etc.) and getting a legal copy of the last released version. The bottom line is that Novell and Federal Technology Corporation (FTC) are currently negotiating for the rights on the software product and that FTC hopes to provide the support that we need. I guess we'll have to wait and see what happens. The following points were brought up in the responses and in other research I have done: 1. EXOS software a "dead" product We weren't the only people confused about the state of this product. Many people, including ourselves, thought that EXOS was placed in the public domain when Novell took over Excelan. We even had someone at Novell tell us in December, 1990, that this was the case. Representatives from both Novell and FTC now tell us that they are negotiating to turn the product over to FTC. 2. Excelan Hardware Support FTC does provide continued manufacture and support of the EXOS boards. We have had no problems to date with this support that I am aware of. 3. Use of EXOS code in Novell products We acquired a copy of "LAN Workplace for DOS 4.0" and they are still using the EXOS NET code on an EXOS 205 board. One thing I'm still confused about is what is the latest version and what do the version numbers mean? We originally started with V3.2. Avnish Aggarwal, who used to work for Excelan and now works for Novell, says the latest version is 4.Na. The version we got with LAN Workplace is 4.Ca. The "Na" and "Ca" suffixes seem odd. What we think we can do about the licensing problem at this point is to go ahead and buy all the LAN Workplace licenses we need and then run NET on our Multibus EXOS 201 boards rather than the PC EXOS 205 boards. The license agreement states that you can run object code on one licensed machine at a time, but they don't distinguish what a "machine" is. Are there any legal experts out there? It looks like our news server is OK now, so I can accept further postings on this subject. Tom Sardella Network Control Systems Branch, Code 532 NASA/Goddard Space Flight Center Greenbelt, MD sardella@strfleet.gsfc.nasa.gov
-----------[000280][next][prev][last][first]---------------------------------------------------- Date: 20 Apr 91 21:36:54 GMT From: sl@wimsey.bc.ca (Stuart Lynne) To: comp.protocols.tcp-ip Subject: Re: call for discussion of usenet newsgroup 'comp.protocols.ppp'.
In article <9104190537.AA00924> brian@napa.telebit.COM writes: >I propose comp.protocols.serial-internetworking. The name is more in >line with the likely discussion areas including slip, ppp, and using >all this stuff to build or extend networks. How about: comp.protocols.a-gratuitously-long-name-that-may-or-may-not-adequately-describe-the-group-to-discuss-ppp-and-related-protocols Personally I think that comp.protocols.ppp is succinct and to the point. As Ed pointed out there is currently a lot of discussion in a wide range of groups on ppp. We need to collect it together. If you want to suggest a different group to discuss building internets or WANS or whatever go to it. I suggest it should be seperate from comp.protocols.ppp. -- Stuart Lynne Computer Signal Corporation, Canada ...!van-bc!sl 604-937-7785 604-937-7718(fax) sl@wimsey.bc.ca
-----------[000281][next][prev][last][first]---------------------------------------------------- Date: 20 Apr 91 22:53:15 GMT From: TAYBENGH@NUSDISCS.BITNET (THE AGEIS) To: comp.protocols.tcp-ip Subject: Re: Raw Ip sockets
>I am interested in finding out if there are any Unix applications which >use a raw socket interface directly to IP (not ICMP). I would like >to get the source code if possible as an example. The BSD gated program is a working example of how to use raw socket. It is available in uunet.uu.net:networking. - Beng Hang (email: taybengh@nusdiscs.bitnet)
-----------[000282][next][prev][last][first]---------------------------------------------------- Date: 21 Apr 91 01:30:24 GMT From: beame@maccs.dcss.mcmaster.ca (Carl Beame) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Netbios B-node to M-node converter (looking for).
I remember a while ago someone posted the source to a program which intercepted B-Node Netbios Name requests and did some sort of Domain Name Lookup and response, thus allowing B-Node Netbios implimentations to function like M-Node stations. I saved this posting, but it got purged when I ran out of disk space. I find that I now need a copy of the programs. (So whats new? :-) ). Can anyone direct me to its location or email me a copy? - Thanks in advance, Carl Beame Beame@McMaster.CA
-----------[000283][next][prev][last][first]---------------------------------------------------- Date: 21 Apr 91 03:06:33 GMT From: brian@ucsd.Edu (Brian Kantor) To: comp.protocols.tcp-ip Subject: Re: Finger services (surf server)
In article <9104190835.AA25013@asylum.sf.ca.us> romkey@asylum.sf.ca.us writes:
>Ask Brian Kantor about the surf server.
> - john romkey Epilogue Technology
SIO Pier Weather: Sat Apr 20 19:55:00 1991
Air Temperature: 14.1 DegC (57.4 DegF)
Wind: 004.2 Mi/Hr From 294.1 Degrees
Barometer: 30.05 Inches
Water Temperature:
Surface = OUT OF ORDER
Bottom = 16.3 DegC (61.3 DegF)
Tide Gauge: 03.85 Ft.
Last Wave Data Record: Sat Apr 20 16:05
Sig Ht: 33.1 Cm Period: 11 Sec
-----------[000284][next][prev][last][first]---------------------------------------------------- Date: 21 Apr 91 19:27:29 GMT From: emv@ox.com (Ed Vielmetti) To: comp.protocols.tcp-ip Subject: Re: Raw Ip sockets
In article <89829A68693FA012DB@nusdiscs.bitnet> TAYBENGH@NUSDISCS.BITNET (THE AGEIS) writes: The BSD gated program is a working example of how to use raw socket. It is available in uunet.uu.net:networking. More accurately, the home of gated is gated.cornell.edu in /pub/gated/; the current release is gated.tar.Z (of 24 Jan 1990), and the working version is 2.0.1.10 (of 16 Apr 1991). uunet only has the old version. -- Msen Edward Vielmetti /|--- moderator, comp.archives emv@msen.com "With all of the attention and publicity focused on gigabit networks, not much notice has been given to small and largely unfunded research efforts which are studying innovative approaches for dealing with technical issues within the constraints of economic science." RFC 1216
-----------[000285][next][prev][last][first]---------------------------------------------------- Date: 21 Apr 91 21:22:59 GMT From: brendan@cs.widener.edu (Brendan Kehoe) To: comp.protocols.tcp-ip Subject: Re: finger weather
In <1991Apr21.205237.24332@mnemosyne.cs.du.edu>, caserta@athena.mit.edu writes:
>The Department of Atmospheric Sciences, University of Washington
>provides the following service, and also unusual application of finger.
>Do you know of any other unusual application of finger?
NO, they do NOT anymore. The company they get the information from
has it in their contract that the information can't be redistributed.
(Without a $150 fee, but that's not applicable. They have to keep it
on the UofW campus.)
--
Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu
Widener University in Chester, PA A Bloody Sun-Dec War Zone
"Does this person look relaxed to you? Well, it's actually an
experiment of Contour's new 565-E chair!"
-----------[000286][next][prev][last][first]---------------------------------------------------- Date: 22 Apr 91 01:46:25 GMT From: JCHAPMAN@MATHOM.CISCO.COM (John T Chapman) To: comp.protocols.tcp-ip Subject: [John T Chapman <CHAPMAN@mathom.cisco.com>: HSSI]
To Everyone Who Requested the HSSI Spec:
My apologies to everyone for taking so long to get back with copies
of the HSSI specification. We have received so many requests that
we have decided to offer it in the form of an anonymous FTP at
FTP.CISCO.COM
The file name is HSSI.NOT . There are two diagrams which are part of
appendix A and B which are not available yet until I can get the data
files translated. The diagrams in Appendix A and B, however, are
redundant and are fully described in the text of the document. They
will be called HSSI-A and HSSI-B with an extention of .PSF or
.NOT.
Attached is the original note explaining HSSI. Thanks for everyone's
interest.
John T. Chapman
---------------
Mail-From: CHAPMAN created at 11-Mar-91 17:18:55
Date: Mon 11 Mar 91 17:18:55-PST
From: John T Chapman <CHAPMAN@mathom.cisco.com>
Subject: HSSI
To: ez@gandalf.ca
cc: tcp-ip@nic.ddn.mil, cs@cisco.com, chapman@mathom.cisco.com
Message-ID: <12668647454.23.CHAPMAN@mathom.cisco.com>
Eugene,
You were interested in HSSI. HSSI stands for the High Speed Serial
Interface. It is a serial data interface capable of running up to 52
Mbps. The electrical signal levels are balanced ECL, and the
connector/cable used is the same as is used in SCSI-2.
HSSI was conceived and designed by cisco Systems and T3plus Networking
as an interface between cisco's router product and T3plus's DS3 DSU
product. cisco and T3plus have put this spec forward as an open
specification for industry use.
Originally defined in October of 1989, it is now in use by over 50
companies world wide. HSSI is becoming a defacto industry standard
for data interfaces which need to communicate to DS3 equipment, or to
other data facilities which exceed 10 Mbps.
I will send you a copy in the mail. If anyone else would like a copy,
please contact me at the address below. Your name will also go on a
distribution list to receive any future updates.
John T. Chapman
chapman@cisco.com
cisco Systems
1525 O'Brien Drive
Menlo Park, Ca 94555
-------
-------
-----------[000287][next][prev][last][first]---------------------------------------------------- Date: 22 Apr 91 03:32:37 GMT From: TAYBENGH@NUSDISCS.BITNET (THE AGEIS) To: comp.protocols.tcp-ip Subject: Is SunOS4.1 & above supports IPPROTO_RAW & IP_HDRINCL?
Hi netlander,
We would like to use Van Jacobson's traceroute program. However,
in order to make it work, kernel patching is required for supporting
IPPROTO_RAW & IP_HDRINCL (i.e. to send IP data with IP header included)
in SunOS4.0.x and below, and BSD4.y (y<=3) OSs. I would like is it still
necessary to patch SunOS4.1 in order run traceroute. In another word, is
SunOS4.1 support sending IP data with header using IPPROTO_RAW & IP_HDRINCL?
Please email to me, I will summarize.
Thanks a lot.
- Beng Hang (email: taybengh@nusdiscs.bitnet)
Dept of Info Syst. & Comp. Sc.
National University of Singapore.
-----------[000288][next][prev][last][first]---------------------------------------------------- Date: 22 Apr 91 05:44:27 GMT From: TAYBENGH@NUSDISCS.BITNET (THE AGEIS) To: comp.protocols.tcp-ip Subject: Re: Raw Ip sockets
Gated is written by Cornell Univ, thus not a BSD program. I apologize
for the mistake made. I thanks Mark Bodenstein for correcting me.
- Beng Hang (email: taybengh@nusdiscs.bitnet)
-----------[000289][next][prev][last][first]---------------------------------------------------- Date: 22 Apr 91 12:12:39 GMT From: powell@newyork.crd.ge.com To: comp.protocols.tcp-ip Subject: Communication clarification and information requested
I am an engineer and I have the task of trying to develop a system for mechanical engineering design that involves running programming tools such as fortran turbine design programs, compressor design programs, a C database, and a rule system(s) on different platforms. These platforms are IBM PC 386 or higher, Sun 4, HP, Decstation, and Vaxstation. All of my platforms are connected by TCP over ethernet. My problem is which communication software do I use to develop the client-server concept to run on each machine. I would appreciate any and all comments that would enlighten me about the pluses and minus of any given approach. Below I have listed some approaches that I have read about but need clarification from you more experienced software experts on the net. 1. I read about Sun's RPC which are suppose to allow the developer to concentrate on the application and not the network software. These sounded great in principle but is public domain RPC code available for the Vax (VMS and Unix lines) along with the IBM PC and HP. If yes then where can I get it? Suns manual says that RPC's have been run on these machines. To confuse me further, I understand that HP has a different version of RPC's then Suns. Does this mean that there are two different emerging standards? If yes then which is the one that appears to me winning? Does each competitor also support the others standard? 2. Berkley sockets vs System 5 sockets. Should I deal at the socket level and which type of sockets should I use? To run a program on a IBM PC from a Sun which type of sockets do I need on the IBM PC. Do sockets come for free with the TCP, and if yes then which type of sockets are they, and does a software developer have access to the TCP library needed to use these sockets? I appreciate any knowledge or pointers that I can use for helping me fill out my knowledge so that I can concentrate on the best approach to my problem. I have obtianed the Unix Network Programming book by Stevens. The book is excellent in describing the berkley sockets and TLI but I am not sure about which to use or if they are at all applicable when I have a VMS machine. Regards Dave
-----------[000290][next][prev][last][first]---------------------------------------------------- Date: 22 Apr 91 12:32:48 GMT From: cjsv@sserve.cc.adfa.oz.au (Christopher JS Vance) To: comp.protocols.tcp-ip,comp.unix.internals Subject: struct msghdr, passing fds between processes
I note that a BSD struct msghdr (used with sendmsg and recvmsg) allows the passing of `access rights'. I seem to remember someone indicating that this meant open file descriptors, sort of like a call on dup, except to a different process. Could someone who knows please point me to some documentation of this feature, or at least let me know what kinds of stream these can be passed over. I assume that the numbers change on the wire and come out as open fds at the other end. I guess that the stream must probably be a UNIX domain socket or pipe. Or am I barking up the wrong tree? What I'd like to do is start up a process which has access to my login terminal, have it open a socket-based connection to a server process, and have it pass access to my login terminal to the server process. (Subsidiary question - if I can do this, and my server process had no controlling terminal, does it suddenly inherit one?) What colour dragons be here? (i.e., what do I need to be wary of?) A bit of working code would be a bonus. If your reference is the BSD book by Leffler et al., I can borrow a copy, but won't bother unless it helps. I had a copy of the Advanced IPC document, but I don't seem to remember seeing it there, and the person who has my copy hasn't returned it. I can get it back, though, if it's worth it. -- Christopher
-----------[000291][next][prev][last][first]---------------------------------------------------- Date: 22 Apr 91 15:03:19 GMT From: mark@TELESYS.NCSC.NAVY.MIL (Mark L. Williams) To: comp.protocols.tcp-ip Subject: Re: convert Ethernet numbers into ASCII text
David Doll writes: >Hello, > I'm going to be bringing a network analyzer (sniffer) into our >department and it displays the Ethernet number (for example: 8:0:2b:18:96:bf). >I would prefer to look at the host name (for example: foo.cs.washington.edu). >So what I would like to be able to do is to get the names from all the >machine numbers in the department (~100 or so). Has anybody did this or know >how or know what to do...? I'd appreciate any help. Thanks. If you e-mail >me, I could post a summary if theres interest. I don't think the straight conversion implied by your subject is possible. To associate names with ethernet addresses in your Sniffer, you'll need to use the name management tools to enter names for the addresses the Sniffer finds on your network. I don't know of a utility to do this for you. In any event, the information has to exist somewhere before you can use it. BTW, the Sniffer's name field is not real long -- 14 characters or so, as I remember off-hand. If you do have a list of hosts and ethernet addresses somewhere, you'll have to make sure you can fit the whole name in the Sniffer's name field. Finally, deciding on the most useful naming convention for the Sniffer can be a real challenge. If your location is big and has multiple segments, a good name can really help you locate a problem, while a bad name may not help much. However, if you incorporate potentially variable information in the name, maintaining the name list can be a troublesome job. Mark
-----------[000292][next][prev][last][first]---------------------------------------------------- Date: 22 Apr 91 17:07:19 GMT From: rlstewart@eng.xyplex.com (Bob Stewart) To: comp.protocols.tcp-ip Subject: Re: An informal survey
> The Ethernet spec was apparently written by someone who either was not > a mechanical engineer, or did not have any experience with automated > manufaturing. The reputation of the slide lock will probably never > recover from that oversight. Yup. I know the guy. At the Ethernet 10 year reunion last fall, he asked what the designers would do differently. He (an electrical engineer) perpetrated the slide lock. He regrets it, and he wouldn't do it again. For what it's worth, the idea of the slide lock comes from the late 70s, when automated manufacturing techniques were probably a bit different. Bob
-----------[000293][next][prev][last][first]---------------------------------------------------- Date: 22 Apr 91 17:14:23 GMT From: benh@mom.corp.sgi.com (Ben Horowitz) To: comp.protocols.tcp-ip Subject: TCP/IP Tunneled through X.25
Do any of you have experience tunneling ip through an X.25 leased-line? I would be very interested in any empirical information regarding, performance, reliability and administrative costs of this configuration. Thanks, Ben
-----------[000294][next][prev][last][first]---------------------------------------------------- Date: 22 Apr 91 17:25:35 GMT From: eek@bcsaic.UUCP (Edwin King) To: comp.protocols.tcp-ip Subject: NetBIOS Name Server on a UNIX platform?
Does anyone know of a NetBIOS Name Server that will run on a UNIX platform? The NetBIOS Name Server would have to act as an DNS agent requesting name service from exiting DNS servers. Thanks, Ed King Internet eek@atc.boeing.com
-----------[000295][next][prev][last][first]---------------------------------------------------- Date: 22 Apr 91 18:28:50 GMT From: jfv@cbnewsk.att.com (j.f.van valkenburg) To: comp.unix.questions,comp.protocols.tcp-ip Subject: Re: How to change the login message of telnetd?
In article <1991Apr19.143745.14498@mintaka.lcs.mit.edu>, splee@gnu.ai.mit.edu (Seng-Poh Lee, Speedy) writes: > Hi, > > Does anyone out there know how to change the default login message of > telnetd? For example, on my machine, when you telnet to it, it gives > > HP-UX hostname 5.5 B 9000/330 > > login: > > I want to be able to add an additional message to this login message. Is > there any way of doing this without having a customized version of /bin/login > or /etc/telnetd? > > -- > Seng-Poh Lee > splee@gnu.ai.mit.edu The /etc/gettydefs has the login message Thanks, ------------------------ James F. Van Valkenburg a.k.a. "van" AT&T Attmail: !jfv jfv@cbnewsk.att.com Atlanta, GA. Voice 404-873-7920 =============================================================================== ---- Standard Disclaimers included -- Just another grunt at AT&T ---- ===============================================================================
-----------[000296][next][prev][last][first]---------------------------------------------------- Date: 22 Apr 91 20:09:40 GMT From: markb@unix386.Convergent.COM (Mark Beyer) To: comp.protocols.tcp-ip Subject: Re: Is the DNS "working"?
hotz@isi.edu (Steve Hotz) writes:
>In article <NELSON.91Apr18230637@sun.clarkson.edu>
>nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) writes:
>>> Per the quoted message, I'd have to say "No, the Domain Name
>>> System (DNS) is not working".
:
:
> for the most part DNS problems are due to misconfigurations
>by administrators.
Personally, I think the DNS administrative interface was designed by the IRS.
It has to rank right up there with root canal work as one of the most fun
things to contemplate.
But you're right, it's probably the administrators' fault(s).
( :-) ).
--
Mark Beyer
markb@convergent.com
{uunet,sun,decwrl,hplabs}!pyramid!ctnews!markb
-----------[000297][next][prev][last][first]---------------------------------------------------- Date: 22 Apr 91 20:34:04 GMT From: tengi@princeton.edu (Christopher Tengi) To: comp.protocols.tcp-ip Subject: Query: Standards work on IP over ISDN
We at Princeton are about to embark on some IP-over-ISDN experimentation, and would like to know if there is any work being done on standardizing what goes over the ISDN pipe. We would also be interested in hearing about what others are doing out there. Our eventual goal is to have a PRI line or 2 run into our computer center and BRI lines to staff and faculty homes. For now, we will be experimenting with a couple of BRI lines and 2 IBM-PC/XT machines, probably running ka9q. Thanks, /Chris ==========----------==========---------+---------==========----------========== UUCP: ...princeton!tengi VOICEnet: 609-258-6799 INTERNET: tengi@princeton.edu FAX: 609-258-3943 BITNET: TENGI@PUCC
-----------[000298][next][prev][last][first]---------------------------------------------------- Date: Mon, 22 Apr 91 21:28:46 GMT From: splee@wookumz.gnu.ai.mit.edu (Seng-Poh Lee, Speedy) To: comp.unix.questions,comp.protocols.tcp-ip Subject: Re: How to change the login message of telnetd? (Summary)
Thanks to all of those who responded suggesting the gettydefs or gettytabs file, but that only does it for a serial login. It doesn't work for a telnet login. The solution turns out to be replacing the telnetd entry in inetd.conf with a script file which first puts out the message and then execs telnetd. This works, I tried it. -- Seng-Poh Lee splee@gnu.ai.mit.edu
-----------[000299][next][prev][last][first]---------------------------------------------------- Date: 22 Apr 91 22:01:42 GMT From: mark@badger.dosli.govt.nz (Mark Wright) To: comp.protocols.tcp-ip Subject: telnet precedence over ftp?
We have several ethernets that will shortly be linked using intelligent bridges and 9600 baud digital lines. The primary purpose of this is to allow PCs to act as terminals (using telnet) over the link. We would like to have the use of ftp available, but don't want it to interfere with the response of the telnet sessions. What means (short of disabling ftp during working hours and implementing some sort of batching mechanism) are available to me? It WOULD be nice to have ftp always available, but only sending packets when the line is free (e.g. with low priority packets), although I guess this is nigh on impossible with bridging instead of routing. Any/all suggestions gratefully received - please mail me and I will summarise. -- Mark Wright. Dept. of Survey and Land Information,NZ. email: mark@dosli.govt.nz phone: 64 4 710-380 ext 8688