HDTenEightyP/NetNews huggingface dataset:
From: bourkej@ul.ie
Newsgroups: comp.protocols.tcp-ip
Subject: Tricky subnet question for gurus
Date: 18 Nov 92 18:11:15 GMT
Organization: University of Limerick, Ireland

Hi,

can someone tell me if the following is cool.

I have a bunch of units with hard coded ip addresses ( yuck ).
I have four networks these must go on.
I have workstations on these networks which need to talk to the units.
The units must be interchangable.


I want to be able to connect to the workstations from any net.  I only need
to talk to the units via the local workstations.

The units and workstations must be able to interact wothout anything 
routing betweeen them.  I'll have a router connecting to each net to
allow access to the workstations.

Is the following valid.


net 1 x.x.4.0	mask 255.255.248.0
net 2 x.x.5.0	mask 255.255.240.0
net 3 x.x.6.0	mask 255.255.248.0
net 4 x.x.7.0	mask 255.255.248.0

units x.x.1.0	mask 255.255.248.0


last three bits of octet 8 are zero.

Using the subnet system, each net can talk to their local units.  Each net
thinks it can talk to each other ( will never happen ).  Each net will think
it can talk to units on other nets ( never happen )

If I put routers on each net with subnet masks of 255.255.255.0, each router
will advertise a router to each net, and only that net.

Is it ok to have different subnet masks on the one net ?

I'd appreciate any reply's by EMail,

Thanks,



john


Newsgroups: comp.protocols.tcp-ip
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Multicast Routers (was Re: NIS broadcasts over IP subnets)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 19 Nov 1992 17:14:32 GMT

In article <1992Nov19.151355.20000@netcom.com>, tbooth@netcom.com (Todd Booth) writes:
> >...
> >In the sense you probably meant the question, I don't know.  For years
> >I hounded router vendors at Interop, and was always told "wait for
> >OSPF."  
> 
> Why have you been waiting?
> 
> OSPF is a draft internet standard and has been available for over
> a year and a half from Wellfleet Communicaitons (and other vendors).
> Cisco has been shipping OSPF since April?


I know OSPF has been a draft standard for ages.  I was only repeating
what the router vendors told me at Interop90 and before.

In the rest of my text, I wrote that at Interop 91 I was told by Cisco
and others "forget DVMRP, and wait for the new link state multicast
protocol that even Steve Deering supports."  (Well, I didn't explicitly
write "Interop 91".)

Why is the IETF multicasting this week being done with tunnels?
Is that only because of the backbone?

Do Wellfleet, Cisco, or others now do the right things when they see a
class D address?  Do they forward such IP packets?

As far as I can tell, the router vendors have been dragging their feet
vigorously on any kind of multicast routing for at least 4 years.  The
router vendors have shown more enthusiasm for PPP, despite the danger
PPP represents to their locked-in customer bases.


vjs
Newsgroups: comp.protocols.tcp-ip
From: jon.taylor@uuserv.cc.utah.edu (JON M. TAYLOR)
Subject: Looking for a UNIX TELNET with Zmodem
Organization: The University of Utah
Date: Mon, 16 Nov 1992 22:37:38 GMT

	Title sez it all.  Does such a beast exist anywhere?
From: kdlin@advtech.uswest.com (David Lin)
Newsgroups: comp.protocols.tcp-ip
Subject: Flow Control
Date: 14 Nov 92 01:29:46 GMT
Organization: U S WEST Advanced Technologies

I understand that many end-to-end sliding window flow control schemes 
( eq. in TCP/IP and in XTP ) use byte as the unit for calculation. For 
example, if the window size is 6K bytes and you have transmitted 2K bytes
without receiving ACKs from the receiver, then you are allowed to transmit
4K more bytes.

Now, if I change the unit for flow control calculation to packet ( or 
frame ), what is the impact to the whole system? What's the implication?

Since most networks have an upper limit for the frame size ( <= MTU ), 
I cannot transmit unlimited-size packets. Consequently, I will be treating
any packets of size in between 1 and MTU equally, as far as flow control
is concerned.

I understand that interactive traffic will be affected first. However,
packet video and packet voice may not be affected at all, especially
when they have real time delivery requirement.

So why am I doing this? I think it will simplify the computation 
needed for the flow control mechanism. Three more questions follow:

1. Are there any circumstances that this scheme ( using packet as
   the computation unit ) is desirable?

2. When it is NOT desirable?

3. Do I really achieve anything by doing that?

Many thanks.

David
-- 
 K. David Lin, Ph.D.              | E-mail: kdlin@advtech.uswest.com  
 Communication Services Research  | Defend your life with style! -- Beretta
 U S WEST Advanced Technologies   | Disclaimer: Only personal opinions
Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans.ethernet
From: hcb@world.std.com (Howard C Berkowitz)
Subject: Re: Wanted: Advice on calculating timing gaps between packets.
Organization: The World Public Access UNIX, Brookline, MA
Date: Wed, 18 Nov 1992 02:41:13 GMT

A few random things to consider.  You will never get the true 10 MBPS from
an IEEE 802.3/ETHERNET LAN, due to some timing requirements of the protocol
itself.  There must be a minimum 9.6 microsecond delay between packets; this
is part of the medium access control process.  There must be enough idle
time that the most distant station will hear a jam signal.

Assuming a single transmitter and a single receiver, the maximum possible
frame-level transfer rate will be based on the length (or length distribution)
of frames, plus the interframe delay.

I often find it worthwhile to write a reasonably quick-and-dirty Monte Carlo
simulation of the line protocols rather than go too far in analyzing them.  

Retransmission time will be based on the time to send the colliding frames, the
interframe delay, and the time to send the next frame.  The backoff algorithm
uses an exponentially increasing delay after each successive collision.  In a
reasonably loaded network, a frame should get through with a maximum of 3-4
collisions (this is fairly pessimistic).  

So much depends on the interarrival times of new frames, the length of frames, and
the number of stations that simulation often is easier.


Always remember that ETHERNET is a service to Arnold Schwarzenegger.  After all, it
is a cable that connects Terminator I with Terminator II. :-)

Newsgroups: comp.protocols.tcp-ip
From: ihsan@ferranti.com (jaleel ihsan)
Subject: TCP simul- & broadcast
Organization: Ferranti International Controls Corporation
Date: Tue, 17 Nov 1992 19:03:08 GMT

At one time class D IP address (224.0.0.0 thru 255.255.255.254) were
reserved for simul-cast and of course 255.255.255.255 for broadcast.

I have a few questions reguarding TCP simul- and broadcasts, if
someone could please enlighten us:

1. What do the latest standards demand from an implementor in this
   regard.

2. What happens to TCP's reliable delivery feature, specially 
   in case of broadcast ?  Does it drop down to the level of UDP ?

3. What are the vendors providing  and supporting in the market place.

I think I saw an article saying that some one has used TCP simulcast
for video teleconferencing (over ISDN perhaps) but I am not sure.

Newsgroups: comp.protocols.tcp-ip
From: scoggin@snow-white.ee.udel.edu (John K Scoggin)
Subject: Re: What is  "RMON" ? Please explain .
Organization: Delmarva Power & Light Company, Newark
Date: Sat, 21 Nov 1992 20:02:24 GMT

In article <1992Nov20.231216.21904@unislc.uucp> mcs@unislc.uucp (Michael Sontum) writes:
>From article <gdox.722256753@informatik.tu-chemnitz.de>, by gdox@informatik.tu-chemnitz.de (Guntram Dox):
>> 
>> Hi,
>> 
>> I read the term "RMON" in a marketing paper from cabletron. 
>> 
>> Somebody told me, it should be something new on top of SNMP .  Programming
>> interface , or so.
>> 
>> Could somebody explain it in more detail ?
>> Please, email to me, too. My access to this news group will be a little bit
>> difficult in the next weeks.
>> Or any pointers to other information would be great.
>>
>
>My knowledge is also sketchy but I recall that it is something like providing
>almost a sniffer type capability to snmp. 
>
>You might try comp.protocols.snmp
>
>I looked through Marshall T. Rose "The Simple Book" from Prentice Hall and 
>the index was down right annoying. I did not see any reference to it.
>
>The only other thing is the gurus have an electronic magazine you can
>get for free by emailing to
>To: st_subscriptions@simple_times.org
>Subject: help
>Add me to the mailing list.
>
>There is also an snmp discussion group: send a note to
>snmp_request@uu.psi.com
>and asked to be added to the snmp@uu.psi.com  list
>
>Also look at the rfc's.
>
>         Mike Sontum
>
>"SNMP:That Dog'll Hunt" -Dr.Jeffrey D. Case       
>
>

Current Internet Draft documents concerning RMON may be obtained as
follows:

	System:		ftp.nisc.sri.com
	Directory:	internet-drafts
	Files:		draft-ietf-rmon-mib-01.txt
			draft-ietf-rmon-trap-00.txt

For some reason, rollout and standardization seem to going very slowly.
This has not stopped a number of manufacturers (Hewlett-Packard, Novell, and
TTC come to mind) from introducing "RMON-compliant" monitors, even though
there is NO standard yet!

Of course, there always comes a time when you have to stop studying and
start implementing - fish or cut bait...  I am planning on buying 25 or 30
RMON segment monitors this spring for our network.

	- John

-------------------------------------------------------------------------
John K. Scoggin, Jr.			Email:   scoggin@udel.edu
Supervisor, Network Operations			 scoggin@delmarva.com
Delmarva Power & Light Co.		Voice:	 302-451-5200
P.O. Box 6066				Fax:	 302-451-5321
Newark, DE 19714-6066
-------------------------------------------------------------------------
Your milage may vary.  Void where prohibited by law (or common sense).
Newsgroups: comp.protocols.tcp-ip
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: ARP & Duplicate IP addresses
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Sat, 21 Nov 1992 06:31:11 GMT

In article <1992Nov20.202906.9279@jupiter.sun.csd.unb.ca>, dedgar@mta.ca writes:
> Hello Net
> 
> I would value opinions, advice and information on the topic of handling 
> duplicate IP addresses with ARP.
> 
> Specifically
> - Is it a good idea to ARP your own IP address on startup? A returning
>   ARP would tell you that the address was a duplicate.
>   - if so is it a good idea to automatically shut your interface down 
>     if a duplicate IP address is detected on startup? Are there any
>     situations where false returns might be reported? 
>  -  What about detecting one after startup? Should you advise the user
>     and gently start terminating connections? Could be real annoying.
> 
> - If you receive an incoming ARP request and the sender IP address matches
>   yours should you reply to it? Doing so would advice the other node that
>   a duplicate exists (assuming it checks) but also could hopelessly confuse
>   a host that doesn't.  All of the implementations that I have tested do not
>   reply - but I have not tried all that many.
> 
> - What are the consequenses of staying up with a duplicate IP address?
> 
> I would value some insight into this topic. Thank You


For some years Silicon Graphics systems have actively defended their IP
addresses.  Instead of just complaining on the console when they see
some other machine ARP'ing their IP address, they respond with an ARP
response of their own.  (With a suitable timeout to prevent network
storms.)

If you don't do this the first machine with the duplicate IP address to
speak disappears.  And the 2nd machine never notices that anything
is wrong.

On the other hand, this ARP screaming often keeps both stations on the
air for rlogin or telnet long enough to take corrective action,
avoiding the need for a house call.  As important, having the old
holder of the address scream causes the interloper to complain on its
console (assuming BSD style console complaints).  The machine that
needs correcting is probably the new user of the IP address.


Vernon Schryver,  vjs@sgi.com
From: heimir@plusplus.is (Heimir Thor Sverrisson)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: X.25 X.29 software wanted for RS6000
Date: 21 Nov 92 11:21:50 GMT
Organization: Plusplus Inc., Reykjavik, Iceland

gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546) writes:


>	Hi, I've been entasked with locating software which runs
>	on an RS6000 under AIX and which provides X.25 connectivity
>	(serial 56Kbps links) and X.29 PAD (incoming and outgoing)
>	as well as application hooks (like sockets).

>	Can anyone here direct me to who makes or sells such
>	software? 

Try:

    Hugbunadur hf, P.O. Box 437, 202 Kopavogur, Iceland
    Tel: +354-1-641024, Fax: +354-1-46288

They are selling a product called HBX-PAD conforming to X.3, X.28 and
X.29 with simple program hooks as well.  I have no direct connection to
them anymore, but was on the team that developed the product, so I
won't tell anymore about it - ask them.

-- 
Heimir Thor Sverrisson		|		heimir@plusplus.is
Plusplus Inc.			|
Laugavegi 13			|		Tel: +354-1-620 250
108 Reykjavik, ICELAND		|		Fax: +354-1-622 819
Newsgroups: comp.protocols.tcp-ip
From: skl@wimsey.bc.ca (Samuel Lam)
Subject: Re: Getting the ethernet address off (SMC)WD8003E Lan Cards
Reply-To: skl@wimsey.bc.ca (Samuel Lam)
Date: Mon, 16 Nov 1992 09:29:16 GMT

In article <1992Nov16.032841.7572@csc.canberra.edu.au>,
 act@softserver.canberra.edu.au (Andrew Turner) wrote:
>Would someone please e-mail a code fragment assembler/pascal/C
>that will return the ethernet address from an WD8003E card.

	unsigned int i, sum = 0, io_base = 0x...;
	unsigned char eprom[8];
	...
	for (i = 0; i < 8; i++)
	    sum += (eprom[i] = inportb(io_base + 8 + i));
	sum &= 0x00ff;
	if (sum != 0xff)
	    /* checksum failed, possibly no board there */
	else
	    printf("MAC address = %02x:%02x:%02x:%02x:%02x:%02x\n",
		eprom[0], eprom[1], eprom[2], eprom[3], eprom[4], eprom[5]);

If you use a Packet, NDIS or ODI driver to access your card, you
could also call the driver to query for the MAC address instead of
asking the card directly as in the above.

>Technical specs and/or info on where I could get the info would also be
>welcome.

SMC/WD provides a driver development kit to those who want to write
codes to talk to the card directly.

...Sam
-- 
<skl@wimsey.bc.ca> -- Connectivity Technology Inc.
Xref: sparky comp.protocols.tcp-ip:5296 comp.protocols.tcp-ip.ibmpc:6489
From: feoh@hal.gnu.ai.mit.edu (Chris Patti)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject: RAW SPEED numbers for various TCP-IP implementations
Date: 23 Nov 92 19:59:56 GMT
Organization: MIT Laboratory for Computer Science


Hello.

Does anyone have any raw numbers on how fast various TCP-IP implementations 
perform (memory to memory, not disk to disk, etc) and various platforms?

Any help in this matter would be appreciated..

P.S. How would you rate 500KB/sec?

-Chris Patti
feoh@gnu.ai.mit.edu
chrisp@ncm.interlan.com
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans,comp.dcom.lans.ethernet,comp.dcom.lans.misc
From: pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.)
Subject: Re: REQ: MSDOS TCP/IP stack in ASM or Pascal
Summary: Use a TSR stack
Keywords: TCP/IP ASM MSDOS Pascal
Organization: University of New South Wales
Date: Thu, 19 Nov 1992 00:56:01 GMT

In article <peter.722065275@palin.cc.monash.edu.au>, peter@palin.cc.monash.edu.au (Peter Hawkins) writes:
> I need to interface a turbo pascal (V6) application to TCP/IP. The
> application is heavily OOP & TVision etc so I pretty well am forced
> to use turbo pascal.
[...]
> (They advised against my attempting it - and suggested I re-write the
> TCP/IP stack in pascal!)
> 
> Before embarking on a major project such as re-writing the stack, or
> giving up and using IPX and Vines, I thought I'd try and see if anyone
> knew:
> 
> 1)  What public domain / commercial TCP/IP stacks are there which might
>     be callable from turbo C?

> peter@palin.cc.monash.edu.au

Peter, a better idea is to buy a commercial stack, which usually loads a
as a TSR. They usually have a documented API, or even a development kit
with the relevent routines to interface to it. That way you can write
your own pascal code or assembler to stuff registers and do an interrupt
(or whatever mechanism they use to interface to the TSR), which is FAR
easier than re-writing a TCP stack inside your application. All of the
common commercial stacks have documented APIs...
Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |If you have trouble sleeping, try lying on the end of
Kensington NSW 2033|   your bed. With a little luck you'll drop off. 
AUSTRALIA          |                              - Mark Twain. 
Newsgroups: comp.protocols.tcp-ip
From: dedgar@mta.ca
Subject: ARP & Duplicate IP addresses 
Reply-To: dedgar@mta.ca
Organization: Mount Allison U, Sackville, N.B. Canada 
Date: Fri, 20 Nov 1992 20:29:06 GMT

Hello Net

I would value opinions, advice and information on the topic of handling 
duplicate IP addresses with ARP.

Specifically
- Is it a good idea to ARP your own IP address on startup? A returning
  ARP would tell you that the address was a duplicate.
  - if so is it a good idea to automatically shut your interface down 
    if a duplicate IP address is detected on startup? Are there any
    situations where false returns might be reported? 
 -  What about detecting one after startup? Should you advise the user
    and gently start terminating connections? Could be real annoying.

- If you receive an incoming ARP request and the sender IP address matches
  yours should you reply to it? Doing so would advice the other node that
  a duplicate exists (assuming it checks) but also could hopelessly confuse
  a host that doesn't.  All of the implementations that I have tested do not
  reply - but I have not tried all that many.

- What are the consequenses of staying up with a duplicate IP address?

I would value some insight into this topic. Thank You

						- Dale Edgar
						  Cybernetic Control Inc.
						  DEDGAR@MTA.CA
From: lars@spectrum.CMC.COM (Lars Poulsen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: What is  "RMON" ? Please explain .
Date: 21 Nov 92 17:35:49 GMT
Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA

Article <gdox.722256753@informatik.tu-chemnitz.de>,
  by gdox@informatik.tu-chemnitz.de (Guntram Dox):
>> I read the term "RMON" in a marketing paper from cabletron. 
>> Somebody told me, it should be something new on top of SNMP .  Programming
>> interface , or so.

In article <1992Nov20.231216.21904@unislc.uucp> mcs@unislc.uucp (Michael Sontum) writes:
>My knowledge is also sketchy but I recall that it is something like providing
>almost a sniffer type capability to snmp. 

The RMON (Remote MONitoring) MIB (Management Information Base) is a
programming specification for how a "sniffer"-like network monitor can
be remotely managed using a modular extension to the SNMP protocol.

Having defined RMON does not magically confer such a monitoring
capability to all SNMP manged network components. Rather, the spec is a
recognition by the IETF (Internet Engineering Task Force) that several
vendors wre implementing such monitoring stations (the first widely
deployed one was the "LANtern") and it would be helpful if they had a
common interface.

RMON boxes (i.e. boxes that do nothing but RMON) are available from
several sources, including some free MS-DOS/PC-based software. RMON
features are also becoming available on the management processor of some
"smart HUBs" (i.e. ethernet repeaters with a microprocessor on the side
for collecting statistics) and on some bridges.

What is harder to find, is an affordable management station that will
display something useful without going through contortions. There is a
lot of value in good user interfaces for massive amounts of data - just
look at the price of the Sniffer and its cousins.
-- 
/ 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
Newsgroups: comp.protocols.tcp-ip
From: davecb@nexus.yorku.ca (David Collier-Brown)
Subject: Re: Is the Balkanization of the InterNet inevitable?
Keywords: security, firewalls
Organization: York University
Date: Sun, 22 Nov 1992 17:18:10 GMT

In article <141672@lll-winken.LLNL.GOV>, casey@gauss.llnl.gov (Casey Leedom) writes:
|   Are network security firewalls between organizations and the InterNet
| going to be the norm in the future? 
[...]
|   If the Balkanization of the InterNet is inevitable, I feel it will be a
| great loss.  It will be an acknowledgement that irresponsible criminal
| hackers have won from us our freedom of open inter-operation.  What a
| sad thought.  Are there no other realistic options for providing security?
| Is it impossible to conceive of effective authentication methods?

smb@ulysses.att.com (Steven Bellovin) writes:
|For the most part, authentication isn't the issue.


  Well, the cracker density is the real consideration (:-)) We're
**very fortunate** in the Internet: commercial firms using X.25
services like the Canadian ``datapac'' find that instead of gaining
security (a vendor promise), they get a very large number of failed
connection attempts.

  These attempts stem from hobbyist crackers working their way through
a universally-acessable, low cost, **receiver pays** service that can
be dialed into from almost every major city in the country, with a
dense set of ``phone numbers'' each of which connects to a known
computer.

   Of course, most sites using this service don't pay attention to the
failures.  Occasionally they discover their monthly bill has leaped up
and that most of the calls are from Brazil, where the traceback
information is unavailable.
   They get little help from the service provider at this point: obviously
its the customer's fault for having bad security on their side of the
PAD, and they can pay the bill, please, forthwith!


  Balkanization? Yes, to a degree, as we strive to learn from our
mistakes.  Of course, if we fail to learn from our governmental
colleagues' mistakes, we deserve to be balkanized (:-))

--dave
-- 
David Collier-Brown,  | davecb@CCS.YorkU.CA | lethe!dave
72 Abitibi Ave.,      | 
Willowdale, Ontario,  | York Postmaster and
CANADA. 416-223-8968  | occasional email consultant.
From: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: tcp sample sources wanted
Date: 17 Nov 92 09:21:54 GMT



 >
 >	Are the sample sources available from the Comer or Stevens books on
 >	tcp/ip - UNIX Network programming? 
 >

stevens' stuff is certainly gettable

e.g. (from archie)
emx.cc.utexas.edu:/pub/netinfo/src/netprog
or 
nic.ddn.mil:/netprog/

i havnt seen comers...srconline, but archie says
arthur.cs.purdue.edu:/pub/comer/
has something in!

 jon

Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
From: rick@nsscmail.att.com (Rick Calder)
Subject: MS-Kermit 3.12 + TCP + PKTMUX-12 ???
Summary: help sought
Organization: NCR Systems Support Center - New Jersey
Date: Sat, 21 Nov 1992 18:16:45 GMT

	Has anyone gotten mskermit 3.12 to work with pktmux 12 when other
TCP software is also active ??
	When I run kermit via TCP as the 1st pktmux user, there is no problem.
If something else has the 1st pktdrv, like PCTCP ethdrv, then the kermit
session over TCP will lockup on the UNIX host side.  Kermit is still active,
the UNIX side still has its shell running, but nothing can be entered to
UNIX via kermit.  Kermit does still respond, as I can do a normal hangup.

setup that works :		setup that doesn't work :
	autoexec.bat :			autoexec.bat :
		pktmux				pktmux
		pktdrv				pktdrv
		pktdrv				pktdrv
	run kermit via tcp			ethdrv
					run kermit via tcp

			Thanks in advance,

		Rick Calder
		      [att!]rick!rick     rick@rick.att.com
				attmail!rcalder
-- 
		Rick Calder, NCR Systems Support Center - New Jersey
		      [att!]rick!rick     rick@rick.att.com
				attmail!rcalder
Xref: sparky comp.protocols.tcp-ip:5185 comp.unix.wizards:4749