|
|
ARCHIVE: TCP-IP Distribution List - Archives (1992)
DOCUMENT: TCP-IP Distribution List for November 1992 (353 messages, 194577 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1992/11.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Sun, 1 Nov 1992 18:26:13 GMT From: ashah@eos.ncsu.edu (AJAY SHAH) To: comp.protocols.tcp-ip,comp.protocols.pcnet,comp.protocols.tcp-ip.ibmpc Subject: TEST ...
Test Test Test ...
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Sun, 1 Nov 1992 21:52:23 GMT From: dberry@csa.cs.technion.ac.il (dberry) To: comp.protocols.ibm,comp.protocols.tcp-ip Subject: Connecting DEC Vax clusters with IBM SNA networks
We are looking for a gateway that will allow a variety of applications including databases and file servers access to work accross a network consisting of a number of Vax clusters, IBM mainframes and Token-Ring LANs. The connection is accross X.25 WAN. It seems that having a gateway between the VAX world and the SNA world will be of help. What manufacturers are making such gateways? Thanks, Orna -- Prof. Daniel M. Berry, Computer Science Department, Technion, Haifa 32000 ISRAEL Tel:+972-4-294325, Bitnet:DBERRY@TECHSEL Csnet & Internet:dberry@sel.technion.ac.il
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 2 Nov 92 02:27:18 GMT From: sob@hsdndev.UUCP (Scott Bradner) To: comp.protocols.tcp-ip Subject: new Harvard performance numbers
fyi - the results of the new round of Harvard router performance tests are now on-line. Pictures to follow "soon" Scott Machine: hsdndev.harvard.edu (128.103.202.40) Directory: pub/ndtl/results
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Mon, 2 Nov 1992 04:38:47 GMT From: marka@syd.dms.CSIRO.AU (Mark Andrews) To: comp.protocols.tcp-ip Subject: Re: ICMP redirects
In article <don-301092144034@nocmac.cis.brown.edu> don@bodovipa.cis.brown.edu (Donald Wright) writes: >When doing a 'netstat -rn', redirects often show up with the flags UGHDM. >I have been unable to find any documentation on what the "M" stands for. >Does anyone have a clue ? > >Don Wright, Network Systems Specialist >Brown University, Providence RI >Internet: Donald_Wright@Brown.EDU >Phone: (401) 863-7405 >*** Talk is cheap, words plentiful, and deeds precious - Ross Perot *** It stands for multiple. i.e. you have been redirected and then redirected again. If you look an <net/route.h> you will see a flag bit RTF_MODIFIED which indicates that it has been modified be a redirect rather than created be a redirect. Mark.
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Mon, 2 Nov 1992 11:07:26 GMT From: geertj@ica.philips.nl (Geert Jan de Groot) To: comp.protocols.tcp-ip Subject: Re: rpc process chewing up resources
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >The Sun idea is to use the standard stuff to see if ypbind is >registered with the port mapper. Using TCP does mean a socket is left >in TIME_WAIT, but it also means that an answer is returned >immediately. While waiting for SUN to come up with a solution (solaris 3.x maybe?) a workaround might be to make the domainname of your system EMPTY. By default, if you don't set your domainname and don't use Yellow Plague, the install program sets it to 'noname' or such. Just changing that to an empty string killed the huge amount of TIME_WAIT calls here. The easiest way to do this is to edit /etc/defaultdomain (sunos 4.1.x) and make it empty. Hope this helps, Geert Jan --8<--nip-nip--------------------------------------------------------------- "We trained hard - but it seemed that every time we were beginning to form up into teams, we would be reorganized. I was to learn later in life that we tend to meet any new situation by reorganizing, and a wonderful method it can be for creating the illusion of progress while producing confusion, inefficiency, and demoralisation." - possibly from Petronius, 100 BC Geert Jan de Groot SFJ2-218, Philips CE-ADC, P.O. box 80002, 5600 JB Eindhoven, The Netherlands. Email: geertj@ica.philips.nl or ..!sun4nl!philica!geertj Phone: +31 40 797408 FAX: +31 40 732340
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Mon, 02 Nov 92 11:32:01 GMT From: sensei@dojo.mi.org (the Maniak) To: comp.unix.ultrix,comp.protocols.tcp-ip Subject: Giving an Ultrix box a second IP address
For political reasons, I'd like to assign a second IP address in a
different logical network (same physical network) to an Ultrix box.
If this possible, and if so, how?
Maybe I'm pursuing this from the wrong angle. I need to run a
TCP/IP service from one particular IP address, off a machine that
needs to have another IP address/nameservice/etc. for every other
purpose. Am I pursuing the right track here?
...Sensei
==
Internet: sensei@dojo.mi.org
UUCP: ...!wsu-cs!dojo!sensei
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 2 Nov 1992 13:41:24 GMT From: dcleek@csd4.csd.uwm.edu (Dick Cleek) To: comp.protocols.tcp-ip,comp.protocols.pcnet,comp.protocols.tcp-ip.ibmpc Subject: cutcp docs/scripts
Where can I find documentation on cutcp, esp. ftpbin ?? Especially, writing scripts? Thanks in advance. -- .......... ......................... ....................... : |_|\/\/ : Dick Cleek dcleek@csd4.csd.uwm.edu :.centers.: Univ.of Wisconsin Centers dcleek@uwcmail.uwc.edu
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Mon, 2 Nov 1992 15:09:59 GMT From: madhu@cbnewsf.cb.att.com (madhu.shekhar) To: comp.protocols.tcp-ip Subject: TCP/IP sources with MIB-II wanted
Hello,
Will some good samaritan out there please
e'mail me site info on sites having public domain
TCP/IP sources with MIB-II
Thanks in advance
Madhu Shekhar
(908) 957-6859
madhu@mt747.att.com
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Mon, 2 Nov 1992 16:20:04 GMT From: steve@ecf.toronto.edu (Steve Kotsopoulos) To: comp.protocols.tcp-ip Subject: Re: Who supports multicast? (summary of responses)
In comp.protocols.tcp-ip I wrote: >Sorry if this is a FAQ, but I am trying to find out which UNIX >operating systems support multicast (for a project I'm working on). >So far, the only one I have found is SGI's IRIX 4.0.5. Here is a brief summary of the replies I got: Ultrix: no SunOS 4.x: no. Patches available for 4.1.x to add it. SunOS 5.x alias Solaris 2.x: yes. It was first supported in the IRIX 3.3.x release (1990). CDC's EP/IX supports IP multicasting since EP/IX 1.4.3. Thanks to the following people for their help: John DiMarco <jdd@cdf.toronto.edu> arc@xingping.esd.sgi.com (Andrew Cherenson) Doug.McCallum@Central.Sun.COM (Doug McCallum) barnett@alydar.crd.ge.com (Bruce Barnett) Klaus.Steinberger@Physik.Uni-Muenchen.DE guy@auspex.com (Guy Harris) -- Steve Kotsopoulos mail: steve@ecf.toronto.edu Systems Analyst bitnet: steve@ecf.UTORONTO.BITNET Engineering Computing Facility uucp: uunet!utai!ecf!steve University of Toronto phone: (416) 978-5898
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Mon, 2 Nov 1992 17:10:28 GMT From: mdm@kataan.apple.com (Michael McDaniel) To: comp.protocols.tcp-ip,comp.sys.mac.comm Subject: Mac IP?
Hi all,
Here's a strange one. I have a Mac IIsi connected via 50' of ethernet
to a single UNIX box (a NeXT, as it happens). I want to login to the
NeXT from my Mac, but I don't have any kind of gateway around. I
presume, therefore, that I cannot use MacTCP. I think I need some way
to get the Mac to talk IP directly.
I haven't been able to get them talking yet, but I'm not even sure
that the ethernet wire is good. The NeXT can ping itself even if the
ethernet is unbound...
Any ideas?
I'll summarize if there seems to be interest.
Michael
--
Michael D. McDaniel mdm@apple.com
Enterprise Systems Division {amdahl,decwrl,sun,unisoft}!apple!mdm
Apple Computer, Inc.
Beverly: "My personal feelings about Captain Picard are irrelevant to
this investigation, and none of your business."
--Beverly, "Coming Of Age", Stardate 41416.2
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 2 Nov 92 17:43:37 GMT From: gsa@easyaspi.udev.cdc.com (gary s anderson) To: comp.protocols.tcp-ip Subject: Re: Detecting Dropped Sockets (Why is this hard on PC's?)
In article <1992Oct30.212442.119@novell.com>, donp@novell.com (don provan) writes: |> In article <9213@verdix.verdix.com> mark@verdix.com (Mark Lundquist) writes: |> >My point is that the interpretation of FIN is non-negotiable, as that |> >is part of the TCP spec. The interpretation of "connection completes |> >normally" is implementation-dependent. |> |> The interpretation "connection completes normally" is defined by the |> application protocol. Anything that automatically injects a "complete |> connection normally" signal into the TCP data stream without the |> permission of the application protocol implementation is just plain |> broken, since only the application protocol implementation can know |> what that means. |> |> >I'm not familiar with the FTP spec or any implementations, but I'd say |> >it's a fair bet that they don't rely on connection closing to signal |> >the end of an arbitrary-length data stream. |> |> You'd be wrong. FTP indicates the end of a file being transfered by |> closing the TCP connection that was used to transfer the file. |> There's nothing wrong with this: it's only a problem because of the |> broken TCP implementations we're discussing that inject a graceful |> close into a connection they know nothing about. |> don provan |> donp@novell.com I don't disagree with your statements, however, I was curious about the systems you execute on. Specifically, when a process is terminated, what happens to the open file descriptors? Aren't they typically "closed"? Doesn't TCP typically map this into a "normal connection close"? I assume that you would inject an RST in cases where you could prove "abnormal termination". Can you cite an RFC which gives guidelines as to when TCP should inject an RST on behalf of the application? I'm sure we would benefit from clean, consistent implementations. The problem I see is that most nominal BSD implementations do not externalize the "abort" option to the applications (NOTE - "don't linger" doesn't do the job in the few BSD systems I've tried). Here's a possible solution: Provide a socket option to "abort the connection" on close Applications using "normal completion" as a protocol event trigger can select this option (actually any application could use it) When the application is completed with the data transfer it can reset the option to "normal termination" on close NOTE - this only works if the peer system does something meaningful with the receipt of the RST, and of course, the application would have to be in-sync with the propagation of the RST event. This option seems clean and straight-forward. The problem is I am not aware of implementations "providing and using" a similar capability. Once again, I don't doubt your position. I simply don't see conformance in the de-facto implemenation and I don't see guidelines in any RFC's.
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 2 Nov 92 18:15:14 GMT From: gsa@easyaspi.udev.cdc.com (gary s anderson) To: comp.protocols.tcp-ip Subject: Re: rpc process chewing up resources
In article <rqqij64@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: |> In article <49102@shamash.cdc.com>, gsa@easyaspi.udev.cdc.com (gary s anderson) writes: |> > ... |> > Last I looked "sunrpc" was the port number for the portmapper (111). |> > There used to be some "questionable" code in the "ONC suite" which |> > would logically "ping" the portmapper by attempting to create a |> > connection to the portmapper daemon. As I recall, the code actually |> > sits within the "yp" library code (you need to ask SUN why "pinging" |> > the portmapper from within "yp" is useful). This has the wonderful |> > side-effect of leaving connections in a TIME_WAIT state. The |> > frequency of "pings" is usually once per process. Consequently, |> > when you use multi-process applications or write iterative |> > scripts (large iteration count and short duration processes) |> > you exacerbate the problem. |> > |> > The best answer is to ask SUN for a software upgrade. |> |> |> Hmmmph! |> What would you do if you wanted to discover if ypbind is running? I would send a UDP RPC request to the portmapper to find out if ypbind was registered. The problem is that there is code which creates a "dummy" TCP connection just to see if the portmapper is running (i.e. doesn't trust UDP time-outs as sufficient evidence that the portmapper is not running). If the connection succeeds, it is immediately closed and then the UDP RPC request is made to the portmapper to get the information about ypbind. |> |> The Sun idea is to use the standard stuff to see if ypbind is |> registered with the port mapper. Using TCP does mean a socket is left |> in TIME_WAIT, but it also means that an answer is returned |> immediately. Maybe a few scripts showing you what happens when several thousand TIME_WAIT connections per second are left on your system will convince you this is an issue. What's great is that these are all "loopback" connections (i.e. no network latency when generating and no peer system re-use of existing ports)! Of course, you may argue (and not be disagreed with) that this a good reason not to use NIS. |> |> > In the short term, you could avoid using "names" (e.g. netstat -rn) |> > or you could stop using yellow pages (a.k.a. NIS) or you could |> > place frequently referenced names in the local files (e.g. /etc/hosts). |> > |> > NOTE - there maybe a thousand other reasons for this behavior, however, |> > this looks awfully similar to locally observed symptoms. |> |> Netstat can be helped a lot by fixing getservent.c to do cache |> /etc/services when running with NIS turned off. The standard |> implementation scans the whole stupid file on every call, and also |> pokes to see if ypbind is running. |> |> |> Vernon Schryver, vjs@sgi.com
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Mon, 2 Nov 1992 18:57:47 GMT From: lucien@watson.ibm.com (Lucien Van Elsen) To: comp.unix.admin,comp.unix.aix,comp.protocols.tcp-ip Subject: Re: inetd configuration questions
graeme@ccu1.aukuni.ac.nz ( Graeme Moffat) writes: >>Did you execute "inetimp" and "refresh -s inetd" to make sure the odm >>had what was in the inetd.conf file? > >I have noticed in the "Diskless Workstation Management Guide", when >referring to changing inetd.conf, that the command "inetimp" is omitted from >the instructions. Does 3.2 now not use the ODM for inetd? "refresh -s inetd" causes an "inetimp" to occur, and I believe this was true under 3.1 as well. However, this doesn't seem to be a documented feature anywhere, so I wouldn't rely on it in the future. -Lucien -- ----------------------------------------------------------------------- Lucien Van Elsen IBM Research lucien@watson.ibm.com Project Agora
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Mon, 2 Nov 92 19:08:05 GMT From: mogul@pa.dec.com (Jeffrey Mogul) To: comp.protocols.tcp-ip Subject: Re: Who supports multicast? (summary of responses)
In article <Bx3K1H.4ut@ecf.toronto.edu> steve@ecf.toronto.edu (Steve Kotsopoulos) writes: >>Sorry if this is a FAQ, but I am trying to find out which UNIX >>operating systems support multicast (for a project I'm working on). >>So far, the only one I have found is SGI's IRIX 4.0.5. > >Here is a brief summary of the replies I got: > Ultrix: no > SunOS 4.x: no. Patches available for 4.1.x to add it. > SunOS 5.x alias Solaris 2.x: yes. > It was first supported in the IRIX 3.3.x release (1990). > CDC's EP/IX supports IP multicasting since EP/IX 1.4.3. Technically, ULTRIX does not support IP multicast. However, you can obtain patches for ULTRIX V4.2A via anonymous FTP: gregorio.stanford.edu:/vmtp-ip/ipmulticast-ultrix4.2a-binary.tar I have no direct knowledge that these patches actually work, and I'm sure that Digital will not be able to help you with them. But I believe that the Stanford folks use them successfully. This same directory also includes other related files, including source diffs for some versions of ULTRIX (3.1C, 4.1, 4.2A). If you have an Ultrix source license, you might be able to make use of these. And if you want IP multicast support in ULTRIX or OSF, you might consider calling your DEC salesperson and saying so. -Jeff
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Mon, 2 Nov 1992 19:29:34 GMT From: rstevens@noao.edu (W. Richard Stevens) To: comp.protocols.tcp-ip Subject: Re: Detecting Dropped Sockets (Why is this hard on PC's?)
>The problem I see is that most nominal BSD >implementations do not externalize the "abort" option to the >applications (NOTE - "don't linger" doesn't do the job in the few >BSD systems I've tried). On the latest BSD systems (such as BSD/386) linger does (finally) work. Set the SO_LINGER socket option with l_onoff to 1, and l_linger to 0. When you call close() a reset is sent out. (I just watched this with tcpdump.) These newer systems also let you set l_linger to a timer value. Unfortunately, there are some gotchas. First, the l_linger value is not in seconds, but is in clock ticks. Next, even though l_linger is an "int" in the linger structure, it's stored into the signed short so_linger in the socket structure, so you're limited to 32.767 seconds if the system uses 100 ticks/second. It would sure be nice if other vendors picked up support for the linger feature ... >NOTE - this only works if the peer system does something meaningful >with the receipt of the RST, and of course, the application would >have to be in-sync with the propagation of the RST event. The receiver gets ECONNRESET, so it can distinguish between a normal close by the other end, and this abort. Rich Stevens (rstevens@noao.edu)
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Mon, 2 Nov 1992 20:49:45 GMT From: add@is.rice.edu (Arthur Darren Dunham) To: comp.protocols.tcp-ip,comp.sys.mac.comm Subject: Re: Mac IP?
In article <6@kataan.apple.com> mdm@apple.com writes:
>Hi all,
>
>Here's a strange one. I have a Mac IIsi connected via 50' of ethernet
>to a single UNIX box (a NeXT, as it happens). I want to login to the
>NeXT from my Mac, but I don't have any kind of gateway around. I
>presume, therefore, that I cannot use MacTCP. I think I need some way
>to get the Mac to talk IP directly.
You presume incorrectly. MacTCP can do either IPTalk (requiring a
gateway, but works over AppleTalk only lines), or full IP. When MacTCP
is set to "EtherNet" not "EtherTalk", then it is talking IP. A
copy of Telnet 2.5 or any other MacTCP based terminal emulator is all
that is required to get a login to the NeXT.
Just make sure that the IPaddresses you set for each machine are sane
and within the subnet mask. Try pinging the mac from the NeXT at that
point.
>Michael D. McDaniel mdm@apple.com
>Enterprise Systems Division {amdahl,decwrl,sun,unisoft}!apple!mdm
>Apple Computer, Inc.
--
Darren Dunham add@is.rice.edu
MicroConsultant Rice University
(What is that? A small consultant?) Houston, TX
Any resemblance between real opinions and my post is coincidental
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Mon, 2 Nov 1992 21:01:09 GMT From: resnick@cogsci.uiuc.edu (Pete Resnick) To: comp.protocols.tcp-ip,comp.sys.mac.comm Subject: Re: Mac IP?
mdm@kataan.apple.com (Michael McDaniel) writes: >Here's a strange one. I have a Mac IIsi connected via 50' of ethernet >to a single UNIX box (a NeXT, as it happens). I want to login to the >NeXT from my Mac, but I don't have any kind of gateway around. I >presume, therefore, that I cannot use MacTCP. I think I need some way >to get the Mac to talk IP directly. If you have an Ethernet board in the Mac, then MacTCP can put IP on the Ethernet directly and does not need a gateway. Just select "Ethernet" (as opposed to "EtherTalk" or "LocalTalk") in the MacTCP control panel. Then you should be fine. pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet: resnick@cogsci.uiuc.edu
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 2 Nov 92 21:08:48 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: rpc process chewing up resources
In article <49194@shamash.cdc.com>, gsa@easyaspi.udev.cdc.com (gary s anderson) writes: > |> > Last I looked "sunrpc" was the port number for the portmapper (111). > |> > There used to be some "questionable" code in the "ONC suite" which > |> > would logically "ping" the portmapper by attempting to create a > |> > connection to the portmapper daemon. As I recall, the code actually > |> > sits within the "yp" library code (you need to ask SUN why "pinging" > |> > the portmapper from within "yp" is useful). This has the wonderful > |> > side-effect of leaving connections in a TIME_WAIT state. The > |> > frequency of "pings" is usually once per process. Consequently, > |> > when you use multi-process applications or write iterative > |> > scripts (large iteration count and short duration processes) > |> > you exacerbate the problem. > |> > > |> > The best answer is to ask SUN for a software upgrade. > |> > |> Hmmmph! > |> What would you do if you wanted to discover if ypbind is running? > > I would send a UDP RPC request to the portmapper to find out > if ypbind was registered. The problem is that there is code > which creates a "dummy" TCP connection just to see if the > portmapper is running (i.e. doesn't trust UDP time-outs as > sufficient evidence that the portmapper is not running). > If the connection succeeds, it is immediately closed and then > the UDP RPC request is made to the portmapper to get the > information about ypbind. Perhaps my point was not clear. By using TCP you avoid having to wait for a UDP time-out to expire when things are not present. Which would make you more unhappy? Having an anonymous TCP port number tied up for a little while or having to wait a large part of a second (or more if you allow remote access over slow links) to discover that the portmapper is not running? Using TCP ensures that if the destination host is up and reachable, you'll get an answer immediately. Of course, if you always run with ypbind and portmap running, you don't care about such a test. You'll probably be happier lumping the portmap-not-running case in with the host-not-up case. > |> The Sun idea is to use the standard stuff to see if ypbind is > |> registered with the port mapper. Using TCP does mean a socket is left > |> in TIME_WAIT, but it also means that an answer is returned > |> immediately. > > Maybe a few scripts showing you what happens when several thousand > TIME_WAIT connections per second are left on your system will > convince you this is an issue. What's great is that these are > all "loopback" connections (i.e. no network latency when generating > and no peer system re-use of existing ports)! > > Of course, you may argue (and not be disagreed with) that this > a good reason not to use NIS. What harm do the dead TCP ports do? The modest sized university servers which are Silicon Graphics boxes that I know of (i.e. many thousands of users and hundreds of simultaneous active sessions) do not suffer from any difficulties caused by the wasted TCP ports. How do you get "several thousand TIME_WAIT connections per second ... left on your system" in a realistic application? What kind of application and system does "several thousand" NIS lookups per second? It seems to me that any application that does "several thousand" NIS lookups per second is almost certainly very badly designed. It is far more important to design a system to work well in real life than to handle pathological test scripts. For any non-trivial system, there exists a sequence of requests which will be pathologically slow. It is impossible to design anything to do everything well. The use of the TCP RST to detect an absent portmapper is elegant and economical. The cost of the wasted TCP port numbers is several thousands of times less than the cost of not having reasonable port number lookup facilities available for programs like netstat. Vernon Schryver, vjs@sgi.com
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Mon, 2 Nov 1992 22:58:16 GMT From: garrod@smaug.enet.dec.com (Dave Garrod) To: comp.protocols.ibm,comp.protocols.tcp-ip Subject: Re: Connecting DEC Vax clusters with IBM SNA networks
In article <1992Nov1.215223.14114@discus.technion.ac.il>, dberry@csa.cs.technion.ac.il (dberry) writes... >We are looking for a gateway that will allow a variety of applications >including databases and file servers access to work accross a network >consisting of a number of Vax clusters, IBM mainframes and Token-Ring LANs. >The connection is accross X.25 WAN. It seems that having a gateway between >the VAX world and the SNA world will be of help. What manufacturers are >making such gateways? > >Thanks, Orna Digital Equipment Corporation offers a complete range of IBM Interconnect Products to interconnect IBM SNA networked systems to DECnet and TCP/IP networks. You can get information on the DECnet/SNA product set from your local Digital sales office. The piece of literature you should ask for is the "Network Buyers Guide" Dave
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 3 Nov 92 07:43:34 GMT From: hauben@cunixf.cc.columbia.edu (Michael Hauben) To: comp.protocols.misc,comp.unix.questions,news.misc,comp.misc,comp.mail.uucp,comp.protocols.tcp-ip,de.comm.uucp,aus.auug Subject: How are Usenet Posts Transported?
I am interested in the technical explanation and general theory
of how Usenet Posts are transported between the original location
and the rest of the Usenet. I am doing research for a paper about
the origins and explosion of Usenet and connectivity. My Profes-
sor has asked me to include some explanation how messages are
transported.
Thank You,
-Michael
hauben@cunixf.cc.columbia.edu
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Tue, 3 Nov 1992 18:10:36 -0500 From: Pat_Barron@transarc.com To: comp.protocols.tcp-ip Subject: TACACS protocol
OK, I give up. Where is the TACACS protocol documented? I can't find it in any RFC or IEN. --Pat.
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 3 Nov 92 14:20:52 GMT From: maclean@ctt.bellcore.com (Andrew MacLean) To: comp.protocols.tcp-ip Subject: TCP Error Control Question
I have some questions on TCP error control. For common TCP implementations (e.g. SUN): - Do we have a retransmission timer for each transmitted segment or one timer for the whole window? - What happens when the retransmission timer expire? and how it is set and reset? - Does the receiver accept out-of-sequence segments as long as they fit within the receive window? and what is the maximum (receive) window size? Any references would help. Thanks -- Andy ________________________ maclean@ctt.bellcore.com
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 3 Nov 1992 15:02:54 GMT From: kschulz@ba-stuttgart.de (Kay Schulz) To: comp.protocols.tcp-ip Subject: tcp-ip/nfs
Hi, does anybody can tell me the difference and the sense of tcp-ip and nfs i use both here, but why I need them or not and when they are for, I don't know. and I would like to know about NIS(yellow pages). Or do you know a good book? KAY ///**************************************************/// ///*** kschulz@garfield.t-informatik.ba-stuttgart.de***/// ///*** KAY ***///
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Tue, 3 Nov 1992 15:15:34 GMT From: cm@impmh.uucp (Colin Manning) To: comp.protocols.tcp-ip Subject: Online source of IEEE specifications wanted
Does anyone know where to obtain IEEE networking standards from on the Internet ? I'm principally after some of the 802 series. -- Colin Manning cm@impmh.uucp Tel: +44 753 516599
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Tue, 3 Nov 1992 19:11:22 GMT From: bob@MorningStar.Com (Bob Sutterfield) To: comp.protocols.ppp,comp.protocols.tcp-ip Subject: Re: CSU/DSU w/ RS-232 port connected to system
In article <0105015D.hgkk5a@phngnc.Phonogenic.COM> wjk@Phonogenic.COM (Bill Keenan) writes: Does anyone know if I can connect a 56K CSU/DSU with an RS-232 connection to a serial port, which can sustain 56K, on my mail/news system instead of using a router? Most 56K CSU/DSUs are synchronous beasties, and your mail/news system's serial ports are probably asynchronous beasties. The two won't talk. Some CSU/DSUs can talk to an async serial port and convert the data stream into sync before putting the bits on the wire. This would be the sort you'd probably need with your current setup. Alternatively, you could run synchronous PPP on your mail/news system, which would turn it into a sync-PPP router that would talk to most 56K CSU/DSUs. You'd need (a) synchronous PPP software and (b) appropriate synchronous hardware.
-----------[000025][next][prev][last][first]----------------------------------------------------
Date: 3 Nov 92 19:14:07 GMT
From: shj@ultra.com (Steve Jay {Ultra Unix SW Mgr})
To: comp.protocols.tcp-ip
Subject: Re: rpc process chewing up resourcesgsa@easyaspi.udev.cdc.com (gary s anderson) writes: >Of course, you may argue (and not be disagreed with) that this >a good reason not to use NIS. I missed the beginning of this thread, so maybe what's being discussed here isn't the same problem I've seen. The only time I've seen lots of TIME_WAIT connections is when NIS is NOT used, never when NIS is being used. I never investigated the situation very far, but as best I can tell, any getXbyY request which potentially uses an NIS map causes the NIS library routines to see if ypbind is running. If ypbind is running, the library routines cache this result, and additional getXbyY calls don't check again. But, if ypbind is not running, each getXbyY call causes the library to check again, which opens another socket to the portmapper. Because each connection netstat looks at requires several getXbyY calls, you get an explosion of connections if you repetitively run netstat when ypbind isn't running. Is this the problem that's being discussed in this thread, or is this something different? Steve Jay shj@ultra.com ...ames!ultra!shj Ultra Network Technologies / 101 Dagget Drive / San Jose, CA 95134 / USA (408) 922-0100 x130 "Home of the 1 Gigabit/Second network"
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Tue, 3 Nov 1992 19:33:22 GMT From: ae56@rz.uni-karlsruhe.de () To: comp.protocols.tcp-ip Subject: CFP: CSAM93 Computer Congress
************************************************************************
PLEASE MAKE THIS ANNOUMCEMENT AVAILABLE TO YOUR COLLEAGUES
IN ANY APPROPRIATE FORM !
************************************************************************
******* FIRST ANNOUNCEMENT AND CALL FOR SESSIONS AND PAPERS ************
INTERNATIONAL CONGRESS ON COMPUTER SYSTEMS AND APPLIED MATHEMATICS
19-23 JULY 1993
ST. PETERSBURG, RUSSIA
Organized by Center of Modern Communications, University of St.
Petersburg
THE AIMS of the Congress are to provide a forum to explore common
interests and interplay across disciplines, and to bring to
practicing researchers recent advances and the state of the art
in all areas of computer science, scientific computing, software
engineering, applied and computational mathematics. The official
language of the Congress is English and only papers submitted
in English will be considered.
THE TOPICS highlighted by the Congress include, but are not limited
to: Programming Languages; Numerical Analysis; Differential
Equations; Inverse Problems; Fluid Dynamics; Quantum and Statistical
Mechanics; Applied Probability and Statistics; Theory of Computing;
Scientific Computation; Parallel Processing; Supercomputing;
Optimization and Operations Research; Software Engineering and
Compiler Construction; Symbolic Computation; CASE Tools; Fuzzy
Systems; Databases; Networks; Neural Nets; Artificial Intelligence;
Expert Systems; Computer Graphics; Computer Vision and Image
Processing; Data Security; Simulation and Modelling; Electromagnetics
and Semiconductors; Medicine and Biology; Mathematical Education;
Dynamical Systems; Economics and Management; Environmental Science;
Manufacturing Systems; Material Science;
MINISYMPOSIA PROPOSAL:
The Program Committee invites you, as a potential organizer, to submit
a proposal for a minisymposium. A minisymposium is a session of 3-6
speakers focusing on a single topic. The organizers should submit
the title(s) of the session(s) they propose to the Program Committee
as soon as possible. Minisymposium organizers are responsible for the
scientific quality of papers in their sessions, consequently all
papers invited by organizers are automatically accepted.
CONTRIBUTED PAPERS/POSTER PRESENTATIONS:
The program will also include contributed paper sessions (20 -
minute presentation), posters, and industrial exhibits. Authors are
invited to submit to the CSAM'93 Program Committee a one page
abstract and indicate if they prefer an oral or poster session.
Authors may suggest the title(s) of appropriate session(s) for
their paper. Manuscripts of papers presented at the Congress will
be published as CSAM'93 Proceedings after the Congress. A volume
containing all abstract of the accepted papers and description of all
minisymposia including titles and speakers known by May 1, 1993, will
be available to the participants at the Congress. Late papers and
sessions, if accepted, may be presented at the Congress and will be
listed in the Supplementum to the final program.
DEADLINES:
Minisymposium proposals: As soon as possible; Early submissions due:
February 1, 1993; Normal submissions due: May 1, 1993; Late
submissions: After May 1, 1993.
EXHIBITOR INFORMATION:
Booths and tables will be available to companies wishing to display
their products and/or services.
Send inquires for further information, proposals for minisymposia,
and two copies of the abstract to:
Dr. Sergey S. Voitenko
Director, Center of Modern Communications,
University of St. Petersburg
14th Line 29
199178 St. Petersburg
Russia
e-mail: serge@spfac.lgu.spb.su
Outside of Ex-USSR and Eastern Europe proposals for minisymposia and
abstracts can be also send to Dimitri Shiriaev
e-mail: dima@iamk4508.rz.uni-karlsruhe.de
-----------------------Cut Here------------------------------------------------
FORM OF INTENTION
Name:
Affiliation:
Address:
Check as appropriate:
I plan to attend CSAM'93 and to :
- organize a Session/Group of Sessions
- contribute a 20 min lecture
- present a poster
- present a computer demonstration
Provisional title(s) of contributed session(s)/paper:
Although I have not yet decided to attend I wish to
- stay on the mailing list
Date: Signature:
Please mail this form to Dimitri Shiriaev
e-mail: dima@iamk4508.rz.uni-karlsruhe.de
Subject: CSAM93
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 3 Nov 92 21:58:41 GMT From: gsa@easyaspi.udev.cdc.com (gary s anderson) To: comp.protocols.tcp-ip Subject: Re: rpc process chewing up resources
In article <rsbtguk@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: |> In article <49194@shamash.cdc.com>, gsa@easyaspi.udev.cdc.com (gary s anderson) writes: |> > |> > Last I looked "sunrpc" was the port number for the portmapper (111). |> > |> > There used to be some "questionable" code in the "ONC suite" which |> > |> > would logically "ping" the portmapper by attempting to create a |> > |> > connection to the portmapper daemon. As I recall, the code actually |> > |> > sits within the "yp" library code (you need to ask SUN why "pinging" |> > |> > the portmapper from within "yp" is useful). This has the wonderful |> > |> > side-effect of leaving connections in a TIME_WAIT state. The |> > |> > frequency of "pings" is usually once per process. Consequently, |> > |> > when you use multi-process applications or write iterative |> > |> > scripts (large iteration count and short duration processes) |> > |> > you exacerbate the problem. |> > |> > |> > |> > The best answer is to ask SUN for a software upgrade. |> > |> |> > |> Hmmmph! |> > |> What would you do if you wanted to discover if ypbind is running? |> > |> > I would send a UDP RPC request to the portmapper to find out |> > if ypbind was registered. The problem is that there is code |> > which creates a "dummy" TCP connection just to see if the |> > portmapper is running (i.e. doesn't trust UDP time-outs as |> > sufficient evidence that the portmapper is not running). |> > If the connection succeeds, it is immediately closed and then |> > the UDP RPC request is made to the portmapper to get the |> > information about ypbind. |> |> Perhaps my point was not clear. |> |> By using TCP you avoid having to wait for a UDP time-out to expire when |> things are not present. Which would make you more unhappy? Having an |> anonymous TCP port number tied up for a little while or having to wait |> a large part of a second (or more if you allow remote access over slow |> links) to discover that the portmapper is not running? Are you concerned that "port not available" is not returned for UDP? Are you concerned that "port not available" cannot be linked to the calling end point (this is the most likely problem)? Are you concerned that the local RPC entity will not see the "port not available" error when it arrives (i.e. "select" does not wake up the application when an error is present)? Or is there some other subliminal concern which you have (i.e. do you use the presence of portmapper to determine the customer's selection of the yp service)? |> |> Using TCP ensures that if the destination host is up and reachable, |> you'll get an answer immediately. Of course, if you always run with |> ypbind and portmap running, you don't care about such a test. You'll |> probably be happier lumping the portmap-not-running case in with the |> host-not-up case. I never know how to satisfy everyone. Everyone seems to have their own vision. If a customer asks for a "yp" service should we ignore this if our "portmapper" is temporarily unavailable or should we provide a window for re-instantiation of the portmapper? If we stop using "yp" would that mean we might start querying the domain name system with requests it can never resolve (i.e. in cases where we used "yp" to resolve local domain host names and used DNS as the secondary base for everything else)??? I'm sure I could come up with a few other issues if I thought for a while. My point is that the quick receipt of "peer-not-available" does not necessarily yield a better result. I guess if you are using the "presence" of portmapper to determine whether or not "yp" services should be used then the use of TCP may have some value. There are actually several issues here, and maybe we are crossing signals: 1) Does it make sense to "ping" a UDP-based application with a TCP connection before issuing the UDP request to the application? I don't see the value, unless you are using this as a vehicle to determine the customer's desire to use the "application". Even then, only if you think the UDP services are inadequate. For "yp" you seem to feel strongly about this. I'm not sure why? 2) Are there issues with using TCP as a "ping service"? I don't like the fact that "TIME_WAIT" connections are left behind. You don't seem to think that any useful application could cause a problem. A compromise is probably to have support for a connection abort function (see Steven's reply in a different thread about connection terminations) and ultimately employ this service in applications. This however, is at least a few years from universal deployment. NOTE - we didn't even discuss the potnential waste of network resources. 3) Is the UDP RPC mechanism an ineffective means for obtaining portmapper information? I happen to think UDP is a good fit here. I don't think you've commented on this other than implicitly in your promotion of the TCP ping operation. |> |> |> > |> The Sun idea is to use the standard stuff to see if ypbind is |> > |> registered with the port mapper. Using TCP does mean a socket is left |> > |> in TIME_WAIT, but it also means that an answer is returned |> > |> immediately. |> > |> > Maybe a few scripts showing you what happens when several thousand |> > TIME_WAIT connections per second are left on your system will |> > convince you this is an issue. What's great is that these are |> > all "loopback" connections (i.e. no network latency when generating |> > and no peer system re-use of existing ports)! |> > |> > Of course, you may argue (and not be disagreed with) that this |> > a good reason not to use NIS. |> |> What harm do the dead TCP ports do? The modest sized university |> servers which are Silicon Graphics boxes that I know of (i.e. many |> thousands of users and hundreds of simultaneous active sessions) do not |> suffer from any difficulties caused by the wasted TCP ports. |> |> How do you get "several thousand TIME_WAIT connections per second ... |> left on your system" in a realistic application? What kind of |> application and system does "several thousand" NIS lookups per second? |> It seems to me that any application that does "several thousand" NIS |> lookups per second is almost certainly very badly designed. I'm disappointed that you have chosen to doubt the potential to create this many connections in a second. I would have thought you would have told us that you can do 10,000 per second..... The problem lies in the indefinite number of scripts and programs that people have written for UNIX systems over the years. Many of these applications function well when limited to small-scaled systems. However, people attempt to run these simple little applications in systems scaled 100 to 1000 times greater than the intent of the original application writer. When this happens, very interesting system features are encountered. Here's one simple case study to wet your taste buds: 1) Software development system 2) 100,000 files in the source library 3) Shell script walks through the source tree one "*.c" file at a time 4) An "ls -l" is done on each file checking group id 5) A list of all files owned by group "sys" is created 6) The sysadmin decides to switch one day from local files to NIS for group names This script was used for years and worked perfectly until someone decided to make use of NIS. Of course this script brought the system to its knees in a couple of seconds because of the yp feature. Better yet, the user running this script did so three or four times before they correlated the system death and the application launch. If this were the only possible case, I might agree that we simply eradicate the bad applications. Additionally, our customers tend to require vendor system fixes rather than re-writing their applications. Consequently, recommending removal of the "ping" operation seemed like a prudent choice. NOTE - the answer to the burning question is about 400-500 connections per second were generated by this application. However, vendors that think they can really support multiple processors concurrently will find that the potential is greater if concurrent users are invoking similar applications. |> |> It is far more important to design a system to work well in real life |> than to handle pathological test scripts. For any non-trivial system, |> there exists a sequence of requests which will be pathologically slow. |> It is impossible to design anything to do everything well. The use of |> the TCP RST to detect an absent portmapper is elegant and economical. |> |> The cost of the wasted TCP port numbers is several thousands of times |> less than the cost of not having reasonable port number lookup |> facilities available for programs like netstat. |> |> |> Vernon Schryver, vjs@sgi.com
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 4 Nov 92 01:20:30 GMT From: drew@feith1.UUCP (Andrew Sudell) To: comp.unix.aix,comp.protocols.tcp-ip Subject: Netbios over TCP/IP on RS/6000
Does anyone know of a product which supports Netbios over TCP/IP
(RFC 1001/1002) on a RS/6000 running AIX 3.2? I need to move a
netbios client program to AIX and unfortunately it is running
over netbios and RFC 1001 implementations seem hard to come by.
--
Andrew Sudell Phone: 215-646-8000 (main)
Feith Systems and Software, Inc. Phone: 215-540-5490 (support)
Systems Support Fax: 215-540-5495
Smart Mailers: drew@feith1.UUCP Dumb Mailers: {attmail|cbmvax}!feith1!drew
If you've done six impossible things this morning, why not round it off
with breakfast at Milliways, the Restaurant at the end of the Universe?
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Wed, 04 Nov 92 02:07:47 GMT From: ingham@hydra.unm.edu (Kenneth Ingham) To: comp.protocols.tcp-ip Subject: Address Gateway Software
(I am posting this for a friend without access to USENET, please reply to him, not me---Kenneth) I have two applications which I require information on. The first is an address translation gateway the second is a simple address administrator/database type application. Firstly the Address Translation Software.... The network under consideration requires a limited number of users to have interactive access to the Internet as well as providing inbound sessions to one or two hosts. Accordingly the translation application would supply a pool of Internet assigned addresses for outbound traffic, and hard mapped addresses for inbound traffic. One application we have knowledge of is NAT written by Paul Tsuchiya of Bell-Core. We don't know if this is appropriate. The sort of information we are after is the existance of such an application, networks where it is used, sizing info, and how we can get a hold of it. Secondly the address admin software..... The requirement here is for an application which administers the assignement of IP addresses. For example the net administrator would configure the details of how the address is broken down and the software would provide a front end which would simply assign an operator the next address of the rank. (Primitive stuff really) Please reply via email. Thanks for your help, Regards, Peter Stevenson Network Consultant JNA Telecommunications Limited voice: +61 2 417 6177 fax: +61 2 417 5837 e-mail: peterst@jna.com.au post: 16 Smith St, Chatswood, NSW 2067, Australia. -- Kenneth Ingham WD5BBT ingham@i-pi.com or ingham@ariel.unm.edu (NeXTMail OK) Hummin' little Grumman N9646L
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 4 Nov 92 02:21:20 GMT From: raw@ushiva.wariat.org (Roland Wilcher) To: comp.protocols.tcp-ip Subject: TCP connect
Some time ago there was a question about checking for a TCP connect to a possibly non functioning machine without the long wait. An answer was posted using connect with nonblocking mode. I don't have that article now but would appreciate any pointers . Target system would be Esix SVR4 using the socket libraries and TCP/IP. -- Lack of skill dictates economy of style. raw@ushiva.ncoast.org - Joey Ramone raw@ushiva.wariat.org Roland A. Wilcher 6207 Luther Ave. Cleve Oh. 44103 ---------------------------------------------------------------------------
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 4 Nov 92 06:17:19 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: rpc process chewing up resources
In article <1992Nov3.191407.2951@ultra.com>, shj@ultra.com (Steve Jay {Ultra Unix SW Mgr}) writes:
> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
>
> >Of course, you may argue (and not be disagreed with) that this
> >a good reason not to use NIS.
>
> I missed the beginning of this thread, so maybe what's being discussed
> here isn't the same problem I've seen. The only time I've seen lots of
> TIME_WAIT connections is when NIS is NOT used, never when NIS is being used.
>
> I never investigated the situation very far, but as best I can tell,
> any getXbyY request which potentially uses an NIS map causes the NIS
> library routines to see if ypbind is running. If ypbind is running,
> the library routines cache this result, and additional getXbyY calls
> don't check again. But, if ypbind is not running, each getXbyY
> call causes the library to check again, which opens another socket
> to the portmapper. Because each connection netstat looks at requires
> several getXbyY calls, you get an explosion of connections if you
> repetitively run netstat when ypbind isn't running.
>
> Is this the problem that's being discussed in this thread, or is this
> something different?
I think that's an aspect of the problem.
However, the abused ports with NIS turned off are not the worst part.
I think the worst comes from the fact that the getXbyY routines do not
generally cache the data itself. They do cache the "yellowup" flag,
and so hide their really hideous behavior. Watch how the port number
lookup code works.
Depending on timing, you can get netstat into an apparently infinite
loop. Each time it looks up one port, it can create another one, which
in turn must be looked up. What the the oddities of poking at kernel
virtual memory, the loop often does not happen. This behaviour is why
for years Silicon Graphics shipped netstat linked with neither DNS nor
with NIS libraries. It is only in recent months that some modest hacks
to the libraries have made it possible to turn on the network
databases. There are still 4 instead of 1 TIME_WAIT port when that
version of netstat is run without NIS turned on.
Vernon Schryver, vjs@sgi.com
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Wed, 4 Nov 92 09:24:03 GMT From: jogl@merry.imsd.rwth-aachen.de (Joachim Glaubrecht #Alwd#) To: comp.protocols.tcp-ip,comp.protocols.pcnet,comp.protocols.tcp-ip.ibmpc Subject: I/O-Ram for WD-Card > 1 MB ??!!
hi, sorry, if this is a FAQ, but we need help ... we have some Western Digital EtherNet Cards for out PCs and like to move the Buffer-Ram from the normale area of (e.g.) D000 to a place outside the first megabyte. the manual says that works (e.g. at 110000). and we can boot the pc as normale (software QEMM (newest rel.) and a Packet-Driver from the NCSA-Telnet V10.x). but the first EtherNet-Packet that is received crashes the PC and QEMM dumps out a screen full of information that the packet driver has an invaled RAM i/o. We know that the used RAM-Area is FREE and that there should be NO problem with other TSR or highloaded stuff. does anyone out there do such a job and can mail us a copy of his AUTOEXEC.BAT and CONFIG.SYS ? -- ___ ____________________________________ / / _____ ! jogl@tolkien.imsd.rwth-aachen.de ! __/__/_/ Gl ! Inst. f. Med. Stat. & Doku. (IMSD) ! /_/ !___Aachen__Germany__Europe__Earth___!
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 4 Nov 92 12:03:58 GMT From: craa85@ccsun.strath.ac.uk ( D.W.Stevenson) To: comp.protocols.tcp-ip Subject: RFC for proxy ARP?
Is there an RFC for proxy ARP? If not, is there any other source of info about this subject. I'm interested in the context of using proxy ARP for subnets as an interim measure until full subnetting can be implemented in all hosts. Proxy ARP is not a protocol mentioned in rfc1000. Thanks -- Dave Stevenson d.w.stevenson@strath.ac.uk Computer Centre Communications Tel : 44 41-552 4400 ext 3461 University of Strathclyde Glasgow, Scotland, U.K.
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Wed, 4 Nov 1992 14:06:07 GMT From: stewart@daffy.cis.udel.edu (John Stewart) To: comp.protocols.tcp-ip Subject: Re: How large is the DNS?
In article <92309.135530HANK@BARILVM.BITNET> HANK@BARILVM.BITNET (Hank Nussbacher) writes: >When discussing the DNS with someone who didn't know about the Internet >I explained that the DNS is a distributed database scattered throughout >the world. The person then asked me, how large was all the data put >together? I had no idea. Was it hundreds of megabytes or are we in the >gigabytes with the DNS? Is there any way to find out? I have no idea the size of the DNS database in terms of bytes. However, a number that I saw at INTEROP was that DNS currently contains 992,000 hosts. Note, however, that this number was found by doing an "inventory" of the DNS; as a result, any organization who has most of their DNS database hidden from the outside world doesn't have their hosts included in that number. /jws
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Wed, 4 Nov 1992 14:29:15 GMT From: scstech@solomon.technet.sg (Kenneth Soh) To: comp.protocols.tcp-ip Subject: Socket Programming Help
Hi ! I have a problem in TCP/IP programming. Hope someone can help. I am developing a client-server based application. I need to write a deamon program which resides on the server (SUN) and loops indefinitely to accept() client requests. The deamon will then fork() a process for every new incoming request from the client. I keep having "Address already in use" (errno 48) problem everytime I restart the deamon with the same port number - the bind() function returns error. The same port number seems to be "released" and re-usable after say, half an hour. I hence suspect that those child processes which I spawned might have inherited duplicated socket descriptors. The deamon program was then modified so that, upon connection, simply close() all the sockets and exits - no forking at all. I have the same problem even with this simpler version. My observation is that, if I start the deamon program and CTRL-C it while it is blocking at accept(), the above problem ceases and I can restart the deamon. In summary, only after a connection is made, the deamon will fail at bind() when re-executed. I guess the problem is in the use of accept() but I don't understand want actually went wrong. Below is my "program": ------------------------------------------------------ universal_socket = socket( AF_INET, SOCK_STREAM, 0 ); sin.sin_family = AF_INET; sin.sin_addr.s_addr = INADDR_ANY; sin.sin_port = atoi(argv[1]); <-- just a port number bind( universal_socket, &sin, sizeof( sin ) ) listen( universal_socket, 3 ); client_socket = accept( universal_socket, 0, 0 ); close( client_socket ); close( universal_socket ); ------------------------------------------------------ Also... can someone tell me when should we use shutdown() ? I've tried to use it but I don't really understand what it is used for. Regards, Kenneth Soh Singapore
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 4 Nov 92 16:40:30 GMT From: mc@math.math.mv.dupont.com (Matt Cunningham-Software Development) To: comp.protocols.tcp-ip Subject: Sun Generic Broadcasting
I am trying to find the proper broadcast IP address to send a packet (BOOTP packet to be specific - but the packet type is not important) to so that everyone on the network will receive it. At the point I am trying to send this broadcast packet I do not know any portion of my IP address. After consulting some documentation (Internetworking with TCP/IP, and others) I thought I knew where I should be sending the packet "255.255.255.255" which from what I understood meant 'all' hosts on 'all' networks. When the above was attempted I received a 'No Such Network' error message, I then tried "0.0.0.255" which from the documentation I believed meant 'all' hosts on 'this' network, however this approach resulted in the same error message, 'No Such Network'. Is there anybody out there who knows the address I should be sending to? The documentation seems to say that it is possible, diskless SUNS must do something similar (RARP) when booted from a power down state so this is encouraging. Is there a bug in the SunOS 4.1.x? Is there something besides setting the IP (broadcast) address of the UDP packet I'm sending that needs to be done? Thanks in Advance. Matt Cunningham Software Engineer EOP Group
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 4 Nov 92 16:47:33 GMT From: bob@comlab.gatech.edu (Bob Baggerman) To: comp.protocols.tcp-ip,comp.unix.aix Subject: Re: Netbios over TCP/IP on RS/6000
Andrew Sudell writes: >Does anyone know of a product which supports Netbios over TCP/IP >(RFC 1001/1002) on a RS/6000 running AIX 3.2? I need to move a >netbios client program to AIX and unfortunately it is running >over netbios and RFC 1001 implementations seem hard to come by. Syntax in Washington state (USA) makes and markets a line of networking products. They sell a LAN Manager server (actually an SMB server) for a number of Unix hosts. Their LMserver product includes an RFC1001/1002 NetBIOS implementation that can talk to PC TCP/IP NetBIOS implementations. Keep in mind, of course, that NetBIOS is a programming interface and not a protocol per se. And since by definition an application program talks to a NetBIOS driver by invoking a software interrupt on an Intel architecture processor, the API on your RISC box is going to be somewhat different. Still, this will allow your Unix box to talk to TCP/IP NetBIOS stacks on your local PC's. They also support OSI based NetBIOS and shortly will support Microsoft NetBEUI. Syntax 1501 West Valley Hwy North Suite 104 Auburn, WA USA 98001 206-838-2626 Ask for Bob Neary. I am not connected with Syntax, blah, blah, blah.... Bob -- Bob Baggerman ! bob.baggerman@gtri.gatech.edu Communications Laboratory ! bob@comlab.gatech.edu Georgia Tech Research Institute ! qseclrb@prism.gatech.edu Atlanta, GA 30332 USA ! 404-894-3525
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Wed, 4 Nov 1992 13:55:30 IST From: Hank Nussbacher <HANK@BARILVM.BITNET> To: comp.protocols.tcp-ip Subject: How large is the DNS?
When discussing the DNS with someone who didn't know about the Internet I explained that the DNS is a distributed database scattered throughout the world. The person then asked me, how large was all the data put together? I had no idea. Was it hundreds of megabytes or are we in the gigabytes with the DNS? Is there any way to find out? Thanks, Hank
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Wed, 4 Nov 1992 20:49:35 GMT From: wjw@pt.com (Wald Wojdak) To: comp.protocols.tcp-ip Subject: Lachman Associates TCP/IP for Motorola Unix V r3.2
Hello, Is there anyone familiar with a TCP/IP package from LACHMAN ASSOCIATES used by MOTOROLA in their D-Box UNIX V rev 3.2. I am working on Network Interface Device Driver and found that the information in the SYSTEM ADMINISTRATOR's QUIDE are not sufficient. There must be some Network Interface Programmers Guide or some document that describes how to interface Network Interface Device Driver to a LACHMAN ASSOCIATES TCP/IP used in Motorola D-Box UNIX V rev 3.2. Replies to: wjw@pt.com Thank you, Wald (wjw@pt.com) Waldemar Wojdak Performance Technologies Incorporated 315 Science Parkway Rochester, NY 14620 Tel: (716) 256-0200 ext 272 Fax: (716) 256-0791 -- __ Wald Wojdak, Performance Technologies Incorporated wjw@pt.com 315 Science Parkway, Rochester, New York 14620 uupsi!ptsys1!wjw
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Thu, 05 Nov 1992 02:10:09 GMT From: stevea@i88.isc.com (Steve Alexander) To: comp.protocols.tcp-ip Subject: Re: SCO TCP bandwidth problems - experiences sought
In article <chris.720420706@suite.sw.oz.au> chris@suite.sw.oz.au (Chris Maltby) writes:
>I am experiencing some surprising things with a system running
>SCO Unix 3.2.2 and SCO TCP 1.1.3f. We have recently upgraded
>the hardware from a 25MHz 486DX to 486DX2 (clock doubled) cpus,
>extra memory (16+16MB) and a 32bit 3com Ethernet card. The system
>is a microchannel box.
>So, here are my questions:
>
>Q1. Would upgrading to SCO TCP 1.2 improve the efficiency of this
> system or should we just throw out SCO and try something else?
Yes. 1.2 is easily twice as fast as 1.1.3. Also, many of the drivers on
the newest SCO LLI (3.1.0) disk are much faster as well.
>
>Q2. Does SCO TCP 1.2 require an upgrade from SCO UNIX 3.2.2?
Yes. You need to be running 3.2.4, but it's worth it. 3.2.4 is a much
better system (IMO).
>
>Q3. Is this sort of behaviour with installing a 486DX2 to be expected?
I don't know. The DX2 doesn't change the external speed of the CPU. TCP/IP
1.2 seems to be limited by I/O bandwith, since loopback speeds are much higher
than over-the-wire. This may mean that doubling the internal chip processing
speed won't help your problems.
I hope this helps.
--
Steve Alexander, Software Technologies Group | stevea@isc.com
INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 5 Nov 92 03:17:24 GMT From: sklower@diva.Berkeley.EDU (Keith Sklower) To: comp.protocols.tcp-ip Subject: Re: rpc process chewing up resources
In article <rsbtguk@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: }In article <49194@shamash.cdc.com>, gsa@easyaspi.udev.cdc.com (gary s anderson) writes: }> |> What would you do if you wanted to discover if ypbind is running? }Perhaps my point was not clear. } }By using TCP you avoid having to wait for a UDP time-out to expire when }things are not present. An alternative would be to use UDP, but connect() to the port; then when you do a send(), you can examine the error code to see if you get an ECONNREFUSED.
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 5 Nov 92 05:50:47 GMT From: bzs@world.std.com (Barry Shein) To: comp.protocols.tcp-ip Subject: Public Election Server Stats -- An Internet Application
World.std.com (The World) in conjunction with Adam Gaffin and the
Middlesex News ran a free, public election server. Starting about 8PM
on the night of the election major results were updated every twenty
minutes or so.
These results were accessible to anyone on the internet by simply
typing:
finger election@world.std.com
which reflected back a screenful or two of info.
This kept our system (a Sun4/280 with 80MB, not a small system) very
busy. In fact, early in the day the system load jumped to over 200
(anything much over 20 would be considered quite overloaded.) In
response we made some drastic modifications to the finger daemon
software which made things only slightly miserable but we muddled
through.
Here are some stats from the experience:
* Total queries served over approximately 36 hours:
49,419
* Domains served with counts per domain:
Domain Count Type
edu 28001 educational
com 12000 commercial
uk 2444 United Kingdom
se 897 Sweden
gov 848 Government
ca 808 Canada
org 770 Unspecified Organization (usually non-profit)
au 769 Australia
il 457 Israel
net 434 Network Service Org
nz 226 New Zealand
mil 155 Military
de 140 Germany
fi 105 Finland
no 75 Norway
jp 73 Japan
fr 69 France
kr 64 Korea
dk 59 Denmark
sg 58 Singapore
us 47 United States (other than many edu, com, etc)
nl 47 Netherlands (Holland)
ch 34 Switzerland
pt 29 Portugal
at 27 Austria
mx 24 Mexico
ee 17 Estonia
in 16 India
hk 10 Hong Kong
cl 10 Chile
pl 8 Poland
it 8 Italy
hu 5 Hungary
is 2 Iceland
za 1 Republic of South Africa
ve 1 Venezuela
be 1 Belgium
(counts don't add up because hosts who's numeric address could not be
resolved were elided from this report but not the total count.)
* Requests per hour, Nov 3, midnight thru Nov 4, noon:
Hour Count
00 54
01 47
02 37
03 56
04 34
05 36
06 46
07 82
08 189
09 470
10 644
11 202
12 40
13 85
14 466
15 1331
16 1825
17 2145
18 2256
19 4763
20 6044
21 6341
22 5040
23 3503
00 2232
01 1341
02 795
03 596
04 503
05 667
06 730
07 865
08 1151
09 1330
10 1142
11 1036
12 220
(don't ask me why so many people queried for results before the
election even began, perhaps they have more faith in computers than is
reasonably healthy.)
* Sample (last) report:
MIDDLESEX NEWS ELECTION NETWORK
3:50 a.m. Final results of the night. Good night/morning,
all!
For complete results and in-depth news and analysis of
the results, pick up Wednesday's Middlesex News, on sale
throughout MetroWest.
``I accept tonight the responsibility you have given to me,
to be the leader of this, the greatest country in human
history,'' Clinton said. ``This is a remarkable coalition
for change. I ask you to keep that commitment as we move
>from the election to governing.''
Bush promised a smooth transition of power and wished
Clinton well in the White House. ``It's over,'' he whispered
to his wife Barbara.
With 88 percent of the nation's precincts reporting.
Clinton 38,860,586 - 43 percent
Has won 29 states and the District of Columbia with 349 ev.
Leads in 3 states with 16 electoral votes
Bush 34,349,041 - 38 percent
Has won 15 states with 132 electoral votes
Leads in 3 states with 41 electoral votes
Perot 16,835,474 - 19 percent
Has won 0 state with 0 electoral votes
Leads in 0 state with 0 electoral votes
MASSACHUSETTS
1,777 of 2,138 precincts - 83 percent
George Bush, GOP (i) 663,212 - 29 percent
x-Bill Clinton, Dem 1,084,350 - 48 percent
H.Ross Perot, Ind 514,454 - 23 percent
Question 1 Tobacco Tax
747 of 2,138 precincts - 35 percent
x-Yes, 589,725 - 55 percent
No, 480,736 - 45 percent
Question 2 Corporate Taxes
749 of 2,138 precincts - 35 percent
x-Yes, 555,940 - 55 percent
No, 455,437 - 45 percent
Question 3 Recycling
748 of 2,138 precincts - 35 percent
Yes, 432,381 - 40 percent
x-No, 638,730 - 60 percent
Question 4 Oil & Hazards Tax
751 of 2,138 precincts - 35 percent
Yes, 419,733 - 40 percent
x-No, 621,870 - 60 percent
U.S. House District 2
192 of 212 precincts - 91 percent
x-Richard E. Neal, Dem (i) 117,009 - 63 percent
Anthony W. Ravosa Jr., GOP 68,250 - 37 percent
U.S. House District 3
155 of 205 precincts - 76 percent
Joseph D. Early, Dem (i) 87,925 - 45 percent
x-Peter I. Blute, GOP 107,543 - 55 percent
U.S. House District 4
142 of 200 precincts - 71 percent
x-Barney Frank, Dem (i) 143,996 - 72 percent
Edward J. McCormick III, GOP 54,810 - 28 percent
U.S. House District 5
144 of 196 precincts - 73 percent
Paul W. Cronin, GOP 77,649 - 45 percent
x-Martin T. Meehan, Dem 93,404 - 55 percent
U.S. House District 7
198 of 223 precincts - 89 percent
x-Edward J. Markey, Dem (i) 160,251 - 71 percent
Stephen A. Sohn, GOP 66,567 - 29 percent
U.S. House District 8
141 of 233 precincts - 61 percent
x-Joseph P. Kennedy, Dem (i) 76,948 - 83 percent
Alice Harriett Nakash, Unr 15,823 - 17 percent
Midlsx,Norflk&Worcstr State Senate
David P. Magnani, Dem 36,034
Thomas P. Tierney, GOP 22,144
1st Suffolk & Norfolk
16 of 58 precincts - 28 percent
Christopher M. Lane, GOP (i) 12,495 - 53 percent
Marian Walsh, Dem 11,138 - 47 percent
Middlesex & Worcester state senate
16 of 49 precincts - 33 percent
Robert A. Durand, Dem (i) 14,560 - 54 percent
William M. Monnie, GOP 12,633 - 46 percent
Norfolk,Bristol & Middlesex state senate
33 of 47 precincts - 70 percent
David H. Locke, GOP (i) 20,625 - 40 percent
Cheryl A. Jacques, Dem 31,234 - 60 percent
1st Worcester & Middlesex State Senate
Hopkinton, Hopedale, Southboro, Upton reporting
Matthew John Amorello, GOP (i) 9984
Guy W. Glodis, Dem 6788
11th Worcester
Northboro, Shrewsbury reporting
Gauch, GOP 9,938
Whitney, Dem 9,166
Middlesex & Worcester State Senate
Robert A. Durand, Dem (i) 4379
William M. Monnie, GOP 250
4th Middlesex state rep
all precincts reporting
Valianti, Dem (i), 9,318
Carlman, GOP 6179
5th Middlesex
All precincts reporting
Douglas W. Stoddart, GOP (i) 11,091
Megan H. Christopher, Dem 7764
6th Middlesex
All precincts reporting
Gray, Dem (i) 10,729
Havel, GOP 7,075
7th Middlesex State Rep
All precincts reporting
Stefanini, Dem 9,981
Stewart, GOP 5,778
8th Middlesex
9 of 12 precincts - 75 percent
Barbara Gardner, Dem (i) 10,982 - 67 percent
David W. Henderson, GOP 5,459 - 33 percent
9th Middlesex
1 of 11 precincts - 9 percent
David F. Gately, Unr (i) 778 - 55 percent
Kathleen B. McMenimen, Dem 632 - 45 percent
13th Middlesex State Rep
Sudbury, Wayland reporting
Hasty Evans (i), GOP, 10,238
Vicki Hammel, Dem 5,502
9th Worcester State Rep.
All precincts reporting
Platt, Dem, 8,733
Peterson, GOP 8,153
Delle, I, 3,017
10th Norfolk State Rep.
All precincts reporting
Ranieri, Dem, 15,496
Sawyer, IVP, 5,009
14th Norfolk State Rep.
All precincts reporting
Haas, Dem, 8515
Madden, GOP, 10,142
--
-Barry Shein
Software Tool & Die | bzs@world.std.com | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Thu, 5 Nov 1992 11:44:04 GMT From: deraadt@newt.cuc.ab.ca (Theo de Raadt) To: comp.protocols.tcp-ip Subject: Re: rpc process chewing up resources
I'm currently implimenting YP client functionality for 386bsd. So far,
it's been an enjoyable and frustrating time....
In article <49256@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
> |> > |> > sits within the "yp" library code (you need to ask SUN why "pinging"
> |> > |> > the portmapper from within "yp" is useful). This has the wonderful
> |> > |> Hmmmph!
> |> > |> What would you do if you wanted to discover if ypbind is running?
Well, on some systems (including my code at the moment) that's exactly
why TCP is used. It's faster than UDP.
My first code used UDP to find out if ypbind was running. Well, if you
don't get an answer, even in talking to 127.0.0.1, well, the kernel's
buffers could just be swamped at the moment. So you have to try a few
times. Not pretty.
So, I started using TCP. Immediate response yes/no whether YP is
running. I had no real concerns with whether the portmapper is
running.
I'm have a Sun too. A few minutes ago, I went and looked to see why
the file /etc/ypbind.lock exist... a bit of snooping and following a
hunch...
4835 -rw------- 1 root 0 Nov 2 21:46 /etc/ypbind.lock
^^^^
inode
pstat -i | grep 4835
f23f9a8 R 7, 0 4835 100600 1 0 0 E 2 0 1 VREG
^^^
That little 'E' is an exclusive lock.
Could someone explain exactly what is going on here? What I suspect
follows: ypbind maintains the exclusive lock on /etc/ypbind.lock
Processes that are interested can find out if ypbind is running by
doing a lockf(fd, F_TEST). Sun's ypbind also puts an exclusive lock
on /var/yp/binding/domainname.2 and /var/yp/binding/domainname.1. I
suspect the 2 is YPBINDVERS.
Just trying to get a flock() on that file seems to work. This is so much
easier than what it appears the entire argument here is about.
Here's what happens if I trace a program that needs to check YP.
open ("/var/yp/binding/cuc.ab.ca.2", 0, 036736173730) = 4
flock (4, 06) = -1 EWOULDBLOCK (Operation would block)
mmap (0x8ab8, 14, 0x1, 0x80000001, 4, 0) = 0xf7710000
close (4) = 0
Aha. The fact that the flock() failed tells us that ypbind is running.
Sun places into the binding file the actual (struct sockaddr_in) at
which the current ypserver can be found (It could be ypbind's address,
but it makes more sense to be ypserv's address). So they mmap() the
(struct sockaddr_in) and continue.
> |> >
> |> > I would send a UDP RPC request to the portmapper to find out
> |> > if ypbind was registered. The problem is that there is code
> |> > which creates a "dummy" TCP connection just to see if the
> |> > portmapper is running (i.e. doesn't trust UDP time-outs as
> |> > sufficient evidence that the portmapper is not running).
I would not trust a UDP timeout on "localhost" as meaning that the
portmapper is dead. It might take 5 seconds for a busy portmapper to
answer. Someone in Timbuktu, at the end of a very slow link, may have
been spraying the portmapper. Packets may have convoyed, and the
portmapper may be swamped! How long are you going to wait around?
> |> > If the connection succeeds, it is immediately closed and then
> |> > the UDP RPC request is made to the portmapper to get the
> |> > information about ypbind.
> |>
> |> Perhaps my point was not clear.
> |>
> |> By using TCP you avoid having to wait for a UDP time-out to expire when
> |> things are not present. Which would make you more unhappy? Having an
> |> anonymous TCP port number tied up for a little while or having to wait
> |> a large part of a second (or more if you allow remote access over slow
> |> links) to discover that the portmapper is not running?
With TCP, your connection will succeed immediately, well, as long as
the listen queue has room for you....
Really, I prefer Sun's method of checking for yellow. A flock() on a
locked file means you are talking to an inode that is already in the
buffer cache. That's got to be faster and more reliable than talking
to portmap & ypbind.
Anyways, I'm going to impliment my routines much like Sun's did!
Only one thing bothers me with the RPC programming I am doing. Sun's
ypbind is not multithreaded; rather, it forks when it gets a request
for a currently unbound domain. I decided to make my ypbind much more
multithreaded. What I have come to discover to my disgust is that if
you wish to write a properly multithreaded RPC application you have to
give up all the juicy RPC and SVC routines and dig right into the XDR
level. What a pain. And, boy, I could scream because I have found no
way to access msg->msg_xid from the SVC/RPC level! For a proper
multi-threaded application, you are going to need to save a copy of
that for the later reply!
<tdr.
--
This space not left unintentionally unblank. deraadt@newt.cuc.ab.ca
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 5 Nov 92 12:28:44 GMT From: sweeney@Ingres.COM (Tony Sweeney) To: comp.protocols.tcp-ip Subject: Re: TCP connect
In article <Bx66Jn.D6@ushiva.wariat.org> raw@ushiva.wariat.org (Roland Wilcher) writes: > >Some time ago there was a question about checking for a TCP connect >to a possibly non functioning machine without the long wait. >An answer was posted using connect with nonblocking mode. I don't >have that article now but would appreciate any pointers . Target >system would be Esix SVR4 using the socket libraries and TCP/IP. > >-- >Lack of skill dictates economy of style. raw@ushiva.ncoast.org >- Joey Ramone raw@ushiva.wariat.org >Roland A. Wilcher 6207 Luther Ave. Cleve Oh. 44103 >---------------------------------------------------------------------------
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 5 Nov 92 13:02:41 GMT From: mick@horga.ruhr.de (Michael Reichelt) To: comp.protocols.tcp-ip Subject: Tecnical question
Hi, does anybody know if there exists a possibility to log all activities caused by ip-requests that build up an IP connection to other networks than our own ? We have to get a list of all our costs that get up because of outgoing ip packets and because of this I am looking for a program that logs all type of ip activity to a special file or better a software package that tells me about the costs of the connections directly. Thanks, Michael. ps. please send me an answer to mick@macrotk.uucp
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 5 Nov 92 15:20:57 GMT From: a20@nikhefh.nikhef.nl (Marten Terpstra) To: comp.protocols.tcp-ip Subject: Re: How large is the DNS? (around 150 Mbytes)
>>When discussing the DNS with someone who didn't know about the Internet >>I explained that the DNS is a distributed database scattered throughout >>the world. The person then asked me, how large was all the data put >>together? I had no idea. Was it hundreds of megabytes or are we in the >>gigabytes with the DNS? Is there any way to find out? > >I have no idea the size of the DNS database in terms of bytes. >However, a number that I saw at INTEROP was that DNS currently >contains 992,000 hosts. Note, however, that this number was >found by doing an "inventory" of the DNS; as a result, any >organization who has most of their DNS database hidden from >the outside world doesn't have their hosts included in that >number. We do a monthly hostcount for Europe. For that purpose I pull *every* zone file from all properly registered DNSes in Europe (Europe in our sense includes Israel and Tunesia, and the Baltic States and other Ex-Soviet States). The total zone output for this comes down to around 32 Mbytes of DNS info. Considering the fact that there are 250,000 hosts in Europe according to our last count, and 1,1 Million hosts worldwide, according to the last global hostcount done at SRI, the total amount of information available in the DNS on that part of the Internet that we can all reach, must be something in the order of 150 Mbytes. As said above, organisations with their DNS hidden from the "normal" Internet are not counted, and therefore their DNS size unknown. Cheers, -Marten RIPE Network Coordination Centre
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Thu, 5 Nov 1992 15:41:16 GMT From: ronf@panther3.panther.mot.com (Ron Feigen) To: comp.protocols.tcp-ip Subject: Re: TCP connect
In article <Bx66Jn.D6@ushiva.wariat.org> raw@ushiva.wariat.org (Roland Wilcher) writes: > >Some time ago there was a question about checking for a TCP connect >to a possibly non functioning machine without the long wait. >An answer was posted using connect with nonblocking mode. I don't >have that article now but would appreciate any pointers . Target >system would be Esix SVR4 using the socket libraries and TCP/IP. > >-- >Lack of skill dictates economy of style. raw@ushiva.ncoast.org >- Joey Ramone raw@ushiva.wariat.org >Roland A. Wilcher 6207 Luther Ave. Cleve Oh. 44103 >--------------------------------------------------------------------------- If the TCP socket is non-blocking the file descriptor will be ready for writing when the connection is complete. There are several ways to check to see if the socket is ready for writing, select() is one of them. Don't forget to check the errno after connect(). You are expecting EINPROGRESS, but you need to be prepared to handle other errors. -- > Ron Feigen ronf@panther.mot.com
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Thu, 5 Nov 1992 16:53:49 GMT From: alech@hpindda.cup.hp.com (Alec Henderson) To: comp.protocols.tcp-ip Subject: Re: Netbios over TCP/IP on RS/6000
>Does anyone know of a product which supports Netbios over TCP/IP
>(RFC 1001/1002) on a RS/6000 running AIX 3.2? I need to move a
>netbios client program to AIX and unfortunately it is running
>over netbios and RFC 1001 implementations seem hard to come by.
Try contacting:
Micro Computer Systems (MCS)
2300 Valley View Lane, Suite 800
Irving, Texas 75062
214-659-1514
MCS sells a variety of NetBIOS/NetBEUI implementations for various
network transports on both DOS and UNIX.
Note that this is not an official recommendation by Hewlett-Packard;
HP does not sell or support MCS's products.
Regards,
Alec Henderson
Telephone: T/408-447-3965 Hewlett-Packard
FAX: 408-447-3660 Information Networks Division
E-mail: alech@cup.hp.com 19420 Homestead Road MS 43L9
HPDesk: Alec Henderson/HP6600/1B Cupertino, CA 95014 (USA)
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 5 Nov 92 17:07:59 GMT From: jkors@media03.UUCP (Jacques Kors) To: comp.unix.misc,comp.protocols.tcp-ip,comp.lang.postscript Subject: problems tfping to a rip
Can anyone give me some advice on the following problem:
One of our customers has a configuration with an Intel 520 MBII server
running unix SYSV r3.2 and three Linotype Postscript RIPs (rip30) connected
via ethernet.
File are sent from the server to the rips using TFTP. These files are
somewhere between 1Mb and 4Mb in size.
several times a day this communication fails. When this happens the two
machines (server and rip) keep talking to each other but they don't seem
to make any progress. Usually the operator terminates such a print job,
after about 20 minutes, bij resetting the rip and then retransmits the file.
Since this compagny is in the newspaper business they can't really afford
this loss of time.
Every time this happens it turns out that a given packet is not accepted
by the rip. The server keeps retransmitting this packet and the rip keeps
rejecting it. It then takes them about half an hour to decide that there is
no use in going on.
The reason seems to be that the UDP checksum is wrong. normally this
checksum is correct, but the troublesome packets always have 0xFFFF for
checksum. if my calculations are correct it should be 0x0 instead.
Some testing at our site has shown that Interactive SYSV R3.2 v2.0.2
has the same effects. Our sun servers don't even bother to generate a
checksum. All unix boxes we tried don't seem to check this UDP checksum
at the receiving end.
now for the questions:
- am i right on the checksum bit
- Does anybody use a simular setup
what are your experiences
- Has anybody encountered this problem
- What is your solution
- Is there some workaround possible
it would be a great improvement if the problem could be detected
earlier without having to wait for nothing ( and 20 minutes ).
- Hav you got any suggestions
Thanks in advance for any suggestions/help/information etc.....,
Jacques
----
below you'll find an ascii/hex dump of an erroneous packet:
*Packet 5623 (558 bytes) at T + 665.9710 secs, Delta t 0.0209 secs
Destination = RIP03 , Source = GBD02 , Type = 0800
VER/IHL = 45, TOS = 00, Len = 0220, ID = 4108, FLG/FRG = 0000, TTL = 1E,
Prtcl = 11, IP Chksum = C6F9, IP Srce = C05C8907, IP Dest = C05C890B,
Srce Port = 0D38, Dest Port = 065C, Len = 020C, UDP Chksum = FFFF
0000: 00 03 0C 95 41 31 46 31 45 31 44 32 32 32 31 32 ....A1F1E1D22212
0010: 30 32 30 32 30 32 30 32 30 31 42 32 32 31 44 31 0202020201B221D1
0020: 45 31 44 31 43 32 32 31 44 31 44 32 32 32 32 31 E1D1C221D1D22221
0030: 44 31 43 32 36 31 41 31 43 32 31 32 32 31 43 31 D1C261A1C21221C1
0040: 44 31 43 32 31 32 30 31 46 0D 0A 32 35 32 30 32 D1C21201F..25202
0050: 30 32 30 32 30 32 30 32 30 32 33 32 36 32 35 32 0202020202326252
0060: 31 31 44 32 32 32 32 31 44 32 34 31 44 32 34 31 11D22221D241D241
0070: 45 32 30 31 46 32 34 32 31 32 36 32 30 32 32 31 E201F24212620221
0080: 45 31 45 32 33 32 32 32 32 32 32 32 32 32 34 31 E1E2322222222241
0090: 42 31 31 35 43 39 30 36 30 33 34 0D 0A 33 35 31 B115C906034..351
00A0: 46 31 45 31 43 31 44 31 44 31 45 31 45 31 45 31 F1E1C1D1D1E1E1E1
00B0: 45 31 44 32 33 31 44 31 43 32 31 31 43 31 43 32 E1D231D1C211C1C2
00C0: 31 31 46 32 34 32 32 32 31 32 36 31 42 31 37 32 11F242221261B172
00D0: 31 45 39 44 34 43 38 43 37 43 38 43 38 43 32 43 1E9D4C8C7C8C8C2C
00E0: 34 43 36 43 30 43 34 43 34 42 30 42 41 0D 0A 41 4C6C0C4C4B0BA..A
00F0: 44 36 32 31 32 32 31 32 34 32 33 32 41 32 42 31 D62122124232A2B1
0100: 46 32 32 32 32 32 32 32 37 32 32 32 32 32 33 32 F222222272222232
0110: 32 32 31 32 45 32 37 31 45 32 32 31 39 31 41 31 2212E271E22191A1
0120: 43 31 43 31 43 31 42 32 30 31 41 31 35 31 42 31 C1C1C1B201A151B1
0130: 41 31 46 31 46 31 39 31 46 31 46 31 41 31 42 0D A1F1F191F1F1A1B.
0140: 0A 31 41 32 30 31 41 31 42 32 30 32 30 31 42 31 .1A201A1B20201B1
0150: 43 31 38 31 38 31 43 31 42 31 42 32 30 31 43 31 C18181C1B1B201C1
0160: 43 31 43 31 41 31 45 32 32 31 42 31 46 32 33 32 C1C1A1E221B1F232
0170: 32 32 30 32 33 32 39 32 39 32 34 32 33 31 43 31 22023292924231C1
0180: 41 31 43 31 43 31 44 31 44 31 38 31 38 31 39 31 A1C1C1D1D1818191
0190: 38 0D 0A 31 44 31 43 31 43 31 44 31 38 31 44 31 8..1D1C1C1D181D1
01A0: 44 31 38 31 44 31 43 31 43 31 43 31 42 32 31 31 D181D1C1C1C1B211
01B0: 43 31 44 31 38 31 38 31 45 31 38 31 39 31 39 31 C1D18181E1819191
01C0: 38 31 45 31 37 31 44 31 38 31 38 31 44 31 44 31 81E171D18181D1D1
01D0: 39 31 41 31 38 31 45 31 37 31 44 31 44 31 37 31 91A181E171D1D171
01E0: 45 31 38 0D 0A 31 39 31 44 31 43 31 36 31 42 32 E18..191D1C161B2
01F0: 30 31 42 31 44 31 37 31 42 32 34 31 45 31 45 31 01B1D171B241E1E1
0200: 45 31 45 31 E1E1
----
+-----------------+---------------------------------+-------------------+
\ Jacques Kors \ email: jkors@media01.UUCP \ Disclaimer: \
\ Mediasystemen \ ...!sun4nl!media01!jkors \ you would look \
\ P.O.Box 4932 \ \ funny too, if you \
\ 2003 EX Haarlem \ voice: + 31-23-319075 \ were RIPped \
\ The Netherlands \ fax : + 31-23-315210 \ \
+-----------------+---------------------------------+-------------------+
--
+-----------------+---------------------------------+-------------------+
\ Jacques Kors \ email: jkors@media01.UUCP \ Disclaimer: \
\ Mediasystemen \ ...!sun4nl!media01!jkors \ you would look \
\ P.O.Box 4932 \ \ funny too, if you \
\ 2003 EX Haarlem \ voice: + 31-23-319075 \ were JPEGged \
\ The Netherlands \ fax : + 31-23-315210 \ \
+-----------------+---------------------------------+-------------------+
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 5 Nov 92 18:57:00 GMT From: M20923@MBVM.Mitre.Org (Daniel Sorensen) To: bit.listserv.ibmtcp-l,comp.protocols.tcpip Subject: Re: Remote printing from JES2 spool
In article <IBMTCP-L%92110411450390@PUCC.PRINCETON.EDU> David Condrey 656-2733 <DAVIDC@CLEMSON.BITNET> writes: > >At the last SHARE, I brought up the fact that our TSO users are used to >printing by releasing sysout off of spool (in addition to using a TSO >"print" command) and that I wanted to allow these users to be able to >use printers remote to MVS. > >The specific problem that we are having is that we have a plotter on >the network that our MVS users want to plot to via SAS/GRAPH. SAS users >run batch jobs and release the output from spool (in our case using IOF). > >The foremost answer seems to be defining a remote printer to LPD. >However there is currently no way for LPD to get output from spool >and do the right things with it (retry on failure). > >When I mentioned this, someone in the back stood up and said that he was >solving this using a product called VPS (sic). Since then, we have >bought VPS. I have not personally looked at it, but our network manager >says that the VPS people indicated there is no solution to our problem. > >My question is: if you have solved this problem (or have any thoughts >on it), I'd really like to hear them. If the person that mentioned VPS >at the TCP/IP FFA is listening, I'd like to ask a few questions. > >Thanks everyone. >-David >------------------------------------------------------------------------------- >|David S. Condrey ___ ______ _____ Bitnet: DAVIDC@CLEMSON | >|MVS Systems Programmer | \ \_____ | Internet: DAVIDC@CLEMSON.EDU | >|Clemson University |__/ _____/ |____ Phone: (803) 656-2733 | >------------------------------------------------------------------------------- It seems from the responses so far that VM shops have resolved the batch network printing problem by using service machines. In fact, MITRE is currently the same technique. Our MVS machine sends the file to a VM service machine, which in turn sends the files out using LPR. The problem is that we will soon be phasing out the VM machine. Has anyone found a MVS only solution to batch network printing? Even if VPS can use LPR in batch, it is too expensive. If there is no TCP/IP solution to network printing, our next solution would be to look into NJE-type links to an RS/6000 and letting it deal with the actual printing. Any ideas? Daniel Sorensen IBM Systems Group The MITRE Corporation (617) 271-2726 What, me speak for MITRE? Ha!
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 5 Nov 92 19:23:45 GMT From: M20923@MBVM.Mitre.Org (Daniel Sorensen) To: comp.protocols.tcp-ip Subject: Re: Remote printing from JES2 spool
In article <IBMTCP-L%92110411450390@PUCC.PRINCETON.EDU> David Condrey 656-2733 <DAVIDC@CLEMSON.BITNET> writes: > >At the last SHARE, I brought up the fact that our TSO users are used to >printing by releasing sysout off of spool (in addition to using a TSO >"print" command) and that I wanted to allow these users to be able to >use printers remote to MVS. > >The specific problem that we are having is that we have a plotter on >the network that our MVS users want to plot to via SAS/GRAPH. SAS users >run batch jobs and release the output from spool (in our case using IOF). > >The foremost answer seems to be defining a remote printer to LPD. >However there is currently no way for LPD to get output from spool >and do the right things with it (retry on failure). > >When I mentioned this, someone in the back stood up and said that he was >solving this using a product called VPS (sic). Since then, we have >bought VPS. I have not personally looked at it, but our network manager >says that the VPS people indicated there is no solution to our problem. > >My question is: if you have solved this problem (or have any thoughts >on it), I'd really like to hear them. If the person that mentioned VPS >at the TCP/IP FFA is listening, I'd like to ask a few questions. > >Thanks everyone. >-David >------------------------------------------------------------------------------- >|David S. Condrey ___ ______ _____ Bitnet: DAVIDC@CLEMSON | >|MVS Systems Programmer | \ \_____ | Internet: DAVIDC@CLEMSON.EDU | >|Clemson University |__/ _____/ |____ Phone: (803) 656-2733 | >------------------------------------------------------------------------------- It seems from the responses so far that VM shops have resolved the batch network printing problem by using service machines. In fact, MITRE is currently the same technique. Our MVS machine sends the file to a VM service machine, which in turn sends the files out using LPR. The problem is that we will soon be phasing out the VM machine. Has anyone found a MVS only solution to batch network printing? Even if VPS can use LPR in batch, it is too expensive. If there is no TCP/IP solution to network printing, our next solution would be to look into NJE-type links to an RS/6000 and letting it deal with the actual printing. Any ideas? Daniel Sorensen IBM Systems Group The MITRE Corporation (617) 271-2726 What, me speak for MITRE? Ha!
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Thu, 5 Nov 1992 19:35:18 GMT From: donp@novell.com (don provan) To: comp.protocols.tcp-ip Subject: Re: Detecting Dropped Sockets (Why is this hard on PC's?)
In article <49191@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes: >I don't disagree with your statements, however, I was curious about >the systems you execute on. Specifically, when a process is >terminated, what happens to the open file descriptors? So your claim is that if i use such an operating system, then i must agree this behavior is correct. Sorry. Operating systems that aren't brain dead (most, unfortunately, no longer in production) understand that the file system's state shouldn't be changed unless the file manipulation is completed, which the application typically indicates by explicitly closing the file. On such operating systems, terminating a process (or crashing the machine, for that matter) leaves the *original* file unchanged, or leaves no file at all if there was no original file. In almost all cases, leaving a partially written file is absolutely the least desirable end result. But, as most everyone else, i'm forced to use both UNIX and DOS even though they both have this fault. >Aren't they typically "closed"? Doesn't TCP typically map this into >a "normal connection close"? And your claim here is that since UNIX believes that it understands how to gracefully close file descriptors, then it's OK for it to close TCP connections gracefully as well. Hard to argue with that if you truely believe UNIX defines TCP/IP. Even so, it's a shame to lose the useful meaning of a graceful close just because one common operating system thought it knew everything there was to know about any possible TCP application. >I assume that you would inject an RST in cases >where you could prove "abnormal termination". Can you cite an RFC >which gives guidelines as to when TCP should inject an RST on behalf >of the application? I'm sure we would benefit from clean, consistent >implementations. To my knowledge, no RFC deals with what TCP should do if its application disappears. Personally, i think that's because no one ever conceived of the UNIX behavior as a possibility, anymore than they thought an operating system might tend to send "Th-Th-That's all folks!" spontaneously down the TCP pipe. But if we take RFC-793 as gospel (and why not?), since it doesn't mention process termination at all, my conclusion then is that the TCP implementation should do nothing: the connection simply disappears. No FIN, no RST, no nothing. Then any subsequent packets from the other end of the connection would be for a non-existent connection, so TCP would respond with a RST. In practice, in order to expedite the remote node's awareness of the situation, TCP sends a RST immediately. This isn't significantly different than doing nothing, since it's just what would happen if an old packet arrived or something like that. don provan donp@novell.com
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Thu, 5 Nov 1992 20:19:41 GMT From: dank@blacks.jpl.nasa.gov (Daniel R. Kegel) To: comp.protocols.tcp-ip Subject: Should connect() block after setting NDELAY?
Hi all,
I'm writing an application that opens sockets to many servers in parallel
before sending out a query to each server (also in parallel). It sets
the sockets into nonblocking mode before the connect() as follows:
int flags;
#ifdef USE_FIONBIO
flags=1;
netioctl(qp->fds, FIONBIO, (char *)&flags);
#else
flags = fcntl(qp->fds, F_GETFL, 0);
#ifdef USE_O_NDELAY
flags |= O_NDELAY;
#else
flags |= FNDELAY;
#endif
fcntl(qp->fds, F_SETFL, &flags);
#endif
The problem is, under SunOS 4.1.1, connect() then blocks until a
accept, reject, or defer response comes back from the server.
This can take several seconds if the Internet is being slow.
The local Sun guy was able to see this in the source code, but does not
consider it a bug. What do you all think- is it reasonable for connect()
to block for several seconds when the socket is supposedly in nonblocking
mode?
- Dan Kegel (dank@blacks.jpl.nasa.gov)
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Thu, 5 Nov 1992 21:07:59 GMT From: bryan@sphinx.phys.Virginia.EDU (bryan wright) To: comp.protocols.tcp-ip,comp.protocols.nfs Subject: Problems with PC-NFS and pktd.sys
Hi folks, I've just installed PC-NFS version 4.0. Everything works fine if I use the WD8003E.SYS driver, but when I try to substitute PKTD.SYS and the WD8003E.COM packet driver, NFS refuses to start. I get the message: NFS000F : PC-NFS is disabled. (Can't start network. Check configuration.) I think WD8003E.COM is OK, since NCSA telnet has no problems talking to the outside world. I've created a minimal CONFIG.SYS and AUTOEXEC.BAT for test purposes. These files are appended below. Am I doing something stupid? Thanks in advance, Bryan CONFIG.SYS ================================================================= BREAK=ON BUFFERS=30,8 FCBS=30,10 FILES=40 STACKS=0,0 DEVICE=C:\DOS50\ANSI.SYS /X DEVICE=C:\UTIL\MOUSE\MOUSE.SYS INSTALL=C:\NET\DRIVERS\WD8003E.COM -W 0X60 5 0X280 0XD000 DEVICE=C:\NFS\PCNFS.SYS DEVICE=C:\NFS\SOCKDRV.SYS rem DEVICE=C:\NFS\WD8003E.SYS /I5 DEVICE=C:\NFS\PKTD.SYS SHELL=C:\COMMAND.COM /P /E:1024 LASTDRIVE=V AUTOEXEC.BAT ================================================================ @ECHO OFF PATH C:\;C:\DOS50;C:\BATCH DOSKEY/INSERT PROMPT $P$G SET TEMP=C:\DOS50\TEMP =============================================================================
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Thu, 5 Nov 1992 21:17:58 GMT From: rjberke@berke.itg.ti.com (Richard Berke) To: comp.protocols.tcp-ip Subject: Transfer of 100's of MBytes files
What are some customers' experiences with transfering large files between sites using FTP? How often (1 out of 20?) do you run into aborted transfers that have to be restarted from scratch? Have you been able to distinguish what portion of those failures are due to disk issues, circuit failures, or protocol implementations? I am frequently asked about the reliability of using FTP to move files and/or sets of files that are 200-400 Mbytes, and there's interest in some means of recovering from a disruption in the middle of a transfer. I'm sensitive to disruptions, but wary of exotic schemes to recover. Since our world-wide links are as small as 56 Kbits/sec, transmission times are significant. Good throughput for FTP (not best case) is about 5 Kbytes per second. 200-400 Mbytes takes 1-3 hours or more. Detection of failed transfers may be delayed, further adding to wall clock time taken to accomplish the overall transfers. I've heard that protocols exist for transfers that use checkpoints and can restart. I've never heard of mainstream suppliers for them. Are they available? How necessary are they, compared to FTP? Thanks, Richard Berke RBRK Richard.Berke@lobby.ti.com (214) 575-2828 Texas Instruments Plano, Texas -------------------------------------------------------------------------
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Thu, 5 Nov 1992 21:24:24 GMT From: fsgreen@dredd.lerc.nasa.gov (Doug Greenwald) To: comp.protocols.tcp-ip Subject: Need Ethernet types/IP Frame and Header Formats
Howdy, I'm writing a small network analyzer to gather statistics. I have most of the IP protocols in Comer's book done but am having problems finding information regarding a bunch of the ethernet types. I'm seeing a LOT of ethernet types that fall into the "experimental" range of RFC 1060 and am wondering if there are any more complete lists of assigned numbers. I need the type field of the ethernet frame for general statistics gathering and would like the higher layer protocol packet formats for completeness. Any pointers to references or information you could shed would be appreciated. For those interested in the program, I'm writing it for Sun workstations. If responses warrant (and the program doesn't turn into a load of crap), I'll make it available. -- Doug Greenwald fsgreen@icomp01.lerc.nasa.gov Sun System Administrator (216) 433 5965 ICOMP, NASA Lewis Research Center
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: Thu, 5 Nov 92 21:30:39 GMT From: braun@dri.com (Karl T. Braun (kral)) To: ca.unix,comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards,comp.dcom.lans.ethernet Subject: IP Remap Experiences wanted
I am looking for any information on large scale institutional IP addresses remapping - papers, anecdotes, sage advise, whatever. Please email anything you care to contribute to braun@novell.com I am preparing to undertake this "exciting" adventure myself, and hope to gain from other's experiences. I will, in turn, document my own experiences and include what useful info I gather from the net with appropriate references. Thanx, -- kral 408/645-2031 braun@dri.com Network Scapegoat in Training Novell/DSG That's the whole problem with science. You've got a bunch of empiricists trying to describe things of unimaginable wonder." - Calvin
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Thu, 5 Nov 1992 21:47:40 GMT From: deraadt@newt.cuc.ab.ca (Theo de Raadt) To: comp.protocols.tcp-ip Subject: Re: Sun Generic Broadcasting
[Distribution changed from "usa" to "world". Unix is the same in Europe, isn't it??]
In article <1004@math.math.mv.dupont.com> mc@math.math.mv.dupont.com (Matt Cunningham-Software Development) writes:
> I am trying to find the proper broadcast IP address to send a packet (BOOTP
> packet to be specific - but the packet type is not important) to so that
> everyone on the network will receive it.
[deleted descriptions of numerous attempts to make it work...]
The bind() call will take INADDR_ANY to indicate that it will take a
connect from any address. It's more difficult when you send packets
out -- you must indicate _exactly_ where you want to send to. A
unix machine may have multiple interfaces, with multiple addresses.
You need to specify the broadcast address for the particular network
you are interested in. If you wish to send on all the attached networks,
you need to do multiple send()'s.
The program below will list the broadcast addresses for all of the
networks that your machine is directly connected to. It will skip
LOOPBACK and POINTTOPOINT links, simply because those do not have a
broadcast address. For your problem, just sendto() each address that
is discovered by this routine below..
Note that on some machines you'll need to enable broadcasting before
packets will actually make it onto the wire. You don't need this on
Suns, but it does now hurt. Other machines (ie. SGI) DO need it.
if( (sock=socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) {
perror("socket");
return -1;
}
i = 1;
setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &i, sizeof(i));
On some operating system (Ultrix?) only root processes can broadcast,
what a crock.
Hope this helps you.
<tdr.
----------------------------------------------------------------------
#include <sys/param.h>
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/signal.h>
#include <sys/file.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <net/if.h>
#include <netinet/in.h>
#include <dirent.h>
#include <netdb.h>
#include <stdio.h>
#include <string.h>
main()
{
struct ifconf ifc;
struct ifreq ifreq, *ifr;
struct sockaddr_in *sin;
struct in_addr in;
struct net *n;
int i, sock;
char inbuf[1024];
if( (sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) {
perror("socket");
return -1;
}
ifc.ifc_len = sizeof inbuf;
ifc.ifc_buf = inbuf;
if( ioctl(sock, SIOCGIFCONF, (char *)&ifc) < 0) {
close(sock);
perror("ioctl");
return -1;
}
ifr = ifc.ifc_req;
for(i=ifc.ifc_len/sizeof(struct ifreq); i>0; i--, ifr++) {
ifreq = *ifr;
if( ioctl(sock, SIOCGIFFLAGS, (char *)&ifreq) < 0) {
perror("ioctl");
continue;
}
if( (ifreq.ifr_flags & IFF_BROADCAST) &&
(ifreq.ifr_flags & IFF_UP) &&
ifr->ifr_addr.sa_family == AF_INET) {
sin = (struct sockaddr_in *)&ifr->ifr_addr;
if( ioctl(sock, SIOCGIFBRDADDR, (char *)&ifreq) < 0 ) {
in = inet_makeaddr(inet_netof(sin->sin_addr.s_addr),
(int)INADDR_ANY);
} else {
in = ((struct sockaddr_in*)&ifreq.ifr_addr)->sin_addr;
}
printf("address %s\n", inet_ntoa(in));
}
}
close(sock);
}
----------------------------------------------------------------------
--
This space not left unintentionally unblank. deraadt@newt.cuc.ab.ca
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Thu, 5 Nov 1992 21:51:43 GMT From: mr@ogre.cica.indiana.edu (Michael Regoli) To: comp.sys.novell,comp.protocols.tcp-ip Subject: ODIPKT Freezes with my Accton EtherCombo-32
I'm having difficulty with ODIPKT on a 486/50 EISA machine, and was
wondering if anyone else is in this boat with me as well. ;)
I've got a nice little net.bat file that loads lsl, ec32mlid,
ipxodi, and bnetx (burst). That all works fine. And I can connect to
LAN servers like crazy. However, the TCP/IP side is a bit more
sticky.
Has anyone a packet driver for this card???
Thanks for the help!
--
michael regoli
mr@cica.indiana.edu
regoli@indiana.BITNET
..{ames, rutgers}!iuvax!cica!mr
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: Thu, 5 Nov 1992 22:16:17 GMT From: stewart@ra.cis.udel.edu (John Stewart) To: comp.protocols.tcp-ip Subject: Re: Need Ethernet types/IP Frame and Header Formats
In article <1992Nov5.212424.15228@eagle.lerc.nasa.gov> fsgreen@dredd.lerc.nasa.gov (Doug Greenwald) writes: >I'm writing a small network analyzer to gather statistics. I have most of the >IP protocols in Comer's book done but am having problems finding information >regarding a bunch of the ethernet types. I'm seeing a LOT of ethernet types >that fall into the "experimental" range of RFC 1060 and am wondering if there >are any more complete lists of assigned numbers. I need the type field of the >ethernet frame for general statistics gathering and would like the higher layer >protocol packet formats for completeness. See RFC 1340 which obsoletes RFC 1060. /jws
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Thu, 5 Nov 1992 23:00:01 GMT From: jamesd@techbook.com (James Deibele) To: comp.protocols.tcp-ip,comp.unix.admin Subject: Limited telnet program?
I would like to set up a limited telnet program for people to use. Specifically, I'd like to provide local librarians a way of telneting to selected online library catalogs via a menu. If the telnet to that site fails, I would want the telnet program to exit with an error level, which I could then catch with a shell or program. I don't want people who use this account to be able to exit to a shell from within telnet, and I don't want them to be able to telnet elsewhere. If someone has seen a program like this, or has a reason why this is a bad idea*, I'd like to hear about it. It seems like it should be reasonably secure for both us and the rest of our Internet neighbors. Thanks. *Please no criticism about how we should give free shell accounts to anyone who asks for one unless you're prepared to contribute hardware.
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Thu, 5 Nov 1992 23:35:23 GMT From: ronf@panther3.panther.mot.com (Ron Feigen) To: comp.protocols.tcp-ip Subject: Re: Should connect() block after setting NDELAY?
In article <dank.720994781@blacks> dank@blacks.jpl.nasa.gov (Daniel R. Kegel) writes:
>
>Hi all,
>I'm writing an application that opens sockets to many servers in parallel
>before sending out a query to each server (also in parallel). It sets
>the sockets into nonblocking mode before the connect() as follows:
> int flags;
> #ifdef USE_FIONBIO
> flags=1;
> netioctl(qp->fds, FIONBIO, (char *)&flags);
> #else
> flags = fcntl(qp->fds, F_GETFL, 0);
> #ifdef USE_O_NDELAY
> flags |= O_NDELAY;
> #else
> flags |= FNDELAY;
> #endif
> fcntl(qp->fds, F_SETFL, &flags);
> #endif
>The problem is, under SunOS 4.1.1, connect() then blocks until a
>accept, reject, or defer response comes back from the server.
>This can take several seconds if the Internet is being slow.
>The local Sun guy was able to see this in the source code, but does not
>consider it a bug. What do you all think- is it reasonable for connect()
>to block for several seconds when the socket is supposedly in nonblocking
>mode?
>- Dan Kegel (dank@blacks.jpl.nasa.gov)
I use this chunk of code (SunOs 4.1) and have no problem blocking
if ((d_ptr->fid = socket(AF_INET,SOCK_STREAM,0)) < 0) /* make socket */
{
err_log(WARNING, ERRNO, "Making dbs socket");
continue;
}
if (fcntl( d_ptr->fid, F_SETFL, FNDELAY) == -1)
{
err_log(WARNING, ERRNO, "can't set socket to non blocking");
close(d_ptr->fid);
continue;
}
if (fcntl( d_ptr->fid, F_SETFD, 1) == -1)
{
err_log(WARNING, ERRNO, "can't set socket to close on exec");
close(d_ptr->fid);
continue;
}
if(connect(d_ptr->fid,(struct sockaddr *)&sock,sizeof(sock)) == 0)
{
/* connected */
FD_SET(d_ptr->fid, write_fds);
d_ptr->status = CONNECTED;
break;
}
if ( errno == EINPROGRESS )
{
FD_SET(d_ptr->fid, connect_fds);
d_ptr->status = CONNECT_PENDING;
break;
}
.
.
.
--
>
Ron Feigen
ronf@panther.mot.com
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: Fri, 6 Nov 1992 01:40:19 GMT From: nigel@cnw01.storesys.coles.oz.au (Nigel Harwood) To: comp.protocols.tcp-ip Subject: TCP over X.25 TELNET performance
I have recently started using TCP over X.25 with the WIN-TCP product. When using TELNET to log into a remote system using a 2400BPS line performance is very bad, especially for what I enter locally at the keyboard. This is obviously because a whole packet is being constructed for each character I type. So, before I enter into a long and drawn out experimentation session has anyone dealt with this problem already? Perhaps, combinations of local echo, buffering, line mode etc would acheive better through put? Any help appreciated. Regards -- <<<<<<<<<<<<<<<<<<<<<<<<< Nigel Harwood >>>>>>>>>>>>>>>>>>>>>>>>>>> << Post: Coles Supermarkets, PO Box 480 Glen Iris 3146, Australia >> << Phone: +61 3 829 6090 E-mail: nigel@cnw01.storesys.coles.oz.au >> << FAX: +61 3 829 6886 >>
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 6 Nov 92 01:58:54 GMT From: martin@datacomm.ucc.okstate.edu (Martin McCormick) To: comp.protocols.tcp-ip Subject: Bootleggers
We have the occasional problem of people, for whatever reason, choosing an IP number and getting on our network. Since IP numbers are as free as the air and about as easy to get, there is no good reason for somebody to do this. Does anybody know of anything that one can do to, essentially, make life miserable for these bootleggers? Needless to say, I don't want to do anything that would disrupt the network for decent folks who are going about their business, but I truly want to discourage people from this practice since it has the potential for causing some systems to crash if somebody picks a duplicate number. Since the same things that could be used to torment a bootlegger could be misused to disrupt anybody, maybe you should just E-mail me. Thank you. Martin McCormick WB5AGZ Stillwater, OK O.S.U. Computer Center Data Communications Group
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: 6 Nov 92 03:51:54 GMT From: bill@solaria (Bill Neisius) To: comp.protocols.tcp-ip Subject: SLIP connection to XYPLEX on modem
OK, I give up. I'm trying to connect a modem to a XYPLEX 1500 server.... and run SLIP. It works fine when I connect the local ISBN phone network to the server; but when I connect a modem, all I get on the remote machine is 'bad IP checksum' or 'can't open connection, timeout'. I'm using SLIP8250 and TELBIN on the remote PC; modem on the server is a MultiTech v.32, on the PC it's a DigiCom Scout+. Connection is at 9600 baud/V42. I can see 'ping' packets arrive at the PC, but something is missing 'cause they generate 'bad IP checksum' in TELBIN. If I try to open a connection, I get a 'timeout' almost immediately... So what's the deal? Flow control? The XYPLEX has only 8 wires in its serial connection, so you get DCD/DTR or CTS/RTS, but not both. Does SLIP work with XON/XOFF? well...I guess so, cause it works with the ISBN 'modem'.... Any suggestions? Bill Neisius bill@solaria.hac.com
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 6 NOV 92 13:01:34 EST From: murphy@hal.hahnemann.edu To: comp.protocols.tcp-ip Subject: Re: Limited telnet program?
In a previous article, jamesd@techbook.com (James Deibele) wrote:
>I would like to set up a limited telnet program for people to use.
>Specifically, I'd like to provide local librarians a way of telneting to
>selected online library catalogs via a menu. If the telnet to that site
>fails, I would want the telnet program to exit with an error level,
>which I could then catch with a shell or program. I don't want people
>who use this account to be able to exit to a shell from within telnet,
>and I don't want them to be able to telnet elsewhere.
>
Mark Resmer at Sonoma State University has written both a VMS
DCL command procedure and some sort of shell script for accessing
libraries and databases on the Internet. Both are available via
anonymous ftp in the /pub directory on sonoma.edu. You might want
to take a look these before you roll your own...
Regards,
John
-----------------------------------------------------------------------------
|John Murphy (JM66) |Internet: murphy@hal.hahnemann.edu
/ / / /|Library System Manager |VMS Mail: HAL::MURPHY
/---/ / / |Hahnemann University |Beeper #: 1864
/ / /___/ |245 N. 15th St., MS 449 |Voice: (215) 762-1042
|Phila., PA 19102-1192 |Fax: (215) 762-8180
-----------------------------------------------------------------------------
"It's a small world, but I wouldn't want to have to paint it" - Steve Wright
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: Fri, 6 Nov 1992 09:13:07 GMT From: graeme@ccu1.aukuni.ac.nz ( Graeme Moffat) To: comp.unix.admin,comp.unix.aix,comp.protocols.tcp-ip Subject: Re: inetd configuration questions
lucien@watson.ibm.com (Lucien Van Elsen) writes: >>I have noticed in the "Diskless Workstation Management Guide", when >>referring to changing inetd.conf, that the command "inetimp" is omitted from >>the instructions. Does 3.2 now not use the ODM for inetd? >"refresh -s inetd" causes an "inetimp" to occur, and I believe this was true >under 3.1 as well. However, this doesn't seem to be a documented feature >anywhere, so I wouldn't rely on it in the future. You're right, it does. I'll have to pull my tongue back out of my cheek :) -- Graeme Moffat g.moffat@aukuni.ac.nz \ Time wastes us all, Computer Aided Design Centre, Fax: +64-9-366-0702 / our bodies & our wits School of Engineering, Ph: +64-9-737-999 x8384 / But we waste time, University of Auckland, Private Bag, Auckland, NZ \ so time & we are quits
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: Fri, 6 Nov 1992 14:46:45 +0000 From: dblack@ccla.demon.co.uk (David Black) To: comp.protocols.tcp-ip Subject: No subject
Re: Remote Printing from JES2 Spool
I'm not too sure if this is relevant:
We managed to get remote printing via JES 328X onto remote printers
using OS/2 machines running ES this will give you 5 LU's. These were
then addressed as remote printers from within JES.
We also got unix devices to share the same printers by setting up
the TCP/IP for OS/2 running as a TFTP server and TFTP'ing the spool
file to the LPTX port on the PC.
/DB
=
David Black 49 Woodgrange Drive dblack@ccla.demon.co.uk
Crucible Computers Southend On Sea dblack@cix.compulink.co.uk
Networking Consultant Essex UK SS1 2SD Flies AA5B G-NGBI
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 6 Nov 92 14:49:40 GMT From: tas@concert.net (Tim Seaver) To: comp.protocols.tcp-ip Subject: TCP source for binary Ultrix and SunOS
I've been working with TCP on binary SunOS 4.1.1/4.1.2 and Ultrix 4.1 RISC hosts for several months, and I'm making the source code I use available in case other folks would like to do the same. The TCP implementation is based on the 4.3 BSD Reno release, with the RFC1323 High Performance extensions added. The RFC1323 implementation is based on code from Thomas Skibo, done at the University of Illinois at Urbana-Champaign. The TCP source code, adapted to fit into a binary kernel distribution, is available for anonymous ftp from ftp.concert.net as dist/tcp.sunos4.1+.tar and dist/tcp.ultrix4.1.tar. This code is experimental, but has been running on my DECstation 5000 workstation and a production Sparc-2 server for several weeks without problems. If you use this code, please let me know of any problems you run into and any changes you find necessary to bring it up on other hardware or OS versions. Thanks, Tim Seaver CONCERT Network MCNC Center for Communications tas@concert.net
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 6 Nov 92 17:39:36 GMT From: tm8t+@andrew.cmu.edu (Tod McQuillin) To: comp.protocols.tcp-ip Subject: Re: Transfer of 100's of MBytes files
rjberke@berke.itg.ti.com (Richard Berke) writes: > How often (1 out of 20?) do you run into aborted transfers that > have to be restarted from scratch? Pretty often. Especially with large files transferred over a SLIP link. I'd say 1 out of 50 times over SLIP, and 1 out of 200 on more permanent connections. > Have you been able to distinguish > what portion of those failures are due to disk issues, circuit failures, > or protocol implementations? In my experience, TCP is an extremely reliable protocol. Aborted transfers are almost always caused by network hardware problems, or routing difficulties. > I am frequently asked about the reliability of using FTP to move > files and/or sets of files that are 200-400 Mbytes, and there's interest > in some means of recovering from a disruption in the middle of a transfer. You can always check that the transfer was successful by taking the checksum of the data on both ends. The more recent implementations of the FTP protocol I've seen all support the "reget" command (I believe the FTP spec calls this "RETR") which allows you to resume an interrupted transfer. I use it all the time and have never had a problem with it. > I'm sensitive to disruptions, but wary of exotic schemes to recover. I'd hardly call the reget command exotic. > Since our world-wide links are as small as 56 Kbits/sec, transmission times > are significant. Good throughput for FTP (not best case) is about 5 Kbytes > per second. 200-400 Mbytes takes 1-3 hours or more. Detection of failed > transfers may be delayed, further adding to wall clock time taken to > accomplish the overall transfers. You have a point there. The reget command does not automatically work -- you have to type it yourself. > I've heard that protocols exist for transfers that use checkpoints and > can restart. I've never heard of mainstream suppliers for them. > Are they available? How necessary are they, compared to FTP? I've never had a need for something like this, but then, it sounds like your data-moving requirements are more demanding than mine.
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: 6 Nov 92 17:46:54 GMT From: tm8t+@andrew.cmu.edu (Tod McQuillin) To: comp.protocols.tcp-ip Subject: Re: SLIP connection to XYPLEX on modem
bill@solaria (Bill Neisius) writes: > OK, I give up. > > ... but when I connect a modem, all I get on the > remote machine is 'bad IP checksum' or 'can't open connection, timeout'. > > [...] > > I can see 'ping' packets arrive at the PC, but something is missing > 'cause they generate 'bad IP checksum' in TELBIN. If I try to open > a connection, I get a 'timeout' almost immediately... > > So what's the deal? Flow control? The XYPLEX has only 8 wires in its > serial connection, so you get DCD/DTR or CTS/RTS, but not both. Does > SLIP work with XON/XOFF? well...I guess so, cause it works with the > ISBN 'modem'.... SLIP *does not* work with XON/XOFF flow control. IP is a binary protocol, and if I want to send you a packet full of XOFF's, you had better be prepared to accept it. If your modems are set up to respond to XON/XOFF flow control, then SLIP will not work for you -- that's all there is to it. Since you said you were using error-correcting modems (and presumably data-compression as well), this implies your throughput is not the same as the DTE data rate. So you will need some form of flow control, unless you're prepared to suffer from severe data lossage which will cause all kinds of TCP retransmits and make most udp applications unhappy as well. From the description of your equipment, you need to use RTS/CTS flow control.
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: Fri, 06 Nov 92 19:10:36 GMT From: regina@netronix.com (Regina Clarke) To: comp.protocols.tcp-ip Subject: Subnet Masks
Internet : regina@netronix.com
USENET : uunet!netronix!regina
fax : (707) 763-6291
phone : (707) 769-3300
U.S.Mail : Regina Clarke
Netronix, Inc.
1372 N. McDowell Blvd.
Petaluma CA 94954
Would like information on subnet masks--function, any glitches from end-user p.o.v. and why fixed, contiguous addressing necessary or advisable?
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 6 Nov 92 21:16:29 GMT From: pstevens@Metaphor.COM (Paul Stevens) To: comp.protocols.tcp-ip Subject: Determining the hop count to a net or sub-net
I've read how traceroute works: UDP packets retransmitted with greater
Time-To-Live values which result in ICMP packets back from each
router along the way. I'm wondering if there is any lighter-weight
techinque for determining some kind of distance metric for a destination.
I am also interested to know if there is anything around that is done
as a function that can be called rather than a program that display
information on stdout.
+------------------------------------------------------------------------+
Paul Stevens {apple|decwrl}!metaphor!pstevens
Metaphor Computer Systems pstevens@metaphor.com
Mountain View, CA
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: Fri, 6 Nov 1992 21:17:02 GMT From: mac@unison.com (Michael A. Casteel) To: comp.protocols.tcp-ip Subject: Looking for PC network trace software
On the odd occasion when I'm really puzzled over a network application problem, tcpdump or etherfind would be nice. But, I don't have either of those on my HP-UX; seems more like a good PC application anyway. Is there a PC version of Ethernet trace software available for ftp? Thanks. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mike Casteel Unison Tymlabs mac@unison.com 675 Almanor Ave., Sunnyvale, CA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: 6 Nov 92 22:08:11 GMT From: gsa@easyaspi.udev.cdc.com (gary s anderson) To: comp.protocols.tcp-ip Subject: Re: rpc process chewing up resources
In article <DERAADT.92Nov5044404@newt.newt.cuc.ab.ca>, deraadt@newt.cuc.ab.ca (Theo de Raadt) writes:
|> I'm currently implimenting YP client functionality for 386bsd. So far,
|> it's been an enjoyable and frustrating time....
|>
|> In article <49256@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
|> > |> > |> > sits within the "yp" library code (you need to ask SUN why "pinging"
|> > |> > |> > the portmapper from within "yp" is useful). This has the wonderful
|> > |> > |> Hmmmph!
|> > |> > |> What would you do if you wanted to discover if ypbind is running?
|>
|> Well, on some systems (including my code at the moment) that's exactly
|> why TCP is used. It's faster than UDP.
Please explain how TCP is "faster" than UDP. You are sending one request
and getting one reply. This is an unfragmented request/reply sequence,
in the case discussed in this thread. TCP adds an end-to-end
connect sequence besides sending the request and receiving the response.
I'd like to know which systems you use which can create a connection
and send a message faster than you can just send the message.
There are many reasons to use TCP but your comment on "faster"
is obviously missing some relevant context information.
|>
|> My first code used UDP to find out if ypbind was running. Well, if you
|> don't get an answer, even in talking to 127.0.0.1, well, the kernel's
|> buffers could just be swamped at the moment. So you have to try a few
|> times. Not pretty.
If there are no kernel buffers you can't create a TCP connection
either. The case where UDP suffers is when concurrent request
information overflows the receive socket. In the case we are
talking about this isn't a major concern (i.e. small packets and
short think time in server. Additionally, vendors selling useful
multi-user systems provide reasonable buffer sizes). Consequently,
overflowing the TCP connect limit would be roughly
equivalent to the UDP receive buffer limit.
NOTE - In case you missed, the TCP connection in question is directed
to the portmapper not to ypbind.
|>
|> So, I started using TCP. Immediate response yes/no whether YP is
|> running. I had no real concerns with whether the portmapper is
|> running.
|>
|> I'm have a Sun too. A few minutes ago, I went and looked to see why
|> the file /etc/ypbind.lock exist... a bit of snooping and following a
|> hunch...
|>
|> 4835 -rw------- 1 root 0 Nov 2 21:46 /etc/ypbind.lock
|> ^^^^
|> inode
|>
|> pstat -i | grep 4835
|> f23f9a8 R 7, 0 4835 100600 1 0 0 E 2 0 1 VREG
|> ^^^
|> That little 'E' is an exclusive lock.
|>
|> Could someone explain exactly what is going on here? What I suspect
|> follows: ypbind maintains the exclusive lock on /etc/ypbind.lock
|> Processes that are interested can find out if ypbind is running by
|> doing a lockf(fd, F_TEST). Sun's ypbind also puts an exclusive lock
|> on /var/yp/binding/domainname.2 and /var/yp/binding/domainname.1. I
|> suspect the 2 is YPBINDVERS.
|>
|> Just trying to get a flock() on that file seems to work. This is so much
|> easier than what it appears the entire argument here is about.
|>
|> Here's what happens if I trace a program that needs to check YP.
|>
|> open ("/var/yp/binding/cuc.ab.ca.2", 0, 036736173730) = 4
|> flock (4, 06) = -1 EWOULDBLOCK (Operation would block)
|> mmap (0x8ab8, 14, 0x1, 0x80000001, 4, 0) = 0xf7710000
|> close (4) = 0
|>
|> Aha. The fact that the flock() failed tells us that ypbind is running.
|> Sun places into the binding file the actual (struct sockaddr_in) at
|> which the current ypserver can be found (It could be ypbind's address,
|> but it makes more sense to be ypserv's address). So they mmap() the
|> (struct sockaddr_in) and continue.
|>
|> > |> >
|> > |> > I would send a UDP RPC request to the portmapper to find out
|> > |> > if ypbind was registered. The problem is that there is code
|> > |> > which creates a "dummy" TCP connection just to see if the
|> > |> > portmapper is running (i.e. doesn't trust UDP time-outs as
|> > |> > sufficient evidence that the portmapper is not running).
|>
|> I would not trust a UDP timeout on "localhost" as meaning that the
|> portmapper is dead. It might take 5 seconds for a busy portmapper to
|> answer. Someone in Timbuktu, at the end of a very slow link, may have
|> been spraying the portmapper. Packets may have convoyed, and the
|> portmapper may be swamped! How long are you going to wait around?
Why do you assume that this same phantom you fear cannot spray the
portmapper with bogus TCP connections? You will find that the same
quantity of bogus TCP connections are generally worse than bogus UDP
packets. People with this level of paranoia typically deploy firewalls.
Also, you seem to be disillusioned about what happens when a TCP
packet gets dumped on the ground. You will note that it has a
regressive back-off timer with the lowest retry level at
approximately one second. What TCP gives you is a well-respected
retry algorithm which may not always be present in various UDP
applications.
The advantage that was hypothesized for TCP (in this particular
thread) is that the UDP/ICMP "port not available" (i.e. no server currently
bound to the specified port) may not be as well supported as the
equivalent TCP RST functionality. If your application has some
semantical benefit gain from this feature then TCP might be
a better choice.
|>
|> > |> > If the connection succeeds, it is immediately closed and then
|> > |> > the UDP RPC request is made to the portmapper to get the
|> > |> > information about ypbind.
|> > |>
|> > |> Perhaps my point was not clear.
|> > |>
|> > |> By using TCP you avoid having to wait for a UDP time-out to expire when
|> > |> things are not present. Which would make you more unhappy? Having an
|> > |> anonymous TCP port number tied up for a little while or having to wait
|> > |> a large part of a second (or more if you allow remote access over slow
|> > |> links) to discover that the portmapper is not running?
|>
|> With TCP, your connection will succeed immediately, well, as long as
|> the listen queue has room for you....
|>
|>
|> Really, I prefer Sun's method of checking for yellow. A flock() on a
|> locked file means you are talking to an inode that is already in the
|> buffer cache. That's got to be faster and more reliable than talking
|> to portmap & ypbind.
As long as everything is local you can reliably use files for
interlocking, however, I would not be overly enthused to see rpc.lockd
as the cornerstone for provision of these services (e.g. you ever needed
to solve a remote concurrency issue).
|>
|> Anyways, I'm going to impliment my routines much like Sun's did!
|>
|> Only one thing bothers me with the RPC programming I am doing. Sun's
|> ypbind is not multithreaded; rather, it forks when it gets a request
|> for a currently unbound domain. I decided to make my ypbind much more
|> multithreaded. What I have come to discover to my disgust is that if
|> you wish to write a properly multithreaded RPC application you have to
|> give up all the juicy RPC and SVC routines and dig right into the XDR
|> level. What a pain. And, boy, I could scream because I have found no
|> way to access msg->msg_xid from the SVC/RPC level! For a proper
|> multi-threaded application, you are going to need to save a copy of
|> that for the later reply!
|> <tdr.
|> --
One technique is to use request-only primitives (e.g. use timeout==0) to satisfy
multi-threading needs. However, since you probably want to interoperate
with existing ypbind entities this probably won't help much.
|>
|> This space not left unintentionally unblank. deraadt@newt.cuc.ab.ca
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: Sat, 7 Nov 92 00:58:55 GMT From: mogul@pa.dec.com (Jeffrey Mogul) To: comp.protocols.tcp-ip,comp.unix.ultrix Subject: Re: Who supports multicast? (summary of responses)
In article <1992Nov2.190805.23351@PA.dec.com> I wrote: >And if you want IP multicast support in ULTRIX or OSF, you might consider >calling your DEC salesperson and saying so. Some people have expressed little faith in the utility of this approach. Try this instead: send email to Gail Grant (grant@pa.dec.com), who might have some effect (and who knows more than a little about the Internet). Please send Gail concise, friendly messages explaining why you think DEC should support IP multicast (or why not, I guess). In particular, you might want to describe specific applications that require multicast, rather than just "it's a good thing." No promises, of course. -Jeff
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: Sat, 7 Nov 1992 03:44:06 GMT From: eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig) To: comp.protocols.tcp-ip Subject: Proper Method of Closing IP Sockets
What is the proper method of closing a socket in order to release the socket/port binding? Under SunOS 4.1, my application closes its descriptors and exists. If I immediately execute it again, the bind fails with errno EADDRINUSE. Eventually, operating system figures out that the old process is defunct, but I would like to do this properly. The server process just does the standard socket/bind/listen/accept song-and-dance: sin.sin_family = AF_INET; sin.sin_port = htons(PORTNUM); sin.sin_addr.S_un.S_adder = INADDR_ANY; s = socket(AF_INET, SOCK_STREAM, 0); bind (s, &sin, sizeof(sin)); listen(s,5); con = accept(s, &fsin, &conlen); /* Fool around with the socket. */ close(con); close(s); exit(); What am I missing here? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jack Eifrig (eifrig@cs.jhu.edu) The Johns Hopkins University, C.S. Dept. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: Sat, 7 Nov 1992 04:14:30 GMT From: ae2@cunixb.cc.columbia.edu (Amiran Eliashvili) To: comp.protocols.tcp-ip Subject: Re: FTP client source
Hi all:
I have a rather specific question that have been intriguing me for
few days now. I am trying to implement a fault tolerant system based
on the Client/Server model. The nature of the system is to detect if
either ends has been terminated. If it has been terminated abnormally
the system will react accordingly.
I am using BSD sockets in order to establish a link between the server
and the client, using SOCK_STREAM (TCP) as my protocol. I am able to
detect when the other side has been terminated by a SIGKILL, SIGQUIT,
as writing to the socket on the other side sends a SIGPIPE. Yet, when
the machine has been turned off manually I don't get anything even
though I have tried setting setsockopt(SO_KEEPALIVE)
[Man page exerb ]
SO_KEEPALIVE enables the periodic transmission of messages on a
connected socket. Should the connected party fail to respond to
these messages, the con- nection is considered broken. A process
attempting to write to the socket receives a SIGPIPE signal and
the write opera- tion returns an error. By default, a process
exits when it receives SIGPIPE. A read operation on the socket
returns an error but does not generate SIGPIPE.
to setsockopt(SO_LINGER) but none has worked for me. I was wondering
if anyone else has encountered in the problem. If so how did you
overcome it?
Any ideas or suggestions would be much appreciated.
Please mail to : ae2@cunixa.cc.columbia.edu
Thanks
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: 7 Nov 92 17:19:03 GMT From: paul@tivoli.UUCP (Paul Greenspan) To: comp.protocols.tcp-ip,comp.unix.wizards Subject: TLI and non-blocking I/O
Below is a description of a problem that we are having with some of our network code. I would appreciate any help that I could get. Background: ----------- We have taken a rather complicated server that was developed with BSD sockets and converted it to use TLI. The server has to handle many things at once (with threads) so it is important that we use non-blocking endpoints. So to avoid blocking on a t_listen() call waiting for a connection request, we wait for poll() to tell us that there is a connection request and then try to call t_listen(). Here is a description of the behavior of some of our TLI code, as executed under SVR4.0.3: [SERVER] 1. The server calls t_open(DEV_TCP, O_RDWR, 0). 2. The server calls ioctl(tfd, FIONBIO, &non_blocking) to set the TLI endpoint into non-blocking mode. 3. The server calls t_bind(tfd, &req, &ret) to offer a channel to clients. The bound address is selected by the transport provider (req.addr.len is 0) and gets recorded so clients can be told on what address to t_connect. 4. The server calls poll() to wait for connection requests. [CLIENT] 5. A client initiates a connection request by first calling t_open(DEV_TCP, O_RDWR, 0). 6. The client then calls t_bind(tfd, 0, 0) 7. The client calls t_connect(tfd, connreq, 0), where connreq has been t_alloc'd, then set up with the correct address, no options, and no user data. NOTE: The client's t_connect will later appear to succeed. (Weird.) [SERVER] 8. The server is notified of the connection request by poll(). t_look(tfd) returns T_LISTEN (1). 9. The server calls t_listen(tfd, callptr), where callptr has been t_alloc'd but otherwise left alone. This call fails, returning -1. t_errno is TNOTSUPPORT (18). [CLIENT] 5. A client initiates a connection request by first calling t_open(DEV_TCP, O_RDWR, 0). 10. Here's the weird part. The client's t_connect call now returns and indicates all is well. So the client code keeps going. 11. The client calls ioctl(tfd, I_POP, 0) 12. The client calls ioctl(tfd, I_PUSH, "tirdwr") 13. The client calls write(tfd, buf, sizeof(u_long)). This succeeds! 14. The client calls read(tfd, buf, sizeof(u_long)). This is where the client finally sees something is wrong, as the read call returns 0. -- Paul Greenspan paul@tivoli.com Tivoli Systems 6034 West Courtyard, Suite 210 Austin, Texas 78730 (512) 794-9070 / FAX (512) 794-0623
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: 7 Nov 92 19:31:51 GMT From: arena@goethe.credtech.com (Mike Arena) To: comp.protocols.ibm,comp.protocols.tcp-ip,comp.unix.aix Subject: Hardware/Software solutions for TCP/IP <-> LU6.2 APPC communications
We are in the process of investigating products which convert between TCP/IP and LU6.2 (and optionally DECnet) protocols for APPC. We will be using an IBM RS/6000 machine. Our company currently has no IBM machines (AS/400, S/36, S/38, 3090) nor do we (me) have any desire to own and operate one. The current three solutions we are analyzing are: Vendor: Forest Computer Product: Connection System They sell a RiscStation with their own software preloaded which accepts TCP/IP, DECnet, and SNA connections and transparently converts between any and all of them. Features: Too good to be true. Requires no knowledge of LU6.2 or the nightmare of profiles to establish a connection. A simple open of a socket and read() and write() calls are all that is necessary. Also has TELNET, FTP, SET HOST, etc. Price: Expensive Vendor: Harris Adacom Product: SuperNet Super Channel They sell LU6.2 software which runs on your own RS/6000. You must learn LU6.2 verb set programming, etc. Price: Moderate Vendor: System Strategies Product: Express+ They sell LU6.2 software which runs on your own RS/6000. You must learn LU6.2 verb set programming, etc. Price: Inexpensive If anyone has used any of these products or has other suggestions, we would appreciate any information. -- Michael James Arena Credit Technologies Inc. arena@credtech.com 281 Winter Street, Suite #100 (617) 890-2000 x237 Waltham, MA 02154
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: 7 Nov 92 22:33:50 From: amoss@shuldig.cs.huji.ac.il (Amos Shapira) To: comp.protocols.tcp-ip,comp.sys.sgi Subject: NNStat for SGI Irix 4.0.5F anyone?
Hello, The latest version of the NNStat programme (a programme to gather statistics about Internet usage) I could find is dated March 15, 1991. And it doesn't support SGI Irix. Did anyone port it to the Irix? Just asking before I waste my time on this... Thanks for any answers, -- --Amos Shapira (Jumper Extraordinaire) C.S. System Group, Hebrew University, Jerusalem, Israel amoss@cs.huji.ac.il
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: Sun, 08 Nov 1992 18:29:22 GMT From: vances@xenitec.on.ca (Vance Shipley) To: comp.protocols.tcp-ip Subject: LocalTalk -> KA9Q ?
I have a couple subnets of a 10BaseT network connected with a KA9Q router. I also have a small LocalTalk network, a couple TOPS cards and some MAC TCP software. I have found LocalTalk packet drivers and a version of KA9Q NOS which is supposed to support them. So, can I put the TOPS card in the KA9Q and have MAC users Telnet into hosts attached to the 10BaseT subnets on the other side? The packet driver software for the TOPS cards suggests that I need a "gator box" to act as a gateway. Can the KA9Q do this? Thanks in advance for your help. -- Vance Shipley vances@xenitec.on.ca vances@switchview.com vances@ltg.uucp
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: Sun, 8 Nov 1992 18:45:29 GMT From: mdw@theory.TC.Cornell.EDU (Matt Welsh) To: news.admin,news.future,news.misc,comp.protocols.tcp-ip Subject: NREN information wanted
Where can I get information on the NREN project (on-line or otherwise)? Any pointers to documents, papers, books, etc. would be greatly appreciated. Thanks, mdw -- Matt Welsh mdw@tc.cornell.edu +1 607 253 2737 Systems Programmer, Cornell Theory Center "She's like jelly roll, like sculpture!"
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: Sun, 8 Nov 1992 18:51:38 GMT From: scoggin@opus.ee.udel.edu (John K Scoggin) To: news.admin,news.future,news.misc,comp.protocols.tcp-ip Subject: Re: NREN information wanted
In article <1992Nov8.184529.11229@tc.cornell.edu> mdw@theory.TC.Cornell.EDU (Matt Welsh) writes: >Where can I get information on the NREN project (on-line or otherwise)? Any >pointers to documents, papers, books, etc. would be greatly appreciated. > >Thanks, >mdw There are some papers on host nnsc.nsf.net in the nsfnet directory. - John ------------------------------------------------------------------------- John K. Scoggin, Jr. Email: scoggin@udel.edu Supervisor, Network Operations scoggin@delmarva.com Delmarva Power & Light Co. Voice: 302-451-5200 P.O. Box 6066 Fax: 302-451-5321 Newark, DE 19714-6066 ------------------------------------------------------------------------- Your milage may vary. Void where prohibited by law (or common sense).
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: Sun, 8 Nov 1992 20:07:31 GMT From: panos@burton.cs.colorado.edu (Panos Tsirigotis) To: comp.protocols.tcp-ip Subject: Re: Should connect() block after setting NDELAY?
In article <dank.720994781@blacks> dank@blacks.jpl.nasa.gov (Daniel R. Kegel) writes:
>
>Hi all,
>I'm writing an application that opens sockets to many servers in parallel
>before sending out a query to each server (also in parallel). It sets
>the sockets into nonblocking mode before the connect() as follows:
> int flags;
> #ifdef USE_FIONBIO
> flags=1;
> netioctl(qp->fds, FIONBIO, (char *)&flags);
> #else
> flags = fcntl(qp->fds, F_GETFL, 0);
> #ifdef USE_O_NDELAY
> flags |= O_NDELAY;
> #else
> flags |= FNDELAY;
> #endif
> fcntl(qp->fds, F_SETFL, &flags);
^^^^^^
> #endif
This is wrong; all arguments of fcntl are 'int's.
Panos
--
Panos Tsirigotis, CS grad
Pmail: Computer Science Dept., U. of Colorado @ Boulder, Boulder, CO 80309-0430
Email: panos@cs.colorado.edu
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: 9 Nov 1992 03:34:07 GMT From: dank@cco.caltech.edu (Daniel R. Kegel) To: comp.protocols.tcp-ip Subject: SOLVED: Should connect() block after setting NDELAY?
panos@burton.cs.colorado.edu (Panos Tsirigotis) writes: >> flags = fcntl(qp->fds, F_GETFL, 0); >> flags |= FNDELAY; >> fcntl(qp->fds, F_SETFL, &flags); > ^^^^^^ >This is wrong; all arguments of fcntl are 'int's. The prize goes to Panos- he solved the problem where the local Sun rep couldn't. Thanks much; may all your connects be speedy... - Dan Kegel (dank@blacks.jpl.nasa.gov)
-----------[000087][next][prev][last][first]---------------------------------------------------- Date: 9 Nov 92 10:51:13 GMT From: zlsiimw@mcchpc.mcc.ac.uk (Mark Whidby) To: comp.protocols.tcp-ip,comp.unix.admin Subject: Re: Limited telnet program?
In article <Bx9MK3.4nL@techbook.com>, jamesd@techbook.com (James Deibele) writes: |> I would like to set up a limited telnet program for people to use. |> Specifically, I'd like to provide local librarians a way of telneting to |> selected online library catalogs via a menu. If the telnet to that site |> fails, I would want the telnet program to exit with an error level, |> which I could then catch with a shell or program. I don't want people |> who use this account to be able to exit to a shell from within telnet, |> and I don't want them to be able to telnet elsewhere. |> |> If someone has seen a program like this, or has a reason why this is a |> bad idea*, I'd like to hear about it. It seems like it should be |> reasonably secure for both us and the rest of our Internet neighbors. The source of the BSD telnet seems to be available on a number of anonymous ftp sites so if you're running on a Sun then this may help. Use archie to look for telnet.c. Meanwhile, I'm looking for something similar for HP-UX, i.e. a telnet which disallows shell escapes (I'm not bothered about trapping errors). -- _____________________________________________________________ Mark Whidby, Distributed Systems, Manchester Computing Centre
-----------[000088][next][prev][last][first]---------------------------------------------------- Date: 9 Nov 92 10:57:41 GMT From: rol@grasp1.univ-lyon1.fr (Paul Rolland) To: comp.protocols.tcp-ip Subject: /etc/protocols file
Hello, I'm using a Sun system with a /etc/protocols file that contains only 5 or 10 lines, with nothing refering to port 25 (snmp) or 33... I know this file is used when you call getprotobyname and so on, but is it used for something else ? Is it a problem to have it containing only a few lines, and should I update it ? If yes, could s.o. send me a more complete one ? Here is my full /etc/protocols file :( # # @(#)protocols 1.9 90/01/03 SMI # # Internet (IP) protocols # This file is never consulted when the NIS are running # ip 0 IP # internet protocol, pseudo protocol number icmp 1 ICMP # internet control message protocol igmp 2 IGMP # internet group multicast protocol ggp 3 GGP # gateway-gateway protocol tcp 6 TCP # transmission control protocol pup 12 PUP # PARC universal packet protocol udp 17 UDP # user datagram protocol Paul Rolland, rol@grasp1.univ-lyon1.fr --- --------------------- DISCLAIMER ------------------- All the opinions I express in this posting are mine, but I'm ready to share them with anybody interested :-)
-----------[000089][next][prev][last][first]---------------------------------------------------- Date: 9 Nov 92 11:06:25 GMT From: rol@grasp1.univ-lyon1.fr (Paul Rolland) To: comp.protocols.tcp-ip Subject: Re: Need help with write to a socket
In article <40016@unix.SRI.COM>, ric@updike.sri.com (Richard Steinberger) wrote: > > > I have been porting a TCP/IP client from C to C++ on a Sun > running SunOS 4.1.2. The server ported fine but there is an annoying > bug with the client: When I write to a socket using code I lifted > In other words, it's as if the program exit process forces a flush of the > socket that had been taking place with each write when it was running under > C. This is hard for me to understand. Does anyone have any ideas? Thanks > in advance. > Well, this is just an idea, but are you sure the bug is not located in the read in the server code ? This read may be a blocking one, waiting for a given number of bytes, and as long as it has not received what is requested, it waits. But, when you stop the client (and then closed the connection), the server returns from the read and then you have the impression that it is OK.. In fact, you should have give us more precisely the reference of the program you are using from the book, so that it is possible to have a look at it and help you a bit more. But i hope this helps ! Paul Rolland, rol@grasp1.univ-lyon1.fr --- --------------------- DISCLAIMER ------------------- All the opinions I express in this posting are mine, but I'm ready to share them with anybody interested :-)
-----------[000090][next][prev][last][first]---------------------------------------------------- Date: 9 Nov 92 14:47:22 GMT From: sweeney@Ingres.COM (Tony Sweeney) To: comp.protocols.tcp-ip Subject: Re: TCP connect
I wrote:
>In article <Bx66Jn.D6@ushiva.wariat.org> raw@ushiva.wariat.org (Roland Wilcher) writes:
>>
>>Some time ago there was a question about checking for a TCP connect
>>to a possibly non functioning machine without the long wait.
>>An answer was posted using connect with nonblocking mode. I don't
>>have that article now but would appreciate any pointers . Target
>>system would be Esix SVR4 using the socket libraries and TCP/IP.
>>
>>--
>>Lack of skill dictates economy of style. raw@ushiva.ncoast.org
>>- Joey Ramone raw@ushiva.wariat.org
>>Roland A. Wilcher 6207 Luther Ave. Cleve Oh. 44103
>>---------------------------------------------------------------------------
>
>
What I meant to say was - here is some code I wrote to tickle a bug
in Apollo DomainOS 10.4 tcp. Should fail at the connect() on any
working system.
--------------------------cut here--------------------------------
#include <stdio.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <fcntl.h>
main()
{
struct sockaddr_in s, peer;
int sock, namelen;
int maxfd=FD_SETSIZE;
fd_set inbits, outbits, errors;
struct timeval tims;
/* code starts here... */
FD_ZERO(&inbits);
FD_ZERO(&outbits);
FD_ZERO(&errors);
bzero((char *)&s, sizeof(s));
s.sin_family = AF_INET;
s.sin_addr.s_addr = inet_addr("127.0.0.1"); /* loopback */
s.sin_port = htons(12345); /* any bogus value will do */
sock = socket(s.sin_family, SOCK_STREAM, 0);
if( sock < 0 )
{
perror( "socket" );
exit(1);
}
/* set for non-blocking */
if (fcntl( sock, F_SETFL, O_NDELAY ) < 0)
{
perror( "fcntl" );
exit(1);
} ;
if (connect(sock, (struct sockaddr *)&s, sizeof(s)) < 0)
{
if (errno != EINPROGRESS)
{
perror("connect");
exit(1);
}
}
tims.tv_sec=4; /* select times out after 4 seconds */
if (select(maxfd, &inbits, &outbits, &errors, &tims) < 0)
{
perror("select");
exit(1);
}
namelen=sizeof(peer);
if (getpeername(sock, (struct sockaddr *)&peer, &namelen) < 0)
{
printf("Correct: no peer\n");
}
else
{
printf("getpeername thinks it is connected to %s:%d\n",
inet_ntoa(peer.sin_addr.s_addr), peer.sin_port);
exit(1);
}
exit(0);
}
-----------[000091][next][prev][last][first]---------------------------------------------------- Date: 9 Nov 92 16:27:47 GMT From: barnett@grymoire.crd.ge.com (Bruce Barnett) To: comp.protocols.tcp-ip,comp.dcom.lans.ethernet Subject: Wanted: Advice on calculating timing gaps between packets.
I am analyzing the timing between packets during several large file transfers (it's a medical network). We are going to check the accuracy of our network simulation with real data. (Novel concept, huh?) Does anyone have advice on calculating the time between each packet? (Assuming we are looking at packets during a file transfer going from A to B only). We are using tcpdump and a SPARC (typically a SPARC 2). I am not sure I am using the best formula. I know the SPARC 2 has a 1 ms clock. The timestamp that tcpdump provides is actually the time the SPARC making the measurement received the packet, right? If Ethernet transmits at 10Mb/second, or 10,000,000/8 MB/sec, then each byte should take 1/(10000000/8) seconds. Therefore the time the packet was first received on the measurement system would be: $start_time = $receive_time-(1/(10,000,000/8))*$size_of_packet; I am trying to measure the time between the end of one packet and the start of the next packet. If the system started to send a packet, and there was a collision, so it had to back off and retransmit, typically how much difference would the measurement machine see? I realize that there is a propagation delay down the wire. Is there some other factors I should be taking into consideration? -- Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
-----------[000092][next][prev][last][first]---------------------------------------------------- Date: Mon, 9 Nov 1992 16:33:22 GMT From: xsong@marcus.cs.umn.edu (Carol Xiaohui Song) To: comp.protocols.tcp-ip Subject: Need info on Chameleon TCP/IP software
Hello there, I have some questions about the Chameleon network software by NetManage Inc. If you have experiences with any of the Chameleon software (e.g., TCP/Inconsistency Percentage appl. package, NFS, Chameleon32, NEWT-SDK, RPC-SDK), I'd like to hear your opinions on the following: - Chameleon TCP/IP application package (for Windows 3.x). How do you like the applications it provides such as Telnet, FTP, SMTP/Mail, etc? For example, can you open multiple telnet sessions? when you open an application like telnet, do you simply click on the icon? Any features that you like/dislike in particular? - Chameleon32 for Windows NT is the developer's release. Has anyone used it already? Is it good (adequate and efficient) for developing software that makes use of TCP/IP? - Is Chameleon TCP/IP software reliable? If you're using one, are you satisfied with their tech support? (competence, efficiency of the technical personnel) - Anything I should know besides these? The price tag on Chameleon is a little high. I'd like to hear from its users before I decide to purchase the software. I appreciate your help and am looking forward to hear your opinions! Carol Song -- Carol (Xiaohui) Song (xsong@cs.umn.edu) "You know you've been spending too much time on the computer when your friend misdates a check, and you suggest adding a "++" to fix it."
-----------[000093][next][prev][last][first]---------------------------------------------------- Date: 9 Nov 1992 18:00:22 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: /etc/protocols file
In article <rol-091192115942@90.222.1.80> rol@grasp1.univ-lyon1.fr (Paul Rolland) writes:
>I'm using a Sun system with a /etc/protocols file that contains only 5 or
>10 lines, with nothing refering to port 25 (snmp) or 33...
Port number assignments go in /etc/services.
Port 25 is SMTP. SNMP is 161. Port 33 is Display Support Protocol, which
I've never heard of.
The complete list of port numbers is in the Assigned Numbers RFC, the
latest revision of which is RFC 1340.
--
Barry Margolin
System Manager, Thinking Machines Corp.
barmar@think.com {uunet,harvard}!think!barmar
-----------[000094][next][prev][last][first]---------------------------------------------------- Date: Mon, 9 Nov 1992 22:31:51 GMT From: dsiebert@icaen.uiowa.edu (Doug Siebert) To: comp.protocols.tcp-ip Subject: Re: TCP connect
In article <1992Nov9.144723.6561@pony.Ingres.COM> sweeney@Ingres.COM (Tony Sweeney) writes: > >What I meant to say was - here is some code I wrote to tickle a bug >in Apollo DomainOS 10.4 tcp. Should fail at the connect() on any >working system. > [ code deleted ] There is another bug in DomainOS 10.4 tcp that is more serious, but as far as I can determine, it only is shown through the interaction with AIX 3.x (which is also probably buggy) But the bug is bad enough that it can bring down any Apollo running 10.4 in about 5 seconds, corrupting it badly enough it often requires the reset button to unwedge it. I won't post it here for obvious reasons, especially because so far as I know there is no fix available for this problem. -- /-----------------------------------------------------------------------------\ | Doug Siebert | "I don't have to take this abuse | | Internet: dsiebert@isca.uiowa.edu | from you - I've got hundreds of | | NeXTMail: dsiebert@chop.isca.uiowa.edu | people waiting in line to abuse | | ICBM: 41d 39m 55s N, 91d 30m 43s W | me!" Bill Murray, Ghostbusters | \-----------------------------------------------------------------------------/
-----------[000095][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Nov 1992 00:28:40 GMT From: gsu0033@uxa.ecn.bgu.edu (Eric Molas) To: comp.protocols.tcp-ip Subject: FAQ LIST
Is there a FAQ and could someone post it for this group? thanks, Eric Bruno Molas\ ...grate .sig ...
-----------[000096][next][prev][last][first]---------------------------------------------------- Date: 10 Nov 92 01:31:05 GMT From: ljs@netcom.com (Linda Siegel) To: ba.jobs.offered,comp.sys.sgi,comp.protocols.tcp-ip Subject: Senior UNIX Network/System Administrator @LucasArts-ILM
Industrial Light & Magic is the leader in creating visual effects for motion pictures, television and theme-park attractions. ILM has contributed its creative and technical expertise to more than 70 films and has won 11 academy awards (most recently for "TERMINATOR 2"). ILM is also the industry leader in utilizing new, state-of-the-art digital and computer graphics technology. We are seeking a senior systems/network administrator to manage and grow our networks for our increasing high-volume data requirements. As part of the ILM team, you'll have the opportunity to work with very creative and imaginative people in a fast-paced production environment. You'll be a member of a small Computer Services staff with broad support responsibilities. Responsibilities: ================= As the lead systems/network administrator you will provide direction and leadership for network planning and optimization. Your day-to-day activities will include: o Research, evaluate and recommend emerging network technology. o Analyze troubleshoot and optimize production networks. o Plan, analyze and tune system performance of our SGI and Sun workstations. o Communicate with project and department managers to ensure network and computing systems are performing adequately. o Develop procedures and programs to manage installation of all workstation software (OS, graphics-specific, and other software). o Define, improve, develop and monitor data backup of our high-volume data. o Troubleshoot software problems. o Assist with new workstation installation and configuration. Qualifications: =============== o BS in Computer Science (or 4 years related experience in place of educational requirement). o Minimum 3 years experience in system and network administration, preferably in a large workstation environment including SGI and Sun systems. o Demonstrated understanding of networking fundamentals and state-of-the-art technology including: TCP/IP, network analysis, routers, NFS, FDDI and broadband networks. o Working knowledge of UNIX (c-shell, awk) and C. o Ability to work in fast-paced production environment. o Strong verbal and written communication skills. Who to Contact ============== We are accepting resumes by US mail only. If you are interested in this position, please send a cover letter, resume and salary history to: Human Resources Mail-Stop JG LucasArts Entertainment Company P.O. Box 2009 San Rafael, CA 94912 Please do not respond to this account.
-----------[000097][next][prev][last][first]---------------------------------------------------- Date: 10 Nov 92 02:23:15 GMT From: ben@datacomm.ucc.okstate.edu (Ben James) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell Subject: ODITRPKT almost working but need help!
Description of my testing methods. When trying to open a telnet connection with CUTCP I sent out 11 perfectly formed ARP packets. With our general datacomm Sniffer I can see these packets go out and also see responces to them. Therefore send works for ARP. Now I load up the Netcure software on my driver and retransmit those packets that were captured from before. The ones to my mechine show up in netcapt so conclusion receive works for ARP. Now I load up ibmtoken on a mechine and do a telnet session to get data loaded into the sniffer quit and load up oditrpkt and netcapt. Transmit data from sniffer back threw my driver into netcapt. Go into netview and IP/TCP packets look OK. Conclusion Driver receives IP/TCP packets ok. Summary ARP transmit and receive work TCP/IP only receive works My guess is that TCP/IP traffic is getting stopped at the lsl or mlid since I never see a packet go out on the wire. There have been two times when I actually got a TCP packet out on the wire. The only difference in the way I treat ARP and TCP/IP in my sending routine is I change the hardware type in the ARP packet on transmit and receive and I reduce size to eliminate excess on incomming arp_packets. I also round all incomming packets up to 60. I am doing raw receives, but I am giving a specific StackID on sends although I have only bound a prescan stack. I have tried raw sends, default and prescan stacks. I have also tried binding a perticular stack but I had less success there. Question: Are the stack ID's the same as the ProtocolID's? Is it necessary to bind a stack to send things? Why would ARP work and TCP/IP not work. Does anyone have any suggestions on things to try? Seen something simular before? I am also in need of Tools and ideas for debuging. Anyone know of any shims that I can fit into here to gain more knowledge on where the packets are getting lost? All speculations, ideas, and any other help greatly appreciated. Ben James ben@datacomm.ucc.okstate.edu
-----------[000098][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Nov 1992 11:05:17 GMT From: loneshay@csie.nctu.edu.tw (Lone Shay) To: comp.protocols.tcp-ip Subject: TCP-IP implemented in Streams ?
Hi all:
Is there anybody who knows that if the TCP/IP in Sun O.S. Release 4.1.1
is implemented in Streams mechanism ?
Any information will be extremely appreciated !
Thanks...
Lone Shay 1992/Nov/10
Email: loneshay@csie.nctu.edu.tw
-----------[000099][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Nov 1992 12:07:40 GMT From: ian@unipalm.co.uk (Ian Phillipps) To: bit.listserv.ibmtcp-l,comp.protocols.tcp-ip Subject: TCP/IP for AS/400
We know that IBM themselves offer a TCP/IP product for the AS400 range.
Are there any third-party vendors in this market, and have you any
experience of their products?
Ian
--
Ian Phillipps, Unipalm Ltd, 216 Science Park, Phone +44 223 420002
Milton Road, Cambridge, CB4 4WA, England. Phax +44 223 426868
print unpack( u,q,9:G5S="!A;F]T:&5R('!E<FP@:&%C:V5R"@``,.'');
-----------[000100][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Nov 1992 12:25:32 GMT From: g91m1969@alpha.ru.ac.za (Thabo Mosala) To: comp.protocols.tcp-ip Subject: Hippi
I would like to get hold of the new developed standards for High Performance Parallel Interface (Hippi) or where can I get information on the subject ? ___________________________________________________________________________ Thabo Mosala - g91m1969@alpha.ru.ac.za The views expressed above are my own ___________________________________________________________________________
-----------[000101][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Nov 1992 12:41:35 GMT From: gwe@cbnews.cb.att.com (george.w.erhart) To: comp.protocols.tcp-ip Subject: Re: Need info on Chameleon TCP/IP software
In article <xsong.721326802@marcus> xsong@marcus.cs.umn.edu (Carol Xiaohui Song) writes: >- Chameleon TCP/IP application package (for Windows 3.x). >How do you like the applications it provides such as Telnet, FTP, >SMTP/Mail, etc? In general their applications are okay. IMHO, the next windows telnet interface remains QVTNET. The Chameleon telnet is definitely second. The QVT has the best cut/paste mouse interface. I have had some trouble with Chameleon, where I can cut an item, it appears on the clipboard, but it fails to paste. Chameleon seems to like to put a CR/NL after all pasted selections. (This is stupid!) Finally, if you have more than 24 lines of scroll buffer defined, when the display fills, a scroll bar appears on the bottom of the display. This scroll bar uses 1 line of the display. Thus, when you go into VI, the cursor disappears under the menubar at the top of the window. You have to select Settings->Reset Size to get rid of the scrollbar and get the window back to 24 lines. (This is also stupid, I have programmed a "Recorder" macro to automate this process and assigned it to F12.) >For example, can you open multiple telnet sessions? when >you open an application like telnet, do you simply click on the icon? Yes, you click on the icon, then use the connect menu to select the destination. Or, you can set up and icon with the destination passed as an argument (see the "properties" menu item). (I use the latter in conjunction with a freeware program called Dropper that gives me a Norton Desktop ability to put program icons on the base window. >Any features that you like/dislike in particular? In addition to the above ... the newest version of ChameleonNFS integrates NFS into the filemanager. This is great and it seems to work okay. There are a few problems. 1. I could not get it to work with the pcnfsd that came with the WIN/TCP 386 TCP/IP package that we run on our UNIX 5.3.2.3 boxes. A work around was to self-authorize. (Chameleon allows others to mount your PCs drives. It has a built-in pcnfsd.) The problem with this is the giant security hole that makes. (I can change my own system and authorize myself to mount anything I want!) 2. The mapping from UNIX long names to DOS 8.3 names has some problems. I have a directory on the UNIX box that contains a several days worth of weather map GIFs. I have found that the NFS mapping repeats some of the names. This means that there are files that I can not select some of the files. 3. They do have a function for finding out what the real name of the file was. However, the function is part of the "network" widget on the control panel. This makes it a pain to use. The really should make it a filemanager extension. > >- Chameleon32 for Windows NT is the developer's release. Has anyone used it >already? Is it good (adequate and efficient) for developing software that >makes use of TCP/IP? I have order two copies of this ... if any one is interested, I will post a noet about this once I get it running. >- Is Chameleon TCP/IP software reliable? If you're using one, are you >satisfied with their tech support? (competence, efficiency of the technical >personnel) I have purchased and reviewed 6 DOS/Windows TCP/IP packages. I have found that Chameleon is very reliable "on my hardware, with my drives". Please note that with different hardware and different NDIS drivers, you may have a different experience. I have had on-going problems with the PCNFSD mentioned above and with sendmail. I believe that most (if not all) of the problems are with the UNIX side of things. The folks at NetManage have been very helpful. >- Anything I should know besides these? >The price tag on Chameleon is a little high. I'd like to hear from its users >before I decide to purchase the software. The price is definitely high when compared to QVTNET, but QVTNTE does not have: NFS client & server SMTP mail server telnet 3270 SNMP client TFTP client & server BIND (domain name server) built-in SLIP support A word on the last item, I have tested various configurations for SLIP with most of the TCP/IP packages I tested. The Chameleon implementation is both the easiest to setup and the best performing. Finally, I run the Exceed/W X Window package on top of Chameleon. It seems to out perform the same package running on top of FTP's PC/TCP 2.1. -- George Erhart AT&T Bell Laboratories Columbus, Ohio att!archie!gwe or gwe@archie.att.com
-----------[000102][next][prev][last][first]---------------------------------------------------- Date: 10 Nov 92 15:55:19 From: Steinar.Haug@delab.sintef.no (Steinar Haug) To: comp.protocols.tcp-ip Subject: Re: TCP-IP implemented in Streams ?
> Is there anybody who knows that if the TCP/IP in Sun O.S. Release 4.1.1 > is implemented in Streams mechanism ? No, the SunOS 4.1.1 TCP/IP is basically a Berkeley (i.e. socket) based implementation, with streams layered on top of sockets. Solaris 2.0 is a native streams implementation, with (as far as I know) sockets layered on top of streams. Steinar Haug, system/networks administrator SINTEF DELAB, University of Trondheim, NORWAY Email: Steinar.Haug@delab.sintef.no, sthaug@idt.unit.no, steinar@tosca.er.sintef.no
-----------[000103][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Nov 1992 14:40:55 GMT From: silvert@cs.dal.ca (Bill Silvert) To: comp.protocols.tcp-ip Subject: Re: Limited telnet program?
In <6693@m1.cs.man.ac.uk> zlsiimw@mcchpc.mcc.ac.uk (Mark Whidby) writes: >The source of the BSD telnet seems to be available on a number of >anonymous ftp sites so if you're running on a Sun then this may help. There is a secure version of telnet on boombox.micro.umn.edu for use by gopher clients. However, it also is BSD-specific. If anyone knows a secure telnet for SysVR4 (specificially IRIX 4.0.5) I would like to know about it. -- William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2. Tel. (902)426-1577 InterNet Address: silvert@biome.bio.ns.ca
-----------[000104][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Nov 1992 15:30:00 GMT From: martin@datacomm.ucc.okstate.edu (Martin McCormick) To: comp.protocols.tcp-ip Subject: Re: Bootleggers
I want to really thank everybody who answered my question about what to do with or to those people who won't get with the program and register their network interfaces. Since certain actions had the potential for disrupting honest network users, I asked that the responses be E-mailed to me. I received 10 responses. Fortunately, most of the measures which can be taken to stop people from just picking an IP number and going full steam ahead are things that only network managers can do, assuming the network is configured properly. The best actions appear to be to tell all bridges or routers in your network not to handle any packets from X interface. If you can get everybody to go along, run versions of tcp-ip applications that do a nslookup on every connect request to see if they are in the name server data base. Between those two measures, the network should become a pretty boring place for bootleggers. Again, my thanks to all and also thanks for the recommendations for management software which I received from a couple of posters. Martin McCormick WB5AGZ Stillwater, OK O.S.U. Computer Center Data Communications Group
-----------[000105][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Nov 1992 15:42:28 GMT From: ronf@panther3.panther.mot.com (Ron Feigen) To: comp.protocols.tcp-ip Subject: FAST!!! TCP-IP Machines
Has anybody in netland done research on how fast different platforms process communication protocols? I am currently working on an application that relies heavily (very heavily) on TCP-IP. I am currently using Sun SparC II's but I would really like to know if there are machines that are better suited to my application. Any info would be greatly appreciated!!!! Thanks, -- > Ron Feigen ronf@panther.mot.com
-----------[000106][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Nov 1992 17:37:30 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: TCP-IP implemented in Streams ?
In article <STEINAR.HAUG.92Nov10155519@delab.sintef.no>, Steinar.Haug@delab.sintef.no (Steinar Haug) writes: > > Is there anybody who knows that if the TCP/IP in Sun O.S. Release 4.1.1 > > is implemented in Streams mechanism ? > > No, the SunOS 4.1.1 TCP/IP is basically a Berkeley (i.e. socket) based > implementation, with streams layered on top of sockets. > > Solaris 2.0 is a native streams implementation, with (as far as I know) > sockets layered on top of streams. I don't know about Solaris 2.0. However, the TCP in SVR4.1 and beyond seems to be a combination of versions of 4.3BSD around the net-1 release that have been "stream-ized." This observation is based on side-by-side comparisons of the source. Vernon Schryver, vjs@sgi.com
-----------[000107][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Nov 1992 18:16:34 GMT From: ihsan@ferranti.com (jaleel ihsan) To: comp.protocols.tcp-ip Subject: Re: Sun Generic Broadcasting
In article <DERAADT.92Nov5144740@newt.newt.cuc.ab.ca>, deraadt@newt.cuc.ab.ca (Theo de Raadt) writes:
> [Distribution changed from "usa" to "world". Unix is the same in Europe, isn't it??]
>
> In article <1004@math.math.mv.dupont.com> mc@math.math.mv.dupont.com (Matt Cunningham-Software Development) writes:
> > I am trying to find the proper broadcast IP address to send a packet (BOOTP
> > packet to be specific - but the packet type is not important) to so that
> > everyone on the network will receive it.
> [deleted descriptions of numerous attempts to make it work...]
>
> The bind() call will take INADDR_ANY to indicate that it will take a
> connect from any address. It's more difficult when you send packets
> out -- you must indicate _exactly_ where you want to send to. A
> unix machine may have multiple interfaces, with multiple addresses.
> You need to specify the broadcast address for the particular network
> you are interested in. If you wish to send on all the attached networks,
> you need to do multiple send()'s.
^^^^^^^^^^^^^^^^^^
What is the status of TCP broadcasts and mutlicasts ?
-----------[000108][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Nov 1992 20:05:42 GMT From: tga@oar.net (Germann Associates) To: comp.sys.novell,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Request for info 5250 emulator over tcpip for novell
I'm looking for a 5250 emualtor for PC's running over TCP/IP. Either packet drivers or LWP for Dos versions are acceptable. In lieu of that ANY 5250 emulator suggestions that will co-exist with NW would be appreciated. Something like tn3270 from Clarkson University. Thanks in advance. Please reply to eric@tga.com -- ============================================================================ Eric Germann Quote for the campaign: The Germann Associates "Lead, follow, or get out of the eric@tga.com way" - Lee Iacocca
-----------[000109][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Nov 1992 20:28:11 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: FAST!!! TCP-IP Machines
In article <1992Nov10.154228.29047@panther.mot.com>, ronf@panther3.panther.mot.com (Ron Feigen) writes: > Has anybody in netland done research on how fast different platforms process > communication protocols? I am currently working on an application that relies > heavily (very heavily) on TCP-IP. I am currently using Sun SparC II's but I > would really like to know if there are machines that are better suited to my > application. > > Any info would be greatly appreciated!!!! It might help to be more specific. All reasonable machines are now about the same speed--over a 56Kbit/sec link. All good machines are now about the same speed over ethernet--a little more than 1MByte/sec. On the other hand, Cray makes machines that do about 1Gbit/sec. (I have a mental block about the exact numbers, which were over the loopback interface and two flavors of HIPPI.) In between, DEC was showing machines without labels at Interop that were running at about 95Mbit/sec over FDDI. (They said details about the machines would be announced Nov. 10. No doubt everyone has seen the numbers in comp.arch.) Another vendor in a nearby booth (blush) was running somewhat faster, also over FDDI. Vernon Schryver, vjs@sgi.com
-----------[000110][next][prev][last][first]---------------------------------------------------- Date: 10 Nov 1992 21:38:05 GMT From: dank@cco.caltech.edu (Daniel R. Kegel) To: comp.protocols.tcp-ip Subject: Re: Hippi
g91m1969@alpha.ru.ac.za (Thabo Mosala) writes:
>I would like to get hold of the new developed standards for High Performance
>Parallel Interface (Hippi) or where can I get information on the subject ?
A search with Archie reveals:
Host bruno.cs.colorado.edu
Location: /pub/cs/doc/hippi
FILE -rw-r--r-- 748905 Apr 18 00:00 hippi-ph_8.1.ps
etc.
These are the full protocol definition documents, it seems.
- Dan Kegel
-----------[000111][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Nov 1992 21:40:05 GMT From: root@darkside.osrhe.uoknor.edu (Operator) To: comp.protocols.tcp-ip,comp.unix.admin Subject: Re: Limited telnet program?
James Deibele (jamesd@techbook.com) wrote: : I would like to set up a limited telnet program for people to use. : Specifically, I'd like to provide local librarians a way of telneting to : selected online library catalogs via a menu. If the telnet to that site : fails, I would want the telnet program to exit with an error level, : which I could then catch with a shell or program. I don't want people : who use this account to be able to exit to a shell from within telnet, : and I don't want them to be able to telnet elsewhere. : : If someone has seen a program like this, or has a reason why this is a : bad idea*, I'd like to hear about it. It seems like it should be : reasonably secure for both us and the rest of our Internet neighbors. : : Thanks. : : *Please no criticism about how we should give free shell accounts to : anyone who asks for one unless you're prepared to contribute hardware. You can get source code for telnet on ftp.uu.net:/networking/applic/telnet.91.03.25.tar.Z -- ------------------------------------------------------------------------------- Huy Nguyen | "It's not nearly enough to survive, wee@darkside.uoknor.edu | But to live." - M.M. -
-----------[000112][next][prev][last][first]---------------------------------------------------- Date: 10 Nov 92 22:21:53 GMT From: robinson@mdivax1.uucp (Jim Robinson) To: comp.protocols.tcp-ip Subject: Re: Should connect() block after setting NDELAY?
Daniel R. Kegel (dank@blacks.jpl.nasa.gov) wrote:
>
>Hi all,
>I'm writing an application that opens sockets to many servers in parallel
>before sending out a query to each server (also in parallel). It sets
>the sockets into nonblocking mode before the connect() as follows:
> int flags;
> #ifdef USE_FIONBIO
> flags=1;
> netioctl(qp->fds, FIONBIO, (char *)&flags);
> #else
> flags = fcntl(qp->fds, F_GETFL, 0);
> #ifdef USE_O_NDELAY
> flags |= O_NDELAY;
> #else
> flags |= FNDELAY;
> #endif
> fcntl(qp->fds, F_SETFL, &flags);
> #endif
>The problem is, under SunOS 4.1.1, connect() then blocks until a
>accept, reject, or defer response comes back from the server.
>This can take several seconds if the Internet is being slow.
>The local Sun guy was able to see this in the source code, but does not
>consider it a bug. What do you all think- is it reasonable for connect()
>to block for several seconds when the socket is supposedly in nonblocking
>mode?
On a semi-related topic I can say that if, on SunOS 4.1.2, you set the
socket to nonblocking with POSIX O_NONBLOCK, a subsequent connect() will
indeed *block*; i.e., O_NONBLOCK has no effect on the connect().
--
Jim Robinson
robinson@mdd.comm.mot.com
{ubc-cs!van-bc,uunet}!mdivax1!robinson
-----------[000113][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Nov 1992 23:21:43 GMT From: sjs@netcom.com (Stephen Schow) To: comp.protocols.tcp-ip Subject: TCP/IP C Libraries for Macintosh?
Anyone know where I can get information about TCP/IP programming in C on
the Mac and especially any libraries that exist.
Thanks in advance
--
------------------------------------------------------------------
Steve Schow | But you don't have to use the claw, if you
sjs@netcom.com | pick the pear with the big paw paw......
| Have I given you a clue......?
| - Baloo the Bear
------------------------------------------------------------------
-----------[000114][next][prev][last][first]---------------------------------------------------- Date: Wed, 11 Nov 1992 03:31:43 GMT From: tbooth@netcom.com (Todd Booth) To: comp.protocols.tcp-ip Subject: RFD: comp.dcom.sys.wellfleet
This is a formal Request for Discussion on the creation of a new newsgroup
called "comp.dcom.sys.wellfleet" (not moderated).
I forgot to include comp.protocols.tcp-ip in my initial broadcast so now I
will. The original groups were:
Newsgroups: news.announce.newgroups,news.groups,comp.dcom.lans.ethernet,comp.dcom.lans.fddi,comp.dcom.lans.misc,comp.dcom.lans,comp.dcom.cell-relay,comp.dcom.lans.novell
This announcement is cross-posted to newsgroups whose readers may have
interest in the discussion about the new group; follow-up discussion will
take place in "news.groups". Suggestions, comments or problems may also
be emailed to me at <tbooth@netcom.com or tbooth@wellfleet.com>.
REQUEST FOR DISCUSSION
----------------------
NEWSGROUP
comp.dcom.sys.wellfleet (not moderated)
PURPOSE
The newsgroup 'comp.dcom.sys.wellfleet' would be a forum for discussing
issues related to Wellfleet bridge and router systems hardware & software,
interoperability with other products, and system configuration.
It will NOT be a forum for forwarding sensitive information
as e-mail and individual contact are for this purpose.
It could be the best, and quickest way to exchange questions and
answers, hints and tips on optimization, have contacts between users
having common problems and maybe some common solutions.
RATIONALE
Very often Wellfleet users receiving news and having questions don't know
really where to post their questions in such a way that it could be
answered by some other Wellfleet users.
In the same way, people who could be able to answer the question are not
necessarily inspecting all articles where Wellfleet is mentioned, such a
newsgroup will usually permit better follow-ups for Wellfleet issues.
Users could discover lot of indirect Wellfleet matter accidentally in
comp.dcom.lans.{ethernet, fddi, misc...}.
Wellfleet User Groups exist in the U.S. and Europe.
Mailing lists have been going in the U.S and Europe for several years;
but this way of communicating is not particularly adequate for users
of multi-recipient systems, i.e., each message is sent to each registered
user, even on the same systems, moreover each user must ask to be
explicitely registered.
A newsgroup would permit all users of Wellfleet systems receiving the News
to receive only one copy of each message and to share it potentially
with all the users of the systems.
This newsgroup could be a prolongation of each annual Wellfleet User Groups
meetings, permitting not only to those (s)elected people having the chance
to take part to these interesting reunions but also to more common users,
students, researchers, etc... to share their experiences.
In the era of communication, newsgroups are the easiest way to build
bridges across oceans and permitting of people with common interests
to be part of an electronic community wherever they are located
in the world.
CONTENT
Miscellaneaous
- Wellfleet FAQ
- jobs available
- other events that concern Wellfleet systems and/or users
Hardware
- Wellfleet Nodes series
- Wellfleet Backbone Node series
- interfacing 3rd party products to Wellfleet systems
Software
- Public domain SNMP software for management of Wellfleet systems
- Software releases discussion and announcements
- Customization of network configurations for optimal performance
System
- Network integration
- Multi-vendor compatibility
- System tuning
- Benchmarking and performance measurement
System administration
- Security
- How to upgrade between releases
- Remote upgrades
This newsgroup will be in conjunction with the existing mailing lists
to allow users who do not receive News to submit and receive newsgroup
traffic and take part in the discussions.
NAME
comp.dcom.sys.wellfleet seems to be the name fitting the most adequately
the purpose.
NOT MODERATED
In order to have questions answered as fast as possible, this
newsgroup would not need to be moderated and indeed would most
probably be self-moderated.
NEWSGROUP CREATION
The discussion period will be from November 10th, 1992 to December 2nd, 1992.
Please post all discussion in news.group.
If a consensus is reached by the end of the discussion period,
a CFV (Call for Votes) will be posted at that time. The voting period
will last for 21 days.
Thanks for your interest !
Todd Booth | Systems Engineer | Wellfleet Communications, Inc | 310 445-8840
-----------[000115][next][prev][last][first]---------------------------------------------------- Date: 11 Nov 92 04:12:09 GMT From: dank@blacks.jpl.nasa.gov (Daniel R. Kegel) To: comp.protocols.tcp-ip Subject: Re: TCP/IP C Libraries for Macintosh?
sjs@netcom.com (Stephen Schow) writes: >Anyone know where I can get information about TCP/IP programming in C on >the Mac and especially any libraries that exist. There are several socket libraries available for the Mac. 1. a package at ftp.ncsa.uiuc.edu in /misc/unsupported, originally written by Tom Milligan of Toronto, rewritten by creiman@apple.com (Charlie Reiman). For MPW C? 2. Matthias Neeracher <neeri@iis.ethz.ch> has written a Grand Unified Sockets library that tries to make EVERY kind of communication on the Mac available via the socket paradigm. Also for MPW C? 3. hardin@mcc.com (John Hardin) ported one to Think C 5.0, but can't release it yet. And then there's raw MacTCP... but that's another story. - Dan K.
-----------[000116][next][prev][last][first]---------------------------------------------------- Date: Wed, 11 Nov 1992 16:44:06 GMT From: cole@etonic.gsg.dec.com (Larry Cole) To: comp.protocols.tcp-ip Subject: Programmatic Interface to FTP
I have a request from a customer for a programmatic interface to ftp. While not difficult to implement, I have not heard of any UNIX vendors with this capability. Is anyone aware of such an implementation that might be used as a guideline for calling syntax, etc. thanks. larry cole
-----------[000117][next][prev][last][first]---------------------------------------------------- Date: Wed, 11 Nov 1992 18:34:36 GMT From: add@philabs.philips.com (Aninda V. Dasgupta) To: comp.protocols.tcp-ip Subject: TCP Buffer sizes in Routers and packets per second
I have a question for tcp-ip gurus, especially if you are familiar with SunOS. I have the following setup. Sparc II w/ 2 E-net cards _______ | | |-------|Gateway|-------| | | | | Sparc II | |_______| | ______ | | Sparc II | | | | ________ |Sender|-------| |-------| | | | | | |Receiver| |______| | | |________| The gateway is an or'nery Sparc II, with two Ethernet cards on it. I need to send 10 MByte Image files from the sender to the receiver. I set my TCP Transmit and Receive buffer sizes to 50K Bytes. However, the gateway is beyond my control. Do my TCP packets get reassembled at the Gateway? In other words, does the buffer size in the gateway matter in the speed of transfer? I would expect all the routing to be done at the IP layer. Therefore, my TCP buffer sizes should not matter at all, right ? I don't know how this piece of information matters, but I monitored the number of Ethernet Packets on the Sender, the gateway and the Receiver. While Perfmeter showed between 256 and 512 packets per sec. on the sending machine, it showed between 1024 and 2048 pps on the gateway and a constant 1024 pps on the receiver. All three machines were loaded only by my sending and receiving programs. Any insights into this discrepency between the number of pps on the three machines? Thanks for any ideas/answers you can give me. Aninda DasGupta -- Aninda DasGupta (add@philabs.philips.com) Ph:(914)945-6071 Fax:(914)945-6552 Philips Labs\n 345 Scarborough Rd\n Briarcliff Manor\n NY 10510 "Err.., Phillips Petroleum gives you gas; fortunately Pillips Chemical makes antacid. Philips is with one "el", we make lightbulbs. And other shtuff"
-----------[000118][next][prev][last][first]---------------------------------------------------- Date: 11 Nov 92 19:13:16 GMT From: vlei@acp.amdahl.com (Veng Lei) To: comp.protocols.tcp-ip Subject: tcp/ip network performance
Could someone points to me where I can find infomation or discussion related to IP network (for both dialup and leased line cases) performance. Thank you. Veng Lei Amdahl Corporation
-----------[000119][next][prev][last][first]---------------------------------------------------- Date: Wed, 11 Nov 1992 19:20:03 GMT From: hofer@rchland.vnet.ibm.com (Kent Hofer) To: comp.protocols.tcp-ip Subject: Re: Proper Method of Closing IP Sockets
In article <1992Nov7.034406.19500@blaze.cs.jhu.edu>, eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig) writes: |> What is the proper method of closing a socket in order to release |> the socket/port binding? Under SunOS 4.1, my application closes its |> descriptors and exists. If I immediately execute it again, the bind fails |> with errno EADDRINUSE. This isn't related to how you close the socket descriptor: TCP doesn't allow you to re-use a port until (2 * Maximum segment life) time has passed. The work around is to use the SO_REUSEADDR socket option. Add that to your sample program and you should be able to restart the server immediately after killing it. It tells the TCP stack to allow a bind during this "close wait" state. - Kent Hofer hofer@rchland.vnet.ibm.com (my opinions are my own and have nothing to do with my employer)
-----------[000120][next][prev][last][first]---------------------------------------------------- Date: 12 Nov 92 08:26:46 -0600 From: mndot@msus1.msus.edu To: comp.protocols.tcp-ip,comp.protocols.ibm Subject: SNA <-> IP Encapsulation
I am new to this particular news feed so this may have been asked in the past. I am not very familiar with IBM host equipment either. I am trying to provide mainframe connectivity to a number of remote sites. Most of the sites have IBM 3174 (or compatible) remote controllers for SNA communications. This comm. takes place over multidrop 9600 bps lines. We are in the process of installing T1 circuits to all of those same locations. The T1's are primarily IP. Does software exist for the 3174 to allow SNA encapsulation in IP packets? I have seen hints of this scenario on some of the news feeds but I am not sure which ones. Any help with this would be greatly appreciated. -- Al
-----------[000121][next][prev][last][first]---------------------------------------------------- Date: 11 Nov 92 23:22:59 GMT From: jhonan@kralizec.zeta.org.au (Jamie Honan) To: comp.protocols.tcp-ip Subject: Looking for UDP/IP for embedded systems
I am looking for a UDP/IP stack (commercial or freely available) suitable for an embedded system. If you know of any, or have experience with porting such a stack, please email at jhonan@kralizec.zeta.org.au Regards, Jamie Honan
-----------[000122][next][prev][last][first]---------------------------------------------------- Date: Wed, 11 Nov 1992 23:25:35 GMT From: dan@dribble.c-mols.siu.edu (Dan Ellison) To: comp.protocols.tcp-ip,comp.protocols.ibm,comp.os.msdos.apps Subject: print redirector for DOS to remote lpr?
Greetings all. I am interested in getting ahold of a print redirector that will capture the standard LPTn interrupt and redirect the output to a remote lpr server. Does anyone know of such a critter? Any help greatly appreciated and thanks. PS: public domain is preferred but commercial may also be acceptable. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Dan Ellison, Network Spec - Computing Affairs, SIU-C | | Southern Illinois University - Carbondale, IL 62901 | | FAX: (618) 453-3459 - PHONE: (618) 453-6149 |
-----------[000123][next][prev][last][first]---------------------------------------------------- Date: Thu, 12 Nov 92 02:19:05 GMT From: dotytr@nscultrix2.network.com (Ted Doty) To: comp.protocols.tcp-ip Subject: Re: Hippi
The current HIPPI specs are available via annonymous FTP from network.com (I forget the directory, but it's pretty self-evident). - Ted -------------------------------------------------------------------------- Ted Doty, Network Systems Corporation | phone: +1 301 596-2270 8965 Guilford Road, Suite 250 | fax: +1 301 381-3320 Columbia, MD, 21046 USA | voice mail: (800) 233-1485 -------------------------------------------------------------------------- These opinions are my own, not necessarially those of Network Systems.
-----------[000124][next][prev][last][first]---------------------------------------------------- Date: Thu, 12 Nov 1992 04:38:05 GMT From: peterd@tscc2.macarthur.uws.edu.au () To: comp.protocols.tcp-ip,comp.os.os2.apps Subject: IBM TCP/IP 1.2, SLIP fails to dial modem
Hi there all. We have various machines run os/2 2.0 (With service pack) and IBM's TCP/IP 1.2 (With the latest CSD's) The problem :- Using a 9600 baud modem (or any speed modem), the SLIPDIAL -d command doesn't dial the modem. Data is sent to the modem (ie the RD light flashes) but it don't dial :-( (And YES my SLIP.CMD file exists, and is correct.) Anyone out there had similar problems ? -- Peter Degotardi (__) * University of Western Sydney, Macarthur PC Support Programmer /00\ * Computing Centre. Fax +61 46 26-6937 oo * Campbelltown, New South Wales, Australia ! Email p.degotardi@uws.edu.au * Just in case - 'My opinions are all mine !'
-----------[000125][next][prev][last][first]---------------------------------------------------- Date: 12 Nov 92 05:56:49 GMT From: claborne@npg-sd.SanDiegoCA.NCR.COM (Chris Claborne) To: comp.protocols.tcp-ip Subject: SLIP from PC to Netblazer
Has anyone use the Wollongong SLIP driver to connect to a Netblazer? I am
close but can't get it to wrok. One possible problem is that I have to
dial in to the Neblazer first something like Procomm and then exit without
hanging up the line then start the protocal up. Can't get a ping.
... __o
.. -\<,
chris.claborne@sandiegoca.ncr.com ...(_)/(_). CI$: 76340.2422
-----------[000126][next][prev][last][first]---------------------------------------------------- Date: Thu, 12 Nov 1992 16:56:55 From: jbvb@vax.ftp.com (James B. VanBokkelen) To: comp.protocols.tcp-ip Subject: Re: Detecting Dropped Sockets (Why is this hard on PC's?)
In article <49191@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
I don't disagree with your statements, however, I was curious about
the systems you execute on. Specifically, when a process is
terminated, what happens to the open file descriptors? Aren't they
typically "closed"? Doesn't TCP typically map this into a "normal
connection close"?
This is one of the places where attempts to "make network connections look
just like files" start to get rocky. The "close on termination" happens
because 1) close is an operation that already exists, thus it's easy,
2) close is most likely to preserve data and abet debugging, and 3)
close is necessary for overall filesystem consistency. There are many
times I've wished I could find out "file closed during program abort"
from a directory listing, but OS designers haven't gotten that far. TCP
can (and in my opinion, should) be more informative.
... Can you cite an RFC which gives guidelines as to when TCP should
inject an RST on behalf of the application?
As far as I know, none of the relevant RFCs attempt to say anything about
the API to TCP (for fear of getting embroiled in OS Wars). This has
always seemed to be a "goes without saying" issue to me, but maybe it
will be mentioned in a future Host Requirements document.
NOTE - this only works if the peer system does something meaningful
with the receipt of the RST, and of course, the application would
have to be in-sync with the propagation of the RST event.
All "reasonable" TCPs let applications know they've been RST, since that's
the only way to notice when the other system's crashed and rebooted.
This option seems clean and straight-forward. The problem is
I am not aware of implementations "providing and using" a
similar capability.
PC/TCP for DOS provides a "normal close" service to applications which
exit without cleaning up all their connections. If we can detect that
the application was aborted or ^C'ed, we generate RST segments. If
the PC is powered off, we can't do anything.
James B. VanBokkelen 2 High St., North Andover, MA 01845
FTP Software Inc. voice: (508) 685-4000 fax: (508) 794-4488
-----------[000127][next][prev][last][first]---------------------------------------------------- Date: Thu, 12 Nov 1992 15:39:29 GMT From: kro@kvamdata.no (Knut Rogde) To: comp.protocols.tcp-ip,comp.os.os2.networking,comp.os.os2.programmer Subject: TCP_NODELAY after accept()
Hi,
In the process of developing a client server concept based on TCP/IP,
I've come across a problem:
I need to set the TCP_NODELAY option (like the X window system does) in
order to get fast query-response.
I've managed to set this option on the caller side just after making the
socket() call, but I can't make this work on the callee side.
Whent I try to do
{
s = accept(...);
mi=1;
e = setsockopt(s,IPPROTO_TCP,TCP_NODELAY,&mi,sizeof(int));
}
setsockopt returns -1.
I've seen that they do this in X, so it should be possible...
I would appreciate any ideas you might have.
Knut Rogde
--
------------------------------------------------------------------------
Knut Rogde Phone : +47 4 623766
Software engineer Fax : +47 4 623985
Kvam data as Email : kro@kvamdata.no
-----------[000128][next][prev][last][first]---------------------------------------------------- Date: Thu, 12 Nov 1992 15:43:36 GMT From: atkinson@itd.nrl.navy.mil (Randall Atkinson) To: comp.dcom.cell-relay,comp.protocols.tcp-ip Subject: Re: flow control, TCP, and ATM
In article <BxLs14.Gu@usenet.ucs.indiana.edu> robelr@mythos.ucs.indiana.edu writes: >I just want to clarify that my intent was not to dismiss >end-to-end congestion control. Rather, it was to point >out one weakness with CURRENT implementations of TCP (and >by that I mean mainstream commercially available implementations, >not experimental ones). If TCP can be modified so that this >and other weaknesses are fixed, great. Allen, The good vendors already ship a Van Jacobson TCP with their standard product. I believe that SGI is one example of such a vendor. There are other commercial vendors with this. The Van Jacobson TCP is not nearly as experimental these days as your note implies. In fact it is out as a standards track RFC already and is mostly past experimentation. As Rob Warnock pointed out, Jon Crowcroft had an article last January or so (probably in CCR, maybe in IEEE Networks) proposing a way to smooth the TCP oscillation. That proposal is still experimental though the article sounded very well thought out and solidly worked to me. Oscillation of TCP is not a big factor over ATM as near as I can tell at the moment. Ran atkinson@itd.nrl.navy.mil
-----------[000129][next][prev][last][first]---------------------------------------------------- Date: 12 Nov 92 17:34:07 GMT From: dove+@pitt.edu (Daniel L Dove) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: HELP with a Directed Research in TCP/IP,WinTCP
Help, I'm doing a directed research next semester on TCP/IP. If there is anyone out there that can give me any info, FTP sites, etc.... Please let me know. We are run WinTCP. Please send Email dove@unix.csi.pitt.edu dove@vms.cis.pitt.edu Thanks in Advance Dan Dare
-----------[000130][next][prev][last][first]---------------------------------------------------- Date: Thu, 12 Nov 1992 17:49:02 GMT From: wbrand@krishna.shearson.com (Willy Brandsdorfer) To: comp.protocols.tcp-ip,comp.protocols.ibm Subject: Re: SNA <-> IP Encapsulation
In article <1992Nov12.082646.1647@msus1.msus.edu> mndot@msus1.msus.edu writes: > I am new to this particular news feed so this may have been asked in the past. > I am not very familiar with IBM host equipment either. > > I am trying to provide mainframe connectivity to a number of remote sites. > Most of the sites have IBM 3174 (or compatible) remote controllers for SNA > communications. This comm. takes place over multidrop 9600 bps lines. We are > in the process of installing T1 circuits to all of those same locations. The > T1's are primarily IP. Does software exist for the 3174 to allow SNA > encapsulation in IP packets? I have seen hints of this scenario on some of the > news feeds but I am not sure which ones. Any help with this would be greatly > appreciated. Cisco routers support SNA encapsulation. ---------------------------------------------------------------------- William Brandsdorfer | UUCP: !uunet!shearson.com!wbrand Lehman Brothers | INET: wbrand@shearson.com 388 Greenwich St. | Voice: (212) 464-3835 New York, N.Y. 10013 | ----------------------------------------------------------------------
-----------[000131][next][prev][last][first]---------------------------------------------------- Date: 12 Nov 1992 17:50:53 GMT From: aj639@cleveland.Freenet.Edu (Michael Cox) To: comp.protocols.tcp-ip Subject: Scott Bradner's Bridge/Router Results
Does anyone know Scott or know where I can get ahold of the results of his testing? I think he did it in Jan/Feb of 92. Please email me with any leads. Thanks in advance!! Mike -- Okay, look for AmoNER #5 on: ux1.cso.uiuc.edu (128.174.5.59) in /amiga/amoner nic.funet.fi (128.214.6.100) in /pub/amiga/programming/amos Je suis venu ici pour macher du chewing-gum et pour botter des fesses. Et maintenant, je n'ai plus de chewing-gum . . .
-----------[000132][next][prev][last][first]---------------------------------------------------- Date: Thu, 12 Nov 1992 18:34:38 GMT From: rks@chiasmus.engin.umich.edu (Raul Shum) To: comp.protocols.tcp-ip,comp.os.os2.apps Subject: Re: IBM TCP/IP 1.2, SLIP fails to dial modem
Well, I have somewhat the same problem... My computer has a direct connection to a SCP, (yes they do still exist). Howver, I have to engage the SCP from a vt100 to a SLIP protocal. To do that, I have to type SLIP when I dial in. However, IBM's TCP/IP doesn't let you do that. Furthermore, I've been trying to call using a modem and setting up the connection, and then hook up TCP/IP. However, the COM port resets itself after the prog closes, so the SCP resets itself. Does anyone know of a way to get a prog or a REXX script that keeps the COM port (ie COM1) open??? I talked to the head-honcho at IBM, and all he said was that I had to rewire my COM port... However, I was not your typical re-wiring... Anyway, thanx in advance... Raul Shum Go Maize and Blue!
-----------[000133][next][prev][last][first]---------------------------------------------------- Date: 12 Nov 92 19:13:00 GMT From: jc@minya.UUCP (John Chambers) To: comp.protocols.tcp-ip Subject: Is telnet protocol documented?
Well, it wasn't as easy as I thought it might be, so I thought I'd ask
the experts...
Does anyone know (or know of documentation on) how a program might
talk to telnetd and make a connection?
What the project involves is: I have a chunk of code that was written
to call out via a serial port, modem, and whatever, to make a link to
another computer, login, start up a remote daemon, and so on. Sorta
like your usual uucp or slip daemons, y'know. Someone was asking "How
hard would it be to make this software talk across TCP?" I opined as
how it shouldn't be too hard; I'd just find all the code that dealt
with a serial port, and write some parallel code to do TCP instead.
Rather than open("/dev/%s",...), I'd have it call gethostbyname("%s"),
and similar stuff.
It wasn't too hard to do this (maybe a day's work), and it all worked
fine, except that when the connect() returned success and the program
wrote something down the line, instead of a "login:" that I get when I
type "telnet %s", it gets utter garbage. The garbage is quite
consistent: It consists of the 3 bytes FF FD 18, and then it gets
nothing else. Eventually the connection goes away, as if telnetd had
given up in disgust or something.
When I put my own tcpserver on the other end (which just accepts
connections and echoes back whatever it receives), then my client
program gets just what I expect. (If I tell the client to send "Hello
there!\r", tcpserver gets back exactly those bytes, it's log shows
that it got them and echoed them, and the client reports getting
them.) This is proof that it is making the connection correctly, and
is able to exchange messages sanely with whatever is at the other end.
But if it's telnetd at the other end, my client just gets the FF FD
18, and the link goes nowhere. It seems obvious that telnetd is doing
some sort of binary handshake on startup. But I haven't found any
description of what it might be in TFM, or in the few RFCs that I have
copies of.
Now I suppose I could just write my own verion of telnetd that does
things in a way that I understand. But telnetd is already there as
off-the-shelf (or is it off-the-wall? ;-) software on zillions of
machines, so why reinvent the wheel, as they say?
Any idea how I might get documentation of telnetd's protocol? Is there
an RFC on it that someone can email me? Is there some PD code that
does the protocol? Or is it some proprietary stuff that isn't for the
likes of me?
[Meanwhile, maybe I'll just barge ahead with making my own daemon, for
cases where telnetd isn't there or can't be made sane or ... ;-]
--
All opinions Copyright (c) 1992 by John Chambers. Inquire for licensing at:
1-617-647-1813 ...!{bu.edu,harvard.edu,eddie.mit.edu,ruby.ora.com}!minya!jc
--
Pensu tutmonde; agu loke.
-----------[000134][next][prev][last][first]---------------------------------------------------- Date: Thu, 12 Nov 1992 20:07:23 GMT From: klf@fssun09.dev.oclc.org (Kim Fortney) To: comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip Subject: Requesting info on DNS
I'm currently looking into modifying DNS for adding a load balancing capability. This would allow Internet users to access our systems using a single IP address. I'm looking for a reference to a version of public domain source code. Any pointers you can give would be greatly appreciated. Thanks. Kim Fortney (klf@oclc.org) OCLC 6565 Frantz Road Dublin, Ohio 43017
-----------[000135][next][prev][last][first]---------------------------------------------------- Date: 12 Nov 92 23:22:03 GMT From: jallard@microsoft.com (James 'J' Allard) To: comp.protocols.tcp-ip Subject: Re: Programmatic Interface to FTP
In article <1992Nov11.164406.22599@decuac.dec.com> cole@gsg.dec.com writes: > >I have a request from a customer for a programmatic interface to >ftp. While not difficult to implement, I have not heard of >any UNIX vendors with this capability. Is anyone aware of >such an implementation that might be used as a guideline >for calling syntax, etc. A number of PC vendors provide programmatic APIs for FTP. Off the top my head, I'd recommend you try Net Manage and Distict for examples.. J. Allard Microsoft Corp. (jallard@microsoft.com)
-----------[000136][next][prev][last][first]---------------------------------------------------- Date: Fri, 13 Nov 1992 00:22:09 GMT From: hank@ducvax.auburn.edu To: comp.protocols.tcp-ip,comp.os.os2.apps Subject: Re: IBM TCP/IP 1.2, SLIP fails to dial modem
In article <1992Nov12.183438.26104@zip.eecs.umich.edu>, rks@chiasmus.engin.umich.edu (Raul Shum) writes: > However, IBM's TCP/IP doesn't let you do that. Furthermore, I've been trying > to call using a modem and setting up the connection, and then hook up TCP/IP. > However, the COM port resets itself after the prog closes, so the SCP > resets itself. Does anyone know of a way to get a prog or a REXX script that > keeps the COM port (ie COM1) open??? I talked to the head-honcho at IBM, and > all he said was that I had to rewire my COM port... However, I was not your I'm not certain that I understand the more subtle points here, but... Look, for example, at C-Kermit and M2Zmodem. C-Kermit can shell to M2Zmodem, and M2Zmodem gets the com port. This won't work for just any programs, but if your app can be passed the handle for the com port, you could login with C-Kermit, then shell to your program. -- --Darrel Hankerson hank@ducvax.auburn.edu
-----------[000137][next][prev][last][first]---------------------------------------------------- Date: Fri, 13 Nov 1992 03:08:11 GMT From: ss@panix.com (Steve Steinberg) To: comp.protocols.tcp-ip,comp.protocols.nfs,comp.unix.ultrix Subject: Need PCNFSD for DEC Ultrix
Can someone point me to PCNFSD for ultrix? Preferebly one that would
work under miscd. This would be for PC/TCP's Idrive.
Thanks!
--
=====================================================================
=== Steve Steinberg == ss@panix.com == {cmcl2,apple}!panix!ss ===
(The space below intentionally left blank)
-----------[000138][next][prev][last][first]---------------------------------------------------- Date: 13 Nov 92 03:37:19 GMT From: ddl@burrhus.harvard.edu (Dan Lanciani) To: comp.protocols.tcp-ip Subject: Re: Detecting Dropped Sockets (Why is this hard on PC's?)
In article <921112165655@cream.ftp.com>, jbvb@vax.ftp.com (James B. VanBokkelen) writes: | In article <49191@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes: | | I don't disagree with your statements, however, I was curious about | the systems you execute on. Specifically, when a process is | terminated, what happens to the open file descriptors? Aren't they | typically "closed"? Doesn't TCP typically map this into a "normal | connection close"? | | This is one of the places where attempts to "make network connections look | just like files" start to get rocky. The "close on termination" happens | because 1) close is an operation that already exists, thus it's easy, | 2) close is most likely to preserve data and abet debugging, and 3) | close is necessary for overall filesystem consistency. There are many | times I've wished I could find out "file closed during program abort" | from a directory listing, but OS designers haven't gotten that far. TCP | can (and in my opinion, should) be more informative. Curiously enough, the old 2.9BSD (aka 4.1c) networking code went to some lengths to get an indication of whether a socket was closed explicitly by the process. As I recall, this involved a new argument to the internal kernel closef() function and, of course, changes to every call to said function. The argument was passed as true when the process actually called close() and false when closef() was invoked as part of exit handling. (It may not have been completely obvious which way things went on an implicit close caused by, e.g., dup2(). :) After all this bother, the tcp/ip code did very little with the information. I don't remember whether this was because of a real bug or because of a ``fix'' to correct problems caused by doing something extreme like sending RST. The original intent was almost certainly to prevent processes from getting hung in an exiting state, rather than to inform the peer that something funny had happened. In any case, the code disappeared long before 4.3BSD but at least it has been tried... Dan Lanciani ddl@harvard.*
-----------[000139][next][prev][last][first]---------------------------------------------------- Date: 13 Nov 1992 14:40:07 -0600 From: CIR_TLW@VAX1.UTULSA.EDU (Tristia Watson) To: comp.protocols.tcp-ip Subject: TCP/IP Print Drivers?
We have an problem to which we are sure there has to be a solution...but
have no idea what that solution might be...
We have a Zenith 486, with a Cabletron Card (network connection) and we
would like to print from Windows 3.1 to a DEC LPS400 using TCP/IP
connections. We would like to be able to do this without Pathworks or
Novell or any kind of other "formal" network...besides TCP/IP. The problem
that we are seeing is that Windows doesn't have the necessary print
drivers. Are there any TCP/IP-only drivers that might help, either public
domain or otherwise? Any other ideas that might be useful?
+---------------------------------------------------------------------+
| Tristia Watson CIR_TLW@VAX1.UTULSA.EDU |
| Client Support Coordinator HELP@VAX1.UTULSA.EDU |
| Computing & Information Resources Help Desk Phone: 631-3500 |
+---------------------------------------------------------------------+
-----------[000140][next][prev][last][first]---------------------------------------------------- Date: 13 Nov 92 12:21:41 GMT From: petter@fdmetd.uucp (Petter Henrik Hansen) To: comp.protocols.tcp-ip Subject: Information wanted
Does anyone have any information, or know where to get some info about a product calles xcon 62? xcon 62 (TCP/IP -> LU6.2) Thanks Petter Henrik Hansen, Fellesdata a.s, P.O. Box 248, 0212 OSLO 2, NORWAY Phone : +47 2 52 84 02 Fax : +47 2 52 85 10 E-mail : ...!mcsun!nuug!fdmetd!petter or petter@fdmetd.uucp or petter%fdata.uucp@nac.no <The opinions expressed, if any, do not represent Fellesdata a.s>
-----------[000141][next][prev][last][first]---------------------------------------------------- Date: Fri, 13 Nov 1992 17:24:00 GMT From: modic@gumby.dsd.trw.com (Jeanine A. Modic-Carmona) To: comp.protocols.ibm,comp.protocols.tcp-ip Subject: NFS
Hi! I was wondering if anyone has tried to backup a PC or Mac to an IBM mainframe via TCP/IP? If so, how? I have tried backing up my PC to the IBM mainframe with NFS. The IBM mainframe involved has Interlink's SNS/TCPaccess TCP/IP software and Interlink's SNS/NFS. First, I created an NFS connection from my PC to the IBM mainframe and tried to XCOPY my PC's hard disk to the designated NFS drive (allocated as the mainframe) i.e. XCOPY c: g: /s /e. It would only copy my current directory and nothing more. Then I tried to FTP my PC's whole hard disk. Is there way to FTP the whole hard disk of a PC to the mainframe? I could only again find a way to FTP one directory at a time. I am using FTP's PC/TCP software. I would really appreciate anyone's ideas or if anyone is doing this, how. Please send all responsess to modic@gumby.dsd.trw.com Thanks, Jeanine Jeanine Modic TRW Communication Services modic@gumby.dsd.trw.com Redondo Beach, California Newsgroups: comp.protocols.ibm comp.protocols.tcp-ip Subject: NFS Distribution: trw Hi! I was wondering if anyone has tried to backup a PC or Mac to an IBM mainframe via TCP/IP? If so, how? I have tried backing up my PC to the IBM mainframe with NFS. The IBM mainframe involved has Interlink's SNS/TCPaccess TCP/IP software and Interlink's SNS/NFS. First, I created an NFS connection from my PC to the IBM mainframe and tried to XCOPY my PC's hard disk to the designated NFS drive (allocated as the mainframe) i.e. XCOPY c: g: /s /e. It would only copy my current directory and nothing more. Then I tried to FTP my PC's whole hard disk. Is there way to FTP the whole hard disk of a PC to the mainframe? I could only again find a way to FTP one directory at a time. I am using FTP's PC/TCP software. I would really appreciate anyone's ideas or if anyone is doing this, how. Please send all responsess to modic@gumby.dsd.trw.com Thanks, Jeanine Jeanine Modic TRW Communication Services modic@gumby.dsd.trw.com Redondo Beach, California Newsgroups: comp.protocols.ibm, comp.protocols.tcp-ip Subject: NFS Distribution: trw Hi! I was wondering if anyone has tried to backup a PC or Mac to an IBM mainframe via TCP/IP? If so, how? I have tried backing up my PC to the IBM mainframe with NFS. The IBM mainframe involved has Interlink's SNS/TCPaccess TCP/IP software and Interlink's SNS/NFS. First, I created an NFS connection from my PC to the IBM mainframe and tried to XCOPY my PC's hard disk to the designated NFS drive (allocated as the mainframe) i.e. XCOPY c: g: /s /e. It would only copy my current directory and nothing more. Then I tried to FTP my PC's whole hard disk. Is there way to FTP the whole hard disk of a PC to the mainframe? I could only again find a way to FTP one directory at a time. I am using FTP's PC/TCP software. I would really appreciate anyone's ideas or if anyone is doing this, how. Please send all responsess to modic@gumby.dsd.trw.com Thanks, Jeanine Jeanine Modic TRW Communication Services modic@gumby.dsd.trw.com Redondo Beach, California Newsgroups: comp.protocols.ibm comp.protocols.tcp-ip Subject: NFS Distribution: trw Hi! I was wondering if anyone has tried to backup a PC or Mac to an IBM mainframe via TCP/IP? If so, how? I have tried backing up my PC to the IBM mainframe with NFS. The IBM mainframe involved has Interlink's SNS/TCPaccess TCP/IP software and Interlink's SNS/NFS. First, I created an NFS connection from my PC to the IBM mainframe and tried to XCOPY my PC's hard disk to the designated NFS drive (allocated as the mainframe) i.e. XCOPY c: g: /s /e. It would only copy my current directory and nothing more. Then I tried to FTP my PC's whole hard disk. Is there way to FTP the whole hard disk of a PC to the mainframe? I could only again find a way to FTP one directory at a time. I am using FTP's PC/TCP software. I would really appreciate anyone's ideas or if anyone is doing this, how. Please send all responsess to modic@gumby.dsd.trw.com Thanks, Jeanine Jeanine Modic TRW Communication Services modic@gumby.dsd.trw.com Redondo Beach, California
-----------[000142][next][prev][last][first]---------------------------------------------------- Date: Fri, 13 Nov 92 18:31:28 GMT From: sgriffee@nynexst.com (Steve Griffee) To: comp.protocols.tcp-ip Subject: remote tcp/ip LAN access ideas
thanks Steve The opinions above are my own and do not reflect those of my employer. _________________________________________________________________ Steve Griffee sgriffee@nynexst.com NYNEX Science and Technology Data & Information Services 500 Westchester Avenue 914-644-2531 fax: 914-644-2301 White Plains, NY 10604 This is your email. This is your brain on email. Any questions? -- The opinions above are my own and do not reflect those of my employer. _________________________________________________________________ Steve Griffee sgriffee@nynexst.com NYNEX Science and Technology Data & Information Services 500 Westchester Avenue
-----------[000143][next][prev][last][first]---------------------------------------------------- Date: Fri, 13 Nov 1992 19:18:05 GMT From: davecb@nexus.yorku.ca (David Collier-Brown) To: comp.protocols.tcp-ip Subject: Can anyone point me to info about ``Fibre Channel''
I confess I'm terribly ignorant of almost everything about fibre channel save its speed. Can anyone point me toward information on it? I know that there ia an ANSI comittee, X3T9.3, and that 9.5 is FDDI, but I don't know hat 9.3 is... If it's a common question, I'll post the answers (:-)) --dave (and can you run ip over it!!) c-b -- David Collier-Brown, | davecb@CCS.YorkU.CA | lethe!dave 72 Abitibi Ave., | Willowdale, Ontario, | York Postmaster and CANADA. 416-223-8968 | occasional email consultant.
-----------[000144][next][prev][last][first]---------------------------------------------------- Date: Fri, 13 Nov 1992 20:33:09 GMT From: henry@zoo.toronto.edu (Henry Spencer) To: comp.protocols.tcp-ip Subject: Re: Is telnet protocol documented?
In article <1391@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
>...except that when the connect() returned success and the program
>wrote something down the line, instead of a "login:" that I get when I
>type "telnet %s", it gets utter garbage. The garbage is quite
>consistent: It consists of the 3 bytes FF FD 18...
Uh, telnet is a *protocol*; it is not an uninterpreted data path. You're
looking at a telnet option-negotiation sequence.
>Any idea how I might get documentation of telnetd's protocol? Is there
>an RFC on it that someone can email me? ...
You get documentation on telnet the same way you get documentation on
any of the Internet protocols: read the relevant RFCs. For telnet, it
starts with RFC 854. Actually, you probably want to look at the telnet
section of RFC 1123 first, as there are a whole bunch of telnet-related
RFCs and you need to know which ones matter.
--
MS-DOS is the OS/360 of the 1980s. | Henry Spencer @ U of Toronto Zoology
-Hal W. Hardenbergh (1985)| henry@zoo.toronto.edu utzoo!henry
-----------[000145][next][prev][last][first]---------------------------------------------------- Date: Fri, 13 Nov 1992 21:33:08 GMT From: mlikier@novell.com (Marty Likier) To: comp.protocols.tcp-ip Subject: Re: Scott Bradner's Bridge/Router Results
In article <1du5huINNu6@usenet.INS.CWRU.Edu> aj639@cleveland.Freenet.Edu (Michael Cox) writes: > >Does anyone know Scott or know where I can get ahold of the results of his >testing? I think he did it in Jan/Feb of 92. Please email me with any >leads. Thanks in advance!! > >Mike Scott just finished the fall 92 results. They can be anonymous FTPd from hsdndev.harvard.edu (128.103.202.40). They are in the directory pub/ndtl. Marty Likier
-----------[000146][next][prev][last][first]---------------------------------------------------- Date: 14 Nov 92 01:22:42 GMT From: andrew@frip.WV.TEK.COM (Andrew Klossner) To: comp.unix.misc,comp.protocols.tcp-ip,comp.lang.postscript Subject: Re: problems tfping to a rip
[]
"The reason seems to be that the UDP checksum is wrong.
normally this checksum is correct, but the troublesome packets
always have 0xFFFF for checksum. if my calculations are correct
it should be 0x0 instead."
No, a UDP checksum is never 0. If the calculation yields 0, then
0xFFFF is stored instead. Perhaps the code in the RIP is flawed and
does not include this provision. A 0 in the UDP checksum field means
"no checksum was computed."
From RFC768, the defining document for UDP:
> If the computed checksum is zero, it is transmitted as all ones (the
> equivalent in one's complement arithmetic). An all zero transmitted
> checksum value means that the transmitter generated no checksum (for
> debugging or for higher level protocols that don't care).
"What is your solution"
Convince the Intel machine not to generate UDP checksums. On the Suns,
whether or not to UDP checksum is controlled by a variable in the
kernel; you use adb or equivalent to patch it. Check with your Intel
rep to see if they have something equivalent.
In the long term, you should ask Linotype to fix their broken UDP
implementation.
-=- Andrew Klossner (andrew@frip.wv.tek.com)
(uunet!tektronix!frip.WV.TEK!andrew)
-----------[000147][next][prev][last][first]---------------------------------------------------- Date: 14 Nov 92 01:29:46 GMT From: kdlin@advtech.uswest.com (David Lin) To: comp.protocols.tcp-ip Subject: Flow Control
I understand that many end-to-end sliding window flow control schemes ( eq. in TCP/IP and in XTP ) use byte as the unit for calculation. For example, if the window size is 6K bytes and you have transmitted 2K bytes without receiving ACKs from the receiver, then you are allowed to transmit 4K more bytes. Now, if I change the unit for flow control calculation to packet ( or frame ), what is the impact to the whole system? What's the implication? Since most networks have an upper limit for the frame size ( <= MTU ), I cannot transmit unlimited-size packets. Consequently, I will be treating any packets of size in between 1 and MTU equally, as far as flow control is concerned. I understand that interactive traffic will be affected first. However, packet video and packet voice may not be affected at all, especially when they have real time delivery requirement. So why am I doing this? I think it will simplify the computation needed for the flow control mechanism. Three more questions follow: 1. Are there any circumstances that this scheme ( using packet as the computation unit ) is desirable? 2. When it is NOT desirable? 3. Do I really achieve anything by doing that? Many thanks. David -- K. David Lin, Ph.D. | E-mail: kdlin@advtech.uswest.com Communication Services Research | Defend your life with style! -- Beretta U S WEST Advanced Technologies | Disclaimer: Only personal opinions
-----------[000148][next][prev][last][first]---------------------------------------------------- Date: 15 Nov 1992 18:05:59 GMT From: tomb@studsys.mscs.mu.edu (Tom Baas) To: comp.protocols.tcp-ip Subject: can't do a dir when ftp login as anonymous(HELP)
hi, When I do an ftp to my system and login as anonymous, I get logged in fine, but when I try to do a dir, I get: 425 Can't create data socket(0.0.0.0,20): no such file or directory Can anyone tell me what I am doing wrong? I am running under ISC Unix and whether I do an ftp to localhost or if I telnet to another machine and then ftp back, I still get the same results. Thanks to anyone in advance. :) tom@tbaas.mil.wi.us or tbaas!tom or tom@tbaas -- I can accept e-mail and Voice-mail at: tbaas!tom or tom@tbaas.mil.wi.us or ...spool!tbaas!tom or Voice at: 1-414-377-4038
-----------[000149][next][prev][last][first]---------------------------------------------------- Date: 15 Nov 92 22:49:21 GMT From: john@iastate.edu (John Hascall) To: comp.protocols.tcp-ip Subject: Re: can't do a dir when ftp login as anonymous(HELP)
tomb@studsys.mscs.mu.edu (Tom Baas) writes: }When I do an ftp to my system and login as anonymous, I get logged in fine, }but when I try to do a dir, I get: }425 Can't create data socket(0.0.0.0,20): no such file or directory }Can anyone tell me what I am doing wrong? }I am running under ISC Unix and whether I do an ftp to localhost or }if I telnet to another machine and then ftp back, I still get the same results. Is ~ftp/bin/ls present and correctly permissioned? John -- John Hascall ``An ill-chosen word is the fool's messenger.'' Systems Software Engineer Project Vincent Iowa State University Computation Center + Ames, IA 50011 + 515/294-9551
-----------[000150][next][prev][last][first]---------------------------------------------------- Date: 15 Nov 92 23:15:32 GMT From: sl870@europa.ee.usu.edu (ullas gargi) To: comp.protocols.tcp-ip Subject: Name Server Lookup: No. to Name?
Hi, How does one convert an internet no. (address) to an internet (canonical) name? NSLOOKUP doesnt seem to have an option for it, only for the other way round of direct name lookup, not the reverse lookup. (I couldn't find the FAQ in case this is in there) Thanks Ullas Gargi sl870@europa.ee.usu.edu
-----------[000151][next][prev][last][first]---------------------------------------------------- Date: Mon, 16 Nov 92 04:29:01 EST From: seths@schroedinger.engin.umich.edu (seth raynard silverman) To: comp.protocols.tcp-ip Subject: PPP Packet Driver for PC/TCP?
[ Article crossposted from comp.protocols.tcp-ip.ibmpc ] [ Author was seth raynard silverman ] [ Posted on Mon, 16 Nov 92 04:25:51 EST ] I was wondering if anyone knows of a Packet Driver for the PPP protocol. I need it to work the ETHDRV kernel of PC/TCP for DOS v2.01. I was told that FTP software has released PPP support in version 2.1, but I was hoping that something was available that will work with my version. Also, I am looking for a way to automatically configure the IP address of my PC when using a SLFP (Serial Line Framing Protocol) packet driver. I have been told about RARP, but I am not aware of any RARP packages that work with PC/TCP. Any help would be greatly appreciated. Seth Silverman e-mail: seths@eecs.umich.edu
-----------[000152][next][prev][last][first]---------------------------------------------------- Date: Mon, 16 Nov 92 03:28:41 GMT From: act@softserver.canberra.edu.au (Andrew Turner) To: comp.protocols.tcp-ip Subject: Getting the ethernet address off (SMC)WD8003E Lan Cards
Would someone please e-mail(I'll on-forward if you too want same - e-mail requests) a code fragment assembler/pascal/C that will return the ethernet address from an WD8003E card. Technical specs and/or info on where I could get the info would also be welcome. I need this info to produce a PC management program which will use the ethernet address as the PC identifier. Many Thanks -- Renrut Werdna Probable-Possible, my black hen, She lays eggs in the Relative When. She doesn't lay eggs in the Positive Now act@ss.canberra.edu.au Because she's unable to postulate how
-----------[000153][next][prev][last][first]---------------------------------------------------- Date: Mon, 16 Nov 1992 03:56:27 GMT From: skl@wimsey.bc.ca (Samuel Lam) To: comp.protocols.tcp-ip Subject: Re: Name Server Lookup: No. to Name?
In article <1992Nov15.171533.60873@cc.usu.edu>, sl870@europa.ee.usu.edu (ullas gargi) wrote: >How does one convert an internet no. (address) to an internet (canonical) name? >NSLOOKUP doesnt seem to have an option for it, only for the other way round of >direct name lookup, not the reverse lookup. Let's say the IP address you want to map to a domain name is [11.22.33.44], the following sequence would do it. nslookup set q=ptr 44.33.22.11.in-addr.arpa. ^D Note that while the IP address is [11.22.33.44], its corresponding name inside the reverse lookup domain .IN-ADDR.ARPA is 44.33.22.11 (reverse order). ...Sam -- <skl@wimsey.bc.ca> -- Connectivity Technology Inc.
-----------[000154][next][prev][last][first]---------------------------------------------------- Date: Mon, 16 Nov 1992 04:43:18 GMT From: karl@ddsw1.mcs.com (Karl Denninger) To: comp.protocols.tcp-ip Subject: Re: Name Server Lookup: No. to Name?
In article <1992Nov15.171533.60873@cc.usu.edu> sl870@europa.ee.usu.edu (ullas gargi) writes: >Hi, > >How does one convert an internet no. (address) to an internet (canonical) name? >NSLOOKUP doesnt seem to have an option for it, only for the other way round of >direct name lookup, not the reverse lookup. >(I couldn't find the FAQ in case this is in there) The domain name for 128.1.2.3's "reverse lookup" is: 3.2.1.128.in-addr.arpa. That's right. Reverse the octets, and add "in-addr.arpa" to the end. Ask for that with record type "PTR". You'll get the name associated with the IP number (assuming the DNS administrator for that domain correctly set up the DNS system). -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Data Line: [+1 312 248-0900] Anon. arch. (nuucp) 00:00-06:00 C[SD]T Request file: /u/public/sources/DIRECTORY/README for instructions
-----------[000155][next][prev][last][first]---------------------------------------------------- Date: Mon, 16 Nov 1992 09:29:16 GMT From: skl@wimsey.bc.ca (Samuel Lam) To: comp.protocols.tcp-ip Subject: Re: Getting the ethernet address off (SMC)WD8003E Lan Cards
In article <1992Nov16.032841.7572@csc.canberra.edu.au>,
act@softserver.canberra.edu.au (Andrew Turner) wrote:
>Would someone please e-mail a code fragment assembler/pascal/C
>that will return the ethernet address from an WD8003E card.
unsigned int i, sum = 0, io_base = 0x...;
unsigned char eprom[8];
...
for (i = 0; i < 8; i++)
sum += (eprom[i] = inportb(io_base + 8 + i));
sum &= 0x00ff;
if (sum != 0xff)
/* checksum failed, possibly no board there */
else
printf("MAC address = %02x:%02x:%02x:%02x:%02x:%02x\n",
eprom[0], eprom[1], eprom[2], eprom[3], eprom[4], eprom[5]);
If you use a Packet, NDIS or ODI driver to access your card, you
could also call the driver to query for the MAC address instead of
asking the card directly as in the above.
>Technical specs and/or info on where I could get the info would also be
>welcome.
SMC/WD provides a driver development kit to those who want to write
codes to talk to the card directly.
...Sam
--
<skl@wimsey.bc.ca> -- Connectivity Technology Inc.
-----------[000156][next][prev][last][first]---------------------------------------------------- Date: 16 Nov 92 11:28:27 GMT From: HS99@music.mus.polymtl.ca (S. Guimont) To: comp.protocols.tcp-ip Subject: IRC (Internet Relay Chat) protocol need
Hello,
Where I can find the IRC (Internet Relay Chat) protocol?
(Or if somebody have it, Please send me...)
Thanks!
Regards, S. Guimont
RDI - Research and Development Informatik
Internet : hs99@music.mus.polymtl.ca
Bitnet : hs99@polytec1.bitnet
-----------[000157][next][prev][last][first]---------------------------------------------------- Date: 16 Nov 92 12:03:00 GMT From: gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546) To: comp.protocols.tcp-ip Subject: X.25 X.29 software wanted for RS6000
Hi, I've been entasked with locating software which runs on an RS6000 under AIX and which provides X.25 connectivity (serial 56Kbps links) and X.29 PAD (incoming and outgoing) as well as application hooks (like sockets). Can anyone here direct me to who makes or sells such software? Ehud -- Ehud Gavron (EG76) gavron@vesta.sunquest.com "If the OSI developers are sending mail to each other, they're probably doing it over TCP/IP :-)" -- Gary Scott Malkin
-----------[000158][next][prev][last][first]---------------------------------------------------- Date: 16 Nov 92 14:01:33 GMT From: yan_arrouye@gateway.qm.apple.com (Yan Arrouye) To: comp.protocols.tcp-ip Subject: Public dom impl of RFC1006 for MacTCP?
Is there any public domain implementation of RFC 1006 on top of MacTCP ? Otherwise do you know any easy to port public domain implementartion of RFC 1006? Thanks Yan
-----------[000159][next][prev][last][first]---------------------------------------------------- Date: Mon, 16 Nov 1992 14:49:04 GMT From: rjberke@berke.itg.ti.com (Richard Berke) To: comp.protocols.tcp-ip Subject: FAQ - SLIP vs SLFP vs PPP
What are significant differences among those three? If your workstation and its software can support all of them, which would you choose? Why? Thanks, Richard Berke RBRK Richard.Berke@lobby.ti.com (214) 575-2828 Texas Instruments Plano, Texas -------------------------------------------------------------------------
-----------[000160][next][prev][last][first]---------------------------------------------------- Date: Mon, 16 Nov 92 19:08:58 GMT From: sgriffee@nynexst.com (Steve Griffee) To: comp.protocols.tcp-ip Subject: remote tcp/ip LAN access ideas
I'm looking for ideas for connecting remote PC and MAC workstations to our TCP/IP LAN using regular dial-up phone lines. I've seen all the usual asynch access devices. I'm looking at the relatively hi bandwidth facilities such as ISDN. For example, so far I have found out about the IMAC ISDN bridge made by DigiBoard and the RLN asynch bridge (using hi speed modems and regular phone lines) made by DCA which uses the PPP protocol. Has anyone else found any interesting means of connecting remote offices or workstations to the LAN? Let's swap discoveries. Can We Talk? Please respond directly to my email address below. I will summarize all submitted responses if requested. Watch out. Telecommuting may be just around the bend for your company. Don't let it catch you asleep at the wheel. Thanks Steve The opinions above are my own and do not reflect those of my employer. _________________________________________________________________ Steve Griffee sgriffee@nynexst.com NYNEX Science and Technology Data & Information Services 500 Westchester Avenue 914-644-2531 fax: 914-644-2301 White Plains, NY 10604 This is your email. This is your brain on email. Any questions? -- The opinions above are my own and do not reflect those of my employer. _________________________________________________________________ Steve Griffee sgriffee@nynexst.com NYNEX Science and Technology Data & Information Services 500 Westchester Avenue
-----------[000161][next][prev][last][first]---------------------------------------------------- Date: Mon, 16 Nov 1992 22:37:38 GMT From: jon.taylor@uuserv.cc.utah.edu (JON M. TAYLOR) To: comp.protocols.tcp-ip Subject: Looking for a UNIX TELNET with Zmodem
Title sez it all. Does such a beast exist anywhere?
-----------[000162][next][prev][last][first]---------------------------------------------------- Date: Mon, 16 Nov 1992 23:55:22 GMT From: nancyf@sug.org (Nancy Frishberg) To: comp.protocols.tcp-ip,ba.internet Subject: Tutorials (12/7, San Jose) Internet & Protocols, Network Debugging (Sun User Group Conference)
If you're interested in the structure and protocols of the Internet or debugging Sun networks, plan to be at the Sun User Group Conference (San Jose Convention Center) on Monday, December 7, 1992. The Conference and Exhibition extends through Thursday. "The Internet and its Protocols" is one of nine tutorials currently scheduled for the first day of the Sun User Group Conference. Taught by William LeFebvre (Northwestern University), the course will use Douglas Comer's text "Internetworking with TCP/IP" and will cover important protocols, packet routing, client-server model of interaction and more. Concurrently, Smoot Carl-Mitchell (Texas Internet Consulting) will discuss "Sun Network Debugging" focusing on built-in network debugging tools. Other topics include diagnosing routing problems, nameservice problems, networking snooping with Ping and other tools, and broadcast storms on Ethernets. SPECIAL OFFER: 5 full conference registrations (each includes a day of any tutorial) for the price of 4 when preregistering with a single payment. Other full-day tutorials: - Advanced Unix Security (Matt Bishop, Dartmouth College) - Preparing for Disaster (a.m. - Brent Chapman, Great Circle Associates), plus, Why have Computer Security? (p.m. Bob Baldwin, Tandem Computers) - Topics in Perl (Tom Christiansen, Convex Computer Corporation) - Programming in POSIX (Jeffrey S. Haemer, Canary Software) - UNIX Programming Tools (Kenneth Ingham, consultant) - Introduction to UNIX System Administration (Dinah McNutt, Tivoli Systems) - Integrating C Code and Xt Widgets (Craig Rudlin, MD, Medical Software and Computer Systems) If you just want to go to the exhibits, ask for a free show-only pass. To get more information by email about these tutorials, the technical program, or exhibits at the Sun User Group conference, send requests to sugshow@sug.org . You will receive the full tutorials and program description with registration information. Or call 1-800/727-EXPO. (Outside the U.S., use 512/331-7761 (voice) or 512/331-3950 (FAX).) -- Nancy Frishberg, Sun User Group.
-----------[000163][next][prev][last][first]---------------------------------------------------- Date: 17 Nov 92 01:56:32 GMT From: casey@gauss.llnl.gov (Casey Leedom) To: comp.protocols.tcp-ip Subject: Is the Balkanization of the InterNet inevitable?
Are network security firewalls between organizations and the InterNet going to be the norm in the future? This seems to be the answer some of our local people think is inevitable. I haven't had time to keep up with network security issues for a couple of years, so I just don't know what the state of current work is or what the consensus on this issue is. If the Balkanization of the InterNet is inevitable, I feel it will be a great loss. It will be an acknowledgement that irresponsible criminal hackers have won from us our freedom of open inter-operation. What a sad thought. Are there no other realistic options for providing security? Is it impossible to conceive of effective authentication methods? If this has already been hashed out dozens of times before I'm sorry. (I also haven't been able to keep up with USENET for some time.) I'm sure it's a flame-ridden topic. But I'd really like to see a non-flame driven dialogue on the topic. Casey
-----------[000164][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Nov 92 01:59:18 GMT From: joe@igor.tamri.com (Joe Carlson) To: comp.protocols.tcp-ip Subject: CMUTEK for vms 4.7 name server? how?
I'm having trouble getting a domain server to respond to CMUTEK tcp/ip in vms land (4.7) Anybody got a namsrv.config or internet.config (or other sorts of hints...) that could shed light on this for me? I got hosts.txt to resolve names for the local machines and i can telnet and ftp if i know the address, but i have problems beyond that. sorry if this is a RTFM, but i don't got no FM. joe@igor.tamri.com or jcarlsn@itsa.ucsf.edu
-----------[000165][next][prev][last][first]---------------------------------------------------- Date: 17 Nov 92 07:22:49 GMT From: gutherz@europa.rutgers.edu (Matt Gutherz) To: comp.dcom.sys.cisco,comp.protocols.tcp-ip Subject: routing trouble - one ethernet/two subnets
Hi. I have an ethernet segment configured to support two different subnets. Unfortunately the routers serving this segment only generate one routing update sourced from one of its two configured IP addresses on that segment. For the SUN workstations in the subnet that the routers sources the update from this is not a problem. Routed functions properly. The SUN workstations in the other subnet are not as fortunate. Routed on these machines is currently not excepting updates from a router it considers non-local. Does anyone have any ideas how I might be able to make this work (without using gated or fudging subnet masks on the workstations)? The SUNs are 4.1. Thanks. Matt Gutherz matt@japan.sbi.com "Savoir Faire is everywhere." -- blah!
-----------[000166][next][prev][last][first]---------------------------------------------------- Date: 17 Nov 92 08:36:45 GMT From: drake@drake.almaden.ibm.com (Sam Drake) To: comp.protocols.ibm,comp.protocols.tcp-ip Subject: Re: NFS
In article <1992Nov13.172400.5004@gumby.dsd.trw.com> modic@gumby.dsd.trw.com (Jeanine A. Modic-Carmona) writes: > >Hi! I was wondering if anyone has tried to backup a PC or Mac to an IBM >mainframe via TCP/IP? If so, how? IBM sells a (ahem) wonderful product to do this, the Workstation Data Save Facility. Allows you to back up DOS, AIX, OS/2, SunOS and Mac clients to a central VM mainframe. The follow-on product, DFSMS, supports the same clients and both VM and MVS mainframes. Backup and restore are completely automatic; you can retrieve previous versions of files; both disk and offline media are supported in a storage hierarchy; etc. Designed to back up all your PCs and workstations without strain.
-----------[000167][next][prev][last][first]---------------------------------------------------- Date: 17 Nov 92 08:40:15 GMT From: P88037@BARILVM.BITNET To: comp.protocols.tcp-ip Subject: PC control over TCPIP
Question: is there a software that allows one to control a PC via TCPIP,
i.e. telnet to the PC and get a DOS prompt?
please mail to elharrar@bimacs.cs.biu.ac.il or reply in post.
Thanks!
Yair
-----------[000168][next][prev][last][first]---------------------------------------------------- Date: 17 Nov 92 09:21:54 GMT From: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) To: comp.protocols.tcp-ip Subject: Re: tcp sample sources wanted
> > Are the sample sources available from the Comer or Stevens books on > tcp/ip - UNIX Network programming? > stevens' stuff is certainly gettable e.g. (from archie) emx.cc.utexas.edu:/pub/netinfo/src/netprog or nic.ddn.mil:/netprog/ i havnt seen comers...srconline, but archie says arthur.cs.purdue.edu:/pub/comer/ has something in! jon
-----------[000169][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Nov 1992 12:37:36 GMT From: markus@edfd.uucp (Markus Gruenkorn (MAGIC)) To: comp.protocols.tcp-ip Subject: TCP/IP and ISDN / experiences with ISDN ?
Hi guys ! I would like to know something about ISDN ! Which possibilities are there to use TCP/IP over ISDN ? How does it work (it would be nice to geta any details!) ? How about ISDN in other countries or between countries ? ISDN between: germany and UK ? germany and spane ? germany and france ? germany and USA ? Any experiences with ISDN ? Any information would be appreciated ! -- ------ < MAGIC > ------
-----------[000170][next][prev][last][first]---------------------------------------------------- Date: 17 Nov 92 14:07:50 GMT From: paul@tivoli.UUCP (Paul Greenspan) To: comp.protocols.tcp-ip,comp.unix.wizards Subject: Re: TLI and non-blocking I/O
I just wanted to thank all of the people that helped with our problem with non-blocking I/O, TLI and SVR4. The problem has been determined to be a bug in SVR4 that shows up when the same process uses both TCP and UDP and uses non-blocking endpoints. Paul -- Paul Greenspan paul@tivoli.com Tivoli Systems 6034 West Courtyard, Suite 210 Austin, Texas 78730 (512) 794-9070 / FAX (512) 794-0623
-----------[000171][next][prev][last][first]---------------------------------------------------- Date: 17 Nov 92 14:28:56 GMT From: craa85@ccsun.strath.ac.uk ( D.W.Stevenson) To: comp.protocols.tcp-ip Subject: NIS broadcasts over IP subnets
I have a potential problem with NIS in the presence of subnets. Advice would be appreciated. If a NIS client broadcasts to the subnet broadcast address (e.g. 130.159.248.255 in the case of 24 bit subnets), a router will not propogate the broadcast onto other subnets on the LAN and hence the client won't be able to bind to a NIS server unless a server is on the same subnet. If however the NIS client broadcasts to the class B broadcast address (130.159.255.255) even when using an 24 bit subnet mask, the router can be configured to forward all subnet broadcasts and there is no problem. Which way does NIS do it? -- Dave Stevenson d.w.stevenson@strath.ac.uk Computer Centre Communications Tel : 44 41-552 4400 ext 3461 University of Strathclyde Glasgow, Scotland, U.K.
-----------[000172][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Nov 92 14:30:12 GMT From: berman@nlm.nih.gov (Lew Berman) To: comp.protocols.tcp-ip Subject: tcp client/server performance
I am building a client/server to transfer 5Mbyte images over the internet. The system is up and running, but I would like to know what I can do to improve the performance of the system. Besides data compression, different protocols (VMTP, etc.), what can I do with the standard sockets, etc? I've changed the SO_RCVBUF and SO_SNDBUF size at both the client and server sides so that they are now 16384 bytes. Should I make them larger? How large can they be (I'm on SUN workstations)? Currently I just do one massive write into the socket, should this be split into smaller blocks and then written to the socket? If so, what would be a good size block? Any other suggestions for improving the performance? Please send all e-mail directly to me and I will repost to the net. Thanks, Lew Berman National Library of Medicine Bethesda, MD
-----------[000173][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Nov 92 14:42:47 GMT From: nelson@crynwr.com (Russell Nelson) To: comp.dcom.lans.ethernet,comp.dcom.isdn,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: remote tcp/ip LAN access ideas
In article <1992Nov16.191510.474@nynexst.com> sgriffee@nynexst.com writes: Watch out. Telecommuting may be just around the bend for your company. Don't let it catch you asleep at the wheel. Steve Griffee sgriffee@nynexst.com NYNEX Science and Technology Data & Information Services 500 Westchester Avenue 914-644-2531 fax: 914-644-2301 White Plains, NY 10604 Holy shit, Steve, is NYNEX just figuring this out?!?!??? No wonder It Still Does Nothing in New York. Sorry for the gratuitious flamage, but maybe that's what the baby bells need? -russ <nelson@crynwr.com> What canst *thou* say? Crynwr Software Crynwr Software sells packet driver support. 11 Grant St. 315-268-1925 Voice | LPF member - ask me about Potsdam, NY 13676 315-268-9201 FAX | the harm software patents do.
-----------[000174][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Nov 1992 15:44:50 GMT From: erick@sunee.uwaterloo.ca (Erick Engelke) To: comp.protocols.tcp-ip Subject: Re: PC control over TCPIP
P88037@BARILVM.BITNET writes: >Question: is there a software that allows one to control a PC via TCPIP, >i.e. telnet to the PC and get a DOS prompt? > >please mail to elharrar@bimacs.cs.biu.ac.il or reply in post. > This is often called a TELNETD, and there are four options: 1. Free TELNETD - it's not the greatest but it is free. FTP to 129.97.50.50 and get pub/wattcp/telnetd.zip 2. Beame&Whiteside include a TELNETD inside their BW-TCP 3.0. The package comes with other TCP applications like TELNET, FTP, a nifty LPD, etc. Mail to sales@bws.com 3. Essex also includes a TELNETD with their collection of TCP applications and network stack called TCP/2. I don't have an Email address. 4. SNSI specializes in TELNETD with versions for LanWorkPlace, PC/TCP, Pathway, Lantastic/TCP, Beame&Whiteside and packet drivers. Mail to info@snsi.com -- ---------------------------------------------------------------------------- Erick Engelke WATTCP Architect erick@development.uwaterloo.ca TCP/IP was easy but i still can't work VI
-----------[000175][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Nov 1992 15:47:27 GMT From: paola@hplb.hpl.hp.com (paola fulchignoni) To: comp.protocols.tcp-ip Subject: IP security labels
Could anyone give me more details about RFC 1108 (IETF document in which security labels handling in IP packets is explained) and/or how to find it? Thanks, Paola
-----------[000176][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Nov 1992 16:03:14 GMT From: tching@target.uucp (Tracy Ching <SysAdmin>) To: comp.protocols.tcp-ip Subject: Re: tcp sample sources wanted
In article <3223@ucl-cs.uucp> J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) writes: > > Are the sample sources available from the Comer or Stevens books on > > tcp/ip - UNIX Network programming? > >i havnt seen comers...srconline, but archie says >arthur.cs.purdue.edu:/pub/comer/ >has something in! > Don't do this one... it is just for students to try an ftp session. There is nothing there except for two file that say "are you kidding... it was just an example in the text book"
-----------[000177][next][prev][last][first]---------------------------------------------------- Date: 17 Nov 92 16:07:55 GMT From: barr@pop.psu.edu (David Barr) To: comp.protocols.tcp-ip Subject: Re: NIS broadcasts over IP subnets
In article <1992Nov17.142856.19947@ccsun.strath.ac.uk> craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes: >I have a potential problem with NIS in the presence of subnets. Advice would >be appreciated. > >If a NIS client broadcasts to the subnet broadcast address (e.g. 130.159.248.255 >in the case of 24 bit subnets), a router will not propogate the broadcast onto >other subnets on the LAN and hence the client won't be able to bind to a NIS >server unless a server is on the same subnet. If however the NIS client >broadcasts to the class B broadcast address (130.159.255.255) even when using >an 24 bit subnet mask, the router can be configured to forward all subnet >broadcasts and there is no problem. The best (and recommended by Sun) solution is to have an NIS slave on every subnet. It is not a good idea in general to configure your router to route broadcasts outside of a subnet. (The purpose of a router is to decrease traffic, not increase it) --Dave
-----------[000178][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Nov 1992 16:38:25 GMT From: stewart@tweety.cis.udel.edu (John Stewart) To: comp.protocols.tcp-ip Subject: Re: NIS broadcasts over IP subnets
In article <1992Nov17.142856.19947@ccsun.strath.ac.uk> craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes: >I have a potential problem with NIS in the presence of subnets. Advice would >be appreciated. > >If a NIS client broadcasts to the subnet broadcast address (e.g. 130.159.248.255 >in the case of 24 bit subnets), a router will not propogate the broadcast onto >other subnets on the LAN and hence the client won't be able to bind to a NIS >server unless a server is on the same subnet. If however the NIS client >broadcasts to the class B broadcast address (130.159.255.255) even when using >an 24 bit subnet mask, the router can be configured to forward all subnet >broadcasts and there is no problem. > >Which way does NIS do it? NIS was not designed so that clients on a LAN which have no NIS servers (master or slave) for a given NIS domain could participate in that domain. You can use "ypbind" and "ypset" in /etc/rc.local to do what you want (and many people, including me, do it), but it is a kludge at best. I understand from a "white paper" from Sun that NIS+ is supposed to do this better. Good luck. /jws
-----------[000179][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Nov 1992 17:41:09 GMT From: smb@ulysses.att.com (Steven Bellovin) To: comp.protocols.tcp-ip Subject: Re: Is the Balkanization of the InterNet inevitable?
In article <141672@lll-winken.LLNL.GOV>, casey@gauss.llnl.gov (Casey Leedom) writes: > Are network security firewalls between organizations and the InterNet > going to be the norm in the future? This seems to be the answer some of > our local people think is inevitable. I haven't had time to keep up with > network security issues for a couple of years, so I just don't know what > the state of current work is or what the consensus on this issue is. > > If the Balkanization of the InterNet is inevitable, I feel it will be a > great loss. It will be an acknowledgement that irresponsible criminal > hackers have won from us our freedom of open inter-operation. What a > sad thought. Are there no other realistic options for providing security? > Is it impossible to conceive of effective authentication methods? For the most part, authentication isn't the issue. We already know how to build effective authentication methods; they just aren't deployed. But even if they were, it wouldn't help that much. There are too many break-ins caused by buggy software and/or system administration errors. The former is just a special case of the general software engineering problem, and I don't think it's close to being solved. The latter -- well, it would help if vendors would try to ship stuff in a default secure configuration, but there are still so many knobs to twiddle that mistakes are inevitable.
-----------[000180][next][prev][last][first]---------------------------------------------------- Date: 17 Nov 92 17:43:21 GMT From: steve@terminus.ericsson.se (Steve Reynolds) To: comp.protocols.tcp-ip Subject: Re: tcp sample sources wanted
The Comer sources are available on tape from the publishers Prentice hall (sorry no ISBN) The tape also holds XINU and some user contributed stuff . cost about 100GBP
-----------[000181][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Nov 1992 18:11:39 GMT From: syscrc@pickle.gsu.edu (Randy Carpenter) To: comp.protocols.tcp-ip Subject: Rigging up telnetd(1m) for an application.
We want users to be able to telnet into an application on an RS/6000 (running AIX 3.2) and not have to enter a login or password. So, we are considering using a binary editor (say "hex") to patch the telnetd(1) executable and substitute "/bin/fubar" instead of "/bin/login". The program "/bin/fubar" will start the application (our University's registration system). Of course, we will provide the original telnetd(1) on another port so that a real login is possible. Will this interfere with any TELNET negotiations or cause other problems? -- =========================================================================== Randy Carpenter rcarpent@gsu.edu % Got a light? Georgia State University (404) 651-2648 No match. Wells Computer Center % -- =========================================================================== Randy Carpenter rcarpent@gsu.edu % Got a light? Georgia State University (404) 651-2648 No match. Wells Computer Center %
-----------[000182][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Nov 1992 18:35:45 GMT From: ellingsen_jim@Tandem.COM (Jim Ellingsen) To: comp.protocols.tcp-ip Subject: TCP/IP over Token-Ring
Do most TCP/IP over token-ring implementations support source routing? Jim Ellingsen ellingsen_jim@tandem.com Tandem Computers Cupertino, CA
-----------[000183][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Nov 1992 18:58:20 GMT From: nectar@world.std.com (Jacques A Vidrine) To: comp.protocols.tcp-ip Subject: TN5250 ?
I'm looking for a TELNET 5250 client for DOS or Microsoft Windows 3.x. Does anyone know of a freely available package? -- Jacques A. Vidrine... | nectar@world.std.com | There's no use crying over | spilled mitochondria. | - Ren
-----------[000184][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Nov 1992 19:03:08 GMT From: ihsan@ferranti.com (jaleel ihsan) To: comp.protocols.tcp-ip Subject: TCP simul- & broadcast
At one time class D IP address (224.0.0.0 thru 255.255.255.254) were reserved for simul-cast and of course 255.255.255.255 for broadcast. I have a few questions reguarding TCP simul- and broadcasts, if someone could please enlighten us: 1. What do the latest standards demand from an implementor in this regard. 2. What happens to TCP's reliable delivery feature, specially in case of broadcast ? Does it drop down to the level of UDP ? 3. What are the vendors providing and supporting in the market place. I think I saw an article saying that some one has used TCP simulcast for video teleconferencing (over ISDN perhaps) but I am not sure.
-----------[000185][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Nov 1992 20:22:59 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: NIS broadcasts over IP subnets
In article <c241Hya0za@atlantis.psu.edu>, barr@pop.psu.edu (David Barr) writes: > In article <1992Nov17.142856.19947@ccsun.strath.ac.uk> craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes: > >I have a potential problem with NIS in the presence of subnets. Advice would > >be appreciated. > > > >If a NIS client broadcasts to the subnet broadcast address (e.g. 130.159.248.255 > >in the case of 24 bit subnets), a router will not propogate the broadcast onto > >other subnets on the LAN and hence the client won't be able to bind to a NIS > >server unless a server is on the same subnet. If however the NIS client > >broadcasts to the class B broadcast address (130.159.255.255) even when using > >an 24 bit subnet mask, the router can be configured to forward all subnet > >broadcasts and there is no problem. > > The best (and recommended by Sun) solution is to have an NIS slave on every > subnet. It is not a good idea in general to configure your router to route > broadcasts outside of a subnet. (The purpose of a router is to decrease > traffic, not increase it) I think a better way is to use a class-D multicast address and routers which forward multicasts. Vernon Schryver, vjs@sgi.com
-----------[000186][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Nov 1992 20:48:02 GMT From: fsgreen@dredd.lerc.nasa.gov (Doug Greenwald) To: comp.protocols.tcp-ip Subject: SUMMARY: Need Ethernet types/IP Frame and Header Formats
I wish to thank the following people for responding to my request for Ethernet frame headers for the small network analyzer I'm writing. From: stewart@ra.cis.udel.edu (John Stewart) From: Dave Curry <davy@ecn.purdue.edu> From: Stephen C. Trier <trier@odin.INS.CWRU.Edu> From: Amos Shapira <amoss@CS.HUJI.AC.IL> From: Bruce Jones <bj@unislc.slc.unisys.com> From: karwowska@dg-rtp.dg.com (Joanna Karwowska) From: John_Burton@gec-epl.co.uk For people that are interested in the program, it runs on the sun4c platform under SunOS 4.1.x (Solaris 1.x). It takes one argument (the number of packets to grab) and generates a list of packets received (and decodes the packets I've been able to find time and info to decode), and then generates a packet breakdown. It's a very simple program. Time permitting, I will continue to add packet decoding and some filtering ability. -- Doug Greenwald fsgreen@icomp01.lerc.nasa.gov Sun System Administrator (216) 433 5965 ICOMP, NASA Lewis Research Center
-----------[000187][next][prev][last][first]---------------------------------------------------- Date: 18 Nov 92 00:02:09 GMT From: lars@spectrum.CMC.COM (Lars Poulsen) To: comp.protocols.tcp-ip Subject: Re: Flow Control
In article <1992Nov14.012946.13136@advtech.uswest.com> kdlin@advtech.uswest.com (David Lin) writes: >I understand that many end-to-end sliding window flow control schemes >( eq. in TCP/IP and in XTP ) use byte as the unit for calculation. For >example, if the window size is 6K bytes and you have transmitted 2K bytes >without receiving ACKs from the receiver, then you are allowed to transmit >4K more bytes. > >Now, if I change the unit for flow control calculation to packet ( or >frame ), what is the impact to the whole system? What's the implication? > [ ... ] >1. Are there any circumstances that this scheme ( using packet as > the computation unit ) is desirable? >2. When it is NOT desirable? >3. Do I really achieve anything by doing that? HDLC, X25 and TP4 do flow control by counting PDUs (protocol data units) instead of bytes. If the protocol that you are flow controlling has firm record boundaries that must be preserved, it may be simpler to use packet counts for flow control. TCP on the other hand, views the data stream as an unstructured byte stream. Data from several original PDUs may be coalesced on retransmissions. This saves link bandwidth. Depending on the implementation of the protocol stack, either model may more accurately describe the loading on the buffer pools on the two end systems. -- / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM CMC Network Products / Rockwell Int'l Telephone: +1-805-968-4262 Santa Barbara, CA 93117-3083 TeleFAX: +1-805-968-8256
-----------[000188][next][prev][last][first]---------------------------------------------------- Date: Wed, 18 Nov 1992 02:41:13 GMT From: hcb@world.std.com (Howard C Berkowitz) To: comp.protocols.tcp-ip,comp.dcom.lans.ethernet Subject: Re: Wanted: Advice on calculating timing gaps between packets.
A few random things to consider. You will never get the true 10 MBPS from an IEEE 802.3/ETHERNET LAN, due to some timing requirements of the protocol itself. There must be a minimum 9.6 microsecond delay between packets; this is part of the medium access control process. There must be enough idle time that the most distant station will hear a jam signal. Assuming a single transmitter and a single receiver, the maximum possible frame-level transfer rate will be based on the length (or length distribution) of frames, plus the interframe delay. I often find it worthwhile to write a reasonably quick-and-dirty Monte Carlo simulation of the line protocols rather than go too far in analyzing them. Retransmission time will be based on the time to send the colliding frames, the interframe delay, and the time to send the next frame. The backoff algorithm uses an exponentially increasing delay after each successive collision. In a reasonably loaded network, a frame should get through with a maximum of 3-4 collisions (this is fairly pessimistic). So much depends on the interarrival times of new frames, the length of frames, and the number of stations that simulation often is easier. Always remember that ETHERNET is a service to Arnold Schwarzenegger. After all, it is a cable that connects Terminator I with Terminator II. :-)
-----------[000189][next][prev][last][first]---------------------------------------------------- Date: Wed, 18 Nov 1992 04:11:41 GMT From: ben@datacomm.ucc.okstate.edu (Ben James) To: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell Subject: Oditrpkt ( One last Problem! )
I am still haveing problems with oditrpkt.com. At the moment I have almost everything working. My current problem is that my driver or ODI is changeing my offset in TCP this is this field which tells where exactly the data starts. For some reason every time I send a TCP packet out threw my driver and odi this offset is set to 5. Unfortunitally the first packet has an options field giving the maximum segment size so this field should be 6. I have been able to get a telnet session open too our 3Com Token-Ring Bridge's. Also once by some glitch it worked ok. I do know that this field is correct when it goes into my driver so somehow it is getting changed. It appears to me that this is being changed by the LSL or MLID but is always eaiser to place the blame somewhere else. Everything else is working perfectly I even have route.com doing the source routing for me. A brief description of what I do First I get the type field and move it to the Stack ID and also the ProtocolID fields in the ECB then I move the dest address to the immediate address of the ECB if its arp I change the hardware field and also reduce size. Then I move the pointer to where the data begins. Below is a copy of the send routine sECB is a pointer to the beginning of the Event Control Block. I have also marked the portion which differs from odipkt.com which consists of code to alter the mac header. This code is copyrighted by Daniel D. Lanciani and the complete copyright message is given in the odipkt.asm source file. That message also applies to here. ( Just to be safe ) ; This part is done at initialization. ; Initialization for sECB is the same as for odipkt execpt no raw send mov word ptr sECB + 10, offset transcom ; Call Transcom mov word ptr sECB + 12, cs ; Also ptr to transcom ; mov word ptr sECB + 14, -1 ; stack ID mov ax, board ; Board # mov word ptr sECB + 22, ax ; Board # mov word ptr sECB + 44, 1 ; Fragment0Count send_pkt:sti push ds mov bx, ds mov dx, cs mov ds, dx send_pkt1: cmp word ptr 8 + sECB, 0 ; status clear ? jg send_pkt1 ; If not wait until it is. add stab + 4, 1 ; Stistics for Pktdrvr adc stab + 6, 0 add stab + 12, cx adc stab + 14, 0 ; End stats mov word ptr sECB + 48, bx ; Fragment0address LW ;*********Here is where my code and odipkt differ.********* ; They would be the same if you took out this. push cx mov es, bx ; Move type into ECB fields mov cx, word ptr es:12[si] ; Get type field from packet. mov word ptr sECB + 14, cx ; StackID mov word ptr sECB + 20, cx ; ProtocolID mov cx, word ptr es:0[si] mov word ptr sECB + 24, cx ; Immediate address mov cx, word ptr es:2[si] mov word ptr sECB + 26, cx mov cx, word ptr es:4[si] mov word ptr sECB + 28, cx ; ***************** pop cx cmp word ptr es:12[si], 0608h jnz not_arp_send ; if not arp then jump mov byte ptr es:15[si], 06h ; is arp sub cx, 18 ; Reduce size for arp not_arp_send: add si, 14 Offset stack pointer by send and recieve address + AC + FC sub cx, 14 Offset size by the same. ;*********From here on it is the same as odipkt.******** send_pkt4: mov word ptr sECB + 42, cx ; Data Length mov word ptr sECB + 46, si ; Fragment0Address mov word ptr sECB + 50, cx ; Fragment0Legnth mov si, offset sECB mov es, dx mov bx, 12 ; Send Packet call psup sti send_pkt2: cmp word ptr 8 + sECB, 0 ; Status jg send_pkt2 ; loop until clear or fail jnz send_pkt3 pop ds jmp good send_pkt3: add stab + 20, 1 ; Stats adc stab + 22, 0 pop ds mov dh, 12 jmp bad
-----------[000190][next][prev][last][first]---------------------------------------------------- Date: Wed, 18 Nov 1992 05:41:15 GMT From: peter@palin.cc.monash.edu.au (Peter Hawkins) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans,comp.dcom.lans.ethernet,comp.dcom.lans.misc Subject: REQ: MSDOS TCP/IP stack in ASM or Pascal
I need to interface a turbo pascal (V6) application to TCP/IP. The
application is heavily OOP & TVision etc so I pretty well am forced
to use turbo pascal. It's huge & re-writing in C is not practical.
I could use novell IPX & Banyan Vines, but I want it to be more
general if I can.
I got a copy of wattcp - a mixture of asm & C, and compiled it with
BCC, but unfortunately I couldn't link the C & pascal object files
without leaving unresolved externals - Borland's advice was that
interfacing C to Pascal will not work with any C code which is either
not-straightforward (in calling) or which utilises intrinsic libraries.
(They advised against my attempting it - and suggested I re-write the
TCP/IP stack in pascal!)
Before embarking on a major project such as re-writing the stack, or
giving up and using IPX and Vines, I thought I'd try and see if anyone
knew:
1) What public domain / commercial TCP/IP stacks are there which might
be callable from turbo C?
2) Are there any stacks around written entirely in assembly or (joy of
joys!) pascal?
Thanks in advance,
Peter
--
Peter Hawkins,
Assistant Lecturer, Computer Centre
Monash University, Australia
peter@palin.cc.monash.edu.au
-----------[000191][next][prev][last][first]---------------------------------------------------- Date: Wed, 18 Nov 1992 08:25:52 GMT From: benolie@tid.es (Luis Benoliel) To: comp.protocols.tcp-ip Subject: FAQ AVAILABLE FOR THIS NEWSGROUP ?
Is the faq for this newsgroup available? If so, where ? -- //////// /////// ///// Luis Benoliel // // // // email: benolie@tid.es // // // // tel : +34 1 337 41 85 // // // // fax : +34 1 337 42 02
-----------[000192][next][prev][last][first]---------------------------------------------------- Date: 18 Nov 92 11:57:15 GMT From: mrc@Ikkoku-Kan (Mark Crispin) To: comp.protocols.tcp-ip Subject: WARNING on NetInfo
This warning is posted to anyone as an advisory to anyone else who may be so foolish as to try to run a bootp daemon on the NeXT and think he can install it by something as simple and straightforward as niload bootptab . < bootptab Beware!! NetInfo does not maintain the information from /etc/bootptab separately. Instead, it and the information from /etc/hosts are both co-located in the `machines' NetInfo directory. So you do the niload and you discover that the information isn't right. In fact, what appears as the bootp IP address is another IP address for that machine; that client uses both SLIP and Ethernet and so it's dual-homed. Wierd, you think. After all, you put the correct IP address in bootptab. Oh well. No problem, you think, just do niload -d bootptab . < bootptab Yup, that fixed the problem all right. Now you got a worse problem. As you discover after a lot of pulling of hair trying to figure out why everything is falling down in flames, you just hosed the entire hosts database including the definition of localhost. I learned this the hard way. I was not pleased. This is a warning too, to you folks with SUNs and other non-NeXT platforms who may be receiving advertising from NeXT about NetInfo for your machine. DON'T BUY IT. NetInfo is the single worst piece of system administration software, bar none, that I have ever had the misfortune of dealing with. If you thought Yellow Pages was a can of worms, you haven't begun to imagine the myriad ways in which NetInfo can screw you. For those of you who haven't figured out what NetInfo is, it is a distributed system configuration database that pretty much turns off ALL of the standard Unix configuration files: aliases, bootptab, bootparams, exports, fstab, group, hosts, networks, passwd, printcap, protocols, rpc, services. Among its many faults, it stores the data in binary, since you are expected to use the NetInfoManager tool (which has a user interface designed by the Marquis de Sade) to edit it. To some degree, you can edit the Unix configuration file and `niload' it into NetInfo, but there are all sorts of ways it can screw up and I just discovered a new one. What's worse, you can't turn it off on a NeXT. I can't imagine anyone wanting to run it on a machine which doesn't force you into it the way a NeXT does. Verbum sat sapenti.
-----------[000193][next][prev][last][first]---------------------------------------------------- Date: 18 Nov 1992 22:55:35 -0600 From: usbill@ustores.missouri.edu (Bill Canning) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Recommended Terminal Server
I'm looking for a fairly basic terminal server that won't cost a fortune. I need to get between 24 and 32 ports, although this could be with more than one unit. We will only be running 9.6K terminals on it, and we will be using it to attach to a Unix host via Telnet on an ethernet LAN. Does anyone have any recommendations? Thanks in advance for your help, Bill -- Bill Canning usbill@ustores.missouri.edu (Internet) (314) 882-2131 usbill@muccmail.missouri.edu (cc:Mail) [314] 882=4699 (Fax) CSPECWC@MIZZOU1 (BITNET)
-----------[000194][next][prev][last][first]---------------------------------------------------- Date: 18 Nov 92 14:23:27 GMT From: stodola@orion.fccc.edu (Robert K. Stodola) To: comp.protocols.tcp-ip Subject: Re: Is the Balkanization of the InterNet inevitable?
In article <141672@lll-winken.LLNL.GOV>, casey@gauss.llnl.gov (Casey Leedom) writes:
>
> Are network security firewalls between organizations and the InterNet
> going to be the norm in the future?
I think you'll see a lot more of them (certainly, at least one!-).
> If the Balkanization of the InterNet is inevitable, I feel it will be a
> great loss. It will be an acknowledgement that irresponsible criminal
> hackers have won from us our freedom of open inter-operation. What a
> sad thought. Are there no other realistic options for providing security?
This need not be true. Many firewalls allow limited access (ie. particular
systems or ports accessible), and it is always possible to keep machines
designed for public access on the other side of your firewall. It just means
you have to think about what belongs in the public arena and what doesn't.
But you should be doing that anyway.
Suggest you redirect followups to the firewalls (or other) mailing list:
Send the following command in email to "Majordomo@GreatCircle.COM":
subscribe firewalls <your-email-address>
--
stodola@fccc.edu -- Robert K. Stodola (occasionally) speaks for himself.
-----------[000195][next][prev][last][first]---------------------------------------------------- Date: Wed, 18 Nov 1992 15:24:33 GMT From: mwr@eng.tridom.com (Mark Reardon) To: comp.protocols.tcp-ip Subject: Re: TCP/IP over Token-Ring
I am also interested in this topic. Please include me in any non posted milings on the subject as my next assignment is TCP/IP over 802.5 (token ring). Thanks. -- Mark --------------------------------------------------------------------- | Mark Reardon | AT&T Tridom | | mwr@eng.tridom.com | 840 Franklin Court | | | Marietta, GA 30067 | ---------------------------------------------------------------------
-----------[000196][next][prev][last][first]---------------------------------------------------- Date: 18 Nov 92 15:28:52 GMT From: barnett@grymoire.crd.ge.com (Bruce Barnett) To: comp.protocols.tcp-ip Subject: Multicast Routers (was Re: NIS broadcasts over IP subnets)
In article <sg3chj4@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > I think a better way is to use a class-D multicast address and routers > which forward multicasts. I agree, but which routers support Network groups? -- Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
-----------[000197][next][prev][last][first]---------------------------------------------------- Date: Wed, 18 Nov 1992 16:57:07 GMT From: stewart@daffy.cis.udel.edu (John Stewart) To: comp.protocols.tcp-ip Subject: Re: TCP simul- & broadcast
In article <id.XP1V.B11@ferranti.com> ihsan@ferranti.com (jaleel ihsan) writes: >At one time class D IP address (224.0.0.0 thru 255.255.255.254) were >reserved for simul-cast and of course 255.255.255.255 for broadcast. > >I have a few questions reguarding TCP simul- and broadcasts, if >someone could please enlighten us: > >1. What do the latest standards demand from an implementor in this > regard. > >2. What happens to TCP's reliable delivery feature, specially > in case of broadcast ? Does it drop down to the level of UDP ? > >3. What are the vendors providing and supporting in the market place. > >I think I saw an article saying that some one has used TCP simulcast >for video teleconferencing (over ISDN perhaps) but I am not sure. At this point, multicast has been done at the IP-layer, rather than the TCP (or UDP) layer. For example, the Internet Engineering Task Force meeting, which is going on right now in Washington, D.C., is having some of its meetings video and audio mutli-cast over the Internet; applications with such huge bandwidth demands have, to date, all been based on UDP. To do this, a logical multi-cast network has been created within the Internet; this has been called MBONE (multi-cast backbone). Internet-attached customers interested in becoming part of MBONE should contact their regional provider. For more information of a technical nature, I direct you to the Association for Computing Machinery's Special Interest Group on Communication's (ACM SIGCOMM's) Computer Communication Review (CCR) from this fall (I don't have the publication with me, so I can't give you an exact date -- sorry). There is an article there by Steve Casner et. al. describing how MBONE is achieved. /jws
-----------[000198][next][prev][last][first]---------------------------------------------------- Date: 18 Nov 92 17:06:22 GMT From: ajudge@maths.tcd.ie (Alan Judge) To: comp.dcom.servers,comp.dcom.lans,comp.dcom.sys.cisco,comp.protocols.tcp-ip,comp.sys.mips Subject: Routing using a dual-homed machine vs a router
Does anybody have any comments on the performance of a Unix machine as a router vs that of a dedicated router, such as a Cisco? How much delay is imposed by each solution? Are there any other issues here that I am missing? (I realise that a Unix box is likely to be down more than a dedicated router.) Given the simple nature of our setup (no fancy leased lines, only one ethernet at present), what models of router should I be considering if I go for a router? What do these models cost? [I am asked the net, as I need the answer in a hurry.] Background: We are connected to the campus fibre-optic backbone using a bridge at present. There is a possibility that we will switch to using subnetting and routing instead. If that happens, we will either purchase a router or install a second ethernet into one of our machines. There is little bulk traffic between the department and the rest of College, mainly NNTP, SMTP, NTP, telnet, rlogin. No NFS or other file sharing. The machine in question is likely to be an R4000 based MIPS server (a Millenium 4000 SC-50). We would probably run gated. Please reply by email and I will summarise. -- Alan Judge ajudge@maths.tcd.ie a.k.a. amjudge@dsg.cs.tcd.ie +353-1-7021782 A year spent in Artificial Intelligence is enough to make one believe in God. -- Alan Perlis
-----------[000199][next][prev][last][first]---------------------------------------------------- Date: Wed, 18 Nov 1992 17:09:22 GMT From: mazzucch@ghost.dsi.unimi.it (massimo mazzucchi) To: comp.protocols.tcp-ip Subject: SLIP info
Hi
I am Max from Milan Italy
I use to communication UNIXtoDOS SLIP
FTP Software PC/TCP version 1.16pl4
i will know:
- exist a new version and it is a commercila program or public domain?
- for example if i have connect my pc with a serial port of
a modem in which way i can use command ftp correctly?( there
are 2 file *.sys that i have place in Config.sys)
- there 2 file IPCONFIG and IFCONFIG
in which way i must use them?
Thanks for your help
Bye
--------------------------------------------------------------------------------
! Massimo Mazzucchi address e-mail !
! University of State mazzucch@ghost.dsi.unimi.it !
! Departement of Computer Science 149.132.2.1 !
! Via Comelico, 41 - 20133 MILAN ITALY !
-------------------------------------------------------------------------------
-----------[000200][next][prev][last][first]---------------------------------------------------- Date: Wed, 18 Nov 1992 17:29:03 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Multicast Routers (was Re: NIS broadcasts over IP subnets)
In article <BARNETT.92Nov18102852@grymoire.crd.ge.com>, barnett@grymoire.crd.ge.com (Bruce Barnett) writes:
> In article <sg3chj4@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>
> > I think a better way is to use a class-D multicast address and routers
> > which forward multicasts.
>
> I agree, but which routers support Network groups?
Well, most routers in the world do. That is because cause nearly all
routers in the world are UNIX workstations and PC's, instead of
Official Real Routers (tm) and since mrouted & friends work in common
workstations. Someone once observed that Sun all by itself has
probably shipped more "IP routers" than all of the "router vendors"
combined.
It is often enough to just get mrouted running on the workstations you
are using as routers.
You'll notice that an official class-D address has been registered for
the portmapper, 224.0.2.2.
In the sense you probably meant the question, I don't know. For years
I hounded router vendors at Interop, and was always told "wait for
OSPF." Then they started saying "wait until the replacement for the
distance-vector-multicast-routing-protocol." This year I didn't
bother.
The IETF Entertainment Network should finally give the router vendors
enough reason to finish the work.
Vernon Schryver, vjs@sgi.com
P.S. I hope no one finds it necessary to point out all of the reasons
to use an Official Real Router (tm) instead of a workstation, or the
other way around. I trust anyone who cares is already quite familiar
with all sides of that old argument.
-----------[000201][next][prev][last][first]---------------------------------------------------- Date: 18 Nov 92 18:11:15 GMT From: bourkej@ul.ie To: comp.protocols.tcp-ip Subject: Tricky subnet question for gurus
Hi, can someone tell me if the following is cool. I have a bunch of units with hard coded ip addresses ( yuck ). I have four networks these must go on. I have workstations on these networks which need to talk to the units. The units must be interchangable. I want to be able to connect to the workstations from any net. I only need to talk to the units via the local workstations. The units and workstations must be able to interact wothout anything routing betweeen them. I'll have a router connecting to each net to allow access to the workstations. Is the following valid. net 1 x.x.4.0 mask 255.255.248.0 net 2 x.x.5.0 mask 255.255.240.0 net 3 x.x.6.0 mask 255.255.248.0 net 4 x.x.7.0 mask 255.255.248.0 units x.x.1.0 mask 255.255.248.0 last three bits of octet 8 are zero. Using the subnet system, each net can talk to their local units. Each net thinks it can talk to each other ( will never happen ). Each net will think it can talk to units on other nets ( never happen ) If I put routers on each net with subnet masks of 255.255.255.0, each router will advertise a router to each net, and only that net. Is it ok to have different subnet masks on the one net ? I'd appreciate any reply's by EMail, Thanks, john
-----------[000202][next][prev][last][first]---------------------------------------------------- Date: 18 Nov 92 22:18:47 GMT From: sullivan@samsung.com (Chris Sullivan) To: comp.protocols.tcp-ip Subject: CSLIP for Karn's TCP...
Im looking for a CSLIP implementation that I can use with Phil Karn's TCP/IP. Possibly Karn himself has done it???? Any ideas would be greatly appreciated. -- chris =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Chris Sullivan sullivan@samsung.com Samsung Software America ...uunet!samsung!sullivan One Corporate Drive Voice: (508) 685-7200 x132 Andover MA 01810 Fax: (508) 685-4940
-----------[000203][next][prev][last][first]---------------------------------------------------- Date: Wed, 18 Nov 1992 23:48:18 GMT From: peter@palin.cc.monash.edu.au (Peter Hawkins) To: comp.protocols.tcp-ip Subject: REQ: MSDOS TCP/IP stack in ASM or Pascal
I need to interface a turbo pascal (V6) application to TCP/IP. The
application is heavily OOP & TVision etc so I pretty well am forced
to use turbo pascal. It's huge & re-writing in C is not practical.
I could use novell IPX & Banyan Vines, but I want it to be more
general if I can.
I got a copy of wattcp - a mixture of asm & C, and compiled it with
BCC, but unfortunately I couldn't link the C & pascal object files
without leaving unresolved externals - Borland's advice was that
interfacing C to Pascal will not work with any C code which is either
not-straightforward (in calling) or which utilises intrinsic libraries.
(They advised against my attempting it - and suggested I re-write the
TCP/IP stack in pascal!)
Before embarking on a major project such as re-writing the stack, or
giving up and using IPX and Vines, I thought I'd try and see if anyone
knew:
1) What public domain / commercial TCP/IP stacks are there which might
be callable from turbo C?
2) Are there any stacks around written entirely in assembly or (joy of
joys!) pascal?
Thanks in advance,
Peter
--
Peter Hawkins,
Assistant Lecturer, Computer Centre
Monash University, Australia
peter@palin.cc.monash.edu.au
-----------[000204][next][prev][last][first]---------------------------------------------------- Date: Thu, 19 Nov 1992 00:56:01 GMT From: pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans,comp.dcom.lans.ethernet,comp.dcom.lans.misc Subject: Re: REQ: MSDOS TCP/IP stack in ASM or Pascal
In article <peter.722065275@palin.cc.monash.edu.au>, peter@palin.cc.monash.edu.au (Peter Hawkins) writes: > I need to interface a turbo pascal (V6) application to TCP/IP. The > application is heavily OOP & TVision etc so I pretty well am forced > to use turbo pascal. [...] > (They advised against my attempting it - and suggested I re-write the > TCP/IP stack in pascal!) > > Before embarking on a major project such as re-writing the stack, or > giving up and using IPX and Vines, I thought I'd try and see if anyone > knew: > > 1) What public domain / commercial TCP/IP stacks are there which might > be callable from turbo C? > peter@palin.cc.monash.edu.au Peter, a better idea is to buy a commercial stack, which usually loads a as a TSR. They usually have a documented API, or even a development kit with the relevent routines to interface to it. That way you can write your own pascal code or assembler to stuff registers and do an interrupt (or whatever mechanism they use to interface to the TSR), which is FAR easier than re-writing a TCP stack inside your application. All of the common commercial stacks have documented APIs... Paul Brooks |Internet: pwb@newt.phys.unsw.edu.au Uni. of N.S.W. |If you have trouble sleeping, try lying on the end of Kensington NSW 2033| your bed. With a little luck you'll drop off. AUSTRALIA | - Mark Twain.
-----------[000205][next][prev][last][first]---------------------------------------------------- Date: 19 Nov 1992 06:30:57 GMT From: emv@msen.com (Edward Vielmetti) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: Recommended Terminal Server
Bill Canning (usbill@ustores.missouri.edu) wrote:
: I'm looking for a fairly basic terminal server that won't cost a fortune. I
: need to get between 24 and 32 ports, although this could be with more than one
: unit. We will only be running 9.6K terminals on it, and we will be using it to
: attach to a Unix host via Telnet on an ethernet LAN. Does anyone have any
: recommendations?
We have had good luck with a Livingston Portmaster unit. They make
a 30 port box which plugs into the ethernet; it can be configured either
to tie ports back to a specific box (via telnet, rlogin, or their
portmaster-special daemon), or you can make it a little more general
and let people pick their host or even use SLIP or PPP to get out.
It sounds like the feature list is a little bit longer than you really
require, and that there might be a previous-generation stone dumb
terminal server that would do the job.
Here's the mailing list announcement I sent out...
To: tcp-ip@nic.ddn.mil
Cc: ppp-users@MorningStar.Com
Subject: new mailing list for Livingston Portmaster terminal servers
Date: Wed, 09 Sep 92 15:54:49 EDT
From: Edward Vielmetti <emv@msen.com>
I've set up a new mailing list for users of the Livingston Portmaster
line of terminal servers and routers. These boxes are in use by
several network service providers (including ourselves) to support
dialup SLIP and PPP access. Given that the demands of public
access dialup are somewhat more stressful than ordinary async service,
I thought it would be a good idea to get people working with the
equipment off on their own list to exchange working ideas and to
coordinate development requests.
The Portmaster series includes a 4-port 56K router (the IR-4) and a 10
port async terminal server (the PM-11) that supports SLIP and PPP.
To join the list send mail to
portmaster-users-request@msen.com
To submit messages to the list send to
portmaster-users@msen.com
Disclaimer: though we at Msen have some investment in the actual
equipment we have no financial stake in Livingston, and I see this as
a user self-support forum as much as it is a way to get information
from the equipment makers. Caveat vendor.
---
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
MSEN Inc., 628 Brooks, Ann Arbor MI 48103 +1 313 998 4562
A distributed system is one in which the failure of a computer you didn't
even know existed can render your own computer unusable. (Leslie Lamport)
------- End of Forwarded Message
-----------[000206][next][prev][last][first]---------------------------------------------------- Date: 19 Nov 92 10:41:16 GMT From: possoz@sic.epfl.ch (Anne Possoz EPFL-SIC/SL) To: comp.protocols.tcp-ip Subject: RPC vs sockets performance and network influence
Working a lot on transfer of huge arrays across different computers, I reached the following conclusions. 1) using Sun RPC (with underlying XDR), I can handle .2 to .6 Mbytes/sec depending on the platform on which I am working (here the CPU time is converted in Mbytes/sec); this has to be compared to the network which can handle around 1. Mbytes/sec for ethernet. So the CPU is slower than the network. The reason for this is that the XDR package is not at all optimized for this kind of problems. 2) using sockets, I can handle 3. to 10. Mbytes/sec instead. So now the network is my limitation. Moreover, I noticed that if data are going from FFDI network to ethernet network, I reach that performance only if I decrease the SO_RCVBUF size to 8 kbytes (the gain is a factor of 3 to 4 if SO_RCVBUF is set to 8 kbytes compared to 32 kbytes). Note that by default, SO_RCVBUF is 4K on SUN, 8K on HP, 32K on crays and 61K on SG. There is also some interest to increase the SO_SNDBUF to a value of 32K. Thus I have some questions to who migth help : - where can I find any information on performances? - does this means that any application using RPC are not suitable for large transfer of data? And, as far as I can read, NFS is based on RPC; does that mean that NFS is not optimized? - do you know of any other newsgroup where I could read on that subject? Anne -- Anne Possoz possoz@sic.epfl.ch
-----------[000207][next][prev][last][first]---------------------------------------------------- Date: Thu, 19 Nov 1992 11:17:05 GMT From: viau@wm.estec.esa.nl (Pierre "play-soccer-not-football" Viau) To: comp.protocols.tcp-ip Subject: Class D addresses and Multicast routers
Is there a FAQ about Class D addressing and Multicasting ?
If yes, could someone post it please ?
If no, could somebody say what the status of this thing is today ?
Thanks in advance.
---
Pierre Viau
ESTEC - WMS
European Space Agency
Keplerlaan, 1
2200 AG Noordwijk
The Netherlands
Fax: (31) [0]1719-85420
17400
Phone: (31) [0]1719-84357
83816
Preferred Email: viau@wm.estec.esa.nl
Desperate Email: pviau@estec.bitnet
pviau@estec.esa.nl
-----------[000208][next][prev][last][first]---------------------------------------------------- Date: 19 Nov 92 12:58:34 GMT From: G.Knight@cs.ucl.ac.uk (Graham Knight) To: comp.protocols.tcp-ip Subject: TCP/IP and ISDN / experiences with ISDN
Markus, We do this here with our own primary rate kit - basically we just put IP datagrams between HDLC flags on ISDN B-Channels which are set up on demand. I think lots of other people to this too. Try the list isdn@teknology.agderforskning.no for more information. Since you are in Germany you could talk to Clemens Schrimpe (csch@com.netcs) also. Graham
-----------[000209][next][prev][last][first]---------------------------------------------------- Date: Thu, 19 Nov 1992 15:13:55 GMT From: tbooth@netcom.com (Todd Booth) To: comp.protocols.tcp-ip Subject: Re: Multicast Routers (was Re: NIS broadcasts over IP subnets)
>... >In the sense you probably meant the question, I don't know. For years >I hounded router vendors at Interop, and was always told "wait for >OSPF." Why have you been waiting? OSPF is a draft internet standard and has been available for over a year and a half from Wellfleet Communicaitons (and other vendors). Cisco has been shipping OSPF since April? --todd
-----------[000210][next][prev][last][first]---------------------------------------------------- Date: 19 Nov 92 16:16:08 GMT From: scoggin@opus.ee.udel.edu (John K Scoggin) To: comp.protocols.tcp-ip Subject: Re: Multicast Routers (was Re: NIS broadcasts over IP subnets)
In article <1992Nov19.151355.20000@netcom.com> tbooth@netcom.com (Todd Booth) writes: >>... >>In the sense you probably meant the question, I don't know. For years >>I hounded router vendors at Interop, and was always told "wait for >>OSPF." > >Why have you been waiting? > >OSPF is a draft internet standard and has been available for over >a year and a half from Wellfleet Communicaitons (and other vendors). >Cisco has been shipping OSPF since April? > >--todd Because having OSPF is one thing, and having OSPF MULTI-CAST is quite another issue. Last I remember, OSPF Multicast is still in Draft state, as is the MIB. BTW, on the subject of Wellfleet - implementation of OSPF MIB has lagged FAR behind that of OSPF itself. Then the issue becomes - you can pass packets OK, but you want to MANAGE it too?? :-) - John ------------------------------------------------------------------------- John K. Scoggin, Jr. Email: scoggin@udel.edu Supervisor, Network Operations scoggin@delmarva.com Delmarva Power & Light Co. Voice: 302-451-5200 P.O. Box 6066 Fax: 302-451-5321 Newark, DE 19714-6066 ------------------------------------------------------------------------- Your milage may vary. Void where prohibited by law (or common sense).
-----------[000211][next][prev][last][first]---------------------------------------------------- Date: Thu, 19 Nov 1992 17:14:32 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Multicast Routers (was Re: NIS broadcasts over IP subnets)
In article <1992Nov19.151355.20000@netcom.com>, tbooth@netcom.com (Todd Booth) writes: > >... > >In the sense you probably meant the question, I don't know. For years > >I hounded router vendors at Interop, and was always told "wait for > >OSPF." > > Why have you been waiting? > > OSPF is a draft internet standard and has been available for over > a year and a half from Wellfleet Communicaitons (and other vendors). > Cisco has been shipping OSPF since April? I know OSPF has been a draft standard for ages. I was only repeating what the router vendors told me at Interop90 and before. In the rest of my text, I wrote that at Interop 91 I was told by Cisco and others "forget DVMRP, and wait for the new link state multicast protocol that even Steve Deering supports." (Well, I didn't explicitly write "Interop 91".) Why is the IETF multicasting this week being done with tunnels? Is that only because of the backbone? Do Wellfleet, Cisco, or others now do the right things when they see a class D address? Do they forward such IP packets? As far as I can tell, the router vendors have been dragging their feet vigorously on any kind of multicast routing for at least 4 years. The router vendors have shown more enthusiasm for PPP, despite the danger PPP represents to their locked-in customer bases. vjs
-----------[000212][next][prev][last][first]---------------------------------------------------- Date: 19 Nov 92 17:25:42 GMT From: ric@updike.sri.com (Richard Steinberger) To: comp.protocols.tcp-ip Subject: tcp vs. udp transfer rates in a LAN
I have two Suns separated by two repeaters (but no bridges or routers). When I do an FTP transfer I get xfer rates of 90 - 170 Kbs with an average of about 120 Kbs. When I do rcp I get rates closer to 1/10 of that: 14 - 21 Kbs (with one unusual xfer at 127 Kbs). nfs transfer rates (to/from disk from/to imported disk) are similar to rcp rates. When I do similar transfers between 2 SUNs on the same section of ethernet (no repeaters between them), I get ftp rates of 330 Kbs - 830 Kbs. rcp rates are 170 Kbs - 360 Kbs. I have been told that the repeaters can occassionally go into something called "partition" mode, where, if they see "too many" collisions, the temporarily stop repeating. I don't know if this is actually happening. Can anyone help with this? What should we look at next? [We have LAN analyzers and SW tools like tcpdump]. Is there any way to "tune" UDP tranfers? Is it likely that one or both repeaters can't handle the udp traffic, but is better able to handle tcp traffic? Thanks in advance for any replies/suggestions. ric steinberger ric@updike.sri.com
-----------[000213][next][prev][last][first]---------------------------------------------------- Date: 19 Nov 92 19:15:00 GMT From: fredrik@ludd.luth.se (Fredrik Markstrom) To: comp.protocols.tcp-ip Subject: Tokenring Without mau ???
I realy don't know is this is the right place to ask ??? But If I'm wrong please correct me !!! I've seen that a Token Ring MAU hasn't got any power-connection, and thereby I assume that it can't contain any active electronics, maybe some filters and relays (I've heard it clicking !!!). To the question : Is it possible to connect my to PC:s running TCP/IP on token ring, without a mau ??? Please answere by mail.... Pretnx...
-----------[000214][next][prev][last][first]---------------------------------------------------- Date: 19 Nov 92 20:25:43 GMT From: lvandyke@balboa.eng.uci.edu (Lee Van Dyke) To: comp.protocols.tcp-ip Subject: Difference between 32/16 bit ethernet boards?
Can anyone tell me what the performance differences are
between a 32 bit and 16 bit ethernet card?
(We will be going from a 386 PC to a Sun sparc if
that is any help)
--
Lee Van Dyke
lvandyke@balboa.eng.uci.edu,
UUCP: infotec!Infotec.COM!lee@sunkist.West.Sun.COM
-----------[000215][next][prev][last][first]---------------------------------------------------- Date: Thu, 19 Nov 1992 20:36:21 GMT From: ronf@panther3.panther.mot.com (Ron Feigen) To: comp.protocols.tcp-ip,comp.unix.wizards Subject: select()/ Bad File Number
I have got a puzzler??????? I have a situation where a socket gets closed and instead of select() returning informing me that the socket is ready for reading, I get -1 and errno "Bad File Number". Of course I have no clue as to which fid is bad. I really don't want to have to do a sequential search through my FD_SETs checking status on every fid. Is there any easier way????? Any help/info/clues would be greatly appreciated!!!!! Ron -- > Ron Feigen ronf@panther.mot.com
-----------[000216][next][prev][last][first]---------------------------------------------------- Date: 19 Nov 92 21:45:55 GMT From: lvandyke@balboa.eng.uci.edu (Lee Van Dyke) To: comp.protocols.tcp-ip Subject: Wanted ftp sites for wattcp and cutcp
Can someone please tell me where to get the above?
If it's on wuarchive.wustl.edu I have not
been able to log on for weeks. Maybe I'll have
to get autoftp working again. :(
--
Lee Van Dyke
lvandyke@balboa.eng.uci.edu,
UUCP: infotec!Infotec.COM!lee@sunkist.West.Sun.COM
-----------[000217][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Nov 1992 05:36:47 GMT From: logier@cheops.qld.tne.oz.au (Rob Logie) To: comp.protocols.tcp-ip,comp.protocols.ibm Subject: Re: SNA <-> IP Encapsulation
mndot@msus1.msus.edu writes: >I am new to this particular news feed so this may have been asked in the past. >I am not very familiar with IBM host equipment either. >I am trying to provide mainframe connectivity to a number of remote sites. >Most of the sites have IBM 3174 (or compatible) remote controllers for SNA >communications. This comm. takes place over multidrop 9600 bps lines. We are >in the process of installing T1 circuits to all of those same locations. The >T1's are primarily IP. Does software exist for the 3174 to allow SNA >encapsulation in IP packets? I have seen hints of this scenario on some of the >news feeds but I am not sure which ones. Any help with this would be greatly >appreciated. > -- Al I have done it using perment virtual circuits between terminal servers using a terminal server at each end (3COM CS200's). Been working for a few years without trouble. -- Rob Logie | The opions expressed are mine alone and in Telecom Australia ACN 051 775 556 | no-way reflect the views or policies of the TNE Computer Support Services | Australian and Overseas Telecommunications EMAIL: logier@cheops.qld.tne.oz.au| Corporation. "These are my opinions alone"
-----------[000218][next][prev][last][first]---------------------------------------------------- Date: 20 Nov 92 06:10:08 GMT From: sss@scammell.ecos.tne.oz.au (Steve Silver) To: comp.protocols.tcp-ip Subject: Details of Service Name to Socket Type
To all TCP/IP gurus. I am trying to locate the RFC or documention describing all known Service Name types to Socket types (eg. telnet = 23/tcp, ftp = 21/tcp). Could you please send the info to my E-mail address and/or this Bulletin Board. Thank you for your anticipated help. -- Steve Silver sss@scammell.ecos.tne.oz.au
-----------[000219][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Nov 1992 06:22:32 GMT From: tbooth@netcom.com (Todd Booth) To: comp.protocols.tcp-ip Subject: Re: Multicast Routers (was Re: NIS broadcasts over IP subnets)
>>OSPF is a draft internet standard and has been available for over >>a year and a half from Wellfleet Communicaitons (and other vendors). >>Cisco has been shipping OSPF since April? > ...BTW, on the subject of Wellfleet - implementation of OSPF MIB has lagged >FAR behind that of OSPF itself... Are there *any* leading router vendors that support the OSPF MIB? I don't think Cisco has as of 9.1B. There are at least a few sites out there that *think* they can MANAGE their nets without the OSPF MIB :-) . --todd
-----------[000220][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Nov 1992 06:57:33 GMT From: tbooth@netcom.com (Todd Booth) To: comp.protocols.tcp-ip Subject: Re: Multicast Routers (was Re: NIS broadcasts over IP subnets)
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >... >As far as I can tell, the router vendors have been dragging their feet >vigorously on any kind of multicast routing for at least 4 years. The >router vendors have shown more enthusiasm for PPP, despite the danger >PPP represents to their locked-in customer bases. I can't speak for others, but I get requests for multi-vendor interoperability over leased lines over 50 times as often as for multicast routing. Are there a lot of people out there with requirements for multicast routing? Could anyone quantify how many routers would be used for multicast routing? Maybe 1 out of 10, 1 out of 1000...? Assuming it is closer to 1 out of 1000, why not use a high end router for the non-multicast and a Sun or whatever for the multicast? PPP allows our customers to use less expensive IPX or IP routers, from other vendors, and interoperate with Wellfleet equipment at the central site. I think this newsgroup would tear to shreads any router vendors that did not support PPP (at least IP over PPP with static support). --todd
-----------[000221][next][prev][last][first]---------------------------------------------------- Date: 20 Nov 92 10:00:42 From: Steinar.Haug@delab.sintef.no (Steinar Haug) To: comp.protocols.tcp-ip,comp.dcom.lans.ethernet Subject: Re: Wanted: Advice on calculating timing gaps between packets.
hcb@world.std.com (Howard C Berkowitz) writes: >A few random things to consider. You will never get the true 10 MBPS from >an IEEE 802.3/ETHERNET LAN, due to some timing requirements of the protocol >itself. There must be a minimum 9.6 microsecond delay between packets; this >is part of the medium access control process. There must be enough idle >time that the most distant station will hear a jam signal. > >Assuming a single transmitter and a single receiver, the maximum possible >frame-level transfer rate will be based on the length (or length distribution) >of frames, plus the interframe delay. You may not get 100%, no. But modern workstations can get very close (say better than 95%). >I often find it worthwhile to write a reasonably quick-and-dirty Monte Carlo >simulation of the line protocols rather than go too far in analyzing them. How about actually *measuring* instead? With tools like ttcp and a quiet (two station) Ethernet, I can get better than 1 MByte/s (yes, 1048576 B/s) between two Sparc IPCs. And you certainly can't claim they are top of the line these days... People seem fond of propagating the idea that you will never be able to fully load an Ethernet. Well, you can! And despite theoretical predictions to the contrary, Ethernet handles a high load very well, degrades gracefully and is in general extremely reliable. Steinar Haug, system/networks administrator SINTEF DELAB, University of Trondheim, NORWAY Email: Steinar.Haug@delab.sintef.no, sthaug@idt.unit.no, steinar@tosca.er.sintef.no
-----------[000222][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Nov 1992 09:00:57 GMT From: cproto@cs.curtin.edu.au (Computer Protocol) To: comp.protocols.tcp-ip Subject: RIP and OSPF implementations
I am looking for public or commercial implementations of the following IP routing protocols: OSPF and RIP. Any contacts which you can suggest (either via news or mail to me direct) would be appreciated. Heather Payne Datacraft Technologies 11 Brodie Hall Drive BENTLEY WA 6102 AUSTRALIA EMAIL: cproto@cs.curtin.edu.au PHONE: + 61 9 470 2333 FAX: + 61 9 362 2430
-----------[000223][next][prev][last][first]---------------------------------------------------- Date: 20 Nov 92 09:40:14 GMT From: jim@grimaldi.rutgers.edu (Jim Martin) To: comp.protocols.tcp-ip Subject: Re: Wanted ftp sites for wattcp and cutcp
lvandyke@balboa.eng.uci.edu (Lee Van Dyke) writes:
>Can someone please tell me where to get the above?
Both packages are available on dorm.rutgers.edu (128.6.18.15).
Dorm mirrors both wattcp and cutcp, as well as a number of other PC
(and Mac) network packages on a nightly basis.
Jim
--
Jim Martin Internet: jim@dorm.rutgers.edu
Network Services UUCP: {backbone}!rutgers!jim
Rutgers University Phone: (908) 932-3719
-----------[000224][next][prev][last][first]---------------------------------------------------- Date: 20 Nov 92 10:26:16 GMT From: cgra@btma74.nohost.nodomain To: comp.protocols.ibm,comp.protocols.tcp-ip Subject: Re: NFS
In article <1992Nov13.172400.5004@gumby.dsd.trw.com>, modic@gumby.dsd.trw.com (Jeanine A. Modic-Carmona) writes: |>Path: se.alcbel!alcbel!ub4b!mcsun!Germany.EU.net!rrz.uni-koeln.de!unidui!math.fu-berlin.de!news.belwue.de!ira.uka.de!ira.uka.de!sol.ctr.columbia.edu!usc!venice!gumby.dsd.trw.com!modic |>From: modic@gumby.dsd.trw.com (Jeanine A. Modic-Carmona) |>Newsgroups: comp.protocols.ibm,comp.protocols.tcp-ip |>Subject: NFS |>Message-ID: <1992Nov13.172400.5004@gumby.dsd.trw.com> |>Date: 13 Nov 92 17:24:00 GMT |>Organization: TRW Space & Defense, Redondo Beach, CA |>Lines: 122 |>Xref: se.alcbel comp.protocols.ibm:286 comp.protocols.tcp-ip:5086 |> |> |>Hi! I was wondering if anyone has tried to backup a PC or Mac to an IBM |>mainframe via TCP/IP? If so, how? |> [ text deleted...] [repetitions deleted...] Tried using echo suppression?:-))
-----------[000225][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Nov 1992 10:52:33 GMT From: gdox@informatik.tu-chemnitz.de (Guntram Dox) To: comp.protocols.tcp-ip Subject: What is "RMON" ? Please explain .
Hi, I read the term "RMON" in a marketing paper from cabletron. Somebody told me, it should be something new on top of SNMP . Programming interface , or so. Could somebody explain it in more detail ? Please, email to me, too. My access to this news group will be a little bit difficult in the next weeks. Or any pointers to other information would be great. Ta, Guntram University of Humberside, UK
-----------[000226][next][prev][last][first]---------------------------------------------------- Date: 20 Nov 92 16:11:42 EST From: jehresman@eagle.wesleyan.edu To: comp.protocols.tcp-ip Subject: SUN RPC in sys V r 3 w/ WIN/TCP?
Has anyone successfully compiled the sunrpc-4.0 package to a sys V r 3 machine using WIN/TCP? Would it be better to rewrite the functions in the BSD libraries ourselves or to find source for a general purpose BSD library? Our intention is to try to get a PD version of NFS working on top of this, so I also want info / comments on the PD versions of nfs. Thanks in advance, John Ehresman
-----------[000227][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Nov 1992 13:27:32 GMT From: bwarner@mentor.cc.purdue.edu (Bill Warner) To: comp.protocols.tcp-ip Subject: Re: Details of Service Name to Socket Type
In article <1992Nov20.061008.6630@scammell.ecos.tne.oz.au> sss@scammell.ecos.tne.oz.au (Steve Silver) writes: >To all TCP/IP gurus. > >I am trying to locate the RFC or documention describing all known >Service Name types to Socket types (eg. telnet = 23/tcp, ftp = 21/tcp). > The current Assigned Numbers document is RFC 1340. -Bill -- Bill Warner (317)494-1787 General Consulting bwarner@cc.purdue.edu Purdue University Computing Center bwarner@PURCCVM.BITNET
-----------[000228][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Nov 1992 14:57:12 GMT From: bj@unislc.uucp (Bruce Jones) To: comp.protocols.tcp-ip,comp.dcom.lans.ethernet Subject: Re: Wanted: Advice on calculating timing gaps between packets.
In article <STEINAR.HAUG.92Nov20100042@delab.sintef.no> Steinar.Haug@delab.sintef.no (Steinar Haug) writes:
>How about actually *measuring* instead? With tools like ttcp and a quiet
^^^^^^^^
>(two station) Ethernet, I can get better than 1 MByte/s (yes, 1048576 B/s)
>between two Sparc IPCs. And you certainly can't claim they are top of the
>line these days...
>
>Steinar Haug, system/networks administrator
>SINTEF DELAB, University of Trondheim, NORWAY
>Email: Steinar.Haug@delab.sintef.no,
> sthaug@idt.unit.no, steinar@tosca.er.sintef.no
Is this program freely available (ttcp)? I am looking for some kind of
performance measurement tool.
Thanks,
Bruce Jones
--
Unisys bj@unislc.slc.unisys.com
Salt Lake City, Utah {sun, uunet}!unislc!bj
(801)-594-7046
-----------[000229][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Nov 1992 18:08:05 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip,comp.dcom.lans.ethernet Subject: Re: Wanted: Advice on calculating timing gaps between packets.
In article <1992Nov20.145712.5931@unislc.uucp>, bj@unislc.uucp (Bruce Jones) writes: > ... > Is this program freely available (ttcp)? I am looking for some kind of > performance measurement tool. The original is somewhere on brl.mil. You can also ftp the original and a spiffed up version of the source on sgi.com. Vernon Schryver, vjs@sgi.com
-----------[000230][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Nov 1992 19:40:54 GMT From: ramon@helix.nih.gov (Ramon J. Hontanon) To: comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc,vmsnet.networks.tcp-ip.wintcp Subject: WIN-TCP/DECwindows device conflict. Whats's up with that?????
In upgrading our trusty VAXstationII GPX from VMS 5.0 to VMS 5.4 we found out that our version of The Wollongong Groups's TCP/IP allocates three devices (GAA0: GAA1: GAA2:) that will need to be used by DECwindows. The result: DECwindows refuses to install. The DEC people found this out, and it seems true, 'cause DECwindows starts fine if I don't run WIN/TCP. I guess my question is: What version of WIN/TCP do I need to go to in order to fix this bug? Will we be required to buy the product again, or do we just simply upgrade? The e-mail address of The Wollongong Group would also be appreciated. Thanks in advance ramon@helix.nih.gov
-----------[000231][next][prev][last][first]---------------------------------------------------- Date: 20 Nov 92 20:09:10 GMT From: kudzu@netcom.com (Michael Sierchio) To: comp.protocols.tcp-ip,comp.dcom.lans.ethernet Subject: Re: Wanted: Advice on calculating timing gaps between packets.
Measured Capacity of an Ethernet: Myths and Reality Boggs, Mogul, and Kent Digital Western Research Laboratory Mail server is WRL-techreports@decwrl.dec.com Send a message w/subject: help to get info. -- +--------------------------------------------------------------------------+ | Michael Sierchio 1563 Solano Avenue, Suite 123 | | kudzu@netcom.com Berkeley, CA 94707-2116 | +--------------------------------------------------------------------------+
-----------[000232][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Nov 1992 20:29:06 GMT From: dedgar@mta.ca To: comp.protocols.tcp-ip Subject: ARP & Duplicate IP addresses
Hello Net
I would value opinions, advice and information on the topic of handling
duplicate IP addresses with ARP.
Specifically
- Is it a good idea to ARP your own IP address on startup? A returning
ARP would tell you that the address was a duplicate.
- if so is it a good idea to automatically shut your interface down
if a duplicate IP address is detected on startup? Are there any
situations where false returns might be reported?
- What about detecting one after startup? Should you advise the user
and gently start terminating connections? Could be real annoying.
- If you receive an incoming ARP request and the sender IP address matches
yours should you reply to it? Doing so would advice the other node that
a duplicate exists (assuming it checks) but also could hopelessly confuse
a host that doesn't. All of the implementations that I have tested do not
reply - but I have not tried all that many.
- What are the consequenses of staying up with a duplicate IP address?
I would value some insight into this topic. Thank You
- Dale Edgar
Cybernetic Control Inc.
DEDGAR@MTA.CA
-----------[000233][next][prev][last][first]---------------------------------------------------- Date: 20 Nov 92 20:36:57 GMT From: manmetha@gauss.rutgers.edu (Rajesh Malhotra) To: comp.protocols.tcp-ip Subject: Recommendations for Terminal Servers
I had an error in a previous post, and am not sure if it got posted,
so this may be a REPOST. If so, I apologize.
Fellow Netters,
The following is being posted for a friend with no Internet
access. Please send responses to this account, and I will forward them.
Raj.
--------------------------------------------------------------------------
We are looking for recommendations for SLIP connectivity to an IBM RS/6000.
We have been told that the included SLIP device driver on the RS/6000
only supports 8 concurrent connections. We are considering placing
terminal servers across an ethernet connection. By placing the modem
pool on the terminal server we will be able to have the Slip connection
be routed across the ethernet to the RS/6000. We know of no limit on
the number of TCP connections to the RS/6000.
The requirements are:
1. 9 to 50 SLIP connections to one or more terminal servers.
2. Data rates of 19.2 to 56.7Kbps, expecting to use some
switched 56kbps lines with async to sync converters.
3. Transparent access directly from the Mac to the RS/6000.
We wish to avoid the need to login to the terminal server.
We wish to have all calls routed to 1 or alternate
RS/6000's.
We wish to have IP addresses dynamically assigned to
the remote user, independent of the phone line to the
terminal server that they use.
The remote nodes are Apple Macintoshes running MacTCP, by Apple,
and MacSLIP, by Hydepark Software. Without a terminal server we can
use the bootp daemon to dynamically assign addresses to the remote
users(so I'm told). Do any terminal servers do this or have an
alternative method? The goal is to forego addressing changes on the
remote nodes based on the phone line used for access.
We are considering the Telebit Netblazer. We would also consider a
better SLIP device driver. Recommendations?
--------------------------------------------------------------------------
--
===============================================================================
__ __ .
/ __/ / Raj Malhotra.
/ ( /_ / voice : (908)613 4313.
__/ email : manmetha@gauss.rutgers.edu
===============================================================================
-----------[000234][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Nov 1992 20:43:38 GMT From: solomon@becks.comm.mot.com (James Solomon) To: comp.protocols.tcp-ip Subject: Need list of commercial TCP/IP source code vendors
The subject line says it all. Sorry if this is a FAQ but I haven't seen this here lately. Please respond by Email. If I get enough interest I'll post the response. Thank you, -- Jim Solomon (solomon@comm.mot.com) Disclaimer: It's my fault, not Motorola's.
-----------[000235][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Nov 1992 21:26:17 GMT From: "Mun Kein CHANG" <p00196@psilink.com> To: comp.protocols.tcp-ip Subject: Public Domain DNS
I am looking for a public implementation of a DNS server on PC, preferably being able to work in conjunction with FTP's PC/TCP. Anyone's got any ideas? Thanks and regards, Mun-Kein.
-----------[000236][next][prev][last][first]---------------------------------------------------- Date: 20 Nov 92 21:38:14 GMT From: pearce@hook.corp.mot.com (Mike Pearce) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.realtime,mot.general Subject: Looking for embedded TCP/IP implementations
I'm looking for suggestions of TCP/IP products available in source-code form in embedded environments as well as MS-DOS. Our requirements are (briefly): - must support multiple interfaces per host (i.e. 'multi-homing' as defined by the rfc's), but does not require full routing capabilities. - fairly small (I'll take what I can get, though). - supported (I'd really only consider commercial solutions in other words). - source-licensable for development, binary licensable for distribution with a product. Pricing is negotiable. - 'standard' API (i.e. Berkeley sockets preferred, TLI second choice). Since this will be running inside of a DOS virtual-machine under Windows 3.1 in 386 enhanced mode, there is no hard requirement for the API to be available to other Windows &/or DVM processes, but would that would be nice. - 'standard' network interface, preferably Crynwr (Clarkson) packet driver, but NDIS or ODI will do. So far I've played with KA9Q's NOS, but it's kind of buggy, large, and is really starting to look hacked up. Also, its lack of real support and unclear licensing really rules it out for serious consideration. We're also talking with Interactive about their StreamWare/TCP, which provides a System V compatible STREAMS environment, is supported, and source and binary licensable. But it's a little expensive, and I'd really like to find out what else is available. Please email responses to pearce@hook.corp.mot.com - I will summarize to the net if requested. Thanks for your time, Mike ---- Mike Pearce Staff Engineer, Motorola, Inc. Corporate Computer & Communications Research & Development Schaumburg, IL email: pearce@hook.corp.mot.com phone: (708) 576-0999 fax: (708) 576-0892
-----------[000237][next][prev][last][first]---------------------------------------------------- Date: 20 Nov 92 22:23:19 GMT From: kherron@ms.uky.edu (Kenneth Herron) To: comp.protocols.tcp-ip,comp.unix.wizards Subject: Re: select()/ Bad File Number
ronf@panther3.panther.mot.com (Ron Feigen) writes: >I have a situation where a socket gets closed and instead of select() >returning informing me that the socket is ready for reading, I get -1 and errno >"Bad File Number". We have a daemon that does the same thing when it accepts a connection and no fds are available (this is dynix so the fd table is small and static). As far as I can tell, the client's connect succeeds, and the server sometimes acts like the accept() has succeeded (I'm not too clear on this part), but any attempt to use the fd from either side gives an EBADF. My conclusion is that dynix's network code is completely unprepared to deal with this problem :-) In summary: Check the size of your fd table. -- Kenneth Herron kherron@ms.uky.edu University of Kentucky +1 606 257 2975 Dept. of Mathematics "Your ball goes over them, it sails off the edge into a huge cauldren of fire-breathing dragons." "And they call this a par three?"
-----------[000238][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Nov 1992 22:56:39 GMT From: john@iastate.edu (John Hascall) To: comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip Subject: Re: Domain Name Service Deficiencies
tld5032@bcstec.ca.boeing.com (Terry Davis) writes:
}
} This post attempts to summarize some experiences in utilizing DNS
} in a very large corporate environment. The installed base here
} of TCP/IP includes over 50,000 active IP addresses ...
Here are some of my thoughts. We are about an order of magnitude
smaller but make a fair use of DNS and its cousin Hesiod.
} 1) DNS is designed to support INTERNET access not local users.
} If the local LAN does not have a DNS nameserver on it, many user
} environments will cease to function if the primary network feed
} is lost.
I am not sure I understand what you are saying here. I agree that
if a host can not reach a nameserver then things get grim, but I
don't know why you'ld need one on each LAN. I would think 2
or 3 per "campus" would be adequate.
} Configurable timeouts and re-trys might help this greatly by
} allowing the system to be tuned for its environment, LAN or
} INTERNET. It seems likely that these should be placed in the
} /etc/resolv.conf file if they are used.
I hate the way it always scans /etc/resolv.conf from top to bottom.
This file should be read in-core and when the number-1 server is
not responding, switch to another until it returns -- in fact I have
toyed with the idea of writing a kluge daemon which does periodic DNS
requests and re-orders /etc/resolv.conf when trouble is found.
} 2) There is no standard way of determining which secondary
} database to use (/etc/hosts or yphosts) when DNS is inoperable.
} Worse yet is the case where no secondary lookup is allowed by the
} operating system. Very strange things happen when DNS fails and
} the secondary lookup either is non-existent or also fails. Often
} mounts and remote processes simply vanish. It should not be re-
} quired for instance, for the administrator to maintain /etc/hosts
} when NIS is already running on the system or to run NIS just to
} support a secondary lookup function for DNS when /etc/hosts is
} already configured.
}
} Again, a configurable database lookup sequence for gethostbyname
} and gethostbyaddress resolve would go far to solve this problem.
Like DEC's /etc/svc.conf which I really like. Example line:
hosts=local,bind,yp
} 4) In the operations area one of the shortcomings of DNS is that
} the "refresh" and "expire" fields cannot be set to a specific
} time like refresh 5 minutes after every hour, or expire at 4:45
} AM on Thursdays much like a crontab entry. In a large operation
} with tens of primary and secondary servers, the timing of these
} events becomes increasingly important to overall DNS stability
} and responsiveness.
}
} 5) Another DNS flaw is the lack of the ability to force a primary
} server to reload or update only one of its many zones. Often DNS
} primary servers are reloaded hourly in order to keep up with
} changes coming in. This can render a server unavailable for
} several minutes when it has dozens of zones and thousands of host
} and address entries to re-hash.
}
} 6) Full implementation of dynamic updates to DNS would be a major
} improvement in its operational functionality. This could relieve
} many of DNS operational difficulties.
This is what I wish for most. We update every hour and every hour
we have a minute or so of wierdness while they read their files.
Also, if we happen to have lost connectivity to the world (the root
DNS servers) everything is all hosed over.
} 9) Another issue on the horizon, is the compatibility of Netbios
} nameservice, DNS, and X.500. It would seem that these services
} should be converging on a single standard; as of yet this isn't
} clear.
DCE CDS, maybe?
} 11) In addition to DNS, the resolver routines "gethostbyname"
} and "gethostbyaddr" need some extensive enhancements for life in
} the network environment. Some form of short lived caching needs
} to be provided, probably a most recent "10" lookups ...
There would need to be some sort of short clock-time limit as well.
I know we have machines which could go for a long time before looking
up that 11th machine.
John
--
John Hascall ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center + Ames, IA 50011 + 515/294-9551
-----------[000239][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Nov 1992 23:12:16 GMT From: mcs@unislc.uucp (Michael Sontum) To: comp.protocols.tcp-ip Subject: Re: What is "RMON" ? Please explain .
From article <gdox.722256753@informatik.tu-chemnitz.de>, by gdox@informatik.tu-chemnitz.de (Guntram Dox):
>
> Hi,
>
> I read the term "RMON" in a marketing paper from cabletron.
>
> Somebody told me, it should be something new on top of SNMP . Programming
> interface , or so.
>
> Could somebody explain it in more detail ?
> Please, email to me, too. My access to this news group will be a little bit
> difficult in the next weeks.
> Or any pointers to other information would be great.
>
My knowledge is also sketchy but I recall that it is something like providing
almost a sniffer type capability to snmp.
You might try comp.protocols.snmp
I looked through Marshall T. Rose "The Simple Book" from Prentice Hall and
the index was down right annoying. I did not see any reference to it.
The only other thing is the gurus have an electronic magazine you can
get for free by emailing to
To: st_subscriptions@simple_times.org
Subject: help
Add me to the mailing list.
There is also an snmp discussion group: send a note to
snmp_request@uu.psi.com
and asked to be added to the snmp@uu.psi.com list
Also look at the rfc's.
Mike Sontum
"SNMP:That Dog'll Hunt" -Dr.Jeffrey D. Case
-----------[000240][next][prev][last][first]---------------------------------------------------- Date: Sat, 21 Nov 1992 02:05:08 GMT From: Frank@mindlink.bc.ca (Frank I. Reiter) To: comp.protocols.tcp-ip Subject: SCO ODT, DNS queries within a C program
I am currently writing some code to enable a C application to lookup MX records by calling res_mkquery() and res_send() under SCO ODT 2.0. What I am seeing is that the first time we do it everything works as expected, but the second time the answer that comes back is much shorter and in the course of trying to parse it we dump core. The arguments to res_mkquery() and res_send() are the same both times. Has anyone else ever seen a problem like this? Frank. -- ___________________________________________________________________ Frank I. Reiter Internet: Frank@mindlink.bc.ca MIND LINK! Communications Corp. Surrey, British Columbia, Canada
-----------[000241][next][prev][last][first]---------------------------------------------------- Date: Sat, 21 Nov 1992 09:03:52 EST From: Peter M. Weiss <PMW1@psuvm.psu.edu> To: comp.protocols.tcp-ip,comp.protocols.ibm Subject: Re: SNA <-> IP Encapsulation
In article <1992Nov20.053647.25809@cheops.qld.tne.oz.au>, logier@cheops.qld.tne.oz.au (Rob Logie) says: >mndot@msus1.msus.edu writes: >>I am trying to provide mainframe connectivity to a number of remote sites. >>Most of the sites have IBM 3174 (or compatible) remote controllers for SNA >>communications. This comm. takes place over multidrop 9600 bps lines. We are >>in the process of installing T1 circuits to all of those same locations. The >>T1's are primarily IP. Does software exist for the 3174 to allow SNA >>encapsulation in IP packets? I have seen hints of this scenario on some of e Believe it or not, there is optional RPQs for LIC 3174 that allow the 3174 to be a communications gateway to an IP network. This also involves converting/adding a TRN interface, and coax-attached PCs. Don't know its available in IBM W.T. countries. /Pete (pmw1@psuvm.psu.edu) -- Peter M. Weiss | not affiliated with psuvm.psu.edu|psuvm 31 Shields Bldg -- Penn State Univ.| "Connectivity is more than a Connection" University Park, PA USA 16802-1202 | E. Michael Staman, _The Circuit_, Apr 92
-----------[000242][next][prev][last][first]---------------------------------------------------- Date: Sat, 21 Nov 1992 05:53:49 GMT From: jmfres11@ucs.usl.edu (Karthikeyan Gurnswamy) To: comp.protocols.tcp-ip Subject: Pascal Waterloo TCP/IP library
In article <peter.722065275@palin.cc.monash.edu.au> peter@palin.cc.monash.edu.au (Peter Hawkins) writes: >I need to interface a turbo pascal (V6) application to TCP/IP. The >application is heavily OOP & TVision etc so I pretty well am forced >to use turbo pascal. It's huge & re-writing in C is not practical. >I could use novell IPX & Banyan Vines, but I want it to be more >general if I can. > >I got a copy of wattcp - a mixture of asm & C, and compiled it with >BCC, but unfortunately I couldn't link the C & pascal object files >without leaving unresolved externals - Borland's advice was that >interfacing C to Pascal will not work with any C code which is either >not-straightforward (in calling) or which utilises intrinsic libraries. >(They advised against my attempting it - and suggested I re-write the >TCP/IP stack in pascal!) First get the Waterloo TCP/IP manual and make identical functions in C itself like psock_init(), psock_read() which calls sock_init() and sock_read() respectively. Declare psock_init() in the waterloo as pascal psock_init() This directive is for linking your pascal routines correctly with the C function with correct function parameters. You have do the pascal psock_init() in one of the Waterloo TCP/IP source files itself. Build the Waterloo TCP/IP library. Now make a small pascal routine which calls psock_init() or psock_read() and compile and link it with the new library and all the support pascal and c libraries like cs.lib + maths.lib etc., Wild guess - Might work ... >Before embarking on a major project such as re-writing the stack, or >giving up and using IPX and Vines, I thought I'd try and see if anyone >knew: > >1) What public domain / commercial TCP/IP stacks are there which might > be callable from turbo C? > >2) Are there any stacks around written entirely in assembly or (joy of > joys!) pascal? > >Thanks in advance, > >Peter Karthik /----------------------------------------\--------------------------\ | Karthikeyan Guruswamy | | | Graduate Student, Computer Science | Why does'nt my: | | Center for Advanced Computer Studies | | | Univ. of SouthWestern Louisiana | NET WORK ? | | Lafayette, LA 70501 | | | Email: jmfres11@ucs.usl.edu | | | \--------------------------\ | The opinions stated are solely mine and does not reflect the views| | of anyone in my organization ... | \-------------------------------------------------------------------/
-----------[000243][next][prev][last][first]---------------------------------------------------- Date: Sat, 21 Nov 1992 06:31:11 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: ARP & Duplicate IP addresses
In article <1992Nov20.202906.9279@jupiter.sun.csd.unb.ca>, dedgar@mta.ca writes: > Hello Net > > I would value opinions, advice and information on the topic of handling > duplicate IP addresses with ARP. > > Specifically > - Is it a good idea to ARP your own IP address on startup? A returning > ARP would tell you that the address was a duplicate. > - if so is it a good idea to automatically shut your interface down > if a duplicate IP address is detected on startup? Are there any > situations where false returns might be reported? > - What about detecting one after startup? Should you advise the user > and gently start terminating connections? Could be real annoying. > > - If you receive an incoming ARP request and the sender IP address matches > yours should you reply to it? Doing so would advice the other node that > a duplicate exists (assuming it checks) but also could hopelessly confuse > a host that doesn't. All of the implementations that I have tested do not > reply - but I have not tried all that many. > > - What are the consequenses of staying up with a duplicate IP address? > > I would value some insight into this topic. Thank You For some years Silicon Graphics systems have actively defended their IP addresses. Instead of just complaining on the console when they see some other machine ARP'ing their IP address, they respond with an ARP response of their own. (With a suitable timeout to prevent network storms.) If you don't do this the first machine with the duplicate IP address to speak disappears. And the 2nd machine never notices that anything is wrong. On the other hand, this ARP screaming often keeps both stations on the air for rlogin or telnet long enough to take corrective action, avoiding the need for a house call. As important, having the old holder of the address scream causes the interloper to complain on its console (assuming BSD style console complaints). The machine that needs correcting is probably the new user of the IP address. Vernon Schryver, vjs@sgi.com
-----------[000244][next][prev][last][first]---------------------------------------------------- Date: 21 Nov 92 10:08:55 GMT From: j.laidman@cowan.edu.au (Jeremy Laidman) To: comp.protocols.tcp-ip Subject: Re: REQ: MSDOS TCP/IP stack in ASM or Pascal
peter@palin.cc.monash.edu.au (Peter Hawkins) writes: >I need to interface a turbo pascal (V6) application to TCP/IP. The >application is heavily OOP & TVision etc so I pretty well am forced >to use turbo pascal. It's huge & re-writing in C is not practical. [stuff deleted] >Before embarking on a major project such as re-writing the stack, or >giving up and using IPX and Vines, I thought I'd try and see if anyone >knew: >1) What public domain / commercial TCP/IP stacks are there which might > be callable from turbo C? >2) Are there any stacks around written entirely in assembly or (joy of > joys!) pascal? I have a copy of PCGopher source code that I got on the internet somewhere. This has been written in TP6 and interfaces to packet drivers. I believe this was written using TVision. It went under the name of PCG2_SRC.ZIP. Drop me a line if you work out how to use it. --------------------------------------------------------------------- Jeremy Laidman, Computer Support Officer Department of Computer Science Phone: (61 9) 370 6648 Edith Cowan University Fax: (61 9) 370 2910 Perth, Western Australia j.laidman@cowan.edu.au ---------------------------------------------------------------------
-----------[000245][next][prev][last][first]---------------------------------------------------- Date: 21 Nov 92 11:21:50 GMT From: heimir@plusplus.is (Heimir Thor Sverrisson) To: comp.protocols.tcp-ip Subject: Re: X.25 X.29 software wanted for RS6000
gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546) writes:
> Hi, I've been entasked with locating software which runs
> on an RS6000 under AIX and which provides X.25 connectivity
> (serial 56Kbps links) and X.29 PAD (incoming and outgoing)
> as well as application hooks (like sockets).
> Can anyone here direct me to who makes or sells such
> software?
Try:
Hugbunadur hf, P.O. Box 437, 202 Kopavogur, Iceland
Tel: +354-1-641024, Fax: +354-1-46288
They are selling a product called HBX-PAD conforming to X.3, X.28 and
X.29 with simple program hooks as well. I have no direct connection to
them anymore, but was on the team that developed the product, so I
won't tell anymore about it - ask them.
--
Heimir Thor Sverrisson | heimir@plusplus.is
Plusplus Inc. |
Laugavegi 13 | Tel: +354-1-620 250
108 Reykjavik, ICELAND | Fax: +354-1-622 819
-----------[000246][next][prev][last][first]---------------------------------------------------- Date: 21 Nov 92 18:59:59 MDT From: jrd@cc.usu.edu (Joe Doupnik) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: MS-Kermit 3.12 + TCP + PKTMUX-12 ???
In article <1992Nov21.181645.8204@nsscmail.att.com>, rick@nsscmail.att.com (Rick Calder) writes:
> Has anyone gotten mskermit 3.12 to work with pktmux 12 when other
> TCP software is also active ??
> When I run kermit via TCP as the 1st pktmux user, there is no problem.
> If something else has the 1st pktdrv, like PCTCP ethdrv, then the kermit
> session over TCP will lockup on the UNIX host side. Kermit is still active,
> the UNIX side still has its shell running, but nothing can be entered to
> UNIX via kermit. Kermit does still respond, as I can do a normal hangup.
>
> setup that works : setup that doesn't work :
> autoexec.bat : autoexec.bat :
> pktmux pktmux
> pktdrv pktdrv
> pktdrv pktdrv
> run kermit via tcp ethdrv
> run kermit via tcp
>
> Thanks in advance,
>
> Rick Calder
> [att!]rick!rick rick@rick.att.com
> attmail!rcalder
> --
> Rick Calder, NCR Systems Support Center - New Jersey
> [att!]rick!rick rick@rick.att.com
> attmail!rcalder
-------------------
Of course, it's not Kermit as such, but any TCP/IP Telnet application
which would produce this result. A packet monitor and a quiet day is needed
to sort out the changes pktmux probably made to the Telnet traffic from Kermit
(all legit stuff, nothing wierd). So, once again we need to remind people that
as clever as pktmux is, and it is clever, it cannot solve many fundamental
conflicts because there are no solutions. I hope that nothing important was
lost in these tests.
You might notice something useful about the way Kermit employs
Telnet. It attaches to the Packet Driver when Telnet service is required, and
then it frees that attachment at the end of the Telnet session, all while
remaining active.
Folks will chuckle at the following suggestion, but it is consider
purchasing a second lan adapter. Today's prices of $100-$200 make it realistic.
And yes, the laughter is at the irony of coming full circle. Alternatively,
you could run Kermit over FTP's tnglass Int 14h hooker, or over a handy
NetBios link to the Unix box (if convenient), etc. Kermit supports most of
the communication methods associated with PCs.
Joe D.
-----------[000247][next][prev][last][first]---------------------------------------------------- Date: 21 Nov 92 17:35:49 GMT From: lars@spectrum.CMC.COM (Lars Poulsen) To: comp.protocols.tcp-ip Subject: Re: What is "RMON" ? Please explain .
Article <gdox.722256753@informatik.tu-chemnitz.de>, by gdox@informatik.tu-chemnitz.de (Guntram Dox): >> I read the term "RMON" in a marketing paper from cabletron. >> Somebody told me, it should be something new on top of SNMP . Programming >> interface , or so. In article <1992Nov20.231216.21904@unislc.uucp> mcs@unislc.uucp (Michael Sontum) writes: >My knowledge is also sketchy but I recall that it is something like providing >almost a sniffer type capability to snmp. The RMON (Remote MONitoring) MIB (Management Information Base) is a programming specification for how a "sniffer"-like network monitor can be remotely managed using a modular extension to the SNMP protocol. Having defined RMON does not magically confer such a monitoring capability to all SNMP manged network components. Rather, the spec is a recognition by the IETF (Internet Engineering Task Force) that several vendors wre implementing such monitoring stations (the first widely deployed one was the "LANtern") and it would be helpful if they had a common interface. RMON boxes (i.e. boxes that do nothing but RMON) are available from several sources, including some free MS-DOS/PC-based software. RMON features are also becoming available on the management processor of some "smart HUBs" (i.e. ethernet repeaters with a microprocessor on the side for collecting statistics) and on some bridges. What is harder to find, is an affordable management station that will display something useful without going through contortions. There is a lot of value in good user interfaces for massive amounts of data - just look at the price of the Sniffer and its cousins. -- / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM CMC Network Products / Rockwell Int'l Telephone: +1-805-968-4262 Santa Barbara, CA 93117-3083 TeleFAX: +1-805-968-8256
-----------[000248][next][prev][last][first]---------------------------------------------------- Date: Sat, 21 Nov 1992 18:16:45 GMT From: rick@nsscmail.att.com (Rick Calder) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: MS-Kermit 3.12 + TCP + PKTMUX-12 ???
Has anyone gotten mskermit 3.12 to work with pktmux 12 when other TCP software is also active ?? When I run kermit via TCP as the 1st pktmux user, there is no problem. If something else has the 1st pktdrv, like PCTCP ethdrv, then the kermit session over TCP will lockup on the UNIX host side. Kermit is still active, the UNIX side still has its shell running, but nothing can be entered to UNIX via kermit. Kermit does still respond, as I can do a normal hangup. setup that works : setup that doesn't work : autoexec.bat : autoexec.bat : pktmux pktmux pktdrv pktdrv pktdrv pktdrv run kermit via tcp ethdrv run kermit via tcp Thanks in advance, Rick Calder [att!]rick!rick rick@rick.att.com attmail!rcalder -- Rick Calder, NCR Systems Support Center - New Jersey [att!]rick!rick rick@rick.att.com attmail!rcalder
-----------[000249][next][prev][last][first]---------------------------------------------------- Date: Sat, 21 Nov 1992 18:27:04 GMT From: cs000hf@selway.umt.edu (Hong Fan) To: comp.protocols.tcp-ip Subject: how to setsockopt to reuse local address
Hi, everyone:
Does anyone know how to use 'setsockopt' to reuse the local address on the
client site? I want to setup two socket connections as the following
associations.
{ tcp, server, 1500, client, 1000 }
{ tcp, server, 1501, client, 1000 }
One way I tried is setsockopt(sock,SO_SOCK, SO_REUSEADDR,(char *)&on,sizeof(on))
on the client site after the creation of sock. but it still gave me another
port number. Do I need to setsockopt on the server site?
If you know how to solve this problem, please mail me at cs000hf@selway.umt.edu
I appreciate your time and help.
sincerely
hong fan
-----------[000250][next][prev][last][first]---------------------------------------------------- Date: Sat, 21 Nov 1992 20:02:24 GMT From: scoggin@snow-white.ee.udel.edu (John K Scoggin) To: comp.protocols.tcp-ip Subject: Re: What is "RMON" ? Please explain .
In article <1992Nov20.231216.21904@unislc.uucp> mcs@unislc.uucp (Michael Sontum) writes: >From article <gdox.722256753@informatik.tu-chemnitz.de>, by gdox@informatik.tu-chemnitz.de (Guntram Dox): >> >> Hi, >> >> I read the term "RMON" in a marketing paper from cabletron. >> >> Somebody told me, it should be something new on top of SNMP . Programming >> interface , or so. >> >> Could somebody explain it in more detail ? >> Please, email to me, too. My access to this news group will be a little bit >> difficult in the next weeks. >> Or any pointers to other information would be great. >> > >My knowledge is also sketchy but I recall that it is something like providing >almost a sniffer type capability to snmp. > >You might try comp.protocols.snmp > >I looked through Marshall T. Rose "The Simple Book" from Prentice Hall and >the index was down right annoying. I did not see any reference to it. > >The only other thing is the gurus have an electronic magazine you can >get for free by emailing to >To: st_subscriptions@simple_times.org >Subject: help >Add me to the mailing list. > >There is also an snmp discussion group: send a note to >snmp_request@uu.psi.com >and asked to be added to the snmp@uu.psi.com list > >Also look at the rfc's. > > Mike Sontum > >"SNMP:That Dog'll Hunt" -Dr.Jeffrey D. Case > > Current Internet Draft documents concerning RMON may be obtained as follows: System: ftp.nisc.sri.com Directory: internet-drafts Files: draft-ietf-rmon-mib-01.txt draft-ietf-rmon-trap-00.txt For some reason, rollout and standardization seem to going very slowly. This has not stopped a number of manufacturers (Hewlett-Packard, Novell, and TTC come to mind) from introducing "RMON-compliant" monitors, even though there is NO standard yet! Of course, there always comes a time when you have to stop studying and start implementing - fish or cut bait... I am planning on buying 25 or 30 RMON segment monitors this spring for our network. - John ------------------------------------------------------------------------- John K. Scoggin, Jr. Email: scoggin@udel.edu Supervisor, Network Operations scoggin@delmarva.com Delmarva Power & Light Co. Voice: 302-451-5200 P.O. Box 6066 Fax: 302-451-5321 Newark, DE 19714-6066 ------------------------------------------------------------------------- Your milage may vary. Void where prohibited by law (or common sense).
-----------[000251][next][prev][last][first]---------------------------------------------------- Date: Sat, 21 Nov 1992 22:09:22 GMT From: dlucy@sandr.COM (Doug Lucy) To: biz.sco.general,comp.sys.mac.hardware,comp.sys.mac.misc,comp.sys.mac.system,comp.protocols.appletalk,comp.protocols.tcp-ip Subject: Macintosh/Localtalk to SCO/Ethernet
I've got to set up a Macintosh to connect to our net and I need some help pointing me to the right hardware and software. What we've got now is a small network (8 users) on PC's running DOS, Desqview/X, and FTP's PC/TCP all connected to a SCO Unix 3.2.4 (actually OpenDesktop 2.0) running SCO TCP/IP and NFS and X. We need to add a Macintosh to this network. The Macintosh needs to run X sessions and some kind of NFS. What kind of hardware does a Macintosh (let's say a new IIvx) need to connect to the TCP/IP Ether? What kinds of cards are available? What's the MOST COMPATIBLE? More importantly, what kinds os software exist for running TCP/IP, NFS, telnet, and X windows server under System 6 and/or 7? Does the Macintosh ethernet hardware suffer from the same problems as the IBM PC (i.e. you buy a piece of software for your SPECIFIC ethernet card)? My first need is to do all this via Ethernet. However, I want to eventaully also test the possibility of doing a telnet across AppleTalk (or LocalTallk, whatever) to some sort of LocalTalk/Ethernet bridge/gateway. For now: +-----+ | | | | Mac | Ether | | +---------+ +-----+ | | | +-----+ | | | | | PC | Ether | | +---------+ +-----+ | | | +-----+ | | | | | SCO | Ether | | +---------+ +-----+ | Later: +-----+ | | +--------+ | Mac | LocalTalk | | Ether | | +-------------+ Bridge +--------+ +-----+ | | | +--------+ | | | +-----+ | | | | | PC | Ether | | +---------+ +-----+ | | | +-----+ | | | | | SCO | Ether | | +---------+ +-----+ | Any and all help is greatly appreciated. -- | Doug Lucy | Xenus(tm) | | VP Technical Services | Total Security Automation for the | | S&R Software, Inc | protection of Classified, Proprietary, and | | dlucy@sandr.com | Sensitive information 804.320.4057 |
-----------[000252][next][prev][last][first]---------------------------------------------------- Date: Sun, 22 Nov 1992 01:21:15 GMT From: Richard.Kooijman@dnpap.et.tudelft.nl (Richard Kooijman) To: comp.protocols.tcp-ip Subject: Re: What is "RMON" ? Please explain .
scoggin@snow-white.ee.udel.edu (John K Scoggin) writes: > System: ftp.nisc.sri.com > Directory: internet-drafts > Files: draft-ietf-rmon-mib-01.txt > draft-ietf-rmon-trap-00.txt >For some reason, rollout and standardization seem to going very slowly. >This has not stopped a number of manufacturers (Hewlett-Packard, Novell, and >TTC come to mind) from introducing "RMON-compliant" monitors, even though >there is NO standard yet! RFC 1271 is the official name for the Ethernet RMON MIB. >Of course, there always comes a time when you have to stop studying and >start implementing - fish or cut bait... I am planning on buying 25 or 30 >RMON segment monitors this spring for our network. May I state here that our group has a freely available RMON monitor for OS/2 machines? You only need a PC with enough RAM, OS/2, an Ethernet card and our software. Richard.
-----------[000253][next][prev][last][first]---------------------------------------------------- Date: Sun, 22 Nov 1992 07:03:53 GMT From: cyberchrist@wam.umd.edu(X) To: comp.protocols.tcp-ip Subject: etherfind-type program for the Mac
I'm currently working on a SUN SPARC, running the program etherfind to debug a local network, and need to have the same capabilities on a mac. Is there anything out there? please mail me bluefish@wam.umd.edu
-----------[000254][next][prev][last][first]---------------------------------------------------- Date: 22 Nov 92 16:50:49 GMT From: jessea@vpmeu015.me.vp.com (Jesse W. Asher) To: comp.protocols.tcp-ip Subject: Checking for valid ip address (in ascii form).
Does anyone have any suggestions on how to check for a valid IP address
that is in ascii from (not in network byte order)? What I'm doing is
reading in a string that should be made up of a dot notation IP address
and I want to validate it. Unfortunately, inet_addr takes a whole lot
of numbers as valid - even if it isn't in dot notation. It will take
"10000" as a valid ip address, for example. It may be, but it really
isn't in my case because I want to enforce dot notation. Is there a
function I'm not aware of that will do this level of checking? Will I
just have to do it myself?
--
Jesse W. Asher (901)762-6000
Varco-Pruden Buildings
6000 Poplar Ave., Suite 400, Memphis, TN 38119
Internet: jessea@vpbuild.vp.com UUCP: vpbuild!jessea
-----------[000255][next][prev][last][first]---------------------------------------------------- Date: Sun, 22 Nov 1992 17:18:10 GMT From: davecb@nexus.yorku.ca (David Collier-Brown) To: comp.protocols.tcp-ip Subject: Re: Is the Balkanization of the InterNet inevitable?
In article <141672@lll-winken.LLNL.GOV>, casey@gauss.llnl.gov (Casey Leedom) writes: | Are network security firewalls between organizations and the InterNet | going to be the norm in the future? [...] | If the Balkanization of the InterNet is inevitable, I feel it will be a | great loss. It will be an acknowledgement that irresponsible criminal | hackers have won from us our freedom of open inter-operation. What a | sad thought. Are there no other realistic options for providing security? | Is it impossible to conceive of effective authentication methods? smb@ulysses.att.com (Steven Bellovin) writes: |For the most part, authentication isn't the issue. Well, the cracker density is the real consideration (:-)) We're **very fortunate** in the Internet: commercial firms using X.25 services like the Canadian ``datapac'' find that instead of gaining security (a vendor promise), they get a very large number of failed connection attempts. These attempts stem from hobbyist crackers working their way through a universally-acessable, low cost, **receiver pays** service that can be dialed into from almost every major city in the country, with a dense set of ``phone numbers'' each of which connects to a known computer. Of course, most sites using this service don't pay attention to the failures. Occasionally they discover their monthly bill has leaped up and that most of the calls are from Brazil, where the traceback information is unavailable. They get little help from the service provider at this point: obviously its the customer's fault for having bad security on their side of the PAD, and they can pay the bill, please, forthwith! Balkanization? Yes, to a degree, as we strive to learn from our mistakes. Of course, if we fail to learn from our governmental colleagues' mistakes, we deserve to be balkanized (:-)) --dave -- David Collier-Brown, | davecb@CCS.YorkU.CA | lethe!dave 72 Abitibi Ave., | Willowdale, Ontario, | York Postmaster and CANADA. 416-223-8968 | occasional email consultant.
-----------[000256][next][prev][last][first]---------------------------------------------------- Date: Sun, 22 Nov 1992 19:21:30 GMT From: root@mjbtn.jobsoft.com (Mark J. Bailey [ADMIN]) To: comp.unix.ultrix,comp.unix.bsd,comp.protocols.tcp-ip,comp.sys.dec Subject: SL/IP and routing under Ultrix 4.2 on VaxStation 3100
Hello,
We are trying to figure out a problem and maybe some of you can help us.
what we are trying to do is use SL/IP on a VaxStation 3100 running Ultrix
4.2 to connect a 286-AT running an amateur radio tcp/ip software package
called (KA9Q). Getting the link up is no problem. The 286-AT machine is
then linked on the radio interface (ax0) to a wireless TCP/IP network around
our region on the amateur radio bands. The VaxStation is called 'turing'
and its IP address is 161.45.1.14. It is on a LAN of other Ultrix 4.2
workstations connected via thinnet ethernet. There are no subnets present.
The entire ethernet is one network. The 286-AT is called 'w4efq' and has
an IP address of '161.45.63.4'. The wireless network is '44.34'. It is
not so much involved with the problem we are currently trying to figure out
so I will not really explain it further.
As I mentioned, the slip link is working fine between w4efq (286-at) and
turing (vaxtstation). From either end, you can telnet the other. Turing
is the SLAVE and w4efq is the MASTER in this arrangement (ie, w4efq logs
into turing and runs '/usr/new/slattach' as its login shell). W4efq has
all '44.34' addresses going out interface ax0 (radio) and all '161.45'
addresses going down sli0 (slip link to turing). Turing's route table
shows w4efq. If you run ifconfig (no args) it shows ln0 (the ethernet
with dynamic routing, and so on) and sl0 (slip to w4efq) as being POINT-TO-
POINT. We have the /etc/sliphosts file setup fine as best we can tell.
What our problem is, is that we cannot seem to get other workstations
on the ethernet to be able to access w4efq via the slip interface on turing
*UNLESS* we specifically add a route to the workstation in particular
that says
route add 161.45.63.4 161.45.1.14 1
ie, w4efq is via gateway turing. Then it works great!?!? w4efq has no
problem replying to say, 161.45.1.1, and 161.45.1.1 will reach w4efq as long as we manually add the route above. what we want it to somehow have turing
be "listening" for w4efq's address and say "ah, i know what to do with
this one" and send it up the sl/ip line. We don't want to have to go to
each and every workstation and add routes by hand. likewise, it seems to
me that one should not have to update every node in a network if you use
sl/ip to "bridge" another network in (as in my case); attaching it to just
one node in the main network (in my case, turing). Maybe I am wrong. :-)
I know I am confused! :-)
we played around with ARP on turing (no luck so far), and some other stuff.
So, bascially can what I have described be done the way I want it to? If
not, why? If so, how (from the beginning if necessary! :-)) ????
Ultimately, we would like any node in our 161.45 network to be able to
telnet 161.45.63.4 (w4efq) and get a prompt. Conversely, from w4efq,
we would like to telnet any of the other 161.45 nodes and get to them as
well. It is almost like some sort of subnet must be established on
turing, but I am really not sure how it would be done. Turing somehow
has to be listening and when it hears a request for w4efq, do something
about it (send it up the sl/ip).
Well, that is roughly what we are confronted with. Any help whatsoever
would be MOST appreciated!!! We have been trying to figure this for a week
or so and haven't gotten anywhere.
Thanks in advance!
Mark
P.S. email replies if you like (would), this really doesn't need to waste
anymore net bandwidth.
--
Mark J. Bailey, N4XHX _______/====X11====\_______
USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 | JobSoft |
VOICE: +1 615 893 0098 | Design & Development Co.|
UUCP: ...!uunet!mjbtn!mjb, ...!raider!mjbtn!mjb | Murfreesboro, TN USA |
DOMAIN: mjb@mjbtn.JOBSOFT.COM CIS: 76314,160 ---------------------------
<KA9Q-UNIX-USERS Mailing List-Subscribe: ka9q-unix-requests@mjbtn.jobsoft.com>
-----------[000257][next][prev][last][first]---------------------------------------------------- Date: Sun, 22 Nov 92 21:45:57 GMT From: rmaszkow@nyx.cs.du.edu (Rafal Maszkowski) To: comp.protocols.tcp-ip Subject: how to restart broken file transmission in ftp?
How can restart file transfer when I lost connection and I have, say, 20 MB transmitted and 10 still not? Rafal
-----------[000258][next][prev][last][first]---------------------------------------------------- Date: Sun, 22 Nov 1992 22:46:43 GMT From: mike@gordian.com (Michael A. Thomas) To: comp.protocols.tcp-ip Subject: Re: how to restart broken file transmission in ftp?
In article <1992Nov22.214557.26023@mnemosyne.cs.du.edu>, rmaszkow@nyx.cs.du.edu (Rafal Maszkowski) writes: > > How can restart file transfer when I lost connection and I have, say, 20 MB > transmitted and 10 still not? > > Rafal % ftp blah % !! ? -- Michael Thomas (mike@gordian.com) "I don't think Bambi Eyes will get you that flame thrower..." -- Hobbes to Calvin USnail: 20361 Irvine Ave Santa Ana Heights, Ca, 92707-5637 PaBell: (714) 850-0205 (714) 850-0533 (fax)
-----------[000259][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Nov 1992 00:17:29 GMT From: sommerfeld@apollo.hp.com (Bill Sommerfeld) To: comp.protocols.tcp-ip Subject: Re: how to restart broken file transmission in ftp?
In article <1992Nov22.214557.26023@mnemosyne.cs.du.edu> rmaszkow@nyx.cs.du.edu (Rafal Maszkowski) writes: How can restart file transfer when I lost connection and I have, say, 20 MB transmitted and 10 still not? The answer to this is specific to your FTP implementation. Recent versions of the BSD ftp and ftpd support a restart option, which can be accessed using the "restart" and "reget" commands to the FTP client; if your FTP client supports these commands, and the server does as well, you're in business. This code comes from Berkeley, and is in at least 386BSD and HPUX 8.07; I'm not sure when it was introduced. Check your vendor and/or on-line documentation; if the support isn't available, you may also be able to pick up the sources to the berkeley FTP by anonymous FTP and port and build them yourself.. - Bill
-----------[000260][next][prev][last][first]---------------------------------------------------- Date: 23 Nov 92 09:05:30 MST From: leonard@telcom.arizona.edu (Aaron Leonard) To: comp.protocols.tcp-ip Subject: Re: Telnet firewall help?
In article <1992Nov23.130546.7563@atlastele.com>, brians@atlastele.com (Brian Sheets) writes: | Well here I sit with this new neato kean network stuff but, do to the nature | of our company I cannot hook it up until I can assure that nobody will be | able to telnet or make other unauthorized entries into our system. | | So other that turning off telnetd does anyone have any suggestions?? Well there's a couple of ways of doing what you want to do. If your gateway to the Internet is a router that can handle per-port filtering (e.g. a cisco), then you can disallow packets coming into TCP port 23 (TELNET) or 513 (rlogin) (you might want to filter out 514 [rsh], 21 [FTP] and who knows what.) If you don't have that capability, you can put the filtering burden on all your hosts. Get a TCP/UDP master server that's capable of disallowing connects on a per-IP-address basis, such as TGV's MultiNet (VMS only) or the TCP_WRAPPER program on cert.sei.cmu.edu in pub/network_tools/tcp_wrapper. Aaron Leonard (AL104), <Leonard@Arizona.EDU> University of Arizona Network Operations, Tucson AZ 85721
-----------[000261][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Nov 1992 05:34:00 +0000 From: rmt@cix.compulink.co.uk (Richard Thomas) To: comp.protocols.tcp-ip Subject: No subject
Apologies folks: this is just a test transmission
-----------[000262][next][prev][last][first]---------------------------------------------------- Date: 23 Nov 92 05:36:49 GMT From: casey@gauss.llnl.gov (Casey Leedom) To: comp.protocols.tcp-ip Subject: Re: Is the Balkanization of the InterNet inevitable?
Well, I've received several replies regarding my unhappiness with
network firewalls. They fall into the following categories:
1. I'd rather protect one machine than the ten-thousand behind it.
2. So what are the [lauded] services are you missing?
3. Don't worry. Firewalls aren't as bad in general as the one you're
living behind.
The third item answers the second to some extent. The firewall I have
to deal with only supports outgoing telnet and ftp sessions via a set of
utilities apparently fronted by Sun: itelnet and iftp. These work by
routing their outgoing connections through proxy servers on a machine
which is allowed to access the outside world and is also exposed to it.
The only incoming connection arrangement is via a separate machine which
only allows telnet connections. Mail is MX'ed up the wazoo. I'm not
sure how News is handled. (I don't know because I don't use the systems
behind the firewall. I maintain my home on GAUSS.LLNL.GOV and do all my
outside communication from here because I can avoid the firewall and it's
hassles.) One of my biggest gripes is that we only have itelnet and iftp
clients for Suns. This leads to seemingly endless multi-hop store and
forward ftp acts guaranteed to try your patience.
I suppose I should subscribe to the firewalls mailing list suggested by
Robert K. Stodola in order to determine just how bad the situation is in
general. So I'll study up on what the ``state-of-the-art'' is and return
to flame later ... :-)
Casey
-----------[000263][next][prev][last][first]---------------------------------------------------- Date: 23 Nov 1992 05:40:48 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: ARP & Duplicate IP addresses
In article <1992Nov20.202906.9279@jupiter.sun.csd.unb.ca> dedgar@mta.ca writes:
>- Is it a good idea to ARP your own IP address on startup? A returning
> ARP would tell you that the address was a duplicate.
> - if so is it a good idea to automatically shut your interface down
> if a duplicate IP address is detected on startup? Are there any
> situations where false returns might be reported?
There are two situations where you're likely to get a response. One is
when two machines are configured with the same IP address. The other is
when you're configured for the wrong subnet and there's a router that
implements proxy ARP. Either way, there's a serious configuration problem
and the user should be informed.
> - What about detecting one after startup? Should you advise the user
> and gently start terminating connections? Could be real annoying.
I think you should advise the user, but not terminate connections.
However, if packets reach the other host, it may terminate your
connections.
>- If you receive an incoming ARP request and the sender IP address matches
> yours should you reply to it? Doing so would advice the other node that
> a duplicate exists (assuming it checks) but also could hopelessly confuse
> a host that doesn't. All of the implementations that I have tested do not
> reply - but I have not tried all that many.
Either you or the other host is hopelessly confused already, so it's not
clear that replying would make things too much worse.
>- What are the consequenses of staying up with a duplicate IP address?
Some packets that are intended for you will be sent to the other host, and
vice versa. Confusion will reign.
--
Barry Margolin
System Manager, Thinking Machines Corp.
barmar@think.com {uunet,harvard}!think!barmar
-----------[000264][next][prev][last][first]---------------------------------------------------- Date: 23 Nov 1992 09:22:55 GMT From: dclunie@pax.tpa.com.au (David Clunie) To: alt.sys.sun,comp.sys.sun.misc,comp.sys.sun.admin,comp.sys.sun.wanted,comp.unix.solaris,comp.protocols.ppp,comp.protocols.tcp-ip Subject: Packet filtering for Sun needed
I have a server based on a sparc running 4.1.2 connected to the outside world via a slip connection. I have a need to be selective about the packets that come in and go out both in terms of what they are, where they are from and who they are to. I don't have anything like a cisco router to put in between unfortunately, I want the sun to do it itself. I am aware of inetd replacements like log-tcp but that doesn't help with outgoing connections. Has anyone seen or hacked up anything that will do this ? Seems like a common enough need, but I don't know how to go about doing it myself. david
-----------[000265][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Nov 1992 13:05:46 GMT From: brians@atlastele.com (Brian Sheets) To: comp.protocols.tcp-ip Subject: Telnet firewall help?
Well here I sit with this new neato kean network stuff but, do to the nature of our company I cannot hook it up until I can assure that nobody will be able to telnet or make other unauthorized entries into our system. So other that turning off telnetd does anyone have any suggestions?? brians -- Brian Sheets _ /| "TRUCK?! What truck?" 153 N. Hayden Bay Dr. \`o_O' Portland, Or 97217 ( ) -Raiders of the Lost Ark brians@atlastele.com U
-----------[000266][next][prev][last][first]---------------------------------------------------- Date: 23 Nov 1992 16:53:10 GMT From: emv@msen.com (Edward Vielmetti) To: alt.sys.sun,comp.sys.sun.misc,comp.sys.sun.admin,comp.sys.sun.wanted,comp.unix.solaris,comp.protocols.ppp,comp.protocols.tcp-ip Subject: Re: Packet filtering for Sun needed
David Clunie (dclunie@pax.tpa.com.au) wrote:
:
: I have a need to be selective about the packets that come in and go out
: both in terms of what they are, where they are from and who they are to.
: I don't have anything like a cisco router to put in between unfortunately,
: I want the sun to do it itself. I am aware of inetd replacements like
: log-tcp but that doesn't help with outgoing connections.
The Morning Star PPP software (which also speaks SLIP) has a complete
set of packet filtering tools which would let you selectively block
traffic over the line based on ports. I'm quite sure that it would
meet your requirements as described.
I've attached contact information below.
Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
Msen Inc., 628 Brooks, Ann Arbor MI 48103 +1 313 998 GLOB
Symbol: morningstar
Name: Morning Star Technologies, Inc.
1760 Zollinger Road
Columbus, OH 43221
Voice: +1 614 451 1883
Sales: +1 800 558 7827
FAX: +1 614 459 5054
Email: sales@morningstar.com
-----------[000267][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Nov 92 18:14:14 GMT From: reece@eco.twg.com (Reece R. Pollack) To: comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc,vmsnet.networks.tcp-ip.wintcp Subject: Re: WIN-TCP/DECwindows device conflict. Whats's up with that?????
In article <1992Nov20.194054.1499@alw.nih.gov>, ramon@helix.nih.gov (Ramon J. Hontanon) writes: |>In upgrading our trusty VAXstationII GPX from VMS 5.0 to VMS 5.4 we |>found out that our version of The Wollongong Groups's TCP/IP allocates |>three devices (GAA0: GAA1: GAA2:) that will need to be used by |>DECwindows. |>The result: DECwindows refuses to install. The DEC people found this |>out, and it seems true, 'cause DECwindows starts fine if I don't run |>WIN/TCP. I guess my question is: |> |>What version of WIN/TCP do I need to go to in order to fix this bug? |> |>Will we be required to buy the product again, or do we just simply |>upgrade? |> |>The e-mail address of The Wollongong Group would also be appreciated. This is being investigated off-line, but I thought I'd post an initial response for everyone else. To my knowlege, we do not allocate GAA devices. We're running VMS versions ranging from V5.1 through V5.5 with DECwindows or Motif and there should be no conflicts. Here are a couple of email addresses for customer use: support@twg.com - Support requests sales@twg.com - Sales and product info requests -- Reece R. Pollack Senior Software Engineer The Wollongong Group, Inc.
-----------[000268][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Nov 1992 19:29:37 GMT From: huntting@advtech.uswest.com (Brad Huntting) To: comp.dcom.lans.ethernet,comp.dcom.isdn,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: remote tcp/ip LAN access ideas
In article <722011367snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes: >In article <1992Nov16.191510.474@nynexst.com> sgriffee@nynexst.com writes: > Watch out. Telecommuting may be just around the bend for your > company. Don't let it catch you asleep at the wheel. >Holy shit, Steve, is NYNEX just figuring this out?!?!??? >Sorry for the gratuitious flamage, but maybe that's what the baby >bells need? Yup. Until just a few months ago my supervisor (at U S WEST) was unable to fathom telecomuting. He used a Mac, and might have been able to login to a unix machine if he had a system administrator on the phone with him. When I brought up the subject of working at home with him, I got a vacant stare as if I had just asked him "I'm going to die tomarrow and was wondering if I could keep working from beyond the grave". I'm fortunate now to have a new supervisor who understands that I dont have to be in the building to work. (Of course she lives several miles up Boulder canyon and is probably snowed in herself today). There is hope though... At least there is a concensis (now that ATT is out of the picture) that UUCP is not the ultimate answer to the worlds networking needs. :-) brad
-----------[000269][next][prev][last][first]---------------------------------------------------- Date: 23 Nov 92 19:59:56 GMT From: feoh@hal.gnu.ai.mit.edu (Chris Patti) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: RAW SPEED numbers for various TCP-IP implementations
Hello. Does anyone have any raw numbers on how fast various TCP-IP implementations perform (memory to memory, not disk to disk, etc) and various platforms? Any help in this matter would be appreciated.. P.S. How would you rate 500KB/sec? -Chris Patti feoh@gnu.ai.mit.edu chrisp@ncm.interlan.com
-----------[000270][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Nov 1992 20:12:08 GMT From: rsivaram@vela.acs.oakland.edu (Siva) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs,comp.protocols.tcp-ip Subject: Dos Equivalent for gethostbyname()...
Dear Netters, I have written some building blocks for developing an NFS client. They are on UNIX system. I want to port them to DOS preferably using Turbo C because my ultimate objective is to build the client on DOS. Is there any library function equivalent to gethostbyname() available on DOS ? Any pointers will be greatly appreciated. Thanks -Siva --
-----------[000271][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Nov 92 21:51:57 GMT From: terry@cs.weber.edu (A Wizard of Earth C) To: comp.unix.ultrix,comp.unix.bsd,comp.protocols.tcp-ip,comp.sys.dec Subject: Re: SL/IP and routing under Ultrix 4.2 on VaxStation 3100
In article <1992Nov22.192130.1720@mjbtn.jobsoft.com> root@mjbtn.jobsoft.com (Mark J. Bailey [ADMIN]) writes:
>Hello,
>
>We are trying to figure out a problem and maybe some of you can help us.
>
>what we are trying to do is use SL/IP on a VaxStation 3100 running Ultrix
>4.2 to connect a 286-AT running an amateur radio tcp/ip software package
>called (KA9Q). Getting the link up is no problem. The 286-AT machine is
>then linked on the radio interface (ax0) to a wireless TCP/IP network around
>our region on the amateur radio bands. The VaxStation is called 'turing'
>and its IP address is 161.45.1.14. It is on a LAN of other Ultrix 4.2
>workstations connected via thinnet ethernet. There are no subnets present.
>The entire ethernet is one network. The 286-AT is called 'w4efq' and has
>an IP address of '161.45.63.4'.
[ ... ]
>What our problem is, is that we cannot seem to get other workstations
>on the ethernet to be able to access w4efq via the slip interface on turing
>*UNLESS* we specifically add a route to the workstation in particular
>that says
>route add 161.45.63.4 161.45.1.14 1
>ie, w4efq is via gateway turing. Then it works great!?!? w4efq has no
>problem replying to say, 161.45.1.1, and 161.45.1.1 will reach w4efq as long as we manually add the route above. what we want it to somehow have turing
>be "listening" for w4efq's address and say "ah, i know what to do with
>this one" and send it up the sl/ip line. We don't want to have to go to
>each and every workstation and add routes by hand. likewise, it seems to
>me that one should not have to update every node in a network if you use
>sl/ip to "bridge" another network in (as in my case); attaching it to just
>one node in the main network (in my case, turing). Maybe I am wrong. :-)
>I know I am confused! :-)
1) a) "OPTION GATEWAY" in your 3100's config file (don't know
if Ultrix supports this) and rebuild the kernel to allow
routing between subnets.
-OR-
b) Get (and run) gated (from gatekeeper.dec.com, etc.).
2) a) Subnet your wires to give a netmask of 255.255.255.0 (or
anything else you choose to get 161.45.63.x and
161.45.1.x off the same wire.
3) a) There is a default host doing the routing for 161.45.x.x;
tell IT the route to 161.45.63.x is through 161.45.1.14.
This will make the other hosts send packets to the
"unknown" 63 wire to the default hosts, which will
forward them to 161.45.1.14, which is your gateway to
the 161.45.63.x subnet.
4) a) Default the routing for the NET 161.45.63.x to the slip
link; this will avoid a routing loop which you might
otherwise have if someone tries to talk to 161.45.63.9
(or some other nonexistant host) on the 63 net; you
don't want these packets going back to your default router
for the 161.45.x.x wire. Alternately, self designate as
the 161.45.63.x router and specify a single host entry
for the SL/IP.
Topologically:
161.45.x.x ----+------------------------+-------------
domain | |
| |
default 161.45.1.x
domain subnet (OPTIONAL)
router router
|
|
161.45.1.x -----+-----------------------+-----
subnet |
|
161.45.1.14 host /
161.45.63.x gateway
|
|
161.45.63.x ----+---------------+-----------------
gated |
subnet 161.45.63.4
(SINGLE ADDR) SL/IP host
This basically works for us (with gated) using a MVAX II w/Ultrix.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------
-----------[000272][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Nov 1992 00:13:51 GMT From: karl@empirical.com (Karl Auerbach) To: comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip Subject: Re: Domain Name Service Deficiencies
In article <4285@bcstec.ca.boeing.com> tld5032@bcstec.ca.boeing.com (Terry Davis) writes: >From: tld5032@bcstec.ca.boeing.com (Terry Davis) >Subject: Domain Name Service Deficiencies > 11) In addition to DNS, the resolver routines "gethostbyname" > and "gethostbyaddr" need some extensive enhancements for life in > the network environment. Some form of short lived caching needs > to be provided, probably a most recent "10" lookups would be more > than adequate for anything except servers. My PC-based DNS resolver implements a local name cache which it uses before ever hitting the disk or the network. Seems to work OK for my PC applications. --karl--
-----------[000273][next][prev][last][first]---------------------------------------------------- Date: 24 Nov 92 03:21:04 GMT From: davis@unidata.ucar.edu (Glenn P. Davis) To: comp.protocols.tcp-ip Subject: Network Time Protocol on on SunOS 5.0 ?
Yo. I have been trying to bring up xntp3 on SunOS 5.0 aka Solaris 2.0. The main problem is the server, xntpd. I have been moderately successful using /usr/ucb/cc and -DNOKMEM. At this point it runs but doesn't hear other guys. Sigh. Has anyone out there gotten any form of Network Time Protocol service running on SunOS 5.0? -glenn
-----------[000274][next][prev][last][first]---------------------------------------------------- Date: 24 Nov 92 03:56:08 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: RAW SPEED numbers for various TCP-IP implementations
In article <1992Nov23.195956.10971@mintaka.lcs.mit.edu>, feoh@hal.gnu.ai.mit.edu (Chris Patti) writes:
>
> Hello.
>
> Does anyone have any raw numbers on how fast various TCP-IP implementations
> perform (memory to memory, not disk to disk, etc) and various platforms?
>
> Any help in this matter would be appreciated..
>
> P.S. How would you rate 500KB/sec?
That depends on the medium.
Over a modem 500KByte/sec would be amazing.
On an idle FDDI ring, it would be ridiculous.
Vernon Schryver, vjs@sgi.com
P.S. Over ethernet 500KB/s would be poor for a modern workstation, but
common for a PC. As measured by `ttcp`. Ftp ttcp source from
brl.mil or sgi.com
-----------[000275][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Nov 1992 04:42:07 GMT From: ben@datacomm.ucc.okstate.edu (Ben James) To: comp.sys.novell,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: looking for Daniel D. Lanciani
I need to talk to Daniel Lanciani about his odipkt.com driver and the copyright on it. I have modifyed it and renamed it but have kept his copyright notices intact. I would also like to know if my modifications are covered under his copyright or if I need to add one of my own. This is all new to me and any advice would be helpful. Ben James ben@datacomm.ucc.okstate.edu
-----------[000276][next][prev][last][first]---------------------------------------------------- Date: 24 Nov 1992 17:10 MST From: jms@carat.arizona.edu (A virtually vegetal non-entity) To: comp.protocols.tcp-ip Subject: Re: Looking for multicast mailing lists
In article <142229@lll-winken.LLNL.GOV>, casey@gauss.llnl.gov (Casey Leedom) writes...
>
> I'm looking for mailing lists dealing with multicast topics.
Multicast@Arizona.EDU
The multicast mailing list has been set up for discussion of multicast
and broadcast issues in an OSI network environment. In the current
CCITT recommendations and ISO standards, there is little or no mention
of multicast capability. However, there is work in this area in
other environments.
The goal of this mailing list is to facilitate discussion on the
following topics:
- what can we learn from existing multicast and broadcast work in other
environments (local area networks, TCP/IP Internets, XTP, ST-II, etc.)
- what can we do to facilitate quality international standards (ISO and
CCITT, especially) for multicast data transmission
- what can we say about the issues listed below?
- application level interfaces and requirements
- management
- security
- transport level
- network level
- network/transport interworking
- connection-oriented/connection-less interworking
- LAN/WAN interworking
To subscribe to the multicast mailing list, send a message to
Multicast-Request@Arizona.EDU with your full name and preferred
electronic mail address.
Joel M Snyder, 1103 E Spring Street, Tucson, AZ, 85719
Phone: 602.882.4094 (voice) .4095 (FAX) .4093 (data)
BITNET: jms@Arizona Internet: jms@arizona.edu SPAN: 47541::telcom::jms
Yow! Are we laid back yet?
-----------[000277][next][prev][last][first]---------------------------------------------------- Date: 24 Nov 92 17:29:42 EST From: esiewick@pbs.org To: comp.protocols.tcp-ip Subject: Terminal Server Recommendations?
Hello, This is a solicitation for opinions concerning TCP/IP-capable terminal servers (It could also be a sad story about vendor vaporware). PBS is attempting to connect a large number (several thousand) sites on one data network via VSAT satellite. At the satellite-remote site (300+) level we need to connect modems to terminal servers to data servers to satellite communications equipment. All is going fine except the terminal server we've begun the project with cannot/does not perform SLIP and UUCP properly, at least not concurrently. Yes, these would seem to be very simple, common tasks expected of any such product in the marketplace. The vendor, not to be named publicly here, has rewritten their operating system several times for us. Today's offering was even worse than the last. And yes, we THOUGHT we'd provided an adequately exhaustive test of the product. So we now possess a few of these dogs. We don't need any more of them. Enough of the crying. We need sound technical opinions on terminal servers. Of particular interest are: 1: the ease with which a single line can be used to configure itself for SLIP or PPP; 2: robustness & technical accuracy of its implementation of SLIP, PPP and UUCP; 3: remote management capabilities; 4: cost-effectiveness; Suggestions for sound alternatives to terminal servers are also requested. Please respond via mail. I'll summarize and post. Thank you for any and all help. Edward Siewick Public Broadcasting Service 1320 Braddock Place Alexandria, VA 22314
-----------[000278][next][prev][last][first]---------------------------------------------------- Date: 24 Nov 92 17:34:15 EST From: esiewick@pbs.org To: comp.protocols.tcp-ip Subject: Terminal Server Recommendations?
Hello, This is a solicitation for opinions concerning TCP/IP-capable terminal servers (It could also be a sad story about vendor vaporware). PBS is attempting to connect a large number (several thousand) sites on one data network via VSAT satellite. At the satellite-remote site (300+) level we need to connect modems to terminal servers to data servers to satellite communications equipment. All is going fine except the terminal server we've begun the project with cannot/does not perform SLIP and Telnet properly, at least not concurrently. Yes, these would seem to be very simple, common tasks expected of any such product in the marketplace. The vendor, not to be named publicly here, has rewritten their operating system several times for us. Today's offering was even worse than the last. And yes, we THOUGHT we'd provided an adequately exhaustive test of the product. So we now possess a few of these dogs. We don't need any more of them. Enough of the crying. We need sound technical opinions on terminal servers. Of particular interest are: 1: the ease with which a single line can be used to configure itself for SLIP or PPP; 2: robustness & technical accuracy of its implementation of SLIP, PPP and Telnet; 3: remote management capabilities; 4: cost-effectiveness; Suggestions for sound alternatives to terminal servers are also requested. Please respond via mail. I'll summarize and post. Thank you for any and all help. Edward Siewick Public Broadcasting Service 1320 Braddock Place Alexandria, VA 22314
-----------[000279][next][prev][last][first]---------------------------------------------------- Date: 24 Nov 92 12:55:58 GMT From: avalon@coombs.anu.edu.au (Darren Reed) To: comp.protocols.tcp-ip Subject: NSFNet goes to hell..
After watching the NSFnet almost goto pieces in the last hour
or so, I'd like to know if there is any way 'outsiders' can get
info on when upgrades/maintainence is planned or even fault reports
are sent. Someone suggested "nsr" to me but that seems to be an
"in-house" list only. Are there any other offerings or are those
who use/rely on the network expected to put up with the route
between A and B changing every 5 minutes ? (Surprisingly not all
network kernels/programs can handle what goes on and this results
in interruptions for almost anything which uses TCP).
This is a sample traceroute from not long ago:
5 arc2.nsn.nasa.gov (132.160.240.1) 592 ms 576 ms 597 ms
6 ARC1.NSN.NASA.GOV (192.100.12.1) 597 ms 599 ms 599 ms
7 Palo_Alto.CA.NSS.NSF.NET (192.52.195.254) 741 ms 710 ms 721 ms
8 Palo_Alto.CA.NSS.NSF.NET (129.140.13.129) 797 ms 737 ms 722 ms
9 Salt_Lake_City.UT.NSS.NSF.NET (129.140.79.13) 710 ms 768 ms 740 ms
10 Ann_Arbor.MI.NSS.NSF.NET (129.140.81.15) 751 ms 706 ms 748 ms
11 Ann_Arbor.MI.NSS.NSF.NET (129.140.17.78) 732 ms Ann_Arbor.MI.NSS.NSF.NET (1
29.140.17.14) 707 ms Ann_Arbor.MI.NSS.NSF.NET (129.140.17.78) 726 ms
12 t3-2.cnss41.t3.nsf.net (140.222.41.3) 745 ms 761 ms 762 ms
13 t3-3.cnss40.t3.nsf.net (140.222.40.4) 798 ms 779 ms 822 ms
14 t3-2.cnss24.t3.nsf.net (140.222.24.3) 789 ms 814 ms 830 ms
15 t3-0.cnss80.t3.nsf.net (140.222.80.1) 727 ms 762 ms 737 ms
Usually its cnss8-cnss24-cnss80...%-/
darren
p.s. This isnt as rare as some people would have others belive, just
mostly seems to happen when most of the USA is asleep and the
rest of us are awake....well most of the time anyway...
-----------[000280][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Nov 1992 14:35:34 +0000 From: proyse@peeras.demon.co.uk (Phil Royse) To: comp.protocols.tcp-ip Subject: Maximum ports on a Router?
I am working on a strategy for developing a multiprorocol router network for a large client in the healthcare sector. (Protocols to be routed include IP, DECnet Ph IV and IPX (with some ISO 8473 at some future point)). The outline design looks like approx. 15 main nodes, connected in a route- diverse "cartwheel" resilient network. However, we will need at least one link from each node to come into the central node (i.e the hub of the cartwheel). We are planning to start with RIP and move to IntIS-IS at some future point). The question is - does it make sense to have one big router with 14 or 15 WAN ports at the centre, or to split the load and have two 8-port routers side-by-side, connected by an Ethernet segment? (or three 6-port routers...). We are evaluating all main routers (inc. ACC, Cisco, Wellfleet, 3Com etc.). It appears that most makes only support up to 8 ports (WAN+LAN). What are the pros & cons of each approach? Is there any alternative? Will the two-routers side-by-side be more difficult to manage? Will the routing tables cause us a problem? What is the realistic maximum number of WAN ports for a router? Does the protocol make a difference (ie 14 ports OK for IP, but not for IPX?) TIA Phil Royse -- Phil Royse Comms Consultant | member: The Peer Association TUDOR HOUSE | (OSI & GOSIP specialists) 12 Woodside Road, Purley Surrey CR8 4LN (UK) Tel: (+44) 81 645-9868
-----------[000281][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Nov 1992 14:43:02 GMT From: billy@sol.acs.unt.edu (Billy Barron - VAX/UNIX Systems Manager) To: comp.protocols.tcp-ip Subject: Re: NSFNet goes to hell..
avalon@coombs.anu.edu.au (Darren Reed) writes: >After watching the NSFnet almost goto pieces in the last hour >or so, I'd like to know if there is any way 'outsiders' can get >info on when upgrades/maintainence is planned or even fault reports >are sent. Someone suggested "nsr" to me but that seems to be an >"in-house" list only. Are there any other offerings or are those >who use/rely on the network expected to put up with the route >between A and B changing every 5 minutes ? (Surprisingly not all >network kernels/programs can handle what goes on and this results >in interruptions for almost anything which uses TCP). It's called Dynamic Routing and this is the way it is supposed to work. This is a design feature (and I don't mean bug). The NSFnet backbone load balances the traffic. The switching does not necessarily mean there has been an outage. It isn't a matter of kernels/program can handling it or not handling. IP software only receives packets with an original source address and has no idea of how the packet got there. So if your kernels/programs can tell, they are VERY, VERY, VERY broken. Traceroute does some pretty strange things to figure out the route that involves many packets being sent. There is nothing wrong with the NSFNET. It's operating as planned. If you think dynamic routing is causing you a problem, I highly suggest that you start by taking a look at IP packet definitions and realize the route taken is not part of the information being carried in the packet. Billy Barron, VAX/UNIX Systems Manager, University of North Texas billy@unt.edu, billy@untvax.bitnet, THENET: NTVAX::BILLY
-----------[000282][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Nov 1992 15:34:15 GMT From: bob1@cos.com (Bob Blackshaw) To: comp.dcom.lans.ethernet,comp.dcom.isdn,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: remote tcp/ip LAN access ideas
In <1992Nov23.192937.23672@advtech.uswest.com> huntting@advtech.uswest.com (Brad Huntting) writes: >In article <722011367snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes: >>In article <1992Nov16.191510.474@nynexst.com> sgriffee@nynexst.com writes: >> Watch out. Telecommuting may be just around the bend for your >> company. Don't let it catch you asleep at the wheel. >>Holy shit, Steve, is NYNEX just figuring this out?!?!??? >>Sorry for the gratuitious flamage, but maybe that's what the baby >>bells need? >Yup. Until just a few months ago my supervisor (at U S WEST) was >unable to fathom telecomuting. He used a Mac, and might have been able >to login to a unix machine if he had a system administrator on the >phone with him. When I brought up the subject of working at home with >him, I got a vacant stare as if I had just asked him "I'm going to die >tomarrow and was wondering if I could keep working from beyond the >grave". >I'm fortunate now to have a new supervisor who understands that I dont >have to be in the building to work. (Of course she lives several miles >up Boulder canyon and is probably snowed in herself today). >There is hope though... At least there is a concensis (now that ATT is >out of the picture) that UUCP is not the ultimate answer to the worlds >networking needs. :-) >brad Telecommuting got a big play at TRIP '92, in fact there was a delightful exchange during the Golden Splice ceremony. The moderator, Dr. Robert Metcalfe was in a video conference with some school children out in Los Angeles. One of the ISDN applications she and her schoolmates had suggested was the idea of work-at-home, i.e., telecommuting. Dr. Metcalfe asked her how she would like having her parents at home all the time. Her response was that it would be neat and would bring families closer together. The audience of sophisticated executives and media people simply burst into applause. As they say "Out of the mouths of babes..." The second day had several speakers who have already implemented telecommuting to good effect. It seems to be an idea whose time has come, at last. Bob.
-----------[000283][next][prev][last][first]---------------------------------------------------- Date: 24 Nov 92 15:38:17 GMT From: casey@gauss.llnl.gov (Casey Leedom) To: comp.protocols.tcp-ip,comp.protocols.iso,comp.protocols.misc Subject: Looking for multicast mailing lists
NOTE:
Please send all replies directly to me. I'll summarize the results
back to these groups. Please indicate if you don't want your name
or comments used in my summary.
I'm looking for mailing lists dealing with multicast topics. I'm
interested in TCP/IP in particular, but am interested in multicasting
issues in general. I know about the ISIS news group and am following
that already.
Thanks for your time and attention!
Casey
-----------[000284][next][prev][last][first]---------------------------------------------------- Date: 24 Nov 92 18:09:08 GMT From: ldh@svl.cdc.com (Lawrence D. Hare) To: comp.protocols.tcp-ip Subject: Connection comes up halfway and drives me nuts,
This one is driving me nuts.. If anyone has any idea as to what is going on I would be really happy. This is the set up. A Mac application that talks to a specific server on a variety of Unix platforms. It works fine on everything. Part of this application's function is to perform file transfers, it uses ftp. This works on ALL configurations except ONE! What happens on this one is as follows: The application is connected and happy. It wants to perform a file transfer so it establishes a connection to the FTP well-known-port using MacTCP. The connection is created and I go for an ActiveOpen. This returns mac error -23015 which, translated, means: The connection came up halfway and then failed. Why why why WHY!!!!!!!!! If I run other mac applications that use ftp protocols it works all right. Is there some negotiation going on between the TCP peers that is failing? Is there something at the UNIX end? Is there something I should tell someone? Aaaaaarrrrrgh. I am posting this to comp.sys.mac.comm, comp.unix.programmer, comp.unix.admin and comp.unix.bsd. Any and all help is greatly appreciated. Thanks -- Lawrence D. Hare Control Data - Silicon Valley Operations Consultant Voice: (408) 496 4339 - C/N [234] 4339 ldh@svl.cdc.com Mail: SVLa60 FAX: (408) 496-4106
-----------[000285][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Nov 1992 18:40:30 GMT From: stewart@daffy.cis.udel.edu (John Stewart) To: comp.protocols.tcp-ip Subject: Re: Telnet firewall help?
In article <1992Nov23.130546.7563@atlastele.com>, brians@atlastele.com (Brian Sheets) writes: > >Well here I sit with this new neato kean network stuff but, do to the nature >of our company I cannot hook it up until I can assure that nobody will be >able to telnet or make other unauthorized entries into our system. > >So other that turning off telnetd does anyone have any suggestions?? There are commercially available firewalls providing rather sophisticated mechanisms for access to various services depending on source, destination, service, time, etc. One such product, Raptor Systems' Eagle Gateway, has a mailing list at raptor@delmarva.com; subscription requests should be sent to raptor-request@delmarva.com. There are also various documents on the Eagle Gateway in particular, and network security in general, at ftp.delmarva.com (138.39.7.10) in pub/raptor. Good luck. /jws
-----------[000286][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Nov 1992 18:56:55 GMT From: peter@ferranti.com (peter da silva) To: comp.protocols.tcp-ip,comp.sys.sun.misc Subject: Network print spoolers? Parallel ports?
We have a network of Sun workstations that we want to stick a parallel
port dot matrix printer on for draft quality screen dumps. Because it's
such a high data volume, we don't want to mess with a serial printer.
Sun's parallel port is O($1000)!
Next solution is to use a standalone printer server or terminal server
with a parallel port. This would simplify administration and dependence
on some particular workstation, too. What sort of products should we be
looking at, and what sort of prices?
--
Peter da Silva / 77487-5012 USA / +1 713 274 5180
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?
-----------[000287][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Nov 1992 18:57:22 GMT From: msp@mbunix.mitre.org (Panock) To: comp.protocols.tcp-ip Subject: secure OSPF
I am interested in OSPF, in particular implementations that implement
IP security option(CIPSO and/or RIPSO). Please send email replies to
at this address
msp@mbunix.mitre.org
thanks
Marybeth Panock
MITRE Corp.
617-271-8567
-----------[000288][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Nov 1992 18:59:36 GMT From: srao@hpindda.cup.hp.com (Srinivasa Rao) To: comp.protocols.tcp-ip Subject: Standard reply string for 'PWD' command in ftp protocol
Dear netters I am writing a new ftp client. In my ftp client, I need to know the present working directory which I use it for further processing in the program. What string does the ftpd returns for the command 'PWD'? At present I assumed that all ftpd's return the following reply for the command 'PWD' <Three digit code><space>"<dirname>"<space>commentary Is above code is valid always in all implementations? I have gone through the RFC959 and I did not get any standard reply for 'PWD'. For MKD comands, the above reply seems to be standardised. Any help on above problem is greatly appreciated. Thankyou
-----------[000289][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Nov 1992 20:37:46 GMT From: madhu@cbnewsf.cb.att.com (madhu.shekhar) To: comp.protocols.tcp-ip Subject: Where are TCP/IP sources with MIB-II ?
Please help me with site info on where I could
find public domain TCP/IP source with MIB-II.
Please e'mail to
madhu@mt747.att.com
Thanks in advance
-----------[000290][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Nov 1992 20:47:45 GMT From: stewart@daffy.cis.udel.edu (John Stewart) To: comp.protocols.tcp-ip Subject: Re: ARPAnet means?
In article <rhughes.1.0@UCSD> rhughes@UCSD (Richard J. Hughes) writes: >The title says it all. What does the "ARPA" in ARPAnet stand for? Would >some kind soul please let me know. Advanced Research Projects Agency. Actually, the name comes from an agency of the Department of Defense -- the Defense Advanced Research Projects Agency. I believe its network was called ARPANET (rather than DARPANET) purely for reasons of political-correctness. /jws
-----------[000291][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Nov 1992 20:55:21 GMT From: smb@ulysses.att.com (Steven Bellovin) To: comp.protocols.tcp-ip Subject: anyone using tcpmux?
Is anyone using the tcpmux protocol? Do any vendors rely on it for their own standard applications? Reply by mail, please. --Steve Bellovin
-----------[000292][next][prev][last][first]---------------------------------------------------- Date: 24 Nov 92 21:59:04 GMT From: mckenzie@bbn.com (Alex McKenzie) To: comp.protocols.tcp-ip Subject: Re: ARPAnet means?
ARPA stands for Advanced Research Projects Agency. This is an agency
set up within the US Department of Defense after the USSR launched
Sputnik (ca 1956); its mission was to make sure the USA was not
technologically surprised again. ARPA funded a great deal of basic and
applied research in many fields, including computation. In the late 70s
or early 80s the agency was renamed DARPA (Defense Advanced Research
Projects Agency).
__
/ | /\ Alex McKenzie
/ | \/ mckenzie@bbn.com
\__/|_/\_&_/~X_ 617/873-2962
-----------[000293][next][prev][last][first]---------------------------------------------------- Date: 24 Nov 1992 22:43:16 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: ARPAnet means?
In article <rhughes.1.0@UCSD> rhughes@UCSD (Richard J. Hughes) writes:
>The title says it all. What does the "ARPA" in ARPAnet stand for? Would
>some kind soul please let me know.
Advanced Research Projects Agency, the previous name of DARPA (the D stands
for Defense -- the name was changed to emphasize that the agency is a part
of the DOD and should be stressing military applications rather than pure
research). DARPA provided most of the original funding for the original
ARPAnet.
--
Barry Margolin
System Manager, Thinking Machines Corp.
barmar@think.com {uunet,harvard}!think!barmar
-----------[000294][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Nov 1992 22:54:40 GMT From: gdo@aloft.att.com (Glenn O'Donnell) To: comp.protocols.tcp-ip Subject: How do I Monitor Sun Outgoing Packets?
When monitoring packets using etherfind, NetMetrix, etc., I can't see traffic leaving the Sun doing the monitoring. I've been told it's a bug in Sun's NIT interface. Can anybody shed light on this? Is there a patch/workaround? Thanks in advance. Glenn O'Donnell AT&T Bell Laboratories Allentown, PA
-----------[000295][next][prev][last][first]---------------------------------------------------- Date: 25 Nov 92 00:23:38 GMT From: avalon@coombs.anu.edu.au (Darren Reed) To: comp.protocols.tcp-ip Subject: Re: NSFNet goes to hell..
billy@sol.acs.unt.edu (Billy Barron - VAX/UNIX Systems Manager) writes: >avalon@coombs.anu.edu.au (Darren Reed) writes: >>After watching the NSFnet almost goto pieces in the last hour >>or so, I'd like to know if there is any way 'outsiders' can get >>info on when upgrades/maintainence is planned or even fault reports >>are sent. Someone suggested "nsr" to me but that seems to be an >>"in-house" list only. Are there any other offerings or are those >>who use/rely on the network expected to put up with the route >>between A and B changing every 5 minutes ? (Surprisingly not all >>network kernels/programs can handle what goes on and this results >>in interruptions for almost anything which uses TCP). >It's called Dynamic Routing and this is the way it is supposed to work. >This is a design feature (and I don't mean bug). The NSFnet backbone >load balances the traffic. The switching does not necessarily mean >there has been an outage. >It isn't a matter of kernels/program can handling it or not handling. >IP software only receives packets with an original source address and >has no idea of how the packet got there. So if your kernels/programs >can tell, they are VERY, VERY, VERY broken. Traceroute does some pretty >strange things to figure out the route that involves many packets being >sent. Yes, I know how/why traceroute works and how dynamic routing with IP is supposed to work, but why then, does a route change always spell death for most TCP connections that are running over the changing route ? My guess is that somewhere, "unreachable" packets are being sent back to hosts by some router while the route is changing - does anyone have any evidence of the what goes on during a route change or why connections always seem to die ? Darren.
-----------[000296][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Nov 1992 01:23:40 GMT From: Mark Crispin <mrc@Tomobiki-Cho.CAC.Washington.EDU> To: comp.protocols.tcp-ip, Darren Reed <avalon@coombs.anu.edu.au> Subject: Re: NSFNet goes to hell..
Darren -
If your TCP applications break because you get an ICMP Network
(or Host) Unreachable then they are very very broken. Unfortunately,
this is the behavior of vanilla 4.2bsd and 4.3bsd; some cretin several
years ago thought this would be a useful `feature.' A lot of people
have been nagging various vendors to get this fixed (I take credit for
getting NeXT to fix it in 2.0 of NeXTSTEP) and for the most part this
bug seems to have been squished in the US.
A fix is below. Of course, neither I nor UW NDC take any
responsibility for its accuracy or validity on your system, so be sure
to verify that it is valid before applying it.
Mark Crispin
University of Washington
Networks and Distributed Computing
If you don't have sources, use adb to patch /vmunix to set the 8th and
9th offset of the u_char array inetctlerrmap to 0.
inetctlerrmap (defined in ip_input.c) maps the generic error types
from protosw.h to error numbers from errno.h. Offsets 8 and 9 are
(protosw.h):
#define PRC_UNREACH_NET 8 /* no route to network */
#define PRC_UNREACH_HOST 9 /* no route to host */
which are mapped repsectively to (errno.h):
#define ENETUNREACH 51 /* Network is unreachable */
#define EHOSTUNREACH 65 /* No route to host */
Entries in that array which are 0 do not cause user errors. So, this
effectively deletes those errors.
If you have sources, you can do better. The patch causes 4.3 to
ignore ICMP unreachable errors in all cases, something that one
probably does not want to do. For instance, you probably *much*
prefer to have telnet attempts abort quickly with a "network
unreachable" than with a "connection timed out" some 60 seconds later.
On the other hand, once a connection has been established, you prefer
that stray ICMP errors not break a connection. Moreover, nuking ICMP
unreachable errors weakens utilities like ping that understand such
messages. One of ping's useful features is the printing of ICMP
errors it receives.
The following patch to tcp_notify() treats ICMP unreachable errors as
before, except that they won't break established connections.
*** /tmp/,RCSt1025442 Sat Feb 25 13:46:58 1989
--- /tmp/,RCSt2025442 Sat Feb 25 13:46:59 1989
***************
*** 258,264 ****
tcp_notify(inp)
register struct inpcb *inp;
{
!
wakeup((caddr_t) &inp->inp_socket->so_timeo);
sorwakeup(inp->inp_socket);
sowwakeup(inp->inp_socket);
--- 258,271 ----
tcp_notify(inp)
register struct inpcb *inp;
{
! if (inp->inp_socket->so_state != SS_ISCONNECTING) {
! register int error = inp->inp_socket->so_error;
! if ((error == EHOSTUNREACH) || (error == ENETUNREACH)
! || (error == EHOSTDOWN)) {
! inp->inp_socket->so_error = 0; /* clear error */
! return;
! }
! }
wakeup((caddr_t) &inp->inp_socket->so_timeo);
sorwakeup(inp->inp_socket);
sowwakeup(inp->inp_socket);
-----------[000297][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Nov 1992 02:15:34 GMT From: hsu@cs.hut.fi (Heikki Suonsivu) To: comp.compression,comp.protocols.tcp-ip Subject: Wanted: Fast compression routine for PC
I would like to add compression to a ppp (or slip) packet driver. Maybe
someone has done this already (freely available code), if yes, I would like
to know about it?
I would like to get a fast compression routine for a pc, something like
compress(char *input, int size, char *output, int *out_size);
uncompress(char *input, int buffer_size, char *output, int *out_size);
- I would prefer optimized assembly, but simple C code is ok. I'm ready to
do some work myself, just checking out if there would be something I could
drop in easily.
- The level of compression is not very important, as long as it does
something reasonable.
- The routine should be simple and take little memory.
- Speed is an issue. >10k a second on an 286@8MHz would be nice, but I
could settle for 386@16MHz if this cannot be achieved.
- The code should be good in handling corrupted data, it must not crash if
it gets trash as input, but getting corrupted output from corrupted input
is ok.
Any code I use or write for this will be freely available (probably GPL).
-
Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND,
hsu@{otax.tky.hut,cs.hut,clinet}.fi +385-0-8031121
/G=Heikki/S=Suonsivu/O=hut/OU=cs/PRMD=Inet/ADMD=Fumail/C=FI,
mcsun!hutcs!hsu, riippu SN, Email preferable.
-----------[000298][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Nov 1992 02:30:30 GMT From: rale1@cs.aukuni.ac.nz (Ross4Douglas Alexander ) To: comp.protocols.tcp-ip Subject: ARPAnet meaning
ARPAnet is the acronym for Advanced Research Project Acency Network. ARPA was (is?) one of the agencies within the DoD which dealing with funding reseach for the military. NB: ARPANet doesn't actually exist any longer. It was originally a set of 56Kbps leased lines. It has been replaced by NREN, the NSF backbone and MILnet. Ross Alexander Computer Science Auckland University New Zealand
-----------[000299][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Nov 1992 03:32:20 GMT From: johnmac@fawlty.towers.oz.au (John MacLean) To: comp.protocols.tcp-ip Subject: TCP/IP, Windows 3.1, and Mounted File Systems
What options are available to have file systems mounted under MS-Windows 3.1,
from a UNIX box, and having TCP/IP active simultaneously?
I know this can be done using Novell, but are there any NFS options, or
anything else?
John MacLean.
--
This net: johnmac@fawlty.towers.oz.au Phone: +61 2 427 2999
That net: uunet!fawlty.towers.oz.au!johnmac Fax: +61 2 427 7072
Snail: Tower Technology, 1 Apollo Pl, Home: +61 2 449 5930
Lane Cove, NSW 2066, Australia.
-----------[000300][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Nov 1992 04:06:31 GMT From: dsiebert@icaen.uiowa.edu (Doug Siebert) To: comp.protocols.tcp-ip Subject: How do you request that new Telnet option numbers be assigned?
What is the method for requesting a new Telnet option number be assigned? I know that RFCs are collected somewhere, and made available to the Internet community, and after the comments are submitted the option number is then "assigned". But where does one submit an RFC, and are there guidelines available anywhere specifying the form and method of this submission? -- /-----------------------------------------------------------------------------\ | Doug Siebert | "I don't have to take this abuse | | Internet: dsiebert@isca.uiowa.edu | from you - I've got hundreds of | | NeXTMail: dsiebert@chop.isca.uiowa.edu | people waiting in line to abuse | | ICBM: 41d 39m 55s N, 91d 30m 43s W | me!" Bill Murray, Ghostbusters | \-----------------------------------------------------------------------------/
-----------[000301][next][prev][last][first]---------------------------------------------------- Date: 25 Nov 92 04:13:50 GMT From: alanlb@bethesda.cs.vt.edu (Alan L. Batongbacal) To: comp.unix.sysv386,comp.protocols.tcp-ip Subject: Need help with TCP/IP on ISC 3.0
Hi there! I have ISC 3.0 (with the first patch disk) running on an InfoPro 486/33 motherboard (OPTi chipset) with 16MB of RAM and an Adaptec 1542B. I installed the TCP/IP package, with all prereqs and configured the kernel for a Novell NE2000 ethernet board. The config does not conflict with anything else in the kernel. When the machine boots, I can see that the NE2000 is recognized because a line is printed showing the board's Ethernet ID, etc. However, I subsequently get the following messages: cp: bad copy to /dev/netsched tcp timer failed I then login and try to finger one of my hosts, slave.rct.com. I get: [slave.rct.com]connect: Protocol driver not attached I'd appreciate it if somebody could tell me what the heck is going on, and how to fix it. Thanks! alan l. batongbacal frustrated tcp/ip'er
-----------[000302][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Nov 1992 05:30:40 GMT From: panos@burton.cs.colorado.edu (Panos Tsirigotis) To: comp.protocols.tcp-ip Subject: Re: NSFNet goes to hell..
In article <MS-C.722654620.1103527590.mrc@Tomobiki-Cho.CAC.Washington.EDU> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>Darren -
>
> If your TCP applications break because you get an ICMP Network
>(or Host) Unreachable then they are very very broken. Unfortunately,
>this is the behavior of vanilla 4.2bsd and 4.3bsd; some cretin several
>years ago thought this would be a useful `feature.' A lot of people
>have been nagging various vendors to get this fixed (I take credit for
>getting NeXT to fix it in 2.0 of NeXTSTEP) and for the most part this
>bug seems to have been squished in the US.
>
> A fix is below. Of course, neither I nor UW NDC take any
>responsibility for its accuracy or validity on your system, so be sure
>to verify that it is valid before applying it.
>
>Mark Crispin
>University of Washington
>Networks and Distributed Computing
>
>
>If you don't have sources, use adb to patch /vmunix to set the 8th and
>9th offset of the u_char array inetctlerrmap to 0.
>
>inetctlerrmap (defined in ip_input.c) maps the generic error types
>from protosw.h to error numbers from errno.h. Offsets 8 and 9 are
>(protosw.h):
>
>#define PRC_UNREACH_NET 8 /* no route to network */
>#define PRC_UNREACH_HOST 9 /* no route to host */
>
>which are mapped repsectively to (errno.h):
>
>#define ENETUNREACH 51 /* Network is unreachable */
>#define EHOSTUNREACH 65 /* No route to host */
>
>Entries in that array which are 0 do not cause user errors. So, this
>effectively deletes those errors.
>
>If you have sources, you can do better. The patch causes 4.3 to
>ignore ICMP unreachable errors in all cases, something that one
>probably does not want to do. For instance, you probably *much*
>prefer to have telnet attempts abort quickly with a "network
>unreachable" than with a "connection timed out" some 60 seconds later.
>On the other hand, once a connection has been established, you prefer
>that stray ICMP errors not break a connection. Moreover, nuking ICMP
>unreachable errors weakens utilities like ping that understand such
>messages. One of ping's useful features is the printing of ICMP
>errors it receives.
>
>The following patch to tcp_notify() treats ICMP unreachable errors as
>before, except that they won't break established connections.
>
>*** /tmp/,RCSt1025442 Sat Feb 25 13:46:58 1989
>--- /tmp/,RCSt2025442 Sat Feb 25 13:46:59 1989
>***************
>*** 258,264 ****
> tcp_notify(inp)
> register struct inpcb *inp;
> {
>!
> wakeup((caddr_t) &inp->inp_socket->so_timeo);
> sorwakeup(inp->inp_socket);
> sowwakeup(inp->inp_socket);
>--- 258,271 ----
> tcp_notify(inp)
> register struct inpcb *inp;
> {
>! if (inp->inp_socket->so_state != SS_ISCONNECTING) {
>! register int error = inp->inp_socket->so_error;
>! if ((error == EHOSTUNREACH) || (error == ENETUNREACH)
>! || (error == EHOSTDOWN)) {
>! inp->inp_socket->so_error = 0; /* clear error */
>! return;
>! }
>! }
> wakeup((caddr_t) &inp->inp_socket->so_timeo);
> sorwakeup(inp->inp_socket);
> sowwakeup(inp->inp_socket);
The next thing to do is to replace the line
if (inp->inp_socket->so_state != SS_ISCONNECTING) {
with
if ( ! ( inp->inp_socket->so_state & SS_ISCONNECTING ) ) {
(hint: think about a socket with the non-blocking I/O flag set)
Panos
--
Panos Tsirigotis, CS grad
Pmail: Computer Science Dept., U. of Colorado @ Boulder, Boulder, CO 80309-0430
Email: panos@cs.colorado.edu
-----------[000303][next][prev][last][first]---------------------------------------------------- Date: 25 Nov 1992 14:01:09 -0500 From: tal@Warren.MENTORG.COM (Tom Limoncelli) To: comp.protocols.tcp-ip,comp.sys.sun.hardware Subject: Finding a machine's ethernet hardware
(I need an answer for SunOS 4.1.x, but it would be nice if the answer was portable to other brands of Unix.) I'm writing a program in C that needs to find all the internet addresses the current machine has. I know the IOCTLs I have to use on the interface (through NIT) to get the answer, but I don't know how to find out what interfaces the machine has. (i.e. le0 vs. ie0, etc.) All the example programs in AnswerBook and SunSolve have the user specify the interface on the command line. Any tips will be appreciated, Tom P.S. I can't open a pipe to "ifconfig -a", sorry! -- Tom Limoncelli -- tal@warren.mentorg.com (work) -- tal@plts.uucp (play) Reality is stranger than fiction #943247: The IRS granted ANS approval as a 501c3 "charity" on September 14, 1992.
-----------[000304][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Nov 1992 09:58:25 GMT From: mazzucch@ghost.dsi.unimi.it (massimo mazzucchi) To: comp.protocols.tcp-ip Subject: setup SLIP: info
Hi
I am Max from Milan Italy
I use to communication UNIXtoDOS
FTP Software PC/TCP version 1.16pl4
i will know:
- exist a new version and it is a commercial program? $?
- for example if i have connect my pc with a serial port of
a modem in which way i can use command ftp correctly?( there
are 2 file *.sys that i have place in Config.sys)
- there 2 file IPCONFIG and IFCONFIG
in which way i must use them?
- in which way i must setup my modem?
Thanks for your help
Bye
--------------------------------------------------------------------------------
! Massimo Mazzucchi address e-mail !
! University of State mazzucch@ghost.dsi.unimi.it !
! Departement of Computer Science 149.132.2.1 !
! Via Comelico, 41 - 20133 MILAN ITALY !
-------------------------------------------------------------------------------
-----------[000305][next][prev][last][first]---------------------------------------------------- Date: 25 Nov 92 12:02:22 GMT From: steve@terminus.ericsson.se (Steve Reynolds) To: comp.protocols.tcp-ip Subject: header compression algorithms
I am interested in the Van Jacobsen header compression algorithm, but I am worried about it's application over an unreliable medium. I understand it to be a differences algorithm. If this it the case, then how is recovery from a lost packet accomplished? Does a lost packet imply that a TCP connection must be lost or time out before another may be established? ,or are certain TCP control packets sent uncompressed to allow for resynchronisation? If there are problems on unreliable networks - does anyone know of any other header compression algorithm (preferably code) which is applicable to this environment? Thanks in advance Steve --------------------------------------------------- | Steve Reynolds | | Ericsson | | Leicester | | UK | | TEL: +44 533 537534 | | EMAIL: steve@terminus.ericsson.se | ---------------------------------------------------
-----------[000306][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Nov 1992 13:50:26 GMT From: luigi@iet.unipi.it To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: BOOTP ROM problem
We are having problems with a BOOTP prom for WD8003 cards. The BOOTP PROM is Beame & Whiteside v.1.1a for WD8003, and works perfectly with an Ultrix 4.1 server. But when trying to make it work with AIX 3.2, or with a port of CMU bootpd we made to 386bsd, it doesn't work anymore. It appears that the PC sends the bootp request, the host replies, the PC receives the reply and then simply asks "Enter boot volume name: " instead of getting the file via tftp. tftp seems to work on all of the machines, without special configurations or permissions. So which one of these is true ? 1) I didn't do something I should have on the host. 2) Ultrix 4.1 bootp replies differ from the ones produced by CMU bootpd (which is likely to be the source of AIX bootpd), and the latter are either buggy or non-recognized by B&W BOOTP ROM 3) there is some bug in the ROM code Of course I hope 1) is the right explaination. Any help from the net ? Thanks Luigi Rizzo ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56124 PISA (Italy) fax: +39-50-568522 ====================================================================
-----------[000307][next][prev][last][first]---------------------------------------------------- Date: 25 Nov 92 15:32:52 GMT From: sulistio@sutro.SFSU.EDU (Sulistio Muljadi) To: comp.protocols.tcp-ip Subject: Looking for networking tools...
I am not sure if this is the right newsgroup to post.. if not please let me know.. I am looking for network tools (UNIX) to debug networking problem that we have. Preferable in the public domain area. I heard sometihing about traceroute... is this a public domain tools ? Thanks... -- Mul | Alt. address: sulistio@sutro.sfsu.edu sulistio@futon.sfsu.edu | sulistio@sfsuvax1.sfsu.edu #include "std/disclaimer.h" | NeXTmail -> sarong!sulistio@cs.sfsu.edu >Genius is one per cent inspiration and ninety-nine per cent perspiration.
-----------[000308][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Nov 1992 16:28:19 GMT From: yppawlus@cyf-kr.edu.pl (Jerzy Pawlus) To: comp.protocols.tcp-ip Subject: 3270 emulator under Unix?
Hi, Does anybody know the ftp location where I can find Emulator of IBM 3270 terminal running under Unix (preferably SunOS 4.1.1) Jerzy Pawlus ACK CYFRONET, Krakow, Poland Internet: yppawlus@cyf-kr.edu.pl
-----------[000309][next][prev][last][first]---------------------------------------------------- Date: 25 Nov 92 16:55:16 GMT From: rm72@prism.gatech.EDU (Bruce McCullough) To: comp.protocols.tcp-ip Subject: Re: Looking for networking tools...
>I am looking for network tools (UNIX) to debug networking problem that >we have. Preferable in the public domain area. I am also looking for the same but need any other kind of info on TCP/IP as possible. We have a new computer services specialist at work who wants to learn about TCP/IP ( I'm new to the area myself). -- Robert B. McCullough-Computer Operations Tech. Registrar Data Systems Georgia Institute of Technology Internet: rm72@prism.gatech.edu
-----------[000310][next][prev][last][first]---------------------------------------------------- Date: 25 Nov 92 18:08:30 GMT From: barnett@grymoire.crd.ge.com (Bruce Barnett) To: comp.protocols.tcp-ip Subject: FTP: Send 8 1K packets, then wait.....
I am analyzing some medical networks, and I see a common pattern in large file transfers using FTP. Could someone tell me if this sounds like a bsd4.2, or bsd4.3 implementation of TCP. The sending system sends 8 1K packets. The delay is about 2 milliseconds between packets. The last packet has a "Push" flag. An ack comes back. Then the sender waits a while, typically 40-100 milliseconds, and sends out 8 more packets. The outgoing WIN size is 8K. The receiving window is 24K. The network is not causing a bottleneck. The system is not using IP fragments, nor large window sizes on the sends. This sounds like an early implementation of TCP, on a slow CPU. Typically 84KB/sec over ethernet. Any guesses on why it is so slow? It might be a Sun 3 running SunOS 3.5. (This system is on the other coast. I'm analyzing the output of a tcpdump file that was mailed to me.) -- Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
-----------[000311][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Nov 1992 18:17:17 GMT From: fred@maccs.dcss.mcmaster.ca (Fred Whiteside) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Re: BOOTP ROM problem
In <1992Nov25.135026.18329@cli.di.unipi.it>, luigi@iet.unipi.it writes: >We are having problems with a BOOTP prom for WD8003 cards. The BOOTP >PROM is Beame & Whiteside v.1.1a for WD8003, and works perfectly with an >Ultrix 4.1 server. But when trying to make it work with AIX 3.2, or with >a port of CMU bootpd we made to 386bsd, it doesn't work anymore. It >appears that the PC sends the bootp request, the host replies, the PC >receives the reply and then simply asks "Enter boot volume name: " >instead of getting the file via tftp. tftp seems to work on all of the >machines, without special configurations or permissions. The error message that you are getting indicates that the BOOTP code attempted to get the boot file, and was either given a "File not Found" or an "Access denied" response. You should check the permissions on the file; tftp requires that the files be world-writable. You should also check to ensure that the file that you think is being requested is in fact the file that is being requested. The BOOTP code asks for the file /bwboot/default.wd8003. The actual location of this file depends on whether the tftp daemon is being run in a chroot()ed environment, in which case the actual location of the file will be /xxx/bwboot/default.wd8003 where /xxx is the location that the tftp server was chroot()ed from (likely run from). If you continue to have trouble, please feel free to send email to tech@bws.com or support@bws.com. Fred Whiteside -- Fred Whiteside Beame & Whiteside Software Ltd., Caledonia, Ontario fred@bws.com fred@maccs.DCSS.McMaster.CA ...!uunet!utai!utgpu!maccs!fred
-----------[000312][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Nov 1992 18:17:58 GMT From: luigi@iet.unipi.it To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.unix.bsd Subject: Re: BOOTP ROM problem: SOLVED
In article <1992Nov25.135026.18329@cli.di.unipi.it> luigi@iet.unipi.it writes: >We are having problems with a BOOTP prom for WD8003 cards. The BOOTP >PROM is Beame & Whiteside v.1.1a for WD8003, and works perfectly with an >Ultrix 4.1 server. But when trying to make it work with AIX 3.2, or with >a port of CMU bootpd we made to 386bsd, it doesn't work anymore. It Well, the problem has been solved now, at least with 386bsd (and thus I think it will work with AIX as well, given the symptoms). But a few words of explaination might help other people with the same problem: >appears that the PC sends the bootp request, the host replies, the PC >receives the reply and then simply asks "Enter boot volume name: " >instead of getting the file via tftp. tftp seems to work on all of the >machines, without special configurations or permissions. >So which one of these is true ? > >1) I didn't do something I should have on the host. >2) Ultrix 4.1 bootp replies differ from the ones produced by CMU bootpd > (which is likely to be the source of AIX bootpd), and the latter > are either buggy or non-recognized by B&W BOOTP ROM >3) there is some bug in the ROM code > >Of course I hope 1) is the right explaination. Any help from the net ? 1) is true, 2) is (more or less) false, 3) is (more or less) false. To be precise, the problem has nothing to do with bootpd, but with tftpd. The version of tftpd on 386bsd (and probably on AIX 3.2) will not prepend anything to the pathnames of the requested files. Thus, even if I specify something like tftpd /mytftpdirectory in /etc/inetd.conf or its equivalent for AIX, requests for /bwboot/default.wd8003 will look for the absolute pathname. BTW, this tftpd will not send files which are not in the trees specified as parameters to tftpd. On Ultrix 4.1 instead, the above situation would cause tftpd to look for /mytftpdirectory/bwboot/default.wd8003 and to send the file as requested. This is also what B&W documentation says: The file "default.wd8003" must be created in the directory "bwboot" which is a subdirectory of the tftpd's working directory. See the file "default.set" about the make up of the "default.wd8003" file. For 3C501 cards substitute "default.3c501" for "default. and is the reason why things did work fine on Ultrix 4.1 but not on the other, newer machines. So, the bug is mainly in the documentation. Oh well, as a fallout of all this, now at least I have a working bootpd under 386bsd... Thanks for the interest Luigi Rizzo ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56124 PISA (Italy) fax: +39-50-568522 ====================================================================
-----------[000313][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Nov 1992 19:02:48 GMT From: Scott Brim <swb1@cornell.edu> To: comp.protocols.tcp-ip Subject: Re: Multicast Routers (was Re: NIS broadcasts over IP subnets)
In article <sii7sjk@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: Do Wellfleet, Cisco, or others now do the right things when they see a class D address? Do they forward such IP packets? As far as I know only Proteon and SGI (a good router company) do the right thing with class D packets. What could the others do? They don't have a routing protocol. As far as I can tell, the router vendors have been dragging their feet vigorously on any kind of multicast routing for at least 4 years. The router vendors have shown more enthusiasm for PPP, despite the danger PPP represents to their locked-in customer bases. Right. It's a chicken and egg problem, since router vendors are demand-driven. I believe this is going to change now relatively rapidly since the workstation vendors are boosting multimedia and multicasting is the natural extension. We've distributed prototypes of our Mac videoconferencing software with hardly any features at all, for example, and we get impassioned pleas for multicast versions all the time. Scott
-----------[000314][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Nov 1992 21:19:26 GMT From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) To: comp.dcom.modems,comp.protocols.tcp-ip Subject: faster SLIP/PPP
It appears from my experimentation and from what I have seen here on the net that one significant component of SLIP/PPP packet delays is the delay caused by the v.42/v.42bis packetization. The modems appear to have to accumulate and "bless" the whole v.42/v.42bis packet before the packet is sent on. This adds another delay into the SLIP cycle. Has anyone experimented with using a synchronous link between the modems? What sort of delays can one expect between the sync rs-232 data at one modems end and the sync data at the other? Will the delay be on the order of bit-times (eg. 1-2 milliseconds) or will the modems impose a much larger delay, but buffering/delaying the bits anyway? I am told that there is a bucket-brigade "data scrambler" that some protocols use to randomize the data. How long is this shifter? Is it possible to disable it (at both ends, of course) to get lower delays? -wolfgang -- Wolfgang Rupprecht wolfgang@wsrcc.com (or) decwrl!wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511
-----------[000315][next][prev][last][first]---------------------------------------------------- Date: 25 Nov 92 21:28:11 GMT From: alten@novell.com (Alex Alten) To: comp.protocols.tcp-ip Subject: Re: Getting the ethernet address off (SMC)WD8003E Lan Cards
In article <1992Nov16.032841.7572@csc.canberra.edu.au> act@softserver.canberra.edu.au (Andrew Turner) writes: >Would someone please e-mail(I'll on-forward if you too want same - e-mail >requests) a code fragment assembler/pascal/C that will return the ethernet >address from an WD8003E card. .. >Renrut Werdna Probable-Possible, my black hen, You need the Packet Driver specs and the drivers (plus source). The specs should be available from FTP Software (anon.ftp.com?). Version 1.09 is the latest, although I've only seen source for 1.08. If you want to do a more in depth search for source archives, telnet into an Arhie server as user archie. Try 128.6.18.15 archie.rutgers.edu, 129.93.1.14 archie.unl.edu, 132.206.2.3 archie.mcgill.ca (original), 139.130.4.6 archie.au, 128.214.6.100 archie.funet.fi, 146.169.11.3 archie.doc.ic.ac.uk. After you are in type: set mailto <your domain or ip address here> set sortby hostname set search subcase prog packet You will get a long listing... Then type: mail You will then receive several mail messages with your long listing inside them. Don't forget to logoff when you are done. -- - Alex (alten@na.novell.com)
-----------[000316][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Nov 1992 21:34:30 GMT From: hole@cs.UAlberta.CA (Steve Hole) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Need help on Tn3270 key sequences
Can anyone tell me the TN3270 key sequences for :
SYSREQUEST, ATTENTION, CURSOR SELECT and ERASE INPUT.
I am trying to add these keys to the Tn3270 emulator of Beamme and Whiteside .
Please reply to
airon@ed.isac.ca
-----------[000317][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Nov 1992 21:38:58 GMT From: evansmp@uhura.aston.ac.uk (Mark Evans) To: comp.protocols.tcp-ip Subject: Re: NSFNet goes to hell..
Mark Crispin (mrc@Tomobiki-Cho.CAC.Washington.EDU) wrote: : Darren - : : If your TCP applications break because you get an ICMP Network : (or Host) Unreachable then they are very very broken. Unfortunately, : this is the behavior of vanilla 4.2bsd and 4.3bsd; some cretin several : years ago thought this would be a useful `feature.' A lot of people : have been nagging various vendors to get this fixed (I take credit for : getting NeXT to fix it in 2.0 of NeXTSTEP) and for the most part this : bug seems to have been squished in the US. : It also has the problem that it enables a cracker to use this "feature" to kill tcp connections.
-----------[000318][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Nov 1992 21:41:58 GMT From: jcobban@bnr.ca (Jim Cobban) To: comp.protocols.tcp-ip Subject: TN3101 or TN3151
Right next to my Sparc UNIX management workstation with all of its motif windows, I have an IBM 3101. That terminal is rarely used, but when it is it is absolutely necessary, because it is the management console for the CMOSS function on our 3745s. The CMOSS ports on the 3745s are themselves actually plugged into our network, as is the 3101, so we use the switching capability of the network to connect the two. I would just like to reclaim the desk space which the 3101 is occupying, and integrate that function into the management workstation software. However to do so I need the ability to emulate a block mode 3101. Since aside from the 3745 and some protocol converters there is no host support for block mode 3101 (for example UNIX only has termcap support for character mode 3101), I have not been able to lay my hands on any code to do this emulation. Is there anybody out there who could point me at any product or code or anything which does this function? -- ------------------------------------------------------------------------------- Jim Cobban | jcobban@bnr.ca | Phone: (613) 763-8013 BNR Ltd. | bnrgate.bnr.ca!bcars5!jcobban | FAX: (613) 763-2626
-----------[000319][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Nov 1992 21:51:46 GMT From: kudzu@netcom.com (Michael Sierchio) To: comp.protocols.tcp-ip Subject: Re: ARPAnet means?
In article <1992Nov24.204745.2524@udel.edu> stewart@daffy.cis.udel.edu (John Stewart) writes: >Advanced Research Projects Agency. Actually, the name comes >from an agency of the Department of Defense -- the Defense >Advanced Research Projects Agency. I believe its network was >called ARPANET (rather than DARPANET) purely for reasons of >political-correctness. Nope. Went through a name change, had 'DEE-FENSE' prepended. -- +--------------------------------------------------------------------------+ | Michael Sierchio 1563 Solano Avenue, Suite 123 | | kudzu@netcom.com Berkeley, CA 94707-2116 | +--------------------------------------------------------------------------+
-----------[000320][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Nov 1992 22:49:56 GMT From: peter@palin.cc.monash.edu.au (Peter Hawkins) To: comp.protocols.tcp-ip Subject: Re: Pascal Waterloo TCP/IP library
jmfres11@ucs.usl.edu (Karthikeyan Gurnswamy) writes: >In article <peter.722065275@palin.cc.monash.edu.au> peter@palin.cc.monash.edu.au (Peter Hawkins) writes: [...] >>I got a copy of wattcp - a mixture of asm & C, and compiled it with >>BCC, but unfortunately I couldn't link the C & pascal object files >>without leaving unresolved externals - Borland's advice was that [...] >First get the Waterloo TCP/IP manual and make identical functions in >C itself like psock_init(), psock_read() which calls sock_init() >and sock_read() respectively. Declare psock_init() in the waterloo >as >pascal psock_init() >This directive is for linking your pascal routines correctly with >the C function with correct function parameters. You have do the >pascal psock_init() >in one of the Waterloo TCP/IP source files itself. Build the Waterloo >TCP/IP library. Now make a small pascal routine which calls psock_init() >or psock_read() and compile and link it with the new library and all >the support pascal and c libraries like cs.lib + maths.lib etc., >Wild guess - Might work ... Thanks for the advice, however this is exactly what I had attempted to do without success. The unresolved externals (etc) come from C intrinsics etc and Borland says there is no way around this. The Pascal prefix swaps the stack ordering of parameters to be consistent with Pascal, and you can define psock_init() (etc) to be external, but for some reason you can't define the contents of the bcc libraries to be external - or at least, some parts of them remain unresolved. Peter PS - I have now got an alternative - someone suggested I get hold of the PC Gopher source. -- Peter Hawkins, Assistant Lecturer, Computer Centre Monash University, Australia peter@palin.cc.monash.edu.au
-----------[000321][next][prev][last][first]---------------------------------------------------- Date: 25 Nov 92 23:16:10 GMT From: nevries@accucx.cc.ruu.nl (Nico E de Vries) To: comp.compression,comp.protocols.tcp-ip Subject: Re: Wanted: Fast compression routine for PC
In <HSU.92Nov25041528@cardhu.cs.hut.fi> hsu@cs.hut.fi (Heikki Suonsivu) writes:
>I would like to get a fast compression routine for a pc, something like
>compress(char *input, int size, char *output, int *out_size);
>uncompress(char *input, int buffer_size, char *output, int *out_size);
Look for the LZRW and the "Finish" compressor in my LDS_10 package.
>- I would prefer optimized assembly, but simple C code is ok. I'm ready to
>do some work myself, just checking out if there would be something I could
>drop in easily.
The Finish compressor comes in both Intel machine code and C.
>- The routine should be simple and take little memory.
If the Finish compressor uses too much memory look for the included LZRW
compressor.
>- Speed is an issue. >10k a second on an 286@8MHz would be nice, but I
>could settle for 386@16MHz if this cannot be achieved.
I suppose you mean >10k/second. Both Finish and LZRW should be able
to do this.
>- The code should be good in handling corrupted data, it must not crash if
>it gets trash as input, but getting corrupted output from corrupted input
>is ok.
Crashing is not likely. Some extra checks might be usefull.
>Any code I use or write for this will be freely available (probably GPL).
Both LZRW and Finish are free to use I believe. I don't know about
pattents etc. I believe someone patented LZRW. Look in the FAQ for
more info on that subject.
Locating the comp.compression ==> FAQ <== :
* The FAQ is posted often to comp.compression and should also be available
on news.answers as "comp.compression Frequently Asked Questions".
* The FAQ is also available by anonymous ftp on rtfm.mit.edu [18.72.1.58]
in directory /pub/usenet/news.answers/compression-faq, files part1 and part2.
* If you don't have FTP access, you can get the FAQ by a mail
server. Send an email message to mail-server@pit-manager.mit.edu
containing the command "help" (no quotes) for more information.
* If all above REALLY fails, request the files from nevries@cc.ruu.nl
Locating lossless data compression ==> SOURCES <== :
garbo.uwasa.fi /pc/programming/lds_10.zip contains most known sources
for lossless data compression.
>Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND,
Nico E. de Vries (nevries@cc.ruu.nl) |------------------* AA III PPP
_ This text is supplied AS IS, no warranties of any kind | A A I P P
| apply. No rights can be derived from this text. This | AAAA I PPP
| text is likely to contain spelling and grammar errors. | A A I P
*---------------------------( Donate to GreenPeace! )----* A A III P
To get (many) ==> LOSSLESS DATA COMPRESSION SOURCES <== get lds_10.zip at
garbo.uwasa.fi /pc/programming. Make files for Borland C are included.
-----------[000322][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Nov 1992 23:44:59 GMT From: beame@maccs.dcss.mcmaster.ca (Carl Beame) To: comp.protocols.tcp-ip Subject: Re: TCP/IP, Windows 3.1, and Mounted File Systems
In article <1992Nov25.033220.9842@fawlty.towers.oz.au> johnmac@fawlty.towers.oz.au (John MacLean) writes: >What options are available to have file systems mounted under MS-Windows 3.1, >from a UNIX box, and having TCP/IP active simultaneously? > >I know this can be done using Novell, but are there any NFS options, or >anything else? Novell has an NFS Client for LanWorkPlace as an add on option. Also, most TCP/IP companies can provide the NFS and TCP/IP under windows. A short list includes: Beame & Whitesode Software Ltd. FTP Software Wolongong Sun ... > >John MacLean. >-- >This net: johnmac@fawlty.towers.oz.au Phone: +61 2 427 2999 >That net: uunet!fawlty.towers.oz.au!johnmac Fax: +61 2 427 7072 >Snail: Tower Technology, 1 Apollo Pl, Home: +61 2 449 5930 > Lane Cove, NSW 2066, Australia. Carl Beame Beame & Whiteside Software Ltd.
-----------[000323][next][prev][last][first]---------------------------------------------------- Date: Thu, 26 Nov 1992 00:06:27 GMT From: mobrien@telesciences.com (Mark W O'Brien) To: comp.protocols.tcp-ip Subject: Need root privelidges to open RAW socket?
Is it necessary to have root privelidges in order to open
a RAW socket?
This seems to be the case when running the 'ping' implementation
from Steven's book on Unix network programming. If so, is there
a way to make this run without being a superuser?
Mark O'Brien
mobrien@telesciences.com
--
_______________________________________________________________________
"I never liked Star Trek"
_______________________________________________________________________
-----------[000324][next][prev][last][first]---------------------------------------------------- Date: Thu, 26 Nov 92 09:35:23 GMT From: eks@daimi.aau.dk (Eigil Krogh S|rensen) To: comp.protocols.tcp-ip Subject: Is there a "something"-ware tcp/ip package for UNIX ?
s there "something"-ware package(s) for unix which has/have tcp/ip rlogin, rcp remsh/rsh or something like it. nfs. Thank you in advance ! --- Eigil
-----------[000325][next][prev][last][first]---------------------------------------------------- Date: 26 Nov 92 09:44:00 GMT From: smee@bristol.ac.uk (Paul Smee) To: comp.protocols.tcp-ip Subject: Re: ARPAnet means?
In article <rhughes.1.0@UCSD> rhughes@UCSD (Richard J. Hughes) writes: >The title says it all. What does the "ARPA" in ARPAnet stand for? Would >some kind soul please let me know. Advanced Research Projects Agency. Part of the US Department of Defense, or at least was originally. -- Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK P.Smee@bristol.ac.uk - ..!uunet!uknet!bsmail!p.smee - Tel +44 272 303132
-----------[000326][next][prev][last][first]---------------------------------------------------- Date: 26 Nov 92 17:32:19 GMT From: chris@visionware.co.uk (Chris Davies) To: comp.protocols.tcp-ip Subject: Re: TCP/IP, Windows 3.1, and Mounted File Systems
John MacLean (johnmac@fawlty.towers.oz.au) wrote:
: What options are available to have file systems mounted under MS-Windows 3.1,
: from a UNIX box, and having TCP/IP active simultaneously?
We have this scenario. I use FTP's PCTCP and InterDrive. Works fine.
Chris
--
VISIONWARE LTD, 57 Cardigan Lane, LEEDS LS4 2LE, England
Tel +44 532 788858 x238. Fax +44 532 304676. Email chris@visionware.co.uk
---------- "VisionWare: The home of DOS/SQL/UNIX/X/VMS integration" ---------
-----------[000327][next][prev][last][first]---------------------------------------------------- Date: Thu, 26 Nov 1992 22:08:26 GMT From: aaraya@tolten.puc.cl (Arnoldo Araya Flores) To: comp.protocols.tcp-ip Subject: TRouter in CISCO 500-CS !!
I would like to have some help with a routing problem with slip connections in our network. We have a CISCO 500-CS Slip Gateway. We are using it for a remote connection to proffesors of our university. In order to achieve this, we have only one phone number that connects through three lines to our CISCO. Then you can dial to this number and go in one of those three lines (the Telephone Company manage the line the call goes). This CISCO is used like a router. Then I put the next adresses in the dial in ports: 146.155.30.1 146.155.30.2 146.155.30.3 And the ethernet interface has the next IP number 146.155.1.1 It doesn't work. You can go to the slip gateway, enter the slip mode, but when you try to do telnet from your computer it doesn't work (only 5% of the trys). I suspect that it is a routing problem, because what I have is to have one network routed through three differents lines. My interest is to have one network for all the slip connections. I will thanks any help to solve this problem Arnoldo Araya aaraya@tolten.puc.cl Support Manager SECICO PONTIFICIA UNIVERSIDAD CATOLICA DE CHILE CHILE
-----------[000328][next][prev][last][first]---------------------------------------------------- Date: 27 Nov 92 02:03:38 GMT From: bmw@isgtec.com (Bruce M. Walker) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Re: BOOTP ROM problem
In article <1992Nov25.135026.18329@cli.di.unipi.it> luigi@iet.unipi.it writes:
> We are having problems with a BOOTP prom for WD8003 cards. The BOOTP
> PROM is Beame & Whiteside v.1.1a for WD8003, and works perfectly with an
> Ultrix 4.1 server. But when trying to make it work with AIX 3.2, or with
> a port of CMU bootpd we made to 386bsd, it doesn't work anymore. It
> appears that the PC sends the bootp request, the host replies, the PC
> receives the reply and then simply asks "Enter boot volume name: "
Beame & Whiteside's BOOTP ignores "directed" BOOTP replies, they have to
be broadcast to be recognized. This drove me crazy until I accidentally
discovered that fact with an HP implementation of bootpd that has a flag
to do broadcasting instead of the more standard directed reply.
I figure it can't be that hard to modify CMU bootpd, but I haven't got the
time myself.
--
"Eventually, I decided that thinking was not getting me very far and it
was time to try building." -- Rob Pike, The Text Editor sam
bmw@isgtec.com [ ...!uunet.ca!isgtec!bmw ] Bruce Walker
-----------[000329][next][prev][last][first]---------------------------------------------------- Date: 27 Nov 92 16:03:58 GMT From: avalon@coombs.anu.edu.au (Darren Reed) To: comp.protocols.tcp-ip Subject: Re: NSFNet goes to hell..
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: >Darren - > If your TCP applications break because you get an ICMP Network >(or Host) Unreachable then they are very very broken. Unfortunately, >this is the behavior of vanilla 4.2bsd and 4.3bsd; some cretin several >years ago thought this would be a useful `feature.' A lot of people >have been nagging various vendors to get this fixed (I take credit for >getting NeXT to fix it in 2.0 of NeXTSTEP) and for the most part this >bug seems to have been squished in the US. The ICMP unreachable is only a guess at what the network is sending... but why should it send these back when it should be sending redirects to notify someone or something that the route has changed ? Or does a route have to become unreachable before an alternative is found ? Darren
-----------[000330][next][prev][last][first]---------------------------------------------------- Date: Fri, 27 Nov 1992 20:59:50 GMT From: jones@bernie.sal.wisc.edu (Tom Jones) To: comp.protocols.tcp-ip Subject: ENOTTY from getsockopt
One of our programmers is getting the error return ENOTTY from a getsockopt call. I don't have the source code, but here is the situation. He is trying to set the tcp-level option TCP_NODELAY using setsockopt, so before and after that call he uses getsockopt to return the option setting. Each getsockopt call returns the error code ENOTTY. I know this isn't much to go on, but if anyone has seen this behavior and knows what is happening, I would appreciate hearing from them. -- Thomas E. Jones | internet: jones@sal.wisc.edu UW Space Astronomy Laboratory | DECNET: UWSAL::JONES 1150 University Avenue | Madison, WI 53706 | Ma Bell: (608)263-4683
-----------[000331][next][prev][last][first]---------------------------------------------------- Date: 28 Nov 92 01:34:52 From: jraja@vipunen.hut.fi (Jarno Tapio Rajahalme) To: comp.protocols.tcp-ip Subject: Re: header compression algorithms
In article <719@quirm.terminus.ericsson.se> steve@terminus.ericsson.se (Steve Reynolds) writes:
I am interested in the Van Jacobsen header compression algorithm, but I am worried
about it's application over an unreliable medium.
The RCF1144 ("Compressing TCP/IP Headers for Low-Speed Serial Links")
describes the algorithm in detail (including sample code). It (and
other RFCs) can be ftpd from nic.ddn.mil.
I understand it to be a differences algorithm.
If this it the case, then how is recovery from a lost packet accomplished?
Since TCP provides Reliable transfer on top of _unreliable_ media, the
problem is solved by TCP discarding incoming packets (which have, for
example, sequence number out of sync.). Main point here is that the
TCP Checksum is _never_ compressed. When TCP does error recovery the
compression algorithm gets in to sync again.
Does a lost packet imply that a TCP connection must be lost or time out before
another may be established? ,or are certain TCP control packets sent uncompressed
to allow for resynchronisation?
No, yes (see above).
If there are problems on unreliable networks - does anyone know of any other
header compression algorithm (preferably code) which is applicable to this
environment?
Thanks in advance
You're welcome.
Steve
Jarno
--
-----------------------------------------------------------------------------
| Address: Jarno Rajahalme | EMail: |
| Servin Maijan tie 12 H 111 | Jarno.Rajahalme@hut.fi |
| 02150 ESPOO, FINLAND | tel: +358 0 468 2891 |
-----------------------------------------------------------------------------
-----------[000332][next][prev][last][first]---------------------------------------------------- Date: 28 Nov 92 01:04:51 GMT From: mrc@Ikkoku-Kan.Panda.COM (Mark Crispin) To: comp.protocols.tcp-ip, Darren Reed <avalon@coombs.anu.edu.au> Subject: Re: NSFNet goes to hell..
The only thing that an ICMP Unreachable means is that a particular packet got dropped because the route switched. Your TCP is supposed to retransmit. That is, after all, the whole point of the TCP transition nearly 10 years ago (somewhere I have my I Survived the TCP Transition button) was to run on networks that did not guarantee reliable delivery. NCP was otherwise a perfectly good and useful protocol and a helluva lot easier to implement. Furthermore, your question about a redirect makes no sense. A redirect isn't terribly useful if the routing change is further down the pipe from your local gateway. You have no knowledge or control over what gateways are used other than your local gateway; so a redirect wouldn't do you a bit of good. What you're essentially asking is shouldn't the gateway deliver your packet anyway, even though the route switched while your packet was in transit. That requires quite a bit of hair in the routing infrastructure; probably more than can be reasonably expected since the new route may be several routers back. That is, if the packet took a wrong turn 5 routers back, for the router to get it back on track it would have to backtrack it 5 routers. It is a lot easier -- and probably a lot more reliable given the possibility of routing loops -- for the packet to be dropped and let the originator's TCP retransmit. The ICMP Unreachable is simply a courtesy.
-----------[000333][next][prev][last][first]---------------------------------------------------- Date: 28 Nov 92 06:19:36 GMT From: bj@steele.ohsu.edu (Bill Jackson) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Does Ethernet into Token Ring go?
I am looking for experiences in, or references to information on, moving a large Ethernet installation onto a 16M Token Ring backbone. The TR is already supporting approx 800 PC's running NetWare and TCP/IP, and the Ethernet has about the same number of various workstations running almost everything you can think of, including OSI protocols. The Ethernet needs to be upgraded, as it is currently all bridged and the bridges are becoming a throughput bottleneck, not to mention too much chatty traffic going too far! I am looking at the possibility of joining onto an existing 16M TR and cutting down the number of protocols to NetWare, TCP/IP, EtherTalk and some DECNET. I will keep the Ethernet hardware at the stations, and use either NetWare or other (better!) routers to handle traffic onto the TR backbone. I have a few questions about this strategy: Will it WORK? Is the Ethernet traffic going to create any problems? Is there any way to predict the resultant loading on the TR? When subnetting, what is the recommended # of devices (ie subnet mask) on the token ring (4M) and Ethernet (10M) subnets? Sorry if this is a frequent question - I don't get much time to read the News! If anyone has any advice or observations, I would like to hear from them, prferably by mail. I will be gald to post or mail responses to others interested. Thanks. -- --- William Jackson Manager, Network Services, Gaines Hall #113 Oregon Health Sciences University (OHSU), 840 SW Gaines Road, Portland,OR 97201 (503) 494 4535 Internet: bj@ohsu.edu AT&T Mail: attmail!ohsu3b2!bj
-----------[000334][next][prev][last][first]---------------------------------------------------- Date: Sat, 28 Nov 92 06:31:10 GMT From: bernie@metapro.DIALix.oz.au (Bernd Felsche) To: comp.protocols.tcp-ip,comp.sys.sun.misc Subject: Re: Network print spoolers? Parallel ports?
In <id.629V.9W1@ferranti.com> peter@ferranti.com (peter da silva) writes: >We have a network of Sun workstations that we want to stick a parallel >port dot matrix printer on for draft quality screen dumps. Because it's >such a high data volume, we don't want to mess with a serial printer. >Sun's parallel port is O($1000)! >Next solution is to use a standalone printer server or terminal server >with a parallel port. This would simplify administration and dependence >on some particular workstation, too. What sort of products should we be >looking at, and what sort of prices? Don't forget about SCSI-based systems. There's a Central Data widget that connects to SCSI and will give you paralized ports. They start at about $700, list. Phone 800-482-0315 As far as networks are concerned, there's a Milan (don't you hate puns in names?) printserver. It costs about $900 and will drive one printer. Contact fpinfo@milan.com. If you need another termserver anyway, then the cost of an extra paralysed port is minimal. I am not associated in any way with any of the above companies, nor do I have any experience with their products. I just saw the ad's in UNIX REVIEW and thought I might give a couple of alternatives. You're wise enough to make your own choice. -- +-----+ Bernd Felsche _--_|\ #include <std/disclaimer.h> | | | | MetaPro Systems Pty Ltd / \ bernie@metapro.DIALix.oz.au | | | | 328 Albany Highway, X_.--._/ Fax: +61 9 472 3337 |m|p|s| Victoria Park, Western Australia 6100 v Phone: +61 9 362 9355
-----------[000335][next][prev][last][first]---------------------------------------------------- Date: Sun, 29 Nov 1992 03:27:24 GMT From: an318@anon.penet.fi (Knauerhase's friend) To: comp.protocols.tcp-ip Subject: To Rob Knauerhase...
Were you saying something about trying to post anonymously to this group? -------------------------------------------------------------------------- To use this service, send mail to: Anonymous posting: <name.of.news.group>@anon.penet.fi Anonymous mail: <user's alias>@anon.penet.fi <user%host>@anon.penet.fi Test path/get alias: ping@anon.penet.fi Assign nickname: nick@anon.penet.fi (in Subject:) Anon administrator: an0@anon.penet.fi (anonymously) admin@anon.penet.fi (non-anon) Or mail to anon@anon.penet.fi with an X-Anon-To: header line.
-----------[000336][next][prev][last][first]---------------------------------------------------- Date: 29 Nov 92 16:28:06 GMT From: paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO) To: comp.protocols.tcp-ip Subject: Re: To Rob Knauerhase...
an318@anon.penet.fi (Knauerhase's friend) writes: >Were you saying something about trying to post anonymously to this >group? I apologize for this posting. Comments may be sent to the originator, Michael David Adams, aka StarOwl, at mda46419@uxa.cso.uiuc.edu. Nov 28 21:29:28 ux1 sendmail[19646]: AA19646: message-id=<9211290327.AA17120@ eng-nxt10.cso.uiuc.edu > Nov 28 21:29:28 ux1 sendmail[19646]: AA19646: from=<mda46419@eng-nxt10>, size=485, class=0 Nov 28 21:29:28 ux1 sendmail[19646]: AA19646: received from eng-nxt10.cso.uiuc.edu (128.174.2.30) Nov 28 21:29:33 ux1 sendmail[19648]: AA19646: to=<comp.protocols.tcp-ip@anon.penet.fi>, delay=00:00:05, stat=Sent, mailer=TCP, relay=fuug.fi /pbp -- Necessity is the argument of tyrants, it is the creed of slaves. --William Pitt (1783)
-----------[000337][next][prev][last][first]---------------------------------------------------- Date: 29 Nov 92 16:28:49 GMT From: ksh@powell.cs.jt.dk (Kurt Sejr Hansen) To: comp.protocols.tcp-ip Subject: D-link 600 adapter and PC-NFS
Hi' there ........
Has anyone used a D-link adapter with PC-NFS on two
ethernet segments ?.
We are trying to establish a ftp or telnet connection from
one ethernet segment to a host on another segment. But both
ftp an telnet hangs .....
Please give me a hint' if possible.
Used drivers :
DE600PD.sys from 27/3 1992 size is 7848 bytes
PDNFS.SYS from 3/12 1991 size is 4160 bytes
The pocket adapter is a DE-600AUI-E, PC-NFS version is 3.5c
CONFIG.SYS file
device=a:\dos\himem.sys
buffers = 40
BREAK=ON
COUNTRY=045,,a:\DOS\COUNTRY.SYS
DEVICE=a:\DOS\DISPLAY.SYS CON:=(EGA,,1)
INSTALL=a:\DOS\SHARE.EXE
shell =command.com /p /e:800
DEVICE=a:\NFS\PCNFS.SYS /m
DEVICE=a:\NFS\SOCKDRV.SYS
device=a:\nfs\de600pd.sys 98
device=a:\nfs\pdnfs.sys
LASTDRIVE=V
AUTOEXEC.BAT file :
@ECHO OFF
PROMPT $p$g
PATH A:;A:\NFS;A:\DOS;
MODE CON CODEPAGE PREPARE=((850) A:\DOS\EGA.CPI)
MODE CON CODEPAGE SELECT=850
KEYB DK,,A:\DOS\KEYBOARD.SYS
set nfsdrive=a
set TZ=WET0WDT
prt *
nfsrun
a:\nfs\drives.bat file :
NET USE G: kepler:/home/pc/gdos /ms
a:\nfs\hosts file :
192.66.17.90 nfs_test
192.66.17.1 bacon
192.66.17.70 jt
The network.bat file :
NET NISDOMAIN Sysnet
NET START RDR nfs_test *
NET ROUTE jt
NET NISSET bacon
NET NAME *
Router
Problem : ______
Segment #1 | | Segment #2
---------------------------------| |--------------------
| | ------ |
| | |
fileserver #1 D-link fileserver #2
If i try to ftp or telnet from D-link to filserver #1 it's
ok, but it i try to telnet/ftp to filserver #2 i never get a
connection. If i use telnet it displays "Trying ....." and
the connected messages, but i never see the username and
password messages. We have other PC's connected to
segment #1 with 3COM adapters, and it works fine.
Fileserver #1 is a SUN 4/390, fileserver #2 is a SUN 4/470
the D-link adapter is connected to a Toshiba T3100SX.
Kurt Sejr Hansen
ksh@cs.jt.dk
--
J TTTTT AAAA SS JYDSK TELEFON
J T A A S Kurt Sejr Hansen ksh@cs.jt.dk
J T AAAA S Sletvej 30 8310
JJ T A A SS DK Denmark
-----------[000338][next][prev][last][first]---------------------------------------------------- Date: Mon, 30 Nov 92 01:50:27 GMT From: parson@coulomb.pcc.oz.au (Brenda Parsons - x2403) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Re: BOOTP ROM problem
Bruce M. Walker (bmw@isgtec.com) wrote: : Beame & Whiteside's BOOTP ignores "directed" BOOTP replies, they have to : be broadcast to be recognized. This drove me crazy until I accidentally : discovered that fact with an HP implementation of bootpd that has a flag : to do broadcasting instead of the more standard directed reply. : Is this also a problem with the FTP PC/TCP's bootpd? It seems that the bootp requests are being broadcast instead of directed. -- % Brenda Parsons % Currently at Prospect Electricity % 10 Smith Street, Parramatta 2150, Australia % +61 2 635 0300 e-mail: parson@coulomb.pcc.oz.au
-----------[000339][next][prev][last][first]---------------------------------------------------- Date: 30 Nov 92 11:09:11 CST From: robert@cpvax.cpses.tu.com To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Does Ethernet into Token Ring go?
In article <1992Nov28.061936.14440@ohsu.edu>, bj@steele.ohsu.edu (Bill Jackson) writes:
> I am looking for experiences in, or references to information on, moving a
> large Ethernet installation onto a 16M Token Ring backbone. The TR is already
> supporting approx 800 PC's running NetWare and TCP/IP, and the Ethernet has
> about the same number of various workstations running almost everything you can
> think of, including OSI protocols.
>
At CPSES we are sucessfully bridging Ethernets using a site Token Ring
backbone. If you want to bridge, remember that non 802.3 packets (Ethernet
frame format) will need to be "translated" before it gets put on the
token ring. This is done by creating a fake 802.3 header and using a
special DDAP and SSAP field. The bridge on the other side of the link
recognizes the special fields and strips them off for transmission on the
remote Ethernet.
This translation activity is not standardized. We use IBM 8209 bridges for
all our Ethernet-TR bridging. We have CISCOs routing routable protocols
between Ethernet and TR on a couple of segments, but still need an 8209 for the
non-routable protocols. (The routable protocols are filtered out on these
8209s.) Cisco's tranlation bridging (if available) is not compatable with
IBM's.
We use TR to link campus Ethernets because it doesn't have the collision
domain (distance) restrictions and because it was installed for another
project. We are very happy with our configuration.
--
-------------------------------------------------------------------------
Robert Eden 817-897-0491 Glen Rose, TX
Comanche Peak Steam Electric Station robert@cpvax.cpses.tu.com
^^^^^^^^^^^^^^^^^^^^^ politicese for a nuke plant
-------------------------------------------------------------------------
-----------[000340][next][prev][last][first]---------------------------------------------------- Date: Mon, 30 Nov 1992 06:03:19 GMT From: root@candle.uucp (Bruce Momjian) To: comp.protocols.tcp-ip Subject: Rlogin vs. Telnet
Having read Steven's "Unix Network Programming", what is the major difference between rlogin and telnet. Here are the differences I see: 1) rlogin is for unix-to-unix logins, telnet is for any tcp/ip computer 2) rlogin assumes there is a tty terminal discipline on each side of the connection, telnet does not Are there any other major differences, either in function or features? -- Bruce Momjian | 830 Blythe Avenue root%candle.uucp@bts.com | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (215) 353-9879(w) + Christ can be your backup. | (215) 853-3000(h)
-----------[000341][next][prev][last][first]---------------------------------------------------- Date: Mon, 30 Nov 1992 11:29:02 GMT From: tkevans@fallst (Tim Evans) To: comp.protocols.tcp-ip Subject: Re: Rlogin vs. Telnet
root@candle.uucp (Bruce Momjian) writes:
> 1) rlogin is for unix-to-unix logins, telnet is for any tcp/ip
> computer
rlogin is for "something-to-unix" logins. Some (all?) of the PC
TCP/IP packages have an "rlogin" application.
> 2) rlogin assumes there is a tty terminal discipline on each
> side of the connection, telnet does not
>
rlogin can carry your local user environment--terminal type being
only one of what can be carried over to the remote. Also, assuming
proper security equivalences are set up, you can use rlogin to
access a remote host without a password.
--
UUCP: {rutgers|ames|uunet}!mimsy!wb3ffv!fallst!tkevans
INTERNET: tkevans%fallst@wb3ffv.ampr.org
Tim Evans 2201 Brookhaven Ct, Fallston, MD 21047
-----------[000342][next][prev][last][first]---------------------------------------------------- Date: 30 Nov 92 15:02:59 GMT From: hwstock@snll-arpagw.llnl.gov (stockman harlan w) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: RAW SPEED numbers for various TCP-IP implementations
>> P.S. How would you rate 500KB/sec? > > >That depends on the medium. [...] > >P.S. Over ethernet 500KB/s would be poor for a modern workstation, but > common for a PC. As measured by `ttcp`. Ftp ttcp source from > brl.mil or sgi.com It may be possible to get >> 500 kB/sec in a "modern" network, with a moderate amount of traffic and direct connections, but in many older buildings retrofitted for ethernet, it is hard to be guaranteed > 100 kB/sec. I'm hooked up through a tranceiver in a building with about 200 users. I've monitored PC-workstation, workstation workstation, etc transfer rates, and find we rarely get above 100 kB/sec on a busy day. Many people leave long postscript print jobs for the wee hours, so it is hard to find any optimum time. Rates between two SGI workstations are no different than the rates (on average) between a workstation and a PC with an 8-bit, 8 MHz wd8003 card. That's life.
-----------[000343][next][prev][last][first]---------------------------------------------------- Date: Mon, 30 Nov 1992 12:17:10 IST From: Hank Nussbacher <HANK@BARILVM.BITNET> To: comp.protocols.tcp-ip Subject: Re: Rlogin vs. Telnet
In article <1992Nov30.060319.17880@candle.uucp>, root@candle.uucp (Bruce
Momjian) says:
>
>Having read Steven's "Unix Network Programming", what is the major
>difference between rlogin and telnet. Here are the differences I see:
>
> 1) rlogin is for unix-to-unix logins, telnet is for any tcp/ip
> computer
>
> 2) rlogin assumes there is a tty terminal discipline on each
> side of the connection, telnet does not
>
>Are there any other major differences, either in function or features?
From a document I once wrote up serving as a tutorial for terminal
servers:
The Rlogin command enables a user to log into a remote host
system by specifying the host system and a username that is
recognized by the host. There are advantages and disadvantages to
using RLOGIN rather Telnet to make a connection. At some hosts, the
RLOGIN implementation can be more efficient at terminating display
output from a program (i.e when you issue a <CTL C> command, the
user prompt is displayed faster with an RLOGIN connection than a
Telnet connection). However, since the RLOGIN protocol is not a
TCP/IP standard, RLOGIN is less widely available and is usually not
as well implemented as Telnet. For example, the RLOGIN protocol
does not typically support binary session modes, local echoing, or
features that are standard Telnet such as "Are You There?" and
"Synchronize".
>--
>Bruce Momjian | 830 Blythe Avenue
>root%candle.uucp@bts.com | Drexel Hill, Pennsylvania 19026
Hank Nussbacher
Israel
-----------[000344][next][prev][last][first]---------------------------------------------------- Date: Mon, 30 Nov 92 17:48:28 GMT From: sgriffee@nynexst.com (Steve Griffee) To: comp.protocols.tcp-ip Subject: responses: remote TCP/IP LAN ideas
ORIGINAL MESSAGE:
>> I'm looking for ideas for connecting remote PC and MAC workstations
>> to our TCP/IP LAN using regular dial-up phone lines. I've seen all
>> the usual asynch access devices. I'm looking at the relatively hi
>> bandwidth facilities such as ISDN. For example, so far I have
>> found out about the IMAC ISDN bridge made by DigiBoard and the RLN
>> asynch bridge (using hi speed modems and regular phone lines) made
>> by DCA which uses the PPP protocol. Has anyone else found any
>> interesting means of connecting remote offices or workstations to
>> the LAN? Let's swap discoveries. Can We Talk? Please respond
>> directly to my email address below. I will summarize all submitted
>> responses if requested.
>>
>> Watch out. Telecommuting may be just around the bend for your
>> company. Don't let it catch you asleep at the wheel.
>>
>> Thanks
>> Steve
>>
SUMMARIZED RESPONCES:
>From chrisv@cmc.com Sun Nov 22 14:08:20 1992
>Return-Path: <chrisv@cmc.com>
>
>Steve,
>You're exactly right about telecommuting begin right around the corner.
>But, from where we are today, we see that the remote branch office, typically
>occupied by sales or admin personnel, still need to connect in and
>they can't justify a cisco for $10K, a DDS circuit and all the other
>headaches of an enterprise routing solution. At the other side you have people
>who have been using SMARTCOM and all the other terminal emulation packages
>that are a pain in the neck when you try and do REAL network comuting such as
>native mail, file transfer and, heaven forbid, client server computing.
>This problem is eactly the reason why we have released our NetHopper product
>line which is uses V.32bis/V.42bis dialup now, and will use ISDN BRI in the
>***VERY*** near future as well. PLus, with V.FAST coming to a head in the
>standards process by the middle of 93 we can be getting 100 kbps over a phone
>line.
>Cheers,
>Chris VandenBerg
>Product Line Manager
>Rockwell International CMC Network Products
>125 Cremona Dr. Goleta, CA. 93117
>805-562-3127 fax - 805-968-6478
>email - vandenberg@cmc.com
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>From cmkilli@ns.PacBell.COM Thu Nov 19 22:16:00 1992
>Return-Path: <cmkilli@ns.PacBell.COM>
>
>Steve,
>I work for Pacific Bell on a project called Knowledge Network, where we are
>connecting K-14 Schools through our cisco System Hubs to the Internet. As
>part of the project I am also going to supply dial access using either SLIP
>or PPP protocol. I am currently working with a Telebit NetBlazer for SLIP/PPP
>over analog dial (up to 9600 v32bis, v42bis, & MNP5). For ISDN access I am
>working with Commdial boxes that provide a remote mac bridge function over 2
>ISDN B channels on an instant/on demand call set-up system (128Kb) and also
>a product called CommServer that provides 23 B channels to Ethernet mac bridge
>functionality. I am still in the lab test phases for a lot of this and would
>be glad to correspond with you on this.
>
>Buster Killion,
>Voicemail: (510) 823-6290
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>From johnb@kalpana.com Thu Nov 19 00:04:32 1992
>
>Steve,
>
> You might want to look at Telebit's NetBlazer line
>of dailup IP routers. When I worked there they were shipping
>dialup routers for standard lines (9600 baud-ish speeds), sync
>lines, and were working on ISDN. One the local side, they supported
>ethernet & token ring. They supported SLIP, PPP, and
>a plain raw mode you could kermit into. You can call them at (408)
>745-3200, or try email to fmueller@ telebit.com (fritz mueller)
>The Netblazers marketing guy. He should be able to help you out.
>
>They are in Sunnyvale California, USA, but I forget the exact
>street address.
>
>DISCLAIMER: I used to work on the NetBlazer. (but it seems to work
>anyway :-)
>
>====================================================================
>==
>John Bartas | Disclaimer - I don't speak for Kalpana
>Pricipal Software Engineer | in any official capacity. I'm just
>Kalpana, Inc. (408)988-1600x141 | an employee who reads the net.
>
>"We have met the enemy, and he is us." -Pogo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>From dcarr@donut.gandalf.ca Tue Nov 17 09:29:10 1992
>Return-Path: <dcarr@donut.gandalf.ca>
>
>We make 2 products in this category. At the low end, our 5510 is
>an ethernet/ISDN bridge. The 5510 can handle only 1 B-channel.
>At the high end, our 5220 ethernet bridge (which requires an external
>ISDN terminal adapter) offers dual B-channels with DATA COMPRESSION.
>A software upgrade is in progress to add V.25 bis dialing capabilities
>to the 5220 and bandwidth on demand. That is, we'll bring up the
>first B-channel only when there's packets to bridge, and the second
>link when there is sufficient load, etc.
>
>Also in the works is a remote ISDN access system. At the central site
>you have one "pizza box" with up to 4 T1 inputs, and an ethernet out.
>Or, up to 128 B-channels with stackable expansion.
>
>>Watch out. Telecommuting may be just around the bend for your
>>company. Don't let it catch you asleep at the wheel.
>
>We were actually ISDN ready a couple of years ago. Boy the money we
>could have made had ISDN been deployed.
>--
>Dave Carr | dcarr@gandalf.ca | It's what you learn,
>Principal Designer | TEL (613) 723-6500 | after you know it all,
>Gandalf Data Limited | FAX (613) 226-1717 | that counts.
>
>From emv@garnet.msen.com Tue Nov 17 01:06:32 1992
>Return-Path: <emv@garnet.msen.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>Steve,
>
>Msen offers a number of these services to our customers; if you send
>mail to 'info@msen.com' we'll ship you the current list of services etc.
>
>I'm waiting for a call back from Mi Bell about ISDN, but for the moment
>we tend to use dialup PPP stuff.
>
>
> Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
> Msen Inc., 628 Brooks, Ann Arbor MI 48103 +1 313 998 GLOB
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>From ss@panix.com Mon Nov 16 23:35:22 1992
>Return-Path: <ss@panix.com>
>
>I'm no expert on the topic and I'm not familiar with the above mentioned
>ISDN hardware but here are my thoughts:
>
>If we're talking telecomputing,shouldn't the discussion lean towards
>leased lines? Wouldn't it be cheaper then a 8 hour dialup connection?
>I would guess that PPP at 64k would handle most applications on a
>single PC. I think Morningstar has some hardware to do this.
>
>Does the user really need a PC? How about leaving the PC at the office
>running PCAnywhere and give the user a vt100 ?
>
>>Watch out. Telecommuting may be just around the bend for your
>>company. Don't let it catch you asleep at the wheel.
>
>Don't forget: 186,000 miles/second isn't just a good idea, it's the law!
>
>--
>====================================================================
=
>=== Steve Steinberg == ss@panix.com == {cmcl2,apple}!panix!ss ===
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>From w8hd!w8hd!kimc@vela.acs.oakland.edu Mon Nov 16 20:00:18 1992
>Return-Path: <w8hd!w8hd!kimc@vela.acs.oakland.edu>
>
>I have just installed Morningstar PPP on a Sun Sparc and according
>to the docs it should do exactly what you want to connect the
>tcp-ip lan to async. It can do this with a machine's native serial ports
>so 'nothing more to buy.' If you need more/faster ports on a Sun, they work
>closely with Magma, which produces S-Bus expansion boards at low cost.
>They also have really excellent support if you should need it.
>Morningstar: 800-558-7827
>Contact: Dean Schell
>regards
>kim culhan
>------
>kimc@w8hd.org
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>From LEONARD@Arizona.edu Mon Nov 16 19:51:18 1992
>Return-Path: <LEONARD@Arizona.edu>
>
>Hi Steve,
>
>Well, I don't work for the phone company, so please forgive me if
>I'm skeptical about ISDN. (At any rate, I'm *extremely* skeptical
>that USWest will be able to deliver ISDN to a significant fraction of
>the walljacks in Tucson, with a reasonable tariff, within the next
>five years; it may well be that NYNEX will do better.)
>
>So my view is that Plain Old Analog voice lines is the best we'll be
>able to use, in the next several years, as far as delivering dynamic
>network connectivity to the rank and file of telecommuters.
>
>My experience is that the best bet for right now and the next year
>or two is to use commodity V.32bis/V.42bis modems, such as
>MultiTech MT1432s. Our testing shows that these can deliver
>13-32Kbps in real world applications. In the future, V.fast/V.42bis
>modems should be able to deliver 24-70Kbps of real throughput,
>which should to a large extent obviate the need for ISDN. (I don't
>deny that ISDN would be *better*; I simply don't see it happening
>in the local loop real soon.)
>
>On the backbone side, our plan is to plug the modems into serial ports
>on comm servers, with the RS232 port set to 38.4Kbps. (57.6Kbps or
>faster would be nice, especially when V.fast becomes an economic
>reality, but the comm servers we have [Xylogics Annex 3's] will only
>do 38.4.)
>
>The idea is to have the comm servers do dynamic dialup SLIP (or, in
>the future, PPP), by letting the user enter a hostname/password
>combination. It is important that the IP address assigned to the modem
>connection NOT be tied to the serial port, because that would cause the
>user to get a different IP address each time he connects. We prefer
>to give our users a "real host name", so that they can use things like
>rlogin, to pick up mail, etc.
>
>On the PC side, the user can use a script to handle the dialing, issuing
>the hostname/password, and switching into SLIP mode.
>
>We find that this works well for TELNET (wow!) and FTP. Using X11 is
>something of an issue... this speed is just NOT really fast enough.
>It would seem that NCD's Xremote protocol is the champion here.
>Some people (e.g. cisco) are putting Xremote on their comm servers.
>(A software engineer from cisco told me that he was using an X terminal
>over a 9.6Kbps modem link into a comm server, running Xremote, and
>that it worked well enough to keep him happy, which impressed me
>quite a bit.) Others are recommending running the Xremote server
>on a host on the backbone side, which may make more sense.
>
>I'm interested in seeing your summary ... good luck,
>
>Aaron
>
>Aaron Leonard (AL104), <Leonard@Arizona.EDU>
>University of Arizona Network Operations, Tucson AZ 85721
> "It's not a bug, it's a form of flow control."
> - Jerry Leichter on why crash-prone Unix is a suitable
> platform for NSFNET core routers
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>From ittai@ans.net Mon Nov 16 18:17:46 1992
>Return-Path: <ittai@ans.net>
>
>Steve,
>
>ANS has recently announced ANSremote service so that our leased-line
>attachment customers (such as NYNEX S&T) can dial-in to their home
>system from anywhere in the continental US with a convenient 1-800
>number. Initially, we are only supporting virtual terminal services
>(i.e. telnet and rlogin) but plan to introduce full SLIP/PPP services
>in early 1993.
>
>I would also be interested in offering an ANRemote-ISDN service in
>the NY area when/if NY Tel will deploy 2B+D at a reasonable tariff.
>
>-Ittai
>---------------
>
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>From bair@america.Telebit.COM Mon Nov 16 18:14:56 1992
>Return-Path: <bair@america.Telebit.COM>
>
>Hello Steve,
> If your running an IP based network, the NetBlazer is probobly the answer
>your looking for. It is the 1st dialup router and can work with a variety
>of topologies and access methods.
> By that, I mean it can be on a thick, thin, or twisted pair ethernets or
>shielded or unshielded 4/16 mbit token rings. Access can be had via dial up
>modems, T/As for ISDN, or switched 56 services and provide either terminal
>services or routing services. It supports SLIP or PPP on its async ports
>and on the the sync port, PPP. Telebit has also announced that in January,
>Novell and Appletalk routing will also be supported as well as multiple sync
>ports for speeds to T1/E1!
> Your local Telebit office is in Melville, NY. They can be reached by
>calling them at 1 516 420 0560.
>
>I hope that this has been helpful.
>
>Sincerely:
>
>Scott Bair
>Systems Engineer
>Telebit Corporation
>bair@telebit.com
>
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>From pollard@vtserf.cc.vt.edu Mon Nov 16 16:40:29 1992
>Return-Path: <pollard@vtserf.cc.vt.edu>
>
>Steve,
>
>I haven't tried it myself, but I have a spec sheet here on the "Combinet
>INTERCHANGE ISDN LAN adapter" that sounds like what you're looking for.
>I don't have much detail on the above, but you can try contacting the
>sales guy who sent me the info: Ray Thompson @ CLC Associates. 800 394-CLCA
>or at his desk @ 804 922-7601, or 7784.
>
>John Pollard
>Virginia Tech
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>nelson Mon Nov 23 10:01:04 1992
>From: nelson@crynwr.com (Russell Nelson)
>
>In article <1992Nov16.191510.474@nynexst.com> sgriffee@nynexst.com writes:
>
> Watch out. Telecommuting may be just around the bend for your
> company. Don't let it catch you asleep at the wheel.
>
>Holy shit, Steve, is NYNEX just figuring this out?!?!???
>
>No wonder It Still Does Nothing in New York.
>
>Sorry for the gratuitious flamage, but maybe that's what the baby
>bells need?
>
>-russ <nelson@crynwr.com> What canst *thou* say?
>Crynwr Software Crynwr Software sells packet driver support.
>11 Grant St. 315-268-1925 Voice | LPF member - ask me about
>Potsdam, NY 13676 315-268-9201 FAX | the harm software patents do.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Thank you to all those who responded to my request for ideas. For the most
part the responses were constructive and very helpful. I hope that sharing
the results will be useful to others who are engaged in similar ongoing
quests like mine. 1993 should be a very interesting year in the northeast,
especially for those waiting patiently for ISDN. I expect to be ready for
it.
Happy Holidays.
Steve
--
The opinions above are my own and do not reflect those of my employer.
_________________________________________________________________
Steve Griffee sgriffee@nynexst.com NYNEX Science and Technology
Data & Information Services 500 Westchester Avenue
-----------[000345][next][prev][last][first]---------------------------------------------------- Date: Mon, 30 Nov 92 17:57:37 GMT From: scott@tdc.rtp.dg.com (John Scott) To: comp.protocols.tcp-ip Subject: Re: FTP: Send 8 1K packets, then wait.....
In article <BARNETT.92Nov25130830@grymoire.crd.ge.com>, barnett@grymoire.crd.ge.com (Bruce Barnett) writes:
|> I am analyzing some medical networks, and I see a common pattern in
|> large file transfers using FTP. Could someone tell me if this sounds
|> like a bsd4.2, or bsd4.3 implementation of TCP.
|>
|> The sending system sends 8 1K packets. The delay is about 2
|> milliseconds between packets. The last packet has a "Push"
|> flag. An ack comes back. Then the sender waits a while, typically
|> 40-100 milliseconds, and sends out 8 more packets.
You don't say how much the ACK acknowledges. I suspect not all of the
8k is acknowledged. Is there another ACK from the receiver before
the sender transmits any more packets.
|>
|> The outgoing WIN size is 8K. The receiving window is 24K. The network
|> is not causing a bottleneck. The system is not using IP fragments,
|> nor large window sizes on the sends. This sounds like an early
|> implementation of TCP, on a slow CPU. Typically 84KB/sec over
|> ethernet. Any guesses on why it is so slow?
|> It might be a Sun 3 running SunOS 3.5.
I have experimented with data throughput between our AViiON systems and
SUN 3/50s running some version of SunOS (sorry don't remember the revision).
I found that when the receive buffer was much larger than the transmit buffer
(in my case 8k receiver and 4k transmitter), the BSD acknowledgement algorythm
together with the SunOS write flowcontrol scheme would catch the SUN 3/50
transmitter in such a way as to have an open window but have no new data to
send. As soon as the receiver sent a delayed acknowledgement for the rest
of the data, the SUN was able to unblock the socket and get more data from
the application.
If you have the application source, you could use setsockopt() to resize the
send buffer to match that of the peer's receive buffer (or vice versa). Another
method you might try is patching the kernel to use a larger default socket buffer
size.
Hope this helps.
|>
|> (This system is on the other coast. I'm analyzing the output of a
|> tcpdump file that was mailed to me.)
|>
|>
|> --
|> Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
--
+------------------------------------------------------------------+
| John A. Scott | Phone: +1 919 248 5995 |
| Data General | Email: scott@dg-rtp.dg.com |
| 62 TW Alexander Drive | |
| Research Triangle Park, NC 27709 | |
+------------------------------------------------------------------+
-----------[000346][next][prev][last][first]---------------------------------------------------- Date: Mon, 30 Nov 1992 18:31:27 GMT From: spexet@math.lsa.umich.edu (D. Robert Spexet II) To: comp.protocols.tcp-ip Subject: Re: NSFNet goes to hell..
In article <avalon.722609758@coombs> avalon@coombs.anu.edu.au (Darren Reed) writes: >After watching the NSFnet almost goto pieces in the last hour >or so, I'd like to know if there is any way 'outsiders' can get >info on when upgrades/maintainence is planned or even fault reports >are sent. Someone suggested "nsr" to me but that seems to be an >"in-house" list only. Are there any other offerings or are those >who use/rely on the network expected to put up with the route >between A and B changing every 5 minutes ? (Surprisingly not all >network kernels/programs can handle what goes on and this results >in interruptions for almost anything which uses TCP). >p.s. This isnt as rare as some people would have others belive, just > mostly seems to happen when most of the USA is asleep and the > rest of us are awake....well most of the time anyway... It also happens a lot on Saturdays. -- D. Robert Spexet II, N0OKR Internet: spexet@umich.edu Department of Mathematics BITnet: user68xr@umichum.bitnet The University of Michigan UUCP: uunet!mailrus!math.lsa.umich.edu!spexet Ann Arbor, Michigan 48109
-----------[000347][next][prev][last][first]---------------------------------------------------- Date: Mon, 30 Nov 1992 19:09:04 GMT From: mitton@dave.lkg.dec.com (Dave Mitton) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Does Ethernet into Token Ring go?
>In article <1992Nov28.061936.14440@ohsu.edu>, bj@steele.ohsu.edu (Bill Jackson) writes: >From: bj@steele.ohsu.edu (Bill Jackson) >Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip >Subject: Does Ethernet into Token Ring go? >Date: 28 Nov 92 06:19:36 GMT > >I am looking for experiences in, or references to information on, moving a >large Ethernet installation onto a 16M Token Ring backbone. The TR is already >supporting approx 800 PC's running NetWare and TCP/IP, and the Ethernet has >about the same number of various workstations running almost everything you can >think of, including OSI protocols. > >The Ethernet needs to be upgraded, as it is currently all bridged and the >bridges are becoming a throughput bottleneck, not to mention too much chatty >traffic going too far! I am looking at the possibility of joining onto an >existing 16M TR and cutting down the number of protocols to NetWare, TCP/IP, >EtherTalk and some DECNET. I will keep the Ethernet hardware at the >stations, and use either NetWare or other (better!) routers to handle traffic >onto the TR backbone. > >I have a few questions about this strategy: >Will it WORK? >Is the Ethernet traffic going to create any problems? >Is there any way to predict the resultant loading on the TR? >When subnetting, what is the recommended # of devices (ie subnet mask) on the >token ring (4M) and Ethernet (10M) subnets? Bill, simply changing technology is not going to make your loading problem go away. It may just compound them. Packets are packets. If your Ethernet bridges are becoming the bottleneck, you better look out for the performance of Token Ring bridges! The TR bridge products are a bit less mature than Ethernet bridges and tend to under-perform the media. (probably mostly due to the nature of the current TR media chips) I suggest you review Scott Bradner's test results on routing and hunt up copies of the following Data Communications magazine articles: - "Remote Token Ring Bridges: Plug and Play or Plug and Pay?" Aug 1991 - "Remote Token Ring Bridges: DATA COMM Defuses Vendor Performance Claims" Sept 21 1991 - "Bridge Vendors Would Rather Fight than Fix" Jan 1992 My recommendation would not be to migrate your network, but attempt to divide it up into managable pieces. Multiprotocol Routers would help this task immensely. While a Novell NetWare Server can route IPX traffic expecting it to do that while being a file server is a bit much. A dedicated router box provides a more reliable and dependable infrastructure. Multiprotocol Routers are availible from a number of vendors these days. We support the Proteon products for DECnet connection to Token Ring. Other popular vendors are Cisco, Wellfleet, and Novell entering the market. Multiprotocol Routers will contain broadcast and multicast "chatter" to the routed areas of the network, and only forward packets in the proper direction. They also provide an administrative point-of-control. Dave Mitton Token Ring Program Networks and Communications Digital Equipment Corp. Disclaimer: my opinions are not necessarily those of Digital's and may be a bit biased. ;-)
-----------[000348][next][prev][last][first]---------------------------------------------------- Date: 30 Nov 1992 21:27:58 GMT From: trier@slc6.ins.cwru.edu (Stephen C. Trier) To: comp.protocols.tcp-ip Subject: Re: Connection comes up halfway and drives me nuts,
"Connection came up half-way and then closed" is MacTCP's user-friendly error, meaning the same as the ever-so-much-more-confusing BSDish "Connection refused". As to what specifically is going wrong, I can't tell. You didn't post enough specifics. Make sure the Unix host accepts FTPs, make sure you are using the right ports, and try FTPing in from another system to make sure everything works. Try watching everything on a network analysis program to see how the connection opening dialog is working as well as to make sure you are opening it to the correct FTP port (port 21). -- Stephen Trier It's either very surprising Network Services Engineering, IRIS/INS/Telecom or not surprising at all. Case Western Reserve University Let me think about it. trier@ins.cwru.edu - Palmer Davis
-----------[000349][next][prev][last][first]---------------------------------------------------- Date: 30 Nov 92 22:19:42 GMT From: manmetha@gauss.rutgers.edu (Rajesh Malhotra) To: comp.protocols.tcp-ip,comp.protocols.ppp Subject: PPP on MAC? Also FTP sites for RFCs.
Fellow Netters,
Couple of questions,
1. Is there a PPP package available on a MAC? (PD or commercial)
2. Is there a FTP site from where RFCs can be downloaded? I believe
there is an address also where mail can be sent and RFCs returned.
Any and all responses appreciated, Thanx,
Raj.
--
===============================================================================
__ __ .
/ __/ / Raj Malhotra.
/ ( /_ / voice : (908)613 4313.
__/ email : manmetha@gauss.rutgers.edu
===============================================================================
-----------[000350][next][prev][last][first]---------------------------------------------------- Date: 30 Nov 92 22:32:36 GMT From: chris@suite.sw.oz.au (Chris Maltby) To: comp.protocols.tcp-ip Subject: Re: NSFNet goes to hell..
In <MS-C.722912691.1103527590.mrc@Ikkoku-Kan.Panda.COM> mrc@Ikkoku-Kan.Panda.COM (Mark Crispin) writes: >It is a lot easier -- and probably a lot more reliable given the possibility >of routing loops -- for the packet to be dropped and let the originator's TCP >retransmit. The ICMP Unreachable is simply a courtesy. So is there an ICMP return which means "absolutely no way to this destination"? Or do you have to prod a few times and after enough Network Unreachables you can safely give up? It seems to me that the gateways which can switch routes to balance loads can also return the equivalent of EAGAIN, meaning "I'm dropping this datagram because it's the best thing under the circumstances but I'm not making any statement about the likelihood of sucess or failure if you try again." If that is Network Unreachable, how are they to say "forget it, I have no idea how to get there"? Is there an RFC which covers this level of semantic detail? Enquiring minds... -- Chris Maltby - Softway Pty Ltd Internet: chris@softway.sw.oz.au PHONE: +61-2-698-2322 "I'm waiting for X-Windows to become just that; FAX: +61-2-699-9174 Ex-Windows" - A McGrath.
-----------[000351][next][prev][last][first]---------------------------------------------------- Date: 30 Nov 1992 22:54:22 GMT From: bansal@cis.ksu.edu (Vivek Bansal) To: comp.protocols.tcp-ip Subject: Server Port No....
I have written this client-server application in which basically the server waits on a fixed port no (5000) waiting for requests from different clients. Now, while the server was running I had to kill it by doing a Control-C, and then when I tried to rerun the server I got the message that , Socket No 5000 already in use. How do I get over this problem ??? I thought once a process was killed all the ports used by it were immediately released .... Thanks... Vivek...
-----------[000352][next][prev][last][first]---------------------------------------------------- Date: 30 Nov 92 23:34:08 GMT From: bhoule@npg-sd.SanDiegoCA.NCR.COM (Bill Houle) To: comp.protocols.tcp-ip Subject: Re: TCP/IP, Windows 3.1, and Mounted File Systems
John MacLean (johnmac@fawlty.towers.oz.au) wrote: > What options are available to have file systems mounted under MS-Windows 3.1, > from a UNIX box, and having TCP/IP active simultaneously? Wollongong Pathway Access + Pathway NFS gives you this capability. I've also done the above + Novell with no problems. -- Bill Houle bhoule@npg-sd.SanDiegoCA.NCR.COM NCR NPD-San Diego (619) 693-5593
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |