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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Apr 1993 00:34:55 GMT
From:      ckd@eff.org (Christopher Davis)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for a comprehensive list of common port numbers

CS> == Chris Siebenmann <cks@hawkwind.utcs.toronto.edu>

 CS> although the NSFNet measurements consider IRC traffic important enough
 CS> to track it specifically, port 6667 isn't named in 1340.

6667 is the "de facto" IRC port.

194 is the actual registered port.

Since most IRC servers are not run by the system administrators of the
machines in question, and therefore can't bind to port 194, 6667 remained
the IRC port even after 194 was registered.  (Though there are always the
occasional rumblings of a move to 194, nobody's done it yet.)
--
* Christopher Davis * <ckd@eff.org> * <ckd@kei.com> * [CKD1] * MIME * RIPEM *
226 Transfer complete. 17512509 bytes received in 5.2e+02 seconds (33 Kbytes/s)

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 93 01:50:40 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting DNC to work with Internet apps

In article <47111@sdcc12.ucsd.edu> aamicone@sdcc13.ucsd.edu (Andrew Micone) writes:
>I'm running SunOS 4.1.2 ... I've got it configured as a cache-only
>name server, and mostly it seems to work with nslookup for resolving
>host names. ...
>
>The problem is that none of the internet applications seems to work
>right with named.If the host name is in the host table, or if you
>use an IP address it works just fine, but that will not work for
>mail and other services I want to use like gopher. ftp, telnet,
>rlogin and such don't seem to make an attempt to resolve the name
>with the nameserver. I feel like there's a configuration step that
>I'm missing, but I'm not sure. Anybody got an idea what needs to be
>done?

/etc/resolv.conf needs to be installed. (man 5 resolv.conf)
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 93 06:28:45 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.dcom.lans.misc,comp.dcom.servers,comp.protocols.tcp-ip
Subject:   Re: need help:building a mutiplatform net

In article <1993Mar30.004140.1@vmsb.is.csupomona.edu>
   cvakg001@vmsb.is.csupomona.edu writes:
>I have recently recieved a request ... to assemble a [campus residence]
>hall network. We need to be an equal-oppertunity network provider, that is
>the net needs to be equally friendly to macs and PCs. Additionally the 
>equipment investment for either platform needs to be of minimal cost. The 
>housing office has a Mac IIci that we can dedicate as a server. The hall has a 
>maximum capacity of 186 residents. We currently have a need for about 40 users,
>about 20 macs (mostly compacts but with sys7.0) and about 25 pc's. We need to 
>fullfill the current need and have the capability to expand to accouodate about
>150 users.
>
>My basic idea: 
>Run both Phone net and thin ethernet throughout the building using the mac as a
>mail and file server as well as a router between phone net and ethernet. Run 
>appletalk (phase 2?) with AppleShare. 

You don't want to run thin ethernet for two reasons:
(1) Max 30 T-connectors on a thin net; i.e. you need a multiport
    repeater right away, because you need to install wiring to serve
    both kinds in any room of the wing, right ? This wipes out half of
    the savings of thinnet.
(2) Any user can accidentally wipe out a thinnet loop, and then you need
    to get into each room to troubleshoot. Not a good idea.

Put an RJ-45 in each room, with a 4-pair cable to a patch panel.
Now you have identical wiring from each room to the patch panel.

In the wiring closet with the patch panel, install a Mac star controller
and a 10baseT hub (might really be 5 minihubs: 1 at the top level with 4
cascaded below it).

Now you can patch each room's outlet to the appropriate concentrator.

>Problems:
>I don't know if this is even do able.
>I don't know what is involved in using appletalk with PC's. 
>I need to keep the cost down (way down). 

Note that I am not addressing the servers, yet. This is because having
connectivity is more important than having file storage. In fact, the
file storage is just a management headache.

If I were you, I'd forget about the file server and put a GatorBox or
a FastPath in to link the LocalTalk to the Ethernet, and then I'd make
sure to get the Ethernet hooked into the campus backbone.

Since this is a school environment, it is morally wrong to steer people
towards closed, proprietary solutions. Instead you should show them the
wonderful world of the Internet and get them to expect having Internet
access at home.

Note that the active hubs are a little more expensive than the thinwire,
but they are supportable, which is important. If you spend a little bit
more, they can also provide privacy: Some 10baseT hubs will blank out
the data portions of packets addressed to the other ports of the hub, so
that one student with a "LanWatch" program can't monitor everybody
else's sessions and collect their passwords etc. In my opinion, you will
be tempting some people beyond their moral capacity if you don't spend
enough to get this type of hub.

>Questions:
>Is novell a better solution?
>Is tops a better solution?

Both Novell and Tops will add significant money to each client for a
license to the remote file access client.

>Further Complications:
>I want to use both Phonenet and Ethernet so that each Platform can use it's 
>most-affordable data-link.

Running one RJ45 per room solves this.

>I am the entire labor force/ administrator/ installer.
 
>I have to sell this to housing, for they will be paying the bill for cable, and
>netware, ethernet card for the IIci, and possibly some loan-out cards.
 
>The Pc people need to be able to afford a ethernet card.
 
>Would like to beable to share commom files (word,excel,other).

Why ? You still have to PAY FOR a copy for each user.

>Would like to have the capability to future expand to run tcp-ip over the lan 
>while running what ever else were running for school-wide access.

I think you need to start with TCP/IP. If you use a GatorBox as the
Apple-to-ether connection, you can run GatorShare and use the (free)
AppleShare client to access unix-NFS files from the campus fileservers.
(PC user wil have to pay for an NFS client, I think).
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Apr 1993 13:44:47 EST
From:      Andrew T. Robinson <ANDY@MAINE.MAINE.EDU>
To:        comp.protocols.tcp-ip,bit.listserv.ibmtcp-l
Subject:   Encapsulation (tunneling) solutions?

I'm interested in the availability of protocol encapsulation
software/hardware solutions.  I'm particularly interested in
solutions for SNA over TCPIP (if that's not non-sensical) and
IPX over TCPIP.  I'm already familar with the BITNET II protocol
for NJE-in-IP encapsulation.

Please respond directly to ANDY@MAINE.EDU if you have information
on any such solutions.

Andy

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 93 11:12:04 GMT
From:      ub@sapwdf.UUCP (Uwe Bloching)
To:        comp.protocols.tcp-ip
Subject:   Retrieving advertised window size / blocking sockets



Hello TCP/IP-gururs,


anybody out there who can help me solving the following problem ?

We have two programs communicating with each other via TCP/IP non-blocking
stream sockets:

      Program A                      Program B

    --------------                ---------------
    |            |                |             |
    |   send -----------------------> recv      |
    |            |                |             |
    --------------                ---------------

 If program A sends data faster than program B can process it, or even worse,
 if program B does not receive data at all, then the send call in program A
 can block. This is absolutely not acceptable for our application A.
 I'm sure that many of you will spontaneously suggest to use non-blocking
 sockets to prevent this - but because of many many other reasons we don't
 want to do this.
 In the two famous books by Comer (Internetworking with TCP/IP) I read about
 the TCP/IP windowing algorithm: the TCP control process on the system where
 program A runs knows whether it is possible to send data to program B or
 not by evaluating the window size advertised by the system on which program
 B is running.

 Now my simple question is: Is it possible to "ask" a TCP control process
 (for example in program A) whether it is possible to send data without
 getting blocked ?

 If anybody can solve this problem I'm willing to pay a round of beer
 whenever he/she comes to Heidelberg, Germany.


                                   Thank you for your help,

                                         Uwe Bloching

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 93 12:37:35 GMT
From:      Steinar.Haug@delab.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for a comprehensive list of common port numbers

> Another port that I think is becoming common is 1701 for Highland's FlexLM
> license manager.  All the template license.dat files I've seen have used
> this as the port, and an increasing number of applications are making use
> of this license manager.

Shouldn't that be 1700? That's at least what the documentation we have
received says...

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

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 1993 12:42:53 GMT
From:      antonis@intranet.gr (Antonis Kyriazis)
To:        comp.protocols.tcp-ip
Subject:   Re: What is an "ip unnumbered serial line" ?



1. If it's about PPP or X.25 of course you have to. If it's about a
point-to-point HDLC connection or something like that, check the
router's manuals(!)

2. I don't know :-)

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


-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Apr 1993 13:14:47 GMT
From:      dave@com15.NoSubdomain.NoDomain (Dave Stafford)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <1993Mar30.152310.15523@bristol.ac.uk>, smee@bristol.ac.uk (Paul Smee) writes:
|> In article <C4Hno9.Cw4@wm.estec.esa.nl> user@machine.domain writes:
|> >No wonder there's a shortage of addresses. You really only need a class B
|> >address if you have either an awful lot of hosts on a lot of local nets,
|> >or if you have lots of hosts on different sites.
|> >
|> >Too many class B addresses are given out when a block of class C addresses
|> >would do.
|> 
|> It's not quite that simple, owing to the haphazard way in which
|> addresses are assigned (i.e. in numeric order).  There is no way to
|> tell, by just looking at an address, where it is located
|> 'geographically' (meaning both traditional 'geographically', and
|> geographically in terms of the net's topology).  Thus, the backbone
|> routers have got to know where every network is.


    No body ever said that it would be simple, and yes there are always
    trade-offs. Backbone routers don't have to know where every net is,
    at some point they have to choose a default network, and throw the
    packet that way.


|> So, if you have 15 subnets, but they are all subnets of a class B
|> network assigned to you, the backbone boxes need only one routing entry
|> for you, into your class B address space -- it's then your job to route
|> internally between your subnets.  If, on the other hand, you had been
|> given 15 class C networks, which handle your needs equally well, the
|> backbone routers need 15 routing table entries for you -- one into each
|> of your class C address spaces.  Quite simply, high-speed high-volume
|> routers can't cope with large enough routing tables -- yet, at least.

   That depends on what you mean by large. We have several thousand external
   routes, learned via BGP. After the initial update the load on the net
   caused by changes is very low, thus the limiting factor is CPU and memory.
   Both are pretty cheap these days, and a router with 16M can hold a lot of
   routes. This is still no excuse for wasting address space.
  
|> Rumour has it that the Internet gods are going to begin assigning blocks of
|> class C subnets, with some geographical organization behind them.  I.e.
|> addresses 200.*.*.* and 201.*.*.* will be North American, 202.*.*.* and
|> 203.*.*.* will be Europe, and so on.
 .. stuff deleted.... 
|> Pity a hierarchical arrangement wasn't invented earlier.
|> 

  I agree, although it's always easy to say that in retrospect. It's clear
  that a more hierarchical is required, although if addressing was not
  wasted the problem would not be so acute so soon.

Dave 

---------------------------------------------------------------------
Dave Stafford                                    Tel: (31) 1719 84437
Cray Systems Ltd                                 Fax: (31) 1719 85426
European Space Research & Technology Centre
Noordwijk,                                         Opinions:  My OWN!
Holland                                  Email: dstaffor@estec.esa.nl
---------------------------------------------------------------------

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 93 18:29:21
From:      leinwand@mead.cisco.com (Allan Leinwand)
To:        comp.protocols.tcp-ip
Subject:   Re: What is an "ip unnumbered serial line" ?

In article <7458@blue.cis.pitt.edu> imtst@teaser.lis.pitt.edu (I-Ming Tsai) writes:

   Path: cronkite.cisco.com!decwrl!sdd.hp.com!zaphod.mps.ohio-state.edu!pitt.edu!imtst
   From: imtst@teaser.lis.pitt.edu (I-Ming Tsai)
   Newsgroups: comp.protocols.tcp-ip
   Date: 1 Apr 93 07:37:25 GMT
   Sender: news+@pitt.edu
   Organization: University of Pittsburgh
   Lines: 25

Hello,

>	   (1) Do we have to assigned the ip addresses to the serial interfaces
>	       (S0 and S1) in the following simple router connection ?

In most IP networks you do have to assign a subnet address to each link
in the IP network.

>	   (2) What is an "ip unnumbered serial line" ? How do we use that ?

An "ip unnumbered serial line" is a feature of Cisco routers that
enables you to route IP on a point to point serial link and not use an
additional IP subnet.

If you would like more information about this feature on our products,
please send email to cs@cisco.com.

Thanks,

Allan Leinwand
cisco Systems
(510) 831-4730
leinwand@cisco.com

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 1993 22:15:48 +0930
From:      hart@flash.pax.tpa.com.au (Leigh M Hart)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP vs. UDP

schlege@lips2.ecn.purdue.edu (Kevin L Schlegelmilch) writes:


>  For a UNIX process, which protocol (TCP or UDP) can the process
>  carry on sessions with the greatest number of peer processes?

In a typical client/server relationship, the server binds a port and
listens for a connection.  When a connection is established, the server
forks and the child server performs the communications with the client
while the parent goes on listening for further connections.

In this setup (and I believe with TCP generally, I might be wrong) the
server can only communicate with one peer (client) process at a time
(hence using fork).

With a server that uses UDP sockets, it too binds a port and waits for
a packet (note, no connection as such occurs and being a broadcast 
protocol there is no way, unless you program a protocol on top of UDP,
to know if a packet is received, after being sent).

I have written an example client/server file transfer program that uses
the UDP protocol, and is capable of as many sessions as I wish to 
configure (limited by memory I guess *shrug*).

I believe it's a little more efficient than forking an entire server
process with tcp sockets, but it is a little bit CPU intensive.

Anyone interested in the example code (rough as it is) can email me.

Leigh



-- 
Leigh M Hart (hart@pax.tpa.com.au) Ph: +61-8-267-5966 (W)
---------------------
The Fluffy Rabbit rides again

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Apr 1993 14:51:34 GMT
From:      heilbron@Informatik.TU-Muenchen.DE (Stephen Heilbronner)
To:        comp.protocols.tcp-ip
Subject:   Performance comparison TCP vs UDP on LANs

Hello !

We are working on an application of interconnected processes
across a LAN. These processes exchange messages of an
unlimited size. Right now the connections are based on TCP 
sockets but we would like to consider UDP datagrams with a
protocol on top in order to reliability checking and
segmentation. Duplication and sequence checking doesn't seem
to be an issue on a (Ethernet-)LAN.

So the question I have is:
Where can I find figures that compare the performance of UDP
and TCP in this environment?

Any direct emailing of these figures or pointers to them
are very much appreciated.

Thanks very much,
Stephen


-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 1993 14:59:29 GMT
From:      mtg4@po.CWRU.Edu (Michael T. Grossner)
To:        comp.protocols.tcp-ip
Subject:   fsp for dos?


Is it possible to fsp from a pc?
If so, where can I get the software?

Thanks.

-- 
Mike Grossner
mtg4@po.cwru.edu

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 93 15:26:43 GMT
From:      devdjn@space.alcbel.be (Dennis Newport)
To:        comp.protocols.tcp-ip
Subject:   UDP & TCP Questions


I posted the following questions to the group some time ago but I didn't
receive a single response. I'm trying again in the vain hope that someone
can help me.

We are in the process of creating some applications software using TCP/UDP/IP
and I can't find the answer to the following questions anywhere. Can someone
help me.

When we do a UDP broadcast, the datagrams also appear on the relevant port
on the machine doing the broadcasting. They seem to hang around for a short
time then disappear. Does anyone know how long they hang around and what factors
affect this "time-out" ?  I assume the time-to-live (TTL) specified in udp.h may
have something to do with this but I can't seem the relationship with the value
defaulted on our Sun (SunOS 4.1.2) and the time that the datagrams exist during
our tests.

When I was doing some testing a few years ago on a Sun machine I recall that the
maximum data block I could send over a TCP socket was either 32767 or 65535 bytes.
Does anyone know what the current maximum value is and where the defining factor 
can be found ?

When taking down a TCP connection in a client server application, the client goes
into the TIME-WAIT TCP state for a certain time. This time-out should be 2*MSL where
tcp_timer.h defines this to be 30*PR_SLOWHZ. This should be 60 seconds but we don't
observe this. The time-outs can be the order of minutes in reality. Can anyone offer
me an answer to this.

One final question I would ask is a simple one about using xvnews. This is the first
time I have entered an article and I noticed in the header that the "from" and
"reply-to" address specify "nodomain". Can I automatically set these values in a
start-up file and, if so, how do I do it ?

All answers will be greatly appreciated.


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




-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Apr 1993 16:44:50 GMT
From:      tomf@pitvax.claremont.edu
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Re: IPX ROUTING AND IP BRIDGING

In article <1pcteeINNjrd@uwm.edu>, wick9450@miller.cs.uwm.edu (Paul Wickman) writes:
> 
> 	I'm looking for a product that will route IPX/SPX and bridge TCP/IP.
> I know that several (b)router hardware solutions are probably available, but
> I'm wondering if there is a cheaper, software solution.  Any ideas?
> 
> 	Please send all replies to pwickman@carroll1.cc.edu
> 
> Thanks
> 
I'd like to know also.  Could responses be posted?

	tomf@pitzer.claremont.edu



-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Apr 1993 16:45:50 GMT
From:      richb@jti.com (Richard Braun)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: need help:building a mutiplatform net

Note:  this original posting wasn't cross-posted properly.  The
thread is now going on separately in other newsgroups as well (e.g.
comp.sys.novell).  I posted there.

-rich

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Apr 1993 18:21:31 GMT
From:      rps@matuc2.mat.uc.pt (Rui Pedro Mendes Salgueiro)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

		v--- please do something about this.
dave@com15.NoSubdomain.NoDomain (Dave Stafford) writes:
:     No body ever said that it would be simple, and yes there are always
:     trade-offs. Backbone routers don't have to know where every net is,

yes they have.

:     at some point they have to choose a default network, and throw the

No, they can't use a default route.
If they had a default route, when they receive a packet with a invalid
address they would pass it to another backbone router (pointed by the
default route) that will pass it to another (HIS default route), and
you would have a loop.
Even with time-to-live you would waste bandwidth.

Ok, you could have only ONE router with a full routing table, and
still prevent loops, but that would also be wasteful.

I see that you are in Europe (me too). Around here the backbone is
probably a tree (<=> only one path between any 2 points) (at least
Portugal is connected by only one line, maybe Holland is better). 

With such a topology default routing works (but still wastes bandwith
with invalid adresses, and only in that case).

But in the United states the backbone is not a tree (a 3-degree graph
if I'm not mistaken). So each backbone router has to decide by which
line it will send a incoming packet (it has always 2 choices, and the
packet could use either one).
To make the right choice it can't use default routing.

:     packet that way.

I have just read the book Internetworking with TCP/IP by .. Coner(?)
so this subject is still fresh in my mind.
--
   Rui Salgueiro     |   Dpt. de Matematica    |"It's so easy to laugh
rps@matuc2.mat.uc.pt | Universidade de Coimbra | It's so easy to hate
   rps@inescc.pt     |    Portugal - Europe    | It takes strenght to be gentle
" 'He deserves death'.                         |     and kind" - Morrissey
  'Deserves it! I daresay he does. Many that live deserve death. And some that
die deserve life. Can you give it to them ? Then do not be too eager to deal
out death in judgement. For even the very wise cannot see all ends.' "
	Tolkien - The Lord of the Rings

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Apr 1993 19:29:06 GMT
From:      hughes@logos.ucs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip,comp.unix.questions,cs.general
Subject:   Re: UDP question

   When using UDP how does one access the checksum field of the datagram.

You can't except by accessing the UDP datagram itself.  It's a 16-bit
checksum, starting at 48 bits into the datagram (right in front of the
data).

   Also, how does one use the checksum info in order to determine if a
   transmission error has occured.

You don't have to, because the UDP transport layer does it for you.
The Berkeley sockets API (or whatever API you're using) hides all
of that from you, and just gives you the data.

BTW, most UDPs do not in practice implement checksums, to keep it
lightweight.  I believe they have to be capable of it, to be compliant,
but it's usually not enabled by default.


-Larry

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 1993 21:32:56 GMT
From:      atan@unixg.ubc.ca (Albert Tan)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.dcom.lans.ethernet,comp.dcom.lans.misc
Subject:   Re: Netware-lite/ncsa telnet


we have it install, even on window 3.1; but if you are looking for
lightning speed; forget it!

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Fri, 02 Apr 93 01:36:27 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   What is an "ip unnumbered serial line" ?

In article <1peo0d$66f@helios.intranet.gr> antonis@intranet.gr writes:

   1. If it's about PPP or X.25 of course you have to assign an IP
   address to both ends. ...

Hmmm...  The Rockwell/CMC Nethoppers manage to run PPP between
themselves without assigning an IP address to the PPP interfaces. All
you do is say what IP addresses are hanging off the Nethopper at the
other end of your PPP link, and it knows to route them over the PPP
link.

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

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Apr 1993 02:38:28 GMT
From:      mikel@aaahq05.aaa.com (Mikel Manitius)
To:        comp.protocols.tcp-ip
Subject:   Re: What is an "ip unnumbered serial line" ?

In article 7458@blue.cis.pitt.edu, imtst@teaser.lis.pitt.edu (I-Ming Tsai) writes:
> 	(1) Do we have to assigned the ip addresses to the serial interfaces
> 	    (S0 and S1) in the following simple router connection ?
> 
> 	(2) What is an "ip unnumbered serial line" ? How do we use that ?

The answer is: it depends upon the protocol which you are using.

In a traditional router configuration, the link between the routers would need
it's own subnet address. So that each router would have two IP addresses, one
for the real network, and one for the "psudo-network" representing the leased
line.

If you are running PPP this is no longer necessary. Each router has only one
IP address (assuming only one Ethernet per router). It uses the same IP address
to identify itself on both ends, since it's a Point-to-Point link.

I think this is what is meant by an "unnumbered serrial line".
---
						Mikel Manitius
						mikel@aaa.com


-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 93 13:32:03 -0500
From:      harvey@indyvax.iupui.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!

In article <1993Mar30.121411.9759@unipalm.co.uk>, ian@unipalm.co.uk (Ian Phillipps) writes:
>[stuff deleted]
> To get things in perspective: the class Cs are still allocating in the
> 193... series.

Oops -- somebody better tell the new NIC then:

% nslookup internic.net
Server:  hummer.iupui.edu
Address:  134.68.1.9

Name:    internic.net
Address:  198.41.0.5

%

>                That's quite a few more to go. An important problem,
> which must be (and can be) solved, but not one that's going to stop us
> in the next few months.

I think running out of class Bs is supposed to be the immediate problem.
Once using class Cs in blocks becomes common practice then they will start
disappearing faster too.  Oh well.

>
>>Thats before you start to consider toasters etc with an internet address.
>
> There are more IP addresses available than the toaster population of the
> earth :-)

Yeah -- and who'll ever really need more than 640K of memory? :-) :-)
--
James Harvey    IUPUI OIT Technical Support -- VMS/Unix/Networks
harvey@iupui.edu  uucp:iugate!harvey  bitnet:harvey@indyvax

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Apr 1993 09:43:11 GMT
From:      doswangx@nuscc.nus.sg (Wang Xi (Ms))
To:        comp.protocols.tcp-ip
Subject:   WANT: BOOTPFWD.NLM


Hi,

Who can tell me where to get BOOTPFWD.NLM file from FTPsites or commercial ?

Thank you in advance

Esther X.Wang

Internet: doswangx@nuscc.nus.sg
 

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Apr 1993 10:46:52 GMT
From:      ag129@cus.cam.ac.uk (Alasdair Grant)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In article <id.C_FY.2U1@ferranti.com> peter@ferranti.com (peter da silva) writes:
>As for checksumming... if just *checksumming* that data is a killer, how do
>you propose to do useful work on it at that rate?

Many kinds of processing start by selecting a subset of the data to
work on.  I used to do time series on stats data - each job would read
in about 10 tapes and select about 1% of the records (different each
time) for processing.  The selection/rejection process took about 3
machine instructions per record - checksumming all that data would have
been a massive overhead.  Now, obviously if I was doing this over a
WAN I would want to move as much data reduction as possible close to
the source (though not many tape controllers understand SQL or SAS).
But this doesn't mean TCP/IP is adequate for the high-speed local links.

Also, some people use big machines effectively as fast I/O switches.
People still use IBM mainframes running MVS because even though they
aren't too good at number crunching, they are damn good at shifting data
from one place to another, with a small amount of processing in between
(more than could be done in a dedicated I/O switch).  If, for whatever
reason, your machine has this sort of architecture, the amount of CPU
required for TCP/IP could mean having to buy a supercomputer when all
you need is a mainframe.

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Apr 1993 10:59:18 GMT
From:      Yves Tremolet <yves.tremolet@gsi.fr>
To:        comp.protocols.tcp-ip
Subject:   ftp on IBM AS400

Hello,

Does anybody knows an implementation of ftp on the AS400
either public or commercial ?

Thanks in advance, 
                Yves Tremolet     yves.tremolet@gsi.fr

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 93 12:43:23 GMT
From:      efb@slced1.nswses.navy.mil (Everett F Batey)
To:        comp.protocols.tcp-ip
Subject:   Pocket guide anonymous ftp setup

Hope one of you will remember where you last saw a guide to setting up 
anonymous ftp .. cant find it anymore .. help appreciated /Ev/
--
 +  efb@suned1.nswses.Navy.MIL  efb@gcpacix.uucp  efb@gcpacix.cotdazr.org +
 +  efb@nosc.mil   WA6CRE    Gold Coast Sun Users   Vta-SB-SLO DECUS  gnu +
 +  Opinions, MINE, NOT Uncle Sam_s | b-news postmaster xntp dns  WAFFLE  +

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 1993 15:02:15 GMT
From:      antonis@intranet.gr (Antonis Kyriazis)
To:        comp.protocols.tcp-ip
Subject:   Re: What is an "ip unnumbered serial line" ?

In article 733714587snx@crynwr.com, nelson@crynwr.com (Russell Nelson) writes:
> In article <1peo0d$66f@helios.intranet.gr> antonis@intranet.gr writes:
> 
>    1. If it's about PPP or X.25 of course you have to assign an IP
>    address to both ends. ...
> 
> Hmmm...  The Rockwell/CMC Nethoppers manage to run PPP between
> themselves without assigning an IP address to the PPP interfaces. All
> you do is say what IP addresses are hanging off the Nethopper at the
> other end of your PPP link, and it knows to route them over the PPP
> link.

All right, but RFC1171 specifies that IP datagrams are encapsulated (IPCP).
The result might be that Rockwell/CMC Nethoppers doesn't comform exactly
to the above specification (?)

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


-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Apr 93 16:22:23 GMT
From:      mouse@thunder.mcrcim.mcgill.edu (der Mouse)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: Checksum question

In article <1993Mar31.152046.12484@news.cs.indiana.edu>, napi@cs.indiana.edu (Mohd Hanafiah Abdullah) writes:

> Can someone please explain to me how one does a checksum for error
> detection when passing message over a network.

There is no single "how".  Essentially, one computes some function of
the message contents at the source and includes the result in the
message.  The recipient computes the same function and checks to see if
the result matches what's in the message.

As to what "some function" is, that varies.  Some things (eg, tar, TCP)
just add up the pieces.  (TCP sums 16-bit words and uses
one's-complement arithmetic, tar sums bytes and just uses a large
enough accumulator to avoid overflow.)  Some things use more
complicated functions, like CRCs.  What's best depends on the
tradeoffs - how much CPU time you can afford, how strong an assurance
you need that a checksum match implies a correct message, etc....

					der Mouse

				mouse@mcrcim.mcgill.edu

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 93 19:03:05 GMT
From:      mark@verdix.com (Mark Lundquist)
To:        comp.protocols.tcp-ip
Subject:   Re: Performance comparison TCP vs UDP on LANs

In article <1993Apr1.145134.5227@Informatik.TU-Muenchen.DE> heilbron@Informatik.TU-Muenchen.DE (Stephen Heilbronner) writes:
>Hello !
>
>We are working on an application of interconnected processes
>across a LAN. These processes exchange messages of an
>unlimited size. Right now the connections are based on TCP 
>sockets but we would like to consider UDP datagrams with a
>protocol on top in order to reliability checking and
>segmentation. Duplication and sequence checking doesn't seem
>to be an issue on a (Ethernet-)LAN.

Hi.  I don't have the figures you're asking for, but I think you may
really be "barking up the the wrong tree" as we say in the US!

I have implemented a reliable message protocol on top of UDP/IP (but
not for performance reasons -- it was because the other side of the
connection was an embedded system debug monitor that had a very
austere run-time environment: all interrupts disabled, no heap
allocation available, needed to fit in a small amount of RAM.  Not a
rich enough environment to support a full TCP/IP implementation).  It
is pretty easy to implement protocols like this.  But it's a loser as
far as performance is concerned.

What you are considering is virtually guaranteed NOT to be a
performance win, and here are the reasons why:

1) The TCP overhead you are trying to avoid because it's supposedly 
   not needed over an Ethernet LAN is trivial in the first place.
   A lot of the complexity of TCP/IP that's there to deal with the
   exceptional or oddball cases simply doesn't "kick in" unless those
   oddball cases come up.  The algorithms for sequence-space checking
   are very generalized, so while you might imagine a clunky set of
   special-case checks like "check for duplicate segment; OK, now see
   if the segment is out-of-order", etc., in reality it is a lot more
   lightweight.  All this stuff is further streamlined by "Van
   Jacobsen header prediction" that is standard in most
   implementations.  This is an optimization in favor of the expected
   case, where a few quick checks determine whether the incoming segment
   can take the "fast path".  In many cases a segment received from a
   peer on the same Ethernet LAN will fall right through the TCP input
   routine.

   The idea that TCP entails a lot of overhead is a myth!  The
   complexity of the protocol is actually what *enables* you to drive
   the underlying link at its full bandwidth (as will become clear
   shortly).  TCP is almost never the bottleneck.  The processing
   overhead *buys* you performance by enabling you to use the network
   in an efficient way.  Too many people do not understand this, and get
   the idea that they can optimize away an already small processing
   overhead without realizing that in doing so they would be throwing
   away network utilization.

2) You will need to do sequencing anyway.  Consider the case where one
   side sends an ack, but the ack is lost (and packets are lost
   over Ethernet).  The peer is going to retransmit something.  You
   have to be able to recognize that you should discard this
   packet because you have seen it before.  So you will have to deal
   with duplicate packets, even over Ethernet.

3) TCP is able to drive an Ethernet at or near saturation because it
   is a pipelined protocol.  This means that if you have more stuff to
   send, you send it without waiting around for the last thing you
   sent to be acknowledged.  If something turns out not to have been
   acknowledged, then you deal with that later.  A "lock-step" protocol,
   where a packet cannot be transmitted until an ack for the previous
   packet has been received, is a simple lightweight protocol -- but
   it is also a terrible waste of network bandwidth!  So if you try to
   get rid of the processing overhead of a pipelined protocol, your
   thoughput will go down, down, down!

   Now you can say "Well, I'll just implement a *pipelined* protocol
   on top of UDP."  But now you are making your protocol more
   complex, and admitting that you need some of the complexity that
   you thought you were going to avoid by not using TCP.  Note that in
   this case you would have to deal with out-of-order packets, even on
   Ethernet: what if you send a burst of, say 4 packets, and the
   second packet is lost?  Then the other side must receive the
   packets out of order -- 1, 3, 4, 2 (retransmitted).  Unless you
   simply throw away packets 3 and 4 because you have not seen 2
   yet, thus forcing them to be retransmitted as well...not my idea of
   a high-performance protocol!

   Furthermore, even in a pipelined protocol, one ack per packet is a
   waste.  TCP has a cumulative ack scheme in which one ack segment
   can acknowledge many segments.

   Similarly, any decent TCP implementation is capable of coalescing
   several small user message sends into one TCP segment.  This also
   makes more efficient use of the Ethernet.

4) You probably will need flow control, especially if you are dealing
   with "unlimited size" messages, so add some more overhead to your
   protocol if you aren't going to use TCP.
   
   One problem with network flow-control schemes is that they can very
   quickly degenerate into states where the network is being utilized
   in the very worst way possible (in TCP this is known as the
   "silly-window syndrome").  Knowing how much to close the channel
   (you wouldn't even consider binary "start/stop" flow control on a
   network) and getting the channel back up to full capacity after it
   has been closed down is not trivial!  A lot of TCP is devoted to
   dealing with flow control in a way that doesn't destroy throughput.

5) At the bare minimum, for a reliable protocol supporting
   arbitrary-sized messages over Ethernet, you must implement
   (1) segmentation/reassembly and (2) timeout/retransmission.
   Now, if you layer on top of UDP/IP you essentially have a protocol
   stack in which the top layer (the part you implement) runs in user
   space, while the bottom layers (UDP/IP and network drivers) run in
   kernel space.

   Crossing the boundary between user and kernel space incurs two big
   hits: (1) the overhead of trapping into and out of the OS, and
   (2) copying data between the user process memory space and the kernel
   memory space.  With TCP, all the protocol processing occurs in
   kernel space; the user-space boundary is only crossed once per
   reliable send/receive of user data.  But in a reliable protocol
   implementation running in user space on top of UDP, you are crossing
   that boundary once per protocol *packet* required to implement
   reliability and segmentation.


So, to summarize: you're not spending very many more cycles in TCP
than you would in your custom protocol anyway; and those cycles are
worth their weight in gold, because they are spent in the service of
network utilization, which in turn is what buys you throughput.  In
order to even touch the performance of TCP you would have to invent
your own TCP-equivalent, and be stuck with fixing and fine-tuning and
optimizing it for the rest of your life!  And there is no way you
would ever think of all the subtleties and tricks and optimizations
that the TCP community has provided solutions for over the years.
Heck, you would probably never even understand what the bottlenecks
were!  (This isn't a put-down; I would never be able to either!)

You won't see a big difference in raw data-transfer rates between TCP
and UDP over Ethernet anyway, because current TCP implementations can
drive the Ethernet at close to full bandwidth.  And even if there is a
piddling difference between the two, the overhead of whatever custom
protocol you might implement is a matter of pure speculation!  My
advice to you would be to do some profiling and analysis, and find out
where your real bottlenecks are.  Don't blame TCP!  Don't throw it
away!  It is your good buddy!  Don't use it as a scapegoat!  If it
turns out that the network is truly your bottleneck (and you won't
find this out by looking at TCP/IP vs. UDP performance numbers), then
maybe you need a faster network, like FDDI.  But first, you should get
someone who really understands networking to take a look at your whole
application and find out if you can fine-tune your TCP/IP
implementation or your application's use of TCP/IP.  Don't assume that
you can't do any better with TCP/IP than you're doing now.

Good luck,
-- mark

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 93 19:16:07 GMT
From:      mtayler@pilot.njin.net (Mark Tayler)
To:        comp.protocols.tcp-ip
Subject:   Looking for PD TCP/IP for ATT 3b2


We have an old AT&T 3b2 600 and want to run TCP/IP on it.
It is running SVR3.2.1, we have a compiler for it.
We currently have the AT&T TCP/IP WIN 3b but it does not support DNS.
Therefore the users must know the address they want to telnet or ftp to.
The alternative is a pretty hefty /etc/hosts file.
We would like to find a PD TCP/IP system that supports DNS.
If such software exists, and can run on this system, please e-mail
any info you might have.

All info is appreciated

****************************************************************************
*  Mark L. Tayler                               System Administrator:      *
*  mtayler@ccm.edu				County College of Morris   *
*                                               (201) 328-5772    (VOICE)  *
*                                               (201) 328-5058    (DATA)   *
****************************************************************************

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Apr 1993 19:23:15 GMT
From:      craigs@cognos.com (Craig Statchuk)
To:        comp.protocols.tcp-ip,comp.windows.ms
Subject:   TELNET APIs for MS-Windows

Does anyone know of any interfaces to TELNET (or RSH) for use 
by APPLICATIONS running under MS-Windows.   I could use a BIOS
INT 14h redirector to map serial I/O calls over a TCP/IP driver
BUT I would like something better. 

An API that handles 'rlogin' functions automatically (username
and password verification on the remote host) and then allows an application
to send and receive data over the resulting telnet link would be ideal...

Any suggestions or comments are be greatly appreciated...

-- 
Craig Statchuk,          Cognos Incorporated 
Network Architect        3755 Riverside Drive   
craigs@cognos.com        Ottawa, Ontario K1G 3Z4
(613) 738-1440           CANADA

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Apr 1993 20:11:33 GMT
From:      uad1200@dircon.co.uk (Ian Wade)
To:        rec.radio.amateur.packet,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   ******  KA9Q NOS DOCUMENTATION ON ucsd.edu  *****

===========================
KA9Q: NOSview RELEASE [304]
===========================
by Ian Wade, G3NRW


NOSview [304] is now available via FTP on

        * * * * * * * * * * * * * * * * * * * * * * * * *
        *   ucsd.edu:  /hamradio/packet/tcpip/nosview   *
        * * * * * * * * * * * * * * * * * * * * * * * * *

Download the file:
                     * * * * * * * * * *
                     *                 *
                     *   nosvw304.zip  *
                     *                 *
                     * * * * * * * * * *


NOSview, first introduced in September 1991, is an on-line
documentation and runtime package for the KA9Q Network
Operating System (NOS).  It contains:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

***  probably the only complete reference work anywhere
     that describes all of the commands to be found in the
     major NOS releases.

***  a TSR file viewer that lets you read the NOSview
     documentation on-line, without breaking out of NOS.

***  NOSgas: the "NOS Get-Away Special"  --  a complete set
     of working NOS runtime software, based on the PA0GRI
     2.0m release.

***  a complete set of templates for the NOS control files.

***  full details on how to get the book "NOSintro", which
     describes in detail how TCP/IP works and how to use
     KA9Q NOS.  Ideal for beginners to TCP/IP (and more
     advanced users will find many gems of helpful
     information there as well).

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


NOSview [304] contains many new documentation files, and
the template NOS control files match the listings in the
book "NOSintro".

Extras include ....

    UUENCODE/UUDECODE file conversion utilities
    AX.25 Baycom Packet Driver
    KISS protocol documentation
    HOSTS <> DOMAIN conversion programs
    PCElm and ELM Mailers
    The Clockwork VIEW TSR file viewer

As NOSVW304.ZIP is quite large (around 700 KB), you may
prefer instead to get your copy by mailing a DOS-formatted
diskette (any size EXCEPT 360 KB) and return mailer to:

     Ian Wade, G3NRW
     7 Daubeney Close
     Harlington
     DUNSTABLE
     Bedfordshire
     LU5 6NF
     United Kingdom

Please enclose return postage as follows:

     United Kingdom:               UK postage stamps
     Rest of Europe:               3 IRCs
     The Americas, Africa:         7 IRCs
     Rest of the World:            9 IRCs

(Any unused IRCs will of course be returned).

There is no charge for NOSview, so please do NOT enclose
any form of payment.


73 de Ian Wade, G3NRW

February 1993

P.S.  If you would like full details of the book
      "NOSintro", please email me direct:

        ianwade @ dircon.co.uk

--
* * * * * * * * * * * * * * * * *|* * * * * * * * * * * * * * * * * * * *
*  Ian Wade                      | Email:   ianwade @ dircon.co.uk.     *
*  Dowermain Ltd                 |          g3nrw @ dircon.co.uk.       *
*  7 Daubeney Close, Harlington, | AX.25:   G3NRW @ GB7KHW.#21.GBR.EU   *

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 1993 20:45:02 GMT
From:      gnome@pd.org (Mike Mitten)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

Urban Surfer (holdrege@dcv4kd.phs.com) wrote:
>PSI, Alternet and others own huge blocks of class B addresses. It is not hard
>to get a class B address from them. Just sign up for their service, tell them 
>you have hundreds of nodes, and in a few days, you get your class B address. 
>No questions asked.

This was not the case last week.  In search of an Internet connection
for my employer, I called UUNET, PSI, and SURAnet for quotes.  They
all said that they would process/pass on an IP address application,
but that the chances of getting a class B address were slim to none.
Someone (I don't remember who) said that the policy was now that
connection providers (such as UUNET, PSI, etc.) are not allowed to
assign class B's.  As we have somewhat over 600 hosts at our site, I'd
really like to get a class B.

  -Mike

Mike Mitten - gnome@pd.org - ...!emory!pd.org!gnome - AMA#675197 - DoD#522
Irony is the spice of life.     '90 Bianchi Backstreet  '82 Suzuki GS850GL
"The revolution will not be televised."

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Apr 1993 22:53:43 GMT
From:      matthew@ntl02.decnet.nokia.fi (Matthew Faupel)
To:        comp.protocols.tcp-ip
Subject:   Mysterious socket delays

I have a pair of client server test programs.  The server listens on a
TCP/IP socket and the client connects to it.  Once the connection is
established the client sends the server a message and the server bounces it
back.  This is repeated a number of times and the time it takes to perform
one of these bounces is worked out.

If I send the message as one send and receive it with one receive, i.e.:

    Client                          Server

    for(i=0; i<ITERATIONS; ++i)     for(i=0; i<ITERATIONS; ++i)
    {                               {
       send( sock_fd, msg, 27 );       recv( sock_fd, msg, 27 );
       recv( sock_fd, msg, 27 );       send( sock_fs, msg, 27 );
    }                               }

it takes about 0.0005 seconds per cycle.

If I split any one of the sends and receives up into two parts (or all of
them for that matter), e.g.:

    Client                          Server

    for(i=0; i<ITERATIONS; ++i)     for(i=0; i<ITERATIONS; ++i)
    {                               {
       send( sock_fd, msg, 9 );
       send( sock_fd, msg, 18 );       recv( sock_fd, msg, 27 );
       recv( sock_fd, msg, 27 );       send( sock_fs, msg, 27 );
    }                               }

The performance degrades radically and each cycle takes about 0.2 seconds.

This behaviour is apparent on both the HP-UX machines and the Apollos that
I've been able to test this on.


***Here's the question: does anyone know what causes this behaviour?



Sub-points for the interested:

1.  The loops are a little more complicated than I've shown in order to
    cope with send and recv being interrupted, but the basic idea is as
    shown.

2.  I've tried both blocking and non-blocking IO, both of which exhibit this
    problem.

3.  I've tried setting the socket parameter TCP_NODELAY, which again has no
    effect on this "feature".

Cheers,


Matthew
--
matthew@ntl02.decnet.nokia.fi   }
matthew@uk.tele.nokia.fi        } One of these should work...
matthew@cpdapo.uk.tele.nokia.fi }

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Sat, 3 Apr 1993 08:20:13 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: Offloading TCP/IP processing

In article <1p9nm2INNecm@news.hi.com>, tonyr@hicomb.hi.com wrote:
>Are there any successful examples of offloading some or all of the
>protocol processing onto a front-end processor?  ... more interested
>in general TCP offloading.

I can think of two instances of this off-hand...

1) The UBC MTS HIM (University of British Columbia Michigan Terminal
System Host Interface Machine).  It does the TCP error detection and
recovery "off-board" and presents the host with a perfect TCP stream.
The host here is an IBM 370 type system and the front-end is a PDP-11
type box.  They communicate over an IBM channel.

2) The Excelan (now Microdyne) EXOS 205 series Ethernet boards.  I
believe the TCP/IP is implemented entirely "off-board" in this case.
The host is a PC and the front-end is an Intel 80186-based card.
This pair communicate over the PC's ISA bus.

...Sam
-- 
<skl@wimsey.bc.ca> -- Connectivity Technology Inc.

NetNews on CD's: <info@CDPublishing.COM>


-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 93 08:54:52 GMT
From:      mrs@netcom.com (Morgan Schweers)
To:        comp.protocols.tcp-ip
Subject:   Suggested RFC for LCP, Lemmings Control Protocol.






Lemming Studies Group                                          M. Schweers
Request for Comments:  not registered                         Sick-Nose-Is
                                                                March 1993


                LCP - Lemmings Control Protocol Internals

1.       Some notes on LCP.

         This  document introduces some  of the core concepts of  the
         Lemmings Control Protocol (hereafter LCP).  It is the belief
         of this commitee that this  protocol will greatly expand the
         current  capabilities  of  the  Internet.   This document is
         advisory in nature, and does not specify a Internet Standard.

2.       Explanation

         In studying the Internet's operation,  many independant bodies
         have noted inefficiencies in the operation of TCP.  We believe
         the  protocol  described  in  this  document  addresses  those
         inefficiencies.

3.       What is the Lemmings Control Protocol

         Standard  TCP  packets  are  broadcast  wildly  about the  net,
         running  headlong into firewalls,  falling into the bit bucket,
         and living too long.  This results in misdirected packets, lost
         lost luggage, and generally poor system performance.

         On the positive security side,  the LCP specifies that Lemmings
         Packets can, if activated properly, block other LCPs from being
         passed on.

         This is unfortunately  offset by  the negative security feature
         that Lemmings Packets can both dig through and climb over fire-
         walls.

         Lemmings packets will, almost always,  break through to deliver
         their data.

4.       Example

         System FOO begins a transaction.  ("Let's go!")
         The first Lemmings packet is dropped, and heads off the wrong
         direction.
         That LCP's mode is set to L_BLOCKING by system FOO, rerouting
         future LCP packets towards the correct destination.
         The second LCP packet is dropped.
         System FOO waits until the second LCP packet gets near system
         BAR,  and sends  an 'urgent'  LCMP  (Lemmings Control Message
         Protocol) message which sets the L_DIG_IT_ALL flag.
         As the secondary LCP packet breaks through to system BAR, the
         packet-drop rate on system FOO is increased to 99%,  flooding
         the net with properly directed, well behaved LCP packets!

5.       In conclusion, we feel that this implementation of a Lemmings
         Control Protocol is the obvious next step in the evolution of
         the Internet.  Addressing a packet to sites is easily done by
         setting up multiple blockers across the network. The TTL flag
         for any LCP packet is defined as being initially set to five.
         And the most important feature to the future of the Internet,
         Lemmings build their own bridges.
-- 
Hacker, Furry, SFFan, gamer, writer, MUDder, climber.  24 hours isn't enough!
mrs@netcom.com   | Finger mrs@netcom.com or mrs@mcafee.com for my PGP 2.1 key!|
New chrome grass! \ B1 S4 a b g j++! k l? p r- s t+ u v- w+ x y- z, approx.__/
Low-level D&D monsters practicing war games @ night.  Orc-Kestrel manoeuvers...

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Sat, 3 Apr 1993 08:59:34 GMT
From:      heilbron@Informatik.TU-Muenchen.DE (Stephen Heilbronner)
To:        comp.protocols.tcp-ip
Subject:   Re: Performance comparison TCP vs UDP on LANs


I forgot to mention in my original posting (it is
quoted below) that the processes of our application 
also need to do a sort of reliable 
multicasting. From the replies and postings I got so far
I'm aware that UDP with my requirements has no performance
advantages over TCP when it comes to one-to-one connections.

But I'm wondering whether this still holds true when
apps need to do reliable multicasting ? Does anybody know
of public domain or research work that implemented reliable
multicasting on top of UDP or raw sockets?

Mark, after reading your posting -which is really great for
the insights it gave me- I was wondering what you (or anyone
else) would even recommend TCP when there frequent
shutdowns and connects are necessary because of 64 or 128
limitation on open file descriptors in UNIX like systems ?
(We are planning to use more interconnected processes than 128.)
From the way I understand that the "connect" is implemented as
a three-way-handshake thing between the two kernels it looks
like TCP might even be better in this case since it's overhead
for connection establishment is low.

Another question is, whether there are problems with the
kernel running out of sockets when heavy connecting/disconnecting
is going on. This because of what the UNIX manual pages call
"lingering" in order to avoid imediate reuse of identifiers
of closed connections. Has anybody experienced this on SUN-OS,
ULTRIX or HP-UX ?

Thanks,
Stephen Heilbronner <heilbron@informatik.tu-muenchen.de>

-------------- Quote of reply to my original article -----------

In article <9553@verdix.verdix.com> mark@verdix.com (Mark Lundquist) writes:
>In article <1993Apr1.145134.5227@Informatik.TU-Muenchen.DE> heilbron@Informatik.TU-Muenchen.DE (Stephen Heilbronner) writes:
>>Hello !
>>
>>We are working on an application of interconnected processes
>>across a LAN. These processes exchange messages of an
>>unlimited size. Right now the connections are based on TCP 
>>sockets but we would like to consider UDP datagrams with a
>>protocol on top in order to reliability checking and
>>segmentation. Duplication and sequence checking doesn't seem
>>to be an issue on a (Ethernet-)LAN.
>
>Hi.  I don't have the figures you're asking for, but I think you may
>really be "barking up the the wrong tree" as we say in the US!
>
>I have implemented a reliable message protocol on top of UDP/IP (but
>not for performance reasons -- it was because the other side of the
>connection was an embedded system debug monitor that had a very
>austere run-time environment: all interrupts disabled, no heap
>allocation available, needed to fit in a small amount of RAM.  Not a
>rich enough environment to support a full TCP/IP implementation).  It
>is pretty easy to implement protocols like this.  But it's a loser as
>far as performance is concerned.
>
>What you are considering is virtually guaranteed NOT to be a
>performance win, and here are the reasons why:
>
>1) The TCP overhead you are trying to avoid because it's supposedly 
>   not needed over an Ethernet LAN is trivial in the first place.
>   A lot of the complexity of TCP/IP that's there to deal with the
>   exceptional or oddball cases simply doesn't "kick in" unless those
>   oddball cases come up.  The algorithms for sequence-space checking
>   are very generalized, so while you might imagine a clunky set of
>   special-case checks like "check for duplicate segment; OK, now see
>   if the segment is out-of-order", etc., in reality it is a lot more
>   lightweight.  All this stuff is further streamlined by "Van
>   Jacobsen header prediction" that is standard in most
>   implementations.  This is an optimization in favor of the expected
>   case, where a few quick checks determine whether the incoming segment
>   can take the "fast path".  In many cases a segment received from a
>   peer on the same Ethernet LAN will fall right through the TCP input
>   routine.
>
>   The idea that TCP entails a lot of overhead is a myth!  The
>   complexity of the protocol is actually what *enables* you to drive
>   the underlying link at its full bandwidth (as will become clear
>   shortly).  TCP is almost never the bottleneck.  The processing
>   overhead *buys* you performance by enabling you to use the network
>   in an efficient way.  Too many people do not understand this, and get
>   the idea that they can optimize away an already small processing
>   overhead without realizing that in doing so they would be throwing
>   away network utilization.
>
>2) You will need to do sequencing anyway.  Consider the case where one
>   side sends an ack, but the ack is lost (and packets are lost
>   over Ethernet).  The peer is going to retransmit something.  You
>   have to be able to recognize that you should discard this
>   packet because you have seen it before.  So you will have to deal
>   with duplicate packets, even over Ethernet.
>
>3) TCP is able to drive an Ethernet at or near saturation because it
>   is a pipelined protocol.  This means that if you have more stuff to
>   send, you send it without waiting around for the last thing you
>   sent to be acknowledged.  If something turns out not to have been
>   acknowledged, then you deal with that later.  A "lock-step" protocol,
>   where a packet cannot be transmitted until an ack for the previous
>   packet has been received, is a simple lightweight protocol -- but
>   it is also a terrible waste of network bandwidth!  So if you try to
>   get rid of the processing overhead of a pipelined protocol, your
>   thoughput will go down, down, down!
>
>   Now you can say "Well, I'll just implement a *pipelined* protocol
>   on top of UDP."  But now you are making your protocol more
>   complex, and admitting that you need some of the complexity that
>   you thought you were going to avoid by not using TCP.  Note that in
>   this case you would have to deal with out-of-order packets, even on
>   Ethernet: what if you send a burst of, say 4 packets, and the
>   second packet is lost?  Then the other side must receive the
>   packets out of order -- 1, 3, 4, 2 (retransmitted).  Unless you
>   simply throw away packets 3 and 4 because you have not seen 2
>   yet, thus forcing them to be retransmitted as well...not my idea of
>   a high-performance protocol!
>
>   Furthermore, even in a pipelined protocol, one ack per packet is a
>   waste.  TCP has a cumulative ack scheme in which one ack segment
>   can acknowledge many segments.
>
>   Similarly, any decent TCP implementation is capable of coalescing
>   several small user message sends into one TCP segment.  This also
>   makes more efficient use of the Ethernet.
>
>4) You probably will need flow control, especially if you are dealing
>   with "unlimited size" messages, so add some more overhead to your
>   protocol if you aren't going to use TCP.
>   
>   One problem with network flow-control schemes is that they can very
>   quickly degenerate into states where the network is being utilized
>   in the very worst way possible (in TCP this is known as the
>   "silly-window syndrome").  Knowing how much to close the channel
>   (you wouldn't even consider binary "start/stop" flow control on a
>   network) and getting the channel back up to full capacity after it
>   has been closed down is not trivial!  A lot of TCP is devoted to
>   dealing with flow control in a way that doesn't destroy throughput.
>
>5) At the bare minimum, for a reliable protocol supporting
>   arbitrary-sized messages over Ethernet, you must implement
>   (1) segmentation/reassembly and (2) timeout/retransmission.
>   Now, if you layer on top of UDP/IP you essentially have a protocol
>   stack in which the top layer (the part you implement) runs in user
>   space, while the bottom layers (UDP/IP and network drivers) run in
>   kernel space.
>
>   Crossing the boundary between user and kernel space incurs two big
>   hits: (1) the overhead of trapping into and out of the OS, and
>   (2) copying data between the user process memory space and the kernel
>   memory space.  With TCP, all the protocol processing occurs in
>   kernel space; the user-space boundary is only crossed once per
>   reliable send/receive of user data.  But in a reliable protocol
>   implementation running in user space on top of UDP, you are crossing
>   that boundary once per protocol *packet* required to implement
>   reliability and segmentation.
>
>
>So, to summarize: you're not spending very many more cycles in TCP
>than you would in your custom protocol anyway; and those cycles are
>worth their weight in gold, because they are spent in the service of
>network utilization, which in turn is what buys you throughput.  In
>order to even touch the performance of TCP you would have to invent
>your own TCP-equivalent, and be stuck with fixing and fine-tuning and
>optimizing it for the rest of your life!  And there is no way you
>would ever think of all the subtleties and tricks and optimizations
>that the TCP community has provided solutions for over the years.
>Heck, you would probably never even understand what the bottlenecks
>were!  (This isn't a put-down; I would never be able to either!)
>
>You won't see a big difference in raw data-transfer rates between TCP
>and UDP over Ethernet anyway, because current TCP implementations can
>drive the Ethernet at close to full bandwidth.  And even if there is a
>piddling difference between the two, the overhead of whatever custom
>protocol you might implement is a matter of pure speculation!  My
>advice to you would be to do some profiling and analysis, and find out
>where your real bottlenecks are.  Don't blame TCP!  Don't throw it
>away!  It is your good buddy!  Don't use it as a scapegoat!  If it
>turns out that the network is truly your bottleneck (and you won't
>find this out by looking at TCP/IP vs. UDP performance numbers), then
>maybe you need a faster network, like FDDI.  But first, you should get
>someone who really understands networking to take a look at your whole
>application and find out if you can fine-tune your TCP/IP
>implementation or your application's use of TCP/IP.  Don't assume that
>you can't do any better with TCP/IP than you're doing now.
>
>Good luck,
>-- mark



-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 93 21:25:08 -0600
From:      emusser@mac.cc.macalstr.edu
To:        comp.protocols.tcp-ip
Subject:   Port 23 connection problems

Hello,
	I have a program that tries to access port 23 (the default login
port) as a normal Telnet program would.  I want to be set up as a dumb
terminal without any really complicated stuff.  Just opening a connection
to a VMS systems seems to work but when trying to log into a unix system
the systems seems to send two characters #$ and not log in.  I assume it
asking for some type of information such as login name or terminal.  What
is the easiest way to get around this stuff?  The VMS systems seems to send
a single exclamation point but continues on to the login screen.

	Thanks (I'm not even sure if this is even the right newsgroup for this)
	Eric


-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Sat, 3 Apr 1993 16:40:49 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: Patching whois(1) for new InterNIC

  Source for the whois(1) client program is available free via
anonymous ftp from nic.ddn.mil.  It is probably a lot easier just to
ftp that software down and edit the very small amount of C code, or to
use the "-h" option.

  One of the many stupid things that was said at the IETF meeting by
the new InterDROID contractors was that they had purged the whois
database before moving it.  So unless you own an IP network as either
Admin Contact or Tech Contact, you were probably purged.  If you used
to be in the whois database at nic.ddn.mil, you probably should run
and get re-entered into the new database.

Ran
atkinson@itd.nrl.navy.mil


-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Sat, 3 Apr 1993 20:34:10 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Offloading TCP/IP processing

donp@novell.com (don provan) writes:
}In article <1p9nm2INNecm@news.hi.com> tonyr@hicomb.hi.com writes:
}>Are there any successful examples of offloading some or all of the protocol
}>processing onto a front-end processor?
 
}Gee, it's been a long time since this has come up.  Must be a new trend!
}Anyway, current wisdom is that *generally* offloading TCP does not help.
}There are a few reasons for this, but i think you'll get the idea if i
}just cite the two primary ones.

Not to mention when the IETF introduces IP:tng you may
have bigger problems than just getting new software ...

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

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Sat, 3 Apr 1993 21:15:29 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!

harvey@indyvax.iupui.edu writes:
} ian@unipalm.co.uk (Ian Phillipps) writes:
}>[stuff deleted]
}> To get things in perspective: the class Cs are still allocating in the
}> 193... series.
 
}Oops -- somebody better tell the new NIC then:
 
}% nslookup internic.net
}Name:    internic.net     Address:  198.41.0.5

Note the original posters ".uk" address:  Europe was given a chunk of
IP space to do their own allocations from (192 and 193 if I recall correctly).

}>                That's quite a few more to go. An important problem,
}> which must be (and can be) solved, but not one that's going to stop us
}> in the next few months.
}
}I think running out of class Bs is supposed to be the immediate problem.
}Once using class Cs in blocks becomes common practice then they will start
}disappearing faster too.  Oh well.

Yes.  Getting a class-A now would be nearly impossible (they are ~ 1/2 gone).
Getting a class-B now is moderately tough (about a year left if the current
pace were to continue).  Now that B's are tough to get, and people are getting
blocks of C's in preparation for CIDR, the rate of C allocation will no
doubt accelerate.  Probably a total of 4 +/- 2 years remain.

}>>Thats before you start to consider toasters etc with an internet address.
}>
}> There are more IP addresses available than the toaster population of the
}> earth :-)

A true but useless fact.  IP addresses are handed out in chunks which
really can waste a lot of IP space (for example, how many of their
16 million class-A addresses do you think Stanford Univ. is really using?).
That's ~0.4% of the total IP space wasted right there.

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

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Sat, 3 Apr 1993 21:26:03 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Offloading TCP/IP processing


donp@novell.com (don provan) writes:
}Gee, it's been a long time since this has come up.  Must be a new trend!
}Anyway, current wisdom is that *generally* offloading TCP does not help.
}There are a few reasons for this, but i think you'll get the idea if i
}just cite the two primary ones.


In article <C4xD4z.Cv4@news.iastate.edu>, 
	john@iastate.edu (John Hascall) writes:
>Not to mention when the IETF introduces IP:tng you may
>have bigger problems than just getting new software ...
>
>John

  Actually offloading makes sense for some specialised applications,
though not necessarily for "performance" reasons.

  As to IP:TNG, SIP has paid particular attention to simplifying
protocol processing and -- at first glance -- SIP appears easier to
implement in silicon than IPv4 is.  By contrast, TUBA/CLNP is more
complicated to implement in silicon than IPv4 is.

Ran
atkinson@itd.nrl.navy.mil




-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Sun, 4 Apr 1993 02:16:01 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Offloading TCP/IP processing

atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
}donp@novell.com (don provan) writes:
}}Gee, it's been a long time since this has come up.  Must be a new trend!
}}Anyway, current wisdom is that *generally* offloading TCP does not help.

john@iastate.edu (John Hascall) writes:
>Not to mention when the IETF introduces IP:tng you may
>have bigger problems than just getting new software ...
 
}  As to IP:TNG, SIP has paid particular attention to simplifying
}protocol processing and -- at first glance -- SIP appears easier to
}implement in silicon than IPv4 is.  By contrast, TUBA/CLNP is more
}complicated to implement in silicon than IPv4 is.

True enough, but my point was that your custom IPv4 chip will make
a lovely paperweight in the not too distant future.

Don't get me started on TUBA ...                       ;-)

Here is my version of the Star Trek metaphor:

   IP      Star Trek: The Original Series
   SIP     Star Trek: The Next Generation
   PIP     Star Trek: Deep Space 9
   TUBA    Star Trek: The Borg Proposal (you will be assimilated).

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

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Sun, 4 Apr 1993 04:16:38 GMT
From:      amundson@fairview.cc.ndsu.NoDak.edu (Dennis J. Amundson)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain Names

In article <1993Mar31.195944.7799@walter.bellcore.com>, 
maritza@espresso.bae.bellcore.com (Maritza Ramirez) writes:
>Upps, sorry for the previous subject
>
>Does anyone know which is the maximum
>number of characters allowed for a domain
>name ? (i.e., espresso.bae.bellcore.com)

 RFC-1035 limits the size of a domain name to 255 characters.  Each
single label within the name (expresso, bae, bellcore, com) must
be 63 characters or less.  And I've read the maximum number
of labels within your domain name must be under 128...

-- 
Dennis J. Amundson              E-mail: amundson@fairview.cc.ndsu.nodak.edu
NDSU Computer Center            Bitnet: AMUNDSON at PLAINS
Fargo ND  58105                 Phone:  (701) 298-1042

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 93 11:09:03 GMT
From:      eb@felix.Sublink.Org (Enrico Badella)
To:        comp.protocols.tcp-ip,comp.arch
Subject:   TCP/IP on a chip, anything available?

I heard a rumor of a chip (probably by National Semi) is about to come
out with TCP/UDP/IP protocol stack in it.
Is such a beast feasable, reasonable.....

-- 
Enrico Badella				Internet: eb@felix.sublink.org
Soft*Star s.r.l.			          eb@icnucevx.cnuce.cnr.it
Via Camburzano 9			Phone:    +39-11-746092
10143 Torino, ITALY			Fax:      +39-11-746487

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Sun, 4 Apr 1993 15:39:29 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Primer on Telnet options (was Re: Port 23 connection problems)

emusser@mac.cc.macalstr.edu writes:

}	I have a program that tries to access port 23 (the default login
}port) as a normal Telnet program would.  I want to be set up as a dumb
}terminal without any really complicated stuff.  Just opening a connection
}to a VMS systems seems to work but when trying to log into a unix system
}the systems seems to send two characters #$ and not log in.  I assume it
}asking for some type of information such as login name or terminal.  What
}is the easiest way to get around this stuff?  The VMS systems seems to send
}a single exclamation point but continues on to the login screen.

The Telnet protocol (read RFC 854, available at your favorite rfc
archive site, wuarchive.wustl.edu dir doc/rfc is pretty close you you)
inserts ``options'' into the data stream which you need to extract
and act on (your action may be only to send a "no thanks" back).

John

--------------------- A sample session appears below -------------------------
 

Key to below:
   ff   IAC  (is a command)
   fe   DONT (request for other side to not do this option, next byte is opt#)
   fd   DO   (request for other side to do this option, next byte is option#)
   fc   WONT (indicates you are not willing to do this option, next byte ...)
   fb   WILL (indicates you are willing to do this option, next byte ...)
   fa   SUB  (indicates the start of a suboption)
   f0   SUBE (inidcates the end of a suboption)
Lines starting with ">" is telnet telling what it sent.
Lines starting with "<" is telnet telling what it received.
Stuff inside "{}" are my additional comments.

pooh.cc> telnet
telnet> tog opt
Will show option processing.
telnet> tog net
Will print hexadecimal representation of network traffic.
telnet> open tigger.cc
Trying...
Connected to tigger.cc.iastate.edu.
Escape character is '^]'.
SENT do SUPPRESS GO AHEAD               {SUPPRESS GO AHEAD is #03}
SENT will TERMINAL TYPE                 {TERMINAL TYPE IS #18}
> 0x0   fffd03fffb18                    {IAC DO #03 IAC WILL #18}

< 0x0   fffd18
RCVD do TERMINAL TYPE (don't reply)     {We just asked this, so its an ANSWER}

< 0x0   fffb03fffa1801fff0              {IAC WILL #03 IAC SUB #18 ASK IAC SUBE}
RCVD will SUPPRESS GO AHEAD (don't reply)
Received suboption Terminal type - request to send.

> 0x0   fffa18005654313030fff0          {IAC SUB #18 IS v t 1 0 0 IAC SUBE}
Sent suboption Terminal type - answer is.

                         {CrNlCrNlP r o j e c t   V i n c e n t   /   U }
< 0x0   fffb01fffd1ffffd010d0a0d0a50726f6a6563742056696e63656e74202f2055
< 0x20  4c545249582056342e326120287469676765722e63632e696173746174652e65
< 0x40  6475290d0a0d0d0a0d
RCVD will ECHO (reply)
RCVD do WINDOW SIZE (reply)
RCVD do ECHO (reply)

> 0x0   fffd01fffb1ffffa1f00500018fff0fffc01
SENT do ECHO
SENT will WINDOW SIZE
SENT wont ECHO

Project Vincent / ULTRIX V4.2a (tigger.cc.iastate.edu)

< 0x0   fffe01
RCVD dont ECHO (don't reply)

< 0x0   6c6f67696e3a20
login:
> 0x0    04                       {I type ^D (0x04) to end the session}
 -------------------------------- end of session log ---------------------------
-- 
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

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Sun, 4 Apr 1993 17:12:41 GMT
From:      Boris Yanovsky <boris@netmanage.com>
To:        comp.unix.wizards,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: SLIP questions..


In message <1p7fj3$99a@usenet.INS.CWRU.Edu> , <trier@odin.ins.cwru.edu> says:
> In article <C4nusr.Eqp@ux1.cso.uiuc.edu> simms@ux1.cso.uiuc.edu (dan simms ) 
 writes:
> >BOOTP can't be used since it does an IP broadcast, ...
> 
> This is untrue.  BOOTP over SLIP works fine, as long as the SLIP server
> itself includes a BOOTP server that can tell which of its SLIP connections
> originated the request.
> 
> This is neither far-fetched nor theoretical.  Many people use BOOTP for
> SLIP configuration every day.
> 
> The only "trick" is to ignore the hardware address fields of the BOOTP
> request, and for the BOOTP server to know which SLIP connection the request
> came from.  The only hardware I've used that can do this are Cisco terminal
> servers, but there may be others.
> 
> If your SLIP server is a Unix box, you may have a hard time making this work
> without hacking BOOTP into the SLIP driver in the kernel.

Actually most SLIP servers use a simpler apporach.  They just return your IP 
address in clear text before switching to SLIP mode.  With this configuration 
you can write a simple script to dinamically retrieve your IP address.

***************************************
Boris Yanovsky
NetManage Inc.
20823 Stevens Creek Blvd., Suite 100
Cupertino, CA 95014
phone: (408)973-7171
fax:   (408)257-6405
boris@netmanage.com
***************************************



-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 1993 17:54:51 GMT
From:      GRS00051@CONRAD.APPSTATE.EDU (Jon Craig Austin)
To:        comp.protocols.tcp-ip
Subject:   Re: Offloading TCP/IP processing

In <C4wF5q.9IM@wimsey.bc.ca> skl@wimsey.bc.ca writes:

> In article <1p9nm2INNecm@news.hi.com>, tonyr@hicomb.hi.com wrote:
> >Are there any successful examples of offloading some or all of the
> >protocol processing onto a front-end processor?  ... more interested
> >in general TCP offloading.
> 

IBM has accomplished this in it's mainframe TCP/IP products for MVS and VM
operating systems: TCP/IP for MVS Version 2 Release 2.1:Offload processing
The MVS host runs the TCP/IP product with an IBM 3173-3 Interconnect 
Controller(processor is 80486). The 3172-3 is running IBM OS/2 2.0, and
IBM's TCP/IP for OS/2. Data and control messages go between the host 
and the controller using a CLAW protocol, and network traffic is 
handled by the TCP/IP stacks in the controller under OS/2. 
The function from the user's view is completely transparent. This MVS 
release is currently available and the VM product is coming available 
soon via PTF distrubution.


Jon Austin
grs00051@rodan.acs.appstate.edu


-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Sun, 4 Apr 1993 18:02:45 GMT
From:      peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
To:        comp.protocols.tcp-ip
Subject:   Re: Offloading TCP/IP processing

skl@wimsey.bc.ca (Samuel Lam) writes:

>In article <1p9nm2INNecm@news.hi.com>, tonyr@hicomb.hi.com wrote:
>>Are there any successful examples of offloading some or all of the
>>protocol processing onto a front-end processor?  ... more interested
>>in general TCP offloading.
 
>I can think of two instances of this off-hand...
 
>1) The UBC MTS HIM (University of British Columbia Michigan Terminal
>System Host Interface Machine).  It does the TCP error detection and
>recovery "off-board" and presents the host with a perfect TCP stream.
>The host here is an IBM 370 type system and the front-end is a PDP-11
>type box.  They communicate over an IBM channel.

This seems to be a case where the normal arguments for putting TCP on
the central CPU (keeping up with CPU technology, ease of updating
network software, etc.) would probably favor a front-end approach.

>2) The Excelan (now Microdyne) EXOS 205 series Ethernet boards.  I
>believe the TCP/IP is implemented entirely "off-board" in this case.
>The host is a PC and the front-end is an Intel 80186-based card.
>This pair communicate over the PC's ISA bus.

Well, running your protocol code on an 80186 is one way of ensuring
that the ISA bus won't be a bottleneck, I suppose...

				Peter Desnoyers
-- 

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 93 22:45:24 GMT
From:      wmh356@tijc02.uucp (william higginbotham    )
To:        comp.protocols.tcp-ip
Subject:   Data loss using sockets

HELP!!!!!

We are developing a networked application which communicates using sockets.
The nature of our application is such that we do not want to lose any of
the communication (or at least be able to recover from such loss).  Our
application is able to sense that communications has been lost to its peer.
However, this occurs only after some number of send() calls have succeeded
(and the data placed into the Ethernet buffers) even though the data has
not been sent.  When the communicating processes reestablish communications,
the data that was in the buffers is lost.  This is not good.  I know we could
keep a record of communications that have not been successfully completed but
it seems like there should be a way to have the data in the buffers delivered
upon reconnection.  Does anybody have any insight on how to do this?  Please
email at -

      UUCP:  uunet!tijc02!wmh356
  Internet:  wmh356%tijc02@uunet.uu.net

Thanks,
Mike Higginbotham

Siemens Industrial Automation
Johnson City, TN  37605

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Apr 1993 01:04:03 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Offloading TCP/IP processing

In article <peterd.733946565@pjd.dev.cdx.mot.com>, peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
> skl@wimsey.bc.ca (Samuel Lam) writes:
> 
> >In article <1p9nm2INNecm@news.hi.com>, tonyr@hicomb.hi.com wrote:
> >>Are there any successful examples of offloading some or all of the
> >>protocol processing onto a front-end processor?  ... more interested
> >>in general TCP offloading.
 
> >I can think of two instances of this off-hand...
 
> >1) The UBC MTS HIM (University of British Columbia Michigan Terminal
> >System Host Interface Machine).  It does the TCP error detection and
> >recovery "off-board" and presents the host with a perfect TCP stream.
> >The host here is an IBM 370 type system and the front-end is a PDP-11
> >type box.  They communicate over an IBM channel.
> 
> This seems to be a case where the normal arguments for putting TCP on
> the central CPU (keeping up with CPU technology, ease of updating
> network software, etc.) would probably favor a front-end approach.

Instead of throwing all of TCP off the host, what NSC does for Crays on
FDDI makes a lot of sense to me.  If you talk to a Cray, you'll notice
that the Cray thinks the FDDI MTU is ~32KBytes.  The NSC box fools the
Cray into thinking that the network uses big packets that can be
quickly and most efficiently checksummed and copied and even
protocol-processed by the host.

Error recovery does not seem to me like a good candidate for off-host
handling.  If you want your network to run fast, error recovery must be
very infrequent.  Anything that is very infrequent should be done where
it is easiest to implement, debug, maintain, test, and improve, which
is usually (but I suppose not always) in the host.


> >2) The Excelan (now Microdyne) EXOS 205 series Ethernet boards.  I
> >believe the TCP/IP is implemented entirely "off-board" in this case.
> >The host is a PC and the front-end is an Intel 80186-based card.
> >This pair communicate over the PC's ISA bus.
> 
> Well, running your protocol code on an 80186 is one way of ensuring
> that the ISA bus won't be a bottleneck, I suppose...

Does anyone remember when my employer was commonly said to have a
terrible, buggy, slow, incredibly old, and hard to use TCP/IP
implementation?  When people would regularly say things starting with
"oh, them, ..."?  I'd like to think no one has much reason to say such
things since we dumped the EXOS 203 VME stuff in 1986 in favor of
4.3BSD's networking code.

An 80186 is fast enough to run TCP at 1MByte, but board makers are
usually constrained by the difficulties of updating board firmware, and
by the need to have a board-host interface that will work with every
operating system in the world.

That last point can be seen as part of the ~2X difference in the speed
of TCP/IP on an SGI 4D/320 with what SGI calls an "IPG" board, and the
speed of Sun's with the older Interphase VME FDDI board.  The board
itself is common, the result of a joint effort between Interphase and
SGI, but the firmware and software are completely different.  SGI's 
firmware can work only with the SGI operating system, while
Interphase's has an host-board interface that anyone who has dealt with
Interlan or Excelan boards would find comfortable.  The common, easily
understood, easily implemented host-board interface is not as fast as
other, parhaps kludgy, certainly hard to describe ideas.


Vernon Schryver,  vsj@sgi.com

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Apr 1993 05:31:10 GMT
From:      paul@atlas.abccomp.oz.au (Paul Brooks)
To:        comp.protocols.tcp-ip
Subject:   Re: Retrieving advertised window size / blocking sockets

In article <4497@sapwdf.UUCP> ub@sapwdf.UUCP (Uwe Bloching) writes:
|
|
|Hello TCP/IP-gururs,
|
|
|anybody out there who can help me solving the following problem ?
|
|We have two programs communicating with each other via TCP/IP non-blocking
|stream sockets:
|
| If program A sends data faster than program B can process it, or even worse,
| if program B does not receive data at all, then the send call in program A
| can block. This is absolutely not acceptable for our application A.
| I'm sure that many of you will spontaneously suggest to use non-blocking
| sockets to prevent this - but because of many many other reasons we don't
| want to do this.

Your first paragraph indicated you _were_ using non-blocking sockets! I assume
this was a typo....

| Now my simple question is: Is it possible to "ask" a TCP control process
| (for example in program A) whether it is possible to send data without
| getting blocked ?

Not when sending. The 'select()' system call would allow this for reading,
however 'select()' only tells you that 'some' data can be written, but not
how much. Most systems using blocking calls will block until all the data in
the buffer is written. The only way to do this is to use 'select()' to
find out when at least one octet can be sent, then send only one octet - 
which is a very inefficient way of sending a large block of data.

-- 
Paul Brooks               |paul@abccomp.oz.au      |Emerging Standard:
TurboSoft Pty Ltd         |pwb@newt.phys.unsw.oz.au|  one that has not yet
248 Johnston St. Annandale|                        |  been superseded.
Sydney Australia 2038     |ph: +61 2 552 3088      |  

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Apr 1993 07:57:20 GMT
From:      ruud@prl.philips.nl (Ruud Hendricksen)
To:        comp.protocols.tcp-ip
Subject:   What the hell happens to my IP-options !!!

Hello, It's me again.

Some time ago, I posted a question about the use (set and retrieve)
of IP-options of UDP-datagrams on a Sun SPARC-station with the SunOS
Release 4.1 environment.

All replies pointed into the direction of using the procedure "setsockopt"
with level "IPPROTO_IP" and option-name "IP_OPTIONS".
After some starting problems I *THOUGHT* I had the d*mn this working.
                               ^^^^^^^^^

Here is a part of the source-listing that I used:

L	int	optlen;
L	u_char  optval[80];
L
L	bzero( optval, sizeof( optval ) );
L
L	/* ============================================== */
L	/*  0    1    2    3    4    5    6    7   =  HEX */
L	/* COPY  O_CLASS   -------O_NUMBER-------         */
L	/*  1    1    1    0    0    0    0    1   =   E1 */
L	/* ============================================== */
L	/* COPY when fragmentation is necessary		  */
L	/* O_CLASS 3 = reserved for future use (= BY ME)  */
L	/* O_NUMBER  = just a number			  */
L	/* ============================================== */
L
L	optval[0] = (char)0xE1;		/* COPY + O_CLASS + O_NUMBER */
L	optval[1] = (char)11;           /* O_LENGTH */
L	optval[2] = (char)0;		/* Put */
L	optval[3] = (char)0;		/*  Your */
L	optval[4] = (char)0;		/*   Actual */
L	optval[5] = (char)0;		/*    Data */
L	optval[6] = (char)0;		/*     In */
L	optval[7] = (char)0;		/*      Here */
L	optval[8] = (char)0;		/*       And */
L	optval[9] = (char)0;		/*        It */
L	optval[10] = (char)0;		/*         Works ! */
L	optlen = 12;			/* <<< MUST BE A MULTIPLE OF 4 !!! */
L
L	if ( ( sock = MakeSocket( 0 ) ) >= 0 )		/* a little macro ... */
L	    {
L	    /* And now, for the real thing ..... */
L	    if ( setsockopt( sock, IPPROTO_IP, IP_OPTIONS, optval,optlen ) < 0 )
L		{
L		etc.

For this particular case it went well, but when I started filling in
the zero-bytes, things started going wrong. Somehow the SUN-kernel tries
to interpret the options (even though I introduced an 'unknown' option E1),
and in a lot of cases it will ignore the options totally with the
error-message: "Invalid Argument".

What should I do ? Can somebody out there explain to me what the kernel
tries to do here ? Can I circumvent this "feature" ?

More general questions about new ('unknown') ip-options:
========================================================
- Is the ip-fragmentation-software 'future-proof' in the sense that it can
handle new options that were not known-off at the time of implementation?
- Does it, for instance by default, treat all 'unkown' options as
{option-code,option-length,[possible-rest]} pairs?
- How do hosts handle 'unkown' options? The same way?
- How do routers handle 'unkown' options? The same way?
- Are the 'reserved for future use' option classes forbidden or not?

Is there anybody from SUN who knows everything about this and can help me ?

Please reply direct.
Thanks in advance,
Ruud.

==========================================================================
    Ruud Hendricksen                   e-mail: ruud@prl.philips.nl
        A VIRGO IN DISTRESS AGAIN
        (Why do I always have to solve these nasty problems...)
==========================================================================

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 1993 09:08:46 GMT
From:      antonis@intranet.gr (Antonis Kyriazis)
To:        comp.protocols.tcp-ip
Subject:   Re: What is an "ip unnumbered serial line" ?

In article AnE@aaahq05.aaa.com, mikel@aaahq05.aaa.com (Mikel Manitius) writes:
> 
> If you are running PPP this is no longer necessary. Each router has only one
> IP address (assuming only one Ethernet per router). It uses the same IP address
> to identify itself on both ends, since it's a Point-to-Point link.

No, this is sometimes false. There might be need for assigning one IP
address to each physical (or logical) interface. For example 3COM
accepts two physical serial lines to compose a single logical "port"
which has to be assigned an IP address.  So, the answer depends on the
hardware platform being used for the particular routing case.

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


-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 1993 09:21:21 GMT
From:      antonis@intranet.gr (Antonis Kyriazis)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Frame too short...


Hi

Recently we expanded a thin ethernet segment, by attaching a 12-UTP
port hub. Unfortunately the users (3C503-TP) complain about NFS
problems: They mount (with PC-NFS) directories on a HP-UX system and
PKZIP or XCOPY don't work. A capture from Sniffer indicated "frame too short" for the frames generated from the PC when trying to NFS-write and "may be more in subsequent frames". Has someone any idea?

thanx in advance
+-------------------------------------------------------------------+
|     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 - +
+-------------------------------------------------------------------+


-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 93 14:50:34
From:      amoss@shuldig.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip
Subject:   Re: Port 23 connection problems

emusser@mac.cc.macalstr.edu writes:

   Hello,
	   I have a program that tries to access port 23 (the default login
   port) as a normal Telnet program would.  I want to be set up as a dumb
   terminal without any really complicated stuff.  Just opening a connection
   to a VMS systems seems to work but when trying to log into a unix system
   the systems seems to send two characters #$ and not log in.  I assume it
   asking for some type of information such as login name or terminal.  What
   is the easiest way to get around this stuff?  The VMS systems seems to send
   a single exclamation point but continues on to the login screen.

	   Thanks (I'm not even sure if this is even the right newsgroup for this)
	   Eric


The BSD telnet daemon initiates some TELNET protocol commands (byte 255
followed by a couple or so bytes, depends on the command).  If you aren't
interested in interpreting TELNET commands in any way then you can just ignore
them by discarding them and replying "yah yah" to what telnetd tells you, see
the BSD FTP client for an example on how to do it.

Cheers,

--Amos (who just wrote a telnetd replacement for firewalls)

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


-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 1993 19:36 CST
From:      alex@dt.uh.edu (Alexandre Khalil)
To:        alt.internet.services,comp.protocols.tcp-ip
Subject:   Re: NREN Info

In article <C514MH.D4q@csn.org>, jls2@teal.csn.org (Jeff Stoner) writes...
>I'm searching around to find discussions about the proposed new National
>Research and Education Network (NREN). Is there a certain newsgroup that
>I haven't found, or a mailing list I should join?

  Subscribe to COMMUNET by sending mail to ListServ@AUVMVM with a body of

subscribe COMMUNET your name
set COMMUNET digest

  The second line will help prevent the shock of seeing your mailbox flooded
by the 20-40 odd messages that are coming in daily.

alex


-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 1993 19:48 CST
From:      alex@dt.uh.edu (Alexandre Khalil)
To:        alt.internet.services,comp.protocols.tcp-ip
Subject:   Re: NREN Info

In article <5APR199319364912@uhdvx3.dt.uh.edu>, alex@dt.uh.edu (Alexandre Khalil) writes...
>In article <C514MH.D4q@csn.org>, jls2@teal.csn.org (Jeff Stoner) writes...
>>I'm searching around to find discussions about the proposed new National
>>Research and Education Network (NREN). Is there a certain newsgroup that
>>I haven't found, or a mailing list I should join?
> 
>  Subscribe to COMMUNET by sending mail to ListServ@AUVMVM with a body of
                                                    ^^^^^^^^
  oooops                                             @UVMVM

>subscribe COMMUNET your name
>set COMMUNET digest
> 
>  The second line will help prevent the shock of seeing your mailbox flooded
>by the 20-40 odd messages that are coming in daily.
> 
>alex
> 

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 93 14:36:02 GMT
From:      trt@duke.cs.duke.edu (Tom Truscott)
To:        comp.protocols.tcp-ip
Subject:   Re: Mysterious socket delays

[apologies if this is a reprint.]

You are most definitely running afoul of the "small-package avoidance"
algorithm, and use of TCP_NODELAY should have fixed it.
(The 0.2 second delay is a smoking gun.)
The follow call should work:

        int yes = 1;
        if (setsockopt(fd, IPPROTO_TCP, TCP_NODELAY,
                        (char *)&yes, sizeof(yes)) != 0)
                perror("setsockopt");

While on this subject, does anyone's implementation of small-packet
avoidance detect such "multiple-send/receive" RPC patterns
and do something more sensible than bring TCP/IP to a crawl?

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Apr 1993 18:45:01 GMT
From:      gallo@sirius.gsi.fr (Jean-Luc Gallo)
To:        comp.protocols.tcp-ip
Subject:   Looking for a file tranfert product

I'm looking for a file transfert implementation over TCP/IP which must
provide the following functionnality in addition to those found in FTP:
	* retrieve after a connection lost.
	* accounting facilities
	* monitoring facilities
		Example: a monitoring Xsession displaying all the active sessions
		and performance information.
	* API in C language (or C++)
Any pointer or  reference to public domain or even commercial software?
Thank's in advance
Jean-Luc


--
-------------------------------------
Jean-Luc Gallo
  GSI (Generale Service Informatique)
  4 Rue Sentou
  92150 Suresnes
E-mail: Jean-Luc.Gallo@gsi.fr
Voice : (33)-1-41181425 
Fax   : (33)-1-41181401

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 93 19:25:14 GMT
From:      bashford@srs.loral.com (Dave Bashford)
To:        comp.protocols.tcp-ip
Subject:   MIL-STD, DOD-STD #'s for {TCP,UDP}/IP ?

Can some please point me to the goverment standards that define/? the
Internet protocols ? We have the RFC's, but apparently they aren't as
impressive as MIL-STD, DOD-STD references in documentation and proposals.
-- 

db
bashford@srs.loral.com (Dave Bashford, Sunnyvale, CA)

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Apr 1993 21:20:40 GMT
From:      jls2@teal.csn.org (Jeff Stoner)
To:        alt.internet.services,comp.protocols.tcp-ip
Subject:   NREN Info

I'm searching around to find discussions about the proposed new National
Research and Education Network (NREN). Is there a certain newsgroup that
I haven't found, or a mailing list I should join?

Thanks!

-- 
====== Jeff L. Stoner === Boulder, Colo. ============ /\ = /\ ========== |
                                                 /\  /  \ /  /\  /\    --*--
   Home: jls2 @ bearhug.boulder.co.us         /\/  \/    /  /  \/  /\    |
   News: jls2 @ csn.org                    /\/  \   \  /\  /    \    /\

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Apr 93 21:26:53 GMT
From:      maritza@bae.bae.bellcore.com (Maritza Ramirez)
To:        comp.protocols.tcp-ip
Subject:   Re: Pocket guide anonymous ftp setup

In article <28523@suned1.Nswses.Navy.MIL>, efb@slced1.nswses.navy.mil (Everett F Batey) writes:
|> Hope one of you will remember where you last saw a guide to setting up 
|> anonymous ftp .. cant find it anymore .. help appreciated /Ev/
|> --
 


If you are on a Unix system, you can check the ftpd man page

Maritza

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 1993 21:48:01 GMT
From:      vern@daffy.ee.lbl.gov (Vern Paxson)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

Something that's been puzzling me is whether the assigned IP addresses are
really in use.  I've been tracing all wide-area traffic between LBL (where
I work) and the rest of the world.  In the process I've built up a database
of network addresses (for use in producing traffic maps; see my hopefully-
upcoming SIGCOMM '93 paper).  The database now spans six solid month's
worth of data (2 million connections), taken over a two year period.  Over
that time period and all those connections, the traces show connections to
the following address blocks:

	Class A
		 8.*.*.*
		13.*.*.*
		15.*.*.*
		16.*.*.*
		17.*.*.*
		18.*.*.*
		26.*.*.*
		31.*.*.*
		35.*.*.*
		36.*.*.*
		38.*.*.*
		45.*.*.*

	Class B
		128.*.*.* - 134.*.*.*
		136.*.*.* - 153.*.*.*
		155.*.*.* - 164.*.*.*

	Class C
		192.*.*.*
		193.*.*.*
		198.*.*.*

And that's it.

What I'm wondering is, what proportion of the remaining address blocks are
actually in use?  Are class B address from 165-191 still available?  These
represent 40% of the class B address space ...

		Vern

	Vern Paxson				vern@ee.lbl.gov
	Systems Engineering		        ucbvax!ee.lbl.gov!vern
	Lawrence Berkeley Laboratory		(510) 486-7504

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 1993 22:59:50 GMT
From:      booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
To:        comp.protocols.tcp-ip
Subject:   Re: Offloading TCP/IP processing

In article <h34o146@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>Instead of throwing all of TCP off the host, what NSC does for Crays on
>FDDI makes a lot of sense to me.  If you talk to a Cray, you'll notice
>that the Cray thinks the FDDI MTU is ~32KBytes.  The NSC box fools the
>Cray into thinking that the network uses big packets that can be
>quickly and most efficiently checksummed and copied and even
>protocol-processed by the host.

Actually the NSC FDDI adapter for the Cray is acting like a router.  The
Cray side of the adapter looks like HYPERchannel to the Cray, hence the
large MTU is ok.  The other side connects to the FDDI ring.  Since the adapter
is routing, the ring side of the adapter has to be a different subnet from the
Cray side.  As a consequence, you eat up one subnet for each Cray on the ring. 

You can use an MTU of 32 KB, but the adapter will have to fragment it to
send it onto the ring.  Thus, we run with an MTU of 4 KB.

NSC has an option to run in what they call "HYPERchannel emulation mode," in 
which case they get around fragmenting by faking HYPERchannel over FDDI, but 
it only allows you to talk to machines capable of dealing with this mode which 
sort of shoots interoperability to pieces.

mb
-- 
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948
Disclaimer:  booloo speaks for booloo and no other.

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Apr 93 00:17:58 GMT
From:      ajw@squid.mel.dit.CSIRO.AU (Andrew Waugh)
To:        comp.protocols.tcp-ip
Subject:   Internet/NREN Business Journal

There is apparently a new journal to be published with the title
of:

	The Internet/NREN Business Journal
	(ISSN 1192-8646)

Can anyone supply me with contact information for this new journal
(e.g. for subscriptions)?

andrew waugh

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 1993 10:27:29 -0400
From:      mo@rodan.UU.NET (Mike O'Dell)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on a chip, anything available?

Once upon a time, Steve Holmgren did a TCP/IP implementation
on a FORTH single-chip microcontroller with the intention of
replacing UART chips in dumb terminals to make TCP-able terminals.
it actually worked amazingly well, but it never really
got product-ized.

so it certainly can be done..............
(if you're Steve Holmgren)

	-Mike

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 93 06:28:07 GMT
From:      antony@ee.uts.edu.au (Antony Richards)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Giga bit networks, what are the limiting factors? (SUMMARY)



Thankyou to all the people who repied to the question.  The answers where very
interesting.  The question was:-

>The current trends in computer technology is that processing power & network
>bandwidth have exponential improvement, and the cost of memory is plummeting.
>For argument's sake, lets assume that these quantities reach infinite power
>for no cost.
>
>What factors will limit the manipulation of data in such a distributed
>environment?
>
>There are two factors that I have thought of so far.  Firstly, the memory
>access time.  This is evident by looking at the RISC processor architecture.
>Once data is in a cache, the manipulation of data is very quick.  But, this
>approach is inefficient for calculations that involve touching a lot of data
>only once (such as doing character conversions).  The other factor that I have
>identified is the bus bandwidth.
>
>I would appreciate other peoples views on this topic.


Briefly, the replies suggested that the following limitation would occur.



Here is a summary of the reples that I received by post only.  My apploigies
if I accidently left out anybody.


----------
From velthuys@cs.ubc.ca Fri Mar 19 05:00:51 1993

In comp.protocols.misc you write:

>Hi,
 
>The current trends in computer technology is that processing power & network
>bandwidth have exponential improvement, and the cost of memory is plummeting.
 
>For argument's sake, lets assume that these quantities reach infinite power
>for no cost.

A more realistic chareacterization is saying something 
   more then  the sufficient power for  acceptable costs.

>What factors will limit the manipulation of data in such a distributed
>environment?

As you mention:

1) Memory access time/buffering. most of the time data is first put in
   a buffer and then put out on the network or vice versa. Also, the 
   buffered data must be passed on to other processes for processing.
2) Bus bandwidth (how is that defined anyway ?)
3) Operating system overhead. It is not uncommon to see dedicated
   OSs for communication purposes. This way, overhead can be reduced, 
   and all available processing power can be focussed towards the 
   processing and forwarding of data.
4) Amount of processing per data unit per protocol entity in the 
   network -> too high, implies loss of speed/bandwidth.
5) nr. of intermediate nodes in the network: each node adds a certain
   amount of overhead.
6) Generation and acceptance of data by the applications on each side
   of the connection. They have to be capable of dealing with huge 
   amounts of data.
7) Network congestion. This problem is often related to routing mechanisms
   employed.

>I would appreciate other peoples views on this topic.

Hope this helps.

Rolf
--
velthuys@cs.ubc.ca


----------
From mdailey@hpwali.wal.hp.com Wed Mar 24 01:22:26 1993

In article <1993Mar18.135024.14683@hubcap.clemson.edu>,
antony@ee.uts.edu.au (Antony Richards) writes:

|>What factors will limit the manipulation of data in such a distributed
|>environment?
|>
|>
|>There are two factors that I have thought of so far.  Firstly, the memory
|>access time.  This is evident by looking at the RISC processor architecture.
|>Once data is in a cache, the manipulation of data is very quick.  But, this
|>approach is inefficient for calculations that involve touching a lot of data
|>only once (such as doing character conversions).  The other factor
 that I have
|>identified is the bus bandwidth.
|>

Anthony,

>From my perspective some of the largest factors aside from the ones you
mentioned are 
as follows:

 (1) Sequential nature of protocol stacks.  If you want to parse data
quickly you first
 have to ascend the network protocol stack associated with the data.  If
you're dealing
 with gobs of data such as voice or video, then the data needs to have
very little in
 the way of protocol headers to reduce parsing overhead and increase
throughput.
 Even if bandwidth is infinite, it does no good if the processor can't
keep up with the
 overhead imposed by network layers.

 The flip side is that if you reduce the network headers, then you run
the risk of
 limiting the scope of the data - i.e. to a local area network or a section of 
 local area network.  Some of the network layers buy you addressing,
routing and
 delivery guarantees.  Depending upon scope, you may or may not need these.

 (2) Von Neumann architecture is limited in its ability to handle
multiple data 
 streams.  Realistically to handle stuff like radar, image and highly complex 
 engineering or physical calculations you need the ability to operate on data 
 in parallel.  Theoretical approaches I've seen have been applied to
Optical Computing
 architectures, whereby an entire plane of a matrix is handled in one
clock cycle.
 There are alot of papers written on the subject: the journal 'Optical
Engineering'
 had a bunch four years ago, and an IEEE Spectrum (I think) around that
time covered
 the topic.  Additionally, I was recently surprised to see a new book by
MIT Press
 on Optical Computing. I really don't remember the title or authors.

 (3) Even if you have 32 or 64 bits, I think eventually you'll hit the
wall in terms of
 addressing space.  It depends of course on how much data you're
manipulating, but 
 patching schemes like sparse matrices introduce additional design
complexity and 
 processor load.  (I think.)

Good luck.  I'd like to hear what other issues you identify. 

     Mike
                       
-------------------------------------------------------------------------------
    | Mike Dailey
    | Hewlett-Packard Company, Medical Products Group
    | 175 Wyman Street, Waltham, MA 02254-9030  
    | internet email: mdailey@hpwali.wal.hp.com
    | Disclaimer: Any opinions expressed are mine and not those of my employer.
-------------------------------------------------------------------------------



----------
From jtw@pmws.lcs.mit.edu Fri Mar 19 10:21:06 1993

   From: antony@ee.uts.edu.au (Antony Richards)

   The current trends in computer technology is that processing power &
   network bandwidth have exponential improvement, and the cost of memory
   is plummeting.

   What factors will limit the manipulation of data in such a distributed
   environment?

Other than the ones you mention, a primarily important one is the
speed of light.

You might want to read "Architectural Considerations for a New
Generation of Protocols", by Clark and Tennenhouse, in the proceedings
of ACM Sigcomm 90 (could be 91? 89? not sure..)

				regards,
				   -john
John Wroclawski
jtw@lcs.mit.edu



----------
From owhadi@tempest.rice.edu Fri Mar 19 02:04:18 1993

For the bus bandwidth, have you thougth about optic fiber. The limit of bus bandwidth is far away. Today, we know how to do optic fiber busses, but it is still expensive.

Eric owhadi.
owhadi@geophysics.rice.edu


----------
From dfk@wildcat.dartmouth.edu Fri Mar 19 08:49:24 1993

   What factors will limit the manipulation of data in such a distributed
   environment?

I/O to "permanent" storage devices (ie, those that survive without
power). You may have fast networks and large fast RAM memories, but
unless something dramatic happens (cheap fast NVRAM or radical new
optical storage technology) we'll be increasingly limited by the need
to move data to and from permanent storage of some kind (currently,
magnetic or optical disk or tape).

dave


----------
Finally, thanks again to everybody who replied.

Antony.

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Tue, 06 Apr 1993 16:02:20
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Protocols: Minimal Implementation Requirements

In article <1993Mar23.193550.2646@walter.bellcore.com> maritza@espresso.bae.bellcore.com (Maritza Ramirez) writes:

    Does the "minimal implementation" requirement for an Internet
    protocol - such as FTP - apply just to the set of commands that
    a server must implement ? ... or does any tcp/ip client must 
    support a minimal set of commands too ?

You MUST support the MUSTs in IP and ICMP, including anything like ARP
that is required for the media you're connecting to.  All the layered
protocols above that are optional (although some might opine that SNMP
and thus UDP are also MUSTs).  If the system you're working on needs to
use a particular upper-layer protocol, follow the MUSTs (although Don
was right that clients can be simpler than servers).

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488


-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 93 11:15:53 GMT
From:      ercm20@festival.ed.ac.uk (Sam Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain Names

amundson@fairview.cc.ndsu.NoDak.edu (Dennis J. Amundson) writes:
>  RFC-1035 limits the size of a domain name to 255 characters.  Each
> single label within the name (expresso, bae, bellcore, com) must
> be 63 characters or less.  And I've read the maximum number
> of labels within your domain name must be under 128...

You don't need to read anything to tell you that - you just need to be
able to do arithmetic... :-) (or have I fallen for it?)

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

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 1993 12:59:25 GMT
From:      mjr@tis.com (Marcus J Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Performance comparison TCP vs UDP on LANs

heilbron@Informatik.TU-Muenchen.DE (Stephen Heilbronner) writes:
>I forgot to mention in my original posting (it is
>quoted below) that the processes of our application 
>also need to do a sort of reliable 
>multicasting.

	Oh, a *little* thing like multicasting. Hardly worth mentioning
at all...
	What the difference between "a sort" of reliable multicasting
and reliable multicasting?

mjr.

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Apr 93 13:05:50 GMT
From:      news@nlm.nih.gov
To:        comp.protocols.tcp-ip
Subject:   How to configure IP address dynamically using PCNFS?

Hi,

I am trying to have a client/server setup where any users with a PC may call 
my SPARCstation using SLIP.  I am using PCNFS 4.0a,  PC with Windows 3.0,
Borland C 3.1, Sparc running SunOS 4.1.  

I had tested a simple SLIP network between a PC and a SPARC using static
configuration.  This is okay for development since I know the IP address 
of the PC and the SPARC.  However the end product may be accessed by anyone.  

Can dynamic configuration be setup using PCNFS?
What is bootp and how does it work?
How do I setup bootp and where can I get a bootp that works with PCNFS?
Does bootp work with a Cisco terminal server?

I am pretty new to this serial communications stuff, any advices  would
be much appreciated.

Thanks in advance.

Tin Li

National Library of Medicine, NIH

li@nlm.nih.gov


-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 93 13:38:58 GMT
From:      aroby@andersen.co.uk (Tony Roby)
To:        comp.protocols.tcp-ip
Subject:   Re: file permissions criteria on FTP

maritza@espresso.bae.bellcore.com (Maritza Ramirez) writes:

>Does anyone know how is it determined - in Unix - the permissions 
>that a given file will have in the receiving end ?

Many ftp implementations support the umask command (try site umask), 
which enables you to specify the permissions of the target file.

Tony

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Apr 1993 15:00:52 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!

>harvey@indyvax.iupui.edu writes:
>} ian@unipalm.co.uk (Ian Phillipps) writes:
 
>}>>Thats before you start to consider toasters etc with an internet address.
>}>
>}> There are more IP addresses available than the toaster population of the
>}> earth :-)

I should hope so!  I don't know about the rest of you, but I have a heck of 
a lot more more IP addresses than I do toasters.  

Erick

-- 
Networking is the concept of having data, finding it somewhere else and 
thinking that it's a good thing.  A distributed environment just means 
you are less picky about where it ends up before calling the whole 
process a success.  Plumbers call it a leak.

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Apr 1993 15:17:09 GMT
From:      mills@ccu.umanitoba.ca (Gary Mills)
To:        comp.protocols.tcp-ip
Subject:   host route to the loopback interface

I've set up two static host routes to the loopback interface on a
Sun-4/630, and I'm using gated to announce only those routes via RIP.
This all seems to work correctly, and other hosts on the two subnets
have the correct entries in their routing tables.  However, on the
4/630, the routing table looks like this:

Routing tables
Destination          Gateway              Flags    Refcnt Use        Interface
127.0.0.1            127.0.0.1            UH       4      4037       lo0
130.179.32.12        127.0.0.1            UH       0      44         lo0
130.179.16.12        127.0.0.1            UH       38     1124698    lo0
130.179.112.0        130.179.17.54        UG       0      0          le0
130.179.72.0         130.179.16.65        UG       0      38864      le0
130.179.200.0        130.179.17.59        UG       0      32         le0
130.179.192.0        130.179.17.58        UG       0      88         le0
...

I didn't expect the host routes to be actually used.  Have I introduced
a problem or an inefficiency?  I could point the static routes to the
ethernet interfaces instead.  Would that be better or worse?

-- 
-Gary Mills-         -Networking Group-          -U of M Computer Services-

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 1993 15:41:19 GMT
From:      bob@hobbes.dtcc.edu (Bob Rahe)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp on IBM AS400

In article <1993Apr2.105918.11813@gsi.fr> Yves Tremolet <yves.tremolet@gsi.fr> writes:
>Hello,
 
>Does anybody knows an implementation of ftp on the AS400
>either public or commercial ?

  It's part of IBMs TCP/IP package for the AS/400.  We have one site using
it.  All I know is that it is and IBM product and it has a thick manual,
does FTP, TELNET etc. etc.  And that it works - ftp files to and from our
Unisys A-series all the time.

-- 
-------------------------------------------------------------------------
|Bob Rahe, Delaware Tech&Comm College | AIDS, Drugs, Abortion: -        |
|Internet: bob@hobbes.dtcc.edu        |  - Don't liberals just kill you?|
|CI$: 72406,525 Genie:BOB.RAHE        |Save whales; and kill babies?    |
-------------------------------------------------------------------------

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 93 16:03:29 GMT
From:      cmaeda+@cs.cmu.edu (Christopher Maeda)
To:        comp.protocols.tcp-ip
Subject:   Re: Offloading TCP/IP processing

In article <h34o146@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <peterd.733946565@pjd.dev.cdx.mot.com>, peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
>> skl@wimsey.bc.ca (Samuel Lam) writes:
>> 
>> >In article <1p9nm2INNecm@news.hi.com>, tonyr@hicomb.hi.com wrote:
>> >>Are there any successful examples of offloading some or all of the
>> >>protocol processing onto a front-end processor?  ... more interested
>> >>in general TCP offloading.
 
>> >I can think of two instances of this off-hand...
 
>> >1) The UBC MTS HIM (University of British Columbia Michigan Terminal
>> >System Host Interface Machine).  It does the TCP error detection and
>> >recovery "off-board" and presents the host with a perfect TCP stream.
>> >The host here is an IBM 370 type system and the front-end is a PDP-11
>> >type box.  They communicate over an IBM channel.
>> 

Another system to look at is the Nectar prototype done at CMU.  They
have a paper in 1990 Sigcomm, I think.

>Error recovery does not seem to me like a good candidate for off-host
>handling.  If you want your network to run fast, error recovery must be
>very infrequent.  Anything that is very infrequent should be done where
>it is easiest to implement, debug, maintain, test, and improve, which
>is usually (but I suppose not always) in the host.

There is nothing wrong with doing error-recovery off-host.  However,
error-recovery will be an infrequent and exceptional condition so you
shouldn't care about making it go fast.  The common case is the one
that matters.

So the arguments I've seen against protocol co-processors are mostly
market-oriented ones: the CPU in the NETFEP might not get upgraded on
the same schedule as the main CPU, the software in the NETFEP might
get old.  These problems go away if the NETFEP is an integral part of
the machine and if the OS can download code to the NETFEP.

It seems like a co-processor that does all the protocol processing and
VDMA's the data stream directly into the end-user's address space
without any critical-path interaction with the operating system can be
a big performance win.  Aren't a lot of "smart" ATM interfaces trying
to do this exact thing?  


-- 
Chris Maeda, Grad Student and RetroGrouch <cmaeda@cs.cmu.edu>
"A unix signature isn't a return address, it's the ASCII equivalent of
a black velvet clown painting. It's a rectangle of carets surrounding
a quote from a literary giant of weeniedom like Heinlein or Dr. Who."

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Tue,  6 Apr 93 17:06:29 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   RE: MIL-STD, DOD-STD #'s for {TCP,UDP}/IP ?

In Article <1993Apr5.192514.20833@scf.loral.com>
bashford@srs.loral.com (Dave Bashford) writes:
>Can some please point me to the goverment standards that define/? the
>Internet protocols ? We have the RFC's, but apparently they aren't as
>impressive as MIL-STD, DOD-STD references in documentation and proposals.

Impressive or not, last time I looked the MIL-STD specs were in terrible shape
and filled with errors. If you get software that meets those specs, you will
have useless software.

Some may wish to correct me on this if the MIL specs have been updated. It's
a while since I looked at them.

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

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

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Apr 93 19:53:56 GMT
From:      news@nlm.nih.gov
To:        comp.protocols.tcp-ip
Subject:   PC-NFS and SLIP restrictions

Hi,

I am using PC-NFS 4.0a with PCs as SLIP clients, a SPARC as a SLIP server,
and a Cisco terminal server.

When using SLIP with PC-NFS, each PC's name and user ID must be specified
in file /etc/slip.hosts and each PC must also have its own IP address within 
the SLIP network.  The problem is I will have many dial-up users and I
don't know anything about them.  The PC-NFS documentation suggests sharing 
PC name and address among several users.  

Is there any way where the SLIP server can accept any connection requests and 
reply with an address for future communications? 

If PC-NFS cannot do it, will any other TCPIP/SLIP packages (PD or non-PD) 
have such a capability.

Thanks in advance.

Tin Li
National Library of Medicine, NIH

li@nlm.nih.gov


-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Apr 1993 20:52:17 GMT
From:      mikel@aaahq05.aaa.com (Mikel Manitius)
To:        comp.protocols.tcp-ip
Subject:   Re: What is an "ip unnumbered serial line" ?

In article j27@helios.intranet.gr, antonis@intranet.gr (Antonis Kyriazis) writes:
> In article AnE@aaahq05.aaa.com, mikel@aaahq05.aaa.com (Mikel Manitius) writes:
> > 
> > If you are running PPP this is no longer necessary. Each router has only one
> > IP address (assuming only one Ethernet per router). It uses the same IP address
> > to identify itself on both ends, since it's a Point-to-Point link.
> 
> No, this is sometimes false. There might be need for assigning one IP
> address to each physical (or logical) interface. For example 3COM
> accepts two physical serial lines to compose a single logical "port"
> which has to be assigned an IP address.  So, the answer depends on the
> hardware platform being used for the particular routing case.

Actually, that's right. PPP gives you the ability to avoid having to assign
a seperate IP address for the interface if your configuration permits and/or
if you don't want to.

And even if you do have to assign a seperate IP address, you can still avoid
having to make it a seprate network. You could use an available address on
the same network as the router is on. It just gives you more flexability.
---
						Mikel Manitius
						mikel@aaa.com


-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Apr 1993 22:25:03 GMT
From:      rod@elmo.rosemount.com (Rodney Drenth)
To:        comp.protocols.tcp-ip
Subject:   Looking for example bootp request

I'm looking for an example of some source code that does a bootp
request. My app needs to get ip address information contained in
the reply.
I do not need or want code for retrieving the boot file.

-- 

Rodney L. Drenth		rod@elmo.rosemount.com
software engineer		Fisher*Rosemount Systems Division
				Burnsville, MN.
				ph. (612)-895-2414


-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 93 00:02:42 GMT
From:      mark@verdix.com (Mark Lundquist)
To:        comp.protocols.tcp-ip
Subject:   Re: Performance comparison TCP vs UDP on LANs

Thanks for your gracious response to my totally missing your point!
I'm glad you enjoyed my post, though :-)

In article <1993Apr3.085934.26620@Informatik.TU-Muenchen.DE> heilbron@Informatik.TU-Muenchen.DE (Stephen Heilbronner) writes:
>
>I forgot to mention in my original posting (it is
>quoted below) that the processes of our application 
>also need to do a sort of reliable 
>multicasting. From the replies and postings I got so far
>I'm aware that UDP with my requirements has no performance
>advantages over TCP when it comes to one-to-one connections.
>
>But I'm wondering whether this still holds true when
>apps need to do reliable multicasting ? Does anybody know
>of public domain or research work that implemented reliable
>multicasting on top of UDP or raw sockets?

You might take a look at RFC-1235, Coherent File Distribution
Protocol.  There's also RFC-1301, Multicast Transport Protocol.  I
don't know much about either of these, but they might be worth
something to you (you can find them on nic.ddn.mil).


>Another question is, whether there are problems with the
>kernel running out of sockets when heavy connecting/disconnecting
>is going on. This because of what the UNIX manual pages call
>"lingering" in order to avoid imediate reuse of identifiers
>of closed connections.

Yes (actually it's TCB's the kernel will run out of -- or memory to
allocate TCB's from -- not sockets).

To be precise though, this is not what lingering is.  You're really
referring to the TIME_WAIT state entered by the first peer to do a
close() on the connection.  Lingering is something different; it's a
synchronous (blocking) close w/timeout, for applications that need to
know that all pending data has been sent.

hope this helps,
--mark

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Wed, 07 Apr 93 01:43:30 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Giving back an IP address !!!

In article <C52HpH.Hrp@watserv1.uwaterloo.ca> erick@sunee.uwaterloo.ca writes:

   >harvey@indyvax.iupui.edu writes:
   >} ian@unipalm.co.uk (Ian Phillipps) writes:
 
   >}>>Thats before you start to consider toasters etc with an internet address.
   >}>
   >}> There are more IP addresses available than the toaster population of the
   >}> earth :-)

   I should hope so!  I don't know about the rest of you, but I have a heck of 
   a lot more more IP addresses than I do toasters.

Me, too.  In fact, I have an order of magnitude more IP addresses
than I do pieces of electronic equipment.

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

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Apr 1993 02:04:26 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Protocols: Minimal Implementation Requirements

jbvb@ftp.com writes:
}maritza@espresso.bae.bellcore.com (Maritza Ramirez) writes:
}
}    Does the "minimal implementation" requirement for an Internet
}    protocol - such as FTP - apply just to the set of commands that
}    a server must implement ? ... or does any tcp/ip client must 
}    support a minimal set of commands too ?
}
}You MUST support the MUSTs in IP and ICMP, including anything like ARP
}that is required for the media you're connecting to.  All the layered
}protocols above that are optional (although some might opine that SNMP
}and thus UDP are also MUSTs).  If the system you're working on needs to
}use a particular upper-layer protocol, follow the MUSTs (although Don
}was right that clients can be simpler than servers).

In addition, you must not do any of the MUST NOTs.  And to be
considered "unconditionally compliant" (as opposed to conditionally)
you need to do the SHOULDs (probably a darn good idea anyway).
This is all discussed in detail in RFC 1122 (lower layers) and
RFC 1123 (application layers) -- available at an ftp archive near you.

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

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Apr 1993 02:22:07 GMT
From:      Jason Haar <j.haar@csc.canterbury.ac.nz>
To:        comp.protocols.tcp-ip,comp.infosystems
Subject:   Whois servers for SunOS?

Hi,

Anyone know of a whois _server_ that will run on a Sun? 


--

Cheers

Jason Haar, Network Consultant

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 93 09:17:22 EDT
From:      glazer@ohstpy.mps.ohio-state.edu
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   looking for uuencode source

I am looking for Pascal source for the UUENCODE scheme.  Does such a thing
exist?  Can someone point me to it?  If you know of C code, that would be
ok too but I'd really rather look at the pascal code.

Thanks for any help!

Jon


-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 93 05:25:00 GMT
From:      jerry@olivea.atc.olivetti.com (Jerry Aguirre)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <1o7sps$7rh@hpscit.sc.hp.com> radle@corp.hp.com (Andy Radle) writes:
>In HP's case, we've issued more than 100,000 ip addresses.  I think that's a
>legitimate use of a class A address.

Not to imply that HP made the wrong choice, by choosing a class A
instead of several class B's they did the internet a favor.  But
100,000/16,000,000 is less than 1%.  If 99% wastage is "legitimate" then
it is easy to see why we are running out of addresses.

My oppinion is that the decision to split the classes, especially with
256 to 1 scaling, was a mistake.  And all this was to avoid sending the
net width information around with the routes.  Information that can be
encoded in 5 BITS!

Suppose you went to the store and they had two sizes, the one ounce size
and the 16 pound.  You need about 2 pounds (16 ounces/pound for you
metric people) so you can either buy 32 of the small or one of the big.
Oh yea, the big costs the same as each little.  So you get the 16 pound
and 14 pounds of it turns to green slime in the back of your
refrigerator.  The resturant has choice of the 16 pound or the 2 ton
size, still at the same price.

And then there was the choice of a class A, 16 million addresses, for
the loopback addresses.  Put IP with the buffalo and the passenger
pigeon; inexhaustable until they are suddenly all gone.

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 93 05:34:45 GMT
From:      jerry@olivea.atc.olivetti.com (Jerry Aguirre)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <732541036snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
>Again, how many of these are you *using*?   If the subnet is not
>connected to the Internet, why use up an Internet address?

Even if most of the addresses are behind a firewall and have no external
access they still need unique addresses.  The firewall system needs to
talk to both.

One branch insisted on using unallocated class C addresses.  I
admonished them and made sure those routes never leaked to the internet.
Then a company we work with got on the internet.  Guess what class C
address they got?  All email to that company stopped until I happened to
do a traceroute and noticed the packets going off in the wrong
direction.  Fixing that broke email to the internal hosts.

Managing lots of duplicate network addresses is not the answer.

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 1993 07:16:15 GMT
From:      crimson@obsidian.WPI.EDU (Jesus Christ on XTC)
To:        alt.internet.services,comp.protocols.tcp-ip,bit.admin
Subject:   Re: NREN Info

alex@dt.uh.edu (Alexandre Khalil) writes:
>  Subscribe to COMMUNET by sending mail to ListServ@AUVMVM with a body of
>subscribe COMMUNET your name
>set COMMUNET digest
>  The second line will help prevent the shock of seeing your mailbox flooded
>by the 20-40 odd messages that are coming in daily.

If the traffic is sooo large [he muses, before sending a sign-on message] then
why haven't I seen it gated into the bit.listserv.* heirarchy?

just a few hundred pesos....

joe

-- 
Disclaimer: "I'm the only one foolish enough to claim these opinions as mine."
crimson@wpi.wpi.edu         jzp@gene.ummed.edu          jprovo@gnu.ai.mit.edu
    Russell Street UN*X Consultations and Development     (NIC handle: JZP)
                   Rev. Dkr. Nick LaRG0, ASC, BBB

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Apr 1993 07:40:54 GMT
From:      cheong@technet.sg (SCSTECH admin)
To:        comp.protocols.tcp-ip
Subject:   Sample IP code for Sun

We would like to incorporate a VME ISDN card to a Sun3/260 and build
some device drivers on Sun 4.1.1 OS.  

Would appreciate if someone out there could give us some sample code
and the build procedures to incorporate the drivers into Sun OS.

Appreciate if you could email any response to YONGAM@mailhost.scs.com.sg.

Thanks.


-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Wed,  7 Apr 1993 14:44:59 -0400
From:      Lyle_Seaman@transarc.com
To:        comp.protocols.tcp-ip
Subject:   IPX Internet: BS?

This contains a particularly disingenous bit of marketing BS.  See if
you can spot it...

          NOVELL IS ALREADY ACTING ON PLANS TO ESTABLISH A GLOBAL IPX-BASED
          INTERNET-LIKE NETWORK - A REPORT ON NOVELL BRAINSHARE '93.  
 
          According to Novell Executive VP Kanwal Rekhi, Novell is going to
          provide its customers with their own Internet over the
          proprietary NetWare network which is tentatively named the Novell
          Network Registry.  Novell Engineering Director George Powers said
          that the IPX-based Internet could theoretically grow to more than
          twice the maximum size of the current TCP/IP-based Internet. 
          Because of Internet's limitations, it is expected to run out of
          address space some time in the next few years.  Novell is
          working on offering global connectivity, customer support
          services and third-party commercial services through the IPX
          Internet.  Rekhi said that Novell will work with third parties to
          establish naming and addressing schemes, but that his firm will
          maintain control over number allocation.  Novell will formally
          announce its plans for the IPX Internet in the next few months,
          said Rekhi.  Network connection will be available at what he
          called a minimal price. (Open Systems Today,3/29/93,p1)

Lyle		Transarc		707 Grant Street
412 338 4474	The Gulf Tower		Pittsburgh 15219

Death of {the Internet, Usenet} predicted.  Film at 11.

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Apr 1993 11:28:45 GMT
From:      rps@matuc2.mat.uc.pt (Rui Pedro Mendes Salgueiro)
To:        comp.protocols.tcp-ip
Subject:   Re: Performance comparison TCP vs UDP on LANs

heilbron@Informatik.TU-Muenchen.DE (Stephen Heilbronner) writes:
: 
: I forgot to mention in my original posting (it is
: quoted below) that the processes of our application 
: also need to do a sort of reliable 
: multicasting. From the replies and postings I got so far
: I'm aware that UDP with my requirements has no performance
: advantages over TCP when it comes to one-to-one connections.
: 
: But I'm wondering whether this still holds true when
: apps need to do reliable multicasting ? Does anybody know
: of public domain or research work that implemented reliable
: multicasting on top of UDP or raw sockets?

I think what you want might be something called VMTP:
quoting from Internetworking with TCP/IP (Douglas E. Comer) (page 509):

"VMTP
  (Versatile Message Transaction Protocol) A protocol developed to provide,
  among other facilities, efficient, reliable datagram communication
  service at the user level. Unlike most programs that use udp, programs
  using VMTP do not have to implement time out, retransmission, or
  estimation of network delays because the VMTP protocol provides
  reliable end-to-end datagram delivery."

The bad news:
  It's experimental. Quoting again Comer (page 438):
    "A current reseach project is exploring such a protocol. It has resulted
    in a preliminary draft specification and prototype implementation.
    Early measurements show that the protocol, known as VMTP, performs well,
    adapts to internet delays, and supports a wide variety of applications.
    If the results continue to be positive, VMTP may become a TCP/IP
    standard on wich transaction processing systems can be built."

    This has been written circa 1990. I don't know what is the present status
    of this protocol. It is documented in RFC 1045 (1988 February)

  I don't know how this relates to multicasting.

Hope this helps.

--
   Rui Salgueiro     |   Dpt. de Matematica    |"It's so easy to laugh
rps@matuc2.mat.uc.pt | Universidade de Coimbra | It's so easy to hate
   rps@inescc.pt     |    Portugal - Europe    | It takes strenght to be gentle
" 'He deserves death'.                         |     and kind" - Morrissey
  'Deserves it! I daresay he does. Many that live deserve death. And some that
die deserve life. Can you give it to them ? Then do not be too eager to deal
out death in judgement. For even the very wise cannot see all ends.' "
	Tolkien - The Lord of the Rings

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 93 20:09:35 -0400
From:      harvey@vax.cns.muskingum.edu (Ryan Harvey)
To:        comp.protocols.tcp-ip
Subject:   BOOTP: What is Alarm clock?


Did you ever have a noise in the background that just drives you insane?
Well, I've got this alarm clock going off on my Sun that doesn't appear
to be causing any damage, but it is driving me crazy.  I see it in my
/var/adm/messages file on my SPARCstation 2 (running 4.1.3 of SunOS).
The exact message is:

    Apr   3 06:28:53 sun inetd[6853]: /usr/etc/bootpd: Alarm clock

I have no idea why I am getting this message, and I am getting it every
2-3 minutes.  Does anyone out there have any idea why this would show up.
It has stayed with me over a reboot, and I can't find what could be causing
it.  I am using a copy of bootpd that I received from DEC with our VXT
workstations.

Any help or suggestions would be greatly appreciated,

Ryan Harvey
HARVEY@VAX.CNS.MUSKINGUM.EDU

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 93 20:28:10 -0400
From:      harvey@vax.cns.muskingum.edu (Ryan Harvey)
To:        comp.protocols.tcp-ip
Subject:   Good documentation on BOOTP/TFTP?


Is there any place I can get my hands on some documentation on things like
BOOTP and TFTP?  They seem to be so widely used that none of my documentation
goes into any detail about them.  Are there any ftp sites who have docs on
this kind of stuff.  I found the RFCs for them, but they don't explain
what the different options are for each command, or how they interact with
the system (i.e. the processes wake up when ...).  The RFCs contain the more
nuts and bolts of the protocols.

Thanks,

Ryan Harvey
HARVEY@VAX.CNS.MUSKINGUM.EDU

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Apr 1993 14:27:06 GMT
From:      ydavid@dxds04.cern.ch (David Yann)
To:        comp.protocols.tcp-ip
Subject:   async. IO sockets


asynchronous sockets

	Hi there,

I am starting out with asynchronous I/O on a TCPIP socket.
I'm having a hard time writing a UNIX client that is supposed to read
data from a socket... whenever data is available -the client is
awaken by a signal. It seems that the client does not get "enough"
signals and keeps waiting even though some data has arrived from
the (OS9) server; therefore the client gets only part of the data, even
after the server has finished its job and closed its side of the socket.

Also, I have found in _UNIX Network Programming_ (by W. Richard Stevens,
published by Prentice Hall) the following loop which aims at catching
SIGIO signals and then carrying out some work, and whose semantics are
rather unclear to me:

int sigflag;

main()
{/* ... */
	signal(SIGIO, sigio_func);

	for(;;) {
		sigblock(sigmask(SIGIO));
		while (sigflag==0)
			sigpause(0);

		/* work to do when SIGIO is received */

		sigflag=0;
		sigsetmask(0);
		}
}

int sigio_func()
{	sigflag=1;
}


What is the use of 'sigsetmask'? Why can we not just issue a 'sigblock' at
the beginning, and then use 'sigpause' in the 'for(;;)' loop?

	for(;;) {
		sigpause(0);
		
		/* work */
	}

Any hint would be most apreciated. Please e-mail your answers, since I am 
a regular reader of this group.


	Yann David
	Cooperant at CERN
	ydavid@dxcern.cern.ch

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 93 14:46:54 GMT
From:      mjh@dmu.ac.uk (Mike Howarth)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Synchronous NOS - Help please.


I have successfully implemented a system using KA9Q NOS that uses SLIP to
Packet conversions across an asynchronous line over quite a distance.  The
problem that I now have is the speed of the link between the two ends. 
Currently it supports a maxmimum of 9600.  This is causing a few
bottleneck problems.  I have got available an X21 link at 64kb over this
same route.
  Question :  Given that I can buy a Synchronous I/f card for
the PC's at either end - is there a version of NOS that supports
synchronous devices and runs effectivly SLIP or PPP ?
  Question : Is there a simple driver that would fool NOS into thinking
that the Synchronous card was in fact another packet driven system ?
I would appreciate any assistance that you can give.  I hope I'm not
asking a FAQ - if I am _sorry_.

Please eMail replies, and if appropriate I will summarise.

regards

Mike.

The above reflects MY opinions and not always those of my employer.
Mike J. Howarth.  SSG Manager De Montfort University Milton Keynes ENGLAND
+44 908 695511 (Switch) +44 908 834945 (Direct/Voicemail) +44 908 834948 (Fax)
eMail as mjh@dmu.ac.uk (Internet et al) or mjh@uk.ac.dmu (JANET)

-- 
The above reflects MY opinions and not always those of my employer.
Mike J. Howarth.  SSG Manager De Montfort University Milton Keynes ENGLAND
+44 908 695511 (Switch) +44 908 834945 (Direct/Voicemail) +44 908 834948 (Fax)
eMail as mjh@dmu.ac.uk (Internet et al) or mjh@uk.ac.dmu (JANET)

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Apr 1993 14:49:15 GMT
From:      kbridge@magnus.acs.ohio-state.edu (Doug Karl)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   New Release of KarlBridge now available via anonymous ftp

		 Cleanup your network with the KarlBridge

		This is the Latest KarlBridge Version 1.41

WHAT IS THE KarlBridge?

The KarlBridge is a program, that runs on a 286 or 386 clone. It provides
a unique and inexpensive 2 port Ethernet to Ethernet bridge that performs very
sophisticated high level protocol filtering. The bridge filters packets based
on ANY specified Ethernet protocol such as IP, XNS, DECNET, LAT, AppleTalk,
NetBEUI, Novell IPX, etc.

In addition it provides IP "firewall" protection by filtering IP packets based
upon IP address/network/subnet combinations and socket number. It will also
provide DECNET "firewall" filtering based upon DECNET address, Area, Object
number and Object name. It will also filter AppleTalk Phase 1 & 2 packets
based upon file server name, printer name, and/or Zone name. (Yes, Novell
SAP filtering is coming in the next release, along with NCR WaveLAN support).

	The free version of KarlBridge is available via
	anonymous ftp from:  128.146.1.7 /pub/kbridge

WHAT ELSE IS IT?

The KarlBridge is also a complete bridge box based upon the commercial
version of the KarlBridge code.  It comes with AUI & 10Base2 or AUI &
10BaseT connectors. It is a very nice small box, with a 386DX40, 2 SMC
Elite 16 Ethernet cards, special boot ROM, and Floppy drive or Flash ROM
card. It is fully tested and burnt in for added reliability with a 1 year
warranty. KarlNet Inc. is the main commercial supplier of the KarlBridge
hardware and software.  KarlNet Inc. sells the KarlBridge box for $1195.
Look for the product review in March 1993 issue of Personal Computer
magazine, pg 455, published in England, and the upcoming April 1993 issue
of IEEE Computer. KarlBridges are also manufactured and sold in the UK by
Sherwood Data Systems.

SOME EXAMPLES:

	You can use KarlBridge as a standard medium to high performance
	MAC layer Ethernet to Ethernet bridge with SNMP (MIB II, Ether MIB,
	Bridge MIB & SNMP MIB).

	You can configure a KarlBridge to restrict traffic from your public
	computer labs or dial-in-lines to subnets within your campus or
	corporate LAN, prohibiting unauthorized access to your LAN or the
	Internet (in conformance with RFC 1173).

	You can configure a KarlBridge to pass only IP traffic and use it to
	replace many of the functions that people use an IP router for; such
	as localizing non-IP traffic to within a room or workgroup.

	    Many folks have used this feature to bridge IP (only) between
	    several Novell LAN's. They did not want to load down their
	    Novell server with the burden of routing IP between interfaces.

	    The same concept has been used to bridge NetBUEI or LAT (only)
	    between two IP routed networks.

	You can configure KarlBridge to keep file and print servers (Apple,
	Novell, Banyan, and etc.) on the same network from interfering with
	each other.

Join thousands of people worldwide who are using the KarlBridge to solve
some of their networking nightmares. The KarlBridge is the most flexible,
inexpensive and easily configured bridge you have ever seen!

Get a copy, read the README file, run the configuration program on your
favorite PC, and let me know what you think.

Please send e-mail to kbridge@osu.edu with questions, comments, etc.

Doug Karl		  KarlNet Inc.         Sherwood Data Systems, Ltd.
Ohio State University	  (614) 263-5275       +44-(0)494 464 264
kbridge@osu.edu		  sales@KarlNet.com    sales@gbnet.com

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 1993 15:23:45 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: looking for uuencode source

glazer@ohstpy.mps.ohio-state.edu wrote:
> I am looking for Pascal source for the UUENCODE scheme.  Does such a thing
> exist?  Can someone point me to it?  If you know of C code, that would be
> ok too but I'd really rather look at the pascal code.

Here's what I use.  It may not work on your machine.
- Steve Kao
-------------------------------------------------------------------------------
/* 
 * Copyright (c) 1983 Regents of the University of California. 
 * All rights reserved. 
 * 
 * Redistribution and use in source and binary forms are permitted 
 * provided that the above copyright notice and this paragraph are 
 * duplicated in all such forms and that any documentation, 
 * advertising materials, and other materials related to such 
 * distribution and use acknowledge that the software was developed 
 * by the University of California, Berkeley.  The name of the 
 * University may not be used to endorse or promote products derived 
 * from this software without specific prior written permission. 
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR 
 * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED 
 * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. 
 */ 
 
/* 
 * Modified 12 April 1990 by Mark Adler for use on MSDOS systems with 
 * Microsoft C and Turbo C.  Standard input problem fixed 29 April 1990 
 * as per suggestion by Steve Harrold. 
 * 
 * Modifed 13 February 1991 by Greg Roelofs for use on VMS systems. 
 * Compile and link normally (but note that the shared-image link option 
 * produces a binary only 6 blocks long, as opposed to the 152-block one 
 * produced by an ordinary link).  To set up the VMS symbol to run the 
 * program ("run uuencode filename1 filename2 filename3" won't work), do: 
 *		uuencode :== "$disk:[directory]uuencode.exe" 
 * and don't forget the leading "$" or it still won't work.  The syntax 
 * differs slightly from the Unix and MS-DOS versions since VMS has such 
 * an awkward approach to redirection; run the program with no arguments 
 * for the usage (or see USAGE below).  The output file is in VMS "stream- 
 * LF" format but should be readable by MAIL, ftp, or anything else. 
 *
 * Modifed 15 April 1991 by Paul Stephen Kao for use on HP 9000 systems.
 *
 * SYNTAX:
 *     uuencode {infile} giffilename uufile
 *
 * where:
 *     infile      = optional input file
 *     giffilename = what uudecode will call the file after it's through
 *     uufile      = output file from uuencode, and input file to uudecode
 *
 * I used Greg Reolofs VMS definitions, but used the unix (tm) includes.
 * I also removed most of the compile flag options.  -  Steve Kao
 */ 
 
#ifndef lint 
static char sccsid[] = "@(#)uuencode.c	5.6 (Berkeley) 7/6/88"; 
#endif /* not lint */ 
 
/* 
 * uuencode [input] output 
 * 
 * Encode a file so it can be mailed to a remote system. 
 */ 
#include <stdio.h> 
#define OUT out
#define NUM_ARGS 3
#define USAGE "Usage: uuencode [infile] giffilename uufile\n" 
#include <sys/types.h> 
#include <sys/stat.h> 
 
/* ENC is the basic 1-character encoding function to make a char printing */ 
#define ENC(c) ((c) ? ((c) & 077) + ' ': '`') 
 
main(argc, argv) 
char **argv; 
{ 
	FILE *in, *out; 
	struct stat sbuf; 
	int mode; 
 
	/* optional 1st argument */ 
	if (argc > NUM_ARGS) { 
		if ((in = fopen(argv[1], "r")) == NULL) { 
			perror(argv[1]); 
			exit(1); 
		} 
 argv++; argc--; 
	} else 
		in = stdin; 
 
	if (argc != NUM_ARGS) { 
		fprintf(stderr, USAGE); 
		exit(2); 
	} 
 
	/* create the uuencoded file */
	if ((out = fopen(argv[2], "w")) == NULL) { 
		perror(argv[2]); 
		exit(4); 
	} 
 
	/* figure out the input file mode */ 
	if (fstat(fileno(in), &sbuf) < 0 || !isatty(fileno(in))) 
		mode = 0666 & ~umask(0666); 
	else 
		mode = sbuf.st_mode & 0777; 
	fprintf(OUT, "begin %o %s\n", mode, argv[1]); 
 
	encode(in, OUT); 
 
	fprintf(OUT, "end\n"); 
	exit(0); 
} 
 
/* 
 * copy from in to out, encoding as you go along. 
 */ 
encode(in, out) 
register FILE *in; 
register FILE *out; 
{ 
	char buf[80]; 
	register int i, n; 
 
	for (;;) { 
		/* 1 (up to) 45 character line */ 
		n = fread(buf, 1, 45, in); 
		putc(ENC(n), out); 
 
		for (i=0; i<n; i += 3) 
			outdec(&buf[i], out); 
 
		putc('\n', out); 
		if (n <= 0) 
			break; 
	} 
} 
 
/* 
 * output one group of 3 bytes, pointed at by p, on file f. 
 */ 
outdec(p, f) 
register char *p; 
register FILE *f; 
{ 
	register int c1, c2, c3, c4; 
 
	c1 = *p >> 2; 
	c2 = (*p << 4) & 060 | (p[1] >> 4) & 017; 
	c3 = (p[1] << 2) & 074 | (p[2] >> 6) & 03; 
	c4 = p[2] & 077; 
	putc(ENC(c1), f); 
	putc(ENC(c2), f); 
	putc(ENC(c3), f); 
	putc(ENC(c4), f); 
} 

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Apr 1993 16:28:38 GMT
From:      jos@bull.nl (Jos Vos)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.protocols.misc,comp.sys.ibm.pc.misc
Subject:   VINES network in combination with UNIX TCP/IP (lpd and NFS)

Does anybody have experience with products from Incognito Software Inc.
(Canada) for connecting VINES networks to UNIX hosts, offering
print facilities using lpd and file sharing using NFS?

Are there any other products known in this area?

Please MAIL responses to me.

-- 
--    Jos Vos <jos@bull.nl>   (UUCP: ...!{uunet,mcsun,sun4nl}!nlbull!jos)
--    Bull Netherlands, Professional Services, Amsterdam, The Netherlands

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 1993 14:56:33 +0200
From:      szymon@galaxy.uci.agh.edu.pl (Szymon Sokol)
To:        comp.protocols.tcp-ip
Subject:   BOOTP server on Sun


I have posted this question a few days ago to comp.sys.sun.admin, but got
no answer. The problem is: I have several PCs and Suns on our network, and
I use CUTCP and many other TCP/IP applications under MS-DOS. To manage
several IP addresses, I have set up a BOOTP server on one of Sun machines
(690MP running SunOS 4.1.3). It is version 2.1 of bootpd from CMU (by Drew
D. Perkins and Walter L. Wimer). It works, but from time to time it caused
mysterious console hangs on the server. When I read carefully the README file,
I found the following:

2) The server now uses syslog to do logging.  Specifically it uses the 4.3bsd
   version.  I've #ifdef'd all of these calls.  If you are running 4.2 you
   should compile without the -DSYSLOG switch.

As SunOS 4.1.3 is BSD 4.2 rather than 4.3, I have tried to remove -DSYSLOG
from the Makefile. It prevented the source from compiling... So I have patched
the source so that all references to syslog are commented out, but I do not
like this solution - I would like the program to use syslog facility to report
problems... Therefore, my question is: is there a version of bootpd running
under SunOS 4.1.3 and using syslog?
Thanks in advance,

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

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 93 19:00:28 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Offloading TCP/IP processing

In article <1pqdl6$opq@lll-winken.llnl.gov>, booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes:
> 
> Actually the NSC FDDI adapter for the Cray is acting like a router.  The
> Cray side of the adapter looks like HYPERchannel to the Cray, hence the
> large MTU is ok.  The other side connects to the FDDI ring.  Since the adapter
> is routing, the ring side of the adapter has to be a different subnet from the
> Cray side.  As a consequence, you eat up one subnet for each Cray on the ring. 
> 
> You can use an MTU of 32 KB, but the adapter will have to fragment it to
> send it onto the ring.  Thus, we run with an MTU of 4 KB.
> 
> NSC has an option to run in what they call "HYPERchannel emulation mode," in 
> which case they get around fragmenting by faking HYPERchannel over FDDI, but 
>it only allows you to talk to machines capable of dealing with this mode which 
> sort of shoots interoperability to pieces.


I do not understand exactly what the Cray-NSC-FDDI boxes do, but I
think there is even more to it than that.  I just got back from an
expedition to an installation where NSC and/or Cray insist that the
best way to run FDDI on SGI boxes is to fool our machines into using
16K TCP segments, running as if the FDDI MTU were 16K.  I guess they
prefer IP fragments to TCP segments.


Vernon Schryver,  vjs@sgi.com

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 93 19:09:36 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Performance comparison TCP vs UDP on LANs

In article <1prurd$h6p@sol.TIS.COM>, mjr@tis.com (Marcus J Ranum) writes:
> heilbron@Informatik.TU-Muenchen.DE (Stephen Heilbronner) writes:
> >I forgot to mention in my original posting (it is
> >quoted below) that the processes of our application 
> >also need to do a sort of reliable 
> >multicasting.
> 
> 	Oh, a *little* thing like multicasting. Hardly worth mentioning
> at all...
> 	What the difference between "a sort" of reliable multicasting
> and reliable multicasting?


Perhaps the difference between what you can do now, and what might be
nice to have if it turns out it does not cost too much.

As I understand the issue, general purpose, as reliable as TCP to each
and every participant, with dynamic adding and removing of
participants, properly sequenced multicast over non-trivial internets
at reasonable performance is an unsolved and conceivably unsolvable
problem.  There are entirely useful schemes in active use today that
give up one or more of those features.  For example, there is the IEEE
downloading stuff that is great for downloading in a single broadcast
domain, but useless for distributing extended streams of audio and
video.


Vernon Schryver,  vjs@sgi.com

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Wed, 07 Apr 93 19:26:08 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Of course we're running out of IP addresses!

In article <58674@olivea.atc.olivetti.com> jerry@olivea.atc.olivetti.com writes:

   In article <732541036snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
   >Again, how many of these are you *using*?   If the subnet is not
   >connected to the Internet, why use up an Internet address?

   Even if most of the addresses are behind a firewall and have no external
   access they still need unique addresses.  The firewall system needs to
   talk to both.

So designate *one* class A network to be used behind firewalls. Since
by definition the addresses behind the firewall are not on the
Internet, there is no harm in reusing them again and again.

*Again* I ask, how many Internet addresses is HP using?  Yes, they
have assigned 100,000 IP addresses within HP, but how many of these
IP addresses are also Internet addresses?

My plan has a few flaws:
  o when two firewall'ed companies merge.
  o when a firewall'ed company decides that firewalling was a mistake.
  o when you want to move a whole subnet out from behind a firewall.

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

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 1993 19:36:03 GMT
From:      rll@fizban.iol.unh.edu (Robert L. Lamothe)
To:        comp.protocols.tcp-ip
Subject:   802.2 DSAP and SSAP's

	Could someone out there please give me some assistance.  I've been
looking for the valid DSAP and SSAP port numbers for the 802.2 standard.
So far I haven't been too successful in my attempt.  Could someone please
send me a list of valid DSAP and SSAP's or give me the location of an
anonymous ftp site where I might find this?
						Thanks.
						-Bob
-- 
* Robert L. Lamothe                           University of New Hampshire     *
* rll@unh.edu                                 Interoperablity lab room 220    *
*                                                                             *
* 2 wrongs don't make a right, but 3 lefts do.                                *

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 1993 20:20:29 GMT
From:      donald_wright@brown.edu (Donald Wright)
To:        comp.protocols.tcp-ip
Subject:   RIP problem

We have a problem with RIP on our class "B" campus ethernet.  One router (a
RT running BSD 4.3) is configured on the backbone side as 128.148.128.138
(netmask of 255.255.255.0), the subnet is configured as 138.16.1.1 (netmask
of 255.255.0.0).  The problem is that other routers on the backbone timeout
the 138.16 subnet shortly after routed is started.  I suspect the netmask
is the root of this problem.  Can anyone confirm this, and is there any
known workaround short of subnetting the 138.16 network?

Don Wright, Network Systems Specialist    
Brown University, Providence RI
Internet: Donald_Wright@Brown.EDU
Phone:  (401) 863-7405
*** Talk is cheap, words plentiful, and deeds precious - Ross Perot ***

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Apr 1993 20:54:56 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: What is an "ip unnumbered serial line" ?

It's not inherent in the SLIP packet-framing scheme that it cannot
support unnumbered links, nor is it inherent in the PPP packet-framing
spec that it must support unnumbered links.  Whether or not your
point-to-point link requires a subnet of its own depends upon how the
implementors tied it into your system's IP networking layers.

For example, on most UNIX systems, that means they need to set the
IFF_POINTTOPOINT flag on that interface, and use SIOCSIFADDR and
SIOCSIFDSTADDR to set the local and remote addresses appropriately.
Salt to taste with SIOCSIFNETMASK.

Done this way, the IP addresses at the local and remote ends of a
point-to-point link are independent of each other, and independent of
the addresses of any other interfaces on either system.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221           +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Apr 1993 22:40:47 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: What is an "ip unnumbered serial line" ?

In article <BOB.93Apr7165449@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
> It's not inherent in the SLIP packet-framing scheme that it cannot
> support unnumbered links, nor is it inherent in the PPP packet-framing
> spec that it must support unnumbered links.  Whether or not your
> point-to-point link requires a subnet of its own depends upon how the
> implementors tied it into your system's IP networking layers.
> 
> For example, on most UNIX systems, that means they need to set the
> IFF_POINTTOPOINT flag on that interface, and use SIOCSIFADDR and
> SIOCSIFDSTADDR to set the local and remote addresses appropriately.
> Salt to taste with SIOCSIFNETMASK.
> 
> Done this way, the IP addresses at the local and remote ends of a
> point-to-point link are independent of each other, and independent of
> the addresses of any other interfaces on either system.


Exactly.

With "independent" have the strong meaning "in some implemenations, the
IP addresses of the ends of the point-to-point link can be the same as
the IP addresses the machines' main (e.g. ethernet or FDDI) interfaces.



Vernon Schryver,  vjs@sgi.com

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 1993 00:31:20 GMT
From:      yufan@.cs.keele.ac.uk (Yufan Hu)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   slip server on Sun WITHOUT kernel rebuilding?

Hi, 

I would like to know whether there is a slip/cslip server implementation
which do NOT need to put a driver into the kernel. Is it possible?

Any information is greatly appreciated.

-Yufan


-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 1993 22:08:19 +0200
From:      szymon@galaxy.uci.agh.edu.pl (Szymon Sokol)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP server on Sun

OK, I stand corrected - several persons pointed out that syslogd in SunOS 4.1.3
is based on BSD 4.3, not 4.2. This does not change the fact that our console
hangs from time to time (it happened 4 times until now) due to syslogd failure 
(killing and restarting syslogd is enough to resume normal operations) 
and I cannot think about any other source of this problem but bootpd 
(in all 4 cases, lack of BOOTP responses to our PCs was the first sign 
that something is wrong). I will try to prove my theory by moving our
BOOTP server to another machine - if it starts to hang in the same way, 
bootpd is the cause. Thanks for all the answers I have received so far
(BTW. no one mentioned a version of CMU's bootpd newer than 2.1 - is there any?)
-- 
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

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Apr 1993 02:00:59 GMT
From:      gsarff@wicat.com (Gary Sarff)
To:        comp.protocols.tcp-ip
Subject:   SLIP over Terminal Server?

I am setting up slip on my sun3/160 and have a Bridge 100, terminal
server with 14 serial ports.  Is it possible (or is there software) that 
will run SLIP through the terminal server.  Basically, can slip software
talk over a pseudo-tty which will be the connection to the sun.  The
terminal server is binary transparent capable since we can do file transfers
(zmodem/kermit/uucp) through it.  I have slip running on the two serial
ports I have /ttya and /ttyb.  The terminal server connections though
just seem to sit.  Will this work, or should I just get a multi-serial
port card for the sun.  I have looked for information but have not found
any yet.

Thanks.
-- 
  []   (the null signature)

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 93 05:42:30 GMT
From:      martind@nsg.nsg.com.au ( NSA)
To:        comp.protocols.tcp-ip
Subject:   reverse telnet

I'm looking for information and if available source code for an implementation
of reverse telnet.


-- 
Martin P Drenovac             PHONE: (612) 415-0500
                              FAX:   (612) 417-8635
			      EMAIL: martind@nsg.oz.au
Network Solutions             UUNET: !uunet!munnari!nsg.oz.au!martind

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 1993 15:00:44 -0500
From:      chris@wupost.wustl.edu (Chris Myers)
To:        comp.protocols.tcp-ip,comp.archives.admin,alt.sources.d,comp.unix.admin,comp.sys.sun.admin,comp.sys.sgi.admin,comp.unix.ultrix,comp.sources.bugs,comp.protocols.misc,comp.bugs.misc
Subject:   New wuarchive ftp server available w/critical security fix

The Washington University Office of the Network Coordinator is happy to
announce the release of a new version of the wuarchive FTP server.
This server includes many security enhancements and new features, and a
fix for a very serious security problem (only brought to our attention
today) -- if you are running any version of our ftp server released
before April 8, 1993, you should upgrade IMMEDIATELY (we mean today,
not next week!).

This release includes full documentation for installation and
configuration, and is also very easy to compile and install.  See
wu-ftpd-2.0/INSTALL, wu-ftpd-2.0/NOTES and wu-ftpd-2.0/doc/README for
more information on how to install and operate this ftp server.

The server may be retrieved via anonymous FTP from wuarchive.wustl.edu
in the directory /packages/wuarchive-ftpd.  There are two distribution
formats, a tar file and a shar file.  Fetch one of the files, and use
the appropriate method to extract it -- the individual files will be
stored in a new subdirectory called "wu-ftpd-2.0".

The way the "guestgroup" command functions has changed; if you are
using guestgroups, please read the documentation and make the
appropriate configuration changes before installing the new ftp
server.

ADDITIONS AND BUG-FIXES IN RELEASE 2

0.  Fixed a really serious security problem that would allow access to
    real accounts, including root (on poorly configured systems),
    without giving a valid password.

1.  ftpcount no longer displays multiple listings for classes that have
    multiple "class ..." lines.

2.  Added following abilites configurable in the ftpaccess file.
    see ftpaccess(5).

        chmod            <yes|no>  <typelist>
        delete           <yes|no>  <typelist>
        overwrite        <yes|no>  <typelist>
        umask            <yes|no>  <typelist>

        upload           <dir>     <yes|no>  <owner>  <group>  <mode>

        passwd_check     <none|trivial|rfc822>  {<warn|enforce>}

        alias            <name>    <dir>

        path_filter      <typelist>  <msg>  <charset>  {<disallowed> ...}

3.  The conversion table has been moved to a separate file.  The
    fields are:

           %s:%s:%s:%s:%s:%s:%s:%s

           Field    Description
            1       strip prefix
            2       strip postfix
            3       addon prefix
            4       addon postfix
            5       external command
            6       types
            7       options
            8       description

4.  ftpshut program generates shutdown file for ftp server.  Works 
    similarly to shutdown(8).  See ftpshut(8).

5.  guestgroup access no longer needs an entry in the secondary passwd
    file (~ftp/etc/passwd).  The home directory is now specified as 
    "root/./home"  For example:

    ftptest:<encrypted>:100:200:Guest User:/var/ftp/./incoming:/etc/noshell

    When ftptest logs in, it will chroot to /var/ftp and then chdir to
    /incoming (which is actually /var/ftp/incoming before the chroot).

    Since the directory in /etc/passwd actually points to the guest's
    home directory, they can use .forward files, etc.

Chris Myers                                Internet: chris@wugate.wustl.edu
Software Engineer                           UUCP: ...!uunet!wuarchive!chris
Office of the Network Coordinator                BITNET: chris@wunet.bitnet
Washington University in Saint Louis                 Phone: +1 314 935 7390

Bryan D. O'Connor                            Internet: bryan@fegmania.wustl.edu
Software Engineer, wuarchive development        UUCP: ...!uunet!wuarchive!bryan
Office of the Network Coordinator                    BITNET: bryan@wunet.bitnet
Washington University in Saint Louis                     Phone: +1 314 935 7048
-- 
Chris Myers                                Internet: chris@wugate.wustl.edu
Software Engineer                           UUCP: ...!uunet!wuarchive!chris
Office of the Network Coordinator                BITNET: chris@wunet.bitnet
Washington University in Saint Louis                 Phone: +1 314 935 7390

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 1993 08:04:19 GMT
From:      franklee@stein.u.washington.edu (Fan Lee)
To:        comp.protocols.tcp-ip
Subject:   alternate routing


I am currently doing a research project about computer network
routing.  One problem which seems very interesting to me is how to
find alternative paths.  Can someone tell me what is currently being
done on this topic?  That is, if the least cost path is congested, how
people decide which path is a "good" alternative path.

I would appreciate if someone can give me pointers to key research
papers in alternate routing problems.

Thanks.



-- Frank.


-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Apr 1993 11:49:18 GMT
From:      gnn@cs.utwente.nl (George Neville-Neil)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.misc,comp.unix.misc
Subject:   Band Width Measuring programs: Release 0.1

Hi Folks,

	I've just finished up the initial versions of a few small programs
to measure user to user bandwidth for TCP/IP and Unix Domain Sockets.  The
programs are available for anonymous ftp from:

pegasus.cs.utwente.nl [130.89.15.25]

In the file: pub/bandwidth/bwmeas-0.1.tar.Z

	I've included the README at the end of this message.

	This is an alpha release of these programs, I intend to add more 
protocols as time allows.  I also intend to build some scripts
around these programs to generate "interesting" data.

	To report bugs or make requests for other features please email
me at: gnn@cs.utwente.nl .

	This code has been built and tested successfully on Ultrix 4.3a,
SunOS 4.1.2, and HP-UX 8.05 .

Enjoy,
George

--- Begin Included Text ---

This is the README file for the Bandwidth Measuring programs.

This set of programs will allow you to measure user to user bandwidth
over several types of IPC channels.  The current set of tools includes
programs to measure IPC over:

o TCP

o Unix Domain Sockets

This is an ALPHA release of this software.  There are bound to be bugs
and suggestions are welcome.  Please contact me at: gnn@cs.utwente.nl
with either or both.

To build this release do the following:

cd src
make -f Makefile.unx all

You are now done.  If you don't have gcc just change the compiler variable 
(CC) in the Makefile.

There are man pages in the man subdirectory.  These should tell you
all you need to know about the programs.

Please read the man pages first.  If you don't and get the message:

connecting to service: Connection refused

from tcp_speed then go read the man page.

A Note Of Courtesy:

These programs throw as much data as possible across the connection,
if you do this on a network you will swamp it.  If you do this for a
long time then people will think you are a jerk and try to kill you,
or at least remove you from the net.  Please use these programs
cautious and wisely.

--- End Included Text ---
--
Kunst of soep?  - Lilly Tomlin

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Apr 1993 14:14:09 GMT
From:      dcarr@gandalf.ca (Dave Carr)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on a chip, anything available?

In <1245@felix.Sublink.Org> eb@felix.Sublink.Org (Enrico Badella) writes:

>I heard a rumor of a chip (probably by National Semi) is about to come
>out with TCP/UDP/IP protocol stack in it.
>Is such a beast feasable, reasonable.....

Don't know about National, but Protocol Engines went broke doing this.
Perhaps National has picked up where PE left off.
-- 
Dave Carr               | dcarr@gandalf.ca       | It's what you learn, 
Principal Designer      | TEL (613) 723-6500     | after you know it all,
Gandalf Data Limited    | FAX (613) 226-1717     | that counts. 

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Apr 1993 14:45:14 GMT
From:      darren@tsegw.tse.com (Darren Pike )
To:        comp.protocols.tcp-ip
Subject:   Problems with accept and recvfrom system calls


I have read in the book "UNIX Network Programming" by W. Richard Stevens on
page 334, that "although 4.3BSD tries automatically to restart certain
system calls that are interrupted, the accept and recvfrom system calls are
never restarted automatically by the kernel." I would like to know if
anyone has run across this as being a problem before? How did you work
around it. What happens to the data during and after the interrupt?

This has raised some concern at our site since we use BSD sockets extensively
in our communications programs.

We are writing our code on SCO ODT and Data General systems which supports
both sockets and streams.       

We would like to keep using sockets if possible. Since having to restart the 
system call after an interupt would make the program more complex.

Any help would be appreciated. 

Regards,
===========================================================================
Darren Pike, Senior Software Analyst, Toronto Stock Exchange
Phone: (416)947-4288 Email: darren@tse.com
===========================================================================
-- 
===========================================================================
Darren Pike, Senior Software Analyst, Toronto Stock Exchange
Phone: (416)947-4288 Email: darren@tse.com
===========================================================================

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Apr 1993 14:59:23 GMT
From:      lad@uni.ins.com (Lawrence A. Deleski)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Frame too short...

From article <1potmh$j27@helios.intranet.gr>, by antonis@intranet.gr (Antonis Kyriazis):
> 
> Hi
> 
> Recently we expanded a thin ethernet segment, by attaching a 12-UTP
> port hub. Unfortunately the users (3C503-TP) complain about NFS
> problems: They mount (with PC-NFS) directories on a HP-UX system and
> PKZIP or XCOPY don't work. A capture from Sniffer indicated "frame too short" for the frames generated from the PC when trying to NFS-write and "may be more in subsequent frames". Has someone any idea?


What you are seeing are ethernet runt packets, packets that are below the
64 byte minimum size.  Runt packets can be caused accidentally or
intentionally.  If accidental, they are most likely caused as a result of a
faulty ethernet interface somewhere on the network, or some driver or other
software that has malfunctioned.  If intentional, they may be designed to
be runts for a specific reason.  For example, SNMP packets are never larger
than 56 bytes, which is considered an ethernet runt packet.  This is done so
that most network devices will simply ignore an SNMP frame.  If your new
10BaseT hub supports SNMP it may be the source of your runts, as most SNMP
agents found in hubs often send out "uptime" traps, or single SNMP frames
every minute or so.

Do this; check all of your ethernet adapters to make sure they are all
functioning properly.  Then rent a TDR and check you thinnet segments for
shorts, opens, and the proper characteristic impedeance, and if all of that
checks out, start isolating machines from the network and see if your
problem goes away.  Any way you cut it, you're going to have to
trial-and-error troubleshoot this problem.  Good Luck.

-- 
        Lawrence A. Deleski         |       International Network Services
        lad@uni.ins.com             |       4701 Patrick Henry Drive
        uunet!uni!lad               |       Suite 1701
        MABELL:  (408) 496-1410     |       Santa Clara, CA 95054

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 93 15:46:28 GMT
From:      devdjn@nodomain (Dennis Newport)
To:        comp.protocols.tcp-ip
Subject:   Re: Offloading TCP/IP processing

You can also off-load the TCP/IP (and I believe OSI stacks as well)
on the CMC boards. They fit into a range of buses and use the
M68xxx processors (last I heard was the 68020).


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


-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Apr 1993 16:30:27 GMT
From:      PPOLLET@cismibm.univ-lyon1.fr (Patrick POLLET)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   PCROUTE+LOCALTALK+BOOTP HOW


Hi all,
    We have a Novell server that route TCPIP to a 30 PC network and 
send BOOTP requests to them with the BOOTPD.NLM from Hellsoft.Works like a 
charm. All the TCIP softawre are in a public directory, read only ...and 
allo stations parameters are got from the server !

    One of the PC is actually a router that route TCPIP to 30 Macs on 
localtalk using the PCROUTE free software.    It works slowly but it is 
quite OK  from mail and News reading.  

   Our problem it that on every single MAC we has to manually set the IP
address of MAC TCP  . And as you may guess, some students fools around with
MACTCP ,change the IP, gateway,netmask  and the rest of it... 
Generally we got a crash of the PCROUTE router !!!!

    I am wondering what is the format of the BOOTP request that 
MacTCP send to a BOOTP server  if we set the IP adress to SERVER in MacTCP.
Don't forget , these Macs do NOT HAVE an Ethernet card but get the 
TCPIP packets on the localtalk  

    If I had that format ( machine name, Localtalk ID ???? ) may be I could 
add my Macs to the BOOTPD deamon's tables in my Novell server and have all 
machines getting their IP from a server.    

  Am I dreaming ????  :-)
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
-------------------------------------------------------

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 1993 17:08:40 GMT
From:      Mark Measures <measures@gandalf.baylor.edu>
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.misc,comp.unix.misc
Subject:   Re: Band Width Measuring programs: Release 0.1

In article <gnn.734269758@thecity> George Neville-Neil, gnn@cs.utwente.nl
writes:
> Hi Folks,
> 
> 	I've just finished up the initial versions of a few small programs
> to measure user to user bandwidth for TCP/IP and Unix Domain Sockets. 
 The
> programs are available for anonymous ftp from:
> 
> pegasus.cs.utwente.nl [130.89.15.25]
> 
> In the file: pub/bandwidth/bwmeas-0.1.tar.Z
> 

I just downloaded this package to run on an AT&T StarServer E running
SVR4.0.2.  I had to add the following to the makefile:

LFLAGS = -Bdynamic -lnsl -lnls -lnet -lsocket

and then add $(LFLAGS) to the end of each compile line in the makefile.
After that, it built fine.

I thought you might like to see some sample results.  I have no idea if
these results are representative or not.  The hostname of the system I
ran them on is gandalf, and I did everything local.

gandalf% unix_speed -p /tmp/unixtest -b 1024 -c 10000
UNIX SOCKET Time to send 10240000 bytes: 4630 milliseconds
UNIX SOCKET Time to send one 1024 byte chunk: 463.000000 microseconds
UNIX SOCKET Bandwidth 2211663.066955 bytes/second.

gandalf% tcp_speed -h gandalf -b 1024 -c 10000
TCP Time to send 10240000 bytes: 23900 milliseconds
TCP Time to send one 1024 byte chunk: 2390.000000 microseconds
TCP Bandwidth 428451.882845 bytes/second.

---------------------------------------------------------------------
Mark Measures                      All opinions and statements are my
Engineering and Computer Science   own do not represent official policy
Baylor University                  of Baylor University.

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Apr 1993 17:22:44 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on a chip, anything available?

In article <1993Apr8.141409.4608@gandalf.ca>, dcarr@gandalf.ca (Dave Carr) writes:
> In <1245@felix.Sublink.Org> eb@felix.Sublink.Org (Enrico Badella) writes:
> 
> >I heard a rumor of a chip (probably by National Semi) is about to come
> >out with TCP/UDP/IP protocol stack in it.
> >Is such a beast feasable, reasonable.....
> 
> Don't know about National, but Protocol Engines went broke doing this.
> Perhaps National has picked up where PE left off.


Actually, PEI was not putting TCP/IP on their chips, but putting parts
of TCP and IP on the chips that would speed up TCP/IP for the whole
system.  I think they went too far when they presistently wanted to
look up the protocol control block pointer on the board, but even so,
no one could reasonably say their chips were intended to "implement
TCP/IP in silicon."  Too many people involved had too much experience
with disasters called "TCP/IP on ethernet boards."  Everyone knew that
some customers would want to sell products that would be "TCP/IP on a
board", and I suppose they would have sold some themselves.  Their
biggest customers would certainly not have used the products that way.

As usual in such cases, what killed PEI was not what they were doing,
but the way they were doing it.  They took far too long to do what they
did and had difficulty making and sticking to decisions about what to
do next and how to do it.  Getting involved in and generally adopting
The Standards Process was both a sympthom and a cause.


Vernon Schryver,  vjs@sgi.com

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Apr 1993 19:48:47 GMT
From:      daudo@bcars201.bnr.ca (Dau Do)
To:        comp.protocols.tcp-ip
Subject:   HELP !!!


Hi,

   I wrote a software that using the sockets on the Sun WS for the
   following:

         + read/write file
         + X.25 protocol
         + TCP  protocol

   For a while, I received an error number 23 (File Table OverFlow).
   That I cannot allocate another socket for any of the purpose listed
   above.   I checked the code that I did do a 'close' whenever I finished
   using the socket.  If I do the command 'pstat -T' on the WS, I found
   the total number of file descriptor has been used increased abnormally.

   I'm using: OS    version 4.1.2
              X.25  version 7.0

   Can anyone know what I haven't done or how to prevent in the software.
   Right now whenever the problem occurs, I have to reboot my WS.

Thanks,
Dau Do

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Apr 1993 19:56:06 GMT
From:      hosur@ee.umn.edu (Srinath Hosur)
To:        comp.protocols.tcp-ip
Subject:   slip question

Hi, 

Can someone tell me if there is a public domain software on
SLIP (Serial Line Internet Protocol) which can be got by anon.
ftp or some other means.  We already have KA<9Q software.

Thanks in advance,
suresh

P.S. could you e-mail your responses to
hosur@ee.umn.edu
or
datacom@cmcdel.ernet.in

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Fri, 09 Apr 1993 09:18:49
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP & TCP Questions

In article <2002@alcbel.be> devdjn@space.alcbel.be (Dennis Newport) writes:
    
    ... on a Sun machine I recall that the maximum data block I could send
    over a TCP socket was either 32767 or 65535 bytes.  Does anyone know what
    the current maximum value is and where the defining factor can be found ?

There is no limit in TCP itself, only in a particular API to TCP.  In a 4bsd
send() call the length is an 'int', so any 32-bit OS which limited you to
less than 2 Gb per call should document it somewhere....

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488


-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Fri, 09 Apr 1993 09:19:23
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: MIL-STD, DOD-STD #'s for {TCP,UDP}/IP ?

In article <1993Apr5.192514.20833@scf.loral.com> bashford@srs.loral.com (Dave Bashford) writes:

    Can some please point me to the goverment standards that define/? the
    Internet protocols ? We have the RFC's, but apparently they aren't as
    impressive as MIL-STD, DOD-STD references in documentation and proposals.

1777 is IP (don't implement it literally - it has known errors)
1778 is TCP (ditto)
1780 is FTP (obsoleted by RFCs 959, 1123)
1781 is SMTP (don't know any problems, but RFC 821 is the real standard)
1782 is Telnet (predates many recent Telnet option definitions)

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488


-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 93 11:01:19 EDT
From:      anil@umiami.ir.miami.edu
To:        comp.protocols.tcp-ip
Subject:   Help -- Urgent!


Hi all,
       I need urgent help with a networking problem:
Recently, the network department at the campus where I work decided 
to "adjust" their charges for network use.  A workstation, which costed 
$40 per month will now be $50 + 50 cents per minute...CLOCK TIME!  
Typically, I sign into this machine (different campus) every morning and 
sign out at 5 or 6 when I leave.  That's where I get to the usenet news.
During the day, I flip thru the news whenever I get a chance.  

At the new rates, I (only me) would be charged $270 per day!!!
And this doesn't include all the other reasons I use the net for! 

Various departments have tried reasoning with the man behind all
this but he won't give in.

Now, any PC on the network (no matter what it is used for) will
cost a flat $30 per month.  I was wondering if there were some
way to use a PC as a gateway/router and have all of the 
workstations on an internal network.  I picked up "pcroute" from 
the net somewhere but I'm not sure if it will do what I need. 
I already have all the necessary hardware to do this if possible. 
Here's the idea I had in mind:




                ____                   _______   
 to            |    |                 |       |  
campus <-------| PC |-----------------|  HUB  |  
network        |____|                 |_______|  
              A      B                 /  |  \  
                                      /   |   \  
                                     /    |    \  
                            _____   /   __|__   \   _____ 
                           |     |_/   |     |   \_|     |  
                           |     |     |     |     |     | 
                           |_____|     |_____|     |_____|  
                              X           Y           Z 
                                     Workstations  


Some questions:  

1.  The network number on side B of the router will be different from
    than on side A.  Side A is a class B network and side B will be a 
    class C network.  How would workstations X, Y, Z get email?  I  
    would think that any mail incoming to a workstation would be 
    filtered out before it even reached the PC on the A side. 

2.  If it's not possible to send email to individual workstations at 
    their own addresses, would it be possible to send the mail to the 
    PC's address (on the A side) and then maybe some program on the 
    PC could decide which machine it belongs to, and forward it there 
    by changing the address accordingly? 

3.  What about out-going email ... any problems there? 

4.  Anyone know what software I can use to do what I need? 

5.  Anyone has any better ideas? 


Thanx in advance for all the help, 
-Anil.  



-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Apr 1993 11:02:38 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Traceroute for MS-DOS Systems and Other Personal Computers


Are there any versions of the "traceroute" program which will run on MS-DOS
computers?  Hopefully, there would be one for MS-DOS as well as Macintosh
systems.  From time to time, on our campus, we get personal computers that
won't talk to a given location, and it would be really nice to be able to do
something besides guess at the reason.

	Thank you.

Martin McCormick WB5AGZ   Stillwater, OK
O.S.U. Computer Center Data Communications Group

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Apr 1993 14:55:40 GMT
From:      john@physiol.su.OZ.AU (John Mackin)
To:        comp.protocols.tcp-ip
Subject:   netwall - tcp/udp port 533

Most Unix systems seem to have a "netwall" service in their /etc/services,
for both tcp and udp (in most cases), at port number 533.  This is
given a bare mention in RFC1340 but that's all I could find.

I would like to know if there was ever anything implemented that did
this, and where I can find it or more information about it.  Please
reply by mail; I will summarise.  Thanks.

-- 
John Mackin <john@civil.su.oz.au>
Knox's box is a 286.                 Fox in Socks does hacks and tricks
Knox's box is hard to fix.           To fix poor Knox's box for kicks.

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Apr 93 15:58:47 GMT
From:      rob@leland.Stanford.EDU (Rob Tanner)
To:        comp.protocols.tcp-ip
Subject:   How to route xns over an ip backbone??

By administrative mandate, all our subnet routers are configured to
route IP only.  Thus, AppleTalk packets, for example, are IP
encapsulated (IPTalk) in via FastPath gateways in order to be routed
between subnets.

I now have a problem where there is a need to install a client work
station in one building, and have that workstation talk to a server in
another.  The server and the workstation are part of a specialized
ticketing system installed in the Bass outlet in the student union,
and the protocol the system uses to talk between client and server 
is xns.

Any ideas on how to route the xns keeping in mind that I can't effect
any change in the IP only routing policy?  Is there any kind of
gateway I can get that will do the encapsulation into an IP packet
(which is what I presume I'll need to do)?

Any help at all would be most appreciated.  Thanks in advance.


-- 
Rob Tanner                              Internet: rob@sherlock.stanford.edu
System Administrator
President and Provost's Office
Stanford University, California

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Apr 1993 16:20:58 GMT
From:      marcelm@joymrmn.on.ca (Marcel Mongeon)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

nelson@crynwr.com (Russell Nelson) writes:

>In article <58674@olivea.atc.olivetti.com> jerry@olivea.atc.olivetti.com writes:
 
>   In article <732541036snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
>   >Again, how many of these are you *using*?   If the subnet is not
>   >connected to the Internet, why use up an Internet address?
 
>   Even if most of the addresses are behind a firewall and have no external
>   access they still need unique addresses.  The firewall system needs to
>   talk to both.
 
>So designate *one* class A network to be used behind firewalls. Since
>by definition the addresses behind the firewall are not on the
>Internet, there is no harm in reusing them again and again.
 
>*Again* I ask, how many Internet addresses is HP using?  Yes, they
>have assigned 100,000 IP addresses within HP, but how many of these
>IP addresses are also Internet addresses?

Could that Class A network be 127.0.0?  Yes, I know that the loopback 
address (127.0.0.1) falls into that space.  But can you not set up
the routing tables after your loopback has been configured by
including something along the lines of:

	route add 127. 192.43.1.1 1

The 192.43.1.1 being the address of your network adapter.  The specific
routing for 127.0.0.1 would still go through gateway 127.0.0.1 and
the lo0 interface, any other 127 addresses would go to the network
adapter.

One of the advantages of this system is that 127 is already a reserved
network and if it got past your firewall not much would be inclined
to pass it on.

Or am I out to lunch?
-- 
|||  Marcel D. Mongeon          
|||  e-mail:    ... (uunet.ca, mcshub)!joymrmn!marcelm  or
|||                  marcelm@joymrmn.on.ca

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Apr 1993 17:06:39 GMT
From:      jeffrey-ollie@uiowa.edu (Jeffrey C. Ollie)
To:        comp.protocols.tcp-ip
Subject:   Implementing Telnet NVT

Howdy NetFolks,

  I am trying to write an interactive game to which players will be able to
telnet into.  I would like to use features of the Telnet NVT to improve
the user interface.  I have studied the appropriate RFC's (854, etc.) but
I am still unclear on how to implement the options negotiations, etc.

  I would be grateful if anyone had some pointers to additional information,
or had some hints gained from experience and would share them.

  If it helps, I will be using BSD sockets.

  Please e-mail and I will summarize.
-- 
Jeffrey C. Ollie
jeffrey-ollie@uiowa.edu
"The Happy User"


-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Apr 1993 20:30:43 GMT
From:      peram@eceyv.ncsu.edu (Peram Marimuthu)
To:        comp.protocols.tcp-ip
Subject:   RMON: How is it useful?

The RMON standard was designed with the intent that all the counters 
"might" be useful. I am wondering if all those counters are really
useful. RMON provides some interesting statistics but other than that
I do not seem to find any value in the standard. It seems like a nice toy. 

I need some help in knowing how to use RMON effectively.

--peram

peram@eceyv.ncsu.edu

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 1993 21:26:19 GMT
From:      pascoe@rocky.tntn.gtegsc.com (Dave Pascoe)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   PC/TCP PPP to Sun pppd-1.2

I am trying to get PC/TCP PPP (version 2.11 and CONNECT.EXE version
2.2 since there was a compatibility problem with the CONNECT.EXE
v2.11) to work over a modem connection to a Sun running pppd-1.2
(Parker/Christy et al).  I have succeeded in getting through LCP and
IPCP negotiation but after that cannot reach even the pppd server
(tried ping, telnet, etc.).

I see packets being sent and received when I try to ping the remote
end but there are what appear to be lots of FCS (checksum) errors.

The modems are Telebit WorldBlazers at both the PC and the Sun ends of
the link.  I have tried both 9600 and 14400 bps connections.  The
serial port on the PC just has an 8250 UART not the 16550, but the
PPP16550 driver is running in 8250 mode (auto-detect) anyway.  I
suppose the next step is to try 2400 bps.....

Could the problem I'm seeing be related to the fact that I don't have
a 16550 UART?  This is what I suspect but can't be sure.

The only other thing I suspect now is that the Sun perhaps shouldn't
be running the routed daemon.  On the Sun I have a proxy ARP entry for
the remote end of the PPP link, so finding a route to the PPP remote
host is not a problem.  There is a default route on the Sun for
outgoing traffic.  I could kill off routed since it really isn't
necessary.  I have seen problems with PC/TCP SLIP in the lab with a
point-to-point link where the PC cannot get past the Unix machine if
it has it specified as a router (in PCTCP.INI) *and* routed is
running.  It seems that only static routing on the Unix machine works
when trying to use it as a relay.   But this wouldn't explain why I
can't even ping the PPP server which is just one side of the
point-to-point link.

Has anyone had luck getting the PC/TCP PPP to work with a Sun PPP
server running any of the public domain implementations of PPP?

By the way, I am able to make a Mac running MacPPP talk just fine to
the Sun PPP server (@9600 bps).

--
Dave Pascoe
Internet: pascoe@rocky.tntn.gtegsc.com
(508) 880-2297
(617) 455-5704

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Apr 1993 22:45:07 GMT
From:      gnn@cs.utwente.nl (George Neville-Neil)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.misc,comp.unix.misc
Subject:   Re: Band Width Measuring programs: Release 0.1

Mark Measures <measures@gandalf.baylor.edu> writes:


>I thought you might like to see some sample results.  I have no idea if
>these results are representative or not.  The hostname of the system I
>ran them on is gandalf, and I did everything local.
 
>gandalf% tcp_speed -h gandalf -b 1024 -c 10000
>TCP Time to send 10240000 bytes: 23900 milliseconds
>TCP Time to send one 1024 byte chunk: 2390.000000 microseconds
>TCP Bandwidth 428451.882845 bytes/second.


This looks like a moderately loaded ethernet.  Also, your local implementaion of
TCP can affect the numbers.  Jeff Mogul of DEC WRL has written a lot about
this.  From a Dec 5000/240 to another of the same machine running Ultrix 4.3
I get about 1Mbyte per second on a very lightly loaded ethernet segement.

Thanks for the porting info.  I'll add that into the next release.

Later,
George


--
Kunst of soep?  - Lilly Tomlin

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Apr 93 23:28:48 GMT
From:      maritza@bae.bae.bellcore.com (Maritza Ramirez)
To:        comp.protocols.tcp-ip
Subject:   socket question - local ip address


Is there any way to get the ip addresss using using other calls than
the gethostbyname() or inet_addr() ? I am trying to use the getsockname() 
but getting a 0 value for the local address. Is it possible to get the 
ip address using getsockname, or am I doing something wrong with my calls? 
Any pointers on this situation will be appreciated.

Maritza


This is my sequence of calls:

	...
        sockfd_data = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

	...

        bzero(data_addr,sizeof(data_addr));
        data_addr.sin_family=AF_INET;
        data_addr.sin_addr.s_addr=htonl(INADDR_ANY);
        data_addr.sin_port = 0;

	... 

	bind(sockfd_data, (struct sockaddr *) &data_addr,sizeof(data_addr))

	length = sizeof(data_addr);
        if(getsockname(sockfd_data, &data_addr, &length));


after I use the getsockaddr() call to get my local port and ip
address, I can get the port number but, a 0 value for my local 
ip address.

PS> I'm trying to print the values for the port and ip using: 

char *p, a*;
#define UC(b)   (((int)b)&0xff)

                a = (char *)&data_addr.sin_addr;
                p = (char *)&data_addr.sin_port;
                printf("PORT %d,%d,%d,%d,%d,%d",
                      UC(a[0]), UC(a[1]), UC(a[2]), UC(a[3]),
                      UC(p[0]), UC(p[1]));

(from an ftp client software )

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 1993 00:33:35 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <C585Ez.463@joymrmn.on.ca> marcelm@joymrmn.on.ca (Marcel Mongeon) writes:
>...127 is already a reserved network and if it got past your firewall not
>much would be inclined to pass it on.

RFC 1122 says 127.*.*.* is never to go out on a LAN.  3.2.1.3(g) says about
these address, "Internal loopback address.  Addresses of this form MUST NOT
appear outside a host."

I don't know if BSD enforces this, but other systems do.

-- 
Stephen Trier                      "It is proposed to reduce the effective
Network software type               data rate further by replacing the
Case Western Reserve University     tanks with shuttle launch vehicles."
trier@ins.cwru.edu                        - V. Cerf, RFC 1217

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 1993 21:47:42 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: socket question - local ip address

In article <1993Apr9.232848.12106@walter.bellcore.com> maritza@bae.bae.bellcore.com (Maritza Ramirez) writes:
>after I use the getsockaddr() call to get my local port and ip
>address, I can get the port number but, a 0 value for my local 
>ip address.

Bind() just assigns the address you specify to the socket, so it has the IP
address you gave it in the bind() call; INADDR_ANY == 0.

An unconnected socket generally doesn't have a specific local IP address
because you want to allow connections to any of your system's addresses (if
you're connected to the network, you have at least two IP addresses, the
address of your network interface and a loopback address 127.0.0.1).

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Sun, 11 Apr 1993 02:26:45 GMT
From:      streater@unixhub.SLAC.Stanford.EDU (Tim Streater)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Frame too short...

In article <1993Apr8.145923.1771@uni.ins.com> lad@uni.ins.com (Lawrence A. Deleski) writes:
>
>For example, SNMP packets are never larger
>than 56 bytes, which is considered an ethernet runt packet.  This is done so
>that most network devices will simply ignore an SNMP frame.  If your new
>10BaseT hub supports SNMP it may be the source of your runts, as most SNMP
>agents found in hubs often send out "uptime" traps, or single SNMP frames
>every minute or so.
>
This is surely nonsense. SNMP is based on the UDP protocol and as such does
not employ illegal packets of the type you describe. The packets are quite
legal; try capturing some with a Lanalyzer, for example, you will see that
there are many which are routinely hundreds of bytes long. Furthermore, an
agent does not send out unsolicted SNMP packets, except for traps.

Remember that many SNMP agents reside in end-nodes; workstations and the like.
These are hardly likely to have interfaces which can be easily programmed,
using the usual library calls, to break the rules.

Tim (beta tester of SNMP hardware and software).

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Sun, 11 Apr 1993 20:00:13 GMT
From:      bwolfe@is.rpslmc.edu (Brian Wolfe)
To:        comp.protocols.tcp-ip
Subject:   Printing via TCP/IP from MVS...


Hi there,

I'd like to be able to send print jobs from an IBM 3090 running MVS to
printers on TCP/IP terminal servers. We have TCP/IP for MVS and we
currently use a 3172 model 1 and a 3172 model 3 for telnet access.

Of course I'd like this to work in such a way that applications on the
3090 can't distinguish between a printer on SNA and one on TCP/IP.

I seem to get different stories about whether or not this is currently
possible.

Has anyone out there gotten this to work?

Any pointers appreciated!


regards,

Brian


Brian Wolfe					bwolfe@is.rpslmc.edu
Rush Presbyterian-St. Lukes Medical Center
Chicago IL     



-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 1993 04:49:29 MST
From:      RKU651@waccvm.corp.mot.com (Thiam-Yaw Chui)
To:        comp.protocols.tcp-ip
Subject:   Why FTP not work while PING said IP address is alive?

Can anyone tell mewhy FTP not working when my default gateway
is 255.255.255.255 while PING said IP address is alive? If I
use other Host's IP address both command would work however a
lot of FTP anonymous sites cannot be access.

Appreciate your reply. Thank you.
__________________________________________________________
TY CHUI
RKU651@klmcc1.sps.mot.com/ RKU651@waccvm.corp.mot.com

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Apr 1993 01:24:11 GMT
From:      seifert@netcom.com (Rich Seifert)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Frame too short...

In article <1993Apr8.145923.1771@uni.ins.com>, lad@uni.ins.com (Lawrence A. Deleski) writes:
> What you are seeing are ethernet runt packets, packets that are below the
> 64 byte minimum size.  Runt packets can be caused accidentally or
> intentionally.  If accidental, they are most likely caused as a result of a
> faulty ethernet interface somewhere on the network, or some driver or other
> software that has malfunctioned.  If intentional, they may be designed to
> be runts for a specific reason.  For example, SNMP packets are never larger
> than 56 bytes, which is considered an ethernet runt packet.  This is done so
> that most network devices will simply ignore an SNMP frame.  If your new
> 10BaseT hub supports SNMP it may be the source of your runts, as most SNMP
> agents found in hubs often send out "uptime" traps, or single SNMP frames
> every minute or so.
> 

I don't know where this misconception started.

SNMP **DOES NOT SEND RUNT PACKETS** intentionally !!

SNMP messages are encapsulated in UDP and IP, and then sent over 
(in this case) an Ethernet. If for some reason, the SNMP data+protocol
overhead was less than the 46 byte minimum data field of an Ethernet frame,
then the device driver (or LLC, if implemented) would pad it out to the
legal minimum.

If a station ever sent a frame (SNMP or otherwise) that was less than
64 bytes, then EVERY station would ignore it, including the intended
SNMP target!! Discarding of runt frames is implemented in the
Ethernet silicon. A runt frame is the result of a collision, and
the runt frame filter is the method receivers use to determine that
a received frame is a collision fragment.

That said, I know of a device which sends runt packets as for LOOPBACK
only, since it has a FIFO which is too small to receive an entire 
minimum length frame. Such a station may send a SINGLE runt upon
initialization, addressed to ITSELF. It will not bother anyone else
(but may bump a few collision counters by one---No big deal.)

That said, I know of a VERY SMALL set of devices which send runt

-- 
Rich Seifert                    Networks and Communications Consulting
seifert@netcom.com              (408) 996-0922
                                (408) 996-2860 FAX
"... specialists in Local Area Networks and Data Communications systems"

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 1993 02:07:05 GMT
From:      srikanth@garnet.berkeley.edu (Rajan Srikanth)
To:        comp.protocols.tcp-ip
Subject:   when to not replace old technology with new


At the Haas School of Business, University of California at Berkeley,
we are doing a study of what factors influence the decision to replace
or not replace old information technology/products with new information 
technology/products.

*** If you were involved with such a technology replacement situation, we
*** would like to include you in our study. We are especially interested in
*** responses from people who evaluated a replacement but DECIDED AGAINST.

Your participation will contribute to the progress of information technology!
In exchange for your participation, we would be happy to give you
information about our findings- to help you in future decision making.

We are interested in all technology areas and are especially interested in
the areas of DATABASES, IMAGING, and CLIENT-SERVER technology. For example,
we are looking for companies who considered replacement of
a non-relational database with a relational database. Or, replaced older
applications with new generation (e.g. client-server) applications.

If you can help, please provide us a regular (not just email) postal address.
To contact us, send email to
(Asst. Professor) Rajan Srikanth at srikanth@garnet.berkeley.edu or call him
at 510-643-9994 or call (MBA Student) Rehan Syed at 415-312-8420. If we are
not in when you call, please leave a message indicating when you can be
called back.

Thanks very much for your interest!

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

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 1993 12:47:15 GMT
From:      philip@server.uwindsor.ca (Philip Smith)
To:        comp.protocols.tcp-ip
Subject:   Multiple IP addresses

At the University of Windsor we have over 20 networks all joined together
by one super-router.  Until recently we had a one-to-one mapping between  
an ethernet address and IP address, but now we have clients with portable 
computers and X-terminals that want to take these devices from one network
to another.  

Does anyone have any suggestions on how to handle this situation?  Our 
current BOOTP server will only respond with one IP address for one ethernet
card.  Does anyone have a super BOOTP server or RARP server that will respond
with different IP address depending on subnet the request comes from?


Thank-you in advance,
Philip Smith
-- 
Philip Smith                   |  e-mail: PHILIP@UWINDSOR.CA
Systems Programmer             |  phone : (519)253-4232 ext.3252
Dept. of Computing Services    |  fax   : (519)973-7083
University of Windsor          | 

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Apr 1993 14:23:53 GMT
From:      koning@koning.enet.dec.com (Paul Koning)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Frame too short...


In article <1993Apr8.145923.1771@uni.ins.com>, lad@uni.ins.com (Lawrence A. Deleski) writes:
|>From article <1potmh$j27@helios.intranet.gr>, by antonis@intranet.gr (Antonis Kyriazis):
|>> 
|>> Hi
|>> 
|>> Recently we expanded a thin ethernet segment, by attaching a 12-UTP
|>> port hub. Unfortunately the users (3C503-TP) complain about NFS
|>> problems: They mount (with PC-NFS) directories on a HP-UX system and
|>> PKZIP or XCOPY don't work. A capture from Sniffer indicated "frame too short" for the frames generated from the PC when trying to NFS-write and "may be more in subsequent frames". Has someone any idea?
|>
|>
|>What you are seeing are ethernet runt packets, packets that are below the
|>64 byte minimum size.  Runt packets can be caused accidentally or
|>intentionally.  If accidental, they are most likely caused as a result of a
|>faulty ethernet interface somewhere on the network, or some driver or other
|>software that has malfunctioned.  If intentional, they may be designed to
|>be runts for a specific reason.  For example, SNMP packets are never larger
|>than 56 bytes, which is considered an ethernet runt packet.  This is done so
|>that most network devices will simply ignore an SNMP frame.  If your new
|>10BaseT hub supports SNMP it may be the source of your runts, as most SNMP
|>agents found in hubs often send out "uptime" traps, or single SNMP frames
|>every minute or so.

I don't know why the Sniffer doesn't call these things by their proper name.
"Frame too short" is misleading and has sent many people off in the wrong
direction, as we see here.

The normal cause of runts is neither of the two you've mentioned.  Instead,
runts are a NORMAL and EXPECTED consequence of collisions.  They are NOT
(normally) an indication of any broken hardware or software.  "Collision
fragments" is what they are often called; if the Sniffer had the good sense
to do that, a lot of confusion could be avoided.

The comment about short SNMP packets strikes me as highly unlikely.

	paul
|>-- 
|>        Lawrence A. Deleski         |       International Network Services
|>        lad@uni.ins.com             |       4701 Patrick Henry Drive
|>        uunet!uni!lad               |       Suite 1701
|>        MABELL:  (408) 496-1410     |       Santa Clara, CA 95054
|>
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, A-13683
! Digital Equipment Co., LKG1-2/A19, Littleton, MA 01460, USA
! (508) 486-7313 or (508) 952-3344, koning@koning.enet.dec.com
!-----------------------------------------------------------------------
! "The only purpose for which power can be rightfully exercised over 
!  any member of a civilized community, against his will, is to prevent
!  harm to others.  His own good, either physical or moral, is not
!  a sufficient warrant."    -- John Stuart Mill, "On Liberty" 1859


-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Apr 1993 15:28:53 GMT
From:      benoisme@agedwards.com (Mike Benoist)
To:        comp.protocols.snmp,comp.protocols.tcp-ip
Subject:   Sources for SNMP Software?

I am a new user to the Internet and would like information on SNMP.
Specifically, sources for software such as Remote Agents, RMON software
for servers, and TRAP's and/or TRAP generation software.

Thanks for your help!
Mike
benoisme@agedwards.com

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 93 15:48:44 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Why FTP not work while PING said IP address is alive?

In article <1993Apr12.115623.20398@schbbs.mot.com> RKU651@waccvm.corp.mot.com (Thiam-Yaw Chui) writes:
>Can anyone tell mewhy FTP not working when my default gateway
>is 255.255.255.255 while PING said IP address is alive? If I
>use other Host's IP address both command would work however a
>lot of FTP anonymous sites cannot be access.

Well, 255.255.255.255 is the IP Limited Broadcast address and doesn't
make much sense as a default gateway address.  Routers are not supposed
to forward such packets ("broadcast helpers" don't just forward).  I'd
not be suprised to find that many TCPs will not accept a connection that
came in a broadcast packet.  As for PING, the IP/ICMP code may well
allow responses to packets received as a physical level broadcast.

Art

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 1993 15:48:48 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Why FTP not work while PING said IP address is alive?

In article <1993Apr12.115623.20398@schbbs.mot.com> RKU651@waccvm.corp.mot.com (Thiam-Yaw Chui) writes:
>Can anyone tell mewhy FTP not working when my default gateway
>is 255.255.255.255 while PING said IP address is alive?`

Try setting your default gateway to a legal value.  "Routing" to the
broadcast address is a really bad idea.

-- 
Stephen Trier                      "It is proposed to reduce the effective
Network software type               data rate further by replacing the
Case Western Reserve University     tanks with shuttle launch vehicles."
trier@ins.cwru.edu                        - V. Cerf, RFC 1217

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Apr 1993 15:53:47 GMT
From:      weeks@weeks.austin.ibm.com (Craig Weeks)
To:        comp.protocols.tcp-ip
Subject:   TCP/2 for OS/2

Does anyone have any experience with TCP/2 from Essex Systems, Inc. in
Massachusetts?  I am specifically interested in their implementation for
OS/2 2.0.  Even more specifically, I am interested in knowing how
performance (response time, maximum transfer rate) of a socket
application on TCP/2 would compare to the same application running on
TCP/IP implementations from IBM, Microsoft and FTP Software, Inc.

Other than the 4 vendors mentioned here, are there any other
implementations for OS/2 2.0 that I should be aware of?

Craig Weeks
IBM Corp.
Austin, Texas

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Apr 1993 18:42:15 GMT
From:      lad@uni.ins.com (Lawrence A. Deleski)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Frame too short...



OK, OK, OK!  So I was mistaken.  I forget where I heard that SNMP packets
are considered runts, but I think it was at a seminar at Rutgers last year.
Not being an SNMP guru I took it at face value.

However, runts *can* be caused by broken hardware, as I have seen this many
times.  I have also known bad ports on repeaters to cause generation of
runt packets.  I have seen this mainly in PC's, where the interface is
either configured improperly or just plain bad.  

In any event, I stand corrected.  Thanks to Tim Streater, RIch Siefert, 
and Paul Koning for correcting my most obvious mistake.




-- 
        Lawrence A. Deleski         |       International Network Services
        lad@uni.ins.com             |       4701 Patrick Henry Drive
        uunet!uni!lad               |       Suite 1701
        MABELL:  (408) 496-1410     |       Santa Clara, CA 95054

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 1993 20:28:05 GMT
From:      kakazu@racerx.cit.cornell.edu (Gary Kakazu)
To:        comp.protocols.tcp-ip
Subject:   Compiling "Unix Network Programming" progs on a Sun

Has anyone got the programs from Richard Steven's book "UNIX Network
Programming" book to compile under Sun OS 4.1.1?  Some of the include files are
missing. I've tried compiling the programs in the lib subdirectory with
BSD defined, but I get the following when compiling idpopen.c

gcc -O  -target sun4 -c  -DBSD idpopen.c
idpopen.c:8: netns/ns.h: No such file or directory

So, I thought I would try compiling as a Sys V system using the programs in
lib.s5.  This time, rresvport.c couldn't find sys/inet.h.

Thanks for any help
Gary

-- 

Cub fan, Homebrew man

Gary Kakazu				kakazu@cornell.edu
Network Specialist			(607) 255-1679 
Network Support Services
Cornell Information Technologies
Cornell University

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Apr 1993 20:36:00 GMT
From:      karl@empirical.com  (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: Traceroute for MS-DOS Systems and Other Personal Computers

> Are there any versions of the "traceroute" program which will run on MS-DOS
> computers?
There are various places where you can get a traceroute for PC's...
We've got one in our own products (I'm at Empirical Tools and Technologies)
It's mixed into a single executable that can run lots of simultaneous pings,
traceroutes, netwatches, ... and lots more.  All it needs is a packet
driver (and a reasonable PC).  A mouse is useful.  (Contact me for more
information.)
FTP Software's PC/TCP ver 2.2 also has a traceroute built into the "ping"
command.
I'm not sure, but also check with Beame and Whiteside.
For the Mac, check with Intercon.
			--karl--
			Karl Auerbach, Empirical Tools and Technologies
			517-C Mission Street, Santa Cruz, CA   95060
			(408) 427-5280 (voice), (408) 427-5281 (fax)
			karl@empirical.com

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Apr 1993 20:45:00 GMT
From:      karl@empirical.com  (Karl Auerbach)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Frame too short...

> For example, SNMP packets are never larger
> than 56 bytes,
Wrong.  SNMP packets come in all sizes.  And if they are shorter
than 60 bytes (including all appropriate wrappers), they are padded to
the minimum media length.
I've never seen an SNMP agent sent runts.  And I've seen (and written) a
lot of SNMP agents, especially ones that run in 10-Base-T concentrators/hubs.
> that most network devices will simply ignore an SNMP frame.  If your new
> most SNMP
> agents found in hubs often send out "uptime" traps, or single SNMP frames
> every minute or so.
Most hubs are not that spontaneously chatty (at least not in SNMP-ese).
Some hubs (e.g. Synoptics) send out proprietary packets to a multicast
MAC address to do topology and the like.
> Do this; check all of your ethernet adapters to make sure they are all
> functioning properly.  Then rent a TDR and check you thinnet segments for
> shorts, opens, and the proper characteristic impedeance, and if all of that
> checks out, start isolating machines from the network and see if your
> problem goes away.  Any way you cut it, you're going to have to
> trial-and-error troubleshoot this problem.  Good Luck.
Good advice.  (Although I'd to the TDR later rather than sooner if I didn't
have one handy.)  Also see if you can snapshot the source address on one
of the runts.  Do have a cross reference sheet of MAC address to machine?
(Most people don't, but should have.)
				--karl--

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Apr 1993 21:08:54 GMT
From:      paulo@ohmeda.com (Paul E. Ourada)
To:        comp.protocols.tcp-ip
Subject:   Socket creation weirdness

Greetings TCP Wizards:

Why, oh WHY! does the following happen?  I am working on a Sun IPC, and
I am *trying* to learn some rudimentary socket programming, and I have
RTFM *fairly* responsibly, I think.  Now for the problem.  In short,
I create a socket using the socket() sys call.  Like a good little
SE, I test for success, and sure enuf, it is greater than 0.  In fact,
it is 1.  Now, I am a little suspicious of a socket descriptor that has
such a small number, but it's greater than -1, right?  So I wander on
down the road a bit, and finally try to bind the descriptor using what
other than bind().  Again, I dutifully check for an error, and this time
it tells me that the socket descriptor is invalid...  ARRRGGHH!

I have checked all sortsa stuff, like is the socket type set right, yup,
is the address family right, well, if AF_INET is right it is, is the
socket name that I'm trying to bind to OK, checked two ways, yup.

I'd really appreciate some help.  Here are a cupla code frags...

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
if ( Socket_Descriptor = socket( AF_INET, Socket_Type, 0 ) >= 0 )
   {
      cout << "Socket_Descriptor = " << Socket_Descriptor << "\n";
				:
				:
 Server_Descriptor = Socket_Descriptor;	// the descriptor that listens...
				:
if ( bind( Server_Descriptor, &Socket_Name, sizeof ( Socket_Name ) ) < 0 )

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I have checked via the ubiquitous embedded print statements, the values
contained in Server_Descriptor, Socket_Descriptor, and Socket_Name, and
they appear to be the appropriate values -- i.e. XXXX_Descriptor has the
value 1, and Socket_Name has the IP address of my IPC in sa_data and the
value 4999 in sa_family.  I picked that number because it was right 
below some cutoff specified in <netinet/in.h>.  The number was 
IPPORT_USERRESERVED.

I'd really appreciate a guiding hand.

Paul Ourada
paulo@ohmeda.com


-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Apr 1993 23:38:27 GMT
From:      bmiller@cabell.vcu.edu (Bryan E. Miller)
To:        comp.protocols.tcp-ip
Subject:   TCPdump


Greetings,

Can someone give me some guidance on installing packetfilters
on a DECstation running 4.2 Ultrix?  I am trying to use the
TCPdump 2.2 program from LBL.  I've created the packetfilter
devices using "MAKEDEV pfilt".  It created a "pf" directory
in /dev, and created pfilt0 - pfilt63.  

I tried using pfconfig to turn on promiscuous mode on the Ethernet
interface (ln0), but each time I type the command I get "device
not found".  I can use ifconfig on ln0 and turn on promiscuous
without problems.  Does ifconfig and pfconfig do the same thing,
or do I need to figure out why pfconfig isn't working?

One other question, are there kernal mods that have to be done to
enable packetfilters?

Thanks.

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Apr 1993 23:49:55 GMT
From:      seifert@netcom.com (Rich Seifert)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Frame too short...

In article <1993Apr12.184215.12456@uni.ins.com>, lad@uni.ins.com (Lawrence A. Deleski) writes:
> 
> However, runts *can* be caused by broken hardware, as I have seen this many
> times.  I have also known bad ports on repeaters to cause generation of
> runt packets.  I have seen this mainly in PC's, where the interface is
> either configured improperly or just plain bad.  
> 

By the tone of this, it seems you are implying that there is some
sort of PC-based repeater which has this problem. While there are
some PC-based bridges (which are full-frame store-and-forward device)
there is no such thing as a PC-based Ethernet repeater. A repeater
does not contain a MAC state machine, and must operate on the
individual bit level. There is generally a bit-silo and a physical
layer state machine which operates at media speed.

Because of this, repeaters are invariably special-purpose devices. This
includes thick/thin repeaters and 10Base-T hubs.

BTW, no need to apologize for throwing up a target which a lot of
people shoot at. We're all learning how this stuff works.



-- 
Rich Seifert                    Networks and Communications Consulting
seifert@netcom.com              (408) 996-0922
                                (408) 996-2860 FAX
"... specialists in Local Area Networks and Data Communications systems"

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 1993 00:42:35 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: TCPdump

In article <1993Apr12.233827.19039@cabell.vcu.edu> bmiller@cabell.vcu.edu (Bryan E. Miller) writes:
>Can someone give me some guidance on installing packetfilters
>on a DECstation running 4.2 Ultrix?  I am trying to use the
>TCPdump 2.2 program from LBL.  I've created the packetfilter
>devices using "MAKEDEV pfilt".  It created a "pf" directory
>in /dev, and created pfilt0 - pfilt63.  

Not enough.  You have to reconfigure your kernel to include
packet filter support (it's not there by default, so that
people who don't need it don't waste kernel memory on it).

According to "man 4 packetfilter", you need to add these lines to
your configuration file:
	options   PACKETFILTER
	pseudo-device  packetfilter

Read "man doconfig" and the Guide to System Configuration File Maintenance
for more info.

-Jeff

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 93 01:24:33 GMT
From:      sklower@diva.Berkeley.EDU (Keith Sklower)
To:        comp.protocols.tcp-ip
Subject:   Re: How to route xns over an ip backbone??

In article <1993Apr9.155847.15994@leland.Stanford.EDU> "Rob Tanner" <rob@sherlock.stanford.edu> writes:
>By administrative mandate, all our subnet routers are configured to
>route IP only.C...
>I now have a problem where there is a need to install a client work
>station in one building, and have that workstation talk to a server in
>another ...  and the protocol the system uses to talk between client
>and server is xns.

We have had the same admnistrative mandate here at UC Berkeley,
and I put code into the 4.3 BSD release to support this.
We had IP bridges between CS and Mechanical engineering
(so they could use our file server), and cornell university
just to show it could be done accross the internet.

The syntax was a little funky:

	ifconfig ec0 2272 # to set the xns address of the local interface
	ifconfig lo0 2642:2.60.8c.0.5.82 ipdst cad # establish tunnel

Should still work!

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Apr 93 02:50:23 GMT
From:      ajw@squid.mel.dit.CSIRO.AU (Andrew Waugh)
To:        comp.protocols.tcp-ip
Subject:   Re: Socket creation weirdness

In article <1993Apr12.210854.714@ohmeda.com> paulo@ohmeda.com (Paul E. Ourada) writes:
>if ( Socket_Descriptor = socket( AF_INET, Socket_Type, 0 ) >= 0 )

try

if (( Socket_Descriptor = socket( AF_INET, Socket_Type, 0 )) >= 0 )
    ^                                                      ^

(Yes, the socket description was greater than 0...)

andrew waugh

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Apr 1993 03:05:38 GMT
From:      thorinn@diku.dk (Lars Henrik Mathiesen)
To:        comp.protocols.tcp-ip
Subject:   Re: Socket creation weirdness

Always put parentheses around an assignment if it is part of a larger
expression. (See also the operator precedence section of your favourite
C programming text.) In your case, you should have written

if ( ( Socket_Descriptor = socket( AF_INET, Socket_Type, 0 ) ) >= 0 )

Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 1993 15:37:45 -0700
From:      markb@spock.dis.cccd.edu (Mark Bixby)
To:        comp.protocols.tcp-ip
Subject:   How does the NFSNET know the route to my IP address?

Somebody joins Internet and gets an IP address assigned to them.  How are the
many, many routers on the NSFNET notified of the resulting new route?  Due to
the sheer overwhelming size of the net, I'm sure there's got to be some
automatic router protocol to propagate this information.  Can anybody provide
me the relevant acronyms (and optionally RFC numbers)?

Thanks.
-- 
Mark Bixby                         Internet: markb@cccd.edu
Coast Community College District   1370 Adams Avenue
District Information Services      Costa Mesa, CA, USA  92626
Technical Support                  (714) 432-5064
"You can tune a file system, but you can't tune a fish." - tunefs(1M)

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 93 08:04:17 GMT
From:      gt6444c@prism.gatech.EDU (Chip Edwards)
To:        comp.protocols.tcp-ip
Subject:   SLIP or what?


  I have unix(Linux) running on my machine. Presently I can redirect shells,
xwindows, and ports from my school(Ga TECH) to home. However, I am limited to
certain alocation units. I now wish to mount my computer to Internet. What
is the best way? Is there a place in Atlanta where I can get a permenate
SL/IP connection. (With reasonable fee.) This might be a dumd question, but
could I have a direct connection to my pc? (Ethernet or whatever? Would
this be extremly expensive? I would guess so? Please, easy on the flames.) 
:) I'm willing to pay, *within reason, for such a connection. SLIP or TCP/IP)
Oh yes, I have a 14.4k (16.8. ZyXEL) modem.
Please, e-mail me. Any help would be most, and I mean most, appreaciated.
Thank You,
Chip

-- 
Chip Edwards (gt6444c@prism.gatech.edu)
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt6444c
Internet: gt6444c@prism.gatech.edu

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Apr 1993 13:15:44 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Socket creation weirdness

paulo@ohmeda.com (Paul E. Ourada) writes:
+Greetings TCP Wizards:

+Why, oh WHY! does the following happen?  [...tale of much woe elided...]

+if ( Socket_Descriptor = socket( AF_INET, Socket_Type, 0 ) >= 0 )
     (                                                     )
     \----------------- insert these parens ---------------/

+      cout << "Socket_Descriptor = " << Socket_Descriptor << "\n";

Oh, here's another problem, you're using bletcherous C++  ;-)
(If you used C you could find this with lint, no problem)

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

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Apr 1993 14:26:55 GMT
From:      cleelacj@agedwards.com (Chris Cleeland)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   Experience with two LAN cards on the same network?

[Notice that I have set followups to comp.sys.hp]

Does anybody out there have experience with setting up two LAN cards
whose respective IPs are on the same network?  Just for information's
sake, I'm doing this on an HP 8x7 series.

Let me elaborate a bit.  I have two IP segments, but both are within
the same class B network, say 150.120.  Each card will have an IP
attached to it (sorry if that's obvious), and the computer will act
kind of like a router between the two segments.  This is done because
one segment goes across a satellite where you consequently only want
necessary traffic.  The other segment is local over coax, so it
doesn't matter as much.

At the moment, there are not two cards; everything is on a single
segment.  There is a program which opens one socket (call it "A")
across what will eventually be the satellite's segment, and another
socket (call it "B") across what will be the local segment.  The
endpoint of "A" has an IP of 150.120.254.25, and the endpoint of "B"
has an IP of 150.120.227.32.  Each goes out through the same LAN card.

When we get two cards (and thus two segments), the scenario will
change a bit.  The IP addresses will most likely remain the same, but
"A" will have to go out across one card (which is connected to the
satellite), and "B" will go across the other cards (which is connected
to the local coax).

The question is, how can I do this?  My experience with multiple LAN
cards where the computer acts as a router is in situations where the
IP segments are radically different in their addressing, and, thus,
there is no chance of ambiguity in choosing on which card to send.
But in this situation, the IPs are quite similar, and I'm not quite
sure how to pursuade some traffic to be sent out on one card and other
traffic to go out a different card.  For that matter, I'm not even
sure *WHO* (programmatically, or daemon-wise, etc.) I should tell.

Can anyone help?

Thanks much!
-cj





-- 
==============================================================================
Chris Cleeland 	       	       	|  Internet:   cleelacj@agedwards.com
BOS Dev. Team                   |  USnail:     3878 Connecticut St. Louis 63116
                                |  BellNet:    (314) 289-5372

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Apr 1993 14:53:35 GMT
From:      m23364@mwunix.mitre.org (James Meritt)
To:        comp.protocols.tcp-ip
Subject:   Priority information


I heard (second hand) that priority (of delivery/route) information is
contained in the TCP-IP headers (but unused).  Is this so, and how might it
be utilized?

Jim Meritt

--
James W. Meritt:  m23364@mwunix.mitre.org - or - jmeritt@mitre.org
The opinions above are mine.  If anyone else wants to share them, fine.
They may say so if they wish. The facts "belong" to noone and simply are.

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Apr 93 15:07:26 GMT
From:      maritza@bae.bae.bellcore.com (Maritza Ramirez)
To:        comp.protocols.tcp-ip
Subject:   RPC Servers Question



What is the difference between an RPC server that is multitasking
and an RPC server that is asynchronous and multitasking ? 

Maritza


-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 93 15:19:32 GMT
From:      dryfo001@deneb.mc.duke.edu (James D Dryfoos)
To:        comp.protocols.tcp-ip
Subject:   Looking for Proxy-ARP server -- particularly for SUNs


I need to find a proxy-ARP server that will run on a Sun.

Thanks in advance.

Jim

--
   =======================================================================
      James D. Dryfoos                  |  dryfo001@mc.duke.edu
      Duke University Medical Center    |  dryfo001@dukemc.bitnet
      2200 West Main Street             | 
      Suite 450 Room 36A                |  (919) 286-6391 - office
      Durham, NC 27710 Earth            |  (919) 286-6369 - fax
   =======================================================================

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Apr 1993 15:46:25 GMT
From:      mwr@eng.tridom.com (Mark Reardon)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Frame too short...

In article <1993Apr8.145923.1771@uni.ins.com>, lad@uni.ins.com (Lawrence A. Deleski) writes:
|> From article <1potmh$j27@helios.intranet.gr>, by antonis@intranet.gr (Antonis Kyriazis):
|> > 
|> > Hi
|> > 
|> > Recently we expanded a thin ethernet segment, by attaching a 12-UTP
|> > port hub. Unfortunately the users (3C503-TP) complain about NFS
|> > problems: They mount (with PC-NFS) directories on a HP-UX system and
|> > PKZIP or XCOPY don't work. A capture from Sniffer indicated "frame too short" for the frames generated from the PC when trying to NFS-write and "may be more in subsequent frames". Has someone any idea?
|> 
|> 
|> What you are seeing are ethernet runt packets, packets that are below the
|> 64 byte minimum size.  ...... ( lots deleted )

Runts occur on ethernet and aren't a problem in and of themselves.
If a proper collision occurs a runt is created.  Since it is smaller
than the minimum 64 byte frame, ethernet controllers may ignore it.
As you see with the sniffer, some controllers can be programmed to 
receive the runt.  Beware the the information in the runt may be 
in error since the CRC is not valid in a runt.

If the source address appears valid you may use it to determine the
source of the runt but you still do not know that it is a problem.  If the
source of the packet never attempts to retransmit, then there may be a
problem with this device.  It may beleive that the net is always busy
or have some other retransmission problem.  Since you see the same 
problem from multiple nodes I tend to discount this possibility
(I find it unlikely that multiple 3C503's are bad).  I would instead
look more at the NFS mounting and the application for the real problem.
I beleive the sniffer has led you to look in the wrong area for the
problem.

-- 
_____________________________________________
Mark Reardon   AT&T Tridom   (404-514-3383)
email: mwr@tridom.eng.tridom.com, attmail!tridom!mwr

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 93 16:39:06 GMT
From:      dpike@oavax.csuchico.edu (Dan Pike)
To:        comp.protocols.tcp-ip
Subject:   RARP through a Router?

Why am I not able to RARP across a router?  I have a bridge and our
management station on the same Cabletron MMAC, but I'm still not able to
RARP an IP address to the bridge.  The two devices are in different
subnets (one is in .78.xxx and the other is in .80.xxx).  Interface 0 of
our AGS+ goes to a port on the FOMIM which also connects all of our
buildings via fiber.  The subnet mask of each of the buildings on campus
is set up as though it was a class c address.  Why will the router not
allow the management station to RARP an IP address to the bridge?  Any
help you can offer would be greatly appreciated.

Dan Pike
Network Specialist
California State University, Chico
dpike@csuchico.edu

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Apr 1993 17:40:26 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Socket creation weirdness

In article <1993Apr12.210854.714@ohmeda.com> paulo@ohmeda.com (Paul E. Ourada) writes:
>if ( Socket_Descriptor = socket( AF_INET, Socket_Type, 0 ) >= 0 )
>
>I'd really appreciate a guiding hand.

OK.  Unless you're intentionally trying to make your code obscure,
always try to do only one thing at a time:

Socket_Descriptor = socket( AF_INET, Socket_Type, 0 );
if ( Socket_Descriptor >= 0 )
  ...

If you had taken this approach, you never would have been caught by
the fact that the assignment operator has a lower precedence than the
greater-then-or-equal operator.
						don provan
						donp@novell.com

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 93 20:25:11 GMT
From:      itbwvb@puknet.puk.ac.za (Wilhelm van Belkum)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Frame too short...

In article <1993Apr12.184215.12456@uni.ins.com> lad@uni.ins.com (Lawrence A. Deleski) writes:
>From: lad@uni.ins.com (Lawrence A. Deleski)
>Subject: Re: Frame too short...
>Date: Mon, 12 Apr 1993 18:42:15 GMT
>
>
>OK, OK, OK!  So I was mistaken.  I forget where I heard that SNMP packets
>are considered runts, but I think it was at a seminar at Rutgers last year.

!Try having a look at FAQ date 5 JAN 1993 Q1 !
!It look's like we are all reading the FAQ's

>Not being an SNMP guru I took it at face value.
>
>However, runts *can* be caused by broken hardware, as I have seen this many
>times.  I have also known bad ports on repeaters to cause generation of
>runt packets.  I have seen this mainly in PC's, where the interface is
>either configured improperly or just plain bad.  
>
>In any event, I stand corrected.  Thanks to Tim Streater, RIch Siefert, 
>and Paul Koning for correcting my most obvious mistake.
>
>
>
>
>-- 
>        Lawrence A. Deleski         |       International Network Services
>        lad@uni.ins.com             |       4701 Patrick Henry Drive
>        uunet!uni!lad               |       Suite 1701
>        MABELL:  (408) 496-1410     |       Santa Clara, CA 95054
 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
                
 

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 1993 00:38:23 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.dcom.lans,comp.protocols.snmp,comp.protocols.tcp-ip
Subject:   Low Cost MultiPort Thinnet Repeater with SNMP?

Does anyone know of a low cost multiport thin ethernet repeater that
can be monitored with snmp?

Failing that, recommendations for low cost units with good monitoring
lights would be appreciated.


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



-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Apr 1993 17:14:57 -0700 (PDT)
From:      Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
To:        comp.protocols.tcp-ip
Subject:   proxy ARP for UNIX?

I recently added an ATT 3B1 (the old UNIX PC) to my network.  Its TCP
implementation is so old, it doesn't support subnetting.  Well, that's
alright, proxy ARP would take care of that problem, right?  Well, yes, 'cept
that the hub of my network (and the gateway to all other subnets and the rest
of the world) is a NeXT (running a BSD UNIX clone) and it doesn't seem to know
to do proxy ARP when it's acting as a gateway.

I've worked around the problem by manually inserting all known addresses on
other subnets into the 3B1's ARP table, all pointing at the NeXT, but it's a
bit annoying to have to remember to do that every time I add a new host on
another subnet.

So, does anyone have a proxy ARP program for UNIX that will run on NeXTs?  [I
fear the ``run on NeXTs'' part is the hard one.....]


-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 1993 07:04:20 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: How does the NFSNET know the route to my IP address?

In article <1qffbp$nui@spock.dis.cccd.edu> markb@cccd.edu writes: 
    Somebody joins Internet and gets an IP address assigned to them.  How
    are the many, many routers on the NSFNET notified of the resulting new
    route?  Due to the sheer overwhelming size of the net, I'm sure there's
    got to be some automatic router protocol to propagate this information.
    Can anybody provide me the relevant acronyms (and optionally RFC
    numbers)?
    
See BGP, OSPF, RIP and EGP.

Tony

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 1993 07:05:44 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP through a Router?

In article <1qeqbaINNkka@charnel.ecst.csuchico.edu>
dpike@oavax.csuchico.edu (Dan Pike) writes: 
    Why am I not able to RARP across a router?  I have a bridge and our
    management station on the same Cabletron MMAC, but I'm still not able to
    RARP an IP address to the bridge.  The two devices are in different
    subnets (one is in .78.xxx and the other is in .80.xxx).  Interface 0 of
    our AGS+ goes to a port on the FOMIM which also connects all of our
    buildings via fiber.  The subnet mask of each of the buildings on campus
    is set up as though it was a class c address.  Why will the router not
    allow the management station to RARP an IP address to the bridge?  Any
    help you can offer would be greatly appreciated.
    
RARP is an unroutable protocol.  It must be bridged.

Tony

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Apr 1993 13:11:04 GMT
From:      news@bernina.ethz.ch (USENET News System)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!


In article <1993Apr2.133203.623@indyvax.iupui.edu> harvey@indyvax.iupui.edu writes:
>In article <1993Mar30.121411.9759@unipalm.co.uk>, ian@unipalm.co.uk (Ian Phillipps) writes:
>>[stuff deleted]
>> To get things in perspective: the class Cs are still allocating in the
>> 193... series.
>
>Oops -- somebody better tell the new NIC then:
>
>% nslookup internic.net
>Server:  hummer.iupui.edu
>Address:  134.68.1.9
>
>Name:    internic.net
>Address:  198.41.0.5
>
>%
>
>>                That's quite a few more to go. An important problem,
>> which must be (and can be) solved, but not one that's going to stop us
>> in the next few months.
>
>I think running out of class Bs is supposed to be the immediate problem.
>Once using class Cs in blocks becomes common practice then they will start
>disappearing faster too.  Oh well.
>
>>
>>>Thats before you start to consider toasters etc with an internet address.
>>
>> There are more IP addresses available than the toaster population of the
>> earth :-)
>
>Yeah -- and who'll ever really need more than 640K of memory? :-) :-)
>--
>James Harvey    IUPUI OIT Technical Support -- VMS/Unix/Networks
>harvey@iupui.edu  uucp:iugate!harvey  bitnet:harvey@indyvax

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 93 13:59:06 GMT
From:      dickson@escob1.UUCP (Dave Dickson)
To:        comp.lang.perl,comp.protocols.tcp-ip
Subject:   Need h2n - Perl Script


Could someone please provide me with the h2n program referred to
in the Nutshell book, "DNS and BIND".  This is a perl script that
converts from hosts files to DNS database entries.  We are not
on the Internet, yet, so would appreciate a followup or email.

Thanks.

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Apr 1993 14:07:18 GMT
From:      aungk@imea11.enet.dec.com (Kyaw Thet Aung)
To:        comp.protocols.tcp-ip
Subject:   RFC ... HELP...

Help, 
    Could anyone tell me where RFC 1035, 1338, 1347 reside on the net,
or could 
    someone email me please. They are mentioned in the RIPE NCC IP
number request
    document and I can't find them.

Cheers,

Kyaw.

(email : aungk@uproar.enet.dec.com  or aungk@imea11.enet.dec.com )


-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Apr 1993 14:10:24 GMT
From:      stacy@sobeco.com (Stacy L. Millions)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   RIP problem


I'm having some problems with an incompatibility between RIP as implemented
in gated version 2.1.development and as implemented in cisco's 8.3(3) code.

T---------+-----------T
          | 132.220.14.1
      +-------+
      | MIPS  | B
      +-------+
             |
             |
             |
    other    |
  slip links | slip link
       | | | |
      +-------+
      | MIPS  | A
      +-------+
          | 132.220.1.3
T---------+-----------T
          | 132.220.1.70
      +-------+ T
      | AGS+  |-|
      +-------+ |
       |  |  |  |
       |  |  |  T


The "other slip links" that connect to mips A use a fake subnet,
132.220.10.0 (for pc's running PC-NFS or PC/TCP or something similiar)
so mips A will end up with interfaces like this:

slip0: inet 132.220.10.1 --> 132.220.10.2 netmask 0xffffff00
slip1: inet 132.220.10.5 --> 132.220.10.6 netmask 0xffffff00
slip2: inet 132.220.10.10 --> 132.220.10.11 netmask 0xffffff00

The slip link between mips A and mips B use the same IP address as their
ethernet interface, so mips A has an interface:

slip3: inet 132.220.1.3 --> 132.220.14.1 netmask 0xffffff00

and mips B has an interface:

slip0: inet 132.220.14.1 --> 132.220.1.3 0xffffff00

The problem:

The cisco implementation of RIP doesn't implement host routes and does not
ignore them like RFC1058 says it should if it is not going to implement
them.

The cisco receives a routing update:

from 132.220.1.3
    132.220.10.2 in 1 hops
    132.220.10.6 in 1 hops
    132.220.10.10 in 1 hops
    132.220.14.1 in 1 hops
    132.220.14.0 in 2 hops

from this information it generates a routing update of:
    subnet 132.220.1.0 metric 1
    subnet 132.220.10.0 metric 2
    subnet 132.220.14.0 metric 16

according to RFC1058 section 3.4.2:

If the implementor has chosen not to support host routes (see section 3.2),
check to see whether the host portion of the address is non-zero; if so,
ignore the entry.

Therefore the generated update packet should be:
    subnet 132.220.1.0 metric 1
    subnet 132.220.14.0 metric 3


A variation on this problem is when one of the slip interfaces goes down,
the cisco will get a routing update:

from 132.220.1.3
    132.220.10.2 in 1 hops
    132.220.10.6 in 16 hops (inaccessible)
    132.220.10.10 in 1 hops

and will generate an update packet like:
	subnet 132.220.1.0 metric 1
	subnet 132.220.10.0 metric 16

This will effectively freeze all the other slip links until such time
as the 132.220.10.6 route times out.

Now I realise that I can configure gated around these problems, but I
shouldn't have to. The only thing I should have to configure in gated
is to have mips A advertise a route for subnet 132.220.10.0. Then things
should work properly (read "as I expect them to" :-) with any
implementation of RIP that either supports host routes or ignores host
routes.

Is this problem resolved in a more recent release of the cisco code
or does cisco consider this a "feature"?

-stacy

-- 
Q: What is the difference between a                           stacy@sobeco.com
   'but kisser' and a 'brown noser'?                           stacy@sobeco.ca
A: Depth perception.                                              sobeco!stacy

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Apr 1993 14:14:58 GMT
From:      elci@bugs.fi.gs.com (Reha Elci)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,
Subject:   Can anyone point me to a TCP/IP implementation?



I am trying to locate (public domain or to buy) the source code, written in C,
of a complete TCP/IP implementation as well as the layers below so that
I can have turnkey package to go on a platform given an ethernet chip,
and O/S independent.

Does something like this exist? If now, what pieces are available? TCP/UP
implementation would already be a big help.

Thanks a lot for your help.

Reha Elci

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Apr 1993 14:30:26 GMT
From:      aungk@uproar.enet.dec.com (Kyaw Thet Aung)
To:        comp.protocols.tcp-ip
Subject:   RFC 1035, 1338, 1347

 Hi,
    I am looking for the RFC 1035 1338 and 1347 specs. If anyone can
point me in the right
direction please email me or even better email or post the specs.

Thanks

Kyaw

email : aungk@uproar.enet.dec.com or aungk@imea11.enet.dec.com

 



-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 1993 17:33:46 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: RIP problem

In article <1993Apr14.141024.933@sobeco.com> stacy@sobeco.com (Stacy L.
Millions) writes: 

    The cisco implementation of RIP doesn't implement host routes and does not
    ignore them like RFC1058 says it should if it is not going to implement
    them.
    
Stacy,

Version 9.1 supports host routes.  I suggest you upgrade.

Alternately, you can configure an access list to cause the cisco to ignore
host routes:

router rip
distribute-list 1 in

access-list 1 permit 132.220.0.0 0.0.255.0	! Accept subnets
access-list 1 deny   132.220.0.0 0.0.255.255	! Reject host routes
access-list 1 permit 0.0.0.0 255.255.255.255	! Accept everything else

Tony

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 1993 17:39:16 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple IP addresses

In article <C5GHsw.5tB@atlas.abccomp.oz.au> paul@atlas.abccomp.oz.au (Paul
Brooks) writes: 

    The BOOTP/RARP server would have to operate on the super-router to know
    what subnet the request came from. 

Some (most?) routers know how to forward BOOTP requests.  The BOOTP request
is modified by the router so that it's possible to determine the subnet
that the request came from.  

Tony

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 1993 18:45:24 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.dcom.lans,comp.protocols.snmp,comp.protocols.tcp-ip
Subject:   Re: Low Cost MultiPort Thinnet Repeater with SNMP?

Ken Mandelberg (km@mathcs.emory.edu) wrote:
> Does anyone know of a low cost multiport thin ethernet repeater that
> can be monitored with snmp?

I do not know what you mean by low cost, but the HP 28692A ThinLan Hub
Plus has a dealer list price in the US of $2900 and can be monitored
with SNMP.  It has 9 BNC ports and one AUI port.  It also has an RS-232
connector for a terminal connection so that a terminal (or emulator) can
gather hub statistics and perform certain control functions.

- Steve Kao

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Apr 1993 19:44:52 GMT
From:      stewart@oin.cis.udel.edu (John Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: How does the NFSNET know the route to my IP address?

In article <1qgd1kINN50o@cronkite.cisco.com> tli@cisco.com (Tony Li) writes:
>In article <1qffbp$nui@spock.dis.cccd.edu> markb@cccd.edu writes: 
>    Somebody joins Internet and gets an IP address assigned to them.  How
>    are the many, many routers on the NSFNET notified of the resulting new
>    route?  Due to the sheer overwhelming size of the net, I'm sure there's
>    got to be some automatic router protocol to propagate this information.
>    Can anybody provide me the relevant acronyms (and optionally RFC
>    numbers)?
>    
>See BGP, OSPF, RIP and EGP.

Also see IS-IS; I think that's the intra-domain routing protocol
currently in use in the NSFNET (a.k.a ANSNET).

A very good reference on the routing protocols mentioned so far
(as well as a general study in the "how do you get there from
here" problem) is Radia Perlman's _Interconnections: Bridges and
Routers_.

Good luck.

/jws

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Apr 1993 23:15:53 GMT
From:      tkevans@fallst (Tim Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: How does the NFSNET know the route to my IP address?

tli@cisco.com (Tony Li) writes:

>In article <1qffbp$nui@spock.dis.cccd.edu> markb@cccd.edu writes: 
>    Somebody joins Internet and gets an IP address assigned to them.  How
>    are the many, many routers on the NSFNET notified of the resulting new
>    route?  Due to the sheer overwhelming size of the net, I'm sure there's
>    got to be some automatic router protocol to propagate this information.
>    Can anybody provide me the relevant acronyms (and optionally RFC
>    numbers)?
>    
>See BGP, OSPF, RIP and EGP.

Don't forget DNS!
-- 
UUCP:		{rutgers|ames|uunet}!mimsy!wb3ffv!fallst!tkevans
INTERNET:	tkevans@fallst.es.dupont.com
Tim Evans	2201 Brookhaven Ct, Fallston, MD 21047

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Apr 1993 23:19:43 GMT
From:      scott@nova.tcs.tufts.edu (Scott R. Corzine)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple IP addresses

In article <1qhi84INNhjj@cronkite.cisco.com> tli@cisco.com (Tony Li) writes:
> In article <C5GHsw.5tB@atlas.abccomp.oz.au> paul@atlas.abccomp.oz.au (Paul
> Brooks) writes: 
 
>     The BOOTP/RARP server would have to operate on the super-router to know
>     what subnet the request came from. 
 
> Some (most?) routers know how to forward BOOTP requests.  The BOOTP request
> is modified by the router so that it's possible to determine the subnet
> that the request came from.  

    Specifically, what modifications does the router perform to the
    BootP request?  I didn't notice anything in the RFC's, so I guess
    that such modifcations are implementation dependent.

				-Scott-

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 1993 00:31:24 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple IP addresses

In article <SCOTT.93Apr14181944@nova.tcs.tufts.edu>
scott@nova.tcs.tufts.edu (Scott R. Corzine) writes: 

        Specifically, what modifications does the router perform to the
        BootP request?  I didn't notice anything in the RFC's, so I guess
        that such modifcations are implementation dependent.
    
From RFC 951:
   If a gateway does decide to forward the request, it should look at
   the 'giaddr' (gateway IP address) field.  If zero, it should plug its
   own IP address (on the receiving cable) into this field.  

The BOOTP server needs some mechanism (static table, participating in a
routing protocol [ugh]) to infer which subnet the routers address belongs
to.  This mechanism becomes more awkward when there are multiple subnets on
a single interface.

Tony



-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Apr 1993 00:35:32 GMT
From:      jthill@us.oracle.com (Jim Hill)
To:        comp.protocols.tcp-ip
Subject:   Nagle details and performance questions

Hi, I have a question on a specific detail of Nagle's small-packet
solution in RFC896.  Nagle says that to avoid tiny-packet overhead,
the TCP should "inhibit the sending of new TCP segments when new
outgoing data arrives from the user if any previously transmitted data
on the connection remains unacknowledged."
 
One implementation I know of has interpreted this to mean that, if the
user sends MSS+n bytes on an idle connection, the n-byte leftover will
not be sent until the full segment is acknowledged.  On long nets this
can be a noticeable throughput hit.
 
I can't see how they got that interpretation out of the RFC, and
although I think it's wrong, I'm in no sense a TCP guru and would like
some feedback.
 
Just disabling Nagle for the connection is not always the correct
solution to this:  if the application sometimes sends a burst of
short transmissions and sometimes sends a largeish lump, you still
want Nagle but don't want the extra round-trip delay on the lump.
 
I guess there are two ways to approach the argument, and my lack of
experience with RFC's is showing:  should this kind of potential
ambiguity -- which can't actually break anything no matter how it's
interpreted -- be left in official standards like Nagle, with "worse"
and "better" left as a subjective call?
 
Thanks in advance for your opinions and pointers,
Jim Hill
 
--
jthill@us.oracle.com

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Apr 1993 01:00:53 GMT
From:      larry@palan.uucp (Larry Strickland)
To:        comp.protocols.tcp-ip,comp.unix.sys5.r4,comp.sys.m88k,comp.sys.workstations
Subject:   HELP:  Aviion and bootp

My school has just purchased a DG Aviion 4300 to use as a UNIX machine running
UniDATA and a package called ACISS.  Some 70 different computers (40 PCs and
30 Macs roughly) will be connecting (no more than 32 at a time) to the DG
system.

We are currently using NCSA Telnet on both the Macs and PCs for communication.
However, that means more than 70 _different_ configuration files that must
be maintained.

Life would be much easier if I could use bootp or RARP to get the IP address
given the ethernet address.  Unfortunately, bootp is not supported by DG and
I can't seem to get RARP to work (actually, it seems to me both should work
since a 4300 can be used as a diskless workstation).

Anyway, I downloaded a copy of bootp from the internet and compiled it with
only minimal trouble.  The problem _seems_ to be a missing definition,
namely, SIOCSARP.

I tried leaving out the ioctl, using SIOCSARPCLIENT and other variations
in the if.h file, but NOTHING seemed to work.

Has anyone gotten bootp or RARP working on a 4300 under 5.4.2.01?  Do you
have any idea of how to get this to work?  I'd really appreciate some help
on this one.

Thanks,
-larry

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 93 06:17:46 GMT
From:      martind@nsg.nsg.com.au ( NSA)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   ibm, dec, tandem connectivity

I have the scenario of a customer with a 3090 or two, then a number of DEC
hosts, and likewise a number of Tandem hosts running their own (Guardian OS)
operating system.

The requirment is to have the capability of backing up large amounts of DEC and
Tandem data to the hosts via a LAN. Talking about 200MB plus per day. Some of the
data will go to tape whilst other data wants to stay on the 3090 until its
operators decide to archive the data.

I'm looking for a solution to link these disparate environments and provide the
capability to do volumes of FTP (file transfer).

Thanks..

-- 
Martin P Drenovac             PHONE: (612) 415-0500
                              FAX:   (612) 417-8635
			      EMAIL: martind@nsg.oz.au
Network Solutions             UUNET: !uunet!munnari!nsg.oz.au!martind

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Apr 1993 06:56:46 GMT
From:      J.P.M.vOorschot@et.tudelft.nl (Jan van Oorschot)
To:        comp.protocols.snmp,comp.protocols.tcp-ip
Subject:   Re: Sources for SNMP Software?

benoisme@agedwards.com (Mike Benoist) writes:

>I am a new user to the Internet and would like information on SNMP.
>Specifically, sources for software such as Remote Agents, RMON software
>for servers, and TRAP's and/or TRAP generation software.

	have a look at our RMON monitor for OS/2 (we're now
	porting to UNIX) BTNG  and our SNMP utilities kit for 
	OS/2 and UNIX Tricklet. Both BTNG (Beholder, The Next Generation)
	and Tricklet come with full source code.
	
	dnpap.et.tudelft.nl:/pub/btng/btng3src.zip	->BTNG source 
	dnpap.et.tudelft.nl:/pub/btng/btng3exe.zip	->BTNG execs
	dnpap.et.tudelft.nl:/pub/btng/tricklet.3.1.tar.Z->Tricklet source 
	 

Jan
-- 
-- Ir. Jan van Oorschot.          --- Email: J.P.M.vOorschot@et.tudelft.nl --
-- Data Network Performance Analysis Project                               --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --
--
-- Ir. Jan van Oorschot.          --- Email: J.P.M.vOorschot@et.tudelft.nl --
-- Data Network Performance Analysis Project                               --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Apr 1993 16:27:45 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Compiling "Unix Network Programming" progs on a Sun

> Has anyone got the programs from Richard Steven's book "UNIX Network
> Programming" book to compile under Sun OS 4.1.1?  Some of the include files
> are missing. I've tried compiling the programs in the lib subdirectory with
> BSD defined, but I get the following when compiling idpopen.c
>
> gcc -O  -target sun4 -c  -DBSD idpopen.c
> idpopen.c:8: netns/ns.h: No such file or directory

The problem is that most systems today don't come with the XNS protocols.
Take a look at the following lines from the README file that comes with
the sources:

+         Be aware of the warning on page 261 of the text: some vendors of
+ 4.3BSD-based systems do not include the Xerox NS protocols.  I believe
+ Sun and Apollo are examples.  For these 4.3-like systems you should
+ change the line
+ 
+         BSD_OBJ    = idpopen.o sppopen.o sigchild.o
+ 
+ in the file lib/Makefile to be
+ 
+         BSD_OBJ    = sigchild.o
+ 
+ This prevents make from trying to compile the XNS-related files.

> So, I thought I would try compiling as a Sys V system using the programs in
> lib.s5.  This time, rresvport.c couldn't find sys/inet.h.

My guess is that the reason rresvport.c includes <sys/inet.h> is because
that's where it was on the old Wollongong software that was used for the
book.  Try changing that to <arpa/inet.h> and see what happens.

	Rich Stevens  (rstevens@noao.edu)

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Apr 1993 17:25:00 GMT
From:      jdt@voodoo.ca.boeing.com (Jim Tomlinson (jimt II))
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Interop info?



Where would I write/who would I call to get information about the
next Interop?  Thanks in advance.
-- 
Jim Tomlinson                         (206)865-6578  \  "falling snow
BoGART Project                 jdt@voodoo.boeing.com  \  excellent snow"
Boeing Computer Services   ...uunet!bcstec!voodoo!jdt  \  - Anderson/Gabriel

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 93 18:56:40 GMT
From:      jthill@oracle.us.com (Jim Hill)
To:        comp.protocols.tcp-ip
Subject:   Nagle again

I got a pointer to RFC1122 in email, which doesn't change my reading
any.  4.2.3.4 says "if there is unacknowledged data, then the sending
TCP buffers all user data..." which I read as implying "if there is no
unacknowledged data, the Nagle algorithm has nothing to say on the
subject" -- and in this case the TCP should respect PSH according to
step 2.
 
RFC896 says apply the test "when new outgoing data arrives from the
user", and if anything RFC1122 just reinforces the interpretation by
referring to "all queued data".  If 4.2.3.4 said "send segments while"
not "send data if" I'd read it differently.  Also true of many other
possible wordings, but not the actual wording.
 
I know this is a marginal case, but if other people are consistently
getting a different interpretation, I need to fix my parser...
 
Thanks,
Jim
--
Jim Hill
jthill@us.oracle.com

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Apr 1993 19:59:02 GMT
From:      evan@gandalf.ca (Evan Caves)
To:        comp.protocols.tcp-ip
Subject:   tcp keepalive

   Can someone tell me how to implement a session keepalive
probe on TCP. I have not been able to find any definitive
answers for this functionality. If an RFC describes a 
implementation then which one. I am new to this group so
if this question has been asked before then perhaps you
can tell me where the FAQ is.

Evan Caves
Gandalf Data Ltd.
evan@gandalf.ca
-- 
Evan Caves      Junior Designer

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Apr 1993 22:04:56 GMT
From:      garrod@smaug.enet.dec.com (Dave Garrod)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: ibm, dec, tandem connectivity

Re:

> 
>The requirment is to have the capability of backing up large amounts of DEC and
>Tandem data to the hosts via a LAN. Talking about 200MB plus per day. Some of the
>data will go to tape whilst other data wants to stay on the 3090 until its
>operators decide to archive the data.
> 
>I'm looking for a solution to link these disparate environments and provide the
>capability to do volumes of FTP (file transfer).
> 

Digital Equipment Corporation sells a product called

DECnet/SNA Data Transfer Facility

that works through a DECnet/SNA Gateway. This is a file transfer product
to transfer files between DEC and IBM systems. It would handle your 200MB in
less than 15 minutes. If you require further information on this product please
contact your local Digital office or send me an EMAIL.

Dave

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 1993 07:41:57 -0400
From:      jbasara@ssdc.SSDC.Sterling.COM (Jim Basara)
To:        comp.protocols.tcp-ip
Subject:   looking for code for FTP


Are any FTP server(s)/client(s) available in the public domain. Preferably
written in C.
--
-------------------------------------------------------------------------------
Jim Basara
     uunet!ssdc!jbasara                "All the other nations are drinking
     jbasara%ssdc@uunet.uu.net         Ray Charles beer, and we are drinking
                                       Barry Manilow." - Dave Barry

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Apr 1993 02:08:53 GMT
From:      sgccmtm@citec.oz.au (Michael McKeon)
To:        comp.protocols.tcp-ip
Subject:   REMOTE PRINTING USES 4K NULLS TRAILER

Hi,
	I'm an amateur with TCP/IP communications,
	And I was hoping that someone could point me in the right direction.

Pre-Amble
	We use (3-COM BRIDGE) terminal servers to allow printing from multiple
	unix machines, each printer is assigned a port on a terminal server
	and this port is assigned an I.P. address.

	In our ~lp/interface/printername script we use a locally compiled
	programme called tcpsend (similar to telnet) that makes a connection
	to the I.P. address/port and sends the data to the particular printer.
	
My problem in a nutshell is.

	To ensure that print jobs are printed completed we need to append
	4096 Nulls to the data sent VIA tcp/ip. Unfortunately there is
	a delay between successive print jobs.

	IS THERE ANY WAY THAT TCP/IP WILL ALLOW THE FULL TRANSMISSION OF
	DATA TO THE TERMINAL SERVER WITH-OUT THE USE OF PADDING WITH 4096
	NULLS.


-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Apr 1993 02:47:52 GMT
From:      isc20274@nusunix1.nus.sg (FOO SEK KUM)
To:        comp.protocols.tcp-ip
Subject:   Looking for TCP-IP software.

[ Article crossposted from comp.protocols.tcp-ip.ibmpc ]
[ Author was  ]
[ Posted on Fri, 16 Apr 1993 02:30:13 GMT ]


I am currently looking for the program listing of TCP-IP
I seem to find only the executable files but
not the programs complete.
Could anyone please inform me of the ftp site to the programs?
Thank you very much.

I would really appreciate any replies.
current email address : skfoo@iss.nus.sg
--
===============================================================================
           Terence Foo            <>  Man Proposes, God Disposes    
  Department of Computer Science  <>           TeReNZo!         
 email : isc20274@nusunix1.nus.sg <>                   BOY! LiFe SuRe iS GOOD!

--
===============================================================================
           Terence Foo            <>  Man Proposes, God Disposes    
  Department of Computer Science  <>           TeReNZo!         
 email : isc20274@nusunix1.nus.sg <>                   BOY! LiFe SuRe iS GOOD!

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Apr 1993 13:14:40 -0400
From:      Lyle_Seaman@transarc.com
To:        comp.protocols.tcp-ip
Subject:   Re: How Contact Phil Karn ??

[3.3] whois -h rs.internic.net karn
Karn, Phil (PK28)               KARN@QUALCOMM.COM
   Qualcomm, Inc
   10555 Sorrento Valley Rd
   San Diego, CA 92121
   619-597-5501

   Record last updated on 13-Nov-92.

The InterNIC Registration Services Host ONLY contains Internet Information
(Networks, ASN's, Domains, and POC's).
Please use the whois server at nic.ddn.mil for MILNET Information.
[3.3] 

--
Lyle		Transarc		707 Grant Street
412 338 4474	The Gulf Tower		Pittsburgh 15219






-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 93 08:31:18 GMT
From:      marmary@kaa.informatik.rwth-aachen.de (Mahmoud-Reza Nazeman)
To:        comp.protocols.tcp-ip
Subject:   RTO Calculation (decimal)?

In "Comer, Stevens: INTERNETWORKING with TCP/IP, Volume II, Chapter 14" I have
found the following in the comment line of the rto-implementation:

	delta = rtt - srtt
	srtt  = srtt + delta / 8
	rtde  = rtde + (|delta| - rtde) / 4

	rto   = 2 * (srtt + rtde)

I was a little bit confused because of the left and right shifts with the dual
numbers in the implementation and the specifications (jacobsen's paper 88).
So my question is, wether this is the right way to calculate the rto with decimals?

Thanks in advance
-marmary.brand,informatik.rwth-aachen.de


-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Apr 1993 13:04:29 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: tcp keepalive

>   Can someone tell me how to implement a session keepalive
>   probe on TCP. I have not been able to find any definitive
>   answers for this functionality.

The trick is to send a garbage byte just with a sequence number just below
the left edge of the window.  This segment will cause an ACK from the
receiver (the ACK is because a segment to the left of the window suggests
that an ACK was lost, so the receiver transmits a new one).  The ACK indicates
the remote peer is still there.  This is barfulous and non-standard but widely
done.
 
In terms of a FAQ for the list, the closest thing to a FAQ for protocol
related questions is RFCs 1122 and 1123 (Host Requirements) which discuss
all the knotty issues (and their resolutions) for TCP/IP implementations on
hosts.  A companion document, known as Router Requirements (discussing knotty
issues for routers) is due out soon.
 
Craig Partridge
craig@bbn.com

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Apr 1993 14:09:58 GMT
From:      dan@igate.c-mols.siu.edu (Dan Ellison)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: RIP problem

In <1qhhtqINNhen@cronkite.cisco.com> tli@cisco.com (Tony Li) writes:

>In article <1993Apr14.141024.933@sobeco.com> stacy@sobeco.com (Stacy L.
>Millions) writes: 
 
>    The cisco implementation of RIP doesn't implement host routes and does not
>    ignore them like RFC1058 says it should if it is not going to implement
>    them.

This has certainly been a problem for me as well.  I managed to get around
it by going to gated for routing.  Not as reliable I don't think but it
does work B^)

>Version 9.1 supports host routes.  I suggest you upgrade.

And I suggest that you hold onto your hat when you get the upgrade price!
Even though this is admittedly a bug, Cisco will not upgrade you for free.
I'm not a cisco blaster.  IN fact I administer 14 AGS+'s on our fddi
backbone.  They make one *GOOD* product.  I think they should change
some of ther upgrade policies though.

[alternate configuration deleted]
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Dan Ellison, Network Spec 	  -    	Computing Affairs, SIU-C 	| 
| Southern Illinois University 	  - 	Carbondale, IL 62901            |   
| FAX:      (618) 453-3459        -   	PHONE:    (618) 453-6149 	|     

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 93 14:26:12 GMT
From:      gregm@cbmvax.cbm.commodore.com (Greg Miller - Amiga Networking)
To:        comp.protocols.tcp-ip
Subject:   Telnet Window Size Option

Is anyone aware of a telnet server implementation that supports
telnet option 31 -- the Window Size Option?  I've just done an 
implementation of that option, but found (much to my dismay) that
none of the more likely server candidates that I checked supported
that option.  Unless I can test the darned thing, I'm afraid that I'm
going to have to comment out that entire chunk of code -- which I'd really 
prefer not to have to do.

 Thanks!

 - Greg

-- 
Greg Miller                         "The only difference between a
Amiga Networking Group               madman and myself is that I am not
gregm@cbmvax.commodore.com           mad!" -- Salvador Dali

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Apr 1993 14:32:24 GMT
From:      cleelacj@agedwards.com (Chris Cleeland)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   Experience with two LAN cards (SUMMARY)

Thanks to all who responded!  The overwhelming advice was "use
netmasking"!  And, as I e-mailed to one of the responders,
"If I had taken a bit more time to dig in my Tannenbaum book,
I think I would have come to that realization myself.  It's
a good thing the Net is a little forgiving sometimes (at least
in some groups :-)"

Once again, thanks all!  If anybody has suggestions other than
netmasking, I'd be interested in hearing them still.  But that
certainly looks liek the way to "do it right".

-cj

-- 
==============================================================================
Chris Cleeland 	       	       	|  Internet:   cleelacj@agedwards.com
BOS Dev. Team                   |  USnail:     3878 Connecticut St. Louis 63116
                                |  BellNet:    (314) 289-5372

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 93 15:41:07 GMT
From:      pwilson@world.std.com (Pete Wilson)
To:        comp.protocols.tcp-ip
Subject:   How Contact Phil Karn ??

Subject says all. Customer of ours wants to license KA9Q.
--
Thanks, Pete Wilson (pwilson@world.std.com)
Paul Freeman Associates: Makers of the Universal SNMP Agent

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Apr 1993 15:43:30 GMT
From:      bradley@mdd.comm.mot.com (Michael Bradley)
To:        comp.protocols.tcp-ip
Subject:   Header Prediction


I would appreciate a description of the TCP optimization
"header prediction" that is apparently part of the 4.3BSD
Reno implementation.

 Thanks
  Michael Bradley


-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 93 16:04:56 GMT
From:      rohit@SynOptics.COM (Rohit Aggarwal)
To:        comp.protocols.tcp-ip
Cc:        rohit
Subject:   socket interface/multiple interfaces


On a system that has  multiple network interfaces, le0 and tr0.

From the socket level, is there a way to control over which interface 
the packet will be sent out on? 

From the socket level I would like set over which interface the packet
will be sent out on.

thanks in advance
Rohit

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Apr 1993 17:30:44 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Header Prediction

In article <1993Apr16.154330.1408@mdd.comm.mot.com>, bradley@mdd.comm.mot.com (Michael Bradley) writes:
> 
> I would appreciate a description of the TCP optimization
> "header prediction" that is apparently part of the 4.3BSD
> Reno implementation.


The best, most accurate, most complete, most easily understood
description is the code itself.  It is only a few lines.


Look for the source on uunet.

Or get the free 386bsd source and run it on a 386 or 486 PC clone.

Or buy the much more robust and complete, $995 for full source and
binaries on CDROM, BSD/386 from BSDI.


Vernon Schryver,  vjs@sgi.com

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Apr 1993 17:47:21 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: RTO Calculation (decimal)?

> marmary@kaa.informatik.rwth-aachen.de (Mahmoud-Reza Nazeman) writes:
>In "Comer, Stevens: INTERNETWORKING with TCP/IP, Volume II, Chapter 14" I have
>found the following in the comment line of the rto-implementation:
>
>	delta = rtt - srtt
>	srtt  = srtt + delta / 8
>	rtde  = rtde + (|delta| - rtde) / 4
>
>	rto   = 2 * (srtt + rtde)
>
>I was a little bit confused because of the left and right shifts with the dual
>numbers in the implementation and the specifications (jacobsen's paper 88).
>So my question is, wether this is the right way to calculate the rto with decimals?

Several popular writeups (I believe Comer and Stevens) use floating 
point math, but this algorithm is suitable (and intended) for integer
arithmetic.  It's been a while, but I believe Van's paper alludes to
how he chose the operations to make them very compact for integer
arithmetic.

If you introduce floating point into the TCP system, you will eventually
loose out on performance.  And IMHO you don't gain anything, the formulae
produce similar values whether done with floats or ints.  

And you should remember that the rto value calculated is never
an exact value.  It is based on an assumed round-trip time which is based
on history and some stats knowledge.  And that history is based on the system
clock (rarely very precise) and the assumption that the packet will take
a similar route and thus exhibit the same round-trip performance.  So
this is like a sure thing at a race track... the estimate can only be
so good and floating point doesn't enhance it.

Erick
-- 
Networking is the concept of having data, finding it somewhere else and 
thinking that it's a good thing.  A distributed environment just means 
you are less picky about where it ends up before calling the whole 
process a success.  Plumbers call it a leak.

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Apr 1993 18:02:21 GMT
From:      bmiller@cabell.vcu.edu (Bryan E. Miller)
To:        comp.protocols.tcp-ip
Subject:   Sniffer


Fellow netters,

Has anyone written any code to analyze Sniffer data files?

Bryan

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Apr 93 18:06:08 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: ibm, dec, tandem connectivity

Get TCP/IP for the lot of them.

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

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Apr 1993 19:31:18 GMT
From:      mkrause@mitre.org (Mark Krause)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: Interop info?

> Where would I write/who would I call to get information about the
> next Interop?

Call 1-800-INTEROP

-- 
Mark A. Krause			mkrause@mitre.org
The MITRE Corporation		Mail Stop W273
7525 Colshire Drive		(703)883-7642 (Voice)		
McLean, VA 22102		(703)883-6478 (Fax)

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Apr 1993 19:31:34 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Header Prediction

> I would appreciate a description of the TCP optimization
> "header prediction" that is apparently part of the 4.3BSD
> Reno implementation.

As has been pointed out, look at the source.  Specifically you want
the file netinet/tcp_input.c.  Here's the comments from the code.

	/*
         * Header prediction: check for the two common cases
         * of a uni-directional data xfer.  If the packet has
         * no control flags, is in-sequence, the window didn't
         * change and we're not retransmitting, it's a
         * candidate.  If the length is zero and the ack moved
         * forward, we're the sender side of the xfer.  Just
         * free the data acked & wake any higher level process
         * that was blocked waiting for space.  If the length
         * is non-zero and the ack didn't move, we're the
         * receiver side.  If we're getting packets in-order
         * (the reassembly queue is empty), add the data to
         * the socket buffer and note that we need a delayed ack.
         */

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Apr 1993 19:48:09 GMT
From:      swamik@orca.NoSubdomain.NoDomain (Swami Kumaresan)
To:        comp.protocols.tcp-ip
Subject:   KA9Q NOS socket() and unix's socket()

Hi!

        I have the C source code for KA9Q NOS Hamradio network software (Unix
Port). NOS redefines functions such as socket(), bind(), etc for radio
connections. I want to modify nos by adding the capability to open sockets
 on internet. But when I call socket, naturally the compiler uses NOSs socket
call. Is there anyway to tell the compiler to ignore NOSs socket, bind etc
and call unixs functions. I don't want to change the name of every occurence (SP?)
of socket(), etc because it is used 100s of times in the source code!

Thanx in advance.

Swami Kumaresan KB1AMB

replies to:    swamik@orca.ele.uri.edu



-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Apr 1993 20:41:26 GMT
From:      dwight@rock.concert.net (Dwight Frye -- Systems Development Group)
To:        comp.protocols.tcp-ip
Subject:   Outbound connections on terminal server

I have been asked to find out how a process can make outbound
connections via a Xyplex terminal server. The system will be
running on a SparcStation 10 under SunOS 4.1.3. The Xyplex works
fine for making inbound terminal connections to the system (ie.
logging in) but they need to initiate connections in the other
direction.

The idea situation would be to have device files which would 
correspond to specific tty ports on the Xyplex. 

Can anyone pass on some pointers? Thanks.

--
Dwight Frye	dwight@rock.concert.net

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 93 20:52:12 GMT
From:      peter@ferranti.com (peter da silva)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <1q54kv$ole@usenet.INS.CWRU.Edu> trier@odin.ins.cwru.edu (Stephen C. Trier) writes:
> RFC 1122 says 127.*.*.* is never to go out on a LAN.  3.2.1.3(g) says about
> these address, "Internal loopback address.  Addresses of this form MUST NOT
> appear outside a host."

How about using Net 10 for internal networks? It's highly unlikely anyone
in the Real World is going to be using it any time soon.
-- 
Peter da Silva                                            `-_-'
Network Management Technology Incorporated                 'U` 
12808 West Airport Blvd.  Sugar Land, TX  77478  USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Apr 1993 21:27:03 GMT
From:      oleg@watson.ibm.com (Oleg Vishnepolsky)
To:        comp.protocols.tcp-ip
Subject:   BSD bug ?

I seem to have come across what looks like a bug in mechanism of binding 
to the same local port.

The problem manifests itself as follows.
In establishing FTP data connection, FTP server is supposed to bind to port
20 and then do a connect to a port supplied by a client. So far so good.
One can bind to the same local port (20 in this case) more than once, provided
a) SO_REUSEADDR is used b) the previous bind was followed
by a connect thus completing the connection tuple. Now comes the problem.
If you have more than one instance of the server, there is a short timing
window where the second bind can fail with EADDRINUSE because the
connect that followed the first bind has not been issued yet. That can happen
if the first instance of the server issues a bind to port 20 but before it
has a chance to issue a connect, it loses CPU (dispatcher dispatches
second instance of the server which does a bind to port 20 again - boom,
it fails). The fix seems  rather easy - in in_pcb.c,
in in_pcbbind, not to return EADDRINUSE if a socket does not 
accept connections and is a stream socket:

   if ((so->so_options & SO_REUSEADDR) == 0 &&
      ((so->so_proto->pr_flags & PR_CONNREQUIRED) == 0 ||
           (so->so_options & SO_ACCEPTCONN) == 0))
              wild = INPLOOKUP_WILDCARD;
      if (in_pcblookup(head,
          zeroin_addr, 0, sin->sin_addr, lport, wild))
           if ((so->so_options & SO_ACCEPTCONN)||(so->so_type!=SOCK_STREAM))
              return (EADDRINUSE);

It takes a really stressful environment to reproduce the problem.
Any opinions would be greatly appreciated.

Oleg Vishnepolsky



-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Sat, 17 Apr 1993 18:03:35 GMT
From:      adelman@tgv.com (Kenneth Adelman)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet Window Size Option

In article <C5Kyrq.H4G@cbmvax.cbm.commodore.com>, gregm@cbmvax.UUCP (Greg Miller - Amiga Networking) writes...
>Is anyone aware of a telnet server implementation that supports
>telnet option 31 -- the Window Size Option?  I've just done an
>implementation of that option, but found (much to my dismay) that
>none of the more likely server candidates that I checked supported
>that option.  Unless I can test the darned thing, I'm afraid that I'm
>going to have to comment out that entire chunk of code -- which I'd really
>prefer not to have to do.

    We support it in MultiNet. Contact me offline Monday and I'll
arrange for you to get a login you can test against.

							    Ken

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 1993 16:41:52 GMT
From:      papowell@dickory.sdsu.edu (Patrick Powell)
To:        comp.dcom.lans,comp.protocols.snmp,comp.protocols.tcp-ip
Subject:   Re: Low Cost MultiPort Thinnet Repeater with SNMP?

Ken Mandelberg (km@mathcs.emory.edu) wrote:
: Does anyone know of a low cost multiport thin ethernet repeater that
: can be monitored with snmp?
 
: Failing that, recommendations for low cost units with good monitoring
: lights would be appreciated.

I have evaluated several 'inexpensive' hubs for various reasons.
I can recommend the following:

Xinetron Etherhub 12-i with  X-Hub Management.
 - 12 port hub = $200, can put up to 15 on a SNMP agen box
 - SNMP agent box - $400
    i.e.- $600 for 12 ports, $800 for 24 ports, etc.
 These are University prices.

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



--

papowell@sdsu.edu
Prof. Patrick Powell, Dept.  Electrical and Computer Engineering,
Engineering 403G, San Diego State University, San Diego, CA 92182-0190
Office (619) 594-7796; Lab (619) 594-2434 FAX (619) 594-3703

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Apr 1993 03:24:02 GMT
From:      hmchen@fcom.ee.ntu.edu.tw (Hung-ming Chen)
To:        comp.protocols.tcp-ip
Subject:   Two Ethernet Connection Programming Problems

I am writing communication programs with socket package. My
network configuration is depicted as follow:

-----------------------------------------------------
   |         |        |        |       |        ^
 -------    -----   ------   ------- -------     |
| H1  |    | H2|   | CC |   | W1  | | W2  |   Ethernet
 -------    -----   ------   ------- -------     |
   |         |        |                         v
-----------------------------------------------------

There are two Ethernets that are implemented for realiance. The 
three computers, H1, H2 and CC, have two Ethernet cards. For
every card I will build a connection with the other computers
on the networks.  And I want to handle the two connections by 
two processes, one for send data, and the other to receive data. 
Thus, for H1, H2 and CC, every process must control two ethernet 
cards. For the send part it is easy to solve, bur for the received
part, I first call socket() function to get a socket fd, and
then how many times the bind() function I should call. If two
times, the socket address how to assign. The answer had better
a general solution that I needn't change any code for the
three computers. I prefer any example. If no, the concept is O.K.

Thanks in advance.

Fred Chen 4/19/93'
email:hmchen@fcom.ee.ntu.edu.tw
r 
  

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Apr 1993 09:53:11
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Nagle again

In article <16BB1A7F9.JTHILL@oracle.us.com> jthill@oracle.us.com (Jim Hill) writes:

    I got a pointer to RFC1122 in email, which doesn't change my reading
    any.  4.2.3.4 says "if there is unacknowledged data, then the sending
    TCP buffers all user data..." which I read as implying "if there is no
    unacknowledged data, the Nagle algorithm has nothing to say on the
    subject" -- and in this case the TCP should respect PSH according to
    step 2.
     
    RFC896 says apply the test "when new outgoing data arrives from the
    user", and if anything RFC1122 just reinforces the interpretation by
    referring to "all queued data".  If 4.2.3.4 said "send segments while"
    not "send data if" I'd read it differently.  Also true of many other
    possible wordings, but not the actual wording.
     
    I know this is a marginal case, but if other people are consistently
    getting a different interpretation, I need to fix my parser...

I've always interpreted Nagle as meaning that a send(MSS+1 bytes) with
no unacknowlged data in the pipe will generate the following traffic:

	SEG1(MSS bytes)	->
			<-	ACK1
	SEG2(1 byte)	->
			<-	ACK2

Yes, this causes ~1 RTT extra delay over just sending SEG1 and SEG2,
but the point of Nagle is the overall reduction in traffic on
full-duplex connections.  If your application is designed as half-duplex,
you should also be desigining it around optimal segment size and Nagle
override calls.

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488


-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Apr 93 09:21:49 GMT
From:      volkert@kub.nl (Volkert)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   PROBLEM: installing PC/IP drives me crazy

---------------------------------------------------------------------------
Netters!

I've put more than three days of frustrating trial-and-error effort in this
and now I'm desperatly. Please help me directly or point me to some sources
of *good* information.

I'm sure that the problem I'm having with TCP/IP is very basic. I'm trying
to use the PC/IP package with the Crynwr package drivers.
I installed the NETDEV.SYS as mentioned below, and load the WD8003E.COM
afterwards. If that's all to do: when i want to use utils like pping, then
i receive error messages from the driver. As mentioned in the transcript.
The WD8003E card is configured as mentioned in the NETDEV.SYS. And the device
loads nicely.

The other TCP/IP machine is an OS/2 2.0 running TCP/IP 1.2. All deamons
have been started and any ftp/telnet session from-to that machine works
perfectly (machine is both server and client).

Doing FTP and telnet sessions is not my goal: i want to be able to mount
filesystems on the mentioned OS/2 machine as well on many other machines.
Please point me to good sources of information to achieve that goal, using
PC/IP as a basis. In fact: any implementation that is based on TCP/IP will
do as long as it's cost-effective, so perhaps someone from FTP can make me
an offer?

regards, JV
                                                                /////
name:    J-V Meuldijk                                          [ o o ]
address: gildelaar 4                                            \_=_/
         4847 hw teteringen       fax:     +3176-600220         _| |_ 
         holland                  e-mail:  volkert@kub.nl      / \_/ \
_____________________________________________________________oOOO___OOOo__


NETDEV.SYS

CSR base I/O address 0x0280
Interrupt vector 3
Transmit DMA channel 0
Receive DMA channel 0
Base memory is D400,0
1 net interface
My Internet Address 12.216.37.27
Log Server 192.128.153.7
Default Gateway 192.128.153.7
Print Server 192.128.153.7
Domain: xxx.yy
subnet mask is 255.255.0.0
time zone GMT
user's name JOY
debug dump info neterrs proterrs timeout nettrace IPtrace TPtrace APtrace


TRANSCRIPT OF PPING @192.128.153.7

found bad pkt buffer
Initializing Tasking
IP: setting handler for protocol 17
UDP: Opened InterNet connection.
IP: setting handler for protocol 1
ICMP: Opened ip conn
IP: setting handler for protocol 3
GGP: opened ip con
udp_open: host 192.128.153.7, lsock 1202, fsock 42, foo 0000
udp_open: host 192.128.153.7, lsock 1203, fsock 53, foo 0000
UDP: pkt [32] 04B3 -> 192.128.153.7:0035
in_write: pkt[40] prot 17 to 192.128.153.7, route 192.128.153.7
ncb rcv failed 132
netclose() called
pc_close: cancel failed 38


-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Apr 93 17:41:45 CST
From:      EM306965@itesmvf1.rzs.itesm.mx (Gustavo Cavazos)
To:        comp.protocols.tcp-ip
Subject:   IRC... rfc, is there one?

Is there any RFC for tha IRC...? What protocol does it uses?
 
+Gus

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Apr 1993 11:42:25 GMT
From:      jel@tuura.icl.fi (Jerry Lahti)
To:        comp.protocols.tcp-ip
Subject:   Re: REMOTE PRINTING USES 4K NULLS TRAILER

sgccmtm@citec.oz.au (Michael McKeon) writes:

>Pre-Amble
>	We use (3-COM BRIDGE) terminal servers to allow printing from multiple
>	unix machines, each printer is assigned a port on a terminal server
 
>	IS THERE ANY WAY THAT TCP/IP WILL ALLOW THE FULL TRANSMISSION OF
>	DATA TO THE TERMINAL SERVER WITH-OUT THE USE OF PADDING WITH 4096
>	NULLS.

Not really.  As far as I know, the need for padding is caused by
a 'feature' in the 3COM boxes: apparently they tend to discard at least
part of the buffered data immediately when the network connection
closes, instead of waiting for it to drain out of the serial port.
Since TCP connections are supposed to be reliable, 'tcpsend' cannot
do much else than send enough padding so that the real data has time
to make it out of the serial port.  However, 3COM might have new
software/firmware versions which eliminate this 'feature'.
-- 
Jerry Lahti             !  tel. +358-0-567 3639
ICL Personal Systems Oy !  fax. +358-0-567 5670
P.O.Box 780             !  Email: jel@xerver.icl.fi (Internet) 
00101 Helsinki, Finland !  X400:  C=FI A=MAILNET P=ICL O=ICL S=LAHTI G=JERRY

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 1993 14:41:53 GMT
From:      Martin W Freiss <freiss.pad@sni.de>
To:        comp.protocols.tcp-ip
Subject:   Routing: books, literature wanted

Hi,

this is not really about TCP/IP, but about routing in general. I just figure
that this group has the readership I'm looking for :-)
I'm looking for some literature about routing. I've read most of the
RFCs about BGP/EGP/RIP/OSPF, hope that I've understood most of what I
read, but have the nagging feeling that I miss some basic theory.
I'd be grateful for tips on what to read and where to look for
(electronically available?) information on the topics

- link state vs distance vector algorithms
- the mathematics involved in "best path discovery" and propagating
  topology changes 


Thanks in advance,

-Martin

--
 Martin Freiss               | R&D computer center | freiss.pad@sni.de 
 Siemens Nixdorf Infosystems | Dept. MR STO SI 325 | NIC MF194
"In this town, I am the leper with the most fingers." - The Two Jakes


-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Apr 1993 15:48:05 GMT
From:      RayTai@vmdean.ucdavis.edu (Raymond Y. Tai)
To:        comp.protocols.tcp-ip
Subject:   Test

This is a test only...

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Apr 1993 00:06:19 -0400
From:      Kevin Richard O'Toole <ko0m+@andrew.cmu.edu>
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: Ethernet monitoring software wanted.

>I am looking for software that will enable us to monitor network
>traffic from the ethernet level up to TCP/IP.  This software can run
>on either Motorola 88K UNIX R32V3 or on a PC.  PD or commericial.
 
>Thanks,
 
>- Carl -

LanWatch from FTP software is bare as far as ui is concerned, but very
effective as far as figuring out what is happening on your network.

Kevin R. O'Toole,
Information Networking Institute
Carnegie Mellon University


-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 93 06:35:56 -0600
From:      pearcedh@rcwusr.bp.com
To:        comp.unix.ultrix,comp.sys.hp,comp.sys.dec,comp.protocols.tcp-ip
Subject:   HELP: Changing to NIC Compliant Addresses

Hi Net Readers,

I am new to the net, so please forgive me if I do anything annoying!

I have posted this request to the following NewsGroups:
comp.sys.dec
comp.sys.hp
comp.unix.ultrix
comp.protocols.tcp-ip

If there are more appropriate NewsGroups please inform me.

Please can I have any help and advice to cover the following task. Thank you 
in advance for any help you are able to provide.

My company has been awarded NIC compliant addresses (Class B). We 
have non compliant network addresses currently and in June we are planning 
to change our addresses over to NIC compliant addresses. We are not just
changing the network address; we are changing the IP address for each node and
the network mask.

My problem is what order do I do things in and what other problems should I 
be aware off?

Are there any papers on doing this anywhere on Internet?


What do we have?

BIND primary & secondary servers
NIS (YP) master and slave servers that name resolve through BIND
Network Bridges & Routers
Terminal servers (dual protocol TCP/IP & LAT) approx 200-off
150-off Mac's
50+ PC's using variety of TCP/IP stacks
50 VAXes running VMS with a variety of TCP/IP stacks
150+ Unix boxes from a variety of vendors
15+ X-terminals from a variety of vendors


My helpers would like to be able to logon to as many of the desktop 
machines as possible make the changes and then reboot. However this 
means having 2 BIND services running concurrently. I do not think this will 
be a problem as the BIND servers will be on different networks, eg old net-
work 101.x.x.x and new network 168.x.x.x.

Thank you again for any help or information that is provided.
-- 
Huw Pearce			E-mail:pearceh@rcscl1.dnet.bp.com
BP Group Research & Engineering
Sunbury-on-Thames
Middlesex TW16 7LN
UK

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Apr 1993 22:52:56 GMT
From:      carl@plaza.ds.adp.com (Carl Ellis)
To:        comp.sources.wanted,comp.unix.questions,comp.protocols.tcp-ip
Subject:   Ethernet monitoring software wanted.

I am looking for software that will enable us to monitor network
traffic from the ethernet level up to TCP/IP.  This software can run
on either Motorola 88K UNIX R32V3 or on a PC.  PD or commericial.

Thanks,

- Carl -
-- 
----------------------------------------------------------------------
Carl Ellis                         VOICE 503.294.5219
Systems Network Administrator      INTERNET MAIL carl@plaza.ds.adp.com
ADP Dealer Services

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Apr 1993 03:36:39 GMT
From:      chris@cs.uwa.oz.au (chris mcdonald)
To:        comp.protocols.tcp-ip
Subject:   Network.vs.Host byte ordering

At least under StunOS just about all library routines such as
gethostbyname/addr, "provide" structures with IP addresses in
*network* byte order (e.g. (struct hostent).h_addr_list[0] ).

However, according to their manual, structures pointed by getnetent()
and friends has a (struct netent).n_net field which is
in *host/machine* byte order.

Admitedly, under SunOS (SPARC) there is no physical difference,
but why the difference?

_______________________________________________________________________________
Chris McDonald.            _--_|\
                          /      \
                          X_.--._/
                                v
Department of Computer Science,   AARNet: chris@budgie.cs.uwa.edu.au
University of Western Australia,  FTP:    bilby.cs.uwa.edu.au,  130.95.1.11
Crawley, Western Australia, 6009. SCUD:   (31.97 +/-10% S, 115.81 +/-10% E)
PHONE:       +61 9 380 2533       FAX:    +61 9 380 1089

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Apr 1993 05:05:01 GMT
From:      pflaum@world.std.com (Greg M Pflaum)
To:        comp.protocols.tcp-ip
Subject:   Re: Sniffer

> Has anyone written any code to analyze Sniffer data files?  

Network General (makers of the Sniffer) surely has.  Could you be more
specific about your needs/interest?

The Sniffer data file format is documented by Network General, and the
format is easy to parse.  It is also not too difficult to write
additonal protocol decoders which can be linked into the Sniffer
software, enabling you to analyze new protocols, your own protocols,
whatever.

There is a product which, though it doesn't do analysis, might be of
interest.  The Protocol Analyzer Trace Translator (PATT) by, I think,
Pine Mountain, is software which translates between several different
network capture file formats, including the Sniffer.  This program
should be standard equipment for any product support group which uses
a protocol analyzer, as you need not depend upon your customers having
the same equipment.  (How many times has a Sniffer been FedExed to a
customer site when a simple software capture utility would do the job?)

Just a satisfied customer.

Greg Pflaum

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Apr 1993 12:30:30 EDT
From:      Rick Thibeault, UMPI <RICK@MAINE.MAINE.EDU>
To:        comp.protocols.tcp-ip
Subject:   Telnet : Using Scipts

Can anyone email or postinformation about using scripts in Telnet?
I would like to set this up so that certain users won't have to
type in the login name of a public group we have.
IE:  So they don't have to type in the user name and save them
a step to learn.

Thanks for the help in advance.

Rick

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Apr 1993 14:06:00 GMT
From:      wells@dartmouth.edu (Suzanne M. Wells)
To:        comp.protocols.tcp-ip
Subject:   looking for popmail for windows

Does anyone know if there is a mail program for windows which is similar 
to POPMAIL for dos.   I am running dos 5 and windows 3.1 on a 486. Please 
reply via my e-mail address. I am also interested if there is a telnet /ftp 
software for windows. I have NCSA telnet but am unable to get it to work 
effiecently and consistently in windows.

cheers
susan wells
e-mail= suzanne.wells@dartmouth.edu

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Apr 1993 14:14:19 GMT
From:      rmorley@mis.mi04.zds.com (Ron Morley)
To:        comp.unix.ultrix,comp.sys.hp,comp.sys.dec,comp.protocols.tcp-ip
Subject:   Thanks for help

I posted a request for help regarding preventing user logons a couple of weeks
ago.  I would like to thank all of those who responded via e-mail and the net
to my request.

Ron Morley
Zenith Data Systems

Disclaimer: My opinions are my own...no one else wants them.
"The only two things a pirate'll     |"The least flexible component of any
 run for is money and public office" |system is the user" Lowell Jay Arthur
            - Yosemite Sam           |
"Never underestimate the power of human stupidity"  Lazarus Long

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Apr 1993 14:41:44 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   ICMP Destination Unreachable "unknown" codes?

(Ref: RFC 792 pages 4-5, and RFC 1122 section 3.2.2.1)

What is the intended meaning of the ICMP Destination Unreachable
"unknown" codes 6 and 7?

What's the semantic difference between a code 6 "destination network
unknown" and a code 0 "net unreachable"?  And between a code 7
"destination host unknown" and a code 1 "host unreachable"?  Is the
difference only (as hinted in 1122) that codes 0, 1, and 5 may be the
result of transient routing flaps, while 6 and 7 are perhaps
indications of more permanent conditions?
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221           +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Apr 1993 14:53:31 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Volumes 2 through 4 of draft-ietf-rreq-iprouters-04.txt?

The latest Router Requirements draft hints at the existence of Volumes
2 through 4.  Where might one find these tomes?

(Yes, I asked the editor, but I haven't heard anything back.)
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221           +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Apr 1993 15:18:58 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Traceroute Diagnostics


On a Sun Sparc, we routinely ping all of the root name servers for one
second each to see if the Internet connection is up.  If just one of them
answers, the connection is considered to be good.

	We have occasionally had an intermittent condition in which
no answer is gotten from any of the root servers and an alarm is triggered.
When this happens, we run a "traceroute" on the addresses to all the root
name servers.  What we find is that we can get through, but the delays
reach as much as two seconds for those packets that do actually get through.

	What is puzzling is that the entire process of pinging or
tracerouting to all 9 servers slows to a crawl and takes as long as 90 minutes
to complete.  I am wondering what is taking so long? The sluggish packet
returns seem to be only part of what is happening.  Is there a better way
to routinely test the health of the Internet connection?

Martin McCormick WB5AGZ   Stillwater, OK
O.S.U. Computer Center Data Communications Group

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 93 15:38:48 GMT
From:      dickson@escob1.UUCP (Dave Dickson)
To:        comp.protocols.tcp-ip,comp.unix.sys5.r4
Subject:   SVR4 As DNS Client Won't Work


I am trying to get DNS to work on my company's 486 running
SVR4.0.  This machine will not be running the named locally,
it will be in "client mode".  I want to use an existing
Domain Name Service, available on our local network.  I have
installed a "/etc/resolv.conf" file, and modified the
"/etc/netconfig" file per vendor instructions.

When I use nslookup, everything seems to work OK.  When
attempting to use telnet or ftp, or any other network
application that needs name resolution, it fails.  Following
are my "config" files and an example nslookup output, and
telnet failure.  Am I missing something?  ...  Any help
would be very appreciated!

The "Network User's and Administrator's Guide" also mentions
copying /usr/lib/libsockdns.so on top of /usr/lib/libsocket.so ....
no can do - we don't have a libsockdns.so library.

NETCONFIG FILE:#########################################################
#
#       The Network Configuration File.
#
# Each entry is of the form:
#
# network_id semantics flags protofamily protoname device nametoaddr_libs
#
ticlts tpi_clts v loopback - /dev/ticlts /usr/lib/straddr.so
ticots tpi_cots v loopback - /dev/ticots /usr/lib/straddr.so
ticotsord tpi_cots_ord v loopback - /dev/ticotsord /usr/lib/straddr.so
rawip tpi_raw - inet - /dev/rawip /usr/lib/tcpip.so,/usr/lib/resolv.so
tcp tpi_cots_ord v inet tcp /dev/tcp /usr/lib/tcpip.so,/usr/lib/resolv.so
udp tpi_clts v inet udp /dev/udp /usr/lib/tcpip.so,/usr/lib/resolv.so
icmp tpi_raw - inet icmp /dev/icmp /usr/lib/tcpip.so,/usr/lib/resolv.so
########################################################################

RESOLV.CONF FILE:#############################
nameserver 144.161.19.250
domain clmbmocc.oh.ameritech.com
##############################################

TELNET EXAMPLE:###############################
$ telnet ohmacs
ohmacs: unknown host
##############################################

NSLOOKUP EXAMPLE:#############################
$ nslookup ohmacs
Server:  aux-oh.clmbmocc.oh.ameritech.com
Address:  144.161.19.250

Name:    ohmacs.akrnmmoc.oh.ameritech.com
Address:  144.152.1.2
Aliases:  ohmacs.oh.ameritech.com
##############################################
-- 
David G. Dickson
Ohio Bell Telephone Co. (614-223-8134)
uunet!escob1!dickson

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 93 15:49:58 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP Destination Unreachable "unknown" codes?

In article <BOB.93Apr20104138@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes:
>(Ref: RFC 792 pages 4-5, and RFC 1122 section 3.2.2.1)
>
>What is the intended meaning of the ICMP Destination Unreachable
>"unknown" codes 6 and 7?
>
>What's the semantic difference between a code 6 "destination network
>unknown" and a code 0 "net unreachable"?  And between a code 7
>"destination host unknown" and a code 1 "host unreachable"?  Is the
>difference only (as hinted in 1122) that codes 0, 1, and 5 may be the
>result of transient routing flaps, while 6 and 7 are perhaps
>indications of more permanent conditions?

These ICMP error codes originated way back in the early days when IP nets were
built out of PSNs (aka IMPs).  The networking view was a lot simpler in those
days.  I believe that the "unknown" codes were intended for use if the node
had reason to believe that the network/host did not exist.  The "unreachable"
codes were intended if the node believed that the network/host existed, but
did not have a path to it.  With the PSNs, the host unknown would have been
doable if the IP address mapped into a PSN address for a host that did not
exist.  It would probably take a static route table to generate a network
unknown.

Art

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Apr 1993 15:57:52 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Re: Traceroute for MS-DOS Systems and Other Personal Computers


I want to thank everybody who answered my questions both on the news group
and via E-mail.  The suggestions were to either use Beame&Whitesides tcp/nfs
software or get one of the public versions of "traceroute"  from an FTP
site.  Since the price of the public software is more in line with what
a public institution can afford, we decided to give it a try.  Many thanks to
FLEBAN@marvin.ag.uidaho.edu for pointing out a good source.  He said,


>Try Trumpet's HOPCHECK (trace route) program. I found it at
>dorm.rutgers.edu (128.6.18.15) in a collection of Trumpet's utilities
>as /pub/msdos/trumpet/abi-version/tcp201.zip.

	We tried it and it worked.  

Martin McCormick WB5AGZ   Stillwater, OK
O.S.U. Computer Center Data Communications Group

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Apr 1993 16:14:16 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Re: Traceroute Diagnostics


After receiving a helpful suggestion, I see that I failed to give all the
facts about my test situation.  When pinging or tracerouting, I use the
IP numbers of the root name servers and not their names in order to avoide
introducing extra complexity into the test and making it harder to tell
what is broken.

Martin McCormick WB5AGZ   Stillwater, OK
O.S.U. Computer Center Data Communications Group

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Apr 1993 16:16:46 GMT
From:      lorna@iphasew.com (Lorna Politzer)
To:        comp.protocols.tcp-ip
Subject:   Page-flipping

What is page-flipping?  Can someone please elaborate?

Lorna

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      20 APR 93 22:26:54
From:      scott@vms.macc.wisc.edu
To:        comp.protocols.tcp-ip
Subject:   QvtNet and POP3

I'm sitting here tonight testing QvtNet 3.4 as posted at
ftp.cica.indiana.edu.  It was posted today 4-20-93.  So
far it appears to work fine (fixed telnet problem with tgv)

Includes: Telnet
          Ftp
          POP/SMTP mail
          News reader
          LPR
          FPT and RCP Servers

I'm running it with Windows for Workgroups with no problems so far.
The best package I've seen for for the price :)

Scott Bullington, Systems programmer
UW Soil & Plant Analysis Lab
scott@macc.wisc.edu

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Apr 93 16:45:09 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Printing via TCP/IP from MVS...

I've used LPR to send files down to a queue on a UNIX box which in turn shipped the
file off to a terminal server connected printer.

Charles.

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

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Apr 1993 16:45:10 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Network.vs.Host byte ordering

In article <chris.735276999@budgie> chris@cs.uwa.oz.au (chris mcdonald) writes:
>Admitedly, under SunOS (SPARC) there is no physical difference,
>but why the difference?

There are two different byte orderings that predominate the industry.
In order to achive machine independence, the bytes are shipped out in
a standard order.  This order may or may not be the same as your host.
To make it easier to splat stuff out over the network, the bsd
interface to sockets use network order for everything.

It doesn't matter much on Suns, but it does matter on things like
Vaxen and Intel boxes.

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

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Apr 1993 17:00:50 GMT
From:      rpratt@novell.com (Robert Pratt)
To:        comp.sources.wanted,comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: Ethernet monitoring software wanted.

In article <1993Apr19.225256.4810@plaza.ds.adp.com> carl@plaza.ds.adp.com (Carl Ellis) writes:
>I am looking for software that will enable us to monitor network
>traffic from the ethernet level up to TCP/IP.  This software can run
>on either Motorola 88K UNIX R32V3 or on a PC.  PD or commericial.
>Thanks,
>- Carl -
>Carl Ellis                         VOICE 503.294.5219

    Well, we (Novell, that is) make the LANalyzer for Windows, which is
a software based package for Ethernet and Token Ring that supports NetWare,
TCP/IP, and Appletalk.  
    Similar products include Intel's LANSight, FTP's LANWatch, Dolphin
Network's something or other, Triticom's, ...  (as you can tell, the names
all run together as LAN... after a while :-)
    The only PD equivalent I can remember offhand is Beholder, from
(I think) Delft University in the Netherlands.

Bob

Bob Pratt                               | voice     : (408) 473-8274
Network Management Products Division    | Fax       : (408) 435-1706
Novell, Inc.                            | 
2180 Fortune Drive, San Jose, Ca. 95131 | Internet  : rpratt@Novell.com
Disclaimer:  I do not speak for Novell in any way, shape, or form.
     "Next time I say, `Let's go to Bolivia'...  let's go to Bolivia!"
      [BUTCH CASSIDY AND THE SUNDANCE KID]

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 93 17:58:48 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Page-flipping

In article <C5sIJz.Hv8@iphasew.com>, lorna@iphasew.com (Lorna Politzer) writes:
> What is page-flipping?  Can someone please elaborate?


It may depend on whom you ask.

When I say "page-flip", I mean fiddle around in the virtual memory page
tables to cause physical pages to magically move from one virtual space
to another, for example, to move data from an operating system buffer
to a user buffer.  I also use it to mean marking a user page
copy-on-write, forging an mbuf to point to the underlying physical
page, handing that mbuf to the network code, and when the data has gone
out the wire and the mbuf is free, removing the copy-on-write flag.
Both are effective kludges to avoid byte copies, or, more accurately,
to copy network data bytes cheaply.

The costs of page flipping are too complicated and system specific to
talk about in general.  They depend on many things in each particular
system, from the hardware and software implementation of virtual memory
to the hassles and costs of locking common kernel data structures in
multiprocessors.


Vernon Schryver,  vjs@sgi.com

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 93 18:00:12 GMT
From:      alanlb@thor.cs.vt.edu (Alan L. Batongbacal)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Multicast traffic: how much is too much?

Here at Virginia Tech, we have a heterogenous network of DECstations
running Ultrix, DEC X-terminals, Mac II's running A/UX and Mac OS,
Commodore Amigas with SVR4, a few NeXTstations, and I'm not too sure
what else.  All in all, about 40-odd X-stations and about 100 Unix and
Mac OS machines.

Lately, we've been experiencing severe network degradation and I've been
wondering as to whether some bad machine is multicasting its tiny little
brain out.  I say this because I've got this representative netstat
output from one of our primary machines, a DECstation 5000/240:

ln0 Ethernet counters at Tue Apr 20 13:31:43 1993

       65535 seconds since last zeroed
  1660400963 bytes received
   312709931 bytes sent
     3809153 data blocks received
     1779127 data blocks sent
  1371847979 multicast bytes received
     1700475 multicast blocks received
       15694 multicast bytes sent
         371 multicast blocks sent
       97783 blocks sent, initially deferred
       28237 blocks sent, single collision
       18600 blocks sent, multiple collisions
           0 send failures
           0 collision detect check failure
           4 receive failures, reasons include:
		Block check error
		Framing Error
	   0 unrecognized frame destination
	   0 data overruns
	   0 system buffer unavailable
	   0 user buffer unavailable

The X-stations are up most of the time; the machines are nearly never
turned off.

It seems to be that there's an awful amount of multicast traffic going
on.  Is this normal?

--
+---------------------------------------------v-----------------------------+
| Alan L. Batongbacal                         | "If you spew and she bolts, |
| alanlb@cs.vt.edu                            |  it was never meant to be." |
| Bleaksburg, VA 24060                        |    -- Wayne Campbell        |
+---------------------------------------------^-----------------------------+

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 93 19:20:00 GMT
From:      taipan@motoman.pnl.gov (KL Harrison)
To:        comp.protocols.tcp-ip
Subject:   IP Management Tools


Greetings!

I'm looking for advice/software/wisdom regarding add-moves-changes of IP
nodes.  Something that would manage the address space of 13,000 IP nodes.
I'm not after management platforms, just some tools to handle this scenario:

PC with IP addr xxx.xxx.100.111 moves to xxx.xxx.050.023

Has anyone found useful tools to automate/manage the changing of IP
addresses?


Thanks in advance.

--klh


==============================================================================
Ken L. Harrison                  | What I say I say categorically on behalf
VOICE:    (509) 376-1371         | of myself, and what I may say in no way
Internet: taipan@motoman.pnl.gov | represents Boeing, Hanford, DoE, et al.

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Apr 1993 20:09:27 GMT
From:      cleelacj@agedwards.com (Chris Cleeland)
To:        comp.protocols.tcp-ip
Subject:   Firewalls (was "Of course we're running out of IP addresses!")

>In another thread, nelson@crynwr.com (Russell Nelson) writes:
>>In article <58674@olivea.atc.olivetti.com> jerry@olivea.atc.olivetti.com writes:
>>   In article <732541036snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
>>   >Again, how many of these are you *using*?   If the subnet is not
>>   >connected to the Internet, why use up an Internet address?
>>
>>   Even if most of the addresses are behind a firewall and have no external
>>   access they still need unique addresses.  The firewall system needs to
>>   talk to both.
>>
>>So designate *one* class A network to be used behind firewalls. Since
>>by definition the addresses behind the firewall are not on the
>>Internet, there is no harm in reusing them again and again.
>>
>>*Again* I ask, how many Internet addresses is HP using?  Yes, they
>>have assigned 100,000 IP addresses within HP, but how many of these
>>IP addresses are also Internet addresses?

Regarding all these references to firewalls, does anybody know where
one might obtain information about how to write one or (even better),
source to one?  I think this might serve some purposes on one of my
current projects, but I don't want to waste lots of bandwidth spouting
the problem to the World.Net.  If anybody out there feels compassion
for somebody who might be just a bit over his head wants to send mail
to me, I very much like to bounce some ideas/problems off you.

Thanks!
-cj
-- 
==============================================================================
Chris Cleeland 	       	       	|  Internet:   cleelacj@agedwards.com
BOS Dev. Team                   |  USnail:     3878 Connecticut St. Louis 63116
                                |  BellNet:    (314) 289-5372

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Apr 1993 21:23:41 GMT
From:      add@is.rice.edu (Arthur Darren Dunham)
To:        comp.protocols.tcp-ip
Subject:   Re: looking for popmail for windows

In article <wells.26@dartmouth.edu> wells@dartmouth.edu (Suzanne M. Wells) writes:
>Does anyone know if there is a mail program for windows which is similar 
>to POPMAIL for dos.   I am running dos 5 and windows 3.1 on a 486. Please 
>reply via my e-mail address. I am also interested if there is a telnet /ftp 
>software for windows. I have NCSA telnet but am unable to get it to work 
>effiecently and consistently in windows.
>
I don't know about POPMAIL specifically, but assuming that it uses the
POP3 protocol, there is PCEudora.  It does require Windows 3.1 and FTP
software's PC/TCP v2.1 as a TCP stack.	

If these requirements are not too stringent, check ftp.qualcomm.com for
the latest version.
-- 
Darren Dunham                 		          add@is.rice.edu
MicroConsultant                       		  Rice University
(What is that? A small consultant?)	              Houston, TX
Any resemblance between real opinions and my post is coincidental

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Apr 1993 23:35:10 GMT
From:      ejbehr@rs6000.cmp.ilstu.edu (Eric Behr)
To:        comp.protocols.tcp-ip
Subject:   Re: looking for popmail for windows

You may want to look into qvtnet, an integrated package which includes a
POP3 client and works with PD drivers. I haven't used it, but several
people around here did and say it works fine. Do an archie search for the
newest version (3.3?)

-- 
Eric Behr, Illinois State University, Mathematics Department
behr@math.ilstu.edu   or   behr@ilstu.bitnet  (please avoid!)

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Apr 1993 02:31:09 GMT
From:      scotto@ipars.cts.com (Scott O'Connell)
To:        comp.protocols.tcp-ip,biz.sco.general,comp.unix.pc-clone.32bit
Subject:   SCO TCP/IP & PPP Flow Control

I've recently installed a link between two SCO Unix sites running PPP.  I
have found a couple of problems.

The various modems and port configurations have revealed that PPP disables
hardware flow control (rtsflow, ctsflow) when it takes control of the port.
In my case the modem interfaces are configured at 38.4kbps fixed and the
lack of flow control allows rcp/ftp/etc to overrun the modem link.  I'm using
Digiboard's PC/16em and can tell the Digiboard drivers to turn on flow
control AFTER PPP has taken over the port.  This appears to be the only way
to transfer files over the link.

A second problem is that to get the SCO Unix OS to let the Digiboard run
at 115.2kbps Digiboard has an option in the drivers to map 50, 75 and 110
bps to 57.6, 75, and 115.2kbps repectively.  Apparently PPP doesn't work
correctly at these lower(higher) speeds.

My question is have either of these problems been addressed by anyone 
else and have you come up with a work around.  Secondly, is SCO working
on this problem?

Thanks in advance.
-- 

Scott O'Connell - N6ZEK                UUCP: {nosc, ucsd}!crash!ipars!scotto
Spectrum Data Services                 ARPA: crash!ipars!scotto@nosc.mil
Carlsbad, CA                           INET: scotto@ipars.cts.com

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Apr 1993 03:04:53 GMT
From:      pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.)
To:        comp.protocols.tcp-ip
Subject:   Re: Nagle again

In article <930419095311@cream.ftp.com>, jbvb@vax.ftp.com  (James B. VanBokkelen) writes:
> In article <16BB1A7F9.JTHILL@oracle.us.com> jthill@oracle.us.com (Jim Hill) writes:
> 
>     I got a pointer to RFC1122 in email, which doesn't change my reading
>     any.  4.2.3.4 says "if there is unacknowledged data, then the sending
>     TCP buffers all user data..." which I read as implying "if there is no
>     unacknowledged data, the Nagle algorithm has nothing to say on the
>     subject" -- and in this case the TCP should respect PSH according to
>     step 2.
>      
>     RFC896 says apply the test "when new outgoing data arrives from the
>     user", and if anything RFC1122 just reinforces the interpretation by
>     referring to "all queued data".  If 4.2.3.4 said "send segments while"
>     not "send data if" I'd read it differently.  Also true of many other
>     possible wordings, but not the actual wording.
>      
>     I know this is a marginal case, but if other people are consistently
>     getting a different interpretation, I need to fix my parser...
> 
> I've always interpreted Nagle as meaning that a send(MSS+1 bytes) with
> no unacknowlged data in the pipe will generate the following traffic:
> 
> 	SEG1(MSS bytes)	->
> 			<-	ACK1
> 	SEG2(1 byte)	->
> 			<-	ACK2
> 
> Yes, this causes ~1 RTT extra delay over just sending SEG1 and SEG2,
> but the point of Nagle is the overall reduction in traffic on
> full-duplex connections.

And if there _WAS_ unacknowledged data in the pipe, the MSS-sized segment would be sent
immediately, and the extra 1 byte retained until more data arrived from the application that
made the amount of unsent data > 1 MSS, or an ACK arrived acknowledging all previously sent data,
when the 1-byte segment (and any subsequent data from the app to be sent) would be sent as-is.

So streams of lots of data - say a file transfer - are not affected by Nagle at all, since MSS
segments are sent regardless of the presence of un-acknowledged data (up to the window limit, of
course).

Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |          paul@abccomp.oz.au
Kensington NSW 2033| 
AUSTRALIA          | Microwave ovens: God's gift to bachelors

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Apr 1993 03:23:48 GMT
From:      hmchen@fcom.ee.ntu.edu.tw (Hung-ming Chen)
To:        comp.protocols.tcp-ip
Subject:   Re: Network.vs.Host byte ordering

chris@cs.uwa.oz.au (chris mcdonald) writes:
: At least under StunOS just about all library routines such as
: gethostbyname/addr, "provide" structures with IP addresses in
: *network* byte order (e.g. (struct hostent).h_addr_list[0] ).
: 
.......

: Admitedly, under SunOS (SPARC) there is no physical difference,
: but why the difference?

The byte order for Sun is the same as network byte order. But
when you will write a portable program, you had better use the
byte order functios. For example, you hvae a program running
both on VAX/VMS and UNIX. You must use the serial functions.

Fred Chen

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Apr 1993 08:29:48 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!

In article <--------> Ian Phillips writes:

> There are more IP addresses available than the toaster population of the
> earth :-)

Hmm...very profound...

However, surely there are many organisations who do not need to give
Internet access (in the form of a transport session) to all of their 
users, ie. give them a registered IP address.

I'm putting this point not to chastise your arguments in this thread, but 
to get your comments and advice.

In the last year I have advised several large clients who are moving 
slowly  into TCP/IP networking (from either ICL, or stat muxes, 
proprietary networks, or nothing).  In all cases there has been no 
identifiable need for internet access and my advice has been to start 
setting up a "non-registered" IP address space.

The clients have been in transport, health, local authority admin.,
electricity supply, and account for roughly 100,000 workstation/PC
users and some 650,000 employees.  That is a sizable chunk of UK
(large org.) IT. (And for Ian Phillips' interest, they probably all
have toasters....)

In each case, the management of an unregistered "whole internet" address 
space has been possible. Typically, for each client org, we have planned 
to allocate a Class A address to each corporate division, then:

    octet 2  =  subnet within division
    octet 3  =  type of device (eg. 10-60 = PCs, 100 = UNIX box, 
                200 = manageable hubs, 220 = terminal servers etc.)
    octet 4  =  device (host)

We have speculated that if future access to the Internet, or to Internet
connected orgs is needed, then we could use email via one or more gateways.
Also, any small group within each big org (eg. a scientific dept) for
which Internet telnet, rlogin, ftp etc. was essential, they could apply
for "proper"  (IAB/NIC) registered addresses and install them, but we 
would need to build firewalls between our corporate subnets and theirs.

Any comments?  Can anyone see any ghastly pitfalls?

The substantive question for Internet addresses is,  "How many large
organisations (Class-B-worthy) really need ALL their users to be given
telnet, rlogin, ftp, ping, gopher, SNMP etc. to all other users/hosts in
the Internet?"  ("Do they really need a TCP or a UDP connection?"

My view is that there are not all that many academic/defence/research/
engineering bodies left in the world who have not already been 
allocated "official" (NIC) IP address space.  

I believe that Class C addresses will cope for longer than you think.

I also don't think that the shortage of Class B address space, nor the
inconvenience problems of "chunks-of-Class-C" will diminish the massive
growth of sales of TCP/IP/NFS etc. products.

-- 
Phil Royse    -  Comms Consultant
TUDOR HOUSE     12 Woodside Road
Purley, Surrey CR8 4LN  UK        Tel: (44) 81 645 9868

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Apr 1993 13:15:14 GMT
From:      Rob Shirey <shirey@mitre.org>
To:        comp.protocols.tcp-ip
Subject:   Internet Society Symp. on Net. and Dist. Sys. Security


                             CALL FOR PAPERS
                    The Internet Society Symposium on
                 Network and Distributed System Security

        3-4 February 1994, Catamaran Hotel, San Diego, California

The symposium will bring together people who are building software and
hardware to provide network or distributed system security services.
The symposium is intended for those interested in practical aspects of
network and distributed system security, rather than in theory.  Symposium
proceedings will be published by the Internet Society.  Topics for the
symposium include, but are not limited to, the following:

*  Design and implementation of services--access control, authentication,
   availability, confidentiality, integrity, and non-repudiation
   --including criteria for placing services at particular protocol
layers.

*  Design and implementation of security mechanisms and support
   services--encipherment and key management systems, authorization
   and audit systems, and intrusion detection systems.

*  Requirements and architectures for distributed applications and
   network functions--message handling, file transport, remote
   file access, directories, time synchronization, interactive
   sessions, remote data base management and access, routing, voice and
   video multicast and conferencing, news groups, network management,
   boot services, mobile computing, and remote I/O.

*  Special issues and problems in security architecture, such as
   -- very large systems like the international Internet, and
   -- high-speed systems like the gigabit testbeds now being built.

*  Interplay between security goals and other goals--efficiency,
   reliability, interoperability, resource sharing, and low cost.

GENERAL CHAIR:
   Dan Nessett, Lawrence Livermore National Laboratory

PROGRAM CHAIRS:
   Russ Housley, Xerox Special Information Systems
   Rob Shirey, The MITRE Corporation

PROGRAM COMMITTEE:
   Dave Balenson, Trusted Information Systems
   Tom Berson, Anagram Laboratories
   Matt Bishop, Dartmouth College
   Ed Cain, U.S. Defense Information Systems Agency
   Jim Ellis, CERT Coordination Center
   Steve Kent, Bolt, Beranek and Newman
   John Linn, Geer Zolot Associates
   Clifford Neuman, Information Sciences Institute
   Michael Roe, Cambridge University
   Rob Rosenthal, U.S. National Institute of Standards and Technology
   Jeff Schiller, Massachusetts Institute of Technology
   Ravi Sandhu, George Mason University
   Peter Yee, U.S. National Aeronautics and Space Administration

SUBMISSIONS:  The  committee seeks both original technical papers and
proposals for panel discussions on technical and other topics of general
interest.  Technical papers should be 10-20 pages in length.  Panels
should include three or four speakers.  A panel proposal must name the
panel chair, include a one-page topic introduction authored by the chair,
and also include one-page position summaries authored by each speaker
Both the technical papers and the panel papers will appear in the
proceedings.

Submissions must be made by 16 August 1993.  Submissions should be made
via electronic mail to

                   1994symposium@smiley.mitre.org.

Submissions may be in either of two formats:  ASCII or PostScript.  If
the committee is unable to read a PostScript submission, it will be
returned and ASCII requested.  Therefore, PostScript submissions should
arrive well before 16 August.  If electronic submission is absolutely
impossible, submissions should be sent via postal mail to

                   Robert W. Shirey, Mail Stop Z202
                   The MITRE Corporation
                   McLean, Virginia  22102-3481  USA

All submissions must include both an Internet electronic mail address and
a postal address.  Each submission will be acknowledged through the
medium by which it is received.  If acknowledgment is not received within
seven days, please contact either Rob Shirey <Shirey@MITRE.org> or
Russ Housley <Housley.McLean_CSD@xerox.com>, or telephone Mana Weigand at
MITRE in Mclean, 703-883-5397. 

Authors and panelists will be notified of acceptance by 15 October 1993.
Instructions for preparing camera-ready copy for the proceedings will be
postal mailed at that time.  The camera-ready copy must be received by
15 November 1993.

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Apr 93 14:04:20 GMT
From:      odin@macc.wisc.edu (Odin J. Anderson)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   finger client or hack

I need access to finger services (ala port 79), but I'm using Novell's 
LWP and can't find any clients.  Does anyone know were I could find such a 
client or a way to hack into port 79 and get the info?


Odin

--                    Odin J. Anderson                       --
Information Processing Consultant, U.W. Hospital and Clinics   
Dept. of Information Systems       INTERNET: odin@macc.wisc.edu
3330 University Ave. Suite 300     UWHC MHS E-MAIL:  oja@spinet
-- Madison, WI  53705                  PHONE: (608) 263-8434 --

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 93 14:05:09 GMT
From:      b_cobb@hannah.enet.dec.com
To:        comp.protocols.tcp-ip
Subject:   TCPdump questions


-
Does anyone know how to make the tcpdump utility print out just
DNS queries and zone transfers?  I was under the assumption that
just using tcpdump with no qualifiers printed out all packets.
I never see any DNS queries or zone transfers.  Does anyone have
the syntax to print all DNS UDP queries and all TCP zone transfers
going to and comming from host A?

This is on DEC ULTRIX 4.3 with packet filter turned on (I think, 
kernel was configured with 'options PACKETFILER')

Thanks,

-
Name:    Bill Cobb
E-Mail:  cobb@hannah.enet.dec.com
Phone:   508.635.8458
Address: MS DSG1-2/E6
         Digital Equipment Corporation
         4 Technology Park Drive
         Westford, MA  01886

  

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Apr 1993 14:27:32 GMT
From:      price@cbnewsb.cb.att.com (douglas.h.price)
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   MX record overrrides SMTP connection?

I have a question concerning the actions of mail delivery agents with
respect to MX records.  I am aware of a machine that is having trouble
with SMTP mail deliveries.  The SMTP daemon on this machine is flakey,
and doesn't reliably receive mail from other machines.  I would like
to add an MX record to the domain name service for this machine, directing
its mail traffic to another machine that will act as its forwarder.  Will
this work?  Will all mail traffic be directed to the server rather than
the target machine even though the target  machine remains on the Internet?

thanks,

Doug Price

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Apr 1993 14:34:06 GMT
From:      wallwork@rock.concert.net (John D Wallwork -- Personal Account)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Can't FTP from PC to HP workstation: Help!!!

Hi, I'm hoping someone can help me.  Where I work we have to Hewlett-Packard
Workstations connected to an ethernet network (Pathworks).  The HP's are running
HP-UX version  ????.  We also have connected two IBM PC clones running Beam &
Whiteside's TCP-IP implementation for Dos.  When we try to ftp or ping one of the
HP workstations from the PC, the PC hangs, but when we telnet from the PC to the 
workstation it works fine.  FTPing from HP to HP works fine.

The PCs were able to FTP to the workstation lastweek, but it appears someone
changed something this weekend.  Any suggestions would be greatly appreciated.

					Thanx in Advance

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 1993 15:00:48 GMT
From:      calamaro@dist.dist.unige.it (Surlinelli R. Cardino G. Maranzano L.)
To:        comp.protocols.tcp-ip
Subject:   Help about MULTICAST experiment


	Hi all,
		is there anyone who can help me about multicast
	experiment over Internet?
	Who knows something about mbone experiment?
	I have only a report about Internet audicast.

				Thanks

-------------------------------------------------------------------------------
Send a response to:
	
	calamaro@dist.dist.unige.it
-------------------------------------------------------------------------------

 

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 93 15:03:06 GMT
From:      a20@nikhef.nl (Marten Terpstra)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!

In article <735380988snz@peeras.demon.co.uk> proyse@peeras.demon.co.uk writes:
>In article <--------> Ian Phillips writes:
>
>> There are more IP addresses available than the toaster population of the
>> earth :-)
>
>Hmm...very profound...
>
>We have speculated that if future access to the Internet, or to Internet
>connected orgs is needed, then we could use email via one or more gateways.
>Also, any small group within each big org (eg. a scientific dept) for
>which Internet telnet, rlogin, ftp etc. was essential, they could apply
>for "proper"  (IAB/NIC) registered addresses and install them, but we 
>would need to build firewalls between our corporate subnets and theirs.
>
>Any comments?  Can anyone see any ghastly pitfalls?

Not really, except perhaps the fact that you can never communicate with the
"real" owner of the class A you are using from the places where you do have
IP connectivity to the rest of the Internet using a few Cs.

>The substantive question for Internet addresses is,  "How many large
>organisations (Class-B-worthy) really need ALL their users to be given
>telnet, rlogin, ftp, ping, gopher, SNMP etc. to all other users/hosts in
>the Internet?"  ("Do they really need a TCP or a UDP connection?"

From our point of view (the RIPE NCC, who assigns network numbers for
European organisations, including class Bs), hardly any. Most of the B
requests we get are for private companies who will very probably never
connect to the Internet, at least not with the complete internal network.
Pretty much like you have described above. Also we get loads of request
from large supermarkets who want to assign IP numbers to all their cash
registers and even to electronic displays on the shelves. You cannot
convince me that these will ever appear on the Internet ... That is a
waste of unique IP addresses ...

>My view is that there are not all that many academic/defence/research/
>engineering bodies left in the world who have not already been 
>allocated "official" (NIC) IP address space.  

You'll be surprised. Especially in the "newcomers" to the Internet game,
like Eastern Europe, Africa and many others ...

>I believe that Class C addresses will cope for longer than you think.
>I also don't think that the shortage of Class B address space, nor the
>inconvenience problems of "chunks-of-Class-C" will diminish the massive
>growth of sales of TCP/IP/NFS etc. products.

I have to agree with you here. The shortage we can probably live with, the
routing tables is more of a problem ...

-Marten
------------------------------------------------------------------------------
     Marten Terpstra            |        RIPE Network Coordination Centre
 phone: +31 20 592 5065         |                 PO BOX 41882,
  fax:  +31 20 592 5090         |            NL-1098 SJ  Amsterdam,
Internet: marten@ripe.net       |                The Netherlands
------------------------------------------------------------------------------

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Apr 1993 15:33:37 GMT
From:      peter@nmti.com (peter da silva)
To:        comp.dcom.lans.misc,comp.periphs.misc,comp.protocols.tcp-ip
Subject:   UTP class 5 cabling, 25 pair, with telco-50 connectors

We're working on some building wiring designs and have run into a problem:
there doesn't appear to be a source for UTP class 5 (for 100 Mb/s traffic)
in 25 pair bundles. Going to smaller bundles will mean we can't use Telco
50 connectors, which radically complicates the wiring (we can't use stock
telco-50-RJ45 harmonicas and octopus cables, for example).
-- 
Peter da Silva                                            `-_-'
Network Management Technology Incorporated                 'U` 
12808 West Airport Blvd.  Sugar Land, TX  77478  USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Apr 1993 15:59:49 GMT
From:      mwitt@kentrox.com (Michael Witt)
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.dcom.sys.cisco
Subject:   Routers, SMDS and RFC1209


I am trying to gather information on the use of routers over SMDS
networks.  Specifically, I am interested in finding out if router
manufacturers are planning to follow RFC 1209, when forwarding IP
traffic over SMDS links.  If so, I would be very interested in having
a short dialogue with someone who could tell me the details of how
this will work in specific router implementations.

Thanks,

Mike Witt
mwitt@kentrox.com

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Apr 1993 16:01:40 GMT
From:      oldera@twg.com (Ed Alcoff)
To:        comp.sources.wanted,comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: Ethernet monitoring software wanted.

In article <1993Apr19.225256.4810@plaza.ds.adp.com> carl@plaza.ds.adp.com (Carl Ellis) writes:
>I am looking for software that will enable us to monitor network
>traffic from the ethernet level up to TCP/IP.  This software can run
>on either Motorola 88K UNIX R32V3 or on a PC.  PD or commericial.
>
What you probably want is an SNMP-based package, such     
as our Management Station product.  I believe we are      
the only vendor that supports the Motorola MPC.  Our      
current release is 3.0 and supports both R32V3 and        
R40V3.  The next release, 3.1 in November, will only      
support R40V3.                                            
                                                          
What you also need is an RMON SNMP agent (Remote Network  
Monitoring MIB) device for looking at/capturing all of    
the low level (Ethernet) info.  There are several         
vendors that provide such a stand-alone device and I      
can point you to them.                                    
                                                          
Call myself at (415) 962-7240 or sales at (800) 872-8649  
for more info.                                            
                                                          
Regards,                                                  
                                                          
Ed Alcoff                                                 
Product Line Manager                                      
The Wollongong Group, Inc.                                



-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Apr 1993 16:49:21 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: Sniffer


One of the problems I had with Sniffer was the inability to store
information greater than local RAM. I have the desire to capture
information for a 24 hour period or longer. I eventually used tcpdump
Unix program and parsed the 800 MByte file with a Perl script. The
SNIFFER was unsuitable for my needs. 
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 1993 17:53:42 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCPdump questions

In article <2987@sousa.tay.dec.com> b_cobb@hannah.enet.dec.com () writes:
>Does anyone have
>the syntax to print all DNS UDP queries and all TCP zone transfers
>going to and comming from host A?

tcpdump host A and port 53
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Apr 1993 18:38:41 GMT
From:      mandrews@portal.hq.videocart.com (Mike Andrews)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Selective routing on Sun 4/630 using gated

I want to have our Sun 4/630Ms route for only a select few networks.  They
each have 3 or 4 ethernet ports - the one on the motherboard, an InterPhase
NC400 Co-processor on the VME bus, and one or two Sun SBUS ethernet/SCSI
cards.   The SBUS cards connect to small LANs with a group of Xterminals
they "host" (or "client" in X terms).  I want the Sun hosts to route only
for the X networks.  We have a Cisco to route the other networks.  I'm
trying to avoid the expense of buying more etherenet ports on the Cisco
whenever I add an X LAN.

Sooo...   He's my current plan:  I'm going to use gated.  As I understand
it, gated will let me set the metric on the route tables manually.  I'll
set the metric on the interfaces I don't want routed to 5.  

Questions:

I currently have IPFORWARDING 0 in /sys/netinet/in_proto.c:
...
/*
 * ip_forwarding controls whether or not to forward packets:
 *      ip_forwarding == -1  -- never forward; never change this value.
 *      ip_forwarding ==  0  -- don't forward; set this value to 1 when two
 *                              interfaces are up.
 *      ip_forwarding ==  1  -- always forward.
 */
 
#ifndef IPFORWARDING
#define IPFORWARDING 0
#endif
int     ip_forwarding = IPFORWARDING;
...
 
Can I set IPFORWARDING to 1 ("always forward"???)  and still selectively
forward?  As I understand it, the Sun will only advertise routes with
routed or gated, and if I get gated to advertise a higher metric than
the routing will be done by the Cisco with a lower metric.

Anybody doing anything similar?  Will my plan this work?

Please reply via Email and I'll summarize if there's interest.

Thanks!

-- 
Mike Andrews                                        |VideOcart, Inc.
mandrews@hq.videocart.com                           |Chicago, IL USA
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=
Think you've got problems?  How many SHOPPING CARTS are on YOUR LAN?

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Apr 1993 19:05:33 GMT
From:      harrys@ngc.com (Harry Saal)
To:        comp.protocols.tcp-ip
Subject:   Re: Sniffer

In <BARNETT.93Apr21114921@grymoire.crd.ge.com> barnett@grymoire.crd.ge.com (Bruce Barnett) writes:

>One of the problems I had with Sniffer was the inability to store
>information greater than local RAM. I have the desire to capture
>information for a 24 hour period or longer. I eventually used tcpdump
>Unix program and parsed the 800 MByte file with a Perl script. The
>SNIFFER was unsuitable for my needs. 

One feature available since 1986 is to capture only a portion of
each packet into memory, e.g. the first 128 or 256 bytes. As well,
let me bring you up to date on some new features of the most currently
shipping version of the Sniffer analyzer. You can set it up to 
automatically save any or all of the capture memory (0 to 10 MBytes)
to disk when the buffer fills up, and you can also enable data compression
(typically 2:1 or better). I do not believe the unit will be capturing
packets during the disk I/O time, but at your data rates, or for
statistical analysis purposes this is not a great limitation. Of course,
you would have to configure the (portable) PC unit with a multi-hundred
MByte disk to accomplish what you did.

My interest has been piqued: basically what did you want the 800 Mbytes of
LAN traffic for? What was the analysis you performed? 24 hours of raw
A
packet data is a lot!

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Apr 1993 20:37:24 GMT
From:      seifert@netcom.com (Rich Seifert)
To:        comp.dcom.lans.misc,comp.periphs.misc,comp.protocols.tcp-ip
Subject:   Re: UTP class 5 cabling, 25 pair, with telco-50 connectors

In article <id.OLGZ.I2H@nmti.com>, peter@nmti.com (peter da silva) writes:
> We're working on some building wiring designs and have run into a problem:
> there doesn't appear to be a source for UTP class 5 (for 100 Mb/s traffic)
> in 25 pair bundles. Going to smaller bundles will mean we can't use Telco
> 50 connectors, which radically complicates the wiring (we can't use stock
> telco-50-RJ45 harmonicas and octopus cables, for example).
> -- 

That is correct. Category 5 is not available in 25-pair bundles. It is
not possible to meet the crosstalk requirements in this configuration.


-- 
Rich Seifert                    Networks and Communications Consulting
seifert@netcom.com              (408) 996-0922
                                (408) 996-2860 FAX
"... specialists in Local Area Networks and Data Communications systems"

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 93 17:17:39 +0200
From:      wvb@sunvax.sun.ac.za
To:        comp.lang.c++,comp.protocols.tcp-ip
Subject:   Looking for C++ XDR implementation

I am looking for a C++ implementation of XDR, or at
least the basic routines of XDR.  Ideally, a C++ version
of rpcgen that generates all the serialisation code would
be great, but I guess that is too much to ask for :-).

Anyone done anything on this?
Thanks

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Apr 1993 21:16:58 GMT
From:      p45dpmg@fantom.agchem.redwater.iol.ca (Peter Graw)
To:        comp.sys.sun.wanted,comp.protocols.tcp-ip
Subject:   telnet with scripting capabilities

I'm interested in doing some non-interactive logins via telnet (started from
cron) for device monitoring on a regular basis.

Is there some PD telnet implementation available to do this? Any PD 
implementation of telnet? Where? 

Please reply via email. Thanx.
-- 
--------------------------------------------------
Peter Graw (p45dpmg@iol.ca)
Imperial Oil - Chemicals Division
Information Management

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 1993 22:12:16 GMT
From:      marmary@tschil.informatik.rwth-aachen.de (Mahmoud-Reza Nazeman)
To:        comp.protocols.tcp-ip
Subject:   Retransmission Timeout Calculation

I have two questuiions concerning the RTO Calculation:

1. Which values are usually used for initialization?
   (RTO = 3 seconds; srtt = ?; dev = ?)

2. If You would tray to describe the integer calculation of the RTO
   in floating point numbers, would the followin be right?

   (I'm not sure about it, because of some typos in Comer's book)

   delta	= rtt - srtt 

   srtt		= 1/8 rtt + 7/8 srtt

   dev		= 3/4 dev + |delta| * 1/4


   RTO		= srtt + 2 * dev	(?)


Any help would be appreciated.

-marmary

marmary@brand.informatik.rwth-aachen.de


-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Apr 1993 22:40:21 GMT
From:      sblair@upurbmw.dell.com (steve)
To:        comp.protocols.tcp-ip
Subject:   Re: SVR4 As DNS Client Won't Work

[ since the poster's email address causes bounces, this ]
[ distribution is only available media for a followup ]

dickson@escob1.UUCP writes:
*>I am trying to get DNS to work on my company's 486 running
*>SVR4.0.  This machine will not be running the named locally,
*>it will be in "client mode".  I want to use an existing
*>Domain Name Service, available on our local network.  I have
*>installed a "/etc/resolv.conf" file, and modified the
*>"/etc/netconfig" file per vendor instructions.

OK, I've got over 1024 SVR4, SUNOS, IRIX, etc. UNIX clients.
Our DNS hubs are 2 primaries, 6 secondaries, and a few caching-
only name servers. DNS does work, but it's not hard to do.

Since you don't specifiy WHICH V.4 you're using I have to guess it's
not Dell's. Especially since I have hunderd's of SVR4 DNS clients
and if we had this problem, every user in Dell, as well as with 
access to usenet would be complaining.

*>When I use nslookup, everything seems to work OK.  When
*>attempting to use telnet or ftp, or any other network
*>application that needs name resolution, it fails.  Following
*>are my "config" files and an example nslookup output, and
*>telnet failure.  Am I missing something?  ...  Any help
*>would be very appreciated!


There could be that the applicationas could have not been compiled
as -lresolv, -lsocket, are the most glaring issues. The libc from
your vendor could also not have been compiled properly. Your failure
is a common one(in SOME unices) of the function "gethostbyname/gethostbyaddr".


*>The "Network User's and Administrator's Guide" also mentions
*>copying /usr/lib/libsockdns.so on top of /usr/lib/libsocket.so ....
*>no can do - we don't have a libsockdns.so library.

Idle speculation here, mabye it's typo. Could be libresolv.so, or
resolv.so,  we don't have the library either. Nor does Sun, SGI, or
any other available machine I could check.


As far as your netconfig, you MIGHT want to try moving the resolv.so infront
of the tcpip.so. Kinda far-fetched, but so is stating DNS in svr4
is broken w/o saying which vendor's implementation has a problem.


Your resolv.conf should look like this, if you don't have a /etc/domain:

domain	foo.com
nameserver	xxx.xxx.xxx.xxx


good luck.


--
Steve Blair  Dell Network Services sblair@dell.com HOSTMASTER@DELL.COM
======================================================================
"Dan Quayle's head is emptier than a Jack-In-The-Box in Seattle"
					-Dennis Miller

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Apr 1993 23:25:00 GMT
From:      karl@empirical.com  (Karl Auerbach)
To:        comp.sources.wanted,comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: Ethernet monitoring software wanted.

> I am looking for software that will enable us to monitor network
> traffic from the ethernet level up to TCP/IP.  This software can run
> on either Motorola 88K UNIX R32V3 or on a PC.  PD or commericial.
Well, you certainly got a number of answers already, so I'll just
add a few more comments.
I personally use FTP's LANwatch.  I value the display-the-packet-when-it-
happens format as opposed to the capture-then-view format of most
of the other products.
But LANwatch will miss packets on a busy network.  There *are* limits
to how fast one can get packets into a PC and the real-time display
of LANwatch adds overhead.  The Sniffer, Lanalyzer ... products are
better in heavy load situations.
The old non-PC based Lanalyzer was the best box I've seen for doing accurate
timestamps on packets.
The old MIT "netwatch" is still available as part of the PC/IP package
on various archives.
Now for something completely different -- if you want to do more than just
view the traffic on the net, but to analyze it, most packages have some
capabilites, but there whole other classes of gear.
For example, the Concord Trakker is really quite a nice box for gathering
all kinds of statistics.  And check out Net Metrix (sp?) for post hoc
protocol analysis.
My company produces a box that will do a simple traffic view in conjunction
with a reasonably rich toolbox of TCP/IP reachability functions (ARP,
ping, traceroute, i.e. it's not a passive box) plus SNMP plus Netware... 
but I'm getting too commercial here.  Contact me directly for more
information.
			--karl--
			Karl Auerbach -- karl@empirical.com
			Empirical Tools and Technologies
			517-C Mission St. Santa Cruz, CA  95060
			(408) 427-5280 (voice) (408) 427-5281 (fax)

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 02:07:49 GMT
From:      marcelm@joymrmn.on.ca (Marcel Mongeon)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!

proyse@peeras.demon.co.uk (Phil Royse) writes:

>In the last year I have advised several large clients who are moving 
>slowly  into TCP/IP networking (from either ICL, or stat muxes, 
>proprietary networks, or nothing).  In all cases there has been no 
>identifiable need for internet access and my advice has been to start 
>setting up a "non-registered" IP address space.
 
>The clients have been in transport, health, local authority admin.,
>electricity supply, and account for roughly 100,000 workstation/PC
>users and some 650,000 employees.  That is a sizable chunk of UK
>(large org.) IT. (And for Ian Phillips' interest, they probably all
>have toasters....)
 
>In each case, the management of an unregistered "whole internet" address 
>space has been possible. Typically, for each client org, we have planned 
>to allocate a Class A address to each corporate division, then:
 
>    octet 2  =  subnet within division
>    octet 3  =  type of device (eg. 10-60 = PCs, 100 = UNIX box, 
>                200 = manageable hubs, 220 = terminal servers etc.)
>    octet 4  =  device (host)

Which Class A address are you using? :-)

I don't know if you saw it, but in a previous post on a related
issue, I suggested that for this type of purpose consideration
be given to using the class A network "127".  Yes, 127.0.0.1 is the
standard loopback.  However, as far as I can tell, everything else
in the space is free.

One advantage of the 127 space is that if it gets out beyond a
firewall through a mistake, it will be bounced back pretty
quickly with a network unreachable ICMP.

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

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 08:22:50 EDT
From:      Andrew T. Robinson <ANDY@MAINE.MAINE.EDU>
To:        comp.protocols.tcp-ip,comp.security.misc
Subject:   Encrypting IP data "transparently"???

Someone who is considering attaching to the Internet was discussing
some security concerns with me.  One question in particular I have been
wondering about, and hope that folks in c.p.t or c.s.m might be able
to help.

The situation:  An organization with geopraphically dispersed locations
wishes to use Internet connectivity to offload some WAN costs while
enhancing their access to various resources available on the Internet.
The infamous issue of "not knowing where the data goes" is a problem
because this organization works with sensitive information, and their
current dedicated leased line WAN gives them the (perhaps false)security
of knowing exactly what path this information is taking from point to
point.  Connecting to Internet introduces the uncertainty of IP routing,
and the possibility that someone may be sniffing at a connection and
find passwords, sensitive data or file names, etc.

The question:  Is there a product which allows the data portion of IP
datagrams to be encrypted, leaving the headers alone for routing?  I.e.,
"If the destination network is 255.255, then encypt the data portion
with key FOOBAR."  On the receiving end, the product would reverse the
process:  "If the origin network is 0.0, then decrypt the data portion
with key FOOBAR."

If such a thing were to exist, I would assume it would be either a
hardware device that is interposed between the network and gateway
or between the gateway and the Internet, or a software function of the
router/gateway--this is the only way I can see any level of transparency
maintained.  Checksums could be ignored until the datagram was decrypted.

I seem to remember hearing about devices like this, but the more I think
about it the less sure I become.  Is there such a thing, and if so is
it a commercial-grade, commercially available product?

If such a thing DOESN'T exist, what are some solutions that have been
used to address the problem of data security on "cloud" networks?

PLEASE REPLY DIRECTLY TO ANDY@MAINE.EDU

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 09:40:38
From:      rodin@vax.ftp.com  (Jonathan Rodin)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet monitoring software wanted.

karl@empirical.com  (Karl Auerbach) writes:
> But LANwatch will miss packets on a busy network.  There *are* limits
> to how fast one can get packets into a PC and the real-time display
> of LANwatch adds overhead.  The Sniffer, Lanalyzer ... products are
> better in heavy load situations.

The real-time display in LANWatch does cause packets to get dropped.  However,
LANWatch does not need to be run in real-time display mode.  In throughput
mode (where only summary statistics regarding net traffic are displayed)
LANWatch can capture packets at a much higher rate.  If configured correctly
LANWatch will capture packets at the same rate as any other PC based analyzer
product (Sniffer, LANAlyzer, etc.).

Jon

--
Jonathan Rodin             FTP Software, Inc.            voice: (508) 659-6261
rodin@ftp.com              2 High Street                 fax:   (508) 794-4488
                           North Andover, MA  01845




-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 93 15:00:25 -0500
From:      harvey@indyvax.iupui.edu
To:        comp.sys.sun.wanted,comp.protocols.tcp-ip
Subject:   Re: telnet with scripting capabilities

In article <1993Apr21.211658.10905@fantom.agchem.redwater.iol.ca>, p45dpmg@fantom.agchem.redwater.iol.ca (Peter Graw) writes:
> I'm interested in doing some non-interactive logins via telnet (started from
> cron) for device monitoring on a regular basis.
>
> Is there some PD telnet implementation available to do this? Any PD
> implementation of telnet? Where?

C-Kermit has a scripting facility and works over Telnet on SunOS.  You can
get the latest version at watsun.cc.columbia.edu.

> Please reply via email. Thanx.

Others are posting "me too" articles so I'll forward the posted followup.
--
James Harvey    IUPUI OIT Technical Support -- VMS/Unix/Networks
harvey@iupui.edu  uucp:iugate!harvey  bitnet:harvey@indyvax

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 06:42:57 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Network.vs.Host byte ordering

In article <chris.735276999@budgie> chris@cs.uwa.oz.au (chris mcdonald) writes:
>At least under StunOS just about all library routines such as
>gethostbyname/addr, "provide" structures with IP addresses in
>*network* byte order (e.g. (struct hostent).h_addr_list[0] ).

In my opinion, there is no such thing as "host order" or "network
order" to IP addresses.  IP addresses should be treated as four bytes
of eight bits each -- which is how they are always printed: dotted
decimal notation -- not as 32 bit integers.  Since there is no question
about byte swapping for a single byte value, clearly there'd be no
issue about how the four bytes of the IP address should be stored or
transmitted.

I wish i could say that this is why the BSD derived APIs pass the IP
address in the byte order they do, but, alas, the fact that they *also*
handle UDP and TCP ports in network order belies the fact that they
were just being lazy and didn't really give it any serious thought.

>However, according to their manual, structures pointed by getnetent()
>and friends has a (struct netent).n_net field which is
>in *host/machine* byte order.
>
>Admitedly, under SunOS (SPARC) there is no physical difference,
>but why the difference?

Just in case you're overlooking the first order answer, it is that
these numbers are *network* addresses, not IP (a.k.a., host)
addresses.  The loopback network, for example, has network address
127.  An IP address on the loopback network would be 127.0.0.1.
They're two different things, hence the two different formats.

If we move on to the second order answer, i have no idea what was in
someone's mind when they decided to treat network addresses so
radically different than host addresses.  I've always been puzzled by
it.  The difference, by the way, is even more extreme than you
describe.  Network addresses are not only byte swapped on little endian
machines, they are also shifted down to get rid of the host number part
of the address.  So the network address 130.57 would be stored as
130<<8 + 57 instead of the more fathomable 130<<24 + 57<<16.  At least,
that's how it worked on the one batch of BSD derived code i saw...

						don provan
						donp@novell.com


-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 93 15:25:11 -0500
From:      harvey@indyvax.iupui.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!

In article <1r6eh3$roj@usenet.INS.CWRU.Edu>, trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:
> In article <C5v4L2.KH1@joymrmn.on.ca> marcelm@joymrmn.on.ca (Marcel Mongeon) writes:
>>However, as far as I can tell, everything else in the space (127.*) is free.
>
> But will your routers forward it?

If they do, they are broken.  RFC 1122 says that addresses of the form
127.* MUST NOT appear outside a host.

While we're on the subject of loopback addresses, a certain elderly TCP/IP
implementation I am aware of used the class A network 14 for loopback.
This net is in the NIC database as the Public Data Network (PDN-NET) and
the NSFNET backbone knows no routes to it.  Did this ever cause problems
or is it just an historical thing?
--
James Harvey    IUPUI OIT Technical Support -- VMS/Unix/Networks
harvey@iupui.edu  uucp:iugate!harvey  bitnet:harvey@indyvax

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 11:26:14 EDT
From:      Rick Thibeault, UMPI <RICK@MAINE.MAINE.EDU>
To:        comp.sys.sun.wanted,comp.protocols.tcp-ip
Subject:   Re: telnet with scripting capabilities

Me too........Thanks

>I'm interested in doing some non-interactive logins via telnet (started from
>cron) for device monitoring on a regular basis.
 
>Is there some PD telnet implementation available to do this? Any PD
>implementation of telnet? Where?

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 93 08:00:10 GMT
From:      mikec@ornews.intel.com (Mike Coleman)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Reconfiguring <= key with PCTCP

All,

I was curious if there was a way to reconfigure the backspace key to
send a bs (as opposed to a del). I currently do this for every session
by pressing f10 B.

Is it possible to use IPCONFIG to make this setting the default for 
TN sessions?

Thanks,
Mike Coleman
mikec@ornews.intel.com
 

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 08:00:28 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP through a Router?

tli@cisco.com (Tony Li) writes: 

>In article <1qeqbaINNkka@charnel.ecst.csuchico.edu>
>dpike@oavax.csuchico.edu (Dan Pike) writes: 
>    Why am I not able to RARP across a router?  I have a bridge and our
>    management station on the same Cabletron MMAC, but I'm still not able to
>    RARP an IP address to the bridge.  The two devices are in different
>    subnets (one is in .78.xxx and the other is in .80.xxx).  Interface 0 of
>    our AGS+ goes to a port on the FOMIM which also connects all of our
>    buildings via fiber.  The subnet mask of each of the buildings on campus
>    is set up as though it was a class c address.  Why will the router not
>    allow the management station to RARP an IP address to the bridge?  Any
>    help you can offer would be greatly appreciated.
>    
>RARP is an unroutable protocol.  It must be bridged.

More specifically, I believe RARP is a *broadcast* protocol (at least the
request is).  Broadcast packets are not normally routed, the reasoning being
that if they were, one broadcast on some little net somewhere would eventually
make its way to every net in the universe.  Worse yet, any redundant network
routed links (and we know there are plenty in the Internet), they would
rebroadcast them 'round and 'round forever (as RARP has no time-to-live
counter, as IP does) repeating them back to their source and everywhere else
on every cycle, eventually destroying the network.  Bridges have protection
against this phenomenon designed in.

Fred

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 08:13:25 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: How does the NFSNET know the route to my IP address?

stewart@oin.cis.udel.edu (John Stewart) writes: 

>In article <1qgd1kINN50o@cronkite.cisco.com> tli@cisco.com (Tony Li) writes:
>>In article <1qffbp$nui@spock.dis.cccd.edu> markb@cccd.edu writes: 
>>    Somebody joins Internet and gets an IP address assigned to them.  How
>>    are the many, many routers on the NSFNET notified of the resulting new
>>    route?  Due to the sheer overwhelming size of the net, I'm sure there's
>>    got to be some automatic router protocol to propagate this information.
>>    Can anybody provide me the relevant acronyms (and optionally RFC
>>    numbers)?
>>    
>>See BGP, OSPF, RIP and EGP.
>
>Also see IS-IS; I think that's the intra-domain routing protocol
>currently in use in the NSFNET (a.k.a ANSNET).

It was my understanding that the core gateways (and I'm not at all sure
there's suppose to be that many of them) used their own routing protocol.
(CGP or something like that.)  The internal and external protocols mentioned
above aren't really that suitable, as the core gateways need to rapidly
transfer the entire routing tables for *all* internet addresses.  The
protocols mentioned above generally assume a relatively small table of
networks known by the gateways and rely on a default gateway to kick
packets to which are addressed to someplace unknown.

Fred

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 1993 15:24:03 -0400
From:      themos@umbc.edu (Mr. Themos Pentakalos)
To:        comp.protocols.tcp-ip
Subject:   TRAINING

Hi everyone,

Since this is a related list, I thought I'd post something I just
found out:

Our University's Continuing Education program has just started a 
training program and they hired some consulting company to do
a lot of great classes. The classes are held somewhere in the
Baltimore-Washington DC area. Here are some of the titles:

- Alpha Architecture / Migration Planning
- UNIX  (whole bunch of different ones... system management, networking, etc.)
- Windows NT Internals and Configurations
- Ethernet stuff
- Pathworks stuff
- Windows for Workgroups
- a lot of others I don't recall right now.

The best part about it is that they have some ridiculously low prices.
I guess that's because the University is non-for-profit.

Anyway, if anyone's interested in their spring catalog, give this number
a buzz:  (410) 455-2336





-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 93 13:51:05
From:      shirono@ssd.csd.harris.com (Roberto Shironoshita)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!

In article <C5v4L2.KH1@joymrmn.on.ca> marcelm@joymrmn.on.ca (Marcel Mongeon) writes:

> proyse@peeras.demon.co.uk (Phil Royse) writes:
>
> >In the last year I have advised several large clients who are moving 
> >slowly  into TCP/IP networking (from either ICL, or stat muxes, 
> >proprietary networks, or nothing).  In all cases there has been no 
> >identifiable need for internet access and my advice has been to start 
> >setting up a "non-registered" IP address space.
 
> >The clients have been in transport, health, local authority admin.,
> >electricity supply, and account for roughly 100,000 workstation/PC
> >users and some 650,000 employees.  That is a sizable chunk of UK
> >(large org.) IT. (And for Ian Phillips' interest, they probably all
> >have toasters....)
 
> >In each case, the management of an unregistered "whole internet" address 
> >space has been possible. Typically, for each client org, we have planned 
> >to allocate a Class A address to each corporate division, then:
 
> >    octet 2  =  subnet within division
> >    octet 3  =  type of device (eg. 10-60 = PCs, 100 = UNIX box, 
> >                200 = manageable hubs, 220 = terminal servers etc.)
> >    octet 4  =  device (host)
>
> Which Class A address are you using? :-)
>
> I don't know if you saw it, but in a previous post on a related
> issue, I suggested that for this type of purpose consideration
> be given to using the class A network "127".  Yes, 127.0.0.1 is the
> standard loopback.  However, as far as I can tell, everything else
> in the space is free.
>
> One advantage of the 127 space is that if it gets out beyond a
> firewall through a mistake, it will be bounced back pretty
> quickly with a network unreachable ICMP.

Hmm... the ASSIGNED NUMBERS RFC (currently 1340, of July 1992), in its
"Special Addresses" section, states:

   [...]

   There are certain special cases for IP addresses [11].  These special
   cases can be concisely summarized using the earlier notation for an
   IP address:

         IP-address ::=  { <Network-number>, <Host-number> }

            or

         IP-address ::=  { <Network-number>, <Subnet-number>,
                                                         <Host-number> }

   if we also use the notation "-1" to mean the field contains all 1
   bits.  Some common special cases are as follows:

   [...]

         (g)   {127, <any>}

            Internal host loopback address.  Should never appear outside
            a host.
   [...]

Seems like your proposal just got shot.  Nonetheless, from this discussion
the RFC might be changed in some fashion to state that a firewalling
technique would allow its use.

Routing still has to be a nightmare, though.  On the BSD-derived systems I
know of, the loopback interface is assigned address 127.0.0.1, and is
treated by the protocol layers of the software as any other interface.
Since it is typically assigned no netmask, the entire 127 network is routed
through it.

I suppose you could netmask the loopback (say 255.255.255), creating
<however many> Class-C-sized subnets.
--

     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.

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 93 15:12:16
From:      amoss@shuldig.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: finger client or hack

odin@macc.wisc.edu (Odin J. Anderson) writes:

   I need access to finger services (ala port 79), but I'm using Novell's
   LWP and can't find any clients.  Does anyone know were I could find such a
   client or a way to hack into port 79 and get the info?

Maybe GNU finger comes with a client too?  (at least it used to).  You should
be able to write a very simple programme to connect to TCP port 79 and output
the user name on the socket.

If you have a telnet client you can specify the destination port for then try:

% telnet cs 79
Trying 132.65.16.10 ...
Connected to cs.huji.ac.il.
Escape character is '^]'.
amoss                         <--------  here you type the user name and press
                                         ENTER
Amos Shapira (amoss) is not presently logged in.
Last seen at shuldig on Tue Apr 20 22:48:23 1993
Connection closed by foreign host.


Hope this helps.

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


-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 11:12:12 GMT
From:      smee@bristol.ac.uk (Paul Smee)
To:        comp.protocols.tcp-ip
Subject:   Re: How does the NFSNET know the route to my IP address?

In article <1qffbp$nui@spock.dis.cccd.edu> markb@cccd.edu writes: 
>    Somebody joins Internet and gets an IP address assigned to them.  How
>    are the many, many routers on the NSFNET notified of the resulting new
>    route?

Other people have supplied nice refferences, as requested in the bit I
cut off.  For a quick and dirty overview, though:

For the most part, they aren't.  The 'backbone' routers know how to get
to each assigned Class A, Class B, and Class C *network* as an entity
-- but they don't have any idea what goes on inside those nets.  When a
new A/B/C network is assigned, the backbone routers need to be taught
about it, and they are told an IP address which will get them to a
router through which they can get to the new organisation.  The
backbone routers DO have protocols which allow them to trade
information, useful both when new stuff is added, and whenever the
Internet topology changes either intentionally or because of links
going down.

Within each Class A/B/C network, it's up to the local administrators
and routers to keep track of what is where.  This may involve multiple
levels of routing from the 'entrance' router to the machine being
addressed.  In general, the 'organisation' routers involved will know
how to get to all their directly attached machines, and to all their
own subnets, and will be told a 'default' router (usually the
'entrance' router) which they should throw everything at that they
don't know where is.

So, let's say, for (made up) example, you want to send something to
13.14.15.100, and you're somewhere else.  Your machine will put out a
packet addressed to 13.14.15.100.  Your local router will say 'not on
our subnet) and will use the default routing to pass it towards the
backbone.  When the backbone routers get it, they'll say 'that's on
class A network 13' and throw it at net-13's service entrance.

Now assuming that net 13 is big enough that they've used some sensible
hierarchical assignment, their entrance router might say 'that's on my
subnet 14', and toss it at a router which connects to all the '14'
addresses.  That router in turn will toss on towards internal subnet
15, and so on.

(It's important to note that the end site may use hierarchical
assignments, but it also may not.  It's conceivable that the net-13
entrypoint knows exactly where each target machine is.  The basic
point, though, is that no single router knows enough to get things
straight from one end to the other, but each router along the path
knows how to throw the packet in the right direction.)

-- 
Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK
     P.Smee@bristol.ac.uk - Tel +44 272 303132 - FAX +44 272 291576

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 18:15:17 -0400
From:      Lyle_Seaman@transarc.com
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: finger client or hack

odin@macc.wisc.edu (Odin J. Anderson) writes:
> I need access to finger services (ala port 79), but I'm using Novell's 
> LWP and can't find any clients.  Does anyone know were I could find such a 
> client or a way to hack into port 79 and get the info?

Finger just uses the telnet protocol.  I don't know about Novell's
telnet client, but the BSD telnet will let you specify a port number:

telnet hostname 79
@hostname
jimbob

For example (my input preceded by >, computer output preceded by <):
[public] telnet transarc 79
<Trying 192.54.226.1...
<Connected to transarc.com.
<Escape character is '^]'.
>lws
<Login name: lws                         In real life: Lyle Seaman
<Directory: /afs/transarc.com/usr/lws    Shell: /bin/csh
<Address mail to: lws+@transarc.com
<Account used on Thu Apr 22 18:10 (2 minutes 56 seconds ago).
<Last login Sat Apr 10 20:28 on ttyp0 from vaxc.isc.rit.edu
<3 new messages; last one arrived Thu Apr 22 18:08 (4 minutes 40 seconds ago).
<Plan:

Lyle		Transarc		707 Grant Street
412 338 4474	The Gulf Tower		Pittsburgh 15219

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 18:25:52 -0400
From:      Lyle_Seaman@transarc.com
To:        comp.protocols.tcp-ip
Subject:   Re: Retransmission Timeout Calculation

marmary@tschil.informatik.rwth-aachen.de (Mahmoud-Reza Nazeman) writes:
> I have two questuiions concerning the RTO Calculation:
> 
> 2. If You would tray to describe the integer calculation of the RTO
>    in floating point numbers, would the followin be right?

That's right, except that I find that instead of the following:
>    RTO          = srtt + 2 * dev        (?)

RTO = srtt + 4*dev works better.

(actually, I was happy with 3*dev, but 4*dev is cheaper to calculate
 and doesn't seem to hurt anything)

Lyle		Transarc		707 Grant Street
412 338 4474	The Gulf Tower		Pittsburgh 15219

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 11:58:25 GMT
From:      holemans@reks.uia.ac.be (Wim Holemans)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   pcroute - some questions

We use PCroute at our campus for the moment for a few connections but intend to
create a backbone structure with them. We are using PCroute with the patches
announced some months ago, allowing host routing and full proxy arp.

I have some questions for other users of PCroute :

1) what does pcroute do with udp broadcasts ? I know one can forward bootp
   packets, but what about xdcmp (xserver announcement broadcast packets) ?
   Can pcroute easily be adapted so that these requests are forwarded
   or broadcasted to all interfaces ?

2) what does pcroute do with a route to an interface that gets down ? Is
   pcroute able to detect that an ethernet connection has gone down ? We
   are trying to set up a construction with automatic fallback to a serial
   line when ethernet connections go down.
   construction :

   ----------------------------- net 1 (thin net segment with multi port
    |                   |               repeaters on it)
 +---+                 | fiber link
  |R2 |              +-----+
  |   |--------------| R1  |
  +---+ serial line  |     |
                     +-----+                   
                        |
                   -------------- ethernet backbone with other routers

R1 and R2 are both PC-Route based routers. R2 is a backup router. We use
proxy arp in the hosts on net 1 to determine which router to use. In normal
conditions R1 offers a direct connection to the backbone (metric 1) and
R2 keeps silent if it sees arp requests for hosts at or after the backbone.

Suppose our fiber link goes down. After a while R2 doesn't see any route
updates more from R1 concerning routing to the backbone. If a host on net 1
places an arp, R2 answers that he is the default gateway to that route.
This works. I've tested this. But R1 doesn't seem to think that the interface
is down and keeps his route to net 1 with metric 1. You see then (thanks to
the new option for displaying packets that come from a wrong interface) that 
R1 discards packets that he receives via the serial line as he thinks they 
should come from the ethernet interface.

Any solution or remark to this constructin, problem would be welcome.

Thanks,


-- 
-------------------------------------------------------------------------
W. Holemans				phone + 32 3 820 22 03
Network/System manager			fax   + 32 3 820 22 44
U.I.A.

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 12:16:47 GMT
From:      k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
To:        comp.protocols.tcp-ip
Subject:   Re: How does the NFSNET know the route to my IP address?

fred_s@netcom.com (Frederick Scott) writes:

>stewart@oin.cis.udel.edu (John Stewart) writes: 
 
>>In article <1qgd1kINN50o@cronkite.cisco.com> tli@cisco.com (Tony Li) writes:
>>>In article <1qffbp$nui@spock.dis.cccd.edu> markb@cccd.edu writes: 
 
>It was my understanding that the core gateways (and I'm not at all sure
>there's suppose to be that many of them) used their own routing protocol.
>(CGP or something like that.)  The internal and external protocols mentioned
>above aren't really that suitable, as the core gateways need to rapidly

I remember a talk at InterOP Fall 91, where a guy from ANS talked about
the NSF Core, and he said, they use Dual IS-IS.
(IS-IS routing protocol in dual mode supports ISO-IP as well as Internet-IP)
Maybe the situation has changed since then, but I don't know.

Sincerely,
Klaus Steinberger
--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende, D-8046 Garching, Germany
FAX:   (+49 89)3209 4280        !!! after 1. July new ZIP Code 85748
Internet: Klaus.Steinberger@Physik.Uni-Muenchen.DE

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 13:05:13 GMT
From:      stewart@oin.cis.udel.edu (John Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing: books, literature wanted

In article <1qudnhINNck3@nanette.sto.pdb.sni.de> Martin W Freiss <freiss.pad@sni.de> writes:
>this is not really about TCP/IP, but about routing in general. I just figure
>that this group has the readership I'm looking for :-)
>I'm looking for some literature about routing. I've read most of the
>RFCs about BGP/EGP/RIP/OSPF, hope that I've understood most of what I
>read, but have the nagging feeling that I miss some basic theory.
>I'd be grateful for tips on what to read and where to look for
>(electronically available?) information on the topics
>
>- link state vs distance vector algorithms
>- the mathematics involved in "best path discovery" and propagating
>  topology changes 

My personal favorite is _Interconnections: Bridges and Routers_
by Radia Perlman.  She talks about everything you're asking
about, and does so in a pretty humorous way.

Good luck.

/jws

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 15:34:22 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: RTO Calculation (decimal)?

In article <marmary.734949078@kaa>, marmary@kaa.informatik.rwth-aachen.de (Mahmoud-Reza Nazeman) writes:
> In "Comer, Stevens: INTERNETWORKING with TCP/IP, Volume II, Chapter 14" I have
> found the following in the comment line of the rto-implementation:
 ...
> 	rto   = 2 * (srtt + rtde)
 
> So my question is, wether this is the right way to calculate the rto with decimals?

	This last line in the comment in "tcprtt.c" is incorrect. It should
be "rto = srtt + 2*rtde". The code is correct, though not easier to understand
with the bogus comment.


-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 1993 15:43:51 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.dcom.lans.misc,comp.periphs.misc,comp.protocols.tcp-ip
Subject:   Re: UTP class 5 cabling, 25 pair, with telco-50 connectors

In article <id.OLGZ.I2H@nmti.com> peter@nmti.com (peter da silva) writes:
>We're working on some building wiring designs and have run into a problem:
>there doesn't appear to be a source for UTP class 5 (for 100 Mb/s traffic)
>in 25 pair bundles.

Call South Hills Datacomm (1-800-245-6215).  They have Level 5
wiring in 25 pair bundles.  It's Real New (like a month old).  The price
I was told was US$0.75/ft.  It's so new in fact that not even all the
sales reps know about it.  (The first guy I talked to said they didn't
have it, but then got a call back from the rep assigned to our campus
that said there was.  In fact another department here just ordered a roll.)

>Going to smaller bundles will mean we can't use Telco
>50 connectors, which radically complicates the wiring (we can't use stock
>telco-50-RJ45 harmonicas and octopus cables, for example).

Yes, you need what is referred to as a "110" style block.  It is Catagory
5 rated.  Make sure though when you use in a patch panel that there are
level-5 rated wires _everywhere_ internally.  (Needs twists right up to
all the connectors)

[new job, Peter?  congrats!  :-) ]

--Dave
-- 
System Administrator, Penn State Population Research Institute
IP over ATM?  You mean I can read my email from a cash machine?

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 1993 15:44:33 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!

In article <C5v4L2.KH1@joymrmn.on.ca> marcelm@joymrmn.on.ca (Marcel Mongeon) writes:
>However, as far as I can tell, everything else in the space (127.*) is free.

But will your routers forward it?

-- 
Stephen Trier                     Work: trier@ins.cwru.edu
Network Software Engineer         Home: sct@po.cwru.edu
IRIS/INS/T
Case Western Reserve University

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 16:22:01 GMT
From:      wangbs@locust.iie.ncku.edu.tw
To:        comp.protocols.tcp-ip
Subject:   How the tunnel work of IP Multicast ....

    Hi, all:
	I have a question about the transmission of IP Mulitcast Extension.
   Here is a figure of IP header:
    0			1		    2			3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|	      Total Length	   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |	     Identification	   |Flags|	Fragment Offset    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |	Protocol   |	     Header Checksum	   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |			   Source Address			   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |			Destination Address			   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |			Options 		   |	Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		       Internet Datagram Header

   Here is some words from FAQ of MBONE: ---->
   * How do IP multicast tunnels work?
   "IP mulitcast packets are encapsulated for transmission through tunnels,
    So that they look like normal unicast datagrams to intervening routers
    and subnets. Currently, the encapsulation takes the form of source routing.
    The multicast router modifies the packet by appending an IP Loose Source
    Route option to the packet's IP header. The multicast destination address
    is moved into the source route, and the unicast address of the router at
		      ^^^^^^ ^^^^^
    the far end of the tunnel is placed in the IP Destination Address field.
    Thus, normal unicast routing carries the packet to the other end of the
    tunnel where the multicast router restores the original multicast
    destination address and deletes the source route before forwarding the
    packet."
   --> Since I still confuse above words, I want to know how multicast IP
       modify the IP header?	 [ Forgive me if I am so ....fool... :-)  ]
   --> what is source route?	 [ I can't find its means from my all book...]
	    Thanks in advance for any response & help!!
							   wangbs  4/23/93'

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 1993 16:24:56 GMT
From:      richard_kogut@brown.edu (Richard M. Kogut)
To:        comp.dcom.lans.misc,comp.periphs.misc,comp.protocols.tcp-ip
Subject:   Re: UTP class 5 cabling, 25 pair, with telco-50 connectors

In article <seifertC5upAC.Byr@netcom.com> seifert@netcom.com (Rich Seifert) writes:
>From: seifert@netcom.com (Rich Seifert)
>Subject: Re: UTP class 5 cabling, 25 pair, with telco-50 connectors
>Date: Wed, 21 Apr 1993 20:37:24 GMT
>In article <id.OLGZ.I2H@nmti.com>, peter@nmti.com (peter da silva) writes:
>> We're working on some building wiring designs and have run into a problem:
>> there doesn't appear to be a source for UTP class 5 (for 100 Mb/s traffic)
>> in 25 pair bundles. Going to smaller bundles will mean we can't use Telco
>> 50 connectors, which radically complicates the wiring (we can't use stock
>> telco-50-RJ45 harmonicas and octopus cables, for example).
>> -- 
>
>That is correct. Category 5 is not available in 25-pair bundles. It is
>not possible to meet the crosstalk requirements in this configuration.
>
>
>-- 
>Rich Seifert                    Networks and Communications Consulting
>seifert@netcom.com              (408) 996-0922
>                                (408) 996-2860 FAX
>"... specialists in Local Area Networks and Data Communications systems"
There are some confusing and sometimes contradictory issues related to this. 
Many people have found that using the 50 connectors is unwise as it 
complicates problem determination and resolution when there is a problem. My 
impression is that there is a reasonable consensus that patch panels are 
more flexible and easier to troubleshoot. Even though vendors agree with 
this, they have come out with 50 connector products because it lets them get 
much higher densities on a card.
The typical vendor response to "what do we do since there are no 25 pair 
riser cables at category 5?" is to put electronics on each floor, and in the 
case of Ethernet, connect the floors with an FDDI riser backbone. There 
really is no other choice than putting electronics on every floor (or every 
3 floors if you can get away with it), although with Ethernet you'd 
interconnect by connecting all of the floor hubs to a master hub with a 
single 10BASE-T or 10BASE-FL connection. Some of the smaller, expandable hubs
available today (like the Synoptics 2313/2314 series) are cheap and flexible 
enough that you can afford to put electronics on every floor because the per 
port cost is so much cheaper than on the fullblown chassis. Also, if you are 
putting in Category 5 today to hedge against the future, but only need 
Ethernet speeds, you could use Category 3 or 4 riser to go down to a master 
concentrator, knowing that you'd abandon it and put electronics on every 
floor when you need the higher speeds in the future.
Richard M. Kogut,   Manager, Systems Services
                    Brown University Computing & Information Services

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 16:46:23 GMT
From:      pc123@cus.cam.ac.uk (Pete Chown)
To:        comp.protocols.tcp-ip,comp.security.misc
Subject:   Re: Encrypting IP data "transparently"???

In article <93112.082250ANDY@MAINE.MAINE.EDU> Andrew T. Robinson <ANDY@MAINE.MAINE.EDU> writes:

   The question:  Is there a product which allows the data portion of IP
   datagrams to be encrypted, leaving the headers alone for routing?  I.e.,
   "If the destination network is 255.255, then encypt the data portion
   with key FOOBAR."  On the receiving end, the product would reverse the
   process:  "If the origin network is 0.0, then decrypt the data portion
   with key FOOBAR."

I was wondering if you could do this sort of thing by fiddling the
routing tables.  Suppose you say that there is a SLIP connection
direct to network 255.255 (to use the above example), and you run
slattach to tell the kernel that the SLIP link is accessible via a
pty.  Then you have a process reading the pty, and it gets the raw
SLIP stream, which it can then encrypt and send to the remote end over
a normal IP connection.

The remote end, of course, does the opposite.  It decrypts what it
receives from the network, and puts it into a SLIP connection which is
attached to one of its ptys.  Thus you are tunneling encrypted IP
through IP.

I don't expect this would work at all well with high bandwidths, but
it might work on a small scale.

   PLEASE REPLY DIRECTLY TO ANDY@MAINE.EDU

I'm replying here because this is just a discussion point, and I
haven't really answered the question posed.
--
---------------------------------------------+ "A tight hat can be stretched.
Pete Chown, pc123@phx.cam.ac.uk (Internet)   |  First damp the head with steam
            pc123@uk.ac.cam.phx (Janet :-)  -+  from a boiling kettle."

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 17:03:26 GMT
From:      dwight@rock.concert.net (Dwight Frye -- Systems Development Group)
To:        comp.protocols.tcp-ip
Subject:   What/Where is 'rtelnet'?

Ok .. I have gotten some pointers on how to solve my problem of wanting
to create an entry in /dev that a process could open and it would make
an outbound connection. 
 
The suggestion sent to me was one received by him from Sun when he was
trying to do the same thing with the goal being to connect a serial
printer to a terminal server port. The information FAXed to him was as
follows :
 
        With a Sun terminal server (Xylogics made) you could use reverse
        telnet to connect the terminal server port to a /dev file on the
        printer server.  For example, if your printer is on TS port 11,
 
		rtelnet -r term_serv 11 /dev/serial11

	From then on you just refer to /dev/serial11 and follow normal serial
	procedures, ie put it in /etc/printcap and the like.

Now, this sounds all well and good but neither the person who sent me 
this teasing bit of information or I could _find_ rtelnet on our system.

Can someone either point me to this mythical beast or help me with yet
_another_ solution? :)

Thanks.

--
Dwight Frye
dwight@rock.concert.net

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 17:19:59 GMT
From:      jcarroll@Scotia-McLeod.Com (Jim Carroll)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: finger client or hack

In article <odin.17.0@macc.wisc.edu> odin@macc.wisc.edu (Odin J. Anderson) writes:
>I need access to finger services (ala port 79), but I'm using Novell's 
>LWP and can't find any clients.  Does anyone know were I could find such a 
>client or a way to hack into port 79 and get the info?

I'm not certain, but there may be a way to piggyback Beame & Whiteside's
clients onto LWP4.0.  Best lead I can give is sales@bws.com.

Hope this helps.

-- 
Jim Carroll                   | "Big fleas have little fleas,
ScotiaMcLeod Inc., Toronto    |  upon their backs to bite 'em,
Ontario, Canada               |  and little fleas have lesser fleas,
jcarroll@Scotia-McLeod.Com    |  and so, ad infinitum."

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 17:37:55 GMT
From:      blrohler@kocrsv01.delcoelect.com (Brian L. Rohler)
To:        comp.protocols.tcp-ip
Subject:   pctcp printing (lpr) from windows to HP425e




Be nice. This is the first article (request) I have posted. Actually,
I have only been connected for a few weeks. I do, however, enjoy the
info. exchange and the expertise available. Enough chatting, to the
real question at hand.........

        I have a handful of pc's (compaq's,hp vectras, AST,...) and four
HP425e workstations. I want to use my workstation (425e) as the print
spooler for all of the pc's. It already spools for the other
workstations.
        Changing the pctcp.ini file (on pc) allowed the pc's to print
from dos but from windows, a "line to long" error is generated. It
seems like the driver interprets the carriage return instead of
leaving it as part of the file being printed.
        I would appreciate any and all help on this matter. I don't
like using Buffalo boxes (too slow). Spooling to my workstation frees
up the pc's a lot quicker.

Thanks in advance for any help.


Brian L. Rohler
Forward Development (SIR)            MS:A252
Manufacturing Engineering            Kokomo, IN 46902
Delco Electronics Corp.              GM FAX: 8-322-2061
DE PH.: 317-451-2143                 DE FAX: 317-451-2061
INTERNET: blrohler@kobcic02.delcoelect.com     

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 17:40:16 GMT
From:      heimlich@watson.ibm.com (Steve Heimlich)
To:        comp.protocols.tcp-ip
Subject:   Re: How does the NFSNET know the route to my IP address?

In article <k2.735481007@woodstock> k2@bl.physik.tu-muenchen.de (Klaus Steinberger) writes:
>fred_s@netcom.com (Frederick Scott) writes:
>
>>stewart@oin.cis.udel.edu (John Stewart) writes: 
 
>>>In article <1qgd1kINN50o@cronkite.cisco.com> tli@cisco.com (Tony Li) writes:
>>>>In article <1qffbp$nui@spock.dis.cccd.edu> markb@cccd.edu writes: 
 
>>It was my understanding that the core gateways (and I'm not at all sure
>>there's suppose to be that many of them) used their own routing protocol.
>>(CGP or something like that.)  The internal and external protocols mentioned
>>above aren't really that suitable, as the core gateways need to rapidly
>
>I remember a talk at InterOP Fall 91, where a guy from ANS talked about
>the NSF Core, and he said, they use Dual IS-IS.
>(IS-IS routing protocol in dual mode supports ISO-IP as well as Internet-IP)
>Maybe the situation has changed since then, but I don't know.
>
>Sincerely,
>Klaus Steinberger

ANS currently uses a precursor to the current IS-IS which is based on an ANSI
document dated 1987 I believe.  

It also uses BGP and EGP for exterior routing (currently in conjunction
with internal BGP).

Steve

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 18:15:35 GMT
From:      vaf@Valinor.Stanford.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   Port numbers for WAIS and Archie?

Can someone tell me what the TCP or UDP port numbers used by the WAIS and Archie
servers are? Also, if either of these are UDP services, are their any specific
source ports that a client is expected to use?

	Thanks,
	--Vince

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 93 18:16:06 GMT
From:      connolly@labiche.laas.fr (Tom Connolly,,)
To:        comp.protocols.tcp-ip
Subject:   Simple transaction processing question

I have recently read something (an RFC) discussing transaction processing 
over a TCP connection which states that a separate connection must be opened
for each transaction.  

Could someone give me a quick explanation of why the same connection
between two hosts can't be used for multiple transactions.  

thanks





-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 93 20:31:26 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.dcom.sys.cisco
Subject:   Re: Routers, SMDS and RFC1209

In article <1993Apr21.155949.19075@kentrox.com> mwitt@kentrox.com (Michael Witt) writes:
>
>I am trying to gather information on the use of routers over SMDS
>networks.  Specifically, I am interested in finding out if router
>manufacturers are planning to follow RFC 1209, when forwarding IP
>traffic over SMDS links.  If so, I would be very interested in having
>a short dialogue with someone who could tell me the details of how
>this will work in specific router implementations.

Most routers vendors that I know of (including us) follow RFC-1209
for IP over SMDS.  I can certainly talk about how we implemented it.

Art

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Apr 1993 23:20:04 GMT
From:      hughf@algol.csis.dit.csiro.au (Hugh Fisher)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address

Ian Phillips writes:
 
> There are more IP addresses available than the toaster population of the
> earth :-)

and Phil Royse followed up with:

>I believe that Class C addresses will cope for longer than you think.
> 
>I also don't think that the shortage of Class B address space, nor the
>inconvenience problems of "chunks-of-Class-C" will diminish the massive
>growth of sales of TCP/IP/NFS etc. products.

  For those who are really interested, subscribe to the big-internet
  mailing list (big-internet-request@munnari.oz.au). If I've followed
  the discussions on that list correctly, the real problems with IP
  are:

  1) While there are in theory 4 billion odd IP addresses, the byte
  boundaries on the classes mean that a lot get wasted (estimates of
  actual usage vs allocation are around the 1% mark)

  2) Since there aren't enough class B nets around, many organisations
  have to get clumps of class C...and _each_ of these class C nets
  has to be entered in the backbone routing tables. It is more the
  routers that are on the point of collapse rather than the network
  address space.

	Hugh Fisher


-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Apr 1993 09:05:05 GMT
From:      weber@rhrk.uni-kl.de (Christoph Weber-Fahr [KIT])
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: finger client or hack

jcarroll@Scotia-McLeod.Com (Jim Carroll) writes:

>In article <odin.17.0@macc.wisc.edu> odin@macc.wisc.edu (Odin J. Anderson) writes:
>>I need access to finger services (ala port 79), but I'm using Novell's 
>>LWP and can't find any clients.  Does anyone know were I could find such a 
>>client or a way to hack into port 79 and get the info?
 
>I'm not certain, but there may be a way to piggyback Beame & Whiteside's
>clients onto LWP4.0.  Best lead I can give is sales@bws.com.

Sorry, but there IS a finger client I found somewhere.
Have you lokked at sjf-lwp.novell.com ? I don't know for sure where I got 
it from, but If you don't find it somewhere, maybe I can upload it to an ftp
site.

Regards

Christoph Weber-Fahr


-- 
  Christoph Weber-Fahr                  |  E-Mail:  weber@rhrk.uni-kl.de 
  Universitaet Kaiserslautern,  KIT     |  S-Mail:  Postfach 3049
  Tel. 0631/205-3391                    |           D-6750 Kaiserslautern
--------------------------  My personal opinion only    ---------------------

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Apr 1993 09:18:50 GMT
From:      jos@bull.nl (Jos Vos)
To:        comp.protocols.tcp-ip
Subject:   Re: REMOTE PRINTING USES 4K NULLS TRAILER

jel@tuura.icl.fi (Jerry Lahti) writes:

>sgccmtm@citec.oz.au (Michael McKeon) writes:
 
>>	We use (3-COM BRIDGE) terminal servers to allow printing from multiple
>>	unix machines, each printer is assigned a port on a terminal server
 
>>	IS THERE ANY WAY THAT TCP/IP WILL ALLOW THE FULL TRANSMISSION OF
>>	DATA TO THE TERMINAL SERVER WITH-OUT THE USE OF PADDING WITH 4096
>>	NULLS.
 
>Not really.  As far as I know, the need for padding is caused by
>a 'feature' in the 3COM boxes: apparently they tend to discard at least
>part of the buffered data immediately when the network connection
>closes, instead of waiting for it to drain out of the serial port.
>Since TCP connections are supposed to be reliable, 'tcpsend' cannot
>do much else than send enough padding so that the real data has time
>to make it out of the serial port.  However, 3COM might have new
>software/firmware versions which eliminate this 'feature'.

I've connected terminal-servers of several different vendors 
to UNIX systems in this way, and they all needed the padding nulls.

Looks like they all use the same firmware :-)
That might be the reason that they all have an almost
uncomprehensible interface for configuring the box...

-- 
--    Jos Vos <jos@bull.nl>   (UUCP: ...!{uunet,mcsun,sun4nl}!nlbull!jos)
--    Bull Netherlands, Professional Services, Amsterdam, The Netherlands

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Apr 1993 09:32:39 GMT
From:      Thomas.Tornblom@Nexus.Comm.SE (Thomas Tornblom)
To:        comp.protocols.tcp-ip
Subject:   Re: REMOTE PRINTING USES 4K NULLS TRAILER

In article <C5qB6r.Anz@tuura.icl.fi> jel@tuura.icl.fi (Jerry Lahti) writes:

   sgccmtm@citec.oz.au (Michael McKeon) writes:

   >Pre-Amble
   >	We use (3-COM BRIDGE) terminal servers to allow printing from multiple
   >	unix machines, each printer is assigned a port on a terminal server
 
   >	IS THERE ANY WAY THAT TCP/IP WILL ALLOW THE FULL TRANSMISSION OF
   >	DATA TO THE TERMINAL SERVER WITH-OUT THE USE OF PADDING WITH 4096
   >	NULLS.

   Not really.  As far as I know, the need for padding is caused by
   a 'feature' in the 3COM boxes: apparently they tend to discard at least
   part of the buffered data immediately when the network connection
   closes, instead of waiting for it to drain out of the serial port.
   Since TCP connections are supposed to be reliable, 'tcpsend' cannot
   do much else than send enough padding so that the real data has time
   to make it out of the serial port.  However, 3COM might have new
   software/firmware versions which eliminate this 'feature'.

If the terminal server support the telnet option TIMING MARK properly
this can be used to assure that all data has left the terminal server
before closing the connection.

We have a software product for using terminal servers as printer
servers and it uses TIMING MARK if the terminal server can handle it,
otherwise we're stuck with using padding.

Thomas
--
Real life:      Thomas Törnblom           Email:  Thomas.Tornblom@Nexus.Comm.SE
Snail mail:     Communicator Nexus AB     Phone:  +46 18 171814
                Box 857                   Fax:    +46 18 696516
                S - 751 08 Uppsala, Sweden

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 93 11:52:30 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: How the tunnel work of IP Multicast ....


 >    The multicast router modifies the packet by appending an IP Loose Source
 >    Route option to the packet's IP header. The multicast destination address
 >    is moved into the source route, and the unicast address of the router at
 >		      ^^^^^^ ^^^^^
 >    the far end of the tunnel is placed in the IP Destination Address field.
 >    Thus, normal unicast routing carries the packet to the other end of the
 >    tunnel where the multicast router restores the original multicast
 >    destination address and deletes the source route before forwarding the
 >    packet."
 >   --> Since I still confuse above words, I want to know how multicast IP
 >       modify the IP header?	 [ Forgive me if I am so ....fool... :-)  ]
 >   --> what is source route?	 [ I can't find its means from my all book...]
 
IP Multicast used the IP Option for Loose Source Routeing to 'tunnel'
packets addressed to a class D destination through routers that didnt
implement the multicast extensions.  LSR is described in rfc791:
"
     0     3     var.  Loose Source Routing.  Used to route the
                          internet datagram based on information
                          supplied by the source.
"


LSR was chosen because it was opriginally regarded as less burdon on
router processing than the bandwidth overhead of the newer technique:

now some people perfer to implement IP encapsulation in IP, where the packet 
to a class D destination that has members the far side of 1 or more hops of
non-multicast extended routers is put inside another IP header with
the destination in the outer header set to that of the next hop
multicast capable router...

this is not formally described yet to my knowledge (anyone can correct
me!)

 jon


-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Apr 1993 12:08:05 +0000
From:      steve@one47.demon.co.uk (Stephen R Davies)
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.sys.novell
Subject:   Re: Network load queries

Hi,

I thought I'd post this query here as a starting point, as it's
usually the case that there is sufficient "expertise" locally
to answer most queries. Please feel free to point me at a better
destination for this query. Here goes then:

The company I work for (Trebor Bassett Limited) is planning
the installation of a wide area network, and expanding the existing
local area network. This will involve two 'main' offices which will
probably be linked by a 64K Kilostream link due to the fact that
administrative and considerable file-transfer functions will be
carried out over them. The hosts at these locations will be 
IBM RS/6000s and Compaq 486 Novell file-servers on both Mixed-
Ethernet and Token-Ring (IBM Type 1 and Fibre)

Connected to the southern site will be two manufacturing offices,
the traffic from which will mostly be keystrokes/screen updates
with the occasional file transfer, print job etc. There will be a
small admin. overhead occasionally, and we expect there to be no 
more that about 15 users per-site at any time. Protocols in use 
will be TCP/IP, IPX/SPX and perhaps encapsulated SNA or SAA traffic.
Any use over and above this will be given a low-priority so as
not to interfere with this 'normal' traffic.

The northern site is similar, but will have four incoming lines,
which will feed into a fibre-optic setup.

The questions are: are we right to choose 64K between the main 
offices, and what sort of link do we need from the sites. It's been
suggested that a 19.2K line with data-compressing bridges may suffice,
but data-compressing bridges follow no-known standard, so do we want 
to be tied to them ?

Any hints or suggestions are welcome !

Steve.
=====================================================================
Email to : steve@one47.demon.co.uk                      Steve Davies
       Whats a wordprocessor ? Well, you've seen what a food
                     processor does to food...
---------------------------------------------------------------------

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Apr 1993 12:26:17 GMT
From:      hoang1@litwin.com (Ted Hoang)
To:        comp.protocols.tcp-ip
Subject:   RFC 1122

Hi,
Could someone tell me where and how to get RFC 1122?

Thank in advance,
Ted Hoang
Email:hoang1@dynsim1.litwin.com



-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 1993 13:42:35 GMT
From:      steve@jackson.larc.nasa.gov (steve comer)
To:        comp.protocols.tcp-ip
Subject:   FAQ

Is there any FAQs for this newsgroup.

			Thanks
				Steve
			steve@jackson.larc.nasa.gov




-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 93 14:25:32 GMT
From:      pmfranc@afterlife.ncsc.mil. (Paul M. Franceus)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP through a Router?

In article <fred_sC5vKwt.GL7@netcom.com> fred_s@netcom.com (Frederick Scott)  
writes:
> tli@cisco.com (Tony Li) writes: 
> 
> >RARP is an unroutable protocol.  It must be bridged.
> 
> More specifically, I believe RARP is a *broadcast* protocol (at least the

Actually, the first poster was correct.  ARP/RARP is not an IP based protocol,
and therefore not routable.  You need to have a RARP server located on the 
same logical network segment (only separated by bridges and repeaters) as
the thing that is trying to RARP it's address.

Paul

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Apr 1993 14:40:32 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Traffic Analysis (was Re: Sniffer)

In article <C5uL19.5xK@ngc.com> harrys@ngc.com (Harry Saal) writes:
>   My interest has been piqued: basically what did you want the 800 Mbytes of
>   LAN traffic for? What was the analysis you performed? 24 hours of raw
>   packet data is a lot!

One of the reasons I do this is to learn more about traffic patterns.
Many people develop simulations of network traffic, and the models
have not been validated with actual traffic.

I analyzed the traffic on our local ethernet segment, and reported the
results in the 17th LCN conference. The paper was called "High Level
Analysis of a LAN segment". 

I have also analyzed medical networks. I presented a paper at the '93
SPIE conference of Medical Networks. In particular, I examined the
traffic at UCLA. In this case I found some interesting results.  One
of the things I characterized was the timing of image transfers
between two Suns. It may not have been a typical day. In fact, some
images were being sent to a host over the wrong network the day I
measured the activity. Given those cautions, The numbers I got were:
(all timing rounded to milliseconds)

	Delay between two packets of a transmit buffer (No PSH flag): 
		under 2 msec.
	Delay after a transmit buffer (PSH Flag) : under 8 msec
	Delay after a missed packet: Average of 787 msec
	Delay after a receive buffer is filled: not significant

	There were 43 cases of large image transfers. (Ave. 3.5 MBytes)
	Average Transfer Rate: 164.3 KBytes/sec.

	The most interesting thing I found was typically 50% of the
transmission time was caused by missed packets (packets sent but not
seen by the receiver).  There was an average of 13 dropped packets per
image transfer.  As an example, a 20 second transmission of an image
had 10 seconds of timeouts. If the problem of the dropped packets was
fixed, UCLA could half the transmission time.

The paper presented the information in the forms of histograms. I
regret having to reduce this to a simple number.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 1993 12:32:53 +0200
From:      szymon@galaxy.uci.agh.edu.pl (Szymon Sokol)
To:        comp.protocols.tcp-ip
Subject:   Re: What/Where is 'rtelnet'?

Dwight Frye -- Systems Development Group (dwight@rock.concert.net) wrote:

: Now, this sounds all well and good but neither the person who sent me 
: this teasing bit of information or I could _find_ rtelnet on our system.

We got rtelnet for Sun together with our Lantronix ETS-16 terminal server.
-- 
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

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 93 16:03:56 GMT
From:      markh@ohsu.edu (Mark Hashiguchi)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: finger client or hack

In article <odin.17.0@macc.wisc.edu> odin@macc.wisc.edu (Odin J. Anderson) writes:

>I need access to finger services (ala port 79), but I'm using Novell's 
>LWP and can't find any clients.  Does anyone know were I could find such a 
>client or a way to hack into port 79 and get the info?


>Odin
 
>--                    Odin J. Anderson                       --
>Information Processing Consultant, U.W. Hospital and Clinics   
>Dept. of Information Systems       INTERNET: odin@macc.wisc.edu
>3330 University Ave. Suite 300     UWHC MHS E-MAIL:  oja@spinet
>-- Madison, WI  53705                  PHONE: (608) 263-8434 --

Try apps.zip and wattcp.zip at dorm.rutgers.edu or ftp 128.6.18.15.
cd pub/msdos/wattcp.

This is in transition from sunee.uwaterloo.ca. You want to try sunee if 
apps.zip hasn't moved already.

Mark Hashiguchi | Network/Applications Specialist  
Oregon Health Sciences University | Phone:  (503) 494-7582 

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 1993 14:29:26 +0100
From:      heading@signal.dra.hmg.gb (Anthony J.R. Heading)
To:        comp.sys.acorn,comp.sys.hp,comp.protocols.tcp-ip
Subject:   Acorn/HP TCP-IP bug

This is a peculiar bug. I'd like a fix, and I'm not sure
whether the problem is already known, but since it's taken
me a while to track down, it seems worth reporting it.

We have an HP printer which starts up using bootp, responded
to be an HP workstation which broadcasts a bootp reply on
port 68. The Acorn Archimedes machines, running what might
be fairly old IP software, appear to pick up on this reply,
and set *their* IP address to be that of the printer. This, as
one might expect, causes some confusion.

rfc1048 seems to leave some freedom for vendor extensions, so
it's possible that it is some unfortunate interaction between the
two implementations, rather than just a straight Acorn bug.

Has anyone run into this before?

Anthony Heading

Defence Research Agency, UK
heading@signal.dra.hmg.gb


-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Apr 1993 16:47:37 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address

hughf@algol.csis.dit.csiro.au (Hugh Fisher) writes:
}Ian Phillips writes:
}> ...more IP addresses available than the toaster population of the earth :-)
}and Phil Royse followed up with:
 
}>I believe that Class C addresses will cope for longer than you think.
 
}>I also don't think that the shortage of Class B address space, nor the
}>inconvenience problems of "chunks-of-Class-C" will diminish the massive
}>growth of sales of TCP/IP/NFS etc. products.
 
}  For those who are really interested, subscribe to the big-internet
}  mailing list (big-internet-request@munnari.oz.au). If I've followed
}  the discussions on that list correctly, the real problems with IP are:
 
}  1) While there are in theory 4 billion odd IP addresses, the byte
}  boundaries on the classes mean that a lot get wasted (estimates of
}  actual usage vs allocation are around the 1% mark)

    Yup, in particular most "class A" networks (each ~ 1/2% of the total
    space available) are a huge waste of address space (for example, how
    close do you think Stanford is to using up their 16 million addresses?).

}  2) Since there aren't enough class B nets around, many organisations
}  have to get clumps of class C...and _each_ of these class C nets
}  has to be entered in the backbone routing tables. It is more the
}  routers that are on the point of collapse rather than the network
}  address space.

     Hopefully, "CIDR" (a technique for having the backbone routers
     treat the clump-o-C's as a single route) will limit the routing
     growth long enough for a more complete solution.  However this
     only keeps the growth rate of routes the same as if we had
     plenty of B's available (which is still a doubling every year
     as I recall?).  Also note that there are only half as many
     C's as B's, so using the C's like this only adds a short
     breather.

     It's rather like the old story, where you put 1 grain of sand
     on the first square of a chessboard, and 2 on the second and
     4 on the next, and 8, ... goes pretty slow at first, but if
     you look a little ways ahead you can see the dumptruck bearing
     down on you.

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

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Apr 1993 17:12:39 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Traffic Analysis (was Re: Sniffer)

In article <BARNETT.93Apr23094032@grymoire.crd.ge.com>, barnett@grymoire.crd.ge.com (Bruce Barnett) writes:
> ...
> 	The most interesting thing I found was typically 50% of the
> transmission time was caused by missed packets (packets sent but not
> seen by the receiver).  There was an average of 13 dropped packets per
> image transfer.  As an example, a 20 second transmission of an image
> had 10 seconds of timeouts. If the problem of the dropped packets was
> fixed, UCLA could half the transmission time.


Some of our customers have been complaining about the same kinds of
things on junk networks.  They complain that a lost TCP segment that is
not caught by the new fast retransmission stuff means the wire will be
quiet for about 1 second.  (Well, they don't say exactly that, but they
would if they understood and could interpret what they see on their
ethernet analyzers as well as they think they can.)


My response is always "fix your network.  you can't expect reasonable
performance if your network loses any packets at all, and certainly
not with 5% loss rates."

Their counter is "reduce your TCP timeouts" (and often other nonsense
like "implemement read-ahead", but never mind the nonsense.)

My counter to that is "2 Hz and 5 Hz are the classic BSD values, and
we wouldn't want to be non-standard"

Their responses are polite or impolite expressions of incomprehension.


Still, given that PR_SLOWHZ and PR_FASTHZ have not probably not changed
since 1 MIPS was a big deal, I wonder if we shouldn't change run things
4 or 16 times faster?  Leave the timers at the same values, but get
some more resolution?


Vernon Schryver,  vjs@sgi.com

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 93 17:27:15 GMT
From:      martinh@cac.washington.edu (Martin Hunt)
To:        comp.windows.x.apps,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Announcing tcpview: A Motif-based TCP/IP protocol analyzer


Tcpview is the result of several problems we had at UW.  We have several
Network General Sniffers which are heavily used to help debug problems on
several hundred subnets. These are good tools, but they are 1) heavy, 
2) hard to find when you need one, 3) limited in their software expandibility,
4) difficult to use to upload data for analysis, 5) cannot be remotely
operated, and 6) cannot resolve names with DNS, requiring much manual 
manipulation of the name table.  We also sometimes use tcpdump, but we found 
it 1) too difficult for most people, 2) did not have enough information for
many protocols, 3) could not be used interactively, 4) could not handle
TCP streams and 5) could not read Sniffer files.  However, tcpdump did do
a reasonable job of decoding a large number of protocols, and could be easily
modified.  Tcpview is an attempt to resolve these problems
by adding a Motif interface to tcpdump and expanding its features.

Tcpview has been tested on a DECstation 5000 and Sun 4 under Ultrix 4.2 and
SunOS 4.1 respectively.  It should work on the same systems as tcpdump.
It compiles with cc and gcc on the DEC and Sun.  To build tcpview you will
need Motif 1.1 or better.

The following files are available for anonymous ftp from 
ftp.cac.washington.edu in /pub/networking

tcpview-1.0.tar.Z	tcpview and tcpdump source code
tcpview-1.0.sun.tar.Z	Sun4 binaries
tcpview-1.0.dec.tar.Z	DEC Mips Ultrix 4.2 binaries

What tcpview adds to tcpdump:
- easier interface
- enhanced protocol decoding
- hex display of frame
- capture based on time, number of frames, or user interrupt
- can show ethernet addresses with manufacturer's name
- ethernet address host table
- can easily follow a stream, highlighting out-of-order frames
- can send TCP data to an external file or filter for additional
	processing.

-------------------------------------------------------------------------------
CHANGES TO TCPDUMP 2.2.1

New features:

Now reads and writes Network General Sniffer files.  When used with '-r', the 
file type will be automatically detected.

Can now read in (and use) an SNMP MIB file.

The hex format has been changed.

New time options have been added.

Options were added to allow viewing and processing of the data in TCP packets.

Bugs were fixed in the relative TCP sequence numbers. (-S flag)

New flags:
-R	read Sniffer file.  Not usually needed, except for reading from stdin
-ttt	prints delta times
-tttt	prints times relative to the first frame
-W	write a Sniffer save file (use with -w)
-x	print frame (minus link-level header) in hexdump format.  
	Sample output:

16:36:23.349851 jeff.cac.washington.edu.1285 > nic.funet.fi.ftp: S 0:0(0) win 16384
        0000  45 00 00 28 8a 98 00 00 3c 06 7c 9c 80 5f 70 02   |  E..(....<.|.._p.
        0010  80 d6 06 64 05 05 00 15 5b 19 4a 00 00 00 00 00   |  ...d....[.J.....
        0020  50 02 40 00 4e 13 00 00 00 00 00 00 00 00         |  P.@.N.........

-X	print TCP data in hexdump format (used with -Z)
-z	write TCP data to stdout (use with -t to eliminate timestamp)
-Z	write frames and TCP data to stdout


Martin M. Hunt
martinh@cac.washington.edu
Networks & Distributed Computing
University of Washington








--

-------------------------------------------------------------------------------
Martin Hunt                            martinh@cac.washington.edu   
Networks and Distributed Computing     University of Washington		  

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Apr 1993 17:40:32 GMT
From:      jeff@spot.Colorado.EDU (Jefferson W. Christy)
To:        comp.protocols.tcp-ip
Subject:   Looking for OSPF for unix

Does anyone out there in netland know of a routing daemon that
I can compile in a unix environment that speaks OSPF?  I am 
looking into having a sun act as a router for a subnet in a 
large network where the dedicated routers will be using OSPF.
			Thanks in advance,
			Jeff

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Apr 1993 18:00:55 GMT
From:      mromano@world.std.com (Martin Romano)
To:        comp.protocols.tcp-ip
Subject:   how to assign port number

I'm working on an application which may benefit greatly from having
a "well known" port number. How might I go about getting such a number
assigned so as to avoid conflicts? 
-- 
Martin Romano    |    mromano@world.std.com    |    (617) 693-5671

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 1993 18:39:40 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   High-error TCP (was Re: Traffic Analysis (was Re: Sniffer))

In article <hfek250@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>My response is always "fix your network.  you can't expect reasonable
>performance if your network loses any packets at all, and certainly
>not with 5% loss rates."

Speaking of which...

Has anyone looked into running TCP over high-error-rate connections?
I'm dealing with some error-prone (1-5% packet loss) SLIP links that
can't really be improved, and I'd like to figure out if there are known
optimizations for TCP that improve performance over such links.

I _have_ concluded that Jacobson/Karel congestion control and avoidance
is bad on such links, because those algorithms assume that a dropped
packet is the sign of congestion.  Sometimes a dropped packet is
nothing more than a dropped packet.

Suggestions or pointers to references would be welcome.  About all I've
found so far is fast retransmission, documented so thoroughly in the
BSD source.  :-)

     Stephen

-- 
Stephen Trier                     Work: trier@ins.cwru.edu
Network Software Engineer         Home: sct@po.cwru.edu
IRIS/INS/T
Case Western Reserve University

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Apr 1993 19:19:45 +0000
From:      dave@llondel.demon.co.uk (David Hough)
To:        comp.protocols.tcp-ip
Subject:   Re: FAQ

In article <1r8robINNkum@rave.larc.nasa.gov> steve@jackson.larc.nasa.gov writes:
> Is there any FAQs for this newsgroup.
> 
> 			Thanks
> 				Steve
> 			steve@jackson.larc.nasa.gov
> 
> 
> 
Isn't this a FAQ ? Shouldn't the answer be in the FAQ file ;-O

*****************************************************************************
* G4WRW @ GB7WRW.#41.GBR.EU AX25     *    Dictionary entry                  *
* dave@llondel.demon.co.uk  Internet *    Recursion: see recursion          *
* g4wrw@g4wrw.ampr.org      Amprnet  *                                      *
*****************************************************************************
PS Sorry Steve, its been a long, hard week

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Apr 1993 19:43:42 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: how to assign port number

In article <C5y7DL.7tC@world.std.com>, mromano@world.std.com (Martin Romano) writes:
> I'm working on an application which may benefit greatly from having
> a "well known" port number. How might I go about getting such a number
> assigned so as to avoid conflicts? 


Besides writing an RFC or otherwise convincing Those In Charge,
there are 2 other common schemes:

    1. use tcpmux, as described in RFC-1078 and implemented on at
	least some commerical UNIX boxes.

    2. get one of the 2**32 Sun RPC numbers and use the portmapper
	to allocate one of the 2**16 TCP port numbers dynamically.


Vernon Schryver,  vjs@sgi.com

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 93 20:40:09 GMT
From:      shuenn@tora.swdc.stratus.com (Shuenn Hwang)
To:        comp.protocols.tcp-ip
Subject:   enet port on a server

Hi,
	Does anyone compiled or knew how many enet port should a
enet network server host has? I saw our file server here has like
6 enet ports. Is it a function of the server disk size? Like
may be 500 M of disk space should have one enet interface that,
if you have 2 giga, you should have four enet ports. What criteria
does people favor? I'll compile and publish it on the net on my
finding if there is some interests on this.

Thanks,

shuenn hwang

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 1993 20:59:11 GMT
From:      djudy@djudy.East.Sun.COM (Dennis Judy-Sun-Vienna VA-Commercial SE)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet monitoring software wanted.

Has anyone seen any performance comparisons between ethernet and tokenring with TCP/IP?
PC's, workstations, minis whatever.
Dennis


-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Apr 1993 21:13:15 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: Traffic Analysis (was Re: Sniffer)

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

>   My response is always "fix your network.  you can't expect reasonable
>   performance if your network loses any packets at all, and certainly
>   not with 5% loss rates."

But what causes this problem? I do not know what happened at UCLA. I
am sure they don't. It might be a bridge. It might be the receiver is
overloaded. How does a customer find out where the packet is dropped?
And how do you measure/detect this case?

I did it by examining the sequence numbers, and detected when they
slipped backwards. This requires remembering the previous sequence #
associated with those ports between those two systems. Maybe newer
network analyzers do this. The ones I used didn't. 

How does a customer detect this? netstat -i doesn't seem to.
But maybe I'm wrong. All the manual page says is that it displays
input and output "errors". That's a lot of help (sarcasm-mode:on).

>   Still, given that PR_SLOWHZ and PR_FASTHZ have not probably not changed
>   since 1 MIPS was a big deal, I wonder if we shouldn't change run things
>   4 or 16 times faster?  Leave the timers at the same values, but get
>   some more resolution?


I think there is some merit to this. Certainly a vendor who handled it
better could have better performance.  Normally machines on Ethernet
respond much faster that 500 msec. Some systems also do what I believe
is called agressive ACKing. That is, if the receiver on the same
ethernet sends back the same ACK value twice, the sender realizes the
receiver missed a packet.


--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Apr 1993 21:38:32 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: finger client or hack

In article <MfplXp30BwwbQDwhQx@transarc.com>, Lyle_Seaman@transarc.com writes:
> Finger just uses the telnet protocol.  I don't know about Novell's
> telnet client, but the BSD telnet will let you specify a port number:
> 

	This isn't technically true. The telnet client you're using doesn't
use (like most don't) the TELNET protocol when you specify an alternate
port. The finger protocol, described in RFC 1288, is simple in the ordinary
case (send "user\r\n" for information about "user"), and if your telnet
client gives you a straight, uninterpretted connection to alternate ports,
it works. But if it used the TELNET protocol, it wouldn't...
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Apr 1993 21:39:59 GMT
From:      db3l@ans.net (David Bolen)
To:        comp.protocols.tcp-ip
Subject:   Re: NSF backbone routing

In article <1993Apr23.234537.3367@cs.aukuni.ac.nz> rale1@cs.aukuni.ac.nz (Ross Douglas Alexander ) writes:

>These are network addresses, not including hosts so around 70K to 200K hosts.

And in reality we now currently see peaks above 8k networks in the
active routing tables on the backbone.

>>     T1 backbone dismantling activities continued in February, and will
>>     be completed in March.
>
>I nice piece of history.

Note that the "dismantling" referred to here represents the physical
dismantling and shipping of the old T1 NSS (RT) equipment.  The
T1 network was officially turned off as far as carrying any traffic
early in December, 1992 (12/2 I believe).

>Just some useless statics.  I looks like the NSF backbone is using CIDR
>(classless inter domain routing) using Autonomous System Numbers (AS).
>Policy based routing and class C address aggragation is also done using
>Border Gateway Protocol version 4 (BGP-4).

Most of this is future-tense (albeit near future).  The ANSnet
backbone does not currently support CIDR addresses in its routing
tables or protocols.  To do so requires (a) on-card support for the
installation of CIDR routes, and (b) protocols (ie: BGP4) to carry
and exchange those routes with border routers on other CIDR-aware
networks.

Both of these features are in development and should be available in
the near future.  On-card CIDR support will be supplied as part of the
second update to the AIX 3.2 software, and the development of BGP4 as
part of Gated (which will be deployed following AIX 3.2) will provide
the necessary routing protocol support.

Of course, the actual use of CIDR routes within the network carries a
number of issues beyond simple support of such routes by a single
backbone provider.  Much of this is currently being discussed in such
forums as the BGP Deployment group of the IETF.

--
-- David
--
/-----------------------------------------------------------------------\
 \              David Bolen             \  Internet: db3l@ans.net      /
  |   Advanced Network & Services, Inc.   \   Phone: (914) 789-5327   |
 / 100 Clearbrook Road, Elmsford, NY 10523  \   Fax: (914) 789-5310    \
\-----------------------------------------------------------------------/

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Apr 1993 22:05:12 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: Traffic Analysis (was Re: Sniffer)

In article <BARNETT.93Apr23161315@grymoire.crd.ge.com>, barnett@grymoire.crd.ge.com (Bruce Barnett) writes:
> In article <hfek250@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> 
> >   My response is always "fix your network.  you can't expect reasonable
> >   performance if your network loses any packets at all, and certainly
> >   not with 5% loss rates."
> 
> But what causes this problem? I do not know what happened at UCLA. I
> am sure they don't. It might be a bridge. It might be the receiver is
> overloaded. How does a customer find out where the packet is dropped?
> And how do you measure/detect this case?

There is no single problem.  There are more problems then there are
networks.  Families of problems I have seen include:

    1. bridge/hub congestion and bugs.
	A lot of bridge/hubs like to drop packets.  Sometimes they
	delay packets for up to several seconds (!) before they start
	dropping.  Others or at other times they drop packets out of
	bursts for no apparent reason.  I know of theoretical
	justifications for bridge/hubs, but so far I have not met a
	single real case where a bridge/hub did anything but trash the
	ethernet, justify hiring more administrators, and make a lot of
	money for salesslime.

	My favorite diagnostic for junk bridge/hubs is
	`ping -f -s 3000 host`, using a fairly recent, 4.3BSD style
	ping.  If I see >= 1% packet losses (out of 100's or 1000's),
	and especially if `ping -f host` is ok, I start looking for junk
	bridge/hubs to reset.  Resetting often "cures" them, for a while.

	Bad brige/hubs are particularly irritating to find because
	they are "invisible."  It is difficult to convince their
	sponsors that they can cause problems.  You can prove them to
	be at fault by ping`ing between many different pairs of
	stations, or by tripping over the right power cords.

    2. junk wires
	late collisions, CRC errors, etc.

    3. bad twisted pair hubs.
	The new boards (new as of ~2 years ago) of one popular brand of 
	hub cannot be chained together without misteriously eating 
	packets.  (Please do not ask me which brand.)

    4. PC ethernet cards
	We all know about this.  
	Try `ping -s 10000 host` (no -f) to test for this.


>                                ... Some systems also do what I believe
> is called agressive ACKing. That is, if the receiver on the same
> ethernet sends back the same ACK value twice, the sender realizes the
> receiver missed a packet.

Could this be what is commonly known as "fast retransmission"?


Vernon Schryver,  vjs@sgi.com

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Apr 1993 23:45:37 GMT
From:      rale1@cs.aukuni.ac.nz (Ross Douglas    Alexander      )
To:        comp.protocols.tcp-ip
Subject:   NSF backbone routing


This is from the February Internet_Projects (gopher internic.net)

>     The ANSnet forwarding table now supports over 7K destinations that
>     are actively announced.  New adapter microcode and routing protocol
>     changes are being implemented to increase the current capacity of
>     the on-card forwarding tables beyond 10K destination networks.

These are network addresses, not including hosts so around 70K to 200K hosts.

>     T1 backbone dismantling activities continued in February, and will
>     be completed in March.

I nice piece of history.

     Growth in Destination Networks
     ==============================

     The following table (provided by Enke Chen at Merit) illustrates
     the growth in the ANSnet router forwarding tables (maximal number
     of announced networks of each month):

     MONTH           MAX             RATE(%)
     =====           ====            ======
     07/92           4596
     08/92           4866            5.9
     09/92           5070            4.2
     10/92           5432            7.1
     11/92           5772            6.3
     12/92           6239            8.1
     01/93           6654            6.7

           (Avg monthly growth rate: 6.4%)

     The interface forwarding tables on the ANSnet routers are currently
     configured to support 10K destinations.  In the near term,
     microcode changes will be deployed to support improved address
     compression in the forwarding tables which will support 12K
     destinations.  Following the AIX 3.2 deployment, ANS will deploy
     GATED software.  The GATED routing daemon will support a number of
     enhancements that increase the forwarding table capacity.

     BGP4 within GATED will support CIDR aggregation.  The kernel,
     microcode and routing daemon support for CIDR is expected to reduce
     the rate of growth in the number of on-card routes.  ANSnet will
     configure to receive and redistribute aggregated routes to other
     networks that support BGP4.  ANSnet will also perform proxy
     aggregation for networks that are not running BGP4.  No capability
     is planned to explode/de-aggregate supernet routes to allow re-
     advertising them to non-BGP4 neighbors.

     Routing Software Changes
     ========================

     Changes to the rcp_routed software on the T3 network included
     improving the logging performance on ENSS206 (Geneva) since there
     are over 200 routes announced by 3rd party peers.  Other changes
     support the planned migration from AIX 3.1 to AIX 3.2 software,
     support for handling multiple peer routers with multiple interfaces
     to the ENSS (typically one FDDI and one ethernet per peer), and
     additional changes to address problems associated with changing
     third party route announcements.


     Release notes are available for anonymous ftp in:

          ftp.ans.net:/pub/info/t3-rcp_routed/Release-Notes

     Routing Stability Measured on the T3 Network
     ============================================

     During February, internal routing stability was measured by short
     term disconnect times (disconnects of five minutes duration or
     less).  Overall the network saw almost 99% complete routing
     stability (no internal disconnects in any part of the network).
     All individual nodes reported 99.8% stability or better. ENSS206
     (Geneva) continued to experience circuit problems and reported 1
     hour and 20 minutes of short term BGP disconnect time over the
     course of the month.  Taking into account the configuration runs,
     ENSS206 had only 25 minutes of instability.  All other nodes
     reported less than 51 minutes or about 98.9% stability.  Only 10
     nodes reported less than 99.9% stability.  The configuration runs
     accounted for the majority of the instability.  Only ENSS201 (a new
     installation) experienced higher instability at 48 minutes (outside
     the configuration window).  Only 5 nodes reported more than 15
     minutes of instability outside the configuration window during the
     entire month.

     The external routing stability report covers data gathered during
     the following interval:

     Feb  1 00:11:12 UTC - Feb 28 19:05:14 UTC

     During the reporting period 241,195 IBGP updates were received from
     536 distinct AS paths. These updates contained 591,707 network
     numbers (or an average of 2.5 networks per update or 1,103.9
     updates per AS path). There were 2,448 distinct network number. The
     most unstable network during this period was contained in 5,263
     unreachables.

     The total number of updates and number of AS paths were up slightly
     from the January data.  There were fewer updates per AS path. We
     have been forwarding reports to selected peer networks to help
     identify and eliminate chronic route flaps.  The automation of
     these reports is in progress so that the data can be sent daily for
     any AS which supports  networks that were unstable in the previous
     day.

     RS960 FDDI Deployment Status
     ============================

     During February we installed new FDDI adapters on ENSS141

     (Boulder), and ENSS142 (WestNet).

     It has come to our attention that some peer network routers may be
     taking a performance hit by setting the MTU to 4000 bytes to match
     the T3 backbone MTU.  On the T3 backbone, packets received larger
     than 4000 bytes are fragmented on the FDDI card (with the first
     fragment being 4000 bytes).  This will be changed when AIX 3.2 is
     deployed.  The MTU will then increase to 4352 bytes on both the T3
     and FDDI cards.  We will still be able to *receive* packets larger
     than 4352 bytes in size, and fragment them (with first fragment
     being 4352 bytes).  However we will not *send* packets of size
     larger than 4352 bytes.  We therefore suggest that peer networks
     using FDDI set their router MTUs to default maximum.

     ANSnet Performance Testing
     ==========================

     A set of performance tests were conducted on the T3 backbone on
     2/19 in cooperation with Pittsburgh Supercomputer Center (Matt
     Mathis).  The tests involved use of a PSC developed tool "uping",
     which can be viewed as windowed version of traceroute.  It measures
     data rate and loss as functions of ttl (distance into a pipe), mtu,
     and window size.

     All tests were done with MTU=4000 bytes (The current backbone MTU).
     There was no observed packet loss from the PSC Cray C90 to ENSS132
     (Pittsbugh) at any rate tested.  The measured bandwidth to CNSS41
     (Cleveland) was 20.8 Mb/S (650 pps).  The measured bandwidth to
     CNSS40 (also Cleveland), and all points further west to the San
     Diego Supercomputer Center was 17.6 Mb/S (550 pps).

Just some useless statics.  I looks like the NSF backbone is using CIDR
(classless inter domain routing) using Autonomous System Numbers (AS).
Policy based routing and class C address aggragation is also done using
Border Gateway Protocol version 4 (BGP-4).

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

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Apr 1993 23:50:29 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet monitoring software wanted.

In article <1r9lav$mi@sixgun.East.Sun.COM>, djudy@djudy.East.Sun.COM (Dennis Judy-Sun-Vienna VA-Commercial SE) writes:
> Has anyone seen any performance comparisons between ethernet and
> tokenring with TCP/IP?
> PC's, workstations, minis whatever.
> Dennis


Yes.

Unfortunately, that is probably the only answer that should be to
that question, because it all depends.

How could you answer "have any performance comparisons between gasoline
and diesel or kerosene engines been done?" except with "yes"?
You'd have to answer the implicit question of "which is faster, more
powerful, cheaper, or better" with "it depends", since the question
covers cars, trucks, go carts, tractors, most airplanes, and many
boats.


Some pairs of machines run `ttcp` (a memory-to-memory benchmark) at
>1100 KBytes/sec over ethernet.  Some pairs are reported to do close to
2000 KBytes/sec over 16MHz Token Ring.  However, there are always other
issues that make those numbers as useful as the "fastest engine?":
    -not all Token Rings run at 16MHz.
    -(in general) you better not have any T.R. bridges
    -most PC ethernet implementations get a small fraction of
	that ethernet value.
    -almost no one except people implementing TCP/IP and drivers care
	about those ttcp numbers.   Instead, almost everyone cares about
	NFS, FTP, rcp, or some other file transfer number, and those
	numbers are much more variable, because they involve the
	rest of the operating system, and throw in the disk system.


Vernon Schryver,  vjs@sgi.com

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Sat, 24 Apr 93 00:20:19 GMT
From:      skibo@florida.wpd.sgi.com (Thomas Skibo)
To:        comp.protocols.tcp-ip
Subject:   Re: High-error TCP

In article <1r9d5c$a0s@usenet.INS.CWRU.Edu>, trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:
|> 
|> Has anyone looked into running TCP over high-error-rate connections?
|> I'm dealing with some error-prone (1-5% packet loss) SLIP links that
|> can't really be improved, and I'd like to figure out if there are known
|> optimizations for TCP that improve performance over such links.
|> 
|> I _have_ concluded that Jacobson/Karel congestion control and avoidance
|> is bad on such links, because those algorithms assume that a dropped
|> packet is the sign of congestion.  Sometimes a dropped packet is
|> nothing more than a dropped packet.

The "Fast Retransmit" algorithm quickly replaces single packet (per window)
losses without going all the way back to the slow-start phase (I think it
does back off the congestion window to 1/2 though).  Unfortunately,
it won't work for links with more than one error per round trip.  So it's
not so great for high-loss and/or high-delay networks.

I've been interested in extending fast retransmit by using selective
acknowledgements (SACKs).  The idea is that maybe SACKs could trigger
more than one fast retransmit per window.  Also, the SACK tells you
how much data the other side has received so you know how much data has
left the network and wether you can retransmit without violating the
congestion window.  I figure that perhaps some threshold of packet
loss per window or other heuristic would become a congestion signal
and trigger slow-start.

One of these days (when I have Copious Free Time[tm]) I'll probably
try to prototype something like this.


-- 
---
Thomas Skibo     skibo@sgi.com     Advanced Networking, Silicon Graphics, Inc.

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 93 01:52:12 GMT
From:      iglesias@draco.acs.uci.edu (Mike Iglesias)
To:        comp.protocols.tcp-ip
Subject:   Re: TCPdump questions

In article <2987@sousa.tay.dec.com> b_cobb@hannah.enet.dec.com () writes:
>Does anyone know how to make the tcpdump utility print out just
>DNS queries and zone transfers?  I was under the assumption that
>just using tcpdump with no qualifiers printed out all packets.
>I never see any DNS queries or zone transfers.  Does anyone have
>the syntax to print all DNS UDP queries and all TCP zone transfers
>going to and comming from host A?

tcpdump host A and port 53 

>This is on DEC ULTRIX 4.3 with packet filter turned on (I think, 
>kernel was configured with 'options PACKETFILER')

You also need "pseudo-device packetfilter" in the config file.  After
you boot with your packetfilter kernel, do:

  # cd /dev
  # MAKEDEV pfilt
  # pfconfig +p +c ln0 (or whatever interface you are using)


Mike Iglesias                        Internet:    iglesias@draco.acs.uci.edu
University of California, Irvine     BITNET:      iglesias@uci
Office of Academic Computing         uucp:        ...!ucbvax!ucivax!iglesias
Distributed Computing Support        phone:       (714) 856-6926




-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Sat, 24 Apr 1993 04:17:14 GMT
From:      lapp@waterloo.hp.com (David Lapp)
To:        comp.sys.acorn,comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: Acorn/HP TCP-IP bug

Anthony J.R. Heading (heading@signal.dra.hmg.gb) wrote:
.. deleted ...
: We have an HP printer which starts up using bootp, responded
: to be an HP workstation which broadcasts a bootp reply on
: port 68. The Acorn Archimedes machines, running what might
: be fairly old IP software, appear to pick up on this reply,
: and set *their* IP address to be that of the printer. This, as
: one might expect, causes some confusion.
 .. deleted ...
: Has anyone run into this before?

I haven't run into this problem and I'm afraid that my
experience with Acorn Archimedes is lacking (well non-existant
actually) but I have a bit of experience with the bootpd we
(HP) ship.

You mention that the workstation "broadcasts a bootp reply".
I assume that you have seen this being sent to a broadcast
address ? (with some kind of LAN analyzer) If so then that
implies that the bootptab file has a ba tag in it. This tag 
is used to tell the bootp server to send replies using the
link level broadcast address rather the link level address 
from which they were received.  (You can also specify a 
destination address with newer versions of bootpd.) 

This is useful for a couple of things: testing your bootp
config using bootpquery (as documented in bootpd(1M)) and
for those bootp clients which have to recieve the reply
as a broadcast (which I don't believe includes the printer).

Anyway, try removing this tag from the bootptab file 
(/etc/bootptab). The bootp reply should be picked up only 
by the printer.

Hope that helps,

Dave Lapp

Standard Disclaimer: I don't speak for HP.

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Sat, 24 Apr 1993 09:38:54 +0000
From:      chris@keris.demon.co.uk (Chris Croughton)
To:        comp.protocols.tcp-ip
Subject:   Re: finger client or hack

In article <C5yHG8.AAL@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu writes:

>        This isn't technically true. The telnet client you're using doesn't
>use (like most don't) the TELNET protocol when you specify an alternate
>port. The finger protocol, described in RFC 1288, is simple in the ordinary
>case (send "user\r\n" for information about "user"), and if your telnet
>client gives you a straight, uninterpretted connection to alternate ports,
>it works. But if it used the TELNET protocol, it wouldn't...

Surely if your Telnet client just didn't *issue* any option negotiation
(from the RFCs I don't see that you have to issue any, just respond)
then it would still work?  The Telnet client on Interactive UNIX-386
just sends CRLF at the end of lines, and doesn't initiate option
negotiation (although it will respond with appropriate replies if it
receives any).  That seems to be true for the telnet port (23) as well
as for others...

***********************************************************************
*  chris@keris.demon.co.uk      *                                     *
*  chriscr@cix.compulink.co.uk  *  FIAWOL (Filking Is A Way Of Life)  *
*  100014.3217@compuserve.com   *                                     *
***********************************************************************

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Sat, 24 Apr 1993 12:23:38 GMT
From:      nas20@cus.cam.ac.uk (Nick Smith)
To:        comp.sys.acorn,comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: Acorn/HP TCP-IP bug

In article <1r8qvmINN6vp@liszt.dra.hmg.gb> heading@signal.dra.hmg.gb (Anthony J.R. Heading) writes:
>This is a peculiar bug. I'd like a fix, and I'm not sure
>whether the problem is already known, but since it's taken
>me a while to track down, it seems worth reporting it.
>
>We have an HP printer which starts up using bootp, responded
>to be an HP workstation which broadcasts a bootp reply on
>port 68. The Acorn Archimedes machines, running what might
>be fairly old IP software, appear to pick up on this reply,
>and set *their* IP address to be that of the printer. This, as
>one might expect, causes some confusion.

A recent posting to ucam.comp.tcp-ip mentioned this problem that
had hit the Computing Service network too, and that there is a 
fix for the problem. I'm just repeating what I have heard, so 
please don't ask me where to get the fix from ...

Nick.
-- 
Nick Smith, Rm.226, Churchill College, Cambridge XOX Email: nas20@cus.cam.ac.uk
Intel? Watashi o warawasenaide kudasi ...        OXO Phone: (0223) 465596

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      Sat, 24 Apr 1993 14:29:08 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   OSPFv2 availability survey

  We're seeing the canonical well known problems with RIP in our
campus network these days (like you read about).  So I'm considering
starting a grass roots lobbying campaign to start migrating to OSPFv2,
ideally with the draft OSPF multicast routing extensions.

[ Vendor product managers should consider this customer demand and let
your networking folks start implementing OSPFv2+multicast now ! ]

  I'm looking for information on availability of OSPFv2-capable software
to replace routed(8)/gated(8) on the following platforms:
	Sun SPARC with SunOS 4.1.3
	Sun SPARC with Solaris 2.1
	Sun CMW
	SGI Iris with IRIX (probably not the most recent release)
	HP  730/750 with HPUX 8.09 or 8.09+ (HPUX 9.x won't help for now).
	NeXTstation
	BSD Net/2 or 4.4 BSD or BSDI

  I'd especially appreciate hearing from anyone with current
information on how stable the Cornell gated(8) work is for any of the
above.  I'd also be interested in hearing from anyone having
experience with any vendor-supplied software along the above lines or
even from technical staff at vendors (vendor droid disinformation is
actively discouraged).  I suspect that the NeXT and HP platforms will
be the hard ones to get OSPF for, based on past experience with trying
to port code to them. [ Aside: whoever came up with NetInfo on the
NeXT should be forcibly be disconnected from the net -- it is truly an
administrative nightmare].

  Replies to the poster via email are encouraged and I will write a
concise followup posting towards the end of next week or so.

Ran
atkinson@itd.nrl.navy.mil

Internetworking Research Group
Naval Research Laboratory

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 1993 23:06:06 GMT
From:      scooper@cse.ucsc.edu (Scott Cooper)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP STREAMS modules

	Our installation of SunOS 5.1 doesn't appear to include source.
I would like to get ahold of the code for the TCP/IP streams modules.  Does
anyone know of a source for the code (besides buying a source license
from AT&T or something to that effect)?

Thanks,
Scott Cooper			scooper@cse.ucsc.edu

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Sun, 25 Apr 1993 01:14:37 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: finger client or hack

	Ok, if you want to call TELNET without any of the commands "the
TELNET protocol," fine. By that definition, you can implement TELNET using
the "TELNET protocol" as a transport. :-)

	I call it a byte stream, which conveniently is what TCP provides. :-)
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 93 01:18:07 GMT
From:      gls@cirrus.com (Gary L. Schaps)
To:        comp.protocols.tcp-ip
Subject:   "Internetworking With TCP/IP Vol. III" Source Code - Where?

I would like to ftp the source code from the book
"Internetworking with TCP/IP Volume III", by Comer
and Stevens.  Anyone know where I might find it?

Thanks.

Gary L. Schaps
gls@cirrus.com

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 93 11:32:30
From:      amoss@shuldig.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip
Subject:   Re: finger client or hack

chris@keris.demon.co.uk (Chris Croughton) writes:

   dls@mentor.cc.purdue.edu writes:

   >        This isn't technically true. The telnet client you're using doesn't
   >use (like most don't) the TELNET protocol when you specify an alternate
   >port. The finger protocol, described in RFC 1288, is simple in the ordinary
   >case (send "user\r\n" for information about "user"), and if your telnet
   >client gives you a straight, uninterpretted connection to alternate ports,
   >it works. But if it used the TELNET protocol, it wouldn't...

   Surely if your Telnet client just didn't *issue* any option negotiation
   (from the RFCs I don't see that you have to issue any, just respond)
   then it would still work?  The Telnet client on Interactive UNIX-386

Chris is right.  I do a lot of testting of a telnet daemon on a different port
and the client does respond properly for TELNET options.  I also put the
original telnet daemon to listen on a different port than the default one (as
a backdoor) and it works fine there.

Don't see any point in disabeling TELNET processing in the client if it talks
to a none tcp/23 port,  after all that's what you run it for, don't you?

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

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 93 15:25:00
From:      amoss@shuldig.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip
Subject:   Re: finger client or hack

dls@mentor.cc.purdue.edu (David L Stevens) writes:

   Ok, if you want to call TELNET without any of the commands "the
   TELNET protocol," fine. By that definition, you can implement TELNET using
   the "TELNET protocol" as a transport. :-)

   I call it a byte stream, which conveniently is what TCP provides. :-)
   --
					   +-DLS  (dls@mentor.cc.purdue.edu)

It is not a simple byte stream since the telnet client will still quote telnet
command codes (decimal 255) before trasnmitting them over the TCP connection,
so the other side still have to know about the protocol at least enough to
unquote them back.

Cheers,

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

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 1993 14:59:57 GMT
From:      geoff@poori.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP STREAMS modules

Quoth scooper@cse.ucsc.edu (Scott Cooper) (in <1rch4uINNrrr@darkstar.UCSC.EDU>):
#	Our installation of SunOS 5.1 doesn't appear to include source.
#I would like to get ahold of the code for the TCP/IP streams modules.  Does
#anyone know of a source for the code (besides buying a source license
#from AT&T or something to that effect)?

While I can't speak for SunSoft on source licensing policies, I should
point out that buying a license from USL (not AT&T) won't do you much
good: the SunOS 5.x TCP/IP is a new implementation, not based on anything
from USL or Lachmann (or BSD, for that matter).

Geoff

-- 
Geoff Arnold, PC-NFS architect, Sun Select. (geoff.arnold@East.Sun.COM)
--------------------------------------------------+-------------------
"Of course I believe that solipsism is the correct philosophy, but
that's only one man's opinion." (Melvin Fitting, quoted by Smullyan.)

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      Sun, 25 Apr 1993 15:40:11 GMT
From:      cliff@engin.umich.edu (clifford  kaminsky)
To:        comp.protocols.tcp-ip
Subject:   Using KA9Q with Dialup SLIP server

Hi.  I have a PC with KA9Q NOS and SLFP which gives me a SLIP connection
to the internet through the Merit network dialup line.  My modem is
9600 bps and is on COM2.  Can someone please tell me what my
AUTOEXEC.NET and startup batch files should look like?

THanks.

-Cliff
cliff@engin.umich.edu


-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 93 19:09:19 GMT
From:      wca0@ns1.cc.lehigh.edu (W. Cody Anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: pctcp printing (lpr) from windows to HP425e

In article <1993Apr22.173755.25366@kocrsv01.delcoelect.com>, blrohler@kocrsv01.d
elcoelect.com (Brian L. Rohler) writes:
>
>
>        I have a handful of pc's (compaq's,hp vectras, AST,...) and four
>HP425e workstations. I want to use my workstation (425e) as the print
>spooler for all of the pc's. It already spools for the other
>workstations.

[blah blah blah]

Lehigh University systems programming has developed Simple Queue Transfer
Protocol (SQTP) for print sharing in a TCP/IP environment.  You can find this
program on ftp.lehigh.edu:/pub/sqtp/sqtp*.tar.Z.

We use it to integrate and share print services on all our TCP/IP Novell PC
Lans, RS/6000s, and Sun Sparcs.  It really works quite niftily.  I believe
there is also an RFC for it (don't know the number off the top of my head).

Cody

-- 
$ drink < bottle; opener
bottle: cannot open
opener: not found
panic: restarting...

***************************************************************************
W. Cody Anderson            |  LUCC User Services

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      Sun, 25 Apr 1993 20:44:59 GMT
From:      danielh@hpber199.swiss.hp.com (Daniel Huber)
To:        comp.sys.sun.wanted,comp.protocols.tcp-ip
Subject:   Re: telnet with scripting capabilities

: >I'm interested in doing some non-interactive logins via telnet (started from
: >cron) for device monitoring on a regular basis.
 
: >Is there some PD telnet implementation available to do this? Any PD
: >implementation of telnet? Where?

Try expect.

This should do what you want...

Daniel

--
Daniel Huber, RCO, HP Niederwangen (8700), Switzerland
SMTP: danielh@hpber199.swiss.hp.com (or Daniel_Huber@hp8700.desk.hp.com)
X.400: /G=Daniel/S=Huber/OU=HP8700/O=HP/P=HP/A=ArCom/C=CH/
If a train station is where a train stops, then what's a workstation?
My opinions are my own...not HP's...

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      Sun, 25 Apr 1993 23:38:24 GMT
From:      "Jeffrey W. Parker" <p00185@psilink.com>
To:        comp.unix.sysv386,comp.unix.i386,comp.protocols.tcp-ip
Subject:   A Share/FreeWare version for AT&T Unix 3.2.2????

Hi there out in netland,
	I have a copy of AT&T Unix version SVR3.2.2/386 that I would like 
to get TCP/IP (telnet, ftp, etc.) support for.  Is there a FTPable 
Free/shareWare version that will support ethernet cards (preferably 
SMC8003 family) that I can compile, configure and run?  Where can I get 
it? 

Any help by Email would be greatly appreciated.

Thanks in advance,
Jeff Parker
p00185@psilink.com

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 93 00:06:50 GMT
From:      alagu@apple.com (Alagu Periyannan)
To:        comp.protocols.tcp-ip
Subject:   Sample programs using SunOS' NIT ?

Hi!

Does anyone know of a public domain program that uses SunOS Network
Interface Tap (NIT) streams interface. I would like to have the source of
such a program. I need to write some code that reads, writes and filters
ethernet packets from a SUN workstation.

I know "tcpdump" uses NIT to read ethernet packets, but it does not write
out packets. Neither does it use the packet filter module that comes with
NIT.

Something like a public domain RARP Daemon source which uses NIT will be
ideal.

Any pointers, suggestions ?

-------------------------------------------------------------------------
Alagu Periyannan               alagu@apple.com

Disclaimer: My opinions are my own, not Apple's ...

.... and the cosmic hippo rides a jet carpet !!

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 00:11:20 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP Destination Unreachable "unknown" codes?

bob@MorningStar.Com (Bob Sutterfield) writes:

> What's the semantic difference between a code 6 "destination network
> unknown" and a code 0 "net unreachable"? 

The way I've seen some IP implentations handle this is:

6 = I don't have a route to that net
0 = I have a route to that net which points to a router which is down, and
    no backup router is available.

Given the way most routing protocols work, the difference is pretty much
academic.....

> And between a code 7
> "destination host unknown" and a code 1 "host unreachable"?

Probably meaningless on an ARP-based network.  On a net like an X.25 net,
which hard-codes the mapping between IP and DTE addresses, I'd expect
to see:

7 = No IP/DTE address mapping exists
1 = IP/DTE address mapping exists, but nothing is at that DTE address.

-- 
Tom Fitzgerald   Wang Labs       fitz@wang.com   "I went to the universe today;
1-508-967-5278   Lowell MA, USA                   It was closed...."

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 00:11:38 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: finger client or hack

In article <AMOSS.93Apr25152500@shuldig.cs.huji.ac.il>, amoss@shuldig.cs.huji.ac.il (Amos Shapira) writes:
> 
> It is not a simple byte stream since the telnet client will still quote telnet
> command codes (decimal 255) before trasnmitting them over the TCP connection,
> so the other side still have to know about the protocol at least enough to
> unquote them back.

	I think you're confusing the issue. :-) I said *finger* uses a byte
stream and does *not* use TELNET. If memory serves, finger does restrict the
set of allowable characters, so the IAC issue doesn't matter here, but you're
making the point I was trying to make, which is that TELNET is not a byte
stream.  And if the protocol calls for a byte stream, even if you use a telnet
client to connect to it, it does *not* mean the protocol uses TELNET as
transport.  Some telnet clients provide a simple byte stream when you choose
an alternate port, which confuses the issue further. Even if yours doesn't,
if you don't send most non-printing characters (not really allowed without
"binary" negotiated, though I've seen clients that do anyway), or doesn't
send a mark or even parity ASCII DEL, you may not notice.
	In private mail, a couple people have made the point that it uses
a *subset* of TELNET. Well, sure, a byte stream is a subset of TELNET.
Just like my PC is held together by a subset of an aircraft carrier. But
most people call it a screw. :-)
	My point is: TELNET uses TELNET. FTP uses TELNET. Finger uses TCP.
It doesn't need anything more, there *is* more to TELNET, and if you try
to talk full TELNET to a finger server, it will likely say something rude
and go away. As well it should.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 00:19:28 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewalls (was "Of course we're running out of IP addresses!")

cleelacj@agedwards.com (Chris Cleeland) writes:

> Regarding all these references to firewalls, does anybody know where
> one might obtain information about how to write one or (even better),
> source to one?  I think this might serve some purposes on one of my
> current projects, but I don't want to waste lots of bandwidth spouting
> the problem to the World.Net.  If anybody out there feels compassion
> for somebody who might be just a bit over his head wants to send mail
> to me, I very much like to bounce some ideas/problems off you.

A firewall is often just a multihomed Unix system (one leg on the Internet,
one leg on the local net), with routing disabled.  It will drop any packet
that doesn't have its own IP address as the destination.

There are other nice things that can be added, like Wietse Venema's log_tcp
package, and more paranoid versions of ftpd, etc.  These aren't essential
for the basic firewall activities.

Another (and weaker) form of firewall is a smart router with packet filters
set up to discard traffic that's not to or from specific hosts or ports.

RFC 1244 goes into this in more detail.

-- 
Tom Fitzgerald   Wang Labs       fitz@wang.com   "I went to the universe today;
1-508-967-5278   Lowell MA, USA                   It was closed...."

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 00:26:12 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!

marcelm@joymrmn.on.ca (Marcel Mongeon) writes:

> One advantage of the 127 space is that if it gets out beyond a
> firewall through a mistake, it will be bounced back pretty
> quickly with a network unreachable ICMP.

Actually, some routers will treat 127.*.*.* as a valid local address.  If
you can make such a packet leave your host, the first router that sees it
will respond to it as if you were addressing the router itself.

xntpd also uses 127.*.*.* addresses as magic addresses meaning locally-
attached radio clocks.

I don't think using net 127 will work very well.  126 should be ok.....

-- 
Tom Fitzgerald   Wang Labs       fitz@wang.com   "I went to the universe today;
1-508-967-5278   Lowell MA, USA                   It was closed...."

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 1993 01:11:55 GMT
From:      mjr@tis.com (Marcus J Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewalls (was "Of course we're running out of IP addresses!")


	Every so often, when this topic comes up, it's worth mentioning
the firewalls mailing list (send mail to majordomo@greatcircle.com to
join list "firewalls") and the archive from the mailing list that is
also maintained for FTP on ftp.greatcircle.com.
	Other good sources of firewalls-related stuff is Ches' and
Steve Bellovin's various papers, on research.att.com:dist/internet_security

mjr.

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 1993 02:38:10 GMT
From:      bob@comlab.gtri.gatech.edu (Bob Baggerman)
To:        comp.protocols.tcp-ip
Subject:   Re: Sample programs using SunOS' NIT ?

Alagu Periyannan of Apple writes:
>Does anyone know of a public domain program that uses SunOS Network
>Interface Tap (NIT) streams interface.

I wrote a simple mail notification system that uses the NIT interface
to send out my own arbitrary ethernet packet from my SunOS 4.1.x box.
The receiving end is a small TSR on a PC that connects to a packet
driver.  The PC beeps when new mail comes in on the Sun.  Anyway, the
Sun NIT source is available from "lanman.gatech.edu" along with the PC
TSR in the "/pub/pcbiff" directory.

Keep in mind that NIT isn't used anymore by Sun.  In Solaris 2.x the 
ethernet driver is itself a STREAMS driver.  There are some porting
guides to convert NIT code to the new drivers.

Bob

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

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 03:43:39 GMT
From:      crj@comserv.itri.org.tw (Robert Ju-ching Chen)
To:        comp.protocols.tcp-ip
Subject:   SUN's TCP BUG ??

Dear Network Fellows:
  I wonder if Sun's TCP has bugs. I heard that there are some memory manage-
ment bug in TCP/IP. Is that true ?

  We find that when we use NCSA 2.3.05 or PC/NFS 2.0 from PC to connect 
Sun 690MP (SunOS 4.1.2-HL), the login prompt shows up slowly sometimes.
After we used Sniffer to capture the packets between PC and Sun, we found
that the destination port no of packets sent from SUN has been changed !!
After about 1.5 or 2 minutes, the destination port no could be recoverd 
to correct one. That is the reason why the login prompt displays so slowly !
  
  Any comment ? Thanks in advance !

Name	Robert Ju-Ching	Chen
Email	crj%comserv.itri.org.tw@twnmoe10.edu.tw
Addr.	P.O. 9-65 Chutung, Hsinchu, Taiwan 310,	R.O.C.
Tel.	886-35-917558
Fax	886-35-820026

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 93 04:39:58 GMT
From:      otto@fugue.sybase.com (Otto Lind)
To:        comp.windows.x.apps,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: Announcing tcpview: A Motif-based TCP/IP protocol analyzer

In article <1r98tjINNt1j@shelley.u.washington.edu>, martinh@cac.washington.edu (Martin Hunt) writes:
|> 
|> Tcpview has been tested on a DECstation 5000 and Sun 4 under Ultrix 4.2 and
|> SunOS 4.1 respectively.  It should work on the same systems as tcpdump.
|> It compiles with cc and gcc on the DEC and Sun.  To build tcpview you will
|> need Motif 1.1 or better.

I just compiled this package on my Sparc station (4.1.2 sun4c), and found
that the gethostbyaddr() function does not work when you link in the resolve
library -lresolv. This results in the viewer always showing the source and
destination address with only the IP numbers, not the names. If you are
experiencing the same problem, you can make the following mods to the
Makefile file:

	o Make sure that "LIB = -lresolv" is commented out.

	o Add the module res_comp.o to the list of objects defined by
	  TCPVIEW_OBJ. This module contains all the functions which are
	  referenced by detail-domain.c, but does not have the broken
	  gethostbyaddr() routine.

	o Add the following target to the Makefile:

		res_comp.o: /usr/lib/libresolv.a
			ar x /usr/lib/libresolv.a res_comp.o

Hope this helps,

Otto

-- 
Otto Lind                            Sybase, Inc.
otto@sybase.com                      6475 Christie Ave Emeryville, CA 94608
{pacbell,pyramid,sun}!sybase!otto    (510) 596-3691

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 1993 06:56:30 GMT
From:      Martin W Freiss <freiss.pad@sni.de>
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!

In <735380988snz@peeras.demon.co.uk> proyse@peeras.demon.co.uk (Phil Royse) writes:

...
>We have speculated that if future access to the Internet, or to Internet
>connected orgs is needed, then we could use email via one or more gateways.
>Also, any small group within each big org (eg. a scientific dept) for
>which Internet telnet, rlogin, ftp etc. was essential, they could apply
>for "proper"  (IAB/NIC) registered addresses and install them, but we 
>would need to build firewalls between our corporate subnets and theirs.
 
>Any comments?  Can anyone see any ghastly pitfalls?

Well, for one your firewall will never be able to communicate directly with
the organization that legally uses the IP-network address that you are
"illegally" using internally. This can be a major dilemma if that organization
is your major business partner.

Plus, there is always the offchance that the organization suddenly 
decides to connect to the internet in a massive way, and moving an 
organization with several 1000 computers to
registered addresses is a) a major pain and b) costs a _lot_ of money
in time wasted reconfiguring every computer in sight, educating users
and changing programs that have IP-addresses hardcoded on them. Don't
ask :-) - I've been there.

I would assign unregistered addresses only to networks that really
never ever will connect to the Internet, i.e. high security nets
or production environments (factory automata, robots, cash registers
etc.) (really the same thing).


-Martin

--
 Martin Freiss               | R&D computer center | freiss.pad@sni.de 
 Siemens Nixdorf Infosystems | Dept. MR STO SI 325 | NIC MF194
"In this town, I am the leper with the most fingers." - The Two Jakes


-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 1993 08:21:32 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: SUN's TCP BUG ??

In article <crj.3.735795819@comserv.itri.org.tw> crj@comserv.itri.org.tw (Robert Ju-ching Chen) writes:
>Dear Network Fellows:
>  I wonder if Sun's TCP has bugs. 

I'm sure it does.  Just about every program longer than a page, and most
shorter programs as well, has bugs.

>  We find that when we use NCSA 2.3.05 or PC/NFS 2.0 from PC to connect 
>Sun 690MP (SunOS 4.1.2-HL), the login prompt shows up slowly sometimes.
>After we used Sniffer to capture the packets between PC and Sun, we found
>that the destination port no of packets sent from SUN has been changed !!
>After about 1.5 or 2 minutes, the destination port no could be recoverd 
>to correct one. That is the reason why the login prompt displays so slowly !

What do you mean "the port no has been changed"?  If the Sun is sending
packets to a different port, then it's doing something else -- it's not
part of the same connection.  When you telnet to a Unix system, it tries to
look up the name of the client system; you may be seeing the nameserver
queries that do this.  What port is it sending to?
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 08:57:59 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.protocols.tcp-ip
Subject:   Re: SUN's TCP BUG ??

crj@comserv.itri.org.tw (Robert Ju-ching Chen) writes:

>Dear Network Fellows:
>  I wonder if Sun's TCP has bugs. I heard that there are some memory manage-
>ment bug in TCP/IP. Is that true ?

Everything has bugs. The 4.1.2 imnplementation may ahve had some memory
management bugs, I don't see how those relate to your problem.

>  We find that when we use NCSA 2.3.05 or PC/NFS 2.0 from PC to connect 
>Sun 690MP (SunOS 4.1.2-HL), the login prompt shows up slowly sometimes.
>After we used Sniffer to capture the packets between PC and Sun, we found
>that the destination port no of packets sent from SUN has been changed !!
>After about 1.5 or 2 minutes, the destination port no could be recoverd 
>to correct one. That is the reason why the login prompt displays so slowly !

WHat port number is used in the other connection?

It is possible that your Sun has wrapped the telnet daemon with tcp_wrapper
and tries to connect to the ident daemon on your PC. (Traffic to port 113).

I think it's highly unlikely that the Sun would respond with the wrong
address AND correct this a minute later.

Casper

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 93 09:10:24 GMT
From:      connolly@ripolin.laas.fr (Tom Connolly)
To:        comp.protocols.tcp-ip
Subject:   question on client/server use of TCP

I have a networking question for any database networking gurus. 
 
I believe that many (perhaps most) commercial databases utilize 
a reliable, connection-oriented transport protocol like TCP and  
have a (hopefully simple) implementation question: 
 
 
1. In a client/server scenario, does the client open and close a  
   connection for each request/transaction?
 
 
If you post a reply, please e-mail a copy directly as I do not get 
to read this news groups that often. 
 
Thanks, 
 
Tom C 
 
e-mail: connolly@udel.edu 
 



-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 09:29:25 GMT
From:      dm@cl.cam.ac.uk (Derek McAuley)
To:        comp.sys.acorn,comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: Acorn/HP TCP-IP bug

> This is a peculiar bug. I'd like a fix, and I'm not sure
> whether the problem is already known, but since it's taken
> me a while to track down, it seems worth reporting it.

HPUX 7.?? (and prehaps pervious versions) sends bootp replies (i.e. it's the
server at fault) on the Ethernet broadcast address.  RISCiX and RISCOS see this
reply, forget to check it is for them (at the IP level) and reset their IP
address on the mistaken assumption it is for them (i.e. the hooks they have for
booting discless exhibit a "feature").

HPUX 8.?? seems not do this irritating thing anymore. Beta test !Internet
software from Acorn has also been seen to solve this problem. I am unsure of the
position with respect to released version of RISCiX.

Mac.



-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 10:01:03 GMT
From:      ph10@cus.cam.ac.uk (Philip Hazel)
To:        comp.sys.acorn,comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: Acorn/HP TCP-IP bug

In article <1993Apr26.092925.7418@infodev.cam.ac.uk>, dm@cl.cam.ac.uk (Derek McAuley) writes:
|> HPUX 7.?? (and prehaps pervious versions) sends bootp replies (i.e. it's the
|> server at fault) on the Ethernet broadcast address.

I was assured by an "expert" that this is in fact permitted by the bootp
protocol. We saw the same problem with some PC software that was using bootp in
the same way. You will need to contact Acorn if you need a solution urgently.

--
Philip Hazel                   University Computing Service,
ph10@cus.cam.ac.uk             New Museums Site, Cambridge CB2 3QG,
P.Hazel@ucs.cam.ac.uk          England.  Phone: +44 223 334714

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 11:50:03 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address

hughf@algol.csis.dit.csiro.au (Hugh Fisher) writes:

>Ian Phillips writes:
> 
>> There are more IP addresses available than the toaster population of the
>> earth :-)
 
>and Phil Royse followed up with:
[various other stuff deleted]

Well, thank you, Phil, for quoting me out of context. My reply, from
which you are quoting, *did* address the serious issues - repeated and
amplified by Hugh here. I put in the joke at the end which Phil seems
to think is a serious comment, despite the smiley. I assume that he's
picked up my article from the wrong end of a chain, since somewhere
along the line my name has become mis-spelled.

For the record, my original article said, in essence: yes, it's a
serious problem, but not a desparately urgent one. And it's a problem
that's being addressed.

Ian
-- 
Ian Phillipps, Unipalm Ltd, 216 Science Park,		Phone +44 223 420002
Milton Road, Cambridge, CB4 4WA, England.		Phax  +44 223 426868
PIPEX Ltd. is a wholly-owned subsidiary of Unipalm Ltd. - phone 0223 424616.

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 1993 13:12:56 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: How does the NFSNET know the route to my IP address?

In article <fred_sC5vLIE.H1F@netcom.com> fred_s@netcom.com (Frederick
Scott) writes: 
    
    It was my understanding that the core gateways (and I'm not at all sure
    there's suppose to be that many of them) used their own routing protocol.
    (CGP or something like that.)  
    
As Steve pointed out, the NSFnet uses a precursor to ISIS for internal
routing and BGP and EGP for external routing.

The core gateways which still exist on Milnet use (?) a proprietary link
state protocol called Spread.  [This information may be out of date.  If
so, my apologies.]

    The internal and external protocols mentioned 
    above aren't really that suitable, as the core gateways need to rapidly
    transfer the entire routing tables for *all* internet addresses.  The
    protocols mentioned above generally assume a relatively small table of
    networks known by the gateways and rely on a default gateway to kick
    packets to which are addressed to someplace unknown.

This is an over-generalization.  Some of the protocols that were listed
have the scaling problems that you describe.  Some are specifically
designed for large routing tables (e.g., BGP).  In general, any protocol
that doesn't do periodic updates can be made to work reasonably with large
routing tables.  

Tony



-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 93 18:58:42
From:      amoss@shuldig.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip
Subject:   Smarter FTP client for a PC anyone?

Hello,

I'm looking for an FTP client for a PC which won't be confused by the long
messages emitted by my ftp daemon.  (I do have the WU ftp daemon but using
'-' in front of the password won't help here since I emit messages before
reading the password).

The FTP client should also be able to work in a kind of a "batch" mode, i.e.
it should take the commands from a file (e.g. "ftp ftp.huji.ac.il < ftpcmds"
is fine).

It seems like the NCSA ftp client can't handle this situation, it read the
long responses as individual responses to the "USER" and "PASS" commands and
concludes that the login failed.

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

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 14:57:46 GMT
From:      besmith@uncc.edu (Brian E Smith)
To:        comp.windows.x.openlook,comp.windows.open-look,comp.protocols.tcp-ip
Subject:   Alternative to SunOS threads?

I am wanting to do a TCP/IP / Open-Look xtalk-style program.  The idea I am working
with now is to use the SunOS Lightweight Process library (threads).  Here is the 
setup:

  Thread #1:  Main thread - Initializes TCP/IP socket and OLIT Widget structure,
              splits off Thread #2, and goes into Xt event loop.

  Thread #2:  Listens for connections to TCP/IP socket - When a connection is 
              requested, this thread alerts the main thread.  In effect, this thread
              handles the socket connection handshaking.

This approach will make the program dependant on SunOS, but I need the multi-threading
capabilities due to the blocking nature of the listen() call.  Does anyone know of
another, more-portable way to handle this?

-------------------------------------------------------------------------------
     "I don't know if you've got the whole picture or not, but it doesn't 
      seem like he's running on all thrusters!" -- Leonard McCoy

     "A guess?  You, Spock?  That's extraordinary!" -- James T. Kirk
-------------------------------------------------------------------------------
   Brian Smith  (besmith@mosaic.uncc.edu)


-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 15:12:59 GMT
From:      fwp@CC.MsState.Edu (Frank Peters)
To:        comp.protocols.tcp-ip
Subject:   Re: SUN's TCP BUG ??

In article <crj.3.735795819@comserv.itri.org.tw> crj@comserv.itri.org.tw (Robert Ju-ching Chen) says:
: 
:   We find that when we use NCSA 2.3.05 or PC/NFS 2.0 from PC to connect 
: Sun 690MP (SunOS 4.1.2-HL), the login prompt shows up slowly sometimes.
: After we used Sniffer to capture the packets between PC and Sun, we found
: that the destination port no of packets sent from SUN has been changed !!
: After about 1.5 or 2 minutes, the destination port no could be recoverd 
: to correct one. That is the reason why the login prompt displays so slowly !

Hmmm...that "changed" destination port wouldn't be 113 by any chance?

Some administrators use a wrapper around their telnetd that attempts to
query the remote site's authentication daemon (running on port 113 if
it is running at all).  If you connect from a PC things "pause" while
the query times out (during this pause you see packets from the Sun to
port 113 on the PC) and then the login continues normally.  This is
probably what you are seeing (at least, the symptoms you describe match
perfectly).

This isn't a bug, though whether it is a Good Thing is certainly a
valid subject for debate.
--
Frank Peters  -  UNIX Systems Programmer  -  Mississippi State University
Internet: fwp@CC.MsState.Edu  -  Phone: (601)325-7030  -  FAX: (601)325-8921

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 15:21:42 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: SUN's TCP BUG ??

In article <crj.3.735795819@comserv.itri.org.tw> crj@comserv.itri.org.tw (Robert Ju-ching Chen) writes:
>     We find that when we use NCSA 2.3.05 or PC/NFS 2.0 from PC to connect 
>   Sun 690MP (SunOS 4.1.2-HL), the login prompt shows up slowly sometimes.

Years ago we found that logins were slow because the system had to
check the quota of all NFS mounted partitions. We fixed this by making
/usr/ucb/quota a do nothing routine.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 15:24:26 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: FAQ

In article <1r8robINNkum@rave.larc.nasa.gov> steve@jackson.larc.nasa.gov (steve comer) writes:
   Is there any FAQs for this newsgroup.

Get "Internetworking with TCP/IP - Principles, Protocols, and
Architecture" by Douglas Comer (1988, Prentice-Hall, 261 pps. plus 5
appendices, bibliography, and index; ISBN 0-13-470154-2).

Also, the newsgroups {alt,misc}.books.technical have occasionally
carried an annotated networking bibliography.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221           +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 15:48:00 GMT
From:      stern@nsinic.gsfc.nasa.gov (Close your eyes and press ESCAPE three times)
To:        comp.protocols.tcp-ip
Subject:   telnetting from script on VMS

For those few of us not working exclusively on UNIX, it is possible to run
telnet using a script (actually a COM)file. The main problem here is that most
VMS TCP/IP sofware is not PD and therefore can't be easily patched.

The way around this is with a delightful utility called SUPERVISOR. This
utility is really meant for terminal watching and trapping keystrokes.
One of its capabilities however allows you to stream commands from a file
rather than keyboard.  

Availability: Among other sites, we have it online at
              nsinic.gsfc.nasa.gov (aka 128.183.112.71) 
              cd [.software.vms.sys_mgr]
              and in binary mode, mget supser054.*
Documentation: This was originally a pay-for product. As such, it has the
               look and feel of any other VMS utility, even installs using
               VMSinstal. It's documentation is outstanding
Trustworthiness: It's from Hunter Goatley. Need I say more?

Dave Stern

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
                              Hughes STX
                             301-286-6079
 DECnet-   NSINIC::STERN                        Code 933   Bldg 28 Rm W291
 INTERNET- STERN@NSINIC.GSFC.NASA.GOV           Goddard Space Flight Center
 BITnet-   STERN@DFTBIT                         Greenbelt, MD 20771
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 16:07:58 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.windows.x.openlook,comp.windows.open-look,comp.protocols.tcp-ip
Subject:   Re: Alternative to SunOS threads?

besmith@uncc.edu (Brian E Smith) writes:

>This approach will make the program dependant on SunOS, but I need the multi-threading
>capabilities due to the blocking nature of the listen() call.  Does anyone know of
>another, more-portable way to handle this?

Use select():

    Selecting true for reading on a socket descriptor upon which
    a  listen(2) call has been performed indicates that a subse-
    quent accept(2) call on that descriptor will not block.

I assume you already have a call to select() somewhere.
(If it's in the X client code, try XtAppAddInput with ``read''
as condition)

Casper

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 16:12:42 GMT
From:      rgooch@rp.CSIRO.AU (Richard Gooch)
To:        comp.windows.x.openlook,comp.windows.open-look,comp.protocols.tcp-ip
Subject:   Re: Alternative to SunOS threads?

In article <C63IwA.Au3@unccsun.uncc.edu>, besmith@uncc.edu (Brian E Smith) writes:
> I am wanting to do a TCP/IP / Open-Look xtalk-style program.  The idea I am working
> with now is to use the SunOS Lightweight Process library (threads).  Here is the 
> setup:
> 
>   Thread #1:  Main thread - Initializes TCP/IP socket and OLIT Widget structure,
>               splits off Thread #2, and goes into Xt event loop.
> 
>   Thread #2:  Listens for connections to TCP/IP socket - When a connection is 
>               requested, this thread alerts the main thread.  In effect, this thread
>               handles the socket connection handshaking.
> 
> This approach will make the program dependant on SunOS, but I need the multi-threading
> capabilities due to the blocking nature of the listen() call.  Does anyone know of
> another, more-portable way to handle this?
> 

  Try using  XtAddAppInput  .This will register a callback which can process
  input activity on a socket (for a  listen(2)ing socket, this is when something
  tries to connect).

				Regards,

					Richard Gooch....

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 18:49:12 GMT
From:      robelr@ucs.indiana.edu (Allen Robel)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Clarification

Hi,

Don't know if any of you read Communications Week, but
I'd like to clarify something they (mis)quoted me on.

In the April 19 issue "Roadblocks in Network Routing"
(page 103) they say:

    Robel said every time Cisco upgrades its router
    software, network managers have to adjust complex
    tables and codes.

Huh???

    "If we had multiple vendors' routers and [corresponding]
    changing codes every time there's a new software release,
    we would be increasing by many times what we have to 
    check," Robel said.

So Communications Week really does deserve its reputation
as the National Enquirer of the networking world I guess :-)

I didn't say anything about "complex tables and codes." Where
the heck they got that from I'll never know.  What I DID say
was that we were a one router shop because routers are mainly
software-based (and the software is not self-contained i.e.
implements distributed algorithms) and upgrades are hard enough 
to deal with when routing multiple protocols (IP, AppleTalk, 
IPX) in a large campus network without having to worry about 
interoperability problems between different vendors' 
implementations.

Oh well.  If you get a call from CommWeek, I'd suggest
either hanging up the phone or requesting anonymity...

-allen

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 19:11:25 GMT
From:      chk@alias.com (C. Harald Koch)
To:        comp.sys.mac.comm,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Strange MacTCP routing problem

We have a fairly simple corporate internet; five ethernets connected with
two Proteon routers.  We have many Silicon Graphics workstations, and a
whole bunch of Macs.  The Mac users need to be able to login to the SGI
machines, and transfer files. We've been using NCSA Telnet and MacTCP for
this.

Recently, we've been having problems; Telnet is often unable to talk to any
host across the routers. Telnet can reach hosts on the local ethernet OK.
Worse, the problem sometimes magically disappears, only to reappear.

I finally dragged out my network monitoring tools, and figured out (I think)
what's going on. I'm testing with an SE/30 running System 7.0.1, MacTCP
1.1.1, NCSA Telnet 2.5. We have MacTCP configured for Server IP, and several
SGI machines are running BOOTP servers. Also, the routers are configured as
BOOTP helpers (this is important; see below).

When I boot my Mac normally, start NCSA Telnet, and try to connect to
another host across a router, MacTCP sets up the IP portion of the packet
correctly. But instead of forwarding the packet to the appropriate router,
MacTCP sends the packet to the BOOTP server! (I know it's using the BOOTP
server, because it changes each time I reboot my Mac to whichever BOOTP
server responds first). Since the SGI workstations are not routers, they
simply drop the packets, and so I can't connect.

Sometimes, due to the vagaries of packet delivery on a busy network, the
routers reply to the Macs first, before the SGI workstations. When this
happens, everything magically works, because now MacTCP is sending non-local
packets to the routers.

The MacTCP documentation claims that MacTCP monitors RIP traffic on the
local network, looking for gateways. We're running RIP; both routers
broadcast RIP updates every 30 seconds. MacTCP is obviously ignoring these.

I have this strange feeling that I'm missing something obvious here; I find
it difficult to believe that a bug this obvious could still exist. :-)

Can anyone out there help me? EMail replies are preferred; I don't always
have time to check NetNews.

Thanks in advance,


--
C. Harald Koch, Network Manager | "There is no problem, no matter how large or
Alias Research Inc. Toronto, ON | small, that cannot be solved by a suitable
chk@alias.com                   | amount of high explosives."
chk@gpu.utcc.utoronto.ca        |                 -Leo Graf, USS LaFarge, 2298

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 19:14:15 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   Does tcpdump work with for HP/UX? Capturing RAW ethernet?

We have customers who are interested in getting tcpdump to work
on an HP/UX system. Is the HP system able to read packet headers of every
packet on the Ethernet? Can it put the ethernet interface in
promiscuous mode? 

Thanks for any info. 
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 20:04:29 GMT
From:      resnick@cogsci.uiuc.edu (Pete Resnick)
To:        comp.protocols.tcp-ip
Subject:   Re: Sample programs using SunOS' NIT ?

alagu@apple.com (Alagu Periyannan) writes:

>Does anyone know of a public domain program that uses SunOS Network
>Interface Tap (NIT) streams interface. I would like to have the source of
>such a program. I need to write some code that reads, writes and filters
>ethernet packets from a SUN workstation.

How about CAP (Columbia AppleTalk Package)? It implements Apple's
EtherTalk Phase 2 using Sun's NIT interface. CAP can be obtained by
anonymous FTP from

rutgers.EDU             src/{cap60.tar.Z,cap60.patches/*}
munnari.OZ.AU           mac/{cap60.tar.Z,cap.patches/*}
gatekeeper.DEC.COM	pub/net/appletalk/cap/{cap60.tar.Z,cap.patches/*}
ftp.kuis.kyoto-u.AC.JP  net/cap/{cap60.tar.Z,cap60.patches/*.Z}
src.doc.ic.AC.UK        mac/multigate/{cap60.tar.Z,cap.patches/*}

There are 128 odd patches to be applied.

There is also ARNS (AppleTalk Remote Network Server) which is an
AppleTalk packet forwarder for the Sun. It should also be out on
munnari.OZ.AU.

pr
-- 
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: resnick@cogsci.uiuc.edu

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Apr 1993 20:35:27 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: Does tcpdump work with for HP/UX? Capturing RAW ethernet?

> We have customers who are interested in getting tcpdump to work
> on an HP/UX system. Is the HP system able to read packet headers of every
> packet on the Ethernet? Can it put the ethernet interface in
> promiscuous mode? 

Nope.

Some of us have wanted this for a long time. But HP doesn't seem too
interested. This is an extremely good reason to keep at least one Sun
in your network...

Note that HP sells an unbundled STREAMS package which *may* offer some
of the necessary functionality. Note also that HP has something called
nettl which makes it possible to do some tracing and logging of network
events. Note that HP has an interface which allows you to read (and even
write) *some* Ethernet packets.

But you can't make tcpdump out of any of these...

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

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Apr 1993 00:14:58 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.sys.mac.comm,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Strange MacTCP routing problem

In article <1993Apr26.191125.26814@alias.com>, chk@alias.com (C. Harald Koch) writes:
> ...
> When I boot my Mac normally, start NCSA Telnet, and try to connect to
> another host across a router, MacTCP sets up the IP portion of the packet
> correctly. But instead of forwarding the packet to the appropriate router,
> MacTCP sends the packet to the BOOTP server! (I know it's using the BOOTP
> server, because it changes each time I reboot my Mac to whichever BOOTP
> server responds first). Since the SGI workstations are not routers, they
> simply drop the packets, and so I can't connect.

If your MAC software will listen to ICMP redirects or unreachables, try
setting "ipgateway=1" in /usr/sysgen/master.d/bsd/bsd on the SGI boxes,
rebuild the kernels (`/etc/autoconfig`) and reboot.

> Sometimes, due to the vagaries of packet delivery on a busy network, the
> routers reply to the Macs first, before the SGI workstations. When this
> happens, everything magically works, because now MacTCP is sending non-local
> packets to the routers. ...

Or turn off bootp on the SGI boxes by commenting out the bootp line
in /usr/etc/inetd.conf and then `killall -v -HUP inetd`.

Or buy a bunch of 2nd ethernet boards for your SGI boxes, making into
them routers, pleasing your SGI salescritter, and doing the SGI stock
price no harm.


Vernon Schryver,  vjs@sgi.com

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Apr 1993 00:50:29 GMT
From:      "Jeffrey W. Parker" <p00185@psilink.com>
To:        comp.protocols.tcp-ip
Subject:   Free/ShareWare version of TCP/IP for AT&T SYSV/386

Hi there out in netland,
	I have a copy of AT&T Unix version SVR3.2.2/386 that I would like 
to get TCP/IP (telnet, ftp, etc.) support for.  Is there a FTPable 
Free/shareWare version that will support ethernet cards (preferably 
SMC8003 family) that I can compile, configure and run?  Where can I get 
it? 

Any help by Email would be greatly appreciated.

Thanks in advance,
Jeff Parker
p00185@psilink.com


-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Apr 1993 03:16:03 GMT
From:      add@is.rice.edu (Arthur Darren Dunham)
To:        comp.sys.mac.comm,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Strange MacTCP routing problem

In article <1993Apr26.191125.26814@alias.com> chk@alias.com (C. Harald Koch) writes:
>When I boot my Mac normally, start NCSA Telnet, and try to connect to
>another host across a router, MacTCP sets up the IP portion of the packet
>correctly. But instead of forwarding the packet to the appropriate router,
>MacTCP sends the packet to the BOOTP server! (I know it's using the BOOTP
>server, because it changes each time I reboot my Mac to whichever BOOTP
>server responds first). Since the SGI workstations are not routers, they
>simply drop the packets, and so I can't connect.

The default gateway is part of the BOOTP reply.  If it is not set, it
may be defaulting itself (the bootp server).  
>
>Sometimes, due to the vagaries of packet delivery on a busy network, the
>routers reply to the Macs first, before the SGI workstations. When this
>happens, everything magically works, because now MacTCP is sending non-local
>packets to the routers.
>
>The MacTCP documentation claims that MacTCP monitors RIP traffic on the
>local network, looking for gateways. We're running RIP; both routers
>broadcast RIP updates every 30 seconds. MacTCP is obviously ignoring these.

I have this feeling that RIP only works if it doesn't get a gateway by
some other means.  Make sure you are running the latest bootpd and have
explicitly set the mac's IP gateway (In my bootptab it's gw=x.x.x.x).

Any other suggestions?
-- 
Darren Dunham                 		          add@is.rice.edu
MicroConsultant                       		  Rice University
(What is that? A small consultant?)	              Houston, TX
Any resemblance between real opinions and my post is coincidental

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Apr 1993 03:35:41 GMT
From:      pflaum@world.std.com (Greg M Pflaum)
To:        comp.protocols.tcp-ip
Subject:   Re: Sniffer

In a recent article, I wrote:
   > Has anyone written any code to analyze Sniffer data files?  

   [...]
   There is a product which, though it doesn't do analysis, might be of
   interest.  The Protocol Analyzer Trace Translator (PATT) by, I think,
   Pine Mountain, is software which translates between several different
   network capture file formats, including the Sniffer.  This program
   should be standard equipment for any product support group which uses
   a protocol analyzer, as you need not depend upon your customers having
   the same equipment.  (How many times has a Sniffer been FedExed to a
   customer site when a simple software capture utility would do the job?)

   Just a satisfied customer.

I got some requests for info on reaching Pine Mountain Group.  Their
phone number is 209-962-6247.

Greg Pflaum

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Apr 1993 06:24:37 GMT
From:      andy@research.canon.oz.au (Andy Newman)
To:        comp.protocols.tcp-ip
Subject:   ALLO and FTP


I have a question about the ALLO ("allocate") command in FTP. Although
there is a brief mention of ALLO in the RFC that's about all I can
find.

We have a system that is a potential FTP server but due to the simple
file system it uses space must be allocated prior to sending the file.
I've been over the RFCs and can find very little mention of ALLO but
I'm sure others have come across this before.

Questions:

    What other FTP servers require ALLOs? How do they handle
    this at the user interface? Do they force the users to
    use the QUOTE command?
    
Any help in this area will be appreciated.

-- 
Andy Newman (andy@research.canon.oz.au)
"gentle suggestions being those which are written on rocks of less than 5lbs"
				Tracy Nelson in comp.lang.c

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Apr 1993 07:37:04 GMT
From:      vrao@cse.uta.edu (Vinay Rao)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Blocking problem during read of a TCP socket

Hi Netters,
	I have a problem in making a TCP connection work. I have a 
client that does a socket() and then tries a connect() to the server on
another machine. The server as usual does socket(),bind(), listen()
and then accept() 's the connection. My program works fine until the 
connection is established. After this when the client writes to its
socket, the server is supposed to receive it and do some processing
based on the information given by the received client's packets. 
The server gets blocked trying to do a read(). After a while the client
having sent the packet on the TCP connection , will also block waiting 
for reply. 
	My question is whether any of you have come across this odd 
blocking of read on Sun's (SunOS 4.1.2). Is it because of the bugs in
the memory management? Is it because of some messages being too short?
I actually tried to TCP_NODELAY socket option but wasnt of help. 
How can you overcome it? Please let me know .

Any kind of comments or suggestions are welcome.

Thanks

Vinay Rao
vrao@cse.uta.edu


-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Apr 93 07:42:46 GMT
From:      rhk@leland.Stanford.EDU (ROBERT KEELEY)
To:        comp.protocols.tcp-ip
Subject:   Network performance references ?

Hi netters,
	I am interested in finding out more about the performance of
computer networks. As a starting point I am interested in looking 
into the performance of ethernet. I would appreciate if someone
could direct me to some references/simulations on that topic.

Thanks in advance.

Bob


-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 1993 10:20:41 GMT
From:      sundvall@perrier.embnet.se (Mats Sundvall)
To:        comp.protocols.tcp-ip
Subject:   Signals and async communication in SUN OS 5


I have a hard time understanding how signal are delivered in SUNOS 5.1.
There are differences to the BSD behaviour, and the one documented (those
I found) are

SIGPOLL   BSD: are delivered every time data arrives on the port. 
         SYSV: are delieverd only when data arrives to an empty queue.

SIGURG    BSD: are delivered every time urgent data (OOB) arrives on the port.
         SYSV: are delivered only when urgent data arrives and no other urgent
               condition are queued.

This make sense and I wrote a little test program that give the expected behaviour.
Just make sure you read until no more data is available in each IO or URG handling
routine.

I only got the test program to work with OOB data delivered inline. If I do a
recv(s, &oobdata, sizeof(oobdata), MSG_OOB) there's nothing in oobdata.
If it is done inline it works. OK, that I can live with:-<

There is another thing to it. If I send OOB data there is some unknown number
of SIGIO's delivered to the socket before the SIGURG. I have seen 0,1 or 2 SIGIO
coming in. Nothing is there to read from the socket.

Then I go one step further. I now think I understand how signals under SYSV works:->
I am trying to port Mayan Moudgills sstream library to Solaris 2.1.

If you change all signal() to sigset() and some other small changes it all
compile. When I send ordinary IO it work just fine. But when I send OOB data
I end up with SIGIO's delivered before tha SIGURG (se above). I end up in the
iomanager (the SIGIO  handler), BUT, after that no SIGURG is delivered!

What is going on. Maybe I have got it all wrong. I have been staring at my screen
now for several days, and I really need help.

I can't be the first one trying to use these facilities.

Regards,

Mats Sundvall
Dept of Medical Genetics
Uppsala University
Sweden



-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 93 10:25:56 GMT
From:      gdmr@dcs.ed.ac.uk (George Ross)
To:        comp.protocols.tcp-ip
Subject:   Re: SUN's TCP BUG ??

In article <1993Apr26.151259.5170@ra.msstate.edu>, fwp@CC.MsState.Edu (Frank Peters) writes:
> Some administrators use a wrapper around their telnetd that attempts to
> query the remote site's authentication daemon (running on port 113 if
> it is running at all).  If you connect from a PC things "pause" while
> the query times out (during this pause you see packets from the Sun to
> port 113 on the PC) and then the login continues normally.

If there is no listener on TCP port 113 at the PC end then the PC should
immediately reply with a RST, which will be interpreted by the identification
code at the Sun end as an unknown user.  There should be no need to time out. 
If this isn't happening then it's somebody's bug.
-- 
George D M Ross, Department of Computer Science, University of Edinburgh
     Kings Buildings, Mayfield Road, Edinburgh, Scotland, EH9 3JZ
Mail: gdmr@dcs.ed.ac.uk      Voice: 031-650 5147      Fax: 031-667 7209

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Apr 1993 12:32:40 GMT
From:      dedgar@mta.ca
To:        comp.protocols.tcp-ip
Subject:   RFC1115, RSA-MD2 digest algorythm & encryption questions

Hello Net

I have just been reading RFC1115 about the RSA-MD2 digest algorythm. The
question I have about this is:  doesn't the digest or the table used to 
make the digest have to be transmitted by secure channels? - else what would
stop someone making changes to the message just recomputing the digest and 
passing off the message as genuine? I think I must be missing something here.

Are there any public domain algorythms available which would allow a decryption
key to be transmitted along with a multiple recipient message to ensure its 
integerity. I guess this would have to be a kind of public key where a
different (secret) one is used to encrypt and the public one is used to
decrypt.  The intent here is not to hide the contents of the message - but to
ensure its integrity. 

Are there any Public Domain public key algorythms at all? It is
my understanding that the RSA public key algorythm is patented. 

I would sure appreciate advice and information on this topic.
 
                                                  Dale Edgar
                                                  Cybernetic Control Inc.
                                                  DEDGAR@MTA.CA

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Apr 1993 12:59:26 GMT
From:      crj@comserv.itri.org.tw (Robert Ju-ching Chen)
To:        comp.protocols.tcp-ip
Subject:   SUN's TCP Bug ?? The Log file !

Dear Network Fellows:
  I would like to attach the log file we captured by Sniffer. There are	two
stations. We use telnet	from PC	(140.96.1.118) to connect the Sun workstation
(140.96.1.10). And we use ethernet addresses of	these two stations to be
the filter while capturing.

  We placed the	Sniffer	on the same segment of Sun ( 140.96.1.10 ).

  Please notice	that Frame 4, 5	and 6 show the port no of PC is	26174.

  But what happened between Frame 6 and	Frame 7	? There	were 92.6549 seconds
delay between them !!

  From Frame 7 to Frame	11 we can see the same "strange" port no 24750 sent
by Sun ( 140.96.1.10 ).

  And the right	port no	26174 didn't show up until Frame 12. Why ?????

  Thanks for your reply	in advance !

Here we	go !
- - - -	- - - -	- - - -	- - - -	Frame 4	- - - -	- - - -	- - - -	- - - -	-
SUMMARY	 Delta T     Destination   Source	 Summary
     4	  0.0020  [140.96.1.10]	  [140.96.1.118]   TCP D=23 S=26174	ACK=296000001 WIN=1024
TCP:  ----- TCP	header -----
TCP:  
TCP:  Source port = 26174	      <********** port no of PC	 >
TCP:  Destination port = 23 (Telnet)  <********** port no of Sun >
TCP:  Sequence number =	779839
TCP:  Acknowledgment number = 296000001
TCP:  Data offset = 20 bytes
TCP:  Flags = 18
TCP:  ..0. ....	= (No urgent pointer)
TCP:  ...1 ....	= Acknowledgment
TCP:  .... 1...	= Push
TCP:  .... .0..	= (No reset)
TCP:  .... ..0.	= (No SYN)
TCP:  .... ...0	= (No FIN)
TCP:  Window = 1024
TCP:  Checksum = 9846 (correct)
TCP:  No TCP options
TCP:  
- - - -	- - - -	- - - -	- - - -	Frame 5	- - - -	- - - -	- - - -	- - - -	-
SUMMARY	 Delta T     Destination   Source	 Summary
     5	  0.0624  [140.96.1.10]	  [140.96.1.118]   Telnet C PORT=26174 IAC Do Suppress go-ahead
Telnet:----- Telnet data -----
Telnet:
Telnet:IAC Do Suppress go-ahead
Telnet:IAC Will	Terminal type
Telnet:IAC Will	Negotiate about	window size
Telnet:IAC Will	Terminal speed
Telnet:IAC Will	Remote flow control
Telnet:IAC Will	Linemode
Telnet:IAC Do Status
Telnet:IAC Will	unknown	option (36)
- - - -	- - - -	- - - -	- - - -	Frame 6	- - - -	- - - -	- - - -	- - - -	-
SUMMARY	 Delta T     Destination   Source	 Summary
     6	  0.0906  [140.96.1.118]  [140.96.1.10]	   TCP D=26174 S=23	ACK=779863 WIN=4072
TCP:  ----- TCP	header -----
TCP:  
TCP:  Source port = 23 (Telnet)
TCP:  Destination port = 26174
TCP:  Sequence number =	296000001
TCP:  Acknowledgment number = 779863
TCP:  Data offset = 20 bytes
TCP:  Flags = 10
TCP:  ..0. ....	= (No urgent pointer)
TCP:  ...1 ....	= Acknowledgment
TCP:  .... 0...	= (No push)
TCP:  .... .0..	= (No reset)
TCP:  .... ..0.	= (No SYN)
TCP:  .... ...0	= (No FIN)
TCP:  Window = 4072
TCP:  Checksum = 8C4E (correct)
TCP:  No TCP options
TCP:  
- - - -	- - - -	- - - -	- - - -	Frame 7	- - - -	- - - -	- - - -	- - - -	-
SUMMARY	 Delta T     Destination   Source	 Summary
     7	 92.6549  [140.96.1.118]  [140.96.1.10]	   Telnet R PORT=24750 IAC Do Terminal type
	 ^^^^^^^					    ^^^^^^^^^^
     ( a long period ********************** What is going on ? *************)
Telnet:----- Telnet data -----
Telnet:
Telnet:IAC Do Terminal type
- - - -	- - - -	- - - -	- - - -	Frame 8	- - - -	- - - -	- - - -	- - - -	-
SUMMARY	 Delta T     Destination   Source	 Summary
     8	  0.5346  [140.96.1.118]  [140.96.1.10]	   Telnet R PORT=24750 IAC Do Terminal type
							    ^^^^^^^^^^
		    (********************** What is going on ? *************)
Telnet:----- Telnet data -----
Telnet:
Telnet:IAC Do Terminal type
Telnet:IAC Will	Suppress go-ahead
Telnet:IAC Don't Negotiate about window size
Telnet:IAC Don't Terminal speed
Telnet:IAC Don't Remote flow control
Telnet:IAC Don't Linemode
Telnet:IAC Won't Status
Telnet:IAC Don't unknown option (36)           <****** What's this ??>
Telnet:IAC SB ...
- - - -	- - - -	- - - -	- - - -	Frame 9	- - - -	- - - -	- - - -	- - - -	-
SUMMARY	 Delta T     Destination   Source	 Summary
     9	  1.9997  [140.96.1.118]  [140.96.1.10]	   Telnet R PORT=24750 IAC Do Terminal type
Telnet:----- Telnet data -----
Telnet:
Telnet:IAC Do Terminal type
Telnet:IAC Will	Suppress go-ahead
Telnet:IAC Don't Negotiate about window size
Telnet:IAC Don't Terminal speed
Telnet:IAC Don't Remote flow control
Telnet:IAC Don't Linemode
Telnet:IAC Won't Status
Telnet:IAC Don't unknown option (36)
Telnet:IAC SB ...
- - - -	- - - -	- - - -	- - - -	Frame 10 - - - - - - - - - - - - - - - - -
SUMMARY	 Delta T     Destination   Source	 Summary
    10	  3.9996  [140.96.1.118]  [140.96.1.10]	   Telnet R PORT=24750 IAC Do Terminal type
Telnet:----- Telnet data -----
Telnet:
Telnet:IAC Do Terminal type
Telnet:IAC Will	Suppress go-ahead
Telnet:IAC Don't Negotiate about window size
Telnet:IAC Don't Terminal speed
Telnet:IAC Don't Remote flow control
Telnet:IAC Don't Linemode
Telnet:IAC Won't Status
Telnet:IAC Don't unknown option (36)
Telnet:IAC SB ...
- - - -	- - - -	- - - -	- - - -	Frame 11 - - - - - - - - - - - - - - - - -
SUMMARY	 Delta T     Destination   Source	 Summary
    11	  7.9993  [140.96.1.118]  [140.96.1.10]	   Telnet R PORT=24750 IAC Do Terminal type
Telnet:----- Telnet data -----
Telnet:
Telnet:IAC Do Terminal type
Telnet:IAC Will	Suppress go-ahead
Telnet:IAC Don't Negotiate about window size
Telnet:IAC Don't Terminal speed
Telnet:IAC Don't Remote flow control
Telnet:IAC Don't Linemode
Telnet:IAC Won't Status
Telnet:IAC Don't unknown option (36)
Telnet:IAC SB ...
- - - -	- - - -	- - - -	- - - -	Frame 12 - - - - - - - - - - - - - - - - -
SUMMARY	 Delta T     Destination   Source	 Summary
    12	 13.0108  [140.96.1.118]  [140.96.1.10]	   Telnet R PORT=26174 IAC Do Terminal type
							    ^^^^^^^^^^
		    (********************** Recovered !! Why ? *************)
Telnet:----- Telnet data -----
Telnet:
Telnet:IAC Do Terminal type
- - - -	- - - -	- - - -	- - - -	Frame 13 - - - - - - - - - - - - - - - - -
SUMMARY	 Delta T     Destination   Source	 Summary
    13	  0.0018  [140.96.1.10]	  [140.96.1.118]   TCP D=23 S=26174	ACK=296000004 WIN=1021
TCP:  ----- TCP	header -----
TCP:  
TCP:  Source port = 26174
TCP:  Destination port = 23 (Telnet)
TCP:  Sequence number =	779863
TCP:  Acknowledgment number = 296000004
TCP:  Data offset = 20 bytes
TCP:  Flags = 18
TCP:  ..0. ....	= (No urgent pointer)
TCP:  ...1 ....	= Acknowledgment
TCP:  .... 1...	= Push
TCP:  .... .0..	= (No reset)
TCP:  .... ..0.	= (No SYN)
TCP:  .... ...0	= (No FIN)
TCP:  Window = 1021
TCP:  Checksum = 982E (correct)
TCP:  No TCP options
TCP:  

Name	Robert Ju-Ching	Chen
Email	crj%comserv.itri.org.tw@twnmoe10.edu.tw
Addr.	P.O. 9-65 Chutung, Hsinchu, Taiwan 310,	R.O.C.
Tel.	886-35-917558
Fax	886-35-820026

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Apr 1993 13:17:07 +0000
From:      tkr@puffball.demon.co.uk (Tim Rylance)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   IP on IPX?

I may need to tunnel IP over a wide-area IPX network.  Does anyone know
of any products that do this?  Free or commercial, RFC1132 or not, any
reasonable hardware considered.

The politics of this requirement are left to the reader's imagination.

Thanks in advance

--- Tim Rylance, Bath, UK --------------- <tkr@puffball.demon.co.uk> ---

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Apr 1993 14:00:05 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Strange MacTCP routing problem

In article <C64H2s.As8@rice.edu>, add@is.rice.edu (Arthur Darren Dunham) writes:
> In article <1993Apr26.191125.26814@alias.com> chk@alias.com (C. Harald Koch) writes:
> >When I boot my Mac normally, start NCSA Telnet, and try to connect to
> >another host across a router, MacTCP sets up the IP portion of the packet
> >correctly. But instead of forwarding the packet to the appropriate router,
> >MacTCP sends the packet to the BOOTP server! (I know it's using the BOOTP
> >server, because it changes each time I reboot my Mac to whichever BOOTP
> >server responds first). Since the SGI workstations are not routers, they
> >simply drop the packets, and so I can't connect.
> 
> The default gateway is part of the BOOTP reply.  If it is not set, it
> may be defaulting itself (the bootp server).  
> >
> >Sometimes, due to the vagaries of packet delivery on a busy network, the
> >routers reply to the Macs first, before the SGI workstations. When this
> >happens, everything magically works, because now MacTCP is sending non-local
> >packets to the routers.
> >
> >The MacTCP documentation claims that MacTCP monitors RIP traffic on the
> >local network, looking for gateways. We're running RIP; both routers
> >broadcast RIP updates every 30 seconds. MacTCP is obviously ignoring these.
> 
> I have this feeling that RIP only works if it doesn't get a gateway by
> some other means.  Make sure you are running the latest bootpd and have
> explicitly set the mac's IP gateway (In my bootptab it's gw=x.x.x.x).


The original author complained that things failed if an SGI box
answered the MAC's bootp request.

The SGI bootp daemon does not support the vendor specific IP-gateway
field mentioned in RFC-1048.

You could either port another bootp to the SGI boxes, or simply
turn off bootp on the SGI boxes.



Vernon Schryver,  vjs@sgi.com

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Apr 1993 14:42:55 GMT
From:      dawkins@bnr.ca (Spencer Dawkins)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing: books, literature wanted

In article <1qudnhINNck3@nanette.sto.pdb.sni.de> Martin W Freiss <freiss.pad@sni.de> writes:
>Hi,
>
>this is not really about TCP/IP, but about routing in general. I just figure
>that this group has the readership I'm looking for :-)
>I'm looking for some literature about routing. I've read most of the
>RFCs about BGP/EGP/RIP/OSPF, hope that I've understood most of what I
>read, but have the nagging feeling that I miss some basic theory.
>I'd be grateful for tips on what to read and where to look for
>(electronically available?) information on the topics
>
>- link state vs distance vector algorithms
>- the mathematics involved in "best path discovery" and propagating
>  topology changes 


I just finished reviewing Radia Perlman's "Interconnections: Bridges and
Routers", Addison-Wesley, 1992, for IEEE Software. The first half of the
book is about Bridges and discusses transparent bridging, spanning trees,
and source route bridging, and sounds like it would mostly be useful to
you as background. The second half covers network-layer routing, route
discovery, routing table propagation, and lots of specific protocols (OSPF,
IS-IS, and (if I remember correctly) BGP, EGP, RIP, and other similar
protocols. It sounds like just what you want.

Yes, it probably should have been subtitled "Bridges OR Routers". There is
minimal overlap, and Perlman believes strongly in routing these days.

I can't say enough good things about this book. It really opened my eyes
about lots of network-side topics I had a very hazy idea of. (Anyone can
explain spanning tree intuitively; Perlman actually explains it well enough
for you to understand when it works well and when it would work poorly,
for instance.)

Since IEEE has me sign an assignment of copyright form for these reviews,
I think they would prefer that I not "publish" my review, before it appears
in IEEE Software, in this forum. I would be delighted to send copies via
E-mail ("private correspondence", as they say in the bibliography section
of dissertations) to anyone who wants one;

I am dawkins@bnr.ca, if you are interested.
-- 
------------------------------------------------------------------------------
-  Spencer Dawkins			Bell-Northern Research	             -
-  (214) 684-4827			P.O. Box 833871                      -
-  Internet: dawkins@bnr.ca		Richardson TX 75083-3871             -

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 93 15:14:55 GMT
From:      rjc@cc.gatech.edu
To:        comp.protocols.tcp-ip
Subject:   WKS entries in Domain Name Systems


The Domain Name System has a record for IN class entries that
lists Well Known Services (WKS) available on the indicated host.
(eg ftp,telnet,...) 

My somewhat random search of DNS servers indicates that only a 
very few host entries actually contain a WKS entry.

Does anybody out there know of any client applications that actually
make use of this information when it is available? I'm interested in
any consumers of this information from both commercial and research 
applications.

Thanks!

Russ Clark
College of Computing, Georgia Tech, Atlanta, GA 30332-0280
rjc@cc.gatech.edu

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Apr 1993 15:22:40 GMT
From:      sven@anl433.erlm.siemens.de (Sven Werner)
To:        comp.protocols.tcp-ip
Subject:   Routing under UNIX

Hi,
i have a routing-problen under UNIX. I have two networks. The networks
are connectet over a gateway. The gateway is a unix-host with two
interface-cards. The topologie is:

                                  Gateway
+--------------+       +---------------------------+
|host1         |       |host2        |host3        |
|194.25.52.39  |-------|194.25.68.1  |194.25.63.12 |------...
|              |       |             |             |
+--------------+       +---------------------------+

I will connect the host 2, so i must set the command on host1:

route add net 194.25.68.0 host1 0

Then, the command "ping host2" works correct.

I will connect host3, so i must set the command on host1:

route add net 194.25.63.0 host2 1

But i receive a error:  add net 194.25.63.0: gateway host2: L: Network is
                                unreachable

Can anybody help me??

Thank you, Sven.
--
+-----------------------+------------------------------------------+
| Sven Werner           | e-mail         sven@erlm.siemens.de      |
| Siemens AG            |------------------------------------------|
| ANL A433-SZ           | phone (voice)  +49-911-3089-288          |
| Gruendlacher Str. 248 |       (fax)    +49-911-3089-290 or 656   |
| W-8510 Fuerth-Bislohe |------------------------------------------|
|        ============== | ham radio (tcp/ip) dg1hqo@db0rt.ampr.org |
|        GERMANY        |           (ip)     [44.130.87.9]         |
|                       |           (box)    dg1hqo@db0box.deu.eu  |
+-----------------------+------------------------------------------+

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Apr 1993 16:20:19 GMT
From:      cyc@quip.eecs.umich.edu (Yi-Chieh Chang)
To:        comp.protocols.tcp-ip
Subject:   SLIP modem connection for PC

 I would appreciate anybody on the net can share his/her experience
of using/installing SLIP (Serial line interface protocol ?) to
connect PC to a host machine (such as a workstation) by using the 
modem on the phone line. As I heard that on SLIP, the PC can send its 
IP address to the host machine, just like 'rlogin' or 'ftp' on the
ethernet line, how does SLIP work in this way ? I would appreciate 
any response. Thanks.

Yi-Chieh

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 93 18:27:37 GMT
From:      nam@bach.esl.com (Nam Nguyen)
To:        comp.protocols.tcp-ip
Subject:   SLIP in vxWorks

Is SLIP code for VxWorks available in the public domain?

I am implementing a SLIP connection between two hosts, a Sun SPARC
station and an embedded FORCE 68040B board running VxWorks.  With
the porting of CSLIP (from the net) into my SUN and the availability
of SLIP driver in VxWorks, the default SLIP connection is working 
fine.  These default setups treated the IP physical interface as dumb
serial terminals.  So when I have some other devices as the interface
to the serial port, SLIP is not working.  With the code from the
net, I can modify SLIP on the SUN side; however, I do not have
SLIP code for VxWorks.

I wonder if the SLIP code for VxWorks is available in the public
domain.  If any netter knows about this, please let me know at the
above email address.  I would appreciate your information very, very
much.

Thank you,

Nam 


-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 1993 19:18:54 GMT
From:      scoggin@delmarva.com (John K Scoggin Jr)
To:        comp.protocols.tcp-ip
Subject:   X-Archie through a Firewall

I am trying to fire up xarchie-2.0 through my firewall.  I have started a packet
passer on port 1525, but have been unable to reach archie.sura.net.  Is there 
another port in use, as well?

	- John

---
+---------------------------------------------------------------------+    
|  John K. Scoggin, Jr.			Email: scoggin@delmarva.com   |
|  Supervisor, Network Operations       Phone: (302) 451-5200         |
|  Delmarva Power & Light Company       Fax:   (302) 451-5321         |
|  500 N. Wakefield Drive               NOC:   (800) 388-7076         |
|  Newark, DE 19714-6066		                              |
|  The opinions expressed are not those of Delmarva Power, simply the |
|  product of an over-active imagination...                           |
+---------------------------------------------------------------------+


-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Apr 1993 19:23:30 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing under UNIX

Sven.Werner%anl433.uucp@Germany.EU.net writes: 

>i have a routing-problen under UNIX. I have two networks. The networks
>are connectet over a gateway. The gateway is a unix-host with two
>interface-cards. The topologie is:
>
>                                  Gateway
>+--------------+       +---------------------------+
>|host1         |       |host2        |host3        |
>|194.25.52.39  |-------|194.25.68.1  |194.25.63.12 |------...
>|              |       |             |             |
>+--------------+       +---------------------------+

This sketch doesn't really make sense.  Do you realize that the IP addresses,
194.25.*52*.39 and 194.25.*68*.1 are on different networks?  Or at least, the
software will automatically *believe* they are, since they have different net
addresses by definition.

>I will connect the host 2, so i must set the command on host1:
>
>route add net 194.25.68.0 host1 0
>
>Then, the command "ping host2" works correct.
>
>I will connect host3, so i must set the command on host1:
>
>route add net 194.25.63.0 host2 1
>
>But i receive a error:  add net 194.25.63.0: gateway host2: L: Network is
>                                unreachable

But of course.  You have not yet told host1 how to reach the 194.25.68 net
(which host2 is on) yet?  How can it reach host2 to use it as a gateway for
the 194.25.63 net?

Fred

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Apr 93 19:54:35 GMT
From:      fred_s@kalpana.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP through a Router?

pmfranc@afterlife.ncsc.mil. (Paul M. Franceus) writes: 

>In article <fred_sC5vKwt.GL7@netcom.com> fred_s@netcom.com (Frederick Scott)  
>writes:
>> tli@cisco.com (Tony Li) writes: 
>> 
>> >RARP is an unroutable protocol.  It must be bridged.
>> 
>> More specifically, I believe RARP is a *broadcast* protocol (at least the
>
>Actually, the first poster was correct.  ARP/RARP is not an IP based protocol,
>and therefore not routable.

Nonsense - there are lots of packet types which are not IP based protocols
and still routable.  Just not by *IP* routers.

On the other hand, a bootp broadcast packet certain *is* an IP based
protocol packet, but isn't normally routed, either.  Why is that, do you
think?

And by the way, I was not suggesting Tony Li was not correct - just
clarifying why RARP packets are not routed as a policy.  It's not simply
because they don't happen to be IP packets - it's because of the necessity
of utilizing the broadcast feature.

Fred

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Apr 1993 20:01:27 GMT
From:      robertt@n154.mentor.stortek.com (Robert Thompson (robertt))
To:        comp.protocols.tcp-ip
Subject:   PCNFS Name Mangling



--
Is there any way to keep PCNFS from mangling the name of valid DOS file
names ?   More specifically, I have a file name (i.e. SETUP.EXE) that is
all upper case on the mounted file system.  When I look at it on my PC I
get something like SE~~~~1A.TXT.  I want to see 'SETUP.TXT'.

Any ideas ?

Thanks

-Robert


------------------------------------------------------------------------------
Robert Thompson                       |  Storage Technology Corporation
Redwood Digital Hardware Design Team  |  2270 South 88th. Street
(303) 673-7747   FAX: (303) 673-2568  |  Louisville, Colorado 80028-0211
--------------------------------------+---------------------------------------
Please don't rely on the header for replies; use  robertt@n33.stortek.com
------------------------------------------------------------------------------

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 1993 20:48:19 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Strange MacTCP routing problem

In article <C64H2s.As8@rice.edu> add@is.rice.edu (Arthur Darren Dunham) writes:
>I have this feeling that RIP only works if it doesn't get a gateway by
>some other means.  Make sure you are running the latest bootpd and have
>explicitly set the mac's IP gateway (In my bootptab it's gw=x.x.x.x).

Actually, MacTCP is really stupid about this.  RIP data takes precedence
over BOOTP or hard-configured routers.  If that RIP packet says, "I don't
know any routes to anywhere", the Mac will cheerfully decide it has no
idea how to route anywhere, regardless of what routers it already knows
of.

Macs will also grab the BOOTP "gi_addr" field as a gateway, as will many
PC implementations, which is incorrect because this field is only a BOOTP
forwarder, not a full gateway.  I don't know whether the data in this
field takes precedence over RIP information.  The RIP info definitely
takes precedence over a gateway sent in the RFC 1084 vendor extensions
or configured in with the Admin utility.

It's all rather brain-dead.  We don't use RIP here, so we've had problems
with people setting up new workstations to broadcast RIP.  It tends to
make every Mac we have forget how to get off-campus.  This seems to happen
especially often with new SGIs -- maybe they come out of the box configured
to broadcast RIP??

-- 
Stephen Trier                     Work: trier@ins.cwru.edu
Network Software Engineer         Home: sct@po.cwru.edu
IRIS/INS/T
Case Western Reserve University

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 93 19:11:28 +0100
From:      mcspimf@dct.ac.uk
To:        comp.protocols.tcp-ip
Subject:   SLIP help needed!!!

I have some queries about SLIP.

1. Can someone briefly tell me exactly what SLIP does and what the advantages
   and disadvantages of using it are.

2. Is there a version of SLIP for running on an IBM PC. Would this allow me to
   dial into a Unix box that also had SLIP installed.

3. Does SLIP only come in the form of generic source code that has to be edited
   for each platform or is there ready-to-compile SLIP code available for PC's.

4. Are there any other TCP/IP comms packages for PC's that do the same or
   similar to SLIP. If so, what are they and where are they?

5. If SLIP is available for PC's where (preferably in the UK) can I obtain it.

If anyone can help me, please e-mail me your reply. Thanks, MF.

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 1993 21:06:11 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: SUN's TCP BUG ??

In article <C650z8.6qp@dcs.ed.ac.uk> gdmr@dcs.ed.ac.uk (George Ross) writes:
>If there is no listener on TCP port 113 at the PC end then the PC should
>immediately reply with a RST, ...

A surprisingly large number of PC implementations don't send the RST
or send an incorrect RST.

-- 
Stephen Trier                     Work: trier@ins.cwru.edu
Network Software Engineer         Home: sct@po.cwru.edu
IRIS/INS/T
Case Western Reserve University

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 1993 23:17:47 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: WKS entries in Domain Name Systems

In article <1993Apr27.151455.4808@cc.gatech.edu> rjc@cc.gatech.edu () writes:
>My somewhat random search of DNS servers indicates that only a 
>very few host entries actually contain a WKS entry.

True.  WKS records were a half-thought-out way to allow hosts to
"broadcast" what IP services they support, without resorting to
actually connecting to the host (which was thought to be too expensive
or unreliable).  In reality, WKS records are either inaccurate or
missing so often that the data they provide is useless.  E.g. if you
want to know wether a host supports SMTP, it's better just to try to
connect to it on the SMTP port, rather than check DNS first and if the
record exists hope that it is correct and return an error the user.
(same goes for NNTP, DNS, etc)

>Does anybody out there know of any client applications that actually
>make use of this information when it is available? I'm interested in
>any consumers of this information from both commercial and research 
>applications.

All reports seem to say there are none.  (At least none worth
considering, definately none that rely on them).  If you're considering
using WKS in your application, don't.  I suspect WKS will be
undocumented/unsupported in the not-to-distant future.  (It isn't true
yet in the upcoming BIND 4.9 release, however.)

--Dave
-- 
System Administrator, Penn State Population Research Institute
#define ENOTTY          25              /* Not a typewriter */

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Apr 1993 23:21:40 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Strange MacTCP routing problem

In article <1rk66j$8ec@usenet.INS.CWRU.Edu>, trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:
> ...
> It's all rather brain-dead.  We don't use RIP here, so we've had problems
> with people setting up new workstations to broadcast RIP.  It tends to
> make every Mac we have forget how to get off-campus.  This seems to happen
> especially often with new SGIs -- maybe they come out of the box configured
> to broadcast RIP??

Nope.

We ship a slightly extend 4.3BSd routed (mostly support for SLIP and
multi-homed hosts), which is by default silent unless the machine has
more than one network interface.  If the machine has more than one
network interface, routed is by default active.  This can be turned off
with `chkconfig routed off; chkconfig gated off` to turn off both
routed and gated.  Or `echo -q > /etc/config/routed.options`.

Of course, when routed starts, it broadcasts a query to discover
routers.  You'd hope the MAC code would not interpret that empty query
as an offer to route anything anywhere.

(Yes, router-discovery would be nice, as soon as many routers support
it, and as soon as someone here gets a chance to hack it into
something, probably routed so that the default configuration can
automatically discover routes whether RIP or router-discovery is in
use.)


Vernon Schryver,  vjs@sgi.com

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Apr 1993 23:47:49 GMT
From:      daniel@ing.puc.cl (Daniel Hirschberg)
To:        comp.protocols.tcp-ip
Subject:   PCroute: new patch!

	Some time ago I posted this... maybe someone in this group is
interested too:

from comp.protocols.tcpip.ibmpc:

   I've been working around some time with Vance Morrison's PCrouter and
always missed a way to configure it remotely...

   A couple of days ago finally got it! I wrote a patch that makes PCrouter
exit to DOS upon request (a special kind of ping, which I called plop).
It then continues with the rest of the autoexec.bat, which calls a packet
driver and then Erick Engelke's telnetd, which upon exit (or lost connection)
reboots, starting PCroute again, and so on!

Current Features:

	-passwd protected: a password is hard wired upon compilation to 
	avoid unwanted reboots, and telnetd also requests for a passwd
	to open connection.

	-remote reboot: modified telnetd will reboot if it doesn't
	get a connection in 3 minutes.

	-remote configuration: config can be called from the telnet session
	provided by telnetd. 	

	-software upgrade: if used in combination with pktmux, its possible
	(I do it) to ftp to and from the downed PCrouter.


   I have'nt got this stuff nicely documented yet nor really fully tested it,
but if any one wants to give it a try...

	A temptative package has been put in the anonymous ftp at our
local machine: malloco.ing.puc.cl (146.155.1.43),

it's in pub/pc/net/pcrpatch.zip

get at the same time the files that are highlighted when changing to the
net subdir (ftp06.zip & pktmux11.exe I guess), you'll probably want them!

If you have any problem downloading these files through ftp let me know and I
will mail them to you!

If you need help or have any comments,
--- 
       _______________________
      /\                      \
      \_| Daniel Hirschberg J. |
        | daniel@ing.puc.cl    |
        | Santiago, CHILE.     |
        |   ___________________|_
  	 \_/____________________/
 

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 1993 00:25:03 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Network performance references ?

In article <1993Apr27.074246.16010@leland.Stanford.EDU> rhk@leland.Stanford.EDU (ROBERT KEELEY) writes:
>	I am interested in finding out more about the performance of
>computer networks. As a starting point I am interested in looking 
>into the performance of ethernet. I would appreciate if someone
>could direct me to some references/simulations on that topic.

There have been too many papers written about Ethernet performance.
I share the blame for one of them:
      David R. Boggs, Jeffrey C. Mogul, Christopher A. Kent.
      Measured Capacity of an Ethernet: Myths and Reality.
      In Proc. SIGCOMM '88 Symposium on Communications Architectures and
         Protocols, pages 222-234.  ACM SIGCOMM, Stanford, CA, August, 1988.

A somewhat revised version is available as WRL Research Report 88/4.
Send mail to "wrl-techreports@wrl.dec.com" with "Subject: help" to
find out how to order.  Don't ask me.

This paper has a fairly extensive bibliography pointing at other
relevant papers, but that's about 5 years out of date by now.

-Jeff

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 1993 07:01:18 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: WKS entries in Domain Name Systems

In article <1993Apr27.151455.4808@cc.gatech.edu> rjc@cc.gatech.edu () writes:
>Does anybody out there know of any client applications that actually
>make use of this information when it is available? I'm interested in
>any consumers of this information from both commercial and research 
>applications.

Symbolics Lisp Machines try to use them.  The networking software on this
system hides protocol dependencies behind generic interfaces; for instance,
there's a single program for initiating a remote login, and it will use
TELNET or SUPDUP over TCP/IP or Chaosnet, raw terminal emulation over a
serial line or modem, whatever is appropriate over DECnet, etc.  When there
are multiple protocols available over a medium, it tries to use the WKS
information to decide which to use.

As someone else pointed out, this information is usually lacking or
inaccurate.  I made some local modifications to the routines that choose
protocols so that per-OS and global defaults could be specified.  So my
systems assume that every system supports TCP/TELNET, TCP/FTP, TCP/FINGER,
UDP/TIME, etc., and that Unix systems support TCP/SHELL.

My pet peave, though, is the missing HINFO records.  On top of the generic
network system, these machines implement a generic remote file system.  But
in order to know how to parse file names on a server (e.g. the response to
an FTP LIST command), it needs to know the server OS.  I've been tempted to
work around this by patching the file service client code to default to
UNIX if it can't find the client OS.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Apr 1993 09:19:12 GMT
From:      ray@exicom.OZ.AU (Ray Soo)
To:        alt.internet.services,alt.best.of.internet,comp.protocols.tcp-ip
Subject:   has anybody read the "Internet System Handbook"?

apparently there is a new book called the "Internet System Handbook"
( edited by Daniel Lynch and Marshall Rose )
which is supposed to be pretty good.

Has anybody out there come across it?

I would like to know what the subject matter of the book is and how 
(if at all) it differs from the many Internet user guides we are seeing
come out in the bookstores these days. If anyone could provide
a few chapter headings, that would probably give me a feel for the content

I'd also like to know the ISBN number, publisher and price, if possible

If you can help, please EMAIL your reply to : ray@exicom.OZ.AU

thanks in advance,

ray

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Apr 1993 09:30:50 GMT
From:      sven@anl433.erlm.siemens.de (Sven Werner)
To:        comp.protocols.tcp-ip
Subject:   Secondary ip address on wd-card

Hi,

how can I create a secondary ip address on one interface card.
I have a wd-card (8013) and work under Interactive UNIX.

Thank you,   Sven.

--
+-----------------------+------------------------------------------+
| Sven Werner           | e-mail         sven@erlm.siemens.de      |
| Siemens AG            |------------------------------------------|
| ANL A433-SZ           | phone (voice)  +49-911-3089-288          |
| Gruendlacher Str. 248 |       (fax)    +49-911-3089-290 or 656   |
| W-8510 Fuerth-Bislohe |------------------------------------------|
|        ============== | ham radio (tcp/ip) dg1hqo@db0rt.ampr.org |
|        GERMANY        |           (ip)     [44.130.87.9]         |
|                       |           (box)    dg1hqo@db0box.deu.eu  |
 +-----------------------+------------------------------------------+

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 1993 12:20:45 +0100
From:      cudep@csv.warwick.ac.uk (Ian Dickinson)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   SLIP software options for SunOS 4.1.1u1

I have a Sun 3/50 running SunOS 4.1.1u1 at home which I want to run SLIP on.

The other end of the connection is an Annex set up to accept
normal or compressed SLIP.  The connection would be at 19200 between
both end points and the modems, and the modems would be running at 9600
with V.42/V42bis or MNP5.

Would I be better off running a normal or a compressed SLIP on my Sun?
Would compressed SLIP interfere with the modem compression?

I have cslip-2.6.  Is there a newer version?
If uncompressed SLIP would be better in this situation,
what would be the best implementation to install?

Cheers,
-- 
\/ato - Ian Dickinson - NIC handle: ID17          This article is dedicated to
vato@csv.warwick.ac.uk  ...!uknet!warwick!vato        those who disapprove but
/I=I/S=Dickinson/OU=CSV/O=Warwick/PRMD=UK.AC/ADMD= /C=GB/          continue to
@c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson      read

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 1993 14:43:25 GMT
From:      litauer@informatik.uni-koblenz.de (Christoph Litauer)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   broadcast to 2 physical subnets

I have 1 Sparc with two interfaces, each representing a subnet. I set up
my routes and all works well, but ...
My NIS master server (brian) is in one subnet, a slave server (ward) 
connected to the other. If the router is is not a slave server, ward
cannot find it's NIS server, because ypbind tries to find it by using
broadcasts. 
To formulate my question more general: Is it possible to forward
broadcasts between two physical subnets? If yes, what broadcast address
do I have to use?

My environment:
	netmask: 0xfffffc00
	IP address of 1st interface of the router: 141.26.4.17
	IP address of 2nd interface of the router: 141.26.12.1
	IP address of brian: 141.26.4.22
	IP address of ward : 141.26.12.26


Please e-mail, because I don't read this newsgroup so much.

Thanks in advance.

-------------------------------------------------------------------------------
Christoph Litauer                                  litauer@infko.UUCP      
Universitaet Koblenz,                              litauer@infko.uni-koblenz.de
Rechenzentrum,                                     Voice: +49 261 9119-641
Rheinau 3-4, D-5400 Koblenz, Germany               Fax:   +49 261 9119-499
-------------------------------------------------------------------------------

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Apr 1993 14:48:34 GMT
From:      carlson@steam.Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: What/Where is 'rtelnet'?

"rtelnet" is a daemon that is shipped with Xylogics' Annex terminal
servers, which are sold by OEMs (such as Sun Microsystems) and other
distributors.

The rtelnet program acquires a master/slave pseudo-terminal pair on your
host system.  When the slave side is opened, rtelnet opens a telnet
protocol connection to a serial port on the terminal server and begins
transferring data between the port and the pty.

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

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 93 15:09:26 GMT
From:      mart@csri.toronto.edu (Mart Molle)
To:        comp.protocols.tcp-ip
Subject:   Re: Network performance references ?

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

>In article <1993Apr27.074246.16010@leland.Stanford.EDU> rhk@leland.Stanford.EDU (ROBERT KEELEY) writes:
>>	I am interested in finding out more about the performance of
>>computer networks. As a starting point I am interested in looking 
>>into the performance of ethernet. I would appreciate if someone
>>could direct me to some references/simulations on that topic.
 
>There have been too many papers written about Ethernet performance.
>I share the blame for one of them:
>      David R. Boggs, Jeffrey C. Mogul, Christopher A. Kent.
>      Measured Capacity of an Ethernet: Myths and Reality.
>      In Proc. SIGCOMM '88 Symposium on Communications Architectures and
>         Protocols, pages 222-234.  ACM SIGCOMM, Stanford, CA, August, 1988.
 
>A somewhat revised version is available as WRL Research Report 88/4.
>Send mail to "wrl-techreports@wrl.dec.com" with "Subject: help" to
>find out how to order.  Don't ask me.
 
>This paper has a fairly extensive bibliography pointing at other
>relevant papers, but that's about 5 years out of date by now.

And as I pointed out to Jeff years ago, he has included a major blunder
in his bibliography, but not the subsequent retraction/correction.
In particular, section 2.4.6 (of the Sigcomm '88 paper, at least) talks
about a 1985 by Takagi and Kleinrock, which gives a throughput analysis
of unslotted 1-persistent CSMA/CD.  The results of this paper are completely
wrong, and were corrected in a pair of short articles in the Feb. 1987
issue of IEEE Trans. Comm. by Sohraby et al. [I am one of the authors]
and by Takagi and Kleinrock.

Boggs et al. says about the Takagi and Kleinrock paper:
	"one interesting result is that [...] for very small
	values of this parameter [== collision detect time,
	like Ethernet] there is a double peak in the curve."
Both this "camel's hump" shape -- and the fact that it peaked
at only 53% efficiency, even assuming the best values for propagation
time and collision detect time -- are artifacts of a modelling
error in the paper.  The correct analysis [and, indeed, the
measurements reported by Boggs et al.] shows that peak efficiencies
of 90% are possible, and that there is no double peak.

Mart L. Molle
Computer Systems Research Institute
University of Toronto
Toronto Canada M5S 1A4
(416)978-4928

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 1993 15:20:03 GMT
From:      scoggin@delmarva.com (John K Scoggin Jr)
To:        comp.protocols.tcp-ip
Subject:   Re: Network performance references ?

You may want to look at:

Fortier and Desrochers.  Modeling and Analysis of Local Area Networks.
	CRC Press:Boston. 1990. ISBN 0-8493-7405-7

	- John

---
+---------------------------------------------------------------------+    
|  John K. Scoggin, Jr.			Email: scoggin@delmarva.com   |
|  Supervisor, Network Operations       Phone: (302) 451-5200         |
|  Delmarva Power & Light Company       Fax:   (302) 451-5321         |
|  500 N. Wakefield Drive               NOC:   (800) 388-7076         |
|  Newark, DE 19714-6066		                              |
|  The opinions expressed are not those of Delmarva Power, simply the |
|  product of an over-active imagination...                           |
+---------------------------------------------------------------------+


-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Apr 1993 15:32:44 GMT
From:      jcarroll@Scotia-McLeod.Com (Jim Carroll)
To:        comp.protocols.tcp-ip
Subject:   rcp reliability

Greetings, all!

We have a job which rcp's a database export from one host to another.
Both hosts are Pyramids, running the same o/s.

The vendor of the software which was key in driving this project
is now questioning the reliability of rcp (possibly because
we had prior NFS problems between Sun (client) and Pyramid
(server) which are no longer relevant).

A few of us here feel very confident in the robustness of rcp,
but we'd like to hear some reassurances in this regard.
Please be as explicit as you feel is required.  In fact,
if you feel an RFC or similar supporting document is worth
retrieving, please say so.  

Since I'm not intimately familiar with where to find RFC's, 
please be specific where to retrieve it from, as I need to 
use an FTP mailserver to retrieve them.

In other words, I'd like to be able to go back to the
decision makers with an iron-clad argument.

Any volunteers?	  :-)

Replies via e-mail preferred....

-- 
Jim Carroll                   | "Big fleas have little fleas,
ScotiaMcLeod Inc., Toronto    |  upon their backs to bite 'em,
Ontario, Canada               |  and little fleas have lesser fleas,
jcarroll@Scotia-McLeod.Com    |  and so, ad infinitum."

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Apr 1993 16:21:07 GMT
From:      tdnguyen@eecs.uic.edu (T)
To:        comp.protocols.tcp-ip
Subject:   Interoperability Convention

Does anyone has the info on the interoperability convention ? (tie, date, location, 
etc.) Or did I miss it ? Thank you. 
---
-------------------------------------

Tyndall D. Nguyen			

University of Illinois at Chicago

(708) 574-7424 ext. 2509
tdnguyen@earth.eecs.uic.edu

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




-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Apr 1993 21:32:56 CDT
From:      Bob Jackiewicz <U09046@uicvm.uic.edu>
To:        comp.protocols.tcp-ip
Subject:   Good book on programming Sockets?

I was wondering if anyone could point me to a good sockets programming
book, pref for C. I'm interested in the basics, with a good explanation
of the most common functions, as well as advanced. An overview of sockets
in general would also be nice. Thanks in advance. Please e-mail directly,
as I don't read this group.

  Brought to you by the sick mind of      University of Illinois at Chicago
  Bob Jackiewicz, writer of wrongs,                    BITNET: U09046@UICVM
  wronger of rights; not UIC.                InterNet: U09046@uicvm.uic.edu
  Windows - The Gates of hell.


-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Apr 1993 17:58:43 GMT
From:      randy@psg.com (Randy Bush)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.mail.sendmail,comp.mail.misc
Subject:   possible interoperability problem with Star*Nine products

Date: Wed, 28 Apr 1993 11:12:50 -0400 (EDT)
From: John C Klensin <KLENSIN@INFOODS.UNU.EDU>
Subject: EHLO interoperability problem warning
To: ietf-smtp@dimacs.rutgers.edu
Message-id: <736009970.401103.KLENSIN@INFOODS.UNU.EDU>

This is an early warning, to save others some diagnosis time.

I've had a number of interoperability problems with EHLO reported to me
that involve mysterious behavior on the part of SMTP servers.  The
servers in question do not give a clue to their identity in the "220"
message with which they open the SMTP connection, making exact
identification difficult.

All of those that have been identified so far are gateway products from
a company called Star*Nine.  They make SMTP gateways for various LAN
mail products, primarily or exclusively Mac-based (MSMail, QuickMail,
etc. (probably all (tm) of their various owners)).  I understand 
Microsoft resells one of those products under its own name.

Detailed tracing of the mail transactions reveals symptoms like the
following.  It is not clear that all of these products, or all
releases, exhibit exactly the same behavior, but there is clearly a
common core.

(1) All of these products will close connections from the server end if
they get adequately confused.  The close occurs after a command is
sent; 221 or 421 replies are not sent first.  Connecting to the same
server multiple times and issuing a problematic sequence of commands
will always get the connection dropped, but one can sometimes issue
more commands before the close than other times.  In other words, the
point at which the connection is closed is either random or depends on
properties I don't yet understand.
  See (5) below.

(2) These products respond to unknown commands (including EHLO) with
502 (command not implemented) codes, not the more usual 500 (syntax
error).  Usually the command sent is used as the text of the reply
message, but sometimes there is no text (some clients don't like that).
Log entries, when they can be obtained, often indicate 'expected helo'.

(3) Few, if any, of these products recognize and support VRFY.

(4) There is some evidence that RSET is not supported properly.

(5) The following sequence, critical to the successful operation of
RFC1425, will usually result in a closed connection after the RSET,
HELO, or MAIL FROM commands are sent.  I've only been able to send MAIL
FROM once, and have observed the connection closing after only EHLO has
been sent.  I have never successfully gotten mail through after sending
EHLO, but may just have been unlucky.  Reply message texts are omitted
from what follows, and sometimes don't appear (see above).
    Sender: EHLO infoods.mit.edu
    Receiver: 502
    Sender: RSET
    Receiver: 502 (some times/versions), 250 (other times/versions)
    Sender: HELO infoods.mit.edu
    Receiver:  ??  (no log of this code, 250 assumed)
    Sender: MAIL FROM:<user@domain>
   (connection is always closed before this reply comes back)
Of course, no attempt was made to stream these transactions.

(6) A sequence of VRFY and EXPN commands will also produce the 502
errors and connection-closing behavior.   So we aren't breaking
anything that wasn't broken already, we are just stimulating the
behavior more often.  However, clients that routinely send EHLO to open
connections are going to have trouble communicating with these servers.

If anyone knows the Star*Nine folks and can get their attention about
getting this straightened out, it would probably be a good idea :-(

   john


--
randy@psg.com   ...!uunet!m2xenix!randy

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 1993 19:07:17 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Re: IP on IPX?

In article <C658wK.2tF@puffball.demon.co.uk> tkr@puffball.demon.co.uk (Tim Rylance) writes:
>I may need to tunnel IP over a wide-area IPX network.  Does anyone know
>of any products that do this?

The IPXPKT packet driver for MS-DOS can be used with MS-DOS routing or
bridging products to do this, but it may require some tweaking to make
it work.

-- 
Stephen Trier                     Work: trier@ins.cwru.edu
Network Software Engineer         Home: sct@po.cwru.edu
IRIS/INS/T
Case Western Reserve University

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 1993 21:02:44 GMT
From:      mjr@tis.com (Marcus J Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: rcp reliability

>The vendor of the software which was key in driving this project
>is now questioning the reliability of rcp (possibly because
>we had prior NFS problems between Sun (client) and Pyramid
>(server) which are no longer relevant).

	NFS uses UDP (User Datagram Protocol) while 'rcp' et al
use TCP. UDP is connectionless and does not guarantee delivery.
Packages like NFS do various retransmits to ensure reliability.
TCP, however, is a reliable sequenced packet protocol. In other
words, it guarantees that data either gets through correctly or
not at all.

	Is TCP reliable? Ask the hundreds of thousands of systems
that use it daily.

	The problem you're likely referring to is a known bug(*) in
Sun's NFS client side implementation, which was fixed some time
ago.

mjr.

(*)It was not really a bug. Sun broke part of the protocol which
ensured reliability, in order to make their product a little faster
on certain benchmarks. Market pressure and outraged users have
since convinced Sun of the error of their ways.

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Apr 1993 00:16:34 GMT
From:      crj@comserv.itri.org.tw (Robert Ju-Ching Chen)
To:        comp.protocols.tcp-ip
Subject:   Re: SUN's TCP BUG ??

>Subject: SUN's TCP BUG ??
>Date: Mon, 26 Apr 1993 03:43:39 GMT
>Dear Network Fellows:
>  We find that when we use NCSA 2.3.05 or PC/NFS 2.0 from PC to connect 
>Sun 690MP (SunOS 4.1.2-HL), the login prompt shows up slowly sometimes.
>After we used Sniffer to capture the packets between PC and Sun, we found
>that the destination port no of packets sent from SUN has been changed !!
>After about 1.5 or 2 minutes, the destination port no could be recoverd 
>to correct one. That is the reason why the login prompt displays so slowly !
>  
>  Any comment ? Thanks in advance !

Dear Network Fellows:

  The changed port # is	not 113	!! We never install Wrapper in that Sun.

  I would like to attach the log file we captured by Sniffer. There are	two
stations. We use telnet	from PC	(140.96.1.118) to connect the Sun workstation
(140.96.1.10). And we use ethernet addresses of	these two stations to be
the filter while capturing. They are located on	different side of a bridge.

  We placed the	Sniffer	on the same segment of Sun ( 140.96.1.10 ).

  Please notice	that Frame 4, 5	and 6 show the port no of PC is	26174.

  But what happened between Frame 6 and	Frame 7	? There	were 92.6549 seconds
delay between them !!

  From Frame 7 to Frame	11 we can see the same "strange" port no 24750 sent
by Sun ( 140.96.1.10 ).

  And the right	port no	26174 didn't show up until Frame 12. Why ?????

  Thanks for your reply	in advance !

Here we	go !
- - - -	- - - -	- - - -	- - - -	Frame 4	- - - -	- - - -	- - - -	- - - -	-

SUMMARY	 Delta T     Destination   Source	 Summary
     4	  0.0020  [140.96.1.10]	  [140.96.1.118]   TCP D=23 S=26174	ACK=296000001 WIN=1024

TCP:  ----- TCP	header -----
TCP:  
TCP:  Source port = 26174	      <********** port no of PC	 >
TCP:  Destination port = 23 (Telnet)  <********** port no of Sun >
TCP:  Sequence number =	779839
TCP:  Acknowledgment number = 296000001
TCP:  Data offset = 20 bytes
TCP:  Flags = 18
TCP:  ..0. ....	= (No urgent pointer)
TCP:  ...1 ....	= Acknowledgment
TCP:  .... 1...	= Push
TCP:  .... .0..	= (No reset)
TCP:  .... ..0.	= (No SYN)
TCP:  .... ...0	= (No FIN)
TCP:  Window = 1024
TCP:  Checksum = 9846 (correct)
TCP:  No TCP options
TCP:  


- - - -	- - - -	- - - -	- - - -	Frame 5	- - - -	- - - -	- - - -	- - - -	-

SUMMARY	 Delta T     Destination   Source	 Summary
     5	  0.0624  [140.96.1.10]	  [140.96.1.118]   Telnet C PORT=26174 IAC Do Suppress go-ahead

Telnet:----- Telnet data -----
Telnet:
Telnet:IAC Do Suppress go-ahead
Telnet:IAC Will	Terminal type
Telnet:IAC Will	Negotiate about	window size
Telnet:IAC Will	Terminal speed
Telnet:IAC Will	Remote flow control
Telnet:IAC Will	Linemode
Telnet:IAC Do Status
Telnet:IAC Will	unknown	option (36)


- - - -	- - - -	- - - -	- - - -	Frame 6	- - - -	- - - -	- - - -	- - - -	-

SUMMARY	 Delta T     Destination   Source	 Summary
     6	  0.0906  [140.96.1.118]  [140.96.1.10]	   TCP D=26174 S=23	ACK=779863 WIN=4072

TCP:  ----- TCP	header -----
TCP:  
TCP:  Source port = 23 (Telnet)
TCP:  Destination port = 26174
TCP:  Sequence number =	296000001
TCP:  Acknowledgment number = 779863
TCP:  Data offset = 20 bytes
TCP:  Flags = 10
TCP:  ..0. ....	= (No urgent pointer)
TCP:  ...1 ....	= Acknowledgment
TCP:  .... 0...	= (No push)
TCP:  .... .0..	= (No reset)
TCP:  .... ..0.	= (No SYN)
TCP:  .... ...0	= (No FIN)
TCP:  Window = 4072
TCP:  Checksum = 8C4E (correct)
TCP:  No TCP options
TCP:  


- - - -	- - - -	- - - -	- - - -	Frame 7	- - - -	- - - -	- - - -	- - - -	-

SUMMARY	 Delta T     Destination   Source	 Summary
     7	 92.6549  [140.96.1.118]  [140.96.1.10]	   Telnet R PORT=24750 IAC Do Terminal type
	 ^^^^^^^					    ^^^^^^^^^^
     ( a long period ********************** What is going on ? *************)

Telnet:----- Telnet data -----
Telnet:
Telnet:IAC Do Terminal type


- - - -	- - - -	- - - -	- - - -	Frame 8	- - - -	- - - -	- - - -	- - - -	-

SUMMARY	 Delta T     Destination   Source	 Summary
     8	  0.5346  [140.96.1.118]  [140.96.1.10]	   Telnet R PORT=24750 IAC Do Terminal type
							    ^^^^^^^^^^
		    (********************** What is going on ? *************)

Telnet:----- Telnet data -----
Telnet:
Telnet:IAC Do Terminal type
Telnet:IAC Will	Suppress go-ahead
Telnet:IAC Don't Negotiate about window size
Telnet:IAC Don't Terminal speed
Telnet:IAC Don't Remote flow control
Telnet:IAC Don't Linemode
Telnet:IAC Won't Status
Telnet:IAC Don't unknown option (36)           <****** What's this ??>
Telnet:IAC SB ...


- - - -	- - - -	- - - -	- - - -	Frame 9	- - - -	- - - -	- - - -	- - - -	-

SUMMARY	 Delta T     Destination   Source	 Summary
     9	  1.9997  [140.96.1.118]  [140.96.1.10]	   Telnet R PORT=24750 IAC Do Terminal type

Telnet:----- Telnet data -----
Telnet:
Telnet:IAC Do Terminal type
Telnet:IAC Will	Suppress go-ahead
Telnet:IAC Don't Negotiate about window size
Telnet:IAC Don't Terminal speed
Telnet:IAC Don't Remote flow control
Telnet:IAC Don't Linemode
Telnet:IAC Won't Status
Telnet:IAC Don't unknown option (36)
Telnet:IAC SB ...


- - - -	- - - -	- - - -	- - - -	Frame 10 - - - - - - - - - - - - - - - - -

SUMMARY	 Delta T     Destination   Source	 Summary
    10	  3.9996  [140.96.1.118]  [140.96.1.10]	   Telnet R PORT=24750 IAC Do Terminal type

Telnet:----- Telnet data -----
Telnet:
Telnet:IAC Do Terminal type
Telnet:IAC Will	Suppress go-ahead
Telnet:IAC Don't Negotiate about window size
Telnet:IAC Don't Terminal speed
Telnet:IAC Don't Remote flow control
Telnet:IAC Don't Linemode
Telnet:IAC Won't Status
Telnet:IAC Don't unknown option (36)
Telnet:IAC SB ...

- - - -	- - - -	- - - -	- - - -	Frame 11 - - - - - - - - - - - - - - - - -

SUMMARY	 Delta T     Destination   Source	 Summary
    11	  7.9993  [140.96.1.118]  [140.96.1.10]	   Telnet R PORT=24750 IAC Do Terminal type

Telnet:----- Telnet data -----
Telnet:
Telnet:IAC Do Terminal type
Telnet:IAC Will	Suppress go-ahead
Telnet:IAC Don't Negotiate about window size
Telnet:IAC Don't Terminal speed
Telnet:IAC Don't Remote flow control
Telnet:IAC Don't Linemode
Telnet:IAC Won't Status
Telnet:IAC Don't unknown option (36)
Telnet:IAC SB ...


- - - -	- - - -	- - - -	- - - -	Frame 12 - - - - - - - - - - - - - - - - -

SUMMARY	 Delta T     Destination   Source	 Summary
    12	 13.0108  [140.96.1.118]  [140.96.1.10]	   Telnet R PORT=26174 IAC Do Terminal type
							    ^^^^^^^^^^
		    (********************** Recovered !! Why ? *************)

Telnet:----- Telnet data -----
Telnet:
Telnet:IAC Do Terminal type


- - - -	- - - -	- - - -	- - - -	Frame 13 - - - - - - - - - - - - - - - - -

SUMMARY	 Delta T     Destination   Source	 Summary
    13	  0.0018  [140.96.1.10]	  [140.96.1.118]   TCP D=23 S=26174	ACK=296000004 WIN=1021

TCP:  ----- TCP	header -----
TCP:  
TCP:  Source port = 26174
TCP:  Destination port = 23 (Telnet)
TCP:  Sequence number =	779863
TCP:  Acknowledgment number = 296000004
TCP:  Data offset = 20 bytes
TCP:  Flags = 18
TCP:  ..0. ....	= (No urgent pointer)
TCP:  ...1 ....	= Acknowledgment
TCP:  .... 1...	= Push
TCP:  .... .0..	= (No reset)
TCP:  .... ..0.	= (No SYN)
TCP:  .... ...0	= (No FIN)
TCP:  Window = 1021
TCP:  Checksum = 982E (correct)
TCP:  No TCP options
TCP:  

Name	Robert Ju-Ching	Chen
Email	crj%comserv.itri.org.tw@twnmoe10.edu.tw
Addr.	P.O. 9-65 Chutung, Hsinchu, Taiwan 310,	R.O.C.
Tel.	886-35-917558
Fax	886-35-820026

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Apr 1993 01:33:34 GMT
From:      mreamy@rock.concert.net (Michael G Reamy -- Support)
To:        comp.protocols.tcp-ip
Subject:   Splitting Class B Net across Internet

Is it possible to split a Class B network between two different sites and
still connect to the internet?  Let me explain a little..
A company gets a Class B net assignment and 'splits' the net across 2 
different sites via subnetting (mask: 255.255.255.128).  Both sites want to
connect to the Internet in different parts of the country.  From what I have
been able to gather the internet routing system would only recognize the
Class of the net and would get 'confused' by two different sites using the
same B net number.  Am I correct in this assumption?
-- 

Michael G. Reamy (mreamy@rock.concert.net)

The light at the end of the tunnel may be an oncoming dragon.

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Apr 1993 04:09:25 GMT
From:      daniel@ing.puc.cl (Daniel Hirschberg)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Re: IP on IPX?

Tim Rylance (tkr@puffball.demon.co.uk) wrote:
: I may need to tunnel IP over a wide-area IPX network.  Does anyone know
: of any products that do this?  Free or commercial, RFC1132 or not, any
: reasonable hardware considered.

a couple of PCrouters using ipxpkt shouldn't do the trick ?

hope this helps some... I know very little about IPX!

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

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Apr 1993 05:24:42 GMT
From:      vaf@Valinor.Stanford.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address

In article <C5y3zE.LIw@news.iastate.edu>, john@iastate.edu (John Hascall) writes:
|> hughf@algol.csis.dit.csiro.au (Hugh Fisher) writes:
|> }Ian Phillips writes:
|> }> ...more IP addresses available than the toaster population of the earth :-)
|> }and Phil Royse followed up with:
|> 
|>      Hopefully, "CIDR" (a technique for having the backbone routers
|>      treat the clump-o-C's as a single route) will limit the routing
|>      growth long enough for a more complete solution.  However this
|>      only keeps the growth rate of routes the same as if we had
|>      plenty of B's available (which is still a doubling every year
|>      as I recall?).  Also note that there are only half as many
|>      C's as B's, so using the C's like this only adds a short
|>      breather.
|> 
|>      It's rather like the old story, where you put 1 grain of sand
|>      on the first square of a chessboard, and 2 on the second and
|>      4 on the next, and 8, ... goes pretty slow at first, but if
|>      you look a little ways ahead you can see the dumptruck bearing
|>      down on you.

CIDR is intended to do somewhat more than just increase the number of class-B-
sized network blocks available. For those interested, I'd suggest a reading of
RFC1338 (Supernetting) and the follow-on Internet Draft which describes how the
same techniques may be generalized (draft-fuller-cidr-strategy-01.txt in the
usual Internet Drafts repositories).

	--Vince

-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Apr 1993 05:31:37 GMT
From:      vaf@Valinor.Stanford.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   ISDN terminal adapters

Can someone give me pointers to companies which build ISDN terminal adapters?
In particular, I'm trying to chase down a reference to a company called "UDS"
which apparently builds a box that translates between ISDN and standard
synchronous serial (HDLC) framing. Details would be appreciated.

	Thanks,
	--Vince

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Apr 1993 12:42:02 GMT
From:      websterc@decuk.uvo.dec.com (Colin Webster)
To:        comp.protocols.tcp-ip
Subject:   Re: ISDN terminal adapters


Can someone give me pointers to companies which build ISDN terminal adapters?
In particular, I'm trying to chase down a reference to a company called "UDS"
which apparently builds a box that translates between ISDN and standard
synchronous serial (HDLC) framing. Details would be appreciated.

	Never heard of UDS, however, all terminal adaptors give you
	a clear channel to talk whatever protocol  you want once the
	ISDN call has been setup. A TA allows the connection at the
	"S" reference point interface standards such as V35, X.21, V24 etc.
	The main difference between vendors is the flexibilty and features
	of the TA. The only company I can think of that sells in europe as
	well as the US in NEWBRIDGE. I have used these to connect systems
	over ISDN with the protocols being used DDCMP and LAPB with
	no problem.

	Colin	

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Apr 1993 13:53:09 GMT
From:      ijl11@cl.cam.ac.uk (I.J. Leader)
To:        comp.protocols.tcp-ip
Subject:   Good Book on NIS (Yellow Pages)

Could anyone recommend a good book on NIS (Yellow Pages). I'm interested in an
overview as well as advanced aspects. If people could email me, directly, I'd
apreciate it, and if I get any answers, I'll post a summary.

Many thanks,

Ian Leader.

(If this is the wrong group to post to, I apologise, but it seems to be the best
I could find.)

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Apr 1993 13:54:00 GMT
From:      heka@ost.NoSubdomain.NoDomain (hedie kamoun)
To:        comp.protocols.tcp-ip
Subject:   Nagle algoritm

Dear tcp/ip gurus,
	I have a question regarding the Nagle-algoritm. H O W or W H A T do I
do to control the invocation of this algoritm using Berkeley sockets alias SunOS-
sockets, also is it possible totwiggle this option under TLI as well? 

	Any help or lightshedding on the Nagle-algoritm is very welcome, as are
book refrences or articles.

	Best Regards to all of the netcommunity
		Hedie

		email: heka@ppvku.ericsson.se


-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 93 14:07:06 GMT
From:      ercm20@festival (Sam Wilson)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Re: IP on IPX?

Tim Rylance (tkr@puffball.demon.co.uk) wrote:
: I may need to tunnel IP over a wide-area IPX network.  Does anyone know
: of any products that do this?  Free or commercial, RFC1132 or not, any
: reasonable hardware considered.

Just a thought - you may be able to quash this straight away - the only
way I know of doing IPX-only wide area networking is via Novell servers
as routers, and if that is the case they ought to be able to IP routing
as well.  It has to be said that I don't know a) if you're using Novell
servers as routers; b) whether you know that Novell servers can route
IP; c) whether Novell servers can route IP across the wide area anyway
(I've never had to do it!); or ...

: The politics of this requirement are left to the reader's imagination.

.. d) whether the politics would preclude that option anyway!

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


-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Apr 1993 14:45:08 +0000
From:      nshaylor@fabcab.demon.co.uk (Nik Shaylor)
To:        comp.protocols.tcp-ip
Subject:   Looking for TCP/IP source code

I am looking for a nicely written public domain implementation of
TCP/IP that I can port to a network of embedded controllers that are based
on the ARM 6 processor. I have looked at KA9Q but I would like to know of
any other sources that might be appropriate. It must be in C and easily
comprehended.

Thanks,

------------------------------------------------------------------------------
Nik Shaylor.          | nshaylor@fabcab.demon.co.uk      Phone: +44 722 326577
The Old School House, |-------------------------------------------------------
School Lane,          | Merely corroborative detail, intended to give artistic
Salisbury, Wilts      | verisimilitude to an otherwise bald and unconvincing
SP1 3YA, UK.          | narrative.  W.S. Gilbert - The Mikado
------------------------------------------------------------------------------

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 1993 17:34:13 GMT
From:      welch@xcf.Berkeley.EDU (Sean N. Welch)
To:        comp.protocols.tcp-ip
Subject:   Re: ISDN terminal adapters

In article <1993Apr29.053137.10139@CSD-NewsHost.Stanford.EDU> vaf@Valinor.Stanford.EDU (Vince Fuller) writes:
>Can someone give me pointers to companies which build ISDN terminal adapters?
>In particular, I'm trying to chase down a reference to a company called "UDS"
>which apparently builds a box that translates between ISDN and standard
>synchronous serial (HDLC) framing. Details would be appreciated.

Universal Data Systems, a subsidiary of Motorola Inc. (Information Systems
Group) can be reached at:

UDS
5000 Bradford Drive,
Huntsville, Alabama 35805-1993
(205) 430-8000

or at least that's what it says in the UDS TA120 manual I have here.

Sean Welch

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Apr 1993 17:50:47 GMT
From:      melanie@ph-meter.beckman.uiuc.edu (Melanie Humphrey)
To:        comp.protocols.tcp-ip
Subject:   Re: PCNFS Name Mangling

robertt@n154.mentor.stortek.com (Robert Thompson (robertt)) writes:


>
>--
>Is there any way to keep PCNFS from mangling the name of valid DOS file
>names ?   More specifically, I have a file name (i.e. SETUP.EXE) that is
>all upper case on the mounted file system.  When I look at it on my PC I
>get something like SE~~~~1A.TXT.  I want to see 'SETUP.TXT'.

try 'setup.txt' on the unix system instead of 'SETUP.TXT'. i believe pc-nfs
automagically converts lower to upper case, and if it sees uppercase
assumes it's mixed-cased.

>
>------------------------------------------------------------------------------
>Robert Thompson                       |  Storage Technology Corporation
>Redwood Digital Hardware Design Team  |  2270 South 88th. Street
>(303) 673-7747   FAX: (303) 673-2568  |  Louisville, Colorado 80028-0211
>--------------------------------------+---------------------------------------
>Please don't rely on the header for replies; use  robertt@n33.stortek.com
>------------------------------------------------------------------------------
--

-------------------------------------------------------------------------------
Melanie Humphrey | Systems Services	  | BISS --
msh@uiuc.edu	 | Beckman Institute	  |	If we can't fix it, it 
217-244-1079	 | University of Illinois |	ain't broke.
-------------------------------------------------------------------------------

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 93 18:36:36 GMT
From:      sklower@VANGOGH.CS.BERKELEY.EDU (Keith Sklower)
To:        comp.protocols.tcp-ip
Subject:   Requesting Help to keep sockets part of the Posix Networking standard

Last chance to Save Sockets in Posix!

Hello -

	I am writing to solicit help in doing work deemed
necessary in order for the sockets specification to continue
to be part of a proposed IEEE standard for process-to-process
communication.  Realistically, the work needs to be done during
the month of May, or sockets will be dropped from the current
draft.

	A mailing list (socket-friends@vangogh.cs.berkeley.edu)
has been created, from people who indicated some non-atagonism
towards being strong-armed into helping out if it were really
necessary, and unfortunately now it really is.  (A copy of this
note is being sent to the ietf and tcp-ip mailing lists just in
case there are any additional people willing to pitch in).

	No single person needs to be stuck doing all the work;
anybody can sign up for some small part of it by mailing to the list,
and twice a week, announcements will be sent around saying who's
signed up for what, and how much of it has been done, (and what's
been left begging).

	There is a list of 20 items to be done, referring to
the current draft (2.1), which is available in postscript form
via anonymous ftp from vangogh.cs.berkeley.edu as pub/dot12/pii_2_1.ps.
The sources (which require a very complex macro package which I
do not have a copy of) are on line there as 2_1.src.tar.Z.

	As these chores are completed, it would be save work on the
part of the technical editor if text could be returned in roughly the
form of the source, but any sort of flat ascii would be gratefully
appreciated.

	The P1003.12 committee issued this formal statement:



Work Necessary to Preserve Sockets as part of the Proposed
P1003.12 IEEE Posix Protocol-Independent process-to-process API.

The following Items reflect our understanding of the major 
work items to be addressed before P1003.12 goes to ballot.  
It is the feeling of the 1003.12 working group that 
completion of these work items will result in a sockets 
section that is ready for IEEE ballot and subsequent 
standardization.  However, it is also the feeling of 1003.12 
that failure to complete these work items will leave a socket 
section that is not ready for standardization.  The 1003.12 
document will go to ballot after the July 1993 meeting 
(probably about the September 1993 time frame).  If the 
sockets material is not available by the July meeting, the 
1003.12 group has agreed that the sockets interface will be 
removed from the standard to be ballotted.  (A socket 
standard could appear later, but only as the result of the 
approval by the IEEE of a separate Project Authorization 
Request.)

Sockets Introduction

Item 1 - write introduction section for sockets.  Pull 
information from publicly-available sources, provide a 
description of what the socket interface does, the general 
interface paradigm, and other nice introductory stuff.

Item 2 - Draft the text for Section 6.5 (The Use of 
Options).  This is essentially an action to provide a 
reference from the discussion of protocol- independent socket 
options to the protocol specific appendices. Ensure that all 
options that are protocol-independent are documented with 
information including type of parameter (and what the type 
means, e.g. an int doesn't indicate whether sndbuf is 
described in terms of buffer units, octets, or bytes), and 
min and max values, if applicable.  The current documentation 
in the Description section of the setsockopt()/getsockopt() 
functions has a description of most of the socket-level 
options (defined in socket.h).  (The low water mark options 
are not defined, but should be.  There may be others, so part 
of the work is to go through socket.h and make sure we've got 
completeness.)  

Add a discussion of the SO_REUSEADDR - definition, use, and 
intent.  Ditto for SO_LINGER.

Do the same thing for the protocol-specific options in the 
Annexes.

Also, update INET section in annex C to reflect the current 
commonly-used TCP and IP options.  Question:  Are we 
making the commonly-used options normative, or merely 
noting that these options are commonly used?

Coordination with the .1 Base Standard

Item 3 - Document what .1 functions apply to SOCKETS fds and 
what .1 fd semantics apply to SOCKETS fds.  The remainder of 
this item gives pointers to what functions need semantics 
documented.  

The following .1 functions operate on file descriptors:
open()
creat()
pipe()
fstat() - there's some question about this
fpathconf()
dup() +
dup2() +
close() +, !
read() +, !ISO
write() +, !ISO
fcntl() +
tc*(), these are OK since they return ENOTTY if the fd 
is not a device amenable to devctl

+   indicates that these .1 functions operate on socket 
descriptors.
!   indicates that these .1 functions cause a change of 
socket state (per Kurt Matthys's state/event diagram).
!ISO    same as !, but only for ISO.

The following .1 functions affect socket fd's - document the 
effects of these functions on socket file descriptors:
fork()
exec()
umask() - AF_LOCAL implications?
exit()
abort()

Review each of these functions' effects on file 
descriptors and verify that their effects on socket file 
descriptors are identical.  Write statement that says 
that socket file descriptors are affected in the same 
way as regular file descriptors (if true).  Otherwise 
document differences.

The following .1 functions might affect AF_LOCAL
unlink()
rename()
umask()

Item 4 - Add the following types to sys/types.h:  u_int, 
u_short, u_char, u_long.

Verify that caddr_t is defined in .1.  Otherwise, add 
definition of caddr_t to .1.



Documentation of Asynchronous and Non-blocking 
Operation

Item 5 - Create a section (currently 6.4, "States and 
Events") that consolidates the sockets discussion of async-
mode & block vs. non-block SOCKETS.  Note in this section 
that the specific state tables for the socket interface are 
in the protocol-specific annexes, since the socket semantics 
can be affected by underlying protocol actions.

Item 6 -  Identify the socket calls that generate or are 
affected by SIGPIPE, SIGIO, and SIGURG, respectively.  Define 
the semantics of those effects.  Place in the discussion of 
non-blocking/async. operation.  

Item 7 - wordsmith the fact that poll() and select() may be 
used for socket event management.

Item 8 - Put select() in SOCKETS C binding. 

Clarification of Existing Semantics

Item 9 - Clarify distinction between PF_ vs. AF_. in the 
socket() semantics.  

Item 10 - Specify semantics for MSG_PEEK and MSG_OOB in the 
documentation of the recv() and recvmsg() functions.  Xref 
back to where these flags are enumerated.  recv(), et al, in 
flags arg. discussion:  "MSG_PEEK allows an application to 
preview the message without removing it from the input 
buffer."  If no OOB data available, what are the semantics?  

Wordsmith msg flags wherever they're used.  Wordsmithing 
includes defining which calls a flag is valid for, what are 
the effects of the flag being set? being clear?, what are the 
default settings for the flag, and what combinations of flags 
are permitted.
Add MSG_WAITALL to discussion on line 496 sec. 6.
MSG_DONTROUTE
MSG_CTRUNC
MSG_EOR - in proto specific annex (TP4)

Item 11 - Specify the protocol-specific semantics of 
shutdown() for annex C (for both INET and OSI).

Item 12 - Document socket() semantics for AF_LOCAL (nee 
AF_UNIX) in annex B.1.4.

Item 13 - Document the required structs/defines needed in 
each header file for each AF (sys/un.h, netinet/in.h, 
netiso/iso.h).  (I.e., make sure these header files are 
included in the right places, with appropriate edits.)

Item 14 - add section on how to send urgent data for TCP.

Item 15 - Document how you map sockets calls to protocol-
service primitives.  This disussion should appear in the 
protocol-specific annexes.  Clarify the mappings from socket 
calls for each protocol, to lis primitives (in words).  That 
is, clean up section 4 of the LIS draft. 

Item 16 - add text to socket man page describing default 
protocols. What protocols get selected when the _protocol_ 
parameter is 0?  For section C, specifically state what the 
default protocols are, given the PF and socket type.

Item 17 - Correct/rewrite section C.2.1.4.2 and the 
TP_OPT_FLAGS stuff.  (Probably reserved for Keith Sklower, 
UCB, but anybody that can is welcome to take a crack at 
this.)

RFC 1122 Support

Item 18 - Change Sockets/TCP-IP bindings to allow (all, and 
therefore) the following RFC1122-mandated options: 
y   TCP_MAXRXT (maximum retransmits before giving up), 
y   IP_TTL, 
y   SO_KEEPALIVE having a value representing the idle 
interval time, 
y   IP_TOS.

Functional Extensions to Sockets

Item 19 - Ensure that ancillary data specifications are 
complete in the protocol-specific section. (Annex C).  
Document syntax and semantics, but not implementation of the 
macros CMSG_DATA, CMSG_NXTHDR, and CMSG_FIRSTHDR. 

Item 20 - Change setpeer() to set_addresses().  This is new 
functionality proposed by Keith Sklower, allowing the user
to specify both the local and peer addresses in a single
call, rather than separately.  This would be useful for 
ftp - alleviating problems that force the use of 
SO_REUSEADDR, for example.  

-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Apr 1993 19:39:43 GMT
From:      copeland@sdf.lonestar.org (Charles Copeland)
To:        comp.protocols.tcp-ip,comp.sources.wanted,comp.programming,comp.sys.ibm.pc.net
Subject:   TCP-IP MB86960 driver

I am looking for source for a ethernet driver for a board using MB86960 NICE
chips. I've looked at the clarkson drivers (driverss.zip) but do not know
if any of these boards they support use the MB86960 NICE chips.

Please reply to copeland@sdf.lonestar.org

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Apr 1993 20:41:36 GMT
From:      mikel@aaahq05.aaa.com (Mikel Manitius)
To:        comp.protocols.tcp-ip
Subject:   Wanted: to identify routers in a path

There was a program I've seen at USENIX (which I think comes from Solbourne)
which tells you the names (or addresses) of the routers allong a certain path.

You give it an address, like "kgbvax.kgb.org.su" and it will identify all
of the routers allong the path taken.

Can anyone tell me where I can get this?
---
						Mikel Manitius
						mikel@aaa.com


-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Apr 1993 02:25:48 GMT
From:      hmchen@fcom.ee.ntu.edu.tw (Hung-ming Chen)
To:        comp.protocols.tcp-ip
Subject:   UDP recefrom() problem


Hi netters,

  I am writing a broadcast program under Socket packet. When I
complied the program is O.K., but I ran it, there was a
serious error occured. After cheching and checking my program,
I could not find any error. Thus, I post this mail. If you
know anyting about it, please let me know. My program and
error message is :

 typedef {
     char msgtype;
     char status
 } BRD_REC;
 struct sockaddr_in  udp_cli_addr;
 int            brd_fd;
 BRD_REC        recvdata; 

while(recvfrom(brd_fd, (char *) &recvdata, sizeof(BRD_REC), 0,
  (struct sockaddr *) &udp_cli_addr, &addrlen) >= 0) {       

when I ran my program, the error message under SUN debug tool
is shown as:

signal SEGV (no mapping at the fault address) in libc_xstr at 0xf77e1b24
0xf77e1b24:     ld      [%i1], %i1

Thanks in advance.

Fred Chen


-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 93 11:42:37
From:      vixie@pa.dec.com (Paul A Vixie)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: Will SO_KEEPALIVE work with non-blocking sockets ???

what happens is that you start getting -1 returns from read() and write()
after SO_KEEPALIVE or an ICMP or remote close has closed your socket.
errno will be set to EPIPE or EIO if it's a keepalive or remote close,
or to ENETDOWN/ENETUNREACH/ENETRESET if it's an icmp problem.
--
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Don't be a rebel, or a conformist;
<vixie@pa.dec.com> decwrl!vixie		they're the same thing, anyway.  Find
<paul@vix.com>     vixie!paul		your own path, and stay on it."  -me

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Apr 1993 08:52:04 GMT
From:      queloz@bernina.ethz.ch (Ronald Queloz)
To:        biz.sco.general,biz.sco.opendesktop,comp.unix.programmer,comp.protocols.tcp-ip
Subject:   XTI on SCO Unix, does it work?

Hi Netlanders,

I'm writing software for SCO Unix which uses XTI. 

There seems to be a problem with the implementation of the t_alloc call
under SCO. Is there anybody who has used this call without any problems
or has encountered problems using it.

What is the solution to this problem? Do I have to write my own t_alloc?

Thanks in advance

Ron.

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 93 14:38:05
From:      art@now.midnight.com (Art Mellor)
To:        comp.protocols.tcp-ip
Subject:   Dynamic addressability with IP?


Has anyone solved the problem of being able to move IP nodes from one net
to another and have it reacquire a new address and somehow get DNS/NIS to 
notice the change (and any other services that might need to?) This would
require some sort of daemon and other support, I realize, but that is ok.

I am looking for something more than RARP or BOOTP can provide and I don't 
have a concrete definition for what I'm looking for yet, I just want to
find out about things in this realm.

Any info on this sort of work would be greatly appreciated.

--


...............................................................................
  Art Mellor       : Midnight Networks Inc. 100 Fifth Avenue Waltham MA 02154 
  art@midnight.com : Phone 617/890-1001 Fax 890-0028 -- Network Consulting --


-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Apr 1993 10:05:37 GMT
From:      hmchen@fcom.ee.ntu.edu.tw (Hung-ming Chen)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP recefrom() problem


In last post mail I wrote an error about recvfrom. Now I
double that the error may be caused by the mistake. I wrote
both the client and server with the same socket fd in one 
process. Because I want to send a message out and then receive 
the message from another node by using the same process. Dose 
the idea work? If anybody has the experience, please tell me. 
Can it work?

Fred Chen


-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Apr 1993 13:23:20 GMT
From:      ijl11@cl.cam.ac.uk (I.J. Leader)
To:        comp.protocols.tcp-ip
Subject:   Summary: Good Book on NIS (Yellow Pages)

Thanks to everyone who responded to my posting asking about good NIS/YP books. I
received several replies, all recommending:

"Managing NFS and NIS" by Hal Stern, published by O'Reilly & Associates.

Thanks once again.

Ian.


-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Apr 1993 13:28:27 GMT
From:      ijl11@cl.cam.ac.uk (I.J. Leader)
To:        comp.protocols.tcp-ip
Subject:   Summary: Good Book on NIS (Yellow Pages) (Continued)

Sorry, The Nutshell hanbook on NFS and YP by hal Stern was also recommended.

Ian.



-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Apr 1993 14:08:08 GMT
From:      alun@huey.wst.com (Alun Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: PCNFS Name Mangling

In article <melanie.736105847@ph-meter.beckman.uiuc.edu> msh@uiuc.edu writes:
>robertt@n154.mentor.stortek.com (Robert Thompson (robertt)) writes:
>>Is there any way to keep PCNFS from mangling the name of valid DOS file
>>names ?   More specifically, I have a file name (i.e. SETUP.EXE) that is
>>all upper case on the mounted file system.  When I look at it on my PC I
>>get something like SE~~~~1A.TXT.  I want to see 'SETUP.TXT'.
>
>try 'setup.txt' on the unix system instead of 'SETUP.TXT'. i believe pc-nfs
>automagically converts lower to upper case, and if it sees uppercase
>assumes it's mixed-cased.

We have a related problem that we would like to see 'fixed' in some way -
we develop and sell a project management system that runs on Mac, PC, Vax
and Unix, and where the PC and Mac systems can share the same data (since
they both run under xBase clones with the same data format).  We have
some users running PC-NFS and (I think it's called) AUFS to allow the
Macs and PCs on the network to use a Sun as their file server.

Now, obviously on the Mac, we don't force people to choose a case for
file names, since that is "un-Mac-like".  In fact, many users like to see
our file names in Upper Case (since that is how they appear in menus).
However, as pointed out above, these names will ALWAYS be mangled by PC-
NFS.  There is an option in AUFS (I think that's the name) to force
a case on the file name - unfortunately, it forces UPPER CASE as the
default.  Our client will not allow us to modify their AUFS code, since
they feel that all systems should work together with standard options
only.  Since there is no option that will allow both systems to work
together over the Sun, our client has been forced to stop using PC-NFS
and is now using Novell.  (This was their decision, based on how long it
would take us to force all file names to lower case and dos compatible)

I think the question I want to ask here is - would any of you have done
any differently?  What (if anything) could we have done to keep that
client working under his original setup?

For further reference, I should say that the client is quite happy
now with his Novell solution, and that nothing has had to be changed
to make it work properly.

Any thoughts?

Alun.
~~~~




-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Apr 1993 14:32:19 GMT
From:      copeland@sdf.lonestar.org (Charles Copeland)
To:        comp.protocols.tcp-ip,comp.bin.ibm.pc,comp.protocols.tcp-ip.ibmpc
Subject:   Looking for free PC client software aka free PCNFS

I have been looking for free client software to replace PCNFS on a few PC's
at work. I found SOS (Son of Stan) but it is only the file server.

Please mail replies to copeland@sdf.lonestar.org

-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Apr 1993 15:00:25 GMT
From:      rconway@vax1.tcd.ie
To:        comp.protocols.tcp-ip
Subject:   unix to tcpip

Is there any software to convert from tcp/ip to appletalk.


Thank you 

Rory


-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 1993 15:10:05 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: unix to tcpip

In article <1993Apr30.150025.1@vax1.tcd.ie> rconway@vax1.tcd.ie writes:
>Is there any software to convert from tcp/ip to appletalk.

You had better define what you mean by "convert".  What do you want to
accomplish?

-- 
Stephen Trier                     Work: trier@ins.cwru.edu
Network Software Engineer         Home: sct@po.cwru.edu
IRIS/INS/T
Case Western Reserve University

-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Apr 1993 15:19:09 GMT
From:      jcarroll@Scotia-McLeod.Com (Jim Carroll)
To:        comp.protocols.tcp-ip
Subject:   Re: rcp reliability

In article <1rmrdk$jop@sol.TIS.COM> mjr@tis.com (Marcus J Ranum) writes:
>	NFS uses UDP (User Datagram Protocol) while 'rcp' et al
>use TCP. UDP is connectionless and does not guarantee delivery.
>Packages like NFS do various retransmits to ensure reliability.
>TCP, however, is a reliable sequenced packet protocol. In other
>words, it guarantees that data either gets through correctly or
>not at all.

Yeah, that's how we understood it.

>	Is TCP reliable? Ask the hundreds of thousands of systems
>that use it daily.

Again, these are our feelings.  The vendor's argument would go
something like this:  "Well, if you can't trust Pyramid's
implementation of NFS, how can you trust Pyramid's implementation
of rcp?"  This is really bizarre, since their application is
client/server, using the Pyramid as the server.  My counter-
argument would go, "Well, if you can't trust Pyramid's NFS
and rcp, then by association, you introduce doubts about
Pyramid's implementation of TCP/IP," which is wacko, since
the corollary to that would be that their own product would
be unreliable, which is not the case (except for occasional
server process hangs  :-)).

The only problem we had was with NFS on the Pyramid.  Pyramid
was prodded into fixing the bug, but around the time they
produced a fix, we had just finished moving NFS services
over to a Sun.  Too bad...we may never know the truth.

>	The problem you're likely referring to is a known bug(*) in
>Sun's NFS client side implementation, which was fixed some time
>ago.

As mentioned, Pyramid seems to have fixed the bug.  One point which
was brought up, was that Sun has the advantage of having the
latest NFS (naturally), and that (most?) other vendors would have
the disadvantage of being a couple revs behind....

Again I implore, if anybody can point me to some "official"
docs....

-- 
Jim Carroll                   | "Big fleas have little fleas,
ScotiaMcLeod Inc., Toronto    |  upon their backs to bite 'em,
Ontario, Canada               |  and little fleas have lesser fleas,
jcarroll@Scotia-McLeod.Com    |  and so, ad infinitum."

-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Apr 1993 16:25:14 GMT
From:      sylvain@killians.gsfc.nasa.gov (Gregory Sylvain)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Will SO_KEEPALIVE work with non-blocking sockets ???


   Hello Networld,

   I just would like  someone to confirm my suspicion that this will not work.

   I've tried it, and the read operation just keeps returning EWOULDBLOCK. 
I have a desire to use non-blocking socket because this code has to run on 
multinet, and I want to write only one set of code that will run across all 
UNIX tcp implementation and VMS/Multinet.  (So I don't want to have to 
write separate VMS-QIO functions for the socket code)  

   But I do have to detect when a connection is broken, does anyone 
have any ideas how to do this while still using non-blocking sockets ?

   I've tried assuming that if read/write returned 0 (as opposed to 
an error or the len of the message) on a socket, that this meant connection 
was broken.  But this is only true for a few implementations (vms, etc.)

   If you have any suggestion, I'd appreciate hearing from you.

   Thanks,
   greg


-- 
Greg Sylvain (c/o  Hughes STX)      Office: (301) 513-1622  FAX: (301) 513-1608
7601 Ora Glen Drive, Suite 300      Email : sylvain@killians.gsfc.nasa.gov
Greenbelt, MD 20770                         sylvain@rhine.stx.com


-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Apr 1993 17:16:07 GMT
From:      mskucher@math.uwaterloo.ca (Murray S. Kucherawy [MFCF])
To:        comp.protocols.tcp-ip
Subject:   Asking nameservers for domains

I need to write a piece of code that will determine, given an FQDN,
its "minimal" name, ie. without the domain name on the end.  Usually
you can just use strchr and put a \0 after the first "." in the name,
but some machines here have "." in the hostname (and it's debatable
as to whether or not this is legal, according to vendors).

So, given (for example) "cantor.math.uwaterloo.ca", where "uwaterloo.ca"
is our main domain name, I want to be able to determine that "cantor.math"
is the hostname, preferably without consulting /etc/hosts (ie. I'd
like to find out from named).

Using gethostname() isn't enough because on some machines (ie. all of
our AIX machines which have dots in the hostnames), it's necessary
to put the FQDN in the hostname, so gethostname() returns the whole FQDN,
which isn't what I'm after.

So far, the nameserver just gives back the FQDN if I pass it the FQDN,
even though the named data reads:

	cantor.math	IN	A	129.97.204.8
	cantor.math	IN	A	129.97.70.1

(ie. the short name is there, which is the way it's supposed to be...)

Any suggestions?  Or am I as stuck as I think I am?

-- Murray S. Kucherawy ----------------------------------------+--------------
Software Systems Co-op, Math Faculty Computing Facility [MFCF] | All spelling
University of Waterloo, Ontario, Canada                        | errors caused
E-mail: mskucherawy@{math,watdragon}.UWaterloo.ca              | by Pnews.
---------------------------------------------------------------+--------------

-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Apr 1993 17:39:35 GMT
From:      bsaffo01@cad.gmeds.com (Brian H. Safford)
To:        comp.protocols.tcp-ip
Subject:   LPD for Packet Driver

I've forgotten the name and anonymous ftp location for a PC-based LPD Server 
program I used a couple years ago. I'd appreciate some e-mail about where I 
can find it.

Thanks,

+-----------------------------------------------------------+
| Brian H. Safford           EMAIL: bsaffo01@cad.gmeds.com  |
| Electronic Data Systems    PHONE: (313) 696-6302          |
 +-----------------------------------------------------------+
| NOTE: The views and opinions expressed herein are mine,   |
| and DO NOT reflect those of Electronic Data Systems Corp. |
+-----------------------------------------------------------+

-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 93 18:08:10 GMT
From:      carrato@mhinfo.UUCP (Tony Carrato)
To:        comp.unix.sysv386,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   SCO TCP/IP <> Netware TCP/IP problem

A customer of ours is having a fairly strange TCP/IP problem.  If anyone
has seen this one before I'd appreciate any insite.  I've put this into
a few newsgroups so if replies can be emailed to me, I'll summarize them
to the net.

Here's the problem:

	Segment 1				Segment 2
  ================================   ==========================
  "       "          "           "   "           "            "
 SCO    RS6000     PC 1 w/        Netware     PC 2 w/      PC  3 w/
                   LAN WG         w/ Novell   LAN WG       LAN WG
		   for DOS        TCP/IP      for DOS      for DOS

In this configuration, PC 1 can ping/telnet to the SCO box.  If you
move it to segment 2, it can't.  However, on either segment, PC 1
(and the other PC's) can easily ping/telnet to the RS6000.  I'm
somewhat baffled.  It appears that either a) the SCO system is set
up wrong  somehow or the Netware server won't pass packets from it to
segment 2.  Any ideas would be much appreciated.

Tony


----------------------------------------------------------------------------
Tony Carrato				MHIS, Inc.
carrato@mhinfo.com			9101 E. Kenyon Ave, Suite 3400
fax   (303) 721-0281			Denver, CO 80237
voice (303) 721-0851
----------------------------------------------------------------------------

-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Apr 1993 18:15:28 GMT
From:      bsaffo01@cad.gmeds.com (Brian H. Safford)
To:        comp.protocols.tcp-ip
Subject:   PC-based LPD Server

I apologize if this was already posted, but...

I used a PC-based LPD Server a couple years ago, but I've forgotten its
name and location on the Internet. I'd appreciate it if someone would jolt 
my memory with some e-mail...

Thanks,

+-----------------------------------------------------------+
| Brian H. Safford           EMAIL: bsaffo01@cad.gmeds.com  |
| Electronic Data Systems    PHONE: (313) 696-6302          |
 +-----------------------------------------------------------+
| NOTE: The views and opinions expressed herein are mine,   |
| and DO NOT reflect those of Electronic Data Systems Corp. |
 +-----------------------------------------------------------+

-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Apr 1993 19:13:25 GMT
From:      prs9k@brain.med.virginia.edu (Phil Scarr)
To:        comp.protocols.tcp-ip
Subject:   Microsloth Mail SMTP Gateway

If anyone has any hints for configuring the Microsloth Mail SMTP Gateway
to talk to the outside world, I'd love to hear from you.

	-Phil
-- 
PHIL SCARR        \      We are Microsoft...     /          (o) 804.243.0229
 University of    /     OS/2 is irrelevant.      \          (f) 804.243.0294
 Virginia,        \     UNIX is irrelevant.      /        prs9k@Virginia.EDU
 Neurosurgery     /     Openness is futile.      \     prs9k@Virginia.BITNET
 HP-UX is my life!\ Prepare to be assimilated... /   ...uunet!virginia!prs9k

-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Apr 1993 19:30:20 GMT
From:      mtshdsx@gsusgi2.gsu.edu (Herbert D. Sayers)
To:        comp.protocols.snmp,comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: List of MIB variables to monitor

I, mtshdsx@gsusgi2.gsu.edu (Herbert D. Sayers) write in comp.protocols.snmp:

>A couple of months ago, a list of MIB variables to be used for monitoring a
>network w/SNMP was posted to this group ( it may have been comp.dcom.whatever ).
>As a newbie to SNMP, I thought this would be useful. So I put it somewhere safe,
>and of course can not now locate it. Could someone mail me this list? If enough
>people are interested, I will post valid responses.
 
>Mail to mtshdsx@gsusgi2.gsu.edu. Thank you in advance.

[.sig deleted]

Several people have emailed me requesting copies of this list of MIB variables.
I would love to post it, but I can't since no one has replied to the original
post.

Once again, if someone would email this list to me,  I will repost it on
comp.protocols.snmp.

Thanks in advance.

[Follow-ups to comp.protocols.snmp]
-- 
///////////////////////////////////////////////////////////////////////////////
Bert Sayers
GSUCC - MTS
mtshdsx@gsusgi2.gsu.edu

-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Apr 1993 19:53:36 GMT
From:      macker@itd.nrl.navy.mil (Joseph P. Macker)
To:        comp.protocols.tcp-ip
Subject:   Voice/Stream Data Distribution

hello:

I will be running a network technology demonstration project over the next
few years to integrate near real-time stream data and digital voice
services over low capacity radio subnetworks.  I plan on using a
unique, efficient network protocols over these subnetworks while
supporting external IP connections through a point-to-point virtual 
circuit within the subnetwork.  Has something like this ever been 
tried and does anyone have any feedback?

On a separate note, I will be distributing my user voice and data 
terminals over a local LAN (e.g. Ethernet, FDDI) and will be 
using socket interfaces to support data connections to/from a
network manager and subnetwork access controller also hanging off
this LAN.  These socket interfaces will be carrying real-time,
low-data-rate voice and time sensitive data.  I plan on using TCP/IP
for the data interface socket and SNMP/UDP over a management socket.
The trick here will be designing my own MIB agents and getting the 
real-time performance I need from these sockets.  Does anyone have
any experience and/or comments on this type of a system.

-Joe Macker 
macker@itd.nrl.navy.mil



   

-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 1993 21:35:23 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: Asking nameservers for domains

In article <C6B3yw.DIo@math.uwaterloo.ca> mskucher@math.uwaterloo.ca (Murray S. Kucherawy [MFCF]) writes:
>I need to write a piece of code that will determine, given an FQDN,
>its "minimal" name, ie. without the domain name on the end.  Usually
>you can just use strchr and put a \0 after the first "." in the name,

No, you can _always_ do that.

>but some machines here have "." in the hostname (and it's debatable
>as to whether or not this is legal, according to vendors).

That's a separate issue.  The simple hostname _cannot_ have a dot in
the name.  The "hostname" as set by "sethostname()" and retrieved by
gethostname() or vendor equivalent might or might not have a dot in
it.  That depends on vendor (or sysadmin preference) and DNS/NIS
installation.

>So, given (for example) "cantor.math.uwaterloo.ca", where "uwaterloo.ca"
>is our main domain name, I want to be able to determine that "cantor.math"
>is the hostname, preferably without consulting /etc/hosts (ie. I'd
>like to find out from named).

It sounds like your getting really confused about what is a "hostname".
If I am in the domain "math.uwaterloo.ca" (logged on, say, cantor), and I
say "telnet gauss", the resolver will first try "gauss.math.uwaterloo.ca"
If that exists, it will return that.  It will then try "gauss.uwaterloo.ca".
If that exists, it will return that.  Failing that, it will return "host
unknown".  If say "telnet joe.cs", the resolver will first try
"joe.cs.math.uwaterloo.ca", then "joe.cs.uwaterloo.ca".  The above procedure
(called RES_DNSRCH) was added to make life easy for people, so they can
use simpler names, and let the resolver do the hard work.

>Using gethostname() isn't enough because on some machines (ie. all of
>our AIX machines which have dots in the hostnames), it's necessary
>to put the FQDN in the hostname, so gethostname() returns the whole FQDN,
>which isn't what I'm after.
>
>So far, the nameserver just gives back the FQDN if I pass it the FQDN,
>even though the named data reads:
>
>	cantor.math	IN	A	129.97.204.8
>	cantor.math	IN	A	129.97.70.1
>
>(ie. the short name is there, which is the way it's supposed to be...)

No, the short name is not there.  If a host does not have a trailing dot
on the end of the name, it tacks on $ORIGIN.  (Either the domain name
as listed in /etc/named.boot, or set above in the zone file)  In your
case, (I'm assuming the domain name) named thinks that the following two
lines are exactly equivalent to the lines above:

	cantor.math.uwaterloo.ca.	IN	A	129.97.204.8
	cantor.math.uwaterloo.ca.	IN	A	129.97.70.1

--Dave
-- 
System Administrator, Penn State Population Research Institute
IP over ATM?  You mean I can read my email from a cash machine?

-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 1993 22:22:06 GMT
From:      rgoldstone@OAVAX.CSUCHICO.EDU (Robin, Girl Wonder)
To:        comp.protocols.tcp-ip
Subject:   Re: Microsloth Mail SMTP Gateway

In article <C6B9ED.Dwt@murdoch.acc.Virginia.EDU>, prs9k@brain.med.virginia.edu (Phil Scarr) writes:
>If anyone has any hints for configuring the Microsloth Mail SMTP Gateway
>to talk to the outside world, I'd love to hear from you.
>
>	-Phil
>-- 
>PHIL SCARR        \      We are Microsoft...     /          (o) 804.243.0229
> University of    /     OS/2 is irrelevant.      \          (f) 804.243.0294
> Virginia,        \     UNIX is irrelevant.      /        prs9k@Virginia.EDU
> Neurosurgery     /     Openness is futile.      \     prs9k@Virginia.BITNET
     ^^^
Hmm... should I say something like "Well, it doesn't take a neurosurgeon to
figure this out."  Nah.  I will offer several hints:

1) RTFM
2) Call Microsoft's technical support
3) Tell us specifically *what* you are having trouble configuring. 

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

END OF DOCUMENT