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 August 1992 (281 messages, 142545 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1992/08.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 Aug 1992 06:44:30 -0400
From:      revell@ghidra.UU.NET (James R Revell Jr)
To:        comp.protocols.tcp-ip
Subject:   Re: How to control permissions on incoming FTP?

In article <1582elINN9mf@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
} In article <51690@drilex.dri.mgh.com> dricejb@drilex.dri.mgh.com (Craig Jackson drilex1) writes:
} >Is there any way, using the standard ftpd which one might receive with
} >Ultrix or SunOS, for example, to control the permissions on incoming files?
} >I just did a sample put (from a PC), and the file was stored with
} >permisions of rw-rw-rw- (wide open).
} 
} Others have already suggested getting public ftpd source and adding a
} umask() call.

Chris Myers' enhanced BSD 4.3 ftpd sets the umask to a default and allows the
user to reset it via 'site umask'.  I believe these changes were in either
the 4.3 reno or tahoe ftpd.

It's a simple change to have the umask set differently for anonymous vs
real users.  You can work with the code in
   ftp.uu.net:/networking/ftp/ftpd.wuarchive.shar.Z
or wuarchive.wustl.edu:/packages/ftpd.wuarchive.shar

That directory on ftp.uu.net contains a couple fixes and enhancements
I've added as well.
-- 
James Revell	Network Services Mgr   <revell@uunet.uu.net>   /8^{~

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 92 07:14:13
From:      mrl@uai.com (Mark R. Ludwig)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

Okay, at the risk of a stuffed mailbox, I'll raise my hand and say I'm
in the process of designing and implementing a firewall.  Its purpose
is to allow our generally-soft-hearted internal network to remain so
without exposing our softness to the Internet at large.  In my
opinion, the Whole Issue is pragmatism: I don't want to fight with
each of the ten(!) Unix vendors represented over security of their
systems.  Furthermore, I don't have the time to replace the
fundamentally-insecure "protocols" which have made this heterogeneous
nightmare manageable (can you say Yellow P..., er, Network Information
Service?).

I do not want to install a firewall.  It's extra work I don't want.
However, as a professional who wants to continue in the networking
milieu (morass?), I am compelled.  Imagine what would happen if I
blithely connected us to the network and sometime later something bad
happens which is determined to be related to the network.  I could
find myself on the wrong end of a lot of things, from inquisitions
("Why didn't you protect us?") to police guns ("You were actually
aiding and abetting the bad guy, who's your friend, weren't you?") to
unemployment lines ("We're completely out of business because we've
lost too much to the competitor's industrial spy to survive in the
marketplace.").

I've read quite a bit about it, but this firewall discussion has
raised some questions in my mind.  The approach I'm taking is the (I
think) standard one which knows about specific well-known ports, and
imputes the direction of the connection from the port numbers.  What
is not clear is the basis for the assumption that an outgoing FTP or
TELNET connection uses a port greater than (or equal to?) 1024.  Is
this just a Unix convention?  I'd appreciate if someone could point me
to some additional information about non-Unix hosts.

In article <17011@ulysses.att.com> smb@ulysses.att.com (Steven
Bellovin) writes:

|> UDP applications are even more problematic.  We'd love to support
|> ``talk'', or have higher-level access to Archie.  

I assume this means non-TELNET access to Archie.

What are the problems with these two?  It appears from its protections
(lack of set-uid) that "talk" can't be allocating a port under 1024
for its outgoing connection, so I don't understand the problem.  I
probably could answer my own question if I had the source (which I
can't get until we get the firewall installed...).$$
-- 
INET: mrl@uai.com      BANG: uunet!uaisun4!mrl      ICBM: USA; Lower Left Coast
  "You can get a crowd to clap at a phone number, if the inflection is right."
   -- Dave Ross

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 92 03:31:50 GMT
From:      bytor@milton.u.washington.edu (Jill Patterson)
To:        comp.protocols.tcp-ip
Subject:   Re: books on TCP/IP

t9014149@phillip.edu.au writes:

>I am looking for introductory book on TCP/IP
>that covers theory and practical programming
>	thanks

  Take a look at Douglas Comer's two volumes, 
     Internetworking With TCP/IP Vol 1.
          General Overview

     Internetworking With TCP/IP Vol 2.
          More Technical
          Heavily Laden With C-Code

bytor@milton.u.washington.edu


>		joseph.

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 92 04:55:48 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Re: Wang/SCO communications.

ebc@uis.co.za (Errol Back-Cunningham) writes:

> Does anyone have experience of connecting a Wang VS100 running
> VS 7.21.03 to a SCO UNIX 486 for a remote login session? 
> 
> We're using TCP/IP and the SCO login screen keeps scrolling,
> making login inpossible.  Are there any other connectivity
> products available, or, does anyone know what problem we might
> be encountering?

[ Sorry for posting, Errol's address is invalid ]

It's a known problem with that version of VS TCP/IP, and there's a fix
available.  A tech support person should recognize the problem if it's
described exactly like that - or send me a usable mail address and I'll
send you more information.

-- 
Tom Fitzgerald   Wang Labs       fitz@wang.com   "I went to the universe today;
1-508-967-5278   Lowell MA, USA                   It was closed...."

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 92 05:26:29 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

drw@euclid.mit.edu (Dale R. Worley) writes:

> I haven't studied the matter, but I believe that the more
> sophisticated firewalling routers actually *do* track connections.  At
> least, I've heard claims about what some routers could do that I
> couldn't figure out how to do without tracking connections.

This sounds strange to me - and doesn't sound like a good idea.  If a
router has to take over a traffic path because of congestion or a dead
link, or if it's rebooted, it's going to find itself in the middle of a
bunch of connections with no idea of their history.  Should it block all
traffic that it didn't see a SYN for?

Are we going to return to the Good Old Days of stateful IMPs that blow away
all the connections through them when they're rebooted?

I suspect the router claims are based on the fact that you can tell a LOT
about a packet from the port numbers, protocol and flags.

-- 
Tom Fitzgerald   Wang Labs       fitz@wang.com   "I went to the universe today;
1-508-967-5278   Lowell MA, USA                   It was closed...."

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 92 15:12:58 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.dcom.modems,comp.protocols.tcp-ip
Subject:   Bidirectional Modem Pools (especially Telebit/Annex)

Is there really a "foolproof" way to setup a bidirectional modem pool
on a terminal server? 

We have done this ourselves for some time using Annex terminal servers and
various Telebit modems (Worldblazers lately), but it isn't foolproof.
The problem is that that are small timing windows when an outgoing and
incoming calls can get connected to each other.

For example:

1) An outgoing call starts first, it connects to an idle terminal
server port (one with no DCD from the modem). The outgoing caller gets
set to issue his dialing command, but before it does the modem answers
an incoming call. The incoming call now is talking to an outcoming call
(it probably hears the attempt to outdial).

Basically, whats wrong here is that the bidirectional modem doesn't
know that the terminal server has committed it to an outgoing call
before the dialing starts. It can't tell from DTR since it always gets
DTR from the terminal server (so that it will answer incoming calls).


2) An incoming call arrives first. The modems start negotiating
protocol (this can be quite long especially on a modem that needs to
select amoung V32/V32BIS/V42/V42BIS/MNP/PEP/TurboPEP). DCD does not get
asserted until the negotiation is done, and mean time a outgoing call
gets connected to it.


---
Ken Mandelberg      | km@mathcs.emory.edu          PREFERRED
Emory University    | {rutgers,gatech}!emory!km    UUCP 
Dept of Math and CS | km@emory.bitnet              NON-DOMAIN BITNET  
Atlanta, GA 30322   | Phone: Voice (404) 727-7963, FAX 727-5611


-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 92 15:43:09 GMT
From:      sjl@doc.ic.ac.uk (Steve J Lacey)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: rlogin complains "rcmd: socket: Permission denied"

>>>>> On Fri, 31 Jul 92 21:42:17 GMT, shm@syl.syl.nj.nec.com (Shailendra Majmundar) said:

Shailendra> Excuse me if this is a FAQ. rlogin works fine as root, but as any other
Shailendra> user, it gives this error msg. I had similar problem for rsh, which 
Shailendra> turned out to be setting of su bit on rsh. I checked it for rlogin,
Shailendra> things look normal. Any suggestion??
Shailendra> TIA,
Shailendra> Sam (shm@syl.nj.nec.com)

rlogin and friends (rsh, rcp) need to be setuid root in order for the to
access ports below 1024.

There you go. Short and sweet :)

Steve.
--
-----
Steve J Lacey, Systems Group.      (In my opinion, my opinions are just that.)
Department of Computing, Imperial College of Science, Technology and Medicine,
180 Queen's Gate, London SW7. Phone : 071 589 5111 x5085, Fax : 071 581 8024 
Email: sjl@doc.ic.ac.uk            `Quis custodiet ipsos custodes?'

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 92 15:55:14 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.protocols.tcp-ip
Subject:   Annex SLIP with 256 mtu?

Is anyone sucessfully running an Annex terminal server with release 6.2
using the Annex slip set with a 256 byte mtu? In this release you only
get two choices of mtu, 1006 or 256.

What I see with the 256 byte mtu, is a great deal of fragment drops.
Almost all the packets it sees from the ethernet side are 512 byte tcp
packets (the Sun default mtu for a routed packet). With a 256 byte mtu,
the Annex fragments these into 3 packets (the third because of the
extra header overhead). What I see by carefully monitoring the serial
side is that every few seconds of traffic it drops frag 3 or both frag
2 and 3 of an incoming packet.

The evidence is that its the annex dropping the fragments, since it
coincides with an increase in the collision count on its slip
interface.  While there can be no real collisions on a full duplex
serial link, apparently the Annex uses the collision count as an
indication of a queue overflow.

This is not a hardware or noise problem. If I run the same equipment
with the Annex mtu set to 1006, which will never fragment a 512 byte
packet there is no packet loss with the identical test data stream.

I don't really know whats going on here except to guess that maybe the
fragmentation slows down the serial side just enough to cause internal
overflows in the Annex which it reacts to by droping the fragments in
it queue.

You might ask why I just don't use the 1006 mtu and avoid the problem.
Well, as it happens the version of slip I want to use on my remote Sun
doesn't support an mtu bigger than about 850.

---
Ken Mandelberg      | km@mathcs.emory.edu          PREFERRED
Emory University    | {rutgers,gatech}!emory!km    UUCP 
Dept of Math and CS | km@emory.bitnet              NON-DOMAIN BITNET  
Atlanta, GA 30322   | Phone: Voice (404) 727-7963, FAX 727-5611


-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Sat, 1 Aug 1992 23:51:23 GMT
From:      baw@terminator.cc.umich.edu (Brian Wolfe)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Summary of Experiences with Commercial IP Providers



This is a summary of comments that I received for commercial ip providers.
The names and cities have been deleted at the request of the posters.


regards,

Brian


-----------------------------------------------------------------------------
One other to talk to is Alternet (UUNET).  They also offer 56Kb service.

In my dealings with both, trying to get information, etc..., I 
found UUNET to be much easier to deal with than PSI. (a fairly common 
impression among people I've talked to)

In terms of service they all have strong and weak regions.  PSI locates
all of their equipment in secure facilities, like the phone companies
switching offices.  I have heard of at least one case where they had
problems but couldn't get into their equipment.  Probably something
they have resolved.

In any case... I picked UUNET for our service.  

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

Our university has connected to the Internet via PSI for about three years
now via a dedicated connection.  PSI has been outstanding.

With their SNMP management, they typically respond to a line outage
within 5 - 10 minutes.  When a line failure required TELCO
intervention, they managed to get it serviced within 24 hours even
though our local Telephone company was on strike!

As a small college with limited technical staff, it has been very
efficient to let them do all the worrying about maintaining the
network connection.  We have been highly satisfied with their
performance.

Network throughput has been fine...  But then, our local interconnect
(19,200 baud) is clearly the slowest piece of the data path.  We will
soon upgrade to 56KB.

I've not had personal experience with the third item, but a few of our
faculty members have used it without any problems.

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

From: steve@uunet.uu.net (Steve D. Miller)
Subject: IP service providers
To: bwolfe@rad.rpslmc.edu
Date: Mon, 20 Jul 92 9:57:46 EDT
Cc: alternet-info@uunet.UU.NET

   Hi.  I'm Steve Miller, one of the engineers for AlterNet, UUNET's commercial
IP service offering.  I was wondering whether there was any reason why you or
the people you've been working with haven't contacted us for information on
our services.  We offer connections at speeds between dialup SLIP and PPP
through 56K and T1.  Our commercial IP network has connections to a number
of midlevel networks (NEARNET, SURANET, BARRNET) and to a large number of
international networks (including networks in the UK, Canada, Sweden, Finland,
Europe in general, India, Thailand, and South Africa).  We are also a member
of the Commercial Internet Exchange, so we can exchange traffic with other
networks that are part of the CIX (PSI, CERFNET, EUNET, SprintLink, PIPEX,
TIPnet, and DataNet; note that we are the transit network connecting many of
these networks to the CIX).  Furthermore, we have two connections to the
NSFNET, so customers meeting the acceptable-use guidelines for the NSFNET
can talk to anyone on the Internet.

   To address (briefly) some of the points in your posting to 
comp.protocols.tcp-ip:

	- We feel that we offer excellent service at very competitive
	rates.  In terms of response, we do (of course) monitor our customer
	connections all the time.  We have 24x7 coverage, with engineers
	either on site (generally from 7 AM til 11 PM) or on call at all
	times.  We would be more than happy to give you references from our
	customer base.

	- Our backbone is exclusively composed of T1s or fractional T1s;
	we will upgrade our backbone as our links become saturated.  Our
	connections to midlevels in the US are over T1 (or faster) links.

	- We have a TAC service option that can be used to provide telnet
	access for remote staff.  Users can dial our modems in our offices
	in Falls Church, VA, or can dial our 800 number, or can come in
	via modems in our remote points-of-presence, or can come in through
	any CompuServe access point.

   In any case, if you would like more information on our services, please
let us know.  We can be reached at 1-800-4UUNET3 (or 703-204-8000), or via
email as alternet-info@uunet.uu.net.

	-Steve

Spoken: Steve Miller    Domain: steve@uunet.uu.net    UUCP: uunet!steve
USPS: UUNET Technologies, 3110 Fairview Park Drive, Suite 570,
      Falls Church, VA 22042			      Phone: +1-703-204-8000

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

Some feedback that I've heard (second hand) has been that ANS was
much more friendly (and less arrogant) than PSI.   The people involved
felt that PSI although technically competent didn't seem as service
oriented as ANS.  From my standpoint ANS has a local rep (a very
nice and responsive person) while PSI's rep was based in another state.
I prefer having someone around the corner to talk to.

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

	A few coments. We went from PSI to ANS and telnet/ftp became
	alot 'snappier' (on a 56K link). My understanding is ANS uses
	a T3 for it's trunk and PSI uses a T1. Also ANS is directly
	on NFSnet where PSI is a dozen router hops away. This info
	is second hand so I suggest you verify for yourself but I can
	say there was an definite improvement in performance with ANS.

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

We have recently (within the last year) connected to PSI-Net, and have
been nothing but pleased.  In response to your individual points:

Quality of Support and timliness of repsonse

This has been good in the cases I have been involved with.  There
is one instance where PSI-Net contacted us before we realized we had
lost our link with them.  (The loss, by the way was the local phone
company's fault and not PSI-Net's).  Also, the few times I've spoken on
the phone with a technical support person, they were always patient and
well-informed.


Quality and accessibility of dialup service for remote staff.

PSI-Net has terminal servers in a number of cities that provide telnet
service directly to PSI-Net customers.  The speed of these connections is
quite fast and very reliable.   Also, I believe that PSI-Net has 
alternate methods of connection available, but don't remember any off 
the top of my head.

Overall, I've been very please with PSI-Net and wouldn't hesitate to
suggest it as a choice.
-----------------------------------------------------------------------------
-- 
Brian Wolfe                    
Associate Director             			Internet: bwolfe@rad.rpslmc.edu
Diagnostic Radiology and Nuclear Medicine	Voice:    (312)-942-5781 
Rush Medical Center, Chicago, IL USA		FAX:      (312)-942-2114  

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Sun, 2 Aug 1992 04:00:50 GMT
From:      karl@ddsw1.mcs.com (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   BIND - next version questions

Question for those who might know...... 

Does the next version of BIND provide for "non-dedicated" network support? 

I am primarily interested in the following behavior:

	If a query is made for a host, and the system is able to determine a
	host from which it intends to make the name request, yet the route
	to that host is unavailable, BIND would return a non-authoritative
	'no answer available' status.

This would do the following in the face of a disconnected link:

1)	Telnet, FTP, etc would fail with "unknown host" (which is true;
	BIND did not return a host IP address)

2)	SMTP services could "skip" this route decision, since no answer is
	available, and (for instance) batch the job for a relay site via
	UUCP.


This seems like it would be a significant improvement for sites which run
part-time SLIP or PPP links, want services available when the link is up,
but don't want to wait for timeouts when the link is down.

Ideas?

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Data Line: [+1 312 248-0900] Anon. arch. (nuucp) 00:00-06:00 C[SD]T
Request file: /u/public/sources/DIRECTORY/README for instructions

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 92 15:09:28 GMT
From:      dsc3jfs@nmrdc1.nmrdc.nnmc.navy.mil (Jim Small)
To:        comp.protocols.tcp-ip
Subject:   two things



first, can someone tell me the rfc(s) related to rlogin


and

we are debugging a printer package for use over our network, it's supposed
to be in binary mode, but it's not, I've done a packet trace and see what
appears to be a packet that sends 2 bytes but the representation of these
bytes confuses me,   type are shown as  /377/375

can someone explain what this means? (how to convert from this representation
to standard 8 bit)
-- 
I love the 3b2
The 3b2 is my friend.

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Sun, 2 Aug 1992 22:30:01 GMT
From:      jbryans@beach.csulb.edu (Jack Bryans)
To:        comp.protocols.tcp-ip
Subject:   resolv.conf

All the Field Manuals I've Referred to say you don't need a resolv.conf when
you're running a name server.  Some even say it's a waste to have one,
because it gets read on every query.  Yet, every 4.8.3 I've seen doesn't
work w/o at least a 0 byte /etc/resolv.conf.  What's the deal?

Is there any difference between an empty resolv.conf and one w/a
nameserver 127.0.0.1
line and possibly a domain line?

Should resolv.conf be any different for primary, secondary, caching-only,
and slave name servers?

Jack

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Aug 1992 00:30:08 GMT
From:      kre@cs.mu.oz.au (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: Terminology for firewalls (was Re: Firewall usage)

In <1992Jul26.211639.29453@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum) writes:

| Simple gateway - a node which is reachable on two networks, but has routing
| 	disabled, making it a termination point on both. This is typically
| 	a host with TCP/IP forwarding disabled.

That isn't a gateway at all, its a multi-homed host, which is a term
that's been around since about forever.

kre

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 92 08:57:23 MDT
From:      jrd@cc.usu.edu
To:        comp.protocols.tcp-ip,comp.protocols.pcnet
Subject:   Re: Clemson University Packet Driver: I have one problem B-(.

In article <1992Aug3.131945.3470@mtu.edu>, tomiii@mtu.edu (Thomas Dwyer III) writes:
> rh0083b@medtronic.COM (Roger-Hunen) writes:
>>I suppose that you try to send a packet while you are in the receiver
>>(called by the packet driver)? Well, I vaguely remember a statement from
>>Russ Nelson that this may not work with 1.09 compliant drivers. The spec
>>does not say anything about this, but the general consensus is that it is
>>bad practice.
>>
>>What you could do is to have the response packet sent at the next timer
>>interrupt.
>>
> 
> Does this mean that one should not send a packet during the upcall when
> AX=0, or when AX=1 (or both)?  I was under the assumption that you can
> call SEND_PKT during the upcall, but only when AX=1.  Am I mistaken?
> 
> 
> Thanks,
> Tom.III
> tomiii@mtu.edu
--------------------
	Yes, that's what it means. The Packet Driver has the board in an
intermediate state, not to mention the use of local storage for the pending
transfer. Thus one should not attempt transmitting while in the middle of
the receive sequence, at least not with the current generation of Packet
Drivers. There are other ways of scheduling transmission which do not
reenter the Packet Driver.
	Joe D.

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 92 11:49:05 CST
From:      a_millsbs@ccsvax.sfasu.edu
To:        comp.protocols.tcp-ip
Subject:   MS-KERMIT and PC/TCP???

I know that the current version of MS-KERMIT will work with LAT, and TCP using
Packet Drivers, and I beleive INT 14, Has anyone out there modified MS-Kermit
to work with FTP Softwares PC/TCP network Kernel?

We have a site license here for the PC/TCP kernel and I would REALLY like to be
able to use MS-Kermit with it.

Any help greatly appreciated.

------------------------------------------------------------------------------
B. Scott Mills                            (409) 568-1134
Computer Center -- Technical Support,     Stephen F. Austin State University
a_millsbs@ccsvax.sfasu.edu                P.O. Box 13012 SFA Station
root@calvin.sfasu.edu                     Nacogdoches, TX  75962
------------------------------------------------------------------------------


-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Aug 92 07:33:07 GMT
From:      shj@ultra.com (Steve Jay {Ultra Unix SW Mgr})
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Multiple Subnets and Non-byte boundary netmasks

In <1992Jul31.170907.23562@nstn.ns.ca> daniel@nstn.ns.ca (Daniel MacKay) writes:

>In <1992Jul24.160634.5645@acc.com> art@acc.com (Art Berggreen) writes:
>>The only problem I can think of right now with non octet aligned masks,
>>is that some older host TCP/IP implementations would only take octet
>>sized chuncks on netmasks.
 
>That's what everyone *says*.  Does anyone have a list of these noncompliant
>entities?  or is it just one of those net.legends that will be with us
>forever?  I have worked with my share of devices in the past couple of
>years, and a lot with 27 and 28 bit subnet masks, and haven't found
>anything out of sorts.

Well, how about this charming bit of code from the BSD "route" command:

                        /*
                         * If there are more bits than the standard mask
                         * would suggest, subnets must be in use.
                         * Guess at the subnet mask, assuming reasonable
                         * width subnet fields.
                         */
                        while (in.s_addr &~ mask)
                                mask = (long)mask >> subnetshift;
                        net = in.s_addr & mask;
                        while ((mask & 1) == 0)
                                mask >>= 1, net >>= 1;
                        np = getnetbyaddr(net, AF_INET);
                        if (np)
                                cp = np->n_name;

You'll find essentially the same code in the BSD Reno, Sun, and AT&T SysVr4
versions of the route command, and in the portion of the netstat command
that prints out routes.

We tried running with a 255.255.255.128 netmask here for a while, and
we ran into several things (it's been a while, so I don't remember details)
involving setting and displaying routes that didn't work very well.  Most
of the trouble seemed to stem from this bit of code.  I don't think we
found anything that actually broke so bad that we couldn't run with 
that netmask, but we found it a constant bother.

On the other hand, we are now running with a 255.255.254.0 netmask, and
that seems to be ok, although we still find a few programs on a few
systems that don't seem to display things quite right with this netmask.

So, there are definitely some things that don't display routes correctly
when you use a non-standard netmask, but this may not matter at your site.

Steve Jay
shj@ultra.com  ...ames!ultra!shj
Ultra Network Technologies / 101 Dagget Drive / San Jose, CA 95134 / USA
(408) 922-0100 x130	"Home of the 1 Gigabit/Second network"

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Mon, 03 Aug 1992 13:02:16
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip,comp.protocols.pcnet
Subject:   Re: Clemson University Packet Driver: I have one problem B-(.

In article <1992Aug3.131945.3470@mtu.edu> tomiii@mtu.edu (Thomas Dwyer III) writes:

    Does this mean that one should not send a packet during the upcall when
    AX=0, or when AX=1 (or both)?  I was under the assumption that you can
    call SEND_PKT during the upcall, but only when AX=1.  Am I mistaken?
    
It is legal to call send_pkt() at any time.  However, many drivers will
fail with CANT_SEND if their code is being re-entered, or the card is
in a state where they can't initiate a transmission.  It's always been
possible to wait till the next timer tick, which gives pretty good odds
that the driver won't be busy, but this reduces performance.  The 'int-num'
field returned by get_parameters() was intended to eliminate the problem,
by allowing the stack to wait until the EOI.  PC/TCP uses it if offered
by the driver, and our supported version of DIS_PKT offers it if the
'chain-vec' parameter is specified in PROTOCOL.INI.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901


-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Mon, 03 Aug 1992 08:18:22 GMT
From:      paul@atlas.abccomp.oz.au (Paul Brooks)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP: TCP/IP Software for an HP9000

In article <2148@h.cs.wvu.wvnet.edu> hontanon@a.cs.wvu.wvnet.edu (Ramon J. Hontanon) writes:
|Hello All!
|
|I am in charge of an ethernet LAN that includes an HP9000. When it came
|time to obtain TCP-IP software for the HP9000, all they could find was
|a package called FUSION, from Network Research Corp. It works OK, but
 [....]
|Does anybody know of any other TCP-IP package for the HP9000 that runs
|on the old PWS 3.1?

Have you asked Hewlett Packard?

-- 
Paul Brooks               |paul@atlas.abccomp.oz.au|LIFE is a bowl of cherries:
TurboSoft Pty Ltd         |pwb@newt.phys.unsw.oz.au|  sweet at first, until you
248 Johnston St. Annandale|                        |  reach the pits.
Sydney Australia 2038     |ph: +61 2 552 3088      |  

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Mon, 03 Aug 1992 08:31:21 GMT
From:      paul@atlas.abccomp.oz.au (Paul Brooks)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

In article <MRL.92Aug1071413@sun4.uai.com> mrl@uai.com (Mark R. Ludwig) writes:
|
|I've read quite a bit about it, but this firewall discussion has
|raised some questions in my mind.  The approach I'm taking is the (I
|think) standard one which knows about specific well-known ports, and
|imputes the direction of the connection from the port numbers.  What
|is not clear is the basis for the assumption that an outgoing FTP or
|TELNET connection uses a port greater than (or equal to?) 1024.  Is
|this just a Unix convention?  I'd appreciate if someone could point me
|to some additional information about non-Unix hosts.

Basically, the assumptions only apply to Unix systems that you trust the
sysadmin on! Any PC can be made to use any port number it feels like to
initiate connections, under 1024 and under 256. In fact, If someone is
sysadmin (or can get root access) to a unix machine there is no reason
they couldn't change the sources and re-compile to allow low port
numbers either. How will your firewall handle an incoming Telnet (on TCP)
connection using TCP port 23 as the source as well as the destination?

-- 
Paul Brooks               |paul@atlas.abccomp.oz.au|LIFE is a bowl of cherries:
TurboSoft Pty Ltd         |pwb@newt.phys.unsw.oz.au|  sweet at first, until you
248 Johnston St. Annandale|                        |  reach the pits.
Sydney Australia 2038     |ph: +61 2 552 3088      |  

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1992 23:01:19 -0700
From:      tli@skat.usc.edu (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple Subnets and Non-byte boundary netmasks

In article <1992Aug4.034743.895@ddsw1.mcs.com> karl@ddsw1.mcs.com (Karl Denninger) writes:
    
    CISCOs, on the other hand, strip the "1.100" from the route and believe that 
    the entire 150.2.x.x network is routed through the Netblazer!  If this route 
    happens to be a lower metric than the >real< 150.2.x.x route then you are 
    royally screwed; the routers will then ping-pong packets until the TTL 
    expires, saturating your network cable and generally making a mess, and 
    EVERY other subnet on the original router (which is now not getting any 
    packets) becomes orphaned!
    
    I have come to the conclusion that there is no way out of this problem for
    disjointed networks (where the CISCOs in question aren't on the network in
    question) if you have to run RIP.  This is a >serious< problem in some 
    situations.
    
This restriction is relaxed in version 9.1, currently in beta test.

    I would run IGRP but can't -- you see, CISCO plays this as proprietary, so
    none of my hosts understand it.  Running BGP or EGP doesn't help either; I 
    have Netblazers too, which only understand RIP, and the CISCO manuals say 
    you can't run more than one routing protocol on a major network number.
    
The manual is incorrect.  You just have to be careful.
    
-- 
Tony Li - Escapee from the USC Computer Science Department          tli@usc.edu
		       The net is not what it seems.

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 92 11:46:37 GMT
From:      sat@nut.tridom.com (Stephen Thomas)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple Subnets and Non-byte boundary netmasks

Unless it's been fixed in a later version, the KA9Q package's RIP implementation
can, in some situations, manifest this "bug." Since RIP (version 1) doesn't
support the transfer of subnet masks in routing updates, KA9Q tries to guess the
subnet mask for any route it hears about via RIP. If the network is not one the
system knows about, and if the local part is non-zero, KA9Q will assume a byte-
aligned subnet mask.

For example, if a network somewhere is defined as 148.62.2.0 with a mask of
0xFFFFFE00, and if KA9Q hears a RIP update advertising a route to 148.62.2.0,
and if has not been told about the correct mask through manual configuration,
then KA9Q will assume a route to 148.62.2.0 with a mask of 0xFFFFFF00.

Since I believe there are commercial products based on KA9Q (which, IMHO,
is an excellent TCP/IP implementation), I would expect this "bug" to appear
in commercial products.

---

Stephen Thomas (sat@tridom.com)
AT&T Tridom (404-426-4261)

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Aug 1992 13:19:45 GMT
From:      tomiii@mtu.edu (Thomas Dwyer III)
To:        comp.protocols.tcp-ip,comp.protocols.pcnet
Subject:   Re: Clemson University Packet Driver: I have one problem B-(.

rh0083b@medtronic.COM (Roger-Hunen) writes:
>I suppose that you try to send a packet while you are in the receiver
>(called by the packet driver)? Well, I vaguely remember a statement from
>Russ Nelson that this may not work with 1.09 compliant drivers. The spec
>does not say anything about this, but the general consensus is that it is
>bad practice.
>
>What you could do is to have the response packet sent at the next timer
>interrupt.
>

Does this mean that one should not send a packet during the upcall when
AX=0, or when AX=1 (or both)?  I was under the assumption that you can
call SEND_PKT during the upcall, but only when AX=1.  Am I mistaken?


Thanks,
Tom.III
tomiii@mtu.edu

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Aug 1992 15:11:38 GMT
From:      jnm@tdum.CTD.ORNL.GOV (Jamey Maze)
To:        comp.protocols.tcp-ip
Subject:   Need SLIP jump start, please...

Could someone point me to some documentation, books, vendors, etc. where
I could learn quickly about SLIP? My specific concern is security. The
computer security organization here requires that all dial-in access
have some sort of up-front authentication before access is granted. They
also want to have a log of who made connections and when they
disconnected. I need to find out if SLIP can be made to provide these
functions and what equipment is required.

Please reply by e-mail. 

Thanks,

--
Jamey Maze                 | Computing & Telecommunications Division
Oak Ridge National Lab     | Advanced Technology Group
P.O. Box 2008, MS-6238     | Internet: jnm@ornl.gov 
Oak Ridge, TN 37831-6238   | 615/574-6355, FAX 615/574-9646 

"The defense of individual rights has reached such extremes as to 
 make society as a whole defenseless against certain individuals.
 It is time, in the West, to defend not so much human rights as
 human obligations." - Aleksandr Solzhenitsyn

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 92 17:09:04 GMT
From:      henrich@crs.cl.msu.edu (Chuck Henrich)
To:        comp.protocols.tcp-ip
Subject:   Help: Moving a connected session to another host

Hello, I have a quick question here.  Is there any way that one
can take an incoming connection, and re-direct it to another host?

What im thinking of:

A person telnets to a central machine, which will then re-direct that
connection to another machine based on load.

Is there anyway to do this?  Please respond via email, as im not a regular 
reader of this newsgroup.

-Crh
--
                          
Charles Henrich      Michigan State University      henrich@crs.cl.msu.edu
     

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Aug 1992 17:09:26 GMT
From:      alberti@mudhoney.micro.umn.edu (Albatross)
To:        comp.protocols.tcp-ip
Subject:   Re: Need SLIP jump start, please...

In <1992Aug3.151138.21478@ornl.gov> jnm@tdum.CTD.ORNL.GOV (Jamey Maze) writes:

>Could someone point me to some documentation, books, vendors, etc. where
>I could learn quickly about SLIP? My specific concern is security. The
>computer security organization here requires that all dial-in access
>have some sort of up-front authentication before access is granted. They
>also want to have a log of who made connections and when they
>disconnected. I need to find out if SLIP can be made to provide these
>functions and what equipment is required.

What you want is TACACS, which is available for anonymous FTP from many sites,
including boombox.micro.umn.edu in the /pub/tacacs directory.  Otherwise look
it up with Gopher or Archie.
--
Bob Alberti: Computer & Information Services U of MN | aka: Albatross | Unitar-
E-mail     : alberti@boombox.micro.umn.edu           | Metropolis BBS | ian/
Disclaimer : My employer does not mean what I say.   | (612) 721-1870 | Univer-
Minnesota  : Where butter is a spice.                | BBSing as art. | salist!

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 92 17:50:23 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Terminology for firewalls (was Re: Firewall usage)

In article <9221610.4483@mulga.cs.mu.OZ.AU> kre@cs.mu.oz.au (Robert Elz) writes:
>In <1992Jul26.211639.29453@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum) writes:
>| Simple gateway - a node which is reachable on two networks, but has routing
>| 	disabled, making it a termination point on both. This is typically
>| 	a host with TCP/IP forwarding disabled.
>
>That isn't a gateway at all, its a multi-homed host, which is a term
>that's been around since about forever.

I think he really did mean "gateway" in the modern sense, not "router".
You telnet in from the outside world through one interface, authenticate
yourself via a login, and then telnet or whatever out of the other
interface to access machines within the sphere of protection.

So it is a multi-homed host, yes, being used as a simple, service level
gateway, as opposed to a multi-homed host that's just being used to
provide services to both interfaces.
						don provan
						donp@novell.com

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Aug 1992 19:47:59 GMT
From:      lenz@ssd.comm.mot.com (Doug Lenz)
To:        comp.protocols.tcp-ip
Subject:   X Interface to GDB

Can anyone point me to an X interface program for GDB?  I have
xxgdb and on the few systems I actually got it to compile on
(not many :), it would always die reading in source files. 
I never had the time / patience to hack on it but I'm starting
to get kinda desparate!  I'm specifically looking for a version
that will compile under Interactive SVR3.2 Version 3.0 with the
X386 server/libraries.

Any hints / ideas would be greatly appreciated.

Thanks...

	Doug

---
=============================================================
| Douglas Lenz   |   Friends don't let friends use MS-DOS   |
 -------------------------------------------------------------
|           internet :   lenz@ssd.comm.mot.com              |
=============================================================


-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 92 20:20:13 GMT
From:      eddjp@edi386.huber.com ( Dewey Paciaffi )
To:        comp.protocols.tcp-ip
Subject:   Multiple Routes Between Subnets


We have two subnets in our shop, a Token-Ring and an Ethernet. We've
had a machine with two interfaces, a Token-Ring and an Ethernet, which
has been routing between the two. The question came up recently, would it
necessarily be a Bad Thing if a second workstation were to aquire a second
interface and begin routing as pictured below:


		Network A   (Token-Ring)
       ------------------------------------------------------
             |                                      |
             |                                      |
           -----                                  -----
           |   |                                  |   |
           |   |                                  |   |
           -----                                  -----
             |                                      |
             |                                      |
       ------------------------------------------------------
		Network B   (Ethernet)

Are there problems in doing this? It just seems wrong to me, but I 
don't really know if it is.

-- 
Dewey Paciaffi      eddjp@huber.com

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1992 22:25:21 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple Subnets and Non-byte boundary netmasks

In article <1992Aug3.114637.29005@tridom.com> sat@nut.tridom.com writes:
>Unless it's been fixed in a later version, the KA9Q package's RIP implementation
>can, in some situations, manifest this "bug." Since RIP (version 1) doesn't
>support the transfer of subnet masks in routing updates, KA9Q tries to guess the
>subnet mask for any route it hears about via RIP. If the network is not one the
>system knows about, and if the local part is non-zero, KA9Q will assume a byte-
>aligned subnet mask.

Well, if the system has to guess a subnet mask, that's about the best you
can do.  This can only happen when the router is misconfigured (i.e. it
hasn't been told the subnet mask for one of its interfaces) or another
router is sending it invalid RIP packets (since RIP v1 doesn't include
subnet masks, the only routes you should send out are subnet routes within
the local subnetted net and routes to outside class A/B/C nets).  Either
way, I wouldn't consider KA9Q's assumption a "bug"; it's trying to deal
with some other problem as best it can (I hope it logs these occurrences,
since someone should fix whatever problem is causing it).
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 92 01:08:35 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

In article <bsahs5.2bk@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
>drw@euclid.mit.edu (Dale R. Worley) writes:
>> I haven't studied the matter, but I believe that the more
>> sophisticated firewalling routers actually *do* track connections.  At
>> least, I've heard claims about what some routers could do that I
>> couldn't figure out how to do without tracking connections.
>
>This sounds strange to me - and doesn't sound like a good idea.  If a
>router has to take over a traffic path because of congestion or a dead
>link, or if it's rebooted, it's going to find itself in the middle of a
>bunch of connections with no idea of their history.  Should it block all
>traffic that it didn't see a SYN for?
>
>Are we going to return to the Good Old Days of stateful IMPs that blow away
>all the connections through them when they're rebooted?

The screend program (described in "Simple and Flexible Datagram Access
Controls for Unix-based Gateways", in Proc. Summer 1989 USENIX Conference,
pp 203-221) keeps just enough state to match up IP datagram fragments.
Otherwise, there is no way to know the port numbers for a fragment.

This does make it impossible to run multiple screend instances in
parallel (i.e., to allow different fragments of one datagram to
follow different paths across the firewall router).  We believe
that this is not an actual problem, both because few people send
fragments across routers (that usually causes trouble in any case)
and because path-splitting is actually quite rare (especially at
the boundaries of organizations).  It does make it hard to exploit
a multiprocessor screening router, but why worry about it?

It also means that fragments received out of order will not always be
delivered.  We have not observed this to be a problem.

If screend (or the entire router) crashes, the only state that
is lost applies to particular datagrams in transit, not connections.

However, bear in mind that many people believe that there will have
to be some sort of "soft state" setup in future Internets, to handle
both security and performance policies.  The trick will be to avoid
losing a connection when a router crashes, but it's not impossible.

-Jeff

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Aug 92 02:14:17 GMT
From:      maf@falstaff.mae.cwru.edu (Mark Fullmer)
To:        comp.protocols.tcp-ip
Subject:   arp question


When adding an entry to a machines arp table, should the netmask be
consulted?  If the netmask is consulted, then shouldn't the routing
tables also be taken into account?

eg. SunOS 4.1.2.

netmask is 255.255.255.0

routing info: (netstat -r)
Destination          Gateway              Flags    Refcnt Use        Interface
localhost            localhost            UH       2      925        lo0
default              cob-gateway          UG       3      1320       le0
128.146.109.0        curiosity            U        16     29916      le0

-----

Subnet 81 is on the same physical ethernet.

Now I want to add an arp entry for host 128.146.81.100.

arp -s 128.146.81.100 02:60:8C:3E:EE:03 temp
returns Network unreachable.

ifconfig le0 netmask 255.255.0.0 
arp -s 128.146.81.100 02:60:8C:3E:EE:03 temp
This works...
arp -d 128.146.81.100 # delete the above

ifconfig le0 netmask 255.255.255.0
route add net 128.146.81.0 localhost 0
arp -s 128.146.81.100 02:60:8C:3E:EE:03 temp
returns Network unreachable.

ping 128.146.81.100 
The host really isn't connected right now, so no answer, but an 
unresolved arp entry for 128.146.81.100 is there.

now. 
arp -s 128.146.81.100 02:60:8C:3E:EE:03 temp

works.



In real life, this needs to work in a bootstrap protocol daemon.  It gets
a request for the 81 subnet, tries to add an arp entry which fails, then
sends a packet.  Since there's no entry, the kernel tries to resolve it
which ends up leaving an incomplete entry in the arp table (the client
still doesn't know its ip address at this point, so it can't answer).  The 
client broadcasts another request, this time when bootpd tries to update the
arp table it works (because the incomplete entry is present), the reply gets
sent.

Trying to add the entry directly to /dev/kmem seems too risky since
I can't grab a semaphore for the arp table.

Doing a sendto() before doing the ioctl(s, SIOCSARP, entry) if the arp
would fail (look at the netmask, ip, etc) seems dumb.

Not doing anything doesn't work since clients are timing out.

confused...
mark


-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Aug 1992 03:35:52 GMT
From:      mju@mudos.ann-arbor.mi.us (Marc Unangst)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Multiple Subnets and Non-byte boundary netmasks

In article <1992Jul31.201508.7128@acc.com> art@acc.com (Art Berggreen) writes:
>I'm willing to declare it a non issue unless someone can produce a system
>with the problem.

I just love a challenge...

Anyway, SCO TCP/IP v1.1.3 very definitely has problems with non-octet
aligned netmasks.  Specific problems include the inability of route(1)
to recognize an address as a network address if you're using non-octet
aligned netmasks, and problems with routed(8) correctly updating the
routing tables from RIP broadcasts.

The problems have been fixed in SCO TCP/IP 1.2.0.  However, a large
number of sites are still running TCP/IP 1.1.3, since 1.2.0 has not
yet been released as an unbundled product.  (TCP/IP 1.2.0 is, however,
included in copies of Open Desktop 2.0.  SCO is claiming a ship date
of "any day now" for unbundled TCP/IP.)

So I'd say we're not quite rid of the problem...

-- 
Marc Unangst                | Real men don't make backups.  Real men never
mju@mudos.ann-arbor.mi.us   | accidentally delete files that they're going
<backbone>!sharkey!mudos!mju| to need later.

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Aug 1992 03:47:43 GMT
From:      karl@ddsw1.mcs.com (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple Subnets and Non-byte boundary netmasks

In article <15kbohINNl5c@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <1992Aug3.114637.29005@tridom.com> sat@nut.tridom.com writes:
>>Unless it's been fixed in a later version, the KA9Q package's RIP implementation
>>can, in some situations, manifest this "bug." Since RIP (version 1) doesn't
>>support the transfer of subnet masks in routing updates, KA9Q tries to guess the
>>subnet mask for any route it hears about via RIP. If the network is not one the
>>system knows about, and if the local part is non-zero, KA9Q will assume a byte-
>>aligned subnet mask.
>
>Well, if the system has to guess a subnet mask, that's about the best you
>can do.  This can only happen when the router is misconfigured (i.e. it
>hasn't been told the subnet mask for one of its interfaces) or another
>router is sending it invalid RIP packets (since RIP v1 doesn't include
>subnet masks, the only routes you should send out are subnet routes within
>the local subnetted net and routes to outside class A/B/C nets).  Either
>way, I wouldn't consider KA9Q's assumption a "bug"; it's trying to deal
>with some other problem as best it can (I hope it logs these occurrences,
>since someone should fix whatever problem is causing it).

There's another item here though that causes problems..... host routes.

How do you handle these with RIP?  Or do you?  NOS and the Netblazer handle
this quite well, as do most Unix hosts.

The systems I deal with seem to understand them well enough.  As an example,
let's say I have a Netblazer (:-) and want to advertise a host route to a
single host when it fails over to dialup lines from leased circuits ('cause
I don't want to or can't feed an entire network in that condition).  So I
have it "auto-route" to 150.2.1.100 on the dial-backup line coming online.
This is then advertised as a host route when the interface activates.

Now, the hosts on the network are smart enough to get this route via RIP, 
see that they have a >different< route to the network 150.2.0.0 in their 
routing tables, deduce that this is a host route, and do the "right 
thing"(tm), marking this as a host route (flag "H") in their route tables.  
Wonderful, I think to myself -- and then the trouble begins.

CISCOs, on the other hand, strip the "1.100" from the route and believe that 
the entire 150.2.x.x network is routed through the Netblazer!  If this route 
happens to be a lower metric than the >real< 150.2.x.x route then you are 
royally screwed; the routers will then ping-pong packets until the TTL 
expires, saturating your network cable and generally making a mess, and 
EVERY other subnet on the original router (which is now not getting any 
packets) becomes orphaned!

I have come to the conclusion that there is no way out of this problem for
disjointed networks (where the CISCOs in question aren't on the network in
question) if you have to run RIP.  This is a >serious< problem in some 
situations.

I would run IGRP but can't -- you see, CISCO plays this as proprietary, so
none of my hosts understand it.  Running BGP or EGP doesn't help either; I 
have Netblazers too, which only understand RIP, and the CISCO manuals say 
you can't run more than one routing protocol on a major network number.

Blech!

Anyone got a solution to this one?  If CISCO would >ignore< routes with
clearly "inappropriate" network numbers (like the host routes) when they
have other, "politically correct" routes available, the problem would not
present itself.

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Data Line: [+1 312 248-0900] Anon. arch. (nuucp) 00:00-06:00 C[SD]T
Request file: /u/public/sources/DIRECTORY/README for instructions

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1992 04:09:34 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple Routes Between Subnets

In article <211@edi386.huber.com> eddjp@edi386.huber.com ( Dewey Paciaffi ) writes:
>Are there problems in doing this? It just seems wrong to me, but I 
>don't really know if it is.

It's called redundancy, and it's usually a Good Thing.  If one of the
routers goes down, the other one will be used.  When they're both up the
routing load will be split between them.  Note, however, that this requires
the hosts on the two subnets to know about both routers (e.g. run routed so
they hear the routing packets).

Most of our subnets are set up like this.  We have a cisco router connected
to each departmental subnet and a backbone, and the departmental file
servers are also connected to their subnet and the backbone.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1992 04:12:48 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

In article <1992Aug4.010835.11273@PA.dec.com> mogul@pa.dec.com (Jeffrey Mogul) writes:
>The screend program (described in "Simple and Flexible Datagram Access
>Controls for Unix-based Gateways", in Proc. Summer 1989 USENIX Conference,
>pp 203-221) keeps just enough state to match up IP datagram fragments.
>Otherwise, there is no way to know the port numbers for a fragment.

Non-initial fragments can simply be forwarded, and filtering should be
applied to the initial fragment when it shows up.  If the initial fragment
is rejected then the datagram will never be fully assembled and will be
discarded by the destination host.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Aug 1992 07:16:18 GMT
From:      rh0083b@medtronic.COM (Roger-Hunen)
To:        comp.protocols.tcp-ip,comp.protocols.pcnet
Subject:   Re: Clemson University Packet Driver: I have one problem B-(.

In article <1992Aug3.131945.3470@mtu.edu> tomiii@mtu.edu (Thomas Dwyer III) writes:
>>I suppose that you try to send a packet while you are in the receiver
>>(called by the packet driver)? Well, I vaguely remember a statement from
>>Russ Nelson that this may not work with 1.09 compliant drivers. The spec
>>does not say anything about this, but the general consensus is that it is
>>bad practice.

[deleted]

>Does this mean that one should not send a packet during the upcall when
>AX=0, or when AX=1 (or both)?  I was under the assumption that you can
>call SEND_PKT during the upcall, but only when AX=1.  Am I mistaken?

I guess it depends on the specific packet driver whether things break or
not. But as the packet driver interface is meant to be generic, you must
not do this if you want your application to work with all packet drivers.
As far as I know you must not call SEND_PKT during any upcall.

I waded through the WATTCP source code, and all SEND_PKT calls are kept
outside the upcalls. I did not check the details very carefully, but almost
any send actions seem to be done on timer interrrupts. Isn't it possible
then that you get a timer interrupt during the upcall which could cause
things to break? Russel, Eric??

Regards,
-Roger
(I speak for myself)


BTW

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Aug 1992 07:32:05 GMT
From:      eitan@wiscon.weizmann.ac.il (Shternbaum Eitan)
To:        comp.protocols.tcp-ip
Subject:   remote query on services


I posted a question regarding how to gain information about services on site
which i'm not bounded to, i got no answer till now,

so i'm posting again ...

if you have any knowledge  on how to do it please e-mail me
Thanks in advance

Eitan Shterenbaum

eitan@wisdom.weizmann.ac.il

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Aug 1992 10:11:11 GMT
From:      fabien@sun2.cern.ch (Fabien Collin)
To:        comp.protocols.tcp-ip
Subject:   TCP and mbuf (Bug ?)

  We have a problem with TCP/IP on IBM RS/6000 and HP 9000/7X0 :

  We have two programs communicating using internet domain sockets and TCP.
  Program "gen" sends one message to program "sink" -
    sink then "acknowledges" by sending to gen a 1 byte message.
					       ----------------
  NOTE: if you remove the 1 byte ack, it works like a charm on all machines.
  --------------------------------------------------------------------------

Programs :

  Program name : gen
        ...
        for( ; ; ){

          /* loop forever writing blocks */
          if( (bytes_written = write(s,record_buffer,rec_len)) < 0 )
                oops("write");
          if ((bytes_read = read(s,&byte,1)) < 0)
                oops("read");

          if ( (bytes= bytes+bytes_written) >= REPORT_FREQ ) {
                report(1, "source", bytes);
                bytes = 0;
          }


  Program name : sink
        ...
        for (;;) {
            if( (bytes_read = read(sfd, record_buffer, rec_len)) == 0 )
                break;
            if ((bytes_written = write(sfd,&byte,1)) < 0)
                oops("write");

            if ( (bytes = bytes+bytes_read) >= REPORT_FREQ ) {
                report(1, "sink", bytes);
                bytes = 0;
            }
          }

Symptoms :

  1) RS/6000 and SLA/SOCC (Serial Optical Link)
     We ran this test between RS/6000s under AIX 3.2 using the SLA/SOCC, and
     the "gen" machine seizes up. According to a trace, the gen process is
     waiting in kernel mode for mbufs. IP is dead, the network is totally
     unusable (You can log in only though the serial console).
     Gen cannot be killed.

  2) RS/6000 and Ethernet
     Using Ethernet, the machine survives but gen & sink hang.
     (They can be killed).

  3) HP 9000/7X0 and Ethernet
     We ran the same test on HP 9000/7X0 with HP-UX 8.07 on Ethernet.
     Same symptoms as (2).

Question :

   My question is the following :
   I *guess* that both HP-UX and AIX are based on a BSD TCP implementation...

   Is this a well-known problem in this particular implementation ?

        Thanks,

		 Fabien


-- 
-------------------------------------------------------------------------
 COLLIN Fabien				| Computing & Networking Division	
 Email: fabien@sun2.cern.ch		| Building 31, 3-013		
 Voice: + 41-22-767-2487		| CERN 1211 Geneva 23		
 Fax :	+ 41-22-767-7155		| Switzerland			
-------------------------------------------------------------------------

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 92 11:34:14 GMT
From:      rob@icarus.inmos.co.uk (Robin Pickering)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

In article <15l040INN2iv@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <1992Aug4.010835.11273@PA.dec.com> mogul@pa.dec.com (Jeffrey Mogul) writes:
>>The screend program (described in "Simple and Flexible Datagram Access
>>Controls for Unix-based Gateways", in Proc. Summer 1989 USENIX Conference,
>>pp 203-221) keeps just enough state to match up IP datagram fragments.
>>Otherwise, there is no way to know the port numbers for a fragment.
>
>Non-initial fragments can simply be forwarded, and filtering should be
>applied to the initial fragment when it shows up.  If the initial fragment
>is rejected then the datagram will never be fully assembled and will be
>discarded by the destination host.

This is the approach which I took for the IP packet filtering code which
we introduced to our gateway UNIX box kernel.

I have some nagging doubts about this causing problems by filling the fragment
reassembly queues of hosts to which the datagrams are sent. A failed connection
or RPC attempt will potentially generate many fragments. These will obviously
time out eventually but the recommended value for IP reassembly timeout is quite
long (60-120 secs). In practice of course TCP SYNs will arrive un-fragmented due
to their size.

Another problem with this approach is that one tells the sending host a 
complete load of ambiguous cobblers (ICMP Time Exceeded Reassembly from target
and ICMP Unreach Host from gateway) blech!.

--
   Rob.

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Aug 1992 12:47:02 GMT
From:      tsalonen@dsclus.ntc.nokia.com
To:        comp.protocols.tcp-ip
Subject:   Wanted: routing protocol source codes


 Hello,

 We are looking for the source code (C-code) for the following routing
protocols: RIP, BGP, EGP and OSPF. Do anyone have any idea of
where we can find them ?   

Thanks in advance.

Tapio Salonen




-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 92 15:45:40 GMT
From:      mills@ccu.umanitoba.ca (Gary Mills)
To:        comp.protocols.tcp-ip
Subject:   TCP from shell scripts

I suspect that somebody has written Unix software to allow shell
scripts to act as TCP clients and servers.  What I would like to
do is call a command from a script that connects to and communicates
with a server on another host, much like rsh can do.  The server
would have to be a front-end that execs another script.  I have
found something called ``superserver'' that works like this, but
does more than I need.  Is there anything else like this?  I don't
want to reinvent any wheels.

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

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Aug 1992 16:15:43 GMT
From:      wade@nb.rockwell.com (Wade Guthrie)
To:        comp.protocols.tcp-ip
Subject:   TCP over SLIP on PC, Why not?



Let me display my ignorance, here -- I'd like to be able to do something like
anonymous FTP across a modem to one of the FTP sites.  Is there a reason why
TCP can't be overlaid on top of SLIP?  Would this work for TCP/IP over a modem?
Could FTP be layered on top of this?  What would be required for the receiving
site?  Thanks.

Wade Guthrie
wade@nb.rockwell.com

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 92 16:32:55 GMT
From:      clark@daffy.tmc.edu (Matthew Clark)
To:        comp.protocols.tcp-ip
Subject:   HELP! TCP/IP packet driver needed for 3com 3c523b-tp card!

Would any kind soul out there either have or know where I can find
a driver set for a 3com 3c523b-tp ethernet card, so I can run tcp/ip
protocol on it?

Thanks!

Matt Clark
Data Communications, USF
clark@daffy.csee.usf.edu

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Aug 1992 16:58:08 GMT
From:      ylee@syl.dl.nec.com (Ying-Da Lee)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Multiple Subnets and Non-byte boundary netmasks

In article <1992Jul31.201508.7128@acc.com> art@acc.com (Art Berggreen) writes:
>I'm willing to declare it a non issue unless someone can produce a system
>with the problem.

Well, not exactly a 'problem' though it could be a nuisance
for setup and maintenance of your in-addr.arpa DNS database.

I handle netwrok 143.101 among others.  With netmask of 255.255.255.0,
when I allocate a subnet to a division I can also create a separate
zone for it and add a line of NS for it in my 101.143.in-addr.arpa
database.  The network/system administrator of the respective division
can take care of what he does with that particular subnet without
informing (a.k.a. bugging) me and all is harmony and happiness.  Had
I used a non byte-aligned netmask, I would not have been able to have
separate zones for the subnets and would have had to list all
the individual hosts directly in the 101.143.in-addr.arpa database,
which is something I do not relish.  Of course if your policy is to
handle all the DNS in a centralized rather than a distributed fashion
anyway, then this would not matter.

This is not to say that non byte-aligned netmask is a bad thing,
indeed I believe people should be able to pick whatever appropriate
netmask to suit their needs. I just wish that the State of IP is
such that making such a choice does not bring forth this kind of
additional complications.


	Ying-Da Lee	(214)518-3490	(214)518-3552 (FAX)
	Principal Member, Technical Staff
	NEC Systems Laboratory, C&C Software Technology Center /
	NEC USA, Corporate Network Administration Division
	ylee@syl.dl.nec.com	uunet!necbsd!ylee

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Aug 1992 17:21:20 GMT
From:      chrisp@efi.com (Chris Phoenix)
To:        comp.protocols.tcp-ip
Subject:   Protected ports for LPD

What is the real-world use of the protected port space in lpd
implementations?  I haven't looked in the RFCs because I don't have
much time and I don't trust them to reflect what "real world"
implementations do.

My current knowledge is that there is a range of ports that are
"trusted" and are theoretically only usable by the kernel on a TCP-IP
implementation, and that lpd is only supposed to listen to requests
from these ports.  Are there any packages out there in which the
clients do not use these ports?  In other words, what checking should
I do if I want to work with all the packages out there?  What if I
want to be secure?  With all the PCs out there, how much of an
advantage is the extra security?  

-- 
"I did not walk into the wall!  OK, I did walk into the wall, but it wasn't
my fault!!"
			Chris Phoenix -- chrisp@efi.com

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Aug 1992 20:21:24 GMT
From:      alberti@mudhoney.micro.umn.edu (Albatross)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP over SLIP on PC, Why not?

In <1992Aug4.161543.7464@nb.rockwell.com> wade@nb.rockwell.com (Wade Guthrie) writes:



>Let me display my ignorance, here -- I'd like to be able to do something like
>anonymous FTP across a modem to one of the FTP sites.  Is there a reason why
>TCP can't be overlaid on top of SLIP?

No.

> Would this work for TCP/IP over a modem?

Yes.

>Could FTP be layered on top of this?

Yes.

> What would be required for the receiving site?

A SLIP server with a modem access.  The SLIP server would be assigned an IP
address for each modem which might potentially host a session.  When someone
calls the SLIP modem and begins a SLIP session, they would receive a message
telling them their IP address.  They would then have to configure that IP
address into their IP-using programs (such as the CONFIG.TEL file for FTP).

If the SLIP server is part of a network with a BOOTP protocol server, then
life becomes simpler.  Instead of reconfiguring files, the CONFIG.TEL file
(or corresponding configuration file) is configured for BOOTP.  When run, 
FTP (or whatever) sends out a BOOTP packet that says essentially "What is
my IP address, who is my gateway, who is my nameserver?"

The BOOTP server sees this reqest and sends a response, the program auto-
configures itself, and everyone is happy.

For a tool to make this easier, look at SLIPDIAL, available for anonymous
FTP from boombox.micro.umn.edu in the /pub/slipdial directory.

> Thanks.

You're welcome.
--
Bob Alberti: Computer & Information Services U of MN | aka: Albatross | Unitar-
E-mail     : alberti@boombox.micro.umn.edu           | Metropolis BBS | ian/
Disclaimer : My employer does not mean what I say.   | (612) 721-1870 | Univer-
Minnesota  : Where butter is a spice.                | BBSing as art. | salist!

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Aug 1992 22:01:55 GMT
From:      ulfis@cyklop.nada.kth.se (Anders Ulfheden)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and mbuf (Bug ?)

In article <1992Aug4.101111.22116@dxcern.cern.ch> fabien@sun2.cern.ch (Fabien Collin) writes:

     We have a problem with TCP/IP on IBM RS/6000 and HP 9000/7X0 :

     We have two programs communicating using internet domain sockets and TCP.
     Program "gen" sends one message to program "sink" -
       sink then "acknowledges" by sending to gen a 1 byte message.
						  ----------------
     NOTE: if you remove the 1 byte ack, it works like a charm on all machines.

[programming stuff deleted]

   Symptoms :

     1) RS/6000 and SLA/SOCC (Serial Optical Link)
	We ran this test between RS/6000s under AIX 3.2 using the SLA/SOCC, and
	the "gen" machine seizes up. According to a trace, the gen process is
	waiting in kernel mode for mbufs. IP is dead, the network is totally
	unusable (You can log in only though the serial console).
	Gen cannot be killed.

[symptom 2 & 3 deleted]

     My question is the following :
     I *guess* that both HP-UX and AIX are based on a BSD TCP implementation...

     Is this a well-known problem in this particular implementation ?

Is the 1-byte ACK padded when sent from RS/6000? I know that IBM/Austin works
on a update for the 802.3 Ethernet driver. This bug was discovered in an
AppleTalk server implementation for the RS/6000. The RS driver padded the
outgoing packets wrong which caused an Ungermann-Bass router to interpret the
packet as bogus. I also heard that AIX 3.1 as standard has more mbufs than
AIX 3.2. Try to increase them...

	   Thanks,

		    Fabien
ulfis
--
+------------------------------------------------------------------------------
|  Anders Ulfheden
|  USENET:  ulfis@nada.kth.se
|  Royal Institute of Technology
|  Stockholm, Sweden

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Aug 1992 22:06:14 GMT
From:      tjbarre@srv.PacBell.COM (Tom Barrett)
To:        comp.protocols.tcp-ip
Subject:   Hardware Query


Does anyone know of a piece of equipment that will allow me to plug
synchronous lines (such as SNA or Bisync) in one side and ethernet
in the other side?  I am looking to distribute access to remote
synchronous hosts on our net.

Please respond by e-mail to tjbarre@PacBell.COM

thanks,
tom barrett

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Aug 1992 22:53:21 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Protected ports for LPD

In article <1992Aug4.172120.19771@efi.com> chrisp@efi.com (Chris
Phoenix) writes:
>My current knowledge is that there is a range of ports that are
>"trusted" and are theoretically only usable by the kernel on a TCP-IP
>implementation, and that lpd is only supposed to listen to requests
>from these ports.

Close.  LPD (on SunOS) listens to ports <= 1024.  These ports are
supposed to be available only to root on a machine (any user process
running as root, not just the kernel).  However, this isn't
"standard."  PC's and Macs don't have the concept of root, so anybody
who is using them can create something with the right port number

>Are there any packages out there in which the
>clients do not use these ports?  In other words, what checking should
>I do if I want to work with all the packages out there?  What if I
>want to be secure?  With all the PCs out there, how much of an
>advantage is the extra security?  

Any client that didn't use these ports would fail to work with Suns,
and likely other vendor products.  I'm not familiar with all the
security aspects of lpr/lpd, so I won't comment on them.  Having
people able to send arbitrary control files to your host doesn't
strike me as the most secure setup in the world, however.

Warner
-- 
Warner Losh		imp@Solbourne.COM
imp@Solbourne.COM: "I should be OK, I'm basically doing the speed limit"
dworkin@rootgroup.com: "That's why BASIC is so slow.  It has a speed limit"

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1992 23:34:35 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

In article <1992Aug4.113414.22866@inmos.co.uk> rob@inmos.co.uk (Robin Pickering) writes:
>In article <15l040INN2iv@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>>Non-initial fragments can simply be forwarded, and filtering should be
>>applied to the initial fragment when it shows up.
 
>I have some nagging doubts about this causing problems by filling the fragment
>reassembly queues of hosts to which the datagrams are sent. A failed connection
>or RPC attempt will potentially generate many fragments. These will obviously
>time out eventually but the recommended value for IP reassembly timeout is quite
>long (60-120 secs). In practice of course TCP SYNs will arrive un-fragmented due
>to their size.

Under normal conditions, I don't think it should be a problem.  As you
implied, most SYNs don't have any data, so they won't be fragmented.  While
NFS often has to fragment packets containing file data, if you reject the
initial mount request (or the portmapper request before that) then you
won't get as far as sending these large data packets.  I think there are
very few protocols that are likely to send fragmented packets before some
initial handshake using small packets, and if you were planning on
filtering the large packets you should also filter out the handshake.

>Another problem with this approach is that one tells the sending host a 
>complete load of ambiguous cobblers (ICMP Time Exceeded Reassembly from target
>and ICMP Unreach Host from gateway) blech!.

I don't think he'll get the Time Exceeded message.  In order for the target
to send Time Exceeded I believe it has to receive the initial fragment (so
it can include it in the data portion of the ICMP).  When reassembly times
out without receiving the initial fragment, the reassembly queue is
discarded silently.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 92 00:32:58 GMT
From:      ddl@burrhus.harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip,comp.protocols.pcnet
Subject:   Re: Clemson University Packet Driver: I have one problem B-(.

In article <1992Aug4.071618.470@medtron.medtronic.com>, rh0083b@medtronic.COM (Roger-Hunen) writes:
| Isn't it possible
| then that you get a timer interrupt during the upcall which could cause
| things to break? Russel, Eric??

	Yes, it is.  And this scenario needs closer examination because
the proposed restriction on send calls while in an upcall will result
in a far less useful packet driver interface.  In general, if you
disallow sends from the upcall, then you either (1) disallow sends
from *any* interrupt context (since you can never be sure that you have
not interrupted another client's upcall) or (2) disallow enabling interrupts
in the upcall.
	It has been argued that (2) is already implied by the current
spec but there is no easy way to be sure that no existing applications
enable interrupts.  It is stated that early PC/TCP versions *do* enable
interrupts and it is unclear whether this is a "bug" or an acceptable
way to implement.  Of course, the main problem with (2) is that your
application will fail because some other application enables interrupts.
This makes for hard-to-track interactions.
	The problems with (1) should be obvious.  Now, allowing a packet
driver to return an error when send is invoked from an upcall won't cause
major grief since most protocols can cope with retransmits.  But allowing
a packet driver to *crash* (as some now do) under these conditions reduces
the utility of the interface considerably.  Legitimizing such behavior
is a very bad idea.

				Dan Lanciani
				ddl@harvard.*

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Wed, 05 Aug 92 00:41:04 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: Terminology for firewalls (was Re: Firewall usage)

> mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum) writes:
>>| Simple gateway - a node which is reachable on two networks, but has routing
>>| 	disabled, making it a termination point on both. This is typically
>>| 	a host with TCP/IP forwarding disabled.
 
 kre@cs.mu.oz.au (Robert Elz) writes:
> >That isn't a gateway at all, its a multi-homed host, which is a term
> >that's been around since about forever.

donp@novell.com (don provan) writes:
> I think he really did mean "gateway" in the modern sense, not "router".
> You telnet in from the outside world through one interface, authenticate
> yourself via a login, and then telnet or whatever out of the other
> interface to access machines within the sphere of protection.

Then a better name might be "application level gateway".  "Simple" doesn't
really explain what's going on.  An application-level gateway can be a lot
more complicated than an IP-level gateway....  And the definition should
probably emphasize the relaying of data, rather than the lack of IP routing;
if the host isn't doing forwarding data at the application layer, it fits
Marcus's definition but not the label "gateway".

-- 
Tom Fitzgerald   Wang Labs       fitz@wang.com   "I went to the universe today;
1-508-967-5278   Lowell MA, USA                   It was closed...."

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 92 01:39:00 GMT
From:      644736@aisserver2.llnl.gov (Leif Nelson)
To:        comp.protocols.tcp-ip
Subject:   Domain Name Server and config.ora on Mac

We have been using SQL*Net on the Macintosh to connect to remote Oracle databases using Clear Access, Oracle Card, SQL*Forms for the Mac etc.  Up until now, this has worked perfectly for the databases we need to connect to.  Now, however, we have been moving our database machines around and changing their IP addresses, etc.  Each time the database machine moves, we have to modify the config.ora file in every Macintosh that connects to the database.  We have tried to use names registered in the Domain Name 



Server in our config.ora file, but this does not work.  We were wondering if there was some other way to solve this problem so that Macintosh based Oracle applications can use the Domain Name server to resolve the IP address of the remote database.  We have confirmed that we can put the Oracle home folder on an AppleShare file server, but due to political problems, logistics, etc.  we are not prepared to implement that solution.  Any information would be appreciated!

Leif Nelson   lnelson@llnl.gov
Grant Johnson grantj@llnl.gov
 

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Aug 1992 01:40:01 GMT
From:      eengelke@steam.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip,comp.protocols.pcnet
Subject:   Re: Clemson University Packet Driver: I have one problem B-(.

 rh0083b@medtronic.COM (Roger-Hunen) writes:
> tomiii@mtu.edu (Thomas Dwyer III) writes:
>
>>Does this mean that one should not send a packet during the upcall when
>>AX=0, or when AX=1 (or both)?  I was under the assumption that you can
>>call SEND_PKT during the upcall, but only when AX=1.  Am I mistaken?
 
>I waded through the WATTCP source code, and all SEND_PKT calls are kept
>outside the upcalls. I did not check the details very carefully, but almost
>any send actions seem to be done on timer interrrupts. Isn't it possible
>then that you get a timer interrupt during the upcall which could cause
>things to break? Russel, Eric??

Russel has the habit of writing drivers which will survive abuse
so you might be tempted to just try it and assume all drivers
support sends on upcalls.

When I wrote WATTCP, I decided to not insist on the assumption
that we can transmit in the upcall.

Case in point?  Several brands of network cards have a single receive
buffer which must be cleared so they can receive the next packet.
So we must empty the buffer quickly and re-enable interrupts so
it won't drop packets.  But we cannot re-enable interrupts until
after the second upcall, otherwise we may have re-entrancy, but 
if we permit sends during the upcall, we are leaving the network
card in a state where it cannot receive packets and this generates
errors on certain ring-based hardware and dropped packets on all
types of hardware.

The correct solution is to write the packets out after the interrupt.
This can be on the next clock tick if you can wait an average of
28 ms, or you can do it instanteously with the following code.

Find out the hardware interrupt of the network adapter,  many 
poacket drivers support the extended info function which supplies
this information.  Then chain your user interrupt to the network
interrupt so it gets executed after the packet driver.

	new_interupt:	pushf
		    	call dword old_interrupt
			jmp  our_new_code

our_new_code can send packets or do anything we please.  But
make it efficient by quickly checking for received packets
and iret-ting otherwise.  If you are running Netware or any
other network which generates a lot of packet i/o, an 
inefficient network interrupt will significantly cut 
performance.

And if you can't find the hardware interrupt number, do the
same thing, by tie it onto the hardware timer tick.

These techniques are used by most of the commercial tcp stacks,
notably Beame&Whiteside, FTP, Wollongong, and others.  

I can speculate on several other packet drivers which should not
be written to on the upcall, but let it suffice to say it is
not recommended in my books, and others who make their living
writing to packet drivers don't tend to do it either.

Erick

-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Aug 1992 01:45:05 GMT
From:      eengelke@steam.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Protected ports for LPD

 chrisp@efi.com (Chris Phoenix) writes:
>What is the real-world use of the protected port space in lpd
>implementations?  

There is little trust in protected ports.  PC implementations
(like mine) permit anyone to open a port with any value.

>In other words, what checking should
>I do if I want to work with all the packages out there?  What if I
>want to be secure?  With all the PCs out there, how much of an
>advantage is the extra security?  

Full source is available for PCs, so don't trust them at
all.

If the incoming IP address is known to be from a PC, don't
trust it.

If the incoming IP address is known to be coming from a UNIX
system, it could be a PC faking the address, but that is usually 
harder to pull off without someone noticing something has gone awry.

Erick

-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 92 09:31:21 GMT
From:      cudcv@warwick.ac.uk (Rob McMahon)
To:        comp.protocols.tcp-ip
Subject:   Response to request for connection to port without a service

I just put up the RFC931 server, pidentd-1.8, on my Unix servers, since it
seemed like a Good Thing.  Fine.  I then tried wrapping my telnetd, rlogind et
al., servers in identify-0.5, and adding the authentication patches to
sendmail.  Oops.  Now telnetting from a Mac running NCSA/BYU Telnet 2.3.4
hangs when the telnetd wrapper tries to call back to the ident port.  Sendmail
hangs when a Charon gateway (3.4 running over a packet driver) tries to talk
to it, waiting to call back to the ident port.  All works fine talking to
another Unix host.

Here's a dump of the interchange when trying to telnet from a Unix machine to
the ident port on the charon gateway ...

------------------------------------------------------------------------------
cudcv (4399) > tcpdump host gator and host lily
tcpdump: listening on le0
10:10:56.212644 lily.2142 > gator.ident: S 2071872000:2071872000(0) win 4096 <mss 1460>
10:10:57.319324 gator.ident > lily.2142: R 0:0(0) win 0
10:11:02.068624 lily.2142 > gator.ident: S 2071872000:2071872000(0) win 4096 <mss 1460>
10:11:02.105252 gator.ident > lily.2142: R 0:0(0) win 0
etc.
------------------------------------------------------------------------------

telnet hangs until you break in.  Here's doing the same to a Unix machine
without the ident daemon ...

------------------------------------------------------------------------------
cudcv (4400) > tcpdump host thistle and host lily
tcpdump: listening on le0
10:14:43.499648 lily.2148 > thistle.ident: S 2101504000:2101504000(0) win 4096 <mss 1460>
10:14:43.500305 thistle.ident > lily.2148: R 0:0(0) ack 2101504001 win 0
No etc.!
------------------------------------------------------------------------------

telnet returns immediately with 

telnet: connect: Connection refused

The only difference appears to be the missing ack on the reset packet from the
Charon gateway.

Presumably the PC and Mac IP stacks are broken, and Unix is getting it right.
Can someone point me at the appropriate RFC.  I guess this means I can't use
the ident stuff, what do other people do ?

Cheers,

Rob
-- 
UUCP:   ...!mcsun!uknet!warwick!cudcv	PHONE:  +44 203 523037
JANET:  cudcv@uk.ac.warwick             INET:   cudcv@warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 92 11:03:17 GMT
From:      ebc@uiscpt.UUCP (Errol Back-Cunningham)
To:        comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   SCO UNIX to WANG COMMUNICATION


Does anyone have experience of connecting a WANG VS100 running
VS 7.21.03 to a SCO UNIX 486 for a remote login session? We're
using TCP/IP on the WANG and the SCO login screen keeps scrolling,
making login in impossible.

Are there any other WANG/SCO connectivity products available?

Thanx in advance.

Errol.

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 92 11:47:08 GMT
From:      cmaeda+@cs.cmu.edu (Christopher Maeda)
To:        comp.protocols.tcp-ip
Subject:   Re: Protected ports for LPD

In article <BsHM75.3FB@watserv1.uwaterloo.ca> eengelke@steam.uwaterloo.ca (Erick Engelke) writes:
> chrisp@efi.com (Chris Phoenix) writes:
>>What is the real-world use of the protected port space in lpd
>>implementations?  
>
>There is little trust in protected ports.  PC implementations
>(like mine) permit anyone to open a port with any value.
>
>>In other words, what checking should
>>I do if I want to work with all the packages out there?  What if I
>>want to be secure?  With all the PCs out there, how much of an
>>advantage is the extra security?  
>
>Full source is available for PCs, so don't trust them at
>all.
>
>If the incoming IP address is known to be from a PC, don't
>trust it.
>
>If the incoming IP address is known to be coming from a UNIX
>system, it could be a PC faking the address, but that is usually 
>harder to pull off without someone noticing something has gone awry.
>

This is silly.  What if the unix box is a workstation?  Why should you
trust it any more than a pc?  If you give me access to the machine
console on a unix box (== keyboard on a unix workstation), you've
already compromised the security of the machine.

If you really care about the security of your print spooler, you
should add a real authentication scheme.  This address checking crap
will only lull you into a false sense of security.  Then some evil
hacker will come along and print the emacs lisp manual while you're
napping.

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

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Wed, 05 Aug 92 14:17:41 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Clemson University Packet Driver: I have one problem

In article <1992Aug4.071618.470@medtron.medtronic.com> rh0083b@medtronic.COM writes:

   In article <1992Aug3.131945.3470@mtu.edu> tomiii@mtu.edu (Thomas Dwyer III)    writes:
   >>I suppose that you try to send a packet while you are in the receiver
   >>(called by the packet driver)? Well, I vaguely remember a statement from
   >>Russ Nelson that this may not work with 1.09 compliant drivers. The spec
   >>does not say anything about this, but the general consensus is that it is
   >>bad practice.
   
   [deleted]
   
   >Does this mean that one should not send a packet during the upcall when
   >AX=0, or when AX=1 (or both)?  I was under the assumption that you can
   >call SEND_PKT during the upcall, but only when AX=1.  Am I mistaken?
   
   I guess it depends on the specific packet driver whether things break or
   not. But as the packet driver interface is meant to be generic, you must
   not do this if you want your application to work with all packet drivers.
   As far as I know you must not call SEND_PKT during any upcall.
   
   I waded through the WATTCP source code, and all SEND_PKT calls are kept
   outside the upcalls. I did not check the details very carefully, but almost
   any send actions seem to be done on timer interrrupts. Isn't it possible
   then that you get a timer interrupt during the upcall which could cause
   things to break? Russell, Eric??

Roger is correct.  Sending a packet during the upcall does not work
with some drivers.  The possibility of sending a packet during the
upcall is not addressed by the 1.09 specification.  Some major packet
driver software sends packets in the upcall.  Another major
manufacturer's packet driver stops receiving if you send packets in
the upcall.  :)  Interoperability, I love it.

Someone is paying me to fix the packet driver.  Fixing the
application would be more work for them.

-russ <nelson@crynwr.com>  I'm proud to be a humble Quaker!
Crynwr Software            Crynwr Software sells packet driver support.
11 Grant St.               315-268-1925 Voice
Potsdam, NY 13676          315-268-9201 FAX

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 92 14:51:12 GMT
From:      berman@nlm.nih.gov (Lew Berman)
To:        comp.protocols.tcp-ip
Subject:   ftp times


I am interested in finding the method ftp uses to measure the transmission
time.  I need to determine if the receiving end starts the clock upon
receiving the first packet, upon sending out the request, etc.  When does it
stop the clock...after writing everything out to disk, upon receving the last
packet, etc?  ANy help you can provide will be greatly appreciated.

Thanks,

Lew Berman
National Library of Medicine
Bethesda, MD

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 92 17:03:23 GMT
From:      jch+@cs.cmu.edu (Jonathan Hardwick)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin,comp.sys.sun.misc
Subject:   REPOST: "sz0: slip overflow" on SLIP / Sun-3/50 / SunOS 4.0.3 setup

Sorry if this is a repeat post -- my first attempt disappeared without
visible trace 24 hours ago.

Setup: 
The most modern version of Rayan Zachariassen's SunOS SLIP that I
could find (README file dated Oct 29 1989), running on a minimal SunOS
4.0.3 kernel on a Sun-3/50.  Runs at 19.2kbps using a Data-Over-Voice
modem through an annex terminal server to a SLIP host.  Configured for
1006-byte MTUs, without SLIP_FASTECHO or SLIP_STATS.

Problem:
When SLIP is pushed to the limit (eg major X applications), or when
the workstation is trying to do too many things at once (eg swapping),
I get
	sz0: silo overflow
errors on the console.  I assume this means that characters are being
dropped by the Sun serial interface.

Question: 
TCP/IP seamlessly recovers from any errors introduced by these
overflows, but I'd like to eliminate them completely.  Is there any
patch to the SLIP code or to the 4.0.3 kernel that fixes it?  Raising
an interrupt level, maybe?  "Upgrading" to SunOS 3.5 has been
suggested, but I'd like to avoid that if possible.

Thanks in advance,
Jonathan H., jch@cs.cmu.edu

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 1992 19:43:08 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Response to request for connection to port without a service

In article <97pnbbw2@csv.warwick.ac.uk> cudcv@warwick.ac.uk (Rob McMahon) writes:
>The only difference appears to be the missing ack on the reset packet from the
>Charon gateway.
>
>Presumably the PC and Mac IP stacks are broken, and Unix is getting it right.
>Can someone point me at the appropriate RFC.  I guess this means I can't use
>the ident stuff, what do other people do ?

Yes, the PC and Mac are broken.  RFC 793, the definition of TCP.  From
p.65:

  SEGMENT ARRIVES

    If the state is CLOSED (i.e., TCB does not exist) then

      all data in the incoming segment is discarded.  An incoming
      segment containing a RST is discarded.  An incoming segment not
      containing a RST causes a RST to be sent in response.  The
      acknowledgment and sequence field values are selected to make the
      reset sequence acceptable to the TCP that sent the offending
      segment.

and pp.66-67:

    If the state is SYN-SENT then

      ...

        If the RST bit is set

          If the ACK was acceptable then signal the user "error:
          connection reset", drop the segment, enter CLOSED state,
          delete TCB, and return.  Otherwise (no ACK) drop the segment
          and return.

The acknowledgement is necessary so that the RST can be distinguished from
a delayed or duplicate RST from an earlier connection attempt (the SYN
sender is not required to leave the TCB in TIME-WAIT state when it gets a
RST, so it's possible to reuse source ports).

I tried it with a Mac running MacTCP (I don't know what version), and the
RST packet had an appropriate ACK.  However, in the process of trying
various things I discovered that it doesn't send ICMP Port Unreachables
when you send a UDP packet to an unknown port (so traceroute to a Mac
doesn't work right).

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 92 20:34:42 GMT
From:      cts@dragon.com
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Need PC TCP/IP product to coexist with Novell

We currently have token rings in Atlanta and LA connected via a bridge.  We
plan to add two new rings, also via bridge, located in Miami and Houston.
These users will need to access an IBM RS6000 system attached to the 
Atlanta token ring via TCP/IP (possibly other systems as well).  The 
Miami ring will be running Novell 3.1, the Houston Ring Novell Lite.

I'm looking for recomendations for a PC based TCP/IP product that 
can coexist with both Novell and Novell Lite, and provides TCP/IP
support over Token Ring.

Thanks,
  Charles Smith
  cts@dragon.com

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Aug 1992 21:34:13 GMT
From:      peter@ferranti.com (peter da silva)
To:        comp.protocols.tcp-ip
Subject:   Re: Terminology for firewalls (was Re: Firewall usage)

In article <1992Aug3.175023.9159@novell.com> donp@novell.com (don provan) writes:
> >That isn't a gateway at all, its a multi-homed host, which is a term
> >that's been around since about forever.
 
> I think he really did mean "gateway" in the modern sense, not "router".

I call this an application-level gateway. We run a number of these between
OSI and TCP networks.
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Aug 1992 22:20:45 GMT
From:      gyan@unixg.ubc.ca (Gyan P. Sinha)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP over SLIP on PC, Why not?

In <1992Aug4.202124.27835@news2.cis.umn.edu> alberti@mudhoney.micro.umn.edu (Albatross) writes:

>In <1992Aug4.161543.7464@nb.rockwell.com> wade@nb.rockwell.com (Wade Guthrie) writes:



>>Let me display my ignorance, here -- I'd like to be able to do something like
>>anonymous FTP across a modem to one of the FTP sites.  Is there a reason why
>>TCP can't be overlaid on top of SLIP?
 
>No.
 
>> Would this work for TCP/IP over a modem?
 
>Yes.
 
>>Could FTP be layered on top of this?
 
>Yes.
 
>> What would be required for the receiving site?
 
>A SLIP server with a modem access.  The SLIP server would be assigned an IP
>address for each modem which might potentially host a session.  When someone
>calls the SLIP modem and begins a SLIP session, they would receive a message
>telling them their IP address.  They would then have to configure that IP
>address into their IP-using programs (such as the CONFIG.TEL file for FTP).
 
>If the SLIP server is part of a network with a BOOTP protocol server, then
>life becomes simpler.  Instead of reconfiguring files, the CONFIG.TEL file
>(or corresponding configuration file) is configured for BOOTP.  When run, 
>FTP (or whatever) sends out a BOOTP packet that says essentially "What is
>my IP address, who is my gateway, who is my nameserver?"
 
>The BOOTP server sees this reqest and sends a response, the program auto-
>configures itself, and everyone is happy.
 
>For a tool to make this easier, look at SLIPDIAL, available for anonymous
>FTP from boombox.micro.umn.edu in the /pub/slipdial directory.
 
>> Thanks.
 
>You're welcome.
>--
>Bob Alberti: Computer & Information Services U of MN | aka: Albatross | Unitar-
>E-mail     : alberti@boombox.micro.umn.edu           | Metropolis BBS | ian/
>Disclaimer : My employer does not mean what I say.   | (612) 721-1870 | Univer-
>Minnesota  : Where butter is a spice.                | BBSing as art. | salist!


OK, I've got everything configured just like above, using CUTCP for DOS.
What I'd like to know is if an equivalent setup is available for OS/2?

I'd appreciate any information in this regard.

thanks

Gyan P. Sinha
UBC, Vancouver

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Aug 1992 22:25:57 GMT
From:      pngai@adobe.com (Phil Ngai)
To:        comp.cad.cadence,comp.protocols.tcp-ip
Subject:   TCP/IP is a registered trademark

Cadence PCB Library Development Guide Version 4.2,
December 1991, document number 04-25031-0101 says:

TCP/IP is a registered trademark of FTP Software, Inc.

-- 
My opinions are my own.
A right delayed is a right denied.


-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 92 00:12:14 GMT
From:      DART@SLACVM.SLAC.STANFORD.EDU (415)
To:        comp.protocols.tcp-ip
Subject:   RECOMENDATIONS FOR TCP/IP COURSES?

I am looking for information concerning TCP/IP courses.
I have taken a preliminary course and so I understand the
basics about A, B, and C types of addresses and subnets and
those sorts of things.  What I'm looking for is an intermediate
or advanced level course that explains more of the inner workings
of the IP protocols and gives me the background that I need for
troubleshooting IP traffic problems on my network.

I have looked at a course offered by Interop

            TCP/IP: Internals and Implementations,

and it also appears that the course

            Theory of Bridges and Routers: Protocols and Algorithms in Depth,

might be helpful in this area.  Can anyone comment on their satisfaction
with these courses?

Thank you,
Marty Dart.

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 92 00:27:33 GMT
From:      jch+@cs.cmu.edu (Jonathan Hardwick)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin,comp.sys.sun.misc
Subject:   Re: REPOST: "sz0: slip overflow" on SLIP / Sun-3/50 / SunOS 4.0.3 setup

The subject line is, of course, wrong.  It should read
	zs0: silo overflow

That'll teach me to rely on my memory when reporting cryptic errors...

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 1992 02:33:22 GMT
From:      mfitz@devnull.West.Sun.COM (Mark Fitzpatrick - Systems Engineer)
To:        comp.protocols.tcp-ip
Subject:   RPC Programming & inetd

I have a pretty easy question.  I want to run my RPCGEN'erated program
(blob) through inetd but I keep getting "unknown service" errors when I do
my "kill -HUP <inetd pid>".

my /etc/rpc file has the entry:

  blob  536870913

my /etc/inetd.conf has the entry:

  blob/1 stream rpc/tcp wait root /path/to/my/executable/blob


I used the -I switch with RPCGEN and the number 20000001 is the procedure
number I used (0x20000001 = 536870913 (decimal)); is that the right number 
to use?  Any other ideas?

Thanks,
Mark




-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Thu,  6 Aug 1992 09:25:44 -0400
From:      Tom Holodnik <tjh+@andrew.cmu.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: Annex SLIP with 256 mtu?


We ran into the same problem.  My conclusion, after looking at the
fragments generated from the Annex and seeing they were properly formed,
was that many machines can't handle IP datagrams sliced into 3
fragments.  Whether it's because of the way that they're reassembled, or
whether the fragment reassembly times out, I couldn't say for certain.  

Since for many systems the fragment reassembly code is the same no
matter what physical interface you use, it's unlikely that there's a bug
in the fragment reassembly code.  So for a Sun, it's extremely unlikely
that the problem is with the fragment reassembly code, and more likely
that the fragment reassembly just times out.  

When I looked at the SNMP counter for fragment reassembly timeouts on
the Sun operating over a SLIP link, they did go up as the fragmented
packets came in, so that seemed to be the correct diagnosis to me at the
time.  

One possible solution might be to simply use a faster serial line -
maybe you can fill the buffers up fast enough that the fragments no
longer time out.  Another solution is to use a SLIP package that is
capable of handling 1006 MTU sizes.  

Hope this helps,
-tom




-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 92 03:19:21 GMT
From:      sob@hsdndev.UUCP (Scott Bradner)
To:        comp.protocols.tcp-ip
Subject:   Harvard performance tests - Fall '92

Well, its about that time again.  The next round of the Harvard performance
tests will start the 1st week of Sept.  I'll be testing routers this time.
Just about any router with just about any protocol & interface.

Including:
	Ethernet, 16Mb token ring (4Mb if needed), FDDI, 56Kb, T1, T3
	TCP/IP, DECnet, IPX, AppleTalk, TCP/IP on 802.3, OSI, bridge mode
	up to 12 ports on Ethernet, 2 or 4 on token ring, 2 on FDDI

In addition the tests will include the effect of management, broadcast,
and routing traffic and filters.  The tests include, throughput, frame loss rate, latency and system restart. (See RFC 1242 for definitions and the
draft of the BMWG methodology document - on hsdndev.harvard.edu in
pub/bmwg - for details )  As much as possible the tests will use actual 
routing (i.e. not just frames to adjacent networks).

The testers can generate & check frames on a single type of interface
(Ethernet to Ethernet for example) so the testing of mixed interface 
devices is done with two units: ( there is some hope for FDDI to
Ethernet using the Tekelec, I'll know more next week.)

e.g.

                --------           --------
  Ethernet======| DUT1 |-----T1----| DUT2 |=======Ethernet
                --------           --------

All combinations of media types can be supported in this way.

The results will be presented during my Interop tutorial (plug, plug), at 
an Interop special session on Wed 28 oct at 5:30 and added to the
data already on hsdndev.harvard.edu in pub/ndtl. (it will not be 
put onto the net until after the presentations) The data will also be
presented in summary form in a number of publications (Network World, 
Comm Week etc) and in detailed form in one publication, as yet not
finalized.

Vendors will be required to sign a statement that the software/firmware
used will be in the standard, production, system within 3 months of
Oct 28th and that it is not special software just for the testing. All
the better if it is the current release.

The report, like the data on hsdndev, will be cumulative, i.e. all of
the results will be presented, not just the new stuff.

Any vendors that would like to take part should contact me to schedule
a time for the testing.  I expect that this will include both vendors of 
new equipment and vendors who have updated their systems since the last
testing.  The tests are free (well, Harvard & I don't charge, but I 
expect that the airlines & hotels will :-) )

Each vendor gets a copy of their results on the day of the testing and
can make some use of those results. They can show their customers or potential customers but not issue any sort of press release until the full report is presented. They don't get to see the results of other vendors tests until everyone does.

An Alantec PowerBits will be used to generate & check Ethernet traffic,
the Proteon special software & hardware  for token ring and the Tekelec
ChameLAN 100S for FDDI.  The scripts that will be used will be placed on
hsdndev as I work on them so that vendors with those devices can see
what is coming and can help in working them out if they wish.

Mailing lists have been set up for those who:

	1/ have the specific tester
	2/ want to help debug the scripts
	    (i.e. these are not for the general public)

Send mail to the following addresses to be added to the lists:

	powerbits-request@harvard.edu	- for Alantec PowerBits
	protester-request@harvard.edu	- for Proteon tester
	tekelec-request@harvard.edu	- for Tekelec ChameLAN 100S

Scott Bradner
Harvard University - Network Device Test Lab
10 Ware St, Cambridge MA, 02138
(617)495-3864, FAX (617)495-0914

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Thu, 06 Aug 92 05:11:30 GMT
From:      cmaeda+@cs.cmu.edu (Christopher Maeda)
To:        comp.protocols.tcp-ip
Subject:   UDP port unreachable messages

In article <15pb0cINNr7u@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>
>I tried it with a Mac running MacTCP (I don't know what version), and the
>RST packet had an appropriate ACK.  However, in the process of trying
>various things I discovered that it doesn't send ICMP Port Unreachables
>when you send a UDP packet to an unknown port (so traceroute to a Mac
>doesn't work right).

Technically, it's not required to do so.  In RFC1122, this is a
"SHOULD" item, not a "MUST" item.



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

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 92 06:19:05 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   MacTCP ICMP (was Re: UDP port unreachable messages)

In article <1992Aug06.051130.148461@cs.cmu.edu> cmaeda+@cs.cmu.edu (Christopher Maeda) writes:
>In article <15pb0cINNr7u@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>>I discovered that [MacTCP] doesn't send ICMP Port Unreachables
>>when you send a UDP packet to an unknown port (so traceroute to a Mac
>>doesn't work right).
>Technically, it's not required to do so.  In RFC1122, this is a
>"SHOULD" item, not a "MUST" item.

Thanks for the correction.

I did some more tracing, and noticed that it *was* sending ICMP Time
Exceeded for UDP packets received with TTL = 1.  However, the data portion
of the ICMP message didn't include enough of the original packet so that it
would be reported to traceroute (it had all zeroes where the original port
numbers should have been).

Should it be sending these Time Exceeded messages at all, though?  Routers
send them if they receive a packet with TTL = 1, since they can't forward
it with TTL = 0.  But when Suns receive packets destined for them with TTL
= 1 they process them normally.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Aug 1992 07:14:53 GMT
From:      fabien@sun2.cern.ch (Fabien Collin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and mbuf (Bug?)

	Thanks to all people who replied !
	I found the problem :
	My test contained a deadlock !

	First, with Rs/6000 and the optical link, the network layer crashed.
	The problem has been reported to IBM.

	Second, it hangs on Ethernet with all machines I tried. That's
	normal since it contained a (vicious) deadlock.

	The explanation is the following : 
	read and write have different semantics with files and sockets !

	In fact, my test hangs because of a deadlock (both programs after A
	while tried to do a write in the same time while the socket queue
	was full i guess).

	If you do a count = read(fd,buf,bytes) and fd is a regular file,
	then count is always equal to bytes except :

	- If you are at the end of the file (count = 0) or almost at
	the end (count < bytes)

	- If the read began to read from the file and the syscall is
	interrupted by a signal

	If fd is a socket descriptor, count can be different from bytes
	even if the normal situation (the peer is connected and it sent
	some data).

	If I do a 'man read', only the semantics for files are indicated,
	that's why I made the error.

	I replaced read (and write) by myread (mywrite) :

int myread(s,buf,count)
     int s,count;
     char *buf;
{
  int n = count,i,k = 0;

 retry:
  if ((i = read(s,buf + k,n - k)) <= 0)
    return(i);

  if (i < (n - k)) 
    { 
      k += i; 
      goto retry;
    }

  return(n);
}

	and now, it works perfectly.

	Now it works on HP on Ethernet.
	It works with Rs/6000 on Ethernet.
	It works with Rs/6000 on SLA/SOCC without crashing the network
	layer as my previous test...

	There is no bug in the BSD TCP implementation, only in AIX 3.2
	with the SLA/SOCC driver.

							Fabien

-- 
-------------------------------------------------------------------------
 COLLIN Fabien				| Computing & Networking Division	
 Email: fabien@sun2.cern.ch		| Building 31, 3-013		
 Voice: + 41-22-767-2487		| CERN 1211 Geneva 23		
 Fax :	+ 41-22-767-7155		| Switzerland			
-------------------------------------------------------------------------

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 92 08:14:06 GMT
From:      wmchung@eng.ie.cuhk.hk (chung wai man)
To:        comp.protocols.tcp-ip
Subject:   About IP raw socket

Hi!

I need to do a project building a transport protocol based on IP. I have difficulties on using IP.

I wonder if there are any books has more elaboration (example programs) on using IP by opening a raw socket. I can hardly find anyy! Source code about this is also helps..ps.

Please reply via direct email:wmchung@eng.ie.cuhk.hk

Thanks!

Best Regards,
W.M. Chung

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 92 08:46:01 GMT
From:      elefante@flash.ATC.Olivetti.Com (GUEST Luigi Elefante)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   SLIP driver/documentation

Hi,

Can anyone tell me where I can get SLIP sources and documentation for
UNIX 4.0 ?

Thanks

Massimo Barontini


  E-mail   : elefante@olivey.atc.olivetti.com 

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 92 16:48:19 PST
From:      amichael@gsb-yen.stanford.edu
To:        comp.protocols.tcp-ip
Subject:   Wanted - TCP/IP Compliance Testing Tools

Wanted:
	Info on tools required for testing RFC Compliance of a workstation
stack. Prefer workstation platform, but will consider another platform, if
enough tools are available.
	I don't get a regular opportunity to log on here and read the news 
groups so please email any responses to:

amichael@gsb-yen.stanford.edu

it will forward appropriately.
Thank you in advance for the help with this.
Michael Lukanovich

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Thu, 06 Aug 1992 16:28:39
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.cad.cadence,comp.protocols.tcp-ip
Subject:   Re: TCP/IP is a registered trademark

In article <1992Aug5.222557.6319@adobe.com> pngai@adobe.com (Phil Ngai) writes:

    Cadence PCB Library Development Guide Version 4.2,
    December 1991, document number 04-25031-0101 says:
    
    TCP/IP is a registered trademark of FTP Software, Inc.
    
Sorry, we certainly don't consider that to be the case ("PC/TCP" is
registered, though).  Should I get someone to contact Cadence, or are
their people already watching 'comp.cad.cadence'?

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901


-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 92 12:30:49 GMT
From:      elefante@flash.ATC.Olivetti.Com (GUEST Luigi Elefante)
To:        comp.protocols.tcp-ip
Subject:   SLIP driver

Hi,

Can anyone tell me where I can get SLIP sources and documentation
for Unix SV 4.0 ?

Thanks

Massimo Barontini
e-mail: elefante@flash.ATC.Olivetti.Com


-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Aug 1992 15:13:33 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Annex SLIP with 256 mtu?

In article <AeUGVMm00WCo11ICRI@andrew.cmu.edu>, Tom Holodnik <tjh+@andrew.cmu.edu> writes:
> 
> We ran into the same problem.  My conclusion, after looking at the
> fragments generated from the Annex and seeing they were properly formed,
> was that many machines can't handle IP datagrams sliced into 3
> fragments.  Whether it's because of the way that they're reassembled, or
> whether the fragment reassembly times out, I couldn't say for certain.  

What sort of machines are those?
Consider the typical 8KByte UDP/IP NFS datagram, which is chopped
into more than 3 chuncks on ethernet.
Or consider the pathological IP packet sizes of running NFS between machines
with both ethernet and wide area links that with MTU's < 1500.
The original 1500-byte fragements get diced sideways.

> Since for many systems the fragment reassembly code is the same no
> matter what physical interface you use, it's unlikely that there's a bug
> in the fragment reassembly code.  So for a Sun, it's extremely unlikely
> that the problem is with the fragment reassembly code, and more likely
> that the fragment reassembly just times out.  
> 
> When I looked at the SNMP counter for fragment reassembly timeouts on
> the Sun operating over a SLIP link, they did go up as the fragmented
> packets came in, so that seemed to be the correct diagnosis to me at the
> time.   ....

Could there be an error in the IP ID, so that the receivers cannot
recognize the fragments as related?

What does `netstat -s | grep sum` on the Sun's have to say?
Could there be IP header checksum problems?



Vernon Schryver,  vjs@sgi.com

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Aug 1992 15:31:11 GMT
From:      chrisc@ramrod.lmt.mn.org (Chris Cox)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple Subnets and Non-byte boundary netmasks

In article <1992Aug3.114637.29005@tridom.com> sat@nut.tridom.com (Stephen Thomas) writes:
>From: sat@nut.tridom.com (Stephen Thomas)
>Subject: Re: Multiple Subnets and Non-byte boundary netmasks
>Date: 3 Aug 92 11:46:37 GMT
[Bits gone thataway]

>For example, if a network somewhere is defined as 148.62.2.0 with a mask of
>0xFFFFFE00, and if KA9Q hears a RIP update advertising a route to 148.62.2.0,
>and if has not been told about the correct mask through manual configuration,
>then KA9Q will assume a route to 148.62.2.0 with a mask of 0xFFFFFF00.

We in the Twin Cities MAN (amateur packet radio IP net) use three different 
subnet masks, only one of which falls on an octet-wide boundary.  As all of 
the standard ka9q-based IP implementations always assume that a subnet mask 
will fall on an octet-wide boundary, we had problems :-)

We locally rewrote its RIP implementation so that correct subnet information 
could be propagated throughout the MAN.

If anyone would like the local changes for use in either an amateur radio or 
educational environment, I will try and make them available somewhere.

Chris  W0/G4JEC

   Chris Cox  W0/G4JEC                               chrisc@ramrod.lmt.mn.org
   LaserMaster Technologies                          Tel: (612) 944-6069
   7156 Shady Oak Road                               Fax: (612) 944-5544
   Eden Prairie, MN  55344

           ----- For mail of a more social nature, please use -----

     chrisc@moron.vware.mn.org  -or- chrisc@biggus.g4jec.tcman.ampr.org


-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 92 15:37:40 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

In article <15l040INN2iv@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
> Non-initial fragments can simply be forwarded, and filtering should be
> applied to the initial fragment when it shows up.  If the initial fragment
> is rejected then the datagram will never be fully assembled and will be
> discarded by the destination host.

That works in most situations.  However, if you're worried about an
insider using specialized programs to leak information to an outsider,
this isn't sufficient.  Consider the military models -- and you'll see
why security labels are copied on fragmentation.

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 92 16:32:50 GMT
From:      sap@crosfield.co.uk (stelios pavlides)
To:        comp.protocols.tcp-ip
Subject:   Use of ARP with non-IP protocols

I would appreciate everybody's views on this issue:

Assume there is a non-IP protocol, say XX, which nevertheless uses IP-style
addresses and relies on ARP for address resolution (this conveniently
exists for real in the name of XTP). What one should use in the ar$pro
field of the ARP packet, the IP protocol type (a) or the XX protocol type
(b)?

The case for (a) is that XX, although different to IP, should declare the
IP address space that it uses. That is, ar$pro refers to the address space
and not to the protocol itself.

The case for (b) is that one should have separate ARP tables on a per
protocol basis, even if two protocols use the same address space.

Well, what's the answer?

-- 
Stelios Pavlides			Phone  :  +44 442 230000 ext 3468
Crosfield Electronics Ltd		Fax    :  +44 442 232301
Hemel Hempstead, Herts. HP2 7RH, UK	E-mail :  sap@crosfield.co.uk 
-----------------------------------------------------------------------------

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Aug 1992 16:44:40 GMT
From:      Gary White <gwhite@arco.com>
To:        comp.protocols.tcp-ip
Subject:   question about multiple routes to the same location


Hi-
What tricks would be involved in implementing a dual-path connection
scheme to allow file transfers go over a satellite-hopped connection that
is T1 speed but has the unavoidable 1/2 second round-trip delay time, and
interactive sessions to use a terrestial 56KB link?  I can see how doing
this wouldn't be too hard if there were just two hosts involved and each 
has two Ethernet cards, but what if we have multiple machines in each
location that would like to do this trick?

Thanks!!
-Gary White
  ARCO
  Plano, Texas


               [s]
              /  \
             /    \
            /      \
           /        \T1 speed for FTP, etc.
          /          \
         /            \
        /              \
       /                \
Texas  -----------------  Alaska
            56KB
						terrestial 
						link for X-Windows,
						telnet.

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Aug 1992 19:28:48 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Clemson University Packet Driver: I have one problem B-(.

In article <1992Aug5.003258.1077@burrhus.harvard.edu> ddl@burrhus.harvard.edu (Dan Lanciani) writes:
>Now, allowing a packet
>driver to return an error when send is invoked from an upcall won't cause
>major grief since most protocols can cope with retransmits.

Well, yes, that's true, but if send is invoked during an upcall, the
odds are the data being sent is a reaction to the data received.  For
example, it may be TCP ACKing data received.  Consequently, if the
original data is retransmitted, it may, once again, be answered during
the upcall, and that answer would, once again, be rejected by the
driver.  In other words, in most cases retransmissions won't help
because they'll fall prey to exactly the same limitation the initial
transmission encountered.
						don provan
						donp@novell.com

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 92 20:31:48 GMT
From:      fsi@cbnewsh.cb.att.com (furrokh.s.irani)
To:        comp.protocols.tcp-ip
Subject:   network addition/removal


Can anyone tell me how a process can detect either the connection
or disconnection of a host to an ethernet network running TCP/IP?
In other words, I'd like to know if an existing host on a network
went down or a new host has been brought up on the network. The
process runs on a Sun4, SunOS Release 4.1.

Thanks.

Please reply to me and not the net.

-Furrokh

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 92 00:54:39 GMT
From:      beame@maccs.dcss.mcmaster.ca (Carl Beame)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Need PC TCP/IP product to coexist with Novell

In article <1992Aug5.153442.979@dragon.com> cts@dragon.com writes:
>We currently have token rings in Atlanta and LA connected via a bridge.  We
>plan to add two new rings, also via bridge, located in Miami and Houston.
>These users will need to access an IBM RS6000 system attached to the 
>Atlanta token ring via TCP/IP (possibly other systems as well).  The 
>Miami ring will be running Novell 3.1, the Houston Ring Novell Lite.
>
>I'm looking for recomendations for a PC based TCP/IP product that 
>can coexist with both Novell and Novell Lite, and provides TCP/IP
>support over Token Ring.
>
>Thanks,
>  Charles Smith
>  cts@dragon.com

	Any PC based TCP/IP that supports ODI drivers can coexist with Netware
and Netware Lite. ODI drivers can also be supported via the packet driver 
interface odipkt. Since most TCP/IPs support at least one of packet drivers or
ODI, you should be able to use almost any TCP/IP.

	Two things that should be noted are:

	1) Whether the use of the odipkt shim is supported by the vendor of
	   the TCP/IP.

	2) If you want to run NFS and Netware/Lite, there are other structly DOS
	    issuses which need to be considered. 
 
Carl Beame
Beame & Whiteside Software Ltd.
beame@bws.com

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 92 02:25:55 GMT
From:      trier@odin.INS.CWRU.Edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: network addition/removal

In article <1992Aug6.203148.2891@cbnewsh.cb.att.com> fsi@cbnewsh.cb.att.com (furrokh.s.irani) writes:
>In other words, I'd like to know if an existing host on a network
>went down or a new host has been brought up on the network. The
>process runs on a Sun4, SunOS Release 4.1.

Use etherhostprobe, rover, NNStat, or a combination of all three.  All
three are used here: Etherhostprobe looks for hosts we don't know about,
as does one of our NNStat configurations.  Rover tells us when critical
hosts, routers, off-site links, and pingable bridges are down.

-- 
Stephen Trier                    "I am not a lawyer, though I play one
Network Services Engineering      on the net."
CWRU IRIS/INS/TELECOM                Chris Torek, torek@horse.ee.lbl.gov
trier@ins.cwru.edu

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 92 12:31:30 GMT
From:      ptrubey@netcom.com (Phil Trubey)
To:        comp.protocols.tcp-ip
Subject:   Monitor program for catching duplicate IP addrs?

Does anyone know of a utility program that will scan an Ethernet
and build a table of IP # to ethernet # mappings and check for
duplicate IP #s?  Thanks for any info,

-- 

Phil Trubey                   | Internet: ptrubey@netcom.com
Systemhouse Inc.              | Voice:    415-243-8100 (day)  
                              | Fax:      415-243-0471

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Aug 1992 12:53:05 GMT
From:      andy@uis.com (Andy Edwards)
To:        comp.protocols.tcp-ip
Subject:   NDIS SLIP packet driver wanted for DOS


I am looking for a SLIP packet driver that follow the NDIS
specs(?) to use on a 386 PC running DOS and FTP's PC/TCP package.

Can anyone help me.  I would appreciate it immensely.

	Thanks in advance,

	-- andy


-- 
-----------------------------------------------------------------
Andy Edwards   *   Unix Integration Services   *  Urbandale, Iowa
EMAIL: andy@uis.com                         PHONE: (515) 254-3074

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Aug 1992 13:29:44 GMT
From:      kjell@Xenon.Stanford.EDU (Kjell Saeten)
To:        comp.protocols.iso,comp.protocols.tcp/ip
Subject:   SNAP

Hello, netters!

Can anybody tell me anything about SNAP ( IEEE 802.1) ?
Can I find anything about if on Internet ?
Do I need a SNAP to link IP/ARP to LLC ( over FDDI-net)

Thanks in Advance!

Kjell @neon.stanford.edu

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Aug 92 13:31:26 GMT
From:      dad@mozart.webo.dg.com (David A. Dubois)
To:        comp.protocols.tcp-ip
Subject:   Re: Use of ARP with non-IP protocols

In article <15058@suns6.crosfield.co.uk>, sap@crosfield.co.uk (stelios pavlides) writes:
|> I would appreciate everybody's views on this issue:
|> 
|> Assume there is a non-IP protocol, say XX, which nevertheless uses IP-style
|> addresses and relies on ARP for address resolution (this conveniently
|> exists for real in the name of XTP). What one should use in the ar$pro
|> field of the ARP packet, the IP protocol type (a) or the XX protocol type
|> (b)?
|> 
|> The case for (a) is that XX, although different to IP, should declare the
|> IP address space that it uses. That is, ar$pro refers to the address space
|> and not to the protocol itself.
|> 
|> The case for (b) is that one should have separate ARP tables on a per
|> protocol basis, even if two protocols use the same address space.
|> 
|> Well, what's the answer?
|> 

From RFC 826 (An Ethernet Address Resolution Protocol --or--
Converting Network Protocol Addresses to 48.bit Ethernet Address
for Transmission on Ethernet Hardware):

    16.bit: (ar$pro) Protocol address space.  For Ethernet
                     hardware, this is from the set of type
                     fields ether_typ$<protocol>. 

Ethertype fields are 0x0800 for IP and 0x817D for XTP.

-- 
David A. Dubois                              Phone: (508) 870-9522
Open Network Systems Development             Fax:   (508) 898-4212
Data General Corp, Westboro MA 01580         Net:   dad@mozart.webo.dg.com

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Aug 1992 14:07:23 GMT
From:      berlin@is.morgan.com (Alexander Berlin)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp times

In article <1992Aug5.145112.4349@nlm.nih.gov>, berman@nlm.nih.gov (Lew Berman) writes:
|> 
|> I am interested in finding the method ftp uses to measure the transmission
|> time.  I need to determine if the receiving end starts the clock upon
|> receiving the first packet, upon sending out the request, etc.  When does it
|> stop the clock...after writing everything out to disk, upon receving the last
|> packet, etc?  ANy help you can provide will be greatly appreciated.

I don't think this issue is a part of FTP protocol. I would say it is up to 
a particular FTP implementation.

|> 
|> Thanks,
|> 
|> Lew Berman
|> National Library of Medicine
|> Bethesda, MD

---
Alex Berlin                     
berlin@is.morgan.com

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Aug 1992 14:57:42 GMT
From:      xjeldc@lustorfs.ldc.lu.se (Jan Engvald LDC)
To:        comp.protocols.tcp-ip
Subject:   Re: Monitor program for catching duplicate IP addrs?

In article <jqymwsq.ptrubey@netcom.com> ptrubey@netcom.com (Phil Trubey) writes:
>From: ptrubey@netcom.com (Phil Trubey)
>Subject: Monitor program for catching duplicate IP addrs?
>Date: 7 Aug 92 12:31:30 GMT
 
>Does anyone know of a utility program that will scan an Ethernet
>and build a table of IP # to ethernet # mappings and check for
>duplicate IP #s?  Thanks for any info,

That is just what my PDTBUILD program does. Runs on a PC on top of
a packet driver. Included in the PDCLKSET package, available from
msdos.ftp.sunet.se:pub/network/pdclkset/pdclk144.zip or
ftp.lu.se:pub/network/pdclkset/pdclk144.zip

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

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 92 15:50:54 GMT
From:      Norbert_Papke@mindlink.bc.ca (Norbert Papke)
To:        comp.protocols.tcp-ip
Subject:   Re: Need PC TCP/IP product to coexist with Novell

In article <1992Aug5.153442.979@dragon.com> cts@dragon.com writes:
>We currently have token rings in Atlanta and LA connected via a bridge.  We
>plan to add two new rings, also via bridge, located in Miami and Houston.
>These users will need to access an IBM RS6000 system attached to the
>Atlanta token ring via TCP/IP (possibly other systems as well).  The
>Miami ring will be running Novell 3.1, the Houston Ring Novell Lite.
>
>I'm looking for recomendations for a PC based TCP/IP product that
>can coexist with both Novell and Novell Lite, and provides TCP/IP
>support over Token Ring.
>
>Thanks,
>  Charles Smith
>  cts@dragon.com

Check out the July 1992 issue of PC Magazine.  It contains an article called
"TCP/IP Packages for Netware 3.11."  It reviews BW-NFS for DOS, ICE.TCP,
PathWay Access, and PC/TCP Plus.

-- Norbert.

--
Norbert Papke (Norbert_Papke@mindlink.bc.ca)
Prince Rupert Grain Ltd.
900 - 1055 West Hastings St.
Vancouver, BC, Canada

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 92 16:49:40 GMT
From:      jbvb@vax.ftp.com (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: NDIS SLIP packet driver wanted for DOS

In article <1992Aug7.125305.18338@uis.com> andy@uis.com (Andy Edwards) writes:

    
    I am looking for a SLIP packet driver that follow the NDIS
    specs(?) to use on a 386 PC running DOS and FTP's PC/TCP package.

That's kind of a contradiction in terms.  NDIS doesn't really deal
with serial lines - the spec says if your media isn't 802.5 or Ethernet,
your vendor should have tried to simulate one or the other.  Packet
Drivers deal with serial lines, but not in a way that most LAN OSs
can cope with (serial lines are slow and don't do broadcast).  Our
"generic" PC/TCP comes with various serial drivers, some from the Crynwr
collection, and some we wrote (and support) ourselves.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 92 17:38:43 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: question about multiple routes to the same location

In article <1992Aug6.164440.7726@Arco.COM> Gary White <gwhite@arco.com> writes:
>
>Hi-
>What tricks would be involved in implementing a dual-path connection
>scheme to allow file transfers go over a satellite-hopped connection that
>is T1 speed but has the unavoidable 1/2 second round-trip delay time, and
>interactive sessions to use a terrestial 56KB link?  I can see how doing
>this wouldn't be too hard if there were just two hosts involved and each 
>has two Ethernet cards, but what if we have multiple machines in each
>location that would like to do this trick?
>
>Thanks!!
>-Gary White
>  ARCO
>  Plano, Texas
>
>
>               [s]
>              /  \
>             /    \
>            /      \
>           /        \T1 speed for FTP, etc.
>          /          \
>         /            \
>        /              \
>       /                \
>Texas  -----------------  Alaska
>            56KB
>						terrestial 
>						link for X-Windows,
>						telnet.

This is what IP Type-of-Service (TOS) routing is all about.  You need a
router with a routing protocol capable of calculating different routes
depending on the characteristics of the link.  OSPF was designed to
do this type of routing.  You also need hosts which can request the
appropriate TOS for the type of application protocol.  Unfortuneatly,
few routers and even fewer host implementations currently support TOS.

Art

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 92 18:45:31 GMT
From:      rex@pangea.Stanford.EDU (Rex Sanders)
To:        comp.protocols.tcp-ip
Subject:   SLIP for Ultrix/DECstation?

Is SLIP/CSLIP/PPP available for Ultrix running on DECstations?
Pointers to manuals, free software, commercial software, or other
newsgroups would be appreciated.

Thanks.

-- Rex Sanders
   rex@octopus.wr.usgs.gov

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Aug 1992 19:15:55 GMT
From:      rll1@kepler.unh.edu (Robert L Lamothe)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP codes

    I've been searching rfc's in order to find one that contains the codes
for the protocol portion of the IP header.  So far I haven't been able to
find a single rfc that contains all the possible codes that may appear in 
that area.  Does anyone know of one?  Please let me know.
						-Bob

-- 
*******************************************************************************
*                                                                             *
* Robert L. Lamothe                           University of New Hampshire     *
* rll1@kepler.unh.edu                         Interoperablity lab room 220    *
* rll@fizban.iol.unh.edu (preffered)          C/S Major                       *
*                                                                             *
*******************************************************************************


-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 92 19:21:45 GMT
From:      rhott@nswc.navy.mil (The VolleyDog - E41)
To:        comp.protocols.tcp-ip
Subject:   Changing the MTU or MSS

I think that this question has been asked before, but I was not able to
track it down in the archives.  I am looking for ways to reduce the size
of Ethernet packets from various systems.  The reason:  We happen to use
a Xerox Encryption Unit between several hosts, and the encryption overhead
extends large packets beyond the "maximum Ethernet packet size".  The XEUs
don't mind, but link devices, acting properly, drop them on the floor.

I would appreciate any help with respect to either reducing the MTU for
interfaces, or causing the hosts to negotiate a smaller MSS.

Thanks.

Bob Hott
-- 
====================== #include <std/disclaimer.h> =========================
Bob Hott, NSWCDD, Networks Branch (Code E41) |"If man were not meant to play
Dahlgren, Virginia  22448   (703) 663 - 4447 | volleyball, why are there so
rhott@relay.nswc.navy.mil                    | many beaches?"  - Bob Hott -

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Aug 92 20:52:03 GMT
From:      ddl@burrhus.harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip,comp.protocols.pcnet
Subject:   Re: Clemson University Packet Driver: I have one problem B-(.

In article <920803130216@cream.ftp.com>, jbvb@vax.ftp.com  (James B. VanBokkelen) writes:
|     
| The 'int-num'
| field returned by get_parameters() was intended to eliminate the problem,
| by allowing the stack to wait until the EOI.  PC/TCP uses it if offered
| by the driver, and our supported version of DIS_PKT offers it if the
| 'chain-vec' parameter is specified in PROTOCOL.INI.

	One thing to watch out for when using this feature of dis_pkt
(assuming the supported version works as the free one, i.e., calling
the interrupt at indication_complete time) is that some drivers (Interlan
comes to mind) invoke indication_complete before the EOI is generated.
If your protocol stack checks for pending interrupts (a good idea) then
it simply won't run on the tail of dis_pkt's chain-vec when used with,
e.g., ni5210.dos.  If it does not check, then you will see a higher-than-
expected send_pkt failure rate...
	There are other NDIS drivers (WD/SMC) that do defer the
indication_complete until after the EOI yet are still in an unstable
state at this time.  Watch out for sends that queue-up but don't get
onto the wire until after indication_complete returns.
	As of NDIS 2.? it is possible to determine the card's irq
from the info structures so dis_pkt could avoid the indication_complete
problems.

				Dan Lanciani
				ddl@harvard.*

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 92 21:00:35 GMT
From:      bytor@milton.u.washington.edu (Jill Patterson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP codes

rll1@kepler.unh.edu (Robert L Lamothe) writes:


>    I've been searching rfc's in order to find one that contains the codes
>for the protocol portion of the IP header.  So far I haven't been able to
>find a single rfc that contains all the possible codes that may appear in 
>that area.  Does anyone know of one?  Please let me know.
>						-Bob
  Hmm, If I remember correctly, it should be something like
  RFC791, RFC792, or somewhere around there.  Better yet get 
  Douglas Comer's Two Volume Books Internetworking With TCP/IP
  your school library should have them.

  bytor@milton.u.washington.edu

>-- 
>*******************************************************************************
>*                                                                             *
>* Robert L. Lamothe                           University of New Hampshire     *
>* rll1@kepler.unh.edu                         Interoperablity lab room 220    *
>* rll@fizban.iol.unh.edu (preffered)          C/S Major                       *
>*                                                                             *
>*******************************************************************************

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Aug 1992 21:42:19 GMT
From:      tran@peora.sdc.ccur.com (Nhan Tran)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   PC to talk to PostScript printer on Ethernet LAN


At our site we have multiple Unix workstations connected together by Ethernet 
We have a HP LaserJet IIIsi with PostScript cartridge. This HP is equipped with
an ethernet card so we can send output directly to it from each workstation.

We have a 386 PC and we want to use the HP PostScript printer on the Unix 
network. What we need is an ethernet card for the PC and some software to
transfer data from PC to HP printer. Even better is some software that made
the whole thing transparent to the user so, let's say, I would install 
Microsoft Word for PostScript and able to print directly from inside Word.

I am not sure that I need only an Ethernet card with software or I need to 
get a LAN hardware/software combo for PC in order to talk to the printer 
resided on Ethernet LAN.

I would appreciate if someone could give me some pointers in this matter.

N. Tran
tran@peora.sdc.ccur.com


-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Aug 1992 23:30:27 GMT
From:      keith@novell.COM (Keith Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: Need PC TCP/IP product to coexist with Novell

In article <14074@mindlink.bc.ca> Norbert_Papke@mindlink.bc.ca (Norbert Papke) writes:
>
>Check out the July 1992 issue of PC Magazine.  It contains an article called
>"TCP/IP Packages for Netware 3.11."  It reviews BW-NFS for DOS, ICE.TCP,
>PathWay Access, and PC/TCP Plus.
>

Indeed it does. Norbert fails to mention though that it was the Novell
LAN WorkPlace for DOS that received the editors choice award. I know because 
it was me that had to put up with the LAN WorkPlace folk swanning up and 
down the corridors thrusting reprints of that very article under my nose 
every opportunity they got! :-)

Keith
-
Keith Brown                                           Phone: 408-473-8308
Novell San Jose Development Center                      Fax: 408-473-8990
2180 Fortune Drive, San Jose, CA 95131                  Net: keith@novell.COM

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 Aug 1992 10:43:46 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: SLIP over a TELNET Link?

miller@tgv.com writes:
+---------------
| Currently we are working on IP-over-email using the MIME standard.
| Thank god for the slow-start algorithm.  The thing should be useable
| with batch FTP...
+---------------

Given the high-delay path, you probably will also need to implement
RFC 1323 "TCP Extensions for High Performance" (supercedes RFCs 1072 & 1185),
to extend TCP windows to 32 bits ("TCP Window Scale Option"). Once the
slow-start window opens, you should be able to get pretty good throughputs,
provided you never drop any mail. Your performance will probably be limited
by the size of your available retransmission buffers, but giving the delay,
it's probably o.k. to keep the retransmission queues on disk rather than
in kernel mbufs.

Using a 1.5 GB disk for retransmission queues, if your average round-trip
time is, say, 24 hours (several UUCP hops), you could get window-limited
rates of ~140 Kb/s for a single TCP connection. (Of course, I don't know
of many UUCP links that fast.)


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043


-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 92 13:57:34 GMT
From:      ea08+@andrew.cmu.edu (Eric A. Anderson)
To:        comp.protocols.tcp-ip,comp.lang.perl
Subject:   Re: ping + perl problem

Since I said I'd summarize, I will.  It turns out the problem wasn't
either ping or perl, it was an interaction problem.

As it turns out the problem was somewhat more magical than anyone
suspected.  A lot of people guessed at some problem with running out
of filedescriptors.  This was not correct.  The correct answer,
courtesy of William Lewis <wiml@u.washington.edu>  was that it was a
buffering problem.
My program started the pings, and read from them in order, and
wouldn't read from the next until an earlier one had finished.   This
caused the later pings to hang, trying to write output to my perl
process.  By doing some internal perl buffering by reading from each
of the filehandles as soon as they had some output, the problem went
away.
Thanks again William.
          -Eric 
*********************************************************
"Overhead, without any fuss, the stars were going out."
           -The Nine Billion Names of God
"Yes, you're very smart.  Shut up."
           -In "The Princess Bride"
*********************************************************

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 Aug 92 17:50:00 GMT
From:      jbharvey@nyx.cs.du.edu (Justin  Harvey)
To:        comp.protocols.tcp-ip
Subject:   Eff3ective TCP/IP


Greetings from Alaska,
 
I have just applied for 2 Internet addresses and should get a reply within
8 days.  I was wondering what the most effective way to get TCP/IP to a
486 in a town where there are no Internet sites.  (except a University
which does not give out SLIP connections, or anything else for that
matter)  I have heard about leased lines, a company called PSI, T1, ISDN,
Fiberoptics.  I'd like to know the cheapest way to get Internet into
Juneau, Alaska.
 
Thanks,
 
Justin Harvey
Juneau-Douglas Computing
jbharvey@nyx.cs.du.edu
 
 


-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 92 17:50:28 GMT
From:      hgschulz@cs.umass.edu (Henning Schulzrinne)
To:        comp.protocols.tcp-ip
Subject:   IP options/getsockopt

I can't seem to be able to retrieve IP options at the receiving end
using getsockopt(). tcpdump tells me that the options (SATNET, if it
matters) are indeed there, but getsockopt always returns zero length,
both on SunOS and Ultrix. Am I trying to do the impossible or missing
something? The code I use is below (executed after reading from the
socket):

  int opt_len;
  char opt[200];
  ...

  opt_len = sizeof(opt);
  if (getsockopt(s,IPPROTO_IP,IP_OPTIONS,opt,&opt_len) != 0) {
    printf("opt_len %d\n",opt_len);
    perror("getsockopt");
    exit(1);
  }

Hints are appreciated.
---
Henning Schulzrinne  (hgschulz@cs.umass.edu)  [MIME mail welcome]
Dept. of CS and Dept. of ECE; Univ. of Massachusetts at Amherst
Amherst, MA 01003 - USA === phone: +1 (413) 545-3179 (EST); FAX: (413) 545-1249

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 92 19:03:51 GMT
From:      jch+@cs.cmu.edu (Jonathan Hardwick)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin,comp.sys.sun.misc
Subject:   "zs0: silo overflow" (mostly) solved; slstats for 4.0.3, anyone?

My problem with regular
	zs0: silo overflow 
errors on a SLIP / Sun-3/50 / SunOS 4.0.3 setup was solved by
installing the patches in YAPT5.5c from the "slipware" package.  I had
originally ignored these since the SunOS SLIP documentation (written
pre-4.0.3) claimed that the patches were going to be a part of 4.0.3.
However, using filestamps (and the sound empirical rule that "the
newest object file is invariably the largest") I found that they
definitely weren't in *my* SunOS 4.0.3.  These patches have
subjectively reduced the frequency of silo overflows by 80-90%. 

Thanks go to Guy Harris, Tom Holodnik, and Howard Weiss for their
comments and advice on how to fix the silo overflows.

Incidentally, as I've just moved on to Van Jacobsen's "cslipbeta"
package, has anyone modified his SunOS 3.5 "slstats" program to run
under 4.0?  From the looks of things, when it goes into the kernel to
find the stats that the "slcompress" module is recording, it's
grovelling around in the wrong place, and I haven't got the experience
to know here it *should* be grovelling.  Are there any net-accessible
information sources that explain what changed between the 3.5 and 4.0
kernels, or (even better) has anyone already done the hard work and
rewritten slstats?

Jonathan H.

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 92 02:12:17 GMT
From:      mills@ccu.umanitoba.ca (Gary Mills)
To:        comp.protocols.tcp-ip
Subject:   SUMMARY: TCP from shell scripts

In comp.protocols.tcp-ip I wrote:

>I suspect that somebody has written Unix software to allow shell
>scripts to act as TCP clients and servers.  What I would like to
>do is call a command from a script that connects to and communicates
>with a server on another host, much like rsh can do.

Brad Turner <mbt@mkt.3com.com> said:

>Find the RFC that describes the TCPMUX service.

<gdmr@dcs.ed.ac.uk>, <barnett@alydar.crd.ge.com>,
    <george@gloria.pd-nap.compuserve.com>, <mah@parrot.prv.univie.ac.at>,
         <jboeske@namao.ucs.ualberta.ca> all said:

>PERL has this ability. Use it instead of shell.

Well, I almost succumbed to perl, but then I found socket-1.0, recently-
posted to alt.sources, and it looks like exactly what I wanted.
Thanks, everybody.
-- 
-Gary Mills-         -Networking Group-          -U of M Computer Services-

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Aug 1992 08:18:25 GMT
From:      rh0083b@medtronic.COM (Roger-Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP codes

>    I've been searching rfc's in order to find one that contains the codes
>for the protocol portion of the IP header.  So far I haven't been able to
>find a single rfc that contains all the possible codes that may appear in 
>that area.  Does anyone know of one?  Please let me know.
>						-Bob

Try RFC 1060 (assigned numbers).

Regards,
-Roger

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Aug 1992 09:06:00 GMT
From:      givme@ntc.togliatti.su (Gorev Andrew)
To:        comp.protocols.tcp-ip
Subject:   Help ! What is it (RFS <=> Remote File Sharing) ???


	Where I can find docs, sources (PD), RFCs for RFS ?
					Thanks.

P.S.	Addresses, docs, sources, pointers E-mail please.

-- 
@(#)GivMe (Gorev Andrew Alexandrovich)
	RUSSIA c.Togliatti, Dzershinskaja st., 63, 20
	Voice:  37-58-58(home), 378-17-53(work), 379-17-53(work)
	E-mail: givme@ntc.togliatti.su	   


-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Aug 92 10:45:24 MSZ
From:      CGANZ@ibm.gwdg.de (Christian Ganz)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP with PC/3270 and IBM-PCLAN ?

We have a IBM Token-Ring Network, the IBM-PC Lan Support Program Ver. 1.25,
the IBM DOS Lan-Requester 2.0 and the IBM PC-3270 Ver. 2.0 to connect a
IBM 9370.
These IBM-Stuff works fine.
But together with TCPIP we have a problem.
I installed the NCSA-TCPIP and the Clarkson packet driver for IBM-Token.
No problems | It runs together with Netbios-Applications, that means
it is possible to access file server.
The problem is:  The PC-3270 does not run.
 
Which configuration is needed to run PC-3270 *and* TCPIP at the same
time ?
 
Thank you
 
Christian Ganz
 
 
GANZ@DGOWISO1.Bitnet  I  Uni Goettingen, WiSo Rechenzentrum
CGANZ@ibm.gwdg.de     I  Platz der Goettinger Sieben 3, 3400 Goettingen
                      I  Germany

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 92 16:36:42 GMT
From:      hauser_s@eis.dofasco.ca
To:        comp.protocols.tcp-ip
Subject:   Non-byte boundary netmasks


I have recently seen some posts regarding non byte-boundary netmasks.
Unfortunately I only caught the last few posts.  We are planning to use a
netmask which has a non-byte boundary.  What problems have been observed with
such a situation? (besides the ROUTE problems recently mentioned)?


Steve Hauser
Hauser_S@eis.dofasco.ca

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 92 17:03:12 GMT
From:      eddjp@edi386.huber.com ( Dewey Paciaffi )
To:        comp.protocols.tcp-ip
Subject:   Prioritizing TCP/IP Traffic

We have several remote sites connected with 56K lines. The sites have PCs
or Workstations. Is there a way to prioritize the traffic such that a
single ftp cannot saturate a line, and impact interactive users that 
are logged in across that line?


-- 
Dewey Paciaffi      eddjp@huber.com

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Aug 1992 18:27:11 GMT
From:      scott@DSG.Tandem.COM (Scott Hazen Mueller)
To:        comp.protocols.tcp-ip
Subject:   T3000s and SLIP?


I appear to be having a problem with running SLIP over T3000s.  The symptom
is that the link will run fine for 2-3 days, and then just hang up hard.  I'm
actually running on a T1600 at one end, but a colleague was running with T3Ks
at both ends and encountered the same problem.

Does anyone know if this is a modem configuration issue?  If you are running
a SLIP link like this successfully, could you send me your at&v output so that
I can compare with mine?

Thanks,


-- 
Scott Hazen Mueller              +1 408 285 5762  scott@dsg.tandem.com
Tandem Computers, Unix System Administrator, Email Postmaster and Usenet Admin

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Aug 1992 18:47:31 GMT
From:      ckd@eff.org (Christopher Davis)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP codes

RH> == Roger-Hunen  <rh0083b@medtronic.COM> 

>    I've been searching rfc's in order to find one that contains the codes
>for the protocol portion of the IP header.

 RH> Try RFC 1060 (assigned numbers).

1060's finally been superseded.  The new Assigned Numbers RFC is RFC 1340.
--
Christopher Davis * ckd@eff.org * System Administrator, EFF * +1 617 864 0665
            ``Ed Gruberman, you fail to grasp Ti Kwan Leep.
            Approach me that you might see.'' -- The Master

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Aug 92 18:48:36 GMT
From:      jbharvey@nyx.cs.du.edu (Justin  Harvey)
To:        comp.protocols.tcp-ip
Subject:   SLIP services


I have checked with JvNCnet which provides national 800
number SLIP service, and I was wondering if there is anyone
else in the Internet world that provides access such as this.

Thanks,

Justin Harvey jbharvey@nyx.cs.du.edu



-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 92 18:52:12 GMT
From:      dsc3jfs@nmrdc1.nmrdc.nnmc.navy.mil (Jim Small)
To:        comp.protocols.tcp-ip
Subject:   profs / vm/ forwarding mail



I'm really not sure where to post this, but it is somewhat tcp/ip 
related.

We are about to retire about 200 vm profs mail accounts.  Before we do,
we are going to tell the users they may no longer use them and to
use the NEWER accounts instead.  But we will allow the accounts to
exist for about a month to give all the slow commands time to update
mailling lists.

What I need is a method on our KNET equiped VM system, is to be able to
forward the mail to another stmp hosts (If it makes it easier, the
id can be the same, but the address will be different)


say from
joeschmo@vmnmdsc.nmdsc.nnmc.navy.mil
joescho@mailman.med.navy.mil
-- 
I love the 3b2
The 3b2 is my friend.

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 92 19:29:45 GMT
From:      harvey@indyvax.iupui.edu
To:        comp.protocols.tcp-ip
Subject:   Re: HELP! TCP/IP packet driver needed for 3com 3c523b-tp card!

In article <1992Aug4.163255.10085@ariel.ec.usf.edu>, clark@daffy.tmc.edu (Matthew Clark) writes:
> Would any kind soul out there either have or know where I can find
> a driver set for a 3com 3c523b-tp ethernet card, so I can run tcp/ip
> protocol on it?

I use either the Crynwr 3C523 packet driver or the 3C523 ODI MLID with
ODIPKT for this card.  As far as I can tell, to the driver software this
card is identical to the AUI/thinwire version of the 3C523.

You can get the Crynwr packet driver collection at wuarchive.wustl.edu
(128.252.135.4) in the directory /mirrors/msdos/pktdrvr.  The files are
drivers.zip (binaries and docs only), or drivers1.zip and drivers2.zip
(includes with source) and drivers3.zip (update).  This is a mirror of the
distribution in pd1:<msdos.pktdrvr> at simtel20.army.mil (192.88.110.20).

Novell ODI drivers are available from ftp.novell.com (137.65.12.2) in the
file /sys/personal/guest/novlib/01/dosup5.zip.  ODIPKT is available from
hsdndev.harvard.edu (128.103.202.40) in the directory /pub/odipkt.

--
James Harvey    IUPUI OIT Technical Support/Networks
harvey@iupui.edu  uucp: iugate!harvey  bitnet: harvey@indyvax

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 92 19:34:34 GMT
From:      dsc3jfs@nmrdc1.nmrdc.nnmc.navy.mil (Jim Small)
To:        comp.protocols.tcp-ip
Subject:   IP changing/forwarding

We are losing our VM system (killing it actually), and would like to
be able to allow a window for stupid mailers to forward mail.  The 
account names will be the same on a NEW system.  Is there a simple
(more or less) way to redirect packets going to one IP, to another,


and of course, then is there a way to make the NEW machine 
accept the mail  given <userhere@OLDMACHINE.MIL> when the site name is
OLDMACHINE?

-- 
I love the 3b2
The 3b2 is my friend.

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Aug 92 21:21:51 GMT
From:      trier@slc6.INS.CWRU.Edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: IP changing/forwarding

In article <1992Aug10.193434.526@nmrdc1.nmrdc.nnmc.navy.mil> dsc3jfs@nmrdc1.nmrdc.nnmc.navy.mil (Jim Small) writes:
>Is there a simple (more or less) way to redirect packets going to one IP,
>to another,

CNAME records in the name server, or make the new system a multihomed
host.

>and of course, then is there a way to make the NEW machine 
>accept the mail  given <userhere@OLDMACHINE.MIL> when the site name is
>OLDMACHINE?

MX records in the name server.

-- 
Stephen Trier                    "I am not a lawyer, though I play one
Network Services Engineering      on the net."
CWRU IRIS/INS/TELECOM                Chris Torek, torek@horse.ee.lbl.gov
trier@ins.cwru.edu

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Aug 92 23:03:15 GMT
From:      reece@eco.twg.com (Reece R. Pollack)
To:        vmsnet.networks.tcp-ip.misc,comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs,comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: Transferring Multiple files using FTP


In article <1992Jul31.145537.6847@kodak.kodak.com>, adams@kodak.kodak.com (Robert E. Adams) writes:
|>I need some help resolving an FTP problem with PC/NFS
|>Version 3.5. I log into a VMS machine using PC/NFS FTP
|>from an IBM PC. The VMS machine is running Wollogong's
|>FTP software Version 5.1. I am trying to download multiple
|>files from the VMS machine over Ethernet to my PC using
|>"MGET". When I issue the "ftp mget *.*" command from the
|>appropriate directory on the VMS machine, I get the
|>following error message:
|>
|>	ftp: can't open local file : no such file or directory
|>
|>I believe what is happening is that ftp is trying to
|>expand the complete VMS file name literally including the
|>semi-colon and the VMS file version number. When it trys 
|>to convert it to a DOS file name, it chokes with the above
|>error message. Can anyone help me get around this problem.
|>Single file transfers using the following command work fine:
|>
|>	ftp> get vmsfilename dosfilename
|>
|>There are approximately 82 files I need to transfer on a weekly 
|>basis. Any help would greatly be appreciated. Thanks.

WIN/TCP 5.1 is out of date, and even folks around here are having a
bit of trouble remembering the FTP server's behavior. Depending on
which FTP server is running (5.1 had two of them), you may be getting
file names which include a semicolon. Whatever you see when you issue 
the 'ls' (or nlst) command to the server is what will be returned to
an 'mget' command.

This behavior was changed in WIN/TCP 5.2 so that the version number
is appended only if you explicitly specify a version number in the
'get' comand. I suggest you upgrade the VAX to WIN/TCP 5.2 or later
(the current release is 5.2.1.1), which should make your problem
go away.

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

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Aug 1992 23:13:09 GMT
From:      mlei@mona.jpl.nasa.gov (Mary Lei)
To:        comp.protocols.tcp-ip
Subject:   rpc and xdr examples

Can someone tell me how to get some examples of using remote procedure calls (rpc) and using External data representation protocol (XDR) ? or documentation
reference ? I am interested in using xdr streams.
Thanks. 
my mail is mlei@gina.jpl.nasa.gov.

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 92 23:48:36 GMT
From:      ben@datacomm.ucc.okstate.edu (Ben James)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   Novell routing TR to E-net


Ibm PS/2 with Lansup then IBMTOKEN.com then IPX and netx.
using CUTCP for telnet.

Mac with NCSA threw MacTCP and tokenring-extension.

I have gotton ftp threw the token-ring to work between a mac and a PC.
I have also been able to telnet to our NETBuilder TR bridges from both of them.

We have a class B network for ethernet. 139.78.0.0 
We have a class C network for Token-Ring. 192.198.4.0

We are using one of our Novell 3.11 servers to do the routing.

I have heard that Novell uses RIP to do routing.
RIP to my knowledge does not allow for different netmasks but I am defining the
gateway in my config.tel (CUTCP).  (Is this a problem.)
Is routing the same as passing?

As of now I can Telnet into the NETBuilders and ping them etc. from the ethernet and everything there works fine.

I can also Telnet into them on the Token-Ring side using CUTCP and IBMTOKEN.COM.

The problem..
When I try to telnet to the ethernet side from the TR side using CUTCP my arp 
requests never get answered.

When I look at the arp requests using Netcapt and Netview I see only a slight 
difference between them and the NetBuilders.      

On the outside of them the TR pc's hardware address is given as the source and
ff:ff:ff:ff:ff:ff (broadcast) is given as the destination. 
 The difference is the internal destination is given as ff:ff:ff:ff:ff:ff
where as the others (ethernet and Netbuilder) have 00:00:00:00:00:00 as theirs.
Does this matter.  In an rfc I read it defined as blank but I have not found any reference which allows for ff:ff:ff:ff:ff:ff .

An example,

My PC IP=192.198.4.13
Netware IP on TR side = 192.198.4.1
Netware IP on E-net side = 139.78.201.40
Trying to connect to 139.78.1.2

start CUTCP by issueing
telnet 139.78.1.2

first arp packet (internal)
source ??:??:??:??:??:??  IP 192.198.4.13
dest   ff:ff:ff:ff:ff:ff  IP 192.198.4.13

second arp packet (internal) 
source ??:??:??:??:??:??  IP 192.198.4.13
dest   ff:ff:ff:ff:ff:ff  IP 192.198.4.1

then it keeps doing the same as the second packet until it times out.

I checked on the ethernet side and I am getting the SAME EXACT thing there.

The Netware server's setup as best as I can recall is something like this.

packettype tokenring_snap on tokenring with IP forwarding and ARP forwarding.
IP number 192.198.4.1  netmask = 255.255.255.0

Ethernet II  
IP number 139.78.201.40
netmask 255.255.0.0

I am not the one who set up the server so I really can not say for sure.

One of the wierd things is that the arps shouldn't get threw from TR to ethernet as is.  There should be some changes.

I hope this isn't too boring but I have tried to include all the info. I know.

Any suggestions/comments welcome!
At this point I'll try anything to get it to work!

Thank you VERRY much for your time,
Ben James

**> Please email responces unless your unsure and want feedback from others.
    ben@datacomm.ucc.okstate.edu

P.S. I will be posting all of my info when it all works.

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 92 11:22:13 GMT
From:      dsc3jfs@nmrdc1.nmrdc.nnmc.navy.mil (Jim Small)
To:        comp.protocols.tcp-ip
Subject:   mail box machine

I've received several responses about how to properly 'forward mail' from
our VM system.  But of course, here come more requirements.


Mail sent to user@vmnmdsc.nmdsc.nnmc.navy.mil must be sent to
             user@bumed30.med.navy.mil  (diferent domain name)

PLUS, existing mail sent to bumed30.med.navy.mil must continue to be
recieved by the bumed30 site.

Unfortunately, the AT&T 3B2 manuals are, uh, how shall I say,
SHIT FOR DOCUMENTATION, and give basic descriptions of options of nameserver
entries, but no explanation of what they do.  So I'm in need of help in.


What do I need to do to (to the bumed30 site, and at the local nameserver,
and anywhere else), to make this work properly?

-- 
I love the 3b2
The 3b2 is my friend.

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 92 14:54:03 GMT
From:      tmd@s1.gov (Tina M. Darmohray)
To:        comp.protocols.tcp-ip
Subject:   ethernet performance


I'm looking for an article on ethernet performace.  I believe it
was written by Dave Boggs for the 1988 ACM SigComm.  Any pointers 
as to where I could get a copy, or pointers to any other papers on
ethernet measurement/performance would be greatly appreciated.  TIA,

	Tina
	tmd@s1.gov

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 92 15:26:30 GMT
From:      shirono@ssd.csd.harris.com (Roberto Shironoshita)
To:        comp.protocols.tcp-ip
Subject:   Re: IP changing/forwarding

In article <1992Aug10.212151.23333@usenet.ins.cwru.edu> trier@slc6.INS.CWRU.Edu (Stephen C. Trier) writes:

> >and of course, then is there a way to make the NEW machine 
> >accept the mail  given <userhere@OLDMACHINE.MIL> when the site name is
> >OLDMACHINE?
>
> MX records in the name server.

Of course, your SMTP server has to recognize OLDMACHINE.MIL as one of the
names it is known by.  Otherwise, it will reject the incoming messages with
"host unknown".
--

     Roberto Shironoshita      ||   Internet: shirono@ssd.csd.harris.com
      Harris Corporation       ||
   Computer Systems Division   ||   UUCP: ...!uunet!ssd.csd.harris.com!shirono
                               ||
DISCLAIMER: The opinions expressed here are my own; they in no way reflect the
            opinion or policies of Harris Corporation.

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 92 18:22:13 GMT
From:      scherf@maple.swdc.stratus.com (Steve Scherf)
To:        comp.protocols.tcp-ip
Subject:   Slip dialer

I have a fairly generic System V setup at home, and I want to connect to
one or two sites via slip. I got slip running between two ports on my machine,
but there is no program provided for dialing the phone. It's not too useful
to only connect to your own machine.

So, my question is, is there some sort of public domain slip dialer that
works with uugetty so I can use the port for uucp as well? I want to be able
to dial out using either uucp or slip, and I want anyone else to be able to
dial in and establish a uucp or slip connection.

--

Steve Scherf
scherf@swdc.stratus.com

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 92 19:00:29 GMT
From:      pruttman@cerebus.cc.edu (Pete Ruttman)
To:        comp.protocols.tcp-ip
Subject:   I Have SLIP-4.0 running on SUN need package to use it

Okay I managed to get the slip compiled for the sun and have rebuilt
the kernal.  I also managed to use sliplogin to use slip over
one serial port and into the other.  So I guess it is working fine.
Now my next job would be to take advantage of this.  What do I need
to make a mac, pc, amiga be able to use the slip that is working
now on that sun?  I would prefer pd solutions but any help would
be great?  If there is better slip for the sun tell me I am new at
this slip stuff.  Help me out.

Pete
pruttman@cerebus.cc.edu

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 92 21:54:34 GMT
From:      tmd@s1.gov (Tina M. Darmohray)
To:        comp.protocols.tcp-ip
Subject:   Re: ethernet perf. paper


Thanks to all who responded.  --TMD


From mogul@pa.dec.com Tue Aug 11 11:13:50 1992
From: mogul@pa.dec.com (Jeffrey Mogul)
Date: 11 Aug 1992 1113-PDT (Tuesday)
To: tmd@s1.gov (Tina M. Darmohray)
Subject: Re: online copy?
In-Reply-To: tmd@s1.gov (Tina M. Darmohray) / Tue, 11 Aug 92 11:10:49 PDT.             <9208111810.AA02618@random.s1.gov>

You may obtain a copy of a slightly revised version by sending mail
to "wrl-techreports@decwrl.dec.com" with "Subject: send postscript 88/4".

-Jeff

>From @bay.csri.toronto.edu:mart@csri.toronto.edu Tue Aug 11 09:08:11 1992
>From: Mart Molle <mart@csri.toronto.edu>
>To: tmd@s1.gov
>Newsgroups: comp.protocols.tcp-ip
>Date: 	Tue, 11 Aug 1992 12:07:45 -0400
>
>In comp.protocols.tcp-ip you write:
>
>>I'm looking for an article on ethernet performace.  I believe it
>>was written by Dave Boggs for the 1988 ACM SigComm.  Any pointers 
>>as to where I could get a copy,
>
>Tina,
>
>The full citation for the article you are looking for is:
>
>D.R. Boggs, J.C. Mogul and C.A. Kent, "Measured Capacity of an
>Ethernet:  Myths and Reality", Proc. ACM Sigcomm '88, Computer
>Communication Review, Vol 18, No. 4, August 1988, pp.222-234.
>ISBN 0-89791-279-9
>
>There is also a longer version, containing more figures, that is
>available as WRL Research Report 88/4 from
>
>Digitial Western Research Laboratory
>100 Hamilton Avenue
>Palo Alto, Ca 94301
>

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Aug 1992 02:42:35 GMT
From:      fillmore@emr1.emr.ca (Bob Fillmore 992-2832)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Multiple Subnets and Non-byte boundary netmasks

In article <ylee.712947488@florida> ylee@syl.dl.nec.com (Ying-Da Lee) writes:
>
>Well, not exactly a 'problem' though it could be a nuisance
>for setup and maintenance of your in-addr.arpa DNS database.
>
>I handle netwrok 143.101 among others.  With netmask of 255.255.255.0,
>when I allocate a subnet to a division I can also create a separate
>zone for it and add a line of NS for it in my 101.143.in-addr.arpa
>database.  The network/system administrator of the respective division
>can take care of what he does with that particular subnet without
>informing (a.k.a. bugging) me and all is harmony and happiness.  Had
>I used a non byte-aligned netmask, I would not have been able to have
>separate zones for the subnets and would have had to list all
>the individual hosts directly in the 101.143.in-addr.arpa database,
>which is something I do not relish.  Of course if your policy is to
>handle all the DNS in a centralized rather than a distributed fashion
>anyway, then this would not matter.

You have indeed touched on a problem with the in-addr.arpa kludge in the DNS.
If the DNS allowed a subnet mask to be applied during the reverse translation
(at the SOA for the IP net domain) then the problem would be simpler.

One way out of the problem is to disconnect (if possible) the process of
allocating blocks of IP addresses from the subnet structure.  We use a
20-bit subnet mask on our class B IP net, but we use the 3rd octet of the
address to allocate blocks of addresses to various organizations.
The 3rd octet is also used during reverse translation to select one of
a possible 254 name servers (in reality we have several reverse pointers
pointing to the same name server).  It's a compromise to keep the subnet
size large to minimise the number of routers required, and still allow
some flexibility in IP address allocation.

-- 
Bob Fillmore, Technical Services Division          email: fillmore@emr.ca
  Information Management Branch,                   BIX:   bfillmore      
  Energy, Mines, & Resources Canada                Voice: (613) 992-2832
  580 Booth St., Ottawa, Ontario, Canada  K1A 0E4  FAX:   (613) 996-2953    

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 92 09:44:48 GMT
From:      dave@tetra.co.uk (David Sussman)
To:        comp.protocols.tcp-ip
Subject:   telnet and DNS


I have a query regarding the telnet protocol and Domain Name Servers.

The problem:

Our setup is a smallish ethernet (aprox. 20 hosts), with an NCS server
plus several terminal servers to handle the large number of dumb terminals.
One of the hosts is used as a DNS.  When attempting to connect from a 
terminal server to selected machines (using the telnet protocol, I believe)
we did not get a response.  These selected machines all appeared to have one
thing in common - they used the DNS.  The host acting as the DNS seemed ok,
except we could not get out to these machines.  Rebooting this host cleared
the problem.

The question:

When connecting via the telnet protocol does the host attempt to find out
where you are?  Many machines say 'last logged in from .....' giving the
host name that you last connected from.  Could it be that the Name Server
is being queried for this?

Or am I barking up the wrong tree?

Many thanks for any ideas.

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Aug 1992 17:23:13 GMT
From:      ghawkins@unix1.tcd.ie (George C. Hawkins)
To:        comp.protocols.tcp-ip
Subject:   why did development of CSLIP stall in early '90


Hi there,

Maybe I'm missing something but I've been trying to get CSLIP, and
I've found cslip.tar.Z which just contains the README:

> Wed Feb 28 22:56:19 PST 1990
> 
> The official release of the compressed slip code described in
> RFC 1144 is awaiting a Unix PPP driver.  If you want to play
> with a beta version of the code, binary ftp file cslipbeta.tar.Z
> from ftp.ee.lbl.gov (128.3.254.68).  This file contains all the
> code from the RFC and a BSD Unix SLIP (RFC 1055) driver.
> 
> The compression code in cslipbeta.tar (slcompress.[ch]) is the
> code documented in the RFC and the code that will go into
> cslip.tar.Z.  The only changes I expect between now and the time
> cslipbeta.tar gets renamed cslip.tar is the addition of an
> if_ppp.c (BSD Unix PPP driver) and some improvement to the
> (currently pathetic) installation instructions.
> 
> The official release should happen by the end of March, '90.
> I'll announce it on the ietf and tcp-ip mailing lists and the
> comp.protocols.tcp-ip usenet newsgroup.
> 
>  - Van Jacobson

Did this release never happen? Is if_ppp.c an essential ingredient
(I'm using a Sun IPC running SunOS 4.1 and the connection I'm
running SLIP over is a fixed very clean serial line running at 9600
bps if that's relevant)? All I can find on ftp.ee.lbl.gov is
cslipbeta.tar. From what Van say the expected March '90 release
shouldn't have been too much different from this, but reading the
cslipbeta README file:

> Berkeley, CA,  Sun Dec 31 08:54:07 PST 1989
> 
> This directory contains some experimental SLIP code that does
> tcp/ip header compression & TOS queuing.  This is a beta test
> version for hard-core network kernel hackers.  You don't want to
> play with this code unless you're (a) comfortable hacking the
> kernel and (b) familiar with your system's TCP/IP implementation.

suggests that CSLIP is not for people like me (i.e. I don't wish
to hack the code). So what's the situation, is CSLIP for me (or
anyone else for that matter). The server that supplies me my SLIP
service says it can deal with CSLIP so it would be nice to take
advantage of it if I could on my 9600 bps line.

Thanks for your time, yours,


George!
--
george lives at:
___________________________________________________________________________
|   ghawkins@unix1.tcd.ie (mostly)  |   ghawkins@vax1.tcd.ie (sometimes)  |
---------------------------------------------------------------------------

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 92 18:41:30 GMT
From:      jclark@sdcc3.ucsd.edu (John Clark)
To:        comp.protocols.tcp-ip
Subject:   Re: Stopping only incoming TCP connections (was: Firewall usage)

In article <1992Jul31.001141.2305@maccs.dcss.mcmaster.ca> beame@maccs.dcss.mcmaster.ca (Carl Beame) writes:
+
+	A properly configured Firewall Router can allow access from the
+local net onto the Internet and even allow Internet access to specific
+services or servers on the local net. For Example: If you want to provide 

Having only recently been interrested in this type of feature, does
any one have list of hardware which supports 'Firewall' building.

In a somewhat related topic, what does one do about the password
protection problem for accesses other than anonymous FTP. I saw some
mention of a 'encrypter' which appeared to repacket IP datagrams
with the data portion encrypted. Is there hardware that does this or
did I really misunderstand the post.


-- 

John Clark
jclark@ucsd.edu

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Aug 1992 19:08:20 GMT
From:      nectar@world.std.com (Jacques A Vidrine)
To:        comp.programming,comp.protocols.tcp-ip
Subject:   TCP/IP programming on AS/400

My IBM Sales Rep tells me that the only language supported for programming
using TCP/IP Connectivity Utilities/400 is Pascal.  The TCP/IP Connectivity
Utilities/400 manuals seem to agree with this.

I would like to know if TCP/IP programming can be done with the C/400 compiler
before I am forced to buy the Pascal/400 compiler.  Seems to me that many
implementations of C support Pascal calling conventions.  Anyone have any
idea on this with regards to the AS/400?

Thanks in advance!
-- 
Jacques A. Vidrine 		|	What did the Zen Buddhist	
nectar@world.std.com		|	say to the hot dog vendor?
				|	"Make me one with everything."
Request my PGP public key	|

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 92 19:19:38 GMT
From:      mcmath@csb1.nlm.nih.gov (Chuck McMath)
To:        comp.protocols.tcp-ip
Subject:   Help! with Telnet Connection Programming

Help me puhleeze!

I am programming a simple Telnet connection in an existing program.  I have
read the RFC and (kinda) understand it.  My connection is pretty much
batch-oriented; that is, the user specifies a bunch of stuff at the
beginning, then starts up the connection, which transfers a bunch of data
back and forth, and then disconnects.  Currently this is done using a modem
only, and I am adding tcp/ip access.

Ok, now for the question.  I have a simple little program that does
synchronous reads and writes on the Telnet port.  It looks for and handles
all of the option sequences (mostly by telling the other end it WONT do
whatever it asks).  This program works fine when I connect to a local Sun
machine.  But when I try to connect to the target machine, it hangs.  Here
is what happens:

	1. target machine sends IAC DO TERMINAL-TYPE
 2. my program sends IAC WILL TERMINAL-TYPE

	and here I do a read, and it just sits there until it times out.

I have tried doing 2 reads in succession, but there is only that 3 byte
sequence on the line.

I have spied on this machine using another telnet program, and in the other
program here is what happens:

	1. target machine sends IAC DO TERMINAL-TYPE
	2. this program answers IAC WILL TERMINAL-TYPE
 3. target machine sends IAC SB TERMINAL-TYPE SEND IAC SE
	
	and they go on their merry way.


Anybody want to take a stab at what's wrong?  Do I need to do asynchronous
reads?  That's all I can figure.  Or am I supremely stupid somewhere? 
Thanks for any help.

chuck


|- chuck mcmath - mcmath@csb1.nlm.nih.gov - MSD, Inc. ------------|
|- National Library of Medicine - National Institutes of Health --|
|- Bethesda, MD 20894 -  !aixelsyd evah uoy siht daer nac uoy fI -|
|- "Hey batter, hey batter, hey batter, swing" - Anon. -----------|

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Aug 1992 19:34:48 GMT
From:      ett@sparky.carleton.ca (E. Todd Taylor)
To:        comp.protocols.tcp-ip,comp.unix.admin,comp.unix.wizards,comp.windows.x,comp.windows.x.apps
Subject:   xterm, function keys and informix app problems

We presently have informix (v2.10.03B) based applications running 
on 386's with Interactive Unix (5.3.2) which were originally 
accessed by RS-232 based vt100 compatible terminals (with 
"termcap" def'ns).

We have replaced the dumb terminals with X-terminals (HDS FX-15's) 
and are now trying to drive the apps using "xterm".  Since the apps
are function key and escape key driven (ie. onkey() and interrupt),
we seem to be having intermittent problems now that we're on a 
tcp/ip based network.

The problem is that the apps don't seem to be able to consistently
distiguish between the escape sequences and the escape key itself,
which is causing incredible grief and misery.

Is it a timing problem due to net load?  How about the stty 
settings informix sets when running an app? Is it simply a change 
to the termcap definition? Or, do we have to re-write the way we 
drive our apps (read: we do not want to do this :-{ )

Let me know what you guys think.  Every bit of feedback is very
deeply appreciated. Oh, don't post if possible (note the cross
postings) but mail me directly at the address below with your 
responses.

Cheers...Todd

--
ett@sparky.carleton.ca          Carleton University
(613) 788-2600 x8557             Ottawa, ON Canada

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Aug 1992 21:49:23 GMT
From:      karl@thuja.gsfc.nasa.gov (Karl A. Anderson)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   What terminal server should I buy?

I need to buy a terminal or communications server to meet the following 
requirements:

- Ethernet interface with choice of thin- or thick-ethernet
  connections;
- Minimum of 16 dial-in ports, with ability to add more;
- Dial-in speeds of up to 38.4 Kbps;
- Minimum of 1 MB RAM, expandable;
- Security features (ID/password at least, maybe logging too)
- Support for LAT, SLIP/cSLIP/PPP, DNS, SNMP

3Com, Cisco, Telebit and Xylogics (Annex) all appear to offer products 
that meet the minimum requirements.  Are there any other vendors?  Does 
anybody have any recommendations (comp.dcom.sys.cisco readers are 
allowed to recommend Cisco :^}) or caveats, either specific or general?  
Please respond by email, as I don't ordinarily take these groups.  TIA.
-- 
Karl A. Anderson		| Internet: karl@thuja.gsfc.nasa.gov
NASA/GSFC code 920.2 (HSTX)	| voice: (301) 286-3815
Greenbelt, MD 20771		| #include "std_disclaimer"

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Aug 92 23:27:13 GMT
From:      chinson@chin.cs.ucla.edu (Chinson Yi)
To:        comp.protocols.tcp-ip
Subject:   tcpdump for IBM/RT


We are looking for tcpdump (or something similar) which can run on
IBM/RT(4.3BSD UNIX).   If you know of such things, please e-mail me.

Thanks in advance.
--
   /\~ /\      O\_  "I think my golf ball landed around here."
 ~/\/\/  \~  +--\\\                          
~~ ~~~~~ ~~  |  /|@       
/      \   \ !  \ \  Chinson Yi (chinson@cs.ucla.edu 310-206-3584)

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Aug 1992 23:52:07 GMT
From:      nduong@rhea.trl.OZ.AU (Nguyen Duong - Integrated Communication Services)
To:        comp.protocols.tcp-ip
Subject:   How to drive a Crynwr packet driver?

I've down loaded the Crynwr packet driver collection but have no idea
how to drive it. Can somebody post or email some clue? Surely there must
be some document somewhere that specifies the services of a packet
driver (under DOS)? For realtime reason I've have to drive the packet driver
directly from my program. BTW, can I use the same driver under OS/2? If
not how do I go about using a packet driver (or such like) under OS/2?

Thanks very much for any help you could give.
nduong@trl.oz.AU
Telecom Australia Research Laboratories.

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Aug 1992 02:31:31 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Stopping only incoming TCP connections (was: Firewall usage)

jclark@sdcc3.ucsd.edu (John Clark) writes:

>Having only recently been interrested in this type of feature, does
>any one have list of hardware which supports 'Firewall' building.

	We use (not surprisingly) DEC hardware to build host-based
screening routers. See Mogul's paper on the packet screen, for more
details. My gateway here (decuac.dec.com) is built of a DECsystem2100,
a MicroVAXII with a pair of ethernet interfaces, and another
DECsystem2100 internally running IP and DECnet.

mjr.

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Aug 1992 04:35:02 GMT
From:      Quentin.Smart@bbs.actrix.gen.nz
To:        comp.sys.novell,bit.listserv.novell,comp.protocols.tcp-ip
Subject:   Charon 2.0a hanging on large print jobs - HELP

I have CHARON 2.0a setup on our LAN receiving print jobs to a 3.11 file
server from a remote VAX running multinet.

If the print job exceeds about 150k charon seems to lock up once it has
received approx 150k of the file. I have checked that no disk quotas exist
for the charon account. 

Has anyone had this problem before? Any ideas at a solution?

Are there any PD LPD NLM's available yet? (Or ones that don't cost an arm
and a leg!!)

Thanks
Quentin.



-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 92 13:28:07 GMT
From:      ak902@cleveland.Freenet.Edu (Scott Goette)
To:        comp.protocols.tcp-ip
Subject:   Telnet Drivers


I am trying to write a telnet terminal driver for a benchmark of a unix 
application. I am curious if anyone else out there has developed such a driver
. Here's the layout of my hardware : one unix box connected to the benchmarked
machine via tcp/ip ethernet. I wish to initiate a number of telnet sessions
from one of the boxes to the other and fire off the application executable
on the benchmarked machine. I don't need to worry about screen i/o on the 
benchmarked box because the screen interface software used for the application
has a method of reading its' input from a file.
Any suggestions, thoughts, etc... would be greatly appreciated. Sample code
included would not be distributed anywhre else (up to your disgression).

Curious
-- 
---------------------------------------------------------------------
Scott Goette                 |    Email : ak902@cleveland.freenet.edu
---------------------------------------------------------------------
  Life is shortened by engaging in mental battles with the unarmed

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Aug 1992 15:06:25 GMT
From:      carrollj@wm-mercer.ca (Jim Carroll)
To:        comp.protocols.tcp-ip
Subject:   Re: profs / vm/ forwarding mail

In article <1992Aug10.185212.15@nmrdc1.nmrdc.nnmc.navy.mil> dsc3jfs@nmrdc1.nmrdc.nnmc.navy.mil (Jim Small) writes:
>What I need is a method on our KNET equiped VM system, is to be able to
>forward the mail to another stmp hosts (If it makes it easier, the
>id can be the same, but the address will be different)

No problem:

1. First, become an expert in sendmail.	:-)
2. Second, rewrite all sendmail.cf files for all systems through
which said mail passes.  Give them the intelligence to read a flat
file to know where to forward a given user's mail.

It's all there.  All you have to do is tweak it.

I suppose one loose alternative (you'll have to test it, of course)
is to add aliases on all systems, pointing out the proper hosts for
the given mail in question.

I prefer the former method, as it makes life much easier for those
users on multiple hosts who only want to read one mailbox.

-- 
Jim Carroll - carrollj@wm-mercer.ca
-{ Standard Disclaimer in effect .... }-
"Ich weiss nicht, was soll das mir bedeuten."

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Aug 92 15:10:16 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   How to drive a Crynwr packet driver?

In article <1992Aug12.235207.17783@trl.oz.au> nduong@rhea.trl.OZ.AU writes:

   I've down loaded the Crynwr packet driver collection but have no idea
   how to drive it. Can somebody post or email some clue? Surely there must
   be some document somewhere that specifies the services of a packet
   driver (under DOS)?

Sure, it's in the collection as PACKET_D.109.

   For realtime reason I've have to drive the packet driver
   directly from my program. BTW, can I use the same driver under OS/2? If
   not how do I go about using a packet driver (or such like) under OS/2?

The packet drivers calling convention (software interrupt) is
incompatible with OS/2.  Use NDIS drivers there...

-russ <nelson@crynwr.com>  I'm proud to be a humble Quaker!
Crynwr Software            Crynwr Software sells packet driver support.
11 Grant St.               315-268-1925 Voice
Potsdam, NY 13676          315-268-9201 FAX

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 92 15:29:13 GMT
From:      mgic@mixcom.mixcom.com (mgic)
To:        comp.unix.aix,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Wanted: X.25-Ethernet or X.25-Token Ring gateway OR SLIP driver


I am looking for one of the following:

	SLIP driver for RS/6000 AIX (other than IBM's)

	X.25-Ethernet gateway that supports SLIP

	X.25-Token Ring gateway that supports SLIP


I want a product that actually works without crashing
the computer and is available today. Who's selling?

Dean Roth
(414) 347-4805
-- 

MGIC Investment Corp.
270 E. Kilbourn
Milwaukee, WI 53202

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Aug 1992 19:38:32 GMT
From:      mahmood@lambda.msfc.nasa.gov (Rafique Mahmood)
To:        comp.unix.ultrix,comp.sys.sgi,comp.protocols.tcp-ip
Subject:   TLI (transport layer interface), can it replace SOCKET?

 I did a posting on yesterday about X/Open portability guide. This is
a followup posting on that. I am thinking to use TLI (transport layer
Interface) which uses t_open, t_connect etc. instead of socket.

I am doing research on 'Does POSIX support the X/Open Portability
guide'?

My main concern is VMS POSIX. How can I write the networking code
which will run on all UNIX/ULTRIX/POSIX?

If anyone has any experience/knowledge on this subject, please
let me know via email.


Thanks in advance,

Rafique J. Mahmood
email - mahmood@lambda.msfc.nasa.gov
phone - 205-544-6475


-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Aug 92 19:52:08 GMT
From:      macauley@bnr.ca (John MacAuley)
To:        comp.protocols.tcp-ip
Subject:   Maximum udp message size.


I need to know the maximum allowable size of user data
in a udp message.  The sendto man page on my hp specifies
a maximum value of 9216 bytes for hp series 300 and 800.

I can't seem to find the same information for Sun3, and
Sun4 Sparc.  Does anyone know the maximum value?  How
about on other platforms?

Besides sending packets of increasing size until sento
returns EMSGSIZE, is there any way to find this information
in header files?  I will need to find a common maximum for
a number of platforms and would like to save time searching
for the values.

Thank you in advance,

John.

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 92 20:32:57 GMT
From:      THOMASG@epx.cis.umn.edu (ThomasD.Gasser)
To:        comp.protocols.tcp-ip
Subject:   POP Server on IBM-PC

Hello all,

I have heard that it is possible to run a PC as a POP server maybe using 
KA9Q.  I would like to use an old IBM PC connected to ethernet and a Novell 
3.11 server.  

Any ideas?



*********************************************************************
*  Thomas D. Gasser                                                 *
*  Department of Neurosurgery                *******     ******     *
*  University of Minnesota                    ***  *** *** ***      *
*  (612) 624-4427                             ***   *****  ***      *
*  E-Mail:  THOMASG@EPX.CIS.UMN.EDU          *****        *****     *
*                                                                   *
*********************************************************************

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 92 22:05:11 GMT
From:      dennis@longs.LANCE.ColoState.Edu (Dennis Miyoshi)
To:        comp.protocols.tcp-ip
Subject:   Telnet error

Hello,

We are having a slight problem with our tcp-ip system.  We are
useing FTP softwares version of tcp-ip and also AT&T's version
of enhanced win386 tcp-ip.  Recently we have experienced the following
problem:

During a successful telnet connect, a unix application program is
executed. This program runs for a time.  However, at various times
during the telnet session the line is dropped and the following
message is received on the AT&T enhanced win386 tcp-ip side.

	"telnet: can't ipop".

Could someone please tell me why this message pops up and how to
fix the problem?

Thanks in advance.

Dennis

--
===============================================================================
ARPA Internet:  dennis@longs.lance.colostate.edu
UUCP         :  ...ncar!boulder!ccncsu!longs.lance.colostate.edu!dennis
========================= ( ROBUST == A Broken Robot ) ========================

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Aug 1992 22:12:04 GMT
From:      M21816@MBVM.Mitre.Org (Paul Campbell)
To:        comp.protocols.appletalk,comp.protocols.ibm,comp.protocols.tcp-ip,comp.periphs.printers,comp.sys.novell
Subject:   lpr/lpd printing

hi all,
 
i have ARCHIEd and GOPHERed around and cannot find any documents on
general printing.  i have been in search of documents that discuss
experiences sites have had working through the myriad of printer
access possibilities.
 
in the last few years IBM mainframe computers have finally come to
grips with the LPD/LPR considerations and have equipped us with the
potential for connecting to other hosts/servers for print purposes.
in light of the new capabilities we would like to explore the
possibility of re-engineering our current printer scheme.  my main
concern at this point is with the appletalk entities and how
connectivity could be best addressed.
 
ideally, i would like to find CAP like capabilities for both VM and
MVS but i haven't heard of any successes in this area.  I would
appreciate hearing from anyone who has had experience comparing any
of the following as printer servers: Sun running TOPS, VAX running
AlisaShare, whatever running CAP and Novell.  issues like capacities,
performance, reliability and functions would be important
considerations.
 
many thanks
 
/pc
 
-------------
Paul Campbell
m21816@mbvm.mitre.org
Bedford, MA

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Aug 1992 08:34:07 GMT
From:      dansmith@olsen.ch (Dan Smith)
To:        comp.protocols.tcp-ip
Subject:   OSPF commercial or public implementations.

I am looking for public or commercial implementations of OSPF,
described in RFC 1131.  You may respond on the net, or via mail.

Thanks.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Smith

Olsen and Associates, Seefeldstrasse 233, CH-8008 Zurich, Switzerland
Ph. +41 1 386 48 48  (from US, 011-411-386-48-48)  Fax +41 1 422 22 82
Email:  dansmith@olsen.ch   uunet!chx400!olsen!dansmith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Aug 1992 12:02:45 GMT
From:      rune@regina.itek.norut.no (Rune Hamnvik (Stud IT))
To:        comp.protocols.tcp-ip
Subject:   Raw IP

Hello
We are using Berkeley sockets and we wish for some reason to use
raw sockets, but we have a problem. We can not send packets greater
than about 1500 - 2000 bytes. Why is that ?
Does the protocol spesify this or is it only the implementation that
has this limitation ? 
I have read that IP can do fragmentation and that the maximum
size of an IP datagram is 65536 bytes. Is this true ?

Can someone please help us ?

Rune Hamnvik

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Aug 1992 12:07:41 GMT
From:      isc30248@nusunix3.nus.sg (LEE BOON PENG)
To:        comp.protocols.tcp-ip
Subject:   SHILPA Distributed Computing Enviroment


The SHILPA Distributed Computing Environment 
--------------------------------------------

This is a source distribution of SHILPA version 1.0. SHILPA is a distributed
communication architecture developed at the National University of Singapore,
Department of Information Systems and Computer Science. It provides a set
of different communication mechansims for distributed computing.

This distribution contains source for both SunOS (SunOS 4.0 and above) & IBMPC
environment. Please read README.PC for details of PC source and dependants. 
Moreover, SHILPA Intra-machine Message Passing (or RPC call) uses System V 
Shared Memory in SunOS. As such, the shared memory must be configured in SunOS 
kernel. Note that this portion of code (Intra-machine call) is not stable. 
We welcome any reports of bugs. However, no promise is given that the bugs 
would be fixed. We also welcome any suggestions for bug fixes. Please send 
any bug reports, fixes, comments, suggestions, etc to:

		<shilpa@iscs.nus.sg>
	
The entire source package can be obtained through anonymous ftp from 
nuscc.nus.sg (137.132.5.2) at the National University of Singapore. Please
retrieve: shilpa_sun.tar.Z for the SUNOS version or shil_ibm.zip, the PC
version. They can be found under /pub/SHILPA. Please note that the PC 
version only implements the client-side of the package.

About the SHILPA Project
------------------------
 
The SHILPA Distributed Computing Environment  research program was initiated as
a joint collaboration between the  Department of Information Systems and
Computer Science and the High Performance Computing Applications group of ITI
in June 1990. The objectives of the research are:
 
    1.To develop a communication architectural reference model for distributed
      computing within a heterogeneous environment.
 
    2.To design and develop a set of comprehensive communication mechanisms to
      support general distributed computing across heterogeneous hardwares
      and operating systems.
 
    3.To develop various classes of services within each communication mechanism
         for different distributed applications.
 
    4.To  develop distributed applications using  the communication mechanisms
      available within SHILPA.
 
The aim of this project is to address these issues within the scope of the
hardware/software heterogeneity available within the department. Much of
the distributed systems software research has been experimental work in which
actual systems are built, and this project is no exception to that.
 
About  SHILPA
-------------

	SHILPA is layered communication architecture.

	There are many communication mechanisms available for distributed 
computing. However, one single communication mechanism cannot cater to all 
kinds of applications. For example, low-level message-passing mechanism is 
well suited for bulk data transfer, while remote procedure calls (RPC) are 
mainly used in request-response type of client-server applications.  

	Moreover, an architecture to provide an integrated, comprehensive 
and coherent view of useful communication mechanisms is not available.  
Instead, many of the existing distributed systems only define a distributed 
system architecture, and provide only one communication mechanism for 
distributed computing.  On the other hand, although the OSI model defined by 
ISO can be used as a communication architecture for distributed computing, 
it is not specially designed for that purpose; instead its main objective 
has been to provide a general reference model for interconnecting 
heterogeneous computer systems. SHILPA provides a layered communication 
architecture that incorporates several useful communication mechanisms.
 
SHILPA provides a rich set of communication mechanisms to the application
programmer .  This is to facilitate the building of diverse distributed
applications since no single communication mechanism is able to meet all
application requirements. The communication mechanisms defined include an
asynchronous remote procedure call mechanism (ASTRA), a Type-safe
Message-Passing mechanism (TMP), a Sun eXternal Data Representation (XDR) layer,
   a Byte-stream oriented Message-Passing mechanism (BMP), and a Reliable
Datagram Transport Protocol (SRDTP).  Each of these communication mechanisms
forms part of a layered architecture with consistent interfaces between them.
 
About ASTRA
-----------
The top layer is the RPC layer.  RPC is a useful mechanism for distributed
computing.  However, existing RPCs fail to exploit the parallelism inherent
in a distributed application.  This is because the client blocks while waiting
for the server to complete execution.  To remedy this shortcoming, we have
developed a new asynchronous RPC - ASTRA.  ASTRA calls do not block the client,
   thus allowing the client execution to proceed in parallel with the server
invocation.  The result is buffered at the client side when it is returned
by the server, and the client can claim the results later.  ASTRA also allows
a client to specify explicitly whether a call is to be optimized for
low-latency or high throughput.  Moreover, ASTRA optimizes any intra-machine
RPC calls by bypassing expensive network and data conversion operations.
ASTRA is fully compatible with SUN RPC; ASTRA clients can call SUN RPC servers
and vice versa. It provides a general purpose and familiar paradigm for
developing high performance distributed applications.
 
Availability
------------
The entire SHILPA architecture is portable. SHILPA is currently available on
Unix workstations such as the SUN 3, SPARCs, and the AT&T  3B4000. A simplified
version to support client applications development is available on MS DOS
platforms, and a similar version will be developed for the MAC platforms by
the first quarter of next year.
 
SRDTP is currently implemented as a separate daemon process. It will be
incorporated as part of the kernel by implementing it on top of System V
Streams. SRDTP will also be enhanced to include compression, and will be
extended to support audio, video, and graphics transport.
 
Several applications including distributed make, alphabeta serach,  raytracing
algorithm and  volume rendering and visualization applications have been
developed or in the process of development.
 
We have also designed and implemented a test tool for distributed applications
development; it is built on ASTRA. The test tool allows a programmer to
independently verify client or server application behavior. It greatly
simplifies distributed applications development.
 
Acknowledgement
---------------
This research & development is supported by a grant from NUS DISCS.
 
For  Further Information
------------------------
For more information on SHILPA, ASTRA, SRDTP or the distributed test tool,
please contact the SHILPA group at shilpa@iscs.nus.sg


-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Aug 1992 14:19:01 GMT
From:      koelman@cuby.stc.nl (Ton Koelman)
To:        comp.protocols.tcp-ip
Subject:   Retix 7000 Routers, need opinions


Hi,

We're considering to buy a pair of Retix Routers
(ROUTERXchange 7000) for IP and OSI over
Ethernet, X.25, ISDN and FDDI.

Opinions please. Are these boxes any good? cost effective?
Support?

thanks.

--
Ton Koelman   e-mail: koelman@stc.nato.int (NeXT Mail Welcome!)
SHAPE Technical Centre, P.O. Box 174, 2501 CD  The Hague
The Netherlands  (voice: 31-70-3142429, fax: 31-70-3142111)

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Aug 1992 14:31:57 GMT
From:      russ@meaddata.com (Russ Rahn)
To:        comp.protocols.tcp-ip
Subject:   Request for Help on TCP problem


I have been witnessing from time to time, a series of events that I
feel is improper.  I am asking for help from you gurus on the net so
that I can determine (1) if there is a problem, and (2) who has the
problem.  The following is a description of what I see:

We have a protocol converter that takes frames from an X.25 cloud and
converts them to TCP-IP packets and sends them to our PC.  It does the
opposite with TCP-IP frames generated by our PC.

Let's pick up the action with everything running fine.  Our PC is all
caught up and has just acked with an ack value (for the sake of this
discussion) of 0, and gave a windowsize of 512.  The converter sends
a packet to our PC with seq# 0.  For one reason or another, this frame
is missed by the PC.  The converter sends the next frame with seq#
128.  This is what I would have expected.  The PC responds with an ack
message with ack = 0.  Again this is what I would have expected, but
this is the point where reality begins to deviate from my
expectations.

The converter then sends a packet with seq# 256.  The PC acks 0.  The
converter sends the packet seq# 384 with a length of 128.  This fills
our window.  The PC acks 0.  Since our window is full, the converter
listens to the PC this time and retransmits the packet with seq# 0.  The
PC gets it and acks 128.  Our window is no longer full, since it has
just slid over 128 bytes.  The converter then sends a packet with seq#
512.  The PC is forced to ack at 128.  The window is full again, so
the converter listens and resends packet seq# 128.  The window slides
and this pattern continues.

I thought that I had read that if you receive an ack for less than you
had already sent, then you should forget all that was sent after the
ack point and retransmit from that point on.  If you don't receive an
ack, then you should continue sending more and more new packets until
you either fill the given window (flow control) or you eventually get
an ack telling you what to do.

Is this right?  Or should the PC have been saving all of the frames
that were provided after the ack value it gave (those that filled the
window) so that when the converter got around to retransmitting the
missed packet (seq# 0), the PC could have then acked the whole window?

You can see how the current action is putting a delay in our
processing while the window gets filled, and then slows processing
after that by requiring so many packets to deliver just one.

Please E-Mail with any response as I don't get to read the News very
often.  Also, if you would like to help, but I haven't made my
question clear enough, please drop me a line and I'll try to describe
the situation better.

Thanks in advance!

Russ
  
russ@meaddata.com



-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 92 14:50:30 GMT
From:      todd@uvmark.uucp (Todd Cooper)
To:        comp.protocols.tcp-ip,comp.sys.encore
Subject:   How do you measure how much work a machine is doing routing?

We have an Encore running System V with two ethernet ports which we want to 
use as a router.  Is there a way with sar or another program to determine 
how much work the machine is doing in routing packets?

This machine is our heaviest loaded machine and we don't want to cause it
to become overloaded with forwarding packets.

Thanks for the answer, if anyone else it interested send email and I will
post the replies.
-- 
+++++ Just leaving a boring signature. ++++++++++++++++++++++++++++++
Todd Cooper         (uvmark%todd@merk.com uunet!merk.com!uvmark!todd)
Snail Mail: Vmark Software, 30 Speen Street, Framingham, MA 01701 USA

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 92 15:46:02 GMT
From:      gsa@easyaspi.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: Raw IP

In article <1992Aug14.120245.8688@news.uit.no>, rune@regina.itek.norut.no (Rune Hamnvik (Stud IT)) writes:
|> Hello
|> We are using Berkeley sockets and we wish for some reason to use
|> raw sockets, but we have a problem. We can not send packets greater
|> than about 1500 - 2000 bytes. Why is that ?
|> Does the protocol spesify this or is it only the implementation that
|> has this limitation ? 
|> I have read that IP can do fragmentation and that the maximum
|> size of an IP datagram is 65536 bytes. Is this true ?
|> 
|> Can someone please help us ?
|> 
|> Rune Hamnvik

Here are two possible reasons:

1)	The socket send and/or receive buffers are not large enough.
	A nominal value used in BSD code is 2048 bytes.  You can use
	the getsockopt to check the sizes and the setsockopt to
	change the sizes.

2)	You are going between network solutions and the don't fragment
	option is set (e.g. when going from FDDI to Ethernet).  Unless
	you have control over the IP headers you may be SOL (NOTE - if
	you're lucky you might be able to configure the FDDI MTU size).

My guess is that issue "1" is the problem, however, one is always 
humbled by new findings.

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 92 17:35:36 GMT
From:      sap@crosfield.co.uk (stelios pavlides)
To:        comp.protocols.tcp-ip
Subject:   Re: Use of ARP with non-IP protocols

In article <1992Aug7.133126.12636@webo.dg.com> dad@mozart.webo.dg.com writes:
>In article <15058@suns6.crosfield.co.uk>, sap@crosfield.co.uk (stelios pavlides) writes:
/|> 
/|> Assume there is a non-IP protocol, say XX, which nevertheless uses IP-style
/|> addresses and relies on ARP for address resolution (this conveniently
/|> exists for real in the name of XTP). What one should use in the ar$pro
/|> field of the ARP packet, the IP protocol type (a) or the XX protocol type
/|> (b)?
/|> 
/|> The case for (a) is that XX, although different to IP, should declare the
/|> IP address space that it uses. That is, ar$pro refers to the address space
/|> and not to the protocol itself.
/|> 
/|> The case for (b) is that one should have separate ARP tables on a per
/|> protocol basis, even if two protocols use the same address space.
/|> 
/
/From RFC 826 (An Ethernet Address Resolution Protocol --or--
/Converting Network Protocol Addresses to 48.bit Ethernet Address
/for Transmission on Ethernet Hardware):
/
/    16.bit: (ar$pro) Protocol address space.  For Ethernet
/                     hardware, this is from the set of type
/                     fields ether_typ$<protocol>. 
/
/Ethertype fields are 0x0800 for IP and 0x817D for XTP.

But that was precisely the nature of my question. Note that in your
citation above 'protocol ADDRESS SPACE' is first mentioned, not just
'protocol' (possibly an indication of the author's intention?). I
appreciate, of course, that the second sentence follows; but RFC 826 is
dated Nov 1982, at which point there was probably one-to-one correspondence
between 'protocol' and 'protocol address space'. This is no longer true
today.

-- 
Stelios Pavlides			Phone  :  +44 442 230000 ext 3468
Crosfield Electronics Ltd		Fax    :  +44 442 232301
Hemel Hempstead, Herts. HP2 7RH, UK	E-mail :  sap@crosfield.co.uk 
-----------------------------------------------------------------------------

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 92 17:47:46 GMT
From:      ercm20@festival.ed.ac.uk (Sam Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: ethernet perf. paper

tmd@s1.gov (Tina M. Darmohray) writes:
> 
> From: mogul@pa.dec.com (Jeffrey Mogul)
> 
> You may obtain a copy of a slightly revised version by sending mail
> to "wrl-techreports@decwrl.dec.com" with "Subject: send postscript 88/4".
> 
> -Jeff

This is the paper with the wonderful quote:

	Ethernets are not only "distributed packet switches" but
	"distributed single points of failure". 

which I used to have stuck to my door until I moved office - think I'll
put it back... 


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

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 92 20:11:29 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.sys.encore
Subject:   Re: How do you measure how much work a machine is doing routing?

In article <1992Aug14.145030.5609@uvmark.uucp>, todd@uvmark.uucp (Todd Cooper) writes:
> We have an Encore running System V with two ethernet ports which we want to 
> use as a router.  Is there a way with sar or another program to determine 
> how much work the machine is doing in routing packets?
> 
> This machine is our heaviest loaded machine and we don't want to cause it
> to become overloaded with forwarding packets.


A quick and dirty technique I've seen used effectively is to take any
CPU benchmark (the simpler the better, so Drhystone is fine), and run
the benchmark with various simultaneous forwarding loads.  The
variations in what the bencmark reports can be attributed to the
forwarding load.  After calibrating the benchmark to the local machine,
you can have the forwarding load expressed in units of fractions of a
machine.


Vernon Schryver,  vjs@sgi.com

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 92 21:45:18 GMT
From:      jtw@lcs.mit.edu (John Wroclawski)
To:        comp.protocols.tcp-ip
Subject:   Re: Use of ARP with non-IP protocols


In article <15148@suns3.crosfield.co.uk> sap@crosfield.co.uk (stelios pavlides) writes:

   /    16.bit: (ar$pro) Protocol address space.  For Ethernet
   /                     hardware, this is from the set of type
   /                     fields ether_typ$<protocol>. 
   /
   /Ethertype fields are 0x0800 for IP and 0x817D for XTP.

   But that was precisely the nature of my question. Note that in your
   citation above 'protocol ADDRESS SPACE' is first mentioned, not just
   'protocol' (possibly an indication of the author's intention?). I
   appreciate, of course, that the second sentence follows; but RFC 826 is
   dated Nov 1982, at which point there was probably one-to-one correspondence
   between 'protocol' and 'protocol address space'. This is no longer true
   today.

If you use the protocol ID, you can deduce the address format, because
the protocol defines the format in use.

If you use some other ID which identifies the "address space", you
can't deduce what protocol you are talking about, and so, in the worst
case, can't even decide whether to process the request or not.

John Wroclawski
jtw@lcs.mit.edu

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 92 03:21:17 GMT
From:      bloomer@rodson.crd.ge.com (John Bloomer)
To:        comp.protocols.tcp-ip
Subject:   getting RFCs

Is there an approved way to obtain the latest copies of RFCs?
I used archie to find scores of places that have some RFCs
on hand, but is there an approved archive site or surface-mailing
procedure?

-- 
John J. Bloomer 518-387-6964 (dialcomm 833) FAX -7332
KWC317, General Electric Corporate Research and Development
PO Box 8, Schenectady NY 12301

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Sun, 16 Aug 1992 02:50:09 GMT
From:      rmh@cbnewsm.cb.att.com (robert.m.holden)
To:        comp.protocols.tcp-ip
Subject:   Seeking advice using KA9Q over SLIP

I'm new at this and simply want to network a PC to UNIX over a modem.
The quality of the NOS documentation caught my attention and I started
experimenting.  Two days down the drain, and I can't get it to work.
Anyone help?  Is may approach reasonable?  Are all SLIPs compatible?

Configuration:
	UNIX:	A Motorola 1167 running R3V7.0 UNIX with the SLIP
		provided by their NSE package.

	PC:	386 PC with the hardware configured in NOS by:
			attach asy 0x3f8 4 slip sl0 1024 576 9600

I debugged with a direct line between the PC and 1167.  A "ping" from
PC to UNIX and nothing happens.   A "ping" from UNIX to the PC causes the
following repetitive messages on the PC:
	sl0 recv:
	serial line IP: len 26
	IP: bad header

	sl0 recv:
	serial line VJ compressed TCP: len 8
	changes: 0x9e  TCP checksum 0x7ef8 PUSH
	delta window: 0x7e delta ack: 0x60 delta seq: 0xe increment id

	sl0 recv:
	serial line VJ compress TCP: len 117
	changes 0x80 TCP checksum: 0x0066
	increment id

An ipstat on the PC:
	ipInReceives: 10	ipInHdrErrors: 10 ...

ifstat on the PC:
	... link encap SLIP
	flags 0 netmask 0 broadcast 0.0.0.0
	sent ip 0 tot 0
	recv ip 19 tot 19

asystat on the PC:
	sl0: [trigger 0xc0] 9600 bps
	RX: 468 int, 486 chr, 0 hw over, 1 hw hi, 0 sw over, 103 sw hi
	TX: 0 int, 0 chr 0 q 0MS int 0 THRE TO

Thanks in advance!
Bob Holden
...!att!lcuxlm!rmh

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 92 16:18:32 GMT
From:      dan@cedb.dpcsys.org (Dan Busarow)
To:        comp.protocols.tcp-ip
Subject:   NDIS drivers (was Re: How to drive a Crynwr packet driver?)

In article <713718616snx@crynwr.com>, nelson@crynwr.com (Russell Nelson) writes:
> The packet drivers calling convention (software interrupt) is
> incompatible with OS/2.  Use NDIS drivers there...

While on the subject of NDIS, can anyone point me to a source for
documentaion on setting up an NDIS driver?  The 'obvious' changes
to protocol.ini did not work for me.

TIA

Dan
-- 
+                                                                            -
   Dan Busarow             dan@cedb.dpcsys.org              uunet!cedb!dan
   DPC SYSTEMS                Monrovia, CA                  (818) 305-5733
-                                                                            +

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Aug 1992 01:07:10 GMT
From:      kd1hz@anomaly.sbs.risc.net (Michael P. Deignan (KD1HZ))
To:        comp.protocols.tcp-ip
Subject:   Re: Seeking advice using KA9Q over SLIP

rmh@cbnewsm.cb.att.com (robert.m.holden) writes:

>Are all SLIPs compatible?

Yup. This message is being routed from a UNIX machine over a KA9Q SLIP-driven 
line onto the Internet.

>	sl0 recv:
>	serial line IP: len 26
>	IP: bad header
 
>	sl0 recv:
>	serial line VJ compressed TCP: len 8
>	changes: 0x9e  TCP checksum 0x7ef8 PUSH
>	delta window: 0x7e delta ack: 0x60 delta seq: 0xe increment id

This usually indicates one of several things (in decreasing order of 
liklihood):

 1. Your serial port is not configured for 9600 baud (did you execute a MODE
    statement?)

 2. The serial connection was not established at 9600bps (can you lock the
    serial-port speed?)


Basically KA9Q is receiving garbage, and is attempting to decode it (resulting
in KA9Q thinking that it is VJ-compressed SLIP being used.)


MD
-- 
--  Michael P. Deignan                      / Sex is hereditary. If your 
--  Domain: kd1hz@anomaly.sbs.risc.net     /  parents never had it, chances 
--    UUCP: ...!uunet!anomaly!mpd         /   are you won't either...
-- Telebit: +1 401 455 0347              /

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Aug 1992 07:17:55 GMT
From:      rh0083b@medtronic.COM (Roger-Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: getting RFCs

In article <1992Aug15.032117.10906@crd.ge.com> bloomer@rodson.crd.ge.com (John Bloomer) writes:
>Is there an approved way to obtain the latest copies of RFCs?
>I used archie to find scores of places that have some RFCs
>on hand, but is there an approved archive site or surface-mailing
>procedure?

Send mail to 'service@nic.ddn.mil' with the subject line reading 'RFC 1032'
to obtain RFC 1032, etc.

Alternatively FTP to 'nic.ddn.mil' directory 'rfc'.

NIC.DDN.MIL is the official site for RFCs.

Regards,
-Roger


-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 92 12:30:39
From:      jraja@vipunen.hut.fi (Jarno Tapio Rajahalme)
To:        comp.protocols.tcp-ip
Subject:   Re: getting RFCs

In article <1992Aug15.032117.10906@crd.ge.com> bloomer@rodson.crd.ge.com (John Bloomer) writes:


   Is there an approved way to obtain the latest copies of RFCs?
   I used archie to find scores of places that have some RFCs
   on hand, but is there an approved archive site or surface-mailing
   procedure?

nic.ddn.mil carries the rfc's (anonymous ftp). By the way, rfc's are 
allways 'latest copyes', since once rfc is published it is never
changed afterwards.

Hope this helps,

	Jarno

   -- 
   John J. Bloomer 518-387-6964 (dialcomm 833) FAX -7332
   KWC317, General Electric Corporate Research and Development
   PO Box 8, Schenectady NY 12301

-- 
-----------------------------------------------------------------------------
| Address: Jarno Rajahalme            | EMail:                              |
|          Servin Maijan tie 12 H 111 |   Jarno.Rajahalme@hut.fi            |
|          02150  ESPOO, FINLAND      | tel: +358 0 468 2891                |
-----------------------------------------------------------------------------



-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1992 00:08:04 -0700
From:      tli@skat.usc.edu (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: TFTP Broadcasts

In article <1992Aug18.050759.6934@microplex.com> fff@microplex.com (Fred Fierling) writes:
    In RFC 906 (Bootstrap loading using TFTP) it is written:
    
       [**]  Editor's Note:  While there is no standard for an Internet wide
            broadcast or multicast address, it is strongly recommended that
            the "all ones" local part of the Internet address be used to
            indicate a broadcast in a particular network.  That is, in class...
    
    How pervasive is this type of broadcasting?  Anyone care to hazard a guess
    as to what percentage of systems support it?  Are there any big time vendors
    that do NOT support it?

If it helps, "all ones" broadcasts are the default on cisco routers.
I would estimate that 95% of our customers use the default broadcast
address. 

Tony
-- 
Tony Li - Escapee from the USC Computer Science Department          tli@usc.edu
		       The net is not what it seems.

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Aug 92 15:22:46 GMT
From:      berg@physik.tu-muenchen.de (Stephen R. van den Berg)
To:        comp.protocols.tcp-ip
Subject:   Extending IP-numbers

I heard some rumors about several proposals being already on the table
concerning extending the current 4-byte IP-addresses.

Could anyone knowledgeable disclose some specifics about these proposals?
(Or some pointers on where to look for more info?)

Thanks.
-- 
Sincerely,                                  berg@pool.informatik.rwth-aachen.de
           Stephen R. van den Berg (AKA BuGless).    berg@physik.tu-muenchen.de

"Be spontaneous!"

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1992 18:21:46 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: getting RFCs

In article <JRAJA.92Aug17123039@vipunen.hut.fi> jraja@vipunen.hut.fi (Jarno Tapio Rajahalme) writes:
>nic.ddn.mil carries the rfc's (anonymous ftp). By the way, rfc's are 
>allways 'latest copyes', since once rfc is published it is never
>changed afterwards.

This is mostly true.  However, the rfc-index.txt file is updated
frequently; if you have an old version of this, you might be directed to
read an old version of an RFC (for instance, unless you have a recent
rfc-index.txt you'll think that "Assigned Numbers" is RFC 1060, not RFC
1340).

Also, the documents in the FYI series are updated with the same numbers.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1992 21:10:56 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Extending IP-numbers

In article <1992Aug17.152246.29952@Urmel.Informatik.RWTH-Aachen.DE> berg@physik.tu-muenchen.de (Stephen R. van den Berg) writes:
>I heard some rumors about several proposals being already on the table
>concerning extending the current 4-byte IP-addresses.
>
>Could anyone knowledgeable disclose some specifics about these proposals?
>(Or some pointers on where to look for more info?)

Try RFC 1347, "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal
for Internet Addressing and Routing".  I don't think it's the only such
proposal, but it's apparently the only one that's made it to the RFC stage.

A related RFC is 1338, "Supernetting: An Address Assignment and Aggregation
Strategy".  It doesn't extend the 4-byte address space, but does suggest
some ways to live with it a bit longer (e.g. treating contiguous ranges of
class C addresses as a single network, to allow for networks too big for
class C but not needing an entire class B, and to reduce the size of
routing tables in the core gateways).

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 92 21:19:31 GMT
From:      booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
To:        comp.protocols.tcp-ip
Subject:   Why is UDP slower than TCP when running ttcp over FDDI?

Greetings,

We have recently connected a Cray X/MP running Unicos 6.1 to our FDDI ring.  I
have been running some load tests using ttcp and have observed a rather odd
behaviour, and I was hoping I might elicit comment from someone out there.

When sending to a Sun 4 connected to the ring using TCP, the Cray sends at
roughly 32 Mbits/sec.  But when I send using UDP, the best I can do is
somewhere around 10 Mbits/sec.  We connect to the ring using an NSC N130
adapter.  We also have a HYPERchannel connection, and it behaves a little more
as I would expect.  Namely, a TCP send runs around 8 Mbits/sec and a UDP send
runs a little better than 20 Mbits/sec (these rates are achieved using the
same parameters to ttcp as in the FDDI test).

Does anyone have any idea as to why UDP would run slower than TCP over the FDDI
interface?  I have run xnetmon during these tests and found that the dropped
packet count is non-zero whenever I'm running the UDP tests (regardless of
interface used), although I still don't know where these drops occur (my
assumption is in the communication with the IOS).  I have no reason to 
believe this has anything to do with the slower UDP rate, but it is
interesting to find the sender tossing stuff on the ground.

Any information will be greatly appreciated.  Thanks in advance.

best regards,
mb
--
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948
-- 
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 92 01:07:04 GMT
From:      hofer@rchland.vnet.ibm.com (Kent Hofer)
To:        comp.protocols.tcp-ip
Subject:   ioctl() questions


Could anyone please answer the following questions for me:

ioctl() networking commands are grouped into 4 categories in the Steven's book: 
  - file
  - socket
  - routine
  - interface

FILE CATEGORY:

1) what address family must be used?
  - file - I assume this can relate to any address family.  Are all supported
      for AF_UNIX and AF_INET?
 
2) what socket type must be used? I assume that it makes no difference, correct?
 
SOCKET CATEGORY:

1) SIOCATMARK isn't supported for AF_UNIX, right?  Otherwise process group options should be universal, right?

2) Again, socket type makes no difference, right?

3) What are high water marks and low water marks, and why are they here if they are not implemented?  How do they relate to the socket options SO_RCVLOWAT and SO_SNDLOWAT?  Was the SIOCSLOWAT supposed to set both the send and receive side low water marks (whatever they are) or was it intended for just one side?  


ROUTING CATEGORY:

1) Are there more protocol stacks than AF_INET that use these ioctls()?

2) What socket_type is required to use these?  (Rephrased - can I add a TCP
route using a stream socket, a datagram socket, and/or a raw socket?)

INTERFACE CATEGORY:

1) Same questions - what address family and type are required for this? 


Thanks for any answers to any of the questions!!!
  

Kent Hofer    hofer@rchland.vnet.ibm.com  

(my opinions are my own and have nothing to do with my employer)

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Aug 1992 05:07:59 GMT
From:      fff@microplex.com (Fred Fierling)
To:        comp.protocols.tcp-ip
Subject:   TFTP Broadcasts

In RFC 906 (Bootstrap loading using TFTP) it is written:

   [**]  Editor's Note:  While there is no standard for an Internet wide
        broadcast or multicast address, it is strongly recommended that
        the "all ones" local part of the Internet address be used to
        indicate a broadcast in a particular network.  That is, in class...

How pervasive is this type of broadcasting?  Anyone care to hazard a guess
as to what percentage of systems support it?  Are there any big time vendors
that do NOT support it?
-- 
Fred Fierling    fff@microplex.com       Tel: 604 875-1461   Fax: 604 875-9029
Microplex Systems Ltd   265 East 1st Avenue   Vancouver, BC   V5T 1A7,  Canada

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Aug 92 14:03:02 GMT
From:      macauley@bnr.ca (John MacAuley)
To:        comp.protocols.tcp-ip
Subject:   UDP packet headers.


If I have a maximum limit of 8192 bytes for a UDP packet,
how big can the user data be?  Does the UDP header need
to be included in this maxsize?

Questions, questions, questions,

John MacAuley.

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Aug 1992 15:08:30 GMT
From:      dboyes@is.rice.edu (David E Boyes)
To:        comp.protocols.tcp-ip
Subject:   Re: profs / vm/ forwarding mail

In article <BsxGMq.M34@wm-mercer.ca> carrollj@wm-mercer.ca (Jim Carroll) writes:
>In article <1992Aug10.185212.15@nmrdc1.nmrdc.nnmc.navy.mil> dsc3jfs@nmrdc1.nmrdc.nnmc.navy.mil (Jim Small) writes:
>>What I need is a method on our KNET equiped VM system, is to be able to
>>forward the mail to another stmp hosts (If it makes it easier, the
>>id can be the same, but the address will be different)
 
>1. First, become an expert in sendmail.	:-)

It's not nearly that complicated. Assuming that KNET has some
kind of feature similar to the MAILER keyword in IBM's SMTP
implementation, all you need to do is install a recent version of
the Columbia/Princeton VM MAILER code (available on the most
recent VM Workshop tapes or from LISTSERV@PUCC.PRINCETON.EDU),
and configure KNET to send all incoming mail through the MAILER
DVM. 

The MAILER record in the IBM SMTP implementation tells the SMTP
machine to send all incoming messages to the identified virtual
machine for final delivery. MAILER gets them, looks up the
userid, and then if forwarding is necessary, regenerates the
BSMTP header and reprocesses it -- presto, remote delivery.

There is no charge for the Columbia/Princeton MAILER code, and I
strongly recommend it to any VM sites.

>I suppose one loose alternative (you'll have to test it, of course)
>is to add aliases on all systems, pointing out the proper hosts for
>the given mail in question.


This is rather unwieldy, given large numbers of users and hosts.
The other method is user-controllable.

>Jim Carroll - carrollj@wm-mercer.ca


-- 
David Boyes
dboyes@rice.edu

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 92 15:49:30 GMT
From:      laum@csri.toronto.edu (Marc Lau)
To:        comp.protocols.tcp-ip
Subject:   need help on a SLIP message

Hello all,

I am currently running a SLIP link across a regular telephone line.
The link is fairly dependable except once in a while a message saying

"?recvd an ESCAPE followed by <some hex number> with ilen=<some number>"

would pop up.  Most of the time things would get back to normal afterwards
but there are occasions where similar messages would keep appearing and the
link will be totally bogged down.  I am wondering if what this message
means.  Does this indicate a noisy phone line or is it related to some
known bugs?

Other than this, I was told that turning on the UDP checksum would be a good
idea when a SLIP link is run over a regular phone line without an 
error correcting modem.  Do you think this might help fix the above
problem?

Please e-mail your reponse.

Thanks very much.

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Aug 1992 15:55:38 GMT
From:      ckd@eff.org (Christopher Davis)
To:        comp.protocols.tcp-ip
Subject:   Re: TFTP Broadcasts

Fred> == Fred Fierling <fff@microplex.com> 

 Fred> How pervasive is [all 1s] broadcasting?  Anyone care to hazard a
 Fred> guess as to what percentage of systems support it?  Are there any
 Fred> big time vendors that do NOT support it?

SunOS defaults to using net.0 as the broadcast address (although I
believe SunOS 5, aka Solaris 2.0, does finally get this right).

It allows you to change it, but it's annoying.
--
Christopher Davis * ckd@eff.org * System Administrator, EFF * +1 617 864 0665
            ``Ed Gruberman, you fail to grasp Ti Kwan Leep.
            Approach me that you might see.'' -- The Master

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Aug 1992 16:25:11 GMT
From:      lah@unh.edu (Lance A. Hartford)
To:        comp.protocols.tcp-ip
Subject:   Telnet option codes


	Is there a way to get a list of all telnet option codes, without
searching through the RFC's? Thanks

															-- Lance
--
________________________________________________________________________
| Lance A. Hartford             | Computer Science Junior              |
| UNH InterOperability Lab      | Internet: lah@unh.edu                |
| University of New Hampshire   | 32 Coe Drive, Durham NH 03824        |
|----------------------------------------------------------------------|
|                         This space for rent !!!                      |
------------------------------------------------------------------------


-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Aug 1992 17:11:50 GMT
From:      rhm@oclc.org (Robin Hermance-Moore)
To:        comp.protocols.tcp-ip
Subject:   Multiple End Systems Via One IP Address?

Can anyone point me to a commercially-available solution to this
problem?

We are designing an application which will run on multiple Unix
systems & be accessible via TCP/IP.  We would like to make these
systems available to users on the Internet using a single IP
address.  Since the "application systems" all run pretty much
independently of each other, we envision something like this:

Internet
    |
[ Front ]
[ End   ]
    |
 ---------------------------------
    |           |           |
[ Appl  ]   [ Appl  ]   [ Appl  ] ...
[ Host  ]   [ Host  ]   [ Host  ]
[ # 1   ]   [ # 2   ]   [ # 3   ]

The Front End system would listen for connections on a given
port using sockets (say it's the Telnet port), accept them,
open a new connection to the same port on whichever Appl Host
was the least loaded at the same port (connecting to the
real Telnet server when it gets there) and then pass data
back and forth between the Telnet client out in the Internet
and the Telnet servers on the Appl Hosts.

This would be a relatively easy piece of code to write, but
I am concerned about the performance of the Front End system
(i.e., I don't want it to become a bottleneck).

Does anyone know of an off-the-shelf system we could use in the
place of the Front End?  I was hoping for something, perhaps from
one of the router vendors, that would be designed and fine-tuned
for this purpose & thus support a high number of simultaneous
connections.

Any pointers you can give would be greatly appreciated.

Thanks, Robin Hermance-Moore (rhm@oclc.org)

--
Robin Hermance-Moore                                  Section Manager
Mail Stop 468                                Open Systems Development
OCLC Online Computer Library Center                      rhm@oclc.org
6565 Frantz Road, Dublin OH  43017                       614-764-6215

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 92 18:26:38 GMT
From:      bwill@athena.mit.edu (Brian F Williams)
To:        comp.protocols.tcp-ip
Subject:   TCP window size


	It appears that the sun implementation of tcp uses a default
window size of 4K.  Is there a standard way of changing the window
size (a socket option?) or, if not, where can I change this value
on a sun Sparcstation?  Thanks.

--Brian
--
internet: bwill@athena.mit.edu
uucp    : mit-eddie!mit-athena!bwill
bitnet  : bwill@athena.mit.edu

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Aug 1992 18:46:47 GMT
From:      hyl@microplex.com (Henry Lee)
To:        comp.protocols.tcp-ip
Subject:   Van Jacobson Specification for TCP

Can anyone suggest a good book or resource that outlines 
Van Jacobson's specification for data transmission in TCP.

Please send responses to my email address; I will post a summary 
later.

Thanks in advance.
--
Henry Lee              Microplex Systems Ltd      Tel: 604 875-1461
hyl@microplex.com      265 East 1st Avenue        Fax: 604 875-9029
Software Engineer      Vancouver, BC  V5T 1A7,  Canada

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 92 20:48:49 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet option codes

In article <LAH.92Aug18112511@genesis.unh.edu> lah@unh.edu (Lance A. Hartford) writes:
>	Is there a way to get a list of all telnet option codes, without
>searching through the RFC's? Thanks

The usual answer to "how do I get a list of...." questions is to look in
the Assigned Numbers RFC.  And indeed, it's the correct answer in this
case.  The latest Assigned Numbers is RFC 1340, I believe.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 92 21:34:48 GMT
From:      heberlei@cs.ucdavis.edu (Louis Todd Heberlei)
To:        comp.protocols.tcp-ip
Subject:   finding a host's ethernet address

I am sorry if this in not quite the right news group,
or if this question is in a FAQ, but...

Is there a general system call to find the ethernet
address(es) of a host?  For example, if I am working
on a Sun, can I easily determine the ethernet address
(le0 => lance ethernet??) from within C code?

Thanks,

Todd Heberlein

heberlei@cs.ucdavis.edu

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Aug 1992 22:41:01 GMT
From:      dsiebert@icaen.uiowa.edu (Doug Siebert)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Questions regarding OOB data and telnet/rlogin

I have several questions I'm hoping I can find out the answers to between the
two groups I've posted this to.  For question 3 the machine in question is an
HP 9000/710 running HP-UX 8.07, if that matters.

1)  For what functions does telnet rely on OOB data? (i.e. what would happen if
    OOB data was "lost" into /dev/null -- both sides of the connection could
    send it but wouldn't ever know it never made it to the other side)

2)  Same question for rlogin.

3)  Can a send(2) call attempting to write OOB data be blocked, or does the
    call always complete immediately since it uses a different logical channel
    and blocking tends to defeat the purpose of OOB data in the first place?

If anyone can answer one or more of these questions, please mail -- if others
indicate interest in the answers I'll summarize the responses I get.  Thanks!

-- 
/-----------------------------------------------------------------------------\
| Doug Siebert                             | "I don't have to take this abuse |
| Internet:  dsiebert@icaen.uiowa.edu      |  from you - I've got hundreds of |
| NeXTMail:  dsiebert@chop.isca.uiowa.edu  |  people waiting in line to abuse |
|     ICBM:  41d 39m 55s N, 91d 30m 43s W  |  me!"  Bill Murray, Ghostbusters |
\-----------------------------------------------------------------------------/
Hi, I'm a .signature worm.  I've already copied myself into your .signature.

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 92 22:43:46 GMT
From:      realliso@unity.ncsu.edu (Robert Allison)
To:        comp.protocols.tcp-ip
Subject:   ftp from AS/400 to RS/6000 (filename problem)

I have loaded a tape from the census bureau onto an
AS/400 and need to ftp it over to my RS/6000.

I seem to be having trouble with the file-name that
I am specifying (ok, not just 'seem' -- I definitely
*am* having trouble with my file name:)

Can anyone help me get the secret formula right?

Below, I have cut-n-pasted some of my ftp session
so you might be able to tell where I am going wrong.
The files are on the AS/400, and I'm starting the
ftp session on the RS/6000.

Thanks!
Robert Allison (realliso@unity.ncsu.edu)

$ ftp cimas400
Connected to cimas400.tx.ncsu.edu.
220-QTCP at CIMAS400.TX.NCSU.EDU.
220 Connection will close if idle more than 5 minutes.
Name (cimas400:realliso): 
331 Enter password.
Password:
230 REALLISO logged on.

ftp> ls
200 PORT subcommand request successful.
125 List started.
POP.POP
POP.X.AGESEX88
POP
250 List completed successfully.
ftp> 

ftp> mget *
mget POP.POP? y
200 PORT subcommand request successful.
150 Retrieving member POP in file POP in library REALLISO.
250 File transfer completed successfully.
1 bytes received in 0.3504 seconds (0.002787 Kbytes/s)
mget POP.X.AGESEX88? y
200 PORT subcommand request successful.
550 File must be specified by library/file.member.
mget POP? y
200 PORT subcommand request successful.
550 File must be specified by library/file.member.
ftp> 

ftp> get realliso/pop.x.agesex88
realliso/pop.x.agesex88: A file or directory in the path name does not exist.
ftp> get realliso/pop
realliso/pop: A file or directory in the path name does not exist.
ftp> mget realliso/*
mget POP.POP? y
200 PORT subcommand request successful.
150 Retrieving member POP in file POP in library REALLISO.
250 File transfer completed successfully.
1 bytes received in 0.2035 seconds (0.004799 Kbytes/s)
mget POP.X.AGESEX88? y
200 PORT subcommand request successful.
550 File must be specified by library/file.member.
mget POP? y
200 PORT subcommand request successful.
550 File must be specified by library/file.member.
ftp> 

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 92 23:21:16 GMT
From:      Mark.McIntosh@engr.UVic.CA (Mark  McIntosh)
To:        comp.protocols.tcp-ip
Subject:   Re: Extending IP-numbers

On Mon, 17 Aug 92 15:22:46 GMT, berg@physik.tu-muenchen.de (Stephen R. van den Berg) said:
>I heard some rumors about several proposals being already on the table
>concerning extending the current 4-byte IP-addresses.
>
>Could anyone knowledgeable disclose some specifics about these proposals?
>(Or some pointers on where to look for more info?)

Check out the August/92 issue of SunExpert Magazine for a column
called "Ask Mr. Protocol".  This month, he discusses the IP
addresssing crunch and examines possible solutions.  One RFC he
recommends is #1287, "Towards the Future Internet Architecture", by
Clark, Chapin, Cerf, Braden, and Hobby.  Mr. Protocol says, "[it]
makes fascinating reading.  Mr. Protocol cannot recommend this
document to hold up the leg on your kitchen table, as you would be too
tempted to pull it out and read it, as opposed to many (possibly most)
other RFCs."  Personally, I've always liked this column for its highly
readable technical content and a dash of humour here and there.

Mark J. McIntosh <Mark.McIntosh@engr.UVic.CA>
____________________________________________________________________________
University of Victoria, Faculty of Engineering - Dean's Office
Box 3055, Victoria, BC, CANADA    \ "...the mystery of life isn't a problem to
V8W 3P6            (604) 721-6049  \    solve but a reality to experience." 
UUCP: ...!{uw-beaver,ubc-vision}!uvicctr!sirius!mmcintos  \ from Dune

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 92 07:32:26 GMT
From:      lars@itek.norut.no (Lars Vognild)
To:        comp.protocols.tcp-ip,comp.dcom.lans.fddi
Subject:   IP-multicast for FDDI?


Does anyone know of an implementation for FDDI of Deering's IP-multicast?

Im running Ultrix 4.2 on a DECStation 5000/200 with DEC's FDDI cards

-----------------------------------------------------------------
Lars K. Vognild				email: lars@itek.norut.no
FORUT Information Technology AS		phone: +47 83 80150
NORUT-gruppen, N-9005 Tromsoe, NORWAY  	fax  : +47 83 82420

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Aug 1992 11:39:32 GMT
From:      grumpy@jpradley.jpr.com (Jeff Markel)
To:        comp.unix.aix,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: Wanted: X.25-Ethernet or X.25-Token Ring gateway OR SLIP driver

In article <1992Aug13.152913.7258@mixcom.com> mgic@mixcom.mixcom.com (mgic) writes:
>
>I am looking for one of the following:
>
>	SLIP driver for RS/6000 AIX (other than IBM's)
>
>	X.25-Ethernet gateway that supports SLIP
>
>	X.25-Token Ring gateway that supports SLIP
>
>
>I want a product that actually works without crashing
>the computer and is available today. Who's selling?
>
>Dean Roth
>(414) 347-4805
>-- 
>
>MGIC Investment Corp.
>270 E. Kilbourn
>Milwaukee, WI 53202

Yeah, it would be nice to have a SLIP that didn't crash the system...

I believe Morningstar has a PPP for RS6000's that also supports SLIP.


                        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
===============================================================================
	The New World Order is ... "Shoot to kill!"
===============================================================================

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 92 11:56:09 GMT
From:      smj@beta.lanl.gov (Stephen M. Johnson)
To:        comp.protocols.tcp-ip
Subject:   MacTCP tn3270

Is there a version of NCSA TN3270 that supports DNS via MacTCP? 

Mark Johnson			| Westinghouse Savannah River Company
				| (803) 644 1494
 smj@lanl.gov			| Aiken, South Carolina
-- 

Mark Johnson			| Westinghouse Savannah River Company
				| (803) 644 1494
smj@lanl.gov			| Aiken, South Carolina

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 92 12:32:31 GMT
From:      joachimf@norisc.erls01.siemens.de (Joachim Feld)
To:        comp.protocols.tcp-ip
Subject:   HELP: Need AX25 driver for AT&T Sys V Rel 4.0

AX25 is the X25 protocol adapted for amateur radio to have TCP/IP
connections over amateur radio stations. 

Please contact via e-mail, I will summarize all answers to the net.
 

Thanks

Joachim DL8NBS

P.S: I don't need it for the company !!!

--
------------------------------------------------------------------------------
Joachim  Feld			email:  joachimf@norisc.erls01.siemens.de
					SIEMENS AG AUT 922B
------------------------------------------------------------------------------

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 92 16:24:51 GMT
From:      cmaeda+@cs.cmu.edu (Christopher Maeda)
To:        comp.protocols.tcp-ip
Subject:   Mr Protocol


In article <MARK.MCINTOSH.92Aug18152116@sombrio.UVic.CA> Mark.McIntosh@engr.UVic.CA (Mark  McIntosh) writes:
>
>Personally, I've always liked this column [Mr Protocol] for its highly
>readable technical content and a dash of humour here and there.

Mr. Protocol is my Lord and Personal Saviour.
 

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

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Aug 1992 16:49:26 GMT
From:      lpc@dickens.com (Luis P Caamano)
To:        comp.protocols.tcp-ip
Subject:   Re: T3000s and SLIP?

In article <1992Aug10.182711.6527@dsg.tandem.com> scott@dsg.tandem.com writes:
>
>I appear to be having a problem with running SLIP over T3000s.  The symptom
>is that the link will run fine for 2-3 days, and then just hang up hard.  I'm
>actually running on a T1600 at one end, but a colleague was running with T3Ks
>at both ends and encountered the same problem.
>

I'm not sure about this, but I think we had a similar problem some
months ago and it turned out to be the phone company that was shutting
off the line every 3 or 4 days. 

We were using a couple of T3000s. (Not anymore though).

-- 
---------------------------------------------------------------------------
Luis P. Caamano                    |         lpc@dickens.com
Dickens Data Systems, Inc.         |         uunet!dickens.com!lpc
Atlanta, GA                        |         (404) 475-8860
---------------------------------------------------------------------------
If I think I know it all, I'll stop learning. -myself
The more I learn, the more I know I know nothing. -somebody else

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Aug 1992 17:01:56 GMT
From:      tkevans@eplrx7.es.duPont.com (Tim Evans)
To:        comp.protocols.tcp-ip
Subject:   archie "pass-through" client in Firewalled Network?

I'm looking for a "pass-through" archie client that'll work in
a firewalled network.  (By "firewalled," I mean that only one
system in our network is directly on the Internet, with packet
filtering activated to allow only specified packet types to pass
through to other hosts on the network.)

We've implemented pass-through ftp and telnet, so users on other
network hosts can access the outside world from their own
systems, and would like to provide similar access to archie.
(We know about accessing archie via e-mail, of course.)

I presume that we could set up our own archie server locally
if this is the only way to do what we want.

Thanks.
-- 
Tim Evans                     |    E.I. du Pont de Nemours & Co.
tkevans@eplrx7.es.dupont.com  |    Experimental Station
(302) 695-9353/7395           |    P.O. Box 80357
EVANSTK AT A1 AT ESVAX        |    Wilmington, Delaware 19880-0357

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Aug 1992 19:23:15 GMT
From:      mvm@cbnewsb.cb.att.com (michael.v.murphy)
To:        comp.protocols.tcp-ip
Subject:   Info on info-server at CSNET and TCP on Sun

    Does anyone have updated info on how to receive copies of RFC's (as 
described in Appendix 3 of Comer's TCP/IP)  The info-server described does
not seem to respond and the 800 number is disconnected. Also, has anyone
had problems passing large messages using Tli (tcp) on Sun Sparc's ? It
seems to loose part of the data for lengths > 4096 on sends and to fragment
at 1460 on receives. Any suggestions ???

							Mike Murphy


-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 92 20:36:25 GMT
From:      irving@casbah.acns.nwu.edu (Thomas Myers)
To:        comp.protocols.tcp-ip
Subject:   SLIP for VMS <-> NeXT


I need to connect a NeXTstation to a VAX/VMS accross serial lines because we
cannot afford to drop >$27K to put in ethernet to another building.  We want
to use IP to transfer files in order to gain speed and leave compatability,
(we considered alternatives like Kermiting files, yuck!).

If anyone can point me toward software (share, free, or other) or suggest
alternatives, I'd appreciate it.

thanks,

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 92 23:52:53 GMT
From:      shuenn@tora.swdc.stratus.com (Shuenn Hwang)
To:        comp.protocols.tcp-ip
Subject:   Re: ethernet perf. paper

Hi, 
	Recently IEB proposed and withdrawed IPv7, does anyone
know where I can find a copy of this ill-fated proposal?

Thanks.

-shuenn hwang


Stratus Computer Inc., 2065 Hamilton Ave, San Jose, CA 95125
Phone: 408-559-5371, Email: shuenn@swdc.stratus.com

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 92 01:17:11 GMT
From:      mustang@IASTATE.EDU (Daniel M Engholm)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple End Systems Via One IP Address?

In article <1992Aug18.171150.13939@cis.ohio-state.edu>, rhm@oclc.org (Robin
Hermance-Moore) writes:
> Can anyone point me to a commercially-available solution to this
> problem?
> 
> We are designing an application which will run on multiple Unix
> systems & be accessible via TCP/IP.  We would like to make these
> systems available to users on the Internet using a single IP
> address.  Since the "application systems" all run pretty much
> independently of each other, we envision something like this:
> 
> Internet
>     |
> [ Front ]
> [ End   ]
>     |
>     ---------------------------------
>     |           |           |
> [ Appl  ]   [ Appl  ]   [ Appl  ] ...
> [ Host  ]   [ Host  ]   [ Host  ]
> [ # 1   ]   [ # 2   ]   [ # 3   ]
> 
> [more information followed, but has been deleted]

This probably won't help you in you ultimate quest, but I would like to
describe a similar situation we have here.  We have a terminal server (Xyplex)
with fourteen 8-port serial cards.  Each card is a separately managed device
with a unique IP address.  Xyplex has a product call the Rotary Domain Name
Server which watches the use of multiple cards and determines which is least
busy.  When a user opens a telnet connection to the service "isn.iastate.edu",
a query goes to the campus Domain Name Server, which consults
"isn.rdns.iastate.edu" for the associated IP address.  The RDNS replies with
the address of the least busy card.  The campus DNS has a time to live of zero,
so the entry isn't cached.

This solution has the benefit of not having a bottleneck with a single front-
end system handling all the traffic.  I hope this helps, even if just a little.
--
Dan Engholm                      |  Internet: mustang@iastate.edu
Telecommunications Engineer      |  US Mail:  95B Black Engineering Bldg.
                                 |            Iowa State University
(515)294-8414                    |            Ames, Iowa  50011-2163

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 92 03:09:54 GMT
From:      brian@cssc-woll.tansu.com.au (byrnes brian)
To:        comp.protocols.tcp-ip
Subject:   FTP: RFC interpretation



I am currently having a disagreement with IBM regarding their
interpretation of RFC959.  I am using their MVS FTP server 
(part of their TCP/IP for MVS package), and I think their 
server does not adhere to the RFC.  IBM  disagrees.

I am looking for someone who can give me a definitive judgement
on whether IBM's server is doing the right thing or not.

The behaviour of their server that I think is questionable is as
follows:

1  -  a response code of "250" to a STRU command;

2  -  a response code of "257" to a CWD command;

3  -  a response code of "550" to an NLST command to indicate that
      there are no files to list.


Section 5.4 of the RFC has "each command listed with its possible
replies".  As I read it, this section would immediately brand 
responses 1 and 2 as protocol violations, because the server's 
replies are not on the list of "possible replies".

IBM's representative defended the server's actions in the following
words:
"I'm not sure that the intent of section 5.4 is to list each and every
possible reply code from the server.  However, section 4.2 and 4.2.1
further define the reply codes and how they can be used to determine
the state of the machine.  Please have the customer read those sections."

The third response (550 to an NLST), is listed in the RFC as a possible
reply.  However, I believe it is being misused. "550" is a error code.  
I do not see why asking for a listing of an empty directory should be
interpreted as an error. Other FTP servers (e.g. Sun's), simply send
back an empty list in this situation. 


Is anyone out there qualified to judge in this matter?
 


Regards,


Brian Byrnes                     internet: brian@cssc-woll.tansu.com.au
Telecom Australia                fax:      +61 42 29 1021
                                 phone:    +61 42 21 1116

ITC Building                     post:  Locked Bag 8812
Wollongong University                   South Coast Mail Centre		
Northfields Avenue                      NSW  2521
Wollongong     

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 92 07:51:27 GMT
From:      avalon@coombs.anu.edu.au (Darren Reed)
To:        comp.protocols.tcp-ip
Subject:   Re: Extending IP-numbers

berg@physik.tu-muenchen.de (Stephen R. van den Berg) writes:

>I heard some rumors about several proposals being already on the table
>concerning extending the current 4-byte IP-addresses.
 
>Could anyone knowledgeable disclose some specifics about these proposals?
>(Or some pointers on where to look for more info?)

ftp to munnari.oz.au (anonymous) and take a peek in /big-internet.

Darren.

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Aug 1992 13:25:41 GMT
From:      richards@beta.lanl.gov (William C. Richards)
To:        comp.protocols.tcp-ip
Subject:   Re: Monitor program for catching duplicate IP addrs?

In article <xjeldc.21.713199462@lustorfs.ldc.lu.se> xjeldc@lustorfs.ldc.lu.se (Jan Engvald LDC) writes:
>In article <jqymwsq.ptrubey@netcom.com> ptrubey@netcom.com (Phil Trubey) writes:
>>From: ptrubey@netcom.com (Phil Trubey)
>>Subject: Monitor program for catching duplicate IP addrs?
>>Date: 7 Aug 92 12:31:30 GMT
 
>>Does anyone know of a utility program that will scan an Ethernet
>>and build a table of IP # to ethernet # mappings and check for
>>duplicate IP #s?  Thanks for any info,
>
>That is just what my PDTBUILD program does. Runs on a PC on top of
>a packet driver. Included in the PDCLKSET package, available from
>msdos.ftp.sunet.se:pub/network/pdclkset/pdclk144.zip or
>ftp.lu.se:pub/network/pdclkset/pdclk144.zip


I was wondering if there is anything like this for Suns running SunOS 4.1.1?

Much thanks in advance.



Peter Richards
richards@beta.lanl.gov

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 92 16:22:14 GMT
From:      pc@linus.mitre.org (Melissa P. Chase)
To:        comp.protocols.tcp-ip
Subject:   Re: getting RFCs


In article <1992Aug15.032117.10906@crd.ge.com>
bloomer@rodson.crd.ge.com (John Bloomer) writes:

>Is there an approved way to obtain the latest copies of RFCs?

If you have WAIS running, you can also get the RFCs through it.  The
nice thing about using WAIS is that you construct a query to locate
the RFCs of interest.

	Penny

--
UUCP:  { ... }!linus!pc 
INTERNET:  pc@mitre.org

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 92 20:00:54 GMT
From:      mfitz@devnull.West.Sun.COM (Mark Fitzpatrick - Systems Engineer)
To:        comp.protocols.tcp-ip
Subject:   ?: Checking Media via C

Does anyone have a simple C routine that checks if your
media (ethernet) is functioning.  i.e. sends an TCP
packet out onto the wire and then reads it?

Thanks,
Mark

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 92 09:14:12 -0500
From:      imhw400@indyvax.iupui.edu
To:        comp.protocols.tcp-ip
Subject:   Re: What are the Pros/Cons of Multi-protocol routing?

In article <86673@netnews.upenn.edu>, tony@scotty.dccs.upenn.edu (Anthony Olejnik) writes:
[...]
> What are some of the advantages/disadvantages of keeping the
> backbone pure (with only IP)?

[Sound of donning NOMEX suit]

Advantages:	none that I've ever heard of.

Disadvantages:  o	Other protocols slow down (maybe not a lot) due to
			encapsulation overhead.

		o	Greater complexity (=greater opportunity for error),
			in both software and administration.

Bottom line:  you pay little but get nothing.  What a deal.

> What are the advantages/disadvantages of tunnelling the other
> protocols (AppleTalk/IPX/DecNet) within IP?

Same as above.  This is really the same question, given that demand for these
other stacks exists.

}flame on{  Maintaining the ethnic purity of our backbones is a goal that
nobody has ever justified to my satisfaction.  What does it help?  Isn't it
just a holdover from the early days of multiprotocol routers, when they did IP
passably and others poorly?  Those days are gone.
-- 
Mark H. Wood, Lead Analyst/Programmer    +1 317 274 0749   [@disclaimer@]
Internet:  IMHW400@INDYVAX.IUPUI.EDU     BITNET:  IMHW400@INDYVAX
Celebrate freedom:  read a banned newsgroup.

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 92 07:24:48 GMT
From:      mbm@netarch.com (Mike Morey)
To:        comp.protocols.tcp-ip
Subject:   Help with IP configuration

I have a question about IP configuration for the following.
Please note that the IP addresses are not the actual ones used.
These Class C addresses were used just to depict the situation
at hand and is used solely to illustrate a point.

We have a production net and a training net. A SPARCstation 2 (zeus)
is acting as a gateway between the two nets.

We want the production network to have IP access onto the training net
but we do not want any traffic from the training net to be able to
access the production net. i,e, we want the production net to have
IP access to both networks but we want to limit training net so that
it will not traverse the production net.

The following diagram illustrates this:

                                                PRODUCTION NET
------------------------+-------------------------------------
                        |  221.9.10.111
                    +---+---+
                    |       |
                    | zeus  |
                    |       |
                    +---+---+
                        |  226.9.200.10
------------------------+-----------------------------------
                                                TRAINING NET

Can any netters offer any solutions that will solve this problem ?
For right now, we are using a Sun SPARCstation 2 as a gateway machine
but eventually we will be getting a router.

In the interim period, we need to do some kind of IP filtering.

Please email me your responses because I do not access the newsgroups
often.

Thanks !

-Mike

mbm@netarch.com

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 92 15:52:48 PDT
From:      hippo@sonoma.edu (Michel Davidoff)
To:        comp.protocols.tcp-ip
Subject:   No handels for type 0806

What does this error meaage means ?
How do I fix it ?
No Handels for type 0806

Thank you

Michel
E-Mail Michel.Davidoff@Sonoma.edu

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 92 17:49:44
From:      Steinar.Haug@delab.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Is info on the Delta-t protocol available electronically?

I have read the following two articles which (partly) describe the Delta-t
protocol:

"Timer-Based Mechanisms in Reliable Transport Protocol Connection Management",
by R.W.Watson

"Gaining Efficiency in Transport Services by Appropriate Design and
Implementation Choices", by R.W.Watson and S.A.Mamrak

(both from the "Innovations in Internetworking" collection edited by Craig
Partridge.)

I would like to understand the Delta-t protocol better, and therefore I need
more info. My questions are:

- Is any info on the Delta-t protocol available electronically? Anonymous
FTP would be fine.

- Is the Delta-t protocol still being used?

Steinar Haug, system/networks administrator
SINTEF DELAB, University of Trondheim, NORWAY
Email: Steinar.Haug@delab.sintef.no, 
	sthaug@idt.unit.no, steinar@tosca.er.sintef.no

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Aug 1992 15:18:31 GMT
From:      madhu@cbnewsf.cb.att.com (madhu.shekhar)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP gurus, please help




This may be a FAQ, but I don't know where to look for
answers.

We are building a product on which we need to put the
TCP/IP protocol suite. I need to know ASAP the following :

    1) Can I use free distributions of TCP/IP to port it
to my environment (UNIX-like OS) , and use it in my product ?
(I mean, is it legal to use it in a product)

    2) If so, What are the FTP sites for TCP/IP sources.

Please respond by e`mail. Thanks in advance.

     Madhu Shekhar
     madhu@mtdkfs1.att.com


-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Aug 1992 17:14:32 GMT
From:      ddurbin@is.rpslmc.edu (Dave Durbin)
To:        comp.protocols.tcp-ip
Subject:   3172 Help

Some colleagues (sp?) of mine need help with the following:

1) Printing from a 3090 via TCP/IP over a 3172.
2) File transfer (FTP) from MUSIC and CMS via TCP and a 3172.


Any help/experience/war stories are greatly appreciated!

Thanks in advance!

Dave Durbin
Advanced Technology Center
Rush-Presbyterian-St. Luke's Medical Center
(who needs a .sig)

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 92 18:03:55 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: What are the Pros/Cons of Multi-protocol routing?

The disadvantages to running a mutli-protocol network become more
apparent the larger it gets.  The level of sophistication of the routing
code for one protocol in a router versus another becomes clear as you
stress the box.  The result CAN be that you take out a portion of your
network due to a malfunction in a protocol.  Mind you, IP is just as
much a possibility for this as any other.

You also have to know more about these other protocols so that you can
debug them.

I'm not saying you shouldn't do it:  just recognize you are running
parallel networks that just happen to use the same physical facilities. 
And I certainly wouldn't advocate tunneling.  That's always been a bad
idea.

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

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 92 18:51:39 GMT
From:      kwe@noc.near.net (Kent England)
To:        comp.protocols.tcp-ip
Subject:   Re: What are the Pros/Cons of Multi-protocol routing?

In article <86673@netnews.upenn.edu> Anthony Olejnik writes:
>
>Currently we have a pure IP only backbone.
>
>What are some of the advantages/disadvantages of keeping the
>backbone pure (with only IP)?
>
>What are the advantages/disadvantages of tunnelling the other
>protocols (AppleTalk/IPX/DecNet) within IP?
>
>Any comments would be *GREATLY* appreciated.

TCP/IP has more sophisticated routing protocols than many of the other
internet protocols you can run, and it and OSI are the only protocols
suitable for a public internet.

The disadvantage of a single protocol backbone is tunneling everything
else when routing is easier.

But tunneling is sometimes necessary such as for getting AppleTalk across
the Internet, for source routed bridging across a complex WAN, or for
tunneling SDLC.

Don't underestimate the complexity of supporting additional protocols
whether tunneled or routed.  Make sure you have enough features and
filters to control them.  But if they are important enough to your
situation, then by all means support them.

--Kent


-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 92 20:48:12 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: What are the Pros/Cons of Multi-protocol routing?

In article <l9aeprINNsg0@noc.near.net>, kwe@noc.near.net (Kent England) writes:
> In article <86673@netnews.upenn.edu> Anthony Olejnik writes:
>>
>>Currently we have a pure IP only backbone.
>>
>>What are some of the advantages/disadvantages of keeping the
>>backbone pure (with only IP)?
>>
>>What are the advantages/disadvantages of tunnelling the other
>>protocols (AppleTalk/IPX/DecNet) within IP?
>>
>>Any comments would be *GREATLY* appreciated.
> 
> TCP/IP has more sophisticated routing protocols than many of the other
> internet protocols you can run, and it and OSI are the only protocols
> suitable for a public internet.
> 
> The disadvantage of a single protocol backbone is tunneling everything
> else when routing is easier.
> 
> But tunneling is sometimes necessary such as for getting AppleTalk across
> the Internet, for source routed bridging across a complex WAN, or for
> tunneling SDLC.
> 
> Don't underestimate the complexity of supporting additional protocols
> whether tunneled or routed.  Make sure you have enough features and
> filters to control them.  But if they are important enough to your
> situation, then by all means support them.

I have a problem with oversimplifying anything. And this is way oversimplified.

First, how big a backbone is involved? For a small backbone of a couple
thousand systems, routing all of the mentioned protocols is no problem.
AppleTalk and IPX don't scale well, though, for big nets. And all routed
protocols must be centrally administered to avoid addressing conflicts.

AppleTalk should be AppleTalk Phase 2. Phase 1 sends out to much overhead on a
large net. And don't even thing about large scale tunnelling of AppleTalk. The
RTMP will kill you. Routing can work to a limited extent, though.

DECnet is quite suitable for wide area routing. It was designed for it and is
generally much easier to manage than even IP. Many regionals and two of the
three national backbones in the US carry DECnet quite well with a global DECnet
internet of at least 20K nodes. (It's probably much larger, but it's hard to
keep track.) But to join the global DECnet you must get addresses from a
central authority, just like with IP.

I guess I'd say the multi-protocol routing is much better than tunnelling in
most cases. But you have to understand the protocols and how the operate on
things like slow serial lines and with slow propagation. IP, DECnet, and OSI
are well suited to large networks. AppleTalk and IPX are OK for smaller nets,
but not to anything like the size of the Internet.

I might also mention that DECnet has only 16 bits of address, so you have to
deal with that when the net gets big. IP will have this problem shortly. At up
to 160 bits, OSI is OK for a while.

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

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Aug 1992 22:11:54 GMT
From:      hyl@microplex.com (Henry Lee)
To:        comp.protocols.tcp-ip
Subject:   Summary: Van Jacobson's Specs for TCP/IP


Here's a summary of Van Jacobson's specifications for data
transmission in TCP protocol that I requested a while ago.  There are
two different specifications: RFC 1144 (Compressing TCP/IP Headers for
Low-Speed Serial Links) and RFC 1323 (TCP Extensions for High
Performance).  RFC 1323, the info I was looking for in particular,
talks about TCP window scale option, round-trip time measurement, and
protection against wrapped sequence numbers.  Also, SIGCOMM 88
Proceedings was meantioned as having easy reading for Van Jacobson's
family of TCP congestion control algorithms.

I would like to thank the following for their help.
Bob Sutterfield at MorningStar
Rodd Zurcher at Motorola
Pete Schow at InterLan
McKenzie at BBN

-- 
Henry Lee              Microplex Systems Ltd      Tel: 604 875-1461
hyl@microplex.com      265 East 1st Avenue        Fax: 604 875-9029
Software Engineer      Vancouver, BC  V5T 1A7,  Canada

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22 Aug 92 01:36:28 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: TFTP Broadcasts

When RFC906 was written, there was indeed no standard for broadcasting.
RFC919 (issued 4 months later) set the standard.  If you use broadcasts,
you should follow the standard, not some speculation about the standard
that you hear on a bulletin board.

-Jeff

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22 Aug 92 01:46:56 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip,comp.dcom.lans.fddi
Subject:   Re: IP-multicast for FDDI?

In article <1992Aug19.073226.4812@news.uit.no> lars@itek.norut.no (Lars Vognild) writes:
>
>Does anyone know of an implementation for FDDI of Deering's IP-multicast?
>
>Im running Ultrix 4.2 on a DECStation 5000/200 with DEC's FDDI cards

Try looking at the files in 
pescadero.stanford.edu:/vtmp-ip/*ultrix*

To use this you may need an Ultrix source license (which is fairly cheap for
educational institutions); or maybe not.  I have NOT used this code myself.

The FDDI driver in Ultrix probably supports multicasting at the link
layer; it's the IP code that needs to be patched.

-Jeff


-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 92 14:47:53 GMT
From:      jessea@homecare.com (Jesse W. Asher)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   SCO ODT 2.0 having troubles talking to Netblazers?

Is anyone out there having problems with the tcp/ip that comes with
SCO ODT 2.0?  We installed ODT 2.0 and found that we had some problems
talking to remote Netblazers.  We were told it was because the tcp/ip
that comes with ODT 2.0 is based on an RFC that isn't current and the
Netblazers are based on the most current.  Can anyone verify this?
Are we going to continue having problems with this tcp/ip?

-- 
      Jesse W. Asher                                   Phone: (901)762-6000
                         Varco-Pruden Buildings
	      6000 Poplar Ave., Suite 400, Memphis, TN  38119
 Internet: jessea@homecare.COM                 UUCP: ...!banana!homecare!jessea

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22 Aug 1992 23:16:30 GMT
From:      ben@datacomm.ucc.okstate.edu (Ben James)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   Routing IP Token-Ring to Ethernet


I have gotten IBMTOKEN.COM (Crynwr) to work with simutaneous Novell 3.11
server access.

For a router I am using PCROUTE assembled for PacketDrivers on both
sides.  On the token-ring side I am using IBMTOKEN.COM and on the 
ethernet side I am using 3c523 (Crynwr).  I am using a PS/2 model 50
to do the routing (Microchannel Machine).

I am having a few interesting problems!

First all of the microchannel mechines with (4/16) cards are working OK.
All of the AT-bus machines with 4MB cards worked also. (At least all of
them that I tried.)  

The AT-buss mechines with (4/16) cards don't work!  Actually They will
work if I use the ip number 192.198.4.7 but none of the others that I
have tried will work ( i.e 192.198.4.13 ).
If I telnet with 192.198.4.7 to a mechine and then quit, change IP
number to 192.198.4.13 then I can telnet to that same mechine and
login again but I can't telnet to any others.

When not doing this and trying to telnet using CUTCP it hangs at screen 
just after it makes the TCP connection ( The screen where the login prompt 
would come up at).

I have several Microchannel machines working with NO problems.  I only
tried one AT-bus machine with a 4MB card and it was working until I
switched to 4/16 MB card.  I do still have my simutaneous Netware access
on these cards.

I have also noticed a bug in Novell's Lansup Driver v2.62 which
conflicts with IBMTOKEN.COM but v2.60 works fine. 

Routing with the PC is only a tempoary solution for us but surpriseingly
enough It worked (Sort of!).

I am also interested in how you are routing because that is probally the
cause of the problem.  Also any other suggestions for fine-tuneing the 
router would be helpfull.

Also, If you know of a configuration for Novell which will route these
packets could you please email a copy to me.  So far we have been unable
to get our Novell 3.11 server to route the packets properly.

Ben James
ben@datacomm.ucc.okstate.edu 


-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 92 00:53:06 GMT
From:      barr@silver.NNTP (J. Hunter Barr)
To:        comp.protocols.tcp-ip
Subject:   Help on SLIP requested

I am very interested in running SLIP, and I wonder if anyone could
help me with a couple of very basic questions:

Is there a FAQ for SLIP available for FTP?

Where could I get SLIP for a DECstation or an IBM RS/6000?
(Commercial, PD, source, binary, *anything*)


Please reply by email to BARR@SILVER.LCS.MIT.EDU, because I cannot get
reliable access to the usenet news, so I probably won't see anything
posted here.

    Thanks,                     ______
                                HUNTER
--
                                ______
                                HUNTER

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Sun, 23 Aug 1992 05:13:16 GMT
From:      dboyes@is.rice.edu (David E Boyes)
To:        comp.protocols.tcp-ip
Subject:   Re: What are the Pros/Cons of Multi-protocol routing?

In article <1992Aug21.124812.1@ptavv.llnl.gov> oberman@ptavv.llnl.gov writes:
>DECnet is quite suitable for wide area routing. It was designed for it and is
>generally much easier to manage than even IP. Many regionals and two of the
>three national backbones in the US carry DECnet quite well with
>a global DECnet 
>internet of at least 20K nodes. (It's probably much larger, but it's hard to
>keep track.) But to join the global DECnet you must get addresses from a
>central authority, just like with IP.

I have to disagree slightly here. The upper level DECnet
protocols are easily routable, but the device management
protocols (pre-phase V) such as MOP are not. You're stuck with
tunneling or (worse yet) deploying remote hosts to do small tasks
like download microcode into printers. I'm anxiously awaiting a
full phase V implementation which is rumored to correct this
problem, as well as introducing a routable LAT and (I hope) the
demise of MOP in favor of SNMP or something else that will deal
with routed networks in a more congenial fashion.

>R. Kevin Oberman			Lawrence Livermore National Laboratory
-- 
David Boyes
dboyes@rice.edu

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Sun, 23 Aug 1992 09:06:59 GMT
From:      eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert)
To:        comp.protocols.tcp-ip
Subject:   Re: What are the Pros/Cons of Multi-protocol routing?

From article <l9aeprINNsg0@noc.near.net>, by kwe@noc.near.net (Kent England):
> In article <86673@netnews.upenn.edu> Anthony Olejnik writes:
> 
> TCP/IP has more sophisticated routing protocols than many of the other
> internet protocols you can run, and it and OSI are the only protocols
> suitable for a public internet.

RSCS has proven to live in the large too ;-))
> 
> The disadvantage of a single protocol backbone is tunneling everything
> else when routing is easier.

So, what about public data networks (or VDNs) with X.25 or Frame Relay ?
In a way this is tunneling too, only that you would not consider
Frame Relay by itself an Internet network protocol, but X.25 could be.

> But tunneling is sometimes necessary such as for getting AppleTalk across
> the Internet, for source routed bridging across a complex WAN, or for
> tunneling SDLC.
> 
> Don't underestimate the complexity of supporting additional protocols
> whether tunneled or routed.  Make sure you have enough features and
> filters to control them.  But if they are important enough to your
> situation, then by all means support them.

Yes, one should really weight the need for the additional protocol against
the trouble it will cause.

An important point with multiple protocols is the step towards integrated
routing protocols in my opinion.

-- 

             Toerless.Eckert@informatik.uni-erlangen.de
    /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=Eckert/G=Toerless/
	             2b or not 2b that is ff

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Sun, 23 Aug 1992 09:19:26 GMT
From:      eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP gurus, please help

From article <1992Aug21.151831.28538@cbfsb.cb.att.com>, by madhu@cbnewsf.cb.att.com (madhu.shekhar):
> 
> This may be a FAQ, but I don't know where to look for
> answers.
> 
> We are building a product on which we need to put the
> TCP/IP protocol suite. I need to know ASAP the following :
> 
>     1) Can I use free distributions of TCP/IP to port it
> to my environment (UNIX-like OS) , and use it in my product ?
> (I mean, is it legal to use it in a product)
> 
>     2) If so, What are the FTP sites for TCP/IP sources.
> 
> Please respond by e`mail. Thanks in advance.
> 
>      Madhu Shekhar
>      madhu@mtdkfs1.att.com
> 

If i am not mislead by your e-mail and the organisation header of
your message, i would recommend you to repeat your question on
the newsgroups "alt.suit.att-bsdi" or "comp.unix.bsd", where friendly
people will be prepared to answer you, how you might find
a successful (and still free) version of the TCP/IP protocol stack
(unless this changes thanks to att).

(sorry, i couldn't resist)
-- 

             Toerless.Eckert@informatik.uni-erlangen.de
    /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=Eckert/G=Toerless/
	             2b or not 2b that is ff

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 92 18:21:33 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: No handels for type 0806

In article <hippo.12.0@sonoma.edu> hippo@sonoma.edu (Michel Davidoff) writes:
>What does this error meaage means ?
>How do I fix it ?
>No Handels for type 0806

In the hope that you are not the resident networking expert at Sonoma
State University, I would advise that you seek out that guru or one of
his assistants.

(1) You do not state where you see this error message, nor which
    software is likely to have produced it.
(2) Given that your own words are misspelled, I suspect that you have
    not accurately transcribed the error message, either. (While I'm
    sure there are still surviving members of the Handel family, I would
    not expect them to be handling ARP.) :-)
(3) Ethernet type (hex) 0806 is ARP. (What's an ethernet type ? What's
    ARP ? Go read a textbook; take a networking class or something.)
(4) The most likely origin of this message is an error in a program, or
    a misconfigured program. It sounds sort of like somebody forgot to
    make provisions for responding to ARP queries.
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 92 21:25:07 GMT
From:      ian@spider.co.uk (Ian Heavens)
To:        comp.protocols.tcp-ip
Subject:   Traffic characteristics by application

I'm interested in anything published on traffic characteristics of
TCP and UDP based applications, including

- distribution of packet size
- lifetime of a connection
- characteristics of different types of connection
- frequency of packet generation over the lifetime of the connection.

Ideally, one could define benchmarks which measured performance of a TCP/IP
stack in a way reflecting different types of real usage.  Has anyone done this?
I believe that bulk data transfer on a single connection is the usual quoted
benchmark, using ttcp (I know there are NFS benchmarks around).  

Telnet and ftp are examples which are fairly obvious, but NFS, OLTP, etc.,
etc., would be very interesting.

In addition, is the efficiency of protocol processing best reflected by
throughput per unit of CPU usage (as reported by ttcp)?  Any other factors
that are relevant?

Thanks


ian

---
Ian Heavens				ian@spider.co.uk                 
Spider Software
Spider Park, Stanwell Street		
Edinburgh, EH6 5NG, Scotland		+44 31 555 5166 (Ext 4347)
--

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Sun, 23 Aug 1992 21:28:06 GMT
From:      susan@moo.org (Susan Dean)
To:        comp.protocols.tcp-ip
Subject:   SLIP


Does anyone know if there is SLIP for System V/386 avaliable via FTP?
If this is not the place to post this, please advise.

sd

-- 

Susan Dean datanet|| WWUG                      IP 192.207.83.0
Modem Over Olympia,(moo.org)                   MDMOVROLY-CUP.PORTAL.COM         World Wide User Group (MIL)                    SBOB!AT&T.MAIL.COM
      

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Aug 1992 01:07:57 GMT
From:      larry@gator.rn.com (Larry Snyder)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP

susan@moo.org (Susan Dean) writes:


>Does anyone know if there is SLIP for System V/386 avaliable via FTP?

SLIP comes with most SVR3.2 and SVR4 releases -- heck, ISC and Dell
have been shipping SLIP for a couple of years..  Who's UNIX are you
running?

-- 
Larry Snyder                                    internet: larry@gator.rn.com
keeper of the Gator                                  uucp: uunet!gator!larry

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 92 01:34:33 GMT
From:      sob@hsdndev.UUCP (Scott Bradner)
To:        comp.protocols.tcp-ip
Subject:   OSPF interoperability test

FYI - There will be an OSPF interoperability test in the Harvard
Network Device Test Lab starting on Sept. 1 1992. (just in time
scheduling :-} )  The test is being organized by the OSPF Steering
Committee in cooperation with Network World.

If your company makes a router that supports OSPF on Ethernet, token ring,
or FDDI and wants to join in the test please contact Maureen Molloy at
Network World (508) 875-6400.

Scott

PS- don't bother trying to contact me - I'll be out of town & touch
for the next week.


-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Aug 1992 02:16:02 GMT
From:      axk7110@usl.edu (Khanna Alok)
To:        comp.protocols.tcp-ip
Subject:   Implementation of Distributed Database in SUN RPC

Dear Netter,

I am working on implementation of a small model of distributed database. 
The database can reside on different location but for a user it
should be transparent.

I am planning to use SUN RPC for communication between
different clients and servers. 

Has any one has implemented this type of project before? If yes, I would 
like to discuss with you some of design details.

If lot of people are intersted in this type of work, I can summarise later
on the reponses I will receive.

I will appreciate the reponses by email (alok@usl.edu) if it is not 
inconvenient.

Thanks a lot in advance.

Alok Khanna.
email: alok@usl.edu

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      25 AUG 92 21:35:30
From:      jblaine@fsu1.cc.fsu.edu (Jeff Blaine)
To:        comp.protocols.tcp-ip
Subject:   SLIP FAQ ?

Does a SLIP FAQ exist?  If so can anyone please shove me in the direction 
of one, or any SLIP general docs for that matter?  Any help would greatly 
be appreciated.

jblaine@fsu1.cc.fsu.edu
-_-____________________________________________________________________-_-


-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 92 14:44:02 +0200
From:      tamone@uni2a.unige.ch
To:        comp.protocols.tcp-ip
Subject:   caltech.edu mail unreachable ??

I cannot reach caltech.edu by mail. I send to kratel@caltech.edu and the
message bounces there. It seems like they are not well configured locally.
I can finger kratel@caltech.edu, though. Could someone tell them they could have
a problem or I am not doing the right thing ? Is there a better way to
reach kratel@caltech.edu ? Could someone try from the united states.
Meanwhile, I ask my mail manager.

Thanks

Francois tamone@cui.unige.ch

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Aug 1992 20:21:42 GMT
From:      zweig@cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP packet headers.

macauley@bnr.ca (John MacAuley) writes:

>If I have a maximum limit of 8192 bytes for a UDP packet,
>how big can the user data be?  Does the UDP header need
>to be included in this maxsize?

The limitation on maximum datagram size is determined by the implementations
of UDP on both sides of the data transfer.  I know that MacTCP limits you to
8192 octets of user data, and that the protocol limits you to 65535 minus the
combined length of the IP and UDP headers (28, with no IP options present),
but limitations on IP fragmentation/reassembly often make IP godzillagrams
unusable.  So the short answer is "it depends."

-Johnny Header

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Aug 1992 07:57:35 +0000
From:      ronald@gate.demon.co.uk (Ronald Khoo)
To:        comp.unix.sysv386,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: SCO ODT 2.0 having troubles talking to Netblazers?

jessea@homecare.com (Jesse W. Asher) wrote:

> Is anyone out there having problems with the tcp/ip that comes with
> SCO ODT 2.0?

Well, I can't get the rarpd to work for me, but otherwise it looks good.
The performance is better than the last release, and it's got
lots of useful stuff pre-compiled for it, of which I've used at least
dig, traceroute and xntpd today and they all seem to work well.

> We installed ODT 2.0 and found that we had some problems
> talking to remote Netblazers.

How remote ?  Do you mean using PPP or SLIP ?  For certain, SCO ODT
has absolutely no problems talking to netblazers running FRED 1.5
over ethernet because I that's what I'm typing into right now.

> that comes with ODT 2.0 is based on an RFC that isn't current and the
> Netblazers are based on the most current.

This sounds like a reference to the PPP implementation.  It's true that
SCO ODT 2.0 supports only RFC171 and RFC172 PPP which is not the
latest RFC.  However, that goes the same for most PPP implementations
you can get today, and most of them seem to work fine with the Netblazer.

I haven't had a chance to try out SCO's own ppp yet, so I can't say
whether it will interoperate with the Netblazer, but being an "old"
ppp will in itself not prevent it doing so.  Do try changing some
of the Netblazer ppp configurations.  For example, SCO's manuals
at cursory reading don't mention VJ header compression support, so
you might want to try a wild stab at disabling that on the netblazer
end.

Sorry I can't give any concrete help, but I've redirected followups to
a group containing people who might be able to (the ppp newsgroup)
since it sounds like you're having PPP trouble.

-- 
Ronald Khoo <ronald@demon.co.uk> <ronald@ibmpcug.co.uk> <ronald@robobar.co.uk>
BTNet: +44 71 229 7741                    | Brambles are the order of the day.

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 92 08:17:33 GMT
From:      sklower@diva.Berkeley.EDU (Keith Sklower)
To:        comp.protocols.tcp-ip
Subject:   Re: What are the Pros/Cons of Multi-protocol routing?

In article <17bfvnINNrgt@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
}In article <l9i4eiINNocr@noc.near.net> kwe@noc.near.net (Kent England) writes:
}>I think it is stretching the definition of an internet protocol to
}>include X.25.
>Is it really? ...  There are gateways between Tymnet, Telenet, Datapac, and
>various regional telephone company networks.

The last time I checked, I was severely thwarted in attempts to establish
an X.25 connection between me on accunet and apple computer on telenet,
even tough Apple's network manager and I both wanted to do some
interoperability testing.

After much pulling of strings and threating to cut off service (and
nearly being called a liar to my face by the ATT technical
representative to OSINET, I was told that I might be granted permission
to do that if I were to write a technical proposal to OSINET detailing
exactly what kind of testing I had in mind, and why UC Berkeley
couldn't afford to shell $7K to join OSINET, and blah, blah, blah.
I wound up doing some testing against the CDNnet people in toronto.

I would say that X.75 interconnectivity is FAR from comlete.

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Aug 1992 08:52:41 GMT
From:      dov@menora.weizmann.ac.il (Dov Grobgeld)
To:        comp.protocols.tcp-ip
Subject:   tcpip and gobbler

We have had problems with intruders to our network and I have run
the PC Gobbler program to snif up ethernet packets on the local
ethernet segment. With the included software I can look at the
data of tcpip packets, packet by packet, but it is quite tedious
to follow what the intruder typed this way.

Included with Gobbler is a program that dissects the surrounding
ethernet packet and extracts the tcp-ip packet. Unfortunately I have
not been able to decipher the tcp-ip packet manually to extract the
data section.

Could someone please describe the anatomy of a tcpip packet? Or
refer me to a document where it can be found.

Please reply by E-mail, as I am not a regular subscriber of this
group.

--
                                                        ___   ___
                                                      /  o  \   o \
Dov Grobgeld                                         ( o  o  ) o   |
The Weizmann Institute of Science, Israel             \  o  /o  o /
"Where the tree of wisdom carries oranges"              | |   | |
                                                       _| |_ _| |_


-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Aug 1992 15:10:11 GMT
From:      aep@world.std.com (Andrew E Page)
To:        comp.protocols.tcp-ip
Subject:   Text/Book recommendations for TCP-IP

    Does anyone have any recommendations for a good book on TCP-IP
protocol(s), implentations, use/abuse, etc.  I'm looking at debugging
som hardware/firmware that may not be implementing the protocol properly.  

DoD# 0581   1990 Suzuki VX800   MSF Intro Class Aug 1990

-- 
Andrew E. Page CTO(Warrior Poet)|   Decision and Effort The Archer and Arrow
DSP Ironworks                   |     The difference between what we are
Macintosh and DSP Technology    |           and what we want to be.

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Aug 92 17:25:59 GMT
From:      airon@edm.isac.ca (Airon Yan Sung Yiu)
To:        comp.protocols.tcp-ip,comp.protocol.tcp-ip.ibmpc
Subject:   TN327 Emulator using Pathworks for DOS TCP/IP socket library

Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Tn3270 Emulator using Pathwork socket library
Summary: Problems with Pathwork (DOS) socket read
Followup-To: poster 
Distribution: world
Organization: ISA Corporation, Edmonton, AB
Keywords: 


--------------------------------------------------------------------
I have the same problem when using Pathworks for DOS TCP/IP version 2.0.
I have included the first mail that I sent out for your reference.
--------------------------------------------------------------------
*** Previous mail ***

Hi, folks :
I have modified the NCSA Telnet/TN3270 emulation program to work with
Beame and Whiteside TCP/IP socket library and everything works fine.
However, I encountered some problems when I tried to port the program to
work with DEC Pathworks socket library.  It seems that the socket read
function in the Pathworks socket library does not clear the internal
storage buffer before each call (by the way, I clear my own storage
buffer before socket read is called each time).  Consequently, each time
the program reads new information from the network, there is some
leftover stuff from previous socket read calls.  This causes the Telnet
negotiaiton for 3270 sessions to fail.  I had similar problems when I
used the same 3270/Pathwork program (running in VT100 mode) to connect
to our Sun 4.

Can anyone help me ?  Here are some details about the program :
  Pathworks for DOS version 4.1
  Pathworks for DOS (TCP/IP) version 1.1A
  The NCSA/3270 program was ported from Turbo C (v 2) to MicrSoft C (v 6)

Please reply to my e-mail address and I will post the summary of
response.  Thank you.

-- 
Airon Y.S. Yiu 		         mail: airon@edm.isac.ca
ISA Corp.			 uucp: !{uunet, alberta}!isagate!airon
Edmonton, Alberta, Canada       phone: (403) 420-8081 

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Aug 1992 20:07:05 GMT
From:      kannan@oar.net (Kannan Varadhan)
To:        comp.protocols.tcp-ip
Subject:   Re: Extending IP-numbers

Thus spake avalon@coombs.anu.edu.au (Darren Reed)
>berg@physik.tu-muenchen.de (Stephen R. van den Berg) writes:
>>I heard some rumors about several proposals being already on the table
>>concerning extending the current 4-byte IP-addresses.
 
>>Could anyone knowledgeable disclose some specifics about these proposals?
>>(Or some pointers on where to look for more info?)
>
>ftp to munnari.oz.au (anonymous) and take a peek in /big-internet.

Associated mailing lists are big-internet-request@munnari.oz.au,
tuba-request@lanl.gov, ip-encaps-request@lanl.gov and
pip-request@thumper.bellcore.com to join.


Kannan
-- 
Kannan Varadhan,		1224, Kinnear Road,	+1 614 292 4137
Internet Engineer (OARnet)	Columbus, OH 43212	+1 614 292 7168 (FAX)

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Aug 1992 20:10:34 GMT
From:      mats@devildog.att.com (Matt Szela)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   NETBIOS over TP4/CLNP and over TCP/IP

Folks,

I need to find more info on NETBIOS over TP4/CLNP and NETBIOS over TCP/IP.

What are the documents that discuss/specify NETBIOS service/protocol 
and any other related documents on NETBIOS over TP4 and over TCP??

Also how does TOP relate to NETBIOS and LAN MANager protocols??

Please send email to mats@devildog.att.com or post on this group.

Tx,

Matt


-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 92 22:06:29 GMT
From:      booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
To:        comp.protocols.tcp-ip
Subject:   Why UDP was slower than TCP using ttcp

Someone asked me to summarize the answer to my question:  Why, when running
over FDDI, was UDP slower than TCP for a Cray X/MP sending to a Sun 4/680 (
using ttcp)?

I left out one piece of information which appears to be the answer:  I did
*not* fire up a receiver.  I simply sent from the Cray to another unsuspecting
machine.  After posting and getting a few responses (each of which talked
about over-running the receiver), I reran my tests with a receiver in place
and, sure enough, the data rates were as one would expect (I measured the
Cray sending around 64 mbits/second).  My guess is that sending to a machine
with no receiver was causing the receiving machine to generate ICMP
port-unreachable (or some such) error messages, and these were slowing down
the transfer.  Admittedly, this seems a little thin in terms of an
explanation (at least it does to me), but it sure sounded convincing to
those around me asking me to explain what the heck was going on...

thanks,
mb
-- 
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948

"I don't know that atheists should be considered citizens, nor should they be 
considered patriots.  This is one nation under God." - George Bush 8/27/88

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 92 01:36:12 GMT
From:      br.pct@RLG.Stanford.EDU (Peter C. Tam)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   KA9Q NOS LPD

Hi,
    I have been trying to configure KA9Q NOS lpd to work. My system
  consists of:  Victor 286 AT-compatible (8mhz) w LPT1, COM1.,
                3C503 ethernet card,
                HP LaserJet II printer connected to Parallel Port,

                MS-DOS 5.0,
                CryNwr 3c503.com "3c503 0x65 9 0x300 1"

    I was successful in printing a small output file, a file the size
  of an average CONFIG.SYS, but when I try to print a bigger file (2 or
  more pages), Computer will hang. Even after I get into lpc in NOS,
  stop the printer, & just try print file transfer to print queue
  under /spool/lpd/lp1, it still hangs. The Data File of "DFAAxxx" is
  created, & of 0 file length when it hangs. Seems to be hanging in the
  recv() loop in receive_data_file() in lpd.c of NOS LPD.

    Am I missing something here? NOS ftp works, even though it is slower
  than NCSA/CUTCP ftp. So, my network configuration is ok.

    Following is content of my /etc/printcap file:

#
# example printcap for NOS LPD
#

#
# HP LaserJet II
#
lp1|p1:\
	:af=/spool/lpd/lp1-acct:\
	:lf=/spool/lpd/lpd-log:\
	:lp=LPT1:\
	:pl#64:\
	:pw#0:\
	:sd=/spool/lpd/lp1:\
	:sh:

  Thanks for any HELP !!!!

+---------------------------------------------------------------------------+
| Peter C. Tam                         InterNet: br.pct@RLG.Stanford.EDU    |
| Fax: (415) 964-0943                  BitNet:   br.pct@RLG.BITNET          |
 +---------------------------------------------------------------------------+

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 92 07:18:53 GMT
From:      tb@Materna.DE (Torsten Beyer)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over ISDN

Hi Folks,

I have a problem concerning TCP/IP over ISDN. We have an ISDN implementation
for TCP/IP that is able of a so called short hold mode. This means, ISDN
connections that are idle for a certain time get closed without closing the
overlaying TCP connections. As soon as one of the communication partners
starts sending data again, a new ISDN connection is established. All this
happens (nearly) transparently to the IP layer.

However there is a problem: How can a server tell wether an established
connection is still established or already broken due to a crash on the
client side. We don't want to poll clients (i.e. ping) since this would
actually break the cost advantage of ISDN short hold mode.

From my point of view the only way a server can tell a connection is
broken, is when the same client sends a SYN from the same client port to the
same server port. Is this true or are there other ways of detecting that a
connection is broken (or was broken) ?
--
Torsten Beyer                      	mail	     : tb@Materna.DE
Dr. Materna GmbH		   	vox humana   : +49 231 5599 225
Vosskuhle 37, D-4600 Dortmund	   	fax machina  : +49 231 5599 100
 "There must be a place, under the sun, where hearts of olden glory grow young"

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Aug 1992 07:43:45 GMT
From:      y@drug.COM (Yoshi Mizuno)
To:        comp.protocols.tcp-ip
Subject:   Please Help with TCP/IP TLI problem!!



Hi, we encountered a problem trying to impliment our clinent/server application
using TLI. I wonder if anyone can help.  

When a fast machine (SUN Sparc 630 MP) sends a bunch of TCP/IP packets to
a slow machine (Sparc IPC) a lot of packets get dropped.  For example, doing
spray from a fast one to the slow one, we get:


(630MP to IPC)

yt@hana$ spray meto
sending 1162 packets of lnth 86 to meto ...
        in 10.4 seconds elapsed time,
        658 packets (56.63%) dropped
Sent:   111 packets/sec, 9.4K bytes/sec
Rcvd:   48 packets/sec, 4.1K bytes/sec

With this condition, the following test program fails.  We thought that TCP/IP
makes an error free connection. . .  What are we doing wrong?  Or, is this
the way TCP/IP is?  


Yoshi Mizuno, Pharm.D.             [][][]       UUCP:      uunet!drug!y
Mizuno Pharmacies                  []  []       INTERNET:  y@drug.COM
4-1-24 Yushima, Bunkyo-ku        [][][][]       ISDN:      +81-3-5684-7722
Tokyo 113 JAPAN                    []           G3 FAX:    +81-3-5684-7723



------------------------CUT HERE--------------------------------
/* tst.c */

/*	This is test program using TLI to access TCP/IP.
	Server send data to client.
	If this program is used with no arguments, then it is the server.
	If this program gets the name of the machine where the server is
	running as an argument, then it is the client.
	When packets get lost in transmission, the client blocks on t_rcv forever.
	I assume that the lost packets never get sent again.
*/

#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <tiuser.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>

extern int t_errno;

void ErrFn();
#define Error()		ErrFn(__FILE__,__LINE__)
#define Assert(b)	if(!(b)) Error()
#define TLI_ERR		{ t_error("t_error"); Error(); }


#define nTimes		500
#define bufsize		256
#define iPort		5

main(argc,argv)
int argc;
char *argv[];
{
	int i, c, iR, g, fd;
	unsigned char buf[bufsize];

	switch(argc) {
	case 1:					/* no arguments, make server and send */
		fd = OpenServer();
		for( c=0; c<bufsize; c++ )
			buf[c] = c;
		for( i=0; i<nTimes; i++ ) {
			printf("put %d\n",i);
			iR = t_snd(fd,buf,bufsize,0);
			if(iR!=bufsize)  TLI_ERR;
		}
		break;
	case 2:					/* 1 argument is name of server machine, make client and receive */
		fd = OpenClient(argv[1]);
		for( i=0; i<nTimes; i++ ) {
			printf("get %d\n",i);
			for( c=0; c<bufsize; c++ ) {
				iR = t_rcv(fd,buf,1,&g);
				if(iR!=1)  TLI_ERR;
				if( *buf != c ) {
					printf("%d %d\n",*buf,c);
					Error();
				}
			}
		}
		break;
	default:
		Error();
	}
	sleep(60);
	printf("done\n");
	/* the fancy functions to close TLI don't work on Sun, so forget them */
	if( t_close(fd) < 0 )  TLI_ERR;
}

int OpenServer() {
	int fd;
	struct t_bind *pBind;
	struct sockaddr_in oSock;
	struct t_call *pCall;

	fd = t_open("/dev/tcp",O_RDWR,NULL);
	if( fd < 0 )  TLI_ERR;
	pBind = (struct t_bind*)t_alloc(fd,T_BIND,T_ALL);
	if(!pBind)  TLI_ERR;
	pBind->qlen = 1;

	oSock.sin_family = AF_INET;
	oSock.sin_addr.s_addr = INADDR_ANY;
	oSock.sin_port = iPort;
	pBind->addr.len = sizeof(struct sockaddr_in);
	memcpy(pBind->addr.buf,&oSock,sizeof(struct sockaddr_in));

	if( t_bind(fd,pBind,pBind) < 0 )  TLI_ERR;
	if( t_free((char*)pBind,T_BIND) < 0 )  TLI_ERR;
	pCall = (struct t_call*)t_alloc(fd,T_CALL,T_ADDR);
	if(!pCall)  TLI_ERR;
	if( t_listen(fd,pCall) < 0 )  TLI_ERR;
	if( t_accept(fd,fd,pCall) < 0 )  TLI_ERR;
	if( t_free((char*)pCall,T_CALL) < 0 )  TLI_ERR;
	return fd;
}

int OpenClient(sHost)
char *sHost;
{
	int fd;
	struct t_call *pCall;
	struct sockaddr_in oSock;
	struct hostent *pHost;

	fd = t_open("/dev/tcp",O_RDWR,NULL);
	if( fd < 0 )  TLI_ERR;
	if( t_bind(fd,NULL,NULL) < 0 )  TLI_ERR;
	pCall = (struct t_call*)t_alloc(fd,T_CALL,T_ADDR);
	if(!pCall)  TLI_ERR;

	oSock.sin_family = AF_INET;
	pHost = gethostbyname(sHost);
	Assert(pHost);
	memcpy(&oSock.sin_addr,pHost->h_addr,pHost->h_length);
	oSock.sin_port = iPort;
	pCall->addr.len = sizeof(struct sockaddr_in);
	memcpy(pCall->addr.buf,&oSock,sizeof(struct sockaddr_in));

	if( t_connect(fd,pCall,NULL) < 0 ) {
		if(t_errno==TLOOK)  printf("t_look=%x\n",t_look(fd));
		TLI_ERR;
	}
	if( t_free((char*)pCall,T_CALL) < 0 )  TLI_ERR;
	return fd;
}

void ErrFn(s,i)
char *s;
int i;
{
	printf(" %s %d\n",s,i);
	exit(1);
}
 
-- 
Yoshi Mizuno, Pharm.D.             [][][]       UUCP:	   uunet!drug!y
Mizuno Pharmacies                  []  []       INTERNET:  y@drug.COM
4-1-24 Yushima, Bunkyo-ku        [][][][]       ISDN:      +81-3-5684-7722
Tokyo 113 JAPAN                    []           G3 FAX:    +81-3-5684-7723

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Aug 1992 08:26:36 GMT
From:      MLONG@isucard.card.iastate.edu
To:        comp.os.os2.misc,comp.protocols.tcp-ip
Subject:   Re: DOS packet drivers, NDIS and Token-Ring

In article <92239.103636A6054OS2@HASARA11.BITNET>                               
A6054OS2@HASARA11.BITNET writes:                                                
                                                                                
>I'm using OS/2 2.0 and have TCP/IP 1.2 installed with the IBMTOK MAC           
>driver.                                                                        
>Since programs like Archie can only be used with ethernet packet drivers       
>(those progs are based on CUTE or NCSA telnet), I can't use these Network      
>Information Retrieval progs.                                                   
>However I lately read something about converting packet drivers to NDIS. Is    
>that possible and how? Or is there some info available on this topic? Or other 
>possibilities to use those programs?                                           
>                                                                               
>All help is very much appreciated,                                             
>                                                                               
>Rachid Tebbal                                                                  
>University of Amsterdam                                                        
>Department of Information Systems                                              
>The Netherlands.                                                               
>                                                                               
>                                                                               
Right now I am running the IBMTOKEN.COM packet driver and the IBM OS/2 LAN Requ 
ester and CUTCP all at the same time all on the same token ring adapter.        
You will first need the OS/2 NTS/2 Beta LAPS disks, they can be gotten from     
800-IBM-3040 (I see you are international, sorry for the 800 number).  This new 
 version of LAPS (or NTS/2?) comes with a Virtual IEEE 802.2 driver for DOS     
boxes.  Within LAPS I changed the System Key from its default of 0 to 0002 in t 
he OS/2 configuration for IEEE 802.2.  Then open the DOS box, and use the comma 
nd C:\IBMCOM\LTSVCFG S=16 C=18 N1=1 D=1.  Then load the IBMTOKEN.COM packet     
 driver, then load CUTCP, or NCSA, or whatever.                                 
This Virtual 802.2 looks to be very powerful at allowing OS/2 to share network  
adapter resources with DOS Network packet drivers that are written to 802.2.    
Mike Long                                                                       
Iowa State University                                                           
                                                                                

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 1992 18:38:47 -0400
From:      lidl@rodan.UU.NET (Kurt J. Lidl)
To:        comp.protocols.tcp-ip
Subject:   Re: TFTP Broadcasts

In article <CKD.92Aug18115535@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
>Fred> == Fred Fierling <fff@microplex.com> 
>
> Fred> How pervasive is [all 1s] broadcasting?  Anyone care to hazard a
> Fred> guess as to what percentage of systems support it?  Are there any
> Fred> big time vendors that do NOT support it?
>
>SunOS defaults to using net.0 as the broadcast address (although I
>believe SunOS 5, aka Solaris 2.0, does finally get this right).
>
>It allows you to change it, but it's annoying.

Well, sorta.  For older generation sun machines, that need to boot
diskless off an ethernet, if you watch closely, you will see it broadcast
to the all zero's address.  (Cast in ROM, I think.)

For machines that are capable of booting Solaris 2.0, (ie SPARC), I
think they all try all ones when diskless booting...

Once they are up and running, it is a snap to change the broadcast
address of the machines...

-Kurt
-- 
/* Kurt J. Lidl (lidl@uunet.uu.net)   | Unix is the answer, but only if you */
/*                                    | phrase the question very carefully. */
/* Don't even think of confusing my opinions with my employer's opinions!   */

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 92 12:47:01 GMT
From:      ghawkins@unix1.tcd.ie (George C. Hawkins)
To:        comp.protocols.tcp-ip
Subject:   Why does my slip line die overnight?


When I leave my machine overnight and come back in the morning I
find my slip connection has died on me. Does it timeout on inactivity
in the belief that it's saving dialup line money (I have a fixed
link)? There is no mention of such behaviour in my docs. Can I
disable this "feature" or do I have to get my machine to run ping
over the connection at regular intervals or is it something completely
different?

Thanks for your time, yours,


George.
--
george lives at:
___________________________________________________________________________
|   ghawkins@unix1.tcd.ie (mostly)  |   ghawkins@vax1.tcd.ie (sometimes)  |
---------------------------------------------------------------------------

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Aug 1992 15:14:59 GMT
From:      steveh@devildog.att.com (Steve Hendershott)
To:        comp.protocols.tcp-ip
Subject:   Looking for SNMP Trap Sending Program

Does anyone have or know where I can get the source for an SNMP trap sending
program. In particular I'd like to be able to modify the variable bindings
and have it work on a UNIX machine. I really need source code to make this
work. I would appreciate any help directly or where I can FTP this
type of program.

Thanks.
-- 
Stephen W. Hendershott
steveh@devildog.att.com

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Aug 1992 15:16:59 GMT
From:      probert@fires1.uucp (Neal W. Probert)
To:        comp.os.os2.networking,comp.protocols.tcp-ip
Subject:   I need 3COM 3c505 Ethernet Plus driver for IBM's OS/2 TCP/IP

Net folks,

I need the 3COM 3c505 EtherLink Plus driver for IBM's OS/2 TCP/IP
software.  I am running OS/2 2.0 and the driver must conform to the
NDIS MAC specification.

Also, does anybody have a phone# for 3COM?

Thanks.


-- 
    FORD       | Neal W. Probert   E3154 SRL    | probert@fires1.srl.ford.com
 SCIENTIFIC    | Ford Scientific Research Labs  | 313-845-8178 FAX 313-337-5581
RESEARCH LABS  | Dearborn, MI 48121-2053        |

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 92 16:18:34 GMT
From:      ivor@occs (Ivor D'Souza)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: What terminal server should I buy?

karl@thuja.gsfc.nasa.gov (Karl A. Anderson) writes:
: I need to buy a terminal or communications server to meet the following 
: requirements:
: 
: - Ethernet interface with choice of thin- or thick-ethernet
:   connections;
: - Minimum of 16 dial-in ports, with ability to add more;
: - Dial-in speeds of up to 38.4 Kbps;
: - Minimum of 1 MB RAM, expandable;
: - Security features (ID/password at least, maybe logging too)
: - Support for LAT, SLIP/cSLIP/PPP, DNS, SNMP
: 
: 3Com, Cisco, Telebit and Xylogics (Annex) all appear to offer products 
: that meet the minimum requirements.  Are there any other vendors?  Does 
: anybody have any recommendations (comp.dcom.sys.cisco readers are 
: allowed to recommend Cisco :^}) or caveats, either specific or general?  
: Please respond by email, as I don't ordinarily take these groups.  TIA.
--
I would also look at XYPLEX Terminal Servers.

 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
    Ivor L. D'Souza                                      INTERNET:        
    System Administrator                            ivor@occs.nlm.nih.gov 
    National Library of Medicine                    Tel: (301) 402-1742    

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Aug 1992 17:09:21 GMT
From:      mack23@avalon.eecs.nwu.edu (Chris Walsh)
To:        comp.protocols.tcp-ip
Subject:   on-line src from Comer & Stevens, Vol 2 ?


According to the Inroduction in Comer and Stevens' Internetworking
with TCP/IP, vol II, "...the publisher has made machine-readable
copies of the code from the text available".  Does anyone know if
this code is available via anonymous FTP?  Prentice-Hall would have
to be pretty cool to allow this, but I figure it's worth a shot.

Thanks.


-- 

Chris Walsh                               Pithy Quotation Wanted
TechNet Network Administrator             ----------------------
2145 Sheridan Rd.                         Send candidates to: 
Evanston, IL 60208                         mack23@avalon.eecs.nwu.edu

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 92 17:17:00 GMT
From:      booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
To:        comp.protocols.tcp-ip
Subject:   Re: Is info on the Delta-t protocol available electronically?

In article <STEINAR.HAUG.92Aug21174944@delab.sintef.no> Steinar.Haug@delab.sintef.no (Steinar Haug) writes:
>I have read the following two articles which (partly) describe the Delta-t
>protocol:
>
>"Timer-Based Mechanisms in Reliable Transport Protocol Connection Management",
>by R.W.Watson
>
>"Gaining Efficiency in Transport Services by Appropriate Design and
>Implementation Choices", by R.W.Watson and S.A.Mamrak
>
>I would like to understand the Delta-t protocol better, and therefore I need
>more info. My questions are:
>
>- Is any info on the Delta-t protocol available electronically? Anonymous
>FTP would be fine.
>
>- Is the Delta-t protocol still being used?
>

Well, I must say I never expected to actually see Delta-t mentioned on the
Internet!  

I worked for Dick Watson (up until a couple of years ago), and currently work
with John Fletcher (Watson and Fletcher are the orignators of Delta-t).  Sadly,
to my knowledge, there is no information available electronically on Delta-t.
There are protocols which, I believe, have drawn from Delta-t, such as VMTP and
XTP, and you can find information about these protocols on the Internet.

As for Delta-t still being used, the answer is yes, but not for much longer.
At LLNL, we designed a distributed operating system (eventually) called NLTSS,
which utilized Delta-t as its transport protocol.  We currently have Delta-t
implementations running on Vaxen and Crays (and maybe a Sun or two).  However,
we are in the process of migrating to standard vendor-supplied software, as
we can no longer afford to support large research and development efforts.  So
it is likely that, within the next year, the only existing implementations of
Delta-t (of which I know) will disappear, and Delta-t will exist only on
paper.

There are a couple of other papers you might be interested in:  "Mechanisms
for a Reliable Timer-Based Protocol," by John Fletcher and Richard Watson, the
original paper describing Delta-t, and "Delta-t Protocol Specification," by
Richard Watson, which includes a model of a transport user-interface.  There
have been a couple of memos issued by John Fletcher regarding various aspects
of Delta-t (such as performance enhancements), and a couple of memos
discussing the performance of our implementations.

I would be more than happy (thrilled might best describe it) to send you copies
of the above papers and memos (if I can track them down) if you so desire.

Glad to hear there are still people out there looking at Delta-t.  It's a
great piece of work that has been little noticed in the 15 years since its
development.

cheers,
mb
-- 
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948

"I don't know that atheists should be considered citizens, nor should they be 
considered patriots.  This is one nation under God." - George Bush 8/27/88

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Aug 1992 18:23:48 GMT
From:      djarrett@gandalf.ca (Dave Jarrett)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over ISDN

In article <tb.714899933@materna> tb@Materna.DE (Torsten Beyer) writes:
>Hi Folks,
>
>I have a problem concerning TCP/IP over ISDN. We have an ISDN implementation
>for TCP/IP that is able of a so called short hold mode. This means, ISDN
>connections that are idle for a certain time get closed without closing the
>overlaying TCP connections. As soon as one of the communication partners
>starts sending data again, a new ISDN connection is established. All this
>happens (nearly) transparently to the IP layer.
>
>However there is a problem: How can a server tell wether an established
>connection is still established or already broken due to a crash on the
>client side. We don't want to poll clients (i.e. ping) since this would
>actually break the cost advantage of ISDN short hold mode.
>
>From my point of view the only way a server can tell a connection is
>broken, is when the same client sends a SYN from the same client port to the
>same server port. Is this true or are there other ways of detecting that a
>connection is broken (or was broken) ?
>--
>Torsten Beyer                      	mail	     : tb@Materna.DE
>Dr. Materna GmbH		   	vox humana   : +49 231 5599 225
>Vosskuhle 37, D-4600 Dortmund	   	fax machina  : +49 231 5599 100
> "There must be a place, under the sun, where hearts of olden glory grow young"


As far as I know, there is no way of implicitly determining the
difference between a client on hold and a client that has been powered
off. The only way for the server to determine if a disconnected client
is still capable of receiving traffic, is to poll the client.

A polling method that appears to be very cost effective might 
work as follows:

 - The ISDN server maintains a idle timer for each client LAN connection.
   If data packets are received from the client within the preprescribed 
   period of time, no poll will be neccessary. 

 - When the idle timer expires, the ISDN server issue a B-channel 
   connect request to the client ISDN station. The user-user data field
   in the connect request contains a "poll" command. 

 - If the client is still alive, it returns a "disconnect" response to
   the connect request with predefined user "cause" value. 

 - Receipt of a disconnect response, with a user rejection code, 
   informs the server that the client is still alive and capable of
   receiving LAN data.

 - If the server receives a disconnect response with any other "cause"
   code, it knows that the client has been powered off or disconnected. 

This approach has two advantages over polling using SYNs:

 1. No connection is ever established during the polling process,
    so no connection tariffs are applicable.

 2. This approach is LAN protocol independant.


This approach depends on the availability of user-user data in the
connect request. If your local PTT does not support user-user data, 
it might be possible to issue the connect request with a specific,
predefined DDI (extension number) used only for polls. 

If anyone has reason to believe that this approach will not work, or 
can think of viable alternative approaches, feel free to comment. 

It might be a good idea to post your question to the comp.dcom.isdn newsgroup,
where all the real ISDN gurus are.

Regards,
Dave J.




-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 92 20:21:42 GMT
From:      dsc3jfs@nmrdc1.nmrdc.nnmc.navy.mil (Jim Small)
To:        comp.protocols.tcp-ip
Subject:   slip over tcp


I have a use for SLIP over TCP, instead of over a tty.  Is there any
existing code that will do this?   It will most likely be running on
an AIX system for what it's worth . . . .
-- 
I love the 3b2
The 3b2 is my friend.

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Aug 92 20:44:38 GMT
From:      sjs@netcom.com (Stephen Schow)
To:        comp.protocols.tcp-ip
Subject:   NETWORK CONSULTANT WANTED


I am looking for a network consultant that can help us set up our WAN E-mail.
We have a UNIX based mini that runs a patient tracking system called 'HBO'.

Physicians get information from this Host computer down to their PC clients
via 'WAL-LINK'.

We need a consultant that is very experienced setting up UNIX mail servers.
Specifically, we want MD's to be able to send and recieve E-mail
(user-friendily) from their local PC through a new Mail server which we have
yet to acquire, out to any other MD on another PC.

If we can get information acquired from the Host database into mail messages,
that would also be helpful.

If you are a knowledeable consultant in this area, please respond.

You may contact Kathyrn Moser for more information.

Kathryn Moser
John Muir Medical Center
(510) 947-5379
-- 
------------------------------------------------------------------
Steve Schow    | But you don't have to use the claw, if you
sjs@netcom.com | pick the pear with the big paw paw......
               | Have I given you a clue......?
               |                       - Baloo the Bear
------------------------------------------------------------------

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Aug 1992 23:07:32 GMT
From:      bwolfe@rad.rpslmc.edu (Brian A. Wolfe)
To:        comp.dcom.lans.ethernet,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Traffic Visualization tool?


Hi there,

I am designing a show network for a certain medical society and I
am trying to find some sort of network traffic analysis package
that can help some very computer illiterate sorts of people 
understand which clients and servers are communicating with 
one another (in real-time, not just a static map).

For example, one way to show this graphically might be to 
depict the network map (I need to show about 50 hosts at once)
with icons representing the hosts, and then draw lines between the 
hosts in real-time that get thicker (and thinner) based on the 
volume of traffic between them. 

I would like to find something that runs on a Sparcstation,
but I am open to using other platforms (as long as I can send the
video to an Electrohome projector).

Thanks in advance for any pointers,

Brian



-------------------------------------------------------------------------
Brian Wolfe						
Associate Director
Dept of Diagnostic Radiology and Nuclear Medicine
Rush Presbyterian-St. Lukes Medical Center 
Chicago,  IL   USA 
Internet: bwolfe@rad.rpslmc.edu    
Voice:    (312)-942-2141          FAX:  (312)-942-2114

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 92 00:26:47 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP: RFC interpretation

In article <1992Aug20.030954.4831@cssc-woll.tansu.com.au> brian@cssc-woll.tansu.com.au (byrnes brian) writes:
>I am currently having a disagreement with IBM regarding their
>interpretation of RFC959.  I am using their MVS FTP server 
>(part of their TCP/IP for MVS package), and I think their 
>server does not adhere to the RFC.  IBM  disagrees.

This point of RFC959 has been clarified by RFC1123, "Requirements for
Internet Hosts -- Application and Support".  In general, it says that
IBM shouldn't be making up numbers, but your FTP client also shouldn't
assume specific response codes instead of basing its reaction solely
on the highest digit of the response.  Specifically, from 4.1.2.11 on
page 33 of RFC1123:

Begin quote:

            A Server-FTP SHOULD use the reply codes defined in RFC-959
            whenever they apply.  However, a server-FTP MAY use a
            different reply code when needed, as long as the general
            rules of Section 4.2 are followed. When the implementor has
            a choice between a 4xx and 5xx reply code, a Server-FTP
            SHOULD send a 4xx (temporary failure) code when there is any
            reasonable possibility that a failed FTP will succeed a few
            hours later.

            A User-FTP SHOULD generally use only the highest-order digit
            of a 3-digit reply code for making a procedural decision, to
            prevent difficulties when a Server-FTP uses non-standard
            reply codes.

End quote.

						don provan
						donp@novell.com

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 92 01:00:34 GMT
From:      malc@equinox.unr.edu (Malcolm Carlock)
To:        comp.sys.apollo,comp.sys.hp,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Problems using Domain/OS SR10.2 through PCROUTE?

There is a DN3500 at our site running SR10.2 which was recently moved
behind a PC running Van Morrison's PCROUTE.  The subnet behind the
PCROUTER is shared by the DN3500 and an HP320 running HP/UX B.08.00.

The DN3500 used to use an HP Unix box as a router, with no problems.
However, since the PCROUTER replaced the HP (which has since changed
addresses; both machines have been rebooted several times since the change),
telnet, rlogin, ftp connections etc. from the DN3500 to ANY machine outside
of the local subnet fail after 20 seconds or so with "connection closed by
foreign host".  Remote machines can be Suns, DECS, HP's or whatever, and can
be on the UNR network or anywhere else on the Internet.

Eavesdropping from a third machine via etherfind on conversations between
the DN3500 and machines elsewhere shows that remote hosts are, for
reasons that aren't clear, sending a TCP FIN signal to the DN3500.
Connections between the DN3500 and the HP that shares its subnet, and
from the HP to other machines and other networks, don't seem to have
any problems that we can detect.

Anyone know what's going on here?
-- 

Malcolm L. Carlock                      Internet:  malc@unr.edu
                                        UUCP:      unr!malc
                                        BITNET:    malc@equinox

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Aug 1992 08:32:28 GMT
From:      paola@hplb.hpl.hp.com (paola fulchignoni)
To:        comp.protocols.tcp-ip
Subject:   Secure TCP-IP


Does anyone know whether a "secure TCP" or "secure IP" exist (providing
security
services such as access control, source authentication, integrity, etc.)?
If so, where can I get information about them from?

Please e-mail directly to me any reply to this message.

Thank you in advance
Paola

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 92 12:54:52 GMT
From:      dsc3jfs@nmrdc1.nmrdc.nnmc.navy.mil (Jim Small)
To:        comp.mail.sendmail,comp.protocols.tcp-ip
Subject:   tcp encapsulated of mail


A while back there was a discusion of using SMTP as the transport layer
for TCP (or was it IP in general?).  Granted this is extremely slow, but 
I have use for a similar application.  I would not be using mail as the
transport layer, but I would be using a tcp socket (for 
political/administrative reasons, a standard SLIP line is not available).

-- 
I love the 3b2
The 3b2 is my friend.

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Aug 1992 13:07:30 GMT
From:      kozlowsk@Informatik.TU-Muenchen.DE (Rolf Kozlowski)
To:        comp.protocols.nfs,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Question for RPC - gurus


Hi,

I have written a little sample programm using RPC (see any RPC Guide like 
HP's `Programming and Protocols for NFS Services` ).  The client only makes 
a request for an integer value and the server returnes an integer.
Afterwords I have put some timestamps into the client and measured with
our network monitor the time of the packets on the ethernet.
The C-Source looked like this:

	...
	gettimeofday (&timval1, &timzone);
	clnt_stat = clnt_call (client, RUSERSPROC_NUM, xdr_void, 	
	   0, xdr_u_long, &nusers, total_timeout)) != RPC_SUCCESS);
	gettimeofday (&timval1, &timzone);
	...

The results were like this:
	- Output client) 
		the result of the RPC: 777
		    RPC-delay = 2694 usec
				---------
	- Delay between the request-packet from the client and the reply from 
	  the server:            633 usec
				---------
	  (this delay includes: send the request (client), 
				receive the packet and prepare it (server)
				send the reply (server) )

	The time between receiving the frame from ethernet and returnung from 
	the `clnt_call()` is about 2 msec's!!

Now my question:
	What happens after the client has received the reply ?? 

Thanks

---------------------------------------------------------------------------------
Rolf Kozlowski	Inst. fuer Informatik, Technische Universitaet Muenchen
		PO-Box 202420, 8000 Muenchen 2, Germany
Rolf.Kozlowski@Informatik.TU-Muenchen.DE	Tel: +49 89 2105 8193

				
		


-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 92 14:50:48 GMT
From:      probert@fires1.uucp (Neal W. Probert)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.os.os2.misc,comp.os.os2.networking
Subject:   Need help with getting IBM's TCP/IP running under OS/2

I just installed the 3COM 3c505 driver for OS/2 2.0 for use with IBM`s
TCP/IP package.  Here's what I get from STARTUP.CMD:

CALL C:\TCPIP\BIN\TCPSTART.CMD
CONFIGURING TCP/IP
add net default: router 128.5.192.3: (null): Network is unreachable


Here is my protocol.ini just in case:

[PROT_MAN]
 DriverName = PROTMAN$

[IBMLXCFG]
 TCPIP_nif = TCPIP.nif

;*----------------------------------------------*
;*------------- PROTOCOL SECTION ---------------*
;*----------------------------------------------*

[TCPIP_nif]
 DriverName = TCPIP$
 Bindings = ELNKPL_nif


;*----------------------------------------------*
;*--------------- MAC SECTION ------------------*
;*----------------------------------------------*


[ELNKPL_nif]
 DriverName = ELNKPL$
 NETADDRESS = "02608c1aee2d"
 INTERRUPT = 12
 DMACHANNEL = 7
 IOADDRESS = 0x250
 MAXTRANSMITS = 8
-- 
    FORD       | Neal W. Probert   E3154 SRL    | probert@fires1.srl.ford.com
 SCIENTIFIC    | Ford Scientific Research Labs  | 313-845-8178 FAX 313-337-5581
RESEARCH LABS  | Dearborn, MI 48121-2053        |

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Aug 1992 15:58:04 GMT
From:      oleg@watson.ibm.com (Oleg Vishnepolsky)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.os.os2.misc,comp.os.os2.networking
Subject:   Re: Need help with getting IBM's TCP/IP running under OS/2

In  <1992Aug28.155005.25410@watson.ibm.com>  oleg@watson.ibm.com (Oleg Vishnepolsky) writes:
> In  <Btp7wu.2Bv@fmsrl7.srl.ford.com>  probert@fires1.uucp (Neal W. Probert) writes:
> > I just installed the 3COM 3c505 driver for OS/2 2.0 for use with IBM`s
> > TCP/IP package.  Here's what I get from STARTUP.CMD:
> >
> > CALL C:\TCPIP\BIN\TCPSTART.CMD
> > CONFIGURING TCP/IP
> > add net default: router 128.5.192.3: (null): Network is unreachable
>
> What happened to your ifconfig statement ? Without setting an IP address
> for your network interface, any network would be unreachable.

Please also make sure that if you do have ifconfig in your startup.cmd,
that ip address it sets is on the same net as your default router.

Oleg Vishnepolsky

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Aug 1992 16:25:05 GMT
From:      walt@unhsst.unh.edu (Walter R. Trachim)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: What terminal server should I buy?

In article <1992Aug27.161834.7291@nlm.nih.gov> ivor@occs (Ivor D'Souza) writes:
>karl@thuja.gsfc.nasa.gov (Karl A. Anderson) writes:
>: I need to buy a terminal or communications server to meet the following 
>: requirements:
>: 
>: [requirements, comments, etc., deleted]
>--
>I would also look at XYPLEX Terminal Servers.

I would second that, wholeheartedly. As I write this, we're up to 56 Xyplex
Maxserver 1500 and 1600's running on our campus backbone. We have virtually
no trouble with them, and when we have, Xyplex Technical Support has been
quite responsive and helpful. We're very satisfied with them.

Walt

-- 
                              Walter R. Trachim 
      University of New Hampshire - Office of Telecom and Network Services
                 Telecommunications Center, Durham, NH 03824
		             walt_trachim@unh.edu

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Aug 1992 17:49:57 GMT
From:      hoang1@litwin.com (Dave Jackson)
To:        comp.protocols.tcp-ip
Subject:   ioctl request SIOCGARP fail in SCO (ARP protocol)

Hi,
I'm writing a program to read the ARP cache.
But I have the problem when using SIOCGARP in SCO/ODT ver 2.0:
  
  .
  .
  .
  int soc;
  struct arpreq ar;
  .
  .
  .
  /*
  **  Execute the IOCTL to read the ARP cache, if the host is not
  **  currently in the cache, this ioctl will fail.
  */
  if ((i = ioctl( soc, SIOCGARP, &ar )) != 0)

  It's always failed and return:
    errno == ENXIO
    ioctl: No such device or address

But if I test in DEC5000/200 Ultrix 4.2 or SUN/sparc OS 4.1.1 is ok.

Do I miss anything in SCO env.

I will post or mail my source code if you request.

Thanks in advance,

Ted Hoang
Litwin Process Automation
Email:hoang1@dynsim1.litwin.com


-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 92 18:47:17 GMT
From:      wayne@ultra.com (Wayne Hathaway)
To:        comp.protocols.tcp-ip
Subject:   WANTED: C server TELNET

Could somebody please tell me where to get a public-domain C version
of server TELNET?  Or better, could somebody just e-mail me one?

Much appreciated!

    Wayne Hathaway               domain: wayne@Ultra.COM
    Ultra Network Technologies     uucp: ...!ames!ultra!wayne
    101 Daggett Drive             phone: 408-922-0100 x132
    San Jose, CA 95134              FAX: 408-433-9287

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 92 20:07:52 GMT
From:      birchall@pilot.njin.net (Shag)
To:        comp.protocols.tcp-ip
Subject:   SL/IP clues sought, cheap.


	Greetings.

	Being a lazy netrunner, instead of poking around a couple thousand 
FTP directories looking at every SLIP implementation known to mankind [and
probably a few other species], I'm going to ask some questions.

	First, the facts.

	My end:
	80286-16 PC, 1mb RAM, 80mb HD [65mb free], PPI 14.4kbps modem.

	The dialin:
	Cisco box with Multitech 9.6kbps modem, I have a TACACS login.

	This account:
	Sparcstation-II, connected to the Cisco via T-1.

	I've seen things stated on some local newsgroups that lead me to
believe I can, having a TACACS login on the dialin, run SLIP off it, or
off the Sparc, or off something.

	I've poked around a couple FTP sites, and downloaded the most 
promising looking Zipfile... which turned out to be a couple hundred K of
documentation.  Ack.  [Noack]

	I've been told ka9q can handle SLIP nicely, which encourages me,
although the documentation doesn't really say a whole lot about handling
it over a dialup connection, instead of packet radio, which I don't have.

	If someone out there could suggest specific files to get [and 
perhaps even specific FTP sites from whence to get them], I'd be a rather
happy camper, and probably stop asking silly questions for a couple days
while I tried to get it set up right.

	Of course, if you just want to tell me I'm silly, that's okay too.
But anyway.  Any answer is better than no answer.

	-Shag
-- 

     Freedom belongs to only those without video screens for eyes and mouth.
		- Queensryche

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Aug 1992 21:48:47 GMT
From:      sip1@ellis.uchicago.edu (Timothy F. Sipples)
To:        comp.os.os2.networking,comp.protocols.tcp-ip
Subject:   Re: I need 3COM 3c505 Ethernet Plus driver for IBM's OS/2 TCP/IP

In article <BtnEGE.Lw3@fmsrl7.srl.ford.com> probert@fires1.srl.ford.com writes:
>I need the 3COM 3c505 EtherLink Plus driver for IBM's OS/2 TCP/IP
>software.  I am running OS/2 2.0 and the driver must conform to the
>NDIS MAC specification.

I believe it is available via anonymous ftp from ftp-os2.nmsu.edu.

-- 
Timothy F. Sipples      | The OS/2 FREQ. ASKED QUESTIONS LIST is avail. from
sip1@ellis.uchicago.edu | 128.123.35.151, anonymous ftp, in /pub/os2/all/faq.
Dept. of Econ., Univ.   | Or from LISTSERV@BLEKUL11.BITNET (send "HELP").
Chicago, 60637          | Hey GOP: The Economy, Stupid!

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 92 23:45:50 GMT
From:      erik@yarra.pyramid.com.au (Erik Lecis)
To:        comp.protocols.tcp-ip
Subject:   Re: Text/Book recommendations for TCP-IP

In article <BtLJH0.Cw3@world.std.com>, aep@world.std.com (Andrew E Page) writes:
> 
>     Does anyone have any recommendations for a good book on TCP-IP
> protocol(s), implentations, use/abuse, etc.  I'm looking at debugging
> som hardware/firmware that may not be implementing the protocol properly.  
> 
A really useful book I'm using is:

"Troubleshooting TCP/IP - Analyzing the Protocols of the Internet" by
Mark A. Miller, 1992, published by M&T Books. List price is US$44.95.

The author "presents over 25 case studies, take from live internetworks,
that demonstrate TCP/IP and the related protocols they use, typical problems
that may occur, plus solutions".

The case studies are presented in the form of Sniffer packet traces, which
are then methodically analysed.

I can't recommend it highly enough, especially if you have a Sniffer!

- Erik.

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 92 20:52:45 GMT
From:      randy@psg.com (Randy Bush)
To:        comp.protocols.tcp-ip
Subject:   Re: Why does my slip line die overnight?

ghawkins@unix1.tcd.ie (George C. Hawkins) writes:
> When I leave my machine overnight and come back in the morning I
> find my slip connection has died on me.

We see the same thing here in Orygun's RAINet.  We believe (urban legend)
that the telco does an 02:00 blast to clear the lines.
-- 
randy@psg.com   ...!uunet!m2xenix!randy

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Sun, 30 Aug 92 22:52:39 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: Why does my slip line die overnight?

In article <1992Aug30.205245.29936@psg.com> randy@psg.com (Randy Bush) writes:
>ghawkins@unix1.tcd.ie (George C. Hawkins) writes:
>> When I leave my machine overnight and come back in the morning I
>> find my slip connection has died on me.
>
>We see the same thing here in Orygun's RAINet.  We believe (urban legend)
>that the telco does an 02:00 blast to clear the lines.

Yep, i've seen similar experiences here, only here it's around 1:30.
It won't necessarily be all the lines, but a significant portion of them.

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu
  loose: v. to set free, or adj. not securely fastened.
  lose: v. to miss from one's possession.

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 92 01:00:15 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Implementation of Distributed Database in SUN RPC

axk7110@usl.edu (Khanna Alok) writes:
>I am working on implementation of a small model of distributed database. 
>I am planning to use SUN RPC for communication between
>different clients and servers. 

	Unless it's just going to be a toy, good luck. There are two main
problems with Sun RPC for doing this:
	a) Unless you're using a multi-threaded RPC server, the
	server will fairly quickly become the bottleneck. Since it
	takes its requests in order of arrival, it's possible that the
	server will sit doing a big (for example) join that will
	take a while, while a request that would be very short
	has to wait.
	b) Since RPC does retransmit if it doesn't get an answer "fast
	enough" in case 'a' above, you may get multiple retransmits. The
	server then blindly redoes operations, unless you wind up writing
	a reliable delivery system, or using TCP RPC or something else.

	Generally, there are enough problems with using RPC (all fixable)
that for anything other than a toy, by the time you've fixed them all,
you might as well have not used RPC.

mjr.

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 Aug 1992 01:54:13 GMT
From:      mcr@Sandelman.OCUnix.on.ca (Michael Richardson)
To:        comp.unix.bsd,comp.sys.sun.hardware,comp.protocols.tcpip
Subject:   [386bsd] NS8390 ethernet evaluation board


  [please note the followup, and email if the have a better suggestion]
  I have two National Semiconductor (Nominal Semidestructor? cute comment)
network evaluation boards. These are 8 bit cards with 8k of ram, an 8390 and
associated logic. I have placed one in my 386 running 386bsd 0.0
(I will be going to 0.1 when my network starts working) The other is
sitting in my Amiga 2000 (via GoldenGate).
  The 386bsd's hostname is bud. (as in _Married With Children_)

  I started with the NE2000 driver and started bashing. At first,
I was amazed at how little code I actually had to modify. (Mostly
just finding all the hardwired assumptions about 32k of ram that the
NE2000 has) My board does not have a reset location, so I needed a bit more 
code to put the NIC in a known state. 

  I just saw someone's suggestion [in comp.unix.bsd] about changing the u_short 
to a u_char --- that made instant sense to me, but it didn't solve the
basic problem I have been having: ARP isn't quite working.
  The other machine in my basement is my trusty Sun 3/60 (hostname: latour). 
I can't confirm that it has ever worked on a network of any kind, but I 
suspect that it would have been diskless over two years ago (before it 
was mine)

  I have traced things (via printf) into arpinput() and arpwhohas()
[in netinet/if_ether.c]. If I start a ping from the 386, it correctly
starts sending arp packets onto the network. Using rpc.etherd and
traffic (ug! suntools. I have X11R4 not openwindows) I can confirm
that arp packets are making it onto the network. No responses are
received.

  If I ping from the 3/60 to the 386bsd, my debugging shows packets
going into arpinput() where it discovers that the request is for the
386bsd and a response is transmitted. Also, rpc.etherd says things like
"rpc.etherd: bad lnth 42 dest ffffffffffffsrc 0800200622c6"
although sometimes the src is garbled. The above src is the Sun's
ethernet address.

  Of note, if I ping in both directions at the same time, then the
386bsd system realizes that it has an ethernet address for the 3/60's
IP address and just transmits. More debugging shows that it even has
the right ethernet address. Also, traffic then reports seeing icmp
packets.

  The 3/60 also transmits period 70 byte and 202 byte packets out
the interface. These should be routing packets from gated (I have
a hardwired slip connection to the Amiga which runs AmigaNOS, and
have had dialup slip connections to friends and work, which is why
I run gated). I believe that these packets are broadcast packets.
I tried bringing up routed to see if it saw anything, but didn't spend
much time on it. 

  I'm starting to suspect that the Sun can't ARP properly. 
  I have tried adding the arp address in with arp(8) on the Sun.
386bsd 0.0 doesn't have arp, so I haven't been able to do the reverse.

  Of note is that I am trying to use a subnet --- ocunix has an
autonomous class C address that is partitioned into 16 address chunks.
I am 128-143. I have tried going with no subnets, with no difference.
I have also tried turning on trailers, and have confirmed that arp is
enabled on both machines. ifconfig says: <UP,BROADCAST,RUNNING,PROMISC>
and NOARP is added if I do ifconfig le0 -arp and goes away for ifconfig
le0 arp. PROMISC goes away when I kill rpc.etherd.
  
  Further data:
    3/60 (latour): 192.139.46.129, 08:00:20:06:22:c6
    Jolix (bud):   192.139.46.130, 08:00:17:40:0b:d4

  There are no other machines on the thinnet segment which is all of
two feet long (although six inches would do the trick)

  I may have a chance to bring my 386 to work this week (but 
work is 25km by bicycle away, so I'd rather not). We have something called 
`EtherVision' that can run on PCs, and I'm familliar with the iptracing
stuff in the RS/6000s machines that I manage. I'm also going to try and find 
a WD8013 card to borrow, but I think they are all committed.

  Does anyone have any other suggestions as to a course of action
here?

-- 
   :!mcr!:            |  The postmaster never | So much mail, 
   Michael Richardson |    resolves twice.    |  so little time.
HOME: mcr@sandelman.ocunix.on.ca     Bell: (613) 237-5629
SCHOOL: 192228@physics.carleton.ca      

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 Aug 1992 01:56:33 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   addresses-translating router/gateway [was Re: Is there a blackbox that will resolve IP conflicts when joining two nets?]

[ In article <MARKE.92Aug29082730@fsi-ssd.csg.ssd.fsi.com>
marke@fsi-ssd.csg.ssd.fsi.com (Mark W. Easter) ask about
the feasibility of an addresses-translating router/gateway. ]

The answer is actually several yes' and no's.

The "yes" is for yes, a router/gateway could be built to translate
the IP addresses in the IP header as it moves between interfaces.

The "no" is for no, because upper-layer protocols which carry IP
addresses in it will break, since the router/gateway couldn't see
those addresses.

The "yes" is for yes, the router/gateway can be made to know about
those protocols and trnaslates the addresses inside them as well.

The "no" is no, the router will never know about the existence of
all such protocols.

So, the answer really depends on the level of "completeness" desired.

...Sam
-- 
<skl@wimsey.bc.ca>

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 1992 05:27:29 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Why does my slip line die overnight?

>In article <1992Aug30.205245.29936@psg.com> randy@psg.com (Randy Bush) writes:
>ghawkins@unix1.tcd.ie (George C. Hawkins) writes:
>> When I leave my machine overnight and come back in the morning I
>> find my slip connection has died on me.
>
>We see the same thing here in Orygun's RAINet.  We believe (urban legend)
>that the telco does an 02:00 blast to clear the lines.

This is probably the same signal that causes my phone to ding in the middle
of the night.  It's a test signal that the phone company sends out, which
some phones are more sensitive to than others.

I've been told that you can call the phone company and ask them to remove
your circuit from the list that this signal is sent to.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 92 07:39:06 GMT
From:      claude@trc.mew.mei.co.jp (Claude Huss)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP source



	Does anyone know about companies selling TCP/IP source code?

	Thank you in advance,

--
+----------------------+-----------------------------------------------------+
| Claude Huss          | Matsushita Electric Works, Ltd. Tokyo Research Labs.|
| Networking Engineer  | Mita 5-13-2, Minato-Ku, Tokyo 108, JAPAN            |
|                      | Phone: +81-3-3452-4941 Fax: +81-3-3451-0793         |
 +----------------------+-----------------------------------------------------+
| Disclaimer:"Any comments for my company > /dev/null"                       |
+----------------------------------------------------------------------------+
             Gaijin Touroku Card: Don't leave home without it!

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 Aug 1992 12:44:29
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP: RFC interpretation

In article <1992Aug20.030954.4831@cssc-woll.tansu.com.au> brian@cssc-woll.tansu.com.au (byrnes brian) writes:
    
    Section 5.4 of the RFC has "each command listed with its possible
    replies".  As I read it, this section would immediately brand 
    responses 1 and 2 as protocol violations, because the server's 
    replies are not on the list of "possible replies".
    
    IBM's representative defended the server's actions in the following
    words:
    "I'm not sure that the intent of section 5.4 is to list each and every
    possible reply code from the server.  However, section 4.2 and 4.2.1
    further define the reply codes and how they can be used to determine
    the state of the machine.  Please have the customer read those sections."

In RFC 1123 (Host Requirements Upper Layers), the subject is discussed
in section 4.1.2.11.  "A Server-FTP SHOULD use the reply-codes defined
in RFC-959 whever they apply.  However, a server-FTP MAY use a
different reply code when needed, as long as the general rules of
section 4.2 are followed."  "A user-FTP SHOULD gnerally use only the
highest-order digit of a 3-digit reply code for making a procedural
decision...".

As I recall the discussion, the issue arose when an HR WG member proposed
that we require a fixed list of reply codes.  However, with further
discussion we decided that the list in RFC 959 wasn't good enough for
all the situations we could imagine, and we had to open the list. 
Nevertheless, an implementor should have good reasons (which I'd hope
they could explain to you) for any divergence from RFC 959.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901


-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 Aug 1992 13:51:59 GMT
From:      stevea@i88.isc.com (Steve Alexander)
To:        comp.protocols.tcp-ip
Subject:   Re: ioctl request SIOCGARP fail in SCO (ARP protocol)

In article <1992Aug28.174957.2213@litwin.com> hoang1@litwin.com (Dave Jackson) writes:
>Hi,
>I'm writing a program to read the ARP cache.
>But I have the problem when using SIOCGARP in SCO/ODT ver 2.0:

In SCO UNIX, you cannot issue arp ioctls on a socket, due to underlying
architectural issues in the STREAMS implementation.  The way to do this
is to open the ARP driver, and issue the ioctl as part of an I_STR 
(see streamio(M)).

Here's a code fragment that might help.

#include <sys/stropts.h>
#include <sys/stream.h>
#ifndef _PATH_ARP
#define _PATH_ARP "/dev/inet/arp"
#endif

	.
	.
	.

        struct strioctl strioc;
        int s;
        int r;
	struct arpreq ar;
        if ((s = open(_PATH_ARP, O_RDWR)) < 0) {
                perror(_PATH_ARP);
                exit(1);
        }
        strioc.ic_cmd = SIOCSARP;
        strioc.ic_timout = 15;		/* seconds */
        strioc.ic_len = sizeof(ar);
        strioc.ic_dp =  (caddr_t) &ar;
        r = ioctl(s, I_STR, (caddr_t) &strioc);
	if (r < 0) {
		perror("SIOCSARP");
		exit(1);
	}
        close(s);


-- 
Steve Alexander, Software Technologies Group    | stevea@i88.isc.com
INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 Aug 1992 14:22:55 GMT
From:      mack23@avalon.eecs.nwu.edu (Chris Walsh)
To:        comp.protocols.tcp-ip
Subject:   Comer and Stevens source available, ordering info

Several people have contacted me regarding the availabilty of the source 
listings from Comer and Stevens, vol. II.  

The source is available, for a (IMHO) reasonable price.  D. Stevens contacted
me with ordering info, but asked that I not post it to the net because this
would be commercial use.  In deference to his wishes, I have reproduced it 
below, with the prices x'ed out.  He will send an unexpurgated version to
anyone who asks.  Stevens' e-mail address is: dls@mentor.cc.purdue.edu 

Herewith, the info from Stevens:

----
	You can order a tape by sending $xx.95 + sales tax for your area (they
pay shipping for prepaid orders) to:

			Book Distribution Center
			Prentice Hall
			Route 59 at Brook Hill Drive
			West Nyack, NY 10995

	For 1/4" Sun cartridge tape, the order number is 47322-3. For 1600 BPI
9-track tape, it is 47233-2.

	You can also order the latest release directly, including some bug
fixes and minor (so far) enhancements that have not made it to the Prentice
Hall distribution yet. To do that, send a check payable to "David L Stevens"
for $xxx to:

			David L Stevens
			c/o Xinu Librarian
			Computer Science Bldg Room 156
			West Lafayette, IN 47907

	Thanks for your interest in the book!

							+-DLS


Any further requests *I* get will be forwarded to Stevens.


--
Chris Walsh                               Pithy Quotation Wanted
TechNet Network Administrator             ----------------------
2145 Sheridan Rd.                         Send candidates to: 
1-5366                                    mack23@avalon.eecs.nwu.edu


-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 92 16:36:15 GMT
From:      kakazu@theory.TC.Cornell.EDU (Gary Kakazu)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,arpa.bind,arpa.nets
Subject:   Maintaining DNS resource records for sites with many hosts

I would like to see if anyone has developed a front end for maintaining
resource records that named uses, particularly for sites that have many
hosts.

What we do is maintain a file in hosts.txt format (RFC 952), which is
sucked in nightly by a bunch of scripts which produce files with the
records.  This has been working fine for several years, but it is less
than forgiving for typos, error checking illegal addresses, etc.
I think this method is fine if you don't have many hosts, but we are
now approaching several thousand hosts.

I would like to find some type of user friendly front end where one
could input the DNS info, do some error checking, and have the resource
record files automagically generated.

Any info would be greatly appreciated!

Thanks
Gary

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 Aug 1992 18:53:38 GMT
From:      pae@blackcat.stortek.com (Phil Earnhardt)
To:        comp.protocols.tcp-ip
Subject:   Re: Implementation of Distributed Database in SUN RPC

In article <1992Aug31.010015.1275@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes:
>axk7110@usl.edu (Khanna Alok) writes:
>>I am working on implementation of a small model of distributed database.  I
>>am planning to use SUN RPC for communication between different clients and
>>servers.
>
>Unless it's just going to be a toy, good luck. There are two main problems
>with Sun RPC for doing this: a) Unless you're using a multi-threaded RPC
>server, the server will fairly quickly become the bottleneck.

Do you really mean multi-threaded here? Most UNIX platforms still lack kernel
support for multi-threading. It sounds like this is a moot issue in this
context.

Sun does supply something that looks a lot like multi-threading for its NFS
server. At initialization time, n NFS servers are forked. When idle, all of
the clients are blocked in a read() on the same UDP socket. Aesthetically,
it's ugly, but it does work. Is there some reason that Khanna couldn't use the
same trick in his code? Is this something that real users can't do without
excessive modification?

>b) Since RPC does retransmit if it doesn't get an answer "fast enough" in
>case 'a' above, you may get multiple retransmits. The server then blindly
>redoes operations, unless you wind up writing a reliable delivery system, or
>using TCP RPC or something else.

Using TCP isn't the worst thing in the world, provided you're not establishing
and tearing down connections on each transaction.

>Generally, there are enough problems with using RPC (all fixable) that for
>anything other than a toy, by the time you've fixed them all, you might as
>well have not used RPC.

Are you talking about ONC RPC, or all RPCs in general?

Netwise's RPC TOOL has certainly addressed the issue of different styles of
dispatching...there are single-threaded dispatchers, multi-processing
dispatchers (forking off a process for new requests) on systems providing
multi-processing, and multi-threaded dispatchers (spawning a new thread for
new requests) on systems providing multi-threading capabilities.

RPCs do seem to take about a 2x hit in throughput vs. hard-coding your network
application. If that's important in your application, then don't use RPCs.

>mjr.

--phil
pae@blackcat.stortek.com

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 92 20:49:22 GMT
From:      nazari@ecn.purdue.edu (Jamshid Nazari)
To:        comp.protocols.tcp-ip
Subject:   Need TCP/IP source

I have SCO 3.2 version 4.1 operating system, with version 4.0 development
system. I would like to install X11 R5. I don't have TCP/IP. 

Could any one tell me the ftp sites where I  might be able to get public
domain TCP/IP source for unix. 

Thank you.

END OF DOCUMENT