|
|
ARCHIVE: TCP-IP Distribution List - Archives (1993)
DOCUMENT: TCP-IP Distribution List for January 1993 (411 messages, 226682 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1993/01.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 Jan 1993 23:21:53 -0500 From: panvalka@cs.unc.edu (Anay Panvalkar) To: comp.protocols.tcp-ip Subject: Re: Books....
In article <bansal.725649006@depot.cis.ksu.edu.cis.ksu.edu> bansal@cis.ksu.edu (Vivek Bansal) writes: > >I am looking references to some books which deals with writing system >software using UNIX and TCP/IP. I already have Comer and Stevens . > >I intend to write some device driver using STREAMS, switch software and >other such kind of network software in near future. Any references in this >context would be really appreciated. I find the Sun Network Programming manual (Sun OS 4.1.2) very useful for STREAMS programming. -Anay
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 1 Jan 93 16:59:53 GMT From: klaus@kphunix.han.de (Klaus Peter Herrmann) To: comp.protocols.tcp-ip Subject: LAN 8bit
I like to have an 8 bit connection on the remote login (abount telnetd). The LAN is from Lachman. The Terminal-emulation on my PC can work in 7-bit or 8-bit mode. But the System (SCO Unix) gives only an 7-bit connection. Where can I change this? Klaus -- ------------------------------------------------------------------- Klaus - Peter Herrmann klaus@kphunix.UUCP W-3000 Hannover klaus@kphunix.han.de -------------------------------------------------------------------
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Fri, 1 Jan 1993 17:07:35 GMT From: vijay@iitb.ernet.in (Vijay J. Talati) To: comp.sys.cdc,comp.protocols.tcp-ip Subject: finger for CYBER (NOS/VE)
Hi, Has anyone out there ported the TCP-IP programs , especially finger and talk onto CDCNET's CYBER (NOS/VE).? Any pointers would be helpful. Please e-mail responses to vijay@gateway.iitb.ernet.in Thanks. Vijay -- ----------------------------------------------------------------------- Vijay Talati Email: vijay@iitb.ernet.in ERNet Lab. (X.400): Computer Centre s=Talati ou=gateway o=iitb prmd=ernet c=in
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Fri, 1 Jan 1993 18:41:00 +0000 From: shaman@cix.compulink.co.uk (Leo Smith) To: comp.protocols.tcp-ip Subject: Re: TCP/IP vs. PATHWORKS
In-Reply-To: <9212301417.AA22248@TIS.COM> mjr@TIS.COM (Marcus J. Ranum) ..Not forgetting Pathworks for Macintosh, which is an appletalk server on your DEC mini...:-)
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 1 Jan 1993 19:43:30 GMT From: scoggin@delmarva.com (John K. Scoggin, Jr.) To: comp.networks.noctools.wanted,comp.protocols.tcp-ip Subject: Looking for tools
In the Internet System Handbook, two tools are mentioned which appear to be quite useful: NCNS network performance measurement tool from CMU NNam network analysis tool from Merit Does anyone know how to go about procuring copies of these tools? --- +---------------------------------------------------------------------+ | John K. Scoggin, Jr. Email: scoggin@delmarva.com | | Supervisor, Network Operations Phone: (302) 451-5200 | | Delmarva Power & Light Company Fax: (302) 451-5321 | | 500 N. Wakefield Drive NOC: (800) 388-7076 | | Newark, DE 19714-6066 | +---------------------------------------------------------------------+
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Fri, 1 Jan 1993 22:01:12 GMT From: dalk@login.dkuug.dk (Lars Kalsen) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Mixed trafic - x.25/TCP/IP
Hi - and Happy New Year,
We are considering a new network which connect all of our different
sites through a WAN. We will probably buy some CISCO routers.
The trafic which is routed through the CISCO equipment is split
in two
- FTAM trafic based on x25 connections
- Interactive terminal sessions based on TCP/IP on an Ethernet.
The CISCO routers can mix these two kinds of input intp one 2Mbit channel
which connects the different sites.
My concern is now : Will the interactive traffic suffer when a heavy
FTAM transport is taking place ?. Will the file transfers affect the
responsetimes for the interactive traffic to a large extend ?.
Is you have any experience with this please E-mail (or fax) me the
information
~e
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 1 Jan 93 22:34:18 GMT From: guy@Auspex.COM (Guy Harris) To: comp.protocols.tcp-ip Subject: Re: Problems detecting a dead client connections ??????
>But this may well annoy (or bankrupt) users of PayPerPacket networks, or >those with Dial On Demand serial links. It may well also annoy people who don't want the application to give up on the machine on the other end of the connection just because some router or link between the two machines was down for a while....
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 2 Jan 93 11:09:45 GMT From: bill@twg.bc.ca (Bill Irwin) To: comp.protocols.tcp-ip Subject: Trouble configuring UUCP on TCP/IP
A piece of information that I forgot to provide: I had to change the entry in /etc/inetd.conf for uucpd from "/etc/uucpd" to "/usr/lib/uucp/uucpd" in order to get to the password prompt. I just changed the entry back to "/etc/uucpd" in both system's files and got the following: mchFind called (McDonal) list (rmail) num = 1 fillFlds: entered fillFlds: returning list (/) num = 1 list (/) num = 1 list (ALL) num = 1 _Request (TRUE), _Switch (TRUE), _CallBack (FALSE), _MyName (), _Commands ALL chdir(/usr/spool/uucp/McDonal) conn(McDonal) ProtoStr = e Device Type TCP wanted Internal caller type TCP tcpdial host McDonald, port 540 family: 2 port: 7170 addr: 02029384 set interface TCP processdev: calling setdevcfg(uucico, TCP) getto ret 5 sendthem (^M) expect: (gin:) login:got it sendthem (hammond^M) expect: (word:) user unknown^Jlost line errno - 108 ^^^^^^^^^^^^ close caller (5) delock(TCP,e) Call Failed: LOGIN FAILED exit code 101 Conversation Complete: Status FAILED TM_cnt: 0 Notice the "user unknown" above? I was getting this when there used to be a password on the account, before the password was even prompted for! Now I have removed the password because of some recent postings about two Sun systems needing the parity changed for the password. Since this is a TCP connection, the password is not necessary, so I've removed it. I don't know why there are two "uucpd" programs, one in "/etc" and the other in "/usr/lib/uucp", but using the one in uucp does not produce the "user unknown" message. I think that there is some TCP configuration info either missing or incorrect so that a UUCP connection attempt bombs this way. This is new territory for me so I'm just guessing at what could be wrong. The documentation does not cover setting up UUCP on TCP/IP very well at all. Thanks for any help you may be able to provide. -- Bill Irwin - The Westrheim Group - Vancouver, BC, Canada ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ uunet!twg!bill (604) 431-9600 (voice) | Your Computer bill@twg.bc.ca (604) 430-4329 (fax) | Systems Partner
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Sat, 2 Jan 1993 11:53:04 GMT From: andrew@megadata.mega.oz.au (Andrew McRae) To: aus.sun-works,comp.sys.sun.admin,comp.sys.sun.hardware,comp.protocols.tcp-ip,aus.sources Subject: Announcement: CSLIP for SunOS 4.1.x
A revamped SL/IP package for SunOS 4.1.x is available for
anonymous ftp from dmssyd.syd.dms.csiro.au, under
the file src/cslip-sunos.tar.Z
Kam Tam from the CSIRO has kindly allowed me to place the
package on dmssyd, as we do not have a direct Internet
connection. Any comments, complaints or corrections should
*not* be directed to anyone at the CSIRO, but to
me (andrew@mega.oz.au).
I have seen several people asking about cslip for 4.1.x, and
I have sent a few people this package and they tell me it works,
and that I should make it publicly available, so here it is.
The first origins of the software is lost in the mists of time;
Mark Andrews (from CSIRO) converted it to use SunOS STREAMS.
I used that package as a base, and have hacked it mercilessly to
add VJ TCP header compression, and to streamline it so that it can
run a little faster.
It has been tested and used on IPC's, SS1's and some other
Suns we have lying around, all under SunOS 4.1.1 - I don't
see any reason why it wouldn't drop into any 4.1.x system,
but your mileage may vary.
The primary motivation for doing this was to get TCP
header compression running on low speed (2400 baud) SL/IP
lines - PPP could not be used because the terminal servers
on the other end can't talk PPP. Even if you do not
use header compress, it is probably worth using this
package for ordinary SL/IP because of the CPU cycles you
will save.
Please send any comments, patches etc. to me. It would help
if someone compiled it and ran it on 4.1.3 just to see
if it works.
The README is attached.
Enjoy!
Andrew McRae inet: andrew@mega.oz.au
Megadata Pty Ltd, uucp: ..!uunet!mega.oz.au!andrew
North Ryde 2113 Phone: +61 2 805 0899
NSW AUSTRALIA Fax: +61 2 887 4847
------------------
README for SunOS 4.1.1 Compressed SL/IP
The original package was developed by Mark Andrews @ CSIRO DMS Sydney,
from the original SL/IP stuff.
This version has been much modified, with the dual goal of adding
Van Jacobsen's TCP header compression, and improved performance.
Even if you do not use the header compression stuff, the reduced
load on the CPU is worth it.
It should be completely compatible with old SL/IP drivers, as
the TCP header compression can be enabled/allowed via an option
to slip-attach.
A summary of changes:
- Added TCP header compression - The standard header compression code
was used unmodified *except* for a small mod to use mbufs in the
decompression so that the caller would not have to allocate 128 bytes
at the start of every packet. The new slcompress.c is included.
- Collapsed the SL/IP frame encoding from a separate STREAMS module
into the main module. An attempt to reduce extra overhead.
- Removed re-copies of data. As a result of having two STREAMS modules
in the stack, the same data was copied to and fro several times.
- Attempted to guess some buffer sizes to avoid scanning the whole
packet and count the ESCaped characters.
- Added the FLAGS setting code, and also put in the slip stats
counting.
By far and away the biggest difference in performance is due to the
(almost paranoid :-) avoidance of data copying. In the old code I
counted 4 copies of the same data; 1) from zs driver to STREAMS mblk,
2) in slipencode, from STREAMS mblk to internal buffer, 3) at end
of packet to another mblk for xfer to str_ip, 4) in str_ip from
the mblk to the mbufs. On output the code scanned the entire packet
and counted the escapes before allocating a mblk, then had to
scan the packet again to copy it.
The new code copies the mblk data from the zs driver directly to mbufs,
after doing the SL/IP frame decoding.
On output a buffer is allocated after a scratch-the-head fudge
factor is added to the actual length of the packet, and then the
packet is copied. If it runs out of room, it retries with a bigger
packet etc. I keep a track of the number of recopies, and it has
never needed to do one yet, so I figure it's a win.
The SunOS 4.1.1 serial driver for the Zilog 8530 (at least on
all the Suns I have tried) is still a performance black hole, but
at least the rest has been leaned down somewhat. It does make
a difference. The problem seems to be related to extra interrupts
and CPU load when the SL/IP is busy. For example, in one test I
sent large ping packets to an idle workstation on a 19.2 Kbaud
SL/IP line; the system time went to over 50%, and the number of
interrupts went to over 27000 per second (I would only expect around
4000 max), so if *anybody* knows what's going on and can give
me a magic fix, I would appreciate it.
Installation Instructions.
--------------------------
cp slip_var.h slcompress.h /usr/include/sys
cp slip_var.h slcompress.h /sys/sys
cp streamsip.c slcompress.c /sys/os
edit /sys/conf.common/files.cmn and add the lines:
os/streamsip.c optional slip
os/slcompress.c optional slip
edit /sys/sun/str_conf.c and add:
#include "slip.h"
#if NSLIP > 0
extern struct streamtab streams_ip;
#endif
#if NSLIP > 0
{ "str_ip", &streams_ip },
#endif
Edit your kernel configuration /sys/sun?/conf/MACHINE and add the
line below to install the SL/IP psuedo devices.
pseudo-device slip2
Build the new kernel, install and reboot.
make and install slip-attach and slipstat
run slip-attach
slip-attach [ -csa] device speed local remote netmask
Where -c will turn on header compression, -a will only turn it on
if a valid compressed SL/IP packet is received. The default is
to disable the header compression. -s will set a small MTU (256 bytes);
the default is 1006 bytes.
e.g.
/usr/local/etc/slip-attach -c /dev/ttya 19200 my_host their_host 255.255.255.0
slipstat will give you statistics about normal and compressed packets sent
and received. Run it with stdin set to the device that the SL/IP module
is running on e.g.
slipstat < /dev/ttya
Slipstat has an option (-c) to print the header compression stats, and
you can also put a delay and count in to continuously print the stats e.g:
slipstat -c 10 5000 < /dev/ttya
will print the header compression stats every 10 seconds for 5000 samples.
Enjoy!
Andrew McRae (andrew@megadata.mega.oz.au)
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Sat, 2 Jan 1993 13:53:51 GMT From: mg@world.std.com (marcia a gulesian) To: comp.protocols.tcp-ip Subject: TCP/IP for OS/2 - BOSTON DEMO - FEBRUARY 2 - 7:00 pm
UPCOMING EVENTS: Boston Area OS/2 USERS' GROUP (BCS) FREE SOFTWARE DOOR PRIZES ! REGISTRATION NOT REQUIRED ! January 12, 1993 7:00 p.m. (Tuesday) OS/2 DATA COMPRESSION; OS/2 PERFORMANCE TUNING & OPTIMIZATION: Part 1 - Theory of data compression, architecture of Stac Electronic's STACKER FOR OS/2, increasing the utility of fixed disks through data compression, live demonstration. Part 2 - Tips and techniques for matching the design of OS/2 with that of your DOS, Windows, and OS/2 applications. This talk will focus on the dissection of CONFIG.SYS. Note: Vendor demonstration of new OS/2 software for the "power user," beginning at 6:30 pm. February 2, 1993 7:00 p.m. (Tuesday) TCP/IP for OS/2; OS/2 PERFORMANCE TUNING & OPTIMIZATION Part 1 - Discussion and live demo of X Windows, NFS (operating peer-to-peer), Telnet, FTP, SMTP (E-Mail), SNMP (network management, SLIP (TCP/IP over a serial line) etc . . . . first across a Local Area Network, then over The Internet. Part 2 - Tips and techniques for matching the design of OS/2 with that of your DOS, Windows, and OS/2 applications. This talk will focus on strategies for partitioning the fixed disk, selection of a file system. etc. GENERAL MEETING INFORMATION LOCATION : IBM BOSTON COMPUTER CENTER, One Copley Place, Boston, Mass. Near Back Bay and Copley train stations. DIRECTIONS : Mass. Turnpike East - Exit 22 (Copley Square Lane) - First Left onto Dartmouth St - Next Left onto Huntington Ave. Enter COPLEY PLACE PARKING on left. FREE PARKING : Free parking when you spend $5 and have your parking ticket validated in any restaurant or store at Copley Place, provided you enter the garage after 5 p.m. For more information on meetings, please telephone Marcia Gulesian at (508) 369-3918.
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 3 Jan 93 16:45:48 GMT From: jessea@u013.me.vp.com (Jesse W. Asher) To: comp.protocols.tcp-ip Subject: Services getting CLOSED??
We've been having some problems lately with services getting CLOSED out.
When this happens, you can do a netstat and it will show telnet, for
example, as being in a "CLOSED" state. No one can telnet in because it
did not do a passive open. What could be causing this? When I kill the
offending telnet process, it clears up the problem. But I'd like to
know what is causing it in the first place so I can correct it. Any
ideas?
--
Jesse W. Asher (901)762-6000
Varco-Pruden Buildings
6000 Poplar Ave., Suite 400, Memphis, TN 38119
Internet: jessea@vpbuild.vp.com UUCP: vpbuild!jessea
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Mon, 4 Jan 1993 09:35:05 GMT From: mathias@solomon.technet.sg (Mathias Koerber) To: comp.protocols.tcp-ip Subject: wanted: rpc info, primer, generator
I'm looking for a primer on rcp, general info and some tools and maybe a generator to help in creating programs that use rpc. Any pointers? Thx alot Happy New Year Gong Xi Fa Cai -- Mathias Koerber | Tel: +65 / 7780066 ext 29 SW International Systems Pte Ltd | Fax: +65 / 7779401 14 Science Park Drive #04-01 | The Maxwell, Singapore Science Park | email: mathias@solomon.technet.sg Singapore 0511 | swispl@solomon.technet.sg ------------------------------------------------------------------------------- * Eifersucht ist eine Leidenschaft, die mit Eifer sucht, was Leiden schafft *
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Mon, 4 Jan 1993 09:55:42 GMT From: bill@twg.bc.ca (Bill Irwin) To: twg.sco-list,comp.protocols.tcp-ip,biz.sco.general,comp.mail.uucp Subject: Solution to: Trouble configuring UUCP on TCP/IP
bill@twg.bc.ca (Bill Irwin) writes: : unilabs!chare@uunet.UU.NET (Chris Hare) writes: : : In article <2808@twg.bc.ca> bill@twg.bc.ca (Bill Irwin) writes: : : > : : >I am having trouble configuring UUCP to use the TCP/IP network as : : >its "device". I have two systems, both running SCO UNIX 3.2.4, : : I went through this recently. this is what you need to do. : : In Devices, create an entry which reads : : TCP TCP,e - Any TCP 540 : : Note: this instructs uucp to use the 'e' protocol, and to connect on port : : 540. : I have the uucico accessing the TCP device now, but it is failing : after the password is given to the remote system. Following is a : portion of the -x9 log: : mchFind called (SystemB) [stuff deleted] : sendthem (^M) : expect: (gin:) : login:got it : sendthem (systema^M) : expect: (word:) : Password:got it : sendthem (password^M) : msg > Login incorrect.^Jimsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg : The ">imsg" stuff keeps going and going until the log is is over : 700Kb in size. Then it fails. I have seen this type of output : on a normal modem connection before, but can't recall what it is : a symptom of. Actually, this was the uutry log produced after I changed the entry in "/etc/inetd.conf" from "/etc/uucpd" to "/usr/lib/uucp/uucpd". There seemed to be another uucpd on the system and it seemed to get me a little further along in the dialogue. The original uucpd was producing a "user unknown" message right after the login name was given and before a password was even checked. This is the right uucpd to use, which was pointed out to me by belal@sco.com. The one in usr/lib/uucp was released with the UNIX runtime in error and was compiled from an earlier version of the source, with the wrong development environment. The mystery is solved. It seems that the Systems file entry chat script that was used when a modem was being used to connect was producing my "user unknown" message. Here are the two entries that I have used to fix the problem: #SystemB Any TCP,e Any - --gin:--gin:--gin:-BREAK-ogin:-BREAK-ogin: systema word: foobar SystemB Any TCP,e Any - gin: systema word: foobar The first one was being used until today, when I was mailed an extract from the SCO "How to" database that showed the greatly simplified chat script. I decided to take a shot in the dark and see if the BREAK (which I never saw being sent in the uutry log) was causing the trouble. The second entry worked fine, first try. I am now going to test the first entry by just removing the BREAK portion of the entry, to see if it is the syntax of the script that causes the problem, or the BREAK. I would like to thank the following people who responded and helped in this solution: fenner@cs.psu.edu (Bill) belal@sco.com (Bela) chare@unilabs.org (Chris Hare) fitz@wang.com giles@promed.com.au (Giles Lean) udo@umonk.GUN.de (Udo Monk) -- Bill Irwin - The Westrheim Group - Vancouver, BC, Canada ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ uunet!twg!bill (604) 431-9600 (voice) | Your Computer bill@twg.bc.ca (604) 430-4329 (fax) | Systems Partner
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 4 Jan 93 10:23:10 GMT From: nguyenth@amertume.ibp.fr (Thao Nguyen) To: comp.protocols.tcp-ip Subject: Distributed Applications?
Hi there, First: Happy New Year All ;) I'd like to know more about distributed applications. I mean how do they really work and how to implement them. If any gurus out there give me some hints on that. Also, if there's any newsgroups, mailings or books that I can refer to if I want to know more about distributed development. (e.g. is client-server applications can be called distributed?) Well I'm kindda *rookie* so excuse me if it's not the right newsgroup for that :) Thanx & Bye -- Thao Believe it or not but I have no e-mail address!
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 4 Jan 93 13:18:34 GMT From: moshek@FibHaifa.com (Moshe Kochinski) To: comp.protocols.tcp-ip Subject: Source files from TCP/IP Volume 2 Douglas E. Comer
Hi Netters, How can I get the source files from the Douglas E. Comer book - Internetworking with TCP/IP Volume 2 ? Thanks, -- Moshe Kochinski ------------------------------------------------------------------ Fibronics Ltd., Matam Industrial Park, Haifa 31905, ISRAEL phones: +972-4-313665/620 Fax: +972-4-313342 e-mail: moshek@FibHaifa.com or moshek@fibronics.UUCP ------------------------------------------------------------------ -- Moshe Kochinski ------------------------------------------------------------------ Fibronics Ltd., Matam Industrial Park, Haifa 31905, ISRAEL phones: +972-4-313665/620 Fax: +972-4-313342
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Mon, 4 Jan 1993 16:17:04 GMT From: dls@mentor.cc.purdue.edu (David L Stevens) To: comp.protocols.tcp-ip Subject: Re: Source files from TCP/IP Volume 2 Douglas E. Comer
The sources to volume II of _Internetworking_with_TCP/IP_ are copyrighted by Prentice Hall and available for sale only. You can get them through Prentice Hall (order number 47322-3 [Sun cartridge] or 47233-2 [9-track 1600 BPI tape]), or directly from us at a higher price. I'll send ordering information directly to you, and anyone else interested can send me mail for details. And while I'm at it, the sources for volume III are available for free via anonymous FTP to "ftp.uu.net", directory "published/books", file "comer.internetworking3.tar.Z". -- +-DLS (dls@mentor.cc.purdue.edu)
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 4 Jan 93 17:32:46 GMT From: jbvb@vax.ftp.com (James B. VanBokkelen) To: comp.protocols.tcp-ip Subject: Re: Software release problem?
In article <1huab3INNs4t@vttux1.vtt.fi> leino@rat.vtt.fi (Tapio Leino) writes:
a) If the TCP/IP-software in my PC is the Wollongong WINTCP for DOS
there is no trouble in connecting the PC (with telnet) to the 4D/20G
type IRIS with the older IRIX 3.3.1 operating system,
but it cannot be connected to the other IRIS (with IRIS 4.0.5)?
b) If I am using a product called PCTCP instead of the WINTCP I can
connect to both IRIS workstations with no trouble.
This started when we took the newest release 4.0.5 of IRIX! Before that I
could connect the PC to both workstations with WINTCP.
We have checked what happens on the lines. The messages seem to go to the
IRIS quite OK but the messages it sends to the PC are not understood by
the WINTCP and everything just stops.
It isn't really clear from this what the problem is: Does ARP fail (you
should be able to check the cache on both ends), or is it that ARP works
but TCP can't make a connection? Or is the problem that the TCP connection
opens but you never get a Telnet prompt?
If ARP fails, then the issue may be in the PC's hardware driver - you don't
say which network interface you're using, but the TWG driver may not go to
as much effort to salvage packets in the face of board errors.
If TCP won't connect, examine the packets and refer to RFC 793.
If Telnet never gets a prompt, the issue might be in Telnet option
negotiation. Check the Assigned Numbers RFC for the names of the options
that Irix is asking for, and check how the PC responds to each.
James B. VanBokkelen 2 High St., North Andover, MA 01845
FTP Software Inc. voice: (508) 685-4000 fax: (508) 794-4488
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Mon, 4 Jan 93 17:39:58 GMT From: peterson@commtg3.rtp.dg.com (Kevin Peterson) To: comp.protocols.tcp-ip Subject: BOOTP and the first stage bootstrap
Is there a configuration option in bootp that will allow a
client to get a bootp request from one machine and the first
stage bootstrap from another machine. We had the impression
that this is possible but I cannot find out how to accomplish this.
We have multiple subnets and are willing to put a bootp server
on each of the subnets. We would like the clients to boot off
of a different machine than the bootp server.
Thanks for any help.
- Kevin
--
,,,
(o o)
------------------------oOO--(_)--OOo-----------------------
| |
| Kevin Peterson | peterson@dg-rtp.dg.com |
| Data General Corporation | Research Triangle Park |
| Tie-line: 262-6342 | (919)248-6342 |
------------------------------------------------------------
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 4 Jan 93 17:43:08 GMT From: ad0@cbnewsj.cb.att.com (amarjet.dhingra) To: comp.protocols.tcp-ip Subject: Need help with CCITT SS7 docs picked from FTP site
I picked up some files from gumby.dsd.trw.com. These are postcsript format CCITT SS7 files in directory /pub/standards/ccitt/1988/postscript. WHen I print a file , text shows up fine but figures don't print at all. I looked at the file (Don't know anything about postscript language) and it SEEMS that source for figures is not there at all. Anybody has any ideas, please send email at att!mtgzfs3!ad0 or ad0@mtgzfs3.att.com Thanks in advance. Amarjit
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 4 Jan 1993 19:22:39 GMT From: trier@slc6.ins.cwru.edu (Stephen C. Trier) To: comp.protocols.tcp-ip Subject: Re: BOOTP and the first stage bootstrap
In article <1993Jan4.173958.17884@dg-rtp.dg.com> peterson@commtg3.rtp.dg.com (Kevin Peterson) writes: >Is there a configuration option in bootp that will allow a >client to get a bootp request from one machine and the first >stage bootstrap from another machine. This seems to be an ugly part of the BOOTP protocol. If you look in section 7.3 of RFC 951, the client is expected to use the siaddr field as the TFTP server's IP address and sname as the name. I would think it would be safe to set siaddr and sname to something other than the BOOTP server's address. Why would the client want the BOOTP server's address? What it really needs is the TFTP (or other boot protocol) boot address. I'm sure this will be a controversial suggestion, but I think it's justified. It satisfies the use of the siaddr (and sname) fields, if not the intent. If it really bothers you, think of it as "proxy BOOTP". ;-) -- Stephen Trier "We want to offer you a price that you Network software type just can't afford to take advantage of." Case Western Reserve University - Sales blurb from HSC Software trier@ins.cwru.edu
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 4 Jan 1993 19:41:14 GMT From: trier@slc6.ins.cwru.edu (Stephen C. Trier) To: comp.protocols.tcp-ip Subject: Re: BOOTP and the first stage bootstrap
Oops! I forgot to mention that your client will have to use the RFC 1084 vendor extensions, or a similar vendor extensions field, in order to give the client its netmask and gateway. You can't TFTP through a gateway without that info. -- Stephen Trier "We want to offer you a price that you Network software type just can't afford to take advantage of." Case Western Reserve University - Sales blurb from HSC Software trier@ins.cwru.edu
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Mon, 4 Jan 1993 21:25:53 GMT From: ronf@panther3.panther.mot.com (Ron Feigen) To: comp.protocols.tcp-ip,comp.unix.wizards Subject: Determining your pty
A little insight/info would really be appreciated!! 1) I need to write an application that services users who dail-up via a terminal server and are rlogin'ed or telnet'ed to a specified host. Is there any easy way from a 'C' application to determine the pty? 2) Since TCP/IP is the underlying transport, does using pty's cause significant additional overhead? Is there a straightforward method of accessing the socket, and doing socket level communication between the process and the terminal server? Thanks in advance!!!!!! Ron -- > Ron Feigen ronf@panther.mot.com
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 4 Jan 93 23:30:40 GMT From: mcdermj@atlantis.CS.ORST.EDU (Jeremy Mcdermond) To: comp.protocols.tcp-ip Subject: Help with SLIP setup
Can anyone send me some meaningful e-mail on how to set up SLIP from an IBM PC running FTP Software's PC/TCP with the Clarkson SLIP8250 packet driver to a Microvax II running 4.3 BSD? I have tried with no sucess, it seems as if no packets are making it out even though PC/TCP says that it is sending them. This is designed to be a dialup connection over 2400 baud modems. Thanks in advance. ------------------------------------------------------------------------------ Jeremy C. McDermond mcdermj@leela.cs.orst.edu OSU Computer Science Outreach Support Staff jeremy%symbio.uucp@cs.orst.edu ------------------------------------------------------------------------------
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 5 Jan 93 00:20:49 GMT From: jimg@ocean.rutgers.edu (Jim Gasprich) To: comp.protocols.tcp-ip Subject: STARLAN 10 10BASE-T hub unit doesn't like adapters
I have two somewhat old (circa 1988) STARLAN 10 hub units that are part of our TCP/IP ethernet LAN. Our lab is wired twisted pair with RJ-45 plugs. This is fine for our PCs with their RJ-45 port cards, but for our UNIX boxes (Suns), we need to use AUI to RJ-45 adapter boxes. Here's the problem. We recently bought a new (1991) adapter box from Cabletron, but it did not work when we wired it up. We have a few old adapters from AT&T (which came with our now defunct 3B2s (ick!)), and some others from a company called David Systems, which work A-OK. I am somewhat perplexed. Has there been a change in the 802.3 standard, are our hub units no longer usuable, or am I just missing something somewhere ?? It would seem a shame to throw out 22 usuable ports, especially with the price of some of the new fancy-pants hubs I've been looking at. I apologize if these are newbie questions, or are more appropriate to another, more wire-head hardware group. Thanks, Jim Gasprich e-mail: jimg@ocean.rutgers.edu Research & Support Slave tel: (908) 932-9631 Cook College Remote Sensing Center fax: (908) 932-8644 Dept of Natural Resources Rutgers University New Brunswick, NJ, O8903 "Du bist mein Gweckman" - Anonymous Fascist
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Jan 1993 07:29:59 GMT From: root@exicom.OZ.AU (Ray Soo) To: comp.protocols.tcp-ip Subject: ARE THERE ANY TOOLS TO FIND ROUTING TABLES OF REMOTE HOSTS?
is there any program(s) available which enables one to query remote gateways for routing table information i.e. do a remote netstat -rn on arbitrary hosts on the internet? please mail replies to ray@exicom.OZ.AU thanks, ray
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 5 Jan 1993 13:51:23 GMT From: leino@rat.vtt.fi (Tapio Leino) To: comp.protocols.tcp-ip Subject: WINTCP or DOS / IRIS Problem.
Hi folks, Last week I posted an explanation about a problem with the Wollongong WINTCP for DOS TCP/IT connection to IRIS workstation. I received two mail answers and one posting to this newgroup. Shantanu Kothavale from the Wollongong Group answered that there is something in the WINTCP which makes it do this. It had something to do with the large window sizes. Tom Mitchell from Silicon Graphics responded also and he said that the large window size of 60k in the new release of IRIX is the cause and that we should alter it as the parameter fortunately is external (the value in earlier release is 24k). The same has happened with several other products than WINTCP too. We did it and now it seems to work again. Thank you very much! This just makes us wonder. Why has the window size been changed? What do we lose changing it back to its original value, 24k? -- Tapio Leino Technical Research Centre of Finland / Laboratory of Structural Engineering mail: VTT/Rakennetekniikan laboratorio, P.O. Box 26, SF-02151 ESPOO, Finland tel: -358-0-456 6683, telefax: -358-0-456 7003 e-mail: Tapio.Leino@vtt.fi
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Jan 1993 16:00:17 GMT From: geranen@phx.mcd.mot.com (Scott Geranen) To: comp.protocols.tcp-ip Subject: Re: BOOTP and the first stage bootstrap
In article <1ia2pvINNj7b@usenet.INS.CWRU.Edu> trier@slc6.ins.cwru.edu (Stephen C. Trier) writes: >In article <1993Jan4.173958.17884@dg-rtp.dg.com> peterson@commtg3.rtp.dg.com (Kevin Peterson) writes: >>Is there a configuration option in bootp that will allow a >>client to get a bootp request from one machine and the first >>stage bootstrap from another machine. > >This seems to be an ugly part of the BOOTP protocol. If you look in section >7.3 of RFC 951, the client is expected to use the siaddr field as the TFTP >server's IP address and sname as the name. I would think it would be safe to >set siaddr and sname to something other than the BOOTP server's address. >Why would the client want the BOOTP server's address? What it really needs >is the TFTP (or other boot protocol) boot address. > >I'm sure this will be a controversial suggestion, but I think it's justified. >It satisfies the use of the siaddr (and sname) fields, if not the intent. >If it really bothers you, think of it as "proxy BOOTP". ;-) I have done exactly this. The only "trick" is that the CMU bootpd server checks to see if the download file is on the system. When the new "sa" (server address) tag is used in the bootptab file it doesn't check for the file -- I didn't want to try to verify that the file existed on the remote system. I've sent this modification to CMU but I haven't seen it come back out. Also, as noted in a later post, you need to send the gateway and subnet mask if you're booting through a gateway. Another useful modification I made was to be able to use host names instead of IP addresses for the "ip" tag. I hate duplicating information already in the hosts file. > >-- >Stephen Trier "We want to offer you a price that you >Network software type just can't afford to take advantage of." >Case Western Reserve University - Sales blurb from HSC Software >trier@ins.cwru.edu -- Scott Geranen Internet: geranen@phx.mcd.mot.com Motorola Computer Group uunet: uunet!unisoft!mcdphx!geranen 2900 S Diablo Way (DW220) FAX: (602) 438-3836 Tempe, Az 85282 phone: (602) 438-3238
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 5 Jan 93 21:42:47 EST From: roseberry@taney.uscghq.uscg.mil To: comp.protocols.tcp-ip Subject: Mil-Stds for TCP/IP
Does anyone know what Mil-Stds discuss the various parts of TCP/IP, SMTP, FTP, and Telnet ? Thanks. - Bert Roseberry US Coast Guard roseberry@taney.uscghq.uscg.mil
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 5 Jan 93 17:31:21 GMT From: soner@.cs.pitt.edu.cs.pitt.edu ( & Onder) To: comp.protocols.tcp-ip Subject: Re: PC-NFS SLIP and telnet problem
apollo@buengc.bu.edu (Doug A. Chan) writes:
: In article <1992Dec23.043717.1680@colorado.edu> garnett@refuge.Colorado.EDU (Santiago de la Paz) writes:
: >In article <105528@bu.edu> apollo@buengc.bu.edu (Doug A. Chan) writes:
: >>Whenever I try to telnet to a host, it just hangs there...
: >>What is wrong with telnet?
: >One of the primary reasons why a telnet attempt like this will hang is if
: >the remote host cannot reverse-lookup the IP address of the host you're
: >coming from. Make sure that both hosts are forward and reverse-mapped
: >(just for thoroughness, doncha know) if you're using DNS, or that they're
: >both in your machine's hosts files.
:
: It wasn't any host/IP address problem (FTP, ping, nfsping, NFS, finger all
: work fine!) The host table is okay... just telnet was broken.
: I turned on all of PC-NFS' telnet debugging and it got stuck during
: the initial negotiation (after it has established a connection with
: the host).
: -Doug
Reminds me of some sort of Telnet option negotiation loop or deadlock. Your
telnet program may be responding WILL to some option but may not be
properly doing so. Something like this may cause the other system to wait
indefinitely. The other possibility is the two pairs are entering to
an WILL/DO or DON'T/WONT kind of negotiation loop. I don't know how PC-NFS
telnet debugging feature works, but depending on the implementation, I
think you may not be able to see anything on the trace if a loop occurs.
Soner Onder
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Jan 1993 19:51:10 GMT From: k@hprnd.rose.hp.com (Steve Kao) To: comp.protocols.tcp-ip Subject: Re: STARLAN 10 10BASE-T hub unit doesn't like adapters
The main difference between StarLan10 and 10baseT is that 10bT requires LinkBeat, and SL10 doesn't know what it is. In a SL10 network, you need to disable LinkBeat on all devices on the network. - Steve Kao
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Jan 1993 20:47:02 GMT From: maw@netcom.com (Martin Walker) To: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Need NDIS spec please
Hello all. I am looking for a complete spec for NDIS. Please can anyone tell me where I can order/ftp/download a copy of said spec. Please respond via email to maw@netcom.netcom.com. Thanks in advance. Kean Johnston, via maw@netcom.netcom.com -- Martin Walker | "One way to stop a runaway horse ++27-12-344-3973 (w) | is to bet on him" ++27-12-998-7263 (h) | maw@netcom.com Pretoria, South Africa | martin@paradigm.CO.ZA
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 5 Jan 93 22:37:54 GMT From: olo@ccwf.cc.utexas.edu (Lee Thomas) To: comp.protocols.tcp-ip Subject: NEEDED: A good TCP/IP short course. (Austin, Dallas area)
I need to attend a good TCP/IP course that would cover administration issues, network management, programming (RPC or some DCE maybe), etc. Thanks for any ideas! -Lee Thomas --------------------------------------------------------------------------- Lee Thomas Voice: (512)322-6386 Systems Specialist FAX: (512)322-6350 City of Austin Electric Utility Internet: olo@ccwf.cc.utexas.edu ---------------------------------------------------------------------------
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Jan 1993 22:49:47 GMT From: davidr@cs.uow.edu.au (David Ian Raymond) To: comp.protocols.tcp-ip Subject: Re: Distributed Applications?
nguyenth@amertume.ibp.fr (Thao Nguyen) writes:
>Hi there,
>First: Happy New Year All ;)
>I'd like to know more about distributed applications. I mean how do they really work and how to implement
>them. If any gurus out there give me some hints on that.
>Also, if there's any newsgroups, mailings or books that I can refer to if I want to know more
>about distributed development. (e.g. is client-server applications can be called distributed?)
>Well I'm kindda *rookie* so excuse me if it's not the right newsgroup for that :)
>Thanx & Bye
>--
>Thao
>Believe it or not but I have no e-mail address!
Hi,
This seems like a good book:
Distributed systems / edited by Sape Mullender.
New York, N.Y. : ACM Press ; Wokingham, England ; Reading, Mass. :
Addison-Wesley Pub. Co., c1989.
I had a bit of a read of it to get a basic idea of distributed systems.
David
davidr@cs.uow.edu.au
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 5 Jan 1993 23:00:12 GMT From: emv@msen.com (Edward Vielmetti) To: comp.protocols.tcp-ip,comp.mail.mime,comp.os.ms-windows.apps Subject: Frontier MIME support in Super-TCP for Windows ?
Open Systems Today (4 Jan 1993) reports that Frontier has a MIME mailer
for MS Windows. Can anyone from Frontier comment on how well it works,
or even send me some nice multimedia mail to show that it does?
The listed phone contact is +1 414 241 4555, no email was listed tho.
thanks,
Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
Msen Inc., 628 Brooks, Ann Arbor MI 48103 +1 313 998 GLOB
(keeper of the comp.mail.mime FAQ, write for a copy)
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 6 Jan 93 00:33:23 GMT From: valdis@black-ice.cc.vt.edu (Valdis Kletnieks) To: comp.protocols.time.ntp,comp.unix.aix,comp.protocols.tcp-ip Subject: Re: xntp3 socket problem with UDP datagrams from INADDR_ANY.
In article <1992Dec29.115408.103086@ipgaix.unipg.it> peppe@ipgaix.unipg.it (G. Vitillaro) writes:
>
>I had this problem with xntp3 (in xntpd) under AIX/370 1.2.1 (1400).
>I'm interested to understand if I met a bug and
>if there is any way to go over the problem.
Oh.. *that* little bug. It drove me bonkers while trying to get
AIX/370 and xntp to cooperate. Here's the fix I used to work
around it:
*** ntp_io.c.dist Tue Mar 17 16:39:15 1992
--- ntp_io.c Tue Mar 17 16:40:26 1992
***************
*** 688,693 ****
--- 688,694 ----
printf("sendpkt(%s, %s, %d)\n", ntoa(dest),
ntoa(&inter->sin), len);
#endif
+ if (inter == any_interface) inter++;
for (slot = ERRORCACHESIZE; --slot >= 0; )
if (badaddrs[slot].port == dest->sin_port &&
This basically prevents xntpd from "seeing" the 'wildcard' interface.
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jan 1993 01:57:23 GMT From: ray@exicom.OZ.AU (ray) To: comp.protocols.tcp-ip Subject: MORE ON TOOLS TO FIND ROUTING TABLES OF REMOTE HOSTS
many thanks to all those people who replied to my last post, when i asked how would i perform the equivalent of a remote "netstat -rn" on arbitrary internet hosts. Most people suggested SNMP. However, wouldn't this limit me to querying hosts running SNMP? I was hoping that there would be a solution which only required that the gateway in question be running some routing daemon talking RIP (e.g. gated), which is a more common property of gateways than SNMP . I vaguely remember hearing of a program called ripquery, but i can't find any info on it. Has anyone heard of such a thing ; would this do the job I just described in the previous paragraph?
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 6 Jan 93 05:21:09 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: MORE ON TOOLS TO FIND ROUTING TABLES OF REMOTE HOSTS
In article <C0EtFo.FCq@exicom.OZ.AU>, ray@exicom.OZ.AU (ray) writes: > many thanks to all those people who replied to my last post, when i asked how > would i perform the equivalent of a remote "netstat -rn" on > arbitrary internet hosts. > > Most people suggested SNMP. However, wouldn't this limit me to > querying hosts running SNMP? > > I was hoping that there would be a solution which only required > that the gateway in question be running some routing daemon > talking RIP (e.g. gated), which is a more common property of gateways > than SNMP . > > I vaguely remember hearing of a program called ripquery, but i can't > find any info on it. Has anyone heard of such a thing ; would this > do the job I just described in the previous paragraph? There is `rtquery` source in the standard 4.3BSD distribution (I think in the tools subdirectory of the routed subdirectory), and binary shipped on some (at least one--guess which) vendors' workstations. Rtquery works by sending out mostly ordinary RIP requests. It obviously doesn't work if you are not using RIP. It also does not work if the remote machine is picky, as cisco routers seem to be. Vernon Schryver, vjs@sgi.com
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Wed, 06 Jan 1993 16:13:21 From: jbvb@vax.ftp.com (James B. VanBokkelen) To: comp.protocols.tcp-ip Subject: Re: Mil-Stds for TCP/IP
In article <1993Jan5.214247.123@taney.uscghq.uscg.mil> roseberry@taney.uscghq.uscg.mil writes:
Does anyone know what Mil-Stds discuss the various parts of TCP/IP,
SMTP, FTP, and Telnet ?
MIL-STD-1777 is IP, 1778 is TCP, 1780 is FTP, 1781 is SMTP, 1782 is
Telnet. However, most of the above are either incorrect, obsolete or
both. See RFCs 963 and 964 for errors in 1777 and 1778. RFC 959
(the correct spec for FTP) and a number of Telnet Option RFCs
post-date 1780 and 1782. I don't know anything specific wrong with
1781, but you should refer to RFCs 821 and 822 anyway.
James B. VanBokkelen 2 High St., North Andover, MA 01845
FTP Software Inc. voice: (508) 685-4000 fax: (508) 794-4488
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jan 93 18:23:01 PDT From: chris@distinct.com (Chris Bologna) To: comp.protocols.tcp-ip Subject: A short course in TCP/IP
>> I need to attend a good TCP/IP course that would cover administration issues, >> network management, programming (RPC or some DCE maybe), etc. >> Thanks for any ideas! >> -Lee Thomas I know that the American Institute run hands-on training courses for TCP/IP - they run courses all over the country. I don't know what the level of the course is really at as I only know about it through their catalogue. You might want to call and find out. Tel: (800) 345-8016 Chris Bologna Distinct Corporation 14395 Saratoga Avenue, Suite 120 Saratoga, CA 95070 Tel: (408) 741-0781 Fax: (408) 741-0795 email: chris@distinct.com *******************************************************************************
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jan 1993 17:02:12 EST From: H. D. Knoble <HDK@psuvm.psu.edu> To: comp.protocols.tcp-ip Subject: Re: Help with CUTCP 2.2 TN/TC-D Telnet...
I cannot reproduce your problem with my version of TN3270 or TELBIN. I'm running on an old PS/2 55SX with 8M Ram using a Token Ring Card and drivers. I'm running under IBM DOS 5.0 (CSD UR36603 2/92), running from DOS prompt, or DOS Shell, or from Windows PIF. As of November 30, 1992 Clarkson U has updated the TN3270.EXE module (the OMNIGATE.CLARKSON.EDU file /pub/cutcp/v2.2-E/tn3270.exe ). This newer file is 112 bytes bigger than the previous one dated earlier last November. I doubt that this has anything do to with your problem as the older TN3270 also does not fail on my configuration.
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jan 93 12:20:12 GMT From: brunke@DKRZ-Hamburg.dbp.DE (Lutz Brunke) To: comp.protocols.tcp-ip Subject: Re: MORE ON TOOLS TO FIND ROUTING TABLES OF REM
ripquery is a program which comes with gated. But it does not show the routing table of a gateway, it only show which rip routes the gateway is advertising. Lutz --- ------------------------------------------------------------------------- Lutz Brunke Deutsches Klimarechenzentrum GmbH Tel.: +49-40-41173-329 Abteilung Kommunikation E-mail: brunke@dkrz-hamburg.dbp.de Bundesstr. 55, D-2000 Hamburg 13 -------------------------------------------------------------------------
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jan 93 18:04:18 EST From: SYAZDI@PK705VMA.VNET.IBM.COM To: comp.protocols.tcp-ip Subject: FTP Performance, FTP Performance information
Reply: SYAZDI@pk705vma.vnet.ibm.com I have been looking for information regarding FTP performance on different workstations and/or file servers? I have found 0 so far. Does anyone know/or have pointers to what "industry" performance levels are for different machines. Thanks in advance for any information. Sean Yazdi
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jan 1993 13:48:52 GMT From: hughes@logos.ucs.indiana.edu (larry hughes) To: comp.protocols.tcp-ip Subject: Re: PoP3 Daemon ftp site
> Does anyone know where I can find an FTP site for the PoP3
> daemon. I can find plenty for PoP2, no PoP3 alas.
I tried to reply in private, but the headers on your posting (and
your signature) didn't indicate an email address. I don't know
of European locations, but here are two U.S. locations:
Unix POP3 Daemon:
lilac.berkeley.edu
/pub/popper
VMS POP3 Daemon:
logos.ucs.indiana.edu
/pub/iupop3
//==================================================================\\
|| Larry J. Hughes, Jr. | hughes@indiana.edu ||
|| Indiana University | "The person who knows everything ||
|| University Computing Services | has a lot to learn." ||
\\===================================================================//
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jan 1993 14:02:38 GMT From: "Vladislav Akhmedov" <avg@gsrcc.msk.su> To: comp.unix.admin,comp.protocols.tcp-ip Subject: NE2000 multicard driver. HELP!
Hi folks,
I have got a small problem with my ISC UNIX System V r.3.2 version 3.0.
I try to set UNIX LAN with UNIX NFS server and several DOS NFS (PCNFS)
workstations. Some of this wks are connected to one NE2000 of the UNIX
server and other ones to second NE2000 on the UNIX server. OK! I have got
UNIX server with two NE2000 cards. But UNIX have not multipcard driver for
this adapter (only NE0 driver, no one NE1 or NE2 as Western Digital cards).
And file /etc/conf/pack.d/ne0/space.c has not structure declaration
struct neparam neparams[NNE] = {
...
}
I have got some ideas about files /usr/include/sys/ne2k*.h, but i'm not
sure, am i right or not.
If somebody knows anything of it, please tell me.
Thanks in advance.
Vladislav Akhmedov, Russia, Moscov.
E-mail: avg@gsrcc.msk.su
smm@gsrcc.msk.su
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jan 1993 15:24:57 GMT From: mpiet@is.morgan.com (Mark Pietrasanta) To: comp.protocols.tcp-ip Subject: Shareware TCP/IP, NFS
Has anyone out there used shareware TCP/IP and/or shareware NFS in
a production situation? I am interested in other peoples experiences
with this and would be interested in any and all comments. Please
respond by mail if possible.
Thanks,
Mark Pietrasanta - mpiet@is.morgan.com
* * * * * * * * *
"Great spirits have always encountered violent opposition from
mediocre minds." - Albert Einstein
----------------------------------------------------------------
Disclaimer: These responses are my own and in no way reflect the
views of my employer.
----------------------------------------------------------------
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jan 1993 15:37:58 GMT From: bwarner@mentor.cc.purdue.edu (Bill Warner) To: comp.protocols.tcp-ip Subject: Re: MORE ON TOOLS TO FIND ROUTING TABLES OF REMOTE HOSTS
In article <C0EtFo.FCq@exicom.OZ.AU> ray@exicom.OZ.AU (ray) writes: > >I was hoping that there would be a solution which only required >that the gateway in question be running some routing daemon >talking RIP (e.g. gated), which is a more common property of gateways >than SNMP . > Using only RIP may not give you all of the information you want. You can certainly send a RIP Request to a remote machine. But, the only information RIP will send back is a list of destinations for which that machine has routes, and the associated metrics. For example, it will not tell you what gateway the remote machine uses to reach the destination. Nor will you get any of the other information which netstat provides. Bill -- Bill Warner (317)494-1787 General Consulting bwarner@cc.purdue.edu Purdue University Computing Center bwarner@PURCCVM.BITNET
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jan 93 16:30:43 GMT From: maritza@espresso.bae.bellcore.com (Maritza Ramirez) To: comp.protocols.tcp-ip Subject: anonymous ftp
Is there any RFC or other kind of documentation that may describe how the "anonymous ftp" works ? Any pointers would be appreciated, Maritza
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 6 Jan 1993 17:34:51 GMT From: cliff@garnet.berkeley.edu (Cliff Frost) To: comp.protocols.tcp-ip Subject: Re: PoP3 Daemon ftp site
|> Unix POP3 Daemon: |> lilac.berkeley.edu |> /pub/popper This should read: |> Unix POP3 Daemon: |> ftp.cc.berkeley.edu |> /pub/popper Thanks, Cliff Frost UC Berkeley
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 6 Jan 1993 19:09:17 GMT From: haynes@cats.ucsc.edu (Jim Haynes) To: comp.sys.sun.apps,comp.protocols.tcp-ip Subject: Has anyone ported 'query' to SunOS?
'query' is a program that has been around for a while, supplied as a
tool for debugging the route daemon routed. It's available as part of
the Berkeley Net-2 code; but that version appears to be incompatible with
Suns because the differences in the way signal works. Has anybody done
the necessary work to port query?
--
haynes@cats.ucsc.edu
haynes@cats.bitnet
"Ya can talk all ya wanna, but it's dif'rent than it was!"
"No it aint! But ya gotta know the territory!"
Meredith Willson: "The Music Man"
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jan 1993 19:14:11 GMT From: burch@seas.smu.edu (Chris Burchett) To: comp.os.vxworks,comp.unix.bsd,comp.protocols.tcp-ip Subject: Help! (75 seconds to connect() after reboot)
Help! I've found a situation in which I'm unsure of the best solution. The problem has to do with a 75 second timeout in the connect() system call. This occurs after one of two previously connected machines is rebooted and an attempt is subsequently made to reestablish communication. I am using TCP/IP via Berkeley sockets to communicate between a Sun workstation and an embedded system running VxWorks. After communi- cation is established, the embedded system is rebooted. Once the reboot is finished an attempt is made to reestablish the connection, at which point, the connect() system call on the embedded system is unable to reconnect and times out after 75 seconds. I believe this may happen because the embedded system is using the same port number that was used for a connection before the reboot occured (while the remote machine still maintains an established connection on that port). It appears that (after a reboot) if the embedded system attempts to connect() using a port number which was not previously connected, the connection is immediately established; this is the desired behavior. However, if the embedded system uses a port which was previously connected, the connect() system call times out after 75 seconds. Unfortunately, in my application 75 seconds is somewhat too long to wait. I have a potential work around, but it seems to be sort of a kludge and I felt certain that this problem must be a known one with known solutions. (I'm relatively new to NEWS and if this is a topic which has already been discussed in depth or I have improperly used this service in any way, I appologize.) But if someone with insight into this problem would enlighten me on the issues involved, or documentation to be studied, or potential solutions, I would greatly appreciate the help. Chris Burchett email: burch@seas.smu.edu voice: (214) 205-8065
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 6 Jan 93 19:48:43 GMT From: dawkins@acsu.buffalo.edu (Desmond D. Dawkins) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Help with CUTCP 2.2 TN/TC-D Telnet...
I'm having a strange problem with CUTCP 2.2 TN/TC-D. (I'm not the primary user of this machine) Whenever the user exits from Telnet via logging out of the last session, ALT-X, or even ALT-F3, it hangs requiring a 'hot boot'. It never fails! ALT-E does work, however. As does DOS-shelling from other programs - (WordPerfect). I'm at a loss. The following is a list of things I've already tried: a. stripped everything from the AUTOEXEC.BAT and CONFIG.SYS b. reinstalled Telnet c. virus-checked the machine d. checked that COMSPEC was looking at the right COMMAND.COM This is the configuration: * 486/33 compatible with 4M RAM. * MS-DOS 5.0 * 3Com board 3c503 * version 7 for the packet driver - 3c503.COM * invocation - 3c503 -w 0x7e 0x3 0x310 * version 3.04 of the protocol - IPX304.COM I would appreciate all suggestions that you might have. I'm pretty much -- * SUNY/Buffalo, 221 Computing Center, Buffalo, NY 14261 USA 716-645-3983 * * e-mail: dawkins@acsu.buffalo.edu,dawkins@ubvms.bitnet * * "One often meets his destiny, down the road he takes to avoid it." *
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jan 1993 21:13:40 GMT From: garnett@refuge.Colorado.EDU (Santiago de la Paz) To: comp.protocols.tcp-ip Subject: Re: MORE ON TOOLS TO FIND ROUTING TABLES OF REM
brunke@DKRZ-Hamburg.dbp.DE writes:
>
>ripquery is a program which comes with gated. But it does not show
>the routing table of a gateway, it only show which rip routes the
>gateway is advertising.
>
Careful: ripquery is not to be trusted, precisely because it does *not*
truthfully show the routes that are being rip-advertised. ripquery operates
by generating a rip POLL, which explicitly asks the queried gateway to say
what its rip-list looks like. Unfortunately, most machines ignore
split-horizons when they respond to a rip POLL, so what you'll see is a
list of *all* the advertisements that gateway is making, regardless of whether
or not it will make them onto the network that you're querying over.
The only way to really make sure of what advertisements a gateway makes is
to sit and listen for them, e.g. with gated tracing turned on or some
handmade NIT utility.
~james
James Garnett, Network Engineer (303) 444-1338
garnett@cogwheel.com
Cogwheel Incorporated, Boulder *** Producers of low-cost dialup IP routers
Boulder-Denver/Hong Kong
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jan 1993 23:03:03 GMT From: matt@wardsgi.med.yale.edu (Matt Healy) To: comp.protocols.tcp-ip Subject: Re: anonymous ftp
In article <1993Jan6.163043.17410@walter.bellcore.com>, maritza@espresso.bae.bellcore.com (Maritza Ramirez) wrote: > > > Is there any RFC or other kind of documentation that may > describe how the "anonymous ftp" works ? > > Any pointers would be appreciated, > > Maritza There is a document by Tom Czarnik, called Anonymous FTP List - FAQ, which he posts regularly to a number of newsgroups: comp.archives.admin, comp.misc, comp.sources.wanted, alt.sources.wanted, & news.answers. It should answer your questions. Matt Healy "I pretend to be a network administrator; the lab net pretends to work!" matt@wardsgi.med.yale.edu
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 6 Jan 93 23:44:22 GMT From: hwajin@iphasew.com (Hwa-Jin Bae) To: comp.os.vxworks,comp.unix.bsd,comp.protocols.tcp-ip Subject: Re: Help! (75 seconds to connect() after reboot)
In article <1993Jan6.191411.4535@seas.smu.edu> burch@seas.smu.edu (Chris Burchett) writes: >Unfortunately, in my application 75 seconds is somewhat too long >to wait. in vxworks 5.0+, there is an undocumented call -- connectWithTimeout() which takes the same args as connect() plus extra last arg of type 'struct timeval *' which you may be able to use -- you can specify the delay of your own. or you could also just try non-blocking connect() -- set socket FIONBIO temporarily, call connect(), which should return EINPROGRESS immediately if connect attempt is to block -- when this happens you should select() for 'write'. the socket will be marked writeable once's it's connected. to verify the connection after select() returns with 'write' selected, you can do a getpeername(). this is actually what connectWithTimeout() does. [ i do hope this is still in vxworks, it was a few years back when i put this into the system ] hwajin
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: 7 Jan 93 08:05:44 CST From: shan@cray.com (Sharan Kalwani) To: comp.protocols.tcp-ip Subject: Re: A short course in TCP/IP
In article <1006.UUL1.3#20656@distinct.com> chris@distinct.com (Chris Bologna) writes: >>> I need to attend a good TCP/IP course that would cover administration issues, >>> network management, programming (RPC or some DCE maybe), etc. >>> Thanks for any ideas! >>> -Lee Thomas > >I know that the American Institute run hands-on training courses for TCP/IP - >they run courses all over the country. I don't know what the level of the >course is really at as I only know about it through their catalogue. You >might want to call and find out. Tel: (800) 345-8016 > >Chris Bologna you may also wish to contact InterOp. I don't have a phone number handy.... also the USENIX, LISA folks have TCP/IP courses too.... -- Sharan Kalwani, cri, 2000 town center suite 2350, southfield mi 48075 phone: (313) 576-3948 (313) 335-5580 internet: shan@cray.com uucp: ...!uunet!cray.com!shan
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jan 1993 11:24:31 GMT From: grunert@jupiter.rz.Uni-Osnabrueck.DE (Joerg Grunert) To: comp.protocols.tcp-ip Subject: TCP/IP with XINU
I want to use TCP/IP with the XINU system and a WD8003 Ethernet card.
If you have a source code in C please mail it to me.
It will help me also, when you mail me the Internetaddress of a FTP Server
where I can find the Programms.
Regards
grunert@jupiter.rz.uni-osnabrueck.de
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jan 1993 12:06:41 GMT From: kees@echelon.uucp (Kees Hendrikse) To: biz.sco.general,comp.protocols.tcp-ip Subject: Problem with SCO TCP/IP 1.2 and Kermit
When I use Kermit (3.11 or 3.12) to connect to a SCO/Unix system with
TCP/IP 1.2 installed, everything works fine, except for two annoying
details:
1) I can't send a DEL to interupt a process. If I hit the DEL key
(or ^C after 'stty intr ^C') a 'r' character is echoed.
2) If I hit ESC, the connection hangs.
We use the same setup we use when connecting to TCP/IP 1.1.3 systems
where we don't have this problem. Also, when telnetting from one SCO
TCP/IP 1.2 box to another, telnet just runs fine, including interpretation
of a DEL character.
Does anybody know what's wrong here?
--
Kees Hendrikse | email: kees@echelon.uucp
|
ECHELON consultancy and software development | phone: +31 (0)53 836 585
PO Box 545, 7500AM Enschede, The Netherlands | fax: +31 (0)53 337 415
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 7 Jan 1993 14:15:01 GMT From: julian@math.uni-muenster.de (Julian F. Reschke) To: comp.protocols.tcp-ip Subject: Help needed: receiving broadcasted UDP packages
Problem: I am trying to receive broadcasted UDP packages. I'm on SunOS 4.1.3, and use datagram sockets in the internet domain. The port number is 2010 (non- privileged), and the sender has it's socket configured to allow broadcasts. In fact, `etherfind' shows that the packets indeed are sent out. However, the receiver (using revcfrom) doesn't, listening on port 2010, doesn't get them. When I change to sender not to broadcast, but to send directly to the machine running the receiver, all works well. I've looked into SUN's `radio' sources, and all seems to by very similar. Any help appreciated... --- ________________ cut here _________________________ Julian F. Reschke, Hensenstr. 142, D-W4400 Muenster eMail: julian@math.uni-muenster.de, jr@ms.maus.de ________ correct me if I'm wrong __________________
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 7 Jan 93 14:18:46 GMT From: barnett@grymoire.crd.ge.com (Bruce Barnett) To: comp.protocols.tcp-ip Subject: Why would a Sun take 1.5 seconds to retransmit a missed packet?
I am examing some data collected from a medical network, and noticed some unusual timings. A Sun is transmitting large files (3.5Mbytes average) to an archive system while receiving images from a scanner. Packets are missed by the archive system, so the Sun has to retransmit the missed packets. I have noticed large delays (0.5 - 1.5 seconds) while the sending machine has to "back up" and retransmit packets that were previously sent but never acknowledged. 35% of the sessions had inter-packet delays > 1 second. The receiving buffer size is 24K. Why would there be such a long delay? I would expect the data is in mbufs, so the time to resent the missed packets should be small. From the timing it looks like the data was occasionally on a disk. If we wanted to remove these conditions, am I correct in assuming the sending system needs more RAM or perhaps more buffers? -- Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jan 1993 17:00:30 GMT From: larry@news.rn.com (Larry Snyder) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Netblazer
I currently attach via SLIP over a leased line using v.32bis/v.42bis modems from a Dell machine (on my end) into a smartport on a Telebit Netblazer. Would I see any significant increase in throughput using this same physical connection (v.32bis/v.42bis) but replacing the Dell SLIP with a Netblazer on my end -- and connecting my machines via ethernet to the Netblazer? I assume this would give me the ability to support PPP/CSLIP since my connection would be Netblazer-Netblazer -- what would PPP buy me over traditional SLIP (our feed is basically for smtp/nntp traffic, with ftps,telnets,rlogins used infrequently).. -- Larry Snyder internet: larry@gator.rn.com keeper of the Gator uucp: uunet!gator!larry
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 7 Jan 93 17:59:29 GMT From: G.J.Milne@daresbury.ac.uk (g.j.milne) To: comp.protocols.tcp-ip Subject: Re: ftp: subcommand error codes
In article 160@bjcong.bj.co.uk, maf@bjcong.bj.co.uk (AUSTIN FARR) writes:
>What is the meaning of the 3-digit numbers in messages relating to ftp (on AIX)
>subcommands? In particular, how is a failure signalled?
You should take a look at RFC959. As well as providing a description of
the FTP protocol it describes the reurn codes in a fair amount of
detail.
I have a feeling that there is an RFC that describes the return codes
only but I can't remember which one.
Ciao!
Gordon
_/_/_/ _/_/_/ _/_/_/ _/_/_/ Gordon J. Milne
_/ _/ _/ _/ _/ SERC Daresbury Laboratory, Warrington,
_/_/_/ _/_/_/ _/_/_/ _/ WA4 4AD.
_/ _/ _/ _/ _/
_/_/_/ _/_/_/ _/ _/ _/_/_/ e-mail: g.j.milne@dl.ac.uk
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jan 1993 18:05:23 GMT From: faivre@cst02.segin.com (Denis Faivre) To: comp.protocols.tcp-ip Subject: Re: PC-NFS SLIP and telnet problem
apollo@buengc.bu.edu (Doug A. Chan) writes: >What is wrong with telnet? Good question ! I also have trouble using PC-NFS Telnet... I recently upgraded my PC-NFS 2.0 to a newer 4.0 version. Unfortunately, I discovered that Telnet 4.0 is far slower than the older one. Some pointers in the news enabled me to get the 4.0a patch, but Telnet is still worse than before. The machine is a Dell 316SX with 4Mb of RAM, with a 3COM 3C501 Ethernet adapter. The hosts are Sun's (4/330, SunOs 4.1.1) and HP's (9000-800, HPUX 8.0). Note that the hardware did not change from 2.0 to 4.0 . Telnet is particularly slow when I'm using the vi editor and scrolling into a file (with the Ctrl-F "page forward" sequence) : sometimes I must wait several seconds (typically 2 or 3) before the screen is updated. With Telnet 2.0, the reaction was always immediate. Knowing that Telnet 4.0 is a brand new implementation, I tried to use the old one on 4.0 sublayers, but it didn't give good results. Did somebody experience the problem ? RTFM did not lead me to a solution. Denis.
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jan 1993 18:11:48 GMT From: liza@panix.com (Liza Gouger) To: comp.protocols.tcp-ip Subject: TCP/IP & SNA on IBM Lan adaptor card, availability of virtual term?
Hi, I'm posting this for a friend, Please reply to alen@crash.cts.com or post here (where he will look). Alen's request for information... I have a bunch of 486s running OS/2 connected via an IBM Token Ring (using a LAN Adaptor card in each). The main node in this net will be connected to a central machine (via ethernet and TCP/IP). I need to access terminal sessions on the central machine from any of the 486s. The central machine is likely to be a VAX w/VMS but may turn out (in some cases) to be an IBM connected via SNA (LU6.2 capable). Given these 2 scenarios, can anyone out there in NetLand advise me where to look for bridging software across the OS/2 (NetBios) -> TCP/IP VAX and across OS/2 (NetBios) -> SNA? What kind of hardware requirements are there? The main interest is in getting live terminal sessions from OS/2 PM windows on each PC node. There is some need for file and/or data transfer, so leaving these options open would be a plus. Thanks in advance --alen (trying to turn a Sparc into a Flame) alen@crash.cts.com
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jan 1993 18:13:56 GMT From: mlewis@telebit.com (Mark S. Lewis) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
> I currently attach via SLIP over a leased line using v.32bis/v.42bis > modems from a Dell machine (on my end) into a smartport on a Telebit Netblazer. > Would I see any significant increase in throughput using this same > physical connection (v.32bis/v.42bis) but replacing the Dell SLIP > with a Netblazer on my end -- and connecting my machines via ethernet > to the Netblazer? > I assume this would give me the ability to support PPP/CSLIP since > my connection would be Netblazer-Netblazer -- what would PPP buy me > over traditional SLIP (our feed is basically for smtp/nntp traffic, > with ftps,telnets,rlogins used infrequently).. > -- > Larry Snyder internet: larry@gator.rn.com > keeper of the Gator uucp: uunet!gator!larry No I don't think you would get a significant performance increase by putting a NetBlazer at both ends. You are using relatively slow serial lines limited by V.32bis modulation with whatever compression you get with V.42bis. You would get significant performance increase for telnet sessions using TCP header compression. This won't help UDP traffic of course. This compression can be used with SLIP (CSLIP) or PPP. Many PPP implementations include header compression. The main benefits of PPP are dynamic configurability and the ability to run multiple protocols. PPP negotiates things like header compression, MRU/MTU size while trying to bring the link up. With SLIP all this must be statically configured ahead of time. PPP has specifications for protocols other than IP. People run IPX, AppleTalk, XNS, Decnet, OSI, and bridging over PPP links. SLIP is only useful for IP. ... Mark =========----------- Mark S. Lewis -----------========== inet: mlewis@telebit.com Telebit Corp. Telebit (408) 745-3232 uucp: uunet!telebit!mlewis Fax (408) 745-3810
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jan 93 19:21:57 GMT From: larry@eco.twg.com (Lawrence B. Henry III) To: comp.unix.aix,comp.unix.questions,comp.protocols.tcp-ip Subject: Re: ftp: subcommand error codes
In article <160@bjcong.bj.co.uk>, maf@bjcong.bj.co.uk (AUSTIN FARR) writes:
|>
|>ftp on AIX: subcommand errors
|>-----------------------------
|>
|>What is the meaning of the 3-digit numbers in messages relating to ftp (on AIX)
|>subcommands? In particular, how is a failure signalled?
|>
|>The following is an extract from an ftp dialogue:
|>ftp> get absent
|>200 PORT command successful
|>550 absent: No such file or directory
|>ftp> cd tmp
|>250 CWD command successful
|>
|>The leading 3-digit numbers in messages from ftp appear to relate to
|>interactions with the remote machine. A number beginning with '5' appears to
|>signify failure of the operation. If the last message before the 'ftp>' prompt begins with a digit other than '5' - is this a sufficient test for successful
|>completion of the last subcommand?
|>
|>I would be grateful for further information. Please reply by email.
|>Thank you.
|>
Austin,
Check out rfc640.. I believe that this is the latest source of
information on this topic.. it is readily available from nic.ddn.mil in the
RFC sub-directory..
-Larry.
---Excerpt from RFC640 showing response codes for FTP---
There are four values for the first digit of the reply code: 11a
1yz Positive Preliminary reply 11b
The requested action is being initiated; expect another
reply before proceeding with a new command. (The
user-process sending another command before the completion
reply would be in violation of protocol; but server-FTP
processes should queue any commands that arrive while a
preceeding command is in progress.) This type of reply can
be used to indicate that the command was accepted and the
user-process may now pay attention to the data connections,
for implementations where simultaneous monitoring is
difficult. 11b1
2yz Positive Completion reply 11c
The requested action has been successfully completed. A
new request may be initiated. 11c1
3yz Positive Intermediate reply 11d
The command has been accepted, but the requested action is
being held in abeyance, pending receipt of further
information. The user should send another command
specifying this information. This reply is used in command
sequence groups. 11d1
4yz Transient Negative Completion reply 11e
The command was not accepted and the requested action did
not take place, but the error condition is temporary and
the action may be requested again. The user should return
to the beginning of the command sequence, if any. It is
difficult to assign a meaning to "transient", particularly
when two distinct sites (Server and User-processes) have to
agree on the interpretation. Each reply in the 4yz
category might have a slightly different time value, but
the intent is that the user-process is encouraged to try
again. A rule of thumb in determining if a reply fits into
the 4yz or the 5yz (Permanent Negative) category is that
replies are 4yz if the commands can be repeated without any
change in command form or in properties of the User or
Server (e.g. the command is spelled the same with the same
NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843
Neigus FTP Reply Codes [5]
arguments used; the user does not change his file access or
user name; the server does not put up a new
implementation.) 11e1
5yz Permanent Negative Completion reply 11f
The command was not accepted and the requested action did
not take place. The User-process is discouraged from
repeating the exact request (in the same sequence). Even
some "permanent" error conditions can be corrected, so the
human user may want to direct his User-process to
reinitiate the command sequence by direct action at some
point in the future (e.g. after the spelling has been
changed, or the user has altered his directory status.) 11f1
The following function groupings are encoded in the second
digit: 11g
x0z Syntax - These replies refer to syntax errors,
syntactically correct commands that don't fit any
functional category, unimplemented or superfluous
commands. 11g1
x1z Information - These are replies to requests for
information, such as status or help. 11g2
x2z Connections - Replies referring to the TELNET and
data connections. 11g3
x3z Authentication and accounting - Replies for the logon
process and accounting procedures. 11g4
x4z Unspecified as yet 11g5
x5z File system - These replies indicate the status of
the Server file system vis-a-vis the requested
transfer or other file system action. 11g6
The third digit gives a finer gradation of meaning in each of
the function categories, specified by the second digit. The
list of replies below will illustrate this. Note that the
text associated with each reply is suggestive, rather than
mandatory, and may even change according to the command with
which it is associated. The reply codes, on the other hand,
should strictly follow the specifications in the last section;
that is, Server implementations should not invent new codes
for situations that are only slightly different from the ones
described here, but rather should adapt codes already defined.
NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843
Neigus FTP Reply Codes [6]
If additional codes are found to be necessary, the details
should be submitted to the FTP committee, through Jon Postel. 11h
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jan 1993 19:34:48 GMT From: fredh@bohr.logiconultra.com (Fred Hronicek) To: comp.protocols.tcp-ip Subject: TCP/IP Software for VAX 8700
Does anyone know of what TCP/IP software is available for the VAX 8700? (Vendor name, approximate cost, etc) Shareware would be nice. Fred Hronicek Logicon Ultrasystems, Inc. 310/643-5111
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jan 1993 20:10:08 GMT From: ben@csi.compuserve.com (Benny Jones) To: comp.protocols.tcp-ip Subject: TCP/IP for Tops-10
Back in the medieval days of computing, did TCP/IP ever run on a TOPS-10 system? I'd be very interested in knowing who did it or any names of individuals that I might contact with questions about the implementation. Thanks loads. -- Benny Jones 614-457-8600 CompuServe 70003,1153 Internet ben@csi.compuserve.com hjones@magnus.acs.ohio-state.edu
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 7 Jan 93 20:34:04 GMT From: lstowell@pyrnova.mis.pyramid.com (Lon Stowell) To: comp.protocols.tcp-ip Subject: Re: Why would a Sun take 1.5 seconds to retransmit a missed packet?
In article <BARNETT.93Jan7091846@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes: >I am examing some data collected from a medical network, and noticed >some unusual timings. > >A Sun is transmitting large files (3.5Mbytes average) to an archive >system while receiving images from a scanner. Transmitting using what protocol? FTP, NFS copy or what? > >Packets are missed by the archive system, so the Sun has to retransmit >the missed packets. I have noticed large delays (0.5 - 1.5 seconds) Those are pretty typical numbers for TCP layer time-outs... > >Why would there be such a long delay? I would expect the data is in >mbufs, so the time to resent the missed packets should be small. >From the timing it looks like the data was occasionally on a disk. >If we wanted to remove these conditions, am I correct in assuming the >sending system needs more RAM or perhaps more buffers? If this is FTP, you'd probably be better off getting rid of the fatal collisions on the net.....unless you can set the time-outs to a very small number (very dangerous, but....)
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jan 1993 20:45:11 GMT From: larry@news.rn.com (Larry Snyder) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip,comp.unix.sysv386 Subject: SLIP connections and ifconfig/netstat/route problems
my netstat -rn shows (after a re-boot): Destination Gateway Flags Refcnt Use Interface 127.0.0.1 127.0.0.1 UH 0 0 lo0 192.207.21.3 192.207.21.3 UH 0 0 sl0 192.207.21.3 192.207.21.3 UH 0 0 sl0 default 192.207.21.3 UG 5 1366 sl0 192.190.77 192.190.77.1 U 0 0 eth0 I bring the machine up with: cp /etc/inet/resolv.conf.orig /etc/inet/resolv.conf /usr/sbin/slipattach /dev/term/b01s 192.207.21.195 netblazer-ip 38400 /usr/sbin/ifconfig "sl0" gator netblazer-ip netmask 255.255.255.0 up cp /etc/inet/resolv.conf.conf /etc/inet/resolv.conf /usr/sbin/in.named /usr/sbin/route add default netblazer-ip 1 Now, if I don't add the above ifconfig line, route fails with "network is unreachable" on the above route command. I need to add the ifconfig line in order for the route add default.... to take effect. Any ideas why I need to specify another ifconfig (besides the default that comes up enabled with slip)? larry -- Larry Snyder internet: larry@gator.rn.com keeper of the Gator uucp: uunet!gator!larry
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 7 Jan 93 22:46:37 GMT From: merce@xenitec.on.ca (Jim Mercer) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
In article <C0I42H.23D@news.rn.com> larry@news.rn.com (Larry Snyder) writes: >Since the serial ports in the netblazer are on the motherboard, is it >possible to disable them and add a stock 2 port serial board with >16550A chips and will the NB take advantage of the FIDO buffers in >the chips? > >Can the NB support 2 56700 baud modems going full blast on the >stock 2 serial ports on the motherboard? try pulling the case off and seeing of the UARTs are 16550's. i would suspect so. -- [ Jim Mercer Reptilian Research merce@iguana.reptiles.org +1 416-506-0654 ] [ longer life through colder blood ]
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jan 93 23:11:46 GMT From: maritza@espresso.bae.bellcore.com (Maritza Ramirez) To: comp.protocols.tcp-ip Subject: tftp for MVS
Is there available on the internet a C ported version of the TFTP protocol for the MVS mainframes ? Thanks, Maritza
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jan 1993 00:22:57 GMT From: larry@news.rn.com (Larry Snyder) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
merce@xenitec.on.ca (Jim Mercer) writes: >>Can the NB support 2 56700 baud modems going full blast on the >>stock 2 serial ports on the motherboard? >try pulling the case off and seeing of the UARTs are 16550's. >i would suspect so. but does their code use the FIFO in the 550A if installed in a slot? -- Larry Snyder internet: larry@gator.use.com keeper of the Gator uucp: uunet!gator!larry
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 93 00:26:33 GMT From: black@ll.mit.edu (Jerry Glomph Black) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Packet Driver or PCROUTE on PC-synch card NEEDED!
I need to upgrade my Slip service to operate on a 56kB leased DDS line, for which my CSU/DSU operates synchronously. Is there a PCROute driver, or a packet driver, which can talk to a PC card which does synchronous serial? email to black@LL.MIT.EDU Thanks!
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jan 1993 00:37:08 GMT From: bhays@teal.csn.org (Boyd Hays) To: comp.sys.sun.admin,comp.protocols.tcp-ip Subject: SLIP on a SUN?
Hello,
I need to put SLIP up on a SUN IPC running 4.1.2. Is there a general
concensus as to which version is "best". I'm anticipating putting up
cslip-2.6. Is this good, bad, or indifferent. Also, I keep reading in
most documents associated with the various SLIP verions not to have
a getty on the serial line. I'm confused. What I want to do is:
1) Hang a getty on the receiving modem's port.
2) Make the connection over a phone line.
3) Login to a account that runs sliplogin or the equivalent.
(I don't have sanction to run slattach on the host machine)
Is this the general process? Is there a FAQ for SLIP installations?
The best thing I've found so far is the O'Rielly TCP/IP Administration
book's description. Are there any other "standard" references?
Thanks in advance,
Boyd Hays
bhays@csn.org
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jan 1993 02:26:41 GMT From: hak@alf.cooper.edu (Jeff Hakner) To: comp.protocols.tcp-ip Subject: Re: STARLAN 10 10BASE-T hub unit doesn't like adapters
in article <Jan.4.19.20.49.1993.958@ocean.rutgers.edu>, jimg@ocean.rutgers.edu (Jim Gasprich) says: > > I have two somewhat old (circa 1988) STARLAN 10 hub units that > are part of our TCP/IP ethernet LAN. Our lab is wired twisted pair > with RJ-45 plugs. This is fine for our PCs with their RJ-45 port > cards, but for our UNIX boxes (Suns), we need to use AUI to RJ-45 > adapter boxes. > > Here's the problem. We recently bought a new (1991) adapter box from > Cabletron, but it did not work when we wired it up. We have a few > old adapters from AT&T (which came with our now defunct 3B2s (ick!)), > and some others from a company called David Systems, which work A-OK. > > I am somewhat perplexed. Has there been a change in the 802.3 standard, > are our hub units no longer usuable, or am I just missing something > somewhere ?? It would seem a shame to throw out 22 usuable ports, > especially with the price of some of the new fancy-pants hubs I've > been looking at. > > I apologize if these are newbie questions, or are more appropriate to > another, more wire-head hardware group. > > Thanks, > > Jim Gasprich e-mail: jimg@ocean.rutgers.edu > Research & Support Slave tel: (908) 932-9631 > Cook College Remote Sensing Center fax: (908) 932-8644 > Dept of Natural Resources > Rutgers University > New Brunswick, NJ, O8903 "Du bist mein Gweckman" - Anonymous Fascist I've had a similar problem. When I used the Allied Telesis thick-10BASE-T adapter and plucked the twisted pair into an AT&T STARLAN 10 hub, the whole network starting dying with heavy collisions (and no traffic!). WHen I replaced the hub with an Allied hub (more modern), no problems. I thought STARLAN10 was supposed to be compatible with 10-BASE-T, but perhaps there are some subtel differences which prevent this interoperation? --Jeff Hakner Asst. Dir. Telecommunications Cooper Union NYC
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: Fri, 08 Jan 93 03:48:26 GMT From: nelson@crynwr.com (Russell Nelson) To: comp.protocols.tcp-ip Subject: Packet Driver or PCROUTE on PC-synch card NEEDED!
In article <1993Jan8.002633.24525@ll.mit.edu> black@ll.mit.edu writes: I need to upgrade my Slip service to operate on a 56kB leased DDS line, for which my CSU/DSU operates synchronously. Is there a PCROute driver, or a packet driver, which can talk to a PC card which does synchronous serial? Ask Niwot Networks. They sell ISA sync cards that have packet drivers. They're at 303-444-7765. -russ <nelson@crynwr.com> What canst *thou* say? Crynwr Software Crynwr Software sells packet driver support. 11 Grant St. 315-268-1925 Voice | LPF member - ask me about Potsdam, NY 13676 315-268-9201 FAX | the harm software patents do.
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jan 1993 06:11:02 GMT From: lin@tasman.cc.utas.edu.au () To: comp.protocols.tcp-ip Subject: How to network printers?
Hi netlanders, I don't know whether this is right place to ask this question. But, anyway,... Our group has more than 10 PCs, one Dataproducts LZR-1260 b/w laser printer, one HP Deskjet 500C color printer and one HP Scanjet IIp b/w scaner. At moment, the printers and scanner are not networked, even though our PCs are networked through ethnet to a Unix server. We now want our printers and scanner to be networked as well. What do we need? Hardware, software? Someone mentioned FASTPORT (TCP/IP network print server) by MiLAN Technology should be OK for our purpose. Is that right? Any other options? Your help would be greatly appreciated. Please send responses to my account since I don't read this newsgroup very often. I will post a summary if there are enough responses and interests. Thanks in advance. --Tony Lim Internet: lin@tasman.utas.edu.au zzl@bom.gov.au
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 93 06:38:15 GMT From: merce@xenitec.on.ca (Jim Mercer) To: comp.unix.sys5.r4,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
In article <C0IEE9.M4I@news.rn.com> larry@news.rn.com (Larry Snyder) writes: >merce@xenitec.on.ca (Jim Mercer) writes: > >>>Can the NB support 2 56700 baud modems going full blast on the >>>stock 2 serial ports on the motherboard? >>try pulling the case off and seeing of the UARTs are 16550's. >>i would suspect so. > >but does their code use the FIFO in the 550A if installed in a slot? ka9q has had support for the 550 for some time. i once asked Phil Karn if the rumor was true that the Netblazer kernel was based on ka9q. his responded something like "a much mutated version". if the motherboard has 550's on it, it would be rediculous(sp?) for telebit not to support them, especialy if the support was in the base code. 8^) -- [ Jim Mercer Reptilian Research merce@iguana.reptiles.org +1 416-506-0654 ] [ longer life through colder blood ]
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: Fri, 08 Jan 1993 12:48:46 From: jbvb@vax.ftp.com (James B. VanBokkelen) To: comp.protocols.tcp-ip Subject: Re: Why would a Sun take 1.5 seconds to retransmit a missed packet?
In article <184841@pyramid.pyramid.com> lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:
In article <BARNETT.93Jan7091846@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes:
>Packets are missed by the archive system, so the Sun has to retransmit
>the missed packets. I have noticed large delays (0.5 - 1.5 seconds)
Those are pretty typical numbers for TCP layer time-outs...
If so, it indicates that 1) the path is long, 2) the archive system is very
slow or 3) the sending TCP has an inferior or broken adaptive retransmit
algorithm. TCP should retransmit in something on the order of twice the
average Round Trip Time (from send to ack). Some implementations use exactly
2X, others combine the RTT and its standard deviation. With the TCP in PC/TCP
for DOS on a local LAN, the retransmit timeout is typically near its floor of
166 Ms, and I don't see any significant number of unwarranted retransmits.
James B. VanBokkelen 2 High St., North Andover, MA 01845
FTP Software Inc. voice: (508) 685-4000 fax: (508) 794-4488
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jan 1993 08:16:44 GMT From: tbooth@netcom.com (Todd Booth) To: comp.dcom.cell-relay,comp.dcom.lans.novell,comp.protocols.tcp-ip Subject: RESULT: comp.dcom.sys.wellfleet pass 122:14
Happy new year!
At the end of the voting period (midnight GMT, Tuesday, January 5th,
1993), 136 people had sent in their ballots in response to the CFV.
First let me say that this message has been posted to:
news.announce.newgroups
comp.dcom.lans.ethernet
comp.dcom.lans.fddi
comp.dcom.lans.misc
comp.dcom.lans
comp.dcom.cell-relay
comp.dcom.lans.novell
Wellfleet email distribution list (wellfleet-l@nstn.ns.ca)
The mailing list will remain, and those who prefer to receive by
mail, can continue to do so.
Here are the results:
Summary of vote tally:
yes: 122
no: 14
total: 136
Vote test 1: There were over 100 more valid yes votes than no.
Vote test 2: There were over 2/3 of the total (136) in favor.
There will be a five day waiting period during which the net
will have a chance to correct any errors in the voter list or
the voting procedure.
After the waiting period and if there were no serious objections
that might invalidate the vote, the newgroup will be created.
--todd booth
Wellfleet Communications, Inc. ; 310 445-8840
Systems Engineer in Los Angeles today
Stockholm next month (still with WF, still tbooth@wellfleet.com)
********
email addresses for those in favor of comp.dcom.sys.wellfleet:
Vote: From:
yes A.AGNEW@qut.edu.au
yes stortek!Aaron_Dailey@csn.org (Aaron Dailey)
yes "Alain FONTAINE (Post master - UCL)" <fontaine@sri.ucl.ac.be>
yes nothaft@nas.nasa.gov (Alfred E. Nothaft)
yes Andries Ruiter <RUITER@RC.RUG.NL>
yes Andy Linton <Andy.Linton@comp.vuw.ac.nz>
yes Andy Malis <malis@BBN.COM>
yes Armand Giraud <agiraud@itb1s1.grenoble.hp.com>
yes Arne Langmo <Arne.Langmo@runit.sintef.no>
yes art@brick.purchase.edu (Art Weisenseel)
yes ashah@eos.ncsu.edu
yes B.J. 10-Dec-1992 1357 <herbison@erlang.enet.dec.com>
yes b.watson%uws.edu.au@tscc.macarthur.uws.EDU.AU
yes Barry Lynam <LYNAM@qut.edu.au>
yes rlfink@net.lbl.gov (Bob Fink)
yes rhott%galaxy@relay.nswc.navy.mil (Bob Hott - K31)
yes cdperry@attmail.com
yes ccganzhorn@mmm.com ("Charles Ganzhorn")
yes chinson@CS.UCLA.EDU
yes mack23@avalon.eecs.nwu.edu (Chris Walsh)
yes claude@banana.dis.fedex.com (claude bowie)
yes Colin Cooper <colin@udcf.gla.ac.uk>
yes abbott@MicroUnity.com (Curtis Abbott)
yes D.REES@qut.edu.au
yes "D.W.Stevenson" <craa85@computer-centre-sun.strathclyde.ac.uk>
yes dan@lannet.com (Dan Romascanu)
yes carr@acsu.buffalo.edu (Dave Carr)
yes Dave Geurs <dgeurs@mot.com>
yes Dave Pokorney <POKE@nervm.nerdc.ufl.edu>
yes David Kuzminski <kuzminsk@cs.unc.edu>
yes levine@berlioz.nsc.com (David LeVine)
yes dcarros@rcsuna.gmr.com (Donald Carros )
yes Don_Jarmon@ingr.com
yes "Ekkehard Lang" <A2824AA@lrz1.lrz-muenchen.de>
yes Eric Hunt <bsc835!ehunt@uunet.UU.NET>
yes Evan Gamblin <0001847804@mcimail.com>
yes emss!geboykin@uunet.UU.NET (G. E. Boykin x5522 )
yes Gary Kunis <gkunis@cisco.com>
yes skaggs@nsslsun.nssl.uoknor.edu (Gary Skaggs)
yes Gavin Stone-Tolcher <ccgavin@cc.uq.oz.au>
yes gordonr@nms.otca.oz.au (Gordon Rowell)
yes Greg Sawyers <g.sawyers@trl.oz.au>
yes Hampton Watkins <hwatkins@BBN.COM>
yes hand@tbird.cc.bellcore.com (hand,james c)
yes Hiroyasu Murakoshi <mrks@edp.tis.toshiba.co.jp>
yes HJOLLO@BG.HBG.HYDRO.NO
yes takumi@ai03.ics.nitech.ac.jp (Ichi Takumi)
yes Jack Allen Underwood <Jack.A.Underwood@med.umich.edu>
yes Jason R. Pascucci <jasonp@primerd.prime.com>
yes barnes@xylogics.com (Jim Barnes)
yes Jim O'Shea <jwo@hpuerca.atl.hp.com>
yes jim@unirsvl.RSVL.UNISYS.COM
yes John Burgess <jtb@garage.att.com>
yes John Curran <jcurran@nic.near.net>
yes lekash@nas.nasa.gov (John Lekashman)
yes jmills@cass.ma02.bull.com (John Luke Mills)
yes jsblau@panix.com (Jonathan Blau)
yes jude@wk87.nas.nasa.gov (Jude George)
yes Katy Kislitzin <ktk@nas.nasa.gov>
yes Ken Hays <hays@dirac.scri.fsu.edu>
yes Ken Tobias <ktobias@amgen.com>
yes kent@unlinfo.unl.edu (kent eitzmann )
yes smiles@NMC.ED.RAY.COM (Kevin Ruddy)
yes Kirk Olsen <kgo@sununix.comm.wang.com>
yes Larry Rebarchik <lrebarch@us.oracle.com>
yes infmise@grds01.deinf.abb.com (M.Scheurer)
yes marcel@irdeto.nl (Marcel Koelewijn)
yes Marciano Pitargue <pitargue@cisco.com>
yes "Marian Gawel, ESC Data Network Operations" <gawel@bb.dec.com>
yes Mark Garrett <mark@arvak.une.edu.au>
yes "Mark I. Williams" <M.Williams@cc.uq.oz.au>
yes mast@maldata.se (Martin Stromberg)
yes mborden@wellfleet.com (Marty Borden)
yes matsuo@mars.elcom.nitech.ac.jp
yes mmt@RedBrick.COM (Maxime Taksar KC6ZPS)
yes Michael A Wojcik <woj@ll.mit.edu>
yes Michael Quinn <MJQUINN@pucc.Princeton.EDU>
yes "Michael S. McMahon" <MCMAHON@unocdc.unomaha.edu>
yes mgh@sunbim.be (Michel Hendrick)
yes "Michelle R. Koblas" <Michelle.Koblas@itek.norut.no>
yes mac@critter.Prime.COM (Mike Croke x5386 )
yes Mike Scott <mjtt@tonto.cc.rochester.edu>
yes mike@Cadence.COM (Mike Tucker)
yes mustang@iastate.edu
yes nick@beethoven.wellfleet.com (Nicholas Jacobs)
yes bg54305@bgsau3.hbg.hydro.no (Ola Hjollo)
yes Patrick Herlihy <P.Herlihy@ccsd.uts.EDU.AU>
yes pwk@telecomm2.iss.bnr.com (Paul Killion)
yes schow@sun1.InterLan.COM (Peter Schow)
yes PETER@zeus.ed.ray.com
yes proyse@peeras.demon.co.uk (Phil Royse)
yes ptrubey (Phil Trubey)
yes Philippe Debroux <Debroux@sri.ucl.ac.be>
yes Philippe Francq <Francq@sri.ucl.ac.be>
yes michel@thomson-lcr.fr (Philippe Michel)
yes pm@sunbim.be (Philippe Moitroux)
yes pstevens@BBN.COM
yes rjmeye1@afterlife.ncsc.mil (Randy Meyers)
yes rfranken@cs.umr.edu
yes Ritu Bansal <rbansal@cc3.bbn.com>
yes rcraig@cisco.com (Robert Craig)
yes "Robert S. Logan" <BOB@ROMEO.CALTECH.EDU>
yes sameer@atlastele.com
yes scod@ewi.ch (Schorr Daniel)
yes scott@Nova.TCS.Tufts.EDU
yes simha@lannet.com (Simha Karlin)
yes Stephen Sakamoto <steph@CS.UCLA.EDU>
yes sbauer@silver.sdsmt.edu (Steve Bauer)
yes Steve Elias <eli@cisco.com>
yes "Steven Lendt - UNOnet Manager" <SLENDT@unocdc.unomaha.edu>
yes Terry Gong <thg@hprnd.rose.hp.com>
yes thomasb%kestrel.AUSTIN.LOCKHEED.COM@AUSTIN.LOCKHEED.COM (Thomas Benjamin)
yes a2824ak@sunmanager.lrz-muenchen.de (Thomas Kaiser)
yes Tim Pletcher <Timothy.A.Pletcher@med.umich.edu>
yes Todd Booth <tbooth@wellfleet.com>
yes tj@CS.UCLA.EDU (Tom Johnson)
yes Tony Knaus <awk@antlia.ece.cmu.edu>
yes trall@almaden.ibm.com
yes T elogy.Networks@uu2.psi.com, Inc. <billw@telogy.com>
yes Val Freda <rxtvf@possum.ecg.rmit.edu.au>
yes Vesa Halkka <vhalkka@cc.helsinki.fi>
yes cire "ya mon" eric <cire@cisco.com>
********
email addresses for those against comp.dcom.sys.wellfleet:
Vote: From:
no Adrian Miranda <ade@vancouver.wsu.edu>
no Charles Shub <cdash@moet.cs.colorado.edu>
no mcp@netcom.com (Craig Presnell)
no emcguire@intellection.com (Ed McGuire)
no grima@iphase.com (Gary Rima)
no gator@vnet.ibm.com
no ggw@wolves.Durham.NC.US (Gregory G. Woodbury)
no gulik@motcid.rtsg.mot.com (Gregory Gulik)
no Marc Moorcroft <smarry@zooid.guild.org>
no pseudo!mjn@uunet.UU.NET (Murray Nesbitt)
no rens@lorax.shearson.com (Rens Troost)
no rick@crick.ssctr.bcm.tmc.edu (Richard H. Miller)
no "Roy Engehausen" <enge@almaden.ibm.com>
no tom_limoncelli@Warren.MENTORG.COM
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jan 1993 13:06:54 GMT From: dedgar@mta.ca To: comp.protocols.tcp-ip Subject: FTP ABOR vs data channel reset?
Hello Net
I would value information on ways to abort or terminate an FTP sessions
data channel. According to the spec the suggested (required?) way is to
issue an ABOR command on the control channel. However I haven't yet found
any type of machine that takes any notice of this. They all seem to finsh
the transmission and then say something like ABOR command successful.
Obviously this is kinda pointless - or am I just doing it wrong some how.
The other method is to reset the data channel. This works just fine but some
machines (SRV? unix) also shut the control channel (hence logging you out) at
the same time. This is kinda annoying.
So can anybody tell me if they have observed this as well - ( my software is
home grown so I can't really be too sure it isn't my fault). Any suggestions on
alternate methods?, anyone know of any catastrophic problems with the reset
method (besides the one mentioned?).
All info appreciated.
Dale Edgar
Cybernetic Control Inc.
DEDGAR@MTA.CA
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jan 1993 13:47:02 GMT From: karl@ddsw1.mcs.com (Karl Denninger) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
In article <1993Jan07.224637.4538@xenitec.on.ca> merce@xenitec.on.ca (Jim Mercer) writes: >In article <C0I42H.23D@news.rn.com> larry@news.rn.com (Larry Snyder) writes: >>Since the serial ports in the netblazer are on the motherboard, is it >>possible to disable them and add a stock 2 port serial board with >>16550A chips and will the NB take advantage of the FIDO buffers in >>the chips? >> >>Can the NB support 2 56700 baud modems going full blast on the >>stock 2 serial ports on the motherboard? > >try pulling the case off and seeing of the UARTs are 16550's. > >i would suspect so. They certainly are. (I have examined lots of these) They wouldn't work at that speed if they weren't. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Data Line: [+1 312 248-0900]
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 93 14:23:23 GMT From: jh@cadre.com (Joe Hartley) To: comp.sys.sun.admin,comp.protocols.tcp-ip Subject: Re: SLIP on a SUN?
In article EAC@csn.org, bhays@teal.csn.org (Boyd Hays) writes: >Hello, > I need to put SLIP up on a SUN IPC running 4.1.2. Is there a general > concensus as to which version is "best". I'm anticipating putting up > cslip-2.6. I'm currently looking at setting up a SLIP connection as well. I got a version of cslip off the net, although it was not the latest version. It had almost nothing in the way of documentation, and I didn't get it to install properly. I then tried a copy of MorningStar's PPP with cslip that we had in-house. It installed fairly easily, and seems to work fine. I'm going to get the new cslip today, but if it's as cryptic as the old one, MorningStar's going to have a new customer. --- =============================================================================== Joe Hartley | jh@cadre.com - Whenever you find that you are on the Cadre Technologies | side of the majority, it is time to reform. - M. Twain 222 Richmond St. | -------------------------------------------------------- Providence, RI 02903 | Overman 1st Class - the Kilgore Trout Memorial Clench (401) 351-5950 x266 | of the Church of the SubGenius ===============================================================================
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jan 1993 15:43:32 GMT From: larry@news.rn.com (Larry Snyder) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
karl@ddsw1.mcs.com (Karl Denninger) writes: >>>Can the NB support 2 56700 baud modems going full blast on the >>>stock 2 serial ports on the motherboard? >> >>try pulling the case off and seeing of the UARTs are 16550's. >> >>i would suspect so. >They certainly are. (I have examined lots of these) So one can assume they support the FIFO to get those speeds. My next question is do you have to enable a specific protocol -- ie: Can I start talking to the NB with SLIP using VJ compression and will it start using VJ - likewise, can I connect using PPP and will the netblazer be smart enough to change? -- Larry Snyder internet: larry@gator.use.com keeper of the Gator uucp: uunet!gator!larry
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jan 1993 15:46:18 GMT From: larry@news.rn.com (Larry Snyder) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
Would VJ compression with SLIP be benificial even if you have hardware compression (v.42bis?). If so, how much? Just wondering -- -- Larry Snyder internet: larry@gator.use.com keeper of the Gator uucp: uunet!gator!larry
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 93 15:50:33 GMT From: sailesh@litsun.epfl.ch (Sailesh Chutani) To: comp.protocols.tcp-ip Subject: question - performance and fault management in networks
Greetings I am trying to identify the problems that are considered to be the key problems in the area of Network Management, going beyond those solved by CMIP, DME, and SNMP etc. In particular I am focusing attention on fault and performance management issues at the transport layer. I would like to hear from people who are working in the related areas or have some experience and/or ideas on the topic that they would like to share. The problems of interest for example, could be related to : - abstractions used to describe the system - protocol design, specification, and validation techniques - modelling and statistical techniques - framework for dealing with incomplete and erroneous information on problems - gathering and analyis of problem related data - automation of detection and recovery - design of suitable interfaces to aid discovery, diagnosis and recovery I would prefer any feedback via e-mail. I shall post a summary of the information thus collected. Thanks for your help. -Sailesh
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 93 15:57:32 GMT From: davidsen@ariel.crd.GE.COM (william E Davidsen) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
In article <C0I42H.23D@news.rn.com>, larry@news.rn.com (Larry Snyder) writes:
| Can the NB support 2 56700 baud modems going full blast on the
| stock 2 serial ports on the motherboard?
Answer 1: probably, if they're com1 and com2
Answer 2: who cares, use SAS
I have a copy of SAS I got from Dell, and a copy of ESIX ppp I'm going
to try this weekend. I'll let you know how they work!
--
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
Keyboard controller has been disabled, press F1 to continue.
-----------[000087][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jan 1993 16:22:43 GMT From: fisher@tinton.ccur.com (Greg Fisher) To: comp.protocols.tcp-ip Subject: Trivial Telnet?
I was working with a unix kernel the other day whose TCP protocol was "sick", so I could not telnet or ftp to the system. But udp & ip were fine; ping and tftp had no problems. So I just wondered if anyone knows of a telnet-like thing which uses udp (or even raw IP?) so that you can log in and poke around even when half of the protocol stack has gone South? (I realize that some packets may be lost, but I don't think that matters very much in this kind of situation). Comments? -- Greg Fisher @ fisher.tinton.ccur.com
-----------[000088][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jan 1993 16:33:58 GMT From: gmarzot@mitre.org (G. S. Marzot) To: comp.protocols.tcp-ip Subject: Round Trip Time(RTT) and FTP
Here are some interesting issues that I have been having trouble nailing down concerning the behavior of TCP, and FTP on top of TCP in particular. I am on a Sun SPARC 2 SunOS 4.1.2 When FTP begins a file transfer, assuming the connection has already been established, it makes another connection to host1.ftp-data, negotiates MSS and window sizes(in my case mss=1460 and window=24576) and then starts transferring data. The question is - does the second connection use the RTT calculated when the FTP session was brought up or must it recalculate it anew? What is the initial guess at RTT(and corresponding RXMIT timer) for a new TCP connection? Can this be changed? by FTP? in the kernel? Is there a way to monitor/log the progress of the RTT calculations for a particular connection? Does Sun's implementation of TCP use adaptive window slow start algoritms? I have seen FTP sessions negotiate different maximum segment sizes(mss) for different connections - what are the issues driving the selection of an mss and can this be controlled by the user? Thank you very much in advance for any light shed. -GSM
-----------[000089][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 93 16:37:18 GMT From: pozar@kumr.lns.com (Tim Pozar) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
mlewis@telebit.com (Mark S. Lewis) writes:
>> I currently attach via SLIP over a leased line using v.32bis/v.42bis
>> modems from a Dell machine (on my end) into a smartport on a Telebit Netblazer.
>> Would I see any significant increase in throughput using this same
>> physical connection (v.32bis/v.42bis) but replacing the Dell SLIP
>> with a Netblazer on my end -- and connecting my machines via ethernet
>> to the Netblazer?
>> [...]
>> Larry Snyder internet: larry@gator.rn.com
>
>No I don't think you would get a significant performance increase by
>putting a NetBlazer at both ends. You are using relatively slow
>serial lines limited by V.32bis modulation with whatever compression
>you get with V.42bis.
>
>Mark S. Lewis inet: mlewis@telebit.com
I disagree. I think you will get some increase in preformance, depending
on how loaded your box that is doing the routing is. Routing IP packets
takes a certain amount of CPU over head as well as servicing the serial
line interupts that happen every time you get a packet in. Using 16500
helps.
BTW there are other soultions to netblazers...
We have been playing with a number of router soulutions for our coopertive
network, "The Little Garden". Currently we are running KA9Q/NOS for our
dial-up routers. The other day I brought up 386BSD as a router and found
that ping times went down by about 10 to 20%. With a '386DX-16 running
KA9Q tied via v.32bis/v.42bis Forval modems to a '386SX-25 runing KA9Q
our 56byte ping times were about 200 to 240mS on an unloaded circuit.
With 386BSD on just one side the ping times were about 190 to 210 mS.
Same hardware, just one side had different router software.
After experimenting with 386BSD a bit, I am going to put more of an effort
into getting something ship shape to run off a floppy and try to replace
a couple of our links with it.
A side note. Netblazer software was based on the KA9Q software. Enough
work has gone into it by now that I imagine that it doesn't look like KA9Q
any more, but I wonder if it still has the same problems that KA9Q has,
like memory leakage and high latency. Perhaps Mark could comment on the
Netblazer software.
Our cost per KA9Q box is about $600 as it is only a fast '386 mother
board with 1Meg of memory, 1.4 meg floppy drive and controller, case/power
supply, keyboard, ethercard(SMC), 16550 stuffed async card, monitor and
video card.
Phil Karn asks for about $50 for commercial installation of the KA9Q
software. 386BSD is currently availible for free off of the net from
agate.berkeley.edu. Bill Joliz does ask for a contribuition of $50 for
the binaries and $100 for the source.
At the last ONEBBS con in Denver, there was a demonstration of a device
called "Slip-on-a-Stick". It was a box that was about 10"x6"x2" tall, and
would do slip. I don't know if it will do the right thing with subnetting
as I only saw it work with one device on it. The price was less than a
grand.
Tim
--
Internet: pozar@kumr.lns.com FidoNet: Tim Pozar @ 1:125/555
Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA
Voice: +1 415 788 2022
-----------[000090][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 93 16:39:58 GMT From: mckenzie@bbn.com (Alex McKenzie) To: comp.protocols.tcp-ip Subject: Re: TCP/IP for Tops-10
According to Jerry Burchfiel, who was there at the time: "Bill Plummer and Ray Tomlinson of BBN first implemented TCP/IP on TENEX. Thanks to Charles Lynn, also of BBN, it was later ported onto TOPS-20. I think it skipped over TOPS-10." Alex McKenzie BBN
-----------[000091][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 1993 16:59:38 GMT From: kby@cco.caltech.edu (Kimo B. Yap) To: comp.protocols.tcp-ip Subject: Re: TCP/IP for Tops-10
As I mentioned to the original author (but didn't bother to post) I believe there was a hack version of TCP/IP for the -10, but I think it was last known to work in about 6.02. I don't remember who did it and will have to do some digging (I know the chain, but the end is kind of buried).-kby
-----------[000092][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 93 17:07:48 GMT From: chuck@npdiss1.StPaul.NCR.COM (Charles Rissmeyer) To: comp.protocols.tcp-ip Subject: Re: STARLAN 10 10BASE-T hub unit doesn't like adapters
In article <1993Jan8.022641.27932@alf.cooper.edu> hak@alf.cooper.edu (Jeff Hakner) writes: >I've had a similar problem. When I used the Allied Telesis thick-10BASE-T >adapter and plucked the twisted pair into an AT&T STARLAN 10 hub, the >whole network starting dying with heavy collisions (and no traffic!). >WHen I replaced the hub with an Allied hub (more modern), no problems. >I thought STARLAN10 was supposed to be compatible with 10-BASE-T, but perhaps I'm not very familiar with the details of STARLAN10 hubs. The newer ones are 10BaseT compatible. It sounds like you might have a problem with the link-beat , sometimes called link integrity, or heartbeat. Basically, if you have link-beat on at the hub, you need it on at the workstation's transceiver. If your hub doesn't support link-beat, then you must turn it off at the terminal too. One more thing I just thought of, I believe some Allied Telesis transceivers do not have the ablility to turn off link-beat. This means you must have it on at the hub. Good luck, Charles (Chuck) Rissmeyer KE0VG (612) 638-7669 (VP 652-7669) - charles.rissmeyer@StPaul.NCR.COM NCR - An AT&T Company NCR CCS-PM&S NPD St. Paul
-----------[000093][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jan 1993 17:20:41 GMT From: bob@MorningStar.Com (Bob Sutterfield) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: VJ compression (Re: Netblazer)
In article <C0JL58.HqK@news.rn.com> larry@news.rn.com (Larry Snyder) writes: Would VJ compression with SLIP be benificial even if you have hardware compression (v.42bis?). If so, how much? Yes, because RFC-1144 "VJ" TCP header compression and V.42bis do different things. The former is application-specific to TCP datagram headers, so it can be very efficient at its narrow mission. The latter is a general-purpose data compressor, so it does a fair job on lots of different data. RFC-1144 reduces the number of overhead octets with which each TCP datagram is afflicted. It does nothing with the fare-paying cargo inside the packet. A typical single-character telnet packet shrinks from forty-something to 5-8 octets, reducing transmission time and therefore dramatically reducing interactive latency. V.42bis is a general purpose data compression algorithm that compresses everything that passes through the modem - overhead and data alike. V.42bis processing actually adds a little latency, but not so much as to be objectionable. And its effect on shrinking the total size of the packets helps a *lot*. You'll often see over 3Kb/s FTP throughput over a V.32bis (14400) carrier with a 38400 DTE, with very little (if any) adverse effect on latency. -- Bob Sutterfield, Morning Star Technologies +1 614 451 1883 1760 Zollinger Rd, Columbus Ohio USA, 43221 +1 800 558 7827 bob@MorningStar.Com +1 614 459 5054 (FAX)
-----------[000094][next][prev][last][first]---------------------------------------------------- Date: Sat, 09 Jan 93 00:31:47 MST From: wmah@ersys.edmonton.ab.ca (Wayne Mah) To: comp.protocols.tcp-ip Subject: Unisys TCP/IP and UTS 20/40/60 emulation
Can anyone write a few words about TCP/IP on an Unisys mainframe and using a PC based package to provide UTS 20/40/60 emulation? Our very old DCP is flakely and we would like to use the HLC for connection to our Ethernet/Token Ring lan. -- Wayne Mah wmah@ersys.edmonton.ab.ca
-----------[000095][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 93 17:41:07 GMT From: heberlei@cs.ucdavis.edu (Louis Todd Heberlei) To: comp.protocols.tcp-ip Subject: reading what you're writing on Suns
I have found while using ethernet analyzers on Sun workstations
that they do not report the packets from the same host that they
are running on. For example, the command:
etherfind host toadflax
should report all packets TO and FROM toadflax; however, if I am
running the analyzer on toadflax, I only see packets TO toadflax.
None of the packets FROM toadflax are reported.
Apparently a Sun cannot read the packets that it is writing to
the network. I have two questions regarding this:
1) Is this common with most/all workstations (non-Suns)?
2) Is there a patch so the Sun can read it's own packets?
Any help would be appreciated. Thanks,
Todd heberlei@cs.ucdavis.edu
-----------[000096][next][prev][last][first]---------------------------------------------------- Date: Fri, 08 Jan 93 18:13:43 GMT From: alan@oetl1.scf.lmsc.lockheed.com (Alan Strassberg) To: comp.protocols.tcp-ip Subject: Re: STARLAN 10 10BASE-T hub unit doesn't like adapters
In article <1993Jan8.022641.27932@alf.cooper.edu> hak@alf.cooper.edu (Jeff Hakner) writes: [..] >I've had a similar problem. When I used the Allied Telesis thick-10BASE-T >adapter and plucked the twisted pair into an AT&T STARLAN 10 hub, the >whole network starting dying with heavy collisions (and no traffic!). >WHen I replaced the hub with an Allied hub (more modern), no problems. >I thought STARLAN10 was supposed to be compatible with 10-BASE-T, but perhaps >there are some subtel differences which prevent this interoperation? When you mix non-link integrity (pre 10BaseT) with 10BaseT standard you get massive collisions. I run both the old and new side by side by cascading hubs with an AT&T transceiver that has a switch for link-integrity - they work fine together. Some hubs (Asante, AT&T) have link-integrity switches on a per-port basis. And the newer StarLAN10 cards have a link switch on back. alan -- Alan Strassberg alan@oetl1.scf.lmsc.lockheed.com (408) 425-6139 Lockheed, Santa Cruz, California.
-----------[000097][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 93 19:22:35 GMT From: barnett@grymoire.crd.ge.com (Bruce Barnett) To: comp.protocols.tcp-ip Subject: Re: Why would a Sun take 1.5 seconds to retransmit a missed packet?
In article <184841@pyramid.pyramid.com> lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes: > Transmitting using what protocol? FTP, NFS copy or what? It's TCP based. Similar to FTP. >>Packets are missed by the archive system, so the Sun has to retransmit >>the missed packets. I have noticed large delays (0.5 - 1.5 seconds) > Those are pretty typical numbers for TCP layer time-outs... Thomas Narten mentioned that the granularity of the retransmit timer is a multiple of 0.5 seconds. Also for every ACK of one segment sent, you have to restart the timer for the next segment. I wonder if a finer granularity on the retransmit value would help if the peer is on the same network? I guess this is tough because some peers may be slow and some may be fast. It could keep track of the time for an ACK and try to pick a timeout near that time, I guess..... > If this is FTP, you'd probably be better off getting rid of the > fatal collisions on the net.....unless you can set the time-outs > to a very small number (very dangerous, but....) It's not collisions, because I saw the packets being sent. It seems the receiver _missed_ seeing the packets on Ethernet. People have told me the best solution is to upgrade the receiver. This could be a hardware upgrade (faster CPU, more memory, more ethernet ports, smarter ethernet ports, etc.) and possibly some software tuning. Does anyone have advice on the relative advantage of each option? How much would more memory help? A faster CPU? A second CPU? A second Ethernet card? A faster disk? What is the best choice? The most cost-effective choice? Who's gonna win the Superbowl? Well, forget the last question. I was on a roll..... :-) Thanks for all of the advice, esp. Stephen C. Trier, Aaron Leonard, Thomas Narten, Anay Panvalkar, Paul Hyder, and Roger-Hunen. -- Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
-----------[000098][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 93 19:24:13 GMT From: guy@Auspex.COM (Guy Harris) To: comp.protocols.tcp-ip Subject: Re: reading what you're writing on Suns
>Apparently a Sun cannot read the packets that it is writing to >the network. I have two questions regarding this: > > 1) Is this common with most/all workstations (non-Suns)? I've never seen an Ethernet interface that *does* hear its own transmissions, but some may exist. All the Ethernet-interface drivers I've seen will wrap transmitted *broadcast* packets around internally, so that it *looks* as if they receive the packet, but they don't do so for non-broadcast packets. > 2) Is there a patch so the Sun can read it's own packets? The precise question you're asking is "is there a patch so that the Sun can read its own packets *through the Network Interface Tap (NIT) mechanism*, that being the mechanism that "etherfind" uses to listen to Ethernet traffic. I know of none, although a quick look at the code indicates that it might be possible to arrange to have non-broadcast packets wrapped around, just as broadcast packets are wrapped around, if the Ethernet interface is in promiscuous mode, so I suspect such a patch is, at least, implementable.
-----------[000099][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 93 19:51:39 GMT From: donp@novell.com (don provan) To: comp.protocols.tcp-ip Subject: Re: TCP/IP for Tops-10
In article <lkrbiuINNi35@news.bbn.com> mckenzie@labs-n.bbn.com (Alex McKenzie) writes: >According to Jerry Burchfiel, who was there at the time: "Bill Plummer >and Ray Tomlinson of BBN first implemented TCP/IP on TENEX. Thanks to >Charles Lynn, also of BBN, it was later ported onto TOPS-20. I think it >skipped over TOPS-10." Gee, if i'd known there'd be this much interest, i would have posted the answer instead of just sending it directly. I implemented TCP/IP on TOPS-10. There's no relation between the TOPS-10 implementation and the TENEX/TOPS-20 implementation. On the other hand, a derivitive of the TOPS-10 code ran on WAITS, just in case anyone thought this conversation wasn't obscure enough yet. To my knowledge, there is no copy of the code on the face of the earth, though i'd be happy to hear someone tell me i'm wrong, particularly if they could send me a copy. And, although i can't imagine anyone really cares, it ran on 6.02 and 6.03a. After that i'm a little vague, but i think i got it to run on 7.00, but not 7.01. Something about radical changes to the IO system in 7.01, but, gee, that was many years ago so i don't remember the details. don provan donp@novell.com
-----------[000100][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jan 1993 20:37:30 GMT From: sobczyk@bcstec.ca.boeing.com (Andy Sobczyk) To: comp.protocols.tcp-ip Subject: DLPI/LLI Protocols
Newsgroup: comp.protocols.tcp-ip Expires: 1 Feb 92 I am converting a SCO DLPI (Data Link Provider Interface) to a Interactive /Venix LLI driver to work with WINTCP for STREAMS. The problem I am having is getting any information on the two protocols LLI/DLPI perferable a detailed spec. Does anyone know where I can get this information? If you have a copy on line.... could you mail one to me???? Andy Sobczyk sobczyk@bcstec.ca.boeing.com
-----------[000101][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jan 93 20:39:28 GMT From: larry@eco.twg.com (Lawrence B. Henry III) To: comp.unix.aix,comp.unix.questions,comp.protocols.tcp-ip Subject: Re: ftp: subcommand error codes
In article <1993Jan7.192157.18720@eco.twg.com>, larry@eco.twg.com (Lawrence B. Henry III) writes: |>Austin, |> Check out rfc640.. I believe that this is the latest source of |>information on this topic.. it is readily available from nic.ddn.mil in the |>RFC sub-directory.. |> |>-Larry. Ok.. so my index is old.. :-) -Larry.
-----------[000102][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jan 1993 20:49:12 GMT From: narten@cs.albany.edu (Thomas Narten) To: comp.protocols.tcp-ip Subject: Re: Why would a Sun take 1.5 seconds to retransmit a missed packet?
In article <930108124846@cream.ftp.com> jbvb@vax.ftp.com (James B. VanBokkelen) writes: > In article <184841@pyramid.pyramid.com> lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes: > > In article <BARNETT.93Jan7091846@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes: > > >Packets are missed by the archive system, so the Sun has to retransmit > >the missed packets. I have noticed large delays (0.5 - 1.5 seconds) > > Those are pretty typical numbers for TCP layer time-outs... > > If so, it indicates that 1) the path is long, 2) the archive system is very > slow or 3) the sending TCP has an inferior or broken adaptive retransmit > algorithm. The third answer is probably the best. While one could argue that the implementation is "inferior", the observed behavior makes sense given the implementation. In the following, assume we are on a LAN, so that actual RTTs are on the order of milliseconds. It is still possible to see retransmissions up to 1.5 seconds after a segment is sent. Under BSD, the TCP retransmit timer clock ticks at a relatively slow rate of .5 seconds. Thus, the absolute minimum retransmit time one can set is .5 seconds. However, the time can be up to twice as long even under normal circumstances. One factor is that BSD only has one retransmit timer going at a time, rather than one for each outstanding segment. If one transmits segments 1-4, for example, BSD starts a single retransmit timer for segment 1. When the ACK for segment 1 arrives, a timer needs to be started for segment 2. Although segment 2 was sent in the past sometime (perhaps as long as just under one RTT ago), the timer is reset to the full smoothed RTT value. Thus, the actual time that elapses before the retransmit timer for segment 2 expires could be as long as twice what it should be. Finally, even though one can theoretically set a timer to go off in .5 seconds, that's not exactly the case. BSD implements timers by having a clock device driver call the routine tcp_slowtimeo() every .5 seconds. The actual retransmit timer is maintained as a counter in units of .5 seconds, so that tcp_slowtimeo() simply decrements the timer, and if it reaches 0, retransmits the segment in question. Now, if one wants to schedule a timer to go off in exactly .5 seconds, one might think that setting the counter (timer) to 1 would do the trick. Unfortunately, if tcp_slowtimeo() was last invoked 499 ms ago, it is about to be invoked right away again and it would decrement a timer of 1 to 0 almost immediately, certainly before .5 seconds have elapsed. Thus, when setting a timer for .5 seconds, one actually wants the timer to go off *no sooner than* .5 seconds from now, and one may actually have to wait .9999 seconds. That is, we want the timer to go off during the second call of tcp_slowtimeo() rather than the first. Even on a LAN, the above would account for the actual retransmit timer for a segment varying from .5-1.5 seconds. -- Thomas Narten narten@cs.albany.edu
-----------[000103][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jan 1993 21:08:27 GMT From: johnson@trwacs.fp.trw.com (Steve Johnson) To: comp.protocols.tcp-ip Subject: Re: A short course in TCP/IP
shan@cray.com (Sharan Kalwani) writes:
>In article <1006.UUL1.3#20656@distinct.com> chris@distinct.com (Chris Bologna) writes:
>>>> I need to attend a good TCP/IP course that would cover administration issues,
>>>> network management, programming (RPC or some DCE maybe), etc.
>>>> Thanks for any ideas!
>>>> -Lee Thomas
>you may also wish to contact InterOp. I don't have a phone number handy....
^^^^^^^
1 - 800 - INTEROP (figures ;-) )
>also the USENIX, LISA folks have TCP/IP courses too....
>--
>Sharan Kalwani, cri, 2000 town center suite 2350, southfield mi 48075
>phone: (313) 576-3948 (313) 335-5580
>internet: shan@cray.com uucp: ...!uunet!cray.com!shan
--
------- Any views expressed are those of myself and not my employer. --------
Steven C. Johnson, WB3IRU / VK2GDS |
TRW | johnson@trwacs.fp.trw.com
FP1 / 3133 | [129.193.172.90]
-----------[000104][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 93 21:34:38 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: reading what you're writing on Suns
In article <16287@auspex-gw.auspex.com>, guy@Auspex.COM (Guy Harris) writes: > >Apparently a Sun cannot read the packets that it is writing to > >the network. I have two questions regarding this: > > > > 1) Is this common with most/all workstations (non-Suns)? > > I've never seen an Ethernet interface that *does* hear its own > transmissions, but some may exist. All the Ethernet-interface drivers > I've seen will wrap transmitted *broadcast* packets around internally, > so that it *looks* as if they receive the packet, but they don't do so > for non-broadcast packets. > > > 2) Is there a patch so the Sun can read it's own packets? > ... With 7990 LANCE based hardware, it is impossible to hear your own packets with just the hardware, unless your packets are ridiculously small. Anything larger than something like 38 bytes cannot be heard. With SEEQ 8003 and similar based systems, the hardware can in be built to hear its own output, but the main vendor I know of that uses 8003's and derivatives in some systems (guess which vendor) has chosen to implement loopback purely in software. Doing loopback in software is a good idea with common 4.3BSD and SVR4 (I think) style code, which do not work well if they cannot hear their own broadcasts. You usually want your system to come up even if the ethernet cable is unplugged. Vernon Schryver, vjs@sgi.com
-----------[000105][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jan 1993 21:42:48 GMT From: rama@andy.bgsu.edu (Sub Ramakrishnan) To: comp.protocols.tcp-ip Subject: freeware PC RPC
Greettings: Our PC will be connected to the ethernet using a WD ethernet card. Is there a public domain RPC (and TCP) software for PCs? I know Sun's rpc for unix platform is free but am not sure about PCs. Thank You ==sub -- Dr. Sub Ramakrishnan Internet: rama@truth.bgsu.edu Dept of Computer Science Bitnet: rama@bgsuopie Bowling Green State University Bowling Green, OH 43403 Voice: 419 372 2337. Fax:419 372 8061
-----------[000106][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jan 1993 22:55:59 GMT From: sasmkg@unx.sas.com (Mark Gass) To: comp.protocols.tcp-ip Subject: seeking WINSOCK API definition
Where can I find the definition for the WINSOCK API (the recently defined socket API for MS-Windows)? I would like to understand portability problems between UNIX and WINSOCK. For example, I assume that socket descriptors cannot be passed by the normal fork()/process-creation mechanism that is used under UNIX. If this problem exists, are additional functions introduced as an alternative socket passing mechanism? Thanks, Mark Gass EMAIL: sasmkg@unx.sas.com SAS/C Development Voice: (919) 677-8000 SAS Institute FAX: (919) 677-8224
-----------[000107][next][prev][last][first]---------------------------------------------------- Date: Sat, 9 Jan 1993 00:49:58 GMT From: "Bernd Finkemeyer" <p00122@psilink.com> To: comp.protocols.tcp-ip Subject: Re: Mil-Stds for TCP-IP
| The following article was forwarded from a Compuserve user. Please send | any private responses to "72500.3562@compuserve.com". These are the military standards: MIL-STD-1777 IP MIL-STD-1778 TCP MIL-STD-1780 FTP MIL-STD-1781 SMTP MIL-STD-1782 TELNET The last three are verbatim copies of the corresponding RFCs. The first two are technically aligned with the corresponding RFCs, but are more readable and include clearer, tutorial-type descriptions of the protocols. All of them are in the Volume 1 of the Internet Technology Handbook from the SRI NIC (nisc@nisc.sri.com) Bill Stallings 72500.3562@compuserve.com
-----------[000108][next][prev][last][first]---------------------------------------------------- Date: Sat, 09 Jan 1993 00:55:10 GMT From: hofer@rchland.vnet.ibm.com (Kent Hofer) To: comp.protocols.tcp-ip Subject: XTI confusions
If a server is written using XTI, at what point does TCP begin sending a positive ack flow back to the client machine in response to an inbound connection request: 1) When the server issues the t_bind() to mark the descriptor to begin queuing connections? 2) When the server issues the t_listen() to find out if any connections are queued? 3) When the server issues t_accept() to accept the connection on the same or a different descriptor? The X/open XTI spec almost reads like the answer should be 3. The sequence number from the t_listen() completion is used to respond with an "I'll take the connection" via t_accept() or with a "no way" via t_snddis(). If it worked like this, then the server could control if the client connect completed ok or with something like ECONNREFUSE. But, my knowledge of how the sockets API works tells me that XTI probably doesn't work this way, and the answer is problably 1). I'm guessing that the TCP ack goes back to the client when the connection indication is received, as long as someone has done a t_bind(), which appears to be the same as a socket listen(). Ok, if I guessed wrong, please inform me of how this works! If I guessed correctly, could someone tell me what happens to the connection identified by a t_snddis() sequence number when it is not yet accepted by the server application? Does TCP just send a RESET? Thanks! Kent -- Kent Hofer hofer@rchland.vnet.ibm.com (my opinions are my own and have nothing to do with my employer)
-----------[000109][next][prev][last][first]---------------------------------------------------- Date: Sat, 9 Jan 1993 04:34:07 GMT From: karl@ddsw1.mcs.com (Karl Denninger) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
In article <C0JL0L.HEx@news.rn.com> larry@news.rn.com (Larry Snyder) writes: >karl@ddsw1.mcs.com (Karl Denninger) writes: > >>>>Can the NB support 2 56700 baud modems going full blast on the >>>>stock 2 serial ports on the motherboard? >>> >>>try pulling the case off and seeing of the UARTs are 16550's. >>> >>>i would suspect so. >>They certainly are. (I have examined lots of these) > >So one can assume they support the FIFO to get those speeds. > >My next question is do you have to enable a specific protocol -- >ie: Can I start talking to the NB with SLIP using VJ compression >and will it start using VJ - likewise, can I connect using PPP >and will the netblazer be smart enough to change? The login you use on the NB will tell it what protocol (PPP or SLIP) Once you are connected if the NB is set to "auto" mode it will send VJ compressed packets IF it sees one from the other end. That is, it watches the line to see whether it should switch on the compression. If you turn it "on" then it will initiate calls with this feature enabled. Somewhat like the "compression" in their Trailblazer modems. You can enable "automatic" detection, set it "on", or "off". If its "on" the other end must support compression. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Data Line: [+1 312 248-0900]
-----------[000110][next][prev][last][first]---------------------------------------------------- Date: Sat, 9 Jan 1993 04:34:51 GMT From: karl@ddsw1.mcs.com (Karl Denninger) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
In article <C0JL58.HqK@news.rn.com> larry@news.rn.com (Larry Snyder) writes: >Would VJ compression with SLIP be benificial even if you >have hardware compression (v.42bis?). If so, how much? > >Just wondering -- Yes. Without VJ compression interactive sessions on SLIP or PPP connections at dial speeds are painfully slow, even with V.42bis on the modems. They are quite complimentary. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Data Line: [+1 312 248-0900]
-----------[000111][next][prev][last][first]---------------------------------------------------- Date: 9 Jan 93 08:08:07 GMT From: lars@spectrum.CMC.COM (Lars Poulsen) To: comp.protocols.tcp-ip Subject: Re: TCP/IP for Tops-10
In article <lkrbiuINNi35@news.bbn.com> mckenzie@labs-n.bbn.com (Alex McKenzie) writes: >According to Jerry Burchfiel, who was there at the time: "Bill Plummer >and Ray Tomlinson of BBN first implemented TCP/IP on TENEX. Thanks to >Charles Lynn, also of BBN, it was later ported onto TOPS-20. I think it >skipped over TOPS-10." The stock PDP-10s swapped segments. TENEX was a demand paged virtual memory system, and BBN designed a memory management unit to support that, and then implemented the system on that base. DARPA bought a lot of them (by the standards of the time). Later, DEC built a streamlined TENEX box and called it the DEC-system 20. The system was TENEX with fairly minor changes, but to DEC Marketing decided to rename it TOPS-20 to underscore the similarities to TOPS-10. The most significant DEC enhancement over TENEX, may have been DECNET-20. Did TENEX have DECNET ? -- / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM CMC Network Products / Rockwell Int'l Telephone: +1-805-968-4262 Santa Barbara, CA 93117-3083 TeleFAX: +1-805-968-8256
-----------[000112][next][prev][last][first]---------------------------------------------------- Date: 9 Jan 93 08:13:20 GMT From: lars@spectrum.CMC.COM (Lars Poulsen) To: comp.protocols.tcp-ip Subject: Re: reading what you're writing on Suns
In article <16287@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes: >> 2) Is there a patch so the Sun can read it's own packets? >The precise question you're asking is "is there a patch so that the Sun >can read its own packets *through the Network Interface Tap (NIT) >mechanism*, that being the mechanism that "etherfind" uses to listen to >Ethernet traffic. > >I know of none, although a quick look at the code indicates that it >might be possible to arrange to have non-broadcast packets wrapped >around, just as broadcast packets are wrapped around, if the Ethernet >interface is in promiscuous mode, so I suspect such a patch is, at >least, implementable. It seems (from dumps of NIT-traces that I have done) as if some packets do indeed get cloned and looped back, but generally, they don't have the sender's ethernet address filled in, so they don't always get recognized for what they are.... -- / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM CMC Network Products / Rockwell Int'l Telephone: +1-805-968-4262 Santa Barbara, CA 93117-3083 TeleFAX: +1-805-968-8256
-----------[000113][next][prev][last][first]---------------------------------------------------- Date: 9 Jan 93 16:47:34 MDT From: jrd@cc.usu.edu (Joe Doupnik) To: comp.protocols.tcp-ip Subject: Re: time outs in FIN-WAIT2??
In article <1993Jan9.164215.20972@jupiter.sun.csd.unb.ca>, dedgar@mta.ca writes: > Hello > > I was wondering if anyone out there knows anything about a curious thing I've > seen while ftping into various machines. > > I am writing a pc based ftp client program, among other things this software > has a hold screen function which is useful for pausing dirs to the screen & > etc. Anyway, if the screen is held the incoming directory listing backs up > to the limit of my advertised window - just like it is supposed to. If the > window happens to be larger than the remaining data the other side will > send its fin and (i presume) move to fin-wait1. My side will go to close_wait > > My side will remain in close-wait because it cannot get rid of the remaining > data (the hold screen is on) but will ack the other sides fin which > (i presume) moves it to fin_wait2. The problem happens when I release the > hold screen. When this happens my side finishes processing the data and sends > its own fin, then moves to last ack. I have found that if the wait is long > enough (10 sec or so) the other side will ignore my fin and never return an > ack - this leaves me in last_ack. Eventually it seems my retransmitted fin > will generate a reset from the other side. > > I interpret this problem to mean that the other side has timed out or retried > out in fin-wait2. Is this a valid assumption. Does tcp-ip software do this? > It sure isn't in the rfc. Is there another interpretation. I have experienced > it with a number of types of machines on the internet (via anonymous ftp) maybe > anonymous is a special case in unix boxes? > > Can anyone definitly confirm (one way or the other) that this is in fact > what is going on. I don't rule out bugs in my software, but I checked pretty > thouroughly before asking here. > > Thanks > Dale Edgar > Cybernetic Control Inc. > DEDGAR@MTA.CA ----------- I did some similar thinking recently in my program. The answer depends on how one interprets "delivers the data." I finally decided that delivery meant placing in a socket buffer so I could send ACKs in the background as the buffer filled. Given this position then the buffer belongs to the top level application and not to the TCP session. Thus the session can close up normally and so on, yet that buffer remains for later draining. This works well with systems which insist upon sending reams of goodbye message material and my program is busy with other things for a while. For top level app, the session is over when both the TCP part has finished completely and the buffer is empty. Opinions do/will differ on this end to end delivery stuff. Joe D.
-----------[000114][next][prev][last][first]---------------------------------------------------- Date: 9 Jan 93 15:05:50 GMT From: jraja@vipunen.hut.fi (Jarno Tapio Rajahalme) To: comp.protocols.tcp-ip Subject: Re: seeking WINSOCK API definition
The winsock API specification can be found from vax.ftp.com with anonymous ftp from directory pub/winsockapi/winsock-1.1. vax.ftp.com is FTP Software's machine. Jarno
-----------[000115][next][prev][last][first]---------------------------------------------------- Date: Sat, 9 Jan 1993 16:42:15 GMT From: dedgar@mta.ca To: comp.protocols.tcp-ip Subject: time outs in FIN-WAIT2??
Hello I was wondering if anyone out there knows anything about a curious thing I've seen while ftping into various machines. I am writing a pc based ftp client program, among other things this software has a hold screen function which is useful for pausing dirs to the screen & etc. Anyway, if the screen is held the incoming directory listing backs up to the limit of my advertised window - just like it is supposed to. If the window happens to be larger than the remaining data the other side will send its fin and (i presume) move to fin-wait1. My side will go to close_wait My side will remain in close-wait because it cannot get rid of the remaining data (the hold screen is on) but will ack the other sides fin which (i presume) moves it to fin_wait2. The problem happens when I release the hold screen. When this happens my side finishes processing the data and sends its own fin, then moves to last ack. I have found that if the wait is long enough (10 sec or so) the other side will ignore my fin and never return an ack - this leaves me in last_ack. Eventually it seems my retransmitted fin will generate a reset from the other side. I interpret this problem to mean that the other side has timed out or retried out in fin-wait2. Is this a valid assumption. Does tcp-ip software do this? It sure isn't in the rfc. Is there another interpretation. I have experienced it with a number of types of machines on the internet (via anonymous ftp) maybe anonymous is a special case in unix boxes? Can anyone definitly confirm (one way or the other) that this is in fact what is going on. I don't rule out bugs in my software, but I checked pretty thouroughly before asking here. Thanks Dale Edgar Cybernetic Control Inc. DEDGAR@MTA.CA
-----------[000116][next][prev][last][first]---------------------------------------------------- Date: Sat, 9 Jan 1993 18:10:02 GMT From: jcmorris@mwunix.mitre.org (Joe Morris) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: TELNET terminal types
[I haven't been monitoring this group before, so excuse me if this
is an FAQ...]
I'm looking for some help in resolving a problem of common usage versus
RFC standards in the tcp/ip arena.
Our corporate standard PC-based TCP/IP package (Wollongong's PathWay for DOS)
gives us problems when it is used to attach via telnet to the various UNIX
boxes around the campus. In particular, in the terminal-type options
negotiation (per RFC 1091) the Wollongong product is delivering the text
string:
DEC-VT100
(or "DEC-VT220" or whatever) to the host. Unless I've missed something
this actually does conform to the requirements of RFC 1060 ("Assigned
Numbers") dated 3/90.
The trouble is that none of our UNIX boxes (typically running SUN-OS,
IBM's AIX (RS-6000), or Silicon Graphics' IRIX) have the faintest
idea what to do with this terminal type; their terminfo files expect
something like "vt100". One problem is that RFC 1060 does not include
any terminal types of the form "VTxxx".
So...any comments? Is Wollongong alone in adhering to RFC 1060, or do
the UNIX vendors say "RFC's aren't legal standards", or have I missed
some obvious point here?
Joe Morris / MITRE
-----------[000117][next][prev][last][first]---------------------------------------------------- Date: Sat, 9 Jan 1993 23:59:02 GMT From: frank@twg.com (Frank McConnell) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: TELNET terminal types
I find the following workaround helpful in dealing with mismatches between the terminal types listed in the Assigned Numbers RFC and those that appear in termcap or terminfo databases: eval `tset -s -m 'dec-vt100:vt100' -m 'network:?vt100'` This appears in my .login on most of the Suns that I work with. The "-m 'dec-vt100:vt100'" instructs tset to map a terminal type of "dec-vt100" to "vt100", and the "-s" instructs tset to issue commands to reset the terminal type in the environment. (The later "-m 'network:?vt100'" instructs tset to prompt for a terminal type if the terminal type is initially set to "network", but to assume a default value of "vt100". This covers cases where the TELNET client I'm using at the time isn't reporting a terminal type; in some of those cases, I'm TELNET-ing in from an HP terminal that is not like a VT100 and so want to be able to specify a type of "hp".) Hope this helps! If you need additional help with this, feel free to e-mail me. -Frank McConnell, Product Engineering, The Wollongong Group <frank@twg.com>
-----------[000118][next][prev][last][first]---------------------------------------------------- Date: Sun, 10 Jan 1993 00:18:13 GMT From: bygg@sunic.sunet.se (Johnny Eriksson) To: comp.protocols.tcp-ip Subject: Re: TCP/IP for Tops-10
In article <1993Jan8.195139.27625@novell.com> donp@novell.com (don provan) writes:
>Gee, if i'd known there'd be this much interest, i would have posted the
>answer instead of just sending it directly. I implemented TCP/IP on
>TOPS-10. There's no relation between the TOPS-10 implementation and the
>TENEX/TOPS-20 implementation. On the other hand, a derivitive of the
>TOPS-10 code ran on WAITS, just in case anyone thought this conversation
>wasn't obscure enough yet. To my knowledge, there is no copy of the
>code on the face of the earth, though i'd be happy to hear someone tell
>me i'm wrong, particularly if they could send me a copy.
See below.
>And, although i can't imagine anyone really cares, it ran on 6.02 and
>6.03a. After that i'm a little vague, but i think i got it to run on
>7.00, but not 7.01. Something about radical changes to the IO system
>in 7.01, but, gee, that was many years ago so i don't remember the details.
It has been running on 7.02, talking IP-on-top-of-DDCMP to a VAX running
BSD 4.2, thru an ANF-10 front end sync port instead of using an IMP.
This required some slight changes...
Beginning if TCPSER.MAC follows, to prove I'm not lying:
title TCPSer
subttl provan
search f,s
search NetDef ; network definitions
search MacTen ; search only if symbol not found in NetDef
sall
$reloc
$high
XP VTCPSr,7 ; TCP version
comment \
this module contains the support routines for the transmission
control protocol as defined in RFC-793
\
subttl compilation control
; number of perpetual listens to allow at one time.
; [udp] make global
ifndef PlsLen,< PlsLen==:^d10 > ; default is 10 entries
subttl TCP states
; first define the states we have for TCP
S%Clos==^d0 ;; closed (sometimes convenient, although usually
;; detected by absense of DDB)
;; must ALWAYS be zero. "closed" type states are
;; less than or equal to zero.
S%List==^d1 ;; listen
S%SynS==^d2 ;; SYN sent
S%SyRP==^d3 ;; SYN received, passive
S%SyRA==^d4 ;; SYN received, active (from S%SynS)
S%Estb==^d5 ;; established
S%Fin1==^d6 ;; FIN wait 1
S%Fin2==^d7 ;; FIN wait 2
S%Clsn==^d8 ;; Closing
S%TimW==^d9 ;; time wait
S%ClsW==^d10 ;; Close wait
S%LAck==^d11 ;; last ACK
subttl macro for dispatching on different states
; now define a macro to define a dispatch vector. there are three
; arguments. the first is the register containing the state code.
; the second is the location to jump to if a state comes which
; is not defined in this table. the third is a list of pairs of
; entries: the state code and the instruction to execute.
;warning: the state pairs MUST begin on the same line as the second
; argument. state pairs MUST be separated from each other with
; commas (between each pair) which MUST be on the same line as
; the macro which FOLLOWs.
define Dispat (AC,ErrLoc,StPair),
<
...min==777777 ;; a high starting point
...max==-1 ;; and a low one
define Pair (state,instr),
<
ifl <state>-...min,< ...min==<state> >
ifg <state>-...max,< ...max==<state> >
>
define $$help(bogus),< pair(bogus) > ;; your classic helper macro
irp StPair,< ;; for each pair
$$help(StPair) ;; expand the Pair macro with each pair
;; the as arguments.
>
;; code to check to see if the state is in the legal range
cail <AC>,...min ;; less than the lowest we know
caile <AC>,...max ;; or greater than the highest
jrst <ErrLoc> ;; go to the error handler
define Pair (state,instr),
<
ife ...x-<state>,< ;; is this our state?
instr ;; expand the instruction
...flg==1 ;; and tell that we did something
>
>
;; code for the actual dispatching
xct [
...x==...min ;; start with lowest state
repeat ...max-...min+1,< ;; do every state in the range
...flg==0 ;; nobody's claimed this spot yet
irp StPair,< ;; go through all the pairs
$$help(StPair) ;; expanding the Pair macro with each.
>
ife ...flg,< ;; if no one claimed to be this
jrst <ErrLoc>;; go to the error handler
>
...x==...x+1 ;; next place.
>
]-...min(<AC>) ;; now correctly index the XCT
purge ...min,...max,...x,...flg
> ;; end of Dispat macro definition
;; Let's skip to an interesting routine:
subttl SecChk
;++
; Functional description:
;
; Classified.
;
;
; Calling sequence:
;
; Classified.
;
; Input parameters:
;
; Classified.
;
; Output parameters:
;
; Classified.
;
; Implicit inputs:
;
; Classified.
;
; Implicit outputs:
;
; Classified.
;
; Routine value:
;
; Classified.
;
; Side effects:
;
; Classified.
;
;--
SecChk: pjrst cpopj1## ; security looks good.
> don provan
> donp@novell.com
--Johnny
"When in doubt -- hesitate!"
-----------[000119][next][prev][last][first]---------------------------------------------------- Date: 10 Jan 93 03:08:41 GMT From: alagu@Apple.COM (Alagu Periyannan) To: comp.protocols.tcp-ip Subject: raw sockets and TCP/IP internals
Hi! I would like to write some programs on a UNIX system to test the TCP/IP protocol implementation on another system, say a black box running a TCP echo server. I need to test the IP and TCP implementations on such a black box. Is there any document where I can get more information on opening raw sockets and accessing the tcp and ip layers directly ? I would like to have access to the sequence numbers, ack numbers, checksums, etc. on the outgoing packets. I would also like to analyze the response from the black box to determine whether it conforms to TCP/IP protocol. Any suggestions on how to do this ?? There are many include files in /usr/include/netinet which are never used with normal sockets programs. Is there any documentation for using these files in programs ? Thanks. -Alagu Periyannan alagu@apple.com -- --------------------------------------------------------------- Alagu Periyannan alagu@apple.com .... and the cosmic hippo rides a jet carpet !!
-----------[000120][next][prev][last][first]---------------------------------------------------- Date: 10 Jan 93 06:15:28 GMT From: olson@anchor.esd.sgi.com (Dave Olson) To: comp.protocols.tcp-ip Subject: Re: WINTCP or DOS / IRIS Problem.
In <1ic3orINN9nn@vttux1.vtt.fi> leino@rat.vtt.fi (Tapio Leino) writes:
| This just makes us wonder. Why has the window size been changed? What
| do we lose changing it back to its original value, 24k?
Performance between hosts that can handle it.
--
Let no one tell me that silence gives consent, | Dave Olson
because whoever is silent dissents. | Silicon Graphics, Inc.
Maria Isabel Barreno | olson@sgi.com
-----------[000121][next][prev][last][first]---------------------------------------------------- Date: 10 Jan 93 09:16:04 GMT From: paul@frcs.Alt.ZA (Paul Nash) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.sysv386 Subject: Unix drivers for TIARA LE16 ethernet adapters?
I am looking for updated Xenix drivers and SCO Unix drivers for Tiara LE16 ethernet cards. The card came with a slightly shakey Xenix driver, and instructions to call the Tiara BBS (415-966-8533), which seems to have died the death. Does anyone know of FTP-able Tiara drivers for Xenix, SCO Unix or even Intel's sVr4? I have the latest DOS packet drivers, but can't afford to buy a few SMC cards right now :-(. Any pointers will be most gratefully appreciated. ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=--- Paul Nash paul@frcs.Alt.ZA Box 12475, Onderstepoort, 0110 South Africa +27-12-5611879 "Standards are great -- everyone should have one" (Kent Landfield)
-----------[000122][next][prev][last][first]---------------------------------------------------- Date: Sun, 10 Jan 1993 10:06:58 GMT From: skl@wimsey.bc.ca (Samuel Lam) To: comp.protocols.tcp-ip Subject: Re: MORE ON TOOLS TO FIND ROUTING TABLES OF REM
In article <1993Jan6.211340.13111@colorado.edu>, garnett@refuge.Colorado.EDU (Santiago de la Paz) wrote: >The only way to really make sure of what advertisements a gateway makes is >to sit and listen for them, e.g. with gated tracing turned on or some >handmade NIT utility. You could also use "tcpdump" to show what's coming in on the UDP RIP port. In any case, passive monitoring only works if you are on the same network as the source. ...Sam -- <skl@wimsey.bc.ca> -- Connectivity Technology Inc.
-----------[000123][next][prev][last][first]---------------------------------------------------- Date: Sun, 10 Jan 1993 14:22:47 GMT From: jp@tygra.Michigan.COM (John Palmer) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
In article <C0JL0L.HEx@news.rn.com> larry@news.rn.com (Larry Snyder) writes: "karl@ddsw1.mcs.com (Karl Denninger) writes: " ">>>Can the NB support 2 56700 baud modems going full blast on the ">>>stock 2 serial ports on the motherboard? ">> ">>try pulling the case off and seeing of the UARTs are 16550's. ">> ">>i would suspect so. " ">They certainly are. (I have examined lots of these) " "So one can assume they support the FIFO to get those speeds. " The best bet in using the Netblazer for dialup IP is to ignore the first two ports as they are built into the board and are standard AT serial ports. The 8-port cards are Digiboard PC/8e's. You can take one out of the box and plug it into your Netblazer and it will work fine. There are instructions in the Netblazer manual on how to set the dip switches. -- Its most likely a | E-MAIL: jp@michigan.com CAT-TALK IS BACK as a FREE forgery, so save your | SYSTEM!! 313-882-2209 300-14400 V.32/V.32BIS/TurboPEP flames for someone | Anon-UUCP: System: tygra, Login: nuucp, no pw who cares :-> | Get file "/cat/pub/filelist" for a list of files.
-----------[000124][next][prev][last][first]---------------------------------------------------- Date: Sun, 10 Jan 1993 15:16:33 GMT From: wmchung@ie.cuhk.hk (chung wai man) To: comp.protocols.tcp-ip Subject: About image transmission protocol
Hello! I wonder if there is any popular image transmission protocol (like ftp for file transfer). If so, what are they? And, is there any document on those protocols? Thanks! Please mail reply to: wmchung@eng.ie.cuhk.hk Best Regards, W.M. Chung
-----------[000125][next][prev][last][first]---------------------------------------------------- Date: 10 Jan 93 17:01:58 GMT From: trier@odin.ins.cwru.edu (Stephen C. Trier) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: TELNET terminal types
One solution is to modify the termcap or terminfo files, as appropriate for the system, to accept dec-vt100 as a synonym for vt100. The solution used by NCSA Telnet (or was it CUTCP?) was to make the terminal name user-configurable. The final option (really klugey) is to assume your telnet was written in C and use a hex editor to search for and change "DEC-VT100\0" to "vt100\0\0\0\0\0". (\0 represents a NUL, an 00 byte.) I strongly recommend the first option, since one should always prefer making a system RFC compliant over making its peer non-compliant. The third option should be used only as your last resort, and you should check your license to make sure it's legally OK before doing it. -- Stephen Trier "We want to offer you a price that you Network software type just can't afford to take advantage of." Case Western Reserve University - Sales blurb from HSC Software trier@ins.cwru.edu
-----------[000126][next][prev][last][first]---------------------------------------------------- Date: 10 Jan 93 17:10:18 GMT From: jgm+@CMU.EDU (John Gardiner Myers) To: comp.mail.sendmail,comp.protocols.tcp-ip,comp.mail.headers Subject: Re: discrepancies between RFC821 and RFC822 (as amended by RFC1123) regarding Received headers
bruce@blilly.uucp (Bruce Lilly) writes: > 1) RFC821 section 4.1.1 requires the "from" and "by" clauses, while > RFC822 4.1 lists them as optional. [...] > so if a message which arrives at an > Internet site via some mechanism other than SMTP contains an RFC822 > Received header without a "from" or a "by" clause (or without both), > it is a technical violation of either RFC821 or RFC1123 to transmit > the message via SMTP to another Internet site I disagree. RFC 821 specifies the grammar of the time stamp line a server must insert at the beginning of the mail data (4.1.1.DATA). I see no prohibition in RFC 821 against transmitting a message already containing Recieved: headers that do not match the <time-stamp-line> grammar. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
-----------[000127][next][prev][last][first]---------------------------------------------------- Date: Sun, 10 Jan 1993 22:48:44 GMT From: duncan@comp.vuw.ac.nz (Duncan McEwan) To: comp.protocols.tcp-ip Subject: Re: time outs in FIN-WAIT2??
In article <1993Jan9.164215.20972@jupiter.sun.csd.unb.ca> dedgar@mta.ca writes: > >I interpret this problem to mean that the other side has timed out or retried >out in fin-wait2. Is this a valid assumption. Does tcp-ip software do this? I'm not sure if this is what you are seeing, but pg 365 of "The Design and Implementation of the 4.3BSD UNIX Operating System", describes how 4.3 BSD also starts the 2*MSL timer when in FIN_WAIT_2 state if the local process has closed. >It sure isn't in the rfc. It claims this is done as a work around because "certain other TCP implementations (incorrectly) fail to send a FIN on a receive-only connection. Connections to such hosts will remain in FIN_WAIT_2 state forever unless the system times them out". Duncan
-----------[000128][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Jan 1993 10:29:26 -0500 From: "Alex R.N. Wetmore" <aw2t+@andrew.cmu.edu> To: comp.protocols.tcp-ip Subject: call routine when packet arrives?
I was wondering if there is any way to have standard bsd sockets automatically call a routine when a packet arrives (sort of like what signal() does for signals). Basically, I have a program that isn't event driven, but I would like for it to be able to get interrupted when certain packets arrive (it is for a bbs, and I need to use it for system messages, talk pages, etc). I used to implement them using signals, but since I am moving to a client/server model, and the client can be on a different machine, I can't use signals anymore. Otherwise, I could implement the packet waiting routine in where the program waits for keystrokes, but I don't see a way of doing that without polling (which means high cpu usage). any ideas? alex
-----------[000129][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Jan 1993 02:25:32 GMT From: dls@mentor.cc.purdue.edu (David L Stevens) To: comp.protocols.tcp-ip Subject: Re: time outs in FIN-WAIT2??
In article <C0nu19.8z7@comp.vuw.ac.nz>, duncan@comp.vuw.ac.nz (Duncan McEwan) writes: .... > It claims this is done as a work around because "certain other TCP > implementations (incorrectly) fail to send a FIN on a receive-only connection. > Connections to such hosts will remain in FIN_WAIT_2 state forever unless the > system times them out". It's actually worse than that, in that it doesn't require a non- conforming TCP to break things. When you're in FIN_WAIT_2, all data you've sent has been acknowledged and the user has already done a close(). All you're waiting for is the FIN from the other side. If the other machine crashes, there isn't anything to cause you to delete the entry or ever resend another packet, so the TCB will hang around forever. In old 4.2 BSD implementations, these used to collect until a reboot was required to get back the resources they were holding. Adding the timer prevents that, but has its own problems. Having a timer, but a long one, is a compromise. Our Berkeley derivatives timeout after 30 minutes, which is probably long enough; the #define is still named "TCPT_2MSL" (RFC 793 says 2MSL'd be 4 minutes). If I remember right, the original poster said 10 seconds-- a good implementation will restart the TIME_WAIT timer each time it receives a segment, so it really is timing the "dead interval" when the other side may have crashed. Fixing that (or asking the vendor to) may be the solution. -- +-DLS (dls@mentor.cc.purdue.edu)
-----------[000130][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 93 03:23:35 GMT From: vances@xenitec.on.ca (Vance Shipley) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
In article <1993Jan10.142249.5913jp@tygra.Michigan.COM> jp@tygra.Michigan.COM (John Palmer) writes: > >The best bet in using the Netblazer for dialup IP is to ignore the first >two ports as they are built into the board and are standard AT serial >ports. The 8-port cards are Digiboard PC/8e's. You can take one out of >the box and plug it into your Netblazer and it will work fine. There are >instructions in the Netblazer manual on how to set the dip switches. Is there any way to put a DigiBoard PC/8e in a KA9Q NOS box? -- Vance Shipley vances@xenitec.on.ca vances@switchview.com vances@ltg.uucp
-----------[000131][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Jan 1993 03:32:38 GMT From: karl@ddsw1.mcs.com (Karl Denninger) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
In article <1993Jan10.142249.5913jp@tygra.Michigan.COM> jp@tygra.Michigan.COM (John Palmer) writes: >In article <C0JL0L.HEx@news.rn.com> larry@news.rn.com (Larry Snyder) writes: >"karl@ddsw1.mcs.com (Karl Denninger) writes: >" >">>>Can the NB support 2 56700 baud modems going full blast on the >">>>stock 2 serial ports on the motherboard? >">> >">>try pulling the case off and seeing of the UARTs are 16550's. >">> >">>i would suspect so. >" >">They certainly are. (I have examined lots of these) >" >"So one can assume they support the FIFO to get those speeds. > >The best bet in using the Netblazer for dialup IP is to ignore the first >two ports as they are built into the board and are standard AT serial >ports. The 8-port cards are Digiboard PC/8e's. You can take one out of >the box and plug it into your Netblazer and it will work fine. There are >instructions in the Netblazer manual on how to set the dip switches. JP is back! Heh John, that's damn funny you know..... I have this NetBlazer Classic sitting right here in front of me with the cover off it..... It has ------- a SERIAL BOARD in it with two 16550s in it! BE CAREFUL with those Digiboards. The PC/8e is available in more than one version. The ones used in the Netblazer run a different clock rate (12.5Mhz vs 8Mhz normally) and have some other upgraded components. Attempting to use a standard Digiboard >might< work, but it might also not, especially at higher baud rates (57600 bps comes to mind). (I've used more than 200 of the "classic" models, and a few of the STs. The ST is a nice box, but doesn't have enough slots ;-) -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Data Line: [+1 312 248-0900]
-----------[000132][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Jan 1993 05:15:11 GMT From: larry@news.rn.com (Larry Snyder) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
karl@ddsw1.mcs.com (Karl Denninger) writes: >It has ------- a SERIAL BOARD in it with two 16550s in it! Ok, so my question is answered. Thanks -- is that Netblazer going on ddsw1 (some of your users mentioned that ddsw1 should be on the internet "real soon now")? >(I've used more than 200 of the "classic" models, and a few of the STs. The >ST is a nice box, but doesn't have enough slots ;-) I don't know the difference between the classic and st. What is it? Also, is it possible to put a v.35 board in a machine running Dell 2.2 and do the routing under Unix? -- Larry Snyder internet: larry@gator.use.com keeper of the Gator uucp: uunet!gator!larry
-----------[000133][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Jan 1993 16:30:40 -0500 From: Tod McQuillin <tm8t+@andrew.cmu.edu> To: comp.protocols.tcp-ip Subject: Re: call routine when packet arrives?
"Alex R.N. Wetmore" <aw2t+@andrew.cmu.edu> writes: > I was wondering if there is any way to have standard bsd sockets > automatically call a routine when a packet arrives (sort of like what > signal() does for signals). Basically, I have a program that isn't > event driven, but I would like for it to be able to get interrupted when > certain packets arrive (it is for a bbs, and I need to use it for system > messages, talk pages, etc). I used to implement them using signals, but > since I am moving to a client/server model, and the client can be on a > different machine, I can't use signals anymore. Sure. Use asynchronous I/O. You'll want to use int yes=1; fcntl(s, F_SETFL, FASYNC); Then enable a signal handler for SIGIO. signal(SIGIO, handler); > Otherwise, I could implement the packet waiting routine in where the > program waits for keystrokes, but I don't see a way of doing that > without polling (which means high cpu usage). You could do it this way too. Use the select(2) system call instead of polling. Both these techniqies are well explained in Richard Stevens' book, "Unix Network Programming," which I highly recommend.
-----------[000134][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Jan 1993 09:56:34 GMT From: Jan.vOorschot@dnpap.et.tudelft.nl (Jan van Oorschot) To: comp.protocols.snmp,comp.os.os2.networking,comp.os.os2.apps,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: New Beholder and Tricklet, RMON and SNMP software for OS/2 and UNIX
Beholder, The Next Generation (bntg) 8 january 1992 The btng package is the result of the latest work done by the DNPAP group of the Delft University of Technology. The btng package includes beholder.exe, an RMON compliant ethernet monitor for the OS/2 operating system environment. It also includes the Tricklet package for OS/2 and UNIX. Tricklet is a set of SNMP utilities, including a full featured Perl interface. The OS/2 executables and documentation of btng and Tricklet version 2 can be found in: btng2exe.zip The full source of the monitor and the Tricklet utilities are in: btng2scr.zip The sources of the Tricklet utilities to be used on UNIX platforms are in: trcklt2.tar.Z trcklt2.zip OS/2 ---- You will need the following to run the OS/2 executables: - PC with a running OS/2 1.x or 2.x - ethernet network adapter - NDIS protocol stack - optional TCP/IP 1.2 from IBM for OS/2 (only used by Tricklet) UNIX ---- On a UNIX platform you will need an ANSI C compiler and a TCP/IP stack with socket interface. OS/2 development ---------------- To compile the OS/2 software, you will need: - microsoft C compiler 6.0 (last one with OS/2 support, thanx microsoft) - IBM's OS2 toolkit for OS/2 1.3 - IBM's TCP/IP 1.2 kit MISC ---- - btng is distributed with source code - we don't ask for much, just acknowledgement of our work, bug-reports, suggestions etc. - the software can be obtained using anonymous ftp to dnpap.et.tudelft.nl. Get the following files: pub/btng/btng2exe.zip # executables pub/btng/btng2src.zip # full source pub/btng/trcklt2.zip # UNIX source of Tricklet pub/btng/trcklt2.tar.Z # utils. pub/btng/perl4019.zip # OS/2 1.3 perl pub/btng/perl4035.zip # OS/2 2.0 perl pub/btng/unz50x16.exe # OS/2 [12].x unzip you can also mail to our mailserver mailserver@dnpap.et.tudelft.nl Now the bad news: - btng2 is the first (beta-like) version that hits the public streets. There will be problems/bugs. - it is a very advanced piece of software, and you can do a lot of things wrong. - there is documentation, but no introduction for the use of SNMP and RMON monitors. We wrote this software to experiment with network managament, SNMP, and RMON. Although the software conforms to all these standards, it is should not be confused with commercial products. We don't give support, and don't ask for money and licence fees. So use it to experiment with network management, in non-critical network environments. If you are using the btng software, you are advised to join our mailing list. btng@dnpap.et.tudelft.nl --> mailing list btng-request@dnpap.et.tudelft.nl --> subscribtions/unsubscr. You can also have a look at our gopher server at dnpap.et.tudelft.nl port 70 Carpe Diem, Jan -- Ir. Jan van Oorschot. --- Email: Jan.vOorschot@dnpap.et.tudelft.nl -- -- Data Network Performance Analysis Project -- -- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 -- -- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --
-----------[000135][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 93 13:47:51 GMT From: dos@major.panix.com (Dave O'Shea) To: comp.protocols.tcp-ip Subject: Address conversion
I've got the enviable task of connecting together two networks that were designed separately. One is on the internet, so they've kept their addressing clean and up to specs, but the other one is a small stand-alone network that has its own rather unique addressing scheme. Changing the addresses on the network is not really an option; the app they have is hard-coded to look for certain addresses, and rewriting it would be more troublesome than it's worth. What I'm looking for is something along the lines of a router than could hold an address translation table (which would, of course, have to be generated by hand, but that's no problem), and convert addresses going in both directions. As this will be used to pass only some SNMP traffic, performance isn't an issue; 50-100 packets/second would be more than sufficient. Does anyone know if such an animal exists? I've heard of folks doing something along these lines with what they called a gateway, but I've been unable to trace down any commercial source for a product such as this.
-----------[000136][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Jan 1993 14:55:19 GMT From: beaulieu@bose.com (Larry Beaulieu) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
I don't know the difference between the classic and st. What is it? The ST uses a 4" high PC case and has only 3 horizontal ISA slots vs the more conventional configuration of the classic. Except for the limited expandability of the ST the 2 are functionally identical. -- -- Larry Beaulieu beaulieu@bose.com Bose Corporation Phone: 508-879-1916 x6479 Framingham, MA 01701-9168 FAX: 508-820-4865 All flames gleefully ignored.
-----------[000137][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Jan 1993 15:15:39 GMT From: stein@itek.norut.no (Stein Olav Toennessen) To: comp.protocols.tcp-ip Subject: Source routing of "raw-IP" packets.
I'am looking for simple programs which use "loose source routing" in order to spesify a route of internet-addresses which raw-ip packets has to visit. I have tried to implement some code which do this, on a decstation runing ultrix 4.2a, using BSD-sockets without sucess so far. Has somone done this before using raw BSD-sockets? If so how did you do it? Is there other ways to spesify addresses which datagrams have to visit before delivery at destination? (other then loose and strict source-routing) If so, can the source-address and destination-address be the same ? Please reply to me directly !! __________________________________________________________________________ Stein Olav Toennessen Phone: +47 83 80150, Fax: +478382420 FORUT IT AS NORUT-Gruppen AS N-9005 Tromsoe, Norway E-mail: stein-olav.tonnessen@itek.norut.no --------------------------------------------------------------------------
-----------[000138][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Jan 93 15:53:39 GMT From: bruce@sonyd1.Broadcast.Sony.COM (Bruce Lilly) To: comp.mail.sendmail,comp.protocols.tcp-ip,comp.mail.headers Subject: Re: discrepancies between RFC821 and RFC822 (as amended by RFC1123) regarding Received headers
In article <gfICIOa00WBwQPAmVQ@andrew.cmu.edu>,
posted to comp.mail.sendmail,comp.protocols.tcp-ip,comp.mail.headers,
jgm+@CMU.EDU (John Gardiner Myers) wrote:
>
>I disagree. RFC 821 specifies the grammar of the time stamp line a
>server must insert at the beginning of the mail data (4.1.1.DATA). I
>see no prohibition in RFC 821 against transmitting a message already
>containing Recieved: headers that do not match the <time-stamp-line>
>grammar.
The section you mentioned explicitly states ``Relayed messages will have
multiple time stamp lines.'' The syntax for the time stamp (Received) lines
*requires* the "from" and "by" clauses. No exceptions are stated. Note that
example 8 in RFC821 shows "from" and "by" clauses in all Received headers,
not only the first one.
I suppose one could claim that Received headers without the "from"
and/or "by" clauses aren't RFC821 time-stamp lines, but are mere ordinary
RFC822 headers. Note that RFC821 states ``that the final mail data will
begin with a return path line, followed by one or more time stamp lines.
These lines will be followed by the mail data header and body''. If some
Received headers are to be considered non-time-stamps, then it will be
necessary to reorder the Received headers so that the ones which are also
time-stamp-lines are placed before the non-time-stamp lines. I feel that this
would hamper debugging, as the order of Received headers would not then
correspond to the delivery path.
I still think this area needs some clarification. For reasons mentioned in
my original article, I would like to see at least the "by" clause made
mandatory.
--
Bruce Lilly, Product Manager, |
Routers, Peripherals & Still Store,| uupsi!monymsys!sonyd1!bruce
Sony, 3 Paragon Drive, Montvale, | lilb@sony.compuserve.com
NJ 07645-1735 | Telephone: +1 201 358 4161 | FAX: +1 201 358 4274
-----------[000139][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 93 15:53:49 GMT From: barnett@grymoire.crd.ge.com (Bruce Barnett) To: comp.protocols.tcp-ip Subject: Re: reading what you're writing on Suns
The Berkeley Packet Filter, if installed in the kernel, does allow etherfind/tcpdump to "see" packets transmitted. There is source and binary available for some systems, but I have not been able to get it working on SunOS - ( I didn't try too hard). The sources of BPF are included in the sources of tcpdump found on ftp.ee.lbl.gov:tcpdump.tar.Z -- Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
-----------[000140][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 1993 16:52:01 GMT From: berg@physik.tu-muenchen.de (Stephen R. van den Berg) To: comp.sys.sun.admin,comp.protocols.tcp-ip Subject: Re: SLIP on a SUN?
In article <1993Jan8.142323.28975@fripp.ri.cadre.com> jh@cadre.com writes:
>In article EAC@csn.org, bhays@teal.csn.org (Boyd Hays) writes:
>>Hello,
>> I need to put SLIP up on a SUN IPC running 4.1.2. Is there a general
>> concensus as to which version is "best". I'm anticipating putting up
>> cslip-2.6.
>I'm currently looking at setting up a SLIP connection as well. I got a
>version of cslip off the net, although it was not the latest version. It
>had almost nothing in the way of documentation, and I didn't get it to
>install properly. I then tried a copy of MorningStar's PPP with cslip
>that we had in-house. It installed fairly easily, and seems to work fine.
>I'm going to get the new cslip today, but if it's as cryptic as the old one,
>MorningStar's going to have a new customer.
The cslip-2.6 is heartily recommended. Apart from a slightly awkward Makefile
it runs and installs like a charm.
The install docs are correct.
--
Sincerely, berg@pool.informatik.rwth-aachen.de
Stephen R. van den Berg (AKA BuGless). berg@physik.tu-muenchen.de
"Be spontaneous!"
-----------[000141][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Jan 1993 18:00:37 GMT From: martin@datacomm.ucc.okstate.edu (Martin McCormick) To: comp.protocols.tcp-ip Subject: Re: Using RARP for Greater Security
I want to sincerely thank all who answered my questions about using RARP. Here is what you had to say. Quoted material follows: From: Tony Li <tli@cisco.com> Subject: Re: Using RARP for Greater Security Disable ARP on the router attached to that interface. Add static ARP entries. Filter traffic that comes out of that interface. Tony From: Lyndon Nerenberg <Lyndon.Nerenberg@unbc.edu> Subject: Re: Using RARP for Greater Security Our plan is to install Beame & Whiteside TCP on our PC's. B&W provides support for BOOTP. By replacing the ROMs in your Ethernet card you can boot the PC's from your file servers. Using BOOTP allows you to maintain a central database of Ethernet MAC to IP address mappings. They can't bugger with this short of replacing the ROM's. Send e-mail to sales@bws.com for further information. --lyndon From: Adrian Miranda <ade@vancouver.wsu.edu> Subject: Re: Using RARP for Greater Security Well, I think all programs will allow you to change your configuration, though most take a bit more effort than WINQVTNET apparently does. You could obtain the source for NCSA telnet, and recompile it to force it to use rarp or bootp, but a student could always get their own copy of telnet from the Internet and use that. As far as I can tell, there's no really foolproof way to prevent someone from choosing their own IP number. Would it be enough to just use something like NCSA which requires editing a file? The only other thing I can think of is to force your UNIX systems and Routers to use static arp table entries for the PC ethernet numbers. That is, you would tell the UNIX system that a particular ethernet number and IP number are associated. Then the system would presumably ignore attempts by another machine (with a different ethernet number) to pretend to have that same IP number. However, some ethernet cards allow you to modify their ethernet numbers, so even that's not foolproof. By the way, if you're looking at RARP, you should also look at Bootp. It's much more powerful. Adrian Miranda ade@clark.edu From: pcg@aberystwyth.ac.uk (Piercarlo Grandi) Subject: Using RARP for Greater Security The best one is to give up on such goals. Simply put, how are you going to make sure that a fun loving student does not load its very own little TCP/IP module on your dos machine? I always carry around with me a floppy with a bootable system including NOS, PC GOPHER and TRUMPET, just in case :-). It's practically impossible to stop people doing what they want with changing IP numbers, for example masquerading as any host they would like to pose (there are even some Ethernet cards which have programmable ethernet addresses). The only way out is cryptographic authentication. Kerberos...
-----------[000142][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 93 18:05:41 GMT From: jpc@avdms8.msfc.nasa.gov (J. Porter Clark) To: comp.protocols.tcp-ip Subject: Who used TNAMED (IEN-116) any more? And why?
I've noticed (via log_tcp) a few random connections from a couple of machines to the obsolete (or so I thought) IEN-116 trivial name service port. Jan 11 09:42:01 avdms8 in.tnamed[2874]: connect from ... At the time, I didn't have this service turned off, so I presume the machines in questions had a successful connect. Who would want to use trivial name service? Sun's man page for in.tnamed doesn't mention any clients which use this service. There is a nod in the direction of uucp in the SEE ALSO area, but the man page it refers to doesn't mention any sort of name service. Is there a client program to access this service? I'd be interested in seeing what these machines got from me, if anything. Yes, I plan to ask the owners of these machines what they are doing. -- J. Porter Clark jpc@avdms8.msfc.nasa.gov or jpc@gaia.msfc.nasa.gov NASA/MSFC Flight Data Systems Branch
-----------[000143][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 93 21:06:20 GMT From: parsons@postmaster@hq.af.mil (Mike Parsons) To: comp.protocols.tcp-ip Subject: Encapsulation of or translation of DECNET on a TCP/IP backbone
-- Does anyone know of any methods to either convert DECNET to TCP/IP and back again or encapsulate DECNET within TCP/IP. I need to have two DEC sites communicate across a large packet-switched TCP/IP backbone. Unfortunately, it will be a somewhat unreliable network where network congestion and delay are prevalent. DECNET is a requirement because of the applications; TCP/IP is a requirement for the backbone since it's someone else's empire and corporate policy is to use the backbone. -------------------------------------------------------------------- | Mike Parsons 7CG HSRP PROGRAM | | parsons@nic.hq.af.mil | | 703-614-6121 | --------------------------------------------------------------------
-----------[000144][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 93 22:17:19 GMT From: imp@boulder.parcplace.com (Warner Losh) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: TELNET terminal types
In article <jcmorris.726603002@mwunix> jcmorris@mwunix.mitre.org (Joe Morris) writes: > In particular, in the terminal-type options >negotiation (per RFC 1091) the Wollongong product is delivering the text >string: > > DEC-VT100 This is a conforming implementation. >The trouble is that none of our UNIX boxes (typically running SUN-OS, >IBM's AIX (RS-6000), or Silicon Graphics' IRIX) have the faintest >idea what to do with this terminal type; their terminfo files expect >something like "vt100". One problem is that RFC 1060 does not include >any terminal types of the form "VTxxx". This is not a conforming implementation. >So...any comments? Is Wollongong alone in adhering to RFC 1060, or do >the UNIX vendors say "RFC's aren't legal standards", or have I missed >some obvious point here? I've seen other things that adhere to the RFC 1060 standards wrt terminal type. I think that Multinet does as does the TOPS-20 implementation, but I could be wrong on either of these. All that the unix telnet client is doing is pushing across the wire the setting of TERM. There is no attempt to map terminals into the "standard" types and then back again. In fact, I use this trick to push across DISPLAY and terminal size information to less than robust implementations of telnet (that do do terminal type stuff). Your best bet would be to create aliases for DEC-VTxxx in the termcap and terminfo databases. This is a kludge, at best, but would solve the problem of telnetting to the unix box from the PC. Warner -- Warner Losh imp@boulder.parcplace.COM ParcPlace Boulder I've almost finished my brute force solution to subtlety.
-----------[000145][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 93 23:01:07 GMT From: mark@verdix.com (Mark Lundquist) To: comp.protocols.tcp-ip Subject: Re: Why would a Sun take 1.5 seconds to retransmit a missed packet?
In article <930108124846@cream.ftp.com> jbvb@ftp.com writes:
>In article <184841@pyramid.pyramid.com> lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:
In article <BARNETT.93Jan7091846@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes:
>Packets are missed by the archive system, so the Sun has to retransmit
>the missed packets. I have noticed large delays (0.5 - 1.5 seconds)
Those are pretty typical numbers for TCP layer time-outs...
>If so, it indicates that 1) the path is long, 2) the archive system is very
slow or 3) the sending TCP has an inferior or broken adaptive retransmit
algorithm. TCP should retransmit in something on the order of twice the
average Round Trip Time (from send to ack).
The granularity of the per-TCB timers (retransmit, RTT, etc.) on
BSD-derived systems is 500ms.
-----------[000146][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Jan 1993 23:56:19 GMT From: mlewis@telebit.com (Mark S. Lewis) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
> mlewis@telebit.com (Mark S. Lewis) writes: >>> I currently attach via SLIP over a leased line using v.32bis/v.42bis >>> modems from a Dell machine (on my end) into a smartport on a Telebit Netblazer. >>> Would I see any significant increase in throughput using this same >>> physical connection (v.32bis/v.42bis) but replacing the Dell SLIP >>> with a Netblazer on my end -- and connecting my machines via ethernet >>> to the Netblazer? >>> [...] >>> Larry Snyder internet: larry@gator.rn.com >> >>No I don't think you would get a significant performance increase by >>putting a NetBlazer at both ends. You are using relatively slow >>serial lines limited by V.32bis modulation with whatever compression >>you get with V.42bis. >> >>Mark S. Lewis inet: mlewis@telebit.com > I disagree. I think you will get some increase in preformance, depending > on how loaded your box that is doing the routing is. Routing IP packets > takes a certain amount of CPU over head as well as servicing the serial > line interupts that happen every time you get a packet in. Using 16500 > helps. I suppose it is possible to improve performance by shifting the burden of routing to the NetBlazer, 386BSD or whatever. Depends on the routing effeciency of the original system. Also, the NetBlazer typically drives modems at 57600, while many Unix based SLIP connections can reliably support only 19200. In this case, a NetBlazer or dedicated SLIP solution may help. > A side note. Netblazer software was based on the KA9Q software. Enough > work has gone into it by now that I imagine that it doesn't look like KA9Q > any more, but I wonder if it still has the same problems that KA9Q has, > like memory leakage and high latency. Perhaps Mark could comment on the > Netblazer software. As for memory leakage, we have come quite a ways. We have made numerous improvements to the memory allocation to help us find leaks. At this point, there are only a few rare leaks. In general, the NetBlazer will stay up for months. As for latency, I am not sure to which latency you refer. What type of connections are you assuming, async dial-up? Are you talking about round trip ping time? Note that modems introduce significant latency. > At the last ONEBBS con in Denver, there was a demonstration of a device > called "Slip-on-a-Stick". It was a box that was about 10"x6"x2" tall, and > would do slip. I don't know if it will do the right thing with subnetting > as I only saw it work with one device on it. The price was less than a > grand. I like that - "Slip-on-a-Stick." Sound like the next taste sensation :-) Note that I know of several vendors that are developing such dedicated networking serial devices. It will be interesting to see what comes down the pike. > Tim > -- > Internet: pozar@kumr.lns.com FidoNet: Tim Pozar @ 1:125/555 > Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA > Voice: +1 415 788 2022 KKSF is my favorite jazz station. You guys play the tastiest jazz in the bay area. Thanks for the good programming. ... Mark =========----------- Mark S. Lewis -----------========== inet: mlewis@telebit.com Telebit Corp. Telebit (408) 745-3232 uucp: uunet!telebit!mlewis Fax (408) 745-3810
-----------[000147][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 1993 23:58:41 GMT From: mogul@pa.dec.com (Jeffrey Mogul) To: comp.protocols.tcp-ip Subject: Re: reading what you're writing on Suns
In article <21102@ucdavis.ucdavis.edu> heberlei@cs.ucdavis.edu writes: >I have found while using ethernet analyzers on Sun workstations >that they do not report the packets from the same host that they >are running on. >Apparently a Sun cannot read the packets that it is writing to >the network. I have two questions regarding this: > 1) Is this common with most/all workstations (non-Suns)? Recent versions of ULTRIX provide a mechanism for applications (such as tcpdump and nfswatch) to see all packets to/from the host they are running on. On ULTRIX: "man packetfilter" and look for the string ENCOPYALL. It took us a few tries to get this correctly implemented, so before ULTRIX 4.3 there might be some related bugs. Recent releases of tcpdump and nfswatch, including the versions that are shipped with ULTRIX, use this mechanism. The latest version of NNstat (v3.2) does not, but last week I made the appropriate (1-word) patch. -Jeff
-----------[000148][next][prev][last][first]---------------------------------------------------- Date: 12 Jan 1993 08:45:31 -0500 From: drj@dev-null.phys.psu.edu (Dan Jeuch) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: TCP/IP between PCs and 3B2s
I've got an interesting project to tackle. I need to network an AT&T 3B2 with a couple of IBM PCs.... preferably with minimal equipment cost. The PCs are currently equiped with Lantastic ethernet cards, but the cards are supposedly compatable with Novell NE2000 cards, but I have no way of verifying this. Has anyone attempted/been sucessful in doing this? Any suggestions for software, or general advice would be greatly appreciated! Please e-mail responses. If there is a general interest, I can always post a summary. -Dan
-----------[000149][next][prev][last][first]---------------------------------------------------- Date: 12 Jan 93 00:38:54 GMT From: pccl@cbnewsd.cb.att.com (paul.c.liu) To: comp.sys.sun.apps,comp.protocols.tcp-ip Subject: tcp_mss "downshift" with consecutive rcp's
A while ago, I recall a netter from SGI posted an article detailing a BSD TCP bug fix for the tcp_mss "downshift" symptom. Symptom: consecutive "rcp remhost:remfil locfil" will result in smaller TCP payload (i.e. from 1460-byte to 512-byte), unless there is 60+ seconds time gap in between. To reproduce: use three Suns, on sun_a, do rcp sun_b:file1 file1, and rcp sun_b:file2 file2 and run tcpdump/etherfind on sun_c to trace the network traffic. Pointers are appreciated! Paul.C.Liu@ATT.COM
-----------[000150][next][prev][last][first]---------------------------------------------------- Date: 12 Jan 93 01:12:46 GMT From: guy@Auspex.COM (Guy Harris) To: comp.protocols.tcp-ip Subject: Re: reading what you're writing on Suns
> 2) Is there a patch so the Sun can read it's own packets? This is fixed in SunOS 5.x; if a device is in promiscuous mode, the datalink drivers will wrap packets around to all open streams attached to that device that have "physical-level promiscuous enabled" (I assume this means that individual streams can request to hear everything or not to hear everything). And, yes, "streams" refers to STREAMS; I *did* say "SunOS 5.x"....
-----------[000151][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Jan 1993 03:15:12 GMT From: tclark@med.unc.edu (Thomas B. Clark III) To: comp.protocols.tcp-ip Subject: Setting date and time on PC
Does anyone have any experience setting the PC's date and time from a UNIX time server using tcp/ip?
-----------[000152][next][prev][last][first]---------------------------------------------------- Date: 12 Jan 93 04:37:49 GMT From: jkreznar@ininx.UUCP (John E. Kreznar) To: comp.mail.misc,comp.protocols.tcp-ip Subject: SLIP (or PPP) versus ``dumb terminal'' network connections
I plan to change my network connection. Please help me decide how.
I don't know that the groups I've selected for this posting are
appropriate. If not, please steer me to the right place.
Is there a faq I should read?
Please respond by email. I don't read these groups.
I am trying to decide what kind of network connection I should seek.
I have been a satisfied user of UUNET for years, but I believe that I
can now get service better matched to my needs and at lower cost. I
am a single-user site A and seek dial-up connection through a local
Internet node B which might be commercial server or a university. I
can think of two kinds of connection:
Terminal. A appears to B as a ``dumb terminal''. A has a
user account on B and must log in after calling.
SLIP (or PPP). At least for the duration of the dial-up
connection, A is a full-fledged node on the Internet.
Are there others I should consider?
Based on a few impressions I've picked up, a terminal connection can
be lots less expensive than a SLIP connection. One thing I'm trying
to do is clearly identify what I'd get for the extra cost of SLIP. So
I compare the connection modes in their support of various network
services:
email
news
ftp
archie, gopher, etc.
In the following, I describe _my understanding_ of how these services
work in the two cases. My main question is whether my understanding
is accurate and doesn't overlook important issues.
email.
Whether A is a terminal or has a SLIP connection, incoming email is
queued at B until a connection is made. If A is a terminal, the queue
is A's user mailbox and A empties it by reading it, perhaps with the
help of a mail-reading utility. On the other hand, if A connects
using SLIP, the queue is just another part of network traffic destined
for A which will be automatically transmitted when the connection is
made. The mail then moves to a user mailbox at A, but since A has but
one user, this queue contains all email originally present in the SLIP
queue. The volume of traffic over the dial-up connection doesn't
differ very much between the two cases.
There's the issue of what email addresses are possible in the two
cases. With SLIP, A can retain its registered domain address and B's
address or identity need not be apparent in A's address. As a dial-up
terminal, this may not be possible.
news.
Let's say that B is a major site that takes all of the news. If A
connects as a dial-up terminal, the user at A can browse any of the
news. The news is left undisturbed at B, although A may of course
capture to its own local files as it browses. If the connection is by
SLIP on the other hand, site A must subscribe to the news groups it
wishes to see, this news and none other is automatically transmitted
to A's site when the connection is made, and I don't know if A could
readily browse news to which it does not subscribe.
ftp.
With SLIP, A is a full-fledged node on the Internet and can browse
directories and files anywhere else on the Internet in real time,
capturing files at will. The same is true for the terminal case,
except that the ``capture'' is to a file at B, not A, and A would have
to do another step to get it further transmitted to A.
archie, gopher, etc.
These search tools seem to be equally available, whether as a dial-up
terminal or through SLIP.
--
Relations among people to be by mutual consent, or not at all.
---John E. Kreznar, jkreznar@ininx.com, uunet!ininx!jkreznar
-----------[000153][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Jan 1993 05:44:03 GMT From: pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: TELNET terminal types
In article <jcmorris.726695948@mwunix>, jcmorris@mwunix.mitre.org (Joe Morris) writes: > trier@odin.ins.cwru.edu (Stephen C. Trier) writes: > > >One solution is to modify the termcap or terminfo files, as appropriate for > >the system, to accept dec-vt100 as a synonym for vt100. > > [other options suggested] > > >I strongly recommend the first option, since one should always prefer making > >a system RFC compliant over making its peer non-compliant. > > I fully agree with this statement, but... > > The trouble is that we have several hundred hosts, few of which are under > the control of the central DP operations. What I would like to see is > fixes to the default termcap/terminfo tables to be issued by all the > UNIX vendors to make their systems RFC-compliant. > > To me, the strangest thing about this is that I can't find anything to > suggest that the issue has been previously raised. Perhaps the proper > solution is to re-open the "Assigned Numbers" list and update it to > reflect industry practice, but until either the UNIX systems are changed > or I can convince Wollongong to change, I've got a problem. > > Joe Morris / MITRE The issue is raised periodically - I believe I posted much the same beef about 6 months ago, about adding the Telnet termtypes into the terminfo/termcap files for standard releases. It doesn't do much good though - users still have to patch their own files. sigh - maybe one day. This was after wrestling with a box which 'required' telnet term-type negotiation before it would negotiate _anything_ else - and if the client refused to negotiate termtype, the link would be left hanging, the box would acknowledge but not act on any data or commands sent - this from a very well known firm with a TLA for a name. Sigh. Paul Brooks |Internet: pwb@newt.phys.unsw.edu.au Uni. of N.S.W. | paul@abccomp.oz.au Kensington NSW 2033| AUSTRALIA | Buy Australian
-----------[000154][next][prev][last][first]---------------------------------------------------- Date: 12 Jan 1993 06:21:14 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: Who used TNAMED (IEN-116) any more? And why?
In article <jpc.726775541@avdms8.msfc.nasa.gov> jpc@avdms8.msfc.nasa.gov (J. Porter Clark) writes:
>Who would want to use trivial name service?
Our 6-year-old Bridge terminal concentrators use it.
--
Barry Margolin
System Manager, Thinking Machines Corp.
barmar@think.com {uunet,harvard}!think!barmar
-----------[000155][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Jan 1993 12:51:00 From: jbvb@vax.ftp.com (James B. VanBokkelen) To: comp.protocols.tcp-ip Subject: Re: Setting date and time on PC
In article <1993Jan12.031512.16593@samba.oit.unc.edu> tclark@med.unc.edu (Thomas B. Clark III) writes:
Does anyone have any experience setting the PC's date and time
from a UNIX time server using tcp/ip?
A number of the PC TCP/IP packages (including ours) have clients for the
Time Protocol defined in RFC 868. Its accuracy is limited, but it seems
to be good enough for most DOS usages.
James B. VanBokkelen 2 High St., North Andover, MA 01845
FTP Software Inc. voice: (508) 685-4000 fax: (508) 794-4488
-----------[000156][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Jan 1993 12:51:38 From: jbvb@vax.ftp.com (James B. VanBokkelen) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: TELNET terminal types
In article <C0pn8v.Anq@boulder.parcplace.com> imp@boulder.parcplace.com (Warner Losh) writes:
In article <jcmorris.726603002@mwunix> jcmorris@mwunix.mitre.org (Joe
Morris) writes:
>So...any comments? Is Wollongong alone in adhering to RFC 1060, or do
>the UNIX vendors say "RFC's aren't legal standards", or have I missed
>some obvious point here?
I've seen other things that adhere to the RFC 1060 standards wrt
terminal type. I think that Multinet does as does the TOPS-20
implementation, but I could be wrong on either of these.
PC/TCP defaults to RFC 1060, but we let users configure their own
names if they choose. It would be nice if people paying for "support"
from the various Unix vendors submitted this problem as a bug - the
actual work of adding aliases wouldn't take them more than 1 day of a
junior engineer's time, and the Internet would become a *lot* better.
James B. VanBokkelen 2 High St., North Andover, MA 01845
FTP Software Inc. voice: (508) 685-4000 fax: (508) 794-4488
-----------[000157][next][prev][last][first]---------------------------------------------------- Date: 12 Jan 93 11:40:04 GMT From: svl@ktas.dk (Sven Larsen) To: comp.protocols.tcp-ip,comp.protocols.snmp Subject: source from "internetworking with TCP/IP" ?
HI! I'am looking for information on the SNMP software presented in the book "Internetworking With TCP/IP", vol II: Design, Implementation, and Internals. Written by Douglas E. Comer and David L. Stevens and published 1991 by Prentice-Hall Inc. If anybody knows the address of a ftp-server holding this software please let me know. My aim is to integrate/modify the client software part to handle the management of the MIB 1 objects in a CISCO router. Best regards Sven Larsen, KTAS, Denmark; svl@ktas.dk
-----------[000158][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Jan 1993 13:41:55 GMT From: rama@andy.bgsu.edu (Sub Ramakrishnan) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: IBM PC public domain TCP/IP, RPC stack
Hi, our PC will be connected to the ethernet backbone using a WD 8003 or something similar. I want to do some RPC programming on RPC. Two questions: (1) Are there any public domain TCP/IP stack for IBM-PCs? (2) Are there any public domain Sun RPC or equivalent for IBM-PCs? Thanks, ==sub -- Dr. Sub Ramakrishnan Internet: rama@truth.bgsu.edu Dept of Computer Science Bitnet: rama@bgsuopie Bowling Green State University Bowling Green, OH 43403 Voice: 419 372 2337. Fax:419 372 8061
-----------[000159][next][prev][last][first]---------------------------------------------------- Date: 12 Jan 93 14:11:06 GMT From: luc@asterix.drev.dnd.ca (Luc Lamontagne) To: comp.protocols.tcp-ip Subject: Both client and server?
Hi, I want two similar applications to communicate with each other. Can an application, based on RPC, be both client and server? How can it be done? Reply to luc@vela.drev.dnd.ca . -- | | DREV, Defence Research Establishment,Valcartier | | @asterix.drev.dnd.ca | POBox 8800, Courcelette,Quebec, CANADA, G0A 1R0 | | (131.132.48.2) | Office: (418) 844- fax (418) 844- | +---------------------------+-------------------------------------------------+
-----------[000160][next][prev][last][first]---------------------------------------------------- Date: 12 Jan 1993 16:47:19 GMT From: edvax@pyrite.som.cwru.edu (Ed Reznichenko) To: comp.protocols.nfs,comp.sys.sun.apps,comp.protocols.tcp-ip Subject: RPCGEN with inetd
The following is posted for a co-worker. Email responses to me, and I
will pass them along.
Thank you,
--ed
Internet: edvax@pyrite.som.cwru.edu
UUCP: uunet!pyrite.som.cwru.edu!edvax
----- begin included message -----
TOPIC: inetd rpc applications
HARDWARE: SPARC
OS: SunOS 4.1.1
Given that rpcgen -I fails to produce correct code for inetd-tcp-nowait
entries, does anyone happen to have tested server stubs used for
inetd-tcp-nowait entries that they would be willing to share?
Also, the last Stevens text on page 339 says that there are no 4.3BSD
inetd-tcp-wait flag applications. Does anyone know if this remains
true?
In order to simulate concurrent servers, we are considering defining
<n> inetd-tcp-wait servers with clients randomly selecting a server
with a uniform distribution, and hoping client time-outs are
sufficient to account for delays. Does anyone have opinions to offer
on this?
Any help with this problem would be appreciated.
--------
Following is the rpcgen bug report we discovered painfully late after many
futile attempts at creating an inetd-tcp-nowait entry:
Bug Id: 1065359
Category: doc
Subcategory: network
Release summary: 4.1.1
Synopsis: rpcgen -I does not work together with nowait servers
Integrated in releases: 5.0
Summary:
rpcgen -I produces rpc-code which could only be used for server
with the flag wait in /etc/inetd.conf. This is neither
documented in the man-page of rpcgen nor in the RPC-Programming
Manual.
----- end included message -----
--
Bus error, core dumped
-----------[000161][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Jan 1993 17:53:05 GMT From: danson@lgc.com (Doug Anson) To: comp.protocols.nfs,comp.sys.sun.apps,comp.protocols.tcp-ip Subject: Re: RPCGEN with inetd
In article <1iusmnINNa3g@usenet.INS.CWRU.Edu>, edvax@pyrite.som.cwru.edu (Ed Reznichenko) writes: |> |> The following is posted for a co-worker. Email responses to me, and I |> will pass them along. |> |> Thank you, |> |> --ed |> |> Internet: edvax@pyrite.som.cwru.edu |> UUCP: uunet!pyrite.som.cwru.edu!edvax |> |> ----- begin included message ----- |> TOPIC: inetd rpc applications |> HARDWARE: SPARC |> OS: SunOS 4.1.1 |> |> Given that rpcgen -I fails to produce correct code for inetd-tcp-nowait |> entries, does anyone happen to have tested server stubs used for |> inetd-tcp-nowait entries that they would be willing to share? |> |> Also, the last Stevens text on page 339 says that there are no 4.3BSD |> inetd-tcp-wait flag applications. Does anyone know if this remains |> true? |> |> In order to simulate concurrent servers, we are considering defining |> <n> inetd-tcp-wait servers with clients randomly selecting a server |> with a uniform distribution, and hoping client time-outs are |> sufficient to account for delays. Does anyone have opinions to offer |> on this? |> |> Any help with this problem would be appreciated. |> -------- |> |> |> Following is the rpcgen bug report we discovered painfully late after many |> futile attempts at creating an inetd-tcp-nowait entry: |> |> Bug Id: 1065359 |> Category: doc |> Subcategory: network |> Release summary: 4.1.1 |> Synopsis: rpcgen -I does not work together with nowait servers |> Integrated in releases: 5.0 |> Summary: |> rpcgen -I produces rpc-code which could only be used for server |> with the flag wait in /etc/inetd.conf. This is neither |> documented in the man-page of rpcgen nor in the RPC-Programming |> Manual. |> |> |> ----- end included message ----- |> -- |> Bus error, core dumped Furthermore, I would like to add that rpcgen -I doesnt produce stubs that can be used for TCP RPC servers -- I cant seem to get the RPC handle to the exec'ed server from my super server. BTW, I was able to get nowait TCP servers running -- I really dont remeber doing anything "special" to get them to work -- the stubs seem to work fine. Doug -- ------------------------------------------- Doug Anson Internet: danson@lgc.com Phone: 713.560.1274 FAX: 713.560.1277 SNAIL: Landmark Graphics Corporation LGC 15150 Memorial Drive Houston, TX 77079 -------------------------------------------
-----------[000162][next][prev][last][first]---------------------------------------------------- Date: 12 Jan 93 17:59:30 GMT From: skibo@florida.wpd.sgi.com (Thomas Skibo) To: comp.sys.sun.apps,comp.protocols.tcp-ip Subject: Re: tcp_mss "downshift" with consecutive rcp's
In article <1993Jan12.003854.5821@cbnewsd.cb.att.com>, pccl@cbnewsd.cb.att.com (paul.c.liu) writes: |> A while ago, I recall a netter from SGI posted an article |> detailing a BSD TCP bug fix for the tcp_mss "downshift" symptom. |> |> Symptom: consecutive "rcp remhost:remfil locfil" will result |> in smaller TCP payload (i.e. from 1460-byte to 512-byte), |> unless there is 60+ seconds time gap in between. |> |> To reproduce: use three Suns, on sun_a, do |> rcp sun_b:file1 file1, and |> rcp sun_b:file2 file2 |> and run tcpdump/etherfind on sun_c to trace the network traffic. |> |> Pointers are appreciated! |> |> Paul.C.Liu@ATT.COM I don't know if a fix was given but I think I know what the problem is. When a SYN segment is received on a TCP in TIME_WAIT, the old TCP end-point is closed (tcp_close()) and the BSD code jumps back up to start over processing the SYN segment from scratch (look for the "goto findpcb;"). The problem is that the TCP options (MSS) are processed and discarded in the first pass and so are missing on the pass that actually creates the new connection. The new connection defaults to tcp_mssdflt (roughly 512 bytes). I ran into this problem while implementing RFC 1323 (window scaling/ time stamps). The options in the SYN were discarded in those cases and so window scaling and time stamps wouldn't occur on those connections. Apparantly, rlogin and rcp use the SOREUSEADDR flag and they tend to hit on this problem (since they'll use the same local port number over as soon as it's available). This problem will be fixed in the IRIX releases that have RFC 1323 TCP extensions. -- --- Thomas Skibo Advanced Networking, Silicon Graphics skibo@sgi.com
-----------[000163][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Jan 1993 22:33:30 GMT From: karl@ddsw1.mcs.com (Karl Denninger) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
In article <MLEWIS.93Jan11155619@yoyo.telebit.com> mlewis@telebit.com writes: > >> mlewis@telebit.com (Mark S. Lewis) writes: >>>> I currently attach via SLIP over a leased line using v.32bis/v.42bis >>>> modems from a Dell machine (on my end) into a smartport on a Telebit Netblazer. >>>> Would I see any significant increase in throughput using this same >>>> physical connection (v.32bis/v.42bis) but replacing the Dell SLIP >>>> with a Netblazer on my end -- and connecting my machines via ethernet >>>> to the Netblazer? >>>> [...] >>>> Larry Snyder internet: larry@gator.rn.com >>> >>>No I don't think you would get a significant performance increase by >>>putting a NetBlazer at both ends. You are using relatively slow >>>serial lines limited by V.32bis modulation with whatever compression >>>you get with V.42bis. Yikes! And wrong. DELL does not know about VJ header compression. The Netblazer certainly does. As such, you will see significant improvements in interactive performance. >As for memory leakage, we have come quite a ways. We have made >numerous improvements to the memory allocation to help us find leaks. >At this point, there are only a few rare leaks. In general, the >NetBlazer will stay up for months. Now if I could figure out the algorythm for the flipping modemcap.txt file and how you really talk to modems for dialing and configuration. There are some nasties in there that I've yet to figure out.... ;-) I do agree, however, that in general the Netblazer is a really nice product for this use. It does the job and does it quite well. Multi-month uptimes aren't rare at all. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Data Line: [+1 312 248-0900]
-----------[000164][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Jan 1993 23:11:34 GMT From: larry@news.rn.com (Larry Snyder) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
karl@ddsw1.mcs.com (Karl Denninger) writes: >If you can find a driver for the board, certainly ;-) I was told that morningstar is working on a SCSI product which will support up to a T1 on a SCSI buss under Dell 2.2 -- Larry Snyder internet: larry@gator.use.com keeper of the Gator uucp: uunet!gator!larry
-----------[000165][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 93 02:58:10 GMT From: mpmadhu@picasso.ocis.temple.edu (Madhusudan Muchalambkar) To: comp.protocols.tcp-ip Subject: RE:How do I Monitor Sun Outgoing Packets
Refer to etherd and traffic.
-----------[000166][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 1993 15:07:35 -0500 From: feinstn@newsserver.rest.tasc.com (Harlan W. Feinstein) To: comp.protocols.tcp-ip Subject: hooking into a PC/TC-IP network via modem
I'm trying to figure out what software would be needed to be able to perform services like FTP and Telnet from my PC at home. I have no network connections there, simply a 14.4K modem that I can dial in with. Would I necessarily need to be hardwired to the network? Please e-mail me any information if possible. Thanks in advance. --Harlan -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Harlan Feinstein The Analytic Sciences Corporation hwfeinstein@tasc.com NeXTMail okay -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-----------[000167][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 93 11:24:23 GMT From: barnett@grymoire.crd.ge.com (Bruce Barnett) To: comp.protocols.tcp-ip Subject: Re: reading what you're writing on Suns
I use tcpdump a lot, so news that the latest version of Ultrix and SunOS fix the "can't see packets being sent" problem is great! What about the localhost device lo0? I have a patch that allows tcpdump to monitor local connections? Will Ultrix/SunOS support this? Has there been any improvements on the efficiency of nit in SunOS 5.x? Also - what sort of accuracy does the timestamp have? Thanks. -- Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
-----------[000168][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 93 14:32:52 GMT From: hq@sapwdf.UUCP (Harald Kuck) To: comp.protocols.tcp-ip Subject: EADDRINUSE: which UNIX-process is using my port ?
If 2 processes try to use the same port, one of them will fail with UNIX-errno EADDRINUSE. The command netstat tells me the connections between the ports on my machine and all other machines, but how can I find out the processes which are involved ??? Thanks for any help !
-----------[000169][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 1993 15:05:15 GMT From: kroell@pu.informatik.th-darmstadt.de (Christoph Kroell) To: comp.protocols.tcp-ip Subject: Who knows "General Magic" ( = "GM") ?
Who can tell me something about the (tcp-ip ?) working group "General Magic" ( = "GM") ? Or where or how can I get to some information about this group ? Please mail to kroell@iti.informatik.th-darmstadt.de
-----------[000170][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 93 15:24:27 GMT From: jessea@u013.me.vp.com (Jesse W. Asher) To: comp.protocols.tcp-ip,comp.unix.sysv386 Subject: PD slip/cslip for SCO 3.2.4?
Does anyone know of a public domain version of slip/cslip that will run
on SCO Unix 3.2.4? I dislike their version as it takes over the port
and that port has to be dedicated to slip and nothing else. I'd like to
be able to use that port as a login port as well. Thanks for any
assistance.
--
Jesse W. Asher (901)762-6000
Varco-Pruden Buildings
6000 Poplar Ave., Suite 400, Memphis, TN 38119
Internet: jessea@vpbuild.vp.com UUCP: vpbuild!jessea
-----------[000171][next][prev][last][first]---------------------------------------------------- Date: Wed, 13 Jan 1993 18:07:35 GMT From: john@gecko.pac.sc.ti.com (John Maline) To: comp.protocols.tcp-ip Subject: shutdown(s, 2) == close(s)?
I'm having a problem with the semantics of the shutdown() system call. The references I've checked (Comer/Stevens vol 3, vendor docs...) don't indicate if a close() is required after shutdown(). I'd assume close is required after shutdown(s, 0) or (s, 1), since that only closes half of the connection and you've still got a viable socket handle after the shutdown. shutdown(s, 2) isn't as obvious to me, since that closes down both parts of the connection. Sounds pretty equivalent to close(s) at that point... To sum up, the subject says it all: is shutdown(s, 2) equivalent to close(s) (when done on a socket handle)? I'm maintaining some code and came across this. The original coder seems to think they are equivalent. I'm wondering if we're "leaking" file handles. I was thinking of just replacing the shutdown() calls with close(), since it's always a 2-way shutdown anyway. Are there any fine semantic differences I'm missing (aside from my question of file handle leaks)? Please respond by mail. Thanks for any help. -- John Maline jmaline@lobby.ti.com TI MSG: JWMX Texas Instruments PO Box 655012 MS 351 Dallas, Tx 75265 214-995-6692
-----------[000172][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 93 18:32:13 GMT From: wjq@uts.amdahl.com (Bill Quigley) To: comp.protocols.tcp-ip Subject: portable, public domain NIT?
Does anyone know of some kind of portable, public domain NIT-type program? I can hack my kernel to put the ethernet in promiscuous mode and pass every packet to a process, but I don't want to write all of the rest of the packet interpretation code. -- Flower Cake - Trends in food come and go, but the popularity of cookies never wanes - easy to make, easy to eat. Bill Quigley Amdahl - UTS CCE wjq@charon.amdahl.com
-----------[000173][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 1993 21:22:06 GMT From: mogul@pa.dec.com (Jeffrey Mogul) To: comp.protocols.tcp-ip Subject: Re: reading what you're writing on Suns
In article <BARNETT.93Jan13062423@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes: >What about the localhost device lo0? I have a patch that allows >tcpdump to monitor local connections? Will Ultrix/SunOS support this? I can't speak for the parts of DEC that engineer and sell products, but I would not expect ULTRIX to allow you to monitor lo0 using tcpdump, at least not anytime soon. >Also - what sort of accuracy does the timestamp have? You probably mean resolution, not accuracy. The accuracy depends on who set your clock, and how well it keeps time. On ULTRIX, the resolution is that of the system's interrupt clock. That's 256 Hz (just under 4msec/tick) on RISC hardware, and (if my memory serves) 100 Hz on VAXen. It's possible to play some tricks to change these values, but I would not normally advise doing so. ULTRIX does ensure that the timestamps are unique and monotonic, which is why you will occasionally see tcpdump printing packets that appear to have been received 1 microsecond apart. -Jeff
-----------[000174][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 93 12:24:00 ACST From: gcdcrgp@state.systems.sa.gov.au To: comp.protocols.tcp-ip Subject: Reference Sites - IBM TCP/IP+RS/6000
We are looking for a reference site. We are the South Australian Government computing and communications bureau. We have an IBM 3090 running MVS/ESA. We are considering installing IBM's TCP/IP Version 2.2. IBM are proposing an RS/6000 to act as the ethernet-to-channel adapter rather than the usual IBM 3172. Is anyone using this configuration? If so , we would like to hear from them (name, org., phone no, fax no, mail address) to (hopefully) get some warm feelings about the configuration - does it perform to specs? any problems? would you do the same thing again? is there anything we should know? etc. Thanks for your time Roger Phillips - Data Communications group
-----------[000175][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 93 22:53:08 GMT From: ddl@burrhus.harvard.edu (Dan Lanciani) To: comp.protocols.tcp-ip Subject: Re: shutdown(s, 2) == close(s)?
In article <JOHN.93Jan13120735@gecko.pac.sc.ti.com>, john@gecko.pac.sc.ti.com (John Maline) writes: | I'm having a problem with the semantics of the shutdown() system call. | The references I've checked (Comer/Stevens vol 3, vendor docs...) | don't indicate if a close() is required after shutdown(). It is. Shutdown() merely performs protocol actions and changes the state of the underlying tcp/ip. You must dispose of the file descriptor with close() regardless of the option used with shutdown(). | To sum up, the subject says it all: is shutdown(s, 2) equivalent to | close(s) (when done on a socket handle)? It isn't. (I repeat myself because this seems a somewhat popular area of confusion.) | I'm maintaining some code and came across this. The original coder | seems to think they are equivalent. I'm wondering if we're "leaking" | file handles. Probably... | I was thinking of just replacing the shutdown() calls with close(), | since it's always a 2-way shutdown anyway. Are there any fine | semantic differences I'm missing (aside from my question of file | handle leaks)? There are some subtle semantics involving shared descriptors. There were also some special cases for close() in older unix tcp/ip implementations. For most current versions, shutdown(,2) followed by close() is the same as close() itself (excepting timing issues) provided there is but a single reference to the descriptor. If there are multiple references, the situation changes. Consider the extreme case where a process has fork()ed and parent and child share access to a single underlying socket. Say the child is blocked in a read() of the socket. If the parent uses shutdown(,2) the child will wake up. If the parent merely close()s the socket, the child will remain blocked. Dan Lanciani ddl@harvard.*
-----------[000176][next][prev][last][first]---------------------------------------------------- Date: Wed, 13 Jan 1993 23:16:14 GMT From: rich@tsmnet3.melpar.esys.com (Richard Martin) To: comp.protocols.tcp-ip,biz.sco.general Subject: routing with 1 interface
Can SCO UNIX ODT 2.0 systems route using 1 ethernet interface?? Basically,
it would be nice if one ethernet card could be connected to one
cable that had two different IP numbers.
I would like to configure the IP number of my machine to be 128.1.1.1 and
still be able to talk to systems that have IP #'s 11.?.?.?. Is this
possiblie ?? I know it will work with two interface cards...
Thanks in advance...
--
################################### <--> ######################################
Richard Martin
E-Systems, Melpar Division - Network Engineering
Internet: rmartin@melpar.esys.com
-----------[000177][next][prev][last][first]---------------------------------------------------- Date: 14 Jan 93 03:21:02 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: reading what you're writing on Suns
In article <1j215uINN82m@usenet.pa.dec.com>, mogul@pa.dec.com (Jeffrey Mogul) writes: > I can't speak for the parts of DEC that engineer and sell products, > but I would not expect ULTRIX to allow you to monitor lo0 using > tcpdump, at least not anytime soon. > ... Why? The security issues don't seem significanty worse than on a real device. Is it some kind of implementation problem? Vernon Schryver, vjs@sgi.com
-----------[000178][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Jan 1993 05:23:46 GMT From: ae2@cunixb.cc.columbia.edu (Amiran Eliashvili) To: comp.protocols.tcp-ip Subject: checking on a UDP broadcast message
Hi all: I am trying to find the most efficient way of detecting which hosts has received an UDP broadcast message. One way that might be most inefficient is to have all the hosts responding back with an ACK. This scheme is a bit awkward. I was wondering if there is another way I could check on the broadcast message. Any suggestions are most welcomed. Please reply to: ae2@cunixa.cc.columbia.edu Many Thanks in Advance.
-----------[000179][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Jan 1993 05:24:20 GMT From: adelman@tgv.com (Kenneth Adelman) To: comp.protocols.tcp-ip Subject: Re: Encapsulation of or translation of DECNET on a TCP/IP backbone
In article <15912@hq.hq.af.mil>, parsons@nic.hq.af.mil writes...
>
>--
>Does anyone know of any methods to either convert DECNET to TCP/IP and back
>again or encapsulate DECNET within TCP/IP. I need to have two DEC sites
>communicate across a large packet-switched TCP/IP backbone. Unfortunately, it
>will be a somewhat unreliable network where network congestion and delay are
>prevalent. DECNET is a requirement because of the applications; TCP/IP is a
>requirement for the backbone since it's someone else's empire and corporate
>policy is to use the backbone.
Our TCP/IP product for VMS, MultiNet, lets you encapsulate DECnet
in either UDP (low overhead; works best on reasonably reliable networks)
or TCP (more overhead; harder to configure; but what you need for an
unreliable network). Give us a call at 800-TGV-3440 if you'd like
a free evaluation.
Ken
-----------[000180][next][prev][last][first]---------------------------------------------------- Date: 14 Jan 1993 19:53:02 -0800 From: markb@spock.dis.cccd.edu (Mark Bixby) To: sci.space.shuttle,sci.space,comp.protocols.misc,comp.protocols.tcp-ip Subject: Broadcasting shuttle audio over the Internet?
An article posted recently to sci.space.news mentions that some folks at NASA will be broadcasting NASA SELECT shuttle mission audio over MBONE and the Internet. Where can I go to learn more about this audio broadcasting protocol? I.E. what RFC numbers, hardware requirements, FTP software repositories, etc... -- Mark Bixby Internet: markb@cccd.edu Coast Community College District 1370 Adams Avenue District Information Services Costa Mesa, CA, USA 92626 Technical Support (714) 432-5064 "You can tune a file system, but you can't tune a fish." - tunefs(1M)
-----------[000181][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Jan 93 10:07:54 GMT From: tsv@elvis.sovusa.com (Igor Tsvetkovsky) To: comp.protocols.tcp-ip,comp.sys.sun.apps,comp.sys.sun.misc Subject: Rebuilding Sun kernel for multicasting
I took sourses for ip-multicast from ftp directory
vmtp-ip on gregorio.stanford.edu. For SunOS 4.1.* there exists
sources only for sun4c, but i need them for sun4 (SUN4-260)
and for sun3, too.
I try to build multicast kernel on SUN4-260 SunOS 4.1.1, but
there were errors:
# make
loading vmunix
Undefined
_addmultiaddr
_delmultiaddr
_map_regs
_adddma
_slaveslot
_dvmamap
_getprop
_report_dev
_ledriver
*** Error code 2
make: Fatal error: Command failed for target `vmunix'
Can anybody help me?
Thanks!
Igor Tsvetkovsky
Mail : tsv@elvis.sovusa.com
-----------[000182][next][prev][last][first]---------------------------------------------------- Date: 14 Jan 1993 11:18:56 GMT From: antonis@helios.ntua.gr (Antonis Kyriazis) To: comp.protocols.tcp-ip Subject: ftp/NOOP
Hi I'm running ftptool (a SPARC executable for ftp) to connect to an internet host and I get following message 200 NOOP command successful. 257 "/" is the current directory. 200 Type set to A. 200 PORT command successful. 425 Can't build data connection: Host is unreachable. Nevertheless, I get without problems a connection to any of our local machines (SUNs & DECs), and I've never seen such a message when using ftp. Any ideas? thanks in advance +-------------------------------------------------------------------+ | Antonis Kyriazis | | Networks & Communications e-mail: antonis@intranet.gr | | INTRACOM sa | | 19.5 km Marcopoulo Ave. fax: +30-1- 66 44 379 | | Peania 190 02 +30-1- 66 43 718 | | GREECE phone: +30-1- 66 44 961-5 | | +30-1- 88 43 715 | +-------------------------------------------------------------------+
-----------[000183][next][prev][last][first]---------------------------------------------------- Date: 14 Jan 93 14:24:47 GMT From: barnett@grymoire.crd.ge.com (Bruce Barnett) To: comp.protocols.tcp-ip Subject: Re: reading what you're writing on Suns
In article <1j215uINN82m@usenet.pa.dec.com> mogul@pa.dec.com (Jeffrey Mogul) writes: > ULTRIX does ensure that the timestamps are unique and monotonic, which > is why you will occasionally see tcpdump printing packets that appear > to have been received 1 microsecond apart. Interesting. I can see how you make sure the timestamps have at least 1 microsecond difference. What about changes in the system clock? I had to add smarts to a script because I was doing a tcpdump for more than 24 hours, and the measurement system did an "rdate" at midnight. The change in time was immediate, and it threw off my calculations for packets per 60 second slice. (I should be using ntp, I know.) Here is an extreme case, for our amusement.... :-) You set the date wrong (January 14 1994) Start tcpdump. Realize the date was wrong, and correct the date (January 14, 1993) Wait a while. Stop tcpdump. I would think there would be some combination (maybe not a year) where tcpdump would generate two timestamps with the same value. -- Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
-----------[000184][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Jan 1993 15:27:17 GMT From: larry@shark.mitra.com (Larry Williamson) To: comp.protocols.tcp-ip Subject: Efficiency of routing to subnets on one enet cable
Is there any real performance penalty in the following senario?
I put three machines on one ethernet cable. Each machine has only one
ethernet interface. I put machine one (m1) on one subnet (let's say
192.1.1.0) and machine two (m2) on another subnet (say 192.1.2.0). I
configure the routing table on machine three (m3) to know about both
subnets. Machines m1 and m2 have a default routing entry that uses m3,
ie. "route add default m3 1".
What if any performance penalty is there to this setup as compared to
having m1 and m2 route directly to the other subnet, ie.
on m1 "route add m2 m1 0"
and on m2 "route add m1 m2 0"
Ping -s shows ICMP Host redirect messages for each ping packet when I
use the default routing through m3. Yet massive ftp transfers don't
seem to be affected by that setup. The tranfer times for moving (in
binary mode) 20Meg files from m1 to m2 is about the same whether I use
a default route through m3, or a direct route to the other subnet.
If it makes any difference, all machines are Sun IPC's run SunOS 4.1.2
-Larry
-----------[000185][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Jan 1993 17:03:41 GMT From: scrouse@husky1.stmarys.ca To: comp.protocols.tcp-ip Subject: Wanted: IP-IPX router S/W for PC
I looking for routing software that will run on a PC, and will
1) route both TCP/IP and IPX and 2) route between serial and
ethernet interfaces.
OR
a another solution to our problem.
The Configuration:
We have a couple of off campus offices that require access to our
central systems and some novell mail transfers. Currently, for each
office we have PCs (running PCbridge) that are hooked into ethernet
on and connect (via modems/leased line) the off campus sites.
The PCs in the off campus offices "did" run most PC applications from their
hard drives and use the network to connect to our VAXes via telnet.
The Problem:
One of the offices just installed a novell server and now we are finding
that a lot of our PCs are trying to boot from this remote Novell server -
which is a very slow process over a 19200 baud line.
The Possible Solutions:
1) buy a serial card for our Cisco router and use it's SAP routing/filting
capibilities to direct SAP requests. Problem - $$$$$$
2) get router software to replace PCbridge that has the capability to route
IPX and IP. Problem - can not find approate software.
If you know of any such software or if you have any suggestions/solutions,
please send messages directly to me as normally don't follow this news
group (I will summarize and post the responses, if there is enough interest).
I should also mention that money is scarce, but a commercial package
in not out of the question.
Steve
===============================================================================
Steve Crouse
VAX Systems Manager Internet: SCrouse@Husky1.STMARYS.CA
Saint Mary's University Bitnet : SCrouse@STMARYS
Halifax, Nova Scotia Telphone: (902) 420-5476
Canada B3H 3C3 Fax : (902) 420-5115
Murphy's Law #11 "It is impossible to make something foolproof because
fools are so ingenous"
===============================================================================
-----------[000186][next][prev][last][first]---------------------------------------------------- Date: 14 Jan 1993 17:42:55 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: ftp/NOOP
In article <1j3i70INNccf@pythia.csi.forth.gr> antonis@helios.ntua.gr (Antonis Kyriazis) writes:
> 425 Can't build data connection: Host is unreachable.
>
>Nevertheless, I get without problems a connection to any of our local
>machines (SUNs & DECs), and I've never seen such a message when using
>ftp.
Sounds like you have a packet filter at your gateway, which is rejecting
the server's attempt to connect to your system for the data connection.
--
Barry Margolin
System Manager, Thinking Machines Corp.
barmar@think.com {uunet,harvard}!think!barmar
-----------[000187][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Jan 1993 18:49:10 GMT From: rhealey@rogue.digibd.com (Rob Healey) To: comp.protocols.tcp-ip Subject: Re: reading what you're writing on Suns
In article <BARNETT.93Jan13062423@grymoire.crd.ge.com>, barnett@grymoire.crd.ge.com (Bruce Barnett) writes: |> I use tcpdump a lot, so news that the latest version of Ultrix and |> SunOS fix the "can't see packets being sent" problem is great! |> SunOS 5.1, Solaris 2.1, can see packets it sends on the ethernet. Don't know about the loopback port though. The snoop command is part of the OS and IMHO is better than tcpdump for most network snooping purposes. It is VERY good at decoding the guts of an ethernet packet in to PLAIN ENGLISH, much easier than trying to decode TCP options in one's head by reading hex digits. Snoop allows various boolean operations for filtering from the command line and let's you catch packets to a file and then analyze them later. It's timestamp claims better than 60Hz resolution. The REAL plus is snoop decodes NIS+ operations as well as ip, tcp, udp, NIS and others. This allows for decent NIS+ debugging. Nice tool, I suggest all Solaris 2.1 admins bone up on the command. |> Has there been any improvements on the efficiency of nit in SunOS 5.x? |> Dunno. They use the UNIX networking DLPI interface rather than NIT per say although the effect is the same. It's a shame USL never got ahold of snoop for other SVR4 systems, I'd kill for snoop on an Intel box running SVR4... DLPI has some very interesting features for accessing network hardware at a low level including promiscuous mode, multicasting and network adapter parameters. |> Also - what sort of accuracy does the timestamp have? |> Looks like they are using a high resolution timer on it now. -Rob
-----------[000188][next][prev][last][first]---------------------------------------------------- Date: 14 Jan 1993 19:44:55 GMT From: mogul@pa.dec.com (Jeffrey Mogul) To: comp.protocols.tcp-ip Subject: Re: reading what you're writing on Suns
In article <BARNETT.93Jan14092447@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes: >In article <1j215uINN82m@usenet.pa.dec.com> mogul@pa.dec.com (Jeffrey Mogul) writes: >> ULTRIX does ensure that the timestamps are unique and monotonic, which >> is why you will occasionally see tcpdump printing packets that appear >> to have been received 1 microsecond apart. > >Interesting. I can see how you make sure the timestamps have at least >1 microsecond difference. What about changes in the system clock? I was slightly inaccurate. ULTRIX ensures that timestamps are unique and monotonic as long as the system clock is not set backwards using the settimeofday() system call. >I had to add smarts to a script because I was doing a >tcpdump for more than 24 hours, and the measurement system did an >"rdate" at midnight. The change in time was immediate, and it threw >off my calculations for packets per 60 second slice. (I should be >using ntp, I know.) Yes, you should be using NTP. The ULTRIX NTP daemon (/etc/ntpd) never ever uses settimeofday() to set the clock backwards. Wise system managers never use rdate, except in /etc/rc* to give the NTP daemon a clean start. -Jeff
-----------[000189][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Jan 1993 20:26:47 GMT From: paulb@hyphen.com (Paul Bournival) To: comp.protocols.tcp-ip Subject: fcntl() to set non-block mode doesnt seem to work Sunos 413
Hi All!
I am trying to use the fcntl(2V) call to set the non-blocking mode
on a socket (and, in another spot, on a fd pointing at the audio device.)
Here's exactly what I'm doing:
if (fcntl(wellKnownFD,F_SETFL,O_NDELAY)<0) {
fprintf(stderr,"cant set non-block mode for socket.\n");
exit(1);
}
This test proceeds successfully. However, calls to select(2) block while trying
to determine if there's input available on the socket. I think select, read,
and write should return -1 (and EWOULDBLOCK). Does anyone know what I'm doing
wrong?
I'm using SunOS 4.1.3 on a Sparc ELC, and GNU C (don't remember the version.)
However, I tried compiling under acc (well respected commercial compiler),
with similar results.
Thanks in advance for any ideas or help!
Paul Bournival (paulb@hyphen.com paulb@world.std.com)
-----------[000190][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Jan 93 22:15:15 GMT From: maritza@espresso.bae.bellcore.com (Maritza Ramirez) To: comp.protocols.tcp-ip Subject: RPC protocol specifications
I would appreciate if someone could tell me how the RPC protocol specifications can be obtained. Are they proprietary, or freely available on the internet ? (I am interested in the protocol specification of the "portmapper"). Thanks, Maritza
-----------[000191][next][prev][last][first]---------------------------------------------------- Date: 14 Jan 1993 23:00:02 GMT From: scoggin@delmarva.com (John K. Scoggin, Jr.) To: comp.protocols.tcp-ip Subject: Network Management Tools for Internets
I am looking for sources to 2 tools mentioned in the Internet System Handbook (Lynch/Rose) - NCNS - A network performance measurement package from CMU (?) NNam - Internet analysis tool (Merit?) I have looked on Archie to no avail. Does anyone know who to contact to obtain information on these tools? - John --- +---------------------------------------------------------------------+ | John K. Scoggin, Jr. Email: scoggin@delmarva.com | | Supervisor, Network Operations Phone: (302) 451-5200 | | Delmarva Power & Light Company Fax: (302) 451-5321 | | 500 N. Wakefield Drive NOC: (800) 388-7076 | | Newark, DE 19714-6066 | +---------------------------------------------------------------------+
-----------[000192][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Jan 1993 03:10:48 GMT From: bwarner@mentor.cc.purdue.edu (Bill Warner) To: comp.protocols.tcp-ip Subject: Re: RPC protocol specifications
In article <1993Jan14.221515.22259@walter.bellcore.com> maritza@espresso.bae.bellcore.com (Maritza Ramirez) writes: >I would appreciate if someone could tell me how the RPC protocol >specifications can be obtained. Are they proprietary, or freely >available on the internet ? (I am interested in the protocol >specification of the "portmapper"). > The port mapper protocol specification is in Appendix 1 of RFC 1057. Bill -- Bill Warner (317)494-1787 General Consultant bwarner@cc.purdue.edu Purdue University Computing Center bwarner@PURCCVM.BITNET
-----------[000193][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Jan 1993 03:11:23 GMT From: reh@wam.umd.edu (Richard Huddleston) To: comp.protocols.tcp-ip,comp.unix.admin Subject: Subnet fields > 8 bits : question
I'm trying to get an explanation, and references, to a question about subnet fields on Class B Internet addresses which are greater that 8 bits in width. Assume, first, that we *can* define subnets greater than 8 bits ( and I say this because I haven't found an example of this in the RFCs I've read so far -- although I would love to find a reference! ). Let's say that the network ID portion of the address is 155.155: 1001 1011 . 1001 1011 and, for the sake of simplicity, that we want to add a 14 bit subnet field with two bits left over for hosts at that subnet. I'm a little confused as to how the remaining octet numbering would go. Part of my confusion comes from never having worked with subnet masks greater than 8 bits, so that the possibility of a 0-filled octet is accounted for. Is the first subnet / host address like this: 1001 1011 . 1001 1011 . 0000 0001 . 0000 00-01 (<--last two bits are host) (155.155.1.1) this: 1001 1011 . 1001 1011 . 0000 0000 . 0000 01-01 (155.155.0.5) this: 1001 1011 . 1001 1011 . 0000 0001 . 0000 01-01 (155.155.1.5) this: 1001 1011 . 1001 1011 . 0000 0000 . 0000 00-01 (155.155.0.1) or, something else entirely ( and if so, what? ) Answers appreciated; references REALLY appreciated! -- Richard Huddleston University of Maryland at College Park Personal opinions
-----------[000194][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 1993 10:24:34 GMT From: kroell@pu.informatik.th-darmstadt.de (Christoph Kroell) To: comp.protocols.tcp-ip Subject: Mobile tcp-ip? Via satellite or cellular radio?
Hallo world! I'm working on a lecture on the subject of "mobile datacommunication" at the Technical University of Darmstadt in Germany witch should inclose cellular radio and satellite systems as well as used protocols, software and hardware. Is there anywhere an approach to use TCP/IP for mobile data transfer in any mobile communication system of the world ? Who knows actual literature or working groups , institutes or companys working on this item ? If you can give me any pointer on this topic, please mail to kroell@iti.informatik.th-darmstadt.de . Thank you in advance for your assistence. Christoph Kroell.
-----------[000195][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 1993 11:47:42 GMT From: antonis@intranet.gr (Antonis Kyriazis) To: comp.protocols.tcp-ip Subject: Re: Rebuilding Sun kernel for multicasting
I got similar messages by trying to make it under 4.1.2. | Antonis Kyriazis | Networks & Communications e-mail: antonis@intranet.gr | INTRACOM sa | 19.5 km Marcopoulo Ave. fax: +30-1- 66 44 379 | Peania 190 02 +30-1- 66 43 718 | GREECE phone: +30-1- 66 44 961-5 | +30-1- 88 43 715
-----------[000196][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Jan 1993 12:28:22 GMT From: anton@analsyn.gts.org (Anton J Aylward) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
In the article (<C0r1yp.3o4@ddsw1.mcs.com>) Karl Denninger (karl@ddsw1.mcs.com) posted to biz.comp.telebit.netblazer: : In article <C0oBxC.Bvr@news.rn.com> larry@news.rn.com (Larry Snyder) writes: : >Also, is it possible to put a v.35 board in a machine running Dell 2.2 : >and do the routing under Unix? : If you can find a driver for the board, certainly ;-) Thats one BIG if. I've been looking for a while nwo with no sucess. I may end up writing my own! -- Anton J Aylward "The body politic is swerving from left to right and right to left looking for quick fixes for systemic problems." - Paul Palango, Journalist, ex The Globe and Mail
-----------[000197][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Jan 1993 15:06:13 GMT From: bwarner@mentor.cc.purdue.edu (Bill Warner) To: comp.protocols.tcp-ip Subject: Re: Subnet fields > 8 bits : question
In article <1993Jan15.031123.2686@wam.umd.edu> reh@wam.umd.edu (Richard Huddleston) writes: >I'm trying to get an explanation, and references, to a question about >subnet fields on Class B Internet addresses which are greater that 8 bits >in width. Assume, first, that we *can* define subnets greater than 8 >bits ( and I say this because I haven't found an example of this in the >RFCs I've read so far -- although I would love to find a reference! ). > Subnet fields can certainly be greater than 8 bits. RFC 1122 section 3.2.1.3 states that the minimum size of the host (or subnet) field in an IP address is 2 bits. So, if the host field is 2 bits then the subnet field must be 14 bits (for a class B address). >Let's say that the network ID portion of the address is 155.155: > >1001 1011 . 1001 1011 > >and, for the sake of simplicity, that we want to add a 14 bit subnet >field with two bits left over for hosts at that subnet. > >I'm a little confused as to how the remaining octet numbering would go. >Part of my confusion comes from never having worked with subnet masks >greater than 8 bits, so that the possibility of a 0-filled octet is >accounted for. > >Is the first subnet / host address like this: > >1001 1011 . 1001 1011 . 0000 0001 . 0000 00-01 (<--last two bits are host) >(155.155.1.1) > >this: >1001 1011 . 1001 1011 . 0000 0000 . 0000 01-01 >(155.155.0.5) > >this: >1001 1011 . 1001 1011 . 0000 0001 . 0000 01-01 >(155.155.1.5) > All of the above addresses are valid. You can number your subnets *any* way you want. Which one is "first" and what order you number in is entirely up to you. >this: >1001 1011 . 1001 1011 . 0000 0000 . 0000 00-01 >(155.155.0.1) > This is not a valid host address. This violates RFC 1122 section 3.2.1.3 which says that none of the fields in an IP address (network, subnet, or host) can consist of all zeros or all ones. (Except in certain strictly defined special cases, like broadcast addresses.) Bill -- Bill Warner (317)494-1787 General Consultant bwarner@cc.purdue.edu Purdue University Computing Center bwarner@PURCCVM.BITNET
-----------[000198][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 93 20:37:28 GMT From: echan@skynet.intel.com (Eldon Chan ~ ) To: comp.protocols.tcp-ip Subject: Vendor numbers for ethernet addresses
Would someone tell me what vendor has ethernet address prefix
00:00:81
?
I checked the rfc1340 (Assigned numbers), but it's not in there. Anyone have a
more updated list ?
Thanks much.
--
Eldon Chan
Intel Corpoartion
Design Technology
Networking group Phone: 408-765-4992
echan@scdt.intel.com Fax: 408-765-5719
-----------[000199][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Jan 1993 22:31:36 GMT From: stuarts@news.apertus.com (Stuart Stanley) To: comp.protocols.tcp-ip Subject: IP rollover
Heres an odd thought we were having around here: Would it be possible
to create an IP rollover service that would allow a person to connect
to a given ip address, that would either reattach the connection to
a different number (assigned from a bank of numbers) or maybe route all the
packets for the given connection. Errr, basicaly a IP rotary ala a dial-in
rotary common with modem pools.
I was thinking that it might be possible to make a "router" that picks off
packets destined to IP.address.1 and "patch" the source and destination to
point to the "router" and IP.address.load_shared_ip and then drop the
packet back out onto the wire. From this, I have three questions:
1) Can anyone see a reason why this might not work/be wise.
(Other than the doubled network traffic).
2) Has anyone seen anything like this before? (where is it if so?)
3) Does anyone know of any router source for either svr5 or just
a stock PC that I can pick up from a ftp site?
I will post a summary if I get anything interesting out of this question...
Cheers,
--
"Seems lately that I'm doubling as Storm bait" ! Stuart Stanley
Nanci Griffith ! stuarts@apertus.com
(Late Night Grande Hotel) ! Apertus Technologies
(612)-828-0391 <-> Eden Praire, Minnesota
-----------[000200][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 1993 22:39:27 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: Subnet fields > 8 bits : question
In article <1993Jan15.031123.2686@wam.umd.edu> reh@wam.umd.edu (Richard Huddleston) writes:
>and, for the sake of simplicity, that we want to add a 14 bit subnet
>field with two bits left over for hosts at that subnet.
Note that this only allows for two hosts on the subnet, because addresses
with the host field all 0 and all 1 are reserved.
But this may be just the right thing if all the subnets in this network are
point-to-point links.
>Is the first subnet / host address like this:
>1001 1011 . 1001 1011 . 0000 0000 . 0000 01-01
>(155.155.0.5)
Yes.
Just ignore octet boundaries when dealing with addresses with subnet masks.
The IP address is just a 32-bit binary string, and the subnet portion is
just a 14-bit field. Strictly speaking, the subnet field doesn't even have
to be contiguous, but I've heard of implementations that don't handle
noncontiguous subnet fields well (but I've also heard of implementations
that don't handle non-octet-aligned subnets, either).
>this:
>1001 1011 . 1001 1011 . 0000 0000 . 0000 00-01
>(155.155.0.1)
The problem with this is that it uses subnet 0. As with host numbers,
all-0 and all-1 subnet numbers are reserved.
--
Barry Margolin
System Manager, Thinking Machines Corp.
barmar@think.com {uunet,harvard}!think!barmar
-----------[000201][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 93 23:01:48 GMT From: bobw@mge.uucp (bobw) To: comp.protocols.tcp-ip Subject: Routing with 3 class C net addresses
Hello, We're currently creating a TCP/IP network to link together 18 different sites. The sites are of different sizes, and they will be linked together with routers which will connect them via the national ISDN network. The primary need is to transfer data between the sites. We recently obtained three class C addresses, and we'll be subneting within each network address. Since the sites are of different sizes, to use the address space effectivly, we would like to use a different subnet mask for two of the three sites. This brings up several questions. 1. I assume that as long as the same subnet mask is used on a network, there is no reason why we cannot use different masks on each of the nets. Is this correct? 2. What do the routers "see"? To get from site one to site two I may be on a subnet on the same network, or on a subnet on another network. What would the static routes in the hosts look like, and what do those in the routers look like? 3. What happens to a domain name? I understand a domain name to be equated with a network, and not three separate nets. Thanks for any ideas. Please respond by e-mail, as I don't often have access to this newsgroup. Regards, Bob -- Robert Wornan | uucp: bobw@mge.uucp MG Entreprises | internet: bobw@mg-entreprises.fr 42 rue Voltaire | tel: +33 1 42 04 35 83 92800 Puteaux, France -- Robert Wornan | uucp: bobw@mge.uucp MG Entreprises | internet: bobw@mg-entreprises.fr 42 rue Voltaire | tel: +33 1 42 04 35 83 92800 Puteaux, France
-----------[000202][next][prev][last][first]---------------------------------------------------- Date: Sat, 16 Jan 1993 01:15:00 GMT From: Michael T. Keefe To: comp.protocols.tcp-ip Subject: Winqvtnet SLIP help... fine tuning help needed
Thanks to the insightful mail here, I have been able to get Winqvtnet working
over a SLIP connection (modem is a Courier Dual Standard).
I am getting the following error messages when using either the FTP or mail facility in the program:
IP: fragmented packet received, frags not supported
IP: apparent packet length error
IP: bad version number
Packet received for invalid port -- reset sent
Anybody have any ideas how I could fine tune my system to get rid of these error messages?
I am loading in the 3-pre windows files with the following parameters:
SLIP8250 -w 0x62 -h SLIP 4 0x03f8 38400
WINPKT.COM 0x60 0x62
PKTINT.COM
The problem is, I really have no idea where to look in order to correct the above.
Thanks in advance
=======================================
||\/|| || ||/ ||== Michael T. Keefe
\ /| || |// ||
|| || || |\ ||== Listening is an art which requires
|| || || |\\ || the skilled characteristic of listening
|| || || ||\\ ||==
-----------[000203][next][prev][last][first]---------------------------------------------------- Date: 16 Jan 93 15:52:07 GMT From: mperlman@nyx.cs.du.edu (Marshal "Airborne" Perlman) To: sci.space.shuttle,sci.space,comp.protocols.misc,comp.protocols.tcp-ip Subject: Re: Broadcasting shuttle audio over the Internet?
messages always help to have text attached to them.. -- |o| Marshal Perlman Internet: perlman@cs.fit.edu |o| |o| Florida Institute of Technology IRC: Squawk |o| |o| Melbourne, Florida Private Pilot, ASEL |o| |o| 407/768-8000 x8435 Goodyear Blimp Club Member |o|
-----------[000204][next][prev][last][first]---------------------------------------------------- Date: Sat, 16 Jan 1993 16:41:33 GMT From: larry@news.rn.com (Larry Snyder) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
anton@analsyn.gts.org (Anton J Aylward) writes: >In the article (<C0r1yp.3o4@ddsw1.mcs.com>) Karl Denninger (karl@ddsw1.mcs.com) posted to biz.comp.telebit.netblazer: >: In article <C0oBxC.Bvr@news.rn.com> larry@news.rn.com (Larry Snyder) writes: >: >Also, is it possible to put a v.35 board in a machine running Dell 2.2 >: >and do the routing under Unix? >: If you can find a driver for the board, certainly ;-) >Thats one BIG if. >I've been looking for a while nwo with no sucess. >I may end up writing my own! I believe I might have mentioned that Morningstar is working on a v.35 connection for the SCSI buss that will support up to a T1. Should be real neat -- and they plan on even supporting Dell 2.2! -- Larry Snyder internet: larry@gator.use.com keeper of the Gator uucp: uunet!gator!larry
-----------[000205][next][prev][last][first]---------------------------------------------------- Date: 16 Jan 93 17:16:27 GMT From: chris@visionware.co.uk (Chris Davies) To: comp.protocols.tcp-ip Subject: Re: RPC protocol specifications
Maritza Ramirez (maritza@espresso.bae.bellcore.com) wrote:
: I would appreciate if someone could tell me how the RPC protocol
: specifications can be obtained. Are they proprietary, or freely
: available on the internet ? (I am interested in the protocol
: specification of the "portmapper").
The RPC protocol is in the public domain, although it was invented at
Sun Microsystems. You can find information in RFCs 1014 and 1057, or
in the Nutshell book, "Power Programming with RPCs" published by
O'Reilly and Associates last year ('92). I don't know off hand where
you would find out specifically about the portmapper, and I don't think
that these RFCs cover it.
Chris
--
VISIONWARE LTD, 57 Cardigan Lane, LEEDS LS4 2LE, England
Tel +44 532 788858 x238. Fax +44 532 304676. Email chris@visionware.co.uk
---------- "VisionWare: The home of DOS/SQL/UNIX/X/VMS integration" ---------
-----------[000206][next][prev][last][first]---------------------------------------------------- Date: Sat, 16 Jan 1993 23:55:01 GMT From: xjeldc@lustorfs.ldc.lu.se (Jan Engvald LDC) To: comp.protocols.tcp-ip Subject: Re: Setting date and time on PC
In article <1993Jan12.031512.16593@samba.oit.unc.edu> tclark@med.unc.edu (Thomas B. Clark III) writes:
>Does anyone have any experience setting the PC's date and time
>from a UNIX time server using tcp/ip?
Yes, at our and many other universities we do it on most PCs all the time
using PDCLKSET. Here is the readme.1st file:
Jan E LDC
PDCLKSET sets the time and date of the PC clock using a TIME server.
It has daylight saveing (summer time) algorithms for most of the world.
It can use BOOTP to get IP number and other info.
PDCLKSET talks to the network card via a packet driver.
PDCLKSET can assign the proper normal or dls timezone name to
an environment variable (TZ is used by most systems).
There is also a very powerful buildt in ping/echo client and server giving
important statistics on delay, load and packet loss.
The PDTBUILD program, which is included in the ZIP package, looks
at all ARP broadcasts and generates hardware address tables with all the IP
hosts on this (sub)net. It detects IP and hardware address duplication.
And still, PDCLKSET is so small (13 KB) you can use it even on
diskette-only PCs.
For more info, see file PDCLKSET.DOC.
PDCLKxxx.ZIP is available at msdos.ftp.sunet.se:pub/network/pdclkset,
ftp.lu.se:pub/network/pdclkset, wsmr-simtel20.army.mil:PD1:<MSDOS.PKTDRVR>,
oak.oakland.edu:pub/msdos/pktdrvr, wuarchive.wustl.edu:mirrors/msdos/pktdrvr,
nic.funet.fi:pub/msdos/networks/pktdrvr, and probably other Simtel mirror
archives.
Happy timesetting!
_____________________________________________________________________________
Jan Engvald, Lund University Computing Center, Box 783, S-220 07 LUND, Sweden
Telephone: +46 46 107458, Telefax: +46 46 138225, Telex: 33533 LUNIVER S
E-mails: Jan.Engvald@ldc.lu.se, xjeldc@seldc52, psi%2403732202020::xjeldc
-----------[000207][next][prev][last][first]---------------------------------------------------- Date: 17 Jan 1993 05:04:09 GMT From: ralf@wpi.WPI.EDU (Ralph Valentino) To: comp.os.mach,comp.protocols.tcp-ip Subject: SLIP under Mach 3.0
Has anyone gotten SLIP to work under Mach 3.0? /etc/slattach from 2.6MSD reports "ioctl(TIOCSETD): No such device" when run under 3.0 mk77 ux37. Is there a publicly available version of SLIP that will work with Mach 3.0? Are there patches available to the kernel or emulator? -Ralph =============== Ralph Valentino (ralf@chpc.org) (ralf@wpi.wpi.edu) Hardware Engineer, Worcester Polytechnic Institute Center for High Performance Computing, Marlborough MA
-----------[000208][next][prev][last][first]---------------------------------------------------- Date: Sun, 17 Jan 1993 12:32:43 GMT From: bill@wrangler.WLK.COM (Bill Kennedy) To: comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
In article <C0yH19.AF1@news.rn.com> larry@news.rn.com (Larry Snyder) writes:
>
>I believe I might have mentioned that Morningstar is working on a v.35
>connection for the SCSI buss that will support up to a T1.
They're not working on it, they've been shipping it for over a year. It's
called SnapLink and it's V.36, not V.35 (most CSU/DSUs can be ordered with
V.36 or you can get a converter) and it handles an aggregate bit rate of
2.048Mbps through three spigots and a SCSI.
>Should be
>real neat -- and they plan on even supporting Dell 2.2!
They already support it on several platforms. I used it on SPARC and they
assured me it would work with any of their supported systems. In the Intel
world that means ISC, SCO, and BSDI, maybe others. It appears to the
kernel as a raw disk device and the Morning Star drivers handle the details.
A couple of caveats and they're neither complaints nor criticisms. The
SnapLink is quite small so they use the subminiature D connector for the
SCSI bus. There are a number of places who make adapter cables, I happen
to like CS Electronics in Tustin, CA. Also, V.36 and V.35 are not the
same. V.35 is that boxy looking thing with the screws through it, V.36 is
a DB37. As if the connector details weren't enough, V.36 is differential
and V.35 isn't. Be sure that what ever you hook it to is the right one.
I've run SnapLink at T1 speeds and it worked beautifully. Presumably you
could even do fractional T3 and stay within the 2.048Mbps limit but I have
not tried it. Finally, make sure you strap it for an appropriate SCSI ID.
It ships (or used to) as ID 3 and that's Sun's default boot disk.
SnapLink isn't a future, you can buy one today if you have an OS they
support and V.36 telecomm gear. I don't know what they're doing about
Dell 2.2 but I am dead certain they do ISC 3.x and even the old 2.2 (I
bought two licenses for that). It's a nice package and if you don't
need all of the modem handling goop in a NetBlazer, it's a painless plug
and play solution. By "painless" I mean that for a simple setup you can
eliminate a lot of stuff you might not otherwise want/need (a router
comes to mind), just hook up the hose and go.
--
Bill Kennedy bill@WLK.COM | Where there's a will there's a won't.
| NAPA auto parts commercial.
-----------[000209][next][prev][last][first]---------------------------------------------------- Date: Sun, 17 Jan 1993 16:37:01 +0000 From: proyse@peeras.demon.co.uk (Phil Royse) To: comp.protocols.tcp-ip Subject: Address conversion
In article <giT8wB1w165w@major.panix.com> dos@major.panix.com writes: >What I'm looking for is something along the lines of a router than could >hold an address translation table (which would, of course, have to be >generated by hand, but that's no problem), and convert addresses going >in both directions. Yes, I'm looking into this situation too. However, our requirement for address translation is for some different reasons - we are in the health field and have potentially thousands of IP entities (PCs, hubs, SNMP agents, bridges etc. over 60/100 LANs, but only a small amount of (true, ie. registered) Class B address space to work with. (We've been allocated the last 11 bits of a Class B (16 bit) "host" address space). This allows us 32 LANs with 64 PCs on each (nowhere near enough!) We are thinking along the lines of pooling the true addresses on a first come, first served basis, for internal users who wish to have real time access (e.g. FTP, Telnet) to the outside world (ie. the Internet). WE plan to use a private (non-registered Class A IP address structure **internally**. However, we will need an address translation process, which we think could be invoked on a router, particularly one based on UNIX or DOS, where one could pass each packet to the "address translator" before forwarding it. I believe it's workable. Do you have a problem with mapping the number of users on your second network, with the size of the "real" address space you've been allocated? Please keep me (or this group) informed of any leads, suggestions or comments in this matter; I will let you know if we do. Have you read RFC1335 "Two Tier address structure.... A solution to ..address space exhaustion" (Wang & Crowcroft, Univ. College, London)? It's good and throws some light on the issues. Phil Royse Comms Consultant | member: The Peer Association TUDOR HOUSE | (OSI & GOSIP specialists) 12 Woodside Road, Purley Surrey CR8 4LN (UK) Tel: (+44) 81 645-9868
-----------[000210][next][prev][last][first]---------------------------------------------------- Date: Sun, 17 Jan 1993 17:10:24 +0000 From: proyse@peeras.demon.co.uk (Phil Royse) To: comp.protocols.tcp-ip Subject: IP rollover
In article <C0x2Kp.FI9@apertus.com> stuarts@news.apertus.com writes: > >I was thinking that it might be possible to make a "router" that picks off >packets destined to IP.address.1 and "patch" the source and destination to >point to the "router" and IP.address.load_shared_ip and then drop the >packet back out onto the wire.... Yes, excellent idea. An organisation I am working for needs that too. One real problem is that of late replies (from the Internet), being sent to the **new** recipient... This is a real problem with any form of random address assignment. The same as (say) 20 mobile technicians, of whom 10 need to be out of the base at any time, sharing a pool of (say) 10 mobile phones. No user can rely on having the same phone (or IP address) two days running..... Could you explain your problem more? Phil Royse Comms Consultant | member: The Peer Association TUDOR HOUSE | (OSI & GOSIP specialists) 12 Woodside Road, Purley Surrey CR8 4LN (UK) Tel: (+44) 81 645-9868
-----------[000211][next][prev][last][first]---------------------------------------------------- Date: Sun, 17 Jan 1993 18:17:59 GMT From: rick@nsscmail.att.com (Rick Calder) To: comp.protocols.tcp-ip Subject: CSLIP : Exact setups w/ SVR4 slip also ??
I've scarfed back the cslip for SVR4, but the docs don't give me enough info on how to set it up. Can someone email/post their inetinit.cf file, and the slipd.conf if they are used ?? The confusion is that the ifconfig needs to know the interface, yet there isn't one defined in the inetinit.cf. Even so, it seems that it should get set from the slip.hosts and slip.config, but I don't see how. Sigh. thanks in advance, -- Rick Calder, NCR Systems Support Center - New Jersey [att!]rick!rick rick@rick.att.com attmail!rcalder
-----------[000212][next][prev][last][first]---------------------------------------------------- Date: Mon, 18 Jan 1993 05:41:12 GMT From: ae2@cunixa.cc.columbia.edu (Amiran Eliashvili) To: comp.protocols.tcp-ip Subject: multicasting
Greetings all: Does anyone have any experience with multicasting with sockets using UDP? If so, can you please shed some light on this matter -- references, examples or a paragraph or two would be highly appreciated. Thanks much /amiran
-----------[000213][next][prev][last][first]---------------------------------------------------- Date: 18 Jan 93 12:23:51 GMT From: uclyjjd@ucl.ac.uk (Julian Daley) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.protocols.nfs Subject: Slow ftp transfers with pktmux
Im trying to set up my pc using pktmux to let me load PCNFS and
then use CUTCP telnet, ftp etc.
This works fine, except for ftp.
*Without* pktmux, CUTCP's ftp gives me a transfer rate of approx
180 kbytes/sec to or from a Sun unix box, on the local ethernet.
*With* pktmux the transfer rate for PC-unix transfers is approx
60 kbytes/sec, and unix-PC transfers go down to just 9k bytes/sec.
NFS transfer rate isn't effected, about 200k bytes/sec for reads
from a unix box, 100k bytes/sec for writes.
I realise pktmux is doing some very clever things, but this decrease
in ftp performance does seem a bit dramatic, especially as the NFS
performance is unaffected.
I'm using
BICC 16 bit ethernet card
ISOLINK packet driver V10.2
PKTD.SYS V4.0.a3
PKTMUX V1.2a
Any ideas ?
Julian.
--
_____________________________________________________
| Julian Daley, j.daley@ucl.ac.uk |
| Department Clinical Physics, Guys Hospital, London. |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------[000214][next][prev][last][first]---------------------------------------------------- Date: Mon, 18 Jan 1993 13:00:31 GMT From: brians@atlastele.com (Brian Sheets) To: comp.protocols.tcp-ip,comp.sys.sequent Subject: Nameserver help?
I have set up a nameserver on my machine and some weird things are happening and I was wondering if someone could help me out. I am running Dynix 3.0.17.10 on an S3 using a dialup slip connection to PSI The probles I see are, 1) when I lose my connection I can't seem to talk on my local ethernet, When I telnet in to the the system it is very slow with a login prompt. One really weird thing is that "talk" say "target machine does not recoginize you". This happens whenever I am using named. Can someone help me out here??? -- Brian Sheets _ /| "TRUCK?! What truck?" Support Engineer \`o_O' Atlas Telecom Inc. ( ) -Raiders of the Lost Ark brians@atlastele.com U
-----------[000215][next][prev][last][first]---------------------------------------------------- Date: Mon, 18 Jan 1993 18:33:16 GMT From: bob@MorningStar.Com (Bob Sutterfield) To: comp.telebit.netblazer,comp.protocols.tcp-ip Subject: Re: Netblazer
(This is way off the charter of either of these newsgroups, it's
unrelated to the "Subject:" line, and I don't want to sound too
commercial, but I thought I'd clear up a couple of nits...)
In article <1993Jan17.123243.11474@wrangler.WLK.COM> bill@wrangler.WLK.COM (Bill Kennedy) writes:
In article <C0yH19.AF1@news.rn.com> larry@news.rn.com (Larry Snyder) writes:
I believe I might have mentioned that Morningstar is working on
a v.35 connection for the SCSI buss that will support up to a
T1.
They're not working on it, they've been shipping it for over a
year.
His "working on it" was in regard to our Dell port, I think. And
that's a little optimistic - we haven't started yet, though we have
MST PPP running on other SystemV's and it should be a straightforward
port. We're considering it, but we don't even have a copy of Dell's
UNIX here.
It's called SnapLink and it's V.36, not V.35 (most CSU/DSUs can be
ordered with V.36 or you can get a converter)
Most CSU/DSU makers call it RS-449.
Presumably you could even do fractional T3 and stay within the
2.048Mbps limit but I have not tried it.
I suspect you'd just start seeing more bit losses. It's just a cheap
little MC68302, don't expect too much from it!
--
Bob Sutterfield, Morning Star Technologies +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221 +1 800 558 7827
bob@MorningStar.Com +1 614 459 5054 (FAX)
-----------[000216][next][prev][last][first]---------------------------------------------------- Date: Mon, 18 Jan 1993 20:23:33 GMT From: martin@datacomm.ucc.okstate.edu (Martin McCormick) To: comp.protocols.tcp-ip Subject: Re: Who used TNAMED (IEN-116) any more? And why?
Some of the 3Com terminal servers use it if you set a certain soft switch. I was trying to set up a 3Com terminal server, once, and forgot to set the switch correctly. The terminal server, of course, couldn't find out the IP number of any host on our network. I bet, though, that some IEN116 packets were flying around each time I told the server to initiate a telnet connection to a named host. When I told it to use the DNS, everything woke up. Martin McCormick WB5AGZ Stillwater, OK O.S.U. Computer Center Data Communications Group
-----------[000217][next][prev][last][first]---------------------------------------------------- Date: Mon, 18 Jan 1993 21:35:11 GMT From: rhodes@da_vinci.it.uswc.uswest.com (William Rhodes) To: comp.protocols.tcp-ip Subject: tn3270 question
I have two questions about tn3270 (tn3270 is a telnet session that provides IBM 3270 terminal emulation). My first question is where to find information about the tn3270 protocol. I pulled code off the net but there was no documentation. My second question pertains to the tn3270 server portion. General this runs on a remote gateway having direct access to the main frame host. I'm trying to locate public domain code to modify to run on a UNIX server inorder to convert the tn3270 protocol into SNA. So far I've only been able to find the client portion of tn3270. Any pointers to the tn3270 server code or documentation on the protocol would be greatly appriciated thanks, Bill
-----------[000218][next][prev][last][first]---------------------------------------------------- Date: 18 Jan 93 22:03:51 GMT From: echan@skynet.intel.com (Eldon Chan ~ ) To: comp.protocols.tcp-ip Subject: Re: Vendor numbers for ethernet addresses
Thanks to all who replied to my message. It seems there is a more complete file
than rfc1340 at ftp.lcs.mit.edu.
From LEONARD@Arizona.edu Fri Jan 15 16:17:57 1993
Received: by scdt (5.57/10.0i); Fri, 15 Jan 93 16:17:48 -0800
Received: from hermes.intel.com by skynet.intel.com (4.1/SCDT-NMS)
id AA05838; Fri, 15 Jan 93 16:13:01 PST
Received: from Merlin.Telcom.Arizona.EDU by hermes.intel.com (5.65/10.0i); Fri, 15 Jan 93 16:11:31 -0800
Received: from Arizona.edu by Arizona.edu (PMDF #2381 ) id
<01GTK04DUQHC8WZKO7@Arizona.edu>; Fri, 15 Jan 1993 17:11:04 MST
Date: 15 Jan 1993 17:11:03 -0700 (MST)
From: Aaron Leonard <LEONARD@Arizona.edu>
Subject: Re: Vendor numbers for ethernet addresses
To: echan@skynet.intel.com
Message-Id: <01GTK04DUQHE8WZKO7@Arizona.edu>
X-Vms-To: IN%"echan@skynet.intel.com"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Status: RO
In article <C0wxAH.9CH@inews.Intel.COM> you write:
|
| Would someone tell me what vendor has ethernet address prefix
| 00:00:81
That vendor code belongs to Synoptics.
| ?
| I checked the rfc1340 (Assigned numbers), but it's not in there. Anyone have a
| more updated list ?
The best list is not in the RFC, but in the file pub/map/EtherNet-codes on
FTP.LCS.MIT.Edu. I'm appending the 11-Jan-1993 version of this file.
| Thanks much.
You're welcome,
Aaron
Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
"It's not a bug, it's a form of flow control."
- Jerry Leichter on why crash-prone Unix is a suitable
platform for NSFNET core routers
List of codes used on 802.3 and EtherNet networks.
Last update: 11-Jan-93
This file contains collected information on the various codes used on
IEEE 802.3 and EtherNet. There are three "pages", type codes, vendor
codes, and the uses of multicast (including broadcast) addresses. I
wish to thank the contributors, some are listed below and there are
almost certainly others that I have missed. A complete up-to-date
copy of this file may always be obtained with anonymous FTP from
FTP.LCS.MIT.Edu with the name pub/map/EtherNet-codes. Since this
information is from collected wisdom, there are certainly omissions.
I welcome any further additions which can be sent to me at
MAP=EtherNet-codes@LCS.MIT.Edu.
__
/| /| /| \ Michael A. Patton, Network Manager
/ | / | /_|__/ Laboratory for Computer Science
/ |/ |/ |atton Massachusetts Institute of Technology
This document started as a copy of one posted by Walter Urbaniak at
BBN. Additions and corrections have been freely contributed by the
following (as well as others whose names are forgotten):
Jeff Beadles Tektronix jeff@quark.wv.tek.com
Andrew E. Birner Zenith Electronics scsabir@tvgurus.hdtv.zenithe.com
Steve Boyd DSTO Materials Res. Lab.boyd@mrl.dsto.gov.au
Brent Callaghan Sun Brent.Callaghan@eng.sun.com
?? Caloccia (?) Stratus Computer, Inc. caloccia@abersoch.sw.stratus.com
Bob Clements BBN clements@bbn.com
Matt Crawford Fermilab crawdad@fncent.fnal.gov
W. Tait Cyrus Univ. of New Mexico cyrus@pprg.unm.edu
Ian Doak Newcastle Univ. (UK) I.D.Doak@newcastle.ac.uk
Mohamed el Lozy Harvard University ellozy@bess.harvard.edu
Robert M. Enger ANS enger@ans.net
Jan Engvald Lund Univ. Comp. Ctr Jan.Engvald@ldc.lu.se
Jim Geier SHARP HealthCare jcg@sharp.idx.com
Tom Graham HP trg@col.hp.com
Andrew R. Gray Crosfield Electronics ag@crosfield.co.uk
Bruce Hafford Gordian bruce@gordian.com
Patricia Hanagan FTP Software Inc. patty@ftp.com
Mente H. Heemstra State Univ. Groningen HEEMSTRA@RC.RUG.NL
Anders Hillbo ?? ahi@nada.kth.se
Charles Holmes TRW, Inc. cdh@gumby.dsd.trw.com
Stephen Hope ?? sph@logitek.co.uk
Przemek Klosowski NIST przemek@rrdstrad.nist.gov
Samuel Lam CTI skl@wimsey.bc.ca
Craig Leres Lawrence Berkeley Labs leres@ee.lbl.gov
John Robert LoVerso Xylogics, Inc. xylogics!loverso@bu-it.bu.edu
Charles T. Lukaszewski Open Systems Architects imp@osa.com
Malcolm McKenzie Aus. Inst. of Marine S. M_Mckenzie@aims.gov.au
Kurt Melden Cascade Communications kam@casc.com
Richard Milward UNC-Chapel Hill RICHARD.DVC@mhs.unc.edu
Stephen Northcott (??) US Navy (??) snorthc@relay.nswc.navy.mil
Paul O'Neill Oregon State Univ. pvo@oce.orst.edu
Bruce Orchard ??? orchard@eceserv0.ece.wisc.edu
Michael Patton MIT Lab. for Comp. Sci. MAP@LCS.MIT.Edu
Craig Paul Univ. Kansas(?) paul@lane.cc.ukans.edu
Jon Postel ISI (IANA) IANA@ISI.Edu
Bill Russell NYU russell@nyu.edu
Phillip A. Remaker cisco Systems remaker@cisco.com
Joyce Reynolds ISI (IANA) IANA@ISI.Edu
Jay Rosenbloom Univ. of Wisc.-Madison jrosen@noc.macc.wisc.edu
Harry Saal Network General hjs@lindy.stanford.edu
Michael A. Shiels ??? mshiels@tmsoftware.ca
Bill Sommerfeld MIT Project Athena wesommer@athena.mit.edu
Galen Tackett Lockheed TACKETT@eisner.decus.org
Chris Tengi Princeton tengi@princeton.edu
Brian Toomey Chipcom Corp. btoomey@chipcom.com
Robert Ullmann Prime Computer, Inc. ARIEL@en-c06.prime.com
Walter Urbaniak BBN Urbaniak@BBN.COM
Margot Utterback Harvard University utterbac@husc10.harvard.edu
James B. VanBokkelen FTP Software Inc. jbvb@ftp.com
R Brett Wormley Raycom Systems csun!raycom!brettw
Marc E. Zorn TRW, Inc. zorn@gumby.dsd.trw.com
"Type" Fields
The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after
the preamble) consist of the "Ethernet Type" or "IEEE802.3 Length"
field. The "Ethernet Type" values are managed by XEROX. Some
assignments are public (see + below), others private. Current
information includes: Xerox Public Ethernet Packet Type
documentation(Xerox Courier Vol. 3 Issue 4 October 1988); IEEE802.3
Std; NIC RFC1010; contributions from network managers and vendors.
Note Hex
@ 0000-05DC IEEE802.3 Length Field (0.:1500.)
+ 0101-01FF Experimental
0200 Xerox PUP (conflicts with 802.3 Length Field range) (see 0A00)
0201 Xerox PUP Address Translation (conflicts ...) (see 0A01)
0400 Nixdorf (conflicts with 802.3 Length Field)
+* 0600 Xerox NS IDP
0601 XNS Address Translation (3Mb only)
+*# 0800 DOD Internet Protocol (IP)
+ 0801 X.75 Internet
+ 0802 NBS Internet
+ 0803 ECMA Internet
+ 0804 CHAOSnet
+ 0805 X.25 Level 3
+* 0806 Address Resolution Protocol (ARP) (for IP and for CHAOS)
0807 XNS Compatibility
081C Symbolics Private
+ 0888-088A Xyplex
0900 Ungermann-Bass network debugger
0A00 Xerox IEEE802.3 PUP
0A01 Xerox IEEE802.3 PUP Address Translation
0BAD Banyan Systems
0BAF Banyon VINES Echo
1000 Berkeley Trailer negotiation
1001-100F Berkeley Trailer encapsulation for IP
1234 DCA - Multicast
* 1600 VALID system protocol
1989 Artificial Horizons ("Aviator" dogfight simulator [on Sun])
3C00 3Com NBP virtual circuit datagram (like XNS SPP) not registered
3C01 3Com NBP System control datagram not registered
3C02 3Com NBP Connect request (virtual cct) not registered
3C03 3Com NBP Connect repsonse not registered
3C04 3Com NBP Connect complete not registered
3C05 3Com NBP Close request (virtual cct) not registered
3C06 3Com NBP Close response not registered
3C07 3Com NBP Datagram (like XNS IDP) not registered
3C08 3Com NBP Datagram broadcast not registered
3C09 3Com NBP Claim NetBIOS name not registered
3C0A 3Com NBP Delete Netbios name not registered
3C0B 3Com NBP Remote adaptor status request not registered
3C0C 3Com NBP Remote adaptor response not registered
3C0D 3Com NBP Reset not registered
4242 PCS Basic Block Protocol
4321 THD - Diddle
% 5208 BBN Simnet Private
6000 DEC unassigned, experimental
6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance
6002 DEC Maintenance Operation Protocol (MOP) Remote Console
6003 DECNET Phase IV, DNA Routing
6004 DEC Local Area Transport (LAT)
6005 DEC diagnostic protocol (at interface initialization?)
6006 DEC customer protocol
6007 DEC Local Area VAX Cluster (LAVC), System Communication Architecture (SCA)
6008 DEC unassigned (AMBER?)
6009 DEC unassigned (MUMPS?)
+ 6010-6014 3Com Corporation
7000 Ungermann-Bass download
7001 Ungermann-Bass NIUs
7002 Ungermann-Bass diagnostic/loopback
7003 Ungermann-Bass ??? (NMC to/from UB Bridge)
7005 Ungermann-Bass Bridge Spanning Tree
7007 OS/9 Microware
7009 OS/9 Net?
+ 7020-7029 LRT (England) (now Sintrom)
7030 Racal-Interlan
7031 Prime NTS (Network Terminal Service)
7034 Cabletron
8003 Cronus VLN
8004 Cronus Direct
8005 HP Probe protocol
+ 8006 Nestar
+ 8008 AT&T/Stanford Univ. Local use
8010 Excelan
+ 8013 Silicon Graphics diagnostic
+ 8014 Silicon Graphics network games
+ 8015 Silicon Graphics reserved
+ 8016 Silicon Graphics XNS NameServer, bounce server
+ 8019 Apollo DOMAIN
+ 802E Tymshare
+ 802F Tigan, Inc.
+ 8035 Reverse Address Resolution Protocol (RARP)
+ 8036 Aeonic Systems
8037 IPX (Novell Netware?)
8038 DEC LanBridge Management
8039 DEC DSM/DDP
803A DEC unassigned (Argonaut Console?)
803B DEC unassigned (VAXELN?)
803C DEC unassigned (NMSV? DNA Naming Service?)
803D DEC Ethernet CSMA/CD Encryption Protocol
803E DEC Distributed Time Service
803F DEC LAN Traffic Monitor Protocol
8040 DEC unassigned (NetBios Emulator?)
8041 DEC unassigned (MS/DOS?, Local Area System Transport?)
8042 DEC unassigned
+ 8044 Planning Research Corp.
+ 8046 AT&T
+ 8047 AT&T
+ 8049 ExperData
+ 805B VMTP (Versatile Message Transaction Protocol, RFC-1045) (Stanford) [was Stanford V Kernel,
experimental]
+ 805C Stanford V Kernel, version 6.0
+ 805D Evans & Sutherland
+ 8060 Little Machines
+ 8062 Counterpoint Computers
+ 8065 University of Mass. at Amherst
+ 8066 University of Mass. at Amherst
+ 8067 Veeco Integrated Automation
+ 8068 General Dynamics
+ 8069 AT&T
+ 806A Autophon
+ 806C ComDesign
+ 806D Compugraphic Corporation
+ 806E-8077 Landmark Graphics Corporation
+ 807A Matra
+ 807B Dansk Data Elektronik
+ 807C Merit Internodal (or Univ of Michigan?)
+ 807D-807F Vitalink Communications
+ 8080 Vitalink TransLAN III Management
+ 8081-8083 Counterpoint Computers
8088-808A Xyplex
+ 809B EtherTalk (AppleTalk over Ethernet)
+ 809C-809E Datability
+ 809F Spider Systems Ltd.
+ 80A3 Nixdorf Computers
+ 80A4-80B3 Siemens Gammasonics Inc.
+ 80C0-80C3 DCA (Digital Comm. Assoc.) Data Exchange Cluster
+ 80C6 Pacer Software
+ 80C7 Applitek Corporation
+ 80C8-80CC Intergraph Corporation
+ 80CD-80CE Harris Corporation
+ 80CF-80D2 Taylor Instrument
+ 80D3-80D4 Rosemount Corporation
80D5 IBM SNA Services over Ethernet
+ 80DD Varian Associates
+ 80DE-80DF TRFS (Integrated Solutions Transparent Remote File System)
+ 80E0-80E3 Allen-Bradley
+ 80E4-80F0 Datability
+ 80F2 Retix
+ 80F3 AppleTalk Address Resolution Protocol (AARP)
+ 80F4-80F5 Kinetics
+ 80F7 Apollo Computer
+ 80FF-8103 Wellfleet Communications
8107-8109 Symbolics Private
812B Talaris
+ 8130 Waterloo Microsystems Inc.
+ 8131 VG Laboratory Systems
+ 8137 Novell (old) NetWare IPX (ECONFIG E option)
+ 8138 Novell, Inc.
+ 8139-813D KTI
814C SNMP over Ethernet (see RFC1089)
814F Technically Elite Concepts Network Professor
817D XTP
81D6 Lantastic
8582 Kalpana
8888 HP LanProbe test?
+ 9000 Loopback (Configuration Test Protocol)
9001 3Com (Formerly Bridge Communications), XNS Systems Management
9002 3Com (Formerly Bridge Communications), TCP/IP Systems Management
9003 3Com (Formerly Bridge Communications), loopback detection
AAAA DECNET? Used by VAX 6220 DEBNI
% FF00 BBN VITAL-LanBridge cache wakeups
* These protocols use Ethernet broadcast, where multicast would be preferable.
# BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3.
% BBN Private Protocols, not registered
+ These protocols are mentioned by Xerox in their October 1988 issue of
COURIER (page 8-9) as the publicly assigned numbers. Only vendors are
listed by Xerox, not what protocols. For more information about type field
assignments, contact: Pam DuPuy, Xerox Systems Instuture, (408)737-4652.
@ According to the October 1988 issue of COURIER (page 8), "if it is less
than 600H, the packet is assumed to be an 802.3 packet; if it is greater
than 600H, the packet is flagged as an Ethernet packet."
Vendor Addresses
Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits
(0-9, plus A-F, capitalized). These 12 hex digits consist of
the first/left 6 digits (which should match the vendor of the Ethernet interface
within the station) and the last/right 6 digits which specify the interface
serial number for that interface vendor.
Ethernet addresses might be written unhyphenated (e.g. 123456789ABC),
or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated
by octets (e.g. 12-34-56-78-9A-BC).
These addresses are physical station addresses, not multicast nor
broadcast, so the second hex digit (reading from the left)
will be even, not odd.
At present, it is not clear how the IEEE assigns Ethernet block addresses.
Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned
with that block or separately. A portion of the vendor block address
is reportedly assigned serially, with the other portion intentionally
assigned randomly. If there is a global algorithm for which addresses
are designated to be physical (in a chipset) versus logical
(assigned in software), or globally-assigned versus locally-assigned addresses,
some of the known addresses do not follow the scheme (e.g AA0003; 02xxxx).
000002 BBN (was internal usage only, no longer used)
00000C Cisco
00000E Fujitsu
00000F NeXT
000010 Hughes LAN Systems (formerly Sytek)
000011 Tektronix
000015 Datapoint Corporation
000018 Webster (?)
00001A AMD (?)
00001B Novell
00001D Cabletron
000020 DIAB (Data Intdustrier AB)
000021 SC&C
000022 Visual Technology
000029 IMC
00002A TRW
00003C Auspex
00003D AT&T
000044 Castelle
000046 ISC-Bunker Ramo, An Olivetti Company
000049 Apricot Ltd.
00004B APT A.P.T. Appletalk WAN router
00004F Logicraft 386-Ware P.C. Emulator
000052 ODS
000055 AT&T
00005A SK (Schneider & Koch in Europe and Syskonnect outside of Europe)
00005A Xerox 806 (unregistered)
00005D RCE
00005E U.S. Department of Defense (IANA)
00005F Sumitomo (?)
000062 Honeywell
000065 Network General
000069 Silicon Graphics(?)
00006B MIPS
00006E Artisoft, Inc.
000077 MIPS(?), Interphase(?)
000079 Net Ware (?)
00007A Ardent
00007B Research Machines
00007D Harris (3M) (old)
00007F Linotronic
000080 Dowty Network Services [Also shows as "Harris (3M) (new)" and/or "Imagen(?)" elsewhere]
000081 Synoptics
000084 Aquila (?), ADI Systems Inc.(?)
000086 Gateway (?), Megahertz Corporation(?)
000089 Cayman Systems Gatorbox
00008E Jupiter(?), Solbourne(?)
000093 Proteon
000094 Asante MAC
000095 Sony/Tektronix
000097 Epoch
000098 Cross Com
00009F Ameristar Technology
0000A0 Sanyo Electronics
0000A2 Wellfleet
0000A3 Network Application Technology (NAT)
0000A4 Acorn
0000A5 Compatible Systems Corporation
0000A6 Network General (internal assignment, not for products)
0000A7 Network Computing Devices (NCD) X-terminals
0000A8 Stratus Computer, Inc.
0000A9 Network Systems
0000AA Xerox Xerox machines
0000AC Apollo
0000AF Nuclear Data Acquisition Interface Modules (AIM)
0000B0 RND (RAD Network Devices)
0000B3 CIMLinc
0000B4 Edimax
0000B5 Datability Terminal Servers
0000B7 Dove Fastnet
0000BB ????????????????? seems to speak appletalk
0000BC Allen-Bradley
0000C0 Western Digital now SMC (Std. Microsystems Corp.)
0000C6 HP Intelligent Networks Operation (formerly Eon Systems)
0000C8 Altos
0000C9 Emulex Terminal Servers
0000D0 Develcon Electronics, Ltd.
0000D1 Adaptec, Inc. "Nodem" product
0000D4 PureData
0000D7 Dartmouth College (NED Router)
0000D8 3Com? Novell? PS/2
0000DD Gould
0000DE Unigraph
0000E2 Acer Counterpoint
0000E8 Accton Technology Corporation
0000EE Network Designers Limited(?)
0000EF Alantec
0000F0 Samsung
0000F3 Gandalf
0000F4 Allied Telesis, Inc.
0000F6 A.M.C. (Applied Microsystems Corp.)
0000F8 DEC (?)
0000FD High Level Hardware (Orion, UK)
000102 BBN BBN internal usage (not registered)
000143 IEEE 802
000163 NDC (National Datacomm Corporation)
000168 W&G (Wandel & Goltermann)
0001C8 Thomas Conrad Corp.
000852 Technically Elite Concepts
000855 Fermilab
001700 Kabel
00400B Crescendo (?)
004010 Sonic Mac Ethernet interfaces
004015 Ascom (?)
004027 Sigma (?)
00402B TriGem
00402F XDI (?)
004095 Eagle Technologies
00409D DigiBoard Ethernet-ISDN bridges
0040C5 Micom Communications Corp.
0040C8 Milan Technology Corp.
0040FB Cascade Communications Corp.
00608C 3Com (1990 onwards)
00800F SMC (Standard Microsystem Corp.)
008010 Commodore
008017 PFU
008019 Dayna Communications "Etherprint" product
00801B Kodiak Technology
008021 Newbridge Networks Corporation
008024 Kalpana
008029 Microdyne Corporation
00802D Xylogics, Inc. Annex terminal servers
00802E Plexcom, Inc.
008033 Formation (?)
008034 SMT-Goupil
008035 Technology Works
00803E Synernetics
00803F Hyundai Electronics
008051 ADC Fibermux
008052 Network Professor
00805C Agilis(?)
00807C FiberCom
008087 Okidata
00808A Summit (?)
00808C Frontier Software Development
008096 HDS (Human Designed Systems) X terminals
0080A1 Microtest
0080A3 Lantronix
0080AD Telebit
0080B2 NET (Network Equipment Technologies)
0080C0 Penril (?)
0080C2 IEEE 802.1 Committee
0080C7 Xircom, Inc.
0080C8 D-Link (also Solectek Pocket Adapters)
0080D0 Computer Products International
0080D3 Shiva Appletalk-Ethernet interface
0080D4 Chase Limited
0080D6 Apple Mac Portable(?)
0080D8 Network Peripherals
0080E3 Coral (?)
0080F1 Opus
0080F7 Zenith Communications Products
00AA00 Intel
00B0D0 Computer Products International
00DD00 Ungermann-Bass IBM RT
00DD01 Ungermann-Bass
00DD08 Ungermann-Bass
020406 BBN BBN internal usage (not registered)
020701 MICOM/Interlan DEC (UNIBUS or QBUS), Apollo, Cisco
026060 3Com
026086 Satelcom MegaPac (UK)
02608C 3Com IBM PC; Imagen; Valid; Cisco; Macintosh
02CF1F CMC Masscomp; Silicon Graphics; Prime EXL
02E6D3 BTI (Bus-Tech, Inc.) IBM Mainframes
080001 Computer Vision
080002 3Com (formerly Bridge)
080003 ACC (Advanced Computer Communications)
080005 Symbolics Symbolics LISP machines
080006 Siemens Nixdorf PC clone
080007 Apple
080008 BBN
080009 Hewlett-Packard
08000A Nestar Systems
08000B Unisys
08000D ICL (International Computers, Ltd.)
08000E NCR/AT&T
08000F SMC (Standard Microsystems Corp.)
080010 AT&T [misrepresentation of 800010?]
080011 Tektronix, Inc.
080014 Excelan BBN Butterfly, Masscomp, Silicon Graphics
080017 NSC (National Semiconductor Corp.)
08001A Data General
08001B Data General
08001E Apollo
08001F Sharp
080020 Sun
080022 NBI (Nothing But Initials)
080023 Matsushita Denso
080025 CDC
080026 Norsk Data (Nord)
080027 PCS Computer Systems GmbH
080028 TI Explorer
08002B DEC
08002E Metaphor
08002F Prime Computer Prime 50-Series LHC300
080036 Intergraph CAE stations
080037 Fujitsu-Xerox
080038 Bull
080039 Spider Systems
08003B Torus Systems
08003E Motorola VME bus processor modules
080041 DCA (Digital Comm. Assoc.)
080044 DSI (DAVID Systems, Inc.)
080045 ???? (maybe Xylogics, but they claim not to know this number)
080046 Sony
080047 Sequent
080049 Univation
08004C Encore
08004E BICC
080051 Experdata
080056 Stanford University
080057 Evans & Sutherland (?)
080058 ??? DECsystem-20
08005A IBM
080067 Comdesign
080068 Ridge
080069 Silicon Graphics
08006A ATTst (?)
08006E Excelan
080070 Mitsubishi
080074 Casio
080075 DDE (Danish Data Elektronik A/S)
080077 TSL (now Retix)
080079 Silicon Graphics
08007C Vitalink TransLAN III
080080 XIOS
080081 Crosfield Electronics
080083 Seiko Denshi
080086 Imagen/QMS
080087 Xyplex terminal servers
080089 Kinetics AppleTalk-Ethernet interface
08008B Pyramid
08008D XyVision XyVision machines
08008E Tandem
08008F Chipcom Corp.
080090 Retix, Inc. Bridges
10005A IBM
1000D4 DEC
1000E0 Apple A/UX (modified addresses for licensing)
400003 Net Ware (?)
475443 GTC (Not registered!) (This number is a multicast!)
484453 HDS ???
800010 AT&T [misrepresented as 080010? One source claims this is correct]
AA0000 DEC obsolete
AA0001 DEC obsolete
AA0002 DEC obsolete
AA0003 DEC Global physical address for some DEC machines
AA0004 DEC Local logical address for systems running DECNET
C00000 Western Digital (may be reversed 00 00 C0?)
EC1000 Enance Source Co., Ltd. PC clones(?)
Ethernet Multicast (including Broadcast) Addresses and uses
Ethernet Type
Address Field Usage
Multicast Addresses:
01-00-1D-00-00-00 -802- Cabletron PC-OV PC discover (on demand)
01-00-1D-42-00-00 -802- Cabletron PC-OV Bridge discover (on demand)
01-00-1D-52-00-00 -802- Cabletron PC-OV MMAC discover (on demand)
01-00-5E-00-00-00 0800 DoD Internet Multicast (RFC-1112)
through
01-00-5E-7F-FF-FF
01-00-5E-80-00-00 ???? DoD Internet reserved by IANA
through
01-00-5E-FF-FF-FF
01-00-81-00-00-02 ???? Synoptics Network Management
01-80-C2-00-00-00 -802- Spanning tree (for bridges)
01-80-C2-00-00-01 -802- 802.1 alternate Spanning multicast
through
01-80-C2-00-00-0F
01-80-C2-00-00-14 -802- OSI Route level 1 (within area) IS hello?
01-80-C2-00-00-15 -802- OSI Route level 2 (between area) IS hello?
01-80-24-00-00-00 8582 Kalpana Etherswitch every 60 seconds
01-DD-00-FF-FF-FF 7002 Ungermann-Bass boot-me requests
01-DD-01-00-00-00 7005 Ungermann-Bass Spanning Tree
03-00-00-00-00-10 80D5 (OS/2 1.3 EE + Communications Manager)
03-00-00-00-00-40 80D5 (OS/2 1.3 EE + Communications Manager)
09-00-02-04-00-01? 8080? Vitalink printer messages
09-00-02-04-00-02? 8080? Vitalink bridge management
09-00-07-00-00-00 -802- AppleTalk Zone multicast addresses
through
09-00-07-00-00-FC
09-00-07-FF-FF-FF -802- AppleTalk broadcast address
09-00-09-00-00-01 8005 HP Probe
09-00-09-00-00-01 -802- HP Probe
09-00-09-00-00-04 8005? HP DTC
09-00-0D-XX-XX-XX -802- ICL Oslan Multicast
09-00-0D-02-00-00 ???? ICL Oslan Service discover only on boot
09-00-0D-02-0A-38 ???? ICL Oslan Service discover only on boot
09-00-0D-02-0A-39 ???? ICL Oslan Service discover only on boot
09-00-0D-02-0A-3C ???? ICL Oslan Service discover only on boot
09-00-0D-02-FF-FF ???? ICL Oslan Service discover only on boot
09-00-0D-09-00-00 ???? ICL Oslan Service discover as required
09-00-1E-00-00-00 8019? Apollo DOMAIN
09-00-26-01-00-01? 8038 Vitalink TransLAN bridge management
09-00-2B-00-00-00 6009? DEC MUMPS?
09-00-2B-00-00-01 8039 DEC DSM/DDP
09-00-2B-00-00-02 803B? DEC VAXELN?
09-00-2B-00-00-03 8038 DEC Lanbridge Traffic Monitor (LTM)
09-00-2B-00-00-04 ???? DEC MAP End System Hello?
09-00-2B-00-00-05 ???? DEC MAP Intermediate System Hello?
09-00-2B-00-00-06 803D? DEC CSMA/CD Encryption?
09-00-2B-00-00-07 8040? DEC NetBios Emulator?
09-00-2B-00-00-0F 6004 DEC Local Area Transport (LAT)
09-00-2B-00-00-1x ???? DEC Experimental
09-00-2B-01-00-00 8038 DEC LanBridge Copy packets (All bridges)
09-00-2B-01-00-01 8038 DEC LanBridge Hello packets (All local bridges)
1 packet per second, sent by the
designated LanBridge
09-00-2B-02-00-00 ???? DEC DNA Level 2 Routing Layer routers?
09-00-2B-02-01-00 803C? DEC DNA Naming Service Advertisement?
09-00-2B-02-01-01 803C? DEC DNA Naming Service Solicitation?
09-00-2B-02-01-02 803E? DEC Distributed Time Service
09-00-2B-03-xx-xx ???? DEC default filtering by bridges?
09-00-2B-04-00-00 8041? DEC Local Area System Transport (LAST)?
09-00-2B-23-00-00 803A? DEC Argonaut Console?
09-00-39-00-70-00? ???? Spider Systems Bridge Hello packet?
09-00-4C-00-00-00 -802- BICC 802.1 management
09-00-4C-00-00-02 -802- BICC 802.1 management
09-00-4C-00-00-06 -802- BICC Local bridge STA 802.1(D) Rev6
09-00-4C-00-00-0C -802- BICC Remote bridge STA 802.1(D) Rev8
09-00-4C-00-00-0F -802- BICC Remote bridge ADAPTIVE ROUTING (e.g. to Retix)
09-00-4E-00-00-02? 8137? Novell IPX (BICC?)
09-00-56-00-00-00 ???? Stanford reserved
through
09-00-56-FE-FF-FF
09-00-56-FF-00-00 805C Stanford V Kernel, version 6.0
through
09-00-56-FF-FF-FF
09-00-77-00-00-00 -802- Retix Bridge Local Management System
09-00-77-00-00-01 -802- Retix spanning tree bridges
09-00-77-00-00-02 -802- Retix Bridge Adaptive routing
09-00-7C-01-00-01 ???? Vitalink DLS Multicast
09-00-7C-01-00-03 ???? Vitalink DLS Inlink
09-00-7C-01-00-04 ???? Vitalink DLS and non DLS Multicast
09-00-7C-02-00-05 8080? Vitalink diagnostics
09-00-7C-05-00-01 8080? Vitalink gateway?
09-00-7C-05-00-02 ???? Vitalink Network Validation Message
09-00-87-80-FF-FF 0889 Xyplex Terminal Servers
09-00-87-90-FF-FF 0889 Xyplex Terminal Servers
0D-1E-15-BA-DD-06 ???? HP
80-01-43-00-00-00 -802- Bridge
80-01-43-00-00-08 -802- Bridge Management
80-01-43-00-00-28 -802- ISO 10589 level-1 Intermediate Stations
80-01-43-00-00-48 -802- Loadable Device
80-01-43-00-00-88 -802- Load Server
80-01-43-00-00-A8 -802- ISO 10589 level-2 Intermediate Stations
80-01-43-00-80-00 -802- FDDI RMT Directed Beacon
80-01-43-00-80-08 -802- FDDI status report frame
90-00-D4-00-00-20 -802- OSI Network Layer Intermediate Stations
90-00-D4-00-00-A0 -802- OSI Network Layer End Stations
AB-00-00-01-00-00 6001 DEC Maintenance Operation Protocol (MOP)
Dump/Load Assistance
AB-00-00-02-00-00 6002 DEC Maintenance Operation Protocol (MOP)
Remote Console
1 System ID packet every 8-10 minutes, by every:
DEC LanBridge
DEC DEUNA interface
DEC DELUA interface
DEC DEQNA interface (in a certain mode)
AB-00-00-03-00-00 6003 DECNET Phase IV end node Hello packets
1 packet every 15 seconds, sent by each DECNET host
AB-00-00-04-00-00 6003 DECNET Phase IV Router Hello packets
1 packet every 15 seconds, sent by the DECNET router
AB-00-00-05-00-00 ???? Reserved DEC
through
AB-00-03-FF-FF-FF
AB-00-03-00-00-00 6004 DEC Local Area Transport (LAT) - old
AB-00-04-00-xx-xx ???? Reserved DEC customer private use
AB-00-04-01-xx-yy 6007 DEC Local Area VAX Cluster groups
System Communication Architecture (SCA)
C0-00-00-00-00-01 -802- Active Monitor
C0-00-00-00-00-02 -802- Ring Parameter Monitor
C0-00-00-00-00-04 -802- Network Server Heartbeat
C0-00-00-00-00-08 -802- Ring Error Monitor
C0-00-00-00-00-10 -802- Configuration Report Server
C0-00-00-00-00-20 -802- Synchronous Bandwidth Manager
C0-00-00-00-00-40 -802- Locate - Directory Server
C0-00-00-00-00-80 -802- NETBIOS
C0-00-00-00-01-00 -802- Bridge
C0-00-00-00-02-00 -802- IMPL Server
C0-00-00-00-04-00 -802- Ring Authorization Server
C0-00-00-00-08-00 -802- LAN Gateway
C0-00-00-00-10-00 -802- Ring Wiring Concentrator
C0-00-00-00-20-00 -802- LAN Manager
C0-00-00-00-80-00 -802-
through user-defined
C0-00-40-00-00-00 -802-
CF-00-00-00-00-00 9000 Ethernet Configuration Test protocol (Loopback)
FF-FF-00-60-00-04 81D6 Lantastic
FF-FF-00-40-00-01 81D6 Lantastic
FF-FF-01-E0-00-04 81D6 Lantastic
Broadcast Address:
FF-FF-FF-FF-FF-FF 0600 XNS packets, Hello or gateway search?
6 packets every 15 seconds, per XNS station
FF-FF-FF-FF-FF-FF 0800 IP (e.g. RWHOD via UDP) as needed
FF-FF-FF-FF-FF-FF 0804 CHAOS
FF-FF-FF-FF-FF-FF 0806 ARP (for IP and CHAOS) as needed
FF-FF-FF-FF-FF-FF 0BAD Banyan
FF-FF-FF-FF-FF-FF 1600 VALID packets, Hello or gateway search?
1 packets every 30 seconds, per VALID station
FF-FF-FF-FF-FF-FF 8035 Reverse ARP
FF-FF-FF-FF-FF-FF 807C Merit Internodal (INP)
FF-FF-FF-FF-FF-FF 809B EtherTalk
FF-FF-FF-FF-FF-FF 9001 3Com (ex Bridge) Name Service
FF-FF-FF-FF-FF-FF 9002 3Com PCS/TCP Hello, Approx. 1 per minute per w/s
--
Eldon Chan
Intel Corpoartion
Design Technology
Networking group Phone: 408-765-4992
echan@scdt.intel.com Fax: 408-765-5719
-----------[000219][next][prev][last][first]---------------------------------------------------- Date: Mon, 18 Jan 1993 22:16:33 GMT From: mishkin@apollo.HP.COM (Nathaniel Mishkin) To: comp.protocols.tcp-ip Subject: Re: RPC protocol specifications
In article <1993Jan16.171627.4522@visionware.co.uk>, chris@visionware.co.uk (Chris Davies) writes:
>Maritza Ramirez (maritza@espresso.bae.bellcore.com) wrote:
>: I would appreciate if someone could tell me how the RPC protocol
>: specifications can be obtained. Are they proprietary, or freely
>: available on the internet ?
>
>The RPC protocol is in the public domain, although it was invented at
>Sun Microsystems.
Y'know, it's not like I like to be petty or anything, or that I can't
live with a little looseness in terminology, but one thing that just
sends me off the deep end is when people use the terms "RPC" and "Remote
Procedure Call" as synonyms for Sun's RPC. Many other RPC systems have
come before and after Sun's. (The term "RPC" was in wide use before
Sun ever implemented an RPC system.) Sun seems to tend to call their
RPC system either "Sun RPC" or "ONC RPC".
Of course, I'm also a guy who never could understand how the generic
phrase "personal computer" (or "PC") became synonymous with "IBM compatible
PC".
Flames to /dev/null. Thank you.
--
-- Nat Mishkin
Distributed Computing Program
Hewlett-Packard Company
mishkin@apollo.hp.com
-----------[000220][next][prev][last][first]---------------------------------------------------- Date: Tue, 19 Jan 1993 00:49:47 GMT From: atkinson@itd.nrl.navy.mil (Randall Atkinson) To: comp.protocols.tcp-ip,comp.sys.hp Subject: Re: RPC protocol specifications
Someone else commented: >>The RPC protocol is in the public domain, although it was invented at >>Sun Microsystems. In article <C12LvM.7st@apollo.hp.com> mishkin@apollo.HP.COM (Nathaniel Mishkin) writes: > Y'know, it's not like I like to be petty or anything, or that I can't > live with a little looseness in terminology, but one thing that just > sends me off the deep end is when people use the terms "RPC" and "Remote > Procedure Call" as synonyms for Sun's RPC. Many other RPC systems have > come before and after Sun's. Nat, It is very simple. The ONLY freely distributable online specification for RPC was put out there by Sun. Had HP put out such a spec first, folks would use RPC to mean the HP version. Same exact story with NFS. NFS is not the world's best distributed file system, but it was the ONLY one specified openly in an RFC so that anyone on the planet could implement it. The way to win at the open systems vendor game is to be completely open with specifications (e.g. NFS, RPC as RFCs online) and just build the best implementation of that spec. Licensing specs and sample implementations is at best a poor second cousin and HP as a group has not learned this yet (though you individually might understand this). ANYONE on the planet can write an informational status RFC describing ANY information, specification, or protocol that they wish. There is even a long tradition of "April Fool's" RFCs that are mostly humour. HP should write some RFCs on things and use the RFC mechanism to place specifications in the open world. You'd be surprised how effective that mechanism is at getting your technology adopted and supported from the grass roots of the networking world. I'm not impressed with sour grapes, especially from one of the founding firms of the Closed Software Foundation (i.e. OSF). Ran atkinson@itd.nrl.navy.mil
-----------[000221][next][prev][last][first]---------------------------------------------------- Date: Tue, 19 Jan 93 10:07:14 EST From: dos@major.panix.com (Dave O'Shea) To: comp.protocols.tcp-ip Subject: Re: Address conversion
proyse@peeras.demon.co.uk (Phil Royse) writes: > >What I'm looking for is something along the lines of a router than could > >hold an address translation table (which would, of course, have to be > >generated by hand, but that's no problem), and convert addresses going > >in both directions. > > However, we will need an address translation process, which we think > could be invoked on a router, particularly one based on UNIX or > DOS, where one could pass each packet to the "address translator" > before forwarding it. I believe it's workable. I'm certain it is; obviously there would be some limitations - if an address is transmitted as part of the data, it would not get translated. As long as the person at the SNMP console is aware of this, tere's no problem. (though I could see it confusing the bejeezus out of a certain topology-mapping program!) But no luck; I've checked with all the major vendors, and not one of them seems to have a box that will do this kind of address translation. > Do you have a problem with mapping the number of users on > your second network, with the size of the "real" address space > you've been allocated? Neither, really - it's simply that there's a small group which picked out some bogus addresses a Long Time Ago, and changing it would be more trouble than it's worth - they would simply have to stay unconnected. > Please keep me (or this group) informed of any leads, suggestions > or comments in this matter; I will let you know if we do. Will do! > Have you read RFC1335 "Two Tier address structure.... A solution to > ..address space exhaustion" (Wang & Crowcroft, Univ. College, London)? > It's good and throws some light on the issues. Only briefly, and it does offer an interesting work-around - but not suited to the "canned" applications we have here that expect "standard" addresses.
-----------[000222][next][prev][last][first]---------------------------------------------------- Date: Tue, 19 Jan 1993 06:59:23 GMT From: dboyes@is.rice.edu (David E Boyes) To: comp.protocols.tcp-ip Subject: Re: Who used TNAMED (IEN-116) any more? And why?
In article <jpc.726775541@avdms8.msfc.nasa.gov> jpc@avdms8.msfc.nasa.gov (J. Porter Clark) writes:
>I've noticed (via log_tcp) a few random connections from a couple of
>machines to the obsolete (or so I thought) IEN-116 trivial name service
>port.
>
>Who would want to use trivial name service?
Prime's TCP implementation still uses IEN-116, or does on the
version we have here. For some reason, they never quite made it
to DNS.
--
David Boyes In the event I am captured or killed, Rice University
dboyes@rice.edu and the Office of Networking and Computing Systems
will deny any knowledge of my opinions.
-----------[000223][next][prev][last][first]---------------------------------------------------- Date: 19 Jan 93 11:04:54 GMT From: cambler@zeus.calpoly.edu (Christopher J. Ambler, Phish) To: comp.protocols.tcp-ip,comp.unix.xenix.sco Subject: Need help with TCP 1.1.1b (SCO UNIX)
Machine: 386/40 OS: SCO UNIX sys V 3.2.2 TCP: 1.1.1b (yeah, I know, it's old) The problem is that telnet, finger, and ping work fine. FTP, however, exhibits the following error message: NOTICE: tcp sum: src cccccccc, sum cccccccc where cccccccc is replaced with a number. A netstat -s shows that for each message, I'm getting a "discarded for back checksums" packet in the tcp portion. This also happens over NNTP telnet sessions (port 119), but NOT during interactive telnet sessions. My first thought is that it's the speed I'm at. I'm running over ISDN, at 38.4BPS into a serial card, and running SLIP. But, the serial card has a 16550, and SHOULD accept the speed. Can anyone shed any light on the situation? I'm VERY frustrated at this point, after spending all night getting CNews & NNTP up and running :-) Thanks in advance!! -- SO WE'RE SUPPOSED TO PLAY IN | cambler@zeus.calpoly.edu | Think Snow! CURITIBA IN 18 HOURS, BUT OUR | (805) 756-6634/ISDN |------------------- BUS IS BEING HELD HOSTAGE BY | Because all you of | Stop that! You'll THE LOCAL PROMOTERS. -- INSOC | Earth are IDIOTS!! | go blind!
-----------[000224][next][prev][last][first]---------------------------------------------------- Date: Tue, 19 Jan 93 16:33:17 EST From: MACE@HDQCMS2H.UTSD.ATT.COM To: comp.protocols.tcp-ip Subject: Anyone know of a good LPR/LPD Server?
We have 10 LaserJet printers which we would like to connect to a LPD server, for access by our OS/2, DOS/Windows and IBM VM/CMS users. We would rather not use LPD on various machines directly connected to the printers, since we would lose access to the printer when the machine went down (was re-booted or powered off). The connections would be serial (RS-232), with one connection being parallel. We have looked at the Lantronix equipment, but that does not really offer LPD; since we have a diverse user community, we want to use the LPR and LPRMON software that is provided with the TCP/IP implementations. Does anyone have any suggestions? -------------------------------------------------------------------------- Mace Moneta, AT&T VM Product Engineering, Piscataway, NJ --------------------------------------------------------------------------
-----------[000225][next][prev][last][first]---------------------------------------------------- Date: Tue, 19 Jan 1993 12:13:54 GMT From: "Scott Guthery" <p00197@psilink.com> To: comp.protocols.tcp-ip Subject: SMTP for UCX?
Anybody know of a SMTP that works with DEC's UCX (VAX/VMS) package? Thanks, Scott
-----------[000226][next][prev][last][first]---------------------------------------------------- Date: Tue, 19 Jan 1993 19:38:27 GMT From: nfb@mitre.org To: comp.protocols.tcp-ip Subject: Communicating With Wang Systems
I have a task of providing communications between a
Wang VS system and a Sun workstation, and I am in the process
of getting information on the Wang TCP/IP - telnet (limited)
offering. I would really like more than just the SMTP and telnet
that this gives, but that could be a start.
I would much appreciate hearing from people that have done
similar things with Wang systems and can offer their experiences,
as well as leads to groups or people I can contact for assistance.
Also, feel free to suggest a more appropriate news group to post
this message to.
Thanks.
Norman F. Brickman
Internet: nfb@mitre.org
-----------[000227][next][prev][last][first]---------------------------------------------------- Date: Tue, 19 Jan 1993 22:36:13 GMT From: johnr@pacdata.com (John Reed) To: comp.protocols.tcp-ip Subject: Need bootp client code
Can a kind soul tell me where to find an example implementation of
bootp client code?
I have looked on uunet, but only found the server code (bootp.2.1.tar.Z).
Thanks.
JR
--
/------------------------------------------------------------------\
| John Reed {ucsd,uunet}!pacdata!johnr |
| Pacific Data Products johnr@pacdata.com |
\------------------------------------------------------------------/
-----------[000228][next][prev][last][first]---------------------------------------------------- Date: Tue, 19 Jan 1993 22:37:59 GMT From: jswanson@csfb1.fir.fbc.com (James Swanson) To: comp.protocols.tcp-ip Subject: Looking for a sliding-frame file transfer package
I am looking for a sliding frame file transfer facility to use over an internet network. Probably a UDP/IP based thing. Does anyone know of anything that would help? Maybe some PD routines to help? Thanks. -- Jim Swanson First Boston Corporation 5WTC - 9th floor New York, NY 10048 (212)322-1085
-----------[000229][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 1993 14:04:47 -0800 From: smiller@aludra.usc.edu (Stephen B. Miller) To: comp.protocols.tcp-ip Subject: Re: Determining Port Numbers & The RPC Portmapper
In article <1993Jan20.162611.25831@walter.bellcore.com> maritza@espresso.bae.bellcore.com (Maritza Ramirez) writes: > > >I am trying to look for a solution to the problem of determining an >unknown remote port number. I will appreciate any comments on the >following situation: > > [text deleted, see earlier posting] > >Maritza > I am beginning to work an identical problem here, but have not come up with much more than you. I have considered trying the dynamic update features in the BIND 4.8.3 code, but they are so poorly documented that I might be better off writing my own application. My situation is further complicated by then need to change the port number assignments dynamically, which might be done by deregistering and reregistering with the portmapper. If anyone else has ideas please feel free..... Steve Miller - smiller@aludra.usc.edu
-----------[000230][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 93 01:40:00 GMT From: gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546) To: comp.protocols.tcp-ip Subject: Re: SMTP for UCX?
In article <2936527978.2.p00197@psilink.com>, guthery@slcs.slb.com writes... #Anybody know of a SMTP that works with DEC's UCX (VAX/VMS) package? # #Thanks, Scott 1. TGV MultiNet's SMTP package works with DEC UCX or their own IP. (1-800-TGV-3440, Sales@TGV.COM) 2. PMDF from Innosoft International (sales@innosoft.com) 3. MX which is public domain at an FTP site near you. Ehud -- Ehud Gavron (EG76) gavron@vesta.sunquest.com Yow! I just went below the poverty line!
-----------[000231][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jan 1993 02:32:55 GMT From: skl@wimsey.bc.ca (Samuel Lam) To: comp.protocols.tcp-ip Subject: Re: Who used TNAMED (IEN-116) any more? And why?
In article <1993Jan18.202333.28115@osuunx.ucc.okstate.edu>, martin@datacomm.ucc.okstate.edu (Martin McCormick) wrote: >Some of the 3Com terminal servers use it if you set a certain soft switch. Cisco terminal servers and routers can also be configured to use it. If you configure the box to use both DNS and IEN-116, it will query the IEN-116 universe if it couldn't get an answer from the DNS universe. ...Sam -- <skl@wimsey.bc.ca> -- Connectivity Technology Inc.
-----------[000232][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jan 1993 04:35:29 GMT From: lo@ipc5.lat.oz.au (Anthony C C Lo) To: comp.protocols.tcp-ip Subject: TLI Programming on SunOS
Hello all, Recently, I've been trying to write communication programs using the SunOS 4.1.1 Transport Layer Interface (TLI). I'm using asynchronous mode. The SunOS manuals mentioned about asynchronous execution mode, and the examples given made some assumptions like "/dev/tivc" which is fake. Does anybody have experience with this and be able to program the TLI? Any ideas and suggestions are most welcome. Thanks in advance. Anthony LO Dept. of Computer Science & Computer Engineering, La Trobe University, Bundoora 3083 Australia. E-mail: lo@latcs1.lat.oz.au
-----------[000233][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jan 1993 11:13:25 From: jbvb@vax.ftp.com (James B. VanBokkelen) To: comp.protocols.tcp-ip Subject: Re: tn3270 question
In article <C12Jyn.M72@da_vinci.it.uswc.uswest.com> rhodes@da_vinci.it.uswc.uswest.com (William Rhodes) writes:
...My first question is where to find information about the tn3270
protocol....
There is no formal spec. RFC 1123 has a brief mention of the underlying
mechanism (see sections 3.2.7 and 3.3.2) but doesn't connect it with
the name "tn3270". Note that RFC 1041 **DOES NOT* describe current
"tn3270" practice. There has been some effort towards a formal spec,
possibly with extensions to deal with things the current protocol doesn't
handle, like attached printers, but there's not even a draft yet.
James B. VanBokkelen 2 High St., North Andover, MA 01845
FTP Software Inc. voice: (508) 685-4000 fax: (508) 794-4488
-----------[000234][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 93 07:28:14 GMT From: alana@vpbuild.vp.com (Alan Anderson) To: comp.protocols.tcp-ip Subject: TCP/IP Server defunct processes
I am having a problem with defunct processes from clients
connecting to the following server code. Stevens refers to the
zombie processes for a concurrent server but I can't find where
he solves the problem. If anyone can help with this problem I
would greatly appreciate it. We are currently running NPROC @
750 processes and can't get through 1 day.
?? would running the server under inetd solve the problem ??
Please just mail me any ideas, if you need to see the client
code, I will mail it to you.
Thanks
Alan Anderson
Varco-Pruden Buildings
6000 Poplar, Suite 400
Memphis, TN 38119
alana@vpbuild.vp.com
Header/declaration stuff was here....
if ((s = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
printf("Could not open stream socket.");
exit(1);
}
bzero(&sin, sizeof(sin));
sin.sin_family = AF_INET;
sin.sin_addr.s_addr = htonl(INADDR_ANY);
sin.sin_port = htons(SERV_TCP_PORT);
if (bind(s, &sin, sizeof(sin)) == -1) {
printf("Could not bind local address.");
exit(1);
}
if (listen(s, 5) == -1) {
printf("Could not listen to socket.");
exit(1);
}
while(1)
{
/*
* Wait for a connection
*/
clilen = sizeof(cli_addr);
if ((ns = accept(s, (struct sockaddr *) &cli_addr,
&clilen)) == -1) {
printf("Error from accept.");
exit(1);
}
if ((pid = fork()) < 0) {
printf("Error from fork.");
exit(1);
}
if (pid == 0)
{ /* This is the child */
while(1)
{
if ((pid = readline(ns, buffer,
sizeof(buffer))) == -1)
{
printf("Error from read.");
exit(1);
}
buf = strtok(buffer, sep);
switch (buf[0])
{
case 'S':
goto bail_out;
Other instructions are processed here...
default:
printf(" Un-Identified call to server, buffer = <%s> \n",
buffer);
break;
}
}
bail_out:
printf("Bail Out was called, child is dead \n");
close (ns);
exit(0);
}
close (ns);
}
exit(0);
}
-----------[000235][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 93 09:02:56 GMT From: ishikawa@personal-media.co.jp (Chiaki Ishikawa) To: comp.org.ieee,comp.dcom.lans.ethernet,comp.protocols.tcp-ip Subject: Question: How to register a company for Ethernet product?
A colleague of mine is trying to find out how to register the company I work for in order to obtain a unique ID that is burned into ROM (EPROM, and others) for a network product. He vaguely recalls that either IEEE or some organizations have a registration mechanism to hand out unique IDs to hardware product manufacturers. The ID, I understand, helps to make sure the low-level network board have unique identification. Will any kind soul let me know where and who to contact to proceed with this registration? Since this may not be much of an interest to many readers, I would appreciate if you could send an e-mail to my e-mail address. Thank you in advance. Chiaki Ishikawa, Personal Media Corp., MY Bldg, 1-7-7 Hiratsuka, Shinagawa, Tokyo 142, JAPAN. FAX:+81-3-5702-0359, Phone:+81-3-5702-0351 UUNET: ishikawa@personal-media.co.jp
-----------[000236][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jan 1993 12:35:16 GMT From: duru@cc.ec-lyon.fr (Thalie) To: comp.protocols.tcp-ip Subject: SNMP
Does someone know where I could get doc about SNMP protocol (I already have RFCs about SNMP).
Please e-mail me any answer (I don't read newsgroups very often, since I only
have telnet access to them), thanks
Emmanuel Duru ("Thalie")
duru@cc.ec-lyon.fr
Ecole Centrale de Lyon
36 avenue Guy de Collongue
69130 Ecully - France
-----------[000237][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jan 1993 12:55:53 GMT From: ian@unipalm.co.uk (Ian Phillipps) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: TELNET terminal types
jbvb@vax.ftp.com (James B. VanBokkelen) writes: >PC/TCP defaults to RFC 1060, but we let users configure their own >names if they choose. It would be nice if people paying for "support" >from the various Unix vendors submitted this problem as a bug - the >actual work of adding aliases wouldn't take them more than 1 day of a >junior engineer's time, and the Internet would become a *lot* better. I agree, but I'm sure that a lot of people do what we have: add the RFC name to /etc/termcap and terminfo our own server. Elapsed time: 10 minutes, of which most spent consulting terminfo manuals :-) Alternative is a bug report, which would take a lot longer and probably be ineffective. No, we haven't logged a bug report. Ian -- Ian Phillipps, Unipalm Ltd, 216 Science Park, Phone +44 223 420002 Milton Road, Cambridge, CB4 4WA, England. Phax +44 223 426868 PIPEX is a division of Unipalm Ltd. - phone 0223 424616.
-----------[000238][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jan 1993 15:05:30 GMT From: rh0083b@medtronic.COM (Roger-Hunen) To: comp.protocols.tcp-ip,comp.unix.xenix.sco Subject: Re: Need help with TCP 1.1.1b (SCO UNIX)
cambler@zeus.calpoly.edu (Christopher J. Ambler, Phish) writes: > Machine: 386/40 > OS: SCO UNIX sys V 3.2.2 > TCP: 1.1.1b (yeah, I know, it's old) > > The problem is that telnet, finger, and ping work fine. FTP, however, > exhibits the following error message: > > NOTICE: tcp sum: src cccccccc, sum cccccccc > > where cccccccc is replaced with a number. A netstat -s shows that for > each message, I'm getting a "discarded for back checksums" packet in > the tcp portion. > > This also happens over NNTP telnet sessions (port 119), but NOT during > interactive telnet sessions. > > My first thought is that it's the speed I'm at. I'm running over ISDN, > at 38.4BPS into a serial card, and running SLIP. But, the serial card > has a 16550, and SHOULD accept the speed. > > Can anyone shed any light on the situation? I'm VERY frustrated at > this point, after spending all night getting CNews & NNTP up and > running :-) One possibility is that since FTP accesses the disk while TELNET, PING and FINGER do not, interrupts may be disabled for too long. As a result some bytes may be missed. Regards, -Roger (I speak for myself)
-----------[000239][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jan 1993 15:08:47 GMT From: zambrano@dit.upm.es (Jose Manuel Martinez Zambrano) To: comp.protocols.tcp-ip Subject: Q: XDP UDP RTP protocols info needed
I'm looking for any references/papers or public domain implementations of the RTP, UDP and RTP protocols. Actually we're beginning the analisis and specification of a distributed and multimedia educational application and any information on these or anothers protocols suitable for the task are welcome. Please, mail me and i'll summarize. Thanks in advance, Jose. -- +--------------------------------------+------------------------------------+ | Jose Manuel Martinez Zambrano | email: zambrano@dit.upm.es | | Dpto. Ingenieria Sist. Telematicos | | | E.T.S.I.Telecomunicacion | Telf: +34 1 5495700 ext:445 | | Ciudad Universitaria | Fax: +34 1 3367333 | | E-28040 MADRID | Tlx: 47430 ETSIT E | +--------------------------------------+------------------------------------+
-----------[000240][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jan 1993 15:16:25 GMT From: atkinson@itd.nrl.navy.mil (Randall Atkinson) To: comp.protocols.tcp-ip Subject: Re: SNMP
There is discussion of SNMP in comp.protocols.snmp for sites carrying the INET distribution. SNMP documents are available online as part of the RFC series of documents. Each RFC ftp archive has an rfc-index online with descriptions so that you can find which RFCs are of interest to you. Well connected RFC repositories include, but aren't limited to: nic.ddn.mil nnsc.nsf.net ftp.nisc.sri.com ftp.uu.net There is ongoing work on SNMP version 2 which will probably appear during 1993 as RFCs. These revisions include new mechanisms for security, bulk transfer, etc.
-----------[000241][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 93 15:33:21 GMT From: jessea@u013.me.vp.com (Jesse W. Asher) To: comp.protocols.tcp-ip Subject: Defunct processes left by server process.
One of our programmers has written a server using sockets for transferring
data to our application. The only problem is that when the server exits, it
leaves a defunct process out there that takes an entry in the process table
with the process table eventually filling. Eventually we have to reboot the
system to clear all the defunct processes. Anyone know why it would leave
these defunct processes and what we can do to get rid of them??
--
Jesse W. Asher (901)762-6000
Varco-Pruden Buildings
6000 Poplar Ave., Suite 400, Memphis, TN 38119
Internet: jessea@vpbuild.vp.com UUCP: vpbuild!jessea
-----------[000242][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jan 93 16:26:11 GMT From: maritza@espresso.bae.bellcore.com (Maritza Ramirez) To: comp.protocols.tcp-ip Subject: Determining Port Numbers & The RPC Portmapper
I am trying to look for a solution to the problem of determining an
unknown remote port number. I will appreciate any comments on the
following situation:
Let suppose that we have a client application that in a given moment
needs to know the server application's port number in a remote machine
to communicate with it over TCP/IP. Let's say that the client and
server applications are based on tli or socket calls.
In order to determine the server's port number, I was considering to
use an approach similar to the RPC's portmapper, in which a server
registers with a portmapper and gets a port, and then the client
contacts that portmapper in a well known port to find out the port
for the server application.
I was wondering if it would be possible for those client and server
applications (which are not RPC applications) to use the RPC portmapper
itself for this purpose (without using RPC calls, only tli/socket calls),
given that the applications can generate an unique program number and
version to be used as a reference.
If that is possible, does anyone knows ...
a) which is the sequence of steps that must be done to register the
server application with the RPC portmapper ?
b) which is the sequence of steps to obtain the server's port number
from the client side ?
Thanks,
Maritza
-----------[000243][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jan 93 17:37:34 GMT From: jpr@olbela.olivetti.be (Morant Jean-Pierre) To: biz.sco.general,biz.sco.opendesktop,comp.protocols.tcp-ip Subject: bootp on SCO tcp 1.2.0 (or lower)
Hello ! I've read somewhere that an implementation of "bootp" for SCO is available on the net. Do someone know where I can find it ? By the way, another one : I don't know much about the specification of the lli drivers, but is it possible to access them to set the MAC address of the ethernet board ? (with some special ioctl or something like that ...) If it is possible, do someone know of a tool doing this ? Thanks for your help. E-mail me, I'll post a summary. -- Voice : + 32 2 210 9353 Fax : 87 E-mail : ...ub4b!olbela!jpr (office) jpm@jpm.lbo.be (home)
-----------[000244][next][prev][last][first]---------------------------------------------------- Date: 20 JAN 93 17:56:21 GMT From: keele@skyfox To: comp.protocols.tcp-ip Subject: 3C509 pkt. drivers ?
Hello, Does anyone know if there are packet drivers around for the new 3C509 Etherlink III cards ? I have not seen them in the usual DRIVERS.ZIP file. Thanks. ///Ross A. Ross Keele | Keele@Sask.Usask.CA Dept. of Psychology | 46 Arts Building University of Saskatchewan | (306) 966-6696
-----------[000245][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 93 18:16:56 GMT From: exudnw@exu.ericsson.se (Dave Williams) To: comp.protocols.tcp-ip,comp.protocols.nfs Subject: backbone routers and topology
This may be in some FAQ somewhere, but I can't find it.
I'd like to hear from any large sites that have routers configured as
backbones. There's lots of marketing hype from the router companies
on why you "need" to do this, but very little in the way of hard info
on configuration, performance and pitfalls.
Our current configuration consists of about 400 SPARC clients fed by 13 Sun
4/490 servers. Each server has multiple NC400 Network Co-processors (one per
client network), 2 IPI controllers and 6-8 IPI disks (sime Saber's, some Elites).
We are currently setup in a straight hierarchical topology that looks something
like this:
server backbone (ethernet)
+-----------------------+----------------------+-----> to existing router
| | | (3270, x.25, etc.)
| | |
+-------+ +-------+ +-------+
| 490 | | 490 | | 490 |
| 1 | | 2 | | n |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| | | NC400 I/F's | | | | | |
client client client
networks networks networks
We typically put a maximum of 25 diskless w/s on each client network and get
about 60 clients per server. We run NIS, DNS, automounter, etc. and the whole
thing works pretty well. We are currenly in the process of adding about 200
disks to make about half of our client population dataless, the remainder is
Sun SLC's :~(
We started questioning this layout when we noticed our "server backbone" was
hitting high % of possible lan bandwidth at peak hours of the day. We already
had common data replicated on multiple servers but it's too big to copy to
all of them. We thought about this for a bit and came up with the following
possible solutions:
1) Put a large router (Cisco AGS+, Alantec, Wellfleet, etc.) in place of the
server backbone. These typically have near-gigabit backplanes and have *got*
to be faster than our current Ethernet 10 MB/sec "governor".
2) Connect the server's client networks to both the clients and the router
and turn off routing in the servers. We did some informal tests and found
that a single client could cause 10% server CPU load just routing a single
"find" command. I've always heard that Suns made poor routers, but could
never find any hard data on the subject.
3) Use the router as an FDDI connection to a single server containing all
replicated filesystems. We thought this could be a SS10/41 with multiple
fast SCSI disks. This would free up all the space currently taken up by
replicated data spread over all the servers while providing for faster
access and better configuration control.
One question that looms is whether the replicated (read mostly) data server
should use multiple ethernet I/F's, one to each client network (using more
than one server) or use FDDI straight into the router. We don't have a lot
of FDDI experience to guide us.
Is the answer the same for database (read-write, non-NFS) servers as it is for
"read mostly" (NFS) nodes? Which is better (for NFS and/or socket DB access),
multiple ethernet segments in a "matrix" topology spread over each client
network or single FDDI interfaces from each server into the router?
We would end up with something like this:
"old" server backbone
(Left intact for sanity and backup if router ever blows)
+--------------------------+-------------------------+-------------+
| | | |
| | | |
+-------+ +-------+ +-------+ |
| 490 | | 490 | | 490 | |
| 1 | | 2 | | n | |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+ |
| | | NC400 I/F's | | | | | | |
client client client |
networks networks networks |
| | | | | | | | | |
+---+-+-+----------------------+-+-+---------------------+-+-+----+ |
| enet enet enet | |
| enet+-----+
| router "backbone" |
| FDDI/CDDI |
+-----------------------------+----------------------------++-----+
| ||
X.25,3270 +-----++----+
etc. | replicated|
| data |
| server(s) |
| |
+-----------+
Are we on the trail of something good here or have we all been locked up in
the hacketorium too long?
Specifically:
1) Is turning off routing on the servers a *good* thing?
2) What will break?
3) One question that looms is whether the replicated (read mostly) data server
should use multiple ethernet I/F's, one to each client network (using more
than one server to cover all of the client networks) or use FDDI straight
into the router. We don't have a lot of FDDI experience to guide us.
Is the answer the same for database (read-write) servers as it is for "read
mostly" nodes? Which is better (for NFS and/or socket DB access), multiple
ethernet segments in a "matrix" topology spread over each client network
or a single FDDI interface into the router for each type of server?
4) What are we overlooking?
5) Are there any other large sites doing this kind of stuff?
Any comments/suggestions appreciated.
= exudnw@exu.ericsson.se (214)907-7928 =
= David Williams "You can't win, you can't break even, =
= Ericsson Network Systems and you can't quit" =
= Richardson, TX 75081 my opinions... =
--
= exudnw@exu.ericsson.se =
= David Williams "You can't win, you can't break even, =
= Ericsson Network Systems and you can't quit" =
= Richardson, TX 75081 my opinions... =
-----------[000246][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 93 19:06:52 GMT From: tbjorkho@james.abo.fi (Tom Bj|rkholm AT) To: comp.protocols.tcp-ip Subject: TCP/IP byte-stream connection
Dear all, Could someone please point me in the right direction. I have the following problem: I would like to implement a two directional byte stream between a program running on a Sun Sparc and a device (plug in card) in a PC/XT. Could someone point me in the right direction? Is there a good manual or book on the subject? Or has someone even an example source code? WHAT I HAVE: A Sun Sparc IPX running SunOS Release 4.1.2 (GS_ACCT_IPC_SS). The Sparc is connected to an ethernet LAN with the TCP/IP protocol. The LAN is divided into subnets by bridges and a router (it is connected to internet in fact). Connected to an other segment of the LAN is a PC/XT. The PC is an Olivetti M290 (8086). The PC has a 3Com 3C501 ethernet card. In the PC is also the device/plug in card that I want to access from the Sparc. (The card is a MicroWay Monoputer card). The PC has 640 MB RAM, a 20 MB hard disk, a 360 kbyte floppy drive and is running DOS 5.0. The PC/XT will be a dedicated server for this. WHAT I KNOW: I know basic C programming both under Unix and DOS. I do not have any problem to get a DOS C program to communicate with the device (Monoputer). WHAT I NEED TO LEARN: - The TCP/IP packet protocol - How to write a Unix program that connects to another computer on the net and maintains a byte-stream connection with that computer. - How to access the 3Com 3C501 card from a DOS C program. - How to write a DOS C program that accepts a network connection from another computer on the network, and maintains a byte-stream connection with that computer. Thanx in advance, Tom --- -- Tom Bjorkholm Process Design Laboratory Phone: +358 21 654 863 Department of Chemical Engineering Fax: +358 21 654 479 Abo Akademi University Internet: tbjorkho@ra.abo.fi Biskopsgatan 8 or: tbjorkholm@finabo.abo.fi SF-20500 Abo Bitnet: TBJORKHOLM@FINABO FINLAND Nordunet: ABOVAX::TBJORKHOLM
-----------[000247][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jan 93 20:23:01 GMT From: todd@uvmark.uucp (Todd Cooper) To: comp.sys.novell,comp.protocols.tcp-ip Subject: Anyone ever use NetWare MultiProtocol Router v2.0?
We are considering using a cheap local router by buying a PC and using NetWare's router software NetWare MultiProtocol Router v2.0. This is much less expensive than buying a hardware based router (Cisco, Wellfleet, 3Com, etc.). It will also probably be easier to maintain in house (i.e. swapping boards, etc.). Has anyone used this routing software for IP routing? We do not want a bridge, we are interested in doing IP routing. An e-mail reponse would be better, thanks. -- +++++ Just leaving a boring signature. ++++++++++++++++++++++++++++++ Todd Cooper (uvmark%todd@merk.com uunet!merk.com!uvmark!todd) Snail Mail: Vmark Software, 30 Speen Street, Framingham, MA 01701 USA
-----------[000248][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jan 1993 21:05:29 GMT From: danson@lgc.com (Doug Anson) To: comp.protocols.tcp-ip Subject: World-Wide (WAN) Network configuration questions..
Hi: We are a medium size company who is struggling with the costs of implementing world wide networks. We currently have links using common carriers (AT&T, MCI, etc) to most locations. We plan to use CISCO routers with 64KB lines to our NON U.S. locations. We feel that this in a minimum acceptable bandwidth for our applications, some of which are X-WINDOWS based. We would like higher bandwidth, but costs are unacceptably high. Currently the non U.S. locations are; London, Singapore, Calgary and Caracas. To offset costs we have implemented multiplexors from Republic Telecom that compresses and multiplexes voice and data together. I am soliciting input to the following questions: 1. Do you have experience subleasing bandwidth from larger companies. Who are they. What are the legal ramifications of doing that? 2. Do you have any experience using external data compression devices to increase bandwidth? Are these devices practical for interactive use? 3. Do you have experience "OUTSOURCEING" networks like this? If so, what are the costs, relative to leasing lines from the carriers? 4. Do you have any experience with "BANDWIDTH ON DEMAND" setups? 5. Do you have any other suggestions for us? Thanks in advance for any comments, suggestions... Joe Norton Manager of Telecommunications Landmark Graphics Corporation (713)560-1227 jnorton@lgc.com
-----------[000249][next][prev][last][first]---------------------------------------------------- Date: Thu, 21 Jan 93 03:19:58 GMT From: nelson@crynwr.com (Russell Nelson) To: comp.protocols.tcp-ip Subject: 3C509 pkt. drivers ?
In article <20JAN93.17562179@skyfox> keele@skyfox writes: Does anyone know if there are packet drivers around for the new 3C509 Etherlink III cards ? I have not seen them in the usual DRIVERS.ZIP file. They're in beta test, but you're welcome to try using it. No guarantees, of course. It's ftp.msen.com:pub/vendor/crynwr/3c509g.zip. Please tell me if it doesn't work for you. -russ <nelson@crynwr.com> What canst *thou* say? Crynwr Software Crynwr Software sells packet driver support. 11 Grant St. 315-268-1925 Voice | LPF member - ask me about Potsdam, NY 13676 315-268-9201 FAX | the harm software patents do.
-----------[000250][next][prev][last][first]---------------------------------------------------- Date: Thu, 21 Jan 1993 03:50:48 GMT From: tclark@med.unc.edu (Thomas B. Clark III) To: comp.protocols.tcp-ip Subject: NetManage
I would appreciate it if anyone could send me the internet address or phone number for NetManage.
-----------[000251][next][prev][last][first]---------------------------------------------------- Date: Thu, 21 Jan 1993 10:12:08 From: jbvb@vax.ftp.com (James B. VanBokkelen) To: comp.protocols.tcp-ip Subject: Re: Anyone know of a good LPR/LPD Server?
In article <16B5BE8CE.MACE@HDQCMS2H.UTSD.ATT.COM> MACE@HDQCMS2H.UTSD.ATT.COM writes:
We have 10 LaserJet printers which we would like to connect to a LPD
server, for access by our OS/2, DOS/Windows and IBM VM/CMS users.
...
We have looked at the Lantronix equipment, but that does not really
offer LPD; since we have a diverse user community, we want to use the
LPR and LPRMON software that is provided with the TCP/IP implementations.
A number of the DOS TCP/IP vendors offer LPD servers of varying
capabilities (B&W, Sun, FTP Software at least). Ours is sold as a
separate product, and handles multiple simultaneous printers, spools
while printing, allows you to define multiple virtual printers with
different initializations on a single physical printer, etc. (the
same spooler is bundled into our OS/2 product). There is also a
freeware LPD, which I think can be found on tacky.cs.olemiss.edu.
James B. VanBokkelen 2 High St., North Andover, MA 01845
FTP Software Inc. voice: (508) 685-4000 fax: (508) 794-4488
-----------[000252][next][prev][last][first]---------------------------------------------------- Date: Thu, 21 Jan 1993 08:11:53 GMT From: cmaeda+@cs.cmu.edu (Christopher Maeda) To: comp.protocols.tcp-ip Subject: bug in ttcp: SO_RCVBUF, accept
I noticed the following weird behavior using ttcp and the 4.3BSD TCP. (Actually a Mach 3.0 system but the binaries and the TCP code are 4.3BSD Unix). I wanted ttcp to advertise receive windows larger than 4k so I invoked it as follows: ttcp -r -s -b 32768 -l 16384 However, packet traces were showing that the receive windows were always 4k. For the arguments above, ttcp does the following syscalls: fd = socket(AF_INET,SOCK_STREAM,0); setsockopt(fd,SOL_SOCKET,SO_RCVBUF,...); /* 32k rcv window */ listen(fd,...); fd = accept(fd,...) In the TCP I'm using, the accept'ed connection doesn't pick up the modified sockbuf parameters from the parent socket and therefore the accept'ed connection has the 4k default receive window size. If I change the order of calls to the following, the accept'ed connection advertises 32k receive windows. fd = socket(AF_INET,SOCK_STREAM,0); listen(fd,...); fd = accept(fd,...) setsockopt(fd,SOL_SOCKET,SO_RCVBUF,...); /* 32k rcv window */ So my question is this. Is the second syscall sequence what ttcp *should* have been doing or should the accept'ed socket have inherited the sockbuf parameters from the parent socket (and therefore my TCP is buggy). -- Chris Maeda, Grad Student and RetroGrouch <cmaeda@cs.cmu.edu> "A unix signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who."
-----------[000253][next][prev][last][first]---------------------------------------------------- Date: Thursday, 21 Jan 1993 14:11:40 EST From: Tom Williams <TW@UMAB.BITNET> To: comp.protocols.tcp-ip Subject: setsockopt problem
I've got a problem using the BSD socket interface. I'm trying to
set the time out for the read function using the setsockopt function:
int sock, time = 10;
rc = setsockopt(sock,SOL_SOCKET,SO_RCVTIMEO, (char *)&time,
sizeof time);
I've previously called socket(), and it has executed correctly. When
I call setsockopt(), I get rc = -1, and errno = 22 (EINVAL, invalid
arguement according to errno.h).
Any ideas on what I'm doing wrong?
Thanks,
Tom
+----------------------------------------------------------------------------+
| "Work and play are words used to describe the same thing under different |
| conditions." |
| - Mark Twain |
| Bitnet: TW@UMAB Internet: TW@UMAB.UMD.EDU Phonenet: (410)706-4134 |
| SnailNet: 100 N. Green Street, Baltimore, MD 21201 |
+----------------------------------------------------------------------------+
-----------[000254][next][prev][last][first]---------------------------------------------------- Date: Thu, 21 Jan 93 18:55:25 EST From: MACE@HDQCMS2H.UTSD.ATT.COM To: comp.protocols.tcp-ip Subject: Re: Anyone know of a good LPR/LPD Server?
In article <930121101208@cream.ftp.com> jbvb@vax.ftp.com (James B. VanBokkelen) writes: >In article <16B5BE8CE.MACE@HDQCMS2H.UTSD.ATT.COM> MACE@HDQCMS2H.UTSD.ATT.COM writes: > > We have 10 LaserJet printers which we would like to connect to a LPD > server, for access by our OS/2, DOS/Windows and IBM VM/CMS users. > ... > We have looked at the Lantronix equipment, but that does not really > offer LPD; since we have a diverse user community, we want to use the > LPR and LPRMON software that is provided with the TCP/IP implementations. > >A number of the DOS TCP/IP vendors offer LPD servers of varying >capabilities (B&W, Sun, FTP Software at least). Ours is sold as a >separate product, and handles multiple simultaneous printers, spools >while printing, allows you to define multiple virtual printers with >different initializations on a single physical printer, etc. (the >same spooler is bundled into our OS/2 product). There is also a >freeware LPD, which I think can be found on tacky.cs.olemiss.edu. > >James B. VanBokkelen 2 High St., North Andover, MA 01845 >FTP Software Inc. voice: (508) 685-4000 fax: (508) 794-4488 > I was looking for a standalone device, rather than a process running on a set of PCs to drive the printers... Black-Box has indicated that they expect to have one in around March... I was hoping that there was something with a proven track record, instead of having to be on the bleeding edge... Thanks! -------------------------------------------------------------------------- Mace Moneta, AT&T VM Product Engineering, Piscataway, NJ --------------------------------------------------------------------------
-----------[000255][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 93 15:20:43 GMT From: chris@visionware.co.uk (Chris Davies) To: comp.protocols.tcp-ip Subject: Re: RPC protocol specifications
In article <1993Jan16.171627.4522@visionware.co.uk>, I wrote,
>The RPC protocol is in the public domain, although it was invented at
>Sun Microsystems.
Nathaniel Mishkin (mishkin@apollo.HP.COM) wrote:
: one thing that just sends me off the deep end is when people use the
: terms "RPC" and "Remote Procedure Call" as synonyms for Sun's RPC.
..
: Many other RPC systems have come before and after Sun's.
..
: Sun seems to tend to call their RPC system either "Sun RPC" or "ONC
: RPC".
Sorry. I do usually try to get my terminology correct.
(I assumed that the original posting was to do with Sun RPC as that's
what I've been working with lately.) As always, context is vital.
Chris
--
VISIONWARE LTD, 57 Cardigan Lane, LEEDS LS4 2LE, England
Tel +44 532 788858 x238. Fax +44 532 304676. Email chris@visionware.co.uk
---------- "VisionWare: The home of DOS/SQL/UNIX/X/VMS integration" ---------
-----------[000256][next][prev][last][first]---------------------------------------------------- Date: Thu, 21 Jan 1993 15:54:57 GMT From: ronf@panther3.panther.mot.com (Ron Feigen) To: comp.protocols.tcp-ip Subject: Re: Determining Port Numbers & The RPC Portmapper
In article <1jki9vINNmr9@aludra.usc.edu> smiller@aludra.usc.edu (Stephen B. Miller) writes: >In article <1993Jan20.162611.25831@walter.bellcore.com> maritza@espresso.bae.bellcore.com (Maritza Ramirez) writes: >> >> >>I am trying to look for a solution to the problem of determining an >>unknown remote port number. I will appreciate any comments on the >>following situation: >> >> [text deleted, see earlier posting] >> >>Maritza >> > >I am beginning to work an identical problem here, but have not come up with >much more than you. I have considered trying the dynamic update features in >the BIND 4.8.3 code, but they are so poorly documented that I might be better >off writing my own application. My situation is further complicated by then >need to change the port number assignments dynamically, which might be done >by deregistering and reregistering with the portmapper. If anyone else has >ideas please feel free..... > >Steve Miller - smiller@aludra.usc.edu > > registerrpc will register a prog#/ver# with portmapper. Portmapper assigns the port #. svc_unregister() removes the entry. pmap_getport() looks up a prog#/ version# on a host. You must of course know the host name, prog# and version# in advance. Be careful about having the same prog# with different version #s. Portmapper returns the port of a program with a match on prog #, but will give you the latest (I believe) version # if it doesn't find an exact match. Dig through the man pages, the info is skinny but most of it is there. There is also a book called "The Art of Distributed Application" by John R. Corbin. It is supposed to give lots of detail about Portmapper It is part of the Sun Tech Reference Library, published by Springer-Verlag. Ron -- > Ron Feigen ronf@panther.mot.com
-----------[000257][next][prev][last][first]---------------------------------------------------- Date: Thu, 21 Jan 1993 17:10:13 GMT From: alech@hpindda.cup.hp.com (Alec Henderson) To: comp.protocols.tcp-ip Subject: Re: NetManage
tclark@med.unc.edu (Thomas B. Clark III) asks: >I would appreciate it if anyone could send me the >internet address or phone number for NetManage. Internet: support@netmanage.com Phone: 408-973-7171 Regards, Alec Henderson Telephone: 408-447-3965 Hewlett-Packard FAX: 408-447-3660 Information Networks Division E-mail: alech@cup.hp.com 19420 Homestead Road MS 43L9 HPDesk: Alec Henderson/HP6600/1B Cupertino, CA 95014 (USA)
-----------[000258][next][prev][last][first]---------------------------------------------------- Date: Thu, 21 Jan 1993 23:36:55 GMT From: mike@gordian.com (Michael A. Thomas) To: comp.protocols.tcp-ip Subject: Large Windows and Delayed Acking
I have been playing around with a TCP implementation trying to get the throughput up and discovered an interesting anomaly with large windows. The setup I have is a program which is an infinite data source sending to the discard port (port 9) on a remote machine over ethernet. I am merely measuring the bandwidth and occassionally reporting that to the user -- nothing complicated. What I have found is that with large windows (say 16kb) the sending TCP stops sending at about 4k and waits for the receiving TCP to send an ACK. The receiving TCP, however is using a defered acking scheme which tries to delay sending ACK until a larger window is consolidated into one packet. The metric it is using is 1/2 the buffer size, and the delayed ack period is on the order of 100ms. I can understand why a sending TCP might be leary of sending *so* much data without hearing an ack, but my question is what algorithm is the sending TCP using to determine how much data it will send before going into this quiesent state? Is there an appropriate RFC which I should read which describes this situation? Is the behavior of the sending TCP correct? (BTW, I noticed that the IBM/AIX which extends a 16k window has the same problem with a Sun running 4.1.2, so the problem is not unique to the TCP I'm futzing with...) -- Michael Thomas (mike@gordian.com) "I don't think Bambi Eyes will get you that flame thrower..." -- Hobbes to Calvin USnail: 20361 Irvine Ave Santa Ana Heights, Ca, 92707-5637 PaBell: (714) 850-0205 (714) 850-0533 (fax)
-----------[000259][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 93 23:38:57 GMT From: kate@wavefront.wti.com (Kathy Samec) To: comp.protocols.tcp-ip Subject: Slip and SGI machines
I will have to set Slip up on a SGI Indigo soon and would like to know what software will run in this environment. Will cslip work? Also, Who can I contact to get a slip connection to the internet in the NYC area? thanks -- *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Kathi Samec - Everything is beautiful and Santa Barbara Studios Nothing hurt. kate@wti.com -Stoney Stevenson
-----------[000260][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 93 23:52:14 GMT From: kate@wavefront.wti.com (Kathy Samec) To: comp.protocols.tcp-ip Subject: More Slip
One more enquiry about slip. Is a particular modem necessary?? -- *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Kathi Samec - Everything is beautiful and Santa Barbara Studios Nothing hurt. kate@wti.com -Stoney Stevenson
-----------[000261][next][prev][last][first]---------------------------------------------------- Date: Fri, 22 Jan 93 00:42:03 GMT From: maritza@espresso.bae.bellcore.com (Maritza Ramirez) To: comp.protocols.tcp-ip Subject: Re: Determining Port Numbers & The RPC Portmapper
In article <1993Jan21.155457.27880@panther.mot.com>, ronf@panther3.panther.mot.com (Ron Feigen) replies:
|>
|> [text deleted, see earlier posting]
|>
|>
|> registerrpc will register a prog#/ver# with portmapper. Portmapper assigns the
|> port #. svc_unregister() removes the entry. pmap_getport() looks up a prog#/
|> version# on a host. You must of course know the host name, prog# and version#
|> in advance. Be careful about having the same prog# with different version #s.
|> Portmapper returns the port of a program with a match on prog #, but will give
|> you the latest (I believe) version # if it doesn't find an exact match.
|>
|>
|> [text deleted, see earlier posting]
|>
|> Ron
|>
I was just wondering if it is possible to connect and send commands to the
RPC portmapper without using RPC calls (svc_xxx or pmap_xxx) but tli or
socket calls. That approach of connecting and sending commands is possible
when working with some services. For example, I have some source code that
sends commands to an ftp server after establishing a connection with it on
its well known port 21. That program follows the same approach as when we
use a telnet connection to send control commands to ftp (see example).
--o--
Example:
___________________ ftp's well known port
/
$ telnet itsname 21
Trying 128.96.133.64 ...
Connected to itsname.
Escape character is '^]'.
220 itsname FTP server ready. _____________ ftp server accepts connection
USER maritza
331 Password required for maritza.
PASS mypass123
230 User maritza logged in.
HELP
214-The following commands are recognized (* =>'s unimplemented).
USER PORT RETR MSND* ALLO DELE SITE* XMKD CDUP
PASS PASV STOR MSOM* REST* CWD STAT* RMD XCUP
ACCT* TYPE APPE MSAM* RNFR XCWD HELP XRMD STOU
REIN* STRU MLFL* MRSQ* RNTO LIST NOOP PWD
QUIT MODE MAIL* MRCP* ABOR NLST MKD XPWD
QUIT
221 Goodbye.
Connection closed by foreign host.
$
Note that when using this approach, the commands that the ftp server
recognize are the low level commands described on the RFC959 (e.g.,
PORT, PASV, RETR, STOR).
--o--
The question is: Is it possible to connect and send commands to the RPC
portmapper using tli or socket calls ?
The protocol specifications for the portmapper (appendix A of the RFC1057)
does not say anything about the low level commands that the portmapper
recognizes.
Does anyone knows which low level commands must be given to the portmapper
server after a connection is established to (1) register an application,
and (2) get the assigned port from a client application ?
Thanks,
Maritza
-----------[000262][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 93 01:30:35 GMT From: guy@Auspex.COM (Guy Harris) To: comp.protocols.tcp-ip Subject: Re: Determining Port Numbers & The RPC Portmapper
>registerrpc will register a prog#/ver# with portmapper. Portmapper assigns the >port #. No, it doesn't. The portmapper doesn't assign port numbers (take a look at RFC 1057, which describes the portmapper's RPC protocol; there ain't no call in there that *chooses* a port number and *assigns* it to a server - there's just a PMAPPROC_SET call to bind an *already-allocated* port number to a particular program and version number and Internet protocol number); other code does (for example, the UDP or TCP implementation, at least in UNIX systems). If all you want to do is just register a port number with the portmapper as being bound to some particular program and version number for some particular protocol, you can do so with "pmap_set()". The advantage of using "pmap_set()" rather than "registerrpc()" is that you don't set up all the rest of the RPC mechanism; given that the original poster didn't *want* to drag in the rest of the RPC mechanism, that's probably what they want. >svc_unregister() removes the entry. So does "pmap_unset()", and it also doesn't pester the rest of the RPC mechanism.
-----------[000263][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 93 01:33:45 GMT From: alen@crash.cts.com (Alen Shapiro) To: comp.protocols.tcp-ip Subject: TCP-IP for OS/2, I need to disable the DOS mem-load HELP**!!
Hi netters, I have OS/2 1.33 (extended) with IBMs TCP-IP drivers. They load (using config.sys) into both OS/2 and DOS. I only need to run telnet sessions on the OS/2 side, I need the 180k used by these drivers on the DOS side when the DOS window is activated. Is there a mechanism (hack or not) to unload these drivers from DOS and still allow OS/2 TCP-IP to survive? Are there public domain TCP-IPs that run under OS/2 that take less than 80kb on the DOS side or do not load there at all? Help is urgently needed on this one...thanks in advance. please email to alen@crash.cts.com and I'll summarise for the net.
-----------[000264][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 93 02:17:36 GMT From: birchall@pilot.njin.net (Shag) To: comp.protocols.tcp-ip,comp.windows.x Subject: PC<->Unix connection, free/cheap?
My current connection:
PC -normal dialup-> Cisco -> Sparc-II
My desired connection:
PC -better dialup-> Cisco -> Sparc-II
I'm interested in establishing a PC-Unix connection over a dialup line,
with the connectivity listed above. Any protocol (Xremote, SLIP, CSLIP,
maybe PPP) is an option, preference given to those which I could run an
X-server over.
I've had the opportunity to look at a few products so far:
CUTCP - Advantages: PD, cheap, not picky about what else it will run
with. Disadvantages: Not on the list of things that other
picky programs will run with. :)
PC-Xview - Advantages: X-windows, easy to configure. Disadvantages:
Expensive, doesn't support PD connection protocols, works
best with X-Remote, which is also expensive.
PCTCP - Advantages: Widely used, well known, terribly comprehensive.
Disadvantages: Not PD, difficult to configure.
The Cisco in question currently supports X-Remote connections, but doesn't
have SLIP active. I can bug The Powers That Be to turn on SLIP if that's my
only choice... X-windows would be very nice, though.
My PC is a '286, not capable of running Windows or Linux (sorry, for those
who were about to suggest those! ;), with 4 megs of RAM (well, it's capable
of running Windows, but I'm one of those annoying people that actually likes
software to execute at a usable speed! ;), 80mb hard drive (50mb free), VGA
greyscale, and a v.32bis/42bis (14400) modem.
Any ideas? Throw 'em at me.
I'd really prefer e-mail responses to this (reply, don't followup), thanks...
-Shag
--
birchall@pilot.njin.net, shag@glia.biostr.washington.edu, birchall@njin.bitnet
Operator of ShagNet - Rutgers/NJIN dialup access for Burlington County, NJ
Happy and informative user of a PPI 14400 FaxModem and GeoWorks Pro
Editor of the Queensryche E-mail Digest - "Screaming in Digital"
-----------[000265][next][prev][last][first]---------------------------------------------------- Date: Fri, 22 Jan 1993 03:46:13 GMT From: amehta@minerva.cis.yale.edu (Anand R. Mehta) To: comp.protocols.tcp-ip Subject: Help with ka9q
Hello all.
I am currently trying to set up a PPP link between a NeXT and a PC, which
is on the campus ethernet. I have the NeXT PPP implimentation working, but
cannot get the PC up. I believe that the packet driver is installed
correctly (NCSA telnet will use it), and that the problem is one of
configuring the PC routing tables, etc. I have not even tried ka9q with
PPP, as I cannot get it to work over ether.
Could someone who has configured ka9q to work (even without ppp) please
email me a copy of their *.net file so that I can have a look at what is
going on? Also, any tips on where to find more documentation would be
greatly appreciated.
What I would like to have eventually is this:
============PC============ether
|
|
ppp
|
NeXT
with ka9q routing packets between the NeXT and the rest of the world.
Any help that you can give me would be greatly appreciated.
-Anand
Academic Computing Services
Yale University
(203) 436-1437
-----------[000266][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 93 04:00:39 GMT From: guy@Auspex.COM (Guy Harris) To: comp.protocols.tcp-ip Subject: Re: Determining Port Numbers & The RPC Portmapper
>I was just wondering if it is possible to connect and send commands to the >RPC portmapper without using RPC calls (svc_xxx or pmap_xxx) but tli or >socket calls. Well, yes, it is possible - after all, ultimately, the code that implements RPC calls generally does so using sockets or TLI calls.... I.e., yes, you can do it, but the commands you send to it are just RPC calls, so the only way to avoid using the RPC routines is to do just what they do.... >The protocol specifications for the portmapper (appendix A of the RFC1057) >does not say anything about the low level commands that the portmapper >recognizes. Yes, it does. It gives a description, "in RPC Language", of the port mapper protocol. If the fact that the description is given "in RPC Language" doesn't tell you that the port mapper is an RPC service, the fact that section 7.4.2 says, in as many words: Broadcast calls use the Port Mapper RPC service to achieve their semantics. See Appendix A for more information. should sure give you a clue that it's an RPC service.... I.e., no, this isn't like an SMTP or FTP server, wherein you can just type commands at it; it's an RPC server that's just like any other RPC server, except that it has to have a well-known port number - after all, it's kind of hard to ask the portmapper what the port number of the portmapper is if you don't *already* know what its port number is.
-----------[000267][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 93 17:00:24 -0600 From: robin@vax1.mankato.msus.edu To: comp.protocols.tcp-ip Subject: LPR and Fortran flow control RFC 1179
********* Help ******** Help ******** Help ******** I am trying to implement an LPR client using RFC 1179. When trying to send fortran flow control to the server machine, I send a control file with an 'r'+file+LF. What exactly should I be sending as file??? Currently, I am sending the name of the df (same as is being sent by the 03 (receive data file) subcommand. So to sumerize I'm sending the following data: /*connect to remote host*/ [02]<queue>[LF] [02]<size of control file> cfA100POJ1[LF] /*POJ1 = hostname, 100 = JobNo */ CAS400-1.Mankato.MSUS.Edu[LF] HAS400-1.Mankato.MSUS.Edu[LF] J<Jobname>[LF] L<Userid>[LF] N<Source name>[LF] P<Userid>[LF] rdfA100POJ1[LF] /*wait for ack here*/ [03]<size of data file> dfA100POJ1[LF] <insert entire data file here> [0] /*wait for ack here*/ /*disconnect*/ For output we get a complete printout on the host... but the fortran flow control is NOT interpreted and the "1" "0" "+".. etc. are printed. Please reply directly to: j3gum@vax1.mankato.msus.edu AND robin@vax1.mankato.msus.edu THANKYOU THANKYOU THANKYOU THANKYOU THANKYOU THANKYOU THANKYOU THANKYOU
-----------[000268][next][prev][last][first]---------------------------------------------------- Date: Fri, 22 Jan 1993 09:35:51 +0000 From: phil@calibra.demon.co.uk (Philip A Smith) To: comp.protocols.tcp-ip Subject: Re: NetManage
In article <6200055@hpindda.cup.hp.com> alech@hpindda.cup.hp.com writes:
>tclark@med.unc.edu (Thomas B. Clark III) asks:
>
>>I would appreciate it if anyone could send me the
>>internet address or phone number for NetManage.
>
>Internet: support@netmanage.com
>Phone: 408-973-7171
>
>Regards,
>Alec Henderson
>
>Telephone: 408-447-3965 Hewlett-Packard
>FAX: 408-447-3660 Information Networks Division
>E-mail: alech@cup.hp.com 19420 Homestead Road MS 43L9
>HPDesk: Alec Henderson/HP6600/1B Cupertino, CA 95014 (USA)
>
--
Philip A Smith
U
D N
O T N I
S P E C I F (I X )
P S
I
S U P P O R T
SPECIF(IX) FOR SEAMLESS DOS UNIX INTEGRATION
For anyone else interested in a genuine Windows DLL TCP
and client server NFS product please contact:
UK. Specifix 0629 732982
In the USA.
NetManage Inc. Tel :0101 408 973 7171 Fax:0101 408 257 6405
Email: Joseph L'Italien. Director of International Sales.
Dan Geisler. Director of Marketing
info@netmanage.com
-----------[000269][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 1993 12:24:13 GMT From: andreas@informatik.rwth-aachen.de (Andreas Fasbender) To: comp.protocols.tcp-ip Subject: Sequence Numbers in TCP/IP
Can somebody answer a stupid question: What is the reason for the difference in the lenght of the window-field (16) and the sequence-number-field (32 bit). Using 16-bit-numbers for sequencing and acknowledging could spare 4 byte in each packet. Hope this isn«t a faq. Thanks Andreas :-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-: : Andreas Fasbender Institute of Computer Science IV : : Aachen University of Technology : :-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:
-----------[000270][next][prev][last][first]---------------------------------------------------- Date: Fri, 22 Jan 1993 14:26:37 GMT From: evansmp@uhura.aston.ac.uk (Mark Evans) To: comp.protocols.tcp-ip Subject: Re: Sequence Numbers in TCP/IP
Andreas Fasbender (andreas@informatik.rwth-aachen.de) wrote: : Can somebody answer a stupid question: : : What is the reason for the difference in the lenght of the window-field : (16) The window is how much the other end is prepared to accept (65535 implies infinite). (this is bigger than the maximum packet size on every network I have ever seen) : and the sequence-number-field (32 bit). Using 16-bit-numbers for sequencing : and acknowledging could spare 4 byte in each packet. Sequence measures how much has been sent. Both of these are measured in octets (8 bit bytes), it is quite reasonable to expect a TCP link to send more that 64K octets in one session. : Hope this isn+t a faq. : -- ------------------------------------------------------------------------- Mark Evans |evansmp@uhura.aston.ac.uk +(44) 21 429 9199 (Home) |evansmp@cs.aston.ac.uk +(44) 21 359 6531 x4039 (Office) |
-----------[000271][next][prev][last][first]---------------------------------------------------- Date: Fri, 22 Jan 1993 16:28:17 GMT From: amolitor@nmsu.edu (Andrew Molitor) To: comp.protocols.tcp-ip Subject: Re: Large Windows and Delayed Acking
In article <1993Jan21.233655.29402@gordian.com> mike@gordian.com (Michael A. Thomas) writes: > > What I have found is that with large windows (say 16kb) the sending >TCP stops sending at about 4k and waits for the receiving TCP to >send an ACK. The receiving TCP, however is using a defered acking >scheme which tries to delay sending ACK until a larger window is >consolidated into one packet. The metric it is using is 1/2 the >buffer size, and the delayed ack period is on the order of 100ms. > I can understand why a sending TCP might be leary of sending *so* >much data without hearing an ack, but my question is what algorithm >is the sending TCP using to determine how much data it will send >before going into this quiesent state? Is there an appropriate >RFC which I should read which describes this situation? Is the >behavior of the sending TCP correct? Sounds like the sender's computing a congestion window around 4K. See, say, Steven's _Internetworking with TCP/IP_ or probably rfc793 somewhere or other. Steven's has a good exposition. The point is that TCP makes a guess at a good sending window size based on latency of packets, and uses the minimum of that window size and the remote's advertisement as the real window. This is used to avoid congestion. It might even be that the delayed ACK cause the sender to compute an artificially small congestion window (4K seems small to me). One must keep in mind that TCP is polite. If the goal is to hammer your media to death, TCP is the wrong protocol. Not, by the way, to suggest that this is your goal. Andrew > Michael Thomas (mike@gordian.com)
-----------[000272][next][prev][last][first]---------------------------------------------------- Date: Fri, 22 Jan 1993 18:19:10 GMT From: jdoyle@phy.umassd.edu (Jim Doyle) To: comp.os.mach,comp.protocols.tcp-ip Subject: Re: SLIP under Mach 3.0
In <1japc9INNh14@bigboote.WPI.EDU> ralf@wpi.WPI.EDU (Ralph Valentino) writes: >Has anyone gotten SLIP to work under Mach 3.0? /etc/slattach from >2.6MSD reports "ioctl(TIOCSETD): No such device" when run under 3.0 >mk77 ux37. It sounds like your Unix server is not properly configured for SLIP. TIOCSETD is the ioctl argument that you use to change the line discipline on a tty. My guess is that when slattach opens the tty line and tries to set SLPDISC the kernel cant find that discipline descriptor in its switch table. We have problems here with MK78/UX39 SLIP - I have been meaning to port in CSLIP v2.6 to it but just have been too tired / too busy to get to it. It should be a pretty easy thing. If you wanna try to beat me to the punch you can get it from ftp.ee.lbl.gov - use the BSD4.3 installation as a guide. You basically gotta add some things to tty_conf.c to make it jive. -- Jim Doyle Univ. of Massachusetts - Dept. of Computer Science doyle@cs.umass.edu
-----------[000273][next][prev][last][first]---------------------------------------------------- Date: Fri, 22 Jan 1993 18:32:07 GMT From: jswanson@csfb1.fir.fbc.com (James Swanson) To: comp.protocols.tcp-ip Subject: Re: Help with termcap/terminfo needed
|> I have an application running on 2 different flavours of Unix. The applicati
on
|> uses function keys F1 to F4. The are defined as generating ESC-@ ESC-A ESC-B
|> ESC-C. On one system they are passed in to the application as the appropriat
e
|> function keys and on the other arrive separately as ESC and then @/B/C etc.
|> All the terminal definitions are exactly the same.
|> This looks like a timing problem. Is there a code that can be modified to
|> fix this or is my problem somewhere else ? (Like in the application which is
|> Informix and about which I know sweet **??!!)
|>
|> AdvThx
|>
|> --
|> Jo Baker, D9 |email: jo@siesoft.co.uk
|> Siemens Nixdorf, Oldbury, |Tel: +44 344 850450
|> Bracknell, Berks, RG12 4FZ |Fax: +44 344 850096
I had this exact problem using Informix on AIX 2.0. This symptom would
occur only when I was accessing AIX through a psuedo terminal (telnet or
rlogin). I tried to get help from Informix and AIX, but each said the other
was crewing up (suprise!).
The problem is caused by timing, as you suspected, in the AIX pseudo-
terminal driver. If the ESC and the @/A/etc. are received in separate
packets, they will be delivered separately to the application. The application
is supposed to wait long enough after an ESC for the following character
to determine if it is an escape sequence (there must be a better way). In
the case of AIX, and possibly other systems, the time between delivery of
the 2 packets is too long.
Finally, I solved this by writting a "wrapper" around the Informix application.
The wrapper would read from stdin and "bunch-up" any escape sequences before
delivering them to the application in one "write()".
The wrapper:
opened the "tty" in a mode that allowed all cahracters to pass
Forked a child which exec()'d the Informix application
The wrapper tied its stdout to the child's stdin
The wrapper passed every character to the application
if the wrapper saw an ESC, it checked for a follow-on character
with a reasonable timeout
If none came, the ESC was passed
If one did come, the ESC and the follow-on were passed together
in the same buffer.
The wrapper can be tweeked to get the best timeout value, optimize character
throughput by reading with NOWAIT, etc.
I wish I still had the code to share with you, but this was two jobs ago
and I have lost track of it.
Hope this helps.
--
Jim Swanson
First Boston Corporation
5WTC - 9th floor
New York, NY 10048
(212)322-1085
-----------[000274][next][prev][last][first]---------------------------------------------------- Date: Fri, 22 Jan 1993 19:23:50 GMT From: jswanson@csfb1.fir.fbc.com (James Swanson) To: comp.protocols.tcp-ip Subject: Re: Distributed NFS
|>> Looking for a method of replicating NFS file systems...
!>
|> There's already a product available that does this called the Isis Reliable
Network File System
|> from Isis Distributed Systems Inc. Their mail address is ids@isis.com.
|>
Thsnks for your suggestion. I already reviewed the ISIS product. It has
several shortcomings:
It will only export 1 file system for the entire network.
It will not premit any other NFS mounted systems to be exported from
the same server.
It still has some nasty bugs.
I need to be able to use the "automounter" and "secure NFS" packages as well.
I think the best solution will include a mechanism to maintain synchroni-
zation without imposing too many non-standard restrictions. As I mentioned
before, I would like to find a way to use the BIOD or NFSD daemons to
s:
Subject: Re: Distributed NFS
|>> Looking for a method of replicating NFS file systems...
!>
|> There's already a product available that does this called the Isis Reliable
Network File System
|> from Isis Distributed Systems Inc. Their mail address is ids@isis.com.
|>
Thanks for your suggestion. I already reviewed the ISIS product. It has
several shortcomings:
It will only export 1 file system for the entire network.
It will not premit any other NFS mounted systems to be exported from
the same server.
It still has some nasty bugs.
I need to be able to use the "automounter" and "secure NFS" packages as well.
I think the best solution will include a mechanism to maintain synchroni-
zation without imposing too many non-standard restrictions. I would like to
find a way to use the BIOD or NFSD daemons to provide this funcitonality.
--
Jim Swanson
First Boston Corporation
5WTC - 9th floor
New York, NY 10048
(212)322-1085
-----------[000275][next][prev][last][first]---------------------------------------------------- Date: Fri, 22 Jan 1993 19:34:32 GMT From: mgic <mgic@mixcom.mixcom.com> To: comp.protocols.tcp-ip Subject: Problem with RPC and inetd
I am having a problem getting my RPC service started using inetd. I am working on a SparcStation 2 and using Sun's rpcgen to generate my client and server 'stubs'. The RPC client and server work fine if I start the server up myself but when I try to start it using inetd, the client just returns without a message. I have, 1. Used rpcgen with the -I option. (to enable inetd support) 2. Made an entry in the /etc/inetd.conf file for the service. 3. Made an entry in the /etc/rpc file for the service. Also, running rpcinfo shows the service listed as being a service known to the portmapper. What am I doing wrong? Anand Prahlad mgic@mixcom.com --
-----------[000276][next][prev][last][first]---------------------------------------------------- Date: Fri, 22 Jan 1993 21:14:25 GMT From: jswanson@csfb1.fir.fbc.com (James Swanson) To: comp.unix.aix,comp.edu,comp.protocols.tcp-ip Subject: Re: HELP NEEDED TO MAKE ETHERNET AND TOKEN RING COEXIST ON RS6K
In article <1993Jan21.164446.21646@oucsace.cs.ohiou.edu>, sivkumar@dolphins.ent.ohiou.edu (Krish Sivakumar) writes: |> We have a IBM RS6000 530H running TCP/IP under AIX 3.2.3 |> The machine is fully configured and operational with ethernet. |> We are trying to set up a local token ring using the |> Token Ring Adapter in the same Machine and planning to use the |> ethernet as the Token Ring's Gateway to the outside world. |> |> We are not quite sure how to go about doing this. Initial attempts ended |> up in the ethernet getting rendered inactive |> |> Any suggestions, comments, ideas, solutions or thoughts are more than welcome. |> Thanks |> -- |> ----------------------------------------------------------------------- |> - Krish Sivakumar Drive Defensively, Buy a tank - |> - Dept. of Mechanical Engineering ------------------------------- |> - Ohio University, - /\ /\ It should be a simple matter to define each of the network adapters to have a different address and put 2 addresses for your host in the host file. You may need to assign a different subnet to each network card rather than simply a different host address, but one or the other should work fine. This is a standard feature of IP. Once the network cards are set up, you infrom the other nodes that they may route through the dual-ported node to access the folks on the other side. -- Jim Swanson First Boston Corporation 5WTC - 9th floor New York, NY 10048 (212)322-1085
-----------[000277][next][prev][last][first]---------------------------------------------------- Date: Sat, 23 Jan 1993 00:25:17 GMT From: kent@humu.nosc.mil (Kent K. Kuriyama) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: Multiple class 'C' addresses versus single class 'B'
I would like to get comments regarding the problems of using multiple class 'C' addresses vice a single class 'B' addresses. Obviously this is an issue because the NIC is hesitant in granting the rapidly diminishing number of class 'B' addresses. We intend to have approximately 2000 IP addresses with typically 50 address per sub-net. Using class 'C' address we are looking at 40 sub- nets or approximately 10 'C' addresses. Questions: 1) What kind of management problems will we run into if we use class 'C' vice 'B'? It seems to me that use of multiple class 'C' addresses would not change the number of routers required - the number of sub-nets dictates that. 2) Someone mentioned that linking up a bunch of 'C' addresses will require the use of some external gateway protocol (make sense - we need to route between class 'C' networks) on our routers. Is this a big deal? Is EGP a feature only available on expensive routers? 3) Are there any advantages to getting a contiguous set of class 'c' addresses (e.g. 192.101.190,191,192, . . . etc)? 4) Would there be any problem in implementing a single domain name DNS over multiple class 'C' addresses? Thanks. Kent Kuriyama kent@nosc.mil
-----------[000278][next][prev][last][first]---------------------------------------------------- Date: 23 Jan 93 00:27:37 GMT From: guy@Auspex.COM (Guy Harris) To: comp.protocols.tcp-ip Subject: Re: Sequence Numbers in TCP/IP
>The window is how much the other end is prepared to accept (65535 implies >infinite). (this is bigger than the maximum packet size on every network >I have ever seen) Yes, but, as far as I know, it's not required that the sending TCP stuff everything into one packet, and there's a "TCP Big Window" option mentioned in RFC1106, to increase the maximum window size beyond 64K. There's also an RFC, RFC1110, entitled "A Problem with the TCP Big Window Option"; both date back to mid-1989, and not being a full-time networking weenie, I don't know what the state of Big Windows in TCP is (except that I seem to remember Vernon Schryver talking about cranking the window size up when using FDDI, in order to light the fibre up, so I suspect there's at least a semi-stable standard for Big Windows).
-----------[000279][next][prev][last][first]---------------------------------------------------- Date: 23 Jan 93 02:45:51 GMT From: skibo@florida.wpd.sgi.com (Thomas Skibo) To: comp.protocols.tcp-ip Subject: Re: Sequence Numbers in TCP/IP
In article <16594@auspex-gw.auspex.com>, guy@Auspex.COM (Guy Harris) writes: |> >The window is how much the other end is prepared to accept (65535 implies |> >infinite). (this is bigger than the maximum packet size on every network |> >I have ever seen) |> |> Yes, but, as far as I know, it's not required that the sending TCP stuff |> everything into one packet, and there's a "TCP Big Window" option |> mentioned in RFC1106, to increase the maximum window size beyond 64K. |> |> There's also an RFC, RFC1110, entitled "A Problem with the TCP Big |> Window Option"; both date back to mid-1989, and not being a full-time |> networking weenie, I don't know what the state of Big Windows in TCP is |> (except that I seem to remember Vernon Schryver talking about cranking |> the window size up when using FDDI, in order to light the fibre up, so I |> suspect there's at least a semi-stable standard for Big Windows). RFC 1323 is the latest RFC describing big windows. It is basically an update to RFC's 1072 (window scaling, time-stamps for rtt measurement, and selective acknowledgements) and 1185 (using the same time-stamps for rejecting old, duplicate segments). The selective acknowledgement was dropped from 1323 because it was felt that more research needed to be done. RFC 1106 was another method of getting >64K windows. I don't know much about it. The problem with big windows described in RFC 1110 (that a 32-bit sequence number isn't good enough with 30-bit windows) was addressed in RFC 1185 and refined in RFC 1323. RFC 1323 is pretty solid. SGI's next major OS release will include a TCP that can do RFC 1323 (both window scaling, and time-stamps). Vernon nearly saturates an FDDI ring with a couple of Indigos and a single TCP connection with a 60K window (no window scaling needed). But, he likes to crank up the window to 128K+ to squeeze the last 0.2 MBytes/s out. Since the "big windows" will be available soon, you'll be able to try this at home. -- --- Thomas Skibo Advanced Networking, Silicon Graphics skibo@sgi.com
-----------[000280][next][prev][last][first]---------------------------------------------------- Date: Sat, 23 Jan 1993 03:44:53 GMT From: vish@ngc.com (Vish Mulchand) To: comp.protocols.tcp-ip Subject: TCP Testing
I am curious to know how TCP/IP is being tested. I would be interested in almost anything related to testing of TCP/IP and this would include automated TCP testers, conformance tests, test cases/suites, philosophies experiences and other information that might prove to be useful. Regards Vish Mulchand vish@thor.ngc.com (415) 688-2849 -- Vish Mulchand Network General Corporation vish@thor.ngc.com (415)688-2849
-----------[000281][next][prev][last][first]---------------------------------------------------- Date: 23 Jan 93 16:30:20 From: braudes@proto.Read.TASC.COM (Bob E. Braudes) To: comp.protocols.tcp-ip Subject: Re: Large Windows and Delayed Acking
What is the incoming buffer size advertised by the receiver? If it is 4K, like it sounds, then the sender will stop sending after this 4K has been sent and not acknowledged. Bob Braudes TASC
-----------[000282][next][prev][last][first]---------------------------------------------------- Date: Sat, 23 Jan 1993 11:35:44 GMT From: amolitor@moink.nmsu.edu (Andrew Molitor) To: comp.protocols.tcp-ip Subject: TCP congestion/Nagle's algorithm
Darn it, I think I put my foot in my mouth. After poking through rfc896 (in which Nagle introduces his algorithm for solving the 'small packet' problem) and comparing with Karn's NOS TCP implementation, I find myself confused. First, I misunderstood congestion windows. My apologies to whoever it was I responded to a day or so ago, blithely dismissing throughput problems as 'sounds like a small congestion window.' Second, Nagle seems to be saying that a TCP should not send new data while unack'd data is outstanding, while Karn's code seems to not send new data while unack'd data is outstanding *unless* there is a max segment sized chunk to go out. Karn's version seems right, since it allows proper streaming, while Nagle's seems to reduce the sliding window to a stop and wait arrangement. Is Karn's algorithm in Nagle's remarks, disguised as a tacit assumption that one always sends all the data one has, in multiple segments? He seems to be implying that as soon as one gets an ack, one sends all the data one has on hand. This is still not quite Karn's implementation, I think. Andrew
-----------[000283][next][prev][last][first]---------------------------------------------------- Date: Sat, 23 Jan 1993 12:05:52 GMT From: evansmp@uhura.aston.ac.uk (Mark Evans) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: Re: Multiple class 'C' addresses versus single class 'B'
Kent K. Kuriyama (kent@humu.nosc.mil) wrote: : I would like to get comments regarding the problems of using multiple : class 'C' addresses vice a single class 'B' addresses. Obviously : this is an issue because the NIC is hesitant in granting the rapidly : diminishing number of class 'B' addresses. : : We intend to have approximately 2000 IP addresses with typically 50 : address per sub-net. Using class 'C' address we are looking at 40 sub- : nets or approximately 10 'C' addresses. There is something called supernetting, which is analogeous to subnetting which allows a group of class C addresses to be treated as one entity. : : Questions: : : 1) What kind of management problems will we run into if we use class : 'C' vice 'B'? It seems to me that use of multiple class 'C' addresses : would not change the number of routers required - the number of sub-nets : dictates that. : : 2) Someone mentioned that linking up a bunch of 'C' addresses will : require the use of some external gateway protocol (make sense - we need : to route between class 'C' networks) on our routers. Is this a big : deal? Is EGP a feature only available on expensive routers? : : 3) Are there any advantages to getting a contiguous set of class 'c' : addresses (e.g. 192.101.190,191,192, . . . etc)? You do need a continious group for the supeneting, the group must be a power of 2 (2,4,8,...) : : 4) Would there be any problem in implementing a single domain name : DNS over multiple class 'C' addresses? : : Thanks. : : Kent Kuriyama : kent@nosc.mil -- ------------------------------------------------------------------------- Mark Evans |evansmp@uhura.aston.ac.uk +(44) 21 429 9199 (Home) |evansmp@cs.aston.ac.uk +(44) 21 359 6531 x4039 (Office) |
-----------[000284][next][prev][last][first]---------------------------------------------------- Date: Sat, 23 Jan 1993 13:20:41 GMT From: christes@socrates.umd.edu (Skip Christensen) To: comp.unix.aix,comp.edu,comp.protocols.tcp-ip Subject: Re: HELP NEEDED TO MAKE ETHERNET AND TOKEN RING COEXIST ON RS6K
In article <C19xo1.D61@csfb1.fir.fbc.com> uunet!csfb1!jswanson writes: >In article <1993Jan21.164446.21646@oucsace.cs.ohiou.edu>, sivkumar@dolphins.ent.ohiou.edu (Krish Sivakumar) writes: >|> We have a IBM RS6000 530H running TCP/IP under AIX 3.2.3 >|> The machine is fully configured and operational with ethernet. >|> We are trying to set up a local token ring using the >|> Token Ring Adapter in the same Machine and planning to use the >|> ethernet as the Token Ring's Gateway to the outside world. >|> >|> We are not quite sure how to go about doing this. Initial attempts ended >|> up in the ethernet getting rendered inactive >|> >|> Any suggestions, comments, ideas, solutions or thoughts are more than welcome. >|> Thanks >|> -- >|> ----------------------------------------------------------------------- >|> - Krish Sivakumar Drive Defensively, Buy a tank - >|> - Dept. of Mechanical Engineering ------------------------------- >|> - Ohio University, - /\ /\ > > >It should be a simple matter to define each of the network adapters to have >a different address and put 2 addresses for your host in the host file. You >may need to assign a different subnet to each network card rather than simply >a different host address, but one or the other should work fine. This is a >standard feature of IP. > >Once the network cards are set up, you infrom the other nodes that they may >route through the dual-ported node to access the folks on the other side. > >-- >Jim Swanson >First Boston Corporation >5WTC - 9th floor >New York, NY 10048 >(212)322-1085 I agree - I've installed a model 340 with its built-in Ethernet (one address), a second Ethernet (another addreess) and a dual-ring FDDI (with its own address). No problem.
-----------[000285][next][prev][last][first]---------------------------------------------------- Date: 23 Jan 1993 14:28:11 GMT From: rv@deins.Informatik.Uni-Dortmund.DE (Ruediger Volk) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: Re: Multiple class 'C' addresses versus single class 'B'
In article <1993Jan23.002517.22830@nosc.mil>, kent@humu.nosc.mil (Kent K. Kuriyama) writes: > I would like to get comments regarding the problems of using multiple > class 'C' addresses vice a single class 'B' addresses. Obviously > this is an issue because the NIC is hesitant in granting the rapidly > diminishing number of class 'B' addresses. > > We intend to have approximately 2000 IP addresses with typically 50 > address per sub-net. Using class 'C' address we are looking at 40 sub- > nets or approximately 10 'C' addresses. don't forget that in both the host and the subnet field of an IP address you should NOT use the values 0 and -1 (all ones). This implies that the subnetting a class C network can be done in only the folowing ways: bit split # of subnets max # addr/subnet total max # usable addrs 0:8 1 254 254 1:7 ** illegal ** 2:6 2 62 124 3:5 6 30 180 4:4 14 14 196 5:3 30 6 180 2:6 62 2 124 7:1 ** illegal ** 0:8 ** nonsense ** Of course things look different when CIDR is fully available (i.e. you use a supernet of 2*n class Cs and can ignore the 24:8 split of class C). > Questions: > > 2) Someone mentioned that linking up a bunch of 'C' addresses will > require the use of some external gateway protocol (make sense - we need > to route between class 'C' networks) on our routers. Is this a big > deal? Is EGP a feature only available on expensive routers? no, for routing within your "routing domain" you can use the same interior gateway protocols as you would use within a single B. Exterior gateway protocols like EGP (if starting to use one, better try going for BGP) are only needed between different autonomous systems - i.e. network compounds with a separate administratgion and routing policy. > 3) Are there any advantages to getting a contiguous set of class 'c' > addresses (e.g. 192.101.190,191,192, . . . etc)? YES; supernetting - need a power of two with a common prefix > 4) Would there be any problem in implementing a single domain name > DNS over multiple class 'C' addresses? NO - IP addresses and domain names are two COMPLETELY independant name spaces! The domain name service usually is used to provide a mapping between (some) IP addresses and domain names; this mapping can be defined in any way you want. -- Ruediger Volk Universitaet Dortmund, Informatik IRB DE-NIC Postfach 500 500 D-W-4600 Dortmund 50 Germany E-Mail: rv@Informatik.Uni-Dortmund.DE Phone: +49 231 755 4760 Fax: +49 231 755 2386
-----------[000286][next][prev][last][first]---------------------------------------------------- Date: 23 Jan 93 16:43:58 GMT From: alen@crash.cts.com (Alen Shapiro) To: comp.protocols.tcp-ip Subject: IBM OS/2 TCP-IP uses DOS (low) memory? HELP ME PLEASE!!
I'm in a bind... I have OS/2 v1.33 (can't use 2.0 due to lack of suitable device drivers) I have an application that runs on a LAN (IBM Adaptor card) under OS/2 and talks with another application on DOS (can't put the DOS app. on OS/2 due to lack of device drivers!!) The OS/2 side needs to open a telnet session with a remote host. I have IBMs TCP-IP (latest release = 2.1.1 (or thereabouts)). The problem is that IBMs TCP-IP uses DOS memory for its 2 drivers IFNET and INET. Each driver uses 100k and another 140k seems to be unavailable to DOS (even with a fairly cut-down CONFIG.SYS). With 340k out of 640k unavailable to DOS, I can't run my 360k DOS application. QUESTIONS: 1) Why is 140k out of 640k unavailable to DOS with even a minimal CONFIG.SYS (i.e. no TCP-IP or LAN drivers)? ... Can this be changed? (RMSIZE is = 640 in CONFIG.SYS) 2) Can the TCP-IP drivers be persuaded to load high and thus be unavailable to DOS (and not use its memory) (I only need telnet from OS/2)? 3) Are there any TCP-IP packages (commercial or not) that either take a small chunk of DOS memory or none at all? 4) Are there utilities that will show me which drivers are using how much memory? Please help me...I'm in a maze of twisty passages all alike!! --alen Please email to alen@crash.cts.com I'll summarize for the net.
-----------[000287][next][prev][last][first]---------------------------------------------------- Date: Sun, 24 Jan 1993 04:27:07 GMT From: Frank@mindlink.bc.ca (Frank I. Reiter) To: comp.protocols.tcp-ip Subject: Moving from coax to 10BaseT
In a recent column in OST James Gaskin suggests that system administrators should be converting ethernets from coax to 10BaseT and *not* investing anything more in coax. I put two questions to the readers of this group: 1) Do you concur with Mr. Gaskin that coax is dead or dying? 2) What options are available for small (less than a dozen nodes) networks currently running coax and wanting to move to 10BaseT? For example, I understand that 10BaseT topology has all nodes wired to hubs - are there hubs available which are cost effective for small networks? I look forward to your replies... Frank. -- ___________________________________________________________________ Frank I. Reiter Internet: Frank@mindlink.bc.ca MIND LINK! Communications Corp. Surrey, British Columbia, Canada
-----------[000288][next][prev][last][first]---------------------------------------------------- Date: Sun, 24 Jan 1993 23:10:44 GMT From: merce@xenitec.on.ca (Jim Mercer) To: comp.protocols.tcp-ip Subject: Re: Moving from coax to 10BaseT
In article Frank@mindlink.bc.ca (Frank I. Reiter) writes: >In a recent column in OST James Gaskin suggests that system administrators >should be converting ethernets from coax to 10BaseT and *not* investing >anything more in coax. hmm, how nice of OST. don't suppose they mentioned that you should kill your unix boxes and put up OS/2, NT or Netware? or even better, putting in an AS/400, cause it so easy to get one, "just point and order". >I put two questions to the readers of this group: > >1) Do you concur with Mr. Gaskin that coax is dead or dying? for new buildings, dead, except for the possibiliy of backbone pulls of thick coax to connect wiring centres, but then you might consider fiber. ' for existing buildings, if you are pulling new cable, pull UTP. you will probably save some money on media. you will spend it later in hubs. twisted pair gives you more options, ethernet, token ring, CDDI (copper version of FDDI), etc. as far as converting coax to twisted pair, it's your call. if what you have works, keep it. you can connect 10baseT and thinnet networks. >2) What options are available for small (less than a dozen nodes) networks >currently running coax and wanting to move to 10BaseT? For example, I >understand that 10BaseT topology has all nodes wired to hubs - are there hubs >available which are cost effective for small networks? hubs come in many sizes, 4, 8, 12, 16 port stan alone, racks which take 8/12, 16 port cards, etc. another selection you can make is "manageable" hubs. hubs with SNMP management tend to be almost double the cost (my experience) but worth it. i find that coax is cool for tabletop/workbecnch testing, or workgroups that have reasonable airspace around them. having UTP throughout the building now allows us to wire 10baseT, Starlan1, tokenring, RS232 and other stuffwith the same wire. life is much better. -- [ Jim Mercer Reptilian Research merce@iguana.reptiles.org +1 416-506-0654 ] [ longer life through colder blood ]
-----------[000289][next][prev][last][first]---------------------------------------------------- Date: Sun, 24 Jan 1993 23:36:27 GMT From: dvv@hq.demos.su (Dima Volodin) To: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip,comp.dcom.modems Subject: Re: Netblazer
xcuse me for deviating, anyway: We're running a slip link from here in Moscow to Alternet in VA, USA. Runs OK, but: I had to turn V.42/V.42bis off. Reason? It looks like V.42 window is too small for the huge roundtrip echo delay time (>=.5sec) we experience. When V.42/V.42bis was enabled, all we could have from ftp and friends was 500-700 bytes/sec, with V.42 turned off we have more pleasant 1100-1300 bytes/sec. Pity we cannot use V.42bis. Anyone knows how to make V.42 window larger on Telebit and/or ZyXEL? Dima
-----------[000290][next][prev][last][first]---------------------------------------------------- Date: Mon, 25 Jan 1993 05:31:09 GMT From: tga@oar.net (Germann Associates) To: comp.protocols.tcp-ip Subject: Re: IBM OS/2 TCP-IP uses DOS (low) memory? HELP ME PLEASE!!
In article <alen.727807438@crash.cts.com> alen@crash.cts.com (Alen Shapiro) writes: >I'm in a bind... > >I have OS/2 v1.33 (can't use 2.0 due to lack of suitable device drivers) >I have an application that runs on a LAN (IBM Adaptor card) under OS/2 > >QUESTIONS: >1) Why is 140k out of 640k unavailable to DOS with even a minimal > CONFIG.SYS (i.e. no TCP-IP or LAN drivers)? ... Can this be changed? > (RMSIZE is = 640 in CONFIG.SYS) Because the kernal and most of the device drivers in OS/2 1.x had to load low. This was to support the DOS box. Some of the device drivers are dual mode (i.e. they are user by both the DOS compatibility coffin and the OS/2 sessions themselves). And no, there ain't no way to change it. Guess you're SOL. >2) Can the TCP-IP drivers be persuaded to load high and thus be unavailable > to DOS (and not use its memory) (I only need telnet from OS/2)? Nope >3) Are there any TCP-IP packages (commercial or not) that either take a > small chunk of DOS memory or none at all? I'll defer this and the next to the rest of the net...... >4) Are there utilities that will show me which drivers are using how much > memory? > >Please help me...I'm in a maze of twisty passages all alike!! > >--alen >Please email to > alen@crash.cts.com >I'll summarize for the net. > > -- ============================================================================ Eric Germann "You see things; and you say 'Why' But I dream The Germann Associates things that never were; and I say 'Why not?'" eric@tga.com -- "Back to Methuselah" G.B. Shaw 1921
-----------[000291][next][prev][last][first]---------------------------------------------------- Date: Mon, 25 Jan 1993 20:29:50 -0800 (PST) From: Mark Crispin <mrc@Tomobiki-Cho.CAC.Washington.EDU> To: comp.protocols.tcp-ip Subject: Re: Moving from coax to 10BaseT
Just to add a side note to thinnet vs. 10BaseT argument.
I have a computer zoo in my residence. The connectivity between the zoo
critters is thinnet, for two reasons:
1) I'm too cheap to buy a hub
2) one of the critters is a sweet old dinosaur who, when she gets the right
connecting cable and a bit of programming, will think she is talking
thicknet (albeit coerced to thinnet).
In spite of the limited scope of my thinnet, I have spent entirely too much
time debugging it.
If I were to do it again, I'd probably make it 10BaseT and figure some way to
coerce the dinosaur to play the 10BaseT game.
-----------[000292][next][prev][last][first]---------------------------------------------------- Date: Mon, 25 Jan 1993 09:03:31 GMT From: geertj@ica.philips.nl (Geert Jan de Groot) To: comp.protocols.tcp-ip Subject: solaris FTP bug (was: Re: Determining Port Numbers....)
maritza@espresso.bae.bellcore.com (Maritza Ramirez) writes: >Example: > ___________________ ftp's well known port > / >$ telnet itsname 21 >Trying 128.96.133.64 ... >Connected to itsname. >Escape character is '^]'. >220 itsname FTP server ready. _____________ ftp server accepts connection >USER maritza >331 Password required for maritza. >PASS mypass123 >230 User maritza logged in. >HELP >214-The following commands are recognized (* =>'s unimplemented). > USER PORT RETR MSND* ALLO DELE SITE* XMKD CDUP > PASS PASV STOR MSOM* REST* CWD STAT* RMD XCUP > ACCT* TYPE APPE MSAM* RNFR XCWD HELP XRMD STOU > REIN* STRU MLFL* MRSQ* RNTO LIST NOOP PWD > QUIT MODE MAIL* MRCP* ABOR NLST MKD XPWD >QUIT >221 Goodbye. >Connection closed by foreign host. >$ Please note that Maritza probably used a solaris 5.1 machine to display this; you can tell because the response to the HELP command is incorrect. The last line of the response should start with 214<space> to show that this is the last line of the response. There are probalby going to be zillions if machines that have this problem. Has anybody found yet where SUN moved the FTP help response file? Geert Jan
-----------[000293][next][prev][last][first]---------------------------------------------------- Date: Mon, 25 Jan 1993 09:51:34 GMT From: geertj@ica.philips.nl (Geert Jan de Groot) To: comp.protocols.tcp-ip Subject: Re: Moving from coax to 10BaseT
Frank@mindlink.bc.ca (Frank I. Reiter) writes: >In a recent column in OST James Gaskin suggests that system administrators >should be converting ethernets from coax to 10BaseT and *not* investing >anything more in coax. I put two questions to the readers of this group: >1) Do you concur with Mr. Gaskin that coax is dead or dying? No, most certainly not. 10baseT is point-to-point. Which means that you have to have a separate connection between the HUB and every apparatus in your office. In my case, this would mean that I'd fill more than one hub, just for my own equipment! Coax has the big advantage that a new tap can be easily made by adding another T and a piece of coax to the existing wiring. 10baseT is best if you have to run an office of non-technical people that move around a lot and don't know they have to jumper their ethernet tap if they move. Also, if they are sluggish about their cables and break one once a while, 10baseT can be a lifesaver. (coax would mean that you have to hunt for the defective tap every time, like a defect light bulb in a christmas tree). However, for an office of techies, often having more than one device on their bench, I still very much prefer coax. And then, one should not make an ethernet string too long anyway. No more than 5 people depend on a single string to work here. Also, those five are able to fill that segment quite severely so it's no use putting up much machines. Coax isn't 'dead'. It's just that for some applications, there are alternatives these days. Geert Jan
-----------[000294][next][prev][last][first]---------------------------------------------------- Date: 25 Jan 1993 19:47:10 -0500 From: ian@agranat.Agranat.com (Ian Douglas Agranat) To: comp.protocols.tcp-ip Subject: IP Multicasting across routers
I am designing a proprietary application for which IP multicasting across routers may be desirable. I am curious if anyone has any information regarding: 1. Which router vendors support RFC 1112 for routing IP multicast packets across subnets? 2. What kind of performance penalty or processing overhead is typically associated with IP multicasting both within a host and within the routers? 3. What kinds of applications use IP multicasting today? How widely used are they? 4. What policies exist for the registration of well-known IP multicast addresses? I don't have time to read this group often, so please send replies directly to me at ian@Agranat.COM. Any help would be greatly appreciated. -- Ian Douglas Agranat Agranat Systems, Inc. ian@Agranat.COM
-----------[000295][next][prev][last][first]---------------------------------------------------- Date: Mon, 25 Jan 93 13:52:28 GMT From: barr@pop.psu.edu (David Barr) To: comp.protocols.tcp-ip Subject: Re: Moving from coax to 10BaseT
In article <1993Jan25.095134.25886@ica.philips.nl> geertj@ica.philips.nl (Geert Jan de Groot) writes: >Frank@mindlink.bc.ca (Frank I. Reiter) writes: > >>In a recent column in OST James Gaskin suggests that system administrators >>should be converting ethernets from coax to 10BaseT and *not* investing >>anything more in coax. I put two questions to the readers of this group: >>1) Do you concur with Mr. Gaskin that coax is dead or dying? > >No, most certainly not. 10baseT is point-to-point. Which means that you >have to have a separate connection between the HUB and every apparatus >in your office. In my case, this would mean that I'd fill more than one >hub, just for my own equipment! You aren't limited to single-star topolgies. Buy small (10-12 port) hubs and chain them together with AUI cables. If you're starting from scratch, 10BaseT is the way to go, IMHO. --Dave -- System Administrator, Population Research Institute barr@pop.psu.edu What does it profit a man if he gains the whole world, but still runs DOS?
-----------[000296][next][prev][last][first]---------------------------------------------------- Date: Mon, 25 Jan 1993 14:08:43 GMT From: smb@research.att.com (Steven Bellovin) To: comp.protocols.tcp-ip Subject: Re: Moving from coax to 10BaseT
In article <1993Jan25.095134.25886@ica.philips.nl>, geertj@ica.philips.nl (Geert Jan de Groot) writes: > Coax has the big advantage that a new tap can be easily made by adding > another T and a piece of coax to the existing wiring. > > 10baseT is best if you have to run an office of non-technical people that > move around a lot and don't know they have to jumper their ethernet tap > if they move. Also, if they are sluggish about their cables and break > one once a while, 10baseT can be a lifesaver. (coax would mean that you > have to hunt for the defective tap every time, like a defect light bulb > in a christmas tree). This is exactly why I much prefer 10BaseT, even for technical folks. Briefly, 10BaseT is much easier to *manage*. You can isolate faults much more quickly. Each segment is independent, and you're not relying on the quality of vampire taps. From experience, they're often difficult to get right. And failures are hard to find. Besides, no matter how good your technical people are, you're still vulnerable to random electricians accidentally cutting your coax, and mending it with wire nuts and black tape. (No, I'm not making this one up....) There's a second major advantage to 10BaseT -- you can install lots more ``just in case'' wiring. Twisted pair cable is cheap; you can afford to have lots of it in the walls of offices you don't think need more connections. If and when you need them, you can just cross-connect at a patch panel. You can't do that with coax -- at best, you can put 15 wire cables into the wall. But those are much more expensive, and you still have to install a transceiver. (Well, yes, you could have a patch panel of multi-port transceivers in your wiring close, but the distance limitations will get you.) For folks who really need many offices with multiple connections, thin-wire coax might be an acceptable compromise. You still get to isolate segments, and you still get the advantages of a patch panel and relatively cheap wire. I fear, though, that thin-wire coax might be a dinosaur. 10BaseT has most of its advantages, uses cheaper, multi- purpose wire, and more standard components. Its one disadvantage -- that you need a separate hub port for each device -- is offset by the continuing drop in hardware prices. I tend to doubt that much new thin-wire gear is going to show up on the market. Thickwire coax is, in my opinion, useful primarily in machine rooms. The configuration is comparatively static; electrically, it's a high- noise environment, and you don't want to put all your file server eggs in one active basket. Even so, a failed coax can put you off the air much longer than it takes to swap out a failed hub.
-----------[000297][next][prev][last][first]---------------------------------------------------- Date: 25 Jan 1993 16:44:44 GMT From: schuetz@fm11ap01.tu-graz.ac.at (Alexander Schuetz) To: comp.protocols.tcp-ip Subject: Please tell a newbie the differences betw FSP and FTP and ...
Hi dudes,
I hope you don't mind some FAQs (?) from a newbie, do you? Well, I need
some technical info about FTP, FSP, TELNET and stuff like that....
1.) What is FSP exactly? I know and have seen FTP already and been told
that FSP is kinda similar. What are the differences? Is there a program
"FSP.EXE" for the IBMPC, similar to the "FTP.EXE" from FTP software?
Or, is there a public domain version?
If not, is there atleast a UNIX version? Is is shareware anyway?
If it *is* shareware, on which FTP site, in which subdir might I
find it? If not, where can I find info, anyway?
2.) Our "tn.exe" (telnet) preferres to make fuss. Sometimes I can easily
connect to an FTP site, but at the same time TN would't want to
connect. ("Host unrechable, destination unreachable"). Strange...
In general, TELNET seems not to want to connect as easily as FTP.
Any help is greatly appreciated, E-mail answers preferred 'coz I cant
sift through all the news everyday.
Thanks
Alex (schuetz@fm11ap01.tu-graz.ac.at)
-----------[000298][next][prev][last][first]---------------------------------------------------- Date: 26 Jan 1993 01:07:09 -0500 From: tal@plts.uucp (Tom Limoncelli) To: comp.protocols.tcp-ip Subject: Re: Moving from coax to 10BaseT
In <1993Jan24.231044.16138@xenitec.on.ca> merce@xenitec.on.ca (Jim Mercer) writes: >having UTP throughout the building now allows us to wire 10baseT, Starlan1, >tokenring, RS232 and other stuffwith the same wire. life is much better. This the the crux of the matter. Making life easier. 10baseT does have a lot of advantages in that regard. My favorite is the ability to run "n" UTP lines to each office and you can use them for "n" of the following: phone, 10baseT, appletalk, serial, second phone, serial line, [I'm sure others can add to this list.] However, converting an old office building that's already wired for one kind of networking to any other is a whole 'nother matter. No 2-page article in a throw-away networking magazine can tell you what's right for you. I would never convert an entire building from one networking technology to another without a LOT of thought about what my needs might be in the next i years (where i is different depending on your corporate culture). I think the real question is "Why are industry pundits starting to recommend 10baseT all over the place?" I think the answer to that is simple: They know that all the new machines coming out have it built in. Look at the back of all the new SparcLX/SparcClassic, the DEC Alpha, HP, etc.[*] and guess what's there. Also, they know that by the time a person needs to convert from 10baseT to the next level of networking [CDDI?] someone will have developed a way to run it over UTP. (or so we all hope :-) ). I laugh in December when every industry pundit writes a column of "predictions for next year". Most of what they list are things that they've been told under non-disclosure but they don't name the company. For example, "This will be the year for ISDN" was a good prediction for 1993 since anyone with a couple non-disclosure agreements could tell you that EVERY new machine has ISDN hardware because EVERY computer company thinks that Mitch's EFF is going to get congress to pass their ISDN package. Nostradamus? Bah. He just had the right connections. Tom Footnote: [*] I would have listed the Sparc 10 but that would be unrealistic since everyone knows that they aren't really shipping. Oh sure, Sun shipped a few so their press-releases can say that they're shipping, but talk to anyone that has ordered one and you'll find that they've been told "next week" for the last 3 months. I doubt they'll ship in quantity for another year and by then Sun should have developed a chip who's design wasn't DOA. ...but that's just my opinion. If you want to have fun with a Sun salesthing: Next time they tell you "next week" bet them dinner that it won't arrive in the next 7 days. -- Tom Limoncelli -- tal@plts.uucp (home) -- tal@warren.mentorg.com (work) Moderator of ne-social-motss and the Drew University Alumni/ae mailing lists. "There is nothing wrong with America that cannot be cured by what is right with America." --Bill Clinton's inaugural address, 1/20/93
-----------[000299][next][prev][last][first]---------------------------------------------------- Date: 25 Jan 93 18:29:38 GMT From: donp@novell.com (don provan) To: comp.protocols.tcp-ip Subject: Re: Moving from coax to 10BaseT
In article <1993Jan25.095134.25886@ica.philips.nl> geertj@ica.philips.nl (Geert Jan de Groot) writes: >No, most certainly not. 10baseT is point-to-point. Which means that you >have to have a separate connection between the HUB and every apparatus >in your office. In my case, this would mean that I'd fill more than one >hub, just for my own equipment! In my building, they just give each engineer an eight port 10baseT fan-out unit (i guess the official term is "micro repeater"). I've got two in my office. Am i breaking some 10baseT rule? >10baseT is best if you have to run an office of non-technical people... Actually, i've seen no correlation between "non-technical people" and coax failure. If anything, the more technical the people, the more often they try to modify the cabling. With coax, the failure rate seems to be almost directly proportional to the frequency of modifications, and the difficulty of finding a failure increases geometrically in relation to the number of people that make modifications. I was really mystified a couple of years ago when they started pulling miles of 10baseT to replace our "perfectly good" coax, but in retrospect i must admit that our networks are much more stable than with the coax. don provan donp@novell.com
-----------[000300][next][prev][last][first]---------------------------------------------------- Date: 25 Jan 1993 19:09:55 GMT From: trier@slc6.ins.cwru.edu (Stephen C. Trier) To: comp.protocols.tcp-ip Subject: Re: TCP congestion/Nagle's algorithm
In article <1993Jan23.113544.5652@nmsu.edu> amolitor@moink.nmsu.edu (Andrew Molitor) writes: > Second, Nagle seems to be saying that a TCP should not >send new data while unack'd data is outstanding, while Karn's >code seems to not send new data while unack'd data is outstanding >*unless* there is a max segment sized chunk to go out. I thought the latter is what Nagle said, too, but I just went and reread it, and I think you're right. He doesn't talk about sending immediately when one can send a full packet. RFC 1122 amends the 896, though, and 1122 does say that one should not wait for an ack before sending an MSS- sized packet. Perhaps what happened is Jacobson's Slow Start and Congestion Avoidance algorithms provided a better way to solve the broader congestion problem, so Nagle's algorithm is now used only for smaller-than-MSS packets. RFC 1122 has a nice description of how all of the different "when to send" algorithms, including Nagle's, fit together. -- Stephen Trier "We want to offer you a price that you Network software type just can't afford to take advantage of." Case Western Reserve University - Sales blurb from HSC Software trier@ins.cwru.edu
-----------[000301][next][prev][last][first]---------------------------------------------------- Date: 25 Jan 93 20:48:39 GMT From: joeg@novell.com (Joe Gervais) To: comp.protocols.tcp-ip Subject: Re: Moving from coax to 10BaseT
In article <1993Jan25.182938.6414@novell.com> donp@novell.com (don provan) writes:
>In article <1993Jan25.095134.25886@ica.philips.nl> geertj@ica.philips.nl (Geert Jan de Groot) writes:
>>No, most certainly not. 10baseT is point-to-point. Which means that you
>>have to have a separate connection between the HUB and every apparatus
>>in your office. In my case, this would mean that I'd fill more than one
>>hub, just for my own equipment!
>
>In my building, they just give each engineer an eight port 10baseT
>fan-out unit (i guess the official term is "micro repeater"). I've
>got two in my office. Am i breaking some 10baseT rule?
IEEE allows 4 repeaters between any two end stations. I've seen two common
approaches. For the site with the technical people that insist on using
thinnet or 10base2 in their offices or labs because it's "easier to work
with", 10baseT is used to feed the lab or office, and a 10baseT to 10base2
repeater is installed. MIS gets the advantage of individual manageable
segments to each office or lab, and the engineers get to keep their coax,
but Bob removing a terminator or BNC tee in his office will not break the
LAN in John's office.
The second approach is the one Don mentioned, which is to structure the LAN
so each office or LAB can have one more layer of repeaters.
A legal topology diagram that abides by the 4 repeater, no more than 3
tapped coax segments is as follows:
10base5 or 10base2 backbone
-------------------------------
| | |
-------- -------- --------
Wiring Closets | rptr | | rptr | | rptr |
-------- -------- --------
_______| | | |<----FOIRL or 10baseT
- - - - - | - - - | - - - | - - - | - -
| | | |
-------- -------- -------- --------
Labs / | rptr | | rptr | | rptr | | rptr |
Offices -------- -------- -------- --------
| | | | | | | | | | | |<---any media
If you draw the topology as a tree, with a coax backbone, you can go down
two levels of repeaters maximum, and the links between the two levels of
repeaters must be link segments, or you will exceed the 3 populated coax
segment rule. Note that with this topology, a large total number of
repeaters can be used, because you aren't restricted to how many repeaters
off the backbone segment, or how many repeaters off the first layer of
repeaters, just as long as between any two DTEs, you don't traverse more
than 4 repeaters. The problem I've usually seen is using 10baseT hubs
and making three layers of repeaters, which puts five repeaters in the path
between two DTEs. So Don, please be sure your second micro-repeater is not
daisy-chained off the first, and you're probably okay.
Joe Gervais
Joe_Gervais@Novell.com
-----------[000302][next][prev][last][first]---------------------------------------------------- Date: Mon, 25 Jan 1993 23:16:55 GMT From: TOVSRUD@gribb.hsr.no (Tovsrud, Kjell Ove 1-94) To: comp.protocols.tcp-ip Subject: What is TCP/IP ?
Can sombody out there give me a better discription about TCP/IP ? I have to learn what this is !!! Thanks! Kjell Ove
-----------[000303][next][prev][last][first]---------------------------------------------------- Date: Tue, 26 Jan 1993 00:28:14 GMT From: johnk@gordian.com (John Kalucki) To: comp.protocols.tcp-ip Subject: Re: Anyone know of a good LPR/LPD Server?
In article <16B5BE8CE.MACE@HDQCMS2H.UTSD.ATT.COM>, MACE@HDQCMS2H.UTSD.ATT.COM writes: >We have 10 LaserJet printers which we would like to connect to a LPD >server, for access by our OS/2, DOS/Windows and IBM VM/CMS users. > >We would rather not use LPD on various machines directly connected to >the printers, since we would lose access to the printer when the machine >went down (was re-booted or powered off). > >The connections would be serial (RS-232), with one connection being >parallel. > >We have looked at the Lantronix equipment, but that does not really >offer LPD; since we have a diverse user community, we want to use the >LPR and LPRMON software that is provided with the TCP/IP implementations. Hmm. That's funny. I have the Lantronix EPS1 here that does LPD and it works fine. -John Kalucki johnk@gordian.com
-----------[000304][next][prev][last][first]---------------------------------------------------- Date: Tue, 26 Jan 93 08:03:54 EST From: MACE@HDQCMS2H.UTSD.ATT.COM To: comp.protocols.tcp-ip Subject: Re: Anyone know of a good LPR/LPD Server?
In article <1993Jan26.002814.1015@gordian.com> johnk@gordian.com (John Kalucki) writes: > >In article <16B5BE8CE.MACE@HDQCMS2H.UTSD.ATT.COM>, MACE@HDQCMS2H.UTSD.ATT.COM writes: >>We have 10 LaserJet printers which we would like to connect to a LPD >>server, for access by our OS/2, DOS/Windows and IBM VM/CMS users. >> >>We would rather not use LPD on various machines directly connected to >>the printers, since we would lose access to the printer when the machine >>went down (was re-booted or powered off). >> >>The connections would be serial (RS-232), with one connection being >>parallel. >> >>We have looked at the Lantronix equipment, but that does not really >>offer LPD; since we have a diverse user community, we want to use the >>LPR and LPRMON software that is provided with the TCP/IP implementations. > >Hmm. That's funny. I have the Lantronix EPS1 here that does LPD >and it works fine. > > > -John Kalucki > johnk@gordian.com > According to Lantronix, their unit really does RTEL, which can be made to appear to be LPD. The problem is that you must use Lantronix supplied software (not standard LPR software), and that software is only supported for Unix. Since we have DOS, Windows, OS/2 and VM/CMS Lantronix indicated that we were out of luck. They said that they would be providing true LPD support in 2Q93, but still only supported for Unix (since the microcode upload is only supported on Unix). Thanks for the reply, though! -------------------------------------------------------------------------- Mace Moneta, AT&T VM Product Engineering, Piscataway, NJ --------------------------------------------------------------------------
-----------[000305][next][prev][last][first]---------------------------------------------------- Date: Tue, 26 Jan 1993 03:38:09 GMT From: karl@empirical.com (Karl Auerbach) To: comp.protocols.tcp-ip Subject: Re: Moving from coax to 10BaseT
>In a recent column in OST James Gaskin suggests that system administrators >should be converting ethernets from coax to 10BaseT and *not* investing >anything more in coax. I put two questions to the readers of this group: > >1) Do you concur with Mr. Gaskin that coax is dead or dying? > >2) What options are available for small (less than a dozen nodes) networks >currently running coax and wanting to move to 10BaseT? For example, I >understand that 10BaseT topology has all nodes wired to hubs - are there hubs >available which are cost effective for small networks? I lead the Interop "wipe out thinnet" brigade. I strongly agree that thinnet should go the way of punched cards. About the *only* remaining use for thin-net any more is where you have a cluster of machines, say a collection of X terminals, all in one room. When we design and build Interop, that is the only way we will use cheapernet. (We now use fiber-optic Ethernet rather than thick coax for the long runs.) I would never run thin-net through a wall and I would never put it where high reliability is required. Because coax (whether thick or thin) does not limit termination or shorting problems, it tends to break whenever a user gets it into his mind to move something. 10-Base-T, on the other hand, is much more robust. The wire itself is more solid. (And if you use the standard 4-pair stuff, you get two spare pairs, just in case.) If you use level 4 or level 5 wire, you can run it quite a long distance. The RJ45 connectors tend to be pretty solid, much more so than most coax connectors (at least with respect to how they connect to the cable itself.) 10-Base-T hubs also often have very nice properties -- they can block out screeming (jabbering) hosts, block hosts which are sending mal-formed packets, enforce security, etc. They often gather interesting statistics about which hosts are using the net, etc. The 10-Base-T link state light itself is worth many man-hours of saved labor whenever a user calls up and says "my machine isn't talking on the net." On some h