The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 92 03:30:29 GMT
From:      emcgough@ringer.cs.utsa.edu (Eric J. Mc Gough)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm,comp.protocols.tcp-ip.ibmpc,comp.sys.sun.wanted
Subject:   Re: At Home With X11 Windows ???

Is it realistic to work with an X11 windows interface over dial-up modems 
if you use SLIP or PPP?  

If so, what is the minum modem configuration:

     Modem Type         Theoritical Through Put

a. V.32bis/V.42bis   -          57.6K 
b. V.32bis/MNP-5     -          28.8K
c. V.32/V.42bis      -          38.4K
d. V.32/MNP-5        -          19.2K
e. other             -          less than 19.2K


Select the correct Answer: __

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 92 15:57:18 GMT
From:      a563700@hp9000.csc.cuhk.hk (CH Cheng)
To:        comp.protocols.tcp-ip
Subject:   Telebit's NetBlazer

Personally, I think NetBlazer is a very good product.  Could anyone tell
me whether there are other routers which function similiar to NetBlazer?

Thanks in advance.

Che-hoo Cheng
Computer Services Center
The Chinese Univ of Hong Kong

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1 Mar 1992 18:45:09 GMT
From:      mills@ccu.umanitoba.ca (Gary Mills)
To:        comp.protocols.tcp-ip
Subject:   Advertize host routes with RIP?

I have a Sun-4/630 with two ethernet interfaces, which is not acting as a
gateway because it parallels another machine that is the gateway.  I would
like it to advertize host routes between its two interfaces so that other
machines on the two directly-connected ethernets don't use the gateway to
get to the other side of the 630.  I'd prefer to do it this way, rather than
install static host routes on all those machines.  Is there a way to do this
using routed?  How about with gated?  It currently runs routed in quiet mode.

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

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 92 19:17:20 GMT
From:      bob@snuffy.dracut.ma.us (Bob Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP for SUN workstation

In article <2929@carroll1.cc.edu> pruttman@cerebus.cc.edu (Pete Ruttman) writes:
> 
> 4.	Add
> 
> 	pseudo-device slip5
> 
> 	to your CONFIG file.  If you want to preattach all the interfaces,
> 	use
> 	
> 	pseudo-device slip5 init slip_attach
> 
> 
> ^^^^^^^^^^^^^^^^^Where is this "CONFIG" file kept?
> 
This may not be absolutely correct for SunOS 4+, but on my system the
CONFIG file is named SNUFFY, it was derived from a file named GENERIC,
and resides in /sys/conf...

>
> 5.	Copy slip.h to /usr/include/sys/slip.h (and /sys/sys/slip.h)
> 
> ^^^^^^^^^^^^^^^^^^Why two places?
> 
When building a kernel the compiler looks in /sys/sys for include files,
when building user programs the compiler looks in /usr/include/sys...

> 
> 6.	Configure your kernel and install and boot it
> 
> ^^^^^^^^^^^^^^^^^^^^^Could someone explain this more completely?
> 
...again, this is for SunOS 3.5...

cd /sys/conf
copy GENERIC (or one of the other CONFIG files) to <whatever>
edit <whatever> as you may see fit (and as indicated above for your
	CONFIG file)
config <whatever>
cd ../<whatever>
make

>
> 7.	Compile and install the sliplogin program suid root.
> 
> ^^^^^^^^^^^^^^^^^^^^Does this mean put the program in a bin and
> 							 set the S bit?
> 
I installed  mine in /etc, and after copying you want to:
chown root sliplogin
chmod 4755 sliplogin

-- 
 \ Bob Smith         \ mx: bob@snuffy.dracut.ma.us
  \ 835 Mammoth Rd.   \ uucp: ...{ulowell|wang|wybbs}!snuffy!bob
   \ Dracut, MA. 01826 \ office && voice mail: +1 508 670-6712

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 92 20:18:21 GMT
From:      pdjames@ucrmath.ucr.edu (james t. o'linger)
To:        comp.protocols.tcp-ip
Subject:   Beginning programmer seeks help with TCP/IP



Hi, I am trying to write a tcp/ip based service, and I'd like a little help.

The tcp/ip-based service is supposed to allow people to connect to a port
on the host machine.  They can then type things in, and the service will
spit stuff back at them.  The service can allow up to a certain set number
of people to connect.  (I'm leaving a lot of detail out obviously, but this
is the general idea).

I have done some basic research.  I know that what I want to be working with
is socket(), bind(), accept(), select().  But the UNIX man pages, as usual,
are high on content, low on informational value. :(  I've talked to several
people about this and the best I've been able to figure out is the following
strategy:

   Initialization:  use socket() to create a new socket, bind() to link it
    to a port.

   New users:  accept() returns a file descriptor which I can read() and
    write() from/to.

   Getting input:  using select(), with a timeout length of 0 (I want the
    service to be able to do other things in the background at the same
    time people are typing things in).

   Shutting down a connection: close() on the fd.

   Shutting down the socket: ???

The kind of help I would like is references to relevant articles/books,
comments on the above strategy (and corrections if I've got something wrong),
pointers to concrete code that isn't too narrowly specialized, and caveats
in general about things I'll need to watch out for.

Please send mail to: pdjames@ucrmath.ucr.edu

This was posted for a friend.

-- 
pdjames@ucrmath.ucr.edu

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1 Mar 1992 20:24:58 GMT
From:      ddern@world.std.com (Daniel P Dern)
To:        comp.protocols.tcp-ip
Subject:   Seeking 'Internet Howlers' for Internet Society newsletter

For inclusion (with or without attribution) in an article in 
the Internet Society newsletter, I'm seeking 'Internet howlers' --
misstatements and misunderstandings re the Internet (NSFnet, ARPAnet,
usenet, et.al.), from the press, conversation, or any other sources.
For example, "savage [user] interface," from Forbes.  If possible,
please include your source.

Thanks!

Daniel Dern
ddern@world.std.com
617-926-8743
 


-- 
Daniel Dern, Ministry of Public Relations (MiniPurl)  (617) 926-8743
  High-tech journalism, PR and humor; substitute dance instructor
  Internet: ddern@world.std.com  UncaSam: PO Box 114 Belmont MA 02178

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 92 21:26:33 GMT
From:      pushp@nic.cerf.net (Pushpendra Mohta)
To:        comp.protocols.tcp-ip
Subject:   Re: Beginning programmer seeks help with TCP/IP

In article <20484@ucrmath.ucr.edu> pdjames@ucrmath.ucr.edu (james t. o'linger) writes:
>
>
>Hi, I am trying to write a tcp/ip based service, and I'd like a little help.
>

Beginning programmers will benefit by looking at the code for
simpler daemons like fingerd and whoisd.

I believe Comer's book has an example whois server.
 

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 92 23:37:02 GMT
From:      ji@cs.columbia.edu (John Ioannidis)
To:        comp.protocols.tcp-ip
Subject:   Re: Wireless Bridges for ethernet

In article <1992Feb24.145833.20359@isavax.isa.com> cliffb@isavax.isa.com (cliff bedore*) writes:
>We are looking at linking our corporate office with one of our remote
>offices ~ 5 miles away.  We can get a 56K link from the Phone company but
>there are the recurring monthly charges to contend with.  It seems to me
>that there must be some microwave links available that would let us bridge
>two ethernets together so they thought they were one.
>
>Does anyone have experience with anything like this?  Are any vendors
>reading who want to send info?   Please e-mail and I'll summarize
>
>Thanks for any thoughts you might have
>
>Cliff
>
>cliffb@isavax.isa.com
>...!uunet!isavax!cliffb
>


I'm not sure what the regulatory status is for such activities, but if
your two buildings have line-of-sight (you seem to imply that from the
fact that you want microwave links), you can use some of the wireless
LAN interface cards that have been around for a couple of years. I
would suggest a pair of NCR WaveLAN cards ($1100 each), a pair of 386
machines (<$1500 each), a pair of directional antennas for the 900MHz
band, and 75Ohm hardline to feed them (you don't want to be using RG59
at 1db/10ft loss!). With their standard omni antennas, the wavelans
have a 1/5th mile range, and provide a 2Mbps channel. It should be
trivial to enhance that to 5 miles by using a yagi with a large number
of elements. 

Hope this helps,

/ji

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Mon, 02 Mar 1992 08:47:09 GMT
From:      chip@chinacat.unicom.com (Chip Rosenthal)
To:        comp.unix.xenix.sco,comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: BOOTPD patches for SCO TCP/IP available

In article <1992Mar02.035757.7258@chinacat.unicom.com>
	chip@chinacat.unicom.com (Chip Rosenthal) writes:
>Ask your vendors to support the bootp protocol *with* the RFC1048 extensions!

Gack!  Make that RFC1084.

-- 
Chip Rosenthal   <chip@chinacat.Unicom.COM> | My mind's got a mind of its own.
Unicom Systems Development     512-482-8260 |   -Butch Hancock

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Mar 1992 14:44:22 GMT
From:      vittallo@ssd.comm.mot.com (John Vittallo)
To:        comp.protocols.tcp-ip
Subject:   select() ?? multitask??

A previos posting mentioned using the select() so he could do other things in his program.  What does select do in relation to a blocking and non-blocking socket.  How does it work?:w

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 92 15:22:49 GMT
From:      black@ll.mit.edu (Jerry Glomph Black)
To:        comp.protocols.tcp-ip
Subject:   PPP-capable version of PC-route?

I've heard that there's a PPP (rather than SLIP) version of the PC-route
software, possibly under a different name.  Does this exist? Where?

Thanks!
Jerry Black
MIT Lincoln Lab

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 92 16:18:03 GMT
From:      domenikos@delni.enet.dec.com
To:        comp.protocols.tcp-ip
Subject:   SNMP training available

The DTC SNMP training/availability schedule through September
is a follows:

* Network management applications development using SNMP  -- 3 days
                                             Dates: 4/08-10/1992
                                                    6/17-19/1992
                                                    9/16-18/1992
* SNMP Technical Introduction -- 2 days
                                Dates: 6/15-16/1992
                                       9/14-15/1992

For information and registration please
contact:

DTC
275 Wyman Street
Waltham, MA 02154
Tel: (617) 684-0060
Fax: (617) 684-0072



-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Mar 1992 19:06:16 GMT
From:      jcreem@theory.TC.Cornell.EDU (Jeffrey Creem)
To:        comp.protocols.tcp-ip
Subject:   Setting Character mode in daemons

Im trying to set up a daemon that will be accessed by telnet and
I have yet to figure out how to tell the remote telnet session
that it should go into character mode (instead of line mode).

As it stands the program is usable if the remote telnet user
goes into command mode and sets character mode on so I don't think
I need to allocate any pty's to do this..Any hints?  So far I have
tried using the raw() function in libcursesX but It has not helped.

(PS..Running Ultrix4.2 on DECstation 3100 if that helps)
Thanks

---------------------------------------------------------------------
cree7545@baryon.hawk.plattsburg.edu
---------------------------------------------------------------------

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Mar 1992 22:18:40 GMT
From:      poorman@convex.com (Peter Poorman)
To:        comp.protocols.tcp-ip
Subject:   Re: Beginning programmer seeks help with TCP/IP

In article <20484@ucrmath.ucr.edu> pdjames@ucrmath.ucr.edu (james t. o'linger) writes:

>Hi, I am trying to write a tcp/ip based service, and I'd like a little help.

The book "UNIX Network Programming" by W. Richard Stevens is an excellent
tutorial on this subject.

--Pete Poorman
  poorman@convex.com

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Mar 92 22:20:11 GMT
From:      vasoll@a.cs.okstate.edu (Mark Vasoll)
To:        comp.protocols.tcp-ip
Subject:   Need to do UUCP 'g' protocol over a 3Com CS/1 Terminal Server

Does anyone know if it is possible to get a 3Com CS/1 Terminal Server
running V4.1 of their software to pass binary data over a telnet session?
We need to be able to do this to reestablish our UUCP connections that
use the 'g' protocol.

Please respond by email, I'll post a summary if requested.

Thanks,
-- 
Mark Vasoll
Computer Science Department                Email:  vasoll@a.cs.okstate.edu
Oklahoma State University
Stillwater, Oklahoma

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Tue, 03 Mar 1992 00:08:15 GMT
From:      fff@wimsey.bc.ca (Fred Fierling)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Source for Embedded Controllers

What companies out there licence TCP/IP protocol source?
 
I'm looking for code which could be ported to a MC68000 based embedded
controller with a small real time operating system.

-- 
Fred Fierling    fff@wimsey.bc.ca       Tel: 604 875-1461   Fax: 604 875-9029

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Mar 1992 00:22:26 GMT
From:      tannerc@cu18.crl.aecl.ca (Chris Tanner)
To:        comp.protocols.tcp-ip
Subject:   ICMP redirect protocols

Greetings all

I am interested in how ICMP redirect packets work. As far as I
understand things, If machine A wants to connect to machine B which are
in different sub-nets (via the subnet mask) but actually on the same
ethernet, then machine A asks his friendly neighbourhood router to
connect to machine B. The router as well as passing the packet to
machine B, send a packet back to machine A telling it that it can call
machine B directly. Machine A may ignore the packet. 

My actual problem is that we have a class B IP address, but to make life
easier for routing, we use a class C netmask. When 2 Ultrix systems on
different sub-nets exchange files, they always seem to do it through the
router, even though both sub-nets are on the same ethernet.  (Some of
our sub-nets are connected via routers, and eventually all of them will
be connected via routers). 

All information on this subject is welcome. 

Thanks

Chris
-- 
Chris Tanner                  Email: tannerc@CU18.CRL.AECL.CA
AECL Research                 Phone: (613) 584-3311 X4053       
Chalk River, Ont.             FAX:   (613) 584-1082
Canada, K0J 1J0

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 92 06:51:53 GMT
From:      romkey@asylum.UUCP (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Source for Embedded Controllers

fff@wimsey.bc.ca (Fred Fierling) writes:

>What companies out there licence TCP/IP protocol source?
> 
>I'm looking for code which could be ported to a MC68000 based embedded
>controller with a small real time operating system.
 
>-- 
>Fred Fierling    fff@wimsey.bc.ca       Tel: 604 875-1461   Fax: 604 875-9029

My company, Epilogue Technology, licenses a highly portable implementation
of TCP/IP, and SNMP. You can get in contact with us at the number in my
signature (for technical information) or 805 650-7107 for sales & marketing.
-- 
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice: 617 942-0915

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Mar 1992 07:29:33 GMT
From:      skl@cs.sfu.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP redirect protocols

In article <1992Mar3.002226.11925@cu23.crl.aecl.ca>, tannerc@cu18.crl.aecl.ca
 (Chris Tanner) wrote:
>My actual problem is that we have a class B IP address, but to make life
>easier for routing, we use a class C netmask. When 2 Ultrix systems on
>different sub-nets exchange files, they always seem to do it through the
>router, even though both sub-nets are on the same ethernet.

ICMP-redirect can't help you in this case.  Since the "redirect to"
address embedded in the ICMP-redirect packet is an IP address rather
than an Ethernet address, it can only redirect the source node to
send to another node on the same IP subnet.  This is sufficient
for its originally intended purpose -- to redirect to the optimal
router on a multi-routers IP network/subnet.  However, it does not
provide the facility to short-cut the "mirror" router in a Ethernet
segment with multiple IP subnets.

In general, hosts in different subnets need to go through a router
to talk to each others, regardless of if they are on the same physical
Ethernet segement or not.

In practice, some machines' TCP/IP software can be configured to
not need to use the mirror router.  You mileage will vary depending
on the TCP/IP implementation involved.

...Sam
-- 
Samuel Lam <skl@cs.sfu.ca>
Network Support Group, Centre for Systems Science
Simon Fraser University, Burnaby, B.C., Canada

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 1992 10:05:44 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP redirect protocols

In article <1992Mar3.002226.11925@cu23.crl.aecl.ca> tannerc@cu18.crl.aecl.ca (Chris Tanner) writes:
>I am interested in how ICMP redirect packets work. As far as I
>understand things, If machine A wants to connect to machine B which are
>in different sub-nets (via the subnet mask) but actually on the same
>ethernet, then machine A asks his friendly neighbourhood router to
>connect to machine B. The router as well as passing the packet to
>machine B, send a packet back to machine A telling it that it can call
>machine B directly. Machine A may ignore the packet. 

This is not true.  Machines on different subnets never communicate
directly.  The sending machine determines whether a destination can be
reached directly or through a router by masking the local and remote
addresses with the subnet mask and comparing the results.  If they aren't
equal, it will always go through a router.

Once the sender has determined that the destination is not directly
reachable, the routing table and ICMP Redirects are used to tell it which
router to use.  Machines that don't eavesdrop on routing protocols must
have a default router configured, and may also have some specific routes
configured.  If a machine sends a packet to a router, and it's not the best
router for that destination, it will send the originating machine a
redirect; this most often happens when the default router is being used.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 92 10:55:03 GMT
From:      ian@unipalm.uucp (Ian Phillipps)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain Name Service

dweissman@amarna.gsfc.nasa.gov (WiseGuy) writes:

>Are there recommended books or papers on Domain Name Service, it's
>use, set-up, and theory?  

The best guide I know to setup is in TGV's MultiNet manual.  After
reading the "named" man page and despairing, I set up an "island" DNS
from TGV's manuals, which then worked first time when connected to the
Internet.  MultiNet's a VMS TCP/IP package: you may have a copy of it
on your site somewhere.

Comer, of course, has a chapter on it which describes the theory.
"Internetworking with TCP/IP" by Douglas Comer. If you don't know of this
book, correct that omission now!

[Disclaimer/apology: we sell TGV's software.  However the fact that we
sell software doesn't always mean that we like its manuals :-) ]

-- 
Ian Phillipps, Unipalm Ltd, 216 Science Park,		Phone +44 223 420002
Milton Road, Cambridge, CB4 4WA, England.		Phax  +44 223 426868
Vapourware is the programming industry's answer to solid-state computers.

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 92 15:33:07 GMT
From:      ian@spider.co.uk (Ian Heavens)
To:        comp.protocols.tcp-ip
Subject:   TCP probe byte transmission

Some TCP/IP implementations, notably Suns, adhere to the literal
truth when offering a zero window and do not accept and ACK a 
subsequently transmitted probe byte.

This is a nuisance, as this would normally be retransmitted after
a timeout, which is a performance hit.

Special handling of this situation could include

1.  always send probe bytes in the first segment after the window is opened.
2.  detect non-Acknowledgement of probe bytes, and in this case, send in
the first segment after the window is opened.

1) is slightly simpler but implies that receivers that do buffer incoming
probe bytes must ignore the first byte of the next segment.

Has anyone any strong feelings about this?  It isn't mentioned in the
New Testament (RFC1122).

ian


---
Ian Heavens				ian@spider.co.uk                 
Spider Systems Ltd			
Spider Park, Stanwell Street		
Edinburgh, EH6 5NG, Scotland		+44 31 554 9424 (Ext 4166)
--

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 92 17:31:13 GMT
From:      Lyle_Seaman@TRANSARC.COM
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP redirect protocols

barmar@think.com (Barry Margolin) writes:
> In article <1992Mar3.002226.11925@cu23.crl.aecl.ca> tannerc@cu18.crl.aecl.ca \
> (Chris Tanner) writes:
> >I am interested in how ICMP redirect packets work. As far as I
> >understand things, If machine A wants to connect to machine B which are
> >in different sub-nets (via the subnet mask) but actually on the same
> >ethernet, then machine A asks his friendly neighbourhood router to
> >connect to machine B. The router as well as passing the packet to
> >machine B, send a packet back to machine A telling it that it can call
> >machine B directly. Machine A may ignore the packet. 
> 
> This is not true.  Machines on different subnets never communicate
> directly.  The sending machine determines whether a destination can be
> reached directly or through a router by masking the local and remote
> addresses with the subnet mask and comparing the results.  If they aren't
> equal, it will always go through a router.

This is not true, either.
It is possible for multiple logical subnets to coexist on the same
physical medium.  I believe that is the case referred to by the
posting ("actually on the same ethernet").  In that case, a router may
be configured with multiple IP addresses for the same MAC address.
When the router forwards a packet from machine A to machine B, and it
goes out the same interface that the packet from machine A was
received on, it may also send an ICMP redirect to machine A.  (This is
part of the "is there a better router that should have been used
instead" processing).  If the IP implementation on machine A is worth
much, it will send future  traffic to machine B directly to it instead
of via the router.  This is all part of the "route add xxx metric 0"
or "multiple logical networks, same physical network" universe of
discussions.

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

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Mar 92 19:24:28 GMT
From:      mcdowell@exlog.com (Steve McDowell)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Source for Embedded Controllers

fff@wimsey.bc.ca (Fred Fierling) writes:
>What companies out there licence TCP/IP protocol source?
> 
>I'm looking for code which could be ported to a MC68000 based embedded
>controller with a small real time operating system.
>
> <1992Mar03.000815.7965@wimsey.bc.ca>:
> My company, Epilogue Technology, licenses a highly portable implementation
> of TCP/IP, and SNMP. You can get in contact with us at the number in my

Two comments: 

1) Running TCP/IP in a real-time embedded environment seems real dangerous.
	I don't know your application, and the 68K is a pretty powerful
	processor -- but you need to watch how much time you're spending
	servicing broadcast ARP requests and the like.....and,

2) Before spending much money on code that you are going to have to port
	anyway, take a look at Comer's book "Internetworking with TCP/IP, 
	volume II" -- it has complete source broken down into functional
	sections; and all code is available "magnetically" from the 
	publisher (on line anyone???). You might also look at the Berkeley
	networking stuff, but if you aren't intimate with their code, it 
	can get a bit hairy at times.

Just my opinion...

-- 
Steve McDowell             . . . . o o o o o 		Opinions are 
Exlog, Inc.	                  _____      o     	mine, not my 
mcdowell@exlog.com      _____====  ]OO|_n_n__][.    	employers..
		       [_________]_|__|________)<   

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 92 19:50:01 GMT
From:      rypma@hppad.waterloo.hp.com (Ted Rypma)
To:        comp.protocols.tcp-ip
Subject:   Re: At Home With X11 Windows ???

I use CSLIP at an interface rate of 38.4 kbps with V.32bis / V.42bis modems,
running an X-terminal (X11/R4 protocol on the wire).  For xterm windows with
vi and other character-based apps this works fine for me.  X11 based clients
such as FrameMaker are not satisfactory (although Wingz is tolerable).

As a plus, I use the X-terminal as an IP router to get network access for my
PC while I use the X-terminal.

What I really want and what I get is access to multiple logins simultaneously.

Ted Rypma
HP Panacom Division
Waterloo, Ontario

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Mar 1992 20:03:02 GMT
From:      werme@alliant.com (Ric Werme)
To:        comp.protocols.tcp-ip
Subject:   Can anyone explain this code fragment?

In the 4.3 Tahoe networking code, we have this little routine:

sbreserve(sb, cc)
	struct sockbuf *sb;
	u_long cc;
{
	if (cc > (u_long)SB_MAX * CLBYTES / (2 * MSIZE + CLBYTES))
		return (0);
	sb->sb_hiwat = cc;
	sb->sb_mbmax = MIN(cc * 2, SB_MAX);
	return (1);
}

In the BSD-net.2 tape, the if statement becomes:

	if (cc > sb_max * MCLBYTES / (MSIZE + MCLBYTES))

What is this expression trying to say?  sb_max*MCLBYTES is in "units"
of square bytes, which encourages me to reformat the expression as:

	    sb_max
	--------------
	 MSIZE
	--------  +  1
	MCLBYTES

Alliant's MSIZE is 256, the MCLSIZE is 2048 (to hold an entire Ethernet
frame).  So I guess the code is putting a ceiling on the high water mark by
accounting for the overhead of the small mbufs that point to the cluster
mbufs.  Big deal.  Especially since the cluster mbufs may not be full.

So, the question becomes:

1) Why bother, especially why the heavy hand of returning zero?

2) Just *what* is the intent, anyway?

3) How is the BSD-net.2 version "better"?
-- 

| A pride of lions              | Eric J Werme                   |
| A gaggle of geese             | uucp: mit-eddie!alliant!werme  |
| An odd lot of programmers     | Phone: 508-486-1214            |

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Mar 1992 20:07:08 GMT
From:      ericm@microunity.com (Eric Murray)
To:        comp.protocols.tcp-ip
Subject:   PCroute information



I'm considering using PCroute instead of buying
another cisco router.  I'm interested in hearing
about people's experiences with PCroute, and throughput
measurements, if you've got any.

Email me, and I'll summarize.

Thankx.


-- 
  Eric Murray             {ericm,usenet,postmaster,root}@microunity.com

   "Usenet is a right, a left, a jab, and a sharp uppercut to the jaw.
  The postman hits!  You have new mail."- Edward Vielmetti.

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Mar 1992 20:48:03 GMT
From:      ez@mentor.gandalf.ca (Eugene Zywicki)
To:        comp.misc,comp.protocols.tcp-ip
Subject:   Checksum coverage references wanted

	I am looking for technical references that explain the exact
   coverage one gets when using a 'checksum' for error detection of
   packetized information.

	Specifically I would like to know what percentage of various 
   errors can be detected by using a 16 bit checksum over packets up
   to 256 octets long. RFCs 1071, 1141 and 1146 don't contain that kind
   of information, but I'm hoping that someone on the net will be able
   to steer me to the proper reference.

					Thanks in advance,
						Eugene
-- 
Eugene E. Zywicki          CAnet: ez@gandalf.ca
Gandalf Data Ltd.          Voice: (613) 723-6500
Nepean, Ontario              Fax: (613) 226-1717
Canada  K2E 7M4

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 92 21:05:17 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP probe byte transmission

In article <1992Mar3.153307.29297@spider.co.uk> ian@spider.co.uk (Ian Heavens) writes:
>Some TCP/IP implementations, notably Suns, adhere to the literal
>truth when offering a zero window and do not accept and ACK a 
>subsequently transmitted probe byte.
>
>This is a nuisance, as this would normally be retransmitted after
>a timeout, which is a performance hit.
>
>Special handling of this situation could include
>
>1.  always send probe bytes in the first segment after the window is opened.
>2.  detect non-Acknowledgement of probe bytes, and in this case, send in
>the first segment after the window is opened.
>
>1) is slightly simpler but implies that receivers that do buffer incoming
>probe bytes must ignore the first byte of the next segment.
>
>Has anyone any strong feelings about this?  It isn't mentioned in the
>New Testament (RFC1122).

Receivers really ought to be prepared to trim duplicate data from the
front end of a segment anyway, even though the standard falls short
of demanding it, so the extra complication you fear is probably
not extra at all.

However, I admit to being slightly mystified by the question.
When the sender receives an ACK that opens a previously closed window,
it should send a segment beginning at SND.UNA.
If a probe octet has been accepted and acknowledged, then SND.UNA will
have been advanced over it, and it will not be retransmitted, according
to the normal "rules".  If the sender has received an ACK that did
not indicate acceptance, then SND.UNA will not have advanced, and the
probe will be resent in the first segment. 

There is a small likelihood that the sender has not yet received any ACK
for his most recent probe attempt, and in this case it is possible that
retransmission will turn out to be redundant, but I think you should go
ahead and retransmit it anyway.  If the receiver has already accepted it,
the extra processing is small.  If you didn't resend it and the receiver
had thrown it away, you would incur an unnecessary retransmission timeout.

Reading between the lines, I sense that you feel a receiver might
accept a segment at the right window edge, but refuse to acknowledge it
because it was outside the receive window.  This is bizarre behaviour.
The receiver should either accept it, and admit that it has done so,
or throw it away and ACK only what it has accepted.  What is the purported
advantage of "buffering incoming probe bytes"?
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 92 21:17:04 GMT
From:      jwo@hpuerca.atl.hp.com (Jim O'Shea)
To:        comp.protocols.tcp-ip
Subject:   Re: A Subnetting Question

/ hpuerca:comp.protocols.tcp-ip / system@eagle.navsses.navy.mil /  1:58 pm  Feb 25, 1992 /
>I have a question concerning subnets.  If I have a network (for example
>155.155.0.0) and a subnet mask 0.0.240.0 are the subnets 155.155.240.0 and
>155.155.0.0 usable? or am I restricted to subnet number that are not all ones
>(155.155.240.0) and all zeros (155.155.0.0)?
----------

 Read RFC 1122 ( Requirements for Internet Hosts ) Sec 3.2.1.3, Page 31:  
    IP addresses are not permitted to have the value 0 or -1 for
    any of the <Host-number>, <Network-number>, or <Subnet-
    number> fields (except in the special cases listed above).  

-1 as used in RFC 1122 is shorthand for all 1's. The special cases refer
to types of broadcasts. 

I believe the above are not usable but this is my interpretation. Of course,
some systems may not adhere to the rfc.

Jim O'Shea
Hewlett Packard

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 92 21:38:33 GMT
From:      bricker@osprey.cahs.colostate.edu (Chris Bricker)
To:        comp.protocols.tcp-ip
Subject:   3270 Emulator

HELP!!
We need a 3270 emulator for DEC ULTRIX, VMS, or preferably a 
PC package using DECnet.  We will soon be cut off from using
a "backdoor" approach with a VT220 emulator.

Many Thanks,
Chris Bricker
**************************************************************
Chris Bricker
College of Applied Human Sciences, Colorado State University
E-mail: bricker@osprey.cahs.ColoState.Edu
**************************************************************

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 92 22:02:34 GMT
From:      ryan@netcom.com (Robert Plant)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm,comp.protocols.tcp-ip.ibmpc,comp.sys.sun.wanted
Subject:   How to get started with MacLayers?

Excuse me for being a novice, but I picked up MacLayers at an FtP site and
had absolutely no idea how to coordinate the program with my remote unix
system. I have no experience in 'compiling' or 'scripting' and basically
want to ad the Mac interface to Unix. Any help is appreciated.

Thanks,
Ryan

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 92 22:46:14 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: Can anyone explain this code fragment?

In article <1992Mar3.200302.13886@alliant.com> werme@alliant.com (Ric Werme) writes:
>In the 4.3 Tahoe networking code, we have this little routine:
>
>sbreserve(sb, cc)
>	struct sockbuf *sb;
>	u_long cc;
>{
>	if (cc > (u_long)SB_MAX * CLBYTES / (2 * MSIZE + CLBYTES))
>		return (0);
>       sb->sb_hiwat = cc;
>	sb->sb_mbmax = MIN(cc * 2, SB_MAX);
 ...
>
>In the BSD-net.2 tape, the if statement becomes:
>
>	if (cc > sb_max * MCLBYTES / (MSIZE + MCLBYTES))
>
 ...
>
>
>2) Just *what* is the intent, anyway?

sb_mbmax is a limit on total memory use, and cannot be greater than SB_MAX.
sb_hiwat and cc are both limits on the amounts of actual data buffered.

Now, let me introduce you to this new invention, the "comment".
The one in the Tahoe code reads, in part:

 * Attempt to scale cc so that mbcnt doesn't become limiting
 * if buffering efficiency is near the normal case.

So, the intent is to relate the supplied "cc" limit to the SB_MAX hard
limit, so that under normal circumstances the sb_hiwat value will be
the limit first encountered.  This, in turn, means that if you call
sbreserve(sb, N) and get a successful return value, you have a reasonable
hope of actually being able to buffer N bytes before hitting a limit.

>
>3) How is the BSD-net.2 version "better"?

Well, it has a different estimate of "buffering efficiency in the normal case".
That may reflect differences elsewhere in the code, but I don't have one
here so can't check.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Mar 1992 22:57:03 GMT
From:      salim@tigger.Colorado.EDU (Salim Alam)
To:        comp.unix.internals,comp.protocols.tcp-ip
Subject:   3-way handshake help needed

Hi,

I need some help with understanding a 3-way handshake, especially 
the exact algorithm for an initial connection, where a client (A)
and server (B) want to establish a connection.

According to Tanenbaum, the following protocol is used:

        A sends Connection Request (CR) with a seq#=x

        B receives it and returns a Connection Confirm (CC) with 
          seq#=y and ack#=x

	A sends an Acknowledgement (ACK) with seq#=x, ack#=y

Now, my questions are:
1. What should B do after sending the CC? Should it wait for an
   ACK, and keep sending the same CC until it gets an ack for it?
   What if the original CR was some old duplicate floating around?
2. What should A do after sending an ACK?  How can it know if the
   ACK succeeded?

I would think that one of the purposes of the 3-way handshake would
be that both A and B would end up with an established connection, and
could go about sending/receiving data.  This doesn't seem possible
in the light of delayed duplicated/old packets floating around in the
network -- at least one side has to be the unsure one, ready to restart
the handshake process if something goes wrong.

Is there an established algorithm for this?

Any information is appreciated.

Thanks.

-Salim

[sorry if this question is not appropriate for one of the newsgroups]
-- 
Salim Alam (Behold! It is I! ) {}"New processes are created by other processes,
University of Colorado, Boulder{} just like new humans" - Nemeth, et al, Unix
INTERNET: salim@cs.colorado.edu{} System Administration Handbook. [Im SAILING!]
NeXTMail: salim@pizza.rmNUG.org{} STD. DISCLAIMER: "My _OPINIONS_ are my own!"

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Tue, 03 Mar 1992 23:25:47 GMT
From:      alen@crash.cts.com (Alen Shapiro)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: HELP...RIP storms using ka9q SLIP connect? (longish)

In <1992Mar03.030206.10630@crash.cts.com> alen@crash.cts.com (Alen Shapiro) writes:

>I'm trying to set up ka9q on a PC (Version 911229). I have ka9q working
>on my mac (Net/MAC(55)) but the mac version can't do hop checks which
>I need to debug my real problem which is access to the UK. (but I digress).

...description of RIP traffic with ever decreasing ttl DELETED...

Well, guess what...I got past this stage. I connected mac to PC via KA9Q,
set the mac up as trout (the host) and tried pinging with trace sl0 set.

Simulated trout was getting messages from a machine with ip address
0.0.0.0 even though the sending PC responded to the "ip addr" command
with a correct address. Turned out that "ifconfig sl0" was not
inheriting the ip address. If I do a "ifconfig sl0 ipaddress shappy"
the host responds.

Now back to the original problem. Now I have a version of KA9Q that can
do a "hop check" to determine why my pings to the UK do not work. The
hop check responds like this...

Resolving janet...traceroute to 128.86.8.7:33434
 1: 128.49.32.13  shappy.nosc.mil. (0ms) (0ms) (0ms)
 2: 128.49.16.7   trout.nosc.mil. (220ms) (220ms) (220ms)
 3: 128.49.16.2   (220ms) (220ms) (220ms)
 4: 132.249.16.10 (220ms) (220ms) (165ms)
 5: 129.140.75.6  (275ms) (220ms) (275ms)
 6: 129.140.73.11 (330ms) (275ms) (330ms)
 7: 129.140.9.79  (330ms)
    129.140.9.15  (330ms)
    129.140.9.79  (330ms)
 8: *** *** ***
 9: *** *** ***
.....identical sequentially numbered lines deleted.....
29: ...max TTL exceeded

Looks like I need to pick up a routing table. Looks like I need to find
some documentation. Looks like I'm slowly getting there.

Thanks to all those who responded.

--alen

alen@crash.cts.com

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Mar 92 23:26:06 GMT
From:      reece@eco.twg.com (Reece R. Pollack)
To:        comp.protocols.tcp-ip
Subject:   Re: Characteristics round trip time using UDP/IP


In article <treb.699285192@dutepp13>, [NOT FOUND] (Bert Visscher PACS) writes:
|>I am trying to model communication using the UDP/IP protocol.
|>During this research I studied the round trip time of packets
|>with variable length between a sun sparc 2+ and an IBM os2
|>machine. To my supprise, the round trip time looked like this.         
|>
|>
|>Time |
|>     |
|>  ^  |
|>  |  |
|>     |
|>     |
|>     |         ***
|>     |        *   *
|>     |     ***     **                    ************
|>     |    *          *       ************
|>     | ***           ********
|>     |*
|>     |
|>     |
|>     --------------------------------------------------
|>                   500                    -> Packet Length
|>
|>I think, the increased time which occurs step by step for small
|>packets is due to allocation of 'mbuf' buffers. What I cannot 
|>explain is the decreased round trip for packets larger than 515
|>bytesi, which increases gradually. 
|>
|>Who knowns more about this phenomenon and can explain this,
|>or knowns some good literature about this subject in particular,
|>and studies of round trip times in general.
|>
|>Thanks, Bert.

I can't speak for your particular implementations, but BSD has two different
sizes of buffers it can allocate: Mbufs, which are 128 bytes long, including
overhead, and Clicks, which are larger (like 2k bytes). I suspect the
allocation overhead and algorithms used account for this difference.

--
Reece R. Pollack
Senior Software Engineer
The Wollongong Group, Inc.

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Mar 1992 00:05:32 GMT
From:      panos@tigger.Colorado.EDU (Panos Tsirigotis)
To:        comp.protocols.tcp-ip
Subject:   RFCs for rsh, rexec ?

I am aware of the RFC that describes the rlogin protocol. Are there also
RFCs for rsh and rexec ?

Panos

-- 
Panos Tsirigotis, CS grad                        
Pmail: Computer Science Dept., U. of Colorado @ Boulder, Boulder, CO 80309-0430
Email: panos@cs.colorado.edu

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 92 02:38:36 GMT
From:      pdjames@ucrmath.ucr.edu (james t. o'linger)
To:        comp.protocols.tcp-ip
Subject:   Thanks for the copious help... :)





Thanks for the responses (52 so far)!  Basically, they can be summed up as

"Buy _UNIX network programming_ by Richard W. Stevens."

Ok, I will, and for the people who took the time to send me advice, reams
of code, etc... thank you!  I wish I had the time to respond to you all
personally... please accept this as thanks...

This was posted for a friend.

-- 
pdjames@ucrmath.ucr.edu

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Mar 1992 02:48:43 GMT
From:      vaf@Valinor.Stanford.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP redirect protocols

In article <1992Mar3.002226.11925@cu23.crl.aecl.ca>, tannerc@cu18.crl.aecl.ca (Chris Tanner) writes:
|> Greetings all
|> 
|> I am interested in how ICMP redirect packets work. As far as I
|> understand things, If machine A wants to connect to machine B which are
|> in different sub-nets (via the subnet mask) but actually on the same
|> ethernet, then machine A asks his friendly neighbourhood router to
|> connect to machine B. The router as well as passing the packet to
|> machine B, send a packet back to machine A telling it that it can call
|> machine B directly. Machine A may ignore the packet. 
|> 
|> My actual problem is that we have a class B IP address, but to make life
|> easier for routing, we use a class C netmask. When 2 Ultrix systems on
|> different sub-nets exchange files, they always seem to do it through the
|> router, even though both sub-nets are on the same ethernet.  (Some of
|> our sub-nets are connected via routers, and eventually all of them will
|> be connected via routers). 

As has been described by other respondants, you are doing something that ICMP
redirect was never designed to handle. There are several klugy ways to work
around this problem, including:

    - Lie to your hosts and tell them the network is unsubnetted. You'll have
      to make sure that all of your machines agree on the broadcast address,
      though (I'd recommend configuring all of them to use 255.255.255.255),
      or there is a significant potential for broadcast storms. You'll also
      have to make sure that your router supports Proxy-ARP so that it can
      answer the ARP requests made for destinations on subnets which are not
      on the same physical wire.

    - Configure all hosts to know about all of the logical subnets on that
      Ethernet. On BSD Unix-based systems (SunOS, Ultrix, etc.) this can be
      accomplished by using "/etc/route" to add 0-distance routes to all of
      the logical subnets which share the same wire.

    - Configure the hosts to ARP for everything. I believe this can be done on
      BSD-based systems by adding a 0-distance route to the "default". Your
      router will need to support Proxy-ARP to use this kluge as well.

None of these options is particularly elegant, but then again, putting multiple
logical IP subnets on a single wire doesn't lend itself to elegant solutions.

	--Vince



-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 92 04:16:43 GMT
From:      nima@carina.unm.edu (nima bahrami)
To:        comp.protocols.tcp-ip
Subject:   packet driver :-( :-( .... :-)))



Hello  Everyone : 				3/3/92

I have two questions :

1)

Is a "packet driver" not  like a router that decide where packets should be
guided to [e.g. different segments of network/networks of diff. nature] ?
What is a packet driver ?



2)

What is the function of "subnet masking" in refference to tcp/ip ?

Is it not  for striping off information from the packet ?


ThankXX
nima@triton.unm.edu

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 92 05:38:10 GMT
From:      C506634@umcvmb.missouri.edu (Eric Edwards)
To:        comp.protocols.tcp-ip
Subject:   NAOL referenence in RFC 658

In the RFC 652 (cariage return disposition) and RFC 658 there is a reference
to section 4 of "NAOL" and NAOLFD.  In particular the motivation for the option
(and presumably the mechanism) is explained there.  Now, I know what NAOLFD is.
Section 4 says "Please refer to section 4 of the NAOL and of the NAOLFD Telnet
option description"
 
Now refering back to RFC 658 is no big help but what is NAOL?  And more
directly, what mechanisms do these options negotiate?
 
Eric Edwards: c506634 @   | "MS-DOS is one of those rare environments where
Inet: umcvmb.missouri.edu |  applications are written around the operating
Bitnet: umcvmb.bitnet     |  system rather than under it."

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 MAR 92 12:26:03 EST
From:      domenikos@fsdev.enet.dec.com
To:        comp.protocols.tcp-ip
Subject:   Need VAX/VMS/TCP/IP consulting help

Hi there,
Can someone recomend to me  a good VAX/VMS system manager/TCP/IP consultant/
trainer  to work with me on a related project at DTC.

Please Contact:
George Domenikos
DTC
voice: (617) 684-0060
FAX  : (617) 684-0072


thanks for any leads 


-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Mar 1992 12:38:48 GMT
From:      freedse@gdstech.grumman.com (Seth Freedman)
To:        comp.protocols.tcp-ip
Subject:   Multiple ip #s per interface.  Routing question.

   Has anyone had experience with assigning multiple TCP/IP addresses
to a Wellfleet router Ethernet Port.  We are looking to migrate to
Class "B" subnet routing (mask = 255.255.0.0), and want to keep a
consistent subnet mask for all routers.  Since we have network
segments with more than 255 hosts, we use multiple subnets per wire. I
want to avoid re-addressing, or purchasing more hardware.

   Any experiences with other routers would also be helpfull. Email or
Post a response.  Thanks.
-- 
Seth Freedman                |  freedse@gdstech.grumman.com | The usual     
Grumman Data Systems         |  Compuserve ID: 70640,2613   | disclamer     
1111 Stewart Ave  MS:B29-111 |  Voice: (516) 346-9668       | statement     
Bethpage, NY 11714           |  Fax:   (516) 575-5020       | applies ... 

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Mar 1992 14:36:18 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: packet driver :-( :-( .... :-)))

In article <1tthvm-@lynx.unm.edu> nima@carina.unm.edu (nima bahrami) writes:

   Is a "packet driver" not  like a router that decide where packets should be
   guided to [e.g. different segments of network/networks of diff. nature] ?
   What is a packet driver ?

The term "packet driver" is usually applied to MS-DOS software that meets
FTP Software's Packet Driver Specification.

   What is the function of "subnet masking" in refference to tcp/ip ?

Subnet masking is a response to the growth of the Internet.
Originally, addresses were assigned as A (subnet mask of 255.0.0.0), B
(255.255.0.0), and C (255.255.255.0), and routing only occurred
between whole nets.  Well, this is clearly (well, it's clear *now*)
inadequate.  So subnet masking was invented.  A subnet mask is, simply
enough, a mask other than one of the above.  It's almost always the
extension of existing "1" bits further to the right, although a subnet
mask may be non-contiguous.

Certain popular routing protocols (translation: RIP) were invented
before subnet masking, so they only work if you use one subnet mask
across your entire A, B, or C class net.

Someone, somewhere, has software that automatically assigns subnets in
such a manner that very few addresses are wasted.  You can't use it
with RIP because it uses variably-sized subnet masks.  But that's
okay, because RIP isn't really all that good.  It's just ubiquitious.
Look to OSPF to replace it.

--
--russ <nelson@sun.soe.clarkson.edu> I'm proud to be a humble Quaker.
Peace is not the absence of war.  Peace is the presence of a system for
resolving conflicts before war becomes necessary.  War never creates peace.

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Mar 1992 14:57:21 GMT
From:      chanda@sunws0.cs.psu.edu (Chanda Dharap)
To:        comp.protocols.tcp-ip
Subject:   Re: Thanks for the copious help... :)


This is kinda late but I found it just yesterday..

 "An introduction to 4.3BSD Interprocess Communication Tutorial"
-- Stuart Sechrest
  (University of California, Berkeley)

I found this a great help as it not only discusses the ipc paradigms,
but has extensive examples..

U'd probably find it in the archives at U Calif.(berkeley)

- good luck,

chanda
Chanda Dharap
Penn State University
email : chanda@cs.psu.edu

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 92 15:43:39 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: packet driver :-( :-( .... :-)))

In article <NELSON.92Mar4093618@cheetah.clarkson.edu> nelson@sun.soe.clarkson.edu (Russ Nelson) writes:
>In article <1tthvm-@lynx.unm.edu> nima@carina.unm.edu (nima bahrami) writes:
 
>   What is the function of "subnet masking" in refference to tcp/ip ?
>
>Subnet masking is a response to the growth of the Internet.
>Originally, addresses were assigned as A (subnet mask of 255.0.0.0), B
>(255.255.0.0), and C (255.255.255.0), and routing only occurred
>between whole nets.  Well, this is clearly (well, it's clear *now*)
>inadequate.  So subnet masking was invented.  A subnet mask is, simply
>enough, a mask other than one of the above.  It's almost always the
>extension of existing "1" bits further to the right, although a subnet
>mask may be non-contiguous.

This is not quite all the story.

There is an assumption inherent in subnetting that, from far enough
away, it is reasonable to treat the subnets of a network as a single
entity for routing purposes.  Only when you get "up close", do you have
to distinguish the different subnets.  This implies that the subnets of
a network should all be reasonably well connected together.

For example, the University of Toronto uses the class B network address
128.100.X.Y.   Locally, we have many (75?) separate ethernets, token ring nets,
etc., each implementing part of the University "network".  Here, we need to
distinguish these parts from one another, and so we use a subnet mask that
designates "X" above as a subnet number.  But, from far away, you may route
all packets destined to 128.100 in the same way, ignoring our "fine structure".

that way 
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1992 19:30:39 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.unix.internals,comp.protocols.tcp-ip
Subject:   Re: 3-way handshake help needed

[I've set the Followup-to only to comp.protocols.tcp-ip, since there
doesn't seem to be anything about Unix in the question.]

In article <1992Mar3.225703.14233@colorado.edu> salim@tigger.Colorado.EDU (Salim Alam) writes:
>I need some help with understanding a 3-way handshake, especially 
>the exact algorithm for an initial connection, where a client (A)
>and server (B) want to establish a connection.
[Algorithm omitted]

A good way to answer these questions is to get RFC 793.  It includes
detailed explanations and a state transition diagram.

>Now, my questions are:
>1. What should B do after sending the CC? Should it wait for an
>   ACK, and keep sending the same CC until it gets an ack for it?

Yes.

>   What if the original CR was some old duplicate floating around?

If it's for a connection that still exists, A will acknowledge the CC.

If it's for a connection that has gone away, A will send a RST.

>2. What should A do after sending an ACK?  How can it know if the
>   ACK succeeded?

After A sends the ACK, it puts the connection in the ESTABLISHED state and
starts using it.

If the ACK is lost, B will retransmit the CC, which A should acknowledge
again, as it does whenever a duplicate segment is received on an
established connection.

>I would think that one of the purposes of the 3-way handshake would
>be that both A and B would end up with an established connection, and
>could go about sending/receiving data.  This doesn't seem possible
>in the light of delayed duplicated/old packets floating around in the
>network -- at least one side has to be the unsure one, ready to restart
>the handshake process if something goes wrong.

This is known as the "two armies problem", and it's not solvable.  The
three-way handshake is generally considered sufficient.

Note that in TCP, all data segments include an acknowledgement field.
Therefore, even if the acknowledgement of the CC is lost, the first data
segment from A will also acknowledge it.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 92 19:40:13 GMT
From:      kurt@s5000.rsvl.unisys.com (Kurt Matthys x5693)
To:        comp.unix.internals,comp.protocols.tcp-ip
Subject:   Re: 3-way handshake help needed

salim@tigger.Colorado.EDU (Salim Alam) writes:

>Hi,
 
>I need some help with understanding a 3-way handshake, especially 
>the exact algorithm for an initial connection, where a client (A)
>and server (B) want to establish a connection.
 
>According to Tanenbaum, the following protocol is used:
 
>        A sends Connection Request (CR) with a seq#=x
 
>        B receives it and returns a Connection Confirm (CC) with 
>          seq#=y and ack#=x
 
>	A sends an Acknowledgement (ACK) with seq#=x, ack#=y
 
>Now, my questions are:
>1. What should B do after sending the CC? Should it wait for an
>   ACK, and keep sending the same CC until it gets an ack for it?
>   What if the original CR was some old duplicate floating around?
>2. What should A do after sending an ACK?  How can it know if the
>   ACK succeeded?
 
>I would think that one of the purposes of the 3-way handshake would
>be that both A and B would end up with an established connection, and
>could go about sending/receiving data.  This doesn't seem possible
>in the light of delayed duplicated/old packets floating around in the
>network -- at least one side has to be the unsure one, ready to restart
>the handshake process if something goes wrong.

1. B should wait for the ACK for the CC. If it is not received in a 
   reasonable time (i.e. the retransmission timeout), it should resend the
   CC. After resending it some number of times without receiving an ACK,
   B should give up. If the CR was an old duplicate, A will send a RST
   when it receives the CC.

2. After A sends the ACK it can start sending data. It will know if the 
   ACK got to B if the data is acked and it never receives another CC.

Kurt Matthys
Unisys Corp.

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Mar 1992 21:26:08 GMT
From:      kbridge@magnus.acs.ohio-state.edu (Doug Karl)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.misc
Subject:   Anouncing a New Protocol Filtering Bridge available via anonymous ftp

			Academic Computing Services
		Network and Communications, Development Group
			 of The Ohio State University

	   is pleased to announce the availability via anonymous ftp of:

			  The OSU KarlBridge (Ver 1.2)

The OSU KarlBridge is a program, that runs on a 286 or 386 clone. It provides
a unique and inexpensive Ethernet to Ethernet bridge that performs
sophisticated protocol filtering. The bridge filters packets based upon ANY
Ethernet protocol like IP, XNS, DECNET, AppleTalk, 3-Com, Novell, etc. In
addition it will filter IP packets based upon IP address, network, subnet,
and socket. It will also filter DECNET packets based upon DECNET address,
area, and object number and name.

Some Examples:

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

  You can configure the bridge to keep public computer lab users from
  telneting to the SMTP socket and sending bogus e-mail or from ftping
  into or out of your lab.

  You can configure the bridge to keep file servers (Novell, Banyan, MAC,
  and etc.) on the same network from interacting with each other in
  undesirable ways.

The OSU KarlBridge is pingable with SNMP support coming soon. It is the most
flexible 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. The OSU KarlBridge can be obtained via anonymous ftp from:

    nisca.acs.ohio-state.edu, 128.146.1.7, in the directory /pub/kbridge.

ATTENTION pcbridge users!  There are a versions compatible with your hardware.

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

Doug Karl
Senior Computer Specialist
The Ohio State University

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 92 22:50:02 GMT
From:      mahmood@freedom.msfc.nasa.gov (Rafique Mahmood)
To:        comp.protocols.tcp-ip
Subject:   UDP is not connectionless. Question on UDP protocol.

I ran UDP client server program to get the throughput and CPU
utilization. I ran into few problems or questions:

Question 1. UDP is connectionless, therefore it should not matter
	   for a client( who is the sender) is there iny receiver
	   waiting to receive the packets. But surprisingly enough,
	   I found out it does matter. When there is a receiver, 
	   sender's rate become almost double. I ran the test on
	   different machines ( two Decstation 5000/200, Decstation 5000/240,
	   Sparcstation II, Sun 4/260, Silicon Graphics 4/120 ) and
	   same results of send rate drops when no receiver. Can anyone
	   explain what is happening? Is UDP is not completely connectionless.
 	
Question 2. After I run the program for many times ( for example, from morning 
           till afternoon ) on Decstation 5000 I see the message 
		"Sending message: No buffer space available" and can not run
           sender program any more. I even rebooted the system still
	   could not run program anymore. Similarly, on Sun 4/260, and 
	   on Sparcstation II I see the message "mbuf map full". Please
	   tell me if anyone has any idea.

Thanks in advance,
Rafique Mahmood
mahmood@freedom.msfc.nasa.gov
Phone: 205-544-6475

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Mar 92 23:14:26 GMT
From:      mcdowell@exloghou.exlog.com (Steve McDowell)
To:        comp.protocols.tcp-ip
Subject:   Raw sockets on SunOs?

I attempt to create a raw socket under SunOs4.x with the 
following options:

	sockfd = socket( AF_INET, SOCK_RAW, IPPROTO_RAW); 

It succeeds; until I attempt to write, ie.:

	sendto( sockfd, buffer, sizeof(buffer), 0, &serv_addr, sizeof(serv_addr)). 

It fails with the error, "message to big". I`ve checked the 
size of the rcv and send buffers -- they're fine. If I change 
the IPPROTO_RAW in the creation to either "_UDP" or "_ICMP", 
then things will work. Problem is, I don't want to use either 
UDP or ICMP. 

I suspect that Sun simply can't (or doesn't want to) support
completely raw IP access. Anyone know the answer to this? I'd
really hate to have to muck around in the kernel to add a 
protocol......

thanks. 
-- 
Steve McDowell             . . . . o o o o o 		Opinions are 
Exlog, Inc.	                  _____      o     	mine, not my 
mcdowell@exlog.com      _____====  ]OO|_n_n__][.    	employers..
		       [_________]_|__|________)<   

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 92 23:31:43 GMT
From:      jbreeden@netcom.com (John Breeden)
To:        comp.protocols.tcp-ip
Subject:   Compuserve gateway


Someone a while back posted an address for an X.25 gateway from the
internet to Compuserve...if anyone knows it. could they email me
the address?

Thanx in advance..........
-- 

 John Robert Breeden, Hughes Lan Systems
          jbreeden@kailua.hls.com, johnb@hls.com, jbreeden@netcom.com

 ------------------- cut here and you'll break your monitor -------------------

      "The nice thing about standards is that you have so many to choose 
      from. If you don't like any of them, you just wait for next year's 
      model."

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 92 00:45:53 GMT
From:      C506634@umcvmb.missouri.edu (Eric Edwards)
To:        comp.protocols.tcp-ip
Subject:   Line terminators and the Telnet Binary option

I'm in the process of writing a Dialin-in/terminal server implimenting the
Telnet prototcol.  Absolute binary transparency (when needed) is a requirement.
 
At the same time little or no configuration changes should be required of the
attached terminal.
 
The trouble is, when the Binary option is enabled, some unix telnet servers
send and expect Linefeeds as line terminators.  This is despite successfully
negotiating Vt100 as the terminal type.  Vt100's naturally send CR and
receive CR/LF.
 
What I need is some way of negotiating with the host as to what line
termintors should be.  Is there a widely accepted Telnet option that will do
this?  I've looked at the End of Record option but that would require that
I (as the terminal server) know when to toggle cr -> EOR translation and
when to turn it off.
 
Alternatively, is it safe to leave it in text mode and expect that the host
will toggle Binary mode when it is needed?  Or am I going to run into hosts
that stay locked in text mode even when the application is transmitting binary?
(I suspect the latter)
 
Any help, pointers to RFC's, etc would be greatly appreciated.
 
Eric Edwards: c506634 @   | "MS-DOS is one of those rare environments where
Inet: umcvmb.missouri.edu |  applications are written around the operating
Bitnet: umcvmb.bitnet     |  system rather than under it."

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 92 04:07:35 GMT
From:      bob@indian.uucp (Robert Crowe)
To:        comp.protocols.tcp-ip
Subject:   Help - PCbridge failing after 3 minutes.

Hello,
I am attempting to use pcbridge (july 91) to bridge a group of PC's on
thin-net to a group of SUN/SGI's on thick-net. The net software consists
of NCSA telnet (v 2.3), and PC-nfs (v 3.0). I have a 386 with two
3c507 cards, and I am attempting to bridge the thick-net from the
tranciever box to the thin-net that the pc's are on. When I first boot
up, the bridge seems to be working just fine, but after about 3
minutes ( or 20K bytes or data transfer ) the connection breaks, and
nothing else gets through.  I have double checked my configuration of
the boards, and it looks correct. My question is this: Is anyone else
out there using a similar configuration? If so have you experienced
any of these problems? Do you have any answers? I really need to get
this connection made, any advice will be appreciated.

Thanks in advance,

--
Bob Crowe,                     Voice:   (619) 931-2695
Pre-Press Technologies.        Email: benton!bob@peregrine.com
2443 Impala dr.
Carlsbad, Ca 92008.

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 1992 04:55:14 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP is not connectionless. Question on UDP protocol.

In article <1992Mar4.225002.13096@freedom.msfc.nasa.gov> mahmood@freedom.msfc.nasa.gov (Rafique Mahmood) writes:
>Question 1. UDP is connectionless, therefore it should not matter
>	   for a client( who is the sender) is there iny receiver
>	   waiting to receive the packets. But surprisingly enough,
>	   I found out it does matter. When there is a receiver, 
>	   sender's rate become almost double. I ran the test on
>	   different machines ( two Decstation 5000/200, Decstation 5000/240,
>	   Sparcstation II, Sun 4/260, Silicon Graphics 4/120 ) and
>	   same results of send rate drops when no receiver. Can anyone
>	   explain what is happening? Is UDP is not completely connectionless.

While the UDP protocol itself is connectionless, some implementations
provide an illusion of connections based on the common way that UDP is
used, specifically for simple query/response protocols.

A particular use of this is to inform the sender whether there's a
receiver.  If you send a UDP datagram to a port for which there's no
receiver, the receiving host must send an ICMP Port Unreachable message.
By blocking the sending process, the sending host can wait for that
response.  If it arrives, the send call can return an error code.  And if a
reply arrives, the server is known to exist, so the send call can return
success.  But if neither arrives, the send call doesn't return until it
times out.

I'm not sure that this is what's happening, but it's a possibility.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 92 05:22:59 GMT
From:      cis4221@gsusgi2.gsu.edu (CIS 830 Student)
To:        comp.protocols.tcp-ip
Subject:   LAN gateway connection to a UNISYS mainframe

This is a request from a graduate student at Georgia State university

We are configuring a small LAN of 20 nodes using IBM Token-ring and Novell Netware 386 v.3.11.  The pc's currently are connected to a remote UNISYS mainframe 
through a MUX and front end processor at the local site.  We would like to replace some of the hardware (emulation cards) and utilize a gateway to the Unisys
through the LAN.      What hardware/software recommendations would you make?
Also what are some of the factors we need to consider in installing the gateway.

Thanks,
Jimmy Ray
ZZ
  

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 92 06:06:26 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP is not connectionless. Question on UDP protocol.

> In article <1992Mar4.225002.13096@freedom.msfc.nasa.gov> mahmood@freedom.msfc.nasa.gov (Rafique Mahmood) writes:
> >Question 1. UDP is connectionless, therefore it should not matter
> >	   for a client( who is the sender) is there iny receiver
> >	   waiting to receive the packets. But surprisingly enough,
> >	   I found out it does matter. When there is a receiver, 
> >	   sender's rate become almost double. I ran the test on
> >	   different machines ( two Decstation 5000/200, Decstation 5000/240,
> >	   Sparcstation II, Sun 4/260, Silicon Graphics 4/120 ) and
> >	   same results of send rate drops when no receiver. Can anyone
> >	   explain what is happening? Is UDP is not completely connectionless.
....


You can see this effect by `ttcp -t -u -s unwittinghost`, where
unwittinghost is not expecting anything on port 5001.

With the machines and TCP/IP implementation I know about (one of those
mentioned above), one of two things will happen:
    1.  if the sender is much faster than the recevier,
	the receiver will craw to a halt.

    2. If the sender is no faster than the receiver, its UDP output
	rate will drop.

In the first case, the receiver kernel will be drowning in packets and
trying to keep up, responding packet-for-packet with ICMP PORTUNREACHABLEs.
The first case can only happen if the speed of the sender as seen by the
receiver through possibly limiting speed of the medium is high.  In other
words, the first case should only occur on modern machines connected by
FDDI or faster media.  It should not occur with ethernet

In the second case, the receiver keeps up with sender, causing the sender
to have process twice as many datagrams, one UDP and one ICMP.  If the
sender is limited by the speed of the medium (e.g. ethernet or slower), the
bandwidth used by the receiver's ICMP's will slow the sender's UDP's.  If
the sender is CPU bound instead of medium limited, the processing of the
ICMP's will slow the UDP's by using CPU cycles.


Vernon Schryver,  vjs@sgi.com

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 92 07:35:50 GMT
From:      adnan@sgtech.UUCP (Adnan Yaqub)
To:        comp.protocols.misc,comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Questions about AT&T's Link Provider Interface (LPI)

Awhile ago someone sent me a copy of the "Guide to the AT&T Link
Provider Interface for V.3".  After looking at this document, I have
some questions.  In the document, it spells out a DL_BIND_ACK message
sent by the LPI provider to the user.  There is also a DL_OK_ACK which
is sent in response to a DL_BIND_REQ.  I am confused about the use of
the DL_BIND_ACK.  Here are my questions:

1) Is this for the times that you do what the LLC spec calls
"duplicate address checking"?

2) If so, is the LPI always supposed to do this checking, or is it
optional?

3) If it is optional, how do you "turn it on" on a DL_BIND_REQ?

4) Also, if one doesn't do "duplicate address checking", does one
still issue the DL_BIND_ACK right after the DL_OK_ACK?

Thanks for your help.
--
Adnan Yaqub (adnan@sgtech.uucp, ...!uunet!abvax!sgtech!adnan)
Star Gate Technologies
29300 Aurora Rd, Solon, OH, 44139, USA, +1 216 349 1860

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 92 18:09:07 GMT
From:      alfonso@mtecv2.mty.itesm.mx
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   Is there problems using forks and dynamic memory?


  I'm worj=king on an IBM/RS-6000 under AIX 3.1.5 I have an application
that stands as a server. There's a client running on a PS/2 communicating with the server using Remote Procedure Calls.

  When my server initializes, it initialize some arrayas in memory using pointers (this arrays are dynamic because their sizes depend on the amount of data there is in the database that the server access (database is in informix OnLine).
  
  Whenever my app gets a request from a client, it forks and the child pro
cess assists the request and return the response to the client. 

  My problem? This have odd results: sometimes the client hangs itself. If a remove the fork from the server I see that the problem diminishes. I checked in the book "Power Programming with RPC" of John Bloomer my algorithm and it's the same that it is suggested in the book, the only difference is the use of dynamic memory.

  Does anybody know if there's a probkem using pointers and forking at the same time?

  Alfonso Trevino

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Mar 1992 18:59:36 GMT
From:      venu@cirrus.com (Venu Nayar)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP free sources?


I am looking for any sources for the TCP-IP protocol stack which are
available in the freeware domain. I do not have ftp access so it would be
great if mail-servers are available.

Thanks,
-- 
Venu Nayar			|		Internet: venu@cirrus.com
Cirrus Logic Inc.		|		(415)-226-2100 X3737
I don't have to take this abuse from you -- I've got hundreds of
people waiting to abuse me.

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 92 19:58:02 GMT
From:      skip@taygeta.oc.nps.navy.mil (Skip Carter)
To:        comp.protocols.tcp-ip
Subject:   Obtaining the header


	Is there a way to obtain the ethernet header from an incoming
	packet ?  This is usually stripped out at a lower level before
	the data itself reaches the application level.


-- 
   Everett (Skip) Carter              Phone:  408-646-3318 FAX: 408-646-2712
   Naval Postgraduate School          INTERNET: skip@taygeta.oc.nps.navy.mil
   Dept. of Oceanography, Code OC/CR  UUCP:     ...!uunet!taygeta!skip
   Monterey, CA. 93943                TELEMAIL: s.carter/omnet

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 92 20:55:12 GMT
From:      art@Cayman.COM (Art Mellor)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP is not connectionless. Question on UDP protocol.


You may see lower performance in sending UDP packets when there is "no
receiver" (if "no receiver" means that there is no machine at the
destination IP address) because the source machine will be ARPing for
the destination address and waiting for a reply on each of a number of
retries before reporting it couldn't send the UDP packet.

This should be tested separately from sending to an existing machine
that has no listener on the destination port.
--


...............................................................................
 Art Mellor       : Cayman Systems Inc,  26 Landsdowne St,  Cambridge, MA 02139
 art@cayman.com   : Phone 617-494-1999  Fax 617-494-5167  AppleLink CAYMAN.TECH


-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 92 21:09:19 GMT
From:      gregor@oit.itd.umich.edu (Gregor Purdy)
To:        comp.protocols.tcp-ip
Subject:   Public Key Encription in IP or TCP layers

Friends--

I saw some earlier posts about encryption, but didn't see anything recent.

I was thinking about how to keep snoopy people from getting sensitive
information by snooping datagrams and/or packets. Clearly, encryption is
a good way (the only way?) to do this. However, it seems there are some
choices as to details. My favorite scenario is:

(i)	Sender (A) knows public key for talking to receiver (B). It knows
	this because it can now, or has in the past, connected to a special
	port (this is TCP layer, yes? -- like telnetting to a port) on
	B to get the public key.
(ii)	Now, A sends its packet to B with a bit on, indicating encryption.
	B recieves it and tries to decrypt it with its private key. If there
	is a problem (i.e. checksums don't match), B might send a packet
	to A with either: Its public key, or just an error.
(iii)	If A wants an encrypted reply, it can flip a bit and also send
	its public key (perhaps it can assume B already knows it or can
	call back for it and save the bandwidth).

This assumes that the private keys are truly kept private. Also, the
encryption and decryption would have to be fast, but the private key
hard to reverse-calculate.

Is this already possible? Is there a group working on it? If not, why
not? It seems like its high time this sort of thing was incorporated
right into the systems we use everyday.

Replies via email are preferred. I will summarize if appropriate.

--Gregor

------------------------------------------------------------------------------
Gregor N. Purdy                                               gregor@umich.edu

greetings! I am a m@tating s_gnatu~e vrrus. Y*u can't resst hel#ing me +pread!
------------------------------------------------------------------------------

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 92 22:01:43 GMT
From:      walvdrk_r@research.ptt.nl
To:        comp.misc,comp.protocols.tcp-ip
Subject:   Re: Checksum coverage references wanted

In article <1992Mar3.204803.19879@hobbit.gandalf.ca>, ez@mentor.gandalf.ca 
(Eugene Zywicki) writes:
 
> 	I am looking for technical references that explain the exact
>    coverage one gets when using a 'checksum' for error detection of
>    packetized information.
> 
> 	Specifically I would like to know what percentage of various 
>    errors can be detected by using a 16 bit checksum over packets up
>    to 256 octets long. RFCs 1071, 1141 and 1146 don't contain that kind
>    of information, but I'm hoping that someone on the net will be able
>    to steer me to the proper reference.

There is a (quite theoretical) article "Optimum Cyclic Redundancy-Check Codes 
with 16-bit Redundancy" by Guy Castagnoli, Juerg Ganz and Patrick Graber in 
IEEE Trans on Communications, Vol. 38 No. 1, Jan. 1990. (p 111-114).

I also remember there is about a paragraph in one of the standard works on Data 
networks by Tannenbaum (sorry, I forgot the precise title) that claims that all 
bit errors with odd numbers are detected, all double bit errors are detected, 
99.something% of the 4-bit errros etc. Also all burst errors with burst length 
up to 16 should be detected.

If you find any other references, please let me know.

-- 
Kees  van der Wal		       e-mail: J.C.vanderWal@research.ptt.nl

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 92 22:20:24 GMT
From:      jgong@.com (John Gong)
To:        comp.protocols.tcp-ip
Subject:   FAQ: Integrating IP, IPX, Appletalk, OSI Addresses

Greetings,  

      I was wondering if some of you network administrators can share your
thoughts on integrating those network address types in one organization.
We have multiple IP network numbers, islands of Appletalk and Novell
networks, will be doing OSI networking in the near future, and would like
to come up with a universal addressing scheme if that is possible.

For instance, do you map IP subnet numbers to Appletalk zones?  Which number
of bits do you deem significant?  Are the fundamental attributes of each
network address convention irreconcilable from one to the other?  

If you came up with naming conventions, that would be of great interest too!


     Thanks,

     John Gong   Oracle Internet Staff

       jgong@us.oracle.com

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 92 22:38:29 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP is not connectionless. Question on UDP protocol.

In article <ART.92Mar5155512@andros.Cayman.COM>, art@Cayman.COM (Art Mellor) writes:
> 
> You may see lower performance in sending UDP packets when there is "no
> receiver" (if "no receiver" means that there is no machine at the
> destination IP address) because the source machine will be ARPing for
> the destination address and waiting for a reply on each of a number of
> retries before reporting it couldn't send the UDP packet.
> 
> This should be tested separately from sending to an existing machine
> that has no listener on the destination port.


This is a good point.  Thanks for pointing it out.

However, in common BSD implementations, this case may be surprisingly
fast.  There is no waiting by the user program for the ARP response.
The next output packet from the user program will simply mfreem() the
previous UDP/IP mbuf-chain and cause yet another ARP request.  The result
is a stream of small broadcast ARP packets instead of large UDP/IP packets,
at least the rate the UDP/IP packets should have been.

My previous message was at least half silly.  In the BSD based system I
claim to know, there is no UDP output flow control, a point I have been at
pains to beat into the ground recently.  This means that any slow down seen
when transmitting to a present but uncooperating host over ethernet is
caused only by processing the ICMP UNREACHABLEs, not by their consumption
of ethernet bandwidth.



Vernon Schryver,  vjs@sgi.com

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Fri, 06 Mar 92 00:37:18 GMT
From:      andrewk@sco.COM (Andrew Knutsen)
To:        comp.protocols.tcp-ip
Subject:   Re: using a one-to-many SLIP connection


andy@uis.com (Andy Edwards) writes:

>I was wondering if there is any way to use SLIP in the following
>environment:
 
>I have a central site (call it A) that has two modems and several remote
>sites (1 through 20) that each have one modem.  I would like to
>set up a dial-up IP network (using SLIP, I guess) so that A could
>call up to two of the remote sites at a time or two remote sites
>could simultaneously call site A.

	There are a few implementations of dial-up SLIP and PPP around
which could be used to set this up.

	When I first read this though, I got a different impression:
only one modem per site, and do real one-to-many SLIP via conference
calling!  Run CSMA/CD!  Aloha(net), and mahalo (good luck)!

	Seriously, it seems feasible...  just consider incoming
data as "carrier", and any incoming data while transmitting means
a collision.  Of course, you'd have to either inhibit forwarding
on all the nodes, or add a link-level address to SLIP/PPP (and ARP for
it).  Could save some money on modems in certain circumstances.

	Does the CSMA/CD bandwidth/delay/packet-length equation
allow this to be efficient with 9600 baud modems and compressed headers? 
What kind of inter-packet delay would be required?

Andrew
-- 
--------
Andrew Knutsen            andrewk@sco.com
Santa Cruz Operation      (408) 425-7222 x7538

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Mar 1992 01:11:16 GMT
From:      fuchs@tsar.princeton.edu (Ira H. Fuchs)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for Apple2?

This request comes from the Princeton Regional Schools:

We need to be able to connect many Apple 2es which have
AppleTalk interface cards, along with Apple IIgs
computers with built-in AppleTalk to the TCP/IP based
Internet.  This is easily done on Macintoshes; Mac TCP,
TCP/Connect II, etc...).  How is this done on Apple II
series machines?

    We have about 75 Apple II series machines which we wish to
allow access to services via our high speed (234kb at
least) connections, and we obviously do not wish to
install 75 modems and a similar number of phone lines. 
Maybe 30-40% might ever be in use at once. VT-100 terminal
emulation would be a good start, Graphics terminal
emulation would be better.     

    Any information will be greatly appreciated!

Thanks for your help

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Mar 1992 04:34:00 GMT
From:      knauer@cs.uiuc.edu (Rob Knauerhase)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for Apple2?

In <1992Mar6.011116.8263@Princeton.EDU> fuchs@tsar.princeton.edu (Ira H. Fuchs) writes:
>This request comes from the Princeton Regional Schools:
>We need to be able to connect many Apple 2es which have
>AppleTalk interface cards, along with Apple IIgs
>computers with built-in AppleTalk to the TCP/IP based
>Internet.  This is easily done on Macintoshes; Mac TCP,
>TCP/Connect II, etc...).  How is this done on Apple II
>series machines?

Apple has demonstrated an Ethernet card for the Apple II line, but has not
announced any release date.  Unfortunately, with the machinations (real
or rumored) that go on at Apple, this product may or may not ever see the
light of day.

One cottage-industry company and several student groups are developing
network software for the II, either using AppleTalk through a Cayman or
Kinetics gateway (I understand you can now ping an Apple IIGS at Caltech)
or through the serial ports with SLIP (serial-line IP).

So if you want it yesterday, you're better off with a terminal concentrator
and modem software on your II's.  In time, better solutions will be
forthcoming.

Rob
--
Rob Knauerhase           University of Illinois at Urbana-Champaign
knauer@cs.uiuc.edu       Dept. of Computer Science, Gigabit Study Group
"There's no place like $FC58!"

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 92 13:35:26 GMT
From:      ehansen@cs.strath.ac.uk (Eivin P Hansen IE89)
To:        comp.protocols.tcp-ip
Subject:   Protocol vs. TYPE field.


	Hi all net-buggers.

I am for my final year project developing a Ethernet monitor.

Problem:
The TYPE field in packet header(2 byte) of DIX Ethernet contain a number 
coresponding to the protocol of the contained data.

Can anybody help me finding whitch numbers confirm to:

	UDP,TCP,IP,PC_TCP,PC_NFS,NETWARE,and other protocols.

	

	EMAIL Prefered!
				Thanks!!!

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Mar 1992 15:08:37 GMT
From:      korsberg@kirk (Ed Korsberg)
To:        comp.protocols.tcp-ip
Subject:   Source code for TCP/IP in Comer book


Does anyone have the sources from the book
"Internetworking with TCP/IP Volume II, Design , Implementation, 
and Internals" by Douglas Comer and David Stevens?

-- 
Ed Korsberg             E-mail: korsberg@aa.ab.com
Allen Bradley Inc.      phone:  313-998-2470
555 Briarwood Circle
Ann Arbor, Mich 48108

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 92 15:09:40 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Raw sockets on SunOs?


 >I attempt to create a raw socket under SunOs4.x with the 
 >following options:
 >
 >	sockfd = socket( AF_INET, SOCK_RAW, IPPROTO_RAW); 
 >
 >It succeeds; until I attempt to write, ie.:
 >
 >	sendto( sockfd, buffer, sizeof(buffer), 0, &serv_addr, sizeof(serv_addr)). 
 >It fails with the error, "message to big". I`ve checked the 
 >size of the rcv and send buffers -- they're fine. If I change 
 >the IPPROTO_RAW in the creation to either "_UDP" or "_ICMP", 
 >then things will work. Problem is, I don't want to use either 
 >UDP or ICMP. 
 >
 >I suspect that Sun simply can't (or doesn't want to) support
 >completely raw IP access. Anyone know the answer to this? I'd

it does work - maybe try
#ifdef SO_SNDBUF
int len = sizeof(buffer);
        setsockopt(sndsock, SOL_SOCKET, SO_SNDBUF, &len, sizeof(len));
#endif SO_SNDBUF

assuming char buffer[tyhing]

if you have buffer *, you're in trubble with sizeof anyhow...

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 92 16:21:03 GMT
From:      grumpy@jpradley.jpr.com (Jeff Markel)
To:        comp.protocols.tcp-ip
Subject:   non-interactive ftp???

I'm looking for a non-interactive ftp client; i.e., I'd like to be able
to have cron run a job in the middle of the night to pick up files from
another system, without any operator intervention or conversely, to have
the source system ship files to a destination at specified times.  My 
impression is that the ftp program itself cannot do this.

I believe such ought to be possible - the ftpd daemon certainly can handle it.

Is there such a beast?  If so, where can I find the source for it?

                                 Thanks...
-- 
                        Jeff Markel
Jeffrey Markel | uucp:     jpradley!argos!markel   | Argos Computer Systems Inc
KD2HN          | internet: grumpy@jpradley.jpr.com | 110 W. 32nd Street 
(212)594-5400  | amprnet:  kd2hn@kd2hn.ampr.org    | New York, NY 10001

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 92 17:33:25 GMT
From:      davids@os-d.isc-br.com (David Schmidt)
To:        comp.unix.internals,comp.protocols.tcp-ip
Subject:   Re: 3-way handshake help needed

kurt@s5000.rsvl.unisys.com (Kurt Matthys x5693) writes:

>salim@tigger.Colorado.EDU (Salim Alam) writes:
 
>>According to Tanenbaum, the following protocol is used:
 
>>        A sends Connection Request (CR) with a seq#=x
 
>>        B receives it and returns a Connection Confirm (CC) with 
>>          seq#=y and ack#=x

Actually, the ack field is the next expected sequence number.  Thus
the ack field above should be x+1 (since the SYN bit is treated as one
byte of data).

>>	A sends an Acknowledgement (ACK) with seq#=x, ack#=y

Again, the ack field should actually be y+1.

>>Now, my questions are:
>>1. What should B do after sending the CC? Should it wait for an
>>   ACK, and keep sending the same CC until it gets an ack for it?
>>   What if the original CR was some old duplicate floating around?
>>2. What should A do after sending an ACK?  How can it know if the
>>   ACK succeeded?

[...]

>1. B should wait for the ACK for the CC. If it is not received in a 
>   reasonable time (i.e. the retransmission timeout), it should resend the
>   CC. After resending it some number of times without receiving an ACK,
>   B should give up. If the CR was an old duplicate, A will send a RST
>   when it receives the CC.
 
>2. After A sends the ACK it can start sending data. It will know if the 
>   ACK got to B if the data is acked and it never receives another CC.
 
>Kurt Matthys
>Unisys Corp.

We've seen a problem here at my site with the three way handshake.  We
have an amiga running SVR4 connected via slip to our network.  Here is
the scenario:

(1)	A sends CR with seq#=x

(2)	A times out and resends CR with seq#=x  (same packet as (1)

(3)	B (amiga) receives first CR and returns CC with seq#=y and
	ack#=x+1

(4)	B receives second CR and returns CC with seq#=y+1 and
	ack#=x+1.  NOTE: I DON'T THINK THIS IS CORRECT.  B SHOULD NOT
	INCREMENT THE STARTING SEQUENCE NUMBER.

(5)	A receives first CR and sends ACK with seq#=x+1, ack#=y+1.

(6)	A receives second CR with SYN bit set, but the sequence number
	is y+1, not y.  A then sends a RESET packet to clear the
	connection.  This is because it is not legal to have a SYN bit
	set except at the start of a connection.

I feel that the behaviour in (3) is wrong.  B should send out an exact
copy of the original CC, without incrementing the sequence number.

I have also seen this behaviour on an SCO Unix box at one of our
remote sites.  I'm not sure which version of SCO is running on that
box.  Connections work fine if the communications line is not too
loaded, but when the line starts getting loaded down we see the second
CR packet, causing the connection to be reset.

Our solution for people connecting to that site is for them to telnet
into another host at the remote site, and then telnet to the SCO
computer (which works since we rarely get retried CR's on a LAN).
--
David Schmidt                Internet:  davids@isc-br.ISC-BR.COM
ISC-Bunker Ramo Corporation  UUCP:      (oliveb!isc-br!davids)
East 22425 Appleway          Phone:     +1 509 927 5479
Liberty Lake, WA  99019

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 92 18:13:11 GMT
From:      terryl@sail.LABS.TEK.COM
To:        comp.misc,comp.protocols.tcp-ip
Subject:   Re: Checksum coverage references wanted

In article <1992Mar5.230143.65529@research.ptt.nl> walvdrk_r@research.ptt.nl writes:
>In article <1992Mar3.204803.19879@hobbit.gandalf.ca>, ez@mentor.gandalf.ca 
>(Eugene Zywicki) writes:
> 
>> 	I am looking for technical references that explain the exact
>>    coverage one gets when using a 'checksum' for error detection of
>>    packetized information.
 
>I also remember there is about a paragraph in one of the standard works on Data 
>networks by Tannenbaum (sorry, I forgot the precise title) that claims that all 
>bit errors with odd numbers are detected, all double bit errors are detected, 
>99.something% of the 4-bit errros etc. Also all burst errors with burst length 
>up to 16 should be detected.


     Probably "Computer Networks", by Tanenbaum. Check out section 4.2 ERROR
DETECTION AND CORRECTION.

     With a 16 bit checksum, such as CRC-16 or CRC-CCITT, one can "...catch
all single and double bit errors, all errors with an odd number of bits, all
burst errors of length 16 or less, 99.997% of 17 bit errors, and 99.998 of 18
bit and longer bursts."

     BTW, it'a just a tad "more" than a paragraph.... (-:

__________________________________________________________
Terry Laskodi		"There's a permanent crease
     of			 in your right and wrong."
Tektronix		Sly and the Family Stone, "Stand!"
__________________________________________________________

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Mar 92 18:35:25 GMT
From:      gibsoni@ee.mcgill.ca ( irwin roger  gibson )
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   using ka9q with ibm PS/2 on token ring net

Hi.  Question:
    I currently have ka9q and all the Clarkson packet drivers.
There is a netware 386 server running 3.11, with the ability to
route tcp/ip packets.  There is a token ring network connected 
to the file server, and it is required to install ka9q on one
of the PS/2s.  

Has anyone attempted anything similar to this?  I would appreciate
a description of any problems you encountered, the packet driver used
(I guess IBMTOKEN.COM ) and perhaps a copy of your autoexec.net.  Also
the autoexec.bat and config.sys if it includes some real special stuff 
that was neccessary.  

	Any help would be appreciated.

Irwin Gibson

gibsoni@ee470.ee.mcgill.ca
Perv@emf.lan.mcgill.ca 

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 92 20:05:38 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Source code for TCP/IP in Comer book


	You can buy the sources through Prentice Hall. I'll send specific
information via mail to anyone who's interested.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 92 20:38:40 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip,comp.unix.internals,comp.bugs.4bsd
Subject:   Re: 3-way handshake help needed

In article <davids.699903205@os-d> davids@os-d.isc-br.com (David Schmidt) writes:
>
>(4)	B receives second CR and returns CC with seq#=y+1 and
>	ack#=x+1.  NOTE: I DON'T THINK THIS IS CORRECT.  B SHOULD NOT
>	INCREMENT THE STARTING SEQUENCE NUMBER.
>

You are quite right.

There are actually two "correct" things that B could do here, either
send the SYN+ACK with seq=y, or just the ACK with seq=y+1.

You know, it seems to me I have heard of this bug before, though I don't
know when.  In any case, it appears to have a long history: as far as I
can tell, it is present in 4.2, 4.3, Tahoe, SUN{whatever.we.have},
and still in the recent Berkeley net-2 distribution.  I assume it is also
found in anything derived from these (i.e., almost every TCP anywhere).

It's a little funny, since the authors took pains to do the right thing
when resending a FIN, as we see in tcp_output():

     * If resending a FIN, be sure not to use a new sequence number.
     */
    if (flags & TH_FIN && tp->t_flags & TF_SENTFIN &&
	tp->snd_nxt == tp->snd_max)
	    tp->snd_nxt--;

Maybe if we all wish real hard, we can get all those TCP maintainers to add
this right after it:

    if (flags & TH_SYN)
	    tp->snd_nxt = tp->iss;

-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 92 21:45:53 GMT
From:      kdb@intercon.com (Kurt D Baumann)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for Apple2?

In article <1992Mar6.011116.8263@Princeton.EDU>, fuchs@tsar.princeton.edu 
(Ira H. Fuchs) writes:
> We need to be able to connect many Apple 2es which have
> AppleTalk interface cards, along with Apple IIgs
> computers with built-in AppleTalk to the TCP/IP based
> Internet.  This is easily done on Macintoshes; Mac TCP,
> TCP/Connect II, etc...).  How is this done on Apple II
> series machines?
> 

I haven't used a Apple II in years.  Though I fondly remember plugging away 
with AppleSoft, and MACE.  Anyway, do you know if the current OS supports 
anything like the ComToolBox?  Is there a TCP/IP stack on the Apple II?


Kurt Baumann                  Creators of fine TCP/IP Products
InterCon Systems            For the Macintosh

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 1992 11:44:05 -0800
From:      jamin@caldera.usc.edu (Sugih Jamin)
To:        comp.protocols.tcp-ip
Subject:   If you have problems printing our tech. report . . .

Hello,

Several people have had problems printing our tech. report
on tcplib announced here a few weeks back.  I have generated
a new postscript file (with an older operating system/device
driver) that should print without problems.  If you had problems
printing our tech. report, you might consider getting the new
version.  Sorry for any inconveniences.  Following is the 
announcement I posted on the availability of the tech. report.

=======================================================================
There is a new version (0.9) of tcplib on jerico.usc.edu 
(128.125.51.6), under ~ftp/pub/jamin/tcplib.

The differences between this version and the previous version are:
    - Two bug fixes.
    - Uniform use of lrand48() in place of random().
    - Addition of telephone (voice) conversation characteristics.
    - Addition of application breakdown characteristics.
    - A more descriptive tech report.  Among other things, the tech
      report shows how to use the traffic application breakdown to 
      derive a simple conversation arrival model.
If you use the old version of tcplib, you want to get the new version 
if just for the bug fixes.  And if you do use tcplib, please send us
your e-mail address to expedite future bug fixes.

Following is the orginal release note of tcplib.  The papers 
[Caceres91] and [Danzig92] cited in the tech report are also available
for anonymous ftp from jerico.usc.edu:~ftp/pub/jamin/traffic. The file
traffic.ps.Z is for [Caceres91] and the files journal.part[1-4].ps.Z 
are for [Danzig92].

=======================================================================
The following technical report and the source library it describes are
available for anonymous ftp from jerico.usc.edu:~ftp/pub/jamin/tcplib.
(Jerico's IP address is 128.125.51.6.) The directory contains the 
following files:

  README
  libtcp_ds31_ultrix41.a.Z
  libtcp_hp90_hpux847.a.Z
  libtcp_sun3_sunos411.a.Z
  libtcp_sun4_sunos411.a.Z
  brkdn_dist.h
  tcpapps.h
  tcplib.1
  tcplib.tar.Z
  tcplibtr.ps.Z

All you need to transfer to use the library are: README, brkdn_dist.h, 
tcpapps.h, tcplib.1, and one of libtcp* that matches your setup.  You
need tcplib.tar.Z only if you must generate the library yourself.  
The file tcplibtr.ps.Z is the PostScript version of the tech. report 
which is introduced below:


    tcplib: A Library of TCP Internetwork Traffic Characteristics

                 Peter B. Danzig       Sugih Jamin

                    Computer Science Department, 
                 University of Southern California,
                 Los Angeles, California 90089-0781

                     traffic@excalibur.usc.edu

                            USC-CS-91-495

1. Introduction
  When simulating computer networks, it is necessary to specify the 
traffic between network nodes.  Typically, simulation studies of 
wide-area tcp/ip networks model traffic as a combination of Poisson 
processes and maximal rate streams--corresponding to telnet traffic 
and large file transfers respectively.  Such traffic models are 
justified when the modeler wants to show, for example, that his flow 
control or gateway scheduling algorithm responds well to worst case 
traffic or when essentially nothing is known about the real network
traffic.  However, such models do not reveal how similarly robust 
algorithms respond to the common case load.
  This paper describes tcplib, a library to help generate realistic 
tcp/ip network traffic.  Tcplib is motivated by our observation that 
present-day wide-area tcp/ip traffic cannot be accurately modeled with 
simple analytical expressions, but instead requires a combination of 
detailed knowledge of the end-user applications responsible for the 
traffic and certain measured probability distributions [Caceres91].  
We collected three-day traces of wide-area Internet traffic at UC 
Berkeley, University of Southern California, and Bell Communications 
Research.  Our study identified that out of more than 35 different 
application programs, ftp, smtp, nntp, vmnet, telnet, and rlogin are
responsible for 96% of wide-area tcp/ip bytes.  Two related studies, 
one at University College London and the other at Lawrence Berkeley 
Laboratory, identified a subset of these six applications as 
responsible for most of their wide-area tcp traffic [Crowcroft91] 
[Paxson91]. Tcplib models five of these six applications.  It excluded 
vmnet, an IBM mail exchange application , because it was absent from 
three of the five traces.  Furthermore, since telnet and rlogin have 
essentially the same characteristics, we have included in tcplib only 
routines describing telnetUs.  Additionally, we included characteristics 
of phone conversations based on the study reported in [Brady65] and a 
distribution of conversations composition breakdown derived from several 
stub-network traces.
-- 
sugih                                              Use email, save a tree.

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Mar 1992 23:30:55 GMT
From:      werme@alliant.com (Ric Werme)
To:        comp.protocols.tcp-ip
Subject:   Re: Can anyone explain this code fragment?

In article <1992Mar3.174614.8983@jarvis.csri.toronto.edu> thomson@hub.toronto.edu (Brian Thomson) writes:
>In article <1992Mar3.200302.13886@alliant.com> werme@alliant.com (Ric Werme) writes:
>>In the 4.3 Tahoe networking code, we have this little routine:
>>
>>sbreserve(sb, cc)
>>	struct sockbuf *sb;
>>	u_long cc;
>>{
>>	if (cc > (u_long)SB_MAX * CLBYTES / (2 * MSIZE + CLBYTES))
>>		return (0);
>>       sb->sb_hiwat = cc;
>>	sb->sb_mbmax = MIN(cc * 2, SB_MAX);
 ...
>>
>>In the BSD-net.2 tape, the if statement becomes:
>>
>>	if (cc > sb_max * MCLBYTES / (MSIZE + MCLBYTES))
>>
 ...
>>
>>
>>2) Just *what* is the intent, anyway?
>
>sb_mbmax is a limit on total memory use, and cannot be greater than SB_MAX.
>sb_hiwat and cc are both limits on the amounts of actual data buffered.

I'm sorry if I wasn't clear.  I understand that stuff, its the expression
in the if statement I find confusing.  Why MSIZE + MCLBYTES, especially
if MCLBYTES == 2048 which means Ethernet input will have no full cluster
buffers!  Why shouldn't I change the code to account for that?

>Now, let me introduce you to this new invention, the "comment".
>The one in the Tahoe code reads, in part:
>
> * Attempt to scale cc so that mbcnt doesn't become limiting
> * if buffering efficiency is near the normal case.

Believe me, I understand comments.  I even write them!  :-)

>>3) How is the BSD-net.2 version "better"?
>
>Well, it has a different estimate of "buffering efficiency in the normal case".
>That may reflect differences elsewhere in the code, but I don't have one
>here so can't check.

Different is better?

Apologies if I sound somewhat annoyed.  While your reply has little new
information, it is the only reply, so please accept my thanks.

I think I'll just conclude that no really understands that if expression,
so I won't worry too much about changing it for some of my experimenting.
-- 
| A pride of lions               | Eric J Werme                   |
| An odd lot of programmers      | uucp: mit-eddie!alliant!werme  |
| A Constitution of Libertarians | Phone: 508-486-1214            |

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 92 02:31:34 GMT
From:      jc@minya.UUCP (John Chambers)
To:        comp.protocols.tcp-ip
Subject:   Re: using a one-to-many SLIP connection

In article <1992Mar06.003718.26599@sco.COM>, andrewk@sco.COM (Andrew Knutsen) writes:
> andy@uis.com (Andy Edwards) writes:
> 
> >I have a central site (call it A) that has two modems and several remote
> >sites (1 through 20) that each have one modem.  I would like to
> >set up a dial-up IP network (using SLIP, I guess) so that A could
> >call up to two of the remote sites at a time or two remote sites
> >could simultaneously call site A.
 
> 	There are a few implementations of dial-up SLIP and PPP around
> which could be used to set this up.
> 
> 	When I first read this though, I got a different impression:
> only one modem per site, and do real one-to-many SLIP via conference
> calling!  Run CSMA/CD!  Aloha(net), and mahalo (good luck)!

But he described a central site with  two  modems.   There  isn't  any
reason  I  know  of  that  a  site  with  N  modems  couldn't  make  N
simultaneous SLIP links. I've done it with N=3 on several DEC machines
at work, and it works fine.  There are some DEC Customer Support sites
that are using SLIP and a bank of modems to connect to customer sites.
(Now if they would just release it as a supported product.  ;-)

The  idea  of  a  conference call is interesting, though.  I wonder if
anyone has ever done SLIP or PPP this way?  Maybe I should give  it  a
try.   Actually, my biggest worry would be which (if any) modems could
handle a conference call.  I'd bet that most of them couldn't.  If any
can, it'd be interesting to hear the model numbers.

-- 
All opinions Copyright (c) 1991 by John Chambers.  Inquire for licensing at:
Home: 1-617-484-6393 ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc 
Work: 1-508-486-5475 {sppip7.lkg.dec.com!jc,ub40::jc}

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 92 08:46:59 GMT
From:      slin@acsu.buffalo.edu (Shueh-Fen Lin)
To:        comp.protocols.tcp-ip
Subject:   Re: Need Zmodem for Sun Sparc

In article <18410@aggie.ucdavis.edu> ckashuba@carnitas.ucdavis.edu (Chris Kashuba) writes:
>I need Zmodem so that I can download files from home. Is there an FTP site somewhere that has this?

I don't really know _where_ is zmodem in the sea of Internet.  However, 
by following the the steps you should be able to find one and get it run
on the SUN:

1. Telnet to 132.206.51.1 or 147.225.1.2 or 129.93.1.14. Those sites
are archie database server ffor Internet.  Use ID'archie' to login, no 
password is needed.

2. At the 'archie' prompt, enter 'prog rzsz'.  The Database server will start
searching for files with 'rzsz' embedded in the names.  BTW, rzsz is
a public domain program featuring Zmodem protocol.  The author is Chug
Forsberg (spelling?)

3. Pick one site from the long listing generated by the database server,then ftpto it.  Use ordinary anonymous ftp to get the source code of rzsz.

4. Compile the program on the machine you are going to use.  (Sparc in
your case).  You should be able to find documentation in the ftp-ed package.

5. Good luck.

slin@acsu.buffalo.edu

BTW, the latest version of rzsz is rzsz9112.

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7 Mar 1992 19:03:44 GMT
From:      sbyrnes@rice.edu (Steven Byrnes)
To:        comp.protocols.tcp-ip
Subject:   Re: non-interactive ftp???

On 6 Mar 92 16:21:03 GMT, Jeff Markel said:

    I'm looking for a non-interactive ftp client; i.e., I'd like to be able
    to have cron run a job in the middle of the night to pick up files from
    another system, without any operator intervention or conversely, to have
    the source system ship files to a destination at specified times.  My 
    impression is that the ftp program itself cannot do this.

Actually, at least under SunOS 4.1.1, one can redirect standard input and
output for the ftp client.  So, for example, the following will work
nicely:

ftp -n ftp.site < foo

where "foo" contains

user anonymous <you>@<yourhost>
binary
get bar/bass

The "-n" option to ftp tells it to not try to do an autologin even if you
have a .netrc file.

Steven

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 92 19:42:39 GMT
From:      josevela@mtecv2.mty.itesm.mx (Jose A. Vela A.)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: using ka9q with ibm PS/2 on token ring net

gibsoni@ee.mcgill.ca ( irwin roger  gibson ) writes:

>Hi.  Question:
 
>Has anyone attempted anything similar to this?  I would appreciate
>a description of any problems you encountered, the packet driver used
>(I guess IBMTOKEN.COM ) and perhaps a copy of your autoexec.net.  Also
>the autoexec.bat and config.sys if it includes some real special stuff 
>that was neccessary.  


 Sure !!! ... and it works very well ..


 sorry but I don't have my autoexec.net on line :-)

 about the config.sys :

  you MUST have device=dxma0mod.sys and dxmc0mod.sys .. this are the IBM 
   Network Support Program for Token-Ring


 If you have troubles, just mail me ...

Bye
 _____________________________________________________________________________
 Jose Angel Vela Avila. 
  Instituto Tecnologico y de Estudios Superiores de Monterrey
    I.T.E.S.M
  Mexico.
  ___               _    ___  _         __
 (   >             ' )  /    //        /  )  josevela@mtecv2.mty.itesm.mx
  __/________    _  (  / _  // __.    /--/   josevela@tecmtyvm.mty.itesm.mx
 / /  (_)  \_)__</_  \/ </_</_(_/|_  /  ( o  josevela@tecmtyvm.BITNET
<_/

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7 Mar 92 20:18:24 GMT
From:      klassen@sol.UVic.CA (Melvin Klassen)
To:        comp.protocols.tcp-ip
Subject:   Re: Need Zmodem for Sun Sparc

In article <*> slin@acsu.buffalo.edu (Shueh-Fen Lin) writes:
>
>1. Telnet to 132.206.51.1 or 147.225.1.2 or 129.93.1.14. Those sites
>are archie database server for Internet.  Use ID 'archie' to login; 
>no password is needed.
>
Please use the Internet names for these hosts, e.g.,
  QUICHE.CS.MCGILL.CA (not QUICHE-TC.CS.MCGILL.CA),
  NIS.ANS.NET,
  ARCHIE.UNL.EDU (not ARCHIE1.UNL.EDU),
and let a name-server resolve them to their current (always subject-to-change)
addresses.

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 92 00:14:26 GMT
From:      devet@wsinis05.info.win.tue.nl (Arjan de Vet)
To:        comp.protocols.tcp-ip
Subject:   Re: non-interactive ftp???

In article <1992Mar06.162103.28699@jpradley.jpr.com> grumpy@jpradley.jpr.com
(Jeff Markel) writes:

>I'm looking for a non-interactive ftp client; i.e., I'd like to be able
>to have cron run a job in the middle of the night to pick up files from
>another system, without any operator intervention or conversely, to have
>the source system ship files to a destination at specified times.  My 
>impression is that the ftp program itself cannot do this.
>
>I believe such ought to be possible - the ftpd daemon certainly can handle it.
>
>Is there such a beast?  If so, where can I find the source for it?

Here's the README file from a PERL package that I wrote (with some libraries
made by others) for non-interactive ftp. If anyone is interested, send me a
request and I will mail it to you.

-----------------------------------------------------------------------------
ftpfiles
--------

A PERL script for fetching files in the background by anonymous ftp. Example:

	ftpfiles ftp.win.tue.nl -r /pub -l $HOME -a README

transfers ftp.win.tue.nl:/pub/README to $HOME/README in ASCII mode. This
commando puts itself in the background and send a log by E-mail. Manual page
available. Help page when ftpfiles.pl is invoked without arguments:

-----------------------------------------------------------------------------
ftpfiles <host> [ -l <path> | -r <path> | -ls<type> | [ [-a|-b] <file> ] ] ...

Usage:
  <host>    : domain name or IP address
  -l <path> : set local directory prefix (default "./")
  -r <path> : set remote directory prefix (default "/")
  -ls<type> : get directory listing; -<type> is passed to the remote /bin/ls
  -a <file> : get file in ascii mode
  -b <file> : get file in binary mode
  <file>    : get file in binary mode (default)

Version:
$Id: ftpfiles.pl,v 0.8 1992/02/28 09:25:38 devet Exp $

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

ftpi
----

A PERL script to extract site:file specifications (e.g.,
ftp.win.tue.nl:/README) from stdin, loads them into an editor for
corrections/selections and invokes ftpfiles. Example usage:

	|ftpi

from within your newsreader when you see a site:file specification.


Bugs
----

Everything is still in early development. Bug reports welcome. I only tested
this on a SUN SPARC (no other machines available here).


Future
------

Future extension:

- queing requests until it is night at the remote site;


Arjan de Vet <devet@win.tue.nl>
Department of Mathematics and Computing Science
Eindhoven University of Technology
the Netherlands

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

-- 
Arjan de Vet -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Eindhoven University of Technology
Internet : devet@win.tue.nl -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- the Netherlands
X.400    : c=nl;admd=400net;prmd=surf;o=tue;ou=win;s=devet -*-*-*-*-*-*-*-*-*

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 92 00:39:38 GMT
From:      henry_flurry@imagine.com (Henry Flurry)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.protocols.nfs,comp.protocols.ibm
Subject:   Suggestions for home automation network

I'm building a house and I want to install a small LAN consisting of  
mixed platforms.  Here's what I'm wanting to do (as I can afford it -  
this is intended to be a many year project).

What one should be able to do at a computer/terminal:
- manual and automatic control of house alarm/lighting/etc.
- access and compose system-wide available documents (ranging from  
letters to grocery lists)
- run different applications used in maintaining a household (from  
spreadsheets, small databases, money programs, etc.)
- Each computer/terminal must run a decent windowing GUI.

Future possibilities if system allows:
- voice control of lighting, etc.
- digital answering machine accessible from anywhere in house
- routing of audio (and video?) throughout house (since house is to be  
wired for at least audio, audio could be multiplexed through computer  
controlled device)
- reading electronic mail/news from any station.

Here's my thinking so far:
- I do my work on NeXT computers, so there will likely be at least one  
NeXT on the LAN
- Other stations could be IBM compatible 286 (12-16MHz) running DOS and  
the GeoWorks windowing system (a neat, lean Windows 3.0 look-a-like that  
runs FAST on slow machines)
- Most of my custom work (lighting/alarm control, etc.) will be coded in  
an interpreted language I will have ported to each of the computer  
platforms on the LAN.  Thus, the code I write will be portable between  
the different implementations of the same interpreter.

Networking needs:
- Each station needs to be able to access the same files (whether I have  
a single server or a peer-to-peer network is undecided)
- I've pretty much decided I need some sort of Remote Procedure Call  
(RPC) capabilities.  This is so that one station, for example, can tell  
another station to turn off/on a particular light.  Cross network pipes  
could be another acceptable solution.
- I'd be happy working with a low bandwidth network and not have the  
digital answering machine capabilities (a high-bandwidth app, I  
imagine).
- The load on the network will never likely be high (unless I start  
dealing with digital multimedia).  Most often, only one person will be  
using it at a time.

Networking Issues:
- The biggest question seems to revolve around RPC's.  I might settle  
for having just PC's send RPC's to other PC's, but I'd also like to have  
the NeXT receive and send RPC's to the PC's.  What PC Networking  
literature I can find does not mention the RPC side of networking at all  
(but, clearly, RPC's are supported at some level of the network in order  
to have client/server apps!).  Since SUN-NFS specification includes  
specs for RPC's, I can't help but wonder if PC implementations of NFS  
support RPC's too.  (NFS looks attractive to me since I can always add  
more Unix machines with little hassle).
- Assuming I find a suitable network supporting RPC's, I'm hoping to not  
have to invest much (if any!) money for developing software supporting  
RPC's.
- Data medium.  Twisted pair?  Coax?  What topology?  I understand that  
I may not have a tremendous amount of freedom in choice depending on  
what networking software I end up using.

Other thoughts:
- I'm also wondering about having one gigantic multiuser 386/486 system  
hooked up to my NeXT, and then having several VGA/keyboard terminals  
hanging off of the 486 (as opposed to having multiple CPU's networked  
together).  Any experience with this?  Cost?
- Networking of peripherals would be nice.

The BIG I$$UE:
- The title says it all.  Ideally, once the wiring is laid down, I'd  
like to keep each PC workstation costing around $500 (286, 20MB hard  
drive, kybd, mono/gray monitor, networking hardware).  My initial  
research indicates I'll be really lucky to keep them down to about $700  
each.

Finally, The (first) big list of questions:
- What networking software out there will do what I want?
- What varieties of NFS software for the PC are there?  How well do they  
work with PC/Unix mixed systems?
- What options are there for PC's using the printer hooked to the NeXT  
and for using peripherals hooked to other PC's?
- For a LAN of this size (5-7 stations, max; just a few initially), what  
topology and medium would you suggest?
- What are some of the cheaper solutions?  What do I absolutely *have*  
to pay in order to get my desired functionality?

Thanks much!
Henry Flurry


P.S. In case any of you are interested in the home automation side of  
things, I'm leaning towards implementing an X-10 solution.  I'm still  
trying to find more info on the Smart House specs, but I suspect that  
(a) smart house stuff is $$$; (b) X-10 solutions are more widely  
available for most of what I'm interested in.  Maybe my next house will  
be a smart house ;).

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 92 02:45:54 GMT
From:      l00017@eeyore.stcloud.msus.edu (Networking Research)
To:        comp.os.mach,comp.protocols.tcp-ip
Subject:   Setting up Mach386 with an SMC Ethercard Elite 16


	I've been trying to set up a 486 ISA machine running Mach386 with
an SMC (former WD) EtherCard Elite 16, and I've been having rather poor
luck.  I'm trying to communicate with a 386 running FTP Software's PCTCP+,
and if I reboot the Mach machine with DOS, and run PCTCP there, everything
works just great.  However, under Mach, the two machines can't seem to find
each other, except for the very, very rare occasion where the PCTCP machine
can get an ARP from the Mach machine (but not the other way around).  I'm
thinking I've seen people talking about problems with setting up the 16 bit
Western Digital cards before, but I seem to remember that it can be resolved.
Anybody out there running one of these things?
	If it matters, heres the specific hardware setup.
Gateway 2000 486/33C Tower with :
Micronics Motherboard with 486/33 64k Cache, 8Megs mem.
FD/IDE/2 Serial/1 Parallel Multi I/O card with all interrupts and mem 
	locations set as standard for com1, com2, lpr0, etc.
Diamond Speedstar+ VGA card with IRQ 2 disabled, otherwise standard.
SMC EtherCard Elite 16 (I've tried it as IRQ 2, mem 280, IRQ 5, mem 300,
	no luck)

	I have the feeling it's a combination of software configuration under
Mach, and hardware settings,in relation to how Mach386 really wants things.

	Also, since I'm here, has anybody got any idea why my parallel port
works find under DOS, but won't work at all under Mach?  I've checked and
rechecked the IRQ settings and mem locations, with no luck at all.

	I'd bug Mt. Xinu about these things, but my ethernet card and other
stuff didn't get delivered until after the 30 day installation support was
out.

Mark Holden
l00017@eeyore.stcloud.msus.edu

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 92 15:43:50 GMT
From:      jds@cs.umd.edu (James da Silva)
To:        comp.os.mach,comp.protocols.tcp-ip
Subject:   Re: Setting up Mach386 with an SMC Ethercard Elite 16

l00017@eeyore.stcloud.msus.edu (Networking Research) writes:
>	I've been trying to set up a 486 ISA machine running Mach386 with
>an SMC (former WD) EtherCard Elite 16, and I've been having rather poor
>luck.  I'm trying to communicate with a 386 running FTP Software's PCTCP+,
>and if I reboot the Mach machine with DOS, and run PCTCP there, everything
>works just great.  However, under Mach, the two machines can't seem to find
>each other, except for the very, very rare occasion where the PCTCP machine
>can get an ARP from the Mach machine (but not the other way around).  I'm
>thinking I've seen people talking about problems with setting up the 16 bit
>Western Digital cards before, but I seem to remember that it can be resolved.
>Anybody out there running one of these things?
>	If it matters, heres the specific hardware setup.
 ...
>SMC EtherCard Elite 16 (I've tried it as IRQ 2, mem 280, IRQ 5, mem 300,
>	no luck)

(By mem I presume you mean port address.  What was your memory base address
set to?)

We had very similar symptoms on a 486/33 here.  We solved them by modifying
the EtherCard's setup (via its DOS diagnose program) to match what Mach
wanted.  From the Mach "i386_install.doc":

	II.2.1. WD8003 & WD8013
	  We can accept:
                port            irq             memory
                0x280           9               0xd0000
                0x2A0           9               0xd0000
                0x2E0           5               0xd0000
                0x300           5               0xd0000

(there's a lot more about the WD cards in this document, too)

I think we settled on (0x2e0,5,0xd0000) but right now I don't recall for
sure.

Jaime
............................................................................
: Stand on my shoulders, : jds@cs.umd.edu  :		      James da Silva
: not on my toes.	 : uunet!mimsy!jds : Systems Design & Analysis Group

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Mon, 09 Mar 92 17:18:59 GMT
From:      thf@zelator.in-berlin.de (Thomas Funke)
To:        comp.protocols.tcp-ip
Subject:   Re: Source code for TCP/IP in Comer book

In <1992Mar6.150837.27998@icd.ab.com> korsberg@kirk (Ed Korsberg) writes:


>Does anyone have the sources from the book
>"Internetworking with TCP/IP Volume II, Design , Implementation, 
>and Internals" by Douglas Comer and David Stevens?

Is that book even better than the famous 'Unix Network programming'
by W.R. Stevens ??

Any comments ?


-- 
-----------------------------------------------------------------------
Thomas Funke, Gasteinerstr. 29, 1000 Berlin 31, Germany, +49-30-8618224  
** Registered NeXT Developer **
E-mail:  thf@zelator.in-berlin.de
-----------------------------------------------------------------------

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 92 19:29:47 GMT
From:      sss@netcom.com (Small Systems Solutions)
To:        comp.protocols.tcp-ip
Subject:   Re: Source code for TCP/IP in Comer book

In article <WH7Z2XS@zelator.in-berlin.de> 
	 thf@zelator.in-berlin.de (Thomas Funke) writes:
>
>>Does anyone have the sources from the book
>>"Internetworking with TCP/IP Volume II, Design , Implementation, 
>>and Internals" by Douglas Comer and David Stevens?
>
>Is that book even better than the famous 'Unix Network programming'
>by W.R. Stevens ??

Different in scope. Buy both. Rich Stevens's book deals specifically
with TCP/UDP and standard programs built on these -- in the UNIX
environment.  Comer's books are the classics on the protocols themselves.

-- 

Small Systems Solutions
1563 Solano Avenue, Suite 123
Berkeley, CA 94707-2116                           sss@netcom.com

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Monday, 9 Mar 1992 18:13:02 TUR
From:      <C55969@TRMETU.BITNET>
To:        comp.dcom.lans.fddi,comp.dcom.lans.misc,comp.protocols.tcp-ip
Subject:   asynchronous transfer mode


Hi out there;

I am seeking some information regarding ATM (asynchronous transfer mode)
of what so ever. I will be glad if anybody out there could send me files
related to the subject or tell me where, and how I can get them.

best regards & thanks in advance
k1

P.S. I would prefer if you could send your responses directly to me at
C55969@TRMETU.BITNET and save me from searching all the news groups, as
I have sent this mail to more than one list

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 92 20:15:51 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: Can anyone explain this code fragment?

In article <1992Mar6.233055.25860@alliant.com> werme@alliant.com (Ric Werme) writes:
>In article <1992Mar3.174614.8983@jarvis.csri.toronto.edu> thomson@hub.toronto.edu (Brian Thomson) writes:
 [ something shamefully snooty ]
>
>Apologies if I sound somewhat annoyed.  While your reply has little new
>information, it is the only reply, so please accept my thanks.
>
>I think I'll just conclude that no really understands that if expression,
>so I won't worry too much about changing it for some of my experimenting.

Sorry about the condescension.  Let me try again.

First, the queues whose size is being regulated are socket level queues,
so the character counts involved do not include any protocol headers.
But, they may include a source address record in the case of, eg., the
receive queue of a UDP socket.  Those records typically consume an mbuf
that may not be merged with following ones. Also, there may be empty space
in an mbuf or cluster where the headers used to be, and that can contribute
to the overhead, too.

In addition, as you pointed out earlier, the mbuf that points to the cluster
is also overhead.

Consider, too, how data is added to these queues by sbappend*().
There is compression by copying of data in partially-filled mbufs,
but only within a single record (if record-oriented), only within a
single type of mbuf (so the socketname and rights mbufs are not merged
with adjacent data - hmm, I already said this two paragraphs ago!).
In Tahoe, it is also necessary that both the source and destination of
the copy are regular mbufs rather than clusters.
In bsd-2, data can be moved into a regular mbuf from a following
regular mbuf *or* cluster.

Next, consider fragmentation caused by the allocation strategy.
The older VAX drivers used if_ubaget to fetch received packets, which
allocated clusters if they would be at least half full, otherwise used
ordinary mbufs.  This was more-or-less the rule in Tahoe, too.
Bsd-2 (I found one, after all!) introduces something called "MINCLSIZE",
basically equal to the amount of data that two ordinary mbufs can hold,
so roughly 200 bytes.  Anything bigger than that gets a cluster.

Now, I have a hunch that the receive queue is going to be the troublemaker,
so let's concentrate on that.
The buffering efficiency there can be almost arbitrarily poor, if we consider
the reception of short UDP packets, because each input record consumes
at least two mbufs no matter how little data it contains.
So, let's restrict ourselves to the high-volume TCP input case.
Arriving segments are limited in data size to the negotiated MSS for
the connection, which both systems (tahoe and bsd-2) try to set to an
integral number of clusters for local connections, but to 512 bytes for
a non-local one.

In Tahoe:
On a local connection, without the trailer encapsulation, we get a full
cluster to hold the interface pointer, TCP+IP headers, and the first
part of the segment data, plus an extra mbuf for the last bit of data
(equal in size to the extra stuff at the beginning).
Those headers are removed later, but since they come out of the
cluster rather than the mbuf, nothing really gets freed up (Trailers
would change this).  So, the socket queue is a sequence of cluster/mbuf
pairs, each pair holding one MCLBYTES worth of data. 
Efficiency = MCLBYTES/(2*MSIZE + MCLBYTES).

If it is a non-local connection, a 512 byte segment will still cause
a cluster to be allocated (assuming 1024 cluster size), but no accompanying
regular mbuf is needed.  sbcompress will not touch clusters, so
efficiency =  512 / (MSIZE + MCLBYTES).
If clusters are larger than 1024, you will not allocate them, but in that
case sbcompress will compress the chain of ordinary mbufs to get a pretty
good efficiency.

In bsd-2:
Hmm, the interface pointer is handled a little differently, and the minimum
packet length for cluster allocation is lower, but I don't think either
of these make any difference.  It may be that the authors assumed their
change to sbcompress would eliminate the mbufs between clusters in the
local connection case, but it doesn't.

For non-local connections, efficiency actually drops because the threshold
for cluster allocation is only ~200 bytes instead of CLSIZE/2.
However, remember that this sb_max buffer size limit is only likely to be
challenged for very high volume, hence almost certainly local, connections.


There, I hope this is more useful than the last time!
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 92 20:42:31 GMT
From:      peyotr@dobra!UUCP
To:        comp.protocols.tcp-ip
Subject:   send() and non-blocking sockets question

If a non-blocking socket is used in send(), is it OK to return 0
instead of -1 and setting errno to EWOULDBLOCK ? I noticed that
sometimes I get -1/EWOULDBLOCK and sometimes 0 as a return value
from send. Under what circumstances which one would be returned ?

Peyotr Spivakoff

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9 Mar 1992 21:59:46 GMT
From:      walt@unhsst.unh.edu (Walter R. Trachim)
To:        comp.protocols.tcp-ip
Subject:   Re: Source code for TCP/IP in Comer book

In article <WH7Z2XS@zelator.in-berlin.de> thf@zelator.in-berlin.de (Thomas Funke) writes:
>In <1992Mar6.150837.27998@icd.ab.com> korsberg@kirk (Ed Korsberg) writes:
>
>
>>Does anyone have the sources from the book
>>"Internetworking with TCP/IP Volume II, Design , Implementation, 
>>and Internals" by Douglas Comer and David Stevens?
>
>Is that book even better than the famous 'Unix Network programming'
>by W.R. Stevens ??
>
>Any comments ?

I own both - from what I can tell, they pretty much cover any situation very
thoroughly. They're both very good in terms of showing examples of specific
applications, Comer with a fine example of implementing an SNMP client, and 
Stevens with things like PING (which I was able to find in various locations,
thanks to some of you fine net.folks out there) and a good reference on the 
Berkeley socket calls. Overall, I'd recommend both books; for the
cost of dinner for four at a moderately priced restaurant, you could have a
solid resource of information which will probably be viable for a number of
years.

W

-- 
Walter R. Trachim          "The Nethawk"       Net: walt@unhsst.unh.edu
Telecommunications and Network Services        Voice: (603) 862-4742    
University of New Hampshire                    Fax:   (603) 862-2030
Durham, NH 03824                               Local DECnet: UNHH::W_TRACHIM

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 92 23:39:33 GMT
From:      tep@tots.Logicon.COM (Tom Perrine)
To:        comp.protocols.tcp-ip
Subject:   non-connected LANs to share a domain??

Help!

I am having difficulties figuring out how to handle two non-connected
networks that wish to be part of the same domain.

In San Diego, I have a small internet of five or so Ethernet LANs, all
runnning a subnetted class-B network.  This internet is connected to
"The Known Net" only via a UUCP link for mail.  This net is currently
home to the domain "LOGICON.COM".  There are three machines at other
companies and organizations that are providing domain name service for
us.  UCSD.EDU is MXing for us.

This has been working for years, no problem (except that I sorely miss
Internet anonymous FTP!!)

Today, a system manager at a new site in our company called and asked
be to "hook him up".  He has a small LAN in Reston VA, and will be
physically connected via a router to an Ethernet at a government site
that is on the unclassified DDN (MILNET).

Unfortunately, it is not fiscally or politically feasible to actually
directly connect these two sites, at this time.

What we want to do is:
    1. assign one of the subnets of the class-B network for the Reston
    LAN

    2. Make a new subdomain, RESTON.LOGICON.COM.

    3. Have all DNS queries referring to *.RESTON.LOGICON.COM return
    the proper IP addresses for those systems (which will be on the
    Internet)
    AND
    have all DNS queries that are for not-RESTON.LOGICON.COM continue
    to point to our MXer.

I think that this can be done by:
    1. Having the core gateways advertise a route to the assigned
    class-B subnet for the Reston LAN.

    2. Adding a record with RESTON.LOGICON.COM to the existing
    *.LOGICON.COM in the BIND servers at the sites that are handling
    DNS for us.

Is this the way to make this work?  Since the DNS claims that
"domains" are completely independent from network numbers, this kind
of thing must happen all the time.

Is there a better way to make it work?

Tom E. Perrine (tep)     | tep@tots.Logicon.COM  |Voice: +1 619 597 7221
Logicon, Inc.            | sun!suntan!tots!tep   |  or : +1 619 455 1330
4010 Sorrento Valley Blvd|                       |  FAX: +1 619 552 0729
San Diego CA 92121-1498  |Galt's Gulch - If you build it, they will come...

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Mar 1992 04:55:07 GMT
From:      miw@brolga.cc.uq.oz.au (Mark I. Williams)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   TCP Implementation on an Ethernet card

It is now some time since the "smart card" vs. "dumb card" debate has
been aired, and I was wondering what the state of the art in "smart"
ethernet cards is.

I have an application whereI need to transmit data at a rate of about
1.5-2 Mbit/sec over ethernet, preferably using a reliable transport
protocol such as TP4/CLNP, TCP/IP, or even XTP. The data stream will be
produced by a card sitting in a workstation that may be as slow as an
IBM PC/AT, so obviously it is unlikely that the workstation will handle
these speeds very well in software.

It seems to me that there *might* be TCP-bearing ethernet cards that fit
the bill out there. *Is* anybody making an ethernet card with:

* On-board TCP/IP (or even UDP/IP)
* 1.5-2MBPS performance
* A DMA data transfer interface.

If any lateral thinkers out there have other solutions, I'd love to hear
them, of course!

cheers, and thanks!


--
Mark Williams         The University of Queensland       miw@cc.uq.oz.au
+61 7 36 54012   (w)  Prentice Centre
+61 7 36 54477  (fax) Qld 4072  Australia
Si fractus illabatur orbis impavidium ferient ruinae.  -- Horace

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Mar 92 07:04:57 GMT
From:      donkey@lion.kaist.ac.kr (Taekeun Park)
To:        comp.protocols.tcp-ip
Subject:   Q: TCP/IP Sublayer Interface Problem (help!)

Please help me!
I want to replace new network interface module in 
SUN system.
But, I don't know about adding new network hardware
driver to SUN UNIX system.
For example, I want to add RS232-C or
another loop-back pseudodriver under TCP/IP. 
And I make users regard RS232-C as very slow ethernet.
Please give me all informations about that!

Sincerely

			donkey@csd.postech.ac.kr
			

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 92 08:13:15 GMT
From:      frank@tubkom.prz.tu-berlin.de (Frank Ruge)
To:        comp.protocols.tcp-ip
Subject:   PC based Bridge software

Does anyone knows of PC based bridge software which works with
packet drivers ?

Any hints welcome!

Frank
-- 
--- Tel: +49 30 31421172, Inet: ruge@prz.tu-berlin.de, Fax: +49 30 31421112 ---
------ FSP-PV, Sekr. MA073, Strasse des 17. Juni 136, W-1000 Berlin 12 --------

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 92 12:31:17 GMT
From:      atkinson@cmf.nrl.navy.mil (Randall Atkinson)
To:        comp.dcom.lans.misc,comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: TCP Implementation on an Ethernet card

In article <miw.700203307@brolga> miw@brolga.cc.uq.oz.au (Mark I. Williams) writes:
>I have an application whereI need to transmit data at a rate of about
>1.5-2 Mbit/sec over ethernet, preferably using a reliable transport
>protocol such as TP4/CLNP, TCP/IP, or even XTP. The data stream will be
>produced by a card sitting in a workstation that may be as slow as an
>IBM PC/AT, so obviously it is unlikely that the workstation will handle
>these speeds very well in software.

  Protocol Engines, Inc. (PEI) is fabricating a chipset that will
implement significant support for TCP, UDP, IP, and XTP in hardware.
The chipset is the "PE-1000 Series Protocol Engine Chipset".  This
could be used on a smart Ethernet card once the chips become
available, though I think one would really need to be using FDDI or
ATM to take full advantage of these chipsets.

  PEI is also planning to sell an FDDI board for VME (SunOS, SGI, BSD
4.4 drivers) that would be an integrated solution.  I'm pretty sure
that other chipset vendors like NSC or AMD are also seriously
considering making such chipsets.  In general, I think this is a good
thing.

  I have no vested interest in PEI, though I do have a lot of technical
interest in using XTP for real-time applications...

Ran
atkinson@itd.nrl.navy.mil
DISCLAIMER: Views belong to the author, not necessarily his employer.

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Mar 92 14:20:54 GMT
From:      mcdowell@exlog.com (Steve McDowell)
To:        comp.protocols.tcp-ip
Subject:   Re: Source code for TCP/IP in Comer book

In <1992Mar6.150837.27998@icd.ab.com> korsberg@kirk (Ed Korsberg) writes:
>Does anyone have the sources from the book
>"Internetworking with TCP/IP Volume II, Design , Implementation, 
>and Internals" by Douglas Comer and David Stevens?
>
>>Is that book even better than the famous 'Unix Network programming'
>>by W.R. Stevens ??

Apples and oranges. 'Unix Network programming' shows you how to use the
network from Unix.....Comer's book shows you how to give the network to
the operating system -- the actual implementation.

-- 
Steve McDowell             . . . . o o o o o 		Opinions are 
Exlog, Inc.	                  _____      o     	mine, not my 
mcdowell@exlog.com      _____====  ]OO|_n_n__][.    	employers..
		       [_________]_|__|________)<   

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 92 15:00:20 GMT
From:      bill@falcon.cs.uofs.edu (Bill Gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Using a Spider Probe

A couple of quick questions.

Is anyone from Spider Systems reading this??

Is there anyone who can tell me how to query a Spider Probe from something
other than the Spider analyzer??  I wish to automate the collection of 
statistics on our network.  Right now, it looks like the only way to gather 
statistics is manually.  The boxes apparently talk TCPIP, so there must be a
way for my HP Workstation to go out and collect all the info for me.

Can anyone shed any light on this??

bill

-- 

     Bill Gunshannon          |        If this statement wasn't here,
     bill@platypus.uofs.edu   |  This space would be left intentionally blank
     bill@tuatara.uofs.edu    |         #include <std.disclaimer.h>   

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Mar 1992 16:22:32 GMT
From:      peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: TCP Implementation on an Ethernet card

miw@brolga.cc.uq.oz.au (Mark I. Williams) writes:

>It is now some time since the "smart card" vs. "dumb card" debate has
>been aired, and I was wondering what the state of the art in "smart"
>ethernet cards is.
 
>I have an application whereI need to transmit data at a rate of about
>1.5-2 Mbit/sec over ethernet, preferably using a reliable transport
>protocol such as TP4/CLNP, TCP/IP, or even XTP. The data stream will be
>produced by a card sitting in a workstation that may be as slow as an
>IBM PC/AT, so obviously it is unlikely that the workstation will handle
>these speeds very well in software.

I wouldn't be so fast to say that it is "obviously unlikely" that a
PC-AT could achieve such speeds. The chief bottlenecks are going to be
the slow copy over the bus, and the checksumming operation, at least for
a good TCP implementation. A smart card can't do anything about the bus
speed, and the smaller processor normally found in such cards hurts you
on the checksum speed.

In order for a smart card to be faster than the main processor, it has
to be faster. It's a pretty fundamental tautology, but it's amazing how
many otherwise quite intelligent people miss this one, and with a Spinal 
Tap-like mentality ("but it goes to 11...") insist that smart cards have 
to be faster just because they're "smart". 

[note that if you have a heavy-duty OS on the main processor, a slightly
slower CPU on the card with a lighter-weight OS could be "faster"; 
however, DOS isn't heavy-duty by any stretch of the imagination]

Consider that Madge Networks, besides helping advance technology by
overturning the Soderblum patent, has developed a very fast Token Ring
interface by getting rid of the LLC code in the "smart" adapter and
running optimized code on the PC host. (see Data Communications review
of Token ring bridges, last fall)

However, none of this does much to help you find a high-speed TCP
implementation. Does anyone out there have benchmark data for any of the
available packages, like FTP's? 

				Peter Desnoyers
-- 

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1992 16:45:36 GMT
From:      russell@krakatoa.jsc.nasa.gov (Russell Sellers [GHG])
To:        comp.protocols.tcp-ip
Subject:   ftp mnemonics


 I have found that on all the systems I have ftped to that when a
command is complete a three digit code is returned followed by a
Diagnostic message for example:

530 Login incorrect.

Is this standard?? Are there any systems that don't implement this code??
Or do some systems use different codes???

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Mar 92 17:52:49 GMT
From:      thall@isis.cs.du.edu (Tim C. Hall)
To:        comp.sys.att,comp.unix.admin,comp.protocols.tcp-ip
Subject:   SUMMARY:  Internet Firewalling on an AT&T 3B2


The following article was posted to comp.sys.att, comp.unix.admin, and
comp.protocols.tcp-ip:

-------------------------------------------------------------------------------
We are currently looking at firewalling our network from Internet.  Here is our
configuration:

                                     Various Other Machines
                                                 \
   _______            ________                    \  ________      ________
  /       \          /        \                    \/        \    /        \
  |Local  |__________|Gateway |_____________________|Concen- |____|Internet|
  |Network|  802.3   | Host   | 19.2K leased line   | trator |    |        |
  \_______/          \________/    running X.25    /\________/    \________/
                                                  / 
                                                 /
                                      Various Other Machines

Our gateway host is an AT&T 3B2/600G running Unix System V R3.2.3 and 3.2 of
Wollongong TCP/IP.  A standard NI card is used to interface with the
local network, and a SPSC (Special Purpose Synchronous Controller) card is
used for the leased line.  The version of the SPSC software is 3.1 Patch 1.0.  

We want to configure our gateway host to not forward certain incoming packets
from Internet to our local network.  The packets we wish to reject have the
following port numbers:
	23 (telnet)
	25 (SMTP email)
	21 (FTP)

However, outgoing packets with these port numbers from our local network 
to Internet must still be allowed through.  If you or someone you know
has successfully implemented this type of packet filtering on a 3B2, I
would love to hear from you.  My e-mail address is thall@nyx.cs.du.edu.
Thanks in advance.

Tim C. Hall
thall@nyx.cs.du.edu
--------------------------------------------------------------------------
A summary of replies: 

From: Huy Nguyen (hpn@regentdb.uoknor.edu):

A more round-about way of doing this is to port 'inetd' and replace it for
tcplisten.  Then get the 'tcp_wrapper' program from cert.sei.cmu.edu.  This
program (tcp_wrapper) let's you deny or allow certain hosts to connect to
whatever service you want.  It also logs connections (I find that by just 
reading the logs, I can allow most of the internet to connect and disallow
the few that try to crack in.)
--------------------------------------------------------------------------

From: Andy Sherman (andys@ulysses.att.com):

Go find Bill Cheswick's Usenix papers on secure internet
gateways.  His gateway does *not* do packet filtering.  It does not
forward packets at the IP level in either direction.  All functions
are done at the application layer through a proxy service to connect
from the inside to the outside.  (Nothing goes past the gateway in the
other direction.  All inbound mail gets MX'd to the gateway).
--------------------------------------------------------------------------

From: Dave Dorosz (dorosz@plh.af.mil):

The solution to your problem is to modify the server process on your 
gateway host so you do not run the smtp , ftp or telnet servers.
if you are not running named or egp or gated on this host, you
could just disable the server process alltogether.  Disabling all
or part of the server process will allow outgoing traffic but will not 
allow smtp, ftp or telnet connections since your host will have no
server to accept them.  Users who try to telnet for example will
get a "host connection refused" i your telnet server is not running. 
_______________________________________________________________________________

From:  Marc E. Fiuczynski (mef@klinzhai.rutgers.edu) 

You will want to read the Secure_Internet_Gateway.ps file on
research.att.com in /dist.  The author of the package was attempting
to get a software release through the proper channels at AT&T, but I
don't know what the status is.  
_______________________________________________________________________________

From: Alan Cox (iiitac@pyramid.swansea.ac.uk)

There are three easy to approach this, in fact make it 4

1) Make your 3B2 do the filtering. I don't believe it can but it may be able to
2) Can you get the gateway at the other end of the x25 link to do it ?
3) Buy an IBM PC and two ethernet cards to stand between your 3B2 and
the rest of your net. A 286 should do it fine. Then install one of the
various packages like NOS, and hack its ip forwarding code to do what
you want (its free and comes with source).
4) If your programs are accessible enough there are several wrapper
programs for ftpd/telnetd/smtpd tc that have been published at different
times. They involve adding an extra program which looks at the address
of a connection and acts accordingly before passing on into the
supplied executables. I don't know how well that works with the 3B2 but
its not hard with BSD for example.
_______________________________________________________________________________
Conclusions:

Several suggestions were made to tamper with the tcp listener in various
ways, but we would have to do this on every host behind our host gateway
for it to be effective.  We would prefer to control the routing on the
host gateway so that the packets never reach hosts on our side of
the gateway.  This would give us a nice, centralized approach to packet
filtering.  But our 3B2 can only be set to blindly forward packets
between our local network and Internet with the tools we have now.

However after reading the Secure_Internet_Gateway.ps document available
from research.att.com, I will be in touch with AT&T to see if the
procedures and software described are available.  If not, we will soon be
upgrading from our Internet 19.2K line to a fiber link, which will be plugged
into a dedicated router which does the packet filtering we want to do
anyway.  A hearty thanks to all who responded.  Cheers!

Tim C. Hall
thall@nyx.cs.du.edu

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 92 19:14:07 GMT
From:      brunner@practic.com (Thomas Eric Brunner)
To:        comp.protocols.tcp-ip
Subject:   Re: non-interactive ftp???


while you can redirect file descriptors and use either your .netrc or
a perl script, you might also consider using expect/tcl as a mechanism
for generating canned interactive scripts... you can use the same tools
for ftp as well as telnet. see your nearest archive for tcl and expect,
which now go by the name of tk.

a tip o' the scripted hat to don libes and john osterhout

-- 
#include <std/disclaimer.h>
Eric Brunner 4bsd/RT Project
uucp: uunet!practic!brunner or brunner@practic.com
trying to understand multiprocessing is like having bees live inside your head.

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Mar 92 22:25:25 GMT
From:      rees@pisa.citi.umich.edu (Jim Rees)
To:        comp.os.mach,comp.protocols.tcp-ip
Subject:   Re: Setting up Mach386 with an SMC Ethercard Elite 16

In article <1992Mar8.204555.239@msus1.msus.edu>, l00017@eeyore.stcloud.msus.edu (Networking Research) writes:

  	I've been trying to set up a 486 ISA machine running Mach386 with
  an SMC (former WD) EtherCard Elite 16, and I've been having rather poor
  luck.

The necessary patches have been posted here before, but I don't know if
they've made it back into the CMU sources.  The Elite is almost like the
older WD boards, but returns a different ID, so the interrupt doesn't get
enabled.  And the "soft" defaults are different from what Mach expects.
You can fix this with the WD configuration program, or you can fix it in the
driver.

I've heard reports of people getting the Elite to work without these
patches, but I haven't been able to do that myself.

Anyway, here are the patches we've been using.  These originally came from a
kind soul at Columbia, who should receive proper credit but I don't know if
he wants his name spread around or not.  These are for the old 2.5 "sys"
kernel but should also apply to the new "kernel" kernel too.  I don't know
about 3.0 or Mt Xinu.

diff -c sys/i386at/autoconf.c ./autoconf.c
*** sys/i386at/autoconf.c	Fri Jan 11 08:29:24 1991
--- ./autoconf.c	Tue Jul 16 13:10:04 1991
***************
*** 212,217 ****
--- 212,220 ----
  #endif NPC586 > 0
  
  #if NNS8390 > 0
+ /* for EtherCardPLUS Elite "SOFT" defaults */
+ 	{ &ns8390driver, 0, 0, 0, 0, (caddr_t)0x240, SPL6, 9, 0, 0, ns8390intrs,
+ 				      (caddr_t)0x0ce000, 0x2000, 0,  0, 0},
  	{ &ns8390driver, 0, 0, 0, 0, (caddr_t)0x280, SPL6, 9, 0, 0, ns8390intrs,
  				      (caddr_t)0x0d0000, 0x2000, 0,  0, 0},
  	{ &ns8390driver, 0, 0, 0, 0, (caddr_t)0x2A0, SPL6, 9, 0, 0, ns8390intrs,
diff -c sys/i386at/if_ns8390.c ./if_ns8390.c
*** sys/i386at/if_ns8390.c	Wed Jan 30 08:49:23 1991
--- ./if_ns8390.c	Tue Jul 16 13:12:19 1991
***************
*** 1838,1843 ****
--- 1838,1844 ----
  			board_id |= RAM_SIZE_8K;
  		}
  	}
+ 	printf("wd80xxget_board_id: board id = %x\n", board_id);
  	if ((board_id & WD8003EB) == WD8003EB) {
  		/* program the WD83C583 EEPROM registers */
  		if (ram_flag)
***************
*** 1862,1867 ****
--- 1863,1879 ----
  			printf("%s%d wd80xx_get_board_id(): Could not set WD8003EB Interrupt Request Register according to pic(%d).\n",
  				ns8390_softc[unit].card, unit,
  				ns8390info[unit]->dev_pic);
+ 		}
+ 	} else if (board_id == WD8003EP) {
+ 		printf("wd80xx_get_board_id: trying to enable interrupt on 8003EP\n");
+ 		switch(ns8390info[unit]->dev_pic) {
+ 			/* attempt to set interrupt according to assigned pic */
+ 		case 2:
+ 		case 9:
+ 			outb(hdwbase+IRR, IEN);
+ 			break;
+ 		default:
+ 			printf("wd80xx_get_board_id: unsupported PIC value for WD8003EP\n");
  		}
  	}
  	return (board_id);
diff -c sys/i386at/if_wd8003.h ./if_wd8003.h
*** sys/i386at/if_wd8003.h	Fri Jan 11 08:55:59 1991
--- ./if_wd8003.h	Tue Jul 16 13:13:05 1991
***************
*** 230,235 ****
--- 230,236 ----
  #define	WD8013EBT	(ETHERNET_MEDIA | BOARD_16BIT)
  #define	WD8013EB	(ETHERNET_MEDIA | BOARD_16BIT | INTERFACE_CHIP)
  #define	WD8023E		(ETHERNET_MEDIA | INTELLIGENT | INTERFACE_CHIP)
+ #define	WD8003EP	(ETHERNET_MEDIA | RAM_SIZE_8K)
  
  #define BID_SIXTEEN_BIT_BIT  0x01
  

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Mar 1992 22:28:22 GMT
From:      miw@brolga.cc.uq.oz.au (Mark I. Williams)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: TCP Implementation on an Ethernet card

peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:

>miw@brolga.cc.uq.oz.au (Mark I. Williams) writes:
 
>>I have an application whereI need to transmit data at a rate of about
>>1.5-2 Mbit/sec over ethernet, preferably using a reliable transport
>>protocol such as TP4/CLNP, TCP/IP, or even XTP. The data stream will be
>>produced by a card sitting in a workstation that may be as slow as an
>>IBM PC/AT, so obviously it is unlikely that the workstation will handle
>>these speeds very well in software.
 
>I wouldn't be so fast to say that it is "obviously unlikely" that a
>PC-AT could achieve such speeds. The chief bottlenecks are going to be
>the slow copy over the bus, and the checksumming operation, at least for
>a good TCP implementation. A smart card can't do anything about the bus
>speed, and the smaller processor normally found in such cards hurts you
>on the checksum speed.

I think you have proved my point. The PC/AT has a slow bus and a
slow processor. If the workstation gets its greasy CPU around this data,
it will have to be copied across the bus at least twice, and knowing
current TCP implementations, probably many times. (think of checksum
generation.)

I want to DMA the data across the bus, into the card, and forget about
it. If the card has a sparc processor or a 486 or an R3000 or whatever
on it, sobeit. If nobody sells a card like this, then we'll just have to
make one....

(Note that a solution to this is a single-board computer with an
ethernet interface, but then that's exactly what an ethernet card is. If
there's one on the market that fits the specs, then I'll buy it...

I see the workstation around this hardware as little more than something
to download software, gather stats, etc. 

cheers,


--
Mark Williams         The University of Queensland       miw@cc.uq.oz.au
+61 7 36 54012   (w)  Prentice Centre
+61 7 36 54477  (fax) Qld 4072  Australia
Si fractus illabatur orbis impavidium ferient ruinae.  -- Horace

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 92 23:34:34 GMT
From:      vatsan@risky.Convergent.COM (Srivatsan)
To:        comp.protocols.tcp-ip
Subject:   Re: Wireless Bridges for ethernet

In article <1992Mar1.233702.24619@cs.columbia.edu>, ji@cs.columbia.edu (John Ioannidis) writes:
> In article <1992Feb24.145833.20359@isavax.isa.com> cliffb@isavax.isa.com (cliff bedore*) writes:
> >We are looking at linking our corporate office with one of our remote
> >offices ~ 5 miles away.  We can get a 56K link from the Phone company but
> >there are the recurring monthly charges to contend with.  It seems to me
> >that there must be some microwave links available that would let us bridge
> >two ethernets together so they thought they were one.
> >
> >Does anyone have experience with anything like this?  Are any vendors
> >reading who want to send info?   Please e-mail and I'll summarize
> >
> >Thanks for any thoughts you might have
> >
> >Cliff
> >
> >cliffb@isavax.isa.com
> >...!uunet!isavax!cliffb
> >
> 
> 
> I'm not sure what the regulatory status is for such activities, but if
> your two buildings have line-of-sight (you seem to imply that from the
> fact that you want microwave links), you can use some of the wireless
> LAN interface cards that have been around for a couple of years. I
> would suggest a pair of NCR WaveLAN cards ($1100 each), a pair of 386
> machines (<$1500 each), a pair of directional antennas for the 900MHz
> band, and 75Ohm hardline to feed them (you don't want to be using RG59
> at 1db/10ft loss!). With their standard omni antennas, the wavelans
> have a 1/5th mile range, and provide a 2Mbps channel. It should be
> trivial to enhance that to 5 miles by using a yagi with a large number
> of elements. 
> 
> Hope this helps,
> 
> /ji
> 
> In-Real-Life: John "Heldenprogrammer" Ioannidis
> E-Mail-To: ji@cs.columbia.edu
> V-Mail-To: +1 212 854 8120
> P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027



	We have a similar feature across two buildings in our company 
(San Jose CA ) appx 1/2 mile  apart. We have dishes on top of the building. 
( Iam not a system administrator or facilities personnel. Iam not sure about 
the actual make,but I know they even have telphone lines hooked onto this link.)
The speed is appx 56Kbps. All our emails/file transfers/telnet session  work 
through this link. What else you need?. Pretty good. Somebody can eavesdrop
if no encoding scheme is used!!!.

vatsan .

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 92 23:38:08 GMT
From:      vatsan@risky.Convergent.COM (Srivatsan)
To:        comp.protocols.tcp-ip
Subject:   Re: non-interactive ftp???

In article <1992Mar7.190344.6764@rice.edu>, sbyrnes@rice.edu (Steven Byrnes) writes:
> On 6 Mar 92 16:21:03 GMT, Jeff Markel said:
> 
>     I'm looking for a non-interactive ftp client; i.e., I'd like to be able
>     to have cron run a job in the middle of the night to pick up files from
>     another system, without any operator intervention or conversely, to have
>     the source system ship files to a destination at specified times.  My 
>     impression is that the ftp program itself cannot do this.
> 
> Actually, at least under SunOS 4.1.1, one can redirect standard input and
> output for the ftp client.  So, for example, the following will work
> nicely:
> 
> ftp -n ftp.site < foo
> 
> where "foo" contains
> 
> user anonymous <you>@<yourhost>
> binary
> get bar/bass
> 
> The "-n" option to ftp tells it to not try to do an autologin even if you
> have a .netrc file.
> 
> Steven


Use ftp -i <system_name> << inputfile	/* -i non interactive mode option */

<inputfile contents>
user	<user-name> passwd
define your macros through macdef command.
you can also loop through macro. For e.g

macdef loop
type binary
hash
nmap * /dev/null
mget *
$loop


The above script will fetche files in binary mode and dump 
it in /dev/null. Refer document for details of the commands.

vatsan.

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Mar 1992 00:15:35 GMT
From:      johnk@gordian.com (John Kalucki)
To:        comp.protocols.tcp-ip
Subject:   Re: OSPF routing protocol info request

In article <10567@tamsun.tamu.edu>, d1h1883@himalia.tamu.edu (Dave Hess) writes:
|> I'm looking for info on the OSPF routing protocol. Specifically:
|> 
|> 1) I would like to find source code that I can play with.

Gated is rumored to have a OSPF version in Beta. From the gated mailing
list:

-----------------------
Gated 2.1 is now available and contains fixes for all the bugs
reported in the 2.0.1* version of gated.

Gated is a multiprotocol routing daemon for Unix systems.  It's use is
recommended when your Unix system needs to speak a routing protocol
other than RIP, your vendor's version of routed is broken, or you want
more control over what routing information is propagated than routed
allows.

This version supports RIP, HELLO, EGP v2 and BGP v1.  It can also
support SNMP if you buy the PSI SNMP package, contact info@psi.com
more information.

This version *DOES NOT* support BGP v2/3 or OSPF, contact
gated.cornell.edu if you are interested in working
with alpha versions of code that does.

This version should run easily on SunOS, Ultrix, BSD 4.3, BSD 4.3
Tahoe, BSD 4.3 Reno and other BSD based systems.  Generic defines are
available for System V derived systems, but may need some work for
specific systems.


-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Mar 1992 00:46:13 GMT
From:      rafferty@dish.jpl.nasa.gov (mike rafferty)
To:        comp.protocols.tcp-ip
Subject:   Transceiver Question

We have a old Ungermann Bass version 1 ethernet lan made about 1981. I am not
sure if the version 1 transceiver is AC or DC couple. My question is are there
any known problems mixing version 1 AC/DC, and 802.3 transceivers on the same
cable. 

Note: The version 1 tranceivers we have are 3COM 3c100 that comply with the 
Sept 30, 1980 standard for transceivers. 
-- 
Michael H. Rafferty             | rafferty@dish.jpl.nasa.gov  
Jet Propulsion Laboratory       | Voice: (818) 306-6390      
4800 Oak Grove Dr, M/S 525-3681 | Fax:   (818) 306-6969     
Pasadena, Ca. 91109             |                          

-- 
Michael H. Rafferty             | rafferty@dish.jpl.nasa.gov  
Jet Propulsion Laboratory       | Voice: (818) 306-6390      
4800 Oak Grove Dr, M/S 525-3681 | Fax:   (818) 306-6969     
Pasadena, Ca. 91109             |                          

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1992 02:52:05 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp mnemonics

In article <1992Mar10.104536@krakatoa.jsc.nasa.gov> russell@krakatoa.jsc.nasa.gov (Russell Sellers [GHG]) writes:
> I have found that on all the systems I have ftped to that when a
>command is complete a three digit code is returned followed by a
>Diagnostic message for example:
>
>530 Login incorrect.
>
>Is this standard?? Are there any systems that don't implement this code??
>Or do some systems use different codes???

Those codes are standard, and defined by the FTP protocol spec.  The intent
of the FTP protocol design was to allow automated use; the text after the
response code is generally optional.

See RFC 959 for full descriptions of all the code.

BTW, your reference to these codes as "mnemonic" is amusing.  A mnemonic is
an aid to memorization, but these codes are not mnemonic (although there is
some structure to them that makes it easier to recognize them -- e.g. a
first digit of 5 indicates a fatal error).  They would be mnemonics if
three-letter abbreviations (e.g. LGI) were used instead of three-digit
codes.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 92 08:02:34 GMT
From:      melman@FibHaifa.com (David Melman)
To:        comp.protocols.tcp-ip
Subject:   ICMP ECHO REQUEST broadcasts

Interactive TCP/IP (i386 R3.2) does *NOT* permit sending of 
ICMP ECHO REQUEST (ping) to the network IP broadcast 
address.  After much debate, SunSoft, who is now responsible for 
this product, claims this is completely correct and complient with 
all the relevent RFC's.

IS IT???

I know 4.3 BSD, 4.1 SunOS, 4.2 Ultrix, all permit 
pinging the network.

Interactive does however respond to respond to ping broadcasts.
This I know is optional.

Thanks in advance,

David Melman
melman@FibHaifa.com

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 92 18:14:16 MST
From:      royce@scoraz.resp-sci.arizona.edu (Royce Robbins)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   ELC <-SLIP-> ELC help please!

Hello,
     PLEASE  HELP!   I have spent an inordinate  amount  of  time 
trying  to  get the configuration deseribed  below  to  function.  
This  should  NOT be difficult, but I cannot seem to  get  it  to 
work.
     Briefly,  I  am running SLIP at 38.4Kbaud  between  two  Sun 
Microsystems  SPARCstation ELC machines.  I am using the  version 
of  SLIP  and  utilities that came  with  Sun's  PC-NFS  product, 
installed on both machines as per the instructions provided.  For 
various reasons I am using a PC running PCroute as my gateway  to 
the  outside world (which has run successfully for over 2  years) 
and am using Wollongong's WIN/ROUTE for DOS product as a  gateway 
between an Artisoft Lantastic network and a local Ethernet on the 
far  side of the link.
     The  SLIP  link DOES function between the  ELC  hosts;  each 
machine  can talk to the other (ELC #1 <-> ELC #2) and I get  ftp 
throughput of ~1.8Kbytes/sec, and I can even NFS-mount the drives 
of one on the other (and yes, I turned UDP-checksumming ON in the 
kernel).   However,  there  are networks beyond  both  ELCs  that 
cannot  be seen from the far side of the link, although they  can 
be  seen  from the near side, eg ELC #1 CANNOT see  x.y.160.0  or 
x.y.178.0  but  ELC #2 can, and ELC #2 cannot see  x.y.4.0,  etc.  
Obviously I need to be able to do this.  I've tried everything  I 
can think of, does any have any ideas????

     This is the configuration:
                                              x.y.112.20;  +-----------+
   x.y.a.b <-----------------------------------------------+           |
                                               x.y.164.1;  | PCroute   |
                               ----------------------------+           |
                                                           +-----+-----+
                                                      x.y.4.13;  |
                                                                 |
                                                      x.y.4.33;  |
     +-----------+                                         +-----+-----+ 
     |           |                                         |           |
     |  ELC #2   | x.y.11.2;      SLIP link via  x.y.11.1; |  ELC #1   |
     |           +~~~~~~~~~~~~~~~~~~/ US West /~~~~~~~~~~~~+           |
     +-----+-----+                 telephone line          +-----------+
           | x.y.160.2;
           |
           | x.y.160.8;
     +-----+-----+
     |           | x.y.178.8;
     | WIN/Route +-----------------------------------------
     |           |
     +-----------+

************************************************************************
PCroute has the following configuration:
For all interfaces:
             NetMask 255.255.255.0
             Broadcast 255.255.255.255
             Metric 1
             Directed Broadcasts disabled
             ICMP redirects enabled
Interface 1: Address  x.y.112.20
Interface 2: Address  x.y.4.13
Interface 3: Address  x.y.164.1
STATIC ROUTES
Destination          Gateway              Metric
x.y.178.0           x.y.4.33             3
x.y.160.0           x.y.4.33             3
x.y.11.0            x.y.4.33             3

************************************************************************
ELC #1 (at this end of the SLIP link) has the following configuration:
le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
        inet x.y.4.33 netmask ffffff00 broadcast 255.255.255.255
sl0: flags=31<UP,POINTOPOINT,NOTRAILERS>
        inet x.y.11.1 --> x.y.11.2 netmask ffffff00 
        ether 0:0:80:c4:b:2
lo0: flags=49<UP,LOOPBACK,RUNNING>
        inet 127.0.0.1 netmask ff000000 

Routing tables
Destination          Gateway              Flags     Interface
x.y.178.0            x.y.11.2             UGH       sl0
x.y.160.0            x.y.11.2             UGH       sl0
127.0.0.1            127.0.0.1            UH        lo0
x.y.11.2             x.y.11.1             UH        sl0
default              x.y.4.13             UG        le0
x.y.4.0              x.y.4.33             U         le0

************************************************************************
ELC #2 (at the far end of the SLIP link) has the following configuration:
le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
        inet x.y.160.2 netmask ffffff00 broadcast 255.255.255.255
sl0: flags=31<UP,POINTOPOINT,NOTRAILERS>
        inet x.y.11.2 --> x.y.11.1 netmask ffffff00 
        ether 0:0:80:c4:b:1
lo0: flags=49<UP,LOOPBACK,RUNNING>
        inet 127.0.0.1 netmask ff000000 

Routing tables
Destination          Gateway              Flags     Interface
x.y.178.0            x.y.160.8            UGH       sl0
x.y.11.1             x.y.11.2             UH        sl0
127.0.0.1            127.0.0.1            UH        lo0
default              x.y.160.8            UG        le0
x.y.160.0            x.y.160.2            U         le0

************************************************************************
WIN/Route has the following configuration:
For all interfaces:
             NetMask 255.255.255.0
             Broadcast 255.255.255.255
Interface 1: Address  x.y.160.8
Interface 2: Address  x.y.178.8
Default gateway:      x.y.160.2
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Royce Robbins                       INTERNET: royce@scoraz.resp-sci.arizona.edu
Respiratory Sciences Center              FAX: (602) 626-4884
University of Arizona                  PHONE: (602) 626-5022
SysOp for resp-sci..., peds-pulm... and hrp.arizona.edu sub-domains
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Wednesday, 11 Mar 1992 16:54:30 EST
From:      Peter M. Weiss <PMW1@psuvm.psu.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: Backbone design

In article <pista.2@sztaki.hu>, pista@sztaki.hu (Tetenyi Istvan) says:

>Dear Colleagues,
 
>I would like to read some introductory article, case study, etc about the
>design of a relativly small and low-speed IP backbone design. If you have
>good pointer for books, articles etc. please send me a e-mail.

Don't neglect the BIG-LAN listserv and its ~ftp archives at syr.edu.

/Pete
--
Peter M. Weiss                     | pmw1 @ PSUADMIN  |  psuvm.psu.edu|psuvm
31 Shields Bldg - PennState Univ.  | not affiliated with psuvm.psu.edu|psuvm
University Park, PA USA 16802-1202 | A hexadecimal kindof guy in a decimal world

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 92 15:27:57 GMT
From:      pista@sztaki.hu (Tetenyi Istvan)
To:        comp.protocols.tcp-ip
Subject:   Backbone design

Dear Colleagues,

I would like to read some introductory article, case study, etc about the 
design of a relativly small and low-speed IP backbone design. If you have 
good pointer for books, articles etc. please send me a e-mail. 

Kind regards,
      Istvan Tetenyi
      ib006tet@huearn.bitnet

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      11 MAR 92 21:01:56 EST
From:      domenikos@fsdev.enet.dec.com
To:        comp.protocols.tcp-ip
Subject:   SNMP programming seminar offered (April 8-10,Boston)

Registration now in progress for this unique seminar.

* Network management applications development using SNMP  -- 3 days
                                             Dates: 4/08-10/1992


 For registration and info
 please contact:

DTC
275 Wyman Street
Waltham, MA 02154
Tel: (617) 684-0060
Fax: (617) 684-0072



-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 92 17:22:03 GMT
From:      spoelhof@kodak.com
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   FTP Source Code Wanted

Can anyone help me locate source code for a FTP server.  I already have
a TCP stack, and the FTP application is not in Comer's books.

Please respond to my Internet address (spoelhof@kodak.com)

Thank You,

Gordon Spoelhof,
Eastman Kodak Co. - Health Sciences Division

Internet: spoelhof@Kodak.COM              | Office:  716-253-9734
PROFS:    vaes07%lockovm2.profs@kodak.com |          716-253-9647 (Kim Myers)
US Mail:  HSD/I&IM 2-8-C                  | FAX:     716-253-7966
          Eastman Kodak Co. / 100 Carlson Road / Rochester, NY 14653-9105

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 92 21:04:52 GMT
From:      qlin@seneca.cerc.wvu.wvnet.edu (Qiang Lin)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.mail.multi-media,comp.realtime,comp.multimedia
Subject:   Help on transmitting Parallax slow motion video through TCP/IP

Hi:
	I am working on transfering the Parallax video image through
TCP/IP. I am trying to transmit slow motion images captured by the
Parallax because we don't have any real-time compression hardware 
available right now. We have the Parallax VideoView hardware working
on MIT X11/R4. Does anybody know if somebody has done this kind of
work already? 
	I really appreciate if somebody can provide any hints.


Qiang Lin
Concurrent Engineering Research Center
West Virginia University
Morgantown, WV 26506

email: qlin@cerc.wvu.wvnet.edu

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 92 21:53:05 GMT
From:      drw@kronecker.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   whois

I'm trying to use 'whois'.  Unfortunately, I have to work on a
commercial timesharing system which can't talk to nic.ddn.mil, because
of the AUP on the NSFnet, which forbids traffic from the commercial
system.  I was wondering if there are any other sites that offer whois
service that I might be able to use.

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
A funeral service resembles a wedding except it's less serious because
the consequences of the ceremony are already known and there's no
danger of repetition.	-- P. J. O'Rourke, "Modern Manners"

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 92 23:16:59 GMT
From:      sss@netcom.com (Small Systems Solutions)
To:        comp.protocols.tcp-ip
Subject:   Re: whois

In article <DRW.92Mar11165305@kronecker.mit.edu> 
	drw@kronecker.mit.edu (Dale R. Worley) writes:

>I'm trying to use 'whois'.  Unfortunately, I have to work on a
>commercial timesharing system which can't talk to nic.ddn.mil, because
>of the AUP on the NSFnet, which forbids traffic from the commercial
>system.  I was wondering if there are any other sites that offer whois
>service that I might be able to use.

NSFNet doesn't forbid traffic from commercial systems -- it forbids
commercial traffic from any systems.

A whois request is perfectly reasonable, wherever it comes from.

-- 
Small Systems Solutions                   1563 Solano Avenue, Suite 123
sss@netcom.com                                  Berkeley, CA 94707-2116

The above-expressed opinions aren't necessarily

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 92 23:49:32 GMT
From:      schmidt@net6.ics.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip
Subject:   PNPS project from Berkeley


Hi,

	Can anyone point me in the direction of publically available
research papers on the PNPS project by Professor Pravin Varaiya at
Berkeley?

	Thanks in advance,

		Doug
--
His life was gentle, and the elements so            | Douglas C. Schmidt
Mixed in him that nature might stand up             | schmidt@ics.uci.edu
And say to all the world: "This was a man."         | ucivax!schmidt
   -- In loving memory of Terry Williams (1971-1991)| (714) 856-4101

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 92 03:05:10 GMT
From:      jpc@avdms8.msfc.nasa.gov (J. Porter Clark)
To:        comp.protocols.tcp-ip
Subject:   Unwanted SunRPC traffic, what's going on here?

On the local Class B net, there is a computer which seems to behave
oddly.  No surprise there, but it's bugging me.  This machine, call it
"oddity" (not his real name), which issues a broadcast SunRPC call
every 10 minutes.  When it does this, at least 20 hosts respond.  There
are also typically about that many ARPs as the hosts try to rediscover
oddity's Ethernet address.  Many of these hosts have no obvious
business talking to oddity or vice versa.  I've summarized the
etherprint dump below, although I have screened out the ARPs.

What's oddity doing?  I have talked to oddity's keeper, but he doesn't
know either.  I tend to believe that something is wrong with something
in oddity's setup, although everything could be perfectly normal for
all I know.  He's not causing me any problems that I know about, other
than making me nervous (this is fixable).

What else should I look for?  What should I tell oddity's keeper to do?

 0.00 UDP from oddity.1192 to broadcast.sunrpc  64 bytes
 RPC Call portmapper  PMAPPROC_GETPORT  V2 [1ff05a0]

 0.00 UDP from host1.sunrpc to oddity.1192  36 bytes
 RPC Reply  [1ff05a0] AUTH_NULL Success 

 0.01 UDP from host2.sunrpc to oddity.1192  36 bytes
 RPC Reply  [1ff05a0] AUTH_NULL Success 

# A good many hosts later....

 0.12 UDP from hostx-1.sunrpc to oddity.1192  36 bytes
 RPC Reply  [1ff05a0] AUTH_NULL Success 

# There's this one guy who is always last and always gives this reply.

 0.46 UDP from hostx.sunrpc to oddity.1192  32 bytes
 RPC Reply  [1ff05a0] AUTH_NULL PROG_UNAVAIL 

--
J. Porter Clark    jpc@avdms8.msfc.nasa.gov or jpc@eb23.msfc.nasa.gov
NASA/MSFC Communications Systems Branch

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 92 04:49:24 GMT
From:      hyeom@cs.tamu.edu (Heon Y. YEOM)
To:        comp.protocols.tcp-ip
Subject:   How reliable is datagram ?



I'd like to get some data/idea about the message loss on ethernet when using
datagram, especially when the communication is between the machines physically
close to each other (no bridges/routers).
What I want to do is to set up 3-4 machines to talk to each other at the same
time using just one message broadcast to all of them instead sending multiple
messages.  From my initial attempt, I found there are some messages get lost
from time to time.  I guess that's expected by the unreliable nature of
datagram.
Does anybody know how often does a message get lost and why ?
If it matters, the machines I am using now are sparc1,2s.
I believe the main reason of the message loss is due to the buffer overflow.
If that's the case, would it be possible to at least get some indication
that there has been a message loss ?
Any idea would be appreciated.

- hyeom@cs.tamu.edu


-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Mar 1992 05:05:16 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP ECHO REQUEST broadcasts

In article <510@ariadna.FibHaifa.com>, melman@FibHaifa.com (David Melman) writes:
> Interactive TCP/IP (i386 R3.2) does *NOT* permit sending of 
> ICMP ECHO REQUEST (ping) to the network IP broadcast 
> address.  After much debate, SunSoft, who is now responsible for 
> this product, claims this is completely correct and complient with 
> all the relevent RFC's.
> 
> IS IT???
> 
> I know 4.3 BSD, 4.1 SunOS, 4.2 Ultrix, all permit 
> pinging the network.
> Interactive does however respond to respond to ping broadcasts.
> This I know is optional.

As in RFC-1122:
]    3.2.2.6  Echo Request/Reply: RFC-792
]      ....
]	An ICMP Echo Request destined to an IP broadcast or IP
]	multicast address MAY be silently discarded.
]	DISCUSSION:
]	     This neutral provision results from a passionate debate
]	     between those who feel that ICMP Echo to a broadcast
]	     address provides a valuable diagnostic capability and
]	     those who feel that misuse of this feature can too
]	     easily create packet storms.


Anyone who now argues this point is behind the times, as is anyone who
wants UID=0 for the BRL -f for flood option to ping, now found (I think) in
4.3BSD-reno.

It is easier to crash an ethernet with `ttcp` than with ping.  I know
because I keep telling test machines to use each other's ethernet names
instead of their FDDI names, and spending minutes figuring out why
cursors, X, mice, and everything else freezes.

The passion means you're not going to convince Sun that they're wrong.

"Compliant with all the relevant RFC's" has little bearing on "completely
correct."  The customer defines "correct," albeit often by plagiarizing
RFC's.

Depending on how incompatible with sockets is the Interactive STREAMS
TCP/IP, it might be easy to port a good ping.c.  Look for it on uunet.


Vernon Schryver,  vjs@sgi.com


-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 92 07:23:35 GMT
From:      my@berlioz.nsc.com (Michael Yip)
To:        comp.protocols.tcp-ip
Subject:   Re: Source code for TCP/IP in Comer book

>Does anyone have the sources from the book
>"Internetworking with TCP/IP Volume II, Design , Implementation, 
>and Internals" by Douglas Comer and David Stevens?
>
>Is that book even better than the famous 'Unix Network programming'
>by W.R. Stevens ??

D. Comer and D. Stevens' book is about how to implement TCP/IP.
W. Stevens' book is about how to use TCP/IP (in UNIX).

The two books are quite different in context and both very very
good reference.  Although the two books are different, they have
some parts in common.  They both explain what is TCP/IP and how it
works (especially Vol I of Comer's book), and they both have examples
on how to use TCP/IP (socket interface).

Depends on what you want, you might need only one of them.  But I 
would strongly suggest getting that two books in addition to the
RFCs and Vol 1 or Comer's book.

-- 
| Michael Yip			Email: my@berlioz.nsc.com
| National Semiconductor Corp	Voice: (408) 721-5148
| 
| Of course, this is my own opinion!

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 92 11:45:39 GMT
From:      bof@midget.saar.sub.org (Patrick Schaaf)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp mnemonics

russell@krakatoa.jsc.nasa.gov (Russell Sellers [GHG]) writes:
>530 Login incorrect.
>Is this standard?? Are there any systems that don't implement this code??
>Or do some systems use different codes???

Try to obtain the RFC describing the FTP protocol (should be somewhere in
the 700's, if I remember correctly). The digits are standard, e.g. the
5 tells you the intended operation failed, a 2 as the first digit tells
you it worked, a 3 says: "wait for more, command not yet completed".
Get the RFC for a full description.

Patrick
-- 
Patrick Schaaf        /   \ /\  if you can't make it go away,
Saarbruecken, Terra  / -.- /..\  even if you stop believing it,
bof@midget.saar.sub.org   /    \   then, maybe, it might be reality.
-- use this line to annoy people scanning for .signature viruses --

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 92 14:18:54 GMT
From:      adnan@sgtech.UUCP (Adnan Yaqub)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Looking For DLPI Specification

Recently I posted some questions about AT&T's Link Provider Interface
(LPI) specification.  Among the replies I received were several which
informed me that LPI has been obsoleted by the DLPI specification.
Does anyone know how I can get a copy of this specification?  One
person said to check with Unix International.  Does anyone have an
address or phone number for them?

Thanks.
--
Adnan Yaqub (adnan@sgtech.uucp, ...!uunet!abvax!sgtech!adnan)
Star Gate Technologies
29300 Aurora Rd, Solon, OH, 44139, USA, +1 216 349 1860

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 92 17:23:37 GMT
From:      bo550@cleveland.Freenet.Edu (Michael Beaven-Leibow)
To:        comp.protocols.tcp-ip
Subject:   Help with SLIP and routing


We have a class B network
143.240.1.x is administered by somebody else
143.240.2.x by me
143.240.3.x proposed slip machines

We have a sun 4/75: address 143.240.2.1 netmask 255.255.255.0

I ran
slip-attach /dev/ttyb 19200 143.240.2.32 143.240.3.1 255.255.255.0

Question:
I'm not quite sure of what "local-address" and "destination-address" mean,
and I'm not sure how to set up the router on 143.240.2.1.

What is the correct routing command?

route add 143.240.?.? 143.240.?.? 0

Thanks for your help,


	--Mike Leibow
	leibow@csn.ia.com
	(716) 467-7983 x373
-- 
Michael S. Leibow
leibow@csn.ia.com

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 92 18:05:49 GMT
From:      l1ngo@copper.denver.colorado.edu (Swift)
To:        comp.protocols.tcp-ip
Subject:   Re: Source code for TCP/IP in Comer book

In article <WH7Z2XS@zelator.in-berlin.de> thf@zelator.in-berlin.de (Thomas Funke) writes:
>In <1992Mar6.150837.27998@icd.ab.com> korsberg@kirk (Ed Korsberg) writes:
>>"Internetworking with TCP/IP Volume II, Design , Implementation, 
>>and Internals" by Douglas Comer and David Stevens?
>
>Is that book even better than the famous 'Unix Network programming'
>by W.R. Stevens ??

I think that Comer's TCP/IP books (Volume I at least) is a must-read
for beginners before they tackle "Unix Network Programming."  They are
very well-written. Tanenbaum's "Computer Networks" is also great for a general
introduction to networking especially with the OSI model.

Lin

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 92 18:31:37 GMT
From:      tanm@seneca.bst.rochester.edu (Martin Tanner)
To:        comp.protocols.tcp-ip
Subject:   terminal server


We currently own a datability vcp 1000 terminal server which
we are very unhappy with - the server crashes 4-5 per week.
We are interested in suggestions for a replacement for this
terminal server.

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Mar 1992 18:49:42 GMT
From:      mhpower@athena.mit.edu (Matt Power)
To:        comp.protocols.tcp-ip
Subject:   Re: whois

In article <DRW.92Mar11165305@kronecker.mit.edu> drw@kronecker.mit.edu (Dale R. Worley) writes:
>I'm trying to use 'whois'.  Unfortunately, I have to work on a
>commercial timesharing system which can't talk to nic.ddn.mil, ...
>         I was wondering if there are any other sites that offer whois
>service that I might be able to use.

Yes, there are many other hosts that provide whois service, in the sense
that they accept queries and deliver responses in a manner similar to
what's described in RFC 954.

I maintain a list of these whois servers, available via anonymous FTP in

    sipb.mit.edu:/pub/whois/whois-servers.list

It currently includes 74 servers in 14 countries.

Generally, these servers provide information about users. I don't know
of ways to query them for domain or host records of the type registered
with the (U.S.) DDN Network Information Center.

If you're looking to query the NIC database, there may be an alternative
source, although one that isn't a whois server itself. The Knowbot
Information Service (accessible via TCP port 185 on nri.reston.va.us,
for example) provides an interface to the NIC data. It's possible to get
domain and host information, although the formatting isn't perfect if
you connect using just a telnet client, e.g.,

    > service nic
    > mit.edu
    Name:         Institute of of Massachusett
    ...

Matt

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Mar 1992 19:52:40 GMT
From:      johnk@gordian.com (John Kalucki)
To:        comp.protocols.tcp-ip
Subject:   Re: terminal server

In article <1992Mar12.183137.1365@galileo.cc.rochester.edu>, tanm@seneca.bst.rochester.edu (Martin Tanner) writes:
|> 
|> We currently own a datability vcp 1000 terminal server which
|> we are very unhappy with - the server crashes 4-5 per week.
|> We are interested in suggestions for a replacement for this
|> terminal server.

Well, what do you want to do with the replacement? Any specific features that
you want? A price range?

		-John Kalucki
		johnk@gordian.com

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Mar 1992 21:28:51 GMT
From:      kev@sol.acs.unt.edu (Kevin W. Mullet)
To:        comp.protocols.tcp-ip
Subject:   Help with MERIT Rover

Is anyone out there using the MERIT Internet Rover?  We're having beau coup
problems getting it working on our Solbourne 5e904 running Sun OS/MP 4.1A.1.


I need to hook our system programmer up with someone who's gone through
this process so I can get Rover up & running.


Please reply to me by mail.  Thanks.

-Kevin Mullet
 University of North Texas
 kev@unt.edu

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 92 22:20:24 GMT
From:      shava@gibbs.oit.unc.edu (Shava Nerad Averett)
To:        comp.protocols.tcp-ip
Subject:   Is your SLIP showing?

We are interested in finding out what other universities are doing with
SLIP.  We have no slip service now, and have a whole *8* 9600 baud public
dial-in lines.  However, people are coming to us with inquiries about 
SLIP.

Can you folks in university (especially cash poor universities!) environ-
ments tell me what y'all are doing about:

	Providing public SLIP access
	Providing dept only SLIP
	Best equipment (modems, servers, whatever) (preferably free ;-)
	Best software, software tools, management tools, performance tools,...
	Security
	How do you figure out what these folks internet numbers are, anyway?
	Useful articles, documentation, ftp sites, etc.
	Clues cheerfully accepted!

I will gladly gather info and summarize back to the group.

Shava Nerad Averett
UNC Networking Systems
-- 
Shava Nerad Averett				shava_averett@unc.edu
/*  all materials (c)1992, Shava Nerad Averett, and have nothing significant
    to do with the University of North Carolina, a mostly owned subsidiary 
    of the NC Legislature, a mostly owned subsidiary of the DOT.      */

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Mar 92 02:56:38 GMT
From:      wayne@gbrmpa.gov.au (Wayne Amisano)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Quickmail & PC-NFS

hi,

i would like to know if anyone has had any experience
with installing CE-Softwares quickmail package on a
P.C. running PC-NFS.

tnx in advance,
wayne@gbrmpa.gov.au
-- 
Wayne Amisano
GBRMPA                        - Townsvile, Australia
wayne@gbrmpa.gov.au           - Internet  |   Life is too important
vk4kt@vk4afs.#NQ.QLD.AUS.OC   - PBBS      |   to be taken seriously

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Friday, 13 Mar 1992 08:36:01 EST
From:      <KRS100S@ODUVM.BITNET>
To:        comp.protocols.tcp-ip
Subject:   TCPIP for Color Tectronics 4109


I am looking for a TCP/IP product that will support Color Tectronics
emulation such as the 4109.  Does any one know of one or where I could
look up information.... thanks

Ken



-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Friday, 13 Mar 1992 08:43:28 EST
From:      <KRS100S@ODUVM.BITNET>
To:        comp.protocols.tcp-ip
Subject:   TCP for Color Tektronix 4109 or such


I am looking for a TCP/IP product that will support Color Tektronix
emulation such as the 4109.  Does any one know of one or where I could
look up information.... thanks

Ken



-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 92 08:35:30 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Help on transmitting Parallax slow motion video through TCP/IP


 >	I am working on transfering the Parallax video image through
 >TCP/IP. I am trying to transmit slow motion images captured by the
 >Parallax because we don't have any real-time compression hardware 
 
Qiang Lin

are you using TCP, or UDP with an add on
segmentation/reassembly/interpolating-receiver?

we've done this with videopix(TM-sun), and another board - 

we use UDP so we dont get flow controlled by TCP and dont get
retransmits either - we send XImages (but it could be anything, and
have messed around with various compression algs (a modern 30MIPS
workstation can cut data transmission down quite a bit...)
one cute thing is to use multicast (also not possible for TCP yet, but
is for UDP)...for multiple receivers at almost no extra cost...

we await multicasting and timeliness extensions to X (or any
window system...)
we are in the process of writing up what we've done...

cheers

 jon

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 92 12:04:02 GMT
From:      sanders@dev1d.mdcbbs.com (Wayne Sanders-Unrein)
To:        comp.unix.ultrix,comp.protocols.tcp-ip,comp.sys.dec
Subject:   sockets vs bind?


Here's the problem.  I have a very generic client/server application using
sockets.  It has no problems except on Ultrix when ypbind is used a lot.  At
those sites where bind is used extensively for admin my server appears to hang
periodically.  My question could bind be the problem or is it a red herring?

email would be fine.  Thanks

-- 
| Wayne Sanders-Unrein	    | Voice:    +1 714 952 5773
| Currently on contract to: | Internet: sandy@dev3.mdcbbs.com
| EDS, Unigraphics Division | <-- talking from but not for
| Cypress, CA		    | UUCP: ...{uunet,decwrl,att}!dev3.mdcbbs.com!sandy

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Mar 1992 13:10:23 GMT
From:      petav@Physik.TU-Muenchen.DE (Peter Averkamp)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: TCP Implementation on an Ethernet card

miw@brolga.cc.uq.oz.au (Mark I. Williams) writes:

>peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
 
>>miw@brolga.cc.uq.oz.au (Mark I. Williams) writes:
 
>>>I have an application whereI need to transmit data at a rate of about
>>>1.5-2 Mbit/sec over ethernet, preferably using a reliable transport
>>>protocol such as TP4/CLNP, TCP/IP, or even XTP. The data stream will be
>>>produced by a card sitting in a workstation that may be as slow as an
>>>IBM PC/AT, so obviously it is unlikely that the workstation will handle
>>>these speeds very well in software.
 
>>I wouldn't be so fast to say that it is "obviously unlikely" that a
>>PC-AT could achieve such speeds. The chief bottlenecks are going to be
>>the slow copy over the bus, and the checksumming operation, at least for
>>a good TCP implementation. A smart card can't do anything about the bus
>>speed, and the smaller processor normally found in such cards hurts you
>>on the checksum speed.
 
>I think you have proved my point. The PC/AT has a slow bus and a
>slow processor. If the workstation gets its greasy CPU around this data,
>it will have to be copied across the bus at least twice, and knowing
>current TCP implementations, probably many times. (think of checksum
>generation.)
 
>I want to DMA the data across the bus, into the card, and forget about
>it. If the card has a sparc processor or a 486 or an R3000 or whatever
>on it, sobeit. If nobody sells a card like this, then we'll just have to
>make one....
 
>(Note that a solution to this is a single-board computer with an
>ethernet interface, but then that's exactly what an ethernet card is. If
>there's one on the market that fits the specs, then I'll buy it...
 
>I see the workstation around this hardware as little more than something
>to download software, gather stats, etc. 

Ok, so much on guesses. Not that i like mess-dos boxes, BUT i recently
had to find a fast way to transfer big image files from such a beast
to a unix machine. My results boil down to a real, sustained transfer
rate of 240 kBytes/sec from a 20 Mhz 386 PC to a Dec pmax disk by 
using a 16bit WD8003elite and TCP sw from FTP inc. Regarding the potential
speed gains by some faster PC and not driving a unix disk (was a Maxtor
Panther and a Fuji 1/2G,if it matters), a raw transmission rate of
1.5-2Mbit does not seem too far out of reach, right? I am shure that 
some EISA or microchannel thing could easily do it.

Hope this helps,

 - Peter -


--
Peter Averkamp,                      | email:
Physics Department E20               | petav@radon.e20.physik.tu-muenchen.de
Techn. Univ. of Munich               | Phone: ++49 (89) 3209-2408
D-8046 Garching, Germany             | Fax:   ++49 (89) 3209-2338

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 92 13:27:26 GMT
From:      dimitris@aliakmon.cperi.forth.gr (Dimitris Hatzopoulos)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Secondary IP addresses for the same Ethernet interface

I wonder, can I configure a SunOs 4.1.1 (ELC) system in a way that its
Ethernet interface has 2 (or more :-) IP addresses ? Our CISCO router
accepts "secondary" IP addresses for each of its Ethernet interfaces,
so do VMS systems here, running MultiNet.

If you're going to e-mail a response, I'll gladly summarize to the net
later !


Best regards,
D.

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 92 13:28:28 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.kerberos,comp.protocols.tcp-ip,sci.crypt
Subject:   Re: Telnet authentication option

In article <1992Mar10.173714.295581@cs.cmu.edu> moore+@CS.CMU.EDU (Dale Moore) writes:
>>Has anyone added Kerberos V4 authentication to BSD telnet/telnetd as
>>per the IETF Internet Draft?  
>
>Yes. Dave Borman at Cray has.
>His results are on uunet.uu.net.
>I suspect that Berkeley will be distributing this with 4.4 BSD.
>We've been running a variation of it for a couple of months now.

  One would HOPE that Kerberos _V5_ would be what people specified and
implemented rather than the older _V4_.  The security differences are
between the two versions aren't trivial.


  While I'm at it, Peter Honeyman has an interesting Tech Report available
for anonymous ftp from cici.umich.edu concerning security considerations
in AFS (which uses Kerberos).  Definitely worth reading.

Ran
atkinson@itd.nrl.navy.mil

P.S.
  I've set followups to comp.protocols.kerberos, if you are following up
and that isn't really the right place, please use common sense and EDIT
the newsgroups line of your posting. :-)

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 92 15:27:02 GMT
From:      bv@nixctc (Burkhard Viehoff)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   RFC 1006 implementation


	Hi,

I am  looking for a product, that packs up ISO-protocols
in TCP/IP  according to RFC 1006 .

Preferably the product should run on SCO-UNIX.

Any information or  hints are very much appreciated.

	Thanks  for your interest and help.

Burkhard Viehoff


-------------------------------------------------------------------------
Siemens Nixdorf Informationssyteme AG

Burkhard Viehoff                | bv@nixctc.uucp
D9 Open Systems                 | bv@nixctc.de
                                | 
Loeffelstrasse 40               | pyramid!nixctc!bv
7000 Stuttgart 70               |
West Germany                    | Phone: +49 (711) 977-4387
                                | Fax:   +49 (711) 977-4332
-------------------------------------------------------------------------

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 92 16:28:23 GMT
From:      exudnw@exu.ericsson.se (Dave Williams)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   How to get enet H/W address reliably

Does anyone have a foolproof way to get the Ethernet hardware address of
a Sun (any model) system?  It can't depend on /etc/ethers or on NIS or DNS 
services being available.

Yea, I know "/etc/dmesg | grep Ethernet" sorta works, but I want to do this 
from within a program, and don't trust dmesg either.

---
= exudnw@exu.ericsson.se                                  (214)907-7928 =
= David Williams    "UNIX is an incantation oriented operating system"  =
= Ericsson Network Systems                                   --Me       =
= Richardson, TX 75081                        These opinions are my own.=

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Mar 1992 16:39:39 GMT
From:      crm413c@bcars19.bnr.ca (Peter Ng)
To:        comp.protocols.tcp-ip
Subject:   push bit

Would someone be kind enough to tell me:
a. The functions of the 'push' bit in the TCP header.
b. How to turn the 'push' bit on/off in the Unix environment.


... Peter



-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Mar 1992 16:40:39 GMT
From:      robelr@ucs.indiana.edu (Allen Robel)
To:        news.announce.newgroups,news.groups,comp.multimedia,comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.protocols.appletalk,comp.protocols.iso,comp.protocols.nfs,comp.realtime
Subject:   RFD:  comp.dcom.bisdn

This is a request to discuss the naming, charter, and location
in the USENET hierarchy, of a group who's focus would be centered
around ATM technology.  Because ATM has the potential to impact
many areas, I am posting this to all of the groups that I feel
would be interested.  These groups include:

comp.multimedia
comp.dcom.lans
comp.protocols.tcp-ip
comp.protocols.appletalk
comp.protocols.iso
comp.protocols.nfs
comp.realtime

If you know of any other groups please let me know.  Since there
are many workstation issues to bat around, maybe those groups
should be included as well?  Also, since ATM started out as a
potential transport for wide area networks, any groups that 
discuss WANs should be notified as well.

MOTIVATION:

Over the course of the past few months, I've seen many signs
that hint at ATM becoming a viable LAN technology in the 
near future (1 to 2 years).  At least one vendor has released
an ATM hub and ATM interface cards for Sun's SparcStations and
DEC's DECStations and another has announced intention to do so
nest year.  Recently, a consortium of vendors formed
the ATM Forum to develop common implementation specifications
for ATM networks.  These vendors included Adaptive Corp., cisco
Systems, Northern Telecom, and US Sprint.  40 more vendors have
joined the forum, including DEC, Hughs LAN Systems, MCI 
Communications Sun Microsystems, and Ungermann-Bass.  Since
the industry is gearing up for ATM, I feel that users, network
administrators, and network planners should, likewise, begin 
discussing this new technology's potential, its strength's
and limitations, its effect on an organization's structure
(implied by ATM's ability to multiplex voice, video and data),
workstation hardware and OS requirements, and anything else that's 
relevant.  We should *not* discuss protocol/encapsulation issues
in this group, as the IETF is working on these issues on their
mailing list (atm@bbn.com, subscribe to atm-request@bbn.com)

thanks,
-- 
Allen Robel                         robelr@mythos.ucs.indiana.edu 
University Computing Services       ROBELR@IUJADE.BITNET 
Network Research & Planning         voice: (812)855-7171
Indiana University                  FAX:   (812)855-8299

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 92 21:02:27 GMT
From:      spoelhof@kodak.com
To:        comp.protocols.tcp-ip
Subject:   MANDATORY PROTOCOLS

Does anyone know where to find a document specifying the MANDATORY IP 
protocol suite for a non-routing host?  For example, I believe that SNMP
is a RECOMMENDED protocol rather than a MANDATORY one.  I have been searching
through the RFCs, but this has to be documented somewhere...

Please reply to my e-mail address (spoelhof@kodak.com).

Thanks,

Gordon Spoelhof,
Eastman Kodak Co. - Image and Information Management

Internet: spoelhof@Kodak.COM              | Office:  716-253-9734
PROFS:    vaes07%lockovm2.profs@kodak.com |          716-253-9647 (Kim Myers)
US Mail:  HSD/I&IM 2-8-C                  | FAX:     716-253-7966
          Eastman Kodak Co. / 100 Carlson Road / Rochester, NY 14653-9105

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 92 21:59:37 GMT
From:      goldstein@carafe.enet.dec.com (Fred Goldstein [k1io; FN42jk])
To:        comp.dcom.lans.fddi,comp.dcom.lans.misc,comp.protocols.tcp-ip
Subject:   Re: asynchronous transfer mode


In article <92069.181302C55969@TRMETU.BITNET>, C55969@TRMETU.BITNET writes:
>I am seeking some information regarding ATM (asynchronous transfer mode)
>of what so ever. I will be glad if anybody out there could send me files
>related to the subject or tell me where, and how I can get them.

For the sake of the net, I'll mention a new book on the subject.
"Integrated Broadband Networks" by Handel and Huber, published by
Addison-Wesley (Wokingham, England -- this is from their European side, 
though it's available stateside too).  It's about 200 pp hardcover, and
covers the ATM gamut pretty well for something like this (1991
copyright).  The style is rather academic - formal, but it's not a
math treatise; it's rather heavy into CCITT standards though.  (This
is understandable; the authors are from Siemens.)
---
Fred R. Goldstein   goldstein@carafe.enet.dec.com 
                 or goldstein@delni.enet.dec.com   voice:+1 508 952 3274
Standard Disclaimer:  Opinions are mine alone; sharing requires permission.


-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 92 22:16:55 GMT
From:      simotas@zodiac.rutgers.edu
To:        comp.protocols.tcp-ip
Subject:   Looking for Troll

I am looking for the TROLL network simulator program.

I have a manual page from Sun Microsystems describing the program
but it is not installed in our machines.

Does anybody out there know how this program is distributed and
where it is available from ?

Any help would be greatly appreciated.

Please send email at : simotas@zodiac.rutgers.edu

--------------------------------------------------------------------------
Simotas Eleftherios                    Dpt of Electrical Eng.
                                       RUTGERS UNIVERSITY
                                       Piscataway, NJ 08855

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 92 22:27:58 GMT
From:      gsa@easyaspi.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: push bit

In article <1992Mar13.163939.997@bnr.ca>, crm413c@bcars19.bnr.ca (Peter Ng) writes:
|> Would someone be kind enough to tell me:
|> a. The functions of the 'push' bit in the TCP header.

The "push" bit is an informative flag which indicates that all 
data "up to this point" should be delivered to the peer system and
ultimately to the peer application.  The general intent is to 
"flush the data path" to prevent delays caused by coalescing entities.

The "push" flag identifies a point in the data stream (offset + length, 
of message containing the push flag).

The "push" flag is not a delimiter (i.e. successive pushes are merged into
one stream offset, the last one).

Implementations of TCP do not always support this correctly.  Do send
"push" flags to make sure peer systems do not "hang" while coalescing
data!!!  Do not depend on "push" flags when coalescing data!!!


|> b. How to turn the 'push' bit on/off in the Unix environment.

This response is relative to BSD derivatives.

1)	When sending data, the user has no explicit control over the
	insertion of the push flag.  The flag is inserted by TCP in 
	the message which depletes the socket send buffer.  The amount
	of information specified in the socket write (or send) request
	will implicitly influence the setting of this flag.

2)	When receiving data, TCP ignores the PUSH flag.  No coalescing
	or process scheduling is influenced by the presence or absence
	of this flag.


|> 
|> 
|> ... Peter

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 92 07:44:50 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: whois

In article <DRW.92Mar11165305@kronecker.mit.edu> 
	drw@kronecker.mit.edu (Dale R. Worley) writes:
>>I'm trying to use 'whois'.  Unfortunately, I have to work on a
>>commercial timesharing system which can't talk to nic.ddn.mil, because
>>of the AUP on the NSFnet, which forbids traffic from the commercial
>>system.  I was wondering if there are any other sites that offer whois
>>service that I might be able to use.

In article <!k3hgwrsss@netcom.com>
   sss@netcom.com (Small Systems Solutions) writes:
>NSFNet doesn't forbid traffic from commercial systems -- it forbids
>commercial traffic from any systems.
>A whois request is perfectly reasonable, wherever it comes from.

While this might be almost true, it does not help the users on
WORLD.STD.COM, who (apparently unlike NETCOM.COM and WELL.COM) are
refused routing by ANS/NSFnet.

Until the politics change, you are probably SOL (Sh*t Out of Luck).

On the other hand, there is some hope that the politics may change soon.
The House Science Committee is asking NSF why there is any need for the
Acceptable Use Policy restrictions. NSF is researching the issue and may
decide to relax the rules. Watch the COM-PRIV list for latest updates.

The AUP/routing issues are funny. CMC is a commercial customer on
CERFnet. NETCOM is a commercial customer on BARRnet. Both CERF and BARR
are members of CIX, but packets from CMC to NETCOM flow freely over
NSFnet. Packets from CMC to STD, on the other hand, go via CIX.
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 92 20:45:20 GMT
From:      C506634@umcvmb.missouri.edu (Eric Edwards)
To:        comp.protocols.tcp-ip
Subject:   Telnet Server <-> client flow control

I'm writing a terminal server/dialin.  In this application I transfer data
from an ip connection to a serial port and visa versa.  Most of the time
the ip connection is going to be an order of magnitude faster than the serial
line although the reverse situation is also possible.
 
It seems like the ip connection would frequently overflow my buffer unless I
had an extroardiarily fast serial connection on the other side.
 
Is there some way of informing the remote server to stop sending data before
my receive buffer overflows?  Then I could tell the remote to resume when my
buffer has been drained sufficiently.  XON/XOFF is a troubling solution since
more likely than not, the connection will be in binary mode when large bursts
of data are exchanged.
 
Perhaps this is not the big problem I am making it out to be?  Does tcp/ip have
some kind of internal flow control?
 
Eric Edwards: c506634 @   | "MS-DOS is one of those rare environments where
Inet: umcvmb.missouri.edu |  applications are written around the operating
Bitnet: umcvmb.bitnet     |  system rather than under it."

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15 Mar 92 06:36:34 GMT
From:      khanraha@afit.af.mil (Kevin M. Hanrahan)
To:        comp.protocols.tcp-ip
Subject:   Re: non-interactive ftp???

brunner@practic.com (Thomas Eric Brunner) writes:


>while you can redirect file descriptors and use either your .netrc or
>a perl script, you might also consider using expect/tcl as a mechanism
>for generating canned interactive scripts... you can use the same tools
>for ftp as well as telnet. see your nearest archive for tcl and expect,
>which now go by the name of tk.

I've used the script that comes with the expect source to ftp a specific
RFC by just entering "rfc-ftp <number>".  I haven't had much chance to mess
with expect, but it's kinda neat.  At least it can make FTP's a little less
laborious!

--Randy Smith--
rjsmith@mmdis01.hq.aflc.af.mil

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 92 00:30:00 GMT
From:      l00017@eeyore.stcloud.msus.edu (Networking Research)
To:        comp.os.mach,comp.protocols.tcp-ip
Subject:   Re: Setting up Mach386 with an SMC Ethercard Elit

In article <577a6991.1bc5b@pisa.citi.umich.edu> Jim.Rees@umich.edu writes:
>The necessary patches have been posted here before, but I don't know if
>they've made it back into the CMU sources.  The Elite is almost like the
>older WD boards, but returns a different ID, so the interrupt doesn't get
>enabled.  And the "soft" defaults are different from what Mach expects.
>You can fix this with the WD configuration program, or you can fix it in the
>driver.

	I've gotten an number of replies of this nature, and while I do
appreciate it, it's not really what I need, I guess.  I've got Mt. Xinu's
Mach386 *binary only* version of Mach, and it's not even slightly
reconfigurable (unless you get on Mt. Xinu's auto support plan) so patches
for the wd driver aren't what I need.  Besides which, I beleive that the
version of Mach386 I've got has been patched to allow use of the Elite
boards, the addendum to the documentation I have lists compatibility with
Western Digital 80x3 ethernet cards, my card is an 8013EB, and *is* recognized
by the kernel, however, nothing ever gets sent through it by Mach as far as
I can tell.
	"netstat -r" shows packets being routed to the wd0 interface,
but . . .
	I tried a "wd8003 compatable" card the other day, but it wasn't even
recognized (probably the card's fault)  If I had a 3com card to try, I'd do
that too, but the only one I have is a 3c523MC, so . . .
	Please don't think that I'm not happy with Mt. Xinu's product,
in every other regard the package has been wonderful, and my past dealings
with the company and their tech support have been very good.
	Please, if you've got a Mt. Xinu Mach386 binary system working with
a WD/SMC E013EB ethernet card, let me know, even if you don't have any idea
why or how it works.  If I know that someone else at least has one working,
I'll feel a lot better, and be able to concentrate more on finding out *why*
as opposed to *if* . . .


Mark Holden
l00017@eeyore.stcloud.msus.edu

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 92 10:47:38 EST
From:      "william mercer" <william.mercer@canrem.com>
To:        comp.protocols.tcp-ip
Subject:   internet firewalls

Recently, Tim Hall (thall@nyx.cx.du.edu) reprints a dialogue and summary
for Internet firewalls.

As good fortune would have it, there was an article in the February 1992
issue of UNIXWORLD called "Building Internet Firewalls" by Smoot
Carl-Mitchell and John S. Quarterman.

If I were comfortable with the subject, I'd do my best to write what I
could here.  However, since I'm not well-versed in the subject, I
suggest you somehow acquire a copy of the above-mentioned magazine.

From what I can gather from the article, it appears to be well-written.
I know that if my company's LAN were connected to the Internet, I'd be
able to filter a considerable chunk of what I don't want based on this
article, i.e., I wouldn't need any hand-holding.

If anybody else has read this article, please comment.

Jim Carroll (william.mercer@canrem.uucp)
--
Canada Remote Systems  - Toronto, Ontario/Detroit, MI
World's Largest PCBOARD System - 416-629-7000/629-7044

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 92 10:59:53 EST
From:      "william mercer" <william.mercer@canrem.com>
To:        comp.protocols.tcp-ip
Subject:   slow-mo video

Recently, Qiang Lin (qlin@cerc.wvu.wvnet.edu) writes of slow-motion
video over TCP/IP.  I saw this about a year ago at the Toronto Open
Systems Show at the Sun booth.

Hope this tidbit helps.

Jim Carroll (william.mercer@canrem.uucp)
--
Canada Remote Systems  - Toronto, Ontario/Detroit, MI
World's Largest PCBOARD System - 416-629-7000/629-7044

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 92 11:26:22 EST
From:      "william mercer" <william.mercer@canrem.com>
To:        comp.protocols.tcp-ip
Subject:   sourcing rfcs

Although I'm sure that any and all RFCs relating to TCP/IP are available
over the Internet, can anyone suggest a non-Internet way of retrieving
them?  E.g., mail, library, university

If this is going to be a real tome of a book, i.e., unrealistic via air-
or surface-mail, please let me know.  However, I do understand the
importance of being "aware" of whatever I can get my hands on.

If none of the above can be achieved with realistic expectations, please
let me know what the "preferred" way of retrieval is, and I'll scribble
it down for such a time in the future that I may be able to actually FTP
it.

Jim Carroll (william.mercer@canrem.uucp)
--
Canada Remote Systems  - Toronto, Ontario/Detroit, MI
World's Largest PCBOARD System - 416-629-7000/629-7044

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 92 11:26:22 EST
From:      "william mercer" <william.mercer@canrem.com>
To:        comp.protocols.tcp-ip
Subject:   termserver suggestion

Recently Martin Tanner (tanm@seneca.bst.rochester.edu) writes of a
problematic Datability terminal server.

You might want to get 3Com's recent arrival, the CS2100.  Runs TCP/IP,
XNS and OSI simultaneously.  We've got the older model the CS210,
running TCP/IP -or- XNS.  Pretty good box.  No failures among 67
termservers in the past 1.5 years.

Jim Carroll (william.mercer@canrem.uucp)
--
Canada Remote Systems  - Toronto, Ontario/Detroit, MI
World's Largest PCBOARD System - 416-629-7000/629-7044

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 92 11:45:11 EST
From:      "william mercer" <william.mercer@canrem.com>
To:        comp.protocols.tcp-ip
Subject:   atm book by h&h

Recently Fred Goldstein (goldstein@carafe.enet.dec.com) mentions a book,
"Integrated Broadband Networks" by Handel & Huber (pub: Addison-Wesley,
Wokingham, England) which evidently covers Asynchronous Transfer Mode.

Would anybody have the ISBN reference number for this book?

Thanks.

Jim Carroll (william.mercer@canrem.uucp)
--
Canada Remote Systems  - Toronto, Ontario/Detroit, MI
World's Largest PCBOARD System - 416-629-7000/629-7044

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1992 07:47:48 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet Server <-> client flow control

In article <19920314.53120.CST.C506634@umcvmb.missouri.edu> C506634@umcvmb.missouri.edu (Eric Edwards) writes:
>It seems like the ip connection would frequently overflow my buffer unless I
>had an extroardiarily fast serial connection on the other side.

What's an "ip connection"?  IP is a datagram-based network layer protocol.
The TCP transport layer provides connections, though, and I'll assume this
is what you're talking about.

>Perhaps this is not the big problem I am making it out to be?  Does tcp/ip have
>some kind of internal flow control?

Yes.  TCP provides flow control.  TCP informs the sender of how much
buffering capacity it has available all the time.  If your application only
reads data from the TCP buffer as fast as it can send it to the terminal,
then eventually the TCP buffer will fill up and TCP will stop the sender.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 92 08:52:00 GMT
From:      wisner@steller.ims.alaska.edu (Bill Wisner)
To:        comp.protocols.tcp-ip
Subject:   Re: whois

lars@spectrum.CMC.COM (Lars Poulsen) writes:

>While this might be almost true, it does not help the users on
>WORLD.STD.COM, who (apparently unlike NETCOM.COM and WELL.COM) are
>refused routing by ANS/NSFnet.

The World voluntarily restricts their own routing to avoid any
possibility of violating the AUP.

Bill Wisner <wisner@ims.alaska.edu> Gryphon Gang Fairbanks AK 99775
"They have slandered me, they have castigated me, they
have vilified me, yes, they have even criticized me."

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 92 11:58:12 GMT
From:      alexis@panix.com (Alexis Rosen)
To:        comp.protocols.tcp-ip
Subject:   Re: terminal server

tanm@seneca.bst.rochester.edu (Martin Tanner) writes:
>We currently own a datability vcp 1000 terminal server which
>we are very unhappy with - the server crashes 4-5 per week.
>We are interested in suggestions for a replacement for this
>terminal server.

How about getting it repaired? That's not normal behavior. Whatever problems
(actually, just limitations, it's not a mature product yet) the TCP/IP
support has, it's never yet crashed on us.

It's true, our use is relatively light...

---
Alexis Rosen
Owner/Sysadmin, PANIX Public Access Unix, NYC.
alexis@panix.com
{cmcl2,apple}!panix!alexis

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Mar 92 16:12:22 GMT
From:      dc@micronics.com (Darren Croke)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: How to get enet H/W address reliably

In article <1992Mar13.162823.26680@exu.ericsson.se> exudnw@exu.ericsson.se writes:
>Does anyone have a foolproof way to get the Ethernet hardware address of
>a Sun (any model) system?  It can't depend on /etc/ethers or on NIS or DNS 
>services being available.
>

Take a look at the cmu snmp agent code. The file apps/snmp_vars.c 
contains the following -

        /*
         *  the arpcom structure is an extended ifnet structure which
         *  contains the ethernet address.
         */
        klseek(saveifnetaddr);
        klread((char *)&arpcom, sizeof arpcom);
        bcopy((char *)&arpcom.ac_enaddr, EtherAddr, sizeof(arpcom.ac_enaddr));

the kl routines are operating on /dev/kmem using offsets returned by nlist().

Hope this helps.

-- 
 Darren Croke         Micronics Computers
 dc@micronics.com     System Business Group
                          (510) 651-2300

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 92 19:49:09 GMT
From:      a0424986@let.rug.nl (Peter Bouthoorn)
To:        comp.protocols.tcp-ip
Subject:   Telnet-like programs that offer kermit/zmodem instead of ftp?


  Are there any programs that offer telnet facilities,
but use a different protocol for datatransfer, e.g.
kermit/zmodem instead of ftp? The other way around would
be fine too (i.e. a program that offers kermit as download
protocol an has got telnet possibilities :)).
  The idea is to use such a program to connect to and download
from hosts that don't offer ftp but kermit or zmodem etc.
instead (like dubbs at 130.161.180.68). Would it be possible
to connect to these hosts from dos (LAN) and use kermit to
download files??? (I got the feeling it should be possible
in UNIX too: connect to a host and use zmodem to send/
receive files, but i haven't got a clue on how to do this).

Thanks for any help!

Peter Bouthoorn
a0424986@gufalet.let.rug.nl

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Mar 1992 22:28:36 GMT
From:      krasnor@nimios.eng.mcmaster.ca (Carl Krasnor)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet-like programs that offer kermit/zmodem instead of ftp?

ms-kermit from Columbia University supports telnet via packet drivers (as well
as other connection methods). It transfers files using kermit (surprise!). It
provides VT-340 and Tektronix graphics emulations. It is free and can be
downloaded (using the FTP protocol!) from wuarchive.wustl.edu in directory
/mirrors/msdos/kermit, filename mskerm311.zip (I think).

Beame & Whitesides BW220 telnet product supports FTP, kermit and xmodem in the
release I am using (v2.2).

-- 
===============================================================================
Carl Krasnor, Communications Research Lab, McMaster U., Hamilton, Ont. CANADA
krasnor@SSCvax.CIS.McMaster.CA  Tel:(416) 525-9140 x4171  FAX:(416) 521-2922
===============================================================================

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Mar 1992 22:34:07 GMT
From:      rgoldstone@OAVAX.CSUCHICO.EDU (Robin Goldstone)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet-like programs that offer kermit/zmodem instead of ftp?

In article <1992Mar16.194909.10095@let.rug.nl>, a0424986@let.rug.nl (Peter Bouthoorn) writes:
>
>  Are there any programs that offer telnet facilities,
>but use a different protocol for datatransfer, e.g.
>kermit/zmodem instead of ftp? The other way around would
>be fine too (i.e. a program that offers kermit as download
>protocol an has got telnet possibilities :)).
>  The idea is to use such a program to connect to and download
>from hosts that don't offer ftp but kermit or zmodem etc.
>instead (like dubbs at 130.161.180.68). Would it be possible
>to connect to these hosts from dos (LAN) and use kermit to
>download files??? (I got the feeling it should be possible
>in UNIX too: connect to a host and use zmodem to send/
>receive files, but i haven't got a clue on how to do this).
>
There is a new PC Kermit program that supports TCP/IP.  Using this
software, you can make a Telnet connection to a host and then initiate
a Kermit file transfer from that host.  The local (PC) software will 
accept the Kermit packets over TCP/IP.  (I hope I am explaining this
correctly.  Obviously I am leaving out some of the details).  No Mac
version of this (yet ?!).

***********************************************************************
Robin Goldstone, Systems Software Specialist
California State University, Chico  Computing Services
rgoldstone@oavax.csuchico.edu

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Mar 1992 23:36:17 GMT
From:      ray@ipc1.exicom.oz.au (ray)
To:        comp.protocols.tcp-ip
Subject:   SLIP for HP-UX 8.0

Does anybody out there know where to get the source
for a SLIP implementation that runs on HP-UX 8.0 ?
(incidentally the machine is an HP900/360)


mail replies to ray@ipc1.exicom.oz.au

thanks,

ray


-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 92 23:59:58 GMT
From:      gibsoni@ee.mcgill.ca ( irwin roger  gibson )
To:        comp.protocols.tcp-ip
Subject:   Pronet drivers for NCSA telnet or KA9Q


	Hi!  Has anyone found pronet10 drivers that work with NCSA telnet
or Ka9Q?  If so, could you give me the ftp site where I can pick them up.  
Thank you for any help, it would seem that Pronet is not so common.

Irwin R. Gibson
gibsoni@ee470.ee.mcgill.ca
Perv@emf.lan.mcgill.ca

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Mar 1992 08:55:54 -0500
From:      Shikhar Bajaj <sb7c+@andrew.cmu.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: sourcing rfcs

I know of three ways of getting RFCS:

1)  By anonymous FTP from NIC.DDN.MIL

2)  Sending mail to info-server@sh.cs.net.  To get an RFC, the message should
    contain two lines of the following format,

                        REQUEST: rfc
                        TOPIC: <rfc number>

3)  Call NIC at 1-800-235-3155
disclaimer:  All these suggestions come straight out of Appendix 3 of
             Comer's "Internetworking with TCP/IP" vol 1.



Shikhar

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 92 01:27:35 GMT
From:      klassen@sol.UVic.CA (Melvin Klassen)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet-like programs that offer kermit/zmodem instead of ftp?

In article <@> a0424986@let.rug.nl (Peter Bouthoorn) writes:
>
>  Are there any programs that offer telnet facilities,
>but use a different protocol for datatransfer, e.g.
>kermit/zmodem instead of ftp? The other way around would
>be fine too (i.e. a program that offers kermit as download
>protocol an has got telnet possibilities :)).
>  The idea is to use such a program to connect to and download
>from hosts that don't offer ftp but kermit or zmodem etc.
>
The latest versions (V3.11 and V3.12) of MS KERMIT offer this capability,
i.e., talking to a packet-driver instead of to the serial-port!
Thanks to Joe Doupnik!!

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Mar 1992 02:21:51 GMT
From:      gonzzo@duck.WPI.EDU (Javier Gonzalez)
To:        comp.protocols.tcp-ip
Subject:   HELP!: Weird problem using UDP

I hope someone can help me with this:

I'm using udp for communication processes in different machines connected through 
Ethernet. Every time I get a datagram in one of the hosts, the process needs to
know who sent it, so I use "recvfrom()" to obtain the network address. Everything
seems to work ok,but once in a while, I receive datagrams with a weird address
(always the same, 3.0.0.0). The information on the datagram seems to be ok, only
the source address is bad. As far as I know, although udp does not provide checksum
(it's optional), ip has a checksum field that covers both addresses, source and
destination, soit can't be because an error in the transmission. Thus, I don't know
if there is something wrong with the way I set up the sockets or what. Below I include
the part where I set up the socket and I read the information to see if someone has a
clue of what is wrong.

Thanks in advance.
___________________________________________
Javier Gonzalez
Electrical Engineering Department
Worcester Politechnic Institute
Worcester, MA 01609

E_mail: gonzzo@ee.wpi.edu



                   	.
                   	.
                   	.
                    
  if((Socket = socket(AF_INET,SOCK_DGRAM,0)) < 0)
    err("!couldn't open the socket\n");

  bzero((char *) &my_addr,sizeof(my_addr));
  my_addr.sin_family = AF_INET;
  my_addr.sin_port = htons(PORT);          /* PORT = 8000 */
				/* All the hosts use the same port number */
  my_addr.sin_addr.s_addr = htonl(INADDR_ANY);


  if (bind(Socket,(struct sockaddr *)&my_addr,sizeof(my_addr))< 0) { 
    err("!main:couldn't bind mi address\n");
  }

  if(fcntl(Socket,F_SETFL,O_NDELAY)< 0) exit(0);

			.
			.
			.


In another procedure that it is called every time I want to know if
there is a datagram ...

  struct sockaddr_in fromaddr;
  int addrlen;
			.
			.
			.

  while((num = recvfrom(Socket,buffer,(int)MAXLENPACK,(int)0,
			(struct sockaddr *)&fromaddr,&addrlen)) > 0){

	handle the datagram ...
	

  }

For sending a datagram I use ..

void
send_list(char *message,int len,char *name)
{
  struct sockaddr_in rec_addr;
  struct hostent *hp;

 /* get the address of the remote host*/
  if ((hp = gethostbyname(name)) == NULL) {
    err("Please, the host is wrong!\n");
  }

  rec_addr.sin_family = AF_INET;
  rec_addr.sin_port = htons(PORT);
  bcopy(hp->h_addr,(char *)&rec_addr.sin_addr, hp->h_length);
  sendto(Socket,message,len,0,(struct sockaddr *)&rec_addr,sizeof(rec_addr));
}








-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Mar 1992 02:57:33 GMT
From:      eengelke@sail.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Pronet drivers for NCSA telnet or KA9Q

gibsoni@ee.mcgill.ca ( irwin roger  gibson ) writes:
>
>	Hi!  Has anyone found pronet10 drivers that work with NCSA telnet
>or Ka9Q?  If so, could you give me the ftp site where I can pick them up.  
>Thank you for any help, it would seem that Pronet is not so common.
>
>Irwin R. Gibson
>gibsoni@ee470.ee.mcgill.ca
>Perv@emf.lan.mcgill.ca

Yes, in fact we wrote them.  Here are the raw specs: u
  - 2 x performance of every Ethernet packet driver we have tested
  - up to 850 Kbytes/s per node raw data rate sustained
  - compatible with Clarkson, NCSA, FTP, B&W, Wollongong, PC-ROUTE, KA9Q
    MS-Kermit, and of course WATTCP which we also wrote and our tsr BOOTP
  - emulates Ethernet (Class 1) on all above software
  - same driver supports 8 bit, 16 bit, MC card and autoconfigures
  - well tested - used every day as base of our LAN/WAN 

Get Packet driver version of PCRoute and install with one Ethernet card
and one pronet card and appropriate drivers and it all works magically.

FTP from: sunee.uwaterloo.ca in pub/wattcp/pronet.zip

Erick

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 92 03:58:12 GMT
From:      tong@aussie.enet.dec.com (Benny Tong)
To:        comp.protocols.tcp-ip
Subject:   Re: terminal server


In article <1992Mar12.183137.1365@galileo.cc.rochester.edu>, tanm@seneca.bst.rochester.edu (Martin Tanner) writes...
> 
>We currently own a datability vcp 1000 terminal server which
>we are very unhappy with - the server crashes 4-5 per week.
>We are interested in suggestions for a replacement for this
>terminal server.

Have you reported this problem to Datability?
If you are still interested in a replacement, you may take a look at Digital's
DECserver 300 - a Local LAT/TCP/IP terminal server and
MUXserver 380 - a remote LAT/TCP/IP terminal server with multiplexers on up to
		8 synchronous links to 16 remote sites.


Benny

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 92 17:16:27 GMT
From:      shiao@ans.net (Dennis Shiao)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   Telnet Flow Control


*+---------------------------------------------------------------------+*
Environment: 
   RS/6000 530, AIX 3.1.5 
*+---------------------------------------------------------------------+*
Problem: 
   When telnet'ing from a 530 to 530 (or 320), Emacs takes C-s and C-q
to mean Turn Off/On flow control.
*+---------------------------------------------------------------------+*
Observations:
 o The problem does not surface when using rlogin. I think this is 
   because the client is put into raw mode during the connection
   establishment, and "the START and STOP characters are not processed
   locally, but are sent as any other character to the remote server."

 o The problem does not surface when connecting with telnet via kermit.
   Ex.:
        C-Kermit>set host hostname
        C-Kermit>connect

   This *does* introduce another problem; you now need to send two ESC's
   to get one across ! (This new problem does not surface when going from
   the 530 to a Sun). I put kermit in debug mode, and noticed that no flow
   control negotiation happens between the telnet client and server.

 o Playing with stty (modes ixon, ixany, ixoff) did not work.

 o The Emacs FAQ says:
      What do I do if my terminal is sending C-s and C-q for flow control and
      I can't disable it?
   
      Use this piece of Emacs Lisp:
         (set-input-mode nil t)

   This did not work.

 o It appears that AIX telnet/telnetd do not implement RFC 1080, "Telnet Remote
   Flow Control Option".

 o The problem also arises when using NCSA Telnet from a Mac IIci to the
   530 or 320.
*+---------------------------------------------------------------------+*
Questions:
 o What can be done ?

 o Are there any other ways to disable flow control ?

 o Do any telnet clients or servers implement RFC 1080 ?

 o Why does flow control function the way I want it to when using telnet
   from within kermit ?
*+---------------------------------------------------------------------+*

Thanks in advance for any responses/solutions !

-Dennis.
--
Advanced Network & Services, Inc.    E-Mail: shiao@ans.net
100 Clearbrook Road                  Office: (914) 789-5340
Elmsford, NY 10523		     Fax:    (914) 789-5310

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 92 18:01:01 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: atm book by h&h



 >Recently Fred Goldstein (goldstein@carafe.enet.dec.com) mentions a book,
 >"Integrated Broadband Networks" by Handel & Huber (pub: Addison-Wesley,
 >Wokingham, England) which evidently covers Asynchronous Transfer Mode.
 >
 >Would anybody have the ISBN reference number for this book?
 Jim,

Review of "Integrated Broadband Networks - An Introduction to
ATM-Based Networks" by Rainer Handel and Manfred N. Huber,
(ISBN 0-201-54444-X, 1991, 230 pp., Addison-Wesley)

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 92 19:19:31 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: whois

lars@spectrum.CMC.COM (Lars Poulsen) writes:
>>While this might be almost true, it does not help the users on
>>WORLD.STD.COM, who (apparently unlike NETCOM.COM and WELL.COM) are
>>refused routing by ANS/NSFnet.

In article <1992Mar16.085200.17461@raven.alaska.edu>
   WIsner@steller.ims.alaska.edu (Bill Wisner) writes:
>The World voluntarily restricts their own routing to avoid any
>possibility of violating the AUP.

I'm confused now. It is my impression that Barry Shein on behalf of WORLD
has been complaining that academics users cannot telnet and FTP to WORLD
due to NSF's AUP.

If WORLD deliberately and unilaterally refrains from routing packets to
NSF, it seems that there would be no grounds for such complaints.
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Mar 1992 21:56:55 GMT
From:      navare@tss.com (Prashant Navare)
To:        comp.protocols.tcp-ip
Subject:   Context Switches, memory copies and UDP

Teknekron implements a whole application protocol stack on top of UDP for its
applications. The protocol stack is divided between a daemon responsible for
packet transmission and reception and the application itself. The application
uses shared memory to communicate with the daemon. So much for the background...

On Sun SPARCs I have noticed the following performance figures. I am now trying
to find an explanation for them:

Transmission rate for 64 byte sized packets :

Using only the daemon : 3000 pkts/sec.

Using an application which sends the packet to the daemon via shared memory and
then the daemon transmits the packet on the network:  400 pkts/sec

Thus there is a tremendous drop in performance. For small sized packets (like
64 bytes) there would be one context switch per transmitted pkt. In addition,
there are the following memory copies going on (at least):

application process space -> shared memory

shared memory -> daemon process space

Do the context switches and the memory copies add up to the big drop in performa
nce?

Thanks in advance for your replies...

--Prashant


-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Mar 92 22:44:52 GMT
From:      brad@bradley.bradley.edu (Bradley E. Smith)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: How to get enet H/W address reliably

one could always use 'ping XXX.XXX.XXX.XXX' then use arp (or arpbypass
on AT&T SVR4) to get mac address, but if you go through a router, you
get the router's mac address.

-- 
Bradley Smith			 brad@bradley.edu ---  309-677-2337
Network & Technical Services @ Bradley University, Peoria, IL

"It's amazing how much scrap metal you get from 4 cans of beer"

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 92 23:36:38 GMT
From:      markr@seqp4.sequoia.com (Mark Roddy)
To:        comp.protocols.tcp-ip
Subject:   source vendors


I'm trying to compile a list of TCP-IP source code vendors and could
use your help. 

Minimal requirements:
	USL SYSV.4 DDI/DKI compatibility - i.e. a streams protocol stack.
	Conformance to RFC 1122/1123.
	C language (obviously) preferably ANSI C.

Vendor information, i.e. name address phone email, plus any reference
information (good bad or ugly) would be helpful.

Please email responses. I will summarize on this group.

Thanks in advance for your help.

-- 
-Mark Roddy
Sequoia Systems, Inc.          (508) 480-0800 x1284
markr@seqp4.sequoia.com        m2c!seqp4!markr

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 92 09:32:01 GMT
From:      rh0083b@medtronic.COM (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: sourcing rfcs

In article <1992Mar16.1070.7796@dosgate> "william mercer" <william.mercer@canrem.com> writes:
>Although I'm sure that any and all RFCs relating to TCP/IP are available
>over the Internet, can anyone suggest a non-Internet way of retrieving
>them?  E.g., mail, library, university

You can get RFCs via E-mail from the NIC server. Send mail to
service@nic.ddn.mil with the word help in the body. I got my RFC collection
from there.

Regards,
-Roger

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 92 10:54:35 GMT
From:      anderl@kommu.UUCP (Horst Anderl)
To:        comp.protocols.tcp-ip
Subject:   ARCNET TCP/IP driver for SCO-UNIX

I am looking for a TCP/IP-Driver (IP-Interface) for ARCNET boards (SMC
compatible) for SCO-ODT (SCO-UNIX).

Our project is based on SCO-ODT (SCO-UNIX) and we are using TCP/IP and Berkely
Sockets in our application for communication.

For the connection to our MS-DOS based Terminal we use at the moment our
"home made" ARCNET Driver with "home made" protocol.

In the future we want to dump the "home made" stuff and use TCP/IP and Berkely
Sockets also on the ARCNET.

I am looking forward to receive a lot of replies, thanks in advance

Horst Anderl

-- 
NAME   Horst Anderl
EMAIL  anderl@kommu.erls01.siemens.de  {uunet|...}!unido!kommu!anderl
SMAIL  Siemens AG, ANL A432/WF, Postfach 4848, D-8500 Nuernberg, Germany
PHONE  +49-911-895-3998, +49-911-895-4127, +49-9133-5356

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 92 11:53:29 GMT
From:      anderl@kommu.UUCP (Horst Anderl)
To:        comp.protocols.tcp-ip
Subject:   ARCNET driver for PC/TCP (MS-DOS)?


I am looking for a TCP/IP-Driver (IP-Interface) for ARCNET boards (SMC
compatible) for MS-DOS with PC/TCP from FTP.

For the connection to our SCO-ODT based server we use at the moment our
"home made" ARCNET Driver with "home made" protocol.

In the future we want to dump the "home made" stuff and use TCP/IP and Berkely
Sockets also on the ARCNET.

I am looking forward to receive a lot of replies, thanks in advance

Horst Anderl

-- 
NAME   Horst Anderl
EMAIL  anderl@kommu.erls01.siemens.de  {uunet|...}!unido!kommu!anderl
SMAIL  Siemens AG, ANL A432/WF, Postfach 4848, D-8500 Nuernberg, Germany
PHONE  +49-911-895-3998, +49-911-895-4127, +49-9133-5356

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 92 14:12:03 GMT
From:      ks@orchestra.ecn.purdue.edu (Kirk Smith)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Dialup PPP

I have put together a new version of dialup on demand TCP/IP.
We use it to support a number of remote sites with fixed IP addresses
and use it as a full function TCP/IP interface that establishes the
actual dialup connection when necessary to transfer packets..

This distribution can be retrieved from phoenix.acn.purdue.edu via anonymous
ftp in the file etc/dp.2.0.tar or etc/dp.2.0.tar.Z.

Basically, this distribution includes:

	PPP code from CMU
	Sun PPP support from Clarkson
	TCP/IP Header compression from Van Jacobson
	Dialup on demand support from BBN

All this stuff was made to work together with the following additions
and enhancements:

 Expanded (backwards compatible) dial script syntax for quicker error handling.

 Uucp locking is compatible with Sun conventions.

 New configuration file allows setting of several options and timeouts.

 A modem rotary supports a list of modems to be used in rotation.

 Timeout mechanism has been expanded including the following timeouts.

    callwait:   time to wait for a call to complete
    failedcall: time to wait before trying another call
    inactivity: disconnect after no packets in A seconds.
    tcp_close:  disconnect C seconds after last TCP connection
                    is closed and no packets.
    non_tcp:    disconnect U seconds after last non-TCP packet
                    given no activity and no TCP connections.

 We are using the same modems for dial in and dial out with good results.

This version attempts to combine the "best" of the available packages
with some new innovations.  The main serious drawback is that it only
works on SunOS 4 (Solaris 1.0).  If anyone wants to work on other ports,
I would be glad to include your work back into the distribution.

I don't have time to support this software in any way.  However,
I would be glad to here of any fixes for this software, and will try
to incorporate such fixes into future releases.  There is very little
documentation, so this may not be the best route for the faint hearted
system administrator.

Companies sell products that do things similar to this.  I believe that
this software incorporates some unique features and has value in itself.
However, if you want a supported product, you might want to shop around.
Morningstar is one company that I know of (morningstar.com).

If you want on a mailing list for info about bug fixes or new releases,
just send me your email address.

                                Kirk Smith
                                Purdue Agricultural Computer Network
                                ks@acn.purdue.edu

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Mar 92 15:43:11 GMT
From:      hughes@logos.ucs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip,vmsnet.mail.misc,vmsnet.networks.tcp-ip.misc
Subject:   IUPOP3, VMS POP3 server

IUPOP3 Version 1.7, a POP3 server for VMS, is now available for 
anonymous ftp on logos.ucs.indiana.edu (129.79.16.150).  This
version supersedes Version 1.6a.

Look in either of these directories:

  /pub/iupop3/v1.7/files       - individual files 

  /pub/iupop3/v1.7/vms_share   - VMS_SHARE format

IUPOP3 is compatible with the latest release of Digital's UCX, 
TGV's Multinet, and Wollongong's WIN/TCP for VMS.

Questions, problems, or comments about IUPOP3 can be sent via
Internet mail to iupop3@indiana.edu, or Bitnet mail to IUPOP3@IUGATE.

 //====================================================================\\
||     Larry J. Hughes, Jr.       ||         hughes@indiana.edu         || 
||      Indiana University        ||                                    ||
|| University Computing Services  ||  "The person who knows everything  ||
||  750 N. State Road 46 Bypass   ||     has a lot to learn."           ||
||    Bloomington, IN  47405      ||                                    ||
||       (812) 855-9255           ||  Disclaimer: Same as my quote...   ||
 \\=====================================================================//


-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Mar 1992 16:49:12 GMT
From:      jagunich@skyler.mavd.honeywell.com
To:        comp.protocols.tcp-ip
Subject:   AGR TCP/IP "Hands-on" class

I am considering attending a "Hands-on Internetworking with TCP/IP" class
given by ARG (American Research Group).  The instructor is Russ Carleton
who is the Founder and Chairman of the Interlink Group.

If you have attended this class or know anything about the instructor please
comment...

Barb Jagunich
Honeywell
MAvD
jagunich@skyler.mavd.honeywell.com

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Mar 92 23:54:18 EST
From:      max@underg.UUCP (Max Cray)
To:        comp.protocols.tcp-ip,comp.org.eff.talk,news.newusers.questions,ri.sysadmin
Subject:   SLIP Access to the Internet for Individuals

In article <VmX9eB4w164w@underg.UUCP> I wrote:
 
>   Is there a service where you can call a 1-900 number and connect to the 
>Internet using the SLIP protocol? I am thinking of something like UUNET's 
>uucp service, but for SLIP instead. Could someone mail me info if this 
>service exists, or if there is a reason why is does not exist please send me 
>mail telling me why this is a bad idea? Thank you in advance.

--

From: johna@mobdig.ncal.mobdig.com (John Antypas)

It's a nice idea but:

1. For $5/hour Cerfnet offers Dial-n-cerf.  That's 80 cents/minute. 
   Not too bad.

2. PSI offers DCS for $175/month flat rate.  At 24hrs/day (we can),
   that's 25 cents/minute!

3. For an additional $75 PSI even gives you a private phone nubmer to
   call -- no busy signals and a perminant IP address.  (You can be 
   reached over your slip link)

-- 

From: dave@msb.com (Dave Lockwood)

Nope...terrible idea.  You don't want to set something like that up.

Because I want to do it first. :-)

Seriously, it's a great idea.  There are plenty of suck...uh, customers
out there who would pay <insert magic figure here> per minute for SLIP
access.  I'm hoping to set up a x/month system with SLIP access to the
Internet in Riverside, CA.

-- 

From: mickelp@prism.cs.orst.edu (Paul M. Mickel )

Tymnet allows you to do this, but I don't have details on doign this. If you
can find out more, let me know.

[I was not able to verify this. If anyone has more info please let me know.]
--

From: uunet!cerf.net!lanciaj (John Lancia)
Subject: Re: DIAL n' CERF
Cc: lanciaj@cerf.net

Max, starting March 2 we are offering an #800 dial up service.
Anyone can use this service, it is $20 a month and $10 an hour
connect time.  Until April 1 the $50 install charge will be 
waived.

Max,  The DIAL n'CERF connection for individuals is a slip connection.
This service provides full Internet access.  You get e-mail, FTP, Telnet
Anonymous FTP, News feeds and anything else you can get on the Internet.

--

Although I was not able to find a service exactly what I was looking for,
Dial n' Cerf from Cerf-Net seems to be pretty close. As far as I can tell
it is the only service that allows net access via SLIP in small increments
making it affordable for the individual. If you call a non-800 number the
charge is only $5 an hour. Also the install charge waiver has been pushed
back to April 15th. There are other plans available, too.

Call 1(800)876-CERF or e-mail: help@cerf.net

I am in no way affiliated with this company. I have requested an account
and will post my expiernces, if there is interest.


--
underg!max@uunet.uu.net (Max Cray)
The Underground Computing Foundation BBS  -=-  (401) 847-2603  -=-  9600 v.32

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Mar 92 23:55:12 EST
From:      max@underg.UUCP (Max Cray)
To:        comp.protocols.tcp-ip,ri.comp.tech
Subject:   Good Book on TCP/IP

Reference: <N8oBgB1w164w@underg.UUCP>

I posted the following request:

> Can someone recommend a good book, on tcp/ip networking from a
> users/sysadmin's (not programmer's) point of view? Please e-mail replies.
> Thank you.

--

From: jmb@ideas.com (Jonathan M. Bresler)

THE two books are:

Internetworking with TCP/IP
Volume I Principles, Protocols, and Architecture
Douglas E. Comer
1991, 2nd Ed. Prentice-Hall

Internetworking with TCP/IP
Volume II Design, Implementation, and Internals
Douglas E.Comer and David L. Stevens
1991, Prentice-Hall

also get the Network Reading List: TCP/IP, UNIX, and Ethernet
from UTnet Network Information Center, Univ.of Texas at Austin
utnet@utexas.edu, availble thru anonymous ftp.

--

From: rory@wri.com

The Internet.  By Douglas Comer.  Great book. 

--

From: Marcus Hayes <mah@DIALix.oz.au>

Internetworking with TCP/IP and NFS in a Unix Environment. Written by
Michael Santifaller, Addison-Wesley 1991.
Gives info on TCP/iP & NFS at a low level, but details the daemons involved
and what they all do.


--
underg!max@uunet.uu.net (Max Cray)
The Underground Computing Foundation BBS  -=-  (401) 847-2603  -=-  9600 v.32

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 92 20:58:06 GMT
From:      ejbehr@rs6000.cmp.ilstu.edu (Eric Behr)
To:        comp.sys.mac.apps,comp.sys.mac.misc,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Notes on MacTCP configuration

A new, updated version of my notes on MacTCP is available on
sumex-aim.stanford.edu, in /info-mac/report/mac-tcp-info.txt. 
If you don't know how to use anonymous ftp, or can't use it
for other reasons, drop me a line and I'll e-mail the file to
you.

Since I don't always have time to read news, and our expiration
limit is short, use e-mail to get in touch with me rather than
posting a followup.

The notes describe in some detail the process of configuring
MacTCP, and list some Macintosh applications which make use of
he MacTCP driver. The file is about 40K.

Please send comments, requests, suggestions to:
   behr@math.ilstu.edu    or   ejbehr@rs6000.cmp.ilstu.edu.


-- 
Eric Behr, Illinois State University, Mathematics Department
Internet: ejbehr@rs6000.cmp.ilstu.edu    Bitnet: ebehr@ilstu

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 92 21:43:06 GMT
From:      marjo@hpindda.cup.hp.com (Marjo Mercado)
To:        comp.protocols.tcp-ip
Subject:   BSD 4.4 Telnet

Hello,

How is Telnet on BSD 4.4 different from BSD 4.3?

Thanks,

Marjo Mercado
(408)447-2826

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Mar 1992 22:29:59 GMT
From:      whetten@cs.uiuc.edu (Brian Whetten)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP error.  Please Help!

We are looking at the idea of using TCP sockets as reliable datagrams.
i.e. For each message, you set up a socket, pass through the message, and 
close the socket down.  In our test programs, however, doing this repeatedly
(besides being rather slow) causes an error in both SunOS 4.1.1 and HPUX 7.0.

On the 2000th message in SunOS, the system puts up a "mbuf map full"
message to the console window and dies hard.  Power off is needed to reboot.

In HPUX, every 240 messages or so the machine puts up a "NFS error 2025"
message, freezes for approx. 40 sec., and then puts through another 240
messages.

Help please?  Is this a bug in both operating systems?  Has anyone
ever figured out how to use TCP this way?  I have successfully implemented
this type of a thing using NetBios on IBM PC's, and it works very well.

Thanks, Brian


whetten@cs.uiuc.edu

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 92 23:54:56 GMT
From:      ddl@burrhus.harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP error.  Please Help!

In article <1992Mar18.222959.11474@m.cs.uiuc.edu>, whetten@cs.uiuc.edu (Brian Whetten) writes:
| We are looking at the idea of using TCP sockets as reliable datagrams.
| i.e. For each message, you set up a socket, pass through the message, and 
| close the socket down.  In our test programs, however, doing this repeatedly
| (besides being rather slow) causes an error in both SunOS 4.1.1 and HPUX 7.0.
| 
| On the 2000th message in SunOS, the system puts up a "mbuf map full"
| message to the console window and dies hard.  Power off is needed to reboot.
| 
| In HPUX, every 240 messages or so the machine puts up a "NFS error 2025"
| message, freezes for approx. 40 sec., and then puts through another 240
| messages.
| 
| Help please?  Is this a bug in both operating systems?  Has anyone
| ever figured out how to use TCP this way?  I have successfully implemented
| this type of a thing using NetBios on IBM PC's, and it works very well.

	This is a common problem for programs that quickly create
and destroy many tcp/ip connections under BSD-derived systems.  Sockets
accumulate in TIME_WAIT and use up all available memory.  A simple
kludge that avoids this behavior on many systems is to set the linger
option to "on" with a linger time of 0 before closing the socket.  The
close then results in a "hard" tcp drop and an immediate recovery of
memory.  Of course, this can break the protocol...

				Dan Lanciani
				ddl@harvard.*

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 92 01:08:07 GMT
From:      vsp@hpcupt3.cup.hp.com (V Shankar Prasad)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP!: Weird problem using UDP

>/ hpcupt3:comp.protocols.tcp-ip / gonzzo@duck.WPI.EDU (Javier Gonzalez) /  6:21 pm  Mar 16, 1992 /
>I'm using udp for communication processes in different machines connected through 
>Ethernet. Every time I get a datagram in one of the hosts, the process needs to
>know who sent it, so I use "recvfrom()" to obtain the network address. Everything
>seems to work ok,but once in a while, I receive datagrams with a weird address
>(always the same, 3.0.0.0). The information on the datagram seems to be ok, only
>the source address is bad. As far as I know, although udp does not provide checksum
>(it's optional), ip has a checksum field that covers both addresses, source and
>destination, soit can't be because an error in the transmission.
 
>Javier Gonzalez
>E_mail: gonzzo@ee.wpi.edu

[ .. some source deleted .. ]

>For sending a datagram I use ..
>
>void
>send_list(char *message,int len,char *name)
>{
>  struct sockaddr_in rec_addr;
>  struct hostent *hp;
>
> /* get the address of the remote host*/
>  if ((hp = gethostbyname(name)) == NULL) {
>    err("Please, the host is wrong!\n");
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  }
>
>  rec_addr.sin_family = AF_INET;
>  rec_addr.sin_port = htons(PORT);
>  bcopy(hp->h_addr,(char *)&rec_addr.sin_addr, hp->h_length);
>  sendto(Socket,message,len,0,(struct sockaddr *)&rec_addr,sizeof(rec_addr));
>}
>----------

Here is a possibility.  Does your err() routine return to the caller ? Or
does it do an exit() or longjmp() or something which prevents returning ?
If it returns, you will fall through and try to transmit to an address
picked off a NULL ptr.  Though why should that result in a successful
transmission with a meaningless source address ?  Maybe because
hp->h_length is also invalid.  Anyway, just check this out which may be
a future problem even if not the cause of your current difficulty.

By any chance is your network address "3.X.Y.Z" ?   That might hold
a clue.

Sorry - I see that I am not of much use.  Hope the other responses will
help you better.

Shankar Prasad
vsp@cup.hp.com

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 92 01:08:09 GMT
From:      ejp@bohra.cpg.oz.au (Esmond Pitt)
To:        comp.os.os2,sco.opendesktop,comp.protocols.tcp-ip
Subject:   IBM TCP/IP problems (2)

Assistance please. I am running IBM 1.3EE (but without Comms Manager,
so really 1.3 SE) and IBM TCP/IP 1.2. Problems:

1. I used to run MS Lan Manager (NETBIOS/NETBEUI) with MS TCP/IP for
OS/2 (beta). This worked OK, but the latter doesn't have an X server or
NFS, and its TELNET is U/S, so I got IBM's TCP/IP. This runs fine on
its own but I want to use Lan Manager too. I have read the NDIS
documentation and indeed have got my CONFIG.SYS to the point where (i)
both protocol stacks load without complaint; (ii) NET START WORKSTATION
works; (iii) NET LOGON works; and (iv) I can use the Lan, but somewhere
along the way TCP/IP stops working.

Q. Why? If anybody has any experience with such a setup I'd be grateful
for any assistance.

2. With or without LanManager, I have a separate problem. The other end
of the TCP/IP link is an SCO Unix box running Lan Manager for Unix
(NETBIOS) and TCP/IP. This used to work fine talking with my OS/2 box
runnning MS LanMan and MS TCP/IP. Now, IBM TCP/IP for OS/2 talks to the
SCO box OK but the SCO box keeps printing 'unexpected dvmi' messages
(or something like that - I'm presently 4.5 miles from both machines).
These appear about every 10 seconds on all console screen session and
make the console unusable.

Q. Why? Once again, any assistance appreciated.

Naturally I will consult all the vendors concerned; just in case they
all handball me to the others, I though I'd ask here too.

Replies by e-mail please: I don't read all these groups.

Thanks for any assistance.

-- 
Esmond Pitt, Computer Power Group
ejp@bohra.cpg.oz

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Mar 1992 02:22:54 GMT
From:      johnk@gordian.com (John Kalucki)
To:        news.groups,comp.protocols.tcp-ip,comp.dcom.lans,comp.dcom.lans.misc,comp.sys.sun.admin
Subject:   RFD: comp.dcom.servers

Proposal:
--------

Creation of new newsgroup comp.dcom.servers.

Due to the rapid growth of communication servers in the industry and the
lack of a newsgroup to discuss their merits, pitfalls, and configuration
I'd like to begin discussion on a new newsgroup, comp.dcom.servers.


Status:
------

Unmoderated


Charter:
-------

To provide a central newsgroup for discussion about communication
servers such as terminal servers, network print servers, stand
alone SLIP/PPP/Appletalk servers, dial on demand routers, protocol
translators, etc.

Topics likely to be discussed in comp.dcom.servers would include: 
	* Functionality of products
	* Problem solving and appropriate solutions
	* Interoperability
	* General product selection issues, (price, support, etc.)
	* Impressions and debate on merit and drawbacks
	* Ideas/desires for new products and functionality

A monthly FAQ would also be posted containing manufacturers of such
products and how to contact them. Hopefully this will end the endless
messages requesting information of this sort on comp.protocols.tcp-ip
and elsewhere.


Rationale:
---------

Currently there is no central location to discuss this growing
field.  Messages requesting information about this type of product
can be found in such widely dispersed locations as
netblazer-users@telebit.com, comp.dcom.lans, comp.protocols.tcp-ip,
comp.protocols.ppp, comp.dcom.cisco, comp.unix.admin and comp.sys.sun.admin.

Cisco, Xyplex, Lantronix, Digital, Emulex, Livingston, Telebit,
Shiva, Milan and many other vendors provide products of these types,
many with overlapping and/or complimentary functionalities. Splitting
newsgroups along vendor, or communication server type inhibits
relative comparison of product merit and also inhibits problem solving
involving two or more different products.

Follow Up:
---------
Please follow up all discussion to news.groups.



-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 92 07:59:01 GMT
From:      he@edfd.uucp (Hans-Joachim Heurich)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.sgi,comp.sys.sun.wanted,comp.sys.sun.misc,ieee.pcnfs
Subject:   Telnet connection over ethernet/tcp/ip to an IBM AS/400

What we want to do is to connect from a DOS-PC with Sun's PC-NFS or a
Unix workstation (Sun/Silicon Graphics) to an AS/400 using
Ethernet/tcp/ip and the application telnet. Does a 5250 terminal
emulation exist for Sun's PC-NFS and for telnet (SunOS/IRIX)?

HJ

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Mar 1992 08:00:39 GMT
From:      eletanjm@nuscc.nus.sg (Tan Jin Meng @ NUS)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: TCP Implementation on an Ethernet card

: 
: >>miw@brolga.cc.uq.oz.au (Mark I. Williams) writes:
 
: >>>I have an application whereI need to transmit data at a rate of about
: >>>1.5-2 Mbit/sec over ethernet, preferably using a reliable transport
: >>>protocol such as TP4/CLNP, TCP/IP, or even XTP. The data stream will be
: >>>produced by a card sitting in a workstation that may be as slow as an
: >>>IBM PC/AT, so obviously it is unlikely that the workstation will handle
: >>>these speeds very well in software.
: 

You could try the following ... Put a fast SCSI host adapter on your AT
machine and write the software to emulate the host adapter as a hard
disk. 

Requirements :
	A fast SCSI host adapter
	The ability to program the host adapter
	Knowledge about SCSI protocols

Advantage :
	It appears as a hard disk to the receiving side.
	It may be FUN!

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 92 09:23:25 GMT
From:      cgd@ecmwf.co.uk (Dick Dixon)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: How to get enet H/W address reliably

>one could always use 'ping XXX.XXX.XXX.XXX' then use arp (or arpbypass
>on AT&T SVR4) to get mac address, but if you go through a router, you
>get the router's mac address.

Of course, you can always ask another machine on the net...  This works, in
SunOS 4.1.1, so long as you don't have restrictions on remote shelling to other
machines:

rsh `arp -a | sed -e "s/\([A-Za-z0-9]* \).*/\1/p" -e q` arp -a | \
grep `hostname` |sed -e 's/.* \([0-9a-f:]*\)$/\1/p'

It looks in the local arp cache for a host to rsh to, asks that host for its arp cache, and
greps its own host name out of that.

The proper way is to look up the right symbol in the kernel image, of course.  Does anyone
have a fix that makes the CMU SNMP code report correct ethernet addresses rather than
zeroes?

			Dick Dixon

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 1992 23:09:29 -0500
From:      wb8foz@mthvax.cs.miami.edu (David Lesher)
To:        comp.protocols.tcp-ip,comp.unix.ultrix
Subject:   restart delay

I telnet to this host via this long, erratic, route called the backbone
:-] by some.  On an all too regular unschedule, things grind to a
halt.  Later, whatever is wrong goes into remission, and things start
up again. The problem is, "later" is often minutes later. (This gets
old fast.)

The strange thing is that whatever is "wrong" does not stay that way
for long. I can break out at the terminal server, and open a NEW
session to the same host, over the same path (There is only one
possible route for part of the trip, and yup, there's where things
break....) even while the existing one is still dead.

Now, helpful netters have explained why this is. But my remaining
question is: Why the dickens is the restart time for the stalled
existing session often *minutes* in length?  Is there anything
changeable to reduce this? I'm crossposting this to comp.unix.ultrix
because it's a duckstation II w/ 3.0, and somewhere I picked up a rumor
that this was an Ultrix habit. True?

Enlightenment, please.
-- 
A host is a host from coast to coast.....wb8foz@mthvax.cs.miami.edu 
& no one will talk to a host that's close..........................
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Mar 1992 15:11:55 GMT
From:      hsohn@sraopus.sra.com (Hyung Sohn)
To:        comp.protocols.tcp-ip
Subject:   RPC using TCP/IP

Apologies if this is an FAQ.

Actually, first, can some one point to where I can get the list of FAQ?

Now for the post.  We have a client/server application running on our
system.  The client's are PC's and the servers are Unix machines.  We're
using a third party RPC product for communication between the clients and
the servers.

What I would like to do is to find out if we can replace the third party
RPC product, and implement our own RPC at the TCP/IP level.  There are
only about 12 types of RPC calls between clients and servers so the amount
of recoding shouldn't be all that much.

The reason that I'm looking at RPC implementation at the TCP/IP level is
to keep the cost down and give us flexibility in choosing the hardware
involved.  I maybe wrong on this assumption, but most network
card builders seem to support TCP/IP.  If we implement RPC at a level
above TCP/IP, it may make our effort less but we'll be limited to say, PC-NFS
for example.

So, I would like to have opinions as to the viability of the idea, and
any pointers to literatures, people with experience, anything.  I would
like to get some feasibility study going.

Thanks for all your help.

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 92 15:57:56 GMT
From:      wscott@ecn.purdue.edu (Wayne H Scott)
To:        comp.unix.questions,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.sun.misc
Subject:   Re: file transfer: FTP or FTP ?

sopena@gsi.fr (Christophe Sopena) writes:


>Is there an alternative to FTP for transferring files between PC's and UNIX machines,
>over TCP/IP/SLIP networks ?
>The file transfer must be performant, secure, and above all must be able to restart the transfer
>in case of problem (line cut for exemple). I mean restart from the point where the problem 
>occured, of course.
>Any product welcome (shareware, commercial, FTP with implemented REST command...)
 
>Have a nice day
 
>Christophe Sopena
>GSI Telematique
>25 bd de l'amiral Bruix
>75016 Paris
 
>E-mail : sopena@gsi.fr

look at FSP

FSP is a very nice file transfer program that was posted to comp.source.misc
a while back. (or was it alt.sources)

FSP is connectionless, and if a line goes down between you and the server
all you notice is that the transfer does not finish until after the 
line comes back up.

FSP is also VERY easy on the server machine.  There is only one process running
no matter how many people are requesting files.  So 100 people all requesting a
30 meg files will not effect the machine too much.  (However the transfer rates
will get slower and slower..)

FSP is designed to replace Anonymous FTP so there are that many controls over
who can read files.  (You don't log into any account on the host machine.)

If you can't find FSP or want more information send me e-mail.

Wayne Scott
wscott@ecn.purdue.edu


-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 92 16:46:32 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP error.  Please Help!

In article <1992Mar18.235456.27357@burrhus.harvard.edu> ddl@burrhus.harvard.edu (Dan Lanciani) writes:
>A simple
>kludge that avoids this behavior on many systems is to set the linger
>option to "on" with a linger time of 0 before closing the socket.  The
>close then results in a "hard" tcp drop and an immediate recovery of
>memory.  Of course, this can break the protocol...

In BSD and BSD-derived systems (which are probably the only ones that
have a linger option) this is probably a bad idea,  because it causes
an RST to be sent abort the connection, which may be visible as an
ECONNRESET to the application on the other end.  It may also result
in the loss of data.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Mar 1992 16:51:29 GMT
From:      aep@icd.ab.com (Alexander E. Pensky)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP error.  Please Help!

In article <1992Mar18.235456.27357@burrhus.harvard.edu>, ddl@burrhus.harvard.edu (Dan Lanciani) writes:
> In article <1992Mar18.222959.11474@m.cs.uiuc.edu>, whetten@cs.uiuc.edu (Brian Whetten) writes:
> | We are looking at the idea of using TCP sockets as reliable datagrams.
> | i.e. For each message, you set up a socket, pass through the message, and 
> | close the socket down.  In our test programs, however, doing this repeatedly
> | (besides being rather slow) causes an error in both SunOS 4.1.1 and HPUX 7.0.
> | 
> | On the 2000th message in SunOS, the system puts up a "mbuf map full"
> | message to the console window and dies hard.  Power off is needed to reboot.
> | 
> | In HPUX, every 240 messages or so the machine puts up a "NFS error 2025"
> | message, freezes for approx. 40 sec., and then puts through another 240
> | messages.
> | 
> | Help please?  Is this a bug in both operating systems?  Has anyone
> | ever figured out how to use TCP this way?  I have successfully implemented
> | this type of a thing using NetBios on IBM PC's, and it works very well.
> 
> 	This is a common problem for programs that quickly create
> and destroy many tcp/ip connections under BSD-derived systems.  Sockets
> accumulate in TIME_WAIT and use up all available memory.  A simple
> kludge that avoids this behavior on many systems is to set the linger
> option to "on" with a linger time of 0 before closing the socket.  The
> close then results in a "hard" tcp drop and an immediate recovery of
> memory.  Of course, this can break the protocol...

This problem is not unique to BSD-derived systems and is not a bug.
Sockets don't "accumulate" in TIME_WAIT state, they just stay there 
for a while (2*MSL) and then go away.  

This behavior is mandated by the TCP spec; even after a TCP connection is
fully closed, the TCP which initiated the close must remember the sequence
numbers for a time interval of 2*MSL, in case the ACK to the peer TCP's final
FIN was lost, the FIN was retransmitted, and TCP has to ACK it again.

The "socket" per se is not kept, just the minimum part necessary to
remember the TCP ports, sequence numbers, and timer.  On UNIX systems this
generally means at least one mbuf.  Digital's VMS-Ultrix Connection
implementation keeps the pseudo-device which was associated with the socket.

In other words, in any TCP implementation, if you generate new TCP connections
more often than one every 2*MSL, you'll eventually run out of _something_;
exactly what you run out of is implementation-specific.


 -----------------------------------------------------------------------------
 Alex Pensky    	(aep@icd.ab.com)		         (216)646-5211
 Allen-Bradley Company             747 Alpha Drive, Highland Heights, OH 44143
 -----------------------------------------------------------------------------

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Mar 92 18:35:10 GMT
From:      yan@cs.ubc.ca (Hailin Yan)
To:        comp.protocols.tcp-ip
Subject:   help

In  BSD4.3 TCP implementation, there are 3 fields "snd_win" (send  window)
"rcv_win" (receive window) and "rcv_adv"(advertised window)  in tcp control
block structure. I can understand the first two windows' function, but don't
know why we need "rcv_adv" in struct tcpcb.  

Who could tell me that reason? This is my first time to touch TCP.
Thanks a lot for any help.
(please send your explanation to my count directly if it's convenient for you)

--hailin



-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Mar 1992 19:43:20 GMT
From:      bengtson@donnelley.com (Michael Bengtson)
To:        comp.protocols.tcp-ip,comp.sys.transputer
Subject:   tcp-ip code for transputers


Donnelley, a printing company, is doing work with image processing on
transputers and requires tcp-ip code to connect an array of transputers
to an ethernet network.  Does anyone have either Occam or C tcp-ip code
which would run on a transputer?  If there is not an implementation which
runs directly on transputers, where can one obtain tcp-ip source code?

Thanks!

-------------------------------------------------------------------------
Michael Bengtson                               bengtson@donnelley.com
R.R. Donnelley & Sons, Technology Center       Phone: (708) 810-5334
750 Warrenville Road                           FAX: (708) 719-6658
Lisle, IL  60532
-------------------------------------------------------------------------

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 92 23:10:27 GMT
From:      sfalken@apple.com (Steven Falkenburg)
To:        comp.sys.mac.comm,comp.sys.mac.misc,comp.protocols.tcp-ip
Subject:   XferIt 1.5 Available

XferIt 1.5 is now available for distribution to the general public.  XferIt is my
ShareWare Macintosh FTP client.  Here's the intro from the manual:

---
XferIt is a Macintosh application which allows users to transfer files to and from
computers which support the FTP (file transfer protocol) in the TCP/IP protocol stack.
Through the use of a Finder-like interface, XferIt brings the ease of use associated
with the Macintosh to the usually unfriendly world of TCP/IP networking.  Folders and
files are represented by multiple windows, and simultaneous connections to multiple
transfer hosts are permitted, all with a consistent interface.  Vax/VMS, UNIX, VM/CMS,
and Macintosh FTP servers are recognized.  Several different transfer modes are supported,
including text, binary, MacBinary, and BinHex.  All of the above features, in addition
to integrated drag and drop interoperability with the Finder, combine integrate XferIt
seamlessly into both the Macintosh and TCP/IP worlds.  XferIt is ShareWare.

System Requirements

% MacTCP 1.0 or later (available from APDA (Apple ProgrammerUs and DeveloperUs Association
%	A TCP/IP network connection plugged into the Macintosh
%	A Macintosh Plus/Classic/SE or later computer with at least 2MB of RAM
%	System 6.0 or later.
%	System 7.0 is optional, but if available, XferIt will take advantage of AppleEvents and
  Balloon Help
---

XferIt costs $10 for a single-user, $45 for a workgroup (2-30 computers), or $175 for a
location license for 30-500 computers within a 15 mile radius.  You may use XferIt for a
trial period of up to 30 days.
period of 

The software is available by anonymous ftp from mondo.engin.umich.edu (141.212.68.14).
If you're already a registered user, and I have not contacted you with update information,
please mail me at sfalken@apple.com.

-steve falkenburg
 author of XferIt
 sfalken@apple.com

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Mar 92 23:50:15 GMT
From:      jalsop@seachg.uucp (John Alsop)
To:        comp.protocols.ibm,comp.sys.ibm.misc,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   How to connect TCP/IP to DOS/VSE

We have an application which requires a TCP/IP network to be connected to
an IBM mainframe running DOS/VSE.  Data needs to be transferred between the
mainframe and various systems on the network in both directions, with a peak
daily volume of 50 MB.  Currently, 9 track tapes are being used.

I'm looking for pointers to commercial products which address this type of
application.  I realize that there may be approaches using protocols such as
3770/3780, but for a variety of reasons a TCP/IP based solution would be
preferred.

Any of the following solutions would be of interest:

- a direct ethernet connection to the mainframe, allowing ftp sessions

- NFS implementations for DOS/VSE

- SLIP or PPP implementations for a high-speed synchronous line (e.g. 56K)

Note that the DOS/VSE operating system is running under VM, so VM-based
solutions could also be considered.

Please reply directly - I'll summarize if there's sufficient interest.

Thanks

--
-- 
John Alsop

Sea Change Corporation
6695 Millcreek Drive, Unit 8
Mississauga, Ontario, Canada L5N 5R8
Tel: 416-542-9484 Fax: 416-542-9479
UUCP: ...!uunet!uunet.ca!seachg!jalsop

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 92 00:47:58 GMT
From:      gibsoni@ee.mcgill.ca ( irwin roger  gibson )
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Where has the Bootp command gone in recent Net.exe


	Hi.  Concerning net.exe (kapq).  How come there seems to be no
bootp available in more recent versions of net.exe?  I would like to make 
bootp available so any pc on a pronet network could get its ip address.     
Net.exe is also being used as a router so the pronet network can receive ip
packets.   Any help is appreciated.


Irwin Gibson
gibsoni@ee470.ee.mcgill.ca
Perv@emf.lan.mcgill.ca

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 92 02:55:13 GMT
From:      ejp@bohra.cpg.oz.au (Esmond Pitt)
To:        comp.os.os2,sco.opendesktop,comp.protocols.tcp-ip
Subject:   Re: IBM TCP/IP problems (2)

In article <1992Mar19.010809.19243@bohra.cpg.oz.au> ejp@bohra.cpg.oz.au (Esmond Pitt) writes:
> Assistance please. I am running IBM 1.3EE (but without Comms Manager,
> so really 1.3 SE) and IBM TCP/IP 1.2. Problems:

Thanks to Dan Lanciani and Oliver Tschicho for the solution to problem
#1, MS Lan Manager with IBM TCP/IP. The answer is that NETWKSTA does a
NETBIND, so all protocol drivers must be loaded by this statement (&
after PROTMAN.OS2); this also makes the RUN=NETBIND statement
redundant.

This does not cure problem #2. The symptom is that (with or without Lan
Manager) IBM TCP/IP causes the following to appear:

	nb: dssvc: unexpected TPI primitive (18)
	uderror 115, dest=00000000:00000000

about every 10 seconds on all sessions of the console of an SCO ODT Unix
box running TCP/IP and Lan Manager for Unix on the same network.

Any clues?

Once again, thanks for any assistance.

-- 
Esmond Pitt, Computer Power Group
ejp@bohra.cpg.oz

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 1992 07:09:30 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   "Intelligent" Routers

What's an "intelligent" router?  Someone here was called about a LAN
survey, and they mentioned intelligent routers.  Is this a real term, or
just someone's marketing crap?  We use a cisco, and it seems to be about as
intelligent as they currently come.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 92 08:09:39 GMT
From:      ccrth@lut.ac.uk (Rob Thirlby)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Transceiver marks on Thick segs

Can anyone tell me what problems I would see if I fitted a transceiver
in the (roughly) middle of a few hundred metres of yellow cable 
NOT on a mark?  It would be the only transceiver other than at the ends
ie closeness is not an issue. 

Similarly can anyone predict the results of cutting the cable not at a mark and 
splicing in a new section (of an integral number of marks in length!).

This is not just an academic question, we have a cable with very limited access.

Any help appreciated,

Rob Thirlby

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 92 13:38:55
From:      wbe@bbn.com (Winston Edmond)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Re: Dialup PPP

   From: ks@orchestra.ecn.purdue.edu (Kirk Smith)
   Organization: Purdue University Engineering Computer Network

   I have put together a new version of dialup on demand TCP/IP.

   This distribution can be retrieved from phoenix.acn.purdue.edu via anonymous
   ftp in the file etc/dp.2.0.tar or etc/dp.2.0.tar.Z.

I found the files in pub/dp*, not etc/dp*.
 -WBE

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 92 10:36:17 GMT
From:      ppvx@litsun.epfl.ch (Patrick Pleinevaux)
To:        comp.protocols.tcp-ip
Subject:   PD implementation of TCP/IP


Sorry for this recurring question:

Where can I find the sources of a PD implementation of TCP/IP ?


P. Pleinevaux

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 92 12:00:04 GMT
From:      marcg@prl.philips.nl (Groenewegen ME)
To:        comp.protocols.tcp-ip
Subject:   CMU-TEK X-Windows problem




Subject details: X-windows communication between VAXstation and UNIX
                 machine, using CMU-TEK tcp/ip implementation for VMS.


Dear fellow netters,

We are using CMU-TEK to be able to use VAXstations, running VMS,
as X-terminals in a UNIX environment.

The facilities FTP and TELNET, offered by CMU-TEK, function properly
without ANY failures so far in the 1..2 months we are using it.

Setting up X-Windows communication gives more problems.
We use the DECW$TRANSPORT_CMU.EXE program, set security on the
VAXstation to "CMU <X-client>" for all users (basically comparable to
xhost + X-client), and on the UNIX machine (which is the X-client):
setenv DISPLAY <VAXstation>  .

Then start up an X-client-application and expect the output on the
VAXstation (X-server). Sometimes it works, sometimes it doesn't. And
when it doesn't it might work the next time, without changing any
parameters or settings. You never know.

The error message upon unsuccesful attempt is the following:

<X-client>(marcg): Xlib:  connection to "<X-server>:0.0" refused by server
Xlib:  Client is not authorized to access server
Error: Can't Open display

Does this carry a truckload of information or what?

The problem looks to me like a timeout problem (e.g. due to heavy
use of our ethernet) but that's just a wild guess.


Is there anyone out there having experience with this situation or
with tuning CMU-TEK (#retries, timeout values etc.) ?


I'd be grateful for any help,

______________________________________________
Marc Groenewegen
Philips Research Labs, signal processing group
Eindhoven, Netherlands
Room WY851, phone (..3140)742092
E-mail: marcg@prl.philips.nl

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 92 14:38:00 GMT
From:      terrya@MCES.MsState.Edu (Terry Arnsdorff)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Transceiver marks on Thick segs

In article <1992Mar20.080939.29193@lut.ac.uk> ccrth@lut.ac.uk (Rob Thirlby) writes:

>Can anyone tell me what problems I would see if I fitted a transceiver
>in the (roughly) middle of a few hundred metres of yellow cable 
>NOT on a mark?  It would be the only transceiver other than at the ends
>ie closeness is not an issue. 
 
>Similarly can anyone predict the results of cutting the cable not at a mark and 
>splicing in a new section (of an integral number of marks in length!).
 
>This is not just an academic question, we have a cable with very limited access.
 
>Any help appreciated,
 
>Rob Thirlby

There should be no problems with placing your transceiver.  The transceivers 
must be at least 2 meters apart (the black marks).  In addition,  
transceivers must be at least 2 meters from the terminators on either end.  
The black marks are a guideline to use for proper spacing of multiple taps.

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 92 14:52:27 GMT
From:      koning@koning.enet.dec.com (Paul Koning)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Transceiver marks on Thick segs


In article <1992Mar20.080939.29193@lut.ac.uk>, ccrth@lut.ac.uk (Rob Thirlby) writes:
|>Can anyone tell me what problems I would see if I fitted a transceiver
|>in the (roughly) middle of a few hundred metres of yellow cable 
|>NOT on a mark?  It would be the only transceiver other than at the ends
|>ie closeness is not an issue. 

The first purpose of those marks is to keep taps 2.5 meters or more apart.
The second purpose is to have their spacing not be a round multiple of
the wavelength.  Clearly the first aspect is take care of in your case;
the second aspect also isn't an issue in the situation you're talking about.

In other words, no problem.

|>Similarly can anyone predict the results of cutting the cable not at a mark and 
|>splicing in a new section (of an integral number of marks in length!).

Shouldn't be a problem if the splices are good quality (N connectors and
N barrels).  Note though that the standard cable segment lengths are NOT
integral multiples of the mark distance.  In fact, if you're going to splice
in a piece, picking one of the standard segment lengths as the length of
the insert would make sense.

|>This is not just an academic question, we have a cable with very limited access.
|>
|>Any help appreciated,
|>
|>Rob Thirlby
|>

	paul


-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 92 15:08:46 GMT
From:      kjetilo@bilbo.uio.no (Kjetil Otter Olsen)
To:        comp.protocols.tcp-ip
Subject:   Detecting a server closing the socket...



Can anyone help me with the following:

I have a client-program using a TCP-socket to connect to a server-program.
The client is a PC running PC-NFS (PC-NFS Programmers Tookit 1 or 2) and
the server is a SUN or a DEC/Ultrix machine.
( Currently the client-program is using sockets, but a rewrite to use
  XTI is OK if it can solve the problem. )

Both programs send and recive data in an "ASYNC" mode (much like
a telnet session). At any given time the server-program will close
the connection, and the client-program must be able to detect this
to proceed with its many tasks.
( The server does not give any inband information about the close,
  and I am not able to alter the server-software. )


The problem is how do the client-program detect the closed socket??


I guess the clue is to use some combination of select and/or non-blocking
read, but my attempts so far has failed. If anyone should make a simple
"telnet" the same problem would probably come up.

Thanks in advance for any help!  Source examples is very welcome :-)

Answers by e-mail please.

-----
Kjetil Otter Olsen    (kjetilo@usit.uio.no / otter@ifi.uio.no)
Senior Communication Engineer,     M.Sc.,   C.Sc.
Center for Information Technology Services (USIT)
University of Oslo, PoBox 1059 Blindern, N-0316 Oslo, Norway
Phone:   +47-2-45 34 88,       Fax:   +47-2-45 37 30
-----

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Mar 92 15:13:00 GMT
From:      akhavan@maestro.bellcore.com (Hamid Akhavan)
To:        comp.protocols.tcp-ip
Subject:   MIL 1777 and 1778


Hi Folks,

I am a newcomer to the TCP/IP/Ethernet world. Can you help me figure
out what are MIL 1777 and MIL 1778 specs? I suspect they are some sort
of implementation standards for Ethernet. Please send your responses to
me through akhavan@maestro.bellcore.com. I appreciate your help.


Hamid Akhavan
akhavan@maestro.bellcore.com



-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Mar 1992 15:31:13 GMT
From:      poorman@convex.com (Peter Poorman)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   xtacacs protocol?

Hi folks;

CISCO terminal servers support a protocol called TACACS (Terminal Access-
Controller Access system) which, according to the CISCO manuals, was developed
by DOD.  They also support an extended version called (not suprisingly) 
XTACACS.

Like all the other protocols, the CISCO docs expect you to already know
all about the protocols.  Unfortunately, I don't know about this one and
can't seem to find any specs for it.  (For example, the only reference to
it in the RFCs is a Telnet negotiation option.)

Can anybody give me any pointers to specs for these protocols?  Of particular
concern are the semantics of the various values that can be returned to the
client by the server.  (For example, what is a terminal server supposed to
do with a UID?)

Thanks!

-- Pete Poorman
   poorman@convex.com
   713-939-7200


-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 92 16:08:26 GMT
From:      wscott@ecn.purdue.edu (Wayne H Scott)
To:        comp.unix.questions,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.sun.misc
Subject:   Re: file transfer: FTP or FTP ?

harish@csar.uucp (Harish Pillay) writes:

>wscott@ecn.purdue.edu (Wayne H Scott) writes:
>>look at FSP
 
>>FSP is a very nice file transfer program that was posted to comp.source.misc
>>a while back. (or was it alt.sources)
 
>Is it available at a anon ftp site?
 
>Thanks.
>--
>Harish Pillay             harish%csar@uunet.uu.net
>Singapore               "Psst!  Wanna buy some gum?"

Anon FTP from

wuarchive.wustl.edu @ /pub/fsp.23.tar.Z

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Mar 1992 17:07:51 GMT
From:      rgoldstone@OAVAX.CSUCHICO.EDU (Robin Goldstone)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Kermit over TCP/IP

Columbia has developed a PC Kermit client that will do Kermit file transfers
over TCP/IP.  Technically, I don't know quite how this works other than
that the PC client allows you to Telnet to a host and initiate a Kermit file
transfer that the PC will accept over the TCP/IP connection.  There are no
special modifications to the host Kermit for this to work.

I am wondering if Columbia is planning on adding the same capability to its
Macintosh Kermit client or if NCSA is considering adding Kermit support to
NCSA Telnet for Macintosh. 

Minimally, if someone has an e-mail address at Columbia to which I could
address this question, I would be grateful for that.

Thanks in advance.
***********************************************************************
Robin Goldstone, Systems Software Specialist
California State University, Chico  Computing Services
rgoldstone@oavax.csuchico.edu

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 92 17:16:37 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: "Intelligent" Routers

In article <ksj3taINNl23@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
|> What's an "intelligent" router?  Someone here was called about a LAN
|> survey, and they mentioned intelligent routers.  Is this a real term, or
|> just someone's marketing crap?  We use a cisco, and it seems to be about as
               ^^^^^^^^^^^^^^    Yes!!!  To a degree!
|> intelligent as they currently come.
|> -- 
|> Barry Margolin
|> System Manager, Thinking Machines Corp.
|> 
|> barmar@think.com          {uunet,harvard}!think!barmar

This term came in when a lot of routers were available that didn't run an IGP such as RIP and or an EGP (generic) such as EGP (specific).  In other words they were only static configuration routers (this disagrees with the RFC for routers, I forget which number).  Whenever the topology of the network changed they had to be reconfigured.  Now, thankfully most of these have gone away.

This term is also used by router vendor marketing types to infer that bridge technology boxes are not intelligent.  Some people who don't understand the differing technologies are persuaded to buy intelligent routers when a dumb (but learning) bridge would solve the problem for less money.  An example would be, "You need a $20k (unnamed manufacturer) router to connect you five man remote sales office because it's more intelligent than a $2k bridge.

Mark Reardon (mwr@eng.tridom.com)

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 92 17:30:15 GMT
From:      sss@netcom.com (Small Systems Solutions)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Transceiver marks on Thick segs

In article <1992Mar20.080939.29193@lut.ac.uk> 
	rob@lut.ac.uk (Rob Thirlby) writes:

>Can anyone tell me what problems I would see if I fitted a transceiver
>in the (roughly) middle of a few hundred metres of yellow cable 
>NOT on a mark?  It would be the only transceiver other than at the ends
>ie closeness is not an issue. 

Henry Spencer will give you a definitive answer on this -- suffice it to
say that the marks are there for a reason.  I believe that the marks are
a whole number of bits in distance from each other.

-- 
Small Systems Solutions                   1563 Solano Avenue, Suite 123
sss@netcom.com                                  Berkeley, CA 94707-2116

The above-expressed opinions aren't necessarily

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 92 21:36:15 GMT
From:      jim@tiamat.fsc.com ( IT Manager)
To:        comp.protocols.tcp-ip
Subject:   sub-netting question

Our parent organization has secured a class-B network number for use
within our organization.  The guys in charge have decided to sub-net it
using the left-most seven bits of the 3rd octect, and we have received
the address 141.127.172.

Currently, we are not gatewayed to anywhere, but the idea is that we will be
at some point in the future.

Is it possible to sub-net this address even further to allow for several
local networks and still be able to eventually gateway to the rest of the
company (or the world)?

My initial guess is that a gateway machine might have sub-nets as follows:

 world --> netmask FF.FF.FE.00 <-- gateway --> netmask FF.FF.FF.80 <-- us

Would this work?

Thanks.
------------- 
James B. O'Connor                                     jim@tiamat.fsc.com
Information Technology Manager                        voice 615/821-4022 x651
Ahlstrom Filtration, Inc.                             fax   615/821-0616

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 92 22:24:48 GMT
From:      koning@koning.enet.dec.com (Paul Koning)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Transceiver marks on Thick segs


In article <terrya.11@MCES.MsState.Edu>, terrya@MCES.MsState.Edu (Terry Arnsdorff) writes:
|>...
|>There should be no problems with placing your transceiver.  The transceivers 
|>must be at least 2 meters apart (the black marks).  In addition,  
|>transceivers must be at least 2 meters from the terminators on either end.  
|>The black marks are a guideline to use for proper spacing of multiple taps.

Not quite.

1. The Ethernet spec makes it clear that it IS the intent to have transceivers
   on the marks -- or off the mark by equal amounts.  In other words, it's
   not just a minimum spacing issue.  On the other hand, the wording suggests
   that minimum spacing is the major concern and specific spacing a secondary
   concern.  So if you have just a few stations off the mark, that shouldn't
   be a big issue.  If you put a lot of stations at wrong distances, such
   as multiples of the wavelength, you can definitely expect problems.
   [by the way, an earlier comment suggested that the marks are spaced a
   round number of bits apart.  Not so, just the opposite in fact: the goal
   is to avoid that condition.]

2. It is NOT true that you must stay away from the terminator.  Subject to
   the other issues, you can put a transceiver as close to a terminator as
   you wish.
   This is clear from transmission line theory.  You can also see it in the
   field: at the end of a thinwire daisychain you'll see the terminator right
   on the T connector.  And in the thinwire repeater there's a terminator
   built in, right next to the repeater circuit.

	paul


-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 92 20:18:34 GMT
From:      92disanto@gsb-yen.stanford.edu
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for IBM AS400

Does anyone know of a commercially available TCP/IP protocol suite
for the IBM AS400?  Does IBM provide anything?  What's the cost?
Software only, or is extra hardware required?

Thanks

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 92 01:20:41 GMT
From:      hsu@cs.hut.fi (Heikki Suonsivu)
To:        comp.protocols.tcp-ip
Subject:   Printing through NCSA telnet ftp


I have been trying to set up a printing kludge like this:

sun3/60 (ghostscript) -> pc, Olivetti m24 (NCSA telnet) -> kyocera laser.

I'm using Ghostscript as postscript interpreter.  The problem is the
following: if I send the file (graphics produced by ghostscript) to the
printer via ncsa telnet ftp server using

binary
send foo.printout prn

some data gets lost, and the printout gets messed up.  The data seems to
disappear the same point, so I assume that either NCSA telnet or the dos
printer device breaks up something.

If I first upload the file to the pc and then tell the pc to

copy /b foo.printout prn

and the printout is fine. /b seems to be required, otherwise copy stops at
the first ^Z it sees (?).

It is somewhat unpractical to print out files by uploading the stuff to the
pc in pieces and then copy them to the printer manually.  I would like to
use floppy-only pc corpse as the printing server.

I don't want to go back to serial line, 300dpi A4 bitmap would take forever
to upload to the printer.

The printer should be set up to defaults, emulating hp laserjet (+?)
Any ideas?

-
Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND,
hsu@{otax.tky.hut,cs.hut,clinet}.fi  +385-0-8031121
/G=Heikki/S=Suonsivu/O=hut/OU=cs/PRMD=Inet/ADMD=Fumail/C=FI,
mcsun!hutcs!hsu, riippu SN, Email preferable.

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Mar 1992 01:22:24 GMT
From:      pkjc@cbnewsl.cb.att.com (peter.k.chen)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Comparing different TCP/IP software

I like to hear from people about their experiences with different
vendors' TCP/IP for UNIX (Svr4 or 3.2) on 386/486. I am especially
interested in experiences with the following: 

	Microport
	Wollongong
	Interactive Systems 

For example, what are the things you like and do not like, quality of the
software, support, performance ...
Any information/comments/... are greatly appreciated.

Also, now that Interactive has been acquired by SunSoft, any information
on the future of its TCP/IP and SVR4.0 software?

Thanks in advance.

Peter Chen

	



-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Mar 1992 03:11:32 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Transceiver marks on Thick segs

In article <9+#jvrcsss@netcom.com> sss@netcom.com (Small Systems Solutions) writes:
>Henry Spencer will give you a definitive answer on this -- suffice it to
>say that the marks are there for a reason...

I hadn't planned to comment, actually, since others -- some of them probably
more knowledgeable about this than me! -- had already supplied the right
answer.  However, since it's been specifically requested... :-)

Any discontinuity in the cable causes some amount of reflection as a signal
propagates past it.  Too much reflection, and some of the hosts on the
network will see a garbled packet.  You can get lots of reflection either
by one big discontinuity, like an end without a terminator, or lots of
little ones whose locations are such that the reflections reinforce each
other.

Transceivers and cable connectors inevitably are discontinuities, although
they are designed to be small ones.  Both the black marks for transceiver
locations and the rather odd official lengths for thick cable were crafted
most carefully to keep the reflections from reinforcing each other.

However, classical thick-coax Ethernet is heavily over-engineered to work
reliably in severe worst cases.  A single misplaced transceiver is most
unlikely to cause any problem.
-- 
GCC 2.0 is to C as SVR4 is to Unix.     | Henry Spencer @ U of Toronto Zoology
                             -Dick Dunn |  henry@zoo.toronto.edu  utzoo!henry

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 92 14:59:49 GMT
From:      lanier@bart.acpub.duke.edu (Dustin Lanier)
To:        comp.protocols.tcp-ip
Subject:   Re: MIL 1777 and 1778

In article <1992Mar20.151300.24914@walter.bellcore.com>, akhavan@maestro.bellcore.com (Hamid Akhavan) writes:
|> 
|> Hi Folks,
|> 
|> I am a newcomer to the TCP/IP/Ethernet world. Can you help me figure

I however am even more of a newcomer.  I am looking for either an extended FAQ file or a
good book that goes from the basics up ... I want to learn as much about the TCP/IP 
protocol as possible ... an suggestions would be greatly appreciated.

Dustin Lanier

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 92 03:46:31 GMT
From:      jessea@homecare.COM (Jesse W. Asher)
To:        comp.protocols.tcp-ip
Subject:   Slip for SVR4 and Xylogics terminal server.

I was wondering if anyone had cslip running on Esix 4?  I'm trying to get
some Esix 4.0 boxes to talk slip with a Xylogics Annex III terminal
server and I'm having no luck so far.  Has anyone done this?  Can you
tell me where to get cslip for SVR4?  I've got slip right now and that
isn't working well.  Thanks.

-- 
      Jesse W. Asher        NIC Handle:  JA268         Phone: (901)386-5061
                       Health Sphere of America Inc.
	       5125 Elmore Rd., Suite 1, Memphis, TN 38134
 Internet: jessea@homecare.COM                 UUCP: ...!banana!homecare!jessea

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Mar 1992 07:20:06 GMT
From:      sridevan@elec.uq.oz.au (Sri Parameswaran)
To:        comp.protocols.tcp-ip
Subject:   About virtual connections for tcp.

Could anyone out there tell me whether when a tcp session is in progress
there is a virtual connection set up through the intermediate hosts or
is it just end to end. i.e., if a machine intermediate machine crashes
does the session stop completely or does ip route packets using another
route.


Thanks
Sri
-------------------------------------------------------------------------
Sri Parameswaran
Dept. of Electrical Engineering, University of Queensland,
St. Lucia, Australia.

Phone: +61-7-365-4190		Fax:   +61-7-369-4999
ACSnet: sridevan@elec.uq.oz	INTERNET: sridevan@elec.uq.oz.au
				UUCP:     uunet!elec.uq.oz.au!sridevan

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 92 11:43:32 GMT
From:      a0424986@let.rug.nl (Peter Bouthoorn)
To:        comp.protocols.tcp-ip
Subject:   Telnet like programs that offer kermit instead of ftp!!!!!

In a former article I asked for a program that should have normal
telnet capabilities and offer kermit/zmodem instead of ftp. I got
lots of replies and would like to thank everyone who took the time
to mail me (I know I'm a bit late, but that's because of the exams
I had to take!). For those that would like to have just the program
I asked for here's some info:
  
  For UNIX try the newest version of C-kermit which can be found
  at watsun.cc.columbia.edu /kermit/sw/cku179.tar.Z.
  I really liked this one! Telnetting and transferring programs by
  the kermit protocol worked perfect. It's still a beta version so
  it might contain some bugs.
  For DOS try the latest version of MSKERMIT which can be found at
  e.g. wuarchive.wustl.edu /mirrors/msdos/kermit/msker311.zip.
  Haven't tested it myself yet, but heard it should work fine.

So much for this. But what about the other protocols like xmodem and
zmodem? Does anyone know of any implementation of zmodem through tcp/
ip???

Peter Bouthoorn
a0424986@let.rug.nl

Try the new C-kermit, it's really good! (the only disadvantage is that
we're running out of disk space here with people like me installing
their own utilities - C-kermit on hpux 8.0 is about 360K!).

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 92 12:23:47 GMT
From:      rh0083b@medtronic.COM (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: About virtual connections for tcp.

In article <sridevan.701335206@s1.elec.uq.oz.au> sridevan@elec.uq.oz.au (Sri Parameswaran) writes:
>Could anyone out there tell me whether when a tcp session is in progress
>there is a virtual connection set up through the intermediate hosts or
>is it just end to end. i.e., if a machine intermediate machine crashes
>does the session stop completely or does ip route packets using another
>route.

IP will use an alternative route, if available. However, it may take some
time (can't say how much) before the alternative route is used.

-Roger

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 92 15:18:20 GMT
From:      froud@solb1.essex.ac.uk (Froud D D M)
To:        comp.protocols.tcp-ip
Subject:   Telnet protocol hassle

Right! I want to be able to tell a telnet client not to echo user input, but to send it character-by-character to my server sitting on some port, and to echo what the server sends back.

So far, I can put the client into character-by-character mode (WILL SGA & WILL ECHO) but the client then refuses to print anything I send it.

Where am I going wrong?

Dominic 
--
Hello, I'm a signature...!

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 92 16:20:41 GMT
From:      steved@lion.inmos.co.uk (Stephen Doyle)
To:        comp.protocols.tcp-ip,comp.sys.transputer
Subject:   Re: tcp-ip code for transputers

> Michael Bengston writes
>
> Donnely, a printing company, is doing work with image processing on
> transputers and requires tcp-ip code to connect an array of transputers
> to an ethernet network. Does anyone have either OCCAM or C tcp-ip code
> which would run on transputers, where can one obtain tcp-ip source code?
>

For TCP/IP from Transputer networks INMOS sells a product called the B300
(or to give it the full product code IMSB300-1), this provides

Four Transputer networks accessible from Ethernet with Transputer link output
and differentially driven links from the unit and four subsystem control
connections allowing independent booting, rebooting & disconnection.

Use of the unit accessing up to four networks for Transputer program 
development on single & multi-processor systems, uses the standard ISERVER
connection compatible with INMOS ANSI C Toolset, OCCAM Toolset & Glockenspiel
C++.

Transputer programs can talk to other TCP/IP hosts using BSD style sockets
(accessible from C and OCCAM programs).

A connection database allows resources to be searched through by network access
software until a free resource is found, transputer resources can be given
multiple aliases so that different users can use the search facility
in different ways (i.e. one user may want to use T805, another might want at
least 2MB of memory).

For reference the TCP/IP code runs in the B300 unit , so there is no need
for the user to reserve memory for TCP/IP code. 

If you need further information please mail me.

Regards,

Steve Doyle
Steve Doyle, Software Group, INMOS Ltd   | Tel +44 454 616616
1000 Aztec West                          | 
Almondsbury                              | UK: steved@inmos.co.uk
Bristol BS12 4SQ, UK                     | US: steved@inmos.com

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Mar 1992 17:35:32 GMT
From:      johnk@gordian.com (John Kalucki)
To:        news.announce.newgroups,news.groups,comp.protocols.tcp-ip,comp.dcom.lans.misc,comp.sys.sun.admin,comp.protocols.ppp
Subject:   RFD:  comp.dcom.servers

Proposal:
--------

Creation of new newsgroup comp.dcom.servers.

Due to the rapid growth of communication servers in the industry and the
lack of a newsgroup to discuss their merits, pitfalls, and configuration
I'd like to begin discussion on a new newsgroup, comp.dcom.servers.


Status:
------

Unmoderated


Charter:
-------

To provide a central newsgroup for discussion about communication
servers such as terminal servers, network print servers, stand
alone SLIP/PPP/Appletalk servers, dial on demand routers, protocol
translators, etc.

Topics likely to be discussed in comp.dcom.servers would include: 
	* Functionality of products
	* Problem solving and appropriate solutions
	* Interoperability
	* General product selection issues, (price, support, etc.)
	* Impressions and debate on merit and drawbacks
	* Ideas/desires for new products and functionality

A monthly FAQ would also be posted containing manufacturers of such
products and how to contact them. Hopefully this will end the endless
messages requesting information of this sort on comp.protocols.tcp-ip
and elsewhere.


Rationale:
---------

Currently there is no central location to discuss this growing
field.  Messages requesting information about this type of product
can be found in such widely dispersed locations as
netblazer-users@telebit.com, comp.dcom.lans, comp.protocols.tcp-ip,
comp.protocols.ppp, comp.dcom.cisco, comp.unix.admin and comp.sys.sun.admin.

Cisco, Xyplex, Lantronix, Digital, Emulex, Livingston, Telebit,
Shiva, Milan and many other vendors provide products of these types,
many with overlapping and/or complimentary functionalities. Splitting
newsgroups along vendor, or communication server type inhibits
relative comparison of product merit and also inhibits problem solving
involving two or more different products.

Follow Up:
---------
Please follow up all discussion to news.groups.

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 92 21:11:05 GMT
From:      Saeedi@cup.portal.com (Steven J Saeedi)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for IBM AS400

>Does anyone know of a commercially available TCP/IP protocol suite
>for the IBM AS400?  Does IBM provide anything?  What's the cost?
>Software only, or is extra hardware required?

If you have the Token Ring adapter, then it's a software only
solution.  IBM has a TCP/IP for the AS/400 and we bought it for
our machine.  The pricing really depends on what model AS/400
you have.  I think we paid about $2000~$4000 for the software
from IBM for our Model C20.  I have since moved, so I have no 
idea how it has worked out for them.

-- Steve Saeedi
   saeedi@cup.portal.com
>
>Thanks

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 92 21:29:11 GMT
From:      kcw@reef.cis.ufl.edu (Ken Whedbee)
To:        comp.protocols.tcp-ip
Subject:   SLIP, xterminals, opinions wanted



Hi -

I am looking for any pointers on SLIP (Serial Line Internet Protocol)
that allows TCP/IP over dialup lines.  Specifically, I like to
know:

1.  Vendors that supply SLIP.

2.  What additional equipment (boards, modems, etc.) needed to
    add to a unix workstation.

3.  Speed.  (baud rate ? 9600).

4.  Has anyone run X Windows over SLIP to Xterminals?  Is there a real 
    bad performance degradation ?

5.  General opinion on SLIP as compared to price versus performance,
    reliability, etc.

Please email responses and I'll summarize and post if interest warrants.
Please forgive me if this is a FAQ.

Many Thanx! 

-- 
Ken Whedbee                  Internet:  kcw@reef.cis.ufl.edu
University of Florida        UUCP:      ..!uflorida!bikini.cis.ufl.edu!kcw
                             BITNET:    kcw@ufpine
"C Code.  C code run.  Run, code, run... PLEASE!!!"  -- Barbara Toungue

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 92 04:40:06 GMT
From:      aaronm@boy.com (Aaron McClure)
To:        comp.protocols.tcp-ip
Subject:   Please help me find WNOS

I am looking for a copy of WNOS, a TCP-IP ham radio program for windows.

If anyone can send me the program or assist me in getting it I would
be greatly appreciated.

Thank You

Aaron D. McClure

WD0FAA@N6QM.#NCA.CA.USA

aaronm@boy.com

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 92 14:54:28 GMT
From:      pjd@eagle.inesc.pt (Paulo Jorge Delgado)
To:        comp.protocols.tcp-ip
Subject:   firewall


	I've been reading in this newsgroup articles about firewalling. I
understand it is a way to provide safe access from a internet to a LAN.
Can someone tell me exactly how it works? I have a LAN with several Unix
hosts and I wish to allow TCP/IP over X.25 access to some of the machines.
I have the choice of adding a X.25 router to the network, or adding some
SW and HW to one of the hosts so it will become a X.25 router.
	Can you please share your thoughts/experiences on this subject?

-Paulo Jorge Delgado
email: pjd@eniac.inesc.pt

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Mar 1992 15:05:30 GMT
From:      oleg@watson.ibm.com (Oleg Vishnepolsky)
To:        comp.os.os2,sco.opendesktop,comp.protocols.tcp-ip
Subject:   Re: IBM TCP/IP problems (2)

In  <1992Mar20.025513.26230@bohra.cpg.oz.au>  ejp@bohra.cpg.oz.au (Esmond Pitt) writes:
> In article <1992Mar19.010809.19243@bohra.cpg.oz.au> ejp@bohra.cpg.oz.au (Esmond Pitt) writes:
> > Assistance please. I am running IBM 1.3EE (but without Comms Manager,
> > so really 1.3 SE) and IBM TCP/IP 1.2. Problems:
>
> Thanks to Dan Lanciani and Oliver Tschicho for the solution to problem
> #1, MS Lan Manager with IBM TCP/IP. The answer is that NETWKSTA does a
> NETBIND, so all protocol drivers must be loaded by this statement (&
> after PROTMAN.OS2); this also makes the RUN=NETBIND statement
> redundant.
>
> This does not cure problem #2. The symptom is that (with or without Lan
> Manager) IBM TCP/IP causes the following to appear:
>
>       nb: dssvc: unexpected TPI primitive (18)
>       uderror 115, dest=00000000:00000000
>
> about every 10 seconds on all sessions of the console of an SCO ODT Unix
> box running TCP/IP and Lan Manager for Unix on the same network.
>
> Any clues?
>
> Once again, thanks for any assistance.
>
> --
> Esmond Pitt, Computer Power Group
> ejp@bohra.cpg.oz


Taking into account that the messages appear on an SCO UNIX box, why do you
think this is an IBM problem ? Why not contact SCO and ask them what these
messages mean ? Please feel free to e-mail me at oleg@watson.ibm.com

Oleg Vishnepolsky

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 92 16:19:34 GMT
From:      vero@turner.laas.fr (Veronique Baudin Thomas)
To:        comp.protocols.tcp-ip
Subject:   Raw-socket : help !!!

Hello,

we try to use raw-socket under SunOS4.1.
We have to implement a new protocol (XTP) under IP
using the raw-socket.
Question: has anybody here got some basic examples 
using raw-sockets.

Thanx in advance.

Please reply by E-mail at the following address

  ----------------------------------------------------------------
    Veronique BAUDIN                      
       CNRS-LAAS                      e-mail : baudin@laas.laas.fr
  7 av. du Colonel Roche              tel : 33/61.33.63.23   
   31077 TOULOUSE Cedex               fax : 33/61.55.35.77  
         FRANCE                                                   
  ----------------------------------------------------------------

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 92 16:29:37 GMT
From:      williams@ziggy.cac.stratus.com (Eric Williams)
To:        comp.sys.novell,comp.protocols.tcp-ip
Subject:   RARP Server for Novell Network?

Problem:

We have a network of diskless workstations on a Novell network and have
added a Stratus  host on the network using TCP/IP. I'd very much like to 
circumvent the need for loading each workstation with an IP address (diskette 
management nightmare).  The RARP protocol was developed for this but Stratus 
does not support it.  Do any of you know of a server-type product we could hang 
on the network that would provide this functionality? Does Novell offer such a 
product?  Any rational ideas appreciated.

				/edw/

---------
Eric Williams			EMAIL: williams@zen.cac.stratus.com
Stratus Computer Inc.		FAX  : (508) 480-9368
Marlboro, Ma. 01752-1298	PHONE: (508) 460-2915

NeXT Mail Welcome...

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Mar 1992 16:54:14 GMT
From:      mleech@bnr.ca (Marcus Leech)
To:        comp.protocols.tcp-ip
Subject:   Access to PUSH functionality from socket-based TCP

In BSD socket-based TCP implementations, how do you get access to the
  PUSH BIT functionality?

Does the implementation make decisions about when to PUSH that are
  outside of your control?

-- 
Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
mleech@bnr.ca                  P.O. Box 3511, Stn. C   |are my own, and not
ml@ve3mdl.ampr.org             Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 92 19:51:42 GMT
From:      chrisc@ramrod.lmt.mn.org (Chris Cox  W0/G4JEC)
To:        comp.protocols.tcp-ip
Subject:   LPD

Can anyone point me at a detailed specification of the LPD protocol?

I understand that currently it is not defined by any RFC.

Thanks...

Chris

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 92 21:01:59 GMT
From:      dou5@quads.uchicago.edu (Allen Douglas)
To:        comp.protocols.tcp-ip
Subject:   Telnet for windows?

Is there a Telnet (I use a mac) program 'out there' that runs as a windows
application? Or do most pc users run some application in the DOS shell of Win?
Any help is appreciated!  
Thanks,
Allen...

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 92 09:54:30 CST
From:      paul@kuhub.cc.ukans.edu
To:        comp.protocols.tcp-ip
Subject:   Subnet mask brain-teaser!

Anyone have any ideas?

Currently our campus ethernet is "routerless", except to get off
campus. We're contemplating putting three routers on campus to reduce
backbone traffic.

Set up:

Net mask FF.FF.00.00
Subnet mask FF.FF.FC.00


Given the way departments move around between buildings on this campus
we'll almost certainly have a situation in which machines in a
different subnet are on the same ethernet port of a router, such as

                                      129.237.80.8 (Ultrix)
                                     /
router ethernet port  X--------------
                                     \129.237.129.1 (PC running Clarkson CUTCP)

The PC will have its config.tel net mask set to FF.FF.FC.00

When 129.1 tries to connect to the 80.8 the IP address will be outside
the local subnet, so the default gateway will be tried. The router
should take the request and issue an ICMP redirect to the initiating
PC redirecting to a "direct" connection.

What I don't know is whether the router will actually do that, and
whether CUTCP will, upon reception, will delete the route out of its
routing tables and start a direct dialog with the other PC.

I don't read this group, so please e-mail me directly. Thanks!


-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 92 11:54:11 GMT
From:      koelman@cuby.stc.nl (Ton Koelman)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP via serial line with many nodes?

In article <1992Mar24.150736.4108@eng.ufl.edu> ort@wasp.eng.ufl.edu (Randy  
Thomas) writes:
> 
> 
> I have a general question about a serial (RS232) communication scheme.
> We are considering ways of connecting 900 8088-PCs to a broadband  
 network.
> These 900 PCs will be the only communicating devices on the network.   
 What
> I would like is TCP/IP via the RS232 port for 900 PCs hanging bus-like  
 off
> of the network.  This, in my mind, is like ethernet over the serial  
port.


indeed! so you could use those serial (or parallel!) port to thin wire
ethernet adapters. There must be packet drivers for those allowing
you to run TCP/IP over them...

--
Ton Koelman   e-mail: koelman@stc.nl  (NeXT Mail Welcome!)
SHAPE Technical Centre, P.O. Box 174, 2501 CD  The Hague
The Netherlands  (voice: 31-70-3142429, fax: 31-70-3142111)

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 92 13:08:47 GMT
From:      J.Heaton@MCC.ac.uk (John Heaton)
To:        comp.protocols.tcp-ip
Subject:   Re: Please help me find WNOS

In article <1992Mar24.044006.12896@boy.com> aaronm@boy.com (Aaron McClure) writes:

>I am looking for a copy of WNOS, a TCP-IP ham radio program for windows.
 
>If anyone can send me the program or assist me in getting it I would
>be greatly appreciated.
 
>Thank You
 
>Aaron D. McClure
 
>WD0FAA@N6QM.#NCA.CA.USA
 
>aaronm@boy.com


WNOS is NOT a Windows based TCP/IP program.  The W stands for WAMPES.

You can finf WNOS on ucsd.edu, in the hamradio/packet/tcpip/.. directory.

Cheers, John.
                  JANET : J.Heaton@uk.ac.Manchester
  Packet: G1YYH@G1YYH.GB7NWP.#16.GBR.EU                        (QTHR)
* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *
|                      NRS Central Administrator                      |
| MCC Network Unit, The University, Oxford Road, Manchester,  M13-9PL |
|           Phone: (+44) 61 275 6011, FAX: (+44) 61 275 6040          |
* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 92 14:59:20 GMT
From:      dricejb@drilex.dri.mgh.com (Craig Jackson drilex1)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet for windows?

In article <1992Mar24.210159.12011@midway.uchicago.edu> dou5@quads.uchicago.edu (Allen Douglas) writes:
>Is there a Telnet (I use a mac) program 'out there' that runs as a windows
>application? Or do most pc users run some application in the DOS shell of Win?

Novell's LAN Workplace for DOS comes with Windows versions of Telnet,
FTP client, FTP server, and a tool for doing simple DNS queries.

There's a company called Netmanage, I believe, which has a product
called Chameleon.  This is TCP/IP implementation which is Windows-only:
the kernel is completely implemented as a DLL.  They've even recently
released a router.
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,alliant,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Mar 1992 15:11:46 GMT
From:      zrhk0390@awsws6.rus.uni-stuttgart.de (A. Wierse)
To:        comp.protocols.tcp-ip
Subject:   good book on tcp-ip-programming?

Hi,

I was looking for faq, but I didn't find anything but another poster
looking for it too.
So here I go directly:

I need a good book on the programming aspects of tcp-ip.
Especially about socket-communication.
I'm totally new to network-programming but not to networking,
so the book should be easy to understand but should also have a
certain level.

Thanks in Advance

Andreas Wierse


/*--------------------------------------------------------------------------*/
/* Andreas Wierse                                                           */
/* Institut fuer Computeranwendungen II                                     */
/* Abteilung Computersimulation und Visualisierung                          */
/* (Institute for Computerapplications II                                   */
/* Department Computersimulation and Visualization)                         */
/*-------------------------+------------------------------------------------*/
/* Rechenzentrum           | wierse@rus.uni-stuttgart.de                    */
/* Universitaet Stuttgart  | Tel.: ++49-711-685-5796                        */
/* Allmandring 30          | Fax:  ++49-711-682357                          */
/* 7000 Stuttgart 80       |                                                */
/*-------------------------+------------------------------------------------*/

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 92 18:20:07 GMT
From:      lstowell@pyrnova.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for IBM AS400

In article <1992Mar21.121834.1@gsb-yen.stanford.edu> 92disanto@gsb-yen.stanford.edu writes:
>Does anyone know of a commercially available TCP/IP protocol suite
>for the IBM AS400?  Does IBM provide anything?  What's the cost?
>Software only, or is extra hardware required?
>
     I am interested in exactly the same product...but only for
     TCP/IP over Ethernet with the "Type" coding of packets rather
     than the 802.3 frame format.

     Am particularly interested in OEM Ethernet adapter cards for
     the AS/400...with drivers.

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 92 18:43:50 GMT
From:      lstowell@pyrnova.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet for windows?

>In article <1992Mar24.210159.12011@midway.uchicago.edu> dou5@quads.uchicago.edu (Allen Douglas) writes:
>>Is there a Telnet (I use a mac) program 'out there' that runs as a windows
>>application? Or do most pc users run some application in the DOS shell of Win?
>
 In article <47670@drilex.dri.mgh.com> dricejb@drilex.dri.mgh.com (Craig Jackson drilex1) writes:
>
>There's a company called Netmanage, I believe, which has a product
>called Chameleon.  This is TCP/IP implementation which is Windows-only:
>the kernel is completely implemented as a DLL.  They've even recently
>released a router.
    
    NetManage can be reached at 408-973-7171 in Cupertino CA.

(I have no connection other than that I live near them, and their
latest newsletter was coincidentally in my in-stack of mail.

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Mar 1992 19:39:55 GMT
From:      indep-12@mathcs.sjsu.edu (Kuan-Li Ong)
To:        comp.protocols.tcp-ip
Subject:   HELP on Network Protocol Terms

If you have answers to any of my questions, please spare some of your
precious time to enlight me.  I appreciate your kindness very much.

Q1.  What is TCP/IP?

Q2.  What is Ethernet?

Q3.  What is internet?

Q4.  If you know any other terms that are not in my questions, please
     add them into my questions.


I read these terms everywhere; I am very vague about their meanings.

Is there a good book which discusses these network protocols or whatever?


Please kindly mail your expert answers to 

	indep-12@sjsumcs.SJSU.EDU

Kuan-Li Ong

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 92 21:00:17 GMT
From:      roy@alanine.phri.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   FTP choices for the mac


	Other than cosmetic user interface differences, given Fetch 2.0.6
and XferIt 1.4, is there any reason to pick one over the other for use as
an everyday ftp client for the Mac?  Is either more robust, or faster, or
somehow better in a non-obvious way?

-- 
roy@alanine.phri.nyu.edu (Roy Smith)
Public Health Research Institute
455 First Avenue, New York, NY 10016, USA
"This never happened to Bart Simpson."

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 92 23:37:22 GMT
From:      gutman@nosc.mil (Lew Gutman)
To:        comp.protocols.tcp-ip
Subject:   Re: MIL 1777 and 1778

These are the Department of Defense versions of IP and TCP respectively.  The 
standards are available through NTIS.  

Lew Gutman
Naval Ocean Systems Center
San Diego

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Mar 92 23:57:43 GMT
From:      demon@sequent.com (Dave Richards)
To:        comp.protocols.tcp-ip
Subject:   IP over IEEE 802.5 (Token Ring)


I am currently implementing the IP over IEEE 802.5 support for Sequent's
ptx/TCP/IP product.  I have read through RFC 1042 and have a few questions
about the Largest Frame field conventions.  (Comments from other Token Ring
implementor's would be more than welcome.)

It seems to me that the RFC implicitly requires the IP MTU to be one of
the legal LF values.  (BTW: My IBM document 3rd edition uses a different
set of mappings than are in the RFC.)

If the IP MTU is not an exact LF value, then which LF value should be sent?
If we round up, then a remote node could send us a packet we can't receive.
If we round down, we could send a packet larger than the value reported.

Also, the logic for accepting or discarding frames based on the MTU and
the LF value in the incoming packet seems to assume that the MTU is an
even LF value.  Is this correct?  This would mean that I should only allow
a user to set the MTU to one of the 4/7 legal values.

Another possibility would be to always generate 111 (unspecified) and
never check incoming frames.  This would allow the administrator to specify
whatever he wants across the whole network.

Any thoughts, opinions, etc?

	Dave Richards

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Mar 1992 01:05:33 GMT
From:      gtw@arts.su.oz.au (Gilbert Taylor-Wood)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP choices for the mac

roy@alanine.phri.nyu.edu (Roy Smith) writes:

>	Other than cosmetic user interface differences, given Fetch 2.0.6
>and XferIt 1.4, is there any reason to pick one over the other for use as
>an everyday ftp client for the Mac?  Is either more robust, or faster, or
>somehow better in a non-obvious way?

My opinion is that XferIt has the better interface but it also has a number
of bugs, expecially when uploading files. Fetch is less intuitive to use 
but I have not found any bugs in it.

Gilbert


Gilbert Taylor-Wood                          gtw@su.edu.AU
Network Manager
Faculty of Arts A14
The University of Sydney
NSW 2006                                     Ph  +61 2 692 4713
AUSTRALIA                                    Fax +61 2 692 2045
--
Gilbert Taylor-Wood                          gtw@su.edu.AU
Network Manager
Faculty of Arts A14
The University of Sydney

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 92 02:16:06 GMT
From:      bvj@novell.com (Bagalur Jagadeesh)
To:        comp.protocols.tcp-ip
Subject:   Silicon Valley Networking Conf - Program


The following is the SVNC-92 conference program. If you have any questions
please feel free to contact me at the following address

Registration form at the end of this email

Thanks
/Jagadeesh
bvj@novell.com
(408)-473-8789

Subject: Silicon Valley Networking Conf - 92 - Program


    The Silicon Valley Networking Conference (SVNC - 92) 
    ----------------------------------------------

 
    The Conference on Technology, Architectures and 
             MIS Issues for Computer Networks
 
                 April 27-29, 1992
      Santa Clara Convention Center, Santa Clara, CA
 
The third annual Silicon Valley Networking Conference (SVNC'92) will 
take place on April 27-29, 1992 at the Santa Clara Convention Center. 
A stellar three-day program contains over 70 technical papers describing 
innovative design solutions to network hardware implementation, future 
technology, system architectural considerations, network management 
issues, strategic planners and administrators (MIS), and internetworking 
will be presented.
 
The overall thrust of the conference is to provide SOLUTIONS to system 
design and network problems for system designers, hardware developers, 
and strategic planners. Through its high-quality technical program, 
that consists of paper presentations and topical panel sessions, the 
conference will focus on key issues in local networks, physical layer 
design approaches, internetworking, network management, high-speed 
networking, distributed applications, and MIS related topics.
 
In addition to the technical papers and panels portion of the program, 
attendees can select from short-course topics such as FDDI Basics, 
Internetworking, or Network Management. Coffee-break refreshments as 
well as lunches are included as part of the conference registration.
 
A table-top exhibits area at the conference will provide attendees 
with a view of available components, subsystems, and software that 
can be applied to solve network problems. Exhibits will be open for 
two hours starting at noon on Tuesday and Wednesday, and for two 
hours starting at 5:30 pm on Tuesday evening.
 
FOR REGISTRATION OR TABLE-TOP EXHIBIT SPACE SIGNUP, CONTACT: 
Ken Majithia at (408) 924-3930 (voice), (408) 997-8265 (fax), 
                       and majithia@sjsuvm1.bitnet (email).
 
SVNC'92 is a creation of SysTech Research and cosponsored by 
3Com Corp., Mational Semiconductor Corp., and Electronics and 
Electronic Design Magazines (Penton Publications).
 
===========================================================
 
      Monday, April 27:  Tutorials  8:30 am - 5:00 pm
      (lunch and coffee-break refreshments included)
                  PICK ONE:
(T1)  The FDDI Protocol
      Mark Wolter, National Semiconductor Corp.
 
* FDDI Background
* FDDI Specification
* Station Management (SMT): Specification and Structure
* Connection Management (CMT)
* Configuration Management
* Entity Coordination Management (ECM)
* Ring Management (RMT)
* Frame-Based Management
* Introduction to FDDI II
 
INSTRUCTOR:
 
Mr. Wolter is an applications section head for the Advanced 
Communication Group at National Semiconductor and participates
on the ANSI FDDI Committee. He has written papers and presented
seminars related to FDDI standards for several systems conferences.
Mr. Wolter has experience in the design of both network systems and
ICs.
 
================================================================
 
(T2) INTERNETWORKING
     Brian O'Connel, Consultant
 
* Overview of Internetworking
* Introduction to Bridges and Routers
* Design of a Dual- and Multi-Port Bridges
* Spanning Tree Algorithm
* Design of Routers/Brouters
* Different Routing Protocols Used in Today's Routers
* Advantages of Bridges and Routers
* Design of Concentrators/Hubs
* Example of a Brouter Design Using a RISC Processor.
 
INSTRUCTOR:
 
Mr. O'Connell has over 20 years of experience in the networking industry. 
He has presented tutorials in internetworking at various conferences. Mr.
O'Connell holds a Master's degree from the Massachusetts Institute of 
Technology.
 
===================================================
 
(T3) An Introduction to Open Systems Network Management 
     Dave Crocker, Consultant
 
* Internetworking Review
* Framework for Network Management
* Simple Network Management Protocol (SNMP)
* Common Management Information Service/Protocol (CMIS/P)
* Management Tools
* Example Management Problems
* A Day in the Life of a Network Manager
* An Introduction to Open Systems Network Management
 
INSTRUCTOR
 
Mr. Crocker is currently a consultant. He has many years if experience 
in the Computer Network industry. In previous jobs he managed the 
development of numerous TCP/IP, OSI, and network management products 
at Ungermann-Bass, The Wollongong Group, and Digital Equipment Corp. 
He also participated in various standards committees and specified 
the electronic mail format standard (RFC822).
 
===========================================================
 
                   Tuesday, April 28
 
8:15 Conference Opening
8:30 KEYNOTE Presentation:
 
   GLOBAL DATA NETWORKING AND TOMORROW'S CHALLENGES
 
     Eric Benhamou, President and CEO, 3Com Corp.
 
Biography:
Eric Benhamou is currently the President and CEO of 3Com Corp., a 
position he has held since September of 1990. Previously he held
positions as Vice President and General Manager at 3Com.
 
Mr. Benhamou co-founded Bridge Communications in 1981 and held the
position of Vice President of Engineering. He also spent four years
at Zilog Inc., where he served as Project Manager and Software
Engineering Manager.
 
Mr. Benhamou holds a Master's degree in Electrical Engineering from 
Stanford University and a Diplome d'Ingenieur from Nationale
Superieure at Metiers, Paris. He has authored several papers on
Global Networking and LAN Technology.
 
                   Wednesday, April 29
 
8:15 Conference Opening
8:30 KEYNOTE Presentation:
 
   NEW APPROACHES TO NETWORK TESTING
 
     Dr. Colin Mick, Technical Director, Network Products, 
                     Comdisco Systems Inc.
 
Biography:
 
At Comdisco, Dr. Mick is responsible for managing product development
and customer support activities for the firm's Block Oriented Network
Simulator software. Prior to joining the company, Dr. Mick was already
a recognized author, lecturer and consultant in information sciences and
data communications. Most Recently he was the vice president and general 
manager for the services division of LanQuest, a consulting and testing
organization for local area networks. While at LanQuest, he also served 
as the Executive Director of the Open Token Foundation.
 
===================================================
             Tuesday, April 28
                  TRACK 1
 
9:10 am     FDDI I
FDDI Technology and Architecture
Sanjay Dhawan, Advanced Micro Devices Inc.
NC-034
 
FDDI-II Overview
Greg DeJager, National Semiconductor Corp.
NC-004
 
10:15 am    FDDI II
 
The Effect of Local Buffer Memory Size on FDDI Throughput
David Roberts, Advanced Micro Devices Inc.
NC-032
 
Consideration in Building an FDDI Station
Rhonda Dirvin, Motorola Inc.
NC-024
 
Design Consideration of a FDDI Adapter Card for the EISA BUS
Gautam Chanda, 3Com Corp.
NC-044
 
Network Management for FDDI Concentrator
Yeeping Zhong, National Semiconductor Corp.
NC-033
 
12:00 noon - 2:00 pm  Lunch and Exhibits open
 
2:00 pm  INTERNETWORKING
 
Growing LANs into Wide Area Networks
Bob Kesav, NEC America Inc.
NC-021
 
Third Generation Hubs
Mick Seamen, 3Com Corp.
NC-073
 
Backbone, Hub or a Mixture of Both?
Nabil Damouny, NEC America Inc.
NC-022
 
3:30 pm  ISDN and SONET
 
Merging Telephony with Computing: Next Generation ISDN Desktop Architecture
Alan Gordon, AT&T Microelectronics
NC-063
 
ISDN Basic Rate Access and Applications
Raj Paripatyadar, National Semiconductor Corp
NC-037
 
ISDN Primary Rate Interface
Andrew Sorowka, Level One Communications
NC-055
 
ISDN as a Videoconferencing Enabling Technology: Hardware Issues Using 
the T7250B
Terry Bennett, AT&T Microelectronics
NC-064
 
Effective Interface and Buffering Techniques for SONET Equipment
Manuel Alba, IDT Inc.
NC-057
 
5:30 pm  ---  EXHIBITS OPEN (until 7:30 ms)
 
--------------------------------------------------------
 
           Tuesday, April 28
                 TRACK 2
 
9:10 am    DISTRIBUTED SYSTEMS I
 
Fibronics Distributed Object Oriented System
Michael Shurman, Fibronics 
NC-011
 
Configuration Management: A Base for Distributed Object-Oriented Systems
Christian Zeidler, University of Karlsruhe, Germany
NC-012
 
10:15 am    DISTRIBUTED SYSTEMS II
 
Design and Implementation of a Generic Pardigm for Efficient Distributed Communication
James Hong, University of Waterloo, Canada
NC-028
 
Dynamic, Probabilistic Load Balancing In A Heterogeneous Computer Network
Bennet Groeneveld, Idaho National Engineering Laboratories
NC-068
 
The Add-on Distributed Operating System Layer
Rumen Stainov, Technical Univ of Aachen, Germany
NC-038
 
Dynamic Configuration of Distributed Mixed-Language Applications
Jurgen Becher, University of Karlsruhe, Germany
NC-042
 
12:00 noon - 2:00 pm  LUNCH and EXHIBITS OPEN
 
2:00 pm   DISTRIBUTED SYSTEMS III
 
Migrating Objects in Distributed Environments for Performance Improvement
Arnd Gerns, Institut fur Betriebssysteme und Rechnerverbund
Universitat Hildesheim, Germany
NC-050
 
Synchronous Interaction Policy Server
Arjang Ghassemzadeh, BT Labs, UK
NC-006
 
3:30 pm    APPLICATIONS and PROTOCOLS
 
An Enhanced Security Scheme Based on X.500
Hossam Afifi, Inria Project Rodeo Sophia-Antipolis B.P., France
NC-015
 
Matching the X.400 Message Handling System's Services Against User 
Requirements
Kai Jakobs, Technical University of Aachen, Germany
NC-030
 
Integration of TCP/IP with PC Applications
Norman Schneidewind, Naval Postgraduate School
NC-029
 
Integrating Data Compression into a Networking System
Vivie Lee, Integrated Information Technology Inc.
NC-059
 
Wireless LAN Technology
Daryl Maddox, NCR Corp.
NC-002
 
5:30 pm  -- EXHIBITS OPEN (until 7:30 pm)
 
-----------------------------------------------------------
 
               Tuesday, April 28
                    TRACK 3
 
9:10 am     FUTURE TECHNOLOGY I
 
Evolution and Explanation of Networking Standards
Wayne Martson, Chipcomm Corp.
NC-026
 
Multiprotocol Highways
Brad Harrison, DEC Professional
NC-061
 
10:15    FUTURE TECHNOLOGY II
The Networked PC of the 1990's
Robert Breyer, Intel Corp.
NC-019
 
FDDI Network Architectures, Performance and Futures
G.C. Stone, C/O Don Flanagan, Network Systems
NC-060
 
PANEL SESSION: Technology's Impact on Networking
 
12:00 noon - 2:00 pm  LUNCH and EXHIBITS OPEN
 
2:00 pm    TECHNOLOGY ISSUES
 
Application and Connectivity Trends in Office Computing
Michael Anzilotti, Intel Corp.
NC-035
 
Network Security Model: Issues and Analysis
Kenneth Majithia, San Jose State University
NC-066
 
High-Speed Communications: Where do Technology and Public Policy Intersect?
Jack Shandle, Electronics Magazine
NC-069
 
3:30 pm    NETWORK IMPLEMENTATION
 
Connecting to the LAN - The Easy Way
Ron Fuller, Intel Corp.
NC-052
 
Token Ring is Gaining Fast on Ethernet
Tad Witkowicz, Crosscomm Corp.
NC-001
 
Meeting the Network Challenge: Running Multiple Network Protocols on a PC
Randy Robinson, Walker Richer & Quinn
NC-046
 
PANEL SESSION: Network Implementation Issues
 
5:30 pm  -- EXHIBITS OPEN (until 7:30 pm)
 
==================================================================
 
          Wednesday, April 29
               TRACK 1
 
9:10 am    PHYSICAL LAYER I
 
Power Management Considerations for Portable PCs Running LAN Applications
Ron Fuller, Intel Corp.
NC-053
 
An EtherCore Family of Application Specific Standard Product
Octavio Morales, NCR Corp.
NC-003
 
10:15 am     PHYSICAL LAYER II
 
Rintegrating Managed Hub and File Server Technologies
Ian Crayford, Advanced Micro Devices Inc.
NC-005
 
The Humble Master
Robert O'Dell, Motorola Inc.
NC-007
 
The Dry Cleaners Architecture
Ariel Hendel, Standard Microsystems Corp.
NC-039
 
Implementing a LAN Connection in Portable PCs
Ron Fuller, Intel Corp.
NC-051
 
12:00 noon - 2:00 pm  Lunch and Exhibits open
 
2:00 pm      PHYSICAL LAYER III
 
A Highly Integrated Product Family for 10BASE-T Applications
Alex Goldberger, Fujitsu Microelectronics Inc.
NC-058
 
Token Ring Bus Master LAN Adapters
Ariel Gomez-Ortigoza, Lantana Technology
NC-065
 
Adapting a WAN Controller to a LAN Environment
Robert O'Dell, Motorola Inc.
NC-025
 
3:30 pm    NEW ARCHITECTURES
 
MultiMedia Transport: The Semiconductor Challenges
Tim Summers, Texas Instruments Inc., UK
NC-018
 
Third Generation X Terminal Architecture
Robert Tobias, LSI Logic Inc.
NC-020
 
CBRMA++: On How to Increase the Performance of a MAC Protocol Without 
a Second Headend Station
Cesure Baransel, University of Alberta, Canada
NC-045
 
XTP, VMTP or TCP/IP?
Bernd Heinrichs, Aachen University of Technology, Germany
NC-043
 
Computer-Aided Development of Protocol Stacks
Gulicher Klempien, Technische Universitat Dresden, Germany
NC-062
 
5:30 pm  ---  CONFERENCE CLOSES
 
---------------------------------------------------------------
 
                  Wednesday, April 29
                       Track 2
 
9:10 am   NETWORK MANAGEMENT I
 
Network Management: SNMP vs CMIP: Are We Asking the Right Question?
Stefanie Sovak, Timeplex
NC-054
 
Using MIB Compliers in Building Object Oriented Management
Applications
Evan McGinnis, 3Com Corp.
NC-016
 
10:15 am     NETWORK MANAGEMENT II
 
Monitoring Heterogeneous Local Area Networks with a View Towards 
Efficient Network Management
Dr. Martin Beer, University of Liverpool, UK
NC-013
 
A Solution for the Cooperative Systems Management
Abdo Abdul Malak, Universite Paul Sabatier, France
NC-041
 
A Graphical Object Verifer and Managed Object Class Pre-Compiler
Nasser Modiri, NET
NC-040
 
Special Network Management Techniques Examined: Capacity and
Performance Management in SR-MRNs
Rolf Hager, Technical University of Aachen, Germany
NC-017
 
12:00 noon - 2:00 pm  LUNCH and EXHIBITS OPEN
 
2:00 pm    HIGH SPEED NETWORKING I
 
An Overview of Packetized Transmission in Wide Area Networks
William Flanagan, FastComm Communications
NC-010
 
Design of Network Interface Boards for High-Speed Serial
Communications and Wide-Area Networking
Mary Hain, SBE
NC-049
 
Performance of Closed Loop Congestion Avoidance in a Cell-Based 
Frame Relay Network
Pat Daley, StrataCom
NC-036
 
3:30 pm     HIGH-SPEED NETWORKING II
 
Combining Bandwidth Balancing and Priority Mechanism in a 
DQDB MAN--Problems and Solutions
Juergen Roethig, University of Karlsruhe, Germany
NC-014
 
G-TAXIchips and the ANSI X3T9.3 FIBER CHANNEL Standard
Ron Cates, Vitesse Semiconductor Inc.
NC-023
 
On A New Variant of the Double Ring Topology for Very Fast LANs and MANs
Wlodek Dobosiewicz and Pawel Gburzynski, University of Alberta, Canada
NC-067
 
5:30 pm  --- CONFERENCE CLOSES
 
-----------------------------------------------------------------------
 
            Wednesday, April 29
                Track 3
 
9:10 am    INTERNETWORKING
 
Internetworking Metrics for Testing Bridges and Routers
Jim McQuald, Wandel & Goltermann Technologies
NC-027
 
Communications Architecture Critical Decisions for Information Managers
Bill Hipp, Dowty Network Systems
NC-056
 
10:15 am  WIDE-AREA NETWORKING
 
How to REALLY Use Frame Relay in a Private Network Configuration
Robert McGuire, Timeplex
NC-031
 
The Economies of Integrating Data and Voice Wide-Area Networks
Mike Vizzi, Micom
NC-008
~~~~~~~
PANEL SESSION:  Internetworking Issues
 
12:00 noon to 2:00 pm  LUNCH and EXHIBITS OPEN
 
2:00 pm     NETWORK IMPLEMENTATION
 
TCP/IP Networking Considerations for Microsoft Windows: 
   Object-Oriented Programming
Larry Lace, Network Research
NC-047
 
FDDI Media Alternatives
Mitch Strobin, Network Peripherals
NC-048
 
Network Backups Across Heterogeneous Environments
Ranga Rangachari, Legato
NC-009
 
3:30 pm   NETWORK IMPLEMENTATION
 
RMON: Interoperable Network Monitoring
Protools 
 
PANEL SESSION: A Status Report on Global Networking
 
5:30 pm  --- CONFERENCE ENDS

 
                             REGISTRATION FORM
                             *****************

-----------------------------------------------------------------------------
                                            |Before        |    After       |
                                            |April 1, 91   |    April 1, 91 |
--------------------------------------------|--------------|----------------|
MON, April 27, 1992 (one short course only) |              |                |
Choose one:  Internetworking [], FDDI [],   | $250.00      |   $295.00      |
             NetworkManagement []           |              |                |
(Includes Short Course notes, coffee, rolls,|              |                |
 drinks, box lunch, pen and pad)            |              |                |
                                            |              |                |
--------------------------------------------|--------------|----------------|
TUE, WED, April 28-29, 1992                 |              |                |
(technical sessions only)                   |              |                |
                                            | $350.00      |   $395.00      |
(Includes Conference Proceedings, coffee,   |              |                |
rolls, drinks, box lunch, pen and pad)      |              |                |
--------------------------------------------|--------------|----------------|
Three-Day Package: MON, TUE, WED,           |              |                |
April 27-29, 1992                           |              |                |
One Short Course & Technical Sessions       | $450.00      |   $495.00      |
Choose one:  Internetworking [], FDDI [],   |              |
             NetworkManagement []           |              |                |
(Includes Conference Proceedings, coffee,   |              |                |
rolls, drinks, box lunch, pen and pad)      |              |                |
--------------------------------------------|--------------|----------------|
Extra Proceedings                           |     $85.00   |   $100.00      |
Please add $10 for shipping handling        |              |                |
--------------------------------------------|--------------|----------------|

Note: 1. A $25.00 processing fee will be charged for registations
         cancelled before March 30, 1992.  No refunds after March 30, 92

      2. Deduct 10% from the total if registering 5 or more persons from
         one company with a single company check.  
******************************************************************************

Name:                                      Telephone: 

Company:                                   Mail Stop:

Address:                       

City:                    Zip:          Country:

Make checks payable to SysTech Research and mail to: 

SysTech Research
1248 Olive Branch Lane
San Jose, CA  95120
FAX: (408)-997-8265

******************************************************************************

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Mar 1992 02:55:12 GMT
From:      whinery@nancy.uhcc.Hawaii.Edu (Alan Whinery)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   standard on programming to interface packet drivers?

Is there a reference on how to write a program to use a packet 
driver? I can find oodles of source code, but no written spec.

Alan
networks@uhunix.uhcc.hawaii.edu


-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 92 11:49:19 GMT
From:      svenn@stud.cs.uit.no (Svenn Hanssen)
To:        comp.protocols.tcp-ip,ri.comp.tech
Subject:   Re: Good Book on TCP/IP

This is a copy of an previous article on this newsgroup (no: 10026) that
should cover your question pretty good:


>>--From: jmb@ideas.com (Jonathan M. Bresler)
>>
>>THE two books are:
>>
>>Internetworking with TCP/IP
>>Volume I Principles, Protocols, and Architecture
>>Douglas E. Comer
>>1991, 2nd Ed. Prentice-Hall
>>
>>Internetworking with TCP/IP
>>Volume II Design, Implementation, and Internals
>>Douglas E.Comer and David L. Stevens
>>1991, Prentice-Hall
>>
>>also get the Network Reading List: TCP/IP, UNIX, and Ethernet
>>from UTnet Network Information Center, Univ.of Texas at Austin
>>utnet@utexas.edu, availble thru anonymous ftp.
>>
>>--From: rory@wri.com
>>
>>The Internet.  By Douglas Comer.  Great book. 
>>
>>--
>>
>>From: Marcus Hayes <mah@DIALix.oz.au>
>>
>>Internetworking with TCP/IP and NFS in a Unix Environment. Written by
>>Michael Santifaller, Addison-Wesley 1991.
>>Gives info on TCP/iP & NFS at a low level, but details the daemons involved
>>and what they all do.
>>


-- 
////         Svenn A. Hanssen            | OFFICE: A042                \\\\
///   Departement of Computer Science    | PHONE : 47+83+44591          \\\
// University of Tromsoe, N-9000 Tromsoe | EMAIL : svenn@stud.cs.uit.no  \\

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Mar 1992 14:19:19 GMT
From:      dedourek@jupiter.sun.csd.unb.ca (John DeDourek)
To:        comp.protocols.tcp-ip
Subject:   Question on Unix sockets

In debugging network applications on a Sun, the command netstat
displays open connections.  What is the easiest way to identify
which processes (i.e. by process id) are associated with each
of the connections.

On a related topic, netstat -A displays the connections, each with
the hexadecimal address of a "protocol control block (PCB)".  What
is the interpretation of this address, i.e. what struct definition
in the *.h files does it address?

John DeDourek -- University of New Brunswick
dedourek@unb.ca     or     dedourek@jupiter.sun.csd.unb.ca

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 92 14:51:26 GMT
From:      sb7c+@andrew.cmu.edu (Shikhar Bajaj)
To:        comp.protocols.tcp-ip
Subject:   Re: good book on tcp-ip-programming?

Try "Unix Network Programming" by Stevens (prentice Hall)


Shikhar

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 92 17:18:55 GMT
From:      bill@falcon.cs.uofs.edu (Bill Gunshannon)
To:        comp.protocols.tcp-ip
Subject:   BOOTing using TCPIP

Does anyone know of the existence of a Boot Prom for a PC with a WD8003
Ehternet card that would allow the PC to boot over a network??

Free would be prefered (especialy with source) but commercial packages will
be considered as well.

Thanks in advance.

bill

-- 

     Bill Gunshannon          |        If this statement wasn't here,
     bill@platypus.uofs.edu   |  This space would be left intentionally blank
     bill@tuatara.uofs.edu    |         #include <std.disclaimer.h>   

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 92 17:21:59 GMT
From:      romkey@asylum.UUCP (John Romkey)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: standard on programming to interface packet drivers?

whinery@nancy.uhcc.Hawaii.Edu (Alan Whinery) writes:
>Is there a reference on how to write a program to use a packet 
>driver? I can find oodles of source code, but no written spec.

The packet driver specification lives on vax.ftp.com. You can retrieve it
via anonymous FTP. There are three forms of it available in the pub directory:
	packet-d.ascii		ASCII text file
	packet-d.mss		FinalWord source file
	packet-d.prn		HP Laserjet II format file

-- 
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice: 617 942-0915

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Mar 1992 17:36:03 GMT
From:      sukonnik@abyss.zk3.dec.com (Vladimir Sukonnik OSG)
To:        comp.protocols.tcp-ip
Subject:   RE: LPD

LPD is now defined by RFC 1179.

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Mar 1992 19:39:39 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: LPD

In article <1992Mar26.173603.4589@decvax.dec.com> sukonnik@decvax.dec.com writes:
>LPD is now defined by RFC 1179.

Too bad it doesn't describe the LPR/LPD protocol.  It defines
something that is close, but there are differences between the RFC and
the protocol that BSD, et al implements.  The RFC was written to allow
PC's to be able to be servers/clients more easily, but that required
some changes to the protocol.  Think of it more as what LPR/LPD could
be, not what they are today.

Warner
-- 
Warner Losh		imp@Solbourne.COM	  MMP to DoD #882
"You better stay away from him, he'll rip your lungs out Jim,
 He's looking for James Taylor" -- Werewolves of Boulder WZ

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 92 20:12:43 GMT
From:      wmah@ersys.edmonton.ab.ca (Wayne Mah)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Where has the Bootp command gone in recent Net.exe

Just a note on bootp for KA9Q (or NOS).  The version I have allocates
memory for the bootp via static array is thus is limited to hold only
12 bootp entries.  Hopefully the code has been modified to allocate
this structures dynamically in a newer version.  Otherwise, if you
have more than 12 bootp clients you are out of luck.

Wayne Mah              wmah@ersys.edmonton.ab.ca
Edmonton Remote Systems:  Celebrating 10 years of service to Northern Alberta

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 92 00:34:19 GMT
From:      moliver@pyramid.com (Mike Oliver)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over IEEE 802.5 (Token Ring)

In article <1992Mar25.235743.14508@sequent.com> demon@sequent.com (Dave Richards) writes:
>
>I am currently implementing the IP over IEEE 802.5 support for Sequent's
>ptx/TCP/IP product.  I have read through RFC 1042 and have a few questions
>about the Largest Frame field conventions.  (Comments from other Token Ring
>implementor's would be more than welcome.)

I'm still designing.  I hope to be an implementor someday soon.

>It seems to me that the RFC implicitly requires the IP MTU to be one of
>the legal LF values.

I don't read it that way.  If you're referring to the table on page 9
of RFC 1042, I think that's simply a breakdown of the IP MTU values
corresponding to what the RFC thinks are the different "largest frame"
values.

There's no implication that the actual IP MTU value must be chosen from
that table, and subsequent paragraphs recommend that IP MTU's be
configurable up to at least 2002 bytes (not a value in the table) and
state that an implementation is not required to support an IP MTU
smaller than the default 576 octets (again, not a value in the table).

All that the RFC says is that the LF field can be used to qualify
whatever MTU was configured in IP.  It gives you a chance to discover
that the configured MTU is too large for the route to the destination
and that something needs to be adjusted.

(Incidentally, just having LF smaller than the configured MTU doesn't
guarantee that the MTU is reasonable.  LF is manipulated by bridges to
describe the maximum frame length that can be carried by the bridges
and the network segments that make up a route.  It says nothing about
the frame length that can be accommodated by the end stations.  The RFC
assumes that end stations can support frames up to the maximum size
supported by the media, which isn't necessarily true.)

>                      (BTW: My IBM document 3rd edition uses a different
>set of mappings than are in the RFC.)

So does mine :-)  It also defines meanings for the bit combinations
that the RFC says are "reserved for future use".  Then again, the IBM
manual is dated 9/89, the RFC is dated 2/88.  Source routing didn't
make it into IEEE Std 802.5-1989 (dated 6/89), so that's no help.

The values in the IBM manual _almost_ agree (one differs) with those in
the TI TMS380 manual, dated 6/90.  I'd trust either of those over the
RFC (which elsewhere claims that 28 + 4 + 8 == 32), and if pushed I'd
go for the TI values.  I think the RFC is in need of repair.

The numbers for I-field length are

	LF	TI TMS380	IBM T/R Arch Ref	RFC1042

	000	516		516			516
	001	1470		1500			1028
	010	2052		2052			2052
	011	4472		4472			4050
	100	8144		8144			8196
	101	11407		11407
	110	17800		17800

LF == 111 is the initial value in a broadcast frame, according to IBM
and TI.  Actually, the bullet on p2-9 of SC30-3374-02 says "111 - used
in all-routes broadcast frames", but the text at the top of the page
doesn't make that distinction.  I'd put 111 in an all-routes or a
single-route broadcast frame - it doesn't matter.

The IP packet shares the I-field with an 8-byte 802.2 SNAP header, so
the max IP MTU length (which is what the RFC shows) is 8 smaller than
the numbers above.

If a response comes from the local ring it probably won't contain a
RIF, but the RFC rightly says that you should be prepared to accept a
RIF with no entries (and presumably LF == 111, or whatever you put in
there).  The RFC doesn't specify how you decide whether your MTU is
reasonable in these cases.  I'd check it against the maximum local-ring
frame length, which in turns depends on the local-ring bit rate.

(Incidentally, the IBM documentation also disagrees with the RFC in the
definition of the Broadcast Indicator bits.  IBM states that 0XX is
non-broadcast, 10X is all-routes broadcast, and 11X is a single
broadcast.  The RFC and the TI manual say that 000 is non-broadcast,
100 is all-routes broadcast, 110 is single-route broadcast and other
values are "reserved for future use".  The definitions are compatible
today, but "future use" could change that.

The TMS380 manual goes further; it defines 111 in the Broadcast
Indicator bits as "single-route broadcast with non-broadcast response",
and redefines 110 to mean "single-route broadcast with all-routes
response".  This usage of 110 agrees with the RFC.)


>If the IP MTU is not an exact LF value, then which LF value should be sent?
>If we round up, then a remote node could send us a packet we can't receive.
>If we round down, we could send a packet larger than the value reported.

If you're sending a broadcast frame, use 111.  I can't find anything
that says what to put in a non-broadcast frame.  I'd use the LF value
that was in the RIF that you selected when you did your route
discovery, or maybe 111 if you're using a preconfigured route.

If you want to stick with the RFC, which doesn't know about 111, then
you should use "a value at least as large as the supported MTU" [p9,
just above the LF table] ... ie round up.

As you note, IP at the other end can then send you a packet larger than
your MTU, but that's no different from IP operation on any other LAN.
You can't prevent it, and you deal with it same way you'd deal with it
on, say, an 802.3 network.

>Also, the logic for accepting or discarding frames based on the MTU and
>the LF value in the incoming packet seems to assume that the MTU is an
>even LF value.  Is this correct?  This would mean that I should only allow
>a user to set the MTU to one of the 4/7 legal values.

I don't understand this paragraph.  Can you explain your reasoning ?

The MTU can take any value, although the recommendation is that it be
user-configurable up to at least 2002.  The magic 2002 is a limit
imposed by "some current implementations".

>Another possibility would be to always generate 111 (unspecified) and
>never check incoming frames.

By all means send 111 in broadcasts - it's recommended by IBM, so it
must be OK :-)

But I really think you should check the value in all incoming frames,
and follow one of the recommendations in the RFC if the max frame
length on that route is smaller than the MTU - ie don't use that route,
or downgrade the MTU for that route.  An implementation in which
full-length frames get silently dropped while smaller ones sent on the
same route get through will earn you the ire of network administrators
everywhere.

As I mentioned, there's no guarantee that the destination will be able
to accept the frame, but at least it'll get to the destination network.

>                              This would allow the administrator to specify
>whatever he wants across the whole network.

Only if you honour the LF field in incoming frames.

>Any thoughts, opinions, etc?

Just my opinions.  I'd particularly like to here from anyone out there
who knows of any plan to update RFC1042.

Regards, Mike.

moliver@pyramid.com
{allegra,decwrl,hplabs,munnari,sun,utai,uunet}!pyramid!moliver

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Mar 1992 02:14:27 GMT
From:      skl@cs.sfu.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet mask brain-teaser!

In article <1992Mar25.095430.38805@kuhub.cc.ukans.edu>,
 paul@kuhub.cc.ukans.edu wrote:
>                                      129.237.80.8 (Ultrix)
>                                     /
>router ethernet port  X--------------
>                                     \129.237.129.1 (PC running Clarkson CUTCP)
>...
>When 129.1 tries to connect to the 80.8 the IP address will be outside
>the local subnet, so the default gateway will be tried. The router
>should take the request and issue an ICMP redirect to the initiating
>PC redirecting to a "direct" connection.
>
>What I don't know is whether the router will actually do that, ...

No, the router won't send the ICMP-redirect in this case, since
ICMP-redirect was designed for intra-subnet redirection only.
Since 129.237.129.1 and 129.237.80.8 are on different subnets
according to your 0xFFFFFC00 netmask, the router will quietly
forward the datagram back onto the same Ethernet it came in
on without generating an ICMP-redirect.  This behaviour is
specified in the relevent RFC's.

In your situation, you might want to consider leaving the hosts'
netmask at 0xFFFF0000 and enable proxy-ARP on your (subnet aware)
routers.  This way your whole class B network will look unsubnetted
to the hosts and the 129.237.129.1 and 129.237.80.8 above will
be able to communicate directly on their common Ethernet.

...Sam
-- 
Samuel Lam <skl@cs.sfu.ca>
Network Support Group, Centre for Systems Science
Simon Fraser University, Burnaby, B.C., Canada

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 92 02:46:41 GMT
From:      moliver@pyramid.com (Mike Oliver)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over IEEE 802.5 (Token Ring)

In article <180761@pyramid.pyramid.com> moliver@pyramid.com (Mike Oliver) writes:
>           ... just having LF smaller than the configured MTU doesn't
>guarantee that the MTU ...
			       ^^^^^^^--- larger, not smaller, dammit. I
meant larger.  You know I meant larger.


I will proofread my postings more thoroughly in the future.
I will proofread my postings more thoroughly in the future.
I will proofread my postings more thoroughly in the future.
I will proofread my postings more thoroughly in the future.
I will proofread my postings ...


Cheers, Mike.

moliver@pyramid.com
{allegra,decwrl,hplabs,munnari,sun,utai,uunet}!pyramid!moliver

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Mar 1992 06:26:43 GMT
From:      eajjs@cbnewsf.cb.att.com (john.sottile)
To:        comp.protocols.tcp-ip
Subject:   AT&T System V.4 Stargroup TCP/IP Slip Driver


I am trying to set up an asynchronous link not associated with a tty
device (via several other mechanisms -- Mostly streams based async
drivers) and would like to know if anyone out there has tried the
following:

I would like to set up a call between 2 machines via some predefined
call setup procedure.  After the call setup and verification, I would
like the async connection just established to be passed to the slipd
(AT&T Slip Daemon) where the slip protocol requests can be processed,
etc.

I am not that familiar with STREAMS, but both the SLIP driver and the
call setup are streams based.  I know that I can do (in AT&T's 
UNIX V.4) ifconfig sl0 192.1.1.20 192.1.1.100 to let the tcp/ip
driver know about the new slip interface, what I can't seem
to figure out is how to get the device (async streams device) to
"attach" to the sl0 slip streams device.

Has anyone tried this or have any ideas on how to proceed?


=============================
John Sottile                             "Home is where the Software Grows"
AT&T Creative Software                   #include <std/disclaimer/who-me?.h>
jjs@addams.att.com



-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Mar 1992 08:16:52 GMT
From:      ae2@cunixa.cc.columbia.edu (Amiran Eliashvili)
To:        comp.protocols.tcp-ip
Subject:   10Base-F


I am looking for documentations or any litrature on the following
subject:

        FIBER OPTIC-BASED HIGH-SPEED LOCAL AREA NETWORK.

Are there any good books or articles on the subject?

Please reply by e-mail to ae2@cunixa.cc.columbia.edu. Thanks.



-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 92 13:30:14 GMT
From:      barat@platon.Greco-Prog.FR (barat Vincent)
To:        comp.protocols.tcp-ip
Subject:   programming tools for TCP/IP on PCs


	Can anybody tell me where can I find TCP/IP for PCs ?

	I want both a user version of TCP/IP and a development version
	(i.e. with the socket interfaces and librairies).

	Is it possible to find it free, and if not, what companie
	sells it ?

	Can anybody give me the address of FTP Software inc ?

	Thanks to answer me quickly, and excuse me for my poor english !

===============================================================================
	From : barat@geocub.greco-prog.fr

	Vincent BARAT  Universite Bordeaux I - Maitrise Informatique
	tel: 56 05 39 89 - 9 rue Berthollet  - 33160 St Medard - FRANCE
===============================================================================

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Mar 1992 14:59:46 GMT
From:      dzubin@skorpio.usask.ca (Thomas Dzubin)
To:        comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc
Subject:   FAQ?  Review of various tcpip products for VMS?


Yet another FAQ:  About a year ago, I seem to remember someone doing an
informal review of the various TCP/IP packages for VAX/VMS including
UCX, WINTCP, Wollogong, CMU-TEK, etc.
Has this hit the permanent bit bucket in the sky or does someone have
a copy on an FTP-able site?
I'm looking for something that compares/contrasts the packages along with
listing the good & bad points of each.

Thomas Dzubin
Networks Coordinator
Saskatchewan Institute of Applied Science & Technology (SIAST), CANADA
dzubin@skorpio.usask.ca  or  dzubint@sask.usask.ca

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Mar 1992 15:46:27 GMT
From:      rypma@hppad.waterloo.hp.com (Ted Rypma)
To:        comp.protocols.tcp-ip
Subject:   Re: Access to PUSH functionality from socket-based TCP

> In BSD socket-based TCP implementations, how do you get access to the
>   PUSH BIT functionality?
> 
> Does the implementation make decisions about when to PUSH that are
>   outside of your control?
> 
> -- 
> Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
> mleech@bnr.ca                  P.O. Box 3511, Stn. C   |are my own, and not
> ml@ve3mdl.ampr.org             Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs

You can certainly turn TCP PUSH on and off on a connection/socket basis.

Extract from X11 code:

#ifdef TCP_NODELAY
        fromlen = sizeof (from);
        if (!getpeername (newconn, &from.sa, &fromlen))
        {
            if (fromlen && (from.sa.sa_family == AF_INET))
            {
                int mi = 1;
                setsockopt (newconn, IPPROTO_TCP, TCP_NODELAY,
                           (char *)&mi, sizeof (int));
            }
        }
#endif /* TCP_NODELAY */

The TCP_NODELAY essentially forces immediate output and set the PUSH bit in
the TCP header.

Ted Rypma
HP Panacom Division
Waterloo, Ontario

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Mar 1992 15:54:27 GMT
From:      papowell@amber.sdsu.edu (Patrick Powell)
To:        comp.protocols.tcp-ip
Subject:   Re: LPD

In article <MAILQUEUE-99.920324134511.336@ramrod.lmt.mn.org> chrisc@ramrod.lmt.mn.org (Chris Cox  W0/G4JEC) writes:
>Can anyone point me at a detailed specification of the LPD protocol?
>
>I understand that currently it is not defined by any RFC.
>
>Thanks...
>
>Chris

I suggest that you get the source code to PLP (Public Line Printer),
a clone of the LPD source from Berkeley.  It has substantial documentation
on the protocols.  In fact,  you can turn on DEBUGGING and set up
a 'mini lpd' and watch what is happening.

I quietly note that there are tremendous security loopholes in the
current versions of LPR/LPD and PLP.   A new version of PLP
will be coming out Real Soon Now that should help close most
(all that I and some other people) have found.  SUN has fixed
several of these as well.

Prof. Patrick Powell, Dept. Electrical and Computer Engineering,
San Diego State University, San Diego, CA 92182-0190
(619) 594-7796;  Office Eng 403G; FAX (619) 594-3703

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Mar 1992 16:33:00 GMT
From:      sukonnik@abyss.zk3.dec.com (Vladimir Sukonnik DEC TCP/IP for VMS)
To:        comp.protocols.tcp-ip
Subject:   Re: LPD

I have the BSD sources and I do not see it to be very different from the
protocol (if you dare to call it that) descirbed in RFC 1179. I am curious
what exactly you had in mind when you said that the RFC is tuned to help
PCs. You can also find somewhat detailed description of LPR/LPD in 
Stevens's book "UNIX Network Programming".

	Regards,
	Vladimir...

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Mar 1992 16:52:13 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: good book on tcp-ip-programming?

Try:
   Internetworking with TCP/IP, Vol. I, by Comer
   Internetworking with TCP/IP, Vol. II, by Comer and Stevens
   UNIX Network Programming, by Stevens

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Mar 92 17:11:34 GMT
From:      demon@sequent.com (Dave Richards)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over IEEE 802.5 (Token Ring)


Thanks for the response, by the way, that's exactly the sort of discussion
I'm interested in...

The crux of my problem lies in the handling of the LF field on input.  If
the LF is >= the MTU of the receiver then the receiver should accept it.
If the LF < the MTU then the receiver should drop it.  If this check is
dubious to begin with then circumventing it is the easiest way to deal with
it.  However, the RFC had some intent in mind for the checking so it seems
worth trying to make it work.

Okay, let's create a scenario where two RFC 1042 compliant hosts want to
interoperate where LF[x] < MTU < LF[x + 1].  Let's also assume LF[7] is
equal to infinity in the sense that no number is > LF[7].  MTU is the same
for both hosts.

Now, host 1 sends an ARP request to host 2 with say LF[7].  Host 2's input
code says LF[7] >= host 2's MTU and so the packet is processed.  Host 2
now responds to host 1 with an ARP reply.  What value LF does host 2 use in
the response?

(1) Round down LF[x].  Host 1 receives host 2's reply.  The input code says
guess what?  LF < MTU drop the frame.  This assumes that host 1 compares LF
to MTU directly.  If host 1 converted MTU to an LF then success depends
on which LF.  For example, if host 1 chooses LF[x] (round down) then there
is joy.  If host 1 chooses LF[x + 1] then the check fails and the frame is
rejected.

(2) Round up LF[x + 1].  Host 1 receives host 2's ARP reply.  LF[x + 1] is
> MTU so the reply is processed.  This would appear to be fine.  Let's
change the original scenario now and assume that host 1 and host 2 have
different MTUs.  (This is a misconfiguration but this checking is being
done for exactly cases like this so it is relavent.)  Let's assume host
1's MTU > host 2's MTU.  A black hole now exists in one direction (host
1 -> 2).  Obviously the configuration doesn't work, BUT both ARP caches
are filled.  When diagnosing the problem using a sniffer, is it easier to
find the problem when the ARP negotiation succeeds or fails?  This is the
sort of underlying question?  If the answer is it doesn't matter, then
why go through any of this bullshit?  Always send LF[7], and never check
on input.  The administrator will know something's wrong soon enough and
will then resynch the two MTUs.  If it is easier to diagnose the problem
when the second ARP cache doesn't fill, then we should do this processing
and do it the same way on all IP hosts.

Where does that put us?  Always using LF[7] for broadcasts makes sense.
(My code currently doesn't do that in the IP broadcast/single route
broadcast case, but I'm willing to change that.)  That's the easy part
what about all this LF setting and checking stuff, what method (shy of
ignoring the LF check on input guarentees the most interoperability).

My assertion in the first message, the RFC implies MTU = LF[0-6],
is based on the observation that unless MTU is really a member of LF then
interoperability problems exist which the RFC does not address.

	Thanks in advance,

	Dave Richards

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 92 17:13:21 GMT
From:      bob@pigkgn.ibm.com
To:        comp.protocols.tcp-ip
Subject:   Reading entire IP datagrams

Does anyone out there know how to read an entire IP datagram using a raw
socket in AIX 3.2?  I know there is a new way to append your own header
onto a datagram, so there should also be a way to read the entire datagram.

Is this possible to do with a raw socket, or do I need to get down to the
interface level to accomplish this task?

Any help would be greatly appreciated!!

Bob Van Gulick.
IBM Kingston

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Mar 92 20:15:07 GMT
From:      dc@micronics.com (Darren Croke)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over IEEE 802.5 (Token Ring)

In article <1992Mar25.235743.14508@sequent.com> demon@sequent.com (Dave Richards) writes:
>
>I am currently implementing the IP over IEEE 802.5 support for Sequent's
>ptx/TCP/IP product.  I have read through RFC 1042 and have a few questions
>about the Largest Frame field conventions.  (Comments from other Token Ring
>implementor's would be more than welcome.)
>
>It seems to me that the RFC implicitly requires the IP MTU to be one of
>the legal LF values.  (BTW: My IBM document 3rd edition uses a different
>set of mappings than are in the RFC.)
>
>If the IP MTU is not an exact LF value, then which LF value should be sent?
>If we round up, then a remote node could send us a packet we can't receive.
>If we round down, we could send a packet larger than the value reported.
>

The remote node won't send you a larger packet than you can receive 
because the tcp's will negotiate an acceptable maximum segment size
based on the MTU.

-- 
 Darren Croke         Micronics Computers
 dc@micronics.com     System Business Group
                          (510) 651-2300

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 1992 20:58:09 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: LPD

In article <MAILQUEUE-99.920324134511.336@ramrod.lmt.mn.org> chrisc@ramrod.lmt.mn.org (Chris Cox  W0/G4JEC) writes:
>Can anyone point me at a detailed specification of the LPD protocol?

"Unix Network Programming" by Stevens.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 92 22:11:22 GMT
From:      toppin@melpar.UUCP (Doug Toppin)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   arp table entry degrading

We are running TCP/IP on our Ethernet and have run into some
problems associated with a physical address change being detected by ARP.
What I am seeing is this:
    * if I make a connection to a host once every 30-minutes
        I see (using an Ethernet analyzer) an ARP request
        from my client host on each connection, therefore the entries
        in the arp table are being deleted at 20 minutes intervals
    * if I make a connection at an interval of less than 20 minutes
        the physical address already contained in the client
        arp table is used
        - the degrade time in the arp table for that server host is reset
            to zero on each subsequent connection attempt (even if
            I am unable to connect to that host)
        - if the server host physical address changes my host never
            detects the change because the arp table entry never
            makes it to the 20 minute point at which it is automatically
            deleted
        - my TCP does not provide any function for an application to
            manipulate the arp table therefore we cannot clear the
            old physical address for the host when we detect a
            failed connection attempt
My question is this:
    - is there a means of indicating to TCP via the socket/connect
        calls that it should arp?
Please note the following:
    - our operating system is a real-time memory resident one known
      as PSOS+ with the TCP/IP being PNA+, this provides only the basic calls
      for socket and datagram usage
    - there is no gethostbyname function, we have to use the IP address
      rather than the host name in all calls because we have no disk
      to keep the hosts file
    - there is not a console that provides any means of looking at
      the arp table
    - the arp table is a static space within the os load image that
      we cannot access
Please drop me a line if you can give me some insight into this
and I will post useful replies.
thanks
Doug Toppin
uunet!melpar!toppin

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 92 22:53:08 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over IEEE 802.5 (Token Ring)

In article <1992Mar27.171134.6520@sequent.com> demon@sequent.com (Dave Richards) writes:
>
>Okay, let's create a scenario where two RFC 1042 compliant hosts want to
>interoperate where LF[x] < MTU < LF[x + 1].  Let's also assume LF[7] is
>equal to infinity in the sense that no number is > LF[7].  MTU is the same
>for both hosts.
>
>Now, host 1 sends an ARP request to host 2 with say LF[7].  Host 2's input
>code says LF[7] >= host 2's MTU and so the packet is processed.  Host 2
>now responds to host 1 with an ARP reply.  What value LF does host 2 use in
>the response?
>
>(1) Round down LF[x].  Host 1 receives host 2's reply.  The input code says
 ...
>(2) Round up LF[x + 1].  Host 1 receives host 2's ARP reply.  LF[x + 1] is
 ...

Neither one, it should send LF[7], if that is the value it received and
cached in its RIF table.  Hosts shouldn't modify LF's based on their own
MTUs, since as Mr. Oliver points out, the LF is supposed to characterize 
the bridges, not the endpoints.

To look at it another (perhaps better) way, your MTU is the maximum
length packet you will *send*, but the LF value that the other guy should
see ought to be related to the maximum packet size that you can *receive*
(via the specified path).  That's why he compares it to his MTU, to see
whether what he sends will get to your end.  If you really want to
fiddle with LFs you send, you should fiddle them depending on the size of
the largest packet you can receive, which may be greater than your MTU.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Mar 1992 23:37:18 GMT
From:      jon@hook.corp.mot.com (Jon Whalen)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Implementations + HW/SW products

Net.folks:

I have been asked to gather information on available implementations of TCP and 
IP on all combinations of OS, Network, and application layer software.
(I hate being so narrowly focused :-)

Anyway, I'd like any information anyone can give me on any implementation of
TCP/IP on Any OS + Any Network. 
It doesn't matter if it's "native" (e.g. UNIX + TCP/IP/Ethernet, 
TCP/IP/802.5, etc.) or "piggy-backed" on some other protocol stack 
(i.e. DOS + TCP/IP/IPX/Ethernet)

I'm also interested in products/services which use TCP/IP. Of special interest
would be information about:
a) which (if any) commercial data services (like CompuServe, etc.) either 
use TCP/IP in their network and/or have IP gateways into their network; 
b) which routers talk IP (I think thats most of them);
c) what gateways exist from other protocols to IP 
(like FastPath/GatorBox DDP/IP gateways);
d) any applications which use TCP/IP.
e) etc., etc.

Please send e-mail to jon@hook.corp.mot.com. Any information is appreciated!

AtDhVaAnNkCsE
--jon

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 92 23:52:36 GMT
From:      sss@netcom.com (Small Systems Solutions)
To:        comp.protocols.tcp-ip
Subject:   Re: LPD

In article <kt7331INNhng@early-bird.think.com> 
	barmar@think.com (Barry Margolin) writes:

>"Unix Network Programming" by Stevens.

Agreed, especially if you're concerned with all the file locking
nonsense and the business of using the permission bits to start/stop
queuing and printing.

If you're interested in writing clients, see also:

	RFC1179 - Line Printer Daemon Protocol
				 L. McLaughlin III


-- 
Small Systems Solutions                   1563 Solano Avenue, Suite 123
sss@netcom.com                                  Berkeley, CA 94707-2116

The above-expressed opinions aren't necessarily

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 92 00:15:33 GMT
From:      moliver@pyramid.com (Mike Oliver)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over IEEE 802.5 (Token Ring)

In article <1992Mar27.171134.6520@sequent.com> demon@sequent.com (Dave Richards) writes:
>
>Thanks for the response, by the way, that's exactly the sort of discussion
>I'm interested in...

It's certainly useful for me.

If anyone besides myself and Dave is involved in IP over Token Ring I'd
appreciate your comments.  If no-one else is interested I guess we
should take it to email.

Having said that, I'm going to be out of the office for a couple of
weeks from next Tuesday, so if you do follow up please cc: me directly.
I don't know how quickly we expire comp newsgroups, and I'd hate to
lose a contribution to the thread.

>The crux of my problem lies in the handling of the LF field on input.  If
>the LF is >= the MTU of the receiver then the receiver should accept it.
>If the LF < the MTU then the receiver should drop it.

Yes.

>                                                       If this check is
>dubious to begin with then circumventing it is the easiest way to deal with
>it.  However, the RFC had some intent in mind for the checking so it seems
>worth trying to make it work.

The LF value can tell you that you shouldn't send IP traffic on a given
route.  If LF < MTU, then the route can't carry a full-length IP packet
and you shouldn't send _any_ IP traffic over that route.  In this case
you discard the ARP packet and hope there's at least one other ARP
reply making its way to you over some other route that _can_ carry a
full-length IP packet.  If such a reply arrives, you have a usable
route.

However, the LF value can't guarantee the converse situation.  That is,
if LF >= MTU you're guaranteed that a full-length IP packet can make it
to the destination ring, but you still don't know whether the
destination station can accept it.  That's pretty much the situation
you're in on any other network.

So it is necessary, but not sufficent, that LF >= MTU.  I think that's
the limit of what you can do with the LF field, and I think that's what
the RFC had in mind.

>Okay, let's create a scenario where two RFC 1042 compliant hosts want to
>interoperate where LF[x] < MTU < LF[x + 1].  Let's also assume LF[7] is
>equal to infinity in the sense that no number is > LF[7].  MTU is the same
>for both hosts.

I'm with you so far :-)

>Now, host 1 sends an ARP request to host 2 with say LF[7].  Host 2's input
>code says LF[7] >= host 2's MTU and so the packet is processed.

The fact that the frame arrives with LF[7] means that it didn't cross
any bridges.  This shouldn't happen often, since Host 1 should have
reached Host 2 with a non-broadcast frame (no RIF, hence no LF) before
sending a broadcast frame.  I suppose it could happen if Host 2
attached to the network at just the right time, or if Host 1 has a
naive implementation of ARP.  In any case, you have to be prepared to
deal with the situation.

(You might think you could just ditch any frame that comes in with
LF[7] and wait for Host 1 to send a non-broadcast frame, but in that
may never happen.  For instance, a naive implementation might always
send ARP frames as broadcasts.  This is permitted by the RFC.  So we
have to deal with it.)

Host 2 should (IMO) take this frame to mean that (i) Host 1 is on the
local ring, and therefore (ii) the route between the hosts can carry a
frame of the size permitted by the ring bit rate and token hold timer
(that's THT in IEEE-speak, T(any_token) in IBM-ese).

The default 10ms hold time allows ~4500 bytes on a 4Mbps ring, or
~18000 bytes on a 16 Mbps ring.  Taking out the MAC and LLC overhead (a
whopping 32 octets) leaves room for an IP packet that's probably going
to be larger than Host 2's MTU, so it can accept the route.

>                                                                 Host 2
>now responds to host 1 with an ARP reply.  What value LF does host 2 use in
>the response?

If the request came in as an all-routes broadcast, Host 2 should reply 
in a non-broadcast frame whose LF matches that of the request, ie LF[7].

If the request came in as a single-route broadcast, the response will
go back as an all-routes broadcast, so Host 2 should use LF[7].  You
could argue that Host 2 should reply in a non-broadcast frame since it
knows that Host 1 on the local ring, but I think it's better not to
introduce this special case.

>(1) Round down LF[x].  Host 1 receives host 2's reply.  The input code says
>guess what?  LF < MTU drop the frame.  This assumes that host 1 compares LF
>to MTU directly.  If host 1 converted MTU to an LF then success depends
>on which LF.  For example, if host 1 chooses LF[x] (round down) then there
>is joy.  If host 1 chooses LF[x + 1] then the check fails and the frame is
>rejected.

Disastrous.  Don't do this :-)

>(2) Round up LF[x + 1].  Host 1 receives host 2's ARP reply.  LF[x + 1] is
>> MTU so the reply is processed.  This would appear to be fine.  Let's
>change the original scenario now and assume that host 1 and host 2 have
>different MTUs.  (This is a misconfiguration but this checking is being
>done for exactly cases like this so it is relavent.)  Let's assume host
>1's MTU > host 2's MTU.  A black hole now exists in one direction (host
>1 -> 2).  Obviously the configuration doesn't work, BUT both ARP caches
>are filled.

Not as bad as (1), but still pretty bad.  But no worse than say,
Ethernet.  Don't do this either.  This is what the RFC recommends, so
you might want to default to this but recommend that the administrator
reconfigure to LF[7].

>             When diagnosing the problem using a sniffer, is it easier to
>find the problem when the ARP negotiation succeeds or fails?  This is the
>sort of underlying question?

A sniffer isn't my tool of choice for diagnosing IP MTU problems.  It'd
be nice if the protocol implementations actually told someone that they
were discarding packets because of MTU violations, but you can't depend
on that.  With a sniffer you might get a clue from the fact that small
frames were getting through and were eliciting responses while large
ones were vanishing without trace.

>                              If the answer is it doesn't matter, then
>why go through any of this bullshit?  Always send LF[7], and never check
>on input.

Because looking at LF allows you to disqualify unusable routes and
choose a route that at least has a chance of working.

I won't attempt a diagram, but imagine 3 rings (A,B,C) with one bridge
between each pair of rings (AB, BC, AC).  Host 1 is on ring A and Host
2 is on ring B.

Now suppose Host 1 sends out an all-routes ARP request.  Host 2 sees
two copies, one that came through bridge AB and one that came through
AC and BC.  If AB can't handle large frames and sets LF < Host 2's MTU.
then Host 2 knows that it's useless to reply on that route.  But if AC
and BC _can_ handle large frames, the ARP that came on that route will
have LF >= MTU and Host 2 can respond on that route.  So a route is
established from Host 1 to Host 2.  It's not the most direct route, but
it _can_ carry frames of the required size.

If the hosts didn't look at the received LF, they'd have chosen the
route through AB and you'd have short packets getting through while
longer ones got discarded at the bridge.  If you were lucky the bridge
might mention that it was dropping frames.  If you a sniffer on each
ring you'd see frames on one that never showed up on the other, but it
might take a while to notice that and even longer to figure out why it
was happening.

Notice that this has nothing to do with an MTU mismatch.  MTU
mismatches can happen on top of this, even once you've established that
the route has LF >= MTU.

>           The administrator will know something's wrong soon enough and
>will then resynch the two MTUs.  If it is easier to diagnose the problem
>when the second ARP cache doesn't fill, then we should do this processing
>and do it the same way on all IP hosts.

The administrator will have to figure this out the same way that he
would have figured it out if the hosts were on an Ethernet.  The best
we can do is to try to make his life no more difficult than it already
is, and we can do that by taking note of LF in received frames.

>Where does that put us?  Always using LF[7] for broadcasts makes sense.
>(My code currently doesn't do that in the IP broadcast/single route
>broadcast case, but I'm willing to change that.)

I think that's what you should be doing, although the RFC doesn't
mention it.  The RFC has been overtaken by the IBM standard, and I
think we're in a lag period waiting for IEEE and the RFC to catch up.
I can't see how LF[7] can break anything that's been properly
implemented.

>                                                  That's the easy part
>what about all this LF setting and checking stuff, what method (shy of
>ignoring the LF check on input guarentees the most interoperability).

You _must_ check the received LF.  It doesn't guarantee
interoperability, but if you don't do it there are multi-ring networks
that will cause you no end of grief.

>My assertion in the first message, the RFC implies MTU = LF[0-6],
>is based on the observation that unless MTU is really a member of LF then
>interoperability problems exist which the RFC does not address.

It's by no means the first RFC to have a loose end.  Some even have two
or three :-)

Seriously, the interoperability problems are there, they spring from
the connectionless nature of IP, and they can't be solved by looking at
a Token Ring LF.  They can, however, be made much worse by _not_
looking at a Token Ring LF.

>	Thanks in advance,

You're very welcome.

Cheers, Mike.

moliver@pyramid.com
{allegra,decwrl,hplabs,munnari,sun,utai,uunet}!pyramid!moliver

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28 Mar 92 07:15:24 GMT
From:      maffeis@ifi.unizh.ch (Silvano Maffeis)
To:        comp.protocols.tcp-ip
Subject:   >> Seeking programming examples or technical book <<

Hello! We are looking for short C-sources or technical documents
demonstrating how low-level tcp/ip programming can be done on SunOS 4.1:
i.e. we would like to read/alter ip-packet header infos, program
ICMP examples etc.

Any pointer is really appreciated.
Please e-mail directly. (I will post a summary)

--silvano

-- 
Silvano Maffeis, CS Dept. University of Zurich, Switzerland
  email: maffeis@ifi.unizh.ch  
  voice: +411 257 43 27

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 92 08:06:13 GMT
From:      mccanne@horse.ee.lbl.gov (Steven McCanne)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.dcom.lans.ethernet,alt.sources.d
Subject:   Re: etheraddr.c -- get host's phys. ether address (SunOS and SVR4)

Under SunOS, a SIOCGIFADDR on a streams nit descriptor will give the
underlying ethernet address.

Steve

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 92 14:57:35 GMT
From:      greenie@drycas.club.cc.cmu.edu
To:        comp.protocols.tcp-ip
Subject:   "Future" TCP/IP and Security?

Forgive me if this is a frequently discusses topic, but I've never been
in this newsgroup before (I figured it'd be the best place to ask my
question, however... )

Does anyone know of any future implementations of TCP/IP or modifications
to the current processes which would improve security?  IE, preventing
"anybody" from TELNETting to the SMTP port and sending anonymous hate
mail and other such things like that?

Perhaps there are some RFC's out there that I should read, and maybe someone
might be able to point me to them?

Thanks very much for your attention...

Andy, greenie@drycas.club.cc.cmu.edu

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 92 00:40:00 GMT
From:      nader@cup.portal.com (Nader - al-Twaijri)
To:        comp.protocols.tcp-ip
Subject:   tcpip in x25

Are there any TCP/IP/X.25 implementations for Apple UNIX that complies with 
RFC-877 (encapsulating TCP/IP in X.25) -- I know that it is available for SUN.
I would like to use it to connect to the Internet from overseas.
 
Thank you for your help.
 
--
Nader.
 

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 1992 23:42:43 +0100
From:      urlichs@smurf.sub.org (Matthias Urlichs)
To:        comp.protocols.tcp-ip
Subject:   Re: AT&T System V.4 Stargroup TCP/IP Slip Driver

In comp.protocols.tcp-ip, article <1992Mar27.062643.4545@cbfsb.cb.att.com>,
  eajjs@cbnewsf.cb.att.com (john.sottile) writes:
< 
< I am not that familiar with STREAMS, but both the SLIP driver and the
< call setup are streams based.  I know that I can do (in AT&T's 
< UNIX V.4) ifconfig sl0 192.1.1.20 192.1.1.100 to let the tcp/ip
< driver know about the new slip interface, what I can't seem
< to figure out is how to get the device (async streams device) to
< "attach" to the sl0 slip streams device.
< 
On the Streams side, the "device" is probably a Streams module. See "man
streams" on how to push a module onto your stream.

< Has anyone tried this or have any ideas on how to proceed?
< 
The next step would be to find out how to get the unit number of the 
streams module you just pushed so that you can either open a socket and
set up the link, or fork off ifconfig to do the dirty work for you.

If you can't find your way by grepping include files and sample code (the PPP
stuff that's out there does something related to what you're trying to do),
I'd suggest something like comp.unix.programmer/sysv/whatever for enquiries.
-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29 Mar 1992 03:23:55 GMT
From:      karn@chicago.qualcomm.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Use of IP Precedence


Does anyone know of any reason that I should not experiment with
non-zero values in the precedence portion of the IP TOS (Type of
Service) field?

I have researched the relevant RFCs and the only recent mention is in
RFC-1122, Requirements for Internet Hosts. It says that the precedence
portion of the TOS field is for use on DoD networks, and that use of
the field is not (formally) specified by the IP protocol documents.

I am playing with priority queueing in my TCP/IP code for the PC, and
I want my routing code to give interactive packets (Telnet, rlogin,
etc) priority over bulk data (e.g., FTP data) on slow paths (like
my SLIP link to home).

I'm already doing it by peeking into the TCP header and examining the
port numbers, but I'd much prefer to do it in a way that does less
violence to the layering.  (It's not just an ideological issue -- it's
hard to handle IP fragments in this fashion). One way to do it is to
give a TOS precedence of 1 to interactive traffic like telnet
sessions, and allow the priority queuing mechanisms to place it ahead
of default (0) precedence traffic, e.g., a FTP data connection. Is
there any reason I shouldn't do this on the real network, like it
might crash certain common router or host implementations?

I have already found one bug in the SunOS TCP handling of precedence.
RFC-793 says that a TCP should raise the precedence on a new
connection to that contained in the SYN packet received from its peer,
but the BSD TCP doesn't do this. So when my TCP gets subsequent
segments from the other end that don't reflect the correct (higher)
precedence, my TCP resets the connection (as required on page 71 of
RFC-793).  I've had to #ifdef out these tests to be compatible with
Sun's TCP.

Phil

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 92 05:40:26 GMT
From:      thad@public.BTR.COM (Thaddeus P. Floryan)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.dcom.lans.ethernet,alt.sources.d
Subject:   Re: etheraddr.c -- get host's phys. ether address (SunOS and SVR4)

In article <22343@dog.ee.lbl.gov> mccanne@ee.lbl.gov (Steven McCanne) writes:
>Under SunOS, a SIOCGIFADDR on a streams nit descriptor will give the
>underlying ethernet address.

Or, for SunOS only, the following few lines will suffice (and, yes, the list
of #include is longer than the program! :-)

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <net/if.h>
#include <netinet/in.h>
#include <netinet/if_ether.h>
main()
{	char hname[65];
	struct ether_addr ea;
	gethostname(hname, sizeof(hname));
	ether_hostton(hname, &ea);
	printf("%s\n", ether_ntoa(&ea):
}

Yep, that's it.  :-)

Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29 Mar 1992 15:07:01 GMT
From:      mills@ccu.umanitoba.ca (Gary Mills)
To:        comp.protocols.tcp-ip
Subject:   Packet from broadcast poisons bridge

We have been experiencing a problem recently where our bridge suddenly
stops forwarding broadcast packets.  This is caused by a packet that
originates from the ethernet broadcast address, which poisons the forwarding
table in the bridge.  I suspect that most bridges are immune to this
problem.  We captured one of the packets, and it was 60 bytes of all ones.
Does anyone know what machine would emit such a packet?  We have Suns,
PCs, Macs, cisco routers, and assorted other machines on this subnet.

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

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 92 19:33:32 GMT
From:      mccoy@cbnewse.cb.att.com (earl.mccoy)
To:        comp.protocols.tcp-ip
Subject:   SMDS max SDU size of 9188 octets

The maximum Service Data Unit for SMDS is 9188 octets. Does anyone
know a rationale for this figure? BTW, is there a SMDS news group
on the net? Thanks in advance. Earl E. McCoy 312-230-4236

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 92 19:55:04 GMT
From:      pbh@athena.mit.edu (Paul B Hill)
To:        comp.protocols.tcp-ip
Subject:   Re: Need POP3 deamon, help !!

look at --

net-dist.mit.edu:/pub/Berkely-Popper

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 92 20:01:14 GMT
From:      christos@dworkin.wustl.edu (Chris Papadopoulos)
To:        comp.protocols.tcp-ip,comp.unix.internals
Subject:   When  does TCP ack packets?


	I am trying to determine exactly when TCP will send back acks
during a unidirectional data transfer. The data is large, ranging from
256K to a few Mbytes. I am using SunOS 4.0.3.
I am interested on acks generated during normal data transfer on a local
Ethernet between Sparcstation1 and Sparcstation2's.

	I have inserted probes in the kernel that tell me when packets
arrive at the protocol queue, when the protocol picks them up (i.e. when
ipintr() is called), when they get appended to the receive socket buffer,
and when they get copied to user space. Also I can monitor the ack generation
using probes at the sending side.

I know that TCP will generate acks in the following two cases:

	(1) When data is removed from the socket buffer. In this case
	tcp_output() is called, and if the data removed is large enough
	(>= 35% of the window known to peer, or >= 2*MSS and data remaining
	in bufer = 0) an ack will be generated.

	(2) when tcp_fasttimo() runs. Again, tcp_output() is called
	and an ack is generated since the flag TF_ACKNOW is set.

What are the other cases that an ack will be generated?
Given the information from the
probes, can I predict exactly when an ack will be generated? In other
words given the protocol state as given by the probes, can I determine why
an ack was generated when the probes show that there was one?

	Thanks in advance for any information.

Christos.

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 92 20:07:59 GMT
From:      christos@dworkin.wustl.edu (Chris Papadopoulos)
To:        comp.protocols.tcp-ip,comp.unix.internals
Subject:   Question on tcpdump


	I have a problem when trying to use tcpdump with the -w option.
The problem arises when I use tcpdump -r to read the file generated with
the -w option. Here is what I get:

root_flora[56]# tcpdump -w dump
^C
312 packets received by filter
0 packets dropped by kernel
root_flora[57]# tcpdump -r dump
tcpdump: warning: old style file format
tcpdump: truncated dump file

	Anybody can tell me what is wrong? I am using version 2.0.

Christos.

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 92 21:47:27 GMT
From:      demon@sequent.com (Dave Richards)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over IEEE 802.5 (Token Ring)


It's starting to make sense, now.  The following paragraph sort of made it
all click:

>However, the LF value can't guarantee the converse situation.  That is,
>if LF >= MTU you're guaranteed that a full-length IP packet can make it
>to the destination ring, but you still don't know whether the
>destination station can accept it.  That's pretty much the situation
>you're in on any other network.

Sequent's implementation falls into the class that cannot send or receive
full ring MTU sized packets.  I thought prior to the above that I needed to
protect against this situation by dropping my LF such that it was <= to the
size we did support.  However, you indicate that LF wasn't designed to
solve this, and your argument seems plausible.  Thanks.

	Dave Richards

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29 Mar 1992 21:48:34 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: etheraddr.c -- get host's phys. ether address (SunOS and SVR4)

In article <6102@public.BTR.COM>, thad@public.BTR.COM (Thaddeus P. Floryan) writes:
> In article <22343@dog.ee.lbl.gov> mccanne@ee.lbl.gov (Steven McCanne) writes:
> >Under SunOS, a SIOCGIFADDR on a streams nit descriptor will give the
> >underlying ethernet address.
> 
> Or, for SunOS only, the following few lines will suffice (and, yes, the list
> of #include is longer than the program! :-)
> ...
> main()
> ...
> 	gethostname(hname, sizeof(hname));
> 	ether_hostton(hname, &ea);
> 	printf("%s\n", ether_ntoa(&ea):
> ...
> }


Someone has pointed out to me that I should have recognized
ether_hostton().  It is simply Sun's /etc/ethers & NIS scanner.  As he said,
this function relies on the "/etc/ethers fairy" to use ping, arp, and so on
to maintain the (etheraddr,hostname) map.

ether_hostton() is useful for network traffic analyzers.  It's use for
"software node locking" is not likely to be satisfying, at least for
software vendors.


SIOGIFADDR is the elegant way to implement the facility in the kernel,
since SIO[GS]IFADDR is also used to get or set the IP address assoicated
with an interface.  Rumors that 4.4BSD instead has a brand new IOCTL are
disapointing.


Vernon Schryver,  vjs@sgi.com


-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Mar 1992 11:43:08 -0500
From:      Tom Holodnik <tjh+@andrew.cmu.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: "Future" TCP/IP and Security?

Andy,

Excerpts from netnews.comp.protocols.tcp-ip: 28-Mar-92 "Future" TCP/IP
and Security? greenie@drycas.club.cc.c (609)

> Does anyone know of any future implementations of TCP/IP or modifications
> to the current processes which would improve security?  IE, preventing
> "anybody" from TELNETting to the SMTP port and sending anonymous hate
mail and other such things like that?

	This particular case is a matter for the people who maintain the local
facilities to govern, in my opinion. 
	The approach I'd take is to restrict access according to TCP port
number from terminal servers, and in inernet routers, where appropriate.
 There are facilities to do  this in most major router and terminal
server vendors.  


-tom



-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Mar 1992 04:13:10 GMT
From:      eengelke@sail.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: LPD

 sukonnik@decvax.dec.com writes:
>I have the BSD sources and I do not see it to be very different from the
>protocol (if you dare to call it that) descirbed in RFC 1179. I am curious
>what exactly you had in mind when you said that the RFC is tuned to help
>PCs. 

The suggestion that one may send 0 for the filesize if unknown was intended to
allow pcs to spool output as it is generated (in real time).  
BSD and most varients, however, sit in a loop waiting for N bytes to arrive, 
where N is the value given as the file length.  So the '0' option does
not work.

Since BSD versions require this value to be known before the data can be sent,
you must obviously send the control file first.  I believe the RFC suggests
the control and data file may be sent in any order.

There, I think I've given two examples where the RFC misses the mark.  


Erick

-- 
Erick Engelke					  Engineering Computing
Network Systems Manager				 University of Waterloo
erick@development.watstar.uwaterloo.ca		(519) 885-1211 Ext 2965

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 92 14:34:45 GMT
From:      sb7c+@andrew.cmu.edu (Shikhar Bajaj)
To:        comp.protocols.tcp-ip
Subject:   Where is tcpdump?

Does anyone know where and how I can get my hands on the TCPdumo utility?


Shikhar

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 92 14:41:04 GMT
From:      sb7c+@andrew.cmu.edu (Shikhar Bajaj)
To:        comp.protocols.tcp-ip
Subject:   status of 4.4 BSD

Can someone fill me in on the current status of 4.4 BSD?  What I am
particularly interested in is the availability of the code (binaries and
possibly source code) and the major changes between 4.4 and 4.3.  Pardon
me if this is a FAQ.


Shikhar

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 92 16:59:23 GMT
From:      bas@moria.Sp.Unisys.Com (Brian Strop)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   PPP for SunOS 4.1.1

I do not have direct Internet access and would like to get a copy
of Brad Clements' async PPP implementation for the SunOS.
Is there dial-up access to the host it resides on (omnigate.clarson.edu)?

Thanks in advance,

B. Strop
-- 
Brian A. Strop				(612) 687-2709
UNISYS					bas%moria.uucp@email.sp.unisys.com
Network Systems

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Mar 1992 17:45:37 GMT
From:      nether@wpi.WPI.EDU (Joel C Belog)
To:        comp.protocols.tcp-ip
Subject:   looking for FAQ

Hello,

	Subject says it all.  Could someone please e-mail me the FAQ and
	any archive names ...


	Thanks

	Joel Belog
	nether@wpi.wpi.edu
	NeXTmail O.K.

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 92 18:06:35 GMT
From:      ckd@eff.org (Christopher Davis)
To:        comp.protocols.tcp-ip
Subject:   Re: loopback address


 Thomas> == Thomas Heller <Thomas Heller <PPH93@DMSWWU1A.BITNET>> 

 Thomas> I was just wondering about the purpose of the loopback network
 Thomas> address, mostly something like 127.1.1.x.

 Thomas> Shouldn't the OWN ip address serve exactly the same purpose?

(1) '127.0.0.1' is always going to be your local host; this means that
    using it is portable, unlike using 'my.ip.ad.dr'.

(2) Certain implementations may implement packets routed for the
    loopback interface differently than packets routed for the local IP
    address.
--
Christopher Davis <ckd@eff.org> |    ECONOMIC OBSERVATIONS DEPARTMENT
System Manager & Postmaster     |  "There's always something going out of
Electronic Frontier Foundation  |      business in Central Square."
+1 617 864 0665  NIC: [CKD1]    |   -Rita Marie Rouvalis <rita@eff.org>

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Monday, 30 Mar 1992 16:25:36 MES
From:      Thomas Heller <PPH93@DMSWWU1A.BITNET>
To:        comp.protocols.tcp-ip
Subject:   loopback address

I was just wondering about the purpose of the loopback network address,
mostly something like 127.1.1.x.

Shouldn't the OWN ip address serve exactly the same purpose?

Thomas Heller, Univers. of Muenster, Germany

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 92 19:38:24 GMT
From:      dirk@incom.de (Dirk Koeppen)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   TCP/IP BOOT-PROM For Token-Ring Adapters

Hi there,

we want to extend our TCP/IP BOOT-PROM for diskless booting PCs to
support Token Ring networks.

Therefore I would like to know:

	- what kind of Token-Ring adapter is the most common one ...
	- what adapter would you like to see supported and why ...
	- do you see the need for a diskless environment in your
	  Token Ring network ...
	- what price do you expect for a Token Ring BOOT-PROM ?

If you are interested in the product or would like to be one of the
first beta-testers please reply to me via email.

Thanks for your efforts in advance,
dirk

--
  Dirk Koeppen  -  Holzwiesenweg 22  -  D-6050 Offenbach  -  Germany
  Phone: +49 69 89 3000 - FAX: +49 69 89 3004 - email: dirk@incom.de
  ---
  ** Phase 2 - Check Pathnames
  UNALLOCATED I=2 (NOT EMPTY) REMOVE?

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 92 19:48:30 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet mask brain-teaser!

In article <1992Mar27.021427.4401@cs.sfu.ca>, skl@cs.sfu.ca (Samuel Lam) writes:
|> In article <1992Mar25.095430.38805@kuhub.cc.ukans.edu>,
|>  paul@kuhub.cc.ukans.edu wrote:
|> >                                      129.237.80.8 (Ultrix)
|> >                                     /
|> >router ethernet port  X--------------
|> >                                     \129.237.129.1 (PC running Clarkson CUTCP)
|> >...
|> >When 129.1 tries to connect to the 80.8 the IP address will be outside
|> >the local subnet, so the default gateway will be tried. The router
|> >should take the request and issue an ICMP redirect to the initiating
|> >PC redirecting to a "direct" connection.
|> >
|> >What I don't know is whether the router will actually do that, ...
|> 
|> No, the router won't send the ICMP-redirect in this case, since
|> ICMP-redirect was designed for intra-subnet redirection only.
|> Since 129.237.129.1 and 129.237.80.8 are on different subnets
|> according to your 0xFFFFFC00 netmask, the router will quietly
|> forward the datagram back onto the same Ethernet it came in
|> on without generating an ICMP-redirect.  This behaviour is
|> specified in the relevent RFC's.

This should only occur if the router is configured to exist on both subnets on the one physical segment.

|> 
|> In your situation, you might want to consider leaving the hosts'
|> netmask at 0xFFFF0000 and enable proxy-ARP on your (subnet aware)
|> routers.  This way your whole class B network will look unsubnetted
|> to the hosts and the 129.237.129.1 and 129.237.80.8 above will
|> be able to communicate directly on their common Ethernet.
|> 

Of course the routers will also have to know which hosts are on which segment or the proxy arp response will be given from the router and the arp response will be given from the host.  This causes host implementation specific results.  The host may use the first to respond, the last, or flag it as a two hosts with the same address error and cease communications.  "True" proxy arp for subnet support only works if the host addresses conform to the subnet RFC but the hosts themselves don't support subnet mask





s.

|> ...Sam
|> -- 
|> Samuel Lam <skl@cs.sfu.ca>
|> Network Support Group, Centre for Systems Science
|> Simon Fraser University, Burnaby, B.C., Canada


My 2 cents.

Mark Reardon (mwr@eng.tridom.com)

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 92 20:08:39 GMT
From:      hgv@herring.network.com (Harry G. Varnis)
To:        comp.protocols.tcp-ip
Subject:   Reliability with UDP

Does anyone know of code which attempts (at the application level) to
lend reliability to the data exchanged between two UDP endpoints?

I know TCP is designed for this, but my data are naturally blocks
rather than streams and I'd like to avoid the blocking/deblocking
that is expensive in my environment.

On a related subject, are there implementations of the Reliable
Datagram Protocol out there?

Thanks muchly,
-- 
Harry Varnis         <hgv@anubis.network.com>          +1 612 493 1042

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 1992 21:13:44 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: loopback address

In article <92090.162536PPH93@DMSWWU1A.BITNET> Thomas Heller <PPH93@DMSWWU1A.BITNET> writes:
>I was just wondering about the purpose of the loopback network address,
>mostly something like 127.1.1.x.

127.0.0.1

>Shouldn't the OWN ip address serve exactly the same purpose?

If you know your own IP address.  The loopback address is intended to be
useful during bootstrapping, before the machine has learned its network
identity.

It's also a useful value to put in a "localhost" entry in a distributed
host table.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 92 22:40:56 GMT
From:      Kerry_Koppert@kcbbs.gen.nz (Kerry Koppert)
To:        comp.protocols.tcp-ip
Subject:   Problems with PCRoute brouter

I am trying to get the brouter version of PCRoute to work. I have set 
up a test network 223.1.1 with the router set to 223.1.1.2 on one interface 
and a legal class B address off our backbone. Using the standard router 
everything works as expected, using the brouter things sort of go umm 
weird. IPX works fine, I can login into Novell fileservers ok. Ncsa 
telnet works once if I ping the workstation from a unix host on the 
backbone side. i.e. if I reset the router, start Telnet (which doesn't 
find the host) then ping the workstation I can access the unix host. 
If I then exit from Telnet and try again it doesn't work. Pinging the 
workstation the traffic goes from the host to the workstation but is 
not echoed back. I seem to recall there was a bug in the brouter version 
of PCRoute. Could this explain my problem and is there a version around 
that fixes the problem?

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Mar 1992 04:23:19 GMT
From:      stevea@i88.isc.com (Steve Alexander)
To:        comp.os.os2.misc,sco.opendesktop,comp.protocols.tcp-ip
Subject:   Re: IBM TCP/IP problems (2)

In article <1992Mar20.025513.26230@bohra.cpg.oz.au> ejp@bohra.cpg.oz.au (Esmond Pitt) writes:
>This does not cure problem #2. The symptom is that (with or without Lan
>Manager) IBM TCP/IP causes the following to appear:
>
>	nb: dssvc: unexpected TPI primitive (18)
>	uderror 115, dest=00000000:00000000
>
>about every 10 seconds on all sessions of the console of an SCO ODT Unix
>box running TCP/IP and Lan Manager for Unix on the same network.

This is due to the SCO machine receiving ICMP port unreachables in response to
datagram or name service broadcasts.  The unreachable messages are coming from
another machine on the network that's not running NetBIOS over TCP/IP.  SCO 
has (or will have) an SLS to turn off the message, which is about all that 
can be done without fixing the systems that send the port unreachable messages.
It is a violation of RFC 1122 to send a port unreachable in response to a 
broadcast datagram.  Some systems do so anyway, either because they're confused
about the broadcast address, or because they're just confused.  You can use a 
network monitor to figure out which machines are sending the port unreachable 
messages.


-- 
Steve Alexander, Software Technologies Group    | stevea@i88.isc.com
INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Mar 1992 09:48:59 GMT
From:      root@itnsg1.cineca.it (Valter Cavecchia)
To:        comp.sys.sgi,comp.protocols.tcp-ip
Subject:   SLIP and routing

I have the following network configuration:

net A: which is a local network
net B: which is connected to the Internet through the gateway G

I installed a slip connection between one computer of network A (a NeXT)
and a computer of network B (a SGI 4D35), using a phone line.
When I telnet from the NeXT to the SGI everything works.
The problem is the routing.
I would like to telnet from the NeXT to the Internet, and would like the same
from every machine of network A.

I configured the SGI with static routes (without routed) simply adding:
	route add default mygateway 1

Any hints about this topic?
	Thanks a lot in advance,
	valter

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Mar 1992 14:24:12 GMT
From:      dcarr@hobbit.gandalf.ca (Dave Carr)
To:        comp.protocols.tcp-ip
Subject:   Re: Reliability with UDP

In <1992Mar30.200839.4350@ns.network.com> hgv@herring.network.com (Harry G. Varnis) writes:

>Does anyone know of code which attempts (at the application level) to
>lend reliability to the data exchanged between two UDP endpoints?
 
>I know TCP is designed for this, but my data are naturally blocks
>rather than streams and I'd like to avoid the blocking/deblocking
>that is expensive in my environment.
 
>On a related subject, are there implementations of the Reliable
>Datagram Protocol out there?


From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
Subject: Reliable UDP Info
To: vxworks_users@vxw.ee.lbl.gov
Message-ID: <9203181420.AA03426@vxw.ee.lbl.gov>
Sender: daemon@hobbit.gandalf.ca
Organization: Gandalf Data Ltd.
Errors-To: vxwexplo-errs@lbl.gov
Distribution: gandalf
Date: Wed, 18 Mar 1992 14:20:33 GMT
Return-Path: <root@vxw.ee.lbl.gov>
Approved: news@gandalf.ca

Submitted-by mea@sparta.com  Wed Mar 18 06:20:05 1992
Submitted-by: mea@sparta.com (Mike Anderson)
 
Greetings!

  Since I received quite a few questions regarding the reliability of
the ARTSE(TM) datagram facility, here is a copy of the response that
my lead protocol engineer previously sent out.  Also, I humbly
stand corrected.  We use raw sockets to access ICMP services only (we have
a "ping" implementation for VxWorks that uses ICMP echo requests to
determine routing availability and CPU health and status).  
This was the piece I worked on, so I mistakenly assumed that we
used raw sockets throughout.  The ARTSE(TM) RDP is, in fact, 
based on UDP sockets.  Happy Reading...


----- Begin Included Message -----

From csk Tue Mar 17 20:18:48 1992
To: hyeom@cs.tamu.edu
~Subject: Reliable UDP
Cc: csk, mea

hyeom@cs.tamu.edu,

Mike asked me to respond to your questions about how we do reliable UDP.
Our implementation is completely reliable.  The only time we have experienced
packet loss is when there is no physical way to get to the destination or the
the destination process is dead.  In these cases, the sender is notified 
of the failure after a set number of attempts to retransmit (e.g. 4).  It is 
conceivable that if the network were so overcrowded that all retransmissions
were damaged or lost then the message would not get through.  However, to 
reduce this probability we use a backoff scheme on the retransmissions and 
the number of retransmission attempts is parameterized so it may be changed 
to reflect system traffic.

It is possible to use our Reliable Datagram Protocol (RDP) to do broadcast 
on an Ethernet.  In fact, we have previously implemented a reliable 
group-oriented transport service simply by adding group concepts of 
reliability to the RDP.  Broadcast mechanisms could be implemented based 
on the group-oriented mechanisms.

I've included a portion of a paper that describes the RDP.  The publications
listed below describe the ARTSE(TM) Process Control Executive including the
RDP.  If you send a mailing address, I will be happy to send you copies
of these papers.

"The ARTSE(TM) Process Control Executive - A Development for Distributed 
Applications", Curt Kuhn and Craig Franklin, Proceedings of the Sun User 
Group Conference, December, 1991.

"Creating Software for Your Distributed VMEbus System", Craig Franklin and
Curt Kuhn, VMEbus Systems Magazine, October, 1991 and February, 1992 (2 parts).


                                         Curt Kuhn
                                         csk@sparta.com



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


     At the root of the ARTSETM Process Control Executive's
     interprocess communication services is the Reliable Datagram
     Protocol (RDP).  The Reliable Datagram Protocol provides
     guaranteed transfer of information between executives.

     The RDP is a connectionless protocol that allows any process
     to communicate with any other process using datagram
     messages.  Message acknowledgements, sequence numbers, and
     checksums guarantee reliability.

     The RDP uses the User Datagram Protocol (UDP) functions
     provided by the UnixTM operating system.  UDP provides
     connectionless, best-effort message delivery.  Each process
     that wishes to send or receive messages opens a datagram
     socket - a communication endpoint to which a name may be
     assigned.  To a source process that opens a socket, the
     source socket is treated as a file descriptor, allowing
     communication across the network to be handled similarly to
     reading and writing to a file.  Since UDP sockets are
     connectionless, a process may use one socket to communicate
     with any number of processes.

     UDP makes a "best-effort" to deliver a message.  If,
     however, a message is lost in transit, that message is never
     delivered.  If a message is damaged in transit, the message
     may be delivered in error.

     The RDP guarantees the in-order and error-free delivery of
     messages between processes by requiring that each message
     transmitted by a process be acknowledged by the receiving
     process.  A receiving process may not acknowledge a message
     because the message was lost or damaged during transmission,
     because the receiver's buffers were too full to accept the
     message, or because the message was received out of order.
     If the destination process does not acknowledge the message
     within a given period of time, the source process
     retransmits the message.

     Destination processes detect damaged messages by using a 16
     bit checksum.  The source process calculates a checksum
     value and inserts that value in the message header.  The
     destination process recalculates the checksum and compares
     the new value to the value contained in the message header.
     If the two values are not equal, the message is ignored and
     not acknowledged.  Many UDP implementations provide
     checksums.  The RDP provides an additional checksum so that
     correct delivery may be assured even in UDP implementations
     that do not provide checksums.

     A 32 bit sequence number assures ordered delivery of
     messages.   Each source process assigns an initial sequence
     number to the first message transmitted to a particular
     destination.  For each subsequent message transmitted from
     that source to that destination,  the source process
     increments the sequence number.  The destination process
     automatically keeps track of the sequence number of the last
     message received from a particular source.  The destination
     process will only accept a message if its sequence number is

     one larger than the sequence number of the last message
     accepted from that particular source.  However, the
     destination process acknowledges any message with a sequence
     number equal to or less than the expected sequence number.
     In this way, a destination process automatically retransmits
     a lost acknowledgement.

     Any process that sends messages keeps a list of messages
     sent but not yet acknowledged.  If the source process does
     not receive an acknowledgement within a given time-out
     period, the source process retransmits the message.  A
     source process has at most one message waiting for
     acknowledgement from each process with which it
     communicates.  If a process attempts to send additional
     messages to a destination that has not yet acknowledged a
     previous message, the additional messages are queued within
     the source process.  When it receives an acknowledgement for
     a message, the source process transmits the next message in
     the queue for that destination process.

     Acknowledgements also contain sequence numbers.  The
     sequence number of an acknowledgement is the same sequence
     number of the message being acknowledged.  Duplicate message
     acknowledgements are ignored.

     The acceptance of a message and the transmission of an
     acknowledgement does not mean that the destination
     application has read the message. When the RDP software
     accepts a message, the message has arrived without error and
     in order.  The message is queued until the Process Element
     executes a command to read the message from the queue.

     The time-out period used for determining when to retransmit
     a message is calculated for each source-destination pair and
     adapts to the current network loading and delay conditions.
     In this way, we optimize time-out periods for current
     network performance even when a source uses different
     networks to communicate with different destination
     processes.  The algorithm for calculating current time-out
     periods uses weighted averages to update previous time-out
     periods with current round-trip message transmission times.

     When a message is retransmitted, its time-out period is
     adjusted using the following backoff scheme.  The first
     retransmission of the message causes the time-out period to
     be doubled.  Each subsequent retransmission causes the time-
     out period to be redoubled.  For the first four
     retransmissions of a message, the original time-out period
     would be multiplied by 2, then 4, then 8 and finally by 16.
     If a message delays for more than 16 times the original
     time-out period, we assume that the receiving process is
     unreachable and stop attempting to send the message.  This
     backoff does not effect the original time-out period for the
     first transmission of the next message.


----- End Included Message -----


==============================================================================
    AAAA  D D    D D    EEEEE   M   M  TM  // AAAA RRRR  TTTTTT SSSSS EEEEE TM
   A   A  D   D  D   D  E      M M M M    // A   A R   R   TT   S     E
  AAAAAA  D   D  D   D  EEEEE  M  M  M   // AAAAAA RRRR    TT    SSS  EEEEE
 A     A  D   D  D   D  E      M     M  // A     A R  R    TT       S E
A      A  D D    D D    EEEEE  M     M // A      A R   R   TT   SSSSS EEEEE

Process Distribution/Control and Communications for Distributed Systems

Mike Anderson                       Voice: (703) 448-0210 ext. 235
Director, ADDEM(TM) Project Office  FAX:   (703) 734-3323
SPARTA, Inc.                        EMAIL: mea@sparta.com
Suite 900                     
7926 Jones Branch Drive        "The optimist proclaims that we live in the
McLean, VA  22102               best of all possible worlds, and the pessimist
                                fears that this is true."

                                    J.B. Cabell

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


**********

    This is a user group mailing list for vxWorks related topics
    Submit articles to vxwexplo@lbl.gov for 'explosion'
    Send subscription requests & comments to vxwexplo-request@lbl.gov

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

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 92 15:09:52 GMT
From:      smith@sctc.com (Rick Smith)
To:        comp.protocols.tcp-ip,comp.protocols.iso.dev-environ
Subject:   GOSIP meets TCP/IP ??


Several weeks back a vendor claimed that the next revision of
GOSIP (version 3?) is to include an agreement on the use of
TCP/IP for the lower layers.

Is this real, or is this fiction?

Rick.
smith@sctc.com        arden hills, minnesota

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 92 15:50:26 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: loopback address

In article <92090.162536PPH93@DMSWWU1A.BITNET>, PPH93@DMSWWU1A.BITNET (Thomas Heller) writes:
|> I was just wondering about the purpose of the loopback network address,
|> mostly something like 127.1.1.x.
|> 
|> Shouldn't the OWN ip address serve exactly the same purpose?
|> 
|> Thomas Heller, Univers. of Muenster, Germany

Usually does but sometimes when writing an application it's unknown and system dependent.  The the loopback address is nice and handy.

Mark (mwr@eng.tridom.com)

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 92 16:28:02 GMT
From:      slu@paul.rutgers.edu (shen lu)
To:        comp.sys.sgi,comp.protocols.tcp-ip
Subject:   help with my SGI SLIP


  I have the following net configuration and try to make slip
  work. 

  Local net: 3 SGI iris-4D25 (Irix 4.01) on ether net.
  Remote Dial-in Terminal server(SUN Sparc 4.01),supports slip
                      and linked to internet.

  On my local IRIS 4d 25, I starts slip:
  slip -ddd -u sun_server -r IP_ADDRESS_OF_DIALIN
  (sun_server is in my uucp Systems file looks like this:
   sun_server any phone login_passwd slip)

  Everthing goes fine, I do get logged in to the remote host.
  Then I get the slip starting message:
  "Slip starting from "my_local_IP_address" to "IP_address_of _SUN".

  After 4 to 5 seconds, A message appears on the console:
  "sl0: dropping bable".
  Question: is this "sl0: droping bable" a warning message  or
            a fatal error message?

  After the linkage, I do see modem RD and SD lights flushing
  periodically. (We are using hayes 9600 modem). And the netstat
  gives me the # of incoming packeks and outgoing packets on sl0.

  But, I can't ping or telnet to the remote sun_station. 

  I can't figure what's wrong. 

  On my 4D25, I have "routed" running, once slip starts, it
  refreshes teh routing table and puts sl0 in it:
  
  Destination    Gateway	Flags	MTU	RTT RTTvar Use Interface
       some local default routing for ether net

  sun_server    cinemax  	UH	0	0     0	   4300   sl0
  192.1.1	cinemax	        U       0       0     0   766667 ec0
 

  Any suggestion for helpping me outof this hole will be deeply appreciated.

  Reply to here or:

                       slu@paul.rutgers.edu

  Thanks alot.

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Mar 1992 17:39:38 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: status of 4.4 BSD

In article <gdpmW0a00WB5EIdWBS@andrew.cmu.edu> sb7c+@andrew.cmu.edu (Shikhar Bajaj) writes:
>Can someone fill me in on the current status of 4.4 BSD?  What I am
>particularly interested in is the availability of the code (binaries and
>possibly source code) and the major changes between 4.4 and 4.3...

Incomplete, unreleased, and still vaguely defined in spots.  Full release
was, last I heard, set for about a year from now.
-- 
GCC 2.0 is to C as SVR4 is to Unix.     | Henry Spencer @ U of Toronto Zoology
                             -Dick Dunn |  henry@zoo.toronto.edu  utzoo!henry

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Mar 1992 21:15:11 GMT
From:      peter@ferranti.com (peter da silva)
To:        comp.protocols.tcp-ip
Subject:   Telnet RFC... which RFCs do I need?

Gaaah! Apart from the subliminal message option, I can't quite see what RFCs
I need to figure out Telnet. Is there an all-singing all-dancing RFC that
ties together everything up to (say) a year ago or less, or do I need to get
all 69 RFCs that mention the protocol?
-- 
-- Peter da Silva,  Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  +1 713 274 5180
-- "Have you hugged your wolf today?"

END OF DOCUMENT