|
|
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 \fIrea