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 September 1993 (516 messages, 289007 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1993/09.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Sep 1993 00:38:41 GMT
From:      marcelm@joymrmn.on.ca (Marcel Mongeon)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewalls could help put off the IP address shortage

a20@nikhef.nl (Marten Terpstra) writes:

>In article <25stoi$ie0@neon.rain.com> jeff@onion.rain.com (Jeff Beadles) writes:
> * This won't work.
> * 
> * How will the firewall get to the real "Hyperion's" net?  They will see
> * the routes to the internal "Xerox" networks, and take that route.
> * (If they didn't see that route, then nobody could connect via IP to the
> * firewall anyway.)
> * 
> * This is un-good.
> * 
> * Now, if all sites behind firewalls used the same IP addresses,
> * and you removed all incompetent sysadmin's who would do things like
> * leak routing and DNS information, & stuff, then you might have a chance
> * in making something like this work.  I doubt it though, if past
> * performances are any indication.
 
>Well, let me say once more what I suggested just some days ago (and many with
>me). What if we reserve a class A, some Bs and some Cs just for this purpose ?
>If everyone knows what the numbers are, then it would be simple to install
>filters to simply never route this net, never send any packet to this net ...

There is actually a great Class A address available for this.  The address
is 127.  Sure 127.0.0.1 is a reserved loop-back address but you can make a
lot of machines work on other addresses in this space.

Another advantage of 127 is that even if something does escape from behind
a fire-wall they aren't going to get to far.  Unless the addresses are
properly set up to use 127, just about anything else should spit it back
relatively quickly (or at the very least ignore it).

-- 
|||  Marcel D. Mongeon 
|||  (Information Technology Lawyer & Trade Marks Agent, Ontario, Canada)
|||  phone:  (416) 528-5936
|||  e-mail: marcelm@joymrmn.on.ca

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Sep 1993 01:26:38 GMT
From:      mtiernan@world.std.com (Michael C Tiernan)
To:        comp.protocols.tcp-ip,comp.unix.sys5.misc,comp.unix.sys5.r3
Subject:   Re: Nameserver problem

Eigil Krogh S|rensen <eks@daimi.aau.dk> wrote:
 > Please help me with the following problem:
 > What I've done until now is to create the file  /etc/resolv.conf
 > with this content:
 > nameserver  name-server-address

	Oh damn, as I typed this reply, I forgot the answer.  There's
	TWO lines, one is the part you did... I got it!
		"domain frammis.com"
	you have to tell it what domain the nameserver is for.

	So, you've got:
		/etc/resolv.conf:
			domain frammis.com
			nameserver 123.45.67.89
	That should do it.
-- 
        << MCT >>                              mtiernan@world.std.com
        Michael C Tiernan.                     GEnie: M.Tiernan
        Boston Computer Society member         AOL:   M Tiernan or BCS Mike

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 1993 02:23:12 GMT
From:      amolitor@moink.NMSU.edu (Andrew)
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

In article <1993Aug23.111425.412@eisner.decus.org>, saunders@eisner.decus.org writes:
> 
> Of course I'd like to permit the connection to recover from a network error,
> but is it really likely to recover after two hours? And what about applications
> where the network is reasonably reliable? They shouldn't have to wait that
> long.

	Actually, I have heard that in the packet radio community, it is
not uncommon to see TCPs come back to life after *days* of non-connectivity.
I agree that it'd be nice to have an implementation where acceptable
timeouts are settable. As donp@novell has pointed out, you can do this
yourself without much trouble.

	Andrew

> John Saunders
> saunders@eisner.decus.org

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Sep 1993 11:06:12
From:      hans@anest4.anest.ufl.edu (Hans van Oostrom)
To:        comp.protocols.tcp-ip
Subject:   Re: Specs on Talk Protocols????

In article <dedgar.38.0@Cybercon.nb.ca> dedgar@Cybercon.nb.ca (Dale L. Edgar) writes:
>I am looking for the specifications on the talk protocol(s). I have
>done an archie search on "talk" and all that seems to turn up are a
>variety of man pages on talk, ytalk, ntalk et.al. plus the odd bit of 
>source code. Source is nice, but if one wishes to write a talk 
>application a spec sheet is desirable.

The only documentation on talk that I know of is the talkd.h file.  It pretty 
much describes the protocol in the comments.  This file resides on most bsd 
type machines in /usr/include/protocols (or /usr/include/bsd/protocols).  It 
can be ftp'd from ftp.uu.net in the systems/unix/bsd-sources/include/protocols 
directory. talk source code sits in systems/unix/bsd-sources/usr.bin/talk.

Hope this helps

Hans van Oostrom
hans@anest4.anest.ufl.edu


-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 93 09:02:00 GMT
From:      tomc@osi.curtin.edu.au (Tom Crawley)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewalls could help put off the IP address shortage

koreth@spud.Hyperion.COM (Steven Grimm) writes:

>In <1993Aug31.083904.18521@ucl.ac.uk> ccaajac@ucl.ac.uk (Jon Crowcroft) writes:
>>see also
>>1335  Two-tier address structure for the Internet: A solution to the problem
>>      of address space exhaustion.  Wang, Z.; Crowcroft, J.  1992 May;

Without giving much thought to the problem, is it be possible to construct a
gateway that dynamically assigned external IP addresses to internal IP
addresses and vv, and replaced addresses (transparently) in the header on
the fly as IP packets pass through the gateway? That way the (internal) host
need only be assigned  a single address. Requires some high speed processing
at the gateway course, but not out of the question these days.

IP addresses not carried by the IP header would require some thought, such
as DNS info. Point me to the appropriate RFC!

cheers
tomc

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 93 12:28:56 GMT
From:      kmanecke@honda.honda.com (Kurt Manecke)
To:        comp.protocols.tcp-ip
Subject:   IP subnetting and RIP


TCP/IP and RIP gurus, please help. I am trying to come up with an ip
addressing scheme and would like to here any thoughts anyone may have.
I have 2 class C network numbers. They are 198.51.250 and 198.178.216.
I am planning on leaving 198.51.250 a flat network and subnetting
198.178.216 with a mask of 255.255.255.224. Here is what my network
will look like.
 
                            198.51.250 Ethernet
      ---------------------------------------------------------
          |                                  |
          |                                  |
-------Router 1                         Router 2
to remote |                             |   |   |
location  |        Token Ring           |   |   |
          |_____________________________|   |   |
               198.178.216.(160-191)        |   |
                                            |   |
                                            |   | 56Kbps Leased Line
                        Ethernet            |   | 198.178.216.(96-127)
                    ________________________|   |
                      198.178.216.(128-159)     |
                                                |
                                                |
                                                |
                                            Router 3
                                             |   |
                            Token Ring       |   | Ethernet
                            _________________|   |___________________
                            198.178.216.(64-95)    198.178.216.(32-63)
 
 
I would like any network or subnet to communicate with all other networks.
Does this addressing scheme look like it will work? I was told that RIP
has some limitations with subnetting. Any replys would be greatly appreciated.
 
Kurt Manecke      kmanecke@honda.com



-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Sep 1993 13:11:54 GMT
From:      ahand@ctp.com (Aslam Handy)
To:        comp.protocols.tcp-ip
Subject:   FTP, 3rd Party xfers and thru' programs


The "UNIX Networking by Kochan and Wood" book has the following under
the file transfer section:

"FTP allows third-party transfers, where one machine initiates a transfer
between two other remote machines".

and

"Although FTP is often used to transfer files interactively, it is actually
designed to be used by programs".

Any ideas how these 2 things are done ?



ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Aslam Handy                    ||
Cambridge Technology Partners  || "..its usually the amateurs who make the
PH  : 617-374-8254             ||  breakthroughs because the experts know
FAX : 617-374-8300             ||  too many reasons why something will fail"
INET: ahand@ctp.com            ||                     
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Sep 1993 13:39:31 GMT
From:      bwarner@mentor.cc.purdue.edu (Bill Warner)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewalls could help put off the IP address shortage

In article <CCnGGJ.5ro@joymrmn.on.ca> marcelm@joymrmn.on.ca (Marcel Mongeon) writes:
>
>There is actually a great Class A address available for this.  The address
>is 127.  Sure 127.0.0.1 is a reserved loop-back address but you can make a
>lot of machines work on other addresses in this space.
>

This seems to be a common perception, but actually it is incorrect.  From
RFC 1340, page 5, paragraph (g):

	(g)	{127, <any>}
		Internal host loopback address.  Should never appear outside
		a host.


So, *all* 127.*.*.* addresses are reserved for loopback.  An IP implementation
which allows any 127 address to "escape" is broken.  It is also doing more
work than needed.  It only needs to look at the first octet of an address
in order to determine that it should be looped back.  There is no need to
explicitly match 127.0.0.1.

-- 
Bill Warner						(317)494-1787
General Consultant					bwarner@cc.purdue.edu
Purdue University Computing Center			bwarner@PURCCVM.BITNET

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Sep 1993 15:25:54 GMT
From:      keogh@sse.ie (Paul Keogh)
To:        comp.protocols.tcp-ip
Subject:   TCP and TLI

I'm running a concurrent server application over TCP/IP on a SCO 3.2 2 system
and I'm seeing some strange behaviour under heavy load. 

When my server recieves an incoming connection, the poll() fires, it does a
t_listen(), then t_open(), t_bind() and t_accept(), the usual stuff. It then
forks and execs the protocol server and goes back to listening on the endpoints.
This works 99% of the time. When it does not work, the t_accept fails with
an t_errno of 0. I do a t_look() get back an event of 1 which is a connect
indication recieved. Any attempt to do anything on the endpoint results in an
error (generall invalid file descriptor).

Why should an asynch. event occur between the t_listen() and t_accept() and 
if its valid how should I handle it ? 

On a more general point, has anyone any experience of problems with TLI/TCP
on this version of SCO ?

Thanx,
Paul Keogh
SSE
-- 
Paul Keogh, 				// 
SSE 					//
Dublin, Ireland.			//
					//

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      01 Sep 1993 16:19:37 GMT
From:      jazz@jazz.hal.com (Jason Zions)
To:        comp.protocols.tcp-ip
Subject:   Re: a question

In article <2C82729E.13543@news.service.uci.edu> yeh@netix.com (Mr Shannon Yeh) writes:

   One month ago, a Chinese student at UIC.EDU sent us hundreds of pages of
   junk FAX by using UIC's computerized fax system (e-mail/fax), and this
   junk faxing caused damage to us.
[ ... ]
   So far, neither did UIC tell us who that user was, nor did they agree to
   solve this problem positively, nor did they make any apology.  All they
   told us is: 1) they like to protect their student; 2) it will not happen
   again.

   Could someone offer me some knowledge on this?

What more do you want? It won't happen again; that should be sufficient. If
you can prove damages and want to recover them, simply tell UIC how much you
want; be prepared to take them to court. It's *their* problem to figure out
how to extract the money from the student if they choose to do so.

Operationally, you shouldn't *care* who the individual was who did the deed.

Jason

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 1993 16:26:01 GMT
From:      antonis@intranet.gr (Antonis Kyriazis)
To:        comp.protocols.tcp-ip
Subject:   Re: IP subnetting and RIP



I think the corrected ip numbers are:

 
                            198.51.250 Ethernet
      ---------------------------------------------------------
          |                                  |
          |                                  |
-------Router 1                         Router 2
to remote |                             |   |   |
location  |        Token Ring           |   |   |
          |_____________________________|   |   |
               198.178.216.(161-190)        |   |
                                            |   |
                                            |   | 56Kbps Leased Line
                        Ethernet            |   | 198.178.216.(97-126)
                    ________________________|   |
                      198.178.216.(129-158)     |
                                                |
                                                |
                                                |
                                            Router 3
                                             |   |
                            Token Ring       |   | Ethernet
                            _________________|   |___________________
                            198.178.216.(65-94)    198.178.216.(33-62)
 

Your scheme means you reserve 3 bits for subnets and 5 bits for hosts.
The addresses x.y.z.32, x.y.z.64, x.y.z.96, x.y.z.128, x.y.z.160 and
x.y.z.192 are not accepted because, according to the subnet mask, appear
to have zero network portion (a general subnetted ip address consists
of: <class X address>.<subnet portion>.<host portion> ), and continuous
zeros mean "this"! Similarly the addresses x.y.z.63, x.y.z.95, x.y.z.127,
x.y.z.159, x.y.z.191 and x.y.z.223 represent the broadcast addresses for
the corresponding subnets, provided that the broadcast format is "all
ones".

So, after the corresponding definitions for subnet and broadcast mask,
RIP should work...(?)


Please, correct, if I'm wrong.

+-------------------------------------------------------------------+
|     Antonis Kyriazis                                              |
| Networks & Communications       e-mail: antonis@intranet.gr       |
| INTRACOM sa                                                       |
| 19.5 km Marcopoulo Ave.          fax:   +30-1- 66 44 379          |
| Peania 190 02                           +30-1- 66 43 718          |
| GREECE                          phone:  +30-1- 66 44 961-5        |
|                                         +30-1- 88 43 715          |
| "The expressed opinions are of my own"   + - MACEDONIA IS GREEK - +
+-------------------------------------------------------------------+


-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 1993 16:33:38 GMT
From:      agulbra@nvg.unit.no (Arnt Gulbrandsen)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP, 3rd Party xfers and thru' programs

In article <1993Sep1.131154.3722@ctp.com>, Aslam Handy <ahand@ctp.com> wrote:
>"FTP allows third-party transfers, where one machine initiates a transfer
>between two other remote machines".

In the BSD client implementation, use proxy.  RTFM for details.
I've seen some code in the BSD server which might be for this as
well; I didn't study it.

>"Although FTP is often used to transfer files interactively, it is actually
>designed to be used by programs".

I didn't know that, but it does make sense.  The protocol is exactly
like SMTP (that's mail), with fprintf-friendly commands and
three-digit results in the main connection.  The only other data is
sent separately in another TCP connection.

-- 
Arnt Gulbrandsen, agulbra@nvg.unit.no
The other .sig is the real one - this one is just a decoy.
--
Arnt Gulbrandsen, agulbra@nvg.unit.no
The other .sig is the real one - this one is just a decoy.

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 1993 16:44:41 GMT
From:      eks@daimi.aau.dk (Eigil Krogh S|rensen)
To:        comp.protocols.tcp-ip,comp.unix.sys5.misc,comp.unix.sys5.r3
Subject:   Re: Nameserver problem - SOLVED !! - Thanx.

The nameserver problem is solved. 

Thanks to all who helped !


The problem was solved by putting

ehosts:res

into the file

/etc/svcorder

(Meaning "first search /etc/hosts  next  /etc/resolv.conf (for nameserveres)").

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Sep 1993 17:09:21 GMT
From:      ronf@panther.mot.com (Ron Feigen)
To:        comp.protocols.tcp-ip
Subject:   Why Me??? Broken Pipes!

  I am developing a large Client/Server appl. Inet Sock/streams (with a few twists).
 When running a
stress test, after the net becomes saturated (high # of collisions) we begin to get
broken pipes.  I am assuming that what is going on is the O/S (Sun 4.1.3) is closing
the connection because of an error threshold has been reached.  Or could it have some
thing to do with buffer space?  How can a verify what exactly is going on??????

  Another even stranger occurance is when send() returns "Invalid Arguement".  The
process is recv'ing() from socket A and send'ing() on socket B when this occurs.The value of len is set be the previous recv().  Why do I occasionally  get "Invalid Arg"??

Any info/direction/help/assistance would be GREATLY appreciated!!!!!

Thanks,
 

---

>
Ron Feigen
ronf@panther.mot.com


-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Sep 93 17:12:22 GMT
From:      andye@oz.plymouth.edu (Andy Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: IP subnetting and RIP


RIP doesn't pass subnet masks - all subsequent networks are assumed to have
the same mask as the network they are connected to. Default routes
can take care of of the class-C to class-C routing, just don't let the RIP
propagate the subnet structure to the subnets serviced by routers at the 
"head" of those networks. In other words, I'd create and advertise a static 
default route for 198.51.250.0 to all 198.178.216.0 networks, and the same 
in reverse - but filter all the other external routes from the RIP table 
you'll be advertising if you can...  Within the  198.178.216 net you can use
rip as long as the masks are consistent, in conjunction the the default route
to 198.51.250
 
                                                  andye@oz.plymouth.edu  
   Andy Evans                                   andrew.evans@plymouth.edu    
Computer Services                                 Plymouth State College    
Technical Support                                  Plymouth, NH  03264  

In article <401@honda.honda.com> kmanecke@honda.honda.com (Kurt Manecke) writes:
>
>TCP/IP and RIP gurus, please help. I am trying to come up with an ip
>addressing scheme and would like to here any thoughts anyone may have.
>I have 2 class C network numbers. They are 198.51.250 and 198.178.216.
>I am planning on leaving 198.51.250 a flat network and subnetting
>198.178.216 with a mask of 255.255.255.224. Here is what my network
>will look like.
> 
>                            198.51.250 Ethernet
>      ---------------------------------------------------------
>          |                                  |
>          |                                  |
>-------Router 1                         Router 2
>to remote |                             |   |   |
>location  |        Token Ring           |   |   |
>          |_____________________________|   |   |
>               198.178.216.(160-191)        |   |
>                                            |   |
>                                            |   | 56Kbps Leased Line
>                        Ethernet            |   | 198.178.216.(96-127)
>                    ________________________|   |
>                      198.178.216.(128-159)     |
>                                                |
>                                                |
>                                                |
>                                            Router 3
>                                             |   |
>                            Token Ring       |   | Ethernet
>                            _________________|   |___________________
>                            198.178.216.(64-95)    198.178.216.(32-63)
> 
> 
>I would like any network or subnet to communicate with all other networks.
>Does this addressing scheme look like it will work? I was told that RIP
>has some limitations with subnetting. Any replys would be greatly appreciated.
> 
>Kurt Manecke      kmanecke@honda.com
>
>


-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Sep 93 17:19:57 GMT
From:      dotytr@nscultrix2.network.com (Ted Doty)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewalls could help put off the IP address shortage

In article <tomc.746874120@osi> tomc@osi.curtin.edu.au (Tom Crawley) writes:
>koreth@spud.Hyperion.COM (Steven Grimm) writes:
>
>Without giving much thought to the problem, is it be possible to construct a
>gateway that dynamically assigned external IP addresses to internal IP
>addresses and vv, and replaced addresses (transparently) in the header on
>the fly as IP packets pass through the gateway? That way the (internal) host
>need only be assigned  a single address. Requires some high speed processing
>at the gateway course, but not out of the question these days.
>

We have in fact implemented this feature in our routers; it is currently
done via the "CLONE_TO" action in Packet Control Facility.  Remember,
tho, you're changing the socket without the application's permission (or
knowledge).

- Ted

--------------------------------------------------------------------------
Ted Doty, Network Systems Corporation | phone:      +1 301 596-2270
8965 Guilford Road, Suite 250         | fax:        +1 410 381-3320
Columbia, MD, 21046 USA               | voice mail: (800) 233-1485
--------------------------------------------------------------------------
These opinions are my own, not necessarially those of Network Systems.

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 93 22:53:50
From:      mccarty@add.itg.ti.com (Rick McCarty)
To:        comp.protocols.tcp-ip
Subject:   ICMP Timestamps and Solaris

Has anyone encountered problems with sending ICMP timestamp requests to
a Solaris system?  I have written an application which issues such
requests and it works with every other Un*x host I've tried.  But with
any Solaris host, I get a large negative return value and no error values
are set.

(Doesn't work with NT, PC/TCP, etc either - but I haven't looked at
what the error values are.)

Does anyone have a clue as to what I might want to look for in trying
to debug this?  I can post source if necessary - what I'm doing in my
code seems to be pretty standard as far as I can tell.

--Rick

===========================================================================
Rick McCarty                                         Texas Instruments Inc.
mccarty@add.itg.ti.com                               Austin, Texas
===========================================================================



-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Sep 1993 22:04:50 GMT
From:      Tab.McCollum@DaytonOH.NCR.COM (Tab McCollum)
To:        comp.protocols.tcp-ip
Subject:   Help on Sockets

I need some help on obtaining documentation, code on 
client/server file transfers using window sockets.  I am using OBJECTVIEW
which is a front end SQL tool.  The language is similary to basic and I can 
make DLL function calls.

Please give me any help you can.

tab.mccollum.daytonoh.ncr.com

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 93 02:16:46 GMT
From:      sandeep@ee.uts.edu.au (Sandeep Chandra)
To:        comp.protocols.tcp-ip
Subject:   tcpdump [or equivalent] for OSI TP4 etc. ?

Hi Nettors,

I am looking for a utility to help debug OSI protocol
header info at runtime. As the OSI protocols execute
the packets picked up from the ethernet [in the promiscous
mode] need to be deciphered and results presented.

For TCP/IP suite there is tcpdump available.
I am looking for the equivalent, especially for TP4 protocol.

Please let me know the site where available, if you know
it yourself.

Thanks in advance,
Sande'

:



-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 1993 17:27:49 -0700
From:      dave@telco-nac.com (David Cornejo)
To:        comp.protocols.tcp-ip
Subject:   Re: Why is connection to nic.ddn.mil slow

In article <wrl-020993121005@irm124.wdl.loral.com> wrl@wdl.loral.com (Bill Lewandowski) writes:
>Hi,
>
>This seems like an old story but why is the connection to nic.ddn.mil
>so slow again (Yes, I know there are two NIC's now, one for the US Military
>and one for the rest of us). There used to be a connection through NASA to
>the MILNET and NSFNET (The rest of us).

According to RFC 1400, nic.ddn.mil was supposed to cut over to a
56K connection to the Internet effective June 1, 1993. With the number
of people who still have their whois's set to nic.ddn.mil it doesn't
surprise me that it's slow.



-- 
Dave Cornejo                         It's just another day in California
Telco Systems NAC                             where "good enough," isn't
Fremont, California, USA
+1 510 490 3111 x5158             also: dave@dogwood.com, dnc@netcom.com

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Sep 93 08:57:59 GMT
From:      satish@terminus.ericsson.se (Satish Popat)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI access to TCP/IP

In article L8F@ra.nrl.navy.mil, atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
>By the way, Comer's TLI client/server programming is now out.  It is
>the recommended reference for folks using or trying to use TLI.

Does anyone know if there are major differences (apart from using TLI in place 
of BSD Sockets) in the contents of the book? Also, are the sources available on some
ftp site?


---


Satish Popat
Ericsson, England 
Tel +44 533 537534
Fax +44 533 537920


-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 1993 11:04:44 GMT
From:      antonis@intranet.gr (Antonis Kyriazis)
To:        comp.protocols.tcp-ip
Subject:   Re: Slow FTP in one direction only!!


Perhaps the path is different for each direction.  Check routing tables
(and ICMP echo reply's time) in both ends...

+-------------------------------------------------------------------+
|     Antonis Kyriazis                                              |
| Networks & Communications       e-mail: antonis@intranet.gr       |
| INTRACOM sa                                                       |
| 19.5 km Marcopoulo Ave.          fax:   +30-1- 66 44 379          |
| Peania 190 02                           +30-1- 66 43 718          |
| GREECE                          phone:  +30-1- 66 44 961-5        |
|                                         +30-1- 88 43 715          |
| "The expressed opinions are of my own"   + - MACEDONIA IS GREEK - +
+-------------------------------------------------------------------+


-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Sep 1993 11:05:57 GMT
From:      nafallon@vax1.tcd.ie
To:        comp.protocols.tcp-ip
Subject:   Slow FTP in one direction only!!

Greetings!

I am having severe speed problems when trying to ftp files from my PC (running 
Interactive unix). The transfer rate is fine when sending/getting files to
the machine, but all transfers in the other direction creep along at about 2k 
per minute. (Actually, when you are logged into the remote machine this happens
. When running FTP from the PC, it just stalls after sending about 40k).

This occurs whether I am sending to a BSD or Interactive PC, VAX or 
HP machines (but not a dos based 386). I have tried swapping network cards, 
changing IRQ's and fiddling with the network interface. Same problem.
Obviously the problem is with the PC TCP/IP setup (?). 

Any help as to how to approach this would be welcome.

Thanks in advance.

Niall Fallon
Dept of Microelectronics.
Trinity College Dublin
Ireland
fallon@mee.tcd.ie 

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Sep 1993 11:49:05 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP Timestamps and Solaris

>Has anyone encountered problems with sending ICMP timestamp requests to
>a Solaris system?

By default SunOS 5.x does not respond to ICMP timestamp requests:

	solaris % ndd /dev/ip ip_respond_to_timestamp
	0

If you have superuser permission you can change this to 1 with ndd.

	Rich Stevens  (rstevens@noao.edu)

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 1993 09:35:14 +0200
From:      koos@hacktic.nl (Koos van den Hout)
To:        comp.protocols.tcp-ip
Subject:   rcp command for packet-driver

In an application I need to copy a complete directory tree from a Novell
file server to a Unix system.

Since both machines are connected to the same ethernet, I am looking for
an implementation of the rcp command for packet driver (the ethernet runs
both Ethernet_802.3 and Ethernet_II over the ODI driver).

Is there such a beast (yes, I have been asking archie about it).

Thanks in advance.

-- 
||| Koos van den Hout. koos@kzdoos.hacktic.nl (pref.).

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Sep 1993 13:30:02 GMT
From:      mbmg@beethoven.mitre.org (M.Michnikov)
To:        comp.protocols.tcp-ip
Subject:   Sun tcp delay adjustment for mpeg movies

I need help with the following problem.

I play an mpeg movie on one sun workstation (running 4.1.1) and display
it on another sun using X-windows. Both are connected to a fan-out
box.  There is a switchable encryption device between suns. That device
is known to introduce a 5 times delay when switched in. However, it
does not cause tcp retransmissions when used while running ftp or a
specially written test program (checked with etherfind).

When the encryption device is swithed out, the mpeg display looks
normal, with maybe 20 frames per second. With encryption switched in,
the display slows down about 50 times, with 1 frame displayed in 4
seconds, on the average.

Using etherfind I can see that about every fourth tcp packet sent for display
is being retransmitted, and that every retransmission is preceded by a delay
of about 800 msec causing severe performance degradation.

Question: how can I use adb (or anything else) to decrease that retransmission
delay, or, maybe, get rid of retransmission to make display performance better?

Thank you for your help.

Michael.

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Sep 1993 14:46:18 GMT
From:      itbwvb@puknet.puk.ac.za (MNR W VAN BELKUM      )
To:        comp.protocols.tcp-ip
Subject:   (Q) New campus Backbone. RFC

Hi

We are currently implementing a Collapsed Backbone for the campus.
We are upgrading from a 10Mbit Pronet10 Backbone to a Collapsed Backbone.
We are also centralizing all Hosts (Novell,RS/6000,OS/2 Database server
etc.), while still keeping most users on the same ethernet segment
that their hosts are on. We also decided to keep the old Proteon router 
and Pronet10 backbone as backup for Fiber Optic failer. Because the 
RS/6000 came with Token Ring card, we are also going to connect all 
the RS/6000 together with 16Mb Token Ring. This will serve as a path
that the RS/6000 will use for services like NFS etc.
(See Fig)

The question now is what have we overlooked ?

Setup

      =================================          ^
     ||   ProNet10 Old Backbone       ||         |
    Pro=======Pro========Pro========Pro       Fiber Optic to diffrent  
    /\         /\         /\         /\       Buildings on Campus
   /  \       /  \       /  \       /  \      
  /    \     /    \     /    \     /    \        |   Pro - Proteon P4100+
 /      \   /      \   /      \   /      \       v         Routers
 l      l   l      l   l      l   l      l       -    =  - ProNet10 Dual Ring                        
 +-NovS-+   +-NovS-+   +-NovS-+   +-NovS-+       ^    +  - Connection
 l      l   l      l   l      l   l      l       |    )  - Not connected
 l   RS-+   +-RS   l   l      l   l   RS-+       |
 l   |  l   l |    l   l      l   l    | l       |
 +-RS|  l   l |    l   l   RS-+   +-RS | l    This is all in the Central
 l | |  l   l_)___ l   l ___)_l   l |  | l    Location
 l | |  l_____)__B/Router __)_____l |  | l
 l_)_)________)____/   \____)_______)__)_l          RS   - IBM RS/6000
   | |        |             |       |  |            NovS - Novell 3.11 server
   | |        |             |       |  |         |  B/Router - Wellfleet 
   | |        |             |       |  |         |         or Alantec PowerHub
***+*+********+*************+*******+**+*        |  *  - 16Mb Token ring
*      16Mb Token Ring (for NFS etc)    *        |  l  - Ethernet 
*****************************************        v  

We would like any comments on this setup (RFC).
Does anybody see problems with this implementation
(RIP, SAP's OSPF etc) ?
What does the Novell File server do if they are in parallel with a router
Or what does two routers do if they are in parallel (In other words
two router offer the same cost RIP path.)

PS
   Proteon Software version 8.2 (i know it is old)
   RS/6000 software versions 3.1.2 to 3.2.3
   Novell software version 3.11
   We are running two protocols TCP/IP and IPX (Ethernet_II)

Please email direct, I will be on leave for the next two weeks.
Thank you
Wilhelm van Belkum
 Potch Univ.       Email :                     Tel: 
 Potchefstroom        itbwvb@puknet.puk.ac.za      Voice (0148) 992126
 West Transvaal       itbwvb@pukrs3.puk.ac.za      FAX   (0148) 992799
 South Africa         itbwvb@pukvm1.puk.ac.za
                
 

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Sep 1993 16:18:52 GMT
From:      Administration <test1@test1.belpak.minsk.by>
To:        comp.protocols.tcp-ip
Subject:   <none>

SUBSCRIBE comp.protocols.tcp-ip
UNSUBSCRIBE comp.protocols.tcp-ip


-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 1993 13:34:08 +0200
From:      jpmens@ingres.com (Jan-Piet Mens)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Is source for NIS (YP) available ?

The subject says it: Is the source for NIS (former YP) available ?
Can someone give me a hint on where to find it ?
Thanks.
	Jan-Piet
-- 
Jan-Piet Mens                                               jpmens@ingres.com
Ingres GmbH, Frankfurt, Germany                              +49 69 66413-285

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Sep 1993 17:04:16 GMT
From:      STURDJ@A1.Medtronic.com (JamesSturdevant)
To:        comp.protocols.tcp-ip
Subject:   Re: recoverable ftp/ftp wrapper

In article <1993Aug27.133041.15048@glv.uucp> bounds@gulaam.glv.com (Frank Bounds) writes:
>From: bounds@gulaam.glv.com (Frank Bounds)
>Subject: recoverable ftp/ftp wrapper
>Anyone aware of a version of ftp that can detect failed xfers and
>restart or flag the fact that it failed in some meaningful way
>(so it could be restarted automatically)? We would need to do this on UNIX 
>and VAX/VMS systems. 

That sounds like a good application for C-Kermit.  It has a script language, 
loggin capabilities, success and failure tests, can run over TCP/IP on VMS 
and UNIX...

It's all documented in "Using C-Kermit" by Frank da Cruz and Christine 
Gianone. ISBN 1-55558-108-0 from Digital Press (US$35).  Source and some 
binaries are available at watsun.cc.columbia.edu in /pub/kermit/b and 
/pub/kermit/bin.

JamesS
Opinions are a dime a dozen.
Please send $0.0083.
sturdj@a1.medtronic.com

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Sep 1993 18:13:53 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun tcp delay adjustment for mpeg movies

M.Michnikov (mbmg@beethoven.mitre.org) wrote:

: I play an mpeg movie on one sun workstation (running 4.1.1) and display
: ...
: Using etherfind I can see that about every fourth tcp packet sent for display
: is being retransmitted, and that every retransmission is preceded by a delay
: of about 800 msec causing severe performance degradation.
: Question: how can I use adb (or anything else) to decrease that retransmissi
: delay, or, maybe, get rid of retransmission to make display performance bett

What is the TCP window size being shown by etherfind? It is probably 4
KB or something equally small. I don't know if 4.1.1 had "fast
retransmit," but if it does, you will want at least an 8 KB window (on
Ethernets) for it to be able to work as it requires receiving three
duplicate ACK's. 

If you have access to application source, you can add some setsockopt
calls for SO_SNDBUF and SO_RCVBUF on each side. Otherwise, you will
probably find variables called tcp_sendspace and tcp_recvspace which
will be the system defaults. (the names might vary slightly from OS to
OS)

rick jones


-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Sep 1993 18:24:31 GMT
From:      Sam.Wilson@ed.ac.uk
To:        comp.protocols.tcp-ip
Subject:   Re: Firewalls could help put off the IP address shortage

Tom Crawley (tomc@osi.curtin.edu.au) wrote:
: Without giving much thought to the problem, is it be possible to construct a
: gateway that dynamically assigned external IP addresses to internal IP
: addresses and vv, and replaced addresses (transparently) in the header on
: the fly as IP packets pass through the gateway? That way the (internal) host
: need only be assigned  a single address. Requires some high speed processing
: at the gateway course, but not out of the question these days.
 
: IP addresses not carried by the IP header would require some thought, such
: as DNS info. Point me to the appropriate RFC!

As Tony Li of Cisco has already pointed out, the IETF already has people
working on this - the NAT (Network Address Translator) stuff.  As you
hint, the major problem is that it has to be able to guddle about inside
packets to do internal translations - binary addresses aren't that bad
but when they're carried in ASCII (the big one everyone always quotes is
the FTP PORT command, isn't it?) it gets little nastier.

Personally, having lived too much of my life behind Application level
gateways (the UK had different protocols from the rest of the world for
much too long) I get more than a little nervous about this approach -
remember the gateway has to be modified (hopefully just a table
rewritten, but it has to be everyone's table) every time someone comes
up with a new application that carries an IP address inside a packet. 
Bummer!

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




-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Sep 1993 18:30:34 GMT
From:      pim@cti-software.nl (Pim Zandbergen)
To:        comp.unix.sys5.r3,comp.protocols.tcp-ip,comp.unix.pc-clone.32bit
Subject:   ISC Unix telnetd lowercasing TERM variable

I've noticed that when telnetting to an ISC Unix  box,
the negotiated TERM variable has become lower case.

Is this a bug or a feature ? Is there a fix for this ?

Thanks.
-- 
E-mail : Pim Zandbergen <pim@cti-software.nl>
S-mail : Laan Copes van Cattenburch 70, 2585 GD The Hague, The Netherlands
Phone  : +31 70 3542302
Fax    : +31 70 3512837

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Sep 1993 18:42:52 GMT
From:      Sam.Wilson@ed.ac.uk
To:        comp.protocols.tcp-ip
Subject:   IP FORWARDING

Here at the University of Edinburgh we have recently been struggling
with what seemed to us a most bizarre problem with A Well Known
Manufacturer's TCP/IP product.  The machine was connected to an ethernet
and an FDDI ring.  The ethernet has a well connected router speaking
RIP; the FDDI does not carry RIP.  The machine therefore had a good
supply of routes to local subnets pointing out its ethernet and only the
directly connected FDDI subnet routed out the FDDI i/f. 

The bizarre phenomenon was that hosts anywhere on the local net could
succesfully communicate with (ping, telnet, whatever) the ethernet
interface, but only hosts directly on the FDDI could talk to the FDDI
i/f.  A ping packet, say, arriving at the FDDI i/f from another subnet
would NOT be answered, even though there was perfectly good route to
that subnet pointing out the ethernet i/f.

The solution to this problem was to turn on IP forwarding (which was off
by default).  Now this is not Unix and this is not the IPFORWARDING
kernel variable, though it sounds suspiciously like it.  With IP
forwarding switched on the machine would reply to pings from
non-directly-connected hosts arriving on the FDDI i/f by sending the
reply out of the ethernet. 

The vendor maintains that this is, in some sense, 'correct' behaviour. 
I find this difficult to believe, since in this case the machine is not
forwarding a packet, it is generating a reply on its own behalf.  I
don't have any experience of Unix (BSD?) hosts with IPFORWARDING set
off, so I was wondering if anyone out there can tell me whether this is
the kind of behaviour I would observe in that case.  The current state
seems bizarre since it partitions the network into two - depending on
the state of the machines internal routing table other hosts 'out there'
can only use one of its two addresses, traffic to the other address
being ignored. 

Thanks, as they say, in advance. 


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

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Sep 1993 19:12:39 GMT
From:      wrl@wdl.loral.com (Bill Lewandowski)
To:        comp.protocols.tcp-ip
Subject:   Why is connection to nic.ddn.mil slow

Hi,

This seems like an old story but why is the connection to nic.ddn.mil
so slow again (Yes, I know there are two NIC's now, one for the US Military
and one for the rest of us). There used to be a connection through NASA to
the MILNET and NSFNET (The rest of us).

I did a telnet to nic.ddn.mil today (and many past days) so I could do
a "whois" for some people I need to talk too in the Military who I
know are in the "Military "whois" database.

The telnet connection took 75 seconds and it took and additional 159
seconds
to get the greeting banner. It took another 300 seconds for my request to
be echoed back to me. It then took another 300+ seconds to get the
responce.

I hope Milnet users get better responce than us on the Internet.

FYI, its not my end, I have a T1 in to BARRNet and I have been doing
large FTPs today and getting 1Mb throughput on a 1.544 link so
I again assume its the Milnet.

-- 
Bill Lewandowski          Systems Planning & Telecommunications
Systems Engineer          Loral Western Development Labs
V:(408) 473-4362          wrl@wdl.loral.com
F:(408) 473-4440          CIS:72407,3552
/pn=lewandowski, bill/u=msmac/o=lwdl/p=loral/a=attmail/c=us/

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Sep 1993 19:16:11 GMT
From:      geno@sodium.lincroftnj.ncr.com (Eugene Rice)
To:        comp.protocols.tcp-ip
Subject:   Implementations of SNMPv2

Are there any implementations of SNMPv2 out there, either
commercial or public domain?

Thanks,

Geno Rice

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 93 19:28:43 GMT
From:      ccml@hippo.ru.ac.za (Mike Lawrie)
To:        comp.protocols.tcp-ip
Subject:   Re: Slow FTP in one direction only!!

In <1993Sep2.110557.1@vax1.tcd.ie> nafallon@vax1.tcd.ie writes:

>I am having severe speed problems when trying to ftp files from my PC (running 
>Interactive unix). The transfer rate is fine when sending/getting files to
>the machine, but all transfers in the other direction creep along at about 2k 
>per minute. (Actually, when you are logged into the remote machine this happens
>. When running FTP from the PC, it just stalls after sending about 40k).
>..[]...
>Any help as to how to approach this would be welcome.

I cleared a similar problem some time ago - we use CUTCP on DOS-based
PCs, and link to SUNOS. The key lay in setting block sizes and the like
(?MTU?) so that there was not so much fragmentation occurring.

Mike
-- 
Mike Lawrie                             <ccml@hippo.ru.ac.za>
Director, Computing Services            ph +27 461 318279/80
Rhodes University, Drostdy Rd           fx +27 461 25049
Grahamstown 6140, South Africa

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 1993 20:04:29 GMT
From:      babb@sciences.sdsu.edu (Jeff Babb)
To:        comp.protocols.tcp-ip
Subject:   Where is TCP/IP protocol FAQ?

Sub sez all.
Thanks,
Jeff.

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Sep 1993 20:52:26 GMT
From:      bwarner@mentor.cc.purdue.edu (Bill Warner)
To:        comp.protocols.tcp-ip
Subject:   Re: Why is connection to nic.ddn.mil slow

In article <wrl-020993121005@irm124.wdl.loral.com> wrl@wdl.loral.com (Bill Lewandowski) writes:
>Hi,
>
>This seems like an old story but why is the connection to nic.ddn.mil
>so slow again (Yes, I know there are two NIC's now, one for the US Military
>and one for the rest of us). There used to be a connection through NASA to
>the MILNET and NSFNET (The rest of us).
>

From RFC 1400:

   The T1 service currently available to the DDN NIC will be
   disconnected by June 1, 1993.  This will leave only 56K access to the
   DDN NIC site. Excessive traffic to this site after that date will
   cause congestion.

-Bill


-- 
Bill Warner						(317)494-1787
General Consultant					bwarner@cc.purdue.edu
Purdue University Computing Center			bwarner@PURCCVM.BITNET

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 1993 22:12:19 GMT
From:      eks@daimi.aau.dk (Eigil Krogh S|rensen)
To:        comp.unix.sys5.r3,comp.protocols.tcp-ip,comp.unix.sys5.misc,comp.mail.misc
Subject:   smtp

Question:

How do I easiest get a SMTP to run on a Mot. sysV/68 R3V6.2 ?

Which source/bins can I use. Where can I get it ?

Thanks

Eigil

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 1993 23:01:54 GMT
From:      dwee@lucpum.it.luc.edu (Don M. Wee)
To:        comp.protocols.tcp-ip
Subject:   Re: IPX-TCP/IP gateways?

cdb21@cas.org () writes:
: We are planning to develop a client application to run om a PC in Novell
: networks that will communicate with a remote TCP/IP server.  We are aware
: that you can put TCP/IP on the PC and this would be our preferred approach,
: but we expect there may be cases where the client site does not wish to
: put TCP/IP on their Novell for whatever reason (memory limits on PC, etc.).
: So we must account for the possibility we may need to develop an IPX client.
: Are there any IPX-TCP/IP gateways commercially available?
: I'd also be interested in hearing from anyone who thinks this concern is
: not warranted.
: Thanks.
: Carl D. Bloomfield                                 email:  cdb21@cas.org
: Chemical Abstracts Service                         phone:  614-447-3600 (3319)
: 2540 Olentangy River Rd.                           fax:    614-447-3697
: Columbus, Ohio 43210
Yes, the concern is warranted: if someone is using a Netware server as a
router between the local departmental segment and the backbone, the server
may or may not be routing IP as well as IPX.  If the server is NW2.x is CAN'T.
  Such IPX-to-IP gateways do exist as commercial products:
- Novix is made by Firefox, 401 Park Place, Ste 301, Kirkland, WA 98033, 
206/827-9066; fax 206/827-8285.  Novix runs as NLM or VAP and can provide
APIs equivalent to LAN Workplace for DOS.
- CatIPult is made by IPSwitch, 508 Main St, Reading, MA 01867
617/942-0621; fax 617/942-0823. CatIPult runs as a dedicated box (on OS/2)
and can provide APIs equivalent to pc/tcp (INT61) from FTP Software.
- NCM makes a gateway that runs as a NW2.x VAP; however, I don't think
they provide any standard APIs for a developer to write to.  (Their
address also isn't in the LAN Magazine Buyer's guide that I pulled the
other addresses/phone numbers from.)
   Good luck!
Don M. Wee
Loyola University Chicago is my employer, but should not be considered the
source of the opinions expressed above.
Internet: dwee@acm.org  or  dwee@mail.luc.edu
Bitnet: $acsdmw@luccpua   fax 312/508-2262  Compuserve:76314,3315

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Sep 1993 01:01:14 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI access to TCP/IP

In article <1993Sep2.085759.10171@terminus.ericsson.se> satish@terminus.ericsson.se writes:

[Regarding Comer Volume III-TLI]

>Does anyone know if there are major differences (apart from using TLI in 
>place of BSD Sockets) in the contents of the book? 

	Judging from the Tables of Contents (I haven't read the
III-TLI volume fully yet), they are very similar and differ primarily
in use of TLI rather than Sockets.  Note that the differences in those
programming interfaces also cause some of the discussions in
"Algorithms & Issues in Client-Server Design" to vary.

	In short, if you are a TLI/XTI kind of programmer than you
should get Volume III-TLI and if you are of the sockets persuasion
then you should get Volume III-Sockets.

	I have all 4 Comer books primarily as defense against "hallway
consulting" interruptions on days when I'm swamped with other work.
My general observation is that folks who have no experience with
network programming generally have an easier time learning and using
the TLI/XTI interfaces and that long-time Sockets programmers find no
real need to switch.

	In a (now altogether too rare) moment of sanity, the folks who
are putting together the IEEE POSIX specification for network
programming will be standardising both 4.4 BSD Sockets and TLI/XTI
interfaces.  I believe that both interfaces have had very slight
tweaks -- only where necessary.  The balloting on this specificaton
(POSIX.12) should start sometime this fall, though it isn't certain
precisely when.

>Also, are the sources available on some ftp site?

I dunno.

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Sep 1993 01:06:20 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Why is connection to nic.ddn.mil slow

I've also had really poor performance to nic.ddn.mil lately.  

	On the first occasion, I ran a traceroute and found that my
route to nic.ddn.mil from itd.nrl.navy.mil went via SURA to FIX-East
to West Virginia, to Atlanta, to North Carolina, back to FIX-East and
thence out to the nic.  This routing loop is especially painful since
I'm in DC and the NIC is in Herndon, VA within the same metro area.  I
made an enquiry about this with SURA operations and was told both (1)
that ANS was having hardware/software problems with its equipment and
that the obscure re-routing was necessary and (2) later by a different
person that it was a transient routing loop problem that was being
fixed.

MORAL:	If you don't have traceroute(8), you should get it.  Go look
on ftp.ee.lbl.gov for source code (if you have an HP you are out of
luck as per normal for HPUX users :-(.

Ran
atkinson@itd.nrl.navy.mil

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Sep 1993 01:07:27 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Implementations of SNMPv2

In article <CCqquz.CwF@lznj.lincroftnj.ncr.com> geno@sodium.lincroftnj.ncr.com (Eugene Rice) writes:
>Are there any implementations of SNMPv2 out there, either
>commercial or public domain?

Yes. Both kinds exist.

This discussion is misplaced and should be moved to
comp.protocols.snmp instead.  Followups are do directed.



-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Fri, 03 Sep 93 02:05:12 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Slow FTP in one direction only!!

In article <1993Sep2.110557.1@vax1.tcd.ie> nafallon@vax1.tcd.ie writes:

   I am having severe speed problems when trying to ftp files from my
   PC (running    Interactive unix). The transfer rate is fine when
   sending/getting files to the machine, but all transfers in the
   other direction creep along at about 2k  per minute. (Actually,
   when you are logged into the remote machine this happens   . When
   running FTP from the PC, it just stalls after sending about 40k).

40K, you say?  Hmmm...  40K.  That sounds *very* familiar.  I'll bet
you're using a 3c501.  If so, nuke it and get a modern Ethernet card,
or else frob the TCP to make its MSS==Window.

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

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Sep 1993 02:34:56 GMT
From:      deh@rocket.com (Dale E. Higgs)
To:        comp.unix.questions,comp.protocols.misc,comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Determining IP address of incoming telnet (TCP/IP and TLI)

Hello.  I am posting this for a friend.  The cross-posting is my fault.
Please note his request to reply to him via e-mail.  Thank-you in advance
for your assistance.

Dale E. Higgs deh@rocket.com
Olin Aerospace Rocket Research Company
  
===========================================================================
Reply-to: Tony Abo <tabo@hitech.com>

*** Please reply via email... I do not have a usenet feed *** 

I am developing a mission critical application which must run on
UNIX hosts.  It is intended to run on a single host system, and
be accessed via direct connect ascii terminals, or ascii
terminals via a terminal server.  

The application has a very strict (government imposed)
restriction that access to the system be monitored by *physical
terminal*, as well as user id.  The physical terminal will also
be used for routing responses to queries which may arrive at the
host system sometime after the querying user has logged out of
the system.  Therefore the application needs to have access to a
unique identifyer for each physical terminal.

So far, this presents no problems for direct connect users.  The
controlling terminal (i.e. /dev/...) is always unique for the
terminal's hardware port.

The problem is identifying TCP/IP telnet users logging in through
the terminal servers.  We have determined that the remote IP
address and port number provides a physical port in many
terminal servers.  The problem is how to determine the address
and port number of an incoming telnet session? 

A solution to this problem which I have had some success with on
some UNIX boxes is to replace the telnetd program with my own
interlude.  The interlude uses getpeername() to get the address
and port, writes it to a /tmp file (keyed by pid), and then
exec's the real telnetd.  The application program can then trace
the parent (I hope) of the initial login shell to find which /tmp
file to read.

Unfortunately this solution does not seem to work on the most
critical portation which I must make: DG Aviion's DGUX.  This
implementation of telnetd uses a SV4 TLI endpoint (instead of a
socket) for the telnet sessions accepted by inetd.  They claim
that this performs better than sockets.  I cannot, however, find
an equivalent to getpeername() which will operate on a TLI
endpoint which is already in dataxfer state.

Can anyone please...

1. Tell me how to get the peer name of a TLI end point?

2. Suggest another way to accomplish my goals?

3. Shoot me and put me out of my misery?

Thanks in advance,

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

Tony Abo
Hitech Systems, Inc.
1964 Westwood Blvd. # 435
Los Angeles, CA 90025

Internet: tabo@hitech.com
Voice:    (310) 475 3210
Fax:      (310) 474 0655

-- 
 ____________________________________________________________________________
| Dale E. Higgs                                             deh@rocket.com  |
|     "When he sneezes, he looks like a party favor."       !uupsi!rrc!deh  |


-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Sep 1993 14:03:15 GMT
From:      weathere@emr1.emr.ca (Carl Weatherell)
To:        comp.protocols.tcp-ip
Subject:   Driver for NetWare Card with Prolinc

I am trying to connect to Internet using Prolinc.  The Lan
card in the machine is a Netware Ethernet NE1000 V3.00EC
(891227).  Does anyone have, or know where I can get, an appropriate
driver (i.e. with an HP card HPLAN.DOS is used).  I should
warn you that I am only mildly literate in TCP/IP protocols. A
complete AUTOEXEC.BAT and CONFIG.SYS would be a great help with any
recommended drivers.

Thanks!

Carl
weathere@emr1.emr.ca

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Sep 1993 15:24:03 GMT
From:      phuong@rocky.raleigh.ibm.com (Phuong Thanh Nguyen)
To:        comp.protocols.tcp-ip
Subject:   Re: How to send ICMP packets?

You have to open a raw socket with type IPPROTO_ICMP.  It's not too bad.
I wrote one my self.  Please refer to the book called UNIX Network Programming
of W. Richard Stevens.  It'll able you to do several things with sockets
and IP.
*********************************
Opinions are mine not IBM's
Have a "phuongtastic" day,
Best regards,
Phuong Thanh Nguyen
Networking System.
PNGUYEN@VNET.IBM.COM
*********************************
In article <25teo4$6mt@oak4.doc.ic.ac.uk>, cmft@doc.ic.ac.uk (C M F Tsang) writes:
|> 
|> I am trying to send some ICMP packets to some machines, the system
|> we are using is SunOS, i.e. bsd Unix. I know you can open a TCP
|> socket in bsd and use services like whois, but I can find the 
|> method to send a raw ICMP packet, indeed an IP packet down the net.
|> 
|> Could someone advice me how to do it? The basic thing I know is
|> to open a RAW UDP socket, but I'm not sure about how to assemble
|> the packet and write it, and how to receive the reply?
|> Do I use recv, recvfrom ... which of that lot?
|> 
|> Thanks for any help or pointers.
|> 
|> Frank Tsang
|> 

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Sep 1993 15:44:21 GMT
From:      phuong@rocky.raleigh.ibm.com (Phuong Nguyen)
To:        comp.protocols.tcp-ip
Subject:   Re: rawip broadcasts

From what I understand, in the network only the router send ICMP back to
the source which broadcast something it doesn't understand.  The hosts 
are prohibited to answer back in such case.  The reason is just imaging
all the hosts the same LAN try to answer back a broadcast it would cause
a storm on the LAN.
The raw IP (255) is rarely used.

*********************************
Opinions are mine not IBM's
Have a "phuongtastic" day,
Best regards,
Phuong Thanh Nguyen
Networking System.
PNGUYEN@VNET.IBM.COM
*********************************

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Sep 1993 16:01:03 GMT
From:      phuong@rocky.raleigh.ibm.com (Phuong Nguyen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP subnetting and RIP

It's NO NO.  If using RIP router 3 won't be able to talk to router 3 and
vice versa.  According to the RIP RFC, RIP is not capable of advertising
the subnetted network because it doesn't have a field to cary subnetted mask.
So, it only advertise the natural part which in your case is 198.178.216.
Router 3 advertises this 198.178.216 to router 2, router 2 thinks it already
has this network so it will ignore this and the same thing happens as for
router 2.
To solve this problem you have to use OSPF if you want to use subnetted
network.
*********************************
Opinions are mine not IBM's
Have a "phuongtastic" day,
Best regards,
Phuong Thanh Nguyen
Networking System.
PNGUYEN@VNET.IBM.COM
In article <262iep$qs4@helios.intranet.gr>, antonis@intranet.gr (Antonis Kyriazis) writes:
|> 
|> 
|> I think the corrected ip numbers are:
|> 
|>  
|>                             198.51.250 Ethernet
|>       ---------------------------------------------------------
|>           |                                  |
|>           |                                  |
|> -------Router 1                         Router 2
|> to remote |                             |   |   |
|> location  |        Token Ring           |   |   |
|>           |_____________________________|   |   |
|>                198.178.216.(161-190)        |   |
|>                                             |   |
|>                                             |   | 56Kbps Leased Line
|>                         Ethernet            |   | 198.178.216.(97-126)
|>                     ________________________|   |
|>                       198.178.216.(129-158)     |
|>                                                 |
|>                                                 |
|>                                                 |
|>                                             Router 3
|>                                              |   |
|>                             Token Ring       |   | Ethernet
|>                             _________________|   |___________________
|>                             198.178.216.(65-94)    198.178.216.(33-62)
|>  
|> 
|> Your scheme means you reserve 3 bits for subnets and 5 bits for hosts.
|> The addresses x.y.z.32, x.y.z.64, x.y.z.96, x.y.z.128, x.y.z.160 and
|> x.y.z.192 are not accepted because, according to the subnet mask, appear
|> to have zero network portion (a general subnetted ip address consists
|> of: <class X address>.<subnet portion>.<host portion> ), and continuous
|> zeros mean "this"! Similarly the addresses x.y.z.63, x.y.z.95, x.y.z.127,
|> x.y.z.159, x.y.z.191 and x.y.z.223 represent the broadcast addresses for
|> the corresponding subnets, provided that the broadcast format is "all
|> ones".
|> 
|> So, after the corresponding definitions for subnet and broadcast mask,
|> RIP should work...(?)
|> 
|> 
|> Please, correct, if I'm wrong.
|> 
|> +-------------------------------------------------------------------+
|> |     Antonis Kyriazis                                              |
|> | Networks & Communications       e-mail: antonis@intranet.gr       |
|> | INTRACOM sa                                                       |
|> | 19.5 km Marcopoulo Ave.          fax:   +30-1- 66 44 379          |
|> | Peania 190 02                           +30-1- 66 43 718          |
|> | GREECE                          phone:  +30-1- 66 44 961-5        |
|> |                                         +30-1- 88 43 715          |
|> | "The expressed opinions are of my own"   + - MACEDONIA IS GREEK - +
|> +-------------------------------------------------------------------+
|> 

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Sep 1993 20:31:39 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: IP subnetting and RIP

phuong@rocky.raleigh.ibm.com (Phuong Nguyen) writes: 

>It's NO NO.  If using RIP router 3 won't be able to talk to router 3 and
>vice versa.  According to the RIP RFC, RIP is not capable of advertising
>the subnetted network because it doesn't have a field to cary subnetted mask.
>So, it only advertise the natural part which in your case is 198.178.216.
>Router 3 advertises this 198.178.216 to router 2, router 2 thinks it already
>has this network so it will ignore this and the same thing happens as for
>router 2.
>To solve this problem you have to use OSPF if you want to use subnetted
>network.

I don't agree.  Rip only has to propagate the routes, it doesn't have to
set the subnet masks.  As long as each router knows about the how all of
the nets that it's connected to are subnetted, you're probably all right.

The only time propagating subnet masks via a routing protocol would be
important is if a different NEXT-HOP router is to be used to reach different
subnets of the same net address.  Given the table below, only router 2 could
be use to forward to all of the various 198.178.216.* subnets (not router 1)
since rip could not propagate knowledge of how 198.178.216 is subnetted to the
hosts on 198.51.250.  All of the hosts on the 198.178.216.* subnets will
have to be configured so as to inherently know their subnet mask, but
assuming that's possible, there should be no problem with this scheme.
(Admittedly, you would desire to have the routing protocol set subnet masks
for you instead of having to do it yourself statically, but it appears that
rip simply doesn't have that capability.)

>In article <262iep$qs4@helios.intranet.gr>, antonis@intranet.gr (Antonis
>Kyriazis) writes:
 
>|> I think the corrected ip numbers are:
>|> 
>|>  
>|>                             198.51.250 Ethernet
>|>       ---------------------------------------------------------
>|>           |                                  |
>|>           |                                  |
>|> -------Router 1                         Router 2
>|> to remote |                             |   |   |
>|> location  |        Token Ring           |   |   |
>|>           |_____________________________|   |   |
>|>                198.178.216.(161-190)        |   |
>|>                                             |   |
>|>                                             |   | 56Kbps Leased Line
>|>                         Ethernet            |   | 198.178.216.(97-126)
>|>                     ________________________|   |
>|>                       198.178.216.(129-158)     |
>|>                                                 |
>|>                                                 |
>|>                                                 |
>|>                                             Router 3
>|>                                              |   |
>|>                             Token Ring       |   | Ethernet
>|>                             _________________|   |___________________
>|>                             198.178.216.(65-94)    198.178.216.(33-62)
>|>  
>|> 
>|> Your scheme means you reserve 3 bits for subnets and 5 bits for hosts.
>|> The addresses x.y.z.32, x.y.z.64, x.y.z.96, x.y.z.128, x.y.z.160 and
>|> x.y.z.192 are not accepted because, according to the subnet mask, appear
>|> to have zero network portion (a general subnetted ip address consists
>|> of: <class X address>.<subnet portion>.<host portion> ), and continuous
>|> zeros mean "this"! Similarly the addresses x.y.z.63, x.y.z.95, x.y.z.127,
>|> x.y.z.159, x.y.z.191 and x.y.z.223 represent the broadcast addresses for
>|> the corresponding subnets, provided that the broadcast format is "all
>|> ones".
>|> 
>|> So, after the corresponding definitions for subnet and broadcast mask,
>|> RIP should work...(?)

Fred

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Sep 1993 21:59:39 GMT
From:      ddb0248@mcdata.com (David Beal)
To:        comp.protocols.tcp-ip
Subject:   Can you process a TCP header in 30 instructions?

When I took a tutorial from David Clark (MIT) at Interop last year,
he said that Van Jacobson had written a TCP implementation that
"processes a typical TCP header in 30 [machine language] instructions".

I'm having a hard time convincing people that this is possible.
Does anybody know if this is documented anywhere?

Please reply by email.  Thanks.

Dave Beal
McDATA Corporation
Broomfield, CO

ddb@mcdata.com


-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 93 22:01:07 GMT
From:      laum@csri.toronto.edu (Mark Lau)
To:        comp.protocols.tcp-ip
Subject:   Client death detection

Hello,

Pardon me if this question has been answered before ...

The situation is as follows:

1) There is a server process and a client process connected using TCP.
2) The socket on the server side is blocking whereas the one on the client side
   is declared non-blocking.
3) The server invokes select and blocks.
4) The client is killed by "kill -9"
5) The server stays in select and does not return most of the time.  Once every
   now and then it returns with a read mask indicating the client socket
   descriptor is ready for I/O.
6) In the case when the server stays in select, netstat shows that the TCP
   connection is still in an ESTABLISHED state.

However, if the client is killed by a simple Ctrl-C, the server's select call
will always return.

My questions are:

1) Since the server is not catching the Ctrl-C (Sig Term, I think), so what is
   so fundamentally different between these two cases so that select will
   return in only one case and the OS still thinks the connection is alive and
   well?

2) If the server cannot count on select to return when the client dies, what is
   the best detection method?

BTW, I am running both processes on a Sparc station running SunOS 4.1.x.

Any comments will be greatly appreciated.

Many thanks (in advance).

mml.

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 1993 12:20:48 -0400
From:      cross@shetland.ae.eds.com (Jason Cross)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Non-blocking connects

Before I go down this path, are there any caveats with using
non-blocking connect on a connection-oriented socket?  Also,
in the "UNIX Network Programming" book it mentions that a
non-blocking connect returns immediately with the errno value
set to EINPROGRESS.  What do I check to see if I have a valid
connection, and if it's errno what is it set to?  The reason
I'm thinking about doing this, is that I'd like to have a bit
more control over the timeout value of a connection attemp.  
This is for a PC connecting to a UNIX host.  Right now the 
connect time-out parameter is set at 75 seconds, and it can't 
be reduced.  I would like to have it down around 15 seconds. 
thanks.
-- 
ciao,
Jason Cross
EDS
Troy, Mi.

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 93 17:40:17 +1000
From:      itb451natzke@qut.edu.au
To:        comp.protocols.tcp-ip
Subject:   Wanted Src: Sockets for IBM PC DOS

Hi,
   I'm looking for source (or a compiled library) which supports "sockets" for
IBM PC DOS.  Your help greatly appreciated.

Fred NATZKE
Email: ITB451NATZKE@ACACIA.QUT.EDU.AU 
   or: n0948861@WATER.FIT.QUT.EDU.AU

->  What is appealing to the eye may not be appealing to the heart.
 

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 93 21:44:45 GMT
From:      hawkeye@glia.biostr.washington.edu (Ken Keys - TF Dude)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: Non-blocking connects

In <26af90$jvg@shetland.ae.eds.com> cross@shetland.ae.eds.com (Jason Cross) writes:

>Before I go down this path, are there any caveats with using
>non-blocking connect on a connection-oriented socket?  Also,
>in the "UNIX Network Programming" book it mentions that a
>non-blocking connect returns immediately with the errno value
>set to EINPROGRESS.  What do I check to see if I have a valid
>connection, and if it's errno what is it set to?

The problem with this method is determining when the connect is
complete, and whether it was successful.  On some systems, you can tell
connect() has completed when the socket select()s true for writing, and
then test it by writing zero bytes to it.  This method is ugly, not
particularly portable, and provides no way of determining the cause of
failure if connect() fails.  Another problem is that on some systems,
select() for writing always returns true.

A better and more portable (at least to modern OS's) solution is to use
a connection server.  This is a seperate process which does a normal
blocking connect(), and when it's finished passes the new file
descriptor back to the client through a pipe.  This of course requires
the ability to pass descriptors; 4.3 BSD, 4.4 BSD, SVr4, and systems
derived from them, have this ability.  This is described somewhat in
_UNIX Network Programming_, and more completely in the newer Stevens
book, _Advanced Programming in the UNIX Environment_.

-- 

Ken "Hawkeye" Keys
hawkeye@glia.biostr.washington.edu

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5 Sep 1993 02:24:54 GMT
From:      tim@sporran.uucp (Tim Fry)
To:        comp.unix.questions,comp.protocols.misc,comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Determining IP address of incoming telnet (TCP/IP and TLI)

In article <1993Sep3.023456.2595@rocket.com> deh@rocket.com (Dale E. Higgs) 
writes:

>1. Tell me how to get the peer name of a TLI end point?

No suggestions for this one.
>
>2. Suggest another way to accomplish my goals?
>
If you were using a connectionless transport provider under the TLI (ie. UDP),
then you can extract the sender IP address and port from the t_unitdata
argument of the t_rcvudata(3N) call. This is probably not much use unless
you are using your own protocol though. 

Another thought -- Why does your interlude have to use the TLI as well?
Why not pick up the connection using a regular socket and then use the 
t_sync(3N) call to convert the socket fd to a TLI endpoint and then exec the
real telnetd?

>3. Shoot me and put me out of my misery?
>
Sorry, we have gun control laws in Canada :-)

-- 
Tim Fry      			tim@sporran.uucp
Toronto, Canada


-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5 Sep 1993 07:25:31 GMT
From:      crohrer@advtech.uswest.com ( Chris Rohrer)
To:        comp.protocols.tcp-ip
Subject:   TCP over asymmetrical link

In designing protocol stacks to operate over a CATV network the question of
the suitability for TCP operation comes up.  The upstream link will
probably be in the speed range of about 10 kbps and the downstream link will
be in the range of 1 Mbps.  I know that in general on an IP network the
forward and reverse paths may be very different and thus the arrival times
and rates of the IP packets that carry TCP could arrive at quite arbitrary
times.  I'm concerned that there might be some limitations on the use of
TCP or a flat out recommendation against trying to use it in such a
situation.  How dependent is TCP on there being some semblance of symmetry
in what it works over?

Thanks,

Chris Rohrer, U S WEST Advanced Technologies




-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5 Sep 1993 07:35:51 GMT
From:      crohrer@advtech.uswest.com ( Chris Rohrer)
To:        comp.protocols.tcp-ip
Subject:   Reliable broadcast protocol

I'm trying to devise a method for delivering files to many devices on a LAN
preferably simultaneously.  FTP or some other file transfer protocol using
TCP would be a possible choice if I could set up individual sessions
between file server and target terminals.  Likewise, TFTP or some other
similar mechanism over UDP could be used in situations where I would have
individual sessions.  Is there a protocol or other mechanism anyone knows
of that would handle a non-acknowledged or perhaps minimally acknowledged
capability in a broadcast mode?

Thanks,

Chris Rohrer, U S WEST Advanced Technologies


-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 1993 18:44:29 -0500
From:      sali@uafhp.uark.edu (Sal-Myster)
To:        comp.protocols.tcp-ip
Subject:   Need References, and direction.


	Greetings,

	I am in need of any reference where I can get standards set by
	IEEE for the protocols used, the message-formats or any criterion
	or rules set for protocols.

	I am sure that IEEE must have printed out such standards.

	I would appreciate it.
	
	Thank u very much.

	Salman.
	sali@uafhp.uark.edu


-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 1993 20:52:37 -0400
From:      shawn@eddie.mit.edu (Shawn F. Mckay)
To:        comp.protocols.tcp-ip
Subject:   Question: echo/tcp usage

Howdy. I have a question that I suppose I could RTFM :-), but
would probably take a net wizard out there a half second to answer,
so here goes:

Suppose I have a program (Ultrix v4.1) that does roughly.

1	s = socket (AF_INET, SOCK_STREAM, 0);
2	bind (s, remote);
3	connect (s, remote);
4	shutdown (s, 2);
5	close (s);

While connecting to the "echo"/tcp service of a remote Unix(tm)
system. How much ACTUAL network traffic is being generated? And is
there an even more trivial way to just "tickle" a remote host?

I am also having some trouble figuring out the best way to have
the timeout of the connect() be shorter, right now I'm using alarm(2)
but there must be a cleaner way?

The idea is that I am trying to see if a remote host is "up" (refusing
is also an ok response :-)), but with the least traffic per host I
can...

			Thanks for any advice,
			     - Shawn


-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 93 18:49:12 GMT
From:      jim@grimaldi.rutgers.edu (Jim Martin)
To:        comp.protocols.tcp-ip
Subject:   Re: Reliable broadcast protocol

crohrer@advtech.uswest.com ( Chris Rohrer) writes:
>Is there a protocol or other mechanism anyone knows
>of that would handle a non-acknowledged or perhaps minimally acknowledged
>capability in a broadcast mode [for file transefer]?

	You should check out the multicast based tool "imm" and
"immserv", written by Winston KC Dang <wkd@hawaii.edu>, and available
via anonymous ftp on ftp.hawaii.edu:/paccom/imm. Imm is a tool that
allows jpegs to be multicast (usually across the MBone). I end up
getting a new background via this machanism about every 10-20 Minute.
I'm sure the tranfer rates could be jacked up very significantly,
since it is _very_ tightly throttled so the various slow links (T1)
don't get overloaded. Good Luck.
							Jim

--
	Jim Martin			Internet: jim@noc.rutgers.edu
	Network Services		UUCP: {backbone}!rutgers!jim

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 93 19:54:06 GMT
From:      sp9183@swuts.sbc.com (Scott M. Pfeffer)
To:        comp.protocols.tcp-ip
Subject:   Re: Socket to serial interface program?

In article <CCJqGI.CvD@iphase.com> bfriesen@iphase.com writes:
>I am looking for UNIX source code to a program which accepts opens on a
>specified TCP port and then copies data to/from a specified serial
>port.  The idea is to allow programs that currently use sockets to
>instead use a serial port with no code changes to the program.
>
>I am interested in either a daemon style server or a program that
>can be intiated on a per-instance basis.
>
>Thanks,
>
>Bob

In case you have not already investigated this, you might want to look
into public domain SLIP (Serial Line IP) or PPP (Point-to-Point Protocol)
which does handle TCP traffic through serial ports.

If you have a Sun, you might benefit by contacting Purdue university,
which has implemented "DialupPPP", a public domain PPP for Suns.

There are a number of vendors for PPP for a variety of host platforms,
but if source code is required, I do not know if this route will suffice.

Consult news group comp.protocols.ppp for more information.


Scott Pfeffer
Southwestern Bell Telephone

"New Yorker by Birth, Floridian by Growth, Georgian by Education,
 Texan by the Grace of God, St. Louisan by Dumb Luck."



-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 1993 19:57:38 GMT
From:      cyc@quip.eecs.umich.edu (Yi-Chieh Chang)
To:        comp.protocols.tcp-ip
Subject:   RS232 driver on UNIX (SLIP ?)

I'm not sure what I need is SLIP for suppoting RS232 series line under
UNIX operating system. So, I'll describe my problem first. I'm
going to run software on HP 700 series or Sun Sparc station and I
need to communicate with several sensor units which take sample
data and can transmit the data over RS232 series line. What kind of
software I need to use on the workstation in order to
receive/communicate with those sensor units. Since I may need to
connect one of the unit at a time, a sort of polling protocol may
be desirable. Thanks for any response.

Yi-Chieh

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 1993 11:54:36 -0700
From:      schmidt@net1.ics.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and TLI

In article <CCoLJ7.7xG@sse.ie>, Paul Keogh <keogh@sse.ie> wrote:
++ I'm running a concurrent server application over TCP/IP on a SCO 3.2 2 system
++ and I'm seeing some strange behaviour under heavy load. 
++ 
++ When my server recieves an incoming connection, the poll() fires, it does a
++ t_listen(), then t_open(), t_bind() and t_accept(), the usual stuff. It then
++ forks and execs the protocol server and goes back to listening on the endpoints.
++ This works 99% of the time. When it does not work, the t_accept fails with
++ an t_errno of 0. I do a t_look() get back an event of 1 which is a connect
++ indication recieved. Any attempt to do anything on the endpoint results in an
++ error (generall invalid file descriptor).
++ 
++ Why should an asynch. event occur between the t_listen() and t_accept() and 
++ if its valid how should I handle it ? 

	Ah, you've stumbled across a dark, ugly "secret" of TLI, which
rears its ugly head occasionally under the circumstances that you
describe.  If you carefully read the TPI spec, you'll see that the
behavior you've witnessed actually conforms to the state machine
transitions that occur when the qlen field of the t_bind structure is
> 1 (basically creating a "concurrent server").

	IMHO, this "feature" of TLI is rather dubious (I've never seen
a satisfactory justification of *why* the behavior is this way).  If
you want to see the contortions required to deal with this
appropriately, check out Steve Rago's book "UNIX System V Network
Programming" p. 189-195, which contains source code and annotations
that will solve your general problem.  

	If you are willing to wait another week or so, and can use
C++, then you ought to check out the next release of my ADAPTIVE
Communication Environment (ACE) release, which provides a set of C++
interfaces for many UNIX local and remote IPC mechanisms.  I've been
finishing off a C++ wrapper around TLI that will essentially enable
you to use a "socket-like" API for dealing with this quirk of TLI.

	The current version of ACE is available via anonymous ftp from
ics.uci.edu in the gnu/C++_wrappers.tar.Z file.  I've enclosed the
README file below.

	Doug

----------------------------------------
THE "ADAPTIVE COMMUNICATION ENVIRONMENT" (ACE) C++ WRAPPER LIBRARY  

	The following directories contain the source code,
documentation, and example test drivers for a number of C++ wrapper
libraries developed as part of the ADAPTIVE transport system project
at the University of Calfornia, Irvine.  These wrappers encapsulate
many of the user-level BSD and System V Release 4 IPC facilities (such
as sockets, select and poll, named pipes and STREAM pipes, the mmap
family, System V IPC (i.e., shared memory, semaphores, message
queues), explicit dynamic linking (e.g., dlopen/dlsym), etc.), using
type-secure, object-oriented interfaces.

	Several of these wrappers have been described in issues of the
C++ Report and in the proceedings of the 1993 C++ World conference
held in Dallas, Texas in October.  A relatively complete set of
documentation and extensive examples are included in the release.

CONTENTS OF THE RELEASE

	The following subdirectories are included in this release:

	. bin	  -- utility programs for building this release such as g++dep
	. build	  -- a separate subdirectory that keeps links into the main
		     source tree in order to facilitate multi-platform
		     build-schemes
	. doc	  -- LaTeX documentation (in both latex and .ps format)
	. include -- symbolic links to the include files for the release
	. lib	  -- object archive libraries for each C++ wrapper library
	. papers  -- subdirectories with the latest versions of the C++ Report 
		     and C++ World conference papers
	. libsrc  -- the source code for the following C++ wrappers:
			Get_Opt -- a C++ version of the UNIX getopt utility
			IPC_SAP -- wrapper for BSD sockets
			IPC_SAP_FIFO -- wrapper for FIFOS (named pipes)
			IPC_SAP_SPIPE -- wrapper for SVR4 STREAM pipes and connld 
			Log_Msg -- library API for a local/remote logging facility
			Mem_Map -- wrapper for BSD mmap() memory mapped files 
			Message_Queues -- wrapper for SysV message queues
			Reactor -- wrapper for select() and poll()
			Semaphores -- wrapper for SysV semaphores
			Server_Daemon -- a wrapper for dynamically linking
			Shared_Memory -- wrapper for SysV shared memory
			Shared_Malloc -- wrapper for SysV/BSD shared mallocs
	. tests -- programs that illustrate how to use the various wrappers

	Please refer to the INSTALL file for information on how to
build and test the ACE wrappers.  The BIBLIOGRAPHY file contains
information on where to obtain articles that describe the ACE wrappers
and the ADAPTIVE system in more detail.

COPYRIGHT INFORMATION

	You are free to do anything you like with this code.  However,
you may not do anything to this code that will prevent it from being
distributed freely in its original form (such as copyrighting it,
etc.).  Moreover, if you have any improvements, suggestions, and or
comments, I'd like to hear about it!  It would be great to see this
distributed evolve into a comprehensive, robust, and well-documented
C++ class library that would be freely available to everyone.
Natually, I am not responsible for any problems caused by using these
C++ wrappers.

	Thanks,
	
		Douglas C. Schmidt
		Department of Information and Computer Science
		University of California, Irvine
		Irvine, CA 92717
		Work #: (714) 856-4105
		FAX #: (714) 856-4056

ACKNOWLEDGEMENTS
	
	Special thanks to Paul Stephenson for devising the recursive 
Makefile scheme that underlies this distribution.
	
-- 
Douglas C. Schmidt
Department of Information and Computer Science
University of California, Irvine
Irvine, CA 92717. Work #: (714) 856-4105; FAX #: (714) 856-4056

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 1993 12:06:44 -0700
From:      schmidt@net1.ics.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI access to TCP/IP

In article <1993Sep2.085759.10171@terminus.ericsson.se>,
Satish Popat <satish@terminus.ericsson.se> wrote:
++ In article L8F@ra.nrl.navy.mil, atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
++ >By the way, Comer's TLI client/server programming is now out.  It is
++ >the recommended reference for folks using or trying to use TLI.
++ 
++ Does anyone know if there are major differences (apart from using TLI in place 
++ of BSD Sockets) in the contents of the book? 

	From a cursory reading of the new text, it appears quite
similar.  In particular, the interesting discussions in chapter 8-15
on server design dimensions look very familiar (as well they should,
since the general principles remain the same for TLI and for sockets).

	Unfortunately, the book doesn't seem to address some of the
subtle, but important aspects of correct TLI programming, such as
writing a concurrent server with a qlen > 1, and the subtle
differences between the T_COTS and T_COTS_ORD service semantics for
closing down a connection gracefully.  

	Perhaps a closer reading of the text will reveal a discussion
of these points, but I didn't see them during my first perusal.

++ Also, are the sources available on some
++ ftp site?

	The sources for the sockets version appear to be available
from ftp.uu.net in the published/books/ subdirectory.  However, the
TLI version doesn't appear to be there yet.

	Doug
-- 
Douglas C. Schmidt
Department of Information and Computer Science
University of California, Irvine
Irvine, CA 92717. Work #: (714) 856-4105; FAX #: (714) 856-4056

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Sep 1993 09:52:37 GMT
From:      albertk@cs.kun.nl (Albert Koppes)
To:        comp.protocols.tcp-ip
Subject:   References on TCP/IP over satellite ?

I am looking for some references on the operation of TCP/IP
over satellite links at speeds of 1 Mbps, probably using PPP or HDLC.
Items we are especially interested in:

- which network management tools are supporting satellite links ?
- any experiences using HDLC window sizes, and hardware supporting
 larger buffer sizes ?

Other references are welcomed. Thanks in advance.



-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Sep 1993 16:57:17 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Can you process a TCP header in 30 instructions?

In article <CCst3G.971@mcdata.com> ddb0248@mcdata.com (David Beal) writes:
>When I took a tutorial from David Clark (MIT) at Interop last year,
>he said that Van Jacobson had written a TCP implementation that
>"processes a typical TCP header in 30 [machine language] instructions".
>
>I'm having a hard time convincing people that this is possible.
>Does anybody know if this is documented anywhere?

I can believe it if this was using header prediction and the packet met
all expectations for incoming header fields.  If the packet has some
unexpected field, then longer code paths come into play.  I'm also
assuming that this is JUST the header processing logic.  The neccessary
buffer handling before and after header processing is extra (but still
not significant).

Art

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Sep 1993 18:47:10 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: Non-blocking connects

hawkeye@glia.biostr.washington.edu (Ken Keys - TF Dude) writes: 

>In <26af90$jvg@shetland.ae.eds.com> cross@shetland.ae.eds.com (Jason Cross) writes:
>
>>Before I go down this path, are there any caveats with using
>>non-blocking connect on a connection-oriented socket?  Also,
>>in the "UNIX Network Programming" book it mentions that a
>>non-blocking connect returns immediately with the errno value
>>set to EINPROGRESS.  What do I check to see if I have a valid
>>connection, and if it's errno what is it set to?
>
>The problem with this method is determining when the connect is
>complete, and whether it was successful.  On some systems, you can tell
>connect() has completed when the socket select()s true for writing, and
>then test it by writing zero bytes to it.  This method is ugly, not
>particularly portable, and provides no way of determining the cause of
>failure if connect() fails.  Another problem is that on some systems,
>select() for writing always returns true.

I don't know if "writing" zero bytes is a good idea.  If I wanted to test
for the connect completion, I would select() for write as you suggested
first.  This is good if you've done all the other stuff you want to do and
are ready to block until the completion of the connection.  If you just want
to poll, you do another connect on the same file desrcriptor and you should
either get an EINPROGRESS if it's still working on it, an EALREADY (I
believe - someone correct me if I'm wrong) if it's completely sucessfullly,
or the appropriate error code if there was a problem.

There now, that wasn't so ugly, was it?

By the way, I don't know about select() returning true or false.  I don't
think you *SHOULD* be testing the return value from select().  What's really
useful is to test the bits corresponding to the file descriptor(s) you
provided and determine which one(s) are still set.  These correspond to the
operations which are ready/available.

Fred

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Sep 1993 20:04:45 +0000
From:      ian@g3nrw.demon.co.uk (Ian Wade)
To:        comp.protocols.tcp-ip
Subject:   KA9Q NOSintro/NOSview: Author has new e-mail address



========================
CHANGE OF E-MAIL ADDRESS
========================

Please note that I recently changed my e-mail address to:

      * * * * * * * * * * * * * * *
      *                           *
      *  ian @ g3nrw.demon.co.uk  *
      *                           *
      * * * * * * * * * * * * * * *

(and no longer use the dircon.co.uk address).

If you recently sent mail to me at dircon and didn't get a
reply, my apologies. 

And if you need any information on the "NOSview" documentation
package for KA9Q TCP/IP, or on the "NOSintro" book describing
how to set up KA9Q NOS, please e-mail me at the new address.

Ditto if you have any input for me for "PACKET INTERNATIONAL"

73
Ian Wade, G3NRW

 +===============================+========================================+
 | Ian Wade                      | E-mail:  ian@g3nrw.demon.co.uk         |
 | DOWERMAIN LTD                 |                       [158.152.16.226] |
 | 7 Daubeney Close, Harlington, | AX.25:   G3NRW @ GB7BIL.#27.GBR.EU     |
 | Dunstable, Beds LU5 6NF, UK   | AMPRnet: g3nrw.ampr.org [44.131.5.147] |
 +===============================+========================================+




-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      06 Sep 93 19:12:19
From:      dac@ukc.ac.uk (D.A.Clear)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: Non-blocking connects

In article <hawkeye.747179085@glia> hawkeye@glia.biostr.washington.edu (Ken Keys - TF Dude) writes:
>In <26af90$jvg@shetland.ae.eds.com> cross@shetland.ae.eds.com (Jason Cross) writes:
>>Before I go down this path, are there any caveats with using
>>non-blocking connect on a connection-oriented socket?
>
>The problem with this method is determining when the connect is
>complete, and whether it was successful.  On some systems, you can tell
>connect() has completed when the socket select()s true for writing, and
>then test it by writing zero bytes to it.

When the socket has connected (or failed to connect) the socket becomes
available for writing (if you're using select()).  You can then do a
getpeername() on it.  If the connect succeeded then you'll get the
remote address - otherwise it'll fail with errno == ENOTCONN.

>A better and more portable (at least to modern OS's) solution is to use
>a connection server.  This is a seperate process which does a normal
>blocking connect(), and when it's finished passes the new file
>descriptor back to the client through a pipe.

The advantage of using a separate server like this is that it gives you
the ability to pass back more complete error messages.  Using
non-blocking connects as supplied there's no way to discover _why_ a
connect failed - all you get from errno is ENOTCONN (real useful).  As
the connection server will be using the "real" blocking connect() it
will get the real errno (ECONNREFUSED, ETIMEDOUT, ENETUNREAC, etc).

Regards,
Dave.

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Sep 1993 20:45:04 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Can you process a TCP header in 30 instructions?

In article <CCst3G.971@mcdata.com> ddb0248@mcdata.com (David Beal) writes:
}When I took a tutorial from David Clark (MIT) at Interop last year,
}he said that Van Jacobson had written a TCP implementation that
}"processes a typical TCP header in 30 [machine language] instructions".
}
}I'm having a hard time convincing people that this is possible.

  Sure, it's a rather simple thing.  Just check for the expected
  case(s) first:

      if (field == expected_value) ...

  rather than all the extraordinary cases first:

      if (field == anomoly1) ...
      if (field == anomoly2) ...
               :
      if (field == anomolyN) ...
      else {
           /*
            * must be normal...
            */
      }

   Most packets are as expected.
   An excerpt from "netstat -s -p tcp" on my machine shows (of
   a million packets received):

       47%   of packets had an ACK
       47%   of packets updated the rtt value
       29%   of packets updated the window
        0.2%    were connection requests (SYNs)
        0.6% of packets had a not-expected ACK value
        0.3% of packets were complete duplicates
        0.1% of packets were partial duplicates
        0.1% of packets were out-of-order
        0       packets were out-of-window
        0       packets had bad bogus values in the fields
        0       packets failed the checksum
        0       packets were too short
       32       packets were window probes

    These numbers are likely fairly typical.

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

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Sep 1993 21:15:58 GMT
From:      davidc@hubcap.clemson.edu (David S Condrey)
To:        comp.protocols.tcp-ip
Subject:   Terminating RPC servers

This may or may not be the right group for this question. If not,
flame away.

Anyway, I am new to writing RPC code. I have an example working, but
cannot find any spec on terminating a server that has done a call to
svc_run().

I have several books (supposedly good) at my disposal, but none seem
to address this issue. I do not have the Sun documentation though.
 
Is there an elegant way to terminate? Oh, by the way, this server is
running on an MVS system. :-) Even so, any information would be
helpful.

Thanks.
-David

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Sep 1993 03:52:21 GMT
From:      bob@fuzzylog.iphase.com (Bob Friesenhahn)
To:        comp.protocols.tcp-ip
Subject:   Re: Socket to serial interface program?

In article <2156@swuts.sbc.com>, Scott M. Pfeffer <sp9183@swuts.sbc.com> wrote:
>In article <CCJqGI.CvD@iphase.com> bfriesen@iphase.com writes:
>>I am looking for UNIX source code to a program which accepts opens on a
>>specified TCP port and then copies data to/from a specified serial
>>port.  The idea is to allow programs that currently use sockets to
>>instead use a serial port with no code changes to the program.
>>
>>I am interested in either a daemon style server or a program that
>>can be intiated on a per-instance basis.
>>
>>Thanks,
>>
>>Bob
>
>In case you have not already investigated this, you might want to look
>into public domain SLIP (Serial Line IP) or PPP (Point-to-Point Protocol)
>which does handle TCP traffic through serial ports.

Thanks, I already know about SLIP & PPP.  My objective is to interface
a program (newsreader) via a tty connection to a site that does not
support SLIP or PPP.  The only available connection is a terminal
style connection via telnet to the NNTP port.  In principle, I think
this should be possible provided the connection is error free and
flow control works.

I would like to be able to take existing socket-based programs and
hook them to the serial port.

Thanks,

Bob

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Sep 1993 04:05:29 GMT
From:      wayne@netcom.com (wayne t. watson)
To:        comp.protocols.tcp-ip
Subject:   Where is cutcp description?

Where can I find a description of cutcp?  I've looked at a few
archie sites but there seems to be no description of how to operate
cutcp or what it does.
-- 
Wayne T. Watson   wayne@netcom.com (415) 969-4233
Mountain View, CA

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 93 05:09:55 GMT
From:      jim@grimaldi.rutgers.edu (Jim Martin)
To:        comp.protocols.tcp-ip
Subject:   Re: Where is cutcp description?

wayne@netcom.com (wayne t. watson) writes:

>Where can I find a description of cutcp?  I've looked at a few
>archie sites but there seems to be no description of how to operate
>cutcp or what it does.

	CUTCP is a suite of programs that provide basic TCP/IP
functionality for MS-DOS based machines. It primarily consists of a
Telnet client, a IBM 3270 emulator, and a FTP client. These programs,
coupled with a packet driver provides a zero cost solution for
bringing your DOS machines into the TCP/IP world. It's currently being
mantained by Rutgers University (Ie, Me :) and is available via
anonymous FTP from ftp-ns.rutgers.edu:/pub/msdos/cutcp/current. There
is also a discussion list which can be joined by sending mail to
cutcp-l-request@nstn.ns.ca. Hope that was what you were looking for!
							Jim

-- 
	Jim Martin			Internet: jim@noc.rutgers.edu
	Network Services		UUCP: {backbone}!rutgers!jim
	Rutgers University		Phone: (908) 932-3719

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 1993 18:10:59 -0700
From:      schmidt@liege.ics.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TCP and TLI

Hi,

	I just put the finishing touches on a set of C++ wrappers for
TLI available via anonymous ftp from ics.uci.edu in the file
gnu/C++_wrappers.tar.Z.  

	The current implementation of the TLI wrappers utilize
inheritance and C++ class composition to greatly reduce the effort
required to program clients and servers using TLI features.  I've
enclosed a short example from the C++ wrappers distribution release
that illustrates the use of the TLI wrappers for the server-side of a
multi-threaded client/server test driver running on SunOS 5.2:

----------------------------------------
#include "TLI_SAP_Listener.h"

const unsigned short SERVER_PORT = 4899;

void *
read_file (void *fd)
{
  TLI_SAP_Stream stream;
  char		 buf[BUFSIZ];
  int		 flags = 0;
  int		 n;

  stream.set_fd (int (fd));

  ::printf ("start  (tid = %d, fd = %d)\n", thr_self (), stream.get_fd ());
  ::fflush (stdout);

  while ((n = stream.recv (buf, sizeof buf, &flags)) > 0)
    continue;

  ::printf ("finish (tid = %d, fd = %d)\n", thr_self (), stream.get_fd ());

  if (stream.close () == -1)
    t_error ("stream.close error");

  thr_exit ((void *) 0); 
  /* NOTREACHED */
  return 0;
}

int 
main (int argc, char *argv[])
{
  unsigned short   port = argc > 1 ? atoi (argv[1]) : SERVER_PORT;
  TLI_SAP_Listener server;
  TLI_SAP_Stream   new_stream;
  int		   retval;
  thread_t	   clientid;
  
  if (server.open (SAP_INET_Addr (port)) == -1)
    ::t_error ("server.open"), ::exit (1);

  /* Wait for a connection from a client.  
     This is an example of a concurrent server. */

  for (int count = 1; ; count++)
    {
      ::fprintf (stderr, "thread %d, blocking for accept #%d\n", thr_self (), count);
      if (server.accept (new_stream) == -1)
	::t_error ("server.accept error");
      else if ((retval = thr_create (0, 0, read_file, (void *) new_stream.get_fd (),
				     THR_DETACHED | THR_NEW_LWP | THR_BOUND, &clientid)) != 0)
	::fprintf (stderr, "server: can't create worker thread %d\n", retval);
    }
}
----------------------------------------

	Doug
-- 
Douglas C. Schmidt
Department of Information and Computer Science
University of California, Irvine
Irvine, CA 92717. Work #: (714) 856-4105; FAX #: (714) 856-4056

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 1993 08:38:48 GMT
From:      hl@tekla.fi (Harald Lundberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Slow FTP in one direction only!!


In article <747021912snx@crynwr.com>, nelson@crynwr.com (Russell Nelson) writes:
|>In article <1993Sep2.110557.1@vax1.tcd.ie> nafallon@vax1.tcd.ie writes:
|>
|>   I am having severe speed problems when trying to ftp files from my
|>   PC (running    Interactive unix). The transfer rate is fine when
|>   sending/getting files to the machine, but all transfers in the
|>   other direction creep along at about 2k  per minute. (Actually,
|>   when you are logged into the remote machine this happens   . When
|>   running FTP from the PC, it just stalls after sending about 40k).
|>
|>40K, you say?  Hmmm...  40K.  That sounds *very* familiar.  I'll bet
|>you're using a 3c501.  If so, nuke it and get a modern Ethernet card,
|>or else frob the TCP to make its MSS==Window.
|>
I ran into this problem over a slip line. The other end was a decstation,
the other was a xyplex terminal server. ftp stalled at about 10k. I think
the reason was too *big* send-que in the decstation, so that packets
timed-out while still in the que. I never fixed the problem and the line
doesn't exist anymore, so I don't know if this was the reason. But have a
look at the buffersizes (they are in the kernel, require a rebuild).
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_
Harald Lundberg; hl@tekla.fi         _/ _/_/_/ _/  _/  _/        _/ __/ __/ __/
Tekla Oy       tel +358-0-8879449   _/ _/     _/_/    _/       _/_/
Koronakatu 1   fax +358-0-8039489  _/ _/_/   _/_/    _/      _/  _/   __/ __/
SF-02210 ESPOO res +358-0-8026752 _/ _/     _/ _/   _/     _/_/_/_/
FINLAND	       2nd +358-11-728013_/ _/_/_/ _/  _/  _/_/_/_/      _/ __/ __/
				 

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 93 12:36:13 GMT
From:      jordan@IMSI.COM (Jordan Hayes)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: Non-blocking connects

Ken Keys <hawkeye@glia.biostr.washington.edu> writes:

	The problem with this method is determining when the connect is
	complete, and whether it was successful.  On some systems, you
	can tell connect() has completed when the socket select()s true
	for writing, and then test it by writing zero bytes to it.

When select() returns for writing, call connect() again.  If it worked,
you'll get -1 and errno == EISCONN; if it didn't work, you'll get errno
== EINVAL you should call getsockopt(fd, SOL_SOCKET, SO_ERROR, ...) to
retrieve the reason it failed.

/jordan

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      07 Sep 93 15:06:45
From:      dac@ukc.ac.uk (D.A.Clear)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: Non-blocking connects

In article <321@rook.ukc.ac.uk> dac@ukc.ac.uk I wrote:
>Using non-blocking connects as supplied there's no way to discover _why_ a
>connect failed - all you get from errno is ENOTCONN (real useful).

In article <8874@bacon.IMSI.COM> jordan@IMSI.COM (Jordan Hayes) writes:
>...if it didn't work you should call getsockopt(fd, SOL_SOCKET, SO_ERROR, ...)
>to retrieve the reason it failed.

Of course (bangs head against wall)...

Regards,
Dave.

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 93 19:14:55 GMT
From:      hawkeye@glia.biostr.washington.edu (Ken Keys - TF Dude)
To:        comp.protocols.tcp-ip
Subject:   Re: Non-blocking connects

In <8874@bacon.IMSI.COM> jordan@IMSI.COM (Jordan Hayes) writes:

>When select() returns for writing, call connect() again.  If it worked,
>you'll get -1 and errno == EISCONN; if it didn't work, you'll get errno
>== EINVAL you should call getsockopt(fd, SOL_SOCKET, SO_ERROR, ...) to
>retrieve the reason it failed.

The man pages I've checked (IRIX 4.0.5H, IRIX 4.0.1, SunOS 4.1.1) say
nothing about returning EINVAL in errno for a second connect() on a
socket which previously failed to connect().  In fact, the only thing
they say about a second connect() is:

     Generally, stream sockets may successfully connect() only once;
     datagram sockets may use connect() multiple times to  change
     their  association.

I hope you're right, because that looks like a good method.  But I
can't find anything about detecting a failed (first) connect().

-- 

Ken "Hawkeye" Keys
hawkeye@glia.biostr.washington.edu

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Sep 1993 19:39:31 GMT
From:      gilmore@venice.sedd.trw.com (Larry Gilmore)
To:        comp.protocols.tcp-ip
Subject:   FTS2000?

A collegue just asked me about a protocol called FTS2000.  I'd never
heard of it.  Can someone clue us in?  Pretty-please?
Any info gratefully accepted-- TIA!
Larry

-- 
Larry A. Gilmore             Internet: gilmore@venice.sedd.trw.com
TRW SEDD, DH5/2453
P.O. Box 6213                Phone:    (310)764-9163
Carson, CA 90746             Fax:      (310)764-3946

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Sep 1993 19:45:08 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Socket to serial interface program?

In article <2156@swuts.sbc.com> sp9183@swuts.sbc.com (Scott M. Pfeffer) writes:
   ...you might want to look into public domain SLIP (Serial Line IP)
   or PPP (Point-to-Point Protocol) which does handle TCP traffic
   through serial ports.

   If you have a Sun, you might benefit by contacting Purdue
   university, which has implemented "DialupPPP", a public domain PPP
   for Suns.

Careful!  I know of no SLIP or PPP implementation that's in the public
domain.  Many are freely available, but all are copyrighted by their
respective authors.  Purdue's popular DP (Dial-up PPP for Suns) is
based on earlier work by Drew Perkins, Brad Clements, Karl Fox, Greg
Christie, and others.  Drew and Brad not only assert copyright, but
impose various restrictions on the use of their code.

The distinction between "freely available" and "public domain" may
appear to be nit-picking, but the difference may jump up and bite you
someday if you do the wrong things and don't worry about it enough.
--
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)

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 1993 20:38:19 GMT
From:      whalenm@obelix.tsg.com (Matthew Whalen)
To:        comp.protocols.tcp-ip
Subject:   Re: FTS2000?

Larry Gilmore (gilmore@venice.sedd.trw.com) wrote:
: A collegue just asked me about a protocol called FTS2000.  I'd never
: heard of it.  Can someone clue us in?  Pretty-please?
: Any info gratefully accepted-- TIA!
: Larry

Was he referring to the Federal Goverment's phone system (I think that
it stands for Federal Telephone System 2000)?

--
-matthew           ____ 	Due to the change in administration,
whalenm@tsg.com    \  /		the light at the end of the tunnel    
(NeXTMail OK)       \/		will be turned back on.
----------------------------------------------------------------
(My actions/words in no way reflect those of my employer.)

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Sep 1993 20:53:35 GMT
From:      mvm@cbnewsb.cb.att.com (michael.v.murphy)
To:        comp.protocols.tcp-ip
Subject:   Sockets conversion

    We currently have an applications written in TLI that sends messages to
disributed machines via TCP. For several reasons, one of the sides needs to
be re-written in SOCKETS (and we want to retain the TLI code on the other side)
Is there any reason that a connections can't be initiated and maintained
with one side talking sockets and the other TLI? From what I have read to
this point, it seems feasable (although I have not seen any examples of it).
Any net wisdom on this proposed change would be greatly appreciated. 

						Many Thanks...

						Mike Murphy
						mvmurphy@attmail.att.com

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Sep 1993 21:13:27 GMT
From:      ayr@node_man.uucp (Aleksey Y. Romanov)
To:        comp.protocols.tcp-ip
Subject:   SLIP or PPP for Unixware


I am looking for commercial or PD SLIP/PPP implementation which
will work with UnixWare.

Aleksey


Reply to ayr@gtech.com. I am affraid that my posting host
will mangle my address


-- 
Aleksey Y. Romanov

DISCLAIMER: The views expressed are entirely my own and do not
necessary reflect those of my employer or anyone else

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 1993 10:01:08 -0700
From:      schmidt@net1.ics.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip
Subject:   Re: Non-blocking connects

Hi,

	Just out of curiosity, can someone please explain the types of
applications that benefit from the ability to perform non-blocking
connects?  This seems like a feature that would only be use if

	1. You were starting up many connections "simultaneously"
	   and didn't want to serialize the handshaking at the
	   application level

	2. You didn't have multiple threads and wanted to do
	   something while waiting for the connection handshake to
	   complete

	3. You were running over an extremely long latency link
	   where the 3-way packet exchange took a substantial
	   amount of time

Are there any other types of applications that benefit from this
non-block approach?

	Thanks,
	
		Doug
-- 
Douglas C. Schmidt
Department of Information and Computer Science
University of California, Irvine
Irvine, CA 92717. Work #: (714) 856-4105; FAX #: (714) 856-4056

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Sep 1993 00:38:57 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: Non-blocking connects

robert@gar.no (Robert Andersson) writes: 

>In <8874@bacon.IMSI.COM> jordan@IMSI.COM (Jordan Hayes) writes:
>>When select() returns for writing, call connect() again.  If it worked,
>>you'll get -1 and errno == EISCONN; if it didn't work, you'll get errno
>>== EINVAL you should call getsockopt(fd, SOL_SOCKET, SO_ERROR, ...) to
>>retrieve the reason it failed.
>
>I have found that the method below is better.  We do it this way in a
>product that runs on some 10-15 different Unix versions without trouble.
>
>a) After the asynch connect(), do a select() both for reading *and*
>   writing.
>b) Check the read fd_set first, if it's set, do a read() on the socket.
>   The read() will fail and errno will tell why the connect() failed.

What if the connect did succeed and data has been received on the
connection.  Won't the read() consume data?  You might not necessarily
want to consume any of your buffered data just to check if the connect
succeded.

Fred

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Sep 1993 01:29:07 GMT
From:      my2m@Virginia.EDU (Michael J. Yelland)
To:        comp.protocols.tcp-ip
Subject:   Netware RIP/SAP Tables for 2.x

Has anyone been hit by the 2.x SAP/RIP table limits ?
We are almost at the <64K table/segment size limits
due to large IPX net and am getting ready to
experiment with this problem. Anyone done this
already ?  Anyone interested in results ?

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 1993 00:21:44 +0200
From:      robert@gar.no (Robert Andersson)
To:        comp.protocols.tcp-ip
Subject:   Re: Non-blocking connects

In <8874@bacon.IMSI.COM> jordan@IMSI.COM (Jordan Hayes) writes:

>Ken Keys <hawkeye@glia.biostr.washington.edu> writes:
 
>	The problem with this method is determining when the connect is
>	complete, and whether it was successful.  On some systems, you
>	can tell connect() has completed when the socket select()s true
>	for writing, and then test it by writing zero bytes to it.
 
>When select() returns for writing, call connect() again.  If it worked,
>you'll get -1 and errno == EISCONN; if it didn't work, you'll get errno
>== EINVAL you should call getsockopt(fd, SOL_SOCKET, SO_ERROR, ...) to
>retrieve the reason it failed.

I have found that the method below is better.  We do it this way in a
product that runs on some 10-15 different Unix versions without trouble.

a) After the asynch connect(), do a select() both for reading *and*
   writing.
b) Check the read fd_set first, if it's set, do a read() on the socket.
   The read() will fail and errno will tell why the connect() failed.
c) Then check the write fd_set, if it's set the connect() succeeded.

Oh, and remember that on some systems the asynch connect() will in fact
return success, not -1 and errno=EINPROGRESS.  So remember to test the
return value from connect() too.

I'm home now so I don't have the W.R.Stevens book handy, but I think this
is also the way he recommends this done.

Regards, Robert.
-- 
Robert Andersson    Voice +47 22418551     Gallagher & Robertson A/S
robert@gar.no       Fax   +47 22428922     Kongensgt. 23, 0153 Oslo, Norway

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 1993 06:00:59 GMT
From:      micah@stein3.u.washington.edu (Micah Anderson)
To:        comp.protocols.tcp-ip
Subject:   Help! Small network how to?

	Ok, me and a few of my friends all run a BSD 4.3 variant on
our own machines at home, we are curious as to the process of netting
each other up would be. Essentially something quite small, so that
mail could be sent between us, perhaps more (ftp,telnet?)... We all
have in our pocessions 14.4 modems and no idea where to begin. I have
been pouring over man pages for a few hours to find not much help as
to where to start... So if someone has a FAQ on this, or some good
tips as to where to try to post instead or where to start, I would
love it!

Thanks!

Micah


-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Sep 1993 06:15:34 GMT
From:      karn@unix.ka9q.ampr.org.qualcomm.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP over asymmetrical link

In article <1993Sep5.072531.9606@advtech.uswest.com>, crohrer@advtech.uswest.com ( Chris Rohrer) writes:
|> How dependent is TCP on there being some semblance of symmetry
|> in what it works over?

TCP works just fine over assymetric links. You do run into an unusual
bottleneck, though. When you FTP a file down over the cable (a common
operation) your forward link throughput is often limited by the
bandwidth of the reverse channel (the dialup modem). Big data packets
on the forward link and VJ header compression on the reverse link
helps a lot here, as do TCPs that ack only every other packet.

Phil

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Sep 1993 10:23:19 GMT
From:      vakis@ntua.gr (Iakvbos Karakas)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   WfWg and PC/TCP

Hello all,

I have the following problem and I need your help to solve it.

On a 486 pc I have installed :
	WfWg with the beta version of MS-TCP/IP
	PC/TCP ver. 2.2

The problem is that when the PC/TCP is active WfWg are runing 
only as windows without any networking. Reading the manual of
PC/TCP i discover a section about WfWg operation and also an
additional patch (the readme file of the PC/TCP) which instructs
one how to install WfWg and PC/TCP using the NDIS drivers.
I may say that my try to install them together following the 
instructions of the manual was unsuccessful.

Does anyone of you have already tried that or another way
to make them work together ?

Please email any comments or suggestions to :
	vakis@marina.naval.ntua.gr
	ikar@leon.nrcps.ariadne-t.gr

Thanks in advance

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 93 10:40:54 GMT
From:      jordan@IMSI.COM (Jordan Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: Non-blocking connects

Ken Keys <hawkeye@glia.biostr.washington.edu> writes:

	The man pages I've checked (IRIX 4.0.5H, IRIX 4.0.1, SunOS
	4.1.1) say nothing about returning EINVAL in errno for a second
	connect() on a socket which previously failed to connect().  In
	fact, the only thing they say about a second connect() is:

Well, for EISCONN, it says "the socket is already connected" which
would imply that we've called connect() again ... also for EALREADY it
says that "The socket is non-blocking and a  previous connection
attempt has not yet been completed." ...

Anyway, you can call getpeername() or anything else that can tell the
difference between a valid socket descriptor and a partially-torn-down
one.  Since connect() has a bunch of quick checks at the beginning
(like if we're already connected or if the socket descriptor is
invalid), it's the one I use most often.

/jordan

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 93 10:45:30 GMT
From:      jordan@IMSI.COM (Jordan Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: Non-blocking connects

Robert Andersson <robert@gar.no> writes:

	After the asynch connect(), do a select() both for reading *and*
	writing.

Which systems did you find that will return for reading?  That's
certainly not documented anywhere I know of ...

	Then check the write fd_set, if it's set the connect() succeeded.

No; if select() returns for writing, it means the connect "completed"
-- it still may have failed (ETIMEDOUT for instance) ...

	Oh, and remember that on some systems the asynch connect() will
	in fact return success, not -1 and errno=EINPROGRESS.

Of course; in practice, I've only seen it happen when the remote
machine is the loopback address (in which case the connect() completes
immediately).

/jordan

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 1993 18:46:58 -0400
From:      Mike O'Connor <mjo@msen.com>
To:        comp.sys.sun.misc,comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   How to start in.telnetd on a different port?  (SunOS 4.1.3)

I'd like to start in.telnetd on a different, preferably unprivileged,
port.  I tried, as an experiment, adding this to /etc/services:

telnetest         22223/tcp

and to /etc/inetd.conf:

telnetest  stream  tcp     nowait  root    /usr/etc/in.telnetd in.telnetd

then restarting inetd and trying to connect to port 22223, then try to
connect to port 22223 of the machine locally.  "Connection refused".
Doing the above works on DEC Ultrix and HP-UX.  I am running SunOS
4.1.3, with just enough YP to make DNS function.  Please send email,
so I can more easily post a summary.  

-- 
 Mike O'Connor
 <mjo@msen.com>

"The living dead don't NEED to solve word problems."  -Calvin

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 1993 13:45:49 GMT
From:      fgs@kepler.unh.edu ( F r e D  S l a m A )
To:        comp.protocols.tcp-ip
Subject:   non-blocking connect()


	I have posted this on comp.unix.wizards and have received sporatic,
	but helpful responses. I will try here just to be sure I have covered
	all the bases.

	As it stands now, I am obtaining a socket, marking its file descriptor
	as non-blocking, and calling connect().

	It is at this point I need to wait. The "wait" is actually a call to
	a custom threads scheduler, but is irrelevant to the problem at hand.

	When I return, I need some way of knowing that state of the connect()
	attempt. Using select() will indicate that something has happened, but
	WHAT has happened is unknown. I use getpeername() as a
	verification that a connection has succeeded or failed. If it
	failed, I need to know why.

	As a side note, I noted that select() sets the fd's bit in the readfds bit
	set to indicate an error has occured. the bit in the writefds is
	always set when an event occurs using connect().

	This whole thing is a bit out of the ordinary. There is not much
	documentation on connect()'s non-blocking behavior. I would GREATLY
	appreciate any more input.

						Thank you,
								Fred

-- 
 ===============================================================================
 Frederick G. Slama at >>>>>>>>>>>>>| slama@ctron.com
 The University of New Hampshire <<<| fgs@kepler.unh.edu   F_SLAMA@unhh.unh.edu
 ===============================================================================

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 93 13:47:55 GMT
From:      bp3434@swuts.sbc.com (Blair Porter)
To:        comp.protocols.tcp-ip
Subject:   DNS on Pyramid dual universe

I have set up DNS on several UNIX platforms, using the /etc/resolv.conf
to establish a resolving only environment.  I have setup this file on a
Pyramid system, but am unable to get anything to work.  When I run the
/usr/etc/nslookup program, it tells me it is using address 0.0.0.0, but
I know that /etc/resolv.conf has valid nameserver entries.  What gives?
There must be some subtle little thing, specific to the Pyramid, that I
am missing.  Sorry I don't have access to any documentation, so I am
left with trial & error to figure this thing out.  Anyone out there set
this up on Pyramid?  Any assistance would be greatly appreciated.

================================================================================
  Blair Porter - Systems Analyst		One Bell Center  23-L-1
  System Support Division			St. Louis, MO  63101
  Information Services				Work: (314) 235-3419
  Southwestern Bell Telephone Company		FAX:  (314) 235-1397
  E-mail: BP3434@swrunr.sbc.com
	THE RACE GOES TO THOSE WHO KEEP ON RUNNING...

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

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 1993 20:35:17 -0400
From:      Mike O'Connor <mjo@msen.com>
To:        comp.sys.sun.admin,comp.sys.sun.misc,comp.protocols.tcp-ip
Subject:   Re: How to start in.telnetd on a different port?  (SunOS 4.1.3)

In article <26lnd2$m13@garnet.msen.com> Mike O'Connor <mjo@msen.com> writes:
:I'd like to start in.telnetd on a different, preferably unprivileged,
:port.  I tried, as an experiment, adding this to /etc/services:
:
:telnetest         22223/tcp
:
:and to /etc/inetd.conf:
:
:telnetest  stream  tcp     nowait  root    /usr/etc/in.telnetd in.telnetd
:
:then restarting inetd and trying to connect to port 22223, then try to
:connect to port 22223 of the machine locally.  "Connection refused".
:Doing the above works on DEC Ultrix and HP-UX.  I am running SunOS
:4.1.3, with just enough YP to make DNS function.  Please send email,
:so I can more easily post a summary.  

Man, I love the Internet.  6 responses in minutes!  Figured out the
problem: YP overrides /etc/services with its own list.  Hadda do a
make in /var/yp and keep on reminding myself that not every Sun I use
has DNS sans NIS.  Thanks to the hordes who responded!

-- 
 Mike O'Connor
 <mjo@msen.com>

"You can't fight in here!  This is the War Room!"  -Dr. Strangelove

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 1993 21:05:24 -0400
From:      mju@mudos.pc.cc.cmu.edu (Marc Unangst)
To:        comp.protocols.tcp-ip
Subject:   Re: Excessive Fragmentation (SLIP)

sterling@netcom.com (Bruce Sterling Woodcock) writes:
>One of the things I've run across is EXCESSIVE ip fragmentation.
>netstat -s will typically report 100,000 total packets received, but
>50 - 80 thousand fragments received.  [...]  Mtu for sl0 is 1006,
>which seems consistent with the other slip interfaces I

Remember that MTU is Maximum *Transmission* Unit; i.e., the largest
frame that your end will send.  The size of the frames you receive
from the other end is determined by their MTU setting, which need not
be the same as yours.  I would talk to whoever runs the other end of
your SLIP link, and find out what MTU value they are using.  It's very
possible that they are using 296 or something similar, such that you
never receive large frames, even though your MTU is set fairly high.

-- 
Marc Unangst, N8VRH         | "Free software is NOT the same thing as
mju@mudos.pc.cc.cmu.edu     |  free beer."
                            |     -Philip Knapp in comp.os.linux

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 1993 12:12:36 +0200
From:      robert@gar.no (Robert Andersson)
To:        comp.protocols.tcp-ip
Subject:   Re: Non-blocking connects

In <fred_sCD0F4y.CIy@netcom.com> fred_s@netcom.com (Frederick Scott) writes:

>robert@gar.no (Robert Andersson) writes: 
 
>>I have found that the method below is better.  We do it this way in a
>>product that runs on some 10-15 different Unix versions without trouble.
>>
>>a) After the asynch connect(), do a select() both for reading *and*
>>   writing.
>>b) Check the read fd_set first, if it's set, do a read() on the socket.
>>   The read() will fail and errno will tell why the connect() failed.
 
>What if the connect did succeed and data has been received on the
>connection.  Won't the read() consume data?  You might not necessarily
>want to consume any of your buffered data just to check if the connect
>succeded.

It appears this isn't a problem.  Like I wrote, we do it this way and it
works fine on 10-15 different Unix implementations.
The select() returns immediately after the connect() succeeds or fails.
If it succeeds only the write fd_set bit is set, not the read fd_set bit.
This makes a lot of sense, as no data has been received yet at this stage.

Maybe someone working in the sockets group of Posix.12 can shed some light
on all of this?

Regards, Robert.
-- 
Robert Andersson    Voice +47 22418551     Gallagher & Robertson A/S
robert@gar.no       Fax   +47 22428922     Kongensgt. 23, 0153 Oslo, Norway

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Sep 1993 15:54:14 GMT
From:      a722756@pan.mc.ti.com (W. Donald Rolph III)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: WfWg and PC/TCP

In article <vakis.747483799@theseas> vakis@ntua.gr (Iakvbos Karakas) writes:
>From: vakis@ntua.gr (Iakvbos Karakas)
>Subject: WfWg and PC/TCP
>Keywords: WfWg PC/TCP
>Date: Wed, 8 Sep 1993 10:23:19 GMT
 
>Hello all,
 
>I have the following problem and I need your help to solve it.
 
>On a 486 pc I have installed :
>        WfWg with the beta version of MS-TCP/IP
>        PC/TCP ver. 2.2
 
>The problem is that when the PC/TCP is active WfWg are runing 
>only as windows without any networking. Reading the manual of
>PC/TCP i discover a section about WfWg operation and also an
>additional patch (the readme file of the PC/TCP) which instructs
>one how to install WfWg and PC/TCP using the NDIS drivers.
>I may say that my try to install them together following the 
>instructions of the manual was unsuccessful.
 
>Does anyone of you have already tried that or another way
>to make them work together ?
 
>Please email any comments or suggestions to :
>        vakis@marina.naval.ntua.gr
>        ikar@leon.nrcps.ariadne-t.gr
 
>Thanks in advance

Why run both versions of TCP/IP.  It would appear to me that there could be 
conflicts on the ethernet drivers.

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Sep 1993 16:44:17 GMT
From:      Dean.Roth <Dean.Roth@mixcom.mixcom.com>
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Annex-3 terminal server feedback wanted


My employer is considering installing an Annex-3 terminal server to handle
dial-in and dial-out modem needs.

I'm interested in your experience with the Annex-3 handling 32 to 64 modems.
How is performance affected with 32 to 64 14.4K modems running at 14.4?
Thank you.

Dean
-- 
  /`-_                                 
 {     }/  Dean.Roth@MIXcom.com         
  \   */   Milwaukee, Wisconsin, U.S.A. 
   |___|                                

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Sep 1993 17:49:22 GMT
From:      kozowski@tessi.com (Eric Kozowski)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   help wanted with network problem

I am the system admin for a class C ethernet network.  I am running into
severe overloading of the ethernet.  I am looking for any net.wisdom
on how to fix the ethernet overloading.  Here are the stats:

- A Sun 670 and a Sun 690 are doing the routing (multiple NIC's).
- There are 5 ethernet subnets with less than 25 hosts per subnet.
- 1 FDDI Subnet with 2 hosts, the 670 and the 690.
- Subnet 1, 2, 3 and 4 are off of the 670.
- Subnet 5 is off of the 690.
- TCP/IP is the only protocol stack involved.
- All wiring is thinnet, except the FDDI ring :-)
- All hosts are Sun's.
- FDDI ring between 670 and 690.
- All stats gathered by a Network General Sniffer.
- Subnet 1 has very little traffic.
- Subnet 2 has high percentage of diskless workstations.  Most diskless
  workstations NFS mount everything they need from the 670 and 690.
  Banwith usage peaked at 62%.  Most traffic is to/from the 670 and 690.
- Subnet 3 is very similar to subnet 2.  Peak bandwith usage was 65%.
- Subnet 4 is the deveplopent group's subnet.  Mostly SS10's with internal
  disks.  Peak bandwidth usage was 95%.  Lan overloads of upto 8 seconds
  have occoured.  Main server for this group is a SS10 on the subnet.  Some
  access to the 670 and 690.
- Subnet 5 has very little traffic - mostly Sun 3/60's as Xterminals.
- NFS is the biggest network hog.  Lots of NFS mounts everywhere, though
  most are kept within the same subnet or out to the FDDI ring.  There are
  very few NFS mounts that cross ethernet subnets.

I really need to take care of the network overload, and I have a couple of
ideas, but I am looking for any reasonable input.  I plan on cutting back 
on the NFS mounts.  Is there anything else that would help?  TIA.

-- 
Eric Kozowski                       Systems Administrator
                                    Test Systems Strategies, Inc.
kozowski@tessi.com                  503/643-9281

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Sep 1993 18:09:44 GMT
From:      sterling@netcom.com (Bruce Sterling Woodcock)
To:        comp.protocols.tcp-ip,comp.unix.sys5.r4,comp.unix.pc-clone.32bit
Subject:   Excessive Fragmentation (SLIP)

We are using SLIP over a Supra Faxmodem at 14.4K.  The SLIP package is the one
that came with Dell Issue 2.2 of SVR4.0.  We're been using it for a year now,
but performance has just not been as great as we expected, and I'm currently
looking at possible reasons.

One of the things I've run across is EXCESSIVE ip fragmentation.  netstat -s
will typically report 100,000 total packets received, but 50 - 80 thousand
fragments received.  This seems way too much, and probably is a big part of
the performance problem.  Is this normal for SLIP or is something very wrong?
Mtu for sl0 is 1006, which seems consistent with the other slip interfaces I
have seen.  Has anyone else ever encountered excessive fragmentation before
with SLIP?   What about modem compression/error corretion and it's effect on
these statistics?  ifconfig says:

sl0: flags=f1<UP,POINTOPOINT,NOTRAILERS,RUNNING,NOARP>
	inet 192.160.122.1 --> 192.156.196.253 netmask fffffff0 

Any help would be appreciated.

Bruce

-- 
Bruce Sterling Woodcock                 Internet:  sterling@oldcolo.com
Systems Programmer                      Alternate:  sterling@netcom.com
Old Colorado City Communications        "Global Access From Any Micro"

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 1993 18:32:36 GMT
From:      amolitor@moink.NMSU.edu (Andrew)
To:        comp.protocols.tcp-ip
Subject:   Re: Non-blocking connects

In article <26l34k$3ul@net1.ics.uci.edu>, schmidt@net1.ics.uci.edu (Douglas C. Schmidt) writes:
> Hi,
> 
> 	Just out of curiosity, can someone please explain the types of
> applications that benefit from the ability to perform non-blocking
> connects?  This seems like a feature that would only be use if
>  [...]
> Are there any other types of applications that benefit from this
> non-block approach?
> 

	I used 'em in a single threaded server that was willing to spend a
couple seconds to set up a connection, but not willing to be subject to
the full worst-case connect() timeout. Non-blocking connect, followed
by a select() with a short-ish timeout, followed by write-zero-bytes
voodoo to see if it actually worked. I suspect this usage is somewhat
common.

	Andrew

> 		Doug

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Sep 1993 18:41:31 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: Non-blocking connects

robert@gar.no (Robert Andersson) writes: 

>In <fred_sCD0F4y.CIy@netcom.com> fred_s@netcom.com (Frederick Scott) writes:
>
>>robert@gar.no (Robert Andersson) writes: 
 
>>>I have found that the method below is better.  We do it this way in a
>>>product that runs on some 10-15 different Unix versions without trouble.
>>>
>>>a) After the asynch connect(), do a select() both for reading *and*
>>>   writing.
>>>b) Check the read fd_set first, if it's set, do a read() on the socket.
>>>   The read() will fail and errno will tell why the connect() failed.
 
>>What if the connect did succeed and data has been received on the
>>connection.  Won't the read() consume data?  You might not necessarily
>>want to consume any of your buffered data just to check if the connect
>>succeded.
>
>It appears this isn't a problem.  Like I wrote, we do it this way and it
>works fine on 10-15 different Unix implementations.

Yes, but the question is, WHY does it work?  Because it's portable or
because your applications simply don't involve the passive end of the
connection sending any data right away?  You should understand exactly
what your technique is doing before you recommend it to others.  If their
application's passive side sends data right after completing its accept,
it may be received and consumed in the initial read you're recommending
and then they'll wonder what happened to it when then need it.

>The select() returns immediately after the connect() succeeds or fails.
>If it succeeds only the write fd_set bit is set, not the read fd_set bit.
>This makes a lot of sense, as no data has been received yet at this stage.

I wouldn't assume that if I were you.  A loaded system which has swapped
your application out for a couple seconds may well receive data between the
time the connection completes and when the application is swapped back in,
allowing the select to complete.  Perhaps your applications simply have
never been run under such conditions.

Fred

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 93 20:29:01 GMT
From:      fedfile@fedfil.UUCP (Federal Filings)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans,comp.windows.misc
Subject:   TCP/IP stack - memory usage


Hello,

We are using FTP software Inc.'s PC/TCP dev kit for developing a client-server
Windows application in TCP/IP environment. 

Recently I heard that Frontier Tech has some thing called Super TCP, which
takes only 6k of conventional memory, whereas PC/TCP takes about 70k.

When I checked with  FTP software they said, applications written with
PC/TCP API does not work with any other TCP/IP stack but FTP's PC/TCP.
Why is it so?

If anyone has used Super TCP please let me know about their coment on it.

Thanks in advance,

Suma.

suma@fedfil.com



-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Sep 1993 20:39:01 GMT
From:      visser@convex.com (Lance Visser)
To:        comp.protocols.tcp-ip
Subject:   Re: Can you process a TCP header in 30 instructions?


In article <CCst3G.971@mcdata.com> ddb0248@mcdata.com (David Beal) writes:
+>When I took a tutorial from David Clark (MIT) at Interop last year,
+>he said that Van Jacobson had written a TCP implementation that
+>"processes a typical TCP header in 30 [machine language] instructions".
+>
+>I'm having a hard time convincing people that this is possible.
+>Does anybody know if this is documented anywhere?

	I think that it should be stated that Van Jacobson has CLAIMED 
to have written such an implementation.  If it does exist, few if any
people have really seen what it really is.

	Its very possible to cut tcp processing down to a very small 
number of LOC for the common cases, but if you are not careful you
could also create an even more confusing and difficult to maintain
mess than BSD 4.3.

	However, everyone also should understand that most of the performance
problems of tcp are related to memory movements and have very little
to do with protocol overhead.





-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Sep 1993 21:32:39 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Jacobson on TCP in 30 instructions

The 30 instruction posting led to an exchange of notes between some folks
which led to Van sending this note (which he's kindly agreed to let me
repost).

Craig
craig@bbn.com


To: Craig Partridge <craig@aland.bbn.com>
Cc: <deleted>
Subject: Re: query about TCP header on tcp-ip 
In-Reply-To: Your message of Tue, 07 Sep 93 09:48:00 PDT.
Date: Tue, 07 Sep 93 22:30:14 PDT
From: Van Jacobson <van@ee.lbl.gov>

Craig,

As you probably remember from the "High Speed TCP" CNRI meeting,
my kernel looks nothing at all like any version of BSD.  Mbufs
no longer exist, for example, and `netipl' and all the protocol
processing that used to be done at netipl interrupt level are
gone.  TCP receive packet processing in the new kernel really is
about 30 instructions on a RISC (33 on a sparc but three of
those are compiler braindamage).  Attached is the C code & the
associated sparc assembler.

A brief recap of the architecture:  Packets go in 'pbufs' which
are, in general, the property of a particular device.  There is
exactly one, contiguous, packet per pbuf (none of that mbuf
chain stupidity).  On the packet input interrupt, the device
driver upcalls through the protocol stack (no more of that queue
packet on the netipl software interrupt bs).  The upcalls
percolate up the stack until the packet is completely serviced
(e.g., NFS requests that can be satisfied from in-memory data &
data structures) or they reach a routine that knows the rest of
the processing must be done in some process's context in which
case the packet is laid on some appropriate queue and the
process is unblocked.  In the case of TCP, the upcalls almost
always go two levels: IP finds the datagram is for this host &
it upcalls a TCP demuxer which hashes the ports + SYN to find a
PCB, lays the packet on the tail of the PCB's queue and wakes up
any process sleeping on the PCB.  The IP processing is about 25
instructions & the demuxer is about 10.

As Dave noted, the two processing paths that need the most
tuning are the data packet send & receive (since at most every
other packet is acked, there will be at least twice as many data
packets as ack packets).  In the new system, the receiving
process calls 'tcp_usrrecv' (the protocol specific part of the
'recv' syscall) or is already blocked there waiting for new
data.  So the following code is embedded in a loop at the start of
tcp_usrrecv that spins taking packets off the pcb queue until
there's no room for the next packet in the user buffer or the
queue is empty.  The TCP protocol processing is done as we
remove packets from the queue & copy their data to user space
(and since we're in process context, it's possible to do a
checksum-and-copy).

Throughout this code, 'tp' points to the pcb and 'ti' points to
the tcp header of the first packet on the queue (the ip header was
stripped as part of interrupt level ip processing).  The header info
(excluding the ports which are implicit in the pcb) are sucked out
of the packet into registers [this is to minimize cache thrashing and
possibly to take advantage of 64 bit or longer loads].  Then the
header checksum is computed (tp->ph_sum is the precomputed pseudo-header
checksum + src & dst ports).

int tcp_usrrecv(struct uio* uio, struct socket* so)
{
	struct tcpcb *tp = (struct tcpcb *)so->so_pcb;
	register struct pbuf* pb;

	while ((pb = tp->tp_inq) != 0) {
		register int len = pb->len;
		struct tcphdr *ti = (struct tcphdr *)pb->dat;

		u_long seq = ((u_long*)ti)[1];
		u_long ack = ((u_long*)ti)[2];
		u_long flg = ((u_long*)ti)[3];
		u_long sum = ((u_long*)ti)[4];
		u_long cksum = tp->ph_sum;

		/* NB - ocadd is an inline gcc assembler function */
		cksum = ocadd(ocadd(ocadd(ocadd(cksum, seq), ack), flg), sum);

Next is the header prediction check which is probably the most
opaque part of the code.  tp->pred_flags contains snd_wnd (the
window we expect in incoming packets) in the bottom 16 bits and
0x4x10 in the top 16 bits.  The 'x' is normally 0 but will be
set non-zero if header prediction shouldn't be done (e.g., if
not in established state, if retransmitting, if hole in seq
space, etc.).  So, the first term of the 'if' checks four
different things simultaneously:
 - that the window is what we expect
 - that there are no tcp options
 - that the packet has ACK set & doesn't have SYN, FIN, RST or URG set
 - that the connection is in the right state
and the 2nd term of the if checks that the packet is in sequence:

#define FMASK (((0xf000 | TH_SYN|TH_FIN|TH_RST|TH_URG|TH_ACK) << 16) | 0xffff)

        if ((flg & FMASK) == tp->pred_flags && seq == tp->rcv_nxt) {

The next few lines are pretty obvious -- we subtract the header
length from the total length and if it's less than zero the packet
was malformed, if it's zero we must have a pure ack packet & we
do the ack stuff otherwise if the ack field didn't move we have
a pure data packet which we copy to the user's buffer, checksumming
as we go, then update the pcb state if everything checks:

                len -= 20;
                if (len <= 0) {
                        if (len < 0) {
                                /* packet malformed */
                        } else {
                                /* do pure ack things */
                        }
                } else if (ack == tp->snd_una) {
                        cksum = in_uiomove((u_char*)ti + 20, len, uio, cksum);
                        if (cksum != 0) {
                                /* packet or user buffer errors */
                        }
                        seq += len;
                        tp->rcv_nxt = seq;
                        if ((int)(seq - tp->rcv_acked) >= 0) {
                                /* send ack */
                        } else {
                                /* free pbuf */
                        }
			continue;
		}
	}
	/* header prediction failed -- take long path */
	...

That's it.  On the normal receive data path we execute 16 lines of
C which turn into 33 instructions on a sparc (it would be 30 if I
could trick gcc into generating double word loads for the header
& my carefully aligned pcb fields).  I think you could get it down
around 25 on a cray or big-endian alpha since the loads, checksum calc
and most of the compares can be done on 64 bit quantities (e.g.,
you can combine the seq & ack tests into one).

Attached is the sparc assembler for the above receive path.  Hope
this explains Dave's '30 instruction' assertion.  Feel free to
forward this to tcp-ip or anyone that might be interested.

 - Van

 ----------------
	ld [%i0+4],%l3			! load packet tcp header fields
	ld [%i0+8],%l4
	ld [%i0+12],%l2
	ld [%i0+16],%l0

	ld [%i1+72],%o0			! compute header checksum
	addcc %l3,%o0,%o3
	addxcc %l4,%o3,%o3
	addxcc %l2,%o3,%o3
	addxcc %l0,%o3,%o3

	sethi %hi(268369920),%o1	! check if hdr. pred possible
	andn %l2,%o1,%o1
	ld [%i1+60],%o2
	cmp %o1,%o2
	bne L1
	ld [%i1+68],%o0
	cmp %l3,%o0
	bne L1
	addcc %i2,-20,%i2
	bne,a L3
	ld [%i1+36],%o0
	  ! packet error or ack processing
	  ...
L3:
	cmp %l4,%o0
	bne L1
	add %i0,20,%o0
	mov %i2,%o1
	call _in_uiomove,0
	mov %i3,%o2
	cmp %o0,0
	be L6
	add %l3,%i2,%l3
	  ! checksum error or user buffer error
	  ...
L6:
	ld [%i1+96],%o0
	subcc %l3,%o0,%g0
	bneg L7
	st %l3,[%i1+68]
	  ! send ack
	  ...
	  br L8
L7:
	  ! free pbuf
	  ...
L8:	! done with this packet - continue
	...

L1:	! hdr pred. failed - do it the hard way

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Sep 1993 22:09:43 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: IP subnetting and RIP

phuong@rocky.raleigh.ibm.com (Phuong Nguyen) writes:

> It's NO NO.  If using RIP router 3 won't be able to talk to router 3 and
> vice versa.

??? Presumably you mean router 3 and router 1, but they can talk fine over
the tokenring subnet.

> According to the RIP RFC, RIP is not capable of advertising
> the subnetted network because it doesn't have a field to cary subnetted mask.

That's OK, the systems that receive the RIP will assume a netmask that's
the same as the one on an interface they've got on a 198.178.216 subnet.
(If different systems have different netmasks for that net, then you're in
trouble, but that's usually true in any case.)

There are uncountable people (including us) who are RIPing class B subnet
information around their net.  It works fine - and there's no reason a
subnetted class C should be any different.

> To solve this problem you have to use OSPF if you want to use subnetted
> network.
> *********************************
> Opinions are mine not IBM's
> Have a "phuongtastic" day,
> Best regards,
> Phuong Thanh Nguyen
> Networking System.
> PNGUYEN@VNET.IBM.COM
> In article <262iep$qs4@helios.intranet.gr>, antonis@intranet.gr (Antonis Kyriazis) writes:
> |> 
> |> 
> |> I think the corrected ip numbers are:
> |> 
> |>  
> |>                             198.51.250 Ethernet
> |>       ---------------------------------------------------------
> |>           |                                  |
> |>           |                                  |
> |> -------Router 1                         Router 2
> |> to remote |                             |   |   |
> |> location  |        Token Ring           |   |   |
> |>           |_____________________________|   |   |
> |>                198.178.216.(161-190)        |   |
> |>                                             |   |
> |>                                             |   | 56Kbps Leased Line
> |>                         Ethernet            |   | 198.178.216.(97-126)
> |>                     ________________________|   |
> |>                       198.178.216.(129-158)     |
> |>                                                 |
> |>                                                 |
> |>                                                 |
> |>                                             Router 3
> |>                                              |   |
> |>                             Token Ring       |   | Ethernet
> |>                             _________________|   |___________________
> |>                             198.178.216.(65-94)    198.178.216.(33-62)
> |>  
> |> 
> |> Your scheme means you reserve 3 bits for subnets and 5 bits for hosts.
> |> The addresses x.y.z.32, x.y.z.64, x.y.z.96, x.y.z.128, x.y.z.160 and
> |> x.y.z.192 are not accepted because, according to the subnet mask, appear
> |> to have zero network portion (a general subnetted ip address consists
> |> of: <class X address>.<subnet portion>.<host portion> ), and continuous
> |> zeros mean "this"! Similarly the addresses x.y.z.63, x.y.z.95, x.y.z.127,
> |> x.y.z.159, x.y.z.191 and x.y.z.223 represent the broadcast addresses for
> |> the corresponding subnets, provided that the broadcast format is "all
> |> ones".
> |> 
> |> So, after the corresponding definitions for subnet and broadcast mask,
> |> RIP should work...(?)
> |> 
> |> 
> |> Please, correct, if I'm wrong.
> |> 
> |> +-------------------------------------------------------------------+
> |> |     Antonis Kyriazis                                              |
> |> | Networks & Communications       e-mail: antonis@intranet.gr       |
> |> | INTRACOM sa                                                       |
> |> | 19.5 km Marcopoulo Ave.          fax:   +30-1- 66 44 379          |
> |> | Peania 190 02                           +30-1- 66 43 718          |
> |> | GREECE                          phone:  +30-1- 66 44 961-5        |
> |> |                                         +30-1- 88 43 715          |
> |> | "The expressed opinions are of my own"   + - MACEDONIA IS GREEK - +
> |> +-------------------------------------------------------------------+
> |> 
 
-- 
Tom Fitzgerald    Wang Labs, Lowell MA, USA    fitz@wang.com   1-508-967-5278
inews: .sig discarded because it contained false or misleading information

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Sep 1993 23:50:42 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Seeking ethernet-over-IP tunnelling bridge/router

Someone here is looking for a "bridge" that will promiscuously grab
ethernet packets with a particular ethertype, wrap them in TCP/IP, and
tunnel them across the Internet to a peer which will drop them onto another
ethernet, with the same source/destination MAC address and everything.
Does anyone make such a thing?  Info about commercial products are welcome
(via e-mail).

-- 
Tom Fitzgerald    Wang Labs, Lowell MA, USA    fitz@wang.com   1-508-967-5278
inews: .sig discarded because it contained false or misleading information



-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Sep 1993 00:37:44 GMT
From:      sr@acsu.buffalo.edu (Sudhakar Rajamannar)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Help needed in KA9Q

Hi !!!

I am having a problem with KA9Q . I have integrated BM into KA9Q
but have not been able to direct I/O on to the stdin(terminal).

For ex. When I try to send mail the title Subject doesnot appear on
the terminal. But appears when I exit from bm and return to Net (KA9Q).

BM works fine otherwise.

Any pointers to a solution will be of great help.(I have tried including
the necessary headers).

Please email to my account sr@acsu.buffalo.edu

Thanks in advance.


Sudhakar Rajamannar
-- 
-------------------------------------------------------------------------------
     Sudhakar Rajamannar      sr@acsu.buffalo.edu       
     Electrical & Computer Engineering
                           Department 

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Sep 1993 00:45:35 GMT
From:      janzen@idacom.hp.com (Martin Janzen)
To:        comp.protocols.tcp-ip
Subject:   Re: Terminating RPC servers

In article <1993Sep6.211558.22677@hubcap.clemson.edu> davidc@hubcap.clemson.edu (David S Condrey) writes:
>Anyway, I am new to writing RPC code. I have an example working, but
>cannot find any spec on terminating a server that has done a call to
>svc_run().  [...]  Is there an elegant way to terminate?

The main thing is to make sure that you remove your server's entry from the
portmapper's table.  This is the mapping from its program#/version#/protocol
to its port#.

If you're using the low-level calls (eg. svctcp_create(), svc_register()),
call svc_unregister() for each svc_register(), and svc_destroy() for each
svctcp_create(), then exit().

If you're using registerrpc(), then you don't have an SVCXPRT* to pass to
svc_destroy(), so just call svc_unregister(), then exit().

In either case, the svc_unregister() function calls pmap_unset() to remove
the portmapper entry.  Run "rpcinfo -p" before and after this call to check
that it's working correctly.


>Oh, by the way, this server is
>running on an MVS system. :-) Even so, any information would be
>helpful.

If the MVS implementation was based on Sun's ONC RPC 4.0, then this should
still work.  If it's been mangled too badly, you'll have to look for MVS-
specific documentation... :-P


>I have several books (supposedly good) at my disposal, but none seem
>to address this issue. I do not have the Sun documentation though.

I suggest that you get two things:

1) ONC RPC 4.0 source code, by anonymous FTP from bcm.tmc.edu:/nfs/rpc_40*
   This also includes the Sun RPC Programming Guide, etc.  UTSL!

2) John Bloomer's "Power Programming with RPC", from O'Reilly & Assoc.


Good luck!


-- 
Martin Janzen           janzen@idacom.hp.com
Pegasus Systems Group   c/o Hewlett-Packard, Idacom Telecomm. Operation

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Sep 1993 05:09:36 GMT
From:      chchang@ncb.gov.sg (Chang Chen Hsien)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   NCSA Telnet problem

Hi,

I am currently using NCSA Telnet 2.5 with MacTCP 1.1.1. We 
have about 40 Macs on EtherTalk which using this application. 

We have a problem of having intermittent pause (2 - 5 secs) when 
using Telnet (during the Telnet session). Have anyone out there
have the same problem or know how to resolve this ? If you do 
have the problem or know how to solve it, please let me know.
Thanks in advance !

Cheers

chchang@ncb.gov.sg

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Thu, 09 Sep 1993 09:44:47 GMT
From:      shahramn@mentorg.com (Shahram Najm @ ETC)
To:        comp.protocols.tcp-ip
Subject:   [Q] re rexec

Can someone please tell me why the network function 'rexec' sends
the plaintext password and not the encrypted one? 

This is a question posed by Stevens in his network prog book.

Thank v much in adv.

_________________________________________________________________
Shahram Najm                          shahram_najm@etc.MENTORG.COM
Mentor Graphics Corporation (UK)      Tel:   +44 344 867555 x2271
BRACKNELL, Berkshire, England.         #include <std.disclaimer>
_________________________________________________________________

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 93 11:57:26 GMT
From:      jordan@IMSI.COM (Jordan Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: Non-blocking connects

Douglas C. Schmidt <schmidt@ics.uci.edu> writes:

	Are there any other types of applications that benefit from
	this non-block approach?

Any event-driven application needs to do this, as long as there are at
least two potential sources of events.  Good examples are
user-interfaces to remote databases.  You don't want your process
blocked on connect() if someone wants to mouse-click on the cancel
button ...

/jordan

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Sep 1993 13:17:40 GMT
From:      a722756@pan.mc.ti.com (W. Donald Rolph III)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans,comp.windows.misc
Subject:   Re: TCP/IP stack - memory usage

In article <1516@fedfil.UUCP> fedfile@fedfil.UUCP (Federal Filings) writes:
>From: fedfile@fedfil.UUCP (Federal Filings)
>Subject: TCP/IP stack - memory usage
>Keywords: TCP/IP
>Date: 8 Sep 93 20:29:01 GMT


>Hello,
 
>We are using FTP software Inc.'s PC/TCP dev kit for developing a client-server
>Windows application in TCP/IP environment. 
 
>Recently I heard that Frontier Tech has some thing called Super TCP, which
>takes only 6k of conventional memory, whereas PC/TCP takes about 70k.
 
>When I checked with  FTP software they said, applications written with
>PC/TCP API does not work with any other TCP/IP stack but FTP's PC/TCP.
>Why is it so?
 
>If anyone has used Super TCP please let me know about their coment on it.
 
>Thanks in advance,
 
>Suma.
 
>suma@fedfil.com

As an aside, the new microsoft tcp/ip add on to windows for workgroups only 
requires 9.6K of memory on a 386 class machine with appropriate mmemroy 
managers.




-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Sep 1993 13:26:10 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: [Q] re rexec

In article <1993Sep09.094447.5243@news.mentorg.com> shahram_najm@etc.mentorg.com writes:
>Can someone please tell me why the network function 'rexec' sends
>the plaintext password and not the encrypted one? 
>
>This is a question posed by Stevens in his network prog book.

Easy.  It's the same reason the passwords for the vastly more common
telnet and rlogin are in the clear:  Encrypted by which algorithm?  Using
what key?  How is that key distributed?  What about having to pay Public
Key Partners royalties for using the now obvious solutions?  What about
getting permission from the U.S. government to ship the resulting system
out of the U.S.?

Some of those nontrivial questions are why there are things like Kerberos.

Look in sci.crypt where those issues are discussed endlessly.

You obviously couldn't just send the second field of a UNIX /etc/passwd,
and expect any system to think that means you know any authenticating
secrets.


Vernon Schryver    vjs@rhyolite.com

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Sep 1993 13:36:37 GMT
From:      ben@piglet.cr.usgs.gov (Ben A. Mesander)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: help wanted with network problem

In article <1993Sep8.174922.21222@tessi.com> kozowski@tessi.com (Eric Kozowski) writes:
   I really need to take care of the network overload, and I have a couple of
   ideas, but I am looking for any reasonable input.  I plan on cutting back 
   on the NFS mounts.  Is there anything else that would help?  TIA.

You might look at the amd automounter. I found that I could reduce the number
of NFS mounts on average on my network with it, and still allow people to
access all the same remote filesystems they used to.

NFS does appear to be a rather effective way of hosing a network. I started
to run NFSwatch so I could figure out what was causing my network overloads,
and I found that some inexperienced users were doing things like:

find / -name xterm -print

to find where xterm lived, etc. A little education helped here, and amd also
keeps the number of mounts under control, so if someone walks a filesystem,
it doesn't go through every disk on the entire network. I'm now working on
"phase II" of network education, which consists of explaining to people that
perhaps remote shelling the make to the machine that has the source on it
is faster than running the make on the local CPU, etc. This can be set up
very transparently with local variables in an emacs buffer and M-x compile, 
for instance.

I've found that people are quite receptive to any information that makes
their computers run faster.

--Ben

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 1993 14:01:41 GMT
From:      mjr@tis.com (Marcus J. Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: [Q] re rexec

shahram_najm@etc.mentorg.com writes:
>Can someone please tell me why the network function 'rexec' sends
>the plaintext password and not the encrypted one? 

	Because the rexec protocol was designed by someone who
didn't care about security.

mjr.

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Sep 1993 15:24:41 GMT
From:      luigi@iet.unipi.it
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   New version of PC-TAR and TCP-IP libraries available


I have finally managed to put together a new version of my tar program which
can do backups over a TCP circuit. There are some bug fixes in the
TCP-IP library (derived from WATTCP), so the latter is included as well.
Documentation for the TCP-IP library is being written and should be
freely available in the next few weeks (but I don't make promises on the
exact date).

Among the features of this software:

TCP-IP libraries:
      + derived from an old version of WATTCP, almost completely
	rewritten for what concerns the TCP protocol (just to experience
	how hard it is to write the TCP code out of the RFCs).
      + compiles under Microsoft C in both small and large memory
        models.
      +	A bug fix in the UDP code now avoids some annoying hangup
	that occurred in my previous version.
      + there is a socket library which tries to emulate Unix
	sockets, including a select() call. It has not been tested
	very much, so I will appreciate any bug reports and
	suggestions.
      + documentation is being written...

NET-TAR:
      + derived from gnu tar 1.10 and Erick Engelke's RSH client
      + allows redirection of input/output over a TCP connection so that
	the archive can be processed on a Unix host via RSH
      + compiles under MS C in both small and large memory models (so
        that there should be fewer problems with deep directory trees
	which require a lot of stack, or large TCP windows which can
	improve performance but require more memory)
      + wrt the previous release, there are only bug fixes in the TCP-IP
	libraries related to the UDP code.


All the above is available by anonymous ftp from

	pical3.iet.unipi.it (131.114.9.12)

in the directories
	/pub/deit_wattcp (TCP-IP libraries) and
	/pub/net_tar (the modified tar program)

As usual, if you use the above software, please consider spending
a few minutes to send back bug reports, suggestions for improvements, or
simply reporting your successful use.


	Luigi
====================================================================
Luigi Rizzo                     Dip. di Ingegneria dell'Informazione
email: luigi@iet.unipi.it       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522
====================================================================

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 1993 16:10:56 GMT
From:      aj681@cleveland.Freenet.Edu (Carlin Wiegner)
To:        comp.protocols.tcp-ip
Subject:   Need TCP/IP to SNA Connectivity...


We currently have a IBM Token Ring LAN connected to the corporate
WAN and 3090s. We are moving to a TCP/IP based network but we need
to retain our 3270 (SNA) connectivity. does anybody know of any
gateway or brouter products out there that can help us. 
Thanks for all your help and please email replies.
CW

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Sep 1993 17:26:34 GMT
From:      dsathyan@uncc.edu (Deepa Sathyan)
To:        comp.protocols.tcp-ip
Subject:   TLI and TCP

I have run into a peculiar problem while using TLI. I am trying to write a protocol to transfer files
from one machine to another. At this point (testing stage..) I am running my server and client programs
on the same machine. 

I am using a concurrent connection oriented algorithm which (to give you a clearer picture) is as follows:
(Those of you who have read Comer and Stevens (Vol 3) can skip it.....)

On the server side:
1. Create a descriptor (master) and bind to the well-known address for the service being offered.

2. Call t_listen to wait for the next connection request from the client.

3. Allocate a new descriptor, call t_accept to accept connection request, and create a new slave process 
    to  handle the response. Return to step 2 (master) to await another connection.

4. At the new descriptor (slave), interact with the client :receive request(s) and send back response(s).

5. Close the connection and exit. (the accepting descriptor (slave) exits.The listening descriptor     
   (master) stays in an infinite loop listening for connections).



Now, the above algoritm works fine if I have just one t_snd on the client side and one t_rcv on the
server side. I then need to send a t_snddis signal from the client and the t_rcv at the server side
gets out of its blocking mode and then disconnect.

The problem arises when I do this:
On the client side, I am reading a file into the buffer and sending the buffer using a t_snd. I repeat 
this until the EOF is reached. Once it is, I come of the loop. 

On the server side, I do a t_rcv and put the received buffer in a file. I have to put the t_rcv in a 
loop to be able to get the entire file. Now, most examples I have seen in the TLI manual, Stevens etc,
suggest putting the t_rcv in while loop and testing to see if the value returned by t_rcv is -1.
This would work if I were sending a t_snddis from the client side after coming out of the t_snd loop.
But I would like to be able to send another file from the server to the client. Hence, I do not want to 
issue a t_snddis at the client side just yet. 
	
The scenario is as shown below:


            Client                       Server
              |                          |
        t_snd |                          |
	      |----------->---->---------| t_rcv
 	      |                          |
	      |                          |
        t_rcv |                          |
	      |--------<----<------------| t_snd
 	      |                          |
 	      |                          |
	      |                          |
     t_snddis |                          |
	      |-------->---->------------| t_rcvdis
 	      |                          |


 My question is this (whew!):
How do I get of  a t_rcv loop on the server side without issuing a disconnect signal?  

I have  a tried a couple of things to solve this problem, to no avail. If anyone is interested, I can
send her/him mail of my (mostly futile) efforts. 

I would greatly appreciate an answer. Thanks.
Deepa


  







-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 1993 18:11:35 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: [Q] re rexec

In article <1993Sep09.094447.5243@news.mentorg.com> shahram_najm@etc.mentorg.com writes:
>Can someone please tell me why the network function 'rexec' sends
>the plaintext password and not the encrypted one? 

Unless the client and server machines use the same passwd file (either they
share an NIS server or passwd files are automatically copied between them)
the user's password is likely to be encrypted with different salts on the
two machines.  In this case, the encrypted passwords won't match, so it
won't be possible to verify the password.

Also, it doesn't increase security much to send the encrypted password.  If
someone captures the packet with the password, he just has to resend
whatever he captured in order to masquerade as you.  At best, it would mean
that the user could only get in via rexec, since he still wouldn't know a
paintext password to supply to an interactive login.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Sep 1993 18:34:22 GMT
From:      ag129@ucs.cam.ac.uk
To:        comp.protocols.tcp-ip
Subject:   Re: [Q] re rexec

In article <26nd05$rvl@sol.TIS.COM> mjr@tis.com (Marcus J. Ranum) writes:
>shahram_najm@etc.mentorg.com writes:
>>Can someone please tell me why the network function 'rexec' sends
>>the plaintext password and not the encrypted one? 
 
>        Because the rexec protocol was designed by someone who
>didn't care about security.

Remind me never to buy a secure system from you.  Since the poster
refers to 'the' encrypted password, he can only mean one thing -
the one-way encrypted password that Unix does the comparison on.
The reason this is not used by rexec is obvious - because to get
the plaintext password you have to snoop it off the wire, while to
get the encrypted one you just read it out of /etc/password.
Don't lose sight of the wood for the trees eh?

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Sep 1993 18:48:31 GMT
From:      mishra@controls.ccd.harris.com (Sanjoy Mishra)
To:        comp.protocols.tcp-ip
Subject:   SLIP: fails

This request is for SLIP experts:

I have installed the slip on my system: I use seyon dialer to dial
the slip server and then run slip command. I get following errors:

Attaching indus (147.90.4.248) to network via blazer (147.90.4.6)
/bin/slattach: ioctl TCGETA failed
/bin/slattach: ioctl TCGETA failed
ifconfig: ioctl (SIOCGIFFLAGS): Invalid argument


Here is my configuration
_________________
#slip.hosts
# dialup slip host table - maps usercodes to host addresses
#
indus mishra

__________________
#slip.config
# slip.config configuration file
#
# bazer is my slip server as well as gateway
blazer

Where blazer is the slip server and indus is my PC running SVR4.

ls -l /sbin/slip

-r-sr-xr-x   1 root     root       19048 Sep  8 21:48 /sbin/slip

if I run slattach in root window slattach works and I am able to ping
blazer after

ifconfig sl0 inet indus blazer up

______
#/etc/hosts

# Internet host table
#
127.0.0.1       localhost
147.90.4.248 indus
147.90.4.6 blazer

--

Any help on how I can get slip working ? Is the any FAQ ?

______________________________________________________________________________
Sanjay K. Mishra                      Work: 407-242-4333       
mishra@ccd.harris.com                 Home: 407-242-4333
The opinions expressed are my own and do not in any way represent Harris Corp.
------------------------------------------------------------------------------

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Sep 1993 20:06:19 GMT
From:      ben@piglet.cr.usgs.gov (Ben A. Mesander)
To:        comp.protocols.tcp-ip
Subject:   Re: recoverable ftp/ftp wrapper

In article <STURDJ.12.0@A1.Medtronic.com> STURDJ@A1.Medtronic.com (JamesSturdevant) writes:
   In article <1993Aug27.133041.15048@glv.uucp> bounds@gulaam.glv.com (Frank Bounds) writes:
   >From: bounds@gulaam.glv.com (Frank Bounds)
   >Subject: recoverable ftp/ftp wrapper
   >Anyone aware of a version of ftp that can detect failed xfers and
   >restart or flag the fact that it failed in some meaningful way
   >(so it could be restarted automatically)? We would need to do this on UNIX 
   >and VAX/VMS systems. 

   That sounds like a good application for C-Kermit.  It has a script language, 
   loggin capabilities, success and failure tests, can run over TCP/IP on VMS 
   and UNIX...

One of the nice things about the FSP file transfer tool suite is that
it is stateless, and even if the remote machine goes down, or some bit
of network between here and there dies, when it comes back up, the
transfer continues. I do not know if FSP is supported under VMS, but
you might look for the FAQ for whatever the FSP group is.

--Ben

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Sep 1993 23:04:24 GMT
From:      restock@pacbell.com
To:        comp.protocols.tcp-ip
Subject:   Access to gopher, etc through a firewall.


My machine is not actually on the Internet.  Instead my company, like many 
others, have a firewall machine which is connected to both our internal 
internet and the larger Internet.  I can run proxy Telnet and FTP through the 
firewall to get to other machines.  However, proxy Telnet and FTP require that 
I connect to the firewall host, then tell it which real host to connect to.

Now for the real problem.  I can not use any of the new tools (Gopher, WAIS, 
WEB) except within our own internet.  Is anybody working on supporting a proxy 
gopher or whatever?  Something that would use the alternate port numbers as 
well as recognize the host indirection?  It certainly sounds simple, but are 
all of the internet developers directly on the internet, so this is a 
non-problem to them?

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Sep 1993 23:34:11 GMT
From:      arterton@lds.loral.com (Chuck Arterton, 6846)
To:        comp.protocols.tcp-ip
Subject:   Logging in and out addresses


Hi TCPers:

My boss wants a way to log the originating address, the date and time,
and the destination address of a connection made by an employee over
the Internet.  He is interested in the connections to the outside
world.  This type of log might have the format shown below:

Date:   Time:        Originated:         Destined for:
Sep  9  17:14:52     158.186.241.70      192.9.200.18

Could a ciscoSystems router, model AGS+ do this?  Or, could a Sun
workstation be configured to listen on the net, capture the data and
format a report like this?  Is there some readily available software
that could do it?

I'm a SysOp that learns from example.  Could you very knowledgable
folks steer me toward a solution to this task?

Thanks in advance.


-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Sep 1993 00:45:25 GMT
From:      peril@extro.ucc.su.OZ.AU (Peter Lisle)
To:        comp.protocols.tcp-ip
Subject:   Multiple nets on wire


Hi - hopefully someone can answer this question!

We are in a situation where we are about to place a number of machines on the
Internet. We will not be able to get a class B network, yet we do have more
than 254 machines on a physical segment. This means that we need to get
multiple [class C] networks onto a single physical segment! Is this possible?
Does the gateway box need to configured in any specific fashion? Has anyone
done this?

The specific scenario that interests me is where two machines on the same
physical segement yet on different class C networks want to talk to each
other. Obviously they can talk direct - but each one will want to talk
through a gateway.

All thoughts, feedback and information are welcome!

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 1993 01:05:32 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Logging in and out addresses

In article <1993Sep9.233411.24945@lds.loral.com> arterton@lds.loral.com writes:
    
    My boss wants a way to log the originating address, the date and time,
    and the destination address of a connection made by an employee over
    the Internet.  He is interested in the connections to the outside
    world.  This type of log might have the format shown below:
    
    Date:   Time:        Originated:         Destined for:
    Sep  9  17:14:52     158.186.241.70      192.9.200.18
    
    Could a ciscoSystems router, model AGS+ do this?  

Close, but not quite.  With IP accounting enabled, you can get the packet
matrix (as well as packet and bytecounts), but there's no time stamp.  If
you polled the accounting database frequently, you might be able to achieve
enough resolution, depending on your purposes.

Tony

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Sep 1993 01:37:26 GMT
From:      smart@actrix.gen.nz (Quentin Smart)
To:        comp.protocols.tcp-ip
Subject:   Van Jacobson & Karn Algo's

Hello,
I'm trying to find the following references from RFC1122

[TCP:6] "Round Trip Time Estimation," P. Karn & C. Partridge, ACM
     SIGCOMM-87, August 1987.
 
 
[TCP:7] "Congestion Avoidance and Control," V. Jacobson, ACM
SIGCOMM-88,
     August 1988.
 
Or any code implementations of the above with special interest in
the later.

Some associates are trying to understand how Jacobsons algoritm
works so that they may fix a bug in their derivative of the WATTCP
code.

Thanks
Quentin
smart@actrix.gen.nz


-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 1993 01:37:47 GMT
From:      mjr@tis.com (Marcus J. Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Access to gopher, etc through a firewall.

>My machine is not actually on the Internet.  Instead my company, like many 
>others, have a firewall machine which is connected to both our internal 
>internet and the larger Internet.

	One thing I've been looking at doing is setting up a spawner
program that would chroot to a captive directory and let you kick off
Xgopher or whatever with your display set back to your workstation.
That way, the firewall bastion host isn't open to attack, and you
don't have to permit X traffic into and out of your network.

	I realize there are some basic functionality issues (like
configuration, per-user customization, local file access, etc) that
this wouldn't address. DEC CRL has released an X-protocol proxy,
that gateways X traffic - that would be another useful application
that could reside in the captive executable directory.

	I'll be writing some code to do this fairly soon, so if
anyone has suggestions/gotchas you want to share, feel free to
drop me a line.

mjr.

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 1993 01:39:30 GMT
From:      mjr@tis.com (Marcus J. Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Logging in and out addresses

>My boss wants a way to log the originating address, the date and time,
>and the destination address of a connection made by an employee over
>the Internet.  He is interested in the connections to the outside
>world.  This type of log might have the format shown below:

	The best way to do this sort of thing is to block all
traffic, and make the only means of egress via a firewall with
proxies running on a bastion host. Then have the proxy require
user authentication and log traffic.

mjr.

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Sep 1993 07:22:58 GMT
From:      etxmesa@eos.ericsson.se (Michael Salmon)
To:        comp.protocols.tcp-ip
Subject:   Re: [Q] re rexec

In article <1993Sep09.094447.5243@news.mentorg.com>
shahramn@mentorg.com (Shahram Najm @ ETC) writes:
|> Can someone please tell me why the network function 'rexec' sends
|> the plaintext password and not the encrypted one? 

The encrypted password is (in most systems) globally readable hence if
you allow encrypted passwords in you protocol then all that is required
is for someone to read the passwd file, find the entry for root and use
that in his rexec call. Even generating the encrypted password requires
a salt which is stored in the passwd file and hence probably not
available (after all thats why NIS exists). Encryption is probably a
good idea but then you need to have an RSA type scheme to be effective.

-- 

Michael Salmon

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

Ericsson Telecom AB
Stockholm

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 1993 15:38:39 -0400
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple nets on wire

In article <peril.747621925@extro.ucc.su.OZ.AU> peril@extro.ucc.su.OZ.AU (Peter Lisle) writes:
>We are in a situation where we are about to place a number of machines on the
>Internet. We will not be able to get a class B network, yet we do have more
>than 254 machines on a physical segment. This means that we need to get
>multiple [class C] networks onto a single physical segment! Is this possible?
>Does the gateway box need to configured in any specific fashion? Has anyone
>done this?

Yes, it's possible.  How you configure it depends on what you're using as a
gateway.  On a cisco, for instance, you do it by defining "secondary"
addresses for the interface.  On many Unix systems you can configure
static routes that use the interface's address as their gateway, e.g.

ifconfig le0 195.201.30.1
route add net 195.201.31.0 195.201.30.1 0
route add net 195.201.32.0 195.201.30.1 0

>The specific scenario that interests me is where two machines on the same
>physical segement yet on different class C networks want to talk to each
>other. Obviously they can talk direct - but each one will want to talk
>through a gateway.

If all the machines are Unix systems that support the above routing
feature, you can configure the static routes into all of them, and then
they'll talk to each other directly.  Any systems that don't support this
kind of routing feature may have to go through the gateway.

If your network numbers fit certain constraints you could also make use of
"supernetting", in which you set the subnet mask so that it's less than 24
bits long.  For instance, if you have the four networks 195.201.32,
195.201.33, 195.201.34, and 195.201.35 you can set your subnet mask to
255.255.252.0 (fffffc00), so that the low-order two bits of the network get
treated as part of the host.  The constraints I referred to are that the
network numbers be adjacent, the number of networks is a power of two, and
the third octet of the network number is a multiple of that power of two.
There are likely to be some systems that won't let you set the subnet mask
to be smaller than the default subnet mask for the address, though; these
systems will either have to use the above routing scheme, or go through the
gateway.

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 93 17:16:36 PST
From:      marcus@cpva.saic.com (Mark Jenkins, SAIC/CIR Network Services)
To:        comp.protocols.tcp-ip
Subject:   Re: Logging in and out addresses

In article <1993Sep9.233411.24945@lds.loral.com>, arterton@lds.loral.com (Chuck
Arterton, 6846) writes:

> My boss wants a way to log the originating address, the date and time,
> and the destination address of a connection made by an employee over
> the Internet.  He is interested in the connections to the outside
> world.  This type of log might have the format shown below:
> 
> Date:   Time:        Originated:         Destined for:
> Sep  9  17:14:52     158.186.241.70      192.9.200.18

You may want to investigate the Raptor Eagle gateway system.  Contact the
Concorde Group in Cambridge, MA (617) 491-0400.   They should be able to give
you information about it.  It is not cheap, but in addition to giving you the
auditing capabilities you want, it has all sorts of alarm and access control
capabilities.

I have demoed the system, but have no interest in the company (other than as a
possible buyer).

MarkJ
-- 
Mark Jenkins <Marcus@CPVA.SAIC.Com>| My views do not necessarily match yours.
SAICnet Logical Network Manager    | My opinions are not necessarily SAIC's.
Science Applications               | I've never met an iguana I didn't like.
International Corporation          | But that goes without saying.
San Diego, CA   USA  (619) 458-2794| -------- This space for rent ----------

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Sep 1993 09:23:36 GMT
From:      Jerry.Hagon@newcastle.ac.uk (J.P.Hagon)
To:        comp.protocols.tcp-ip
Subject:   Hardware required for machine to act as gateway


Hello 

We have plans to purchase about 20 unix workstations for use in distributed
parallel processing and want to network them together separately from our
campus network. The campus network is connected to internet. The proposed
arrangement would be something like this:


                     ------------------------
                    |                        |
                    |   Campus Network       |
                    |                        |
                     ------------------------
                                |
                           ------------
                          |  gateway   |
                          |  machine   |
                           ------------
                                |
                         ----------------
                        |    our own     |
                        |    private     |
                        |    network     |
                         ----------------

The gateway machine is likely to be a SUN Sparc II. Our private network 
would have its own (Class C) internet address. My question concerns the
hardware on the gateway machine. Does it need two ethernet cards - one
to connect to the campus network and the other to connect to our private
network or is there special hardware that needs to be purchased for 
gateway machines? Are there other ways of linking a local separate
tcp/ip network to an existing tcp/ip network?

                             many thanks

                                  Jerry
-- 
===========================================================================
Jerry Hagon                    |  E-Mail:     
Solid State Physics Group      |  INTERNET  : Jerry.Hagon@newcastle.ac.uk
Dept. of Physics               |  Compuserve: 100014,2702
The University                 |                                      
Newcastle upon Tyne	       |  PHONE:    +44 91 2227380
NE1 7RU                        |  FAX:      +44 91 2227361
United Kingdom                 |
===========================================================================

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Sep 1993 13:09:58 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Van Jacobson & Karn Algo's

> "Congestion Avoidance and Control," V. Jacobson, ACM SIGCOMM-88, August 1988.

A PostScript copy of this paper is available via anonymous FTP from
ftp.ee.lbl.gov in the file congavoid.ps.Z.

>Or any code implementations of the above with special interest in the later.

Take a look at the Berkeley Net/2 code that's publicly available at
lots of archive sites.  You can start at ftp.uu.net in the
systems/unix/bsd-sources directory.

	Rich Stevens  (rstevens@noao.edu)

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Sep 1993 13:24:19 GMT
From:      Sam.Wilson@ed.ac.uk
To:        comp.protocols.tcp-ip
Subject:   User Info for SLIP or PPP?

We are about to provide a SLIP and PPP dialup service (using 14.4Kb
compressing modems and a Xylogics Annex TS if that makes a difference)
and before embarking on writing a note to explain how to use the service
it struck us that people must have been there before.  Does anyone have
a user guide (preferably no more than a page or two) describing how to
dial in and then configure the remote machine (PC with DOS, PC or other
machine with Unix, Mac with MacTCP/NCSA Telnet/MacPPP or whatever
combination of the above).  The setup is that you dial in using dumb
terminal emulation, login with user and password, choose SLIP or PPP
from a command prompt and then set up the local end using the IP address
that the Annex tells you before switching into SLIP or PPP mode.

Mailed replies preferred - if there's a) enough interest and b) enough
response I will of course summarise.  Thanks.


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

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 1993 13:26:25 GMT
From:      antonis@intranet.gr (Antonis Kyriazis)
To:        comp.protocols.tcp-ip
Subject:   Re: Need TCP/IP to SNA Connectivity...

I'm going to extend our SNA  network using LLC2 tunneling on 3COM's s/w
6.x NetBuilderII. The point is that you need either a 37xx with
ethernet or token ring adaptor or a 3172, talking SNA/LLC2 (instead of
SDLC of course) on one side, and a remote cluster controller on the
other side, with ethernet adaptor too (I think this is your case)
talking SNA/LLC2. The  brouter makes local termination of the LLC2 frames
and then encapsulates the rest of the frames to IP packets. It's supposed to
be a successful technique to route APPN/LU6.2 traffic, with prioritization
and filtering too...
IBM does support it (6611).

good luck
+-------------------------------------------------------------------+
|     Antonis Kyriazis                                              |
| Networks & Communications       e-mail: antonis@intranet.gr       |
| INTRACOM sa                                                       |
| 19.5 km Marcopoulo Ave.          fax:   +30-1- 66 44 379          |
| Peania 190 02                           +30-1- 66 43 718          |
| GREECE                          phone:  +30-1- 66 44 961-5        |
|                                         +30-1- 88 43 715          |
| "The expressed opinions are of my own"   + - MACEDONIA IS GREEK - +
+-------------------------------------------------------------------+


-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Sep 1993 14:12:29 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans,comp.windows.misc
Subject:   Re: TCP/IP stack - memory usage

a722756@pan.mc.ti.com (W. Donald Rolph III) writes:

>>Recently I heard that Frontier Tech has some thing called Super TCP, which
>>takes only 6k of conventional memory, whereas PC/TCP takes about 70k.

Check what the salesman says carefully. If they forgot to mention an
NDIS driver, that's usually 20k + on its own. PC/TCP takes 26k of low
memory as minimum; the packet driver, which is usually only 4-6k. I'm
using a generously-configured PC/TCP here (11 packet buffers) which
weighs in at 37K - dedicated kernel, so no other drivers required.

>>When I checked with  FTP software they said, applications written with
>>PC/TCP API does not work with any other TCP/IP stack but FTP's PC/TCP.
>>Why is it so?

Same reason as everyone else's stacks don't interwork under DOS.
They never did - all have their own ABIs.  Winsock fixes this - for MS
Windows. It'll never be fixed with plain DOS.

>As an aside, the new microsoft tcp/ip add on to windows for workgroups only 
>requires 9.6K of memory on a 386 class machine with appropriate mmemroy 
>managers.

Sure. But it still needs a 20k + NDIS driver. Why *are* NDIS drivers so
huge? They do *less* than packet drivers.

With "appropriate memory managers" PC/TCP takes 0k of low memory. It is
not alone. [An appropriate manager here is QEMM 6 or 7 using stealth, BTW]

Ian
-- 
--- 
Ian Phillipps. Tech support manager, Unipalm.	If you ask me, all conspiracy
Phone +44 223 250103, Fax 250101		theories are put about by the
Pipex phone +44 223 250120			same bunch of people.

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 1993 14:34:18 GMT
From:      udaya@omp2.mch.sni.de (Bhavanasi Ravi)
To:        comp.protocols.tcp-ip
Subject:   Where do I find ftp Software.....

Hi,

	I am looking for ftp Software . If anybody  knows where I can
find please respond as quickly as possible.

Thanks in advance.

-- Ravi
-------------------------------------------------------------------------
Bhavanasi Udaya Ravi Shankar (BURS)           udaya@omp2.mch.sni.de
Siemens Nixdorf Informations Systems
Muenchen, Germany
-------------------------------------------------------------------------



-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 1993 14:54:42 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Logging in and out addresses

I once kluged up something similar to this with NNStat, but it was
awkward to use because NNStat wasn't meant for the job.  The problem,
in your case, is the precise timestamp.  Very little will be able to
record that.

One way to do it would be with a network analyzer that can be
configured to capture only TCP SYN, SYN/ACK, and FIN packets.  Save the
dump once a day and you will have precise timestamps for the beginning
and ending of every connection.  The network analyzer is going to be
expensive, though.

	 Stephen

-- 
Stephen Trier (trier@ins.cwru.edu - MIME OK)   "This is not a computer --
Network Software Engineer                       this is my arch-enemy!"
IRIS/INS/T                                           O'Brien, DS9
Case Western Reserve University             

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Sep 1993 15:51:33 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Proper behavior of FTP "NLST" command?

Should the NLST command of FTP return:

        a list of all files (i.e., including directories)
or just a list of regular files?

From a human ("ls") perspective the first seems desirable,
but from an automated ("mget") perspective, the second seems needed...

John
PS, I RTFFTPRFC, it gave little guidance.
-- 
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

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 93 16:36:06 GMT
From:      sam@bsu-cs.bsu.edu (B. Samuel Blanchard)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI and TCP

In article <CD3KGA.Lvp@unccsun.uncc.edu> dsathyan@uncc.edu writes:
>I have run into a peculiar problem while using TLI. I am trying to write a protocol to transfer files
 
>On the server side:
>[..]
>4. At the new descriptor (slave), interact with the client :receive request(s)
> and send back response(s).

One option is to create sub-processes to control each file.  This adds a layer
to your current design.  I.e.  server listens and creates "transfer control"
sub-process, "transfer control" process creates "file transfer" sub-process,
and "file transfer" sub-process terminates for each file.

The "transfer control" and "files transfer" processes described above would
also be needed on the client side.

This also adds a level of control which could prove useful.  Examples of using
this "transfer control" include: multiple files at one time, detection of hangs.

I think this matches ftp's structure.

>[..] if I have just one t_snd on the client side and one t_rcv on the
>server side. I then need to send a t_snddis signal from the client and the
>t_rcv at the server side gets out of its blocking mode and then disconnect.
>
>The problem arises when I do this:
>On the client side, I am reading a file into the buffer and sending the buffer
>using a t_snd. I repeat 
>this until the EOF is reached. Once it is, I come of the loop. 
>
>On the server side, I do a t_rcv and put the received buffer in a file. I have to put the t_rcv in a 
>Now, most examples I have seen in the TLI manual, Stevens etc,
>suggest putting the t_rcv in while loop and testing to see if
>the value returned by t_rcv is -1.
>This would work if I were sending a t_snddis from the client side
>after coming out of the t_snd loop.
>But I would like to be able to send another file from the server to the client.

Stepping back from my earlier redesign and using your current design:
Looks like you need a FLAG to indicate End-Of-Record.

According to my documentation for t_snd:
"T_MORE enables a user to break up large logical data units without
losing the boundaries of those units at the other end of the connection."
also note!
"The size of each TSDU must not exceed the limits of the transport
provider as returned by t_open or t_getinfo."

MAYBE you could use T_MORE to indicate continuation of the current file.
I'm unsure if TSDU limitation are exceeded (probably obvious to someone?).

>
> My question is this (whew!):
>How do I get of  a t_rcv loop on the server side without issuing a disconnect signal?  
>I would greatly appreciate an answer. Thanks.
>Deepa

1 answer and 1 question, how's that?
-- 
B. Sam Blanchard        sam@bsu-cs.bsu.edu
418 Winfield Dr         (317) 284-7131   work
Greenfield, IN 46140

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 1993 16:45:20 GMT
From:      ahh@cisco.com (Andy Heffernan)
To:        comp.protocols.tcp-ip
Subject:   Re: Van Jacobson & Karn Algo's

In article <CD476F.C5C@actrix.gen.nz> smart@actrix.gen.nz (Quentin Smart) writes:
[...]
>[TCP:7] "Congestion Avoidance and Control," V. Jacobson, ACM
>SIGCOMM-88,
>     August 1988.

	A Postscript version of this paper is available (under the name
congavoid.ps.Z) via anonymous FTP to ftp.ee.lbl.gov.


-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Sep 1993 17:19:44 GMT
From:      bdz+@cs.cmu.edu (Brian Zill)
To:        comp.protocols.tcp-ip
Subject:   Re: Non-blocking connects

In article <fred_sCD1t97.4Mz@netcom.com>,
Frederick Scott <fred_s@netcom.com> wrote:
>robert@gar.no (Robert Andersson) writes: 
>
>>In <fred_sCD0F4y.CIy@netcom.com> fred_s@netcom.com (Frederick Scott) writes:
>>
>>>robert@gar.no (Robert Andersson) writes: 
 
>>>>I have found that the method below is better.  We do it this way in a
>>>>product that runs on some 10-15 different Unix versions without trouble.
>>>>
>>>>a) After the asynch connect(), do a select() both for reading *and*
>>>>   writing.
>>>>b) Check the read fd_set first, if it's set, do a read() on the socket.
>>>>   The read() will fail and errno will tell why the connect() failed.
 
>>>What if the connect did succeed and data has been received on the
>>>connection.  Won't the read() consume data?  You might not necessarily
>>>want to consume any of your buffered data just to check if the connect
>>>succeded.
>>
>>It appears this isn't a problem.  Like I wrote, we do it this way and it
>>works fine on 10-15 different Unix implementations.
>
>Yes, but the question is, WHY does it work?  Because it's portable or
>because your applications simply don't involve the passive end of the
>connection sending any data right away?  You should understand exactly
>what your technique is doing before you recommend it to others.  If their
>application's passive side sends data right after completing its accept,
>it may be received and consumed in the initial read you're recommending
>and then they'll wonder what happened to it when then need it.

It's worse than that: TCP allows one to send data in SYN packets.  Now the
socket interface doesn't allow one to do this (at least in any implementation
I've looked at closely), so you probably won't see this behavior from the
vast majority of machines on the Internet today, but it's a perfectly valid
thing for a TCP to do.  In other words, someday your implementation that works
just fine on 10-15 different Unix implementations may attempt to connect to
a server that sends some initial data back in the connection accept packet
and find it doesn't work just fine anymore.  Oops.  I agree with Frederick
Scott, you should understand what your technique is doing and think about
whether or not it really is a general solution just because it works for
you in your current case.

>>The select() returns immediately after the connect() succeeds or fails.
>>If it succeeds only the write fd_set bit is set, not the read fd_set bit.
>>This makes a lot of sense, as no data has been received yet at this stage.
>
>I wouldn't assume that if I were you.  A loaded system which has swapped
>your application out for a couple seconds may well receive data between the
>time the connection completes and when the application is swapped back in,
>allowing the select to complete.  Perhaps your applications simply have
>never been run under such conditions.
>
>Fred

As I pointed out above, you don't even need a loaded system for this to
happen.  The assumption that "no data has been received yet at this stage"
simply cannot be made.

--Brian

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Sep 1993 17:39:42 GMT
From:      dryan@cscns.com (David Ryan)
To:        comp.protocols.tcp-ip
Subject:   Novell MP Router as firewall

Is Novell's multiprotocol router suitable as a firewall?

Does it allow for filtering based on IP address, MAC address 
and IP protocols?

How secure is it?  What have been people's experiences?

Thanks in advance for comments.



-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Sep 1993 17:47:31 GMT
From:      bdz+@cs.cmu.edu (Brian Zill)
To:        comp.protocols.tcp-ip
Subject:   Re: Sockets conversion

In article <CD04pC.7o2@cbfsb.cb.att.com>,
michael.v.murphy <mvm@cbnewsb.cb.att.com> wrote:
>    We currently have an applications written in TLI that sends messages to
>disributed machines via TCP. For several reasons, one of the sides needs to
>be re-written in SOCKETS [...]
>Is there any reason that a connections can't be initiated and maintained
>with one side talking sockets and the other TLI? [...]

No problem at all.  They have TCP in common, it doesn't matter what interface
to the protocol the user used to send the data.   The other side only sees
TCP/IP coming in the wire/fiber/whatever and has no knowledge of whether the
programmer on the other end used sockets, TLI, or even a home-brew interface.

--Brian

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Sep 1993 18:50:15 GMT
From:      lawson@netcom.com (Steven Lawson)
To:        comp.protocols.tcp-ip
Subject:   Re: Proper behavior of FTP "NLST" command?

John Hascall (john@iastate.edu) wrote:
: Should the NLST command of FTP return:
 
:         a list of all files (i.e., including directories)
: or just a list of regular files?
 
: From a human ("ls") perspective the first seems desirable,
: but from an automated ("mget") perspective, the second seems needed...

Per RFC 959, the LIST function should return the listing in a human readable
form with any information the user may be interrested in reading, while the
NLST function should return valid pathname strings suitable for processing
by a program (multiple get is their example).

- Steve


-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 1993 20:57:25 GMT
From:      mjo@iao.ford.com (Mike O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Re: Where do I find ftp Software.....

In article <26q39a$9u1@horus.mch.sni.de> udaya@omp2.mch.sni.de
(Bhavanasi Ravi) writes:

:	I am looking for ftp Software . If anybody  knows where I can
:find please respond as quickly as possible.

If you're referring to the software company:
I suggest sending electronic mail to postmaster@ftp.com.

-- 
 Michael J. O'Connor           |  Internet:  mjo@fmsrL7.srL.ford.com
 Ford Motor Company, OPEO      |  UUCP:      ...!fmsrl7!opeo!mjo
 20000 Rotunda, Bldg. 1-3001   |  Phone:     +1 (313) 248-1260
 Dearborn, MI  48121           |  Fax:       +1 (313) 323-6277

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 1993 21:24:37 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Non-blocking connects

In article <CD5Esw.53M.3@cs.cmu.edu>, Brian Zill <bdz+@cs.cmu.edu> wrote:
>In other words, someday your implementation that works
>just fine on 10-15 different Unix implementations may attempt to connect to
>a server that sends some initial data back in the connection accept packet
>and find it doesn't work just fine anymore.

I can confirm this.  I did an MS-DOS gopher client in which, to save a
few packets, I piggybacked data in the SYN packet.  It stopped working
with a couple of gopher servers.  Yes, I would have saved a little
bandwidth (and one RTT of delay), but I couldn't abandon those buggy
servers.  Oh, well.

	Stephen

-- 
Stephen Trier (trier@ins.cwru.edu - MIME OK)   "This is not a computer --
Network Software Engineer                       this is my arch-enemy!"
IRIS/INS/T                                           O'Brien, DS9
Case Western Reserve University             

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 1993 10:15:52 -0700
From:      schmidt@liege.ics.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip
Subject:   "Promiscuous-mode" token ring controllers

Hi,

	I've used the promiscuous-mode feature of our Ethernet
controllers to track protocol behavior on our local subnet.  I'm
curious whether this type of promiscuous-mode behavior is also
available on most token ring controllers?  It seems easy enough to do,
but no one around here has any token ring experience!

	Thanks for any insights,
	
		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

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 93 03:40:22 GMT
From:      hawkeye@glia.biostr.washington.edu (Ken Keys - TF Dude)
To:        comp.protocols.tcp-ip
Subject:   Re: Non-blocking connects

My previous response seems to have been lost, so I'm posting again.

In <8874@bacon.IMSI.COM> jordan@IMSI.COM (Jordan Hayes) writes:

>When select() returns for writing, call connect() again.  If it worked,
>you'll get -1 and errno == EISCONN; if it didn't work, you'll get errno
>== EINVAL you should call getsockopt(fd, SOL_SOCKET, SO_ERROR, ...) to
>retrieve the reason it failed.

The man pages I've checked (IRIX, SunOS) don't say anything about the
result of a second connect() when an eariler connect() failed.
However, as D.A.Clear suggested in his article, one could use
getpeername() and check for errno==ENOTCONN.  (The only other system
call I found which fails with ENOTCONN is shutdown(), which wouldn't
work for the general case).  This, combined with Jordan's suggestion of
getsockopt(), will give a fully functional nonblocking connect() (with
all the functionality of my original server suggestion, without the
complexity).

-- 
Ken "Hawkeye" Keys
hawkeye@glia.biostr.washington.edu

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 1993 12:21:26 +1000
From:      rpp@mippet.ci.com.au (Richard Perini)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS on Pyramid dual universe

bp3434@swuts.sbc.com (Blair Porter) writes:

>I have set up DNS on several UNIX platforms, using the /etc/resolv.conf
>to establish a resolving only environment.  I have setup this file on a
>Pyramid system, but am unable to get anything to work.  When I run the
>/usr/etc/nslookup program, it tells me it is using address 0.0.0.0, but
>I know that /etc/resolv.conf has valid nameserver entries.  What gives?
>There must be some subtle little thing, specific to the Pyramid, that I
>am missing.  Sorry I don't have access to any documentation, so I am
>left with trial & error to figure this thing out.  Anyone out there set
>this up on Pyramid?  Any assistance would be greatly appreciated.


You need to create a file "/etc/nameserver", which apparently indicates
to the resolver routines that you want to use DNS for name resolution.
You don't actually need to run a nameserver on the Pyramid, despite
advice I received to the contrary.  

BTW, this applies to OSx,  I have no idea about DC/ox (or whatever its 
called).


-- 
Richard Perini                                       Internet:  rpp@ci.com.au
Corinthian Engineering Pty Ltd                       PHONE:     +61 2 9064333
Sydney, Australia                                    FAX:       +61 2 9061556

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Sep 1993 08:28:36 GMT
From:      jagane@netcom.com (Jagane D Sundar)
To:        alt.winsock,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   *** Announcing WINTCP - A VxD Based WINSOCK impl for win 3.1 ***



		WINTCP - A VxD Based TCP/IP Stack with Winsock Interface

	Here is a neat way to do TCP on PC's - using a VxD. Following is the
	install.doc for wintcp. It doen not come with its own apps but I have
	tested it with wnqvt38 and trumpet for windows. Compare this stack
	with other commercial/PD winsock implementations for speed - IT FLIES.

	You can find the file wintcpa1.zip file at wuarchive.wustl.edu at
	/pub/MSDOS_UPLOADS/windows. I hope to get this release out to more
	sites at the earliest.


	Have fun,

		Jagane D Sundar
		jagane@netcom.com


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

		WINTCP Alpha1 - A VxD based TCP/IP Stack for Windows 3.1
						Jagane D Sundar

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Wintcp is a winsock implementation for Windows 3.1. It uses a radically
new approach in that the protocol stack is implemented as a VxD and
the accompanying winsock.dll simply provides a way for applications
to talk to the VxD. In addition the TCP/IP protocol layer is implemented
using the industry standard Net/2 Release of UCB.

All Aplha and Beta versions are free. The end product will include NFS
client support and will be some form of inexpensive shareware. All Alpha,
Beta testers will essentially get the software free for life including all
real releases.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

REQUIREMENTS:

Following are the requirements to install wintcp.

1) YOU MUST BE RUNNING WINDOWS IN 386 Enhanced mode.
2) You MUST use NDIS Drivers to access the network card.
3) You should be in a position to use a local hosts file till DNS support
   comes through in the next release.
4) You must be prepared to configure your network software by hand as
   BOOTP support is lacking in this release.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

FEATURES MISSING:

	1) DNS has not been implemented.
	2) The AsyncGetXbyY routines are not yet done. Blocking versions of the
	   same have been implemented with information taken from local files.
	3) BOOTP support for configuration is not supported.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

PERFORMANCE:

	The major advantage of implementing the TCP/IP Protocol stack as a VxD
	is speed. Although I have spent little time tuning the VxD for speed, I
	can already beat the performance of many commercial vendors. 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

TESTED APPLICATIONS:

	Although wintcp does not come with any applications I have succesfully
tested it with the following packages.

	WinQVT/v3.8:
		Telnet and ftp clients work fine.
		The ftp/rcp servers seem to be a little flaky.
	Trumpet for Winsock.
		Works fine.
	finer31:
		Works fine.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

INSTALLATION PRIMER:

	If you are familiar with PC Network installation, skip this section
	and go directly to WINTCP INSTALLATION.

	If you are unfamiliar with network installation this section may give
	you a little more information. It is not comprehensive.

	Wintcp installation involves 3 steps.
		1) Installing and configuring the NDIS Drivers.
		2) Installing the wintcp stack.
		3) Network configuration using tcpx, the tiny tcp executive provided
		   with wintcp.
	
	INSTALLING AND CONFIGURING THE NDIS DRIVERS:

	In order to do this you need the following files.
		1 - Protman.dos: provided with wintcp, courtesy Microsoft.
		2 - Protman.exe: provided with wintcp, courtesy Microsoft.
		3 - XXXXXX.dos: NDIS MAC Driver for your ethernet card, usually included
					 in the floppy of drivers that came with your card. If
					 not you can probably get them at your favourite ftp
					 site or BBS.Examples are smcmac.dos for WD80xx cards and
					 ELNKII.DOS for etherlink II cards. I have included these
					 two drivers with the wintcp zip file. But you are probably
					 best off getting your NDIS MAC driver from the card vendor.
		4 - dis_pktw.dos: A modified version of dis_pkt9.dos for use with
						wintcp.
		5 - netbind.exe: provided with winttcp, courtesy Microsoft.

	Entries need to be made to start protman.dos, XXXXX.dos, and dis_pktw.dos
	from config.sys and netbind.com from autoexec.bat.

	INSTALLING THE WINTCP STACK

	This is done by adding two lines to the windows\system.ini file in the
	Enh386 section.

	NETWORK CONFIG USING TCPX - WINTCP Executive.

	In order to configure your PC for use in the network you need the
	following information. This CANNOT BE made up and needs to be
	obtained from your Internet admin or somebudy knowledgeable.
		1) hostname ( unique name assigned by admin in most cases ).
		2) IP Address ( Usually of form, 167.28.1.2).
		3) Netmask ( Usually like 255.255.0.0 ).
		4) Broadcast mask ( Usually like 255.255.0.0 );
		5) Default router address. (optional).

	TCPX is a really stupid little program that makes life a little easier
	for initial configuration. It lets you enter the above values and stores
	them in configuration files for wintcp to use.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

WINTCP INSTALLATION:

	You need the following in order to install WINTCP.
		1) hostname. Usually assigned by network admin.
		2) IP Address ( Usually of form, 167.28.1.2).
		3) Netmask ( Usually like 255.255.0.0 ).
		4) Broadcast mask ( Usually like 255.255.0.0 );
		5) Default router address. (optional).
		6) NDIS MAC Driver for your ethernet card.

	************************* IMPORTANT ************************************
	If you do not have the NDIS MAC driver for your network card, you cannot
	complete installation of wintcp. The NDIS MAC drivers for your card
	have not been included in this package. If you do not have the NDIS MAC
	driver DO NOT PROCEED. The NDIS MAC drivers can be found in the drivers
	floppy that came with your network card. It may also be downloaded from
	from many internet sites if you want it free. Many vendors also have 
	BBS's form where you can download the drivers for free. If you feel like
	paying money for the same drivers you may download from COMPUSERVE.
	*************************************************************************

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

	STEP 1:

		Create \wintcp directory. It is hardcoded for now.
			mkdir c:\wintcp

		Unzip wintcp.zip into \wintcp. Use the -d option since the \wintcp\etc
		directory must to be created.
			pkunzip -d wintcp.zip

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

	STEP 2:

		If you are already running NDIS drivers for some other reason such as
		MS Lan Manager, things will be easy. Go directly to STEP 3. If not
		do the following.

		The NDIS drivers need at least three entries in your config.sys and
		one entry in your autoexec.bat file. Also, the configuration of
		NDIS is read in from the file protocol.ini (located in c:\wintcp in
		our case).

		Modifying config.sys:
			Add the following lines to your config.sys.
DEVICE=C:\wintcp\PROTMAN.DOS /I:C:\wintcp
DEVICE=C:\wintcp\ELNKII.DOS

# Line 1:	The protocol manager driver. /I: parameter tells it where to find 
			protocol.ini
# Line 2:	The NDIS MAC Driver for your card. Replace ELNKII.DOS with the 
			driver for your own card.

	Create the protocol.ini file in c:\wintcp with a text editor. You need
	entries in this file for at least the network card driver( NDIS MAC Driver
	for your card) and the dis_pktw.dos hook for wintcp.

	Make the right entries in the c:\wintcp\protocol.ini file for your
	NDIS MAC driver.  Shown below is the protocol.ini entry for the ELNKII
	card as suggested by 3COM. For other card there usually is a sample
	protocol.ini file somewhere in the drivers floppy which will give you
	an idea.

[EtherLinkII]
DRIVERNAME=ELNKII$
INTERRUPT=5
TRANSCEIVER=OnBoard
IOADDRESS=0x300

	Add the following line to your autoexec.bat.

c:\wintcp\netbind

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

	STEP 3:

		Add the following lines to your protocol.ini file.

[pktdrv]
drivername=pktdrv$
# Replace EtherLinkII with the name your network driver.
bindings=EtherLinkII
# The interrupt vector to use. NOTE THAT THE NEXT HIGHER VECTOR IS ALSO USED.
intvec=0x60
chainvec=0x66

		Add the following to your config.sys after the entry for protocol.dos
		and the network card.

DEVICE=c:\wintcp\dis_pktw.dos

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

	STEP 4:

	Add c:\wintcp to your path.

	Reboot so that your drivers get loaded and path is set.
	If any of the drivers you added complain or if netbind complains that it
	cannot bind you need help configuring the NDIS drivers.

	ENSURE THAT NO OTHER WINSOCK.DLL FROM ANY OTHER SOURCE IS IN THE PATH
	BECAUSE THE MOST COMMON PROBLEM SEEMS TO BE OUTDATED/INCORRECT
	WINSOCK.DLL KICKING IN WHEN ANY APP REQUESTS WINSOCK SERVICES.
    ----------------------------------------------------------------------------

	STEP 5:

	Add the following lines to your \windows\system.ini file in the 
	386Enh section.

device=c:\wintcp\wintcp.386
WINTCP_INT=60
			|
			|--->	Same as the entry in your protocol.ini file. BUT LEAVE OUT
					THE 0x part. Also remember that the next vector is used
					as well. Unless you have a really compelling reason, do not
					change the vector from 60. I have had problems running it
					at very high vector numbers.

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

	STEP 6:

	- Start windows.
	- Run c:\wintcp\tcpx either from file manager, run menu or create an icon
	  in you favourite group and click on the icon.
	- Use the Setup... menu item to setup the local host information
	  you have( hostname, IP Address, Netmask, Broadcast mask and default 
	  router(optional). ) You will be warned that you need to REBOOT windows
	  in order for your configuration information to be activated. But before
	  rebooting you may add host entries in your local hosts file.
	- Using the Setup... item in the main menu and add host information to
	  add the names of hosts that you are planning to use. DNS has not been
	  implemented in this release. Please bear with the inconvenience of using
	  a local hosts file for now.
	  	----------------------------- NOTE ---------------------------------
		The local hosts file resides in /wintcp/etc and is of the same
		format as the unix /etc/hosts file. You may setup minimal hosts
		using tcpx. Then ftp into your unix server and  get the /etc/hosts
		file. concat the /wintcp/etc/hosts file and the hosts file you just
		downloaded to form the new /wintcp/etc/hosts file. If your network
		uses NIS(YP) then telnet into the server and do "ypcat hosts > hosts"
		and download and concat this file into your wintcp/etc/hosts file.
		---------------------------------------------------------------------
	- Quit tcpx.
	- EXIT AND RESTART WINDOWS.
	- Your winsock tcp software is now ready. TCPX Need not be running for
	  you application to get winsock services.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

							APPENDIX  A

							FILE FORMATS

	The following files are used by wintcp for its configuration info.
	They are all in the wintcp/etc directory and closely resemble 
	corresponding unix system files. In general you may modify any of these
	files using a text editor, but you will probably have to restart windows
	for any changes to take effect.

	/wintcp/etc/hostname.e0:
		Configuration information for ethernet0, the first ethernet card in
	the system. Multiple interface support will soon be added. Contains three
	lines exactly. First line contains hostname, second line contains IP
	Address and third line contains the netmask. NO COMMENTS ALLOWED IN THIS
	FILE.It is parsed by a stupid parser in the VxD. Comments in this file
	are a luxury I  cannot afford. Example file contains:

calvin
167.28.1.2
255.255.0.0


	/wintcp/etc/services:
		Standard BSD /etc/services file with service port number entries.
	wintcp comes with the BSD standard services default file. To add entries
	you need to get the format from some unix system.

	/wintcp/etc/hosts
		Standard BSD /etc/hosts file. Comments are allowed. You can obtain
	hosts file from your local unix box and concat it to /wintcp/etc/host.

	/wintcp/etc/route:
		Standard route information file. Unix style. Refer to your unix
	box documentation for info on /etc/route.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

							APPENDIX B
							COPYRIGHTS

WINTCP includes several components built from publicly available sources
primarily from the BSD Net/2 release. The following Copyrights are relevant.

/*
 * Copyright (c) 1982, 1986 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 the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. All advertising materials mentioning features or use of this software
 *    must display the following acknowledgement:
 *	This product includes software developed by the University of
 *	California, Berkeley and its contributors.
 * 4. 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 BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 *
 *	@(#)tcp.h	7.7 (Berkeley) 6/28/90
 */

	The dis_pktw.dos driver is a modified version of the ndis shim and its
	copyright notice is included below.

; DIS_PKT.ASM - Adapter provides Packet Driver v1.09 interface over NDIS.
; Version 1.07  18 May 1991  by Joe R. Doupnik, Utah State Univ.
; Version 1.08  9 Aug 1991 by Dan Lanciani, ddl@harvard.harvard.edu
; Version 1.09  3 Nov 1991 by Joe R. Doupnik, Utah State Univ.
; Copyright (C) 1988 - 1991 FTP Software, Inc.
;
; This unmodified source file and it's executable form may be used and
; redistributed freely.  The source may be modified, and the source or
; executable versions built from the modified source may be used and
; redistributed, provided that this notice and the copyright displayed by
; the exectuable remain intact, and provided that the executable displays
; an additional message indicating that it has been modified, and by whom.
;
; FTP Software Inc. releases this software "as is", with no express or
; implied warranty, including, but not limited to, the implied warranties
; of merchantability and fitness for a particular purpose.
;
; USE AT YOUR OWN RISK.
;

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Sep 1993 10:15:55 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: User Info for SLIP or PPP?

In article <CD53wJ.2o@festival.ed.ac.uk> Sam.Wilson@ed.ac.uk writes:

>We are about to provide a SLIP and PPP dialup service (using 14.4Kb
>compressing modems and a Xylogics Annex TS if that makes a difference)
>and before embarking on writing a note to explain how to use the service
>it struck us that people must have been there before.  Does anyone have
>a user guide (preferably no more than a page or two) describing how to
>dial in and then configure the remote machine (PC with DOS, PC or other
>machine with Unix, Mac with MacTCP/NCSA Telnet/MacPPP or whatever
>combination of the above).  The setup is that you dial in using dumb
>terminal emulation, login with user and password, choose SLIP or PPP
>from a command prompt and then set up the local end using the IP address
>that the Annex tells you before switching into SLIP or PPP mode.
>
>Sam Wilson
>Computing Services, The University of Edinburgh
>Edinburgh, Scotland, UK


Sam,

Sorry I can't help directly with the user guide, but your description
of the log in process make it appear a bit long winded.   Many people 
on Demon Internet Services use the ka9q stack.  I am using it now,
from home.

It gives a TCP/IP/PPP (or slip) stack which supports Telnet, SMTP,
FTP, NNTP etc. all from a unix-like prompt.  All facilities are
served by a "master menu", offering mail, news, login, config. etc.

When I have prepared my mail (like in a few minutes from now) I will
return to my DIS menu, select "(L)og onto the Internet" and the stack 
does the rest:  firstly the autodialer kicks in and dials Demon;
their Morning Star PPP responds; my PPP does the authentication and
giving my IP address bit; then I get my unix-like prompt..... easy.

There's no need to log on with a terminal emulator and then swap
modes.

I have been looking too at FPT's PC/TCP (with PPP & SLIP).  It has
a dialer, which will automate any log in process, but whilst the
"send" verb is useful in any dialup/logon script, there is no
"await {string}" verb, so one would need to set a timer between each
"send{string}" command.  This is not good, because sometimes 
Demon takes 2 secs, sometimes 20 !

If you use an automated process, you could avoid the need for
a user guide.

Cheers,

Phil

-- 

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 

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 1993 13:18:41 GMT
From:      jaenicke@emserver.ee.TU-Berlin.DE (Lutz Jaenicke)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: New version of PC-TAR and TCP-IP libraries available

Dear Luigi,
I intended to send you the following as personal mail, but it get bounced back.
I also include the mailer error, so that you can contact your local sysadmin
to get the mail problem fixed.
	Lutz

From MAILER-DAEMON@pimac2.iet.unipi.it Sat Sep 11 15:06 MES 1993
Received: from mailgzrz.TU-Berlin.DE by emserver.ee.TU-Berlin.DE with SMTP
	(1.37.109.4/16.2) id AA19881; Sat, 11 Sep 93 15:06:52 +0200
Return-Path: <MAILER-DAEMON@pimac2.iet.unipi.it>
Received: from pimac2.iet.unipi.it by mailgzrz.TU-Berlin.DE (5.65c/ZRZ-MX)
          for <jaenicke@emserver.ee.TU-Berlin.DE>
	  id AA13982; Sat, 11 Sep 1993 15:06:26 +0200
Received: by pimac2.iet.unipi.it (5.57/Ultrix3.0-C)
	id AA19450; Sat, 11 Sep 93 15:05:29 +0200
Date: Sat, 11 Sep 93 15:05:29 +0200
From: MAILER-DAEMON@pimac2.iet.unipi.it (Mail Delivery Subsystem)
Subject: Returned mail: Service unavailable
Message-Id: <9309111305.AA19450@pimac2.iet.unipi.it>
To: <jaenicke@emserver.ee.TU-Berlin.DE>

   ----- Transcript of session follows -----
<<< RCPT To:<luigi@iet.unipi.it>
<<< DATA
>>> HELO pimac2.iet.unipi.it
<<< 553 pimac2.iet.unipi.it I refuse to talk to myself
554 <luigi@iet.unipi.it>... Service unavailable: Bad file number

   ----- Unsent message follows -----
Received: by pimac2.iet.unipi.it (5.57/Ultrix3.0-C)
	id AA19448; Sat, 11 Sep 93 15:05:29 +0200
Received: from emws1.ee.TU-Berlin.DE by mailgzrz.TU-Berlin.DE (5.65c/ZRZ-MX)
          for <luigi@iet.unipi.it>
	  id AA13977; Sat, 11 Sep 1993 15:05:05 +0200
Message-Id: <199309111305.AA13977@mailgzrz.TU-Berlin.DE>
Received: by emws1.ee.TU-Berlin.DE
	(1.37.109.4/16.2) id AA14499; Sat, 11 Sep 93 15:05:02 +0200
From: Lutz Jaenicke <jaenicke@emserver.ee.TU-Berlin.DE>
Subject: Re: New version of PC-TAR ... (with suggestions)
To: luigi@iet.unipi.it
Date: Sat, 11 Sep 1993 15:05:01 +0100 (MESZ)
In-Reply-To: <1993Sep9.152441.18846@serra.unipi.it> from "luigi@iet.unipi.it" at Sep 9, 93 03:24:41 pm
X-Mailer: ELM [version 2.4 PL22]
Content-Type: text
Content-Length: 3080      

> Among the features of this software:
> 
> TCP-IP libraries:
>       +	A bug fix in the UDP code now avoids some annoying hangup
> 	that occurred in my previous version.
That's very fine.

> NET-TAR:
>       + compiles under MS C in both small and large memory models (so
>         that there should be fewer problems with deep directory trees
> 	which require a lot of stack, or large TCP windows which can
> 	improve performance but require more memory)
See below.

> As usual, if you use the above software, please consider spending
> a few minutes to send back bug reports, suggestions for improvements, or
> simply reporting your successful use.
> 
> 
> 	Luigi

So I'll do:

Dear Luigi,
I got an older version of your net_tar from an ftp server some weeks ago.
The program was a GREAT help in switching some of our PCs from old and small
ST-506 hard disks to new IDE ones (you know, you cannot have both in your
PC at the same time). Data transfer was perfectly easy, one tar up,
one tar down. We had some hangs, however. We didn't mind, because transfer
is such fast that a second try didn't matter. We got some new trouble
(we couldn't get our data back from our HP9000/700) after I installed the
new HP-UX 9.01, so I am very pleased to see your announcement.

I downloaded your new version immediatly (as the internet allowed :-)
and did try it today. Here are my impressions:
- most of the time, the program works fine.
- some of the directories on the test-PC contain lots of files
  (e.g. the texinput directory of emtex). Tar refused to back up
  those directories with "error opening directory". Those directories
  are _not_ located deep in the directory-tree.
- The "z" option allows to automatically use compress on the UNIX-host.
  Given that we use HP's 700 line, the on-line compression doesn't give
  a remarkable time gap (the ISA-PCs with WD8000 cards cannot handle the
  hard disk data fast enough to make the HPs sweat).
  It would be nice however, to have an additional switch to use
  gzip instead of compress because of it's better compression ratio.
  I did use it with "-r", but I know for sure not all of our PC users
  do know what an rsh is or what "gzip - > my.tar.gz" means.
  
I cannot help you with the above mentioned bug and the gzip suggestion,
because I do not have a MS-C compiler (I remember I once saw an MASM in
our institute). I am the UNIX admin in our institute and "only" have a
HP 710 on my desk, but I am also responsible for the network software
on our PCs.
 
Again, I do like your net-tar very much and want to encourage you to do
further development on it.

With kind regards,
	Lutz
-- 
Lutz Jaenicke 				jaenicke@emserver.ee.TU-Berlin.DE 
Institut fuer Elektrische Maschinen	jaenicke@emapollo.ee.TU-Berlin.DE
Technische Universitaet Berlin		Tel. (004930)314-24552
Einsteinufer 11, D-10587 Berlin		Fax. (004930)314-21133 







-- 
Lutz Jaenicke 				jaenicke@emserver.ee.TU-Berlin.DE 
Institut fuer Elektrische Maschinen	jaenicke@emapollo.ee.TU-Berlin.DE
Technische Universitaet Berlin		Tel. (004930)314-24552
Einsteinufer 11, D-10587 Berlin		Fax. (004930)314-21133 

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 1993 14:21:59 GMT
From:      tstark@clark.net (Tim Stark)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   NcFTP 1.53 problem - terminfo.

Everyone:

     On my Solaris 2.2, I installed NcFTP 1.53 software without any problems
successfully. When I run it, I saw '$<2>' everywhere around NcFTP messages.
What's up? I debugged them on both terminfo and ncftp. I found no $<2>
word in its source code but found it in terminfo database! There are
$<2> in vt100 terminfo entry. How do I filter them out before print them
out? Which apporiate routines should I use for $<n> to being intrepret for
delay time? I need your help! I never heard of $<n> before.

     Or I have modify termcap_get routine to filter out $<n> commands.

     Everything works on Solaris 2.2 very well execpt $<n> printouts. :(
That is annoying to me.

-- Tim Stark

--
Timothy Stark			Inet: tstark@clark.net
6130 Edsall Rd. #301		TDD: (703)212-9731  FAX: (703)212-7598
Alexandria, Va. 22304-5859	Voice: Via VA Relay Center (800)828-1140
"God bless you! - My friend, Washington DC. - The Most Deaf Population City!"

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Sep 1993 17:43:22 GMT
From:      khai@adi.com (S. Khai Mong)
To:        comp.sys.novell,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Novell & Banyan & TCP/IP

I have this application which uses Novell's TCP/IP API and compiled
and linked with Novell's TCP/IP product.  This works fine on
Novell client workstations.

My question: Is there a chance that such an application will run on a
client workstation that has _only_ Banyan and Banyan's TCP/IP software
installed?  Is there any quick answer why it won't work?  (I am
thinking of getting Banyan's TCP/IP software)




-- 
Sao Khai Mong  Applied Dynamics, 3800 Stone School Road, Ann Arbor, MI 48108
Voice: (313) 973-1300x263      Fax: (313) 668-0012      E-mail: khai@adi.com  

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Sep 1993 19:59:31 GMT
From:      tim@sporran.uucp (Tim Fry)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI and TCP

In article <5001@bsu-cs.bsu.edu> sam@bsu-cs.bsu.edu (B. Samuel Blanchard) writes:
>Stepping back from my earlier redesign and using your current design:
>Looks like you need a FLAG to indicate End-Of-Record.
>
>According to my documentation for t_snd:
>"T_MORE enables a user to break up large logical data units without
>losing the boundaries of those units at the other end of the connection."
>also note!
>"The size of each TSDU must not exceed the limits of the transport
>provider as returned by t_open or t_getinfo."
>
>MAYBE you could use T_MORE to indicate continuation of the current file.
>I'm unsure if TSDU limitation are exceeded (probably obvious to someone?).

Unfortunatly, I think you'll find that the tsdu member of the t_info 
structure filled in by the t_open call, will be set to 0  -- meaning that
the transport provider (TCP) does not support the concept of TDSU (it is
a stream based protocol after all). Both the t_snd and t_rcv man pages state
that the T_MORE flag is not meaningfull and should be ignored in this case.

The only TLI t_rcv implementation I've seen which sets the T_MORE flag is
RS6000 AIX, but until release 3.2.4, it had serious problems with its 
implementation anyway, so I'm not sure it is to be relied upon in this case.

Tim



-- 
Tim Fry      			tim@sporran.uucp
Toronto, Canada


-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Sep 1993 22:25:54 GMT
From:      logier@qus102.qld.tne.oz.au (Rob Logie)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS on Pyramid dual universe

rpp@mippet.ci.com.au (Richard Perini) writes:

>bp3434@swuts.sbc.com (Blair Porter) writes:
 
>>I have set up DNS on several UNIX platforms, using the /etc/resolv.conf
>>to establish a resolving only environment.  I have setup this file on a
>>Pyramid system, but am unable to get anything to work.  When I run the
>>/usr/etc/nslookup program, it tells me it is using address 0.0.0.0, but
>>I know that /etc/resolv.conf has valid nameserver entries.  What gives?
>>There must be some subtle little thing, specific to the Pyramid, that I
>>am missing.  Sorry I don't have access to any documentation, so I am
>>left with trial & error to figure this thing out.  Anyone out there set
>>this up on Pyramid?  Any assistance would be greatly appreciated.


>You need to create a file "/etc/nameserver", which apparently indicates
>to the resolver routines that you want to use DNS for name resolution.
>You don't actually need to run a nameserver on the Pyramid, despite
>advice I received to the contrary.  
 
>BTW, this applies to OSx,  I have no idea about DC/ox (or whatever its 
>called).


>-- 
>Richard Perini                                       Internet:  rpp@ci.com.au
>Corinthian Engineering Pty Ltd                       PHONE:     +61 2 9064333
>Sydney, Australia                                    FAX:       +61 2 9061556


Also, some of the "nslookup" versions are broken, depending on what
ptf you are on.  It is possible for the DNS to be working ok, but for
NSlookup not to work.  Try using "ping" etc.

For more info, talk to you local Pyramid SE.


-- 
Rob Logie,      Telecom Australia | The opinions expressed are mine alone and in
Telstra Corp.     ACN 051 775 556 | no-way reflect the views or policies of the
NP-IT Operations, Queensland      | Telstra Corporation Limited
EMAIL: logier@qus102.qld.tne.oz.au| "These are my opinions alone"

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 1993 02:01:54 GMT
From:      axa12@po.CWRU.Edu (Ashok Aiyar)
To:        comp.protocols.tcp-ip
Subject:   POP3D for System V



I am looking for a pop3 daemon that can be compiled under System V.
Suggestions/help would be appreciated.

Ashok
-- 
Ashok Aiyar                                      tel: (216) 368-3300
Department of Biochemistry                       fax: (216) 368-4544
CWRU School of Medicine                  ashok@biochemistry.cwru.edu

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12 Sep 1993 04:45:10 GMT
From:      jagane@netcom.com (Jagane D Sundar)
To:        alt.winsock,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   WINTCP - VxD Winsock impl - Available at biochemistry....


	
	Thanks to Ashok, WINTCP Alpha 1 is availbale at biochemistry.cwru.edu.

	The details,

		biochemistry.cwru.edu in /pub/wintcp. Filename is wintcpa1.zip.

	Download and have fun,

		Jagane
		jagane@netcom.com

	PS: Included is the article I had earlier posted on alt.winsock.

		WINTCP - A VxD Based TCP/IP Stack with Winsock Interface

	Here is a neat way to do TCP on PC's - using a VxD. Following is the
	install.doc for wintcp. It doen not come with its own apps but I have
	tested it with wnqvt38 and trumpet for windows. Compare this stack
	with other commercial/PD winsock implementations for speed - IT FLIES.

	You can find the file wintcpa1.zip file at wuarchive.wustl.edu at
	/pub/MSDOS_UPLOADS/windows. I hope to get this release out to more
	sites at the earliest.


	Have fun,

		Jagane D Sundar
		jagane@netcom.com


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

		WINTCP Alpha1 - A VxD based TCP/IP Stack for Windows 3.1
						Jagane D Sundar

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Wintcp is a winsock implementation for Windows 3.1. It uses a radically
new approach in that the protocol stack is implemented as a VxD and
the accompanying winsock.dll simply provides a way for applications
to talk to the VxD. In addition the TCP/IP protocol layer is implemented
using the industry standard Net/2 Release of UCB.

All Aplha and Beta versions are free. The end product will include NFS
client support and will be some form of inexpensive shareware. All Alpha,
Beta testers will essentially get the software free for life including all
real releases.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

REQUIREMENTS:

Following are the requirements to install wintcp.

1) YOU MUST BE RUNNING WINDOWS IN 386 Enhanced mode.
2) You MUST use NDIS Drivers to access the network card.
3) You should be in a position to use a local hosts file till DNS support
   comes through in the next release.
4) You must be prepared to configure your network software by hand as
   BOOTP support is lacking in this release.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

FEATURES MISSING:

	1) DNS has not been implemented.
	2) The AsyncGetXbyY routines are not yet done. Blocking versions of the
	   same have been implemented with information taken from local files.
	3) BOOTP support for configuration is not supported.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

PERFORMANCE:

	The major advantage of implementing the TCP/IP Protocol stack as a VxD
	is speed. Although I have spent little time tuning the VxD for speed, I
	can already beat the performance of many commercial vendors. 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

TESTED APPLICATIONS:

	Although wintcp does not come with any applications I have succesfully
tested it with the following packages.

	WinQVT/v3.8:
		Telnet and ftp clients work fine.
		The ftp/rcp servers seem to be a little flaky.
	Trumpet for Winsock.
		Works fine.
	finer31:
		Works fine.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

INSTALLATION PRIMER:

	If you are familiar with PC Network installation, skip this section
	and go directly to WINTCP INSTALLATION.

	If you are unfamiliar with network installation this section may give
	you a little more information. It is not comprehensive.

	Wintcp installation involves 3 steps.
		1) Installing and configuring the NDIS Drivers.
		2) Installing the wintcp stack.
		3) Network configuration using tcpx, the tiny tcp executive provided
		   with wintcp.
	
	INSTALLING AND CONFIGURING THE NDIS DRIVERS:

	In order to do this you need the following files.
		1 - Protman.dos: provided with wintcp, courtesy Microsoft.
		2 - Protman.exe: provided with wintcp, courtesy Microsoft.
		3 - XXXXXX.dos: NDIS MAC Driver for your ethernet card, usually included
					 in the floppy of drivers that came with your card. If
					 not you can probably get them at your favourite ftp
					 site or BBS.Examples are smcmac.dos for WD80xx cards and
					 ELNKII.DOS for etherlink II cards. I have included these
					 two drivers with the wintcp zip file. But you are probably
					 best off getting your NDIS MAC driver from the card vendor.
		4 - dis_pktw.dos: A modified version of dis_pkt9.dos for use with
						wintcp.
		5 - netbind.exe: provided with winttcp, courtesy Microsoft.

	Entries need to be made to start protman.dos, XXXXX.dos, and dis_pktw.dos
	from config.sys and netbind.com from autoexec.bat.

	INSTALLING THE WINTCP STACK

	This is done by adding two lines to the windows\system.ini file in the
	Enh386 section.

	NETWORK CONFIG USING TCPX - WINTCP Executive.

	In order to configure your PC for use in the network you need the
	following information. This CANNOT BE made up and needs to be
	obtained from your Internet admin or somebudy knowledgeable.
		1) hostname ( unique name assigned by admin in most cases ).
		2) IP Address ( Usually of form, 167.28.1.2).
		3) Netmask ( Usually like 255.255.0.0 ).
		4) Broadcast mask ( Usually like 255.255.0.0 );
		5) Default router address. (optional).

	TCPX is a really stupid little program that makes life a little easier
	for initial configuration. It lets you enter the above values and stores
	them in configuration files for wintcp to use.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

WINTCP INSTALLATION:

	You need the following in order to install WINTCP.
		1) hostname. Usually assigned by network admin.
		2) IP Address ( Usually of form, 167.28.1.2).
		3) Netmask ( Usually like 255.255.0.0 ).
		4) Broadcast mask ( Usually like 255.255.0.0 );
		5) Default router address. (optional).
		6) NDIS MAC Driver for your ethernet card.

	************************* IMPORTANT ************************************
	If you do not have the NDIS MAC driver for your network card, you cannot
	complete installation of wintcp. The NDIS MAC drivers for your card
	have not been included in this package. If you do not have the NDIS MAC
	driver DO NOT PROCEED. The NDIS MAC drivers can be found in the drivers
	floppy that came with your network card. It may also be downloaded from
	from many internet sites if you want it free. Many vendors also have 
	BBS's form where you can download the drivers for free. If you feel like
	paying money for the same drivers you may download from COMPUSERVE.
	*************************************************************************

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

	STEP 1:

		Create \wintcp directory. It is hardcoded for now.
			mkdir c:\wintcp

		Unzip wintcp.zip into \wintcp. Use the -d option since the \wintcp\etc
		directory must to be created.
			pkunzip -d wintcp.zip

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

	STEP 2:

		If you are already running NDIS drivers for some other reason such as
		MS Lan Manager, things will be easy. Go directly to STEP 3. If not
		do the following.

		The NDIS drivers need at least three entries in your config.sys and
		one entry in your autoexec.bat file. Also, the configuration of
		NDIS is read in from the file protocol.ini (located in c:\wintcp in
		our case).

		Modifying config.sys:
			Add the following lines to your config.sys.
DEVICE=C:\wintcp\PROTMAN.DOS /I:C:\wintcp
DEVICE=C:\wintcp\ELNKII.DOS

# Line 1:	The protocol manager driver. /I: parameter tells it where to find 
			protocol.ini
# Line 2:	The NDIS MAC Driver for your card. Replace ELNKII.DOS with the 
			driver for your own card.

	Create the protocol.ini file in c:\wintcp with a text editor. You need
	entries in this file for at least the network card driver( NDIS MAC Driver
	for your card) and the dis_pktw.dos hook for wintcp.

	Make the right entries in the c:\wintcp\protocol.ini file for your
	NDIS MAC driver.  Shown below is the protocol.ini entry for the ELNKII
	card as suggested by 3COM. For other card there usually is a sample
	protocol.ini file somewhere in the drivers floppy which will give you
	an idea.

[EtherLinkII]
DRIVERNAME=ELNKII$
INTERRUPT=5
TRANSCEIVER=OnBoard
IOADDRESS=0x300

	Add the following line to your autoexec.bat.

c:\wintcp\netbind

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

	STEP 3:

		Add the following lines to your protocol.ini file.

[pktdrv]
drivername=pktdrv$
# Replace EtherLinkII with the name your network driver.
bindings=EtherLinkII
# The interrupt vector to use. NOTE THAT THE NEXT HIGHER VECTOR IS ALSO USED.
intvec=0x60
chainvec=0x66

		Add the following to your config.sys after the entry for protocol.dos
		and the network card.

DEVICE=c:\wintcp\dis_pktw.dos

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

	STEP 4:

	Add c:\wintcp to your path.

	Reboot so that your drivers get loaded and path is set.
	If any of the drivers you added complain or if netbind complains that it
	cannot bind you need help configuring the NDIS drivers.

	ENSURE THAT NO OTHER WINSOCK.DLL FROM ANY OTHER SOURCE IS IN THE PATH
	BECAUSE THE MOST COMMON PROBLEM SEEMS TO BE OUTDATED/INCORRECT
	WINSOCK.DLL KICKING IN WHEN ANY APP REQUESTS WINSOCK SERVICES.
    ----------------------------------------------------------------------------

	STEP 5:

	Add the following lines to your \windows\system.ini file in the 
	386Enh section.

device=c:\wintcp\wintcp.386
WINTCP_INT=60
			|
			|--->	Same as the entry in your protocol.ini file. BUT LEAVE OUT
					THE 0x part. Also remember that the next vector is used
					as well. Unless you have a really compelling reason, do not
					change the vector from 60. I have had problems running it
					at very high vector numbers.

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

	STEP 6:

	- Start windows.
	- Run c:\wintcp\tcpx either from file manager, run menu or create an icon
	  in you favourite group and click on the icon.
	- Use the Setup... menu item to setup the local host information
	  you have( hostname, IP Address, Netmask, Broadcast mask and default 
	  router(optional). ) You will be warned that you need to REBOOT windows
	  in order for your configuration information to be activated. But before
	  rebooting you may add host entries in your local hosts file.
	- Using the Setup... item in the main menu and add host information to
	  add the names of hosts that you are planning to use. DNS has not been
	  implemented in this release. Please bear with the inconvenience of using
	  a local hosts file for now.
	  	----------------------------- NOTE ---------------------------------
		The local hosts file resides in /wintcp/etc and is of the same
		format as the unix /etc/hosts file. You may setup minimal hosts
		using tcpx. Then ftp into your unix server and  get the /etc/hosts
		file. concat the /wintcp/etc/hosts file and the hosts file you just
		downloaded to form the new /wintcp/etc/hosts file. If your network
		uses NIS(YP) then telnet into the server and do "ypcat hosts > hosts"
		and download and concat this file into your wintcp/etc/hosts file.
		---------------------------------------------------------------------
	- Quit tcpx.
	- EXIT AND RESTART WINDOWS.
	- Your winsock tcp software is now ready. TCPX Need not be running for
	  you application to get winsock services.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

							APPENDIX  A

							FILE FORMATS

	The following files are used by wintcp for its configuration info.
	They are all in the wintcp/etc directory and closely resemble 
	corresponding unix system files. In general you may modify any of these
	files using a text editor, but you will probably have to restart windows
	for any changes to take effect.

	/wintcp/etc/hostname.e0:
		Configuration information for ethernet0, the first ethernet card in
	the system. Multiple interface support will soon be added. Contains three
	lines exactly. First line contains hostname, second line contains IP
	Address and third line contains the netmask. NO COMMENTS ALLOWED IN THIS
	FILE.It is parsed by a stupid parser in the VxD. Comments in this file
	are a luxury I  cannot afford. Example file contains:

calvin
167.28.1.2
255.255.0.0


	/wintcp/etc/services:
		Standard BSD /etc/services file with service port number entries.
	wintcp comes with the BSD standard services default file. To add entries
	you need to get the format from some unix system.

	/wintcp/etc/hosts
		Standard BSD /etc/hosts file. Comments are allowed. You can obtain
	hosts file from your local unix box and concat it to /wintcp/etc/host.

	/wintcp/etc/route:
		Standard route information file. Unix style. Refer to your unix
	box documentation for info on /etc/route.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

							APPENDIX B
							COPYRIGHTS

WINTCP includes several components built from publicly available sources
primarily from the BSD Net/2 release. The following Copyrights are relevant.

/*
 * Copyright (c) 1982, 1986 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 the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. All advertising materials mentioning features or use of this software
 *    must display the following acknowledgement:
 *	This product includes software developed by the University of
 *	California, Berkeley and its contributors.
 * 4. 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 BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 *
 *	@(#)tcp.h	7.7 (Berkeley) 6/28/90
 */

	The dis_pktw.dos driver is a modified version of the ndis shim and its
	copyright notice is included below.

; DIS_PKT.ASM - Adapter provides Packet Driver v1.09 interface over NDIS.
; Version 1.07  18 May 1991  by Joe R. Doupnik, Utah State Univ.
; Version 1.08  9 Aug 1991 by Dan Lanciani, ddl@harvard.harvard.edu
; Version 1.09  3 Nov 1991 by Joe R. Doupnik, Utah State Univ.
; Copyright (C) 1988 - 1991 FTP Software, Inc.
;
; This unmodified source file and it's executable form may be used and
; redistributed freely.  The source may be modified, and the source or
; executable versions built from the modified source may be used and
; redistributed, provided that this notice and the copyright displayed by
; the exectuable remain intact, and provided that the executable displays
; an additional message indicating that it has been modified, and by whom.
;
; FTP Software Inc. releases this software "as is", with no express or
; implied warranty, including, but not limited to, the implied warranties
; of merchantability and fitness for a particular purpose.
;
; USE AT YOUR OWN RISK.
;

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 1993 17:51:03 -0500
From:      peveritt@ncts.navy.mil (LTJG Paul Everitt)
To:        comp.protocols.tcp-ip
Subject:   Whois++

I have seen several references to whois++.  Anyone want to shed some 
light on this -- what is it, what is its status?  The RFCs make the 
case for X.500.

Paul.Everitt@ncts.navy.mil


-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12 Sep 1993 10:57:29 GMT
From:      andrew@megadata.mega.com.au (Andrew McRae)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewalls could help put off the IP address shortage

From article <25stoi$ie0@neon.rain.com>, by jeff@neon.rain.com (Jeff Beadles):
> koreth@spud.Hyperion.COM (Steven Grimm) writes:
> 
> ....
>>Then it occurred to me: Why can't nets behind firewalls use the entire IP
>>address space as they see fit?  All they need to be able to do is route to
>>the firewall (or a secondary firewall -- more on that in a sec) to get mail
>>out, establish connections via proxy-telnet servers, and so on.
>>is it if Xerox uses, say, Hyperion's net number of 192.65.216 internally,
>>since no routing information is propogated outside of Xerox?
> 
> This won't work.
> 
> Now, if all sites behind firewalls used the same IP addresses,
> and you removed all incompetent sysadmin's who would do things like
> leak routing and DNS information, & stuff, then you might have a chance
> in making something like this work.  I doubt it though, if past
> performances are any indication.

The problem is, how do you allocate localised IP addresses that are
guaranteed to be unused elsewhere on the (visible) net, but have
enough space to allocate your own subnets etc. It seems to me that
any use of Class A, B or C is fraught with problems, so why not
use Class D. I am aware that Class D is somehow tied up with
multicast IP, but I would have thought multicast IP is not a widely
distributed technology (yet).

All these ideas, though, seem to fiddle about at the edges of the
problem, and smell of too much kludge. The best way to deal with
a problem of this magnitude is not to introduce a quick-fix
solution that may make it even harder in the future to migrate
to a new scheme.

Cheers,
Andrew McRae			inet:	andrew@mega.com.au
Megadata Pty Ltd,		uucp:	..!uunet!mega.com.au!andrew
North Ryde  2113		Phone:	+61 2 805 0899
NSW    AUSTRALIA		Fax:	+61 2 887 4847

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 1993 20:22:34 -0500
From:      peveritt@ncts.navy.mil (LTJG Paul Everitt)
To:        comp.protocols.tcp-ip
Subject:   Re: Whois++

In article G71@ra.nrl.navy.mil, atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
> In article <27094n$ldu@terminator.ncts.navy.mil> peveritt@ncts.navy.mil writes:
> > The RFCs make the case for X.500.
> 
> WHICH RFCs make WHAT case for X.500 ?  
> 
>   There is widespread belief in the Internet that X.500 is too heavy
> for most uses.  The current InterNIC service provider has X.500 on the
> brain, but the facts are that X.500 is not currently in wide use and
> X.500 clients aren't widely available.

Ansswers:
RFC 1308 (FYI 13): "Executive Introduction to Directory Services 
		    Using the X.500 Protocol"
RFC 1309 (FYI 14): "Technical Overview of Directory Services
		    Using the X.500 Protocol"

Both are "products of the Directory Information Services(pilot) Infrastructure
(DISI) working group", and are dated March 1992.

However, I also have (dated 11/10/92) an draft memo from the WNILS Working
Group, entitled "Architecture of the Whois++ Index Service, which states:

	"This approach has been tried before, most notably in some 
	implementations of the X.500 standard. However, there are two 
	major flaws with the approach as it has been taken. This new 
	Index Service is designed to fix these flaws."

In any event, presuming whois++ is the right direction, can anyone
speak as to its status and implemenation?



-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 1993 20:40:26 -0400
From:      phil@clarknet.clark.net (Phil Anglin)
To:        comp.protocols.tcp-ip
Subject:   IP over cable tv

Would it be possible to run IP over a cable tv channel?
How much bandwidth does a cable tv channel have?


-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 93 19:22:59
From:      amoss@picton.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip
Subject:   Using xntpd as a broadcast client

Hello,

I know comp.protocols.time.ntp is the the place for this question but
no-one there answered it so I'm trying a broader forum.

I setup a regular xntp-3.1alpha xntp daemon on our network and configures
it to broadcast on the local net.  This works fine,  the clock on that
machine is very accurate and etherfind shows it broadcsts a packet every
64 seconds.

On another machine I tried to run xntpd as a broadcast client (basically
with "xntpd -b") but it doesn't hear anything.  etherfind on the same
machine DOES see the broadcast packets so I assume this is something in the
xntpd level.

The broadcast client is running under SunOS 4.1.3,  the broadcast server
runs under SunOS 4.1.2

Did anyone out there get xntpd work with broadcasts?  How?

Thanks,

--Amos
--
--Amos Shapira (Jumper Extraordinaire) | "War does not determine who is right,
C.S. System Group, Hebrew University,  |  but who is left"
Jerusalem 91904, ISRAEL                |
amoss@cs.huji.ac.il                    |                 -- Anonymous?

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12 Sep 1993 20:58:11 GMT
From:      sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: NCSA Telnet problem

In article <1993Sep9.050936.27841@iti.gov.sg> chchang@ncb.gov.sg (Chang Chen Hsien) writes:
>Hi,
>
>I am currently using NCSA Telnet 2.5 with MacTCP 1.1.1. We 
>have about 40 Macs on EtherTalk which using this application. 
>
>We have a problem of having intermittent pause (2 - 5 secs) when 
>using Telnet (during the Telnet session). Have anyone out there
>have the same problem or know how to resolve this ? If you do 
>have the problem or know how to solve it, please let me know.
>Thanks in advance !

Yes, I have had that problem as well... I have tried tracing it down in the
Unix system, but I can't find it anywhere.  The pauses only seem to be coming
up when running NCSA Telnet on a Mac.  The odds are that it is a bug of some
sort in the Telnet program.  The reason that I say this is that I have seen
quite a few other quirky behavious that occur with NCSA Telnet that does not
occur on VersaTerm or other programs (especially when running a curses program
on Unix...).

Scott
-- 
         Scott W. Adkins           Internet: sadkins@ohiou.edu
         ~~~~~~~~~~~~~~~                     ak323@cleveland.freenet.edu
    Ohio University of Athens        Bitnet: adkins@ouaccvma.bitnet

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12 Sep 1993 23:22:59 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Whois++

In article <27094n$ldu@terminator.ncts.navy.mil> peveritt@ncts.navy.mil writes:
> The RFCs make the case for X.500.

WHICH RFCs make WHAT case for X.500 ?  

  There is widespread belief in the Internet that X.500 is too heavy
for most uses.  The current InterNIC service provider has X.500 on the
brain, but the facts are that X.500 is not currently in wide use and
X.500 clients aren't widely available.



-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Sep 1993 02:08:06 GMT
From:      johnt@poolhall.win.net (John Tarbotton)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: New version of PC-TAR and TCP-IP libraries available

 
In article <1993Sep9.152441.18846@serra.unipi.it>, luigi@iet.unipi.it (luigi@iet.unipi.it) writes:
>
>All the above is available by anonymous ftp from
>
>       pical3.iet.unipi.it (131.114.9.12)
>
>in the directories
>       /pub/deit_wattcp (TCP-IP libraries) and
>       /pub/net_tar (the modified tar program)
>
Could you give a description of the files in the net_tar directory
as there where a couple files with dates as part of their names I
was not sure what all I needed to get.

THANX

                        ... johnt ...
                         


-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 1993 14:01:06 -0700
From:      schmidt@liege.ics.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip,comp.unix.solaris,comp.unix.internals
Subject:   Performance of TLI and sockets on Solaris

Hi,

	I've been doing some experimenting with TLI and socket
performance on our SPARCserver 1000 50Mhz, 135MIP 2-CPU box running
Solaris 2.2.  I'm getting some interesting performance differences
that seem to be consistent over multiple trials.

	The test program consists of 2 versions of the standard ttcp
benchmarking tool: one is the usual version using sockets and the
other a modified version using TLI.  Note that under Solaris 2.x, both
sockets and TLI are implemented as user-level libraries that interact
with various STREAMS modules, multiplexors, and drivers in the kernel
(unlike Sun OS 4.1.x, where sockets were system calls).

	Basically, the primary differences occur when large (e.g.,
~100k bytes) TCP buffer sizes are used in the performance
measurements.  In this case, the TLI version is consistently about 3/4
as fast the the socket version.  Here are the representative numbers:

------------------------( socket ttcp )--------------------
./sock-ttcp -s -r -f m -b 100000 -l 100000
ttcp-r: buflen=100000, nbuf=2048, align=16384/0, port=5001, sockbufsize=100000  tcp
ttcp-r: socket
ttcp-r: rcvbuf
ttcp-r: accept from 127.0.0.1
ttcp-r: 204800000 bytes in 12.92 real seconds = 120.97 Mbit/sec +++
ttcp-r: 2811 I/O calls, msec/call = 4.71, calls/sec = 217.64
ttcp-r: 0.1user 5.1sys 0:12real 40%
----------------------------------------

------------------------( TLI ttcp )--------------------
./tli-ttcp -s -r -f m -b 100000 -l 100000
ttcp-r: buflen=100000, nbuf=2048, align=16384/0, port=5001, sockbufsize=100000  tcp
ttcp-r: t_open
ttcp-r: rcvbuf
ttcp-r: t_accept from 127.0.0.1
ttcp-r: 204800000 bytes in 17.03 real seconds = 91.77 Mbit/sec +++
ttcp-r: 26535 I/O calls, msec/call = 0.66, calls/sec = 1558.47
ttcp-r: 0.8user 7.3sys 0:17real 47%
----------------------------------------

	Does anyone know what would lead to such a disparity in
performance?  Perhaps the fact that TLI is MT-safe whereas sockets
aren't might have something to do with this?  It will be interesting
to see what might happen when Solaris 2.3 arrives (where sockets are
apparently also MT-safe).
	
	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

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Sep 1993 02:55:48 GMT
From:      sh7000157@ntuvax.ntu.ac.sg
To:        comp.protocols.tcp-ip
Subject:   Talk Daemon on PC?

Hi,

I'm looking for a talk daemon(TSR would be more appropriate perhaps)
that will run on a PC.  I have manage to compile the unix talk code(client)
and now I need a talk daemon to run on my PC to test it.
Could somebody please advise where I can get the talk daemon.(public
domain preferably)

Thanks.

Sim Huat
(sh7000157@ntuvax.ntu.ac.sg)


-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 93 04:35:05 GMT
From:      brianhe@eve.atm.com (Brian Henry)
To:        comp.protocols.tcp-ip
Subject:   Re: "Promiscuous-mode" token ring controllers

In article <26t148$s6i@liege.ics.uci.edu> schmidt@ics.uci.edu (Douglas C. Schmidt) writes:
>	I've used the promiscuous-mode feature of our Ethernet
>controllers to track protocol behavior on our local subnet.  I'm
>curious whether this type of promiscuous-mode behavior is also

I think that it is theoretically possible (from an electrical signal
standpoint) for any token ring card to do this.  However, the firmware
on the card usually prohibits looking at any packet but those
addressed to you.

The exception that I know of is the IBM TAP (Trace and Performance)
card, which does exactly what you are talking about.  It has special
firmware on board to allow it to do this.


-- 
-------------------------------------------------------------------------
brianhe@atm.com		Brian L. Henry
			Software Engineer, Attachmate Corp., Bellevue WA

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Sep 1993 06:35:35 GMT
From:      michelg@wang.com (Michel Godfroid)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over cable tv

phil@clarknet.clark.net (Phil Anglin) writes:

>Would it be possible to run IP over a cable tv channel?
>How much bandwidth does a cable tv channel have?
Here in Europe, some companies have a bandwidth of over 400 Mhz. They use 
selective amplifiers though, so total effective is probably much less.
(and they are one-way, so you would run into problems).
There are a number of implementations of Ethernet over the cable technology.
Most of them run a number of ethernet channels over the broadband.
you may want to investigate solutions from Ungermann-Bass, Chipcom,
and Wang Labs (Wangnet) (a plug for my own company :-).
--
Michel Godfroid, Wang Laboratories, Belgium (michelg@wang.com)

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Sep 1993 13:00:04 GMT
From:      pbachman@scott.skidmore.edu (peter bachman)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over cable tv

I suppose most everyone has seen the article regarding Cablevision and
PSI to provide IP in Boston by year end?

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Sep 93 13:27:23 GMT
From:      anir@nynexst.com (Anirban Chowdhuri)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   TCP Problems on PC Clients




I have been having a problem with PC clients communicating with UNIX
servers, upon their abnormal termination (PC application crashes,
system reboots, etc.). It seems like the indication of the client's
crash, or non-existance, is never received by the server, or when 
something is at all received, it is entirely mangled. 


I have heard from some people that this has been encountered as a 
TCP driver problem/bug(?) for PC clients in client-server setups.

Any thoughts on this problem, possible workarounds would be appreciated.


Thank you.


Regards,



Anirban Chowdhuri

NYNEX Science & Technology, Inc.
500 Westchester Avenue
White Plains, NY 10604

Phone:	(914) 644-2481
E-mail:	anir@nynexst.com

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Sep 1993 14:08:45 GMT
From:      gba@lucy.trnet.bb.softpro.de (Giovanni Baruzzi)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI and TCP

dsathyan@uncc.edu (Deepa Sathyan) writes:


> My question is this (whew!):
>How do I get of  a t_rcv loop on the server side without issuing a
>disconnect signal?  
 
>I have  a tried a couple of things to solve this problem, to no avail.
>If anyone is interested, I can
>send her/him mail of my (mostly futile) efforts. 

I read also the other answer to this. In my opinion it would be much
better to subdivide the session you just created by using the concept
of conversations. Although this concept is derived from SNA, it proves
to be useful for many different things.
You may want to add an header to every message (that could span several
transport blocks) and define a tini protocol between the server and the client,
storing function code, options and return codes in this header.
Although not a standard soluntion, it proves to be very efficient
and EXPANDABLE for many client/server applications.


>I would greatly appreciate an answer. Thanks.
>Deepa
Let me informed by mail if your efforts are successful.

Ciao,
Giovanni

-- 
Giovanni Baruzzi, gba@softpro.de, IBMMAIL: DEJP9VK9@IBMMAIL
SOFTPRO GmbH - Stadtgrabenstr. 21 - D-71032 Boeblingen (Germany)
TEL: +49-7031-660645 FAX +49-7031-660645


-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Sep 1993 14:40:37 GMT
From:      glenne@sad.hp.com (Glenn Elmore)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over cable tv

Phil Anglin (phil@clarknet.clark.net) wrote:
: Would it be possible to run IP over a cable tv channel?
: How much bandwidth does a cable tv channel have?

There was a company from the San Jose, CA area with a booth at InterOp
last month which was selling IP-over-CATV.  They were using a standard
channel width (6 MHz) above the normal 40 to provide one-way 10 Mbps
data into their converter box.  Outbound data was currently via phone
line at much lower rates.
  Apparantly they approach cable TV suppliers in various areas and get a
channel above the standard band.  Things are starting to degrade within
there systems but evidently not badle enough to stop data.

  I don't remember the details but they had a couple of models and it
all appeared to be working and ready to sell (doesn't it always?).


Glenn Elmore 

N6GN @ K3MC      
amateur IP:	glenn@SantaRosa.ampr.org
Internet:	glenne@sr.hp.com 




-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 1993 15:06:46 GMT
From:      billy@utdallas.edu (Billy Barron)
To:        comp.protocols.tcp-ip
Subject:   Re: Whois++

peveritt@ncts.navy.mil (LTJG Paul Everitt) writes:

>In any event, presuming whois++ is the right direction, can anyone
>speak as to its status and implemenation?
>
From everything I've heard, it is vapor at this point.  The momentum
behind X.500 is picking up.  I think whois++ may just be too late to
matter.  In our case, we are going with X.500 because it is here and
it is possible to integrate it into our soon to be installed e-mail
system as well as via gopher.


--
Billy Barron,  Network Services Manager, Univ of Texas at Dallas
billy@utdallas.edu 

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Sep 1993 15:20:08 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over cable tv


	The one broad-band system I have seen uses 1 full channel for the
head-end and channel 4A for the return path.  In North America and a few
other parts of the globe, single channels are 6MHZ wide.  In Europe and
other places where PAL at 625 lines is used, the bandwidth is a little more.
I seem to recall, 7MHZ.  With some versions of SECAM, it can even be 8MHZ
per channel.  The one system I dealt with had a data throughput of 5MB/S
so it was not an Ethernet extender by any means.  

	For those who might be curious, channel 4A occupies the 4MHZ between
channel 4 and channel 5 in North America. It is the 72-76MHZ band which is
not wide enough for a full television channel

Martin McCormick WB5AGZ   Stillwater, OK
O.S.U. Computer Center Data Communications Group

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Sep 1993 15:58:13 GMT
From:      waynej@ncs.com (Wayne Johnson)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   sniffer/TDR recomendations

We are looking for a decent sniffer TDR combination.  Anyone got one they 
really like?  Or one thats a dog?

We need it for both network utilization monitoring but it would be handy
to diagnose cable breaks, etc.

Anyone know of IBM/RS6000 hardware/software to do this?

Thanks.
-- 
Wayne D. T. Johnson       Internet: waynej@ncs.com      Phone: (612) 830-7880
     National Computer Systems, 4401 West 76th Street,  Edina, Mn.  55435 
"He is no fool, who gives up what he cannot keep, for what he cannot lose"
                                           - Jim Elliott

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Sep 1993 16:29:35 GMT
From:      pcg@decb.aber.ac.uk (Piercarlo Antonio Grandi)
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   Numeric IP addresses: support them?

Hi, I am begging the local sysadmins to allow receiving and sending
mail by SMTP to sites that are not DNS-registered. Currently
the local MTA (PP) rejects mail from other MTAs which are not
DNS registered and flags as invalid To: lines sporting numeric
IP addresses.

I believe that this is bogus, both on practical and normative
grounds. Anybody out there care to support or contradict this
statement?

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Sep 1993 16:34:01 GMT
From:      schwartz@roke.cse.psu.edu (Scott Schwartz)
To:        comp.protocols.tcp-ip
Subject:   Re: Whois++

billy@utdallas.edu (Billy Barron) writes:
   From everything I've heard, it is vapor at this point.  The momentum
   behind X.500 is picking up.  I think whois++ may just be too late to
   matter.  In our case, we are going with X.500 because it is here and
   it is possible to integrate it into our soon to be installed e-mail
   system as well as via gopher.

At PSU, the comp center has decided to go with UIUC's qi/ph and gopher.
They spent a year of so flirting with X.500 before (as I understand it)
deciding that a lot of lip service is building up behind it, but that it
doesn't really do the job.  After one week of hacking ph was fully in
production, and yielded more functionality than the X.500 stuff had even
after considerably more effort was invested.


-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 1993 16:48:00 GMT
From:      mjr@tis.com (Marcus J. Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Whois++

>   The momentum
>   behind X.500 is picking up.

	Is this written in the context of, "As they grunted and
heaved, their sinews popping and straining, momentum began to
pick up, the huge edifice grinding slowly forward, nearer and
nearer to the edge of the cliff. A spontaneous cheer welled in
the throats of the workers, as they saw the end in sight"?

mjr.

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Sep 1993 16:56:41 GMT
From:      a722756@pan.mc.ti.com (W. Donald Rolph III)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: TCP Problems on PC Clients

In article <1993Sep13.132723.2415@nynexst.com> anir@nynexst.com (Anirban Chowdhuri) writes:
>From: anir@nynexst.com (Anirban Chowdhuri)
>Subject: TCP Problems on PC Clients
>Keywords: PC TCP Client
>Date: Mon, 13 Sep 93 13:27:23 GMT




>I have been having a problem with PC clients communicating with UNIX
>servers, upon their abnormal termination (PC application crashes,
>system reboots, etc.). It seems like the indication of the client's
>crash, or non-existance, is never received by the server, or when 
>something is at all received, it is entirely mangled. 


>I have heard from some people that this has been encountered as a 
>TCP driver problem/bug(?) for PC clients in client-server setups.
 
>Any thoughts on this problem, possible workarounds would be appreciated.


>Thank you.


>Regards,



>Anirban Chowdhuri
 
>NYNEX Science & Technology, Inc.
>500 Westchester Avenue
>White Plains, NY 10604
 
>Phone:  (914) 644-2481
>E-mail: anir@nynexst.com

If you think about this problem, by the nature of the pc crash (i.e. an 
unexpected termination), the pc cant send notification of status to the unix 
machine.

You can try running keep alive packets to ensure that failure of the pc 
is comprehended by the unix server.  

It is my understanding, however, that the general solution for this problem 
doesn't exist.  

This is the full employment progeam for network and unix admins! 


-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Sep 1993 17:38:27 GMT
From:      randy@psg.com (Randy Bush)
To:        comp.protocols.tcp-ip
Subject:   Re: Whois++

billy@utdallas.edu (Billy Barron) writes:
> From everything I've heard, it is vapor at this point.

Please don't tell my server and a few dozen others.  There are already four
separate free implementations available.  Like other lightweight competitors
to OSI monsters, Whois++ servers and services will outnumber the monsters in
a month or two.

> The momentum behind X.500 is picking up.

Someone spent the two person years putting up a second server?  :-)
--
randy@psg.com   ...!uunet!m2xenix!randy

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 1993 17:40:43 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   Re: Numeric IP addresses: support them?

In article <1993Sep13.162935.9452@aber.ac.uk>,
Piercarlo Antonio Grandi <pcg@aber.ac.uk> wrote:
>Hi, I am begging the local sysadmins to allow receiving and sending
>mail by SMTP to sites that are not DNS-registered. Currently
>the local MTA (PP) rejects mail from other MTAs which are not
>DNS registered and flags as invalid To: lines sporting numeric
>IP addresses.
>
>I believe that this is bogus, both on practical and normative
>grounds. Anybody out there care to support or contradict this
>statement?

Whip out your copy of "Requirements for Internet Hosts", RFC 1123:

      5.2.17  Domain Literals: RFC-822 Section 6.2.3

         A mailer MUST be able to accept and parse an Internet domain
         literal whose content ("dtext"; see RFC-822) is a dotted-
         decimal host address.  This satisfies the requirement of
         Section 2.1 for the case of mail.

The language of the RFC is very clear.  The "user@[1.2.2.3]" format
(a.k.a a "domain-literal" in the language of RFC 822) MUST be supported,
not only for local hosts, but other hosts.

--Dave
-- 
System Administrator, Penn State Population Research Institute
"A gentleman need not know Latin, but he should at least have
forgotten it."  Brander Matthews

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 1993 17:15:30 +0200
From:      szymon@galaxy.uci.agh.edu.pl (Szymon Sokol)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Fixed port # for ypserv, how?

Is it possible to force ypserv (SunOS 4.1.3 in particular, but any other NIS
implementation - HP, IBM, DEC - as well) to use a *given* port number?
I can check what port is used by ypserv using "rpcinfo -p", but this port 
seems to be different on different machines. I would like to filter out this
port number on our routers to prevent people from outside fetching our NIS
maps (namely passwd.byname and passwd.adjunct.byname :-( ). However, with 
several NIS servers, each of them using another port, this is rather tiresome
solution...
Thanks for any answers (including UTSL if you provide me the source to use ;-)
RTFM won't do, I have already tried and found nothing appriopriate).

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

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Sep 1993 20:37:38 GMT
From:      BERRYMAN@orca.drep.dnd.ca (DON BERRYMAN)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   UDP Broadcast Size Limit

I am attempting to BROADCAST UDP DATAGRAMS to all
nodes, from a HP735 HPUX9.01 The following code
does that for packets less that are less than
4328 bytes but gives the following error:

$ cc -o udp udp.c
$ udp
Sending 4320 
               Sent 4320
Sending 4328 
udp: Message too long
udp: unable to send request

If I change server.sin_addr.s_addr to INADDR_ANY
then I do not get this error but can only receive
the data on the local node. 

It seems that there is a limit on the size UDP
Broadcasts.  Is it possible to up this limit on my
node?  Or have I reached a limit in the actual UDP
definition that I can not work around?

My goal is to broadcast 4700 byte packets 32 times
per second.  I know this is 150kbytes/second and
might seriously degrade (or even kill) the local
ethernet but I am not incharge of system
specification.

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

#include <sys/types.h>
#include <sys/socket.h>
#include <sys/errno.h>
#include <netinet/in.h>
#include <stdio.h>
#include <signal.h>
#include <netdb.h>

extern int errno;
int sock;			/* socket descriptor */
struct sockaddr_in server;	/* for local socket address */

handler()
{
	signal(SIGALRM, handler);                         
}

main(argc, argv)

int argc;
char *argv[];
                                                         
{
	int i;
        int k, j, size;
        char buffer[10000];

	sock = socket (AF_INET, SOCK_DGRAM, 0);
	if (sock == -1) {
		perror(argv[0]);                                                
		fprintf(stderr, "%s: unable to create socket\n", argv[0]);
		exit(1);
	}
                                                                       
        i = 1;
        k = setsockopt (sock, SOL_SOCKET, SO_BROADCAST, &i, sizeof(i));

	server.sin_family      = AF_INET;
	server.sin_port        = 1456;                           

/*	server.sin_addr.s_addr = INADDR_ANY;     */  /* If used packets larger  than 4328 can be sent locally */
	server.sin_addr.s_addr = INADDR_BROADCAST;   /* If used packets smaller than 4328 can be broadcasted to all nodes */
                                              
	signal(SIGALRM, handler);  /* Set up alarm signal handler. */

        size = 4320;
        for (i=1 ; i<200 ; ++i) {

          fprintf(stdout, "Sending %i \n", size);               

          k = sendto (sock, &buffer, size, 0, &server, sizeof(server));

          if (k == -1) { perror(argv[0]);
		         fprintf(stderr, "%s: unable to send request\n", argv[0]);
		         exit(1);
	               }

          fprintf(stdout, "               Sent %i \n", k);

	  alarm(1);
          pause();
          size = size + 8;

        }
}



Don Berryman
Defence Research Establishment Pacific
Canadian Forces Base Esquimalt
Victoria, BC, CANADA, V0S-1B0
604-363-2731    604-363-2856fax
berryman@orca.drep.dnd.ca

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Sep 1993 21:24:06 GMT
From:      cpearce@nemesis.acs.unt.edu (Chris Pearce)
To:        comp.protocols.tcp-ip
Subject:   gated questions

This seemed like the best place to get the answer I seek. You guys are
tcp-ip experts,after all, and gated is tied closely to network administration.

HP 9000/710, HPUX 9.0.1.

I'm struggling with gated. My gateway machine learns routes okay, but
a local router on the same network is expecting to learn its default route
through rip, and I can't tell if its failure to do so is my or
its fault.

Here's the entry in question from my gated.conf

#
# Announce default via 192.246.58.2
#
propagate proto rip interface 192.246.58.2
{
	proto rip
	{
		announce default ;
	}
}

There is no interface qualifier on the second proto because the other
router, the one on the Internet side, doesn't send any rip packets. 

Should I use announce all instead of announce default?

Finally, my syslog is getting hundred of messages like:

Sep 13 10:14:20 maverick gated[123]: krt_delete_dst: task: ICMP: SIOCDELRT
192.246.58.38 via 192.246.58.38 flags <UP GW HOST DYN>: No such process

Does this message indicate that the gateway machine is getting rip packets
that tell it to delete routes that are not in its internal table? If I'm
getting lots of these, is it indicative of amore serious problem?

Finally, what mechanisms are there by which I can test my gated?
-- 
Chris Pearce -- cpearce@nemesis.acs.unt.edu
How do you say delicious?                          How do you say delovely? 
How do you say delectable, define?             How do you say - deGORgeous? 
How do you say dewith-it?                            How do you say Delite?

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Sep 1993 23:11:54 GMT
From:      hjb@netcom.com (hwajin bae)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over cable tv

In article <CDArFq.8Ht@srgenprp.sr.hp.com> glenne@sad.hp.com (Glenn Elmore) writes:
>There was a company from the San Jose, CA area with a booth at InterOp
>last month which was selling IP-over-CATV.  They were using a standard
>channel width (6 MHz) above the normal 40 to provide one-way 10 Mbps
>data into their converter box.  Outbound data was currently via phone
>line at much lower rates.

for more info, ftp to hybrid.com.  get FAQ file.
or call hybrid networks in cupertino, ca.

>
>  I don't remember the details but they had a couple of models and it
>all appeared to be working and ready to sell (doesn't it always?).
>

sbus card version should be available already.
the model 100 (standalone) should be available soon, if not already.

>
>Glenn Elmore 
>
>N6GN @ K3MC      
>amateur IP:	glenn@SantaRosa.ampr.org
>Internet:	glenne@sr.hp.com 
>
>
>


hjb@hybrid.com
--
Hwajin Bae (hjb@netcom.com)
Peaceful Star Consulting, Oakland, CA	(vox) 510.536.7607  (page) 510.466.9166

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Sep 1993 23:52:48 GMT
From:      gryphon@openage.openage.com (The Golden Gryphon)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over cable tv

phil@clarknet.clark.net (Phil Anglin) writes:

>Would it be possible to run IP over a cable tv channel?

Yes.

>How much bandwidth does a cable tv channel have?

3.3 Mbps.  This is about 1/3 of ethernet and there are all sorts of
problems with it.  First is that you need 2 channels, one for send and one for
receive.  

It can be done, but it is not a fun task.

-- 
The Golden Gryphon 				gryphon@openage.COM
"I'd put my two cents in, but I'm afraid they would tax me on it" -Me
			 This space for rent.
Openage - The Premier SCO UNIX integrator in the Washington D.C. area

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 1993 11:38:32 -0700
From:      schmidt@liege.ics.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip
Subject:   Re: What book is considered the TCP/IP "Bible"

++ In article <babb-130993173054@larc.sdsu.edu>,
++ Jeff Babb <babb@sciences.sdsu.edu> wrote:
++ Need to learn about TCP/IP protocols post haste. Sub sez all. Thanks.
++ Jeff.

Depending on whether you want to do with your knowledge, you might
want to check out several different sources (given enough time, you
might want to check them all out ;-)). 

----------------------------------------
1. For info on the protocols qua protocols, you might consider:

	"Internetworking with TCP/IP Volume I: Principles, Protocols,
	and Architectures" by Douglas Comer (Prentice Hall, 1991)

2. If you also are interested in implementing the protocols, you
   might check out:

	"Internetworking with TCP/IP Volume II: Design,
	Implementation, and Internals" by Douglas Comer and
	David L. Stevens (Prentice Hall, 1991) 

        as well as the relevant RFCs such as 768 (UDP), 791 (IP), and
	793, 1122/1123, 1072, 1185, 1191, 1323 (TCP-related RFCs)

3. If you are going to be programming distributed applications
   (at various levels of abstraction) some good books are:

	"UNIX Network Programming" by W. Richard Stevens (Prentice
	Hall, 1990)

	"UNIX System V Network Programming" by Steve Rago (Addison
	Wesley, 1993)

	"Internetworking with TCP/IP Vol III: Client -- Server
	Programming and Applications" by Douglas Comer and
	David L. Stevens (Prentice Hall, (socket version 1992,
	TLI version 1993)

4. If you're going to be administering a TCP/IP network,
   a good reference to check out is

	"TCP/IP Illustrated" by W. Richard Stevens (Addison Wesley,
	1993)

5. If you plan to consult on strategic directions of networking
   (or if you want to engage Marshall Rose in the next 
   great Interop debate ;-)) you might check out

	"Open Systems Networking, TCP/IP and OSI" by
	David M. Piscitello and A. Lyman Chapin (Addison Wesley,
	1993)
 
6. If you are planning to do research on high-performance 
   communication subsystems the following book (due out soon)
   would be handy:
   
   	"Gigabit Networking" by Craig Partridge (Addison Wesley,
	1993)

7. If you are interested in security aspects, there's a book
   due out sometime in the near future:
   
   	"Firewall Gateways and Internet Security" by Bill
	Cheswick and Steven M. Bellovin (Addison Wesley, 199?)

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

	Needlesstosay, there are scads of other books available on
this topic as well.  These are just some of the ones that I've found
particularly useful for my work.

	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

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 1993 00:27:08 GMT
From:      babb@sciences.sdsu.edu (Jeff Babb)
To:        comp.protocols.tcp-ip
Subject:   What book is considered the TCP/IP "Bible"

Need to learn about TCP/IP protocols post haste. Sub sez all. Thanks.
Jeff.

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 1993 08:49:29 -0400
From:      patelk@basfegw.basf-corp.com (Kalpesh Patel)
To:        comp.protocols.tcp-ip
Subject:   Running X based application in firewall setup

Hello, 

Like many organizations we have the firewall setup for accessing 
the Internet. The internal machine runs DNS which resolves the names for
internal hosts. The external host resolves names for the Internet hosts.
We are using unofficial IP addresses for the internal network. I have some
issues regarding running X based applications in this setup:

1. How to run X based application like xmosaic, xarchie etc. on the internal
host since name resolution and routing are going to be a problem?

2. Is there any way name resolution can be done on external host and routing
decision be made in each X application?

3. Does any commercial product exist which can solve this problem?

4. How to make routing decision on the internal host? (route to 
the internal net or to the Internet)

Any input is appreciated.

Kalpesh Patel
BASF Corp.
***********************************
All the standard disclaimers apply.

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Sep 1993 03:18:20 GMT
From:      ben@rex.uokhsc.edu (Benjamin Z. Goldsteen)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Re: NcFTP 1.53 problem - terminfo.

tstark@clark.net (Tim Stark) writes:

>Everyone:
 
>     On my Solaris 2.2, I installed NcFTP 1.53 software without any problems
>successfully. When I run it, I saw '$<2>' everywhere around NcFTP messages.
>What's up? I debugged them on both terminfo and ncftp. I found no $<2>
>word in its source code but found it in terminfo database! There are
>$<2> in vt100 terminfo entry. How do I filter them out before print them
>out? Which apporiate routines should I use for $<n> to being intrepret for
>delay time? I need your help! I never heard of $<n> before.
 
>     Or I have modify termcap_get routine to filter out $<n> commands.
 
>     Everything works on Solaris 2.2 very well execpt $<n> printouts. :(
>That is annoying to me.

     I too found this problem.  $<XX> is amount of delay need for the
terminal to execute a command, (i.e., how long it takes a dumb terminal to
clear the screen -- it actually calculable amounts of time not too long
ago).  It seems that NcFTP does not parse the output of terminfo correctly. 
From what I can tell, NcFTP was written for termcap so I simply told it to
use that as I like to configure programs to use what they are written for
(on the other hand, you have to maintain two databases -- termcap and
terminfo; I have one program that works much better with termcap and I
really like that program so at this point it does not make much different
between having one program using termcap and two programs using termcap).

    This all assumes that Solaris has termcap.  DG/UX 5.4 has both, but all
DG supplied programs use terminfo.  On the other hand, their terminfo
database is not the greatest and applications like SAS simply supply their
own terminfo database (which includes more entires then I have seen on any
other UNIX platform) and an addendum to access capabilities that can not be
coded into terminfo..  Applications like WordPerfect do not use either --
they come with their own, "*.trs" files.  Someday, perhaps the UNIX world
will redo their character-cell interfaces -- replacing stty, termios,
terminfo, termcap, barf, etc.

-- 
Benjamin Z. Goldsteen

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Sep 1993 06:07:10 GMT
From:      vincent@cc.und.ac.za (Russell Vincent)
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   Re: Numeric IP addresses: support them?

In article <1993Sep13.162935.9452@aber.ac.uk> pcg@decb.aber.ac.uk (Piercarlo Antonio Grandi) writes:

>Hi, I am begging the local sysadmins to allow receiving and sending
>mail by SMTP to sites that are not DNS-registered. Currently
>the local MTA (PP) rejects mail from other MTAs which are not
>DNS registered and flags as invalid To: lines sporting numeric
>IP addresses.

PP rejects by default - you can change this (if you didn't know already). 
Add the following to your "smtp" entry of the tailor file:
   ininfo=sloppy

It's hidden somewhere in the manual!  :-)

 -Russell

--
Russell Vincent,  Computer Services, Univ. of Natal, Durban, South Africa
vincent@cc.und.ac.za

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Sep 1993 08:01:35 GMT
From:      dave@mizar.csis.dit.csiro.au (David Campbell)
To:        comp.protocols.tcp-ip
Subject:   Signalled by incoming data on socket


Can somebody please explain what it takes to get signalled by incoming
data on a socket?

The signals never arrive in the following code:

static void socketIO(int pid, ...)
{
	abort(); /* crash bang but never gets here */
}

static int serveClient(int fd)
{
	pid_t pid = getpid();

	/* Trap/enable socket signals */

	if(signal(SIGIO, socketIO) == SIG_ERR)
		return failure("SIGIO setting failed");

	if(setpgid(pid, pid) < 0)
		return failure("setpgid failed");

/*	if(fcntl(fd, F_SETFL, FASYNC) < 0)
		return failure("fcntl failed"); */

	if(ioctl(fd, SIOCSPGRP, &pid) < 0)
		return failure("ioctl failed");

	....

Thanks,
-- Dave Campbell

-- 
  +-----------------------------------------------+--------------------------+
  | Dave Campbell (dave@csis.dit.csiro.au)        |          |\     ____|\   |
  | Phone: + 61 6 275 0944   Fax: + 61 6 257 1052 | |\___   /\ \   / /    \  |
  | CSIRO Division of Information Technology      | | _  \ /  \ \_/ /  ____> |
  | Centre for Spatial Information Systems        | | |>  > __ \   / \ \___  |
  | GPO BOX 664          _--_|\                   | |__  /_/  \ \_/   \___/  |
  | CANBERRA ACT 2601   /      \                  |    \/      \/            |
  | AUSTRALIA           \_.--._/ <- Canberra      |  Get right, or get left! |
  |                           v                   |  Heb 2:3                 |
  +-----------------------------------------------+--------------------------+

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Sep 1993 10:25:44 GMT
From:      Jerry.Hagon@newcastle.ac.uk (J.P.Hagon)
To:        comp.protocols.tcp-ip
Subject:   Cost of small CDDI network


Hello 

We are in the early planning stages of designing a small network of UNIX
workstations for use in distributed parallel processing. We would like to
have the highest data transfer rates possible (within our budget) and were
wondering about a CDDI network with machines connected by shielded twisted
pair cable which I understand has a bandwidth close to 100 Mbit/s. 
Presumably the workstations making up the network would have to have 
CDDI interface cards. We would also want our network connected to the
campus ethernet probably via a dedicated bridge. If our network expands
we may also need to consider multiport repeaters and the like. Is this
just a pipe dream or can the infrastructure for such a network be set up
at a reasonable cost. The machines making up our network will almost
certainly be RS6000's, HP9000's and SUN Sparcs. Initially we are likely
to have about 10 machines on the network. Any approximate idea of how
much more expensive this would be than standard 10 Mbit/s ethernet?

                   thanks in advance

                                Jerry


-- 
===========================================================================
Jerry Hagon                    |  E-Mail:     
Solid State Physics Group      |  INTERNET  : Jerry.Hagon@newcastle.ac.uk
Dept. of Physics               |  Compuserve: 100014,2702
The University                 |                                      
Newcastle upon Tyne	       |  PHONE:    +44 91 2227380
NE1 7RU                        |  FAX:      +44 91 2227361
United Kingdom                 |
===========================================================================

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Sep 1993 10:28:36 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over cable tv

In article <1993Sep13.152008.8759@osuunx.ucc.okstate.edu>, 
martin@datacomm.ucc.okstate.edu (Martin McCormick) writes:

>	The one broad-band system I have seen uses 1 full channel for the
>head-end and channel 4A for the return path.  

The Tech U of Trondheim, Norway, has for years (since around 1980?) been
running Norway's largest LAN - when I was a student, I think they had
something like 1500 terminals/workstations - on a Sytek broadband net.

I am a software man - not into transmission technology, so take some of
this with a small grain of salt. But anyway: I think the net provides 60
channels of 7.5 MHz each; I believe that is the standard European CATV
channel width. During conferences at the U, they can allocate one or more
of the channels for CCTV. (The way newspapers are: During a conference a
few years back, the local paper reported that all students and staff 
could follow the presentations from their terminals all over the U. This
was in the days of monochrome, character oriented terminals...)

The Sytek net has a tree topology: It depends on a head end tranciever
that echoes data on a set of upstream channels to a set of downstream 
channels. At least this is how they do it for the Sytek "native" protocol
used for simple terminal adaptor boxes (with RS-232 connectors); it migth
be different with eg. Ethernet.

For the Tech U network, the majority of the cables are plain coax, but 
some sections of it are optical fiber.

>The one system I dealt with had a data throughput of 5MB/S
>so it was not an Ethernet extender by any means.  

But there *is* a 5 Mbps Ether standard, specially tailored to broadband 
networks. One (or more?) of the channels at the Tech U is most definitely 
allocated to Ethernet traffic. The adapter box accept/deliver data at a
rate of 10 Mbps on the workstation interface, but transmits 5 Mbps on the
broadband cable. Ethernet being asynchronous, this causes no problems.
(Except if some workstation contiuously offers 10 Mbps outgoing traffic -
but whether 5 Mbps being available is caused by other traffic taking the
other half or by the signalling speed being lower makes no principal
difference.)


-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 93 16:37:40 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Re: TCP/IP on Token Ring

	Maybe you need a comms program which speaks with ODI directly, such 
as MS-DOS Kermit. This runs over Token Ring et al. The framing expected is
very likely TOKEN-RING_SNAP. See the MSK doc mskerm.bwr for more details
on ODI and NET.CFG and other things. Anonymous ftp to kermit.columbia.edu,
cd kermit/a, or to netlab2.usu.edu cd kermit.
	Joe D.

In article <27579m$44l@hp4at.eunet.co.at>, paul@eunet.co.at (Paul Gillingwater) writes:
> Hi,
> 
> I've installed a Sun onto a Token Ring network that's running a variety
> of protocols, including DLC, SPX/IPX and IP.  When I run 
> 
> 	snoop -d tr0
> 
> I can see a variety of traffic including some IP addresses.  My problem
> is, I can't seem to ping anything successfully, nor can I telnet into
> the Sun from a PC running Novell LAN WorkPlace.
> 
> My question is: how does TCP/IP encapsulate inside Token Ring packets,
> when Source Routing is enabled?  The software I've installed (using ODI)
> seems to want an Ethernet_II frame, but my TR card will only support
> TOKEN-RING and TOKEN-RING_SNAP.
> 
> What type of encapsulation is the Sun expecting for incoming Telnet, and
> ICMP responses in general?
> 
> I've tweaked the obvious things, like adjusting the netmask, and I'm
> certain there are no IP address conflicts.  I'd appreciate any hints in
> helping me to get the Sun on the air.  The local Sun reps are very good
> at Ethernet, but we're a TR shop, and they're clueless.
> 
> Please e-mail!
> -- 
> Paul Gillingwater    
> Home system: paul@actrix.co.at (Waffle), Vienna, Austria (!= Kangaroos)
> ** If you read news with rn/trn, ask me about EEP! the friendly .newsrc editor!

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Sep 1993 11:16:13 GMT
From:      smart@actrix.gen.nz (Quentin Smart)
To:        comp.protocols.tcp-ip
Subject:   Lingering closes

Hello,
Can anyone tell me why when I do a shutdown and then a close on a
socket it lingers (on and on) the environment I am using is a NLM
under netware. As netware uses standard(?) BSD sockets this may be
something I'm doing rather than a quirk of netware.

I originally had a 
  shutdown(socket,1)
  close(socket)

but the port got stuck in a fin-wait condition so when I try to
re-bind I cannot (I'm rebinding to the same port on the same machine
as before)

So what I do now is set the linger:
 
    closeopt.l_onoff = 1;
    closeopt.l_linger = 0;
    setsockopt(s_handle,SOL_SOCKET,SO_LINGER,
               (char *)&closeopt,sizeof(closeopt));

    shutdown(socket,1)
    .... do some code
    close(socket)

  Looking with a sniffer this starts to close the socket waits for a
bit (send two FINS then pauses) thensends a RST.

Anyone help me here?

Thanks
Quentin
smart@actrix.gen.nz



-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 1993 12:45:21 GMT
From:      jstewart@cnri.reston.va.us (John W. Stewart III)
To:        comp.protocols.tcp-ip
Subject:   Re: What book is considered the TCP/IP "Bible"

In article <babb-130993173054@larc.sdsu.edu>,
Jeff Babb <babb@sciences.sdsu.edu> wrote:
>Need to learn about TCP/IP protocols post haste. Sub sez all. Thanks.
>Jeff.

Personally, I like "Internetworking with TCP/IP Volume I:
Principles, Protocols, and Architectures" by Douglas Comer
(Prentice Hall -- ISBN 0-13-468505-9).

/jws

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Sep 1993 17:13:52 EDT
From:      <JFL4@psuvm.psu.edu>
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Setting Up a Filtering Bridge for TCP/IP

I'm trying to configure a bridge to pass only TCP/IP (IP) traffic.
My feeling is that I should let only packets of type 0800 through
the bridge, but I don't know about ARP (0806) or possibly even
RARP (8035).  We'll have some devices on one side of the bridge that
need to get to a router interface on the other side of the bridge.

I'd appreciate some help here.

Thanks in advance for any help and advice.

Jeff Luck
Continuing and Distance Education
Penn State University
jfl4@omnibus.ce.psu.edu

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 1993 13:18:33 GMT
From:      net@cs.tu-berlin.de (Oliver Laumann)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: UDP Broadcast Size Limit

BERRYMAN@orca.drep.dnd.ca (DON BERRYMAN) writes:
> It seems that there is a limit on the size UDP
> Broadcasts.  Is it possible to up this limit on my node?

The size of UDP broadcast datagrams is usually limited by the
MTU of the network interface you are using, because broadcast
datagrams are not fragmented.  The MTU of ethernet interfaces,
for instance, is typically 1500 (see netstat -i); I don't think
you can increase this value.


By the way, your code can be improved a bit in a couple of places:

> 	server.sin_family      = AF_INET;
> 	server.sin_port        = 1456;                           

This should read

	server.sin_port        = htons(1456);

or your program won't work on machines with host byteorder != network
byteorder.

> /*	server.sin_addr.s_addr = INADDR_ANY;
> 	server.sin_addr.s_addr = INADDR_BROADCAST;

I don't think that using INADDR_ANY or INADDR_BROADCAST as the address
for broadcasts datagrams is a good idea (unless it's a test program).
You can't control which interface is used on a multi-homed machine
(besides, INADDR_BROADCAST doesn't work correctly in some UNIX versions).

A better solution is to obtain the interface list (by means of the
SIOCGIFCONF ioctl) and use the broadcast address of the interface
connecting to the network to which you want to send the broadcast
packets.

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Sep 1993 14:47:16 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: UDP Broadcast Size Limit

>> It seems that there is a limit on the size UDP
>> Broadcasts.  Is it possible to up this limit on my node?

Most Berkeley-derived implementations prohibit the fragmentation of a
broadcast datagram.  There's no technical reason, it's just a common
sense decision they made way back.  If you *really* don't mind the
performance implications, and have the sources, it's trivial to change;
just remove the following test in netinet/ip_output.c:

        /* don't allow broadcast messages to be fragmented */
        if ((u_short)ip->ip_len > ifp->if_mtu) {
                 error = EMSGSIZE;
                 goto bad;
        }

Rich Stevens  (rstevens@noao.edu)

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 93 19:51:19
From:      mccarty@add.itg.ti.com (Rick McCarty)
To:        comp.protocols.tcp-ip
Subject:   shutdown()

I'm getting core dumps in shutdown() on a SunOS 4.1.3 box from a zero
page read.  Here's what I know:

	-  I've used Purify against the application and can't find
	   anything trashing memory.  That doesn't mean something
	   bad isn't happening - but Purify is generally pretty
	   thorough.

	-  I've got a valid fd, so I've eliminated that as a problem.
	   And I've verified that it has not been trashed prior to
	   the call to shutdown().

	-  The network interface API I'm using opens the connection,
	   does its thing, and closes the connection all before
	   returning control to the application.  There's no opportunity
	   for the calling app to muck with things while the connection
	   is open.

	-  The API works fine linked into a different application -
	   shutdown() call and all.

	-  If I remove the shutdown() call things work fine.

Here's a pared down extraction of what I'm doing:

	static int CommandFD;		/* Command connection fd */

	...

	static void
	CloseConnection()
	{
	 ...

	  /*
	   * This call has generated core dumps for some unknown reason.
	   */
	  shutdown(CommandFD, 2);

	  close(CommandFD);
	  CommandFD = -1;
	  return;
	}

Has anyone seen a similar problem?  I'm clueless at this point.  It's probably
pilot error on my part, but at this moment I can't see the forest from the
trees.

Regards,

Rick

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 1993 15:19:03 GMT
From:      s29@osiris.cso.uiuc.edu (R Mills)
To:        comp.protocols.tcp-ip
Subject:   tn3270 source for sys v

Does anyone have any tn3270 source code that will compile on 
a sys V machine.  We are having problems porting the BSD code to Sys v
Some of the signals will not port and we are lost.

Help!

Please send your reply to don@scsmo1.attmail.com

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Sep 1993 16:18:20 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over cable tv


I guess I should be a little more specific in my descriptions.  The system
we used at Oklahoma State University for a while was an Ethernet bridge,
but its maximum throughput speed was 5MB/s.  Normally, this worked for
run-of-the-mill conditions, but it definitely would have been left in the dust
by any sustained blast of 10MB/s traffic.  I have no idea how large the
buffer was.

	The biggest problem we had with it was occasional cable plant failures
and more frequent operational failures of the bridge, the kind where it
either totally stops forwarding any packets or begans to intermittently
throw away data for no good reason.

	The most interesting failure we had happened when some technicians
from our local cable T.V. company were doing work in one of the wire rooms
in the Computer Center.  It seems that our data network had red tags on
the amplifiers and cables while cable television service in the building
used yellow or was it the other way?  The tec couldn't remember, either
and ended up giving free cable T.V. service to all the Ethernet modems for
most of a day before somebody finally figured out what was going on.  Now,
the tags are clearly labeled in writing as well as color coded.

	The issue is no longer a problem, because we were able to move data
services to fiber optics and shut down the broadband network.  We were never
really very happy with it.

Martin McCormick WB5AGZ   Stillwater, OK
O.S.U. Computer Center Data Communications Group

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Sep 1993 16:30:39 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   NCSA Telnet Sometimes Can't get DNS


When using NCSA Telnet on a PC, name server lookups sometimes fail as if the
name server was down.  It isn't down and config.tel is set for two nameservers.  Other times, it works like clockwork.  This system is on a 10baseT connection
and normally has beautiful connectivity.  Can anybody think what sort of
marginal timing situation or other problem might be causing this?  We have
seen it with more than one machine.  Other work stations and multi-user
systems experience no trouble when the PC's are choking and the PC'S do
make a successful connection when using Internet numbers.

Martin McCormick WB5AGZ   Stillwater, OK
O.S.U. Computer Center Data Communications Group

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 93 16:47:30 GMT
From:      lvandyke@balboa.eng.uci.edu (Lee Van Dyke)
To:        comp.protocols.tcp-ip
Subject:   Wanted: makefile to port Stevens' "Unix Network Programming" to Sun4

Has anyone ported the source from the above book to a sun4?

I've started to but there is no <netns/ns.h> file for the
/lib/idpopen.c.

Thanks,
Lee

--
Lee Van Dyke
      lvandyke@balboa.eng.uci.edu,
UUCP: infotec!Infotec.COM!lee@sunkist.West.Sun.COM

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Sep 1993 17:07:23 GMT
From:      evans@tsd.arlut.utexas.edu (Eric Evans x3364 (gardner))
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: UDP Broadcast Size Limit

BERRYMAN@orca.drep.dnd.ca (DON BERRYMAN) writes:

>I am attempting to BROADCAST UDP DATAGRAMS to all
>nodes, from a HP735 HPUX9.01 The following code
>does that for packets less that are less than
>4328 bytes but gives the following error:
 
>$ cc -o udp udp.c
>$ udp
>Sending 4320 
>               Sent 4320
>Sending 4328 
>udp: Message too long
>udp: unable to send request
.
.
.
>It seems that there is a limit on the size UDP
>Broadcasts.  Is it possible to up this limit on my
>node?  Or have I reached a limit in the actual UDP
>definition that I can not work around?

On SunOS and SCO UNIX, at least, I have sent (*not broadcast*) UDP 
datagrams of sizes up to 16000 octets.  UDP merely slaps on a header 
and passes this monster to IP, which segments it to fit over the local 
Ethernet.

However, to allow this I have had to change a kernel parameter the sets 
a limit on the largest block of data that can be passed from the user 
process to the OS via a socket or TLI call.  Each version of UNIX (or 
other OS) may do this in a different way, if it is even allowed.  If 
this limit is exceeded by a given datagram, then the send call returns 
an error.  I don't know about HPUX, though.

As for BROADCASTING, when I try to broadcast a datagram larger than 
the Ethernet MTU, my socket/TLI call throws it away and doesn't even 
return an error (at least on SCO UNIX).  If you think about it, it
doesn't make much sense to broadcast something larger than the LAN
MTU, since it's the LAN itself that provides the broadcast capability.
IP simply uses the local LAN's broadcast mechanism (if it has one)
whenever it needs to send a message to the IP broadcast address.

Hope this helps

-------------------------------------------------------------------------
Eric Evans                        evans@titan.tsd.arlut.utexas.edu
Applied Research Laboratory
University of Texas at Austin


-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Sep 1993 18:49:51 GMT
From:      bvelv@dbsoftware.com (Bernie Velvis)
To:        comp.sys.novell,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Novell & Banyan & TCP/IP

In article <1993Sep11.174322.21972@adi.com> khai@adi.com (S. Khai Mong) writes:
>From: khai@adi.com (S. Khai Mong)
>Subject: Novell & Banyan & TCP/IP
>Date: 11 Sep 93 17:43:22 GMT
>I have this application which uses Novell's TCP/IP API and compiled
>and linked with Novell's TCP/IP product.  This works fine on
>Novell client workstations.
>
>My question: Is there a chance that such an application will run on a
>client workstation that has _only_ Banyan and Banyan's TCP/IP software
>installed?  Is there any quick answer why it won't work?  (I am
>thinking of getting Banyan's TCP/IP software)
>
>
>
>
>-- 
>Sao Khai Mong  Applied Dynamics, 3800 Stone School Road, Ann Arbor, MI 48108
>Voice: (313) 973-1300x263      Fax: (313) 668-0012      E-mail: khai@adi.com  

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Sep 1993 19:17:53 GMT
From:      garipoli@tigger.jvnc.net (Lou Garipoli)
To:        comp.protocols.tcp-ip
Subject:   Where to find SLIP specifications

Anyone know where I can find detailed SLIP specifications?


-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 1993 19:38:45 GMT
From:      dawkins@bnr.ca (Spencer Dawkins)
To:        comp.protocols.tcp-ip
Subject:   Re: What book is considered the TCP/IP "Bible"

In article <275338$ddl@liege.ics.uci.edu> schmidt@ics.uci.edu (Douglas C. Schmidt) writes:
>
>++ In article <babb-130993173054@larc.sdsu.edu>,
>++ Jeff Babb <babb@sciences.sdsu.edu> wrote:
>++ Need to learn about TCP/IP protocols post haste. Sub sez all. Thanks.
>++ Jeff.
>
>Depending on whether you want to do with your knowledge, you might
>want to check out several different sources (given enough time, you
>might want to check them all out ;-)). 

Geezus Moose! How come nobody posts smart answers like this to MY posts
(and PLEASE don't tell me!) -- anyway, Doug's list is pretty encyclopedic.
The only addition I can make is that Craig Hunt's Administering TCP/IP
book (O'Reilly, I think 1992) is pretty good in the section 4 category,
especially if you use SUNs for your network servers. 
>
>----------------------------------------
>4. If you're going to be administering a TCP/IP network,
>   a good reference to check out is
>
>	"TCP/IP Illustrated" by W. Richard Stevens (Addison Wesley,
>	1993)
>

Thanks for the following pointer to what I'm sure will be an
excellent book when it comes out.

>7. If you are interested in security aspects, there's a book
>   due out sometime in the near future:
>   
>   	"Firewall Gateways and Internet Security" by Bill
>	Cheswick and Steven M. Bellovin (Addison Wesley, 199?)

I'd also look seriously at "Practical Unix Security" by Garfinkel/Spafford
(O'Reilly, I think 1991) and "UNIX System Security" by Curry (Addison-Wesley,
1992). Both are post-Morris Worm, and consequently have chapters on network
security from an administrator's viewpoint.

Spencer
-- 
------------------------------------------------------------------------------
-  Spencer Dawkins			Bell-Northern Research	             -
-  (214) 684-4827			P.O. Box 833871                      -
-  Internet: dawkins@bnr.ca		Richardson TX 75083-3871             -

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Sep 1993 19:56:36 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: makefile to port Stevens' "Unix Network Programming" to Sun4

> Has anyone ported the source from the above book to a sun4?
>
> I've started to but there is no <netns/ns.h> file for the
> /lib/idpopen.c.

Please read the README that comes with the source code.  Sun does not
provide the XNS protocols so you need to change one line in the Makefile.
The change is given in the README file.

	Rich Stevens  (rstevens@noao.edu)

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 1993 20:00:07 GMT
From:      mjo@iao.ford.com (Mike O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Re: Running X based application in firewall setup

In article <274ekp$6hl@basfigw.basf-corp.com>
patelk@basfegw.basf-corp.com (Kalpesh Patel) writes:

:Like many organizations we have the firewall setup for accessing 
:the Internet. The internal machine runs DNS which resolves the names for
:internal hosts. The external host resolves names for the Internet hosts.
:We are using unofficial IP addresses for the internal network. I have some
:issues regarding running X based applications in this setup:

etc.

"unofficial" -> not registered in the NIC?

You may wish to check out an application called xforward, which is
available via anonymous FTP from crl.dec.com:/pub/DEC/xforward.tar.Z.
How is it that your firewall talks to your internal hosts?  If there's
a conflict with a registered host somewhere else on the Internet, what
does your firewall want to do?

						...Mike

-- 
 Michael J. O'Connor           |  Internet:  mjo@fmsrL7.srL.ford.com
 Ford Motor Company, OPEO      |  UUCP:      ...!fmsrl7!opeo!mjo
 20000 Rotunda, Bldg. 1-3001   |  Phone:     +1 (313) 248-1260
 Dearborn, MI  48121           |  Fax:       +1 (313) 323-6277

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 93 20:31:20 GMT
From:      mdivax1!robinson@pobox.mot.com (Jim Robinson)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Broadcast Size Limit

Oliver Laumann (net@cs.tu-berlin.de) wrote:

>I don't think that using INADDR_ANY or INADDR_BROADCAST as the address
>for broadcasts datagrams is a good idea (unless it's a test program).
>You can't control which interface is used on a multi-homed machine
>(besides, INADDR_BROADCAST doesn't work correctly in some UNIX versions).

Under SunOS 4.1.1 it certainly did seem (to my surprise) that
INADDR_BROADCAST did not work. I traced the packet making its way to the
recipient hosts, but apparently being discarded by the IP layer. Assuming
I did not screw my testing up, why would Sun #define INADDR_BROADCAST when
it doesn't work? Hasn't the use of 0xffffffff as a broadcast address been
around long enough to expect that even a not-quite-current version of
SunOS such as 4.1.1 should do the right thing?

>A better solution is to obtain the interface list (by means of the
>SIOCGIFCONF ioctl) and use the broadcast address of the interface
>connecting to the network to which you want to send the broadcast
>packets.

I eventually did use the broadcast address of the appropriate interface
and, voila, worked like a charm.
-- 
Jim Robinson
robinson@mdd.comm.mot.com
{ubc-cs!van-bc,uunet}!mdivax1!robinson


-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Sep 1993 20:32:07 GMT
From:      card@sybus.com (James Card)
To:        comp.protocols.tcp-ip
Subject:   Re: What book is considered the TCP/IP "Bible"

In article <babb-130993173054@larc.sdsu.edu> babb@sciences.sdsu.edu (Jeff Babb) writes:
>Need to learn about TCP/IP protocols post haste. Sub sez all. Thanks.
>Jeff.


The Douglas E. Comer series of books is very good and easy reading (doesn't put
you to sleep).  There are three volumes to the "Internetworking with TCP/IP". The
first one describes TCP/IP and the second two have source code for various things
dealing with TCP/IP as well as text.

The card catalog entry in the Library of Congress (from the book) reads:

Comer, Douglas E.
	Internetworking with TCP/IP / Douglas E. Comer. -- 2nd ed.
		p. cm.
	Includes bibliographical references (v. 1, p. ) and index.
	Contents: vol. 1. Principles, protocols, and architecture.
	ISBN 0-13-468505-9 (v. 1)
	1. Computer networks.  2. Computer network protocols.  3. Data
	transmission systems.  I. Title.
	TK5105.5.C59  1991
	004.6--dc20					90-7829
							   CIP

Hope this helps.

jC

-- 
  __/o___~_                 James Card (Firmware Engineer)
 (________|  Nothin' like   Sybus Corporation
   @    @    top down       2300 Tall Pines Dr. Suite 100
             weather...     Largo, Fl  34641  (813) 535-6999

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Sep 1993 21:39:32 GMT
From:      macker@itd.nrl.navy.mil (Joseph P. Macker)
To:        comp.protocols.tcp-ip
Subject:   Re: Can you process a TCP header in 30 instructions?

In article <1993Sep6.165717.22204@acc.com>, art@acc.com (Art Berggreen)
wrote:

> In article <CCst3G.971@mcdata.com> ddb0248@mcdata.com (David Beal) writes:
> >When I took a tutorial from David Clark (MIT) at Interop last year,
> >he said that Van Jacobson had written a TCP implementation that
> >"processes a typical TCP header in 30 [machine language] instructions".
> >
> >I'm having a hard time convincing people that this is possible.
> >Does anybody know if this is documented anywhere?
> 
> I can believe it if this was using header prediction and the packet met
> all expectations for incoming header fields.  If the packet has some
> unexpected field, then longer code paths come into play.  I'm also
> assuming that this is JUST the header processing logic.  The neccessary
> buffer handling before and after header processing is extra (but still
> not significant).
> 
> Art

I believe your instructor was referring to Van Jacobsen header compression
work.  In that case, it is exactly as you stated.  A known header state
(related to a particular TCP connection) is expected and can be processed
on average very quickly.  This works well for SLIP and PPP like connections
which do not multiplex a large number of packet services.

-Joe

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 1993 21:50:14 +0200
From:      paul@eunet.co.at (Paul Gillingwater)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   TCP/IP on Token Ring

Hi,

I've installed a Sun onto a Token Ring network that's running a variety
of protocols, including DLC, SPX/IPX and IP.  When I run 

	snoop -d tr0

I can see a variety of traffic including some IP addresses.  My problem
is, I can't seem to ping anything successfully, nor can I telnet into
the Sun from a PC running Novell LAN WorkPlace.

My question is: how does TCP/IP encapsulate inside Token Ring packets,
when Source Routing is enabled?  The software I've installed (using ODI)
seems to want an Ethernet_II frame, but my TR card will only support
TOKEN-RING and TOKEN-RING_SNAP.

What type of encapsulation is the Sun expecting for incoming Telnet, and
ICMP responses in general?

I've tweaked the obvious things, like adjusting the netmask, and I'm
certain there are no IP address conflicts.  I'd appreciate any hints in
helping me to get the Sun on the air.  The local Sun reps are very good
at Ethernet, but we're a TR shop, and they're clueless.

Please e-mail!
-- 
Paul Gillingwater    
Home system: paul@actrix.co.at (Waffle), Vienna, Austria (!= Kangaroos)
** If you read news with rn/trn, ask me about EEP! the friendly .newsrc editor!

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 1993 01:44:04 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Setting Up a Filtering Bridge for TCP/IP

In article <93257.171352JFL4@psuvm.psu.edu> <JFL4@psuvm.psu.edu> writes:
>I'm trying to configure a bridge to pass only TCP/IP (IP) traffic.
>My feeling is that I should let only packets of type 0800 through
>the bridge, but I don't know about ARP (0806) or possibly even
>RARP (8035).  We'll have some devices on one side of the bridge that
>need to get to a router interface on the other side of the bridge.

You definitely need to pass ARP, since devices on the same ethernet network
can't talk to each other via IP unless they can first talk via ARP.  If
there's an RARP server on both sides of the bridge you don't need to pass
RARP.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Sep 1993 01:48:48 GMT
From:      westes@netcom.com (Will Estes)
To:        misc.forsale.computers.workstation,comp.protocols.tcp-ip,comp.dcom.servers
Subject:   WANTED: Livingston or DCA Dialup Router

I would like to buy two cheap, used Livingston dialup routers.
Alternately, I would be happy with DCA's software-only dial-up
router solution.  If you have either for sale please contact me 
by mail.

-- 
Will Estes		Internet: westes@netcom.com

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Sep 1993 04:32:46 GMT
From:      chchang@ncb.gov.sg (Chang Chen Hsien)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Another Telnet application ?

Hi,

Is there anyone out there knows about other free/shareware
Telnet beside NCSA Telnet ? If you know, can I have the 
ftp address ? Thanks in advance !

Cheers

chchang@ncb.gov.sg

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Sep 1993 13:40:22 -0400 (EDT)
From:      ERIC@SEARN.SUNET.SE (Eric Thomas)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc,bit.listserv.ibmtcp-l,bit.listserv.domain-l,mail.tcp-ip
Subject:   Looking for US site to act as secondary name server

This message is being posted on Behalf of Eric Thomas.  Please mail
any replies to this message to him.
---
I  am looking  for a  site in  the US  that would  be willing  to act  as
secondary name  server for the  LISTSERV.NET domain,  that I am  about to
register. The only purpose of this domain is to register a MX record that
will give Internet  users direct access to the GLX,  without having to do
...%LISTSERV.BITNET@...  After bringing  up this  issue with  EARN and  a
couple other people, it  was decided that it was better not  to rely on a
sub-domain of EARN.NET or any similar organization, given the uncertainty
of the future of NJE. In other words, if we teach users that the hostname
is LISTSERV.EARN.NET and EARN disappears in two years or is taken over by
the  RARE OU,  we  will have  a  hard time  re-teaching  everyone to  use
something else. Please reply directly to me.

Eric Thomas <ERIC@searn.sunet.se>




-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Sep 1993 11:13:30 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over cable tv

In article <270fhq$cvi@clarknet.clark.net> phil@clarknet.clark.net (Phil Anglin) writes:
>Would it be possible to run IP over a cable tv channel?
>How much bandwidth does a cable tv channel have?

Another option we have been using for years is Sytek, we
have dedicated one of our campus channels to this system
with its 9600 baud virtual links.  You can just run SLIP 
over it.  It was also used in the original PC-LAN

Now we are phasing it out, but it is suitable for wider
area communication and easily passes through standard
Jerold cable amplifiers.

But how much bandwidth is available?  Ted Rogers, Canada's
version of Ted Turner, owns our largest cable network, our
largest cellular phone network and part of our largest non-BELL
phone company.  Last year his cable company demonstrated a Gpbs 
data network connecting Toronto's banks over their cable connection.

Here, all of our neighbourhood cable heads are fibre connected
to the main office, and his people can use cable-phones to 
call any other cable phones on the cable system.  But our
equivalent of the FCC does not allow them to sell such a
voice service, at least not yet.

Good luck,
Erick


-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 93 19:21:21 PDT
From:      schow@neptune.calstatela.edu (Steven Chow)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: Another Telnet application ?

In article <1993Sep15.043246.16379@iti.gov.sg>, chchang@ncb.gov.sg (Chang
Chen Hsien) wrote:

> Is there anyone out there knows about other free/shareware
> Telnet beside NCSA Telnet ? If you know, can I have the 
> ftp address ? Thanks in advance !

Yes, there's a program called "Comet" from Cornell University that you can
use.  It's screen redraw is much faster than NCSA Telnet but I'm not that
fond of the rest of its interface.

Comet should be available via anonymous FTP from ftp.cit.cornell.edu
somewhere under the /pub/mac/comm directory.  I think the latest version is
2.1.7.

You can also use any Communications Toolbox-capable terminal communications
program (i.e Termy, etc.) with the TGE TCP Tool for telnets.
The TGE TCP CTB Tool is available via anonymous FTP from
sumex-aim.stanford.edu under the /info-mac/comm directory and also from
mac.archive.umich.edu under the /mac/util/comm/commtoolbox directory.

-- 
Steven Chow
schow@neptune.calstatela.edu

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 1993 12:34:14 GMT
From:      bab@se40.wg2.waii.com (Brian Button)
To:        comp.protocols.tcp-ip
Subject:   Recommendations for Network/Client-Server classes

We've been doing a little network programming around here lately, with
a bunch more on the horizon. I've read through "Unix Network
Programming", making my way through Comer's first book, to be followed
by his second book, but my management OK'ed my taking a course in this
topic if I can find one.

Never one to look a gift class in the mouth, I decided to see if
anyone out there in net.land knew of any good classes. I'd like a
class that was heavy in the programming area, and a bit light in
management, administration issues.

Thanks for any advice,
bab - Network Programmer in Waiting <g>
--
|-----------------------|----------------------------------------------------|
| Brian Button          | email : button@wg2.waii.com                        |
| Design Engineer       |         71023.276@compuserve.com                   |
| Western Geophysical   | voice : (713)964-6221                              |
| 3600 Briarpark        |----------------------------------------------------|
| Houston, Texas  77042 |                                                    |
|-----------------------|----------------------------------------------------|

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Sep 1993 15:11:12 GMT
From:      garyb@gcm.com (Gary Blumenstein)
To:        comp.protocols.tcp-ip,alt.internet.services,comp.dcom.lans.misc,comp.dcom.sys.cisco,comp.sys.sun.admin,comp.unix.admin
Subject:   Evaluating Internet Services


When evaluating the various ways to connect to the Internet, Susan
Estrada in her new O'Reilly book, _Connecting to the Internet_ suggests
having the service providor supply packet round trip times from two
given points where one site is outside the providor's regional network.
I would like to do just that sice I'm evaluating the performance of the
various products offered by Performance Systems International (PSI) and 
Advanced Network Services (ANS).

My question is this; Should I ask them to send ICMP echoes (ping) times
and what sites should I tell them to check when all I know are the top
level domain names of various sites out there?  I am located in
southern Connecticut, and ideally I would like to ping a site on the
west coast that is not directly connected to any PSI or ANS (NSFnet)
backbones.

Would anybody out there like to volunteer by sending me their system
name, IP number, and the name of their regional network (i.e. BARRNet, 
CERFnet).  I will have the two vendors measure and supply me with 
average packet round trip times and would be happy to share the results 
with you.

Many thanks.

-Gary


-- 
Gary Blumenstein    //   garyb@gcm.com    - Greenwich Capital Markets - 

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Sep 1993 15:26:19 GMT
From:      sobi0268@mary.cs.fredonia.edu (Kevin V. Sobilo)
To:        comp.protocols.tcp-ip
Subject:   Parallel SLIP???

	I saw in a FAQ somewhere that there exists some type of parallel SLIP such that
mutliple serial connections can be used.  Has anyone done this??? If so has anyone
done this on a MicroVAX??? Please post here or email me if you have experience with this
or know where I can find more information or an implimentation in which I can do this.

--

/					  \\				  \ 
|					   \\                              |
|	Kevin V. Sobilo			    \\                             |
|	sobi0268@mary.cs.fredonia.edu        \\  //   "Only Amiga Makes    |
|					      \\//     It Possible"        |
|					       \/                          |
|									   |
|									   |
 \==========================================================================/

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Sep 1993 16:03:46 GMT
From:      stwill@rchland.vnet.ibm.com (Steve Will)
To:        comp.protocols.tcp-ip
Subject:   Building IP headers

I hear that it is possible, using sockets, to build my own datagrams, even including
the IP headers, and try to ship them out.  Can anyone tell me how this is done?  What
values do I need to specify on the socket() call to get this ability?

-- 

Steve Will       (stwill@vnet.ibm.com or stevewill@vnet.ibm.com)

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 1993 17:21:10 GMT
From:      nam@peregrine.esl.com (Nam N. Nguyen)
To:        comp.protocols.tcp-ip
Subject:   SLIP for sunos4.1.3


I have got the cslip and slip version working on SunOS 4.1.1.  Now when
I upgrade my OS to 4.1.3, the same SLIP does not seem to work.

My setup:

	host a: a FORCE board running vxWorks 5.1, having SLIP of its own.

	host b: a Sparc 10 running sunos4.1.3, using previous SLIP (4.1.1).

If any netter has this problem or knows how to fix it, PLEASE help!

Thank you very much,

Nam N.





-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Sep 1993 17:22:04 GMT
From:      pcg@decb.aber.ac.uk (Piercarlo Antonio Grandi)
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   Re: Numeric IP addresses: support them?

On Tue, 14 Sep 1993 06:07:10 GMT, Russell Vincent (vincent@cc.und.ac.za) wrote:

  In article <1993Sep13.162935.9452@aber.ac.uk> pcg@decb.aber.ac.uk
  (Piercarlo Antonio Grandi) writes:

  >Hi, I am begging the local sysadmins to allow receiving and sending
  >mail by SMTP to sites that are not DNS-registered. Currently
  >the local MTA (PP) rejects mail from other MTAs which are not
  >DNS registered and flags as invalid To: lines sporting numeric
  >IP addresses.

  PP rejects by default - you can change this (if you didn't know already). 
  Add the following to your "smtp" entry of the tailor file: ininfo=sloppy

Thanks to you and everybody else that replied. The local sysadmins seem
to have been persuaded now, and they had indeed missed the ininfo=sloppy
directive...

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Sep 93 15:43:56 MEST
From:      matthias@oln.zer.de (Matthias Watermann)
To:        alt.winsock,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: ***** ODI Support For WINTCP - the VxD winsock, HERE IT IS ***

jagane@netcom.com (Jagane D Sundar) writes:

>

 WHERE is it? Your mail just contained one (single/empty) line :-(



	Matthias

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Sep 1993 18:00:36 GMT
From:      phuong@rocky.raleigh.ibm.com (Phuong Nguyen)
To:        comp.protocols.tcp-ip
Subject:   Re: Building IP headers

The book called UNIX Network Programming by W. Richard Stevens will walk
you through all this.  You can use puborder to order it.  It's number is
SC31-7004-00.
What you want is in the book, just get it and go from there.

*********************************
Opinions are mine not IBM's
Have a "phuongtastic" day,
Phuong Thanh Nguyen
Networking System.
PNGUYEN@VNET.IBM.COM
*********************************

In article <1993Sep15.160346.40807@rchland.ibm.com>, stwill@rchland.vnet.ibm.com (Steve Will) writes:
|> I hear that it is possible, using sockets, to build my own datagrams, even including
|> the IP headers, and try to ship them out.  Can anyone tell me how this is done?  What
|> values do I need to specify on the socket() call to get this ability?
|> 
|> -- 
|> 
|> Steve Will       (stwill@vnet.ibm.com or stevewill@vnet.ibm.com)

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Sep 1993 18:18:04 GMT
From:      ddk@beta.lanl.gov (David D Kaas)
To:        comp.protocols.tcp-ip
Subject:   Fibre Channel

Are there currently any Fibre Channel interfaces/switches
available to connect to workstations? Such as Sparc, RS6000
or HP.

Thanks

-- 
| Dave Kaas                         | Internet: ddk@lanl.gov               |
| Box 300 M/S A1-05                 |                                      |
| Boeing Computer Services Richland |                                      |
| Richland, Wa 99352                | Phone:    (509) 376-6386             |

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Sep 1993 19:42:18 GMT
From:      stwill@rchland.vnet.ibm.com (Steve Will)
To:        comp.protocols.tcp-ip
Subject:   Re: Building IP headers

In case anyone else was wondering:

Rich Stevens was kind enough to offer me the answer off-line.  My thanks to the person
who pointed me at Rich's book, but even Rich said this fact is not spelled out in the
current edition (though it will be in the next).  Here is Rich's answer.
--------------------------------------------------------------
Hi.  You need: socket(AF_INET, SOCK_RAW, IPPROTO_RAW);  Then whatever
you write to that socket descriptor is assumed to start with a valid
IP header.  You probably don't want to read on this descriptor,
however, as I don't think you'll get anything.  traceroute uses this,
one of these socket types for writing, and one with the final argument
IPPROTO_ICMP for reading.

	Rich Stevens 

-- 

Steve Will       (stevewill@vnet.ibm.com)

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 1993 20:10:51 GMT
From:      walt@unhsst.unh.edu (Walter R. Trachim)
To:        comp.protocols.tcp-ip
Subject:   gopher client for MS-DOS, MS-Windows, etc.

Subject says it all - does anyone know where I can find one?

Replies to e-mail are ok; I don't want to tie up bandwidth....

thanks in advance,

W
-- 
    Walter R. Trachim                                   walt_trachim@unh.edu
    University of New Hampshire      Telecommunications and Network Services
    Durham, NH 03824               603-862-4742 (Voice) / 603-862-2030 (Fax)
    ########################################################################
          "Answers are the easy part - questions raise the doubts."
						--Jimmy Buffett

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 93 20:17:21 GMT
From:      sean@applix.com (Sean Murphy [ext 332])
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Question: obtaining port numbers from pid...

I am looking for information regarding obtaining the udp and tcp port
numbers which a server is bound to and listening on. Someone mentioned
that such a tool existed out here somewhere at one time etc, which did this.

Please resond with any info to: sean@applix.com

Thanks,
Sean
----

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Sep 1993 20:49:09 GMT
From:      phuong@rocky.raleigh.ibm.com (Phuong Nguyen)
To:        comp.protocols.tcp-ip
Subject:   Re: Building IP headers

The book order number has been changed to SC31-7193-00 in puborder.  It's
a very good book for whoever works for networking programming.

In article <CDEq10.Iys@sernews.raleigh.ibm.com>, phuong@rocky.raleigh.ibm.com (Phuong Nguyen) writes:
|> The book called UNIX Network Programming by W. Richard Stevens will walk
|> you through all this.  You can use puborder to order it.  It's number is
|> SC31-7004-00.
|> What you want is in the book, just get it and go from there.
|> 
|> *********************************
|> Opinions are mine not IBM's
|> Have a "phuongtastic" day,
|> Phuong Thanh Nguyen
|> Networking System.
|> PNGUYEN@VNET.IBM.COM
|> *********************************
|> 
|> In article <1993Sep15.160346.40807@rchland.ibm.com>, stwill@rchland.vnet.ibm.com (Steve Will) writes:
|> |> I hear that it is possible, using sockets, to build my own datagrams, even including
|> |> the IP headers, and try to ship them out.  Can anyone tell me how this is done?  What
|> |> values do I need to specify on the socket() call to get this ability?
|> |> 
|> |> -- 
|> |> 
|> |> Steve Will       (stwill@vnet.ibm.com or stevewill@vnet.ibm.com)

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Sep 1993 21:15:18 GMT
From:      lees@austin.ibm.com (Lee Slaughter)
To:        comp.protocols.tcp-ip
Subject:   ICMP redirects; default gateways

Hello netland dwellers,

I have a couple of questions:

1. Is there ever a case when a host should listen to a 
   "non-authoritative" ICMP redirect? i.e. he gets this
   redirect from a gateway which is not the gateway he
   has been using for the destination in question? 
   Presumably he figures this is bogus info and ignores it. 
   BSD makes this check, among others, but is there some newer heuristic?

2. Someone is speaking to me of using 'proxy ARP' in a non-Comer
   sense, and a host uses one of his own interfaces for a default
   gateway. Is there indeed a routing scheme in which a host uses
   one of his own interfaces for a default gateway? If so, I'd 
   appreciate pointers to references.
   (this question is related to the first, as when a host has
    his own interface for a default gateway and receives a 
    redirect from, say, a router, he ignores it, because the
    redirect didn't emenate from his gateway..)

Thanking you in advance,

lee slaughter
lees@austin.ibm.com

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Sep 93 21:46:31 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: Building IP headers

In article <1993Sep15.194218.45125@rchland.ibm.com> stwill@rchland.vnet.ibm.com (Steve Will) writes:
>In case anyone else was wondering:
>
>Rich Stevens was kind enough to offer me the answer off-line.  My thanks to the person
>who pointed me at Rich's book, but even Rich said this fact is not spelled out in the
>current edition (though it will be in the next).  Here is Rich's answer.
>--------------------------------------------------------------
>Hi.  You need: socket(AF_INET, SOCK_RAW, IPPROTO_RAW);  Then whatever
>you write to that socket descriptor is assumed to start with a valid
>IP header.  You probably don't want to read on this descriptor,
>however, as I don't think you'll get anything.  traceroute uses this,
>one of these socket types for writing, and one with the final argument
>IPPROTO_ICMP for reading.
>
>	Rich Stevens 
>
>-- 
>
>Steve Will       (stevewill@vnet.ibm.com)

A couple of comments:

1. You need root privs (euid=0) for the socket() call above to work.
2. You should be able to read off a AF_INET, SOCK_RAW, IPPROTO_RAW socket, 
else how would network sniffers work? (I'm not sure about this though)


-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Sep 1993 21:47:40 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over cable tv

> The Tech U of Trondheim, Norway, has for years (since around 1980?) been
> running Norway's largest LAN - when I was a student, I think they had
> something like 1500 terminals/workstations - on a Sytek broadband net.

This is true. But nowadays more and more of the University (and the
R&D environment) are being moved behind their own routers - so it is
*not* one large LAN any more. This is a good thing. Also, we now have
an FDDI infrastructure which is (slowly) replacing the Sytek based
infrastructure.

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

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 93 23:01:04 GMT
From:      mdivax1!robinson@pobox.mot.com (Jim Robinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Building IP headers

Steve Will (stwill@rchland.vnet.ibm.com) wrote:
>In case anyone else was wondering:
 
>Rich Stevens was kind enough to offer me the answer off-line.  My thanks to the person
>who pointed me at Rich's book, but even Rich said this fact is not spelled out in the
>current edition (though it will be in the next).  Here is Rich's answer.
>--------------------------------------------------------------
>Hi.  You need: socket(AF_INET, SOCK_RAW, IPPROTO_RAW);  Then whatever
>you write to that socket descriptor is assumed to start with a valid
>IP header.  You probably don't want to read on this descriptor,
>however, as I don't think you'll get anything.  traceroute uses this,
>one of these socket types for writing, and one with the final argument
>IPPROTO_ICMP for reading.

If so, then for SunOS 4.1.3, either the man page for IP (section 4P) 
is incorrect, or the above is implementation dependent (like what isn't).

The man page says:

     Raw IP sockets are connectionless and are normally used with
     the  sendto  and  recvfrom  calls, (see send(2) and recv(2))
     although the connect(2) call may also be  used  to  fix  the
     destination for future datagrams (in which case the read(2V)
     or recv(2) and write(2V) or send(2) calls may be used).   If
     proto  is  zero, the default protocol, IPPROTO_RAW, is used.
     If proto is non-zero, that protocol number will  be  set  in
     outgoing  datagrams  and  will  be  used  to filter incoming
     datagrams.  An IP header will be generated and prepended  to
     each outgoing datagram; Received datagrams are returned with
     the IP header and options intact.

Note the last sentence.

-- 
Jim Robinson
robinson@mdd.comm.mot.com
{ubc-cs!van-bc,uunet}!mdivax1!robinson


-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 1993 23:19:37 GMT
From:      ahh@cisco.com (Andy Heffernan)
To:        comp.protocols.tcp-ip
Subject:   Re: Building IP headers

In article <CDExtx.EEL@sernews.raleigh.ibm.com> phuong@rocky.raleigh.ibm.com (Phuong Nguyen) writes:
>The book order number has been changed to SC31-7193-00 in puborder.  It's
>a very good book for whoever works for networking programming.

For non-IBMers, the ISBN is 0-13-949876-1.


-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Sep 1993 23:57:19 GMT
From:      steve@bertha (Steven L. Etheridge)
To:        comp.protocols.tcp-ip
Subject:   Broadcast mode, how to ?

 Help,

 I need info on BSD broadcast mode. I am writing a real-time 
 client/server application and need to broadcast ip packets 
 with imbedded data. If you have any sample 'c' code for connections,
 send's, recv's etc. it would be very helpful. My development
 environment consists of a 486dx2-66 PC, Windows 3.1, Microsoft
 Visual C/C++, and Netmanage TCP/IP SDK for win3.1.

	If you'd like to mail response's my address is:
		steve@bertha.dfrf.nasa.gov

									thanx!


-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 1993 07:05:33 -0400
From:      phoff@panix.com (Phill Hoff)
To:        comp.protocols.tcp-ip
Subject:   More or Less ACK's Means What?


My sniffer shows decreasing ACK packets. What are the causes and 
ramifications of decreasing ACK numbers on TCP.

I will post a summary.


Phil Hoff



-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 93 05:34:32 GMT
From:      claude@bauv.unibw-muenchen.de (Claude Frantz)
To:        comp.protocols.tcp-ip
Subject:   Multi address host question

Assuming an UNIX environment and a host named felix having some
interfaces, each one having a different IP address. All these
addresses are included in the DNS.

A host named lisa want to open a session with felix. lisa ask the
DNS and try to open a session using the first address assigned to
felix which lisa got. Unfortunatly felix's interface having this
address is defective and down but all the other ones are operational.
Now lisa will consider felix as not reachable although a session
could be opened using another of felix's address.

How can lisa's behaviour be changed ?

Thanks in advance for your help

--
Claude F.

This message may contain opinions which are not shared by my employer.
The facts can speak for themselves.

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Sep 1993 12:35:00 GMT
From:      aurora@lando.hns.com (CONTI, DENNIS)
To:        comp.protocols.tcp-ip
Subject:   Re: What book is considered the TCP/IP "Bible"

In article <275338$ddl@liege.ics.uci.edu>, schmidt@ics.uci.edu (Douglas C. Schmidt) writes...
>++ In article <babb-130993173054@larc.sdsu.edu>,
>++ Jeff Babb <babb@sciences.sdsu.edu> wrote:
>++ Need to learn about TCP/IP protocols post haste. Sub sez all. Thanks.
>++ Jeff.
> 
>Depending on whether you want to do with your knowledge, you might
>want to check out several different sources (given enough time, you
>might want to check them all out ;-)). 
> 
>----------------------------------------
>1. For info on the protocols qua protocols, you might consider:
> 
>	"Internetworking with TCP/IP Volume I: Principles, Protocols,
>	and Architectures" by Douglas Comer (Prentice Hall, 1991)
> 
>2. If you also are interested in implementing the protocols, you
>   might check out:
> 
>	"Internetworking with TCP/IP Volume II: Design,
>	Implementation, and Internals" by Douglas Comer and
>	David L. Stevens (Prentice Hall, 1991) 
> 
>        as well as the relevant RFCs such as 768 (UDP), 791 (IP), and
>	793, 1122/1123, 1072, 1185, 1191, 1323 (TCP-related RFCs)
> 
>3. If you are going to be programming distributed applications
>   (at various levels of abstraction) some good books are:
> 
>	"UNIX Network Programming" by W. Richard Stevens (Prentice
>	Hall, 1990)
> 
>	"UNIX System V Network Programming" by Steve Rago (Addison
>	Wesley, 1993)
> 
>	"Internetworking with TCP/IP Vol III: Client -- Server
>	Programming and Applications" by Douglas Comer and
>	David L. Stevens (Prentice Hall, (socket version 1992,
>	TLI version 1993)
> 
>4. If you're going to be administering a TCP/IP network,
>   a good reference to check out is
> 
>	"TCP/IP Illustrated" by W. Richard Stevens (Addison Wesley,
>	1993)
> 
>5. If you plan to consult on strategic directions of networking
>   (or if you want to engage Marshall Rose in the next 
>   great Interop debate ;-)) you might check out
> 
>	"Open Systems Networking, TCP/IP and OSI" by
>	David M. Piscitello and A. Lyman Chapin (Addison Wesley,
>	1993)
> 
>6. If you are planning to do research on high-performance 
>   communication subsystems the following book (due out soon)
>   would be handy:
>   
>   	"Gigabit Networking" by Craig Partridge (Addison Wesley,
>	1993)
> 
>7. If you are interested in security aspects, there's a book
>   due out sometime in the near future:
>   
>   	"Firewall Gateways and Internet Security" by Bill
>	Cheswick and Steven M. Bellovin (Addison Wesley, 199?)
> 
>----------------------------------------
> 
>	Needlesstosay, there are scads of other books available on
>this topic as well.  These are just some of the ones that I've found
>particularly useful for my work.
> 
>	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
o



klkjljk

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 93 13:26:46 GMT
From:      roberto@eecg.toronto.edu (Roberto Togneri)
To:        comp.protocols.tcp-ip
Subject:   Time-outs with archie/xarchie


[I'm not sure whether this the right the newsgroup for this query; its the
closest one I could find]

After using the latest verison of xarchie I have found very flexible. However
both it and its command-line counterpart (archie) always seem to suffer from
time-out problems. However if I login to archie.sura.net directly as
user 'qarchie' (and I also assume 'archie') I don't get this problem. Why
is that the case? Something to do with niceness? Obviously the archie server
is loaded but how does it select between xarchie/archie, qarchie and archie
telnet logins and archie emails?

Thanks for any information,

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Sep 1993 13:31:07 GMT
From:      richardm@sdf.lonestar.org (Richard F. Masoner)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Setting Up a Filtering Bridge for TCP/IP

In article <93257.171352JFL4@psuvm.psu.edu> <JFL4@psuvm.psu.edu> writes:
>I'm trying to configure a bridge to pass only TCP/IP (IP) traffic.
>My feeling is that I should let only packets of type 0800 through
>the bridge, but I don't know about ARP (0806) or possibly even
>RARP (8035).  We'll have some devices on one side of the bridge that

ARP is definitely important.  It's what allows one station to know
the address of another station.  RARP is important if you have
computers that remotely boot, i.e. the OS is loaded from the network.
-- 
Richard F. Masoner 				richardm@sdf.lonestar.org

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 1993 15:00:02 GMT
From:      klb@paradyne.com (Kevin Baughman)
To:        comp.protocols.tcp-ip
Subject:   EMBEDDED Server for Telnet


We have an embedded multitasking OS which supports a VT100 interface.
We've ported TCP/IP to the OS and we now want to put a telnetd
implemenation on the OS to allow network access to the VT100 interface.
The only telnetd implementation I've found (from Berkeley) assumes
it is running on UNIX.

Does anyone know of an implementation of telnetd (server) which
has been enhanced/generalized/simplified to handle a VT100 without
having access to the normal UNIX support of sockets, termio terminal
driver, termcap, etc?

Thanks,
Kevin

--
Kevin Baughman                         AT&T Paradyne, LG133
klb@paradyne.com                       8545 126th Ave N
Phone: (813) 530-8378                  P.O. Box 2826
FAX: (813) 532-5244                    Largo, FL  34649-2826

-- 
Kevin Baughman                         AT&T Paradyne, LG133
klb@paradyne.com                       8545 126th Ave N
Phone: (813) 530-8378                  P.O. Box 2826
FAX: (813) 532-5244                    Largo, FL  34649-2826

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Sep 1993 15:02:13 GMT
From:      sobi0268@mary.cs.fredonia.edu (Kevin V. Sobilo)
To:        comp.protocols.tcp-ip
Subject:   TCP on PC Question?!?!?!


	I am not personaly familiar with the packages on the market which network PCs to
other machines via a serial line using SLIP... But I understand that NFS has been inplimented
in most of the commercial packages, such that a file hierarchy on say a UNIX server can be
mounted as a disk on the PC...
	Well, Can you also mount on your PC a file hierarchy of ANOTHER PC which is networked
via the same method???? 
	Also, can you do any other type of interactive login to the PCs networked in this
fashion, besides ftp... Such as telnet or rlogin... and if you can rlogin or telnet,
if you run a software package on that machine, is there any way to redirect the
output (screen manipulation) to your screen??? This would be kinda like what X-Windows does.
	
	Thanx, for your help... (in advance)


--

/					  \\				  \ 
|					   \\                              |
|	Kevin V. Sobilo			    \\                             |
|	sobi0268@mary.cs.fredonia.edu        \\  //   "Only Amiga Makes    |
|					      \\//     It Possible"        |
|					       \/                          |
|									   |
|									   |
\==========================================================================/

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 93 15:22:58 GMT
From:      mikeh@uts.amdahl.com (Mike Harvey)
To:        comp.protocols.tcp-ip
Subject:   Paper by Borman, Msgs by Jacobson


Can anyone point me to online copies of:

 "Implementing TCP/IP On a Cray Computer", Borman D.A
(originally in Comp. Comms. review, Vol. 19, No. 2, Apr 1989)

 "Some Interim Notes On the BSD Network Speedup", Jacobson V
(originally msg. in comp.protocols.tcp-ip, July 1988)

 "Performance" Jacobson V
(originally msg. in comp.protocols.tcp-ip, Nov 1988)

and other TCP/IP performance SPECIFIC work. Thanks, Mike H

--------------------------------------------------------------------------
        Mike Harvey                     | #include <Amdahl.std.disclaimer>
                                        |
        Amdahl Intl. Mngmt. Services,   |
        European Open Systems Group.    |
                                        |
 E-mail:mikeh@uts.amdahl.com            |
 Voice :+44 252 346293                  |
 Fax   :+44 252 346400                  |
 Snail :Cromwell House, Bartley Way,    |
        Hook, Nr. Basingstoke, UK.      |
---------------------------------------------------------------------------
-- 
--------------------------------------------------------------------------

	Mike Harvey                     | #include <std.disclaimer>
                                        |
	Amdahl Intl. Mngmt. Services,   |
	European Open Systems Group.    |
                                        |
 E-mail:mikeh@uts.amdahl.com            |
 Voice :+44 252 346293                  |
 Fax   :+44 252 346400                  |
 Snail :Bartlett Wood Business Park,    |
        Hook, Nr. Basingstoke, UK.      | 

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

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Sep 1993 16:31:05 GMT
From:      dedgar@Cybercon.nb.ca (Dale L. Edgar)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: Another Telnet application ?

In article <1993Sep15.043246.16379@iti.gov.sg> chchang@ncb.gov.sg (Chang Chen Hsien) writes:

>Is there anyone out there knows about other free/shareware
>Telnet beside NCSA Telnet ? If you know, can I have the 
>ftp address ? Thanks in advance !
>

Why don't you give CommSet a try. It offers up to seven multi-tasking
tcp/ip sessions on a DOS PC. You can pick and choose among the following
apps: Telnet (VT320), FTP, Ping, NSLookup, Whois, Finger, an Editor,
a File Browser, command sessions for scripts, and numerous others. Currently
the product is in beta test - grab the demo (it is fully functional, just
time limited) via anonymous FTP on our server "ftp.cybercon.nb.ca".

CommSet has lots of other useful features - full details and spec sheets
available on our server.

Dale Edgar
Cybernetic Control Inc.
dedgar@cybercon.nb.ca

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Sep 1993 18:52:50 GMT
From:      jonathan@CS.Stanford.EDU (Jonathan Stone)
To:        comp.protocols.tcp-ip
Subject:   Re: Building IP headers

>If so, then for SunOS 4.1.3, either the man page for IP (section 4P) 
>is incorrect, or the above is implementation dependent (like what isn't).
>
>The man page says:
>
>     datagrams.  An IP header will be generated and prepended  to
>     each outgoing datagram; Received datagrams are returned with
>     the IP header and options intact.


One option is:

Find sources for BPF (e.g., in TCPdump), or an old release of
Deering IPmulticast,  and apply the patches that provide
either the SO_HDRINCL  socket option, or that enable the moral
equivalent on *all* raw sockets. (For Internet domain sockets, this
socket option disables the prepending of IP headers;  users must provide
a complete IP header. Check the documentation of the kernel modification
you install as to whether the user has to supply a valid IP header
checksum; and as to whether, for IP protocols with checksums, the user
code must compute the user-level checksum.)

Or get 4.4bsd...
Or complain fiercely to your OS vendor...


-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 1993 18:58:51 GMT
From:      dawkins@bnr.ca (Spencer Dawkins)
To:        comp.protocols.tcp-ip,comp.protocols.nfs,comp.protocols.misc
Subject:   Experiences with RPC tools?

Several sessions at Interop covered various aspects of remote procedure
calls. This is an area I haven't been following for a year or two. I
went and got the "Power Programming with RPC" O'Reilly book at lunch,
but I'm interested in hearing about experiences people have had with
RPCgen, etc. I don't have an opinion about ONC vs DCE yet, so I'd also
like to hear views on this subject.

Please respond via Email to dawkins@bnr.ca and I will summarize.

Thanks!
-- 
------------------------------------------------------------------------------
-  Spencer Dawkins			Bell-Northern Research	             -
-  (214) 684-4827			P.O. Box 833871                      -
-  Internet: dawkins@bnr.ca		Richardson TX 75083-3871             -

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 93 19:12:48 GMT
From:      jim@grimaldi.rutgers.edu (Jim Martin)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Why not some standard TELNET command lines?

Robert.Turner@brunel.ac.uk (Robert Turner) writes:
>
> [a bunch of perfectly good code deleted]
>
>This would mean that 'telnet bobsbox 12345 jimsbox 54321' would be
>valid, but DOES assume that there are no hosts whose names start with
>a numeric. This can always be a clause, with such names needing to be
>quoted.

	Well, back a ways it was legal to assume that a hostname would
start with a alpha character. rfc952 says:

   1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
   to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
   sign (-), and period (.).  Note that periods are only allowed when
   they serve to delimit components of "domain style names". (See
   RFC-921, "Domain Name System Implementation Schedule", for
   background).  No blank or space characters are permitted as part of a
   name. No distinction is made between upper and lower case.  The first
   character must be an alpha character.  The last character must not be
   a minus sign or period.

So, it would be easy to parse things the way you suggested, but
unfortunately, along came rfc1123, which says:

      The syntax of a legal Internet host name was specified in RFC-952
      [DNS:4].  One aspect of host name syntax is hereby changed: the
      restriction on the first character is relaxed to allow either a
      letter or a digit.  Host software MUST support this more liberal
      syntax.

So, alas, we can't make any kind of assumption about what will be in a
hostname :( If _anyone_ has a better idea, _PLEASE_ let me know.

						Jim

-- 
	Jim Martin			Internet: jim@noc.rutgers.edu
	Network Services		UUCP: {backbone}!rutgers!jim
	Rutgers University		Phone: (908) 932-3719

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 1993 19:15:37 GMT
From:      shirono@ssd.csd.harris.com (Roberto Shironoshita)
To:        comp.protocols.tcp-ip
Subject:   Re: Multi address host question

In article <claude.748157672@bauv106> claude@bauv.unibw-muenchen.de (Claude Frantz) writes:

> Assuming an UNIX environment and a host named felix having some
> interfaces, each one having a different IP address. All these
> addresses are included in the DNS.
>
> A host named lisa want to open a session with felix. lisa ask the
> DNS and try to open a session using the first address assigned to
> felix which lisa got. Unfortunatly felix's interface having this
> address is defective and down but all the other ones are operational.
> Now lisa will consider felix as not reachable although a session
> could be opened using another of felix's address.
>
> How can lisa's behaviour be changed ?

If your DNS is configured properly, lisa should get a bunch of addresses
for felix.  When attempting to establish the session, it should try each
address in turn, until a session is established, or it runs out of
addresses.  This is what the BSD telnet program does.
--

     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.

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Sep 1993 20:32:41 GMT
From:      dgr@ENG.Vitalink.COM (Daniel Robinson)
To:        comp.protocols.tcp-ip,comp.windows.x
Subject:   Looking for info on XTI

I'm looking for information on XTI, X/Open Transport Interface.
Any tips?

Thanks, Daniel

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Sep 93 08:23:00 -0700
From:      mike.laplaunte@freddy.ersys.edmonton.ab.ca (Mike Laplaunte)
To:        comp.protocols.tcp-ip
Subject:   Help

Hi.  I have come across some old ethernet equipment and would like to
set up a file server with it.  One problem:  The documentation seems to
be lost.  Can anyone tell me what the switches on a EtherLink AT card
(3Com is the manufacturer) would be and what Novell 3.11 driver I would
use?  My best guess for the driver is 3c503 but I could be wrong.  The
switches are set as such:
                                MEM ADDR
                                        14  15    17  18  19
                                12  13         16

                                I/O ADDR        MEM EN
                                                8  9  10
                                 4   5   6   7

There is also a set of switches for the interrupt and DMA but they are
marked with the actual number.  Any help with this would be greatly
appretiated.

- mike

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Sep 1993 22:47:00 GMT
From:      msells@undergrad.math.uwaterloo.ca (Marty Sells)
To:        comp.protocols.tcp-ip
Subject:   Raw IP - How

I saw a few messages detailing how to send IP packets out (basically
do a socket(AF_INET,RAW...)). Could someone please send me some
code snippits? I'm not at any HW that I can play with so finding
out if Sun does or doesn't prepend an IP header is impossible for
me. Also in the tests I did I couldn't get send or sendto to
work (errors about no destination and then network unreachable).
I was just trying to send packets to the local machine and
dump them out using etherfind.

Pointers to where some RAW socket code is that isn't *TOO* heavy
would be appriciated.

Marty

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Sep 1993 01:27:24 GMT
From:      hopkinso@interaccess.com (Carl Hopkinson)
To:        comp.protocols.tcp-ip,alt.internet.services,comp.dcom.lans.misc,comp.dcom.sys.cisco,comp.sys.sun.admin,comp.unix.admin
Subject:   Re: Evaluating Internet Services

garyb@gcm.com (Gary Blumenstein) writes:


>When evaluating the various ways to connect to the Internet, Susan
>Estrada in her new O'Reilly book, _Connecting to the Internet_ suggests
>having the service providor supply packet round trip times from two
>given points where one site is outside the providor's regional network.

Yes, but are you really just interested in the trip times to random
sites thru these two providers at random times of the day or is
your interest more focused on certain sites (for instance, some other
far-flung nodes in your corporate empire?)  I would think the latter.

>I would like to do just that sice I'm evaluating the performance of the
>various products offered by Performance Systems International (PSI) and 
>Advanced Network Services (ANS).

The round trip time to any node thru a provide will be a function of the
hops the packet has to visit on the way to the destination and the
delay incurred at each of these hops.  At certain busy times, some nodes
along the route may become so congested that your poor packets will get
dropped on the floor (actually, removed from an over-burdened reception
or transmission queue) that you experience big delays due to retransmission.
Considering this, the highest-bandwith provider in general will be the one
that is able to do most of your packet forwarding on intra-provider links
that is also well-connected to the outside world so as to minimize the
the number of congestion-prone external hops it has to go thru.  Your
own private tollroad to everywhere, in other words.  Of course, the closer
a provider approachs this ideal situation (many links, low traffic volume)
the more expensive the service must be (what else is new :) ).

>My question is this; Should I ask them to send ICMP echoes (ping) times
>and what sites should I tell them to check when all I know are the top
>level domain names of various sites out there?  I am located in
>southern Connecticut, and ideally I would like to ping a site on the
>west coast that is not directly connected to any PSI or ANS (NSFnet)
>backbones.
 
>Would anybody out there like to volunteer by sending me their system
>name, IP number, and the name of their regional network (i.e. BARRNet, 
>CERFnet).  I will have the two vendors measure and supply me with 
>average packet round trip times and would be happy to share the results 
>with you.
 
>Many thanks.
 
>-Gary


>-- 
>Gary Blumenstein    //   garyb@gcm.com    - Greenwich Capital Markets - 


Carl Hopkinson (hopkinso@switch.rockwell.com or hopkinso@interacccess.com)


-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 1993 09:05:28 GMT
From:      net@cs.tu-berlin.de (Oliver Laumann)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Bug in inet_addr()?

Is 255.255.255.255 a valid broadcast IP address?

I suppose it is, as the address is mentioned in RFC 919, and there
is an (undocumented) symbol INADDR_BROADCAST with this value in
<netinet/in.h> in various UNIX versions.

On the other hand, the inet_addr() function from inet(3) uses the
return value -1 as an error indication, so that it cannot be called
with 255.255.255.255 as an argument.  This means that, for instance,
"ping -sv 255.255.255.255" reports "unknown host" (although this
command could be quite useful to obtain a reply from all hosts in
the local network).

Is this a bug in inet_addr()?

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Sep 1993 10:39:57 GMT
From:      vharten@prl.philips.nl (Peter R. van Harten)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.misc,comp.os.ms-windows.setup
Subject:   Problem with comb. of Dell 425s/L, PC-NFS and ET4W32 windows-drivers

Hi troubleshooters,

We encountered a problem using a brand new Dell 425s/L with Tseng ET4W32 
chipset and PC-NFS. When using the Dell ET4W32 video-drivers under Windows, we 
see that screen updating is disturbed. There are several white or black 
rectangles. We tried several network cards/drivers: no difference. PC-NFS 4.0a 
or 5.0a: no difference, ET4W32 version 1.0, 1.0a, 1.1: no difference. When 
using VGA or ET4000 drivers, the problem vanished, so we suspect the Dell 
ET4W32 drivers, but we only see the problem, when using PC-NFS. When 
mounting/unmounting drives, the effects are different. (?) We have never 
problems like this before.

Can anyone help us out ...?

Thanks,
------------------------------------------------------------------ 
P.R. van Harten                      Philips Research Laboratories
tel. +31 40 742209                   Prof. Holstlaan 4
fax. +31 40 744810                   5656 AA  Eindhoven
email: vharten@prl.philips.nl        The Netherlands
CompuServe: 100142,3044

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Sep 1993 11:17:02 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: Bug in inet_addr()?

>Is 255.255.255.255 a valid broadcast IP address?

Yes, but it should only be used by a program that doesn't know the local
IP adress and subnet mask (i.e., someone bootstrapping such as BOOTP).
It's called the limited broadcast address.

There are some systems (Ultrix, I think?) that take datagrams sent
to the limited broadcast address and send a copy out each broadcast-
capable interface on a multihomed host.  RFC 1122 explicitly avoids
taking a stand on this technique.

>On the other hand, the inet_addr() function from inet(3) uses the
>return value -1 as an error indication, so that it cannot be called
>with 255.255.255.255 as an argument.  This means that, for instance,
>"ping -sv 255.255.255.255" reports "unknown host" (although this
>command could be quite useful to obtain a reply from all hosts in
>the local network).
>
>Is this a bug in inet_addr()?

Yes.  The BSD Net/2 code fixed this by adding a new function called
inet_aton() with a second argument (struct in_addr *) that points
to the return structure; then the function returns 0 or 1.  I haven't
looked around to see what vendors have picked up this new function.

As a side note, I fixed my own version of ping to use the new function,
specifically to see what a variety of hosts did with 255.255.255.255,
and only 1 of 6 (Solaris 2.2) handled it "correctly" (a local broadcast
on the primary interface).  The other 5 (SunOS 4.1.3, BSD/386, AIX,
SVR4, and one other, 4.4BSD I think) all applied the default route,
and eventually someone threw away the ping requests.

	Rich Stevens  (rstevens@noao.edu)

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Sep 1993 12:12:07 GMT
From:      ercm20@festival.ed.ac.uk (Sam Wilson)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: Bug in inet_addr()?

Oliver Laumann (net@cs.tu-berlin.de) wrote:
: Is 255.255.255.255 a valid broadcast IP address?
 
: I suppose it is, as the address is mentioned in RFC 919, and there
: is an (undocumented) symbol INADDR_BROADCAST with this value in
: <netinet/in.h> in various UNIX versions.

See RFC 1122 for better info on broadcast addresses and their uses.

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


-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Sep 1993 13:42:08 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Building IP headers

stwill@rchland.vnet.ibm.com (Steve Will) writes:
}In case anyone else was wondering:
}--------------------------------------------------------------
}Hi.  You need: socket(AF_INET, SOCK_RAW, IPPROTO_RAW);  Then whatever
}you write to that socket descriptor is assumed to start with a valid
}IP header.  You probably don't want to read on this descriptor,
}however, as I don't think you'll get anything.  traceroute uses this,
}one of these socket types for writing, and one with the final argument
}IPPROTO_ICMP for reading.
}
}	Rich Stevens 
}--------------------------------------------------------------
   On at least some platforms, you can make use of the `packet filter'
   to send and receive raw packets (really raw!  at least under
   Ultrix you have to build the ethernet/fddi layer header too).

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

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Sep 1993 18:56:45
From:      brian@novell.com (Brian Meek)
To:        comp.sys.novell,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Novell & Banyan & TCP/IP

khai@adi.com (S. Khai Mong) writes:
>From: khai@adi.com (S. Khai Mong)
>Subject: Novell & Banyan & TCP/IP
>Date: Sat, 11 Sep 1993 17:43:22 GMT
>
>I have this application which uses Novell's TCP/IP API and compiled
>and linked with Novell's TCP/IP product.  This works fine on
>Novell client workstations.
>
>My question: Is there a chance that such an application will run on a
>client workstation that has _only_ Banyan and Banyan's TCP/IP software
>installed?  Is there any quick answer why it won't work?  (I am
>thinking of getting Banyan's TCP/IP software)

You can't run two TCP/IP stacks at the same time on the same board
(not easily, anyway).  This is because both stacks are competing for
the same packets... (long story, FAQ item).

It would be easier (and take less RAM) to run Novell's TCP/IP software
with Banyan VINES.  VINES supports NDIS (maybe even native ODI by 
now?), and it can be run over the ODINSUP driver found in:

	ftp.novell.com: /netwire/novfiles/dosup7.exe

Refer to ODINSUP.DOC for intructions.  The idea is you'll have
Banyan's VINES protocol over NDIS (ODINSUP) and Novell TCP/IP
directly over ODI running simultaneously.  No NetWare, unfortunately...
but all will function nonetheless :-).

-- brian
___________________________________________________________________________
Brian Meek                               Novell, Inc. -- UNIX Systems Group
                                         Internet mail:  brian@Novell.COM

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Sep 1993 14:23:55 GMT
From:      gkb1@tower.york.ac.uk (Graham Barlow)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.misc,comp.os.ms-windows.setup
Subject:   Re: Problem with comb. of Dell 425s/L, PC-NFS and ET4W32 windows-drivers

In article <vharten.31.000BAA71@prl.philips.nl> vharten@prl.philips.nl (Peter R. van Harten) writes:


>Hi troubleshooters,
 
>We encountered a problem using a brand new Dell 425s/L with Tseng ET4W32 
>chipset and PC-NFS. When using the Dell ET4W32 video-drivers under Windows, we 
>see that screen updating is disturbed. There are several white or black 
>rectangles. We tried several network cards/drivers: no difference. PC-NFS 4.0a 
>or 5.0a: no difference, ET4W32 version 1.0, 1.0a, 1.1: no difference. When 
>using VGA or ET4000 drivers, the problem vanished, so we suspect the Dell 
>ET4W32 drivers, but we only see the problem, when using PC-NFS. When 
>mounting/unmounting drives, the effects are different. (?) We have never 
>problems like this before.

One suggestion, I solved several problems by updating my Dell S3 drivers, 
perhaps you could try and update yours.  DELL actually have an ftp server! I 
saw this in a news message from one of their people a couple of weeks ago:

...you can ftp to dell1.us.dell.com, login in as anonymous...

Try it, it worked for me...

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


-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 93 15:07:07 GMT
From:      cherasar@icarus.montclair.edu (Ken J. Cherasaro)
To:        comp.protocols.tcp-ip
Subject:   SLIP

I was wondering if anybody could point me in the direction of a 
PD SLIP protocol which works under SunOS 4.1.3.  And also if anyone
has had any experience with FTP Software's PC/TCP for the PC and their 
SLIP, any info would be greatly appreciated.

Thank you,
Ken J. Cherasaro

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Sep 1993 15:39:14 GMT
From:      spchuid@cicero.spc.uchicago.edu (Hui Dong)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   TCP programming question

TCP suppose to provide reliable data transfer, but when I wrote a client-server
model shipping large files, I find some data are lost, I am pretty new to
TCP programming, so any help from experts here are appreciated.

After I set up a TCP connection, I need to ship big file from server to client,
I break up the file into chunks of say 512Byte data on the server, then I
"send" the chunks in a while loop on server. On client, I "recv" chunks of
512Byte data in a while loop, but everytime have to do some I/O to disk, so
client is slower than server. Now, I notice some data lost on the client,
I assume that might be because the server "send" data too fast, not aware of
the client can't take it more, no blocking on the "send" function (although
there should be "window" reported from client, but that can be only on the
system data buffer level, I am not sure). I check sizes of real data sent or
received on server and client, the server always sent 512Byte successfully,
but the client sometimes only received smaller size data (say 398Bytes etc.).
Now, if I put a "recv" in the while loop on the server to get a dummy "int",
"recv" will block until the client finished I/O to disk and "send" the dummy
"int", this way kind of synchronize the action on both sides, the problem
disappear. This experience is contrary to my understanding that TCP should
block "send" and so synchronize the server-client communication automatically,
or it might be I have a misconception here. Any clearification will be
appreciated.



-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 1993 15:52:06 GMT
From:      jbotz@mtholyoke.edu (Jurgen Botz)
To:        comp.protocols.tcp-ip
Subject:   Re: Whois++

In article <1993Sep13.173827.5486@psg.com>, Randy Bush <randy@psg.com> wrote:
>billy@utdallas.edu (Billy Barron) writes:
>> From everything I've heard, it is vapor at this point.
>
>Please don't tell my server and a few dozen others.  There are already four
>separate free implementations available.

Don't just tantalize us, tell us more.

>Like other lightweight competitors
>to OSI monsters, Whois++ servers and services will outnumber the monsters in
>a month or two.

Only if more people learn about this stuff.  Last week I couldn't even
find the draft RFC on whois++ on internic.  What gives?
-- 
Jurgen Botz, jbotz@mtholyoke.edu | ``Accountability is the price of openness''
South Hadley, MA, USA            | - Daniel Geer


-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Sep 1993 16:30:04 GMT
From:      ben@piglet.cr.usgs.gov (Ben A. Mesander)
To:        comp.protocols.tcp-ip
Subject:   Re: Building IP headers

In article <evansmp.5@aston.ac.uk> evansmp@aston.ac.uk (Mark Evans) writes:

   Every version of unix I have ever seen requires you to be root to open
   a raw socket.
   Which is why ping and traceroute binaries are setuid.

ESIX SVR4 for Intel machines did not require that you be root to open a
raw socket.

--Ben

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Sep 1993 17:51:15 GMT
From:      perlman@zeno.fit.edu (Marshal H. Perlman)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   LIVINGSTON PORTMASTER

IF ANYONE HERE KNOWS what type of modems work good on a LIVINGSTON PORTMASTER
(i.e. on the answering end)... >>>AND<<< what the proper AT settings are, 
please get in touch with me ASAP!!!!


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

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Sep 1993 17:52:37 GMT
From:      perlman@tuck.cs.fit.edu (Marshal H. Perlman)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   LIVINGSTON PORTMASTER

IF ANYONE HERE KNOWS what type of modems work good on a LIVINGSTON PORTMASTER
(i.e. on the answering end)... >>>AND<<< what the proper AT settings are, 
please get in touch with me ASAP!!!!

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Sep 1993 19:54:33 GMT
From:      lees@austin.ibm.com (Lee Slaughter)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: Bug in inet_addr()?

In article <1993Sep17.111702.8074@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:
>>Is 255.255.255.255 a valid broadcast IP address?
 ...
>>Is this a bug in inet_addr()?
 ...
>As a side note, I fixed my own version of ping to use the new function,
>specifically to see what a variety of hosts did with 255.255.255.255,
>and only 1 of 6 (Solaris 2.2) handled it "correctly" (a local broadcast
>on the primary interface).  The other 5 (SunOS 4.1.3, BSD/386, AIX,
>SVR4, and one other, 4.4BSD I think) all applied the default route,
>and eventually someone threw away the ping requests.

hmmm. 
AIX3.2.4 seems to be OK:

  struct sockaddr_in	dest_addr;
  ...
  dest_addr.sin_addr.s_addr = inet_addr("255.255.255.255");
  ...
    sendto(sockfd,(char *)msg,msg_size,0,&dest_addr,sockaddr_len);
  ...

works OK in AIX 3.2.4  (but the ping gives me 'malformed
address', tho a network-directed ping works OK, e.g. 9.255.255.255)

lee

=========================================================================
Lee Slaughter                 AIX RISC System/6000 Communications Support
11400 Burnet Road             Austin, TX 78758              
e-mail: lees@austin.ibm.com   Phone: (512) 838-2817 TL 678-2817   
==========================================================================

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Sep 1993 22:59:42 GMT
From:      BERRYMAN@orca.drep.dnd.ca (DON BERRYMAN)
To:        comp.sys.sun.admin,comp.sys.hp,comp.protocols.tcp-ip
Subject:   How to kill every SUN on your network.


Title: How to kill every SUN on your network.
Alternate Title: How to be lynched

Concider the following Network Topology:

     HP735 
     FDDI----+
              \                     
     HP735     CableTron            
     FDDI------FDDI Concentrator    |
              /Bridge to Ethernet---+
     HP735   /                      |
     FDDI---+                       |
                         SUN--------+
                                    |
      Macintoshs       GATORBOX     |
      on APPLETALK-----AppleTalk    |
                       Ethernet-----+
                       Bridge       |
           

Now write a program on the HP's to BROADCAST UDP packets that are
larger than Ethernet's MTU (maximum transimission unit) of 1500
bytes. This is allowable on the HP since FDDI has a MTU of 4358
bytes. My program was sending 2312 byte packets, 8 times per
second, which is a trivial amount of data.

Now what happens is that the CableTron FDDI to Ethernet bridge
passes these big packets onto the Ethernet. In my opion it should
realize that this violates Ethernet's MTU and not passes them on,
but it does.  

Now every SUN on the network will attempt to receive the "Giant
Packet" and start generating error messages on their consol.
Eventually the SUN will die and then refuse to boot until I turn
off my Broadcaster.  In my opion the SUN's should just ignore the
"Giant Packet" since it obviously violates Ethernet's
Specifications and is thus garbage (as far as the SUN is
concerned).                     

Also the GATORBOX will hang while the large packets are on the
network but seems to recover whe n they go away.

My Network Diagram is extremely simplified and omits all the:
VAXs, SGIs, IBMs, Xterms, Printers, PCs, and god knows what else;
that did not complain.


Don Berryman
Defence Research Establishment Pacific
Canadian Forces Base Esquimalt
Victoria, BC, CANADA, V0S-1B0
604-363-2731    604-363-2856fax
berryman@orca.drep.dnd.ca

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18 Sep 1993 01:56:00 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.sys.sun.admin,comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: How to kill every SUN on your network.

DON BERRYMAN (BERRYMAN@orca.drep.dnd.ca) wrote:

: Title: How to kill every SUN on your network.
: Alternate Title: How to be lynched

[Bunches of good details deleted]

#begin SOAPBOX
This is why one SHOULD NOT bridge FDDI and Ethernet together.
This is why one SHOULD route FDDI and Ethernet together.
#end

If the bridge were to drop every packet larger than EthernetMTU, then
you would loose *generic* IP connectivity between your FDDI ring and
your Ethernet. Yes, TCP would probably work thanks to Max TPDU
negotiation, but there is no such thing for UDP. Consider what would
happen of someone on the Ethernet tried to do NFS to machines on the
FDDI... Yes, there is rsize and wsize on the mounts, but we come back
to generic IP (UDP) connectivity again.

Of course, there are some FDDI<->Ethernet bridges which do not IP
fragment. Then you have to go and set the interface MTU on the FDDI
interfaces to be Ethernet sized - poof gee whiz, there goes most if
not all of your point-to-point performance improvements between
stations on the FDDI ring.

One could argue that the FDDI systems should be using Path MTU
discovery, but then one has to argue that the bridge must understand
PMTU... 

One could argue that the bridge should know that it is not supposed to
send broadcast fragments...

Of course, if the bridge did all these things that one might argue it
should, it would begin to look remarkably like a router wouldn't it?-)

This brings us back to the original soapboxing:

This is why one SHOULD NOT bridge FDDI and Ethernet together.
This is why one SHOULD route FDDI and Ethernet together.

rick jones
Quick and simple will bite you every time...

PS - there is a patch which will allow setting the FDDI Interface MTU
on HP systems, which might help in some situations - such as the
non-fragmenting bridges. See your friendly neighborhood HP rep type.

Of course in this specific situation, Don wants to send frames that
are larger than EthernetMTU, so setting the FDDI interface MTU to
EthernetMTU would "break" his application....

Aren't networks fun ?-) Brings us back to the soapbox...


-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 1993 13:36:49 -0400
From:      mjf@clarknet.clark.net (Marc J. Fraioli)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: How to kill every SUN on your network.

In article <1993Sep18.133722.22936@lokkur.dexter.mi.us> scs@lokkur.dexter.mi.us (Steve Simmons) writes:
>raj@cup.hp.com (Rick Jones) writes:
>>DON BERRYMAN (BERRYMAN@orca.drep.dnd.ca) wrote:
 
>>: Title: How to kill every SUN on your network.
 
>>[Bunches of good details deleted]
 
>>#begin SOAPBOX
>>This is why one SHOULD NOT bridge FDDI and Ethernet together.
>>This is why one SHOULD route FDDI and Ethernet together.
>>#end
>
>I'll go one step further.  If the FDDI/Enet bridge is putting packets
>*in violation of the ethernet spec* onto the ethernet, then the bridge
>is fundamentally broke.  Period.  End of discussion.  

One thing that hasn't been entered into this discussion yet, which I will now
add, is why the Suns hang when they see it.  Isn't this a defect too?  They
seem to recognize what the error is, that a packet which violates the 
ethernet spec has been receieved, so why can't they simply print an error
and ignore it?  What causes them to hang?  
 
 At my site, we have been troubled by this for some time now.  We have an 
increasing number of SPARC 2s on our net, all running 4.1.3.  We also have 
a lot of PCs and Netware on the net.  The SPARCs get those giant packet
errors constantly, and I have heard in this group that many PC ethernets
do this, either accidentally, or deliberately (to increase performance).  We
have also had the problem of the Suns hanging, apparently for no reason, or
hanging during the execution of shutdown.  Sun claims to have never heard of
this problem.  They recently sent us the source to shutdown, but I suspect
it is a canary in a coalmine, so to speak.  So, does anyone know why this
might be causing the Suns to hang?  And also, does this happen to machines
running Solaris 2.x?

-- 
Marc Fraioli			       |      CHICAGO DAILY TRIBUNE
mjf@clark.net   <--- New Address!      |    ---------------------------
				       |      Windows defeats OS/2!

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 1993 20:36:03 -0500
From:      karl@genesis.MCS.COM (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   FTPD question (WU version)

Hi there,

We have someone here who would like to have a "semi-private" area for FTP
transfers set up.  I don't want to just make another user; what I'm looking
for is a way to have FTPD do its own authentication for some number of
user(s) and place them in an area which is "restricted". 

Anyone done this?  Can it be done?

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

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18 Sep 93 13:37:22 GMT
From:      scs@lokkur.dexter.mi.us (Steve Simmons)
To:        comp.sys.sun.admin,comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: How to kill every SUN on your network.

raj@cup.hp.com (Rick Jones) writes:

>DON BERRYMAN (BERRYMAN@orca.drep.dnd.ca) wrote:
 
>: Title: How to kill every SUN on your network.
 
>[Bunches of good details deleted]
 
>#begin SOAPBOX
>This is why one SHOULD NOT bridge FDDI and Ethernet together.
>This is why one SHOULD route FDDI and Ethernet together.
>#end

I'll go one step further.  If the FDDI/Enet bridge is putting packets
*in violation of the ethernet spec* onto the ethernet, then the bridge
is fundamentally broke.  Period.  End of discussion.  This is why we
have standards for things like ethernet.  We can build reliable hardware
and software which rejects things out of tolerance.

Who sells that abortion, anyway?  I want to put them on my fecal roster.
I give classes on IP and ethernet a lot, and one part of the class is
things that can go wrong.  This is definately going to be on my list.
-- 
"It has about as much chance of survival in the current marketplace as a
 blonde ingenue overnight guest at a Transylvanian castle."
 	- review of Jimmy Buffet's first album, 1973.

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 1993 15:35:43 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.protocols.tcp-ip
Subject:   Static Host Route on Cisco?

Is it possible to get a Cisco IGS router (we are running 9.0 software)
to allow a static route to a particular host (not a subnet). From the
doc I have it looks like its just subnets.

The application is this. We have a host with two interfaces, one on
each side of the router.  

                subnet A --Router--subnet B
                      |                |
                      |-----HOST-------|

"HOST" gets a lot of traffic from the "A" side addressed to its
"B" inteface. I want the router to send it to the HOST'S A interface
so that it won't load the B subnet. 


---
Ken Mandelberg      | km@mathcs.emory.edu          PREFERRED
Emory University    | {rutgers,gatech}!emory!km    UUCP 
Dept of Math and CS | km@emory.bitnet              NON-DOMAIN BITNET  
Atlanta, GA 30322   | Phone: Voice (404) 727-7963, FAX 727-5611



-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18 Sep 1993 17:18:15 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: Bug in inet_addr()?

lees@austin.ibm.com (Lee Slaughter) writes:
}rstevens@noao.edu (W. Richard Stevens) writes:
}>>Is 255.255.255.255 a valid broadcast IP address?
}>>Is this a bug in inet_addr()?
 
}hmmm. 
}AIX3.2.4 seems to be OK:
}
}  struct sockaddr_in	dest_addr;
}  ...
}  dest_addr.sin_addr.s_addr = inet_addr("255.255.255.255");
}  ...
}    sendto(sockfd,(char *)msg,msg_size,0,&dest_addr,sockaddr_len);
}  ...

Sure, because you left out any error checking:

   if ((dest_addr.sin_addr.s_addr = inet_addr("255.255.255.255")) == -1) {
	/* error ... */
   } else {
  sendto(sockfd,(char *)msg,msg_size,0,&dest_addr,sockaddr_len);
   }

To do this "right", you need to throw in a strcmp too (*sigh*) ...

   if (((dest_addr.sin_addr.s_addr = inet_addr(ascii_inet_addr)) == -1) &&
        (strcmp(ascii_inet_addr, "255.255.255.255") != 0)) {
	/* error ... */
   } else {
  sendto(sockfd,(char *)msg,msg_size,0,&dest_addr,sockaddr_len);
   }

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

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 1993 18:48:36 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Static Host Route on Cisco?

In article <27f9sfINNt4a@emory.mathcs.emory.edu> km@mathcs.emory.edu writes:
    Is it possible to get a Cisco IGS router (we are running 9.0 software)
    to allow a static route to a particular host (not a subnet). From the
    doc I have it looks like its just subnets.
    
Nope, sorry.  You need at least 9.1 to do that.

Tony

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 93 19:34:58 GMT
From:      guy@Auspex.COM (Guy Harris)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: How to kill every SUN on your network.

>One thing that hasn't been entered into this discussion yet, which I will now
>add, is why the Suns hang when they see it.  Isn't this a defect too?  They
>seem to recognize what the error is, that a packet which violates the 
>ethernet spec has been receieved, so why can't they simply print an error
>and ignore it?  What causes them to hang?  

Possibly the fact that the message is printed using the kernel's
"printf()" routine, which disables interrupts while it's printing stuff,
and uses polling I/O to do the printing, at least if it's printing to a
physical console rather than a console window; the system may be "hung"
in the sense that it's so busy doing that printing that it can't do
anything else.

A fix might be to have it remember the Ethernet address of the offending
machine and, if another bad packet comes in from that host, not bother
printing another message.  (An even *better* fix might be to send that
machine a poison packet and shut its ass down, but, unfortunately,
there's no standard poison packet....)

>We
>have also had the problem of the Suns hanging, apparently for no reason, or
>hanging during the execution of shutdown.

The "shutdown" command does a "sync()"; if your machine has, in its
memory, dirty pages fetched from an NFS server, and it can't get a reply
from that NFS server for some reason, the "sync()", and thus the
"shutdown", can hang.

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18 Sep 1993 22:44:01 GMT
From:      lees@austin.ibm.com (Lee Slaughter)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: Bug in inet_addr()?

In article <CDK82F.3z6@news.iastate.edu> john@iastate.edu (John Hascall) writes:
>lees@austin.ibm.com (Lee Slaughter) writes:
>}AIX3.2.4 seems to be OK:
>}
>}  struct sockaddr_in	dest_addr;
>}  ...
>}  dest_addr.sin_addr.s_addr = inet_addr("255.255.255.255");
>}  ...
>}    sendto(sockfd,(char *)msg,msg_size,0,&dest_addr,sockaddr_len);
>}  ...
>
>Sure, because you left out any error checking:
>
>   if ((dest_addr.sin_addr.s_addr = inet_addr("255.255.255.255")) == -1) {
>	/* error ... */
>   } else {
  sendto(sockfd,(char *)msg,msg_size,0,&dest_addr,sockaddr_len);
>   }
>
>To do this "right", you need to throw in a strcmp too (*sigh*) ...
>
>   if (((dest_addr.sin_addr.s_addr = inet_addr(ascii_inet_addr)) == -1) &&
>        (strcmp(ascii_inet_addr, "255.255.255.255") != 0)) {
>	/* error ... */
>   } else {
  sendto(sockfd,(char *)msg,msg_size,0,&dest_addr,sockaddr_len);
>   }
>

Sorry, the complete line is

    if((snd_len=sendto(sockfd,(char *)msg,msg_size,0,&dest_addr,sockaddr_len))<0)
    {
      perror("sendto");
      exit(6);
    }

I just took out the error checking for clarity.
But the strcmp is a good idea.
lee


-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 1993 01:05:20 GMT
From:      moongw@ece.arizona.edu (Gwi Moon)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.os.os2.networking
Subject:   Internet address for gateways

Hello, netter!!

I want to know about the route between source and destination.
If I send message from A to B using TCP or UDP protocal, how many relay nodes it run through?
What are their addresses?
I am wondering about how I can get the addresses of gateways and configuration of networks between two nodes.
I think there is some mechanism to make interim gateways insert their addresses.
 
Send e-mail to 'moongw.ece.arizona.edu'.
I appreciate any help.

Moon
--

Moon, Gwi
----
                       Dept. of Electrical & Computer Engineering

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19 Sep 1993 02:45:30 GMT
From:      sjanicki@us.oracle.com (sjanicki)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: LIVINGSTON PORTMASTER

In article <CDIExF.Is1@zeno.fit.edu> perlman@zeno.fit.edu (Marshal H. Perlman) writes:
>From: perlman@zeno.fit.edu (Marshal H. Perlman)
>Subject: LIVINGSTON PORTMASTER
>Date: Fri, 17 Sep 1993 17:51:15 GMT
 
>IF ANYONE HERE KNOWS what type of modems work good on a LIVINGSTON PORTMASTER
>(i.e. on the answering end)... >>>AND<<< what the proper AT settings are, 
>please get in touch with me ASAP!!!!


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

We have a 10 port and a 30 port unit, we tested it using stand alone US 
Robotics Courier 14.4 modems and now we are using the rack mounted versions, 
both work just fine with default settings. Check with Livingston to ensure you 
have the latest software revisions on your PORTMASTER. Call their tech support 
and get them to dial into the portmaster on your end and check it out, they 
can also supply you with their recommended modem settings. I have tested PPP 
using Distinct Corporations PPP and FTP's PPP, Distinct is the best and most 
simple to configure and run, it also includes scripts to run with the 
Livingstion Portmaster.

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19 Sep 93 14:26:00 -0500
From:      tom.kauffman@channel1.com (Tom Kauffman)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP network config que

The company I work for is going to migrate to TCP/IP over the next
couple of years, and I'll be in the thick of it -- so I have some
questions about configuration . . .

We currently run an IBM 3090 mainframe, with all the baggage that
implies, and an HP 3000/960 for MRP and purchasing. There are 17 sites
running 3270 devices, SNA/SDLC, over a mixed bag of point-to-point and
multi-drop lines; 7 sites running HP devices, Async echoplex ENQ/ACK,
over point-to-point lines with stat muxes and x.25 packet switches; and
6 sites running both configurations.

The long-range plan includes migration to a client/server environment,
with each major site being fairly close to self-contained and
self-sufficient. The sites will be tied to Corporate via adaptive
bridges at first, running over 19.2Kbps analog or 56Kbps digital lines
as traffic warrants. I anticipate a router or two as traffic loads grow.

I am currently leaning toward a class 'B' network address (if we can get
one. . .) sub-netted in the third octet, so each site is a logical
sub-network. There may be several sub-nets at Corporate (I'd like to
keep the application developers 'firewalled' from the rest of the net,
if possible). However -- 10 of the 3270 sites are very small (two
terminals and two printers each) and 'belong' to two of the remaining
sites, not to Corporate. Should these sites share their parent sites
subnet? Or should they be two subnets, one for the one parent, one for
the other? (This is the way I'm leaning now). These ten sites will
probably be tied into the rest via frame relay (currently they're on one
big multipoint circuit at 9600bps).

Am I thinking in the right direction? Are there any pitfalls I need to
be aware of? Feedback would be deeply appreciated!

Tom.Kauffman@Channel1.com

---
 þ QMPro 1.02 41-4592 þ 2/3 of a stamp's price goes for storage.

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19 Sep 1993 09:18:16 GMT
From:      ccml@hippo.ru.ac.za (Mike Lawrie)
To:        comp.protocols.tcp-ip,alt.internet.services,comp.dcom.lans.misc,comp.dcom.sys.cisco,comp.sys.sun.admin,comp.unix.admin
Subject:   Re: Evaluating Internet Services

In <hopkinso.748229244@interaccess.com> hopkinso@interaccess.com (Carl Hopkinson) writes:

>garyb@gcm.com (Gary Blumenstein) writes:


>>When evaluating the various ways to connect to the Internet, Susan
>>Estrada in her new O'Reilly book, _Connecting to the Internet_ suggests
>>having the service providor supply packet round trip times from two
>>given points where one site is outside the providor's regional network.
 
>Yes, but are you really just interested in the trip times to random
>sites thru these two providers at random times of the day or is
>your interest more focused on certain sites (for instance, some other
>far-flung nodes in your corporate empire?)  I would think the latter.

There is more to performance of a tcp/ip network than the ping _times_.
Have a look at the packet loss rate. Well, that's what I calculate and
have experienced with our link from South Africa on a thin pipe that
runs at full capacity for hours on end.


>.  At certain busy times, some nodes
>along the route may become so congested that your poor packets will get
>dropped on the floor (actually, removed from an over-burdened reception
>or transmission queue) that you experience big delays due to retransmission.

This is BAD news when it happens.

Here's my theory as to why loss rate is _critical_, and I would
appreciate someone pointing out the flaws. Consider a single 56 Kbd
line (you can extend this for your fat pipes in the USA). Suppose that:-

a) the line is free for a single user and runs at 56,000 baud (>5,500
   cps)

b) that the packet loss is 10% (because your IP provider has not
   provided enough bandwidth for all of the customers, or simply a
   failure)

c) that the packet are 1500 characters in size (they are probably much
   smaller)

d) the timeout of a lost TCP packet is 5 seconds (I don't know the
   variance of this)

A 5 minute transfer has thus (5 * 60 * 5500 / 1500) = 1100 packets.
Thus the number of lost packets are 1100 *10%       =  110 packets lost.
The delay due to lost packets is 110*5              =  550 seconds
Total time to transmit is 5 mins + 550 seconds      =  850 seconds

Thus the transfer takes (850 / 300) = 2.83 times as long as it should,
and the effective bandwidth has dropped to under 20 Kbd.

I would urge you to write into your contract some heavy penalty clauses
for lost packets, and that you run periodic burst of pings to monitor
the loss. In the case of the link from South Africa, we are detecting a
zero loss to the first router in the USA, and a non-zero loss to the
second (a la traceroute). I'm not too sure how far into the net to do
additional tests and whether anyone will react to reports of lost
packets.

You should, of course, ping with packets sizes that are close to that of
your live traffic.

Mike
-- 
Mike Lawrie                             <ccml@hippo.ru.ac.za>
Director, Computing Services            ph +27 461 318279/80
Rhodes University, Drostdy Rd           fx +27 461 25049
Grahamstown 6140, South Africa

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 1993 13:17:20 GMT
From:      root@perot.mtsu.edu (Mark J. Bailey [Admin])
To:        comp.unix.sys5.r4,comp.dcom.lans.ethernet,comp.protocols.tcpip,comp.unix.admin,comp.dcom.lans.misc
Subject:   WEIRD problem with UnixWare router and 2 networks!  Help!  (LONG)

Hello,

First off, I apologize for the size and cross-post of this article.  I tried
to be as narrow as possible.

I have a situation that should be a piece of cake but has stumped me for the
past 6 weeks!  I finally got so mad at it that I have gathered herein a 
fairly detailed descripition of my situation in the hopes of finding a 
sympathetic soul out there reading this that may strike the match and allow
me to be done with this!  :-)  If you hate mysteries and long detail, then
you may move on to the next article at this time.  :-)

 

I have a novell 3.11 100-user server which has 4 NE2000's and we are
assigning this system 161.45.3.??? out of our campus class B address assign-
ment.  This system then subnet's this class C on 255.255.255.192 (2 subnet
bits and 6 host bits) for 4 subnets:

	161.45.3.0	subnet #1
	161.45.3.64	subnet #2
	161.45.3.128	subnet #3
	161.45.3.192	subnet #4

TCP/IP is enabled in the Novell server and forwarding and RIP are turned on
as well.

Now, we have a virginning campus network that started off in just one depart-
ment.  We have a class B assignment of 161.45 that will eventually service
every desktop on campus by next summer with our new fiber network.  Anyway,
right now (and I mean just for right now) we have no subnets on campus and
our mask is 255.255.0.0.  We use a broadcast of 161.45.255.255.  All of this
will change next spring.  

Now, what I want to do is use this UnixWare system we have just installed
(which was a USL SVR4.2 system before UnixWare so, ie, no difference in the
core unix system) as a gateway/router between the novell server network
and the campus network / internet.  Note, we have done enough testing to know
that routing WITHIN the novell subnet with the novell server as the router
between tcp/ip hosts (like LAN Work Place for DOS) on the different 4 branches 
is doing just fine.

Now, a side note (one of many :-)).  The novell server is in our library which
is a physically different location from the connection point to the current
campus network.  Since we don't have fiber in the ground yet, we opt'ed for
a wireless bridge (using Part 15 spread spectrum at 900mhz).  We are using 
a 2mbit/sec AirLAN bridge.  For what it is worth, the bridge works GREAT!  
But anyway, the bridge essentially extends the "cable" from the connection
point to the campus network over the air to the unixware box interface el31.
Besides, the bridge just send ethernet frames so routing isn't even an 
issue at its level.  

Anyway, I configured the UnixWare box as a gateway (set IPFORWARDING = 1 in
the kernel) and enabled routed and setup an /etc/gateways file and it 
did not work!  And what follows is many hours of dissection to try and under-
stand what is happening and why and how to correct it.  While I have worked
with TCP/IP for some time and have configured routers like our campus 
proteon, this situation, IMHO, should work, but doesn't and I finally got
so fed up that I am posting and I hope that someone reading this may email
me a one-liner and the world me go on its merry way!  :-)

Well, here goes....

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

Novell Configuration:

: load tcpip forward=yes rip=yes
: load snmp
: load snmplog

4 cards (all Ethernet_II frames on same NE2000 with 802.3 frames with IPX/SPX)

161.45.3.1	netmask 0xffffffc0	broadcast 161.45.3.63	RIP (subnet #1)
161.45.3.65	netmask 0xffffffc0	broadcast 161.45.3.127	RIP (subnet #2)
161.45.3.129	netmask 0xffffffc0	broadcast 161.45.3.191	RIP (subnet #3)
161.45.3.193	netmask 0xffffffc0	broadcast 161.45.3.255	RIP (subnet #4)

Larger Campus Net Configuration:

Netmask everywhere (for right now) = 0xffff0000
Broadcast Address		   = 161.45.255.255
Internet Router 		   = Proteon 4100 (w/ IP / RIP)

General UnixWare / USL 4.2 Configuration:

UnixWare Application Server 1.0 (aka USL SVR4.2v1)

486-50 ISA with 8mb RAM and 400mb diskspace.  IPFORWARDING = 1 in
/etc/conf/pack.d/ip/space.c.  

Ethernet cards = 2 3Com 3C509 Etherlink III 16-bit 10Base2 cards with drivers 
		 provided by USL / Univel.

Some host / network addresses:

network mtsunet = 161.45.0.0 (campus network)
host ulibnet = 161.45.3.194 unixware interface on same branch as novell 
	       subnet #4 [interface name el30]
host airlan = 161.45.32.128 unixware interface on same branch as campus
	      network [interface name el31]
proteon router = 161.45.64.254 on campus network
main server = 161.45.1.1 on campus network

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1) here we have ONLY ONE card being initialized.  Just the card linked
   to the Novell server.  routed is running but NO /etc/gateways entries.
   With only this one card coming up, the TCP/IP network works PERFECTLY!!!!
   Routes shown to the various Novell server subnetted-networks are 
   received by RIP BROADCASTS from the Novell server!!!!

# netstat -nr
Routing tables
Destination          Gateway              Flags    Refcnt Use        Interface
127.0.0.1            127.0.0.1            UH       0      0          lo0
161.45.3.64          161.45.3.193         UG       0      0          el30
161.45.3.128         161.45.3.193         UG       0      0          el30
161.45.3.192         161.45.3.194         U        0      31         el30
161.45.3             161.45.3.193         UG       0      0          el30

# ifconfig el30
el30: flags=23<UP,BROADCAST,NOTRAILERS>
	inet 161.45.3.194 netmask ffffffc0 broadcast 161.45.3.255

# netstat -ir
Name   Mtu   Network     Address      Ipkts   Ierrs Opkts   Oerrs Collis
lo0    8256  loopback    localhost    0       0     0       0     0
el31   1500  none        none         0       0     0       0     0
el30   1500  161.45.3.1  ulibnet      0       0     0       0     0
             ^^^^^^^^^^
		 |--------this is really 161.45.32.192 but truncated by netstat

# tail -3 /etc/confnet.d/inet/interface
el3:0::/dev/el3_0:netmask 0xffffffc0 broadcast 161.45.3.255 -trailers::
# el3:1:airlan:/dev/el3_1:netmask 0xffff0000 broadcast 161.45.255.255 -trailers:
:
lo:0:localhost:/dev/loop::add_loop:

# ps -aef | fgrep rou
root   282     1  0 17:50:28 ?        0:01 /usr/sbin/in.routed

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1) here, the only change is that the 2nd card that connects the UnixWare
   box to the greater campus WAN is brought up.  A gateways file has been
   setup too but nothing else has changed.

# tail -3 /etc/confnet.d/inet/interface
el3:0::/dev/el3_0:netmask 0xffffffc0 broadcast 161.45.3.255 -trailers::
el3:1:airlan:/dev/el3_1:netmask 0xffff0000 broadcast 161.45.255.255 -trailers::
lo:0:localhost:/dev/loop::add_loop:

# netstat -ir
Name   Mtu   Network     Address      Ipkts   Ierrs Opkts   Oerrs Collis
lo0    8256  loopback    localhost    1       0     1       0     0
el31   1500  mtsunet     airlan       0       0     0       0     0
el30   1500  161.45.3.1  ulibnet      0       0     0       0     0
             ^^^^^^^^^^
		 |--------this is really 161.45.32.192 but truncated by netstat

# netstat -nr
Routing tables
Destination          Gateway              Flags    Refcnt Use        Interface
161.45.3.0           161.45.3.193         UGH      0      0          el30
161.45.3.64          161.45.3.193         UGH      0      0          el30
161.45.3.128         161.45.3.193         UGH      0      0          el30
127.0.0.1            127.0.0.1            UH       0      0          lo0
161.45.3.192         161.45.3.194         U        0      0          el30
161.45               161.45.32.128        U        0      0          el31

Notice the change to FLAGS on the routes to the Novell server's subnets.

# ifconfig el31
el31: flags=23<UP,BROADCAST,NOTRAILERS>
	inet 161.45.32.128 netmask ffff0000 broadcast 161.45.255.255

# ping 161.45.3.0
161.45.3.0 is alive
# ping 161.45.3.1
no answer from 161.45.3.1
# ping 161.45.3.64
161.45.3.64 is alive
# ping 161.45.3.65
no answer from 161.45.3.65
# ping 161.45.3.128
161.45.3.128 is alive
# ping 161.45.3.129
no answer from 161.45.3.129
# ping 161.45.3.192
no answer from 161.45.3.192
# ping 161.45.3.193
161.45.3.193 is alive

Now, why can I ping the "networks" above and not the actual interface card
in the Novell server.  When only bringing up the one card up in the very
first senerio above, I could ping 3.1, 3.65, 3.129, and 3.193 no problem.
Something about bringing up the second interface hosed things, but why and
how?!?!?!?!  :-|

Here is the /etc/gateways in effect for this configuration:

# cat /etc/gateways
net 0.0.0.0 gateway 161.45.64.254 1 passive
net 161.45.3.0 gateway 161.45.3.193 1 passive
net 161.45.3.64 gateway 161.45.3.193 1 passive
net 161.45.3.128 gateway 161.45.3.193 1 passive
net 161.45.3.192 gateway 161.45.3.193 1 passive

Note that this DEFAULT gateway entry never even got entered into the table.
I made these passive so RIP would leave them alone but still broadcast them to
the other interfaces.

Also, not that here, the Novell server *DOES* receive the RIP updates from
the Proteon (161.45.64.254) which is basically all the Internet RIP info 
from our service provider.  At this point, *NONE* of the RIP updates from
the Novell server are showing up on the proteon or the main server.  Likewise,
*NONE* of the proteon RIP updates are showing up in the UnixWare routing 
table!

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

# tail -3 /etc/confnet.d/inet/interface
el3:1:airlan:/dev/el3_1:netmask 0xffff0000 broadcast 161.45.255.255 -trailers::
el3:0::/dev/el3_0:netmask 0xffffffc0 broadcast 161.45.3.255 -trailers::
lo:0:localhost:/dev/loop::add_loop:

# netstat -nr
Routing tables
Destination          Gateway              Flags    Refcnt Use        Interface
127.0.0.1            127.0.0.1            UH       0      0          lo0
198.146.48           161.45.64.254        UG       0      0          el31
198.146.80           161.45.64.254        UG       0      0          el31
192.221.40           161.45.64.254        UG       0      0          el31
default              161.45.64.254        U        0      0          el31
198.146.10           161.45.64.254        UG       0      0          el31
129.59               161.45.64.254        UG       0      0          el31
161.45               161.45.32.128        U        0      0          el31
149.149              161.45.64.254        UG       0      0          el31
161.45.3.128         161.45.3.193         UG       0      0          el31 ****
161.45.3.192         161.45.3.194         U        0      0          el30
192.111.110          161.45.64.254        UG       0      0          el31

**** what is the deal here?????  Why is a gateway route showing up here going
to el31 (campus wide net) showing the proper gateway at 3.193 (novell server
interface for the branch that the UnixWare box is on) and proper network 
detination?  Also, why does only the 3.128 subnet showup and not 3.0 and 3.64?
I know that the system somehow may be determining that it is "cheaper" to go
out el31 and then seek the detination 3.193, but 3.193 is not on el31 and
is a different subnet altogether.  

Oh yes, now, the RIP broadcasts from the novell server are coming in on el30 
and going out on el31 JUST FINE!  Ie, the proteon's routing tables (and other 
systems like the main server 161.45.1.1) showing the 4 subnets, and their 
gateways correctly specified as follows:

(A portion of 'netstat -nr' from 161.45.1.1 [DecStation 3100 Risc Ultrix 4.3])
161.45.3.0           161.45.32.128        UGH      0      0          ln0
161.45.3.192         161.45.32.128        UGH      0      0          ln0
161.45.3.128         161.45.32.128        UGH      0      0          ln0
161.45.3.64          161.45.32.128        UGH      0      0          ln0

Also, now the Novell Server is getting *NO* routing updates from the proteon
nor UnixWare!  

Here is the UnixWare's interface statistics in this senerio:

# netstat -ir
Name   Mtu   Network     Address      Ipkts   Ierrs Opkts   Oerrs Collis
lo0    8256  loopback    localhost    2       0     2       0     0
el31   1500  mtsunet     airlan       0       0     0       0     0
el30   1500  161.45.3.1  ulibnet      0       0     0       0     0
             ^^^^^^^^^^
		 |--------this is really 161.45.32.192 but truncated by netstat

I did some pings again to various addresses from the UnixWare system:

# ping 161.45.3.193
no answer from 161.45.3.193
# ping 161.45.1.1
161.45.1.1 is alive
# ping 161.45.3.0
no answer from 161.45.3.0
# ping 149.149.11.6
149.149.11.6 is alive

Note the last indicates that the UnixWare is now routing to Internet!

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I do not think that there is a problem with the Novell 3.11 Server in terms
of routing information it is providing.  Of course, I could be wrong.  I am 
afraid I just don't know enough about what it is sending.  :-)  But it appears
to be OK (especially with just the one card enabled, it worked as expected).

Note that we are a site license for USL SVR4.2v1 and had installed it on
this unix node in question with EXACT same behavior.   Also, at one point 
we had only the 1 3C509 and an older Western Digital WD8003E with same
behavior.  We then installed UnixWare and same thing.  So, basically I guess
it must be me!  :-)  HELP!

What is really weird is that when el30 comes up by itself, the novell server
and the unixware server worked exactly as one would expect and all routing 
and so forth did perfectly.  Then, bring up the el31 card AFTER the el30 
card and the novell server gets RIP updates from the proteon but the proteon
does not get RIP updates from the novell server and the UnixWare server's
routing table gets only RIP from the novell server and not the proteon.  Swap
these so that el31 comes up by itself, you have a perfectly running host 
on the Internet.  Bring up el31 and then el30 second, then the novell server
gets NO RIP updates, the UnixWare server gets RIP from the proteon and nothing
from novell server and the proteon gets RIP from the novell server.  ARGH!
I am stumped!  It has to be simple, right?!?!?!  

What might be happening here?  Since the el30 is 161.45.3.??? with netmask
of 0xffffffc0 (and this HAS to be this way and we did try 4 seperate Class C's
on the novell server with 0xffffff00 and SAME thing) and the el31 is a more
general 161.45.???.??? with mask 0xffff0000, is the routed algorithm confused.
Sounds like gated may be appropriate.

I know that it may be simpler to just get an old 286 and put 2 cards in 
it and PC Route or KA9Q and do it that way, but that is not what we want
to do nor should we have to, IMHO.  UnixWare "should" do fine, right?

I tried gated 3.0 on the UnixWare system and got some better table setup but
RIP was royally screwed and all this is because I certainly don't understand
gated but I am convinced that it is a better solution.  Also, someone told me
that he had read that in a system with more than one interface, that the
first interface came up as RIP "master" and all others as RIP "slaves."  I
had not personally come across this information, but in a way the behavior 
I have been seeing sort of makes that sound possible.  He said that gated
was better in that sense since you could have individual control over
each interface and explicitly have it "master"/"slave" or "both".  The guy
is no dummy and also said that he wasn't sure about it either but he had read
something like that somewhere.  At this point I would believe devine inter-
vention.

Anyway, using either gated 3.0 or gated 2.1 as the foundation, could some gated 
guru reading this PLEASE email me a gated config file that would satisfy 
my desired end goal of having the unixware box act as a router between the
novell network and the campus WAN / Internet using RIP?  I have gated 3.0 
running so it would be preferred.  I would be eternally grateful!   :-)
I am pretty good at this stuff and getting stumped like this really makes you
feel dumb (which is a good reality minder) and all I want to do is understand.
For what it is worth, I have read the sections in _TCP/IP Network 
Administration_ from Nutshell, stuff in Comer's book, and some other stuff
so I understand what should be happening, I just can't seem to make it
happen!  :-(  Maybe I am missing the forest for the trees so please, if you
have some ideas, I really would like to hear from you.

Sorry to be so verbose but this has been such a stumper for me I felt that
I should paint as clear a picture as possible.  If I have left out some 
important info, please speak up.  I will try and get whatever additional 
information anyone might need.

NOTE: Direct EMAIL replies would probably be best as this is certainly not a
late breaking industry issue.

Thank you very much for taking time and patience to put up with this.

Mark

--
						   ^
System Administrator, Workstation LAN              |          Mark J. Bailey
Department of Computer Science               NFS - * - YP     root@mtsu.edu
Middle Tennessee State University                 / \         615-898-2397
Murfreesboro, Tennessee  37132  USA             TCP DECnet    615-898-2378

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19 Sep 1993 15:11:41 GMT
From:      M.T.Hamilton@lut.ac.uk (Martin Hamilton)
To:        comp.protocols.tcp-ip
Subject:   Re: FTPD question (WU version)

karl@genesis.MCS.COM (Karl Denninger) wrote:

> We have someone here who would like to have a "semi-private" area for FTP
> transfers set up.  I don't want to just make another user; what I'm looking
> for is a way to have FTPD do its own authentication for some number of
> user(s) and place them in an area which is "restricted". 

Here's what I did with the wuarchive ftp daemon...

Create a group called (say) "incoming" -- in /etc/group

  incoming:*:4321:

Create a user, say "deposit", in this group -- with a null shell:

  deposit:rM/IH02ZMKDFqY:133:4321:FTP in:/home/ftp/./deposit:/bin/sync

(you may need to add /bin/sync to /etc/shells or equivalent)

Make their home directory, e.g. /home/ftp/deposit in this case

  # mkdir ~deposit
  # chown deposit.incoming ~incoming

Add a "guestgroup" entry to ftpaccess, e.g.

  guestgroup incoming

..and that's it! :-)

Martin

PS You'll probably want to customise the upload/permissions stuff

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 1993 19:36:23 GMT
From:      trall@almaden.ibm.com (Tony Rall)
To:        comp.unix.sys5.r4,comp.dcom.lans.ethernet,comp.protocols.tcpip,comp.unix.admin,comp.dcom.lans.misc
Subject:   Re: WEIRD problem with UnixWare router and 2 networks!  Help!  (LONG)

In article <27hm50$5jh@perot.mtsu.edu>, root@perot.mtsu.edu (Mark J.
Bailey [Admin]) writes:
( a long description of a routing problem)
|> ...
|> Now, we have a virginning campus network that started off in just one
 depart-
|> ment.  ...

(If your network is continually unsullied, I would think you wouldn't have any
problems. :-)  I think you mean "burgeoning".)

I'm no guru and have experience with NONE of your IP implementations, so 
consume several salt grains with this.

I'm not going to try to answer all the questions that were raised; in fact,
I can't explain most of them.

I do believe that you're suffering from a basic flaw in your configuration,
and the problem has nothing to do with the version of routed/gated you're
using or, in fact, the IP code on your various systems.

You have two overlapping networks - what is the Unixware router to do?  It
see RIP packets coming in from the Novell server that say that it is the
gateway for 161.45.3.*.  And its other interface is purported to be on
network 161.45 - that means the entire 161.45 network can be accessed via
that interface (which is not true).  I have the feeling that you can't do 
this.  The Unixware system thinks it has direct access to the entire 
161.45 network over its second interface (el31).

Sorry, I don't have any suggestions for resolving this problem, short of
immediately going to your fully subnetted setup.

(Hey, it was either read and respond to this post, or watch football.
Easy choice.)

Tony Rall                       IBM Almaden Research Center
trall@almaden.ibm.com           Voice: (408)927-2667   Fax: (408)927-4115

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 1993 23:09:40 GMT
From:      ccwf@gg.caltech.edu (Charles Fu)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: Bug in inet_addr()?

lees@austin.ibm.com (Lee Slaughter) writes:

>In article <CDK82F.3z6@news.iastate.edu> john@iastate.edu (John Hascall) writes:
>>To do this "right", you need to throw in a strcmp too (*sigh*) ...
>>
>>   if (((dest_addr.sin_addr.s_addr = inet_addr(ascii_inet_addr)) == -1) &&
>>        (strcmp(ascii_inet_addr, "255.255.255.255") != 0)) {
>>	/* error ... */
>>   } else {
  sendto(sockfd,(char *)msg,msg_size,0,&dest_addr,sockaddr_len);
>>   }
>>
 
>Sorry, the complete line is
 
>    if((snd_len=sendto(sockfd,(char *)msg,msg_size,0,&dest_addr,sockaddr_len))<0)
>    {
>      perror("sendto");
>      exit(6);
>    }
 
>I just took out the error checking for clarity.
>But the strcmp is a good idea.

And, even then, it's not quite complete since addresses may be in a
mixture of decimal, octal, and hex. I'm sure that's why "right" is in
quotes.

-ccwf

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Sep 1993 07:09:28 GMT
From:      PPOLLET@cismibm.univ-lyon1.fr (Patrick POLLET)
To:        comp.protocols.tcp-ip
Subject:   Unix to code time conversion code ?

Hi all,

   I am looking for source code (either Pascal or C) to convert 
the Internet time returned by a time server to a Day,month,Year;Hours,Min,Sec
record.
  I know that there is a C routine called unixtodos() in Turbo.C dos.h 
library but I am programming in turboPascal and such a beast do not
exist .
Thanks
ppollet@cismibm.univ-lyon1.fr (Patrick POLLET)
--------------------------------------------------------
Dr Patrick L.Pollet
INSA Centre Informatique du 1er Cycle  Bat 110
20 Avenue A.Einstein  69621 Villeurbanne Cedex France
--------------------------------------------------------
Phone: 72 43 83 80 -   la premiere erreur c'est
Fax  : 72 43 85 33 -   de se lever le matin  ... GASTON
-------------------------------------------------------

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Sep 1993 07:29:07 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: Cost of small CDDI network

In article <CDCAAw.Gyx@newcastle.ac.uk> Jerry.Hagon@newcastle.ac.uk writes:

>
>We are in the early planning stages of designing a small network of UNIX
>workstations for use in distributed parallel processing. We would like to
>have the highest data transfer rates possible (within our budget) and were
>wondering about a CDDI network with machines connected by shielded twisted
>pair cable which I understand has a bandwidth close to 100 Mbit/s. 

Jerry,

CDDI (also called TPDDI - twisted pair) is intended to run over 
unshielded 100 ohm, the same as 10baseT cable.  There is some controversy
over whether level 3 (4, not used much) or 5 should be used.  In your
case, with no existing UTP installed (?) your choice is simple - level 5.

Unshielded is better than shielded for these high frequencies, because it
preserves the characteristic impedance of what are in effect two
transmission lines (twisted and snuggling in a common sheath).  Shielding,
among other things (including screening from emissions, which is not
always needed) changes the impedance characteristics and inhibits correct
performance at the frequencies needed.

> .... We would also want our network connected to the
>campus ethernet probably via a dedicated bridge. 

This is where you may have problems (which FDDI/CDDI) salespersons 
won't readily admit.  Any bridge (and other ?-DDI station devices)
will have a latency which may slow down their frame transit.

You probably need to work out exactly why you need the highest 
bandwidth, as you mention.  If you're looking for high data volumes
(ie. packets/sec) then FDDI/CDDI etc can achieve a composite
throughput approaching 100 Mbits/sec.  This is excellent for combining
several 10Mb/s Ethernets into a common backbone (eg. the well known
FDDI campus ring).

However, if you are looking for fast response times, CDDI may not be as
good as it seems at first site. The transit delay will not be ten times 
better for 100Mb/s CDDI (or FDDI) than it is for 10Mb/s Ethernet. This is 
due to the latency in all the devices and components between any pair
of communicating stations.  I suspect that the devices which will
slow your transit down to roughly Ethernet speeds will be: the internal
card driver s/w (?), the CDDI cards, the CDDI hub (?) and any bridges
or routers in between.

Good, tuned, optimised Ethernet bridges have a latency of between about
70 and 120 microsecs. This is barely noticable on Ethernets (by
measuring the transit delay with and without a bridge).  In order to 
achieve a ten times better/faster frame transit, then any bridge (or 
other device) ought to have a latency something less than 10 microsecs
(which, for 1500 byte frames is pushing electronics to its limits).

>... If our network expands
>we may also need to consider multiport repeaters and the like. Is this
>just a pipe dream or can the infrastructure for such a network be set up
>at a reasonable cost. The machines making up our network will almost
>certainly be RS6000's, HP9000's and SUN Sparcs. Initially we are likely
>to have about 10 machines on the network. Any approximate idea of how
>much more expensive this would be than standard 10 Mbit/s ethernet?

Sorry, I can't really help there.  However, CDDI should be very low 
cost (100 per outlet, assuming less than 90 metre runs).  The main cost
will be in the CDDI devices.  These are very expensive.  

If you really need low transit times (as distinct from just high volume
throughput) then you may consider FDDI and laying fibre to each host.
FDDI "Station Management" is not yet standardised, but I believe there
are good products available which are intended to intercept the standard.

I believe these are designed to be optimised for FDDI ring traffic and
have very low latency.

Contact 3Com, UB, Cabletron, Synoptics, Hughes etc.

Hope this helps.

-- 

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 

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 93 09:13:33 GMT
From:      token@ernohb.UUCP (Thomas.Kendelbacher)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: TCP programming question

In article <1993Sep17.153914.15610@midway.uchicago.edu>, spchuid@cicero.spc.uchicago.edu (Hui Dong) writes:
|> TCP suppose to provide reliable data transfer, but when I wrote a client-server
|> model shipping large files, I find some data are lost, I am pretty new to
|> TCP programming, so any help from experts here are appreciated.
|> 
|> After I set up a TCP connection, I need to ship big file from server to client,
|> I break up the file into chunks of say 512Byte data on the server, then I
|> "send" the chunks in a while loop on server. On client, I "recv" chunks of
|> 512Byte data in a while loop, but everytime have to do some I/O to disk, so
|> client is slower than server. Now, I notice some data lost on the client,
|> I assume that might be because the server "send" data too fast, not aware of
|> the client can't take it more, no blocking on the "send" function (although
|> there should be "window" reported from client, but that can be only on the
|> system data buffer level, I am not sure). I check sizes of real data sent or
|> received on server and client, the server always sent 512Byte successfully,
|> but the client sometimes only received smaller size data (say 398Bytes etc.).
|> Now, if I put a "recv" in the while loop on the server to get a dummy "int",
|> "recv" will block until the client finished I/O to disk and "send" the dummy
|> "int", this way kind of synchronize the action on both sides, the problem
|> disappear. This experience is contrary to my understanding that TCP should
|> block "send" and so synchronize the server-client communication automatically,
|> or it might be I have a misconception here. Any clearification will be
|> appreciated.

Nothing's wrong with your TCP. If you RTFM, you'll find that a read/recv
operation will return the number of bytes actually read, which is the number
of bytes that is currently available. Remember, what you get is a byte stream,
not a sequence of packets of a fixed size, even if you always "send" fixed
size chunks! So, what TCP transmits at one point may well be just 398 bytes
of your chunk, with the rest coming in the next transmitted block of data.
What you have to do is:
  1)	Check how many bytes have been read/recv'd. (You would do that
	anyway to check for errors.)
  2)	If these are less than your expected chunk size, just read/recv
	again (and again and...) --after incrementing the buffer pointer by
	the number of previously read bytes, of course-- until all your
	512 bytes are complete. These will indeed be reliably transmitted,
	and in sequence, unless an error occurs (which will be flagged by
	an error return code instead of a positive number of bytes read).
THIS WILL WORK, and solve your problem.

Hope this helps,

Thomas Kendelbacher, ROT133   |   email : Thomas.Kendelbacher@erno.de
ERNO Raumfahrttechnik GmbH    |   voice : +49 421 539 5492 (07.00-15.00 GMT)
Postfach 10 59 09             |      or : +49 421 57 04 37
D-28059 Bremen
Germany

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Sep 1993 10:45:08 GMT
From:      shewison@brookes.ac.uk (Simon Hewison)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Why not some standard TELNET command lines?

In article <Sep.16.15.12.48.1993.18024@grimaldi.rutgers.edu>, jim@grimaldi.rutgers.edu (Jim Martin) says:
>So, it would be easy to parse things the way you suggested, but
>unfortunately, along came rfc1123, which says:
>
>      The syntax of a legal Internet host name was specified in RFC-952
>      [DNS:4].  One aspect of host name syntax is hereby changed: the
>      restriction on the first character is relaxed to allow either a
>      letter or a digit.  Host software MUST support this more liberal
>      syntax.
>
>So, alas, we can't make any kind of assumption about what will be in a
>hostname :( If _anyone_ has a better idea, _PLEASE_ let me know.
>

Basically, for parsing a name, try this algorithm:
Does the string contain three dots, with a valid number between 0 and 255 in
each field? If so,

Try to parse it as byte.byte.byte.byte If any of this fails, then do a name lookup
on it.

If you're in charge of assigning names, keep to the original standard, or you
WILL have problems with people not being able to contact your machine by
name.

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Sep 93 12:14:53 GMT
From:      philippe@diver.cfmu.eurocontrol.be (Philippe Waroquiers)
To:        comp.protocols.tcp-ip,comp.sys.hp,comp.unix.programmer
Subject:   reliability => duplicate LANs. How to configure it?


Our project requires to have an high availability for the communication
between the workstations and the application servers. For this,we have
in each computer two lan ethernet lan cards. The situation is thus the
following :

                                LAN A
       ____________________________________________________________.........
       |                            |                       |
       |srvad1                      |                       |
    SERVER                     workstation1          workstation2
    COMPUTER                        |                       |
       |srvad2                      |                       |
       |____________________________|_______________________|_______......
                                LAN B

Note : there is one hub (not in the drawing) for each LAN.
TCP/IP is the protocol used.
Workstations and server are HP-UX PA-risc 1.0 and 1.1 computers running
HP-UX 9.0

OBJECTIVE :
The objective is that in case of failure of a component (i.e. either the
cable, a LAN card in the server or in a workstation, the hub), the failure is
as transparent as possible. Among others, it is desirable that the applications
do not notice the failure (except for the delay required to switch the route).
The delay should be short (let's say less than 1 minute).
QUESTION :
What is the best way to configure the routers inside the SERVER and the
workstations to achieve the objective ?


For the moment, the best (?) solution we currently have is not based upon 
automatic rerouting :
In each workstation and server, a script runs.
Every ten seconds, this scripts tries to ping the first address of the server
or workstation. If the server or the workstation does not respond, then
the route table of the workstation and server are changed so that a new
route is defined in order to reach the other system (workstation or server)
through the other interface.


--
Philippe WAROQUIERS             Eurocontrol - Central Flow Management Unit
philippe@cfmu.eurocontrol.be    Avenue des Arts 19H
Tel: +32 2 729 33 67            B-1040 BRUSSELS
Fax: +32 2 729 32 16            Belgium

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Sep 1993 14:18:13 GMT
From:      cslee@pds.nchu.edu.tw (Lee Chee Siong)
To:        comp.protocols.tcp-ip
Subject:   Re: gopher client for MS-DOS, MS-Windows, etc.

In article <277ssb$8gn@mozz.unh.edu> walt@unhsst.unh.edu (Walter R. Trachim) writes:
>From: walt@unhsst.unh.edu (Walter R. Trachim)
>Subject: gopher client for MS-DOS, MS-Windows, etc.
>Date: 15 Sep 1993 20:10:51 GMT
>Subject says it all - does anyone know where I can find one?
>
>Replies to e-mail are ok; I don't want to tie up bandwidth....
>
   Try to use anonymous ftp to boombox.micro.umn.edu:/pub/gopher


<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
<>   CS Lee  (Lee Chee Siong  §õ§Ó²»)           <>  If you can give     <>
<>   System Manager of Computer Center          <>        nothing else, <>
<>   National Chung Hsing University,           <>                      <>
<>   Taichung, Taiwan, Republic of China.       <>  at least give a     <>
<>   Internet Address: cslee@pds.nchu.edu.tw    <>        cheerful face <>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Sep 1993 15:19:04 GMT
From:      woody@praxis.co.uk (Paul Woodman)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.misc,comp.os.ms-windows.setup
Subject:   Re: Problem with comb. of Dell 425s/L, PC-NFS and ET4W32 windows-drivers

vharten@prl.philips.nl (Peter R. van Harten) writes:

>Hi troubleshooters,
 
>We encountered a problem using a brand new Dell 425s/L with Tseng ET4W32 
>chipset and PC-NFS. When using the Dell ET4W32 video-drivers under Windows, we 
>see that screen updating is disturbed. There are several white or black 
>rectangles. We tried several network cards/drivers: no difference. PC-NFS 4.0a 
>or 5.0a: no difference, ET4W32 version 1.0, 1.0a, 1.1: no difference. When 
>using VGA or ET4000 drivers, the problem vanished, so we suspect the Dell 
>ET4W32 drivers, but we only see the problem, when using PC-NFS. When 
>mounting/unmounting drives, the effects are different. (?) We have never 
>problems like this before.
 
>Can anyone help us out ...?

 I have exactly this problem. I called Dell and didn't get very far.

 I posted to this group and got a very helpfull reply from Paul Carroll
 at Sun who suggested that Dell should swap the motherboard for the S3
 version.

 [In fact, Dell do advertise all the "L" range as having S3 local bus video
  but they have a supply problem with S3 at the moment and most of the "L"
  range is now being shipped with Tseng. However, they don't tell you this
  in advance, they don't tell you that you can order either S3 or Tseng to
  taste and they don't tell you that they will swap the motherboard if the
  choice of video gives conflicts. X windows fans should also note that 
  they don't tell you that they will supply with 3 button mice for no extra
  charge.] 
  
 As a result of my post, I got a personal Fax from Kathleen Bishop at Tseng
 Labs tel (215) 968-0502. She said:

 "We have learned of your problem through internet and have a solution.
  Our latest windows 3.1 drivers dated 8/26/93 should correct this problem.
  the file is posted on our BBS (215) 860 04530 as W31W32.ZIP."

 Top marks to Kathleen and Tseng. I haven't had time to get these drivers
 yet so can't say that they will work for you.

 Best wishes,
    Woody.


                               Paul Woodman  
                               Systems Manager
                               Praxis plc,
\          /           |       the software engineering company of Touche Ross, 
 \        / ___  ___  _|       20 Manvers Street, Bath, BA1 1PX, UK.
  \  /\  / /  / /  / / | \  /  Tel +44 225 444700 xt228
   \/  \/ /__/ /__/ /__|  \/   Fax +44 225 465205.
 _________________________/    woody@praxis.co.uk                       
These opinions are mine and do not represent Touche Ross or Praxis.

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 1993 18:55:43 GMT
From:      jbotz@mtholyoke.edu (Jurgen Botz)
To:        comp.protocols.tcp-ip
Subject:   telnetd[9738]: ttloop:  peer died: Invalid argument

At some irregular intervals I've been seeing the following 
behavior at a site for which I do some consulting work...

- My remote login session to the site dies.

- If I try to start another telnet session a connection
  appears (i.e. telnet says "connected to...") and then
  immediately dies with "host unreachable".

- ICMP (ping, traceroute) seems to go through fine.

- Some UDP services I was able test worked.

- Connecting to the NNTP port on the machine in question
  gave me the servers greeting message and then died with
  "host unreachable" once I hit a key.

- A little while later everything is back to normal.

- "telnetd[9738]: ttloop:  peer died: Invalid argument" appeared
   in the syslog on the machine in question, with the time-stamp
   matching my attempted telnet connection.

In summary, everything seemed to work except TCP connections which
seemed to be aborted at the local end after an initial connection
(with data being received) was made.

What's a "ttloop"?  What could be causing this?  I suspect
poorly configured routing, but I know very little about this
aspect of networking.
-- 
Jurgen Botz, jbotz@mtholyoke.edu | ``Accountability is the price of openness''
South Hadley, MA, USA            | - Daniel Geer


-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 93 19:27:03 GMT
From:      swengr@eskimo.com (Ricky Leong)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP

I'm also interested in knowing what SLIP is.  I'm interested
in using it from a Mac.  Basically, I'd like to know if SLIP will
allow me to run something that requires TCP/IP from my modem.
Any information on SLIP would be greatly appreciated.
 
Thank you.
 
- Ricky
 

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Sep 93 19:47:10 GMT
From:      wagner@ost.com (Mitch Wagner)
To:        comp.unix.questions,comp.protocols.tcp-ip,comp.sys.novell,comp.unix.osf.misc,comp.os.ms-windows.advocacy,comp.os.os2.advocacy
Subject:   net.views ... middleware


          What is the one now-nonexistent piece of middleware
          that you'd like to see?



We're asking this question to collect opinions for the "net.views" column in
OPEN SYSTEMS TODAY. Please E-mail your responses to wagner@ost.com
 
By responding to that address, you'll be granting permission to OST to publish
your response.
 
In order to use your response, we'd like to know who you are. Please tell us
your real, full name, your job title, your employer, and location---or,
alternately, if you're a student, your class standing (freshman, sophomore,
junior, senior, grad, etc.), college and university, and its location. Please
also include a telephone number where you can be reached during daytime hours
in North America.
 
Please limit responses to about two full screens (24x80) of text, not including
headers and other administrivia.

Responses to net.views will be posted to this space shortly.
 
Thanks for participating, and we look forward to hearing from you!

 
                         -- mitch w.
--
Mitch Wagner, senior editor, Open Systems Today
2353 Massachusetts Ave. Suite 47, Cambridge, MA 02140
wagner@ost.com  (617)547-8485  CIS:70212,51  GEnie:MITCHWAGNER  
For subscription information, please call 516/562-5882


-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 1993 21:18:55 GMT
From:      greg@carnivore.tamu.edu (Greg Economides)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.misc
Subject:   using SLIP on a machine w/o modem


I am beginning to experiment with SLIP and seem to have come to a standstill.
What I am trying to do is to have SLIP installed on the Internet host
(Sparc, SunOS 4.1.3) and connect to it by phoning another host first (the
terminal server lines supplied by the University), then connecting (telnetting)
to the Sparc.

It appears that the way SLIP is intended to be used is on a machine that has
the modem/serial line connected directly to it.  This means, in my setup,
that I would have to have SLIP set up on the terminal server lines which
have the modems connected to them.  Since the term. servers are not under
my control, I want to make the SLIP connection via my Sparc.

Is it possible to do this?  Is there already a 'slip-attach'-like program
for doing this, or will I have to hack the code I already have?

Peace,
greg




--
Greg Economides,   Systems Administrator, Center for Biosystems Modelling
Texas A&M University
WERC 214-O
Internet: econ@tamu.edu, Phone: (409) 845-9574

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Sep 1993 21:59:15 GMT
From:      terry@rod.mitre.org (Terry Reed)
To:        comp.protocols.tcp-ip
Subject:   Trouble with Sun FDDI card in SPARC2 using NIS

I have a Sun SPARC2 running SunOS 4.1.2 that I'm adding a Sun SBus FDDI
card to. My goal is to use the SS2 as a router for a small FDDI testbed
that I'm setting up (all of other machines are currently on Ethernet only).
This machine uses a Sun 370 (SunOS 4.1.2) for a NIS server.

I'm trying to set up the FDDI side of the SS2 as a different subnet on the same 
class B address (e.g., subnets 128.29.149.0 for Ethernet & 128.29.148.0 for FDDI However, when the ifconfig statement for the FDDI i/f is executed in rc.local,
the machine is no longer able to communicate with the NIS server, i.e., get NIS timeouts.  Out of desperation I changed the FDDI i/f IP address from 
128.29.148.1 to 128.27.148.1 (i.e., different Class B address) & the machine
comes up fine.  Why is this?  In the past I've set up Suns using local tables
rather than NIS with Ntwk Peripheral FDDI cards & not had this difficulty.
I tried moving the ifconfig statement for the FDDI i/f around (e.g., I tried 
putting it as the last statement in rc.local), but to no avail.  I`m 
admittedly not exactly a NIS expert since I've mainly dealt with 
local tables in the past.

I checked to ensure that both the Ethernet & FDDI i/f's had the same subnet
mask, that the FDDI i/f was properly listed in NIS, etc., but cannot figure
this out.  Any help or hints would be much appreciated.  E-mail replies are
preferred (but I'll take what I can get :-) ).  Thanks.

     Terry Reed
     MITRE
     (703)883-6401
     terry@mitre.org

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Sep 1993 22:00:26 GMT
From:      iddptm@iddss1.iddis.com (Paul T. Marquis)
To:        comp.protocols.tcp-ip
Subject:   What's going on here?

Hi everyone,

We're trapped in a dilemma and we don't know what to do.  When initiating
an FTP session to one machine (a Pyramid MIServer-ES) and trying to pull a
file from it in binary mode, we get back a file that is smaller than the
original file.  If I do it again, I again get a smaller file, but this time
with a different size.  I get inconsistent file sizes regardless of what
machine I start the file transfer from, or if I originate the transfer from
the Pyramid itself.  Also, it appears this is only a one-way dilemma, as I
can send files to the Pyramid without problems (at least till now).

Any pointers as to where to trace the problem?  Could it be an FTP bug on
their end (both in the client and the server)?  Please help!

Thanks a lot!

--
Paul, the Edge, Marquis
pmarquis@iddis.com

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Sep 1993 03:57:25 GMT
From:      plate@cdsmn.mn.org (Doug Plate)
To:        comp.protocols.tcp-ip
Subject:   NNTPD Configuration on UNIX System


I am trying to set up an nntp server on our Interactive UNIX system to
feed hungry PC's over tcp/ip.  There is an nntp server on our system
(nntpd ver. 1.5.8. Mar. 90, Stan Barber), but no configuration docs.
I realize there must be a configuration file required to tell it who
to connect to, etc, but if it exists, I can't find it.  When I try to
talk to it, I get a message saying that the nntp server can't talk to
me and I assume it's because it's not configured to.

Can anyone help me get this running, or point me to another nntpd
that is free and has docs?

Regards,
Doug Plate Sr.
-- 
      ()(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)*(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)()
     /                    plate@cdsmn.mn.org                           \
   /         /      Doug Plate Sr.    | "Assume no malice!"   \          \
 (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Sep 1993 04:45:23 GMT
From:      John Matthews <matthews@mis.uswest.com>
To:        comp.dcom.modems,comp.protocols.tcp-ip
Subject:   GOOD Pocket Modem(s) for SLIP?

Does anyone have any GOOD recommendations for a pocket modem that
can run SLIP with V.42bis compression enabled?  I've been running
some tests with the U S Robotics WorldPort 14,400 Fax/Data modem
and I'm noticing that whenever compression is enabled, it adds quite
a bit of delay to the roundtrip times on ping (also visably noticable
when typing via telnet).  I've talked to U S Robotics and they claim
that there's nothing they can do about it.  They do have software
for their other larger black standalone modems that allow SLIP to
work quite well with V.42bis compression enabled but claim that there's
nothing they can do with the WorldPort 14.4 pocket modem.  I know I can
run SLIP without compression enabled and the delay times are consistent
and reasonable, but I'd like to take advantage of the compression because
I know that on the other U S Robotics modems I've tested, the V.42bis
compression does improve the delay time for telnet as well as the overall
throughput for FTP.  Does anyone know of a good pocket modem that doesn't
add delay with compression enabled and also has good power support via a
cable that could steal power from the keyboard connector the way the Xircom
PE3 ethernet adaptors do?
				Thanks in advance,
					John Matthews
					matthews@mis.uswest.com

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 1993 13:25:25 -0500
From:      pwickman@carroll1.cc.edu (Paul Wickman)
To:        comp.protocols.tcp-ip
Subject:   YP (NIS) over routers


	I;ve been told that YP(NIS) will not work over routers.  Does that
mean at all?  the only problem that I could forsee is when a client broadcasts
for a YP server adn there isn't one in the subnet, that would be a problem.
But since the map transfer from the master server to the slave servers is
not done via broadcast, it seems that should work fine over a router.  As
long as there is a slave server in the subnet available to broadcasts, 
wouldn't everyting be OK?

Email answers, I'm sure not to many people are interested

-- 
Paul J. Wickman - Network Analyst/Programmer - Harnischfeger Corporation
Internet: pwickman@carroll1.cc.edu	Phone: 414-671-7778

"Some people should die, that's just unconscious knowledge" - Jane's Addiction

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 93 08:49:02 GMT
From:      huitema@mitsou.inria.fr (Christian Huitema)
To:        comp.sys.sun.admin,comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: How to kill every SUN on your network.

In article <CDJ1DD.7FA@cup.hp.com>, raj@cup.hp.com (Rick Jones) writes:
|> DON BERRYMAN (BERRYMAN@orca.drep.dnd.ca) wrote:
|> 
|> : Title: How to kill every SUN on your network.
|> : Alternate Title: How to be lynched
|> 
|> [Bunches of good details deleted]
|> 
|> #begin SOAPBOX
|> This is why one SHOULD NOT bridge FDDI and Ethernet together.
|> This is why one SHOULD route FDDI and Ethernet together.
|> #end
|> 

Absolutely. "Transparent bridging" between incompatible networks (different
MTUs) is by and large a violation of the architecture. The box should really
have router functionality. It should in particular, as you mention, be able to
do IP fragmentation and also to send back ICMP messages for large packets
where the fragmentation is not allowed.

Christian Huitema

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 1993 17:38:46 -0400
From:      gronbeck@access.digex.net (Christopher Gronbeck)
To:        comp.protocols.tcp-ip
Subject:   Where is FAQ (New SLIP Mac User Needs Help)?

I have a mac, a modem, MacTCP, and a SLIP account from a dial-in service. 
I can't get anything to work, and probably need to get InterSlip, I have
been told.  The applications I need to run are TurboGoher-type stuff.  So
where's the FAQ?  Thanks.

Christopher


-- 
Christopher Gronbeck
Center for Renewable Energy and Sustainable Technology (CREST)
Funded by the Solar Energy Research and Education Foundation
gronbeck@digex.net

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Sep 1993 12:13:30 GMT
From:      albertk@cs.kun.nl (Albert Koppes)
To:        comp.protocols.tcp-ip
Subject:   FTP under programmatic access ?

Is there somebody having experience with 
ftp under programmatic access ? N

Suppose one would do it via port 21,
according to my current understanding, one
needs to send the data over the datasocket,
doing segmentation  and other
housekeeping yourselves.

Isn't there some way just to
open the connection under programmatic
control and issue a getfile("xxx")
command or something.

I remember that FTP Software has
this kind of interface, but is somebody
aware of a UNIX-C method for this ?


Thanks in advance,

Frank


  

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Sep 1993 12:45:27 GMT
From:      andrew@megadata.mega.oz.au (Andrew McRae)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Looking for performance comparision between OSI & TCP/IP

Greetings,
I am looking for some performance comparisons between OSI
based networks and IP based networks, especially across
Wide Area Networks (i.e not across X.25 networks, but across
networks using point-to-point serial connections).

Note that I am looking for real world results, not theoretical
models or simulated systems.

The aim of the comparison is to examine the overhead of
both systems in terms of throughput, and response.

For example, it would be good to see a case study of
someone running some file transfers across a WAN
using compressed SL/IP or PPP, and running a similar
OSI based system employing CLNP, TP 4 and maybe FTAM.

Thanks in advance,
Andrew McRae			inet:	andrew@mega.com.au
Megadata Pty Ltd,		uucp:	..!uunet!mega.com.au!andrew
North Ryde  2113		Phone:	+61 2 805 0899
NSW    AUSTRALIA		Fax:	+61 2 887 4847

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Sep 1993 13:44:23 GMT
From:      etxmesa@eos.ericsson.se (Michael Salmon)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP under programmatic access ?

In article <CDpDyJ.8Er@sci.kun.nl>
albertk@cs.kun.nl (Albert Koppes) writes:
|> Is there somebody having experience with 
|> ftp under programmatic access ? N
|> 
|> Suppose one would do it via port 21,
|> according to my current understanding, one
|> needs to send the data over the datasocket,
|> doing segmentation  and other
|> housekeeping yourselves.
|> 
|> Isn't there some way just to
|> open the connection under programmatic
|> control and issue a getfile("xxx")
|> command or something.
|> 
|> I remember that FTP Software has
|> this kind of interface, but is somebody
|> aware of a UNIX-C method for this ?

One way to do it is to install alex and then let it do the ftp access
for you.

-- 

Michael Salmon

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

Ericsson Telecom AB
Stockholm

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Sep 1993 15:05:57 GMT
From:      mark@alias.com (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: Paper by Borman, Msgs by Jacobson

In <8bHW037Wda0O00@amdahl.uts.amdahl.com> mikeh@uts.amdahl.com (Mike Harvey) writes:


>Can anyone point me to online copies of:
 
> "Implementing TCP/IP On a Cray Computer", Borman D.A
>(originally in Comp. Comms. review, Vol. 19, No. 2, Apr 1989)
 
> "Some Interim Notes On the BSD Network Speedup", Jacobson V
>(originally msg. in comp.protocols.tcp-ip, July 1988)
 
> "Performance" Jacobson V
>(originally msg. in comp.protocols.tcp-ip, Nov 1988)
 
>and other TCP/IP performance SPECIFIC work. Thanks, Mike H

Here are three Jacobson articles I have, the first two of which were
asked for:

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

From uunet!HELIOS.EE.LBL.GOV!van Wed Jul 20 00:26:17 1988
Path: hsi!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!HELIOS.EE.LBL.GOV!van
From: van@HELIOS.EE.LBL.GOV (Van Jacobson)
Newsgroups: comp.protocols.tcp-ip
Subject: some interim notes on the bsd network speedups
Message-ID: <8807200426.AA01221@helios.ee.lbl.gov>
Date: 20 Jul 88 04:26:17 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 292

I told the potential beta-tests for our new 4bsd network code
that I hoped to have a version of the code out by the end of
July.  (BTW, we've got all the beta testers we can handle --
please don't apply.)  It looks like that's going to turn into
the end of August, in part because of SIGCOMM and in part
because Sun puts sending source to academic customers on the
bottom of its priority list.  I thought I'd flame about the
latter and give a bit of a status report on the new code.

I've been trying to put together a beta distribution for the
"header prediction" bsd network code.  This effort has been
stymied because it's impossible to get current source from Sun.
The code involves major changes to the 4.3bsd kernel.  The only
local machines I can use to develop new kernels are Suns --
everything else is either multi-user or has pathetic ethernet
hardware.  But the only Sun kernel source I've got is the doubly
obsolete Sun OS 3.5/4.2 BSD.  It would be a massive waste of
time to upgrade this system to 4.3 BSD just so I can develop
the next BSD -- Bill Nowicki did the upgrade a year ago and
binaries of the new system (totally worthless to me) are
shipping as Sun OS 4.0.  [I'm not the only one suffering this
problem -- I understand Craig Partridge's multicast work is
suffering because he can't get 4.3-compatible Sun source.  I
think he gave up & decided to do all his development on 4.3bsd
Vaxen.  And I think I heard Chuck Hedrick say 4.0 has all the
rlogin, URG and nameserver bugs that we fondly remember fixing
in 3.x.  And he has to get source before the academic year
starts or they won't be able to switch until a semester break.
And Mike Karels is saying "I told you so" and suggesting I buy
some CCIs.  Pity that Sun can't figure out that it's in their
best interest to do TIMELY source distribution to the academic
and research community -- their software development base gets
expanded a few hundred-fold for the cost of making tapes.]

Anyway, now that I've vented my spleen, there are some interim
results to talk about.  While waiting for either useful source
or a better hardware platform to show up, I've been cleaning up
my original mods and backing out changes one and two at a time
to gauge their individual effect.  Because network performance
seems to rest on getting a lot of things happening in parallel,
this leave-one-out testing doesn't give simple good/bad answers
(I had one test case that went like

	Basic system:   600 KB/s
	add feature A:  520 KB/s
	drop A, add B:  530 KB/s
	add both A & B: 700 KB/s

Obviously, any statement of the form "feature A/B is good/bad"
is bogus.)  But, in spite of the ambiguity, some of the network
design folklore I've heard seems to be clearly wrong.  

In the process of cleaning things up, they slowed down.  Task-
to-task data throughput using TCP between two Sun 3/60s dropped
from 1 MB/s (about 8.6 Mb/s on the wire) to 890 KB/s (about 7.6
Mb/s on the wire).  I know where the 11% was lost (an
interaction between "sosend" and the fact that an AMD LANCE chip
requires at least 100 bytes in the first chunk of data if you
ask it to chain -- massive braindamage on AMD's part) and how to
get it back (re-do the way user data gets handed to the
transport protocol) but need to talk with Mike Karels about the
"right" way to do this.

Still, 890 KB/s represents a non-trivial improvement over the
stock Sun/4bsd system:  Under identical test conditions (same
socket & user buffer sizes, same MSS and MTU, same machines),
the best tcp throughput I could get with an out-the-box Sun OS
3.5 was 380 KB/s.  I wish I could say "make these two simple
changes and your throughput will double" but I can't.  There
were lots and lots of fiddley little changes, none made a huge
difference and they all seemed to be necessary.

The biggest single effect was a change to sosend (the routine
between the user "write" syscall and tcp_output).  Its loop
looked something like:

    while there is user data & space in the socket buffer
        copy from user space to socket
    call the protocol "send" routine

After hooking a scope to our ethernet cable & looking at the
packet spacings, I changed this to

    while there is user data & space in the socket buffer
        copy up to 1K (one cluster's worth) from user space to socket
        call the protocol "send" routine

and the throughput jumped from 380 to 456 KB/s (+20%).  There's
one school of thought that says the first loop was better
because it minimized the "boundary crossings", the fixed costs
of routine calls and context changes.  This same school is
always lobbying for "bigger":  bigger packets, bigger windows,
bigger buffers, for essentially the same reason: the bigger
chunks are, the fewer boundary crossings you pay for.  The
correct school, mine :-), says there's always a fixed cost and a
variable cost (e.g., the cost of maintaining tcp state and
tacking a tcp packet header on the front of some data is
independent of the amount of data; the cost of filling in the
checksum field in that header scales linearly with the amount of
data).  If the size is large enough to make the fixed cost small
compared to the variable cost, making things bigger LOWERS
throughput because you throw away opportunities for parallelism.
Looking at the ethernet, I saw a burst of packets, a long dead
time, amother burst of packets, ... .  It was clear that while
we were copying 4 KB from the user, the processor in the LANCE
chip and tcp_input on the destination machine were mostly
sitting idle.

To get good network performance, where there are guaranteed to
be many processors that could be doing things in parallel, you
want the "units of work" (loop sizes, packet sizes, etc.) to be
the SMALLEST values that amortise the fixed cost.  In Berkeley
Unix, the fixed costs of protocol processing are pretty low and
sizes of 1 - 2 KB on a 68020 are as large as you'd want to get.
(This is easy to determine.  Just do a throughput vs. size test
and look for the knee in the graph.  Best performance is just to
the right of the knee.)  And, obviously, on a faster machine
you'd probably want to do things in even smaller units (if the
overhead stays the same -- Crays are fast but hardware
strangeness drives the fixed costs way up.  Just remember that
if it takes large packets and large buffers to get good
performance on a fast machine, that's because it's broken, not
because it's fast.)

Another big effect (difficult to quantify because several
changes has to be made at once) was to remove lots of
more-or-less hidden data copies from the protocol processing.
It's a truism that you never copy data in network code.  Just
lay the data down in a buffer & pass around pointers to
appropriate places in that buffer.  But there are lots of places
where you need to get from a pointer into the buffer back to a
pointer to the buffer itself (e.g., you've got a pointer to the
packet's IP header, there's a header checksum error, and you
want to free the buffer holding the packet).  The routine "dtom"
converts a data pointer back to a buffer pointer but it only
works for small things that fit in a single mbuf (the basic
storage allocation unit in the bsd network code).  Incoming
packets are never in an mbuf; they're in a "cluster" which the
mbuf points to.  There's no way to go from a pointer into a
cluster to a pointer to the mbuf.  So, anywhere you might need
to do a dtom (anywhere there's a detectable error), there had to
be a call to "m_pullup" to make sure the dtom would work.
(M_pullup works by allocating a fresh mbuf, copying a bunch of
data from the cluster to this mbuf, then chaining the original
cluster behind the new mbuf.)

So, we were doing a bunch of copying to expedite error handling.
But errors usually don't happen (if you're worried about
performance, first you make sure there are very, very few
errors), so we were doing a bunch of copying for nothing.  But,
if you're sufficiently insomniac, in about a week you can track
down all the pullup's associated with all the dtom's and change
things to avoid both.  This requires massive recoding of both
the TCP and IP re-assembly code.  But it was worth it:  TCP
throughput climbed from around 600 KB/s to 750 KB/s and IP
forwarding just screamed:  A 3/60 forwarding packets at the 9
Mb/s effective ethernet bandwidth used less than 50% of the CPU.

[BTW, in general I didn't find anything wrong with the BSD
mbuf/cluster model.  In fact, I tried some other models (e.g.,
do everything in packet sized chunks) and they were slower.
There are many cases where knowing that you can grab an mbuf and
chain it onto a chunk of data really simplifies the protocol
code (simplicity == speed).  And the level of indirection and
fast, reference counted allocation of clusters can really be a
win on data transfers (a la kudp_fastsend in Sun OS).  The
biggest problem I saw, other than the m_pullup's, was that
clusters are too small:  They need to be at least big enough for
an ethernet packet (2K) and making them page sized (8K on a Sun)
doesn't hurt and would let you do some quick page swap tricks in
the user-system data copies (I didn't do any of these tricks in
the fast TCP.  I did use 2KB clusters to optimize things for the
ethernet drivers).]

An interesting result of the m_pullup removals was the death of
another piece of folklore.  I'd always heard that the limiting
CPU was the receiver.  Wrong.  After the pullup changes, the
sender would be maxed out at 100% CPU utilization while the
receiver loafed along at 65-70% utilization (utilizations
measured with a microprocessor analyzer; I don't trust the
system's stats).  In hindsight, this seems reasonable.  At the
receiver, a packet comes in, wanders up to the tcp layer, gets
stuck in the socket buffer and an ack is generated (i.e., the
processing terminates with tcp_input at the socket buffer).  At
the sender, the ack comes in, wanders up to the tcp layer, frees
some space, then the higher level socket process has to be woken
up to fill that space (i.e., the processing terminates with
sosend, at the user socket layer).  The way Unix works, this
forces a boundary crossing between the bottom half (interrupt
service) and top half (process context) of the kernel.  On a
Sun, and most of the other Unix boxes I know of, this is an
expensive crossing.  [Of course, the user process on the
receiver side has to eventually wake up and empty the socket
buffer but it gets to do that asynchronously and the dynamics
tend to arrange themselves so it processes several packets on
each wakeup, minimizing the boundary crossings.]

Talking about the bottom half of the kernel reminds me of
another major effect.  There seemed to be a "sound barrier" at
550 KB/s.  No matter what I did, the performance stuck at 550
KB/s.  Finally, I noticed that Sun's LANCE ethernet driver,
if_le.c, would only queue one packet to the LANCE at a time.
Picture what this means:  (1) driver hands packet to LANCE, (2)
LANCE puts packet on wire, (3) end of packet, LANCE interrupts
processor, (4) interrupt dispatched to driver, (5) go back to
(1).  The time involved in (4) is non-trivial, more than 150us,
and represents a lot of idle time for the LANCE and the wire.
So, I rewrote the driver to queue an arbitrary number of packets
to the LANCE, the sound barrier disappeared, and other changes
started making the throughput climb (it's not clear whether this
change had any effect on throughput or just allowed other
changes to have an effect).

[Shortly after making the if_le change, I learned why Sun might
have written the driver the silly way they did:  Before the
change, the 6 back-to-back IP fragments of an NFS write would
each be separated by the 150us interrupt service time.  After
the change, they were really back-to-back, separated by only the
9.6us minimum ethernet spacing (and, no, Sun does NOT violate
the ethernet spec in any way, shape or form.  After my last
message on this stuff, Apollo & DEC people kept telling me Sun
was out of spec.  I've been watching packets on our ethernet for
so long, I'm starting to learn the middle name of every bit.
Sun bits look like DEC bits and Sun, or rather, the LANCE in the
3/50 & 3/60, completely complys with the timings in the blue
book.)  Anyway, the brain-dead Intel 82586 ethernet chip Sun
puts in all its 3/180, 3/280 and Sun-4 file servers can't hack
back-to-back, minimum spacing packets.  Every now and again it
drops some of the frags and wanders off to never-never land
("iebark reset").  Diskless workstations don't work well when
they can't write to their file server and, until I hit on the
idea of inserting "DELAY" macros in kudp_fastsend, it looked
like I could have a fast TCP or a functional workstation but not
both.]

Probably 30% of the performance improvements came from fixing
things in the Sun kernel.  I mean like, really, guys:  If the
current task doesn't change, and it doesn't 80% of the time
swtch is called, there's no need to do a full context save and
restore.  Adding the two lines

	cmpl	_masterprocp,a0
	jeq	6f		| restore of current proc is easy

just before the call to "resume" in sun3/vax.s:swtch got me a
quick 70 KB/s performance increase but felt more like a bug fix
than progress.  And a kernel hacker that does 16-bit "movw"s and
"addw"s on a 68020, or writes 2 instruction dbra loops designed
to put a 68010 in loop mode, should be shot.  The alu takes the
same 3 clocks for a 2 byte add or a 4 byte add so things will
finish a lot quicker if you give it 4 bytes at a time.  And
every branch stalls the pipe, so unrolling that loop to cut down
on branches is a BIG win.

Anyway, I recoded the checksum routine, ocsum.s (now oc_cksum.s
because I found the old calling sequence wasn't the best way to
do things) and its caller, in_cksum.c, and got the checksumming
time down from 490us/KB to 130us/KB.  Unrolling the move loop in
copyin/copyout (the routines that move data user to kernel and
kernel to user), got them down from 200us/KB to 140us/KB.  (BTW,
if you combine the move with the checksum, which I did in the
kludged up, fast code that ran 1 MB/s on a 15MHz 3/50, it costs
200us/KB, not the 300us/KB you'd expect from adding the move
and sum times.  Pipelined processors are strange and wonderful
beasts.)

From these times, you can work out most of the budgets and
processing details:  I was using 1408 data byte packets (don't
ask why 1408).  It takes 193us to copy a packet's worth of data
and 184us to checksum the packet and its 40 byte header.  From
the logic analyzer, the LANCE uses 300us of bus and memory
bandwidth reading or writing the packet (I don't understand why,
it should only take half this).   So, the variable costs are
around 700us per packet.  When you add the 18 byte ethernet
header and 12 byte interpacket gap, to run at 10 Mb/s I'd have
to supply a new packet every 1200us.  I.e., there's a budget of
500us for all the fixed costs (protocol processing, interrupt
dispatch, device setup, etc.).  This is do-able (I've done it,
but not very cleanly) but what I'm getting today is a packet
every 1500us.  I.e., 800us per packet fixed costs.  When I look
with our analyzer, 30% of this is TCP, IP, ARP and ethernet
protocol processing (this was 45% before the "header prediction"
tcp mods), 15% is stalls (idle time that I don't currently
understand but should be able to eventually get rid of) and 55%
is device setup, interrupt service and task handling.  I.e.,
protocol processing is negligible (240us per packet on this
processor and this isn't a fast processor in today's terms).  To
make the network go faster, it seems we just need to fix the
operating system parts we've always needed to fix:  I/O service,
interrupts, task switching and scheduling.  Gee, what a surprise.

 - Van

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

From uunet!HELIOS.EE.LBL.GOV!van Wed Nov 23 06:21:18 1988
Path: hsi!uunet!eplrx7!udel!princeton!njin!rutgers!mailrus!ames!pasteur!ucbvax!HELIOS.EE.LBL.GOV!van
From: van@HELIOS.EE.LBL.GOV (Van Jacobson)
Newsgroups: comp.protocols.tcp-ip
Subject: re: Performance
Message-ID: <8811231121.AA19744@helios.ee.lbl.gov>
Date: 23 Nov 88 11:21:18 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 39

> Recently, I improved "ftp" in one of our products which is 4.2BSD based.
> I had 351465 bytes received in 1 second ( 3.4 e + 02 Kbytes/sec )
> ...
> Is there anybody has better "ftp" performance than mine ???

It would be interesting to see what performance you would get
with a good tcp.  I think Dave Borman of Cray Research holds the
current ftp speed record:  He routinely gets 30 Megabytes/sec
(of course, some of us think using two Cray-IIs gives him an
unfair competitive advantage).  If you're using more
conventional hardware, 340 Mb/s still isn't spectacular.  Here's
a typescript between two of our Sun 3/60s across an ethernet.
Both machines are running stock 4.3bsd-tahoe ftp & ftpd with
Mike Karels' and my tcp & kernel hacks:

    Script started on Wed Nov 23 02:40:44 1988
    [vs 1]% ftp yak
    Connected to yak.ee.lbl.gov.
    220 yak FTP server (Version 4.27 Sat Nov 5 02:20:42 PST 1988) ready.
    Name (yak:van):
    331 Password required for van.
    Password:
    230 User van logged in.
    ftp> bin
    200 Type set to I.
    ftp> get /usr/lib/libcore.a /dev/null
    200 PORT command okay.
    150 Opening data connection for /usr/lib/libcore.a (669336 bytes).
    226 Transfer complete.
    669336 bytes received in 0.82 seconds (8e+02 Kbytes/s)
    ftp> get /usr/lib/libcore.a /dev/null
    200 PORT command okay.
    150 Opening data connection for /usr/lib/libcore.a (669336 bytes).
    226 Transfer complete.
    669336 bytes received in 0.82 seconds (8e+02 Kbytes/s)
    ftp> bye
    221 Goodbye.
    [vs 2]% exit
    script done on Wed Nov 23 02:41:23 1988

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

Date:    Thu, 27 Oct 1988 02:40
From:    Van Jacobson <van@HELIOS.EE... <BBOARD>
Subject: 4BSD TCP Ethernet Throughput
 
Date:     Mon, 24 Oct 88 13:33:13 PDT
From:     Van Jacobson <van@HELIOS.EE.LBL.GOV>
 
Many people have asked for the Ethernet throughput data I
showed at Interop so it's probably easier to post it:
 
These are some throughput results for an experimental version of
the 4BSD (Berkeley Unix) network code running on a couple of
different MC68020-based systems: Sun 3/60s (20MHz 68020 with AMD
LANCE Ethernet chip) and Sun 3/280s (25MHz 68020 with Intel
82586 Ethernet chip) [note again the tests were done with Sun
hardware but not Sun software -- I'm running 4.?BSD, not Sun
OS].  There are lots and lots of interesting things in the data
but the one thing that seems to have attracted people's
attention is the big difference in performance between the two
Ethernet chips.
 
The test measured task-to-task data throughput over a TCP
connection from a source (e.g., chargen) to a sink (e.g.,
discard).  The tests were done between 2am and 6am on a fairly
quiet Ethernet (~100Kb/s average background traffic).  The
packets were all maximum size (1538 bytes on the wire or 1460
bytes of user data per packet).  The free parameters for the
tests were the sender and receiver socket buffer sizes (which
control the amount of 'pipelining' possible between the sender,
wire and receiver).  Each buffer size was independently varied
from 1 to 17 packets in 1 packet steps.  Four tests were done at
each of the 289 combinations.  Each test transferred 8MB of data
then recorded the total time for the transfer and the send and
receive socket buffer sizes (8MB was chosen so that the worst
case error due to the system clock resolution was ~.1% -- 10ms
in 10sec).  The 1,156 tests per machine pair were done in random
order to prevent any effects from fixed patterns of resource
allocation.
 
In general, the maximum throughput was observed when the sender
buffer equaled the receiver buffer (the reason why is complicated
but has to do with collisions).  The following table gives the
task-to-task data throughput (in KBytes/sec) and throughput on
the wire (in MBits/sec) for (a) a 3/60 sending to a 3/60 and
(b) a 3/280 sending to a 3/60.
 
    _________________________________________________
    |              3/60 to 3/60   |  3/280 to 3/60   |
    |            (LANCE to LANCE) | (Intel to LANCE) |
    | socket                      |                  |
    | buffer     task to          | task to          |
    |  size       task      wire  |  task      wire  |
    |(packets)   (KB/s)    (Mb/s) | (KB/s)    (Mb/s) |
    |    1         384      3.4   |   337      3.0   |
    |    2         606      5.4   |   575      5.1   |
    |    3         690      6.1   |   595      5.3   |
    |    4         784      6.9   |   709      6.3   |
    |    5         866      7.7   |   712      6.3   |
    |    6         904      8.0   |   708      6.3   |
    |    7         946      8.4   |   710      6.3   |
    |    8         954      8.4   |   718      6.4   |
    |    9         974      8.6   |   715      6.3   |
    |   10         983      8.7   |   712      6.3   |
    |   11         995      8.8   |   714      6.3   |
    |   12        1001      8.9   |   715      6.3   |
    |_____________________________|__________________|
 
The theoretical maximum data throughput, after you take into
account all the protocol overheads, is 1,104 KB/s (this
task-to-task data rate would put 10Mb/s on the wire).  You can
see that the 3/60s get 91% of the the theoretical max.  The
3/280, although a much faster processor (the CPU performance is
really dominated by the speed of the memory system, not the
processor clock rate, and the memory system in the 3/280 is
almost twice the speed of the 3/60), gets only 65% of
theoretical max.
 
The low throughput of the 3/280 seems to be entirely due to the
Intel Ethernet chip: at around 6Mb/s, it saturates.  (I put the
board on an extender and watched the bus handshake lines on the
82586 to see if the chip or the Sun interface logic was pooping
out.  It was the chip -- it just stopped asking for data.  (The
CPU was loafing along with at least 35% idle time during all
these tests so it wasn't the limit).
 
[Just so you don't get confused:  Stuff above was measurements.
 Stuff below includes opinions and interpretation and should
 be viewed with appropriate suspicion.]
 
If you graph the above, you'll see a large notch in the Intel
data at 3 packets.  This is probably a clue to why it's dying:
TCP delivers one ack for every two data packets.  At a buffer
size of three packets, the collision rate increases dramatically
since the sender's third packet will collide with the receiver's
ack for the previous two packets (for buffer sizes of 1 and 2,
there are effectively no collisions).  My suspicion is that the
Intel is taking a long time to recover from collisions (remember
that you're 64 bytes into the packet when you find out you've
collided so the chip bus logic has to back up 64 bytes -- Intel
spent their silicon making the chip "programmable", I doubt they
invested as much as AMD in the bus interface).  This may or may
not be what's going on:  life is too short to spend debugging
Intel parts so I really don't care to investigate further.
 
The one annoyance in all this is that Sun puts the fast Ethernet
chip (the AMD LANCE) in their slow machines (3/50s and 3/60s)
and the slow Ethernet chip (Intel 82586) in their fast machines
(3/180s, 3/280s and Sun-4s, i.e., all their file servers).
[I've had to put delay loops in the Ethernet driver on the 3/50s
and 3/60s to slow them down enough for the 3/280 server to keep
up.]  Sun's not to blame for anything here:  It costs a lot
to design a new Ethernet interface; they had a design for the
3/180 board set (which was the basis of all the other VME
machines--the [34]/280 and [34]/110); and no market pressure to
change it.  If they hadn't ventured out in a new direction with
the 3/[56]0 -- the LANCE -- I probably would have thought
700KB/s was great Ethernet throughput (at least until I saw
Dave Boggs' DEC-Titan/Seeq-chip throughput data).
 
But I think Sun is overdue in offering a high-performance VME
Ethernet interface.  That may change though -- VME controllers
like the Interphase 4207 Eagle are starting to appear which
should either put pressure on Sun and/or offer a high
performance 3rd party alternative (I haven't actually tried an
Eagle yet but from the documentation it looks like they did a
lot of things right).  I'd sure like to take the delay loops out
of my LANCE driver...
 
 - Van
 
ps: I have data for Intel-to-Intel and LANCE-to-Intel as well as
    the Intel-to-LANCE I listed above.  Using an Intel chip on the
    receiver, the results are MUCH worse -- 420KB/s max.  I chose
    the data that put the 82586 in its very best light.
 
    I also have scope pictures taken at the transceivers during all
    these tests.  I'm sure there'll be a chorus of "so-and-so violates
    the Ethernet spec" but that's a lie -- NONE OF THESE CHIPS OR
    SYSTEMS VIOLATED THE ETHERNET SPEC IN ANY WAY, SHAPE OR FORM.
    I looked very carefully for violations and have the pictures to
    prove there were none.
 
    Finally, all of the above is Copyright (c) 1988 by Van Jacobson.
    If you want to reproduce any part of it in print, you damn well
    better ask me first -- I'm getting tired of being misquoted in
    trade rags.
 
 


-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Sep 1993 16:06:29 GMT
From:      leanne@netmanage.com
To:        comp.sys.novell,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Novell & Banyan & TCP/IP


In article <brian.438.0012F2B1@novell.com>, <brian@novell.com> writes:
> Xref: netman-gate comp.sys.novell:24960 comp.dcom.lans:7665 
 comp.protocols.tcp-ip:17484
> Newsgroups: comp.sys.novell,comp.dcom.lans,comp.protocols.tcp-ip
> Path: 
netman-gate!uunet!elroy.jpl.nasa.gov!sdd.hp.com!sgiblab!newsun!brian.SJF.Nov
ell.COM!brian
> From: brian@novell.com (Brian Meek)
> Subject: Re: Novell & Banyan & TCP/IP
> Message-ID: <brian.438.0012F2B1@novell.com>
> Lines: 33
> Sender: news@novell.com (The Netnews Manager)
> Nntp-Posting-Host: brian.sjf.novell.com
> Organization: Novell, Inc. -- UNIX Systems Group
> X-Newsreader: Trumpet for Windows [Version 1.0 Rev A]
> References:  <1993Sep11.174322.21972@adi.com>
> Date: Fri, 17 Sep 1993 18:56:45
> 
> khai@adi.com (S. Khai Mong) writes:
> >From: khai@adi.com (S. Khai Mong)
> >Subject: Novell & Banyan & TCP/IP
> >Date: Sat, 11 Sep 1993 17:43:22 GMT
> >
> >I have this application which uses Novell's TCP/IP API and compiled
> >and linked with Novell's TCP/IP product.  This works fine on
> >Novell client workstations.
> >
> >My question: Is there a chance that such an application will run on a
> >client workstation that has _only_ Banyan and Banyan's TCP/IP software
> >installed?  Is there any quick answer why it won't work?  (I am
> >thinking of getting Banyan's TCP/IP software)
> 
> You can't run two TCP/IP stacks at the same time on the same board
> (not easily, anyway).  This is because both stacks are competing for
> the same packets... (long story, FAQ item).
> 
> It would be easier (and take less RAM) to run Novell's TCP/IP software
> with Banyan VINES.  VINES supports NDIS (maybe even native ODI by 
> now?), and it can be run over the ODINSUP driver found in:
> 
> 	ftp.novell.com: /netwire/novfiles/dosup7.exe
> 
> Refer to ODINSUP.DOC for intructions.  The idea is you'll have
> Banyan's VINES protocol over NDIS (ODINSUP) and Novell TCP/IP
> directly over ODI running simultaneously.  No NetWare, unfortunately...
> but all will function nonetheless :-).
> 
> -- brian
> 
 ___________________________________________________________________________
> Brian Meek                               Novell, Inc. -- UNIX Systems 
 Group
>                                          Internet mail:  brian@Novell.COM

Chameleon TCP/IP For Windows runs fine with Vines and NetWare.  

NetManage's Chameleon is a DLL implementation of TCP/IP and uses less than 
6K of memory.
Leanne
****************************************************************************
Leanne Brunette
NetManage, Inc.
(408) 973-7171
Internet mail:  leanne@netmanage.com
****************************************************************************

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Sep 1993 16:50:30 GMT
From:      ameen@hpcc01.corp.hp.com (Kavetta Ameen)
To:        comp.protocols.tcp-ip
Subject:   Re: Help! Small network how to?

> 	Ok, me and a few of my friends all run a BSD 4.3 variant on
> our own machines at home, we are curious as to the process of netting
> each other up would be. Essentially something quite small, so that
> mail could be sent between us, perhaps more (ftp,telnet?)... We all
> have in our pocessions 14.4 modems and no idea where to begin. I have
> been pouring over man pages for a few hours to find not much help as
> to where to start... So if someone has a FAQ on this, or some good
> tips as to where to try to post instead or where to start, I would
> love it!
> 
> Thanks!
> 
> Micah
> 
> ----------
> 
You might want to subscribe to NETCOM's network service. I think a local
number you can use is (206) 547-5992 or (800) 488-2558. The other possibility
is to set up one of your machines as a SLIP server. Then all your buddy's can
dial in to that machine and use ftp, telnet, email, etc. Check out
comp.protocols.ppp.
**********************************************************************

From: Bob Bellavance bobb@hppcih58.svale.hp.com

**********************************************************************

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Sep 1993 16:55:56 GMT
From:      ameen@hpcc01.corp.hp.com (Kavetta Ameen)
To:        comp.protocols.tcp-ip
Subject:   Re: RS232 driver on UNIX (SLIP ?)

> I'm not sure what I need is SLIP for suppoting RS232 series line under
> UNIX operating system. So, I'll describe my problem first. I'm
> going to run software on HP 700 series or Sun Sparc station and I
> need to communicate with several sensor units which take sample
> data and can transmit the data over RS232 series line. What kind of
> software I need to use on the workstation in order to
> receive/communicate with those sensor units. Since I may need to
> connect one of the unit at a time, a sort of polling protocol may
> be desirable. Thanks for any response.
> 
> Yi-Chieh
> ----------
> 
You problably don't need slip for this. You could use kermit to read from
the RS232 port (I'am assuming you will be using a modem although a direct
connect might work) and if it got data then send back a response.
**********************************************************************

From: Bob Bellavance bobb@hppcih58.svale.hp.com

**********************************************************************

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Sep 1993 18:33:37 GMT
From:      pmj@roadnet.ups.com (Pete Jansson)
To:        comp.protocols.tcp-ip
Subject:   Free proxy ftp agent sought


I am looking for a free proxy ftp agent.  We have a Unix system operating as
an internet gateway via a dial-up SLIP link.  I would like to arrange things
so that, by invoking a standard ftp client on a magic port, a user could wake
the proxy ftp agent, which would bring up the slip link, via some magic
initiate an ftp connection with the other side, and serve as a pass-through
while the session is in-progress.  I am aware that DEC may have a product
which is similar to this, but I need a free one -- I have enough trouble
getting Internet resources as it is.

I know about socks, but folks internally will be using a variety of ftp clients
on a number of platforms, so I can't recompile them all.  My Unix box is not
running Perl, so I can't run tcpr, either (no disk space -- did I mention my
Internet resource problem?).

I would appreciate any help.  Thanks in advance,
    Pete.


-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Sep 1993 18:53:10 GMT
From:      denny@tss.com (Denny Page)
To:        comp.protocols.tcp-ip
Subject:   IP net broad from within a subnet

Query for the IP Gods:

It is considered "legal" to send a broadcast addressed to the ip
network from within a subnet?

For example, given the following ifconfig:

  Ip addr          160.101.100.137
  Netmask          255.255.255.0
  Broadcast addr   160.101.100.255

What do you feel the system should do when presented a destination
address of 160.101.255.255 (from a process local to the machine)?

Yes, I've read 950 and 922 and have my own conclusion, but I'd like
the interpretation of others.


Denny

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Sep 1993 18:56:11 GMT
From:      BERRYMAN@orca.drep.dnd.ca (DON BERRYMAN)
To:        comp.protocols.tcp-ip,comp.sys.hp,comp.sys.sun.admin
Subject:   Re: How to kill every SUN on your network.


> In article <1993Sep18.133722.22936@lokkur.dexter.mi.us> scs@lokkur.dexter.mi.us (Steve Simmons) writes:
> >raj@cup.hp.com (Rick Jones) writes:
> >>DON BERRYMAN (BERRYMAN@orca.drep.dnd.ca) wrote:
 
> >>: Title: How to kill every SUN on your network.
 
> >>[Bunches of good details deleted]
 
> >>#begin SOAPBOX
> >>This is why one SHOULD NOT bridge FDDI and Ethernet together.
> >>This is why one SHOULD route FDDI and Ethernet together.
> >>#end
> >
> >I'll go one step further.  If the FDDI/Enet bridge is putting packets
> >*in violation of the ethernet spec* onto the ethernet, then the bridge
> >is fundamentally broke.  Period.  End of discussion.  

I have been talking to Cabletron and they admit that there FDDI/Enet
bridge (FDMMIM) has incorrect firmware. They plan to fix this problem
in the next firmware release, maybe in November.

I cann't see why bridging FDDI/Enet should not be done, that is assuming
the bridge was smart enough to:
   1) Fragment large TCP packets to fit on Enet.
   2) Not pass large UDP packets that cannot be fragmented.
      This is allowable since UDP delivery is not guarenteed.
   3) Not needlessly bridge FDDI packets to Enet and possibly
      saturate Enet.
   4) Some how not bridge UDP Broadcasts on FDDI when this would
      saurate Enet. Again UDP delivery is not guarenteed so this
      is allowable.

Now it might be that with all these limitations the Bridge is behaving
like a Router. Maybe the definitions are ambiguous. What ever you
want to call it, a Bridge/Router, is an extremely necessary piece
of hardware. In the future/today you'd want to have the main highspeed
network being FDDI with strands of Enet serving small groups of users.
Thus you can use cheap Enet interfaces for most users while allowing
maximum bandwidth on the main Network.


Don Berryman
Defence Research Establishment Pacific
Canadian Forces Base Esquimalt
Victoria, BC, CANADA, V0S-1B0
604-363-2731    604-363-2856fax
berryman@orca.drep.dnd.ca

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Sep 1993 00:20:23 GMT
From:      snvasam@srv.PacBell.COM (Satya Vasametti)
To:        comp.protocols.tcp-ip
Subject:   Modem dialup software


I am looking for software (to run on Unix platform)   which does the following:

1. Open the specified  tty port (RS232 serial port on Sun sparc). 

2. Set the desired baud rate.

3. Dial the specified number and connect to the remote system.

4. If the connection is successful, return the value of the opened file descriptor to the calling function.

The functionality is similar to what the system command "tip" does but without the
terminal emulation portion. 

I appreciate if someone can email me any pointers or suggestions to where I can find such a software. 

Thanks.

/Satya.
email path: snvasam@srv.PacBell.com



-- 
Test VS

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Sep 1993 02:33:55 GMT
From:      justin@hp750.me.engr.uky.edu (Justin Sullivan)
To:        comp.protocols.tcp-ip,comp.sys.hp,comp.sys.sun.admin
Subject:   Re: How to kill every SUN on your network.

BERRYMAN@orca.drep.dnd.ca (DON BERRYMAN) writes:

>I have been talking to Cabletron and they admit that there FDDI/Enet
>bridge (FDMMIM) has incorrect firmware. They plan to fix this problem
>in the next firmware release, maybe in November.

How in the hell can vendors release products that don't work right
(sometimes they just don't work "as advertised") and then bug fixes are
so slow? One would think that if there was something wrong with it, they
would notice before it left the lab..

-- 
* Justin P. Sullivan            * justin@engr.uky.edu  (Internet) *
* System Administrator          * justin@mik.uky.edu   (NeXTMail) *
* Computational Fluid Dynamics  * JUSTIN@UKCC            (BITNET) *
* (606) 257-2368                * ukma!ukecc!justin        (UUCP) *

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Sep 1993 09:39:39 -0400
From:      "Thomas P. Evans" <te0h+@andrew.cmu.edu>
To:        comp.protocols.tcp-ip
Subject:   programming libraries/wrappers


Hello,
     This is probably a FAQ, but I'm looking for a set of library or
wrapper functions that will make tcpip programming easier.  Does any
such library exist and where could I find it?

     ...tom


-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Sep 93 09:25:24 CST
From:      EM306965@itesmvf1.rzs.itesm.mx (Gustavo Cavazos)
To:        comp.protocols.tcp-ip
Subject:   Help on IP Subnets...

Hello...
 I have several machines running on a class C IP network, and I'm
installing others on a token ring network. Do I have to create a
subnet to have the token ring net working?If so, who do I work with
Subnet mask. I have a whole range  of IP numbers (132.254.5.X)
 
Thanks,
+Gus Cavazos

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 1993 06:39:02 GMT
From:      guriga@snrc.uow.edu.au (Istvan Kerekes)
To:        comp.protocols.tcp-ip
Subject:   Re: WOLLONGONG PATHWAY

I need to know everything about  a S/W called WOLLONGONG PATHWAY.
1. What is it good for?
2. Vendor?  
3. etc.
Any info is appriciated !

Thanks,
Istvan Kerekes
gurgia@snrc.uow.edu.au



-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 1993 06:48:36 GMT
From:      guriga@snrc.uow.edu.au (Istvan Kerekes)
To:        comp.protocols.tcp-ip
Subject:   WOLLONGONG PATHWAY


1. What is it good for?
2. Vendor?  
3. etc.
Any info is appriciated !

Thanks,
Istvan Kerekes
guriga@snrc.uow.edu.au
Ps. Sorry for reposting it, I had a typo in my email address


-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Sep 93 08:43:45 GMT
From:      srl@terminus.ericsson.se (Steve Langstaff)
To:        comp.protocols.tcp-ip
Subject:   Re: How to kill every SUN on your network.

In article 23729@netfs.dnd.ca, BERRYMAN@orca.drep.dnd.ca (DON BERRYMAN) writes:

:I cann't (sic) see why bridging FDDI/Enet should not be done, that is]
:assuming the bridge was smart enough to:
 
:   1) Fragment large TCP packets to fit on Enet.

Looks like a router to me.

:   2) Not pass large UDP packets that cannot be fragmented.
:      This is allowable since UDP delivery is not guarenteed.

I would imagine that systematic loss of datagrams is not 'in the spirit' of
IP. To take this comment to the extreem, one could discard all datagrams,
since their delivery is not guarenteed.

:   3) Not needlessly bridge FDDI packets to Enet and possibly
:      saturate Enet.
 
:   4) Some how not bridge UDP Broadcasts on FDDI when this would
:      saurate Enet. Again UDP delivery is not guarenteed so this
:      is allowable.
:
:Now it might be that with all these limitations the Bridge is behaving
:like a Router. Maybe the definitions are ambiguous.

!?

---

Steve L.


-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Sep 1993 13:00:15 EDT
From:      madjk@wolfman.br.rohmhaas.com (John Kinker)
To:        comp.protocols.tcp-ip
Subject:   Test - Ignore



-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Sep 1993 13:01:16 EDT
From:      madjk@wolfman.br.rohmhaas.com (John Kinker)
To:        comp.protocols.tcp-ip
Subject:   Test - Ignore

Test message. Please ignore.

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Sep 1993 21:30:44 -0700
From:      carr@esl.com (John A. Carr)
To:        comp.sys.hp,comp.protocols.tcp-ip,comp.dcom.sys.wellfleet
Subject:   HP Router ER Configuration

Sorry for the cross-post, but I really don't have a clue where this
belongs.

I have an HP Router ER (5.74 software).  This is a small
IP/appletalk/IPX/DECNet router with 2 ethernet ports and 2 serial ports. 
It is somehow based on Wellfleet technology and the command interface seems
very similar.  

I want to configure it as follows & don't understand how to do what I want.

I want to route between the two LAN ports but want to bridge IP between the
second LAN port and the two serial WAN ports.  I want to route appletalk
everywhere (I know how to do that).  I don't care about DECNet or IPX.

I see how to turn off IP routing, but it seems to turn it off altogether,
not just between selected ports.

Can anyone give me a clue whether what I want to do is possible (&, if so,
how to do it)?  And, what is the appropriate group for questions like this?

Also, is there an HP tech support phone number for these things?  I can't
find anything in the documentation and my dealer has no clue what I'm
talking about?

Reply by email, please, to carr@esl.com.  Thanks in advance.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John A. Carr          ESL Incorporated           carr@esl.com

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Sep 1993 16:49:53 -0400
From:      Pat_Barron@transarc.com
To:        comp.protocols.tcp-ip
Subject:   Where can I get latest KA9Q TCP/IP?

Where can I find the latest version of Phil Karn's "NOS" TCP/IP
software for MS-DOS?  I looked on ucsd.edu under the "hamradio"
directory, but there are so many different versions of NOS there it's
hard to tell what's what.  Ideally, I'd like the latest version from
Phil which has not been edited or patched by anyone.

Thanks,
--Pat.

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 93 10:44:28 GMT
From:      devjwu@nodomain (Wuyts Jan)
To:        comp.protocols.tcp-ip
Subject:   Odd transmission delays


---

During testing with a piece of communication software we developed,
we noticed some strange behavior in the TCP communication.

The program is in principle doing:

 +-----------+                     +-----------+
 | PROCESS 1 |       | TCP |       | PROCESS 2 |
 +-----------+       |     |       +-----------+
             After connection set-up
         (with TCP_NODELAY on the sockets)
      *-SEND--->     |     |
                     |     | -----RECV-> *
                     |     |       After full receipt
                     |     |   <---SEND--*
      * <-RECV-----  |     |

And so on...

We measure the 'transmission delay' as "half the time 
between the SEND and RECV" in PROCESS 1.

We are sending fixed size messages back and forth and the results were 
strange

# of messages  MessageSize TransmissionDelay
                  Byte          milli-sec   
   200               10             99      
   200               20             99      
   200               50            100      
   200              100             99      
   200              200             99      
   200              400             99      
   200              700             99      
   200             1024            100      
   200             1449             99 <---     
   200             1460             10 <--- 
   200             1461             10      
   200             1800             10      
   200             2048              9      
   200             4096             10 <--- 
   200             4097             99 <--- 
   200             4460             99      
   200             4461            100      
   200             8192             30      
   200            16384             71      
   200            20480             91      

Notice the factor 10 drop between 1449 and 1460 and
the opposite jump between 4096 and 4097! 
So it is actually 10 times faster to send 2048 bytes 
than it is to send 20 bytes!?!

We have run the tests on Sun SPARCstation 2(local),
HP 9000/827(local) and between the two across the ethernet.
The results were always comparable, so i presume its got 
something to do with the TCP/IP protocol.

Other people must have seen this before us so, is there anybody
who has a good explanation for it????

---
Jan Wuyts,                       email: devjwu@space.alcbel.be
Alcatel Bell Telephone,
Berkenrodelei 33,                phone: (+32) 3/829.5479
2660 Hoboken,
Belgium.


-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Sep 93 11:23:35 GMT
From:      scs@lokkur.dexter.mi.us (Steve Simmons)
To:        comp.protocols.tcp-ip,comp.sys.hp,comp.sys.sun.admin
Subject:   Re: How to kill every SUN on your network.

BERRYMAN@orca.drep.dnd.ca (DON BERRYMAN) quotes me several reference back:

>>I'll go one step further.  If the FDDI/Enet bridge is putting packets
>>*in violation of the ethernet spec* onto the ethernet, then the bridge
>>is fundamentally broke.  Period.  End of discussion.  
 
>I can't see why bridging FDDI/Enet should not be done, that is assuming
>the bridge was smart enough to:
>   1) Fragment large TCP packets to fit on Enet.
>   2) Not pass large UDP packets that cannot be fragmented.
>      This is allowable since UDP delivery is not guarenteed.
>   3) Not needlessly bridge FDDI packets to Enet and possibly
>      saturate Enet.
>   4) Some how not bridge UDP Broadcasts on FDDI when this would
>      saurate Enet. Again UDP delivery is not guarenteed so this
>      is allowable.

A bridge connects networks together at levels 1 and 2.  Fragmentation only
occurs at level 3 in the stack, IP datagrams.  TCP and UDP are level 4
protocols.  By definition, if the connecting hardware understands the layers
3 and up protocols, it is something more than a simple bridge.

Bridges have several advantages.  Since they blindly replicate data on
the wire from one media to another, they are independant of the higher
level protocols.  Thus an ethernet bridge will merrily pass DECNET, IP,
SNA, IPX, X.25, whatever, without ever having to think about it.  The
solution proposed would require that the bridge be protocol-aware for
*all* higher-level protocols.  I'm not sure that all of those protocols
even permit fragmentation.
-- 
"It has about as much chance of survival in the current marketplace as a
 blonde ingenue overnight guest at a Transylvanian castle."
 	- review of Jimmy Buffet's first album, 1973.

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 1993 12:03:45 GMT
From:      natonek@imtsg5.epfl.ch (Emerico Natonek)
To:        comp.protocols.tcp-ip
Subject:   Re: Help on Sockets

Hi I'm kind of new in TCP-IP protocols. We have an application running on SG (Irix) and we exhange informations with a PC (via NFS). SO far everithing worked fine. 
Now we try to implement a Socket. I have read the Unix creation of Socket, and think I could do something. But on the PC side I am really lost.  I need some help on obtaining documentation, code on client/server file transfers using sockets under DOS.  

Thank in advance

 Emerico

-- 
                                                              ,,,
                                                             (o o)
/========================================================oOO==(_)==OOo====/|
| Emerico Natonek                      |                                  ||
| Departement de Microtechnique        |    Tel: +41 21  693 3826         ||
| Swiss Institute of Technology (EPFL) |    Fax: +41 21  693 3866         ||
| CH - 1015 Lausanne                   |    natonek@imtsg5.epfl.ch        ||
|_________________________________________________________________________|/
                                                          (__)   (__)

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Sep 1993 13:42:43 GMT
From:      cleelacj@agedwards.com (Chris Cleeland)
To:        comp.protocols.tcp-ip
Subject:   UDP Broadcast packet limitations?

I have consulted the Usual Sources of Knowledge, only to find nothing
specific regarding the subject...

What limitations are imposed on UDP broadcast packets in terms of sizes
of data that can be transmitted, etc.  My man pages discuss the max
and the default for UDP, but don't expressly discuss how they relate to
broadcast UDP.  Thus, I don't expect there to be any differences; am
I mistaken?

The specific thing I'm trying is to broadcast a datagram that is larger
than a single MAC layer packet (about 2k bytes), but the implementation
of TCP/IP I'm using refuses to send any datagram larger than a MAC packet.
Is it brain-dead, or am I?

Any responses welcomed.  I will summarize if interest is shown.

Thanks
-cj
-- 
==============================================================================
Chris Cleeland 	       	       	|  Internet:   cleelacj@agedwards.com
BOS Dev. Team                   |  USnail:     3878 Connecticut St. Louis 63116
                                |  BellNet:    (314) 289-5372

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Sep 1993 13:47:30 GMT
From:      kf5mg@vnet.ibm.com (Jack Snodgrass)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.os.os2.networking
Subject:   Re: Internet address for gateways

In <27gb8g$2dr@zippy.Telcom.Arizona.EDU>, moongw@ece.arizona.edu (Gwi Moon) writes:
>I want to know about the route between source and destination.

Use TRACE ROUTE. It's tracerte under OS/2 TCP/IP V2.0. It will show you how many hops
it takes to get to you destination and who they are.

73's  de  Jack - kf5mg
AX25net         -  kf5mg@kf5mg.#dfw.tx.usa.na - (817) 962-4409
AMPRnet         -  kf5mg@kf5mg.ampr.org       - 44.28.0.14
Internet        -  kf5mg@vnet.ibm.com


-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 1993 14:42:56 GMT
From:      nh@beach.cis.ufl.edu (Nadeem Haider)
To:        comp.protocols.tcp-ip,comp.protocols.iso.x400
Subject:   Email from Internet to X.400 ?


Could anyone tell me how to send email
from the Internet to an X.400 address ?

thanks
---
nadeem



-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Sep 93 16:09:13 GMT
From:      rob@leland.Stanford.EDU (Rob Tanner)
To:        comp.protocols.tcp-ip
Subject:   Re: WOLLONGONG PATHWAY

In article <27oru6$2ql@falin.cs.uow.edu.au> guriga@snrc.uow.edu.au writes:
>I need to know everything about  a S/W called WOLLONGONG PATHWAY.
>1. What is it good for?
>2. Vendor?  
>3. etc.
>Any info is appriciated !
>
>Thanks,
>Istvan Kerekes
>gurgia@snrc.uow.edu.au
>
>



Wollongong Pathway is written by (and I presume marketed by) The
Wollongong Group on San Antonio Road in Palo Alto, California.
Pathway is, basically, a TCP/IP stack and a bundle of TCP/IP utilities
(telnet, FTP, ping, et cetera) for PCs -- both DOS and OS/2 .  It also
includes drivers for just about any ethernet card you can think of.

From a network point of view, the most important features that are a
part of Pathway are the telnet services, file transfer services, and
printing services -- a PC can function as a print server for a number
of ethernetted PCs, and without you're having to have a NOVELL or
other brand of networking host.

Another product, which is not technically a part of Pathway (but
Pathway is required to use it) is Wollongong's ClientNFS software
which enables a PC to NFS mount a unix server.  ClientNFS also
includes a bundle of unix like commands in lieu of their DOS
equivalents (e.g., ls).

My networks are mostly Mac (:-<) but the few PCs I do have run the
Wollongong products, and I'm most pleased with them.  If you have any
other specific questions, send me an e-mail, and I'll be glad to
answer them.

-- 
Rob Tanner                              Internet: rob@sherlock.stanford.edu
Network Manager
President and Provost's Office
Stanford University, California

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Sep 1993 16:46:44 GMT
From:      ercm20@festival.ed.ac.uk (Sam Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: IP net broad from within a subnet

Denny Page (denny@tss.com) wrote:
:    :
:    :
:   Ip addr          160.101.100.137
:   Netmask          255.255.255.0
:   Broadcast addr   160.101.100.255
 
: What do you feel the system should do when presented a destination
: address of 160.101.255.255 (from a process local to the machine)?
 
: Yes, I've read 950 and 922 and have my own conclusion, but I'd like
: the interpretation of others.

Read RFC 1122, 3.2.1.3, case (f), p.31.

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

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Sep 1993 17:35:59 GMT
From:      robn@apertus.com (Rob Nielsen)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Tools for gathering ethernet usage statistics

I'm looking for some tools that I could use to gather statistics on
ethernet traffic (tcp, udp, nfs, etc), and display current status of the
network. Does anybody know of any public-domain tools that can help me
out?

Thanks in advance,

Rob 
---
Rob Nielsen                       robn@apertus.com
Apertus Technologies        


-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 93 18:19:10 GMT
From:      karthik@informix.com (Karthikeyan Guruswamy)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.os.os2.networking
Subject:   Re: Internet address for gateways

In article <27gb8g$2dr@zippy.Telcom.Arizona.EDU> moongw@ece.arizona.edu (Gwi Moon) writes:
>Hello, netter!!
>
>I want to know about the route between source and destination.
>If I send message from A to B using TCP or UDP protocal, how many relay nodes it run through?
>What are their addresses?
>I am wondering about how I can get the addresses of gateways and configuration of networks between two nodes.
>I think there is some mechanism to make interim gateways insert their addresses.
> 
>Moon, Gwi
>----
>                       Dept. of Electrical & Computer Engineering

Try running 'traceroute' after you login as root. That would give you the 
interim gateways while the packet hops. 

Karthik

---------------------------------------------------------------
Karthik						
Infosoft Inc, (Contractor to INFORMIX Inc.)
Cupertino, CA

'It's 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.
---------------------------------------------------------------

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Sep 93 12:33:03 +0400
From:      Akhmedov Vladislav <vlad@grcc.msk.su>
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,relcom.archives
Subject:   îÕ ÏÞÅÎØ ÎÕÖÅÎ TCP/IP ÄÒÁÊ×ÅÒ ÄÌÑ PS 2/70

Hi Everybody,

ïÞÅÎØ ÎÕÖÅÎ NDIS ÉÌÉ PKT drivers for MicroChannel's D-Link (PS 2/70) ÐÏÄ
TCP/IP.

Thanks in advance.
Vlad Akhmedov.                                      vlad@grcc.msk.su



-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 1993 21:45:12 GMT
From:      nh@reef.cis.ufl.edu (Nadeem Haider)
To:        comp.mail.misc,comp.protocols.iso.x400,comp.protocols.tcp-ip
Subject:   MORE INFO on Internet to X.400



How do I send email to the following X.400 address from the Internet?

X400:(c=US; a=ATTMAIL; p=SYNTEX; OU=RES IOP; s=BUXTON; g=ALISON; i=RBUX)

thanks
--
nadeem

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Sep 1993 00:22:13 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Why not some standard TELNET command lines?

In article <YEGHBEDG@math.fu-berlin.de> shewison@brookes.ac.uk (Simon
Hewison) writes: 
>Basically, for parsing a name, try this algorithm:
>Does the string contain three dots, with a valid number between 0 and 255 in
>each field? If so,
>
>Try to parse it as byte.byte.byte.byte If any of this fails, then do
>a name lookup on it.

I usually try a name lookup on it.  If that works, then I'm set.  If
that fails, I try to parse it as some sort of number.

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

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Sep 1993 01:00:04 GMT
From:      ka@socrates.hr.att.com (Kenneth Almquist)
To:        comp.protocols.tcp-ip
Subject:   Re: Access to gopher, etc through a firewall.

In article <1993Sep9.231335.7761@PacBell.COM>, restock@pacbell.com writes:
> 
> My machine is not actually on the Internet.  Instead my company, like many
> others, have a firewall machine which is connected to both our internal
> internet and the larger Internet.
>
> Now for the real problem.  I can not use any of the new tools (Gopher, WAIS,
> WEB) except within our own internet.  Is anybody working on supporting a
> proxy gopher or whatever?  Something that would use the alternate port
> numbers as well as recognize the host indirection?  It certainly sounds
> simple, but are all of the internet developers directly on the internet,
> so this is a non-problem to them?

There is no standard for firewall machines to follow, so a solution that
works with one firewall will probably not work with another.  There is
a need for a firewall standard--anybody looking into putting one together?

In the case of the gopher client, get the source and edit the file
object/Sockets.  The only routine called by the client is SOCKconnect,
which makes a TCP connection to a host and port specified as arguments.
You have to rewrite this routine to have your firewall machine make the
connection for you.  I just did this for the AT&T gateway, but of course
my code won't help you since the firewalls are different.
				Kenneth Almquist

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 93 09:28:20 PDT
From:      morley@suncad.camosun.bc.ca (Mark Morley)
To:        comp.protocols.tcp-ip,comp.bbs.misc
Subject:   Re: Telnet door for BBS ?

Koos van den Hout (koos@hacktic.nl) wrote:
: Hello everyone,
 
: I am looking for a 'telnet' program that I can run as a door in my BBS.
: This would enable callers to telnet to a given Unix machine (connected to the
: BBS over an ethernet). The BBS PC's will be running the ODI drivers and a
: packet-over-ODI driver.
 
: I would like the telnet program to be able to use fossil for communicating
: with the modem, and close the IP session and exit when carrier is lost.
 
: The telnet program has to be 'secure' so the caller cannot reconnect to
: a different host/IP number.
 
: Does anybody know of such a program or is working on a beast like that ?
 
: Thanks in advance for any help,
 
:                                          Grtx. KH

I've written a DOS Telnet program that uses packet drivers.  I've also
written a seperate term package.  I've been thinking of merging the two
and creating a series of doors for BBS's including Telnet, Gopher, Finger,
FTP, etc.  I don't believe it would take much time, as I've already
written all the parts (I just have to cut'n'paste from my various
projects), but I'd only do it if I thought people would pay for it (via
shareware).  If I get enough people asking for it I'll do it.

Mark

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 1993 09:35:32 -0400
From:      vss@mathcs.emory.edu (V.S.Sunderam)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Overhead in duplex use of TCP socket connection



In doing some timing tests, I recently noticed that there
is a tremendous overhead associated with using a single
TCP socket connection for bi-directional, small packet transfers.

I.e. two processes connected by a streams socket incur heavy
performance hits when they interact with "write; read" on one
side, with a corresponding "read; write" on the other. 

In most Unix implementations (Irix, SunOS, HPUX, Dec OSF?)
this "turnaround" overhead seems to have a lower bound of
100 msec. Interestingly, AIX is free of this problem!

Anyway, does anyone have an explanation of why this is so?
Any clues would be appreciated. Even better, fixes or workarounds
are welcome. 

Thanks in advance

Vaidy Sunderam
--
-- 
V. S. Sunderam           | vss@mathcs.emory.edu      | Phone: (404) 727-5926
Emory University         | {decvax,gatech}!emory!vss | Fax  : (404) 727-5611


-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 1993 12:19:34 -0500
From:      rand@cs.UND.NoDak.Edu (Douglas K. Rand)
To:        comp.protocols.tcp-ip
Subject:   giant packets

We've been getting quite a few of these messages logged lately, and I
don't have much of an idea of whats causing them. Can anybody help?

Sep 23 09:29:42 agassiz vmunix: le0: Receive: giant packet from 0:a8:aa:aa:aa:aa
Sep 23 09:29:42 agassiz vmunix: le0: Receive: STP in rmd cleared

The different addresses that have been logged are:

0:0:55:55:55:55
0:0:c:55:55:55
0:0:c:6:52:b7
0:0:c:a6:aa:aa
0:0:c:aa:aa:aa
0:0:f3:0:27:3c
0:0:f3:0:27:54
0:50:55:55:55:55
0:a8:aa:aa:aa:aa
40:55:55:55:55:55
54:55:55:55:55:55
55:55:55:55:55:55
80:aa:aa:aa:aa:aa
a0:aa:aa:aa:aa:aa
a8:aa:aa:aa:aa:aa
aa:aa:aa:aa:aa:aa
--
Douglas K. Rand                     UND Aerospace - Scientific Computing Center
Home:   +1 218 773 0120                              University of North Dakota
Office: +1 701 777 2801                    Box 9022, Grand Forks ND  58202-9022
Internet: rand@cs.UND.NoDak.Edu             UUCP: ...!uunet!plains!agassiz!rand

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 1993 19:45:34 -0700
From:      skl@Connectivity.com (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: What is this protocol?

In article <1993Sep23.212352.22991@lmpsbbs.comm.mot.com>,
 solomon@comm.mot.com wrote:
>   shilp           2049/udp
>Does anyone know what this protocol is (shilp)?

The de facto use of UDP port 2049 is for NFS servers.  If this
"shilp" protocol isn't NFS, then its servers would have trouble
using UDP port 2049 on systems which run a NFS server.

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

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


-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Sep 1993 08:33:33 GMT
From:      giapfr@giau04.gia.ch (Frame Peter)
To:        comp.protocols.tcp-ip
Subject:   Routed



Hello,

Is it possible to get routed to route datagrams, even though
the node has only one network interface.


Thanks, Peter

Peter Frame
Grapha Informatik AG 

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Sep 1993 12:44:59 GMT
From:      leo@elmail.co.uk (E.J.Leoni-Smith)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.misc,comp.os.ms-windows.setup
Subject:   Re: Problem with comb. of Dell 425s/L, PC-NFS and ET4W32 windows-drivers

In article <vharten.31.000BAA71@prl.philips.nl> vharten@prl.philips.nl (Peter R. van Harten) writes:
>Hi troubleshooters,
>
>We encountered a problem using a brand new Dell 425s/L with Tseng ET4W32 
>chipset and PC-NFS. When using the Dell ET4W32 video-drivers under Windows, we 
>see that screen updating is disturbed. There are several white or black 
>rectangles. We tried several network cards/drivers: no difference. PC-NFS 4.0a 
>or 5.0a: no difference, ET4W32 version 1.0, 1.0a, 1.1: no difference. When 
>using VGA or ET4000 drivers, the problem vanished, so we suspect the Dell 
>ET4W32 drivers, but we only see the problem, when using PC-NFS. When 
>mounting/unmounting drives, the effects are different. (?) We have never 
>problems like this before.
>
>Can anyone help us out ...?


Try NET BLINK OFF before loading windows....

Leo


-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 1993 22:03:36 -0500
From:      ddean@robadome.com (Drew Dean)
To:        comp.protocols.tcp-ip
Subject:   Non-blocking connect

To followup on the recent discussion, I've found that a select on a socket
after a non-blocking connect will return ready for writing if the connect
was successful, and ready for both reading and writing if the connect failed.
This is true on SunOS 4.1.3 and BSD/386 1.0 (ie. a Net-2 TCP/IP).  Is
this documented anywhere (I didn't see it in the man pages) ?

Drew Dean
ddean@robadome.com aka ddean@shell.portal.com

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Sep 1993 14:06:57 +0000
From:      daveh@fusion.demon.co.uk (David Hodgkinson)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Overhead in duplex use of TCP socket connection


In article <27s8n4INN544@emory.mathcs.emory.edu> vss@mathcs.emory.edu (V.S.Sunderam) writes:

   In doing some timing tests, I recently noticed that there
   is a tremendous overhead associated with using a single
   TCP socket connection for bi-directional, small packet transfers.

   I.e. two processes connected by a streams socket incur heavy
   performance hits when they interact with "write; read" on one
   side, with a corresponding "read; write" on the other. 

   In most Unix implementations (Irix, SunOS, HPUX, Dec OSF?)
   this "turnaround" overhead seems to have a lower bound of
   100 msec. Interestingly, AIX is free of this problem!

The reason for this is that AIX is broken.

You are encountering "delayed write" which is intended to make better
use of the cable bandwidth by packing small fragments together. If you
want packets to go out in a timely manner, then you need to "push"
them. Even then, that is no guarantee, as senders can bundle up
consecutively pushed fragments. Equally receivers are allowed to be
lax abouting waking up the waiting task.

I would be more worried that AIX _isn't_ doing this.

Try making your "small" packet, say, 1420 bytes and see what happens.

   Anyway, does anyone have an explanation of why this is so?
   Any clues would be appreciated. Even better, fixes or workarounds
   are welcome. 

Read the rfcs. They're not as bad as all that. Or Comer's book.

Dave

--
Dave Hodgkinson - Wizard for hire.			+44 71 377 9009

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Sep 1993 23:13:42 -0500
From:      macgregor@austin.slcs.slb.com (William I. MacGregor)
To:        comp.protocols.tcp-ip
Subject:   Dynamic Black Tunnels?

[ This question is about secure IP service between portable computers 
  and distant networks; I apologize for its length, if you aren't 
  interested in the topic this is the place to stop... ]

Dynamic Black Tunnels (DBTs)

This message describes a problem and a functional concept called 
Dynamic Black Tunnels (DBTs) that could solve the problem.  Could you 
tell me if this problem is already understood, and if a solution is
already architected, under development, or available?

Pointers to relevant RFCs or other expertise would be appreciated.
Dialogue welcome,  - Bill


THE PROBLEM

The TCP/IP Internet is divided into "trusted realms" by "firewalls".
A "trusted realm" is a collection of TCP/IP Internet networks typically
operated by a single organization (e.g., a corporation).  Firewalls
permit only certain kinds of IP traffic to pass, possibly only between 
approved source and destination hosts.  Within a trusted realm, IP
routing is usually done with little or no filtering.

The concept behind a trusted realm is that the principals inside the
realm trust each other more than they trust the (entire) population 
outside the realm.  They are thus willing to allow greater freedom of
action to each other than to an outsider.

This model is widespread, and it is quite possible that there are now
more users inside trusted realms than directly connected to the
"public" Internet.  (Does anyone know how many firewalls adjoin the
public Internet?)  Trusted realms are relatively common and permanent
artifacts.

Enter portable computing.  An increasing number of Internet users are
now carrying portable computers, capable of operating as Internet
nodes using SLIP, PPP, or other dialup protocols.  Such a users might
wish to use dialup connectivity via commercial IP service providers,
but doing so places the user outside the home trusted realm, i.e., on the
"wrong" side of the firewall.

Hence the problem:  how might a SLIP or PPP dialup node connected to
a commercial dialup IP service be included, logically, in its home
trusted realm?


AN APPROACH

Dynamic changes to the firewall filters might be an approach, but this  
is impractical.  To be trusted, the firewall needs to remain relatively
fixed.

Dynamic Black Tunnels might offer a solution.  A DBT would be "dynamic"
because it is created on demand at dialup, and the IP address of at 
least one end of the DBT (the dialup end) can't be statically known
(because portable computers move around).  A DBT is "black" because it 
is carrying traffic through an untrusted realm (by definition), so the 
IP traffic over the DBT must be encrypted.  A DBT is an IP "tunnel" 
because it should carry all IP traffic, without restriction, between the
dialup node and hosts inside the home trusted realm.  The 
interoperability of the dialup unit with hosts in its trusted realm 
should be the same as if it were physically connected inside the realm 
(except for performance).

A DBT carries traffic through an encrypted tunnel between the dialup
node and a DBT "terminus" inside the trusted realm.  The terminus is
the transition point between unencrypted and encrypted IP traffic; it
is the other end of the tunnel.

To implement DBTs, several mechanisms are probably needed:  secure
authentication (kerberos?); dynamic dialup host configuration (PPP and/or
DHCP?); dynamic IP tunnels; and encrypted IP traffic.  A practical
implementation might involve a dedicated DBT terminus inside the
trusted realm, and DBT client software in the portable node.

Encryption should be done in software; there are plenty of cycles to 
encrypt data streams at dialup speeds of 20 Kb/sec or less.  The only
system components that should be aware of the existence of a DBT are
the terminus and a client layer in the portable--applications shouldn't
be affected.  The commercial dialup IP service shouldn't have to 
know about DBTs, either; it should just configure the dialup node and 
supply untrusted IP service.  Today's PC and Mac portables should be 
adequate client platforms.

A design might give the portable two IP addresses.  One is the IP 
address assigned dynamically by the commercial IP service; the other is
the IP address of the tunnel, an address assigned by the terminus.  So
the portable would effectively be a multihomed host, and would have to
respond to ICMP requests, for example, at either address.  The terminus
itself would appear to be a router to the network inside the trusted
realm.

Do DBTs already exist?  I've sketched the idea as a
means of connecting a dialup node to its trusted realm, but there are
other topologies and applications, and, of course, many fun issues 
to explore!  I'm sure there are subtleties of routing; DBTs might even be
impossible; wouldn't that be an interesting answer?

-- 
William I. MacGregor
Schlumberger Laboratory for Computer Science
Austin, TX

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Sep 1993 15:13:46 GMT
From:      root@lbm.com (Operator)
To:        comp.protocols.tcp-ip
Subject:   Class C Subnet

I could use a little assistance implementing a class C subnet in my shop.
We have a Sun 630MP running SunOS4.1.3 which provides our Internet access
(Morningstar PPP), and internal LAN. We have a class C net number. We also
have a substantial MAC population. We want to use the net interface which
comes on one of our fast SCSI sbus cards to supply LAN connectivity to our
MACs. We will need to feed TCP/IP and AppleTalk over this interface. I think
that I understand that each interface requires a separate subnet. Is this
so? AND if so, we want to fragment our class C address into two subnets,
one for the Unix hosts (Sparc processor built-in) and one for the MACs
(SCSI le1 interface). I really don't think I am comfortable in defining
the routing and subnet mask to accomplish this. We don't have a great number
of machines, so if we split it in hals, the 128 node per subnet figure is
just fine.

Thanx in advance,

Brian Arnold, Systems & Network Manager
LB&M Associates
211 SW A Ave.
Lawton, Oklahoma, 73501

Phone   : (405) 355-1471
Fax:    : (405) 357-9360
Email   : arnoldbs@lbm.com or root@lbm.com      [192.231.3.1]
          (Our network connection is not always up. Mail exchanger is
           uu7.psi.com [38.145.204.6])



-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Sep 93 15:50:07 GMT
From:      porche@dvorak.amd.com (John Porche)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.misc,comp.os.ms-windows.setup
Subject:   Re: Problem with comb. of Dell 425s/L, PC-NFS and ET4W32 windows-drivers

In article <vharten.31.000BAA71@prl.philips.nl> vharten@prl.philips.nl (Peter R. van Harten) writes:
>Hi troubleshooters,
>
>We encountered a problem using a brand new Dell 425s/L with Tseng ET4W32 
>chipset and PC-NFS. When using the Dell ET4W32 video-drivers under Windows, we 
>see that screen updating is disturbed. There are several white or black 
>rectangles. We tried several network cards/drivers: no difference. PC-NFS 4.0a 
>or 5.0a: no difference, ET4W32 version 1.0, 1.0a, 1.1: no difference. When 
>using VGA or ET4000 drivers, the problem vanished, so we suspect the Dell 
>ET4W32 drivers, but we only see the problem, when using PC-NFS. When 
>mounting/unmounting drives, the effects are different. (?) We have never 
>problems like this before.
>
>Can anyone help us out ...?
>
Hey, I see the exact same problem! I run PCNFS with a Local Bus ET4000
video card, In other words - I dont think it is Dell related. One hint 
though, I had a DX50 (486) with a heat sink.  When I moved over to
the Tseng "Turbo drivers" the sparkling went away.  I then changed to
a DX40 (486) overclocked with no heat sink, and the sparkling returned!
-Note-I was swapping out just the CPU - nothing else.



-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Sep 1993 15:57:16 GMT
From:      dkulkarn@tagore.helios.nd.edu (Dinesh Kulkarni)
To:        comp.protocols.tcp-ip
Subject:   Reliable Transport Protocols - State of the Art

Hi !

I would like to know if there are any reliable transport protocols
(stream & datagram) that have interfaces with the following characteristics.

* Appl. process on the sending side should be able to query the protocol
  implementation to find out the number of bytes (position in the stream)
  for which acknowledgements have been received.  Any out of order 
  acknowledgement, of course does not count.

* In case of datagrams, the interface should allow an application to
  query either

  1. The no. of the last datagram in a sequence of acknowledged datagrams
  or 
  2. A list of datagrams that have been acknowledged.
  or both.

Note that in both the cases, it is assumed that the protocol is connection
oriented.

Thanks a lot.

Dinesh


-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 1993 12:42:58 +0200
From:      koos@hacktic.nl (Koos van den Hout)
To:        comp.protocols.tcp-ip,comp.bbs.misc
Subject:   Telnet door for BBS ?

Hello everyone,

I am looking for a 'telnet' program that I can run as a door in my BBS.
This would enable callers to telnet to a given Unix machine (connected to the
BBS over an ethernet). The BBS PC's will be running the ODI drivers and a
packet-over-ODI driver.

I would like the telnet program to be able to use fossil for communicating
with the modem, and close the IP session and exit when carrier is lost.

The telnet program has to be 'secure' so the caller cannot reconnect to
a different host/IP number.

Does anybody know of such a program or is working on a beast like that ?

Thanks in advance for any help,

                                         Grtx. KH

-- 
||| Koos van den Hout. koos@kzdoos.hacktic.nl (pref.).

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 1993 16:12:41 GMT
From:      aej@manyjars.WPI.EDU (Allan E Johannesen)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Residence Hall Networking

Wiring the student residence halls for computer networking (and cable
and phones) is finally being contemplated on our campus.  We would
like to offer Ethernet connection or serial connections for those who
don't want to invest in Ethernet cards (purchased or leased from the
college, or whatever).

I would appreciate recomendations on media, on the network infra-
structure we should establish, any war stories, or even good
experiences with an effort like this (if there are any).  If there is
some mailing list or other newsgroup to try, I'd like to hear about
that, too.

Please mail; I'll post a summary if I get any responses.

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 93 17:24:03 GMT
From:      owe@labiche.laas.fr (Philippe Owezarski,,)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.
Subject:   problems with large packets on UDP


	I have written a videoconference system that works over a platform including two sun sparc stations 2 with two parallax cards and interconnected by an FDDI and an ETHERNET LAN. I have decided to use UDP sockets for the transmission of voice and video, because it is the only protocol I have that is able to transmit the data fast enough for my videoconference system.
	I have decided too to send each picture in one UDP packet. For that, I have to extend the size of the sending and receiving buffers. So when I have created the UDP client and server sockets with 

	*sock_descriptor = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

I have then to increase the sending and receiving buffers sizes with :

	int bufflen = 50000;

	setsockopt(*sock_descriptor, SOL_SOCKET, SO_RCVBUF, &bufflen, sizeof(bufflen))

	setsockopt(*sock_descriptor, SOL_SOCKET, SO_SNDBUF, &bufflen, sizeof(bufflen))


So, it should be possible to send packets whose size is 50000 bytes. But I have noticed that packets longer than 30400 bytes are not well handled by the system. They are transmited by the UDP transport layer to the IP network layer for segmentation. But after the segmentation operation they are too long for the Ethernet or the FDDI drivers that detect a giant packet. However these giant packets are sended on the physical link, But the receiver can not retrieve them, and prints it can receive giant packets 



(longer than 1518 bytes if it is on the ethernet LAN).

	So I would like to know if it is a well known problem of IP segmentation, or if I have forgotten an operation whose missing makes the sending of messages longer than 30400 bytes impossible. For the moment I do not understand what happens, and why the sending of packets whose size is around 40000 bytes is impossible while UDP sockets allow it.

		Thanks in advance

+----------------------------------------+-----------------------------------+
|                                        |                                   |
| Philippe OWEZARSKI                     |       E-mail: owe@laas.fr         |
| LAAS CNRS                              |                                   |
| GROUPE OLC (Outils et Logiciels pour   |                                   |
|             la Communication)          +-----------------------------------+
| 7 avenue du colonel Roche,             |                                   |
| 31077 TOULOUSE CEDEX,		         |     phone: (33) 61.33.63.20.      |
| FRANCE                                 |                                   |
|                                        |                                   |
+----------------------------------------+-----------------------------------+


-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 1993 17:25:56 GMT
From:      larry@eco.twg.com (Larry Henry)
To:        comp.protocols.tcp-ip
Subject:   Re: WOLLONGONG PATHWAY


In article <27oru6$2ql@falin.cs.uow.edu.au>, guriga@snrc.uow.edu.au (Istvan Kerekes) writes:
|>I need to know everything about  a S/W called WOLLONGONG PATHWAY.
|>1. What is it good for?
|>2. Vendor?  
|>3. etc.
|>Any info is appriciated !
|>

Istvan,
	PathWay is a family of products produced by The Wollongong Group. This
family of products supports:

o VMS (both AXP and VAX)
o UNIX (SVR4, Solaris, ... )
o DOS
o MACs
o OS/2

DOS is the most widely recognized member of the PathWay family since it was the
first PathWay product per say, however, all of Wollongong's TCP/IP products
have evolved to this architecture. If you need more information please contact
sales@twg.com. If your query was really in reference to the use of the word
Wollongong we can let you know that too... ;-)

-Larry.

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Sep 1993 17:59:41 GMT
From:      phuong@rocky.raleigh.ibm.com (Phuong Nguyen)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Broadcast packet limitations?

There is nothing wrong with you nor the system.  When you want use UDP
broadcast a packet greater than the frame size of media, UDP packs up
a packet and send it to IP.  Your packet is need to be fraged but the rule
is "can't frag the broadcast packet".  That's why you get the error.
Now, you know why so be happy.


*********************************
Opinions are mine not IBM's
Have a "phuongtastic" day,
Phuong Thanh Nguyen
Networking System.
PNGUYEN@VNET.IBM.COM
*********************************


-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 93 18:09:43 GMT
From:      peer@pid.HellNet.org (I. Pe'er)
To:        comp.protocols.tcp-ip
Subject:   Reading the Burn-in-address from a NIC


 With Novell or NetBios I can read the burn-in address from the
 Ethernet/Token-Ring cards.
 Could someone out there help me, poiting out how to  get it
 with NDIS drivers and Packet-drivers, using 'C' or ASM on a PC-DOS. 
 
 Thanks in  advance
 
 I. Pe'er
 System Integration R&D 
 ---------------------------------------
 P.I.D - Process Instrumentation Design
 ---------------------------------------
 

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 93 18:43:06 GMT
From:      mvm@cbnewsb.cb.att.com (michael.v.murphy)
To:        comp.protocols.tcp-ip
Subject:   BAD TRAP messages


	I am currently testing software on a SUN sparc 10 that uses tcp/ip tli
calls to transfer data to a MVS mainframe. The sysadmin has started getting the
following messages on the system consol:

BAD TRAP cpu=3 type=9 rp=f8833de4 addr=20 mmu_fsr=126 rw=1
MMU sfsr=126: INvalid Address on supv data fetch at level 1
regs at f8833de4

	<register dumps>

pid 12244, 'tcptli_auxproc': Data fault

	Following this message the tcp-ip access on ports seems to be suspended.
This has occured twice in the last 2 months, and a reboot fixes it. Does 
anyone out their have experience with this problem? Any suggestions on fixes,
patches, or were to go for help would be appreciated.

							Mike Murphy
							mvmurphy@attmail.att.co

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 93 19:46:34 GMT
From:      lvandyke@balboa.eng.uci.edu (Lee Van Dyke)
To:        comp.protocols.tcp-ip
Subject:   Wanted: Help with bsd socket problem (or how does recv work)


Hi, I am having a problem with a pc server and sun client application
using blocking stream sockets. 

It appears that the socket sometimes isn't flushed until the declared
buffer size is full. In "Unix Network Programming" by Stevens, pg.
279: "A read or write on a socket might input or output fewer bytes
than requested, but this is not an error condition. The reason is that
buffer limits might be reached for the socket in the kernel and all
that is required is for the caller to invoke the read or write system
call again, to input or output the remaining bytes."

So if the server only sends 3 bytes for a 80 declared buffer size
is another write  sometimes required to flush the buffer?


Next I have tried to use flow control via acknowledge for 
each write (send) since the pc and sun slow down with 
the upper application processes. This however, has
resulted in deadlocks. Then using nonblocking and the
select call things improve only when the receive 
buffer (recv) is about 512 bytes. If it is 80
the select call does not wait the 25 seconds
that is set in the tv_sec, but immediately releases?
Why is that?

I'm using Sun os 4.1.3, and on the pc Desqv 1.1 with their socket
library, Metaware Highc, Pharlap Linker and unfortunately ALsys
and Verdix Ada for the application.


Thanks for any help




--
Lee Van Dyke
      lvandyke@balboa.eng.uci.edu,
UUCP: infotec!Infotec.COM!lee@sunkist.West.Sun.COM

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 93 20:03:17 GMT
From:      lvandyke@balboa.eng.uci.edu (Lee Van Dyke)
To:        comp.protocols.tcp-ip
Subject:   Wanted: Help with bsd socket problem (or how does recv work)



Hi, I am having a problem with a pc server and sun client application
using blocking stream sockets. 

It appears that the socket sometimes isn't flushed until the declared
buffer size is full. In "Unix Network Programming" by Stevens, pg.
279: "A read or write on a socket might input or output fewer bytes
than requested, but this is not an error condition. The reason is that
buffer limits might be reached for the socket in the kernel and all
that is required is for the caller to invoke the read or write system
call again, to input or output the remaining bytes."

So if the server only sends 3 bytes for a 80 declared buffer size
is another write  sometimes required to flush the buffer?


Next I have tried to use flow control via acknowledge for 
each write (send) since the pc and sun slow down with 
the upper application processes. This however, has
resulted in deadlocks. Then using nonblocking and the
select call things improve only when the receive 
buffer (recv) is about 512 bytes. If it is 80
the select call does not wait the 25 seconds
that is set in the tv_sec, but immediately releases?
Why is that?

I'm using Sun os 4.1.3, and on the pc Desqv 1.1 with their socket
library, Metaware Highc, Pharlap Linker and unfortunately ALsys
and Verdix Ada for the application.


Thanks for any help




--
Lee Van Dyke
      lvandyke@balboa.eng.uci.edu,
UUCP: infotec!Infotec.COM!lee@sunkist.West.Sun.COM

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Sep 1993 20:06:09 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.sys.hp,comp.sys.sun.admin
Subject:   Re: How to kill every SUN on your network.

In article <1993Sep21.185611.23729@netfs.dnd.ca> BERRYMAN@orca.drep.dnd.ca (DON BERRYMAN) writes:
>...
>I cann't see why bridging FDDI/Enet should not be done, that is assuming
>the bridge was smart enough to:
>   1) Fragment large TCP packets to fit on Enet.
>   2) Not pass large UDP packets that cannot be fragmented.
>      This is allowable since UDP delivery is not guarenteed.
>   3) Not needlessly bridge FDDI packets to Enet and possibly
>      saturate Enet.
>   4) Some how not bridge UDP Broadcasts on FDDI when this would
>      saurate Enet. Again UDP delivery is not guarenteed so this
>      is allowable.

What does "allowable" mean?  Are you somewhere that has Protocol Police
that will break your knuckles if you do something that is "not allowable"?

Dropping large UDP/IP packets might get knuckles broken by the people who
pay for the hardware and salaries to run it.  Dropping large UDP/IP packets
makes NFS appear to work sometimes and not other times, to some
destinations and not others.

Is it "allowable" to drop IP packets because "IP delivery is not
guarenteed"?   IP is no more reliable than UDP.

Consider a pair of FDDI rings bridged to an Ethernet.  What do you suppose
happens to TCP circuits?  (Answer: they work sometimes but not other times.)

How does a bridge "not needless bridge FDDI packets to Enet"?


>         ... In the future/today you'd want to have the main highspeed
>network being FDDI with strands of Enet serving small groups of users.
>Thus you can use cheap Enet interfaces for most users while allowing
>maximum bandwidth on the main Network.

I do not understand what is intended by those sentences.  Who needs network
hardware that does not serve the applications for which it was purchased?


Vernon Schryver    vjs@rhyolite.com

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Sep 1993 20:11:48 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.sys.hp,comp.sys.sun.admin
Subject:   Re: How to kill every SUN on your network.

In article <1993Sep22.112335.26520@lokkur.dexter.mi.us> scs@lokkur.dexter.mi.us (Steve Simmons) writes:
>...
>A bridge connects networks together at levels 1 and 2.  Fragmentation only
>occurs at level 3 in the stack, IP datagrams.  TCP and UDP are level 4
>protocols.  By definition, if the connecting hardware understands the layers
>3 and up protocols, it is something more than a simple bridge.
>
>Bridges have several advantages.  Since they blindly replicate data on
>the wire from one media to another, they are independant of the higher
>level protocols.  Thus an ethernet bridge will merrily pass DECNET, IP,
>SNA, IPX, X.25, whatever, without ever having to think about it.  The
>solution proposed would require that the bridge be protocol-aware for
>*all* higher-level protocols.  I'm not sure that all of those protocols
>even permit fragmentation.

I agree with most of what you say, but be careful about being too religious
with the OSI layering religion.  Layers are only a useful way to segment
your thinking, to postpone some questions.

Even ignoring packet sizes, to bridge some traffic between Ethernet and
FDDI, you must rewrite some of the higher-layer headers.  The classic
example is one of the flavors of Appletalk.  Doesn't IPX's old 802
encapsulation have a similar problem?


Vernon Schryver    vjs@rhyolite.com

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Sep 1993 20:19:00 GMT
From:      jeff@astph (Jeff Martin)
To:        comp.protocols.tcp-ip
Subject:   tcp reliability VS udp simplicity (long)


dear tcp/ip programmers,

first post to this group.

we are developing on a UNIX SYSV, Interactive Rel 3, Ver 3.0.
we have both Berkley sockets and TLI available for our network
programming.  we are working on a client/server application
to be distributed on a network.  the server will return
database information from a file server machine to
clients as they request it.  the server is very i/o intensive.
the client processes will be distributed across the network on
application machines.  we may have 100-200 client processes.  each
of these processes will be making requests to the server at different
speeds and amounts.  thus the load of the clients on the server will
be variable.  we can assume that on the average the number of
simultaneous requests to the server machine will never be more than
25 of 100 processes.  finally one complete request to the server
from one client would consist of one write() and read() by the
client process and one read() and write() by the server process.
the size of information to pass in this read and write would be
a maximum of 65536 bytes.

the model we hope to design includes many client processes on
application machines with few server processes on the server
machine.  for every 10 client processes we may have 1 server
process.  with this model we hoped to accomplish two goals
in optimizing our networking speed.  first fewer processes on
the server machine will allow a more efficient use of the
server processor with less context switching and less idle
server processes.  keep in mind that less than 25 of 100 client
processes will be making requests to the server machine at one
time.  thus if we had one server process for each client process
we would have alot of idle server processes.  secondly we want
more than one server process so as to allow concurrent processing
to take place on the server.  these processes are to be
preallocated because the fork() call is too expensive to include
into every request to the server.  we want just enough server
processes so that as every client request reaches the server
machine we have an idle server process ready to pick up the
request.  the book, "Internetworking with TCP/IP, volume III"
by Comer, explains much of this model in chapter 15.  need i
describe our networking goals anylonger?

Comer's book explains how to achieve this model with both TCP and
UDP, connection-oriented or connectionless-oriented.  we have tried
both and still have questions remaining.

First the TCP/connection-oriented, many clients, few servers model.
we hesitantly chose this model because the cost of establishing
a connection for each server transaction seemed too high.  especially
when the concept of a socket connection seemed to imply more longevity
than one write() and read() by the client and one read() and write()
by the server.  to close() after such a short interchange seemed to
be fairly expensive compared to the cost of establishing the connection
in the first place.  however perhaps that is the cost of reliability?
well we have yet to get this model to work anyway!

Comer implies that many server processes should be able to block on
the accept() call with only one of the processes accepting each
request for a connection and server request.  we know that we are
missing something here but we cannot get this to happen.  we have
a single server process create a socket, bind to the address,
listen on the socket, fork to create a few more of us, and finally
everyone calls the accept call and blocks.  fine so far.  however
our client now creates a socket,  calls connect, but unfortunately
one server bombs immediately at this point with accept() returning
error number 71.  the client hangs.  does any one have a clue what
we are doing wrong?  perhaps some setsockopt() calls of something?

to simplify things we tried to use just one server and one client
to perform our request exchange.  that is for each transaction we
establish a new socket connection, write to the server, read from
the server, close the socket, and start again.  this seemed to work
great, but only for about 300 odd transactions.  at this point we
recieve an error message from the server accept() call of number 63.
the client returns error 126 from the connect() call.  again any
clue as to what we are doing wrong here?  interestingly enough if
i do a "netstat" command immediately after the client/server bombs
i get a report of TIME_WAIT type errors.  have i run out of socket
resources or something?

Secondly, enter the UDP/connection-less, many clients, few servers model.
with all these problems and concerns we looked into possibly using
UDP to simplify the client/server model and solve our TCP problems.
UDP seems to offer some attractive features for our needs.  we can
pre-allocate several server processes all to block with a recvfrom()
on the same socket.  we are assured of only one server recieving the
datagram.  we are also assured that the datagram transaction boundaries
are maintained across the client/server processes.  we can then start as
many clients as we wish and let them sendto() the server socket.  the
model looks great.  it is considerably faster than TCP because it
is skips the connection establishment.  however it has two shortcomings.
UDP does not insure reliable message delivery.  UDP maximum size
limitations would require us to break up our datagrams into small
packets which may not be delivered in the proper order.  and more than
that, if we have to break up our packet how can we easily deliver the
entire packet to the server process which picked up the first packet
segment?  considering our limited time and programmer resources it
seems a monumental task to code solutions for those two problem.

has anyone else noticed the need for a combination of UDP and TCP
features?  that is a reliable datagram service with a much larger
datagram size maximum to allow sending our packets with one sendto()
and one recvfrom().  does such a protocol exist or has someone
out there created this software?  i have begun reading "Unix System V
Network Programming" by Rago.  on page 10 of the text Rago mentions
the concept of a reliable datagram service.  we imagine this guy
knows what he is talking about, however Comer's books imply that
UDP/datagram service is synomous with unreliability.  who to believe?

In conclusion getting the UDP model to work reliably with larger
datagram sizes than now available would be fantastic.  we would
have the speed and simplicity of UDP and the flexibility to create
the client/server model of our choice.  if this is not possible
perhaps there is some ridiculous over-sight that is keeping us from
getting the TCP model to function properly.  any help would be
greatly appreciated.

signed, jeff


-- 
Jeff Martin, dbms programmer,		Philadelphia Phillies
INET:	astph!jeff@attmail.com		Voice:	(814)234-8592x32
UUCP:	attmail.com!astph!jeff		FAX:	(814)234-1269

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Sep 1993 21:00:33 GMT
From:      rpratt@novell.com (Robert Pratt)
To:        comp.protocols.tcp-ip
Subject:   Re: "Promiscuous-mode" token ring controllers

In article <272egp$q4a@eve.atm.com> brianhe@eve.atm.com (Brian Henry) writes:
>I think that it is theoretically possible (from an electrical signal
>standpoint) for any token ring card to do this.  However, the firmware
>on the card usually prohibits looking at any packet but those
>addressed to you.
>The exception that I know of is the IBM TAP (Trace and Performance)
>card, which does exactly what you are talking about.  It has special
>firmware on board to allow it to do this.

   Actually, a more accurate way of putting it is that IBM's firmware,
in the Tropic chipset, doesn't allow the card to do promiscuous mode.
Every other Token Ring chipset that I know of allows promiscuous mode,
including the new IBM one.  Its only Tropic that is brain dead in this
regard.  And while the IBM TAP card allows you to receive in promiscuous
mode, you lose all transmit capabilities in return.  Not the greatest
design in the world, IMHO.

Bob
Bob Pratt                               | voice     : (408) 473-8274
Novell, Inc.                            | Fax       : (408) 435-1706
2180 Fortune Drive, San Jose, Ca. 95131 | Internet  : rpratt@Novell.com
Disclaimer:  I do not speak for Novell in any way, shape, or form.
"Cuius testiculos habes, habeas cardia et cerebellum."
        -- (Terry Pratchett, Small Gods)

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Sep 1993 21:23:52 GMT
From:      solomon@becks.comm.mot.com (James Solomon)
To:        comp.protocols.tcp-ip
Subject:   What is this protocol?


Greetings,

From "Assigned Numbers", a.k.a. RFC 1060:

   Service Name   Port/Protocol   Description
   ------------   -------------   -----------
     [...]
   shilp           2049/udp

Does anyone know what this protocol is (shilp)?  I can't seem to find a
reference to it in any of my man pages or any of the RFCs.  Please reply by
Email.

Thanks,
-- 
Jim Solomon (solomon@comm.mot.com)
Disclaimer:  It's my fault, not Motorola's.

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Sep 1993 22:11:11 GMT
From:      davek@davbon.uucp (Dave Kennedy)
To:        comp.protocols.tcp-ip
Subject:   DCE vs. RPC 4.0

I am using RPC for a project that has to run clients and servers on:

   IBM AIX
   Sun (probably Solaris 2.2)
   MS Windows
   OS/2

For various internal political reasons the decision to use RPC is
being slammed.  The main technical argument is that RPC does not provide
multi-thread capability intrinsically.  I am not emotionally tied
to RPC or DCE.  And I am willing, within the project's time constraints
to use DCE.  In fact, having some assistance from DCE with threads
would be nice.  My question is: 

   Is DCE available on all the above platforms?
   Is it reliable on all the above platforms?

If you have information contrasting and comparing the two, please post
the info or post a pointer to an ftp site.  Postscript, nroff, ASCII -
heck just about anything in English would be fine.

Thanks.
-- 
| Dave Kennedy        -  UUCP {gatech,emory}!wa4mei!igikpak!davbon!davek |
| Home: 404-368-0331  -  Internet  wa4mei!igikpak!davek@mathcs.emory.edu |

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 1993 10:05:01 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: Class C Subnet

In article <1993Sep23.151346.8520@lbm.com> root@lbm.com (Operator) writes:
>I could use a little assistance implementing a class C subnet in my shop.
>We have a Sun 630MP running SunOS4.1.3 which provides our Internet access
>(Morningstar PPP), and internal LAN. We have a class C net number. We also
>have a substantial MAC population. We want to use the net interface which
>comes on one of our fast SCSI sbus cards to supply LAN connectivity to our
>MACs. We will need to feed TCP/IP and AppleTalk over this interface. I think
>that I understand that each interface requires a separate subnet. Is this
>so? AND if so, we want to fragment our class C address into two subnets,
>one for the Unix hosts (Sparc processor built-in) and one for the MACs
>(SCSI le1 interface). I really don't think I am comfortable in defining
>the routing and subnet mask to accomplish this. We don't have a great number
>of machines, so if we split it in hals, the 128 node per subnet figure is
>just fine.
>
   
      What you really should do is make sure that each interface
      on a given machine has a different "network" portion of the
      internet address.  That way the IP layer in each machine
      can easily figure out what interface to send individual packets
      on.

      If you have a machine with two interfaces that have the same
      effective network address (network portion of the internet
      address), some vendor's IP layers become 'truly quaint' in
      trying to figure out which physical port to send packets on.  

      I've seen implementations which would receive packets on any
      of the multiple interfaces but only send on one of them (which
      is perfectly legal).  

      I don't see that you really need to implement subnetting at all
      if you don't EVER expect to have more than 128 hosts on your
      entire network.  

      Just use a netmask of 'ffffff00' on all the machines in the
      network, and make sure that the two (or more) interfaces on
      a given machine do NOT have the same first three fields in
      the dotted notation.  

      E.g.  192.24.32.15 and 192.24.32.16 would be two hosts on
      the network known as 192.24.32...   you wouldn't want two
      interfaces on the same machine addressed such.  

      You'll need to configure default routing in all the machines
      with multiple interfaces or use routed...as  ONLY machines on
      the same "network"  (with the same network portion of internet
      address) can communicate directly with each other--without a
      router or using the hosts themselves as router/gateways.

      192.24.32.15  
      192.24.32.16
      192.24.32.22
      192.24.32.109

	  These would all be hosts (host is the 4th item for class C)
	  on the same network.  All could talk to each other.  

      192.24.33.15 and 192.24.32.15 would be considered as two
      hosts on two different networks and could only speak to one
      another if there is a router on the network, or if they are
      interfaces on the same machine.  This is because the two
      have different network portions of the address.   

      Hope this helps....


>Thanx in advance,
>
>Brian Arnold, Systems & Network Manager
>LB&M Associates
>211 SW A Ave.
>Lawton, Oklahoma, 73501
>
>Phone   : (405) 355-1471
>Fax:    : (405) 357-9360
>Email   : arnoldbs@lbm.com or root@lbm.com      [192.231.3.1]
>          (Our network connection is not always up. Mail exchanger is
>           uu7.psi.com [38.145.204.6])
>
>



-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Sep 1993 23:35:32 GMT
From:      swslr@well.sf.ca.us (Larry Krone)
To:        comp.protocols.tcp-ip
Subject:   Help with AIX TCP

Gentle People:

We have a need to have several sites call into a set of modems at our
main office....we would like to use some sort of TCP protocol to make 
this all happen....(so we could have multiple sessions....)

Apparently, all AIX seems to have is slip (without even something neat
like sliplogin) and this makes it very hard to set up this sort of 
configuration unless I designate a modem for each site, which I do not
wnat to do....

Is there some sort of sliplogin out for AIX, or better yet, 
is there a PPP implemetation that can be used on AIX out there
somewhere????

Thanx....


Larry
swslr@well.sf.ca.us


-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Sep 1993 23:55:40 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: giant packets

rand@cs.UND.NoDak.Edu (Douglas K. Rand) writes:
}We've been getting quite a few of these messages logged lately, and I
}don't have much of an idea of whats causing them. Can anybody help?
}0:0:55:55:55:55
}0:0:c:55:55:55
}0:0:c:6:52:b7
}0:0:c:a6:aa:aa
}0:0:c:aa:aa:aa
}0:0:f3:0:27:3c
}0:0:f3:0:27:54
}0:50:55:55:55:55
}0:a8:aa:aa:aa:aa
}40:55:55:55:55:55
}54:55:55:55:55:55
}55:55:55:55:55:55
}80:aa:aa:aa:aa:aa
}a0:aa:aa:aa:aa:aa
}a8:aa:aa:aa:aa:aa
}aa:aa:aa:aa:aa:aa

  Looks like noise to me.

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

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Sep 1993 00:41:06 GMT
From:      heberlei@cs.ucdavis.edu  (Louis Todd Heberlein)
To:        comp.protocols.tcp-ip
Subject:   RPC portmapper

I am have been reading over the O'Reilly book on RPC, and
I was curious about the portmapper routine.  According to
my reading, before a client calls a server (which is at
some unknown port), an RPC call is first made to the
portmapper (which is at a well known port, 111).  Now a
number of the RPC protocol definitions are in
 /usr/include/rpcsvc (e.g., mount.x, yp.x, and nfs_prot.x).
But I cannot find the protocol definition for the original
RPC call to the portmapper.

Am I missing something?  Is there an FTP site which has this
protocol definition file (and perhaps more .x files)?

Any help would be appreciated.

Thanks,

Todd			heberlei@cs.ucdavis.edu

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 1993 02:04:37 GMT
From:      geoff@poori.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC portmapper

On SunOS 4.x (and systems whose RPC implementations are derived from
that source base) there is no .x file provided for the portmapper,
but the relevant .h files can be found in /usr/include/rpc.  On
Solaris 2.x (and presumably other SVR4 systems) you will find
the .x files for portmap and rpcbind (the TIRPC equivalent) in the same
directory.  You should also look at RFC1057.

Geoff
-- 
Geoff Arnold, PC-NFS architect, Sun Select. (geoff.arnold@East.Sun.COM)
#### "Here the ways of men part: if you wish to strive for peace ####
####   of soul and pleasure, then believe; if you wish to be a   ####
####     devotee of truth, then inquire..." - Heinrich Heine     ####

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 1993 02:06:47 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Logging in and out addresses

In article <1993Sep9.233411.24945@lds.loral.com> arterton@lds.loral.com writes:
>My boss wants a way to log the originating address, the date and time,
>and the destination address of a connection made by an employee over
>the Internet.  He is interested in the connections to the outside
>world.  This type of log might have the format shown below:
>
>Date:   Time:        Originated:         Destined for:
>Sep  9  17:14:52     158.186.241.70      192.9.200.18
>
>Could a ciscoSystems router, model AGS+ do this?  Or, could a Sun
>workstation be configured to listen on the net, capture the data and
>format a report like this?  Is there some readily available software
>that could do it?

I don't know about other possible solutions, but if you use a Digital
Ultrix or OSF/1 system as a router, the "screend" software (included
with either operation system) does both access control and logging.

Screend does not log "connections", it logs packets, but it does
a fair amount of automatic log compression, so the logs typically
are not too huge.  (On the other hand, while screend can be set up
to log/not log a huge variety of patterns, we usually log only
the packets that are rejected for security reasons.)

See my paper in Proc. 1989 Summer USENIX Conference for more info
on screend.

This approach isn't going to have nearly as much throughput as
specialized router hardware would.  But if your load is light,
it might be appropriate.

-Jeff

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Sep 1993 02:18:12 GMT
From:      ag995@Freenet.carleton.ca (Marwan Forzley)
To:        comp.protocols.tcp-ip
Subject:   Internet address


Can someone tell me how to get an Internet address.Who should 
I call to get my own address for my own small network. i also
need to know what software i need to get to be able to telnet
and ftp from my pc. It  would be appreciated if you can answer
my question by giving me some detailed information as well as
how much $$$ do i need to setup this project.
Thanks
-- 
******************************************************************
***                                                            ***
***                           MARWAN                           ***
***                     ag995@freenet.carleton.ca              ***

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 93 02:55:57 GMT
From:      kenw@skyler.arc.ab.ca (Ken Wallewein)
To:        comp.protocols.tcp-ip
Subject:   Address resolution on non-broadcast networks


  We are in the processess of setting up a 200-plus-subnet TCP/IP network 
which will use X.25 as the wide-area carrier.  Unlike Ethernet networks,
there appears to be absolutely no way for X.25-connected nodes (i.e.
routers) to discover each other's MAC (X.121) addresses based on their IP
addresses, as is done by the ARP protocol.

  I'm kinda blown away by this.  Sure, X.25 doesn't directly support
broadcast-based ARP, but surely one of the routing protocols might
distribute the MAC addresses.  Nope, looks like we're stuck maintaining the
tables manually.  There's _gotta_ be a better way!

  And get this: ICMP redirects, which tell a node on a network how to talk
(more) directly to another node, do not pass on this information either.
So it tells the node to talk to an address that that node doesn't know how
to reach, thus breaking the connection set-up.  And there's no way to turn
it off!

  OK, now -- have I missed something?  Have I screwed up?  Is there a
solution to my woes?  Or is IP over non-broadcast networks just broken?

/kenw



--
/kenw  (as me)

Ken Wallewein
kenw@skyler.arc.ab.ca
(403) 274-7848


-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Sep 1993 03:31:09 GMT
From:      martelm@sco.COM (Martel Manalo)
To:        comp.protocols.tcp-ip,alt.internet.services,comp.dcom.lans.misc,comp.dcom.sys.cisco,comp.sys.sun.admin,comp.unix.admin
Subject:   Re: Evaluating Internet Services

Can someone send me the internet address of BARRNet in San Francisco ?
I need to find out how much it would cost to lease a dedicated 64k port.
Their FAX number would also be greatly appreciated.

Thanks,
Martel Manalo
SCO Canada
email: martelm@sco.com


-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Sep 1993 04:21:02 GMT
From:      mick@ddiq.com (Mick Galvin)
To:        comp.protocols.tcp-ip
Subject:   tcp to Z8000cpu port - HELP!

Project hell calls for porting tcp/ip to a Z8000 based controller. First 
question; has anyone heard of this sort of port? Hearing nothing, my next 
questions are: Does anyone know of a z8000 C compiler?
               How about source for tcp close to z8000 code?   
               Anyone got a strategy regarding this?
               How about opinions on a better news group to post to?
-- 
-----------------------------------------------------------------------------
         We have the tools, we have the talent - it's Miller time!
-----------------------------------------------------------------------------

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Sep 1993 06:06:01 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: Bug in inet_addr()?

> >On the other hand, the inet_addr() function from inet(3) uses the
> >return value -1 as an error indication, so that it cannot be called
> >with 255.255.255.255 as an argument.  This means that, for instance,
> >"ping -sv 255.255.255.255" reports "unknown host" (although this
 
> >Is this a bug in inet_addr()?

rstevens@noao.edu (W. Richard Stevens) writes:

> Yes.  The BSD Net/2 code fixed this by adding a new function called
> inet_aton() with a second argument (struct in_addr *) that points
> to the return structure; then the function returns 0 or 1.  I haven't
> looked around to see what vendors have picked up this new function.

I hope it got rid of the assumption that a leading 'x' meant hex, as
well....  a group here ignorantly named systems "x400" and "x500", which
seemed perfectly fine, except that some utilities including ping won't
touch them.  (Many systems attempt to ping 0.0.4.0 and 0.0.5.0, AIX reports
"Address malformed", other systems do similar entertaining things).

-- 
Tom Fitzgerald    Wang Labs, Lowell MA, USA    fitz@wang.com   1-508-967-5278
inews: .sig discarded because it contained false or misleading information

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Sep 1993 06:40:44 GMT
From:      hjb@netcom.com (hwajin bae)
To:        comp.protocols.tcp-ip
Subject:   Re: Non-blocking connects

not to add further confusion... but here's what i use to accomplish
non-blocking connect.

---

	ioctl(fd, FIONBIO, &on);
	if (connect(fd, sin, sin_len) < 0) {
		if (errno == EINPROGRESS) {
			FD_ZERO(&write_fds);
			FD_SET(fd, &write_fds);
			if (select (FD_SETSIZE, NULL, NULL, timeout) > 0) {
				if (FD_ISSET(fd, &write_fds)) {
					if (getpeername(fd, &peer, &peerlen)<0)
						bad!!!!!
				}
			} else
 bad!!!!
		} 
	} else
		OK!

---

non-blocking connect followed by a select with desired timeout val.
after you detect WRITE is set (can write on socket) by select, you
can do getpeername() to double check.

this works in all bsd 4.3 derived TCP/IP systems i've used including
VxWorks realtime OS, which has the function connectWithTimeout() built in,
which does exactly the same as above, since i wrote it ;-)

--
Hwajin Bae (hjb@netcom.com, hjb%peacefulstar@wrs.com)	2899 Ford Street
PEACEFUL STAR						Oakland, CA 94601
Consulting Services: UNIX, VxWorks, FREE kernel		Voice/FAX: 510.536.7607
TCP/IP, NFS, Realtime, Embedded systems, SW & HW	Pager:     510.466.9166

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Sep 1993 08:30:59 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: Non-blocking connects

hjb@netcom.com (hwajin bae) writes: 

>not to add further confusion... but here's what i use to accomplish
>non-blocking connect.

I believe this could use a few slight clarifications.  If I've made errors,
flame away.

>---
>
>	ioctl(fd, FIONBIO, &on);
>	if (connect(fd, sin, sin_len) < 0) {
>		if (errno == EINPROGRESS) {
>			FD_ZERO(&write_fds);
>			FD_SET(fd, &write_fds);
>			if (select (FD_SETSIZE, NULL, NULL, timeout) > 0) {
>				if (FD_ISSET(fd, &write_fds)) {
>					if (getpeername(fd, &peer, &peerlen)<0)
>						bad!!!!!
>				}
                                else { what to if connect times out }
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>			} else
 bad!!!!
>		} 
                else { bad!!!! } // the connect failed in an unexpected way
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>	} else
>		OK!

/*
** And if the connect succeedes only *after* the select() call, control
** will drop to here, without passing through the "OK!" block behind the
** "else" statement.
*/

Fred

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Sep 1993 08:47:32 GMT
From:      steven@unipalm.co.uk (Steven Vincent)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip,IPX and decnet

dmurphy@ithaca.Eng.Sandy.Novell.COM (David Murphy) writes:

>In article <1993Aug20.014140.3146@colorado.edu> dwing@uh01.colorado.edu writes:
>>In article <abbott-190893140340@159.56.3.20>, abbott@pixel.kodak.com (Terry 
>>Abbott) writes:
>>
>>>Is there a product or products that I can run on an intel processor to
>>>allow tcp/ip, IPX/SPX and decnet at the same time?
>>
>>Do you want to run an operating system, too, or just networking protocols?  
>>:-)
>>
>>
>>-Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet
>>


>u can do this with ODI, in DOS or OS/2 using ODINSUP for the NDIS DECNet Stack
>and TCP/IP over ODI or TCP/IP over NDIS using ODINSUP, and DOS can handle it.
 
>This is one of the reasons for ODINSUP's orig. development.

You can do this w/o ODI as well.

In fact I have found that using NDIS for DEC Pathworks,
DIS_PKT.GUP for PC/TCP from FTP Software
            and a BYUIPX binding to the DIS_PKT.GUP actually used less RAM.

Of course you milage will vary since the relative sizes of the NDIS driver and
the MLID make a big difference.  Also Performance will matter a lot (Try to get
the most important stack to be using its native mode driver and minimize the
numbers of conversions your traffic goes through).

i.e ODI over LanSup (IBM ASI) over NDIS does work but is extreamly slow.
    Especially when the NetX module started trying to send 2k packets on
    Ethernet. (LanSup being needed for IBM'S PC-Support).

>David_Murphy@novell.com         All opinions are my own, not the employer's
>                                And I am not a support person either, so 
>                                support questions should go to support people.
================================================
Steven Vincent,             steven@unipalm.co.uk
Unipalm Ltd.                (44) 0223-250100
Cambridge,
England.
================================================


-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Sep 1993 23:50:10 -0600
From:      Mike.Dale@tdkt.kksys.com (Mike Dale)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Resource

I'm absolutely new to TCP/IP and am looking for a good (basic) yet comprehen-
sive resource.

Anyone have any suggestions? Any FAQ's floating around, books, etc.

Mike                                               

mike.dale@tdkt.kksys.com

 * Origin:  Command Line BBS - Mpls. MN - v.32b (612) 788-6685 (1:282/2007)


-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Sep 1993 14:52:00 GMT
From:      anton@AccessPoint.North.Net (Anton Aylward)
To:        comp.protocols.tcp-ip
Subject:   RFC 1375 - any deveopment

I'd like to know if there have been any development of the dieas
proposed in RFC 1375.

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Sep 93 17:28:14 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Reading the Burn-in-address from a NIC

In article <748807783snx@pid.HellNet.org> peer@pid.HellNet.org writes:

    With Novell or NetBios I can read the burn-in address from the
    Ethernet/Token-Ring cards.
    Could someone out there help me, poiting out how to  get it
    with NDIS drivers and Packet-drivers, using 'C' or ASM on a PC-DOS. 

Look at pktaddr.asm in the Crynwr Packet Driver Collection -- it does
exactly what you want.

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

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Sep 1993 17:38:24 GMT
From:      msells@undergrad.math.uwaterloo.ca (Marty Sells)
To:        comp.protocols.tcp-ip,biz.sco.general
Subject:   ST-II (or raw ip) on SCO. /etc/sockcf?

[This is cross-posted. Please follow up to email. -Thanks]

I am trying to install ST-II, a streams protocol, (RFC 1190)
onto a SCO box. I have instructions on how to install ST-II
onto a Sun, which involves rebuilding the kernel and other
not so nice things. If I have to I am willing to do this
on the SCO, but the networking is different enough to cause
me big problems. Here is what I need:

ST-II runs with IP version number set to 5. What I would like
is to have a socket type interface to this protocol. I need
to be able to send packets and recieve packets with IP version
set to 5. I *THINK* I need to modify /etc/sockcf, but what
do I use for a device?

I am willing to somehow use RAW IP sockets to get what I want
but that needs the protocol to be in /etc/sockcf. Also I think
that sendto will pre-pend the IP header with version set to
4.

Does anybody have any RAW IP code for SCO? Has anybody changed
/etc/sockcf? I don't need a walk through, but some pointers
or snippits of code would be a big help.

Thanks,
Marty.

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 93 17:45:40 GMT
From:      mdivax1!robinson@pobox.mot.com (Jim Robinson)
To:        comp.protocols.tcp-ip
Subject:   Re: DCE vs. RPC 4.0

Dave Kennedy (davek@davbon.uucp) wrote:
>I am using RPC for a project that has to run clients and servers on:
 
>   IBM AIX
>   Sun (probably Solaris 2.2)
>   MS Windows
>   OS/2
 
>For various internal political reasons the decision to use RPC is
>being slammed.  The main technical argument is that RPC does not provide
>multi-thread capability intrinsically.

Sorry to follow up a question w/ a question, but there must be more to DCE
over ONC than just multi-threading as this feature could probably be
retro-fitted by Sun (or whoever) to ONC without a whole lot of work. Given
the apparent industry embrace of DCE, I would hope this technology to be
significantly more functional than ONC. Is this not the case, or has
marketing and/or politics taken its toll?  
[disclaimer - my knowledge of DCE is quite thin]
-- 
Jim Robinson
robinson@mdd.comm.mot.com
{ubc-cs!van-bc,uunet}!mdivax1!robinson


-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 1993 19:27:57 GMT
From:      mjr@tis.com (Marcus J. Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Dynamic Black Tunnels?

>This message describes a problem and a functional concept called 
>Dynamic Black Tunnels (DBTs) that could solve the problem.  Could you 
>tell me if this problem is already understood, and if a solution is
>already architected, under development, or available?

	I have a modified version of a TCP/IP tunnel device driver
with a packet passing daemon that does DES encryption. It can be
used to implement host-to-host network tunnelling in a manner
similar to what you describe.

	Adding dynamicness would be best approached by just having
a level of authentication for the packet passing daemons, and
possibly expanding the protocol to do dynamic addressing.

	Note that some routers are starting to do encrypting and
tunnelling of traffic already (which is why I gave up doing it
in the host). I can probably make the code for the modified tunnel
driver and packet passer available to US citizens, if anyone
wants it.

mjr.

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Sep 93 20:20:44 GMT
From:      tanm@seneca.bst.rochester.edu (Martin Tanner)
To:        comp.protocols.tcp-ip
Subject:   milan 800 transceiver


 I would be very interested in hearing any comments on the above product.
I am especially interested in comments on quality and reliability of the 
product.  Please e-mail me directly. 
 
Thanks, 
Martin 
~


-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Sep 1993 23:32:56 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Broadcast packet limitations?

In article <CDrCr8.E3y@agedwards.com> cleelacj@agedwards.com (Chris Cleeland) writes:
>I have consulted the Usual Sources of Knowledge, only to find nothing
>specific regarding the subject...
>
>What limitations are imposed on UDP broadcast packets in terms of sizes
>of data that can be transmitted, etc.  My man pages discuss the max
>and the default for UDP, but don't expressly discuss how they relate to
>broadcast UDP.  Thus, I don't expect there to be any differences; am
>I mistaken?
>
>The specific thing I'm trying is to broadcast a datagram that is larger
>than a single MAC layer packet (about 2k bytes), but the implementation
>of TCP/IP I'm using refuses to send any datagram larger than a MAC packet.
>Is it brain-dead, or am I?

This is another one of those things inherited from BSD Unix.  The IP code
in BSD Unix (and derivitives) refuses to fragment IP broadcast packets.
The IP spec itself does not rule out fragmenting them, but the BSD
behavior is pretty widespread.

Art


-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 93 21:41:25 EET
From:      jaakola@cc.helsinki.fi
To:        comp.sys.dec,comp.protocols.tcp-ip
Subject:   SLIP Alpha OSF/1 - ka9q problems

I'm trying to connect a PC running ka9q with Alpha AXP 4000 model 610
running OSF/1 V1.3 using SLIP.

I have read "Configuring Your Network" and slattach man pages. I did
what the configuration guide said and the issued a "slattach +c -i tty00
19200" command. When I dial from the ka9q and try ping or telnet, modem
"send data" LED blinks but nothing comes back!

On the alpha "ifconfig sl0" says just flags=10<POINTTOPOINT>. I tried
"ifconfig sl0 up", and then the flags were UP,POINTTOPOINT.

When I try to ping from Alpha the slattach process disappears and ping
says "sendto:host is unreachable" and ret=-1.

WHAT SHOULD I DO?

I have successfully used SLIP between AIX and ka9q and between HP-UX and
ka9q. But now I don't know what to try next.
--
Juhani Jaakola, jaakola@cc.helsinki.fi

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Sep 1993 00:02:26 GMT
From:      maxstrat@shell.portal.com (Peter van Cruyningen)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   NFS/TCP-IP dynamic buffer sizing? (techy)

I am designing a high-throughput TCP/IP engine to be used in a server
which supports both NFS and FTP access.  In order to achieve the high
performance (>400Mbps), window scaling with large windows (300-500K)
appears to be necessary (recent thread in .tcp-ip).  Using large
window sizes requires correspondingly large buffers.  However consider
a server which is NFS mounted from multiple clients.  Each client
maintains a permanent TCP connection to the server (recent thread in
.nfs).  Therefore the server must maintain separate large buffers for
each connection even though many may be idle.

One possible solution to this is to support dynamic buffer sizing
with allocation by all connections from a common pool (the available
memory).  Initially each connection could allocate a small buffer
(eg. one segment), and as data arrives, dynamically increase the
allocated space (and the corresponding advertised window).  One
problem with this is when the client stops sending data, that 
connection will have a large advertised window which the server
cannot shrink, so the large memory buffer again lies there idle.

Any ideas?  Thanks,
--
Peter van Cruyningen (peterv@maxstrat.com)

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Sep 1993 02:06:27 GMT
From:      mrs@kithrup.com (Mike Stump)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: NFS/TCP-IP dynamic buffer sizing? (techy)

In article <CDvus4.EM5@unix.portal.com> maxstrat@shell.portal.com (Peter van Cruyningen) writes:

>Using large window sizes requires correspondingly large buffers.
>However consider a server which is NFS mounted from multiple clients.
>Each client maintains a permanent TCP connection to the server
>(recent thread in .nfs).  Therefore the server must maintain separate
>large buffers for each connection even though many may be idle.

No, the conclusion does not follow.  For idle connections, you don't
have to have any resources (data buffers) allocated exclusively for
the connection.  You are free to toss things that come in for it, and
merley mark it as non-idle, and when freeing resources, assign them over
to the newly non-idle connections that need the resources.

One way to do this may be just advertise lots initially.  Internally,
hopefully you can turn things around in short order, and hopefully you
get things in sequence.  So in general a smaller amount of memory
should be enough.  When you run out of memory, you just toss
something, and continue.  When you do run out of memory, you can then
take throttling steps, or down window sizes, or disallow new
connections as you see fit.  The only trick is that you have to
exclusively allocate the buffers for all the data that comes before
something that you want to ACK.  This should not present a real
problem, and to the extent it does, you cannot work around it in
software anyway.

The assumption here is that your not going to have your 100 TCP
clients throwing data at you at full tilt and out of order, or losing
packets to boot and have tiny amounts of memory to play with.  But if
you do, then performance will degrade.  The solution in this case, is
a CPU upgrade or more memory.

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Sep 1993 15:20:33 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: NFS/TCP-IP dynamic buffer sizing? (techy)

In article <CDvus4.EM5@unix.portal.com> maxstrat@shell.portal.com (Peter van Cruyningen) writes:
>                               ...       In order to achieve the high
>performance (>400Mbps), window scaling with large windows (300-500K)
>appears to be necessary (recent thread in .tcp-ip).  Using large
>window sizes requires correspondingly large buffers.  However consider
>a server which is NFS mounted from multiple clients.  Each client
>maintains a permanent TCP connection to the server (recent thread in
>.nfs).  Therefore the server must maintain separate large buffers for
>each connection even though many may be idle.
>
>One possible solution to this is to support dynamic buffer sizing
>with allocation by all connections from a common pool (the available
>memory). ...

Look at any of the freely available BSD source implementations, paying
particular attention to anything having to do with the string "mbuf".  It
seems almost everyone who has ported 4.*BSD has fiddled with the mbuf
allocation code either a little or a lot, so there are plenty of opinions
on how to do it "right."  (My obsessions involve not using a fixed VM
window, and more than 2 sizes of mbuf to allow 1500 or 4K byte packets to
sit 1 buffer on systems with 4K pages without wasting 60% of memory, 
and mechanisms to shrink the mbuf pool when things get quiet.)

Note in BSD-style code that the empty input buffers are tied up in the
drivers, not the sockets.  More open connections do not imply more buffers
(except for the kludge of using mbufs for the data structures).

For several years, I have wondered about anyone who writes their own TCP
stack with at least looking at the freely available and redistributable
de facto standard implemenation, 4.*BSD.


Vernon Schryver    vjs@rhyolite.com

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 1993 22:08:12 GMT
From:      5652garsidej@vms.csd.mu.edu
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Resource

In article <748933041.AA01412@tdkt.kksys.com>, Mike.Dale@tdkt.kksys.com (Mike Dale) writes:
>I'm absolutely new to TCP/IP and am looking for a good (basic) yet comprehen-
>sive resource.
>
>Anyone have any suggestions? Any FAQ's floating around, books, etc.
>
>Mike                                               
>
>mike.dale@tdkt.kksys.com
>
> * Origin:  Command Line BBS - Mpls. MN - v.32b (612) 788-6685 (1:282/200)
>

If you get any responses, could you relay them to me?  I am also looking for
some good books.

I do have a good programming book called "Unix Network Programming", but I
unfortunately do not have it with me, so I cannot give you an author.  If you
want the author's name, mail me and I can scrounge it up for you.

Thanks,
jg
 

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Sep 1993 23:43:25 GMT
From:      crohrer@advtech.uswest.com ( Chris Rohrer)
To:        comp.protocols.tcp-ip
Subject:   IP over X.25

Has anyone implemented anything using X.25 to connect two separate IP sites
together?  I realize it's been done and that there is even an RFC that
touches on the subject; the same is true for ISO CLNP.  I'm more concerned
about the convergence function used to map IP into X.25.  When implementing
IP over X.25 for either temporary or long term  interconnection of two
nets, how do you indicate which protocol is being carried inside a given
X.25 packet?  

I mean, if you want to use IP, RARP and ARP simultaneously, what do you
do?  Over something like Ethernet, you have the type field to do this
"multiplexing" for you since the embedded protocols are not
self-indicating.  Do you define a header that sits at the front of every
X.25 data packet to indicate type?  Do you set up multiple parallel
virtual circuits, one for each protocol you want to carry and indicate in
each call request packet's protocol identifier field what the protocol for
that circuit will be?  That would require both ends to "remember" which
virtual circuit to use for each protocol.

Thanks for any info

Chris Rohrer


-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 1993 01:09:06 GMT
From:      Jerry@PeachNet.EDU (Jerry Segers)
To:        comp.sys.hp,comp.protocols.tcp-ip,comp.dcom.sys.wellfleet
Subject:   Re: HP Router ER Configuration

In article <carr-220993213044@macm407.esl.com>
carr@esl.com (John A. Carr) writes:

> I have an HP Router ER (5.74 software).  This is a small
> IP/appletalk/IPX/DECNet router with 2 ethernet ports and 2 serial ports. 
> It is somehow based on Wellfleet technology and the command interface seems
> very similar.  
> 
> I want to configure it as follows & don't understand how to do what I want.
> 
> I want to route between the two LAN ports but want to bridge IP between the
> second LAN port and the two serial WAN ports.  I want to route appletalk
> everywhere (I know how to do that).  I don't care about DECNet or IPX.
> 
> I see how to turn off IP routing, but it seems to turn it off altogether,
> not just between selected ports.
> 
> Can anyone give me a clue whether what I want to do is possible (&, if so,
> how to do it)?  And, what is the appropriate group for questions like this?

1 - I believe that HP is now selling a repainted Wellfleet router.

2 - I have too tried to take the action you are trying and according to
the information I recieved from Wellfleet support, this action is
impossible.

Their explanation went something like this:

There is a single packed manager that looks at every incoming packet no
matter what source.  If the packet type matches one of the protocols
loaded into the machine that packet is handed off to the software
routine if none of the packet types match then the packed is handed to
the bridging software.  Thus if the IP routing software is loaded (See
software load options on main menu) then any IP packet is handed to the
IP routing software.  Once the IP software has the packet it routes it
appropriately thus it is no nonger available to be handed to the
bridging software.

I don't claim to like this action just reporting how it seems to work
for me.

3 - I saw the article in comp.dcom.sys.wellfleet

**************************************
Jerry W. Segers
Director
Regents Telecommunications and Networking
P.O. Box 444
Marietta, GA   30061
Phone: 404-423-6860
Fax: 404-423-6868
Internet:Jerry@PeachNet.EDU
**************************************

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Sep 1993 17:30:27 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: Address resolution on non-broadcast networks

In article <KENW.93Sep23195557@skyler.arc.ab.ca> kenw@skyler.arc.ab.ca writes:

>  We are in the processess of setting up a 200-plus-subnet TCP/IP network 
>which will use X.25 as the wide-area carrier.  Unlike Ethernet networks,
>there appears to be absolutely no way for X.25-connected nodes (i.e.
>routers) to discover each other's MAC (X.121) addresses based on their IP
>addresses, as is done by the ARP protocol.

It's RIP, or other interior protocol for talking between routers isn't it? 
ARP is for hosts to talk to routers. 
Also MAC addresses are the station addresses on LAN subnetworks and 
X.121 addresses are the station addresses (DTEs) on 
X.25 subnetworks.  However, no matter, your requirement is valid.

>  I'm kinda blown away by this.  Sure, X.25 doesn't directly support
>broadcast-based ARP, but surely one of the routing protocols might
>distribute the MAC addresses.  Nope, looks like we're stuck maintaining the
>tables manually.  There's _gotta_ be a better way!

Yes, there is a better way. (please note I'm talking pure theory here
and in practice it may not work well.)

ISO 10589 (CLNS IS-IS routing protocol) is designed to overcome this
problem (of ISs discovering their neighbours' X.121 addresses when
connected via an X.25 subnetwork).  This protocol also works for IP.

See section 8.3  "(Use of ISO 10589 over) ISO 8208 Subnetworks".  
The drawback is that a dynamically established static circuit 
(ie an SVC) needs to be set up by "system management" to carry 
the routing traffic between your real known routers.
Note that Integrated IS-IS (RFC 1195) is a superset of ISO 10589 and works
the same for IP.  Several router manufacturers including DEC (DECNIS)
and Cisco support RFC 1195 Integrated IS-IS routing for IP.

For a big client of mine we have postulated the idea of setting up
these routing virtual circuits in the morning, then bringing 
them down in the evening, and relying on static entries in the routing 
tables to cope during the night.

Hope this helps.


-- 

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 

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 93 00:32:26
From:      hkarhune@plootu.Helsinki.FI (Heikki Karhunen)
To:        comp.sys.apollo,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: HELP: RJ45 to BNC conversion, how do I do it?


Try to find a gadget that connects to AUI port and has an RJ45 on the
other end. These most definitely exist, as I have several at work.

	HTK, the mad mad idiot...
--
/-----------------------------+-----------------------------------------\
| Heikki.Karhunen@helsinki.fi | There is always a job for a theoretical |
| hkarhune@cc.helsinki.fi     | physicist -- at least in theory.        |
\-----------------------------+-----------------------------------------/


-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 1993 20:23:13 GMT
From:      ahn@wfu.edu (Dave Ahn)
To:        comp.sys.apollo,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   HELP: RJ45 to BNC conversion, how do I do it?

Hi.

The situation is this:
Box A is an Apollo DN3500 w/ 3C505 board (AUI and BNC connectors).
Box B is a Gateway 2000 (DOS machine) w/ 3c509-TP (AUI and RJ45 connectors).
We are trying to connect the two machines together in a local ethernetwork.
What we have is an RJ45 cable that runs between the two machines, but there
is no way to connect the RJ45 cable to the Apollo w/ the BNC connector.
I thought there was a BNC to RJ45 converter, but local computer stores
have never heard of such a thing.

We are looking at a solution that will be minimal in costs, so we don't
need anything like a Starlet hub.

Thanks for your help in advance,
-dka
--
Dave Ahn                "When you were born, you cried and the world rejoiced.
ahn@wfunet.wfu.edu       Try to live your life so that
                         When you die, you will rejoice and the world will cry."
#include <stdisclaimer.h>					    - 1/2 jj^2

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 1993 11:33:29 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over X.25

In article <1993Sep25.234325.29720@advtech.uswest.com> crohrer@advtech.uswest.com ( Chris Rohrer) writes:
>Has anyone implemented anything using X.25 to connect two separate IP sites
>together?  I realize it's been done and that there is even an RFC that
>touches on the subject; the same is true for ISO CLNP.  I'm more concerned
>about the convergence function used to map IP into X.25.  When implementing
>IP over X.25 for either temporary or long term  interconnection of two
>nets, how do you indicate which protocol is being carried inside a given
>X.25 packet?  
>
    The first byte of the user data field in the Call Request packet
    is a 0xcc.  This indicates IP for either the CSNET or MILNET
    implementations of IP over X.25.

    There is a nice white paper from Perdue on running IP over X,25.
    IMHO it is more useful than the RFC's.  Most of the IP/X.25
    implementations I've seen that will interoperate are based on
    that white paper.  About the only technical flaw in it is that
    it doesn't seem to know about the leading 15th digit for "PSTN
    Select" in the X.121 addresses in SOME countries.

>I mean, if you want to use IP, RARP and ARP simultaneously, what do you
>do?  Over something like Ethernet, you have the type field to do this
>"multiplexing" for you since the embedded protocols are not
>self-indicating.  Do you define a header that sits at the front of every
>X.25 data packet to indicate type?  Do you set up multiple parallel
>virtual circuits, one for each protocol you want to carry and indicate in
>each call request packet's protocol identifier field what the protocol for
>that circuit will be?  That would require both ends to "remember" which
>virtual circuit to use for each protocol.
>
   You don't really "do ARP" over X.25....you really wouldn't want to
   be broadcasting all over any public Packet Network looking for
   IP stations anyway.  

   Most implementations have a setup parameter for any given pair of
   hosts which allows you to set up the initial number of VC's as well
   as the max number of VC's the IP layer will try to open.  

   Each data packet just carries (enough of) an IP header to allow
   data to be transferred to the IP endpoints on the connection.  You
   can have multiple IP connections on a single VC, but performance
   tends to be rather slow.....unless you have a T-1 speed X.25 link.


-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 93 08:57:05 MDT
From:      atheist@Feline.CAD.UCLA.EDU (Jim Small)
To:        comp.protocols.tcp-ip
Subject:   hardware question


I currently setting up two machines at my home to be 'nett-ed` together, this
way I can test my software without having to trudge off to work or school.
Some of my applications will be bandwidth intensive.  Is it possible to simply
plug in 2 ethernet cards and then use RG58 cabling with appropriate
terminations on the T-sections of each card without having to purchase a huge
repeater assembly?



-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 93 10:18:57 -0400
From:      glazer@ohstpy.mps.ohio-state.edu (JON GLAZER)
To:        rec.radio.amateur.packet,comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   KA9Q .. Need a particular mutant strain...;-)


I have now downloaded some 12 different versions of the KA9Q program and I
still cannot find the one that best suites my needs.  I am looking for support
for PPP as well as a version that is scriptable, can setup timed scripts ("AT
..." or whatever), and has a watchdog facility to shutdown after nnn seconds of
inactivity.

Does anyone know of a version such as this?  If so, where might I ftp it from?

Thanks!

Jon


-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 93 09:29:05 EST
From:      hari
To:        comp.protocols.tcp-ip
Subject:   Re: DCE vs. RPC 4.0

In article <1993Sep23.221111.4510@davbon.uucp> davek@davbon.uucp (Dave Kennedy) writes:
>I am using RPC for a project that has to run clients and servers on:
>
>   IBM AIX
>   Sun (probably Solaris 2.2)
>   MS Windows
>   OS/2
>
>For various internal political reasons the decision to use RPC is
>being slammed.  The main technical argument is that RPC does not provide
>multi-thread capability intrinsically.  I am not emotionally tied
>to RPC or DCE.  And I am willing, within the project's time constraints
>to use DCE.  In fact, having some assistance from DCE with threads
>would be nice.  My question is: 
>
>   Is DCE available on all the above platforms?
>   Is it reliable on all the above platforms?
>
>If you have information contrasting and comparing the two, please post
>the info or post a pointer to an ftp site.  Postscript, nroff, ASCII -
>heck just about anything in English would be fine.
>
>Thanks.
>-- 
>| Dave Kennedy        -  UUCP {gatech,emory}!wa4mei!igikpak!davbon!davek |
>| Home: 404-368-0331  -  Internet  wa4mei!igikpak!davek@mathcs.emory.edu |

As far as I know DCE is either available in production or in beta on
OS/2, AIX and Windows (from IBM). This might sound like a naive question
but since DCE services sit on top of RPC's, are you not essentially
using RPC's anyway. 
Hari

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 93 12:27:10 CST
From:      postma@inland.com
To:        comp.protocols.tcp-ip
Subject:   Seeking answers to Net Problem

I recently ran into small network problem, and I am wondering if someone can
help me understand what went wrong.

We have a 10base5 Ethernet network with a majority of Vitalink bridges with a
handfull of DEC bridges.  We have a DEC VAXStation 3100 Ultrix workstation
running Vitalink's WANManager.  The WanManager provides a graphical display of
the status of our vitalink and DEC Bridges.  The WanManager uses TCP/IP and
some proprietary Vitalink protocols to accomplish this task.  The WanManager
uses a bridge that is assigned as a "gateway" bridge.  I needed to move the 
WanManager gateway bridge to a different bridge (both bridges are Vitalink
TransLAN 350 at the same rev level).  

The original gateway bridge had an IP address of 156.144.60.2.  I assigned the 
"new" gateway bridge an address of 156.144.60.40.  Then I changed the Ultrix
Wanmanager software to use 156.144.60.40 as the address of its gateway bridge.
The system never came up.  I used an HP Lan analyser and saw no traffic between
the Vitalink Gateway bridge (156.144.60.40) and the Ultrix station.  I then
tried to ping the new bridge.  It failed the ping, than I ARP'd it and that was
successfull.  The old bridge could be ARP'd and Ping'd.  After alot of time
with Tech support, I finally decided to try a new IP address for the new
bridge.  I assigned the bridge the address of 156.144.60.100, then modified the
WanManager software to look for that address.  At this point the system came on
line and has been working fine since.

Now what I don't understand is what really was wrong?  I spent a lot of time on
this and did not come away learning anything.  The only other thing is that
156.144.60.40 used to be assigned to a cisco router we were testing, but the
router is gone and has been for at least a week.  Any answers or help would be
greatly appreciated.

BRP
postma@inland.com


-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 1993 15:37:01 -0500
From:      robbh@cs.utexas.edu (Robert Raymond Hunziker)
To:        comp.protocols.tcp-ip
Subject:   Client/Server, RPC


Can anyone help me out?  I'm doing some research on the client/server
design model, and how it relates to loosely-coupled distributed systems and
RPC.  My main problem is a lack of information (other than textbooks).
Can anyone point me in the right direction?  Is this a good newsgroup for this
type of discussion?

Thanks,
Robb Hunziker
robbh@cs.utexas.edu


-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 1993 08:57:34 GMT
From:      antonis@intranet.gr (Antonis Kyriazis)
To:        comp.protocols.tcp-ip
Subject:   Re: HP Router ER Configuration

WIth my NetBuildersII it's also impossible to get routed and bridged the
same protocol.


+-------------------------------------------------------------------+
|     Antonis Kyriazis                                              |
| Networks & Communications       e-mail: antonis@intranet.gr       |
| INTRACOM sa                                                       |
| 19.5 km Marcopoulo Ave.          fax:   +30-1- 66 44 379          |
| Peania 190 02                           +30-1- 66 43 718          |
| GREECE                          phone:  +30-1- 66 44 961-5        |
|                                         +30-1- 88 43 715          |
| "The expressed opinions are of my own"   + - MACEDONIA IS GREEK - +
+-------------------------------------------------------------------+


-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Sep 1993 13:03:19 EDT
From:      Ross Druker <RS0VRD@rohvm1.rohmhaas.com>
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Named, and the FORWARDERS line (help!)

We are running with RS/6000s as nameservers on AIX 3.2.4 and 3.2.3 and are
having some problems.

In subnet A, our NAMED.BOOT file includes two nameservers in our
Root domain, via the NAMED.CACHE file.

If we do *NOT* have a FORWARDERS line at the end of the NAMED.BOOT file
referencing the same two nameservers, all queries for hosts *outside*
subnet A fail.

If we put in the FORWARDERS line, all is well.  According to O'Reilly's
Managing TCP/IP book, the forwarders line is not required; the NAMED.CACHE
entries should handle requests *not* in subnet A by pointing the local server
to the server(s) at the root level of our domain.

Is this an AIXism?  Any help would be appreciated.  Thanks.

--
Ross Druker
Rohm and Haas. Co.
RDruker@RohmHaas.com

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 1993 16:10:10 -0400
From:      Mike O'Connor <mjo@msen.com>
To:        comp.protocols.tcp-ip
Subject:   Re: DNS & /etc/hosts usage

In article <2218@swuts.sbc.com> root@swuts.sbc.com (System
Administrator) writes:

:Does anyone know what the official RFC word is on how this should work?
:It seems to me that there ought to be some official standard on how DNS
:and the /etc/hosts files should or should not interact together.  As for
:my own opinion, using DNS, then /etc/hosts seems like the ideal situation.

I much prefer solutions where I am given the choice of order of name
resolution, as DEC and Sun/Solaris do.  I cannot predict when I might
need one sort of ordering scheme or the the other -- it's far from a
perfect world out there, by any means.  Your DNS may be done by total
idiots centrally, with your forward maps owned by a different bunch of
people than your reverse maps, and you may have to run an /etc/hosts
table for your sanity.  There could be lots of policy situations which
lend themselves towards the technical solution of "use hosts first".

-- 
 Mike O'Connor
 <mjo@msen.com>

"I keep forgetting that rules are only for little nice people."  -Calvin

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Sep 1993 10:10:19 GMT
From:      jordan@hursley.ibm.com (Rob Jordan)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over X.25

As the previous poster indicated, typically all IP traffic between two hosts
is carried over a single X.25 virtual circuit. As you suggest, the protocol
indicator in the Call Request packet is used to indicate that the VC is to 
be used for carrying IP. Both ends have to remember this.

IP over X.25 implementations typically don't handle protocols which require 
broadcasts, e.g. ARP. Instead a fixed translation table is required to map
IP adresses to X.25 NUAs. This isn't too bad so long as the the number of 
hosts interconnected over X.25 is not huge.

All this is explained in RFC877, and in its successor RFC1356.

Rob
-- 
_______________________________________________________________________________
Rob Jordan, DirectTalk/6000 Development, MP 183, Hursley Park, Winchester, UK
Telephone: +44 962 844433 x 5505        Internet:  jordan@vnet.ibm.com 
Fax:       +44 962 849268               IBM IPnet: jordan@b52.hursley.ibm.com

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Sep 1993 11:02:17 GMT
From:      cc_paul@rcvie.co.at (Wolf Paul)
To:        comp.protocols.tcp-ip
Subject:   Bizarre Network Problem

During the past few months, and with increasing frequency, we are 
experiencing a strange problem in our network of about 100 SUNs, 70
PCs and a cluster of half a dozen VAXen.

We have tried to diagnose it with the aid of various network analyzer
machines and utilities, but so far to no avail.

Here is a description

For a few seconds, varying from one to thirty, the network simply
locks up. One of the SUNs stops in its tracks, one of the VAXen
usually crashes and reboots if the lock-up lasts longer than about
five seconds. The bulk of the SUN workstations also seem to lock up,
since they are booted and rooted via the network; the PCs (running
PC/TCP from FTP Software) get real sluggish in their response,
especially inside MS Windows, or report that they couldn't find the
nameserver, etc.

The LAN Analyzer we have running also locks up and is thus not able to
tell us WHAT is going on on the network.

Does anyone have any ideas, suggestions where we could start looking,
or such like?

Please reply by e-mail, if there are any generally useful responses I
will summarize to the group.

Thanks,

Wolf
-- 
         V           Wolf N. Paul, Computer Center         wnp@rcvie.co.at
+-----------------+  Alcatel Austria Research Center  +43-1-391621-122 (w)
|  A L C A T E L  |  Ruthnergasse 1-7                   +43-1-391452 (fax)
+-----------------+  A-1210 Vienna-Austria/Europe        +43-1-2246913 (h)

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 1993 12:16:51 GMT
From:      H.J.M.intVeen@telecom.ptt.nl (Herman in 't veen)
To:        comp.protocols.tcp-ip
Subject:   Products for document distribution?

I am trying to find out what products exist to aid in the distribution of documents (file transfer)
with (some of) the following features:
- based on ((defacto) standards (support of more than one standard desired)
- management facilities
- accounting
- security

Could anyone who has any information about such a product mail me this information, or pass
me the name of the company (preferably with a contact).
Lots of thanks in advance!
                                         Herman

Herman in 't Veen
H.J.M.intVeen@telecom.ptt.nl

-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 1993 20:21:08 -0400
From:      bb31351@bingsuns.cc.binghamton.edu (Rakesh Shetty)
To:        comp.sys.novell,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   TCP/IP sockets bind/close  question ?


Hello,

I am having a peculiar problem when attemptimg to use sockets (SUN OS 4.1.1).
Here is the socket creation in a server program :


bzero((char *)&distributor_server,sizeof(distributor_server));
 distributor_server.sin_family=AF_INET;
 distributor_server.sin_addr.s_addr = INADDR_ANY;
 distributor_server.sin_port=    (u_short)DISTRIBUTOR_PORT ;
 if (bind(sock,(struct sockaddr *)&distributor_server,
          sizeof(distributor_server)) < 0)
  {
    printf("cant bind server  local addr. \n");
    perror("dist server bind");
    exit(1);
  }

where:
#define DISTRIBUTOR_PORT 5500

Now the above socket is closed successfully when the program ends:
if (close(sock)==-1)  {perror("dist. sock close failed:");}

The program terminates normally. However after certain runs I get a message:

cant bind server  local addr.
server address in use.

Although strictly speaking one must be able to use the port immediately,
I guess the system needs some time to retrieve the port numbers for 
reuse. However I dont seem to able to place a time duration on this.
It gets quite irritating when i have to debug with different clients and the
server keeps giving the above error message although it terminated
normally on the last run.

I have a similar problem in another program where I bind a socket
with the broadcast option turned on. This too at times gives the mesg.

address already in use: unable to bind.

ALTHOUGH on the previous run the program  terminated normally ,
successfully closing the socket.

Any pointers or suggestions are welcome.

Thanx,
Rakesh
email:rshetty@cs.binghamton.edu

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Sep 1993 13:52:39 GMT
From:      rr@netrix.com
To:        comp.protocols.tcp-ip
Subject:   Re: Diff between NIS and DNS(Attn: David McCann)

 In your posting you write:
>Hi,
>	First I'd like to apologise for the somewhat indescriminate way I've
>distributed this post.  Second because of this can I ask that all replies
 are
>e-mailed to me.  Should anyone else be interested, mail me too and I'll
 let you
>have a copy of any useful info I collect.  Alternatively I could post a
 summry
>back here.
>
>	Right, the real problem.
>
>	I need to know the difference between RARP, DNS, NIS, and NFS.
>
>My understanding so far is that :-
>
>	RARP (using the rarpd daemon) listens for RARP request on the Ethernet
>and repsonds to them with the appropriate IP address from /etc/hosts.
>
>	DNS allows automatic finding of IP addresses from server names using a
>named server.
>
>	NIS does much the same as DNS  (although it can ues DNS too.  Don't
>understand this quite)
>
>	NFS allows remote access to files from other hosts.
>
>Finally, I know that these systems all exist in SunOS 4.1 and I get the
 feeling
>that they can all run side by side.  What about all the other UNIX
 systems and
>then all the other TCP/IP systems in the world, how do they fit in ?
>
>	The reason I'm asking all this is that I'm trying to sort out the
>hostnaming systems on a small network (not on the Internet.)  I should
 perhaps
>point out that this has ABSOULUTELY NOTHING to do the with the network at
>Brunel University (form where I'm posting) which is not in any way under
 my
>control.
>
>	Many thanks for _anything_ you can suggest,
>
>			David McCann
>
>
>

I could clearly describe the difference between NIS and DNS.

Both of them help in obtaining host information (host to IP address
mapping) . DNS uses the Berkeley Internet Domain Names (BIND) program and
was written for names service for the entire internet whereas NIS was
written for SUN systems by SUN.

NIS also helps in distributing other databases and information like
/etc/passwd, /etc/groups, /etc/services etc whereas DNS only helps in
hosts information dissemination. 

NIS is used for your own network whereas DNS is used both by your network
and the entire internet. 

If you are not connected to the Internet and if you have SUNs and PCs
running PC-NFS, NIS is highly recommended. You dont need to run DNS.

NFS is used for a totally different purpose ie., for mounting one system
on another and see remote file systems as if they were local to you. 

-Ramesh.

Ramesh Radhakrishnan, LAN Administrator, Netrix Corporation, Herndon, VA.



-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Sep 1993 14:13:54 GMT
From:      root@foobar.hanse.de (Jens Stark)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for TANDEM CLX series ???


Hi,

I heard about a package which allows to use a vt100 via telnet to
work as a page mode terminal.
Has anybody heard about that thing ? Pricing ? Who sells it ??

Any help appreciated,
              Jens


-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Sep 1993 15:15:34 GMT
From:      hanna@world.std.com (Stephen R Hanna)
To:        comp.protocols.tcp-ip
Subject:   UDP & TCP port numbers

I am developing several client-server applications using UDP & TCP. As
usual, the server will listen on a certain port and answer requests
sent by the clients. The issue is how the clients figure out which
port number to send their requests to. While I will allow the user to
select the port number explicitly, I don't want them to have to do so.
As I see it, there are three solutions:

1) Get a well-known port number assigned to each of my applications.

2) Get a single well-known port number assigned to my company and
create a protocol similar to tcpmux (RFC 1078) which directs clients
to the appropriate dynamically allocated port number for their
favorite application.

3) Use an existing well-known port number which provides a similar mux
capability. Port number 1 (tcpmux) or port number 111 (sunrpc) could
serve this purpose. On machines which don't provide system support for
these protocols, I can create my own implementation.

Solution 1 is simple, but well-known port numbers are a scarce
resource and it requires several. Also, acquiring a well-known port
number might take a while.

Solution 2 still requires a single well-known port number for my
company's exclusive use. It seems to be popular, since RFC 1340
(Assigned Numbers) lists several other companies with special
well-known mux numbers (3com-tsmux, xyplex-mux, and genrad-mux).

Solution 3 doesn't require any additional well-known ports, so it
seems the most sustainable solution. Unfortunately, tcpmux is
classified as Historic and Not Recommended. sunrpc is a bit more
intricate than what I need, but could be made to serve. There's
potential for problems on machines that don't implement sunrpc if I
implement it and someone else tries the same trick, but that's not too
bad.

What do other people do in this situation? Which of these solutions is
better? Are there others? Have I missed an obvious solution in one of
the RFCs?

Thanks,

Steve Hanna
hanna@world.std.com

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 93 20:22:20 CDT
From:      kmoch@whscdp.whs.edu
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Communication Server?

We are planning to extend our network courtesy of a grant from Ameritech.
Part of this involves modem access to something they are developing called
the Learning Village.  Their first suggestion involved purchasing 5 micros
with modems and using these to call out.  Since we already have a network,
I thought that putting these modems on a communication server would allow
numerous machines throughout our school access to the modems.

Here is where I need help.  A Novell marketer suggested an IPX-based
communication server which would require that anything dealing with it
would have to support IPX.  We have a bunch of Macs on our ethernet connected
via a FastPath gateway (these Macs are actually connected via Phonenet which is
a clone of AppleTalk (Localtalk?)) Their suggestion was to purchase a card 
(actually 2 or 3 cards) which contain 2 386 cpus with memory
which would be connected to the modem server (I believe).
Essentially, a Mac would have to allocate one of these micros and then
be able to access the comm server.  This seems to be a costly and 
possibly difficult system to use, though it would allow a user to call
into the modems, allocate one of these 386s and essentially be part of
the Novell net.

Instead of this Novell-based net, I wonder if it might be appropriate to
think about a comm server which would support TCP/IP and then make
a micro talk to it via IP.  We are also getting a Dynix library system
which is Unix-based and this has TCP/IP "native."  Does this make sense
and if so, can you suggest how we would do this and perhaps even some
equipment we should consider?

I should also indicate that the ethernet is currently "based" on a VAX/VMS
machine which supports Decnet, TCP/IP (via UCX), LAT, and AppleTalk through
Pathworks.  Sometime next semester we will also connect a Unix box to
support a library automation system called Dynix.  This variety of equipment
on the net suggests a more general solution than the Novell one for allowing
modem access for comoputers.  In addition, if possible, we would like these
modems to be call-in modems which might allow a Mac user to connect to 
the AppleTalk net, or (as we currently do) act as a terminal to the VAX.  It
would also be nice for a DOS user to be able to connect as a Netware user.

Confused?  Maybe I want too much - at least I would like as many different
machines to be able to allocate modems and call out.

Thanks for your time.

Joe

--
Joe Kmoch                                   Washington High School
kmoch@whscdp.whs.edu                        2525 N. Sherman Blvd
(414) 449-2765 (office)                     Milwaukee, WI  53210
(414) 444-9250 (fax)                        (414) 444-9760 (gen school phone)
-- 
--
Joe Kmoch                                   Washington High School
kmoch@whscdp.whs.edu                        2525 N. Sherman Blvd
(414) 449-2765 (office)                     Milwaukee, WI  53210
(414) 444-9250 (fax)                        (414) 444-9760 (gen school phone)

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Sep 1993 15:40:36 GMT
From:      philn@ims.com (Phil Neff)
To:        comp.protocols.tcp-ip
Subject:   Stevens Source Code

---

Once upon a time, it was possible to get the code for all of Stevens' example
programs (i.e., UNIX NETWORK PROGRAMMING By W. Richard Stevens) from the net.
Anyone out there know were to find the code?

-------------------------------------------------------------------------------
Phillip R. Neff                | Integrated Measurement Systems, Inc.
Systems Application Engineer   | 9525 S.W. Gemini Drive
E-mail:   philn@ims.com        | Beaverton, OR 97005
Phone:    (503) 626-7117       |
FAX:      (503) 644-6969       | (A Subsidiary of Cadence Design Systems, Inc.)
-------------------------------------------------------------------------------




-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 93 15:51:02 GMT
From:      root@swuts.sbc.com (System Administrator)
To:        comp.protocols.tcp-ip
Subject:   DNS & /etc/hosts usage

Newsgroups: comp.protocols.tcp-ip
Subject: DNS & /etc/hosts files ???
Summary: 
Followup-To: 
Distribution: 
Organization: Southwestern Bell Telephone Company
Keywords: 

I have been doing some testing with various UNIX platforms concerning the
use of domain name service resolving & /etc/hosts resolving.  I have found
that some platforms first check the domain name server, and if the hostname
is not found, looks in the local /etc/hosts file for the name.  Other
platforms use only the DNS resolver for hostname lookup, never resorting
to the /etc/hosts file in cases where the name is not located in the DNS
resolver.  Specifically, my tests show HP-UX, Pyramind, & Interactive
UNIX as NOT using the /etc/hosts file in conjunction with DNS.  Amdahl UTS,
SCO, AT&T/NCR StarServer, and IBM OS/2 appear to use the /etc/hosts file
along with the DNS system.

Does anyone know what the official RFC word is on how this should work?
It seems to me that there ought to be some official standard on how DNS
and the /etc/hosts files should or should not interact together.  As for
my own opinion, using DNS, then /etc/hosts seems like the ideal situation.
This would allow for local systems to configure various IP addressed
entities such as printers, workstations, etc. which would not be known by
other systems, even if they all used the same DNS resolver system.

Any information, opinions, etc. on this topic would be greatly appreciated.

Thanks,
--
================================================================================
  Blair Porter - Systems Analyst		One Bell Center  23-L-1
  System Support Division			St. Louis, MO  63101
  Information Services				Work: (314) 235-3419
  Southwestern Bell Telephone Company		FAX:  (314) 235-1397
  E-mail: BP3434@swrunr.sbc.com
	THE RACE GOES TO THOSE WHO KEEP ON RUNNING...
================================================================================

-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Sep 1993 15:56:02 GMT
From:      Andy Malis <malis_a@timeplex.com>
To:        comp.protocols.tcp-ip
Subject:   Re: IP over X.25

In article <1993Sep25.234325.29720@advtech.uswest.com> Chris Rohrer,
crohrer@advtech.uswest.com writes:
> When implementing IP over X.25 for either temporary or long term 
> interconnection of two nets, how do you indicate which protocol is being
> carried inside a given X.25 packet? ... I mean, if you want to use IP,
> RARP and ARP simultaneously, what do you do?  

This convergence function is defined in RFC 1356, !Multiprotocol
Interconnect on X.25 and ISDN in the Packet Mode!.  [Disclaimer: I!m one
of the authors.]  Let me know if you have any further questions once
you!ve read the RFC.

Regards,
Andy
_______________________________________________________________________
____
Andrew G. Malis   malis_a@timeplex.com   -or-  
malis@maelstrom.timeplex.com
Ascom Timeplex    289 Great Rd., Acton MA 01720  USA         +1 508
266-4522

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Sep 1993 16:45:34 GMT
From:      dz@bsun3.zfe.siemens.de (Dietmar Zaig)
To:        comp.protocols.tcp-ip
Subject:   (HELP) TCP/IP, UDP sources


-- 

Does anybody know where I can get the source code of TCP/IP and UDP for 
the PC?

Thanks for any info!



++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+  Dietmar Zaig                                                  	 +
+                                                                	 +
+  Siemens AG                                           	 	 +
+  ZFE ST SN 61                		Phone: +49 89-636-49479 	 +
+  Otto Hahn Ring 6             	Fax:   +49 89-636-2393           +
+  8000 Munich 83, Germany      	Email: dz@bsun11.zfe.siemens.de  +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 1993 17:06:49 GMT
From:      sastr_a@hathor.cs.odu.edu (Ravi Sastry)
To:        comp.protocols.tcp-ip,comp.sys.sun.apps,alt.sys.sun
Subject:   How to order SUN RPC book (Springer-Verlag)?


	I would like to order "The Art of Distributed Applications"
	by John R Corbin.  Is it possible to order Springer Verlag
	books by e-mail. I would appreciate if you can give me 
	info on Ordering Springer Verlag books (either 800 number
	or e-mail address).

	Thank you.
	Ravi

p.s.  In case someone has this book for sale PLEASE let me know.
	

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 93 18:34:06 GMT
From:      guy@Auspex.COM (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: Diff between NIS and DNS(Attn: David McCann)

>Both of them help in obtaining host information (host to IP address
>mapping) . DNS uses the Berkeley Internet Domain Names (BIND) program and
>was written for names service for the entire internet whereas NIS was
>written for SUN systems by SUN.

Note that:

	1) NIS was not written by any company named "SUN"; it was,
	   instead, written by a company named "Sun Microsystems" (it's
	   *not* a set of initials when used in their name - in
	   particular, it doesn't stand for "Stanford University
	   Network" when used in their name);

	2) NIS is available on systems not running SunOS - it's part of
	   their ONC/NFS software, and some adopters of NFS have also
	   adopted NIS.

(It was originally called Yellow Pages before British Telecom informed
Sun that Yellow Pages was, at least in the UK, a British Telecom
trademark.)

>NIS also helps in distributing other databases and information like
>/etc/passwd, /etc/groups, /etc/services etc whereas DNS only helps in
>hosts information dissemination. 

There exists a facility called Hesiod, developed at MIT's Project
Athena, that uses DNS to serve up information other than host names and
addresses; however, I don't know which systems use it.  (DEC, I think,
offers it in some form, perhaps for systems other than DEC systems.) 
It's probably not as common as NIS, though.

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Sep 1993 18:58:24 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: hardware question

In article <1993Sep27.085706.1101@cc.usu.edu> atheist@Feline.CAD.UCLA.EDU writes:

>
>I currently setting up two machines at my home to be 'nett-ed` together, this
>way I can test my software without having to trudge off to work or school.
>Some of my applications will be bandwidth intensive.  Is it possible to simply
>plug in 2 ethernet cards and then use RG58 cabling with appropriate
>terminations on the T-sections of each card without having to purchase a huge
>repeater assembly?

Yes, that's just what I've got here.  I use it as test bed for various
new PC software packages etc..  Both the comms protocols, eg. NetBIOS, 
TCP/IP and applications.

Careful on cable length.  It's supposed to be no more than 185 metres
 between 10base2 stations.  But I've only got about 20 metres and most 
of that is to negotiate the doorway.

(My 2 PCs are on adjacent desks  -- I can reach the keyboard of one from
the other.  Trouble is, I can't see the screen too well.... old age.)

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

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 93 19:07:27 GMT
From:      herberts@enstb.enst-bretagne.fr (HERBERTS Mathias)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP programming question

I have a simple question for sockets guru ...

I want to program a server , if I run it on my machine , let say it is called gauss ,
on port 1068 for example , if people want to connect to it they have to telnet to gauss 1068 and I would like to make my server available at a higher level , that is all our
machines here at school are under domain enst-bretagne.fr so instead of having to type
telnet gauss.enst-bretagne.fr 1068 I would like to make my server accessible through telnet enstb.enst-bretagne.fr where enstb is the server for the previously mentionned machine gauss.
How do I do that ?


Thanks for your answers.


---
 Mathias HERBERTS  Telecom Bretagne  BP 832  29285 BREST Cedex  --  98.00.17.01
 Email: herberts@enstb.enst-bretagne.fr				Chambre: 116 I7

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 1993 02:21:45 -0400
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS & /etc/hosts usage

In article <2218@swuts.sbc.com> root@swuts.sbc.com (System Administrator) writes:
>I have been doing some testing with various UNIX platforms concerning the
>use of domain name service resolving & /etc/hosts resolving.  I have found
>that some platforms first check the domain name server, and if the hostname
>is not found, looks in the local /etc/hosts file for the name.  Other
>platforms use only the DNS resolver for hostname lookup, never resorting
>to the /etc/hosts file in cases where the name is not located in the DNS
>resolver.

And some have configuration files that permit the administrator to specify
the order.  Also, don't forget that some systems also use NIS, Hesiod, or
some other local network database server.

>Does anyone know what the official RFC word is on how this should work?
>It seems to me that there ought to be some official standard on how DNS
>and the /etc/hosts files should or should not interact together.

Why?  The RFCs are concerned with inter-system protocols.  The choice of
*when* to use any particular protocol is purely a local matter, and not in
the domain of the network protocol designers.  The DNS RFC's say, "If you
want to find out domain information from a name server, this is how you do
it."  They don't say what would cause you to want to query a name server,
though.

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Sep 1993 19:43:31 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Stevens Source Code

>Once upon a time, it was possible to get the code for all of Stevens' example
>programs (i.e., UNIX NETWORK PROGRAMMING By W. Richard Stevens) from the net.
>Anyone out there know were to find the code?

Use anonymous FTP to ftp.uu.net and get the file
published/books/stevens.netprog.tar.Z.  The current
errata is also there in stevens.netprog.errata.Z.

	Rich Stevens  (rstevens@noao.edu)

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Sep 1993 20:32:30 GMT
From:      jimr@world.std.com (James A Robinson)
To:        comp.protocols.tcp-ip
Subject:   Is there a 5 hub limit on UTP tcp/ip?

Sorry for what is probably a very newbie question, but if a network
has five hubs (four UTP hubs and a UTP/BNC repeater) will it mean that
the computers on hub one will not be able to talk to the computers on
hub five because the signal cannot go over five hub hops?

Thanks for any info, and for being understanding. :-)

Jim
jimr@world.std.com


-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Sep 1993 20:51:49 GMT
From:      Walter E. Gillett <walter@mathworks.com>
To:        comp.protocols.tcp-ip,comp.sys.sun.apps,alt.sys.sun
Subject:   Re: How to order SUN RPC book (Springer-Verlag)?

>How to order SUN RPC book (Springer-Verlag)?

Try quanbook@world.std.com (Quantum Books, Cambridge, MA, (617) 494-5042).
They are the only bookstore I know of that takes orders by email (O'Reilly
also does this, but they are a publisher, not a bookstore, and will only
sell you books that they publish).  I have no relationship with them other
than being a satisfied customer.

Walter E. Gillett 
The MathWorks, Inc.
walter@mathworks.com
(508) 653-1415

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 1993 10:14:38 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over X.25

In a prior posting, I mentioned a white paper on running TCP/IP
over X.25.  Since I've gotten several E-mails, I'll just post here.

NOTE that this is more for hosts doing such, I'd imagine the router
vendors have much better ideas on how to do router-router traffic.

     "Session 6A:  The Computer Science Network (CSNET)"
      Chair:  Peter J. Denning
      Perdue University

      Copyright: Association for Computing Machinery

      1983 ACM 0-89791-089-3/83/0300-0138  
      It was $0.75

      The copyright gives permission to copy w/o fee as long as
      it is not for commercial use.

There was also the Comer and Korb paper "CSNET Protocol Software: the
 IP to X.25 Interface" from that same month and year of ACM.  I don't
 have the number.



-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 1993 23:19:52 GMT
From:      tomw@kalpana.com (Tom Walsh)
To:        comp.protocols.tcp-ip
Subject:   Re: Information about rmon

Can anyone point me in the right direction for finding information or source code for rmon??

---
----------*----------*----------*---------*---------*---------*
Tom Walsh

"To Internet or not to Internet, That is the question"

			( 408 ) 749-1600 ext 153
			( 408 ) 749-1690 ( FAX )
			internet: tomw@kalpana.com
---------*----------*----------*---------*---------*---------*



-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Sep 1993 23:32:31 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: Residence Hall Networking

In article <AEJ.93Sep23121242@manyjars.WPI.EDU> aej@manyjars.WPI.EDU (Allan E Johannesen) writes:
>Wiring the student residence halls for computer networking (and cable
>and phones) is finally being contemplated on our campus.  We would
>like to offer Ethernet connection or serial connections for those who
>don't want to invest in Ethernet cards (purchased or leased from the
>college, or whatever).

  I'd recommend running Class 5 twisted-pair to each room using a star
topology to a wiring closet.  This will support Ethernet today using
commercial Ethernet hubs.  It will also be upgradable to FDDI over
twisted-pair or ATM over twisted-pair later on.  Ethernet cards are
cheap enough ($99) now that I wouldn't even bother with the serial
connections.

>I would appreciate recomendations on media, on the network infra-
>structure we should establish, any war stories, or even good
>experiences with an effort like this (if there are any).  If there is
>some mailing list or other newsgroup to try, I'd like to hear about
>that, too.

I know that other schools have done similar things.  It would probably
be worth asking around academic computing circles.  U.Va. did this in
some dorms built about 4-5 years ago and it seems to have worked quite
well from a technical point of view.

Ran
atkinson@itd.nrl.navy.mil


-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Sep 1993 00:04:01 GMT
From:      cricket@hpuecoz.nsr.hp.com (Cricket Liu)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS & /etc/hosts usage

System Administrator (root@swuts.sbc.com) wrote:
: Does anyone know what the official RFC word is on how this should work?
: It seems to me that there ought to be some official standard on how DNS
: and the /etc/hosts files should or should not interact together.  As for
: my own opinion, using DNS, then /etc/hosts seems like the ideal situation.
: This would allow for local systems to configure various IP addressed
: entities such as printers, workstations, etc. which would not be known by
: other systems, even if they all used the same DNS resolver system.

There isn't an RFC that dictates this behavior.  BSD UNIX set the standard
with their resolver implementation, which does not fall back to /etc/hosts
if more than one name server is listed in /etc/resolv.conf.  The HP-UX
resolver is based on this code and doesn't fall back.  Other vendors have
added the ability to fall back, and some have made resolution order
completely configurable (e.g., Sun, DEC and SGI).

Note that HP-UX and maybe some of the others you mentioned will fall back
if only one name server is listed and each attempt to send queries to the
name server results in an error (as opposed to a timeout).

--
cricket

cricket@hp.com / Hewlett-Packard Professional Services / Englewood, CO

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Sep 1993 00:24:30 GMT
From:      waltb@feenix.metronet.com (Walt Beaulieu)
To:        comp.protocols.tcp-ip
Subject:   TR Lanalyzer for Sale

I won a full Token Ring Lanalyzer.(Retail $12,000) from NCC 
corporation at the Interop show. Since I am an individual I would
just as soon sell it for a discounted price. Includes a full year
Warranty from last week etc etc. If interested:

Email me at waltb@feenix.metronet.com

Phone is (817)963-9115

Thanks

Walt

-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 1993 01:19:56 GMT
From:      cceleecm@leonis.nus.sg (Mr. Lee Chiap Meng)
To:        comp.protocols.tcp-ip
Subject:   Enterprise NM tools evaluation


Hi out there, 

I am currently doing a comparison of the features between the major
Enterprise Network Management tools that are available e.g Openview,
Sunnet, DecMcc, Netview, etc.

I have some experience with DecMcc and have read some reviews and 
white paper on the various tools.

However I would like to hear from users out there that have experiences
in the other tools or may have done some comparative studies on the
pro and cons of the various tools.

Pls e-mail all replies to cceleecm@leonis.nus.sg. 
 
I will summarize and post to the net

Thanks and regards,
Chiap Meng Lee 
           ---

-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 1993 02:08:55 GMT
From:      mwh45279@uxa.cso.uiuc.edu (Marc Henkel)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: Residence Hall Networking

In article <CE1DE9.4M@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
>In article <AEJ.93Sep23121242@manyjars.WPI.EDU> aej@manyjars.WPI.EDU (Allan E Johannesen) writes:
>>Wiring the student residence halls for computer networking (and cable
>>and phones) is finally being contemplated on our campus.  We would
>>like to offer Ethernet connection or serial connections for those who
>>don't want to invest in Ethernet cards (purchased or leased from the
>>college, or whatever).
>
>  I'd recommend running Class 5 twisted-pair to each room using a star
>topology to a wiring closet.  This will support Ethernet today using
>commercial Ethernet hubs.  It will also be upgradable to FDDI over
>twisted-pair or ATM over twisted-pair later on.  Ethernet cards are
>cheap enough ($99) now that I wouldn't even bother with the serial
>connections.

Since our residence halls already had the twisted pair installed, we
didn't have a choice of media, but twisted pair does seem to be the
best in a res. hall environment.  For the pilot project this year, we
offered to loan cards to students.  They were external Xircom adaptors
for DOS PCs and Asante SCSI adaptors for Macintoshes.  It is uncertain
whether this practice will continue if and when other halls are brought
online.  Also, about 15% of the students did buy their own cards.

>
>>I would appreciate recomendations on media, on the network infra-
>>structure we should establish, any war stories, or even good
>>experiences with an effort like this (if there are any).  If there is
>>some mailing list or other newsgroup to try, I'd like to hear about
>>that, too.
>
>I know that other schools have done similar things.  It would probably
>be worth asking around academic computing circles.  U.Va. did this in
>some dorms built about 4-5 years ago and it seems to have worked quite
>well from a technical point of view.
>
>Ran
>atkinson@itd.nrl.navy.mil
>

So far, things have gone pretty well considering this is a pilot project.
We are using Ungermann-Bass hubs as the concentrators for all the twisted
pair.  They offer anti-eavesdropping and anti-intrusion to prevent packet
sniffing, etc. so a very secure environment can be given to the residents.
As far as IP management goes, we use the bootp of Clarkson Telnet for DOS
PCs, and WinQVT along with a little bootp utility for MS Windows PC users.
Mac users use NCSA Telnet, which also supports bootp.  Many residents have
also successfully set up Linux and OS/2 as another for an even wider
variety of operating systems.

Right now, our biggest challenge is deciding what level of service we should
offer to residents.  In these past few weeks, two other student employees
and myself have set up hundreds of computers not only with network connections
but also with a connection to our local LAN Manager network so that users
can print to the laser printer queue in the local lab.  Some of these installs
have run into multi-hour long troubleshooting sessions.  "All PCs are the 
same" is the biggest crock I have ever heard.  Add in some very novice
users with some strange machine configurations, and you have one heck of
a nightmare.  The worst is over, though, and most of the service requests
are to fix minor problems (memory conflicts, etc.).  When do we tell the 
student "There's nothing we can do"?  Well, it hasn't happened yet, but it
is something we will be deciding after this pilot is done. Hope this helps...

-----
Marc Henkel   mwh@uiuc.edu       University of Illinois - Champaign-Urbana
ISRnet Coordinator
Residential Student Computing                    

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Sep 93 03:18:50 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   SunOS socket weirdity/question

	I'm having a weird problem. I am in the process of writing a
telnet server, and the following program exhibits _weird_ (to me)
behaviour. After the fork, the child closes the network socket (it
communicates with the parent though pipes). When the parent exits, it
(implicitly) should close the network socket (I just call exit, but
the OS should take care of this, no?). However the network socket
stays active and accepting connections, even after the parent is dead.
Only if I kill the child does all become normal. I compile the
program, type a.out 3333, type telnet localhost 3333, close the telnet
connection, and port 3333 is still active. But the parent is dead
(exit()), and the child had closed the network socket!

	Please tell me what is going on, it is getting to be quite a
mystery. Is it because I haven't set SO_LINGER or some other socket
option?

	Sorry about the length, but I am afraid if I cut it, I'll
remove a critical (buggy) section of code. Thanks in advance.

-------

#include <unistd.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/fcntl.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <errno.h>

#ifndef BUFSIZ
#warning "BUFSIZ not set in standard includes, defaulting to 1024."
#define BUFSIZ 1024
#endif /* BUFSIZ */

#define BACKLOG 5 /* This is arbitrary, but it is the SunOS maximum (?) */

#define selwidth 32 /* Temporary kludge, should use ulimit() */

#define WILL 251
#define WONT 252
#define DO 253
#define DONT 254
#define IAC 255

int main(int argc, char *argv[]) {
     int lsock, asock;
     int tofd[2]; /* to application */
     int fromfd[2]; /* from application */
     int apin, apout; /* fd's from/to application */
     fd_set readfds, writefds, exceptfds;
     unsigned char temp;
     unsigned int tempint;
     unsigned char buffer[BUFSIZ];
     unsigned char ndata;
     unsigned char ntype;
     enum {N_NORMAL, N_IAC_RCVD, N_NEG_RCVD} nstate;
     signed int retval; /* syscall return value */
     struct sockaddr_in baddr; /* Bind address */
     if ((lsock=socket(AF_INET, SOCK_STREAM, 0))<0)
	  perror("socket");
     tempint=1;
     if ((setsockopt(lsock, SOL_SOCKET, SO_REUSEADDR, &tempint, sizeof(int)))<0)
	  perror("setsockopt");
     baddr.sin_family=AF_INET;
     baddr.sin_port=htons(atoi(argv[1]));
     baddr.sin_addr.s_addr=INADDR_ANY;
     if ((bind(lsock, &baddr, sizeof(baddr)))<0)
	  perror("bind");
     if ((listen(lsock, BACKLOG))<0)
	  perror("listen");
     while (1) {
	  if ((asock=accept(lsock, NULL, 0))<0)
	       perror("accept");
	  if (pipe(tofd)<0)
	       perror("pipe: tofd");
	  if (pipe(fromfd)<0)
	       perror("pipe: fromfd");
	  if ((retval=fork())<0)
	       perror("fork");
	  if (retval) {
	       if (close(tofd[0])<0)
		    perror("parent: close: tofd");
	       if (close(fromfd[1])<0)
		    perror("parent: close: fromfd");
	       apin=fromfd[0];
	       apout=tofd[1];
	  } else {
	       if (close(0)<0)
		    perror("child: close: stdin");
	       if (close(1)<0)
		    perror("child: close: stdout");
	       if (close(2)<0)
		    perror("child: close: stderr");
	       if (close(asock)<0)
		    perror("child: close: network socket");
	       if (dup2(tofd[0], 0)<0)
		    perror("child: dup2: stdin");
	       if (dup2(fromfd[1], 1)<0)
		    perror("child: dup2: stdout");
	       if (dup2(fromfd[1], 2)<0)
		    perror("child: dup2: stderr");
	       if (execl("/bin/sh", "/bin/sh", "-i", NULL)<0)
		    perror("child: execl");
	  }
	  nstate=N_NORMAL;
	  FD_ZERO(&readfds);
	  FD_ZERO(&writefds);
	  FD_ZERO(&exceptfds);
	  while (1) {
	       FD_SET(asock, &readfds);
	       FD_SET(apin, &readfds);
	       select(selwidth, &readfds, &writefds, &exceptfds, NULL);
	       if (FD_ISSET(asock, &readfds)) {
		    if ((retval=read(asock, &ndata, 1))<0)
			 perror("read: from network");
		    if (!retval)
			 exit(0);
		    switch (nstate) {
		    case N_NORMAL:
			 if (ndata!=IAC)
			      write(apout, &ndata, 1);
			 else {
			      nstate=N_IAC_RCVD;
			      continue;
			 }
			 break;
		    case N_IAC_RCVD:
			 switch (ndata) {
			 case IAC:
			      write(apout, &ndata, 1);
			      write(apout, &ndata, 1); /* Escape IAC */
			      nstate=N_NORMAL;
			      continue;
			 case WILL:
			 case WONT:
			 case DO:
			 case DONT:
			      nstate=N_NEG_RCVD;
			      ntype=ndata;
			      continue;
			 default:
			      nstate=N_NORMAL;
			      continue;
			 }
		    case N_NEG_RCVD:
			 switch (ntype) {
			 case WONT:
			 case DONT:
			      nstate=N_NORMAL;
			      continue;
			 case WILL:
			 case DO:
			      temp=IAC;
			      write(asock, &temp, 1);
			      if (ntype==WILL)
				   temp=DONT;
			      else
				   temp=WONT;
			      write(asock, &temp, 1);
			      write(asock, &ndata, 1);
			      nstate=N_NORMAL;
			      continue;
			 default:
			      fprintf(stderr, "BUG!\n");
			 }
		    }
	       }
	       if (FD_ISSET(apin, &readfds)) {
		    if ((retval=read(apin, &ndata, 1))<0)
			 perror("read: from application");
		    if (!retval)
			 exit(0);
		    write(asock, &ndata, 1);
		    if (ndata==IAC)
			 write(asock, &ndata, 1);
	       }
	  }
  }
}




-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 1993 11:08:21 +1000
From:      markd@bushwire.apana.org.au (Mark Delany)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over X.25

In <1993Sep25.234325.29720@advtech.uswest.com> crohrer@advtech.uswest.com ( Chris Rohrer) writes:

>Has anyone implemented anything using X.25 to connect two separate IP sites
>together?  I realize it's been done and that there is even an RFC that
 
>I mean, if you want to use IP, RARP and ARP simultaneously, what do you
>do?  Over something like Ethernet, you have the type field to do this
>"multiplexing" for you since the embedded protocols are not
>self-indicating.  Do you define a header that sits at the front of every
>X.25 data packet to indicate type?  Do you set up multiple parallel
>virtual circuits, one for each protocol you want to carry and indicate in

Hmm, dunno about ARP and RARP over X.25...

The way that I've seen it done merely to encapsulate the IP packets
and send them over a single VC. There is a single server on the other
end of the VC which 'more or less' injects all packets back into IP.

Very simple.

Using a single VC has a many good points. The primary one is that
which you allude to. Namely that the mapping of IP 'circuits' to X.25
is completely avoided. And consider the problems of UDP applications
such as NFS?

A second point is that many X.25 switches can only support a small
number of active VCs at one time, which could easily be consumed by
busy IP sites if the "one VC per TCP connection" strategy was used.

The disadvantage though is that IP encapsulation over X.25 is pretty
inefficient, especially for interactive applications. Mind you,
nothing stops an encapsulator from looking into the packets and doing
a bit of compression on them. VJ compression from SLIP is an obvious
one.


M.

-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 93 05:40:13 GMT
From:      nir@Zoran.Hellnet.Org (Nir Sever)
To:        comp.protocols.tcp-ip,comp.sys.sun.apps,alt.sys.sun
Subject:   Re: How to order SUN RPC book (Springer-Verlag)?

In article <CE15yE.9Kz@MathWorks.COM>, walter@mathworks.com (Walter E. Gillett) writes:
> >How to order SUN RPC book (Springer-Verlag)?
> 
> Try quanbook@world.std.com (Quantum Books, Cambridge, MA, (617) 494-5042).
> They are the only bookstore I know of that takes orders by email (O'Reilly

Computer Literacy Bookshops, Inc. does it too.

Computer Literacy Bookshops, Inc.
PO Box 641897
San Jose, CA  95164-1897
(408) 435-5017 (Corinna) or (408) 435-5015 ext 108 (Rachel)
Fax (408) 435-1823
info@clbooks.com
-- 

    Nir (Samburski) Sever,            Tel: 972-4-551551
    CAD group,                        Fax: 972-4-551550
    Zoran Microelectronics LTD,
    Advanced Technology Center
    POB 2495, Haifa 31204, Israel     E-mail: nir@Zoran.HellNet.Org

-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 93 05:46:34 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   The Importance of Non-Data Touching Processing Overheads in TCP/IP


	The SIGCOMM '93 paper, "The Importance of Non Data Touching
Overheads," on why non data touching overheads are more important than
data touching overheads in processing a realistic packet workload, is
available for anonymous FTP.  It may be found in

ucsd.edu:pub/csl/fastnet/sigcomm93.ps.Z

							Jon

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

   The Importance of Non-Data Touching Processing Overheads in TCP/IP

		   Jonathan Kay and Joseph Pasquale

		     Computer Systems Laboratory
	   Department of Computer Science and Engineering
		 University of California, San Diego
		      San Diego, CA 92093-0114

		    {jkay, pasquale}@cs.ucsd.edu

Abstract:

We present detailed measurements of various processing overheads of
the TCP/IP and UDP/IP protocol stacks on a DECstation 5000/200 running
the Ultrix 4.2a operating system. These overheads include
data-touching operations, such as the checksum computation and data
movement, which are well known to be major time consumers. In this
study, we also considered overheads due to non-data touching
operations, such as network buffer manipulation, protocol-specific
processing, operating system functions, data structure manipulations
(other than network buffers), and error checking. We show that when
one considers realistic message size distributions, where the majority
of messages are small, the cumulative time consumed by the non-data
touching overheads represents the majority of processing time. We
assert that it will be difficult to significantly reduce the
cumulative processing time due to non-data touching overheads.


-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 1993 13:18:20 -0400
From:      aem@symbiosis.ahp.com (a.e.mossberg)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: Residence Hall Networking


In article <AEJ.93Sep23121242@manyjars.WPI.EDU> aej@manyjars.WPI.EDU (Allan E Johannesen) writes:
>Wiring the student residence halls for computer networking (and cable
>and phones) is finally being contemplated on our campus.  We would
>like to offer Ethernet connection or serial connections for those who
>don't want to invest in Ethernet cards (purchased or leased from the
>college, or whatever).

atkinson@itd.nrl.navy.mil (Ran Atkinson) replies:
>  I'd recommend running Class 5 twisted-pair to each room using a star
>topology to a wiring closet.  This will support Ethernet today using
>commercial Ethernet hubs.  It will also be upgradable to FDDI over
>twisted-pair or ATM over twisted-pair later on.  Ethernet cards are
>cheap enough ($99) now that I wouldn't even bother with the serial
>connections.


You can do either serial or ethernet over the wire.  Terminate it to the RJ45
connector in the rooms, and for those who desire serial instead of 10baseT,
have RJ45-DB25 cables available, and connect it in the wiring closet to a
terminal server.

Using 4-pair you'll also be able to upgrade to 100base-VG when it is finally
chosen and approved.  You don't even have to use Level 5 -- you can use level 3
wire just fine.

aem

-- 
andrew mossberg * network manager * symbiosis corporation * miami, florida, usa
(305) 597-4110  *  fax: 597-4002  * aem@symbiosis.ahp.com * pahayokee bioregion

-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Sep 1993 11:44:42 GMT
From:      sh7000157@ntuvax.ntu.ac.sg
To:        comp.protocols.tcp-ip
Subject:   Looking for Talk on PC?

Hi,

I am looking for a Unix talk program that can run on PC using
PC/TCP.  So far I have come across Win Chat, Waterloo's Experimental
Version of Talk and several others.  But none seem to work.
I would like to find out if anybody have successfully ported the 
original UCB version of Talk to PC.  Please advise.  I hope that
I can find one that can communicate between a PC running PC/TCP
and a remote site running Unix.

Best Regards,
Sim Huat
email : sh7000157@ntuvax.ntu.ac.sg


-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Sep 1993 11:53:27 GMT
From:      jhall@madeline.umhc.umn.edu (Jeff Hallgren)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for TANDEM CLX series ???

In article <1993Sep27.141354.3780@foobar.hanse.de> root@foobar.hanse.de (Jens Stark)  
writes:
> 
> Hi,
> 
> I heard about a package which allows to use a vt100 via telnet to
> work as a page mode terminal.
> Has anybody heard about that thing ? Pricing ? Who sells it ??
> 
> Any help appreciated,
>               Jens

	We're doing vt100 telnet sessions to a Tandem VLX. The software is by  
FAILSAFE COMPUTER SYSTEMS, INC
8303 W Higgins
Chicago IL, 60631
Phone: (312)-693-1310
	I hope this helps,
	Jeff

jhall@tahiti.umhc.umn.edu (Jeff Hallgren)

-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Sep 93 13:20:44 GMT
From:      dpratt@nlbbs.com (David Pratt)
To:        comp.protocols.tcp-ip
Subject:   Class C subnetting

We have a new class C Internet number at our school... How do I go about
subnetting this and why would I want to...

                              .... David

-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Sep 1993 13:56:01 GMT
From:      alexis@avalon.elis.crimea.ua (Alex Yushin)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS & /etc/hosts usage

System Administrator (root@swuts.sbc.com) wrote:
> I have been doing some testing with various UNIX platforms concerning the
> use of domain name service resolving & /etc/hosts resolving.  I have found
> that some platforms first check the domain name server, and if the hostname
> is not found, looks in the local /etc/hosts file for the name.  Other
> platforms use only the DNS resolver for hostname lookup, never resorting
> to the /etc/hosts file in cases where the name is not located in the DNS
 ..
> other systems, even if they all used the same DNS resolver system.
 
> Any information, opinions, etc. on this topic would be greatly appreciated.

All information about the way of resolving an ip-address is usually stored in
/etc/resolv.conf file.
-- 
	  	  	   	  	  	   	Dark Alexis.


"I've asked the neighbour why he is so fool, he treated my tears for laugh."

-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 93 14:18:17 GMT
From:      bas@moria.macs.sp.unisys.com (Brian Strop)
To:        comp.protocols.tcp-ip
Subject:   lpr/lpd for Unix SVR4

I am looking for any commerical, shareware, freeware implementations of
lpr/lpd for Unix SVR4. Any information would be greatly appreciated.
Thanks in advance,

Brian

P.S. If you repond by private mail, do not use the reply field; my return
address gets corrupted some where along the way. Use the address in the
signature below. Thanks again
-- 
Brian A. Strop				(612) 687-2709
UNISYS					bas%moria.uucp@email.sp.paramax.com
Network Systems

-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Sep 1993 15:34:04 GMT
From:      phuong@rocky.raleigh.ibm.com (Phuong Nguyen)
To:        comp.sys.novell,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: TCP/IP sockets bind/close  question ?

In article <28801k$d25@bingsuns.cc.binghamton.edu>, bb31351@bingsuns.cc.binghamton.edu (Rakesh Shetty) writes:
|> 
|> Hello,
|> 
|> I am having a peculiar problem when attemptimg to use sockets (SUN OS 4.1.1).
|> Here is the socket creation in a server program :
|> 
|> 
|> bzero((char *)&distributor_server,sizeof(distributor_server));
|>  distributor_server.sin_family=AF_INET;
|>  distributor_server.sin_addr.s_addr = INADDR_ANY;
|>  distributor_server.sin_port=    (u_short)DISTRIBUTOR_PORT ;
|>  if (bind(sock,(struct sockaddr *)&distributor_server,
|>           sizeof(distributor_server)) < 0)
|>   {
|>     printf("cant bind server  local addr. \n");
|>     perror("dist server bind");
|>     exit(1);
|>   }
|> 
|> where:
|> #define DISTRIBUTOR_PORT 5500
|> 
|> Now the above socket is closed successfully when the program ends:
|> if (close(sock)==-1)  {perror("dist. sock close failed:");}
|> 
|> The program terminates normally. However after certain runs I get a message:
|> 
|> cant bind server  local addr.
|> server address in use.
|> 
|> Although strictly speaking one must be able to use the port immediately,
|> I guess the system needs some time to retrieve the port numbers for 
|> reuse. However I dont seem to able to place a time duration on this.
|> It gets quite irritating when i have to debug with different clients and the
|> server keeps giving the above error message although it terminated
|> normally on the last run.
|> 
|> I have a similar problem in another program where I bind a socket
|> with the broadcast option turned on. This too at times gives the mesg.
|> 
|> address already in use: unable to bind.
|> 
|> ALTHOUGH on the previous run the program  terminated normally ,
|> successfully closing the socket.
|> 
|> Any pointers or suggestions are welcome.
|> 
|> Thanx,
|> Rakesh
|> email:rshetty@cs.binghamton.edu

 A while ago, I had a same problem you just described above.  I found
out that while my program ended successfully but some proccesses I created
to send or read sockets did not ended.  They were still hung around.  So
I solved it by code my program kills all subprocesses before it leaves 
then I see no more problem.  May you have a same problem ???

*********************************
Opinions are mine not IBM's
Have a "phuongtastic" day,
Phuong Thanh Nguyen
Networking System.
PNGUYEN@VNET.IBM.COM
*********************************


-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 1993 23:21:52 -0400
From:      kbb@access.digex.net (Kevin Burkhardt)
To:        comp.protocols.tcp-ip,alt.sources.wanted,comp.sys.novell
Subject:   Wanted: TLI/IPX example source!


***************************************************************************
    Wanted: Univell/UnixWare C source code that demonstrates TLI using IPX.

   Purpose: I want my UnixWare box to be able to log into a Novell/Netware
            File Server and read IPX packets (sent to the process logged into
	    the server) from the Novell LAN.

Background: I have the code to allow my process to attach/log into the Netware
	    File Server.
	    
	    To use TLI/IPX I started off with the demo program listed on 2-32 
	    in the Univell, "Network Programming Interfaces" document, making
	    the appropriate changes to use IPX.

	    Before I call "bind()", I set the desired port number
	    (Univell calls it the server address and Netware calls it a
	    socket number).  There is a discrepancy between the port number
	    I requested (0x04) and the port number returned 
	    (0xFF 0xFF 0xFF 0xFD).

	    According to the Univell tech support, I can only set the 
	    port number to one of the set of port numbers listed in the 
	    "/var/spool/sap/in" directory.  In my case, I have three ports 
	    to choose from:

	    0x4
	    0x3e1
	    0x3e4

	    Much thanks to anyone who can help.


	    Craig Knapik
	    EON (formerly "TV Answer")
	    703-715-8824
	    "knapikc@eon.com"

Please email responses to: knapikc@eon.com

-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Sep 1993 16:48:03 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Re: giant packets


	
	We had a couple of Ethernet meltdowns at Oklahoma State University
caused by giant packets which came from new 10baseT hubs which had gone
into failure mode.  The packets were basically continuous blasts of carrier
which made finding the actual bad interface very hard.
	
	As a person still on the lower end of the networking learning curve,
I am truly surprised at the amount of damage that certain network conditions
can cause.  While noise, giant packets and cut cables can be expected to
halt communications on the effected network or segment, one would expect
Those systems whose operating system is self-contained to be able to institute
a sort of safety valve or circuit breaker strategy to keep themselves from
sliding into chaos along with the rest of the network.  A work station's
interface driver might sense that what is coming in is not a valid packet
for whatever reason and simply shut down any further interrupts, choosing to
pole the interface for an end to the jamming before normal operation would
resume.  Obviously, with a network down, it is not business as usual, but
it beats a host crash and the disruption to users who may not have even been
using any telecommunication at the time.

	What I am talking about is more of a strategy than a specific fix.
Accidents and sabotage do happen and every bit  of network code should be
written with the idea that there must be some way to save as much of the
rest of the host's ability to function as possible.

Martin McCormick WB5AGZ   Stillwater, OK
O.S.U. Computer Center Data Communications Group

-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Sep 1993 16:50:07 GMT
From:      Stanley.D.Dunten@dartmouth.edu (Stanley D. Dunten)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: Residence Hall Networking

We wired our dorms in '84 to run AppleTalk. Physical layer is mostly
LocalTalk with now a few IP over Ethernet ports.

AppleTalk is so easy. A couple of Saturdays ago we passed out Macs to
about 1000 freshmen in 4 hours. Within an hour the number of Macs on
the network started increasing. By the end of the 4 hours 80% of the
freshmen had sent or received email. AppleTalk really is plug and play.

Stan Dunten, Dartmouth College (Stan Dunten@Dartmouth.edu)

-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Sep 93 18:05:04 GMT
From:      al@runit.sintef.no (Arne Langmo)
To:        comp.sys.hp,comp.protocols.tcp-ip,comp.dcom.sys.wellfleet
Subject:   Re: HP Router ER Configuration

In article <282q3i$mlb@news-feed-2.peachnet.edu>, Jerry@PeachNet.EDU (Jerry Segers) writes:
|> In article <carr-220993213044@macm407.esl.com>
|> carr@esl.com (John A. Carr) writes:
|> 
|> > I have an HP Router ER (5.74 software).  This is a small
|> > IP/appletalk/IPX/DECNet router with 2 ethernet ports and 2 serial ports. 
|> > It is somehow based on Wellfleet technology and the command interface seems
|> > very similar.  
|> > 
 
|> 1 - I believe that HP is now selling a repainted Wellfleet router.

No, the HP-ER (and HP-TR) are HP made hardware that uses Wellfleet
software, with some mods.

HP-ER has no floppy, the software are in EEPROM.


Arne Langmo                          E-Mail: Arne.Langmo@runit.sintef.no
SINTEF Runit                                         Phone: +47 759 2068
Computing Center at the                                FAX: +47 794 0706
University of Trondheim                           Mail: N-7034 Trondheim
NORWAY.                                                            NORGE

-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 1993 16:43:14 +0100
From:      jpmens@ingres.com (Jan-Piet Mens)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Howto route machine onto different subnet

I would like to hook up a machine on say subnet 1.1.1.2 temporarily
onto a network say, 100.200.1.1  without having to reconfigure (except
adding routing information).
Is this possible ?
What would I have to do ?

Thanks!
	Jan-Piet
-- 
Jan-Piet Mens                                               jpmens@ingres.com
ASK Ingres GmbH, Frankfurt, Germany                          +49 69 66413-285

-----------[000463][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Sep 93 18:28:18 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Excellent lesson in TCP timers provided by KA9Q

Cool!

Get a copy of KA9Q (ucsd.edu:hamradio/packet/tcpip/ka9q/rcsdsrc.zip
Also get rcs: ucsd.edu:hamradio/packet/tcpip/ka9q/rcs56b.zip).
Install it along with yr. fav. packet driver.

Start a long FTP session.  Go back to the command prompt with F10.
Find the TCP session block for port 20 using "tcp s".  Then watch
that block using "repeat tcp s xxxxxxxx", where xxxxxxxx is the value
you found from the previous command.  Observe the bottom line.  Now
unplug your machine from the Ethernet and watch the timers increase
as it retries.  Then plug it back in and watch them decrease as TCP
re-learns that you have a working, timely connection again.

This works best on a slow transfer.  It's not so instructive if
you're getting 100Kb/sec.

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

-----------[000464][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 1993 20:54:03 GMT
From:      bab@se40.wg2.waii.com (Brian Button)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Problem with XDR server and client

I'm having a heck of a time getting a simple piece of XDR code to work
correctly, and the Sun Tech Support people are refusing to help.

I've written a simple client and server to send a simple structure
from one to the other. The sender (client) seems to be sending the
data correctly, but the server isn't even trying to read the data off
the socket. I must have left out some important piece of the puzzle,
but I cannot figure out what.

What I'm seeing is that xdr_NavUVLocation in the server is being
called correctly, but it is returning FALSE. This function calls
xdr_double three times, but the first call is failing.

I grabbed the XDR source code and worked my way through it, and I
think I know where the problem is. xdr_double calls XDR_GETLONG, which
calls xdrrec_getlong, which in turn calls xdrrec_getbytes to actually
read from the socket. It appears that the conditions necessary to call
xdrrec_getbytes are never being satisfied, so the socket is never
being read. I've loaded the code into CodeCenter and gdb, and ReadProc
in the server is never being entered.

What have I left out? If there is anyone out there who has any
suggestions, please let me know. I know it must be something minor,
but I can't find it and Sun refuses to help.

------------ server.c ------------
#include    <stdio.h>
#include    <assert.h>
#include    <sys/types.h>
#include    <sys/socket.h>
#include    <netdb.h>
#include    <netinet/in.h>

#include    <rpc/types.h>
#include    <rpc/xdr.h>

#include    "str.h"

int ReadProc( char * iohandle, char * buf, int count )
{
    int i;
    int ret;
    int sd = *( int * )iohandle;

    fprintf( stderr, "server : inside ReadProc\n" );
    fflush( stderr );
    
    if( buf == NULL ) return -1;

    ret = read( sd, buf, count );

    fprintf( stderr, "Server : just read %d bytes : \n", ret );
    
    for( i = 0; i < ret; i++ )
    {
        if( i && ( i % 16 )) fprintf( stderr, "\n" );
        fprintf( stderr, "%02X ", buf[ i ] );
    }

    fprintf( stderr, "\n" );

    return ret;
}


int WriteProc( char * iohandle, char * buf, int count )
{
    int ret;
    int sd = *( int * )iohandle;

    if( buf == NULL ) return -1;

    ret = write( sd, buf, count );

    return ret;
}


extern int CreateSocket( short port );
extern int AcceptConnection( int sd );
extern void ReadData( XDR * xdr );

int main( int argc, char ** argv )
{
    int     a_sd;
    int     sd;
    XDR     xdr;
    
    if( argc != 2 )
    {
        fprintf( stderr, "usage : server <port>\n" );
        fflush( stderr );

        return 1;
    }

    sd = CreateSocket(( short )atoi( argv[ 1 ] ));
    a_sd = AcceptConnection( sd );
    
    xdrrec_create( &xdr, 1024, 1024, ( char * )a_sd, ReadProc, WriteProc );

    ReadData( &xdr );

    xdr_destroy( &xdr );

    shutdown( a_sd, 2 );
    shutdown( sd, 2 );
    
    close( a_sd );
    close( sd );

    return 0;
}

    
int CreateSocket( short port )
{
    int     ret;
    int     sd;
    int     addr_len = sizeof( struct sockaddr_in );

    struct sockaddr_in  host_addr;

    memset( host_addr, 0, sizeof( host_addr ));

    sd = socket( AF_INET, SOCK_STREAM, 0 );

    host_addr.sin_family = AF_INET;
    host_addr.sin_port = htons( port );
    host_addr.sin_addr.s_addr = htonl( INADDR_ANY );

    if( bind( sd, ( struct sockaddr * )&host_addr, addr_len ) == -1 )
    {
        perror( "bind" );
        abort( );
    }

    if( listen( sd, 5 ) == -1 )
    {
        perror( "listen" );
        abort( );
    }

    return sd;
}


int AcceptConnection( int sd )
{
    int     a_sd;
    int     remote_addr_len = sizeof( struct sockaddr_in );

    struct sockaddr_in  remote_addr;

    memset( remote_addr, 0, sizeof( remote_addr ));

    fprintf( stderr, "server: accepting..." );
    fflush( stderr );
    
    if(( a_sd = accept( sd,
                       ( struct sockaddr * )&remote_addr,
                       &remote_addr_len )) == -1 )
    {
        perror( "accept" );
        abort( );
    }

    fprintf( stderr, "got it!\n" );

    return a_sd;
}


void ReadData( XDR * xdr )
{
    bool_t          ret;
    NavUVLocation   uv_loc;

    xdr->x_op = XDR_DECODE;

    ret = xdr_NavUVLocation( xdr, &uv_loc );
    if( ret == FALSE )
    {
        perror( "xdr_NavUVLocation" );
        abort( );
    }

    fprintf( stderr, "uv_loc.u = %lf\n", uv_loc.u );
    fprintf( stderr, "uv_loc.v = %lf\n", uv_loc.v );
    fprintf( stderr, "uv_loc.w = %lf\n", uv_loc.w );
}

------------------- client.c ----------------
#include    <stdio.h>
#include    <assert.h>
#include    <sys/types.h>
#include    <sys/socket.h>
#include    <netdb.h>
#include    <netinet/in.h>

#include    <rpc/types.h>
#include    <rpc/xdr.h>

#include    "str.h"


int ReadProc( char * iohandle, char * buf, int count )
{
    int ret;
    int sd = *( int * )iohandle;

    if( buf == NULL ) return -1;

    ret = read( sd, buf, count );

    return ret;
}


int WriteProc( char * iohandle, char * buf, int count )
{
    int i;
    int ret;
    int sd = *( int * )iohandle;

    if( buf == NULL ) return -1;

    for( i = 0; i < count; i++ )
    {
        if( i && !( i % 16 )) fprintf( stderr, "\n" );
        fprintf( stderr, "%02X ", ( unsigned char )buf[ i ] );
    }

    fprintf( stderr, "\n" );

    ret = write( sd, buf, count );

    return ret;
}


extern int CreateSocket( const char * host, short port );
extern void SendData( XDR * xdr );

int main( int argc, char ** argv )
{
    XDR     xdr;
    int     sd;
    int     ret;

    if( argc != 3 )
    {
        fprintf( stderr, "usage : client <host> <port>\n" );
        fflush( stderr );

        return 1;
    }
    
    sd = CreateSocket( argv[ 1 ], ( short )atoi( argv[ 2 ] ));

    xdrrec_create( &xdr, 1024, 1024, ( char * )&sd, ReadProc, WriteProc );

    SendData( &xdr );

    xdr_destroy( &xdr );

    shutdown( sd, 2 );
    close( sd );

    return 0;
}


int CreateSocket( const char * host, short port )
{
    int     sd;
    int     ret;
    int     addr_len = sizeof( struct sockaddr_in );

    struct sockaddr_in  host_addr;
    struct hostent *    host_entry;
    
    memset( host_addr, 0, sizeof( struct sockaddr_in ));

                                            /* Open a tcp socket */
    sd = socket( AF_INET, SOCK_STREAM, 0 );
    if( sd == -1 ) return -1;

                                            /* Find out the host address
                                               from the name */
    host_entry = gethostbyname( host );
    assert( host_entry );

                                            /* Fill out the address
                                               structure  */
    host_addr.sin_family = AF_INET;
    host_addr.sin_port = htons( port );
    host_addr.sin_addr.s_addr = *(( unsigned long * )( host_entry->h_addr ));

    ret = connect( sd, ( struct sockaddr * )&host_addr, addr_len );
    if( ret < 0 )
    {
        perror( "connect" );
        assert( ret >= 0 );
    }

    return sd;
}    
    

void SendData( XDR * xdr )
{
    bool_t          ret;
    NavUVLocation   uv_loc;

    uv_loc.u = 10.7;
    uv_loc.v = 55.7;
    uv_loc.w = -881.2;

    xdr->x_op = XDR_ENCODE;

    ret = xdr_NavUVLocation( xdr, &uv_loc );
    if( ret == FALSE )
    {
        perror( "xdr_NavUVLocation" );
        abort( );
    }

    ret = xdrrec_endofrecord( xdr, 1 );
    if( ret == FALSE )
    {
        perror( "xdr_endofrecord" );
        abort( );
    }
}

------------- str.x --------------

#ifdef RPC_HDR
%#ifndef _STRUCTS_H
%#define _STRUCTS_H
%
#endif

struct NavUVLocation
{
    double              u;                  /* In meters. */
    double              v;                  /* In meters. */
    double              w;                  /* In meters. */
};

#ifdef RPC_HDR
%
%#endif
#endif

--------------- end ---------------

Thanks,
bab











--
|-----------------------|----------------------------------------------------|
| Brian Button          | email : button@wg2.waii.com                        |
| Design Engineer       |         71023.276@compuserve.com                   |
| Western Geophysical   | voice : (713)964-6221                              |
| 3600 Briarpark        |----------------------------------------------------|
| Houston, Texas  77042 |                                                    |
|-----------------------|----------------------------------------------------|

-----------[000465][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 1993 21:56:03 GMT
From:      jazz@jazz.hal.com (Jason Zions)
To:        comp.sys.novell,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: TCP/IP sockets bind/close  question ?

Please read the TCP RFC and RFC 1122 in the section that discusses
FIN_WAIT_2 state. Also, check your programming documentation for the
SO_REUSEADDR socket option, or something like it (depending on the quality
of implementation on your system) that lets you override the mandatory
waiting period.

According to the RFCs, you cannot rebind a port for one minute (or is it two
minutes? Damn, I knew I'd forget) after a close; this allows data to safely
drain and prevents the connection peer from confusing a new socket on that
port with the old (closed) one.

Jason

-----------[000466][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 1993 10:21:58 -0700
From:      schmidt@liege.ics.uci.edu (Douglas C. Schmidt)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip
Subject:   Re: Gigabit Networking book out

In article <foltaCE3F73.5ro@netcom.com>, Steve Folta <folta@netcom.com> wrote:
++ How much will it cost?

	The announcement I have says the list price is $46.25.  The
book is 400 pages with an ISBN number of 0-201-56333-9.

	On a related note, I'm forwarding the following message at the
request of John Wait, who is the editor for Dr. Partridge's new book.

---------------------------------------- 
Craig Partridge will be at Quantum Books at Kendall Square in
Cambridge on October 4 (12:30-1pm) to offer a lively and somewhat
controversial discussion on the topic of his new book GIGABIT
NETWORKING (Addison-Wesley, 1994).

Please stop by during your lunch break.  We guarantee the talk will be
interesting, and there will be time to visit with Craig after the
talk.  The first copies of his book are being shipped from the bindery
to Quantum's this Friday, October 1st.

If you are interested in this book, we are sure Craig would be
delighted in autographing your copy.  Please reserve your seat at this
talk by contacting Bill Szabo at Quantum's at 617-494-5042 or via
email at quanbook@world.std.com.

Hope to see you there next Monday!

Best regards,

John Wait
Addison-Wesley
----------------------------------------
-- 
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

-----------[000467][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Sep 1993 22:51:24 GMT
From:      craigp@world.std.com (Craig Partridge)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip
Subject:   Gigabit Networking book out

Several folks have asked me when my book on Gigabit Networking would be
in print.  The answer is Friday, Oct 1.  It's from Addison Wesley (ISBN
0-201-56333-9).  Table of concents is appended for anyone interested.

Craig

		Contents of Gigabit Networking

Preface                                 			xi

1. An Introduction to Gigabit Networking
   1.1 Change in the Wind                			 1
   1.2 What is Changing?                    			 3
   1.3 Rules of the Road                    			 8
   1.4 What Follows this Chapter           			12

2. Fiber Optics
   2.1 Introduction                     			15
   2.2 Essentials of Fiber Optics          			15
   2.3 Transmitters and Receivers          			25
   2.4  An  Example  of  Fiber  Optic  Signalling: SONET 	28
   2.5 Another Example: WDM Networks       			34
   2.6 Other Media                         			40
   2.7 Summary                             			41

3. An Introduction to Cell Networking
   3.1 Introduction                     			43
   3.2 What Is a Cell?                     			43
   3.3 Fragmenting Data into Cells         			47
   3.4 Why Cells?                          			48
   3.5 Cell Routing                        			51
   3.6 Adaptation Layer Protocols          			53
   3.7 Cell Error Recovery                 			56
   3.8 Summary                             			59

4. Asynchronous Transfer Mode
   4.1 Introduction                     			61
   4.2 ATM Inside the Telephone Networks   			62
   4.3 ATM Conceptual Model                			63
   4.4 ATM Cell Format                     			65
   4.5 ATM Cell Header at the NNI          			65
   4.6 ATM at the User-Network Interface   			69
   4.7 Adaptation Layers                   			71
   4.8 Signalling an ATM Connection        			82
   4.9 Putting the ATM Bits on the Wire    			83
   4.10 Issues in ATM                      			84
   4.11 Summary                            			87

5. Wide Area Cell Networking
   5.1 Introduction                     			89
   5.2 Blocking                            			90
   5.3 The Canonical Cell Switch           			90
   5.4 Buffering Strategies                			92
   5.5 Crossbar Switches                  			100
   5.6 Batcher-Banyan Switches            			110
   5.7 Input Buffering Revisited          			123
   5.8 An Optical Cell Switch             			125
   5.9 The Cost of Port Controllers       			127
   5.10 Summary                           			127

6. Local Area Cell Networks
   6.1 Introduction                    				129
   6.2 Shared Media Cell Networks         			130
   6.3 Local Area Switching Technologies  			147
   6.4 Summary                            			151

7. Gigabit Packet Networks
   7.1 Issues in Packet Network Design	 			153
   7.2 Local Area Packet Technologies     			154
   7.3 Wide Area Packet Technologies      			163
   7.4 Summary                            			172

8. Gigabit Applications
   8.1 Introduction    	                			175
   8.2 Classic Applications               			175
   8.3 New Applications                   			176
   8.4 New Computing Applications         			177
   8.5 Applications with Humans in the Loop			178
   8.6 The Impact of New Applications     			190
   8.7 Summary                            			193

9. Making Hosts Ready for Gigabit Networks
   9.1 Introduction	                    			195
   9.2 The Model Machine                  			196
   9.3 The Costs of Moving Data           			196
   9.4 Reducing Memory Copy Costs         			202
   9.5 Other Processor-Memory Interactions			207
   9.6 Multiprocessor Architectures       			210
   9.7 What about Cells?                  			213
   9.8 A Summary of System Performance Issues			216
   9.9 Support for Real-Time Applications 			217
   9.10 Summary                           			222

10. Today's Internetworking Protocols
   10.1 Internetworking                				225
   10.2 Gigabit Speeds and Today's Protocols			226
   10.3 Architecture of TCP/IP            			227
   10.4 Techniques for Going Fast         			230
   10.5 Limitations of Today's Protocols  			241
   10.6 Converging on the Shape of Gigabit Protocols		248
   10.7 Summary                           			250

11. Traffic Shaping
   11.1 Introduction	                   			253
   11.2 Why Shape Traffic?                			253
   11.3 Isochronous Shaping               			255
   11.4   Isochronous Shaping with Priority Schemes		258
   11.5 Shaping Bursty Traffic Patterns   			260
   11.6 Summary                           			263

12. Performance Guarantees
   12.1 Introduction           	        			265
   12.2 Terminology and Issues            			266
   12.3 Statistical Multiplexing          			269
   12.4 Weighted Fair Queueing            			276
   12.5 Jitter Control Schemes            			280
   12.6 Statistical Multiplexing Revisited			285
   12.7 Summary                           			286

13. Flow Setup and Routing
   13.1 Remaining Problems	             			289
   13.2 The Host's Role in Flow Setup     			290
   13.3 Protocols to Establish a Flow     			293
   13.4 Routing                           			305
   13.5 Summary                           			309

14. Distributed Systems
   14.1 Introduction                   				311
   14.2 Distributed Systems Today         			312
   14.3 Alternative Approaches to Distributed Systems		320
   14.4 Enhancing Distributed Services    			330
   14.5 Authentication                    			337
   14.6 Summary                           			339

15. The State of Gigabit Networking
   15.1 Introduction   	                			341
   15.2 Putting the Pieces Together       			341
   15.3 Lingering Problems                			342
   15.4 Unaddressed Problems              			344
   15.5 After Gigabits, Terabits?         			345
   15.6 Final Thoughts                    			346

16. Where to Learn More
   16.1 Introduction  	                 			347
   16.2 Testbeds and Research Programs    			347
   16.3 Conferences and Journals          			357
   16.4 Getting Items in the Bibliography 			360

Bibliography                           				361
Index                                  				389

-----------[000468][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Sep 1993 23:36:26 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.sys.novell,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: TCP/IP sockets bind/close  question ?

>Please read the TCP RFC and RFC 1122 in the section that discusses
>FIN_WAIT_2 state. Also, check your programming documentation for the
>SO_REUSEADDR socket option, or something like it (depending on the quality
>of implementation on your system) that lets you override the mandatory
>waiting period.
>
>According to the RFCs, you cannot rebind a port for one minute (or is it two
>minutes? Damn, I knew I'd forget) after a close; this allows data to safely
>drain and prevents the connection peer from confusing a new socket on that
>port with the old (closed) one.

It's twice the MSL.  Most BSD-derived systems assume an MSL of 30 seconds,
so 2MSL is 1 minute.  Solaris 2.x is the first one I've seen that actually
uses the recommended value of 120 seconds, for a 2MSL of 4 minutes.

And, the RFCs say *nothing* about binding a port that's in the 2MSL state.
The rule is that TCP cannot create a connection whose socket pair (the
4-tuple defining the connection) is in the 2MSL wait.  Period.

The rule about bind() returning an error just because the local port
is part of a socket pair that's in the 2MSL wait is a BSD-ism that
continually confuses people.  It's not required, which is why they
provide the SO_REUSEADDR socket option.  Realize, however, that even
with SO_REUSEADDR you still cannot create a connection whose identical
4-tuple is in the 2MSL wait.  (Of course, there's a BSD-exception to
this rule also: you can override the 2MSL wait if a SYN arrives for
that port and the sequence number is "greater than" the ending sequence
number for the previous incarnation of the connection.)

This is all explained (with copious examples) in my new book, "TCP/IP
Illustrated" (Addison-Wesley) that'll be out in December.

	Rich Stevens  (rstevens@noao.edu)

-----------[000469][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 1993 00:15:51 GMT
From:      fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: Problem with XDR server and client

Brian Button writes:
>I'm having a heck of a time getting a simple piece of XDR code to work

I know this is going to sound like a silly question, 
but why don't you just add something like this to
the end of str.x, run rpcgen, and then just call the 
remote procedure calls, like in the rpc manual?

program NAVPROG {
        version NAVVERS_ORIG {
                void
                NAVPROC_STATS(struct NavUVLocation) = 1;
        } = 1;
} = 999999;

Brian

-----------[000470][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Sep 1993 02:06:38 GMT
From:      folta@netcom.com (Steve Folta)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip
Subject:   Re: Gigabit Networking book out

How much will it cost?

-- 
Steve Folta
folta@holonet.net (finger for PGP key)

-----------[000471][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Sep 93 04:13:53 GMT
From:      minich@a.cs.okstate.edu (Robert J Minich)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: Residence Hall Networking

>                                 By the end of the 4 hours 80% of the
> freshmen had sent or received email. AppleTalk really is plug and play.
> 
> Stan Dunten, Dartmouth College (Stan Dunten@Dartmouth.edu)

For Macs it certainly is. Of course, AppleTalk has its ugly warts as
well, but the ease for end users is certainly a model to build on. Now,
if Apple could/would fix those, I'd be a very happy camper.
-- 
Robert Minich
minich@a.cs.okstate.edu   | "Maybe awake is what's left at the end
Oklahoma State University |  of dreaming"

-----------[000472][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Sep 1993 09:06:46 GMT
From:      agiraud@hpgnux65.grenoble.hp.com (Armand Giraud)
To:        comp.protocols.tcp-ip
Subject:   Re: Bizarre Network Problem

Hi,

Are you experiencing a broadcast storm ? trigered by ...?

just a hint

Armand


--

	 /\    Armand Giraud    /\/\    Telnet:  779-1416
  /\    /  \                 /\/ /  \   non-TN:  (+33) 76 62 14 16
 /  \/\/    \  CNS-E        /  \/    \  Fax:     (+33) 76 62 17 70
/    \ \     \_GRENOBLE____/    \     \_e-mail:  Armand_Giraud@grenoble.hp.com
               HEWLETT PACKARD	        HPDESK:  Armand Giraud/HP6300

-----------[000473][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Sep 1993 13:09:19 GMT
From:      jims@fiu.edu (Jim Schenk)
To:        comp.protocols.tcp-ip
Subject:   FAQ ?

Is there a FAQ for this list?

Thanks,

Jim Schenk     jims@servax.fiu.edu

-----------[000474][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Sep 1993 14:46:07 GMT
From:      smb@cc.purdue.edu (Scott M. Ballew)
To:        comp.protocols.tcp-ip
Subject:   Re: SunOS socket weirdity/question

In article <1993Sep28.031850.12685@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes:
>... However the network socket
>stays active and accepting connections, even after the parent is dead.
>Only if I kill the child does all become normal. I compile the
>program, type a.out 3333, type telnet localhost 3333, close the telnet
>connection, and port 3333 is still active. But the parent is dead
>(exit()), and the child had closed the network socket!
>
>	Please tell me what is going on, it is getting to be quite a
>mystery. Is it because I haven't set SO_LINGER or some other socket
>option?

No, the client never closes lsock (the listen socket) so it is still
listening on port 3333 (in your example) for new connections.
accept() gives you a _new_ socket connected to the local port.

Scott M. Ballew
Purdue Data Network

-----------[000475][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 93 20:03:19
From:      drw@zermelo.mit.edu (Dale R. Worley)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip
Subject:   New IP protocol?

It seems that there are several sorts of data streams like real-time
video and audio that have the properties:
	- tight timing requirements
	- resistance to loss of individual packets
Clearly, TCP is a poor protocol for transporting this sort of data.
Has anybody considered building a new protocol (on top of IP) that
would work well for this sort of data stream?

(Conveniently, such a protocol would map onto ATM quite nicely.)

Dale

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
I'd rather laugh with the sinners than cry with the saints!
-- "Only the Good Die Young" by Billy Joel

-----------[000476][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Sep 1993 15:18:25 GMT
From:      jimc@jts.com (Jim Carroll )
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Searching for WAN simulator 'black box'

Greetings, all!

We are a software manufacturer.  Our product is document imaging &
workflow automation.  We're looking for a solution which will allow us 
to simulate a WAN of varying distances over a minimum of 56 kbps speed,
so that we can address application problems in this environment.

So far, we've only managed to come up with the following combination:

2 routers (Ethernet <-> 56 kbps (and up))
Analog 'black box' (capable of simulating analog wiring of varying
	distances, as well as being able to inject various noise, etc.)

This is all well and good, but we don't really need to simulate huge
distances between routers/repeaters/whatever, we need to be able to
also simulate 'real world' WANs, e.g., Toronto - Montreal, New York - Tokyo,
complete with propagation delays and latency normally associated with
large distances and varying numbers of routers.  The ability to add in
the analog variances as above would be nice to have, too.

A trivial test case would involve 2 Suns on separate Ethernet segments,
which are in turn connected to a router (each), with the black box
connecting the two routers at the serial interface.

Suggestions for an appropriate solution would be most welcome.
(Vendor name/address/phone/fax/e-mail address, etc.)

Please reply directly (I'll summarize) to jimc@jts.com.
-- 
Jim Carroll   | If Jim Morrison drove his van to Van Morrison's gym,
jimc@jts.com  | would Don Johnson use the john in Van Johnson's van?
              |   - Charles Fleischer

-----------[000477][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Sep 1993 16:52:53 GMT
From:      dcc@scitor.com (Dennis Coyle)
To:        comp.protocols.tcp-ip
Subject:   Subnet address of all zeros??

I looked at D. Comer's book and RFC950, but I am still not sure if you can
have a subnet address of all zeros. Given the following IP address and Subnet 
mask:
	Class B Address: 149.64.0.0
	Subnet Mask: FF.FF.F8.00 (i.e. 255.255.248.0)

I am reserving 5 bits for subnet addressing and 10 bits for hostids. In most of
the examples, it is stated that the first available subnet would have an
IP address of 149.64.8.X.  My question is what happens if you have an
IP address of say 149.64.1.1 ? Is it mapped into subnet 0 hostid 257?
(i.e., see example below)

  255.255.248.0 => FF.FF.F8.00 (Subnet mask)
  149.64.1.1 =>    95.40.01.01 (IP address)
                   95.40.00.00 => 149.64.0.0 & hostid of 257 ??

My confusion stems from the fact that some of the examples state that a 
5-bit subnet address field will yield 32 physical subnets, but RFC940 states
that "...subnets of all zeros and all ones in the subnet field should not be
assigned to actual (physical) subnets". I understand why you wouldn't
what all 1's, but I do not understand the all 0's.

P.S. Excuse my ignorance, but this is all new stuff for me. Also, I'm not
a regular reader of the group so I would appreciate direct mail. Howerver,
I wll post a summary of the answers.

Thanks in advance







-----------[000478][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Sep 1993 19:22:54 GMT
From:      mohacsi@fsz.bme.hu ( Janos Mohacsi)
To:        rec.radio.amateur.packet,comp.protocols.tcp-ip
Subject:   Which version of KA9Q should I use ?


I have been working on a new service for KA9Q. I started to work with KA9Q
Version 911218. Which KA9Q or NOS should I use if I don't want to lose my work.
Which recent version of the KA9Q is most compatible that old KA9Q and hopefully
less buggy?

Thanks!
	John Mohacsi



-----------[000479][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 93 20:40:25 GMT
From:      chougaby@autan.enst.fr (Gaby Choucrallah)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip
Subject:   Re: Gigabit Networking book out

Craig Partridge (craigp@world.std.com) wrote:
: Several folks have asked me when my book on Gigabit Networking would be
: in print.  The answer is Friday, Oct 1.  It's from Addison Wesley (ISBN
: 0-201-56333-9).  Table of concents is appended for anyone interested.
 
: Craig
 
: 		Contents of Gigabit Networking
 
: Preface                                 			xi
 
: 1. An Introduction to Gigabit Networking
:    1.1 Change in the Wind                			 1
:    1.2 What is Changing?                    			 3
:    1.3 Rules of the Road                    			 8
:    1.4 What Follows this Chapter           			12
 
: 2. Fiber Optics
:    2.1 Introduction                     			15
:    2.2 Essentials of Fiber Optics          			15
:    2.3 Transmitters and Receivers          			25
:    2.4  An  Example  of  Fiber  Optic  Signalling: SONET 	28
:    2.5 Another Example: WDM Networks       			34
:    2.6 Other Media                         			40
:    2.7 Summary                             			41
 
: 3. An Introduction to Cell Networking
:    3.1 Introduction                     			43
:    3.2 What Is a Cell?                     			43
:    3.3 Fragmenting Data into Cells         			47
:    3.4 Why Cells?                          			48
:    3.5 Cell Routing                        			51
:    3.6 Adaptation Layer Protocols          			53
:    3.7 Cell Error Recovery                 			56
:    3.8 Summary                             			59
 
: 4. Asynchronous Transfer Mode
:    4.1 Introduction                     			61
:    4.2 ATM Inside the Telephone Networks   			62
:    4.3 ATM Conceptual Model                			63
:    4.4 ATM Cell Format                     			65
:    4.5 ATM Cell Header at the NNI          			65
:    4.6 ATM at the User-Network Interface   			69
:    4.7 Adaptation Layers                   			71
:    4.8 Signalling an ATM Connection        			82
:    4.9 Putting the ATM Bits on the Wire    			83
:    4.10 Issues in ATM                      			84
:    4.11 Summary                            			87
 
: 5. Wide Area Cell Networking
:    5.1 Introduction                     			89
:    5.2 Blocking                            			90
:    5.3 The Canonical Cell Switch           			90
:    5.4 Buffering Strategies                			92
:    5.5 Crossbar Switches                  			100
:    5.6 Batcher-Banyan Switches            			110
:    5.7 Input Buffering Revisited          			123
:    5.8 An Optical Cell Switch             			125
:    5.9 The Cost of Port Controllers       			127
:    5.10 Summary                           			127
 
: 6. Local Area Cell Networks
:    6.1 Introduction                    				129
:    6.2 Shared Media Cell Networks         			130
:    6.3 Local Area Switching Technologies  			147
:    6.4 Summary                            			151
 
: 7. Gigabit Packet Networks
:    7.1 Issues in Packet Network Design	 			153
:    7.2 Local Area Packet Technologies     			154
:    7.3 Wide Area Packet Technologies      			163
:    7.4 Summary                            			172
 
: 8. Gigabit Applications
:    8.1 Introduction    	                			175
:    8.2 Classic Applications               			175
:    8.3 New Applications                   			176
:    8.4 New Computing Applications         			177
:    8.5 Applications with Humans in the Loop			178
:    8.6 The Impact of New Applications     			190
:    8.7 Summary                            			193
 
: 9. Making Hosts Ready for Gigabit Networks
:    9.1 Introduction	                    			195
:    9.2 The Model Machine                  			196
:    9.3 The Costs of Moving Data           			196
:    9.4 Reducing Memory Copy Costs         			202
:    9.5 Other Processor-Memory Interactions			207
:    9.6 Multiprocessor Architectures       			210
:    9.7 What about Cells?                  			213
:    9.8 A Summary of System Performance Issues			216
:    9.9 Support for Real-Time Applications 			217
:    9.10 Summary                           			222
 
: 10. Today's Internetworking Protocols
:    10.1 Internetworking                				225
:    10.2 Gigabit Speeds and Today's Protocols			226
:    10.3 Architecture of TCP/IP            			227
:    10.4 Techniques for Going Fast         			230
:    10.5 Limitations of Today's Protocols  			241
:    10.6 Converging on the Shape of Gigabit Protocols		248
:    10.7 Summary                           			250
 
: 11. Traffic Shaping
:    11.1 Introduction	                   			253
:    11.2 Why Shape Traffic?                			253
:    11.3 Isochronous Shaping               			255
:    11.4   Isochronous Shaping with Priority Schemes		258
:    11.5 Shaping Bursty Traffic Patterns   			260
:    11.6 Summary                           			263
 
: 12. Performance Guarantees
:    12.1 Introduction           	        			265
:    12.2 Terminology and Issues            			266
:    12.3 Statistical Multiplexing          			269
:    12.4 Weighted Fair Queueing            			276
:    12.5 Jitter Control Schemes            			280
:    12.6 Statistical Multiplexing Revisited			285
:    12.7 Summary                           			286
 
: 13. Flow Setup and Routing
:    13.1 Remaining Problems	             			289
:    13.2 The Host's Role in Flow Setup     			290
:    13.3 Protocols to Establish a Flow     			293
:    13.4 Routing                           			305
:    13.5 Summary                           			309
 
: 14. Distributed Systems
:    14.1 Introduction                   				311
:    14.2 Distributed Systems Today         			312
:    14.3 Alternative Approaches to Distributed Systems		320
:    14.4 Enhancing Distributed Services    			330
:    14.5 Authentication                    			337
:    14.6 Summary                           			339
 
: 15. The State of Gigabit Networking
:    15.1 Introduction   	                			341
:    15.2 Putting the Pieces Together       			341
:    15.3 Lingering Problems                			342
:    15.4 Unaddressed Problems              			344
:    15.5 After Gigabits, Terabits?         			345
:    15.6 Final Thoughts                    			346
 
: 16. Where to Learn More
:    16.1 Introduction  	                 			347
:    16.2 Testbeds and Research Programs    			347
:    16.3 Conferences and Journals          			357
:    16.4 Getting Items in the Bibliography 			360
 
: Bibliography                           				361
: Index                                  				389

-----------[000480][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Sep 1993 21:17:00 GMT
From:      adcad@zeus.datasrv.co.il (Ad-cad)
To:        comp.protocols.tcp-ip
Subject:   Bidirectional RPC usage

Hi TCP gurus,
I am interested to use the RPC technology in an application where the 'Server'
sometimes initiates calls to a client (in this sense it is not a 'pure'
server). I have one such 'server', where clients may connect themselves
and request services. Some services are 'callback' services, where the
server asinchronously notifies the client with new data.
Does it make sense to use RPC here ?
Currently I'm using a home-made 'transport' based on TCP/Berkley Sockets.
We would be glad to get rid of this low-level TCP based communication.
Any suggestions ? Experiences ?

Eran.

-----------[000481][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 1993 00:01:04 GMT
From:      crohrer@advtech.uswest.com ( Chris Rohrer)
To:        comp.protocols.tcp-ip
Subject:   Specifying IP

Never having tried to hook up two IP devices or (even worse) networks
together I need to know just how you go about specifying everything you
have to do to have a set of rules for a well-behaved network.  Not
necessarily (only) from a physical point of view, but definitely from a
logical point of view, how do you pick the relevant protocol parameters, their
settings and whatever else you have to specify?  Can I just say "Oh, we'll
just put in an Ethernet and use the TCP/IP protocol suite over it" and use
all the "default" settings out of the box, as it were?  Are there
well-known "typical or default" values for various items?  For example,
can/must I specify the following as an absolute minimum:

MTU size
Version number
Use of other header fields
Use of optional fields
Use of address resolution mechanism(s)

And many more items at other layers too--You get the picture.

Do rfc985 "Requirements for Internet Gateways", rfc1122 "Requirements for
Internet Hosts -- Communication Layers" have this information or checklists
or profiles for such purposes?  Or must I just "know" how everything is to
work, find the relevant rfc's and supporting documentation and have at
writing the rules (and/or hire an IP networking specialist).

Like if I were to write an "interface specification" to my IP network, what
items would I absolutely have to specify (ignoring for the moment the
actual applications and their requirements...)?

Please be gentle in your responding

Chris

-----------[000482][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 1993 01:00:20 GMT
From:      910536m@dragon.acadiau.ca (David W. Murphy)
To:        comp.protocols.tcp-ip
Subject:   tcp-ip over serial connection

  Howdy. I was wondering if there was any way to run tcp-ip over
a serial connection, i.e. modem, but not a slip connection.
 The reason I ask is that our school only has 1 slip line at any one time
and I would like to emulate a slip connection or simply utilize a tcp-ip
connection through my modem

  any takers?

 Email me.
  Thanks


-----------[000483][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 93 08:56:42 EST
From:      green@ids.net
To:        comp.protocols.tcp-ip
Subject:   Text Descriptions with FTP's "ls" command

I'm hoping this is somewhat related to this group :-)  I was wondering if
anyone could point me out to the programs I can set in my Anonymous FTP
processes (on our server) that alters the output of the LS command in such a
way that it lists text descriptions along with files.  I remember hearing about
it a while ago - it was something along the lines of a program that was used to
keep an index of the files with their text descriptions, and then another
program used in place of "ls" that would display the file and the text
description - made for a very useful FTP server mod.  Any ideas, anyone?

Andy, green@ids.net

-----------[000484][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 1993 04:41:56 GMT
From:      earlf@netcom.com (Earl Ferguson)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip
Subject:   Re: New IP protocol?

In article <DRW.93Sep29200319@zermelo.mit.edu> drw@zermelo.mit.edu (Dale R. Worley) writes:
>It seems that there are several sorts of data streams like real-time
>video and audio that have the properties:
>	- tight timing requirements
>	- resistance to loss of individual packets
>Clearly, TCP is a poor protocol for transporting this sort of data.
>Has anybody considered building a new protocol (on top of IP) that
>would work well for this sort of data stream?
>
>(Conveniently, such a protocol would map onto ATM quite nicely.)

Look at rfc1045 for one possibility.

Also the Audio - Visual task force (avt) RTP seems a likely candidate.
There are several drafts related to the avt work, I have listed only the
latest versions below as taken from the ftp.nisc.sri.com internet-drafts
directory:
	draft-ietf-avt-encodings-02.txt
	draft-ietf-avt-issues-00.txt
	draft-ietf-avt-profile-02.txt
	draft-ietf-avt-rtp-03.txt - this is the actual protocol spec
	draft-ietf-avt-video-packet-01.txt

Earl

-----------[000485][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 1993 09:45:16
From:      andyj@letterbox.rl.ac.uk (Andrew Jessett)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   PCNFSD for VMS/UCX anyone?

Does anyone know the whereabouts of a version of PCNFSD authentication server 
for VMS running UCX.

TIA
          Andrew Jessett

-----------[000486][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 93 05:21:15 GMT
From:      jdn8@encon.pge.com (Jeff Newmiller)
To:        comp.protocols.tcp-ip
Subject:   PC routing software?

Has anyone tried to write a simple router for a PC that could
handle a small (class C) leaf subnetwork?  There is a Cisco
router for the next hop...

Please email me if this is a FAQ or just hopelessly silly.

--
Jeff Newmiller --- JDN8%Proj%RnD@rnd.esb.pge.com

-----------[000487][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 93 05:22:30 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: SunOS socket weirdity/question

Thanks to all those that replied. I forgot to close the daemon listening 
socket (lsock in the example), when I forked off the child. I guess that 
sorta thing happens when you are trying to debug code too late at night. ;)



-----------[000488][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 93 05:27:46 GMT
From:      jdn8@encon.pge.com (Jeff Newmiller)
To:        comp.protocols.tcp-ip
Subject:   Telnet def.port works, other doesn't

I have been trying to connect to a remote game server using
   telnet host.domain 6969
and receiving "Host not reachable" error. However,
   telnet host.domain
works just fine.  Ideas? Is this kind of connection subject
to some kind of routing interference (seems odd)? Bug in
my telnet (Sun workstation) misidentifying the error?

--
Jeff Newmiller --- JDN8%Proj%RnD@rnd.esb.pge.com

-----------[000489][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 1993 06:00:13 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet def.port works, other doesn't

In article <2032@news01.pge.com> jdn8@encon.pge.com (Jeff Newmiller) writes:
    I have been trying to connect to a remote game server using
       telnet host.domain 6969
    and receiving "Host not reachable" error. However,
       telnet host.domain
    works just fine.  Ideas? Is this kind of connection subject
    to some kind of routing interference (seems odd)? Bug in
    my telnet (Sun workstation) misidentifying the error?
    
Most likely, there is a security firewall that is blocking that particular
TCP port number.

Tony


-----------[000490][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 1993 08:46:26 GMT
From:      antonis@intranet.gr (Antonis Kyriazis)
To:        comp.protocols.tcp-ip
Subject:   Point-to-Point ip addressing

A question:

Is  it right to set up a point-to-point connection with different
ip addresses like this: 

146.124.14.200 <-> 146.124.100.91 ?

I'd like to hear your comments.

Thank you
+-------------------------------------------------------------------+
|     Antonis Kyriazis                                              |
| Networks & Communications       e-mail: antonis@intranet.gr       |
| INTRACOM sa                                                       |
| 19.5 km Marcopoulo Ave.          fax:   +30-1- 66 44 379          |
| Peania 190 02                           +30-1- 66 43 718          |
| GREECE                          phone:  +30-1- 66 44 961-5        |
|                                         +30-1- 88 43 715          |
| "The expressed opinions are of my own"   + - MACEDONIA IS GREEK - +
+-------------------------------------------------------------------+


-----------[000491][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 1993 10:10:00 GMT
From:      sarkies@ltisun8.epfl.ch (Professeur)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip
Subject:   Re: New IP protocol?

In article <DRW.93Sep29200319@zermelo.mit.edu>, drw@zermelo.mit.edu (Dale R. Worley) writes:
|> It seems that there are several sorts of data streams like real-time
|> video and audio that have the properties:
|> 	- tight timing requirements
|> 	- resistance to loss of individual packets
|> Clearly, TCP is a poor protocol for transporting this sort of data.
|> Has anybody considered building a new protocol (on top of IP) that
|> would work well for this sort of data stream?
|> 
|> (Conveniently, such a protocol would map onto ATM quite nicely.)
|> 
|> Dale


Is it necessary to build such a protocol onto IP? Why not keep it separate?
Is there much more required than that given in the AAL protocols which
separate the four major classes of traffic defined by the standards people?
It seems to me that the idea of complete sharing of network resources by
all traffic, which appeared to be the dream of the early proponents of BISDN,
is becoming less reasonable because of the major differences between real
time stream traffic and highly bursty data traffic. Thus an ATM network
may need to be partitioned in some way to protect the various traffic types from
the adverse effects of coexistence with certain other types.
-- 

Ken Sarkies

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Sauve qui peut, la Grande Panique,
Rien n'est simple, tout se complique.
- Sempe
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

|> 
|> Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
|> --
|> I'd rather laugh with the sinners than cry with the saints!
|> -- "Only the Good Die Young" by Billy Joel

We know why the sinners laugh, but why do the saints cry? Do they know something
that the sinners don't?

-----------[000492][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 1993 10:38:23 GMT
From:      Alain Struyf <astruyf@UB.com>
To:        comp.protocols.tcp-ip
Subject:   Re: Class C subnetting

In article <znr749222444k@nlbbs.com> David Pratt, dpratt@nlbbs.com writes:
> We have a new class C Internet number at our school... How do I go about
> subnetting this and why would I want to...

RFC1219 (On the assignement of subnetnumbers) could be a good start for
you. However, on the why you would want to subnet a class C...

Alain.

-----------[000493][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 1993 12:08:47 GMT
From:      klos@mv.mv.com (Patrick Klos)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address of all zeros??

In article <1993Sep29.165253.9380@scitor.com>,
Dennis Coyle <dcc@scitor.com> wrote:
>I looked at D. Comer's book and RFC950, but I am still not sure if you can
>have a subnet address of all zeros. Given the following IP address and Subnet 
>mask:
>	Class B Address: 149.64.0.0
>	Subnet Mask: FF.FF.F8.00 (i.e. 255.255.248.0)
>
>I am reserving 5 bits for subnet addressing and 10 bits for hostids. In most of
>the examples, it is stated that the first available subnet would have an
>IP address of 149.64.8.X.  My question is what happens if you have an
>IP address of say 149.64.1.1 ? Is it mapped into subnet 0 hostid 257?
>(i.e., see example below)
>
>  255.255.248.0 => FF.FF.F8.00 (Subnet mask)
>  149.64.1.1 =>    95.40.01.01 (IP address)
>                   95.40.00.00 => 149.64.0.0 & hostid of 257 ??
>
>My confusion stems from the fact that some of the examples state that a 
>5-bit subnet address field will yield 32 physical subnets, but RFC940 states
>that "...subnets of all zeros and all ones in the subnet field should not be
>assigned to actual (physical) subnets". I understand why you wouldn't
>what all 1's, but I do not understand the all 0's.
>
>P.S. Excuse my ignorance, but this is all new stuff for me. Also, I'm not
>a regular reader of the group so I would appreciate direct mail. Howerver,
>I wll post a summary of the answers.
>
>Thanks in advance

Technically speaking, a subnet number of zero means "this" subnet.  Say your
address is 149.64.129.1 with your current subnet mask (5 bits).  Then if you
were to use 149.64.0.5, where the 5 subnet bits were all zeros, you would
technically be asking for 149.64.128.5 because you'd be looking for "node" 5
on "this" (or your) subnet.  I know Comer's book defines the notion of "this"
in his book, because that's where I learned about it.  Just like "all 1's"
in a subnet means "broadcast", "all 0's" should be interpreted as "this".

Patrick
-- 
============================================================================
    Patrick Klos                           Internet: klos@mv.mv.com
    Klos Technologies, Inc.                Voice: (603) 424-8300
    604 Daniel Webster Highway             FAX:   (603) 424-9300
    Merrimack, New Hampshire  03054        BBS:   (603) 429-0032
============================================================================

-----------[000494][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 93 12:21:41 GMT
From:      benedic@nrccsb6.di.nrc.ca (James Benedict)
To:        comp.protocols.tcp-ip
Subject:   Packets lost between PC and X


I have a 486 connetced to an X server.  Everything was working fine until
two weeks ago, then the following problem started:

Whenever the user tries to run a program called xmgr (graphics program),
it works fine for a while, and then crashes with Xlib reporting the
following types of errors "Xlib:  sequence lost (0xXXXXX > 0xXXXX) in relpy
type 0xXX!)"

It seems fairly likely that too many packets are being lost or something like
that.  The funny part is, if xmgr is started in the background, the program
will run alot longer before crashing.

Anyone have any ideas where the problem might lie?

Please email any replies, thanx

James A Benedic (benedic@nrccsb6.di.nrc.ca)

Other possibly helpfull information:

Transport:  FTP's PC/TCP for DOS/Windows version 2.11
X Emulator: HCL eXceed/W  (Windows 3.1)
EtherNet Card:  don't know yet, but I can find out if it's important.

PS:  There are many other machines on Campus that CAN run the same program
     with the same configuration.

PPS:  I'm also cross-posting this to the X newsgroups, but I thought someone here
      might have encountered the same problem before.

-----------[000495][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 1993 13:31:48 GMT
From:      bondt@dutiws.twi.tudelft.nl (Piet de Bondt)
To:        comp.protocols.tcp-ip
Subject:   Re: FAQ ?

Sorry to post this here. Just want to make all clear for the new ones.

In article <CE49vJ.E66@fiu.edu>, Jim Schenk <jims@fiu.edu> wrote:
>Is there a FAQ for this list?
>

Yes, of course, almost every important group has a FAQ.
It is posted here (at regular intervals).
Subscribe to news.answers and you'll get all the FAQ you've (n)ever
wanted to know about.

>Thanks,
>
You're welcome.

>Jim Schenk     jims@servax.fiu.edu

-----------[000496][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 1993 14:02:13 GMT
From:      mark@scot1.ucsalf.ac.uk (Mark Powell)
To:        comp.unix.sys5.r4,comp.unix.pc-clone.32bit,comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Dell v2.2 <-> SunOS 4.1.3 NIS set-up problems

Hi,
  I have a Dell v2.2 SVR4 machine running the primary DNS for our domain
ucsalf.ac.uk. I want to set-up NIS to get selected passwd entries
from the already established NIS system running on a network of Suns
here. I've set my machine's RPC domainname to the same as the Suns are
using but ypbind fails to bind. The Suns are all on a differnet class
C network from the Dell machine, separated by a cisco router.
  On looking through the Sun NIS stuff I find the following, seemingly,
contradictory info:

	an RPC domain can cover machines over different sub-nets

	because RPC broadcast messages (used by ypbind) are not
	routed further than a subnet there must be an NIS server
	on the same subnet as the client wishing to bind

	"domain servers may exist through different sub-nets since domain
	map propagation works across sub-net boundaries"

Seems okay.... It would seem I need to set up the Dell machine as a 
slave server (to fulfill the condition that there must be an NIS server
on a subnet for clients on that subnet to bind.) However, the setting
up requires, first the starting of ypbind and then running ypinit.
Problem, how can the ypbind work without the server? Seems like a
chicken and egg. The sun manual only documents one solution of having
a machine which is connected to both subnets run the NIS server.
I *can* 'rpc' files onto and off of the Sun that is the master NIS
server, so what's up?
Anybody help here. Any input from anyone successfully getting NIS running
under Dell would be appreciated (just to assure me it works okay.)
Thanks in advance.

-- 
Mark Powell

mark@scot1.ucsalf.ac.uk		mark%scot1.ucsalf.ac.uk@nsfnet-relay.ac.uk
Work:	+44 61 745 3207		Home:	+44 61 737 3812

-----------[000497][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 93 14:58:26 GMT
From:      radha@yrloc.ipsa.reuter.COM (radha)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   SLIP

Where do i get information about installing SLIP in sun
systems?





-----------[000498][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 1993 15:00:11 GMT
From:      ccaajac@ucl.ac.uk (Jon Crowcroft)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip
Subject:   Re: New IP protocol?

In article <28eb9o$b1f@disuns2.epfl.ch>, sarkies@ltisun8.epfl.ch (Professeur) writes:
|> In article <DRW.93Sep29200319@zermelo.mit.edu>, drw@zermelo.mit.edu (Dale R. Worley) writes:
|> |> It seems that there are several sorts of data streams like real-time
|> |> video and audio that have the properties:
|> |> 	- tight timing requirements
|> |> 	- resistance to loss of individual packets
|> |> Clearly, TCP is a poor protocol for transporting this sort of data.
 ........
|> may need to be partitioned in some way to protect the various traffic types from
|> the adverse effects of coexistence with certain other types.


multiservice networks need quarantining or partitioning of different traffic types
whther data versus 'real-time'

public nets also need it so you can build virtual private networks

a lot of work on next generation IP includes concepts of link sharing (a form of VPN)
as well as supporting traffic which must needs be treated differently, in the context
of starting with bursty (traffic that needs big buffers in switches) and adding
less bursty (CBR video, or voice) (not to get into a debate about whether VBR
video is bursty...)

this is in contrast to the bulk of published work on aTM which starts with
supporting policed (leaky bucket sources) and has only recently added some
work on adding really bursty sources...

the sooner the communities absorb each others expertise, the sooner we'll get
a true multiservice (one stop shopping) network

note, it isnt exactly difficult when designing switches to add very very large buffers for 
flows that need it, or hard to use...

a delay variation of seconds would be tolerable for a large FTP, so long as the rate of
 change of delay wasnt too high...w.r.t rtt...


-- 
jon crowcroft (hmmm...)

-----------[000499][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 1993 15:13:28 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Text Descriptions with FTP's "ls" command

In article <1993Sep30.085642.1@ids.net> green@ids.net writes:
}I'm hoping this is somewhat related to this group :-)  I was wondering if
}anyone could point me out to the programs I can set in my Anonymous FTP
}processes (on our server) that alters the output of the LS command in such a
}way that it lists text descriptions along with files.  I remember hearing about
}it a while ago - it was something along the lines of a program that was used to
}keep an index of the files with their text descriptions, and then another
}program used in place of "ls" that would display the file and the text
}description - made for a very useful FTP server mod.  Any ideas, anyone?

This would be a *really* bad idea.  In ftp clients that I have seen,
the user command "ls" sends the internal FTP command NLIST.
Here is what RFC959 (the FTP standard) says:

         NAME LIST (NLST)
 
            This command causes a directory listing to be sent from
            server to user site.  The pathname should specify a
            directory or other system-specific file group descriptor; a
            null argument implies the current directory.  The server
            will return a stream of names of files and no other
            information.  The data will be transferred in ASCII or
            EBCDIC type over the data connection as valid pathname
            strings separated by <CRLF> or <NL>.  (Again the user must
            ensure that the TYPE is correct.)  This command is intended
            to return information that can be used by a program to
            further process the files automatically.  For example, in
            the implementation of a "multiple get" function.

It is only valid to return a list of pathnames (actually most Unix
FTP server daemons are in violation of this, since they are lazy
and use the "/bin/ls" command to do this and it does stuff like:

ftp> ls p*
private:
Makefile
vers.c

public:
isu-ethics
larn-scores
puzzle

On the other hand, the ftp user command "dir" usually results in the
FTP command of LIST:

         LIST (LIST)
 
            This command causes a list to be sent from the server to the
            passive DTP.  If the pathname specifies a directory or other
            group of files, the server should transfer a list of files
            in the specified directory.  If the pathname specifies a
            file then the server should send current information on the
            file.  A null argument implies the user's current working or
            default directory.  The data transfer is over the data
            connection in type ASCII or type EBCDIC.  (The user must
            ensure that the TYPE is appropriately ASCII or EBCDIC).
            Since the information on a file may vary widely from system
            to system, this information may be hard to use automatically
            in a program, but may be quite useful to a human user.

You can return pretty much whatever suits your fancy here (most
Unix-based FTP server daemons just do "/bin/ls -lg").

John
PS, I really love how programs like NcFTP send junk like:

    NLST -FC file

assuming that all (unix) LIST/NLSTs are ls-based...   (*sigh*)

226 Huh, huh, huh, like no files named "-FC file" here dude, huh, huh, huh  :)
-- 
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

-----------[000500][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 93 15:27:13 GMT
From:      dburke@icarus.lis.pitt.edu (Doug Burke)
To:        comp.protocols.tcp-ip
Subject:   libftp libraries on a sun4


Hi.  I am trying to get the "libftp" ftp libraries up and running on our
Sun4/360 machine running SunOS 4.1.3 but keep getting core dumps when
trying to run the sample application.  It seems to be core dumping when
trying to use the hostname passed to the FtpConnect function.  The
"libftp" software was posted to this newsgroup sometime last July.

Has anyone had success with these libraries on their Sun machines?  I am
using GCC 2.4.5.  Thanks in advance for any information.  Email responses
and I'll post if there's interest.

Thanks and cheers,


-----------[000501][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 1993 15:29:37 GMT
From:      pconrad@mercury.cis.udel.edu (Phill Conrad)
To:        comp.protocols.tcp-ip
Subject:   Writing a new TCP/IP based on raw sockets on Sun4 (OS 4.1.3)

(Sorry if this is a duplicate; my posts seem to be going to a black hole).

I am currently tasked with implementing a version of TCP on top of the
raw socket interface to the BSD implementation of IP.  In my case, I
happen to be running on a Sun 4, running Sun OS 4.1.3.

According to my copy of the Sun "Network Programming Guide", this is a
typical and reasonable thing to do:`

   "... For example, a new version of TCP might be developed at the
   user level by utilizing a raw IP socket for delivery of packets. 
   The raw socket interface attempts to provide an identical interface
   to the one a protocol would have if it were resident in the kernel." 
			(p. 341, section 12.7, "Raw Sockets")
	
The purpose for doing this is to have an implementation of TCP that we
can "play" with to do some networking research into new approaches in
transport level protocols.

Questions:  

   1) Has anybody else already done this?  If so are you willing to share your
      code, or if not that, than your experiences?

      Even if your code/experiences are NOT Sun, as long as its based
      on the BSD Network architecture it would be useful, even if only
      for comparison purposes.

   2) Can anybody provide some helpful clues?

I'm stuck at this point: I have the source code to the implementation of TCP
that resides in the kernel.  Now this TCP communicates with the IP layer
via the "protosw" structure, passing "mbufs" back and forth.   My version
needs to communicate with TCP via a raw_socket interface.   It seems that
these are fundamentally different interfaces, very far from the statement
above that the raw socket attempts to provide an "identical interface"...

I also am having trouble writing a user program that has access to the 
manipulating mbuf's.  Is this an operation that is reserved for the kernel?
If so, then I will have to rewrite the TCP code that I have to NOT use
mbufs (a rather difficult task.)

Those who are familiar with raw_sockets, protosw's and mbufs; can you help
me sort this out?

(Follow-up's to comp.protocols.tcp-ip)




-- 
--Phill Conrad					      pconrad@cis.udel.edu
--Ph. D. Student -- Dept. of Computer and Info. Science -- Univ. of Delaware


-- 
--Phill Conrad					      pconrad@cis.udel.edu
--Ph. D. Student -- Dept. of Computer and Info. Science -- Univ. of Delaware

-----------[000502][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 1993 16:20:20 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip
Subject:   Re: New IP protocol?

In article <DRW.93Sep29200319@zermelo.mit.edu> drw@zermelo.mit.edu (Dale R. Worley) writes:

>It seems that there are several sorts of data streams like real-time
>video and audio that have the properties:
>	- tight timing requirements
>	- resistance to loss of individual packets
>Clearly, TCP is a poor protocol for transporting this sort of data.
>Has anybody considered building a new protocol (on top of IP) that
>would work well for this sort of data stream?

The Internet currently moves real-time audio/video/whiteboard data
around quite nicely using UDP/IP Multicast.  In practice, one does not
need the properties that you describe, at least not to the degree you
claim.  The MBONE is an existance proof that it is not so.  You might
also want to look into the work of the IETF's avt working group.

>(Conveniently, such a protocol would map onto ATM quite nicely.)

ATM has serious problems with cell loss due to switch congestion, so
it isn't clear that ATM is a big win -- if your second property above
really is important to you.


-----------[000503][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 1993 16:23:39 GMT
From:      msells@undergrad.math.uwaterloo.ca (Marty Sells)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip
Subject:   Re: New IP protocol?

>|> In article <DRW.93Sep29200319@zermelo.mit.edu>, drw@zermelo.mit.edu (Dale R. Worley) writes:
>|> |> It seems that there are several sorts of data streams like real-time
>|> |> video and audio that have the properties:
>|> |> 	- tight timing requirements
>|> |> 	- resistance to loss of individual packets
>|> |> Clearly, TCP is a poor protocol for transporting this sort of data.
 ........
>|> may need to be partitioned in some way to protect the various traffic types from
>|> the adverse effects of coexistence with certain other types.

See RFC1190 - Experimental Internet Stream Protocol (ST-II).
ST-II was designed since IP did not provide the delay and data
rate to support voice applications. ST is at the same level
as IP. ST-II has been used for point-to-point voice and video.

Full implementation details (for a Sun) are available on
clynn.bbn.com as pub/STII_SOURCE.Z I haven't tried this on a Sun
but am trying (no luck!) to somehow get it running on a SCO box.
If anybody knows how to send out IP packets from a SCO box with
the IP version set to 5, in fact, I need to be able to generate
the entire IP header myself, something that SCOKET_RAW doesn't
provide. Maybe /etc/rip and /etc/ip... Anybody???

Marty
P.S. If you get involved in STII please keep in touch.

-----------[000504][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 1993 16:24:37 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Writing a new TCP/IP based on raw sockets on Sun4 (OS 4.1.3)

>I am currently tasked with implementing a version of TCP on top of the
>raw socket interface to the BSD implementation of IP.  In my case, I
>happen to be running on a Sun 4, running Sun OS 4.1.3.
>
>According to my copy of the Sun "Network Programming Guide", this is a
>typical and reasonable thing to do:`
>
>   "... For example, a new version of TCP might be developed at the
>   user level by utilizing a raw IP socket for delivery of packets. 
>   The raw socket interface attempts to provide an identical interface
>   to the one a protocol would have if it were resident in the kernel." 
>			(p. 341, section 12.7, "Raw Sockets")

The last time I dug into raw sockets you could *not* receive IP
datagrams with a protocol field that the kernel was already set to
handle (i.e., TCP), so I'm not sure this will work.

	Rich Stevens  (rstevens@noao.edu)

-----------[000505][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 93 18:13:45 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   PC routing software?

In article <2031@news01.pge.com> jdn8@encon.pge.com writes:

   Has anyone tried to write a simple router for a PC that could
   handle a small (class C) leaf subnetwork?  There is a Cisco
   router for the next hop...

FTP to ftp.acns.nwu.edu, and look for pcroute.

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

-----------[000506][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 1993 18:25:20 GMT
From:      amit@canon.CS.Berkeley.EDU (Amit Gupta)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip
Subject:   Re: New IP protocol?

Hi Dale

A number of different groups are working on this problem. At least initially,
the idea of modifying (or replacing) TCP-IP was greeted with very strong
resistance in the networking community. Over the last couple of years, there
has been a "broad acknowledgement" that these problems exist, though some
researchers still believe that TCP/IP is fundamentally good enough, and we
can add resource management at the top.

A number of researchers are investigating many different approaches. It would
not be possible for me to comment on their relative merits (and not very
desirable for me to comment on the *de*merits of their techniques :), but 
some of the related work includes

- link sharing (Van Jacobson, Sally Floyd {LBL})
- "Predictive Service" (David Clark {MIT}, Lixia Zhang { Xerox PARC}, and others)
- ST-2 (BBN, IBM Hiedelberg, other Europeans)
- RTP (IETF AVT)
- the Tenet Real-time Communication scheme (Domenico Ferrari, {U.C. Berkeley})

I am a member of the Tenet research group, and our work includes a real-time
protocol suite that provides guaranteed service for the network clients who
desire real-time communication. Our protocols co-exist with TCP/IP (real-time
traffic uses our protocols, non-real-time goes over TCP/IP). You can obtain
further information about the real-time protocols by anonymous ftp from
tenet.Berkeley.EDU:pub/Tenet/Papers

thanks

-amit
 Amit Gupta
 amit@cs.Berkeley.EDU

-----------[000507][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 1993 19:08:33 GMT
From:      molin@tuomas.it.lut.fi (Kim Molin)
To:        comp.protocols.tcp-ip
Subject:   Design of parallel TCP. Is it possible ?

I'm wondering if TCP protocol can be parallelized to make the
processing of the protocol more effective.

If the protocol can't be entirely parallelized, so could it be partially
parallelized ?

These subjects are especially of my interest !

	- The checksum calculation
	- segmentation and resegmentation
	- routing in the operating system
	- etc.


	Kim Molin	molin@lut.fi
	Finland


-----------[000508][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 93 19:27:36 GMT
From:      donur@pilot.njin.net (Damoder Donur)
To:        comp.protocols.tcp-ip
Subject:   Ftp script

Hello tcp-ip experts:

i would like to know is there any ftp script that I can put into 
cron file to get the file from the pc which is connected to network.

I am administering Rs/6000 servers running AIX(3.2) and also running tcp-ip
using ethernet interface.

Everyday I am manually ftping to pc getting some files. So instead of 
doing manually is there any script which will automaticall connect to that pc
and get the file from pc to rs/6000.

Thanks 

Damoder Donur
System Administrator


email Address:

donur@rs32h.atlantic.edu
-------------------------------------------------------------

-----------[000509][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 1993 19:57:51 GMT
From:      pconrad@mercury.cis.udel.edu (Phill Conrad)
To:        comp.protocols.tcp-ip
Subject:   Re: Writing a new TCP/IP based on raw sockets on Sun4 (OS 4.1.3)

In article <1993Sep30.162437.25542@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:
>>I am currently tasked with implementing a version of TCP on top of the
>>raw socket interface to the BSD implementation of IP.  In my case, I
>>happen to be running on a Sun 4, running Sun OS 4.1.3.
>
>The last time I dug into raw sockets you could *not* receive IP
>datagrams with a protocol field that the kernel was already set to
>handle (i.e., TCP), so I'm not sure this will work.
>

Perhaps I should have been more clear; the "version" of TCP would in
fact be a "new" protocol, and would not have the same protocol name
or protocol number as TCP.  

By "version" of TCP, I mean that I plan to use the TCP code as a starting 
point, and then make modifications.  Clearly one of the first modifications
will be to change the protocol name and number.  And, as I quoted in my 
original post, the Sun manual specifically mentions this as an application
for raw sockets.  So I'm fairly certain this CAN be done; my question is
more around HOW it is to be done.

The questions that concern me:
-----------------------------

1) I'm becoming more convinced that mbufs are NOT accessible from any user
program; that they are only accessible from kernel processes.  Is this
true?  If this is so, then it seems that I shall have to recode all of the 
TCP routines to be based on my own private memory management scheme, yes?

2) Since the interface between IP and TCP is based on the protosw mechanism,
which involves passing mbufs, if I can't access mbufs,and if my only 
access to the IP layer is through a raw socket, then this must also be
recoded, true?

This seems a far cry from the promise made both in the Sun manual
(see previous post for reference) and in the book "The Design and
Implementation of the 4.3BSD Unix Operating System" (Leffler, McKusic,
Karels and Quartermann, Addison-Wesley, 1990), where it is stated:

  "The raw IP socket interface attempts to provide an identical
  interface to the one a protocol would have if it were resident in the
  kernel".

If I'm in the kernel, my interface is a protosw based on mbufs.  
If I use a raw socket, my interface is through systems calls sendto and
recvfrom.  These hardly seem identical.

I therefore conclude that either (1) the quote above is a big lie, or
(2) I have misunderstood something.  I am hoping very much, that (2) is
the case, and that someone will point this out to me, with a helpful
explanation.

Thanks, Phill

-- 
--Phill Conrad					      pconrad@cis.udel.edu
--Ph. D. Student -- Dept. of Computer and Info. Science -- Univ. of Delaware

-----------[000510][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 1993 20:02:35 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: Packets lost between PC and X

In article <1993Sep30.122141.6858@nrcnet0.nrc.ca>, benedic@nrccsb6.di.nrc.ca (James Benedict) writes:
|> 
|> I have a 486 connetced to an X server.  Everything was working fine until
|> two weeks ago, then the following problem started:
|> 
|> Whenever the user tries to run a program called xmgr (graphics program),
|> it works fine for a while, and then crashes with Xlib reporting the
|> following types of errors "Xlib:  sequence lost (0xXXXXX > 0xXXXX) in relpy
|> type 0xXX!)"
|> 
|> It seems fairly likely that too many packets are being lost or something like
|> that.  The funny part is, if xmgr is started in the background, the program
|> will run alot longer before crashing.

No, that's not very likely at all.  X11 is built on top of TCP, which is
a reliable byte-stream protocol.  You're not going to get data out of
order, no matter *how* many packets are lost, garbled or duplicated.

|> Anyone have any ideas where the problem might lie?

I've seen this before, but only with (1) applications that weren't well
tested and which trashed random blocks of memory in Xlib and (2)
Xservers which had bugs.

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

-----------[000511][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 1993 20:19:05 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Writing a new TCP/IP based on raw sockets on Sun4 (OS 4.1.3)

>1) I'm becoming more convinced that mbufs are NOT accessible from any user
>program; that they are only accessible from kernel processes.  Is this
>true?  If this is so, then it seems that I shall have to recode all of the 
>TCP routines to be based on my own private memory management scheme, yes?

Yes.

>2) Since the interface between IP and TCP is based on the protosw mechanism,
>which involves passing mbufs, if I can't access mbufs,and if my only 
>access to the IP layer is through a raw socket, then this must also be
>recoded, true?

Yes.

What you get with raw sockets is the ability to write IP datagrams
of that protocol type (the 3rd argument to socket()) and the ability
to receive IP datagrams of that protocol type.  Be aware that you
do not write the outgoing IP header (the kernel will prepend that
for you) but you will receive the complete IP header.  That's it.
Everything else is just a small matter of programming on top of this
raw sockets interface :-)  Oh, you also need superuser privilege to
create a raw socket.

	Rich Stevens  (rstevens@noao.edu)

-----------[000512][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 1993 20:31:01 GMT
From:      scohan@ml.com (Scott Cohan)
To:        comp.protocols.tcp-ip
Subject:   Multiple ports, one service name?


I recently came across a group which uses multiple service ports, all registered
under the same name in NIS.  For example...


	foobar		4000/tcp
	foobar		4001/tcp
	foobar		4002/tcp
	foobar		4003/tcp

I would have thought this was illegal, or at least
not recommended in standard practice. Any comments?  
Pro or con?  Good idea or bad, as I suspect?

Thanks!

-----------------------------------------------------------------------
Scott Cohan			|  Mail:  scohan@masdev.ml.com
Enterprise Systems Management	|  UUCP:  Ha!Ha!Ha!Ha
40 Davenport Avenue		| Phone:  (212) 449-2758
New Rochelle, NY 10805		|   Fax:  (212) 449-1465

If you go parachuting, and your parachute doesn't open, and your friends
are all watching you fall, I think a funny gag would be to pretend you were
swimming.

				- Jack Handey, Deep Thoughts



-----------[000513][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 1993 20:47:24 GMT
From:      msells@undergrad.math.uwaterloo.ca (Marty Sells)
To:        biz.sco.general,comp.protocols.tcp-ip
Subject:   How to use /dev/ip & /dev/rip ???

Can someone tell me something about these?! The only
reference I have is from System FIles And Devices
Reference Unix SVR4.2 from prentice Hall Unix press.
 
Somebody somewhere *MUST* know something about them??
Pointers to code, people, or documentation...
*ANYTHING* would be great.
 
SCO Canada have been giving me the 
runaround and I really don't have time for it...

Marty


-----------[000514][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 93 20:48:07 GMT
From:      perl@dwrsun4.UUCP (Robert Perlberg)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Changing IP addresses/subnetting/status monitor problem (HELP!)

Environment:
	Hardware:	Sun SPARCstation 10
	OS:		SunOS 4.1.3 (Solaris 1.1)

I've reported this problem to Sun, but they don't seem to be able to
help us.

We originally set up the network with an arbitrary addressing scheme
wherein all of the Suns had IP addresses that started with 1.1.3.x with
no subnet mask.  We are now changing to an addressing scheme using an
address prefix of 128.254.1.x (Class B network) with a subnet mask of
255.255.255.0.  I attempted to effect this change by performing the
following steps:

- shutdown all systems.

- shutdown the NIS server last

- boot the NIS server single-user

- add the following line to /etc/netmasks:

128.254         255.255.255.0

- edit /etc/hosts and change all of the IP addresses

- cd /var/yp; make

- reboot

When the server came to the point of starting rpc.lockd, the system
displayed the message:

rpc.lockd: Cannot contact status monitor!

This message was repeated continuously at a rate which made it
impossible to use the console.  Restoring the IP addresses to their
previous values allowed the system to be brought back up without
emitting the errors.

Sun support suggested that we try:

rm /etc/sm/*
rm -r /etc/sm.bak

That didn't help.

What do we need to do to effect this address change without
encountering this problem?

Robert Perlberg
Dean Witter Reynolds Inc., New York
dwrsun4!perl@murphy.com -or- philabs!dwrsun4!perl

-----------[000515][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Sep 1993 21:47:18 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Writing a new TCP/IP based on raw sockets on Sun4 (OS 4.1.3)

In article <28fdnv$msb@louie.udel.edu> pconrad@mercury.cis.udel.edu (Phill Conrad) writes:
>...
>If I'm in the kernel, my interface is a protosw based on mbufs.  
>If I use a raw socket, my interface is through systems calls sendto and
>recvfrom.  These hardly seem identical.
>
>I therefore conclude that either (1) the quote above is a big lie, or
>(2) I have misunderstood something.....

Answers to such questions can be most authoritatively and completely
answered by refering to the source.  Get a copy of the BSD Net-2 source,
or one of the free BSD UNIX releases that run on PC-AT 386 clones (look
on agate.berkeley.edu).

A good guess about the question can be made by considering the nature of
a typical system.  If any user process could read or write arbitrary kernel
buffers, then the system might not be very secure or likely to survive
minor bugs in application programs.  (Can you spell DOS?)

Some versions of Sun's TCP/IP are different from classic 4.*BSD.  I don't
think Sun has believed in mbuf's for years, using STREAMS instead, so
trying to get to Sun's mbuf's might not be fruitful.

From at least one perspective, the main problem with almost any network
protocol in the last 10 years is speed.  A user-code implementation of
any protocol in a 4.*BSD-style UNIX kernel is not likely to be a fraction
as fast as a kernel implementation, if only because of the extra copies
of data from kernel buffers (e.g. mbufs) to user buffers (e.g. via
recvfrom()) and later copies back.  However, given kernel source, it is
easy to protocols to the 4.3BSD kernel.  That's another reason to look at
the free BSD UNIX source.  I think I've heard people are working on a
SPARC port of NetBSD.  Or was it FreeBSD?

Some UNIX workstation vendors, I think including Sun, allow customers
without source to add their own non-IP protocols, equivalent to adding
switch table entries to the ethernet drivers.


Vernon Schryver    vjs@rhyolite.com

END OF DOCUMENT