|
|
ARCHIVE: TCP-IP Distribution List - Archives (1993)
DOCUMENT: TCP-IP Distribution List for July 1993 (469 messages, 286644 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1993/07.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Thu, 1 Jul 1993 04:49:31 GMT From: catstyle@gofish.aiss.uiuc.edu (Jason R. Heimbaugh) To: comp.protocols.tcp-ip Subject: Anyone offering DNS for a .org site?
Is anyone offering DNS for a .org? I know that there used to be someone at DEC (or similar) that would do it for $5/year. Is he still around, or is someone else offering the same for a nominal price? Thanks, -- Jason R. Heimbaugh jrh@uiuc.edu
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Thu, 1 Jul 93 10:30:23 GMT From: oberman@ptavv.llnl.gov To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was RFC 1191 compliance)
In Article <rturner.741550521@imagen> rturner@imagen.com (Randy Turner) writes: > And while all of this sounds like a wonderful speedup, it > shoots down the usual layered approach to network software, in that > we have taken functions of the transport layer and embedded that > functionality in what normally would be the data link layer. There > would also have to be additional logic to handle a multi-protocol stack > implementation over this network interface , meaning the hardware would > have to be able to detect that the packet is a UDP/TCP packet > before doing the summing , if I understand what you are describing. 1. We're talking real world, not standards committees here. Perfect layering is really a myth in every system I've ever worked with. 2. IP predates the OSI model by some years and doesn't really fit it well.. 3. Tell me, which layer is ICMP in? Are you really sure about that? R. Kevin Oberman Lawrence Livermore National Laboratory Internet: koberman@llnl.gov (510) 422-6955 Disclaimer: Being a know-it-all isn't easy. It's especially tough when you don't know that much. But I'll keep trying. (Both)
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 93 14:10:28 GMT From: black@ll.mit.edu (Jerry Glomph Black) To: comp.protocols.tcp-ip Subject: TCP/IP over satellite T1
We're setting up a satellite T1 link at full bandwidth for certain bulk data transfers [usually the data only gets 1/24 of the bandwidth, the rest is voice/fax]. In our tests (with the usual 560 ms round-trip time) we are getting well under the expected FTP rate of 130 kBytes/sec (actually, about 25% of this rate!). It appears that the limiting factor is the TCP window size (we're losing a lot of time waiting for acknowledgements). You've undoubtedly run into this kind of problem, how is it usually solved? We're trying to do transfers between various TCP hosts, usually Suns and SGIs. I'd like to avoid special-purpose kludge drivers to keep file transfers universal. Thanks, Jerry Jerry G. Black, MIT Lincoln Laboratory, Lexington MA black@LL.MIT.EDU
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Thu, 1 Jul 1993 15:22:17 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was RFC 1191 compliance)
In article <rturner.741475245@imagen>, rturner@imagen.com (Randy Turner) writes: > vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > ... > >Hardware assist for TCP checksumming is a bit of a hassle on output, > >because you need to stuff the checksum for the whole packet into the > >front of the same packet. Hardware assist for received packets is > >trivial, and requires no more than the 16-bit sum of the entire > >packet. Clear the adder at the start of the packet, and fetch its > >contents at the end. If you have an odd byte, don't bother to add it, > >or zero fill and add it. (Yes, all that sums too much or too > >little, but is no problem. Everyone please think about how the TCP > >checksum works before arguing with me about that detail.) > > The thing that really complicates the issue of optimizing the > checksum through means described above is the fact that a > pseudo-header has to be formed and checksummed first..... > It's not just a straightforward summing of a packet as an > additional bit of logic in an ASIC for Ethernet DMA... Depending on what is meant, that is false. Of course you add the checksum of the psuedo-header, just like any TCP implementation. You need not handle the psuedo-header first. Remember that cksum(A+B)-cksum(B)=cksum(A). Hardware support for input TCP checksum is absolutely trivial, subject only to contraints on the speed of the adder(s) compared to the speed of the medium. I'm not talking about academic theories. The most recent SGI FDDI card for SGI's low cost workstations has been shipping in volume for some time. Vernon Schryver, vjs@sgi.com
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Thu, 1 Jul 1993 15:34:41 GMT From: emurphy@cs.uno.edu (Edward Murphy) To: comp.protocols.tcp-ip Subject: (?) is Dlink DE-200 an NE2000 clone?
Howdy. Is the D-Link DE200 similar enough to an NE2000 so that the driver program for an NE2000 will work? Ed Murphy
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Thu, 1 Jul 1993 15:44:45 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: TCP/IP over satellite T1
In article <1993Jul1.141028.8433@ll.mit.edu>, black@ll.mit.edu (Jerry Glomph Black) writes: > We're setting up a satellite T1 link at full bandwidth > for certain bulk data transfers [usually the data only gets 1/24 of the > bandwidth, the rest is voice/fax]. > > In our tests (with the usual 560 ms round-trip time) we are getting well > under the expected FTP rate of 130 kBytes/sec (actually, about 25% of this > rate!). It appears that the limiting factor is the TCP window size (we're > losing a lot of time waiting for acknowledgements). > > You've undoubtedly run into this kind of problem, how is it usually solved? > We're trying to do transfers between various TCP hosts, usually Suns and > SGIs. I'd like to avoid special-purpose kludge drivers to keep file transfers > universal. The default TCP/IP window on SGI boxes is 61440, 60*1024, about as big as you can make it. (Big windows help TCP over FDDI.) You can adjust the default TCP window size on SGI boxes by changing tcp_recvspace and tcp_sendspace in /usr/sysgen/master.d/bsd. I think there was a way in some Sun kernels to edit a file to change the default TCP window. You could also use adb to edit /vmunix or the running kernel. You can also use setsockopt(SO_SNDBUF) and setsockopt(SO_RCVBUF) in SGI and presumably Sun systems to adjust the TCP window for a single TCP connection. If you use `rcp` to transfer files, you can put a small program out of ~guest/.cshrc (or whatever) to apply those setsockopt()'s to standard input. (Recall that `rcp` uses an ordinary shell via the `rsh` protocol.) Big windows are bad for wide area links, causing Bad Things in router queues, and I've been distributing a quick hack program that adjusts windows inside the SGI network to reduce the harm of 60K windows over 56K and T1 circuits. I'll send source if you want it, but it really is trivial. Vernon Schryver, vjs@sgi.com
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Thu, 1 Jul 1993 16:01:03 GMT From: erick@sunee.uwaterloo.ca (Erick Engelke) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was RFC 1191 compliance)
jkay@cs.ucsd.edu (Jon Kay) writes: > >> How many of those disk problems produced undetected errors? > > I ran into one just last week on our server. I found a bogus >directory that had been copied by tar from another directory without >passing over a network. What produced it? So long as it's not the >network (which it wasn't), my argument remains intact. It was >undetected for months; I only ran noticed it by sheer accident. I'm actually in an excellent position to answer this question. Glancing up I see status monitors constantly reporting on the forty-two network servers I manage. Though our system is trivial, providing disk service rather than fileservice, it gives an excellent opportunity to answer this sort of question. Our diskservers report all disk CRC errors, all network checksum and other network errors, and they checksum physical memory in all background cycles (ie. most of the time) because we keep all data structures in memory checksummed. In other words, all parts of the system are monitorred separately. What I have said so far does not answer your question about end-to-end integrity, but this does: On those servers there are a total of approximately 30,000 disk sectors which the server checksums on every read and write. Though these special sectors constitute less than 0.05 % of the total disk space, they are distributed relatively evenly over the many disk surfaces (they are control blocks preceding each virtual disk space), so they give an excellent idea of exactly what you ask. These sectors are checked to provide user privileges very frequently, and each is read at least once a day by the daily-save proceedure to see if there has been any activity in the next few blocks which may need to be archived. Sooooo, the results are surprisingly in favour of believing the CRC. We keep track of all CRC errors and have found that they appear very frequently in the same day whenever we get a checksum error on the checksummed blocks. So if you get a few CRCs, and your OS reports them to you, start orderring a spare drive because this one will be going to the shop soon. Our experience is that the CRC is not perfect, but that errors tend to appear in clumps, and the CRC detects many of them, enough for you to put your emergency plan into action. Check your backups, check your data, you've been given advance notice of an impending failure. Of course, that only applies to OS's which keep track of the CRC failure status. As for the lightning strikes, blizzards happen attitude, a UPS solves that for anyone willing to spend the money. Erick --
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Thu, 1 Jul 1993 16:48:43 GMT From: robc@splinter.synnet.com (Rob Ciampa) To: comp.protocols.tcp-ip Subject: TLI, Streams, and other events
|> In article <1993Jun25.153006.20899@lmpsbbs.comm.mot.com>, gulik@rtsg.mot.com (Gregory Gulik) writes: > In article <1993Jun25.032827.8335@sporran.uucp> tim@sporran.uucp (Tim Fry) writes: |> > > |> > >Since the TLI is layered on top of streams, you can use poll(2) to check for |> > >events on multiple file descriptors. Check the man page. I believe there |> > >is an example in the standard AT&T TLI programmers guide. |> > |> > poll() only works on streams devices. |> > I need to be able to watch for input on a serial port. |> > Although later implementations of poll() in SVR4.x will solve the problem of handling different descriptor types, users of older releases (like SunOS 4.x) should probably be blocking on events like read() and select(). Streams events can interrupt these calls by registered file descriptors for SIGPOLL and letting the interrupt handler invoke the poll() - non-blocking, of course. Many users have been apprehensive about mixing streams events and non-streams events, but the implementation is rather straightforward. It's also a great way to implement TCP/IP client-server applications with TLI-based data link interfaces. -- Robert A. Ciampa (robc@synnet.com) Synernetics 85 Rangeway Road North Billerica, MA 01862 (508) 670-5488
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 93 18:15:21 GMT From: rturner@imagen.com (Randy Turner) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was RFC 1191 compliance)
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >In article <rturner.741475245@imagen>, rturner@imagen.com (Randy Turner) writes: >> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >> ... >> >Hardware assist for TCP checksumming is a bit of a hassle on output, >> >because you need to stuff the checksum for the whole packet into the >> >front of the same packet. Hardware assist for received packets is >> >trivial, and requires no more than the 16-bit sum of the entire >> >packet. Clear the adder at the start of the packet, and fetch its >> >contents at the end. If you have an odd byte, don't bother to add it, >> >or zero fill and add it. (Yes, all that sums too much or too >> >little, but is no problem. Everyone please think about how the TCP >> >checksum works before arguing with me about that detail.) >> >> The thing that really complicates the issue of optimizing the >> checksum through means described above is the fact that a >> pseudo-header has to be formed and checksummed first..... >> It's not just a straightforward summing of a packet as an >> additional bit of logic in an ASIC for Ethernet DMA... >Depending on what is meant, that is false. Of course you add the >checksum of the psuedo-header, just like any TCP implementation. >You need not handle the psuedo-header first. >Remember that cksum(A+B)-cksum(B)=cksum(A). >Hardware support for input TCP checksum is absolutely trivial, subject >only to contraints on the speed of the adder(s) compared to the speed >of the medium. >I'm not talking about academic theories. The most recent SGI FDDI >card for SGI's low cost workstations has been shipping in volume for >some time. >Vernon Schryver, vjs@sgi.com Right, that's what I was saying, that there is more to the implementation than just summing the data portion in hardware. After that's done, there is still some pseudo-header construction and summing to be done in software. And while all of this sounds like a wonderful speedup, it shoots down the usual layered approach to network software, in that we have taken functions of the transport layer and embedded that functionality in what normally would be the data link layer. There would also have to be additional logic to handle a multi-protocol stack implementation over this network interface , meaning the hardware would have to be able to detect that the packet is a UDP/TCP packet before doing the summing , if I understand what you are describing. Randy -- ----------------------------------------------------------------------------- Randy Turner QMS, Inc. rturner@aqm.com
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Thu, 1 Jul 1993 18:21:06 GMT From: gcamp@evtech.com (Glen Campbell) To: comp.protocols.tcp-ip Subject: Re: New Yorker cartoon
In article <20sc1a$kmr@calvin.NYU.EDU> roy@mchip00.med.nyu.edu (Roy Smith) writes: >From: roy@mchip00.med.nyu.edu (Roy Smith) >Subject: New Yorker cartoon >Date: 30 Jun 1993 15:38:18 GMT > It would seem the Internet has finally really made it into the >popular press. The 1993 July 5th New Yorker has a cartoon (page 61) of two >dogs. One is sitting at a computer terminal, saying to the other, "On the >Internet, nobody knows you're a dog". >-- >Roy Smith <roy@nyu.edu> >Hippocrates Project, Department of Microbiology, Coles 202 >NYU School of Medicine, 550 First Avenue, New York, NY 10016 >"This never happened to Bart Simpson." It does make one wonder about who has time to make all these postings I'm reading... Glen Campbell (gcamp@evtech.com)
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Thu, 1 Jul 1993 18:22:17 GMT From: raj@cup.hp.com (Rick Jones) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was RFC 1191 compliance)
Vernon Schryver (vjs@rhyolite.wpd.sgi.com) wrote: : I'm not talking about academic theories. The most recent SGI FDDI : card for SGI's low cost workstations has been shipping in volume for : some time. Nor is Vernon talking SGI specific. Two of the three FDDI cards from HP (Series 800 NIO, and Series 700 Integrated), offer either both out/in, or in checksum offload. rick jones
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 1993 18:32:21 GMT From: bcarter@magnus.acs.ohio-state.edu (Bryan D Carter) To: comp.protocols.tcp-ip Subject: Finding IP #s
Greetings...
I'm not sure if this is right place to ask this, but here goes.
Could someone please give me some information on how to determine
what a site's IP address is if all you have is a system name
ie:bluemoon.use.com and a user name ie:jdoe@bluemoon.use.com? When
I try to finger/whois the system I get something to the effect of
"no host found, try using the host IP address" as an error.
I know the system is in the UUCP map because I've check in there,
but that doesn't give me an IP# either.
Any help would be appreciated, please send any replies via e-mail.
Thanks...
Bryan Carter
bcarter@magnus.acs.ohio-state.edu
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 1993 19:57:46 GMT From: drawbridge@sc.tamu.edu To: comp.security.misc,alt.security,comp.unix.admin,comp.protocols.tcpip,comp.sys.sun.admin Subject: TAMU Security Package Update
Texas A&M Network Security Package Update
7/1/93
Dave Safford
Doug Schales
Dave Hess
This is an updated release of the security tools developed at the
Texas A&M University Supercomputer Center. These tools are available
for anonymous FTP from sc.tamu.edu:/pub/security/TAMU.
------------------------------------------------------------------------
CHANGE SUMMARY (see respective README files for more information):
'tiger' - Version 2.1.1 - UNIX security checking tool
An explain facility for giving more information on the output from
tiger. Many new checks, bug fixes, all around improvements. Too
numerous to go into. Briefly, checks mail aliases, cron jobs, inetd
configuration, PATH variables, more checks on passwd and group files.
Untested initial configuration files for AIX 3, IRIX 4, HPUX and
UNICOS. Tested configurations for SunOS 4.1.1, 4.1.2, 4.1.3, 5.1 and
5.2, including signatures for latest security patches, and NeXTSTEP 3.0.
'netlog' - Version 1.02 - Network traffic logging tools
Bug fixes, minor enhancements to functionality. New tool for gathering
statistics on protocol and port usage.
'drawbridge' - Version 1.1 - IP bridging filter
Bug fixes. Allow and reject clauses did not work properly and bridging
was not working efficiently.
'check_TAMU' - TAMU Security distribution check script
A new script is now available for checking this distribution for any signs
of tampering. This is intended for anyone who obtains this distribution from
a site other than sc.tamu.edu. The script is available from a mailserver at
"drawbridge-server@sc.tamu.edu". See the section AVAILABILITY below for more
info.
------------------------------------------------------------------------
ORIGINAL DESCRIPTION:
Last August, Texas A&M University UNIX computers came under extensive
attack from a coordinated group of internet crackers. This package of
security tools represents the results of over nine months of
development and testing of the software we have been using to protect
our estimated five thousand IP devices. This package includes three
coordinated sets of tools: "drawbridge", an exceptionally powerful
bridging filter package; "tiger", a set of convenient yet thorough
machine checking programs; and "netlog", a set of intrusion detection
network monitoring programs.
KEY FEATURES:
For full technical details on the products, see their individual README's,
but here are some highlights:
DRAWBRIDGE:
- inexpensive (PC with two SMC/WD 8013 cards)
- high level filter language and compiler
- powerful filtering parameters
- DES authenticated remote filter management
- O(1) table lookup processing even with dense class B
net filter specifications.
TIGER:
- checks key binaries against cryptographic
checksums from original distribution files
- checks for critical security patches
- checks for known intrusion signatures
- checks all critical configuration files
- will run on most UNIX systems, and has tailored
components for SunOS, Next, SVR4, Unicos.
NETLOG:
- efficiently logs all tcp/udp establishment attempts
- powerful query tool for analyzing connection logs
- "intelligent" intrusion detection program
AVAILABILITY:
This package is available via anonymous ftp in
sc.tamu.edu: pub/security/TAMU
Due to the sensitive nature of these tools, we recommend that you
retrieve them from this location. If you do not get them from
sc.tamu.edu we suggest that you use our check_TAMU script that uses
cryptographic checksums to check the distribution for any signs of
tampering. The script is available in the anonymous ftp directory above
and from an e-mail server at:
drawbridge-server@sc.tamu.edu
Note that there are some distribution limitations, such as the
inability to export outside the US the DES libraries used in
drawbridge; see the respective tool README's for details of any
restrictions. (Note that the DES libraries are NOT required to use
drawbridge. They just enable secure remote management of drawbridge.)
CONTACT:
Comments and questions are most welcome. Please address them to:
drawbridge@sc.tamu.edu
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Thu, 1 Jul 1993 22:03:35 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was RFC 1191 compliance)
In article <rturner.741550521@imagen>, rturner@imagen.com (Randy Turner) writes:
> ...
> And while all of this sounds like a wonderful speedup, it
> shoots down the usual layered approach...
hmmph. That "usual layered approach" to network protocols exists only in
1. academic papers about how things ought to be.
2. standards committee view graphcs.
3. standards documents
4. low speed, often buggy, naive implementations.
Layering is an excellent way to think about networks, and to roughly
structure code and hardware, but no more.
The boxes and layers in the standards documents are perfectly fine
descriptions of how things should appear to work from outside your
black box. However, who anyone to tries to implement exactly the boxes
and layers, Signal_This and Indicate_That functions in the OSI, IEEE,
and ANSI standards almost always (well, always in my experience) fails
to produce a salable or even interesting product.
Imagine how useful would be an Ethernet chip that was actually
implemented with the Pascal code in the IEEE-802.3 standard.
Doing the TCP checksum in the link layer need not be a particularly big
layering violation. There are far larger violations of Standard
Committee Law than having your link layer code pass both the data and
the 1's complement sum of all of that data to the next layer up. Eventually
the TCP code (in which ever layer you put it) would receive its data and
adjusted 1's complement sum, and do the obvious.
Note: the SGI FDDI checksum scheme just flat out voilates the layers.
The link layer adds a bit to the data that says "this was good; trust me".
The Layering Standards Mavens are welcome to arrest me.
Why do so many otherwise rational people who would never outlaw
absolutely every use of goto and every use of assembly language have
such an unhealthy respect for network layering?
Vernon Schryver, vjs@sgi.com
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Thu, 1 Jul 1993 22:18:18 GMT From: john@gecko.mtc.ti.com (John Maline) To: comp.protocols.tcp-ip Subject: Errors on unconnected UDP sockets and RFC1122
I've got an application that finds a server via a UDP broadcast, then communicates with it via directed UDP. At no time is a connect() ever done on this socket. Under SCO Unix 2.3v4, I get ECONNREFUSED on subsequent recvfrom() and sendto() calls, because a couple of misbehaving host on our net send me an ICMP port unreachable message in response to my broadcast (something that's prohibited by RFC1122). Other hosts running SunOS 4.1.x, AIX 3.1.x do the same broadcast and get the same ICMP message, but don't return any error to the application. According to RFC1122, paragraph 4.1.3.3: "UDP MUST pass to the application layer all ICMP error messages that it receives from the IP layer. Conceptually at least, this may be accomplished with an upcall to the ERROR_REPORT routine (see section 4.2.4.1)." According to _Unix Network Programming_ by Stevens, p 271 (discussing the connect() call): "There is another feature provided for connectionless clients that call connect. If the datagram protocol supports notification for invalid addresses, then the protocol routine can inform the user process if it sends a datagram to an invalid address. For eample, the Internet protocols specify that a host should generate an ICMP port unreachable message if it receives a UDP datagram specifying a UDP port for which no process is waiting to read from. ... 4.3BSD, for example, notifies the process with a "connection refused" error (ECONNREFUSED) on the next system call for the socket, only if the process had connected the socket to the destination address." It sounds like the 4.3 (and SunOS and AIX) behavior described by Stevens isn't in compliance with RFC1122. Is this correct? Are other vendors going to the mandatory error reporting behavior? Is there some loophole that allows them to be RFC1122 compliant, but use the 4.3 behavior? Is SCO doing something *wrong* by reporting the error even without the connect() (and can you quote me a paragraph number from some Internet standard RFC? :-). Please reply by mail. Thanks. -- John Maline jmaline@lobby.ti.com TI MSG: JWMX 214-995-6692 Texas Instruments PO Box 655012 MS 351 Dallas, TX 75265
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Thu, 1 Jul 1993 23:14:38 GMT From: craig@sics.se (Craig Partridge) To: comp.protocols.tcp-ip Subject: the usual layered approach
>> And while all of this sounds like a wonderful speedup, it >> shoots down the usual layered approach... > > hmmph. That "usual layered approach" to network protocols exists only in > 1. academic papers about how things ought to be. > 2. standards committee view graphcs. > 3. standards documents > 4. low speed, often buggy, naive implementations. > > Layering is an excellent way to think about networks, and to roughly > structure code and hardware, but no more. Let me add my voice to Vernon's here. The grand seven layer architecture as we know it now was developed as a way to assign work to standards committees. All that strongly worded text about strict layering and clean interfaces was a way of making sure the standards committees not to mess in each other's work. Thus a layered implementation is typically one that is blindly following a set of committee assignments made 15 years ago. Personally I find it a bit funny that a set of political decisions should dictate coding styles... Craig
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Fri, 02 Jul 1993 00:08:29 GMT From: debiso@westfield.win.net (Joe DeBiso) To: comp.protocols.tcp-ip Subject: Network printing from a PC to an SCO box
I need to be able to print to postscript printers on my network. I have a bunch of PC's all using ncsa telnet and ftp with clarkson drivers. Is there a way to redirect LPT2: to the network printer?? Any one with info, please HELP!!! Thanx, Joe DeBiso Plantrol Systems, Ltd.
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 2 Jul 1993 02:08:43 GMT From: mjr@tis.com (Marcus J Ranum) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was RFC 1191 compliance)
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >Note: the SGI FDDI checksum scheme just flat out voilates the layers. >The link layer adds a bit to the data that says "this was good; trust me". >The Layering Standards Mavens are welcome to arrest me. Don't worry on that account. They're all too busy trying to figure out how to make theirs work fast, to go out arresting people. In all seriousness, layering software is useful. Once you prototype something in a layered manner it's *REAL* easy to profile it and see where the bottlenecks are, and *THEN* to optimize it. This is what I always thought of as "computer science" 10 Hypothesize 20 Perform experiments 30 Evaluate results 40 GOTO 10 A real scientist will throw out the theory if the output of lines 20 and 30 are promising and/or make your product more competitive on the market. mjr.
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 2 Jul 93 08:13:15 GMT From: tom@wcc.oz.au (Tom Evans) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was RFC 1191 compliance)
In article <20s7kv$h8s@calvin.NYU.EDU>, roy@mchip00.med.nyu.edu (Roy Smith) writes: > vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > > The TCP checksum is effective, as shown by detected errors. > > ... show is that TCP checksuming catches *some* errors... It's well > known that there are certain kinds of errors which will corrupt a > packet yet still pass checksum (i.e. transposed quadwords). Transposed shorts and longs too. And one that bit me last month - if the packet is thought to be longer than it originally was (length field calculation stuffup) and the extra "data" is +0 or -0, it doesn't get detected either. ======================== Tom Evans tom@wcc.oz.au Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179 Victoria, Australia 61-3-764-1100 FAX ...764-1179 A.C.N. 004 818 455
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Fri, 2 Jul 1993 08:15:38 GMT From: shewison@brookes.ac.uk (Simon Hewison) To: comp.protocols.tcp-ip Subject: Alternative protocols for Lan Manager/X
Does anyone know if it's possible to run a protocol stack other than tcp/ip with Lan Manager/X or DEC Pathworks? We're currently running NETBEUI to OS/2 servers, and would like to know if we need to go and change all our clients to tcp/ip if we are to use Lan Manager/X or DEC Pathworks. On a more general note, if there is any other way of having alternate protocol stacks on unix, at what level would it come in? I assume that it would be below the sockets interface.
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Fri, 2 Jul 1993 11:26:43 GMT From: kuipers@fwi.uva.nl (Tobias Kuipers) To: comp.protocols.tcp-ip Subject: How to get IP# of telnet-session on SCO?
Does anyone have experience in fetching runtime data of SCO TCP/IP (release 1.1.3f) under SCO UNIX (386/3.2v4.0)? I want to obtain the IP number of a telnet session for security enhancements, but whilst the IP number of a PTY login is stored in /etc/utmp under e.g. SunOS and Silicon Graphics, this is not the case with SCO. Does anyone know how to hook into the kernel chars of SCO to fetch TCP parameters of a session? I do have a development license, but the docs are worse then the manual of a Bulgarian food processor. Please reply by email: kuipers@fwi.uva.nl or kuipers@eurocode.nki.nl Thanks in advance, Tobias Kuipers
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Fri, 2 Jul 1993 11:31:45 GMT From: nick@quay.ie (Nick Hilliard) To: comp.protocols.ppp,comp.protocols.tcp-ip Subject: Routing problems with ppp
Howdy all. I'm having some problems using PPP. I'm using a Sun (4.1.3) with the freeware PPP (ppp-1.2.tar.Z) package written by Brad Clements. The problem is that the Sun, for some reason or other, isn't routing packets properly. Here's the configuration: Apart from the loopback device, the Sun (quake) has 2 interfaces (they have different names for political reasons): ppp0: 192.122.232.1 (extern.quay.ie) le0: 192.122.220.8 (quake.quay.ie) The routing table on the Sun is like this: quake:/# netstat -rn Routing tables Destination Gateway Flags Refcnt Use Interface 127.0.0.1 127.0.0.1 UH 0 0 lo0 192.111.39.4 192.122.232.1 UH 0 0 ppp0 default 192.122.232.1 U 17 236 ppp0 192.122.220.0 192.122.220.8 U 50 66976 le0 The default route is added using quake:/# route add default 192.122.232.1 0 The PPP server that I use is tain.ieunet.ie (192.111.39.4), and 192.122.220.0 is a local net. 'curia' is a machine in the outside world, which I log in to from quake. But this is what happens when I try to ping 192.122.220.8 (the Ethernet interface on quake) curia:/home/nick> ping 192.122.220.8 ICMP Time Exceeded from tain.IEunet.ie (192.111.39.4) for curia (143.239.1.8) to 192.122.220.8 port 6026 ICMP Time Exceeded from tain.IEunet.ie (192.111.39.4) for curia (143.239.1.8) to 192.122.220.8 port XXXX [etc, etc, for various values of XXXX] A traceroute reveals the following: traceroute to 192.122.220.8 (192.122.220.8), 30 hops max, 38 byte packets 1 cisucc (143.239.1.199) 10 ms 0 ms 10 ms [intermediary nodes deleted] 8 Dublin.IE.EU.net (134.222.6.2) 160 ms 90 ms 110 ms 9 tain.IEunet.ie (192.111.39.4) 330 ms 130 ms 110 ms 10 134.226.128.1 (134.226.128.1) 200 ms 140 ms 100 ms 11 tain.IEunet.ie (192.111.39.4) 160 ms 410 ms 210 ms 12 134.226.128.1 (134.226.128.1) 130 ms 230 ms 130 ms 13 tain.IEunet.ie (192.111.39.4) 110 ms 100 ms 180 ms [etc] As might be expected, none of the machines on the 192.122.220.* net can contact the outside world either. If I set up SLIP on another machine on the 192.122.220.* net, everything works fine. All local machines can be contacted from the outside world (and vice versa) without any problems, so the problem is (almost) definitely with the PPP on the Sun. So, any ideas? I've tried fiddling about with routing table, but nothing I did seemed to make the slightest difference :-( Is this a problem with this particular version of PPP? Thanks in advance, Nick -- | Nick Hilliard | e-mail: nick@quay.ie | | Quay Financial Software, | Phone: [+353] 1 6612377 | | Ferry House, Lower Mount St, | Fax: [+353] 1 6607592 | | Dublin 2, Ireland. | Opinions: I think; therefore I disclaim. |
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Fri, 2 Jul 1993 13:05:04 GMT From: rwausti@aplcenmp.apl.jhu.edu (NE Austin richard way ddfde344556666) To: comp.protocols.tcp-ip Subject: Where to find TCP/IP over X.25 data
I am conducting a research project and am in need of acquiring TCP/IP over X.25 traffic (1's and 0's). Can anyone suggest a good network simulator or better yet, does anyone have access to test data that might meet this criteria. Any and all help would be appreciated. Rick Austin Austin_Richard_W@smtpmac.ads.com "When in doubt, REBOOT". Ken Updike, 1990
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Fri, 2 Jul 1993 13:27:17 GMT From: errol@hpgnd153.grenoble.hp.com (Errol_Inan) To: comp.protocols.tcp-ip Subject: Re: New Yorker cartoon
> "On the Internet, nobody knows you're a dog". Bark, bark! Ruff, ruff. Sniff, sniff, sniff, sniff, sniff. <censored> Pant, pant, pant, ....
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: 2 Jul 1993 13:50:39 GMT From: bob@comlab.gtri.gatech.edu (Bob Baggerman) To: comp.protocols.tcp-ip Subject: Re: Alternative protocols for Lan Manager/X
Simon Hewison asks: > Does anyone know if it's possible to run a protocol stack other than > tcp/ip with Lan Manager/X or DEC Pathworks? We're currently running > NETBEUI to OS/2 servers, and would like to know if we need to go and > change all our clients to tcp/ip if we are to use Lan Manager/X or > DEC Pathworks. The short answer is yes, it is possible to run other protocol stacks. You can run whatever protocol stack your server vendor has available. But that's probably not really what you are asking. The LM/X product runs on a Unix box and depending on the vendor uses TCP/IP or OSI as the transport protocol for the server NetBIOS. DEC Pathworks uses DECnet and TCP/IP on the VAX and MIPS based servers. I haven't looked at Pathworks in a while but they may now offer other protocols such as NetBEUI on the VAX and MIPS based servers. It's worth a call to a knowledgeable sales type. Syntax in Auburn, Washington, USA has recently finished up a NetBEUI implementation for their Unix based LanMan compatible LMserver product. LMserver is supposed to run on most flavors of Unix. If you haven't bought into LM/X (I think they call it LMU now) or Pathworks then LMserver might be a good alternative. Keep in mind that you can run multiple NetBIOS protocol stacks on your PCs if need be. I.e. you can run both NetBEUI and an IP based NetBIOS at the same time. It would be a real memory pig but other people have reported being able to do it. Bob -- Bob Baggerman ! bob.baggerman@gtri.gatech.edu Communications Laboratory ! bob@comlab.gtri.gatech.edu Georgia Tech Research Institute ! qseclrb@prism.gatech.edu Atlanta, GA 30332 USA ! 404-894-3525
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Fri, 2 Jul 1993 14:25:11 GMT From: durst@mwunix.mitre.org (Robert Durst) To: comp.protocols.tcp-ip,comp.protocols.iso Subject: POSIX Ballot Group Forming for Sockets and XTI
To Whom It May Concern: The POSIX P1003.12 group is defining a protocol-independent Application Program Interface for process-to-process communication. POSIX requires its standards to be based on existing practice, and two C-language interfaces are being standardized by P1003.12. One is the X/Open Transport Interface (XTI), and the other is the Sockets interface. The group has defined a language-independent specification to which both C-language bindings conform, and this enables the two bindings to be presented within a common framework. Additionally, the group anticipates that non-C-language bindings would be developed in accordance with this language-independent specification. The group intends to ballot its draft standard in the September 1993 time frame. It is to everyone's benefit that these APIs are incorporated into POSIX. Your help is requested to ensure that they are incorporated correctly. You can provide this help by joining the ballot group and balloting on the standard.. If you are a sockets user or implementor, you should be aware that a significant amount of semantic information has been extracted from the Berkeley reference implementation for incorporation into the specification. This material should be reviewed thoroughly. If you are an XTI expert, the text in the P1003.12 draft is essentially that of the XTI CAE specification. As the draft goes through the IEEE balloting process, changes will certainly be requested. The presence of both Sockets experts and XTI experts in the ballot pool is essential if these requests are to be handled properly. Membership in the P1003.12 ballot pool is by invitation. IF YOU WISH TO RECEIVE AN INVITATION to join the P1003.12 ballot pool, either you must already receive POSIX invitations to ballot on draft standards or you must REPLY TO THIS MESSAGE so I can make sure you get an invitation. Once the ballot pool is formed, it is fixed and cannot be added to, so reply now. You DO NOT have to be a member of IEEE to ballot on this draft standard, however, you must be a member in order to vote "yes." Non-IEEE members are considered parties of interest, and if objections are raised by parties of interest, we will give them due consideration. THERE IS A FEE charged by the IEEE to cover the initial distribution of the document and all subsequent recirculations. The document is currently about 400 pages long, and we expect the fee to be approximately $50. In order to receive an invitation to ballot on IEEE P1003.12, reply to this message with your name, address, phone number, fax number, email address, and IEEE membership number (if applicable). Regards, Robert C. Durst Chairman, IEEE P1003.12 durst@mitre.org
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Fri, 2 Jul 1993 14:48:04 GMT From: nick@quay.ie (Nick Hilliard) To: comp.protocols.ppp,comp.protocols.tcp-ip Subject: Re: Routing problems with ppp
Nick Hilliard (nick@quay.ie) wrote: [Sad woes deleted] Ok - the problem appears to be with the PPP server I was connecting into, so you can safely ignore my previous posting... best, Nick -- | Nick Hilliard | e-mail: nick@quay.ie | | Quay Financial Software, | Phone: [+353] 1 6612377 | | Ferry House, Lower Mount St, | Fax: [+353] 1 6607592 | | Dublin 2, Ireland. | Opinions: I think; therefore I disclaim. |
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Fri, 2 Jul 1993 15:01:22 +0000 From: robin@tcam.demon.co.uk (Robin Duerden) To: comp.protocols.tcp-ip Subject: SUN, IP Broadcasts and woe!!
I would like to send out UDP broadcast datagram packets to IP destination address 255.255.255.255 from my SUN workstation using the standard Berkley socket interface API. My SUN's ifconfig command currently reports interface le0 being set up as ip addr=192.1.1.177, netmask=FFFFFF00 and broadcast=192.1.1.255. I can receive packets broadcast from other sources containing the IP address of 255.255.255.255 by using ifconfig to set broadcast=255.255.255.255 but all attempts to send to this address result in a "network unreachable" error. -- Robin Duerden
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Fri, 2 Jul 1993 15:28:45 GMT From: emurphy@cs.uno.edu (Edward Murphy) To: comp.protocols.tcp-ip Subject: (?) experiences installing a De-200 card and NCSA Telnet
Howdy. I am installing NCSA Telnet for the PC version 2.3.06. The hardware is a 386 PC with a DE-200 ethernet card (made by D-Link). The card is certified compatible with the NE2000 series of Novell ethernet cards. If anyone has experiences with configuration, I would greatly appreicate your contacting me. I have several questions regarding the process. Ed Murphy
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 2 Jul 1993 15:47:10 GMT From: bcarter@magnus.acs.ohio-state.edu (Bryan D Carter) To: comp.protocols.tcp-ip Subject: Re: Finding IP #s
I've got what I needed, thank for all the help. R.I.P.
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Fri, 2 Jul 1993 15:56:30 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was RFC 1191 compliance)
In article <3202@wcc.oz.au>, tom@wcc.oz.au (Tom Evans) writes: > In article <20s7kv$h8s@calvin.NYU.EDU>, roy@mchip00.med.nyu.edu (Roy Smith) writes: > > vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > > > The TCP checksum is effective, as shown by detected errors. > > > > ... show is that TCP checksuming catches *some* errors... It's well > > known that there are certain kinds of errors which will corrupt a > > packet yet still pass checksum (i.e. transposed quadwords). > > Transposed shorts and longs too. And one that bit me last month - if > the packet is thought to be longer than it originally was (length > field calculation stuffup) and the extra "data" is +0 or -0, it > doesn't get detected either. I agree. If I were arguing about the right checksum, I would ask for something that would distribute almost as easily over concatenation (ck(A+B)-ck(B)=ck(A)), but would have detected at least some transpositions, something like a rotate between 16-bit adds. Of course today, you'd probably use 32-bit adds, which detects transposed 16-bit-words. On the other hand, all of the hardware and software bugs I've seen discovered with or covered by the TCP checksum were not simple transpositions, or also involved other problems. As long as you're sending data bit-serial, I don't supposed transpositions are as likely as other fun like "simple" noise. Vernon Schryver, vjs@sgi.com
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 2 Jul 1993 16:29:33 GMT From: haas@bnr.ca (Mark Haas) To: comp.protocols.ibm,comp.protocols.iso,comp.protocols.misc,comp.protocols.tcp-ip Subject: Advance Announcement: ICNP-93
Advance Announcement
The 1993 International Conference on Network Protocols (ICNP '93)
October 19-22, 1993
ANA Hotel, San Francisco, California
ICNP '93 is concerned with the design, specification, validation,
implementation and testing of computer network protocols for network
access, routing, flow and congestion control, network operation and
management, and internetworking.
The new conference will prove well worth attending. Two half-day and
one full-day tutorials will be given on the first day to provide an
opportunity for intensive exposure to hot topics of current interest.
During the last three days of the conference, there will be two
invited keynote addresses, one planery panel session, and presentation
of 42 papers in 14 sessions. In addition a reception will be given
for social activities. Come and join us.
The conference will be held at the ANA Hotel, 50 Third Street, San
Francisco, CA 94103. Rates for ICNP '93 are $130 single and $150
double. Please contact the hotel directly at (415) 974-6400 for
reservation. Please be sure to mention ICNP '93 for the special
rates. The deadline for reservations is September 27, 1993.
The two keynote addresses will be delivered by Mr. Tony M. Yuen, VP,
Data Communications Products, Northern Telecom; and by Dr. Harry R. Rudin,
IBM Research Division, Zurich Research Laboratory. Mr. Yeun's
topic is "Data Networking in the 1990's" and Dr. Rudin's topic is
``Protocol Development vs. Formal Description Techniques.''
The plenary panel session is organized by Dr. David Lee of AT&T Bell Labs.
The topic is ``Protocol Conversion and Internetworking.'' The
panelists are Dr. Simon Lam, University of Texas, Austin; Dr. Krishan
Sabnanni, AT&T Bell Labs.; Dr. Joshua Auerbach, IBM Watson Research
Center; and others to be announced later.
Tutorials (October 19)
No.1: ATM: Technology, Design and Control, by Drs. P. Varaiya and
J. Walrand, University of California, Berkeley. Full Day, 9 am
to 5 pm (including lunch).
No.2: Mobile Communications: Systems Architecture, by Dr. B. Gopinath,
Rutgers University. Half Day, 9 am to 12:30 pm.
No.3: Design and Validation of Communication Protocols, by
G. Holzmann, AT&T Bell Labs. Half-Day, 1:30 pm to 5:00 pm.
Technical Program (October 20-22)
The technical program will consist of 14 sessions in two tracks, 3 papers per
session. The session titles are as follows.
October 20:
1A. Protocol Configuration and Architecture
1B. Protocol Verification I
2A. Routing Protocols
2B. Protocol Modularity and Layering
3A. Congestion and Flow Control
3B. Protocol Theory
October 21:
4A. Congestion and Rate Control
4B. Protocol Testing I
5A. Broadcast Protocol
5B. Simulation and Validation Tools
Panel: Protocol Conversion and Internetworking
October 22:
6A. Protocol for LANs
6B. Protocol Verification II
7A. Performance Evaluation
7B. Protocol Testing II
Registration
Advance Registration will be handled by Mr. Mark Haas, ICNP '93, 2116
E. Arapaho Road, Suite 297, Richardson, TX 75081; Phone, (214)
684-4629; Fax, (214) 684-3705; e-mail, icnp93@compmail.com. The
deadline for advance registration is September 27. The rates are as
follows:
Advance Late
(until 9/27) (after 9/27)
Tutorials
Member Full Day (No.1) $200 $250
Member Two Half Days (Nos. 2 & 3) $200 $250
Member One Half Day (No. 2 or 3) $110 $140
Nonmember Full Day (No. 1) $250 $315
Nonmember Two Half Days (Nos. 2 & 3) $250 $315
Nonmember One Half Day (No. 2 or 3) $130 $160
Technical Program
Member $250 $300
Nonmember $315 $375
Full Time Student $100 $120
Please make checks in US dollars to IEEE Computer Society, and provide
your name, affiliation, address, phone and fax numbers, e-mail
address, and IEEE-CS membership number (if applicable) when
registering.
Credit cards (VISA, MasterCard, Diners Club, and American Express) are
acceptable. Please provide your card type, card number, cardholder's
name (exactly as it appears on the card), card expiration date, and
your signature.
For further information, please contact Dr. Ming T. (Mike) Liu, phone (614)
292-6552, fax (614) 292-2911, e-mail mike.liu@osu.edu.
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Fri, 2 Jul 93 10:37:57 +0400 From: aleksey@kivc.magnitka.chel.su To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.xenix.sco,fido7.unix,relcom.fido.ru.unix Subject: [HELP!] pOMIpA@ BEZ TCP/IP Run Time for SCO XENIX.gDE WZQTX?(aleksey@kivc.magnitka.chel.su)
--- -- - G.mAGNITOGORSK iwc a/o "magnitostroj" - aLEKSEJ r. gOLOWA^EW
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: Fri, 2 Jul 1993 18:39:48 GMT From: wunder@hpl.hp.com (Walter Underwood) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was RFC 1191 compliance)
The TCP checksum won't catch transpositions, but it will usually catch blocks of 1's or 0's. Does your Ethernet controller have parity memory? What happens if one of those chips goes bad? wunder
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Fri, 2 Jul 1993 20:00:20 GMT From: jburnes@csisun.uucp (Jim Burnes) To: comp.protocols.tcp-ip Subject: GURU question - Routing & SNMP
Hi Folks...here is a question for you....
We have a situation where a site administrator needs to have
SNMP access to a bunch of smart computer appliances (lets call
them room air conditioners for sake of argument). Lets also
say that these air conditioners are frequently hooked to
host computers via RS232 lines in order to tell the computer
when to shut down because its too hot.
Now the administrator queries these room air conditioners via
SNMP to keep constant tabs on room temp, performance, BTU's
etc etc etc
Lets also assume that all the conditioning units except two
or three have ethernet adapters and can understand TCP/IP/SNMP
right off the net. The other ones are dumb, but they are hooked
to smart hosts running TCP/IP. Is there any way for the smart
host to act as a proxy for his dumb air conditioner and route
packets destined for the air conditioner and then interpret
the SNMP coming in and translate it to something the air
conditioner can understand?
Something like this.....
+-------+
! !
! admin !--------+-----------+-----------NET--------------+-------------...
! ! ! ! !
+-------+ ! ! !
SNMP for air 1>! SNMP> ! SNMP for smart host>! <for dumb air
+----------+ +-----------+ +------------+
! ! ! ! 192.9.200.3 ! !
! smart air! ! smart air ! ! smart host !
! 1 ! ! 2 ! ! !
! ! ! ! !------------!
+----------+ +-----------+ ! routing !
192.9.200.1 192.9.200.2 !------------!
! xlation !
+------------+
^
(no net) !<RS232 command pipe
V
+------------+
192.9.200.4 ! !
(by proxy) ! dumb air !
! !
! !
+------------+
So I expect you would essentially route packets for this dumb air
conditioner and then somehow link in to the other end of the
packets being routed, recieved them by some proxy program and
then do protocol translation to and from the air conditioner.
I'm really mirky on what sort of API would allow me access to the
incoming packets. Is this possible? Would I need access to the
OS's TCP/IP source or is their a predefined interface to become
some sort of server daemon at this level.
TCP GURU's...I need your help!
I will repost a digest version of my replies for the rest of the
net.
Thanks,
Jim Burnes
jburnes@compusci.com
--
Jim Burnes
Software Engineer
CompuSci, Inc.
jburnes@compusci.com
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Fri, 2 Jul 1993 20:26:34 GMT From: DELLA@lexmark.com To: comp.protocols.tcp-ip Subject: Reverse remote name server help?
We are attempting to have our primary name server refer to another primary name server for reverse address resolution. For some reason we cannot. We've played in the named.boot file and also named.rev file to find where we might possibly place a record and what the format of this record might be (to no avail). After looking through the RFC 883 and other UNIX documentation, we have been unsuccessful in doing this thing. We are running AIX 3.2 on an RS/6000. Here is what we need to resolve: My name server is the primary name server for the abc.123.com domain. Another name server is the primary name server for the def.123.com domain. I want to be able to resolve an IP address that is defined on the other name server from my name server. i.e. 'host 157.184.29.2' Thanks in advance. ========================================================================= Paul L. Della Maggiora della@lexmark.com
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 1993 00:33:38 GMT From: mogul@pa.dec.com (Jeffrey Mogul) To: comp.protocols.tcp-ip Subject: Re: Path MTU Discovery
In article <rturner.741408434@imagen> rturner@imagen.com (Randy Turner) writes: > >>>>A host using PMTU Discovery would normally advertise an MSS equal to >>>>the first-hop MSS; that is, the MTU of the directly connected LAN >>>>interface, less the TCP+IP header sizes. Hosts that use RFC1191 >>>>will avoid fragmentation through that mechanism. Older hosts, at >>>>least those that comply with RFC1122, will use MIN(received-MSS, 512) >>>>[I could have the constant wrong] for "non-local" peers, and so >>>>will not do anything too awful. > Wow, that seems awfully inefficient. Something must be missing > from this equation, either that, or one of us is talking about > hosts and the other intermediates. No, the formula is right. Your math is wrong. It's less efficient than using, say, MSS = 1460 (unless the larger MSS causes fragmentation and that causes trouble). But the net change in throughput, over a bandwidth-limited connection, is less than 10%. (If you are limited by the rate at which your end-hosts can process packets, then the performance loss might be larger.) There is a persistant myth that if one cuts the packet size by a factor of N, throughput will drop by the same factor. Anyone with a junior-high mathematics education can easily prove this wrong. -Jeff
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Sat, 3 Jul 1993 04:21:24 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Path MTU Discovery
In article <212k52$hel@usenet.pa.dec.com>, mogul@pa.dec.com (Jeffrey Mogul) writes: > ... > There is a persistant myth that if one cuts the packet size by a > factor of N, throughput will drop by the same factor. Anyone with > a junior-high mathematics education can easily prove this wrong. Uh, sorry, but that's inapplicable. Yes, if you are limited by the medium, changing the packet size does not change throughput very much. However, in the case at hand, a printer controller whose proprieters say cannot keep up with the medium, changing the packet size by N changes the packet rate by the same factor, and probably changes the printer's throughput by the same factor. This "myth" applies even if you are not medium-limited only because your system is too busy burning CPU cycles on the application. Cycles/byte is best approximated by packets/byte, until you get to quite large packets. If you do not have enough cycles, you must reduces packets/byte to improve performance. Consider that even Van Jacobson's numbers for instructions/TCP segment are not much different from the cycles needed to copy and checksum 512 byte segments on a 32-bit machine. (ignoring cache costs, and assuming you insist on byte copying and checksumming with your CPU) Vernon Schryver, vjs@sgi.com
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 93 07:09:54 GMT From: jkay@cs.ucsd.edu (Jon Kay) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was RFC 1191 compliance)
mogul@pa.dec.com (Jeffrey Mogul) writes: > >In article <ipk632k@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > >Based on the excellent idea of looking at `netstat`, I looked at two > >servers (mostly netnews), and found in the two days they've been up, > ... > Jon clearly argues for turning off checksums only when the underlying > path is highly reliable (e.g., with uninterrupted CRC protection). > ... > None of the netstat numbers posted so far have distinguished between > local-LAN and remote-LAN checksum errors (nor could they, as far as > I am aware, because BSD-based systems don't keep separate statistics). > Unless you can provide some sort of evidence that some of those 57 > bad TCP checksums came from "local" packets, then these numbers don't > support your side of the argument. > ... Exactly. Thanks. As you point out, what's important is how many of the errors are local versus remote, since remote errors would be detected under redundant checksum avoidance. It is tough to get the correct numbers (that doesn't stop us from looking, but it's mighty time-consuming - don't expect an answer tomorrow). Preliminary digging on netstat numbers from various machines supported the notion that bad checksums mostly come from remote machines. One preliminary thing we did do what sort of patterns of bad checksums cropped up on DECstations with checksums turned. The DECstations' main servers were also DECstations with checksums turned on. Now, my idea was that if I was correct and that WANs really are the major source of errors, there would be fewer logged UDP errors than logged TCP errors, because most packets sent over WANs are TCP packets. On the other hand, most packets that only traverse LANs are UDP packets. Thus, the overwhelming majority of errors should show up in TCP. This turned out to be the case, even though most packets overall are UDP packets (so you expect more UDP errors if even a tenth of errors come from LANs). Jon
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 93 07:12:48 GMT From: jkay@cs.ucsd.edu (Jon Kay) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was RFC 1191 compliance)
There is always a cost to reliability. The question is how much you're willing to trade for how much reliability. Clearly, more reliability is always better. We would all like our computers to never make mistakes. However, that is not our primary goal. It is trivial to design computer that never makes any mistakes at all - so long as it doesn't actually have to do anything, it can never make any mistakes - a brick of lead meets the specs. Moving along the (price/performance) / reliability curve, if you're willing to fork over a few million dollars to buy an extremely specialized product, you can buy systems with thorough (for today) fault detection and tolerance. You will still get bugs and data corruption on this machine; at most you can hope that they will be much rarer. A small number of you reading this note may be reading it on such a machine. The majority of you, though, have opted to go way further down the curve. You have traded reliability for price/performance. You considered a certain amount of unreliability reasonable. Some of you went even further and bought the cheapest clone PC you could lay your hands on, trading the many subtle incompatibilities of PCs for a low price. So how much reliability is "reasonable?" The more expensive an operation is, the less "reasonable"; the more errors it catches, the more "reasonable." I feel that data checksumming for general TCP/IP data transmission is reasonable, especially given that wide-area links are often slow and error-prone. We have not suggested eliminating software checksums entirely. Performing a software data checksum across a LAN is a different story. There it is usually secondary to the LAN CRC implemented in hardware, and given the higher bandwidths, the checksum is likely to be an imposing overhead. Yes, both network interfaces and bridges can cause corrupt packets - but remember, both the CRC and the bridge/controller have to break for packet corruption to go undetected. Of course both happen, but in my experience no more often than other system problems. So, given such a gray area, I think it is reasonable to propose dropping the software checksum, in the limited case when a packet is not routed, and allow users to decide whether they want to pay the cost or not, rather than forcing the cost on everyone. Jon
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 93 07:51:27 GMT From: jkay@cs.ucsd.edu (Jon Kay) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was RFC 1191 compliance)
> That outboard checksumming is worthwhile, but only because I also fixed > things to prevent byte copies. 0.5 cycles/byte is measurable, but not > significant compared to the cache costs, which are 10 to 500 times > higher than 0.5cycle/B, even on old R3000 based systems like DEC's. Well, we're almost in agreement, for once. One of us must be sick :-). The possibility of not even touching the cache is a big reason why I'm pushing redundant checksum avoidance, though by no means the only reason - checksumming remains a big factor even in a Reno-or-earlier copying environment. Then again, some numbers you've posted suggest that some of the memory systems you're playing with are slower relative to the CPU than the ones in the DECstations and Alphas I deal with (I simply won't argue over whether SGIs have slower memory systems or faster CPUs....). Jon
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 1993 20:19:14 -0400 From: masato@access.digex.net (J M Thompson) To: comp.protocols.tcp-ip Subject: Intermittent IP Packet Loss
We recently experienced a problem of intermittent IP packet loss from
a SUN 690MP (SUNOS 4.3.1??). The symptoms of the problem manifested
as excessively long response times. Executing the following ping
command on the SUN690 in question
ping -s another.host 1000
resulted with the ping command reporting from between 30 to 50 percent
packet loss.
Other pertinent information:
1) The network interface was token ring.
2) We believe the problem started as a result of a buffer overflow
in a brouter, but that overflow problem was corrected and the
problem still persisted.
3) After the buffer overflow problem was corrected, the IP packet
loss problem would go away for awhile (30 to 120 minutes) and then
reappear for awhile.
4) We experienced the packet loss problem between the SUN690 in question and
other systems on the same local area network. Other systems on the
same local area network did not experience the same problem.
At wits end, we rebooted the SUN690 and the problem went away.
Would appreciate any insight that anyone could provide about this problem.
Thanks, Jim Thompson
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 1993 11:55:32 +0200 From: mike@horus.ap.mchp.sni.de (Mike Hoffmann) To: comp.sources.wanted,comp.protocols.tcp-ip Subject: Logging ftp CLIENT wanted
Hi! I am looking for an "ftp" client, that will allow logging for accounting purposes. Best would be syslog-ish, noting, who called up "ftp", and what actions he did, mainly what files were retrieved from which servers and what file-size they had. The ftp clients I retrieved from some Internet anon. ftp sites don't seem to have any capabilities like that. I am a *bit* reluctant to dive into the source and build it in myself - but am desperate enough to do so, as I need it *urgent* So, if no such beast is around, I would appreciate help and pointers on where to start. (The ftp source I am using seems to be the current "standard" client, a "what" gives me a version of 5.28 on ftp.c) (NB: just to make it clear: I mean the ftp *client*, not the ftpd server, which does all the logging I could ever want!) Thanks in advance! Mike -- Mike Hoffmann - Internet Administrator, Siemens-Nixdorf AG, SNI SU AP 1123 INTERNET: Mike.Hoffmann@ap.mchp.sni.de "...And I looked, and I saw a fifth rider, riding a purple horse. It's voice sang a dirge of happiness, and it wanted to be my neighbor..." -- Revelations, the verse they left out because it was _too_ _damn_ _scary_. (tomault+@cs.cmu.edu (Thomas Galen Ault))
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Sat, 3 Jul 1993 18:49:08 GMT From: Steinar.Haug@runit.sintef.no (Steinar Haug) To: comp.sys.hp,comp.protocols.tcp-ip Subject: Why doesn't the HP-UX ftpd allow port numbers < 1024 in PORT command?
We have an IBM AS/400 system which wants to use port numbers just below 1024 in the PORT command sent from the FTP client to the FTP server (ftpd) on the remote host. The HP-UX ftpd doesn't like this, and responds: ftp> quote PORT 129,241,4,6,3,255 ---> PORT 129,241,4,6,3,255 530 Bad parameters for PORT command. I checked a bit, and it seems that it's port numbers in the range 513 to 1023 which are not accepted: ftp> quote PORT 129,241,4,6,0,0 200 PORT command successful. ftp> quote PORT 129,241,4,6,2,0 200 PORT command successful. ftp> quote PORT 129,241,4,6,2,1 530 Bad parameters for PORT command. ftp> quote PORT 129,241,4,6,4,0 ---> PORT 129,241,4,6,4,0 200 PORT command successful. It seems rather likely that this is done in a (misguided) attempt to stay away from the "reserved" port range. It happens on all 8.0 and 9.0 systems I have tried it on. HP, how about reading the FTP spec? It says nothing about reserved ports. Can you give us a good reason why your ftpd works like this? Sun's doesn't. The Ultrix ftpd doesn't. Also, can you give us a good workaround while you fix the problem? Steinar Haug, system/networks administrator SINTEF RUNIT, University of Trondheim, NORWAY Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Sat, 3 Jul 93 21:55:51 GMT From: woods@robohack.UUCP (Greg A. Woods) To: comp.protocols.tcp-ip,comp.sys.att Subject: Re: TLI
In article <1993Jun26.231521.16079@sporran.uucp> tim@sporran.uucp (Tim Fry) writes: > In article <C97313.8zx@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes: > > First, whether TLI is on top of STREAMS or not depends entirely on the > >implementation, which I don't believe was specified. It has nothing to do with > >TLI per se. > > I concur that the TLI may not be implemented on top of STREAMS, but I have to > say that I've yet to see an implementation where it wasn't. See the AT&T 3B1 Starlan-1 package for an example.... BTW, someone earlier "concluded" that RFS & TLI would be slower than using socket()'s and perhaps they also mentioned NFS being faster too. This is not (entirely) true for a 3B2. RFS is quite reasonable on a 3B2, esp. over Starlan-10. Socket libraries, to the best of my knowledge, are implemented on top of STREAMS/TLI interfaces, thus introduce another layer of abstraction to plow through. NFS, if you can get it, may be faster, but that's got nothing to do with the underlying transport, but rather that NFS doesn't offer complete filesystem semantics, where RFS does, and that takes a bit more effort to do correctly. -- Greg A. Woods woods@robohack.UUCP VE3TCP GAW Cons. & UniForum Canada +1 416 443-1734 [home] Toronto, Ontario; CANADA
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 4 Jul 93 16:55:13 From: bataller@dogie.macc.wisc.edu (Erik Bataller) To: comp.protocols.ppp,comp.unix.admin,comp.sys.sun.admin,comp.protocols.tcp-ip,comp.sys.sun.apps,comp.sys.sun.hardware Subject: dp-2.3 Supra(and/or Prac. Peripherals) modem configuration files
Hello Y'all, I have recently setup dp-2.3 on my Sparc 10 model 41 running SunOS 4.1.3. I was wondering if any out there had done this and if they could send me their Supra specific files. Turns out I am having a difficult time making the supra talk to much. I suppose I have become spoiled, my Practical Peripherals 14.4 fxsa has basically been able to automagically attach to most things, that is the full auto-negotiation at configuration switches have worked well for me. The files I am interested in are: script files modem files for either modem and anything else you may thing would be helpful. Thanks in advance, Please reply directly to me, I will post a summary. Erik -- !! Erik M. Bataller | Phone: (414) 242-0347 | Univ. of Wi., Osh Kosh !! Academic Computing Services | 800 Algoma Blvd., 307 Dempsey, !! Osh Kosh, Wi. 54901-8602 | Internet: Bataller@sol.acs.uwosh.edu !! Bitnet: Bataller@oshkoshw.bitnet
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Sun, 4 Jul 93 12:56:00 +0200 From: rune.mossige@euronetis.no (Rune Mossige) To: comp.protocols.tcp-ip Subject: SCO 3.2v2.2 -> 3.2v4.1
I've just come onto a very strange problem. We have two SDI 80486 machines running SCO unix. One is running 3.2v4.1 and the other is running 3.2v2.2 I upgrading the 3.2v2.2 box to v4.1, but after the upgrade, I was not able to get contact with the network. Nothing at all. No ping, no telnet, nothing. I could ping and telnet myself, but nothing else. I even copied the whole /etc directory from the working machine, but still nothing. I spent several hours looking at various files, and could not find anything unusual. In the end I had to reinstall 3.2v2.2 from the backup tape. The only reason I'd want to upgrade, is to have NFS 1.2 with it's NIS utilities. I have to admit that I do not know very much about SCO, so there might be something I have missed. I followd the manual that told me to first remove NFS, LLI and TCP/IP and then install from original discs. I hate to give up, but after spending 10 hours on saturday, I had yo give up. I've successfully installed/upgraded several Sun boxes (SunOS) and RS6000's with AIX, and they all work. Does anyone have any hints or tips of what I am doing wrong?? Please respond with e-mail to rune.mossige#euronetis.no or rmossige@halnet.com Rune Mossige * 1st 1.11 #274 * Never let a fool kiss you, or a kiss fool you...
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 04 Jul 1993 20:56:35 GMT From: bai@iesd.auc.dk (Bo Nygaard Bai) To: comp.protocols.tcp-ip Subject: How to trace duplicate IP addresses using a PC running DOS or SCO?
I have a problem with my two SCO Unix boxes reporting duplicate IP addresses on each other. (A reports that B's IP is duplicated and vise versa) Is there any free software that i can use to trace the Ethernet address of the (other :-) offender? My network administrator is sure that the IP numbers i use are free, so it could be a SCO Unix problem. Has anybody had similar problems on SCO. I hate the fact that SCO does not report the two ethernet numbers. They must have them to detect the duplicate....DAMIT! Any help will be appreciated. I'll summarize if i get enough info. -- .___ o .__ | | Bo Nygaard Bai | Department of Computer Science ,_//( |__. | | |/ | | University of Aalborg (AUC) / | \ ___| | |__ |\ nature | bai@iesd.auc.dk | DENMARK A U C
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Sun, 4 Jul 1993 23:09:04 GMT From: royc@rbdc.wsnc.org (Roy Crabtree) To: comp.protocols.tcp-ip,comp.sys.att Subject: Re: TLI
In article <1993Jul3.215551.2941@robohack.UUCP> woods@robohack.UUCP (Greg A. Woods) writes: >In article <1993Jun26.231521.16079@sporran.uucp> tim@sporran.uucp (Tim Fry) writes: >> In article <C97313.8zx@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes: >> > First, whether TLI is on top of STREAMS or not depends entirely on the >> >implementation, which I don't believe was specified. It has nothing to do with >> >TLI per se. >> >> I concur that the TLI may not be implemented on top of STREAMS, but I have to >> say that I've yet to see an implementation where it wasn't. > >See the AT&T 3B1 Starlan-1 package for an example.... > >BTW, someone earlier "concluded" that RFS & TLI would be slower than >using socket()'s and perhaps they also mentioned NFS being faster too. I was one. > >This is not (entirely) true for a 3B2. RFS is quite reasonable on a >3B2, esp. over Starlan-10. Socket libraries, to the best of my I did no tmentiuon RFS being slow on STARLAN; I did mention NFS usually outperforming it, speedwise. Although NFS CPU usage tends to be about 35% higher on a StarServer E 2SMP (4.0v3.1, TCPiP 4.2.1.2). >knowledge, are implemented on top of STREAMS/TLI interfaces, thus RFS is on top of TLI; TLI is on top of STREAMS on 3B2. Sockets are on top of STREAM, but not on top of TLI as best I understand it; what causes the confusion is that TLI addresses via the protocol family specifications have a mapping that is 1:1 onto the TCP/IP sockets points; \x0002040238000015 000000000000.... 0002 TCP/IP address family type (INET) 0402 TCP/IP port number (1026 for RFS in this case) 38000015 being the internet address in hex (my machine at work; who can see what's wrong? 00000 .... enough hex 0's to fill 128 bits; presumed if not specified. this does _not_ imply that sockets "goes through:" TLI although it may, and in this case it might if my memory is incorrect to do the work. TCP/IP does NOT go through TLI (which is what sockets uses); TLI goes on top of TCP/IP >introduce another layer of abstraction to plow through. I do not believe this is correct, though it could be. > >NFS, if you can get it, may be faster, but that's got nothing to do UNless the RFS TLI to TCP/IP intersection is just a bit slower than direct TCP/IP connection. >with the underlying transport, but rather that NFS doesn't offer >complete filesystem semantics, where RFS does, and that takes a bit AGreed; I prefer RFS (but for several strangenesses, like 'vi' startup running slowly) because I Like to access remote devices transparently; remsh mach dd of=devname does not dot it for me; all my experience with 'remsh' has the sucker dying afdter about 45-60MB traffic. >more effort to do correctly. Yes. And as wel, CPU usage is a bit beter. Although it might interest you to know that RPC calls in theNFS domain on StarServer apparently bind through TLI. I get error messages on this. >-- > Greg A. Woods > >woods@robohack.UUCP VE3TCP GAW Cons. & UniForum Canada >+1 416 443-1734 [home] Toronto, Ontario; CANADA royc
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Mon, 05 Jul 1993 01:03:41 GMT From: mark@taylor.uucp (Mark A. Davis) To: comp.protocols.ppp,comp.unix.admin,comp.sys.sun.admin,comp.protocols.tcp-ip,comp.sys.sun.apps,comp.sys.sun.hardware Subject: Re: dp-2.3 Supra(and/or Prac. Peripherals) modem configuration files
bataller@dogie.macc.wisc.edu (Erik Bataller) writes: >Hello Y'all, > I have recently setup dp-2.3 on my Sparc 10 model 41 running >SunOS 4.1.3. I was wondering if any out there had done this and if >they could send me their Supra specific files. Turns out I am having >a difficult time making the supra talk to much. My advice is to drop the Supra NOW. I have been fighting two of them for almost a year. The speakers died, they have trouble negotiating with other modems, they "freak out" too often, etc.... > I suppose I have become >spoiled, my Practical Peripherals 14.4 fxsa has basically been able to >automagically attach to most things, that is the full auto-negotiation >at configuration switches have worked well for me. EXACTLY. I just TRASHED one of the Supra's and replaced it with a Practical Perhiperals and it works great now.... I just which it had a display like the Supra's. -- /--------------------------------------------------------------------------\ | Mark A. Davis | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 | | Sys.Administrator| Computer Services | mark@taylor.wyvern.com .uucp | \--------------------------------------------------------------------------/
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Mon, 5 Jul 1993 02:08:44 GMT From: bcutter@paradyne.com (Brooks Cutter) To: comp.protocols.tcp-ip,comp.unix.admin Subject: Re: Equal hostnames for multiple interfaces?
In <C95Jxq.8Go@wang.com> Tom Fitzgerald <fitz@wang.com> wrote:
>> each ip address should have it's own, unique hostname. also, be sure to
>> modify rc and/or rc.local to ifconfig both addresses.
>Could you expand on this a little? The one-name-per-host advocates have
>posted believable explanations for their viewpoint; one-name-per-interface
>fans seem to be posting bald statements with no explanation.
The above wasn't my posting but...
The reason why we are using a unique name for each interface is because
we have those servers provide NIS server to clients on multiple segments..
If "server" had interfaces on 1, 2, and 3 - then by only using one name
for all three interfaces, all the clients on two segments will go through
the router to access the server... The answer is of course to use RIP
so the clients will discover the local interfaces - but there are problems
with RIP in our environment and we haven't had the time to spend solving
them - And we need a solution now.
So what we currently do is call one of the interfaces "server" and
setup names or aliases for each of the interface with the hostname (ex:
"server") and append the interface number ("server1", etc) -- Then we
setup the client's fstab, etc to use the local segment number, and
in the automounter setup the interfaces to look like replicated
servers - so it pings the RPC Null procedure, and the first one to
respond (presumably the local interface), gets service...
We'd like to use DNS to resolve hostname to IP address mappings -
but I don't believe (or I don't know) that DNS will optimize
the returned address based on the client's IP address (ie:
try to return a server IP address on the same segment as the
requestor)
(I put two interface numbers (with the same name) in our NIS hosts file
and did a ypmatch on the name - the address returned depended on the
order in the host file, unfortunately...)
>One-name-per-host works fine here. I can see why "sortlist" might be
>needed in some /etc/named.boot files, to prevent X.25 interfaces from being
>favored over FDDI interfaces, but that works. (In fact, I use sortlist all
>over the place, listing networks from fastest to slowest.)
We plan to put all our servers on a private FDDI segment to support
compute servers, and for automounting on the servers... The NIS servers
and client use the same hosts file - We don't want the servers talking
over 10BaseT and we don't want the clients going through the router to
get on the FDDI segment, when they are locally attached via UTP...
It's the same problem - and unfortunately I only see the current solution..
(I wonder if Hesoid does Name/address mappings and if so does
optimization based on segment number...?)
--
Brooks Cutter (I: bcutter@paradyne.com) (U: ...uunet!pdn!bcutter)
Unix System Administrator, Engineering Services
AT&T Paradyne, Largo Florida
(Opinions expressed are my own and do not reflect those of my employer)
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Mon, 5 Jul 1993 13:26:44 EDT From: Peter M. Weiss <PMW1@psuvm.psu.edu> To: comp.protocols.tcp-ip Subject: Re: what is a router anyway?
Many Q&A concerning basic networking questions have been stored in a
file maintained by John Wobus of Syracuse University.
"syr.edu also has a copy of the BIG-LAN "FAQ" memo (answers to frequently
asked questions) under the path information/big-lan/big-lan.faq"
I'm enclosing the Table of Contents (see #5.3).
-------
BIG-LAN Frequently Asked Questions
Last Updated: February 14, 1993
Acknowledgements: A lot of people provided information for me and I freely
admit that I have not recorded the list of names. Thanks to all.
Contents
--------
I. About BIG-LAN
II. Explanation of this Memo
III. Sources of Information on Campus Networks
1. Must-Read Sources
2. A Few General Sources
3. LISTSERV Mailing Lists
4. Internet Mailing Lists
5. USENET/Netnews Groups
6. Anonymous FTP-based Archive Sites
7. LISTSERV-based Archive Sites
8. RFCs (Internet "Request For Comments")
9. Other Useful Online Papers
10. Sources of Protocol Documents
11. Useful Free Software
12. Books
13. Periodicals
14. Training Courses
15. Conferences
IV. Basic Glossary on Campus Networks
V. Frequently Asked Questions on Campus Networks
1. What is the difference between Ethernet and IEEE 802.3?
2. What is encapsulation? What do I have to know about it?
3. How do I know whether to use a router or a bridge?
4. How do I know whether to use a bridge or a repeater? How many
repeaters may I put on an Ethernet?
5. Should I use "manageable" hubs, concentrators, etc on my LAN?
6. Which LAN technology should I use? Arcnet? FDDI? Token Ring? 10BASE-T?
7. What is the ideal cable to install in a new building?
8. What is the ideal cable to install between buildings on a campus?
9. Whose routers are recommended?
10. Whose bridges are recommended?
11. Whose Ethernet equipment are recommended?
12. Whose Token Ring equipment are recommended?
13. Whose FDDI equipment are recommended?
14. What PC network software is recommended?
15. What protocols should run on a campus-wide LAN?
16. What software is recommended for managing a campus-wide LAN?
17. What terminal server is recommended?
18. Whose troubleshooting equipment are recommended?
19. What security products should I buy?
20. Should the names of devices on my campus LAN have subdomains?
21. Should client stations use POP? Should they use just SMTP? Should
I use some non-TCP/IP protocol for mail to/from client stations?
22. Should I enable SQE/heartbeat?
/Pete (pmw1@psuvm.psu.edu)
--
Peter M. Weiss +1 814 863 1843
31 Shields Bldg. -- Penn State Univ -- University Park, PA USA 16802-1202
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Mon, 5 Jul 1993 10:15:25 GMT From: Steinar.Haug@runit.sintef.no (Steinar Haug) To: comp.protocols.tcp-ip Subject: Re: How to trace duplicate IP addresses using a PC running DOS or SCO?
> I have a problem with my two SCO Unix boxes reporting duplicate IP
> addresses on each other. (A reports that B's IP is duplicated and vise
> versa)
>
> Is there any free software that i can use to trace the Ethernet
> address of the (other :-) offender?
Sure, if you have a Sun or DEC workstation available.
On the Sun, you have 'etherfind' available as standard (or 'snoop' if you
run Solaris 2.x). On both Sun and DEC workstations you can run the wonderful
'tcpdump' program, available from ftp.ee.lbl.gov. tcpdump can help you a lot
when debugging network problems. I have enclosed the manual page below.
Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no
----------------------------------------------------------------------
.\" @(#) $Header: tcpdump.1,v 1.40 92/01/29 16:56:02 mccanne Exp $ (LBL)
.\"
.\" Copyright (c) 1988, 1989, 1990, 1991, 1992
.\" The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that: (1) source code distributions
.\" retain the above copyright notice and this paragraph in its entirety, (2)
.\" distributions including binary code include the above copyright notice and
.\" this paragraph in its entirety in the documentation or other materials
.\" provided with the distribution, and (3) all advertising materials mentioning
.\" features or use of this software display the following acknowledgement:
.\" ``This product includes software developed by the University of California,
.\" Lawrence Berkeley Laboratory and its contributors.'' Neither the name of
.\" the University nor the names of its contributors may be used to endorse
.\" or promote products derived from this software without specific prior
.\" written permission.
.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
.\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
.\"
.TH TCPDUMP 1 "4 Jan 1992"
.SH NAME
tcpdump \- dump traffic on a network
.SH SYNOPSIS
.na
.B tcpdump
[
.B \-deflnNOpqStvx
] [
.B \-c
.I count
] [
.B \-F
.I file
]
.br
.ti +8
[
.B \-i
.I interface
] [
.B \-r
.I file
]
[
.B \-s
.I snaplen
]
.br
.ti +8
[
.B \-w
.I file
]
.I expression
.br
.ad
.SH DESCRIPTION
.LP
\fITcpdump\fP prints out the headers of packets on a network interface
that match the boolean \fIexpression\fP.
.B Under SunOS:
You must be root to invoke \fItcpdump\fP or it must be installed
setuid to root.
.B Under Ultrix:
Any user can invoke \fItcpdump\fP once the super-user has enabled
promiscuous-mode operation using
.IR pfconfig (8).
.B Under BSD:
Access is controlled by the permissions on
.I /dev/bpf0,
etc.
.SH OPTIONS
.TP
.B \-c
Exit after receiving \fIcount\fP packets.
.TP
.B \-d
Dump the compiled packet-matching code to standard output and stop.
.TP
.B \-e
Print the link-level header on each dump line.
.TP
.B \-f
Print `foreign' internet addresses numerically rather than symbolically
(this option is intended to get around serious brain damage in
Sun's yp server \(em usually it hangs forever translating non-local
internet numbers).
.TP
.B \-F
Use \fIfile\fP as input for the filter expression.
An additional expression given on the command line is ignored.
.TP
.B \-i
Listen on \fIinterface\fP.
If unspecified, \fItcpdump\fP searches the system interface list for the
lowest numbered, configured up interface (excluding loopback).
Ties are broken by choosing the earliest match.
.TP
.B \-l
Make stdout line buffered. Useful if you want to see the data
while capturing it. E.g.,
.br
``tcpdump\ \ \-l\ \ |\ \ tee dat'' or
``tcpdump\ \ \-l \ \ > dat\ \ &\ \ tail\ \ \-f\ \ dat''.
.TP
.B \-n
Don't convert addresses (i.e., host addresses, port numbers, etc.) to names.
.TP
.B \-N
Don't print domain name qualification of host names. E.g.,
if you give this flag then \fItcpdump\fP will print ``nic''
instead of ``nic.ddn.mil''.
.TP
.B \-O
Do not run the packet-matching code optimizer. This is useful only
if you suspect a bug in the optimizer.
.TP
.B \-p
\fIDon't\fP put the interface
into promiscuous mode. Note that the interface might be in promiscuous
for some other reason; hence, `-p' cannot be used as an abbreviation for
`ether host {localhost} or broadcast'.
.TP
.B \-q
Quick (quiet?) output. Print less protocol information so output
lines are shorter.
.TP
.B \-r
Read packets from \fIfile\fR (which was created with the -w option).
Standard input is used if \fIfile\fR is ``-''.
.TP
.B \-s
Snarf \fIsnaplen\fP bytes of data from each packet rather than the
default of 68 (with NIT, the minimum is actually 96).
68 bytes is adequate for IP, ICMP, TCP
and UDP but may truncate protocol information from name server and NFS
packets (see below). Packets truncated because of a limited snapshot
are indicated in the output with ``[|\fIproto\fP]'', where \fIproto\fP
is the name of the protocol level at which the truncation has occured.
Note that taking larger snapshots both increases
the amount of time it takes to process packets and, effectively,
decreases the amount of packet buffering. This may cause packets to be
lost. You should limit \fIsnaplen\fP to the smallest number that will
capture the protocol information you're interested in.
.TP
.B \-S
Print absolute, rather than relative, TCP sequence numbers.
.TP
.B \-t
\fIDon't\fP print a timestamp on each dump line.
.TP
.B \-tt
Print an unformatted timestamp on each dump line.
.TP
.B \-v
(Slightly more) verbose output. For example, the time to live
and type of service information in an IP packet is printed.
.TP
.B \-w
Write the raw packets to \fIfile\fR rather than parsing and printing
them out. They can later be printed with the \-r option.
Standard output is used if \fIfile\fR is ``-''.
.TP
.B \-x
Print each packet (minus its link level header) in hex.
The smaller of the entire packet or
.I snaplen
bytes will be printed.
.IP "\fI expression\fP"
.RS
selects which packets will be dumped. If no \fIexpression\fP
is given, all packets on the net will be dumped. Otherwise,
only packets for which \fIexpression\fP is `true' will be dumped.
.LP
The \fIexpression\fP consists of one or more
.I primitives.
Primitives usually consist of an
.I id
(name or number) preceded by one or more qualifiers. There are three
different kinds of qualifier:
.IP \fItype\fP
qualifiers say what kind of thing the id name or number refers to.
Possible types are
.BR host ,
.B net
and
.BR port .
E.g., `host foo', `net 128.3', `port 20'. If there is no type
qualifier,
.B host
is assumed.
.IP \fIdir\fP
qualifiers specify a particular tranfer direction to and/or from
.I id.
Possible directions are
.BR src ,
.BR dst ,
.B "src or dst"
and
.BR "src and dst" .
E.g., `src foo', `dst net 128.3', `src or dst port ftp-data'. If
there is no dir qualifier,
.B "src or dst"
is assumed.
.IP \fIproto\fP
qualifiers restrict the match to a particular protocol. Possible
protos are:
.BR ether ,
.BR ip ,
.BR arp ,
.BR rarp ,
.B tcp
and
.BR udp .
E.g., `ether src foo', `arp net 128.3', `tcp port 21'. If there is
no proto qualifier, all protocols consistent with the type are
assumed. E.g., `src foo' means `(ip or arp or rarp) src foo'
(except the latter is not legal syntax), `net bar' means `(ip or
arp or rarp) net bar' and `port 53' means `(tcp or udp) port 53'.
.LP
In addition to the above, there are some special `primitive' keywords
that don't follow the pattern:
.BR gateway ,
.BR broadcast ,
.BR less ,
.B greater
and arithmetic expressions. All of these are described below.
.LP
More complex filter expressions are built up by using the words
.BR and ,
.B or
and
.B not
to combine primitives. E.g., `host foo and not port ftp and not port ftp-data'.
To save typing, identical qualifier lists can be omitted. E.g.,
`tcp dst port ftp or ftp-data or domain' is exactly the same as
`tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'.
.LP
Allowable primitives are:
.IP "\fBdst host \fIhost\fR"
True if the IP destination field of the packet is \fIhost\fP,
which may be either an address or a name.
.IP "\fBsrc host \fIhost\fR"
True if the IP source field of the packet is \fIhost\fP.
.IP "\fBhost \fIhost\fP
True if either the IP source or destination of the packet is \fIhost\fP.
Any of the above host expressions can be prepended with the keywords,
\fBip\fP, \fBarp\fP, or \fBrarp\fP as in:
.in +.5i
.nf
\fBip host \fIhost\fR
.fi
.in -.5i
which is equivalent to:
.in +.5i
.nf
\fBether proto \fI\\ip\fB and host \fIhost\fR
.fi
.in -.5i
If \fIhost\fR is a name with multiple IP addresses, each address will
be checked for a match.
.IP "\fBether dst \fIehost\fP
True if the ethernet destination address is \fIehost\fP. \fIEhost\fP
may be either a name from /etc/ethers or a number (see
.IR ethers (3N)
for numeric format).
.IP "\fBether src \fIehost\fP
True if the ethernet source address is \fIehost\fP.
.IP "\fBether host \fIehost\fP
True if either the ethernet source or destination address is \fIehost\fP.
.IP "\fBgateway\fP \fIhost\fP
True if the packet used \fIhost\fP as a gateway. I.e., the ethernet
source or destination address was \fIhost\fP but neither the IP source
nor the IP destination was \fIhost\fP. \fIHost\fP must be a name and
must be found in both /etc/hosts and /etc/ethers. (An equivalent
expression is
.in +.5i
.nf
\fBether host \fIehost \fBand not host \fIhost\fR
.fi
.in -.5i
which can be used with either names or numbers for \fIhost / ehost\fP.)
.IP "\fBdst net \fInet\fR"
True if the IP destination address of the packet has a network
number of \fInet\fP, which may be either an address or a name.
.IP "\fBsrc net \fInet\fR"
True if the IP source address of the packet has a network
number of \fInet\fP.
.IP "\fBnet \fInet\fR"
True if either the IP source or destination address of the packet has a network
number of \fInet\fP.
.IP "\fBdst port \fIport\fR"
True if the packet is ip/tcp or ip/udp and has a
destination port value of \fIport\fP.
The \fIport\fP can be a number or a name used in /etc/services (see
.IR tcp (4P)
and
.IR udp (4P)).
If a name is used, both the port
number and protocol are checked. If a number or ambiguous name is used,
only the port number is checked (e.g., \fBdst port 513\fR will print both
tcp/login traffic and udp/who traffic, and \fBport domain\fR will print
both tcp/domain and udp/domain traffic).
.IP "\fBsrc port \fIport\fR"
True if the packet has a source port value of \fIport\fP.
.IP "\fBport \fIport\fR"
True if either the source or destination port of the packet is \fIport\fP.
Any of the above port expressions can be prepended with the keywords,
\fBtcp\fP or \fBudp\fP, as in:
.in +.5i
.nf
\fBtcp src port \fIport\fR
.fi
.in -.5i
which matches only tcp packets.
.IP "\fBless \fIlength\fR"
True if the packet has a length less than or equal to \fIlength\fP.
This is equivalent to:
.in +.5i
.nf
\fBlen <= \fIlength\fP.
.fi
.in -.5i
.IP "\fBgreater \fIlength\fR"
True if the packet has a length greater than or equal to \fIlength\fP.
This is equivalent to:
.in +.5i
.nf
\fBlen >= \fIlength\fP.
.fi
.in -.5i
.IP "\fBip proto \fIprotocol\fR"
True if the packet is an ip packet (see
.IR ip (4P))
of protocol type \fIprotocol\fP.
\fIProtocol\fP can be a number or one of the names
\fIicmp\fP, \fIudp\fP, \fInd\fP, or \fItcp\fP.
Note that the identifiers \fItcp\fP, \fIudp\fP, and \fIicmp\fP are also
keywords and must be escaped via backslash (\\), which is \\\\ in the C-shell.
.IP "\fBether broadcast\fR"
True if the packet is an ethernet broadcast packet. The \fIether\fP
keyword is optional.
.IP "\fBip broadcast\fR"
True if the packet is an IP broadcast packet. It checks for both
the all-zeroes and all-ones broadcast conventions, and looks up
the local subnet mask.
.IP "\fBether multicast\fR"
True if the packet is an ethernet multicast packet. The \fIether\fP
keyword is optional.
This is shorthand for `\fBether[0] & 1 != 0\fP'.
.IP "\fBip multicast\fR"
True if the packet is an IP multicast packet.
.IP "\fBether proto \fIprotocol\fR"
True if the packet is of ether type \fIprotocol\fR.
\fIProtocol\fP can be a number or a name like
\fIip\fP, \fIarp\fP, or \fIrarp\fP.
Note these identifiers are also keywords
and must be escaped via backslash (\\).
.IP "\fBip\fR, \fBarp\fR, \fBrarp\fR"
Abbreviations for:
.in +.5i
.nf
\fBether proto \fIp\fR
.fi
.in -.5i
where \fIp\fR is one of the above protocols.
.IP "\fBtcp\fR, \fBudp\fR, \fBicmp\fR"
Abbreviations for:
.in +.5i
.nf
\fBip proto \fIp\fR
.fi
.in -.5i
where \fIp\fR is one of the above protocols.
.IP "\fIexpr relop expr\fR"
True if the relation holds, where \fIrelop\fR is one of >, <, >=, <=, =, !=,
and \fIexpr\fR is an arithmetic expression composed of integer constants
(expressed in standard C syntax), the normal binary operators
[+, -, *, /, &, |], a length operator, and special packet data accessors.
To access
data inside the packet, use the following syntax:
.in +.5i
.nf
\fIproto\fB [ \fIexpr\fB : \fIsize\fB ]\fR
.fi
.in -.5i
\fIProto\fR is one of \fBether, ip, arp, rarp, tcp, udp, \fRor \fBicmp\fR, and
indicates the protocol layer for the index operation.
The byte offset, relative to the indicated protocol layer, is
given by \fIexpr\fR.
\fISize\fR is optional and indicates the number of bytes in the
field of interest; it can be either one, two, or four, and defaults to one.
The length operator, indicated by the keyword \fBlen\fP, gives the
length of the packet.
For example, `\fBether[0] & 1 != 0\fP' catches all multicast traffic.
The expression `\fBip[0] & 0xf != 5\fP'
catches all IP packets with options. The expression
`\fBip[2:2] & 0x1fff = 0\fP'
catches only unfragmented datagrams and frag zero of fragmented datagrams.
This check is implicitly applied to the \fBtcp\fP and \fBudp\fP
index opertations.
For instance, \fBtcp[0]\fP always means the first
byte of the TCP \fIheader\fP, and never means the first byte of an
intervening fragment.
.LP
Primitives may be combined using:
.IP
A parenthesized group of primitives and operators
(parentheses are special to the Shell and must be escaped).
.IP
Negation (`\fB!\fP' or `\fBnot\fP').
.IP
Concatenation (`\fBand\fP').
.IP
Alternation (`\fBor\fP').
.LP
Negation has highest precedence.
Alternation and concatenation have equal precedence and associate
left to right. Note that explicit \fBand\fR tokens, not juxtaposition,
are now required for concatenation.
.LP
If an identifier is given without a keyword, the most recent keyword
is assumed.
For example,
.in +.5i
.nf
\fBnot host vs and ace\fR
.fi
.in -.5i
is short for
.in +.5i
.nf
\fBnot host vs and host ace\fR
.fi
.in -.5i
which should not be confused with
.in +.5i
.nf
\fBnot ( host vs or ace )\fR
.fi
.in -.5i
.LP
Expression arguments can be passed to tcpdump as either a single argument
or as multiple arguments, whichever is more convenient.
Generally, if the expression contains Shell metacharacters, it is
easier to pass it as a single, quoted argument.
Multiple arguments are concatenated with spaces before being parsed.
.SH EXAMPLES
.LP
To print all packets arriving at or departing from \fIsundown\fP:
.RS
.nf
\fBtcpdump host sundown\fP
.fi
.RE
.LP
To print traffic between \fIhelios\fR and either \fIhot\fR or \fIace\fR:
.RS
.nf
\fBtcpdump host helios and \\( hot or ace \\)\fP
.fi
.RE
.LP
To print all IP packets between \fIace\fR and any host except \fIhelios\fR:
.RS
.nf
\fBtcpdump ip host ace and not helios\fP
.fi
.RE
.LP
To print all traffic between local hosts and hosts at Berkeley:
.RS
.nf
.B
tcpdump net ucb-ether
.fi
.RE
.LP
To print all ftp traffic through internet gateway \fIsnup\fP:
(note that the expression is quoted to prevent the shell from
(mis-)interpreting the parentheses):
.RS
.nf
.B
tcpdump 'gateway snup and (port ftp or ftp-data)'
.fi
.RE
.LP
To print traffic neither sourced from nor destined for local hosts
(if you gateway to one other net, this stuff should never make it
onto your local net).
.RS
.nf
.B
tcpdump ip and not net \fIlocalnet\fP
.fi
.RE
.LP
To print the start and end packets (the SYN and FIN packets) of each
TCP conversation that involves a non-local host.
.RS
.nf
.B
tcpdump 'tcp[13] & 3 != 0 and not src and dst net \fIlocalnet\fP'
.fi
.RE
.LP
To print IP packets longer than 576 bytes sent through gateway \fIsnup\fP:
.RS
.nf
.B
tcpdump 'gateway snup and ip[2:2] > 576'
.fi
.RE
.LP
To print IP broadcast or multicast packets that were
.I not
sent via ethernet broadcast or multicast:
.RS
.nf
.B
tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
.fi
.RE
.LP
To print all ICMP packets that are not echo requests/replies (i.e., not
ping packets):
.RS
.nf
.B
tcpdump 'icmp[0] != 8 and icmp[0] != 0"
.fi
.RE
.SH OUTPUT FORMAT
.LP
The output of \fItcpdump\fP is protocol dependent. The following
gives a brief description and examples of most of the formats.
.de HD
.sp 1.5
.B
..
.HD
Link Level Headers
.LP
If the '-e' option is given, the link level header is printed out.
On ethernets, the source and destination addresses, protocol,
and packet length are printed.
.LP
\fI(N.B.: The following description assumes familiarity with
the SLIP compression algorithm described in RFC-1144.)\fP
.LP
On SLIP links, a direction indicator (``I'' for inbound, ``O'' for outbound),
packet type, and compression information are printed out.
The packet type is printed first.
The three types are \fIip\fP, \fIutcp\fP, and \fIctcp\fP.
No further link information is printed for \fIip\fR packets.
For TCP packets, the connection identifier is printed following the type.
If the packet is compressed, its encoded header is printed out.
The special cases are printed out as
\fB*S+\fIn\fR and \fB*SA+\fIn\fR, where \fIn\fR is the amount by which
the sequence number (or sequence number and ack) has changed.
If it is not a special case,
zero or more changes are printed.
A change is indicated by U (urgent pointer), W (window), A (ack),
S (sequence number), and I (packet ID), followed by a delta (+n or -n),
or a new value (=n).
Finally, the amount of data in the packet and compressed header length
are printed.
.LP
For example, the following line shows an outbound compressed TCP packet,
with an implicit connection identifier; the ack has changed by 6,
the sequence number by 49, and the packet ID by 6; there are 3 bytes of
data and 6 bytes of compressed header:
.RS
.nf
\fBO ctcp * A+6 S+49 I+6 3 (6)\fP
.fi
.RE
.HD
ARP/RARP Packets
.LP
Arp/rarp output shows the type of request and its arguments. The
format is intended to be self explanatory.
Here is a short sample taken from the start of an `rlogin' from
host \fIrtsg\fP to host \fIcsam\fP:
.RS
.nf
.sp .5
\f(CWarp who-has csam tell rtsg
arp reply csam is-at CSAM\fP
.sp .5
.fi
.RE
The first line says that rtsg sent an arp packet asking
for the ethernet address of internet host csam. Csam
replies with its ethernet address (in this example, ethernet addresses
are in caps and internet addresses in lower case).
.LP
This would look less redundant if we had done \fBtcpdump \-n\fP:
.RS
.nf
.sp .5
\f(CWarp who-has 128.3.254.6 tell 128.3.254.68
arp reply 128.3.254.6 is-at 02:07:01:00:01:c4\fP
.fi
.RE
.LP
If we had done \fBtcpdump \-e\fP, the fact that the first packet is
broadcast and the second is point-to-point would be visible:
.RS
.nf
.sp .5
\f(CWRTSG Broadcast 0806 64: arp who-has csam tell rtsg
CSAM RTSG 0806 64: arp reply csam is-at CSAM\fP
.sp .5
.fi
.RE
For the first packet this says the ethernet source address is RTSG, the
destination is the broadcast address, the type field
contained hex 0806 (type ETHER_ARP) and the total length was 64 bytes.
.HD
TCP Packets
.LP
\fI(N.B.:The following description assumes familiarity with
the TCP protocol described in RFC-793. If you are not familiar
with the protocol, neither this description nor tcpdump will
be of much use to you.)\fP
.LP
The general format of a tcp protocol line is:
.RS
.nf
.sp .5
\fIsrc > dst: flags data-seqno ack window urgent options\fP
.sp .5
.fi
.RE
\fISrc\fP and \fIdst\fP are the source and destination IP
addresses and ports. \fIFlags\fP are some combination of S (SYN),
F (FIN), P (PUSH) or R (RST) or a single `.' (no flags).
\fIData-seqno\fP describes the portion of sequence space covered
by the data in this packet (see example below).
\fIAck\fP is sequence number of the next data expected the other
direction on this connection.
\fIWindow\fP is the number of bytes of receive buffer space available
the other direction on this connection.
\fIUrg\fP indicates there is `urgent' data in the packet.
\fIOptions\fP are tcp options enclosed in angle brackets (e.g., <mss 1024>).
.LP
\fISrc, dst\fP and \fIflags\fP are always present. The other fields
depend on the contents of the packet's tcp protocol header and
are output only if appropriate.
.LP
Here is the opening portion of an rlogin from host \fIrtsg\fP to
host \fIcsam\fP.
.RS
.nf
.sp .5
\s-2\f(CWrtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
rtsg.1023 > csam.login: . ack 1 win 4096
rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
csam.login > rtsg.1023: . ack 2 win 4096
rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1\fP\s+2
.sp .5
.fi
.RE
The first line says that tcp port 1023 on rtsg sent a packet
to port \fIlogin\fP
on csam. The \fBS\fP indicates that the \fISYN\fP flag was set.
The packet sequence number was 768512 and it contained no data.
(The notation is `first:last(nbytes)' which means `sequence
numbers \fIfirst\fP
up to but not including \fIlast\fP which is \fInbytes\fP bytes of user data'.)
There was no piggy-backed ack, the available receive window was 4096
bytes and there was a max-segment-size option requesting an mss of
1024 bytes.
.LP
Csam replies with a similar packet except it includes a piggy-backed
ack for rtsg's SYN. Rtsg then acks csam's SYN. The `.' means no
flags were set.
The packet contained no data so there is no data sequence number.
Note that the ack sequence
number is a small integer (1). The first time \fBtcpdump\fP sees a
tcp `conversation', it prints the sequence number from the packet.
On subsequent packets of the conversation, the difference between
the current packet's sequence number and this initial sequence number
is printed. This means that sequence numbers after the
first can be interpreted
as relative byte positions in the conversation's data stream (with the
first data byte each direction being `1'). `-S' will override this
feature, causing the original sequence numbers to be output.
.LP
On the 6th line, rtsg sends csam 19 bytes of data (bytes 2 through 20
in the rtsg \(-> csam side of the conversation).
The PUSH flag is set in the packet.
On the 7th line, csam says it's received data sent by rtsg up to
but not including byte 21. Most of this data is apparently sitting in the
socket buffer since csam's receive window has gotten 19 bytes smaller.
Csam also sends one byte of data to rtsg in this packet.
On the 8th and 9th lines,
csam sends two bytes of urgent, pushed data to rtsg.
.HD
.B
UDP Packets
.LP
UDP format is illustrated by this rwho packet:
.RS
.nf
.sp .5
\f(CWactinide.who > broadcast.who: udp 84\fP
.sp .5
.fi
.RE
This says that port \fIwho\fP on host \fIactinide\fP sent a udp
datagram to port \fIwho\fP on host \fIbroadcast\fP, the Internet
broadcast address. The packet contained 84 bytes of user data.
.LP
Some UDP services are recognized (from the source or destination
port number) and the higher level protocol information printed.
In particular, Domain Name service requests (RFC-1034/1035) and Sun
RPC calls (RFC-1050) to NFS.
.HD
UDP Name Server Requests
.LP
\fI(N.B.:The following description assumes familiarity with
the Domain Service protocol described in RFC-1035. If you are not familiar
with the protocol, the following description will appear to be written
in greek.)\fP
.LP
Name server requests are formatted as
.RS
.nf
.sp .5
\fIsrc > dst: id op? flags qtype qclass name (len)\fP
.sp .5
\f(CWh2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)\fP
.sp .5
.fi
.RE
Host \fIh2opolo\fP asked the domain server on \fIhelios\fP for an
address record (qtype=A) associated with the name \fIucbvax.berkeley.edu.\fP
The query id was `3'. The `+' indicates the \fIrecursion desired\fP flag
was set. The query length was 37 bytes, not including the UDP and
IP protocol headers. The query operation was the normal one, \fIQuery\fP,
so the op field was omitted. If the op had been anything else, it would
have been printed between the `3' and the `+'.
Similarly, the qclass was the normal one,
\fIC_IN\fP, and omitted. Any other qclass would have been printed
immediately after the `A'.
.LP
A few anomalies are checked and may result in extra fields enclosed in
square brackets: If a query contains an answer, name server or
authority section,
.IR ancount ,
.IR nscount ,
or
.I arcount
are printed as `[\fIn\fPa]', `[\fIn\fPn]' or `[\fIn\fPau]' where \fIn\fP
is the appropriate count.
If any of the response bits are set (AA, RA or rcode) or any of the
`must be zero' bits are set in bytes two and three, `[b2&3=\fIx\fP]'
is printed, where \fIx\fP is the hex value of header bytes two and three.
.HD
UDP Name Server Responses
.LP
Name server responses are formatted as
.RS
.nf
.sp .5
\fIsrc > dst: id op rcode flags a/n/au type class data (len)\fP
.sp .5
\f(CWhelios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)\fP
.sp .5
.fi
.RE
In the first example, \fIhelios\fP responds to query id 3 from \fIh2opolo\fP
with 3 answer records, 3 name server records and 7 authority records.
The first answer record is type A (address) and its data is internet
address 128.32.137.3. The total size of the response was 273 bytes,
excluding UDP and IP headers. The op (Query) and response code
(NoError) were omitted, as was the class (C_IN) of the A record.
.LP
In the second example, \fIhelios\fP responds to query 2 with a
response code of non-existent domain (NXDomain) with no answers,
one name server and no authority records. The `*' indicates that
the \fIauthoritative answer\fP bit was set. Since there were no
answers, no type, class or data were printed.
.LP
Other flag characters that might appear are `\-' (recursion available,
RA, \fInot\fP set) and `|' (truncated message, TC, set). If the
`question' section doesn't contain exactly one entry, `[\fIn\fPq]'
is printed.
.LP
Note that name server requests and responses tend to be large and the
default \fIsnaplen\fP of 96 bytes may not capture enough of the packet
to print. Use the \fB\-s\fP flag to increase the snaplen if you
need to seriously investigate name server traffic. `\fB\-s 128\fP'
has worked well for me.
.HD
NFS Requests
.LP
Sun NFS (Network File System) requests and replies are printed as:
.RS
.nf
.sp .5
\fIsrc.xid > dst.nfs: len op args\fP
\fIsrc.nfs > dst.xid: reply stat len\fP
.sp .5
\f(CWvs.e2766 > helios.nfs: 136 readdir fh 6.5197 8192 bytes @ 0
helios.nfs > vs.e2766: reply ok 384
vs.e2767 > helios.nfs: 136 lookup fh 6.5197 `RCS'\fP
.sp .5
.fi
.RE
In the first line, host \fIvs\fP sends a transaction with id \fIe2766\fP
to \fIhelios\fP (note that the number following the src host is a
transaction id, \fInot\fP the source port). The request was 136 bytes,
excluding the UDP and IP headers. The operation was a \fIreaddir\fP
(read directory) on file handle (\fIfh\fP) 6.5197. 8192 bytes are
read, starting at offset 0. \fIHelios\fP replies `ok' with 384
bytes of data. (The design of Sun's RPC protocol makes it difficult to
interpret replies. I don't bother.)
.LP
In the third line, \fIvs\fP asks \fIhelios\fP to lookup the name
`\fIRCS\fP' in directory file 6.5197. Note that the data printed
depends on the operation type. The format is intended to be self
explanatory (at least, to me) if read in conjunction with
an NFS protocol spec.
.LP
Note that NFS requests are very large and the above won't be printed
unless \fIsnaplen\fP is increased. I use `\fB\-s 192\fP' to watch
NFS traffic.
.HD
KIP Appletalk (DDP in UDP)
.LP
Appletalk DDP packets encapsulated in UDP datagrams are de-encapsulated
and dumped as DDP packets (i.e., all the UDP header information is
discarded). The file
.I /etc/atalk.names
is used to translate appletalk net and node numbers to names.
Lines in this file have the form
.RS
.nf
.sp .5
\fInumber name\fP
\f(CW1.254 ether
16.1 icsd-net
1.254.110 ace\fP
.sp .5
.fi
.RE
The first two lines give the names of appletalk networks. The third
line gives the name of a particular host (a host is distinguished
from a net by the 3rd octet in the number \-
a net number \fImust\fP have two octets and a host number \fImust\fP
have three octets.) The number and name should be separated by
whitespace (blanks or tabs).
The
.I /etc/atalk.names
file may contain blank lines or comment lines (lines starting with
a `#').
.LP
Appletalk addresses are printed in the form
.RS
.nf
.sp .5
\fInet.host.port\fP
\f(CW144.1.209.2 > icsd-net.112.220
office.2 > icsd-net.112.220
jssmag.149.235 > icsd-net.2\fP
.sp .5
.fi
.RE
(If the
.I /etc/atalk.names
doesn't exist or doesn't contain an entry for some appletalk
host/net number, addresses are printed in numeric form.)
In the first example, NBP (DDP port 2) on net 144.1 node 209
is sending to whatever is listening on port 220 of net icsd node 112.
The second line is the same except the full name of the source node
is known (`office'). The third line is a send from port 235 on
net jssmag node 149 to broadcast on the icsd-net NBP port (note that
the broadcast address (255) is indicated by a net name with no host
number \- for this reason it's a good idea to keep node names and
net names distinct in /etc/atalk.names).
.LP
NBP (name binding protocol) and ATP (Appletalk transaction protocol)
packets have their contents interpreted. Other protocols just dump
the protocol name (or number if no name is registered for the
protocol) and packet size.
\fBNBP packets\fP are formatted like the following examples:
.RS
.nf
.sp .5
\s-2\f(CWicsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186\fP\s+2
.sp .5
.fi
.RE
The first line is a name lookup request for laserwriters sent by net icsd host
112 and broadcast on net jssmag. The nbp id for the lookup is 190.
The second line shows a reply for this request (note that it has the
same id) from host jssmag.209 saying that it has a laserwriter
resource named "RM1140" registered on port 250. The third line is
another reply to the same request saying host techpit has laserwriter
"techpit" registered on port 186.
\fBATP packet\fP formatting is demonstrated by the following example:
.RS
.nf
.sp .5
\s-2\f(CWjssmag.209.165 > helios.132: atp-req 12266<0-7> 0xae030001
helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
jssmag.209.165 > helios.132: atp-req 12266<3,5> 0xae030001
helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
jssmag.209.165 > helios.132: atp-rel 12266<0-7> 0xae030001
jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002\fP\s+2
.sp .5
.fi
.RE
Jssmag.209 initiates transaction id 12266 with host helios by requesting
up to 8 packets (the `<0-7>'). The hex number at the end of the line
is the value of the `userdata' field in the request.
.LP
Helios responds with 8 512-byte packets. The `:digit' following the
transaction id gives the packet sequence number in the transaction
and the number in parens is the amount of data in the packet,
excluding the atp header. The `*' on packet 7 indicates that the
EOM bit was set.
.LP
Jssmag.209 then requests that packets 3 & 5 be retransmitted. Helios
resends them then jssmag.209 releases the transaction. Finally,
jssmag.209 initiates the next request. The `*' on the request
indicates that XO (`exactly once') was \fInot\fP set.
.HD
IP Fragmentation
.LP
Fragmented Internet datagrams are printed as
.RS
.nf
.sp .5
\fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB+)\fR
\fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB)\fR
.sp .5
.fi
.RE
(The first form indicates there are more fragments. The second
indicates this is the last fragment.)
.LP
\fIId\fP is the fragment id. \fISize\fP is the fragment
size (in bytes) excluding the IP header. \fIOffset\fP is this
fragment's offset (in bytes) in the original datagram.
.LP
The fragment information is output for each fragment. The first
fragment contains the higher level protocol header and the frag
info is printed after the protocol info. Fragments
after the first contain no higher level protocol header and the
frag info is printed after the source and destination addresses.
For example, here is part of an ftp from arizona.edu to lbl-rtsg.arpa
over a CSNET connection that doesn't appear to handle 576 byte datagrams:
.RS
.nf
.sp .5
\s-2\f(CWarizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
arizona > rtsg: (frag 595a:204@328)
rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560\fP\s+2
.sp .5
.fi
.RE
There are a couple of things to note here: First, addresses in the
2nd line don't include port numbers. This is because the TCP
protocol information is all in the first fragment and we have no idea
what the port or sequence numbers are when we print the later fragments.
Second, the tcp sequence information in the first line is printed as if there
were 308 bytes of user data when, in fact, there are 512 bytes (308 in
the first frag and 204 in the second). If you are looking for holes
in the sequence space or trying to match up acks
with packets, this can fool you.
.LP
A packet with the IP \fIdon't fragment\fP flag is marked with a
trailing \fB(DF)\fP.
.HD
Timestamps
.LP
By default, all output lines are preceded by a timestamp. The timestamp
is the current clock time in the form
.RS
.nf
\fIhh:mm:ss.frac\fP
.fi
.RE
and is as accurate as the kernel's clock (e.g., \(+-10ms on a Sun-3).
The timestamp reflects the time the kernel first saw the packet. No attempt
is made to account for the time lag between when the
ethernet interface removed the packet from the wire and when the kernel
serviced the `new packet' interrupt (of course,
with Sun's lousy clock resolution this time lag is negligible.)
.SH "SEE ALSO"
traffic(1C), nit(4P), bpf(4)
.SH AUTHORS
Van Jacobson (van@helios.ee.lbl.gov),
Craig Leres (leres@helios.ee.lbl.gov) and
Steven McCanne (mccanne@helios.ee.lbl.gov), all of
Lawrence Berkeley Laboratory, University of California, Berkeley, CA.
.SH BUGS
The clock resolution on most Suns is pathetic (20ms).
If you want to use the timestamp to generate some of the important
performance distributions (like packet interarrival time) it's best
to watch something that generates packets slowly (like an Arpanet
gateway or a MicroVax running VMS).
.LP
NIT doesn't let you watch your own outbound traffic, BPF will.
We recommend that you use the latter.
.LP
\fItcpdump\fP for Ultrix requires Ultrix version 4.0 or later; the kernel
has to have been built with the \fIpacketfilter\fP pseudo-device driver
(see
.IR packetfilter (4)).
As of this writing, Ultrix does not let you
watch either your own outbound or inbound traffic.
.LP
Under SunOS 4.1, the packet capture code (or Streams NIT) is not what
you'd call efficient. Don't plan on doing much with your Sun while
you're monitoring a busy network.
.LP
On Sun systems prior to release 3.2, NIT is very buggy.
If run on an old system, tcpdump may crash the machine.
.LP
Some attempt should be made to reassemble IP fragments or, at least
to compute the right length for the higher level protocol.
.LP
Name server inverse queries are not dumped correctly: The (empty)
question section is printed rather than real query in the answer
section. Some believe that inverse queries are themselves a bug and
prefer to fix the program generating them rather than tcpdump.
.LP
Apple Ethertalk DDP packets could be dumped as easily as KIP DDP
packets but aren't.
Even if we were inclined to do anything to promote the use of
Ethertalk (we aren't), LBL doesn't allow Ethertalk on any of its
networks so we'd would have no way of testing this code.
.LP
A packet trace that crosses a daylight savings time change will give
skewed time stamps (the time change is ignored).
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Mon, 5 Jul 1993 10:46:59 GMT From: chetanm@visionware.co.uk (Chetan Mistry) To: comp.protocols.tcp-ip Subject: KEEPALIVE option for tcp sockets
Can the KEEPALIVE option for tcp sockets be switched on ??
My program sets KEEPALIVE succesfully with the following
int optval = 1;
if (setsockopt(sock, SOL_SOCKET, SO_KEEPALIVE, (char *)&optval,
sizeof(int)) < 0)
perror("tcp:setsockopt for keepalive failed");
My program then successfully connects to the remote machine and waits
in a select() loop with readfds set. However if the remote machine
crashes or drops the connection, the select() does not return. According
to the man pages the select() should return TRUE but then the following
read() or write() should fail. (I don't specify a timeout for select()).
Do I have to set the KEEPALIVE option at a different level ?
How often are the KEEPALIVE packets sent ? Can I change this timeout ?
Cheers in advance
Chet
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 93 16:07:34 EDT From: joltes@husc10.harvard.edu (Richard Joltes) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: NFS or other fileserver protocols
I am attempting to link a small group of 4 PCs and 1 Mac using only TCP/IP (no Novell!) and need to know one thing: is there a facility for implementing something like PCNFSD on one server PC so that the other "client" systems can access the server's drives transparently (i.e. as if they were local, using virtual "D:" or other drive designators)? I've examined FTP Software's Interdrive add-on to PC/TCP, but it requires a Sun or other NFS server. I need to do the same thing without the Sun! Does such a creature exist currently? If there are any public domain or shareware packages that will do this, that would be great. Commercial stuff is also an option. Please respond via e-mail and I can summarize if there's interest. Thanks in advance. -------------------------------------------------------------------------------- Dick Joltes joltes@husc.harvard.edu Harvard University Science Center
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 1993 13:52:53 GMT From: trier@odin.ins.cwru.edu (Stephen C. Trier) To: comp.protocols.tcp-ip Subject: Re: any "middleware" API products
[I cut down on the wide cross-posting.] In article <C96D0q.2wv@brunel.ac.uk> Robert.Turner@brunel.ac.uk (Robert Turner) writes: >That's about it. It's a addition to 'normal' sockets, not a replacement. Well, I'm not sure I'd agree with that, but it is a minor point. A DOS TCP/IP stack might not have a BSD sockets-like interface but could have a Windows Sockets interface anyway. Windows Sockets is simply a standard way to talk to TCP/IP stacks while in Microsoft Windows. It would be silly for it to be available under BSD-derived Unix, since Unix already has the BSD sockets interface. (Keep in mind that while Windows Sockets was inspired by BSD sockets, the two are not identical.) One could write programs to run in both environments, but it would take as much work as making any program run in both Unix and Windows. (The flow-of-control, memory management, and terminal I/O models are radically different, making this portability non-trivial.) I don't think Windows Sockets fits what the original questioner wanted as "middleware" -- the only source I've heard of for such a "middleware" abstraction layer in networking is to write it yourself. Take your programmer who is most skilled at abstraction and give him a couple of months to design and implement a standard "middleware" layer which can then be used in your products. The most common approach seems to be the obvious one -- hide all network calls in a nice, per-application, "network calls" module. If you design that module right, porting to another network suite becomes a matter of writing a drop-in replacement. This isn't as elegant as writing a standard intermediate layer, but it is the way the problem tends to be solved. -- Stephen Trier (trier@ins.cwru.edu - MIME OK) Network Software Engineer IRIS/INS/T Case Western Reserve University
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 1993 14:43:16 GMT From: trier@odin.ins.cwru.edu (Stephen C. Trier) To: comp.protocols.tcp-ip Subject: Re: KEEPALIVE option for tcp sockets
In article <1993Jul5.104659.25388@visionware.co.uk> chetanm@visionware.co.uk (Chetan Mistry) writes: >However if the remote machine crashes or drops the connection, the select() >does not return. According to the man pages the select() should return TRUE >but then the following read() or write() should fail. It will fail eventually, but it will take 10 minutes or 2 hours, depending on the vintage of the OS. This timeout cannot be changed per-application in current Unixes. This was the subject of a debate not two weeks ago and previously a few months ago, so it is probably a sore subject by now. Regardless of The Way It Should Be, an immediate solution is to add some sort of polling to your application so that it periodically sends its own keep-alive NOP packets to the other side. Another solution is to live with it. :-( Stephen -- Stephen Trier (trier@ins.cwru.edu - MIME OK) Network Software Engineer IRIS/INS/T Case Western Reserve University
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: Mon, 5 Jul 1993 16:23:33 GMT From: cej@world.std.com (Craig E Jackson) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was Re: RFC 1191 compliance)
Just to throw my oar into this discussion: 1. Several persons have gotten hysterical about corrupt printouts. Randy from QMS has mentioned that he supports multiple protocol stacks. Most likely, one of those stacks is NetWare; NetWare *does* rely on a reliable link layer. I think that Novell stockholders will testify that such a reliance is not an instant formula for commercial failure. 2. I don't know what QMS is working on, but there *are* fast printers out there. Xerox was doing 2 pages/second 13-14 years ago, with 11/34s and 8080s. A Postscript web press was announced recently. (A web press is the big mutha with the huge spinning drums on which they print books, etc.) 3. As others have said, a simple 16-bit checksum just isn't that good. I would suggest that it is insufficient to be the primary error check for any IP data link layer. 4. Lots of people have quoted TCP speeds for this processor or that. Few have mentioned how much of the processor was left for the application(s) when running at such speeds. I would suspect that a printer vendor would prefer that a very high percentage of the processor be delivered to PDL interpretation and imaging. -- Craig Jackson cej@world.std.com
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Mon, 5 Jul 1993 17:01:45 GMT From: cyrus@netcom.com (Cyrus Azar) To: comp.protocols.tcp-ip Subject: what is a router anyway?
Could someone out in netland clarify a pretty basic question?
I need to link two remote sites via some type of bridge/router to allow
TCP/IP traffic to flow between them.
What conditions would dictate one or the other?
Are there some "standard" definitions of bridge and router capability
that can help guide my choice? If I say I need a router, what am I
really saying?
Any help would be sincerely appreciated.
Thanks,
-cyrus
__________________________________________________________________________
Cyrus Azar cyrus@netcom.com
--
__________________________________________________________________________
Cyrus Azar cyrus@netcom.com
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 93 17:20:09 GMT From: roy@mchip00.med.nyu.edu (Roy Smith) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was Re: RFC 1191 compliance)
cej@world.std.com (Craig E Jackson) writes: > 4. Lots of people have quoted TCP speeds for this processor or that. Few > have mentioned how much of the processor was left for the application(s) > when running at such speeds. I would suspect that a printer vendor would > prefer that a very high percentage of the processor be delivered to PDL > interpretation and imaging. Van Jacobson used to saturate ethernets running TCP with a Sun-3/50, which is a 16 MHz 68020, no cache. I suspect that compared to the cost of everything else in a printer fast enough to worry about the speed of TCP checksumming over ethernet, a cacheless 16 MHz 68020's worth of MIPS would just get lost in the noise. -- Roy Smith <roy@nyu.edu> Hippocrates Project, Department of Microbiology, Coles 202 NYU School of Medicine, 550 First Avenue, New York, NY 10016 "This never happened to Bart Simpson."
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 05 Jul 1993 17:54:17 GMT From: bai@iesd.auc.dk (Bo Nygaard Bai) To: comp.protocols.tcp-ip Subject: Re: How to trace duplicate IP addresses using a PC running DOS or SCO?
>>>>> On Mon, 5 Jul 1993, Steinar.Haug@runit.sintef.no (Steinar Haug) said: Haug> Sure, if you have a Sun or DEC workstation available. Haug> On the Sun, you have 'etherfind' available as standard (or 'snoop' if you Haug> run Solaris 2.x). Thanks any way, but the reason i want a snoop program for a PC is that i would hate to have to drag my home computer (Sun SLC) to work. My employer insists on using PC's running DOS or SCO *sigh*. Haug> On both Sun and DEC workstations you can run the wonderful Haug> 'tcpdump' program, available from ftp.ee.lbl.gov. tcpdump can help you a lot Haug> when debugging network problems. I have enclosed the manual page below. [...a very long man page left out...perhaps more appropriate as e-mail?] I found the tcpdump program by using archie, but it needs a BSD system. SCO looses again... I have found out that the problem was two nearby PC's using the same IP numbers. I am still very interrested in a snoop/etherfind/tcpdump program for a PC running DOS or SCO though, as I am now experiencing severe performance problems and freqent hangs on the SCO boxes. -- .___ o .__ | | Bo Nygaard Bai | Department of Computer Science ,_//( |__. | | |/ | | The University of Aalborg (AUC)/ | \ ___| | |__ |\ nature | bai@iesd.auc.dk | DENMARK A U C
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Mon, 5 Jul 1993 18:20:45 GMT From: emurphy@cs.uno.edu (Edward Murphy) To: comp.protocols.tcp-ip Subject: (FYI) NCSA Telnet and the D-Link DE200 ethernet card
Howdy. I've posted several messages regarding problems I was having in getting NCSA Telnet (2.3.06) to work with a D-Link DE200 ethernet card. Well, thanks to a very helpful response, the problem was solved. Solution: The hardware option in the config.tel file should have been set to "packet". The NCSA manual doesn't mention anything about the DE200 card. I had tried several options including "ne2000" and "generic", but they didn't seem to work. Regards and thanks to all those who replied, Ed Murphy
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Mon, 5 Jul 1993 22:22:40 GMT From: dkelly@esinc.uucp (Dwight Kelly) To: comp.protocols.tcp-ip Subject: Slip quest
I have installed slip-4.1 on a Sparc 2 running SunOS 4.1.3. The modem is a Telebit Worldblazer running a fixed 38400 baud to the computer and 9600 baud to PSI.NET. Everything seems to work ok; except syslog is telling me: Jul 5 18:09:22 webco vmunix: slipencode: overrun many, many times. What is happening? -- Dwight Kelly Essential Technical Services, Inc. 3375 Summit Trail Cumming, GA 30131 (404) 889-2848 (404) 889-2624 fax
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: Tue, 6 Jul 1993 00:55:33 GMT From: marka@syd.dms.CSIRO.AU (Mark Andrews) To: comp.protocols.tcp-ip Subject: Re: Reverse remote name server help?
In article <16BFFD92A.DELLA@lexmark.com> DELLA@lexmark.com writes: >We are attempting to have our primary name server refer to another primary >name server for reverse address resolution. For some reason we cannot. >We've played in the named.boot file and also named.rev file >to find where we might possibly place a record and what the format >of this record might be (to no avail). > >After looking through the RFC 883 and other UNIX documentation, >we have been unsuccessful in doing this thing. >We are running AIX 3.2 on an RS/6000. > >Here is what we need to resolve: > My name server is the primary name server for the abc.123.com domain. > Another name server is the primary name server for the def.123.com > domain. I want to be able to resolve an IP address that is > defined on the other name server from my name server. > >i.e. 'host 157.184.29.2' > >Thanks in advance. >========================================================================= >Paul L. Della Maggiora della@lexmark.com Firstly are you one or off the Internet? It looks like you are behind a firewall. If you are off you will need to establisth 'root' nameservers. These nameservers contain the glue that holds the DNS altogether. i.e create a root zone with at least the following information @ IN SOA machine1.lexmac.com. user.machine1.lexmac.com. ( 1 1000 1000 1000000 10000 ) IN NS machine1.lexmac.com. IN NS machine2.lexmac.com. 84.157.in-addr.arpa. IN NS machine3.lexmac.com. IN NS machine4.lexmac.com. lexmac.com. IN NS machine5.lexmac.com. IN NS machine6.lexmac.com. * IN MX 0 external_mail_gateway.lexmac.com. machine1.lexmac.com. IN A XXX.XXX.XXX.XXX machine2.lexmac.com. IN A XXX.XXX.XXX.XXX machine3.lexmac.com. IN A XXX.XXX.XXX.XXX machine4.lexmac.com. IN A XXX.XXX.XXX.XXX machine5.lexmac.com. IN A XXX.XXX.XXX.XXX machine6.lexmac.com. IN A XXX.XXX.XXX.XXX and add it to named.boot on machine1 and machine2 e.g. primary . file_containing_zone machine3 and machine4 are configured as nameservers for 84.157.in-addr.arpa. Say machine3 in the primary then it will have a line in named.boot like "primary 84.157.in-addr.arpa file_containing_84_157_zone" and machine4 will have a line like "secondary 84.157.in-addr.arpa XXX.XXX.XXX.XXX file_containing_84_157_zone" where XXX.XXX.XXX.XXX is the IP address of machine3 If you are on the internet you need to register the namservers that server the reverse zone 84.157.in-addr.arpa. This can be done by sending mail to hostmaster@internic.net. Mark.
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: Tue, 6 Jul 1993 05:12:22 GMT From: dls@mentor.cc.purdue.edu (David L Stevens) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was RFC 1191 compliance)
I really hate to encourage this discussion anymore, but I guess I'm not old and wise enough to *not* put in some observations. 1) Weird and unlikely hardware failure scenarios are at best a straw man argument. Ok, suppose the board DMA's bogus data into the driver buffer. Sure, TCP checksums will catch it. But suppose you have the (my guess) much more likely hardware faulure of failed memory chips in any of the (often multiple) copies of the data up to and including the user buffer itself. It doesn't catch it, and if the enviroment is one in which not doing checksums doubles performance, it's obviously better to leave the Ethernet checksum as one on the data. 2) I believe vjs suggested doing the checksum via special purpose chips rather than in software. Great! Why not put those on an Ethernet board and do them on the packets as they arrive... oh, they're already there and already done, now, aren't they? The whole point... I'm not at all advocating that checksums should not be used, or that it's worth a hack to not compute them. But some of the arguments I've seen for keeping them don't seem to have much support in reality to me. Under the conditions of the original post, a TCP checksum *is* mostly redundant and is *not* worth a significant reduction in throughput for the infinitesimal cases it would catch (versus the number of cases it still wouldn't). If anyone was designing the system from scratch as an integrated whole to just do printing on a LAN, there wouldn't be 2 checksums on every part of the packet. B U T..... The great thing about using TCP in the first place-- in fact, the whole point-- is that it allows your customers and/or you to extend the system or use it in ways you might not anticipate today. That means that full compliance with the protocol is a good idea. That is, if you want to keep your customers. Further, one of those extensions might be to use it on a non-ethernet medium that doesn't do checksumming, or to use it on a wide-area network where who knows what sort of battering might go on. Having an end-to-end checksum is almost a necessity, then, and that is the only argument I've seen that makes any sense. So what if in 1986 one machine somewhere, after hundreds of billions of packets, had some funny Ethernet DMA problem that the TCP checksum caught! How much data, by comparison, has not been reliably delivered because of any number of other hardware failures, not to mention bugs in the TCP and/or user program software in that time frame? Answer: a *LOT*. So, two handy rules of thumb: 1) If the world will end if one bit is incorrect and is delivered to an application once every trillion packets, don't use TCP. Don't use Ethernet. Don't use any computer I've ever heard of, or any large software or hardware system I've ever heard of. In fact, don't build it at all; humanity will thank you. 2) If you're printing bitmaps of pamphlets for the "Nixon in '96" campaign and one of the pixels is the wrong color, but it prints twice as fast, your customers would probably rather you left out checksums. Though they'd like it much more if you got a real processor to run it on, or a decent TCP where the checksum speed doesn't dominate in the first place. If you want to *claim* compliance without losing the speed, take the VJS approach of using an "outboard" checksummer-- the one on the Ethernet board, with a little fiddling. Subtract off the contribution from the headers and add in the pseudo header to whatever the Ethernet checksum gets you. You avoid resumming the data-- handy for very large packets, I suppose. But if there's a DMA problem, the planet might end [see ROT #1]. Are we done now? -- +-DLS (dls@mentor.cc.purdue.edu)
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: Tue, 6 Jul 93 06:52:55 GMT From: gljones@nyx.cs.du.edu (Glenn Jones) To: comp.protocols.tcp-ip Subject: TCP Packet Prioritization
I am looking for TCP/IP protocol stack developers who have implemented the packet prioritization scheme. In particular, I am looking for an implementation on SUN, IBM, HP, SGI, DEC or other workstation class machines. I can be reached at glennesys@delphi.com Thanks in advance Glenn -- Glenn Jones E-Systems Inc. glennesys@delphi.com Garland Division ----------------------------------------------------------
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: Tue, 6 Jul 1993 09:33:27 GMT From: gnn@cs.utwente.nl (George Neville-Neil) To: comp.protocols.tcp-ip,comp.dcom.lans,comp.windows.open-look,alt.toolkits.xview Subject: New version of xv_ping with a minor bug fix...
Hi Folks, I just put up a new version of xv_ping, an XView 3.0 client to maintain a list of the "upness" of hosts on an IP internet using ICMP messages, on pegasus.cs.utwente.nl:pub/bandwidth/xv_ping.tar.Z . This has one minor bug fix, in that the icons for up and down were being munged on certain architectures with different byte ordering than my DecStation. Everything is now of the right type etc. and the bug is fixed. Later, George -- Once you get to 25 you can rent a car anywhere in the world, and nothing else matters. -- Max Rochlin
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: Tue, 6 Jul 1993 10:19:15 GMT From: dganit@gemini.math.tau.ac.il (Amitay Dganit) To: comp.protocols.tcp-ip Subject: AS/400 connectivity ?
How can we connect AS/400 to Unix workstations ? Are there any TCP/IP implementations for the IBM AS/400 ? or are there any gateways that do the trick ?
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: Tue, 6 Jul 1993 10:54:40 GMT From: xjeldc@lustorfs.ldc.lu.se (Jan Engvald LDC) To: comp.protocols.tcp-ip Subject: Re: How to trace duplicate IP addresses using a PC running DOS or SCO?
>I have a problem with my two SCO Unix boxes reporting duplicate IP
>addresses on each other. (A reports that B's IP is duplicated and vise
>versa)
>Is there any free software that i can use to trace the Ethernet
>address of the (other :-) offender?
Yes, you can use PDTBUILD which is part of the PDCLKSET package. It will
build tables which map hostname, IP number and Ethernet address for all
hosts on a net. Any duplicates will be marked, so they are easily found.
The readme.1st file appended below.
>My network administrator is sure that the IP numbers i use are free,
Maybe not the case this time, but remember that if you use free IP numbers
but on the wrong net and it is connected to a router with proxy arp
turned on, many programs will report duplicate IP number conflict.
This is because if they send an ARP packet to themselves they normally don't
expect an answer, beeing on the wrong arm the ROUTER will answer.
Jan E LDC
========================================================================
PDCLKSET sets the time and date of the PC clock using a TIME server.
It has daylight saveing (summer time) algorithms for most of the world.
It can use BOOTP to get IP number and other info.
PDCLKSET talks to the network card via a packet driver.
PDCLKSET can assign the proper normal or dls timezone name to
an environment variable (TZ is used by most systems).
There is also a very powerful buildt in ping/echo client and server giving
important statistics on delay, load and packet loss.
The PDTBUILD program, which is included in the ZIP package, looks
at all ARP broadcasts and generates hardware address tables with all the IP
hosts on this (sub)net. It detects IP and hardware address duplication.
And still, PDCLKSET is so small (13 KB) you can use it even on
diskette-only PCs.
For more info, see file PDCLKSET.DOC.
PDCLKxxx.ZIP is available at msdos.ftp.sunet.se:pub/network/pdclkset,
ftp.lu.se:pub/network/pdclkset, wsmr-simtel20.army.mil:PD1:<MSDOS.PKTDRVR>,
oak.oakland.edu:pub/msdos/pktdrvr, wuarchive.wustl.edu:mirrors/msdos/pktdrvr,
nic.funet.fi:pub/msdos/networks/pktdrvr, and probably other Simtel mirror
archives.
Happy timesetting!
_____________________________________________________________________________
Jan Engvald, Lund University Computing Center, Box 783, S-220 07 LUND, Sweden
Telephone: +46 46 107458, Telefax: +46 46 138225, Telex: 33533 LUNIVER S
E-mails: Jan.Engvald@ldc.lu.se, xjeldc@seldc52, psi%2403732202020::xjeldc
_____________________________________________________________________________
Jan Engvald, Lund University Computing Center, Box 783, S-220 07 LUND, Sweden
Telephone: +46 46 107458 Telefax: +46 46 138225 Telex: 33533 LUNIVER S
E-mail: Jan.Engvald@ldc.lu.se
X.400: G=Jan/S=Engvald/O=ldc/PRMD=lu/ADMD=sunet/C=se
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 93 11:32:23 GMT From: ercm20@festival (Sam Wilson) To: comp.protocols.tcp-ip Subject: Re: How to trace duplicate IP addresses using a PC running DOS or SCO?
Bo Nygaard Bai (bai@iesd.auc.dk) wrote: : I have a problem with my two SCO Unix boxes reporting duplicate IP : addresses on each other. (A reports that B's IP is duplicated and vise : versa) : Is there any free software that i can use to trace the Ethernet : address of the (other :-) offender? : My network administrator is sure that the IP numbers i use are free, : so it could be a SCO Unix problem. Has anybody had similar problems on : SCO. I hate the fact that SCO does not report the two ethernet : numbers. They must have them to detect the duplicate....DAMIT! Have a look in the ARP caches of the SCO boxes (I assume you can do that - apologies if the 'arp' command is another BSD-ism that SCO left out). It's not a very good check, but you will get one of the MAC addresses of the offenders and, if you keep looking at irregular intervals, you might spot the other(s). Just a thought. Sam Wilson Network Services Division Computing Services, The University of Edinburgh Edinburgh, Scotland, UK
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 93 11:49:31 GMT From: jordan@IMSI.COM (Jordan Hayes) To: comp.protocols.tcp-ip Subject: Re: KEEPALIVE option for tcp sockets
Chetan Mistry <chetanm@visionware.co.uk> writes: However if the remote machine crashes or drops the connection, the select() does not return. According to the man pages the select() should return TRUE but then the following read() or write() should fail ... Which man page are you refering to? In all Unix implementations that I know of, if the keepalive timer goes off, the socket is marked as invalid, but select() does not return. If you want to do something about it, you'd need to schedule a timer to go off and check the status of the socket, closing it if necessary. I use FIONREAD (an otherwise useless concept) to reap kept-alive-now-dead sockets. It's cheap, it's easy, and it will return -1 if the socket has been torn down ... /jordan
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: Tue, 6 Jul 93 12:50:29 GMT From: cliffb@cjbsys.bdb.com (cliff bedore) To: comp.protocols.tcp-ip Subject: Re: How to trace duplicate IP addresses using a PC running DOS or SCO?
In article <BAI.93Jul5185417@loke.iesd.auc.dk> bai@iesd.auc.dk (Bo Nygaard Bai) writes: >>>>>> On Mon, 5 Jul 1993, Steinar.Haug@runit.sintef.no (Steinar Haug) said: > >Haug> Sure, if you have a Sun or DEC workstation available. >Haug> On the Sun, you have 'etherfind' available as standard (or 'snoop' if you >Haug> run Solaris 2.x). > >Thanks any way, but the reason i want a snoop program for a PC is that >i would hate to have to drag my home computer (Sun SLC) to work. My >employer insists on using PC's running DOS or SCO *sigh*. > >Haug> On both Sun and DEC workstations you can run the wonderful >Haug> 'tcpdump' program, available from ftp.ee.lbl.gov. tcpdump can help you a lot >Haug> when debugging network problems. I have enclosed the manual page below. > >[...a very long man page left out...perhaps more appropriate as e-mail?] > >I found the tcpdump program by using archie, but it needs a BSD >system. SCO looses again... > >I have found out that the problem was two nearby PC's using the same >IP numbers. I am still very interrested in a snoop/etherfind/tcpdump >program for a PC running DOS or SCO though, as I am now experiencing >severe performance problems and freqent hangs on the SCO boxes. > >-- >.___ o .__ | | Bo Nygaard Bai | Department of Computer Science ,_//( >|__. | | |/ | | The University of Aalborg (AUC)/ | \ >___| | |__ |\ nature | bai@iesd.auc.dk | DENMARK A U C There is a program called netwatch that run on DOS using packet drivers that will give a reasonable indication of what is happening on your ethernet. Easily smart enough to let you see harware addresses and TCP/IP addresses. Used to be on omnigate.clarkson.edu. It's free and depending upon your PC and eithernet card will give you at least several hundred packets per second. There is also another DOS/packet driver based program called the BEHOLDER from the netherlands. Sorry but I don't remember an address for this Cliff -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20840 cliffb@cjbsys.bdb.com
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: Tue, 6 Jul 1993 13:20:39 GMT From: loss@fs7.ECE.CMU.EDU (Doug Loss) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: NFS or other fileserver protocols
In article <1993Jul5.160734.25517@husc14.harvard.edu> joltes@husc10.harvard.edu (Richard Joltes) writes: >I am attempting to link a small group of 4 PCs and 1 Mac using only TCP/IP (no >Novell!) and need to know one thing: is there a facility for implementing >something like PCNFSD on one server PC so that the other "client" systems can >access the server's drives transparently (i.e. as if they were local, using >virtual "D:" or other drive designators)? > >I've examined FTP Software's Interdrive add-on to PC/TCP, but it requires a >Sun or other NFS server. I need to do the same thing without the Sun! Does >such a creature exist currently? > >If there are any public domain or shareware packages that will do this, that >would be great. Commercial stuff is also an option. > I'm posting this because I think it's of general interest. SOS is a public domain NFS server program for MS-DOS. The PC that SOS is running on is dedicated, and can't be used as a user node while it's exporting its filesystem to other machines. If you do an archie search on "sos" I'm sure you'll find a lot of sites that have it. Doug Loss loss@husky.bloomu.edu
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 1993 13:56:40 GMT From: whalenm@tsg.com (Matthew Whalen) To: comp.protocols.tcp-ip Subject: SL/IP for Windows 3.1
A friend is looking for a SL/IP client for his PC Windows 3.1 machine. Since I only deal with workstations and macs, I couldn't offer advice, but promised to ask around for him. If anyone has suggestions on slip clients for windows 3.1, he'd appreciate hearing them. His email address is: staylor@nas.edu many thanks -matthew ____ equal rights, not special rights whalenm@tsg.com \ / (NeXTMail OK) \/ Only dead fish swim with the stream. ---------------------------------------------------------------- (My actions/words in no way reflect those of my employer.)
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: Tue, 6 Jul 1993 14:27:48 GMT From: toaiari@tlon.cirfid.unibo.it (Alessandro Toaiari) To: comp.protocols.tcp-ip Subject: Problems with RPC DES Authentication!!
I've a very big problem with RPC DES Authentication with SunOS. I've a clien-server structure and I need some security mechanism between client and server. I've used DES Authentication and I manage to notify - calling Authdes_create() to fill client's field cl_auth - the client's DES key to the server. Unfortunatelly I don't know where server places information about its authentication and about client's recognition (for example client's nickname and server's encripted window time) when it replyes to client.. Moreover i don't know how to call server from client the second time. Infact if I used Authdes_create twice I obtain a duplicate key error. I'm desperate because i must solve this problem and the SunOS Network Programming Guide sais nothing about this problem. I will be grateful with anybody can help me !!! P.S. Excuse my poor english!!! Hallo everybody by Alessandro Toaiari E_Mail : toaiari@cs.unibo.it toaiari@cirfid.unibo.it
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: Tue, 06 Jul 1993 17:52:13 GMT From: debiso@westfield.win.net (Joe DeBiso) To: comp.protocols.tcp-ip Subject: Re: SCO 3.2v2.2 -> 3.2v4.1
In article <4.1494.362.0N566670@euronetis.no>, Rune Mossige (rune.mossige@euronetis.no) writes: > > >I've just come onto a very strange problem. We have two SDI 80486 >machines running SCO unix. One is running 3.2v4.1 and the other is >running 3.2v2.2 > >I upgrading the 3.2v2.2 box to v4.1, but after the upgrade, I was not >able to get contact with the network. Nothing at all. No ping, no >telnet, nothing. I could ping and telnet myself, but nothing else. I >even copied the whole /etc directory from the working machine, but >still nothing. I spent several hours looking at various files, and >could not find anything unusual. In the end I had to reinstall 3.2v2.2 >from the backup tape. The only reason I'd want to upgrade, is to have >NFS 1.2 with it's NIS utilities. I have to admit that I do not know >very much about SCO, so there might be something I have missed. I >followd the manual that told me to first remove NFS, LLI and TCP/IP and >then install from original discs. I hate to give up, but after spending >10 hours on saturday, I had yo give up. I've successfully >installed/upgraded several Sun boxes (SunOS) and RS6000's with AIX, >and they all work. > >Does anyone have any hints or tips of what I am doing wrong?? Please >respond with e-mail to >rune.mossige#euronetis.no or >rmossige@halnet.com > >Rune Mossige > > * 1st 1.11 #274 * Never let a fool kiss you, or a kiss fool you... > I did the same upgrade with the same problems! I had to rev up my tcp/ip and the firmware on my ethernet card. Call SCO and check your revs! That may solve your problem! Joe DeBiso Plantrol Systems, Ltd. Westfield, NY
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 1993 17:53:05 GMT From: kbw@helios.ath.epa.gov (Kevin B. Weinrich) To: comp.unix.admin,comp.sun.admin,comp.protocols.tcp-ip Subject: Any public programs that do some of what a Network Sniffer does?
I've got etherman, interman, and packetman from Curtin University (applause to the folk from Down Under), but I'm looking for something that will give me some of the other neat stats of a Network Sniffer, such as "Average acknowledgement time". We have a Sniffer in the next building, but due to Gov't Contracting Regulations, I am no longer able to get access to it. I would prefer to run it from my Sun, but could conceivable do it from a PC. I don't need protocols beyond TCP/IP. I would be interested in even partial work that has been done along this line, or suggestions as to how to program it myself, if it wasn't very hairy. Tips as to better places to post this would be most welcome. There doesn't seem to be anything like "comp.unix.networking" . -- Kevin Weinrich Computer Sciences Corp. kbw@helios.ath.epa.gov
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: Tue, 6 Jul 1993 19:02:18 GMT From: 47.201.0.2 (Siva Arunthavanathan) To: comp.protocols.tcp-ip Subject: help needed in multiple read and write on tcp socket
Hi everyone! I am performing multiple read and write in my program. I need to find out which socket is ready for reading, before actually reading from it. Someone told me to use select system call to find out which socket has the data. Have anyone done anything similar to this? if so I am looking for more information on select or some example codes that uses select system call. Thanks alot . (in advance) Siva
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 93 19:12:29 GMT From: rturner@imagen.com (Randy Turner) To: comp.protocols.tcp-ip Subject: Re: Path MTU Discovery
mogul@pa.dec.com (Jeffrey Mogul) writes: >In article <rturner.741408434@imagen> rturner@imagen.com (Randy Turner) writes: >> >>>>>A host using PMTU Discovery would normally advertise an MSS equal to >>>>>the first-hop MSS; that is, the MTU of the directly connected LAN >>>>>interface, less the TCP+IP header sizes. Hosts that use RFC1191 >>>>>will avoid fragmentation through that mechanism. Older hosts, at >>>>>least those that comply with RFC1122, will use MIN(received-MSS, 512) >>>>>[I could have the constant wrong] for "non-local" peers, and so >>>>>will not do anything too awful. >> Wow, that seems awfully inefficient. Something must be missing >> from this equation, either that, or one of us is talking about >> hosts and the other intermediates. >No, the formula is right. Your math is wrong. It's less efficient >than using, say, MSS = 1460 (unless the larger MSS causes fragmentation >and that causes trouble). But the net change in throughput, over a >bandwidth-limited connection, is less than 10%. (If you are limited >by the rate at which your end-hosts can process packets, then the >performance loss might be larger.) >There is a persistant myth that if one cuts the packet size by a >factor of N, throughput will drop by the same factor. Anyone with >a junior-high mathematics education can easily prove this wrong. >-Jeff I don't think the myth says that throughput will drop by the same factor, just that the throughput will drop, usually significantly. This fact also would not elude a junior high student. Also , I would think the MIN(received-MSS, 512) would be used conditionally, depending on whether or not the connection was to a host on a different network. If the host is on the same network, then this equation would never allow a TCP segment that was larger than 512 bytes. I think we will be adding the Path MTU discovery code to our in-house testbed to see what kinds of results we have with WAN connections. Randy -- ----------------------------------------------------------------------------- Randy Turner QMS, Inc. rturner@aqm.com
-----------[000079][next][prev][last][first]----------------------------------------------------
Date: Tue, 6 Jul 93 20:11:08 GMT
From: ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To: comp.protocols.tcp-ip
Subject: Re: Reverse remote name server help?The problem you are having is that there is no relationship between forward look ups (e.g., "nslookup 123.abc.com") and reverse lookups (e.g., "nslookup 1.2.3.4"). That is to say, domains don't have to map onto any one subnet or network and, conversely, different addresses in the same network or subnet might be members of different domains. You can MAKE a relationship by specifying that 123.abc.com names are always in a given subnet or network, X and, that all members of subnet or network X are members of 123.abc.com. In mathematical terms, the set of names in 123.abc.com and the set of addresses in network or subnet X are "one to one and on to" (I fudged here a little bit because aliases actually make it "many to one and on to" but in the non-alias case, my original statement holds.) So, assuming you are talking about a subnetted class B, you could define: 123.abc.com <=> class.b.subnet1 (pretend those are numbers) 456.abc.com <=> class.b.subnet2 (pretend those are numbers) In the nameserver for abc.com, you have a NS record which delegates authority for the 123.abc.com and 456.abc.com to some nameserver (even if the server resides in the same box) and alter the named.boot file accordingly. In the nameserver for the b.class.in-addr.arpa, you delegate subnet1.b.class.in-addr.arpa and subnet2.b.class.in-addr.arpa. And make sure the top level reverse name server doesn't have any entries for either subnet1 or subnet2. If you can't make a clear relationship between subdomain and subnet like this, you won't be able to delegate authority of the reverse mappings. You can delegate authority of the NAMES but the reverse mappings would have to be handled by the top level reverse name server. Charles. -- Charles Ganzhorn E/Mail: ccganzhorn@mmm.com 3M IT Network Services AT&T: +1 612 736 7122 St. Paul, MN FAX: +1 612 736 7689
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: Tue, 6 Jul 1993 21:03:38 GMT From: mbendic@nautilus.micro.umn.edu (Michael Bendickson) To: comp.protocols.tcp-ip Subject: * Help! Need an example of read/write TCP Stream Sockets *
I am having a heck of a time trying to get a message sent from my server to my client. I am using TCP with stream sockets. I can send a message from the client (via write or send) and receive if fine (via recv), but I cant flip it around. Do I need to create the sockets with the socketpair command? When I put a recv in the client, it says that it has received a message of size 0. What does that mean? Connection closed or something right? I get a return code of -1 when I try the send from the server. If there are any examples of this floating around, please email them to me. Thanks, -Mike Bendickson mbendic@mermaid.micro.umn.edu -- =============================================================================== Michael Bendickson University of Minnesota E-Mail: mbendic@mermaid.micro.umn.edu Institute of Technology ===============================================================================
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: Tue, 6 Jul 1993 21:52:57 GMT From: steve@hacker.smy.com (Stephen Youndt) To: comp.dcom.lans.ethernet,comp.protocols.tcp-ip,comp.realtime,comp.sys.ibm.pc.hardware,comp.protocols.tcp-ip.ibmpc,comp.robotics Subject: Embedded systems booting/communicating over TCP/IP
I'm sorry for the scatter shot approach (so many different newsgroups), but
I just couldn't find a single group that fit my subject.
I want to build a small data acquisition and device control system based
around a 386 that can remote boot and communicate with a host workstation
over Ethernet using TCP/IP.
The system components would include:
386SX (cheapest 32bit) Single Board Computer w/ 4-8 Meg Memory
that plugs into a passive ISA backplane
Ethernet card (8 bit) with boot ROMS
CCD Controller/Frame Grabber
Serial and Parallel ports
The system would have no local disks, but would boot and do all file access
over TCP/IP to the host.
My basic stumbling blocks are:
Can I get Ethernet boot ROMS with an IP kernel built in with a
documented call interface that I can use in my application?
Is there a good, cheap 386SX single board computer that I can use
for a project like this? Built in serial, parallel and
ethernet would be great, but I don't want VGA, keyboard,
disk controller, etc. ADC and DACs on board would be a plus,
but not required.
I'd like to build the system for ~$600 (ignoring the CCD controller which
I'll purchase separately). All cards (4 max) should be no larger than
3/4 length ISA cards.
If you have any suggestions as to where I should search, vendors, or any
other helpful comments, please send them by e-mail directly to me. If
there's interest, I'll e-mail summaries of what I get.
Thanks in advance.
Steve
P.S. For those interested, if you haven't guessed, the application
is telescope control.
--
Stephen M. Youndt | geek - n. [Perh. < dial. geek, fool < MLG geck.]
I-net: steve@hacker.smy.com | - A carnival performer whose act usually
UUCP: uunet!hacker!steve | consists of biting the head off a live
(703)978-6352 | chicken or snake.
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 1993 21:53:21 GMT From: cracraft@rice-chex.ai.mit.edu (Stuart Cracraft) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.wizards Subject: Public/Free TCP/IP for DOS/Windows/Macintosh
Is there any public/free implementation of TCP/IP for DOS, Windows, and Macintosh? Replies => cracraft@ai.mit.edu --Stuart
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: Tue, 6 Jul 1993 21:57:37 GMT From: automate@netcom.com (Competitive Automation) To: comp.protocols.tcp-ip,comp.sys.sun.admin,comp.unix.programmer Subject: Sun nit-pf STREAMS packet filtering module question
I want to use the STREAMS NIT packet filtering module to capture UDP/IP packets with a particular destination port#. (Never mind why I want to use /dev/nit instead of higher level socket -- it would take too long to explain here). This appears to be non-trivial because the packets are structured as follows: Ethernet stuff (14 bytes) IP header (20 bytes + variable length options) UDP header Data Thus the field in the UDP header on which I want to test is at a variable length from the start of the packet. The filtering module appears to provide no method to make such a test, or at least the "man" page in SunOS documentation is incomplete. But programs such as Etherfind & Snoop must be capable of making such tests (?). Does anyone know how to accomplish this? Of course, I could capture the packet and make the test in user space, but the whole point of the filtering module is its speed. Performing tests in user space is likely to lead to packet loss. Rob Stevens
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: 06 Jul 93 23:12:04 GMT From: sukvg@microsoft.com (Sukvinder Singh Gill) To: comp.protocols.tcp-ip,comp.mail.misc Subject: Re: SMTP: "500" error message closing connection
In article <adrian.1.00114531@cursci.co.uk> adrian@cursci.co.uk wrote: > In article <20rqqp$j9n@grasp1.univ-lyon1.fr> Christophe.Wolfhugel@grasp.insa-lyon.fr (Christophe Wolfhugel) writes: > >5 [12:14] wolf@grasp1:~> telnet gate1.pbi.nrc.ca smtp > >Trying... > >Connected to gate1.pbi.nrc.ca. > >Escape character is '^]'. > >220 All set, fire away > >ehlo blah > >500 Huh? > >Connection closed. > > A classic case of connecting to a Microsoft Mail SMTP Gateway.... > It's braindead - Microsoft are seemingly not going to fix it, so we > are stuck with it. > > Regards, > > Adrian Adrian, Christophe: Sorry for not responding to you earlier, I have been on holiday. Christophe is correct in stating that the Gateway should not close the connection on receiving the ehlo command. It should respond with a "command unknown response" (500) as documented in RFCs 1425, 821, and the sending side should return with either a helo or quit. A fix is available from Product Support Services. In the US dial: 206 637 9307 ( A voice message indicating the services offered) or 206 635 7702 In Europe and the rest of the world, please contact your local Microsoft Support Centre for Mail. Thanks, Sukvinder Gill Program Manager Microsoft Corp. e-mail: sukvg@microsoft.com
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: Wed, 7 Jul 1993 00:25:18 GMT From: marka@syd.dms.CSIRO.AU (Mark Andrews) To: comp.protocols.tcp-ip Subject: Re: Slip quest
In article <C9pq5s.64L@esinc.uucp> dkelly@esinc.uucp (Dwight Kelly) writes: >I have installed slip-4.1 on a Sparc 2 running SunOS 4.1.3. >The modem is a Telebit Worldblazer running a fixed 38400 baud >to the computer and 9600 baud to PSI.NET. >Everything seems to work ok; except syslog is telling me: > >Jul 5 18:09:22 webco vmunix: slipencode: overrun > >many, many times. What is happening? > > >-- >Dwight Kelly >Essential Technical Services, Inc. >3375 Summit Trail Cumming, GA 30131 >(404) 889-2848 (404) 889-2624 fax This usually maean that you have a noisy line, or the other end is sending with a MTU larger than the default 1006 bytes. You will get one "slipencode: overrun" for every packet greater than 1006 bytes and the packet will be dropped. When ever I saw this on our leased line, the phone company had been fiddling with the line. In your case I would fix the interface speed at 9600 and make sure that software flow control is turned off. Mark.
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 1993 10:09:19 -0400 From: masato@access.digex.net (J M Thompson) To: comp.protocols.tcp-ip Subject: Re: help needed in multiple read and write on tcp socket
I'd recommend the book "Advanced Programming in the UNIX Environment" by W. Richard Stevens (published by Addison-Wesley, 1992). See Chapter 12 , section on "I/O Multiplexing" for sample code. Jim Thompson
-----------[000087][next][prev][last][first]---------------------------------------------------- Date: Wed, 7 Jul 1993 03:44:27 GMT From: daniel@ing.puc.cl (Daniel Hirschberg) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: NFS or other fileserver protocols
Doug Loss (loss@fs7.ECE.CMU.EDU) wrote:
: In article <1993Jul5.160734.25517@husc14.harvard.edu> joltes@husc10.harvard.edu (Richard Joltes) writes:
: >I am attempting to link a small group of 4 PCs and 1 Mac using only TCP/IP (no
: >Novell!) and need to know one thing: is there a facility for implementing
: >something like PCNFSD on one server PC so that the other "client" systems can
: >access the server's drives transparently (i.e. as if they were local, using
: >virtual "D:" or other drive designators)?
: >
: >I've examined FTP Software's Interdrive add-on to PC/TCP, but it requires a
: >Sun or other NFS server. I need to do the same thing without the Sun! Does
: >such a creature exist currently?
: >
: >If there are any public domain or shareware packages that will do this, that
: >would be great. Commercial stuff is also an option.
: >
: I'm posting this because I think it's of general interest. SOS is a
: public domain NFS server program for MS-DOS. The PC that SOS is running
: on is dedicated, and can't be used as a user node while it's exporting
: its filesystem to other machines. If you do an archie search on "sos"
: I'm sure you'll find a lot of sites that have it.
I read somewhere that someone had run SOS in a WINDOWS' window
freeing the PC.
Hope this helps...
--
_______________________
/\ \
\_| Daniel Hirschberg J. |
| daniel@ing.puc.cl |
| Santiago, CHILE. |
| ___________________|_
\_/____________________/
-----------[000088][next][prev][last][first]---------------------------------------------------- Date: Wed, 7 Jul 1993 06:11:40 GMT From: sjanicki@us.oracle.com (Steven B. Janicki) To: comp.protocols.tcp-ip Subject: Re: SL/IP for Windows 3.1
In article <21c0ao$nbp@obelix.tsg.com> whalenm@tsg.com (Matthew Whalen) writes: >Path: oracle!gatekeeper.us.oracle.com!decwrl!decwrl!concert!gatech!howland.reston.ans.net!europa.eng.gtefsd.com!tsg.com!news >From: whalenm@tsg.com (Matthew Whalen) >Newsgroups: comp.protocols.tcp-ip >Subject: SL/IP for Windows 3.1 >Date: 6 Jul 1993 13:56:40 GMT >Organization: Telos Systems Group, Chantilly, VA >Lines: 16 >Distribution: usa >Message-ID: <21c0ao$nbp@obelix.tsg.com> >Reply-To: whalenm@tsg.com >NNTP-Posting-Host: benzene.tsg.com > A friend is looking for a SL/IP client for his PC Windows 3.1 >machine. Since I only deal with workstations and macs, I couldn't offer >advice, but promised to ask around for him. If anyone has suggestions >on slip clients for windows 3.1, he'd appreciate hearing them. His >email address is: > staylor@nas.edu >many thanks >-matthew ____ equal rights, not special rights >whalenm@tsg.com \ / >(NeXTMail OK) \/ Only dead fish swim with the stream. >---------------------------------------------------------------- >(My actions/words in no way reflect those of my employer.) FTP 'CELLO' it comes with DISTINCTS PPP/SLIP. You can use 'TRUMPET' with this as well.
-----------[000089][next][prev][last][first]---------------------------------------------------- Date: Wed, 7 Jul 1993 07:08:27 GMT From: etxmesa@eos.ericsson.se (Michael Salmon) To: comp.protocols.tcp-ip,comp.protocols.nfs Subject: Tips on alternative to NFS requested.
I am looking for an alternative to NFS, preferably TCP based. RFS seems to do what I want but I can't yet find a standard for it. All suggestions welcome. -- Michael Salmon #include <standard.disclaimer> #include <witty.saying> #include <fancy.pseudo.graphics> Ericsson Telecom AB Stockholm
-----------[000090][next][prev][last][first]---------------------------------------------------- Date: Wed, 7 Jul 1993 11:10:27 GMT From: pjulich@su102a.ess.harris.com (Paul M. Julich) To: comp.protocols.tcp-ip Subject: Portable TCP-IP Stack
I would like to locate vendors of Portable TCP-IP code. The application I have runs on a MIPS R-3000 processor with a custom Ada run-time kernal. Please respond by E-mail and I will summarize if there is enough interest. pjulich@rhino.ess.harris.com
-----------[000091][next][prev][last][first]---------------------------------------------------- Date: Wed, 7 Jul 1993 11:25:43 GMT From: ag@fokus.gmd.de (A. Gavras) To: comp.protocols.tcp-ip Subject: RT-IP need information
Hi, I heard of RT-IP (does it stand for Real-Time-IP ?) but was unable to find any further information. Can anyone point me to articles, papers or other sources that describe RT-IP ? Thanks in advance -- Anastassios Gavras, e-mail:gavras@fokus.gmd.de Tel.:+49 30 25499263 GMD-FOKUS, Hardenbergplatz 2, 10623 Berlin, Germany
-----------[000092][next][prev][last][first]---------------------------------------------------- Date: Wed, 7 Jul 1993 15:46:34 EDT From: Thomas J Cozzolino <RBNTJC@rohvm1.rohmhaas.com> To: comp.protocols.tcp-ip Subject: Scripts to check Network health?
We are running a multi-site world-wide IP network, and so need to properly configure/manage nameservers, etc. between several groups of people and several machine types. Has anyone already written any scripts (Perl, etc.) to perodically go out to one's local WAN and resolve names, etc., and then report by E-mail to sys admins regarding the status? It would be nice if the script tried to query the host(s) by address, if name services were not available, and note that it its status report. Thanks for any help. Please reply directly to tcozz@rohmhaas.com, or directly to this newsgroup. +============================================+ | Thomas J. Cozzolino - Rohm and Haas Co. = | InterNet: tcozz@rohmhaas.com = | = | Internet Access for Everyone.. = | Isn't it time? = | = | - Opinions expressed are my own, not = | necessarily those of Rohm and Haas Company = +=====================================================+
-----------[000093][next][prev][last][first]---------------------------------------------------- Date: Wed, 7 Jul 1993 11:49:29 GMT From: chetanm@visionware.co.uk (Chetan Mistry) To: comp.protocols.tcp-ip Subject: Re: KEEPALIVE option for tcp sockets
Jordan Hayes (jordan@IMSI.COM) wrote:
: Which man page are you refering to? In all Unix implementations that I
: know of, if the keepalive timer goes off, the socket is marked as
: invalid, but select() does not return. If you want to do something
: about it, you'd need to schedule a timer to go off and check the status
: of the socket, closing it if necessary. I use FIONREAD (an otherwise
: useless concept) to reap kept-alive-now-dead sockets. It's cheap, it's
: easy, and it will return -1 if the socket has been torn down ...
Here's part of the setsockopt/getsockopt man page :-
reuse of local addresses. 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. If the process is
waiting in select(2) when the connection is broken, select()
returns true for any read or write events selected for the
socket. SO_DONTROUTE indicates that outgoing messages
The problem I'm having is that we have a tcp socket based RPC server which
talks to PC's. If the PC client program crashes, it takes the PC with it.
Its ok if your doing it between 2 Unix boxes, if the client program
crashes the kernal will close the socket and the server will get an EOF
on that socket.
The earlier posting said it will fail but would take 10mins to 2 hours.
I have left the server for half a day, and it is still waiting in the
select() loop ??
Can somebody tell me how rlogin does it. If you have an rlogin session
and the remote host your logged into crashes, the rlogin process comes
back (almost instantly) with the following message
"Connection reset by peer"
Cheers
Chet
-----------[000094][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 93 18:30:18 CST From: kodagali@wsuhub.uc.twsu.edu To: comp.protocols.tcp-ip Subject: X-Window over phone line?
Hi, I have a Sparc 2 at my workplace running SunOS 4.1.3 and Openwin 3.0. It is on an ethernet running TCP/IP. It also has a TELEBIT Worldblazer modem for dialing in. I have a PC at home which I would like to connect to the Sparc through the phone line so that I can run X-Window progs on the Sparc and display them on the PC. I have DesqView/X to convert the PC into X-terminal. I have a modem on the PC. Is this possible ? Thanks for your time. ---------------------------------------------------------- Email: kodagali@wsuhub.uc.twsu.edu
-----------[000095][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 1993 14:07:48 GMT From: welander@i4.informatik.rwth-aachen.de To: comp.protocols.tcp-ip Subject: Unexplainable measurement figures ?!
Hi ! At RWTH Aachen we are presently doing performance measurements with TCP and XTP and have come up with some rather strange results that we cannot explain. The measurements are made on an unloaded Ethernet between two SUN workstations. When the CPU is unloaded (except for the protocol) we get reasonable throughput values, but when we load the CPU with 15 background processes the spread between measured throughput is very strange. Out of 25 measurements with the same settings about 20-22 have reasonable throughbut (6-8 Mbits/s) while the remaining 3-5 transmissions show only a throuhput of 1-2 Mbit/s. The extreme low values appear at totaly random places within each set of measurements. We haven«t been able to find any reasonable explaination to this behavior, our guess so far is that it has to do with the operating system in some way (maybe the schedular) and not with the protocol implementations. If anybody has an explanation or a good guess don«t hesitate, mail it. Bjoern Welander
-----------[000096][next][prev][last][first]---------------------------------------------------- Date: Wed, 7 Jul 1993 16:07:06 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: KEEPALIVE option for tcp sockets
In article <1993Jul7.114929.9369@visionware.co.uk>, chetanm@visionware.co.uk (Chetan Mistry) writes: > Jordan Hayes (jordan@IMSI.COM) wrote: > : Which man page are you refering to? In all Unix implementations that I > : know of,... > Here's part of the setsockopt/getsockopt man page :- > ... Once again, "the setsockopt/getsockopt man page" for which system? Almost all UNIX TCP/IP systems are based on 4.2-BSD or 4.3BSD TCP/IP code, including System V Release 3 and System V Release 4. (Don't believe the USL scumbags; compare the source. The only major, modern exception I can recall is Sun's new code.) However, there have been more than one version of 4.*BSD TCP/IP code and more than one version of "the" man page just from CSRG. Of course, every vendor is compelled to change things at least a little. > ... > The earlier posting said it will fail but would take 10mins to 2 hours. > I have left the server for half a day, and it is still waiting in the > select() loop ?? > > Can somebody tell me how rlogin does it. If you have an rlogin session > and the remote host your logged into crashes, the rlogin process comes > back (almost instantly) with the following message > "Connection reset by peer" Not if you do not type anything to the rlogin client. Try it. The standard 4.*BSD rlogin client source does not turn on keepalives. It is only rlogind, the server, that does. Of course, your unspecified system may be different. Perhaps your system's rlogin client turns on keepalives. Look for the net2 rlogin source on uunet. Vernon Schryver, vjs@sgi.com
-----------[000097][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 93 16:10:30 GMT From: 1993Jul7.070827.3131@ericsson.se, , etxmesa@eos.ericsson.se writes: (rcc30@juts.amdahl.comIn article) To: comp.protocols.tcp-ip,comp.protocols.nfs Subject: Re: Tips on alternative to NFS requested.
|> I am looking for an alternative to NFS, preferably TCP based. RFS seems
|> to do what I want but I can't yet find a standard for it. All
|> suggestions welcome.
|>
RFS is defined (from an external perspective) in the SVID.
There are some technical papars circulating that desribe the implementation.
The archetypal paper was given by Andy Rifkin at USENIX, Jul 1986 in Atlanta
In principle it is a remote system call mechanism, this is how it provides
greater UNIX transparency than NFS.
==========================================================================
Richard Croucher | EMAIL rcc30@ccc.amdahl.com
| +44 252 346376
Any views, opinions expressed are my own and do not necessarily reflect
those of Open Systems Europe, or the Amdahl Corporation.
==========================================================================
-----------[000098][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 93 16:31:54 GMT From: apple@drvax3.msfc.nasa.gov (Kathleen Applegate) To: comp.protocols.tcp-ip Subject: Re: New Yorker cartoon
errol@hpgnd153.grenoble.hp.com (Errol_Inan) writes: >> "On the Internet, nobody knows you're a dog". >Bark, bark! Ruff, ruff. Sniff, sniff, sniff, sniff, sniff. ><censored> >Pant, pant, pant, .... First the cartoon, and now this dialgoue gives flesh to the oxymoron used recently to describe the Internet (Washington Post?): "remote intimacy." -- Kathleen Applegate, Sr. Analyst apple@drvax3.msfc.nasa.gov Marshall Space Flight Center Voice: (205) 544-7656
-----------[000099][next][prev][last][first]---------------------------------------------------- Date: Wed, 7 Jul 1993 17:00:14 GMT From: gsa@mercury.udev.cdc.com (gary s anderson) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was RFC 1191 compliance)
In article <C9q94M.Fuw@mentor.cc.purdue.edu>, dls@mentor.cc.purdue.edu (David L Stevens) writes: |> I really hate to encourage this discussion anymore, but I guess I'm |> not old and wise enough to *not* put in some observations. |> |> 1) Weird and unlikely hardware failure scenarios are at best a straw |> man argument. Ok, suppose the board DMA's bogus data into the |> driver buffer. Sure, TCP checksums will catch it. But suppose |> you have the (my guess) much more likely hardware faulure of |> failed memory chips in any of the (often multiple) copies of |> the data up to and including the user buffer itself. It doesn't |> catch it, and if the enviroment is one in which not doing |> checksums doubles performance, it's obviously better to leave |> the Ethernet checksum as one on the data. |> You obviously haven't played with RISC systems and their VME buses :-) The CPU, memory, and disk paths may have parity but the VME buses and peripherals have had much looser requirements. The "high performance" and/or "high power" adapters tend to have interesting problems, especially if the buses are loaded. Network adapter vendors tend to ignore (or at least they don't rush to correct the problem) their integrity problems, because the protocol checksums catch most of their short-comings. When a remote entity chooses to ignore the computed checksum, they now open a "hole" which the peer had assumed was adequately covered. NOTE - in case you want to talk about most likely problems, single bit loss has been the most prevalent problem with the few VME buses I've had the pleasure to deal with. My previous point about needing to "know" the entire path is still valid even with your arguments. You must "know" that all elements in the path (routers, bridges, peer systems, etc.) are not relying on the checksum to Cover Their A...s, befor making a unilateral decision to ignore the checksum! |> [deleted a bunch of stuff.....] I don't disagree with your philosophy, but it will be interesting to see who's "box" needs to be upgraded when the customer complains about seeing printing errors :-)
-----------[000100][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 1993 18:47:30 GMT From: rgoldstone@OAVAX.CSUCHICO.EDU (Robin, Girl Wonder) To: comp.protocols.tcp-ip,comp.mail.misc Subject: Re: SMTP: "500" error message closing connection
In article <1993Jul06.231204.16147@microsoft.com>, sukvg@microsoft.com (Sukvinder Singh Gill) writes:
>Sorry for not responding to you earlier, I have been on holiday.
>Christophe is correct in stating that the Gateway should not close
>the connection on receiving the ehlo command. It should respond with
>a "command unknown response" (500) as documented in RFCs 1425, 821, and
>the sending side should return with either a helo or quit.
>
>A fix is available from Product Support Services.
>
>In the US dial: 206 637 9307 ( A voice message indicating the services offered)
>or 206 635 7702
>
Dialing these numbers results in a message stating that your credit card
will be billed by Microsoft. This is typical Microsoft bullshit. Their
gateway contains a serious bug, as confirmed here by Microsft themselves,
yet they are charging their customers for the fix. Microsoft's SMTP gateway
has been a nightmare from day one. And now Microsoft *finally* acknowledges
the brain-dead behavior of their product, and we're supposed to pay to get
a working version! What a joke. I can't believe Sukvinder posted this
message, telling people to call the above number, where they are greeted by
a message informing them that they will be billed $150 to talk to a customer
service rep. This makes me sick.
************************************************************************
Robin Goldstone, Systems Software Specialist ____
California State University, Chico Computing Services \ /
rgoldstone@oavax.csuchico.edu \/
Closets are for clothes
-----------[000101][next][prev][last][first]---------------------------------------------------- Date: Wed, 7 Jul 1993 19:53:17 GMT From: carlson@steam.Xylogics.COM (James Carlson) To: bit.listserv.ibmtcp-l,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.servers,comp.bugs.4bsd,comp.bugs.misc Subject: Bug in many versions of TCP
IMPORTANT BUG FIX FOR TCP INPUT CODE
Xylogics has found and fixed a bug that exists in the tcp_input.c
routine in 4.4BSD and several other versions of TCP. We strongly
recommend that you examine your version of TCP for this error.
Traces of this bug occurring are available on request. Send a message
to carlson@xylogics.com with comments or requests for this data.
THE FIX:
From 4.4a BSD sys/netinet/tcp_input.c, lines 609 through 663:
/*
* States other than LISTEN or SYN_SENT.
* First check that at least some bytes of segment are within
* receive window. If segment begins before rcv_nxt,
* drop leading data (and SYN); if nothing left, just ack.
*/
todrop = tp->rcv_nxt - ti->ti_seq;
if (todrop > 0) {
if (tiflags & TH_SYN) {
tiflags &= ~TH_SYN;
ti->ti_seq++;
if (ti->ti_urp > 1)
ti->ti_urp--;
else
tiflags &= ~TH_URG;
todrop--;
}
if (todrop > ti->ti_len ||
todrop == ti->ti_len && (tiflags&TH_FIN) == 0) {
tcpstat.tcps_rcvduppack++;
tcpstat.tcps_rcvdupbyte += ti->ti_len;
/*
* If segment is just one to the left of the window,
* check two special cases:
* 1. Don't toss RST in response to 4.2-style keepalive.
* 2. If the only thing to drop is a FIN, we can drop
* it, but check the ACK or we will get into FIN
* wars if our FINs crossed (both CLOSING).
* In either case, send ACK to resynchronize,
* but keep on processing for RST or ACK.
*/
if ((tiflags & TH_FIN && todrop == ti->ti_len + 1)
#ifdef TCP_COMPAT_42
|| (tiflags & TH_RST && ti->ti_seq == tp->rcv_nxt - 1)
#endif
) {
todrop = ti->ti_len;
tiflags &= ~TH_FIN;
tp->t_flags |= TF_ACKNOW;
} else
goto dropafterack;
} else {
tcpstat.tcps_rcvpartduppack++;
tcpstat.tcps_rcvpartdupbyte += todrop;
}
m_adj(m, todrop);
ti->ti_seq += todrop;
ti->ti_len -= todrop;
if (ti->ti_urp > todrop)
ti->ti_urp -= todrop;
else {
tiflags &= ~TH_URG;
ti->ti_urp = 0;
}
}
Change this to:
/*
* States other than LISTEN or SYN_SENT.
* First check that at least some bytes of segment are within
* receive window. If segment begins before rcv_nxt,
* drop leading data (and SYN); if nothing left, just ack.
*/
todrop = tp->rcv_nxt - ti->ti_seq;
if (todrop > 0) {
if (tiflags & TH_SYN) {
tiflags &= ~TH_SYN;
ti->ti_seq++;
if (ti->ti_urp > 1)
ti->ti_urp--;
else
tiflags &= ~TH_URG;
todrop--;
}
if (todrop > ti->ti_len ||
todrop == ti->ti_len && (tiflags&TH_FIN) == 0) {
tcpstat.tcps_rcvduppack++;
tcpstat.tcps_rcvdupbyte += ti->ti_len;
/*
* If FIN is just one to the left of the window,
* then drop it.
*/
if ((tiflags & TH_FIN) && todrop == ti->ti_len + 1)
tiflags &= ~TH_FIN;
/*
* Send ACK to resynchronize, and drop any data,
* but keep on processing for RST or ACK.
*/
todrop = ti->ti_len;
tp->t_flags |= TF_ACKNOW;
} else {
tcpstat.tcps_rcvpartduppack++;
tcpstat.tcps_rcvpartdupbyte += todrop;
}
m_adj(m, todrop);
ti->ti_seq += todrop;
ti->ti_len -= todrop;
if (ti->ti_urp > todrop)
ti->ti_urp -= todrop;
else {
tiflags &= ~TH_URG;
ti->ti_urp = 0;
}
}
JUSTIFICATION OF CHANGES
In the original BSD code, if it gets through the test:
if (todrop > ti->ti_len ||
todrop == ti->ti_len && (tiflags&TH_FIN) == 0) {
Then it will generate an ack packet by setting TF_ACKNOW either through
the first clause of the following "if" statement, or when it jumps to
"dropafterack." Thus, it is valid to simply set TF_ACKNOW in both
cases.
Since both cases will ignore any data in the packet, it is valid to set
"todrop = ti->ti_len;" All of this data, since it is less than rcv_nxt,
is to the left of the window and has already been acknowledged and must
be dropped. The following m_adj call will do that.
The new code hauls these two statements out of that next "if" statement.
The "TCP_COMPAT_42" code is there to force RST (reset) packets through
the data-dropping code so that RST is handled. If this weren't done,
then the "goto dropafterack" statement would cause the RST to be
inappropriately ignored. This test is no longer needed since the new
code doesn't jump to "dropafterack."
BUG DUPLICATION SCENARIO
With this configuration:
Host A <--Enet--> Router <--X.25--> Router <--Enet--> Host B
The X.25 link must have long delays (about 1 second in our test) and be
much lower speed (about 64Kbps) than the Ethernet links used, and enough
TCP connections must be transmitting data in both directions to cause
significant packet loss and ICMP Source Quench messages on both ends.
The TCP connection that fails must be transferring data in both
directions simultaneously, and "host A" and "host B" must be identical
machines with identical timer settings.
The bug manifests itself when both host A and host B generate resent
data due to a TCP "persist" timer expiry at approximately the same time.
DESCRIPTION OF BUG
After a near-simultaneous drop of data-bearing TCP packets in each
direction and subsequent TCP send-ahead, the state is:
Reassembly queue on host A (112.0.0.55.7004):
6CE1C477 6CE1C677 6CE1C877 6CE1C921 6CE1CB21 6CE1CBBA
| | | | | |
+---------+---------+---------+---------+---------+
| Missing | 512 oct | 170 oct | 512 oct | 153 oct |
+---------+---------+---------+---------+---------+
Some TCP variables on host A:
snd_una: 4A2363B3
snd_max: 4A2367B3
rcv_nxt: 6CE1C477
rcv_max: 6CE1CBBA
Reassembly queue on host B (114.0.0.55.10400):
4A2363B3 4A2365B3 4A2367B3
| | |
+---------+---------+
| Missing | 512 oct |
+---------+---------+
Some TCP variables on host B:
snd_una: 6CE1C477
snd_max: 6CE1CBBA
rcv_nxt: 4A2363B3
rcv_max: 4A2367B3
Both hosts go into retransmit mode due to persist timer expiry, which
causes them to send segments, at almost the same time, which look like
this:
From host A: seq 4A2363B3, ack 6CE1C477, len 512
From host B: seq 6CE1C477, ack 4A2363B3, len 512
Since this is a persist timer expiry, the snd_nxt values are left at the
end of the resent data instead of the end of all sent data. Therefore,
the host A's snd_nxt is 4A2365B3 and host B's snd_nxt is 6CE1C677.
When these two segments are received by the peers, the queues are
reassembled and passed up to the application. Host A's rcv_nxt is set
to 6CE1CBBA and host B's rcv_nxt is set to 4A2367B3. Acks are then sent
out, but since the retransmit was done by a persist timer expiry and the
input ack numbers on the resent packets were old, the snd_nxt variables
aren't advanced to the end of the data. Therefore, these ack packets
are sent:
From host A: seq 4A2365B3, ack 6CE1CBBA, len 0
From host B: seq 6CE1C677, ack 4A2367B3, len 0
Now, the "todrop = tp->rcv_nxt - ti->ti_seq;" calculation in tcp_input.c
yields 0x543 on host A and 0x200 on host B when these packets are
received. Due to the bug, it executes "goto dropafterack;" on both
sides, which completely ignores the valid ack numbers in the input
packets.
At this point TCP is stuck. Subsequent resends -- due to persist or due
to excessive acks -- will send out this apparently "old" sequence number
from snd_nxt and the other side's tcp_input.c will continually drop the
data until, eventually, the connection is killed by a higher-level
timer. With the fix in place, it will instead fall through to the code
that properly flushes the output queue based on the new ack number and
updates the snd_nxt variable to the end of the newly-acked data, and
then subsequent acks will have good sequence numbers.
--
James Carlson <carlson@xylogics.com> Tel: +1 617 272 8140
Annex Software Support / Xylogics, Inc. +1 800 225 3317
53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 3159
-----------[000102][next][prev][last][first]---------------------------------------------------- Date: Wed, 7 Jul 1993 20:13:03 GMT From: raj@cup.hp.com (Rick Jones) To: comp.protocols.tcp-ip Subject: Re: Unexplainable measurement figures ?!
Well, I would expect that system loading would give such variation only if your test times were rather small. You could test the hypothesis by having each of those system load programs try to do something useful, and measure *that* time and see what the variations are. My favorite first culprit in such apparently random performance loss situations would be retransmissions. The degree to which this will affect performance will depend on a number of factors - the first would be the presence (with TCP at least, don't know about XTP) of "fast retransmit." The usefulness of this can be nullified if you have a TCP window that is only a few (<6?, maybe 5) times larger than the connection's MSS - fast retransmit relies on receiving multiple, duplicate ACKs. For example, a 4096 byte window on an Ethernet will preclude TCP fast retransmit (the MSS would likely be 1460 bytes, and 4096 / 1460 < 5) rick jones
-----------[000103][next][prev][last][first]---------------------------------------------------- Date: Wed, 7 Jul 1993 20:32:43 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was RFC 1191 compliance)
Just to beat this horse some more ...
The non-zero TCP and UDP checksum error coutners I mentioned recently
almost certainly were counting errors that occurred in traffic
that travelled routes that were completely protected by link-layer
checksums, either FDDI or Ethernet. It is almost certain that
none of the errors occurred on traffic going over less protected
56K or T1 or fractional-T1 wide area network links. I say this
based on my knowledge of the network and traffic involved.
This implies those ~100 errors
1. occurred in router memory or buses (including workstations
acting as routers, as well as various Cisco routers).
2. happened in host memory or buses.
3. were committed by various bridges or switching hubs.
4. were link layer errors not detected by the FDDI or Ethernet
checksums.
Isn't it true that cases (1) through (3) are essentially the same?
Does it matter if an error happens when a packet is being forwarded by
a router or bridge or when it happens when a packet is being sent or
received? I think it does not.
If you agree, then does it matter in any of those four cases whether
the packet was going directly from one host to its destination or if
peers were not directly connected?
In other words, what difference does it make if an error occurs on a
direct link or on a route? If it is safe to turn off TCP checksums for
a direct link then it should be about 1/(N+1) as safe to turn TCP
checksums when the peers are separated by N routers and N+1 links with
link-layer checksums.
If you accept that, then don't you also accept the statement that for
all values of N, the danger P of turning off the TCP checksum is, for
all practical purposes, the same as the danger P*(N+1) ?
In other words, non-zero `netstat` numbers are convincing evidence that
the TCP checksum is a Good Thing.
Vernon Schryver, vjs@sgi.com
-----------[000104][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 93 20:41:21 GMT From: donr@sadis05.kelly.af.mil (DONALD G. RUEBENSON II - SCST) To: comp.protocols.tcp-ip,comp.unix.admin Subject: Re: Equal hostnames for multiple interfaces?
Brooks Cutter (bcutter@paradyne.com) wrote:
: In <C95Jxq.8Go@wang.com> Tom Fitzgerald <fitz@wang.com> wrote:
: >> each ip address should have it's own, unique hostname. also, be sure to
: >> modify rc and/or rc.local to ifconfig both addresses.
: >Could you expand on this a little? The one-name-per-host advocates have
: >posted believable explanations for their viewpoint; one-name-per-interface
: >fans seem to be posting bald statements with no explanation.
: The above wasn't my posting but...
: The reason why we are using a unique name for each interface is because
: we have those servers provide NIS server to clients on multiple segments..
: If "server" had interfaces on 1, 2, and 3 - then by only using one name
: for all three interfaces, all the clients on two segments will go through
: the router to access the server... The answer is of course to use RIP
: so the clients will discover the local interfaces - but there are problems
: with RIP in our environment and we haven't had the time to spend solving
: them - And we need a solution now.
The problem you are experiencing is probably caused by trying to run
dynamic routing (routed) on hosts that should only have limited and
fixed modifications to their route tables. routed usually is not run on
hosts with only one interface; the route table is "primed" with a
default route and specific network routes as appropriate for the local
topology.
: So what we currently do is call one of the interfaces "server" and
: setup names or aliases for each of the interface with the hostname (ex:
: "server") and append the interface number ("server1", etc) -- Then we
: setup the client's fstab, etc to use the local segment number, and
: in the automounter setup the interfaces to look like replicated
: servers - so it pings the RPC Null procedure, and the first one to
: respond (presumably the local interface), gets service...
: We'd like to use DNS to resolve hostname to IP address mappings -
: but I don't believe (or I don't know) that DNS will optimize
: the returned address based on the client's IP address (ie:
: try to return a server IP address on the same segment as the
: requestor)
"Optimization" needs to be done in the IP route table, as explained
below.
: (I put two interface numbers (with the same name) in our NIS hosts file
: and did a ypmatch on the name - the address returned depended on the
: order in the host file, unfortunately...)
This behavior is not a problem in that a single interface host will only
ba able to talk to one of the ip addresses returned anyway, the one it
shares a network segment with or the one that has the most accurate
match in the route table (either network or host entry).
: >One-name-per-host works fine here. I can see why "sortlist" might be
: >needed in some /etc/named.boot files, to prevent X.25 interfaces from being
: >favored over FDDI interfaces, but that works. (In fact, I use sortlist all
: >over the place, listing networks from fastest to slowest.)
: We plan to put all our servers on a private FDDI segment to support
: compute servers, and for automounting on the servers... The NIS servers
: and client use the same hosts file - We don't want the servers talking
: over 10BaseT and we don't want the clients going through the router to
: get on the FDDI segment, when they are locally attached via UTP...
: It's the same problem - and unfortunately I only see the current solution..
: (I wonder if Hesoid does Name/address mappings and if so does
: optimization based on segment number...?)
IMHO, there is a very common misunderstanding here of the concepts and
relative function of name service (NIS,DNS) and IP routing (RIP/routed).
If I can be of assistance, please give me a call or send e-mail.
: --
: Brooks Cutter (I: bcutter@paradyne.com) (U: ...uunet!pdn!bcutter)
: Unix System Administrator, Engineering Services
: AT&T Paradyne, Largo Florida
: (Opinions expressed are my own and do not reflect those of my employer)
Don Ruebenson
Systems Analyst
(210) 980-7871
-----------[000105][next][prev][last][first]---------------------------------------------------- Date: 07 Jul 93 21:33:13 GMT From: sukvg@microsoft.com (Sukvinder Singh Gill) To: comp.protocols.tcp-ip,comp.mail.misc Subject: Re: SMTP: "500" error message closing connection
In article <1993Jul06.231204.16147@microsoft.com> sukvg@microsoft.com wrote: > In article <adrian.1.00114531@cursci.co.uk> adrian@cursci.co.uk wrote: > > In article <20rqqp$j9n@grasp1.univ-lyon1.fr> Christophe.Wolfhugel@grasp.insa-lyon.fr (Christophe Wolfhugel) writes: > > >5 [12:14] wolf@grasp1:~> telnet gate1.pbi.nrc.ca smtp > > >Trying... > > >Connected to gate1.pbi.nrc.ca. > > >Escape character is '^]'. > > >220 All set, fire away > > >ehlo blah > > >500 Huh? > > >Connection closed. > > > > A classic case of connecting to a Microsoft Mail SMTP Gateway.... > > It's braindead - Microsoft are seemingly not going to fix it, so we > > are stuck with it. > > > > Regards, > > > > Adrian > > Adrian, Christophe: > > Sorry for not responding to you earlier, I have been on holiday. > Christophe is correct in stating that the Gateway should not close > the connection on receiving the ehlo command. It should respond with > a "command unknown response" (500) as documented in RFCs 1425, 821, and > the sending side should return with either a helo or quit. > > A fix is available from Product Support Services. > > In the US dial: 206 637 9307 ( A voice message indicating the services offered) > or 206 635 7702 > > In Europe and the rest of the world, please contact your local Microsoft > Support Centre for Mail. > > Thanks, > > Sukvinder Gill > Program Manager > Microsoft Corp. > e-mail: sukvg@microsoft.com > I received a message from Robin Goldstone, with the University of California, stating that Microsoft charges customers for bug fixes. I'd like to apologize that my earlier mail did not state the process of getting Support and how it works when you are requesting a fixed version of the code. If there is a bug and you need a new version, there will be no charge! i.e. the credit card charge is refunded. For credit card holders the number is 206 635 7022 If you do not have a credit card you can reach Product Support Services by dialing 1 900 555 2100 Again the cost is refunded in this case. For further information on Product Support Services options please call 1 800 227 4679. (PSS Sales Group) There is a recorded message stating all these numbers on 206 637 9307. You may also call you local Microsoft Representative for information on Product Support Services. I hope this clarifies the situation more clearly. Thanks, Sukvinder Gill Program Manager of SMTP Gateway Technologies Microsoft Corporation e-mail: sukvg@microsoft.com
-----------[000106][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 93 21:53:27 GMT From: rturner@imagen.com (Randy Turner) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was RFC 1191 compliance)
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >Just to beat this horse some more ... >The non-zero TCP and UDP checksum error coutners I mentioned recently >almost certainly were counting errors that occurred in traffic >that travelled routes that were completely protected by link-layer >checksums, either FDDI or Ethernet. It is almost certain that >none of the errors occurred on traffic going over less protected >56K or T1 or fractional-T1 wide area network links. I say this >based on my knowledge of the network and traffic involved. >This implies those ~100 errors > 1. occurred in router memory or buses (including workstations > acting as routers, as well as various Cisco routers). > 2. happened in host memory or buses. > 3. were committed by various bridges or switching hubs. > 4. were link layer errors not detected by the FDDI or Ethernet > checksums. >Isn't it true that cases (1) through (3) are essentially the same? >Does it matter if an error happens when a packet is being forwarded by >a router or bridge or when it happens when a packet is being sent or >received? I think it does not. >If you agree, then does it matter in any of those four cases whether >the packet was going directly from one host to its destination or if >peers were not directly connected? >In other words, what difference does it make if an error occurs on a >direct link or on a route? If it is safe to turn off TCP checksums for >a direct link then it should be about 1/(N+1) as safe to turn TCP >checksums when the peers are separated by N routers and N+1 links with >link-layer checksums. >If you accept that, then don't you also accept the statement that for >all values of N, the danger P of turning off the TCP checksum is, for >all practical purposes, the same as the danger P*(N+1) ? >In other words, non-zero `netstat` numbers are convincing evidence that >the TCP checksum is a Good Thing. >Vernon Schryver, vjs@sgi.com Ok, I'll pick up the whip for the horse for awhile... I agree in part with your probabilities for router/bridge errors, but I 'm not sure I understand the conclusion you draw from the math. It seems that for increasing values of N, the probability of failure in one of the N intermediates also increases. In other words, the more pieces you have between the connected hosts, the more likely it is that one of them might screw up. For a direct link (i.e. both hosts tapped into the same Ethernet segment) your odds for failure are somewhat less. Also, I have been studying some traffic here on our network, and it appears that the bulk of our traffic is small packets (less than 1K bytes), and with small packets, the optimization techniques for checksums probably don't pay off much. In other words, for alot of this traffic, the payback for checksum optimization, or even elimination wouldn't be worth the risk. In earlier comments, it was mentioned that the checksum algorithm shouldn't really be one of the more burdensome throughput bottlenecks. However, as network media speeds increase, and MTU sizes also increase, for those vendors that don't have hardware support for checksumming, the checksum algorithm may not scale well - meaning that the link layer stuff is all much faster, but the packets are still being serialized through the same checksum algorithm. (I should note that the profiling I've done on our network was only for TCP packets. I would imagine there are huge amts of full MTU-size, fragmented Ethernet packets representing NFS UDP traffic that would be consuming cycles for checksumming, provided checksumming was enabled for these packets.) We have been using a modified version of Jacobsen's checksum algorithm, as presented in RFC 1071(?). We are now in the process of combining this algorithm with an existing buffer copy in our stack to see what gains we can achieve. My guess is, since Jacobsen's algorithm was using extensive loop unrolling, and was thereby neutralizing the 68020 I-cache advantages, we may see some improvement. Randy -- ----------------------------------------------------------------------------- Randy Turner QMS, Inc. rturner@aqm.com
-----------[000107][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Jul 1993 02:47:46 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was RFC 1191 compliance)
In article <rturner.742082007@imagen>, rturner@imagen.com (Randy Turner) writes: > ... > >If you accept that, then don't you also accept the statement that for > >all values of N, the danger P of turning off the TCP checksum is, for > >all practical purposes, the same as the danger P*(N+1) ? > I agree in part with your probabilities for router/bridge errors, > but I 'm not sure I understand the conclusion you draw from the math. > It seems that for increasing values of N, the probability of failure > in one of the N intermediates also increases. In other words, the > more pieces you have between the connected hosts, the more likely > it is that one of them might screw up. For a direct link (i.e. > both hosts tapped into the same Ethernet segment) your odds for > failure are somewhat less. Yes, you're right that I blew the calculation. I suppose it's something more like (1 - (1-P)**(N+1)) which does increase a lot faster than linearly. But when P=1E-6 and N=5, it's still very close to linear in N. (N=5 is about the upper bound on the diameter for almost all of the traffic I saw, and the error rate was around 1 in 10**5 packets). However, that wasn't my point, which was that given an observed packet error rate with <= 5 hops over CRC-safe links of around 1 in 10**5, the error rate on at least one link in the mess must be 10**6 or worse. In practice, 1 in 10**5 is about as bad as 1 in 10**6, and I think both are completely unusable for data transfers. (Of course, if you're just sending voice or pictures, you might be happy with something 100 or 1000 times worse.) Consider that you're supposed to shut down an individual station-to- station link in an FDDI ring with a detected bit error rate of 1 in 10**7 and ring bells at 10**8. > Also, I have been studying some traffic here on our network, and > it appears that the bulk of our traffic is small packets (less than > 1K bytes),... Weren't the classic numbers around 50/50 in big and small packets, whether measured in Bytes/sec or packets/sec? In recent years, we seen a lot of small packets. X-windows generates horrendous numbers of tinygrams. Even file transfer stuff like NFS involves an amazing number of bytes in small packets (getattr's, lookup's, r/w-requests). Unfortunately, media with big packets like FDDI or HIPPI do not reduce the number of small packets. They only reduce the number of large packets, and because of routers and bridges, not nearly as much as one would like or expect. Vernon Schryver, vjs@sgi.com
-----------[000108][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Jul 1993 03:04:18 GMT From: cej@world.std.com (Craig E Jackson) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was Re: RFC 1191 compliance)
In article <219ns9$p07@calvin.NYU.EDU> roy@mchip00.med.nyu.edu (Roy Smith) writes: >cej@world.std.com (Craig E Jackson) writes: >> 4. Lots of people have quoted TCP speeds for this processor or that. Few >> have mentioned how much of the processor was left for the application(s) >> when running at such speeds. I would suspect that a printer vendor would >> prefer that a very high percentage of the processor be delivered to PDL >> interpretation and imaging. > > Van Jacobson used to saturate ethernets running TCP with a Sun-3/50, >which is a 16 MHz 68020, no cache. I suspect that compared to the cost of >everything else in a printer fast enough to worry about the speed of TCP >checksumming over ethernet, a cacheless 16 MHz 68020's worth of MIPS would >just get lost in the noise. >-- >Roy Smith <roy@nyu.edu> Actually, the person who started this discussion said that what he had to work with *was* a 16MHz 68020. Also, he was trying to spiff things up without redesigning the printer hardware, so changing the processor wasn't a variable in his inquiries. (One of the reasons why processors are embedded in various things is because they can be spiffed up by changing ROMs.) I believe that when Van Jacobson got his results on the 3/50, those 68020s were pretty busy with TCP processing. -- Craig Jackson cej@world.std.com
-----------[000109][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 1993 15:57:54 -0700 From: hjb@butch.netapp.com (Consultant-Hwa Jin Bae) To: comp.protocols.tcp-ip Subject: Re: Unexplainable measurement figures ?!
In article <andreas-070793155050@freitag.informatik.rwth-aachen.de> welander@i4.informatik.rwth-aachen.de writes: >At RWTH Aachen we are presently doing performance measurements with TCP and >XTP and have come up with some rather strange results that we cannot >explain. one of the things i've noticed over the years running "benchmarks" over various tcp/ip implementations of others as well as my own is that the number thans to vary almost each time (not much but a little), and that the varying behavior doesn't seem to have a real "pattern". that is, when running tests on unix based machines... this seemed true for both tcp and xtp. but if you run the same tests on a realtime operating system implementations of the same protocols (using almost the same code), the result tend to come out precisely equal. the result is reproduced almost exactly each time, down to the microsecond. when you run multiple instantiations of the benchmarking application, you also see exactly equal amount of throughput/latency/cpu-usage per each task (or thread or whatever). this is true of both vxworks and my own little realtime os implementations of tcpip. of course, nobody knows why this happens on unix -- not! <grin> love hwajin -- Hwa-Jin Bae *IX/Realtime/Embbeded/Network/HW/SW Consultant hjb@netcom.com - Peaceful Star Project Vox: 510-536-7607 Page: 510-466-9166 hjb@netapp.com - Network Appliance hjb@hybrid.com - Hybrid Networks
-----------[000110][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 1993 11:24:44 -0400 From: frankb@epenviron.eapi.com (Frank Brock) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs,ieee.nfs Subject: SOS as a client?
can SOS provide the client side of nfs for a pc? are there any known plans to do so? frank brock
-----------[000111][next][prev][last][first]---------------------------------------------------- Date: Thu, 08 Jul 93 13:05:29 EDT From: NELSON@msu.edu (Doug Nelson) To: comp.protocols.tcp-ip Subject: Re: Would 0xFFFF ever be a TCP checksum? Comments pls.
In article <C9ut0z.D6y@raistlin.udev.cdc.com> cmclal@lizzie.arh.cdc.com (A. Sudhakarlal) writes: >During ftp sessions , client side TCP receives a packet with checksum 0xFFFF >from a Novell Flex/IP server. I am not very sure whether a TCP packet could >have checksum value 0xFFFF. I was looking into RFC 1071. And yet I can not >figure out the problem. We are having problems in file transfers. Middle of a >file transfer, connection is getting timed out. > >Please throw light on to the problem. This topic has come up before. Since a TCP checksum is defined as a 16 bit one's complement value, 0xFFFF is equivalent to 0x0000. However, since most TCPs are implemented on two's complement systems, or compute the checksum in a larger word, a special check is needed to treat them as equivalent. This check is missing from some TCPs, which likely includes the system with your client. This shortcoming often slips through a TCP implementation, since the normal ways of generating the checksum favor 0x0000 over 0xFFFF. Note that UDP, which uses the same 16 bit one's complement checksum, does not have this problem since 0x0000 is used as a special value. Doug Nelson nelson@msu.edu Network Manager Ph: (517) 353-2980 Computer Laboratory Michigan State University
-----------[000112][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 93 14:28:44 CDT From: schaubert@turtle.fisher.com To: comp.protocols.tcp-ip Subject: Need help reading TCP OOB data
am in the process of learning how to send and receive TCP urgent
(out of band) data and am having some trouble.
I have the following signal handler in my server (listening)
process
void
my_tcp_urg(int signal_id)
{
char sig_buff[200];
int size;
size = recv (newsock, sig_buff, 200, MSG_OOB);
if (size < 1)
printf ("Urgent data not ready yet, errno - %d\n",errno);
else
printf ("Urgent data received size %d char %d %c>%s\n",size,sig_buff[0], sig_buff[0], sig_buff);
urg_flag = 1;
signal(SIGURG, my_tcp_urg);
}
This signal handler gets called while the program is in the main loop
waiting on non-urgent data.
int getinput (fd, input_buffer, done)
int fd;
char *input_buffer;
{
int x;
int size;
int err;
/*
read (fd,input_buffer,700);
*/
err = 0;
x = read (fd, &input_buffer[0], 1);
if (x < 1) {
err = 1;
printf ("Got read error, errno is %d\n",errno);
if (errno == EBADF) {
shutdown(fd);
close(fd);
exit(0);
}
if (errno == EINTR && urg_flag) {
size = recv (fd, input_buffer, 1, MSG_OOB);
if (size < 0) {
printf ("Errno on recv with oob flag is %d\n",errno);
sleep(1);
size = recv (fd, input_buffer, 200, 0);
if (size < 0) {
printf ("Failed to get data from non-oob read \n");
}
}
printf ("OOB>, size %d >%s\n",size, input_buffer);
urg_flag = 0;
}
}
So when I try and use this code I am sending a few
non-urgent messages first, then an urgent one.
Here is the client screen (the server prepends ACKG and
echos whatever it received)
Cterm -- use u> to send tcp urgent data
Terminal > 111
ACKG 111
Terminal > 222
ACKG 222
Terminal > u>333
URG - send msg_oob data on socket fd 3
Terminal > 444
ACKG 444
And here is the server screen
SERVER GOT - 3 111
SERVER GOT - 3 222
Urgent data received size 1 char 0 >
Got read error, errno is 4
Errno on recv with oob flag is 22
OOB>, size 4 >333
SERVER GOT - 3 444
Ok, so this line
Urgent data received size 1 char 0 >
is from the signal handler, why is it only 1 byte?
This line
Got read error, errno is 4
is an EINTR and is the main loop breaking out of the read call
due to an interrupt
This line
Errno on recv with oob flag is 22
I don't uderstand why I am getting an
EINVAL 22 /* Invalid argument */
(my OS is AIX 3.2)
on the recv with the oob flag.
and this line
OOB>, size 4 >333
is where I give up and just read for NON-OOB data.
So can someone show me how to get multiple byte OOB messages through TCP
and handle it properly on the receive side?
Also where can I read a discussion and see some examples of leaving
data inline vs oob? The Stevens book is not quite as strong on
TCP OOB examples as it is on other areas.
thanks in advance
joel
schaubert@fisher.com
-----------[000113][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 1993 18:46:43 -0400 From: gregm@db.erau.edu (Gregory S. Miller) To: comp.protocols.tcp-ip,comp.protocols.iso Subject: Protocol Stack Author Available
My apologies to those who'd prefer not to read such things outside of
misc.jobs.*, but I'm afraid that I'm far more likely to reach the correct
audience here than there.
---
To whom it may concern:
I'm currently seeking a position involving networking systems development.
If your company is looking for someone with in-depth knowledge of networking,
specifically the lower levels of protocol stacks, please review the enclosed
resume, and get in touch with me.
As I explained above, my specialty is everything between the Data Link
and Session layers in a protocol stack. I've designed (and implemented
from scratch) two entirely seperate IP stacks, while maintaining a third
for my previous employer. I'm extremely well informed, having done
pure implementations, of how nearly every segment in a TCP/IP suite works.
In addition to protocol stack work, I've designed and developed everything
from implementations of standards (FTP, Telnet, RCP, ...) to entire networking
packages.
Although I haven't done implementations of other protocol stacks, I am
familiar with several others. I hold knowledge about many of the different
pieces of OSI, including CLNP and TP4. I've also researched the different
components of AppleTalk's stack as well. I'm proficient in many languages,
including C, C++, and Motorola assembly. I also have a general understanding
of ISDN and ATM, but have worked on no projects directly involving either.
I'm specifically seeking an ambitious company that intends to lead,
rather than follow the rest of the industry -- that is enthusiastically
planning for the future, not waiting for the future to carry them along.
- Greg Miller
-------------------------------------------------------------------
Gregory S. Miller
190 Lindenwood Drive
Exton, PA 19341
(215) 594-8756
Objective
Seeking a software engineering position dealing with networking
systems development.
Experience
Commodore International, West Chester, PA.
Software Engineer
Responsible for developing and maintaining system software
for Commodore's Amiga computers.
o Project Manager and leader of the design and development
team for a peer-to-peer networking package for the Amiga.
Responsible for nearly every part of the project's development,
including creating a comprehensive design document, laying out
and submitting project schedules, and ensuring that deadlines
were met by all involved parties. Designed and implemented
the protocol stack, the stack's API, the network filesystem,
network printing facilities, and associated user interfaces
for each, as well as other project segments.
o Member of the AS225/Release 2 development team. (AS225 is
Commodore's TCP/IP package for the Amiga.) Responsible for
various modules, including inet.library -- the protocol stack.
Redesigned the lowest levels of the protocol stack to support
SANA-II, which allowed TCP/IP operation over any SANA-II
compliant networking device (Ethernet, ARCNET, SLIP, custom,
etc.) Rewrote several of the included user utilities in
AS225 (Telnet, RCP, etc.).
o Member of the SANA-II design and development team. (SANA-II
is Commodore's Data Link layer interface standard, designed
to eliminate dependance on certain networking cards and their
particular attributes.) As part of the team, contributed to
the specification, was responsible for (and implemented)
several SANA-II device drivers to support Commodore's existing
networking hardware.
Milliluk Partnership, Lansing, MI.
Co-Owner/Operator
Developed a wide variety of applications for various platforms:
o A TCP/IP implementation for the Amiga. Designed and
implemented -everything- from the Data Link layer all the
way up through standard applciations (including clients
and servers for Telnet, FTP, etc.).
o Color Max Deluxe -- a full-featured GUI paint program,
patterned after MacPaint, and written in several thousand
lines of 6809 assembly. Voted "Product of the Year", and
ranked #1 in sales for six months.
o A suite of image manipulation tools that offered exchange
between Mac, GIF, Atari ST, and MGE file formats.
Education
Michigan Technological University, Houghton, MI.
Bachelor of Science in Electrical Engineering, Cum Laude.
References
Available upon request.
-----------[000114][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Jul 1993 13:57:25 GMT From: thurlow@convex.com (Robert Thurlow) To: comp.protocols.tcp-ip,comp.protocols.nfs Subject: Re: Tips on alternative to NFS requested.
In <1993Jul7.070827.3131@ericsson.se> etxmesa@eos.ericsson.se (Michael Salmon) writes: >I am looking for an alternative to NFS, preferably TCP based. RFS seems >to do what I want but I can't yet find a standard for it. All >suggestions welcome. I might have some suggestions if I had any clue about what problems you were trying to solve. Asking for "better" is only goung to get you noise, in my opinion, unless we know what "better" would feel like to you. Rob T -- Rob Thurlow, Convex AFS project leader Convex Computer Corporation, Richardson, TX (214) 497-4405 thurlow@convex.com
-----------[000115][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 93 18:08:19 EDT From: joltes@husc10.harvard.edu (Richard Joltes) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Summary: NFS servers for the PC
I received a number of responses to my query regarding NFS server s/w for the PC. They all basically pointed to a package called "SOSS," which provides the capability I was looking for. The following came from Francis Selkirk at FTP Software: ----------- Any NFS server, including the SOS server that Doug Loss mentioned, will be fine with InterDrive. If the current version of SOSS does not include a PCNFSD, however, you will need a special program that bypasses that authentication. This is free to customers that need it, but not part of our standard distribution. (It's a tremendous security hole...) Contact me if you go that route. ----------- The SOSS package is available from dorm.rutgers.edu, in /pub/msdos/packet- drivers. Many thanks to everyone who responded. This is the way the net's supposed to work! -------------------------------------------------------------------------------- Dick Joltes joltes@husc.harvard.edu Harvard University Science Center
-----------[000116][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 93 14:27:32 GMT From: devdjn@space.alcbel.be (Dennis Newport) To: comp.protocols.tcp-ip Subject: Re: KEEPALIVE option for tcp sockets
The guy who originally posted this article has a valid point. I am personally interested in the responses. All that seems to have occurred so far is that the responses are bitching about which manual pages he is reading. Old Sun BSD, SunOS 4.1.2 and HP-UX manual pages are different but they say they same thing about KEEPALIVE. Does anyone have an answer ? People don't really seem to answer things in this group. They just chat. I have posted a couple of articles to which the response has been pitiful. To both my articles I received mail from people asking to forward any responses. Unfortunately this hasn't been possible due to (almost) complete lack of response. Do any TCP/IP experts read this group ? Or is it just something to browse through while eating lunch ? --- Dennis Newport, email: devdjn@space.alcbel.be Alcatel Bell Telephone, Berkenrodelei 33, phone: (+32) 3/829.5488 2660 Hoboken, Belgium.
-----------[000117][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Jul 1993 15:12:32 GMT From: Steinar.Haug@runit.sintef.no (Steinar Haug) To: comp.protocols.tcp-ip,comp.sys.hp Subject: Are port numbers < 1023 reserved for the client end of an FTP data connection?
We have an IBM AS/400 system which wants to use port numbers just below 1024 in the PORT command sent from the FTP client to the FTP server (ftpd) on the remote host. The HP-UX ftpd doesn't like this, and responds: ftp> quote PORT 129,241,4,6,3,255 ---> PORT 129,241,4,6,3,255 530 Bad parameters for PORT command. After some more checking, I concluded that the HP ftpd accepts port numbers in the range 0-512, but refuses port numbers in the range 513-1023, in the PORT command sent by the ftp client. I reported this error to HP Norway earlier today, and was quickly given a reply: HP considers this to be the correct behavior (according to RFC-1340), and does not intend to change it. I need some net wisdom on this subject: *Are* port numbers < 1024 reserved for the client end of an FTP data connection? RFC-1340 says on page 9: ---------------------------------------------------------------------- The Well Known Ports are controlled and assigned by the IANA and on most systems can only be used by system (or root) processes or by programs executed by privileged users. Ports are used in the TCP [45,106] to name the ends of logical connections which carry long term conversations. For the purpose of providing services to unknown callers, a service contact port is defined. This list specifies the port used by the server process as its contact port. The contact port is sometimes called the "well-known port". ---------------------------------------------------------------------- And then goes on to list well known ports up to 1000: cadlock 1000/tcp ock 1000/udp It's quite clear to me that the HP ftpd is *inconsistent* in its behavior, since it allows port numbers <= 512. But is it in error? Or is the IBM ftp client in error by using a port number < 1024 in the PORT command? The RFC section quoted above talks about "service contact port", and this gets a little fuzzy with FTP since you have one command connection and one data connection, and the data connection is normally initiated from the FTP server. Steinar Haug, system/networks administrator SINTEF RUNIT, University of Trondheim, NORWAY Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no
-----------[000118][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Jul 1993 15:24:13 GMT From: jmc@hal.com (Jerry McCollom) To: comp.protocols.tcp-ip,comp.sys.hp Subject: Re: Are port numbers < 1023 reserved for the client end of an FTP data connection?
Steinar.Haug@runit.sintef.no (Steinar Haug) writes: >We have an IBM AS/400 system which wants to use port numbers just below 1024 >in the PORT command sent from the FTP client to the FTP server (ftpd) on the >remote host. The HP-UX ftpd doesn't like this, and responds: > >ftp> quote PORT 129,241,4,6,3,255 >---> PORT 129,241,4,6,3,255 >530 Bad parameters for PORT command. > >After some more checking, I concluded that the HP ftpd accepts port numbers >in the range 0-512, but refuses port numbers in the range 513-1023, in the >PORT command sent by the ftp client. > >I reported this error to HP Norway earlier today, and was quickly given a >reply: HP considers this to be the correct behavior (according to RFC-1340), >and does not intend to change it. What version of HP-UX do you have? This was a feature of HP-UX 7.0 and some prior releases, but I believe it was removed in HP-UX 8.0 and later based on customer complaints and on discussion on comp.protocols.tcp-ip that concluded (especially, as I remember, after an authoritative reply from Jon Postel) that it was out of spec. I cannot remember if there was a patch for this for HP-UX 7.0 (I no longer work for HP and so cannot check on this). I am almost certain it was removed before the HP-UX 8.0 release (since I did it :-). However, I cannot state authoritatively that it was not reintroduced, based on your observations (I believe the older HPUX 7.0 and earlier code excluded all ports < 1024; the behavior you observe where it permits 0-512 suggests to me it may have been reintroduced in some sort of mutated form). Perhaps somebody from HP (Art?) will be able to give you specifics as to whether this was fixed and maybe direct you to the appropriate patch. Your response seems to indicate that the support folks didn't understand the problem. A client can specify any valid port it wishes for the data connection. The FTP specs say nothing about limiting ports and, in practice and as you've observed, it is not interoperable with many ftp clients in the real world. - Jerry (who speaks for neither HP nor for HaL Computer Systems, Inc. but who does speak for himself) -- Jerry McCollom HaL Computer Systems, Inc., Austin, TX jmc@hal.com
-----------[000119][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Jul 1993 16:12:34 GMT From: cmclal@lizzie.arh.cdc.com (A. Sudhakarlal) To: comp.protocols.tcp-ip Subject: Would 0xFFFF ever be a TCP checksum? Comments pls.
During ftp sessions , client side TCP receives a packet with checksum 0xFFFF from a Novell Flex/IP server. I am not very sure whether a TCP packet could have checksum value 0xFFFF. I was looking into RFC 1071. And yet I can not figure out the problem. We are having problems in file transfers. Middle of a file transfer, connection is getting timed out. Please throw light on to the problem.
-----------[000120][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Jul 1993 16:53:32 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: KEEPALIVE option for tcp sockets
In article <2081@alcbel.be>, devdjn@space.alcbel.be (Dennis Newport) writes:
>
> The guy who originally posted this article has a valid point.
> I am personally interested in the responses. All that seems to
> have occurred so far is that the responses are bitching about
> which manual pages he is reading. Old Sun BSD, SunOS 4.1.2 and
> HP-UX manual pages are different but they say they same thing
> about KEEPALIVE. Does anyone have an answer ?
Without knowing which man page the previous guy was talking about,
how could anyone offer a useful guess? What if the select() the
guy wanted to know about is only library code to make System V's poll()
look right? What if the socket code is really something like the old
Excelan socket library? Even if the code is all 4.3BSD-reno or net2
based, there is no assurance that the vendor has made no changes.
There are a few variants of 4.3BSD select() I might guess about or
check the source or write a test program, but there are far more I
won't guess about.
Until the guy admits which system is involved, no one who might know
will help. That the brand is still a secret after so many repetitions
of "what system are you talking about?" is itself interesting.
Select() in some BSD systems must return when a keepalive kills a TCP
connection, because the BSD rlogind seems to me to depend on that
behavior. Look at the source for yourself. (Do not expect someone
else to look at it for you because you are too lazy or poor.)
> People don't really seem to answer things in this group. They
> just chat. I have posted a couple of articles to which the
> response has been pitiful. To both my articles I received
> mail from people asking to forward any responses. Unfortunately
> this hasn't been possible due to (almost) complete lack of response.
>
> Do any TCP/IP experts read this group ? Or is it just something
> to browse through while eating lunch ?
For some reason beyond my ken, the money you pay for advice doesn't
seem to reach the people whose time you are demanding. You no doubt
know that $100/hour would be cheap for work.
Once you have answered a reasonable question half a dozen times, it
becomes tiresome. Besides, it never pays to answer a question like "my
system doesn't work", when the questioner does not know or refuses to
say what brand of system is involved. Why should "TCP/IP experts" who
are only chatting be interested in solving someone else's basic
programming problem? It's not as if there are not enough hard bugs to
fix or new stuff to write in the universe.
There is a worse syndrome. If you lurk in newsgroups for a while, you
notice that almost all articles fit in the following catagories:
1. boring flames, like yours and this one.
2. responses to (1), which are usually also members of (1)
3. interesting statements and questions
4. responses to (3), which may themselves be members of (3)
3. nonspecific, impossible to answer questions ("why doesn't my
my program work?")
4. boring, obvious, familiar questions that are asked 3 times/week
("what is a keepalive", "what is UDP")
5. responses to (3) and (4) from people who just finished reading
a textbook or some netnews articles.
6. responses to (3) and (4) from people who know the answers.
There are far more in (5) than (6), and the accuracy of (5) is what you
would expect--not always wrong but (like the rest of netnews) unreliable.
Netnews is worth no more than what you pay for it.
Vernon Schryver, vjs@sgi.com
-----------[000121][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Jul 1993 17:03:13 GMT From: john@iastate.edu (John Hascall) To: comp.protocols.tcp-ip Subject: Re: KEEPALIVE option for tcp sockets
In article <2081@alcbel.be> devdjn@space.alcbel.be writes:
}The guy who originally posted this article has a valid point.
}I am personally interested in the responses. All that seems to
}have occurred so far is that the responses are bitching about
}which manual pages he is reading. Old Sun BSD, SunOS 4.1.2 and
}HP-UX manual pages are different but they say they same thing
}about KEEPALIVE. Does anyone have an answer ?
}People don't really seem to answer things in this group. They
}just chat. I have posted a couple of articles to which the
}response has been pitiful. To both my articles I received
}mail from people asking to forward any responses. Unfortunately
}this hasn't been possible due to (almost) complete lack of response.
}Do any TCP/IP experts read this group ? Or is it just something
}to browse through while eating lunch ?
This actually has more to do with BSD sockets, but...
Well, here's "man 2 socket" from Ultrix (which is what I am most
familiar with [and which is a BSD4.2 descendent]):
SO_KEEPALIVE enables the periodic transmission of messages on a
connected socket. Should the connected party fail to respond to
these messages, the connection is considered broken and processes
using the socket are notified through a SIGIO signal.
Note that
in order to receive signals on a socket the program must first
call fcntl(2) with a F_SETOWN request to set the process group of
the process to receive the signal, and with a F_SETFL request to
set the FASYNC flag, which enables the SIGIO signal to be sent.
And here are some code excerpts from a program I wrote:
(void)signal(SIGIO, sigcatch);
if (setsockopt(netfd, SOL_SOCKET, SO_KEEPALIVE, &on, sizeof(on)) < 0) {
com_err(whoami, errno, "setting keepalive");
return (1);
}
if (fcntl(netfd, F_SETOWN, pid) < 0) {
com_err(whoami, errno, "setting socket owner");
return (1);
}
fdflgs = fcntl(netfd, F_GETFL, NULL);
fdflgs |= FASYNC;
if (fcntl(netfd, F_SETFL, fdflgs) < 0) {
com_err(whoami, errno, "setting socket flags");
return (1);
}
static void sigcatch(sig, code, scp)
int sig;
int code;
struct sigcontext * scp;
{
int l;
switch (sig) {
case SIGPIPE:
:
:
case SIGTERM:
:
:
case SIGIO:
l = sizeof(nerrno);
if (getsockopt(*nfdp, SOL_SOCKET, SO_ERROR, &nerrno, &l) == 0) {
if (nerrno == EINTR) nerrno = 0;
if (nerrno != 0) caught = sig;
}
break;
}
}
for (;;) {
/*
* A signal?
*/
if (caught) {
errno = nerrno;
if (caught == SIGPIPE) DiedIn("network(pipe)");
if (caught == SIGTERM) DiedIn("ppt(terminated)");
if (caught == SIGIO) DiedIn("network(keepalive)");
DiedIn("programmer botch(signal)");
}
errno = 0;
readable = reading;
writable = writing;
goofable = readable | writable;
timeout.tv_sec = done ? 10 : (60 * Delay(n));
switch (select(32, &readable, &writable, &goofable, &timeout)) {
:
:
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
-----------[000122][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 93 17:25:12 GMT From: trt@duke.cs.duke.edu (Tom Truscott) To: comp.protocols.tcp-ip Subject: Re: Would 0xFFFF ever be a TCP checksum? Comments pls.
>I am not very sure whether a TCP packet could
>have checksum value 0xFFFF.
A *UDP* (but not TCP) packet can have the checksum value 0xFFFF. Ordinarily
the value stored is the ones complement of the 16-bit summation.
The summation can yield a value of 0xFFFF, so its ones complement is 0.
But "0" is a special indicator that means "no checksum",
so in that case 0xFFFF is stored (ones-complement summation
makes 0xFFFF and 0 equivalent for valid packets).
A TCP packet can never have a checksum value of 0xFFFF, because that
would mean the sum was 0, which is only possible if the entire packet
consists of 0, but that would be an invalid packet.
=======
What this means is, the current UDP checksumming algorithm was botched!
The "no checksum" value should be the impossible 0xFFFF value,
rather than the current 0 value.
Then no special check for 0 would be needed.
Current UDP algorithm:
if (nochecksum)
sum = 0;
else
{
sum = ~end_around_16_bit_sum(packet);
if (sum == 0)
sum = 0xffff;
}
packet.checksum = sum;
The way it should have been:
packet.checksum = ~(nochecksum? 0: end_around_16_bit_sum(packet));
=======
Tom Truscott
-----------[000123][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 1993 17:28:09 GMT From: corrigan@weber.ucsd.edu (Michael J. Corrigan) To: comp.protocols.tcp-ip,comp.sys.hp Cc: corrigan Subject: Re: Are port numbers < 1023 reserved for the client end of an FTP data connection?
It is still (again?) in HP-UX 8.x. ftpd from: wuarchive.wustl.edu:packages/wuarchive-ftpd builds fine under HP-UX, and doesn't have this problem. -Mike Corrigan In <JMC.93Jul8102407@jayhawk.hal.com> Jerry McCollom <jmc@hal.com> wrote: >What version of HP-UX do you have? This was a feature of HP-UX 7.0 and >some prior releases, but I believe it was removed in HP-UX 8.0 and later >based on customer complaints and on discussion on comp.protocols.tcp-ip >that concluded (especially, as I remember, after an authoritative reply >from Jon Postel) that it was out of spec. > >I cannot remember if there was a patch for this for HP-UX 7.0 (I no >longer work for HP and so cannot check on this). I am almost certain it >was removed before the HP-UX 8.0 release (since I did it :-). However, >I cannot state authoritatively that it was not reintroduced, based on >your observations (I believe the older HPUX 7.0 and earlier code >excluded all ports < 1024; the behavior you observe where it permits >0-512 suggests to me it may have been reintroduced in some sort of >mutated form). > >Perhaps somebody from HP (Art?) will be able to give you specifics as to >whether this was fixed and maybe direct you to the appropriate patch. > >Your response seems to indicate that the support folks didn't understand >the problem. A client can specify any valid port it wishes for the data >connection. The FTP specs say nothing about limiting ports and, in >practice and as you've observed, it is not interoperable with many ftp >clients in the real world. > >- Jerry (who speaks for neither HP nor for HaL Computer Systems, Inc. > but who does speak for himself) >-- >Jerry McCollom >HaL Computer Systems, Inc., Austin, TX >jmc@hal.com
-----------[000124][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Jul 1993 17:53:49 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Would 0xFFFF ever be a TCP checksum? Comments pls.
In article <C9ut0z.D6y@raistlin.udev.cdc.com>, cmclal@lizzie.arh.cdc.com (A. Sudhakarlal) writes: > During ftp sessions , client side TCP receives a packet with checksum 0xFFFF > from a Novell Flex/IP server. I am not very sure whether a TCP packet could > have checksum value 0xFFFF. I was looking into RFC 1071. And yet I can not > figure out the problem. We are having problems in file transfers. Middle of a > file transfer, connection is getting timed out. > > Please throw light on to the problem. Since you must have the whole packet to know the checksum is 0xffff, the best way to procede is to manually compute the checksum yourself. Or write a quick and dirty program in C or awk (or BASIC or whatever) to compute the checksum. There is C code for the IP checksum in many places. I'd start with the BSD portable version. Look on uunet in the net2 source. Or, given a return address in *.cdc.com, the source of any of the many implementations that CDC has. Vernon Schryver, vjs@sgi.com
-----------[000125][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Jul 1993 22:58:53 EST From: Rogelio Montanana (MONTANAN at EVALUN11) <MONTANAN@EVALUN11.BITNET> To: comp.protocols.tcp-ip Subject: Can I use TCP/IP over satellite links?
We are a group of four Universities that want to be connected by high speed links (2 Mb or higher), without using the PTT services, that happen to be very expensive in Spain. The topology would be a star with three links, the distances varying from about 8 Km to about 100 Km. The main protocol used is TCP/IP. Talking with telecommunication specialists they recommend satellite links (they call it VSAT); I remember to have read somewhere that satellite links introduce long delays in the packets sent (something between half a second and two seconds maybe?). It worries me because, for example, using telnet with remote echo means two packets sent per key, and half a second delay would be unacceptable in this situation. The specialists claim that it is no problem, but I am not so sure. Is anybody over there using satellite links for interactive applications, like telnet? I will appreciate hearing of any experience using satellite links in TCP/IP networks. Regards, Rogelio. Rogelio Montanana, System Analyst Tel:(346)3864310 Fax:(346)3864200 Valencia Univ. Computer Center Bitnet: montanan at evalun11 Dr. Moliner, 50 Internet: montanan@vm.ci.uv.es 46100 Burjassot Hepnet: evalun::montanan (or 16530::montanan) Spain X400: C=es;A=mensatex;P=iris;O=uv;OU=ci;OU=vm;SN=montanan
-----------[000126][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Jul 1993 18:56:29 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Would 0xFFFF ever be a TCP checksum? Comments pls.
In article <742152311@romeo.cs.duke.edu>, trt@duke.cs.duke.edu (Tom Truscott) writes:
> >I am not very sure whether a TCP packet could
> >have checksum value 0xFFFF.
>
> A *UDP* (but not TCP) packet can have the checksum value 0xFFFF. Ordinarily
> the value stored is the ones complement of the 16-bit summation.
> The summation can yield a value of 0xFFFF, so its ones complement is 0.
> But "0" is a special indicator that means "no checksum",
> so in that case 0xFFFF is stored (ones-complement summation
> makes 0xFFFF and 0 equivalent for valid packets).
>
> A TCP packet can never have a checksum value of 0xFFFF, because that
> would mean the sum was 0, which is only possible if the entire packet
> consists of 0, but that would be an invalid packet.
-The 4.3BSD based TCP/IP and UDP/IP code I know about uses exactly
the same functions to compute and check the TCP and UDP checksums.
The conversion of 0 to 0xffff needed for UDP is thereby done
to TCP packets.
-Consider a TCP packet containing no options, and 2 bytes of user
data, where that data just happens to consist of the 1's complement
of the checksum of the TCP header and psuedo-header.
What would be the TCP checksum of such a TCP packet?
Vernon Schryver, vjs@sgi.com
-----------[000127][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Jul 1993 19:18:52 GMT From: kfisher3@mach1.wlu.ca (kevin fisher U) To: comp.protocols.tcp-ip Subject: Rexec problem!
Hi folks: I'm trying to write a small program that rexec's another program on a remote machine. This remote program is a curses based administration program for our budget database. What I did is, I rexec'd the program on the remote machine, and used the socket that was returned to ferry the local I/O to the remote machine, and vice versa. It works no problem, except for the fact that whenever the remote machine prints something to stdout, the screen (on the local machine) will be immediately cleared after printing it. I don't think this is a curses problem, as when i resh() the same program, the screen clearing fluke doesn't happen. Incidentally, to handle the I/O from the socket on the local machine, I just fork() and send the socket to two functions, one that reads from the socket and the other that writes to it (after grabbing stuff from local stdin), all character by character. Oh, and the local terminal is in a raw() mode as well, so buffering isn't an issue. Any help would be greatly appreciated (sorry if this sounds a bit vague...) -- Kevin Fisher ><> | WLU - - Home of the kfisher3@mach1.wlu.ca | Internationally Bright Young Thingies
-----------[000128][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Jul 1993 19:52:32 GMT From: Steinar.Haug@runit.sintef.no (Steinar Haug) To: comp.protocols.tcp-ip,comp.sys.hp Subject: Re: Are port numbers < 1023 reserved for the client end of an FTP data connection?
jmc@hal.com (Jerry McCollom) writes: > What version of HP-UX do you have? This was a feature of HP-UX 7.0 and > some prior releases, but I believe it was removed in HP-UX 8.0 and later > based on customer complaints and on discussion on comp.protocols.tcp-ip > that concluded (especially, as I remember, after an authoritative reply > from Jon Postel) that it was out of spec. It is in all the versions of HP-UX I have checked: HP-UX 8.0 s400 HP-UX 8.07 s700 HP-UX 9.0 s700 HP-UX 9.01 s700 HP-UX 9.0 s800 I would be extremely interested if you could dig up that answer from Jon Postel. > I cannot remember if there was a patch for this for HP-UX 7.0 (I no > longer work for HP and so cannot check on this). I am almost certain it > was removed before the HP-UX 8.0 release (since I did it :-). However, > I cannot state authoritatively that it was not reintroduced, based on > your observations (I believe the older HPUX 7.0 and earlier code > excluded all ports < 1024; the behavior you observe where it permits > 0-512 suggests to me it may have been reintroduced in some sort of > mutated form). If you actually remember removing it, it has definitely been reintroduced. > Your response seems to indicate that the support folks didn't understand > the problem. A client can specify any valid port it wishes for the data > connection. The FTP specs say nothing about limiting ports and, in > practice and as you've observed, it is not interoperable with many ftp > clients in the real world. That's basically my interpretation also. Unfortunately the HP support folks here in Norway (who answered quickly and efficiently, just not the answer I wanted) dug up a similar case (also involving an AS/400), and said, in effect, that "HP has decided that it follows the standard; case closed". I'm trying to dig up supporting evidence for *not* closing the case. Steinar Haug, system/networks administrator SINTEF RUNIT, University of Trondheim, NORWAY Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no
-----------[000129][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Jul 1993 19:57:27 GMT From: kudzu@netcom.com (Michael Sierchio) To: comp.protocols.tcp-ip Subject: Re: KEEPALIVE option for tcp sockets
In article <j1hf31k@rhyolite.wpd.sgi.com>
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>Netnews is worth no more than what you pay for it.
I must disagree. See my scientific survey results below:
Advice value * Percentage of Netnews
-------------------------------------------
0 90%
infinite 5%
less than zero 5%
* (the cost of actually *following* bad advice makes it very expensive. If
it is of any value at all, It's worth infinitely more than the price paid).
Anyway, my check for "Infinity" is in the mail, Vernon.
--
+--------------------------------------------------------------------------+
| Michael Sierchio 1563 Solano Avenue, Suite 123 |
| kudzu@netcom.com Berkeley, CA 94707-2116 |
+--------------------------------------------------------------------------+
-----------[000130][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Jul 1993 20:16:22 GMT From: clm@uiuc.edu (C Lance Moxley) To: comp.unix.admin,comp.protocols.tcp-ip,comp.unix.aix Subject: Where did I come from?
How can I tell where I've telnetted from? I have a service I provide on an IBM RS/6000 AIX3.2.3e that users telnet to. I take them and do a tn3270 for them to our mainframe for access to our library circulation system. What I'd like to do is route certain clients certain directions for them when they telnet to my box. For example users on this campus (uiuc.edu) should go one way, but maybe users at Southern Illinois (siu.edu) should go elsewhere. It seems that /var/adm/wtmp has some of what I need through the who command, but it's truncated at about 16 characters. Obviously what I want to key on is the LAST few characters and a long hostname may not have the last part of the domainname in wtmp. How can this be handled? Any and all ideas are welcome! -- C Lance Moxley Internet: clm@uiuc.edu AISS/Telecommunications BITNET: UNETCLM at UICVMC University of Illinois UUCP: uunet!uiucuxc!uiuc.edu!clm
-----------[000131][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Jul 1993 20:41:19 GMT From: tmm@apollo.HP.COM (Thomas M. Mistretta) To: comp.protocols.tcp-ip,comp.networks.noctools.wanted Subject: Request for tools/test suites for IP routers
Could anyone recommend any tools or suites to test and validate the operation of an IP router? Specifically, we would like to examine fragmentation, IP option handling, ICMP, etc., in addition to various routing protocols like RIP, OSPF, and HELLO. Realistically - at a minimum - we would like to see testing of the guidelines set forth in RFC-1009: "Requirements for Internet Gateways." Any response would be appreciated. Thanks. Tom Mistretta tmm@apollo.hp.com
-----------[000132][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Jul 1993 21:27:33 GMT From: donp@novell.com (don provan) To: comp.protocols.tcp-ip Subject: Re: Would 0xFFFF ever be a TCP checksum? Comments pls.
In article <16C05B870.NELSON@msu.edu> NELSON@msu.edu (Doug Nelson) writes: >In article <C9ut0z.D6y@raistlin.udev.cdc.com> >cmclal@lizzie.arh.cdc.com (A. Sudhakarlal) writes: >>During ftp sessions , client side TCP receives a packet with checksum 0xFFFF >>from a Novell Flex/IP server. I am not very sure whether a TCP packet could >>have checksum value 0xFFFF. I was looking into RFC 1071. And yet I can not >>figure out the problem. We are having problems in file transfers. Middle of a >>file transfer, connection is getting timed out. > >This topic has come up before. Since a TCP checksum is defined as a 16 >bit one's complement value, 0xFFFF is equivalent to 0x0000. However, >since most TCPs are implemented on two's complement systems, or compute >the checksum in a larger word, a special check is needed to treat them >as equivalent. This check is missing from some TCPs, which likely >includes the system with your client. There's no need for a special check. The proper way to check the TCP checksum is to checksum received packets with the TCP checksum still *in* the packet. If, on a twos complement machine, you don't get a checksum of 0xffff, the check is a failure. It doesn't matter whether the checksum in the packet was 0 or 0xffff. (I've never figured out if this characteristic of the TCP/IP checksum was intentional...) I think i'm the one that made the NetWare TCP code send 0xffff instead of zero, but now i can't remember why i did it. Could it be that the UNIX implementations Vernon was refering to, the ones that used the same routine to calculate the UDP and TCP checksum, would choke if they received a checksum set to 0? don provan donp@novell.com
-----------[000133][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 93 21:44:00 GMT From: trt@duke.cs.duke.edu (Tom Truscott) To: comp.protocols.tcp-ip Subject: Re: Would 0xFFFF ever be a TCP checksum? Comments pls.
> > -The 4.3BSD based TCP/IP and UDP/IP code I know about uses exactly > the same functions to compute and check the TCP and UDP checksums. Yes. in_cksum() is used to calculate the checksum. I should have used it in my pseudo-code. Sorry about that. But special code for UDP substitutes 0xffff if 0 is returned. This is done only for UDP, since checksumming is optional only for UDP :-( (For example, in the net-2 release see udp_usrreq.c:342 and tcp_output.c:382) > -Consider a TCP packet containing no options, and 2 bytes of user > data, where that data just happens to consist of the 1's complement > of the checksum of the TCP header and psuedo-header. > What would be the TCP checksum of such a TCP packet? It would be 0. Suppose X is the checksum of the header (and the value of the data). So ~X must be the sum of the header. So the total sum is ~X + X == 0xffff. So the checksum (the 1's complement of the end-around-carry sum) is 0. Another example: suppose the header and data each sum to 0xffff. Then the total sum is again 0xffff thanks to end-around carry. Tom Truscott
-----------[000134][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 93 22:05:56 GMT From: trt@duke.cs.duke.edu (Tom Truscott) To: comp.protocols.tcp-ip Subject: Re: Would 0xFFFF ever be a TCP checksum? Comments pls.
>I think i'm the one that made the NetWare TCP code send 0xffff instead >of zero, but now i can't remember why i did it. There is no need to do it for TCP. You don't *need* to do it for UDP. The reason why you *should* do it for UDP is that otherwise one in 64k random packets will have a checksum of 0 which the receiver will interpret as "no checksum". That could dramatically increase the undetected error rate. If 0xffff had been used as the "no checksum" value then no special check would have been needed (see previous article). The checksum is simple, but has been obfuscated by overloading of the term "ones complement". The ones complement of the sum. The ones complement sum. The ones complement computer. Yuck. Tom Truscott
-----------[000135][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 1993 23:23:53 GMT From: louie@sayshell.umd.edu (Louis A. Mamakos) To: comp.protocols.tcp-ip Subject: Re: Would 0xFFFF ever be a TCP checksum? Comments pls.
In article <742152311@romeo.cs.duke.edu> trt@duke.cs.duke.edu (Tom Truscott) writes: >>I am not very sure whether a TCP packet could >>have checksum value 0xFFFF. Sure it should. (I assume you mean the contents of the checksum TCP header field.) I had it easy; the IP stack that I did actually ran on a 1's complement computer (on the other hand it was a word-addressable 36 bit machine, so I didn't have it all *that* easy; you should see my analog of htonl(), etc!) >A *UDP* (but not TCP) packet can have the checksum value 0xFFFF. Ordinarily >the value stored is the ones complement of the 16-bit summation. >The summation can yield a value of 0xFFFF, so its ones complement is 0. >But "0" is a special indicator that means "no checksum", >so in that case 0xFFFF is stored (ones-complement summation >makes 0xFFFF and 0 equivalent for valid packets). You have it backwards. Don't confuse implementation from the underlying arithmetic. Remember that the IP protocol suite checksums are computed using 1's complement arithmetic, with end-around-carry and all that good stuff. One 1's complement CPUs, you have two distinct representations of the value of zero. One is all zero bits (+0) and the other is all one bits (-0). Arithmetically, 0 == 0xffff (that is, +0 == -0) for a 16 bit integer on a 1's complement machine. The ALU on such a machine will never normally give you a negative zero as the result of an arithmetic operation (such as computing a sum). >A TCP packet can never have a checksum value of 0xFFFF, because that >would mean the sum was 0, which is only possible if the entire packet >consists of 0, but that would be an invalid packet. Again, you're confusing implementation of 1's complement arithmetic on 2's complement hardware. On a 1's complement CPU, you'll never get a computed value of 0xffff doing the sum! So, if you end up with a checksum of zero, putting the 1's complement of it (that is its negative value) in the packet will result in 0xffff which is why you see it in there. Obviously, the reason you put the complement of the computed value in the checksum field is so a checksum of the packet will come out to zero. (Since 0xffff == -0 == 0); Louis Mamakos University of Maryland
-----------[000136][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 1993 23:28:22 GMT From: trier@odin.ins.cwru.edu (Stephen C. Trier) To: comp.protocols.tcp-ip Subject: Re: Would 0xFFFF ever be a TCP checksum? Comments pls.
In article <742169155@romeo.cs.duke.edu> trt@duke.cs.duke.edu (Tom Truscott) writes: >If 0xffff had been used as the "no checksum" value >then no special check would have been needed (see previous article). No, that is not true. What is the checksum of 4 bytes with contents 0000 0000? (sum = 0000, so the checksum is ffff.) What is the checksum for 4 bytes with contents 0000 ffff? (sum = ffff, so the checksum is 0000.) There is no "impossible" result for the checksum. The UDP checksum semantics therefore do work -- a 0000 checksum is transmitted as ffff, and a transmitted 0000 means "no checksum". -- Stephen Trier (trier@ins.cwru.edu - MIME OK) Network Software Engineer IRIS/INS/T Case Western Reserve University
-----------[000137][next][prev][last][first]---------------------------------------------------- Date: 9 Jul 1993 08:28:40 -0400 From: dsc@xray.hmc.psu.edu (David S. Channin) To: news.announce.newgroups,news.groups,sci.med,sci.med.physics,sci.med.telemedicine,sci.image.processing,comp.graphics,comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.misc Subject: RESULT: comp.protocols.dicom passes 147:22
RESULT: comp.protocols.dicom
The voting for the proposed newsgroup comp.protocols.dicom was concluded at
23:59 EST on 8 July 1993.
169 valid votes were received:
147 YES votes (in favor of creation)
22 NO votes (opposed to creation)
In accordance with tradition, there being at least 100 more yes votes
than no votes, and at least two-thirds of the votes being in favor,
the proposal for the creation of the newsgroup comp.protocol.dicom
PASSES.
Thank you to those who participated.
For off-line discussion concerning this vote, please contact:
dsc@xray.hmc.psu.edu
David S. Channin
Department of Radiology
Section of Radiologic Computing and Imaging Science
Penn State University
The Milton S. Hershey Medical Center
P.O. Box 850
Hershey, PA 17033
(717) 531 - 5728
YES votes:
Zenon Fortuna <zenon@resonex.com>
Khanh Ly <k.ly@trl.oz.au>
elang@cs.unsw.oz.au (E Setiawan)
McBride_Brian/pinewood_lab_hpopd@hpopd.pwd.hp.com
add@philabs.Philips.Com (Aninda Dasgupta)
Eric LaPresto <lapresto@bme.ri.ccf.org>
weinhous@alpha.hahnemann.edu (Martin S. Weinhous Ph.D.)
Andy Hewett <Andy.Hewett@arbi.informatik.uni-oldenburg.de>
cjoa@fciad3.bsd.uchicago.edu
"Gerald Q. Maguire" <maguire@cs.columbia.edu>
gargulak@colossus.med.ge.com (Anthony Gargulak 5-4308)
Andrew Schmidt <schmidt@cs.uiuc.edu>
Randolph Gladish <randy@topaz.bds.com>
diro@edison.Phone.North.DE (Dirk Rode)
wmihalo@rdth2.rdth.luc.edu (William E. Mihalo, PhD)
Chet Mazur <chet@spock.retix.com>
mjb@cs.brown.edu (Manish Butte)
steve.strother@vapet.uucp@cs.umn.edu (Steven Strother)
"Fred Prior, Ph.D." <prior@radmail.xray.hmc.psu.edu>
INFOMED@ccvax.unicamp.br
kevino@nmgw.nm.nasu.toshiba.co.jp (Kevin O'Donnell)
David Haynor <haynor@u.washington.edu>
swire@Kodak.COM (Alan Swire)
ploeger@aplki.toppoint.de (Andreas Ploeger)
Alan R. Bleier <bleier@NORMAN.VI.RI.CMU.EDU>
gerry@cs.tamu.edu (Gerald J Creager)
jbono@atl.com
gpmcdona@cats.UCSC.EDU (Glenn McDonald)
jhoben@jwh.win.net (John W. Hoben)
diegert@cs.sandia.gov (Carl F. Diegert)
stanley@kpc.com (Stanley Guan)
T.CASEY@cardiff-institute.ac.uk
nightowl@brimston.apana.org.au (Leanne Taylor)
jkippen@newssun.med.miami.edu (Jonathan Kippenhan)
robday@uniwa.uwa.edu.au (Robert Day)
93CRBM@npd1.ufpe.br
sippel@mallet.med.ge.com (Teri Sippel 5-5045)
mitrakos@cperi.forth.gr (Dimitris Mitrakos)
Richard L. Morin Ph.D. <morin@mayo.edu>
smm@wuerl.WUstl.EDU (Steve Moore)
giorgos@cs.rochester.edu
Ken Krippner <kek@cms-stl.com>
Peter Hauke <se92psh@brunel.ac.uk>
shukky@acs.bu.edu (Joshua Blume)
Dan Ritt <danritt@csn.org>
dclunie@pax.tpa.com.au (David Clunie)
Paul Mockapetris <pvm@ISI.EDU>
KATER@WSUHUB.UC.TWSU.EDU
jkkjasio@psk2.am.lod.edu.pl (jan k.kaminski)
parisot@mmi3.med.ge.com (Charles Parisot 5-5857)
RAY DEININGER <R_DEININGER@uvmvax.uvm.edu>
asw2s@palm.cs.virginia.edu
wes@wes.win.net (Wes Rishel)
alex@vuse.vanderbilt.edu (Alexander P. Zijdenbos)
hlavac@prip.tuwien.ac.at
minmail@mindymail.win.net (MINDY NEMON)
mitchell@alydar.crd.ge.com (Robert Mitchell)
ph@physiology.oxford.ac.uk (Patrick Haggard)
ewert@nasse.cb.uu.se
chassign@lix.polytechnique.fr (Chassignet Philippe)
arneny@mikrosys.no (Arne Nylund)
mct@philabs.Philips.Com (Mark C. Tucker)
gary@maestro.mitre.org (Gary Bisaga)
nrd@lenti.med.umn.edu
"Umberto Tachinardi, MD" <TACHINARDI@incor.hc.usp.ansp.br>
gerrit@isgtec.com (Gerrit Visser)
Hedley Bond <bond@scanner.hosp.utk.edu>
jlc@adaclabs.com (Jean-Luc Chatelain)
berman@nlm.nih.gov (Lewis Berman)
"Paul Picot" <ppicot@irus.rri.uwo.ca>
Brendan Forsyth <bff@csn.org>
jpower@atl.com
clay@cool.vortech.com (Clay Luther)
jperser@pluto.vortech.com (John Perser)
TALLANTJ.DFP@mhs.unc.edu (TALLANTJ)
Trevor Cradduck <trevorc@uwovax.uwo.ca>
dsc@xray.hmc.psu.edu (David S. Channin)
Peter Hauke <se92psh@brunel.ac.uk>
shin@nop.han.de (Hoen-oh Shin)
Allan Noordvyk <allan@blue>
nam@modu.etri.re.kr (Nam Ji-Seung)
Martin Ohly <mjo@enterprise.DHZB.DE>
jvpardo@vapet.uucp@cs.umn.edu (Jose V. Pardo)
John.B.Weaver@Dartmouth.EDU (John B. Weaver)
maj%mdis1@wdl1.wdl.loral.com (Michael A Johnston)
James Harrison <james@hplb.hpl.hp.com>
lsven@uckbv1.ece.uc.EDU (Sven Loncaric)
andress@penfold.siemens.com (Keith M Andress)
<NAM110@PSUVM.PSU.EDU>
rob horn <horn%temerity@leia.polaroid.com>
kelly@simvax.labmed.umn.edu
curran@stereo.medphysics.nemc.org (Bruce Curran)
srl@wdl1.wdl.loral.com (Steve Lennon)
Alan Strassberg <alan@lscruz.scf.lmsc.lockheed.com>
dgb@mrindigo.utmb.edu
hagmanti@cps.msu.edu
Brian F Long <bflong@convex.csd.uwm.edu>
Lutz Kleinholz <lutz@enterprise.DHZB.DE>
Merge Technologies Inc. <Merge.Tech@mixcom.mixcom.com>
herbison@lassie.ucx.lkg.dec.com (B.J.)
"Cor Posch, Automatisering, AZUA - AMC, Amsterdam." <POSCH@amc.uva.nl>
Bill Bennett <Bill_Bennett@qmserver.vortech.com>
vezina@jupiter.drev.dnd.ca (Guy Vezina)
Mark Wofford <mgw@cool.vortech.com>
frank@frank.vortech.com (Frank Ely)
brianl@vortech.com (Brian Lind)
Erik Strom <Erik_Strom@qmserver.vortech.com>
betsy@vortech.com (Betsy Zimmerman)
bmadsen@tribble.vortech.com (Brian Madsen)
hchen@mr.picker.com (hong chen)
gaeta@picker.com (Jay Gaeta)
Paul Hodgkinson <phh@de-montfort.ac.uk>
kaka@mallet.med.ge.com (Khuzema Kaka)
barbiaux@iscmed.med.ge.com (Bill Barbiaux x5-8283)
"Allan G. Farman, PhD, MBA" <AGFARM01@ULKYVM.LOUISVILLE.EDU>
barnett@alydar.crd.ge.com (Bruce Barnett)
mcconnell@hal.hahnemann.edu
speer@CS.UCLA.EDU (Rick Speer)
brendt@dip1.ee.uct.ac.za (Brendt Wohlberg)
Michael Marrin <marrin@fhs.csu.McMaster.CA>
jc@relito.medeng.wfu.edu (John Campbell)
eric@mitra.com (Eric Peterson)
bennett@Kodak.COM (Gordon Bennett 253-7947)
TALLANTJ.DFP@mhs.unc.edu (TALLANTJ)
buchanan@bme8.utmem.edu
areynold@rpms.ac.uk (Anthony Reynolds)
calvin@vortech.vortech.com (Calvin Head)
jjr@sparkey.att.com
ensa@infomed.cu (Emp. Nac. de Servicios Aereos)
Nadim Yared <yared@inf.enst.fr>
"Gordon A. Sterling" <gordon.sterling@analog.com>
Dr D J Harvey 92 <wdrdjh@thor.cardiff.ac.uk>
kall@mayo.EDU (Bruce Kall)
diana@Kodak.COM (Gary Diana)
bennett@Kodak.COM (Gordon Bennett 253-7947)
phillier@techsup1.hobbit.gandalf.ca (Peter Hillier)
Trevor Cradduck <trevorc@uwovax.uwo.ca>
Xiaohua Xuan <xuan@hpsrjtc.sr.hp.com>
hucaby@mri.uky.edu (David Hucaby)
Eugene Lief <lief@zeno.rice.edu>
Hardcore Alaskan <FSSPR@acad3.alaska.edu>
D. Kris Rovell-Rixx <rovell@hpana0.an.hp.com>
ram@mr.picker.com (Bob Marino)
Robert Nowotny <NOWORO1@VM.AKH-WIEN.AC.AT>
root@manoj.austin.ibm.com
lrt@poirot.siemens.com (Lawrence R. Tarbox)
comaxs03@asnmail.asc.edu (Alan Scales)
NO votes:
L Jonas Olsson <ljo@vger.EEAP.CWRU.Edu>
txj2421@cs.rit.edu (Thomas X Jagodits)
bourland@mayo.EDU (Dan Bourland)
julian@bongo.tele.com (Julian Macassey)
Shane Hartman <shane@spr.com>
maus@fid.morgan.com (Malcolm Austin)
eharold@sunspot.noao.edu (Elliotte Harold)
Tim Pierce <twpierce@unix.amherst.edu>
srogers@tad.eds.com (Steve Rogers)
cmarble@fenris.claremont.edu (Chris Marble)
bogstad@blaze.cs.jhu.edu (Bill Bogstad)
rick@crick.ssctr.bcm.tmc.edu (Richard H. Miller)
Murray Nesbitt <pseudo!mjn>
jfurr@polaris.async.vt.edu (Joel Furr)
"Eric J. Olson" <ejo@kaja.gi.alaska.edu>
Marc Moorcroft <smarry@zooid.guild.org>
Georg Schwarz <georg@marie.physik.tu-berlin.de>
Bill Owens <owens@desperado.cc.rochester.edu>
wbrand@lehman.com (Willy Brandsdorfer)
gt0670e@prism.gatech.edu (Brennan Tennesen Price)
srogers@tad.eds.com (Steve Rogers)
Keith Sklower <sklower@vangogh.CS.Berkeley.EDU>
-----------[000138][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Jul 93 01:55:52 GMT From: ddl@burrhus.harvard.edu (Dan Lanciani) To: bit.listserv.ibmtcp-l,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.servers,comp.bugs.4bsd,comp.bugs.misc Subject: Re: Bug in many versions of TCP
In article <1993Jul7.195317.3075@xylogics.com>, carlson@steam.Xylogics.COM (James Carlson) writes: | IMPORTANT BUG FIX FOR TCP INPUT CODE | | Xylogics has found and fixed a bug that exists in the tcp_input.c | routine in 4.4BSD and several other versions of TCP. We strongly | recommend that you examine your version of TCP for this error. Interestingly, I recently posted a fix for this same code in relation to the self-connect problem. Both problems are caused by throwing away perfectly good ACKs just because data was trimmed. While I believe Xylogics' patch will work, it does introduce some unnecessary code; to wit: | if ((tiflags & TH_FIN) && todrop == ti->ti_len + 1) | tiflags &= ~TH_FIN; At this point, we already know that either TH_FIN wasn't set to begin with or todrop is greater than ti->ti_len. Therefore, TH_FIN can be cleared unconditionally. The first clause of the suggested if() statement is moot, so the only time this would make a difference is if todrop is greater than ti->ti_len + 1 with TH_FIN set. That condition would imply a FIN occupying the sequence number of previously transmitted data, a weird situation to say the least! Dan Lanciani ddl@harvard.*
-----------[000139][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Jul 1993 02:15:47 GMT From: lance@deja-vu.aiss.uiuc.edu (C Lance Moxley) To: comp.unix.aix,comp.unix.admin,comp.protocols.tcp-ip,comp.lang.perl Subject: AIX /etc/utmp
A little while ago I asked about how to find out the fully
qualified domainname where I've telenetted from. Below is a
perl script that was sent to me. It has a problem with AIX's
/etc/utmp file. Also below is what happens when I run the script.
Are there any perl experts out there that can tell me how to
modify this script to find the proper string in /etc/utmp?
The output from the script:
/,)ѯ/: unmatched () in regexp at ./displayhost line 26.
The script with line 26 in arrows:
#!/usr/local/bin/perl
# Find the name of the host from which a user is logged in.
# This is necessary because utmp entries truncate the host name,
# often losing necessary information.
#
# USAGE: setenv DISPLAY `displayhost`:0
#
# Written by Patrick Nolan (pln@egret0.stanford.edu) April 4, 1993
#
# Inspired by a shell script of the same name written by
# don@mars.dgrc.doc.ca (Donald McLachlan), 11/12/92
#require 'sys/socket.ph';
$AF_INET = 2;
# Use `tty` to get the name of the tty device. Look around in
# utmp file to find entry with a matching device. The first
# 16 characters of the remote host name is in utmp.
$ttyname = (`tty`)[0];
$host = "";
open (UTMP, "/etc/utmp") || die "Can't open /etc/utmp\n";
while (read(UTMP, $utmp_rec, 36)) {
($tty,$userid,$ut_host,$time) = unpack("A8 A8 A16 L", $utmp_rec);
----> $host = $ut_host if $tty && ($ttyname =~ /$tty/); <----
last if $host;
}
close(UTMP);
# If there's no valid host, then we are logged in locally. This is easy.
if ($host eq "" || $host eq ":0.0") {
print `hostname`; # Already contains \n
exit; }
else {
# This is a remote login.
# Use netstat -n to get the host address associated with each
# established net connection. Find the full hostname associated
# with each one. Take the first one which contains our partial
# hostname.
foreach (`netstat -n`) {
if (/ESTABLISHED/) {
$adrs = pack("C4", split(/\./, (split)[4])); # Convert addrs to word
$fullname = (gethostbyaddr($adrs, $AF_INET))[0];
if ($fullname =~ $host) { # See if it matches partial host
print $fullname,"\n";
exit;
}
}
}
exit -1;
}
Thanks for any help anyone can provide!
--
C Lance Moxley Internet: clm@uiuc.edu
AISS/Telecommunications BITNET: UNETCLM at UICVMC
University of Illinois UUCP: uunet!uiucuxc!uiuc.edu!clm
-----------[000140][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Jul 1993 03:02:14 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Would 0xFFFF ever be a TCP checksum? Comments pls.
In article <1993Jul8.212733.29176@novell.com>, donp@novell.com (don provan) writes:
> ...
> I think i'm the one that made the NetWare TCP code send 0xffff instead
> of zero, but now i can't remember why i did it. Could it be that the
> UNIX implementations Vernon was refering to, the ones that used the
> same routine to calculate the UDP and TCP checksum, would choke if
> they received a checksum set to 0?
Actually, I'm wrong. It turns out that udp_usrreq.c does:
if (udpcksum && uh->uh_sum) {
....
if ((ui->ui_sum = in_cksum(m, sizeof (struct udpiphdr) + len)) == 0) ui->ui_sum = 0xffff;
....
while tcp_output.c does:
ti->ti_sum = in_cksum(m, (int)(hdrlen + len));
For output, there is
if (uh->uh_sum = in_cksum(m, len + sizeof (struct ip))) {
udpstat.udps_badsum++;
....
and
if (ti->ti_sum = in_cksum(m, len)) {
tcpstat.tcps_rcvbadsum++;
....
in_cksum() does the familiar folding, returning with something like:
return (~sum & 0xffff);
That means in_cksum() cannot produce 0xffff, but has no trouble
producing 0, which is handy for those input checks above.
It also means that it doesn't matter to the 4.3BSd code whether the
checksum is in the TCP header is 0 or 0xffff.
Vernon Schryver, vjs@sgi.com
-----------[000141][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Jul 1993 03:04:39 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Would 0xFFFF ever be a TCP checksum? Comments pls.
In article <742167839@romeo.cs.duke.edu>, trt@duke.cs.duke.edu (Tom Truscott) writes: > ... > > -Consider a TCP packet containing no options, and 2 bytes of user > > data, where that data just happens to consist of the 1's complement > > of the checksum of the TCP header and psuedo-header. > > What would be the TCP checksum of such a TCP packet? > > It would be 0. > Suppose X is the checksum of the header (and the value of the data). > So ~X must be the sum of the header. > So the total sum is ~X + X == 0xffff. > So the checksum (the 1's complement of the end-around-carry sum) is 0. > > Another example: suppose the header and data each sum to 0xffff. > Then the total sum is again 0xffff thanks to end-around carry. All true in 4.3BSD, except that in_cksum() complements its result before returning. Which means that in_cksum() can return 0xffff but not 0, given a non-zero buffer, which seems likely given that the addresses in the psuedo-header. Vernon Schryver, vjs@sgi.com
-----------[000142][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Jul 1993 03:43:18 GMT From: cej@world.std.com (Craig E Jackson) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: What do people do for load-balancing in IP?
What do people do for load-balancing for IP applications? I mean applications which want to connect to any of n hosts. I've heard of a 'shuffle A records' patch for bind, but I don't know how it works, especially in the presence of secondary servers. Is it load based, or round-robin? What other patches or systems are available to do this? Also, what do people do in a failure situation, when you want to move an application from one host to a backup one? Do most people simply rename/number the backup host to the primary address? I suspect that this would come up when one wanted to change a CNAME record for ftp.foobar.com from a.foobar.com to b.foobar.com. For upto a day or so, couldn't secondaries and other nameservers have old data? Would it be reasonable to put a 10-minute TTL on the CNAME record only? -- Craig Jackson cej@world.std.com
-----------[000143][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Jul 1993 04:54:12 GMT From: bha@offsite.com (Bryan H Apple) To: comp.unix.sys5.r3,comp.unix.sysv386,comp.protocols.tcp-ip Subject: Help with ISC v3.0.1 slip and ethernet
OK, I'll admit it, I just don't get it! I'm have configuration
questions with slip, and /etc/route, and don't seem to get any
satisfaction out of /etc/gated. The configuration is ISC R3.2
V3.0.1 w/Maint #1 (TCP/IP 1.3)
Ethernet
----------------------------------------------
| | | |
Box A Box B Box C Box D
130.18.1.1 130.18.1.2 130.18.1.3 130.18.1.4
130.18.2.1 Modem
^
|
Box HOME v
130.18.2.2 Modem
The ethernet works fine. Class B address, subnet mask=255.255.255.0,
everybody is happy.
I have questions about slip between Box A and Box HOME.
1) Am I correct in setting up the two slip interfaces as a subnet
different from the ethernet? What if I don't?
2) What about associating names to those IP numbers. What should
I name the slip interface in Box A (if anything)?
/etc/hosts:
130.18.1.1 = Box A
130.18.1.2 = Box B
130.18.2.1 = Box A-sl (???)
130.18.2.2 = Box HOME
3) The ifconfig for the slip device specifies both the interface
IP number and the destination IP. Is this correct?
Box HOME sl0: flags=55<UP,DEBUG,POINTOPOINT,RUNNING>
inet 130.18.2.2 --> 130.18.2.1 netmask ffffff00
Box A sl0: flags=55<UP,DEBUG,POINTOPOINT,RUNNING>
inet 130.18.2.1 --> 130.18.2.2 netmask ffffff00
4) Does it make ANY difference which side initiates the
connection. I can dial Box A from Box HOME (Box A runs
sllogin and Box HOME runs sldialup). I can do it the other
way around.
5) I want Box HOME to be able to access any host on the ethernet
and visa versa. What do I do with /etc/gated or /etc/route?
Specifically, just running /etc/gated doesn't seem to get me
any results. If I try to specify routing with /etc/route I
have different problems. /etc/route calls for a destination
and a gateway. Do I run this on Box HOME, Box A, both? Does
it matter who initiated the connection?
What ever help (general or specific) you wish to offer will be
appreciated. Post or email.
--
Bryan Apple
Data Vault Systems
(708) 885-6000
-----------[000144][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Jul 1993 05:35:25 GMT From: roy@issy.cnet.fr (Jean-Michel ROY) To: comp.protocols.tcp-ip Subject: Verifying access-list on CISCO
Does anybody made a tool to verify the integrity of the access-list on a CISCO Router ?
-----------[000145][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Jul 1993 07:58:43 GMT From: etxmesa@eos.ericsson.se (Michael Salmon) To: comp.protocols.tcp-ip,comp.protocols.nfs Subject: Re: Tips on alternative to NFS requested.
In article <thurlow.742139845@convex.convex.com> thurlow@convex.com (Robert Thurlow) writes: |> In <1993Jul7.070827.3131@ericsson.se> |> etxmesa@eos.ericsson.se (Michael Salmon) writes: |> |> >I am looking for an alternative to NFS, preferably TCP based. RFS seems |> >to do what I want but I can't yet find a standard for it. All |> >suggestions welcome. |> |> I might have some suggestions if I had any clue about what problems |> you were trying to solve. Asking for "better" is only goung to get |> you noise, in my opinion, unless we know what "better" would feel |> like to you. Basically I need a more secure remote file system and a simpler one, the first requirement is the more important. It should also not consume very much processor time and be supported by every Unix system. Seriously though, I want a protocol that is fast, secure, standard and tcp based (to avoid building my own timers). My understanding is that NFS is not particularly secure in its mounting. I also understand that I can use NFS over TCP as RPC is not dependant upon protocol, however I haven't heard of anyone who has done that. I could also use a tcp connection to port mapper but the standard is a little uncertain about whether CALLIT can be used from tcp. -- Michael Salmon #include <standard.disclaimer> #include <witty.saying> #include <fancy.pseudo.graphics> Ericsson Telecom AB Stockholm
-----------[000146][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Jul 1993 08:17:34 GMT From: donp@novell.com (don provan) To: comp.protocols.tcp-ip Subject: Re: Would 0xFFFF ever be a TCP checksum? Comments pls.
In article <742169155@romeo.cs.duke.edu> trt@duke.cs.duke.edu (Tom Truscott) writes: >>I think i'm the one that made the NetWare TCP code send 0xffff instead >>of zero, but now i can't remember why i did it. > >There is no need to do it for TCP. Are you saying that you know for sure that there's no need to do this for TCP, or are you just saying that you don't see anything in the spec that calls for it? I could have sworn that i changed that code specifically because there was a TCP implementation that rejected arriving TCP packets with a zero in the checksum field, but now i can't recall. Needless to say, such an implementation would be broken, but it's a fairly simple to accomodate it by sending it the checksum value it expects. Now with at least one broken implementation coming up that rejects packets with 0xffff in the checksum field, i guess i must have backed the wrong horse...or i suppose i may have just gotten my bits flipped. don provan donp@novell.com P.S. By the way, son, i've been calculating checksums since you were in knickers, so you really don't need to explain to me how they work. -dp
-----------[000147][next][prev][last][first]---------------------------------------------------- Date: 9 Jul 93 11:30:24 GMT From: jordan@IMSI.COM (Jordan Hayes) To: comp.protocols.tcp-ip Subject: Re: KEEPALIVE option for tcp sockets
Dennis Newport <devdjn@space.alcbel.be> writes: All that seems to have occurred so far is that the responses are bitching about which manual pages he is reading. Does anyone have an answer? I started the discussion about reading the manual because I wanted to clarify that the manual pages (not to mention the 4.3 Book) say *nothing* about getting notified when the KEEPALIVE timer goes off. Ok, maybe that's a bug or a misfeature. Regardless, It *only* says that the socket will get marked as invalid and that the *next* time a read or a write is attempted that it will return an error. Specifically, I wrote: In all Unix implementations that I know of, if the keepalive timer goes off, the socket is marked as invalid, but select() does not return. People don't really seem to answer things in this group. They just chat. Don't be rude. Have a nice day. /jordan
-----------[000148][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Jul 1993 12:47:53 GMT From: carlson@steam.Xylogics.COM (James Carlson) To: comp.protocols.tcp-ip Subject: Re: Bug in many versions of TCP
In article <1993Jul9.015552.16180@burrhus.harvard.edu>, ddl@burrhus.harvard.edu (Dan Lanciani) writes: |> In article <1993Jul7.195317.3075@xylogics.com>, carlson@steam.Xylogics.COM (James Carlson) writes: |> |> | IMPORTANT BUG FIX FOR TCP INPUT CODE |> | |> | Xylogics has found and fixed a bug that exists in the tcp_input.c |> | routine in 4.4BSD and several other versions of TCP. We strongly |> | recommend that you examine your version of TCP for this error. |> |> Interestingly, I recently posted a fix for this same code in relation |> to the self-connect problem. Both problems are caused by throwing away |> perfectly good ACKs just because data was trimmed. While I believe |> Xylogics' patch will work, it does introduce some unnecessary code; |> to wit: |> |> | if ((tiflags & TH_FIN) && todrop == ti->ti_len + 1) |> | tiflags &= ~TH_FIN; |> |> At this point, we already know that either TH_FIN wasn't set to begin with |> or todrop is greater than ti->ti_len. Therefore, TH_FIN can be cleared |> unconditionally. The first clause of the suggested if() statement is moot, |> so the only time this would make a difference is if todrop is greater than |> ti->ti_len + 1 with TH_FIN set. That condition would imply a FIN occupying |> the sequence number of previously transmitted data, a weird situation to |> say the least! I strongly disagree with that statement. The FIN and SYN "bits" *DO* occupy sequence numbers, and do need to be checked in this manner. The problem is this: It is possible to enter this section of code with a packet that has some old data and some new data. Consider the case where the "new data" consists of some number of new octets and a FIN bit -- in that case you will want to drop the old data, keep the new data, and notify the application that no more data will arrive (FIN). Now consider the case where all of the data is old, but it now has a FIN bit -- in that case you want to notify the application that there are no more data. Lastly, there is the case where all of the data -- including an ACK-ed FIN -- are duplicate. In that case, you do not want to notify the application (again) that the connection is closing. You just want to re-ACK the FIN since the peer must have lost an ACK. The code is not introduced in this patch -- it is retained from the original Berkeley code. -- James Carlson <carlson@xylogics.com> Tel: +1 617 272 8140 Annex Software Support / Xylogics, Inc. +1 800 225 3317 53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 3159
-----------[000149][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Jul 1993 14:01:33 GMT From: Steinar.Haug@runit.sintef.no (Steinar Haug) To: comp.protocols.tcp-ip,comp.sys.hp Subject: Re: Are port numbers < 1023 reserved for the client end of an FTP data connection?
I wrote: > That's basically my interpretation also. Unfortunately the HP support > folks here in Norway (who answered quickly and efficiently, just not the > answer I wanted) dug up a similar case (also involving an AS/400), and > said, in effect, that "HP has decided that it follows the standard; case > closed". I'm trying to dig up supporting evidence for *not* closing the > case. I did some digging in what I had saved from comp.protocols.tcp-ip, and found one interesting message from Don Provan. This whole discussion has evidently happened before, and in that case too HP was the one causing the problem. How can we get HP to understand that they should change? Steinar Haug, system/networks administrator SINTEF RUNIT, University of Trondheim, NORWAY Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no ---------------------------------------------------------------------- From: donp@na.excelan.com (don provan) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ports 1000-1023 reserved? Date: 31 Jul 90 19:51:51 GMT Reply-To: donp@novell.com (don provan) Organization: Novell, Inc., San Jose, California In article <1990Jul31.115309.1@rogue.llnl.gov> oberman@rogue.llnl.gov writes: >In article <9007301547.AA19807@ucbvax.Berkeley.EDU>, DBARTON@IBM.COM writes: > >> TCP/IP Version 2 for VM will start allocating ports at port number 1024, >> to prevent this problem with the Hewlett Packard product. > >I beg to differ. Please check RFC-1060 in the section "UNIX PORTS". > > By convention, ports in the range 256 to 1024 are used for "Unix > Standard" services. OK, this discussion has gotten out of hand and i'm afraid some innocent novice it going to believe some of this misinformation. While it is true that ports lower than 1024 are reserved on many systems, that has nothing whatsoever to do with the HP bug that's being discussed here. The port given in the FTP PORT command is a *remote* port. There's no justification at all for HP checking this port for any range of any type for any reason. It should just use the port given. I don't even understand what prompted some misguided soul to add the extra, unnecessary code needed to make this check. I applaud the IBM developers for making this simple change to accommodate the HP implementation, but i want everyone to understand that the HP implementation is, in fact, broken. don provan donp@novell.com
-----------[000150][next][prev][last][first]---------------------------------------------------- Date: 9 Jul 1993 14:47:14 GMT From: booloo@framsparc.ocf.llnl.gov (Mark Boolootian) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.ppp Subject: SLIP vs. PPP: Which is best?
If I have a choice of running SLIP or PPP, which should I run? I'd be interested in hearing about the relative (dis)advantages of each of these protocols. Thanks in advance, mb -- Mark Boolootian booloo@llnl.gov +1 510 423 1948 Disclaimer: booloo speaks for booloo and no other.
-----------[000151][next][prev][last][first]---------------------------------------------------- Date: 9 Jul 1993 15:40:54 GMT From: bryan@notorious.rs.itd.umich.edu (Bryan Beecher) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: Re: What do people do for load-balancing in IP?
In article <C9vp07.AA9@world.std.com> Craig E Jackson writes: > >I've heard of a 'shuffle A records' patch for bind, but I don't know >how it works, especially in the presence of secondary servers. Is it >load based, or round-robin? > >What other patches or systems are available to do this? There's a copy of BIND 4.9 and a patch file containing the umich "goodies" that didn't make it into 4.9 available for anonymous ftp from terminator.rs.itd.umich.edu in the /dns/bind4.9 directory. Also, if you look in /dns/info, there is also some information about my shuffle A records, and the other contenders out there (CIP and POOL). The latter was written by David Bolen of ANS, and I thought it was so good, I kept a copy. It discusses the various features of all three record types. In brief, shuffle A (SA) records are sort of round-robin. My code does not re-order the records; but it does treat the records as a circular list, and randomly picks a new head of the list. They are IN NO WAY load based. We use them for various computing clusters where a connection to some random machine -- not necessarily the least loaded -- is good enough. Unless 'named' is started with a "-s" flag (that is part of the SA patch), SA records are transferred as A records to a secondary server. Merit Inc uses a combination of SA records and A records for the name hermes.merit.edu. One feature of SA records is that if a name has both SA records and A records, *both* types of records get shuffled. (And to the client, they appear as A records.) In the case of Merit, their server (merit.edu) understands SA records and so does one of their secondary servers (dns2.itd.umich.edu); a second secondary server (ncar.ucar.edu) does not understand SA records. The 'named' on merit.edu uses the "-s" flag, and so on a zone transfer, it sends SA records for SA records (i.e., it doesn't substitute A records for SA records). hermes.merit.edu consists of several A records and a single SA record. Thus, due to the feature I mentioned above, the records get shuffled together when a query goes to merit.edu or dns2.itd.umich.edu, the two servers that understand SA records. Queries going to ncar.ucar.edu aren't shuffled, and since it doesn't understand SA records, it also happens to discard the one SA record it gets. The remaining records (all A) are returned in the usual, static order. I'm hoping to formally write-up SA records in a RFC (like Bill Manning's RFC on NSAP records) sometime this month, and that might make finding information about them a little easier. If you have any questions or suggestions, please don't hesitate to send them to me. -- Bryan Beecher, U-M Information Technology Division (+1 313 747 4050) Domain: Bryan.Beecher@umich.edu Path: ..!uunet!destroyer!bryan
-----------[000152][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Jul 1993 16:12:45 GMT From: erick@sunee.uwaterloo.ca (Erick Engelke) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: Re: What do people do for load-balancing in IP?
> cej@world.std.com (Craig E Jackson) writes: >What do people do for load-balancing for IP applications? I mean applications >which want to connect to any of n hosts. > >I've heard of a 'shuffle A records' patch for bind, but I don't know >how it works, especially in the presence of secondary servers. Is it >load based, or round-robin? Shuffling A records is not really a great solution. I think most of our IP-savvy (practicing my American colloquialisms) readers would agree that A record swapping is more appropriate when the change is more permanent than the duration of an application. >What other patches or systems are available to do this? I posted on this topic a few weeks ago, so frequent readers may choose to skip this reply. There is a product which does something like you ask for TELNET sessions. It will load balance given priorities you assign. It also handles downed hosts and other anomolies. Contact info@snsi.com about the EAGATE as it may be a good option for your particular use. Erick --
-----------[000153][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Jul 1993 16:26:37 GMT From: jmc@hal.com (Jerry McCollom) To: comp.protocols.tcp-ip,comp.sys.hp Subject: Re: Are port numbers < 1023 reserved for the client end of an FTP data connection?
Steinar.Haug@runit.sintef.no writes: >jmc@hal.com (Jerry McCollom) writes: >> What version of HP-UX do you have? This was a feature of HP-UX 7.0 and >> some prior releases, but I believe it was removed in HP-UX 8.0 and later >> based on customer complaints and on discussion on comp.protocols.tcp-ip >> that concluded (especially, as I remember, after an authoritative reply >> from Jon Postel) that it was out of spec. > >It is in all the versions of HP-UX I have checked: > > HP-UX 8.0 s400 > HP-UX 8.07 s700 > HP-UX 9.0 s700 > HP-UX 9.01 s700 > HP-UX 9.0 s800 > >I would be extremely interested if you could dig up that answer from >Jon Postel. Alas, either I failed or it was reintroduced before 8.0 released to customers (several months after I had my hands on it). If I failed, my personal apologies for botching it. Be assured, though, that I agree this is incorrect behavior. I dropped a line to a buddy in HP to bring this problem to their attention. Their defect history may include Postel's reply, but, as my (well demonstrated :-) cloudy memory recalls, it was a terse statement to the effect that the HP server is broken. Jerry (again speaking neither for HP nor for HaL) -- Jerry McCollom HaL Computer Systems, Inc., Austin, TX jmc@hal.com
-----------[000154][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Jul 1993 16:41:04 +0000 From: steve@one47.demon.co.uk (Stephen R Davies) To: comp.protocols.tcp-ip Subject: Re: SCO 3.2v2.2 -> 3.2v4.1
In article <39@westfield.win.net> debiso@westfield.win.net (Joe DeBiso) writes:
>
>In article <4.1494.362.0N566670@euronetis.no>, Rune Mossige (rune.mossige@euronetis.no) writes:
>>
>>
>>I've just come onto a very strange problem. We have two SDI 80486
>>machines running SCO unix. One is running 3.2v4.1 and the other is
>>running 3.2v2.2
>>
>>I upgrading the 3.2v2.2 box to v4.1, but after the upgrade, I was not
>>able to get contact with the network. Nothing at all. [...]
You really should upgrade TCP/IP to version 1.2 and install LLI. I also
recommend that you install everything from scratch, as some of the
uninstall scripts don't work completely...
Steve.
============================================================================
_/_/_/ _/_/_/ _/_/_/ _/ _/ _/_/_/ Trebor Bassett Limited,
_/ _/ _/ _/ _/ _/ Hertford Place, Denham Way,
_/ _/ _/_/ _/ _/ _/_/ Maple Cross, Herts., WD3 2XB.
_/ _/ _/ _/ _/ _/ Tel.: +44 (0)923 896565
_/_/_/ _/ _/_/_/ _/ _/_/_/ steve@one47.demon.co.uk
======================= PGP 2.3 public key available =======================
-----------[000155][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Jul 1993 16:55:47 GMT From: phil@pex.eecs.nwu.edu (William LeFebvre) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: Re: What do people do for load-balancing in IP?
In article <21k3i6$rar@terminator.rs.itd.umich.edu> bryan@notorious.rs.itd.umich.edu (Bryan Beecher) writes: >I'm hoping to formally write-up SA records in a RFC (like Bill >Manning's RFC on NSAP records) sometime this month, and that might make >finding information about them a little easier. If you have any >questions or suggestions, please don't hesitate to send them to me. Yes I have a suggestion, not just for you but for consideration by the entire DNS community. Instead of stuff like SA, CIP, and POOL records what we need is a more generalized mechanism. SA records are great, but some people need honest-to-gosh load balancing. Yet I don't like the idea of embedding actual load determining code in named itself. Besides, this problem could potentially extend to more than just A records. Why standardize on a solution that is restricted to only A records? What we need is a mechanism whereby a site administrator can dictate his/her own policy on the order in which A records are handed out in a reply. I'd like to propose a really radical idea (I'm good at doing that :-) ). How about a mechanism that allows a DNS server to determine an appropriate answer via external means? This could take the form of a perl or shell script, a program, or what have you. This process could do whatever it wants to do (under total control of the zone adminstrator) to determine, for example, the order in which A records should appear in the answer. Or the order in which MX priority 0 records should appear, for instance. Or perhaps even the priorities in the MX records (imagine being able to change dynamically which mail exchangers have what priority!). Now I haven't thought this through completely....this is still a pretty rough idea, but I'd like to see discussion about it. In some ways, a mechanism like this already exists within DNS: it's called the NS record. So here's my off-the-top-of-the-head idea. Let's invent a new records called FWD, for forward. It specifies a host AND a port number to which any query on the associated string should be forwarded. When an authoritative server see a question that resolves to a FWD record, it forwards the question along to the host/port specified in the record (whoops....that will only work for the IN class) and will return whatever answer it gets back. To provide robustness, you could specify muiltiple FWD records. Now the server that runs on the specified name/port could be stripped down. It wouldn't need to be a full blown DNS server (it probably doesn't even need the asynchronicity that named has). In fact, it would have to be written in an entirely different manner if we are going to leave determination of the answer up to the administrator. What I envision is a library of routines to do all the grubby DNS stuff (reading and parsing questions, building and sending answers) and an administrator writing a C program or a perl script on top of this library to actually determine what the answer should be. We might also need to restrict what types of RRs could be sent in answer to a FWD....I haven't given much thought to possible ramifications here (especially the effects that caching these answers will have on functionality). Why go to all the bother? We could just provide a hook in named so that the authoritative server would invoke a program to get the answer. But this might be very difficult to work in to the asynchronous nature of named. Plus, this external program would need to exist on ALL the secondaries, or the whole thing will be useless. And that could be a potentially serious concern, since most every zone has an off-site secondary. The advantage of having a FWD record is that it can easily be part of a zone transfer to anywhere in the world and the receiving site will always be able to do something useful with it. It occurs to me that this very mechanism could solve a problem brought up here a week or so ago: how to accomodate non-octet subnetting in in-addr.arpa. With FWD records you could potentially "delegate" part of a domain to another server on a label-by-label basis. I'm sure there are many disadvantages and pitfalls to this idea, not the least of which would be actually implementing it. But since everone is turning to DNS to do things like load-balancing, I think the time is ripe for a good general mechanism to solve the problem. Comments? William LeFebvre Computing Facilities Manager and Analyst Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>
-----------[000156][next][prev][last][first]---------------------------------------------------- Date: 9 Jul 1993 17:41:01 GMT From: bryan@notorious.rs.itd.umich.edu (Bryan Beecher) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: Re: What do people do for load-balancing in IP?
In article <C9wpp0.B92@eecs.nwu.edu> William LeFebvre writes: > >I'm sure there are many disadvantages and pitfalls to this idea, not >the least of which would be actually implementing it. But since >everone is turning to DNS to do things like load-balancing, I think >the time is ripe for a good general mechanism to solve the problem. I agree with you in that it would be useful and convenient to have some solution to the "load balancing" problem. Using some external process seems to be a better method than glueing more and more stuff into 'named'. And as you said, this could easily be useful in all sorts of ways. It turns 'named' from a database of resources to a database of pointers to resources. That said, I also think that the SA record, or more generally, any sort of record with a data flag set to indicate that ordering should be random instead of static, is very useful. One of the big wins with this approach is that it interoperates very well with existing client software and existing nameservers. Something like a FWD record could be *the* solution, but until the FWD record becomes ubiquitous, it isn't a viable solution. But that isn't a strike against the idea; it just means it cannot be today's solution. -- Bryan Beecher, U-M Information Technology Division (+1 313 747 4050) Domain: Bryan.Beecher@umich.edu Path: ..!uunet!destroyer!bryan
-----------[000157][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Jul 1993 18:18:58 GMT From: braun@novell.com (Karl Braun) To: comp.protocols.tcp-ip Subject: Re: Would 0xFFFF ever be a TCP checksum? Comments pls.
In article <1993Jul9.081734.11702@novell.com> donp@novell.com (don provan) writes: > >...or i suppose i may have just gotten my bits flipped. > I hate it when that happens... kral 408/647-6112 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
-----------[000158][next][prev][last][first]---------------------------------------------------- Date: 9 Jul 93 19:46:14 GMT From: schmidt@net1.ics.uci.edu (Douglas C. Schmidt) To: comp.protocols.tcp-ip Subject: Re: bypassing TCP checksum (was RFC 1191 compliance)
Hi, I'd be interested to know if there are any conference, workshop, or journal articles that I could cite regarding the combination data-copy/checksumming optimizations described in recent discussions on this newsgroup. Have any of the performance numbers presented here been published yet? Thanks, Doug -- His life was gentle, and the elements so | Douglas C. Schmidt Mixed in him that nature might stand up | schmidt@ics.uci.edu And say to all the world: "This was a man." | ucivax!schmidt -- In loving memory of Terry Williams (1971-1991)| (714) 856-4101
-----------[000159][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 93 03:19:49 -0400 From: spjrg@drycas.club.cc.cmu.edu (Jim Glover) To: comp.protocols.tcp-ip Subject: Can anyone recommend some good reading?
In the coming months, I will be considering the implementation of
a network involving up to a dozen or so sites at various locations in
one city, and a client/server application which will run on this
network. I'm a VM system programmer by profession, and have some
experience with networked PC's. I need to educate myself enough to be
able to make wise decisions concerning type of network, what
language(s) I should use for writing the client and server, and what
kind of hardware to use.
It is important for this new network and application to be as
inexpensive as possible and have the potential for growth in the
future. The network will be devoted to this single application. As
of now, I'm thinking in terms of TCP/IP, IBM PC compatibles as the
workstations, and a server that will run on a PC compatible at first,
but could be ported to a more powerful system as the network grows, if
needed. I'm not sure whether I'd want networking software for the
upper layers, or if my client and server should be designed to work
without that support.
Now that you have some idea what I'm up to, can anyone recommend
sources of information that will help me make the best possible design
decisions? What I really want are recommendations about books that
will give me the knowledge I need to make good decisions, although
specific recommendations won't be ignored, even in this early stage.
Thanks in advance for anything you can recommend.
-----------[000160][next][prev][last][first]---------------------------------------------------- Date: 9 Jul 93 21:24:25 GMT From: rturner@imagen.com (Randy Turner) To: comp.protocols.tcp-ip Subject: Zero-window probing
Should TCP zero-window probes always contain data? Thanks! Randy -- ----------------------------------------------------------------------------- Randy Turner QMS, Inc. rturner@aqm.com
-----------[000161][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Jul 1993 21:27:42 GMT From: sameer@atlastele.com To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: Re: What do people do for load-balancing in IP?
In article <C9vp07.AA9@world.std.com> cej@world.std.com (Craig E Jackson) writes: >What do people do for load-balancing for IP applications? I mean applications >which want to connect to any of n hosts. > >I've heard of a 'shuffle A records' patch for bind, but I don't know >how it works, especially in the presence of secondary servers. Is it >load based, or round-robin? Points on applic.load bal. deleted Also, what about load balancing between two hosts connected by a dual dial-up SLIP lines. How would that work. In case one line goes down the traffic shifts to the other line. Any ideas ? THanks, Sameer.. -- ================================================================== "I strongly disclaim the above disclaimer. Hey you stupid machine why did you put it in there!, Hey Stop!, Stop right there, I have a right to fre@$# ommuph!, arrghhh! choke! sp*#ch..SPLAT!!......."
-----------[000162][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Jul 1993 21:31:00 GMT From: mack23@avalon.eecs.nwu.edu (Chris Walsh) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: Re: What do people do for load-balancing in IP?
In article <C9wnpA.82H@watserv1.uwaterloo.ca> erick@sunee.uwaterloo.ca (Erick Engelke) writes:
>
>> cej@world.std.com (Craig E Jackson) writes:
>>What do people do for load-balancing for IP applications? I mean applications
>>which want to connect to any of n hosts.
>
>There is a product which does something like you ask for
>TELNET sessions. It will load balance given priorities you
>assign. It also handles downed hosts and other anomolies.
>
>Contact info@snsi.com about the EAGATE as it may be a good
>option for your particular use.
There's also a product from HP called Task Broker which does this. It uses
a daemon to solicit "bids" from servers for specified processes. The servers
return a bid in the form of an integer. Highest non-zero integer gets the
job. The product is available for HP, SUN, RS6K and possibly other machines,
as I recall. In essence, Bill LeFebvre's FWD record suggestion (which I
think is pretty cool) amounts to bundling into named the bid solicitation
process.
There was a vendor display at the January USENIX in San Diego that was showing
a similar product to Task Broker. It was cheaper but not quite as cool. I
do not have the sales propaganda handy, but there are apparently at least three
packages that purport to do some load balancing, for at least some processes.
EAGATE seems the most limited, Task Broker the least, and the USENIX vendor's
somewhere in the middle. I apologize for posting this to this newsgroup, but
given the latent interest out there, I thought it was defensible. Before
following up, you might want to change the headers. I could not think of
an appropriate newsgroup :^).
--
Chris Walsh "Cable, I wish you were with me now."
Technet Network Administrator --John Cale
Northwestern Univ. "Networks of the future cannot fail."
2145 Sheridan Rd. --Roger Dev, Cabletron (out of context)
Evanston, IL 60208
DoD# 0671
-----------[000163][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Jul 1993 21:39:19 GMT From: bossert@claircom.com (John Bossert) To: comp.protocols.tcp-ip,comp.sys.sun.misc,comp.source.wanted Subject: Help with writing to /dev/nit (SunOS)
Could someone send me a snippet of code showing how to _write_ to /dev/nit? I'm trying to construct a RARP daemon and am able to pull packets _from_ /dev/nit, but my reply packets are going nowhere. This is on a Sparc IPX, running SunOS 4.1.3. Thanks in advance. John Bossert bossert@claircom.com
-----------[000164][next][prev][last][first]---------------------------------------------------- Date: 9 Jul 93 22:25:44 GMT From: trt@duke.cs.duke.edu (Tom Truscott) To: comp.protocols.tcp-ip Subject: Re: Would 0xFFFF ever be a TCP checksum? Comments pls.
>>If 0xffff had been used as the "no checksum" value >>then no special check would have been needed (see previous article). > >No, that is not true. What is the checksum of 4 bytes with contents >0000 0000? (sum = 0000, so the checksum is ffff.) But 0000 0000 (or any data that is entirely 0) is not a valid packet. This whole thing is pretty trivial. I regret having brought it up.
-----------[000165][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 1993 01:26:54 GMT From: trier@odin.ins.cwru.edu (Stephen C. Trier) To: comp.protocols.tcp-ip Subject: Re: Zero-window probing
In article <rturner.742253065@imagen> rturner@imagen.com (Randy Turner) writes:
> Should TCP zero-window probes always contain data?
They would not be particularily useful if they did not, because there
is no reason for the receiving TCP to ack a dataless packet.
The TCP should never probe unless it has data to send, but if it has data,
it should include the data in the probe packet.
Stephen
--
Stephen Trier (trier@ins.cwru.edu - MIME OK)
Network Software Engineer
IRIS/INS/T
Case Western Reserve University
-----------[000166][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 93 01:34:35 GMT From: rturner@imagen.com (Randy Turner) To: comp.protocols.tcp-ip Subject: Re: Zero-window probing
rturner@imagen.com (Randy Turner) writes: > Should TCP zero-window probes always contain data? > Thanks! > Randy >-- >----------------------------------------------------------------------------- >Randy Turner >QMS, Inc. >rturner@aqm.com Never mind, after taking the time to peruse RFC 793, in section 3.7 it says that the host must be able to send at least 1 octet of data in zero-window probes to try and detect the window opening. I would think it would normally try and send the data it wanted to send in the first place, just in case the window opened while the output pkt was in transit. The reason I asked is that we have been asked to modify our implementation so that it responds to window-probes with no data in them. The other implementation that we have been asked to be compliant with is Wollongong's Pathway TCP/IP product for the PC. We observed the Wollongong's zero-window probing on a Lanalyzer and it did not include any data in the probes, so our implementation was not responding to it with the updated window size. Clearly this is not our fault since I feel we are RFC793 compliant, and while we might could make the changes to force ourselves to work with the Wollongong product, I feel like we probably should not. To date, this is the only TCP/IP implementation that we have tested with that does not send data with zero-window probes. Today, we tested with an SGI IRIS and it even goes to the trouble of sending an ASCII '0' in the data portion of the packet, just to be compliant (I guess...). Solaris 2.2 tries to go ahead and send a full packets worth of data from it's send queue along with the probe, which is what I would expect. Comments? Randy -- ----------------------------------------------------------------------------- Randy Turner QMS, Inc. rturner@aqm.com
-----------[000167][next][prev][last][first]---------------------------------------------------- Date: Sat, 10 Jul 93 01:59:38 GMT From: ddl@burrhus.harvard.edu (Dan Lanciani) To: comp.protocols.tcp-ip Subject: Re: Bug in many versions of TCP
In article <1993Jul9.124753.12821@xylogics.com>, carlson@steam.Xylogics.COM (James Carlson) writes:
| In article <1993Jul9.015552.16180@burrhus.harvard.edu>,
| ddl@burrhus.harvard.edu (Dan Lanciani) writes:
| |>
| |> At this point, we already know that either TH_FIN wasn't set to begin with
| |> or todrop is greater than ti->ti_len. Therefore, TH_FIN can be cleared
| |> unconditionally. The first clause of the suggested if() statement is moot,
| |> so the only time this would make a difference is if todrop is greater than
| |> ti->ti_len + 1 with TH_FIN set. That condition would imply a FIN occupying
| |> the sequence number of previously transmitted data, a weird situation to
| |> say the least!
|
| I strongly disagree with that statement. The FIN and SYN "bits" *DO*
| occupy sequence numbers, and do need to be checked in this manner.
I'm not sure which part of my statement you disagree with, but nowhere
do I say that FIN and SYN don't occupy sequence space. The situation
to which I refer is one in which a FIN is received whose sequence number is
the same as that of previously received (and presumed valid) data.
| The problem is this: It is possible to enter this section of code with
| a packet that has some old data and some new data.
Is it? Consider that the entire block of code is within the following if():
if (todrop > ti->ti_len ||
todrop == ti->ti_len && (tiflags&TH_FIN) == 0) {
This says that either we are throwing away more than the whole packet
(in other words, we are trimming all the data plus at least one more
to account for a possible FIN) or else we are trimming exactly the length
of data in the packet but the FIN flag isn't set. How can a packet with
new data pass this test?
| Consider the case
| where the "new data" consists of some number of new octets and a FIN
| bit -- in that case you will want to drop the old data, keep the new
| data, and notify the application that no more data will arrive (FIN).
In this case the code is question would never run because todrop
is less than ti->ti_len.
| Now consider the case where all of the data is old, but it now has a FIN
| bit -- in that case you want to notify the application that there are no
| more data.
In this case the code in question would still not run because, although
todrop exactly equals ti->ti_len, (tiflags&TH_FIN) is non-zero.
| Lastly, there is the case where all of the data -- including
| an ACK-ed FIN -- are duplicate. In that case, you do not want to notify
| the application (again) that the connection is closing. You just want
| to re-ACK the FIN since the peer must have lost an ACK.
In this case the code runs and does the right thing by clearing
the TH_FIN flag.
Now, the interesting case that I mentioned above is one where
all the data (and any possible FIN) is duplicate but the sequence
space occupied by the FIN was previously used by valid data. Obviously,
either such a segment is bogus or some previous segment was bad. While
I suppose you could make an argument to do something clever, I think the
appropriate action is to drop the bogus FIN. Whatever your opinion on
the correct action, however, you probably want to at least be consistent.
This is where your test of (todrop == ti->ti_len + 1) creates two
different sub-cases:
Sub-1. If the bogus FIN has the same sequence number as the last octet of
data received (rcv_nxt - 1), then todrop will be equal to ti->ti_len + 1 and
you will discard the FIN. I consider this behavior correct.
Sub-2. If the bogus FIN has a sequence number before that of the
last octet of data received, then todrop will be greater than ti->ti_len + 1
and you will process the FIN. I consider this incorrect: a FIN from a
previous connection could terminate the current connection even though
is has a sequence number before rcv_nxt.
| The code is not introduced in this patch -- it is retained from the
| original Berkeley code.
Not exactly. The original code was:
if ((tiflags & TH_FIN && todrop == ti->ti_len + 1)
#ifdef TCP_COMPAT_42
|| (tiflags & TH_RST && ti->ti_seq == tp->rcv_nxt - 1)
#endif
) {
todrop = ti->ti_len;
tiflags &= ~TH_FIN;
tp->t_flags |= TF_ACKNOW;
} else
goto dropafterack;
You collapsed the if() statement to:
if ((tiflags & TH_FIN) && todrop == ti->ti_len + 1)
tiflags &= ~TH_FIN;
removing the else/goto clause and leaving these statements to execute always:
todrop = ti->ti_len;
tp->t_flags |= TF_ACKNOW;
The key difference is that the original code either cleared TH_FIN or jumped
to dropafterack, knowing that the flags would then be ignored. In no
case did the original code fall through with TH_FIN still set. The problem
with the original code was that it branched to dropafterack in several cases
where it should have fallen through for more processing. There was no problem
with clearing TH_FIN.
Dan Lanciani
ddl@harvard.*
-----------[000168][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 93 13:16:02 From: jim@cs.strath.ac.uk (Jim Reid) To: comp.protocols.tcp-ip,comp.protocols.nfs Subject: Re: Tips on alternative to NFS requested.
In article <1993Jul9.075843.3569@ericsson.se> etxmesa@eos.ericsson.se (Michael Salmon) writes: Basically I need a more secure remote file system and a simpler one, the first requirement is the more important. It should also not consume very much processor time and be supported by every Unix system. You might as well be asking for World Peace or a cure for cancer. NFS is to all extents the ONLY network file system protocol that is readily available on any UNIX system. The only other obvious choice is RFS. This is a little more secure, harder to administer and far, far less ubiquitous. I have yet to come across a site using it. My understanding is that NFS is not particularly secure in its mounting. Not really. The first implementations of the NFS mount daemon were very trusting. Current versions take a lot more care over who gets to mount what. You now need to impersonate a host if you want to spoof the server. I also understand that I can use NFS over TCP as RPC is not dependant upon protocol, however I haven't heard of anyone who has done that. I could also use a tcp connection to port mapper but the standard is a little uncertain about whether CALLIT can be used from tcp. The NFS by Rick Macklem for 4.4 BSD can work over TCP as well as UDP. However, there are very few other NFS implementation (none?) which do this. Commercial suppliers ship NFS running over UDP because that's what everybody else uses. It's true that Sun RPC is independent of the transport protocol (sort of). However NFS is a "special case". The NFS protocol is handled by the kernel and it is heavily interlinked with the UDP code there. Jim
-----------[000169][next][prev][last][first]---------------------------------------------------- Date: Sat, 10 Jul 93 12:54:03 GMT From: IVERSEN@vsfys1.fi.uib.no (Per Steinar Iversen) To: comp.protocols.tcp-ip Subject: Re: Tips on alternative to NFS requested.
In <JIM.93Jul10131602@lister.cs.strath.ac.uk> jim@cs.strath.ac.uk writes:
> The NFS by Rick Macklem for 4.4 BSD can work over TCP as well as UDP.
> However, there are very few other NFS implementation (none?) which do
> this. Commercial suppliers ship NFS running over UDP because that's
> what everybody else uses.
Not quite, MultiNet TCP/IP for VMS by TGV can use TCP, here is from the
help file:
NFSMOUNT
/TRANSPORT
/TRANSPORT=({LOCAL,NETWORK})
Specifies the underlying transport to be used for the NFS requests. The
default is UDP if /TRANSPORT is not specified. The TCP transport
can be used with servers that support it. If both transports are
specified, TCP is tried first, and if it fails the mount falls back
to UDP.
So at least one commercial implementations can use TCP too.
-psi (iversen@vsfys1.fi.uib.no)
-----------[000170][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 1993 13:20:02 GMT From: trier@odin.ins.cwru.edu (Stephen C. Trier) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: Re: What do people do for load-balancing in IP?
In article <1993Jul9.212742.1341@atlastele.com> sameer@atlastele.com writes: >Also, what about load balancing between two hosts connected by a dual >dial-up SLIP lines. How would that work. >In case one line goes down the traffic shifts to the other line. Any ideas ? That's a routing issue. Any routing algorithm can cope with the fallback from one line to another. The Internet would hardly work were that not the case! Sharing load while both lines are up is a more difficult problem, but I think Cisco advertise that their routers can do it. Followups to comp.protocols.tcp-ip. Stephen -- Stephen Trier (trier@ins.cwru.edu - MIME OK) Network Software Engineer IRIS/INS/T Case Western Reserve University
-----------[000171][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 1993 13:30:51 GMT From: trier@odin.ins.cwru.edu (Stephen C. Trier) To: comp.protocols.tcp-ip Subject: Re: Zero-window probing
In article <rturner.742268075@imagen> rturner@imagen.com (Randy Turner) writes:
> Today, we tested with an SGI IRIS
> and it even goes to the trouble of sending an ASCII '0' in the data
> portion of the packet, just to be compliant (I guess...).
This sounds suspiciously a keepalive packet, not a zero-window probe.
The zero-window probe works by sending real data. If the probe
succeeds, that data gets delivered! If your data included NUL bytes,
you are probably OK. If it did not include NULs, you were not seeing a
zero-window probe.
Keep-alive packets may or may not contain one "garbage octet". Since
the keep-alives work by sending at a sequence number the remote has
already acked, it doesn't matter what the octet contains. NUL would be
logical.
Stephen
--
Stephen Trier (trier@ins.cwru.edu - MIME OK)
Network Software Engineer
IRIS/INS/T
Case Western Reserve University
-----------[000172][next][prev][last][first]---------------------------------------------------- Date: Sat, 10 Jul 1993 14:36:42 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Tips on alternative to NFS requested.
In article <1993Jul10.125403.7400@alf.uib.no>, IVERSEN@vsfys1.fi.uib.no (Per Steinar Iversen) writes: > In <JIM.93Jul10131602@lister.cs.strath.ac.uk> jim@cs.strath.ac.uk writes: > > > The NFS by Rick Macklem for 4.4 BSD can work over TCP as well as UDP. > > However, there are very few other NFS implementation (none?) which do > > this. Commercial suppliers ship NFS running over UDP because that's > > what everybody else uses. > > Not quite, MultiNet TCP/IP for VMS by TGV can use TCP,.... > So at least one commercial implementations can use TCP too. BSDI's BSD/386 costs money and works pretty well, and so qualifies as "commercial", and also supports NFS over TCP. There are also the free 386BSD and NetBSD, which being free may not be "commercial." However, you can pay for CDROM's containing 386BSD 0.1. Vernon Schryver, vjs@sgi.com
-----------[000173][next][prev][last][first]---------------------------------------------------- Date: Sat, 10 Jul 1993 14:41:35 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Zero-window probing
In article <21mgab$mlc@usenet.INS.CWRU.Edu>, trier@odin.ins.cwru.edu (Stephen C. Trier) writes: > In article <rturner.742268075@imagen> rturner@imagen.com (Randy Turner) writes: > > Today, we tested with an SGI IRIS > > and it even goes to the trouble of sending an ASCII '0' in the data > > portion of the packet, just to be compliant (I guess...). > > This sounds suspiciously a keepalive packet, not a zero-window probe. Whichever. If you look at the 4.3BSD-reno or net2 source, you'll easily be able to figure out which, what, and why. Of course, like any fairly vanillia (at least in that part) 4.3BSD implementation, a keepalive won't be emitted from an SGI IRIS on an established TCP connection until after 2 hours of idle time. Vernon Schryver, vjs@sgi.com
-----------[000174][next][prev][last][first]---------------------------------------------------- Date: Sat, 10 Jul 93 17:11:29 GMT From: woods@robohack.UUCP (Greg A. Woods) To: comp.protocols.tcp-ip,comp.sys.att Subject: Re: TLI
In article <C9nxn5.BG8@rbdc.wsnc.org> royc@rbdc.wsnc.org (Roy Crabtree) writes: > >This is not (entirely) true for a 3B2. RFS is quite reasonable on a > >3B2, esp. over Starlan-10. Socket libraries, to the best of my > > I did no tmentiuon RFS being slow on STARLAN; I did mention > NFS usually outperforming it, speedwise. Although NFS CPU > usage tends to be about 35% higher on a StarServer E 2SMP > (4.0v3.1, TCPiP 4.2.1.2). That's why I specifically mentioned 3B2's. That 35% more CPU means that often NFS cannot outperform RFS on a 3B2, if you look at the total system, that is.... ;-) > RFS is on top of TLI; TLI is on top of STREAMS on 3B2. > > Sockets are on top of STREAM, but not on top of TLI > as best I understand it; what causes the confusion is > that TLI addresses via the protocol family specifications > have a mapping that is 1:1 onto the TCP/IP sockets points; Good point. I have seen libsocket implementations that used TLI calls, but indeed I've no information about the 3B2 (WIN/3B) implementation of sockets, so I should keep my mouth shut. > AGreed; I prefer RFS (but for several strangenesses, like > 'vi' startup running slowly) because I Like to > access remote devices transparently; remsh mach dd of=devname > does not dot it for me; all my experience with 'remsh' > has the sucker dying afdter about 45-60MB traffic. It sounds like the implementation of 'remsh' (rsh) you are using is a wee bit buggy. I've pumped gigabytes through a single rsh connection from a SunOS 4.1.3 to an ISC 386/ix 3.0 machine with an exabyte tape. -- Greg A. Woods woods@robohack.UUCP VE3TCP GAW Cons. & UniForum Canada +1 416 443-1734 [home] Toronto, Ontario; CANADA
-----------[000175][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 1993 20:14:26 GMT From: matt@severian.chi.il.us (Matt Crawford) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: Re: What do people do for load-balancing in IP?
William LeFebvre: > In some ways, a mechanism like this already exists within DNS: it's > called the NS record. ... TGV's Multinet 3.2 has this. Certain terminal domain names are delegated by NS records to a subset of nodes in a vaxcluster, and those nodes chat among themselves to decide in what order to list the A records in response to a query, basing the order on their instantaneous load averages (and relative processing power, I believe). They send the response with a TTL of 5 seconds, if I recall rightly. It's unfortunate that they only work this magic in response to type=A queries and not type=ANY. __________________________________________________________ Matt Crawford matt@severian.chi.il.us Java Man
-----------[000176][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 1993 21:11:07 GMT From: bob@comlab.gtri.gatech.edu (Bob Baggerman) To: comp.protocols.tcp-ip,comp.sources.wanted,comp.sys.sun.misc Subject: Re: Help with writing to /dev/nit (SunOS)
John Bossert writes: >Could someone send me a snippet of code showing how to _write_ to /dev/nit? >This is on a Sparc IPX, running SunOS 4.1.3. Thanks in advance. I wrote a NIT based daemon for my mail notification package I call PCBIFF. Look on "comlab.gtri.gatech.edu", I think in the "/pub/pcbiff" directory. There should be a file called "pcbiffd.c" or something close. I should be a pretty good starting example on sending arbitrary ethenet packets down the wire. Bob -- Bob Baggerman ! bob.baggerman@gtri.gatech.edu Communications Laboratory ! bob@comlab.gtri.gatech.edu Georgia Tech Research Institute ! qseclrb@prism.gatech.edu Atlanta, GA 30332 USA ! 404-894-3525
-----------[000177][next][prev][last][first]---------------------------------------------------- Date: Sat, 10 Jul 1993 21:20:40 GMT From: jim@reptiles.org (Jim Mercer) To: comp.protocols.tcp-ip,comp.protocols.ibm Subject: Re: AS/400 connectivity ?
In article <1993Jul6.101915.18857@aristo.tau.ac.il> dganit@gemini.math.tau.ac.il (Amitay Dganit) writes: >How can we connect AS/400 to Unix workstations ? >Are there any TCP/IP implementations for the IBM AS/400 ? or are there any >gateways that do the trick ? IBM has TCP/IP for the AS/400, it is half decent. it would be better supported if IBM contributed their xterm5250 to the MIT distribution. a couple companies (OpenConnect is one) also sell software and "protocol converters". there are also NFS implementations for the AS/400. -- [ Jim Mercer Reptilian Research merce@iguana.reptiles.org +1 416 506-0654 ] [ fix signs ]
-----------[000178][next][prev][last][first]---------------------------------------------------- Date: Sun, 11 Jul 1993 02:52:01 GMT From: maklinm@cognos.COM (Max Maklin) To: comp.protocols.tcp-ip,comp.protocols.nfs Subject: Re: Tips on alternative to NFS requested.
In article <JIM.93Jul10131602@lister.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) writes: :^() :^() The NFS by Rick Macklem for 4.4 BSD can work over TCP as well as UDP. :^() However, there are very few other NFS implementation (none?) which do :^() this. Commercial suppliers ship NFS running over UDP because that's :^() what everybody else uses. :^() :^() It's true that Sun RPC is independent of the transport protocol (sort :^() of). However NFS is a "special case". The NFS protocol is handled by :^() the kernel and it is heavily interlinked with the UDP code there. :^() Has anyone seen the new NFS protocol (V3, I think) that Sun was supposed to reveal at Connectathon. I have a hunch that they may have found an efficient way to do it over TCP ports. Is this so? -- Max Maklin P.O. Box 9707 Technical Analyst 3755 Riverside Drive Cognos Incorporated Ottawa, Ontario CANADA Internet: maklinm@cognos.COM UUNet: maklinm@cognos.UUCP
-----------[000179][next][prev][last][first]---------------------------------------------------- Date: Sun, 11 Jul 1993 12:51:15 GMT From: souva@aibn55.mpifr-bonn.mpg.de (Ignatios Souvatzis) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.ppp Subject: Re: SLIP vs. PPP: Which is best?
PPP has the disadvantage of 3 bytes relative (to slip) overhead per
frame, 2 of which are a frame level CRC which gives you peace of mind.
And it is much better to configure. If anything goes wrong, you don't
have to guess, but it'll tell you.
For any reasonable implementation (on both sides), performance
differences transmitting IP frames should be neglectable. For non-IP,
PPP has hooks build in to transmit them over the same link... SLIP has
nothing except a framing method.
For more details, read:
ftp.uu.net:vendor/MorningStar/papers/sug91-cheapIP.ps.Z (text) and
sug91-cheapIP.shar.Z (overhead projector slides).
or the frequently wanted information, to be reposted in this group in
32 hours.
i.s.
--
--
Ignatios Souvatzis
Paper mail: Radioastronomisches Institut der Universitaet Bonn,
Auf dem Huegel 71, D-53121 Bonn 1, FRG
Internet: souva@astro.uni-bonn.de or ignatios@cs.uni-bonn.de
Cute quote: "You should also consider that the ST comes fully equipped with a
text adventure. It's called ST Basic." Amylaar@meolyon.hanse.de
''A pencil probably would we called LWD/MO ---
Lead Writing Device/Manual Option. ''
(German computer magazine "c't" 7/93, p.70, about IBM)
-----------[000180][next][prev][last][first]---------------------------------------------------- Date: Sun, 11 Jul 1993 22:32:57 GMT From: rreed@btr.com (Robin Reed) To: comp.protocols.tcp-ip Subject: Software Development Mgr Needed for Start-up Company
Position Overview: Software Development Manager for On-line Information Service Database Development, located in Phoenix Arizona. Start-up company funded by second-largest communications company in the world. Equity participation is significant. Full relocation provided. If you have led a successful development effort through to shipping a commercially successful product in one of these areas, please read on: Database Development Client Server Software Systems Integrated applications (networking software) On-line transaction based system development You know how to get product shipped. The ideal candidate will have delivered multiple complex software products under simultaneous deadlines with limited resources. The individual will be experienced at code reviews, schedule reviews, mid-course corrections, manpower allocation against objectives, and cost containment. He/she will be used to working with small teams, and will have strong previous technical experience to insure that they can thoroughly understand and test the details of product development. This individual has a track record of accurately projecting schedules and holding to deliverables. Ideally, this individual will have worked with UNIX platform/database development (Sybase preferred), integrated applications (dbase, TCP/IP, communications, full text retrieval), Windows and OOP projects. Experience with or knowledge of SGML a major plus. Key requirement is that they understand and thrive in a start-up environment with high stakes. In their background theyÕve successfully pulled products out of the fire and shipped those against deadlines. This person will be a tough minded manager that can drive a development project and make decisions on priorities and the allocation of talent and resources to meet the objectives. Combination of experiences include management of multiple teams in a commercial product development environment, and previous hands-on development/Project Lead expertise on a C based product development team that shipped new product through several releases. At least 10 years of experience, of which 4 most recent years have been in Development Management of a complex software product (system and application level, prefer database) where he/she has managed the aggressive schedules of a start up or new product development effort. The most important requirement is that this individual knows how to get product shipped and can do code reviews. The development work is primarily C, Unix, TCP/IP, Sybase, Sun based. Knowledge of advanced development techniques, process maturity, system and subsystem architectural design, test, QA improvement approaches, and object-oriented dev. and DB are obvious advantages. At the moment, there are 18 people in the engineering/technology group of which 9 are doing hands-on development. The other 9 are performing non-coding development tasks such as human factors, simulation, testing, project management. Compensation: Commensurate with experience (competitive base salary and comprehensive benefits) with the equity participation being the key component to the overall compensation package. Full relocation assistance provided. Next Steps: WeÕre a Technical Recruiting firm and weÕve been hired by this start-up company to manage the recruitment of their engineering management team and primary individual contributors. To learn more, please send a request for more information to this email address: rreed@btr.com, or call direct to Robin Reed at (415) 928-7535 PST or fax to (415) 931-5220. A resume is required. Confidentiality is guaranteed. DonÕt delay if you think you may be interested. Our client wants to make a decision and relocate the person as soon as possible. Thank you for your interest. Robin Reed, Managing Diretor The Reed Group, a management consulting firm retained by advanced software and mobile computing/communications companies since 1984. (415)928-7535 voice, (415) 931-5220 fax.Internet: rreed@btr.com, Applelink: RREED. San Francisco, Seattle, Boston offices.
-----------[000181][next][prev][last][first]---------------------------------------------------- Date: Mon, 12 Jul 1993 04:42:46 GMT From: royc@rbdc.wsnc.org (Roy Crabtree) To: comp.protocols.tcp-ip,comp.sys.att Subject: Re: TLI
In article <1993Jul10.171129.20435@robohack.UUCP> woods@robohack.UUCP (Greg A. Woods) writes: >In article <C9nxn5.BG8@rbdc.wsnc.org> royc@rbdc.wsnc.org (Roy Crabtree) writes: >> >This is not (entirely) true for a 3B2. RFS is quite reasonable on a >> >3B2, esp. over Starlan-10. Socket libraries, to the best of my >> >> I did no tmentiuon RFS being slow on STARLAN; I did mention >> NFS usually outperforming it, speedwise. Although NFS CPU >> usage tends to be about 35% higher on a StarServer E 2SMP >> (4.0v3.1, TCPiP 4.2.1.2). > >That's why I specifically mentioned 3B2's. That 35% more CPU means >that often NFS cannot outperform RFS on a 3B2, if you look at the >total system, that is.... ;-) Chuckle. Since when did a system developer at AT&T actually ever consider total system performance? But you are right. .... > >> RFS is on top of TLI; TLI is on top of STREAMS on 3B2. >> >> Sockets are on top of STREAM, but not on top of TLI >> as best I understand it; what causes the confusion is >> that TLI addresses via the protocol family specifications >> have a mapping that is 1:1 onto the TCP/IP sockets points; > >Good point. I have seen libsocket implementations that used TLI calls, >but indeed I've no information about the 3B2 (WIN/3B) implementation >of sockets, so I should keep my mouth shut. > >> AGreed; I prefer RFS (but for several strangenesses, like >> 'vi' startup running slowly) because I Like to >> access remote devices transparently; remsh mach dd of=devname >> does not dot it for me; all my experience with 'remsh' >> has the sucker dying afdter about 45-60MB traffic. > >It sounds like the implementation of 'remsh' (rsh) you are using is a >wee bit buggy. I've pumped gigabytes through a single rsh connection >from a SunOS 4.1.3 to an ISC 386/ix 3.0 machine with an exabyte tape. Ayah. Every one of them. All from WOllongong ... Albeit the latest fixes of TCP/IP seem to rectify this .... >-- > Greg A. Woods > >woods@robohack.UUCP VE3TCP GAW Cons. & UniForum Canada >+1 416 443-1734 [home] Toronto, Ontario; CANADA royc
-----------[000182][next][prev][last][first]---------------------------------------------------- Date: Mon, 12 Jul 1993 10:36:22 GMT From: chetanm@visionware.co.uk (Chetan Mistry) To: comp.protocols.tcp-ip Subject: Re: KEEPALIVE option for tcp sockets
Jordan Hayes (jordan@IMSI.COM) wrote: : I started the discussion about reading the manual because I wanted to : clarify that the manual pages (not to mention the 4.3 Book) say : *nothing* about getting notified when the KEEPALIVE timer goes off. : Ok, maybe that's a bug or a misfeature. Regardless, It *only* says : that the socket will get marked as invalid and that the *next* time a : read or a write is attempted that it will return an error. : Specifically, I wrote: : In all Unix implementations that I know of, if the keepalive timer : goes off, the socket is marked as invalid, but select() does not : return. How do you detect that the KEEPALIVE timer has "gone off" ? If the socket has been marked as invalid, how do you detect this before doing a read/write operation ? You say that the read/write will fail, but surely it will fail anyway because the connection is broken ! So whats the point in having a KEEPALIVE option if it can't be detected and the software behaves exactly the same whether KEEPALIVE is set or not set ? I'm the person who made the original posting. The man pages I showed were from a SPARC running SunOS 4.1.2 (but the pages are the same on 4.1.3 and a Sun3) and were for setsockopt(). On our SVR4 machines (uname -a says: Unisys 4.0 2 i386 386/AT and 4.0 3.0 486/AT i486) the man pages say that you should receive a SIGPIPE, but this doesn't happen either. Whats happening ? Is this something that just hasn't been implemented, or is the documentation out of date ? Chet
-----------[000183][next][prev][last][first]---------------------------------------------------- Date: Mon, 12 Jul 1993 13:08:54 GMT From: carlson@steam.Xylogics.COM (James Carlson) To: comp.protocols.tcp-ip Subject: Re: Bug in many versions of TCP
In article <1993Jul10.015938.15951@burrhus.harvard.edu>,
ddl@burrhus.harvard.edu (Dan Lanciani) writes:
|> In article <1993Jul9.124753.12821@xylogics.com>,
carlson@steam.Xylogics.COM (James Carlson) writes:
|> | In article <1993Jul9.015552.16180@burrhus.harvard.edu>,
|> | ddl@burrhus.harvard.edu (Dan Lanciani) writes:
|> | |>
|> | |> At this point, we already know that either TH_FIN wasn't set to
begin with
|> | |> or todrop is greater than ti->ti_len. Therefore, TH_FIN can be cleared
|> | |> unconditionally. The first clause of the suggested if()
statement is moot,
|> | |> so the only time this would make a difference is if todrop is
greater than
|> | |> ti->ti_len + 1 with TH_FIN set. That condition would imply a
FIN occupying
|> | |> the sequence number of previously transmitted data, a weird
situation to
|> | |> say the least!
Nuts. I should beware of writing replies on a Friday. Mea culpa.
After rereading the code, I'll agree that this particular relic doesn't
accomplish a whole lot anymore. Perhaps I've been a little too
conservative in my hacking.
I'll change that to omit the offending "if" statement and reset the FIN
bit unconditionally -- just as the original code effectively did.
/*
* States other than LISTEN or SYN_SENT.
* First check that at least some bytes of segment are within
* receive window. If segment begins before rcv_nxt,
* drop leading data (and SYN); if nothing left, just ack.
*/
todrop = tp->rcv_nxt - ti->ti_seq;
if (todrop > 0) {
if (tiflags & TH_SYN) {
tiflags &= ~TH_SYN;
ti->ti_seq++;
if (ti->ti_urp > 1)
ti->ti_urp--;
else
tiflags &= ~TH_URG;
todrop--;
}
if (todrop > ti->ti_len ||
todrop == ti->ti_len && (tiflags&TH_FIN) == 0) {
/*
* Any valid FIN must be to the left of the
* window. At this point, FIN must be a
* duplicate or out-of-sequence, so drop it.
*/
tiflags &= ~TH_FIN;
/*
* Send ACK to resynchronize, and drop any data,
* but keep on processing for RST or ACK.
*/
tp->t_flags |= TF_ACKNOW;
tcpstat.tcps_rcvdupbyte += todrop = ti->ti_len;
tcpstat.tcps_rcvduppack++;
} else {
tcpstat.tcps_rcvpartduppack++;
tcpstat.tcps_rcvpartdupbyte += todrop;
}
m_adj(m, todrop);
ti->ti_seq += todrop;
ti->ti_len -= todrop;
if (ti->ti_urp > todrop)
ti->ti_urp -= todrop;
else {
tiflags &= ~TH_URG;
ti->ti_urp = 0;
}
}
Thanks for the sanity check!
--
James Carlson <carlson@xylogics.com> Tel: +1 617 272 8140
Annex Software Support / Xylogics, Inc. +1 800 225 3317
53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 3159
-----------[000184][next][prev][last][first]---------------------------------------------------- Date: Mon, 12 Jul 1993 13:15:03 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: KEEPALIVE option for tcp sockets
In article <1993Jul12.103622.21194@visionware.co.uk>, chetanm@visionware.co.uk (Chetan Mistry) writes: > Jordan Hayes (jordan@IMSI.COM) wrote: > : I started the discussion about reading the manual because I wanted to > : clarify that the manual pages (not to mention the 4.3 Book) say > : *nothing* about getting notified when the KEEPALIVE timer goes off. > : Ok, maybe that's a bug or a misfeature. Regardless, It *only* says > : that the socket will get marked as invalid and that the *next* time a > : read or a write is attempted that it will return an error. > : Specifically, I wrote: > : In all Unix implementations that I know of, if the keepalive timer > : goes off, the socket is marked as invalid, but select() does not > : return. > > How do you detect that the KEEPALIVE timer has "gone off" ? If the > socket has been marked as invalid, how do you detect this before doing > a read/write operation ? You say that the read/write will fail, but surely > it will fail anyway because the connection is broken ! So whats the > point in having a KEEPALIVE option if it can't be detected and the software > behaves exactly the same whether KEEPALIVE is set or not set ? > > I'm the person who made the original posting. The man pages I showed were > from a SPARC running SunOS 4.1.2 (but the pages are the same on 4.1.3 > and a Sun3) and were for setsockopt(). On our SVR4 machines (uname -a says: > Unisys 4.0 2 i386 386/AT and 4.0 3.0 486/AT i486) the man pages say that > you should receive a SIGPIPE, but this doesn't happen either. > > Whats happening ? Is this something that just hasn't been implemented, > or is the documentation out of date ? > > Chet When you write "[SIGPIPE] doesn't happen either", do you mean it does not happen only on the Unisys PC-AT clone running SVR4 or also on the SPARC running SunOS 4.1.2? What happens if you 1. `rlogin` into the Unisys PC-AT clone. 2. reboot the client machine. 3. wait > 2 hours. 4. check the processes still present on the Unisys PC-AT clone. Does the PC-AT clone notice that the client has disappeared? In other words, does the shell process on the server disappear? If the server notices, then it is likely that Unisys's version of SVR4 does do TCP keepalives. If not, then Unisys's version SVR4 probably does not do TCP keepalives. If this experiment shows that the Unisys SVR4 does do keepalives (I bet it does), but your use of them does fails, then it might be effective to obtain and port the 4.3BSD rlogind.c code from any of the many sources, and see why it works. Vernon Schryver, vjs@sgi.com
-----------[000185][next][prev][last][first]---------------------------------------------------- Date: 12 Jul 1993 16:52:07 GMT From: salzberg@kiwi.imgen.bcm.tmc.edu (Benjamin Salzberg) To: comp.protocols.tcp-ip Subject: compuserve or MCI from internet
hi, how can i send messages to a compuserve address from my internet-based e-mail? is it also possible to MCI Mailbox ? thanks, beni
-----------[000186][next][prev][last][first]---------------------------------------------------- Date: Mon, 12 Jul 1993 16:56:02 GMT From: ba.cgb@RLG.Stanford.EDU (Clif Baker) To: comp.protocols.tcp-ip Subject: Re: compuserve or MCI from internet
In article <21s4rn$sim@gazette.bcm.tmc.edu> salzberg@kiwi.imgen.bcm.tmc.edu (Benjamin Salzberg) writes: >Path: nntp.Stanford.EDU!morrow.stanford.edu!decwrl!decwrl!elroy.jpl.nasa.gov!usc!howland.reston.ans.net!darwin.sura.net!convex!bcm!salzberg >From: salzberg@kiwi.imgen.bcm.tmc.edu (Benjamin Salzberg) >Newsgroups: comp.protocols.tcp-ip >Subject: compuserve or MCI from internet >Date: 12 Jul 1993 16:52:07 GMT >Organization: Molecular Biology Information Resource, Baylor College of Medicine, Houston, Tx >Lines: 13 >Distribution: world >Message-ID: <21s4rn$sim@gazette.bcm.tmc.edu> >NNTP-Posting-Host: kiwi.imgen.bcm.tmc.edu >Originator: salzberg@kiwi.imgen.bcm.tmc.edu > > >hi, > >how can i send messages to a compuserve address from my internet-based >e-mail? > >is it also possible to MCI Mailbox ? > > >thanks, >beni > Beni, In general the e-mail addresses for the two services are: E-MAILID@COMPUSERVE.COM & E-MAILID@MCI.COM Have fun! Clif
-----------[000187][next][prev][last][first]---------------------------------------------------- Date: 12 Jul 1993 17:21:40 GMT From: whalenm@tsg.com (Matthew Whalen) To: comp.protocols.tcp-ip Subject: Re: compuserve or MCI from internet
In article <21s4rn$sim@gazette.bcm.tmc.edu> salzberg@kiwi.imgen.bcm.tmc.edu (Benjamin Salzberg) writes: > > how can i send messages to a compuserve address from my internet-based > e-mail? > > is it also possible to MCI Mailbox ? > > beni To send to compuserve, you send to username@compuserve.com I don't remember how to send to MCI, but I would guess it's somethine like username@mci.com -- -matthew ____ equal rights, not special rights whalenm@tsg.com \ / (NeXTMail OK) \/ Only dead fish swim with the stream. ---------------------------------------------------------------- (My actions/words in no way reflect those of my employer.)
-----------[000188][next][prev][last][first]---------------------------------------------------- Date: Mon, 12 Jul 1993 20:21:35 GMT From: fred_s@netcom.com (Frederick Scott) To: comp.protocols.tcp-ip Subject: Re: compuserve or MCI from internet
salzberg@kiwi.imgen.bcm.tmc.edu (Benjamin Salzberg) writes: >how can i send messages to a compuserve address from my internet-based >e-mail? If you're sending to user 11111,222 on Compuserve, address it: 11111.222@CompuServe.COM >is it also possible to MCI Mailbox ? I don't know, maybe someone else can answer that. Fred
-----------[000189][next][prev][last][first]---------------------------------------------------- Date: 12 Jul 93 20:45:33 GMT From: jordan@IMSI.COM (Jordan Hayes) To: comp.protocols.tcp-ip Subject: Re: KEEPALIVE option for tcp sockets
Chetan Mistry <chetanm@visionware.co.uk> writes: How do you detect that the KEEPALIVE timer has "gone off"? Under SunOS, I try to use the socket in some way in order to generate the error. Typically FIONREAD will do it. Others have reported that Ultrix "fixed" this by actually delivering you a signal. /jordan
-----------[000190][next][prev][last][first]---------------------------------------------------- Date: Mon, 12 Jul 1993 21:19:03 GMT From: emurphy@cs.uno.edu (Edward Murphy) To: comp.protocols.tcp-ip,comp.sys.ibm.pc.hardware Subject: (?) COMPEX ENET32 card and NCSA Telnet
I am having difficulty connecting a PC to our net. The environment is a 486 clone (EISA bus), a Compex ENET32 (32-bit ethernet adapter), and NCSA Telnet 2.3.6. I am hoping that someone has experience with this particular type of setup and can answer a few questions for me. Please reply via e-mail. Regards, Ed Murphy emurphy@cs.uno.edu emcs@uno.edu
-----------[000191][next][prev][last][first]---------------------------------------------------- Date: Mon, 12 Jul 1993 21:40:04 GMT From: moodys@tigger.jvnc.net (Moodys Investors Service) To: comp.protocols.tcp-ip Subject: Re: CSLIP on a SUN
Sorry if this is a FAQ question but I just compiled cslip and I would love to get it running. I dialed into a terminal server, which runs slip, entered the right passwd for my assigned IP @, backgrounded the job, ran slip-attach for the right addresses and tried to ping the terminal server. Of course it told me *network unreachable*. Then how do you establish the route w/o a /etc/hostname.le0 to be listed in the hosts file. I'd be really grateful if you'd fill me in since I'm mystified. Thanks in advance- John van Vlaanderen aka moodys@tigger.jvnc.net
-----------[000192][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 1993 09:22:12 -0700 From: donegan@stanton.wdc.com (Steven P. Donegan) To: comp.protocols.tcp-ip Subject: Kermit 3.13 and TCP/IP
I recently grabbed and installed Kermit 3.13 on a PC. The TCP/IP functions work quite well but the host I'm using is set up for kermit file transfer protocols. Is there some way of using kermit during the telnet session? Thanks for any pointers.
-----------[000193][next][prev][last][first]---------------------------------------------------- Date: Mon, 12 Jul 1993 21:58:28 GMT From: cmclal@lizzie.arh.cdc.com (A. Sudhakarlal) To: comp.protocols.tcp-ip Subject: Re: Would 0xFFFF ever be a TCP checksum? Comments pls.
Thanks a lot for all the responses that came in for my article on TCP checksum. After going through all the responses, I understand that checksumming in TCP/IP protocol suite has not been taken care of cautiously. As we all know that TCP/IP has been more successful in internetworking, it is important that we must have a standard for checksumming which takes into account various hardware platforms and other related issues. Louis Mamakos says that one can get 0xffff as checksum value on 1's complement machine. He says that the ALU on such a machine would never give 0xffff as the result of an arithmetic operation. I want to point out here that only summation is involved in calculating checksum, and it is on "unsigned" values. So one can get 0xffff as the result of an unsigned summation. In that case, checksum would be zero. So one can never get 0xffff as the checksum. I agree that in TCP/IP standards, we should have 0xffff to mean "no checksum", and all other values should be considered as checksum values. Will this work? A. Sudhakarlal ( lal ) email:cmclal@lizzie.arh.cdc.com System software programmer Ph: (612) 483 - 6627 Communications Control Data
-----------[000194][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 1993 01:36:04 GMT From: trier@odin.ins.cwru.edu (Stephen C. Trier) To: comp.protocols.tcp-ip Subject: Re: Is there hardware support for PPP or SLIP to implement the following....
In article <RSI.93Jul12174555@scf16.scf.loral.com> rsi@scf16.scf.loral.com (Rich S. Ishikawa) writes: >What I'm interested in is some hardware product that implements the >mux portion of the above diagram. The "mux" is usuall called a "terminal server". Modern ones handle SLIP and PPP as well as the more traditional ASCII dumb terminals. -- Stephen Trier (trier@ins.cwru.edu - MIME OK) Network Software Engineer IRIS/INS/T Case Western Reserve University
-----------[000195][next][prev][last][first]---------------------------------------------------- Date: Tue, 13 Jul 1993 01:45:55 GMT From: rsi@scf16.scf.loral.com (Rich S. Ishikawa) To: comp.protocols.tcp-ip Subject: Is there hardware support for PPP or SLIP to implement the following....
Hi,
I'd like to know it there is hardware multiplexing support to implement the
following configuration:
______
-------- ------- PPP/WAN |Modem---RS232--PC
|Sun | | |--------------______
|Server| Ethernet/LAN | MUX |-----|
| |----------------------------| |---| | PPP ______
-------- TCP/IP on coax ------- | |-------- Modem---RS232--PC
| PPP ______
|-------- _____
modem---RS232--PC
_____
What I'm interested in is some hardware product that implements the
mux portion of the above diagram. This would be in a form of
Ethernet to PPP supporting multiple serial connections.
Can this be done?? Please email responses!!
What hardware can do it??
Which is recommended??
Much thanks,
-Rich
--
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
-*-*-* Richard S. Ishikawa -*-*-*-*-\ "To be or not to be..." /*-*-*-*-
-*-*-*-* rsi@srs.loral.com -*-*-*-*-*-\ - can't be the question. /*-*-*-*-*-
-*-*-* Loral Space and Range Systems *-*-*-*-* (408)734-6337 *-*-*-*-*-*-*-*-*-
-*-*-*-* 1260 Crossman Ave. Sunnyvale, CA 94089 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
-----------[000196][next][prev][last][first]---------------------------------------------------- Date: Tue, 13 Jul 1993 03:38:15 GMT From: hjb@netcom.com To: comp.protocols.tcp-ip Subject: Re: KEEPALIVE option for tcp sockets
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >If this experiment shows that the Unisys SVR4 does do keepalives (I bet >it does), but your use of them does fails, then it might be effective >to obtain and port the 4.3BSD rlogind.c code from any of the many >sources, and see why it works. i know that it does keepalives. but be aware that this version of tcpip (in various releases) have some mind-blowing hacks thrown into it -- like ridiculously short default keepalive time, and tcp checksums turned off by default in some releases!, and hacked up socket library which is not really fully bsd compatible, and gross hacks to make the loopback go faster, etc., the list goes on... love hwajin -- Hwajin Bae PEACEFUL STAR PROJECT *IX/Realtime/Embedded/Network Consultant Internet: hjb@netcom.com, hjb@hybrid.com, hwajin@wrs.com, hjb@netapp.com Vox: 510.536.7607 / Page: 510.466.9166
-----------[000197][next][prev][last][first]---------------------------------------------------- Date: Tue, 13 Jul 1993 04:19:11 GMT From: eajjs@cbnewsf.cb.att.com (john.sottile) To: comp.protocols.tcp-ip Subject: Re: Is there hardware support for PPP or SLIP to implement the following....
In article <RSI.93Jul12174555@scf16.scf.loral.com> rsi@scf16.scf.loral.com (Rich S. Ishikawa) writes: > > ______ > -------- ------- PPP/WAN |Modem---RS232--PC > |Sun | | |--------------______ > |Server| Ethernet/LAN | MUX |-----| > | |----------------------------| |---| | PPP ______ > -------- TCP/IP on coax ------- | |-------- Modem---RS232--PC > | PPP ______ > |-------- _____ > modem---RS232--PC > _____ > > The Telebit NetBlazer does exactly this. It supports up to 26 Serial ports (I have the "old" version which does up to 26 ports). I have the original Netblazer in a 2 port configuration and have set it up using both SLIP and PPP on demand. It even supports several PPP or SLIP connections to the same place and spreads the load. In the old 2 port configuration (2 8550 Serial Ports -- lots of interrupts), I was able to get 7KBytes/Second with very flat data (ASCII). With Compressed files using rcp, I saw 2.7 KBytes/s. I used it with NFS for a long time and saw good numbers once I tuned the NFS timeo and rsize/wsize stuff. They had a DIGIBoard 8 which allows for 8 Ports locked at 56KBps and I presume that I would have gseen slightly better numbers. The New Versions just came out and although I haven't seen it yet, I can expect top notch stuff as before. Oh, BTW, they have this modemcap file which allows you to add modems not described in the "generic" configuration. I understand that 2 Companies have demonstrated V.Fast Capabilities in a modem (28.8K plus data compression -- up to 115Kbps). I saw a demonstration on the Paradyne and have read about the Comdex. Both are proprietary until V.Fast is standarized (end of this year or sometime early next year, perhaps). If you get a configuration which has something like the New NetBlazer, Digi-8 Cards locked at 115Kbps and in parallel, I bet you would see some impressive numbers. I've also run X Traffic over it too. All in all a good product. I Think Telebit's 800 number is 1-800-TELEBIT. ============================= John Sottile "That Guy has to Oil his Brakes!" AT&T Bell Labs #include <std/disclaimer/who-me?.h> jjs@cblph.att.com My comments are mine and not AT&T's.
-----------[000198][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 1993 10:15:14 +0100 From: cudep@csv.warwick.ac.uk (Ian Dickinson) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: Re: What do people do for load-balancing in IP?
In article <21mfm2$m0f@usenet.ins.cwru.edu>, trier@odin.ins.cwru.edu (Stephen C. Trier) writes: >In article <1993Jul9.212742.1341@atlastele.com> sameer@atlastele.com writes: >>Also, what about load balancing between two hosts connected by a dual >>dial-up SLIP lines. How would that work. >>In case one line goes down the traffic shifts to the other line. Any ideas ? >That's a routing issue. Any routing algorithm can cope with the >fallback from one line to another. The Internet would hardly work were >that not the case! True. >Sharing load while both lines are up is a more difficult problem, but I >think Cisco advertise that their routers can do it. This being the main point of the question. So, if Cisco can do it - is is a proprietary workaround?? How do you do it if both ends of the line happen to be, say, Suns? An arbitrary external process plugged into named for certain addresses, would allow complicated behaviour without client changes, and would be very extendible. It could cope with the above situation, load balancing, and policy based return values pretty easily - especially if the program provided named with the equivalent of a $INCLUDE'd file with TTLs which can then have other defaults substituted within it and sent on to the client that queried. >Followups to comp.protocols.tcp-ip. And back again to comp.protocols.tcp-ip.domains since I don't think you got *ALL* the answer. Cheers, -- \/ato - Ian Dickinson - NIC handle: ID17 This article is dedicated to vato@csv.warwick.ac.uk ...!uknet!warwick!vato those who disapprove but /I=I/S=Dickinson/OU=CSV/O=Warwick/PRMD=UK.AC/ADMD= /C=GB/ continue to @c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson read
-----------[000199][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 1993 12:03:31 GMT From: welander@i4.informatik.rwth-aachen.de (Bjoern Welander) To: comp.protocols.tcp-ip Subject: More on Unexplainable Measurement Figures ?!
Hi ! Thanks for all your answers to my previous mail. I recieved a whole lot of answers asking for more elucidation. I would therefor like to repeat my earlier question and add some clearifying information. As I wrote before we are doing performance measurements with TCP and XTP, using SUN Sparc-2 workstations connected to an Ethernet. When we load the CPU:s on both SUN:s with 15 background processes we get some rather peculiar measurement results. The background processes do not send anything on the net. They are just simple C-programs counting from zero to 100.000 an infinite number of times. Here follows a sample measurement. It is made with XTP, but we find similar results also with TCP. No. 1 delay: 5.61 s throughput: 5700 Kbit/s No. 2 delay: 5.62 s throughput: 5696 Kbit/s No. 3 delay: 5.61 s throughput: 5703 Kbit/s No. 4 delay: 20.64 s throughput: 1551 Kbit/s No. 5 delay: 5.62 s throughput: 5698 Kbit/s No. 6 delay: 5.63 s throughput: 5689 Kbit/s No. 7 delay: 5.63 s throughput: 5689 Kbit/s No 8 delay: 5.65 s throughput: 5668 Kbit/s N. 9 delay: 12.19 s throughput: 2626 Kbit/s No. 10 delay: 23.81 s throughput: 1344 Kbit/s No. 11 delay: 5.63 s throughput: 5683 Kbit/s No. 12 delay: 5.64 s throughput: 5677 Kbit/s No. 13 delay: 5.63 s throughput: 5681 Kbit/s No. 14 delay: 5.62 s throughput: 5695 Kbit/s No. 15 delay: 5.64 s throughput: 5669 Kbit/s No. 16 delay: 10.85 s throughput: 2959 Kbit/s No. 17 delay: 5.69 s throughput: 5619 Kbit/s No. 18 delay: 5.65 s throughput: 5668 Kbit/s No. 19 delay: 5.62 s throughput: 5692 Kbit/s No. 20 delay: 5.62 s throughput: 5692 Kbit/s No. 21 delay: 5.64 s throughput: 5679 Kbit/s No. 22 delay: 5.64 s throughput: 5678 Kbit/s No. 23 delay: 8.24 s throughput: 3883 Kbit/s No. 24 delay: 5.60 s throughput: 5712 Kbit/s No. 25 delay: 5.61 s throughput: 5703 Kbit/s rate: 512.000 bytes/s burst: 14.560 bytes/burst window size: 21.504 bytes background network load: 0 % background CPU load: 15 processes It seems as if the mean delay should be somewhere between 5.6 and 5.7 seconds. But totaly randomly these up to four or five times bigger values appear without any reasonable explaination. Note that these higher values don«t appear when there are no background processes. My question is simply; can anybody explain these strange values? For the measurements we are using the ttcp respective txtp tools. Every transmission is 4 Mbyte of data. The workstations are situated in the same building on two different Ethernets, connected through a third Ethernet. The Ethernets are connected with each other with bridges. Our best guess so far is that it has something to do with the UNIX operating system. Since it isn«t a real-time OS variations could be expected, but reasonably not this high. All good (and bad) explainations (and guesses) are warmly welcome Bjoern Welander :-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-: : Bjoern Welander Institute of Computer Science IV : : Aachen University of Technology : : : : welander@i4.informatik.rwth-aachen.de : : : : HA EN TREVLIG DAG ! : :-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:
-----------[000200][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 93 13:03:32 GMT From: devdjn@space.alcbel.be (Dennis Newport) To: comp.protocols.tcp-ip Subject: Re: More on Unexplainable Measurement Figures ?
We have done similar measurements between SPARC IIs, IPCs and HP 9000/827s. We only used TCP and made the measurements with our own test programs (all software written in Ada because it's an ESA project). We used message sizes of 1, 50, 100, 128, 1023, 1024, 1025, 4095, 4096 4097, 8K, 16K and 20K to transmit 4MB (I think). But we never saw this type of anomalous behaviour. We also set off background processes (upto 10) and still no strangeness. I'd like to give you our figures but I can't say too much because they belong to ESA. I can say that in a multi-tasking Ada environment with no appreciable network or CPU load on SPARC IIs we managed around 2.5-3 Mb/s (steady state) for 4KB messages and this fell to 900 Kb/s when we used our traffic generator to put 50% load on our Ethernet LAN and put an extra 10 CPU intensive processes on the machines. Sorry we can't be of more help. --- Dennis Newport, email: devdjn@space.alcbel.be Alcatel Bell Telephone, Berkenrodelei 33, phone: (+32) 3/829.5488 2660 Hoboken, Belgium. Ha en det sa bra (inte ratt stavning - ingen Svensk bokstaver pa datorn).
-----------[000201][next][prev][last][first]---------------------------------------------------- Date: Tue, 13 Jul 1993 14:16:31 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: More on Unexplainable Measurement Figures ?!
In article <welander-130793140134@freitag.informatik.rwth-aachen.de>, welander@i4.informatik.rwth-aachen.de (Bjoern Welander) writes: > ... > As I wrote before we are doing performance measurements with TCP and XTP, > using SUN Sparc-2 workstations connected to an Ethernet. When we load the > CPU:s on both SUN:s with 15 background processes we get some rather > peculiar measurement results. > ... > No. 1 delay: 5.61 s throughput: 5700 Kbit/s > ... > No. 4 delay: 20.64 s throughput: 1551 Kbit/s > No. 5 delay: 5.62 s throughput: 5698 Kbit/s > ... > rate: 512.000 bytes/s > burst: 14.560 bytes/burst > window size: 21.504 bytes > background network load: 0 % > background CPU load: 15 processes > It seems as if the mean delay should be somewhere between 5.6 and 5.7 > seconds. But totaly randomly these up to four or five times bigger values > appear without any reasonable explaination. Note that these higher values > don«t appear when there are no background processes. My question is simply; > can anybody explain these strange values? > > For the measurements we are using the ttcp respective txtp tools. Every > transmission is 4 Mbyte of data. The workstations are situated in the same > building on two different Ethernets, connected through a third Ethernet. > The Ethernets are connected with each other with bridges. > > Our best guess so far is that it has something to do with the UNIX > operating system. Since it isn«t a real-time OS variations could be > expected, but reasonably not this high. Do the background process run continuously from the start of the first test until the end of the last? Without being restarted? How does their CPU priority vary? Does the kernel you are using occassionally give higher priority to jobs that have not had a chance to run for a long time? (`ps` can often be used to discover processes' CPU priority.) What happens if you modify your background processes to print or log their progress, say announce every 1,000,000th iteration? Do you see a similar variation in iterations/second? What are you trying to simulate? Do you really expect your systems to have a load average higher than 15 when you are using TCP or XTP for whatever you intend? Why are your TCP numbers so low? Why are you getting only 500KB/sec in the good times? Vernon Schryver, vjs@sgi.com
-----------[000202][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 93 14:49:01 GMT From: mills@athena.lkg.dec.com (George Mills) To: comp.protocols.tcp-ip,comp.protocols.nfs Subject: Re: Tips on alternative to NFS requested.
jim@cs.strath.ac.uk (Jim Reid) writes: >In article <1993Jul9.075843.3569@ericsson.se> etxmesa@eos.ericsson.se (Michael Salmon) writes: > Basically I need a more secure remote file system and a simpler one, > the first requirement is the more important. It should also not consume > very much processor time and be supported by every Unix system. You might consider DEC-Athena for the PC (in pilot stage now). It offers significant increases in security with out compromising speed or compatability. and a many other benifits as well. Send mail to pc_pilot@athen.tay.dec.com for more information.
-----------[000203][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 93 15:12:25 GMT From: ICH211@DJUKFA11.BITNET (Thomas Heil) To: comp.protocols.tcp-ip Subject: LPR protocol documentation
Hello!
Does someone know if there is ftp'able documentation on the LPR protocol
somewhere (something beyond RFC1179)? I have some questions that this RFC
cannot answer.
1. What is the way to get multiple copies of a document? Do I have to send
the file several times, or is there a control file option that is not in
the RFC?
2. What is the file type to use for printing raw printer data (data that has
to get to the printer without being further filtered)? "v" or "f" or "l"?
Maybe someone can shed some light. Please reply to me directly.
/Thomas
---------------------------------------+--------------------------------------
Mail: Thomas Heil | EMail: BITNET: ICH211@DJUKFA11.BITNET
Forschungszentrum Juelich - ICG2 | Internet: th.heil@kfa-juelich.de
D-5170 Juelich | Phone: +49 2461 61-6915
Germany | Fax: +49 2461 61-5346
-----------[000204][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 93 15:42:05 GMT From: trt@duke.cs.duke.edu (Tom Truscott) To: comp.protocols.tcp-ip Subject: Re: Would 0xFFFF ever be a TCP checksum? Comments pls.
>I agree that in TCP/IP standards, we should have 0xffff to mean "no checksum", >and all other values should be considered as checksum values. Will this work? If you are asking "is it okay for us to implement a TCP/IP product with the roles of 0 and 0xffff reversed?" then the answer is NO! A thousand times NO! The checksum rules in rfc1122 are fairly clear IP checksums and TCP checksums are always present, and MUST be checked. Line 4646 tells us that a 0 in the UDP checksum field means "no checksum". Line 4590 tells us that a non-0 UDP checksum MUST be checked. From line 4620 we can infer that, for IP and TCP, 0 and 0xffff may be used interchangeably. ===== If you are asking "wouldn't it be better if 0xffff had mean't no checksum" then I would say yes. But as Louis Mamakos pointed out, having 0 mean "no checksum" made good sense on the ones complement machines that were popular on the ARPAnet back in the old days. And in any event this is a trivial efficiency issue compared with e.g. getting rid of checksums entirely :-) ===== Vaguely related, and in a desperate attempt to change the subject... One thing that is worrying me these days is that the future of computing is looking little-endian. x86 is little-endian. DOS and Windows (including NT) and OS/2 are little-endian. Most RISC chips are now bi-endian, for compatibility with the above. If five years from now the industry has settled on little-endian, won't the TCP/IP "network order" look like a terrible mistake? Tom Truscott
-----------[000205][next][prev][last][first]---------------------------------------------------- Date: Tue, 13 Jul 1993 15:46:40 GMT From: dwight@hyphen.com (Dwight Ernest) To: comp.protocols.tcp-ip Subject: FAX via TCP/IP?
Hi. I'm interested in finding out what other sites might be using to get FAX functionality working through TCP/IP circuits. We have TCP/IP connectivity between two of our main company sites (soon to be more), and since it's gone online, I've gotten a flood of inquiries from a very wide variety of people, from bean-counters to programmers, about whether it would be possible to use that circuit to connect FAX machines on each end. What are other people doing for this? I've glanced through RFC809, but it seems pretty dated.
-----------[000206][next][prev][last][first]---------------------------------------------------- Date: Tue, 13 Jul 1993 17:38:48 GMT From: ag129@ucs.cam.ac.uk To: comp.protocols.tcp-ip Subject: Re: LPR protocol documentation
In article <93194.171425ICH211@DJUKFA11.BITNET> ICH211@DJUKFA11.BITNET (Thomas Heil) writes: >1. What is the way to get multiple copies of a document? Do I have to send > the file several times, or is there a control file option that is not in > the RFC? Every line in the control file that starts with a lower-case letter causes the file to be printed out. You just need more than one of them. >2. What is the file type to use for printing raw printer data (data that has > to get to the printer without being further filtered)? "v" or "f" or "l"? Use 'v'. Both 'f' and 'l' refer to text, which even if control chars are passed through, is likely to be subject to ASCII-EBCDIC conversion, have its line feeds turned into record boundaries etc. In fact it is less than a week since someone crashed our LPD/NJE gateway by sending binary data to it using an 'l' code. -- Alasdair Grant, England
-----------[000207][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 1993 18:34:57 GMT From: vijay@hicomb.hi.com (P.A. Vijayakumar) To: comp.sources.wanted,comp.protocols.tcp-ip Subject: TCP/IP performance evaluation programs
I am looking for TCP/IP performance evaluation programs on UNIX using sockets. I am currently using netperf which is pretty good but I am also interested in looking at others (if any). If anyone out there knows of any other programs, please let me know. Thanks in advance. Vijay (vijay@hicomb.hi.com)
-----------[000208][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 1993 19:06:11 GMT From: roy@mchip00.med.nyu.edu (Roy Smith) To: comp.protocols.tcp-ip Subject: Re: compuserve or MCI from internet
ba.cgb@RLG.Stanford.EDU (Clif Baker) writes: >In general the e-mail addresses for the two services are: > >E-MAILID@COMPUSERVE.COM & E-MAILID@MCI.COM At least for Compuserve, you also have to change the "," in the E-MAILID part to a ".". -- Roy Smith <roy@nyu.edu> Hippocrates Project, Department of Microbiology, Coles 202 NYU School of Medicine, 550 First Avenue, New York, NY 10016 "This never happened to Bart Simpson."
-----------[000209][next][prev][last][first]---------------------------------------------------- Date: Tue, 13 Jul 93 19:37:04 GMT From: heiser@TDWR.ED.RAY.COM (Bill Heiser) To: comp.protocols.tcp-ip Subject: IP Filtering for SunOS 4.X
Please accept my apologies if this (comp.protocols.tcp-ip) isn't the right newsgroup for this post. DEC Ultrix has a program called "screend" which acts as an IP filter, allowing a DECstation to be used, say, as a FIREWALL between two networks. I am interested in a comparable program for use on a SunOS 4.1 system. Is there such a thing? If so, where might I find it. Thanks in advance, Bill -- Bill Heiser Business: heiser@TDWR.ED.RAY.COM Unix Workstation System Manager Personal: heiser@world.std.com
-----------[000210][next][prev][last][first]---------------------------------------------------- Date: Tue, 13 Jul 1993 20:33:22 GMT From: Steinar.Haug@runit.sintef.no (Steinar Haug) To: comp.protocols.tcp-ip Subject: Any site with comp.protocols.tcp-ip archives available for anonymous FTP?
I need to dig into some old comp.protocols.tcp-ip postings. Are there any archive sites available? I didn't find any with archie. Steinar Haug, system/networks administrator SINTEF RUNIT, University of Trondheim, NORWAY Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no
-----------[000211][next][prev][last][first]---------------------------------------------------- Date: Tue, 13 Jul 1993 20:57:52 GMT From: Steinar.Haug@runit.sintef.no (Steinar Haug) To: comp.protocols.tcp-ip,comp.sys.hp Subject: tcpdump is now available for HP-UX, but requires extra STREAMS software
tcpdump is now available for HP-UX on the 700 and 800 series systems. This is
something I've been wanting for quite a while, and I found out about it more
or less by accident... this is the posting with the announcement:
----------------------------------------------------------------------
From: librarian@iworks.ecn.uiowa.edu (InterWorks librarian)
Subject: InterWorks software library (update #21)
Date: Tue, 13 Jul 1993 03:05:52 GMT
The following is a list of new (or updated) entries (since my last posting),
of UX-related software on the InterWorks library node (iworks.ecn.uiowa.edu--
128.255.18.10). Note that everything is available via anonymous ftp-- in
"comp.hp"). The README there contains a complete list of the available
software.
...
128965 tcpdump.tar.Z
HP-UX (unofficial) tool to dump identified headers of
network packets. Suitable for PA-RISC 9.x systems only.
Version 2.2.1.
----------------------------------------------------------------------
I retrieved the package, and found that it contained the following README:
----------------------------------------------------------------------
This is revision 2.2.1 of tcpdump, modified to work on HP-UX. For tcpdump
to work, your system must be running HP-UX 9.0 (S800) or 9.01 (S700) and
have the STREAMS/DLPI product installed. It must also have either patch
PHNE_2666 or PHNE_2665 installed (one is 700, the other 800).
On HP-UX, tcpdump MUST NOT be setuid root. It should only be run by root,
to do otherwise is to ensure a panic - YOU HAVE BEEN WARNED!-) Just in
case this was not clear - this programs should ONLY be run by root.
This program should NOT be chmoded to be setuid root and then run by
normal users.
I have not tested this software on anything other than the Series 700. I
am told that it "should" work on the Series 800 (at least those systems
with the half-height NIO (lan3) interface. It certainly will not run on
the 68K systems. This is a PA-RISC1.1 shared executable dynamically linked.
This is at the *FARTHEST* edges of the UNSUPPORTED spectrum. At some
point, after being blessed by the original authors, I am sure that the
source changes will be distributed via the normal Internet means.
This g-job would not be possible without the gracious assistance of
Warren Burnett and other members of the HP IND LAN Drivers project,
who provided me with example code for DLPI.
enjoy,
rick jones
----------------------------------------------------------------------
So, tcpdump for HP-UX is here, finally - but unfortunately it requires an
unbundled STREAMS product.
HP is to be congratulated on making tcpdump available. Now if we could
only have it *without* needing to an extra piece of software, like we can
with Sun and DEC workstations for instance :-)
Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no
-----------[000212][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 1993 22:28:40 GMT From: Pearce Turpin <lanshark@llnl.gov> To: comp.protocols.tcp-ip Subject: TCP/IP - Novell - WAN from HELL!
I will buy dinner for the person who solves this one. 5 LAN's connected via a T1 WAN with a UNIX host on one of the LAN's. We have a proprietary app that needs Racal/Interlan NP600 'smart' NIC's running their own version of FTP's PC/TCP designed for the NP600. The routers are Netware 3.11-based with 3C509 LAN NIC's and Novell's Multi-protocol Router boards on the WAN side. Our addresses are all class 'C'. We have no subnets. Everything works fine, except when we try to use the NP600 based PC's. I cannot ping anything outside my own net. I can ping the NIC on the LAN side of the router, because it's on the same net. Now, if I use LWP ODI drivers, everything works perfectly. The same with FTP's PC/TCP ver 2.2 and the UNIX host. The only thing that dosn't work is the PC's with the NP600. I'm assuming either: a. The router is not seeing packets sent by that particular board for what ever reason. or b. The boards are not compatible with SOMETHING, even though I've isolated everything and they work locally. I think it's (a), but I can't, for the life of me, figure out why. The server is set up to receive any size packet, and everything else wroks just fine. Any of all input appreciated, and I'm serious about the dinner.......
-----------[000213][next][prev][last][first]---------------------------------------------------- Date: Tue, 13 Jul 1993 23:18:16 GMT From: fred_s@netcom.com (Frederick Scott) To: comp.protocols.tcp-ip Subject: Re: TCP/IP - Novell - WAN from HELL!
Pearce Turpin <lanshark@llnl.gov> writes: >I will buy dinner for the person who solves this one. 5 LAN's connected >via a T1 WAN with a UNIX host on one of the LAN's. We have a proprietary >app that needs Racal/Interlan NP600 'smart' NIC's running their own >version of FTP's PC/TCP designed for the NP600. The routers are Netware >3.11-based with 3C509 LAN NIC's and Novell's Multi-protocol Router boards >on the WAN side. Our addresses are all class 'C'. We have no subnets. >Everything works fine, except when we try to use the NP600 based PC's. I >cannot ping anything outside my own net. I can ping the NIC on the LAN >side of the router, because it's on the same net. Now, if I use LWP ODI >drivers, everything works perfectly. The same with FTP's PC/TCP ver 2.2 >and the UNIX host. The only thing that dosn't work is the PC's with the >NP600. I'm assuming either: > >a. The router is not seeing packets sent by that particular board for >what ever reason. >or >b. The boards are not compatible with SOMETHING, even though I've >isolated everything >and they work locally. > >I think it's (a), but I can't, for the life of me, figure out why. The >server is set up to receive any size packet, and everything else wroks >just fine. > >Any of all input appreciated, and I'm serious about the dinner....... By "pinging", I assume you mean they won't do *anything* with a peer outside of their own net, e.g. ftp, telnet, etc. There's a DIFFERENCE, ya know... (If it were just ping problems, the difficulties might be limited to icmp packets or something weird like that.) The simplest explanation would be that the special FTP software is having some sort of problem finding the default router. I suspect you may not have configured the address of the Netware router in correctly - or if you have, that the special FTP software is just not working right. Naturally, it would be interesting to hook up a network analyzer and see what network activity took place when you attempted to ping something outside the net. From what you described, I would expect to see (in the following order of preference): 1) No activity at all - as the FTP software recognizes that it has to route the packets but doesn't know where to. 2) An arp broadcast for the IP address of the peer on the remote network. or 3) An arp broadcast for the Novell router - in which case I'm wrong and something completely different is the problem. (Becuase this would be the correct behavior, so far.) Fred
-----------[000214][next][prev][last][first]---------------------------------------------------- Date: 14 Jul 93 00:51:27 GMT From: mayshah@gandalf.rutgers.edu (Mayank Shah) To: comp.protocols.tcp-ip Subject: Extended Error message
Hi Folks, I am testing IBM's TCP/IP v 2.2?(2.1) and NFS. I am mounting unix drive on to a ps/2, and I am facing some problems. I hope that someone can help me. IF you can please e-mail them to me. Drive J is mounted for the unix station. so I type :dir /s (to get a long) directory list. It will start displaying the dir, then at one point it will stop and say :Extended Error 51: Does anyone know what this means, what causes this and how do i fix this. Problem, 2: When running applications from the server, root or someone else is the owner, under windows I get a message "Access Denined, ...". So, I copied Winfile on to the server (so I was the owner), now the message I get is "Insufficent memory to run that appliation). I have 8mb or RAM./ I hope someone can reply, Thankx in advance. Mayank -- ------------------------------------------------------------------------------ Mayank Shah Rutgers University mayshah@gandalf.rutgers.edu
-----------[000215][next][prev][last][first]---------------------------------------------------- Date: 14 Jul 93 05:40:08 GMT From: catone@compstat.wharton.upenn.edu (Tony Catone) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: NFS or other fileserver protocols
In article <C9qvqJ.FIA@fs7.ece.cmu.edu> loss@fs7.ECE.CMU.EDU (Doug Loss) writes:
I'm posting this because I think it's of general interest. SOS is a
public domain NFS server program for MS-DOS. The PC that SOS is running
on is dedicated, and can't be used as a user node while it's exporting
its filesystem to other machines.
Actually, the product's name is SOSS. You'll find a version with a
few bug fixes I made locally at
hilbert.wharton.upenn.edu:pub/tcpip/soss.zip.
- Tony
catone@compstat.wharton.upenn.edu
-----------[000216][next][prev][last][first]---------------------------------------------------- Date: 14 Jul 1993 17:54:40 -0500 From: karl@genesis.MCS.COM (Karl Denninger) To: comp.protocols.tcp-ip Subject: Re: What's the better way to administer IP addresses to dorms?
In article <136021@netnews.upenn.edu> tony@scotty.dccs.upenn.edu (Anthony Olejnik) writes: >This september, the first phase of our student dorm wiring >(to the campus IP/AppleTalk network) will be completed. > >As such, we're looking for the better (best, ideally) way >to administer/assign IP addresses. > >Should we: > -statically assign them (one per network outlet) > -statically assign them but use BOOTP > -manually assign them (on an 'as-requested; basisc_ > -etc. > >*ANY* help/comments would be *GREATLY* appreciated. >Thanks in advance. For this kind of situation I would probably do two things: 1) Implement a "anonymous IP bootp" extension which would assign an address from a random pool (after trying to "arp" it to see if its already in use) and return that. This works well for people with MACs and PCs that don't have persistent connections (ie: they want to telnet or FTP out, but don't care about incoming connections) I can't imagine that this kind of extension to bootpd would take more than a day to implement and test. 2) Allow registration of MAC level addresses for permanent IP assignment for those people running something like (or equivalent to) Unix, who want inbound connections to their machine to be possible. -- Karl Denninger (karl@genesis.MCS.COM) | You can never please everyone except Modem Access: [+1 312 248-0900] | by bankrupting yourself. Voice & FAX: [+1 312 248-8649] | Internet in Chicago; a MCSNET first!
-----------[000217][next][prev][last][first]---------------------------------------------------- Date: 14 Jul 93 16:47:30 MDT From: jrd@cc.usu.edu (Joe Doupnik) To: comp.protocols.tcp-ip Subject: Re: Kermit 3.13 and TCP/IP
In article <donegan.742580430@stanton.wdc.com>, donegan@stanton.wdc.com (Steven P. Donegan) writes: > I recently grabbed and installed Kermit 3.13 on a PC. The TCP/IP functions > work quite well but the host I'm using is set up for kermit file transfer > protocols. Is there some way of using kermit during the telnet session? > > Thanks for any pointers. ------------ Steven, Pardon for me looking puzzled, but have you gone ahead and done the Kermit to Kermit file transfers over Telnet? MS-DOS Kermit works very well that way (please scan the release docs again for hints: no flow control, long packets, two or more window slots). If your host is running C Kermit 5A then setup CK the same way. The full story is in the user's manual, the book "Using MS-DOS Kermit" by Christine Gianone, 2nd edition, Digital Press and Prentice Hall, about ~$35. Joe D.
-----------[000218][next][prev][last][first]---------------------------------------------------- Date: 14 Jul 1993 12:43:39 GMT From: fgs@kepler.unh.edu ( F r e D S l a m A ) To: comp.unix.questions,comp.unix.programmer,comp.protocols.tcp-ip Subject: Port allocation below 1024 for users
Is it possible to allocate a port below 1024 without having to be
root? I realize that this question is odd and it is a matter of
security that disallows port allocation below this number
for users. Nonetheless, is there a way (without modifying the kernel).
Thank you,
-Fred
--
===============================================================================
Frederick G. Slama at >>>>>>>>>>>>>| slama@ctron.com
The University of New Hampshire <<<| fgs@kepler.unh.edu F_SLAMA@unhh.unh.edu
===============================================================================
-----------[000219][next][prev][last][first]---------------------------------------------------- Date: Wed, 14 Jul 1993 12:57:21 GMT From: rg@camb-lads.loral.com (Roger Gonzalez) To: comp.protocols.tcp-ip Subject: UDP Performance Testing
I need to test the UDP performance (send, receive, and latency) on several different architectures. I whipped out some programs that provided what seemed like unreasonably fast numbers. I suspect this was due to me actually measuring nonuseful things like how long it takes for a process to wake up out of a sleeping select(). I could keep tweaking my programs, (and I would love some insight on what I should do to them) but I would prefer to use something already written. Thanks! -- -Roger Roger Gonzalez Loral Advanced Distributed Simulation rg@camb-lads.loral.com 50 Moulton Street, MS 3/A home (508) 465-3170 Cambridge, MA 02138 mobile (508) 641-0539 work (617) 873-4286 fax -4315
-----------[000220][next][prev][last][first]---------------------------------------------------- Date: 14 Jul 1993 13:54:44 GMT From: kbw@helios.ath.epa.gov (Kevin B. Weinrich) To: comp.protocols.tcp-ip,comp.unix.admin,comp.sun.admin Subject: SUMMARY: Sniffer programs
None of the recommended solutions really do the highly-specialized
task I wanted done, namely, to find out about the avg. ack. time
for a bunch of packets that all make up one file being transmitted.
But evidently a lot of folks are interested in simpler packet-capture
programs. So, here are the programs I know about. The messages
that brought them to my attention follow.
(My personal favorites:)
In space.mit.edu:/pub/netman you can find the following precompiled
binaries:
etherman.tar.Z
interman.tar.Z
packetman.tar.Z and
hershey-sun4c.tar.Z (hershey fonts needed for display of above)
I personally love etherman for showing me who's talking with who
on my net. Lots of other goodies. Interman is neat, but very
fragile. Packetman does its job, but other packages (Tcpview) do it better.
No source available on these, and neither I nor others have been
able to get ahold of the boys from Down Under at Curtin Univ. who
wrote them up, so no support is available.
(See following messages for explanations of the following)
Tcpview and NNstat are available for UNIX boxes. Ask Archie for
locations. Gobbler is for PCs. Packetview and Netscope are low-cost
commercial solutions, both of which have free demo versions
available.
====================================================================
From: "Steve Alpert" <sra%idx.com@sadye.EMBA.UVM.EDU>
Rumor has it that on the simtel archives is a pd network analyzer. I've
wondered about it myself but only have e-mail access to internet and don't
have the patience to send an ftpmailer after it.
I recall seeing it mentioned in an Ad for a CD cut for SIMTEL that
included the VAX stuff. I suspect this means that it isn't in the tree rooted
at pd1:<msdos...> but more likely pd1:<misc...> or some such. Sorry I don't
have the name or more to go on. Perhaps a note to Keith Peterson (keeper of
MISC) is in order...
====================================================================
From: gls@cirrus.com (Gary L. Schaps)
TCPVIEW - An Interactive Motif-Based Protocol Analyzer
This archive contains the source to tcpview and an enhanced tcpdump 2.2.1.
The two programs share much of the same source code.
Tcpview is the result of several problems we had at UW. We have several
Network General Sniffers which are heavily used to help debug problems on
several hundred subnets. These are good tools, but they are 1) heavy,
2) hard to find when you need one, 3) limited in their software expandibility,
4) difficult to use to upload data for analysis, 5) cannot be remotely
operated, and 6) cannot resolve names with DNS, requiring much manual
manipulation of the name table. We also sometimes use tcpdump, but we found
it 1) too difficult for most people, 2) did not have enough information for
many protocols, 3) could not be used interactively, 4) could not handle
TCP streams and 5) could not read Sniffer files. However, tcpdump did do
a reasonable job of decoding a large number of protocols, and had superior
filtering to the Sniffer. Tcpview is an attempt to resolve these problems
by adding a Motif interface to tcpdump and expanding its features.
Tcpview has been tested on a DECstation 5000 and Sun 4 under Ultrix 4.2 and
SunOS 4.1 respectively. It should work on the same systems as tcpdump.
It compiles with cc and gcc on the DEC and Sun. To build tcpview you will
need Motif 1.1 or better.
What tcpview adds to tcpdump:
- easier interface
- enhanced protocol decoding
- hex display of frame
- capture based on time, number of frames, or user interrupt
- can show ethernet addresses with manufacturer's name
- ethernet address host table
- can easily follow a stream, highlighting out-of-order frames
- can send TCP data to an external file or filter for additional
processing.
-------------------------------------------------------------------------------
CHANGES TO TCPDUMP 2.2.1
New features:
Now reads and writes Network General Sniffer files. When used with '-r', the
file type will be automatically detected.
Can now read in (and use) an SNMP MIB file.
The hex format has been changed.
New time options have been added.
Options were added to allow viewing and processing of the data in TCP packets.
Bugs were fixed in the relative TCP sequence numbers. (-S flag)
New flags:
-R read Sniffer file. Not usually needed, except for reading from stdin
-ttt prints delta times
-tttt prints times relative to the first frame
-W write a Sniffer save file (use with -w)
-x print frame (minus link-level header) in hexdump format.
Sample output:
16:36:23.349851 jeff.cac.washington.edu.1285 > nic.funet.fi.ftp: S 0:0(0) win 16384
0000 45 00 00 28 8a 98 00 00 3c 06 7c 9c 80 5f 70 02 | E..(....<.|.._p.
0010 80 d6 06 64 05 05 00 15 5b 19 4a 00 00 00 00 00 | ...d....[.J.....
0020 50 02 40 00 4e 13 00 00 00 00 00 00 00 00 | P.@.N.........
-X print TCP data in hexdump format (used with -Z)
-z write TCP data to stdout (use with -t to eliminate timestamp)
-Z write frames and TCP data to stdout
FUTURE ENHANCEMENTS:
New and better detailed protocol decoders need to be written. I'm
only planning to add those as we need them here at UW. I'm hoping
others will find this tool useful enough to help out with enhancing
the protocol support. I'm planning on expanding the visualization
options to include graphical representations of protocol traces. I'm
also interested in adding in some intelligent protocol analysis. How
far I get in this depends on the level of interest in it and how much time
I have available.
Please send me any bug reports you have. Also suggestions are always
welcome. If you do write any new protocol decoders or add any enhancements,
let me know and I will include them in the next release.
Martin M. Hunt
martinh@cac.washington.edu
University of Washington
/*
*
* Copyright 1992 by the University of Washington
*
* Permission to use, copy, modify, and distribute this software and its
* documentation for any purpose and without fee is hereby granted, provided
* that the above copyright notice appears in all copies and that both the
* above copyright notice and this permission notice appear in supporting
* documentation, and that the name of the University of Washington not be
* used in advertising or publicity pertaining to distribution of the software
* without specific, written prior permission. This software is made
* available "as is", and
* THE UNIVERSITY OF WASHINGTON DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
* WITH REGARD TO THIS SOFTWARE, INCLUDING WITHOUT LIMITATION ALL IMPLIED
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, AND IN
* NO EVENT SHALL THE UNIVERSITY OF WASHINGTON BE LIABLE FOR ANY SPECIAL,
* INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
* LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, TORT
* (INCLUDING NEGLIGENCE) OR STRICT LIABILITY, ARISING OUT OF OR IN CONNECTION
* WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*
*/
====================================================================
From: jdl@cip250.corp.harris.com (John Little)
To: kbw@helios.ath.epa.gov
Subject: network
Content-Length: 204
Status: RO
X-Lines: 5
I think NNStat is the best packet capture and sort program I have seen. It
allows you to capture just about anything that travels across your network.
Available via anonymous FTP, just use archie.
John
====================================================================
From: cruoho@nyx.cs.du.edu (Clint Ruoho)
If nobody has pointed you to gobbler yet, let me recommend that to you.
It is a freely available and distributable ethernet sniffer, does tcp/ip
other files, and a number of other files.
It can be found at
ftp.uu.net:/systems/ibmpc/msdos/wattcp/delft/gobbler.zip
If you need a package for Suns, you can look at etherfind or tcpdump, but
they're pretty yucky packages if you want to capture packets and look at
them in anything except hex.
====================================================================
From: klos@mv.MV.COM (Patrick Klos)
Organization: Klos Technologies, Inc.
Although this doesn't quite fit your description, you might be interested in
knowing about our product, PacketView, which is a low-cost PC-based protocol
analyzer. It doesn't do statistics, but it's GREAT at packet capture. It
can decode TCP/IP packets, including UDP and SNMP. It does other protocols
also, but you indicated a specific need for TCP/IP only. It costs $249.00
and you can check out a demo version by downloading it from our BBS at
(603) 429-0032 (if you're interested).
====================================================================
- Rick Thau
Though not public domain, you may want to download a demo of NetScope
from the mailserver below. It will run on your Sun workstation, and
provide the capabilities of the Sniffer, as you requested.
---
- Rick Thau
voice: 415/572-0200
fax: 415/572-1300
email: rthau@qualix.com
mail: Qualix Group, Inc
1900 S. Norfolk St., #224
San Mateo, CA 94403
--------------------------------------------------------------
Qualix maintains a mailserver with information files and demo
versions of products. If you would like more information on
the mailserver, send an email to qfacts@qualix.com (or,
uunet!qualix!qfacts). The email body should take the following
form:
BEGIN
send help
send index
END
Name, company or affiliation
Address
Phone
--------------------------------------------------------------
--
Kevin Weinrich Computer Sciences Corp.
kbw@helios.ath.epa.gov
-----------[000221][next][prev][last][first]---------------------------------------------------- Date: Wed, 14 Jul 1993 14:33:05 GMT From: barnett@grymoire.crd.ge.com (Bruce Barnett) To: comp.protocols.tcp-ip Subject: System Tuning
I am interested in "rules" that can be used to characterize system and
network problems. I have some papers from Sun on NFS tuning, but
I am also interested in non-NFS tuning.
For instance, "netstat -s" returns 70-85 lines of information.
Which lines of information indicate a problem, and what are
the possible fixes?
I realize that values may have completely different meanings
depending on the purpose of the system. Still, I am interested in any
rules - even if for specific cases....
Some brief examples----
On a gateway:
tcp:
599422 packets received
4314 completely duplicate packets (1091342 bytes)
1227 packets with some dup. data (47696 bytes duped)
14930 out-of-order packets (6545338 bytes)
5308 retransmit timeouts
3 connections dropped by rexmit timeout
On another machine:
ip:
2161667 total packets received
18557 fragments received
0 bad header checksums
0 fragments dropped (dup or out of space)
88 fragments dropped after timeout
107713 packets not forwardable
There are many more possible errors. I wish I understood all of the
values - and what causes them, but I don't.
It would be a great service if these tidbits of information were
available somewhere. I'll volunteer to collect them, and will post a
summary.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett
-----------[000222][next][prev][last][first]---------------------------------------------------- Date: 14 Jul 1993 14:53:12 GMT From: Pearce Turpin <lanshark@llnl.gov> To: comp.protocols.tcp-ip Subject: Re: TCP/IP - Novell - WAN from HELL!
Subject: Re: TCP/IP - Novell - WAN from HELL! We now have a LANanyzer going, and noted activity locally, with a few checksum errors. I'm really not sure why we would get those errors or what would cause them; I'm relatively new to the TCP/IP arena, though I know Netware well. I WANT to think that there is something wrong with the way the card's TCP/IP is working, because everthing else works great. I mean, wouldn't all TCP/IP packets bomb if there were a problem with the router? hmmm.
-----------[000223][next][prev][last][first]---------------------------------------------------- Date: Wed, 14 Jul 1993 15:57:58 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: UDP Performance Testing
In article <RG.93Jul14085721@adams.camb-lads.loral.com>, rg@camb-lads.loral.com (Roger Gonzalez) writes: > > I need to test the UDP performance (send, receive, and latency) on several > different architectures. I whipped out some programs that provided what > seemed like unreasonably fast numbers. I suspect this was due to me actually > measuring nonuseful things like how long it takes for a process to wake up out > of a sleeping select(). I could keep tweaking my programs, (and I would love > some insight on what I should do to them) but I would prefer to use something > already written. There is always the pack of common TCP/IP benchmarks, including netperf, ttcp, and nettest, source for all of which can be found on sgi.com. UDP tests often yield ridiculously high numbers on the sender, because the common BSD code discards UDP packets that overflow the driver output queue. You do get an ENOBUFS, and if you do as ttcp does and delay an arbitrary, small time, you can tune your sender to overflow the output queue only occassionally. UDP tests often yield ridiculously low numbers on the receiver, if the sender and medium are much faster than the receiver. At the extreme (which I have seen), the receiver effectively receives only a single UDP packet, because the receiver gets so swamped processing input interrupts and so forth that it suffers so many input overflows that it ends up with only the first IP fragment of the first UDP packet and the IP fragments of the last UDP packet. People are strange. I once had an major Ethernet board vendor try to convince me that their VME board was really great because their UDP benchmark had been able to write about 15Mbit/sec to the board. They were either too dumb to notice the ENOBUFS or thought I was too dumb to be able to convert Bytes/sec to bits/sec, or (probably) both. Vernon Schryver, vjs@sgi.com
-----------[000224][next][prev][last][first]---------------------------------------------------- Date: Wed, 14 Jul 1993 16:56:15 GMT From: fred_s@netcom.com (Frederick Scott) To: comp.protocols.tcp-ip Subject: Re: TCP/IP - Novell - WAN from HELL!
Pearce Turpin <lanshark@llnl.gov> writes: >We now have a LANanyzer going, and noted activity locally, with a few >checksum errors. I'm really not sure why we would get those errors or >what would cause them; I'm relatively new to the TCP/IP arena, though I >know Netware well. The useful test is to set up the LANalyzer to filter all but packets going to and from the NP600 card. You do this by selecting the filter option (F6, I believe) when the cursor is on one of the active channel's fields while in the edit display. Once in the filter display, move the curser first to one ethernet address field, type in the NP600's address, than to the arrow and hit the minus key until a "<----->" pops up (as opposed to a "<----" or a "---->". Make sure the other ethernet address has all X's in it. That will filter all but packets going to or from the NP600's ethernet address. >I WANT to think that there is something wrong with the way the card's >TCP/IP is working, because everthing else works great. I mean, wouldn't >all TCP/IP packets bomb if there were a problem with the router? hmmm. No, I didn't say the problem was with the router itself. I said it might be with the special FTP TCP/IP software version for the NP600. It has to know the IP address of the default router or it (alone of all the devices on that net) will not be able to interact with devices outside of the net - which I believe is exactly the situtation you're describing. You may not have configured it correctly or perhaps you did but the software is not working correctly, for some reason. Fred
-----------[000225][next][prev][last][first]---------------------------------------------------- Date: 14 Jul 1993 18:50:14 GMT From: kbw@helios.ath.epa.gov (Kevin B. Weinrich) To: comp.protocols.tcp-ip,comp.unix.admin,comp.sun.admin Subject: Re: SUMMARY: Sniffer programs
It seems space.mit.edu has gotten rid of their copies of etherman, et al. Here's a place that works as of 930714 14:44 EST ( ;-) pprg.eece.unm.edu:/pub/X -- Kevin Weinrich Computer Sciences Corp. kbw@helios.ath.epa.gov
-----------[000226][next][prev][last][first]---------------------------------------------------- Date: 14 Jul 93 21:27:04 GMT From: tony@scotty.dccs.upenn.edu (Anthony Olejnik) To: comp.protocols.tcp-ip Subject: What's the better way to administer IP addresses to dorms?
This september, the first phase of our student dorm wiring (to the campus IP/AppleTalk network) will be completed. As such, we're looking for the better (best, ideally) way to administer/assign IP addresses. Should we: -statically assign them (one per network outlet) -statically assign them but use BOOTP -manually assign them (on an 'as-requested; basisc_ -etc. *ANY* help/comments would be *GREATLY* appreciated. Thanks in advance. --tony
-----------[000227][next][prev][last][first]---------------------------------------------------- Date: 14 Jul 93 21:32:10 GMT From: sparker@oscar.UUCP (Sean Parker) To: comp.protocols.tcp-ip Subject: Best Modems for Slip and PPP
We are in the process of upgrading our modems here. Currently we are looking into 14.4K modems. My question is what modems in this range that people have used/evaluated using slip and/or PPP to unix machines running a variety of X-applications. Basically I would like to know which modems would be best suited for this environment. Could you e-mail responses to: sparker@hns.com Thanks! Sean
-----------[000228][next][prev][last][first]---------------------------------------------------- Date: 14 Jul 1993 21:41:45 GMT From: kumar@sloop.cis.ufl.edu (SHASHANK KUMAR) To: comp.dcom.lans.ethernet,comp.protocols.tcp-ip,comp.realtime,comp.sys.ibm.pc.hardware,comp.protocols.tcp-ip.ibmpc,comp.windows.x,comp.windows.x.apps,comp.windows.x.i386unix Subject: TCP/IP & Windows 3.1
Greetings Everyone,
I suppose Microsoft has recently released TCP/IP 4 WINDOWS ($50). I am not sure
if its for WFW or Windows 3.1. But I got this news from credible source that it
can be used for running Xwindows applications at remote site using a Third Party
software like WinQVT. Let me put the exact words,
" X-server running over a Windows Sockets TCP/IP transport (which
also supports WinQVT/Net and other TCP/IP applications)."
I would appreciate if someone who is actually using it, would enlighten me. I
would like to open multiple windows as I do right now for 'rlogin' using WinQVT.
Is it possible to run Xwindows applications in these windows by just
specifying the environment by the IP address (128.227.84.123:0.0) i.e.,
display terminal and address (iota fanciful). I have the experience of using
Desqview/X which I found notably competent for this purpose, but its Windows
support wasn't that immaculate.
Please send email:
kumar@coconut.cis.ufl.edu
/ Ever notice that even the busiest people are never /
/ too busy to tell you just how busy they are. /
-----------[000229][next][prev][last][first]---------------------------------------------------- Date: 14 Jul 93 23:17:05 GMT From: randy@psg.com (Randy Bush) To: comp.protocols.tcp-ip Subject: Re: What's the better way to administer IP addresses to dorms?
karl@genesis.MCS.COM (Karl Denninger) writes: >> This september, the first phase of our student dorm wiring >> (to the campus IP/AppleTalk network) will be completed. > 1) Implement a "anonymous IP bootp" extension which would assign an > address from a random pool (after trying to "arp" it to see if its > already in use) and return that. This works well for people with > MACs and PCs that don't have persistent connections (ie: they want > to telnet or FTP out, but don't care about incoming connections) > I can't imagine that this kind of extension to bootpd would take > more than a day to implement and test. Given the first derivative of security incidents, I might favor more sticky and hence trackable IP address assignments. -- randy@psg.com ...!uunet!m2xenix!randy
-----------[000230][next][prev][last][first]---------------------------------------------------- Date: 14 Jul 1993 23:59:09 GMT From: trier@odin.ins.cwru.edu (Stephen C. Trier) To: comp.protocols.tcp-ip Subject: Re: What's the better way to administer IP addresses to dorms?
If you want your users get the most out of their computers, you must
have a permanent IP address per machine. There are many reasons to do
this:
- Greater accountability
- Simplified debugging
- Wider software compatibility
- Hosts can act as servers as well as clients.
The last is perhaps the most important feature. We have students
contacting each others machines directly all the time to transfer
files, chat online, or whatever.
If you want your PCs used solely as terminals, use dynamic assignment.
It will definitely reduce the paperwork involved! On the other hand,
if you want the PCs to function as computers in their own right, give
them static addresses.
One definition: by "static address", I mean that the address doesn't
change across reboots. This doesn't preclude use of BOOTP. In fact,
BOOTP will really reduce the configuration headaches involved, since it
means all of your users can run identical, turnkey software.
Stephen
--
Stephen Trier (trier@ins.cwru.edu - MIME OK)
Network Software Engineer
IRIS/INS/T
Case Western Reserve University
-----------[000231][next][prev][last][first]---------------------------------------------------- Date: Thu, 15 Jul 1993 00:45:35 GMT From: fred_s@netcom.com (Frederick Scott) To: comp.protocols.tcp-ip Subject: Re: What's the better way to administer IP addresses to dorms?
karl@genesis.MCS.COM (Karl Denninger) writes: >In article <136021@netnews.upenn.edu> tony@scotty.dccs.upenn.edu (Anthony Olejnik) writes: >>This september, the first phase of our student dorm wiring >>(to the campus IP/AppleTalk network) will be completed. >> >>As such, we're looking for the better (best, ideally) way >For this kind of situation I would probably do two things: > >1) Implement a "anonymous IP bootp" extension which would assign an > address from a random pool (after trying to "arp" it to see if its > already in use) and return that. This works well for people with > MACs and PCs that don't have persistent connections (ie: they want > to telnet or FTP out, but don't care about incoming connections) > I can't imagine that this kind of extension to bootpd would take > more than a day to implement and test. Not unless you really LIKE trouble. What if a student unplugs his PC and then plugs it back in later, with rebooting? (Or is running an application which is making it impossible or very slow to respond to an arp.) What if the IP address assigner doesn't see the response - icmp packets aren't guaranteed delivery, ya know. An interesting though but too, too many flaws and the potential for problems just isn't worth it. You don't want PCs running around your net spoofing other PCs. Fred
-----------[000232][next][prev][last][first]---------------------------------------------------- Date: Thu, 15 Jul 1993 02:39:07 GMT From: kleung@netcom.com (Kenneth Leung) To: comp.protocols.tcp-ip Subject: Re: AS/400 connectivity ?
Connecting Unix workstation to AS/400 can be done with the following :
AS/400 based TCP/IP is available, check with IBM rep
SNA connectivity for Unix from vendors such as Cleo, System Strategies
and Rabbit Software
Use a DOS box in between with AS/400 PC Support+TCP/IP
Anyone got anything suggestions?
Kenneth C.P. Leung 1303 Walnut Hill Ln. 2nd Floor, Irving, TX 75038
Information Specialist Voice : 214-550-8371 Fax : 214-550-9269
Innovax Concepts Corp. AURORA Supermarket Application
Innovax Integration Partner Program
--
Kenneth C.P. Leung 1303 Walnut Hill Ln. 2nd Floor, Irving, TX 75038
Information Specialist Voice : 214-550-8371 Fax : 214-550-9269
Innovax Concepts Corp. AURORA Supermarket Application
Innovax Integration Partner Program
-----------[000233][next][prev][last][first]---------------------------------------------------- Date: Thu, 15 Jul 1993 02:49:17 GMT From: scott@zmax.com (Scott Wallace) To: comp.protocols.tcp-ip,comp.unix.aix Subject: Sigpipe on AIX blocked socket read
Greetings Netters, Sorry if this is a faq, but I'm stuck on this one. I have a socket-based server which blocks on a read on a socket under AIX 3.2 on a RS6000/320. A client frequently sends data packets to this server, but should the client die (network crash or whatever) I need the server to know about this and exit. (it's forked from an accept). Currently, if the client dies, the server see's nothing. The blocked read on the socket doesn't return -1, and also, a SIGPIPE is not generated to the server process. I've tried messing with setsockopt with SO_KEEPALIVE etc... with no success. Does anyone have any idea how to get around this? (P.S. The exact same code works on DEC). Please email responses since I don't regularly get this group. Thanks in advance, Scott scott@zmax.com Z/Max Computer Solutions Inc. Baldwinsville NY 13027
-----------[000234][next][prev][last][first]---------------------------------------------------- Date: Thu, 15 Jul 1993 05:06:55 GMT From: aidan@vast.unsw.edu.au (aidan) To: comp.protocols.tcp-ip,comp.unix.admin,comp.sun.admin Subject: netman etc.. (Was: Re: SUMMARY: Sniffer programs)
kbw@helios.ath.epa.gov (Kevin B. Weinrich) writes:
: It seems space.mit.edu has gotten rid of their copies of etherman, et al.
: Here's a place that works as of 930714 14:44 EST ( ;-)
: pprg.eece.unm.edu:/pub/X
:
: --
: Kevin Weinrich Computer Sciences Corp.
: kbw@helios.ath.epa.gov
Here is a copy of the original posting which gives you the official
distribution site.
regards
aidan
____
:wq! aidan@cse.unsw.edu.au OR aidan@vast.unsw.edu.au
---README----------------------------------------------------------------------
Network monitoring and visualisation tools 13th April 1993
netman@cs.curtin.edu.au
Overview:
We have developed a set of tools (3) which may be used to monitor and
"display" network communications. Two of the tools provide a real-time
picture of network communications, while the other provides retrospective
packet analysis. These tools are designed to allow network managers to
passively monitor a network and diagnose common network problems as quickly
and efficiently as possible.
The tools:
Etherman is an X11 based tool which displays a representation of real-time
Ethernet communications. Network data is promiscously received via a system
"network tap" and summarised into useful statistics. These statistics are
displayed in a graphical manner, as to allow both experienced network managers
and newbies an insight as to how a network is being used. Etherman will also
provide protocol summaries, usage statistics and postscript(tm) snapshots of
network activity.
Interman focusses on IP connectivity within a single segment. As with
Etherman, this tool allows a real-time representation of network communications
to be displayed. Interman employs the same methods of network data
capture as Etherman, except only IP traffic is considered. Since IP is a
network-level protocol, Interman will display multiple networks - both local
and remote. Protocol summaries, usage statistics and postscript snapshots
are also available.
Packetman is a retrospective Ethernet packet analyser. This tool allows
the capture and analysis of an Ethernet packet trace.
Availability:
At present, only binaries for SUN Sparc (SunOS 4.1.x) and DEC-mips
(Ultrix 4.2a and above) are avaliable. Each tool must be run as root.
ftp.cs.curtin.edu.au:
~ftp/pub/netman/[sun4c|dec-mips]/[etherman|interman|packetman].tar.Z
You will also need:
~ftp/pub/netman/hershey-[sun4c|dec-mips].tar.Z
--
Mike Schulze, Craig Farrell and George Benko.
Department of Computer Science
Curtin University
Perth, West Australia
-----------[000235][next][prev][last][first]---------------------------------------------------- Date: Thu, 15 Jul 1993 10:42:42 From: djmiller@newsserver.tasc.com (Dean J. Miller) To: comp.protocols.tcp-ip Subject: Re: TCP/IP - Novell - WAN from HELL!
In article <21vcuo$si7@lll-winken.llnl.gov> Pearce Turpin <lanshark@llnl.gov> writes: >>I will buy dinner for the person who solves this one. 5 LAN's connected >>via a T1 WAN with a UNIX host on one of the LAN's. We have a proprietary >>app that needs Racal/Interlan NP600 'smart' NIC's running their own >>version of FTP's PC/TCP designed for the NP600. The routers are Netware >>3.11-based with 3C509 LAN NIC's and Novell's Multi-protocol Router boards >>on the WAN side. Our addresses are all class 'C'. We have no subnets. >>Everything works fine, except when we try to use the NP600 based PC's. I >>cannot ping anything outside my own net. I can ping the NIC on the LAN >>side of the router, because it's on the same net. Now, if I use LWP ODI >>drivers, everything works perfectly. The same with FTP's PC/TCP ver 2.2 >>and the UNIX host. The only thing that dosn't work is the PC's with the >>NP600. I'm assuming either: >> >>a. The router is not seeing packets sent by that particular board for >>what ever reason. >>or >>b. The boards are not compatible with SOMETHING, even though I've >>isolated everything >>and they work locally. >> >>I think it's (a), but I can't, for the life of me, figure out why. The >>server is set up to receive any size packet, and everything else wroks >>just fine. >> >>Any of all input appreciated, and I'm serious about the dinner....... This may be a long shot, but have you tried swapping out the 3C509 boards on your Novell Router (or at least the one that is on the same ethernet segment as the NP-600s) with a non-3Com board? We have had anomalous behavior in the past with PCs using 3Com cards that has been unexplainable. -- dean ==================== Dean J. Miller TASC (617)942-2000 x2769 djmiller@tasc.com
-----------[000236][next][prev][last][first]---------------------------------------------------- Date: 15 Jul 93 11:45:58 GMT From: rens@stimpys.imsi.com (Rens Troost) To: comp.protocols.tcp-ip Subject: Re: KEEPALIVE option for tcp sockets
Slightly off the thread, but to the point, here's how to change the
keepalive timeout (on a sun, or in fact any 4.3 derivative)
timeout value = timeout_in_seconds * PR_SLOWHZ (from sys/protosw.h, usually 2)
adb -w -k /vmunix /dev/mem << EOF
tcp_keepidle?W {timeout value}
EOF
reboot
And, alas, select will not return unaided. Use jordan's method.
-Rens
--
o===============================================================o
| J. Laurens Troost - UNIX Systems | At Work: rens@imsi.com |
| Investment Management Svcs, Inc. | At Play: rens@century.com |
| 12 East 49th Street, 35th floor | Phone: (212) 339-2823 |
| New York, New York 10017 | Fax: (212) 339-2854 |
o===============================================================o
-- IMS is unlikely to share any of the above opinions --
-----------[000237][next][prev][last][first]---------------------------------------------------- Date: 15 Jul 93 17:21:33 From: shirono@ssd.csd.harris.com (Roberto Shironoshita) To: comp.protocols.tcp-ip Subject: Need info on terminal servers
We are currently contemplating the purchase of a TCP/IP terminal server to
be used as incoming server for high-speed dialup lines.
The server we have in mind is the PortMaster2 Communications Server, from
Livingston Enterprises, Inc.
Any comments on these servers (or any others) would be appreciated,
especially as far as their security capabilities. The blurb we have from
Livingston says that their servers do dialback, have local passwords,
provide packet and access filters, and implement an authentication
protocol. The authentication server source, the blurb says, is made
available without use restrictions.
Please reply by email. If there is interest, I will post a summary of any
responses I receive. If there is some other newsgroup where this article
would be better sent, please let me know.
Thank you.
--
Roberto Shironoshita || Internet: shirono@ssd.csd.harris.com
Harris Corporation ||
Computer Systems Division || UUCP: ...!uunet!ssd.csd.harris.com!shirono
||
DISCLAIMER: The opinions expressed here are my own; they in no way reflect the
opinion or policies of Harris Corporation.
-----------[000238][next][prev][last][first]---------------------------------------------------- Date: 15 Jul 1993 13:08:10 GMT From: nprobert@fires1.uucp (Neal Probert) To: comp.protocols.tcp-ip Subject: Looking for Ethernet, Tcp/Ip, SNMP tools for UNIX ?
I am looking for PD UNIX tools for sniffing and analyzing networks. This
includes Ethernet, tcp/ip, SNMP and NFS. What are the names of these
packages and where can I find them. (I can use archie to find them).
Thanks.
--
-------------------------------------------------------------------------------
FORD | Neal W. Probert E3154 SRL | nprobert@fires1.srl.ford.com
SCIENTIFIC | Ford Scientific Research Labs | 313-845-8178 FAX 313-845-8202
RESEARCH LABS | Dearborn, MI 48121-2053 | Disclaimer: I'm innocent!
-----------[000239][next][prev][last][first]---------------------------------------------------- Date: 15 Jul 1993 14:12:46 GMT From: roy@mchip00.med.nyu.edu (Roy Smith) To: comp.protocols.tcp-ip Subject: Re: What's the better way to administer IP addresses to dorms?
I admittedly have limited experience with this kind of stuff, but in the one situation where I ran a dynamically allocated IP address pool, it was a bunch of localtalk Macs behind a FastPath. The theory is that a pool will allow you to reduce the number of address you have to allocate. In practice, however, I found that most people tended to keep some IP application up all the time (usually email), so I ended up having to allocate about as many addresses as we had machines anyway. -- Roy Smith <roy@nyu.edu> Hippocrates Project, Department of Microbiology, Coles 202 NYU School of Medicine, 550 First Avenue, New York, NY 10016 "This never happened to Bart Simpson."
-----------[000240][next][prev][last][first]---------------------------------------------------- Date: 15 Jul 1993 15:09:27 GMT From: Pearce Turpin <lanshark@llnl.gov> To: comp.protocols.tcp-ip Subject: Re: TCP/IP - Novell - WAN from HELL!
Re: TCP/IP - Novell - WAN from HELL! LANalyzer results: Can I get an interpretation? Test1 - Capture packets from initial PING to router LAN card with LWP ODI drivers (theses work on the card): an ARP packet, followed by the ICMP, then the returning ICMP. Test 2 - Now I use the drivers that come with the board (the ones that DON'T work): I get an ICMP FOLLOWED by an ARP, then the returning ICMP. Is this an indicator of the problem?? I heard the another site has been able to duplicate the problem with a different router, but that has yet to be confirmed. Pearce Turpin (w) lanshark@llnl.gov (h) lanshark@bohunk.win.net
-----------[000241][next][prev][last][first]---------------------------------------------------- Date: Thu, 15 Jul 1993 17:56:07 GMT From: tozz@hpindda.cup.hp.com (Bob Tausworthe) To: comp.protocols.tcp-ip Subject: Portable SNMP & TCP/IP for 8051
I have a friend at a local telecomm company who is looking for a portable version of SNMP and TCP/IP for an 8051 controller. This implementation would be communicating over a serial line. Since it is an 8051 it will in all likelyhood need to be ROM-able. Please send all correspondence to: sftcom@infoserv.com BTW - they are willing to pay! for the code. tozz@cup.hp.com
-----------[000242][next][prev][last][first]---------------------------------------------------- Date: 15 Jul 93 19:24:29 GMT From: karthik@informix.com (Karthikeyan Guruswamy) To: comp.protocols.tcp-ip Subject: Re: TCP/IP - Novell - WAN from HELL!
In article <21vcuo$si7@lll-winken.llnl.gov> lanshark@llnl.gov (Pearce Turpin) writes:
>I will buy dinner for the person who solves this one. 5 LAN's connected
>via a T1 WAN with a UNIX host on one of the LAN's. We have a proprietary
>app that needs Racal/Interlan NP600 'smart' NIC's running their own
>version of FTP's PC/TCP designed for the NP600. The routers are Netware
>3.11-based with 3C509 LAN NIC's and Novell's Multi-protocol Router boards
>on the WAN side. Our addresses are all class 'C'. We have no subnets.
>Everything works fine, except when we try to use the NP600 based PC's. I
>cannot ping anything outside my own net. I can ping the NIC on the LAN
>side of the router, because it's on the same net. Now, if I use LWP ODI
>drivers, everything works perfectly. The same with FTP's PC/TCP ver 2.2
>and the UNIX host. The only thing that dosn't work is the PC's with the
>NP600. I'm assuming either:
>
>a. The router is not seeing packets sent by that particular board for
>what ever reason.
>or
>b. The boards are not compatible with SOMETHING, even though I've
>isolated everything
>and they work locally.
>
>I think it's (a), but I can't, for the life of me, figure out why. The
>server is set up to receive any size packet, and everything else wroks
>just fine.
>
>Any of all input appreciated, and I'm serious about the dinner.......
First things first - What Frame Type are you using in the NP-600 PC ?
Karthik
P.S: I like Pan Fried Pizza with extra cheese, mushrooms and pineapple
;-y
---------------------------------------------------------------
Karthik
Infosoft Inc, (Contractor to INFORMIX Inc.)
Cupertino, CA
' Its not how FAR you go, but how GO you far ... '
All the views expressed here are solely mine and they dont
represent those of my organization.
---------------------------------------------------------------
-----------[000243][next][prev][last][first]---------------------------------------------------- Date: Thu, 15 Jul 1993 19:44:51 GMT From: mgic <mgic@mixcom.mixcom.com> To: comp.protocols.tcp-ip Subject: Mysterious RPC failure.
I am having a strange problem with an RPC client that sometimes fails on the clnt_call() call. It fails with a return code of 4 which is RPC_CANTRECV (RPC client unable to receive result). All the RPC server does is generate a postscript document from a text file, convert it to fax format, and fax it out. This involves a couple of system calls which all return successfully. Would a SIGCLD in the server somehow cause this behavior? This happens on a Sun Sparcstation 10. The rpc code was generated via rpcgen. Any pointers will be greatly appreciated. Thanks Anand Prahlad mgic@mixcom.com --
-----------[000244][next][prev][last][first]---------------------------------------------------- Date: 15 Jul 93 19:50:18 GMT From: matt@calico.math.binghamton.edu (Matt Brin) To: comp.protocols.tcp-ip,comp.sys.sun.admin,comp.unix.admin,comp.unix.wizards Subject: glacial file transfers
This is a copy of a post that I put out before. I have a little more information. It is quite bizzare. Start of former post. We are having trouble transfering files. We are a subnet in a university with a sun acting as a gateway to the rest of the university. We recently split our subnet into two and added a bit to our netmask on our side of the gateway. Thus we have a second gateway into our inner part of our lan. Eerything works fine (e.g., reading net news, which is done through our gateway). We have our interfaces configured correctly and everything seems to be able to communicate with everything else. rlogin, ping, mail, and so forth work just fine. EXCEPT: some file transfers that either originate from or go through our outer gateway (the old one) come to almost a halt after about 20 or 30 kilobytes have been transfered. This happens with ftp, rcp and tftp. There are no network storms going on. Watching etherfind shows nothing suspicious except a marked lack of activity regarding the file transfers. Sometimes if you wait long enough, an extra packet or two gets through. The word "some" adds to the puzzle. A file transfer from within our lan to within a lan elsewhere on campus goes fine. This transfer involves two gateways - one on each lan. A file transfer from within the second part of our lan (three gateways involved) bogs down after some 10s of kilobytes. A transfer from the main net on campus to the first part of our lan (only one gateway involved) bogs down. All of these transfers use our main gateway. A transfer from our gateway to within the outer part of our lan (direct transfer on our ethernet - no routing at all) bogs down. Any hints wil be apreciated. End of former post. I now have more information that I cannot account for in any way. I have run snoop on a third machine while running the transfer between two machines that bog down. After the transfer is initiated, packets flow between the machines at about 10 per hundreth of a second. This included repeated packets (many are repeated once - a few twice). After about a tenth of a second, there is a one second delay, then a two second delay, then a four second delay, then (you guessed it) an eight second delay, then 16, then 32 (I am not making this up), then 64, then a packet goes out evey 64 seconds. This went on for about 5 more transmissions before I killed the process. _____________________________________________________________________________ matt brin / math. dept / SUNY / Binghamton, NY 13902-6000 / (607)-777-2147 matt@math.binghamton.edu INTERNET mbrin@bingvaxa BITNET -----------------------------------------------------------------------------
-----------[000245][next][prev][last][first]---------------------------------------------------- Date: Thu, 15 Jul 1993 20:28:39 GMT From: maass@orchis.enet.dec.com (Joerg Maass) To: comp.protocols.tcp-ip,comp.networks.noctools.wanted Subject: Re: Request for tools/test suites for IP routers
In article <C9v5Gv.9xv@apollo.hp.com>, tmm@apollo.HP.COM (Thomas M. Mistretta) writes: Could anyone recommend any tools or suites to test and validate the operation of an IP router? Specifically, we would like to examine fragmentation, IP option handling, ICMP, etc., in addition to various routing protocols like RIP, OSPF, and HELLO. Realistically - at a minimum - we would like to see testing of the guidelines set forth in RFC-1009: "Requirements for Internet Gateways." Any response would be appreciated. Thanks. Tom Mistretta tmm@apollo.hp.com -- How about HP OpenView? As far as I know, it is specialized on TCP/IP networks (SNMP) and should be capable of providing such information (as far as it is retrievable from the router or end system). If not, send me a mail :-). Cheers Joerg Maass Network Management Specialist Digital Equipment GmbH Tel.: +49/6103/383-107 Robert-Bosch-Str. 5 Fax : +49/6103/383-157 D-63303 Dreieich-Sprendlingen Joerg.Maass@frs.mts.dec.com
-----------[000246][next][prev][last][first]---------------------------------------------------- Date: 15 Jul 1993 20:39:14 GMT From: Pearce Turpin <lanshark@llnl.gov> To: comp.protocols.tcp-ip Subject: Re: TCP/IP - Novell - WAN from HELL!
Re: TCP/IP - Novell - WAN from HELL! ETHERNET_II ---Another tangent: Encapsulation. How does this fit in? Someone said Netware requires it, but the NP doesn't do it. Is this true?? Holy cow! Pearce Turpin (W)lanshark@llnl.gov (H) lanshark@bohunk.win.net
-----------[000247][next][prev][last][first]---------------------------------------------------- Date: 15 Jul 93 21:24:51 GMT From: sazi@badlands.bellcore.com (Sazi Temel) To: comp.protocols.tcp-ip Subject: pSOS/pNA RARP ???
Does anyone know if there exist a RARP implementation for pNA/pSOS running on a 68x0 CPU ? Please respond to pbs@badlands.bellcore.com
-----------[000248][next][prev][last][first]---------------------------------------------------- Date: Thu, 15 Jul 1993 20:53:00 +0100 From: hugo@rusthoff.hacktic.nl (Hugo van.der.Kooij) To: comp.protocols.tcp-ip Subject: TCP/IP - Novell - WAN from HELL!
> From: Pearce Turpin <lanshark@llnl.gov> > Organization: Lawrence Livermore National Lab > I will buy dinner for the person who solves this one. > 5 LAN's connected > via a T1 WAN with a UNIX host on one of the LAN's. We > have a proprietary > app that needs Racal/Interlan NP600 'smart' NIC's > running their own > version of FTP's PC/TCP designed for the NP600. The > routers are Netware Some suggestions for the NP600 board. a) Try to debug the download code for the board. The board is handling IP. b) You might have to specify the IP router for any non-local network. I have seen a TCP server using this card that had to be taught each network besides it's own and which router was to forward. If you 're using SCO with special Racal software this answers your question. > 3.11-based with 3C509 LAN NIC's and Novell's Multi- > protocol Router boards > on the WAN side. Our addresses are all class 'C'. We > have no subnets. > Everything works fine, except when we try to use the > NP600 based PC's. I > cannot ping anything outside my own net. I can ping > the NIC on the LAN > side of the router, because it's on the same net. Now, > if I use LWP ODI > drivers, everything works perfectly. The same with > FTP's PC/TCP ver 2.2 > and the UNIX host. The only thing that dosn't work is > the PC's with the > NP600. I'm assuming either: > a. The router is not seeing packets sent by that > particular board for > what ever reason. > or > b. The boards are not compatible with SOMETHING, even > though I've > isolated everything > and they work locally. > I think it's (a), but I can't, for the life of me, > figure out why. The > server is set up to receive any size packet, and > everything else wroks > just fine. > Any of all input appreciated, and I'm serious about > the dinner....... You might indeed owe me one. Send me a private message and I will drop in whenever I come in your area. I admit I have the avantage of doing networks for four years with Racal. > --- > * Origin: Rust-Hoff is using a Private UUCP <==> FIDO > gateway (2:512/32.23) * Origin: Rust-Hoff; Home of the Brave. (2:512/32.23)
-----------[000249][next][prev][last][first]---------------------------------------------------- Date: Thu, 15 Jul 1993 23:12:55 GMT From: leanne@netmanage.com To: comp.protocols.tcp-ip Subject: Re: X-Window over phone line?
In article <1993Jul7.183018.1854@wsuhub.uc.twsu.edu>, <kodagali@wsuhub.uc.twsu.edu> writes: > Path: netman-gate!uunet!news.cnri.reston.va.us!newsserver.jvnc.net!howland.reston.ans net!wupost!kuhub.cc.ukans.edu!wsuhub.uc.twsu.edu!kodagali > Newsgroups: comp.protocols.tcp-ip > Subject: X-Window over phone line? > Message-ID: <1993Jul7.183018.1854@wsuhub.uc.twsu.edu> > From: kodagali@wsuhub.uc.twsu.edu > Date: 7 Jul 93 18:30:18 CST > Organization: Wichita State University, Wichita, Ks > Lines: 14 > > Hi, > > I have a Sparc 2 at my workplace running SunOS 4.1.3 and Openwin 3.0. It > is on an ethernet running TCP/IP. It also has a TELEBIT Worldblazer > modem for dialing in. I have a PC at home which I would like to connect > to the Sparc through the phone line so that I can run X-Window > progs on the Sparc and display them on the PC. I have DesqView/X to > convert the PC into X-terminal. I have a modem on the PC. Is this > possible ? > > Thanks for your time. > ---------------------------------------------------------- > Email: kodagali@wsuhub.uc.twsu.edu NetManage has a X Windows product called XSession that would solve the problem you have described. There is a module called XRemote that compresses the X protocol over phone lines. PPP and Slip are also supported although they aren't rec. for X. For more information email to netmanage.com. or call (408) 973-7171. Leanne leanne@netmanage.com >
-----------[000250][next][prev][last][first]---------------------------------------------------- Date: Fri, 16 Jul 1993 03:07:44 GMT From: chiang@iti.gov.sg (Chiang Kuo Chiang (IIRS)) To: comp.protocols.tcp-ip Subject: changing seg & win size in UNIX?
(I'm asking this for a friend) Is there a way to change the segment size and window size of TCP in unix? Thanks! --- +-------+ --+ +---+ | --+-- | | |___| | | | +-+ +-|-+ -+- | | | | | | | \ | +-+ +-|-+ | --+-- | | | +-------+ \| --+-\ Kuo Chiang, Chiang
---------