The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1993)
DOCUMENT: TCP-IP Distribution List for July 1993 (469 messages, 286644 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1993/07.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Jul 1993 04:49:31 GMT
From:      catstyle@gofish.aiss.uiuc.edu (Jason R. Heimbaugh)
To:        comp.protocols.tcp-ip
Subject:   Anyone offering DNS for a .org site?

Is anyone offering DNS for a .org?  I know that there used to be someone at 
DEC (or similar) that would do it for $5/year.  Is he still around, or is 
someone else offering the same for a nominal price?

Thanks,

-- 
Jason R. Heimbaugh 
jrh@uiuc.edu

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Thu,  1 Jul 93 10:30:23 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

In Article <rturner.741550521@imagen>
rturner@imagen.com (Randy Turner) writes:

>	   And while all of this sounds like a wonderful speedup, it
>	shoots down the usual layered approach to network software, in that
>	we have taken  functions of the transport layer and embedded that
>	functionality in what normally would be the data link layer.  There
>	would also have to be additional logic to handle a multi-protocol stack
>	implementation over this network interface , meaning the hardware would
>	have to be able to detect that the packet is a UDP/TCP packet
>	before doing the summing , if I understand what you are describing.

1. We're talking real world, not standards committees here. Perfect layering is
   really a myth in every system I've ever worked with.

2. IP predates the OSI model by some years and doesn't really fit it well..

3. Tell me, which layer is ICMP in? Are you really sure about that?

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 422-6955

Disclaimer: Being a know-it-all isn't easy. It's especially tough when you
don't know that much. But I'll keep trying. (Both)

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 93 14:10:28 GMT
From:      black@ll.mit.edu (Jerry Glomph Black)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over satellite T1

We're setting up a satellite T1 link at full bandwidth
for certain bulk data transfers [usually the data only gets 1/24 of the
bandwidth, the rest is voice/fax]. 

In our tests (with the usual 560 ms round-trip time) we are getting well
under the expected FTP rate of 130 kBytes/sec (actually, about 25% of this
rate!).  It appears that the limiting factor is the TCP window size (we're
losing a lot of time waiting for acknowledgements).

You've undoubtedly run into this kind of problem, how is it usually solved?
We're trying to do transfers between various TCP hosts, usually Suns and
SGIs. I'd like to avoid special-purpose kludge drivers to keep file transfers
universal.

Thanks, Jerry 
Jerry G. Black, MIT Lincoln Laboratory, Lexington MA   black@LL.MIT.EDU

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Jul 1993 15:22:17 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

In article <rturner.741475245@imagen>, rturner@imagen.com (Randy Turner) writes:
> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> ...
> >Hardware assist for TCP checksumming is a bit of a hassle on output,
> >because you need to stuff the checksum for the whole packet into the
> >front of the same packet.  Hardware assist for received packets is
> >trivial, and requires no more than the 16-bit sum of the entire
> >packet.  Clear the adder at the start of the packet, and fetch its
> >contents at the end.  If you have an odd byte, don't bother to add it,
> >or zero fill and add it.  (Yes, all that sums too much or too
> >little, but is no problem.  Everyone please think about how the TCP
> >checksum works before arguing with me about that detail.)
> 
> 	The thing that really complicates the issue of optimizing the
> 	checksum through means described above is the fact that a
> 	pseudo-header has to be formed and checksummed first.....
> 	It's not just a straightforward summing of a packet as an 
> 	additional bit of logic in an ASIC for Ethernet DMA...


Depending on what is meant, that is false.  Of course you add the
checksum of the psuedo-header, just like any TCP implementation.
You need not handle the psuedo-header first.

Remember that cksum(A+B)-cksum(B)=cksum(A).

Hardware support for input TCP checksum is absolutely trivial, subject
only to contraints on the speed of the adder(s) compared to the speed
of the medium.

I'm not talking about academic theories.  The most recent SGI FDDI
card for SGI's low cost workstations has been shipping in volume for
some time.


Vernon Schryver,  vjs@sgi.com

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Jul 1993 15:34:41 GMT
From:      emurphy@cs.uno.edu (Edward Murphy)
To:        comp.protocols.tcp-ip
Subject:   (?) is Dlink DE-200 an NE2000 clone?

Howdy.

Is the D-Link DE200 similar enough to an NE2000 so that the driver program  
for an NE2000 will work?

Ed Murphy

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Jul 1993 15:44:45 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over satellite T1

In article <1993Jul1.141028.8433@ll.mit.edu>, black@ll.mit.edu (Jerry Glomph Black) writes:
> We're setting up a satellite T1 link at full bandwidth
> for certain bulk data transfers [usually the data only gets 1/24 of the
> bandwidth, the rest is voice/fax]. 
> 
> In our tests (with the usual 560 ms round-trip time) we are getting well
> under the expected FTP rate of 130 kBytes/sec (actually, about 25% of this
> rate!).  It appears that the limiting factor is the TCP window size (we're
> losing a lot of time waiting for acknowledgements).
> 
> You've undoubtedly run into this kind of problem, how is it usually solved?
> We're trying to do transfers between various TCP hosts, usually Suns and
> SGIs. I'd like to avoid special-purpose kludge drivers to keep file transfers
> universal.


The default TCP/IP window on SGI boxes is 61440, 60*1024, about as big
as you can make it.  (Big windows help TCP over FDDI.) You can adjust
the default TCP window size on SGI boxes by changing tcp_recvspace and
tcp_sendspace in /usr/sysgen/master.d/bsd.

I think there was a way in some Sun kernels to edit a file to change
the default TCP window.  You could also use adb to edit /vmunix or the
running kernel.

You can also use setsockopt(SO_SNDBUF) and setsockopt(SO_RCVBUF) in SGI
and presumably Sun systems to adjust the TCP window for a single TCP
connection.

If you use `rcp` to transfer files, you can put a small program out of
~guest/.cshrc (or whatever) to apply those setsockopt()'s to standard
input.  (Recall that `rcp` uses an ordinary shell via the `rsh`
protocol.)  Big windows are bad for wide area links, causing Bad Things
in router queues, and I've been distributing a quick hack program that
adjusts windows inside the SGI network to reduce the harm of 60K
windows over 56K and T1 circuits.  I'll send source if you want it, but
it really is trivial.


Vernon Schryver,  vjs@sgi.com

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Jul 1993 16:01:03 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

jkay@cs.ucsd.edu (Jon Kay) writes:
> 
>> How many of those disk problems produced undetected errors?
>
>	I ran into one just last week on our server.  I found a bogus
>directory that had been copied by tar from another directory without
>passing over a network.  What produced it?  So long as it's not the
>network (which it wasn't), my argument remains intact.  It was
>undetected for months; I only ran noticed it by sheer accident.  

I'm actually in an excellent position to answer this question.

Glancing up I see status monitors constantly reporting on the forty-two
network servers I manage.  Though our system is trivial, providing
disk service rather than fileservice, it gives an excellent opportunity
to answer this sort of question.

Our diskservers report all disk CRC errors, all network checksum and 
other network errors, and they checksum physical memory in all background
cycles (ie. most of the time) because we keep all data structures 
in memory checksummed.  In other words, all parts of the system are
monitorred separately.  

What I have said so far does not answer your question about end-to-end
integrity, but this does:

On those servers there are a total of approximately 30,000 disk 
sectors which the server checksums on every read and write.

Though these special sectors constitute less than 0.05 % of the 
total disk space, they are distributed relatively evenly over the
many disk surfaces (they are control blocks preceding each virtual 
disk space), so they give an excellent idea of exactly what you ask.

These sectors are checked to provide user privileges very frequently,
and each is read at least once a day by the daily-save proceedure to
see if there has been any activity in the next few blocks which may
need to be archived.

Sooooo, the results are surprisingly in favour of believing the CRC.
We keep track of all CRC errors and have found that they appear very 
frequently in the same day whenever we get a checksum error on the 
checksummed blocks.  So if you get a few CRCs, and your OS reports them 
to you, start orderring a spare drive because this one will be going 
to the shop soon.

Our experience is that the CRC is not perfect, but that errors tend
to appear in clumps, and the CRC detects many of them, enough for
you to put your emergency plan into action.

Check your backups, check your data, you've been given advance
notice of an impending failure.  Of course, that only applies to OS's
which keep track of the CRC failure status.

As for the lightning strikes, blizzards happen attitude, a UPS solves
that for anyone willing to spend the money.

Erick
-- 


-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Jul 1993 16:48:43 GMT
From:      robc@splinter.synnet.com (Rob Ciampa)
To:        comp.protocols.tcp-ip
Subject:   TLI, Streams, and other events


|> In article <1993Jun25.153006.20899@lmpsbbs.comm.mot.com>, gulik@rtsg.mot.com (Gregory Gulik) writes: > In article <1993Jun25.032827.8335@sporran.uucp> tim@sporran.uucp (Tim Fry) writes:
|> > >
|> > >Since the TLI is layered on top of streams, you can use poll(2) to check for 
|> > >events on multiple file descriptors. Check the man page. I believe there
|> > >is an example in the standard AT&T TLI programmers guide.
|> > 
|> > poll() only works on streams devices.
|> > I need to be able to watch for input on a serial port.
|> > 

Although later implementations of poll() in SVR4.x will solve the problem of
handling different descriptor types, users of older releases (like SunOS 4.x)
should probably be blocking on events like read() and select().  Streams events
can interrupt these calls by registered file descriptors for SIGPOLL and
letting the interrupt handler invoke the poll() - non-blocking, of course.  Many
users have been apprehensive about mixing streams events and non-streams events,
but the implementation is rather straightforward.  It's also a great way to
implement TCP/IP client-server applications with TLI-based data link interfaces.

-- 
Robert A. Ciampa (robc@synnet.com)
Synernetics
85 Rangeway Road
North Billerica, MA  01862
(508) 670-5488

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 93 18:15:21 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>In article <rturner.741475245@imagen>, rturner@imagen.com (Randy Turner) writes:
>> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>> ...
>> >Hardware assist for TCP checksumming is a bit of a hassle on output,
>> >because you need to stuff the checksum for the whole packet into the
>> >front of the same packet.  Hardware assist for received packets is
>> >trivial, and requires no more than the 16-bit sum of the entire
>> >packet.  Clear the adder at the start of the packet, and fetch its
>> >contents at the end.  If you have an odd byte, don't bother to add it,
>> >or zero fill and add it.  (Yes, all that sums too much or too
>> >little, but is no problem.  Everyone please think about how the TCP
>> >checksum works before arguing with me about that detail.)
>> 
>> 	The thing that really complicates the issue of optimizing the
>> 	checksum through means described above is the fact that a
>> 	pseudo-header has to be formed and checksummed first.....
>> 	It's not just a straightforward summing of a packet as an 
>> 	additional bit of logic in an ASIC for Ethernet DMA...


>Depending on what is meant, that is false.  Of course you add the
>checksum of the psuedo-header, just like any TCP implementation.
>You need not handle the psuedo-header first.
 
>Remember that cksum(A+B)-cksum(B)=cksum(A).
 
>Hardware support for input TCP checksum is absolutely trivial, subject
>only to contraints on the speed of the adder(s) compared to the speed
>of the medium.
 
>I'm not talking about academic theories.  The most recent SGI FDDI
>card for SGI's low cost workstations has been shipping in volume for
>some time.


>Vernon Schryver,  vjs@sgi.com

	Right, that's what I was saying, that there is more to the
	implementation than just summing the data portion in hardware.
	After that's done, there is still some pseudo-header construction
	and summing to be done in software.
	   And while all of this sounds like a wonderful speedup, it
	shoots down the usual layered approach to network software, in that
	we have taken  functions of the transport layer and embedded that
	functionality in what normally would be the data link layer.  There
	would also have to be additional logic to handle a multi-protocol stack
	implementation over this network interface , meaning the hardware would
	have to be able to detect that the packet is a UDP/TCP packet
	before doing the summing , if I understand what you are describing.

	Randy

-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Jul 1993 18:21:06 GMT
From:      gcamp@evtech.com (Glen Campbell)
To:        comp.protocols.tcp-ip
Subject:   Re: New Yorker cartoon

In article <20sc1a$kmr@calvin.NYU.EDU> roy@mchip00.med.nyu.edu (Roy Smith) writes:
>From: roy@mchip00.med.nyu.edu (Roy Smith)
>Subject: New Yorker cartoon
>Date: 30 Jun 1993 15:38:18 GMT
 
>        It would seem the Internet has finally really made it into the
>popular press.  The 1993 July 5th New Yorker has a cartoon (page 61) of two
>dogs.  One is sitting at a computer terminal, saying to the other, "On the
>Internet, nobody knows you're a dog".
>-- 
>Roy Smith <roy@nyu.edu>
>Hippocrates Project, Department of Microbiology, Coles 202
>NYU School of Medicine, 550 First Avenue, New York, NY 10016
>"This never happened to Bart Simpson."

It does make one wonder about who has time to make all these postings I'm
reading...


Glen Campbell (gcamp@evtech.com)

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Jul 1993 18:22:17 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

Vernon Schryver (vjs@rhyolite.wpd.sgi.com) wrote:

: I'm not talking about academic theories.  The most recent SGI FDDI
: card for SGI's low cost workstations has been shipping in volume for
: some time.

Nor is Vernon talking SGI specific. Two of the three FDDI cards from
HP (Series 800 NIO, and Series 700 Integrated), offer either both
out/in, or in checksum offload.

rick jones


-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 1993 18:32:21 GMT
From:      bcarter@magnus.acs.ohio-state.edu (Bryan D Carter)
To:        comp.protocols.tcp-ip
Subject:   Finding IP #s

Greetings...

     I'm not sure if this is right place to ask this, but here goes.
     Could someone please give me some information on how to determine
what a site's IP address is if all you have is a system name
ie:bluemoon.use.com and a user name ie:jdoe@bluemoon.use.com?  When
I try to finger/whois the system I get something to the effect of
"no host found, try using the host IP address" as an error.
     I know the system is in the UUCP map because I've check in there,
but that doesn't give me an IP# either.
     Any help would be appreciated, please send any replies via e-mail.
     Thanks...

Bryan Carter

bcarter@magnus.acs.ohio-state.edu

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 1993 19:57:46 GMT
From:      drawbridge@sc.tamu.edu
To:        comp.security.misc,alt.security,comp.unix.admin,comp.protocols.tcpip,comp.sys.sun.admin
Subject:   TAMU Security Package Update


              Texas A&M Network Security Package Update
                              7/1/93

                           Dave Safford
                           Doug Schales
                            Dave Hess

This is an updated release of the security tools developed at the
Texas A&M University Supercomputer Center.  These tools are available
for anonymous FTP from sc.tamu.edu:/pub/security/TAMU.

------------------------------------------------------------------------
CHANGE SUMMARY (see respective README files for more information):

'tiger' - Version 2.1.1 - UNIX security checking tool

An explain facility for giving more information on the output from
tiger.  Many new checks, bug fixes, all around improvements.  Too
numerous to go into.  Briefly, checks mail aliases, cron jobs, inetd
configuration, PATH variables, more checks on passwd and group files.
Untested initial configuration files for AIX 3, IRIX 4, HPUX and
UNICOS.  Tested configurations for SunOS 4.1.1, 4.1.2, 4.1.3, 5.1 and
5.2, including signatures for latest security patches, and NeXTSTEP 3.0.

'netlog' - Version 1.02 - Network traffic logging tools

Bug fixes, minor enhancements to functionality.  New tool for gathering
statistics on protocol and port usage.

'drawbridge' - Version 1.1 - IP bridging filter

Bug fixes. Allow and reject clauses did not work properly and bridging
was not working efficiently.

'check_TAMU' - TAMU Security distribution check script

A new script is now available for checking this distribution for any signs
of tampering. This is intended for anyone who obtains this distribution from
a site other than sc.tamu.edu. The script is available from a mailserver at
"drawbridge-server@sc.tamu.edu". See the section AVAILABILITY below for more
info.

------------------------------------------------------------------------
ORIGINAL DESCRIPTION:

Last August, Texas A&M University UNIX computers came under extensive
attack from a coordinated group of internet crackers.  This package of
security tools represents the results of over nine months of
development and testing of the software we have been using to protect
our estimated five thousand IP devices.  This package includes three
coordinated sets of tools: "drawbridge", an exceptionally powerful
bridging filter package; "tiger", a set of convenient yet thorough
machine checking programs; and "netlog", a set of intrusion detection
network monitoring programs.

KEY FEATURES:

For full technical details on the products, see their individual README's,
but here are some highlights:

        DRAWBRIDGE:
                - inexpensive (PC with two SMC/WD 8013 cards)
                - high level filter language and compiler
                - powerful filtering parameters
                - DES authenticated remote filter management
                - O(1) table lookup processing even with dense class B
                        net filter specifications.      

        TIGER:
                - checks key binaries against cryptographic
                  checksums from original distribution files
                - checks for critical security patches
                - checks for known intrusion signatures
                - checks all critical configuration files
                - will run on most UNIX systems, and has tailored
                  components for SunOS, Next, SVR4, Unicos.

        NETLOG:
                - efficiently logs all tcp/udp establishment attempts
                - powerful query tool for analyzing connection logs
                - "intelligent" intrusion detection program

AVAILABILITY:

This package is available via anonymous ftp in 

        sc.tamu.edu: pub/security/TAMU

Due to the sensitive nature of these tools, we recommend that you
retrieve them from this location. If you do not get them from
sc.tamu.edu we suggest that you use our check_TAMU script that uses
cryptographic checksums to check the distribution for any signs of
tampering. The script is available in the anonymous ftp directory above
and from an e-mail server at:

        drawbridge-server@sc.tamu.edu

Note that there are some distribution limitations, such as the
inability to export outside the US the DES libraries used in
drawbridge; see the respective tool README's for details of any
restrictions. (Note that the DES libraries are NOT required to use
drawbridge. They just enable secure remote management of drawbridge.)

CONTACT:

Comments and questions are most welcome. Please address them to:

        drawbridge@sc.tamu.edu


-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Jul 1993 22:03:35 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

In article <rturner.741550521@imagen>, rturner@imagen.com (Randy Turner) writes:
> ...
> 	   And while all of this sounds like a wonderful speedup, it
> 	shoots down the usual layered approach...

hmmph.  That "usual layered approach" to network protocols exists only in 
    1. academic papers about how things ought to be.
    2. standards committee view graphcs.
    3. standards documents
    4. low speed, often buggy, naive implementations.

Layering is an excellent way to think about networks, and to roughly
structure code and hardware, but no more.

The boxes and layers in the standards documents are perfectly fine
descriptions of how things should appear to work from outside your
black box.  However, who anyone to tries to implement exactly the boxes
and layers, Signal_This and Indicate_That functions in the OSI, IEEE,
and ANSI standards almost always (well, always in my experience) fails
to produce a salable or even interesting product.

Imagine how useful would be an Ethernet chip that was actually
implemented with the Pascal code in the IEEE-802.3 standard.

Doing the TCP checksum in the link layer need not be a particularly big
layering violation.  There are far larger violations of Standard
Committee Law than having your link layer code pass both the data and
the 1's complement sum of all of that data to the next layer up.  Eventually
the TCP code (in which ever layer you put it) would receive its data and
adjusted 1's complement sum, and do the obvious.

Note: the SGI FDDI checksum scheme just flat out voilates the layers.
The link layer adds a bit to the data that says "this was good; trust me".
The Layering Standards Mavens are welcome to arrest me.


Why do so many otherwise rational people who would never outlaw
absolutely every use of goto and every use of assembly language have
such an unhealthy respect for network layering?

Vernon Schryver,  vjs@sgi.com

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Jul 1993 22:18:18 GMT
From:      john@gecko.mtc.ti.com (John Maline)
To:        comp.protocols.tcp-ip
Subject:   Errors on unconnected UDP sockets and RFC1122

I've got an application that finds a server via a UDP broadcast, then
communicates with it via directed UDP.  At no time is a connect()
ever done on this socket.

Under SCO Unix 2.3v4, I get ECONNREFUSED on subsequent recvfrom() and
sendto() calls, because a couple of misbehaving host on our net send
me an ICMP port unreachable message in response to my broadcast
(something that's prohibited by RFC1122).

Other hosts running SunOS 4.1.x, AIX 3.1.x do the same broadcast and
get the same ICMP message, but don't return any error to the
application.

According to RFC1122, paragraph 4.1.3.3:

	"UDP MUST pass to the application layer all ICMP error
	messages that it receives from the IP layer.  Conceptually at
	least, this may be accomplished with an upcall to the
	ERROR_REPORT routine (see section 4.2.4.1)."

According to _Unix Network Programming_ by Stevens, p 271 (discussing
the connect() call):

	"There is another feature provided for connectionless clients
	that call connect.  If the datagram protocol supports
	notification for invalid addresses, then the protocol routine
	can inform the user process if it sends a datagram to an
	invalid address.  For eample, the Internet protocols specify
	that a host should generate an ICMP port unreachable message
	if it receives a UDP datagram specifying a UDP port for which
	no process is waiting to read from. ...  4.3BSD, for example,
	notifies the process with a "connection refused" error
	(ECONNREFUSED) on the next system call for the socket, only if
	the process had connected the socket to the destination
	address."

It sounds like the 4.3 (and SunOS and AIX) behavior described by
Stevens isn't in compliance with RFC1122.  Is this correct?

Are other vendors going to the mandatory error reporting behavior?  Is
there some loophole that allows them to be RFC1122 compliant, but use
the 4.3 behavior?  Is SCO doing something *wrong* by reporting the
error even without the connect() (and can you quote me a paragraph
number from some Internet standard RFC? :-).

Please reply by mail.  Thanks.

--
John Maline
jmaline@lobby.ti.com    TI MSG: JWMX           214-995-6692
Texas Instruments       PO Box 655012 MS 351   Dallas, TX 75265


-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Jul 1993 23:14:38 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   the usual layered approach

>>          And while all of this sounds like a wonderful speedup, it
>>       shoots down the usual layered approach...
>
> hmmph.  That "usual layered approach" to network protocols exists only in
>    1. academic papers about how things ought to be.
>    2. standards committee view graphcs.
>    3. standards documents
>    4. low speed, often buggy, naive implementations.
>
> Layering is an excellent way to think about networks, and to roughly
> structure code and hardware, but no more.

Let me add my voice to Vernon's here.

The grand seven layer architecture as we know it now was developed as a way
to assign work to standards committees.  All that strongly worded text about
strict layering and clean interfaces was a way of making sure the standards
committees not to mess in each other's work.

Thus a layered implementation is typically one that is blindly following
a set of committee assignments made 15 years ago.  Personally I find it a
bit funny that a set of political decisions should dictate coding styles...

Craig

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Fri, 02 Jul 1993 00:08:29 GMT
From:      debiso@westfield.win.net (Joe DeBiso)
To:        comp.protocols.tcp-ip
Subject:   Network printing from a PC to an SCO box

I need to be able to print to postscript printers on my network.  I
have a bunch of PC's all using ncsa telnet and ftp with clarkson
drivers.  Is there a way to redirect LPT2: to the network
printer??  Any one with info, please HELP!!!

Thanx,
Joe DeBiso
Plantrol Systems, Ltd.



-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 1993 02:08:43 GMT
From:      mjr@tis.com (Marcus J Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>Note: the SGI FDDI checksum scheme just flat out voilates the layers.
>The link layer adds a bit to the data that says "this was good; trust me".
>The Layering Standards Mavens are welcome to arrest me.

	Don't worry on that account.

	They're all too busy trying to figure out how to make theirs
work fast, to go out arresting people.

	In all seriousness, layering software is useful. Once you
prototype something in a layered manner it's *REAL* easy to profile
it and see where the bottlenecks are, and *THEN* to optimize it.
This is what I always thought of as "computer science"

10	Hypothesize
20	Perform experiments
30	Evaluate results
40	GOTO 10

	A real scientist will throw out the theory if the output
of lines 20 and 30 are promising and/or make your product more
competitive on the market.

mjr.

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 93 08:13:15 GMT
From:      tom@wcc.oz.au (Tom Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

In article <20s7kv$h8s@calvin.NYU.EDU>, roy@mchip00.med.nyu.edu (Roy Smith) writes:
> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> > The TCP checksum is effective, as shown by detected errors.
> 
> ... show is that TCP checksuming catches *some* errors... It's well
> known that there are certain kinds of errors which will corrupt a
> packet yet still pass checksum (i.e. transposed quadwords).

Transposed shorts and longs too. And one that bit me last month - if
the packet is thought to be longer than it originally was (length
field calculation stuffup) and the extra "data" is +0 or -0, it
doesn't get detected either.

========================
Tom Evans  tom@wcc.oz.au
Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179
Victoria, Australia 61-3-764-1100  FAX ...764-1179  A.C.N. 004 818 455


-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Jul 1993 08:15:38 GMT
From:      shewison@brookes.ac.uk (Simon Hewison)
To:        comp.protocols.tcp-ip
Subject:   Alternative protocols for Lan Manager/X

Does anyone know if it's possible to run a protocol stack other than tcp/ip with
Lan Manager/X or DEC Pathworks? We're currently running NETBEUI to OS/2
servers, and would like to know if we need to go and change all our clients
to tcp/ip if we are to use Lan Manager/X or DEC Pathworks.

On a more general note, if there is any other way of having alternate protocol
stacks on unix, at what level would it come in? I assume that it would be 
below the sockets interface.

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Jul 1993 11:26:43 GMT
From:      kuipers@fwi.uva.nl (Tobias Kuipers)
To:        comp.protocols.tcp-ip
Subject:   How to get IP# of telnet-session on SCO?


Does anyone have experience in fetching runtime data of SCO TCP/IP
(release 1.1.3f) under SCO UNIX (386/3.2v4.0)? I want to obtain the
IP number of a telnet session for security enhancements, but whilst
the IP number of a PTY login is stored in /etc/utmp under e.g. SunOS
and Silicon Graphics, this is not the case with SCO.

Does anyone know how to hook into the kernel chars of SCO to fetch TCP
parameters of a session? I do have a development license, but the docs
are worse then the manual of a Bulgarian food processor.

Please reply by email: kuipers@fwi.uva.nl or kuipers@eurocode.nki.nl

Thanks in advance,

Tobias Kuipers



-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Jul 1993 11:31:45 GMT
From:      nick@quay.ie (Nick Hilliard)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Routing problems with ppp

Howdy all.

I'm having some problems using PPP.  I'm using a Sun (4.1.3) with
the freeware PPP (ppp-1.2.tar.Z) package written by Brad Clements.

The problem is that the Sun, for some reason or other, isn't routing
packets properly.  Here's the configuration:

Apart from the loopback device, the Sun (quake) has 2 interfaces (they
have different names for political reasons):
	ppp0:		192.122.232.1	(extern.quay.ie)
	le0:		192.122.220.8	(quake.quay.ie)

The routing table on the Sun is like this:

quake:/# netstat -rn
Routing tables
Destination          Gateway              Flags    Refcnt Use
Interface
127.0.0.1            127.0.0.1            UH       0      0          lo0
192.111.39.4         192.122.232.1        UH       0      0          ppp0
default              192.122.232.1        U        17     236        ppp0
192.122.220.0        192.122.220.8        U        50     66976      le0

The default route is added using 
quake:/# route add default 192.122.232.1 0

The PPP server that I use is tain.ieunet.ie (192.111.39.4), and
192.122.220.0 is a local net.

'curia' is a machine in the outside world, which I log in to from quake.
But this is what happens when I try to ping 192.122.220.8 (the Ethernet
interface on quake)

curia:/home/nick> ping 192.122.220.8
ICMP Time Exceeded from tain.IEunet.ie (192.111.39.4)
 for curia (143.239.1.8) to 192.122.220.8 port 6026
ICMP Time Exceeded from tain.IEunet.ie (192.111.39.4)
 for curia (143.239.1.8) to 192.122.220.8 port XXXX
[etc, etc, for various values of XXXX]

A traceroute reveals the following:

traceroute to 192.122.220.8 (192.122.220.8), 30 hops max, 38 byte packets
 1  cisucc (143.239.1.199)  10 ms  0 ms  10 ms
[intermediary nodes deleted]
 8  Dublin.IE.EU.net (134.222.6.2)  160 ms  90 ms  110 ms
 9  tain.IEunet.ie (192.111.39.4)  330 ms  130 ms  110 ms
10  134.226.128.1 (134.226.128.1)  200 ms  140 ms  100 ms
11  tain.IEunet.ie (192.111.39.4)  160 ms  410 ms  210 ms
12  134.226.128.1 (134.226.128.1)  130 ms  230 ms  130 ms
13  tain.IEunet.ie (192.111.39.4)  110 ms  100 ms  180 ms
[etc]

As might be expected, none of the machines on the 192.122.220.* net can
contact the outside world either.

If I set up SLIP on another machine on the 192.122.220.* net, everything
works fine. All local machines can be contacted from the outside world
(and vice versa) without any problems, so the problem is (almost)
definitely with the PPP on the Sun.

So, any ideas?  I've tried fiddling about with routing table, but nothing
I did seemed to make the slightest difference :-( Is this a problem with
this particular version of PPP?

Thanks in advance,
Nick
--
| Nick Hilliard                  | e-mail:   nick@quay.ie                   |
| Quay Financial Software,       | Phone:    [+353] 1 6612377               |
| Ferry House, Lower Mount St,   | Fax:      [+353] 1 6607592               |
| Dublin 2, Ireland.             | Opinions: I think; therefore I disclaim. |

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Jul 1993 13:05:04 GMT
From:      rwausti@aplcenmp.apl.jhu.edu (NE Austin richard way ddfde344556666)
To:        comp.protocols.tcp-ip
Subject:   Where to find TCP/IP over X.25 data

I am conducting a research project and am in need of acquiring TCP/IP over
X.25 traffic (1's and 0's).  Can anyone suggest a good network simulator or
better yet, does anyone have access to test data that might meet this 
criteria.  Any and all help would be appreciated.

Rick Austin
Austin_Richard_W@smtpmac.ads.com

"When in doubt, REBOOT".  Ken Updike, 1990



-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Jul 1993 13:27:17 GMT
From:      errol@hpgnd153.grenoble.hp.com (Errol_Inan)
To:        comp.protocols.tcp-ip
Subject:   Re: New Yorker cartoon

> "On the Internet, nobody knows you're a dog".

Bark, bark!  Ruff, ruff.  Sniff, sniff, sniff, sniff, sniff.

<censored>

Pant, pant, pant, ....


-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 1993 13:50:39 GMT
From:      bob@comlab.gtri.gatech.edu (Bob Baggerman)
To:        comp.protocols.tcp-ip
Subject:   Re: Alternative protocols for Lan Manager/X

Simon Hewison asks:
> Does anyone know if it's possible to run a protocol stack other than 
> tcp/ip with Lan Manager/X or DEC Pathworks? We're currently running 
> NETBEUI to OS/2 servers, and would like to know if we need to go and 
> change all our clients to tcp/ip if we are to use Lan Manager/X or 
> DEC Pathworks.

The short answer is yes, it is possible to run other protocol stacks.
You can run whatever protocol stack your server vendor has available.
But that's probably not really what you are asking.  The LM/X product
runs on a Unix box and depending on the vendor uses TCP/IP or OSI as
the transport protocol for the server NetBIOS.  DEC Pathworks uses
DECnet and TCP/IP on the VAX and MIPS based servers.  I haven't looked
at Pathworks in a while but they may now offer other protocols such
as NetBEUI on the VAX and MIPS based servers.  It's worth a call to 
a knowledgeable sales type.  Syntax in Auburn, Washington, USA has
recently finished up a NetBEUI implementation for their Unix based
LanMan compatible LMserver product.  LMserver is supposed to run on 
most flavors of Unix.  If you haven't bought into LM/X (I think they 
call it LMU now) or Pathworks then LMserver might be a good alternative.

Keep in mind that you can run multiple NetBIOS protocol stacks on your
PCs if need be.  I.e. you can run both NetBEUI and an IP based NetBIOS
at the same time.  It would be a real memory pig but other people have
reported being able to do it.

Bob

-- 
Bob Baggerman                         !  bob.baggerman@gtri.gatech.edu
Communications Laboratory             !  bob@comlab.gtri.gatech.edu
Georgia Tech Research Institute       !  qseclrb@prism.gatech.edu
Atlanta, GA  30332  USA               !  404-894-3525

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Jul 1993 14:25:11 GMT
From:      durst@mwunix.mitre.org (Robert Durst)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   POSIX Ballot Group Forming for Sockets and XTI


To Whom It May Concern:

The POSIX P1003.12  group is defining a protocol-independent 
Application Program Interface for process-to-process 
communication.  POSIX requires its standards to be based on 
existing practice, and two C-language interfaces are being 
standardized by P1003.12.  One is the X/Open Transport 
Interface (XTI), and the other is the Sockets interface.  The 
group has defined a language-independent specification to 
which both C-language bindings conform, and this enables the 
two bindings to be presented  within a common framework.  
Additionally, the group anticipates that non-C-language 
bindings would be developed in  accordance with this 
language-independent specification.

The group intends to ballot its draft standard in the 
September 1993 time frame.

It is to everyone's benefit that these APIs are incorporated  
into POSIX.  Your help is  requested to ensure that they are 
incorporated correctly.  You can provide this help by joining 
the ballot group and balloting on the standard..

If you are a sockets user or implementor, you should be aware 
that a significant amount of semantic information has been 
extracted from the Berkeley reference implementation for 
incorporation into the specification.  This material should 
be reviewed thoroughly.  If you are an XTI expert, the text 
in the P1003.12 draft is essentially that of the XTI CAE 
specification.  As the draft goes through the IEEE balloting 
process, changes will certainly be requested.  The presence 
of both Sockets experts and XTI experts in the ballot pool is 
essential if these requests are to be handled properly.  

Membership in the P1003.12 ballot pool is by invitation.  IF 
YOU WISH TO RECEIVE AN INVITATION  to join the P1003.12 
ballot pool, either you must already receive POSIX 
invitations to ballot on draft standards or you must REPLY TO 
THIS MESSAGE so I can make sure you get an invitation.  Once 
the ballot pool is formed, it is fixed and cannot be added 
to, so reply now.

You DO NOT have to be a member of IEEE to ballot on this 
draft standard, however, you must be a member in order to 
vote "yes."  Non-IEEE members are considered parties of 
interest, and if objections are raised by parties of 
interest, we will give them due consideration.  

THERE IS A FEE charged by the IEEE to cover the initial 
distribution of the document and all subsequent 
recirculations.  The document is currently about 400 pages 
long, and we expect the fee to be approximately $50.

In order to receive an invitation to ballot on IEEE P1003.12, 
reply to this message with your name, address, phone number, 
fax number, email address, and IEEE membership  number (if 
applicable).  


Regards,

Robert C. Durst
Chairman, IEEE P1003.12
durst@mitre.org

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Jul 1993 14:48:04 GMT
From:      nick@quay.ie (Nick Hilliard)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: Routing problems with ppp

Nick Hilliard (nick@quay.ie) wrote:
[Sad woes deleted]

Ok - the problem appears to be with the PPP server I was connecting into, so
you can safely ignore my previous posting...

best,
Nick
--
| Nick Hilliard                  | e-mail:   nick@quay.ie                   |
| Quay Financial Software,       | Phone:    [+353] 1 6612377               |
| Ferry House, Lower Mount St,   | Fax:      [+353] 1 6607592               |
| Dublin 2, Ireland.             | Opinions: I think; therefore I disclaim. |

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Jul 1993 15:01:22 +0000
From:      robin@tcam.demon.co.uk (Robin Duerden)
To:        comp.protocols.tcp-ip
Subject:   SUN, IP Broadcasts and woe!!


	I would like to send out UDP broadcast datagram packets to IP
destination address 255.255.255.255 from my SUN workstation using the standard
Berkley socket interface API. My SUN's ifconfig command currently reports
interface le0 being set up as ip addr=192.1.1.177, netmask=FFFFFF00 and
broadcast=192.1.1.255.

	I can receive packets broadcast from other sources containing the
IP address of 255.255.255.255 by using ifconfig to set broadcast=255.255.255.255
but all attempts to send to this address result in a "network unreachable"
error.

-- 
Robin Duerden

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Jul 1993 15:28:45 GMT
From:      emurphy@cs.uno.edu (Edward Murphy)
To:        comp.protocols.tcp-ip
Subject:   (?) experiences installing a De-200 card and NCSA Telnet


Howdy.

I am installing NCSA Telnet for the PC version 2.3.06. The hardware is a  
386 PC with a DE-200 ethernet card (made by D-Link). The card is certified  
compatible with the NE2000 series of Novell ethernet cards. If anyone has  
experiences with configuration, I would greatly appreicate your contacting  
me. I have several questions regarding the process.

Ed Murphy

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 1993 15:47:10 GMT
From:      bcarter@magnus.acs.ohio-state.edu (Bryan D Carter)
To:        comp.protocols.tcp-ip
Subject:   Re: Finding IP #s

I've got what I needed, thank for all the help.

R.I.P.

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Jul 1993 15:56:30 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

In article <3202@wcc.oz.au>, tom@wcc.oz.au (Tom Evans) writes:
> In article <20s7kv$h8s@calvin.NYU.EDU>, roy@mchip00.med.nyu.edu (Roy Smith) writes:
> > vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> > > The TCP checksum is effective, as shown by detected errors.
> > 
> > ... show is that TCP checksuming catches *some* errors... It's well
> > known that there are certain kinds of errors which will corrupt a
> > packet yet still pass checksum (i.e. transposed quadwords).
> 
> Transposed shorts and longs too. And one that bit me last month - if
> the packet is thought to be longer than it originally was (length
> field calculation stuffup) and the extra "data" is +0 or -0, it
> doesn't get detected either.


I agree.

If I were arguing about the right checksum, I would ask for something
that would distribute almost as easily over concatenation
(ck(A+B)-ck(B)=ck(A)), but would have detected at least some
transpositions, something like a rotate between 16-bit adds.  Of course
today, you'd probably use 32-bit adds, which detects transposed
16-bit-words.

On the other hand, all of the hardware and software bugs I've seen
discovered with or covered by the TCP checksum were not simple
transpositions, or also involved other problems.

As long as you're sending data bit-serial, I don't supposed
transpositions are as likely as other fun like "simple" noise.



Vernon Schryver,  vjs@sgi.com

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 1993 16:29:33 GMT
From:      haas@bnr.ca (Mark Haas)
To:        comp.protocols.ibm,comp.protocols.iso,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Advance Announcement: ICNP-93

		Advance Announcement
The 1993 International Conference on Network Protocols (ICNP '93)
		October 19-22, 1993
	ANA Hotel, San Francisco, California

ICNP '93 is concerned with the design, specification, validation,
implementation and testing of computer network protocols for network
access, routing, flow and congestion control, network operation and
management, and internetworking.

The new conference will prove well worth attending.  Two half-day and
one full-day tutorials will be given on the first day to provide an
opportunity for intensive exposure to hot topics of current interest.
During the last three days of the conference, there will be two
invited keynote addresses, one planery panel session, and presentation
of 42 papers in 14 sessions.  In addition a reception will be given
for social activities.  Come and join us.

The conference will be held at the ANA Hotel, 50 Third Street, San
Francisco, CA 94103.  Rates for ICNP '93 are $130 single and $150
double.  Please contact the hotel directly at (415) 974-6400 for
reservation.  Please be sure to mention ICNP '93 for the special
rates.  The deadline for reservations is September 27, 1993.

The two keynote addresses will be delivered by Mr. Tony M. Yuen, VP,
Data Communications Products, Northern Telecom; and by Dr. Harry R. Rudin,
IBM Research Division, Zurich Research Laboratory.  Mr. Yeun's
topic is "Data Networking in the 1990's" and Dr. Rudin's topic is
``Protocol Development vs. Formal Description Techniques.''

The plenary panel session is organized by Dr. David Lee of AT&T Bell Labs.
The topic is ``Protocol Conversion and Internetworking.''  The
panelists are Dr. Simon Lam, University of Texas, Austin; Dr. Krishan
Sabnanni, AT&T Bell Labs.; Dr. Joshua Auerbach, IBM Watson Research
Center; and others to be announced later.




Tutorials (October 19)

No.1: ATM: Technology, Design and Control, by Drs. P. Varaiya and
      J. Walrand, University of California, Berkeley.  Full Day, 9 am
      to 5 pm (including lunch).

No.2: Mobile Communications: Systems Architecture, by Dr. B. Gopinath,
      Rutgers University.  Half Day, 9 am to 12:30 pm.

No.3: Design and Validation of Communication Protocols, by
      G. Holzmann, AT&T Bell Labs. Half-Day, 1:30 pm to 5:00 pm.




Technical Program (October 20-22)

The technical program will consist of 14 sessions in two tracks, 3 papers per
session. The session titles are as follows.

October 20:

1A.  Protocol Configuration and Architecture
1B.  Protocol Verification I

2A.  Routing Protocols
2B.  Protocol Modularity and Layering

3A.  Congestion and Flow Control
3B.  Protocol Theory

October 21:

4A.  Congestion and Rate Control
4B.  Protocol Testing I

5A.  Broadcast Protocol
5B.  Simulation and Validation Tools

Panel: Protocol Conversion and Internetworking

October 22:

6A.  Protocol for LANs
6B.  Protocol Verification II

7A.  Performance Evaluation
7B.  Protocol Testing II




Registration

Advance Registration will be handled by Mr. Mark Haas, ICNP '93, 2116
E. Arapaho Road, Suite 297, Richardson, TX 75081; Phone, (214)
684-4629; Fax, (214) 684-3705; e-mail, icnp93@compmail.com.  The
deadline for advance registration is September 27.  The rates are as
follows:

					Advance			Late
				     (until 9/27)	     (after 9/27)
Tutorials

Member Full Day (No.1)			$200			$250
Member Two Half Days (Nos. 2 & 3)	$200			$250
Member One Half Day (No. 2 or 3)	$110			$140
Nonmember Full Day (No. 1)		$250			$315
Nonmember Two Half Days (Nos. 2 & 3)	$250			$315
Nonmember One Half Day (No. 2 or 3)	$130			$160

Technical Program

Member					$250			$300
Nonmember				$315			$375
Full Time Student			$100			$120


Please make checks in US dollars to IEEE Computer Society, and provide
your name, affiliation, address, phone and fax numbers, e-mail
address, and IEEE-CS membership number (if applicable) when
registering.

Credit cards (VISA, MasterCard, Diners Club, and American Express) are
acceptable.  Please provide your card type, card number, cardholder's
name (exactly as it appears on the card), card expiration date, and
your signature.

For further information, please contact Dr. Ming T. (Mike) Liu, phone (614)
292-6552, fax (614) 292-2911, e-mail mike.liu@osu.edu.




-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Fri,  2 Jul 93 10:37:57 +0400
From:      aleksey@kivc.magnitka.chel.su
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.xenix.sco,fido7.unix,relcom.fido.ru.unix
Subject:   [HELP!] pOMIpA@ BEZ TCP/IP Run Time for SCO XENIX.gDE WZQTX?(aleksey@kivc.magnitka.chel.su)

---
--

-     G.mAGNITOGORSK iwc a/o "magnitostroj"
-       aLEKSEJ r. gOLOWA^EW


-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Jul 1993 18:39:48 GMT
From:      wunder@hpl.hp.com (Walter Underwood)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

The TCP checksum won't catch transpositions, but it will usually catch
blocks of 1's or 0's.  Does your Ethernet controller have parity memory?
What happens if one of those chips goes bad?

wunder


-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Jul 1993 20:00:20 GMT
From:      jburnes@csisun.uucp (Jim Burnes)
To:        comp.protocols.tcp-ip
Subject:   GURU question - Routing & SNMP

Hi Folks...here is a question for you....

We have a situation where a site administrator needs to have
SNMP access to a bunch of smart computer appliances (lets call
them room air conditioners for sake of argument).  Lets also
say that these air conditioners are frequently hooked to
host computers via RS232 lines in order to tell the computer
when to shut down because its too hot.

Now the administrator queries these room air conditioners via
SNMP to keep constant tabs on room temp, performance, BTU's
etc etc etc

Lets also assume that all the conditioning units except two
or three have ethernet adapters and can understand TCP/IP/SNMP
right off the net.  The other ones are dumb, but they are hooked
to smart hosts running TCP/IP.  Is there any way for the smart
host to act as a proxy for his dumb air conditioner and route
packets destined for the air conditioner and then interpret
the SNMP coming in and translate it to something the air
conditioner can understand?

Something like this.....



+-------+
!       !
! admin !--------+-----------+-----------NET--------------+-------------...
!       !        !           !                            !
+-------+        !           !                            !
  SNMP for air 1>!     SNMP> !        SNMP for smart host>! <for dumb air
            +----------+ +-----------+              +------------+
            !          ! !           !  192.9.200.3 !            !
            ! smart air! ! smart air !              ! smart host !
            !     1    ! !    2      !              !            !
            !          ! !           !              !------------!
            +----------+ +-----------+              !  routing   !
            192.9.200.1  192.9.200.2                !------------!
                                                    !   xlation  !
                                                    +------------+
                                                          ^
                                                 (no net) !<RS232 command pipe
                                                          V
                                                    +------------+
                                        192.9.200.4 !            !
                                         (by proxy) ! dumb air   !
                                                    !            !
                                                    !            !
                                                    +------------+

So I expect you would essentially route packets for this dumb air 
conditioner and then somehow link in to the other end of the
packets being routed, recieved them by some proxy program and
then do protocol translation to and from the air conditioner.

I'm really mirky on what sort of API would allow me access to the
incoming packets.  Is this possible?  Would I need access to the
OS's TCP/IP source or is their a predefined interface to become
some sort of server daemon at this level.  

TCP GURU's...I need your help!

I will repost a digest version of my replies for the rest of the
net.

Thanks,

Jim Burnes
jburnes@compusci.com

-- 
Jim Burnes
Software Engineer
CompuSci, Inc.
jburnes@compusci.com

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Jul 1993 20:26:34 GMT
From:      DELLA@lexmark.com
To:        comp.protocols.tcp-ip
Subject:   Reverse remote name server help?

We are attempting to have our primary name server refer to another primary
name server for reverse address resolution.  For some reason we cannot.
We've played in the named.boot file and also named.rev file
to find where we might possibly place a record and what the format
of this record might be (to no avail).
 
After looking through the RFC 883 and other UNIX documentation,
we have been unsuccessful in doing this thing.
We are running AIX 3.2 on an RS/6000.
 
Here is what we need to resolve:
   My name server is the primary name server for the abc.123.com domain.
   Another name server is the primary name server for the def.123.com
   domain.  I want to be able to resolve an IP address that is
   defined on the other name server from my name server.
 
i.e. 'host 157.184.29.2'
 
Thanks in advance.
=========================================================================
Paul L. Della Maggiora    della@lexmark.com

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 1993 00:33:38 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Path MTU Discovery

In article <rturner.741408434@imagen> rturner@imagen.com (Randy Turner) writes:
>
>>>>A host using PMTU Discovery would normally advertise an MSS equal to
>>>>the first-hop MSS; that is, the MTU of the directly connected LAN
>>>>interface, less the TCP+IP header sizes.  Hosts that use RFC1191
>>>>will avoid fragmentation through that mechanism.  Older hosts, at
>>>>least those that comply with RFC1122, will use MIN(received-MSS, 512)
>>>>[I could have the constant wrong] for "non-local" peers, and so
>>>>will not do anything too awful.
>	Wow, that seems awfully inefficient.  Something must be missing
>	from this equation, either that, or one of us is talking about
>	hosts and the other intermediates.

No, the formula is right.  Your math is wrong.  It's less efficient
than using, say, MSS = 1460 (unless the larger MSS causes fragmentation
and that causes trouble).  But the net change in throughput, over a
bandwidth-limited connection, is less than 10%.  (If you are limited
by the rate at which your end-hosts can process packets, then the
performance loss might be larger.)

There is a persistant myth that if one cuts the packet size by a
factor of N, throughput will drop by the same factor.  Anyone with
a junior-high mathematics education can easily prove this wrong.

-Jeff

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Sat, 3 Jul 1993 04:21:24 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Path MTU Discovery

In article <212k52$hel@usenet.pa.dec.com>, mogul@pa.dec.com (Jeffrey Mogul) writes:
> ...
> There is a persistant myth that if one cuts the packet size by a
> factor of N, throughput will drop by the same factor.  Anyone with
> a junior-high mathematics education can easily prove this wrong.


Uh, sorry, but that's inapplicable.

Yes, if you are limited by the medium, changing the packet size does
not change throughput very much.  However, in the case at hand, a
printer controller whose proprieters say cannot keep up with the
medium, changing the packet size by N changes the packet rate by the
same factor, and probably changes the printer's throughput by the same
factor.

This "myth" applies even if you are not medium-limited only because
your system is too busy burning CPU cycles on the application.
Cycles/byte is best approximated by packets/byte, until you get to
quite large packets.  If you do not have enough cycles, you must
reduces packets/byte to improve performance.

Consider that even Van Jacobson's numbers for instructions/TCP segment
are not much different from the cycles needed to copy and checksum 512
byte segments on a 32-bit machine.  (ignoring cache costs, and assuming
you insist on byte copying and checksumming with your CPU)


Vernon Schryver,  vjs@sgi.com

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 93 07:09:54 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

mogul@pa.dec.com (Jeffrey Mogul) writes:
> >In article <ipk632k@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> >Based on the excellent idea of looking at `netstat`, I looked at two
> >servers (mostly netnews), and found in the two days they've been up,
> ...
> Jon clearly argues for turning off checksums only when the underlying
> path is highly reliable (e.g., with uninterrupted CRC protection).
> ...
> None of the netstat numbers posted so far have distinguished between
> local-LAN and remote-LAN checksum errors (nor could they, as far as
> I am aware, because BSD-based systems don't keep separate statistics).
> Unless you can provide some sort of evidence that some of those 57
> bad TCP checksums came from "local" packets, then these numbers don't
> support your side of the argument.
> ...

	Exactly.  Thanks.  As you point out, what's important is how
many of the errors are local versus remote, since remote errors would
be detected under redundant checksum avoidance.  It is tough to get
the correct numbers (that doesn't stop us from looking, but it's
mighty time-consuming - don't expect an answer tomorrow).  Preliminary
digging on netstat numbers from various machines supported the notion
that bad checksums mostly come from remote machines.
	One preliminary thing we did do what sort of patterns of bad
checksums cropped up on DECstations with checksums turned.  The
DECstations' main servers were also DECstations with checksums turned
on.  Now, my idea was that if I was correct and that WANs really are
the major source of errors, there would be fewer logged UDP errors
than logged TCP errors, because most packets sent over WANs are TCP
packets.  On the other hand, most packets that only traverse LANs are
UDP packets.  Thus, the overwhelming majority of errors should show up
in TCP.  This turned out to be the case, even though most packets
overall are UDP packets (so you expect more UDP errors if even a tenth
of errors come from LANs).

							Jon

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 93 07:12:48 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)


	There is always a cost to reliability.  The question is how
much you're willing to trade for how much reliability.  Clearly, more
reliability is always better.  We would all like our computers to
never make mistakes.  However, that is not our primary goal.  It is
trivial to design computer that never makes any mistakes at all - so
long as it doesn't actually have to do anything, it can never make any
mistakes - a brick of lead meets the specs.
	Moving along the (price/performance) / reliability curve, if
you're willing to fork over a few million dollars to buy an extremely
specialized product, you can buy systems with thorough (for today)
fault detection and tolerance.  You will still get bugs and data
corruption on this machine; at most you can hope that they will be
much rarer.  A small number of you reading this note may be reading it
on such a machine.  The majority of you, though, have opted to go way
further down the curve.  You have traded reliability for
price/performance.  You considered a certain amount of unreliability
reasonable.  Some of you went even further and bought the cheapest
clone PC you could lay your hands on, trading the many subtle
incompatibilities of PCs for a low price. 
	So how much reliability is "reasonable?"  The more expensive
an operation is, the less "reasonable"; the more errors it catches,
the more "reasonable."
	I feel that data checksumming for general TCP/IP data
transmission is reasonable, especially given that wide-area links are
often slow and error-prone.  We have not suggested eliminating
software checksums entirely.
	Performing a software data checksum across a LAN is a
different story.  There it is usually secondary to the LAN CRC
implemented in hardware, and given the higher bandwidths, the checksum
is likely to be an imposing overhead.  Yes, both network interfaces
and bridges can cause corrupt packets - but remember, both the CRC and
the bridge/controller have to break for packet corruption to go
undetected.  Of course both happen, but in my experience no more often
than other system problems.
	So, given such a gray area, I think it is reasonable to
propose dropping the software checksum, in the limited case when a
packet is not routed, and allow users to decide whether they want to
pay the cost or not, rather than forcing the cost on everyone.

						Jon

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 93 07:51:27 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

> That outboard checksumming is worthwhile, but only because I also fixed
> things to prevent byte copies.  0.5 cycles/byte is measurable, but not
> significant compared to the cache costs, which are 10 to 500 times
> higher than 0.5cycle/B, even on old R3000 based systems like DEC's.

Well, we're almost in agreement, for once.  One of us must be sick
:-).  The possibility of not even touching the cache is a big
reason why I'm pushing redundant checksum avoidance, though by no
means the only reason - checksumming remains a big factor even in a
Reno-or-earlier copying environment.
	Then again, some numbers you've posted suggest that some of
the memory systems you're playing with are slower relative to the CPU
than the ones in the DECstations and Alphas I deal with (I simply
won't argue over whether SGIs have slower memory systems or faster
CPUs....).

							Jon

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 1993 20:19:14 -0400
From:      masato@access.digex.net (J M Thompson)
To:        comp.protocols.tcp-ip
Subject:   Intermittent IP Packet Loss

We recently experienced a problem of intermittent IP packet loss from
a SUN 690MP (SUNOS 4.3.1??).  The symptoms of the problem manifested
as excessively long response times.  Executing the following ping
command on the SUN690 in question

       ping -s another.host 1000

resulted with the ping command reporting from between 30 to 50 percent
packet loss.

Other pertinent information:
 
  1) The network interface was token ring.
  2) We believe the problem started as a result of a buffer overflow
     in a brouter, but that overflow problem was corrected and the
     problem still persisted.
  3) After the buffer overflow problem was corrected, the IP packet
     loss problem would go away for awhile (30 to 120 minutes) and then
     reappear for awhile.
  4) We experienced the packet loss problem between the SUN690 in question and
     other systems on the same local area network.  Other systems on the
     same local area network did not experience the same problem.
  
At wits end, we rebooted the SUN690 and the problem went away.

Would appreciate any insight that anyone could provide about this problem.


Thanks,  Jim Thompson

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 1993 11:55:32 +0200
From:      mike@horus.ap.mchp.sni.de (Mike Hoffmann)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Logging ftp CLIENT wanted

Hi!

I am looking for an "ftp" client, that will allow logging for accounting
purposes. Best would be syslog-ish, noting, who called up "ftp", and
what actions he did, mainly what files were retrieved from which servers
and what file-size they had.

The ftp clients I retrieved from some Internet anon. ftp sites don't seem
to have any capabilities like that. I am a *bit* reluctant to dive into the
source and build it in myself - but am desperate enough to do so, as I need
it *urgent*

So, if no such beast is around, I would appreciate help and pointers on
where to start. (The ftp source I am using seems to be the current "standard"
client, a "what" gives me a version of 5.28 on ftp.c)

(NB: just to make it clear: I mean the ftp *client*, not the ftpd server, which
does all the logging I could ever want!)

Thanks in advance!
Mike
-- 
Mike Hoffmann - Internet Administrator, Siemens-Nixdorf AG, SNI SU AP 1123
INTERNET: Mike.Hoffmann@ap.mchp.sni.de
"...And I looked, and I saw a fifth rider, riding a purple horse.  It's voice
sang a dirge of happiness, and it wanted to be my neighbor..."
-- Revelations, the verse they left out because it was _too_ _damn_ _scary_.
(tomault+@cs.cmu.edu (Thomas Galen Ault))

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Sat, 3 Jul 1993 18:49:08 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   Why doesn't the HP-UX ftpd allow port numbers < 1024 in PORT command?

We have an IBM AS/400 system which wants to use port numbers just below 1024
in the PORT command sent from the FTP client to the FTP server (ftpd) on the
remote host. The HP-UX ftpd doesn't like this, and responds:

ftp> quote PORT 129,241,4,6,3,255
---> PORT 129,241,4,6,3,255
530 Bad parameters for PORT command.

I checked a bit, and it seems that it's port numbers in the range 513 to
1023 which are not accepted:

ftp> quote PORT 129,241,4,6,0,0
200 PORT command successful.

ftp> quote PORT 129,241,4,6,2,0
200 PORT command successful.

ftp> quote PORT 129,241,4,6,2,1
530 Bad parameters for PORT command.

ftp> quote PORT 129,241,4,6,4,0
---> PORT 129,241,4,6,4,0
200 PORT command successful.

It seems rather likely that this is done in a (misguided) attempt to stay
away from the "reserved" port range. It happens on all 8.0 and 9.0 systems
I have tried it on.

HP, how about reading the FTP spec?  It says nothing about reserved ports.
Can you give us a good reason why your ftpd works like this? Sun's doesn't.
The Ultrix ftpd doesn't.

Also, can you give us a good workaround while you fix the problem?

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Sat, 3 Jul 93 21:55:51 GMT
From:      woods@robohack.UUCP (Greg A. Woods)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Re: TLI

In article <1993Jun26.231521.16079@sporran.uucp> tim@sporran.uucp (Tim Fry) writes:
> In article <C97313.8zx@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
> >	First, whether TLI is on top of STREAMS or not depends entirely on the
> >implementation, which I don't believe was specified. It has nothing to do with
> >TLI per se.
> 
> I concur that the TLI may not be implemented on top of STREAMS, but I have to
> say that I've yet to see an implementation where it wasn't.

See the AT&T 3B1 Starlan-1 package for an example....

BTW, someone earlier "concluded" that RFS & TLI would be slower than
using socket()'s and perhaps they also mentioned NFS being faster too.

This is not (entirely) true for a 3B2.  RFS is quite reasonable on a
3B2, esp. over Starlan-10.  Socket libraries, to the best of my
knowledge, are implemented on top of STREAMS/TLI interfaces, thus
introduce another layer of abstraction to plow through.

NFS, if you can get it, may be faster, but that's got nothing to do
with the underlying transport, but rather that NFS doesn't offer
complete filesystem semantics, where RFS does, and that takes a bit
more effort to do correctly.
-- 
						Greg A. Woods

woods@robohack.UUCP		  VE3TCP	GAW Cons. & UniForum Canada
+1 416 443-1734 [home]				Toronto, Ontario; CANADA

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 93 16:55:13
From:      bataller@dogie.macc.wisc.edu (Erik Bataller)
To:        comp.protocols.ppp,comp.unix.admin,comp.sys.sun.admin,comp.protocols.tcp-ip,comp.sys.sun.apps,comp.sys.sun.hardware
Subject:   dp-2.3 Supra(and/or Prac. Peripherals) modem configuration files

Hello Y'all,
	I have recently setup dp-2.3 on my Sparc 10 model 41 running
SunOS 4.1.3.  I was wondering if any out there had done this and if
they could send me their Supra specific files.  Turns out I am having
a difficult time making the supra talk to much.  I suppose I have become
spoiled, my Practical Peripherals 14.4 fxsa has basically been able to 
automagically attach to most things, that is the full auto-negotiation
at configuration switches have worked well for me.

The files I am interested in are:

	script files
	modem files

for either modem and anything else you may thing would be helpful.

Thanks in advance, Please reply directly to me, I will post a summary.

Erik

--
!!  Erik M. Bataller | Phone: (414) 242-0347 | Univ. of Wi., Osh Kosh 
!!  Academic Computing Services | 800 Algoma Blvd., 307 Dempsey, 
!!  Osh Kosh, Wi. 54901-8602 | Internet: Bataller@sol.acs.uwosh.edu 
!!  Bitnet: Bataller@oshkoshw.bitnet


-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Sun,  4 Jul 93 12:56:00 +0200
From:      rune.mossige@euronetis.no (Rune Mossige)
To:        comp.protocols.tcp-ip
Subject:   SCO 3.2v2.2 -> 3.2v4.1



I've just come onto a very strange problem. We have two SDI 80486 
machines running SCO unix. One is running 3.2v4.1 and the other is 
running 3.2v2.2

I upgrading the 3.2v2.2 box to v4.1, but after the upgrade, I was not 
able to get contact with the network. Nothing at all. No ping, no 
telnet, nothing. I could ping and telnet myself, but nothing else. I 
even copied the whole /etc directory from the working machine, but 
still nothing. I spent several hours looking at various files, and 
could not find anything unusual. In the end I had to reinstall 3.2v2.2 
from the backup tape. The only reason I'd want to upgrade, is to have 
NFS 1.2 with it's NIS utilities. I have to admit that I do not know 
very much about SCO, so there might be something I have missed. I 
followd the manual that told me to first remove NFS, LLI and TCP/IP and 
then install from original discs. I hate to give up, but after spending 
10 hours on saturday, I had yo give up. I've successfully 
installed/upgraded several Sun boxes (SunOS) and RS6000's with AIX, 
and they all work. 

Does anyone have any hints or tips of what I am doing wrong?? Please 
respond with e-mail to
rune.mossige#euronetis.no or
rmossige@halnet.com

Rune Mossige

 * 1st 1.11 #274 * Never let a fool kiss you, or a kiss fool you...

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      04 Jul 1993 20:56:35 GMT
From:      bai@iesd.auc.dk (Bo Nygaard Bai)
To:        comp.protocols.tcp-ip
Subject:   How to trace duplicate IP addresses using a PC running DOS or SCO?

I have a problem with my two SCO Unix boxes reporting duplicate IP
addresses on each other. (A reports that B's IP is duplicated and vise
versa)

Is there any free software that i can use to trace the Ethernet
address of the (other :-) offender? 

My network administrator is sure that the IP numbers i use are free,
so it could be a SCO Unix problem. Has anybody had similar problems on
SCO. I hate the fact that SCO does not report the two ethernet
numbers. They must have them to detect the duplicate....DAMIT!

Any help will be appreciated. I'll summarize if i get enough info.

--
.___ o .__ |         | Bo Nygaard Bai  | Department of Computer Science ,_//(
|__. | |   |/        |                 | University of Aalborg (AUC)   /  |  \
___| | |__ |\ nature | bai@iesd.auc.dk | DENMARK                       A  U  C

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Sun, 4 Jul 1993 23:09:04 GMT
From:      royc@rbdc.wsnc.org (Roy Crabtree)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Re: TLI

In article <1993Jul3.215551.2941@robohack.UUCP> woods@robohack.UUCP (Greg A. Woods) writes:
>In article <1993Jun26.231521.16079@sporran.uucp> tim@sporran.uucp (Tim Fry) writes:
>> In article <C97313.8zx@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>> >	First, whether TLI is on top of STREAMS or not depends entirely on the
>> >implementation, which I don't believe was specified. It has nothing to do with
>> >TLI per se.
>> 
>> I concur that the TLI may not be implemented on top of STREAMS, but I have to
>> say that I've yet to see an implementation where it wasn't.
>
>See the AT&T 3B1 Starlan-1 package for an example....
>
>BTW, someone earlier "concluded" that RFS & TLI would be slower than
>using socket()'s and perhaps they also mentioned NFS being faster too.

	I was one.

>
>This is not (entirely) true for a 3B2.  RFS is quite reasonable on a
>3B2, esp. over Starlan-10.  Socket libraries, to the best of my

	I did no tmentiuon RFS being slow  on STARLAN; I did mention
	NFS usually outperforming it, speedwise.  Although NFS CPU
	usage tends to be about 35% higher on a StarServer E 2SMP
	(4.0v3.1, TCPiP 4.2.1.2).

>knowledge, are implemented on top of STREAMS/TLI interfaces, thus

	RFS is on top of TLI; TLI is on top of STREAMS on 3B2.

	Sockets are on top of STREAM, but not on top of TLI
	as best I understand it; what causes the confusion is
	that TLI addresses via the protocol family specifications
	have a mapping that is 1:1 onto the TCP/IP sockets points;

		\x0002040238000015 000000000000....
			0002	TCP/IP address family type (INET)
			0402	TCP/IP port number (1026 for RFS in this case)
			38000015 being the internet address in hex (my machine
					at work; who can see what's wrong?
			00000 ....	enough hex 0's to fill 128 bits;
				presumed if not specified.

			
	this does _not_ imply that sockets "goes through:" TLI

		although it may, and in this case it might if my
		memory is incorrect

	to do the work.   TCP/IP does NOT go through TLI (which
	is what sockets uses); TLI goes on top of TCP/IP

>introduce another layer of abstraction to plow through.

	I do not believe this is correct, though it could be.

>
>NFS, if you can get it, may be faster, but that's got nothing to do

	UNless the RFS TLI to TCP/IP intersection is just a bit
	slower than direct TCP/IP connection.

>with the underlying transport, but rather that NFS doesn't offer
>complete filesystem semantics, where RFS does, and that takes a bit

	AGreed; I prefer RFS (but for several strangenesses, like
	'vi' startup  running slowly) because I Like to
	access remote devices transparently; remsh mach dd of=devname
	does not dot it for me; all my experience with 'remsh'
	has the sucker dying afdter about 45-60MB traffic.

>more effort to do correctly.

	Yes.  And as wel, CPU usage is a bit beter.

	Although it might interest you to know that RPC calls
	in theNFS domain on StarServer apparently bind through TLI.

		I get error messages on this.

>-- 
>						Greg A. Woods
>
>woods@robohack.UUCP		  VE3TCP	GAW Cons. & UniForum Canada
>+1 416 443-1734 [home]				Toronto, Ontario; CANADA


royc

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Mon, 05 Jul 1993 01:03:41 GMT
From:      mark@taylor.uucp (Mark A. Davis)
To:        comp.protocols.ppp,comp.unix.admin,comp.sys.sun.admin,comp.protocols.tcp-ip,comp.sys.sun.apps,comp.sys.sun.hardware
Subject:   Re: dp-2.3 Supra(and/or Prac. Peripherals) modem configuration files

bataller@dogie.macc.wisc.edu (Erik Bataller) writes:

>Hello Y'all,
>	I have recently setup dp-2.3 on my Sparc 10 model 41 running
>SunOS 4.1.3.  I was wondering if any out there had done this and if
>they could send me their Supra specific files.  Turns out I am having
>a difficult time making the supra talk to much.

My advice is to drop the Supra NOW.  I have been fighting two of them for
almost a year.  The speakers died, they have trouble negotiating with
other modems, they "freak out" too often, etc....

> I suppose I have become
>spoiled, my Practical Peripherals 14.4 fxsa has basically been able to 
>automagically attach to most things, that is the full auto-negotiation
>at configuration switches have worked well for me.

EXACTLY.  I just TRASHED one of the Supra's and replaced it with a 
Practical Perhiperals and it works great now....  I just which it had a
display like the Supra's.

-- 
  /--------------------------------------------------------------------------\
  | Mark A. Davis    | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 |
  | Sys.Administrator|  Computer Services   | mark@taylor.wyvern.com   .uucp |
  \--------------------------------------------------------------------------/

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Jul 1993 02:08:44 GMT
From:      bcutter@paradyne.com (Brooks Cutter)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

In <C95Jxq.8Go@wang.com> Tom Fitzgerald <fitz@wang.com> wrote:
>> each ip address should have it's own, unique hostname. also, be sure to 
>> modify rc and/or rc.local to ifconfig both addresses.
>Could you expand on this a little?  The one-name-per-host advocates have
>posted believable explanations for their viewpoint; one-name-per-interface
>fans seem to be posting bald statements with no explanation.

The above wasn't my posting but...

The reason why we are using a unique name for each interface is because
we have those servers provide NIS server to clients on multiple segments..
If "server" had interfaces on 1, 2, and 3 - then by only using one name
for all three interfaces, all the clients on two segments will go through
the router to access the server...  The answer is of course to use RIP
so the clients will discover the local interfaces - but there are problems
with RIP in our environment and we haven't had the time to spend solving
them - And we need a solution now.

So what we currently do is call one of the interfaces "server" and
setup names or aliases for each of the interface with the hostname (ex:
"server") and append the interface number ("server1", etc) -- Then we
setup the client's fstab, etc to use the local segment number, and
in the automounter setup the interfaces to look like replicated
servers - so it pings the RPC Null procedure, and the first one to
respond (presumably the local interface), gets service...

We'd like to use DNS to resolve hostname to IP address mappings -
but I don't believe (or I don't know) that DNS will optimize
the returned address based on the client's IP address (ie:
try to return a server IP address on the same segment as the
requestor)

(I put two interface numbers (with the same name) in our NIS hosts file
and did a ypmatch on the name - the address returned depended on the
order in the host file, unfortunately...)

>One-name-per-host works fine here.  I can see why "sortlist" might be
>needed in some /etc/named.boot files, to prevent X.25 interfaces from being
>favored over FDDI interfaces, but that works.  (In fact, I use sortlist all
>over the place, listing networks from fastest to slowest.)

We plan to put all our servers on a private FDDI segment to support
compute servers, and for automounting on the servers... The NIS servers
and client use the same hosts file - We don't want the servers talking
over 10BaseT and we don't want the clients going through the router to 
get on the FDDI segment, when they are locally attached via UTP...
It's the same problem - and unfortunately I only see the current solution..

(I wonder if Hesoid does Name/address mappings and if so does 
optimization based on segment number...?)

-- 
Brooks Cutter    (I: bcutter@paradyne.com) (U: ...uunet!pdn!bcutter)
Unix System Administrator, Engineering Services
        AT&T Paradyne, Largo Florida
(Opinions expressed are my own and do not reflect those of my employer)

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Jul 1993 13:26:44 EDT
From:      Peter M. Weiss <PMW1@psuvm.psu.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: what is a router anyway?

Many Q&A concerning basic networking questions have been stored in a
file maintained by John Wobus of Syracuse University.

"syr.edu also has a copy of the BIG-LAN "FAQ" memo (answers to frequently
asked questions) under the path information/big-lan/big-lan.faq"

I'm enclosing the Table of Contents (see #5.3).
     -------
BIG-LAN Frequently Asked Questions

Last Updated: February 14, 1993

Acknowledgements: A lot of people provided information for me and I freely
admit that I have not recorded the list of names.  Thanks to all.

Contents
--------
I. About BIG-LAN
II. Explanation of this Memo
III. Sources of Information on Campus Networks
  1. Must-Read Sources
  2. A Few General Sources
  3. LISTSERV Mailing Lists
  4. Internet Mailing Lists
  5. USENET/Netnews Groups
  6. Anonymous FTP-based Archive Sites
  7. LISTSERV-based Archive Sites
  8. RFCs (Internet "Request For Comments")
  9. Other Useful Online Papers
  10. Sources of Protocol Documents
  11. Useful Free Software
  12. Books
  13. Periodicals
  14. Training Courses
  15. Conferences
IV. Basic Glossary on Campus Networks
V. Frequently Asked Questions on Campus Networks
  1. What is the difference between Ethernet and IEEE 802.3?
  2. What is encapsulation?  What do I have to know about it?
  3. How do I know whether to use a router or a bridge?
  4. How do I know whether to use a bridge or a repeater?  How many
     repeaters may I put on an Ethernet?
  5. Should I use "manageable" hubs, concentrators, etc on my LAN?
  6. Which LAN technology should I use?  Arcnet?  FDDI?  Token Ring?  10BASE-T?
  7. What is the ideal cable to install in a new building?
  8. What is the ideal cable to install between buildings on a campus?
  9. Whose routers are recommended?
  10. Whose bridges are recommended?
  11. Whose Ethernet equipment are recommended?
  12. Whose Token Ring equipment are recommended?
  13. Whose FDDI equipment are recommended?
  14. What PC network software is recommended?
  15. What protocols should run on a campus-wide LAN?
  16. What software is recommended for managing a campus-wide LAN?
  17. What terminal server is recommended?
  18. Whose troubleshooting equipment are recommended?
  19. What security products should I buy?
  20. Should the names of devices on my campus LAN have subdomains?
  21. Should client stations use POP?  Should they use just SMTP?  Should
      I use some non-TCP/IP protocol for mail to/from client stations?
  22. Should I enable SQE/heartbeat?


/Pete (pmw1@psuvm.psu.edu)
--
Peter M. Weiss                                            +1 814 863 1843
31 Shields Bldg. -- Penn State Univ -- University Park, PA USA 16802-1202

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Jul 1993 10:15:25 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: How to trace duplicate IP addresses using a PC running DOS or SCO?

> I have a problem with my two SCO Unix boxes reporting duplicate IP
> addresses on each other. (A reports that B's IP is duplicated and vise
> versa)
> 
> Is there any free software that i can use to trace the Ethernet
> address of the (other :-) offender? 

Sure, if you have a Sun or DEC workstation available.

On the Sun, you have 'etherfind' available as standard (or 'snoop' if you
run Solaris 2.x). On both Sun and DEC workstations you can run the wonderful
'tcpdump' program, available from ftp.ee.lbl.gov. tcpdump can help you a lot
when debugging network problems. I have enclosed the manual page below.

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no
----------------------------------------------------------------------
.\" @(#) $Header: tcpdump.1,v 1.40 92/01/29 16:56:02 mccanne Exp $ (LBL)
.\"
.\" Copyright (c) 1988, 1989, 1990, 1991, 1992
.\" The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that: (1) source code distributions
.\" retain the above copyright notice and this paragraph in its entirety, (2)
.\" distributions including binary code include the above copyright notice and
.\" this paragraph in its entirety in the documentation or other materials
.\" provided with the distribution, and (3) all advertising materials mentioning
.\" features or use of this software display the following acknowledgement:
.\" ``This product includes software developed by the University of California,
.\" Lawrence Berkeley Laboratory and its contributors.'' Neither the name of
.\" the University nor the names of its contributors may be used to endorse
.\" or promote products derived from this software without specific prior
.\" written permission.
.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
.\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
.\"
.TH TCPDUMP 1  "4 Jan 1992"
.SH NAME
tcpdump \- dump traffic on a network
.SH SYNOPSIS
.na
.B tcpdump
[
.B \-deflnNOpqStvx
] [
.B \-c
.I count
] [
.B \-F
.I file
]
.br
.ti +8
[
.B \-i
.I interface
] [
.B \-r
.I file
]
[
.B \-s
.I snaplen
]
.br
.ti +8
[
.B \-w
.I file
]
.I expression
.br
.ad
.SH DESCRIPTION
.LP
\fITcpdump\fP prints out the headers of packets on a network interface
that match the boolean \fIexpression\fP.
.B Under SunOS:
You must be root to invoke \fItcpdump\fP or it must be installed
setuid to root.
.B Under Ultrix:
Any user can invoke \fItcpdump\fP once the super-user has enabled
promiscuous-mode operation using
.IR pfconfig (8).
.B Under BSD:
Access is controlled by the permissions on
.I /dev/bpf0,
etc.
.SH OPTIONS
.TP
.B \-c
Exit after receiving \fIcount\fP packets.
.TP
.B \-d
Dump the compiled packet-matching code to standard output and stop.
.TP
.B \-e
Print the link-level header on each dump line.
.TP
.B \-f
Print `foreign' internet addresses numerically rather than symbolically
(this option is intended to get around serious brain damage in
Sun's yp server \(em usually it hangs forever translating non-local
internet numbers).
.TP
.B \-F
Use \fIfile\fP as input for the filter expression.
An additional expression given on the command line is ignored.
.TP
.B \-i
Listen on \fIinterface\fP.
If unspecified, \fItcpdump\fP searches the system interface list for the
lowest numbered, configured up interface (excluding loopback).
Ties are broken by choosing the earliest match.
.TP
.B \-l
Make stdout line buffered.  Useful if you want to see the data
while capturing it.  E.g.,
.br
``tcpdump\ \ \-l\ \ |\ \ tee dat'' or
``tcpdump\ \ \-l \ \ > dat\ \ &\ \ tail\ \ \-f\ \ dat''.
.TP
.B \-n
Don't convert addresses (i.e., host addresses, port numbers, etc.) to names.
.TP
.B \-N
Don't print domain name qualification of host names.  E.g.,
if you give this flag then \fItcpdump\fP will print ``nic''
instead of ``nic.ddn.mil''.
.TP
.B \-O
Do not run the packet-matching code optimizer.  This is useful only
if you suspect a bug in the optimizer.
.TP
.B \-p
\fIDon't\fP put the interface
into promiscuous mode.  Note that the interface might be in promiscuous
for some other reason; hence, `-p' cannot be used as an abbreviation for
`ether host {localhost} or broadcast'.
.TP
.B \-q
Quick (quiet?) output.  Print less protocol information so output
lines are shorter.
.TP
.B \-r
Read packets from \fIfile\fR (which was created with the -w option).
Standard input is used if \fIfile\fR is ``-''.
.TP
.B \-s
Snarf \fIsnaplen\fP bytes of data from each packet rather than the
default of 68 (with NIT, the minimum is actually 96).
68 bytes is adequate for IP, ICMP, TCP
and UDP but may truncate protocol information from name server and NFS
packets (see below).  Packets truncated because of a limited snapshot
are indicated in the output with ``[|\fIproto\fP]'', where \fIproto\fP
is the name of the protocol level at which the truncation has occured.
Note that taking larger snapshots both increases
the amount of time it takes to process packets and, effectively,
decreases the amount of packet buffering.  This may cause packets to be
lost.  You should limit \fIsnaplen\fP to the smallest number that will
capture the protocol information you're interested in.
.TP
.B \-S
Print absolute, rather than relative, TCP sequence numbers.
.TP
.B \-t
\fIDon't\fP print a timestamp on each dump line.
.TP
.B \-tt
Print an unformatted timestamp on each dump line.
.TP
.B \-v
(Slightly more) verbose output.  For example, the time to live
and type of service information in an IP packet is printed.
.TP
.B \-w
Write the raw packets to \fIfile\fR rather than parsing and printing
them out.  They can later be printed with the \-r option.
Standard output is used if \fIfile\fR is ``-''.
.TP
.B \-x
Print each packet (minus its link level header) in hex.
The smaller of the entire packet or
.I snaplen
bytes will be printed.
.IP "\fI expression\fP"
.RS
selects which packets will be dumped.  If no \fIexpression\fP
is given, all packets on the net will be dumped.  Otherwise,
only packets for which \fIexpression\fP is `true' will be dumped.
.LP
The \fIexpression\fP consists of one or more
.I primitives.
Primitives usually consist of an
.I id
(name or number) preceded by one or more qualifiers.  There are three
different kinds of qualifier:
.IP \fItype\fP
qualifiers say what kind of thing the id name or number refers to.
Possible types are
.BR host ,
.B net
and
.BR port .
E.g., `host foo', `net 128.3', `port 20'.  If there is no type
qualifier,
.B host
is assumed.
.IP \fIdir\fP
qualifiers specify a particular tranfer direction to and/or from
.I id.
Possible directions are
.BR src ,
.BR dst ,
.B "src or dst"
and
.BR "src and dst" .
E.g., `src foo', `dst net 128.3', `src or dst port ftp-data'.  If
there is no dir qualifier,
.B "src or dst"
is assumed.
.IP \fIproto\fP
qualifiers restrict the match to a particular protocol.  Possible
protos are:
.BR ether ,
.BR ip ,
.BR arp ,
.BR rarp ,
.B tcp
and
.BR udp .
E.g., `ether src foo', `arp net 128.3', `tcp port 21'.  If there is
no proto qualifier, all protocols consistent with the type are
assumed.  E.g., `src foo' means `(ip or arp or rarp) src foo'
(except the latter is not legal syntax), `net bar' means `(ip or
arp or rarp) net bar' and `port 53' means `(tcp or udp) port 53'.
.LP
In addition to the above, there are some special `primitive' keywords
that don't follow the pattern:
.BR gateway ,
.BR broadcast ,
.BR less ,
.B greater
and arithmetic expressions.  All of these are described below.
.LP
More complex filter expressions are built up by using the words
.BR and ,
.B or
and
.B not
to combine primitives.  E.g., `host foo and not port ftp and not port ftp-data'.
To save typing, identical qualifier lists can be omitted.  E.g.,
`tcp dst port ftp or ftp-data or domain' is exactly the same as
`tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'.
.LP
Allowable primitives are:
.IP "\fBdst host \fIhost\fR"
True if the IP destination field of the packet is \fIhost\fP,
which may be either an address or a name.
.IP "\fBsrc host \fIhost\fR"
True if the IP source field of the packet is \fIhost\fP.
.IP "\fBhost \fIhost\fP
True if either the IP source or destination of the packet is \fIhost\fP.
Any of the above host expressions can be prepended with the keywords,
\fBip\fP, \fBarp\fP, or \fBrarp\fP as in:
.in +.5i
.nf
\fBip host \fIhost\fR
.fi
.in -.5i
which is equivalent to:
.in +.5i
.nf
\fBether proto \fI\\ip\fB and host \fIhost\fR
.fi
.in -.5i
If \fIhost\fR is a name with multiple IP addresses, each address will
be checked for a match.
.IP "\fBether dst \fIehost\fP
True if the ethernet destination address is \fIehost\fP.  \fIEhost\fP
may be either a name from /etc/ethers or a number (see
.IR ethers (3N)
for numeric format).
.IP "\fBether src \fIehost\fP
True if the ethernet source address is \fIehost\fP.
.IP "\fBether host \fIehost\fP
True if either the ethernet source or destination address is \fIehost\fP.
.IP "\fBgateway\fP \fIhost\fP
True if the packet used \fIhost\fP as a gateway.  I.e., the ethernet
source or destination address was \fIhost\fP but neither the IP source
nor the IP destination was \fIhost\fP.  \fIHost\fP must be a name and
must be found in both /etc/hosts and /etc/ethers.  (An equivalent
expression is
.in +.5i
.nf
\fBether host \fIehost \fBand not host \fIhost\fR
.fi
.in -.5i
which can be used with either names or numbers for \fIhost / ehost\fP.)
.IP "\fBdst net \fInet\fR"
True if the IP destination address of the packet has a network
number of \fInet\fP, which may be either an address or a name.
.IP "\fBsrc net \fInet\fR"
True if the IP source address of the packet has a network
number of \fInet\fP.
.IP "\fBnet \fInet\fR"
True if either the IP source or destination address of the packet has a network
number of \fInet\fP.
.IP "\fBdst port \fIport\fR"
True if the packet is ip/tcp or ip/udp and has a
destination port value of \fIport\fP.
The \fIport\fP can be a number or a name used in /etc/services (see
.IR tcp (4P)
and
.IR udp (4P)).
If a name is used, both the port
number and protocol are checked.  If a number or ambiguous name is used,
only the port number is checked (e.g., \fBdst port 513\fR will print both
tcp/login traffic and udp/who traffic, and \fBport domain\fR will print
both tcp/domain and udp/domain traffic).
.IP "\fBsrc port \fIport\fR"
True if the packet has a source port value of \fIport\fP.
.IP "\fBport \fIport\fR"
True if either the source or destination port of the packet is \fIport\fP.
Any of the above port expressions can be prepended with the keywords,
\fBtcp\fP or \fBudp\fP, as in:
.in +.5i
.nf
\fBtcp src port \fIport\fR
.fi
.in -.5i
which matches only tcp packets.
.IP "\fBless \fIlength\fR"
True if the packet has a length less than or equal to \fIlength\fP.
This is equivalent to:
.in +.5i
.nf
\fBlen <= \fIlength\fP.
.fi
.in -.5i
.IP "\fBgreater \fIlength\fR"
True if the packet has a length greater than or equal to \fIlength\fP.
This is equivalent to:
.in +.5i
.nf
\fBlen >= \fIlength\fP.
.fi
.in -.5i
.IP "\fBip proto \fIprotocol\fR"
True if the packet is an ip packet (see
.IR ip (4P))
of protocol type \fIprotocol\fP.
\fIProtocol\fP can be a number or one of the names
\fIicmp\fP, \fIudp\fP, \fInd\fP, or \fItcp\fP.
Note that the identifiers \fItcp\fP, \fIudp\fP, and \fIicmp\fP are also
keywords and must be escaped via backslash (\\), which is \\\\ in the C-shell.
.IP "\fBether broadcast\fR"
True if the packet is an ethernet broadcast packet.  The \fIether\fP
keyword is optional.
.IP "\fBip broadcast\fR"
True if the packet is an IP broadcast packet.  It checks for both
the all-zeroes and all-ones broadcast conventions, and looks up
the local subnet mask.
.IP "\fBether multicast\fR"
True if the packet is an ethernet multicast packet.  The \fIether\fP
keyword is optional.
This is shorthand for `\fBether[0] & 1 != 0\fP'.
.IP "\fBip multicast\fR"
True if the packet is an IP multicast packet.
.IP  "\fBether proto \fIprotocol\fR"
True if the packet is of ether type \fIprotocol\fR.
\fIProtocol\fP can be a number or a name like
\fIip\fP, \fIarp\fP, or \fIrarp\fP.
Note these identifiers are also keywords
and must be escaped via backslash (\\).
.IP "\fBip\fR, \fBarp\fR, \fBrarp\fR"
Abbreviations for:
.in +.5i
.nf
\fBether proto \fIp\fR
.fi
.in -.5i
where \fIp\fR is one of the above protocols.
.IP  "\fBtcp\fR, \fBudp\fR, \fBicmp\fR"
Abbreviations for:
.in +.5i
.nf
\fBip proto \fIp\fR
.fi
.in -.5i
where \fIp\fR is one of the above protocols.
.IP  "\fIexpr relop expr\fR"
True if the relation holds, where \fIrelop\fR is one of >, <, >=, <=, =, !=,
and \fIexpr\fR is an arithmetic expression composed of integer constants
(expressed in standard C syntax), the normal binary operators
[+, -, *, /, &, |], a length operator, and special packet data accessors.
To access
data inside the packet, use the following syntax:
.in +.5i
.nf
\fIproto\fB [ \fIexpr\fB : \fIsize\fB ]\fR
.fi
.in -.5i
\fIProto\fR is one of \fBether, ip, arp, rarp, tcp, udp, \fRor \fBicmp\fR, and
indicates the protocol layer for the index operation.
The byte offset, relative to the indicated protocol layer, is
given by \fIexpr\fR.
\fISize\fR is optional and indicates the number of bytes in the
field of interest; it can be either one, two, or four, and defaults to one.
The length operator, indicated by the keyword \fBlen\fP, gives the
length of the packet.

For example, `\fBether[0] & 1 != 0\fP' catches all multicast traffic.
The expression `\fBip[0] & 0xf != 5\fP'
catches all IP packets with options. The expression
`\fBip[2:2] & 0x1fff = 0\fP'
catches only unfragmented datagrams and frag zero of fragmented datagrams.
This check is implicitly applied to the \fBtcp\fP and \fBudp\fP
index opertations.
For instance, \fBtcp[0]\fP always means the first
byte of the TCP \fIheader\fP, and never means the first byte of an
intervening fragment.
.LP
Primitives may be combined using:
.IP
A parenthesized group of primitives and operators
(parentheses are special to the Shell and must be escaped).
.IP
Negation (`\fB!\fP' or `\fBnot\fP').
.IP
Concatenation (`\fBand\fP').
.IP
Alternation (`\fBor\fP').
.LP
Negation has highest precedence.
Alternation and concatenation have equal precedence and associate
left to right.  Note that explicit \fBand\fR tokens, not juxtaposition,
are now required for concatenation.
.LP
If an identifier is given without a keyword, the most recent keyword
is assumed.
For example,
.in +.5i
.nf
\fBnot host vs and ace\fR
.fi
.in -.5i
is short for
.in +.5i
.nf
\fBnot host vs and host ace\fR
.fi
.in -.5i
which should not be confused with
.in +.5i
.nf
\fBnot ( host vs or ace )\fR
.fi
.in -.5i
.LP
Expression arguments can be passed to tcpdump as either a single argument
or as multiple arguments, whichever is more convenient.
Generally, if the expression contains Shell metacharacters, it is
easier to pass it as a single, quoted argument.
Multiple arguments are concatenated with spaces before being parsed.
.SH EXAMPLES
.LP
To print all packets arriving at or departing from \fIsundown\fP:
.RS
.nf
\fBtcpdump host sundown\fP
.fi
.RE
.LP
To print traffic between \fIhelios\fR and either \fIhot\fR or \fIace\fR:
.RS
.nf
\fBtcpdump host helios and \\( hot or ace \\)\fP
.fi
.RE
.LP
To print all IP packets between \fIace\fR and any host except \fIhelios\fR:
.RS
.nf
\fBtcpdump ip host ace and not helios\fP
.fi
.RE
.LP
To print all traffic between local hosts and hosts at Berkeley:
.RS
.nf
.B
tcpdump net ucb-ether
.fi
.RE
.LP
To print all ftp traffic through internet gateway \fIsnup\fP:
(note that the expression is quoted to prevent the shell from
(mis-)interpreting the parentheses):
.RS
.nf
.B
tcpdump 'gateway snup and (port ftp or ftp-data)'
.fi
.RE
.LP
To print traffic neither sourced from nor destined for local hosts
(if you gateway to one other net, this stuff should never make it
onto your local net).
.RS
.nf
.B
tcpdump ip and not net \fIlocalnet\fP
.fi
.RE
.LP
To print the start and end packets (the SYN and FIN packets) of each
TCP conversation that involves a non-local host.
.RS
.nf
.B
tcpdump 'tcp[13] & 3 != 0 and not src and dst net \fIlocalnet\fP'
.fi
.RE
.LP
To print IP packets longer than 576 bytes sent through gateway \fIsnup\fP:
.RS
.nf
.B
tcpdump 'gateway snup and ip[2:2] > 576'
.fi
.RE
.LP
To print IP broadcast or multicast packets that were
.I not
sent via ethernet broadcast or multicast:
.RS
.nf
.B
tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
.fi
.RE
.LP
To print all ICMP packets that are not echo requests/replies (i.e., not
ping packets):
.RS
.nf
.B
tcpdump 'icmp[0] != 8 and icmp[0] != 0"
.fi
.RE
.SH OUTPUT FORMAT
.LP
The output of \fItcpdump\fP is protocol dependent.  The following
gives a brief description and examples of most of the formats.
.de HD
.sp 1.5
.B
..
.HD
Link Level Headers
.LP
If the '-e' option is given, the link level header is printed out.
On ethernets, the source and destination addresses, protocol,
and packet length are printed.
.LP
\fI(N.B.: The following description assumes familiarity with
the SLIP compression algorithm described in RFC-1144.)\fP
.LP
On SLIP links, a direction indicator (``I'' for inbound, ``O'' for outbound),
packet type, and compression information are printed out.
The packet type is printed first.
The three types are \fIip\fP, \fIutcp\fP, and \fIctcp\fP.
No further link information is printed for \fIip\fR packets.
For TCP packets, the connection identifier is printed following the type.
If the packet is compressed, its encoded header is printed out.
The special cases are printed out as
\fB*S+\fIn\fR and \fB*SA+\fIn\fR, where \fIn\fR is the amount by which
the sequence number (or sequence number and ack) has changed.
If it is not a special case,
zero or more changes are printed.
A change is indicated by U (urgent pointer), W (window), A (ack),
S (sequence number), and I (packet ID), followed by a delta (+n or -n),
or a new value (=n).
Finally, the amount of data in the packet and compressed header length
are printed.
.LP
For example, the following line shows an outbound compressed TCP packet,
with an implicit connection identifier; the ack has changed by 6,
the sequence number by 49, and the packet ID by 6; there are 3 bytes of
data and 6 bytes of compressed header:
.RS
.nf
\fBO ctcp * A+6 S+49 I+6 3 (6)\fP
.fi
.RE
.HD
ARP/RARP Packets
.LP
Arp/rarp output shows the type of request and its arguments.  The
format is intended to be self explanatory.
Here is a short sample taken from the start of an `rlogin' from
host \fIrtsg\fP to host \fIcsam\fP:
.RS
.nf
.sp .5
\f(CWarp who-has csam tell rtsg
arp reply csam is-at CSAM\fP
.sp .5
.fi
.RE
The first line says that rtsg sent an arp packet asking
for the ethernet address of internet host csam.  Csam
replies with its ethernet address (in this example, ethernet addresses
are in caps and internet addresses in lower case).
.LP
This would look less redundant if we had done \fBtcpdump \-n\fP:
.RS
.nf
.sp .5
\f(CWarp who-has 128.3.254.6 tell 128.3.254.68
arp reply 128.3.254.6 is-at 02:07:01:00:01:c4\fP
.fi
.RE
.LP
If we had done \fBtcpdump \-e\fP, the fact that the first packet is
broadcast and the second is point-to-point would be visible:
.RS
.nf
.sp .5
\f(CWRTSG Broadcast 0806  64: arp who-has csam tell rtsg
CSAM RTSG 0806  64: arp reply csam is-at CSAM\fP
.sp .5
.fi
.RE
For the first packet this says the ethernet source address is RTSG, the
destination is the broadcast address, the type field
contained hex 0806 (type ETHER_ARP) and the total length was 64 bytes.
.HD
TCP Packets
.LP
\fI(N.B.:The following description assumes familiarity with
the TCP protocol described in RFC-793.  If you are not familiar
with the protocol, neither this description nor tcpdump will
be of much use to you.)\fP
.LP
The general format of a tcp protocol line is:
.RS
.nf
.sp .5
\fIsrc > dst: flags data-seqno ack window urgent options\fP
.sp .5
.fi
.RE
\fISrc\fP and \fIdst\fP are the source and destination IP
addresses and ports.  \fIFlags\fP are some combination of S (SYN),
F (FIN), P (PUSH) or R (RST) or a single `.' (no flags).
\fIData-seqno\fP describes the portion of sequence space covered
by the data in this packet (see example below).
\fIAck\fP is sequence number of the next data expected the other
direction on this connection.
\fIWindow\fP is the number of bytes of receive buffer space available
the other direction on this connection.
\fIUrg\fP indicates there is `urgent' data in the packet.
\fIOptions\fP are tcp options enclosed in angle brackets (e.g., <mss 1024>).
.LP
\fISrc, dst\fP and \fIflags\fP are always present.  The other fields
depend on the contents of the packet's tcp protocol header and
are output only if appropriate.
.LP
Here is the opening portion of an rlogin from host \fIrtsg\fP to
host \fIcsam\fP.
.RS
.nf
.sp .5
\s-2\f(CWrtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
rtsg.1023 > csam.login: . ack 1 win 4096
rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
csam.login > rtsg.1023: . ack 2 win 4096
rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1\fP\s+2
.sp .5
.fi
.RE
The first line says that tcp port 1023 on rtsg sent a packet
to port \fIlogin\fP
on csam.  The \fBS\fP indicates that the \fISYN\fP flag was set.
The packet sequence number was 768512 and it contained no data.
(The notation is `first:last(nbytes)' which means `sequence
numbers \fIfirst\fP
up to but not including \fIlast\fP which is \fInbytes\fP bytes of user data'.)
There was no piggy-backed ack, the available receive window was 4096
bytes and there was a max-segment-size option requesting an mss of
1024 bytes.
.LP
Csam replies with a similar packet except it includes a piggy-backed
ack for rtsg's SYN.  Rtsg then acks csam's SYN.  The `.' means no
flags were set.
The packet contained no data so there is no data sequence number.
Note that the ack sequence
number is a small integer (1).  The first time \fBtcpdump\fP sees a
tcp `conversation', it prints the sequence number from the packet.
On subsequent packets of the conversation, the difference between
the current packet's sequence number and this initial sequence number
is printed.  This means that sequence numbers after the
first can be interpreted
as relative byte positions in the conversation's data stream (with the
first data byte each direction being `1').  `-S' will override this
feature, causing the original sequence numbers to be output.
.LP
On the 6th line, rtsg sends csam 19 bytes of data (bytes 2 through 20
in the rtsg \(-> csam side of the conversation).
The PUSH flag is set in the packet.
On the 7th line, csam says it's received data sent by rtsg up to
but not including byte 21.  Most of this data is apparently sitting in the
socket buffer since csam's receive window has gotten 19 bytes smaller.
Csam also sends one byte of data to rtsg in this packet.
On the 8th and 9th lines,
csam sends two bytes of urgent, pushed data to rtsg.
.HD
.B
UDP Packets
.LP
UDP format is illustrated by this rwho packet:
.RS
.nf
.sp .5
\f(CWactinide.who > broadcast.who: udp 84\fP
.sp .5
.fi
.RE
This says that port \fIwho\fP on host \fIactinide\fP sent a udp
datagram to port \fIwho\fP on host \fIbroadcast\fP, the Internet
broadcast address.  The packet contained 84 bytes of user data.
.LP
Some UDP services are recognized (from the source or destination
port number) and the higher level protocol information printed.
In particular, Domain Name service requests (RFC-1034/1035) and Sun
RPC calls (RFC-1050) to NFS.
.HD
UDP Name Server Requests
.LP
\fI(N.B.:The following description assumes familiarity with
the Domain Service protocol described in RFC-1035.  If you are not familiar
with the protocol, the following description will appear to be written
in greek.)\fP
.LP
Name server requests are formatted as
.RS
.nf
.sp .5
\fIsrc > dst: id op? flags qtype qclass name (len)\fP
.sp .5
\f(CWh2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)\fP
.sp .5
.fi
.RE
Host \fIh2opolo\fP asked the domain server on \fIhelios\fP for an
address record (qtype=A) associated with the name \fIucbvax.berkeley.edu.\fP
The query id was `3'.  The `+' indicates the \fIrecursion desired\fP flag
was set.  The query length was 37 bytes, not including the UDP and
IP protocol headers.  The query operation was the normal one, \fIQuery\fP,
so the op field was omitted.  If the op had been anything else, it would
have been printed between the `3' and the `+'.
Similarly, the qclass was the normal one,
\fIC_IN\fP, and omitted.  Any other qclass would have been printed
immediately after the `A'.
.LP
A few anomalies are checked and may result in extra fields enclosed in
square brackets:  If a query contains an answer, name server or
authority section,
.IR ancount ,
.IR nscount ,
or
.I arcount
are printed as `[\fIn\fPa]', `[\fIn\fPn]' or  `[\fIn\fPau]' where \fIn\fP
is the appropriate count.
If any of the response bits are set (AA, RA or rcode) or any of the
`must be zero' bits are set in bytes two and three, `[b2&3=\fIx\fP]'
is printed, where \fIx\fP is the hex value of header bytes two and three.
.HD
UDP Name Server Responses
.LP
Name server responses are formatted as
.RS
.nf
.sp .5
\fIsrc > dst:  id op rcode flags a/n/au type class data (len)\fP
.sp .5
\f(CWhelios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)\fP
.sp .5
.fi
.RE
In the first example, \fIhelios\fP responds to query id 3 from \fIh2opolo\fP
with 3 answer records, 3 name server records and 7 authority records.
The first answer record is type A (address) and its data is internet
address 128.32.137.3.  The total size of the response was 273 bytes,
excluding UDP and IP headers.  The op (Query) and response code
(NoError) were omitted, as was the class (C_IN) of the A record.
.LP
In the second example, \fIhelios\fP responds to query 2 with a
response code of non-existent domain (NXDomain) with no answers,
one name server and no authority records.  The `*' indicates that
the \fIauthoritative answer\fP bit was set.  Since there were no
answers, no type, class or data were printed.
.LP
Other flag characters that might appear are `\-' (recursion available,
RA, \fInot\fP set) and `|' (truncated message, TC, set).  If the
`question' section doesn't contain exactly one entry, `[\fIn\fPq]'
is printed.
.LP
Note that name server requests and responses tend to be large and the
default \fIsnaplen\fP of 96 bytes may not capture enough of the packet
to print.  Use the \fB\-s\fP flag to increase the snaplen if you
need to seriously investigate name server traffic.  `\fB\-s 128\fP'
has worked well for me.

.HD
NFS Requests
.LP
Sun NFS (Network File System) requests and replies are printed as:
.RS
.nf
.sp .5
\fIsrc.xid > dst.nfs: len op args\fP
\fIsrc.nfs > dst.xid: reply stat len\fP
.sp .5
\f(CWvs.e2766 > helios.nfs: 136 readdir fh 6.5197 8192 bytes @ 0
helios.nfs > vs.e2766: reply ok 384
vs.e2767 > helios.nfs: 136 lookup fh 6.5197 `RCS'\fP
.sp .5
.fi
.RE
In the first line, host \fIvs\fP sends a transaction with id \fIe2766\fP
to \fIhelios\fP (note that the number following the src host is a
transaction id, \fInot\fP the source port).  The request was 136 bytes,
excluding the UDP and IP headers.  The operation was a \fIreaddir\fP
(read directory) on file handle (\fIfh\fP) 6.5197.  8192 bytes are
read, starting at offset 0.  \fIHelios\fP replies `ok' with 384
bytes of data.  (The design of Sun's RPC protocol makes it difficult to
interpret replies.  I don't bother.)
.LP
In the third line, \fIvs\fP asks \fIhelios\fP to lookup the name
`\fIRCS\fP' in directory file 6.5197.  Note that the data printed
depends on the operation type.  The format is intended to be self
explanatory (at least, to me) if read in conjunction with
an NFS protocol spec.
.LP
Note that NFS requests are very large and the above won't be printed
unless \fIsnaplen\fP is increased.  I use `\fB\-s 192\fP' to watch
NFS traffic.

.HD
KIP Appletalk (DDP in UDP)
.LP
Appletalk DDP packets encapsulated in UDP datagrams are de-encapsulated
and dumped as DDP packets (i.e., all the UDP header information is
discarded).  The file
.I /etc/atalk.names
is used to translate appletalk net and node numbers to names.
Lines in this file have the form
.RS
.nf
.sp .5
\fInumber	name\fP

\f(CW1.254		ether
16.1		icsd-net
1.254.110	ace\fP
.sp .5
.fi
.RE
The first two lines give the names of appletalk networks.  The third
line gives the name of a particular host (a host is distinguished
from a net by the 3rd octet in the number \-
a net number \fImust\fP have two octets and a host number \fImust\fP
have three octets.)  The number and name should be separated by
whitespace (blanks or tabs).
The
.I /etc/atalk.names
file may contain blank lines or comment lines (lines starting with
a `#').
.LP
Appletalk addresses are printed in the form
.RS
.nf
.sp .5
\fInet.host.port\fP

\f(CW144.1.209.2 > icsd-net.112.220
office.2 > icsd-net.112.220
jssmag.149.235 > icsd-net.2\fP
.sp .5
.fi
.RE
(If the
.I /etc/atalk.names
doesn't exist or doesn't contain an entry for some appletalk
host/net number, addresses are printed in numeric form.)
In the first example, NBP (DDP port 2) on net 144.1 node 209
is sending to whatever is listening on port 220 of net icsd node 112.
The second line is the same except the full name of the source node
is known (`office').  The third line is a send from port 235 on
net jssmag node 149 to broadcast on the icsd-net NBP port (note that
the broadcast address (255) is indicated by a net name with no host
number \- for this reason it's a good idea to keep node names and
net names distinct in /etc/atalk.names).
.LP
NBP (name binding protocol) and ATP (Appletalk transaction protocol)
packets have their contents interpreted.  Other protocols just dump
the protocol name (or number if no name is registered for the
protocol) and packet size.

\fBNBP packets\fP are formatted like the following examples:
.RS
.nf
.sp .5
\s-2\f(CWicsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186\fP\s+2
.sp .5
.fi
.RE
The first line is a name lookup request for laserwriters sent by net icsd host
112 and broadcast on net jssmag.  The nbp id for the lookup is 190.
The second line shows a reply for this request (note that it has the
same id) from host jssmag.209 saying that it has a laserwriter
resource named "RM1140" registered on port 250.  The third line is
another reply to the same request saying host techpit has laserwriter
"techpit" registered on port 186.

\fBATP packet\fP formatting is demonstrated by the following example:
.RS
.nf
.sp .5
\s-2\f(CWjssmag.209.165 > helios.132: atp-req  12266<0-7> 0xae030001
helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
jssmag.209.165 > helios.132: atp-req  12266<3,5> 0xae030001
helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
jssmag.209.165 > helios.132: atp-rel  12266<0-7> 0xae030001
jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002\fP\s+2
.sp .5
.fi
.RE
Jssmag.209 initiates transaction id 12266 with host helios by requesting
up to 8 packets (the `<0-7>').  The hex number at the end of the line
is the value of the `userdata' field in the request.
.LP
Helios responds with 8 512-byte packets.  The `:digit' following the
transaction id gives the packet sequence number in the transaction
and the number in parens is the amount of data in the packet,
excluding the atp header.  The `*' on packet 7 indicates that the
EOM bit was set.
.LP
Jssmag.209 then requests that packets 3 & 5 be retransmitted.  Helios
resends them then jssmag.209 releases the transaction.  Finally,
jssmag.209 initiates the next request.  The `*' on the request
indicates that XO (`exactly once') was \fInot\fP set.

.HD
IP Fragmentation
.LP
Fragmented Internet datagrams are printed as
.RS
.nf
.sp .5
\fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB+)\fR
\fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB)\fR
.sp .5
.fi
.RE
(The first form indicates there are more fragments.  The second
indicates this is the last fragment.)
.LP
\fIId\fP is the fragment id.  \fISize\fP is the fragment
size (in bytes) excluding the IP header.  \fIOffset\fP is this
fragment's offset (in bytes) in the original datagram.
.LP
The fragment information is output for each fragment.  The first
fragment contains the higher level protocol header and the frag
info is printed after the protocol info.  Fragments
after the first contain no higher level protocol header and the
frag info is printed after the source and destination addresses.
For example, here is part of an ftp from arizona.edu to lbl-rtsg.arpa
over a CSNET connection that doesn't appear to handle 576 byte datagrams:
.RS
.nf
.sp .5
\s-2\f(CWarizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
arizona > rtsg: (frag 595a:204@328)
rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560\fP\s+2
.sp .5
.fi
.RE
There are a couple of things to note here:  First, addresses in the
2nd line don't include port numbers.  This is because the TCP
protocol information is all in the first fragment and we have no idea
what the port or sequence numbers are when we print the later fragments.
Second, the tcp sequence information in the first line is printed as if there
were 308 bytes of user data when, in fact, there are 512 bytes (308 in
the first frag and 204 in the second).  If you are looking for holes
in the sequence space or trying to match up acks
with packets, this can fool you.
.LP
A packet with the IP \fIdon't fragment\fP flag is marked with a
trailing \fB(DF)\fP.
.HD
Timestamps
.LP
By default, all output lines are preceded by a timestamp.  The timestamp
is the current clock time in the form
.RS
.nf
\fIhh:mm:ss.frac\fP
.fi
.RE
and is as accurate as the kernel's clock (e.g., \(+-10ms on a Sun-3).
The timestamp reflects the time the kernel first saw the packet.  No attempt
is made to account for the time lag between when the
ethernet interface removed the packet from the wire and when the kernel
serviced the `new packet' interrupt (of course,
with Sun's lousy clock resolution this time lag is negligible.)
.SH "SEE ALSO"
traffic(1C), nit(4P), bpf(4)
.SH AUTHORS
Van Jacobson (van@helios.ee.lbl.gov),
Craig Leres (leres@helios.ee.lbl.gov) and
Steven McCanne (mccanne@helios.ee.lbl.gov), all of
Lawrence Berkeley Laboratory, University of California, Berkeley, CA.
.SH BUGS
The clock resolution on most Suns is pathetic (20ms).
If you want to use the timestamp to generate some of the important
performance distributions (like packet interarrival time) it's best
to watch something that generates packets slowly (like an Arpanet
gateway or a MicroVax running VMS).
.LP
NIT doesn't let you watch your own outbound traffic, BPF will.
We recommend that you use the latter.
.LP
\fItcpdump\fP for Ultrix requires Ultrix version 4.0 or later; the kernel
has to have been built with the \fIpacketfilter\fP pseudo-device driver
(see
.IR packetfilter (4)).
As of this writing, Ultrix does not let you
watch either your own outbound or inbound traffic.
.LP
Under SunOS 4.1, the packet capture code (or Streams NIT) is not what
you'd call efficient.  Don't plan on doing much with your Sun while
you're monitoring a busy network.
.LP
On Sun systems prior to release 3.2, NIT is very buggy.
If run on an old system, tcpdump may crash the machine.
.LP
Some attempt should be made to reassemble IP fragments or, at least
to compute the right length for the higher level protocol.
.LP
Name server inverse queries are not dumped correctly: The (empty)
question section is printed rather than real query in the answer
section.  Some believe that inverse queries are themselves a bug and
prefer to fix the program generating them rather than tcpdump.
.LP
Apple Ethertalk DDP packets could be dumped as easily as KIP DDP
packets but aren't.
Even if we were inclined to do anything to promote the use of
Ethertalk (we aren't), LBL doesn't allow Ethertalk on any of its
networks so we'd would have no way of testing this code.
.LP
A packet trace that crosses a daylight savings time change will give
skewed time stamps (the time change is ignored).

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Jul 1993 10:46:59 GMT
From:      chetanm@visionware.co.uk (Chetan Mistry)
To:        comp.protocols.tcp-ip
Subject:   KEEPALIVE option for tcp sockets

Can the KEEPALIVE option for tcp sockets be switched on ??
My program sets KEEPALIVE succesfully with the following

	int optval = 1;
	if (setsockopt(sock, SOL_SOCKET, SO_KEEPALIVE, (char *)&optval, 
			sizeof(int)) < 0) 
		perror("tcp:setsockopt for keepalive failed");

My program then successfully connects to the remote machine and waits
in a select() loop with readfds set. However if the remote machine
crashes or drops the connection, the select() does not return. According
to the man pages the select() should return TRUE but then the following
read() or write() should fail. (I don't specify a timeout for select()).

Do I have to set the KEEPALIVE option at a different level ?
How often are the KEEPALIVE packets sent ? Can I change this timeout ?

Cheers in advance
Chet


-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 93 16:07:34 EDT
From:      joltes@husc10.harvard.edu (Richard Joltes)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   NFS or other fileserver protocols

I am attempting to link a small group of 4 PCs and 1 Mac using only TCP/IP (no
Novell!) and need to know one thing:  is there a facility for implementing 
something like PCNFSD on one server PC so that the other "client" systems can
access the server's drives transparently (i.e. as if they were local, using
virtual "D:" or other drive designators)?

I've examined FTP Software's Interdrive add-on to PC/TCP, but it requires a
Sun or other NFS server.  I need to do the same thing without the Sun!  Does
such a creature exist currently?

If there are any public domain or shareware packages that will do this, that
would be great.  Commercial stuff is also an option.

Please respond via e-mail and I can summarize if there's interest.

Thanks in advance.

--------------------------------------------------------------------------------
Dick Joltes						joltes@husc.harvard.edu
Harvard University Science Center


-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1993 13:52:53 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: any "middleware" API products

[I cut down on the wide cross-posting.]

In article <C96D0q.2wv@brunel.ac.uk> Robert.Turner@brunel.ac.uk (Robert Turner) writes:
>That's about it. It's a addition to 'normal' sockets, not a replacement.

Well, I'm not sure I'd agree with that, but it is a minor point.  A DOS
TCP/IP stack might not have a BSD sockets-like interface but could have
a Windows Sockets interface anyway.

Windows Sockets is simply a standard way to talk to TCP/IP stacks while
in Microsoft Windows.  It would be silly for it to be available under
BSD-derived Unix, since Unix already has the BSD sockets interface.
(Keep in mind that while Windows Sockets was inspired by BSD sockets,
the two are not identical.) One could write programs to run in both
environments, but it would take as much work as making any program run
in both Unix and Windows.  (The flow-of-control, memory management, and
terminal I/O models are radically different, making this portability
non-trivial.)

I don't think Windows Sockets fits what the original questioner wanted
as "middleware" -- the only source I've heard of for such a
"middleware" abstraction layer in networking is to write it yourself.
Take your programmer who is most skilled at abstraction and give him a
couple of months to design and implement a standard "middleware" layer
which can then be used in your products.  The most common approach
seems to be the obvious one -- hide all network calls in a nice,
per-application, "network calls" module.  If you design that module
right, porting to another network suite becomes a matter of writing a
drop-in replacement.  This isn't as elegant as writing a standard
intermediate layer, but it is the way the problem tends to be solved.

-- 
Stephen Trier (trier@ins.cwru.edu - MIME OK)   
Network Software Engineer              
IRIS/INS/T                               
Case Western Reserve University             

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1993 14:43:16 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: KEEPALIVE option for tcp sockets

In article <1993Jul5.104659.25388@visionware.co.uk> chetanm@visionware.co.uk (Chetan Mistry) writes:
>However if the remote machine crashes or drops the connection, the select()
>does not return. According to the man pages the select() should return TRUE
>but then the following read() or write() should fail.

It will fail eventually, but it will take 10 minutes or 2 hours,
depending on the vintage of the OS.

This timeout cannot be changed per-application in current Unixes.

This was the subject of a debate not two weeks ago and previously a few
months ago, so it is probably a sore subject by now.  Regardless of The
Way It Should Be, an immediate solution is to add some sort of polling
to your application so that it periodically sends its own keep-alive
NOP packets to the other side.  Another solution is to live with it.  :-(

	Stephen

-- 
Stephen Trier (trier@ins.cwru.edu - MIME OK)   
Network Software Engineer              
IRIS/INS/T                               
Case Western Reserve University             

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Jul 1993 16:23:33 GMT
From:      cej@world.std.com (Craig E Jackson)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

Just to throw my oar into this discussion:

1. Several persons have gotten hysterical about corrupt printouts.  Randy
from QMS has mentioned that he supports multiple protocol stacks.
Most likely, one of those stacks is NetWare; NetWare *does* rely on a
reliable link layer.  I think that Novell stockholders will testify that
such a reliance is not an instant formula for commercial failure.

2. I don't know what QMS is working on, but there *are* fast printers out
there.  Xerox was doing 2 pages/second 13-14 years ago, with 11/34s and 8080s.
A Postscript web press was announced recently.  (A web press is the big
mutha with the huge spinning drums on which they print books, etc.)

3. As others have said, a simple 16-bit checksum just isn't that good.  I
would suggest that it is insufficient to be the primary error check for
any IP data link layer.

4. Lots of people have quoted TCP speeds for this processor or that.  Few
have mentioned how much of the processor was left for the application(s) when
running at such speeds.  I would suspect that a printer vendor would prefer
that a very high percentage of the processor be delivered to PDL interpretation
and imaging.
-- 
Craig Jackson
cej@world.std.com

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Jul 1993 17:01:45 GMT
From:      cyrus@netcom.com (Cyrus Azar)
To:        comp.protocols.tcp-ip
Subject:   what is a router anyway?


Could someone out in netland clarify a pretty basic question?

I need to link two remote sites via some type of bridge/router to allow
TCP/IP traffic to flow between them.

What conditions would dictate one or the other?

Are there some "standard" definitions of bridge and router capability
that can help guide my choice?  If I say I need a router, what am I
really saying?

Any help would be sincerely appreciated.

Thanks,
-cyrus
__________________________________________________________________________
                  Cyrus Azar    cyrus@netcom.com
-- 
__________________________________________________________________________
                  Cyrus Azar    cyrus@netcom.com

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 93 17:20:09 GMT
From:      roy@mchip00.med.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

cej@world.std.com (Craig E Jackson) writes:
> 4. Lots of people have quoted TCP speeds for this processor or that.  Few
> have mentioned how much of the processor was left for the application(s)
> when running at such speeds.  I would suspect that a printer vendor would
> prefer that a very high percentage of the processor be delivered to PDL
> interpretation and imaging.

	Van Jacobson used to saturate ethernets running TCP with a Sun-3/50,
which is a 16 MHz 68020, no cache.  I suspect that compared to the cost of
everything else in a printer fast enough to worry about the speed of TCP
checksumming over ethernet, a cacheless 16 MHz 68020's worth of MIPS would
just get lost in the noise.
-- 
Roy Smith <roy@nyu.edu>
Hippocrates Project, Department of Microbiology, Coles 202
NYU School of Medicine, 550 First Avenue, New York, NY 10016
"This never happened to Bart Simpson."

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      05 Jul 1993 17:54:17 GMT
From:      bai@iesd.auc.dk (Bo Nygaard Bai)
To:        comp.protocols.tcp-ip
Subject:   Re: How to trace duplicate IP addresses using a PC running DOS or SCO?

>>>>> On Mon, 5 Jul 1993, Steinar.Haug@runit.sintef.no (Steinar Haug) said:

Haug> Sure, if you have a Sun or DEC workstation available.
Haug> On the Sun, you have 'etherfind' available as standard (or 'snoop' if you
Haug> run Solaris 2.x). 

Thanks any way, but the reason i want a snoop program for a PC is that
i would hate to have to drag my home computer (Sun SLC) to work. My
employer insists on using PC's running DOS or SCO *sigh*.

Haug> On both Sun and DEC workstations you can run the wonderful
Haug> 'tcpdump' program, available from ftp.ee.lbl.gov. tcpdump can help you a lot
Haug> when debugging network problems. I have enclosed the manual page below.

[...a very long man page left out...perhaps more appropriate as e-mail?]

I found the tcpdump program by using archie, but it needs a BSD
system. SCO looses again...

I have found out that the problem was two nearby PC's using the same
IP numbers. I am still very interrested in a snoop/etherfind/tcpdump
program for a PC running DOS or SCO though, as I am now experiencing
severe performance problems and freqent hangs on the SCO boxes. 

--
.___ o .__ |         | Bo Nygaard Bai  | Department of Computer Science  ,_//(
|__. | |   |/        |                 | The University of Aalborg (AUC)/  |  \
 ___| | |__ |\ nature | bai@iesd.auc.dk | DENMARK                        A  U  C

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Jul 1993 18:20:45 GMT
From:      emurphy@cs.uno.edu (Edward Murphy)
To:        comp.protocols.tcp-ip
Subject:   (FYI) NCSA Telnet and the D-Link DE200 ethernet card


Howdy.

I've posted several messages regarding problems I was having in getting  
NCSA Telnet (2.3.06) to work with a D-Link DE200 ethernet card. Well,  
thanks to a very helpful response, the problem was solved.

Solution: The hardware option in the config.tel file should have been set  
to "packet". The NCSA manual doesn't mention anything about the DE200  
card. I had tried several options including "ne2000" and "generic", but  
they didn't seem to work.

Regards and thanks to all those who replied,

Ed Murphy

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Jul 1993 22:22:40 GMT
From:      dkelly@esinc.uucp (Dwight Kelly)
To:        comp.protocols.tcp-ip
Subject:   Slip quest

I have installed slip-4.1 on a Sparc 2 running SunOS 4.1.3.
The modem is a Telebit Worldblazer running a fixed 38400 baud
to the computer and 9600 baud to PSI.NET.
Everything seems to work ok; except syslog is telling me:

Jul  5 18:09:22 webco vmunix: slipencode: overrun

many, many times. What is happening?


-- 
Dwight Kelly
Essential Technical Services, Inc.
3375 Summit Trail Cumming, GA 30131
(404) 889-2848  (404) 889-2624 fax

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Jul 1993 00:55:33 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: Reverse remote name server help?

In article <16BFFD92A.DELLA@lexmark.com> DELLA@lexmark.com writes:
>We are attempting to have our primary name server refer to another primary
>name server for reverse address resolution.  For some reason we cannot.
>We've played in the named.boot file and also named.rev file
>to find where we might possibly place a record and what the format
>of this record might be (to no avail).
> 
>After looking through the RFC 883 and other UNIX documentation,
>we have been unsuccessful in doing this thing.
>We are running AIX 3.2 on an RS/6000.
> 
>Here is what we need to resolve:
>   My name server is the primary name server for the abc.123.com domain.
>   Another name server is the primary name server for the def.123.com
>   domain.  I want to be able to resolve an IP address that is
>   defined on the other name server from my name server.
> 
>i.e. 'host 157.184.29.2'
> 
>Thanks in advance.
>=========================================================================
>Paul L. Della Maggiora    della@lexmark.com

	Firstly are you one or off the Internet?
	It looks like you are behind a firewall.

	If you are off you will need to establisth 'root' nameservers.
	These nameservers contain the glue that holds the DNS
	altogether.

	i.e create a root zone with at least the following information

	@ IN SOA machine1.lexmac.com. user.machine1.lexmac.com. (
		1
		1000
		1000
		1000000
		10000 )
	  IN NS machine1.lexmac.com.
	  IN NS machine2.lexmac.com.
	84.157.in-addr.arpa. IN NS machine3.lexmac.com.
	                    IN NS machine4.lexmac.com.
	lexmac.com. IN NS machine5.lexmac.com.
		   IN NS machine6.lexmac.com.
	*	   IN MX 0 external_mail_gateway.lexmac.com.
	machine1.lexmac.com. IN A XXX.XXX.XXX.XXX
	machine2.lexmac.com. IN A XXX.XXX.XXX.XXX
	machine3.lexmac.com. IN A XXX.XXX.XXX.XXX
	machine4.lexmac.com. IN A XXX.XXX.XXX.XXX
	machine5.lexmac.com. IN A XXX.XXX.XXX.XXX
	machine6.lexmac.com. IN A XXX.XXX.XXX.XXX

	and add it to named.boot on machine1 and machine2

	e.g. primary . file_containing_zone

	machine3 and machine4 are configured as nameservers for
	84.157.in-addr.arpa. Say machine3 in the primary then it
	will have a line in named.boot like
	"primary 84.157.in-addr.arpa file_containing_84_157_zone"
	and machine4 will have a line like
	"secondary 84.157.in-addr.arpa XXX.XXX.XXX.XXX file_containing_84_157_zone"
	where XXX.XXX.XXX.XXX is the IP address of machine3

	If you are on the internet you need to register the 
	namservers that server the reverse zone
	84.157.in-addr.arpa. This can be done by sending mail to
	hostmaster@internic.net.

	Mark.

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Jul 1993 05:12:22 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

	I really hate to encourage this discussion anymore, but I guess I'm
not old and wise enough to *not* put in some observations.

	1) Weird and unlikely hardware failure scenarios are at best a straw
		man argument. Ok, suppose the board DMA's bogus data into the
		driver buffer. Sure, TCP checksums will catch it. But suppose
		you have the (my guess) much more likely hardware faulure of
		failed memory chips in any of the (often multiple) copies of
		the data up to and including the user buffer itself. It doesn't
		catch it, and if the enviroment is one in which not doing
		checksums doubles performance, it's obviously better to leave
		the Ethernet checksum as one on the data.

	2) I believe vjs suggested doing the checksum via special purpose
		chips rather than in software. Great! Why not put those on
		an Ethernet board and do them on the packets as they arrive...
		oh, they're already there and already done, now, aren't they?
		The whole point...

	I'm not at all advocating that checksums should not be used, or that
it's worth a hack to not compute them. But some of the arguments I've seen
for keeping them don't seem to have much support in reality to me. Under the
conditions of the original post, a TCP checksum *is* mostly redundant and is
*not* worth a significant reduction in throughput for the infinitesimal cases
it would catch (versus the number of cases it still wouldn't). If anyone was
designing the system from scratch as an integrated whole to just do printing
on a LAN, there wouldn't be 2 checksums on every part of the packet.

	B U T.....

	The great thing about using TCP in the first place-- in fact, the whole
point-- is that it allows your customers and/or you to extend the system or
use it in ways you might not anticipate today. That means that full compliance
with the protocol is a good idea. That is, if you want to keep your customers.
Further, one of those extensions might be to use it on a non-ethernet medium
that doesn't do checksumming, or to use it on a wide-area network where who
knows what sort of battering might go on. Having an end-to-end checksum is
almost a necessity, then, and that is the only argument I've seen that makes
any sense.
	So what if in 1986 one machine somewhere, after hundreds of billions
of packets, had some funny Ethernet DMA problem that the TCP checksum caught!
How much data, by comparison, has not been reliably delivered because of any
number of other hardware failures, not to mention bugs in the TCP and/or user
program software in that time frame? Answer: a *LOT*.
	So, two handy rules of thumb:

1) If the world will end if one bit is incorrect and is delivered to
an application once every trillion packets, don't use TCP. Don't use Ethernet.
Don't use any computer I've ever heard of, or any large software or hardware
system I've ever heard of. In fact, don't build it at all; humanity will thank
you.

2) If you're printing bitmaps of pamphlets for the "Nixon in '96" campaign
and one of the pixels is the wrong color, but it prints twice as fast, your
customers would probably rather you left out checksums. Though they'd like
it much more if you got a real processor to run it on, or a decent TCP where
the checksum speed doesn't dominate in the first place.

	If you want to *claim* compliance without losing the speed, take the
VJS approach of using an "outboard" checksummer-- the one on the Ethernet
board, with a little fiddling. Subtract off the contribution from the headers
and add in the pseudo header to whatever the Ethernet checksum gets you. You
avoid resumming the data-- handy for very large packets, I suppose. But if
there's a DMA problem, the planet might end [see ROT #1].

	Are we done now?
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Jul 93 06:52:55 GMT
From:      gljones@nyx.cs.du.edu (Glenn Jones)
To:        comp.protocols.tcp-ip
Subject:   TCP Packet Prioritization

I am looking for TCP/IP protocol stack developers who have implemented 
the packet prioritization scheme.  In particular, I am looking for
an implementation on SUN, IBM, HP, SGI, DEC or other workstation class 
machines.

I can be reached at glennesys@delphi.com

Thanks in advance 
   Glenn

--
Glenn Jones                               E-Systems Inc.
glennesys@delphi.com                      Garland Division
----------------------------------------------------------

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Jul 1993 09:33:27 GMT
From:      gnn@cs.utwente.nl (George Neville-Neil)
To:        comp.protocols.tcp-ip,comp.dcom.lans,comp.windows.open-look,alt.toolkits.xview
Subject:   New version of xv_ping with a minor bug fix...

Hi Folks,

	I just put up a new version of xv_ping, an XView 3.0 client
to maintain a list of the "upness" of hosts on an IP internet using ICMP
messages, on pegasus.cs.utwente.nl:pub/bandwidth/xv_ping.tar.Z .

	This has one minor bug fix, in that the icons for up and down
were being munged on certain architectures with different byte ordering
than my DecStation.  Everything is now of the right type etc. and the bug
is fixed.

Later,
George

--
Once you get to 25 you can rent a car anywhere in the world, and
nothing else matters.
-- Max Rochlin

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Jul 1993 10:19:15 GMT
From:      dganit@gemini.math.tau.ac.il (Amitay Dganit)
To:        comp.protocols.tcp-ip
Subject:   AS/400 connectivity ?

How can we connect AS/400 to Unix workstations ?
Are there any TCP/IP implementations for the IBM AS/400 ? or are there any
gateways that do the trick ?

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Jul 1993 10:54:40 GMT
From:      xjeldc@lustorfs.ldc.lu.se (Jan Engvald LDC)
To:        comp.protocols.tcp-ip
Subject:   Re: How to trace duplicate IP addresses using a PC running DOS or SCO?


>I have a problem with my two SCO Unix boxes reporting duplicate IP
>addresses on each other. (A reports that B's IP is duplicated and vise
>versa)
>Is there any free software that i can use to trace the Ethernet
>address of the (other :-) offender? 

Yes, you can use PDTBUILD which is part of the PDCLKSET package. It will
build tables which map hostname, IP number and Ethernet address for all
hosts on a net. Any duplicates will be marked, so they are easily found.
The readme.1st file appended below.


>My network administrator is sure that the IP numbers i use are free,

Maybe not the case this time, but remember that if you use free IP numbers
but on the wrong net and it is connected to a router with proxy arp
turned on, many programs will report duplicate IP number conflict.
This is because if they send an ARP packet to themselves they normally don't 
expect an answer, beeing on the wrong arm the ROUTER will answer.

Jan E LDC

========================================================================

PDCLKSET sets the time and date of the PC clock using a TIME server.
It has daylight saveing (summer time) algorithms for most of the world.

It can use BOOTP to get IP number and other info.
PDCLKSET talks to the network card via a packet driver.

PDCLKSET can assign the proper normal or dls timezone name to
an environment variable (TZ is used by most systems).

There is also a very powerful buildt in ping/echo client and server giving
important statistics on delay, load and packet loss.

The PDTBUILD program, which is included in the ZIP package, looks
at all ARP broadcasts and generates hardware address tables with all the IP 
hosts on this (sub)net. It detects IP and hardware address duplication.

And still, PDCLKSET is so small (13 KB) you can use it even on 
diskette-only PCs.

For more info, see file PDCLKSET.DOC.

PDCLKxxx.ZIP is available at msdos.ftp.sunet.se:pub/network/pdclkset,
ftp.lu.se:pub/network/pdclkset, wsmr-simtel20.army.mil:PD1:<MSDOS.PKTDRVR>,
oak.oakland.edu:pub/msdos/pktdrvr, wuarchive.wustl.edu:mirrors/msdos/pktdrvr,
nic.funet.fi:pub/msdos/networks/pktdrvr, and probably other Simtel mirror
archives.

Happy timesetting!
                                             
_____________________________________________________________________________
Jan Engvald, Lund University Computing Center, Box 783, S-220 07 LUND, Sweden
Telephone: +46 46 107458, Telefax: +46 46 138225, Telex: 33533 LUNIVER S
E-mails: Jan.Engvald@ldc.lu.se,  xjeldc@seldc52,  psi%2403732202020::xjeldc

_____________________________________________________________________________
Jan Engvald, Lund University Computing Center, Box 783, S-220 07 LUND, Sweden
Telephone: +46 46 107458   Telefax: +46 46 138225   Telex: 33533 LUNIVER S
E-mail: Jan.Engvald@ldc.lu.se
X.400:  G=Jan/S=Engvald/O=ldc/PRMD=lu/ADMD=sunet/C=se

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 93 11:32:23 GMT
From:      ercm20@festival (Sam Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: How to trace duplicate IP addresses using a PC running DOS or SCO?

Bo Nygaard Bai (bai@iesd.auc.dk) wrote:
: I have a problem with my two SCO Unix boxes reporting duplicate IP
: addresses on each other. (A reports that B's IP is duplicated and vise
: versa)
 
: Is there any free software that i can use to trace the Ethernet
: address of the (other :-) offender? 
 
: My network administrator is sure that the IP numbers i use are free,
: so it could be a SCO Unix problem. Has anybody had similar problems on
: SCO. I hate the fact that SCO does not report the two ethernet
: numbers. They must have them to detect the duplicate....DAMIT!

Have a look in the ARP caches of the SCO boxes (I assume you can do that
- apologies if the 'arp' command is another BSD-ism that SCO left out). 
It's not a very good check, but you will get one of the MAC addresses of
the offenders and, if you keep looking at irregular intervals, you might
spot the other(s).  Just a thought. 

Sam Wilson
Network Services Division
Computing Services, The University of Edinburgh
Edinburgh, Scotland, UK


-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 93 11:49:31 GMT
From:      jordan@IMSI.COM (Jordan Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: KEEPALIVE option for tcp sockets

Chetan Mistry <chetanm@visionware.co.uk> writes:

	However if the remote machine crashes or drops the connection,
	the select() does not return. According to the man pages the
	select() should return TRUE but then the following read() or
	write() should fail ...

Which man page are you refering to?  In all Unix implementations that I
know of, if the keepalive timer goes off, the socket is marked as
invalid, but select() does not return.  If you want to do something
about it, you'd need to schedule a timer to go off and check the status
of the socket, closing it if necessary.  I use FIONREAD (an otherwise
useless concept) to reap kept-alive-now-dead sockets.  It's cheap, it's
easy, and it will return -1 if the socket has been torn down ...

/jordan

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Jul 93 12:50:29 GMT
From:      cliffb@cjbsys.bdb.com (cliff bedore)
To:        comp.protocols.tcp-ip
Subject:   Re: How to trace duplicate IP addresses using a PC running DOS or SCO?

In article <BAI.93Jul5185417@loke.iesd.auc.dk> bai@iesd.auc.dk (Bo Nygaard Bai) writes:
>>>>>> On Mon, 5 Jul 1993, Steinar.Haug@runit.sintef.no (Steinar Haug) said:
>
>Haug> Sure, if you have a Sun or DEC workstation available.
>Haug> On the Sun, you have 'etherfind' available as standard (or 'snoop' if you
>Haug> run Solaris 2.x). 
>
>Thanks any way, but the reason i want a snoop program for a PC is that
>i would hate to have to drag my home computer (Sun SLC) to work. My
>employer insists on using PC's running DOS or SCO *sigh*.
>
>Haug> On both Sun and DEC workstations you can run the wonderful
>Haug> 'tcpdump' program, available from ftp.ee.lbl.gov. tcpdump can help you a lot
>Haug> when debugging network problems. I have enclosed the manual page below.
>
>[...a very long man page left out...perhaps more appropriate as e-mail?]
>
>I found the tcpdump program by using archie, but it needs a BSD
>system. SCO looses again...
>
>I have found out that the problem was two nearby PC's using the same
>IP numbers. I am still very interrested in a snoop/etherfind/tcpdump
>program for a PC running DOS or SCO though, as I am now experiencing
>severe performance problems and freqent hangs on the SCO boxes. 
>
>--
>.___ o .__ |         | Bo Nygaard Bai  | Department of Computer Science  ,_//(
>|__. | |   |/        |                 | The University of Aalborg (AUC)/  |  \
>___| | |__ |\ nature | bai@iesd.auc.dk | DENMARK                        A  U  C
There is a program called netwatch that run on DOS using packet drivers that
will give a reasonable indication of what is happening on your ethernet.
Easily smart enough to let you see harware addresses and TCP/IP addresses.
Used to be on omnigate.clarkson.edu.  It's free and depending upon your PC and
eithernet card will give you at least several hundred packets per second.  

There is also another DOS/packet driver based program called the BEHOLDER from
the netherlands.  Sorry but I don't remember an address for this

Cliff


-- 
Cliff Bedore
7403 Radcliffe Dr. College Park MD 20840
cliffb@cjbsys.bdb.com


-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Jul 1993 13:20:39 GMT
From:      loss@fs7.ECE.CMU.EDU (Doug Loss)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: NFS or other fileserver protocols

In article <1993Jul5.160734.25517@husc14.harvard.edu> joltes@husc10.harvard.edu (Richard Joltes) writes:
>I am attempting to link a small group of 4 PCs and 1 Mac using only TCP/IP (no
>Novell!) and need to know one thing:  is there a facility for implementing 
>something like PCNFSD on one server PC so that the other "client" systems can
>access the server's drives transparently (i.e. as if they were local, using
>virtual "D:" or other drive designators)?
>
>I've examined FTP Software's Interdrive add-on to PC/TCP, but it requires a
>Sun or other NFS server.  I need to do the same thing without the Sun!  Does
>such a creature exist currently?
>
>If there are any public domain or shareware packages that will do this, that
>would be great.  Commercial stuff is also an option.
>
   I'm posting this because I think it's of general interest.  SOS is a
public domain NFS server program for MS-DOS.  The PC that SOS is running
on is dedicated, and can't be used as a user node while it's exporting
its filesystem to other machines.  If you do an archie search on "sos"
I'm sure you'll find a lot of sites that have it.

Doug Loss
loss@husky.bloomu.edu

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 1993 13:56:40 GMT
From:      whalenm@tsg.com (Matthew Whalen)
To:        comp.protocols.tcp-ip
Subject:   SL/IP for Windows 3.1


	A friend is looking for a SL/IP client for his PC Windows 3.1
machine.  Since I only deal with workstations and macs, I couldn't offer
advice, but promised to ask around for him.  If anyone has suggestions
on slip clients for windows 3.1, he'd appreciate hearing them.  His
email address is:

	staylor@nas.edu

many thanks

-matthew           ____    equal rights, not special rights  
whalenm@tsg.com    \  /         
(NeXTMail OK)       \/     Only dead fish swim with the stream. 
----------------------------------------------------------------
(My actions/words in no way reflect those of my employer.)

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Jul 1993 14:27:48 GMT
From:      toaiari@tlon.cirfid.unibo.it (Alessandro Toaiari)
To:        comp.protocols.tcp-ip
Subject:   Problems with RPC DES Authentication!!


I've a very big problem with RPC DES Authentication with SunOS.
I've a clien-server structure and I need some security mechanism between client and server.
I've used DES Authentication and I manage to notify - calling Authdes_create() to fill 
client's field cl_auth - the client's DES key to the server.
Unfortunatelly I don't know where server places information about its authentication and
about client's recognition (for example client's nickname and server's encripted window time) 
when it replyes to client..
Moreover i don't know how to call server from client the second time. Infact if I used
Authdes_create twice I obtain a duplicate key error.
I'm desperate because i must solve this problem and the SunOS Network Programming Guide
sais nothing about this problem.
I will be grateful with anybody can help me !!!

P.S. 
Excuse my poor english!!!


						Hallo everybody 
						      by

						Alessandro Toaiari


	E_Mail : toaiari@cs.unibo.it
		 toaiari@cirfid.unibo.it

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Tue, 06 Jul 1993 17:52:13 GMT
From:      debiso@westfield.win.net (Joe DeBiso)
To:        comp.protocols.tcp-ip
Subject:   Re: SCO 3.2v2.2 -> 3.2v4.1

 
In article <4.1494.362.0N566670@euronetis.no>, Rune Mossige (rune.mossige@euronetis.no) writes:
>
>
>I've just come onto a very strange problem. We have two SDI 80486 
>machines running SCO unix. One is running 3.2v4.1 and the other is 
>running 3.2v2.2
>
>I upgrading the 3.2v2.2 box to v4.1, but after the upgrade, I was not 
>able to get contact with the network. Nothing at all. No ping, no 
>telnet, nothing. I could ping and telnet myself, but nothing else. I 
>even copied the whole /etc directory from the working machine, but 
>still nothing. I spent several hours looking at various files, and 
>could not find anything unusual. In the end I had to reinstall 3.2v2.2 
>from the backup tape. The only reason I'd want to upgrade, is to have 
>NFS 1.2 with it's NIS utilities. I have to admit that I do not know 
>very much about SCO, so there might be something I have missed. I 
>followd the manual that told me to first remove NFS, LLI and TCP/IP and 
>then install from original discs. I hate to give up, but after spending 
>10 hours on saturday, I had yo give up. I've successfully 
>installed/upgraded several Sun boxes (SunOS) and RS6000's with AIX, 
>and they all work. 
>
>Does anyone have any hints or tips of what I am doing wrong?? Please 
>respond with e-mail to
>rune.mossige#euronetis.no or
>rmossige@halnet.com
>
>Rune Mossige
>
> * 1st 1.11 #274 * Never let a fool kiss you, or a kiss fool you...
>
I did the same upgrade with the same problems!  I had to rev up my
tcp/ip and the firmware on my ethernet card.  Call SCO and check
your revs!  That may solve your problem!

Joe DeBiso
Plantrol Systems, Ltd.
Westfield, NY 


-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 1993 17:53:05 GMT
From:      kbw@helios.ath.epa.gov (Kevin B. Weinrich)
To:        comp.unix.admin,comp.sun.admin,comp.protocols.tcp-ip
Subject:   Any public programs that do some of what a Network Sniffer does?

I've got etherman, interman, and packetman from Curtin University (applause
to the folk from Down Under), but I'm looking for something that will give
me some of the other neat stats of a Network Sniffer, such as
"Average acknowledgement time".  We have a Sniffer in the next building,
but due to Gov't Contracting Regulations, I am no longer able to get access
to it.  I would prefer to run it from my Sun, but could conceivable do it
from a PC.  I don't need protocols beyond TCP/IP.

I would be interested in even partial work that has been done along this line,
or suggestions as to how to program it myself, if it wasn't very hairy.

Tips as to better places to post this would be most welcome.  There doesn't
seem to be anything like "comp.unix.networking" .
-- 
Kevin Weinrich     Computer Sciences Corp.
kbw@helios.ath.epa.gov

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Jul 1993 19:02:18 GMT
From:      47.201.0.2 (Siva Arunthavanathan)
To:        comp.protocols.tcp-ip
Subject:   help needed in multiple read and write on tcp socket

Hi everyone!
I am performing multiple read and write in my program. 
I need to find out which socket is ready for reading, before actually
reading from it. Someone told me to use select system call to find out
which socket has the data. Have anyone done anything similar to this? if so
I am looking for more information on select or some example codes that uses
select system call. Thanks alot . (in advance)


Siva
 

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 93 19:12:29 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: Path MTU Discovery

mogul@pa.dec.com (Jeffrey Mogul) writes:

>In article <rturner.741408434@imagen> rturner@imagen.com (Randy Turner) writes:
>>
>>>>>A host using PMTU Discovery would normally advertise an MSS equal to
>>>>>the first-hop MSS; that is, the MTU of the directly connected LAN
>>>>>interface, less the TCP+IP header sizes.  Hosts that use RFC1191
>>>>>will avoid fragmentation through that mechanism.  Older hosts, at
>>>>>least those that comply with RFC1122, will use MIN(received-MSS, 512)
>>>>>[I could have the constant wrong] for "non-local" peers, and so
>>>>>will not do anything too awful.
>>	Wow, that seems awfully inefficient.  Something must be missing
>>	from this equation, either that, or one of us is talking about
>>	hosts and the other intermediates.
 
>No, the formula is right.  Your math is wrong.  It's less efficient
>than using, say, MSS = 1460 (unless the larger MSS causes fragmentation
>and that causes trouble).  But the net change in throughput, over a
>bandwidth-limited connection, is less than 10%.  (If you are limited
>by the rate at which your end-hosts can process packets, then the
>performance loss might be larger.)
 
>There is a persistant myth that if one cuts the packet size by a
>factor of N, throughput will drop by the same factor.  Anyone with
>a junior-high mathematics education can easily prove this wrong.
 
>-Jeff

	I don't think the myth says that throughput will drop by the
	same factor, just that the throughput will drop, usually 
	significantly.  This fact also would not elude a junior high
	student.
		Also , I would think the MIN(received-MSS, 512) would be used
	conditionally, depending on whether or not the connection was to a
	host on a different network. If the host is on the same network,
	then this equation would never allow a TCP segment that was larger
	than 512 bytes. I think we will be adding the Path MTU discovery
	code to our in-house testbed to see what kinds of results we have
	with WAN connections.

	Randy
-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Jul 93 20:11:08 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Reverse remote name server help?

The problem you are having is that there is no relationship between
forward look ups (e.g., "nslookup 123.abc.com") and reverse lookups
(e.g., "nslookup 1.2.3.4").  That is to say, domains don't have to map
onto any one subnet or network and, conversely, different addresses in
the same network or subnet might be members of different domains.

You can MAKE a relationship by specifying that 123.abc.com names are
always in a given subnet or network, X and, that all members of subnet
or network X are members of 123.abc.com.  In mathematical terms, the set
of names in 123.abc.com and the set of addresses in network or subnet X
are "one to one and on to" (I fudged here a little bit because aliases
actually make it "many to one and on to" but in the non-alias case, my
original statement holds.)

So, assuming you are talking about a subnetted class B, you could define:

123.abc.com	<=>	class.b.subnet1 (pretend those are numbers)
456.abc.com	<=>	class.b.subnet2 (pretend those are numbers)

In the nameserver for abc.com, you have a NS record which delegates
authority for the 123.abc.com and 456.abc.com to some nameserver (even
if the server resides in the same box) and alter the named.boot file
accordingly.

In the nameserver for the b.class.in-addr.arpa, you delegate
subnet1.b.class.in-addr.arpa and subnet2.b.class.in-addr.arpa.  And make
sure the top level reverse name server doesn't have any entries for
either subnet1 or subnet2.

If you can't make a clear relationship between subdomain and subnet like
this, you won't be able to delegate authority of the reverse mappings. 
You can delegate authority of the NAMES but the reverse mappings would
have to be handled by the top level reverse name server.

Charles.

--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IT Network Services			AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Jul 1993 21:03:38 GMT
From:      mbendic@nautilus.micro.umn.edu (Michael Bendickson)
To:        comp.protocols.tcp-ip
Subject:   * Help!  Need an example of read/write TCP Stream Sockets *


I am having a heck of a time trying to get a message sent from my server to
my client.  I am using TCP with stream sockets.  I can send a message from
the client (via write or send) and receive if fine (via recv), but I cant
flip it around.  Do I need to create the sockets with the socketpair 
command?  When I put a recv in the client, it says that it has received a
message of size 0.  What does that mean?  Connection closed or something
right?  I get a return code of -1 when I try the send from the server.
If there are any examples of this floating around, please email them to me.

Thanks,
-Mike Bendickson
 mbendic@mermaid.micro.umn.edu
--
===============================================================================
 Michael Bendickson	                               University of Minnesota
 E-Mail: mbendic@mermaid.micro.umn.edu		       Institute of Technology
===============================================================================

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Jul 1993 21:52:57 GMT
From:      steve@hacker.smy.com (Stephen Youndt)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip,comp.realtime,comp.sys.ibm.pc.hardware,comp.protocols.tcp-ip.ibmpc,comp.robotics
Subject:   Embedded systems booting/communicating over TCP/IP

I'm sorry for the scatter shot approach (so many different newsgroups), but
I just couldn't find a single group that fit my subject.

I want to build a small data acquisition and device control system based
around a 386 that can remote boot and communicate with a host workstation
over Ethernet using TCP/IP. 

The system components would include:
	386SX (cheapest 32bit) Single Board Computer w/ 4-8 Meg Memory
		that plugs into a passive ISA backplane
	Ethernet card (8 bit) with boot ROMS
	CCD Controller/Frame Grabber
	Serial and Parallel ports

The system would have no local disks, but would boot and do all file access
over TCP/IP to the host.

My basic stumbling blocks are:

	Can I get Ethernet boot ROMS with an IP kernel built in with a
		documented call interface that I can use in my application?
	Is there a good, cheap 386SX single board computer that I can use
		for a project like this? Built in serial, parallel and
		ethernet would be great, but I don't want VGA, keyboard,
		disk controller, etc. ADC and DACs on board would be a plus,
		but not required.

I'd like to build the system for ~$600 (ignoring the CCD controller which
I'll purchase separately). All cards (4 max) should be no larger than
3/4 length ISA cards.

If you have any suggestions as to where I should search, vendors, or any
other helpful comments, please send them by e-mail directly to me. If
there's interest, I'll e-mail summaries of what I get.

Thanks in advance.

Steve

P.S. For those interested, if you haven't guessed, the application 
     is telescope control.
-- 
Stephen M. Youndt           | geek - n. [Perh. < dial. geek, fool < MLG geck.] 
I-net: steve@hacker.smy.com |      - A carnival performer whose act usually 
UUCP:  uunet!hacker!steve   |        consists of biting the head off a live 
(703)978-6352               |        chicken or snake.

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 1993 21:53:21 GMT
From:      cracraft@rice-chex.ai.mit.edu (Stuart Cracraft)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.wizards
Subject:   Public/Free TCP/IP for DOS/Windows/Macintosh



Is there any public/free implementation of TCP/IP for DOS, Windows,
and Macintosh?

Replies => cracraft@ai.mit.edu

--Stuart

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Jul 1993 21:57:37 GMT
From:      automate@netcom.com (Competitive Automation)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin,comp.unix.programmer
Subject:   Sun nit-pf STREAMS packet filtering module question

I want to use the STREAMS NIT packet filtering module to
capture UDP/IP packets with a particular destination
port#. (Never mind why I want to use /dev/nit instead of
higher level socket -- it would take too long to explain here).

This appears to be non-trivial because the packets are structured
as follows:
	Ethernet stuff (14 bytes)
	IP header (20 bytes + variable length options)
	UDP header
	Data

Thus the field in the UDP header on which I want to test
is at a variable length from the start of the packet.
The filtering module appears to provide no method
to make such a test, or at least the "man" page in
SunOS documentation is incomplete. But programs such
as Etherfind & Snoop must be capable of making such
tests (?).

Does anyone know how to accomplish this? Of course,
I could capture the packet and make the test in
user space, but the whole point of the filtering
module is its speed. Performing tests in user 
space is likely to lead to packet loss.

Rob Stevens

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      06 Jul 93 23:12:04 GMT
From:      sukvg@microsoft.com (Sukvinder Singh Gill)
To:        comp.protocols.tcp-ip,comp.mail.misc
Subject:   Re: SMTP: "500" error message closing connection

In article <adrian.1.00114531@cursci.co.uk> adrian@cursci.co.uk wrote:
> In article <20rqqp$j9n@grasp1.univ-lyon1.fr> Christophe.Wolfhugel@grasp.insa-lyon.fr (Christophe Wolfhugel) writes:
> >5 [12:14] wolf@grasp1:~> telnet gate1.pbi.nrc.ca smtp
> >Trying...
> >Connected to gate1.pbi.nrc.ca.
> >Escape character is '^]'.
> >220 All set, fire away
> >ehlo blah
> >500 Huh?
> >Connection closed.
> 
> A classic case of connecting to a Microsoft Mail SMTP Gateway....
> It's braindead - Microsoft are seemingly not going to fix it, so we
> are stuck with it.
> 
> Regards,
> 
> Adrian

Adrian, Christophe:

Sorry for not responding to you earlier, I have been on holiday.
Christophe is correct in stating that the Gateway should not close
the connection on receiving the ehlo command. It should respond with
a "command unknown response" (500) as documented in RFCs 1425, 821, and
the sending side should return with either a helo or quit.

A fix is available from Product Support Services.

In the US dial: 206 637 9307 ( A voice message indicating the services offered)
or 206 635 7702

In Europe and the rest of the world, please contact your local Microsoft
Support Centre for Mail.

Thanks,

Sukvinder Gill
Program Manager
Microsoft Corp.
e-mail: sukvg@microsoft.com


-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Jul 1993 00:25:18 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: Slip quest

In article <C9pq5s.64L@esinc.uucp> dkelly@esinc.uucp (Dwight Kelly) writes:
>I have installed slip-4.1 on a Sparc 2 running SunOS 4.1.3.
>The modem is a Telebit Worldblazer running a fixed 38400 baud
>to the computer and 9600 baud to PSI.NET.
>Everything seems to work ok; except syslog is telling me:
>
>Jul  5 18:09:22 webco vmunix: slipencode: overrun
>
>many, many times. What is happening?
>
>
>-- 
>Dwight Kelly
>Essential Technical Services, Inc.
>3375 Summit Trail Cumming, GA 30131
>(404) 889-2848  (404) 889-2624 fax
This usually maean that you have a noisy line, or the other end is
sending with a MTU larger than the default 1006 bytes. You will
get one "slipencode: overrun" for every packet greater than 1006 bytes
and the packet will be dropped.

When ever I saw this on our leased line, the phone company had been
fiddling with the line.

In your case I would fix the interface speed at 9600 and make sure
that software flow control is turned off.

Mark.

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1993 10:09:19 -0400
From:      masato@access.digex.net (J M Thompson)
To:        comp.protocols.tcp-ip
Subject:   Re: help needed in multiple read and write on tcp socket


I'd recommend the book "Advanced Programming in the UNIX Environment"
by W. Richard Stevens (published by Addison-Wesley, 1992).  See
Chapter 12 , section on "I/O Multiplexing" for sample code.

Jim Thompson

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Jul 1993 03:44:27 GMT
From:      daniel@ing.puc.cl (Daniel Hirschberg)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: NFS or other fileserver protocols

Doug Loss (loss@fs7.ECE.CMU.EDU) wrote:
: In article <1993Jul5.160734.25517@husc14.harvard.edu> joltes@husc10.harvard.edu (Richard Joltes) writes:
: >I am attempting to link a small group of 4 PCs and 1 Mac using only TCP/IP (no
: >Novell!) and need to know one thing:  is there a facility for implementing 
: >something like PCNFSD on one server PC so that the other "client" systems can
: >access the server's drives transparently (i.e. as if they were local, using
: >virtual "D:" or other drive designators)?
: >
: >I've examined FTP Software's Interdrive add-on to PC/TCP, but it requires a
: >Sun or other NFS server.  I need to do the same thing without the Sun!  Does
: >such a creature exist currently?
: >
: >If there are any public domain or shareware packages that will do this, that
: >would be great.  Commercial stuff is also an option.
: >
:    I'm posting this because I think it's of general interest.  SOS is a
: public domain NFS server program for MS-DOS.  The PC that SOS is running
: on is dedicated, and can't be used as a user node while it's exporting
: its filesystem to other machines.  If you do an archie search on "sos"
: I'm sure you'll find a lot of sites that have it.

	I read somewhere that someone had run SOS in a WINDOWS' window 
freeing the PC.

Hope this helps...

--
       _______________________
      /\                      \
      \_| Daniel Hirschberg J. |
        | daniel@ing.puc.cl    |
        | Santiago, CHILE.     |
        |   ___________________|_
  	 \_/____________________/
 

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Jul 1993 06:11:40 GMT
From:      sjanicki@us.oracle.com (Steven B. Janicki)
To:        comp.protocols.tcp-ip
Subject:   Re: SL/IP for Windows 3.1

In article <21c0ao$nbp@obelix.tsg.com> whalenm@tsg.com (Matthew Whalen) writes:
>Path: oracle!gatekeeper.us.oracle.com!decwrl!decwrl!concert!gatech!howland.reston.ans.net!europa.eng.gtefsd.com!tsg.com!news
>From: whalenm@tsg.com (Matthew Whalen)
>Newsgroups: comp.protocols.tcp-ip
>Subject: SL/IP for Windows 3.1
>Date: 6 Jul 1993 13:56:40 GMT
>Organization: Telos Systems Group, Chantilly, VA
>Lines: 16
>Distribution: usa
>Message-ID: <21c0ao$nbp@obelix.tsg.com>
>Reply-To: whalenm@tsg.com
>NNTP-Posting-Host: benzene.tsg.com



>        A friend is looking for a SL/IP client for his PC Windows 3.1
>machine.  Since I only deal with workstations and macs, I couldn't offer
>advice, but promised to ask around for him.  If anyone has suggestions
>on slip clients for windows 3.1, he'd appreciate hearing them.  His
>email address is:
 
>        staylor@nas.edu
 
>many thanks
 
>-matthew           ____    equal rights, not special rights  
>whalenm@tsg.com    \  /         
>(NeXTMail OK)       \/     Only dead fish swim with the stream. 
>----------------------------------------------------------------
>(My actions/words in no way reflect those of my employer.)
FTP 'CELLO' it comes with DISTINCTS PPP/SLIP. You can use 'TRUMPET' with this 
as well.

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Jul 1993 07:08:27 GMT
From:      etxmesa@eos.ericsson.se (Michael Salmon)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Tips on alternative to NFS requested.

I am looking for an alternative to NFS, preferably TCP based. RFS seems
to do what I want but I can't yet find a standard for it. All
suggestions welcome.

-- 

Michael Salmon

#include	<standard.disclaimer>
#include	<witty.saying>
#include	<fancy.pseudo.graphics>

Ericsson Telecom AB
Stockholm

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Jul 1993 11:10:27 GMT
From:      pjulich@su102a.ess.harris.com (Paul M. Julich)
To:        comp.protocols.tcp-ip
Subject:   Portable TCP-IP Stack


I would like to locate vendors of Portable TCP-IP code.  The
application I have runs on a MIPS R-3000 processor with a custom Ada
run-time kernal.  Please respond by E-mail and I will summarize if
there is enough interest.

pjulich@rhino.ess.harris.com    


-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Jul 1993 11:25:43 GMT
From:      ag@fokus.gmd.de (A. Gavras)
To:        comp.protocols.tcp-ip
Subject:   RT-IP need information

Hi,
I heard of RT-IP (does it stand for Real-Time-IP ?) but was unable 
to find any further information. Can anyone point me to articles,
papers or other sources that describe RT-IP ?
Thanks in advance

-- 
Anastassios Gavras, e-mail:gavras@fokus.gmd.de Tel.:+49 30 25499263
GMD-FOKUS, Hardenbergplatz 2, 10623 Berlin, Germany

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Jul 1993 15:46:34 EDT
From:      Thomas J Cozzolino <RBNTJC@rohvm1.rohmhaas.com>
To:        comp.protocols.tcp-ip
Subject:   Scripts to check Network health?

We are running a multi-site world-wide IP network, and so need to
properly configure/manage nameservers, etc. between several groups
of people and several machine types.

Has anyone already written any scripts (Perl, etc.) to perodically go out
to one's local WAN and resolve names, etc., and then report by E-mail to
sys admins regarding the status?  It would be nice if the script tried to
query the host(s) by address, if name services were not available, and note
that it its status report.

Thanks for any help.  Please reply directly to tcozz@rohmhaas.com, or
directly to this newsgroup.


+============================================+
|   Thomas J. Cozzolino - Rohm and Haas Co.   =
|   InterNet:    tcozz@rohmhaas.com            =
|                                               =
|     Internet Access for Everyone..             =
|         Isn't it time?                          =
|                                                  =
|   - Opinions expressed are my own, not            =
|     necessarily those of Rohm and Haas Company     =
+=====================================================+

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Jul 1993 11:49:29 GMT
From:      chetanm@visionware.co.uk (Chetan Mistry)
To:        comp.protocols.tcp-ip
Subject:   Re: KEEPALIVE option for tcp sockets

Jordan Hayes (jordan@IMSI.COM) wrote:
: Which man page are you refering to?  In all Unix implementations that I
: know of, if the keepalive timer goes off, the socket is marked as
: invalid, but select() does not return.  If you want to do something
: about it, you'd need to schedule a timer to go off and check the status
: of the socket, closing it if necessary.  I use FIONREAD (an otherwise
: useless concept) to reap kept-alive-now-dead sockets.  It's cheap, it's
: easy, and it will return -1 if the socket has been torn down ...

Here's part of the setsockopt/getsockopt man page :-

     reuse of local addresses.  SO_KEEPALIVE enables the periodic
     transmission of messages on a connected socket.  Should  the
     connected  party fail to respond to these messages, the con-
     nection is considered broken.  A process attempting to write
     to the socket receives a SIGPIPE signal and the write opera-
     tion returns an error.  By default, a process exits when  it
     receives SIGPIPE.  A read operation on the socket returns an
     error but does not generate  SIGPIPE.   If  the  process  is
     waiting in select(2) when the connection is broken, select()
     returns true for any read or write events selected  for  the
     socket.    SO_DONTROUTE  indicates  that  outgoing  messages

The problem I'm having is that we have a tcp socket based RPC server which
talks to PC's. If the PC client program crashes, it takes the PC with it.
Its ok if your doing it between 2 Unix boxes, if the client program
crashes the kernal will close the socket and the server will get an EOF
on that socket.

The earlier posting said it will fail but would take 10mins to 2 hours.
I have left the server for half a day, and it is still waiting in the
select() loop ??

Can somebody tell me how rlogin does it. If you have an rlogin session
and the remote host your logged into crashes, the rlogin process comes
back (almost instantly) with the following message 
	"Connection reset by peer"

Cheers

Chet


-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 93 18:30:18 CST
From:      kodagali@wsuhub.uc.twsu.edu
To:        comp.protocols.tcp-ip
Subject:   X-Window over phone line?

Hi,

I have a Sparc 2 at my workplace running SunOS 4.1.3 and Openwin 3.0. It
is on an ethernet running TCP/IP. It also has a TELEBIT Worldblazer
modem for dialing in. I have a PC at home which I would like to connect
to the Sparc through the phone line so that I can run X-Window
progs on the Sparc and display them on the PC. I have DesqView/X to
convert the PC into X-terminal. I have a modem on the PC. Is this
possible ?

Thanks for your time.
----------------------------------------------------------
Email: kodagali@wsuhub.uc.twsu.edu


-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1993 14:07:48 GMT
From:      welander@i4.informatik.rwth-aachen.de
To:        comp.protocols.tcp-ip
Subject:   Unexplainable measurement figures ?!

Hi !

At RWTH Aachen we are presently doing performance measurements with TCP and
XTP and have come up with some rather strange results that we cannot
explain.

The measurements are made on an unloaded Ethernet between two SUN
workstations. When the CPU is unloaded (except for the protocol) we get
reasonable throughput values, but when we load the CPU with 15 background
processes the spread between measured throughput is very strange.

Out of 25 measurements with the same settings about 20-22 have reasonable
throughbut (6-8 Mbits/s) while the remaining 3-5 transmissions show only a
throuhput of 1-2 Mbit/s.

The extreme low values appear at totaly random places within each set of
measurements. We haven«t been able to find any reasonable explaination to
this behavior, our guess so far is that it has to do with the operating
system in some way (maybe the schedular) and not with the protocol
implementations.

If anybody has an explanation or a good guess don«t hesitate, mail it.

Bjoern Welander

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Jul 1993 16:07:06 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: KEEPALIVE option for tcp sockets

In article <1993Jul7.114929.9369@visionware.co.uk>, chetanm@visionware.co.uk (Chetan Mistry) writes:
> Jordan Hayes (jordan@IMSI.COM) wrote:
> : Which man page are you refering to?  In all Unix implementations that I
> : know of,...


> Here's part of the setsockopt/getsockopt man page :-
> ...

Once again, "the setsockopt/getsockopt man page" for which system?

Almost all UNIX TCP/IP systems are based on 4.2-BSD or 4.3BSD TCP/IP
code, including System V Release 3 and System V Release 4.  (Don't
believe the USL scumbags; compare the source.  The only major, modern
exception I can recall is Sun's new code.)  However, there have been
more than one version of 4.*BSD TCP/IP code and more than one version
of "the" man page just from CSRG.  Of course, every vendor is compelled
to change things at least a little.


> ...
> The earlier posting said it will fail but would take 10mins to 2 hours.
> I have left the server for half a day, and it is still waiting in the
> select() loop ??
> 
> Can somebody tell me how rlogin does it. If you have an rlogin session
> and the remote host your logged into crashes, the rlogin process comes
> back (almost instantly) with the following message 
> 	"Connection reset by peer"

Not if you do not type anything to the rlogin client.  Try it.
The standard 4.*BSD rlogin client source does not turn on keepalives.
It is only rlogind, the server, that does.  Of course, your unspecified
system may be different.  Perhaps your system's rlogin client turns on
keepalives.


Look for the net2 rlogin source on uunet.


Vernon Schryver,  vjs@sgi.com

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 93 16:10:30 GMT
From:      1993Jul7.070827.3131@ericsson.se, , etxmesa@eos.ericsson.se writes: (rcc30@juts.amdahl.comIn article)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Tips on alternative to NFS requested.

|> I am looking for an alternative to NFS, preferably TCP based. RFS seems
|> to do what I want but I can't yet find a standard for it. All
|> suggestions welcome.
|> 

RFS is defined (from an external perspective) in the SVID.  
There are some technical papars circulating that desribe the implementation.


The archetypal paper was given by Andy Rifkin at USENIX, Jul 1986 in Atlanta

In principle it is a remote system call mechanism, this is how it provides
greater UNIX transparency than NFS.

==========================================================================
Richard Croucher       | EMAIL  rcc30@ccc.amdahl.com
                       |        +44 252 346376
   Any views, opinions expressed are my own and do not necessarily reflect
   those of  Open Systems Europe, or the Amdahl Corporation.
==========================================================================

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 93 16:31:54 GMT
From:      apple@drvax3.msfc.nasa.gov (Kathleen Applegate)
To:        comp.protocols.tcp-ip
Subject:   Re: New Yorker cartoon

errol@hpgnd153.grenoble.hp.com (Errol_Inan) writes:

>> "On the Internet, nobody knows you're a dog".
 
>Bark, bark!  Ruff, ruff.  Sniff, sniff, sniff, sniff, sniff.
 
><censored>
 
>Pant, pant, pant, ....

First the cartoon, and now this dialgoue gives flesh to the
oxymoron used recently to describe the Internet (Washington Post?):
"remote intimacy."
--
Kathleen Applegate, Sr. Analyst      apple@drvax3.msfc.nasa.gov           
Marshall Space Flight Center             Voice:  (205) 544-7656

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Jul 1993 17:00:14 GMT
From:      gsa@mercury.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

In article <C9q94M.Fuw@mentor.cc.purdue.edu>, dls@mentor.cc.purdue.edu (David L Stevens) writes:
|> 	I really hate to encourage this discussion anymore, but I guess I'm
|> not old and wise enough to *not* put in some observations.
|> 
|> 	1) Weird and unlikely hardware failure scenarios are at best a straw
|> 		man argument. Ok, suppose the board DMA's bogus data into the
|> 		driver buffer. Sure, TCP checksums will catch it. But suppose
|> 		you have the (my guess) much more likely hardware faulure of
|> 		failed memory chips in any of the (often multiple) copies of
|> 		the data up to and including the user buffer itself. It doesn't
|> 		catch it, and if the enviroment is one in which not doing
|> 		checksums doubles performance, it's obviously better to leave
|> 		the Ethernet checksum as one on the data.
|> 

You obviously haven't played with RISC systems and their VME buses :-)

The CPU, memory, and disk paths may have parity but the VME buses and
peripherals have had much looser requirements.  The "high performance"
and/or "high power" adapters tend to have interesting problems, especially
if the buses are loaded.  Network adapter vendors tend to ignore 
(or at least they don't rush to correct the problem) their
integrity problems, because the protocol checksums catch most of their
short-comings.  When a remote entity chooses to ignore the computed 
checksum, they now open a "hole" which the peer had assumed was 
adequately covered.  

NOTE - in case you want to talk about most likely problems, single
bit loss has been the most prevalent problem with the few VME buses
I've had the pleasure to deal with.

My previous point about needing to "know" the entire path is still
valid even with your arguments.  You must "know" that all elements in
the path (routers, bridges, peer systems, etc.) are not relying on
the checksum to Cover Their A...s, befor making a unilateral decision
to ignore the checksum!

|>  [deleted a bunch of stuff.....]

I don't disagree with your philosophy, but it will be interesting
to see who's "box" needs to be upgraded when the customer 
complains about seeing printing errors :-)


-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1993 18:47:30 GMT
From:      rgoldstone@OAVAX.CSUCHICO.EDU (Robin, Girl Wonder)
To:        comp.protocols.tcp-ip,comp.mail.misc
Subject:   Re: SMTP: "500" error message closing connection

In article <1993Jul06.231204.16147@microsoft.com>, sukvg@microsoft.com (Sukvinder Singh Gill) writes:
>Sorry for not responding to you earlier, I have been on holiday.
>Christophe is correct in stating that the Gateway should not close
>the connection on receiving the ehlo command. It should respond with
>a "command unknown response" (500) as documented in RFCs 1425, 821, and
>the sending side should return with either a helo or quit.
>
>A fix is available from Product Support Services.
>
>In the US dial: 206 637 9307 ( A voice message indicating the services offered)
>or 206 635 7702
>
Dialing these numbers results in a message stating that your credit card
will be billed by Microsoft.  This is typical Microsoft bullshit.  Their
gateway contains a serious bug, as confirmed here by Microsft themselves,
yet they are charging their customers for the fix.  Microsoft's SMTP gateway
has been a nightmare from day one.  And now Microsoft *finally* acknowledges
the brain-dead behavior of their product, and we're supposed to pay to get
a working version!  What a joke.  I can't believe Sukvinder posted this
message, telling people to call the above number, where they are greeted by
a message informing them that they will be billed $150 to talk to a customer
service rep.  This makes me sick.

************************************************************************
Robin Goldstone, Systems Software Specialist             ____
California State University, Chico  Computing Services   \  /
rgoldstone@oavax.csuchico.edu                             \/
                                                 Closets are for clothes

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Jul 1993 19:53:17 GMT
From:      carlson@steam.Xylogics.COM (James Carlson)
To:        bit.listserv.ibmtcp-l,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.servers,comp.bugs.4bsd,comp.bugs.misc
Subject:   Bug in many versions of TCP


IMPORTANT BUG FIX FOR TCP INPUT CODE

Xylogics has found and fixed a bug that exists in the tcp_input.c
routine in 4.4BSD and several other versions of TCP.  We strongly
recommend that you examine your version of TCP for this error.

Traces of this bug occurring are available on request.  Send a message
to carlson@xylogics.com with comments or requests for this data.


THE FIX:

From 4.4a BSD sys/netinet/tcp_input.c, lines 609 through 663:

	/*
	 * States other than LISTEN or SYN_SENT.
	 * First check that at least some bytes of segment are within 
	 * receive window.  If segment begins before rcv_nxt,
	 * drop leading data (and SYN); if nothing left, just ack.
	 */
	todrop = tp->rcv_nxt - ti->ti_seq;
	if (todrop > 0) {
		if (tiflags & TH_SYN) {
			tiflags &= ~TH_SYN;
			ti->ti_seq++;
			if (ti->ti_urp > 1) 
				ti->ti_urp--;
			else
				tiflags &= ~TH_URG;
			todrop--;
		}
		if (todrop > ti->ti_len ||
		    todrop == ti->ti_len && (tiflags&TH_FIN) == 0) {
			tcpstat.tcps_rcvduppack++;
			tcpstat.tcps_rcvdupbyte += ti->ti_len;
			/*
			 * If segment is just one to the left of the window,
			 * check two special cases:
			 * 1. Don't toss RST in response to 4.2-style keepalive.
			 * 2. If the only thing to drop is a FIN, we can drop
			 *    it, but check the ACK or we will get into FIN
			 *    wars if our FINs crossed (both CLOSING).
			 * In either case, send ACK to resynchronize,
			 * but keep on processing for RST or ACK.
			 */
			if ((tiflags & TH_FIN && todrop == ti->ti_len + 1)
#ifdef TCP_COMPAT_42
			  || (tiflags & TH_RST && ti->ti_seq == tp->rcv_nxt - 1)
#endif
			   ) {
				todrop = ti->ti_len;
				tiflags &= ~TH_FIN;
				tp->t_flags |= TF_ACKNOW;
			} else
 goto dropafterack;
		} else {
			tcpstat.tcps_rcvpartduppack++;
			tcpstat.tcps_rcvpartdupbyte += todrop;
		}
		m_adj(m, todrop);
		ti->ti_seq += todrop;
		ti->ti_len -= todrop;
		if (ti->ti_urp > todrop)
			ti->ti_urp -= todrop;
		else {
			tiflags &= ~TH_URG;
			ti->ti_urp = 0;
		}
	}

Change this to:

	/*
	 * States other than LISTEN or SYN_SENT.
	 * First check that at least some bytes of segment are within 
	 * receive window.  If segment begins before rcv_nxt,
	 * drop leading data (and SYN); if nothing left, just ack.
	 */
	todrop = tp->rcv_nxt - ti->ti_seq;
	if (todrop > 0) {
		if (tiflags & TH_SYN) {
			tiflags &= ~TH_SYN;
			ti->ti_seq++;
			if (ti->ti_urp > 1) 
				ti->ti_urp--;
			else
				tiflags &= ~TH_URG;
			todrop--;
		}
		if (todrop > ti->ti_len ||
		    todrop == ti->ti_len && (tiflags&TH_FIN) == 0) {
			tcpstat.tcps_rcvduppack++;
			tcpstat.tcps_rcvdupbyte += ti->ti_len;
			/*
			 * If FIN is just one to the left of the window,
			 * then drop it.
			 */
			if ((tiflags & TH_FIN) && todrop == ti->ti_len + 1)
				tiflags &= ~TH_FIN;
			/*
			 * Send ACK to resynchronize, and drop any data,
			 * but keep on processing for RST or ACK.
			 */
			todrop = ti->ti_len;
			tp->t_flags |= TF_ACKNOW;
		} else {
			tcpstat.tcps_rcvpartduppack++;
			tcpstat.tcps_rcvpartdupbyte += todrop;
		}
		m_adj(m, todrop);
		ti->ti_seq += todrop;
		ti->ti_len -= todrop;
		if (ti->ti_urp > todrop)
			ti->ti_urp -= todrop;
		else {
			tiflags &= ~TH_URG;
			ti->ti_urp = 0;
		}
	}


JUSTIFICATION OF CHANGES

In the original BSD code, if it gets through the test:

		if (todrop > ti->ti_len ||
		    todrop == ti->ti_len && (tiflags&TH_FIN) == 0) {

Then it will generate an ack packet by setting TF_ACKNOW either through
the first clause of the following "if" statement, or when it jumps to
"dropafterack."  Thus, it is valid to simply set TF_ACKNOW in both
cases.

Since both cases will ignore any data in the packet, it is valid to set
"todrop = ti->ti_len;"  All of this data, since it is less than rcv_nxt,
is to the left of the window and has already been acknowledged and must
be dropped.  The following m_adj call will do that.

The new code hauls these two statements out of that next "if" statement.

The "TCP_COMPAT_42" code is there to force RST (reset) packets through
the data-dropping code so that RST is handled.  If this weren't done,
then the "goto dropafterack" statement would cause the RST to be
inappropriately ignored.  This test is no longer needed since the new
code doesn't jump to "dropafterack."


BUG DUPLICATION SCENARIO

With this configuration:

	Host A <--Enet--> Router <--X.25--> Router <--Enet--> Host B

The X.25 link must have long delays (about 1 second in our test) and be
much lower speed (about 64Kbps) than the Ethernet links used, and enough
TCP connections must be transmitting data in both directions to cause
significant packet loss and ICMP Source Quench messages on both ends.

The TCP connection that fails must be transferring data in both
directions simultaneously, and "host A" and "host B" must be identical
machines with identical timer settings.

The bug manifests itself when both host A and host B generate resent
data due to a TCP "persist" timer expiry at approximately the same time.


DESCRIPTION OF BUG

After a near-simultaneous drop of data-bearing TCP packets in each
direction and subsequent TCP send-ahead, the state is:

Reassembly queue on host A (112.0.0.55.7004):

	6CE1C477  6CE1C677  6CE1C877  6CE1C921  6CE1CB21  6CE1CBBA
	|         |         |         |         |         |
 +---------+---------+---------+---------+---------+
	| Missing | 512 oct | 170 oct | 512 oct | 153 oct |
	+---------+---------+---------+---------+---------+

Some TCP variables on host A:

	snd_una:	4A2363B3
	snd_max:	4A2367B3
	rcv_nxt:	6CE1C477
	rcv_max:	6CE1CBBA

Reassembly queue on host B (114.0.0.55.10400):

	4A2363B3  4A2365B3  4A2367B3
	|         |         |
 +---------+---------+
	| Missing | 512 oct |
	+---------+---------+

Some TCP variables on host B:

	snd_una:	6CE1C477
	snd_max:	6CE1CBBA
	rcv_nxt:	4A2363B3
	rcv_max:	4A2367B3

Both hosts go into retransmit mode due to persist timer expiry, which
causes them to send segments, at almost the same time, which look like
this:

	From host A:  seq 4A2363B3, ack 6CE1C477, len 512
	From host B:  seq 6CE1C477, ack 4A2363B3, len 512

Since this is a persist timer expiry, the snd_nxt values are left at the
end of the resent data instead of the end of all sent data.  Therefore,
the host A's snd_nxt is 4A2365B3 and host B's snd_nxt is 6CE1C677.

When these two segments are received by the peers, the queues are
reassembled and passed up to the application.  Host A's rcv_nxt is set
to 6CE1CBBA and host B's rcv_nxt is set to 4A2367B3.  Acks are then sent
out, but since the retransmit was done by a persist timer expiry and the
input ack numbers on the resent packets were old, the snd_nxt variables
aren't advanced to the end of the data.  Therefore, these ack packets
are sent:

	From host A:  seq 4A2365B3, ack 6CE1CBBA, len 0
	From host B:  seq 6CE1C677, ack 4A2367B3, len 0

Now, the "todrop = tp->rcv_nxt - ti->ti_seq;" calculation in tcp_input.c
yields 0x543 on host A and 0x200 on host B when these packets are
received.  Due to the bug, it executes "goto dropafterack;" on both
sides, which completely ignores the valid ack numbers in the input
packets.

At this point TCP is stuck.  Subsequent resends -- due to persist or due
to excessive acks -- will send out this apparently "old" sequence number
from snd_nxt and the other side's tcp_input.c will continually drop the
data until, eventually, the connection is killed by a higher-level
timer.  With the fix in place, it will instead fall through to the code
that properly flushes the output queue based on the new ack number and
updates the snd_nxt variable to the end of the newly-acked data, and
then subsequent acks will have good sequence numbers.

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 3159

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Jul 1993 20:13:03 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Unexplainable measurement figures ?!

Well, I would expect that system loading would give such variation
only if your test times were rather small. You could test the
hypothesis by having each of those system load programs try to do
something useful, and measure *that* time and see what the variations
are. 

My favorite first culprit in such apparently random performance loss
situations would be retransmissions. The degree to which this will
affect performance will depend on a number of factors - the first
would be the presence (with TCP at least, don't know about XTP) of
"fast retransmit." The usefulness of this can be nullified if you have
a TCP window that is only a few (<6?, maybe 5) times larger than the
connection's MSS - fast retransmit relies on receiving multiple,
duplicate ACKs. For example, a 4096 byte window on an Ethernet will
preclude TCP fast retransmit (the MSS would likely be 1460 bytes, and
4096 / 1460 < 5)

rick jones


-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Jul 1993 20:32:43 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)


Just to beat this horse some more ...

The non-zero TCP and UDP checksum error coutners I mentioned recently 
almost certainly were counting errors that occurred in traffic
that travelled routes that were completely protected by link-layer
checksums, either FDDI or Ethernet.  It is almost certain that
none of the errors occurred on traffic going over less protected
56K or T1 or fractional-T1 wide area network links.  I say this
based on my knowledge of the network and traffic involved.

This implies those ~100 errors
    1. occurred in router memory or buses (including workstations
	acting as routers, as well as various Cisco routers).
    2. happened in host memory or buses.
    3. were committed by various bridges or switching hubs.
    4. were link layer errors not detected by the FDDI or Ethernet 
	checksums.

Isn't it true that cases (1) through (3) are essentially the same?
Does it matter if an error happens when a packet is being forwarded by
a router or bridge or when it happens when a packet is being sent or
received?  I think it does not.

If you agree, then does it matter in any of those four cases whether
the packet was going directly from one host to its destination or if
peers were not directly connected?

In other words, what difference does it make if an error occurs on a
direct link or on a route?  If it is safe to turn off TCP checksums for
a direct link then it should be about 1/(N+1) as safe to turn TCP
checksums when the peers are separated by N routers and N+1 links with
link-layer checksums.

If you accept that, then don't you also accept the statement that for
all values of N, the danger P of turning off the TCP checksum is, for
all practical purposes, the same as the danger P*(N+1) ?


In other words, non-zero `netstat` numbers are convincing evidence that
the TCP checksum is a Good Thing.


Vernon Schryver,  vjs@sgi.com

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 93 20:41:21 GMT
From:      donr@sadis05.kelly.af.mil (DONALD G. RUEBENSON II - SCST)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

Brooks Cutter (bcutter@paradyne.com) wrote:
: In <C95Jxq.8Go@wang.com> Tom Fitzgerald <fitz@wang.com> wrote:
: >> each ip address should have it's own, unique hostname. also, be sure to 
: >> modify rc and/or rc.local to ifconfig both addresses.
: >Could you expand on this a little?  The one-name-per-host advocates have
: >posted believable explanations for their viewpoint; one-name-per-interface
: >fans seem to be posting bald statements with no explanation.
 
: The above wasn't my posting but...
 
: The reason why we are using a unique name for each interface is because
: we have those servers provide NIS server to clients on multiple segments..
: If "server" had interfaces on 1, 2, and 3 - then by only using one name
: for all three interfaces, all the clients on two segments will go through
: the router to access the server...  The answer is of course to use RIP
: so the clients will discover the local interfaces - but there are problems
: with RIP in our environment and we haven't had the time to spend solving
: them - And we need a solution now.

The problem you are experiencing is probably caused by trying to run
dynamic routing (routed) on hosts that should only have limited and
fixed modifications to their route tables.  routed usually is not run on
hosts with only one interface; the route table is "primed" with a
default route and specific network routes as appropriate for the local
topology.

: So what we currently do is call one of the interfaces "server" and
: setup names or aliases for each of the interface with the hostname (ex:
: "server") and append the interface number ("server1", etc) -- Then we
: setup the client's fstab, etc to use the local segment number, and
: in the automounter setup the interfaces to look like replicated
: servers - so it pings the RPC Null procedure, and the first one to
: respond (presumably the local interface), gets service...
 
: We'd like to use DNS to resolve hostname to IP address mappings -
: but I don't believe (or I don't know) that DNS will optimize
: the returned address based on the client's IP address (ie:
: try to return a server IP address on the same segment as the
: requestor)

"Optimization" needs to be done in the IP route table, as explained
below.

: (I put two interface numbers (with the same name) in our NIS hosts file
: and did a ypmatch on the name - the address returned depended on the
: order in the host file, unfortunately...)

This behavior is not a problem in that a single interface host will only
ba able to talk to one of the ip addresses returned anyway, the one it
shares a network segment with or the one that has the most accurate
match in the route table (either network or host entry).

: >One-name-per-host works fine here.  I can see why "sortlist" might be
: >needed in some /etc/named.boot files, to prevent X.25 interfaces from being
: >favored over FDDI interfaces, but that works.  (In fact, I use sortlist all
: >over the place, listing networks from fastest to slowest.)
 
: We plan to put all our servers on a private FDDI segment to support
: compute servers, and for automounting on the servers... The NIS servers
: and client use the same hosts file - We don't want the servers talking
: over 10BaseT and we don't want the clients going through the router to 
: get on the FDDI segment, when they are locally attached via UTP...
: It's the same problem - and unfortunately I only see the current solution..
 
: (I wonder if Hesoid does Name/address mappings and if so does 
: optimization based on segment number...?)

IMHO, there is a very common misunderstanding here of the concepts and
relative function of name service (NIS,DNS) and IP routing (RIP/routed).
If I can be of assistance, please give me a call or send e-mail.

: -- 
: Brooks Cutter    (I: bcutter@paradyne.com) (U: ...uunet!pdn!bcutter)
: Unix System Administrator, Engineering Services
:         AT&T Paradyne, Largo Florida
: (Opinions expressed are my own and do not reflect those of my employer)

Don Ruebenson
Systems Analyst
(210) 980-7871 

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      07 Jul 93 21:33:13 GMT
From:      sukvg@microsoft.com (Sukvinder Singh Gill)
To:        comp.protocols.tcp-ip,comp.mail.misc
Subject:   Re: SMTP: "500" error message closing connection

In article <1993Jul06.231204.16147@microsoft.com> sukvg@microsoft.com wrote:
> In article <adrian.1.00114531@cursci.co.uk> adrian@cursci.co.uk wrote:
> > In article <20rqqp$j9n@grasp1.univ-lyon1.fr> Christophe.Wolfhugel@grasp.insa-lyon.fr (Christophe Wolfhugel) writes:
> > >5 [12:14] wolf@grasp1:~> telnet gate1.pbi.nrc.ca smtp
> > >Trying...
> > >Connected to gate1.pbi.nrc.ca.
> > >Escape character is '^]'.
> > >220 All set, fire away
> > >ehlo blah
> > >500 Huh?
> > >Connection closed.
> > 
> > A classic case of connecting to a Microsoft Mail SMTP Gateway....
> > It's braindead - Microsoft are seemingly not going to fix it, so we
> > are stuck with it.
> > 
> > Regards,
> > 
> > Adrian
> 
> Adrian, Christophe:
> 
> Sorry for not responding to you earlier, I have been on holiday.
> Christophe is correct in stating that the Gateway should not close
> the connection on receiving the ehlo command. It should respond with
> a "command unknown response" (500) as documented in RFCs 1425, 821, and
> the sending side should return with either a helo or quit.
> 
> A fix is available from Product Support Services.
> 
> In the US dial: 206 637 9307 ( A voice message indicating the services offered)
> or 206 635 7702
> 
> In Europe and the rest of the world, please contact your local Microsoft
> Support Centre for Mail.
> 
> Thanks,
> 
> Sukvinder Gill
> Program Manager
> Microsoft Corp.
> e-mail: sukvg@microsoft.com
> 
I received a message from Robin Goldstone, with the University of California,
stating that Microsoft charges customers for bug fixes. I'd like to apologize
that my earlier mail did not state the process of getting Support and how
it works when you are requesting a fixed version of the code.

If there is a bug and you need a new version, there will be no charge!
i.e. the credit card charge is refunded.

For credit card holders the number is 206 635 7022

If you do not have a credit card you can reach Product Support Services
by dialing 1 900 555 2100
Again the cost is refunded in this case.

For further information on Product Support Services options please call
1 800 227 4679. (PSS Sales Group)

There is a recorded message stating all these numbers on 206 637 9307.

You may also call you local Microsoft Representative for information
on Product Support Services.

I hope this clarifies the situation more clearly.

Thanks, 

Sukvinder Gill
Program Manager of SMTP Gateway Technologies
Microsoft Corporation
e-mail: sukvg@microsoft.com

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 93 21:53:27 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:


>Just to beat this horse some more ...
 
>The non-zero TCP and UDP checksum error coutners I mentioned recently 
>almost certainly were counting errors that occurred in traffic
>that travelled routes that were completely protected by link-layer
>checksums, either FDDI or Ethernet.  It is almost certain that
>none of the errors occurred on traffic going over less protected
>56K or T1 or fractional-T1 wide area network links.  I say this
>based on my knowledge of the network and traffic involved.
 
>This implies those ~100 errors
>    1. occurred in router memory or buses (including workstations
>	acting as routers, as well as various Cisco routers).
>    2. happened in host memory or buses.
>    3. were committed by various bridges or switching hubs.
>    4. were link layer errors not detected by the FDDI or Ethernet 
>	checksums.
 
>Isn't it true that cases (1) through (3) are essentially the same?
>Does it matter if an error happens when a packet is being forwarded by
>a router or bridge or when it happens when a packet is being sent or
>received?  I think it does not.
 
>If you agree, then does it matter in any of those four cases whether
>the packet was going directly from one host to its destination or if
>peers were not directly connected?
 
>In other words, what difference does it make if an error occurs on a
>direct link or on a route?  If it is safe to turn off TCP checksums for
>a direct link then it should be about 1/(N+1) as safe to turn TCP
>checksums when the peers are separated by N routers and N+1 links with
>link-layer checksums.
 
>If you accept that, then don't you also accept the statement that for
>all values of N, the danger P of turning off the TCP checksum is, for
>all practical purposes, the same as the danger P*(N+1) ?


>In other words, non-zero `netstat` numbers are convincing evidence that
>the TCP checksum is a Good Thing.


>Vernon Schryver,  vjs@sgi.com

Ok, I'll pick up the whip for the horse for awhile...

	I agree in part with your probabilities for router/bridge errors,
	but I 'm not sure I understand the conclusion you draw from the math.
	It seems that for increasing values of N, the probability of failure
	in one of the N intermediates also increases.  In other words, the
	more pieces you have between the connected hosts, the more likely
	it is that one of them might screw up. For a direct link (i.e.
	both hosts tapped into the same Ethernet segment) your odds for
	failure are somewhat less.

	Also, I have been studying some traffic here on our network, and
	it appears that the bulk of our traffic is small packets (less than
	1K bytes), and with small packets, the optimization techniques for
	checksums probably don't pay off much.  In other words, for alot
	of this traffic, the payback for checksum optimization, or even
	elimination wouldn't be worth the risk.  In earlier comments, it
	was mentioned that the checksum algorithm shouldn't really be one
	of the more burdensome throughput bottlenecks.  However, as network
	media speeds increase, and MTU sizes also increase, for those
	vendors that don't have hardware support for checksumming, the
	checksum algorithm may not scale well - meaning that the link layer
	stuff is all much faster, but the packets are still being serialized
	through the same checksum algorithm. 

	(I should note that the profiling I've done on our network was only
	for TCP packets.  I would imagine there are huge amts of full
	MTU-size, fragmented Ethernet packets representing NFS UDP traffic
	that would be consuming cycles for checksumming, provided 
	checksumming was enabled for these packets.) 

	We have been using a modified version of Jacobsen's checksum 
	algorithm, as presented in RFC 1071(?).  We are now in the process of
	combining this algorithm with an existing buffer copy in our stack
	to see what gains we can achieve.  My guess is, since Jacobsen's
	algorithm was using extensive loop unrolling, and was thereby
	neutralizing the 68020 I-cache advantages, we may see some
	improvement.


	Randy
-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Jul 1993 02:47:46 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

In article <rturner.742082007@imagen>, rturner@imagen.com (Randy Turner) writes:
> ...
> >If you accept that, then don't you also accept the statement that for
> >all values of N, the danger P of turning off the TCP checksum is, for
> >all practical purposes, the same as the danger P*(N+1) ?


> 	I agree in part with your probabilities for router/bridge errors,
> 	but I 'm not sure I understand the conclusion you draw from the math.
> 	It seems that for increasing values of N, the probability of failure
> 	in one of the N intermediates also increases.  In other words, the
> 	more pieces you have between the connected hosts, the more likely
> 	it is that one of them might screw up. For a direct link (i.e.
> 	both hosts tapped into the same Ethernet segment) your odds for
> 	failure are somewhat less.

Yes, you're right that I blew the calculation.  I suppose it's
something more like (1 - (1-P)**(N+1)) which does increase a lot faster
than linearly.  But when P=1E-6 and N=5, it's still very close to linear
in N.  (N=5 is about the upper bound on the diameter for almost all of
the traffic I saw, and the error rate was around 1 in 10**5 packets).

However, that wasn't my point, which was that given an observed packet
error rate with <= 5 hops over CRC-safe links of around 1 in 10**5, the
error rate on at least one link in the mess must be 10**6 or worse.  In
practice, 1 in 10**5 is about as bad as 1 in 10**6, and I think both
are completely unusable for data transfers.  (Of course, if you're
just sending voice or pictures, you might be happy with something
100 or 1000 times worse.)

Consider that you're supposed to shut down an individual station-to-
station link in an FDDI ring with a detected bit error rate of 1 in
10**7 and ring bells at 10**8.


> 	Also, I have been studying some traffic here on our network, and
> 	it appears that the bulk of our traffic is small packets (less than
> 	1K bytes),...


Weren't the classic numbers around 50/50 in big and small packets,
whether measured in Bytes/sec or packets/sec?  In recent years, we seen
a lot of small packets.   X-windows generates horrendous numbers of
tinygrams.  Even file transfer stuff like NFS involves an amazing
number of bytes in small packets (getattr's, lookup's, r/w-requests).

Unfortunately, media with big packets like FDDI or HIPPI do not
reduce the number of small packets.  They only reduce the number
of large packets, and because of routers and bridges, not nearly
as much as one would like or expect.


Vernon Schryver,  vjs@sgi.com

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Jul 1993 03:04:18 GMT
From:      cej@world.std.com (Craig E Jackson)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <219ns9$p07@calvin.NYU.EDU> roy@mchip00.med.nyu.edu (Roy Smith) writes:
>cej@world.std.com (Craig E Jackson) writes:
>> 4. Lots of people have quoted TCP speeds for this processor or that.  Few
>> have mentioned how much of the processor was left for the application(s)
>> when running at such speeds.  I would suspect that a printer vendor would
>> prefer that a very high percentage of the processor be delivered to PDL
>> interpretation and imaging.
>
>	Van Jacobson used to saturate ethernets running TCP with a Sun-3/50,
>which is a 16 MHz 68020, no cache.  I suspect that compared to the cost of
>everything else in a printer fast enough to worry about the speed of TCP
>checksumming over ethernet, a cacheless 16 MHz 68020's worth of MIPS would
>just get lost in the noise.
>-- 
>Roy Smith <roy@nyu.edu>

Actually, the person who started this discussion said that what he had
to work with *was* a 16MHz 68020.  Also, he was trying to spiff things
up without redesigning the printer hardware, so changing the processor
wasn't a variable in his inquiries.  (One of the reasons why processors
are embedded in various things is because they can be spiffed up by
changing ROMs.)

I believe that when Van Jacobson got his results on the 3/50, those 68020s were
pretty busy with TCP processing.
-- 
Craig Jackson
cej@world.std.com

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 1993 15:57:54 -0700
From:      hjb@butch.netapp.com (Consultant-Hwa Jin Bae)
To:        comp.protocols.tcp-ip
Subject:   Re: Unexplainable measurement figures ?!

In article <andreas-070793155050@freitag.informatik.rwth-aachen.de> welander@i4.informatik.rwth-aachen.de writes:
>At RWTH Aachen we are presently doing performance measurements with TCP and
>XTP and have come up with some rather strange results that we cannot
>explain.

one of the things i've noticed over the years running "benchmarks" over
various tcp/ip implementations of others as well as my own is that the
number thans to vary almost each time (not much but a little), and that
the varying behavior doesn't seem to have a real "pattern".  that is,
when running tests on unix based machines... this seemed true for both
tcp and xtp.  but if you run the same tests on a realtime operating system
implementations of the same protocols (using almost the same code), 
the result tend to come out precisely equal.  the result is reproduced
almost exactly each time, down to the microsecond.  when you run multiple
instantiations of the benchmarking application, you also see exactly equal
amount of throughput/latency/cpu-usage per each task (or thread or whatever).
this is true of both vxworks and my own little realtime os implementations
of tcpip.  of course, nobody knows why this happens on unix -- not! <grin>

love
hwajin

-- 
Hwa-Jin Bae	*IX/Realtime/Embbeded/Network/HW/SW Consultant	
hjb@netcom.com - Peaceful Star Project   Vox: 510-536-7607 Page: 510-466-9166
hjb@netapp.com - Network Appliance
hjb@hybrid.com - Hybrid Networks

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 1993 11:24:44 -0400
From:      frankb@epenviron.eapi.com (Frank Brock)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs,ieee.nfs
Subject:   SOS as a client?

can SOS provide the client side of nfs for a pc?  are there any known plans 
to do so?

frank brock

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Thu, 08 Jul 93 13:05:29 EDT
From:      NELSON@msu.edu (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.

In article <C9ut0z.D6y@raistlin.udev.cdc.com>
cmclal@lizzie.arh.cdc.com (A. Sudhakarlal) writes:
 
>During ftp sessions , client side TCP receives a packet with checksum 0xFFFF
>from a Novell Flex/IP server. I am not very sure whether a TCP packet could
>have checksum value 0xFFFF. I was looking into RFC 1071. And yet I can not
>figure out the problem. We are having problems in file transfers. Middle of a
>file transfer, connection is getting timed out.
>
>Please throw light on to the problem.
 
This topic has come up before.  Since a TCP checksum is defined as a 16
bit one's complement value, 0xFFFF is equivalent to 0x0000.  However,
since most TCPs are implemented on two's complement systems, or compute
the checksum in a larger word, a special check is needed to treat them
as equivalent.  This check is missing from some TCPs, which likely
includes the system with your client.
 
This shortcoming often slips through a TCP implementation, since the
normal ways of generating the checksum favor 0x0000 over 0xFFFF.
 
Note that UDP, which uses the same 16 bit one's complement checksum,
does not have this problem since 0x0000 is used as a special value.
 
Doug Nelson                     nelson@msu.edu
Network Manager                 Ph: (517) 353-2980
Computer Laboratory
Michigan State University

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 93 14:28:44 CDT
From:      schaubert@turtle.fisher.com
To:        comp.protocols.tcp-ip
Subject:   Need help reading TCP OOB data

 am in the process of learning how to send and receive TCP urgent
(out of band) data and am having some trouble.

I have the following signal handler in my server (listening)
process

void
my_tcp_urg(int signal_id)
{
  char sig_buff[200];
  int size;

  size = recv (newsock, sig_buff, 200, MSG_OOB);
  if (size < 1)
    printf ("Urgent data not ready yet, errno - %d\n",errno);
  else 
    printf ("Urgent data received size %d char %d %c>%s\n",size,sig_buff[0], sig_buff[0], sig_buff);
  urg_flag = 1;
  signal(SIGURG, my_tcp_urg);

}


This signal handler gets called while the program is in the main loop
waiting on non-urgent data.

int getinput (fd, input_buffer, done)
     int fd;
     char *input_buffer;
{
  int x;
  int size;
  int err;

/*
  read (fd,input_buffer,700);
*/
  err = 0;

  x = read (fd, &input_buffer[0], 1);
  if (x < 1) {
    err = 1;
    printf ("Got read error, errno is %d\n",errno);
    if (errno == EBADF) {
      shutdown(fd);
      close(fd);
      exit(0);
    }
    if (errno == EINTR && urg_flag) {
      size = recv (fd, input_buffer, 1, MSG_OOB);
      if (size < 0) {
	printf ("Errno on recv with oob flag is %d\n",errno);
	sleep(1);
	size = recv (fd, input_buffer, 200, 0);
	if (size < 0) {
	  printf ("Failed to get data from non-oob read \n");
	}
      }
      printf ("OOB>, size %d >%s\n",size, input_buffer);
      urg_flag = 0;
    }
  }



So when I try and use this code I am sending a few
non-urgent messages first, then an urgent one.
Here is the client screen (the server prepends ACKG and
echos whatever it received)

Cterm -- use u> to send tcp urgent data
Terminal > 111
ACKG 111
Terminal > 222
ACKG 222
Terminal > u>333
URG - send msg_oob data on socket fd 3
Terminal > 444
ACKG 444

And here is the server screen 

SERVER GOT - 3 111
SERVER GOT - 3 222
Urgent data received size 1 char 0 >
Got read error, errno is 4
Errno on recv with oob flag is 22
OOB>, size 4 >333
SERVER GOT - 3 444


Ok, so this line
Urgent data received size 1 char 0 >
is from the signal handler, why is it only 1 byte?

This line
Got read error, errno is 4
is an EINTR and is the main loop breaking out of the read call
due to an interrupt

This line
Errno on recv with oob flag is 22
I don't uderstand why I am getting an 
EINVAL  22      /* Invalid argument                     */
(my OS is AIX 3.2)
on the recv with the oob flag.

and this line
OOB>, size 4 >333
is where I give up and just read for NON-OOB data.


So can someone show me how to get multiple byte OOB messages through TCP
and handle it properly on the receive side?

Also where can I read a discussion and see some examples of leaving
data inline vs oob?  The Stevens book is not quite as strong on
TCP OOB examples as it is on other areas.


thanks in advance

joel
schaubert@fisher.com



-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 1993 18:46:43 -0400
From:      gregm@db.erau.edu (Gregory S. Miller)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Protocol Stack Author Available


 My apologies to those who'd prefer not to read such things outside of
misc.jobs.*, but I'm afraid that I'm far more likely to reach the correct
audience here than there.

 ---

To whom it may concern:

    I'm currently seeking a position involving networking systems development.
If your company is looking for someone with in-depth knowledge of networking,
specifically the lower levels of protocol stacks, please review the enclosed
resume, and get in touch with me.

    As I explained above, my specialty is everything between the Data Link
and Session layers in a protocol stack.  I've designed (and implemented
from scratch) two entirely seperate IP stacks, while maintaining a third
for my previous employer.  I'm extremely well informed, having done
pure implementations, of how nearly every segment in a TCP/IP suite works.
In addition to protocol stack work, I've designed and developed everything
from implementations of standards (FTP, Telnet, RCP, ...) to entire networking
packages.

    Although I haven't done implementations of other protocol stacks, I am
familiar with several others.  I hold knowledge about many of the different
pieces of OSI, including CLNP and TP4.  I've also researched the different
components of AppleTalk's stack as well.  I'm proficient in many languages,
including C, C++, and Motorola assembly.  I also have a general understanding
of ISDN and ATM, but have worked on no projects directly involving either.

    I'm specifically seeking an ambitious company that intends to lead,
rather than follow the rest of the industry -- that is enthusiastically
planning for the future, not waiting for the future to carry them along.

    - Greg Miller

     -------------------------------------------------------------------


                              Gregory S. Miller
                            190  Lindenwood Drive
                               Exton, PA  19341
                                (215) 594-8756

Objective
            Seeking a software engineering position dealing with networking
            systems development.

Experience
            Commodore International, West Chester, PA.
            Software Engineer
            Responsible for developing and maintaining system software
            for Commodore's Amiga computers.

            o   Project Manager and leader of the design and development
                team for a peer-to-peer networking package for the Amiga.
                Responsible for nearly every part of the project's development,
                including creating a comprehensive design document, laying out
                and submitting project schedules, and ensuring that deadlines
                were met by all involved parties.  Designed and implemented
                the protocol stack, the stack's API, the network filesystem,
                network printing facilities, and associated user interfaces
                for each, as well as other project segments.

            o   Member of the AS225/Release 2 development team.  (AS225 is
                Commodore's TCP/IP package for the Amiga.)  Responsible for
                various modules, including inet.library -- the protocol stack.
                Redesigned the lowest levels of the protocol stack to support
                SANA-II, which allowed TCP/IP operation over any SANA-II
                compliant networking device (Ethernet, ARCNET, SLIP, custom,
                etc.)  Rewrote several of the included user utilities in
                AS225 (Telnet, RCP, etc.).

            o   Member of the SANA-II design and development team.  (SANA-II
                is Commodore's Data Link layer interface standard, designed
                to eliminate dependance on certain networking cards and their
                particular attributes.)  As part of the team, contributed to
                the specification, was responsible for (and implemented)
                several SANA-II device drivers to support Commodore's existing
                networking hardware.

            Milliluk Partnership, Lansing, MI.
            Co-Owner/Operator
            Developed a wide variety of applications for various platforms:

            o   A TCP/IP implementation for the Amiga.  Designed and
                implemented -everything- from the Data Link layer all the
                way up through standard applciations (including clients
                and servers for Telnet, FTP, etc.).

            o   Color Max Deluxe -- a full-featured GUI paint program,
                patterned after MacPaint, and written in several thousand
                lines of 6809 assembly.  Voted "Product of the Year", and
                ranked #1 in sales for six months.

            o   A suite of image manipulation tools that offered exchange
                between Mac, GIF, Atari ST, and MGE file formats.

Education
            Michigan Technological University, Houghton, MI.
            Bachelor of Science in Electrical Engineering, Cum Laude.

References
            Available upon request.


-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Jul 1993 13:57:25 GMT
From:      thurlow@convex.com (Robert Thurlow)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Tips on alternative to NFS requested.

In <1993Jul7.070827.3131@ericsson.se> etxmesa@eos.ericsson.se (Michael Salmon) writes:

>I am looking for an alternative to NFS, preferably TCP based. RFS seems
>to do what I want but I can't yet find a standard for it. All
>suggestions welcome.

I might have some suggestions if I had any clue about what problems
you were trying to solve.  Asking for "better" is only goung to get
you noise, in my opinion, unless we know what "better" would feel
like to you.

Rob T
--
Rob Thurlow, Convex AFS project leader
Convex Computer Corporation, Richardson, TX
(214) 497-4405		thurlow@convex.com

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 93 18:08:19 EDT
From:      joltes@husc10.harvard.edu (Richard Joltes)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Summary:  NFS servers for the PC

I received a number of responses to my query regarding NFS server s/w for
the PC.  They all basically pointed to a package called "SOSS," which
provides the capability I was looking for.

The following came from Francis Selkirk at FTP Software:

-----------
	Any NFS server, including the SOS server that Doug Loss mentioned,
	will be fine with InterDrive. If the current version of SOSS does not
	include a PCNFSD, however, you will need a special program that
	bypasses that authentication. This is free to customers that need it,
	but not part of our standard distribution. (It's a tremendous
	security hole...) Contact me if you go that route.
-----------

The SOSS package is available from dorm.rutgers.edu, in /pub/msdos/packet-
drivers.

Many thanks to everyone who responded.  This is the way the net's supposed
to work!

--------------------------------------------------------------------------------
Dick Joltes						joltes@husc.harvard.edu
Harvard University Science Center


-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 93 14:27:32 GMT
From:      devdjn@space.alcbel.be (Dennis Newport)
To:        comp.protocols.tcp-ip
Subject:   Re: KEEPALIVE option for tcp sockets


The guy who originally posted this article has a valid point. 
I am personally interested in the responses. All that seems to
have occurred so far is that the responses are bitching about
which manual pages he is reading. Old Sun BSD, SunOS 4.1.2 and
HP-UX manual pages are different but they say they same thing
about KEEPALIVE. Does anyone have an answer ?


People don't really seem to answer things in this group. They 
just chat. I have posted a couple of articles to which the
response has been pitiful. To both my articles I received
mail from people asking to forward any responses. Unfortunately
this hasn't been possible due to (almost) complete lack of response.

Do any TCP/IP experts read this group ?  Or is it just something
to browse through while eating lunch ?

---
Dennis Newport,                  email: devdjn@space.alcbel.be
Alcatel Bell Telephone,
Berkenrodelei 33,                phone: (+32) 3/829.5488
2660 Hoboken,
Belgium.


-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Jul 1993 15:12:32 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   Are port numbers < 1023 reserved for the client end of an FTP data connection?

We have an IBM AS/400 system which wants to use port numbers just below 1024
in the PORT command sent from the FTP client to the FTP server (ftpd) on the
remote host. The HP-UX ftpd doesn't like this, and responds:

ftp> quote PORT 129,241,4,6,3,255
---> PORT 129,241,4,6,3,255
530 Bad parameters for PORT command.

After some more checking, I concluded that the HP ftpd accepts port numbers
in the range 0-512, but refuses port numbers in the range 513-1023, in the
PORT command sent by the ftp client.

I reported this error to HP Norway earlier today, and was quickly given a
reply: HP considers this to be the correct behavior (according to RFC-1340),
and does not intend to change it.

I need some net wisdom on this subject: *Are* port numbers < 1024 reserved
for the client end of an FTP data connection? RFC-1340 says on page 9:
----------------------------------------------------------------------
The Well Known Ports are controlled and	assigned by the	IANA and on most
systems	can only be used by system (or root) processes or by programs
executed by privileged users.

Ports are used in the TCP [45,106] to name the ends of logical
connections which carry	long term conversations.  For the purpose of
providing services to unknown callers, a service contact port is
defined.  This list specifies the port used by the server process as its
contact	port.  The contact port	is sometimes called the	"well-known
port".
----------------------------------------------------------------------
And then goes on to list well known ports up to 1000:

   cadlock	   1000/tcp
   ock		   1000/udp

It's quite clear to me that the HP ftpd is *inconsistent* in its behavior,
since it allows port numbers <= 512. But is it in error? Or is the IBM ftp
client in error by using a port number < 1024 in the PORT command? The RFC
section quoted above talks about "service contact port", and this gets a
little fuzzy with FTP since you have one command connection and one data
connection, and the data connection is normally initiated from the FTP
server.

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Jul 1993 15:24:13 GMT
From:      jmc@hal.com (Jerry McCollom)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   Re: Are port numbers < 1023 reserved for the client end of an FTP data connection?


Steinar.Haug@runit.sintef.no (Steinar Haug) writes:

>We have an IBM AS/400 system which wants to use port numbers just below 1024
>in the PORT command sent from the FTP client to the FTP server (ftpd) on the
>remote host. The HP-UX ftpd doesn't like this, and responds:
>
>ftp> quote PORT 129,241,4,6,3,255
>---> PORT 129,241,4,6,3,255
>530 Bad parameters for PORT command.
>
>After some more checking, I concluded that the HP ftpd accepts port numbers
>in the range 0-512, but refuses port numbers in the range 513-1023, in the
>PORT command sent by the ftp client.
>
>I reported this error to HP Norway earlier today, and was quickly given a
>reply: HP considers this to be the correct behavior (according to RFC-1340),
>and does not intend to change it.

What version of HP-UX do you have?  This was a feature of HP-UX 7.0 and
some prior releases, but I believe it was removed in HP-UX 8.0 and later
based on customer complaints and on discussion on comp.protocols.tcp-ip
that concluded (especially, as I remember, after an authoritative reply
from Jon Postel) that it was out of spec.  

I cannot remember if there was a patch for this for HP-UX 7.0 (I no
longer work for HP and so cannot check on this).  I am almost certain it
was removed before the HP-UX 8.0 release (since I did it :-).  However,
I cannot state authoritatively that it was not reintroduced, based on
your observations (I believe the older HPUX 7.0 and earlier code
excluded all ports < 1024; the behavior you observe where it permits
0-512 suggests to me it may have been reintroduced in some sort of
mutated form).

Perhaps somebody from HP (Art?) will be able to give you specifics as to
whether this was fixed and maybe direct you to the appropriate patch.

Your response seems to indicate that the support folks didn't understand
the problem.  A client can specify any valid port it wishes for the data
connection.  The FTP specs say nothing about limiting ports and, in
practice and as you've observed, it is not interoperable with many ftp
clients in the real world.

- Jerry (who speaks for neither HP nor for HaL Computer Systems, Inc.
	 but who does speak for himself)
--
Jerry McCollom
HaL Computer Systems, Inc., Austin, TX
jmc@hal.com

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Jul 1993 16:12:34 GMT
From:      cmclal@lizzie.arh.cdc.com (A. Sudhakarlal)
To:        comp.protocols.tcp-ip
Subject:   Would 0xFFFF ever be a TCP checksum? Comments pls.

During ftp sessions , client side TCP receives a packet with checksum 0xFFFF
from a Novell Flex/IP server. I am not very sure whether a TCP packet could 
have checksum value 0xFFFF. I was looking into RFC 1071. And yet I can not 
figure out the problem. We are having problems in file transfers. Middle of a
file transfer, connection is getting timed out. 

Please throw light on to the problem.



-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Jul 1993 16:53:32 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: KEEPALIVE option for tcp sockets

In article <2081@alcbel.be>, devdjn@space.alcbel.be (Dennis Newport) writes:
> 
> The guy who originally posted this article has a valid point. 
> I am personally interested in the responses. All that seems to
> have occurred so far is that the responses are bitching about
> which manual pages he is reading. Old Sun BSD, SunOS 4.1.2 and
> HP-UX manual pages are different but they say they same thing
> about KEEPALIVE. Does anyone have an answer ?

Without knowing which man page the previous guy was talking about,
how could anyone offer a useful guess?  What if the select() the
guy wanted to know about is only library code to make System V's poll()
look right?  What if the socket code is really something like the old
Excelan socket library?  Even if the code is all 4.3BSD-reno or net2
based, there is no assurance that the vendor has made no changes.
There are a few variants of 4.3BSD select() I might guess about or
check the source or write a test program, but there are far more I
won't guess about.

Until the guy admits which system is involved, no one who might know
will help.  That the brand is still a secret after so many repetitions
of "what system are you talking about?" is itself interesting.


Select() in some BSD systems must return when a keepalive kills a TCP
connection, because the BSD rlogind seems to me to depend on that
behavior.  Look at the source for yourself.  (Do not expect someone
else to look at it for you because you are too lazy or poor.)


> People don't really seem to answer things in this group. They 
> just chat. I have posted a couple of articles to which the
> response has been pitiful. To both my articles I received
> mail from people asking to forward any responses. Unfortunately
> this hasn't been possible due to (almost) complete lack of response.
> 
> Do any TCP/IP experts read this group ?  Or is it just something
> to browse through while eating lunch ?

For some reason beyond my ken, the money you pay for advice doesn't
seem to reach the people whose time you are demanding.  You no doubt
know that $100/hour would be cheap for work.

Once you have answered a reasonable question half a dozen times, it
becomes tiresome.  Besides, it never pays to answer a question like "my
system doesn't work", when the questioner does not know or refuses to
say what brand of system is involved.  Why should "TCP/IP experts" who
are only chatting be interested in solving someone else's basic
programming problem?  It's not as if there are not enough hard bugs to
fix or new stuff to write in the universe.

There is a worse syndrome.  If you lurk in newsgroups for a while, you
notice that almost all articles fit in the following catagories:
    1. boring flames, like yours and this one.
    2. responses to (1), which are usually also members of (1)
    3. interesting statements and questions
    4. responses to (3), which may themselves be members of (3)
    3. nonspecific, impossible to answer questions  ("why doesn't my
	my program work?")
    4. boring, obvious, familiar questions that are asked 3 times/week
	("what is a keepalive", "what is UDP")
    5. responses to (3) and (4) from people who just finished reading
	a textbook or some netnews articles.
    6. responses to (3) and (4) from people who know the answers.
There are far more in (5) than (6), and the accuracy of (5) is what you
would expect--not always wrong but (like the rest of netnews) unreliable.

Netnews is worth no more than what you pay for it.


Vernon Schryver,  vjs@sgi.com

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Jul 1993 17:03:13 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: KEEPALIVE option for tcp sockets

In article <2081@alcbel.be> devdjn@space.alcbel.be writes:

}The guy who originally posted this article has a valid point. 
}I am personally interested in the responses. All that seems to
}have occurred so far is that the responses are bitching about
}which manual pages he is reading. Old Sun BSD, SunOS 4.1.2 and
}HP-UX manual pages are different but they say they same thing
}about KEEPALIVE. Does anyone have an answer ?
 
}People don't really seem to answer things in this group. They 
}just chat. I have posted a couple of articles to which the
}response has been pitiful. To both my articles I received
}mail from people asking to forward any responses. Unfortunately
}this hasn't been possible due to (almost) complete lack of response.
 
}Do any TCP/IP experts read this group ?  Or is it just something
}to browse through while eating lunch ?

This actually has more to do with BSD sockets, but...

Well, here's "man 2 socket" from Ultrix (which is what I am most
familiar with [and which is a BSD4.2 descendent]):

          SO_KEEPALIVE enables the periodic transmission of messages on a
          connected socket.  Should the connected party fail to respond to
          these messages, the connection is considered broken and processes
          using the socket are notified through a SIGIO signal.

                                                                Note that
          in order to receive signals on a socket the program must first
          call fcntl(2) with a F_SETOWN request to set the process group of
          the process to receive the signal, and with a F_SETFL request to
          set the FASYNC flag, which enables the SIGIO signal to be sent.


And here are some code excerpts from a program I wrote:

        (void)signal(SIGIO,   sigcatch);
        if (setsockopt(netfd, SOL_SOCKET, SO_KEEPALIVE, &on, sizeof(on)) < 0) {
                com_err(whoami, errno, "setting keepalive");
                return (1);
        }
        if (fcntl(netfd, F_SETOWN, pid) < 0) {
                com_err(whoami, errno, "setting socket owner");
                return (1);
        }
        fdflgs = fcntl(netfd, F_GETFL, NULL);
        fdflgs |= FASYNC;
        if (fcntl(netfd, F_SETFL, fdflgs) < 0) {
                com_err(whoami, errno, "setting socket flags");
                return (1);
        }

static void sigcatch(sig, code, scp)
        int                     sig;
        int                     code;
        struct sigcontext *     scp;
{
        int     l;

        switch (sig) {
            case SIGPIPE:
                   :
                   :
            case SIGTERM:
                   :
                   :
            case SIGIO:
                l = sizeof(nerrno);
                if (getsockopt(*nfdp, SOL_SOCKET, SO_ERROR, &nerrno, &l) == 0) {
                        if (nerrno == EINTR) nerrno = 0;
                        if (nerrno != 0) caught = sig;
                }
                break;
        }
}

        for (;;) {
                /*
                 * A signal?
                 */
                if (caught) {
                        errno = nerrno;
                        if (caught == SIGPIPE) DiedIn("network(pipe)");
                        if (caught == SIGTERM) DiedIn("ppt(terminated)");
                        if (caught == SIGIO)   DiedIn("network(keepalive)");
                        DiedIn("programmer botch(signal)");
                }
                errno = 0;
                readable = reading;
                writable = writing;
                goofable = readable | writable;
                timeout.tv_sec = done ? 10 : (60 * Delay(n));
                switch (select(32, &readable, &writable, &goofable, &timeout)) {
                     :
                     :


John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 93 17:25:12 GMT
From:      trt@duke.cs.duke.edu (Tom Truscott)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.

>I am not very sure whether a TCP packet could 
>have checksum value 0xFFFF.

A *UDP* (but not TCP) packet can have the checksum value 0xFFFF.  Ordinarily
the value stored is the ones complement of the 16-bit summation.
The summation can yield a value of 0xFFFF, so its ones complement is 0.
But "0" is a special indicator that means "no checksum",
so in that case 0xFFFF is stored (ones-complement summation
makes 0xFFFF and 0 equivalent for valid packets).

A TCP packet can never have a checksum value of 0xFFFF, because that
would mean the sum was 0, which is only possible if the entire packet
consists of 0, but that would be an invalid packet.

=======

What this means is, the current UDP checksumming algorithm was botched!
The "no checksum" value should be the impossible 0xFFFF value,
rather than the current 0 value.
Then no special check for 0 would be needed.

Current UDP algorithm:
	if (nochecksum)
		sum = 0;
	else
	{
		sum = ~end_around_16_bit_sum(packet);
		if (sum == 0)
			sum = 0xffff;
	}
	packet.checksum = sum;

The way it should have been:
	packet.checksum = ~(nochecksum? 0: end_around_16_bit_sum(packet));

=======

Tom Truscott

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 1993 17:28:09 GMT
From:      corrigan@weber.ucsd.edu (Michael J. Corrigan)
To:        comp.protocols.tcp-ip,comp.sys.hp
Cc:        corrigan
Subject:   Re: Are port numbers < 1023 reserved for the client end of an FTP data connection?

It is still (again?) in HP-UX 8.x.

ftpd from:
wuarchive.wustl.edu:packages/wuarchive-ftpd
builds fine under HP-UX, and doesn't have this problem.

-Mike Corrigan

In <JMC.93Jul8102407@jayhawk.hal.com> Jerry McCollom <jmc@hal.com> wrote:
>What version of HP-UX do you have?  This was a feature of HP-UX 7.0 and
>some prior releases, but I believe it was removed in HP-UX 8.0 and later
>based on customer complaints and on discussion on comp.protocols.tcp-ip
>that concluded (especially, as I remember, after an authoritative reply
>from Jon Postel) that it was out of spec.  
>
>I cannot remember if there was a patch for this for HP-UX 7.0 (I no
>longer work for HP and so cannot check on this).  I am almost certain it
>was removed before the HP-UX 8.0 release (since I did it :-).  However,
>I cannot state authoritatively that it was not reintroduced, based on
>your observations (I believe the older HPUX 7.0 and earlier code
>excluded all ports < 1024; the behavior you observe where it permits
>0-512 suggests to me it may have been reintroduced in some sort of
>mutated form).
>
>Perhaps somebody from HP (Art?) will be able to give you specifics as to
>whether this was fixed and maybe direct you to the appropriate patch.
>
>Your response seems to indicate that the support folks didn't understand
>the problem.  A client can specify any valid port it wishes for the data
>connection.  The FTP specs say nothing about limiting ports and, in
>practice and as you've observed, it is not interoperable with many ftp
>clients in the real world.
>
>- Jerry (who speaks for neither HP nor for HaL Computer Systems, Inc.
>	 but who does speak for himself)
>--
>Jerry McCollom
>HaL Computer Systems, Inc., Austin, TX
>jmc@hal.com



-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Jul 1993 17:53:49 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.

In article <C9ut0z.D6y@raistlin.udev.cdc.com>, cmclal@lizzie.arh.cdc.com (A. Sudhakarlal) writes:
> During ftp sessions , client side TCP receives a packet with checksum 0xFFFF
> from a Novell Flex/IP server. I am not very sure whether a TCP packet could 
> have checksum value 0xFFFF. I was looking into RFC 1071. And yet I can not 
> figure out the problem. We are having problems in file transfers. Middle of a
> file transfer, connection is getting timed out. 
> 
> Please throw light on to the problem.


Since you must have the whole packet to know the checksum is 0xffff,
the best way to procede is to manually compute the checksum yourself.

Or write a quick and dirty program in C or awk (or BASIC or whatever)
to compute the checksum.

There is C code for the IP checksum in many places.  I'd start with
the BSD portable version.  Look on uunet in the net2 source.

Or, given a return address in *.cdc.com, the source of any of the many 
implementations that CDC has.


Vernon Schryver,  vjs@sgi.com

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Jul 1993 22:58:53 EST
From:      Rogelio Montanana (MONTANAN at EVALUN11) <MONTANAN@EVALUN11.BITNET>
To:        comp.protocols.tcp-ip
Subject:   Can I use TCP/IP over satellite links?

We are a group of four Universities that want to be connected by high speed
links (2 Mb or higher), without using the PTT services, that happen to be very
expensive in Spain. The topology would be a star with three links, the
distances varying from about 8 Km to about 100 Km. The main protocol used
is TCP/IP.

Talking with telecommunication specialists they recommend satellite links
(they call it VSAT); I remember to have read somewhere that satellite
links introduce long delays in the packets sent (something between half a
second and two seconds maybe?). It worries me because, for example,
using telnet with remote echo means two packets sent per key, and half a
second delay would be unacceptable in this situation. The specialists
claim that it is no problem, but I am not so sure.


Is anybody over there using satellite links for interactive applications,
like telnet? I will appreciate hearing of any experience using satellite
links in TCP/IP networks.

Regards,
Rogelio.

Rogelio Montanana, System Analyst             Tel:(346)3864310 Fax:(346)3864200
Valencia Univ. Computer Center                     Bitnet: montanan at evalun11
Dr. Moliner, 50                                  Internet: montanan@vm.ci.uv.es
46100 Burjassot                   Hepnet: evalun::montanan (or 16530::montanan)
Spain                 X400: C=es;A=mensatex;P=iris;O=uv;OU=ci;OU=vm;SN=montanan

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Jul 1993 18:56:29 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.

In article <742152311@romeo.cs.duke.edu>, trt@duke.cs.duke.edu (Tom Truscott) writes:
> >I am not very sure whether a TCP packet could 
> >have checksum value 0xFFFF.
> 
> A *UDP* (but not TCP) packet can have the checksum value 0xFFFF.  Ordinarily
> the value stored is the ones complement of the 16-bit summation.
> The summation can yield a value of 0xFFFF, so its ones complement is 0.
> But "0" is a special indicator that means "no checksum",
> so in that case 0xFFFF is stored (ones-complement summation
> makes 0xFFFF and 0 equivalent for valid packets).
> 
> A TCP packet can never have a checksum value of 0xFFFF, because that
> would mean the sum was 0, which is only possible if the entire packet
> consists of 0, but that would be an invalid packet.


    -The 4.3BSD based TCP/IP and UDP/IP code I know about uses exactly
	the same functions to compute and check the TCP and UDP checksums.
	The conversion of 0 to 0xffff needed for UDP is thereby done
	to TCP packets.

    -Consider a TCP packet containing no options, and 2 bytes of user
	data, where that data just happens to consist of the 1's complement
	of the checksum of the TCP header and psuedo-header.
	What would be the TCP checksum of such a TCP packet?


Vernon Schryver,  vjs@sgi.com

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Jul 1993 19:18:52 GMT
From:      kfisher3@mach1.wlu.ca (kevin fisher U)
To:        comp.protocols.tcp-ip
Subject:   Rexec problem!


Hi folks:

	I'm trying to write a small program that rexec's another program on
a remote machine.  This remote program is a curses based administration
program for our budget database.  What I did is, I rexec'd the program on
the remote machine, and used the socket that was returned to ferry the local
I/O to the remote machine, and vice versa.  It works no problem, except for
the fact that whenever the remote machine prints something to stdout, the
screen (on the local machine) will be immediately cleared after printing it.

I don't think this is a curses problem, as when i resh() the same program,
the screen clearing fluke doesn't happen.

Incidentally, to handle the I/O from the socket on the local machine, I just
fork() and send the socket to two functions, one that reads from the socket
and the other that writes to it (after grabbing stuff from local stdin), all
character by character.   Oh, and the local terminal is in a raw() mode as
well, so buffering isn't an issue.

Any help would be greatly appreciated (sorry if this sounds a bit vague...)



-- 
Kevin Fisher  ><> 	|           WLU - - Home of the 
kfisher3@mach1.wlu.ca   |  Internationally Bright Young Thingies 

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Jul 1993 19:52:32 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   Re: Are port numbers < 1023 reserved for the client end of an FTP data connection?

jmc@hal.com (Jerry McCollom) writes:
> What version of HP-UX do you have?  This was a feature of HP-UX 7.0 and
> some prior releases, but I believe it was removed in HP-UX 8.0 and later
> based on customer complaints and on discussion on comp.protocols.tcp-ip
> that concluded (especially, as I remember, after an authoritative reply
> from Jon Postel) that it was out of spec.  

It is in all the versions of HP-UX I have checked:

	HP-UX 8.0	s400
	HP-UX 8.07	s700
	HP-UX 9.0	s700
	HP-UX 9.01	s700
	HP-UX 9.0	s800

I would be extremely interested if you could dig up that answer from
Jon Postel.

> I cannot remember if there was a patch for this for HP-UX 7.0 (I no
> longer work for HP and so cannot check on this).  I am almost certain it
> was removed before the HP-UX 8.0 release (since I did it :-).  However,
> I cannot state authoritatively that it was not reintroduced, based on
> your observations (I believe the older HPUX 7.0 and earlier code
> excluded all ports < 1024; the behavior you observe where it permits
> 0-512 suggests to me it may have been reintroduced in some sort of
> mutated form).

If you actually remember removing it, it has definitely been reintroduced.

> Your response seems to indicate that the support folks didn't understand
> the problem.  A client can specify any valid port it wishes for the data
> connection.  The FTP specs say nothing about limiting ports and, in
> practice and as you've observed, it is not interoperable with many ftp
> clients in the real world.

That's basically my interpretation also. Unfortunately the HP support
folks here in Norway (who answered quickly and efficiently, just not the
answer I wanted) dug up a similar case (also involving an AS/400), and
said, in effect, that "HP has decided that it follows the standard; case
closed". I'm trying to dig up supporting evidence for *not* closing the
case.

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Jul 1993 19:57:27 GMT
From:      kudzu@netcom.com (Michael Sierchio)
To:        comp.protocols.tcp-ip
Subject:   Re: KEEPALIVE option for tcp sockets

In article <j1hf31k@rhyolite.wpd.sgi.com> 
    vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>Netnews is worth no more than what you pay for it.

I must disagree.  See my scientific survey results below:


Advice value *        Percentage of Netnews
-------------------------------------------


     0                   90%
	infinite               5%
   less than zero         5%

* (the cost of actually *following* bad advice makes it very expensive. If
it is of any value at all, It's worth infinitely more than the price paid).

Anyway, my check for "Infinity" is in the mail, Vernon.
-- 
+--------------------------------------------------------------------------+
|  Michael Sierchio                          1563 Solano Avenue, Suite 123 |
|  kudzu@netcom.com                                Berkeley, CA 94707-2116 |
+--------------------------------------------------------------------------+

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Jul 1993 20:16:22 GMT
From:      clm@uiuc.edu (C Lance Moxley)
To:        comp.unix.admin,comp.protocols.tcp-ip,comp.unix.aix
Subject:   Where did I come from?

How can I tell where I've telnetted from? I have a service I provide
on an IBM RS/6000 AIX3.2.3e that users telnet to. I take them and
do a tn3270 for them to our mainframe for access to our library
circulation system. What I'd like to do is route certain clients
certain directions for them when they telnet to my box. For example
users on this campus (uiuc.edu) should go one way, but maybe users
at Southern Illinois (siu.edu) should go elsewhere. It seems that
/var/adm/wtmp has some of what I need through the who command, but
it's truncated at about 16 characters. Obviously what I want to key
on is the LAST few characters and a long hostname may not have the
last part of the domainname in wtmp.

How can this be handled? Any and all ideas are welcome!

-- 
C Lance Moxley                      Internet: clm@uiuc.edu
AISS/Telecommunications               BITNET: UNETCLM at UICVMC
University of Illinois                  UUCP: uunet!uiucuxc!uiuc.edu!clm

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Jul 1993 20:41:19 GMT
From:      tmm@apollo.HP.COM (Thomas M. Mistretta)
To:        comp.protocols.tcp-ip,comp.networks.noctools.wanted
Subject:   Request for tools/test suites for IP routers

Could anyone recommend any tools or suites to test and validate the operation
of an IP router?  Specifically, we would like to examine fragmentation,
IP option handling, ICMP, etc., in addition to various routing protocols like
RIP, OSPF, and HELLO.  Realistically - at a minimum - we would like to see
testing of the guidelines set forth in RFC-1009: "Requirements for Internet
Gateways."  Any response would be appreciated.

Thanks.
Tom Mistretta                         tmm@apollo.hp.com

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Jul 1993 21:27:33 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.

In article <16C05B870.NELSON@msu.edu> NELSON@msu.edu (Doug Nelson) writes:
>In article <C9ut0z.D6y@raistlin.udev.cdc.com>
>cmclal@lizzie.arh.cdc.com (A. Sudhakarlal) writes:
>>During ftp sessions , client side TCP receives a packet with checksum 0xFFFF
>>from a Novell Flex/IP server. I am not very sure whether a TCP packet could
>>have checksum value 0xFFFF. I was looking into RFC 1071. And yet I can not
>>figure out the problem. We are having problems in file transfers. Middle of a
>>file transfer, connection is getting timed out.
> 
>This topic has come up before.  Since a TCP checksum is defined as a 16
>bit one's complement value, 0xFFFF is equivalent to 0x0000.  However,
>since most TCPs are implemented on two's complement systems, or compute
>the checksum in a larger word, a special check is needed to treat them
>as equivalent.  This check is missing from some TCPs, which likely
>includes the system with your client.

There's no need for a special check.  The proper way to check the TCP
checksum is to checksum received packets with the TCP checksum still
*in* the packet.  If, on a twos complement machine, you don't get a
checksum of 0xffff, the check is a failure.  It doesn't matter whether
the checksum in the packet was 0 or 0xffff.  (I've never figured out
if this characteristic of the TCP/IP checksum was intentional...)

I think i'm the one that made the NetWare TCP code send 0xffff instead
of zero, but now i can't remember why i did it.  Could it be that the
UNIX implementations Vernon was refering to, the ones that used the
same routine to calculate the UDP and TCP checksum, would choke if
they received a checksum set to 0?
						don provan
						donp@novell.com

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 93 21:44:00 GMT
From:      trt@duke.cs.duke.edu (Tom Truscott)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.

>
>    -The 4.3BSD based TCP/IP and UDP/IP code I know about uses exactly
>	the same functions to compute and check the TCP and UDP checksums.

Yes.  in_cksum() is used to calculate the checksum.
I should have used it in my pseudo-code.  Sorry about that.
But special code for UDP substitutes 0xffff if 0 is returned.
This is done only for UDP, since checksumming is optional only for UDP :-(
(For example, in the net-2 release  see udp_usrreq.c:342 and tcp_output.c:382)


>    -Consider a TCP packet containing no options, and 2 bytes of user
>	data, where that data just happens to consist of the 1's complement
>	of the checksum of the TCP header and psuedo-header.
>	What would be the TCP checksum of such a TCP packet?

It would be 0.
Suppose X is the checksum of the header (and the value of the data).
So ~X must be the sum of the header.
So the total sum is ~X + X == 0xffff.
So the checksum (the 1's complement of the end-around-carry sum) is 0.

Another example: suppose the header and data each sum to 0xffff.
Then the total sum is again 0xffff thanks to end-around carry.

Tom Truscott

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 93 22:05:56 GMT
From:      trt@duke.cs.duke.edu (Tom Truscott)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.

>I think i'm the one that made the NetWare TCP code send 0xffff instead
>of zero, but now i can't remember why i did it.

There is no need to do it for TCP.
You don't *need* to do it for UDP.
The reason why you *should* do it for UDP is that otherwise
one in 64k random packets will have a checksum of 0
which the receiver will interpret as "no checksum".
That could dramatically increase the undetected error rate.

If 0xffff had been used as the "no checksum" value
then no special check would have been needed (see previous article).

The checksum is simple, but has been obfuscated by overloading
of the term "ones complement".
	The ones complement of the sum.
	The ones complement sum.
	The ones complement computer.
Yuck.

Tom Truscott

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 1993 23:23:53 GMT
From:      louie@sayshell.umd.edu (Louis A. Mamakos)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.

In article <742152311@romeo.cs.duke.edu> trt@duke.cs.duke.edu (Tom Truscott) writes:
>>I am not very sure whether a TCP packet could 
>>have checksum value 0xFFFF.

Sure it should.  (I assume you mean the contents of the checksum TCP
header field.)

I had it easy; the IP stack that I did actually ran on a 1's
complement computer (on the other hand it was a word-addressable 36
bit machine, so I didn't have it all *that* easy; you should see my
analog of htonl(), etc!)

>A *UDP* (but not TCP) packet can have the checksum value 0xFFFF.  Ordinarily
>the value stored is the ones complement of the 16-bit summation.
>The summation can yield a value of 0xFFFF, so its ones complement is 0.
>But "0" is a special indicator that means "no checksum",
>so in that case 0xFFFF is stored (ones-complement summation
>makes 0xFFFF and 0 equivalent for valid packets).

You have it backwards.  Don't confuse implementation from the
underlying arithmetic.  Remember that the IP protocol suite checksums
are computed using 1's complement arithmetic, with end-around-carry
and all that good stuff.  One 1's complement CPUs, you have two
distinct representations of the value of zero.  One is all zero bits
(+0) and the other is all one bits (-0).

Arithmetically, 0 == 0xffff (that is, +0 == -0) for a 16 bit integer
on a 1's complement machine.  The ALU on such a machine will never
normally give you a negative zero as the result of an arithmetic
operation (such as computing a sum).

>A TCP packet can never have a checksum value of 0xFFFF, because that
>would mean the sum was 0, which is only possible if the entire packet
>consists of 0, but that would be an invalid packet.

Again, you're confusing implementation of 1's complement arithmetic on
2's complement hardware.  On a 1's complement CPU, you'll never get a
computed value of 0xffff doing the sum!

So, if you end up with a checksum of zero, putting the 1's complement
of it (that is its negative value) in the packet will result in 0xffff
which is why you see it in there.

Obviously, the reason you put the complement of the computed value in
the checksum field is so a checksum of the packet will come out to
zero.  (Since 0xffff == -0 == 0);

Louis Mamakos
University of Maryland

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 1993 23:28:22 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.

In article <742169155@romeo.cs.duke.edu> trt@duke.cs.duke.edu (Tom Truscott) writes:
>If 0xffff had been used as the "no checksum" value
>then no special check would have been needed (see previous article).

No, that is not true.  What is the checksum of 4 bytes with contents
0000 0000?  (sum = 0000, so the checksum is ffff.)  What is the checksum
for 4 bytes with contents 0000 ffff?  (sum = ffff, so the checksum is
0000.)

There is no "impossible" result for the checksum.  The UDP checksum
semantics therefore do work -- a 0000 checksum is transmitted as ffff,
and a transmitted 0000 means "no checksum".

-- 
Stephen Trier (trier@ins.cwru.edu - MIME OK)   
Network Software Engineer              
IRIS/INS/T                               
Case Western Reserve University             

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 1993 08:28:40 -0400
From:      dsc@xray.hmc.psu.edu (David S. Channin)
To:        news.announce.newgroups,news.groups,sci.med,sci.med.physics,sci.med.telemedicine,sci.image.processing,comp.graphics,comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   RESULT: comp.protocols.dicom passes 147:22

                         RESULT: comp.protocols.dicom

 The voting for the proposed newsgroup comp.protocols.dicom was concluded at
 23:59 EST on 8 July 1993.
 
 169 valid votes were received:
 
   147 YES votes (in favor of creation)
     22  NO  votes (opposed to creation)
     
In accordance with tradition, there being at least 100 more yes votes
than no votes, and at least two-thirds of the votes being in favor,
the proposal for the creation of the newsgroup comp.protocol.dicom
PASSES.

Thank you to those who participated.

For off-line discussion concerning this vote, please contact:
  
  dsc@xray.hmc.psu.edu
  
  David S. Channin
  Department of Radiology
  Section of Radiologic Computing and Imaging Science
  Penn State University
  The Milton S. Hershey Medical Center
  P.O. Box 850
  Hershey, PA 17033
  (717) 531 - 5728
  


YES votes:
 Zenon Fortuna <zenon@resonex.com>
 Khanh Ly <k.ly@trl.oz.au>
 elang@cs.unsw.oz.au (E   Setiawan)
 McBride_Brian/pinewood_lab_hpopd@hpopd.pwd.hp.com
 add@philabs.Philips.Com  (Aninda Dasgupta)
 Eric LaPresto <lapresto@bme.ri.ccf.org>
 weinhous@alpha.hahnemann.edu (Martin S. Weinhous Ph.D.)
 Andy Hewett <Andy.Hewett@arbi.informatik.uni-oldenburg.de>
 cjoa@fciad3.bsd.uchicago.edu
 "Gerald Q. Maguire" <maguire@cs.columbia.edu>
 gargulak@colossus.med.ge.com (Anthony Gargulak 5-4308)
 Andrew Schmidt <schmidt@cs.uiuc.edu>
 Randolph Gladish <randy@topaz.bds.com>
 diro@edison.Phone.North.DE (Dirk Rode)
 wmihalo@rdth2.rdth.luc.edu (William E. Mihalo, PhD)
 Chet Mazur <chet@spock.retix.com>
 mjb@cs.brown.edu (Manish Butte)
 steve.strother@vapet.uucp@cs.umn.edu (Steven Strother)
 "Fred Prior, Ph.D." <prior@radmail.xray.hmc.psu.edu>
 INFOMED@ccvax.unicamp.br
 kevino@nmgw.nm.nasu.toshiba.co.jp (Kevin O'Donnell)
 David Haynor <haynor@u.washington.edu>
 swire@Kodak.COM (Alan Swire)
 ploeger@aplki.toppoint.de (Andreas Ploeger)
 Alan R. Bleier <bleier@NORMAN.VI.RI.CMU.EDU>
 gerry@cs.tamu.edu (Gerald J Creager)
 jbono@atl.com
 gpmcdona@cats.UCSC.EDU (Glenn McDonald)
 jhoben@jwh.win.net (John W. Hoben)
 diegert@cs.sandia.gov (Carl F. Diegert)
 stanley@kpc.com (Stanley Guan)
 T.CASEY@cardiff-institute.ac.uk
 nightowl@brimston.apana.org.au (Leanne Taylor)
 jkippen@newssun.med.miami.edu (Jonathan Kippenhan)
 robday@uniwa.uwa.edu.au (Robert Day)
 93CRBM@npd1.ufpe.br
 sippel@mallet.med.ge.com (Teri Sippel 5-5045)
 mitrakos@cperi.forth.gr (Dimitris Mitrakos)
 Richard L. Morin Ph.D. <morin@mayo.edu>
 smm@wuerl.WUstl.EDU (Steve Moore)
 giorgos@cs.rochester.edu
 Ken Krippner <kek@cms-stl.com>
 Peter Hauke <se92psh@brunel.ac.uk>
 shukky@acs.bu.edu (Joshua Blume)
 Dan Ritt <danritt@csn.org>
 dclunie@pax.tpa.com.au (David Clunie)
 Paul Mockapetris <pvm@ISI.EDU>
 KATER@WSUHUB.UC.TWSU.EDU
 jkkjasio@psk2.am.lod.edu.pl (jan k.kaminski)
 parisot@mmi3.med.ge.com (Charles Parisot 5-5857)
 RAY DEININGER <R_DEININGER@uvmvax.uvm.edu>
 asw2s@palm.cs.virginia.edu
 wes@wes.win.net (Wes Rishel)
 alex@vuse.vanderbilt.edu (Alexander P. Zijdenbos)
 hlavac@prip.tuwien.ac.at
 minmail@mindymail.win.net (MINDY NEMON)
 mitchell@alydar.crd.ge.com (Robert Mitchell)
 ph@physiology.oxford.ac.uk (Patrick Haggard)
 ewert@nasse.cb.uu.se
 chassign@lix.polytechnique.fr (Chassignet Philippe)
 arneny@mikrosys.no (Arne Nylund)
 mct@philabs.Philips.Com  (Mark C. Tucker)
 gary@maestro.mitre.org (Gary Bisaga)
 nrd@lenti.med.umn.edu
 "Umberto Tachinardi, MD" <TACHINARDI@incor.hc.usp.ansp.br>
 gerrit@isgtec.com (Gerrit Visser)
 Hedley Bond <bond@scanner.hosp.utk.edu>
 jlc@adaclabs.com (Jean-Luc Chatelain)
 berman@nlm.nih.gov (Lewis Berman)
 "Paul Picot" <ppicot@irus.rri.uwo.ca>
 Brendan Forsyth <bff@csn.org>
 jpower@atl.com
 clay@cool.vortech.com (Clay Luther)
 jperser@pluto.vortech.com (John Perser)
 TALLANTJ.DFP@mhs.unc.edu (TALLANTJ)
 Trevor Cradduck <trevorc@uwovax.uwo.ca>
 dsc@xray.hmc.psu.edu (David S. Channin)
 Peter Hauke <se92psh@brunel.ac.uk>
 shin@nop.han.de (Hoen-oh Shin)
 Allan Noordvyk <allan@blue>
 nam@modu.etri.re.kr (Nam Ji-Seung)
 Martin Ohly <mjo@enterprise.DHZB.DE>
 jvpardo@vapet.uucp@cs.umn.edu (Jose V. Pardo)
 John.B.Weaver@Dartmouth.EDU (John B. Weaver)
 maj%mdis1@wdl1.wdl.loral.com (Michael A Johnston)
 James Harrison <james@hplb.hpl.hp.com>
 lsven@uckbv1.ece.uc.EDU (Sven Loncaric)
 andress@penfold.siemens.com (Keith M Andress)
 <NAM110@PSUVM.PSU.EDU>
 rob horn <horn%temerity@leia.polaroid.com>
 kelly@simvax.labmed.umn.edu
 curran@stereo.medphysics.nemc.org (Bruce Curran)
 srl@wdl1.wdl.loral.com (Steve Lennon)
 Alan Strassberg <alan@lscruz.scf.lmsc.lockheed.com>
 dgb@mrindigo.utmb.edu
 hagmanti@cps.msu.edu
 Brian F Long <bflong@convex.csd.uwm.edu>
 Lutz Kleinholz <lutz@enterprise.DHZB.DE>
 Merge Technologies Inc. <Merge.Tech@mixcom.mixcom.com>
 herbison@lassie.ucx.lkg.dec.com (B.J.)
 "Cor Posch, Automatisering, AZUA - AMC, Amsterdam." <POSCH@amc.uva.nl>
 Bill Bennett <Bill_Bennett@qmserver.vortech.com>
 vezina@jupiter.drev.dnd.ca (Guy Vezina)
 Mark Wofford <mgw@cool.vortech.com>
 frank@frank.vortech.com (Frank Ely)
 brianl@vortech.com (Brian Lind)
 Erik Strom <Erik_Strom@qmserver.vortech.com>
 betsy@vortech.com (Betsy Zimmerman)
 bmadsen@tribble.vortech.com (Brian Madsen)
 hchen@mr.picker.com (hong chen)
 gaeta@picker.com (Jay Gaeta)
 Paul Hodgkinson <phh@de-montfort.ac.uk>
 kaka@mallet.med.ge.com (Khuzema Kaka)
 barbiaux@iscmed.med.ge.com (Bill Barbiaux x5-8283)
 "Allan G. Farman, PhD, MBA" <AGFARM01@ULKYVM.LOUISVILLE.EDU>
 barnett@alydar.crd.ge.com (Bruce Barnett)
 mcconnell@hal.hahnemann.edu
 speer@CS.UCLA.EDU (Rick Speer)
 brendt@dip1.ee.uct.ac.za (Brendt Wohlberg)
 Michael Marrin <marrin@fhs.csu.McMaster.CA>
 jc@relito.medeng.wfu.edu (John Campbell)
 eric@mitra.com (Eric Peterson)
 bennett@Kodak.COM (Gordon Bennett 253-7947)
 TALLANTJ.DFP@mhs.unc.edu (TALLANTJ)
 buchanan@bme8.utmem.edu
 areynold@rpms.ac.uk (Anthony Reynolds)
 calvin@vortech.vortech.com (Calvin Head)
 jjr@sparkey.att.com
 ensa@infomed.cu (Emp. Nac. de Servicios Aereos)
 Nadim Yared <yared@inf.enst.fr>
 "Gordon A. Sterling" <gordon.sterling@analog.com>
 Dr D J Harvey 92 <wdrdjh@thor.cardiff.ac.uk>
 kall@mayo.EDU (Bruce Kall)
 diana@Kodak.COM (Gary Diana)
 bennett@Kodak.COM (Gordon Bennett 253-7947)
 phillier@techsup1.hobbit.gandalf.ca (Peter Hillier)
 Trevor Cradduck <trevorc@uwovax.uwo.ca>
 Xiaohua Xuan <xuan@hpsrjtc.sr.hp.com>
 hucaby@mri.uky.edu (David Hucaby)
 Eugene Lief <lief@zeno.rice.edu>
 Hardcore Alaskan <FSSPR@acad3.alaska.edu>
 D. Kris Rovell-Rixx <rovell@hpana0.an.hp.com>
 ram@mr.picker.com (Bob Marino)
 Robert Nowotny <NOWORO1@VM.AKH-WIEN.AC.AT>
 root@manoj.austin.ibm.com
 lrt@poirot.siemens.com (Lawrence R. Tarbox)
 comaxs03@asnmail.asc.edu (Alan Scales)

NO votes:
 L Jonas Olsson <ljo@vger.EEAP.CWRU.Edu>
 txj2421@cs.rit.edu (Thomas X Jagodits)
 bourland@mayo.EDU (Dan Bourland)
 julian@bongo.tele.com (Julian Macassey)
 Shane Hartman <shane@spr.com>
 maus@fid.morgan.com (Malcolm Austin)
 eharold@sunspot.noao.edu (Elliotte Harold)
 Tim Pierce <twpierce@unix.amherst.edu>
 srogers@tad.eds.com (Steve Rogers)
 cmarble@fenris.claremont.edu (Chris Marble)
 bogstad@blaze.cs.jhu.edu (Bill Bogstad)
 rick@crick.ssctr.bcm.tmc.edu (Richard H. Miller)
 Murray Nesbitt <pseudo!mjn>
 jfurr@polaris.async.vt.edu (Joel Furr)
 "Eric J. Olson" <ejo@kaja.gi.alaska.edu>
 Marc Moorcroft <smarry@zooid.guild.org>
 Georg Schwarz <georg@marie.physik.tu-berlin.de>
 Bill Owens <owens@desperado.cc.rochester.edu>
 wbrand@lehman.com (Willy Brandsdorfer)
 gt0670e@prism.gatech.edu (Brennan Tennesen Price)
 srogers@tad.eds.com (Steve Rogers)
 Keith Sklower <sklower@vangogh.CS.Berkeley.EDU>

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jul 93 01:55:52 GMT
From:      ddl@burrhus.harvard.edu (Dan Lanciani)
To:        bit.listserv.ibmtcp-l,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.servers,comp.bugs.4bsd,comp.bugs.misc
Subject:   Re: Bug in many versions of TCP

In article <1993Jul7.195317.3075@xylogics.com>, carlson@steam.Xylogics.COM (James Carlson) writes:

| IMPORTANT BUG FIX FOR TCP INPUT CODE
| 
| Xylogics has found and fixed a bug that exists in the tcp_input.c
| routine in 4.4BSD and several other versions of TCP.  We strongly
| recommend that you examine your version of TCP for this error.

Interestingly, I recently posted a fix for this same code in relation
to the self-connect problem.  Both problems are caused by throwing away
perfectly good ACKs just because data was trimmed.  While I believe
Xylogics' patch will work, it does introduce some unnecessary code;
to wit:

| 			if ((tiflags & TH_FIN) && todrop == ti->ti_len + 1)
| 				tiflags &= ~TH_FIN;

At this point, we already know that either TH_FIN wasn't set to begin with
or todrop is greater than ti->ti_len.  Therefore, TH_FIN can be cleared
unconditionally.  The first clause of the suggested if() statement is moot,
so the only time this would make a difference is if todrop is greater than
ti->ti_len + 1 with TH_FIN set.  That condition would imply a FIN occupying
the sequence number of previously transmitted data, a weird situation to
say the least!

				Dan Lanciani
				ddl@harvard.*

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jul 1993 02:15:47 GMT
From:      lance@deja-vu.aiss.uiuc.edu (C Lance Moxley)
To:        comp.unix.aix,comp.unix.admin,comp.protocols.tcp-ip,comp.lang.perl
Subject:   AIX /etc/utmp

A little while ago I asked about how to find out the fully
qualified domainname where I've telenetted from. Below is a
perl script that was sent to me. It has a problem with AIX's
/etc/utmp file. Also below is what happens when I run the script.
Are there any perl experts out there that can tell me how to
modify this script to find the proper string in /etc/utmp?

The output from the script:

/,)ѯ/: unmatched () in regexp at ./displayhost line 26.

The script with line 26 in arrows:

#!/usr/local/bin/perl
 
# Find the name of the host from which a user is logged in.
# This is necessary because utmp entries truncate the host name,
# often losing necessary information.
#
# USAGE: setenv DISPLAY `displayhost`:0
#
# Written by Patrick Nolan (pln@egret0.stanford.edu) April 4, 1993
#
# Inspired by a shell script of the same name written by
# don@mars.dgrc.doc.ca (Donald McLachlan), 11/12/92

#require 'sys/socket.ph';
$AF_INET = 2;

# Use `tty` to get the name of the tty device.  Look around in
# utmp file to find entry with a matching device.  The first
# 16 characters of the remote host name is in utmp.

$ttyname = (`tty`)[0];
$host = "";
open (UTMP, "/etc/utmp") || die "Can't open /etc/utmp\n";
while (read(UTMP, $utmp_rec, 36)) {
 ($tty,$userid,$ut_host,$time) = unpack("A8 A8 A16 L", $utmp_rec);
---->  $host = $ut_host if $tty && ($ttyname =~ /$tty/); <----
  last if $host;
}
close(UTMP);

# If there's no valid host, then we are logged in locally.  This is easy.

if ($host eq "" || $host eq ":0.0") {
   print `hostname`;   # Already contains \n
   exit;  }

else {

# This is a remote login.
# Use netstat -n to get the host address associated with each
# established net connection.  Find the full hostname associated
# with each one.  Take the first one which contains our partial
# hostname.

   foreach (`netstat -n`) {
     if (/ESTABLISHED/) {
       $adrs = pack("C4", split(/\./, (split)[4]));  # Convert addrs to word
       $fullname = (gethostbyaddr($adrs, $AF_INET))[0];
       if ($fullname =~ $host) {  # See if it matches partial host
         print $fullname,"\n";
         exit;
         }
      }
   }
 exit -1;
}


Thanks for any help anyone can provide!
-- 
C Lance Moxley                      Internet: clm@uiuc.edu
AISS/Telecommunications               BITNET: UNETCLM at UICVMC
University of Illinois                  UUCP: uunet!uiucuxc!uiuc.edu!clm

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jul 1993 03:02:14 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.

In article <1993Jul8.212733.29176@novell.com>, donp@novell.com (don provan) writes:
> ...
> I think i'm the one that made the NetWare TCP code send 0xffff instead
> of zero, but now i can't remember why i did it.  Could it be that the
> UNIX implementations Vernon was refering to, the ones that used the
> same routine to calculate the UDP and TCP checksum, would choke if
> they received a checksum set to 0?


Actually, I'm wrong.  It turns out that udp_usrreq.c does:

    if (udpcksum && uh->uh_sum) {
	....
	if ((ui->ui_sum = in_cksum(m, sizeof (struct udpiphdr) + len)) == 0)                ui->ui_sum = 0xffff;
	    ....

while tcp_output.c does:

	ti->ti_sum = in_cksum(m, (int)(hdrlen + len));


For output, there is

	if (uh->uh_sum = in_cksum(m, len + sizeof (struct ip))) {
		udpstat.udps_badsum++;
		....
and
        if (ti->ti_sum = in_cksum(m, len)) {
		tcpstat.tcps_rcvbadsum++;
		....


in_cksum() does the familiar folding, returning with something like:
	  return (~sum & 0xffff);

That means in_cksum() cannot produce 0xffff, but has no trouble
producing 0, which is handy for those input checks above.

It also means that it doesn't matter to the 4.3BSd code whether the
checksum is in the TCP header is 0 or 0xffff.


Vernon Schryver,  vjs@sgi.com

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jul 1993 03:04:39 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.

In article <742167839@romeo.cs.duke.edu>, trt@duke.cs.duke.edu (Tom Truscott) writes:
> ...
> >    -Consider a TCP packet containing no options, and 2 bytes of user
> >	data, where that data just happens to consist of the 1's complement
> >	of the checksum of the TCP header and psuedo-header.
> >	What would be the TCP checksum of such a TCP packet?
> 
> It would be 0.
> Suppose X is the checksum of the header (and the value of the data).
> So ~X must be the sum of the header.
> So the total sum is ~X + X == 0xffff.
> So the checksum (the 1's complement of the end-around-carry sum) is 0.
> 
> Another example: suppose the header and data each sum to 0xffff.
> Then the total sum is again 0xffff thanks to end-around carry.


All true in 4.3BSD, except that in_cksum() complements its result
before returning.  Which means that in_cksum() can return 0xffff
but not 0, given a non-zero buffer, which seems likely given that
the addresses in the psuedo-header.


Vernon Schryver,  vjs@sgi.com

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jul 1993 03:43:18 GMT
From:      cej@world.std.com (Craig E Jackson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   What do people do for load-balancing in IP?

What do people do for load-balancing for IP applications?  I mean applications
which want to connect to any of n hosts.

I've heard of a 'shuffle A records' patch for bind, but I don't know
how it works, especially in the presence of secondary servers.  Is it
load based, or round-robin?

What other patches or systems are available to do this?

Also, what do people do in a failure situation, when you want to move
an application from one host to a backup one?  Do most people simply
rename/number the backup host to the primary address?

I suspect that this would come up when one wanted to change a CNAME
record for ftp.foobar.com from a.foobar.com to b.foobar.com.  For upto
a day or so, couldn't secondaries and other nameservers have old data?
Would it be reasonable to put a 10-minute TTL on the CNAME record only?
-- 
Craig Jackson
cej@world.std.com

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jul 1993 04:54:12 GMT
From:      bha@offsite.com (Bryan H Apple)
To:        comp.unix.sys5.r3,comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Help with ISC v3.0.1 slip and ethernet

OK, I'll admit it, I just don't get it!  I'm have configuration
questions with slip, and /etc/route, and don't seem to get any
satisfaction out of /etc/gated.  The configuration is ISC R3.2
V3.0.1 w/Maint #1 (TCP/IP 1.3)

                         Ethernet
     ----------------------------------------------
     |              |              |              |
     Box A          Box B          Box C          Box D
     130.18.1.1     130.18.1.2     130.18.1.3     130.18.1.4
     130.18.2.1 Modem 
                    ^
                    |
     Box HOME       v
     130.18.2.2 Modem

The ethernet works fine.  Class B address, subnet mask=255.255.255.0,
everybody is happy.

I have questions about slip between Box A and Box HOME.

 1)  Am I correct in setting up the two slip interfaces as a subnet
     different from the ethernet?  What if I don't?

 2)  What about associating names to those IP numbers.  What should
     I name the slip interface in Box A (if anything)?
     /etc/hosts:
               130.18.1.1 = Box A
               130.18.1.2 = Box B
               130.18.2.1 = Box A-sl (???)
               130.18.2.2 = Box HOME

 3)  The ifconfig for the slip device specifies both the interface
     IP number and the destination IP.  Is this correct?

     Box HOME sl0: flags=55<UP,DEBUG,POINTOPOINT,RUNNING>
                inet 130.18.2.2 --> 130.18.2.1 netmask ffffff00

     Box A    sl0: flags=55<UP,DEBUG,POINTOPOINT,RUNNING>
                inet 130.18.2.1 --> 130.18.2.2 netmask ffffff00

 4)  Does it make ANY difference which side initiates the
     connection.  I can dial Box A from Box HOME (Box A runs
     sllogin and Box HOME runs sldialup).  I can do it the other
     way around.

 5)  I want Box HOME to be able to access any host on the ethernet
     and visa versa.  What do I do with /etc/gated or /etc/route? 
     Specifically, just running /etc/gated doesn't seem to get me
     any results.  If I try to specify routing with /etc/route I
     have different problems.  /etc/route calls for a destination
     and a gateway.  Do I run this on Box HOME, Box A, both?  Does
     it matter who initiated the connection?

What ever help (general or specific) you wish to offer will be
appreciated.  Post or email.
-- 
Bryan Apple
Data Vault Systems
(708) 885-6000

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jul 1993 05:35:25 GMT
From:      roy@issy.cnet.fr (Jean-Michel ROY)
To:        comp.protocols.tcp-ip
Subject:   Verifying access-list on CISCO

Does anybody made a tool to verify the integrity of the access-list
on a CISCO Router ?

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jul 1993 07:58:43 GMT
From:      etxmesa@eos.ericsson.se (Michael Salmon)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Tips on alternative to NFS requested.

In article <thurlow.742139845@convex.convex.com>
thurlow@convex.com (Robert Thurlow) writes:
|> In <1993Jul7.070827.3131@ericsson.se>
|> etxmesa@eos.ericsson.se (Michael Salmon) writes:
|> 
|> >I am looking for an alternative to NFS, preferably TCP based. RFS seems
|> >to do what I want but I can't yet find a standard for it. All
|> >suggestions welcome.
|> 
|> I might have some suggestions if I had any clue about what problems
|> you were trying to solve.  Asking for "better" is only goung to get
|> you noise, in my opinion, unless we know what "better" would feel
|> like to you.

Basically I need a more secure remote file system and a simpler one,
the first requirement is the more important. It should also not consume
very much processor time and be supported by every Unix system.
Seriously though, I want a protocol that is fast, secure, standard and
tcp based (to avoid building my own timers).

My understanding is that NFS is not particularly secure in its
mounting. I also understand that I can use NFS over TCP as RPC is not
dependant upon protocol, however I haven't heard of anyone who has done
that. I could also use a tcp connection to port mapper but the standard
is a little uncertain about whether CALLIT can be used from tcp.

-- 

Michael Salmon

#include	<standard.disclaimer>
#include	<witty.saying>
#include	<fancy.pseudo.graphics>

Ericsson Telecom AB
Stockholm

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jul 1993 08:17:34 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.

In article <742169155@romeo.cs.duke.edu> trt@duke.cs.duke.edu (Tom Truscott) writes:
>>I think i'm the one that made the NetWare TCP code send 0xffff instead
>>of zero, but now i can't remember why i did it.
>
>There is no need to do it for TCP.

Are you saying that you know for sure that there's no need to do this
for TCP, or are you just saying that you don't see anything in the
spec that calls for it?  I could have sworn that i changed that code
specifically because there was a TCP implementation that rejected
arriving TCP packets with a zero in the checksum field, but now i
can't recall.  Needless to say, such an implementation would be
broken, but it's a fairly simple to accomodate it by sending it the
checksum value it expects.

Now with at least one broken implementation coming up that rejects
packets with 0xffff in the checksum field, i guess i must have backed
the wrong horse...or i suppose i may have just gotten my bits flipped.

						don provan
						donp@novell.com

P.S. By the way, son, i've been calculating checksums since you were
in knickers, so you really don't need to explain to me how they work.
-dp

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 93 11:30:24 GMT
From:      jordan@IMSI.COM (Jordan Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: KEEPALIVE option for tcp sockets

Dennis Newport <devdjn@space.alcbel.be> writes:

	All that seems to have occurred so far is that the responses
	are bitching about which manual pages he is reading.  Does
	anyone have an answer?

I started the discussion about reading the manual because I wanted to
clarify that the manual pages (not to mention the 4.3 Book) say
*nothing* about getting notified when the KEEPALIVE timer goes off.

Ok, maybe that's a bug or a misfeature.  Regardless, It *only* says
that the socket will get marked as invalid and that the *next* time a
read or a write is attempted that it will return an error.

Specifically, I wrote:

   In all Unix implementations that I know of, if the keepalive timer
   goes off, the socket is marked as invalid, but select() does not
   return.

	People don't really seem to answer things in this group. They
	just chat.

Don't be rude.  Have a nice day.

/jordan

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jul 1993 12:47:53 GMT
From:      carlson@steam.Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: Bug in many versions of TCP

In article <1993Jul9.015552.16180@burrhus.harvard.edu>,
ddl@burrhus.harvard.edu (Dan Lanciani) writes:
|> In article <1993Jul7.195317.3075@xylogics.com>,
 carlson@steam.Xylogics.COM (James Carlson) writes:
|> 
|> | IMPORTANT BUG FIX FOR TCP INPUT CODE
|> | 
|> | Xylogics has found and fixed a bug that exists in the tcp_input.c
|> | routine in 4.4BSD and several other versions of TCP.  We strongly
|> | recommend that you examine your version of TCP for this error.
|> 
|> Interestingly, I recently posted a fix for this same code in relation
|> to the self-connect problem.  Both problems are caused by throwing away
|> perfectly good ACKs just because data was trimmed.  While I believe
|> Xylogics' patch will work, it does introduce some unnecessary code;
|> to wit:
|> 
|> | 			if ((tiflags & TH_FIN) && todrop == ti->ti_len + 1)
|> | 				tiflags &= ~TH_FIN;
|> 
|> At this point, we already know that either TH_FIN wasn't set to begin with
|> or todrop is greater than ti->ti_len.  Therefore, TH_FIN can be cleared
|> unconditionally.  The first clause of the suggested if() statement is moot,
|> so the only time this would make a difference is if todrop is greater than
|> ti->ti_len + 1 with TH_FIN set.  That condition would imply a FIN occupying
|> the sequence number of previously transmitted data, a weird situation to
|> say the least!

I strongly disagree with that statement.  The FIN and SYN "bits" *DO*
occupy sequence numbers, and do need to be checked in this manner.

The problem is this:  It is possible to enter this section of code with
a packet that has some old data and some new data.  Consider the case
where the "new data" consists of some number of new octets and a FIN
bit -- in that case you will want to drop the old data, keep the new
data, and notify the application that no more data will arrive (FIN).
Now consider the case where all of the data is old, but it now has a FIN
bit -- in that case you want to notify the application that there are no
more data.  Lastly, there is the case where all of the data -- including
an ACK-ed FIN -- are duplicate.  In that case, you do not want to notify
the application (again) that the connection is closing.  You just want
to re-ACK the FIN since the peer must have lost an ACK.

The code is not introduced in this patch -- it is retained from the
original Berkeley code.

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 3159

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jul 1993 14:01:33 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   Re: Are port numbers < 1023 reserved for the client end of an FTP data connection?

I wrote:
> That's basically my interpretation also. Unfortunately the HP support
> folks here in Norway (who answered quickly and efficiently, just not the
> answer I wanted) dug up a similar case (also involving an AS/400), and
> said, in effect, that "HP has decided that it follows the standard; case
> closed". I'm trying to dig up supporting evidence for *not* closing the
> case.

I did some digging in what I had saved from comp.protocols.tcp-ip, and
found one interesting message from Don Provan. This whole discussion has
evidently happened before, and in that case too HP was the one causing the
problem. How can we get HP to understand that they should change?

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no
----------------------------------------------------------------------
From: donp@na.excelan.com (don provan)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Ports 1000-1023 reserved?
Date: 31 Jul 90 19:51:51 GMT
Reply-To: donp@novell.com (don provan)
Organization: Novell, Inc., San Jose, California

In article <1990Jul31.115309.1@rogue.llnl.gov> oberman@rogue.llnl.gov writes:
>In article <9007301547.AA19807@ucbvax.Berkeley.EDU>, DBARTON@IBM.COM writes:
>
>> TCP/IP Version 2 for VM will start allocating ports at port number 1024,
>> to prevent this problem with the Hewlett Packard product.
> 
>I beg to differ. Please check RFC-1060 in the section "UNIX PORTS".
>
>   By convention, ports in the range 256 to 1024 are used for "Unix
>   Standard" services. 

OK, this discussion has gotten out of hand and i'm afraid some
innocent novice it going to believe some of this misinformation.

While it is true that ports lower than 1024 are reserved on many
systems, that has nothing whatsoever to do with the HP bug that's being
discussed here.  The port given in the FTP PORT command is a *remote*
port.  There's no justification at all for HP checking this port for
any range of any type for any reason.  It should just use the port
given.  I don't even understand what prompted some misguided soul to
add the extra, unnecessary code needed to make this check.

I applaud the IBM developers for making this simple change to
accommodate the HP implementation, but i want everyone to understand
that the HP implementation is, in fact, broken.
							don provan
							donp@novell.com

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 1993 14:47:14 GMT
From:      booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.ppp
Subject:   SLIP vs. PPP:  Which is best?

If I have a choice of running SLIP or PPP, which should I run?  I'd be
interested in hearing about the relative (dis)advantages of each of
these protocols.

Thanks in advance,
mb
-- 
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948
Disclaimer:  booloo speaks for booloo and no other.

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 1993 15:40:54 GMT
From:      bryan@notorious.rs.itd.umich.edu (Bryan Beecher)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: What do people do for load-balancing in IP?

In article <C9vp07.AA9@world.std.com> Craig E Jackson writes:
>
>I've heard of a 'shuffle A records' patch for bind, but I don't know
>how it works, especially in the presence of secondary servers.  Is it
>load based, or round-robin?
>
>What other patches or systems are available to do this?

There's a copy of BIND 4.9 and a patch file containing the umich
"goodies" that didn't make it into 4.9 available for anonymous ftp from
terminator.rs.itd.umich.edu in the /dns/bind4.9 directory.

Also, if you look in /dns/info, there is also some information about my
shuffle A records, and the other contenders out there (CIP and POOL).
The latter was written by David Bolen of ANS, and I thought it was so
good, I kept a copy.  It discusses the various features of all three
record types.

In brief, shuffle A (SA) records are sort of round-robin.  My code does
not re-order the records; but it does treat the records as a circular
list, and randomly picks a new head of the list.  They are IN NO WAY
load based.  We use them for various computing clusters where a
connection to some random machine -- not necessarily the least loaded
-- is good enough.  Unless 'named' is started with a "-s" flag (that is
part of the SA patch), SA records are transferred as A records to a
secondary server.

Merit Inc uses a combination of SA records and A records for the name
hermes.merit.edu.  One feature of SA records is that if a name has both
SA records and A records, *both* types of records get shuffled.  (And
to the client, they appear as A records.)  In the case of Merit, their
server (merit.edu) understands SA records and so does one of their
secondary servers (dns2.itd.umich.edu); a second secondary server
(ncar.ucar.edu) does not understand SA records.

The 'named' on merit.edu uses the "-s" flag, and so on a zone transfer,
it sends SA records for SA records (i.e., it doesn't substitute A
records for SA records).  hermes.merit.edu consists of several A
records and a single SA record.  Thus, due to the feature I mentioned
above, the records get shuffled together when a query goes to merit.edu
or dns2.itd.umich.edu, the two servers that understand SA records.
Queries going to ncar.ucar.edu aren't shuffled, and since it doesn't
understand SA records, it also happens to discard the one SA record it
gets.  The remaining records (all A) are returned in the usual, static
order.

I'm hoping to formally write-up SA records in a RFC (like Bill
Manning's RFC on NSAP records) sometime this month, and that might make
finding information about them a little easier.  If you have any
questions or suggestions, please don't hesitate to send them to me.
-- 
Bryan Beecher, U-M Information Technology Division (+1 313 747 4050)
Domain:	Bryan.Beecher@umich.edu      Path:  ..!uunet!destroyer!bryan

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jul 1993 16:12:45 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: What do people do for load-balancing in IP?

> cej@world.std.com (Craig E Jackson) writes:
>What do people do for load-balancing for IP applications?  I mean applications
>which want to connect to any of n hosts.
>
>I've heard of a 'shuffle A records' patch for bind, but I don't know
>how it works, especially in the presence of secondary servers.  Is it
>load based, or round-robin?

Shuffling A records is not really a great solution.  I think most
of our IP-savvy (practicing my American colloquialisms) readers
would agree that A record swapping is more appropriate when the
change is more permanent than the duration of an application.

>What other patches or systems are available to do this?

I posted on this topic a few weeks ago, so frequent readers may
choose to skip this reply.

There is a product which does something like you ask for 
TELNET sessions.  It will load balance given priorities you 
assign.  It also handles downed hosts and other anomolies.

Contact info@snsi.com about the EAGATE as it may be a good
option for your particular use.  

Erick
-- 


-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jul 1993 16:26:37 GMT
From:      jmc@hal.com (Jerry McCollom)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   Re: Are port numbers < 1023 reserved for the client end of an FTP data connection?


Steinar.Haug@runit.sintef.no writes:

>jmc@hal.com (Jerry McCollom) writes:
>> What version of HP-UX do you have?  This was a feature of HP-UX 7.0 and
>> some prior releases, but I believe it was removed in HP-UX 8.0 and later
>> based on customer complaints and on discussion on comp.protocols.tcp-ip
>> that concluded (especially, as I remember, after an authoritative reply
>> from Jon Postel) that it was out of spec.  
>
>It is in all the versions of HP-UX I have checked:
>
>	HP-UX 8.0	s400
>	HP-UX 8.07	s700
>	HP-UX 9.0	s700
>	HP-UX 9.01	s700
>	HP-UX 9.0	s800
>
>I would be extremely interested if you could dig up that answer from
>Jon Postel.

Alas, either I failed or it was reintroduced before 8.0 released to
customers (several months after I had my hands on it).  If I failed, my
personal apologies for botching it.  Be assured, though, that I agree
this is incorrect behavior.

I dropped a line to a buddy in HP to bring this problem to their
attention.  Their defect history may include Postel's reply, but, as my
(well demonstrated :-) cloudy memory recalls, it was a terse statement
to the effect that the HP server is broken.

Jerry (again speaking neither for HP nor for HaL)




--
Jerry McCollom
HaL Computer Systems, Inc., Austin, TX
jmc@hal.com

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jul 1993 16:41:04 +0000
From:      steve@one47.demon.co.uk (Stephen R Davies)
To:        comp.protocols.tcp-ip
Subject:   Re: SCO 3.2v2.2 -> 3.2v4.1

In article <39@westfield.win.net> debiso@westfield.win.net (Joe DeBiso) writes:
> 
>In article <4.1494.362.0N566670@euronetis.no>, Rune Mossige (rune.mossige@euronetis.no) writes:
>>
>>
>>I've just come onto a very strange problem. We have two SDI 80486 
>>machines running SCO unix. One is running 3.2v4.1 and the other is 
>>running 3.2v2.2
>>
>>I upgrading the 3.2v2.2 box to v4.1, but after the upgrade, I was not 
>>able to get contact with the network. Nothing at all. [...]

You really should upgrade TCP/IP to version 1.2 and install LLI. I also
recommend that you install everything from scratch, as some of the
uninstall scripts don't work completely...

Steve.
============================================================================
      _/_/_/ _/_/_/ _/_/_/  _/  _/  _/_/_/ Trebor Bassett Limited,
    _/       _/   _/      _/  _/  _/         Hertford Place, Denham Way,
     _/    _/   _/_/    _/  _/  _/_/           Maple Cross, Herts., WD3 2XB.
      _/ _/   _/       _/ _/  _/                 Tel.: +44 (0)923 896565
_/_/_/ _/   _/_/_/     _/   _/_/_/         steve@one47.demon.co.uk
======================= PGP 2.3 public key available =======================

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jul 1993 16:55:47 GMT
From:      phil@pex.eecs.nwu.edu (William LeFebvre)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: What do people do for load-balancing in IP?

In article <21k3i6$rar@terminator.rs.itd.umich.edu> bryan@notorious.rs.itd.umich.edu (Bryan Beecher) writes:
>I'm hoping to formally write-up SA records in a RFC (like Bill
>Manning's RFC on NSAP records) sometime this month, and that might make
>finding information about them a little easier.  If you have any
>questions or suggestions, please don't hesitate to send them to me.

Yes I have a suggestion, not just for you but for consideration by the
entire DNS community.  Instead of stuff like SA, CIP, and POOL records
what we need is a more generalized mechanism.  SA records are great,
but some people need honest-to-gosh load balancing.  Yet I don't like
the idea of embedding actual load determining code in named itself.
Besides, this problem could potentially extend to more than just A
records.  Why standardize on a solution that is restricted to only
A records?  What we need is a mechanism whereby a site administrator
can dictate his/her own policy on the order in which A records are
handed out in a reply.

I'd like to propose a really radical idea (I'm good at doing that :-) ).
How about a mechanism that allows a DNS server to determine an
appropriate answer via external means?  This could take the form of a
perl or shell script, a program, or what have you.  This process could
do whatever it wants to do (under total control of the zone
adminstrator) to determine, for example, the order in which A records
should appear in the answer.  Or the order in which MX priority 0
records should appear, for instance.  Or perhaps even the priorities
in the MX records (imagine being able to change dynamically which mail
exchangers have what priority!).

Now I haven't thought this through completely....this is still a
pretty rough idea, but I'd like to see discussion about it.

In some ways, a mechanism like this already exists within DNS:  it's
called the NS record.  So here's my off-the-top-of-the-head idea.
Let's invent a new records called FWD, for forward.  It specifies a
host AND a port number to which any query on the associated string
should be forwarded.  When an authoritative server see a question that
resolves to a FWD record, it forwards the question along to the
host/port specified in the record (whoops....that will only work for
the IN class) and will return whatever answer it gets back.  To
provide robustness, you could specify muiltiple FWD records.

Now the server that runs on the specified name/port could be stripped
down.  It wouldn't need to be a full blown DNS server (it probably
doesn't even need the asynchronicity that named has).  In fact, it
would have to be written in an entirely different manner if we are
going to leave determination of the answer up to the administrator.
What I envision is a library of routines to do all the grubby DNS
stuff (reading and parsing questions, building and sending answers)
and an administrator writing a C program or a perl script on top of
this library to actually determine what the answer should be.

We might also need to restrict what types of RRs could be sent in
answer to a FWD....I haven't given much thought to possible
ramifications here (especially the effects that caching these answers
will have on functionality).

Why go to all the bother?  We could just provide a hook in named so
that the authoritative server would invoke a program to get the
answer.  But this might be very difficult to work in to the
asynchronous nature of named.  Plus, this external program would need
to exist on ALL the secondaries, or the whole thing will be useless.
And that could be a potentially serious concern, since most every zone
has an off-site secondary.  The advantage of having a FWD record is
that it can easily be part of a zone transfer to anywhere in the world
and the receiving site will always be able to do something useful with
it.

It occurs to me that this very mechanism could solve a problem brought
up here a week or so ago: how to accomodate non-octet subnetting in
in-addr.arpa.  With FWD records you could potentially "delegate" part
of a domain to another server on a label-by-label basis.

I'm sure there are many disadvantages and pitfalls to this idea, not
the least of which would be actually implementing it.  But since
everone is turning to DNS to do things like load-balancing, I think
the time is ripe for a good general mechanism to solve the problem.

Comments?

		William LeFebvre
		Computing Facilities Manager and Analyst
		Department of Electrical Engineering and Computer Science
		Northwestern University
		<phil@eecs.nwu.edu>

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 1993 17:41:01 GMT
From:      bryan@notorious.rs.itd.umich.edu (Bryan Beecher)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: What do people do for load-balancing in IP?

In article <C9wpp0.B92@eecs.nwu.edu>  William LeFebvre writes:
>
>I'm sure there are many disadvantages and pitfalls to this idea, not
>the least of which would be actually implementing it.  But since
>everone is turning to DNS to do things like load-balancing, I think
>the time is ripe for a good general mechanism to solve the problem.

I agree with you in that it would be useful and convenient to have some
solution to the "load balancing" problem.  Using some external process
seems to be a better method than glueing more and more stuff into 'named'.
And as you said, this could easily be useful in all sorts of ways.  It
turns 'named' from a database of resources to a database of pointers
to resources.

That said, I also think that the SA record, or more generally, any sort of
record with a data flag set to indicate that ordering should be random
instead of static, is very useful.  One of the big wins with this
approach is that it interoperates very well with existing client
software and existing nameservers.  Something like a FWD record could
be *the* solution, but until the FWD record becomes ubiquitous, it
isn't a viable solution.  But that isn't a strike against the idea;
it just means it cannot be today's solution.
-- 
Bryan Beecher, U-M Information Technology Division (+1 313 747 4050)
Domain:	Bryan.Beecher@umich.edu      Path:  ..!uunet!destroyer!bryan

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jul 1993 18:18:58 GMT
From:      braun@novell.com (Karl Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.

In article <1993Jul9.081734.11702@novell.com> donp@novell.com (don provan) writes:

>
>...or i suppose i may have just gotten my bits flipped.
>

I hate it when that happens...


kral   408/647-6112                                              
Network Scapegoat in Training                                      NOVELL/DSG
That's the whole problem with science.  You've got a bunch of empiricists 
trying to describe things of unimaginable wonder." - Calvin

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 93 19:46:14 GMT
From:      schmidt@net1.ics.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

Hi,

	I'd be interested to know if there are any conference,
workshop, or journal articles that I could cite regarding the
combination data-copy/checksumming optimizations described in recent
discussions on this newsgroup.  Have any of the performance numbers
presented here been published yet?

	Thanks,

		Doug
--
His life was gentle, and the elements so            | Douglas C. Schmidt
Mixed in him that nature might stand up             | schmidt@ics.uci.edu
And say to all the world: "This was a man."         | ucivax!schmidt
   -- In loving memory of Terry Williams (1971-1991)| (714) 856-4101

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 93 03:19:49 -0400
From:      spjrg@drycas.club.cc.cmu.edu (Jim Glover)
To:        comp.protocols.tcp-ip
Subject:   Can anyone recommend some good reading?

     In the coming months, I will be considering the implementation of
a network involving up to a dozen or so sites at various locations in
one city, and a client/server application which will run on this
network.  I'm a VM system programmer by profession, and have some
experience with networked PC's.  I need to educate myself enough to be
able to make wise decisions concerning type of network, what
language(s) I should use for writing the client and server, and what
kind of hardware to use.
     It is important for this new network and application to be as
inexpensive as possible and have the potential for growth in the
future.  The network will be devoted to this single application.  As
of now, I'm thinking in terms of TCP/IP, IBM PC compatibles as the
workstations, and a server that will run on a PC compatible at first,
but could be ported to a more powerful system as the network grows, if
needed.  I'm not sure whether I'd want networking software for the
upper layers, or if my client and server should be designed to work
without that support.
     Now that you have some idea what I'm up to, can anyone recommend
sources of information that will help me make the best possible design
decisions?  What I really want are recommendations about books that
will give me the knowledge I need to make good decisions, although
specific recommendations won't be ignored, even in this early stage.
Thanks in advance for anything you can recommend.










































 

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 93 21:24:25 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Zero-window probing


	Should TCP zero-window probes always contain data?  

	Thanks!
		Randy

-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jul 1993 21:27:42 GMT
From:      sameer@atlastele.com
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: What do people do for load-balancing in IP?

In article <C9vp07.AA9@world.std.com> cej@world.std.com (Craig E Jackson) writes:
>What do people do for load-balancing for IP applications?  I mean applications
>which want to connect to any of n hosts.
>
>I've heard of a 'shuffle A records' patch for bind, but I don't know
>how it works, especially in the presence of secondary servers.  Is it
>load based, or round-robin?

	Points on applic.load bal. deleted

Also, what about load balancing between two hosts connected by a dual dial-up SLIP lines. How would that work.
In case one line goes down the traffic shifts to the other line. Any ideas ?
THanks,
Sameer..
-- 
==================================================================
"I strongly disclaim the above disclaimer. Hey you stupid machine
why did you put it in there!, Hey Stop!, Stop right there, I have 
a right to fre@$# ommuph!, arrghhh! choke! sp*#ch..SPLAT!!......."

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jul 1993 21:31:00 GMT
From:      mack23@avalon.eecs.nwu.edu (Chris Walsh)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: What do people do for load-balancing in IP?

In article <C9wnpA.82H@watserv1.uwaterloo.ca> erick@sunee.uwaterloo.ca (Erick Engelke) writes:
>
>> cej@world.std.com (Craig E Jackson) writes:
>>What do people do for load-balancing for IP applications?  I mean applications
>>which want to connect to any of n hosts.
>
>There is a product which does something like you ask for 
>TELNET sessions.  It will load balance given priorities you 
>assign.  It also handles downed hosts and other anomolies.
>
>Contact info@snsi.com about the EAGATE as it may be a good
>option for your particular use.  


There's also a product from HP called Task Broker which does this.  It uses
a daemon to solicit "bids" from servers for specified processes.  The servers
return a bid in the form of an integer.  Highest non-zero integer gets the
job.  The product is available for HP, SUN, RS6K and possibly other machines,
as I recall.  In essence, Bill LeFebvre's FWD record suggestion (which I
think is pretty cool) amounts to bundling into named the bid solicitation
process.

There was a vendor display at the January USENIX in San Diego that was showing
a similar product to Task Broker.  It was cheaper but not quite as cool.  I
do not have the sales propaganda handy, but there are apparently at least three
packages that purport to do some load balancing, for at least some processes.
EAGATE seems the most limited, Task Broker the least, and the USENIX vendor's
somewhere in the middle.  I apologize for posting this to this newsgroup, but
given the latent interest out there, I thought it was defensible.  Before
following up, you might want to change the headers.  I could not think of
an appropriate newsgroup :^).

--
Chris Walsh                 "Cable, I wish you were with me now."
Technet Network Administrator   --John Cale 
Northwestern Univ.          "Networks of the future cannot fail."
2145 Sheridan Rd.               --Roger Dev, Cabletron (out of context)
Evanston, IL 60208       
DoD# 0671               
                       
                      


-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jul 1993 21:39:19 GMT
From:      bossert@claircom.com (John Bossert)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc,comp.source.wanted
Subject:   Help with writing to /dev/nit (SunOS)

Could someone send me a snippet of code showing how to _write_ to /dev/nit?

I'm trying to construct a RARP daemon and am able to pull packets _from_
/dev/nit, but my reply packets are going nowhere.

This is on a Sparc IPX, running SunOS 4.1.3.  Thanks in advance.

	John Bossert
	bossert@claircom.com

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 93 22:25:44 GMT
From:      trt@duke.cs.duke.edu (Tom Truscott)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.

>>If 0xffff had been used as the "no checksum" value
>>then no special check would have been needed (see previous article).
>
>No, that is not true.  What is the checksum of 4 bytes with contents
>0000 0000?  (sum = 0000, so the checksum is ffff.)

But 0000 0000 (or any data that is entirely 0) is not a valid packet.

This whole thing is pretty trivial.
I regret having brought it up.

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 1993 01:26:54 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Zero-window probing

In article <rturner.742253065@imagen> rturner@imagen.com (Randy Turner) writes:
>	Should TCP zero-window probes always contain data?  

They would not be particularily useful if they did not, because there
is no reason for the receiving TCP to ack a dataless packet.

The TCP should never probe unless it has data to send, but if it has data,
it should include the data in the probe packet.

       Stephen

-- 
Stephen Trier (trier@ins.cwru.edu - MIME OK)   
Network Software Engineer              
IRIS/INS/T                               
Case Western Reserve University             

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 93 01:34:35 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: Zero-window probing

rturner@imagen.com (Randy Turner) writes:

>	Should TCP zero-window probes always contain data?  
 
>	Thanks!
>		Randy
 
>-- 
>-----------------------------------------------------------------------------
>Randy Turner
>QMS, Inc.
>rturner@aqm.com

	Never mind, after taking the time to peruse RFC 793, in section 3.7
	it says that the host must be able to send at least 1 octet of data
	in zero-window probes to try and detect the window opening.  I would
	think it would normally try and send the data it wanted to send in
	the first place, just in case the window opened while the output pkt
	was in transit.

	The reason I asked is that we have been asked to modify our 
	implementation so that it responds to  window-probes with no data in
	them.  The other implementation that we have been asked to be 
	compliant with is Wollongong's Pathway TCP/IP product for the PC.

	We observed the Wollongong's zero-window probing on a Lanalyzer
	and it did not include any data in the probes, so our implementation
	was not responding to it with the updated window size.

	Clearly this is not our fault since I feel we are RFC793 compliant,
	and while we might could make the changes to force ourselves to work
	with the Wollongong product, I feel like we probably should not.

	To date, this is the only TCP/IP implementation that we have tested
	with that does not send
	data with zero-window probes.  Today, we tested with an SGI IRIS
	and it even goes to the trouble of sending an ASCII '0' in the data
	portion of the packet, just to be compliant (I guess...).

	Solaris 2.2 tries to go ahead and send a full packets worth of data
	from it's send queue along with the probe, which is what I would 
	expect.

	Comments? 

	Randy

-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Sat, 10 Jul 93 01:59:38 GMT
From:      ddl@burrhus.harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: Bug in many versions of TCP

In article <1993Jul9.124753.12821@xylogics.com>, carlson@steam.Xylogics.COM (James Carlson) writes:
| In article <1993Jul9.015552.16180@burrhus.harvard.edu>,
| ddl@burrhus.harvard.edu (Dan Lanciani) writes:
| |> 
| |> At this point, we already know that either TH_FIN wasn't set to begin with
| |> or todrop is greater than ti->ti_len.  Therefore, TH_FIN can be cleared
| |> unconditionally.  The first clause of the suggested if() statement is moot,
| |> so the only time this would make a difference is if todrop is greater than
| |> ti->ti_len + 1 with TH_FIN set.  That condition would imply a FIN occupying
| |> the sequence number of previously transmitted data, a weird situation to
| |> say the least!
| 
| I strongly disagree with that statement.  The FIN and SYN "bits" *DO*
| occupy sequence numbers, and do need to be checked in this manner.

I'm not sure which part of my statement you disagree with, but nowhere
do I say that FIN and SYN don't occupy sequence space.  The situation
to which I refer is one in which a FIN is received whose sequence number is
the same as that of previously received (and presumed valid) data.

| The problem is this:  It is possible to enter this section of code with
| a packet that has some old data and some new data.

Is it?  Consider that the entire block of code is within the following if():

		if (todrop > ti->ti_len ||
		    todrop == ti->ti_len && (tiflags&TH_FIN) == 0) {

This says that either we are throwing away more than the whole packet
(in other words, we are trimming all the data plus at least one more
to account for a possible FIN) or else we are trimming exactly the length
of data in the packet but the FIN flag isn't set.  How can a packet with
new data pass this test?

| Consider the case
| where the "new data" consists of some number of new octets and a FIN
| bit -- in that case you will want to drop the old data, keep the new
| data, and notify the application that no more data will arrive (FIN).

In this case the code is question would never run because todrop
is less than ti->ti_len.

| Now consider the case where all of the data is old, but it now has a FIN
| bit -- in that case you want to notify the application that there are no
| more data.

In this case the code in question would still not run because, although
todrop exactly equals ti->ti_len, (tiflags&TH_FIN) is non-zero.

| Lastly, there is the case where all of the data -- including
| an ACK-ed FIN -- are duplicate.  In that case, you do not want to notify
| the application (again) that the connection is closing.  You just want
| to re-ACK the FIN since the peer must have lost an ACK.

In this case the code runs and does the right thing by clearing
the TH_FIN flag.

Now, the interesting case that I mentioned above is one where
all the data (and any possible FIN) is duplicate but the sequence
space occupied by the FIN was previously used by valid data.  Obviously,
either such a segment is bogus or some previous segment was bad.  While
I suppose you could make an argument to do something clever, I think the
appropriate action is to drop the bogus FIN.  Whatever your opinion on
the correct action, however, you probably want to at least be consistent.
This is where your test of (todrop == ti->ti_len + 1) creates two
different sub-cases:

Sub-1.  If the bogus FIN has the same sequence number as the last octet of
data received (rcv_nxt - 1), then todrop will be equal to ti->ti_len + 1 and
you will discard the FIN.  I consider this behavior correct.

Sub-2.  If the bogus FIN has a sequence number before that of the
last octet of data received, then todrop will be greater than ti->ti_len + 1
and you will process the FIN.  I consider this incorrect:  a FIN from a
previous connection could terminate the current connection even though
is has a sequence number before rcv_nxt.

| The code is not introduced in this patch -- it is retained from the
| original Berkeley code.

Not exactly.  The original code was:

			if ((tiflags & TH_FIN && todrop == ti->ti_len + 1)
#ifdef TCP_COMPAT_42
			  || (tiflags & TH_RST && ti->ti_seq == tp->rcv_nxt - 1)
#endif
			   ) {
				todrop = ti->ti_len;
				tiflags &= ~TH_FIN;
				tp->t_flags |= TF_ACKNOW;
			} else
				goto dropafterack;

You collapsed the if() statement to:

 			if ((tiflags & TH_FIN) && todrop == ti->ti_len + 1)
 				tiflags &= ~TH_FIN;

removing the else/goto clause and leaving these statements to execute always:

				todrop = ti->ti_len;
				tp->t_flags |= TF_ACKNOW;

The key difference is that the original code either cleared TH_FIN or jumped
to dropafterack, knowing that the flags would then be ignored.  In no
case did the original code fall through with TH_FIN still set.  The problem
with the original code was that it branched to dropafterack in several cases
where it should have fallen through for more processing.  There was no problem
with clearing TH_FIN.

				Dan Lanciani
				ddl@harvard.*

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 93 13:16:02
From:      jim@cs.strath.ac.uk (Jim Reid)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Tips on alternative to NFS requested.

In article <1993Jul9.075843.3569@ericsson.se> etxmesa@eos.ericsson.se (Michael Salmon) writes:

   Basically I need a more secure remote file system and a simpler one,
   the first requirement is the more important. It should also not consume
   very much processor time and be supported by every Unix system.

You might as well be asking for World Peace or a cure for cancer. NFS
is to all extents the ONLY network file system protocol that is
readily available on any UNIX system. The only other obvious choice is
RFS. This is a little more secure, harder to administer and far, far
less ubiquitous. I have yet to come across a site using it.

   My understanding is that NFS is not particularly secure in its
   mounting.

Not really. The first implementations of the NFS mount daemon were
very trusting. Current versions take a lot more care over who gets to
mount what. You now need to impersonate a host if you want to spoof
the server. 

   I also understand that I can use NFS over TCP as RPC is not
   dependant upon protocol, however I haven't heard of anyone who has done
   that. I could also use a tcp connection to port mapper but the standard
   is a little uncertain about whether CALLIT can be used from tcp.

The NFS by Rick Macklem for 4.4 BSD can work over TCP as well as UDP.
However, there are very few other NFS implementation (none?) which do
this. Commercial suppliers ship NFS running over UDP because that's
what everybody else uses.

It's true that Sun RPC is independent of the transport protocol (sort
of). However NFS is a "special case". The NFS protocol is handled by
the kernel and it is heavily interlinked with the UDP code there.

		Jim

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Sat, 10 Jul 93 12:54:03 GMT
From:      IVERSEN@vsfys1.fi.uib.no (Per Steinar Iversen)
To:        comp.protocols.tcp-ip
Subject:   Re: Tips on alternative to NFS requested.

In <JIM.93Jul10131602@lister.cs.strath.ac.uk> jim@cs.strath.ac.uk writes:

> The NFS by Rick Macklem for 4.4 BSD can work over TCP as well as UDP.
> However, there are very few other NFS implementation (none?) which do
> this. Commercial suppliers ship NFS running over UDP because that's
> what everybody else uses.

Not quite, MultiNet TCP/IP for VMS by TGV can use TCP, here is from the
help file:

NFSMOUNT

  /TRANSPORT

   /TRANSPORT=({LOCAL,NETWORK})

    Specifies the underlying transport to be used for the NFS requests. The
    default is UDP if /TRANSPORT is not specified. The TCP transport
    can be used with servers that support it. If both transports are
    specified, TCP is tried first, and if it fails the mount falls back
    to UDP.

So at least one commercial implementations can use TCP too.

-psi (iversen@vsfys1.fi.uib.no)

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 1993 13:20:02 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: What do people do for load-balancing in IP?

In article <1993Jul9.212742.1341@atlastele.com> sameer@atlastele.com writes:
>Also, what about load balancing between two hosts connected by a dual
>dial-up SLIP lines. How would that work.
>In case one line goes down the traffic shifts to the other line. Any ideas ?

That's a routing issue.  Any routing algorithm can cope with the
fallback from one line to another.  The Internet would hardly work were
that not the case!

Sharing load while both lines are up is a more difficult problem, but I
think Cisco advertise that their routers can do it.

Followups to comp.protocols.tcp-ip.

	Stephen

-- 
Stephen Trier (trier@ins.cwru.edu - MIME OK)   
Network Software Engineer              
IRIS/INS/T                               
Case Western Reserve University             

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 1993 13:30:51 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Zero-window probing

In article <rturner.742268075@imagen> rturner@imagen.com (Randy Turner) writes:
>	Today, we tested with an SGI IRIS
>	and it even goes to the trouble of sending an ASCII '0' in the data
>	portion of the packet, just to be compliant (I guess...).

This sounds suspiciously a keepalive packet, not a zero-window probe.
The zero-window probe works by sending real data.  If the probe
succeeds, that data gets delivered!  If your data included NUL bytes,
you are probably OK.  If it did not include NULs, you were not seeing a
zero-window probe.

Keep-alive packets may or may not contain one "garbage octet".  Since
the keep-alives work by sending at a sequence number the remote has
already acked, it doesn't matter what the octet contains.  NUL would be
logical.

       Stephen

-- 
Stephen Trier (trier@ins.cwru.edu - MIME OK)   
Network Software Engineer              
IRIS/INS/T                               
Case Western Reserve University             

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Sat, 10 Jul 1993 14:36:42 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Tips on alternative to NFS requested.

In article <1993Jul10.125403.7400@alf.uib.no>, IVERSEN@vsfys1.fi.uib.no (Per Steinar Iversen) writes:
> In <JIM.93Jul10131602@lister.cs.strath.ac.uk> jim@cs.strath.ac.uk writes:
> 
> > The NFS by Rick Macklem for 4.4 BSD can work over TCP as well as UDP.
> > However, there are very few other NFS implementation (none?) which do
> > this. Commercial suppliers ship NFS running over UDP because that's
> > what everybody else uses.
> 
> Not quite, MultiNet TCP/IP for VMS by TGV can use TCP,....
 
> So at least one commercial implementations can use TCP too.



BSDI's BSD/386 costs money and works pretty well, and so qualifies as
"commercial", and also supports NFS over TCP.

There are also the free 386BSD and NetBSD, which being free may not be
"commercial."  However, you can pay for CDROM's containing 386BSD 0.1.


Vernon Schryver,  vjs@sgi.com

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Sat, 10 Jul 1993 14:41:35 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Zero-window probing

In article <21mgab$mlc@usenet.INS.CWRU.Edu>, trier@odin.ins.cwru.edu (Stephen C. Trier) writes:
> In article <rturner.742268075@imagen> rturner@imagen.com (Randy Turner) writes:
> >	Today, we tested with an SGI IRIS
> >	and it even goes to the trouble of sending an ASCII '0' in the data
> >	portion of the packet, just to be compliant (I guess...).
> 
> This sounds suspiciously a keepalive packet, not a zero-window probe.


Whichever.
If you look at the 4.3BSD-reno or net2 source, you'll easily be able to
figure out which, what, and why.

Of course, like any fairly vanillia (at least in that part) 4.3BSD
implementation, a keepalive won't be emitted from an SGI IRIS on an
established TCP connection until after 2 hours of idle time.


Vernon Schryver,  vjs@sgi.com

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Sat, 10 Jul 93 17:11:29 GMT
From:      woods@robohack.UUCP (Greg A. Woods)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Re: TLI

In article <C9nxn5.BG8@rbdc.wsnc.org> royc@rbdc.wsnc.org (Roy Crabtree) writes:
> >This is not (entirely) true for a 3B2.  RFS is quite reasonable on a
> >3B2, esp. over Starlan-10.  Socket libraries, to the best of my
> 
> 	I did no tmentiuon RFS being slow  on STARLAN; I did mention
> 	NFS usually outperforming it, speedwise.  Although NFS CPU
> 	usage tends to be about 35% higher on a StarServer E 2SMP
> 	(4.0v3.1, TCPiP 4.2.1.2).

That's why I specifically mentioned 3B2's.  That 35% more CPU means
that often NFS cannot outperform RFS on a 3B2, if you look at the
total system, that is.... ;-)

> 	RFS is on top of TLI; TLI is on top of STREAMS on 3B2.
> 
> 	Sockets are on top of STREAM, but not on top of TLI
> 	as best I understand it; what causes the confusion is
> 	that TLI addresses via the protocol family specifications
> 	have a mapping that is 1:1 onto the TCP/IP sockets points;

Good point.  I have seen libsocket implementations that used TLI calls,
but indeed I've no information about the 3B2 (WIN/3B) implementation
of sockets, so I should keep my mouth shut.

> 	AGreed; I prefer RFS (but for several strangenesses, like
> 	'vi' startup  running slowly) because I Like to
> 	access remote devices transparently; remsh mach dd of=devname
> 	does not dot it for me; all my experience with 'remsh'
> 	has the sucker dying afdter about 45-60MB traffic.

It sounds like the implementation of 'remsh' (rsh) you are using is a
wee bit buggy.  I've pumped gigabytes through a single rsh connection
from a SunOS 4.1.3 to an ISC 386/ix 3.0 machine with an exabyte tape.
-- 
						Greg A. Woods

woods@robohack.UUCP		  VE3TCP	GAW Cons. & UniForum Canada
+1 416 443-1734 [home]				Toronto, Ontario; CANADA

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 1993 20:14:26 GMT
From:      matt@severian.chi.il.us (Matt Crawford)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: What do people do for load-balancing in IP?

William LeFebvre:
> In some ways, a mechanism like this already exists within DNS:  it's
> called the NS record.  ...

TGV's Multinet 3.2 has this.  Certain terminal domain names are
delegated by NS records to a subset of nodes in a vaxcluster, and
those nodes chat among themselves to decide in what order to list
the A records in response to a query, basing the order on their
instantaneous load averages (and relative processing power, I
believe).  They send the response with a TTL of 5 seconds, if I
recall rightly.

It's unfortunate that they only work this magic in response to
type=A queries and not type=ANY.
__________________________________________________________
Matt Crawford       matt@severian.chi.il.us       Java Man


-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 1993 21:11:07 GMT
From:      bob@comlab.gtri.gatech.edu (Bob Baggerman)
To:        comp.protocols.tcp-ip,comp.sources.wanted,comp.sys.sun.misc
Subject:   Re: Help with writing to /dev/nit (SunOS)

John Bossert writes:
>Could someone send me a snippet of code showing how to _write_ to /dev/nit?
>This is on a Sparc IPX, running SunOS 4.1.3.  Thanks in advance.

I wrote a NIT based daemon for my mail notification package I call
PCBIFF.  Look on "comlab.gtri.gatech.edu", I think in the "/pub/pcbiff"
directory.  There should be a file called "pcbiffd.c" or something
close.  I should be a pretty good starting example on sending arbitrary
ethenet packets down the wire.

Bob

-- 
Bob Baggerman                         !  bob.baggerman@gtri.gatech.edu
Communications Laboratory             !  bob@comlab.gtri.gatech.edu
Georgia Tech Research Institute       !  qseclrb@prism.gatech.edu
Atlanta, GA  30332  USA               !  404-894-3525

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Sat, 10 Jul 1993 21:20:40 GMT
From:      jim@reptiles.org (Jim Mercer)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Re: AS/400 connectivity ?

In article <1993Jul6.101915.18857@aristo.tau.ac.il> dganit@gemini.math.tau.ac.il (Amitay Dganit) writes:
>How can we connect AS/400 to Unix workstations ?
>Are there any TCP/IP implementations for the IBM AS/400 ? or are there any
>gateways that do the trick ?

IBM has TCP/IP for the AS/400, it is half decent.

it would be better supported if IBM contributed their xterm5250 to the MIT
distribution.

a couple companies (OpenConnect is one) also sell software and "protocol
converters".

there are also NFS implementations for the AS/400.



-- 
[ Jim Mercer   Reptilian Research merce@iguana.reptiles.org  +1 416 506-0654  ]
[                                  fix signs                                  ]

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Sun, 11 Jul 1993 02:52:01 GMT
From:      maklinm@cognos.COM (Max Maklin)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Tips on alternative to NFS requested.

In article <JIM.93Jul10131602@lister.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) writes:
:^()  
:^()  The NFS by Rick Macklem for 4.4 BSD can work over TCP as well as UDP.
:^()  However, there are very few other NFS implementation (none?) which do
:^()  this. Commercial suppliers ship NFS running over UDP because that's
:^()  what everybody else uses.
:^()  
:^()  It's true that Sun RPC is independent of the transport protocol (sort
:^()  of). However NFS is a "special case". The NFS protocol is handled by
:^()  the kernel and it is heavily interlinked with the UDP code there.
:^()  

Has anyone seen the new NFS protocol (V3, I think) that Sun was supposed to
reveal at Connectathon.  I have a hunch that they may have found an efficient
way to do it over TCP ports.  Is this so?

-- 
Max Maklin                                                P.O. Box 9707 
Technical Analyst	                           3755 Riverside Drive
Cognos Incorporated                              Ottawa, Ontario CANADA
Internet: maklinm@cognos.COM                 UUNet: maklinm@cognos.UUCP

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Sun, 11 Jul 1993 12:51:15 GMT
From:      souva@aibn55.mpifr-bonn.mpg.de (Ignatios Souvatzis)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.ppp
Subject:   Re: SLIP vs. PPP:  Which is best?

PPP has the disadvantage of 3 bytes relative (to slip) overhead per
frame, 2 of which are a frame level CRC which gives you peace of mind.

And it is much better to configure. If anything goes wrong, you don't
have to guess, but it'll tell you.

For any reasonable implementation (on both sides), performance
differences transmitting IP frames should  be neglectable. For non-IP,
PPP has hooks build in to transmit them over the same link... SLIP has
nothing except a framing method.

For more details, read:
ftp.uu.net:vendor/MorningStar/papers/sug91-cheapIP.ps.Z (text) and
sug91-cheapIP.shar.Z (overhead projector slides).

or the frequently wanted information, to be reposted in this group in
32 hours.

	i.s.
--
--
	Ignatios Souvatzis
Paper mail: Radioastronomisches Institut der Universitaet Bonn, 
	    Auf dem Huegel 71, D-53121 Bonn 1, FRG
Internet: souva@astro.uni-bonn.de or ignatios@cs.uni-bonn.de
Cute quote: "You should also consider that the ST comes fully equipped with a 
	     text adventure. It's called ST Basic." Amylaar@meolyon.hanse.de

  ''A pencil probably would we called LWD/MO --- 
    Lead Writing Device/Manual Option. ''


(German computer magazine "c't" 7/93, p.70, about IBM)

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Sun, 11 Jul 1993 22:32:57 GMT
From:      rreed@btr.com (Robin Reed)
To:        comp.protocols.tcp-ip
Subject:   Software Development Mgr Needed for Start-up Company

Position Overview:  

Software Development Manager for On-line Information Service Database
Development, located in Phoenix Arizona.  Start-up company funded by
second-largest communications company in the world. Equity participation is
significant.  Full relocation provided.

If you have led a successful development effort through to shipping a
commercially successful product in one of these areas, please read on:  

			Database Development 
			Client Server Software Systems
			Integrated applications (networking software)
			On-line transaction based system development


You know how to get product shipped.  The ideal candidate will have
delivered multiple complex software products under simultaneous deadlines
with limited resources.  The individual will be experienced at code
reviews, schedule reviews, mid-course corrections, manpower allocation
against objectives, and cost containment. He/she will be used to working
with small teams, and will have strong previous technical experience to
insure that they can thoroughly understand and test the details of product
development.  This individual has a track record of accurately projecting
schedules and holding to deliverables.  Ideally, this individual will have
worked with UNIX platform/database development (Sybase preferred), 
integrated applications (dbase, TCP/IP, communications, full text
retrieval), Windows  and OOP projects.  Experience with or knowledge of
SGML a major plus. Key requirement is that they understand and thrive in a
start-up environment with  high stakes.  In their background theyÕve
successfully pulled products out of the fire and shipped those against
deadlines.  This person will be a tough minded manager that can drive a
development project and make decisions on priorities and the allocation of
talent and resources to meet the objectives. 
 
Combination of experiences include management of multiple teams in a
commercial product development environment, and previous hands-on
development/Project Lead expertise on a C based product development team
that shipped new product through several releases.  At least 10 years of
experience, of which 4 most recent years have been in Development
Management of a complex software product (system and application level,
prefer database) where he/she has managed the aggressive schedules of a
start up or new product development effort.

The most important requirement is that this individual knows how to get
product shipped and can do code reviews.  The development work is primarily
C, Unix, TCP/IP, Sybase, Sun based.  Knowledge of advanced development
techniques, process maturity, system and subsystem architectural design,
test, QA improvement approaches, and object-oriented dev. and DB are
obvious advantages.

At the moment, there are 18 people in the engineering/technology group of
which 9 are doing hands-on development.  The other 9  are performing
non-coding development tasks such as human factors, simulation, testing,
project management.

Compensation:  Commensurate with experience (competitive base salary and
comprehensive benefits)  with the equity participation being the key
component to the overall compensation package. Full relocation assistance
provided.

Next Steps:  WeÕre a Technical Recruiting firm and weÕve been hired by this
start-up company to manage the recruitment of their engineering management
team and primary individual contributors. To learn more, please send a
request for more information to this email address:  rreed@btr.com, or call
direct to Robin Reed at (415) 928-7535 PST or fax to (415) 931-5220.  A
resume is required.  Confidentiality is guaranteed.  DonÕt delay if you
think you may be interested.  Our client wants to make a decision and
relocate the person as soon as possible. 

Thank you for your interest.


Robin Reed, Managing Diretor
The Reed Group, a management consulting firm retained by advanced software
and mobile computing/communications companies since 1984. (415)928-7535
voice, (415) 931-5220 fax.Internet: rreed@btr.com, Applelink: RREED. San
Francisco, Seattle, Boston offices.

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Jul 1993 04:42:46 GMT
From:      royc@rbdc.wsnc.org (Roy Crabtree)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Re: TLI

In article <1993Jul10.171129.20435@robohack.UUCP> woods@robohack.UUCP (Greg A. Woods) writes:
>In article <C9nxn5.BG8@rbdc.wsnc.org> royc@rbdc.wsnc.org (Roy Crabtree) writes:
>> >This is not (entirely) true for a 3B2.  RFS is quite reasonable on a
>> >3B2, esp. over Starlan-10.  Socket libraries, to the best of my
>> 
>> 	I did no tmentiuon RFS being slow  on STARLAN; I did mention
>> 	NFS usually outperforming it, speedwise.  Although NFS CPU
>> 	usage tends to be about 35% higher on a StarServer E 2SMP
>> 	(4.0v3.1, TCPiP 4.2.1.2).
>
>That's why I specifically mentioned 3B2's.  That 35% more CPU means
>that often NFS cannot outperform RFS on a 3B2, if you look at the
>total system, that is.... ;-)

	Chuckle.  Since when did a system developer at AT&T actually
	ever consider total system performance?

	But you are right. ....

>
>> 	RFS is on top of TLI; TLI is on top of STREAMS on 3B2.
>> 
>> 	Sockets are on top of STREAM, but not on top of TLI
>> 	as best I understand it; what causes the confusion is
>> 	that TLI addresses via the protocol family specifications
>> 	have a mapping that is 1:1 onto the TCP/IP sockets points;
>
>Good point.  I have seen libsocket implementations that used TLI calls,
>but indeed I've no information about the 3B2 (WIN/3B) implementation
>of sockets, so I should keep my mouth shut.
>
>> 	AGreed; I prefer RFS (but for several strangenesses, like
>> 	'vi' startup  running slowly) because I Like to
>> 	access remote devices transparently; remsh mach dd of=devname
>> 	does not dot it for me; all my experience with 'remsh'
>> 	has the sucker dying afdter about 45-60MB traffic.
>
>It sounds like the implementation of 'remsh' (rsh) you are using is a
>wee bit buggy.  I've pumped gigabytes through a single rsh connection
>from a SunOS 4.1.3 to an ISC 386/ix 3.0 machine with an exabyte tape.

	Ayah.  Every one of them.

		All from WOllongong ...

	Albeit the latest fixes of TCP/IP seem to rectify this ....

>-- 
>						Greg A. Woods
>
>woods@robohack.UUCP		  VE3TCP	GAW Cons. & UniForum Canada
>+1 416 443-1734 [home]				Toronto, Ontario; CANADA

royc

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Jul 1993 10:36:22 GMT
From:      chetanm@visionware.co.uk (Chetan Mistry)
To:        comp.protocols.tcp-ip
Subject:   Re: KEEPALIVE option for tcp sockets

Jordan Hayes (jordan@IMSI.COM) wrote:
: I started the discussion about reading the manual because I wanted to
: clarify that the manual pages (not to mention the 4.3 Book) say
: *nothing* about getting notified when the KEEPALIVE timer goes off.
 
: Ok, maybe that's a bug or a misfeature.  Regardless, It *only* says
: that the socket will get marked as invalid and that the *next* time a
: read or a write is attempted that it will return an error.
 
: Specifically, I wrote:
 
:    In all Unix implementations that I know of, if the keepalive timer
:    goes off, the socket is marked as invalid, but select() does not
:    return.

How do you detect that the KEEPALIVE timer has "gone off" ? If the
socket has been marked as invalid, how do you detect this before doing
a read/write operation ? You say that the read/write will fail, but surely
it will fail anyway because the connection is broken ! So whats the
point in having a KEEPALIVE option if it can't be detected and the software
behaves exactly the same whether KEEPALIVE is set or not set ?

I'm the person who made the original posting. The man pages I showed were
from a SPARC running SunOS 4.1.2 (but the pages are the same on 4.1.3
and a Sun3) and were for setsockopt(). On our SVR4 machines (uname -a says: 
Unisys 4.0 2 i386 386/AT and 4.0 3.0 486/AT i486) the man pages say that 
you should receive a SIGPIPE, but this doesn't happen either. 

Whats happening ? Is this something that just hasn't been implemented,
or is the documentation out of date ?

Chet



-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Jul 1993 13:08:54 GMT
From:      carlson@steam.Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: Bug in many versions of TCP


In article <1993Jul10.015938.15951@burrhus.harvard.edu>,
ddl@burrhus.harvard.edu (Dan Lanciani) writes:
|> In article <1993Jul9.124753.12821@xylogics.com>,
 carlson@steam.Xylogics.COM (James Carlson) writes:
|> | In article <1993Jul9.015552.16180@burrhus.harvard.edu>,
|> | ddl@burrhus.harvard.edu (Dan Lanciani) writes:
|> | |> 
|> | |> At this point, we already know that either TH_FIN wasn't set to
 begin with
|> | |> or todrop is greater than ti->ti_len.  Therefore, TH_FIN can be cleared
|> | |> unconditionally.  The first clause of the suggested if()
 statement is moot,
|> | |> so the only time this would make a difference is if todrop is
 greater than
|> | |> ti->ti_len + 1 with TH_FIN set.  That condition would imply a
 FIN occupying
|> | |> the sequence number of previously transmitted data, a weird
 situation to
|> | |> say the least!

Nuts.  I should beware of writing replies on a Friday.  Mea culpa.

After rereading the code, I'll agree that this particular relic doesn't
accomplish a whole lot anymore.  Perhaps I've been a little too
conservative in my hacking.

I'll change that to omit the offending "if" statement and reset the FIN
bit unconditionally -- just as the original code effectively did.

	/*
	 * States other than LISTEN or SYN_SENT.
	 * First check that at least some bytes of segment are within 
	 * receive window.  If segment begins before rcv_nxt,
	 * drop leading data (and SYN); if nothing left, just ack.
	 */
	todrop = tp->rcv_nxt - ti->ti_seq;
	if (todrop > 0) {
		if (tiflags & TH_SYN) {
			tiflags &= ~TH_SYN;
			ti->ti_seq++;
			if (ti->ti_urp > 1) 
				ti->ti_urp--;
			else
				tiflags &= ~TH_URG;
			todrop--;
		}
		if (todrop > ti->ti_len ||
		    todrop == ti->ti_len && (tiflags&TH_FIN) == 0) {
			/*
			 * Any valid FIN must be to the left of the
			 * window.  At this point, FIN must be a
			 * duplicate or out-of-sequence, so drop it.
			 */
			tiflags &= ~TH_FIN;
			/*
			 * Send ACK to resynchronize, and drop any data,
			 * but keep on processing for RST or ACK.
			 */
			tp->t_flags |= TF_ACKNOW;
			tcpstat.tcps_rcvdupbyte += todrop = ti->ti_len;
			tcpstat.tcps_rcvduppack++;
		} else {
			tcpstat.tcps_rcvpartduppack++;
			tcpstat.tcps_rcvpartdupbyte += todrop;
		}
		m_adj(m, todrop);
		ti->ti_seq += todrop;
		ti->ti_len -= todrop;
		if (ti->ti_urp > todrop)
			ti->ti_urp -= todrop;
		else {
			tiflags &= ~TH_URG;
			ti->ti_urp = 0;
		}
	}

Thanks for the sanity check!

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 3159

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Jul 1993 13:15:03 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: KEEPALIVE option for tcp sockets

In article <1993Jul12.103622.21194@visionware.co.uk>, chetanm@visionware.co.uk (Chetan Mistry) writes:
> Jordan Hayes (jordan@IMSI.COM) wrote:
> : I started the discussion about reading the manual because I wanted to
> : clarify that the manual pages (not to mention the 4.3 Book) say
> : *nothing* about getting notified when the KEEPALIVE timer goes off.
 
> : Ok, maybe that's a bug or a misfeature.  Regardless, It *only* says
> : that the socket will get marked as invalid and that the *next* time a
> : read or a write is attempted that it will return an error.
 
> : Specifically, I wrote:
 
> :    In all Unix implementations that I know of, if the keepalive timer
> :    goes off, the socket is marked as invalid, but select() does not
> :    return.
> 
> How do you detect that the KEEPALIVE timer has "gone off" ? If the
> socket has been marked as invalid, how do you detect this before doing
> a read/write operation ? You say that the read/write will fail, but surely
> it will fail anyway because the connection is broken ! So whats the
> point in having a KEEPALIVE option if it can't be detected and the software
> behaves exactly the same whether KEEPALIVE is set or not set ?
> 
> I'm the person who made the original posting. The man pages I showed were
> from a SPARC running SunOS 4.1.2 (but the pages are the same on 4.1.3
> and a Sun3) and were for setsockopt(). On our SVR4 machines (uname -a says: 
> Unisys 4.0 2 i386 386/AT and 4.0 3.0 486/AT i486) the man pages say that 
> you should receive a SIGPIPE, but this doesn't happen either. 
> 
> Whats happening ? Is this something that just hasn't been implemented,
> or is the documentation out of date ?
> 
> Chet


When you write "[SIGPIPE] doesn't happen either", do you mean it does
not happen only on the Unisys PC-AT clone running SVR4 or also on the
SPARC running SunOS 4.1.2?

What happens if you
	1. `rlogin` into the Unisys PC-AT clone.
	2. reboot the client machine.
	3. wait > 2 hours.
	4. check the processes still present on the Unisys PC-AT clone.

Does the PC-AT clone notice that the client has disappeared?  In other
words, does the shell process on the server disappear?  If the server
notices, then it is likely that Unisys's version of SVR4 does do TCP
keepalives.  If not, then Unisys's version SVR4 probably does not do
TCP keepalives.

If this experiment shows that the Unisys SVR4 does do keepalives (I bet
it does), but your use of them does fails, then it might be effective
to obtain and port the 4.3BSD rlogind.c code from any of the many
sources, and see why it works.


Vernon Schryver,  vjs@sgi.com

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1993 16:52:07 GMT
From:      salzberg@kiwi.imgen.bcm.tmc.edu (Benjamin Salzberg)
To:        comp.protocols.tcp-ip
Subject:   compuserve or MCI from internet



hi, 

how can i send messages to a compuserve address from my internet-based
e-mail? 

is it also possible to MCI Mailbox ?


thanks,
beni 


-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Jul 1993 16:56:02 GMT
From:      ba.cgb@RLG.Stanford.EDU (Clif Baker)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve or MCI from internet

In article <21s4rn$sim@gazette.bcm.tmc.edu> salzberg@kiwi.imgen.bcm.tmc.edu (Benjamin Salzberg) writes:
>Path: nntp.Stanford.EDU!morrow.stanford.edu!decwrl!decwrl!elroy.jpl.nasa.gov!usc!howland.reston.ans.net!darwin.sura.net!convex!bcm!salzberg
>From: salzberg@kiwi.imgen.bcm.tmc.edu (Benjamin Salzberg)
>Newsgroups: comp.protocols.tcp-ip
>Subject: compuserve or MCI from internet
>Date: 12 Jul 1993 16:52:07 GMT
>Organization: Molecular Biology Information Resource, Baylor College of Medicine, Houston, Tx
>Lines: 13
>Distribution: world
>Message-ID: <21s4rn$sim@gazette.bcm.tmc.edu>
>NNTP-Posting-Host: kiwi.imgen.bcm.tmc.edu
>Originator: salzberg@kiwi.imgen.bcm.tmc.edu
>
>
>hi, 
>
>how can i send messages to a compuserve address from my internet-based
>e-mail? 
>
>is it also possible to MCI Mailbox ?
>
>
>thanks,
>beni 
>

Beni,

In general the e-mail addresses for the two services are:

E-MAILID@COMPUSERVE.COM & E-MAILID@MCI.COM


Have fun!

Clif

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1993 17:21:40 GMT
From:      whalenm@tsg.com (Matthew Whalen)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve or MCI from internet

In article <21s4rn$sim@gazette.bcm.tmc.edu>  
salzberg@kiwi.imgen.bcm.tmc.edu (Benjamin Salzberg) writes:
> 
> how can i send messages to a compuserve address from my internet-based
> e-mail? 
> 
> is it also possible to MCI Mailbox ?
> 
> beni 

To send to compuserve, you send to 

	username@compuserve.com

I don't remember how to send to MCI, but I would guess it's somethine like  
username@mci.com

--
-matthew           ____    equal rights, not special rights  
whalenm@tsg.com    \  /         
(NeXTMail OK)       \/     Only dead fish swim with the stream. 
----------------------------------------------------------------
(My actions/words in no way reflect those of my employer.)

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Jul 1993 20:21:35 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve or MCI from internet

salzberg@kiwi.imgen.bcm.tmc.edu (Benjamin Salzberg) writes: 

>how can i send messages to a compuserve address from my internet-based
>e-mail? 

If you're sending to user 11111,222 on Compuserve, address it:

11111.222@CompuServe.COM

>is it also possible to MCI Mailbox ?

I don't know, maybe someone else can answer that.

Fred

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 93 20:45:33 GMT
From:      jordan@IMSI.COM (Jordan Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: KEEPALIVE option for tcp sockets

Chetan Mistry <chetanm@visionware.co.uk> writes:

	How do you detect that the KEEPALIVE timer has "gone off"?

Under SunOS, I try to use the socket in some way in order to generate
the error.  Typically FIONREAD will do it.  Others have reported that
Ultrix "fixed" this by actually delivering you a signal.

/jordan

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Jul 1993 21:19:03 GMT
From:      emurphy@cs.uno.edu (Edward Murphy)
To:        comp.protocols.tcp-ip,comp.sys.ibm.pc.hardware
Subject:   (?) COMPEX ENET32 card and NCSA Telnet


I am having difficulty connecting a PC to our net. The environment is a  
486 clone (EISA bus), a Compex ENET32 (32-bit ethernet adapter), and NCSA  
Telnet 2.3.6. I am hoping that someone has experience with this particular  
type of setup and can answer a few questions for me. Please reply via  
e-mail.

Regards,

Ed Murphy
emurphy@cs.uno.edu
emcs@uno.edu

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Jul 1993 21:40:04 GMT
From:      moodys@tigger.jvnc.net (Moodys Investors Service)
To:        comp.protocols.tcp-ip
Subject:   Re: CSLIP on a SUN

Sorry if this is a FAQ question but I just compiled cslip
and I would love to get it running.

I dialed into a terminal server, which runs slip, entered the
right passwd for my assigned IP @, backgrounded the job, ran
slip-attach for the right addresses and tried to ping the terminal
server.

Of course it told me *network unreachable*.  Then how do you
establish the route w/o a  /etc/hostname.le0 to be listed in the
hosts file.  I'd be really grateful if you'd fill me in since I'm
mystified.

Thanks in advance-    John van Vlaanderen aka moodys@tigger.jvnc.net




-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1993 09:22:12 -0700
From:      donegan@stanton.wdc.com (Steven P. Donegan)
To:        comp.protocols.tcp-ip
Subject:   Kermit 3.13 and TCP/IP

I recently grabbed and installed Kermit 3.13 on a PC. The TCP/IP functions
work quite well but the host I'm using is set up for kermit file transfer
protocols. Is there some way of using kermit during the telnet session?

Thanks for any pointers.

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Jul 1993 21:58:28 GMT
From:      cmclal@lizzie.arh.cdc.com (A. Sudhakarlal)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.

Thanks a lot for all the responses that came in for my article on TCP checksum.
After going through all the responses, I understand that checksumming in TCP/IP
protocol suite has not been taken care of cautiously.

As we all know that TCP/IP has been more successful in internetworking, it is
important that we must have a standard for checksumming which takes into
account various hardware platforms and other related issues.

Louis Mamakos says that one can get 0xffff as checksum value on 1's complement
machine. He says that the ALU on such a machine would never give 0xffff as the
result of an arithmetic operation. I want to point out here that only summation
is involved in calculating checksum, and it is on "unsigned" values. So one can
get 0xffff as the result of an unsigned summation. In that case, checksum 
would be zero. So one can never get 0xffff as the checksum.

I agree that in TCP/IP standards, we should have 0xffff to mean "no checksum",
and all other values should be considered as checksum values. Will this work?

A. Sudhakarlal ( lal )                      email:cmclal@lizzie.arh.cdc.com
System software programmer                  Ph: (612) 483 - 6627
Communications
Control Data 


-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1993 01:36:04 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there hardware support for PPP or SLIP to implement the following....

In article <RSI.93Jul12174555@scf16.scf.loral.com> rsi@scf16.scf.loral.com (Rich S. Ishikawa) writes:
>What I'm interested in is some hardware product that implements the
>mux portion of the above diagram.

The "mux" is usuall called a "terminal server".  Modern ones handle
SLIP and PPP as well as the more traditional ASCII dumb terminals.

-- 
Stephen Trier (trier@ins.cwru.edu - MIME OK)   
Network Software Engineer              
IRIS/INS/T                               
Case Western Reserve University             

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Jul 1993 01:45:55 GMT
From:      rsi@scf16.scf.loral.com (Rich S. Ishikawa)
To:        comp.protocols.tcp-ip
Subject:   Is there hardware support for PPP or SLIP to implement the following....




Hi,


I'd like to know it there is hardware multiplexing support to implement the
following configuration:





	       						    ______
    --------		                -------     PPP/WAN |Modem---RS232--PC
    |Sun   |			     	|     |--------------______
    |Server|	   Ethernet/LAN         | MUX |-----|
    |      |----------------------------|     |---| | PPP     ______
    --------	   TCP/IP on coax 	-------   | |-------- Modem---RS232--PC
				                  |  PPP      ______
				       	          |-------- _____
					      	            modem---RS232--PC
						            _____


What I'm interested in is some hardware product that implements the
mux portion of the above diagram.  This would be in a form of
Ethernet to PPP supporting multiple serial connections.


Can this be done??                     Please email responses!!
What hardware can do it??
Which is recommended??


Much thanks,



-Rich



--
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
-*-*-* Richard S. Ishikawa -*-*-*-*-\     "To be or not to be..."     /*-*-*-*-
-*-*-*-* rsi@srs.loral.com -*-*-*-*-*-\   - can't be the question.  /*-*-*-*-*-
-*-*-* Loral Space and Range Systems *-*-*-*-* (408)734-6337 *-*-*-*-*-*-*-*-*-
-*-*-*-* 1260 Crossman Ave. Sunnyvale, CA  94089 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Jul 1993 03:38:15 GMT
From:      hjb@netcom.com
To:        comp.protocols.tcp-ip
Subject:   Re: KEEPALIVE option for tcp sockets

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>If this experiment shows that the Unisys SVR4 does do keepalives (I bet
>it does), but your use of them does fails, then it might be effective
>to obtain and port the 4.3BSD rlogind.c code from any of the many
>sources, and see why it works.

i know that it does keepalives. but be aware that this version of tcpip
(in various releases) have some mind-blowing hacks thrown into it --
like ridiculously short default keepalive time, and tcp checksums
turned off by default in some releases!, and hacked up socket library
which is not really fully bsd compatible, and gross hacks to make the
loopback go faster, etc., the list goes on...

love
hwajin
--
Hwajin Bae    PEACEFUL STAR PROJECT 	*IX/Realtime/Embedded/Network Consultant
Internet: hjb@netcom.com,  hjb@hybrid.com,  hwajin@wrs.com, hjb@netapp.com
Vox: 510.536.7607 / Page: 510.466.9166


-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Jul 1993 04:19:11 GMT
From:      eajjs@cbnewsf.cb.att.com (john.sottile)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there hardware support for PPP or SLIP to implement the following....

In article <RSI.93Jul12174555@scf16.scf.loral.com> rsi@scf16.scf.loral.com (Rich S. Ishikawa) writes:
>
>	       						    ______
>    --------		                -------     PPP/WAN |Modem---RS232--PC
>    |Sun   |			     	|     |--------------______
>    |Server|	   Ethernet/LAN         | MUX |-----|
>    |      |----------------------------|     |---| | PPP     ______
>    --------	   TCP/IP on coax 	-------   | |-------- Modem---RS232--PC
>				                  |  PPP      ______
>				       	          |-------- _____
>					      	            modem---RS232--PC
>						            _____
>
>

The Telebit NetBlazer does exactly this.  It supports up to 26 Serial ports
(I have the "old" version which does up to 26 ports).  I have the original
Netblazer in a 2 port configuration and have set it up using
both SLIP and PPP on demand.  It even supports several PPP or SLIP
connections to the same place and spreads the load.  In the old 2 port
configuration (2 8550 Serial Ports -- lots of interrupts), I was
able to get 7KBytes/Second with very flat data (ASCII).  With 
Compressed files using rcp, I saw 2.7 KBytes/s.  I used it with NFS
for a long time and saw good numbers once I tuned the NFS
timeo and rsize/wsize stuff.  They had a DIGIBoard 8 which
allows for 8 Ports locked at 56KBps and I presume that I would have gseen
slightly better numbers.  The New Versions just came out and although
I haven't seen it yet, I can expect top notch stuff as before.

Oh, BTW, they have this modemcap file which allows you to add
modems not described in the "generic" configuration.  I understand
that 2 Companies have demonstrated V.Fast Capabilities in
a modem (28.8K plus data compression -- up to 115Kbps).  I
saw a demonstration on the Paradyne and have read about the Comdex.  Both
are proprietary until V.Fast is standarized (end of this year or
sometime early next year, perhaps).  If you get a configuration
which has something like the New NetBlazer, Digi-8 Cards locked
at 115Kbps and in parallel, I bet you would see some impressive
numbers.

I've also run X Traffic over it too.  All in all a good product.

I Think Telebit's 800 number is
1-800-TELEBIT.



=============================
John Sottile                             "That Guy has to Oil his Brakes!"
AT&T Bell Labs                           #include <std/disclaimer/who-me?.h>
jjs@cblph.att.com

My comments are mine and not AT&T's.

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1993 10:15:14 +0100
From:      cudep@csv.warwick.ac.uk (Ian Dickinson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: What do people do for load-balancing in IP?

In article <21mfm2$m0f@usenet.ins.cwru.edu>,
	trier@odin.ins.cwru.edu (Stephen C. Trier) writes:
>In article <1993Jul9.212742.1341@atlastele.com> sameer@atlastele.com writes:
>>Also, what about load balancing between two hosts connected by a dual
>>dial-up SLIP lines. How would that work.
>>In case one line goes down the traffic shifts to the other line. Any ideas ?
>That's a routing issue.  Any routing algorithm can cope with the
>fallback from one line to another.  The Internet would hardly work were
>that not the case!

True.

>Sharing load while both lines are up is a more difficult problem, but I
>think Cisco advertise that their routers can do it.

This being the main point of the question.
So, if Cisco can do it - is is a proprietary workaround??
How do you do it if both ends of the line happen to be, say, Suns?

An arbitrary external process plugged into named for certain addresses,
would allow complicated behaviour without client changes, and would be very
extendible.  It could cope with the above situation, load balancing, and policy
based return values pretty easily - especially if the program provided named
with the equivalent of a $INCLUDE'd file with TTLs which can then have other
defaults substituted within it and sent on to the client that queried.

>Followups to comp.protocols.tcp-ip.

And back again to comp.protocols.tcp-ip.domains since I don't think you got
*ALL* the answer.

Cheers,
-- 
\/ato - Ian Dickinson - NIC handle: ID17          This article is dedicated to
vato@csv.warwick.ac.uk  ...!uknet!warwick!vato        those who disapprove but
/I=I/S=Dickinson/OU=CSV/O=Warwick/PRMD=UK.AC/ADMD= /C=GB/          continue to
@c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson      read

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1993 12:03:31 GMT
From:      welander@i4.informatik.rwth-aachen.de (Bjoern Welander)
To:        comp.protocols.tcp-ip
Subject:   More on Unexplainable Measurement Figures ?!

Hi !

Thanks for all your answers to my previous mail. I recieved a whole lot of
answers asking for more elucidation. I would therefor like to repeat my
earlier question and add some clearifying information.

As I wrote before we are doing performance measurements with TCP and XTP,
using SUN Sparc-2 workstations connected to an Ethernet. When we load the
CPU:s on both SUN:s with 15 background processes we get some rather
peculiar measurement results. 

The background processes do not send anything on the net. They are just
simple C-programs counting from zero to 100.000 an infinite number of
times.

Here follows a sample measurement. It is made with XTP, but we find similar
results also with TCP.

No.   1	delay:   5.61 s	throughput:   5700 Kbit/s
No.   2	delay:   5.62 s	throughput:   5696 Kbit/s
No.   3	delay:   5.61 s	throughput:   5703 Kbit/s
No.   4	delay:  20.64 s	throughput:   1551 Kbit/s
No.   5	delay:   5.62 s	throughput:   5698 Kbit/s
No.   6	delay:   5.63 s	throughput:   5689 Kbit/s
No.   7	delay:   5.63 s	throughput:   5689 Kbit/s
No    8	delay:   5.65 s	throughput:   5668 Kbit/s
N.    9	delay:  12.19 s	throughput:   2626 Kbit/s
No.  10	delay:  23.81 s	throughput:   1344 Kbit/s
No.  11	delay:   5.63 s	throughput:   5683 Kbit/s
No.  12	delay:   5.64 s	throughput:   5677 Kbit/s
No.  13	delay:   5.63 s	throughput:   5681 Kbit/s
No.  14	delay:   5.62 s	throughput:   5695 Kbit/s
No.  15	delay:   5.64 s	throughput:   5669 Kbit/s
No.  16	delay:  10.85 s	throughput:   2959 Kbit/s
No.  17	delay:   5.69 s	throughput:   5619 Kbit/s
No.  18	delay:   5.65 s	throughput:   5668 Kbit/s
No.  19	delay:   5.62 s	throughput:   5692 Kbit/s
No.  20	delay:   5.62 s	throughput:   5692 Kbit/s
No.  21	delay:   5.64 s	throughput:   5679 Kbit/s
No.  22	delay:   5.64 s	throughput:   5678 Kbit/s
No.  23	delay:   8.24 s	throughput:   3883 Kbit/s
No.  24	delay:   5.60 s	throughput:   5712 Kbit/s
No.  25	delay:   5.61 s	throughput:   5703 Kbit/s

rate: 512.000 bytes/s
burst: 14.560 bytes/burst
window size: 21.504 bytes
background network load: 0 %
background CPU load: 15 processes


It seems as if the mean delay should be somewhere between 5.6 and 5.7
seconds. But totaly randomly these up to four or five times bigger values
appear without any reasonable explaination. Note that these higher values
don«t appear when there are no background processes. My question is simply;
can anybody explain these strange values?

For the measurements we are using the ttcp respective txtp tools. Every
transmission is 4 Mbyte of data. The workstations are situated in the same
building on two different Ethernets, connected through a third Ethernet.
The Ethernets are connected with each other with bridges. 

Our best guess so far is that it has something to do with the UNIX
operating system. Since it isn«t a real-time OS variations could be
expected, but reasonably not this high.

All good (and bad) explainations (and guesses) are warmly welcome

Bjoern Welander

:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:
:    Bjoern Welander         Institute of Computer Science IV     :
:                            Aachen University of Technology      :
:                                                                 :
:    welander@i4.informatik.rwth-aachen.de                        :
:		                                                               :
:                    HA EN TREVLIG DAG !                          :
:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 93 13:03:32 GMT
From:      devdjn@space.alcbel.be (Dennis Newport)
To:        comp.protocols.tcp-ip
Subject:   Re: More on Unexplainable Measurement Figures ?


We have done similar measurements between SPARC IIs, IPCs and HP
9000/827s. We only used TCP and made the measurements with our own
test programs (all software written in Ada because it's an ESA project).
We used message sizes of 1, 50, 100, 128, 1023, 1024, 1025, 4095, 4096
4097, 8K, 16K and 20K to transmit 4MB (I think). But we never saw this
type of anomalous behaviour. We also set off background processes (upto
10) and still no strangeness. I'd like to give you our figures but I
can't say too much because they belong to ESA. I can say that in a 
multi-tasking Ada environment with no appreciable network or CPU load on
SPARC IIs we managed around 2.5-3 Mb/s (steady state) for 4KB messages and 
this fell to 900 Kb/s when we used our traffic generator to put 50% load 
on our Ethernet LAN and put an extra 10 CPU intensive processes on the
machines.

Sorry we can't be of more help.

---
Dennis Newport,                  email: devdjn@space.alcbel.be
Alcatel Bell Telephone,
Berkenrodelei 33,                phone: (+32) 3/829.5488
2660 Hoboken,
Belgium.

Ha en det sa bra (inte ratt stavning - ingen Svensk bokstaver pa datorn).



-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Jul 1993 14:16:31 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: More on Unexplainable Measurement Figures ?!

In article <welander-130793140134@freitag.informatik.rwth-aachen.de>, welander@i4.informatik.rwth-aachen.de (Bjoern Welander) writes:
> ...
> As I wrote before we are doing performance measurements with TCP and XTP,
> using SUN Sparc-2 workstations connected to an Ethernet. When we load the
> CPU:s on both SUN:s with 15 background processes we get some rather
> peculiar measurement results. 
> ...
 
> No.   1	delay:   5.61 s	throughput:   5700 Kbit/s
> ...
> No.   4	delay:  20.64 s	throughput:   1551 Kbit/s
> No.   5	delay:   5.62 s	throughput:   5698 Kbit/s
> ...
 
> rate: 512.000 bytes/s
> burst: 14.560 bytes/burst
> window size: 21.504 bytes
> background network load: 0 %
> background CPU load: 15 processes
 

> It seems as if the mean delay should be somewhere between 5.6 and 5.7
> seconds. But totaly randomly these up to four or five times bigger values
> appear without any reasonable explaination. Note that these higher values
> don«t appear when there are no background processes. My question is simply;
> can anybody explain these strange values?
> 
> For the measurements we are using the ttcp respective txtp tools. Every
> transmission is 4 Mbyte of data. The workstations are situated in the same
> building on two different Ethernets, connected through a third Ethernet.
> The Ethernets are connected with each other with bridges. 
> 
> Our best guess so far is that it has something to do with the UNIX
> operating system. Since it isn«t a real-time OS variations could be
> expected, but reasonably not this high.


Do the background process run continuously from the start of the first
test until the end of the last?  Without being restarted?  How does
their CPU priority vary?  Does the kernel you are using occassionally
give higher priority to jobs that have not had a chance to run for a
long time?  (`ps` can often be used to discover processes' CPU
priority.)  What happens if you modify your background processes to
print or log their progress, say announce every 1,000,000th iteration?
Do you see a similar variation in iterations/second?

What are you trying to simulate?  Do you really expect your systems to
have a load average higher than 15 when you are using TCP or XTP for
whatever you intend?

Why are your TCP numbers so low?  Why are you getting only 500KB/sec in
the good times?


Vernon Schryver,  vjs@sgi.com

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 93 14:49:01 GMT
From:      mills@athena.lkg.dec.com (George Mills)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Tips on alternative to NFS requested.

jim@cs.strath.ac.uk (Jim Reid) writes:

>In article <1993Jul9.075843.3569@ericsson.se> etxmesa@eos.ericsson.se (Michael Salmon) writes:
 
>   Basically I need a more secure remote file system and a simpler one,
>   the first requirement is the more important. It should also not consume
>   very much processor time and be supported by every Unix system.

You might consider DEC-Athena for the PC (in pilot stage now). It offers
significant increases in security with out compromising speed or compatability.
and a many other benifits as well.

Send mail to pc_pilot@athen.tay.dec.com for more information.

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 93 15:12:25 GMT
From:      ICH211@DJUKFA11.BITNET (Thomas Heil)
To:        comp.protocols.tcp-ip
Subject:   LPR protocol documentation

Hello!

Does someone know if there is ftp'able documentation on the LPR protocol
somewhere (something beyond RFC1179)? I have some questions that this RFC
cannot answer.

1. What is the way to get multiple copies of a document? Do I have to send
   the file several times, or is there a control file option that is not in
   the RFC?

2. What is the file type to use for printing raw printer data (data that has
   to get to the printer without being further filtered)? "v" or "f" or "l"?

Maybe someone can shed some light. Please reply to me directly.

/Thomas

---------------------------------------+--------------------------------------
Mail: Thomas Heil                      | EMail: BITNET: ICH211@DJUKFA11.BITNET
      Forschungszentrum Juelich - ICG2 |      Internet: th.heil@kfa-juelich.de
      D-5170 Juelich                   | Phone: +49 2461 61-6915
      Germany                          | Fax:   +49 2461 61-5346

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 93 15:42:05 GMT
From:      trt@duke.cs.duke.edu (Tom Truscott)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.


>I agree that in TCP/IP standards, we should have 0xffff to mean "no checksum",
>and all other values should be considered as checksum values. Will this work?

If you are asking "is it okay for us to implement a TCP/IP product
with the roles of 0 and 0xffff reversed?" then the answer is NO!
A thousand times NO!

The checksum rules in rfc1122 are fairly clear
IP checksums and TCP checksums are always present, and MUST be checked.
Line 4646 tells us that a 0 in the UDP checksum field means "no checksum".
Line 4590 tells us that a non-0 UDP checksum MUST be checked.
From line 4620 we can infer that, for IP and TCP,
0 and 0xffff may be used interchangeably.

=====

If you are asking "wouldn't it be better if 0xffff had mean't no checksum"
then I would say yes.
But as Louis Mamakos pointed out, having 0 mean "no checksum" made
good sense on the ones complement machines that were popular
on the ARPAnet back in the old days.
And in any event this is a trivial efficiency issue
compared with e.g. getting rid of checksums entirely :-)

=====

Vaguely related, and in a desperate attempt to change the subject...

One thing that is worrying me these days is that the future of computing
is looking little-endian.  x86 is little-endian.
DOS and Windows (including NT) and OS/2 are little-endian.
Most RISC chips are now bi-endian, for compatibility with the above.
If five years from now the industry has settled on little-endian,
won't the TCP/IP "network order" look like a terrible mistake?

Tom Truscott

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Jul 1993 15:46:40 GMT
From:      dwight@hyphen.com (Dwight Ernest)
To:        comp.protocols.tcp-ip
Subject:   FAX via TCP/IP?

Hi.  I'm interested in finding out what other sites might be using to
get FAX functionality working through TCP/IP circuits.  We have TCP/IP
connectivity between two of our main company sites (soon to be more),
and since it's gone online, I've gotten a flood of inquiries from a
very wide variety of people, from bean-counters to programmers, about
whether it would be possible to use that circuit to connect FAX machines
on each end.

What are other people doing for this?

I've glanced through RFC809, but it seems pretty dated.


-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Jul 1993 17:38:48 GMT
From:      ag129@ucs.cam.ac.uk
To:        comp.protocols.tcp-ip
Subject:   Re: LPR protocol documentation

In article <93194.171425ICH211@DJUKFA11.BITNET> ICH211@DJUKFA11.BITNET (Thomas Heil) writes:
>1. What is the way to get multiple copies of a document? Do I have to send
>   the file several times, or is there a control file option that is not in
>   the RFC?

Every line in the control file that starts with a lower-case letter 
causes the file to be printed out.  You just need more than one of them.

>2. What is the file type to use for printing raw printer data (data that has
>   to get to the printer without being further filtered)? "v" or "f" or "l"?

Use 'v'.  Both 'f' and 'l' refer to text, which even if control chars
are passed through, is likely to be subject to ASCII-EBCDIC conversion,
have its line feeds turned into record boundaries etc.  In fact it is
less than a week since someone crashed our LPD/NJE gateway by sending
binary data to it using an 'l' code.
--
Alasdair Grant, England

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1993 18:34:57 GMT
From:      vijay@hicomb.hi.com (P.A. Vijayakumar)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   TCP/IP performance evaluation programs

I am looking for TCP/IP performance evaluation programs on
UNIX using sockets. I am currently using netperf which is
pretty good but I am also interested in looking at others (if any).
If anyone out there knows of any other programs, please let me know.

Thanks in advance.

Vijay
(vijay@hicomb.hi.com)

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1993 19:06:11 GMT
From:      roy@mchip00.med.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve or MCI from internet

ba.cgb@RLG.Stanford.EDU (Clif Baker) writes:
>In general the e-mail addresses for the two services are:
>
>E-MAILID@COMPUSERVE.COM & E-MAILID@MCI.COM

At least for Compuserve, you also have to change the "," in the E-MAILID
part to a ".".

-- 
Roy Smith <roy@nyu.edu>
Hippocrates Project, Department of Microbiology, Coles 202
NYU School of Medicine, 550 First Avenue, New York, NY 10016
"This never happened to Bart Simpson."

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Jul 93 19:37:04 GMT
From:      heiser@TDWR.ED.RAY.COM (Bill Heiser)
To:        comp.protocols.tcp-ip
Subject:   IP Filtering for SunOS 4.X

Please accept my apologies if this (comp.protocols.tcp-ip) isn't
the right newsgroup for this post.

DEC Ultrix has a program called "screend" which acts as an IP filter,
allowing a DECstation to be used, say, as a FIREWALL between two
networks.  I am interested in a comparable program for use on a 
SunOS 4.1 system.  Is there such a thing?  If so, where might I
find it.

Thanks in advance,
Bill


-- 
Bill Heiser                         Business: heiser@TDWR.ED.RAY.COM
Unix Workstation System Manager     Personal: heiser@world.std.com

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Jul 1993 20:33:22 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Any site with comp.protocols.tcp-ip archives available for anonymous FTP?

I need to dig into some old comp.protocols.tcp-ip postings. Are there any
archive sites available? I didn't find any with archie.

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Jul 1993 20:57:52 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   tcpdump is now available for HP-UX, but requires extra STREAMS software

tcpdump is now available for HP-UX on the 700 and 800 series systems. This is
something I've been wanting for quite a while, and I found out about it more
or less by accident... this is the posting with the announcement:

----------------------------------------------------------------------
From: librarian@iworks.ecn.uiowa.edu (InterWorks librarian)
Subject: InterWorks software library (update #21)
Date: Tue, 13 Jul 1993 03:05:52 GMT

The following is a list of new (or updated) entries (since my last posting),
of UX-related software on the InterWorks library node (iworks.ecn.uiowa.edu--
128.255.18.10). Note that everything is available via anonymous ftp-- in 
"comp.hp"). The README there contains a complete list of the available 
software.
...
    128965     tcpdump.tar.Z
                  HP-UX (unofficial) tool to dump identified headers of
                  network packets. Suitable for PA-RISC 9.x systems only.
                  Version 2.2.1.  
----------------------------------------------------------------------

I retrieved the package, and found that it contained the following README:

----------------------------------------------------------------------
This is revision 2.2.1 of tcpdump, modified to work on HP-UX. For tcpdump
to work, your system must be running HP-UX 9.0 (S800) or 9.01 (S700) and 
have the STREAMS/DLPI product installed. It must also have either patch
PHNE_2666 or PHNE_2665 installed (one is 700, the other 800).

On HP-UX, tcpdump MUST NOT be setuid root. It should only be run by root,
to do otherwise is to ensure a panic - YOU HAVE BEEN WARNED!-) Just in
case this was not clear - this programs should ONLY be run by root.
This program should NOT be chmoded to be setuid root and then run by
normal users.

I have not tested this software on anything other than the Series 700. I
am told that it "should" work on the Series 800 (at least those systems
with the half-height NIO (lan3) interface. It certainly will not run on 
the 68K systems. This is a PA-RISC1.1 shared executable dynamically linked.

This is at the *FARTHEST* edges of the UNSUPPORTED spectrum. At some
point, after being blessed by the original authors, I am sure that the
source changes will be distributed via the normal Internet means.

This g-job would not be possible without the gracious assistance of
Warren Burnett and other members of the HP IND LAN Drivers project,
who provided me with example code for DLPI.

enjoy,
rick jones
----------------------------------------------------------------------

So, tcpdump for HP-UX is here, finally - but unfortunately it requires an
unbundled STREAMS product.

HP is to be congratulated on making tcpdump available. Now if we could
only have it *without* needing to an extra piece of software, like we can
with Sun and DEC workstations for instance :-)

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1993 22:28:40 GMT
From:      Pearce Turpin <lanshark@llnl.gov>
To:        comp.protocols.tcp-ip
Subject:   TCP/IP - Novell - WAN from HELL!

I will buy dinner for the person who solves this one. 5 LAN's connected
via a T1 WAN with a UNIX host on one of the LAN's. We have a proprietary
app that needs Racal/Interlan NP600 'smart' NIC's running their own
version of FTP's PC/TCP designed for the NP600. The routers are Netware
3.11-based with 3C509 LAN NIC's and Novell's Multi-protocol Router boards
on the WAN side. Our addresses are all class 'C'. We have no subnets.
Everything works fine, except when we try to use the NP600 based PC's. I
cannot ping anything outside my own net. I can ping the NIC on the LAN
side of the router, because it's on the same net. Now, if I use LWP ODI
drivers, everything works perfectly. The same with FTP's PC/TCP ver 2.2
and the UNIX host. The only thing that dosn't work is the PC's with the
NP600. I'm assuming either:

a. The router is not seeing packets sent by that particular board for
what ever reason.
or
b. The boards are not compatible with SOMETHING, even though I've
isolated everything
and they work locally.

I think it's (a), but  I can't, for the life of me, figure out why. The
server is set up to receive any size packet, and everything else wroks
just fine.

Any of all input appreciated, and I'm serious about the dinner.......

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Jul 1993 23:18:16 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP - Novell - WAN from HELL!

Pearce Turpin <lanshark@llnl.gov> writes: 

>I will buy dinner for the person who solves this one. 5 LAN's connected
>via a T1 WAN with a UNIX host on one of the LAN's. We have a proprietary
>app that needs Racal/Interlan NP600 'smart' NIC's running their own
>version of FTP's PC/TCP designed for the NP600. The routers are Netware
>3.11-based with 3C509 LAN NIC's and Novell's Multi-protocol Router boards
>on the WAN side. Our addresses are all class 'C'. We have no subnets.
>Everything works fine, except when we try to use the NP600 based PC's. I
>cannot ping anything outside my own net. I can ping the NIC on the LAN
>side of the router, because it's on the same net. Now, if I use LWP ODI
>drivers, everything works perfectly. The same with FTP's PC/TCP ver 2.2
>and the UNIX host. The only thing that dosn't work is the PC's with the
>NP600. I'm assuming either:
>
>a. The router is not seeing packets sent by that particular board for
>what ever reason.
>or
>b. The boards are not compatible with SOMETHING, even though I've
>isolated everything
>and they work locally.
>
>I think it's (a), but  I can't, for the life of me, figure out why. The
>server is set up to receive any size packet, and everything else wroks
>just fine.
>
>Any of all input appreciated, and I'm serious about the dinner.......

By "pinging", I assume you mean they won't do *anything* with a peer outside
of their own net, e.g. ftp, telnet, etc.  There's a DIFFERENCE, ya know...
(If it were just ping problems, the difficulties might be limited to
icmp packets or something weird like that.)

The simplest explanation would be that the special FTP software is having
some sort of problem finding the default router.  I suspect you may not
have configured the address of the Netware router in correctly - or if
you have, that the special FTP software is just not working right.

Naturally, it would be interesting to hook up a network analyzer and see what
network activity took place when you attempted to ping something outside the
net.  From what you described, I would expect to see (in the following order
of preference):

1) No activity at all - as the FTP software recognizes that it has to route
the packets but doesn't know where to.

2) An arp broadcast for the IP address of the peer on the remote network.

or

3) An arp broadcast for the Novell router - in which case I'm wrong and
something completely different is the problem.  (Becuase this would be the
correct behavior, so far.)

Fred

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 93 00:51:27 GMT
From:      mayshah@gandalf.rutgers.edu (Mayank Shah)
To:        comp.protocols.tcp-ip
Subject:   Extended Error message

Hi Folks,

I am testing IBM's TCP/IP v 2.2?(2.1) and NFS.  I am mounting unix drive
on to a ps/2, and I am facing some problems.  I hope that someone can
help me. IF you can please e-mail them to me.

Drive J is mounted for the unix station.  so I type :dir /s (to get a long)
directory list.  It will start displaying the dir, then at one point it will
stop and say :Extended Error 51:  Does anyone know what this means, 
what causes this and how do i fix this.
Problem, 2:  When running applications from the server, root or someone 
else is the owner, under windows I get a message "Access Denined, ...".

So, I copied Winfile on to the server (so I was the owner), now the message
I get is "Insufficent memory to run that appliation).  I have 8mb or RAM./

I hope someone can reply, 

Thankx in advance.

Mayank

-- 
------------------------------------------------------------------------------
Mayank Shah				Rutgers University
mayshah@gandalf.rutgers.edu

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 93 05:40:08 GMT
From:      catone@compstat.wharton.upenn.edu (Tony Catone)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: NFS or other fileserver protocols

In article <C9qvqJ.FIA@fs7.ece.cmu.edu> loss@fs7.ECE.CMU.EDU (Doug Loss) writes:

      I'm posting this because I think it's of general interest.  SOS is a
   public domain NFS server program for MS-DOS.  The PC that SOS is running
   on is dedicated, and can't be used as a user node while it's exporting
   its filesystem to other machines.

Actually, the product's name is SOSS.  You'll find a version with a
few bug fixes I made locally at
hilbert.wharton.upenn.edu:pub/tcpip/soss.zip.


- Tony
  catone@compstat.wharton.upenn.edu

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1993 17:54:40 -0500
From:      karl@genesis.MCS.COM (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   Re: What's the better way to administer IP addresses to dorms?

In article <136021@netnews.upenn.edu> tony@scotty.dccs.upenn.edu (Anthony Olejnik) writes:
>This september, the first phase of our student dorm wiring
>(to the campus IP/AppleTalk network) will be completed.
>
>As such, we're looking for the better (best, ideally) way
>to administer/assign IP addresses.
>
>Should we:
>	-statically assign them (one per network outlet)
>	-statically assign them but use BOOTP
>	-manually assign them (on an 'as-requested; basisc_
>	-etc.
>
>*ANY* help/comments would be *GREATLY* appreciated.
>Thanks in advance.

For this kind of situation I would probably do two things:

1)	Implement a "anonymous IP bootp" extension which would assign an
	address from a random pool (after trying to "arp" it to see if its
	already in use) and return that.  This works well for people with
	MACs and PCs that don't have persistent connections (ie: they want
	to telnet or FTP out, but don't care about incoming connections)  
	I can't imagine that this kind of extension to bootpd would take 
	more than a day to implement and test.

2)	Allow registration of MAC level addresses for permanent IP
	assignment for those people running something like (or equivalent
	to) Unix, who want inbound connections to their machine to be
	possible.

--
Karl Denninger (karl@genesis.MCS.COM) 	| You can never please everyone except
Modem Access: [+1 312 248-0900]		| by bankrupting yourself.
Voice & FAX: [+1 312 248-8649]		| Internet in Chicago; a MCSNET first!

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 93 16:47:30 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Kermit 3.13 and TCP/IP

In article <donegan.742580430@stanton.wdc.com>, donegan@stanton.wdc.com 
(Steven P. Donegan) writes:
> I recently grabbed and installed Kermit 3.13 on a PC. The TCP/IP functions
> work quite well but the host I'm using is set up for kermit file transfer
> protocols. Is there some way of using kermit during the telnet session?
> 
> Thanks for any pointers.
------------
Steven,
	Pardon for me looking puzzled, but have you gone ahead and done the
Kermit to Kermit file transfers over Telnet? MS-DOS Kermit works very well
that way (please scan the release docs again for hints: no flow control,
long packets, two or more window slots). If your host is running C Kermit
5A then setup CK the same way. The full story is in the user's manual,
the book "Using MS-DOS Kermit" by Christine Gianone, 2nd edition, Digital
Press and Prentice Hall, about ~$35.
	Joe D.

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1993 12:43:39 GMT
From:      fgs@kepler.unh.edu ( F r e D  S l a m A )
To:        comp.unix.questions,comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Port allocation below 1024 for users

    Is it possible to allocate a port below 1024 without having to be
	root? I realize that this question is odd and it is a matter of
	security that disallows port allocation below this number
	for users. Nonetheless, is there a way (without modifying the kernel).


													Thank you,
													-Fred

-- 
 ===============================================================================
 Frederick G. Slama at >>>>>>>>>>>>>| slama@ctron.com
 The University of New Hampshire <<<| fgs@kepler.unh.edu   F_SLAMA@unhh.unh.edu
 ===============================================================================

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Jul 1993 12:57:21 GMT
From:      rg@camb-lads.loral.com (Roger Gonzalez)
To:        comp.protocols.tcp-ip
Subject:   UDP Performance Testing


I need to test the UDP performance (send, receive, and latency) on several
different architectures.  I whipped out some programs that provided what
seemed like unreasonably fast numbers.  I suspect this was due to me actually
measuring nonuseful things like how long it takes for a process to wake up out
of a sleeping select().  I could keep tweaking my programs, (and I would love
some insight on what I should do to them) but I would prefer to use something
already written.

Thanks!





--
-Roger

Roger Gonzalez              Loral Advanced Distributed Simulation
rg@camb-lads.loral.com      50 Moulton Street, MS 3/A
home   (508) 465-3170       Cambridge, MA 02138
mobile (508) 641-0539       work (617) 873-4286 fax -4315




-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1993 13:54:44 GMT
From:      kbw@helios.ath.epa.gov (Kevin B. Weinrich)
To:        comp.protocols.tcp-ip,comp.unix.admin,comp.sun.admin
Subject:   SUMMARY: Sniffer programs

None of the recommended solutions really do the highly-specialized
task I wanted done, namely, to find out about the avg. ack. time
for a bunch of packets that all make up one file being transmitted.

But evidently a lot of folks are interested in simpler packet-capture
programs.  So, here are the programs I know about.  The messages
that brought them to my attention follow.

(My personal favorites:)
In space.mit.edu:/pub/netman you can find the following precompiled
binaries:
  etherman.tar.Z
  interman.tar.Z
  packetman.tar.Z and
  hershey-sun4c.tar.Z (hershey fonts needed for display of above)

I personally love etherman for showing me who's talking with who
on my net.  Lots of other goodies.  Interman is neat, but very
fragile.  Packetman does its job, but other packages (Tcpview) do it better.
No source available on these, and neither I nor others have been
able to get ahold of the boys from Down Under at Curtin Univ. who
wrote them up, so no support is available.

(See following messages for explanations of the following)
Tcpview and NNstat are available for UNIX boxes. Ask Archie for
locations. Gobbler is for PCs. Packetview and Netscope are low-cost
commercial solutions, both of which have free demo versions
available.

====================================================================
From: "Steve Alpert" <sra%idx.com@sadye.EMBA.UVM.EDU>
 Rumor has it that on the simtel archives is a pd network analyzer.  I've
wondered about it myself but only have e-mail access to internet and don't
have the patience to send an ftpmailer after it.
I recall seeing it mentioned in an Ad for a CD cut for SIMTEL that
included the VAX stuff.  I suspect this means that it isn't in the tree rooted
at pd1:<msdos...> but more likely pd1:<misc...> or some such.  Sorry I don't
have the name or more to go on.  Perhaps a note to Keith Peterson (keeper of
MISC) is in order...


====================================================================
From: gls@cirrus.com (Gary L. Schaps)

TCPVIEW - An Interactive Motif-Based Protocol Analyzer

This archive contains the source to tcpview and an enhanced tcpdump 2.2.1.
The two programs share much of the same source code.

Tcpview is the result of several problems we had at UW.  We have several
Network General Sniffers which are heavily used to help debug problems on
several hundred subnets. These are good tools, but they are 1) heavy, 
2) hard to find when you need one, 3) limited in their software expandibility,
4) difficult to use to upload data for analysis, 5) cannot be remotely
operated, and 6) cannot resolve names with DNS, requiring much manual 
manipulation of the name table.  We also sometimes use tcpdump, but we found 
it 1) too difficult for most people, 2) did not have enough information for
many protocols, 3) could not be used interactively, 4) could not handle
TCP streams and 5) could not read Sniffer files.  However, tcpdump did do
a reasonable job of decoding a large number of protocols, and had superior
filtering to the Sniffer.  Tcpview is an attempt to resolve these problems
by adding a Motif interface to tcpdump and expanding its features.

Tcpview has been tested on a DECstation 5000 and Sun 4 under Ultrix 4.2 and
SunOS 4.1 respectively.  It should work on the same systems as tcpdump.
It compiles with cc and gcc on the DEC and Sun.  To build tcpview you will
need Motif 1.1 or better.

What tcpview adds to tcpdump:
- easier interface
- enhanced protocol decoding
- hex display of frame
- capture based on time, number of frames, or user interrupt
- can show ethernet addresses with manufacturer's name
- ethernet address host table
- can easily follow a stream, highlighting out-of-order frames
- can send TCP data to an external file or filter for additional
	processing.

-------------------------------------------------------------------------------
CHANGES TO TCPDUMP 2.2.1

New features:

Now reads and writes Network General Sniffer files.  When used with '-r', the 
file type will be automatically detected.

Can now read in (and use) an SNMP MIB file.

The hex format has been changed.

New time options have been added.

Options were added to allow viewing and processing of the data in TCP packets.

Bugs were fixed in the relative TCP sequence numbers. (-S flag)

New flags:
-R	read Sniffer file.  Not usually needed, except for reading from stdin
-ttt	prints delta times
-tttt	prints times relative to the first frame
-W	write a Sniffer save file (use with -w)
-x	print frame (minus link-level header) in hexdump format.  
	Sample output:

16:36:23.349851 jeff.cac.washington.edu.1285 > nic.funet.fi.ftp: S 0:0(0) win 16384
        0000  45 00 00 28 8a 98 00 00 3c 06 7c 9c 80 5f 70 02   |  E..(....<.|.._p.
        0010  80 d6 06 64 05 05 00 15 5b 19 4a 00 00 00 00 00   |  ...d....[.J.....
        0020  50 02 40 00 4e 13 00 00 00 00 00 00 00 00         |  P.@.N.........

-X	print TCP data in hexdump format (used with -Z)
-z	write TCP data to stdout (use with -t to eliminate timestamp)
-Z	write frames and TCP data to stdout


FUTURE ENHANCEMENTS:

New and better detailed protocol decoders need to be written.  I'm
only planning to add those as we need them here at UW.  I'm hoping
others will find this tool useful enough to help out with enhancing
the protocol support.  I'm planning on expanding the visualization
options to include graphical representations of protocol traces.  I'm
also interested in adding in some intelligent protocol analysis.  How
far I get in this depends on the level of interest in it and how much time 
I have available.

Please send me any bug reports you have.  Also suggestions are always
welcome.  If you do write any new protocol decoders or add any enhancements,
let me know and I will include them in the next release.

Martin M. Hunt
martinh@cac.washington.edu
University of Washington

/*
 *
 * Copyright 1992 by the University of Washington
 *
 * Permission to use, copy, modify, and distribute this software and its
 * documentation for any purpose and without fee is hereby granted, provided
 * that the above copyright notice appears in all copies and that both the
 * above copyright notice and this permission notice appear in supporting
 * documentation, and that the name of the University of Washington not be
 * used in advertising or publicity pertaining to distribution of the software
 * without specific, written prior permission.  This software is made
 * available "as is", and
 * THE UNIVERSITY OF WASHINGTON DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
 * WITH REGARD TO THIS SOFTWARE, INCLUDING WITHOUT LIMITATION ALL IMPLIED
 * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, AND IN
 * NO EVENT SHALL THE UNIVERSITY OF WASHINGTON BE LIABLE FOR ANY SPECIAL,
 * INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, TORT
 * (INCLUDING NEGLIGENCE) OR STRICT LIABILITY, ARISING OUT OF OR IN CONNECTION
 * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 *
 */

====================================================================
From: jdl@cip250.corp.harris.com (John Little)
To: kbw@helios.ath.epa.gov
Subject: network
Content-Length: 204
Status: RO
X-Lines: 5

I think NNStat is the best packet capture and sort program I have seen.  It
allows you to capture just about anything that travels across your network.
Available via anonymous FTP, just use archie.
John

====================================================================
From: cruoho@nyx.cs.du.edu (Clint Ruoho)

If nobody has pointed you to gobbler yet, let me recommend that to you. 
It is a freely available and distributable ethernet sniffer, does tcp/ip
other files, and a number of other files.

It can be found at

	ftp.uu.net:/systems/ibmpc/msdos/wattcp/delft/gobbler.zip

If you need a package for Suns, you can look at etherfind or tcpdump, but
they're pretty yucky packages if you want to capture packets and look at
them in anything except hex.

====================================================================
From: klos@mv.MV.COM (Patrick Klos)
Organization: Klos Technologies, Inc.

Although this doesn't quite fit your description, you might be interested in
knowing about our product, PacketView, which is a low-cost PC-based protocol
analyzer.  It doesn't do statistics, but it's GREAT at packet capture.  It
can decode TCP/IP packets, including UDP and SNMP.  It does other protocols
also, but you indicated a specific need for TCP/IP only.  It costs $249.00
and you can check out a demo version by downloading it from our BBS at
(603) 429-0032 (if you're interested).

====================================================================
- Rick Thau

Though not public domain, you may want to download a demo of NetScope
from the mailserver below. It will run on your Sun workstation, and 
provide the capabilities of the Sniffer, as you requested.

---
- Rick Thau
	voice:	415/572-0200
	fax:	415/572-1300
	email:	rthau@qualix.com
	mail:	Qualix Group, Inc
		1900 S. Norfolk St., #224
		San Mateo, CA 94403
--------------------------------------------------------------
Qualix maintains a mailserver with information files and demo
versions of products.  If you would like more information on
the mailserver, send an email to qfacts@qualix.com (or,
uunet!qualix!qfacts).  The email body should take the following
form:
	BEGIN
	send help 
	send index
	END

	Name, company or affiliation
	Address
	Phone
--------------------------------------------------------------



-- 
Kevin Weinrich     Computer Sciences Corp.
kbw@helios.ath.epa.gov

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Jul 1993 14:33:05 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   System Tuning

I am interested in "rules" that can be used to characterize system and
network problems. I have some papers from Sun on NFS tuning, but 
I am also interested in non-NFS tuning. 

For instance, "netstat -s" returns 70-85 lines of information. 
Which lines of information indicate a problem, and what are
the possible fixes?


I realize that values may have completely different meanings
depending on the purpose of the system. Still, I am interested in any
rules - even if for specific cases....

Some brief examples----

On a gateway:
tcp:
        599422 packets received
                4314 completely duplicate packets (1091342 bytes)
                1227 packets with some dup. data (47696 bytes duped)
                14930 out-of-order packets (6545338 bytes)
        5308 retransmit timeouts
                3 connections dropped by rexmit timeout


On another machine:
ip:
        2161667 total packets received
        18557 fragments received
        0 bad header checksums
        0 fragments dropped (dup or out of space)
        88 fragments dropped after timeout
        107713 packets not forwardable


There are many more possible errors. I wish I understood all of the
values - and what causes them, but I don't.

It would be a great service if these tidbits of information were
available somewhere. I'll volunteer to collect them, and will post a
summary.

--
Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1993 14:53:12 GMT
From:      Pearce Turpin <lanshark@llnl.gov>
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP - Novell - WAN from HELL!

Subject: Re: TCP/IP - Novell - WAN from HELL!


We now have a LANanyzer going, and noted activity locally, with a few
checksum errors. I'm really not sure why we would get those errors or
what would cause them; I'm relatively new to the TCP/IP arena, though I
know Netware well. 

I WANT to think that there is something wrong with the way the card's
TCP/IP is working, because everthing else works great. I mean, wouldn't
all TCP/IP packets bomb if there were a problem with the router? hmmm.

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Jul 1993 15:57:58 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Performance Testing

In article <RG.93Jul14085721@adams.camb-lads.loral.com>, rg@camb-lads.loral.com (Roger Gonzalez) writes:
> 
> I need to test the UDP performance (send, receive, and latency) on several
> different architectures.  I whipped out some programs that provided what
> seemed like unreasonably fast numbers.  I suspect this was due to me actually
> measuring nonuseful things like how long it takes for a process to wake up out
> of a sleeping select().  I could keep tweaking my programs, (and I would love
> some insight on what I should do to them) but I would prefer to use something
> already written.


There is always the pack of common TCP/IP benchmarks, including netperf,
ttcp, and nettest, source for all of which can be found on sgi.com.

UDP tests often yield ridiculously high numbers on the sender, because
the common BSD code discards UDP packets that overflow the driver
output queue.  You do get an ENOBUFS, and if you do as ttcp does and
delay an arbitrary, small time, you can tune your sender to overflow
the output queue only occassionally.

UDP tests often yield ridiculously low numbers on the receiver, if the
sender and medium are much faster than the receiver.  At the extreme
(which I have seen), the receiver effectively receives only a single
UDP packet, because the receiver gets so swamped processing input
interrupts and so forth that it suffers so many input overflows that it
ends up with only the first IP fragment of the first UDP packet and the
IP fragments of the last UDP packet.

People are strange.  I once had an major Ethernet board vendor try to
convince me that their VME board was really great because their UDP
benchmark had been able to write about 15Mbit/sec to the board.  They
were either too dumb to notice the ENOBUFS or thought I was too dumb to
be able to convert Bytes/sec to bits/sec, or (probably) both.


Vernon Schryver,  vjs@sgi.com

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Jul 1993 16:56:15 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP - Novell - WAN from HELL!

Pearce Turpin <lanshark@llnl.gov> writes: 

>We now have a LANanyzer going, and noted activity locally, with a few
>checksum errors. I'm really not sure why we would get those errors or
>what would cause them; I'm relatively new to the TCP/IP arena, though I
>know Netware well. 

The useful test is to set up the LANalyzer to filter all but packets
going to and from the NP600 card.

You do this by selecting the filter option (F6, I believe) when the
cursor is on one of the active channel's fields while in the edit display.
Once in the filter display, move the curser first to one ethernet address
field, type in the NP600's address, than to the arrow and hit the minus
key until a "<----->" pops up (as opposed to a "<----" or a "---->".  Make
sure the other ethernet address has all X's in it.  That will filter all
but packets going to or from the NP600's ethernet address.

>I WANT to think that there is something wrong with the way the card's
>TCP/IP is working, because everthing else works great. I mean, wouldn't
>all TCP/IP packets bomb if there were a problem with the router? hmmm.

No, I didn't say the problem was with the router itself.  I said it might
be with the special FTP TCP/IP software version for the NP600.  It has to
know the IP address of the default router or it (alone of all the devices
on that net) will not be able to interact with devices outside of the net -
which I believe is exactly the situtation you're describing.  You may not
have configured it correctly or perhaps you did but the software is not
working correctly, for some reason.

Fred

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1993 18:50:14 GMT
From:      kbw@helios.ath.epa.gov (Kevin B. Weinrich)
To:        comp.protocols.tcp-ip,comp.unix.admin,comp.sun.admin
Subject:   Re: SUMMARY: Sniffer programs

It seems space.mit.edu has gotten rid of their copies of etherman, et al.
Here's a place that works as of 930714 14:44 EST  ( ;-)
  pprg.eece.unm.edu:/pub/X

-- 
Kevin Weinrich     Computer Sciences Corp.
kbw@helios.ath.epa.gov

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 93 21:27:04 GMT
From:      tony@scotty.dccs.upenn.edu (Anthony Olejnik)
To:        comp.protocols.tcp-ip
Subject:   What's the better way to administer IP addresses to dorms?

This september, the first phase of our student dorm wiring
(to the campus IP/AppleTalk network) will be completed.

As such, we're looking for the better (best, ideally) way
to administer/assign IP addresses.

Should we:
	-statically assign them (one per network outlet)
	-statically assign them but use BOOTP
	-manually assign them (on an 'as-requested; basisc_
	-etc.

*ANY* help/comments would be *GREATLY* appreciated.
Thanks in advance.

--tony


-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 93 21:32:10 GMT
From:      sparker@oscar.UUCP (Sean Parker)
To:        comp.protocols.tcp-ip
Subject:   Best Modems for Slip and PPP


We are in the process of upgrading our modems here. Currently we are
looking into 14.4K modems. My question is what modems in this range
that people have used/evaluated using slip and/or PPP to unix machines running a variety of X-applications.  

Basically I would like to know which modems would be best suited for
this environment.

Could you e-mail responses to:

sparker@hns.com

Thanks!
Sean

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1993 21:41:45 GMT
From:      kumar@sloop.cis.ufl.edu (SHASHANK KUMAR)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip,comp.realtime,comp.sys.ibm.pc.hardware,comp.protocols.tcp-ip.ibmpc,comp.windows.x,comp.windows.x.apps,comp.windows.x.i386unix
Subject:   TCP/IP & Windows 3.1

Greetings Everyone,

I suppose Microsoft has recently released TCP/IP 4 WINDOWS ($50). I am not sure
if its for WFW or Windows 3.1. But I got this news from credible source that it
can be used for running Xwindows applications at remote site using a Third Party
software like WinQVT. Let me put the exact words,

        " X-server running over a Windows Sockets TCP/IP transport (which
          also supports WinQVT/Net and other TCP/IP applications)."

I would appreciate if someone who is actually using it, would enlighten me. I
would like to open multiple windows as I do right now for 'rlogin' using WinQVT.
Is it possible to run Xwindows applications in these windows by just
specifying the environment by the IP address (128.227.84.123:0.0) i.e.,
display terminal and address (iota fanciful). I have the experience of using
Desqview/X which I found notably competent for this purpose, but its Windows
support wasn't that immaculate.

Please send email:
kumar@coconut.cis.ufl.edu

/		Ever notice that even the busiest people are never 		/
/		too busy to tell you just how busy they are.			/






-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 93 23:17:05 GMT
From:      randy@psg.com (Randy Bush)
To:        comp.protocols.tcp-ip
Subject:   Re: What's the better way to administer IP addresses to dorms?

karl@genesis.MCS.COM (Karl Denninger) writes:
>> This september, the first phase of our student dorm wiring
>> (to the campus IP/AppleTalk network) will be completed.
> 1)	Implement a "anonymous IP bootp" extension which would assign an
> 	address from a random pool (after trying to "arp" it to see if its
> 	already in use) and return that.  This works well for people with
> 	MACs and PCs that don't have persistent connections (ie: they want
> 	to telnet or FTP out, but don't care about incoming connections)  
> 	I can't imagine that this kind of extension to bootpd would take 
> 	more than a day to implement and test.

Given the first derivative of security incidents, I might favor more sticky
and hence trackable IP address assignments.
--
randy@psg.com   ...!uunet!m2xenix!randy

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1993 23:59:09 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: What's the better way to administer IP addresses to dorms?

If you want your users get the most out of their computers, you must
have a permanent IP address per machine.  There are many reasons to do
this:

  - Greater accountability
  - Simplified debugging
  - Wider software compatibility
  - Hosts can act as servers as well as clients.

The last is perhaps the most important feature.  We have students
contacting each others machines directly all the time to transfer
files, chat online, or whatever.

If you want your PCs used solely as terminals, use dynamic assignment.
It will definitely reduce the paperwork involved!  On the other hand,
if you want the PCs to function as computers in their own right, give
them static addresses.

One definition: by "static address", I mean that the address doesn't
change across reboots.  This doesn't preclude use of BOOTP.  In fact,
BOOTP will really reduce the configuration headaches involved, since it
means all of your users can run identical, turnkey software.

       Stephen

-- 
Stephen Trier (trier@ins.cwru.edu - MIME OK)   
Network Software Engineer              
IRIS/INS/T                               
Case Western Reserve University             

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Jul 1993 00:45:35 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: What's the better way to administer IP addresses to dorms?

karl@genesis.MCS.COM (Karl Denninger) writes: 

>In article <136021@netnews.upenn.edu> tony@scotty.dccs.upenn.edu (Anthony Olejnik) writes:
>>This september, the first phase of our student dorm wiring
>>(to the campus IP/AppleTalk network) will be completed.
>>
>>As such, we're looking for the better (best, ideally) way
>For this kind of situation I would probably do two things:
>
>1)	Implement a "anonymous IP bootp" extension which would assign an
>	address from a random pool (after trying to "arp" it to see if its
>	already in use) and return that.  This works well for people with
>	MACs and PCs that don't have persistent connections (ie: they want
>	to telnet or FTP out, but don't care about incoming connections)  
>	I can't imagine that this kind of extension to bootpd would take 
>	more than a day to implement and test.

Not unless you really LIKE trouble.  What if a student unplugs his PC and
then plugs it back in later, with rebooting?  (Or is running an application
which is making it impossible or very slow to respond to an arp.)  What if
the IP address assigner doesn't see the response - icmp packets aren't
guaranteed delivery, ya know.

An interesting though but too, too many flaws and the potential for problems
just isn't worth it.  You don't want PCs running around your net spoofing
other PCs.

Fred

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Jul 1993 02:39:07 GMT
From:      kleung@netcom.com (Kenneth Leung)
To:        comp.protocols.tcp-ip
Subject:   Re: AS/400 connectivity ?

Connecting Unix workstation to AS/400 can be done with the following :

AS/400 based TCP/IP is available, check with IBM rep

SNA connectivity for Unix from vendors such as Cleo, System Strategies
and Rabbit Software

Use a DOS box in between with AS/400 PC Support+TCP/IP

Anyone got anything suggestions?


Kenneth C.P. Leung      1303 Walnut Hill Ln. 2nd Floor, Irving, TX 75038 
Information Specialist  Voice : 214-550-8371 Fax : 214-550-9269
Innovax Concepts Corp.  AURORA Supermarket Application
                        Innovax Integration Partner Program
-- 
Kenneth C.P. Leung      1303 Walnut Hill Ln. 2nd Floor, Irving, TX 75038 
Information Specialist  Voice : 214-550-8371 Fax : 214-550-9269
Innovax Concepts Corp.  AURORA Supermarket Application
                        Innovax Integration Partner Program

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Jul 1993 02:49:17 GMT
From:      scott@zmax.com (Scott Wallace)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   Sigpipe on AIX blocked socket read

Greetings Netters,

Sorry if this is a faq, but I'm stuck on this one. I have a socket-based
server which blocks on a read on a socket under AIX 3.2 on a RS6000/320.
A client frequently sends data packets to this server, but should the
client die (network crash or whatever) I need the server to know about this
and exit. (it's forked from an accept).

Currently, if the client dies, the server see's nothing.  The blocked read
on the socket doesn't return -1, and also, a SIGPIPE is not generated
to the server process. 

I've tried messing with setsockopt with SO_KEEPALIVE etc... with no
success.

Does anyone have any idea how to get around this?
(P.S. The exact same code works on DEC).

Please email responses since I don't regularly get this group.

Thanks in advance,

Scott
scott@zmax.com
Z/Max Computer Solutions Inc.
Baldwinsville NY 13027



-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Jul 1993 05:06:55 GMT
From:      aidan@vast.unsw.edu.au (aidan)
To:        comp.protocols.tcp-ip,comp.unix.admin,comp.sun.admin
Subject:   netman etc.. (Was: Re: SUMMARY: Sniffer programs)

kbw@helios.ath.epa.gov (Kevin B. Weinrich) writes:
: It seems space.mit.edu has gotten rid of their copies of etherman, et al.
: Here's a place that works as of 930714 14:44 EST  ( ;-)
:   pprg.eece.unm.edu:/pub/X
: 
: -- 
: Kevin Weinrich     Computer Sciences Corp.
: kbw@helios.ath.epa.gov

Here is a copy of the original posting which gives you the official
distribution site.

regards
	aidan
____
:wq!	aidan@cse.unsw.edu.au     OR     aidan@vast.unsw.edu.au

---README----------------------------------------------------------------------

	Network monitoring and visualisation tools		13th April 1993
	netman@cs.curtin.edu.au


Overview:

    We have developed a set of tools (3) which may be used to monitor and
"display" network communications.  Two of the tools provide a real-time
picture of network communications, while the other provides retrospective
packet analysis.  These tools are designed to allow network managers to 
passively monitor a network and diagnose common network problems as quickly
and efficiently as possible.

The tools:

    Etherman is an X11 based tool which displays a representation of real-time
Ethernet communications.  Network data is promiscously received via a system
"network tap" and summarised into useful statistics.  These statistics are
displayed in a graphical manner, as to allow both experienced network managers
and newbies an insight as to how a network is being used.  Etherman will also
provide protocol summaries, usage statistics and postscript(tm) snapshots of
network activity.

    Interman focusses on IP connectivity within a single segment.  As with
Etherman, this tool allows a real-time representation of network communications
to be displayed.  Interman employs the same methods of network data
capture as Etherman, except only IP traffic is considered.  Since IP is a
network-level protocol, Interman will display multiple networks - both local
and remote.  Protocol summaries, usage statistics and postscript snapshots
are also available.

    Packetman is a retrospective Ethernet packet analyser.  This tool allows
the capture and analysis of an Ethernet packet trace.


Availability:

    At present, only binaries for SUN Sparc (SunOS 4.1.x) and DEC-mips
(Ultrix 4.2a and above) are avaliable.  Each tool must be run as root.

	ftp.cs.curtin.edu.au:
	~ftp/pub/netman/[sun4c|dec-mips]/[etherman|interman|packetman].tar.Z

You will also need:

	~ftp/pub/netman/hershey-[sun4c|dec-mips].tar.Z

--
Mike Schulze, Craig Farrell and George Benko.
Department of Computer Science
Curtin University
Perth, West Australia

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Jul 1993 10:42:42
From:      djmiller@newsserver.tasc.com  (Dean J. Miller)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP - Novell - WAN from HELL!

In article <21vcuo$si7@lll-winken.llnl.gov> Pearce Turpin <lanshark@llnl.gov> writes:

	>>I will buy dinner for the person who solves this one. 5 LAN's connected
	>>via a T1 WAN with a UNIX host on one of the LAN's. We have a proprietary
	>>app that needs Racal/Interlan NP600 'smart' NIC's running their own
	>>version of FTP's PC/TCP designed for the NP600. The routers are Netware
	>>3.11-based with 3C509 LAN NIC's and Novell's Multi-protocol Router boards
	>>on the WAN side. Our addresses are all class 'C'. We have no subnets.
	>>Everything works fine, except when we try to use the NP600 based PC's. I
	>>cannot ping anything outside my own net. I can ping the NIC on the LAN
	>>side of the router, because it's on the same net. Now, if I use LWP ODI
	>>drivers, everything works perfectly. The same with FTP's PC/TCP ver 2.2
	>>and the UNIX host. The only thing that dosn't work is the PC's with the
	>>NP600. I'm assuming either:
	>>
	>>a. The router is not seeing packets sent by that particular board for
	>>what ever reason.
	>>or
	>>b. The boards are not compatible with SOMETHING, even though I've
	>>isolated everything
	>>and they work locally.
	>>
	>>I think it's (a), but  I can't, for the life of me, figure out why. The
	>>server is set up to receive any size packet, and everything else wroks
	>>just fine.
	>>
	>>Any of all input appreciated, and I'm serious about the dinner.......

This may be a long shot, but have you tried swapping out the 3C509 boards on
your Novell Router (or at least the one that is on the same ethernet segment
as the NP-600s) with a non-3Com board?  We have had anomalous behavior in the
past with PCs using 3Com cards that has been unexplainable. 

--
dean
====================
Dean J. Miller
TASC
(617)942-2000 x2769
djmiller@tasc.com


-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 93 11:45:58 GMT
From:      rens@stimpys.imsi.com (Rens Troost)
To:        comp.protocols.tcp-ip
Subject:   Re: KEEPALIVE option for tcp sockets


Slightly off the thread, but to the point, here's how to change the
keepalive timeout (on a sun, or in fact any 4.3 derivative)

timeout value = timeout_in_seconds * PR_SLOWHZ (from sys/protosw.h, usually 2)

adb -w -k  /vmunix /dev/mem << EOF
tcp_keepidle?W {timeout value}
EOF

reboot

And, alas, select will not return unaided. Use jordan's method.

-Rens
--
  o===============================================================o
  | J. Laurens Troost - UNIX Systems  | At Work: rens@imsi.com    |
  | Investment Management Svcs, Inc.  | At Play: rens@century.com |
  | 12 East 49th Street,  35th floor  |   Phone: (212) 339-2823   |
  | New York, New York         10017  |     Fax: (212) 339-2854   |
  o===============================================================o
     -- IMS is unlikely to share any of the above opinions --

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 93 17:21:33
From:      shirono@ssd.csd.harris.com (Roberto Shironoshita)
To:        comp.protocols.tcp-ip
Subject:   Need info on terminal servers

We are currently contemplating the purchase of a TCP/IP terminal server to
be used as incoming server for high-speed dialup lines.

The server we have in mind is the PortMaster2 Communications Server, from
Livingston Enterprises, Inc.

Any comments on these servers (or any others) would be appreciated,
especially as far as their security capabilities.  The blurb we have from
Livingston says that their servers do dialback, have local passwords,
provide packet and access filters, and implement an authentication
protocol.  The authentication server source, the blurb says, is made
available without use restrictions.

Please reply by email.  If there is interest, I will post a summary of any
responses I receive.  If there is some other newsgroup where this article
would be better sent, please let me know.

Thank you.
--

     Roberto Shironoshita      ||   Internet: shirono@ssd.csd.harris.com
      Harris Corporation       ||
   Computer Systems Division   ||   UUCP: ...!uunet!ssd.csd.harris.com!shirono
                               ||
DISCLAIMER: The opinions expressed here are my own; they in no way reflect the
            opinion or policies of Harris Corporation.

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 1993 13:08:10 GMT
From:      nprobert@fires1.uucp (Neal Probert)
To:        comp.protocols.tcp-ip
Subject:   Looking for Ethernet, Tcp/Ip, SNMP tools for UNIX ?

I am looking for PD UNIX tools for sniffing and analyzing networks.  This
includes Ethernet, tcp/ip, SNMP and NFS.  What are the names of these
packages and where can I find them. (I can use archie to find them).

Thanks.
-- 
-------------------------------------------------------------------------------
    FORD       | Neal W. Probert   E3154 SRL    | nprobert@fires1.srl.ford.com
 SCIENTIFIC    | Ford Scientific Research Labs  | 313-845-8178 FAX 313-845-8202
RESEARCH LABS  | Dearborn, MI 48121-2053        | Disclaimer: I'm innocent!

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 1993 14:12:46 GMT
From:      roy@mchip00.med.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: What's the better way to administer IP addresses to dorms?

	I admittedly have limited experience with this kind of stuff, but in
the one situation where I ran a dynamically allocated IP address pool, it
was a bunch of localtalk Macs behind a FastPath.  The theory is that a pool
will allow you to reduce the number of address you have to allocate.  In
practice, however, I found that most people tended to keep some IP
application up all the time (usually email), so I ended up having to
allocate about as many addresses as we had machines anyway.
-- 
Roy Smith <roy@nyu.edu>
Hippocrates Project, Department of Microbiology, Coles 202
NYU School of Medicine, 550 First Avenue, New York, NY 10016
"This never happened to Bart Simpson."

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 1993 15:09:27 GMT
From:      Pearce Turpin <lanshark@llnl.gov>
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP - Novell - WAN from HELL!

Re: TCP/IP - Novell - WAN from HELL!


LANalyzer results: Can I get an interpretation? 

Test1 - Capture packets from initial PING to router LAN card with LWP ODI
drivers (theses work on the card): an ARP packet, followed by the ICMP,
then the returning ICMP.

Test 2 - Now I use the drivers that come with the board (the ones that
DON'T work): I get an ICMP FOLLOWED by an ARP, then the returning ICMP.

Is this an indicator of the problem?? 



I heard the another site has been able to duplicate the problem with a
different router, but that has yet to be confirmed.

Pearce Turpin

(w) lanshark@llnl.gov
(h)  lanshark@bohunk.win.net

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Jul 1993 17:56:07 GMT
From:      tozz@hpindda.cup.hp.com (Bob Tausworthe)
To:        comp.protocols.tcp-ip
Subject:   Portable SNMP & TCP/IP for 8051

I have a friend at a local telecomm company who is looking for a portable
version of SNMP and TCP/IP for an 8051 controller. This implementation
would be communicating over a serial line. Since it is an 8051 it will in
all likelyhood need to be ROM-able.

Please send all correspondence to:

sftcom@infoserv.com

BTW - they are willing to pay! for the code. 

			 tozz@cup.hp.com

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 93 19:24:29 GMT
From:      karthik@informix.com (Karthikeyan Guruswamy)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP - Novell - WAN from HELL!

In article <21vcuo$si7@lll-winken.llnl.gov> lanshark@llnl.gov (Pearce Turpin) writes:
>I will buy dinner for the person who solves this one. 5 LAN's connected
>via a T1 WAN with a UNIX host on one of the LAN's. We have a proprietary
>app that needs Racal/Interlan NP600 'smart' NIC's running their own
>version of FTP's PC/TCP designed for the NP600. The routers are Netware
>3.11-based with 3C509 LAN NIC's and Novell's Multi-protocol Router boards
>on the WAN side. Our addresses are all class 'C'. We have no subnets.
>Everything works fine, except when we try to use the NP600 based PC's. I
>cannot ping anything outside my own net. I can ping the NIC on the LAN
>side of the router, because it's on the same net. Now, if I use LWP ODI
>drivers, everything works perfectly. The same with FTP's PC/TCP ver 2.2
>and the UNIX host. The only thing that dosn't work is the PC's with the
>NP600. I'm assuming either:
>
>a. The router is not seeing packets sent by that particular board for
>what ever reason.
>or
>b. The boards are not compatible with SOMETHING, even though I've
>isolated everything
>and they work locally.
>
>I think it's (a), but  I can't, for the life of me, figure out why. The
>server is set up to receive any size packet, and everything else wroks
>just fine.
>
>Any of all input appreciated, and I'm serious about the dinner.......

First  things first - What Frame Type are you using in the NP-600 PC ?
                              
Karthik
P.S: I like Pan Fried Pizza with extra cheese, mushrooms and pineapple
;-y
 
---------------------------------------------------------------
Karthik						
Infosoft Inc, (Contractor to INFORMIX Inc.)
Cupertino, CA

' Its not how FAR you go, but how GO you far ... '

All the views expressed here are solely mine and they dont 
represent those of my organization.
---------------------------------------------------------------

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Jul 1993 19:44:51 GMT
From:      mgic <mgic@mixcom.mixcom.com>
To:        comp.protocols.tcp-ip
Subject:   Mysterious RPC failure.


I am having a strange problem with an RPC client that sometimes fails on
the clnt_call() call.  It fails with a return code of 4 which is 
RPC_CANTRECV (RPC client unable to receive result).  

All the RPC server does is generate a postscript document from a text file,
convert it to fax format, and fax it out.  This involves a couple of system
calls which all return successfully.  
Would a SIGCLD in the server somehow cause this behavior?

This happens on a Sun Sparcstation 10.  The rpc code was generated via rpcgen.
Any pointers will be greatly appreciated.

Thanks
Anand Prahlad
mgic@mixcom.com
-- 

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 93 19:50:18 GMT
From:      matt@calico.math.binghamton.edu (Matt Brin)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin,comp.unix.admin,comp.unix.wizards
Subject:   glacial file transfers

This is a copy of a post that I put out before.  I have
a little more information.  It is quite bizzare.

Start of former post.

We are having trouble transfering files.

We are a subnet in a university with a sun acting as a gateway
to the rest of the university.  We recently split our subnet
into two and added a bit to our netmask on our side of the gateway.
Thus we have a second gateway into our inner part of our lan.
Eerything works fine (e.g., reading net news, which is done through
our gateway).  We have our interfaces configured correctly and
everything seems to be able to communicate with everything else.
rlogin, ping, mail, and so forth work just fine.

EXCEPT: some file transfers that either originate from or go
through our outer gateway (the old one) come to almost a halt after
about 20 or 30 kilobytes have been transfered.  This happens with
ftp, rcp and tftp.  There are no network storms going on.  Watching
etherfind shows nothing suspicious except a marked lack of activity 
regarding the file transfers.  Sometimes if you wait long enough, an
extra packet or two gets through.  The word "some" adds to the puzzle.
A file transfer from within our lan to within a lan elsewhere on campus
goes fine.  This transfer involves two gateways - one on each lan.
A file transfer from within the second part of our lan (three
gateways involved) bogs down after some 10s of kilobytes.  A 
transfer from the main net on campus to the first part of our lan (only
one gateway involved) bogs down.  All of these transfers use our main
gateway.  A transfer from our gateway to within the outer part of our lan
(direct transfer on our ethernet - no routing at all) bogs down.

Any hints wil be apreciated.

End of former post.

I now have more information that I cannot account for in any way.

I have run snoop on a third machine while running the transfer
between two machines that bog down.  After the transfer is 
initiated, packets flow between the machines at about 10 per
hundreth of a second.  This included repeated packets (many are 
repeated once - a few twice).  After about a tenth of a second, 
there is a one second delay, then a two second delay, then a four
second delay, then (you guessed it) an eight second delay, then 16, 
then 32 (I am not making this up), then 64, then a packet goes
out evey 64 seconds.  This went on for about 5 more transmissions
before I killed the process.
_____________________________________________________________________________
matt brin / math. dept / SUNY / Binghamton, NY 13902-6000 / (607)-777-2147
matt@math.binghamton.edu      	INTERNET
mbrin@bingvaxa			BITNET
-----------------------------------------------------------------------------

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Jul 1993 20:28:39 GMT
From:      maass@orchis.enet.dec.com (Joerg Maass)
To:        comp.protocols.tcp-ip,comp.networks.noctools.wanted
Subject:   Re: Request for tools/test suites for IP routers


In article <C9v5Gv.9xv@apollo.hp.com>, tmm@apollo.HP.COM (Thomas M. Mistretta) writes:

Could anyone recommend any tools or suites to test and validate the operation
of an IP router?  Specifically, we would like to examine fragmentation,
IP option handling, ICMP, etc., in addition to various routing protocols like
RIP, OSPF, and HELLO.  Realistically - at a minimum - we would like to see
testing of the guidelines set forth in RFC-1009: "Requirements for Internet
Gateways."  Any response would be appreciated.

Thanks.
Tom Mistretta                         tmm@apollo.hp.com

-- 

How about HP OpenView? As far as I know, it is specialized on TCP/IP networks
(SNMP) and should be capable of providing such information (as far as it is
retrievable from the router or end system).

If not, send me a mail :-).


Cheers



Joerg Maass


Network Management Specialist

Digital Equipment GmbH                Tel.: +49/6103/383-107
Robert-Bosch-Str. 5                   Fax : +49/6103/383-157
D-63303 Dreieich-Sprendlingen         Joerg.Maass@frs.mts.dec.com


-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 1993 20:39:14 GMT
From:      Pearce Turpin <lanshark@llnl.gov>
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP - Novell - WAN from HELL!

Re: TCP/IP - Novell - WAN from HELL!

ETHERNET_II


---Another tangent: Encapsulation. How does this fit in? Someone said
Netware requires it, but the NP doesn't do it. Is this true?? Holy cow!

Pearce Turpin

(W)lanshark@llnl.gov 
(H) lanshark@bohunk.win.net

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 93 21:24:51 GMT
From:      sazi@badlands.bellcore.com (Sazi Temel)
To:        comp.protocols.tcp-ip
Subject:   pSOS/pNA  RARP ???



Does anyone know if there exist a RARP implementation for pNA/pSOS
running on a 68x0 CPU ?

Please respond to pbs@badlands.bellcore.com 

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Jul 1993 20:53:00 +0100
From:      hugo@rusthoff.hacktic.nl (Hugo van.der.Kooij)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP - Novell - WAN from HELL!

 > From: Pearce Turpin <lanshark@llnl.gov>
 > Organization: Lawrence Livermore National Lab
 
 > I will buy dinner for the person who solves this one.
 > 5 LAN's connected
 > via a T1 WAN with a UNIX host on one of the LAN's. We
 > have a proprietary
 > app that needs Racal/Interlan NP600 'smart' NIC's
 > running their own
 > version of FTP's PC/TCP designed for the NP600. The
 > routers are Netware

Some suggestions for the NP600 board.

 a) Try to debug the download code for the board. The board is handling IP.

 b) You might have to specify the IP router for any non-local network. I have seen a TCP server using this card that had to be taught each network besides it's own and which router was to forward. If you 're using SCO with special Racal software this answers your question.

 > 3.11-based with 3C509 LAN NIC's and Novell's Multi-
 > protocol Router boards
 > on the WAN side. Our addresses are all class 'C'. We
 > have no subnets.
 > Everything works fine, except when we try to use the
 > NP600 based PC's. I
 > cannot ping anything outside my own net. I can ping
 > the NIC on the LAN
 > side of the router, because it's on the same net. Now,
 > if I use LWP ODI
 > drivers, everything works perfectly. The same with
 > FTP's PC/TCP ver 2.2
 > and the UNIX host. The only thing that dosn't work is
 > the PC's with the
 > NP600. I'm assuming either:
 
 > a. The router is not seeing packets sent by that
 > particular board for
 > what ever reason.
 > or
 > b. The boards are not compatible with SOMETHING, even
 > though I've
 > isolated everything
 > and they work locally.
 
 > I think it's (a), but  I can't, for the life of me,
 > figure out why. The
 > server is set up to receive any size packet, and
 > everything else wroks
 > just fine.
 
 > Any of all input appreciated, and I'm serious about
 > the dinner.......

You might indeed owe me one. Send me a private message and I will drop in whenever I come in your area. I admit I have the avantage of doing networks for four years with Racal.

 > ---
 >  * Origin: Rust-Hoff is using a Private UUCP <==> FIDO
 > gateway (2:512/32.23)

 * Origin: Rust-Hoff; Home of the Brave. (2:512/32.23)

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Jul 1993 23:12:55 GMT
From:      leanne@netmanage.com
To:        comp.protocols.tcp-ip
Subject:   Re: X-Window over phone line?


In article <1993Jul7.183018.1854@wsuhub.uc.twsu.edu>, 
<kodagali@wsuhub.uc.twsu.edu> writes:
> Path: 
netman-gate!uunet!news.cnri.reston.va.us!newsserver.jvnc.net!howland.reston.ans
net!wupost!kuhub.cc.ukans.edu!wsuhub.uc.twsu.edu!kodagali
> Newsgroups: comp.protocols.tcp-ip
> Subject: X-Window over phone line?
> Message-ID: <1993Jul7.183018.1854@wsuhub.uc.twsu.edu>
> From: kodagali@wsuhub.uc.twsu.edu
> Date: 7 Jul 93 18:30:18 CST
> Organization: Wichita State University, Wichita, Ks
> Lines: 14
> 
> Hi,
> 
> I have a Sparc 2 at my workplace running SunOS 4.1.3 and Openwin 3.0. It
> is on an ethernet running TCP/IP. It also has a TELEBIT Worldblazer
> modem for dialing in. I have a PC at home which I would like to connect
> to the Sparc through the phone line so that I can run X-Window
> progs on the Sparc and display them on the PC. I have DesqView/X to
> convert the PC into X-terminal. I have a modem on the PC. Is this
> possible ?
> 
> Thanks for your time.
> ----------------------------------------------------------
> Email: kodagali@wsuhub.uc.twsu.edu

NetManage has a X Windows product called XSession that would 
solve the problem you have described.  There is a module called XRemote
that compresses the X protocol over phone lines.  PPP and Slip are also 
supported although they aren't rec. for X.  For more information email to 
netmanage.com. or call (408) 973-7171.

Leanne
leanne@netmanage.com

> 


-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Jul 1993 03:07:44 GMT
From:      chiang@iti.gov.sg (Chiang Kuo Chiang (IIRS))
To:        comp.protocols.tcp-ip
Subject:   changing seg & win size in UNIX?

(I'm asking this for a friend)
Is there a way to change the segment size and window size of TCP in unix?
Thanks!
---

  +-------+   --+ +---+
  | --+-- |     | |___|
  |   |   |   +-+ +-|-+
 -+-  |   |   | | |
  |   | \ |   +-+ +-|-+
  | --+-- |     |   |
  +-------+    \| --+-\
  Kuo Chiang, Chiang

---------