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

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Jul 1993 05:26:57 GMT
From:      greg@serveme.chi.il.us (Gregory Gulik)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   LOOKING FOR: Simple socket program.


Has anyone written a simple socket based program does does
the following?:

- Connect to socket on remote node to specified port

- Establishes 8-bit clean connection.

- Transfers characters back and forth between both ends of socket.

Please let me know if you have such a program already.
Thanks.

-greg

-- 
Gregory A. Gulik                                 Call Gagme, a public access
       greg@serveme.chi.il.us                    UNIX system at 312-282-8606
   ||  gulik@rtsg.mot.com                        For information, drop a note
                                                 to info@gagme.chi.il.us

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Jul 1993 06:47:25 GMT
From:      js@kreutler.de (Juergen Stieber)
To:        comp.protocols.tcp-ip,comp.unix.solaris,comp.sys.sun.apps,comp.sys.sun.misc
Subject:   SLIP for Solaris 1.1: A few questions

Hi all,

I'm running Solaris 1.1 (SunOS 4.1.3) on a SPARCstation IPX and I
have a few questions concerning SLIP:
1) Is SLIP already installed / delivered with Solaris 1.1?
   If no, how can I get and install it?
2) How can I use the SLIP connection, i.e. how can I run an
   application over my SLIP connection (e.g. a X client on
   one side and the X server on the other side of the SLIP connection)?
3) How can I make a SPARCstation a SLIP gateway? (or another machine,
   if there is no difference on principle)

I hope my questions aren't too general, but I'm rather new to
TCP/IP subjects, especially SLIP.

Any hints are greatly appreciated. Please answer by e-mail, because
I don't read this News groups regularly.

Thanks in advance

Juergen Stieber
-- 
 Juergen Stieber                        Phone: +49 721 8508-86
 KREUTLER GmbH                          Fax:   +49 721 8508-71
 P.O.B. 3744
 76022 Karlsruhe 1,    Germany          Mail:  js@kreutler.de

-- 
 Juergen Stieber                        Phone: +49 721 8508-86
 KREUTLER GmbH                          Fax:   +49 721 8508-71
 P.O.B. 3744
 76022 Karlsruhe 1,    Germany          Mail:  js@kreutler.de

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 93 16:02:28 +0930
From:      sherwood@dstos3.dsto.gov.au
To:        comp.protocols.tcp-ip
Subject:   PEASE HELP me with SLIP !!!


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

  Hello,

        My name is Kevin Sherwood and I work for DSTO at Salisbury, South
  Australia. I am presently trying to configure SLIP on a Cisco CS500
  terminal server which has dial-in modem access. So far I have set up a
  test port on one of the dial-in lines and included the SLIP commands -

  slip routing
  slip address dynamic xxx.xxx.xxx.xxx

  Can anyone please confirm this approach or add any more details as I am
  in the dark. I would also appreciate some help in using the slip8250
  driver in conjunction with cutcp.

  Thanks in advance.

--------------------------------------------------------------------------------
  Kevin Mark Sherwood
Information Technology Services              E-mail: sherwood@scm.dsto.gov.au
Corporate Information Systems Unit      Message Pgr: +61 8 378 1111 (112753)
Defence Science & Technology Organisation     Phone: +61 8 259 5715
PO Box 1500, Salisbury, 5108, Australia         Fax: +61 8 259 5537
--------------------------------------------------------------------------------

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Jul 1993 07:32:40 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 <742578124@romeo.cs.duke.edu> trt@duke.cs.duke.edu (Tom Truscott) writes:
>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.

I don't think ones complement machines were ever "popular", they just
existed and were accounted for.  If you're going to take one number
out of a range of numbers to be a special case, all bits zero is the
obvious choice.  I wasn't there, but i doubt anyone ever gave any
thought at all as to whether that would naturally be the result of a
standard checksum calculation on any type of machine.  (In fact, it
wouldn't surprise me to learn that they decided on zero to mean "no
checksum" before they decided on a checksum algorithm...)

>If five years from now the industry has settled on little-endian,
>won't the TCP/IP "network order" look like a terrible mistake?

I seriously doubt it.  I don't know of *any* network protocol that
doesn't transmit multiple octet values high order octet first.  If CPU
architectures which store multiple byte values with the low order byte
first do, in fact, "win out", it'll just mean that network order and
memory order will forever be different.
						don provan
						donp@novell.com

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Jul 93 12:45:17 GMT
From:      chiltj@ois.com (Jeff CHILTON)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve or MCI from internet

From the MCI-Mail help system:

| There are three ways an MCI Mail
| subscriber may be addressed from
| the Internet.  Either by their
|
| 1. Unique 7 digit MCI ID
|    followed by @MCIMail.com
| 2. MCI Mail Username followed
|    by @MCIMail.com
| 3. Formal name as registered on
|    MCI Mail followed by @MCIMail.com
|
| For example, John Morris could be
| addressed the following ways:
|
| To: 248-3894@MCIMail.com  (MCI ID)
| To: JMorris@MCIMail.com   (MCI Username)
| To: John_Morris@MCIMail.com  (MCI Mail
| formal name.  Note that underscore is
| required.  Blank spaces not allowed.)
|
| To guarantee delivery, the MCI ID is
| the most reliable addressing format.
| It should be used when the Username
| or Formal name are common.

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 1993 11:08:42 +0200
From:      szymon@galaxy.uci.agh.edu.pl (Szymon Sokol)
To:        comp.protocols.tcp-ip
Subject:   Re: What's the better way to administer IP addresses to dorms?

Frederick Scott (fred_s@netcom.com) wrote:

: 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.

I wonder how do you want to prevent it... Most Ethernet adapters can spoof
*hardware* (i.e., MAC-level) addresses, and BOOTP (as well as RARP) uses 
MAC address to determine IP address. IMHO, you can do nothing about it.
Nevertheless, I would go for static address assignment - at least, it is harder
to spoof.
-- 
U     U  M     M  M     M  Szymon Sokol -- Network Manager
U     U  MM   MM  MM   MM  University of Mining and Metallurgy, Computer Center
U     U  M M M M  M M M M  ave. Mickiewicza 30, 30-059 Krakow, POLAND
 UUUUU   M  M  M  M  M  M  TEL. +48 12 338100 EXT. 2885    FAX +48 12 338907

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Jul 1993 14:48:21 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.

}>If five years from now the industry has settled on little-endian,
}>won't the TCP/IP "network order" look like a terrible mistake?

donp@novell.com (don provan) writes:
}I seriously doubt it.  I don't know of *any* network protocol that
}doesn't transmit multiple octet values high order octet first.  If CPU
}architectures which store multiple byte values with the low order byte
}first do, in fact, "win out", it'll just mean that network order and
}memory order will forever be different.

   Why?  If we have to seriously `dink' with a network protocol
   for other reasons (IP:`the next generation' comes to mind),
   then why shouldn't we consider changing `network byte order'?
   (other than entrenched big-endian-ism)

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

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Jul 1993 14:52:05 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.

 donp@novell.com (don provan) writes:
> trt@duke.cs.duke.edu (Tom Truscott) writes:
>
>>If five years from now the industry has settled on little-endian,
>>won't the TCP/IP "network order" look like a terrible mistake?

It was an arbitrary choice, but I'm glad it was standardized and
not left up to negotiation.

As for little endian machines, conversion is becoming trivial.
The i486 processor added a BSWAP instruction which switches
endians in one clock cycle.  

Erick
-- 


-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 1993 15:16:35 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?

szymon@galaxy.uci.agh.edu.pl (Szymon Sokol) writes:
> I wonder how do you want to prevent it... Most Ethernet adapters can spoof
> *hardware* (i.e., MAC-level) addresses, and BOOTP (as well as RARP) uses 
> MAC address to determine IP address. IMHO, you can do nothing about it.

	Most ethernet adapters that I know of have their MAC address in rom
(eprom, more likely).  I suppose there might be some fancy way, if you know
how to program, to change the address via software, but not too many people
know how to do that.  On the other hand, anybody can just go into whatever
IP setup program they have and change the IP address.  We had a guy a while
ago running Sun's PC/NFS on his PC who set his maching to have the same IP
address as one of our main file servers.  What fun.  (I don't mean to imply
it was PC/NFS's fault; the same thing could have happend with anybody else's
package just as easily).

	Anyway, to answer your second question, there are hubs that can
enforce MAC-level security.  We're putting in some ODS hubs here.  The
10baseT cards can be programmed to only allow packets to/from a single
ethernet address on each port (essentially per-port fascist bridging).  If
you wired your dorm up with hubs like that, you could require that students
register the ether address of any object they want to plug in and program
the hub to only allow that address on that port.  Overkill, perhaps (not to
mention that these boxes aren't cheap), but possible.
-- 
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."

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 1993 16:50:53 GMT
From:      kerch@reynaldo.PARC.Xerox.Com (Berry Kercheval)
To:        comp.protocols.tcp-ip
Subject:   Re: What's the better way to administer IP addresses to dorms?

In article <226goj$kgf@calvin.NYU.EDU> roy@mchip00.med.nyu.edu (Roy Smith) writes:
   szymon@galaxy.uci.agh.edu.pl (Szymon Sokol) writes:
   > I wonder how do you want to prevent it... Most Ethernet adapters can spoof
   > *hardware* (i.e., MAC-level) addresses, and BOOTP (as well as RARP) uses 
   > MAC address to determine IP address. IMHO, you can do nothing about it.

	   Most ethernet adapters that I know of have their MAC address in rom
   (eprom, more likely).  I suppose there might be some fancy way, if you know
   how to program, to change the address via software, but not too many people
   know how to do that. 

A lot (I won't say most) of ethernet adapters copy the MAC address
from the prom into a register, or scratch ram, or something, on
startup.  There is often a command to set this register (or whatever
it is) to whatever you like.  I remember seeing this as far back as
3com's original Unibus ethernet device (On TWO big 6-high cards!
Woof!).

  --berry

--
Berry Kercheval :: kerch@parc.xerox.com 


-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Jul 1993 17:18:02 GMT
From:      schoenw@ibr.cs.tu-bs.de (Juergen Schoenwaelder)
To:        comp.lang.tcl,comp.unix.admin,comp.protocols.tcp-ip,comp.protocols.snmp
Subject:   first public release of tkined and scotty available for ftp


The first public release of our network editor INED is now available
from ftp.ibr.cs.tu-bs.de [134.169.34.15] in /ibr/pub/local/tkined-0.4.tar.Z.
tkined is a tcl/tk based re-implementation of the original INED editor
described in a paper presented at SANS II, April 1993. The PostScript
version of this paper can be found on ftp.ibr.cs.tu-bs.de in the file
/pub/ibr/local/papers/ined.ps.Z.


So what is tkined?

tkined is a drawing program that allows you to produce maps of your
network configuration. But the most important feature of tkined is
its programming interface that can be used to turn the editor into a
network management system. tkined provides commands to present status
information in stripcharts, barcharts or as piecharts.


And what about scotty?

scotty is a tcl interpreter that has extensions to set up tcp
connections, to submit ping packets and to query various RPC services.
There are some sample scripts for troubleshooting your network
(ping, traceroute, finger, query tcp services, query rpc services),
for monitoring network status and for layouting your IP network map.

scotty is available from ftp.ibr.cs.tu-bs.de [134.169.34.15] in
/ibr/pub/local/scotty-0.5.tar.Z. To use scotty together with tkined
you need a wish with the addinput patch available from the
tcl contrib server harbor.ecn.purdue.edu.


Where do I report bugs and suggestions?

If you have problems or if you have made any changes to run tkined and
scotty on your hardware or if you have found any serious bugs, please 
contact us. We may be reached under the email address
netman@ibr.cs.tu-bs.de.

We would also like to collect icons for all kinds of machines. If you
make new icons and if you are willing to share them with us, please
drop us a note (and the icons :-).

Have fun with tkined and scotty!
						Juergen


-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 93 17:24:24 GMT
From:      karthik@informix.com (Karthikeyan Guruswamy)
To:        comp.protocols.tcp-ip
Subject:   TCP: WAN from Hell !

Hi,
ETHERNET_II ? Okay - sounds good. Now, you said you can ping to all
the PCs on the same LAN, I assume you can ping to the Novell Server
with the MultiProtocol Router Board too ... Can you do it ? If you
can, you must make sure the Default Gateway is set to the Novell 
server's IP on the NP-600. When you ping for the distant  LAN,
you might want to watch the ICMP statistics going up on the 
TCPCON on file server console. What happens can you say ?

Karthik   
---------------------------------------------------------------
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.
---------------------------------------------------------------

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 93 12:30:37 +0300
From:      viljo@ebc.ee (Viljo Soo)
To:        comp.protocols.tcp-ip
Subject:   Re: Can I use TCP/IP over satellite links?

Rogelio Montanana (MONTANAN at EVALUN11) (MONTANAN@EVALUN11.BITNET) wrote:
> 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.

We use satellite link to connect our network in Tartu, Estonia to
Internet via KTH, Stockholm, Sweden. Yes, there is some delay on
sending and receiving packets. It depends on distance between Earth
and satellite. We use satellite TELE-X and it is located on distance
about 30,000 km. Each packet passes this distance twice. So the delay
caused by the satellite link itself is 200ms. Actually, the delay is
about 280-290ms due to additional time spended in hardware. Minimum
response time for ping over our satellite link is 572ms.

My conclusion is, the satellite link is usable for TCP/IP but you
feel that the remote host is "far away".

Viljo

--
Viljo Soo			|   Internet: Viljo.Soo@ebc.ee
				|   Phone:    +(372 34) 33635
 Estonian Biocentre		|   fax:      +(372 34) 35430

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Jul 1993 18:18:55 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 <CA9IMu.2J2@watserv1.uwaterloo.ca>, erick@sunee.uwaterloo.ca (Erick Engelke) writes:
>  donp@novell.com (don provan) writes:
> > trt@duke.cs.duke.edu (Tom Truscott) writes:
> >
> >>If five years from now the industry has settled on little-endian,
> >>won't the TCP/IP "network order" look like a terrible mistake?
> 
> It was an arbitrary choice, but I'm glad it was standardized and
> not left up to negotiation.


You mean unlike other protocols like XTP?

Yes, me too.


Vernon Schryver,  vjs@sgi.com

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Jul 1993 18:21:46 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 <CA9IGL.KAt@news.iastate.edu>, john@iastate.edu (John Hascall) writes:
> }>If five years from now the industry has settled on little-endian,
> }>won't the TCP/IP "network order" look like a terrible mistake?
> 
> donp@novell.com (don provan) writes:
> }I seriously doubt it.  I don't know of *any* network protocol that
> }doesn't transmit multiple octet values high order octet first.  If CPU
> }architectures which store multiple byte values with the low order byte
> }first do, in fact, "win out", it'll just mean that network order and
> }memory order will forever be different.
> 
>    Why?  If we have to seriously `dink' with a network protocol
>    for other reasons (IP:`the next generation' comes to mind),
>    then why shouldn't we consider changing `network byte order'?
>    (other than entrenched big-endian-ism)


IP is not TCP.

I think at least some of the IPv7 proposals do not involve any changes
that would break end-to-end user-data checksums.

In any case, gratuitious, faddish changes are the worst dangers of
constitutional conventions and standards committee revisions.


Vernon Schryver,  vjs@sgi.com

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 1993 19:33:52 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: What's the better way to administer IP addresses to dorms?

[removing Distribution: usa restriction]
In article <225r6qINN6jb@galaxy.uci.agh.edu.pl> szymon@galaxy.uci.agh.edu.pl (Szymon Sokol) writes:
>
>Frederick Scott (fred_s@netcom.com) wrote:
>
>: 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.
>
>I wonder how do you want to prevent it... Most Ethernet adapters can spoof
>*hardware* (i.e., MAC-level) addresses,

How it was explained to me, our dorm setup at Penn State effectively
solves this problem:

There is a static ARP table linking MAC addresses to IP addresses
at the router. (prevents IP spoofing)

Each port on the concentrator "learns" the MAC address of the device
on the other end, and bells and whistles go off if it detects a change.
(prevents MAC spoofing)

Each ethernet packet not destined for a particular MAC address/port
(except a broadcast) has its data portion replaced with 1's and the
checksum recomputed.  (Prevents snooping)

To me, _all_ open computing ethernet environments like a dorm or PC lab
should have at least this setup.

--Dave
-- 
System Administrator, Penn State Population Research Institute
"existing" vs. "pre-existing".  Is that like "born" vs. "born again"? -me

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Jul 1993 20:49:39 GMT
From:      lees@c4cbd.austin.ibm.com (Lee Slaughter)
To:        comp.protocols.tcp-ip
Subject:   Re: Errors on unconnected UDP sockets and RFC1122

In article <JOHN.93Jul1171819@gecko.mtc.ti.com> john@gecko.mtc.ti.com (John Maline) writes:
... deletions
>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?

I don't follow. UDP *did* pass the ICMP error to the application
and the application (under BSD) marked the socket. It seems to me
that fulfills the intention of the RFC sentence you quote, or am I
missing something?  (has been known to happen  ;^) 

(I am very interested in this as I'm working on a defect of this
very nature)

lee

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Jul 1993 20:51:26 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?

szymon@galaxy.uci.agh.edu.pl (Szymon Sokol) writes: 

>Frederick Scott (fred_s@netcom.com) wrote:
>
>: 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.
>
>I wonder how do you want to prevent it... Most Ethernet adapters can spoof
>*hardware* (i.e., MAC-level) addresses, and BOOTP (as well as RARP) uses 
>MAC address to determine IP address. IMHO, you can do nothing about it.
>Nevertheless, I would go for static address assignment - at least, it is harder
>to spoof.

You are correct - it is impossible to prevent the *deliberate* spoofing of
another device on the network.

What I was referring to was the potential for inadvertent spoofing caused by
one of the scenarios I mentioned in my previous post.  Security problems in
a dorm net are scary enough without making legitimate users into unwitting
contributers to network instability.

Fred

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 93 21:47:13 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.unix.questions,comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Re: Port allocation below 1024 for users

In article <220v1r$aus@mozz.unh.edu> fgs@kepler.unh.edu ( F r e D  S l a m A ) writes:
>    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).

You could write a set-uid program that allocates the socket and then passes
it to the user program via a Unix domain socket (using the sendmsg(2)
call).
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 1993 21:49:52 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.

In article <1993Jul16.073240.22953@novell.com> donp@novell.com (don provan) writes:
>I seriously doubt it.  I don't know of *any* network protocol that
>doesn't transmit multiple octet values high order octet first.

Don, I think there's one in your own backyard!  Doesn't NCP send most
of its datagrams with the low-order octet first?

      Stephen

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

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 1993 21:58:08 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: What's the better way to administer IP addresses to dorms?

We do something similar by using NNStat to monitor IP addresses vs.
Ethernet addresses.  A periodic script checks the results and flags and
discrepencies with our BOOTP tables.

Our repeaters can do "frozen" setups like what you mention, but
maintaining those setups were far too much work.

Bridging means that NNStat monitor I mentioned is not as effective as
I would like.  My dream would be to have such monitors scattered
across campus, but we don't have the resources for that.  They are
useful for many things besides Ethernet/IP address checking!

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

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Jul 1993 22:48:48 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Would 0xFFFF ever be a TCP checksum? Comments pls.

}>If five years from now the industry has settled on little-endian,
}>won't the TCP/IP "network order" look like a terrible mistake?

donp@novell.com (don provan) writes:
}I seriously doubt it.  I don't know of *any* network protocol that
}doesn't transmit multiple octet values high order octet first.  If CPU
}architectures which store multiple byte values with the low order byte
}first do, in fact, "win out", it'll just mean that network order and
}memory order will forever be different.

john@iastate.edu (John Hascall) writes:
>    Why?  If we have to seriously `dink' with a network protocol
>    for other reasons (IP:`the next generation' comes to mind),
>    then why shouldn't we consider changing `network byte order'?
>    (other than entrenched big-endian-ism)

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
}IP is not TCP.
 
}I think at least some of the IPv7 proposals do not involve any changes
}that would break end-to-end user-data checksums.

   If by "user-data checksum", you mean the UDP or TCP checksum,
   I am doubtful, since these include the pseudo-header, and
   since the pseudo-header includes addresses.

   At least one of the contenders proposes changes to TCP as
   well as IP (sort of a `fix it all at once' strategy).

}In any case, gratuitious, faddish changes are the worst dangers of
}constitutional conventions and standards committee revisions.

   I'm not sure it's clear that considering the 20 years
   experience we've gained with current checksum scheme
   as it might apply to a new protocol is gratuitous or faddish.

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

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Jul 1993 23:01:26 GMT
From:      perlman@tuck.cs.fit.edu (Marshal H. Perlman)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   MORE ON SLIP, MTU, ETC...

Greetings all,

Could someone please inform me of how I can determine correct MTU, MSS, & RWIN
settings for running a slip under DOS to a Xyplex MX1600... [or how to get
this info my own self...]

THANKS

a CC: of your posting is always nice!

--
  |o| Marshal Perlman                       Internet: perlman@cs.fit.edu |o|
  |o| Florida Institute of Technology                        IRC: Squawk |o|
  |o| Melbourne, Florida                             Private Pilot, ASEL |o|
  |o| 407-676-4331                            Goodyear Blimp Club Member |o|

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Jul 1993 23:09:56 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: Errors on unconnected UDP sockets and RFC1122

john@gecko.mtc.ti.com (John Maline) writes:
> 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.  [...]"
> According to _Unix Network Programming_ by Stevens, p 271 (discussing
> the connect() call):
> 	"[...] 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?

  Notice that the discussion under RFC 1122 4.1.3.3 states:

     "A UDP-based application that wants to receive ICMP error messages is
      responsible for __maintaining__the__state__ necessary to demultiplex
      these messages __when__they__arrive__; ..."

  Thus, UDP is required to notify only those applications whose state 
  (of the UDP socket) indicates that they are interested in the ICMP.

  This would require that the application indicate an interest in input
  from the particular IP address and port (for Port Unreachable) that would
  be indicated in the ICMP.

  It is true that the RFC says:  "__for__example__, the application may keep
  a pending receive operation for this purpose."

  But in 4.3BSD, this is not sufficient state information because the read
  request does __not__ indicate the source of the expected input.

  Instead, in 4.3BSD, this state is set up by calling connect(2) on the
  SOCK_DGRAM descriptor.

  So I would conclude that 4.3BSD __is__ compliant with RFC 1122 insofar as
  the API (socket interface) provides.

-- Ken Mintz

DISCLAIMER:  This response does not represent the official position of, or
statement by, the Hewlett-Packard Company.  This response is provided for
informational purposes only and is supplied without warranty of any kind. 

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Sat, 17 Jul 1993 00:26:44 GMT
From:      rale1@cs.aukuni.ac.nz (Ross Douglas    Alexander      )
To:        comp.protocols.tcp-ip
Subject:   Re: Can I use TCP/IP over satellite links?

In <1993Jul16.123039.156@ebc.ee> viljo@ebc.ee (Viljo Soo) writes:

>Rogelio Montanana (MONTANAN at EVALUN11) (MONTANAN@EVALUN11.BITNET) wrote:
>> Talking with telecommunication specialists they recommend satellite links
 ...
>> claim that it is no problem, but I am not so sure.
 
>We use satellite link to connect our network in Tartu, Estonia to
 ...
>response time for ping over our satellite link is 572ms.
 
>My conclusion is, the satellite link is usable for TCP/IP but you
>feel that the remote host is "far away".
>Viljo

Here in NZ we connect to the world through Paccom, with is a sattelite link
to the west coast (USA).  Here are some stats.  These were done on a Saturday
morning so the delays are average.

 1  ccr1.aukuni.ac.nz (130.216.3.33)  0 ms  0 ms  10 ms
 2  gw-fr.waikato.tuia.net.nz (140.200.240.2)  30 ms  70 ms  20 ms
 3  feba-aotearoa.waikato.paccom.net.nz (140.200.128.2)  30 ms  220 ms  30 ms
 4  132.160.254.1 (132.160.254.1)  720 ms  700 ms  810 ms
 5  AMES.BARRNET.NET (192.52.195.8)  690 ms *  730 ms

PING ames.barrnet.net (131.119.3.2): 56 data bytes
64 bytes from 131.119.3.2: icmp_seq=0 ttl=251 time=710 ms
64 bytes from 131.119.3.2: icmp_seq=1 ttl=251 time=660 ms
64 bytes from 131.119.3.2: icmp_seq=2 ttl=251 time=660 ms
64 bytes from 131.119.3.2: icmp_seq=3 ttl=251 time=1010 ms
64 bytes from 131.119.3.2: icmp_seq=4 ttl=251 time=690 ms
64 bytes from 131.119.3.2: icmp_seq=5 ttl=251 time=750 ms
64 bytes from 131.119.3.2: icmp_seq=6 ttl=251 time=770 ms
64 bytes from 131.119.3.2: icmp_seq=7 ttl=251 time=700 ms
64 bytes from 131.119.3.2: icmp_seq=8 ttl=251 time=750 ms
64 bytes from 131.119.3.2: icmp_seq=9 ttl=251 time=990 ms

----ames.barrnet.net PING Statistics----
10 packets transmitted, 10 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 660/769/1010

As you can see the delays are significant.  The delays to nic.ddn.mil (which
I use as an ftp site) can often be 10 times worst than above (eg 5 to 10 secs
delay).  This makes ftp real slow and interactive work impossible.

This is not to say that TCP does not work.  No transport protocol works well
with such large (and variable) delays.  For ftp, mail and news it does not
matter since almost all is done in the background.

So, yip, IP and TCP over sattelite is not a problem but the delays are a
killer.

-- 
---------------------------------------------------------------------------
| Ross Alexander            | " Well, thats the problem with plutonium    |
| Computer Science          |   Craven, its limited in is application.    |
| Auckland University       |   Why hell, of course I made a bomb."       |

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 93 13:01:22 -0600
From:      stubrbee@acs.eku.edu (Oooooooops)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   Re: LOOKING FOR: Simple socket program.

In article <1993Jul16.052657.29883@serveme.chi.il.us>, greg@serveme.chi.il.us (Gregory Gulik) writes:
> 
> Has anyone written a simple socket based program does does
> the following?:
 
> Gregory A. Gulik                                 Call Gagme, a public access
>        greg@serveme.chi.il.us                --> UNIX system at 312-282-8606
>    ||  gulik@rtsg.mot.com                    |    For information, drop a note
                                               |
                                                -----------------------
Mr. Gulik,                                                             |
     Here is a simple socket program i just hacked out.  This was      |
written for vax/vms/multinet but since you seem to be on a unix system |
i converted it the best i could.  It should work.
Enclosed is the following:

Sock.h ......... The header file that i use on out ultrix. ( the 
                 includes should be similar on your unix machine )
Sock_r.c ....... This the the read daemon.  This program must be running
                 by the person you are attempting to send to.  (it can 
                 run in background if you so desire)
Sock_s.c ....... This is the program that sends the information to the 
                 read daemon.

You stated in your request that you wanted to send a character.  Well my 
example send a int.  You can modify it by changing int *buf to char 
*buf.  You may also have to alter some printf's....nothing to big.
Let me know how itr goes, or if you need any help with it.  I'm still learning
about them myself...

David...

{-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=}
{ Name         : David Barbee              Aliases  : Sybie                    }
{ Bitnet       : STUBRBEE@EKU              Internet : stubrbee@acs.eku.edu     }
{ Disclaimer   : Listen to me?!?  Can't imagine why.                           }
{-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=}


/*****************************Sock.h*****************************/
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/time.h>
#include <netinet/in.h>
#include <netdb.h>
#include <stdio.h>

#define HOSTNAME "acs.eku.edu"
#define PORTNUM  50000
#define MESSAGE  123
#define oops(msg) { perror(msg); exit(-1); }

struct   sockaddr_in saddr;
struct   hostent *hp;
int      sock;



/****************************Sock_r.c******************************/
#include "sock.h"

main()
{
  int *buf;
  fd_set ready;
  struct timeval to;
  int nsock, length, stat;

  /* set up defaults */
  server.sin_family = AF_INET;
  server.sin_addr.s_addr = INADDR_ANY;
  server.sin_port = htons(PORTNUM);

  /* create socket */
  sock = socket(AF_INET, SOCK_STREAM, 0);
  if (sock < 0) oops ("createing socket!");

  /* bind socket */
  if (bind(sock, &server, sizeof(server))) oops("Binding!");
  length = sizeof(server);
  
  /* Get socket name */
  if (getsockname(sock, &server, &length)) oops("Getting socket name!");

  /* Queue up calls */
  listen(sock, 1);

  printf("Socket has port #%d\n", ntohs(server.sin_port));

  while(1)
  {
    close(nsock);

    /* Accept connection */
    nsock = accept(sock, (struct sockaddr *)0, (int *)0);
    printf("-=-=-=-=-=-=-=-=-=-=Connection Opened-=-=-=-=-=-=-=-=-=-=\n");

    /* Read everyting from that person */
    do
    {
      bzero(buf,sizeof(buf));
      stat = read(nsock,buf,sizeof(buf));
      if (stat < 0) oops("Reading!");
      if (stat > 0) printf("Server read:  %d\n",*buf);
    } while( stat > 0);

    printf("-=-=-=-=-=-=-=-=-=-=Connection Closed-=-=-=-=-=-=-=-=-=-=\n");

    /* Close Socket */
    close(nsock);
  }
}





/******************************Sock_s.c******************************/
#include "sock.h"

main()
{
  /* Make sure we have a legitamate host */
  hp = gethostbyname(HOSTNAME);
  if (hp == 0) oops("Unknown host!");

  /* Tell the server what host we will be connecting to */
  bzero((char *) &server, sizeof(server));
  bcopy(hp -> h_addr, (char *) &server.sin_addr, hp -> h_length);

  /* Let the server know what port we will be taking */
  server.sin_port = (unsigned short) htons(PORTNUM);

  /* Let the server know what protocol we will be using */
  server.sin_family = hp -> h_addrtype;

  /* Create the socket */
  sock = socket(AF_INET, SOCK_STREAM, 0);
  if (sock < 0) oops("creating socket!");

  /* Connect our socket to the 'read' daemon */
  if ((connect(sock, (struct sockaddr *) &server, sizeof(server))) < 0) oops("connecting!");

  printf("Attempting to write '%d' to %s on port %d.\n",MESSAGE,HOSTNAME,PORTNUM);

  /* Write something to the socket */
  if (write(sock, &MESSAGE, sizeof(MESSAGE)) < 0) oops("writeing!");

  /* Close our connection */
  close(sock);
}


-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 93 17:17:14
From:      amoss@picton.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip
Subject:   Re: What's the better way to administer IP addresses to dorms?

trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:

   We do something similar by using NNStat to monitor IP addresses vs.
   Ethernet addresses.  A periodic script checks the results and flags and
   discrepencies with our BOOTP tables.

   Our repeaters can do "frozen" setups like what you mention, but
   maintaining those setups were far too much work.

   Bridging means that NNStat monitor I mentioned is not as effective as
   I would like.  My dream would be to have such monitors scattered
   across campus, but we don't have the resources for that.  They are
   useful for many things besides Ethernet/IP address checking!

NNStat seems a bit an overkill for such trivial tasks IMO.  There is a small
utility called "arpwatch" distributed from ee.lbl.gov quite a while ago which
seems to do what you want:  it checks for consistency between MAC addresses and
IP addresses.

Maybe you would like to check it out.  I never used it myself though.

Cheers,
--
--Amos Shapira (Jumper Extraordinaire) |  "It is true that power corrupts,
C.S. System Group, Hebrew University,  |   but absolute power is better!"
Jerusalem 91904, ISRAEL                |
amoss@cs.huji.ac.il                    |          -- the Demon to his son

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 1993 19:25:04 GMT
From:      sean@ugcs.caltech.edu (M. Sean Bennett)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Source for rwalld

Could someone point me at the sources for Rwalld (not rwall I have that).

E-mail me as I don't read this group that often.
Thanks

Sean

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 93 23:15:14 GMT
From:      leisner@hydrus (Marty Leisner x71348 )
To:        comp.protocols.tcp-ip
Subject:   reliable datagram communications

What work has been done on reliable datagram communiations?

--
Marty Leisner	leisner@eso.mc.xerox.com   leisner.henr801c@xerox.com
"A distributed system is a system in which
I can't get my work done because a computer has
failed that I've never heard of" -- Butler Lampson

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1993 01:00:00 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: reliable datagram communications

In article <1993Jul17.231514.24278@spectrum.xerox.com> leisner@eso.mc.xerox.com writes:
>
>What work has been done on reliable datagram communiations?

Lots.  Look at TCP.

(or is that begging the question?)

--Dave
-- 
System Administrator, Penn State Population Research Institute
"I have been talking about *newsgroup* democracy, and sysadmins don't
control newsgroups." - Dick Depew

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1993 01:24:43 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   dnswalk 1.6 - preliminary announcement

	I found a couple minor bugs in dnswalk, and one semi-major bug
having to do with the output of the 4.9.x dig.  (";serial" in the SOA
was changed to "; serial".  Hmft.  It should work now with either.)
Also, does anyone know why dig now prints two SOA's?  (doesn't remove
the matching SOA)
	This is a preliminary (ok, call it beta) release of 1.6.  Please
report any bugs to me.  You can get dnswalk from:

ftp.pop.psu.edu:/pub/src/networking/dnswalk.1.6.tar.Z

	After a week or so if I don't hear anything I'll post it to
one of the .sources groups and send a copy to vix for 4.9.(3?).

	For those of you unfamiliar with dnswalk, here is the README:

--Dave
---------
		dnswalk 1.6 - July 1993

Author: David Barr <barr@pop.psu.edu>

INTRO

dnswalk is a DNS debugger.  It performs zone transfers of specified
domains, and checks the database in numerous ways for internal
consistency, as well as accuracy.

dnswalk requires perl and dig.  (Tested under perl-4.036, dig 2.0, and
the dig shipped with BIND 4.9.x) If you do not have these tools, get
them.  (perl is assumed to be in /usr/local/bin, edit the first line of
dnswalk if it is not)

They can be found by anonymous ftp at:
ftp.uu.net:/networking/ip/dns/dig.2.0.tar.Z
ftp.uu.net:/systems/gnu/perl-*.tar.Z
gatekeeper.dec.com:/pub/BSD/bind/4.9/4.9.*.tar.Z

	dnswalk works much better if you use the dig that is packaged
with the BIND 4.9.x distribution.  (It is much less buggy than its
predecessor)

	dnswalk is not for the faint of heart.  It should NOT be
used without a firm knowledge of the DNS RFC's.  If you use this
tool for cracking or otherwise evil purposes, the author hereby
considers you a slime-ball.  See the end of this README file for
a list of good reading material.

	dnswalk is not the be-all end-all tool for checking the
integrity of your DNS database.  I would suggest it be used after
using 'doc', written by Steve Hotz (hotz@isi.edu) and Paul Mockapetris
(pvm@isi.edu).  It can be found via FTP from:
ftp.uu.net:/networking/ip/dns/doc.2.0.tar.Z

	dnswalk is not a replacement for doc.  This was written to
check individual database entries, while 'doc' ensures that the overall
database structure and authority records are consistent.  dnswalk may
not even function correctly if authority records are missing or
incorrect.

	This program may be freely distributed, as long as this notice
and documentation are distributed with the program.  This program is
released as-is, with no warranty expressed or implied.  Some assembly
required, contents may settle during shipment.  This program can be
found at ftp.pop.psu.edu:/pub/src/networking/dnswalk.1.6.tar.Z,
and probably also in ftp.uu.net:/networking/ip/dns.

USAGE

	Invoke dnswalk as follows:

dnswalk [-fradm] domain [> logfile]

	dnswalk tends to produce lots of output, so I'd suggest
redirecting this into a file of your choice.  I debated using doc's
strategy of automatically putting it in a logfile, but decided not
to.  (The author reserves the right to change his mind)  For small,
mostly-correct domains it is pretty manageable, however.  For larger
domains, use the included 'do-dnswalk' script as a guide.

Options:
	-f	Force a zone transfer from an authoritative nameserver.
		dnswalk normally will look in its saved 'axfr' file
		for each domain and use that. (if it exists)
	-r	Recursively descend sub-domains of the specified
		domain.  Use with caution and care.
	-a	Turn on warning of duplicate A records.  (see below)
	-d	Some debugging.  (Use only if redirecting stdout)
	-m	Perform checks only if the zone has been modified since
		the previous run.
	-F	perform "fascist" checking.  When checking an A record,
		compare the PTR name for each IP address with the forward
		name and report mismatches.  (see below)  I recommend
		you try this option at least once to see what sorts of
		errors pop up - you might be surprised!.
	-l	Perform "lame delegation" checking.  For every NS record,
		check to see that the listed host is indeed returning
		authoritative answers for this domain.  Inspiration for
		this comes from the great guys at U-M.


The domain name specified on the command line MUST end with a '.'.
You can specify a forward domain, such as "dnswalk pop.psu.edu."
or a reverse domain, such as "dnswalk 155.118.128.in-addr.arpa."

What dnswalk will do is if it is checking "pop.psu.edu.", it will
do a zone transfer of the data from the authoritative nameserver and
put it in the file "edu/psu/pop/axfr".  (relative to the current directory)
If dnswalk is run again, it will use this file instead of asking the
nameserver again.  You can override this with the '-f' switch.  It
will also do a zone transfer again later if the serial number in the
file is less than what is returned from the server.

As a result, if you use the recursive option, you will get a directory
tree corresponding exactly to the DNS hierarchy.  Again, I must stress
that you use the recursive option with care, and the author calls you
a slime-ball again if you use this for evil purposes.


WHAT DNSWALK CHECKS FOR..

*  all PTR records that look like a full IP address point back to a
forward name.  In other words, "3.155.118.128.in-addr.arpa."
will be checked, but "155.118.128.in-addr.arpa." will NOT be checked.
(For those people who give their subnets a name)  Addresses ending
in .0 are also NOT checked.
[ reports error as "X PTR Y: unknown host" ]

*  PTR records are listed as IP addresses in forward name.  In other
words if 4.3.2.1.in-addr.arpa. points to "foo.org", but "foo.org"
doesn't have "1.2.3.4" listed in its forward A records then it will
 be an error.
[ reports error as "X PTR Y: forward matching A record not found" ]

*  PTR records do not point to a CNAME.
[ reports error as "X PTR Y: CNAME (to Z)" ]

*  CNAMEs point to a host with an A record.
[ reports error as "X CNAME Y: unknown host" ]

*  CNAMEs do not point to another CNAME.
[ reports error as "X CNAME Y: CNAME (to Z)" ]

*  MXs point to a host with an A record.
[ reports error as "X MX Y: unknown host" ]

*  MXs do not point to a CNAME.
[ reports error as "X MX Y: CNAME (to Z)" ]

*  A records have some corresponding PTR record.  (Not necessarily
of the same name, of course)
[ reports error as "X A Y: no PTR record" ]

*  Reports any packet size errors listed in dig zone transfer output
(Could be caused by a corrupted zone file, or invalid syntax used)

*  That there is more than one authoritative nameserver for a zone.
It does not check if the machine is on a separate network (yet).
A site should ALWAYS have a secondary nameserver.  It SHOULD be
on a different network than the primary.

(with -a switch)
*  duplicate A records listed for a given host.  NOTE: this is most
often caused by the practice of always putting A records for all
secondaries after NS glue records.  While this is not an error, it is
usually redundant and makes changing IP addresses later more difficult,
since they occur more than one time in the file (and in multiple
files).  This checking needs more work.  (Mostly because of a quirk in
BIND that reports cached A records in a zone transfer even though they
don't exist in the original zone file.  I might just end up skipping this
check altogether.)
[ reports error as "X: possible duplicate A record (glue of Z?)" 
where Z is the previous zone listed in the file ]

(with -F switch)
* perform "fascist" checking.  When checking an A record, compare the PTR
  name for each IP address with the forward name.  This WILL result in
  needless errors (like if you have an A record for your domain name
  pointing to your main server, or have A records like "mailhost" or
  "ns" defined to point to your mail or DNS server) but will catch little
  errors that may have crept in if you have an A record pointing to a host
  that you didn't intend to.
[ reports error as "X A Y: points to Z" where Z is the "canonical" name
  as returned by gethostbyaddr() ]

(with -l switch)
* Lame delegations.  A lame delegation is when a domain says "this
server is a secondary for zone Z" but the listed server is not giving
out authoritative data for zone Z.  This is usually the result of
a lack of communication on the part of the respective hostmasters.
Lame delegations are not fatal problems, they just tend to create
significant increases in DNS traffic.
[ reports error as "X NS Y: lame NS delegation" where X is the domain,
and Y is the lame nameserver ]


*** NOTICE ***
	I fully realize that while some of the above rules are not
in violation of an RFC, it might be wise to reconsider their usage anyway.
dnswalk was written to be a tool to let the hostmaster decide what are 
troublesome areas, not as a program that has all the answers.
*** NOTICE ***


CAVEATS

	If a domain "foo.edu" lists "ns.bar.foo.edu" as authoritative for
a zone "bar.foo.edu", but "ns.bar.foo.edu" isn't, then the the dig of
the zone transfer will hang.  (This was the case here for a subdomain
that moved into a new set of IP addresses, but the parent nameserver still
had the old authority records pointing to their nameservers which weren't
answering to the old reverse domain anymore.)  If this happens, you can
hit ^C while the transfer is going on and dnswalk will abort that server.
(It will also remove the partial axfr file)  Hopefully I can figure a
more elegant way around this.  (or fix dig so that it doesn't hang)

This program was tested with data from the psu.edu domain.  If your
site does things differently than the way we do things, then you
may see it report things as errors, when in fact they are "okay".
If you notice something not being reported, or something reported that
is not an error, please send me output!  I fully admit that I'm not
an expert in DNS and the requirements.  My rules tend to be skewed to
my personal feelings about what "nice" DNS databases look like.  Others
are free to differ.  (and tell me so)

BUGS
	I should get around to writing a real man page.

	dnswalk will make the directory tree before it has a chance to
find out that you gave it a bogus domain name.

	When checking lots of hosts and lots of options, it is very
slow.  Running dnswalk on a machine with a local nameserver helps
considerably.

	Perl's gethostby{name,addr}() routine doesn't seem to
consistently return an error whenever it is unable to resolve an
address.  Argh.  This will mean lots of "no PTR record" and "host unknown"
errors if a server is unavailable, or for some reason the lookup fails.

	I really need to rewrite this all to not rely on dig, and use
bind.pl instead.

OTHER SOURCES

RFC 1034 - "DOMAIN NAMES - CONCEPTS AND FACILITIES"

RFC 1035 - "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

RFC 1123 - "Requirements for Internet Hosts -- Application and Support"

Paul Albits, Cricket Liu: "DNS and BIND" O'Reilly & Associates.

[the author recommends copies by your favorite bathroom and/or nightstand]

David Barr - System Administrator
The Pennsylvania State University Population Research Institute
<barr@pop.psu.edu>

Thanks:

Bill Fenner - tips with perl

BUGS FIXED

added equal() routine and changed all string comparisons to use it
instead.  equal() does case-insensitive comparisons.  This was causing
several problems with mixed case host and domain names in various
places.

checks for invalid PTR records now skip addresses ending in ".0".

shortened error messages so they are more likely to fit in 80 columns

handles failed zone transfers better.  You can't trust dig to return
a non-zero return code if the transfer fails, so I parse the output
myself to see if it contains an SOA record to prove that it is 'valid'.

sorts output by zone.  Also displays server of authority and the
contact for the zone.  (So you know who to bug :-) )

produced erroneous warnings regarding having only one authoratative
nameserver for a zone.  It now warns correctly.

[ BUGS now moved to CHANGES file ]
-- 
System Administrator, Penn State Population Research Institute
lose: v. to miss from one's possession.
loose: n. not securely fastened.  v. to set free.

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18 Jul 1993 02:38:58 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: reliable datagram communications

barr@pop.psu.edu (David Barr) writes: 

>In article <1993Jul17.231514.24278@spectrum.xerox.com>
>leisner@eso.mc.xerox.com writes:
>>
>>What work has been done on reliable datagram communiations?
>
>Lots.  Look at TCP.

TCP is generally consider a "streaming protocol", as opposed to a "datagram"
protocol, in the sense that record boundries can easily be lost in the
course of transmission.  That is, when you present a record to the transport
level software on one peer for sending, you are not guaranteed that it will
be received on the other peer with its record boundries in tact.  You ARE
gauranteed that no data will be lost and that the data will be received in
the order that it was sent, but the software running on top of the TCP
software at the peer cannot gleen anything about where record boundries begin
or end from the TCP services offered.

As for the original question, sorry - I can't say for sure.  It seems to me
that I heard that one of the Decnet protocols was considered a "sequenced,
reliable datagram" protocol but I've never had any experience with it.  XTP
had facilities for marking bytes which might assist application software in
framing records but it isn't exactly the same thing.

Fred

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 93 12:10:20
From:      amoss@picton.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip
Subject:   Re: reliable datagram communications

fred_s@netcom.com (Frederick Scott) writes:


   >>leisner@eso.mc.xerox.com writes:
   >>
   >>What work has been done on reliable datagram communiations?
   >
   >Lots.  Look at TCP.

   As for the original question, sorry - I can't say for sure.  It seems to me
   that I heard that one of the Decnet protocols was considered a "sequenced,
   reliable datagram" protocol but I've never had any experience with it.  XTP
   had facilities for marking bytes which might assist application software in
   framing records but it isn't exactly the same thing.

What about RDP (Reliable Data Protocol)?  Version 2 is described in RFC 1151.

I didn't look at it myself so I don't know if it's relevant at all.

--Amos

--
--Amos Shapira (Jumper Extraordinaire) |  "It is true that power corrupts,
C.S. System Group, Hebrew University,  |   but absolute power is better!"
Jerusalem 91904, ISRAEL                |
amoss@cs.huji.ac.il                    |          -- the Demon to his son

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18 Jul 1993 07:18:28 GMT
From:      olea@netcom.com (Michael Olea)
To:        comp.protocols.tcp-ip
Subject:   Re: reliable datagram communications

>TCP is generally consider a "streaming protocol" ...

	Yep.  It's reliable, but it's not "datagram communication".
For one thing, TCP is "connection" oriented.  That is, for TCP
communication to procede, there must be a connection between a pair
of processes.  Sure, TCP is built on top of an (unreliable) datagram
service, but TCP is decidedly not a datagram service.  It is not just
that TCP does not preserve record boundaries, but a matter of topology:
with TCP you send data, over a connection, from one process to another.
A given process might, of course, have many TCP connections, but if you
want to send the same message to many (connected) processes, you have
to send them each the message - one send command per connected process.
You can imagine that this might involve the same little packet traversing
the same ethernet repeatedly; first with this <host,port>, then with that
<host,port> etc.  TCP is great for data streams (e.g. file transfer), but
if you have processes exchanging fixed-sized messages in response to
occasional events, then something like a datagram service is called for.
	Trouble is, with UDP, the User Datagram Protocol, datagrams can
be lost, duplicated, delivered out of sequence, what you will - the
burden falls upon applications to ensure reliability.  And probably
thousands of UDP applications do just that - implement their very own
reliable UDP protocol.  Given perhaps thousands of implementations of
essentialy the same thing - reliable datagrams, does the notion generalize?
Is there call for a standard reliable datagram service?  Maybe, but it
is no simple matter to define the service.  One thing I would like to do
is send a packet once, and have it distributed to "all interested parties".
What does that mean - specificaly, what does IP do for destination net and
host addresses?  And assuming that multi-cast semantics can be resolved,
how are errors to be handled?  Say 9 out of 10 (perhaps unknown, and not
enumerated) targets, or maybe 8 out of 10, ack the datagram - what then?
	OK, so maybe my parochial notion of multi-cast datagrams does
not generalize - maybe reliabile delivery requires a unique source and
a unique destination - call any such source/destination pair a connection,
and it might as well be TCP...


-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18 Jul 1993 08:35:23 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: reliable datagram communications

olea@netcom.com (Michael Olea) writes: 

>>TCP is generally consider a "streaming protocol" ...
>
>	Yep.  It's reliable, but it's not "datagram communication".
>For one thing, TCP is "connection" oriented.  That is, for TCP
>communication to procede, there must be a connection between a pair
>of processes.  Sure, TCP is built on top of an (unreliable) datagram
>service, but TCP is decidedly not a datagram service.  It is not just
>that TCP does not preserve record boundaries, but a matter of topology:
>with TCP you send data, over a connection, from one process to another.

This is hardly unique to TCP.  UDP does this (allow connection-to-connection
communication) as well.  In fact, the only service UDP/IP really provides over
straight IP is connection demultiplexing.  

>A given process might, of course, have many TCP connections, but if you
>want to send the same message to many (connected) processes, you have
>to send them each the message - one send command per connected process.
>You can imagine that this might involve the same little packet traversing
>the same ethernet repeatedly; first with this <host,port>, then with that
><host,port> etc.  TCP is great for data streams (e.g. file transfer), but
>if you have processes exchanging fixed-sized messages in response to
>occasional events, then something like a datagram service is called for.

True.

>	Trouble is, with UDP, the User Datagram Protocol, datagrams can
>be lost, duplicated, delivered out of sequence, what you will - the
>burden falls upon applications to ensure reliability.  And probably
>thousands of UDP applications do just that - implement their very own
>reliable UDP protocol.  Given perhaps thousands of implementations of
>essentialy the same thing - reliable datagrams, does the notion generalize?

Likewise, I'm sure quite a few applications have implemented the same
functionality over TCP by implementing record boundries on the application
level.  It adds up to the same thing: framed data + reliability.

>Is there call for a standard reliable datagram service?  Maybe, but it
>is no simple matter to define the service.  One thing I would like to do
>is send a packet once, and have it distributed to "all interested parties".
>What does that mean - specificaly, what does IP do for destination net and
>host addresses?  And assuming that multi-cast semantics can be resolved,
>how are errors to be handled?  Say 9 out of 10 (perhaps unknown, and not
>enumerated) targets, or maybe 8 out of 10, ack the datagram - what then?
>	OK, so maybe my parochial notion of multi-cast datagrams does
>not generalize - maybe reliabile delivery requires a unique source and
>a unique destination - call any such source/destination pair a connection,
>and it might as well be TCP...

Actually, XTP implemented a "reliable" stream multicast service.  "Reliable"
quoted because it worked on a algorithm which required receivers to send
retransmission requests within a certain period of time or lose their right
to get data retransmitted.   In this case, a 'retransmission request' was
actually a control status packet showing portions of data missing.  Since
such packets are sent over what is essentially a net level protocol, they
could be lost in transmission and the multicast sender might never receive
them in time - before it had gone far enough to discard the data the receiver
had lost.  Therefore, the service was not 100% reliable, although it was
nearly so over a fairly well-behaved (as opposed to "lossy") network and
given reasonable acknowledge timeout contraints.  The algorithm also at least
permitted receivers to detect when they had been left behind and allowed to
"rejoin" the connection at a later point in the stream if they so desired.
Implementing the stream multicast service this way greatly simplified it
since there was no necessity for the sender to keep track of the exact status
of all of its receivers.  It also allowed receivers to skip acking a given
portion of data if they "overheard" another receiver acking the same data on
the same connection.

Fred

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18 Jul 93 15:25:36 EDT
From:      edimg@willard.atl.ga.us (Ed pimentel)
To:        comp.protocols.tcp-ip
Subject:   Looking for Net Mgr snmp programs

I would like to learn more about tcp/ip and snmp net programming,
and I am looking for small program that do net managements.
Are there any C source, that query node, bridges, routers etc..

-- 
edimg@willard.atl.ga.us (Ed pimentel)
gatech!kd4nc!vdbsan!willard!edimg
emory!uumind!willard!edimg
Willard's House BBS, Atlanta, GA -- +1 (404) 664 8814

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18 Jul 1993 13:32:24 GMT
From:      d7stfax@dtek.chalmers.se (Stefan Axelsson)
To:        comp.protocols.tcp-ip
Subject:   Re: reliable datagram communications

leisner@hydrus (Marty Leisner x71348 ) writes:
>What work has been done on reliable datagram communiations?

Funny you should ask, I'm just reading the paper "The organization of
Networks in Plan 9" by Dave Presotto and Phil Winterbottom. (AT&T Bell
Labs) They wanted a protocol suitable for transmitting their 9P file
system protocol that had the following properties:

- Reliable datagram service with sequenced delivery
- Runs over IP
- Low complexity, high performance
- Aptive timeouts

Since none of UDP/TCP or anyting else met these criteria they designed
IL.

From the paper (quoted without permission):

"IL is a lightwight protocol designed to be encapsulated by IP. It is a
connection-based protocol providing reliable transmission of sequenced
messages between machines. No provision is made for flow control since
the protocol is designed to transport RPC messages between client and
server. A small outstanding message window prevents too many incoming
messages from being buffered; messages outside the window are
discarded and must be retransmitted. Connection setup uses a two way
handshake to generate initial sequence numbers at each end of the
connection; subsequent data messages increments the sequence numbers
allowing the receiver to resequence out of order messages. In contrast
to other protocols, IL does not do blind retransmission. If a message
is lost and timeout occurs, a query message is sent. The query message
is a small control message containing the current sequence numbers as
seen by the sender. The receiver responds to a query by retransmitting
missing messages. This allows the protocol to work well in congested
networks, where blind retransmission would cause further congestion.
Like TCP, IL has adaptive timeouts. A round-trip timer is used to
calculate acknowledge and retransmission times in terms of the network
speed. This allows the protocol to perform well on both the Internet
and on local Ethernets.
	In keeping with the minimalist design of the rest of the
kernel, IL is small. The entire protocol is 847 lines of code,
compared to 2200 lines for TCP. IL is our protocol of choice."

I think you could get this paper by ftp from research.att.com, but
you've seen all the IL related stuff in it already. If you want more
info, its in the source code I guess. And I'm not allowed to give you
that... Research licences are available though, that's how I got
mine.

Regards,
--
Stefan Axelsson,			Chalmers University of Technology,
d7stfax@dtek.chalmers.se		Sweden

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18 Jul 1993 14:40:17 GMT
From:      debiso@westfield.win.net (Joe DeBiso)
To:        comp.protocols.tcp-ip
Subject:   Problem with FTP-TCP/IP

I need some help!! I have FTP-TCP/IP and I cant get remote printing
to work.  I can use the lpr command, but the redirector wont
work.  Please help!!!



-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1993 16:44:16 GMT
From:      kumar@sloop.cis.ufl.edu (SHASHANK KUMAR)
To:        comp.protocols.tcp-ip
Subject:   Transport dll that implements WINSOCK.DLL

Hi Netters,

Excuse me if this is a FAQ. I am looking for a 

	"transport dll that implements the Winsock DLL, v1.1 
	(WINSOCK.DLL)".

I am interested in Shareware/Freeware products. Where can I find them.  

Replies => kumar@ketch.cis.ufl.edu

Thanks in advance,
-kumar

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18 Jul 93 17:30:16 GMT
From:      lourent@shamin.genie.uottawa.ca (Lourent Oppenheim)
To:        comp.protocols.tcp-ip
Subject:   Location of FAQ?


Please EMail as I do not read this often.
------------------------------------------------------------------------
Laurent Oppenheim                        lourent@shamin.genie.uottawa.ca
Multimedia Communications Research Lab            Ottawa, Ontario Canada
Univerity of Ottawa                                       (613) 564-9211        

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1993 19:09:51 GMT
From:      rv@Informatik.Uni-Dortmund.DE (Ruediger Volk)
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.
This topic has been on the agenda of the previous IETF meeting in Columbus.
A small group of interested persons worked on it since than, and reported back
results to the DNS WG meeting in Amsterdam last week (a nice closed action
item).

I guess the minutes will include some related paragraphs.

BTW in that session the question was raised whether this news group and
the namedroppers mailing list are (still) gatewayed and whether to post to
the news group or the mailing list;  the answers were:
- no, the gateway does not seem to work (certainly not bidirectionally)
- if you want to have the DNS WG be aware of a question or contribution
  send it to the WG's mailing list
--------
Ruediger Volk
Universitaet Dortmund, Informatik IRB				DE-NIC
D-44221 Dortmund, Germany

E-Mail: rv@Informatik.Uni-Dortmund.DE
Phone:  +49 231 755 4760                 Fax:  +49 231 755 2386

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18 Jul 1993 22:19:56 GMT
From:      maas@dutiws.twi.tudelft.nl (Frank Maas)
To:        comp.protocols.tcp-ip
Subject:   Re: On the usefulness of the ident service (Was: FTP - Port # 113 - query)

Since the discussion is just being "overposted" to comp.protocols.tcp-ip
(and please let me know if it continues on another group) I don't know what
lead it on and what has been said before. But since I have tried to get the
chief system manager outhere to support the ident-service I think I know
what the discussion is about.

The identity daemon offers a protocol to identify the user of a remote
system that is currently using a service on your machine. The big problem
some have against it (yes, the chief had (and has) it also) is the
trustability of the information you get.
It is true that this info can easily get corrupted. Firstly you don't know
if the system has an official (means installed by the system management)
identity-daemon installed, so you might be talking to something else that
gives you rubbish. Seccondly, a system may be hacked and the official
daemon with it giving you rubbish as well.

However, I think that the information should be used in a way which is less
dependent of the trustability. On my system nothing will happen until we
suspect a hack. In that case we try to investigate the system from which
the hackattempt came and if the system seems 'normal' we notify the local
system managment providing as much information as we can. If we got a
response from "an" identity-daemon, we include that in  the message. After
having sent the message (or in the case of a obviously crooked system)
access to our basic services is denied for that machine.
Now the local system manager can determine to use the identity-daemon
information as (s)he pleases. It is up to him/her to investigate the
trustability of the service, the possibility of a crooked version, etc.

Another possibile use of the identity-daemon is the automated
user-identification for anonymous ftp. Nowadays, users type in their e-mail
address to identify themselves. It is obvious that this isn't at all
trustable, so the information of the identity-daemon is to be preferred.

To close: from the above it should be obvious that I see the identity
information as an aid. You should not see the information as totally
secure, but use it in relation to the things you are doing. For me it is
clear that it would never be possible to use the identity information for
an automated login or other secured access procedures.

-- 
   _____                      _ _ _              
    /  '               /     ' ) ) )             |  maas@dutiws.TWI.TUDelft.NL
 ,-/-, __  __.  ____  /_      / / / __.  __.  _  |-----------------------------
(_/   / (_(_/|_/ / <_/ <_    / ' (_(_/|_(_/|_/_)_|   TWI - TU Delft - Holland

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Jul 1993 00:35:31 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: On the usefulness of the ident service (Was: FTP - Port # 113 - query)

In article <CADsp8.JEz@dutiws.twi.tudelft.nl> maas@dutiws.twi.tudelft.nl (Frank Maas) writes:

>Another possibile use of the identity-daemon is the automated
>user-identification for anonymous ftp. Nowadays, users type in their e-mail
>address to identify themselves. It is obvious that this isn't at all
>trustable, so the information of the identity-daemon is to be preferred.

  The data from the Ident "service" is not particularly more
trustworthy.  A better process is to log date, time, apparent remote
host, and apparent userid for all anonymous ftp logins.  If a problem
arises, contact the admin of that remote host.  The log/audit files on
that remote host are MUCH MUCH more trustworthy than any alleged IDENT
data.  Such audit logs are certainly not completely trustworthy since
a clever intruder will carefully edit audit/log data to cover tracks.

You all completely overlook the insecurity of the IDENT protocol itself.

Ran
atkinson@itd.nrl.navy.mil


-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Jul 1993 00:38:21 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: More on the usefulness of ident (Was: FTP - Port # 113 - query)

In article <22cdat$mql@cnam.cnam.fr>, bortz@cnam.cnam.fr (Stephane Bortzmeyer) writes:
> ...
> >It is silly to worry about people doing "strange things" with FTP.
> >Anyone on the Internet who would let FTP be used for more than fetching
> >a few files by anonymous people on untrusted remote systems simply
> >because the remote systems answer port 113 is crazy.  Anyone not crazy
> >has closed up FTP so it is not useful in any way to bad guys.  
> 
> A few months ago, a severe bug was found in the "wuarchive" ftpd, a
> software used by many, many sites over the Internet. Before I patched
> it, a hacker was able to log in as root on my system. log_tcp was there
> but I only had the name of the remote site in my syslog file, not the user 
> name.

Would port 113 have done you any good?  I bet not.  In fact, from what
you say, port 113 was easily bypassed in this particular case, as
it would be in practially all cases that matter.

> Would you say I was crazy to run ftp at all? Do note I didn't ban access
> to anybody, I prefer to log what happens and to harass people only when
> they've done something.

No, I would say you were crazy to run an untested, unexamined FTP
server on a machine you care about.  In this case, "tested and
examined" means either that you personally have examined the code, or
that you personally know the names of a lot of good people who have
examined the code.  The wuarchive FTP server is neat, but no one should
run it on a machine they care about without being crazy, or without
doing a personal and very careful examinination of its facilities for
running programs and creating files.  It's neat to have the FTP server
synthesize tar.Z files, but that sort of thing has long been a major
source of security problems.  People who are not experienced enough to
do such an examination, or who do not hire it done, are crazy, or at
least woefully ignorant of the history of the Internet and of the
possibilities, and general "flexibility" of UNIX.

The prudent will wait at least 2 or 3 years before running something 
like that FTP server.  Or even something like the log-tcp package.
Let the crazy people take the risks and experience the fun.


> >Remember that tap, ident, and finger are all mild security holes in
> >your system, since they allow bad guys on remote systems to discover
> >user names on your system. 
> 
> I disagree: hiding user names seems to me yet another form of security
> through obscurity (STO). See the FAQ of alt.security for a discussion of
> STO. User names can be obtained by many ways, from telephone directories
> to E-mail addresses (unless you rewrite them). They shouldn't, IMHO, be
> used a defense line. Passwords are here for that.

I agree that security through obscurity cannot be depended on, where
what is obscure is how your system works.  However, why is keeping a
password secret not security through obscurity, but keeping the 8
characters required before the password not?  The username is simply
part of the passcode that is usually not very secret.

One reason that it is prudent (but not nearly sufficient) to avoid
broadcasting user names is that people consistently like to use
varients of their user names as their password.  The verients can be
obscure, and not practically detectable by the "good password
packages", things like shifting your fingers on the keyboard or mixing
control- or Shift- augmentations or padding with digits or control
characters.  Of course, we all know that forcing people to use a
password of the system's choosing is one of the least secure ways to
run a system, because of how humans respond to having to use hard to
remember passwords.

Security through obscurity is a useful first line of defense, a way to
be obnoxious to make a break-in less interesting.  For example, it is
an excellent idea to fiddle with libcrypt on your system so that the
common password crackers do not work.


Vernon Schryver,  vjs@sgi.com

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1993 22:37:22 +0200
From:      bortz@cnam.cnam.fr (Stephane Bortzmeyer)
To:        comp.protocols.tcp-ip
Subject:   On the usefulness of the ident service (Was: FTP - Port # 113 - query)

(This thread started on comp.sys.sgi and comp.dcom.sys.cisco, then was followed
up here, since there's nothing system-specific in it. It's about the RFC 931
"identification" service.)

atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:

>Blocking IDENT from working as alleged would only require a small
>extra step that anyone can do.  The method by which this is
>accomplished is left as an exercise.  

I'm afraid I'm not a good hacker. I didn't find the method yet. Can I suggest
you send it to the CERT and the author of the RFC 931 and of the ident 
software?

>Now if one's users are not very
>bright or aren't really doing anything intentionally malicious, IDENT
>will appear to work properly.  IDENT fails in the case that is most
>important -- a bright, malicious users.

There aren't only bright hackers. There are also A LOT of ordinary hackers
which, put together, make me loose a lot of time. No protocol can resist
to a genius. But if there is a protocol which stops low-level intruders,
it's already good for me.

Stephane Bortzmeyer           Conservatoire National des Arts et Metiers	
bortzmeyer@cnam.cnam.fr       Laboratoire d'Informatique
                              292, rue Saint-Martin			
tel: +33 (1) 40 27 27 31      75141 Paris Cedex 03
fax: +33 (1) 40 27 27 72      France	

"C'est la nuit qu'il est beau de croire a la lumiere." E. Rostand

					
	


-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Jul 1993 13:38:12 -0700 (PDT)
From:      Mark Crispin <mrc@Tomobiki-Cho.CAC.Washington.EDU>
To:        comp.protocols.tcp-ip, Arnt Gulbrandsen <agulbra@nvg.unit.no>
Subject:   Re: Trusted servers (was Re: More on the usefulness of ident)

Running ident can make the situation worse than it is presently, by
introducing false data.  Noise in data is as much of a contributor to the loss
of data quality as missing data.


-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1993 22:54:53 +0200
From:      bortz@cnam.cnam.fr (Stephane Bortzmeyer)
To:        comp.sys.sgi.admin,comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   More on the usefulness of ident (Was: FTP - Port # 113 - query)

(Notice the followup: I send this thread to comp.protocols.tcp-ip where it 
belongs since there's nothing specific to SGI or Cisco.)

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

>I agree with you.  Tap and ident can be useful for that.  So can `finger`.

finger is useless if you have too many users. You can finger the client
machine (if it agrees), but on a large site (again, my personal experience),
you'll find a lot of people with an 'idle' field of zero. What can you say
to the client machine's sysadmin? Fire them all?

>More important and useful than all three are good logs of who did what
>on your machines (say from system accounting).  Most real troubles, not

OK, good practice, not only for security purposes.

>Those three protocols, tap, ident, or finger, have nothing to do with
>"security," "authorization," or "authentication," but with what might be
>called "forensic computing."  It is silly to reject anonymous FTP
>requests from unknown (i.e. unauthenticated) users on untrusted, remote
>systems simply because the remote systems are not answerng port 113.

The original case (a site which was trying to do anonymous ftp to an 
'ident-curious' site in Denmark) involved probably a server which used
the log_tcp package (or something similar) to log all connections. 
Without ident, log_tcp can only record the client machine name. With
ident, you have the user name as well. I strongly recommend the use
of this package (see the excellent FAQ of alt.security, log_tcp can be
found in ftp.win.tue.nl:pub/security/log_tcp.shar.Z and on the CERT ftp
server). You can ask log_tcp to reject the requests when the ident server 
doesn't reply, but you don't have to.

>It is silly to worry about people doing "strange things" with FTP.
>Anyone on the Internet who would let FTP be used for more than fetching
>a few files by anonymous people on untrusted remote systems simply
>because the remote systems answer port 113 is crazy.  Anyone not crazy
>has closed up FTP so it is not useful in any way to bad guys.  

A few months ago, a severe bug was found in the "wuarchive" ftpd, a
software used by many, many sites over the Internet. Before I patched
it, a hacker was able to log in as root on my system. log_tcp was there
but I only had the name of the remote site in my syslog file, not the user 
name.
Would you say I was crazy to run ftp at all? Do note I didn't ban access
to anybody, I prefer to log what happens and to harass people only when
they've done something.

>Remember that tap, ident, and finger are all mild security holes in
>your system, since they allow bad guys on remote systems to discover
>user names on your system. 

I disagree: hiding user names seems to me yet another form of security
through obscurity (STO). See the FAQ of alt.security for a discussion of
STO. User names can be obtained by many ways, from telephone directories
to E-mail addresses (unless you rewrite them). They shouldn't, IMHO, be
used a defense line. Passwords are here for that.

Stephane Bortzmeyer           Conservatoire National des Arts et Metiers	
bortzmeyer@cnam.cnam.fr       Laboratoire d'Informatique
                              292, rue Saint-Martin			
tel: +33 (1) 40 27 27 31      75141 Paris Cedex 03
fax: +33 (1) 40 27 27 72      France	

"C'est la nuit qu'il est beau de croire a la lumiere." E. Rostand

					
	

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 93 04:47:35 GMT
From:      matt@emily.math.binghamton.edu (Matt Brin)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin,comp.unix.wizards
Subject:   solaris 2 route problems (formerly: glacial transmissions)

This is an elaboration on a previously posted problem.

We have the following geometry:  All machines are SUN SPARCs.

______ _________ ______ ______ ______ ______ ______ _________
|host| |gateway| |host| |host| |host| |host| |host| |gateway|
| 1  | |   A   | | 2  | | 3  | | 4  | | 5  | | 6  | |   B   |
 ______ _________ ______ ______ ______ ______ ______ _________
  |      |   |     |      |      |      |      |      |   |
  |      |   |     |      |      |      |      |      |   |
  --------   ------------------------------------------   -----------------
 net-a                      net-b                            university 
                                                             backbone
                                                               net-c

host 1 and gateway A run solaris 2
hosts 2-6 and gateway B run sunos 4.1.3
both gateways run in.routed in broadcast mode
host 1 has gateway A as defualt
hosts 2-6 have gateway B as default with an extra route entry for lan-a
	with gateway A listed as the gateway  (for example:

Destination          Gateway              Flags    Refcnt Use        Interface
localhost            localhost            UH       0      9          lo0
net-a                gateway-A            UG       1      1329       le0
default              gateway_B            UG       0      7683       le0
net-b                host-2               U        28     119616     le0     )

All network operations work except that ftp transmissions of large files
FROM gateway B TO a host from 2-6 go into exponential backoff after
transfering 20K or so, evidently from lack of acknowledgement from the
receiving host.  THE PROBLEM GOES AWAY if the in.routed on gateway A is
terminated.  It comes back if in.routed is restarted.

1. Why do we need in.routed on gateway A?  (Quick answer, host 1 cannot
get out if it doesn't run.  We turned ip_forwarding on gateway A, and host
1 still cannot get out.  Of course we had gateway A listed as the default
router on host 1.  This is not the answer that we are looking for.)

2. Why is the in.routed fouling the transmissions on net-b?

We have gotten some help to get us this far, but we are still in the 
woods.  Any other suggestions?
_____________________________________________________________________________
matt brin / math. dept / SUNY / Binghamton, NY 13902-6000 / (607)-777-2147
matt@math.binghamton.edu      	INTERNET
mbrin@bingvaxa			BITNET
-----------------------------------------------------------------------------

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1993 14:27:59 -0500
From:      karl@genesis.MCS.COM (Karl Denninger)
To:        comp.protocols.tcp-ip,comp.security.misc
Subject:   Re: Trusted servers (was Re: More on the usefulness of ident)

In article <PCL.93Jul19173319@rhodium.ox.ac.uk> pcl@ox.ac.uk (Paul C Leyland) writes:
>In article <22e7su$gu4@sol.TIS.COM> mjr@tis.com (Marcus J. Ranum) writes:
>
>	   A second route, and one which I personally feel is more
>   secure and sophisticated is to take care to configure your system
>   so that the quality of the software you are running for security
>   related services is irrelevant. In other words, if you're presenting
>   an anonymous FTP service, consider having it run under chroot
>   *BEFORE* anyone gets to talk to it. Then the thing can have a
>   shell escape to root in it for all you care, and it's not going
>   to hurt you. (This is not to imply that any of the sources for
>
>Am I missing something?  If I have a root shell, even in a chroot()ed
>filesystem, cannot I create device special files and from there go on
>to do interesting things?

Assuming you can get an executable file on the system which does what you
want (has a mknod() call in it) the answer is yes.

Securing the area then reduces to being able to prevent that first transfer.

--
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!

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 93 16:30:51 PST
From:      sgoldberg@davidsys.com
To:        ba.seminars,comp.org.decus,comp.protocols.tcp-ip,comp.os.vms
Subject:   Multinet training, Palo Alto, Sat, July 24

BayLUG (formerly BAYVAX), the San Francisco Bay Area DECUS LUG,
will be having an all day (9am-5pm) workshop on Saturday, July 24, 1993
on TGV's MultiNet software.  There is a $25 charge and this will
include sandwich lunch and course materials.

Title:  MultiNet Configuation, Management, and Troubleshooting
Presenters:  John McMahon and Trey Garlough (both of TGV)

The seminar will provide in-depth coverage of configuration, 
administration, and troubleshooting of MultiNet TCP/IP for OpenVMS 
environment.  Nearly all the services (DNS, FTP, SMTP, LPD, NTP, SNMP,
POP, etc) provided by MultiNet will be covered including NFS Server
and Client.

The workshop takes place at Syntex in Palo Alto in their conference 
center from 9am to 5pm on Sat, July 24.  Parking is in the main parking
lots next to the Hillview Ave side of Syntex (between Foothill Expressway
and Asatradero Road).

You do need to preregister by sending $25 to BAYVAX, PO Box 50444,
Palo Alto, CA 940303-0444 (Box still under our old name) or e-mail to
goldberg@davidsys.com or calling Seth Goldberg at (408)541-6834 to
indicate you will pay at the door as we need a head count in advance.
Give name, address, e-mail address, and phone number.  Checks should be
made out to BAYVAX (again, bank accounts have not been changed yet).


Seth Goldberg
BayLUG/BAYVAX Chair/Treasurer
goldberg@davidsys.com

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Jul 1993 09:25:20 GMT
From:      maas@dutiws.twi.tudelft.nl (Frank Maas)
To:        comp.protocols.tcp-ip
Subject:   Re: On the usefulness of the ident service (Was: FTP - Port # 113 - query)

atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
>In article <CADsp8.JEz@dutiws.twi.tudelft.nl> maas@dutiws.twi.tudelft.nl (Frank Maas) writes:
>
>>Another possibile use of the identity-daemon is the automated
>>user-identification for anonymous ftp. 
>
>  The data from the Ident "service" is not particularly more
>trustworthy.  A better process is to log date, time, apparent remote
>host, and apparent userid for all anonymous ftp logins.  If a problem
>arises, contact the admin of that remote host.  The log/audit files on
>that remote host are MUCH MUCH more trustworthy than any alleged IDENT
>data.  Such audit logs are certainly not completely trustworthy since
>a clever intruder will carefully edit audit/log data to cover tracks.

I think you dig your own hole. IMHO the ident-service is certainly a bit
more trustworthy than letting the user key in what he likes. Only in the
case of a hacked system the information can be bogus, in all other cases
the information will be correct and thus far more interesting than the
current system.
Whenever a system is hacked, no information of that host is trustworthy. A
hacker who is intelligent enough to disturb the working of IDENT is
certainly able to mess up the logfiles. Furthermore you don't seem to have
grasped the meaning of the statements I've made in my preceeding message:
the "attacked" host sends as much information as possible to the
"attacking" host. The manager of the latter has to look in it logfiles and
not blindly trust the information that is sent to him/her. But this is
his/her responsability, not mine.

>You all completely overlook the insecurity of the IDENT protocol itself.

Nice statement. Could you dig this out a bit deeper?

-- 
   _____                      _ _ _              
    /  '               /     ' ) ) )             |  maas@dutiws.TWI.TUDelft.NL
 ,-/-, __  __.  ____  /_      / / / __.  __.  _  |-----------------------------
(_/   / (_(_/|_/ / <_/ <_    / ' (_(_/|_(_/|_/_)_|   TWI - TU Delft - Holland

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Jul 1993 09:42:53 GMT
From:      maas@dutiws.twi.tudelft.nl (Frank Maas)
To:        comp.protocols.tcp-ip
Subject:   Re: More on the usefulness of ident (Was: FTP - Port # 113 - query)

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <22cdat$mql@cnam.cnam.fr>, bortz@cnam.cnam.fr (Stephane Bortzmeyer) writes:
>> ...
>>                                                      Before I patched
>> it, a hacker was able to log in as root on my system. log_tcp was there
>> but I only had the name of the remote site in my syslog file, not the user 
>> name.
>
>Would port 113 have done you any good?  I bet not.  In fact, from what
>you say, port 113 was easily bypassed in this particular case, as
>it would be in practially all cases that matter.

What do you mean by "port 113 was easily bypassed"? In this case, as far as
I understand, the remote site hadn't the identity daemon running, thus
providing no information at all. If the site had provided the information,
it would have been interesting information to send back to the manager of
the remote site.

>No, I would say you were crazy to run an untested, unexamined FTP
>server on a machine you care about.  In this case, "tested and
>examined" means either that you personally have examined the code, or
>that you personally know the names of a lot of good people who have
>examined the code.  

I disagree, but think that this doesn't belong in this discussion. A lot of
people I know also used that ftpserver. Are you testing and examining every
Borland product you receive? WUARCHIVE has a name and I think it is normal
that one trusts such sources. Furthermore: a security hole is very, very
difficult to find, certainly if you have to do it with "dry-testing".

>> I disagree: hiding user names seems to me yet another form of security
>> through obscurity (STO). See the FAQ of alt.security for a discussion of
>> STO. User names can be obtained by many ways, from telephone directories
>> to E-mail addresses (unless you rewrite them). They shouldn't, IMHO, be
>> used a defense line. Passwords are here for that.
>
>I agree that security through obscurity cannot be depended on, where
>what is obscure is how your system works.  However, why is keeping a
>password secret not security through obscurity, but keeping the 8
>characters required before the password not?  The username is simply
>part of the passcode that is usually not very secret.

The security of an account depends on the password. The passcode is
certainly not the pair (user, password). In my opinion it is a bit STO to
use a shadow password file, see below.
(Continuing your example: the user is your CreditCard, the password is the
personal code. It is not a secret that you have a CC, but the code, well...)

>One reason that it is prudent (but not nearly sufficient) to avoid
>broadcasting user names is that people consistently like to use
>varients of their user names as their password.  The verients can be
>obscure, and not practically detectable by the "good password
>packages", things like shifting your fingers on the keyboard or mixing
>control- or Shift- augmentations or padding with digits or control
>characters.  Of course, we all know that forcing people to use a
>password of the system's choosing is one of the least secure ways to
>run a system, because of how humans respond to having to use hard to
>remember passwords.

I agree and disagree. With this you already say that preventing the
usernames to be public is STO. It is the user's responsability to choose a
correct password not related to any other information. It is true that good
password crackers aren't always able to crack the variants, but please bear
in mind that hackers usually use the same kind of crackers.

>Security through obscurity is a useful first line of defense, a way to
>be obnoxious to make a break-in less interesting.  For example, it is
>an excellent idea to fiddle with libcrypt on your system so that the
>common password crackers do not work.

Sorry, but I don't agree on that. If you rely on STO your system is totally
hacked whenever the obscurity is broken.

-- 
   _____                      _ _ _              
    /  '               /     ' ) ) )             |  maas@dutiws.TWI.TUDelft.NL
 ,-/-, __  __.  ____  /_      / / / __.  __.  _  |-----------------------------
(_/   / (_(_/|_/ / <_/ <_    / ' (_(_/|_(_/|_/_)_|   TWI - TU Delft - Holland

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Jul 1993 12:07:20 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 <1993Jul15.202839.4064@janix.pcs.dec.com>, maass@orchis.enet.dec.com (Joerg Maass) writes:

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

-- 

OK, I was misunderstood! If HP Openview doesn't do what you want (and, since
you didn't mention it, I assume that it doesn't), try Polycenter Network
Manager (formerly DECmcc). This tool can do state-of-the-art network management
and a whole lot besides network management. See you nearest Digital
representative for details or call 1-800-DIGITAL.



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


-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 93 17:33:19
From:      pcl@ox.ac.uk (Paul C Leyland)
To:        comp.protocols.tcp-ip,comp.security.misc
Subject:   Re: Trusted servers (was Re: More on the usefulness of ident)

In article <22e7su$gu4@sol.TIS.COM> mjr@tis.com (Marcus J. Ranum) writes:

	   A second route, and one which I personally feel is more
   secure and sophisticated is to take care to configure your system
   so that the quality of the software you are running for security
   related services is irrelevant. In other words, if you're presenting
   an anonymous FTP service, consider having it run under chroot
   *BEFORE* anyone gets to talk to it. Then the thing can have a
   shell escape to root in it for all you care, and it's not going
   to hurt you. (This is not to imply that any of the sources for


Am I missing something?  If I have a root shell, even in a chroot()ed
filesystem, cannot I create device special files and from there go on
to do interesting things?

--
Paul Leyland <pcl@oxford.ac.uk>          | Hanging on in quiet desperation is
Oxford University Computing Service      |     the English way.
13 Banbury Road, Oxford, OX2 6NN, UK     | The time is come, the song is over.
Tel: +44-865-273200  Fax: +44-865-273275 | Thought I'd something more to say.
Finger pcl@black.ox.ac.uk for PGP key    |

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1993 13:34:22 GMT
From:      mjr@tis.com (Marcus J. Ranum)
To:        comp.protocols.tcp-ip,comp.security.misc
Subject:   Trusted servers (was Re: More on the usefulness of ident)

[I suggest we move this discussion to comp.security.misc where it
belongs]

>>No, I would say you were crazy to run an untested, unexamined FTP
>>server on a machine you care about.  In this case, "tested and
>>examined" means either that you personally have examined the code, or
>>that you personally know the names of a lot of good people who have
>>examined the code.  
>
>I disagree, but think that this doesn't belong in this discussion. A lot of
>people I know also used that ftpserver. Are you testing and examining every
>Borland product you receive? WUARCHIVE has a name and I think it is normal
>that one trusts such sources. Furthermore: a security hole is very, very
>difficult to find, certainly if you have to do it with "dry-testing".

	There's a basic issue here, with respect to security. It's
absolutely true that a security hole is dificult to find and that
trusted code should be "tested and examined" before being put into
use. That's often impractical in the real world.

	If, however, one is going to examine one's code before
putting it into use, I recommend using the *simplest* version of
the code you can find. I'd hate to have to read through all the
sources to the wustl ftpd!! It's absolutely humongous compared to
the BSD version - and while I haven't bothered to track the details
of its recent security hole, I'll bet a dollar to a donut that it
was a side-effect of some important new functionality or other that
was added incautiously.

	A second route, and one which I personally feel is more
secure and sophisticated is to take care to configure your system
so that the quality of the software you are running for security
related services is irrelevant. In other words, if you're presenting
an anonymous FTP service, consider having it run under chroot
*BEFORE* anyone gets to talk to it. Then the thing can have a
shell escape to root in it for all you care, and it's not going
to hurt you. (This is not to imply that any of the sources for
ftpd out on the net have shell escapes to root in them - I haven't
read all their sources. Have you?)

	In general, this is a pretty sound model for network
services across the board. It's unfortunate that there are so
many network servers that are written to run with privileges
and which almost always seem to have at least one bug.

mjr.
-- 
C++ -> C   ::  cancer -> lung

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1993 14:09:06 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: On the usefulness of the ident service (Was: FTP - Port # 113 - query)

In article <CADyz7.KMK@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
>You all completely overlook the insecurity of the IDENT protocol itself.

IDENT is no less secure than DNS, yet DNS is used a heck of a lot more
as a basis of identification.  (And even authorization)

You take every clue to incident within its context.  Logfiles can be
altered, DNS/NIS spoofed, IP traffic forged, and NFS hacked.  The more
hoops to jump through, the more likely one of them will be tripped.

--Dave
-- 
System Administrator, Penn State Population Research Institute
"I have been talking about *newsgroup* democracy, and sysadmins don't
control newsgroups." - Dick Depew

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Jul 1993 14:12:17 GMT
From:      hughes@logos.ucs.indiana.edu (larry j. hughes jr.)
To:        comp.protocols.tcp-ip
Subject:   Re: More on the usefulness of ident (Was: FTP - Port # 113 - query)

In article <j8b6vn0@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
|> The prudent will wait at least 2 or 3 years before running something 
|> like that FTP server.  Or even something like the log-tcp package.
|> Let the crazy people take the risks and experience the fun.

The same could be said for many versions of UNIX.  After upgrading to 
SunOS 4.1.3, I had to install 17 security-related patches.  

Problem is, nobody really wants to wait that long, even if there is
good reason to.

 //==================================================================\\
||      Larry J. Hughes, Jr.       |        hughes@indiana.edu        || 
||       Indiana University        | "The person who knows everything ||
||  University Computing Services  |        has a lot to learn."      ||
 \\===================================================================//

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1993 14:19:59 GMT
From:      bob@comlab.gtri.gatech.edu (Bob Baggerman)
To:        comp.protocols.tcp-ip
Subject:   Re: reliable datagram communications

Marty Leisner asks the pregnant question:
>What work has been done on reliable datagram communiations?

Just to offer a little bit different angle on all this...  I have recently
begun programming SVR4 STREAMS.  I found it interesting that the Data
Link Provider Interface (DLPI) documentation defines an acknowledged
connectionless service as well as the other two traditional services.
Of course that doesn't tell which protocols over which media (if any) are
used to provide the acknowedged connectionless service.  But the designers
must have had something in mind.

STREAMS has taken a little getting used to but overall I like the approach.
I like being able to stack various drivers along a stream.  And the Quality
of Service support could be handy in some cases.  By comparison, Sun's NIT
interface is a weird mish-mash of getmsg/putmsgs and ioctls.  But I 
digress...

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

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Jul 1993 14:45:15 GMT
From:      map@scr.siemens.com (Michael Platoff)
To:        comp.protocols.tcp-ip
Subject:   Looking for evaluation of Internet carriers

We are currently connected to the Internet and are very happy
with the quality of service.  However, I recently received a
quote from Performance Systems International (PSI) that was
substantially less than what I am currently paying.  Has someone
evaluated Internet carriers in the past?  Would someone be
willing to give me a reference for PSI?  How is their customer
service?  What is their uptime record, etc.?  Are there any
gotchas that aren't apparent in their sales literature?  I will
keep all references confidential if requested.

Thanks for your help.

Michael Platoff               email: map@scr.siemens.com
Siemens Corporate Research    phone: (609) 734-3354
755 College Road East         fax:   (609) 734-6565
Princeton, NJ 08540-6668


-- 
Michael Platoff               email: map@scr.siemens.com
Siemens Corporate Research    phone: (609) 734-3354
755 College Road East         fax:   (609) 734-6565
Princeton, NJ 08540-6668

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Jul 1993 14:57:08 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: More on the usefulness of ident (Was: FTP - Port # 113 - query)

maas@dutiws.twi.tudelft.nl (Frank Maas) writes:
>vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>
>>Security through obscurity is a useful first line of defense, a way to
>>be obnoxious to make a break-in less interesting.  For example, it is
>>an excellent idea to fiddle with libcrypt on your system so that the
>>common password crackers do not work.
>
>Sorry, but I don't agree on that. If you rely on STO your system is totally
>hacked whenever the obscurity is broken.

correction, if you rely TOTALLY on STO, your system is ....

Note that 'totally' is not commutitive.

For example, take DES, convert the output to hex and apply ROT13.  
It's questionable whether the result is more secure, but it sure 
ain't any easier.

Erick
-- 


-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 93 20:04:54
From:      oleg@gd.cs.CSUFresno.EDU (Oleg Kibirev)
To:        comp.protocols.tcp-ip,comp.security.misc
Subject:   Re: Trusted servers (was Re: More on the usefulness of ident)



In article <22e7su$gu4@sol.TIS.COM> mjr@tis.com (Marcus J. Ranum) writes:

	   If, however, one is going to examine one's code before
   putting it into use, I recommend using the *simplest* version of
   the code you can find. I'd hate to have to read through all the
   sources to the wustl ftpd!! It's absolutely humongous compared to
   the BSD version - and while I haven't bothered to track the details
   of its recent security hole, I'll bet a dollar to a donut that it
   was a side-effect of some important new functionality or other that
   was added incautiously.

Not really, I think it's inherited from old BSD ftpd. Here is a problem (from
man getpwnam).


BUGS
     All information is contained  in  a  static  area  which  is
     overwritten  by  subsequent  calls to these functions, so it
     must be copied if it is to be saved.
--

							Oleg

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Jul 1993 15:12:07 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: On the usefulness of the ident service (Was: FTP - Port # 113 - query)

In article <CAEnI9.Bz9@dutiws.twi.tudelft.nl>, maas@dutiws.twi.tudelft.nl (Frank Maas) writes:
> atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
> >In article <CADsp8.JEz@dutiws.twi.tudelft.nl> maas@dutiws.twi.tudelft.nl (Frank Maas) writes:
> >
> >>Another possibile use of the identity-daemon is the automated
> >>user-identification for anonymous ftp. 
> >
> >  The data from the Ident "service" is not particularly more
> >trustworthy.  A better process is to log date, time, apparent remote
> >host, and apparent userid for all anonymous ftp logins.  If a problem
> >arises, contact the admin of that remote host.  The log/audit files on
> >that remote host are MUCH MUCH more trustworthy than any alleged IDENT
> >data.  Such audit logs are certainly not completely trustworthy since
> >a clever intruder will carefully edit audit/log data to cover tracks.
> 
> I think you dig your own hole. IMHO the ident-service is certainly a bit
> more trustworthy than letting the user key in what he likes. Only in the
> case of a hacked system the information can be bogus, in all other cases
> the information will be correct and thus far more interesting than the
> current system.

The info is not necessarily very much more interesting or useful.
A system running reasonable accounting will log that user X started
program Y (e.g. the FTP client) at time hh:mm:ss.  Given similar logs
from the FTP server, how much more help does a port 113 service provide?

Conversely, if the FTP client does not keep good logs, how can you
think that the FTP client is the home of the bad guy?  Don't they all
know to hop around at least a little first?  If you start accusing the
owner of the account on port 113 server of computer crime based purely
on port 113 packets, I'd think you'd be risking legal actions for
defamation--even if you were right.


> Whenever a system is hacked, no information of that host is trustworthy. A
> hacker who is intelligent enough to disturb the working of IDENT is
> certainly able to mess up the logfiles.

Not necessarily.  Prudent people send running logs to other machines.
(See /etc/syslog.conf or equivalent on your favorite UNIX system.)
A bad guy might be able to kill the port 113 server on a machine
without being able to reach the logs.

>                                         Furthermore you don't seem to have
> grasped the meaning of the statements I've made in my preceeding message:
> the "attacked" host sends as much information as possible to the
> "attacking" host. The manager of the latter has to look in it logfiles and
> not blindly trust the information that is sent to him/her. But this is
> his/her responsability, not mine.
> 
> >You all completely overlook the insecurity of the IDENT protocol itself.
> 
> Nice statement. Could you dig this out a bit deeper?

Consider a few of the possible cases:
    -the FTP client is not running an auth or TAP server or anything
	else bound to port 113.  What is a poor bad guy to do?  Perhaps
	start a useful program?

    -the FTP client is running an auth server.  Can the bad guy
	kill the server?  Maybe by flooding it with requests?
	Maybe directly?

    -the FTP client is running an auth server.  Might it be effective
	to use a third machine and send TCP SYN's and so forth to the
	target (the FTP server) from the third machine, as if the
	packets came from the FTP client?  This might not work
	on ever query to port 113 by the FTP server, but would it work
	more than 30% of the time?

    -the FTP client is running an auth server.  Might it be effective
	to send the FTP client ICMP redirects to make the FTP 
	server unreachable for a short time, during which time
	a third machine can impersonate the FTP client's prot 113 
	server to the FTP server?

I'm sure there are many more, and more creative and less intrusive ways
that I don't know about.

I don't think anyone thinks port 113 servers are useless.  They can
be handy for figuring out the ultimate home of a bad guy, along with
logs and other things.  However, do you think it makes sense to permit
or deny anonymous FTP service based on what you get from the remote,
untrusted, untrustworthy FTP client?  Conversely, do you think it makes
sense to trust someone on a remote machine simply because your query to
port 113 in that direction delivers a lot of bytes?


Vernon Schryver,  vjs@sgi.com

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Jul 1993 15:30:00 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: More on the usefulness of ident (Was: FTP - Port # 113 - query)

In article <CAEoBI.CEM@dutiws.twi.tudelft.nl>, maas@dutiws.twi.tudelft.nl (Frank Maas) writes:
> ...
> >Would port 113 have done you any good?  I bet not.  In fact, from what
> >you say, port 113 was easily bypassed in this particular case, as
> >it would be in practially all cases that matter.
> 
> What do you mean by "port 113 was easily bypassed"? In this case, as far as
> I understand, the remote site hadn't the identity daemon running, thus
> providing no information at all. If the site had provided the information,
> it would have been interesting information to send back to the manager of
> the remote site.

If the site had not been running an identity daemon when the bad guy
came along, as most systems today are not running identity daemons,
what do you suppose the bad guy would do?

What about the other kludges I just listed in my other article?


> >No, I would say you were crazy to run an untested, unexamined FTP
> >server on a machine you care about.  In this case, "tested and
> >examined" means either that you personally have examined the code, or
> >that you personally know the names of a lot of good people who have
> >examined the code.  
> 
> I disagree, but think that this doesn't belong in this discussion. A lot of
> people I know also used that ftpserver. Are you testing and examining every
> Borland product you receive? WUARCHIVE has a name and I think it is normal
> that one trusts such sources. Furthermore: a security hole is very, very
> difficult to find, certainly if you have to do it with "dry-testing".

That's not entirely true.  In a carefully constructed program, security
holes very rarely happen.  You completely isolate and minimize the
places where useful things are done, and you do very few of them.  You
arrange things so that an informal proof of correctness makes sense.
That often means foregoing neat features.


> >> I disagree: hiding user names seems to me yet another form of security
> >> through obscurity (STO). See the FAQ of alt.security for a discussion of
> >> STO. User names can be obtained by many ways, from telephone directories
> >> to E-mail addresses (unless you rewrite them). They shouldn't, IMHO, be
> >> used a defense line. Passwords are here for that.
> >
> >I agree that security through obscurity cannot be depended on, where
> >what is obscure is how your system works.  However, why is keeping a
> >password secret not security through obscurity, but keeping the 8
> >characters required before the password not?  The username is simply
> >part of the passcode that is usually not very secret.
> 
> The security of an account depends on the password. The passcode is
> certainly not the pair (user, password). In my opinion it is a bit STO to
> use a shadow password file, see below.
> (Continuing your example: the user is your CreditCard, the password is the
> personal code. It is not a secret that you have a CC, but the code, well...)

Not true.  A password without an account name is useless.
A credit card account number without a name is not very useful.  The
combination of a credit card number and the right name is as good as gold.

> ...
> >Security through obscurity is a useful first line of defense, a way to
> >be obnoxious to make a break-in less interesting.  For example, it is
> >an excellent idea to fiddle with libcrypt on your system so that the
> >common password crackers do not work.
> 
> Sorry, but I don't agree on that. If you rely on STO your system is totally
> hacked whenever the obscurity is broken.

Who wrote the word "rely" or expressed any sentiment remotely similar?
Please read what I wrote.

Ultimately, everyone "relies" on security through obscurity.  What is a
password except a shared secret?  The smart trick is to pick secrets
that are easily changed, like passwords, instead of secrets that need
only be discovered once, such as encryption algorithms.  That does not
mean that you should not change your algorithms as well, particularly
where such changes cause no inconvience, such as in libcrypt for your
passwords.

There is no such thing as perfect security.  For example, everything
and anything you might do can be broken with enough rubber-hose and/or
gold cryptography.  All you can do is make the cost higher than the gain.


Vernon Schryver,  vjs@sgi.com

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1993 15:47:08 GMT
From:      mjr@tis.com (Marcus J. Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: On the usefulness of the ident service (Was: FTP - Port # 113 - query)

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>I don't think anyone thinks port 113 servers are useless.

	I do.

	I'm not convinced that getting possibly inaccurate information
is better than getting no information at all. As long as the administrator
understands that the information ident returns is "advisory" and not
guaranteed, and doesn't take action based on it, then it's OK. But
that's a long cry from saying it's useful.

	It's OK if everyone understands how easy ident is to spoof, and
uses it as a disposable tool to help try to track problems, but I'm
deeply concerned that there ARE individuals out there who don't
understand how weak a protocol it is, and who might rely on it. I'm
also not too happy to see ident coming into use because it may actually
reduce the pressure to develop a real solution. If someone wants to have
authenticated anonymous FTP, for goodness sake, use PGP or RIPEM or
PEM keys and *SOLVE* the problem.

mjr.
----/* I had this gem in my toolbox and I can't recall who wrote it... */----
#include <stdio.h>
#define NAME "brnstnd@kramden.acf.nyu.edu"
main(argc,argv)
  int argc;
  char *argv[];
{
        int lport, fport;
        if (scanf("%d , %d", &lport, &fport) != 2) {
                printf("%d, %d: ERROR: UNKNOWN-ERROR\r\n", lport, fport);
                exit(1);
        }
        printf("%d, %d: USERID: UNIX: %s\r\n", lport, fport, NAME);
        exit(0);
}
-- 
C++ -> C   ::  cancer -> lung

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1993 15:47:37 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: On the usefulness of the ident service (Was: FTP - Port # 113 - query)

In article <j8o0htk@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>Not necessarily.  Prudent people send running logs to other machines.
>(See /etc/syslog.conf or equivalent on your favorite UNIX system.)

So?  Anyone can run "logger" and forge their own logs.

>A bad guy might be able to kill the port 113 server on a machine
>without being able to reach the logs.

So?

--Dave
-- 
System Administrator, Penn State Population Research Institute
* Dog Dianetics ("Woof woof woof?  Page 725.") - Kibo

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Jul 1993 16:20:46 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: On the usefulness of the ident service (Was: FTP - Port # 113 - query)

In article <j8o0htk@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com
(Vernon Schryver) writes: 
>Consider a few of the possible cases:
>    -the FTP client is not running an auth or TAP server or anything
>	else bound to port 113.  What is a poor bad guy to do?  Perhaps
>	start a useful program?

< others deleted >

Another situation that will come up a lot is firewalls.  Here we allow
outbound connections to any machine that an internal user wants, but
only allow inbound connections below port 1024 to one machine.  It
would be a royal pain for me to have to log into that machine (since
it doesn't NFS mount file systems) to get files via anonymous FTP.  It
would also be a breach of our security to allow connections to port
113, which none of our vendors support.  I'm not going to run
something off the net for something like this.  I'm too busy to waste
my time on something that is not even a recommended practice per the
RFC's.

Ok, the above may be a little extreme, but it is a setup that is in
place today, with attitudes that are also in place today.  It
certainly is my attitude for the most part about how things are setup
here.  We don't have a sysadmin to run our systems, so I do it from
time to time.

Bottom line:  Bad idea.  If you must do it, make if for logs only.  Do
not deny service based on it.

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Jul 1993 16:35:09 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: On the usefulness of the ident service (Was: FTP - Port # 113 - query)

In article <22efmp$ei@genesis.ait.psu.edu>, barr@pop.psu.edu (David Barr) writes:
> In article <j8o0htk@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> >Not necessarily.  Prudent people send running logs to other machines.
> >(See /etc/syslog.conf or equivalent on your favorite UNIX system.)
> 
> So?  Anyone can run "logger" and forge their own logs.

No, you cannot.  You can run `logger` and add things to the logs.
That can obscure things, but it does not remove or change the
real log information.

If you can't see the logs on the remote machine, it can be difficult
(but not impossible) to fake the PID's and so forth in a way that is
difficult to notice.

> >A bad guy might be able to kill the port 113 server on a machine
> >without being able to reach the logs.
> 
> So?

So the bad guy can then start an improved port 113 server, commit
whatever dasteredly dead is possible with FTP on the target anonymous
FTP server, and leave a false trail for the complacent victims who
believe everthing that authd or TAP say.

So it is wiser to rely more on logs than a port 113 server.


As everyone continues to agree, a port 113 server is useful for finding
clues to the bad guys after an attack.  All that is at issue is whether
port 113 is useful for pre-screening anonymous FTP clients.


Vernon Schryver,  vjs@sgi.com

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Jul 1993 16:57:40 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: On the usefulness of the ident service (Was: FTP - Port # 113 - query)

In article <22efls$nds@sol.TIS.COM>, mjr@tis.com (Marcus J. Ranum) writes:
> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> >I don't think anyone thinks port 113 servers are useless.
> 
> 	I do.
> 
> 	I'm not convinced that getting possibly inaccurate information
> is better than getting no information at all. As long as the administrator
> understands that the information ident returns is "advisory" and not
> guaranteed, and doesn't take action based on it, then it's OK. But
> that's a long cry from saying it's useful.
> 
> 	It's OK if everyone understands how easy ident is to spoof, and
> uses it as a disposable tool to help try to track problems, but I'm
> deeply concerned that there ARE individuals out there who don't
> understand how weak a protocol it is, and who might rely on it. I'm
> also not too happy to see ident coming into use because it may actually
> reduce the pressure to develop a real solution.

I sympathize.  However, ident/authd/TAP would not be the first such
panacea, or FTP+authd the first such bogusly secure service.
People prefer to believe, instead of work to understand.

>                                                 If someone wants to have
> authenticated anonymous FTP, for goodness sake, use PGP or RIPEM or
> PEM keys and *SOLVE* the problem.

Why?  If you do that, you do not have an anonymous FTP server, you
have far better authentication than is typically possible between
server and client.


What I do not understand is why people care about port 113 for
anonymous FTP.  Maybe port 113 is mildly interesting and vaguely useful
for normal FTP, rlogin, telnet, rsh, rexec, and LAT (yes, LAT, why
not?), where you want to authenticate the user to know what is authorized.

Anonymous FTP is supposed to be used when you don't know and do not
trust the other guy.  That's why it's called anonymous FTP.  That's why
standard, commercial ftpd code (i.e. BSD) goes to such paranoid lengths
to offer such restricted services in such a controlled environment.
It seems impolite to me to even want to determine the real identity of
people using an anonymous service; it seems gauche to advertise
(e.g. in the system banner) that an anonymous service is not anonymous.
If you don't want to offer anonymous FTP, then don't.  Tell prospective
users to contact you for a user name and password.

Oh, well.  I guess one common cause is the diease I call sysadminitis,
which is characterized by delusions of technical omniscience, personal
superiority, and compulsions to monitor and control everything and
everyone.  


Vernon Schryver,  vjs@sgi.com

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1993 13:42:51 +0200
From:      szymon@galaxy.uci.agh.edu.pl (Szymon Sokol)
To:        comp.protocols.tcp-ip
Subject:   Re: On the usefulness of the ident service (Was: FTP - Port # 113 - query)

Ran Atkinson (atkinson@itd.nrl.navy.mil) wrote:
:   The data from the Ident "service" is not particularly more
: trustworthy.  A better process is to log date, time, apparent remote
: host, and apparent userid for all anonymous ftp logins.  If a problem
: arises, contact the admin of that remote host.  The log/audit files on
: that remote host are MUCH MUCH more trustworthy than any alleged IDENT
: data.  Such audit logs are certainly not completely trustworthy since
: a clever intruder will carefully edit audit/log data to cover tracks.

If they manage to get root access on a 'host' machine (to spoof IDENT server)
they will certainly purge logs! But IDENT is still useful if the intruder
do not have root access, so that system manager of the 'target' machine
can inform managers of the 'host' whom should they investigate...
-- 
U     U  M     M  M     M  Szymon Sokol -- Network Manager
U     U  MM   MM  MM   MM  University of Mining and Metallurgy, Computer Center
U     U  M M M M  M M M M  ave. Mickiewicza 30, 30-059 Krakow, POLAND
 UUUUU   M  M  M  M  M  M  TEL. +48 12 338100 EXT. 2885    FAX +48 12 338907

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Jul 1993 18:02:56 GMT
From:      jdd@cdf.toronto.edu (John DiMarco)
To:        comp.protocols.tcp-ip
Subject:   Re: On the usefulness of the ident service (Was: FTP - Port # 113 - query)

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

>As everyone continues to agree, a port 113 server is useful for finding
>clues to the bad guys after an attack.  All that is at issue is whether
>port 113 is useful for pre-screening anonymous FTP clients.

Yes, only for client machines where root@machine is trusted, but
user@machine isn't.  If I have a service that is set up to accept
connections only from a list of known machines, and if I trust
root@machine (but not necessarily user@machine) for each machine in the
list, then I can trust the ident service enough to permit/deny access to
the service on the basis of an ident query.

It is quite useless for random.machine.internet, since there is no indication
that "root"@random.machine.internet is any more trustworthy than any random
user on that machine, if even "root" exists (it doesn't for PC's running
eg. DOS, for example). 

Regards,

John
--
John DiMarco                                              jdd@cdf.toronto.edu
Computing Disciplines Facility Systems Manager            jdd@cdf.utoronto.ca
University of Toronto                                     EA201B,(416)978-1928

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1993 19:27:21 GMT
From:      agulbra@nvg.unit.no (Arnt Gulbrandsen)
To:        comp.protocols.tcp-ip,comp.security.misc
Subject:   Re: Trusted servers (was Re: More on the usefulness of ident)

In article <PCL.93Jul19173319@rhodium.ox.ac.uk> pcl@ox.ac.uk (Paul C Leyland) writes:
>Am I missing something?  If I have a root shell, even in a chroot()ed
>filesystem, cannot I create device special files and from there go on
>to do interesting things?

If you can mknod(), yes.  You need either a compiler, a program which will
mknod() for you, or the ability to ship in your own binaries.  Or if you
have mount, you can mount the real root disk or some NFS disk you build
yourself and chroot() again.

However, I'd like to hear more about one specific question:  How can running
ident make the situation _worse_ than it is presently?  I realise that it's
not even nearly perfect, but small improvements are improvements too.

-- 
Arnt Gulbrandsen, agulbra@nvg.unit.no
The perpetual double-sig newbie.
-- 
Arnt Gulbrandsen, agulbra@nvg.unit.no

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1993 19:33:37 GMT
From:      paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CCSO)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: On the usefulness of the ident service (Was: FTP - Port # 113 - query)

I would like to see Ident service made available in our Cisco terminal 
servers.  On a busy host (14,000 accounts, 250 active users), correlating
the Unix login with a particular terminal server port after the fact is
nearly impossible.  Terminal server logins are based on the campus
white pages entry which seldom has exact correspondence with the UNIX login
name.

We find the ident service useful.  Bright hackers are not our problem.
The wannabes are our big problem.  Ident works very well at keeping
them under control.

Security is adequate for our needs.  Syslog is configured to report to
a non-user host.

/pbp
-- 
As CSO, Service was our middle name.  Now as CCSO, it's next to last.
	-- Anonymous	(btw, :-) for the humor-impaired)

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Jul 1993 20:11:47 GMT
From:      maas@dutiws.twi.tudelft.nl (Frank Maas)
To:        comp.protocols.tcp-ip
Subject:   Re: On the usefulness of the ident service

I was planning on summarizing, but it seems I will only summarize me and
Vernon Schryver. Well, who cares.

In the first place: let's state clearly that I have never said something
about restricting access to users based on the information provided by the
identity daemon. If you read my postings carefully I said that the
information is only to be used as an aid and is not to be relied upon.

VS> The info is not necessarily very much more interesting or
VS> useful. A system running reasonable accounting will log that
VS> user X started program Y (e.g. the FTP client) at time
VS> hh:mm:ss.  Given similar logs from the FTP server, how much
VS> more help does a port 113 service provide?

If you login as anonymous ftp client, you should type your e-mail address as 
a password. A lot of users don't type this in at all, which is not a "hack"
but simply lazyness or trying to be really anonymous. This kind of sessions
can be better logged with the information of the identity-daemon. In
reverse you aren't going to ask the remote sysadmin for his logs wheneve a
John Doe does an ftp session.

VS> onversely, if the FTP client does not keep good logs, how
VS> can you think that the FTP client is the home of the bad
VS> guy?  Don't they all know to hop around at least a little
VS> first?  If you start accusing the owner of the account on
VS> port 113 server of computer crime based purely on port 113
VS> packets, I'd think you'd be risking legal actions for
VS> defamation--even if you were right.

When we are talking about an ftp-session, false 113 information won't have
any effect I think. In the case of attacks, the information is sent to the
system administrator of the remote system. It is his/her responsability to
use the information in a good way.

VS> Not necessarily.  Prudent people send running logs to other
VS> machines. (See /etc/syslog.conf or equivalent on your
VS> favorite UNIX system.) A bad guy might be able to kill the
VS> port 113 server on a machine without being able to reach the
VS> logs.

Nope. The identity server is launched when a request is made. It is
launched under a certain userid (can be root, or something else) so
somebody who kills the server has special permissions.

VS>     -the FTP client is not running an auth or TAP server or
VS> anything else bound to port 113.  What is a poor bad guy to
VS> do?  Perhaps start a useful program?

...providing bogus information. That won't mind. I never trust the
information, though send it to the sysadmin out there. Let him handle it.

VS> Not true.  A password without an account name is useless.
VS> A credit card account number without a name is not very
VS> useful.  The combination of a credit card number and the
VS> right name is as good as gold.

An account without a password is useless as well. When I mentioned the CC
code I meant the personal id code (4 figures).

VS> > Sorry, but I don't agree on that. If you rely on STO your s
VS> > hacked whenever the obscurity is broken.
VS> 
VS> Who wrote the word "rely" or expressed any sentiment
VS> remotely similar? Please read what I wrote.

You didn't, it was a general you. But if you talk about rewriting libcrypt
in stead of trying to crack the passwords of your users and preventing
others from cracking in this way, you won't be surprised if somebody hacks
libcrypt the same way as you and cracks every password in the book.


-- 
   _____                      _ _ _              
    /  '               /     ' ) ) )             |  maas@dutiws.TWI.TUDelft.NL
 ,-/-, __  __.  ____  /_      / / / __.  __.  _  |-----------------------------
(_/   / (_(_/|_/ / <_/ <_    / ' (_(_/|_(_/|_/_)_|   TWI - TU Delft - Holland

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Jul 1993 20:37:09 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Can I use TCP/IP over satellite links?

In article <1993Jul17.002644.12699@cs.aukuni.ac.nz> rale1@cs.aukuni.ac.nz (Ross Douglas Alexander) writes:
   The delays to nic.ddn.mil (which I use as an ftp site) can often be
   10 times worst than above (eg 5 to 10 secs delay).  This makes ftp
   real slow and interactive work impossible.

The Internet's links to nic.ddn.mil, and possibly the machine itself,
are always overloaded.  Nobody gets good FTP performance, even
campuses with T1 links only a few hops off the T3 backbone.  You'll be
better off finding the same stuff mirrored elsewhere.

   This is not to say that TCP does not work.  No transport protocol
   works well with such large (and variable) delays.  For ftp, mail
   and news it does not matter since almost all is done in the
   background.

A modern TCP, incorporating the performance extensions described in
RFC 1323, should be able to accomodate high and moderately variable
latency as well as it can possibly be accomodated.  Yes, your
interactive responsiveness and your ping times will be terrible, but
that's just the laws of physics working against you.  But your
throughput needn't be so badly affected by latency.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 93 20:54:34 GMT
From:      mercer@odin.control.utoronto.ca (Jim Mercer (Guest))
To:        comp.protocols.tcp-ip,bit.listserv.novell,comp.sys.novell,biz.sco.general,comp.dcom.lans.ethernet
Subject:   SMC EISA ethernet card

i now have 3 of these (Elite 3200?) cards.

originally we were going to use them in our novell server, but the Novell 3.11
drivers they provided were a bit flakey. (about 16 months ago)

i remember that there were new drivers issued, but since we had the box
up and running using 2 16 bit controllers, i haven't worried about it.

does anyone have any experience using these cards, with both ports active
in a Novell 3.11, 4.0 or SCO ODT [23].0 environment?

also, if you have the drivers for Novell, can someone put them up for ftp
like the SuperDisk 4.6?

-- 
[ Jim Mercer   Reptilian Research  merce@iguana.reptiles.org  +1 416 506-0654 ]
[                "Clickity-Click, Barba-Trick" - The Barbapapas               ]

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1993 01:26:19 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: Trusted servers (was Re: More on the usefulness of ident)

In article <MS-C.743114292.1103527590.mrc@tomobiki-cho.cac.washington.edu> Mark Crispin <mrc@Tomobiki-Cho.CAC.Washington.EDU> writes:
>Running ident can make the situation worse than it is presently, by
>introducing false data.

Minor nitpick.  Running ident doesn't introduce any false data.  It is
the use of ident on the other end that could lead to false data.

>Noise in data is as much of a contributor to the loss
>of data quality as missing data.

I take exception that ident data is 'noise'.  Yes, it is extra data
that could be forged, but in typical logs there is lots of forgeable
data (and by your definition, 'noise' as well).  Take sendmail mail
logs for example.  Do you trust the from= line in the logs?  Of course
not.  To people propose taking it out of the logs simply because it
isn't trustworthy?  Of course not.  They provide useful information
given the context of the log.  The same goes for ident.

Take hostnames as another example.  Your tcp wrapper log just reported a
telnet connection from sneaky.lcs.mit.edu.  How do you know?  Well,
DNS says so.  How do you know DNS hasn't been falsified?  You don't,
but it at least provides a place from which to start.  The same goes
for ident.

--Dave
-- 
System Administrator, Penn State Population Research Institute
sync your disks three times and say: "There's no place like $HOME"

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Jul 1993 01:58:45 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Trusted servers (was Re: More on the usefulness of ident)

> Mark Crispin <mrc@Tomobiki-Cho.CAC.Washington.EDU> writes:
>Running ident can make the situation worse than it is presently, by
>introducing false data.  Noise in data is as much of a contributor to the loss
>of data quality as missing data.

I disagree strongly.  Faking ident is important in that a person who
does it will do so repeatedly, and that can prove very useful to you.

In several recent police investigations we were able to track the
accuseds' actions by watching for patterns that identified them almost
like a fingerprint.  Consistant ident faking would be just one more handy 
thing to check for.  It also tells you that you have someone being 
purposefully mischieveous and not just a victim of a wrong keypress.

But even if you don't have to solve a crime,  you will find 
that security-breaking people tend to be careless and
will probably fake ident for a month before and after a break-in.  So
what?  You can catch these people and use U.Washington's computer user
policies to take action against the bad guy, as many schools treat on-campus
computer attacks as an academic office whereas the other offenses may
be harder to prove or may not fit the policies directly.

Erick
-- 


-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Jul 1993 03:54:59 GMT
From:      Deven
To:        comp.protocols.tcp-ip
Subject:   Questions regarding METRIC in IFCONFIG and ROUTE

Hi, 

	I had posted this about a month ago, but have not received
	any response.  I hope the article made out to the Net.
	Any response will be appreciated.

Thanks
-Deven
July 18, 1993
===========================================================================

Hi,

	I have a few questions related to METRIC as used in the
	IFCONFIG and ROUTE commands, as also how it compares with 
	the METRIC in a dynamic route.

Background:
	The man page for IFCONFIG states that the metric argument
	"Sets the routing metric of the interface to n, default 0.  Higher 
	metrics have the effect of making a route less favorable; metrics 
	are counted as additional hops to the destination network or host."

	The man page for the ROUTE command states that "The metric 
	argument indicates the number of "hops" to the destination.
	The metric is required for add commands; it must be zero
	if the destination is on a directly-attached network,
	and nonzero if the route utilizes one or more gateways."

Question 1: 
	What is the relationship between the metric (hops) in the ROUTE 
	command and what is placed in the IP TTL field?

Question 2: 
	What is the maximum value that can be specified for METRIC
	in the IFCONFIG command?

Question 3:  
	What is the difference between the METRIC argument for the 
	IFCONFIG command and the METRIC argument for the ROUTE command?

Question 4:
	I understand that ROUTED  makes use of the metric specified 
	for a given interface.   Let us say that the route propagated by 
	ROUTED has a metric of x (after allowing for the metric for that 
	particular interface).  Would it be possible to override the metric 
	of the route given by ROUTE by adding a static route with a metric 
	of y (where y < x)?  

	If so, what would be the effects if some administrator (of another 
	network) sets up an arbitrarily high value for an interface on his 
	machine (which is a gateway), to prevent others from using it as a 
	gateway?  Would a static route on the originating machine, if 
	installed with a lower metric, take precedence?
	

Thanks for any information.
-Deven 
--
"To learn, and at due times to repeat what one has learned, is that not,
 after all, a pleasure?"		-- Confucius



-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Jul 1993 09:59:49 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: On the usefulness of the ident service (Was: FTP - Port # 113 - query)

In article <22e1brINN9d@galaxy.uci.agh.edu.pl> szymon@galaxy.uci.agh.edu.pl (Szymon Sokol) writes:

>If they manage to get root access on a 'host' machine (to spoof IDENT server)
>they will certainly purge logs! But IDENT is still useful if the intruder
>do not have root access, so that system manager of the 'target' machine
>can inform managers of the 'host' whom should they investigate...

REPEAT 
  One does NOT need root access in order to spoof the IDENT service !
  One does NOT need root access in order to spoof the IDENT service !
  One does NOT need root access in order to spoof the IDENT service !
UNTIL you understand that root access is NOT needed to spoof IDENT

One DOES need root access in order to purge audit logs.



-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Jul 1993 10:02:37 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: On the usefulness of the ident service (Was: FTP - Port # 113 - query)

In article <22e9u2$pnf@genesis.ait.psu.edu> barr@pop.psu.edu (David Barr) writes:

>IDENT is no less secure than DNS, yet DNS is used a heck of a lot more
>as a basis of identification.  (And even authorization)

False.

  There are ways that one can confirm that offered DNS information is
valid because there are multiple independently operated DNS servers,
even at the root level.  One cannot confirm that offered IDENT
information is believed to be valid by more than one system because
the IDENT service is not replicated or particularly replicatable.





-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Jul 1993 11:58:53 GMT
From:      randy@chinet.chinet.com (Randy Suess)
To:        comp.protocols.tcp-ip
Subject:   packet driver for gateway card


	Someone just dropped a bunch of 8 and 16bit Gateway ethernet
	cards in my lap.  Says Gateway Communications G/ETHERNET AT
	on them.  Seems to use the same chip as the wd8003, a
	83908N??  Is there a packet driver available for this card?
	I did a quick glance thru the simtel packet listings, but
	nothing found specific for this card.
	Thanks for any info.
-- 
	I am created Shiva the Destroyer; Death, the shatterer of worlds!
	Who is this dog meat who stands before me now?
	That's the biz, sweetheart.
Randy Suess					 randy@chinet.chinet.com

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1993 13:19:35 GMT
From:      ethan@brock.css.gov (Ethan Brown)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Looking for ROM-able IP stack

Hi.  Where I work (not the above address), I have been given the
(not so) enviable task of implementing a LAN boot on a PC clone, using custom
LAN hardware.  I am planning
on using BOOTP and TFTP to do the downloading.

What I am looking for is pointers to a ROM-able UDP/IP stack (I don't need
TCP, thank god).  I need ARP and IP, and possibly ICMP.  I will have a data
link layer, so this would be above that level in the stack.  Any pointers
would be appreciated, esp. pointers to available code or code fragments.

Please respond via E-mail as I don't get out here enough to keep up with
the newsgroups, plus I don't really read these groups.  Thanks a lot.


Scott "The Pseudo-Hacker" Neugroschl
secssxn@mx.secs.csun.edu
SnailMail:	8000 Woodley Ave, M/S 44-55
		Van Nuys, CA 91409
Phone: 818-902-4507   FAX 818-902-4528


-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 93 14:30:00 GMT
From:      joubert@teldata.UUCP (joubert)
To:        comp.protocols.tcp-ip
Subject:   help with pcroute please

I am in need of some help setting up pcroute.  Here is the what I am trying to
accomplish:

We have two ethernet networks at two different locations.  I want to connect
the two.

    Network A  (192.9.200.x)         Network B  (192.9.201.x)
                255.255.255.0                    255.255.255.0
----------------------------    ------------------------------------

      +----------+                   +----------+
      | Router A |                   | Router B |
      +----------+                   +----------+
                  \__ Phone Line ___/

Router A is set up as:               Router B is set up as:
192.9.200.81                         192.9.201.5
The slip connection on               The slip connection on
router A is:                         router B is:
192.9.202.1                          192.9.202.2

On router A I have the               On router B I have the
default route set up                 default route set up
to go to 192.9.202.2                 to go to 192.9.202.1


It just does not seem to want to work.  Any ideas?

I can ping router A on network A and I can ping router B on network B.
But that is it.  When I ping from network A to a station on network B
I can see that something is being sent over the modem.  BUT when I ping
from network B to some station on network A I see nothing going over the
modem.  What am I doing wrong?

Any help would be grealy appreciated.

                    Joubert
-- 
Joubert Berger                   | Email:  
Teldata Computer Industries, Inc.| joubert@teldata.uucp
Atlanta, Georgia  (404) 256-2166 | joubert%teldata.uucp@mathcs.emory.edu
                                 | {rutgers,ogicse,gatech}!emory!teldata!joubert

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1993 02:33:14 -0700
From:      skl@Connectivity.com (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: unknown vendor address

In article <22he7g$mie@gazette.bcm.tmc.edu>, salzberg@kiwi.imgen.bcm.tmc.edu
 (Benjamin Salzberg) wrote:
>which vendor has the prefix  00-00-94 ?

According to the 8-Apr-93 version of ftp.lcs.mit.edu:pub/map/EtherNet-codes
the vendor is Asante.

>any specific devices ?

They used to be Macintosh-specific, but now they also make PC products.

...Sam
-- 
<skl@Connectivity.com> -- Connectivity Technology Inc.

"NetNews on CD's" product information: <NewsCD@CDPublishing.com>


-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1993 14:54:13 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: On the usefulness of the ident service (Was: FTP - Port # 113 - query)

In article <CAGJwD.Mrs@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
>
>In article <22e9u2$pnf@genesis.ait.psu.edu> barr@pop.psu.edu (David Barr) writes:
>
>>IDENT is no less secure than DNS, yet DNS is used a heck of a lot more
>>as a basis of identification.  (And even authorization)
>
>False.
>
>  There are ways that one can confirm that offered DNS information is
>valid because there are multiple independently operated DNS servers,
>even at the root level.

So?  For a given zone, only one is the master.  How is an "independently
operated DNS server" supposed to know that the data the master is feeding
it is valid?  It doesn't.

>One cannot confirm that offered IDENT
>information is believed to be valid by more than one system because
>the IDENT service is not replicated or particularly replicatable.

But there still is a single corruption point.  Granted there are less
corruption points than with IDENT, but there are more ways to corrupt
DNS than just corrupting the master.

--Dave
-- 
System Administrator, Penn State Population Research Institute
lose: v. to miss from one's possession.
loose: n. not securely fastened.  v. to set free.

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Jul 1993 15:45:17 GMT
From:      s29@osiris.cso.uiuc.edu (R Mills)
To:        comp.protocols.tcp-ip
Subject:   Looking for tcp/ip & nfs for AT&T SYSV/386 r3.2.x

Hello All,

I am looking for sources to purchase TCP/IP and NFS to run
on AT&T SYSV/386 3.2.x.  NCR has just tripled their prices and I
need other sources for TCP/IP and NFS  (Public domain as well).

If you know where I can get it or who I can call to ask, please e-mail me.
I do not read this group so email to   don@scsmo1.attmail.com

Thanx!

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Jul 1993 16:42:21 GMT
From:      chris@marvin.ag.uidaho.edu (Chris Magagna)
To:        comp.protocols.tcp-ip,bit.listserv.novell,comp.sys.novell,biz.sco.general,comp.dcom.lans.ethernet
Subject:   Re: SMC EISA ethernet card

Hey Jim,  I tried to send mail to your odin address and it bounced back with 
something about an illegal entry in your .forward, so:

In article <1993Jul19.165433.11544@jarvis.csri.toronto.edu> mercer@odin.control.utoronto.ca (Jim Mercer (Guest)) writes:
>does anyone have any experience using these cards, with both ports active
>in a Novell 3.11, 4.0 or SCO ODT [23].0 environment?

Can't vouch for 4.0 or SCO, but we've been using them in our 3.11 server 
since we got it in September of 1992.  We've got 4 of them in it and both 
ports on all cards have been active since April.  No problems with the 
cards, other than until the last release of the driver they wouldn't speak 
AppleTalk (which didn't matter to us, since we just added NW4Mac a month 
ago).

>also, if you have the drivers for Novell, can someone put them up for ftp
>like the SuperDisk 4.6?

I've just put the server driver, smce32.lan on marvin.ag.uidaho.edu for 
anon. ftp in /users/ftp/upload.  It's the most current I know about, 
3/19/93.  If you need any of the other files email me and I'll dig them up 
and zip them for you.

>[ Jim Mercer   Reptilian Research  merce@iguana.reptiles.org  +1 416 506-0654 ]
>[                "Clickity-Click, Barba-Trick" - The Barbapapas               ]

Chris

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Jul 93 16:59:55 GMT
From:      twriter@rd.hydro.on.ca (Timothy Writer)
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:   Re: TCP/IP & Windows 3.1

kumar@sloop.cis.ufl.edu (SHASHANK KUMAR) writes:

>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.

Sorry, I can't answer your question, but if you want to run X Windows
applications under Windows, I can make a recomendation: XVision.
Contact vware@visionware.co.uk for further information.

Tim

P.S. I am in no way affiliated with VisionWare, I'm just a very
satisfied customer.

-- 
Tim Writer			     phone:  (416) 207-6990
Ontario Hydro Research Division	     fax:    (416) 237-9285
Toronto, Ontario		     e-mail: twriter@rd.hydro.on.ca
CANADA

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Jul 1993 17:04:04 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Ftplib announce

In article <22gutb$1ev@lpuds.oea.ihep.su> orel@lpuds.oea.ihep.su (Oleg Orel) writes:
>Last sources of ftplib aviable in ftp@lpuds.oea.ihep.su:/lib/ftplib

I can't seem to lookup that address from here.  Do you have an IP
address for this host, or is there someplace else that has been able
to snag a copy of it?

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1993 18:16:00 GMT
From:      mathur@umbc.edu (Mr Ashish K Mathur (CMSC Grad))
To:        comp.protocols.tcp-ip
Subject:   Connecting thru TCP/IP on Win-OS/2


Hi,
A friend of mine is trying to connect thru TCP/IP on Win-OS/2.
But apparently is encountering some problems. 

Can some GURU throw some light on the matter. 

Any suggestions regarding the setup are most welcome.

Thanks in advance.

Ashish

________________________________________________________________________________

Ashish K Mathur

Computer Science Department
University of Maryland, Baltimore County
5401 Wilkens Avenue,
Baltimore, Maryland 21228

Phone : (Home) (410)247-7340            email : ashish@cs.umbc.edu      (UNIX)
        (Work) (410)455-2111                    mathur@umbc.edu         (IRIX)
        (Dept) (410)455-3000                    MATHUR@UMBC2.UMBC.EDU   (VMS)
________________________________________________________________________________


-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Jul 1993 18:33:01 GMT
From:      hancock@tigger.geg.mot.com (Don Hancock x2712)
To:        comp.protocols.tcp-ip
Subject:   Reset of TCP-IP server connection.



Got a problem with some low level tcp-ip software.

How do you know if your connection is broken when your client is killed
via power off?  It's in the Berkeley TCP-IP software packaged with
VxWorks.  We have to 680x0 boards using an ethernet interface and we
power one board off.  The live board has a server socket and he thinks
the client is still there (forever).  What we want is a way to
automatically know if the client dies.  Thanks for your help.  Email
please to hancock@mack.geg.mot.com or post.






---
Don Hancock



-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1993 18:40:48 GMT
From:      salzberg@kiwi.imgen.bcm.tmc.edu (Benjamin Salzberg)
To:        comp.protocols.tcp-ip
Subject:   unknown vendor address



hi,

which vendor has the prefix  00-00-94 ?
any specific devices ?


thanks, 

beni 


-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Jul 1993 18:59:49 GMT
From:      madabusi@csvaxe.csuohio.edu
To:        comp.protocols.tcp-ip
Subject:   Problem with NCSA Telnet. Help!!!





Hi Netters:

		One of our faculty has installed a DEC Ethernet card 
(DEC Etherworks DE-203) in his DEC PC, got NCSA Telnet public Domain software
assigned a valid IP Address and installed other software. But when he tries to
telnet even to the localhost, it's giving an error message as follows.

message: local host or gateway not responding.

		When he tried with other telnet software, everything works
fine. He has NCSA Telnet 2.3.06 version, MAC/DIS Packet driver converter
loaded version 1.09 by Ftp Software.

		Any advice or info on this issue will be greatly appreciated.

		Please e-mail your responses to sudha@garfield.csuohio.edu or 
		madabusi@csvaxe.csuohio.edu


Sudha.

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1993 19:46:11 GMT
From:      bjaspan@GZA.COM (Barry Jaspan)
To:        comp.protocols.tcp,comp.unix.bsd,comp.unix.wizards
Subject:   Multiple IP addresses on a single interface?

Is it possible to configure a SunOS 4.x kernel to respond to multiple IP
addresses on a single ethernet interface?

Looking over the BSD network code, each interface structure (struct ifnet)
seems to maintain a linked list of addresses, not just one.  Also, the code
for the SIOCSIFADDR ioctl seems to append its address argument to the end of
the list.  But SIOCGIFADDR only returns a single address, and it isn't clear
to me how to set multiple addresses.  ifconfig, clearly, doesn't support
multiple addresses directly.

Any information is appreciated.  Thanks.

-- 
Barry Jaspan, bjaspan@gza.com
Geer Zolot Associates

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Jul 1993 21:11:34 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: On the usefulness of the ident service (Was: FTP - Port # 113 - query)

In article <CAGJwD.Mrs@ra.nrl.navy.mil>, atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
> In article <22e9u2$pnf@genesis.ait.psu.edu> barr@pop.psu.edu (David Barr) writes:
> 
> >IDENT is no less secure than DNS, yet DNS is used a heck of a lot more
> >as a basis of identification.  (And even authorization)
> 
> False.
> 
>   There are ways that one can confirm that offered DNS information is
> valid because there are multiple independently operated DNS servers,
> even at the root level.  One cannot confirm that offered IDENT
> information is believed to be valid by more than one system because
> the IDENT service is not replicated or particularly replicatable.


There are no more than ways to try to confirm offered DNS information
with what you hope are multiple independently operated DNS servers.
Since DNS includes no authentication mechanisms, you are limited to
hoping you're exchanging packets with what you think you are.

Of course, that's usually a good bet, particularly if you trust your
local network and your links to the greater Internet.  And even more if
you notice source routes.

It is also entirely different from what IDENT offers, which is as you
say, as well as suffering from the same problems of trusting the
address in the IP header.


Vernon Schryver, vjs@sgi.com

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Jul 1993 21:39:02 GMT
From:      russell@ccu1.aukuni.ac.nz (Russell Fulton)
To:        comp.protocols.tcp-ip
Subject:   Re: Ftplib announce

imp@boulder.parcplace.com (Warner Losh) writes:

>In article <22gutb$1ev@lpuds.oea.ihep.su> orel@lpuds.oea.ihep.su (Oleg Orel) writes:
>>Last sources of ftplib aviable in ftp@lpuds.oea.ihep.su:/lib/ftplib
 
>I can't seem to lookup that address from here.  Do you have an IP
>address for this host, or is there someplace else that has been able
>to snag a copy of it?

Server:  ccvcom.aukuni.ac.nz
Address:  130.216.1.2

Non-authoritative answer:
Name:    lpuds.oea.ihep.su
Address:  192.102.229.78

-- 
Russell Fulton, Computer Center, University of Auckland, New Zealand.
<rj_fulton@auckland.ac.nz>

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Jul 1993 23:18:51 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Ftplib announce

In article <1993Jul20.213902.1612@ccu1.aukuni.ac.nz> russell@ccu1.aukuni.ac.nz (Russell Fulton) writes:
>Name:    lpuds.oea.ihep.su
>Address:  192.102.229.78

I get "Host unreachable" when I try this address.  It seems to be
coming from the NFS backbone at ucar:
 1  troll.Boulder.ParcPlace.COM (192.245.99.65)  10 ms  10 ms  10 ms
 2  ucb-annex.csn.org (128.138.213.20)  2310 ms  2520 ms  1940 ms
 3  cu-gw.Colorado.EDU (128.138.213.254)  1910 ms  2290 ms  320 ms
 4  ncar-ucb.CO.westnet.net (129.19.254.45)  210 ms  220 ms  1380 ms
 5  enss.ucar.edu (192.43.244.10)  280 ms !H  2740 ms !H  1890 ms !H

Any ideas why that might be?  I don't have problems getting to
anyplace else....

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1993 18:19:23 +0400
From:      orel@lpuds.oea.ihep.su (Oleg Orel)
To:        comp.protocols.tcp-ip
Subject:   Ftplib announce

Last sources of ftplib aviable in ftp@lpuds.oea.ihep.su:/lib/ftplib

If any archive manager archived library in your archive in europe or USA
please informing world and me about it.

Thanks

-- 
---------------------------------------------------------------------------
| Oleg Orel, Russia, Protvino       |   orel@lpuds.oea.ihep.su            |
| Institute of High Energy Physics  |   Home Phone: 49106                 |
---------------------------------------------------------------------------

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1993 18:23:04 +0400
From:      orel@lpuds.oea.ihep.su (Oleg Orel)
To:        comp.protocols.tcp-ip
Subject:   Last modification of ftplib


In functions FtpGood & FtpCommand insert using varargs, and all problem
with transfer parameter cleaning

In function syntax added insert zero at the and of ruslting strings.


-- 
---------------------------------------------------------------------------
| Oleg Orel, Russia, Protvino       |   orel@lpuds.oea.ihep.su            |
| Institute of High Energy Physics  |   Home Phone: 49106                 |
---------------------------------------------------------------------------

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Jul 1993 01:36:45 GMT
From:      mike@gordian.com (Michael A. Thomas)
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:
|> 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.

   I have wondered about this. Isn't this a rather implementation
specific thing, and thus violates the principle of liberal-receive
conservative-send? I could conceivably see a TCP which receives
already acknowledged data into its buffer (for which, say, the
user has not already taken possetion of it) on the assumption
that if the sending TCP is sending a packet with data in it,
acknowledged or not, it ought to be correct if the checksums
etc. are kosher. It might not be in the receivers best interest
implementationwise, but I can't imagine why it would be bogus
otherwise.
   Am I being overly prudish here, or does this sound suspect
to anybody else?
-- 

		Michael Thomas	(mike@gordian.com)
	"I don't think Bambi Eyes will get you that flame thrower..."  
		-- Hobbes to Calvin
		USnail: 20361 Irvine Ave Santa Ana Heights, Ca,	92707-5637
		PaBell: (714) 850-0205 (714) 850-0533 (fax)

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1993 03:35:35 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Ftplib announce

It was said here a few months ago that NSFnet was not routing packets
to the .su sites.  CIX was, as were at least some European nets.

The best short-term solution is to get someone in Europe or on CIX to
set up another FTP site.  The long-term solution would be to get NSFnet
to change the routing policy.

The accuracy of this information is likely to be low.  Not only is it
old and second-hand, it is second-hand from the net.

       Stephen

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

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1993 03:45:42 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Zero-window probing

In article <1993Jul21.013645.25062@gordian.com> mike@gordian.com (Michael A. Thomas) writes:
>I could conceivably see a TCP which receives already acknowledged data
>into its buffer...on the assumption that if the sending TCP is sending
>a packet with data in it, acknowledged or not, it ought to be correct
>if the checksums etc. are kosher.

There are practical limits to the "be conservative" rule.  This is one
of them.  Yes, you are strictly correct.  However, there are many reasons
why such copying is not likely to take place:

   - The TCP spec refers to throwing away already-acked data in a
     packet.  It is not mandated, but suggested as a model.
   - The extra copy is silly.  It slows down the TCP and buys you
     _nothing_ in accuracy.
   - RFC-1122 specifically refers to "garbage" octets.  If I were a
     TCP implementor considering this, that word would make me worry.
   - Paying attention to already-acked data weakens the old-duplicate-
     rejection rules.

>   Am I being overly prudish here, or does this sound suspect
>to anybody else?

IMHO, you're correct with the spirit of the "be conservative/liberal"
rule, but the letter of the law is strong enough here that just sending
a garbage octet (which is already being tolerant of broken TCPs) is
sufficient conservatism.

I think sending a garbage octet is OK.  Unless someone can cite a
released TCP with such awful behavior, I don't think it's worth
defending against.

        Stephen

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

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Jul 1993 13:20:49
From:      todd.young@stpaul.ncr.com (Todd Young)
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:   Re: TCP/IP & Windows 3.1

In article <221uipINNfts@snoopy.cis.ufl.edu> kumar@sloop.cis.ufl.edu (SHASHANK KUMAR) writes:
>From: kumar@sloop.cis.ufl.edu (SHASHANK KUMAR)
>Subject: TCP/IP & Windows 3.1
>Date: 14 Jul 1993 21:41:45 GMT
>Summary: WinQVT
 
>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.                    /

It sounds like you want an MDI type of application. You might want to check 
out Wollongong ACCESS. It offers a very nice telnet appl that supports 
a number of concurent Telnet, TN3270, and FTP sessions. 






Todd Young           Todd.Young@St.Paul.NCR.com
NCR Corp. 
612-638-7582
"What, Me Worry ?"

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 93 16:24:08 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Does MS Kermit 3.13 do z-modem transfers?

In article <1993Jul20.001550.17629@news.csuohio.edu>, cowboy@trans.csuohio.edu (Joe Rosenfeld) writes:
> Iam just about to get the latest MS Kermit, version 3.13, and I was asked
> a question I did not know the answer to. Can anyone tell me if MS Kermit
> can do z-modem transfers, and how is it accomplished?
> 
> TIA.  Much appreciated,
> Joe
> | Joe Rosenfeld			   cowboy@trans.csuohio.edu
> | CSU Law Library		    j.rosenfeld@csuohio.edu
----------
	Yes and no. Yes is you can shell out and run a separate program. No
is there is no Zmodem protocol in MS-DOS Kermit (which uses the Kermit protocol,
surprize). 
	Joe D.

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 93 11:16:36 GMT
From:      phone@cairo.anu.edu.au (matthew green)
To:        comp.protocols.tcp-ip
Subject:   Re: On the usefulness of the ident service (Was: FTP - Port # 113 - query)

atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:

>REPEAT 
>  One does NOT need root access in order to spoof the IDENT service !
>  One does NOT need root access in order to spoof the IDENT service !
>  One does NOT need root access in order to spoof the IDENT service !
>UNTIL you understand that root access is NOT needed to spoof IDENT
 
>One DOES need root access in order to purge audit logs.

i must be lame.  or stupid.  perhaps both.  i have pondered on these
statements the past day without understanding why you said them..

care to explain ?

mrg..

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1993 12:56:27 GMT
From:      agulbra@nvg.unit.no (Arnt Gulbrandsen)
To:        comp.protocols.tcp-ip
Subject:   Ftplib announce

>I can't seem to lookup that address from here.  Do you have an IP
>address for this host, or is there someplace else that has been able
>to snag a copy of it?

I have a copy, at ftp.nvg.unit.no, /pub/usenet-sources/libftp.tar.gz,
freshly copied from lpuds.oea.ihep.su.  Everyone should have internet
connectivity to ftp.nvg.unit.no, and for most people it should be quite
a bit faster to get it from there than from lpuds.oea.ihep.su (I had
11-second average RTT :-)

-- 
Arnt Gulbrandsen, agulbra@nvg.unit.no
Since my .sig is so short I'll include it twice.
-- 
Arnt Gulbrandsen, agulbra@nvg.unit.no

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Jul 1993 13:02:07 GMT
From:      schaeff@wega.heidelbg.ibm.com (Ulrich Schaeffer)
To:        comp.protocols.tcp-ip
Subject:   Multicast Transport Protocol (RFC 1301) PD Implementation wanted

Is there any public domain implementation of the Multicast Transport Protocol
(RFC 1301) available on some FTP server?

Thanks a lot in advance,
Ulrich Schaeffer

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1993 14:08:37 GMT
From:      rgoldstone@OAVAX.CSUCHICO.EDU (Robin, Girl Wonder)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   problem with StarNine's Mail Link SMTP gateway

I use StarNine's Mail Link SMTP gateway for Microsoft Mail.  We have been having
the following problem with this gateway for the past few months:

Incorrect IP addresses are being returned/cached for certain hosts.  Our gateway
is set up to use StarNine's resolver, then MacTCP's resolver (this sequence
provides MX record support).  The behavior is erratic but not totally random.
It happens for certain hosts only, and for those hosts, it does not happen
every time (bear with me...).  When an incorrect IP address is returned, there
is a pattern to it.  The pattern is that one or more octets of the address
are zero'd out.  Examples:
hostname             real ip address    bogus ip address returned
oasis.calpoly.edu    129.65.2.20        129.0.0.0
uga.cc.uga.edu       128.192.1.5        128.192.0.0

Once an invalid IP address is returned for the particular host, this address
is cached by MailLink and used for successive connect attempts until the ttl
for the host expires.  Needless to say, connection attempts to these addresses
fail during this period.  Once the cache entry expires, Mail Link will 
re-resolve the address, sometimes successfully, sometimes not.  If I quit the
gateway and re-start, the address is always resolved correctly immediately
following re-initialization.

I have attempted to look at the records for these hosts with nslookup, trying
to see if there is anything weird about them.  I am not a DNS expert though
so nothing much has caught my eye.  I had our DNS administrator look at
this too and he also sees nothing out of the ordinary.

So far, StarNine has made some effort to help us, but not much.  Apparently
we are the only people in the world having this problem.  They seem to believe
that if their resolver is getting invalid addresses, then it is because our
name server is returning invalid addresses.  But many other hosts on this 
campus use the same name server and we don't have this problem anywhere else.
I suspect that StarNine's resolver is the problem.  We have to use it though
since MacTCP's resolver doesn't do MX lookups.

Does anyone else have this problem?  If you use Mail Link SMTP for MS Mail and
have seen this problem, please contact me.

Thanks in advance.

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

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 93 13:14:18 BST
From:      eggermont@molbiol.ox.ac.uk
To:        comp.protocols.tcp-ip
Subject:   VINES and TCP/IP implementation

I am shortly moving to a new lab. The local network system is run on a 
Banyan-VINES server to which individual PC's are connected via thinwire 
ethernet. The VINES server is part of the university backbone which I am told 
supports TCP/IP protocols. 
As I am a Mac addict, I would like to link my Mac to this network so 
that I have direct access to Internet facilities. However, two questions come 
to my mind concerning this set up: 

(1) does the VINES server implement TCP/IP protocols? 

(2) if it does, can a Mac see and use the TCP/IP on the VINES network?

Thanks for any hints, tips, suggestions.....

Jan Eggermont
eggermont@molbiol.ox.ac.uk 

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 93 14:30:05 GMT
From:      ssanbeg@hebron.connected.com (Scott Sanbeg)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP! - Email via dial up line??

In article <42@westfield.win.net> debiso@westfield.win.net (Joe DeBiso) writes:
>Is it possible to do E-mail over a dial up line automatically??? 
>Can anyone assist me with this?  Please post news or E-mail me!

By automatically, do you mean UUCP? That will probably do for starters;
otherwise check out the SLIP descriptions in your server manuals.
Scott

-- 
Scott Sanbeg    UNIX Systems Administrator  Seattle, WA
ssanbeg@hebron.connected.com	        +1-206-431-9128

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Jul 1993 16:27:58 GMT
From:      ke9zd@gagme.chi.il.us (James D. Barlow)
To:        comp.protocols.tcp-ip
Subject:   ip over x.25


Howdy,

i'm looking forw a way to do tcp/ip over x.2 frames, asynch link.

hopefully, a commercially supported product.  

the platform is Interactive unix 5.3.2.

Thanks in advance for any help you may be able to offer.

--
jim@ke9zd.chi.il.us

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Jul 1993 17:13:41 GMT
From:      nafallon@vax1.tcd.ie
To:        comp.protocols.tcp-ip
Subject:   ftp stops dead!

Greetings
I'm having some trouble getting files between two Interactive unix PC's using 
FTP. The transfer zips along until around 22k at which point it stops dead.
The connection seems to be maintained, and a 'break' will get me back to the ftp prompt. The same thing happens when sending to vax systems, although not the
other way around. Connections to DOS machines are giving no such problems
though. 
I would be grateful if anyone has any ideas on whats happening. 

Niall Fallon
Dept. Microelectronic Engineering
Trinity College
Dublin
fallon@mee.tcd.ie

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1993 11:03:07 +0400
From:      orel@lpuds.oea.ihep.su (Oleg Orel)
To:        comp.protocols.tcp-ip
Subject:   Re: Ftplib announce

Russell Fulton (russell@ccu1.aukuni.ac.nz) wrote:
: imp@boulder.parcplace.com (Warner Losh) writes:
 
: >In article <22gutb$1ev@lpuds.oea.ihep.su> orel@lpuds.oea.ihep.su (Oleg Orel) writes:
: >>Last sources of ftplib aviable in ftp@lpuds.oea.ihep.su:/lib/ftplib
 
: >I can't seem to lookup that address from here.  Do you have an IP
: >address for this host, or is there someplace else that has been able
: >to snag a copy of it?
 
: Server:  ccvcom.aukuni.ac.nz
: Address:  130.216.1.2
 
: Non-authoritative answer:
: Name:    lpuds.oea.ihep.su
: Address:  192.102.229.78

lpuds location at exUSSR network. This network have access only to europe
and any other regions of world. This problem linked with COCOM org.

Sorry,
Anybody, Please make refresh from me to full-conectivity ftp-acrive....

Thanks


: -- 
: Russell Fulton, Computer Center, University of Auckland, New Zealand.
: <rj_fulton@auckland.ac.nz>





-- 
---------------------------------------------------------------------------
| Oleg Orel, Russia, Protvino       |   orel@lpuds.oea.ihep.su            |
| Institute of High Energy Physics  |   Home Phone: 49106                 |
---------------------------------------------------------------------------

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Jul 1993 18:29:06 +0000
From:      mike@charnock.demon.co.uk (Mike Charnock)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over X.25 - Help

Help!!!

A strange request, but there seems to be no other way!

We are trying to make the following connections, and would like some
advice as to whether its possible, and if so, who sells what

           IBM PS/2 running OS/2 v1.3 and CommsMgr 5250
                                |
                          SDLC Connection
                                |
                             X.25 WAN
                                |
                 X.25 to Ethernet Bridge/Router
                                |
                             Ethernet
                                |
                        VAX running TCP/IP

We need to run TCP/IP on the PS/2, co-existing with their 5250 connection
to an AS/400 across the SDLC and X.25, and establish a VT220 session over
TCP/IP to the VAX.  The VAX is not ours, so we can't load anything onto it -
it already has TCP/IP.

Thanks for you help. Email to mike@charnock.demon.co.uk would help but I will
monitor the group as well.

-- 
Mike Charnock   -   IDK          Custom Development - UNIX, Windows, DOS

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Jul 1993 18:59:19 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 <2277q0$63o@usenet.INS.CWRU.Edu> trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:
>In article <1993Jul16.073240.22953@novell.com> donp@novell.com (don provan) writes:
>>I seriously doubt it.  I don't know of *any* network protocol that
>>doesn't transmit multiple octet values high order octet first.
>
>Don, I think there's one in your own backyard!  Doesn't NCP send most
>of its datagrams with the low-order octet first?

I admit i'm no expert on NetWare's NCP, but from what i can tell from
looking at packet traces, it, too, appears to be, at least at heart,
high-order first.  (All the more amazing since NCP spent the first few
years of its life implemented exclusively on low-order first
machines...)
						don provan
						donp@novell.com

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Jul 1993 19:13:04 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Zero-window probing

In article <1993Jul21.013645.25062@gordian.com> mike@gordian.com (Michael A. Thomas) writes:
>   I have wondered about this. Isn't this a rather implementation
>specific thing, and thus violates the principle of liberal-receive
>conservative-send? I could conceivably see a TCP which receives
>already acknowledged data into its buffer (for which, say, the
>user has not already taken possetion of it) on the assumption
>that if the sending TCP is sending a packet with data in it,
>acknowledged or not, it ought to be correct if the checksums
>etc. are kosher. It might not be in the receivers best interest
>implementationwise, but I can't imagine why it would be bogus
>otherwise.
>   Am I being overly prudish here, or does this sound suspect
>to anybody else?

You are not being overly prudish, and it is definitely suspect.
Still, it is also standard practice, something that's probably
done by nearly every TCP implementation on the face of the earth.
It's one of those 4.2BSD legacies that TCP/IP will take to its
grave, although this one's somewhat benign since, as was just
mentioned, any implementation which had trouble with the garbage
byte would be doing something somewhat irrational, anyway.

						don provan
						donp@novell.com

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Jul 1993 18:21:00 +0100
From:      hugo@rusthoff.hacktic.nl (Hugo van.der.Kooij)
To:        comp.protocols.tcp-ip
Subject:   SLIP for Solaris 1.1: A few questions

 > From: js@kreutler.de (Juergen Stieber)
 > Organization: KREUTLER GmbH, 7500 Karlsruhe 1, Germany
 
 > Hi all,
 
 > I'm running Solaris 1.1 (SunOS 4.1.3) on a
 > SPARCstation IPX and I
 > have a few questions concerning SLIP:
 > 1) Is SLIP already installed / delivered with Solaris
 > 1.1?
 >    If no, how can I get and install it?

No, I got it from the last disk of PC-NFS but it is free.

 > 2) How can I use the SLIP connection, i.e. how can I
 > run an
 >    application over my SLIP connection (e.g. a X
 > client on
 >    one side and the X server on the other side of the
 > SLIP connection)?

If the SLIP link is up ANY ip traffic can cross. I know for
I have successfully done so (telnet, ftp and X)

 > 3) How can I make a SPARCstation a SLIP gateway? (or
 > another machine,
 >    if there is no difference on principle)

Just by stating so in your /etc/gateways file which routes
should take which router.

 > I hope my questions aren't too general, but I'm rather
 > new to
 > TCP/IP subjects, especially SLIP.
 
 > Any hints are greatly appreciated. Please answer by
 > e-mail, because
 > I don't read this News groups regularly.
 
 > Thanks in advance
 
 > Juergen Stieber

Just my $0.02

CU, Hugo.

 * Origin: Rust-Hoff; Home of the Brave. (2:512/32.23)

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Jul 93 20:59:23 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   packet driver for gateway card

In article <CAGpA5.nL@chinet.chinet.com> randy@chinet.chinet.com writes:

           Someone just dropped a bunch of 8 and 16bit Gateway ethernet
           cards in my lap.  Says Gateway Communications G/ETHERNET AT
           on them.  Seems to use the same chip as the wd8003, a
           83908N??  Is there a packet driver available for this card?

Yes, ask their tech support for it (it's not a Crynwr-derived driver).

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Jul 1993 21:05:09 GMT
From:      bsrikant@ho17.eng.ua.edu (B. Srikanth)
To:        comp.protocols.tcp-ip
Subject:   RPC

Greetings,
 I am trying to write an application to do Network Performance Monitoring 
using RPC's for our network. We have a token ring network of IBM RS/6000's 
running AIX 3.2. 
I was wondering, if there is a statistics server available  for token ring, 
like "rpc.etherd" which does the work for ethernet.

Any help/suggestions is greatly appreciated.
-- 
--------------
  Srikanth.B.

|----------------------|---------------------------|
|                      |                           |
|Srikanth.B.           |bsrikant@buster.eng.ua.edu |
|University of Alabama |                           |
|----------------------|---------------------------|

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1993 14:33:27 +0400
From:      orel@lpuds.oea.ihep.su (Oleg Orel)
To:        comp.protocols.tcp-ip
Subject:   libftp manual


   21 Jul 1993                                                      libftp(3)



   NAME
     libftp - Library functions of File Trasfer Protocol.

   SYNTAX
      #include <FtpLibrary.h>

      STATUS FtpConnect   (FTP **ftp,char *hostname)
        - connect to remote host. This function allocated memory for struc-
     ture FTP with before use for indentification connection.

      STATUS FtpUser      (FTP *ftp,char *username)
        - send user name to remote daemon.

      STATUS FtpPassword  (FTP *ftp,char *password)
        - send password.

      STATUS FtpAccount   (FTP *ftp,char *account)
        - send account name.

      STATUS FtpLogin     (FTP **ftp,char *user,
                    char *pass,char *account)
        - send all login information, if account is absent, then use NULL
           instend it.

      STATUS FtpChdir     (FTP *ftp,char *directory)
        - change remote working directory.

      STATUS FtpMkdir     (FTP *ftp,char *directory)
        - change remote working directory.

      STATUS FtpRm        (FTP *ftp,char *file)
        - erase remote file.

      STATUS FtpType      (FTP *ftp,char *type)
        - set file type

      STATUS FtpAscii     (FTP *ftp)
        - set file type to ASCII.

      STATUS FtpBinary    (FTP *ftp)
        - set file type to BINARY.

      char *FtpPwd       (FTP *ftp)
        - get working directory.

      STATUS FtpBye       (FTP *ftp)
        - Close ftp connection.

      STATUS FtpCommand   (FTP *ftp,char *command,
                    param,ans1,ans2,...,EOF)
        - Send command to remote daemon,command for remote daemon making by
     sscanf(x,command,param). If deamon return answer but not equivalent
     answer lists then if set error handler ( by SetErrorHandler ) then call


   libftp version 1.0                                                       1






   libftp(3)                                                      21 Jul 1993


     it., else return answer by negative sing.

      STATUS FtpData     (FTP *ftp,char *command,param,mode)
      - Open data connection to remote host. command and param send to remote
     daemon,mode is "r" or "w". Before call it subroutine , you can
     read/write by use ftp->data file structure.

      STATUS FtpOpenRead  (FTP *ftp,char *file)
        - Open file for read.

      STATUS FtpOpenWrite (FTP *ftp,char *file)
        - Open file for write.

      STATUS FtpOpenAppend (FTP *ftp,char *file)
        - Open file for append.

      STATUS FtpOpenDir   (FTP *ftp,char *pater)
        - Open directory brief list from remote host.

      STATUS FtpClose     (FTP *ftp)
        - Close data connection.

      STATUS FtpGetFile   (FTP *ftp,char *file)
        - Send get command to remote daemon.

      STATUS FtpPutFile   (FTP *ftp,char *file)
        - Send put command to remote daemon.

      STATUS FtpRead      (FTP *ftp)
        - Read one character from remote host.

      STATUS FtpWrite     (FTP *ftp,char c)
        - Write one character to remote host.

      STATUS FtpGetString (FTP *ftp,char *s)
        - Get String from data connection.

      STATUS FtpGet       (FTP *ftp,char *remotefile,char *localfile)
      STATUS FtpPut       (FTP *ftp,char *localfile,char *remotefile)
      STATUS FtpDir       (FTP *ftp,char *outfile)
      STATUS FtpDirectory (FTP *ftp,char *patern,char *outfile)
        - Transfer file or lists.

      FILE *FtpFullOpen  (char *filename,char *mode)
        - Open file.

          filename: host/user/password:file

             mode:     "r","w" or "a".

      STATUS FtpFullClose ( FILE * )
        - Close file opened by FtpFullOpen.

      FtpSetErrorHanler(FTP *ftp,STATUS (*handler)())


   2                                                       libftp version 1.0






   21 Jul 1993                                                      libftp(3)


      FtpSetDebugHanler(FTP *ftp,STATUS (*handler)())
        - Set error and debug handlers.

      void FtpDebug(FTP *ftp)

        - Set standard error and debug handlers. Thouse hadlers print all
     debug and errors informations to strerr. If got error, then exit pro-
     gram.


   AUTHORS
       Oleg Orel
       e-mail: orel@lpuds.oea.ihep.su


   LOCATION


          HOST: lpuds.oea.ihep.su

          IP:   192.102.229.78

          DIR:  /libs/libftp































   libftp version 1.0                                                       3




 9 9
-- 
---------------------------------------------------------------------------
| Oleg Orel, Russia, Protvino       |   orel@lpuds.oea.ihep.su            |
| Institute of High Energy Physics  |   Home Phone: 49106                 |
---------------------------------------------------------------------------

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Jul 1993 21:13:38 GMT
From:      choover@usd.edu (Christopher J Hoover )
To:        comp.protocols.tcp-ip
Subject:   Training Advice Request:  American Research Group, Inc.

For any who might have answers:

My supervisor handed me a brochure for a seminar entitled "Hands-On
Internetworking with TCP/IP," to be put on by the American Research Group,
Inc., and Russ Carleton, in several cities in the coming months, including
Omaha in October, which is fairly close.  The cost for the 3-day seminar
is $1,195 (or $1,095, if more than three attend), and my bosses want to
figure out if it would be worthwhile to send some of us to attend.

So.  Has anyone out there attended one of ARG's seminars (preferably this
one), and if so, have you any impressions, either positive or negative,
that you might care to pass along?  If the seminar is _good_, it would be
quite useful for some of us, but I'm wondering whether there will be
enough substance to it to justify the expense.

Response in e-mail would be most appropriate, I suppose, unless you think
the general readership might benefit.


Thanks in advance to any who reply, and apologies if this request is less
technical than the usual traffic, and correspondingly off-topic,

Chris

--
Christopher J. Hoover | If the automobile had followed the same development
choover@usd.edu       | cycle as the computer, a Rolls-Royce would today cost
Univ. of South Dakota | $100, get a million miles per gallon, and explode once
Disclaimer:  standard | a year, killing everyone inside.  --Robert X. Cringely

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Jul 1993 21:27:30 GMT
From:      swslr@well.sf.ca.us (Larry Krone)
To:        comp.protocols.tcp-ip
Subject:   AIX (RS/6000) TCP/IP Problems

Gentle people:

I am running into a somewhat interesting (frustrating) situation
communicating between an SCO and AIX box via tcp....

Every so often, I will be unable to rlogin from the AIX to the SCO
box. (FTP works fine, Telnet does not).  I CAN, however, rlogin from
the SCO to the AIX.  AFter I do this, I am able to rlogin the other way...

A reboot on the AIX box seems to fix the problem also.,..


Any ideas???


Please email to:

swslr@well.sf.ca.us

Thanx... Larry Krone


-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Jul 1993 21:47:43 GMT
From:      macedoni@cs.nps.navy.mil (mike macedonia)
To:        comp.protocols.tcp-ip
Subject:   Re: Does MS Kermit 3.13 do z-modem transfers?

Joe Rosenfeld (cowboy@trans.csuohio.edu) wrote:
: Iam just about to get the latest MS Kermit, version 3.13, and I was asked
: a question I did not know the answer to. Can anyone tell me if MS Kermit
: can do z-modem transfers, and how is it accomplished?
 
: TIA.  Much appreciated,
: Joe
 
: --

MS Kermit has only the Kermit file tranfer protocol built in. However, you can
shell out (push) or run from the MS-Kermit prompt a program like DZE which 
invokes  zmodem externally.  


--
Mike Macedonia | macedoni@cs.nps.navy.mil
------------------------------------------------------------

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Jul 1993 00:31:02 GMT
From:      tkevans@fallst (Tim Evans)
To:        comp.protocols.tcp-ip,comp.sys.mac
Subject:   InterSLIP?

InterCon, a vendor of TCP/IP products for the Macintosh, has recently
announced something called "InterSLIP."  They describe it in their
press release as a "MacTCP extension" which apparently enabled
dynamic, dial-on-demand SLIP connections.

Is this solely an InterCon product, or it is a real Apple extension to
MacTCP?  Can someone provide other details?  Please email.  Thanks.
-- 
INTERNET:	tkevans@fallst.es.dupont.com
UUCP:		{rutgers|ames|uunet}!mimsy!wb3ffv!fallst!tkevans
Tim Evans	2201 Brookhaven Ct, Fallston, MD 21047

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Jul 1993 01:05:46 GMT
From:      mjclelan@yoyo.cc.monash.edu.au (Michael Cleland)
To:        comp.protocols.tcp-ip
Subject:   Zmodem Protocol

Apologies if this is the wrong area, but...

Does anyone know where I can find a Zmodem program for Unix, so that I can
use it, instead of Kermit, for file xfers to my home? Call me old
fashioned, but I just prefer Zmodem.

PS: Please Email your reply direct to me.

Thank you,


-- 
Michael Cleland, Monash Uni,   | To do comedy, you have to be FUNNY... ;-)
Melbourne, Victoria, Australia |------------------------------------------- 
mjclelan@yoyo.cc.monash.edu.au |       Only   //                
Don't waste water - Drink PEPSI|            \X/   AMIGA makes it POSSIBLE!

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Jul 1993 01:31:17 GMT
From:      ittai@ans.net (Ittai Hershman)
To:        comp.protocols.tcp-ip
Subject:   Re: Ftplib announce

The Russian nets are being announced to ANS CO+RE users of the ANSNet
T3 backbone which includes most of the Regional networks.  Those sites
that are exclusively NSFNET Backbone Service subscribers, are still
not seeing the .su nets, as per NSF policy.

-Ittai
---------------
    It was said here a few months ago that NSFnet was not routing packets
    to the .su sites.  CIX was, as were at least some European nets.
    
    The best short-term solution is to get someone in Europe or on CIX to
    set up another FTP site.  The long-term solution would be to get NSFnet
    to change the routing policy.
    
    The accuracy of this information is likely to be low.  Not only is it
    old and second-hand, it is second-hand from the net.

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Jul 1993 09:10:12 GMT
From:      Graham Barlow
To:        comp.protocols.tcp-ip
Subject:   Telnet Scripts with WINQVT/NET

Has anyone got the Telnet scripts to work with recent versions of WINQVT/NET?

They seemed to break a couple of versions ago, I NEED them if I am to use this
package because many of my hosts are on the other side of an X29/telnet 
gateway, and I use small scripts to enter the X29 addresses.

Can anyone help?

Graham
     

.______________________________________________________________________.
|  Dr. Graham Barlow   |                                               |
|  NMR Service         |                                               |
|  Dept. of Chemistry  |    JANET mail:        gkb1@UK.AC.YORK         |
|  Univ. of York, UK   |    Internet mail:     gkb1@tower.york.ac.uk   |
 +----------------------+-----------------------------------------------+

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Jul 1993 13:09:19 GMT
From:      wilfred@zeus.wnc.nedlloyd.nl (Wilfred Mollenvanger)
To:        comp.protocols.tcp-ip
Subject:   Automatic setting of line-by-line mode in telnet session

Hello netters,

I've got a little problem (don't we all ;-)
I've got users with radio terminals logging in to a unix box to use an
application. The radio terminals have a build-in telnet program. A
user types a hostname, logs in and the application is started. Now the
problem is that by default the telnet session operates in
character-by-character mode. Because these radio terminals are really
slow I want to improve performance by using a line-mode connection.
This can be set with the telnet "mode line" command. I don't want the
users to do this but I want to set it automagically. How can this be
done? Are there terminal setting to do this, can I write a program (shell
script) which is executed when the user logs in, please help?

Thanx in advance,

Wilfred Mollenvanger.

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Jul 1993 13:37:39 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP! - Email via dial up line??

In article <22l54d$h0k@hebron.connected.com>, ssanbeg@hebron.connected.com (Scott Sanbeg) writes:
> In article <42@westfield.win.net> debiso@westfield.win.net (Joe DeBiso) writes:
> >Is it possible to do E-mail over a dial up line automatically??? 
> >Can anyone assist me with this?  Please post news or E-mail me!
> 
> By automatically, do you mean UUCP? That will probably do for starters;
> otherwise check out the SLIP descriptions in your server manuals.


Some SLIP packages dial on demand.  The SYN to port 25 starting an
SMTP exchange causes the near side of the SLIP link to dial and
get things going.  The same facilities are available in some PPP
packages.


Vernon Schryver,  vjs@sgi.com

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Jul 1993 13:39:31 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RIP broadcast daemon ?

In article <22lf9s$l3f@DIALix.oz.au>, dcs@DIALix.oz.au (Dept. of Community Services) writes:
> 
> I am looking for a unix daemon which will read an ascii file holding a routing
> table, and broadcast these routes as RIP updates.
> 
> Does such a beast exist on internet ?


The `gated` daemon can be configured to do that.

Look in the newsgroup "info.gated" or on devvax.TN.CORNELL.EDU.


Vernon Schryver,  vjs@sgi.com

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1993 13:49:28 GMT
From:      dewey@centerline.com (Devan F. Dewey)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm,comp.protocols.appletalk
Subject:   Blank session window with NCSA Telnet 2.5 (HELP!)

We recently moved a Sun Sparc 10 to a different subnet.

Ever since then we are experiencing the following sporadic behavior:

        User opens a session to this host by name.
        A session window opens (indicating a response from the host).
        The window remains blank (no login prompt).
        Sometimes the prompt shows up in about 2-4 minutes.
        Sometimes it never shows up and the window closes.

We are using NCSA Telnet 2.5 with MacTCP 1.1.1 in a System 7.0.1
environment of a variety of Macs on LocalTalk. This problem occurs with
about 10% of the attempts. There is no delay in dsplaying the login prompt
from Macs on ethernet or from a telnet request from another Unix box.

Does this ring a bell? Do you have any suggestions?

Any help is greatly appreciated. (E-mail preferred.)

Best regards,
Devan

                             
               Devan F. Dewey | Senior Systems Analyst
          CenterLine Software | dewey@centerline.com
            10 Fawcett Street | "Leme esplain - no dere is
          Cambridge, MA 02138 | too much. Leme sum up."
                                       -Inigo Montoya

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 93 15:03:36 GMT
From:      matt@emily.math.binghamton.edu (Matt Brin)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin,comp.unix.wizards
Subject:   more details on galcial ftp transfer problem

This is an addition of information to a previous problem.  We are
the ones who were having trouble with long ftp transfers.  We know a
lot more about what is happening.  In fact we know exactly what is
happening.  That doesn't mean we have solved our problem.  The
situation is as follows.

We are a lan in two pieces.  Our subnet mask is 255.255.255.128 or,
equivalently, 0xffffff80.  One piece has net number 128.226.2.0 and
the other piece has net number 128.226.2.128.  The piece with net
number 128.226.2.0 is joined to the "outside world" by a SUN SPARC
1+ running sunos 4.1.3 and acting as a router.  Call this machine
our _router.  On the "outer side" of our _router is net 128.226.1.0
and the netmask on this side is 255.255.255.0 or, equivalently,
0xffffff00.  The interfaces on our _router are configured to have
the right netmasks on each side.  All other machines in our
two-piece lan use netmasks 255.255.255.128.  Our _router must run
in.routed since the "outside world" changes too frequently for us to
keep up with the changes.

Obviously we have a machine connecting net 128.226.2.0 and
128.226.2.128.  Call it our _gateway.  It does not run in.routed
since it and all other machines we have except our _router have
route tables statically set.  Machines on net 128.226.2.0 have
default gateway = our _router and an entry for net 128.226.2.128
with gateway our _gateway.  Machines on net 128.226.2.128 have
default gateway our _gateway.  Our _gateway has default gateway =
our _router and knows how to get to the two nets that it is directly
connected to.  Since our _gateway is not running in.routed, our
_router will not know how to get to net 128.226.2.128 unless we tell
it how.  This is our problem.

If we do NOT manually do the following instruction (as root)
% route add net 128.226.2.128 "our _gateway" 1
then our _router cannot find the other net.

If we DO add the gateway entry manually to the route table, then our
_router starts to mess up.  On ftp transmissions to hosts on
128.226.2.0 (no need ot use our _gateway), it goes into exponential
backoff --- symptomatic of not getting acks from the receiver.  Here
are the details.

An ftp session from our _router to a machine on net 128.226.2.0
(same net as our _router) has all packets from the _router to the
receiving host structured as follows.  The Ether Header has
destination address = the ether address of the receiving machine and
source address = the ether address of our _gateway.  (I kid you
not.)  The IP envelope has destination address = the IP address of
the receiving machine and source address = the IP address of our
_router (the sending machine of the ftp session).  I expected to
find that the acks from the receiving machine were being sent to our
_gateway instead of our _router (the sending machine) because of the
addresses in the ether header.  However, I found that acks from the
receiving machine were correctly addressed.  They just stopped after
a while.  I found the following packet much later in the stream
(after exponential backoff had gotten sending down to one packet per
minute).  I have inserted comments in C style.

ETHER:  ----- Ether Header -----
ETHER:  
ETHER:  Packet 156 arrived at 9:34:19.69
ETHER:  Packet size = 60 bytes
ETHER:  Destination = 8:0:20:4:33:2a, Sun  /* ether of our _gateway */
ETHER:  Source      = 8:0:20:b:71:55, Sun  /* ether of receiving host */
ETHER:  Ethertype = 0806 (ARP)
ETHER:  
ARP:  ----- ARP/RARP Frame -----
ARP:  
ARP:  Hardware type = 1
ARP:  Protocol type = 0800 (IP)
ARP:  Length of hardware address = 6 bytes
ARP:  Length of protocol address = 4 bytes
ARP:  Opcode 2 (ARP Reply)
ARP:  Sender's hardware address = 8:0:20:b:71:55  /* receiving host */
ARP:  Sender's protocol address = 128.226.2.2, phyllis  /* ditto  */
ARP:  Target hardware address = 8:0:20:4:33:2a  /* our _gateway  */
ARP:  Target protocol address = 128.226.2.126, math-off-gw /* ditto */
ARP:  

(The output is from snoop.  It is running on a machine on our net
that runs under Solaris 2.1.)

I don't know if this packet means anything in this problem.  It
showed up even earlier in the stream when I did this once before. 

Here is a sequencing of events
9:30:4.70   17 packets data to receiving host
9:30:4.79   1  ack from receiving host to port 20
9:30:4.80   5  packets data to receiving host
9:30:4.82   1  ack from receiving host to port 20
9:30:4.82   1  ack from receiving host to port 21
9:30:4.82   9  packets data to receiving host
9:30:5.01   1  ack from receiving host to port 20
There were no more acks.
From here on one packet was sent to the receiving host at
9:30:5, 9:30:7, 9:30:11, 9:30:19, 9:30:35, 9:31:7, 9:32:11, 9:33:15,
9:34:19.
I terminated transmission at 9:35:13.

Questions: Should we be able to run nets with netmaks 0xffffff80?
Should we be able to run a router with one netmask on one interface
and another netmask on the other?  Does anyone have an idea as to
what is going on here?
_____________________________________________________________________________
matt brin / math. dept / SUNY / Binghamton, NY 13902-6000 / (607)-777-2147
matt@math.binghamton.edu      	INTERNET
mbrin@bingvaxa			BITNET
-----------------------------------------------------------------------------

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Jul 1993 16:15:12 GMT
From:      ameen@hpcc01.corp.hp.com (Kavetta Ameen)
To:        comp.protocols.tcp-ip
Subject:   Re: Network printing from a PC to an SCO box




    Try NFS for the PC's...




-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1993 17:15:09 GMT
From:      sand@dist.dist.unige.it (Francesco Giugu Giuffrida)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Sockets &PC

I need to comunicate by sockets between a PC and workstation,
Where I can find A socket library for PC that works with different 
ethernet Adapters (3-Com Western Novell)?

--
______________________________________________________________________________
| /    /~~\ |\ | | \ | Francesco (Giugu) Giuffrida  e-mail: sand@dist.unige.it  
| \    |__| | \| |  ||      tel. +39 (10) 3532801   fax: +39 (10) 3532948       
|  \   |  | |  | |  || DIST (Departement of Comunications and Computer Science)

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 93 17:24:59 GMT
From:      birchall@pilot.njin.net (Shag)
To:        comp.protocols.tcp-ip
Subject:   Looking for "SLIP16550" for PC

A while back (before I got my PC a 16550AFN UART chip to handle high-speed
transfers), I saw a version of SLIP for the PC that was specifically geared
toward systems with the 16550.  I now am using SLIP8250, which is all well
and good, but doesn't take advantage of my system's capabilities.

I haven't been able to find the 16550 version as an individual file on the net
using Archie, and was wondering if anyone knows of any archived SLIP packages
on the net (zipfiles and such) which would include it.  I don't want to just
download every SLIP package known to mankind and dearchive them looking for 
it. ;)

Thanks much,

-Shag

-- 
birchall@pilot.njin.net  shag@gnu.ai.mit.edu  shag@glia.biostr.washington.edu
ShagNet - Rutgers/NJIN / Editor of "Screaming in Digital" | PPI 14.4 FaxModem
Dialup access serving / The Queensryche Net-Digest.  Mail | GeoSadist two-oh!
Burlington County NJ / queensryche-request@pilot.njin.net | Cannondale SR-500

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 93 15:48:03 +0100
From:      ccdarg@dct.ac.uk (Alan Greig)
To:        comp.os.vms,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Meeting Announcement: Internet Security Concepts

In article <1993Jul21.154437.448@rlgsc.com>, nyseclug@rlgsc.com writes:
> 
>                      The Security User Group
> 
> 
>              Internet Security Concepts and Approaches
>                      Tuesday, July 27, 1993
>                       6:00 p.m. - 8:00 p.m.


> 
> If you plan to attend, please RSVP by Monday, March 8 to:

This might be a bit tricky.

-- 
Alan Greig                            Janet: A.Greig@uk.ac.dct
Dundee Institute of Technology	   Internet: A.Greig@dct.ac.uk
Tel: (0382) 308810                 (Int +44 382 308810)
         ** Never underestimate the power of human stupidity **

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1993 17:40:29 GMT
From:      elr@tinman.dev.prodigy.com (Ed Ravin)
To:        comp.protocols.tcp-ip
Subject:   Re: Does MS Kermit 3.13 do z-modem transfers?

In article <1993Jul21.162408.70295@cc.usu.edu> jrd@cc.usu.edu (Joe Doupnik) writes:
>
>	Yes and no. Yes is you can shell out and run a separate program. No
>there is no Zmodem protocol in MS-DOS Kermit (which uses the Kermit protocol,
>surprize). 

But, you can run Omen Technologies DSZ under MS-DOS Kermit, as long as
you're using a serial port and not a network connection.  MS-Kermit gives
you its own, built in protocol for Kermit but lets you escape and run
whatever programs you want.

Get ahold of DSZ.ZOO or whatever it's called at your nearest ftp site
or bbs.  MS-Kermit works well with it...
-- 
Ed Ravin                 | "A mind is a terrible thing to waste -- boycott TV!"
Prodigy Services Company |    
White Plains, NY 10601   |                            (the usual disclaimers)
+1 914 993 4737          | elr@dev.prodigy.com, eravin@panix.com

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Jul 1993 17:45:40 GMT
From:      ching@angelo.amd.com (Mike Ching)
To:        comp.protocols.tcp-ip
Subject:   Re: Does MS Kermit 3.13 do z-modem transfers?

In article <CAJB7J.8HL@taurus.cs.nps.navy.mil> macedoni@cs.nps.navy.mil (mike macedonia) writes:
>Joe Rosenfeld (cowboy@trans.csuohio.edu) wrote:
>: Iam just about to get the latest MS Kermit, version 3.13, and I was asked
>: a question I did not know the answer to. Can anyone tell me if MS Kermit
>: can do z-modem transfers, and how is it accomplished?
>
>MS Kermit has only the Kermit file tranfer protocol built in. However, you can
>shell out (push) or run from the MS-Kermit prompt a program like DZE which 
>invokes  zmodem externally.  
>


Is there an external protocol program that can support the telnet/packet
driver connection?

Thanks in advance,
Mike Ching

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 93 18:22:34 GMT
From:      nyseclug@rlgsc.com
To:        comp.os.vms,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Meeting Announcement: Internet Security Concepts


                     The Security User Group


             Internet Security Concepts and Approaches
                     Tuesday, July 27, 1993
                      6:00 p.m. - 8:00 p.m.


The focus of this presentation will be Internet Security Concepts 
and approaches.  This will include a brief overview of the 
present status of the Internet, and a topical discussion of: the 
TCP/IP protocol suite and applications services, UNIX (tm) 
Security vulnerabilities, and approaches employed within the 
Internet to support inter and intra-network access control 
including protocol filtering, route filtering firewalls, and 
applications level gateways.

Speaker:              Alton Hoover
                      Vice President
                      ANS CO+RE Systems, Inc.
                      Co-chair, IP Security Working Group
                      Internet Engineering Task Force

Location:             Coopers & Lybrand
                      1301 Avenue of the Americas (52nd Street)
                      Cafeteria (2nd floor)
                      New York, New York

Host:                 Carol A. Siegel

If you plan to attend, please RSVP by Monday, July 26 to:

                                 Carol A. Siegel
                                Coopers & Lybrand
                                 +1 212 259 2931 (NOTE: Corrected Number)
                                nyseclug@rlgsc.com

RSVP is mandatory. Building security will not permit any person not on the 
attendee list to enter the building (This is the Security User Group after 
all!)
                         

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 93 18:36:05 GMT
From:      peterg@eng.krldwa.mccaw.com (Peter Gregory)
To:        comp.protocols.tcp-ip
Subject:   setsockopt - how to do two options?

Hi...

I want to set SO_REUSEADDR and SO_KEEPALIVE on a TCP socket.  Is there
a way to set both options in a single setsockopt call?  Or, must I 
call setsockopt twice?

What I *want* to do:

 int dummy=1;
 rc = setsockopt(sock,
                  SOL_SOCKET,
                  SO_REUSEADDR|SO_KEEPALIVE,
                  (char *) &dummy,
                  sizeof(dummy));

...is this the right way, or ????


-- 

Pete Gregory   peterg@eng.krldwa.mccaw.com  |  "It may be rice wine to you,
Senior Consultant. ASIX, Inc., Seattle, WA  |  but it's sake to me."
on-site at McCaw Cellular Communications, Kirkland, WA

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Jul 1993 19:13:26 GMT
From:      ronf@mazel. (Ron Feigen)
To:        comp.protocols.tcp-ip
Subject:   Re: Sockets &PC

In article c6o@sgi.iunet.it, sand@dist.dist.unige.it (Francesco Giugu Giuffrida) writes:
>I need to comunicate by sockets between a PC and workstation,
>Where I can find A socket library for PC that works with different 
>ethernet Adapters (3-Com Western Novell)?
>
>--
>______________________________________________________________________________
>| /    /~~\ |\ | | \ | Francesco (Giugu) Giuffrida  e-mail: sand@dist.unige.it  
>| \    |__| | \| |  ||      tel. +39 (10) 3532801   fax: +39 (10) 3532948       
>|  \   |  | |  | |  || DIST (Departement of Comunications and Computer Science)


Novel has a product called Lan Workplace for DOS Toolkit.  It is for developing
TCP/IP products over Ethernet/Arcnet or token ring.  Any card that has a standard 
ODI driver will work.  You get Novels Lan workplace software plus a BSD socket 
libary complete with select()!


---

>
Ron Feigen
ronf@panther.mot.com


-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1993 19:16:43 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for "SLIP16550" for PC

In article <Jul.22.13.24.58.1993.28553@pilot.njin.net> birchall@pilot.njin.net writes:
>A while back (before I got my PC a 16550AFN UART chip to handle high-speed
>transfers), I saw a version of SLIP for the PC that was specifically geared
>toward systems with the 16550.  I now am using SLIP8250...

SLP16550 is a commercial product bundled with FTP Software, Inc.'s
TCP/IP stuff for PCs.

SLIP8250 uses 16550 UARTS without problems.  Have you noticed the
message that says "16650 detected - FIFO enabled"?

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

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Jul 1993 20:46:36 GMT
From:      a722756@pan.mc.ti.com (W. Donald Rolph III)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Sockets &PC

In article <22mhut$c6o@sgi.iunet.it> sand@dist.dist.unige.it (Francesco Giugu Giuffrida) writes:
>From: sand@dist.dist.unige.it (Francesco Giugu Giuffrida)
>Subject: Sockets &PC
>Date: 22 Jul 1993 17:15:09 GMT
 
>I need to comunicate by sockets between a PC and workstation,
>Where I can find A socket library for PC that works with different 
>ethernet Adapters (3-Com Western Novell)?
 
>--
>______________________________________________________________________________
>| /    /~~\ |\ | | \ | Francesco (Giugu) Giuffrida  e-mail: sand@dist.unige.it  
>| \    |__| | \| |  ||      tel. +39 (10) 3532801   fax: +39 (10) 3532948       
>|  \   |  | |  | |  || DIST (Departement of Comunications and Computer Science)

If you choose a socket stack which talks to an ndis driver, your code will be 
card independent.  I have used the socket libraries from microsoft/DEC for the 
lanman tcp/ip or DEC pathworks tcp/ip stacks quite successfully.

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1993 21:21:02 GMT
From:      twong@civil.ubc.ca (Thomas Wong)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   PC/TCP + X Window products


Hello. Now that I have a list of all the 3rd party X Windows products
that work under PC/TCP package from FTP Software, I was wondering if
anyone would like to offer some experience as to which package is better
than the other. They all look quite similar and I have to evaluate which
package to get. Thanks in advance.

Thomas.


-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Jul 1993 21:55:10 GMT
From:      sr@acsu.buffalo.edu (Sudhakar Rajamannar)
To:        comp.protocols.tcp-ip
Subject:   Info on fax thro mail

Hi !!

I am planning to work on transmitting fax,video... thro e-mail.
Can any one familiar with it let me know the ftp site where I can find the
latest info on this besides the rfcs and also on the interest group I 
should subscribe to ( I have subscribed to Header-people but am not getting
any acknowledgement).

Plese send mail to sr@destiny.eng.buffalo.edu


Thanks in advance.

Sudhakar Rajamannar






-- 
-------------------------------------------------------------------------------
	"kARRu veLiyidaik kaNNammA -- ninRan
      	   kAdhalai eNNik kaLikkinREn 


-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Jul 1993 22:19:02 GMT
From:      dkung@co2.mnet.uswest.com (Darwei Kung)
To:        comp.protocols.tcp-ip
Subject:   Help on MacTCP

Hi, I have a problem with MacTCP subnetting.  For class B addresses,
MacTCP automatically applies the mask 255.255.0.0, which would mask
out any traffic with a different network number.  I would like to turn
this masking off in MacTCP, but I couldn't find how to do that in any
documentation.  Any hints on how to disable the subnet masking is
greatly appreciated.

ps.  I was able to use NCSA/Telnet by using the built-in ethernet
driver, with mask set to 0.0.0.0, but whenever I tried to use the
MacTCP driver, the program would not be able to connect to a host on a
different network.

Darwei Kung
--
+-------------------------------------+
|  Darwei Kung                        |====================
|  Engineering Reengineering Team     |  ====================
|  U S WEST Communications            |    ====================
|  (206) 345-2255                     |              =======================  
|  dkung@co2.mnet.uswest.com          |            =======================
+-------------------------------------+          =======================
--
+-------------------------------------+
|  Darwei Kung                        |====================
|  Engineering Reengineering Team     |  ====================
|  U S WEST Communications            |    ====================

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 1993 01:00:45 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Help on MacTCP

In article <dkung.743379542@co2> dkung@co2.mnet.uswest.com (Darwei Kung) writes:
>ps.  I was able to use NCSA/Telnet by using the built-in ethernet
>driver, with mask set to 0.0.0.0, but whenever I tried to use the
>MacTCP driver, the program would not be able to connect to a host on a
>different network.

A mask of 0.0.0.0 is always wrong.  Your subnet mask must be _at least_
as long as 255.255.0.0 if you are on a class B net.  255.255.0.0 is, by
definition, the base netmask for all class B nets.  You can subnet it
by increasing the number of 1 bits, but you cannot decrease the number
of 1 bits.  For example, a popular subnet mask for class B nets is
255.255.255.0, but valid subnet masks are anything from 255.255.192.0
to 255.255.255.252.

I suggest talking to your TCP/IP network administrator, asking him what
subnet mask to use.  Guessing at the subnet mask is not practical.

Make sure you have configured at least one gateway, by the way.

       Stephen

(Note to purists: Yes, I know about supernetting, but I have a strong
hunch it doesn't apply in this case.)

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

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 93 02:21:19 GMT
From:      sklower@diva.Berkeley.EDU (Keith Sklower)
To:        comp.protocols.tcp-ip
Subject:   Re: Questions regarding METRIC in IFCONFIG and ROUTE

In article <1993Jul20.035459.12156@twg.com> Deven writes:

}	I had posted this about a month ago, but have not received
}	any response.  I hope the article made out to the Net.
}	Any response will be appreciated.

The article got as far as UC Berkeley.  I'm going to be a prig
and say that some of us have our own job to do - you apparently
work for Wollongong, which has a BSD source license, so you should be
able to answer your own questions just by looking at the source code.
And, I presume I'm not going to get any of the customer support
money your company will be getting by being able to answer the question.
But, just for the record, I'll answer anyway.


}
}	I have a few questions related to METRIC as used in the
}	IFCONFIG and ROUTE commands, as also how it compares with 
}	the METRIC in a dynamic route.
}
}Background:
}	The man page for IFCONFIG states that the metric argument
}	"Sets the routing metric of the interface to n, default 0.  Higher 
}	metrics have the effect of making a route less favorable; metrics 
}	are counted as additional hops to the destination network or host."
 
}	The man page for the ROUTE command states that "The metric 
}	argument indicates the number of "hops" to the destination.
}	The metric is required for add commands; it must be zero
}	if the destination is on a directly-attached network,
}	and nonzero if the route utilizes one or more gateways."
 
}Question 1: 
}	What is the relationship between the metric (hops) in the ROUTE 
}	command and what is placed in the IP TTL field?

Absolutely none.  The metric argument in the route command
merely indicates whether the host is directly reachable, or
must be sent via a gateway.  The actual value is not stored
anywhere in the system.  An unnamed individual thought this
was bogus and attempted to change the syntax of the route command
to be something more reasonable.  Whether he succeeded or not
is open to question.

}
}Question 2: 
}	What is the maximum value that can be specified for METRIC
}	in the IFCONFIG command?

There is a practical limit of 14 (see question 4).
The code in ``ifconfig'' doesn't actually check for a maximum value,
so it won't warn you if you do something unreasonable.


}Question 3:  
}	What is the difference between the METRIC argument for the 
}	IFCONFIG command and the METRIC argument for the ROUTE command?

Absoultely none.

}Question 4:
}	I understand that ROUTED makes use of the metric specified 
}	for a given interface.

True; both routed and gated use the information supplied in the
IFCONFIG [sic] command.  It was going to add this value to any
routes either learned or announced on that interface.  Different
version of routed did different things.  I let you figure out
what gated does with it, and maybe you'll be willing to report back.
since early versions of the RIP protocol said that anything with
a metric of 15 was unreachable, adding anything greater than
14 doesn't make sense . . .

}	                         Let us say that the route propagated by 
}	ROUTED has a metric of x (after allowing for the metric for that 
}	particular interface).  Would it be possible to override the metric 
}	of the route given by ROUTE by adding a static route with a metric 
}	of y (where y < x)?  

Not in this fashion.  You might be able to cobble something by using
/etc/gateways.

}
}	If so, what would be the effects if some administrator (of another 
}	network) sets up an arbitrarily high value for an interface on his 
}	machine (which is a gateway), to prevent others from using it as a 
}	gateway?

The arbitrarily high value was intended to be 1 or maybe 2 so that you
could engineer fall-back gateways, but you couldn't actually prevent
a fall-back gateway being used entirely if somebody had a really
stupid listener that looked for any system sending RIP packets
and used it as the default.

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1993 15:23:40 +0800
From:      dcs@DIALix.oz.au (Dept. of Community Services)
To:        comp.protocols.tcp-ip
Subject:   RIP broadcast daemon ?

Greetings all

I am looking for a unix daemon which will read an ascii file holding a routing
table, and broadcast these routes as RIP updates.

Does such a beast exist on internet ?

Thanks in Advance

jimm@lima.DIALix.oz.au


-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 93 05:30:44 GMT
From:      briana@tau-ceti.isc-br.com (Brian W. Antoine)
To:        comp.protocols.tcp-ip
Subject:   Re: ip over x.25

James D. Barlow (ke9zd@gagme.chi.il.us) wrote:
: Howdy,
: i'm looking forw a way to do tcp/ip over x.2 frames, asynch link.

  Huh, IP on X.25 is cool, but isn't X.25 a sync protocol?  Thats why
it takes a special card for PC's, the 8250 and cousins can't handle
sync, only async.

-- 
Brian W. Antoine   --------|        "Most sane people try to avoid annoying
Olivetti North AM   ||   *             wizards, whats your excuse?"
E. 22425 Appleway   ||   |/\
Spokane, WA 99220   ||   `7l==  *  *  *  *  *  *  *  (*)            "Ribbit!"
                   ====  / l   briana@tau-ceti.isc-br.com

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 1993 17:35:45 -0700
From:      dmitzel@pollux.usc.edu (Danny Mitzel)
To:        comp.protocols.tcp-ip
Subject:   Wanted: NETBLT / rate controlled file transfer


I am working on a system where I'd like to send audio/video/file transfer
over a fixed size, dedicated link.  The audio/video I can set rate limits
within the application.  Using standard FTP over TCP+slow-start for file
transfer is going to keep probing for more bandwidth until it gets a packet
loss, then back off, then start probing again.  I'm concerned that as the
TCP window opens up it's going to interfere [cause packet losses] in the
audio/video stream even though they're well behaved.

I was thinking a rate controlled protocol such as NETBLT may be more 
appropriate in this case.  My question is, is there an implementation of
NETBLT or other rate controlled file transfer protocol available?  Is there
a better [current] solution?

thanks for any info,
danny (mitzel@usc.edu)

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Jul 1993 07:04:17 GMT
From:      gnb@bby.com.au (Gregory N. Bond)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin,comp.unix.wizards
Subject:   Re: more details on galcial ftp transfer problem

In article <matt.743353416@emily> matt@emily.math.binghamton.edu (Matt Brin) writes:

   We are a lan in two pieces.  Our subnet mask is 255.255.255.128 or,
   equivalently, 0xffffff80.  One piece has net number 128.226.2.0 and
   the other piece has net number 128.226.2.128.....  
   On the "outer side" of our _router is net 128.226.1.0
   and the netmask on this side is 255.255.255.0 or, equivalently,

Bingo.  You are telling this machine (_router) that the _same_ class B
net (128.226) has two different netmasks.  This is not allowed!

Greg.
--
Gregory Bond <gnb@bby.com.au> Burdett Buckeridge & Young Ltd Melbourne Australia
   Knox's 386 is slick.            Fox in Sox, on Knox's Box
   Knox's box is very quick.       Plays lots of LSL. He's sick!
(Apologies to John "Iron Bar" Mackin.)

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Jul 1993 08:28:28 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Internet address  transalation

This question may have arisen before, but there may be new ideas 
and answers:

A large organisation for which I provide consultancy needs to establish 
a small quantity of interactive links from IP entities scattered
within its boundaries.

It is building up a closed IP internet for its own internal use, and is
allocating NON-registered IP addresses for some very important reasons:

    -   Some 98% of the users will not need and will not be allowed 
	interactive access to the Internet.

    -   There is no commercial or business reason why this 
	organisation should (globally) have any correspondence
	or computing activity with the Internet.

    -   The organisation has a suballocation of a Class B address 
	space (ie. registered address space) with eleven bits.  
	This is insufficient to identify, let alone address all the 
	real IP hosts/entities within its growing boundary.

We would like to continue applying the NON-registered IP addresses
internally for all the right internal reasons, but wish to allow a small
quatity (<100) selected users/PCs/hosts a notional or "virtual" real 
Internet address from this registered IP address space. 
We would therefore like to perform address translation at each router 
at the boundary of the organisation.  

That is, for an outgoing packet from source IP address:

	 {internal s-addrX}

the address transalator should rewrite the source address to be:

	{external s-addrX},  by referring to a lookup table

(which we would be content to maintain manually).

Any incoming packet from the Internet with {external d-addrX} would 
have its address converted to {internal d-addrX} and passed into
the organisation's internal internet.

Can anyone give advice on this process?

Do any organisations have experience of doing this?

Are there any commercial, PD or other sources of address transalation
software for this purpose?

The last time a similar set of queries came up, there were several 
replies relating to firewalls, and several respondents recommended 
looking at certain firewalls interest groups.

However, I believe the requirement described above is not a "firewalls"
issue.  It is one of straight address translation and one-to-one mapping 
from selected addresses in a large unregistered space to a small number 
of officially allocated registered Internet addresses.

Thanks in advance for comments, advice and guidance.

-- 

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 1993 09:13:17 GMT
From:      beepy@nfsvax.Eng.Sun.COM (Brian Pawlowski)
To:        comp.protocols.tcp-ip
Subject:   [fwd] NFS Version 3

[Delete now if not interested in the Version 3 NFS protocol.
This was posted to comp.protocols.nfs, and I thought might be
some interest here]

***************************************************************************

    ANNOUNCING AVAILABILITY OF THE NFS VERSION 3 PROTOCOL SPECIFICATION

***************************************************************************

A new version of the NFS protocol has been developed and implemented.
The specification of this new version has been developed with the
cooperation of several vendors active in the NFS community.  Several
implementations based on this specification will be tested at this
year's Connectathon in San Jose.  Availability of implementations of
this new version will be discussed at a later time.

A specification describing the new protocol is available via anonymous
ftp from:

        ftp.uu.net:/networking/ip/nfs/NFS3.spec.ps.Z
        bcm.tmc.edu:/nfs/nfsv3.ps.Z
        gatekeeper.dec.com:/pub/standards/nfs/nfsv3.ps.Z

The specification is available as a compressed postscript file.

NOTE: this specification supercedes any previous version of an NFS
Version 3 specification that you might have in your possession.

Version 3 specification that you might have in your possession.

This version of the NFS protocol features 64 bit support, exclusive
create, ACCESS over the wire, and support for asynchronous writes.  In
addition, the protocol includes support for increased performance which
is attributable to an improved client caching model, relaxed transfer
size restrictions, and a reduction in the number of GETATTR operations
that a client must make.  All of the field overloads which existed in
Version 2 implementations have been replaced with direct support in the
new protocol.

Also included are new versions of the MOUNT and NLM protocols.  The new
MOUNT protocol contains support for returning NFS Version 3 file
handles as well as returning RPC authentication flavors supported by
the server.  The new NLM protocol includes 64 bit support and improved
error handling.

Questions and/or comments should be directed to nfs3@eng.sun.com.

        Thanx...

                Peter Staubach
                NFS Engineering
                SunSoft

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Jul 1993 09:15:02 GMT
From:      WhiskerP@lgwct.logica.com (Peter Whisker)
To:        comp.protocols.tcp-ip
Subject:   Re: ip over x.25

In article <1993Jul21.162758.14030@serveme.chi.il.us> ke9zd@gagme.chi.il.us (James D. Barlow) writes:
>From: ke9zd@gagme.chi.il.us (James D. Barlow)
>Subject: ip over x.25
>Date: Wed, 21 Jul 1993 16:27:58 GMT


>Howdy,
 
>i'm looking forw a way to do tcp/ip over x.2 frames, asynch link.
 
>hopefully, a commercially supported product.  
 
>the platform is Interactive unix 5.3.2.
 
>Thanks in advance for any help you may be able to offer.
 
>--
>jim@ke9zd.chi.il.us

It is possible to get a product in the UK which does this. Contact
unipalm@unipalm.co.uk (phone + 44 223 250100, fax +44 223 250101).

They market a PC card from Software Forge which provides a TCP/IP packet
driver interface to X.25 with leased line or autodial.

Software Forge are also developing an ISDN interface (I believe).

The idea is that when your IP product (PC/TCP, PC/NFS etc) opens a TCP/IP
session, the card sets up the X.25 link for you.

It is compatible with RFC 1356.

This info was gathered for a recent bid, but I don't guarantee its accuracy
nor do I work for any of the companies concerned.

Peter Whisker

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 1993 11:14:14 GMT
From:      tribe@stein.u.washington.edu (tribe)
To:        comp.protocols.tcp-ip
Subject:   FAQ

Thanks
TC
tribe@stein.u.washington.edu
"1993 that's the year we'll all be free"- Nivek Ogre



-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 93 19:13:39 MDT
From:      slkst@cc.usu.edu
To:        comp.protocols.tcp-ip
Subject:   Conferencing over internet+ X Env



I wanted to know what kind of programs are existing, for providing
a conferencing ability over the Internet.  That is something similar 
to TALK, only conferencing capable.

I also would, like to know what kind of features they provide

like

- X window  environment 
- Other user friendly facilities 

and whatever else.


Thanks   
Please Email to   rajivg@sysdiv.sdl.usu.edu
               or slkst@cc.usu.edu
Thanks a bunch
Rajiv Goyal

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Jul 1993 19:43:07 EST
From:      erickson@alee.UUCP (Lee C. Erickson)
To:        comp.protocols.tcp-ip
Subject:   Experience with Softerm Groupware?

Can anyone share their opinion of "Softerm Groupware" by Softronics, Inc.?

-----------------------------------------------------------------
Lee Erickson                uucp: erickson@alee.UUCP
    WS3J		internet: erickson%alee@VFL.Paramax.COM

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Jul 1993 16:19:23 GMT
From:      ronf@mazel. (Ron Feigen)
To:        comp.protocols.tcp-ip
Subject:   Help!!!!!!!! where to get TCP/IP stack for PCs


Help please!

  I am currently developing a TCP/IP socket appl. for windows.  This product will be 
distributed (hopefully) hither and yon.  My problem is getting a TCP/IP stack.  I
bought 
the Novell SDK under the impression that no fee was required to distribute the product.
Well that was partially true, you can distribute the stuff built with their toolkit
but you must pay $10,0000 per year to distribute the TCP/IP stack.  Ouch!!!!!!!!!!!

If ANYBODY has ANY info on this subject please respond!


Thanks in advance,


Ron Feigen

  

---

>
Ron Feigen
ronf@panther.mot.com


-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 93 16:31:22 GMT
From:      braun@kadsma.kodak.com (Curtis Braun)
To:        comp.protocols.tcp-ip
Subject:   Ethernet card Drivers for Interactive?


Hi, I have been given an offer to buy a copy of interactive unix sysV rel3.
(ver 2.3.x) I need to know if there are ethernet card drivers for this
for the NE2000 (or clone) or the Intel card. I know I can't get
it to work with a 3c501 card. I know that it will take the 3c503 and
wd card. I'd really like a 16 bit ( I don't have interupts left).

Thanks.....
-- 
Curtis Braun (curtis@computronics.com) (n2hkd) braun@telstar.kodak.com
Computronics, POBOX 1002 Fairport,NY 14450 
Guest@Digital Telstar,Network Operations Center Kodak 

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 93 20:50:22 GMT
From:      cpham@uts.amdahl.com
To:        comp.unix.questions,comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Telnet flow control

hi,

following is an excerpt from telnet man page:

.......

          set argument value
          unset argument ...
    
          ..........

                      start
                           If the TELNET TOGGLE-FLOW-CONTROL option
                           has been enabled, then this character is
                           taken to be the terminal's start character.
                           The initial value for the start character
                           is taken to be the terminal's start
                           character. 
                     
                      stop If the TELNET TOGGLE-FLOW-CONTROL option
                           has been enabled, then this character is
                           taken to be the terminal's stop character.
                           The initial value for the stop character is
                           taken to be the terminal's stop character.

.......


now my questions are:

1.  what flow control is this?  is it the local flow control at my
physical terminal (client side) or the flow control at the pseudo-
terminal (host side where telnetd runs)?

2.  how do i enable/disable/toggle FLOW-CONTROL?  i checked and there
is no telnet command to enable/disable/toggle FLOW-CONTROL.

i searched telnet source codes and found this option TELOPT_LFLOW
and the mode flag MODE_FLOW and they are used during sub-options
negotiation.  it looks like the flow control is enabled/disabled
through negotiation between the client and server.  user has no
control over it.  if my assumption is correct, why does the man page
imply (at least to my understanding) that flow control could be
toggled on/off (by user, presumably)?

you can post or e-mail me at 

cpham@uts.amdahl.com

thanks,



-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 1993 21:19:14 GMT
From:      lanshark@llnl.gov (Pearce Turpin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP - Novell - WAN from HELL!

OK! Sorry gang! No one gets the food. The vendor of the proprietary software turned up the HEAT on Racal/Interlan after coming to the same conclusion at their site, and wouldn't you know it, two days later a new driver turned up that WORKED. YEAY!

...and thanks to Hugo, the only other NP627 user I could find on the face of the earth, or at least, cyberspace.

Pearce Turpin
lanshark@llnl.gov


-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 1993 21:59:53 GMT
From:      nicholas@picard.computone.com (Nick Hennenfent)
To:        comp.protocols.tcp-ip
Subject:   Weird Urgent Packets


Hello,

I am running the following configuration -


------------------------------------
     |                    |
+---------+          +----------+        +------------+
| univell |          | terminal |        | 486 dos pc |
| 486 pc  |          |  server  |        |   procomm  |
+---------+          +----------+        +------------+
                              |                 |
                              +-----------------+


I run rlogin to connect to the univell host.
I am using ZMODEM to transfer a file from the
univell host to the dos pc. There were problems.

I used our SNIFFER network analyzer to look at the packets.

The univell host sends LOTS of ACK packets during the
file transfer with the URGENT flag set. Which is unexpected
but would probably be ok except for the fact that the
URGENT POINTER in the header is much larger than the
amount of data in the packets. Most of the time there
is no data (the are just acknowledgements, after all)
and there is that urgent pointer pointing into outer
space.

It seems that eventually these weird packets make the
terminal server sick.

Anybody ever seen anything like this???
Is there any chance that this is actually correct
and/or normal behavior???

Nick Hennenfent
nicholas@computone.com


-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 1993 19:36:06 +0200
From:      szymon@galaxy.uci.agh.edu.pl (Szymon Sokol)
To:        comp.os.vms,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Meeting Announcement: Internet Security Concepts

nyseclug@rlgsc.com wrote:
:              Internet Security Concepts and Approaches
:                      Tuesday, July 27, 1993
:                       6:00 p.m. - 8:00 p.m.
 
: If you plan to attend, please RSVP by Monday, March 8 to:
                                                ^^^^^^^
May be difficult to do...
-- 
U     U  M     M  M     M  Szymon Sokol -- Network Manager
U     U  MM   MM  MM   MM  University of Mining and Metallurgy, Computer Center
U     U  M M M M  M M M M  ave. Mickiewicza 30, 30-059 Krakow, POLAND
 UUUUU   M  M  M  M  M  M  TEL. +48 12 338100 EXT. 2885    FAX +48 12 338907

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Jul 1993 23:49:21 GMT
From:      ledger@convex.com (Chad Ledger)
To:        comp.protocols.tcp-ip
Subject:   Question about 802.3 packet headers

	I seem to have misplaced my 802.3 standard.  Does the length/type
field of an ethernet header include the length of the header of is it just
the data?

	---------------------------------------------------------
	|		Chad Ledger				|
	|		CONVEX Computer Corp			|
	|		3000 Waterview Pkwy.			|
	|		Dallas, TX  75080			|
	|		ledger@convex.com			|
	---------------------------------------------------------

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Jul 1993 23:54:09 GMT
From:      poc@shaddam.usb.ve (Patrick O'Callaghan)
To:        comp.protocols.tcp-ip
Subject:   Re: Help on MacTCP

In article <dkung.743379542@co2> dkung@co2.mnet.uswest.com (Darwei Kung) writes:

   Hi, I have a problem with MacTCP subnetting.  For class B addresses,
   MacTCP automatically applies the mask 255.255.0.0, which would mask
   out any traffic with a different network number.  I would like to turn
   this masking off in MacTCP, but I couldn't find how to do that in any
   documentation.  Any hints on how to disable the subnet masking is
   greatly appreciated.

Fire up the MacTCP extension, click on the "More..." button, and look
at the settings window. Unless the "Protected" box is checked, you can
slide a control (top right) over the binary representation of 4 octets
and set the subnet mask. I've done it often (MacTCP version 1.1.1 as
far as I remember).
--
Patrick O'Callaghan			Internet: poc@usb.ve
Departamento de Computacion		NICNAME: PO22
Universidad Simon Bolivar 		Tel: +058 (2) 906 3320, 906 3947
Apartado de Correos 89000		FAX: +058 (2) 93 71 28
Caracas, Venezuela			"There is no Net but the Internet"

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      Sat, 24 Jul 1993 16:23:57 GMT
From:      gene@aee.aee.com (Gene Kochanowsky)
To:        comp.protocols.tcp-ip
Subject:   looking for public domain TCP/IP and NFS for microVAX II on VMS????

Greetings,

	The title says it all. Please reply to gene@aee.com

Later

Gene Kochanowsky
-- 
Gene Kochanowsky                           | "And remember ....
Associated Electronic Engineers, Inc.      |       The better you look ... 
(904)893-6741 Voice, (904)893-1270 Fax     |       the more you will see."
gene@aee.com                               |               Miss Lidia

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      Sun, 25 Jul 93 04:23:16 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Internet address transalation

In article <743416108snz@peeras.demon.co.uk> proyse@peeras.demon.co.uk writes:

   We would like to continue applying the NON-registered IP addresses
   internally for all the right internal reasons, but wish to allow a small
   quatity (<100) selected users/PCs/hosts a notional or "virtual" real 
   Internet address from this registered IP address space. 
   We would therefore like to perform address translation at each router 
   at the boundary of the organisation.  
   
   That is, for an outgoing packet from source IP address:
   
            {internal s-addrX}
   
   the address transalator should rewrite the source address to be:
   
           {external s-addrX},  by referring to a lookup table
   
   (which we would be content to maintain manually).
   
   Any incoming packet from the Internet with {external d-addrX} would 
   have its address converted to {internal d-addrX} and passed into
   the organisation's internal internet.
   
   Can anyone give advice on this process?

I thought of a similar idea back in December, which I was going to
call SSLIP.  This is where a TCP package would connect to a SLIP
server using a fixed class C IP address allocated for that purpose.
The SLIP server would then translate the address into the *real*
addresses it was serving for.  The idea was to make it much simpler
to configure and use SLIP.

I don't think it can be done.  For example, FTP sessions contain the
IP address quoted in the control stream.  And even though that one
might be fixed via hackery, I'm sure that there are other protocols
that peek down into the IP layer.

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 1993 05:46:58 GMT
From:      acagney@macadam.mpce.mq.edu.au (Andrew Cagney - aka Noid)
To:        comp.os.386bsd.questions,comp.protocols.tcp-ip,comp.unix.bsd
Subject:   Bootpc (not bootps/bootpd) for (386)BSD?

Hello,

Has any one implemented a bootp client for (386)BSD?  Such a client
could turn on the IP network during a BSD host's boot process with out
having to use hardwired values.

Am I correct in assuming that such a bootp client would (could) be
implemented using bpf (Berkeley Packet Filter)?

				Andrew - aka Noid

(Please don't confuse this with bootpd, a bootp server)
(If all else fails I suppose I could hack my bootp/tftp prom code :-)

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 93 01:34:56 GMT
From:      severin@csrd.nkk.co.jp (Severin)
To:        comp.protocols.tcp-ip
Subject:   NFS modeling/simulation/analysis

Greetings!

I have two requests:

(1) I would like some quick details on what to look at or expect when
analysing NFS for performance. I really don't know what I'm getting
into, so I just want some quick details.

(2) Can someone please recommend some good books or technical papers
on NFS modeling and analysis? I don't have a big budget or lots of
time, but I do need to know what is going on at a fairly high level of
abstraction.

Thanks im advance!


Severin Beauvais
C.Sc. Co-op student
University of Victoria, BC, CANADA
--

--------------------------------------+----------------------------------------
   Severin Beauvais                 |   On work term with...
   Dept of Computer Science        |      コンピュータシステム研究部
   Co-op Japan Program             |      エレクトロニクス研究所
   University of Victoria           |      NKK
   Canada                            |      Kawasaki, Japan
--------------------------------------+----------------------------------------

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Jul 1993 02:37:11 GMT
From:      jackl@pribal.uucp (jack lowry)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   TCP/ip printer interfaces

[ Article crossposted from comp.dcom.lans.ethernet ]
[ Author was jack lowry ]
[ Posted on Mon, 26 Jul 1993 02:35:03 GMT ]

Hi all I need suggestions on a device to connect to thin ethernet
talk tcpipi, with an interface to a parallel printer, and accept 
print jobs from a SCO unix box running tcpip and lpd.

I have seen one such item in UNIX catolog but I can't seem put my 
finger on it right now. 
Thanx, Jackl

Ps. Please either port or mail to wb3ffv.ampr.org!pribal!jackl
as I messed up my map entry, and the correct one is not out yet.
Thanx again.

---------------------------------------------------------------
Jack Lowry Prism Medical Systems  |186000 mps not just a good 
jackl@pribal.uucp                 |idea....it's the law
---------------------------------------------------------------

-- 
---------------------------------------------------------------
Jack Lowry Prism Medical Systems  |186000 mps not just a good 
jackl@pribal.uucp                 |idea....it's the law
---------------------------------------------------------------
-- 
---------------------------------------------------------------
Jack Lowry Prism Medical Systems  |186000 mps not just a good 
jackl@pribal.uucp                 |idea....it's the law
---------------------------------------------------------------

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Jul 93 05:45:08 GMT
From:      minich@a.cs.okstate.edu (Robert Minich)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet address transalation

proyse@peeras.demon.co.uk writes:
>    We would like to continue applying the NON-registered IP addresses
>    internally for all the right internal reasons, but wish to allow a small
>    quatity (<100) selected users/PCs/hosts a notional or "virtual" real 
>    Internet address from this registered IP address space. 
>    We would therefore like to perform address translation at each router 
>    at the boundary of the organisation.  
>    
>    That is, for an outgoing packet from source IP address:
>    
>             {internal s-addrX}
>    
>    the address transalator should rewrite the source address to be:
>    
>            {external s-addrX},  by referring to a lookup table
>    
>    (which we would be content to maintain manually).
 ...    
>    Can anyone give advice on this process?
 
by nelson@crynwr.com (Russell Nelson):
> I thought of a similar idea back in December, which I was going to
> call SSLIP.  This is where a TCP package would connect to a SLIP
> server using a fixed class C IP address allocated for that purpose.
> The SLIP server would then translate the address into the *real*
> addresses it was serving for.  The idea was to make it much simpler
> to configure and use SLIP.
> 
> I don't think it can be done.  For example, FTP sessions contain the
> IP address quoted in the control stream.  And even though that one
> might be fixed via hackery, I'm sure that there are other protocols
> that peek down into the IP layer.

Such as TCP, which uses a checksum that covers (among other things) a source
and destination IP address that are NOT inside the actual packet.

From RFC 793:

    The checksum also covers a 96 bit pseudo header conceptually
    prefixed to the TCP header.  This pseudo header contains the Source
    Address, the Destination Address, the Protocol, and TCP length.
    This gives the TCP protection against misrouted segments.  This
    information is carried in the Internet Protocol and is transferred
    across the TCP/Network interface in the arguments or results of
    calls by the TCP on the IP.
 
                     +--------+--------+--------+--------+
                     |           Source Address          |
                     +--------+--------+--------+--------+
                     |         Destination Address       |
                     +--------+--------+--------+--------+
                     |  zero  |  PTCL  |    TCP Length   |
                     +--------+--------+--------+--------+

-- 
Robert Minich
minich@a.cs.okstate.edu   | "Maybe awake is what's left at the end
Oklahoma State University |  of dreaming"

-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 93 15:07:05 CDT
From:      mcginnis@kuhub.cc.ukans.edu
To:        comp.protocols.tcp-ip,biz.jobs.offered
Subject:   WANTED: TCP/IP app developer, C++, MS-Windows

My personel consultant friend is looking for a communications
software developer for TCP/IP and related protocols.  C++
and MS Windows experience.  5 years minimum commercial experience
required.  $55,000/year plus profit sharing plus bonus plus
relocation plus benefits.

If you're interested let me know fast.  They want to hire now.

Michael McGinnis                Internet: mcginnis@kuhub.cc.ukans.edu
Computer Center                   Bitnet: mcginnis@ukanvax
University of Kansas               Voice: (913)864-0413
Lawrence, KS  66045                  FAX: (913)864-0485

Rust never sleeps.


-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Jul 1993 13:51:06 GMT
From:      pen@lysator.liu.se (Peter Eriksson)
To:        comp.protocols.tcp-ip
Subject:   Re: On the usefulness of the ident service (Was: FTP - Port # 113 - query)

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

>What I do not understand is why people care about port 113 for
>anonymous FTP.  Maybe port 113 is mildly interesting and vaguely useful
>for normal FTP, rlogin, telnet, rsh, rexec, and LAT (yes, LAT, why
>not?), where you want to authenticate the user to know what is authorized.

I don't think anyone seriously needs to use IDENT to identify
anonymous FTP users. However, it can occasionally be useful. I know
that I have more than once put up programs for anonymous FTP just to
find a fatal bug in the program, and put up a new version a short
while after. Then it was useful to be able to see which users FTP'd
the buggy version so I could email them about the new version.

Not all users type in their email address at the password prompt. Many
many enter things like "guest" instead (since there are FTP servers
who wants that...).

But it's not really a big deal.

I find it much more interresting in conjunction with SMTP to make it
a little harder to forge emails without a trace.

/Peter



--
Peter Eriksson                                            pen@lysator.liu.se
Lysator Academic Computer Society               ...!uunet!lysator.liu.se!pen
University of Linkoping, Sweden                           <Something boring>

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Jul 1993 14:04:29 GMT
From:      Alain Struyf <astruyf@UB.com>
To:        comp.protocols.tcp-ip
Subject:   Re: Internet address  transalation

In article <743416108snz@peeras.demon.co.uk> Phil Royse,
proyse@peeras.demon.co.uk writes:
> We would like to continue applying the NON-registered IP addresses
> internally for all the right internal reasons, but wish to allow a small
> quatity (<100) selected users/PCs/hosts a notional or "virtual" real 
> Internet address from this registered IP address space. 
> We would therefore like to perform address translation at each router 
> at the boundary of the organisation.  

I wouldn't try to perform address translation. Depending on what these
100 or so users are supposed to do with the internet, several options
exist. One of the easiest to implement, is to put a host (simple UNIX
machine will do) on the "official" side of your network, and to give
these 100 users an account on that machine. They can now surely do
telnet, ftp, mail etc...

If needed, you can run mailgateways, ftp proxyservers etc... on this
host. All the software combined can probably give you an almost
transparant connection from your "non-registered" net to the "official"
net.

Alain.

Ungermann-Bass Benelux (Brussels-Belgium)
e-mail: astruyf@ub.com

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 1993 16:51:54 GMT
From:      booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet,comp.protocols.nfs
Subject:   Need info on NFS performance over Ethernet


I'm looking for information on the performance of NFS over Ethernet.  That's
about as succinct as I can make it.  Any pointers would be greatly appreciated.
Thanks in advance.

regards,
mb
-- 
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948
Disclaimer:  booloo speaks for booloo and no other.

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 1993 17:35:40 GMT
From:      nisc@nisc.sri.com
To:        comp.protocols.tcp-ip
Subject:   Internet Domain Survey

Network Information Systems Center                                July 1993
SRI International                                    Internet Domain Survey

 The Domain Survey attempts to discover every host on the Internet by doing a
 complete search of the Domain Name System.  The latest results gathered
 during mid-July 1993 are listed.  For more information see RFC 1296; for
 more info see the pub/zone directory on ftp.nisc.sri.com.
                                                          -- Mark Lottor


   Number of Hosts, Domains, and Nets Advertised in the Domain Name System

           July 1993     Apr 93     Jan 93     Oct 92    Jul 92   Change (year)
 ==============================================================================
 Hosts:    1,776,000  1,486,000  1,313,000  1,136,000   992,000       79%

 PingReply:  464,000    421,000
  %ofHosts:      26%        28%

 Domains:     26,000     22,000     21,000     18,100    16,300       59%

 Nets:
  Class A:        67         58         54         52        60       12%
  Class B:      3728       3409       3206       2985      2714       37%
  Class C:      9972       6255       4998       4468      3795      163%
 Total:        13767       9722       8258       7505      6569      110%


                Host Distribution by Top-Level Domain Name

    539668 edu    27033 fi      3165 nz        498 my         19 bg
    460848 com    25151 no      3092 cs        455 si         15 ro
    109550 gov    18305 net     2734 cz        415 tr         13 tn
     91987 de     14746 it      2093 mx        349 su         13 gb
     89788 uk     11741 at      1956 pt        298 ve         10 lv
     88163 mil     8773 es      1802 sg        238 ee          4 aq
     82157 au      7337 za      1728 ie        223 sk          3 ua
     70977 ca      6232 hk      1403 hu        186 lu          2 yu
     39860 fr      6160 dk      1340 us        175 int         2 li
     39359 org     5625 kr      1317 gr        110 in          2 ar
     35639 jp      5469 tw      1259 is        101 ec
     35629 nl      5244 il      1101 br         61 th
     31449 se      4361 be      1073 cl         56 cr
     30697 ch      3511 pl       504 hr         30 cy


                Host Distribution by Top-Level Domain Name
                      of Hosts Responding to a Ping		

    163532 edu     7194 nl       872 il        286 sg         30 ec
     87602 com     6864 se       805 za        214 hu         20 hr
     42431 gov     5297 org      795 hk        128 tr         16 cy
     26462 de      5068 fi       670 pl        123 my          9 lv
     24986 uk      4628 it       551 br        117 si          6 gb
     23865 mil     2809 at       549 gr         70 sk          4 bg
     23479 ca      2259 tw       517 cs         70 ee          3 ro
     13966 jp      2115 es       381 cz         64 ve          2 li
     12713 fr      1907 dk       378 us         64 int         1 yu
     11886 au      1775 kr       329 is         52 in          1 tn
      7943 ch      1217 be       327 cl         40 lu
      7498 net      937 nz       321 pt         38 su
      7320 no       908 mx       300 ie         34 cr


                              Top 50 Host Names

     795 venus     578 mac2      446 mac4      410 titan     381 calvin
     747 pluto     569 charon    443 pc3       401 sirius    378 phoenix
     710 cisco     545 iris      442 alpha     398 fred      378 pc4
     675 mars      539 mercury   434 apollo    394 gateway   378 mac13
     672 gw        524 pc2       426 mac10     393 merlin    375 mac8
     659 zeus      496 mac3      423 mac5      391 hobbes    371 mac14
     640 jupiter   484 orion     419 thor      385 mac6      368 athena
     615 mac1      478 eagle     418 ns        384 mac12     364 mac9
     613 pc1       461 newton    416 hermes    382 mac7      360 mac15
     607 saturn    459 neptune   411 gauss     381 mac11     356 ariel


                Frequently Asked Questions about the Domain Survey

 What do all those domain names stand for?
    See pub/zone/iso-country-codes on ftp.nisc.sri.com.

 Why do only 26% of the advertised hosts answer a ping?
    Many advertised hosts are behind firewalls that only allow email
    to get through.  Technically, they would not be considered hosts
    that are directly on the Internet.  Smaller hosts such as PCs might
    be turned off when they are not in use.  Also, some pings are probably
    lost due to links being down, and/or problems with the pinging process.

 Where can I get more information?
    See the pub/zone directory on ftp.nisc.sri.com.

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Jul 1993 17:18:44 CET
From:      Lefort Thierry <TLEFORT@ESTEC.BITNET>
To:        comp.protocols.tcp-ip
Subject:   bandwidth limitation

Hello,
I am trying to find a way to limit the throughput of FTP transfers:
We have several client-server applications with well defined through-put over
a network which has a well defined bandwidth as well (part of it is leased-
line). We face the problem of having file transfers taking as much bandwidth
as they can, slowing down the client-server applications for which we must
keep the data rate as constant as possible (yet with a bit of flexibility
because it's Tcp/ip!). We know exactly how much should be allocated as an
upper limit to these FTP transfers. Any help on how to implement this
limitation would be appreciated.
Thanx,
Thierry Lefort
TLEFORT@ESTEC.BITNET


-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 1993 16:34:58 +0200
From:      szymon@galaxy.uci.agh.edu.pl (Szymon Sokol)
To:        comp.protocols.tcp-ip
Subject:   Extra bytes in Telnet packet?

I have recently played with etherfind to look at TCP packets. I have noticed
a strange thing: some of Telnet packets (i.e. TCP packets destined for port 23)
have extra bytes appended. Example:

Using interface le0
                                            icmp type
 lnth proto         source     destination   src port   dst port
   60  tcp             noc          galaxy       1278     telnet
 08 00 20 11 dd 1c 08 00 20 0d 3b 92 08 00 45 00
 00 29 a9 72 00 00 3c 06 ea 12 95 9c 60 08 95 9c
 60 09 04 fe 00 17 3e a6 16 18 6c 50 84 3c 50 18
 10 00 f7 20 00 00 73 32 50 18 10 00
                   ^^^^^^^^^^^^^^^^^
I have underlined the contents of this packet - everything preceding them are
MAC-level (14 bytes), IP header (20 bytes) and TCP header (20 bytes).
What is strange: this packet should contain only the first of those 6 bytes -
0x73 for 's' character, which I actually typed. What are the remaining 5 bytes?
Kind of checksum or padding? I have not found any mention of such appendices
in RFCs: 791 (IP), 793 (TCP), 854 (Telnet), so what are they and where are they
described?
TIA,
-- 
U     U  M     M  M     M  Szymon Sokol -- Network Manager
U     U  MM   MM  MM   MM  University of Mining and Metallurgy, Computer Center
U     U  M M M M  M M M M  ave. Mickiewicza 30, 30-059 Krakow, POLAND
 UUUUU   M  M  M  M  M  M  TEL. +48 12 338100 EXT. 2885    FAX +48 12 338907

-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Jul 1993 20:32:19 GMT
From:      mark@alias.com (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: setsockopt - how to do two options?

In <1993Jul22.183605.24923@Octopus.COM> peterg@eng.krldwa.mccaw.com (Peter Gregory) writes:

>Hi...
 
>I want to set SO_REUSEADDR and SO_KEEPALIVE on a TCP socket.  Is there
>a way to set both options in a single setsockopt call?  Or, must I 
>call setsockopt twice?

[rest deleted]

You have to call setsockopt() twice.

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 1993 17:39:07 +0200
From:      szymon@galaxy.uci.agh.edu.pl (Szymon Sokol)
To:        comp.protocols.tcp-ip
Subject:   Re: Extra bytes in Telnet packet?

Szymon Sokol (szymon@galaxy.uci.agh.edu.pl) wrote:
: I have recently played with etherfind to look at TCP packets. I have noticed
: a strange thing: some of Telnet packets (i.e. TCP packets destined for port 23)
: have extra bytes appended. Example:

I have received 4 messages reminding me about the minimum packet length of
Ethernet. In short, my mysterious bytes were padding bytes added by 
Ethernet rather than by Telnet or TCP/IP. Thanks to everyone who responded.
-- 
U     U  M     M  M     M  Szymon Sokol -- Network Manager
U     U  MM   MM  MM   MM  University of Mining and Metallurgy, Computer Center
U     U  M M M M  M M M M  ave. Mickiewicza 30, 30-059 Krakow, POLAND
 UUUUU   M  M  M  M  M  M  TEL. +48 12 338100 EXT. 2885    FAX +48 12 338907

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 1993 01:34:37 GMT
From:      vsnyder@math.jpl.nasa.gov (Van Snyder)
To:        comp.protocols.tcp-ip
Subject:   Packet capture

I saw the recent summary about packet sniffers.  I spent most of the day
downloading things, poking around in Archie and Gopher, and various
archives.  Nothing I found would even COMPILE under HP-UX version 8.07.
This is a pretty much vanilla SVR4-kind of system.

Does anybody know of a packet capturer/analyzer/displayer that runs on HP-UX,
or is known to run on vanilla SVR4?  I got netwatch from gatekeeper, and
it even has a special setup for SVR4, but it ended up wanting some includes
that aren't on my system -- strings.h, etc.

The problem I'm trying to solve is the following:
We have a PC running OS/2 2.1, but it doesn't have a backup device.  So we
put up NFSD on it.  When we try to mount from it, it says it can't find
the client name it it's exports file.  IBM insists there's something wrong
with HP's NFS, but we have no trouble mounting volumes exported by HP or Sun.

So, I'd like to see the packet/s that gets sent to the OS/2 machine when the
HP machine runs mount.

Thanks in advance
-- 
What fraction of Americans believe   |  Van Snyder
Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 93 01:39:00 GMT
From:      mayshah@gandalf.rutgers.edu (Mayank Shah)
To:        comp.protocols.tcp-ip
Subject:   IBM's WINSOCK.DLL

Hi,

I was wondering if anyone has been able to use IBM's winsock.dll succssessfuly?
We have analyzed it and found that it is returning strange codes.

Any input?  Oh, by the way according to IBM "No problems have been reported."


  Mayank

--
Standards must be so important, that's why we have so many of them.


-- 
------------------------------------------------------------------------------
Mayank Shah				Rutgers University
mayshah@gandalf.rutgers.edu

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Jul 1993 02:16:17 GMT
From:      davis@unidata.ucar.edu (Glenn P. Davis)
To:        comp.client-server,comp.protocols.tcp-ip
Subject:   SunOS 5.2 (TIRPC) backward compatibility problem

The program below demonstrates a problem with the "rpc_soc"
backward compatibility interfaces in SunOS 5.2.

If we pass the svctcp_create() or svcudp_create() routine a socket which
has already been created and bound, the routine fails with the
following sort of message:

svc_tli_create: could not do t_sync: Illegal file descriptor

Looks like the descriptors coming out of the socket interface don't
interact well with the TLI functions.

At the end of this message find a sample program which demonstrates the problem
for tcp. The sample works for all pre TLI ONC RPC implementations I have access
to.  I also believe it worked on SunOS 5.1.

Glenn P. Davis
UCAR / Unidata
PO Box 3000                   3300 Mitchell Lane, Suite 170
Boulder, CO 80307-3000        Boulder, CO  80301

(303) 497 8643

--- cut here ---
/* cc this.c -lsocket -lnsl */
#define PORTMAP
#include <rpc/rpc.h>
#include <syslog.h>


/*
 * Create a socket of type "udp" or "tcp" and bind it
 * to port.
 * Return the socket or -1 on error.
 */
int
sockbind(type, port)
char *type ;
unsigned short port ;
{
	int sock = -1 ;
	struct sockaddr_in addr ;
	int len = sizeof(struct sockaddr_in) ;

	if(type == NULL)
		return -1 ;

	if(*type == 't')
		sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) ;
	else if(*type == 'u')
		sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP) ;

	if(sock == -1) 
		return -1 ;

	/*
	 * Eliminate problem with EADDRINUSE for reserved socket.
	 * We get this if an upstream data source hasn't tried to
	 * write on the other and we are in FIN_WAIT_2
	 */
	if(*type == 't')
	{
		int on = 1 ;
		(void) setsockopt(sock, SOL_SOCKET, SO_REUSEADDR,
			(char *)&on, sizeof(on)) ;
	}

	(void) memset((char *)&addr, 0, len) ;
	addr.sin_family = AF_INET ;
	addr.sin_addr.s_addr = INADDR_ANY ;
	addr.sin_port = htons(port) ;

	if(bind(sock, (struct sockaddr *)&addr, len) < 0)
	{
		(void) close(sock) ;		
		return -1 ;
	}

	return sock ;
}


/*
 * Demonstrate problem with TIRPC in SunOS 5.2
 */
main(int argc, char *argv[])
{
	int sock ;
	SVCXPRT *transp;

	openlog(argv[0], (LOG_CONS|LOG_PID), LOG_LOCAL0) ;

	sock = sockbind("tcp", 2388) ;
	if(sock < 0)
	{
		syslog(LOG_ERR, "sockbind tcp") ;
		exit(1) ;
	}
	/* else */

	transp = svctcp_create(sock, 0, 0);
	if (transp == NULL) {
		syslog(LOG_ERR, "cannot create tcp service: %m");
		exit(2);
	}
	/* else */

	printf("All is well\n") ;

	exit(0) ;
}

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 93 03:11:11 GMT
From:      matt@emily.math.binghamton.edu (Matt Brin)
To:        comp.protocols.tcp-ip,comp.unix.solaris,comp.sys.sun.admin
Subject:   SUN as bridge? arpserve under solaris 2?

Can a SUN workstation running Solaris 2.1 act as a smart (filtering)
bridge?  If arpserve has been ported to Solaris 2, then the answer
is yes.  Has anyone done such a port?  Is there another way to do it?
The only version of arpserve that I am aware of uses /dev/nit which
does not seem to exist in Solaris 2.  Is there a standard way to get
around this?

I know that pcroute and pcbridge exist, but in this era of worrying
about footprints, why introduce an extra piece of hardware?
_____________________________________________________________________________
matt brin / math. dept / SUNY / Binghamton, NY 13902-6000 / (607)-777-2147
matt@math.binghamton.edu      	INTERNET
mbrin@bingvaxa			BITNET
-----------------------------------------------------------------------------

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Jul 1993 05:08:31 GMT
From:      zpg@snoopy.mmk.e-technik.tu-muenchen.de (Zwickenpflug)
To:        comp.protocols.tcp-ip,comp.unix.solaris,comp.sys.sun.admin
Subject:   Re: SUN as bridge? arpserve under solaris 2?

In article <matt.743742671@emily>, matt@emily.math.binghamton.edu (Matt Brin) writes:
|> Can a SUN workstation running Solaris 2.1 act as a smart (filtering)
|> bridge?  If arpserve has been ported to Solaris 2, then the answer
|> is yes.  Has anyone done such a port?  Is there another way to do it?
|> The only version of arpserve that I am aware of uses /dev/nit which
|> does not seem to exist in Solaris 2.  Is there a standard way to get
|> around this?
|> 
|> I know that pcroute and pcbridge exist, but in this era of worrying
|> about footprints, why introduce an extra piece of hardware?
|> _____________________________________________________________________________
|> matt brin / math. dept / SUNY / Binghamton, NY 13902-6000 / (607)-777-2147
|> matt@math.binghamton.edu      	INTERNET
|> mbrin@bingvaxa			BITNET
|> -----------------------------------------------------------------------------

-- 

As far as I know, arpserve does only answer arp requests. Does
anyone know, how to get a SUN (with Solaris 1.x) to work as
a bridge? I think there is additional filtering software
necessary.


Yours sincerely,
Mit freundlichen Gruessen,

Robert Zwickenpflug

                                ,,,
                               (o o)
+--------------------------oOO--(_)--OOo----------------------------------+
| Robert Zwickenpflug                                                     |
| Lehrstuhl Mensch-Maschine-Kommunikation ( Human-Machine-Communication ) |
| Technische Universitaet Muenchen ( Technical University Munich )        |
| smail:  Arcisstrasse 21, 80290 Muenchen, Germany                        |
| email:  zpg@mmk.e-technik.tu-muenchen.de                                |
| phone:  ++49 089/2105-8548                                              |
 +-------------------------------------------------------------------------+

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Jul 1993 07:51:40 GMT
From:      trk110@aixrs2.hrz.uni-essen.de (Jacek Chmielniak)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over X.25 - Help

mike@charnock.demon.co.uk (Mike Charnock) writes:
: 
: 
: 
: We need to run TCP/IP on the PS/2, co-existing with their 5250 connection
: to an AS/400 across the SDLC and X.25, and establish a VT220 session over
: TCP/IP to the VAX.  The VAX is not ours, so we can't load anything onto it -
: it already has TCP/IP.
: 

i am running OS/2 2.0 with tcp/ip 1.2.1 (this is version for 1.3 but 
"refreshed" for 2.0) it has optional part X.25. This part coexists with
Communication Mgr. You can run ip over x.25 with this package.
Documentation is not briliant, but you can make it.

jacek
------------------------------------------------------------------------------
Jacek Chmielniak                               e-mail: trk110@hrz.uni-essen.de
Uniklinikum Essen                              tel. +49-201-877.0200
Germany                                        fax. +49-201-723.4694

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      Tuesday, 27 Jul 1993 13:50:10 EST
From:      <ACAD8060@RyeVm.Ryerson.Ca>
To:        comp.protocols.tcp-ip
Subject:   TCP/IP BOOT ROMS available

Workstation management on TCP/IP networks simplified
====================================================



BootWarePLUS TCP/IP from Lanworks addresses issues of software upgrades and
security


Toronto, Ontario - June 21, 1993:

Lanworks Technologies today announced the availability of BootWarePLUS for
TCP/IP compatible networks.  BootWarePLUS TCP/IP joins the BootWarePLUS family
of Centralized Boot Systems.  These systems are used to redirect a
workstation's boot sequence to the network, giving LAN administrators complete
control over the issues of data security, virus protection, and updating
workstation drivers.

BootWarePLUS TCP/IP allows workstations to obtain their operating system (DOS,
Windows, NFS), network drivers and other files directly from the server

without requiring a boot diskette or boot related files on their hard drives.
BootWarePLUS TCP/IP consists of: the SMARTROM and initialization,
configuration and utility diskettes.  The SMARTROM, patented by Lanworks
Technologies, enhances a network interface card ROM socket by allowing read
and write access to it.  BootWarePLUS for TCP/IP supports the major Ethernet
adapters and most compatibles.


New Freedom
-----------

Prior to BootWarePLUS,  LAN managers had two choices --allow each user to boot
from local media, or use inflexible boot PROMs in conjunction with public
domain BOOTP daemons.  BootWarePLUS provides the LAN administrator with the
flexibility to use a daemon, or to store the workstation IP address, server IP
address and boot image file name in the SmartROM.  Local media functionality
can be set to allow optional local boots if required, or to force a network
boot and then release local drive functionality.  The level of security and
control is determined by the LAN administrator, and not by the limitations of
a Boot PROM.

Never change PROMS again
------------------------
t
The BootWarePLUS centralized boot system also includes easy to follow
configuration menus, and comprehensive, network operating system specific,
installation manuals. Once the BootWarePLUS PROM is installed in the
workstation, all future updates and reconfigurations are done via software.

Maintaining the image
---------------------

BootWarePLUS TCP/IP is supplied with a number of utilities which both simplify
and enhance boot image file installation and maintenance:  IMAGEN generates a
boot file from the contents on a boot diskette, MAPGEN provides the ability

to examine and edit the contents of the image file created by IMAGEGEN, and
FREEMEM, which releases all the memory that was used to transfer the boot
image file from the server to the workstation.  BootWarePLUS TCP/IP also
provides optional support for TFTP Secure Mode.


Reduce the possibility of device memory conflicts
-------------------------------------------------

To speed installation, BootWarePLUS includes a built in software product
called ROMSCAN. A diagnostic tool, ROMSCAN finds and reports detailed
information on every BIOS option ROM in the workstation.  This allows the LAN
administrator to select an address which will not conflict with other ROMs in
the workstation.

BootWarePLUS TCP/IP is available now at $79 U.S. for a 1-station package and
$595 for a 10-station package.



Lanworks Technologies inc. is the world leader in Centralized Boot software
and firmware. Over 250,000 workstations worldwide depend on Lanworks
Centralized Boot Systems to manage the issues of network security,
maintenance, and network integrity.  Lanworks Technologies can be reached at
416-238-5528.

###

Contact:   Ihor Petelycky
           Lanworks Technologies
           Tel: 416-238-5528
           Fax: 416-238-9407

Lanworks Technologies
2425 Skymark Ave., Unit 4
Mississauga, Ontario, L4W 4Y6


-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Jul 1993 16:21:58 -0400
From:      Abhijit_Khale@transarc.com
To:        comp.client-server,comp.protocols.tcp-ip
Subject:   Re: SunOS 5.2 (TIRPC) backward compatibility problem

Excerpts from netnews.comp.client-server: 27-Jul-93 SunOS 5.2 (TIRPC)
backward .. Glenn P. Davis@unidata.u (2392)

> The program below demonstrates a problem with the "rpc_soc" backward
> compatibility interfaces in SunOS 5.2.
 
> If we pass the svctcp_create() or svcudp_create() routine a socket which
> has already been created and bound, the routine fails with the following
> sort of message:
 
> svc_tli_create: could not do t_sync: Illegal file descriptor
 
> Looks like the descriptors coming out of the socket interface don't
> interact well with the TLI functions.The sample works for all pre TLI
> ONC RPC implementations I have access
> to.  I also believe it worked on SunOS 5.1.

I don't see how this could have worked on SunOS 5.1  The TI-RPC 
library tries to do TLI operations on the fd given to it, and it will na-
turally fail on an fd created with a socket. If I'm not mistaken, this 
should be documented somewhere. 

To get around this, you need to do one of the following in
decreasing order of preference : 

a) Recode your application to use tli instead. 

b) Link using the line -lrpcsoc -lsocket -lnsl, which will use the
backward compatibility librpcsoc.a library, which uses sockets, and
 hence will work with your application. 

c) Compile on an older pre-Solaris 2.0 platform and run in BCP mode. 

Abhijit

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Jul 1993 09:43:43 GMT
From:      uclyjjd@ucl.ac.uk (Julian Daley)
To:        comp.protocols.tcp-ip
Subject:   Re: Conferencing over internet+ X Env

slkst@cc.usu.edu writes:
>I wanted to know what kind of programs are existing, for providing
>a conferencing ability over the Internet.  That is something similar 
>to TALK, only conferencing capable.

See the Internet Relay Chat FAQ in alt.irc

>I also would, like to know what kind of features they provide

ircII is a termcap based unix irc client.

Julian.

--
        _____________________________________________________
       | Julian Daley,                     j.daley@ucl.ac.uk |
       | Department Clinical Physics, Guys Hospital, London. |
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 93 11:24:44 GMT
From:      matt@priscilla.math.binghamton.edu (Matt Brin)
To:        comp.protocols.tcp-ip,comp.unix.solaris,comp.sys.sun.admin
Subject:   Re: SUN as bridge? arpserve under solaris 2?

In <1993Jul27.050831.26614@news.lrz-muenchen.de> zpg@snoopy.mmk.e-technik.tu-muenchen.de (Zwickenpflug) writes:

>In article <matt.743742671@emily>, matt@emily.math.binghamton.edu (Matt Brin) writes:
>|> Can a SUN workstation running Solaris 2.1 act as a smart (filtering)
>|> bridge?  If arpserve has been ported to Solaris 2, then the answer
>|> is yes.  Has anyone done such a port?  Is there another way to do it?
 
>As far as I know, arpserve does only answer arp requests. Does
>anyone know, how to get a SUN (with Solaris 1.x) to work as
>a bridge? I think there is additional filtering software
>necessary.

You can use arpserve to give out wrong arp information.  If host A,
that bridges two wires, tells all hosts on the left side that the
ether addresses of all hosts on the right side are the ether address
of host A and it tells all hosts on the right side that the ether
addresses of all hosts on the left side are the ether address of host
A, then all packets that are supposed to cross sides will go to host A.
Now all you have to do is build routing info into host A so that host A
will send the packets along to their correct destinations.  We have done
this with Solaris 1 machines.  So I repeat my original questions.
_____________________________________________________________________________
matt brin / math. dept / SUNY / Binghamton, NY 13902-6000 / (607)-777-2147
matt@math.binghamton.edu      	INTERNET
mbrin@bingvaxa			BITNET
-----------------------------------------------------------------------------

-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 93 15:18:06 GMT
From:      tony@scotty.dccs.upenn.edu (Anthony Olejnik)
To:        comp.protocols.tcp-ip
Subject:   multiple entries (for same host w/diff. subnet) in /etc/bootptab file


Is it possible to have multiple entries in a bootptab file for a node
with the same Mac level address?

I would like to use BOOTP (on my PowerBook with a SCSI ethernet i/f)
on multiple subnets.  My backbone (CISCO AGS+) routers have IP forwarding
enabled (and pointing to the subnet on which my bootp server is running).

By manually changing bootptab, I can sucessfully boot from multiple subnets.
However, Its not convienient to manually change bootptab.  Thus, I would 
like to have multiple entries (for the same Mac level (ethernet) address).

My thought is these multiple entries would allow me to statically configure
the necessary info (IP addr, GW IP addr, Subnet Mask) for any given subnet.
Then, depending on which subnet I boot from, the correct bootptab entry will
be used as part of the response.

Any help would be *GREATLY* appreciated.
Thanks in advance.

--tony


-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Jul 1993 15:59:01 GMT
From:      hitz@netapp.com (Dave Hitz)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet,comp.protocols.nfs
Subject:   Re: Need info on NFS performance over Ethernet

In article <23123a$t78@lll-winken.llnl.gov> booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes:
>
>I'm looking for information on the performance of NFS over Ethernet.  That's
>about as succinct as I can make it.  Any pointers would be greatly appreciated.
>Thanks in advance.

There's so much to say that you'll really have to be more specific.  A
single Ethernet is about 1.25 MB/sec, and there are plenty of servers
that can pretty much saturate a single Ethernet with pure reads or pure
writes.

If you are looking at Laddis style operations (similar to nhfstone operations:
32% lookup, 13% getattr, 22% read, 15% writes, etc.), then the theoretical
maximum for a single Ethernet at 100% utiliation is about 400 ops/sec.  Faster
servers can typically handle 300-350 ops/sec on one Ethernet if they have
enough disks and memory.

What are you actually trying to figure out?

Dave Hitz			hitz@netapp.com
Network Appliance 		(408) 562-1906

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Jul 1993 16:16:42 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: SLIP or PPP broadcasts

In article <CAMtHA.EJs@unx.sas.com> djc@scimitar.unx.sas.com (David J. Cherveny) writes:
   Given a typical terminal server with SLIP or PPP connections
   established on the serial port side, and an ethernet connection on
   the other....

   What *SHOULD* happen to broadcast messages received on the ethernet
   side of the terminal server?

For background see RFC 1122, sections 3.2.1.3 (c-f and later
discussions), 3.3.1.1, and 3.3.6.  The last paragraph of the
Discussion in 3.3.6 explicitly takes no stand on the issue, but IMHO
broadcast messages should stay on the broadcast medium.

   In particular, RIP routing updates.  I have a user that wants to
   set up an at-home network with a system acting as a router.  He's
   using RIP to announce his presence (which I get), but he never gets
   updates from my router (they do get sent).

LAN broadcast messages should not be forwarded to the hosts connected
via point-to-point links.  The RIP broadcasts on that LAN describe the
routers' known connectivity and reachability from the point of view of
hosts also on that LAN.  Since the remote systems aren't on that LAN,
it's inappropriate for them to form routing decisions based on that
topology information.

   My guess is that my terminal server is not forwarding them to the
   SLIP/PPP connections.  Whats the expected behaviour?

The terminal server's RIPspeaker should build its topology lists by
listening to the RIP broadcasts on the LAN, along with any RIP
messages it hears over the point-to-point links.  Then the terminal
server should advertise its connectivity in a broadcast on the LAN,
and in RIP messages sent to its active point-to-point peers.

Beware, though: some RIPspeakers time out a route if they haven't
heard from a peer in some interval.  If your remote systems are
intermittently connected (e.g. demand-dialed SLIP or PPP), you might
need to tell your various RIPspeakers not to prematurely time out the
routes that cross those demand-dialed links.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 1993 17:20:07 GMT
From:      vsnyder@math.jpl.nasa.gov (Van Snyder)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   Re: tcpdump is now available for HP-UX, but requires extra STREAMS software

In article <STEINAR.HAUG.93Jul13215752@runit.sintef.no>, Steinar.Haug@runit.sintef.no (Steinar Haug) writes:
|> 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:
 ...
|> 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).
...

Does anybody know of ANY packet analysis tools that run on HP 7x0/HP-UX 8.0 without
extra unbundled and/or proprietary software?

I thought I had a simple problem:  We have a PC running OS/2 2.1.  It's NFSD uses
the usual exports file.  But if one puts a machine name on the line with a path name
(to limit access to that machine), HP-UX can't mount it.  HP-UX has no trouble
mounting volumes exported by HP-UX or SunOS.  A PC running DOS with PC/TCP is
able to mount the volume exported by OS/2.  IBM insists HP somehow screwed up how
it identifies itself when sending the mount request.  Thus, I would like to look
at the relevant packet/packets, in the hope of discovering what I might put in the
exports file on OS/2 to allow HP to mount the volume, without allowing world access.

Thanks in advance.

-- 
What fraction of Americans believe   |  Van Snyder
Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov

-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Jul 1993 18:03:17 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: SLIP or PPP broadcasts

In article <BOB.93Jul27121639@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
> ...
> Beware, though: some RIPspeakers time out a route if they haven't
> heard from a peer in some interval.  If your remote systems are
> intermittently connected (e.g. demand-dialed SLIP or PPP), you might
> need to tell your various RIPspeakers not to prematurely time out the
> routes that cross those demand-dialed links.

This hack is handy for detecting disconnected ethernet cables or other
problems, and thereby avoiding advertising a black hole.

Another problem with `routed` on demand-dialed links is that `routed`
generally wants to advertise only what it hears.  Even if your `routed`
does not stop advertising the point-to-point link simply because it has
not heard anything for a while, you will have troubles if an internet
is beyond point-to-point link.  The normal RIP timeout requires that
when the local routing daemon stops hearing of routes to the distant
internet, it should stop advertising them.

I've been using the previous version of `gated` to get arround this
problem on demand-dialed links.  `Gated` has its own non-trivial set of
problems, but one of its advantages is a complicated configuration
mechanism that can instruct the daemon to advertise routes that it
never hears or hears only intermittently.


Vernon Schryver,  vjs@sgi.com

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 93 18:09:44 GMT
From:      bas@moria.macs.sp.unisys.com (Brian Strop)
To:        comp.protocols.ppp,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Public domain SLIP for Macintosh

I am looking for a public domain SLIP implementation for the Mac that runs
with MacTCP 1.1.1.  I thought I saw mention somewhere of something called
MacSLIP (or something like that).  Thanks in advance.

Brian

P.S.  Send any responses to my mail address listed below.  Using the reply
feature doesn't seem to work.  Somewhere along the line my return address
is being corrupted.
-- 
Brian A. Strop				(612) 687-2709
UNISYS					bas%moria.uucp@email.sp.paramax.com
Network Systems

-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 1993 18:34:58 GMT
From:      bleimeyp@wolf.mayo.edu (Paul Bleimeyer)
To:        comp.periphs.printers,comp.protocols.appletalk,comp.protocols.tcpip
Subject:   Success or Failures with Lantronix print server

Hello,

We have recently acquired a Lantronix print server (EPS1) box for  
evaluation and are wondering if other people would share their experiences  
with us concerning the  use, installation, configuration of the unit. All  
reply to bleimeyp@mayo.edu Please. I will post a summary.

--
Paul Bleimeyer
Mayo Foundation
Rochester, MN 55905

-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Jul 1993 18:53:40 GMT
From:      adam@franz.com (Adam T. Dingle)
To:        comp.protocols.tcp-ip
Subject:   Is there a FAQ for this newsgroup?  If so, where?

Is there a FAQ file for comp.protocols.tcp-ip?

If so, where is it?  Why can't I find it on standard FAQ archives
(e.g. rtfm.mit.edu)?

If not, is there any good reason why there isn't one?

Please email to me (adam@franz.com).  I'll summarize to the net.

Thanks

Adam Dingle
adam@franz.com

-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Jul 1993 19:18:53 GMT
From:      cckimmell@vax.cns.muskingum.edu (Kevin Kimmell - CompSci/German)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   SLIP connections (Help wanted)

In article <1993Jul20.160606.1@vax.cns.muskingum.edu> cckimmell@vax.cns.muskingum.edu (Kevin Kimmell - CompSci/German) writes:
>        I'm looking for information on the SLIP packets (or whatever they are)
>in reguards to connectiong my bbs to the internet with a TCP/IP packet
>interface.  Any FAQ's or other pertinent information would be much appreciated.

Please respond to: cckimmell@vax.cns.muskingum.edu
-- 
-> -> -> -> -> -> -> -> -> -> -> Kevin Kimmell <- <- <- <- <- <- <- <- <- <- <-
 cckimmell@143.246.0.1 ||     Muskingum College       ||  the  B E E R  bbs
 Work: (614) 826-8040  ||Computer and Network Services|| SearchLight BBS v3.0 
 Home: (614) 826-7490  ||   Student Systems Analyst   ||   (614) 826-8243
===============================================================================
# "Independence limited. Freedom of choice is made for you my friend. Freedom #
#   of speech is words that they will bend. Free-dom with their exceptions!"  #
# -> -> -> -> -> -> -> -> -> -> -> MetallicA <- <- <- <- <- <- <- <- <- <- <- #

-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Jul 1993 19:27:14 GMT
From:      avrenios@ipx12.panther.mot.com (Alex Vrenios)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet,comp.protocols.nfs
Subject:   Need info on Ethernet behavior

Hi,

When I force a LOT of packets from one machine to another, on the same LAN,
which is 10baseT, I see the packets-sent increase to a maximum (~600/sec),
then the transfer rate drops to zero for a few seconds, before the performance
repeats.

   A. The device driver is running out of buffer space and data transfer stops
      until there is room again for packet data.

   B. The collision rate is so high at those rates (evidenced by a frantic Col
      light) that the retry delay becomes ineffective until the delay time is
      increased dramatically.

   C. All of the above.

   D. None of the above. (Please elaborate.)


My opinions only.

Thanks, Alex.
<avrenios@panther.mot.com>

-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Jul 1993 19:39:08 GMT
From:      sobi0268@mary.cs.fredonia.edu (Kevin V. Sobilo)
To:        comp.protocols.tcp-ip
Subject:   Ethernet Question



	I know the basics of how an ethernet works, and I was wondering why
an ethernet card was necessary to connect to an ethernet. Why couldn't the
function of the card be done in software rather than hardware, using a
RS-232 serial port??? 
	Any help or comments are greatly appreciated...

--

/					  \\				  \ 
|					   \\                              |
|	Kevin V. Sobilo			    \\                             |
|	sobi0268@mary.cs.fredonia.edu        \\  //   "Only Amiga Makes    |
|					      \\//     It Possible"        |
|					       \/                          |
|									   |
|									   |
 \==========================================================================/

-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 1993 20:17:43 GMT
From:      dhara_s@penda.cs.odu.edu (Sudheer Dharanikota)
To:        comp.protocols.tcp-ip
Subject:   ARP flags..

Hai,

	I wonder if any of you could help me in understanding
the relavance of the flags in the ARP cache entry structure,
namely ...
	
	ACE_F_PERMANENT
	ACE_F_PUBLISH
	ACE_F_DYING
	ACE_F_RESOLVED
	ACE_F_MAPPING

	Please do send me a mail to dhara_s@cs.odu.edu if you
couldnot post on this group for any reason.

Thank you

sudheer.

-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Jul 1993 21:55:50 GMT
From:      mac@s1.msi.umn.edu (Jim MacDonald)
To:        comp.protocols.tcp-ip
Subject:   Address already in use error

Can anyone tell me why bind will sometimes fail
with errno = EADDRINUSE address already in use?

If I run a program, then try to run it again right away
I get this error (sometimes).  I then have to wait
about 5 minutes and the program works.

Thanks for any info.

Jim MacDonald mac@msi.umn.edu


-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 93 00:34:25 GMT
From:      brucek@Ingres.COM (Bruce Kleinman)
To:        comp.protocols.tcp-ip
Subject:   Re: Address already in use error

In article <mac.743810150@msi.umn.edu> mac@s1.msi.umn.edu (Jim MacDonald) writes:
>Can anyone tell me why bind will sometimes fail
>with errno = EADDRINUSE address already in use?
>
>If I run a program, then try to run it again right away
>I get this error (sometimes).  I then have to wait
>about 5 minutes and the program works.

You need to set the socket option REUSEADDR.  When this option is not
set, attempts to bind to a port which still has old connections in
status TIME_WAIT will fail with EADDRINUSE.  Your 5-minute delay is
long enough to allow for these obsolete connections to fall out of
TIME_WAIT, which is why you can then re-bind to your port again.


-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Jul 1993 08:21:13 GMT
From:      peter@volvo.volvo.se (Peter HÔkansson)
To:        comp.protocols.tcp-ip
Subject:   rfc1475 - An argument for OSI ??

Request for discussion about rfc1475

I've just browsed through rfc1475 . This is one of the suggestions
for how to relife the lack of addresses in TCP/IP. 

But i am stunned by the silentness of networking people about 
this subject, maybe the most importent issue if TCP/IP during
it entire lifespan. As i will attend InterOp in SF i would
welcome a BOF discussion. Why is there no BIG seminars about this
at InerOp ??? Lets at least use the 'Net' for this.

rfc1475 looks good. It should work ok. But there is drawbacks.
The biggest one is the large header sizes. This is a big problem
for all those non-FDDI connections. To convince you i will remind
about all efforts that's been put into tcp header compression, slip
and PPP optimization etc.

Another drawback is a tendency to swift focus from the 'KISS' strategy
that has been very successful. This strategy has positioned TCP/IP 
as THE LEADER OF NETWORKING, leaving alternatives behind.
In my opinion, the concept of 'autonomus datagrams' with or without
sequencing upper layers is the very key to TCP/IP success.
This is the strength of ip, this is what should be focused on.

What is there to do then ? 
Lets compare IP-v4 and rfc1475 :

ip v4                       rfc1475
ip header: 20 bytes         header : 32 (or 36, see note about options)
tcp header: 20 bytes        header : 36 (or 40, see note about options)

Whats can be done in rfc1475 to reduce this ? Well amazingly a lot.
If we keep ip to be simple and RISC-like we could remove lots of
fields. This is my suggestion:

IP header
*  remove ' forward route identifier' This has nothing
   to do with datagrams, it is routing information. But as such it
   is at best doubtful and obsolete.  = - 8 bytes
*  protocol. 8 bits has been filled to maybe 50% during > 10 years 
   of use. There seems to be no point in increasing this. = -1byte
*  Total datagram length. I admit that 64K is small, but 4294967295
   is a bit of overkill. If we are to save something why don't we
   use a reasonable number like '1/10 second on a sonet fibre' which
   is 620/8 bytes/10 = 7.75 Mbyte. Think of this as one second
   of error-free transfer on an ethernet. This would give 24 bits
   as length and spare 8 bits for use as 'options present', TOS,
   or maybe security (i wonder if some organizations would ever
   consider using rfc1475 without some security mechanism ?)
*  TTL, doing 65Khops would be slow. Having a delay of 4000 sec.
   is also slow (i would give up that connection :-) ), anyway
   the standard MUST decide what should be represented here, it
   must be a well defined value. If we go for hopcount 256 would be
   more then enough.   =-1 byte
*  header length, consider the effect of a network where 
   the header could be too small for some links. That could be
   the effect of allowing 12 bits for this. I say 'if it can't 
   be done in 128 bytes it ain't worth doing'. Here i would save
   4 bits.

It sums up to 11 bytes and 4 bits. But we need some bits for indicators
missing in rfc1475 (option present, TOS etc). We also would like
to align our fields with 'natural' computable entitys. Therefor
a saving of 8 bytes is easy, 10 bytes possible if some shuffling is made.

TCP header,
the broadening of sequence and acknowledgement number is motivated
by reducing the likehood of having duplicate packets floating around.
But if we consider that 2^32 bytes represents a substantial storage
capacity i really doubt that we will ever be even close to beeing
able to store them in a network. Much less 2^64 bits. I therefore
suggest that we add a 'connection identifier' with the purpose to
discriminate between parallell sessions between two machines
and reduce sequence/acknowledgement numbers to 4 bytes.  = - 4 bytes
*   source/ destination port, here i'm more uncertain if there
    is a real limitation with 64K ports. The prospects of saving
    4 bytes on the TCP header seems more attractive to mee then
    being able to squeeze more active processes into a single box.
    Are we really moving towards huge multi-servers again ?? If we 
    are not, then the total number of active connection will in my
    opinion be well below 64.000.    = -4 bytes
This would reduce tcp header to 28 bytes, an increase with 8 from
ip v4.
A further reduction could be done if we used 2 bytes from the window
field and coded windows in a non contigous way ( power of 2 ?)
What ever method used should be coordinated with the 'datagram lengt'
in the ip-header. If a non-contigous method is choosen, the same 
could be used for tcp window and ip-datagram length.
(BTW SNA uses 8 bits and can represent from 8 to 491520 bytes by 
a simple encoding in 'Request Unit Size')
This is an area of discussion that YOU could help with. 

In total we should then have a protocol suite that for the most
common protocol combination (does there exists statistics on
what is the most common tcp/ip usage ??). This is in line with 
RISC - strategy to optimize for the most common operations and
do the unfrequent ones with combination of methods.

Summary:
with the above cuts from rfc1475 we would have a tcp/ip header
of 24 + 28 bytes (as 20+20 in ip-v4). This is the price to pay 
for increasing the address space to a comfortable 10-20 year
period. 
Of course this is a trade-off between functionality and speed. Most
things are in the computer world. But we make a better job if
we are aware of this and don't search for the free lunch.
The increase of headers would be 

Notes:
options in ip (and tcp) headers, i'm not shure how the absence of
options in rfc1475 is expressed, at worst a full 4 byte word with
option=0 is pushed on every frame. A useful way of dealing with this
is to have an 'option present bit' in the header and each option. Absence
of this bit then interpreted as 'no more options'.
-- 
--------------------------------------------------------------
Peter H<aring>kanson  VolvoData Dep 2230 phone +46 31 66 74 27
"Speaking for myself 'cause noone else does'"

-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 93 09:37:42 EET
From:      jaakola@cc.helsinki.fi
To:        comp.sys.hp,comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: SLIP or PPP for HP 9000 HP-UX?

In article <1993Jul23.172316.1@cc.helsinki.fi>, jaakola@cc.helsinki.fi writes:
> 
> Anyone know of a free compressed SLIP or PPP package for HP 9000 HP-UX?
> 
> I know, HP-UX has PPL, which is SLIP *without* compression.
> 
> Thanks.

So far no-one has replied anything. Does anyone know definitively that
no such beastie exists? Are all other HP-UX users satisfied with HP's
PPL?

-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 93 14:42:24 GMT
From:      DETHLEJD@AM.ACQ.OSD.MIL (James Dethlefsen)
To:        comp.protocols.tcp-ip
Subject:   Dynamic Socket Addressing

This may be a bit out of bounds, but here goes.

I need information on socket addressing under TCP/IP.  Specifically, how can I 
assure that I do not tromp all over some other processes' socket?

Also, is there a reference out there that describes standard socket numbers for 
popular applications?  I.E. PING, CHAT, ETC.

Furthermore, are there any specifics available on PING?

Jim Dethlefsen

-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Jul 1993 15:13:39 GMT
From:      pjc@xylint.co.uk (Pete Cameron)
To:        comp.protocols.tcp-ip
Subject:   Re: rfc1475 - An argument for OSI ??


In article <CAv8JF.8vM@volvo.volvo.se>, peter@volvo.volvo.se (Peter HÔkansson) writes:
|> Request for discussion about rfc1475
|> 
|> I've just browsed through rfc1475 . This is one of the suggestions
|> for how to relife the lack of addresses in TCP/IP. 
|> 
|> But i am stunned by the silentness of networking people about 
|> this subject, maybe the most importent issue if TCP/IP during
|> it entire lifespan. As i will attend InterOp in SF i would
|> welcome a BOF discussion. Why is there no BIG seminars about this
|> at InerOp ??? Lets at least use the 'Net' for this.

You would not say that if you had been to the IETF meeting
in Amsterdam a couple of weeks ago. Many hours of heated
debate took place!!

-- 
Pete Cameron                                            tel: +44 908 222112
Consulting Engineer                                     fax: +44 908 222115
Xylogics International Limited                  email: cameron@xylint.co.uk
Featherstone Rd, Wolverton Mill, MK12 5RD, UK.         cameron@xylogics.com

-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Jul 1993 15:51:18 GMT
From:      tmurray@cup.hp.com (Tom Murray)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   Re: tcpdump is now available for HP-UX, but requires extra STREAMS software

Van Snyder (vsnyder@math.jpl.nasa.gov) wrote:

: Does anybody know of ANY packet analysis tools that run on HP 7x0/HP-UX 8.0 without
: extra unbundled and/or proprietary software?
 
: I thought I had a simple problem:  We have a PC running OS/2 2.1.  It's NFSD uses
: the usual exports file.  But if one puts a machine name on the line with a path name
: (to limit access to that machine), HP-UX can't mount it.  HP-UX has no trouble
: mounting volumes exported by HP-UX or SunOS.  A PC running DOS with PC/TCP is
: able to mount the volume exported by OS/2.  IBM insists HP somehow screwed up how
: it identifies itself when sending the mount request.  Thus, I would like to look
: at the relevant packet/packets, in the hope of discovering what I might put in the
: exports file on OS/2 to allow HP to mount the volume, without allowing world access.

You can use nettl (network tracing/logging) to capture the network
packets during the mount attempt and use netfmt to format the packets.
Something like this should work:

nettl -start
nettl -traceon pduin pduout -e ns_ls_driver -f /tmp/NFSTRC

< ... attempt the mount ...>

nettl -tf -e all

netfmt -N -f  /tmp/NFSTRC.TRC1  # if it exists
netfmt -N -f  /tmp/NFSTRC.TRC0

If you have a lot of trace data you may wish to create a filter file.
Put the following lines into a file and add the -c <filter_file> option
to the netfmt command(s) above:
	filter udp_sport 2049   # 2049 is the nfs port number
	filter udp_dport 2049

See the man pages for other options that may be useful.  
Hope this helps!
Tom Murray

# NOT AN OFFICIAL STATEMENT OF THE HEWLETT PACKARD COMPANY.


-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Jul 93 15:58:23 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   RE: Need info on Ethernet behavior

In Article <1993Jul27.192714.3458@panther.mot.com>
avrenios@ipx12.panther.mot.com (Alex Vrenios) writes:

>When I force a LOT of packets from one machine to another, on the same LAN,
>which is 10baseT, I see the packets-sent increase to a maximum (~600/sec),
>then the transfer rate drops to zero for a few seconds, before the performance
>repeats.

You don't say too much about just what sorts o data you are running over you
net, but...

>   A. The device driver is running out of buffer space and data transfer stops
>      until there is room again for packet data.

Probably. Sounds like typical throttling of the link by closing down the window
for congestion control. Have you looked at the window size? If the destination
is dropping it down (possibly to 0), this is your problem.

>   B. The collision rate is so high at those rates (evidenced by a frantic Col
>      light) that the retry delay becomes ineffective until the delay time is
>      increased dramatically.

Possibly, but looking at the transceiver of the units involved in the transfer
is not useful. Look at the CP light on a transceiver on a third device.
Assuming SQE Test is enabled (and it should be), the CP light will come on for
every packet transmitted. Don't forget that the receiving unit is transmitting
acks.

>   C. All of the above.

Not likely, but anything is possible.

>   D. None of the above. (Please elaborate.)

Not likely, either. "A" is the most likely cause, probably by an order of
magnitude.

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)

-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Jul 1993 16:30:12 GMT
From:      ccaajac@ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: rfc1475 - An argument for OSI ??


this is actively discussed on lots of lists, not the least 
big-internet@au.oz.munnari
(send to big-internet-request@au.oz.munnari) and others specific to the various 
proposals


please go to an ietf if you wish for technical discussion -
InterOp has a slightly dfifferent emphasis and goals (though I am sure
discussion of IP replacements at Interop will be rife/welcome etc

|> Peter H<aring>kanson  VolvoData 
 
-- 
jon crowcroft (hmmm...)

-----------[000463][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Jul 1993 17:04:23 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Question

> 	I know the basics of how an ethernet works, and I was wondering why
> an ethernet card was necessary to connect to an ethernet. Why couldn't the
> function of the card be done in software rather than hardware, using a
> RS-232 serial port??? 

If you think the functions of an Ethernet card could be done in software, I'm
afraid you *don't* know the basics of how an Ethernet works. For instance, how
would you do collision detection in software?

I recommend getting hold of a good data communications book and reading up
on Ethernet. W.Stallings "Data and computer communications" and A.Tanenbaum
"Computer networks" are good places to start.

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

-----------[000464][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Jul 1993 17:18:17 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: rfc1475 - An argument for OSI ??

> But i am stunned by the silentness of networking people about 
> this subject, maybe the most importent issue if TCP/IP during
> it entire lifespan. As i will attend InterOp in SF i would
> welcome a BOF discussion. Why is there no BIG seminars about this
> at InerOp ??? Lets at least use the 'Net' for this.

Actually, networking people in the IP standards community have been talking
about little else.

The mailing list big-internet-request@munnari.oz.au has been full of
discussions about the merits of the various IP:tng proposals.

The May issue of IEEE Network was a special issue devoted to the major
proposals, with good descriptions of each proposal and its goals by its
primary authors.

Craig

-----------[000465][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Jul 1993 18:24:07 GMT
From:      tim@jade.spctrm.com (Tim Fry)
To:        comp.protocols.tcp-ip,comp.binaries.ibm.pc.wanted,comp.windows.ms.programmer
Subject:   WANTED: Windows 3.x GUI on VT emulation

We need to rapidly prototype a new Windows 3 GUI interface to sit on top of
an existing VT220 based application (hosted on a UNIX box). Are there any 
products that can map a character base VT220 telnet terminal emulation to 
a Windows interface and that can actually manipulate the *displayed* data. 

For instance, can fields on the VT220 emulation be represented as Windows
text boxes. 

It doesn't have to be very fancy since this is only a prototype for demo
purposes.

Any suggestions would be welcome.

Thanks
-- 
Tim Fry
Spectrum Investment Systems Inc. 214 King Street West, Toronto Ont. Canada.

-----------[000466][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Jul 1993 19:57:56 GMT
From:      ba.cgb@RLG.Stanford.EDU (Clif Baker)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there a FAQ for this newsgroup?  If so, where?

In article <1993Jul27.185340.27977@franz.com> adam@franz.com (Adam T. Dingle) writes:
>Newsgroups: comp.protocols.tcp-ip
>Path: nntp.Stanford.EDU!morrow.stanford.edu!decwrl!decwrl!spool.mu.edu!howland.reston.ans.net!noc.near.net!uunet!franz.com!adam
>From: adam@franz.com (Adam T. Dingle)
>Subject: Is there a FAQ for this newsgroup?  If so, where?
>Message-ID: <1993Jul27.185340.27977@franz.com>
>Keywords:  faq
>Sender: news@franz.com
>Nntp-Posting-Host: akbar
>Organization: Franz Incorporated, Berkeley CA
>Date: Tue, 27 Jul 1993 18:53:40 GMT
>Lines: 13
>Is there a FAQ file for comp.protocols.tcp-ip?
>
>If so, where is it?  Why can't I find it on standard FAQ archives
>(e.g. rtfm.mit.edu)?
>
>If not, is there any good reason why there isn't one?
>
>Please email to me (adam@franz.com).  I'll summarize to the net.
>
>Thanks
>
>Adam Dingle
>adam@franz.com


Adam,

There probably is...I just haven't made an effort to look for it yet.

GENFYI...

A LOT[!!] of FAQs are stored on RTFM.MIT.EDU in the PUB\USENET directory.  
Give that a peek and FTP the one[s] of interest to you.  If there is one for 
this newsgroup there is a VERY high probability it's there.

Clif

-----------[000467][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Jul 1993 10:37:22 +0000
From:      bryan@alex.com (Bryan Boreham)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Question

In article <jffaf7a@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> In article <1993Jul28.121823.3167@alex.com>, bryan@alex.com (Bryan Boreham) writes:
> > In article <1993Jul27.193908.1978@penny.cs.fredonia.edu>, sobi0268@mary.cs.fredonia.edu (Kevin V. Sobilo) writes:
> > 
> > > 	I know the basics of how an ethernet works, and I was wondering why
> > > an ethernet card was necessary to connect to an ethernet. Why couldn't the
> > > function of the card be done in software rather than hardware, using a
> > > RS-232 serial port??? 
> > 
> > One fundamental thing: ethernet cards need to be able to recognize
> > that another card has transmitted at the same time.  This requires
> > more electronics than a serial port provides.
> 
> Doesn't the collision pair from the transciever help for that?

I would count an Ethernet transceiver as "more electronics".
 
Bryan.

-----------[000468][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 93 23:59:02
From:      amoss@picton.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: Ethernet addr => host name

In article <2366@mefos.se> pam@mefos.se (PA Monwall) writes:

   Is there a way to map the ethernet card address to a hostname or
   internet adress without running a setup program at each host?
   We have a host running SCO Unix which reports the error:
   "rwhod: malformed host name from c047b764"
   My guess is that the number is a ethernet adress but I don't know
   what host it is.

Your guess seems wrong to me.  I can't believe rwhod has anything to do with
ethernets.  Also ethernet addresses are 6 bytes long.  I would bet this
hex number is actually an IP address,  although admitedly this is not such
a regular represenation.  Translating each two hex digits to decimal gave me
192.71.183.100 which I couldn't either traceroute(8) or ping(8).  I see
mefos.se isn't on the Internet, right? (I could only find an MX record for it).
So probebly you have troubles with a host who's address is the one mentioned
above.

Hope this sequence of guesses isn't too far from the truth.

|--pa
 
|----------------------------!------------------------------------------------
|    /////// /////// //   // ! PA Monwall               E-mail: pam@mefos.se
|   //   // //   // ///////  ! Foundation for Metallurgical Research (MEFOS)
|  /////// /////// // / //   ! Box 812, S-971 25 Lulea, Sweden
| //      //   // //   //    ! Tel: +46 920 55640  Home : +46 920 221581
|//      //   // //   //     ! Fax: +46 920 55832  Telex: 80482 MEFOS S

Cheers,

--Amos
--
--Amos Shapira (Jumper Extraordinaire) |  "It is true that power corrupts,
C.S. System Group, Hebrew University,  |   but absolute power is better!"
Jerusalem 91904, ISRAEL                |
amoss@cs.huji.ac.il                    |          -- the Demon to his son

END OF DOCUMENT