|
|
ARCHIVE: TCP-IP Distribution List - Archives (1991)
DOCUMENT: TCP-IP Distribution List for March 1991 (353 messages, 180385 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1991/03.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 Mar 91 04:12:16 GMT From: digennar@umbc3.UMBC.EDU (Mr. Jerry DiGennaro) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Request for information on netmask
Could somebody please point me in the direction of any easy to comprehend essay on the purpose and use of the TCP-IP netmask feature? Or, could someone e-mail me a brief description of netmask? Some specific questions are: What is the difference between 255.255.255.0, 255.255.0.0 and 0.0.0.0? How is the netmask used? Why does it exist? What other questions should be asked by a novice? You can send me e-mail to jad@loyola.edu or digennaro@umbc3.umbc.edu or post a reply to these groups. Thanks in advance for your efforts. Jerry DiGennaro -- Jerry DiGennaro digennar@umbc3.umbc.edu (301) 532-5129
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 91 06:39:48 GMT From: marc@dumbcat.sf.ca.us (Marco S Hyman) To: comp.protocols.tcp-ip Subject: Re: What Is Difference Between Internet And X.400 Style Names?
In article <8698@gollum.twg.com> david@twg.com (David S. Herron) writes:
Marshal Roses "The Open Book" (but only if you can stand long
digressions into the political maneuvers which networking
development has become ... (*sigh*))
At least Marshal Rose is nice enough to warn the reader when he gets on his
soapbox. (The margins have "Begin Soap...End Soap" delimiters.)
// marc
--
// marc@dumbcat.sf.ca.us
// {ames,decwrl,sun}!pacbell!dumbcat!marc
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 91 08:04:33 GMT From: j.onions@xtel.co.uk (Julian Onions) To: comp.protocols.tcp-ip Subject: Re: do me a favor and answer this
> X.{4,5}00 names for people & mailboxes have (at least) the following attri
bu
> tes:
>
> Country /C=../
> Administrative Domain /ADMD=.../
> Primary Domain /PRMD=.../
> Organization /O=.../
> Organizational Unit /OU=.../
> Surname /S=.../
> Given Name /G=.../
> Common Name /CN=.../
No - you are missing something here. X.400 and X.500 are different.
X.400 was designed before X.500 and therefore X.400 could not rely on
X.500 information. This is why X.400 includes obvious routing things
such as ADMD and PRMD. An X.500 Distinguished Name has almost no
constraints on it whatsoever. In practice, it usual starts with a
Country, Orgnization or locality as the most significant part, but
this is not enforced by the standard. X.500 is used to look up X.400
names so my X.500 DN may be very different to my X.400 mail address
and you can't in general algorithmically derive one from another.
The X.500 name is meant to be natural and 'intuitive' the X.400
address is meant as an address. As it looks so horrible - you are
meant to try and hide it from the users wherever possible (my
opinion). Just to complete this an example:
My Distinguished Directory Name is the following (in white pages
syntax)
C=GB@O=X-Tel Services Ltd@cn=Julian Onions
my X.400 address on the other hand is (in rfc987 syntax)
/C=GB/ADMD= /PRMD=X-Tel Services Ltd/O=Xtel/I=J/S=Onions/
X.400 in the 1984 recommendation says an address is made up of the
following components.
Country, ADMD, PRMD, X121address, TerminalID, Organization,
UniqueUAID, Personal Name (made up of initial, given, surname and
generational-qualifier) organizationalunit and domaindefined-attributes
X.400 only allows one of 5 combinations of these though.
X121address & terminalID (optional) - used for sending mail when
- you're infrastructure only
- supports digits (e.g.
- phone/telex)
C, ADMD, UniqueUAId & DD (optional)
C, ADMD, X121address & DD (optional)
C, ADMD, + one or more of { PRMD, PN, O, OU, DD }
In practice, it is only the last one that I have ever seen used.
The other cases I think are for a PTT running a service and supplying
a mailbox facility or some such.
In the 1988 X.400 standard a whole bunch of new attributes were added.
There are one or two extensions, such as CommonName for things that
are and aren't people (seems kind of silly to address a list as
'Surname=tcp-ip'). The rest are broadly speaking either Teletex string
forms of the above, so that you can type names in whatever alphabet
you require, or paper postal address attributes to allow interworking
between X.400 and the postal system.
> Are these attributes required of every X.[45]00 people and mailbox
> names, or are they specific to the naming convention chosen by the
> NYSERNet White Pages Project (and possibly others)?
Summary: X.400 is fairly rigid in the addresses you can have, X.500
isn't. The white pages project has a lot of freedom to choose formats,
X.400 people don't have so much. (In practice, you don't get so much
freedom in X.500 - you are dependant on what the higher parts of the
tree define. For E.G. if C=US decided that at the next layer down people are
either put into subtrees type=competent and type=incompetent you are
stuck with this if you want to join the tree :-) ...)
Julian.
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 91 13:27:00 GMT From: 0004219666@MCIMAIL.COM (Bob Stine) To: comp.protocols.tcp-ip Subject: IP addressing & T1 channels
A client of mine is developing a real-time, distributed system that will use the
TCP/IP protocol suite for control & monitoring. A component in the system will
serve as a gateway between a LAN and a T1 link to (another gateway on) another
LAN.
In addition to control traffic, we will be performing down-line loads to
components on the distant LAN, sometihing like:
LAN T1 LAN
Server ------ GW --------- GW --------- Destination
1 2
Now, we don't want the bulk traffic to cause overly-long delays to the real-time
traffic. The control traffic will all be on a single 56kbs channel of the T1,
framed in HDLC. We were contemplating giving the down-line load traffic its own
channel, and using an application at GW2 to receive and distribute big files to
the destinations on the far LAN.
We will be writing our own device driver for the T1.
To me, a "natural" solution to this problem seems to be to use separate IP
addresses for the control and bulk-data channels.
Questions:
1. Would this require separate drivers to get any performance improvements
(i.e., would a sinlge HDLC device driver become a bottleneck)?
2. Is there a better approach?
3. What are the hidden "gotchas"?
4. Where could I look for more info?
Thanks,
Bob Stine
bstine@MCIMail.com
c_rstine@hns.com
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 91 15:17:00 GMT From: JRJONES@ALEX.STKATE.EDU To: comp.protocols.tcp-ip Subject: snmp packages on pc's
Hello, I have several questions dealing with SNMP and such packages on a PC. 1. Is anyone using any SNMP package on a PC? 2. What package are you using and how do you like it? 3. What short comings do you find? Because of cost issues we are now going to look at a pc solution so any info would really be helpful. James R. Jones jrjones@alex.stkate.edu voice - 612-690-6856 P.S. I will summarize responses send it over the net for everyone.
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 91 16:02:45 GMT From: SRGHGCP@chv.dsir.govt.nz To: comp.protocols.tcp-ip Subject: Re: NS DP8390 ethernet chip
In article <1991Feb14.150021.5723@unipalm.uucp>, leo@unipalm.uucp (E.J. Leoni-Smith) writes: > ash@uupc.omega (Andrew Hardie) writes: > >>I seem to remember some months ago talk about problems (dropped packets?) >>with the A and B versions of the DP8390 chip as fitted to the WD8003E. >>I notice that the new boards have the DP8390C chip. Can someone remind >>me what the problem was and whether it (and any others that may have >>existed in the A and/or B versions) were fixed in the C revision. >>Thanks >>-- >>Andrew Hardie ash@omega.uucp >>London, England ukc!cctal!omega!ash > > Include me in your mailing lists too - Russ? James? The NSC 8390 has been through a lot of revisions...there were even some released which were 'pre-A'. The B version has some problems with the internal statemachine on heavily loaded LANs. Exactly how the will manifest itself will depend on the software. The worst problem is that collisions may be lost due to a small 'blind' window. There are 3 main problems with the B rev, one can be sorted out in software and the other two need a hardware work around. Its fair to say that the last 2 problems shouldn't happen it the LAN is TOTALLY perfect! I can post a full description of them if you want? The C rev has no serious problems that I know of...we are using both B and C revs. There is also a D rev which is supposed to be a die shrink but is given the status of a rev 'cause DEC have'nt 'approved'it..or so the story goes! Geoff Peck Physical Sciences Division Information Technology Group Department of Scientific and Industrial Research New Zealand +64-4-666-919 fax; +64-4-690-067
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 91 16:22:47 GMT From: kasten@EUROPA.CLEARPOINT.COM (Frank Kastenholz) To: comp.protocols.tcp-ip Subject: Re: IP addressing & T1 channels
> From tcp-ip-RELAY@NIC.DDN.MIL Fri Mar 1 10:21:04 1991 > From: Bob Stine <0004219666@mcimail.com> > To: tcp-ip <tcp-ip@nic.ddn.mil> > Subject: IP addressing & T1 channels > > A client of mine is developing a real-time, distributed system that will use the > TCP/IP protocol suite for control & monitoring. A component in the system will > serve as a gateway between a LAN and a T1 link to (another gateway on) another > LAN. > > In addition to control traffic, we will be performing down-line loads to > components on the distant LAN, sometihing like: > > > LAN T1 LAN > Server ------ GW --------- GW --------- Destination > 1 2 > > Now, we don't want the bulk traffic to cause overly-long delays to the real-time > traffic. The control traffic will all be on a single 56kbs channel of the T1, > framed in HDLC. We were contemplating giving the down-line load traffic its own > channel, and using an application at GW2 to receive and distribute big files to > the destinations on the far LAN. > > We will be writing our own device driver for the T1. > > To me, a "natural" solution to this problem seems to be to use separate IP > addresses for the control and bulk-data channels. > > Questions: > > 1. Would this require separate drivers to get any performance improvements > (i.e., would a sinlge HDLC device driver become a bottleneck)? > > 2. Is there a better approach? > > 3. What are the hidden "gotchas"? > > 4. Where could I look for more info? > > Thanks, > > Bob Stine > bstine@MCIMail.com > c_rstine@hns.com Bob, I suggest that you use type of service routing for differentiating the traffic "streams". Do something like assigning the download traffic "high throughput" and the control traffic "low delay". It sounds like you are building your own router/gateway box so you can have it do the right thing. Differentiating things by IP address would be "a bad thing". First, IP addresses just identify an endpoint of the communications -- they are not meant to identify type of service. Second, what if you decide to change IP addresses? You might want to take a look at things like the OSPF spec and some of the Internet Drafts and RFCs on things like policy routing and the like. Hope this helps Frank Kastenholz Clearpoint Research Corp.
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 91 16:34:30 GMT From: guenther@irafs2.ira.uka.de (Guenther Schreiner) To: comp.protocols.tcp-ip Subject: Re: why UDP send ICMP port unreachable message?
In article <9103011243.AA10028@ucbvax.Berkeley.EDU>, TAYBENGH@NUSDISCS.BITNET writes: > Hi netlanders, > After reading thru the implementation of TCP/IP from > the book The Design and Implementation of the 4.3BSD OS (published by > Addison-Wesley) and the source code of BSD4.3 TCP/IP, I am puzzled of > the purpose of ICMP Port Unreachable error message sent by UDP that appeared > in the routine udp_input(). According to my understanding, this ICMP message > is never received by UDP, nor is reported to the user if the user send a > UDP message to a non-existent server (destination port). So why it is sent > by the UDP? Did I misunderstand sth? Even if it sounds strange, it is possible to establish a UDP "connection". If you do so (with the system call connect() and I/O with send()/recvfrom()), the I/O system calls will return EADDRNOTAVAIL, ENETDOWN and ENETUNREACH after an appropriate incoming ICMP message. In opposite to this the I/O calls will NOT return an error if you use a loose UDP connection (with sendto() and recvfrom() calls without a connect()). Hope this helps, Guenther -- Guenther Schreiner University of Karlsruhe, West Germany c/o Fakultaet fuer Informatik Phone: (0721) 608-2749 Am Fasanengarten 5 UUCP: ...!seismo!unido!uka!guenther 7500 Karlsruhe 1 CSNET: guenther@ira.uka.de EARN: GUENTHER at DKAUNI0I --
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 91 17:07:33 GMT From: jim@group1.uucp (Jim Haile) To: comp.protocols.tcp-ip Subject: MacTCP
We use MacTCP in an application that gets info from our Unix based database onto our Macs. It works great now through Ethernet but we are contemplating adding a 56K line to a remote office and I am concerned about MacTCP. Will it time out at this slower speed? Has anyone tried this? Thanks, Jim -- Jim Haile Group One, Ltd. uunet!group1!jim
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 91 18:15:15 GMT From: rstevens@noao.edu (Rich Stevens) To: comp.protocols.tcp-ip Subject: Re: why UDP send ICMP port unreachable message?
In article <9103011243.AA10028@ucbvax.Berkeley.EDU> TAYBENGH@NUSDISCS.BITNET writes: > According to my understanding, this ICMP message > is never received by UDP, nor is reported to the user if the user send a > UDP message to a non-existent server (destination port). UDP does indeed receive this message. It's not documented well, so you really need to go to the sources to see what's going on. The publicly available "BSD Networking Release" suffices. The sequence of events is: icmp_input() receives the ICMP error. The ICMP "type" is ICMP_UNREACH and the ICMP "code" is "port unreachable". This code is converted to PRC_UNREACH_PORT and udp_ctlinput() is called to process the error. udp_ctlinput() calls in_pcbnotify(), converting the PRC_UNREACH_PORT error into the ECONNREFUSED errno value, using the table inetctlerrmap[] (in the file ip_input.c). A 32-bit internet address is passed to udp_ctlinput() and this address is passed again to in_pcbnotify(). This address is the address that the datagram was sent to that generated the ICMP error. The routine in_pcbnotify() is interesting because it looks at this address and finds *every* socket that is connect()ed to this address and sends those sockets the asynchronous error ECONNREFUSED. So there are three caveats: (1) you'll only know about the error if you've done a connect(); (2) not only will you find out about the error, but *every* process on your host that is UDP "connect()ed" to the host that sends the ICMP port unreachable gets a ECONNREFUSED error; (3) you usually don't find out about the error when you send() the datagram to the port that no one is reading from, in most cases you'll find out when you do a recv() on that socket (assuming the classic send-a-datagram, receive-a-datagram scenario). Rich Stevens (rstevens@noao.edu)
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 91 19:55:08 GMT From: mab@mentor.cc.purdue.edu (Mike Brown) To: comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Looking for network/protocol analyzer
I'm looking for a PC- and/or Unix-based (especially RS/6000 AIX) network/protocol analysis software package that understands NFS/RPC/XDR over TCP/UDP/IP on ethernet networks. Understanding of other IP-family protocols would be a real bonus, too. I seem to recall a network posting in the last couple of months about such a package that was available via anonymous ftp. Naturally, I can't find the posting now that I need the package (must not have saved the article like I intended). Can anyone provide pointers to this or other packages with similar capabilities? We already have and make extensive use of a Sniffer, so that's not the recommendation I'm looking for here. I'm looking for something I can fire up in my office at random and sometimes extended intervals for troubleshooting without having to take the Sniffer out of productive use elsewhere. Thanks in advance for any information you can provide. If I get the usual flood of "please let me know what you find out" replies, I'll repost a short summary.
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 91 20:16:28 GMT From: chris@vision.uucp (Chris Davies) To: comp.protocols.tcp-ip Subject: Registering an "official" port name
Apologies in advance for my probable misuse of the word "port". I hope you will understand what I mean... We would like to be able to register a known TCP/IP port number (as seen in /etc/services on most implementations of TCP/IP that I've seen) for use by one of our products. We do not want to allow the system admin to choose (at installation time) which port our product should use - we want to be able to guarantee (ish) that port _number_ XYZ will have our client sitting on it. Unfortunately we don't know who (or what) is responsible for the allocation and registration of these ports. Can someone point me in the right direction? If not, has anyone got any useful suggestions, please? Thanks in advance, Chris -- VISIONWARE LTD | UK: chris@vision.uucp JANET: chris%vision.uucp@ukc 57 Cardigan Lane | US: chris@vware.mn.org BANGNET: ...!ukc!vision!chris LEEDS LS4 2LE, England | VOICE: +44 532 788858 FAX: +44 532 304676 -------------- "VisionWare: The home of DOS/UNIX/X integration" -------------
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 91 21:39:44 GMT From: mab@mentor.cc.purdue.edu (Mike Brown) To: comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Looking for network/protocol analyzer
I'm looking for a PC- and/or Unix-based (especially RS/6000 AIX) network/protocol analysis software package that understands NFS/RPC/XDR over TCP/UDP/IP on ethernet networks. Understanding of other IP-family protocols would be a real bonus, too. I seem to recall a network posting in the last couple of months about such a package that was available via anonymous ftp. Naturally, I can't find the posting now that I need the package (must not have saved the article like I intended). Can anyone provide pointers to this or other packages with similar capabilities? We already have and make extensive use of a Sniffer, so that's not the recommendation I'm looking for here. I'm looking for something I can fire up in my office at random and sometimes extended intervals for troubleshooting without having to take the Sniffer out of productive use elsewhere. Thanks in advance for any information you can provide. If I get the usual flood of "please let me know what you find out" replies, I'll repost a short summary. Mike Brown, Network Systems Programmer Internet: mab@cc.purdue.edu Purdue University Computing Center Bitnet: xmab@purccvm 1408 ENAD, Room 130A Phone: (317) 494-1787 West Lafayette, IN 47907, USA Fax: (317) 494-0566
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 2 Mar 91 03:48:00 GMT From: TAYBENGH@NUSDISCS.BITNET To: comp.protocols.tcp-ip Subject: why UDP send ICMP port unreachable message?
Hi netlanders,
After reading thru the implementation of TCP/IP from
the book The Design and Implementation of the 4.3BSD OS (published by
Addison-Wesley) and the source code of BSD4.3 TCP/IP, I am puzzled of
the purpose of ICMP Port Unreachable error message sent by UDP that appeared
in the routine udp_input(). According to my understanding, this ICMP message
is never received by UDP, nor is reported to the user if the user send a
UDP message to a non-existent server (destination port). So why it is sent
by the UDP? Did I misunderstand sth?
Also did TCP use this message to inform the client when it tries to
initiate a connection to a non-existent server?
Could somebody please explain this? Thanks a lot.
- Beng Hang (email: taybengh@nusdiscs.bitnet)
Dept of Information Systems and Computer Science
National University of Singapore
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 2 Mar 91 05:24:00 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: why UDP send ICMP port unreachable message?
In article <9103011243.AA10028@ucbvax.Berkeley.EDU> TAYBENGH@NUSDISCS.BITNET writes:
>I am puzzled of
>the purpose of ICMP Port Unreachable error message sent by UDP that appeared
>in the routine udp_input().
Others have already given adequate answers to this question (I am quite
disheartened if the assertion that the port unreachable message is sent to
all sockets connected to the host that sent the ICMP, i.e. that it doesn't
restrict it to sockets connected to the unreachable port).
> Also did TCP use this message to inform the client when it tries to
>initiate a connection to a non-existent server?
TCP doesn't use ICMP Port Unreachable. Instead, the remote host responds
to the SYN with a RST instead of a SYN. UDP needs to use ICMP because
there is no built-in handshake in the protocol, whereas TCP uses a
handshake to establish a connection and can include the error report as
part of the handshake.
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 2 Mar 91 12:41:59 GMT From: thad@public.BTR.COM (Thaddeus P. Floryan) To: comp.protocols.tcp-ip Subject: Re: Need a compact Ethernet driver for AT&T 7300
In article <1991Feb28.183714.12039@csusac.csus.edu> cs175111@csusac.ecs.csus.edu (Steven Little) writes:
>
> I am currently working on a project to connect an AT&T 7300
>to a host via an Ethernet cable. The problem I'm having is that
>the ROM space in the 7300 is very small.
> What I need is a reduced tcp-ip or a tiny tcp-ip to handle
>this problem. I thank anyone who can help me with my problem in advance.
I don't understand the reference to "small" ROM space; the system supports
up to 4MB (or 8MB) RAM and > 300MB HD; not bad for a circa-1985 10MHz 68010.
In any event, the AT&T 7300 is also known as the 3B1, and questions such as
this are best directed to comp.sys.3b1 where you'll get a LOT of help! :-)
Ethernet exists for the 3B1 (I have many connected on my net) as does StarLAN.
The Ethernet is the WIN/3B TCP/IP 802.3a-1988 10BASE2 10Mbit/S, and the
StarLAN is 802.3e-1988 1BASE5 1Mbit/S over twisted-pair.
Several people, myself included, have ported portions of the 4.3BSD "Tahoe"
networking software suite to the 3B1/7300 and some of this can be found at
osu-cis (aka cheops.cis.ohio-state.edu [IP 128.146.8.62]) and (soon) in the
comp.sources.3b1 newsgroup.
I also have copies of the 3B1/7300 Device Driver Development Guide (from AT&T)
available at cost for anyone interested; either send email (see sig below) or
browse the comp.sys.3b1 newsgroup.
Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 2 Mar 91 16:11:10 GMT From: Steven_Carmody@BROWN.EDU To: comp.protocols.tcp-ip Subject: sending data over citywide cable TV systems
We're currently talking to the local cable TV company about transmitting data over the "institutional cable" they are required to operate (interconnects schools, libraries, colleges, universities, hospitals, etc). We have ten years of experience with a campus based broadband system, and feel there is a reasonable possibility of success with the citywide cable. Unfortunately, as soon as we said the word "data" the cable company heard the words "common carrier", and routed our request to their legal dept. I'd like to supply the lawyers with a list of communities which are already doing what we're proposing. If you know of a community that's doing this, please send me a note. thanks very much.
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 2 Mar 91 18:58:31 GMT From: guy@auspex.auspex.com (Guy Harris) To: comp.protocols.tcp-ip Subject: Re: why UDP send ICMP port unreachable message?
>The routine in_pcbnotify() is interesting because it looks at this >address and finds *every* socket that is connect()ed to this address >and sends those sockets the asynchronous error ECONNREFUSED. The routine "in_pcbnotify()" is buggy. It is *not* supposed to be doing that. It appears to be fixed in 4.3-reno and in SunOS 4.1, and may be fixed in other systems as well.
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 2 Mar 91 19:11:58 GMT From: efb@suned1.Nswses.Navy.MIL (Everett F Batey) To: comp.protocols.tcp-ip Subject: Digital phones for SLIP circuits
Confronted with an urgent need to run SLIP between two Sun3s (OS 4.1 and 4.1.1) and some easy to comeby telephone assets AND NO money for modems, we are trying to pick the most trustworthy and easy to accomplish SLIP link. Sites are within 3 miles, wire, 1/2 mile crow flight. - We have Meridian phones for which we can get 9600 baud RS-232 interfaces. DOES ANYBODY know if with handshaking and async over digitized phone line, these data phone options WORK SUCCESSFULLY for this purpose ? - We have access to a four wire metallic circuit, not conditioned. Is there an economical, recent or old, technology four wire modem YOU USE to support 9600 baud SLIP ? - We have some available Telebit modems, no two alike and NO T2500. Dont think any are the newer of V32/V42 which ever that is. The last neighbor we knew using these a 200 mile dialup phone path spent lots of time restarting the circuit. Is there a good way to use these locally over an analog delivered voice grade phone line ? - How would YOU rate from YOUR PERSONAL experience these options, for cost effectiveness and ease ( idiot-proof-ness ) of installation ? - Remember in answering these questions, the right answer leads to the most efficient use of tax dollars. Thanks /Ev/ -- + efb@suned1.nswses.Navy.MIL efb@gcpacix.uucp efb@gcpacix.cotdazr.org + + efb@nosc.mil WA6CRE Gold Coast Sun Users Vta-SB-SLO DECUS gnu + + Opinions, MINE, NOT Uncle Sam_s | b-news postmaster xntp dns WAFFLE +
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 2 Mar 91 19:38:01 GMT From: cs175111@csusac.ecs.csus.edu (Steven Little) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domain Subject: Need 3b1 Ethernet driver
I need a compact or tiny tcp/ip for the 3b1. I'm trying to get a Ethernet driver for an EPROM based system. The 3b1's are being used to teach operating systems. The students are programing operating systems and cross compilling them to a host computer. The current method is to use the RS-232 ports, this is an extremely slow process. The problem is that I have a limited ROM space in which to place the driver. That is why I need the compact or tiny tcp/ip. Thank you in advance. send email to cs175111@csusac.ecs.csus.edu
-----------[000020][next][prev][last][first]----------------------------------------------------
Date: 2 Mar 91 21:35:49 GMT
From: dmbarton@ralvmm.vnet.ibm.com ("Daniel M. Barton")
To: comp.protocols.tcp-ip
Subject: Re: Underscores
> Hi,
> I've been getting complaints about my SMTP rejecting mail from sites
> with a underscore in its host name. If I read RFC 821 correctly, names
> may consist of letters, digits, and hyphens. Has this been liberalized
> recently?
> The site in question is: its_gate.cc.uow.edu.au
>
> Thanks,
> Jeff
RFC 821 and 822 weren't very clear on what characters a hostname could
contain. RFC 952, "DOD Internet Host Table Specification" clarifies
what characters are legal. The legal characters are letters, numbers,
and the hyphen, and the hostname must begin with a letter, and end with
a letter or digit. The exact syntax is:
<hname> ::= <name>*("."<name>)
<name> ::= <let>(*(let-or-digit-or-hyphen>)<let-or-digit>>
Note: I used parentheses instead of square brackets (none on my
terminal...)
Daniel
========================================================================
Daniel M. Barton
TCP/IP Development
IBM Research Triangle Park, NC
Internet: dmbarton@ralvmm.vnet.ibm.com
dmbarton%ralvmm@vnet.ibm.com
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 2 Mar 91 22:37:14 GMT From: solensky@animal.clearpoint.com (Frank T. Solensky) To: comp.protocols.tcp-ip Subject: Re: do FINs count as 1 like SYNs ?
>Hi! >Sending a SYN advances the sequence number by one since it must be ACKed. >A FIN is ACKed, too, so does it advanced the sequence number? >I browsed through RFC761 but found nothing which tells me. :-( Kai -- RFC 791 (which updated 763) describes the closing sequence pretty well and illustrates this case in Figure 13 (page 39). The packet that ACKs the FIN will have an ACK number one greater than the FIN's sequence number. So, yes, the sequence number is incremented after the FIN is transmitted (so that ACK will == snd.NXT). You may want to also get a copy of RFC-1122 (Requirements for Internet hosts): this document clarifies a number of points in both the TCP and IP protocol specifications that have been interpreted in different (and frequently incompatible) ways. -- Frank Solensky / Clearpoint Research Corp.
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 2 Mar 91 23:16:51 GMT From: oberman@amazon.llnl.gov To: comp.protocols.tcp-ip Subject: Re: UnderscoresDIR/NEW
In article <9103022255.AA04928@ucbvax.Berkeley.EDU>, dmbarton@ralvmm.vnet.ibm.com ("Daniel M. Barton") writes:
> RFC 821 and 822 weren't very clear on what characters a hostname could
> contain. RFC 952, "DOD Internet Host Table Specification" clarifies
> what characters are legal. The legal characters are letters, numbers,
> and the hyphen, and the hostname must begin with a letter, and end with
> a letter or digit. The exact syntax is:
This is out of date information RFC 1122 removes the prohibition of numeric
first characters in host names. Other than that, I know of no changes fron 952.
As far as I can tell, underscores remain a no-no.
That stated, they are quite common and most implementation will allow them. The
only problem is when you hit a system that doesn't. So, please follow the rules
and don't use them. I would also recommend against numeric first characters as
many implementation have not been changed since 1122/1123 were issued.
R. Kevin Oberman
Lawrence Livermore National Laboratory
Internet: oberman@icdc.llnl.gov
(415) 422-6955
Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 2 Mar 91 23:34:07 GMT From: braden@ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Underscores
RFC-1123 (Section 2.1) points you to RFC-952, and then liberalizes the syntax to allow "3COM.COM". Bob Braden
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 91 05:05:53 GMT From: emv@ox.com (Ed Vielmetti) To: comp.protocols.tcp-ip Subject: Re: Underscores
underscores are found in some hostnames managed by merit on behalf of the nsfnet, e.g. ann_arbor.mi.nss.nsf.net, 129.140.17.77. until these names are changed, it's hard to argue that underscores are illegal, just ill-advised. --Ed emv@ox.com please ignore the goofy From: line in the header.
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 91 05:09:18 GMT From: dab@ASYLUM.SF.CA.US (Dave Bridgham) To: comp.protocols.tcp-ip Subject: Registering an "official" port name
If your application is using TCP (as it sounded from your message), may I suggest reading RFC1078 (TCPMUX) for an alternative to using a well known port. David Bridgham
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 91 12:01:01 GMT From: HANK@VM.BIU.AC.IL (Hank Nussbacher) To: comp.protocols.tcp-ip Subject: 3270 Telnet via satellite circuit problems
This past weekend we converted our 9.6kb terrestial link to a 64kb satellite link. I realize the inherent delays of a satellite link. Everything worked except for 3270 Telnet (VM to VM). Linemode Telnet, FTP and SMTP worked fine. But when establishing a 3270 Telnet session, the user would have his/her terminal cleared, and that would be it. Sometimes the remote status area (bottom right hand corner) would appear but never a remote VM logo. We run FAL V.1.2.1 with the BTI Ethernet gateway (Texas line driver) and cisco AGS routers. Any ideas? Will V.1.2.2 solve this problem? Thanks, Hank
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 91 12:22:08 GMT From: efb@suned1.Nswses.Navy.MIL (Everett F Batey) To: comp.protocols.tcp-ip Subject: Re: NetCure and Packet Drivers
What are examples of the component _packed drivers_ upon which to load the many products such as NetCure, in this case .. does the .SYS file that comes with Sun PC-NFS qualify, does some component of ka9q nos or other public access product fill this need ? e.g. for 3C503s ? Thanks. -- + efb@suned1.nswses.Navy.MIL efb@gcpacix.uucp efb@gcpacix.cotdazr.org + + efb@nosc.mil WA6CRE Gold Coast Sun Users Vta-SB-SLO DECUS gnu + + Opinions, MINE, NOT Uncle Sam_s | b-news postmaster xntp dns WAFFLE +
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 91 15:18:48 GMT From: gsb1@forth.stirling.ac.uk (Mr Gordon S Byron) To: comp.protocols.tcp-ip Subject: sending data over citywide cable TV systems
Could you let us have a synopsis of your replies concewrning other sites who are doing this? We are interested in moving in a similar direction in the future and would appreciate any info. thanks ******************************************************************************* Snailmail: Gordon Byron, Arts Computing Advisor,Pathfoot Building, University of Stirling,FK9 4LA Stirling, Scotland, UK. Voice: 0786 73171: Ext 7266 Fax: +78651335 *******************************************************************************
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 91 00:32:52 GMT From: VANCE@TGV.COM (Icarus) To: comp.protocols.tcp-ip Subject: Re: Underscores
>underscores are found in some hostnames managed by merit on behalf of >the nsfnet, e.g. ann_arbor.mi.nss.nsf.net, 129.140.17.77. until these >names are changed, it's hard to argue that underscores are illegal, >just ill-advised. Doing something in broad daylight doesn't make it legal. If we want to expand the allowable characters in host names (which I think is quite reasonable), then let's move on that. RFC 1123 (Host Requirements) explicitly relaxes the restriction of the first character in a host/domain name being a letter (now allows numbers as well), but it does NOT add an underscore to the valid set of characters. Until a change is "officially" made, using underscores in hostnames is a mistake, and can cause problems for some hosts. Regards, -----Stuart
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 91 02:02:24 GMT From: swansonc@acc.stolaf.edu (Chris Swanson DDN:(CDS6)) To: comp.protocols.tcp-ip Subject: Serial line IP packages over a net
Helo out there in netland, I am looking for a way to hook my system into an Internet feed in another town. The simplest method would be to hang a modem off of both machines (mine an Amiga 3000UX and the other site a SparcStation 2) and run SLIP, PPP, or dialupip over a regular phone line between us. There are two problems with this, first the LD charges (same area code, different local telcoms) and second the use of a valuable serial port in the back of the SS2. Another method of accessing the SS2 seems to clean up both of these problems, but I am not sure if one of the serial line ip packages would work over it, some have said that it would and others have said that it wouldn't as part of the connection is itself packetized. Here's the set up. Let's say I am in city A and the SS2 is in city B. There is a terminal server in city A that has modems hanging off of it and can connect to the SS2 in city B over a DECnet or TCP-IP connection (I am not sure which). Here's the question, would any of the serial line ip packages (SLIP, PPP, or dialupip) be able to run over this kind of connection ([mybox]-[modem]-[modem]-[terminal server]-[SS2])? Has anybody done this or know if it could be done or not? On a related note, has anyone run one of the SLIP or like packages over a connection facilitated by a pair of 2400 bps V42.bis (4 to 1 compression) modems (I know - SLOW, but they are cheap and what I have available to me right now.) Please respond via e-mail as I can not always read news. I will share any answers either via e-mail or, if volume dictates, I will post a summary. Thank's in advance, -Chris -- Chris Swanson, Chem/CS/Pre-med Undergrad, St. Olaf College, Northfield,MN 55057 DDN: (CDS6) INTERNET: swansonc@acc.stolaf.edu UUCP: swansonc@stolaf AT&T: Work: (507)-645-6845 Home: (507)-663-6424 I would deny this reality, but that wouldn't pay the bills...
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 91 04:05:15 GMT From: nelson@sun.soe.clarkson.edu (Russ Nelson) To: comp.protocols.tcp-ip Subject: Re: NetCure and Packet Drivers
In article <8218@suned1.Nswses.Navy.MIL> efb@suned1.Nswses.Navy.MIL (Everett F Batey) writes: What are examples of the component _packed drivers_ upon which to load the many products such as NetCure, in this case .. does the .SYS file that comes with Sun PC-NFS qualify, does some component of ka9q nos or other public access product fill this need ? e.g. for 3C503s ? Thanks. "Packet drivers" are those bits of software (usually TSRs, but sometimes actual MS-DOS device drivers) that comply with FTP Software's Packet Driver Specification </anonymous@vax.ftp.com:pub/packet-d.ascii> A number of hardware manufacturers supply their own packet drivers. Clarkson University also distributes a freely copyable collection of packet drivers </anonymous@sun.soe.clarkson.edu:pub/packet-drvers/driverss.zip> with source, or </anonymous@sun.soe.clarkson.edu:pub/packet-drvers/drivers.zip> without source. -- --russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker. It's better to get mugged than to live a life of fear -- Freeman Dyson I joined the League for Programming Freedom, and I hope you'll join too.
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 91 06:31:09 GMT From: jclark@sdcc6.ucsd.edu (John Clark) To: comp.protocols.tcp-ip Subject: RARP implimentations for BSD 4.3 tahoe/reno
The standard BSD 4.3 does not seem to have a 'rarpd' program implimented. Is there a public version of the RARP protocol. Please mail a reply to John Clark jclark@ucsd.edu -- John Clark jclark@ucsd.edu
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 91 10:25:25 GMT From: k2@bl.physik.tu-muenchen.de (Klaus Steinberger) To: comp.protocols.tcp-ip Subject: Time schedule for next InterOP ?
Hi folks, Does somebody know the date for the next InterOP (in San Jose?). I'm just planning a private journey to the west coast, and want to combine it with a visit of InterOP. Sincerely, Klaus Steinberger -- Klaus Steinberger Beschleunigerlabor der TU und LMU Muenchen Phone: (+49 89)3209 4287 Hochschulgelaende FAX: (+49 89)3209 4280 D-8046 Garching, Germany BITNET: K2@DGABLG5P Internet: k2@bl.physik.tu-muenchen.de
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 91 12:46:11 GMT From: rstevens@noao.edu (Rich Stevens) To: comp.protocols.tcp-ip Subject: Re: Time schedule for next InterOP ?
7-11 October, 1991 (San Jose) 18-22 May, 1992 (Washington, DC - new Interop East) 26-30 October, 1992 (San Francisco - SJCC too small)
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 91 13:05:06 GMT From: gt3741b@prism.gatech.EDU (Kikai heno hanashite) To: comp.protocols.tcp-ip Subject: SLIP and Dial-up
I have a question about the "Dial-up Internet Protocol".. namely, does it exist yet, was it ever a serious idea (or just a joke), and if it's not there yet, and is serious.. how far away is it? John -- Emperors Thought for the Day: | John E. Rudd jr. Only the insane have the strength to prosper; | gt3741b@prism.gatech.edu Only those who prosper judge what is sane. | (ex- kzin@ucscb.ucsc.edu) | Speaker to Machines #include<std.disclaim> Send all comments, flames, and complaints to /dev/null.
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 91 16:37:46 GMT From: jaynes@med.umich.edu (William Jaynes) To: comp.protocols.tcp-ip Subject: setting TCP/IP segment size
I've got Sun's running 4.1 and 4.1.1. Is there anyway to configure the maximum packet or segment size. I'd like to limit it to 1024 but they are negotiating for a size of 1460. At 1460, my packets are getting fragmented and under some circumstances this is a problem. At 1024 I can side-step this problem. Any help?
-----------[000037][next][prev][last][first]----------------------------------------------------
Date: 4 Mar 91 16:48:00 GMT
From: MGRJTC@ROSEVC.Rose-Hulman.EDU ("Jerrod T. Carter, Networking Manager")
To: comp.protocols.tcp-ip
Subject: routed problems on a SPARCstationWe are having trouble with routed on a SPARCstation I running SunOS 4.0.3. We have the machine set up as a router between two different networks with two different Ethernet cards. The cards seem to be configured correctly and the machine passes packets between the networks just fine. However, the problem comes in when routed trys to send a rip packet but it is getting a message that says network not reachable. Right now we have another router advertising the route for it, but we'd like to get it to advertise for itself. The network numbers are 137.112.4.0 and 137.112.40.0 with a netmask of 255.255.252.0 and broadcast of 137.112.7.255. Anyone else having these kinds of problems or have any suggestions? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= jerrod t. carter, networking manager | my employer has no opinions rose-hulman institute of technology | mgrjtc@rosevc.rose-hulman.edu | "may all your faults be soft."
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 91 17:33:00 GMT From: TAYBENGH@NUSDISCS.BITNET To: comp.protocols.tcp-ip Subject: Use of SOCK_RAW to implement new transport protocol on top of IP?
Hi netlander,
I would like to use SOCK_RAW provided in BSD socket to implement a new
transport protocol on top of IP. Regretably, the documentation of SOCK_RAW
usage is very scare, it is not clearly discussed in BSD documantation, nor the
two precious books - The design and implementation of 4.3BSD OS (published by
Addsion-Wesley), and Unix Network Programming (published by Prentice-Hall).
As such, I would like to sort for the net experience. The questions are:
1) How one can associate a new protocol (that is not defined in in.h -
socket) to the socket? Specifically, how one can initialize the rcp_proto
field so as to filter packets on input, and also the rcb_pcb field so as to
attach the new protocol-specific information? (note: the rcb_* and raw socket
are discussed in 11.7 of the BSD4.3 book - pg 332)
2) If one cannot filter out the packets on input using the above
method, then if I open a socket using protocol 0 (the default protocol - IP?),
does this socket receive all the packets including TCP, UDP, ICMP, and pure IP
packets? (in fact, I did an experiment on SunOS4.1, I found out the socket
receives only the ICMP packets, not even the pure IP packets, the program
segment are attached as follow, did I did sth wrong?, I also crashed the system
several times when I tried to send out IP packets, is this a bug or I did sth
wrong again?) Moreover, how to initialize the socket so that it can receive all
IP packets in order to extract the newly defined packets?
3) In SunOS4.1, I opened a raw socket with protocol 0 to receive IP
packets using the attached program segment shown below, then when I used ping
(within same host) to ping itself, this program only receive the echo ICMP
messages, but NOT the request ICMP messages. On the other hand, if I ping from
other host to this particular host, the request ICMP messages are also NOT
received by this program. As such it seems that all ICMP request messages are
filtered out by IP layer and thus cannot be received by user process? Is that
true? Morevoer, if I used an connected UDP socket to send message to an
unreachable port within the same host, this program is also able receives the
port unreachable ICMP messages (type=3, code=3). Why is it so? I thought it
should EITHER receive ALL ICMP messages (including echo, request and etc), OR
it should not receive any ICMP messages at all.
4) After looking thru the in.h, I found out there is a IPPROTO_RAW (255)
, should I use this instead of the default 0 in order to receive pure IP
packets? If not, what is the purpose of this protocol?
Could somebody please solve/explain all these puzzles? I am desparated,
please help. Thanks a lot.
==> Here are the receiving part (in C), this part can receive ICMP
message, BUT NOT the pure IP packets sent by the below program.
int sock, socklen;
struct sockaddr_in local_in, remote_in;
char buf[1024], hostname[15], s1[10];
u_short local_port, remote_port;
sock = socket(AF_INET, SOCK_RAW, 0);
if (sock <0)
{
perror("opening datagram socket");
exit(1);
}
for (;;)
{
int i;
long *lp;
socklen = sizeof(remote_in);
/* read from the socket */
if (recvfrom(sock, buf, 1024, 0, &remote_in, &socklen)
< 0)
perror("receiving datagram packets");
lp = (long *)buf;
printf("-->%s\n", buf);
for (i=0; i<12; i++)
printf("x%2.2x: x%8.8x\n", i*sizeof(long), *lp++);
}
close(sock);
===> Here are the sending part (in C), the receving part above never
receive the message sent here, anything worng here? This segment
also crashed the SunOS4.1 many times, error message saying the panic
in m_copy, any clues?
char buf[BUFLEN], remote_host[40], str[40];
int local_port, remote_port, size;
struct sockaddr_in local_sock, remote_sock;
struct hostent *host;
if ((id = socket(AF_INET, SOCK_RAW, 0)) < 0)
syserr("main(): socket()")
/* Get the messages and sendto */
for (;;)
{
printf("\nPls input the messages:\n");
gets(buf);
if (buf[0] == '\n' || buf[0] == '\0')
break;
host = gethostbyname(remote_host);
bcopy(host->h_addr, &remote_sock.sin_addr, host->h_length);
remote_sock.sin_family = AF_INET;
size = sendto(id, buf, sizeof(buf), 0,
(struct sockaddr *)&remote_sock, sizeof(remote_sock));
if (size < 0)
syserr("main(): sendto()")
}
Sorry for the lenghty posting, Thanks in advance for any help.
- Beng Hang (EMAIL: taybengh@nusdiscs.bitnet)
Dept of Information Systems and Computer Science
National University of Singapore
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 91 21:07:25 GMT From: kdb@macaw.intercon.com (Kurt Baumann) To: comp.protocols.tcp-ip Subject: Re: MacTCP
In article <1991Mar01.170733.9543@group1.UUCP>, jim@group1.uucp (Jim Haile) writes: > Path: intercon!uupsi!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!group1!jim > From: jim@group1.uucp (Jim Haile) > Newsgroups: comp.protocols.tcp-ip > Subject: MacTCP > Keywords: MacTCP > Message-ID: <1991Mar01.170733.9543@group1.UUCP> > Date: 1 Mar 91 17:07:33 GMT > Sender: jim@group1.UUCP (Jim Haile) > Organization: Group One, Ltd.; San Francisco > Lines: 12 > > We use MacTCP in an application that gets info from our Unix based > database onto our Macs. It works great now through Ethernet but we > are contemplating adding a 56K line to a remote office and I am > concerned about MacTCP. Will it time out at this slower speed? Has > anyone tried this? > Thanks, > Jim > > -- > Jim Haile > Group One, Ltd. > uunet!group1!jim From my understanding you should not have any problems. I know there is a problem at 9600. I do know that Apple is working on that problem, but we use our product out over the net at 56K without any problems. Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh.
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 91 21:34:30 GMT From: ez@mentor.gandalf.ca (Eugene Zywicki) To: comp.protocols.misc,comp.protocols.tcp-ip Subject: HSSI Standard??
I am looking for information about a proposed standard that I believe is called HSSI (High Speed Serial Interface). Can anyone elaborate further on the background of HSSI, its place in internetworking, and the standards body that is defining it? -- Eugene E. Zywicki CAnet: ez@gandalf.ca Gandalf Data Ltd. Voice: (613) 723-6500 Nepean, Ontario Fax: (613) 226-1717 Canada K2E 7M4
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 91 22:24:50 GMT From: ejm@riscit.NOC.Vitalink.COM (Erik J. Murrey) To: comp.protocols.tcp-ip Subject: Subnet Number 0
I see in RFC950 and the like that the subnet portion of the IP address should not be zero, since it is reserved. This seems to stem from the concept of 0 meaning "this" network; presumably subnet "0" means "this" subnet. (i.e. if we have 128.1.0.0, with a 255.255.255.0 mask, then an address of 128.1.0.x is illegal) Is this still a real restriction on the address space? --- Erik J. Murrey Vitalink Communications NOC ejm@NOC.Vitalink.COM ...!uunet!NOC.Vitalink.COM!ejm
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 91 23:01:27 GMT From: fillmore@emrcan To: comp.protocols.tcp-ip Subject: TCP/IP software for OS/2 ?
Has anyone made a list of available TCP/IP software packages that run under OS/2 and which Ethernet boards they support? I am aware of IBM's product but would like to know what else is available, including public domain software. Thanks in advance.. ________________________ Bob Fillmore, Systems Software & Communications BITNET: FILLMORE@EMRCAN Computer Services Centre, BIX: bfillmore Energy, Mines, & Resources Canada Voice: (613) 992-2832 588 Booth St., Ottawa, Ontario, Canada K1A 0E4 FAX: (613) 996-2953
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 5 Mar 91 14:28:31 GMT From: martin@udac.uu.se (Martin Wendel) To: comp.protocols.tcp-ip Subject: nntpxmit dumps core
I've just compiled and installed NNTP 1.5.8 on a SUN Sparcstation
running SUNOS-4.0.3. It seems like the server works allright but
nntpxmit dumps core when trying to transmit news. I'm using inews
instead and it seems to be working ok.
Does anyone know which one is best, inews or nntpxmit, for posting
and relaying news?
By the way, I run cnews.
--
E-mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC
Domainmaster@UU.SE Martin Wendel
Postmaster@UDAC.UU.SE Box 2103
Tel: 018 - 18 77 80 S-750 02 Uppsala
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 5 Mar 91 14:44:29 GMT From: jcurran@SH.CS.NET (John Curran) To: comp.protocols.tcp-ip Subject: Re: SLIP and Dial-up
-------- > From: Kikai heno hanashite <prism!gt3741b@gatech.edu> > Organization: Georgia Institute of Technology > Subject: SLIP and Dial-up > To: tcp-ip@nic.ddn.mil > I have a question about the "Dial-up Internet Protocol".. > > namely, does it exist yet, was it ever a serious idea (or just > a joke), and if it's not there yet, and is serious.. how far > away is it? "Dialup IP" is real. It is available via ftp from uunet.uu.net and from bbn.com. The software will automatically initiate SLIP connections to remote hosts whenever packets are queued to the dialup IP interface. The package includes a general (mmdf-like?) script language to negotiate and establish connections. There is a mailing list for discussion, send to "dialupip-request@sh.cs.net" for info. Now the surreal part: The software runs under BSD, Ultrix, and 3.x SunOS. It does not run under SunOS 4.x streams (yet). /John
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 5 Mar 91 16:13:28 GMT From: Deb_Kocsis@UM.CC.UMICH.EDU To: comp.protocols.tcp-ip Subject: Seminar Announcement
/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* * * * T h e M e r i t N e t w o r k i n g S e m i n a r s * * * * * * M A K I N G Y O U R N S F N E T C O N N E C T I O N C O U N T * * * * * /*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* Merit/NSFNET Information Services is committed to providing current information on national networking to all users of the NSFNET backbone. Toward this end we will sponsor a two-day seminar in Ann Arbor, Michigan, May 20 and 21. "Making Your NSFNET Connection Count" will be an informative seminar focusing on issues of interest to campus computing leaders, information systems and networking administrators, educational liaisons, librarians, and educators who want to learn more about national networking. Day 1, "Real People Doing Real Things," will feature a number of presentations concerning network applications in education from the elementary grades through the college level. The Day 1 activities will begin with a keynote address by Paul Evans Peters, Director, Coalition for Networked Information and will close with a tour of the Merit Network Operations Center. Day 2, "How to Get Connected and Stay Connected" will provide local, state, mid-level, and national networking perspectives from the experts. Day 2 will also be comprised of presentations on internetworking, information/user services, and network operations. The seminar will be held at the Tenneco Automotive Training and Development Center in Ann Arbor. Microcomputers connected to regional and national networks will be available on-site so that attendees may access network resources discussed in the presentations. The registration fee is $395. An early-bird fee of $345 will be charged for registrations received before April 15, 1991. This fee includes the two-day seminar, a reception on Sunday evening, lunch on Monday and Tuesday, all seminar material, and an optional tour of the Network Operations Center. For further information send an electronic message to seminar@merit.edu or telephone 1-800-66-MERIT.
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 5 Mar 91 16:21:06 GMT From: chrisv@CMC.COM (Chris VandenBerg) To: comp.protocols.tcp-ip Subject: bandwidth usage for X applications?
Good morning all, I tried posting the following question to the X windows interest group but received NO responses. So I'm going to give it a go here on TCP, since most of you ARE concerned with bandwidth usage for applications, etc. QUESTION - Does anyone have a feel for rough bandwidth usage for some of the "typical" (if there is such a thing) X client applications? Has anyone run any benchmarks which included X sessions across the net? It can't be too difficult to fill up an Ethernet VERY quickly running clients to a few servers doing CAD or something. If you have some applications that can eat up an Ethernet let me know, we're actively looking for good app's to highlight the need for FDDI at Interop this year. Many thanks, Chris VandenBerg CMC A Rockwell Co. chrisv@cmc.com 805-562-3127
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 5 Mar 91 18:12:17 GMT From: jonson@SERVER.AF.MIL (Lt. Matt Jonson) To: comp.protocols.tcp-ip Subject: Re: Subnet Number 0
<Erik J. Murrey writes> > Subject: Subnet Number 0 > Message-Id: <1423@nocsun.NOC.Vitalink.COM> > > I see in RFC950 and the like that the subnet portion of the IP address > should not be zero, since it is reserved. This seems to stem from the > concept of 0 meaning "this" network; presumably subnet "0" means > "this" subnet. (i.e. if we have 128.1.0.0, with a 255.255.255.0 mask, > then an address of 128.1.0.x is illegal) > Absolutely. Take a look at RFC 1122, section 3.2.1.3. There are some caveats for using such addresses in IP address discovery routines. /matt -- Lt Matthew W Jonson jonson@server.af.mil snail-mail: Network Systems Engineer 205-279-4075 SSC/SSMT USAF DDN Program Office AV: 596-4075 Gunter AFB, AL 36114
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 5 Mar 91 18:28:35 GMT From: mark@TELESYS.NCSC.NAVY.MIL (Mark L. Williams) To: comp.protocols.tcp-ip Subject: Re: Time server (Internet-style); anyone got freely distributable source?
UNIX Review, Vol 8 No 12 says, in the Daemons and Dragons column, that RFC 1129 covers Network Time Protocols. The article describes the time service reasonably clearly, I think. According to the author, he/they use xntpd "written by Dennis Ferguson at the University of Toronto." "To obtain the xntp implementation of the NTP protocol, use anonymous ftp to louie.udel.edu and look in the directory ~ftp/pub/ntp/xntp. The distribution consists of a 49 KB compressed tar archive. The distribution takes approximately 10 minutes to build on a Sparcstation 1." [typos, if any, are mine] Author of the article was Rob Kolstad, who acknowledges help from Jeff Polk. Mark
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 5 Mar 91 18:30:19 GMT From: jonson@SERVER.AF.MIL (Lt. Matt Jonson) To: comp.protocols.tcp-ip Subject: Re: Looking for mil spec archive
<J B Systems writes> > > I have received a spec which references MS 1777 (IP) and MS 1778 (TCP). > I have the rfc's to tcp and ip, but where can I find an archive for the > mil standards? Any help would be welcome. > The Mil-Stds can be gotten as publication NIC 5004 - "DDN Protocol Handbook, Vol 1" from DDN Network Information Center, SRI International, Menlo Park, CA, 94025. It was put together in 1985. They can also be requested from the Naval Publications and Forms Center (NPFC) (individually, by name) which is : Naval Publications and Forms Center Code 3015 5801 Tabor Drive Philadelphia, PA 19120 The Mil-Stds in question date back to 1983. I know that there are still military acquisitions that reference those particular specs, but to be really interoperable, vendors should be referencing RFC 1122 & RFC 1123 and using them as their criteria. Any military acquisition authority that doesn't invoke 1122 & 1123 is seriously behind the times. Some people still come up with their specs in a virtual vacuum, however... The catch-22 disclaimer of course: The opinions above are my own and do not represent official views of the U.S. Government. (maybe the opinions are catching on... :-) /matt -- Lt Matthew W Jonson jonson@server.af.mil snail-mail: Network Systems Engineer 205-279-4075 SSC/SSMT USAF DDN Program Office AV: 596-4075 Gunter AFB, AL 36114
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 5 Mar 91 18:48:42 GMT From: tksjmi@sybil.cs.Buffalo.EDU (JoAnn Illuzzi) To: comp.protocols.tcp-ip Subject: mac to mac ftp with NCSA Telnet 2.3?
I posted this question to telnet@ncsa.uiuc.edu on 1/22, but apparently that is a dead list, I didn't receive any replies. Does Mac NCSA Telnet support mac to mac ftps directly? I don't want to sign onto a mainframe/mini to ftp stuff between two macs. I thought ncsa telnet 2.3 had this feature, but I don't see it documented. JoAnn
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 5 Mar 91 19:32:23 GMT From: jclark@sdcc6.ucsd.edu (John Clark) To: comp.protocols.tcp-ip Subject: Re: CWRU student prevented from teaching how to send ethernet packets
In article <1991Feb27.144731.23147@usenet.ins.cwru.edu> cjs@po.CWRU.Edu (Christopher J. Seline) writes: + +I wrote a program that puts packets on ethernet and takes responce packets +off; the idea that my (or any) program could be modified to send n+1 packets +(swamping our 100M FDDI fiber backbone) scared them; my program didn't do +that -- but it (And any other program) could be modified to do so. What is so special about such a program. Most intro texts on tcp inplementation have examples of this. Clearly just writing a piece of code which talks to various 'echo' services could do the 'swamping'. Big deal. Of course if you have a way to bring down the net maybe you should post an article stating the hole in argument that says access to the net will resonably likely for all users. -- John Clark jclark@ucsd.edu
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 5 Mar 91 20:39:32 GMT From: ash@omega.UUCP (Andrew Hardie) To: comp.protocols.tcp-ip Subject: DS8390 chip problems
Message posted to net in case strange NZ mail address doesn't work! Geoff Pack, DSIR, New Zealand Yes, please to the details on the problems with the B version of the DS8390 chip. Thanks. Email to ash@omega.uucp or ...!ukc!cctal!andrew, whichever is easier. Will acknowledge receipt. If anyone else on list is interested, please contact me and I will pass it on or post it to the net, depending on interest. Andrew -- +----------------------------------------------------------------------------+ | Andrew Hardie ash@omega.uucp | | London, England ukc!cctal!omega!ash | +----------------------------------------------------------------------------+
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 5 Mar 91 22:19:14 GMT From: swansonc@acc.stolaf.edu (Chris Swanson) To: comp.protocols.tcp-ip Subject: Re: Serial line IP packages over a net
Well here is the followup I said I would post. It seems that, using a "plain, no frills" terminal server, you are out of luck, however there are terminal servers that do support SLIP (some even support PPP). With these servers, you connect to the server as a regular session and then do the commands to start SLIP (something like "set terminal internet slip enable") and go back and start your SLIP connection without dropping the line. With these servers (Xyplex, Cisco, and some others) you do not even need to continue your SLIP link to a "gateway" machine. The server, in fact, acts like a slow router. Once you are SLIP'd to the terminal server, that is on the desired network, you are connected and _shuldn't_ need to do anything else then set up some nameservers if needed. There has been concern expressed about running a SLIP connection with a lot of high-density trafic over a terminal server as possibly being detrimental to throughput for other users. My application will be a very low density connection, however. Any more comments or questions are wlcome. Thank's again, -Chris -- Chris Swanson, Chem/CS/Pre-med Undergrad, St. Olaf College, Northfield,MN 55057 DDN: (CDS6) INTERNET: swansonc@acc.stolaf.edu UUCP: swansonc@stolaf AT&T: Work: (507)-645-6845 Home: (507)-663-6424 I would deny this reality, but that wouldn't pay the bills...
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: 5 Mar 91 23:39:10 GMT From: BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) To: comp.protocols.tcp-ip Subject: Re: Serial line IP packages over a net
Here's the set up. Let's say I am in city A and the SS2 is in city B.
There is a terminal server in city A that has modems hanging off of it
and can connect to the SS2 in city B over a DECnet or TCP-IP
connection (I am not sure which). Here's the question, would any of
the serial line ip packages (SLIP, PPP, or dialupip) be able to run
over this kind of connection ([mybox]-[modem]-[modem]-[terminal
server]-[SS2])?
A good number of todays terminal servers support SLIP directly. Some
even support PPP. This would solve your problem more convieniently.
Bill Westfield
cisco Systems.
-------
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 91 00:09:34 GMT From: steve@edm.isac.CA (Steve Hole) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: POP2/3, IMAP2/3
This is almost certainly an FAQ, but I have yet to see a collection of
definitive answers posted to either of these groups. What I would like
is information on the following items:
* POP2/3 server for UNIX, clients for UNIX and DOS.
* IMAP2/3 server for UNIX, clients for UNIX and DOS.
I don't really care too much about the flavor of UNIX or of the DOS
TCP/IP libraries that it is implemented for, as I can probably muddle
through that if I have too. Summary information on the software and a
list of ftp sites would be appreciated for each. I will be happy to
post a summary back to the group for those who wish it.
--
Steve Hole mail: steve@edm.isac.ca
ISA Corp. uucp: !{uunet, alberta}!ncc!isagate!steve
Edmonton, Alberta, Canada phone: (403) 441-4121
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 91 01:41:02 GMT From: keith@ca.excelan.com (Keith Brown) To: comp.protocols.tcp-ip Subject: Re: Need: Enhanced FTP
The News Manager) Nntp-Posting-Host: ca Reply-To: keith@ca.excelan.com (Keith Brown) Organization: Novell, Inc. San Jose, California References: <867@nddsun1.sps.mot.com> Date: Thu, 28 Feb 1991 23:19:18 GMT In article <867@nddsun1.sps.mot.com> wied@birdie.sps.mot.com (Bill Wied) writes: >I'm looking for an enhanced version of FTP which will create virtual connections between hosts that are not directly connected, possibly using routing table information on in between hosts. > FTP clients should never find themselves in a configuration where they have to worry about such matters. Interhost routing is the job of IP which sits a few layers below FTP. When an FTP client wishes to connect to a host that is not directly on its own IP network, IP will carry it's connection request across an IP internet to the IP network on which the remote host lives (on a good day). >The control connection probably needs to be some virtual pipe but the data connection can either create a virtual connection or use some kind of store and forward mechanism to route it's data to the desired host. > The only example of data and control connection "juggling" that I'm aware of is in FTP clients that support what I'm in the habit of calling "third party copies". The idea is that you can sit at Machine A and use FTP to transfer a file from Machine B to Machine C without the data ever darkening Machine As doorstep. We support this in both our Windows 3.0 based FTP client and also our non-Windows FTP client in the LAN Workplace for DOS. I'm not sure if FTP softwares client can do this too but it wouldn't surprise me (2.04 couldn't, right James?). Also, the University of Marylands TCP/IP implementation looks pretty complete, so perhaps that can do it too? Keith - Keith Brown Phone: (408) 473 8308 Novell San Jose Development Centre Fax: (408) 433 0775 2180 Fortune Dr, San Jose, California 95131 Net: keith@novell.COM
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 91 01:41:31 GMT From: brian@na.excelan.com (Brian Meek) To: comp.os.os2.misc,comp.os.os2.programmer,comp.protocols.tcp-ip Subject: Re: Looking for OS/2 TCP/IP products with RFC 1001/1002
The News Manager)
Nntp-Posting-Host: na
Reply-To: brian@novell.com (Brian Meek)
Organization: Novell, Inc. - San Jose, California
References: <4432@se-sd.SanDiego.NCR.COM> <1331@vaxeline.COM>
Date: Sat, 2 Mar 1991 08:44:57 GMT
In article <1331@vaxeline.COM> backman@vaxeline.ftp.com.UUCP (Larry Backman) writes:
[...]
>FTP Software V1.1 (in beta right now) supports RFC 1001/2 NETBIOS
>3Com's 3+TCP for LAN Mgr supports RFC 1001/2 Netbios. It has been
>shipping for a while.
>IBM TCP/IP for OS/2 V1.1 does not to my knowledge support Netbios.
>Ungermann-Bass is rumored to have an OS/2 TCP Netbios. I have not seen it.
>Excelan (now Novell) once shipped LAN Workplace for OS/2 w/ TCP & Netbios.
>I have no idea if it still is shipping.
The LAN WorkPlace for OS/2 is no more dead than OS/2 itself... hmmm.
Version 2.0 of LWP for OS/2 is a remnant of our LAN Manager developments
before we started focusing on NetWare and merged with Novell. The next
release of the product (v3.0) is nearly ready for BETA testing and includes
a redesigned TCP/IP module.
The v3.0 release works in conjunction with the NetWare Resquestor for
OS/2 using a single adapter. Ethernet, Token-Ring and ARCNET cards with
ODI for OS/2 drivers can be used. RFC-NETBIOS is there, so are all of the
basic service applications and a good BSD 4.3 Socket Library.
Those interested in BETA testing should send a note to me describing your
need for TCP/IP on OS/2 (Toolkit or end-user, for example...) and be sure
to include a mailing address and a FAX number.
PS - the recently announced LWP for DOS is not available for BETA testing
as it will be shipping in April.
-- brian
____________________________________________________________________________
Brian Meek Novell, Inc. - 2180 Fortune Dr. San Jose, CA 95131
Internet Mail: brian@novell.COM Phone: (408) 473-8375
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 91 01:43:27 GMT From: stu@gtisqr.uucp (Stu Donaldson) To: comp.unix.sysv386,comp.protocols.tcp-ip Subject: Re: Help with Anonymous FTP
In article <1991Feb21.211534.772@ulkyvx.bitnet> rwmira01@ulkyvx.bitnet (Rob Miracle) writes: >"If the username is "anonymous" or "ftp" and an "anonymous" account is present >if /etc/passwd, the user is allowed to log in by specifying any password. Since >anyone can log in under "anonymous," it is wise to restrict the access >privileges of this account." I used the account 'ftp' since it wouldn't have the problem. With this, both 'anonymous' and 'ftp' work as logins. >anonymous account and add an account called ftp. Now I can log in, but any >access other than CD barfs with a message: > >PORT 136,165,2,12,8,17 >200 PORT command okay >NLST >425 Data Socket not created [0.0.0.0,0] I had the same problem. It doesn't tell you that there are a few other files thatyou need to have in the ~ftp account. ~ftp/bin ls needed for the NLST or LIST commands in ftp to work. pwd needed to get the current working directory ~ftp/dev null tcp # needed so the socket call within ftp can work. udp # probably not needed, but I added it when I added tcp ~ftp/etc group # needed for group id to show up in the dir command. passwd # needed for login id to show up in the dir commadn. ~ftp/shlib libc_s # surprise, /bin/ls uses the shared library so this # is requried. shlib: total 54 -rwxr-xr-x 1 root other 26236 Feb 27 10:47 libc_s* >Problem #2 It seems that the CD command can get anywhere on the system. How >do I restrict it to just the tree that I want it in? ftpd will automatically do a chroot to the new directory, thus preventing you from using CD to get to directories above ~ftp. >Thanks in Advance >Rob >-- >Rob Miracle | Bitnet : RWMIRA01@ULKYVX CIS: 74216,3134 >Programmer/Analyst-II | INTERNET : rwmira01%ulkyvx.bitnet@cunyvm.cuny.edu >University of Louisville | UUCP : ...psuvax1!ulkyvx.bitnet!rwmira01 >"Revenge is a dish best served cold. It is very cold in space" > -- Ancient Klingon Proverb ----------------------------------------------------------------------- Stu Donaldson "Can't you understand what I'm saying?" stu@mav.com "What did you do, fail telepathy?"
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 91 01:46:09 GMT From: stu@gtisqr.uucp (Stu Donaldson) To: comp.unix.sysv386,comp.protocols.tcp-ip Subject: Re: Help with Anonymous FTP
In article <1991Feb21.211534.772@ulkyvx.bitnet> rwmira01@ulkyvx.bitnet (Rob Miracle) writes: >Problem #1, AT&T SVR3.2.2 only allows 8 character file names, thus "anonymous" >can not be created. By hand editing /etc/passwd and /etc/shadow, I added the >account as: anonymous:x:1000:100:FTP Anonymous Account: I used the account 'ftp' since it wouldn't have the problem. With this, both 'anonymous' and 'ftp' work as logins. >anonymous account and add an account called ftp. Now I can log in, but any >access other than CD barfs with a message: > >PORT 136,165,2,12,8,17 >200 PORT command okay >NLST >425 Data Socket not created [0.0.0.0,0] I had the same problem. It doesn't tell you that there are a few other files thatyou need to have in the ~ftp account. ~ftp/bin ls needed for the NLST or LIST commands in ftp to work. pwd needed to get the current working directory ~ftp/dev null tcp # needed so the socket call within ftp can work. udp # probably not needed, but I added it when I added tcp ~ftp/etc group # needed for group id to show up in the dir command. passwd # needed for login id to show up in the dir commadn. ~ftp/shlib libc_s # surprise, /bin/ls uses the shared library so this # is requried. shlib: total 54 -rwxr-xr-x 1 root other 26236 Feb 27 10:47 libc_s* >Problem #2 It seems that the CD command can get anywhere on the system. How >do I restrict it to just the tree that I want it in? ftpd will automatically do a chroot to the new directory, thus preventing you from using CD to get to directories above ~ftp. >Thanks in Advance >Rob >-- >Rob Miracle | Bitnet : RWMIRA01@ULKYVX CIS: 74216,3134 >Programmer/Analyst-II | INTERNET : rwmira01%ulkyvx.bitnet@cunyvm.cuny.edu >University of Louisville | UUCP : ...psuvax1!ulkyvx.bitnet!rwmira01 >"Revenge is a dish best served cold. It is very cold in space" > -- Ancient Klingon Proverb ----------------------------------------------------------------------- Stu Donaldson "Can't you understand what I'm saying?" stu@mav.com "What did you do, fail telepathy?"
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 91 01:48:41 GMT From: stu@gtisqr.uucp (Stu Donaldson) To: comp.unix.sysv386,comp.protocols.tcp-ip Subject: Re: Help with Anonymous FTP
In article <1991Feb21.211534.772@ulkyvx.bitnet> rwmira01@ulkyvx.bitnet (Rob Miracle) writes: >Problem #1, AT&T SVR3.2.2 only allows 8 character file names, thus "anonymous" >can not be created. By hand editing /etc/passwd and /etc/shadow, I added the >account as: anonymous:x:1000:100:FTP Anonymous Account: I used the account 'ftp' since it wouldn't have the problem. With this, both 'anonymous' and 'ftp' work as logins. >anonymous account and add an account called ftp. Now I can log in, but any >access other than CD barfs with a message: > >PORT 136,165,2,12,8,17 >200 PORT command okay >NLST >425 Data Socket not created [0.0.0.0,0] I had the same problem. It doesn't tell you that there are a few other files thatyou need to have in the ~ftp account. This is for Interactive Systems 2.0.2, your mileage may vary. ~ftp/bin ls needed for the NLST or LIST commands in ftp to work. pwd needed to get the current working directory ~ftp/dev null # may not be needed, but I added it while trying to fix # the problem. tcp # needed so the socket call within ftp can work. udp # probably not needed, but I added it when I added tcp Note that these files in the ~ftp/dev directory will need to be actual devices. Therefore, you will need to either link to the real /dev/* files, or use mknod to create them. ~ftp/etc group # needed for group id to show up in the dir command. passwd # needed for login id to show up in the dir commadn. ~ftp/shlib libc_s # surprise, /bin/ls uses the shared library so this # is requried. >Problem #2 It seems that the CD command can get anywhere on the system. How >do I restrict it to just the tree that I want it in? ftpd will automatically do a chroot to the new directory, thus preventing you from using CD to get to directories above ~ftp. >Thanks in Advance >Rob >-- >Rob Miracle | Bitnet : RWMIRA01@ULKYVX CIS: 74216,3134 >Programmer/Analyst-II | INTERNET : rwmira01%ulkyvx.bitnet@cunyvm.cuny.edu >University of Louisville | UUCP : ...psuvax1!ulkyvx.bitnet!rwmira01 >"Revenge is a dish best served cold. It is very cold in space" > -- Ancient Klingon Proverb ----------------------------------------------------------------------- Stu Donaldson "Can't you understand what I'm saying?" stu@mav.com "What did you do, fail telepathy?"
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 91 01:54:35 GMT From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) To: comp.protocols.tcp-ip Subject: Re: Looking for mil spec archive
Matt: > <J B Systems writes> > > I have received a spec which references MS 1777 (IP) and MS 1778 (TCP). > > I have the rfc's to tcp and ip, but where can I find an archive for the > > mil standards? Any help would be welcome. > I know that there are still military acquisitions that reference those > particular specs, but to be really interoperable, vendors should be referencing > RFC 1122 & RFC 1123 and using them as their criteria. Any military acquisition > authority that doesn't invoke 1122 & 1123 is seriously behind the times. > Some people still come up with their specs in a virtual vacuum, however... ...now what was the name of that Gunter AFB program--had something to do with LANs, PCs, etc.--it was supposed to become the Air Force standard based on MIL-STD-1777 and MIL-STD-1778 ? ;-) Some of the newer RFPs still contain references to the MIL-STDs but suggest that the vendor read them, primarily, for hysterical reasons. Merton
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 91 04:54:18 GMT From: bvj@ESD.3Com.COM (B.V. Jagadeesh) To: comp.protocols.tcp-ip Subject: Silicon Vallaey Networking Conference - Advance Program
Hi -
The Technical Committee of SVNC - 91 ( Silicon Valley Networking
conference ) has put together an excellent technical program
with papers from Universities from USA and Europe, Leading Networking
companies and Research Institutes from different parts of the
world. A preliminary conference program is attached for your
reference.
SVNC also offers one day tutorial on FDDI and X- Motif
SVNC-91 aims to cover technical papers in the following areas
1. Internetworking
2. High Speed Networking
3. X - Windows
4. Network Management
5. Distributed Systems
6. Physical layer
7. Networking Applications
8. Network Test Equipments
If you have any questions about this conference please
do not hesitate to contact me.
The conference will be held from April 23rd - 25th at Santa Clara
Convention Center, Santa Clara, CA - 95052
Registration form is attached at the end of this mail which can
be used for registering in the conference.
Thanks
/B.V. Jagadeesh
Chairman - Technical Committee
bvj@ESD.3Com.com
(408)-764-5169
Silicon Valley Networking Conference 1991 - Advance Program
------------------------------------------------------------
Conference Dates: April 23rd to 25th 1991
Place : Santa-Clara Convention Center,
Santa-Clara, CA - 95052
USA.
DAY 1 April 23, 1991 TUTORIALS
----------------------------------------------------------------------
| Track 1 | Track 2
----------------------------------------------------------------------
8:30 AM | Introduction to X-Motif | Introduction to FDDI
to | Richard Lasslo | Mark Wolter
5:00 PM | Hewlett Packard Company | National Semiconductor
----------------------------------------------------------------------
12:00 NOON Lunch Break
----------------------------------------------------------------------
*******************************************************************************
DAY 2 April 24, 1991 TECHNICAL PAPER TRACKS
---------------------------------------------------------------------
KEYNOTE SPEAKER: Current and future trends in network management.
Keith McCloghrie, Hughes LAN Systems 8:30 - 9:00
---------------------------------------------------------------------
Track 1 | Track 2
---------------------------------------------------------------------
Session: NETWORK MANAGEMENT | Session: PHYSICAL LAYER - I
---------------------------------------------------------------------
1. John Pickens, 3COM | 1. Dave Wong, Level One Comm
Open Management Architecture | Understanding Twisted Pair
Making network management | Ethernet
manageable. |
|
2. Arminius Mignea, Hughes LAN Systems| 2. William.V.Ringer, Intel
A methodology for configuring | Notebook PC Network
large networking. | Interface card.
|
3. Joe Grim, Hewlett Packard | 3. Peter Sun, PLX
The SNMP protocol | A non-buffered architecture
| for Ethernet LAN
| controllers.
|
| 4. Paul Singh, Intellicom
| 10Base/T based Ethernet Networks
----------------------------------------------------------------------
COFFEE BREAK + Discussion with Speakers
----------------------------------------------------------------------
Session: INTERNETWORKING | Session: Physical Layer - II
|
4. Kai Jacobs, Tech. Univ. of Aachen | 5. Mike Seibert, MICRON
Point to multipoint communication.| Use of triple port DRAM for
| smart/faster network app.
|
5. Joachim Carlo, Clearpoint | 6. Greg Wolfson, Intel
Analysis of the effects of high | LAN connection for
speed bridges on network | advanced controller micro
performance | controller platform.
6. Brian Lloyd, Telebit | 7. Donna Weaver, Standard
| Microsystems Corp.
IP routing over public switched |
networks. | Advanced silicon for the
| networking of controller
7 Vinod Bhardwaj, Kalpana Inc. | based systems.
Parallel Networking |
|
----------------------------------------------------------------------
LUNCH + Exhibits
----------------------------------------------------------------------
Session: X-Window | Session: NETWORK TEST EQUIPMENT
|
8. V.R. Ranganath and | 8. Jay Weill, Network General
Phil Bourkekas | Network troubleshooting
RISC Controllers - An Architecture| analysis and trends and
well suited for X - Windows | issues.
|
9. Dale Luck, Gfx Base Inc. | 9. Jay Seaton, Spider Sys.
X Window System for Amiga Computer| Monitoring and Managing
| LANs.
|
10. Jim Fulton, NCD | 10. Daniel Bougher, Tektronix
Making fonts more manageable. | LAN Map Local Area Network
| conduit troubleshooting.
----------------------------------------------------------------------
COFFEE BREAK + Discussion with Speakers
---------------------------------------------------------------------
Session: X-Window | Session: HIGHSPEED NETWORKING
|
11. Mark Brown, GRAPHON | 11. Yigal Jacoby, Tekelec
Advantages of an advanced X-Term | FDDI Network testing.
design. |
|
12. Kevin Herbert, CISCO | 12. Sanjay Dhavan, AMD
X-remote and terminal server | FDDI Interoperability
solutions to needing an X-window.| testing.
|
13. Panel Discussion | 13. Sonu Mirchandani, Business
| Networks Group
| Performance Isuues in FDDI
| LANs
|
| 14. My T Le, Plus Logic.
| FDDI - Traffic Controller
----------------------------------------------------------------------
DAY 3 April 25, 1991 TECHNICAL PAPER TRACKS
----------------------------------------------------------------------
KEYNOTE SPEAKER: Bruce Nelson, Auspex Systems 8:30 - 9:00
----------------------------------------------------------------------
Track 1 | Track 2
----------------------------------------------------------------------
Session: Highspeed Networking | Session: Distributed Systems
|
14. George Marshall, Adaptive | 15. Jeff Eppinger, Transarc
| Corp
Impact of telecommunications and | Transactional remote
highspeed networking. | procedure calls.
|
15. Jaffar Rehman, U of Penn | 16. S. Gopisetty
Using detailed traffic | Santa Clara University
statistics for more effective | A client-Agent-Server Model
wideband multiplexing. | for Distributed Processing
| environment
|
16. Alan Taffel, US Sprint | 17. Peter Taid, Peer Logic
Frame Relay an overview of | Peer-to-peer computing for
networking technology. | distributed environment.
|
17. Tom Dugan, Vitesse Semiconductor |
Sonet on Silicon |
----------------------------------------------------------------------
BREAK 10:35 - 11:15 AM
----------------------------------------------------------------------
Session: Highspeed Networking | Session: Distributed Systems
|
18. Brian Button, Stratacom | 18. Michel Besson, Cerics
Frame Relay its concepts and | A protocol for interactive
implications | remote programming in
| heterogenous implementation
| and performance.
|
19. Raj Pari, National Semiconductor | 19. Harold Rabie, Echelon
ISDN Basic access components and | Distributed Processing using
design of ISDN peripherals. | Local Operating Network
|
20. Tom Russel, Ultranet | 20. OSF Distributed Management
System Issues in Gigabit/s | Environment
Networking | David Schwab - Hewlett Packaret
----------------------------------------------------------------------
LUNCH 12:05 - 2:00PM
----------------------------------------------------------------------
Session: Internetworking II | Session: Physical Layer II
|
21. Karen Parker, National Semi | 21. Ed D'Souza, National Semi
Designing and Ethernet for FDDI | Parallel architecture for
router. | maximized throughput in
| star-wired topologies.
|
22. R. Spurk, Dept. of Computer | 22. Daniel Pettengil, Intel
Science, Univ. of Saarbruken | Bus mastering for LAN
Router support for multicasting in | adapters.
multicomputer interconnection |
network. |
|
23. Jim Forster, Cisco Systems | 23. Mike Yep, National Semi
Comparison of metrics in todays | Design of FDDI concentrator
routing protocols. |
|
24. Milo Medin, NASA | 24. Dick Allen, Photonics
OSPF Routing protocol | Non-cable connectivity
| alternatives in design
| and implementation of
| networks.
----------------------------------------------------------------------
BREAK 3:15 - 3:45 PM
----------------------------------------------------------------------
Session: Network Management II | Session: Network Applications
|
| 25. Paul Flaherty, Stanford University
| A Fast Open Systems Interconnection
| Protocol System
|
25. Bob Stewart, Xyplex | 26. Manoj Goel, Novell
Development and integration of MIB | Integration of electronic
| mail messages.
|
26. Fred Baker, ACC | 27. T. Casey, Dept. of CS
SNMP experimental bridge MIB | Univ. College of LONDON
development. | U.K.
| A Hybrid network image
| server.
|
27. Larry Lace, Network Research | 28. Bala Parasuram, Syscom
Heterogenous networking | Fascimile outsource a
considerations when using SNMP | resource saving
agents and network management | alternatives to
devices. | in-house.
|
28. Tin Phan & Dean K. Endo, Touch Comm| 29. Bob Jacobson, U of
An object oriented agent | Washington
architecture | Virtual world paradigm
| and televirtuality
| implications for network
| design capabilities.
|
29. Jochen Seitz, Institute of Tele - | 30. Norm Schneidwind, Navel
matics, Univ of Karlaruhe, FRG | PG School
An architecture for an Expert | Issues in allocating
system Aiding in Network Planning | servers and files in LAN.
and Network Management |
| 31. Daniel PattenGill
| Banyan Systems Inc
| Directory Services and Street Talk
---------------------------------------------------------------------
A three Day package is $295 and a two day package is $245.
For more info on registration please call B.V. Jagadeesh at (408)-764-5169
or send email to bvj@ESD.3Com.com or majithia@calstate.bitnet
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 91 07:58:00 GMT From: tb@Materna.DE (Torsten Beyer) To: comp.protocols.tcp-ip Subject: RFC 1078
Hi Everybody, Recently I stumbled across RFC 1078. I have never seen this implemented, but maybe I'd like to use it. Before I start doing it myself, has anybody else already done it or is awar of an implementation ? ciao -Torsten -- Torsten Beyer e-mail : tb@Materna.DE Dr. Materna GmbH VOX : +49 231 5599 225 Vosskuhle 37 FAX : +49 231 5599 100 D-4600 Dortmund 1, West Germany
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 91 08:54:04 GMT From: efb@suned1.Nswses.Navy.MIL (Everett F Batey) To: comp.protocols.tcp-ip Subject: Sun 4c (SLC) OS 4.1.1 and SLIP packages
Have TWO questions. (1) Do you have any version of public SLIP running on a Sun4c architecture under SunOS 4.1.1 ( minimal kernel config files and all ) ? (2) If YES to (1), what SLIP packages have you integrated / which ONE have you used ON THIS CONFIG ( sun4c with SunOS 4.1.1 ) ? PLEASE, save the bandwidth, I am willing to do PPP .. BUT the neighboring BSD-Tahoe VAX IS NOT configured and that cant be done for several months .. I know .. PPP is the right answer .. been flamed many times already .. Thnx -- + efb@suned1.nswses.Navy.MIL efb@gcpacix.uucp efb@gcpacix.cotdazr.org + + efb@nosc.mil WA6CRE Gold Coast Sun Users Vta-SB-SLO DECUS gnu + + Opinions, MINE, NOT Uncle Sam_s | b-news postmaster xntp dns WAFFLE +
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 91 08:59:33 GMT From: romkey@ASYLUM.SF.CA.US (John Romkey) To: comp.protocols.tcp-ip Subject: TCP/IP via Token Ring
Yes, a number of companies support TCP/IP over token ring. I think you'll find most of the PC vendors do; in fact, there's even a token ring packet driver. Some of the router vendors, like Proteon, cisco and probably Wellfleet do as well. Whether non-router and non-PC vendors support IP over token ring is as problematic as finding a token ring card for something that's not a PC... RFC 1042 will do the trick. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us FAX: 415 594-1141
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 91 14:39:08 GMT From: tmallory@BBN.COM To: comp.protocols.tcp-ip Subject: Re: bandwidth usage for X applications?
Chris, While not very sexy, performing file system backups over the net is a necessary and bandwidth hungry application. Our corporate communications folks are concerned that an FDDI backbone might be not be enough to get all remote systems backed up to come central site in the not too far distant future. You might consider loading up 50% of the ring with this sort of traffic, and then run some of the apps that other people will be suggesting. Tracy
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 91 15:27:43 GMT From: wied@birdie.sps.mot.com (Bill Wied) To: comp.protocols.tcp-ip Subject: Re: Need: Enhanced FTP
There seems to be some confusion over this request I posetd earlier. I realize that the IP layer is responsible for routing. But sometimes two networks are seperated by "firewall" machines for security measures (ie. a firewall between a business network and Internet). Thus to log on to an Internet machine from the business side you must first log on to the firewall machine. This keeps the Internet machine directly off your business network, while still allowing you to get access to it. I'm looking for an e nhanced FTP which will "bridge" this firewall. To make data retrival a one-step process. Please mail replys directly to me and do not post them. This just clutters the newsgroup. Thanks
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 91 16:03:46 GMT From: DAVID@wcc.govt.nz (David Richards) To: comp.protocols.tcp-ip Subject: Wollongong TCP/IP for VAX/VMS List
Does anybody known if there is a list for the Wollongong TCP/IP for VAX/VMS? David Richards. PS. Please reply to david@ccc.govt.nz, my return is incorrect. Thanks.
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 91 17:26:33 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: TCP/IP software for OS/2 ?
Has anyone made a list of available TCP/IP software packages that run
under OS/2 and which Ethernet boards they support?
IBM, FTP Software, Essex Systems, 3Com, and Ungermann-Bass all use the NDIS
software driver interface standard, and so can run on any network card for
which an OS/2 NDIS driver can be obtained (ask the vendor - it's required by
LAN Manager, but Netware uses ODI, which is different). Most, if not all of
these can use either Ethernet or 802.5 NDIS drivers. Interlan's offering
requires their intelligent Ethernet adapter. Novell (Excelan)'s may use NDIS,
or it may use ODI, or it may require their intelligent adapter; I'm not sure.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 91 18:11:31 GMT From: pks%netearth@SHAKTI.ERNET.IN To: comp.protocols.tcp-ip Subject: Request for x.25 addresses ...
Dear Sir,
I am interested in knowing some locations which are running x.25
over tcp/ip?
It'll be very kind of you if you can send me list of such locations.
Thanking you.
Praveen
*==========================================================================*
!
|||||||||| ! PRAVEEN KANT SHARMA
|| ||| !
|| ||| ! Educational & Reseach Network Project
|||||||||| ! Dept. of CS&E
|| ! Indian Institute of Technology, Delhi
|| !
|| ! 686-7431, Fax: 686-8765
|| ! pks%netearth@shakti.ernet.in
!
*==========================================================================*
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 91 19:45:30 GMT From: smithfd@weiss.cs.unc.edu (Don Smith) To: comp.protocols.tcp-ip Subject: TriComm'91 Announcement and Advance Registraton
ANNOUNCEMENT and ADVANCE REGISTRATION
TriComm'91
IEEE CONFERENCE ON COMMUNICATIONS SOFTWARE:
COMMUNICATIONS FOR DISTRIBUTED APPLICATIONS AND SYSTEMS
Chapel Hill, NC April 18-19, 1991 (Registration & Reception April 17, 6 pm)
An International Conference Sponsored by the IEEE Communication Society,
the University of North Carolina at Chapel Hill, and MCNC
The decade of the 1980s was a period of rapid advances in communications
technology (both hardware and software) and of pioneering deployment of
distributed systems and applications. At the beginning of the 1990's,
new communications technologies and new distributed applications are
emerging that will have far-reaching impact on communications software.
Very high-speed networks (e.g., from FDDI to Gigabit technologies), multi-
and continuous-media communications, interconnection of workstations and
supercomputers, visualization and image applications, and computer-supported
cooperative work (CSCW) are just a few examples. Participation in the
conference by both developers of advanced distributed applications or
systems and researchers interested in communications software will
provide a mutually beneficial dialogue.
FEATURED SPEAKERS
Ken Birman, Cornell University, "Group Communication in Operating System
Microkernals"
Roger Bushnell, Bell Northern Research, "Subscriber Service Evolution"
J. L. Felton, IBM, "Directions in Information Systems in the 1990s"
John Morris, Open Software Foundation, "Distributed Systems: Meeting the
Needs of the 90s"
Dave Sincoskie, Bellcore, "Gigabit Testbed Activities at Bellcore"
SESSIONS
COMMUNICATIONS FOR MULTIMEDIA
"Multimedia TeleConferencing over International Packet Switched Networks,"
J. Crowcroft, University College-London
"On the Synchronization and Display of Multiple Full-Motion Video Streams,"
Howard Katseff, AT & T Bell Laboratories
"Delay Jitter Control for Real-Time Communication in a Packet Switching
Network,"
Dinesh C. Verma, University of CA-Berkeley & International Computer Science
Institute
"New Virtual Time CSMA/CD Protocols for Real-Time Communication,"
Jaideep Srivastava, University of Minnesota
APPLICATIONS AND ARCHITECTURES
"The Design and Implementation of the MONTAGE Multimedia Mail System,"
Keith Edwards, Georgia Institute of Technology
"A Proposed Extension of the ODA Document Model for the Processing of
Multimedia Documents,"
Hannes P. Lubich, ETH-Zurich
"The Andrew File System on OS/2 and SNA,"
Neil Sullivan, IBM-RTP
"Vector Processor Services for Local Area Networks,"
Scott Midkiff, Virginia Polytechnic Institute and State University
COMPUTER CONFERENCING
"Evaluating Alternative Display Sharing System Architectures,"
Nina Rosson, Southwest Research Institute
"XTV: A Framework for Sharing X Window Clients in Remote Synchronous
Collaboration,"
Hussein Abdel-Wahab, Old Dominion University
"Control Issues in Multimedia Conferencing,"
S. R. Ahuja, AT & T Bell Laboratories
"System Design for Workstation-Based Conferencing with Digital Audio
and Video."
Kevin Jeffay, University of North Carolina-Chapel Hill
NETWORK PROTOCOLS AND IMPLEMENTATIONS
"A Communication Protocol for a Multi-level Secure Network,"
Andrew Mazeikis, Queen's University-Ontario
"Heirarchial Network Routing,"
Alan Fekete, University of Sydney
"A Parallel Implementation of the ISO 8802-2.2 Protocol,"
Matthias Kaiserswerth, IBM Research-Zurich
"A Layered Communication System Generator,"
Gen-Huey Chen, National Taiwan University
PERFORMANCE AND MEASUREMENT
"The Effects of Long Delay and Transmission Errors on the Performance of TP-4
Implementation,"
Randy C. Mitchell, The MITRE Corp.
"HiPPI Link Data Analysis System,"
Dan Winkelstein, MCNC
"Tingle: Suite for Monitoring Networks,"
J. Dean Brock, University of North Carolina-Asheville
"Capability Analysis of Distributed Switching Systems in Interprocessor
Communications,"
Serap Savari, MIT
CONFERENCE COMMITTEE
Alan Blatecky, General Chairman Jurg Nievergelt, International Chairman
MCNC, USA ETH, Switzerland
Peter Calingaert Andre Fournier
UNC-Chapel Hill, USA BNR, USA
David May Joe Rusnak
BNR, USA IBM, USA
Dan Stevenson
MCNC, USA
PROGRAM COMMITTEE
F. Donelson Smith Chairman Yutaka Matsushita
IBM & UNC-Chapel Hill, USA Keio University, Japan
Steven Bellovin Najah Naffah
AT & T Bell Laboratories, USA Bull, France
Rich Chilausky Erich Neuhold
BNR, USA GMD-IPSI, Germany
Brian Coan Bernhard Plattner
Bellcore, USA ETH, Switzerland
Flaviu Cristian Tom Rodeheffer
IBM Research-Almaden, USA DEC System Research Center, USA
Carla Ellis Beverly Sanders
Duke University ETH, Switzerland
Rong-Chin Fang M. Satyanarayanan
Northern Telecom, USA Carnegie Mellon U., USA
Domenico Ferrari H.T. Smith
U. of CA-Berkeley, USA Nottingham University, UK
James P. Gray Jorgen Stanstrup
IBM-RTP, USA Technical University, Denmark
Fukuya Ishino Liba Svobodova
NTT, Japan IBM Res.-Zurich, Switzerland
Kevin Jeffay Mladen Vouk
UNC-Chapel Hill, USA NC State U., USA
Rivka Laden Hussein Abdel-Wahab
DEC CRL. USA Old Dominion University, USA
Simon Lam William Weihl
U. of Texas-Austin, USA MIT, USA
Geovane Magalhaes Jennifer Welch
CPqD/TELEBRAS, Brazil UNC-Chapel Hill, USA
LOCATION
TriComm '91 will take place in Chapel Hill, North Carolina, at the University
of North Carolina. The University of North Carolina is located at one corner
of North Carolina's Research Triangle (Raleigh, Durham, Chapel Hill) in the
center of which is the Research Triangle Park and the Raleigh-Durham Airport.
MCNC, a national resource in microelectronics, is located in the Research
Triangle Park. MCNC is a non-profit corporation established to support and
develop t